Juli 2009 - Nav-users - lister.unit.no

Email problems after upgrade
by Lars 18 Aug '09

18 Aug '09

Hi, NAV has been running on a Debian machine flawlessly for a while, but after I did a "aptitude update" and "aptitude upgrade" I ran into some problems. The updated NAV package warned me that I needed to edit in the db password manually, which I did. Firstly I had to point apache into the right directory to get the webpage to work again. It seems to work properly. It detects devices going up and down and updates statuses on the frontpage/status page and logs per device seem fine as well. So as far as I can tell the database is working as it should as well as all the background processes. Email alerts does not work though. Apparently the addresses are blacklisted according to the alertenginge.log, but I can't find any place where email addresses are blacklisted. New alert adresses also get blacklisted. From what I can see in our mailserver log, the mail alerts never get there, which is understandable since it looks like there is some setting in NAV somewhere that stop alerts from being sent. Here is an example from the log. [2009-07-27 00:48:19,368] [WARNING] [pid=5403 nav.alertengine.alertaddress.send] Not sending alert 4927 to xxxx(a)example.com as handler Email is blacklisted (Email address edited out) alertengine.err.log is empty. Email from Cron daemon works fine. I tried changing the mailserver in the alertengine.conf file, but that did not change anything. I am lost here. Anyone have any pointers? Lars Marius Schjærin Brednett AS

2 3

Login "unsupported hash type" error
by Pau 07 Aug '09

07 Aug '09

Hello, I just installed Nav 3.5.3 from source on a Debian 5 (Lenny), following the steps described in http://metanav.uninett.no/installing_from_source_on_debian. The problem is that when I try to log in I get the following error: 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 Any clues on this? Did I do something wrong? Let me know if you need more info. Thank You.

3 2

SQL-query takes looong time
by Ingeborg Hellemo 03 Jul '09

03 Jul '09

postgresql version 8.3.7 When we use "IP Device Info" and enter the name of a SRV the resulting page takes minutes to load. Thanks to the useful Debug:-line at the bottom of the page I know this is because of this query: SELECT "cam"."camid", "cam"."netboxid", "cam"."sysname", "cam"."ifindex", "cam"."module", "cam"."port", "cam"."start_time", "cam"."end_time", "cam"."misscnt", "cam"."mac" FROM "cam" WHERE "cam"."netboxid" = 566 ORDER BY "cam"."start_time" ASC LIMIT 1 Time: 174.495 The result of this query is 0 lines since this is a SRV and not a GW/GSW. If I drop the "ASC LIMIT 1" from the query I get the answer in no time. I hope somebody with more SQL-knowledge than me can come up with a fix, since this is quite annoying. --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no (Univ. of Tromsø, Norway)

2 2

cleanrrds.pl is not up to date
by Ingeborg Hellemo 03 Jul '09

03 Jul '09

NAV 3.5.4 $BINDIR/cleanrrds.pl is run nightly from crickets crontab. 1) This script has not been updated to use the new database: my $dbh = &NAV::connection('statTools', 'manage'); 2) This script also needs a version of find(1) that supports -printf. In FreeBSD we have to use gfind (no problem). gfind returns timestamps with a fractional part i.e. Thu May 28 12:38:06.0000000000 I suggest that line 117 in cleanrrds.pl is replaced with something like this: # Selects filepath,filename, time and size from the output. $line =~ m/(^\/.*)\/(.*\.rrd)\s(.*\d{2}:\d{2}:\d{2}(\.\d{10})?\s\d{4})\s(\d+)/; --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no (Univ. of Tromsø, Norway)

2 1