Nav-users

nav-users@lister.sikt.no

1376 discussions

Announcement: NAV 3.11.1 released
by Morten Brekkevold 22 Mar '12

22 Mar '12

NAV 3.11.1 is now available for download at Launchpad: https://launchpad.net/nav/3.11/3.11.1 This maintenance release contains the following improvements: * Unrecognized neighbors report is now back, with improved information and populated with source data from both CDP and LLDP. * Running out of available file descriptors while opening SNMP sockets is logged more informatively. * ipdevpoll will not run jobs unnecessarily for devices whose SNMP agents are known to be down. .. and fixes for the following reported issues: * LP#890142 (sysname is not updated from DNS for non-SNMP devices) * LP#953967 (Don't store router port addresses for shutdown ports) * LP#954766 (CDP plugin crashes with AttributeError on some devices) * LP#955087 (Geomap fails to draw map after OpenStreetMap shut down tiles@home server) * LP#955789 (sc.03.11.0004.sql fails on PostgreSQL 9) * LP#955808 (navtopology ValueError: need more than 1 value to unpack) * LP#955861 (ipdevpoll topo job IntegrityError) * LP#956772 (navtopology doesn't delete unused vlan records) * LP#956904 (ipdevpoll creates unusable Vlan records) * LP#956910 (ipdevpoll is unable to detect cisco router trunks properly) * LP#956955 (mcc.py creates sensors configuration for netboxes that have no SNMP community) * LP#959081 (Error in IP filter causes AlertEngine to crash) * LP#959156 (ipdevpoll AttributeError: LoggerAdapter instance has no attribute 'warn') * LP#961123 (ipdevpoll topo job UnboundLocalError in neighbor processing) * LP#961206 (Non-conformance to IPV6-TC in IPV6-MIB causes inventory job crash) * LP#961238 (ipdevpoll topo job crash when storing blocked ports for some Procurve switches) * LP#961566 (FieldDoesNotExist error in ipdevpoll: ifoperstatus_change) * LP#961573 (ipdevpoll ValueError: u'1.3' is not a valid sysObjectID) 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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users