API: bug or works as designed? update_device_field switches back to standard value

Help
1

Hi,

I’m trying to connect our “home brew component database/ipam/configuration database” to LibreNMS as our new monitoring solution.
Question: the API-function “update_device_field” is supposed to edit any field of a device, am I right?

If so, then I think I stumbled upon a bug in the API: when I try to patch the field “type” to “wireless”, it switches back to “server”.

Steps:

curl -k -X POST -d '{"hostname":"HOSTNAME","snmp_disable":"true","os":"ping","hardware":"AP-Hardware"}' -H 'X-Auth-Token: MYTOKEN' https://MY.SERVER.ADDRESS/api/v0/devices
{
"status": "ok",
"message": "Device HOSTNAME (42) has been added successfully"
}
 
curl -k -X PATCH -d '{"field":"type","data":"wireless"}' -H 'X-Auth-Token: MYTOKEN https://MY.SERVER.ADDRESS/api/v0/devices/HOSTNAME
{
"status": "ok",
"message": "Device type field has been updated"
}

curl -k H 'X-Auth-Token: MYTOKEN' https://MY.SERVER.ADDRESS/api/v0/devices/HOSTNAME
{
"status": "ok",
"devices": [
    {
    (...)
    "type": null,
    (...)
    }
],
"count": 1
}
 
output from the same command a few minutes later showed:
(...)
"type":"server",
(...)

In the WebUI Eventlog, whenever I try to switch the “type” field by API, it shows:

System Device type changed wireless => server

Changes done through the WebUI to the field “type” are persistent, but no option for me.

Output of “./validate.php”

LibreNMS  | 1.42.01-34-g731da950d
DB Schema | 258
PHP       | 7.0.30
MySQL     | 10.0.34-MariaDB
RRDTool   | 1.4.7
SNMP      | NET-SNMP 5.7.3

[OK]    Composer Version: 1.7.2
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[OK]    Database schema correct
[FAIL]  fping6 could not be executed. fping6 must have CAP_NET_RAW capability (getcap) or suid. Selinux exlusions may be required.
 (/usr/sbin/fping6: can't create raw socket (must run as root?) : Operation not permitted)
[FAIL]  fping6 should be suid!
[FIX] chmod u+s /usr/sbin/fping6

(The [FAIL] in the output is of no importance to us so far as LibreNMS is running in a test area without IPv6.)

2

Some fields will be overwritten by the discovery/poller. For example, type is tied to the OS, so, whatever OS is detected will set the type.

1 Like
3

Thanks for the answer, so it works as designed.

But: the device isn’t accessed by SNMP at all, it’s only pinged. So where does disco/poller get it’s information from?:thinking:

Back in the lab: I just set the “os” field by API to “” (which worked) and tried to change the “type”-field, but no success, it again switched back to “server”. So I guess it’s a fallback. If I get it right, LibreNMS has two grouping mechanisms: one by the field “type” (which is in some cases determined by the field “os”, in some cases not and it has a default value of “server”) and one by the configurable patterns based on the columns in the “devices” table.

Idea 1: put a list of the fields in the docs with the information whether they are overwritten by the poller or not and if so, with what, depending on what and what’s the fall back value.

Idea 2: add free configurable tags for structuring as suggested by @Tadpole in Tags for creating dissimilar Device Groups - suggestable and formulaic and make them usable in the patterns for grouping devices to .

(Note to myself: first dig deeper in the code, then read more docs - or vice versa)

Keep up the good work, me really likes LibreNMS. :+1:

1 Like