This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

How to query Orion.CredentialProperty via rest api ?

FormerMember
FormerMember

Is it possible to query the database table "CredentialProperty" using the rest api ?

The reason for this question is to find a workaround for creating snmpv3 nodes using a "Credential Set Library". If I am not mistaken, snmpv3 nodes can not be created using a credential set library. The credential details must be specified explicitly. Hopefully, I am mistaken on that count. emoticons_happy.png

The workaround I am trying is first to retrieve the credential details using the name of the expected credential set library. And then create the snmpv3 node using the credentials details. Functionally this is the same.

It seems Credential Set Library data is stored into the Credential database table, mapped with the entity Orion.Credential. The credential details reside in the database table CredentialProperty. However, there doesn't seem to be an entity mapping this table. A dead end it seems.

According to the api documentation there are no verbs associated with entities to associate a node with a credential set library.

  • I think you are mistaken, in the current release there are verbs to create an SNMPv3 credential Orion.Credential | Orion SDK Schemas​.

    When you want to add a node right now there are two methods in common usage, the one I recommend is just to have your script build a discovery. In the GUI running a discovery for each new node is kind of a pain, but programatically it makes things a lot easier for us to do the discoveries, even for a single node.  If you go this route you just include the credentialid of your snmpv3 creds in the list and it should be good to go.

    The alternative is to write a script that does a create action against the nodes table.  This can be painful because it requires you to know everything about the node ahead of time and feed all those properties into your script.  There's also pretty much no sanity checking done to nodes added this way, so you can just insert complete trash into the database and as long as the data types aren't incompatible then it will probably show up but there are no guarantees that it is going to work as"normal" nodes do.  You also need to go to the pollers table and create a poller for most of the types of data you want to collect from the node.  You also need to go to the nodesettings table and set the settings there, which is where you would specify the v3 credential to use.  This can be a painful process of trial and error since there are many permutations of pollers that might need to be turned on for the node.  Relying on the built in discovery mechanism skips over a ton of this mess by deciding which pollers apply to the node automatically as the device gets probed and just creating them.  Much less work on your part so you don't have to learn every possible combination of available pollers and account for them in your code, and you can feel reasonably sure that things will just work.

  • Totally agree with mesverrum on using Discovery via API, rather than creating the Nodes from scratch. I know some people do it, but I would advise against it. For our discoveries via API, we programmatically build the SNMP credentials. If you're interested, see this post for what that looks like in Python: How can I make SW reuse SNMP credentials when adding node

    Cheers

  • FormerMember
    0 FormerMember

    What I meant is not to create those. But rather to use the rest api to query this table. The credentials are already created by an authoritative person. I just want to query it.

    If I am not mistaken the entity catalog does not contain an entity mapping with it. Or is there ?

    Maybe there is a way to run an arbitrary sql statement via the rest api ?

  • Orion.credential has the credentialid and the user selected name that was given to the credential, so you shouldn't need to go any deeper since the snmpv3 nodes only require the credentialid in their configuration.  The username and passwords on credentialproperty are encrypted anyway for all current releases so you can't really use that info directly for anything very useful.

    To answer your question about abritrary SQL, there is a verb called executesql under orion.reporting that requires you to be an admin to execute but allows for any kind of sql madness you would like to try.

  • sorry, in my previous post I was not very clear explaining what we do. We programmatically build the SNMP credentials for the discovery, but we don't build it from scratch. In our scenario, we first query the credentials table, grab the SNMP creds, remove public & private, then loop through what's left to build out the credentials for the discovery. Script below was my local dev script. In Prod, there are no print statements, instead it logs as needed.

    snmp_creds = swis.query("SELECT ID, Name, CredentialType FROM Orion.Credential"

                            " WHERE CredentialType LIKE '%snmp%' AND Name != 'public' AND Name != 'private'")

    pprint.pprint(snmp_creds)

    creds = []

    for c in snmp_creds['results']:

        print(c['ID'])

        creds.append(c['ID'])

    print(creds)

    snmp_discovery_creds = []

    order = 0

    for c in creds:

        order = order +1

        cred_id = {'CredentialID': c,

                   'Order': order}

        snmp_discovery_creds.append(cred_id)

    pprint.pprint(snmp_discovery_creds)

    # and this is further down in the script when we start defining the discovery. Notice where we have 'Credentials':  snmp_discovery_creds

    corePluginContext = {

       'BulkList': bulklist_hosts,

       'Subnets': subnets,

       "IpRanges": ipranges,

       'Credentials': snmp_discovery_creds,

       'WmiRetriesCount': 0,

       'WmiRetryIntervalMiliseconds': 1000,

       'IsDiscoveryForVimEnabled': False

    }

    Apologies if this is not addressing what you're working on.

    Thanks