When trying to lift a detention where the interface in question is on a Cisco device, the webpage return 500.

Traceback (most recent call last):

File "/usr/lib/pymodules/python2.6/django/core/handlers/base.py", line 100, in get_response
response = callback(request, *callback_args, **callback_kwargs)

File "/usr/lib/pymodules/python2.6/nav/web/arnold/views.py", line 292, in lift_detentions
open_port(identity, account.login, 'Enabled from web')

File "/usr/lib/pymodules/python2.6/nav/arnold.py", line 394, in open_port
change_port_vlan(identity, identity.fromvlan)

File "/usr/lib/pymodules/python2.6/nav/arnold.py", line 468, in change_port_vlan
raise ChangePortVlanError(error)

ChangePortVlanError: An error occured when changing portvlan: Illegal value for vlan: None

Imported from Launchpad using lp2gh.

• date created: 2013-02-28T12:58:57Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1135699

It appears that some database error causes AlertEngine in NAV 3.5.0b1 to be unable to delete old alerts, and it keeps re-sedning them over and over.

See the attached excerpt from alertengine.log for more information.

Imported from Launchpad using lp2gh.

• date created: 2008-10-17T12:06:07Z
• owner: mbrekkevold
• assignee: adamcik
• the launchpad url was https://bugs.launchpad.net/bugs/284939

Under NAV 4.2 (up to 4.2.1), if an IP device currently on endless ("until up") maintenance is deleted from NAV, the maintenance engine (maintengine) will crash on every run, effectively rendering the entire maintenance system broken. No new maintenance tasks will be activated, and active ones will remain active indefinitely.

The problem occurs because maintengine will attempt to extract information about the deleted component from the maintenance task. Traceback from maintengine.log looks like this:

[2014-12-03 11:35:02,057] [ERROR] [pid=13467 nav.maintengine] An unhandled exception occurred:
Traceback (most recent call last):
File "/usr/lib/nav/maintengine.py", line 40, in main
check_devices_on_maintenance()
File "/usr/lib/python2.7/dist-packages/nav/maintengine.py", line 220, in check_devices_on_maintenance
check_tasks_without_end()
File "/usr/lib/python2.7/dist-packages/django/db/transaction.py", line 224, in inner
return func(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/nav/maintengine.py", line 84, in check_tasks_without_end
end_time = subject.last_downtime_ended()
AttributeError: 'NoneType' object has no attribute 'last_downtime_ended'

Imported from Launchpad using lp2gh.

• date created: 2014-12-03T11:58:52Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1398791

On installations using PostgreSQL 8.1 and the PostgreSQL 8.1 JDBC driver,
the three NAV processes getDeviceData, eventEngine and getBoksMacs seem to
produce exceedingly many SQLExceptions with the message "This statement has
been closed".

Example stacktrace:
SQLException for update statement: INSERT INTO netbox_vtpvlan
(netboxid,vtpvlan) VALUES ('379','921')
org.postgresql.util.PSQLException: This statement has been closed.
at
org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(AbstractJdbc2Statem
ent.java:2409)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.getUpdateCount(AbstractJdbc2Sta
tement.java:480)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Stat
ement.java:288)
at no.ntnu.nav.Database.Database.update(Database.java:1004)
at no.ntnu.nav.Database.Database.insert(Database.java:928)
at
no.ntnu.nav.getDeviceData.dataplugins.Netbox.NetboxHandler.handleData(Netbo
xHandler.java:225)
at DataContainersImpl.callDataHandlers(DataContainersImpl.java:69)
at QueryNetbox.run(QueryNetbox.java:808)

[http://sourceforge.net/tracker/index.php?func=detail&aid=1798698&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2007-09-20T18:49:00Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/258267

We've received several reports about missing machine tracker data for
switches. Looking at the OID compatibility profile of these switches, one
sees that NAV has decided these switches are not compatible with the
macPortEntry OID (dot1dTpFdbPort), which contains the cam table (or bridge
table, if you will).

Having getDeviceData's OID-tester re-classify these switches seems to have
no effect, as it still says the switch does not answer the macPortEntry
query. A switch without an accessible bridge table is not worth the
plastic it is contained in.

Further investigation reveals that only Cisco switches are affected, and
that these switches either do not have a VLAN 1, or that there are no
entries in the bridge table for VLAN 1.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1812189&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2007-10-12T18:41:00Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/258275

When using a profile to detain users, you have the option to turn on exponential increase of duration for repeated offenders. If you turn off this, a previous offender will be detained the same duration as the last time he was detained no matter what the duration of the detention profile says.

Imported from Launchpad using lp2gh.

• date created: 2015-01-20T10:43:26Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1412735

The upgrade-script for NAV-3.4.2 (doc/sql/upgrades/3.4.2.sql) contains a small bug :

In the "CREATE OR REPLACE RULE rrdfile_deleter" definition :
DO DELETE FROM rrd_file
WHERE key='serviceid' AND value=old.serviceid;
WHERE key='serviceid' AND value=old.serviceid::text;

The last two lines isnt suppose to be there?

Imported from Launchpad using lp2gh.

• date created: 2008-08-22T10:40:21Z
• owner: a-l-prois
• assignee: jodal
• the launchpad url was https://bugs.launchpad.net/bugs/260330

the fix for bug 1177754 introduced yet another regression, thanks to the ill conceived idea that is camlogging monitored devices in the first place.

The net effect is that any VLAN that has a monitored SRV or OTHER in it will have MAC addresses of any equipment logged on all link ports, which is way outside the design parameters for camlogging. Any switch in a VLAN will also be logged on each of the other switches' ports it is visible from.

Once rolled out, the 3.14.15926 release also seems to increase server load immensely, which may be related to the fact that the camlogger suddenly does a lot more work, but this remains to be seen.

Recommended fix is to rollback all the changes related to camlogging SRV and OTHER devices, despite the reference committee's wishes. This entire feature needs to be rethought.

Imported from Launchpad using lp2gh.

• date created: 2013-06-27T08:55:28Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1195206

Traceback (most recent call last):
File "/usr/lib/nav/autoenable.py", line 69, in
main()
File "/usr/lib/nav/autoenable.py", line 57, in main
eventcomment="Opened automatically by autoenable")
File "/usr/lib/pymodules/python2.6/nav/arnold.py", line 377, in open_port
identity.interface))
File "/usr/lib/pymodules/python2.6/django/db/models/fields/related.py", line 302, in get
rel_obj = QuerySet(self.field.rel.to).using(db).get(**params)
File "/usr/lib/pymodules/python2.6/django/db/models/query.py", line 341, in get
% self.model._meta.object_name)
nav.models.manage.DoesNotExist: Interface matching query does not exist.

Imported from Launchpad using lp2gh.

• date created: 2013-02-15T15:44:40Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1126341

In NAV versions up to 3.15.2, a bug in the ipdevpoll camlogger has been identified.

Prerequisites:

1. A switch has open CAM records in the NAV database.
2. The camlogger cannot find any CAM records on the device (e.g. alle the ports have become link ports or all access ports have been disconnected)

Result:

When no CAM records are collected in a run, the Cam cleanup routines are never run, which means the open CAM records for this switch aren't expired from the database.

A cleanup sentinel should be introduced into the Cam shadow model in ipdevpoll, such as is the case with several other models. This would force the CamManager to be used during the processing stage, after plugins have run.

Imported from Launchpad using lp2gh.

• date created: 2013-11-13T08:59:02Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1250760

The readabilty of the netmap is bad. Shorter names will help. Cut of the suffix based on
the domain_suffix attribute from nav.conf.

In addition default to a larger font size. Even with a few boxes only the graph is not readable.

Imported from Launchpad using lp2gh.

• date created: 2008-10-18T08:12:23Z
• owner: faltin-uninett
• assignee: klette
• the launchpad url was https://bugs.launchpad.net/bugs/285361

Django 1.0 is targeted for release September 2 2008 (current release is beta-1). To jump from the version NAV are currently using (SVN r7534) to 1.0, some changes have to be made to the Django code in NAV.

http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges contains details of the about 30 backwards incompatible changes done to Django between our current version and Django 1.0. We should do this jump before the release of NAV 3.5.0 in September 2008.

Imported from Launchpad using lp2gh.

• date created: 2008-08-23T00:24:06Z
• owner: jodal
• assignee: jodal
• the launchpad url was https://bugs.launchpad.net/bugs/260554

Under rare circumstances, the eventengine (and possibly, other parts of NAV as well) will enter an infinite loop, rendering it unable to continue processing events, and thus alerts will cease to be dispatched from NAV.

The issue arises from the nav.manage.Module.get_chassis() method, which traverses the NetboxEntity hierarchy bottom-up in an attempt to find the chassis that owns the respective module.

If the hierarchy, for some unknown reason, such as a either a NAV bug or a vendor SNMP implementation bug, contains cycles (i.e. it's not a proper tree), the loop may never exit.

The code attempts to protect against infinite loops, but only considers the corner case where an entity points to itself as its parent, not the case that two entities point to each other as their respective parents (which seems to be the case at one customer's installation)

Imported from Launchpad using lp2gh.

• date created: 2016-05-04T08:21:02Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1578108

NAV's shim for authenticating requests to the Cricket CGI script does not insert 'wsgi.input' into the simulated wsgi environment, which, apparently, Django 1.4.5 seems to require.

Imported from Launchpad using lp2gh.

• date created: 2013-09-25T14:08:15Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1230299

Several users report that their getDeviceData process freaks out and makes
strange changes to their NAV database.

Looking at stderr logs reveals that the Java process has run out of heap
memory. In turn, this seems to throw the PostgreSQL JDBC driver out of
whack, producing numerous SQLExceptions about protocol errors.

The symptoms make it look like a memory leak, i.e. something in the code
holds on to data references that are never used again. There is cause to
believe the problem arises because of unexpected SNMP responses from
devices that gDD is monitoring.

The problem is present in both versions 3.1.1 and 3.2.1.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1675508&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2007-03-07T15:50:00Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/258239

Searching for an IP-address gives you multiple hits with the same combination of start time and end time.
(see attached screenshot)

The "IP search results" part of "MAC search" gives you the correct results...

This error started occuring after upgrading to version 3.4.3

Imported from Launchpad using lp2gh.

• date created: 2008-10-03T12:41:17Z
• owner: ssj
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/277569

NAV 3.5.3 introduces a regression, causing web logins to fail with a traceback when running under Python 2.5 or newer.

A patch was introduced to the nav.pwhash module to make it compatible with Python 2.6, where the hashlib module replaces the md5 and sha1 modules. Importing the latter will raise DeprecationWarnings.

The patch imports hashlib in a manner that is incompatible with the md5 and sha1 usage in the rest of the module.

This traceback was reported by Pau on the nav-users mailing list:

DocumentRoot: '/usr/local/nav/apache/webroot'

URI: '/index/login'
Location: None
Directory: '/usr/local/nav/apache/webroot/'
Filename: '/usr/local/nav/apache/webroot/index.py'
PathInfo: '/login'

Phase: 'PythonHandler'
Handler: 'mod_python.publisher'

Traceback (most recent call last):

File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
1537, in HandlerDispatch
default=default_handler, arg=req, silent=hlist.silent)

File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
1229, in _process_target
result = _execute_target(config, req, object, arg)

File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
1128, in _execute_target
result = object(arg)

File "/usr/lib/python2.5/site-packages/mod_python/publisher.py",
line 213, in handler
published = publish_object(req, object)

File "/usr/lib/python2.5/site-packages/mod_python/publisher.py",
line 425, in publish_object
return publish_object(req,util.apply_fs_data(object, req.form, req=req))

File "/usr/lib/python2.5/site-packages/mod_python/util.py", line
554, in apply_fs_data
return object(**args)

File "/usr/local/nav/apache/webroot/index.py", line 194, in login
authenticated = account.authenticate(password)

File "/usr/local/nav/lib/python/nav/db/navprofiles.py", line 119, in
authenticate
return stored_hash.verify(password)

File "/usr/local/nav/lib/python/nav/pwhash.py", line 116, in verify
password=password)

File "/usr/local/nav/lib/python/nav/pwhash.py", line 80, in init
self.update(password)

File "/usr/local/nav/lib/python/nav/pwhash.py", line 96, in update
hasher = known_methods[self.method].new(password + self.salt)

File "/usr/lib/python2.5/hashlib.py", line 98, in __hash_new
return __get_builtin_constructor(name)(string)

File "/usr/lib/python2.5/hashlib.py", line 77, in __get_builtin_constructor
raise ValueError, "unsupported hash type"

ValueError: unsupported hash type

Imported from Launchpad using lp2gh.

• date created: 2009-05-14T10:39:55Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/376430

the rrdvalues for the link stat in netmap are not the correct values.

An example of the link oslo-trd netmap shows values of 144Mbps and out:130Mbit
Correct values should be over a gigabit.

Imported from Launchpad using lp2gh.

• date created: 2008-10-18T08:06:27Z
• owner: faltin-uninett
• assignee: klette
• the launchpad url was https://bugs.launchpad.net/bugs/285358

The sql-query for finding mac-addresses and ports based on an ip-address
does not give the expected results. The query tries to find historical
ports based on a wrong assumption.

Fix:
Rewrite the sql-query.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1992863&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2008-06-13T18:43:00Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/258312

Any module that NAV has not registered any switch ports
for, will repeatedly be marked as down. Typically, it
will mark such a module as down for five hours, then
mark it as up again for one hour, and then mark it as
down again for the next five.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1583453&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2006-10-24T16:58:00Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/258219

At Oslo University College, the Netmap displays some layer 2 links as layer 3 links.

The initial view shows all GWs and GSWs and the layer 3 links between them. When adding the SW category to the filter list, but not checking the layer 2 filter, a bunch of SWs appear. This should not be possible, as switch topology comes from the layer 2 topology information (the netbox_to/swport_to fields from the swport and gwport tables).

Layer 3 topology is only derived from the link, core (and external links via elink) nettypes.

Pulling the raw GraphML from Netmap's backend shows the data from the backend is to blame. It contains edges between the routers and switches and mark these as nettype=link and also lists a netident from some link network. The SQL statement used to produce the GraphML also appears to make this mistake.

An SQL output from Oslo University College has been mailed privately to Kristian.

Imported from Launchpad using lp2gh.

• date created: 2008-10-21T11:13:08Z
• owner: mbrekkevold
• assignee: klette
• the launchpad url was https://bugs.launchpad.net/bugs/286922

The active ip collector stores the number of active ip addresses on a prefix every 30 minutes. However the collection of this data is very slow and, depending on the size of the arp table, often takes more than 30 minutes.

Fix the queries so that it has one query for collecting now and one for collecting and filling historic data.

Imported from Launchpad using lp2gh.

• date created: 2013-01-23T13:21:21Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1103455

After observing a customer installation of NAV, we speculate that the following events occurred, leading to the situation described in the summary:

1. A router was shut down.
2. ipdevpoll's snmpcheck plugin generated an snmpAgentState start event for the router.
3. ipdevpoll temporarily ceased all SNMP communication with the router as a consequence of the registered SNMP error state.
4. A new router booted up in the old router's place.
5. ipdevpoll's snmpcheck plugin generated an snmpAgentState end event for the router.
6. eventengine was unable to match the end event to the start event, because the device id had changed, and consequently rejected the event.
7. Steps 5 and 6 repeat; ipdevpoll's normal SNMP polling of the router never resumes because the alert state is never resolved.

What is not entirely clear from this, is in which step the new deviceid was set for the router, as that discovery would require SNMP communication with the device. Further investigation is warranted.

• ipdevpoll's detection and handling of device replacements should be reviewed.
• eventengine's matching of stateful events that may occur as a result of device replacements should be reviewed.

Imported from Launchpad using lp2gh.

• date created: 2014-01-16T08:49:29Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1269714

Since NAV 3.14.1, Netmap is no longer working. The menus aren't loaded, and the map itself only displays an animated spinner.

Developer tools show that no AJAX requests are made after page load, which likely means none of the Netmap's code is running.

Imported from Launchpad using lp2gh.

• date created: 2013-03-19T12:14:45Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1157154

I have tested ipdevinfo at uninett and hio and many circumstances ipdevinfo uses a long time, som times it just hangs and hangs,
in other cases it simply fails with the message:

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.

Imported from Launchpad using lp2gh.

• date created: 2008-10-18T06:42:22Z
• owner: faltin-uninett
• assignee: jodal
• the launchpad url was https://bugs.launchpad.net/bugs/285328

Running doc/sql/manage.sql gives the following errors:

psql:doc/sql/manage.sql:216: ERROR: relation "arp" does not exist
psql:doc/sql/manage.sql:220: ERROR: relation "cam" does not exist
psql:doc/sql/manage.sql:819: ERROR: operator does not exist: character
varying = integer

The rules netbox_close_arp and netbox_close_cam are defined on the netbox
table, referring to the cam and arp tables before they are created.

Also, the definition of the rule rrdfile_deleter will fail on PostgreSQL
8.3 because of its stricter typecasting rules.

[http://sourceforge.net/tracker/index.php?func=detail&aid=2023345&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2008-07-21T15:24:00Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/258319

The eventEngine inadvertently uses an inccorrect way of discovering the
maintenance status of devices. It relies on the tables of the old
messages/maintenance subsystem, which was replaced in NAV 3.2.0.

The old tables have been dropped, cause the eventEngine's device plugins to
throw SQLExceptions when attempting to collect device data. The
eventEngine consequently fails to see any of the devices in the NAVdb and
will not function properly for most events.

See nav-users posting:
http://desperados.itea.ntnu.no/pipermail/nav-users/2007-February/001580.htm
l

[http://sourceforge.net/tracker/index.php?func=detail&aid=1660516&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2007-02-15T19:46:00Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/258231

The syncdb.py program, which was previously a part of NAV's documentation files, is now the navsyncdb program in the bindir. However, the Makefile does not install this program into the bindir, which is a problem for binary distributions and will confuse any user following the install docs.

Imported from Launchpad using lp2gh.

• date created: 2013-09-25T12:11:14Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1230240

The SNMP trap daemon cannot load any of its handler plugins from the
nav.snmptrapd.handlers package, because the nav/snmptrapd directory is
missing its init.py . Thus Python doesn't recognize nav.snmptrapd as a
proper package.

The problem isn't easy to reproduce, because snmptrapd only imports the
plugins as traps are received and not at the start of the process.

Reported by Ingeborg Hellemo of the University of Tromsø.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1822650&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2007-10-30T16:55:00Z
• owner: mbrekkevold
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/258279

NAV 3.2.2 introduced some caching into IP Device Center to speed up page
loads. Unfortunately, this caching is braindead and broken, and causes
wrong and confusing results for end users.

The cache of port activity results is stored in a global variable in the
devBrowse.module module. Once an Apache child process handles a request to
an IP Device Center page, this cache will be filled with results for the
given device and interval. These results are then re-used for all
subsequent IP Device Center requests in this Apache child process, no
matter which device is browsed or which activity interval is selected.

This may have worked fine in the development environment, where each Apache
child process is configured to only handle one request each and then die,
but not in a production environment.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1811548&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2007-10-11T20:32:00Z
• owner: mbrekkevold
• assignee: jodal
• the launchpad url was https://bugs.launchpad.net/bugs/258274

In NAV 3.15.1, thresholdMon appears to crash on every run when it wants to send a threshold event.

Traceback looks like this:

Traceback (most recent call last):
File "/usr/lib/nav/thresholdMon.py", line 298, in
main(sys.argv)
File "/usr/lib/nav/thresholdMon.py", line 276, in main
'stillactive')
File "/usr/lib/nav/thresholdMon.py", line 102, in make_event
netboxid = rrd_file.netbox.id
File "/usr/lib/python2.7/dist-packages/django/db/models/fields/related.py", line 344, in get
other_field = self.field.rel.get_related_field()
File "/usr/lib/python2.7/dist-packages/django/db/models/fields/related.py", line 890, in get_related_field
data = self.to._meta.get_field_by_name(self.field_name)
AttributeError: 'str' object has no attribute '_meta'

Imported from Launchpad using lp2gh.

• date created: 2013-10-18T14:28:31Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1241630

While investigating a customer report of issues with service monitor alerts, it was discovered that the servicemon process on their installation was doing nothing. The customer had restarted the servicemon daemon, and it resumed its work in a normal fashion.

The logs (debug level) indicated that all the checkers were being instantiated on each cycle, but none were run. After the restart, logs showed normal behavior for a while, until a traceback was logged and servicemon resumed the errant behavior.

A code review reveals that a refactoring from 2011 introduced this bug. A line of code refers to a renamed variable by its old name, causing an AttributeError exception when recycling old worker threads.

This means the bug is triggered as each worker thread reaches its maximum number of jobs and is recycled. Once all the worker threads have triggered the exception, no more worker threads remain available, and the servicemon ceases entirely to monitor services.

The time it takes for this to happen is dependent on the number of configured worker threads in servicemon.conf (default: 20), and the value of the recycle interval option (default: 50), and, of course, how many service checkers that have been configured in SeedDB.

Once this message appears in servicemon.log, normal service checking ceases:

Exception in thread worker19:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/dist-packages/nav/statemon/RunQueue.py", line 61, in run
    self.execute()
  File "/usr/lib/python2.7/dist-packages/nav/statemon/RunQueue.py", line 78, in execute
    self._runqueue.unusedThreadName.append(self.getName())
AttributeError: '_RunQueue' object has no attribute 'unusedThreadName'

Imported from Launchpad using lp2gh.

• date created: 2015-11-26T08:38:05Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1520119

The database rule close_arp_prefices, which is meant to close open arp
records when prefices are delete from the database, erroneously sets a new
end time for all arp records coming from the given prefix, even those that
have already been closed.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1899431&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2008-02-22T17:07:00Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/258296

The fix for bug 1295092 causes ipdevpoll inventory jobs to crash fail in the psu plugin whenver a Cisco device is being queried.

The fix introduced changes to how the EntityTable class works. Unfortunately, it appears that the implementation for CISCO-ENTITY-FRU-MIB is misusing the EntityTable class to manipulate data from other tables than the ENTITY-MIB::entPhysicalTable. The EntityTable class should NOT be used at all here!

Imported from Launchpad using lp2gh.

• date created: 2014-03-31T09:34:49Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1300117

When adding or editing SeedDb prefix or vlan, most of the fields in the form are missing.

Imported from Launchpad using lp2gh.

• date created: 2014-04-02T08:53:39Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1301260

A similar problem to bug SF#1899431 exists in the cam table. A trigger
sets end_time to current_timestamp when netboxid is set to null. Netboxid
is typically set to null only through a cascading mechanism when a netbox
is deleted.

The problem here is also that the end_time is updated even for already
closed records. This bug has been present at least since 2002, and has
amazingly gone undisocovered until now.

Kudos to Gro-Anita Vindheim of NTNU, who reported both bugs.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1899476&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2008-02-22T18:22:00Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/258297

When an interface has been detained and that interface later is removed, the interface crashes because it tries to create links to ipdevinfo for a non existant netbox.

Imported from Launchpad using lp2gh.

• date created: 2013-08-12T12:13:32Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1211299

University College of Narvik reports that they are unable to receive SMS messages from NAV 3.5.0b3. The matching profile timeperiod has the same subscription for both an email address and a phone number, but only the email address receives the alert.

I configured alertengine to do DEBUG logging, and it claims to dispatch the alert to the SMS queue, but the smsq database table is constantly empty.

Attaching a log excerpt from alertengine.

Imported from Launchpad using lp2gh.

• date created: 2009-01-09T09:18:44Z
• owner: mbrekkevold
• assignee: adamcik
• the launchpad url was https://bugs.launchpad.net/bugs/315380

Adding a report to report.local.conf causes the report interface to crash when attempting to open that report. Adding the an identical report to report.conf does not cause a crash.

The traceback is as follows (tested on the current tip of the report branch):

MOD_PYTHON ERROR

ProcessId: 12506
Interpreter: 'navdev.uninett.no'

ServerName: 'navdev.uninett.no'
DocumentRoot: '/usr/local/nav/apache/webroot'

URI: '/report/duplexmismatch'
Location: None
Directory: '/usr/local/nav/apache/webroot/report/'
Filename: '/usr/local/nav/apache/webroot/report/duplexmismatch'
PathInfo: ''

Phase: 'PythonHandler'
Handler: 'nav.web.report.handler'

Traceback (most recent call last):

File "/usr/lib/python2.4/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch
default=default_handler, arg=req, silent=hlist.silent)

File "/usr/lib/python2.4/site-packages/mod_python/importer.py", line 1229, in _process_target
result = _execute_target(config, req, object, arg)

File "/usr/lib/python2.4/site-packages/mod_python/importer.py", line 1128, in _execute_target
result = object(arg)

File "/usr/local/nav/lib/python/nav/web/report/handler.py", line 278, in handler
req.write(page.respond())

File "/usr/local/nav/lib/python/nav/web/templates/MainTemplate.py", line 627, in respond
_v = VFFSL(SL,"content",False)() # '$content()' on line 219, col 1

File "/usr/local/nav/lib/python/nav/web/templates/ReportTemplate.py", line 285, in content
self.advSearch(trans=trans)

File "/usr/local/nav/lib/python/nav/web/templates/ReportTemplate.py", line 171, in advSearch
for a in VFFSL(SL,"report.form",True): # generated from line 114, col 1

NotFound: cannot find 'form' while searching for 'report.form'

Imported from Launchpad using lp2gh.

• date created: 2008-09-30T08:46:00Z
• owner: mbrekkevold
• assignee: jorabra
• the launchpad url was https://bugs.launchpad.net/bugs/276225

makecricketconfig apparently follows some Cisco logic and thinks most
Juniper interfaces are sub-interfaces, as they contain dots in their names
(e.g. ge-0/1/0.0). This leads makecricketconfig to configure Cricket to
use the "sub-interface" target type for these interfaces.

This means only traffic counters, and not error counters, are collected,
and only 32-bit counters are used, not 64-bit counters. This leads to
erroneous holes and spikes in traffic graphs when the counters start to
wrap rapidly.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1897681&group_id=107608&atid=648170]

Imported from Launchpad using lp2gh.

• date created: 2008-02-20T18:05:00Z
• owner: mbrekkevold
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/258295

On a link between two routers in the map, a click for the popup: interfaces are mixed.

example:
Link: oslo-gw -> trd-gw1
Interfaces: ge-0/1/0.0 -> ge-6/3/0.0
should be:
Interfaces: ge-6/3/0.0 -> ge-0/1/0.0

Imported from Launchpad using lp2gh.

• date created: 2008-10-18T08:09:07Z
• owner: faltin-uninett
• assignee: klette
• the launchpad url was https://bugs.launchpad.net/bugs/285360

We've seen one specific instance (so far) of getDeviceData crashing, seemingly due to ConcurrentModificationExceptions, followed by OutOfMemoryExceptions. A full traceback from getDeviceData-stderr.log is attached.

Apparently, some part of the ArpLogger plugin that was introduced in 3.4 does not use synchronized/thread-safe data structures.

Imported from Launchpad using lp2gh.

• date created: 2008-09-22T08:22:20Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/273030

Hi,

I was playing around with the login page on NAV, and found a XSS-hole in the 'origin' parameter. It looks like the system is doing some checking on the string, but it fails to prevent javascript injection.

https://nav.uio.no/index/login?origin=/%3CIMG%20%22%22%22%3E%3CSCRIPT%3Ealert(%22XSS%22)%3C/SCRIPT%3E%22%3E

(tested with Opera 9.64 and firefox 3.0.4)

Imported from Launchpad using lp2gh.

• date created: 2009-03-10T14:31:16Z
• owner: berulfsen
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/340516

There seems to be a problem with the stability of the getDeviceData and eventEngine daemons when there is a loss of database connectivity.

Although it is thought that NAV's Java Database library was designed to overcome temporary losses of connectivity, it seems that this is not the case.

Several installations report logs full of SQLExceptions with the following error message: "An I/O error occured while sending to the backend".

Imported from Launchpad using lp2gh.

• date created: 2008-10-08T12:33:56Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/280145

When an ifalias format is defined a template is loaded to inform the user of the format. This template fails to load, making the page inaccessble.

Imported from Launchpad using lp2gh.

• date created: 2014-01-03T10:05:18Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1265755

A typo in the nav.alertengine.dispatchers.sms_dispatcher module fills alertengine.log with AttributeErrors. See the attached log file excerpt.

Apparently, the exception causes the engine to think the sms dispatcher plugin failed, although it really was sucessful. Therefore, the engine keeps retrying to send the SMS.

Imported from Launchpad using lp2gh.

• date created: 2008-10-17T12:31:53Z
• owner: mbrekkevold
• assignee: adamcik
• the launchpad url was https://bugs.launchpad.net/bugs/284950

AlertEngine crashes immediately when started on a clean install of the series/3.5.x branch, due to an UnboundLocalError exception.

Looks like it has to do with the fact that there are no queued alerts in a freshly installed db. The log is attached.

This bug is blocking the release of NAV 3.5.0b2 and is therefore critical.

Imported from Launchpad using lp2gh.

• date created: 2008-10-31T15:33:44Z
• owner: mbrekkevold
• assignee: adamcik
• the launchpad url was https://bugs.launchpad.net/bugs/291631

collect_active_ip stores references to prefix ids in rrd_file. When a prefix has changed id, the reference is wrong and the script tries to create a new tuple for the rrdfile. This will trigger the unique constraint on rrd_file.filename and the script crashes.

1. Make the script do a rollback on such errors.
2. Use prefix.netaddr as reference to prefix in stead of prefix.id
3. Make sure the old references are removed.

Imported from Launchpad using lp2gh.

• date created: 2013-01-28T10:12:23Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1107723

There is a typo in cricket-config/switches/Defaults. This typo leads to no cpu collection for hp switches.

Details:

OID hpcpu1 3.6.1.4.1.11.2.14.11.5.1.9.6.1.0
should be:
OID hpcpu 1.3.6.1.4.1.11.2.14.11.5.1.9.6.1.0

Imported from Launchpad using lp2gh.

• date created: 2013-07-08T13:56:13Z
• owner: john-m-bredal
• assignee: john-m-bredal
• the launchpad url was https://bugs.launchpad.net/bugs/1198970

It appears the fix for bug 1403365 has caused a regression that stops the pping from being able to post events, essentially breaking one of the most important features of NAV.

Unfortunately, this made it into the 4.2.4 release, which we have now retracted.

These symptomatic errors can be seen in pping.log:

[2015-03-20 11:47:52] db.py:execute:167 [Critical] Throwing away update...
[2015-03-20 11:47:52] db.py:execute:165 [Critical] insert or update on table "eventqvar" violates foreign key constraint "eventqvar_eventqid_fkey"
DETAIL: Key (eventqid)=(1287006) is not present in table "eventq".

[2015-03-20 11:47:52] db.py:execute:167 [Critical] Throwing away update...
[2015-03-20 11:47:52] db.py:execute:165 [Critical] null value in column "subid" violates not-null constraint

Imported from Launchpad using lp2gh.

• date created: 2015-03-20T11:34:15Z
• owner: mbrekkevold
• assignee: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1434520