Expand
Support for Unknown Devices
Virtually any SNMP device can be managed by NeDi and I don’t just mean reading some default MIBs. All you need is a .def file which resides in the sysobj folder. In addition CLI support can be added by following the steps in the tutorial or even editing libcli-iopty.pm, but that’s a bit trickier…
Defining Devices
If an unknown device is discovered, you can create a definition file and assign an icon to it, with that it can be properly supported within NeDi.
The easiest way is through Defgen, which can be invoked by clicking on the sysobj value in Devices-List or the triangle icon in Devices-Status. Consult the help (life-saver icon on top) or have a look at the tutorial to learn how to use Defgen.
Device Icons
In order to provide some sort of consistency while not limiting expanding device support, I’ve come up with this scheme, which should cover most of the device types out there. A few exceptions exist, mainly concerning printers and supervisor(s). Use the browser in Defgen to select the icon according to the following scheme…
Colors
The color indicates the device health (starting wtih NeDi 2.0)
| State | Color |
|---|---|
| Good | Green |
| (New) Alert | (Red) Orange |
| Acknowledged Alert, Informal | Blue |
| Unknown | Gray |
Icons
| Type | Subtype | Shade | Icon Name |
|---|---|---|---|
| Cloud (dummy device) | – | – | clm |
| Workgroup Switch (L2) | ~12 Port | pale | s2s |
| Workgroup Switch (L2) | ~24 Port | normal | s2m |
| Workgroup Switch (L2) | ~48 Port | dark | s2l |
| Workgroup Switch (L3) | ~12 Port | pale | s3s |
| Workgroup Switch (L3) | ~24 Port | normal | s3m |
| Workgroup Switch (L3) | ~48 Port | dark | s3l |
| Modular Switch | small | pale | sms |
| Modular Switch | medium | normal | smm |
| Modular Switch | large | dark | sml |
| Switch Stack | – | – | skm |
| Fabric Switch | – | – | sfm |
| Router | small | – | rts |
| Router | medium | – | rtm |
| Router | large | – | rtl |
| Firewall | – | – | fwm |
| Appliance/Computer | – | – | cpm |
| Load Balancer | – | – | lbm |
| IP Phone | – | – | phm |
| Storage | – | – | stm |
| Wlan Access Point | – | – | wam |
| Wlan Bridge | – | – | wbm |
| Wlan Controller | – | – | wcm |
| Sensor | – | – | sem |
| Video System | – | – | vcm |
API
NeDi’s API allows reading data from a table. You can use basic-auth with GET request or submit credentials as well with POST:
GET or POST options:
- t table (prepend with COUNT to count values instead listing them)
- q query in the form of column (= LIKE < > | &) string
- o order column (prepend with – for descending)
- l limit number[,offset]
- m mode csv also returns load and available memory in the 1st row (default is json)
POST only:
- u user
- p password
It uses query.php, which can be presented intuitively with a rewrite rule:
rewrite rule for nginx
location /api {
rewrite ^/api/(\w*)$ /query.php?t=$1&q=$args last;
}
I recommend using RESTClient for Firefox or the Chrome extension “postman” for testing:
As you can see, the rewrite rule assigns the path after API/ to the table (t) variable and the optional query to q…
Without rewrite rule, the API can be used like this:
Queries can be worked out with regular GUI modules. As admin, click on the ladybug in the top right corner to enter debug mode. You can click on a query to examine it further in System-Export. This export module is helpful to explore the database structure as well.
Due to the fact that queries can circumvent NeDi’s tenant filters, the user cannot have a “Filter Devices” set in User-Management.