NAV 3.1.0 is now available for download at SourceForge, see
This is mainly a bugfix release, and some serious issues have been fixed
in this version, including one security vulnerability discovered by Jim
Binary packages for Debian will be available at a later time. The Debian
package is maintained by Morten Werner Olsen, and he is currently
polishing his nearly finished packaging of the 3.1.0 release.
We would also like to welcome anyone interested in maintaining packages
for RPM-based distributions!
Release notes for NAV 3.1.1
Please report bugs at http://sourceforge.net/projects/nav
Upgrading from NAV 3.0.1
An old error, confusing HP hardware versions with firmware versions, caused
storms of incorrect devHwVerChanged alerts for HP equipment in previous
versions of NAV. The fix in version 3.1.1 involves changing an entry in the
NAVdb's snmpoid table - the entry for oidkey='hpHwVer' should be changed to
The new hpFwVer OID will be inserted into the snmpoid table when you re-run
the `snmpoid.sql` script, but to make sure the existing entry is renamed, the
following SQL command should be performed on the manage database using psql
(running `psql manage` as the postgres user):
SET oidkey='hpFwVer', descr='Firmware revision number'
WHERE snmpoid = '22.214.171.124.126.96.36.199.188.8.131.52.1.4.0'
Upgrading from NAV 3.0
You must remember to upgrade your database scheme. The new Arnold subsystem
requires its own database. Please read doc/sql/README for instructions on how
to create this database and initialize it. Use the script and instructions
provided in doc/sql/upgrades/3.1.0.sql to upgrade the rest of the database
The recommended database setup has changed. Previously, the README suggested
creating two database users `navread` and `navwrite`, and sometimes even a
`manage` superuser. It then suggested creating the NAV databases as the
postgres/manage superuser, while the provided sql scripts would grant
read/write privileges on the tables to the navread and navwrite users. The
new recommendation is to create only one database user called `nav`, and
specify this user as the owner of the databases when creating them. Hence,
the provided db.conf has been changed to reference only this one user.
PostgreSQL versions prior to 8.0 do not have explicit commands to change a
database's owner. Because of this, we've prepared an SQL script which should
be suitable to use for upgrading to the new user scheme on both PostgreSQL 7.4
and 8. Be warned though, that this script will create a new database user
called nav, DELETE the old users and reset all privileges on the NAV tables.
If you've made any customizations here, they will be *lost* by running the
The script is located in `doc/sql/upgrades/3.0-to-3.1-users.sql`. To run it,
simply perform the following as the postgres user:
psql -f doc/sql/upgrades/3.0-to-3.1-users.sql template1
If you don't want to use this script, and you are running _PostgreSQL 8.0_ or
newer, you can create the `nav` user as suggested in the README, and the use
the following SQL commands to make it the owner of the NAV databases:
ALTER DATABASE manage OWNER TO nav;
ALTER DATABASE navprofiles OWNER TO nav;
ALTER DATABASE logger OWNER TO nav;
Which ever solution you choose, make sure to update your db.conf to at least
include the bits about Arnold in the db.conf supplied with this version.
pysnmp must be downgraded to version 2. Any release from the major version 2
will do, as of this writing the latest version is 2.0.9.
forgetSQL 0.5.1 has a bug which may affect the web interface of NAV 3.1 in
weird ways (looks like a deadlock, which makes page loads hang forever). The
upstream author is working on making a bugfix release, but if you're an
impatient expert, you can manually patch your forgetSQL 0.5.1 installation.
The patch is contained in contrib/patches/forgetSQL-0.5.1.patch (this is the
same patch that was sent upstream).
(released 08 November 2006)
* The session mechanism of the web interface contained a potential directory
traversal vulnerability. A mitigating factor was that an attacker would
first need write access to the local file system of the NAV server. The
vulnerability was discovered by Jim Gallacher, and is similar to a
vulnerability discovered in mod_python:
* getDeviceData no longer attempts to map Cisco submodules into NAV's data
model. This solves several Cisco related module problems.
* Any module without switch ports would erroneously be detected as down when
the module monitor ran single handedly. Typically, they would stay marked
as down for five hours, go up for one hour, then down again for another
* getDeviceData threads working with equipment that enabled VLANs above 1023
would crash, causing incomplete information to be collected from these
devices.. It no longer crashes, but NAV still will not properly support
more than 1024 vlans (#1518783)
* getDeviceData should no longer generate repeated, incorrect
deviceHwVerChanged alerts for HP equipment (#1550393).
* Fixed bug that would cause a getDeviceData collector thread to crash when a
device appeared not to support the ifHighSpeed OID.
* A couple of getDeviceData plugins had NullPointerExceptions.
* Initial Cricket/makecricketconfig setup was botched after directory
restructuing. Makecricketconfig is now more flexible when locating a
system's cricket installation, and where its config and data are placed.
* Some SQL errors in EditDB were fixed.
* Fixed bugs in SNMP getnext handling in EditDB.
* Fixed an EditDB hardcoded limitation of 10 characters in an IP device's
orgid field - the database allows up to 30 characters.
* EditDB would crash when inserting devices that happened to return non-ASCII
serial numbers. Non-ASCII serial numbers are now ignored.
* Removed code from networkDiscovery that attempted to traverse non-routed
VLANs. This code was not properly tested, and potentially caused several
topology related problems.
* Build/install errors related to Arnold were fixed.
* A bug caused by hardcoded values in Arnold prevented it from blocking ports
on equipment of other categories than EDGE, even if it was configured to
* Status page preferences no longer crashes with a Python traceback
* The Traffic Map admin buttons no longer disappear when the Traffic Map
applet is reloaded (#1495566).
* The traffic map would never display any load data for links on interfaces
with spaces in their names (such as ATM interfaces on Cisco devices).
* The "black load" syndrome of the Traffic Map has been compensated for.
* The cam collector would not insert port numbers in cam records unless NAV
had collected proper ifName/ifDescr values for the ports in question.
* The pping and servicemon processes now properly perform a double fork and
detach completely from the controlling terminal when daemonized. When the
daemons had been started/restarted in an SSH session, this bug would
sometimes cause said SSH session to hang on logout.
* Fixed a bug which rendered NAV's Cheetah templates incompatible with
* Various other small bugfixes and cosmetic changes.