Where do mcc.py get its data from

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"

Announcement: NAV 3.10.1 released

NAV 3.10.1 is now available for download at Launchpad:
https://launchpad.net/nav/3.10/3.10.1

This maintenance release contains fixes for the following reported
issues, as well as a few other minor tweaks:

  * LP#903096 (Ampersand in organization id crashes ipdevinfo)
  * LP#904605 (netboxinfo subcat column links to a failing page)
  * LP#906763 (SyntaxError in powersupplywatch.py on Python < 2.6)
  * LP#906845 (Status on front page shows device on maintenance as down)
  * LP#906850 (Alert Profiles NoReverseMatch error under Django 1.3)
  * LP#907193 (COMMIT/ROLLBACK error after deleting device (Django 1.3))
  * LP#907204 (seeddb crashes while adding an already existing switch)
  * LP#907741 (NAV 3.10 pping inaccurately reports multitudes of devices as down
               when pinging self)
  * LP#907772 (navtopology crashes with TypeError)
  * LP#910849 (ipdevpoll wastes time and I/O bandwidth with unnecessary SQL
               UPDATEs)
  * LP#910855 (navtopology doesn't avoid multiple instances)
  * LP#911684 (radius accounting log crashes when searching)
  * LP#911786 (servicemon stops sending events)

Also, as Adrian Bucurica discovered, there may be issues with how NAV
handles time unless you're in the Europe/Oslo (CET/CEST) time zone.
nav.conf has been updated to reflect the availability of the TIME_ZONE
option.

Please report bugs at https://launchpad.net/nav/+filebug 

Binary packages for Debian will be made available as soon as

Timezone problem

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

nav 9.10 missing cricket summary info

Ugly and confusing error messages in /alertprofiles/

NAV 3.9.4

When editing filters and other items in Alert profiles we get several error 
messages, but the things we are trying to do is indeed saved. Is this a NAV 
issue or our version of Django?

In Alert Profiles -> Alert addresses -> New address

When I click "Save new" I get the following error, but when I go back to 
<https://nav.uit.no/alertprofiles/address/> I see that the address is saved.

----------
NoReverseMatch at /alertprofiles/address/save/

Reverse for 'alertprofiles-address-detail' with arguments '(None,)' and 
keyword arguments '{}' not found.

Request Method: 	POST
Request URL: 	https://nav.uit.no/alertprofiles/address/save/
Django Version: 	1.3
Exception Type: 	NoReverseMatch
Exception Value: 	

Reverse for 'alertprofiles-address-detail' with arguments '(None,)' and 
keyword arguments '{}' not found.

Exception Location: 	/usr/local/lib/python2.7/site-packages/django/core/urlreso
lvers.py in reverse, line 337
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/simplejson-2.1.6-py2.7-freebsd-8.2-REL
EASE-amd64.egg',
 '/usr/local/lib/python2.7/site-packages/zope.interface-3.6.5-py2.7-freebsd-8.2
-RELEASE-amd64.egg',
 '/usr/local/lib/python2.7/site-packages/pyasn1-0.0.13b-py2.7.egg',
 '/usr/local/lib/python2.7/site-packages/Cheetah-2.4.4-py2.7-freebsd-8.2-RELEAS
E-amd64.egg',
 '/usr/local/lib/python2.7/site-packages/pyasn1_modules-0.0.1a-py2.7.egg',
 '/usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-8.2-RE
LEASE-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']
-------

Similar error occurs when adding a new filter or a new filter group:

NoReverseMatch at /alertprofiles/filters/save/

Reverse for 'alertprofiles-filters-detail' with arguments '(None,)' and 
keyword arguments '{}' not found.

Request Method: 	POST
Request URL: 	https://nav.uit.no/alertprofiles/filters/save/
Django Version: 	1.3
Exception Type: 	NoReverseMatch
Exception Value: 	

Reverse for 'alertprofiles-filters-detail' with arguments '(None,)' and 
keyword arguments '{}' not found.

Exception Location: 	/usr/local/lib/python2.7/site-packages/django/core/urlreso
lvers.py in reverse, line 337

-------

NoReverseMatch at /alertprofiles/filter-groups/save/

Reverse for 'alertprofiles-filter_groups-detail' with arguments '(None,)' and 
keyword arguments '{}' not found.

Request Method: 	POST
Request URL: 	https://nav.uit.no/alertprofiles/filter-groups/save/
Django Version: 	1.3
Exception Type: 	NoReverseMatch
Exception Value: 	

Reverse for 'alertprofiles-filter_groups-detail' with arguments '(None,)' and 
keyword arguments '{}' not found.

Exception Location: 	/usr/local/lib/python2.7/site-packages/django/core/urlreso
lvers.py in reverse, line 337
Python Executable: 	/usr/local/bin/python

--Ingeborg
--

-- 
Ingeborg Østrem Hellemo  --  ingeborg.hellemo@...
Dep. of Information Technology  ---  Univ. of Tromsø

Announcement: NAV 3.10.0 and 3.9.4 released

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

Announcement: NAV 3.10.0 and 3.9.4 released

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

COMMIT/ROLLBACK error after deleting device

When I delete a device I get an

"Error: Transaction managed block ended with pending COMMIT/ROLLBACK"

The device is deleted, but the error message (in red) is noisy and confusing.

NAV 3.9.3
postgresql-client-8.4.8
postgresql-server-8.4.8_1

--Ingeborg
--

-- 
Ingeborg Østrem Hellemo  --  ingeborg.hellemo@...
Dep. of Information Technology  ---  Univ. of Tromsø

Issues with status-page and box down

2 issues really:

At the moment I have 3 boxes down, one of which is on maintenance.

1. The "Status now" box on the NAV front page shows also the box which is on 
maintenance as down. Is this a bug or a feature? NAV pre 3.9 was silent about 
boxes on maintenance on the front page.

2. https://nav.example.com/status/ shows correctly one box as on maintenance, 
but the "IP devices down" is empty! I have to click on the history-tag to find 
my two boxes (which went dows yesterday, but are still down).

 
--Ingeborg
--

-- 
Ingeborg Østrem Hellemo  --  ingeborg.hellemo@...
Dep. of Information Technology  ---  Univ. of Tromsø

Bug in reports, subcategories

We use subcategories extensively. There is a bug in the report generator 
related to subcats.

Howto reproduce: 
* Goto Home > Report > Server (or some other category with subcategories). 
* Click on subcats for a server which belongs to a subcategory. You are now in 
<https://nav.uit.no/report/netboxinfo?netboxid=(#ofnetbox)>.
* Click on the name of a subcategory
* You will now enter https://nav.uit.no/report/netboxinfo?category=(Name of 
subcat)>

Lo and behold:

Netboxinfo
Configuration error! The report generator is not able to do such things. 
column "category" does not exist LINE 1: ...IN netboxcategory USING 
(netboxid)) AS foo WHERE category =... ^

--

-- 
Ingeborg Østrem Hellemo  --  ingeborg.hellemo@...
Dep. of Information Technology  ---  Univ. of Tromsø

Problems after upgrade to 3.9.3

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