While designing ipdevpoll, we decided to throw out the over-engineered
OID database from NAV. The tables haven't been removed yet, but none
of the new code makes use of them.
Now, it looks like we need to keep some aspects of the OID database.
While configuring Cricket, makecricketconfig needs to know ahead of
time which proprietary OIDs from the Cricket config files are
supported by an IP device. In other words, makecricketconfig still
needs to have an SNMP OID profile for a box.
John-Magne has written a script that will pull all configured OID
labels from the Cricket configuration tree, and insert them into NAV's
snmpoid table. I've written an oidprofiler plugin to ipdevpoll, which
does most of what getDeviceData's OID tester did.
But, some superfluous fields can be removed from the snmpoid and
netboxsnmpoid tables to complete the transition to NAV 3.6:
* The netboxsnmpoid.frequency and snmpoid.defaultfreq fields are right
out, since these tables will no longer be used for scheduling
* snmpoid.oidsource is irrelevant in the new context.
* snmpoid.descr, oidname and mib can be safely removed. If anyone
needs them, they can be inferred by a mib compiler.
* snmpoid.decodehex is just ridiculous.
* snmpoid.match_regex is unnecessary, because there is no such
information in the Cricket config files.
And the more interesting part:
* snmpoid.uptodate - We can't really assess whether an snmpoid is
really up-to-date or not. When gDD sees an snmpoid with
uptodate=false, it will query that snmpoid for all netboxes and set
uptodate=true. But "all netboxes" only means all netboxes that are
online at the moment. There is no guarantee that all netboxes were
My suggestion is that we rather set netbox.uptodate=false for all
netboxes when snmpoids are inserted or updated. Re-profiling a
netbox is not a huge operation (especially since the current cricket
config contains about 12 OIDs that need to be profiles), and new
snmpoids will not be inserted very often.
This can be implemented via a simple trigger or rule on the snmpoid
This is FYI, and a heads-up for a possible discussion on Monday's