Nav-users

nav-users@lister.sikt.no

1 participants
1378 discussions

Announcement: NAV 3.10.0 and 3.9.4 released
by Morten Brekkevold 16 Des '11

16 Des '11

The newest feature release of NAV, version 3.10.0, is now available for download at Launchpad: https://launchpad.net/nav/3.10/3.10.0 The last bugfix release of the 3.9 series is also available at https://launchpad.net/nav/3.9/3.9.4 Both releases include fixes for the following issues: * LP#898992 (ipdevinfo displays all ports as blocking whereas stpblock report confirms that they're not) * LP#900723 (No SW version on Cisco 4506E L3 switch) * LP#900779 (smsd crashes when discarding non-dispatchable messages with non- ASCII chars) * LP#901623 (mcc does not update maximum threshold value for interfaces) * LP#903128 (servicemon/pping opens a new connection on any database error) * LP#903681 (room report should include position) * LP#904178 (smsd removes permanently failed dispatchers even when it should ignore permanent failures) The 3.10.0 release also fixes these issues: * LP#744940 (geomap should default to a sensible start map) * LP#894727 (No server software versions since NAV 3.5) The 3.10.0 release adds the following user-visible features and improvements: * VLAN subtopology detection has been rewritten to Python. The old networkDiscovery Java program is now deprecated. * Alerts when SNMP agents stop responding. * Alerts on power failure SNMP traps from UPS units. UPS-MIB (RFC 1628) and proprietary MIBs from Eaton Corporation, APC and MGE are supported. * Configurable port link status monitoring and alerting in ipdevpoll, independent of SNMP trap configuration. * Alerts on redundant power supply and fan failures on Cisco and HP devices. * Statistics from all environment sensors (such as temperature, humidity, light, sound, etc.) detectable through either ENTITY-SENSOR-MIB (RFC 3433), CISCO-ENVMON-MIB or IT-WATCHDOGS-MIB (IT Watchdogs WeatherGoose) are now collected via Cricket. * pping can now ping IPv6 hosts. * ipdevinfo and Machine Tracker now perform bulk DNS lookups in parallel, improving page load times when DNS is slow. Don't forget to check out the release notes before/during/after upgrading to NAV 3.10. 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

1 0

Problems after upgrade to 3.9.3
by Sigurd Mytting 09 Des '11

09 Des '11

Hi, I've run into trouble after upgrading to 3.9.3 via apt-source, system is debian 6.0.3, this was not a problem with 3.9.2. First the message during upgrade: Setting up nav (2+3.9.3-1) ... Installing new version of config file /etc/nav/sortedStats.conf ... Installing new version of config file /etc/nav/smsd.conf ... Installing new version of config file /etc/nav/report/report.conf ... Traceback (most recent call last): File "/usr/share/doc/nav/sql/syncdb.py", line 463, in <module> main() File "/usr/share/doc/nav/sql/syncdb.py", line 44, in main sync.synchronize() File "/usr/share/doc/nav/sql/syncdb.py", line 220, in synchronize self.apply_changes() File "/usr/share/doc/nav/sql/syncdb.py", line 305, in apply_changes self.apply_change_script(version, script) File "/usr/share/doc/nav/sql/syncdb.py", line 326, in apply_change_script self.execute_sql_file(script) File "/usr/share/doc/nav/sql/syncdb.py", line 352, in execute_sql_file self.cursor.execute(sql) psycopg2.extensions.QueryCanceledError: canceling statement due to statement timeout CONTEXT: SQL statement "DELETE FROM ONLY "manage"."rrd_datasource" WHERE $1 OPERATOR(pg_catalog.=) "rrd_fileid"" and if I try adding a new device I get: Something went wrong Something went wrong while processing your request. Please try again later. If the problems persists, contact your system administrator and/or report a bug on NAV bugtracker. And an error when trying to delete a device: Error: canceling statement due to statement timeout CONTEXT: SQL statement "UPDATE ONLY "manage"."cam" SET "netboxid" = NULL WHERE $1 OPERATOR(pg_catalog.=) "netboxid"" When digging into the postgres-log I find (everything from a database restart with two delete attempts): 2011-12-07 10:11:04 CET LOG: database system was shut down at 2011-12-07 10:10:55 CET 2011-12-07 10:11:04 CET LOG: database system is ready to accept connections 2011-12-07 10:11:04 CET LOG: autovacuum launcher started 2011-12-07 10:11:05 CET LOG: incomplete startup packet 2011-12-07 10:12:00 CET ERROR: canceling statement due to statement timeout 2011-12-07 10:12:00 CET CONTEXT: SQL statement "UPDATE ONLY "manage"."cam" SET "netboxid" = NULL WHERE $1 OPERATOR(pg_catalog.=) "netboxid"" 2011-12-07 10:12:00 CET STATEMENT: DELETE FROM "netbox" WHERE "netboxid" IN (162) 2011-12-07 10:15:01 CET LOG: unexpected EOF on client connection 2011-12-07 10:18:22 CET ERROR: canceling statement due to statement timeout 2011-12-07 10:18:22 CET CONTEXT: SQL statement "UPDATE ONLY "manage"."cam" SET "netboxid" = NULL WHERE $1 OPERATOR(pg_catalog.=) "netboxid"" 2011-12-07 10:18:22 CET STATEMENT: DELETE FROM "netbox" WHERE "netboxid" IN (162) 2011-12-07 10:20:02 CET LOG: unexpected EOF on client connection Anyone having any idea on what's going on? Postgresql has been tuned a bit with allowing 1000 simultaneous connections, but should otherwise be standard. Best regards, -Sigurd

2 4

Announcement: NAV 3.9.3 released
by Morten Brekkevold 05 Des '11

05 Des '11

NAV version 3.9.3 is now available for download at Launchpad: https://launchpad.net/nav/3.9/3.9.3 This maintenance release includes the following: Improvements: * Using the `-d` option with cleanrrds.py will now also remove references to stale availability and response time RRD files from NAV's database. This should help against the "Availability: N/A" issue seen by some in ipdevinfo, whereas bugfixes to pping should prevent it from creating new entries while leaving stale ones in the future. Bugfixes: * LP#586334 (HTTPS service checker doesn't work with Python 2.6) * LP#744958 (ranked stats config file should default to mbit/s) * LP#888056 (MacWatch GUI crashes if the input of the MAC address is invalid) * LP#891542 (Add option to make smsd ignore "permanent" dispatch errors) * LP#891568 (logengine cron mail complains: global name 'ENOENT' is not defined) * LP#893591 (pping crashes when rrd files already exist) * LP#897175 (ipdevpoll stops polling a device whose type is yet unregistered) * LP#897194 (NameError when adding IP device in SeedDB) * LP#898128 (Trying to seed - when going to USAGE crash) Please report bugs at https://launchpad.net/nav/+filebug :-) A binary package 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

***SPAM***End of year Online Bonanza...
by Europe Royal 01 Des '11

01 Des '11

Europe Royal Online Program Amsterdam - Holland. Tel: 0031-685242542 Fax: 0031-847508652 online1(a)europe.com Ref: ER/07533 Ticket Number: 025613-ING. Are you the owner of this email address? Congratulations! Your email have been officially selected as a winner from Europe Royal Online. You are hereby authorised for claim with your email attached to winning ticket Number: 025613-ING for the 2nd category winning prize of Seven Hundred and Fifty Thousand Euros and a Dell Latitude Laptop. Contact Notarization Officer: Mr Laurens Nijenhuis Email: notarization(a)winning.com with required informations below: Full Names Occupation: Address: Country: Telephone: Ticket Number: 025613-ING. Regards, Wotide Mo Sope. Europe Royal. © 2011 Europe Royal. All rights reserved. Terms of use. Privacy Statement.

1 0

Re: Question for NAV Users with Cisco 3750 Stacks
by Borge Brunes 21 Nov '11

21 Nov '11

gwc2004(a)gmail.com said: > I'm looking for some input from anyone using NAV with Cisco 3750 switch > stacks. If you have a stack of 2 or more 3750's and all the L2/L3 interfaces > are being properly pulled from it by NAV, then would you mind sharing what > version of IOS you are using? [cut] Seems to be working fine with 12.2(55)SE4 (c3750-ipbasek9-mz.122-55.SE4.bin) regards, -- Borge Brunes, Computer Center, University of Tromso, Norway http://www.cc.uit.no/~borge/ | http://www.freebsd.org

2 1

Announcement: NAV 3.9.2 released
by Morten Brekkevold 21 Nov '11

21 Nov '11

Unfortunately, there were no releases while I was on leave, so it's time to get back on track: NAV version 3.9.2 is now available for download at Launchpad: https://launchpad.net/nav/3.9/3.9.2 This release includes bugfixes for the following issues: * LP#300708 (Improve the link up/down trap plugin to include description) * LP#338696 (Postgresql service checker is actually a port checker) * LP#787957 (No trunk information on H3C switches) * LP#802408 (Lowercase cricket rrd file not found when sysname has uppercase letters) * LP#854696 (Adding a new filter or new filter group in Alert Profiles fails) * LP#858055 (Creating a new maintenance task with ÆØÅ in description fails) * LP#862208 (No cricket stats for directories "routers" and "switches" in cricket) * LP#865292 (HTTP service checker ignores query string) * LP#890190 (linkstate trap handler does not work) * LP#890607 (Set supervisor SW version as chassis SW version on Cisco devices) * LP#891090 (pping creates multiple RRD files for same data, causing ipdevinfo to display availability as N/A) Please report bugs at https://launchpad.net/nav/+filebug :-) A binary package 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

Differences in SNMP results between versions
by Seb Rupik 17 Nov '11

17 Nov '11

Hi all, I have been tasked with creating a new NAV (3.9.1) install. All appears to be fine until I compare it against the previous old (3.5.4) installation. The majoirty of our switches are Cisco 3750's nearly all stacked, but the new install doesn't seem to acknowledge this under 'IP Device Info' where the 'Modules' field shows '0', but the 'switch port status' table shows all interfaces spanning the stack. On the old install the 'Modules' field has the correct number and the 'Switch port status' shows the right number of separate modules. Looking under: 'Report-> Vendors -> Cisco' confirms that the new install is receiving less SNMP OIDs per switch stack; typically 75. Where as the old install is showing between 88-90 for the same stacks. Also in some cases the new install is not showing any returns under #mod, #swp, #gwp and #prefixes, where is does on the old install. Both installs are running libsnmp1.4-java; the old 1.4-5, and the new install 1.4.2-2. Would that account for the differences? What's the best way to test the two installs side by side in an output based comparison? Many thanks, seb.

4 8

Question for NAV Users with Cisco 3750 Stacks
by Greg Cooper 17 Nov '11

17 Nov '11

Hi, All. I'm looking for some input from anyone using NAV with Cisco 3750 switch stacks. If you have a stack of 2 or more 3750's and all the L2/L3 interfaces are being properly pulled from it by NAV, then would you mind sharing what version of IOS you are using? I think I may be running into an SNMP issue with the particular version of IOS I'm on. I get timeouts when querying the 3750 via SNMP. I can do an snmpwalk from the NAV server to the device, and it runs for a while, but it will sometimes time out. Thanks! Greg

4 3

NAV reference committee
by Morten Brekkevold 15 Nov '11

15 Nov '11

Hello all, I just wanted to say a few words about the NAV reference committee, which was established just last week. Those of you who aren't one of UNINETT's NREN customers in Norway may or may not be aware that NAV is one of the many free software offerings to our customers. We even operate remote NAV servers as a service for ~30 of our smaller customers. We try to concentrate our development efforts to meet the demands of our customers in higher education (HE), and since this is a free software project we also cooperate with some of our HE customers, who regularly contribute to and maintain parts of NAV (some by their own volition, others commissioned and paid by us). It is not always clear what the customer wants. Some of our customers are very vocal about what they want, others keep quiet, maybe spilling their guts in the occasional face to face meeting (or maybe not even then). So we've revived a several years old idea to establish a kind of committee of reference for NAV development. This committee consists of representatives from our HE customers, and would be responsible for collecting, massaging, filtering and prioritizing wishes for further NAV development from the HE community. This committee was established on Thursday 10th November here in Trondheim, and consists of the following representatives: * Vidar Faltinsen, UNINETT (committee leader/secretary) * Morten Brekkevold, UNINETT (lead NAV developer) * Gro-Anita Vindheim, Norwegian University of Science and Technology * Børge Brunes, University of Tromsø * Jan Sigurd Refvik, University of Oslo * Rune Kittelsen, University of Agder * Peder Sefland, Volda University College The committee will publish its work on the web at [1], were you can already find the minutes from the inaugural meeting. As we're the Norwegian NREN, the committee's working language will be Norwegian - if you don't speak Norwegian, you may want to try using Google Translate or similar services to translate those pages if you want to see the details of what's going on (although automatic translation may confuse more than it helps ;-) ). Nevertheless, the results of the committee's input will be visible in how we prioritize bug reports and blueprints on our Launchpad project page [2]. Have a great day! [1] https://ow.feide.no/gigacampus:nav-ref [2] https://launchpad.net/nav -- Morten Brekkevold UNINETT

1 0

Twisted SNMP Patch Question
by Greg Cooper 15 Nov '11

15 Nov '11

Hello, I have a question about this from the NOTES: The latest TwistedSNMP version (0.3.13) contains a bug that manifests in table retrieval operations. Timeouts and retries aren't handled properly, and this may cause slow or otherwise busy devices to be bombarded with requests from NAV. The `contrib/patches` directory contains a patch for TwistedSNMP that solves this problem. The patch has been submitted upstream, but not yet accepted into a new release. Alternatively, you can install `pynetsnmp` for improved performance. I think I am running into the Twisted SNMP timeout issues talked about here. So my question is this: When it says, "Alternatively, you can install pynetsnmp for improved performance" does that mean that instead of patching TwistedSNMP, i can just do an apt-get install pynetsnmp and then I don't have to worry about the Twisted SNMP library's problems? If so, do I have to uninstall twisted SNMP? If I still have to patch Twisted, then what is the best way for me to go from using the standard debian packaged TwistedSNMP to using the patched one I build from scratch? I don't want to be stuck where I have both installed, but it is still using the old version. Thanks in advance, Greg

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