- Nav-users - lister.unit.no

Where do mcc.py get its data from
by Ingeborg Hellemo 19 Mar '12

19 Mar '12

NAV 3.10.1 We have several (but not all) routers and switches where cricket try to collect data fram OIDs the devices doesn't know anything about. I fail to find any similarities in type of device or OS-version between the devices. For a switch the offending lines in switches/navTargetTypes looks like this: targetType brusS101-sw.infra.uit.no ds = "c1900Bandwidth, c1900Bandwidth, c1900BandwidthMax, c1900BandwidthMax, mem5minFree, mem5minFree, mem5minUsed, mem5minUsed, sysUpTime, sysUpTime, c2900Bandwidth, c2900Bandwidth, c5000Bandwidth, c5000Bandwidth, c5000BandwidthMax, c5000BandwidthMax, cpu1min, cpu1min, cpu5min, cpu5min, hpcpu, hpcpu, hpmem5minFree, hpmem5minFree, hpmem5minUsed, hpmem5minUsed" view = "bandwidth: c1900Bandwidth c1900BandwidthMax c2900Bandwidth c5000Bandwidth c5000BandwidthMax, cpu: cpu1min cpu5min hpcpu, memory: hpmem5minFree hpmem5minUsed mem5minFree mem5minUsed, sysuptime: sysUpTime" Note that it tries to collect both c1900Bandwidth, c2900Bandwidth and c5000Bandwidth When I check the device via https://nav.example.com/report/netboxsnmpoid?netbox id=## I don't find any OIDs relating to Bandwidth at all. For Cisco routers the offending OID is hpcpu and hpmem*. targetType kulth-gsw.infra.uit.no ds = "c5000Bandwidth, c5000BandwidthMax, cpu1min, cpu5min, hpcpu, hpmem5minFree, hpmem5minUsed, mem5minFree, mem5minUsed, sysUpTime" view = "bandwidth: c5000Bandwidth c5000BandwidthMax, cpu: cpu1min cpu5min hpcpu, memory: hpmem5minFree hpmem5minUsed mem5minFree mem5minUsed, sysuptime: sysUpTime" Any ideas why mcc.py puts them in? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no Dep. of Information Technology --- Univ. of Tromsø

3 10

Geomap has gone blank since the end of February
by Morten Brekkevold 14 Mar '12

14 Mar '12

It has been brought to our attention that NAV's Geomap has recently gone blank. Apparently, this is because OpenStreetMap has pulled their support for the Osmarender layer, which is one of the two OSM layers initialized and used by Geomap (the other being Mapnik). A post [1] on the OSM-dev list explains what has happened. As a response, we've removed the Osmarender layer from Geomap; this will be effective from the NAV 3.11.1 release, but if you wish to patch your current NAV installation to enable Geomap again, the patch is available at [2]. [1] http://lists.openstreetmap.org/pipermail/dev/2012-February/024301.html [2] http://metanav.uninett.no/hg/default/rev/516efd5456a4 -- Morten Brekkevold UNINETT

1 0

Announcement: NAV 3.11.0 and 3.10.4 released
by Morten Brekkevold 13 Mar '12

13 Mar '12

The newest feature release of NAV, version 3.11.0, is now available for download at Launchpad: https://launchpad.net/nav/3.11/3.11.0 The (hopefully) last bugfix release of the 3.10 series is also available at https://launchpad.net/nav/3.10/3.10.4 Both releases include a fix for the following embarrassing issue: * LP#947080 (Netbox attributes aren't updated when modules are found) The 3.11.0 release adds the following user-visible features and improvements: * LLDP support for improved topology detection. * getBoksMacs replaced by ipdevpoll plugins in `topo` job (i.e. fewer Java dependencies) * Q-BRIDGE-MIB now also used when collecting switch forwarding tables, meaning improved machine tracking data for switch vendors like HP, Juniper and Alcatel. * The Machine Tracker's IP search form has consolidated the `To` and `From` IP address search fields into a single `IP Range` search field with extended search syntax for ranges of IP addresses. See LP#643544 for details. * ipdevpoll can now be made to run single job configurations from ipdevpoll.conf, to run in the foreground, and to log to stderr instead of its log file. * ipdevpoll will reset its log levels from logging.conf upon receiving a SIGHUP signal. * ipdevpoll will log the currently active polling jobs upon receiving a SIGUSR1 signal. Don't forget to check out the release notes before/during/after upgrading to NAV 3.11. Please report bugs at https://launchpad.net/nav/+filebug :-) Binary packages for Debian will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. Happy NAVing everyone! -- Morten Brekkevold UNINETT

3 2

Using NAV as a source for rancid
by Sigurd Mytting 12 Mar '12

12 Mar '12

Hi! We´re looking into using rancid (http://www.shrubbery.net/rancid/) for keeping track of device configuration. I´d like to use the NAV database to build the rancid configuration. Currently I use dump.py, but I need more of the internal NAV data per device, most importantly I need to know the device vendor - cisco, juniper, alteon and so on. Is there an easy way to get a more complete dump of the NAV database? Cheers, -Sigurd

2 3

unsubscripe nav-users
by Jan Bakke 02 Mar '12

02 Mar '12

unsubscripe nav-users

1 0

Announcement: NAV 3.10.3 released
by Morten Brekkevold 02 Mar '12

02 Mar '12

NAV 3.10.3 is now available for download at Launchpad: https://launchpad.net/nav/3.10/3.10.3 This maintenance release contains fixes for the following reported issues, as well as a few other minor tweaks: * LP#906849 (Status page does not show current IP devices down) * LP#936926 (mcc registers sensors RRD files in wrong directory) * LP#937622 (a device's supported snmp version is never updated) * LP#937677 (type, device and various other attributes aren't updated) * If you're on NAV 3.10, we recommend that you upgrade as soon as possible, as these bugs are quite crippling if they hit you. * After the upgrade, we also recommend running `cleanrrds.py` with the -d option, to clean NAV's database of references to non-existant sensor-related RRD files. Please report bugs at https://launchpad.net/nav/+filebug :-) Binary packages for Debian will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. Happy NAVing everyone! -- Morten Brekkevold UNINETT

2 1

Device with strange(?) snmp-implementation triggers bug in seeddb
by Ingeborg Hellemo 23 Feb '12

23 Feb '12

Nav version 3.10.2 Django debug is intentionally turned on We need to monitor uptime on our printers and add them to NAV in category OTHER. When we add snmp-enabled SafeCom controllers (<http://www.betasoft.co.uk/safeco m/safecom_ext_controller.htm>) seeddb barfs while talking snmp to the device with ValueConstraintError at /seeddb/netbox/edit/1691/ SingleValueConstraint for 'Version': value 0 not within allowed values: [1] Request Method: POST Request URL: https://nav.uit.no/seeddb/netbox/edit/1691/ Django Version: 1.3.1 Exception Type: ValueConstraintError Exception Value: SingleValueConstraint for 'Version': value 0 not within allowed values: [1] Exception Location: /usr/local/lib/python2.7/site-packages/pysnmp/asn1/constra ints.py in __call__, line 40 Python Executable: /usr/local/bin/python Python Version: 2.7.2 Python Path: ['/usr/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg', '/usr/local/lib/python2.7/site-packages/Cheetah-2.4.4-py2.7-freebsd-8.2-RELEAS E-p5-amd64.egg', '/usr/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-freebsd-8.2 -RELEASE-p5-amd64.egg', '/usr/local/lib/python2.7/site-packages/pyasn1-0.1.2-py2.7.egg', '/usr/local/lib/python2.7/site-packages/python_ldap-2.4.7-py2.7-freebsd-8.2-RE LEASE-p5-amd64.egg', '/usr/local/nav/lib/python', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7', '/usr/local/lib/python2.7/plat-freebsd8', '/usr/local/lib/python2.7/lib-tk', '/usr/local/lib/python2.7/lib-old', '/usr/local/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/site-packages'] Traceback: File "/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response 111. response = callback(request, *callback_args, **callback_kwargs) File "/usr/local/nav/lib/python/nav/web/seeddb/page/netbox/edit.py" in netbox_edit 49. if netbox_form.is_valid(): File "/usr/local/lib/python2.7/site-packages/django/forms/forms.py" in is_valid 121. return self.is_bound and not bool(self.errors) File "/usr/local/lib/python2.7/site-packages/django/forms/forms.py" in _get_errors 112. self.full_clean() File "/usr/local/lib/python2.7/site-packages/django/forms/forms.py" in full_clean 268. self._clean_form() File "/usr/local/lib/python2.7/site-packages/django/forms/forms.py" in _clean_form 296. self.cleaned_data = self.clean() File "/usr/local/nav/lib/python/nav/web/seeddb/page/netbox/forms.py" in clean 81. self._check_ro_community(ip, ro_community, cat) File "/usr/local/nav/lib/python/nav/web/seeddb/page/netbox/forms.py" in _check_ro_community 106. version = self.get_snmp_version(ip, ro_community) File "/usr/local/nav/lib/python/nav/web/seeddb/page/netbox/forms.py" in get_snmp_version 135. snmp.get(sysobjectid) File "/usr/local/nav/lib/python/nav/Snmp/pysnmp_se.py" in get 99. rsp.berDecode(answer) File "/usr/local/lib/python2.7/site-packages/pysnmp/asn1/encoding/ber/base.py" in berDecode 296. input = self[key].berDecode(input) File "/usr/local/lib/python2.7/site-packages/pysnmp/asn1/encoding/ber/base.py" in berDecode 202. self._setRawAsn1Value(value) File "/usr/local/lib/python2.7/site-packages/pysnmp/asn1/base.py" in _setRawAsn1Value 169. self._subtype_constraint(value) File "/usr/local/lib/python2.7/site-packages/pysnmp/asn1/base.py" in _subtype_constraint 78. c( self, value ) File "/usr/local/lib/python2.7/site-packages/pysnmp/asn1/constraints.py" in __call__ 40. self.values.keys(), Exception Type: ValueConstraintError at /seeddb/netbox/edit/1691/ Exception Value: SingleValueConstraint for 'Version': value 0 not within allowed values: [1] It is quite possible that the SNMP-implementation on these devices are odd, but seeddb should be able to cope in a more elegant way. Attached is the output of snmpwalk of the device without any fancy flags. Let me know if you need more info. --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no Dep. of Information Technology --- Univ. of Tromsø

2 1

Announcement: NAV 3.10.2 released
by Morten Brekkevold 21 Feb '12

21 Feb '12

NAV 3.10.2 is now available for download at Launchpad: https://launchpad.net/nav/3.10/3.10.2 This maintenance release contains fixes for the following reported issues, as well as a few other minor tweaks: * LP#258298 (Service alerts aren't closed on service deletion) * LP#392022 (Incorrect IPv4 net address prefix link in Subnet matrix) * LP#744930 (vlan report for closed vlans is empty) * LP#744933 (IP range searches in radius accounting tool ignores timestamp) * LP#912210 (pping crashes when its PID is >= 32768) * LP#912219 (Network explorer incomplete domain names) * LP#920882 (moduleDown alerts reference affected module only as "$module") * LP#920886 (Status page doesn't show modules down) * LP#922566 (SQL syntax errors from getBoksMacs on PostgreSQL 9.1) * LP#922586 (Cisco 1900 switches cause getBoksMacs SNMP walks to go into infinite loops) * LP#922616 (report system behaves badly if accessed without a trailing slash in url) * LP#923641 (Fan outage on HP devices never reported) * LP#925928 (HP Virtual Connect Ethernet modules report crazy MAC addresses, making getBoksMacs spew SQL errors) * LP#925956 (link from organization report to prefix report crashes report page) * LP#928754 (Installing database on PostgreSQL 9 fails) Please report bugs at https://launchpad.net/nav/+filebug :-) Binary packages for Debian will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. Happy NAVing everyone! -- Morten Brekkevold UNINETT

2 1

Sanitizing table cam in the nav database
by Nik Mitev 14 Feb '12

14 Feb '12

Hello, I have created a pilot installation of NAV, currently handling 16 production switches. It seems that the cam table, holding the MAC addresses seen on the switches is growing very fast and holding large amounts of redundant information, in some cases up to 250 entries per MAC address. I am looking for ways to restrict the amount of history kept, as we only need to know which switch/port a MAC is on, rather than a full history of online/offline status changes. This can of course be done by scripts, I was wondering though is there any relevant built-in functionality already present? Thanks, Nik

2 1

Timezone problem
by Adrian Bucurica 05 Jan '12

05 Jan '12

Hello everyone, We've just started to test NAV and I have a strange problem with the timezone reported in NAV. It seems that NAV reports all operations using timezone GMT+1 (Western Europe) but on localhost we have configured a different timezone: diff -s /etc/localtime /usr/share/zoneinfo/`cat /etc/timezone` Files /etc/localtime and /usr/share/zoneinfo/America/Chicago are identical We are using Debian Squeeze 64-bit and NAV 3.10 installed from source. What am I missing? Regards, Adrian

2 2