Nav-users

nav-users@lister.sikt.no

1372 discussions

new production install
by mels＠mels-kooijman.nl 05 Nov '07

05 Nov '07

mels wrote: > Begin with the lasr, install the patch. > That doesn't work, still the error page with status. When I comment out > the next two lines in > /usr/lib/python2.5/site-packages/mod_python/importer.py > # Check for an attempt by the module to import > # itself. > > => # if parent_info: > => # assert(file != parent_info.file), "Import cycle in %s." % file > > Status seems to be working. > > The toolbox/alert profiles page is complete empty, only a white page is > displaying. I see the problem in the apache log: PHP Fatal error: Call to undefined function pg_connect() I forget the php_pg, I think > > Anmd I use the source nav-3.3.0.tar.gz > > Mels > > > Morten Brekkevold wrote: >> On Thu, 01 Nov 2007 17:47:41 +0100 mels <mels(a)mels-kooijman.nl> wrote: >> >> >>> Nav is starting without errors, but in the toolbox Alert Profiles is >>> empty. >> What do you mean by empty? Is the descriptive text missing, or the >> icon? >> >>> And Status give the following error page: >>> MOD_PYTHON ERROR >> [snip] >>> AssertionError: Import cycle in >>> /usr/local/nav/apache/webroot/status/StatusPrefs.py. >>> Any idea what's wrong? >> Yes. The same problem was discussed on this list in May. See >> http://desperados.itea.ntnu.no/pipermail/nav-users/2007-May/001635.html . >> Basically this error comes up on newer versions of mod_python. >> >> Your options are: >> >> * Upgrade to NAV 3.3 (I don't think anyone has made an RPM of this >> version yet, though. Mr. Krapivin has been strangely silent) >> >> * Or apply this patch: >> http://desperados.itea.ntnu.no/pipermail/nav-users/2007-May/001639.html >> > > _______________________________________________ > nav-users mailing list > nav-users(a)itea.ntnu.no > http://mailman.itea.ntnu.no/mailman/listinfo/nav-users >

1 0

new production install
by mels＠mels-kooijman.nl 01 Nov '07

01 Nov '07

After installing nav in the test enviorment on opensuse 10.2, I installed nav on a new virtual production system with opensuse 10.3. BTW the python version is the same. Nav is starting without errors, but in the toolbox Alert Profiles is empty. And Status give the following error page: MOD_PYTHON ERROR ProcessId: 2483 Interpreter: 'nav.happyunix' ServerName: 'nav.happyunix' DocumentRoot: '/usr/local/nav/apache/webroot' URI: '/status/' Location: None Directory: '/usr/local/nav/apache/webroot/status/' Filename: '/usr/local/nav/apache/webroot/status/' PathInfo: '' Phase: 'PythonHandler' Handler: 'status' 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/local/nav/apache/webroot/status/status.py", line 71, in handler output = indexInternal(req) File "/usr/local/nav/apache/webroot/status/status.py", line 107, in indexInternal prefs = HandleStatusPrefs.loadPrefs(req) File "/usr/local/nav/apache/webroot/status/StatusPrefs.py", line 340, in loadPrefs prefs = cPickle.loads(data) File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 991, in load_module return _global_modules_cache.import_module(self.__file) File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 488, in import_module assert(file != parent_info.file), "Import cycle in %s." % file AssertionError: Import cycle in /usr/local/nav/apache/webroot/status/StatusPrefs.py. MODULE CACHE DETAILS Accessed: Thu Nov 1 16:27:23 2007 Generation: 7 _mp_136225482982648bcdfdd40e74885289 { FileName: '/usr/local/nav/apache/webroot/status/StatusDefaultPrefs.py' Instance: 1 [IMPORT] Generation: 8 Modified: Tue May 1 22:46:42 2007 Imported: Thu Nov 1 16:27:23 2007 } _mp_37bf19280ab45e11f34ffeed40ee4974 { FileName: '/usr/local/nav/apache/webroot/status/StatusPrefs.py' Instance: 1 [IMPORT] Generation: 10 Modified: Tue May 1 22:46:42 2007 Imported: Thu Nov 1 16:27:23 2007 Children: '/usr/local/nav/apache/webroot/status/StatusDefaultPrefs.py', '/usr/local/nav/apache/webroot/status/StatusSections.py' } _mp_444e13f7996d2281eb7234ce037aea9a { FileName: '/usr/local/nav/apache/webroot/status/StatusSections.py' Instance: 1 [IMPORT] Generation: 9 Modified: Tue May 1 22:46:42 2007 Imported: Thu Nov 1 16:27:23 2007 } _mp_6cd588e65f9c575e8e4b02d3d41602d5 { FileName: '/usr/local/nav/apache/webroot/status/status.py' Instance: 1 [IMPORT] Generation: 11 Modified: Tue May 1 22:46:42 2007 Imported: Thu Nov 1 16:27:23 2007 Children: '/usr/local/nav/apache/webroot/status/StatusPrefs.py', '/usr/local/nav/apache/webroot/status/StatusSections.py' } Any idea what's wrong? The installation is done with the package files from: http://ans.hsh.no/home/roger/nav3/ Mels >From mels at mels-kooijman.nl Thu Nov 1 20:16:09 2007 From: mels at mels-kooijman.nl (mels) Date: Thu Nov 1 20:20:00 2007 Subject: [Nav-users] arplogger.pl In-Reply-To: <472A032D.4040805(a)mels-kooijman.nl> References: <200710311344.l9VDiXYI010616(a)barnetv.cc.uit.no> <472A032D.4040805(a)mels-kooijman.nl> Message-ID: <472A25F9.6070309(a)mels-kooijman.nl> I get in the root mail the next message: Subject: Cron <navcron@nav> $BINDIR/arplogger.pl X-Cron-Env: <PERL5LIB=/usr/lib/perl5/vendor_perl/5.8.8/i586-linux-thread-multi/DBD> X-Cron-Env: <PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/java/jdk1.5.0_12/jre/bin> X-Cron-Env: <BINDIR=/usr/local/nav/bin> X-Cron-Env: <LOCALSTATEDIR=/usr/local/nav/var> X-Cron-Env: <MAILTO=root@localhost> X-Cron-Env: <CRICKETDIR=/usr/local/nav/cricket> X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/usr/local/nav> X-Cron-Env: <LOGNAME=navcron> X-Cron-Env: <USER=navcron> Message-Id: <20071101173003.23A6219140(a)nav.happyunix.mks> Date: Thu, 1 Nov 2007 18:30:03 +0100 (CET) Status: RO Undefined subroutine &Pg::connectdb called at /usr/lib/perl5/site_perl/5.8.8/NAV.pm line 78. The perl modules Pg and DBD::Pg are installed cpan> install Pg Pg is up to date. cpan> install DBD::Pg DBD::Pg is up to date. Any idea? Mels >From mels at mels-kooijman.nl Thu Nov 1 20:33:21 2007 From: mels at mels-kooijman.nl (mels) Date: Thu Nov 1 20:33:35 2007 Subject: [Nav-users] error on toolbix/Status In-Reply-To: <472A032D.4040805(a)mels-kooijman.nl> References: <200710311344.l9VDiXYI010616(a)barnetv.cc.uit.no> <472A032D.4040805(a)mels-kooijman.nl> Message-ID: <472A2A01.7020703(a)mels-kooijman.nl> After installing nav in the test enviorment on opensuse 10.2, I installed nav on a new virtual production system with opensuse 10.3. BTW the python version is the same. Nav is starting without errors, but in the toolbox Alert Profiles is empty. And Status give the following error page: MOD_PYTHON ERROR ProcessId: 2483 Interpreter: 'nav.happyunix' ServerName: 'nav.happyunix' DocumentRoot: '/usr/local/nav/apache/webroot' URI: '/status/' Location: None Directory: '/usr/local/nav/apache/webroot/status/' Filename: '/usr/local/nav/apache/webroot/status/' PathInfo: '' Phase: 'PythonHandler' Handler: 'status' 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/local/nav/apache/webroot/status/status.py", line 71, in handler output = indexInternal(req) File "/usr/local/nav/apache/webroot/status/status.py", line 107, in indexInternal prefs = HandleStatusPrefs.loadPrefs(req) File "/usr/local/nav/apache/webroot/status/StatusPrefs.py", line 340, in loadPrefs prefs = cPickle.loads(data) File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 991, in load_module return _global_modules_cache.import_module(self.__file) File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 488, in import_module assert(file != parent_info.file), "Import cycle in %s." % file AssertionError: Import cycle in /usr/local/nav/apache/webroot/status/StatusPrefs.py. MODULE CACHE DETAILS Accessed: Thu Nov 1 16:27:23 2007 Generation: 7 _mp_136225482982648bcdfdd40e74885289 { FileName: '/usr/local/nav/apache/webroot/status/StatusDefaultPrefs.py' Instance: 1 [IMPORT] Generation: 8 Modified: Tue May 1 22:46:42 2007 Imported: Thu Nov 1 16:27:23 2007 } _mp_37bf19280ab45e11f34ffeed40ee4974 { FileName: '/usr/local/nav/apache/webroot/status/StatusPrefs.py' Instance: 1 [IMPORT] Generation: 10 Modified: Tue May 1 22:46:42 2007 Imported: Thu Nov 1 16:27:23 2007 Children: '/usr/local/nav/apache/webroot/status/StatusDefaultPrefs.py', '/usr/local/nav/apache/webroot/status/StatusSections.py' } _mp_444e13f7996d2281eb7234ce037aea9a { FileName: '/usr/local/nav/apache/webroot/status/StatusSections.py' Instance: 1 [IMPORT] Generation: 9 Modified: Tue May 1 22:46:42 2007 Imported: Thu Nov 1 16:27:23 2007 } _mp_6cd588e65f9c575e8e4b02d3d41602d5 { FileName: '/usr/local/nav/apache/webroot/status/status.py' Instance: 1 [IMPORT] Generation: 11 Modified: Tue May 1 22:46:42 2007 Imported: Thu Nov 1 16:27:23 2007 Children: '/usr/local/nav/apache/webroot/status/StatusPrefs.py', '/usr/local/nav/apache/webroot/status/StatusSections.py' } Any idea what's wrong? The installation is done with the package files from: http://ans.hsh.no/home/roger/nav3/ Mels >From morten.brekkevold at uninett.no Mon Nov 5 09:37:17 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Mon Nov 5 09:37:21 2007 Subject: [Nav-users] new production install In-Reply-To: <472A032D.4040805(a)mels-kooijman.nl> (mels(a)mels-kooijman.nl's message of "Thu, 01 Nov 2007 17:47:41 +0100") References: <200710311344.l9VDiXYI010616(a)barnetv.cc.uit.no> <472A032D.4040805(a)mels-kooijman.nl> Message-ID: <yylprypdr5u.fsf(a)voldsminde.uninett.no> On Thu, 01 Nov 2007 17:47:41 +0100 mels <mels(a)mels-kooijman.nl> wrote: > Nav is starting without errors, but in the toolbox Alert Profiles is > empty. What do you mean by empty? Is the descriptive text missing, or the icon? > And Status give the following error page: > MOD_PYTHON ERROR [snip] > AssertionError: Import cycle in > /usr/local/nav/apache/webroot/status/StatusPrefs.py. > Any idea what's wrong? Yes. The same problem was discussed on this list in May. See http://desperados.itea.ntnu.no/pipermail/nav-users/2007-May/001635.html . Basically this error comes up on newer versions of mod_python. Your options are: * Upgrade to NAV 3.3 (I don't think anyone has made an RPM of this version yet, though. Mr. Krapivin has been strangely silent) * Or apply this patch: http://desperados.itea.ntnu.no/pipermail/nav-users/2007-May/001639.html -- mvh Morten Brekkevold UNINETT >From mels at mels-kooijman.nl Mon Nov 5 17:47:36 2007 From: mels at mels-kooijman.nl (mels) Date: Mon Nov 5 17:47:48 2007 Subject: [Nav-users] new production install In-Reply-To: <yylprypdr5u.fsf(a)voldsminde.uninett.no> References: <200710311344.l9VDiXYI010616(a)barnetv.cc.uit.no> <472A032D.4040805(a)mels-kooijman.nl> <yylprypdr5u.fsf(a)voldsminde.uninett.no> Message-ID: <472F4928.2040002(a)mels-kooijman.nl> Begin with the lasr, install the patch. That doesn't work, still the error page with status. When I comment out the next two lines in /usr/lib/python2.5/site-packages/mod_python/importer.py # Check for an attempt by the module to import # itself. => # if parent_info: => # assert(file != parent_info.file), "Import cycle in %s." % file Status seems to be working. The toolbox/alert profiles page is complete empty, only a white page is displaying. Anmd I use the source nav-3.3.0.tar.gz Mels Morten Brekkevold wrote: > On Thu, 01 Nov 2007 17:47:41 +0100 mels <mels(a)mels-kooijman.nl> wrote: > > >> Nav is starting without errors, but in the toolbox Alert Profiles is >> empty. > > What do you mean by empty? Is the descriptive text missing, or the > icon? > >> And Status give the following error page: >> MOD_PYTHON ERROR > [snip] >> AssertionError: Import cycle in >> /usr/local/nav/apache/webroot/status/StatusPrefs.py. > >> Any idea what's wrong? > > Yes. The same problem was discussed on this list in May. See > http://desperados.itea.ntnu.no/pipermail/nav-users/2007-May/001635.html . > Basically this error comes up on newer versions of mod_python. > > Your options are: > > * Upgrade to NAV 3.3 (I don't think anyone has made an RPM of this > version yet, though. Mr. Krapivin has been strangely silent) > > * Or apply this patch: > http://desperados.itea.ntnu.no/pipermail/nav-users/2007-May/001639.html >

1 0

deb woes
by prieheck＠iwu.edu 31 Okt '07

31 Okt '07

On Wed, 2007-10-31 at 17:42 +0100, Morten Werner Forsbring wrote: > Pat Riehecky <prieheck(a)iwu.edu> writes: > > > I have setup the mirror in the documentation to get the 3.3 nav package, > > but luck is not on my side. > > > > Setting up nav (2+3.3.0-2) ... > > dpkg: error processing nav (--configure): > > subprocess post-installation script returned error exit status 1 > > Errors were encountered while processing: > > nav > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > > > any ideas? > > This was my fault with a typo in one of the maintainer scripts. Please > try again now with 2+3.3.0-4. > > > - Werner > Hurray!!! It dumped a few warnings, but nothing halted its progress. I have attached them if you care, if not it is on 12k of wasted space on the internets. Pat

1 0

Home > IP Device Center > Services - "We're terribly sorry"
by morten.brekkevold＠uninett.no 31 Okt '07

31 Okt '07

Ingeborg Hellemo <Ingeborg.Hellemo(a)cc.uit.no> writes: > morten.brekkevold(a)uninett.no said: >> Ingeborg, if you can, please try the attached patch for this problem (I have >> no Postgres 8.2 to test on). > > Nope. We are still sorry. This time because of one escape too many. [snip] > WHERE key='serviceid' and value IN (''1','6','2','8','4','5','3'') That doesn't make sense. I took a look at servicetable.py on po, and it doesn't match servicetable.py from the current trunk or NAV 3.3. A few lines below the patched line, it contains the following: WHERE key='serviceid' and value IN (\'%s\')""" % serviceIDs This extra quote must have been added by you or someone else; it breaks both my patch and the original functionality. -- mvh Morten Brekkevold UNINETT >From prieheck at iwu.edu Tue Oct 30 10:20:17 2007 From: prieheck at iwu.edu (Pat Riehecky) Date: Tue Oct 30 16:20:15 2007 Subject: [Nav-users] deb woes Message-ID: <1193757617.6102.20.camel(a)thales.iwu.edu> I have setup the mirror in the documentation to get the 3.3 nav package, but luck is not on my side. Setting up nav (2+3.3.0-2) ... dpkg: error processing nav (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: nav E: Sub-process /usr/bin/dpkg returned an error code (1) any ideas?

2 2

AlertEngine - delayed alerts, something is not right
by Ingeborg.Hellemo＠cc.uit.no 31 Okt '07

31 Okt '07

(My mission this week is to keep you occupied with new bugs) I have made a nightly profile which is supposed to send alerts immediately via email and delayed (Daily queue) to my phone. Something is happening with queuing/deleting alerts which makes me receive two emails and I am not sure if I would have received any sms in the morning. (Today I wasn't supposed to because all downs were canceled by ups). >From alertengine.log: Wed Oct 31 04:08:57 2007 alertEngine NewAlerts-7-collectInfo: found 1 new alerts Wed Oct 31 04:08:57 2007 alertEngine QueuedAlerts-7-collectInfo: collecting info about queued alerts Wed Oct 31 04:08:57 2007 alertEngine User-7-checkAlertQueue: borge(1000); Checking queued alerts for user Wed Oct 31 04:08:57 2007 alertEngine User-7-checkNewAlerts: borge(1000); Processing new alerts for user Wed Oct 31 04:08:57 2007 alertEngine User-7-checkRights: borge(1000); Checking rights for user Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkAlert: checking to see if alertid 4819 is in equipmentgroup 71 Wed Oct 31 04:08:57 2007 alertEngine Alert-7-getInfo: collecting info from table alertq column severity Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkMatch: datatype=1 type=4 value=100 info=50 ret=1 Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkAlert: Alertid 4819 is in equipmentgroup 71 Wed Oct 31 04:08:57 2007 alertEngine User-7-checkActiveProfile: borge(1000); Checking active profile for user Wed Oct 31 04:08:57 2007 alertEngine User-7-collectTimePeriod: borge(1000); No time period available Wed Oct 31 04:08:57 2007 alertEngine User-7-checkAlertQueue: ingeborg(1001); Checking queued alerts for user Wed Oct 31 04:08:57 2007 alertEngine User-7-checkNewAlerts: ingeborg(1001); Processing new alerts for user Wed Oct 31 04:08:57 2007 alertEngine User-7-checkRights: ingeborg(1001); Checking rights for user Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkAlert: checking to see if alertid 4819 is in equipmentgroup 71 Wed Oct 31 04:08:57 2007 alertEngine Alert-7-getInfo: collecting info from table alertq column severity Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkMatch: datatype=1 type=4 value=100 info=50 ret=1 Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkAlert: Alertid 4819 is in equipmentgroup 71 Wed Oct 31 04:08:57 2007 alertEngine User-7-checkActiveProfile: ingeborg(1001); Checking active profile for user Wed Oct 31 04:08:57 2007 alertEngine User-7-collectTimePeriod: ingeborg(1001); Collected 2 alarm addresses Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkAlert: checking to see if alertid 4819 is in equipmentgroup 69 Wed Oct 31 04:08:57 2007 alertEngine Alert-7-getInfo: collecting info from table cat column catid Wed Oct 31 04:08:57 2007 alertEngine Alert-7-collecttable: collecting info from table: select c.* from cat c, netbox n where n.netboxid=136 and n.catid=c.catid Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkMatch: datatype=0 type=0 value=SRV info=SRV ret=1 Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkAlert: Alertid 4819 is in equipmentgroup 69 Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkAlert: checking to see if alertid 4819 is in equipmentgroup 69 Wed Oct 31 04:08:57 2007 alertEngine Alert-7-getInfo: collecting info from table cat column catid Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkMatch: datatype=0 type=0 value=SRV info=SRV ret=1 Wed Oct 31 04:08:57 2007 alertEngine EquipmentGroups-7-checkAlert: Alertid 4819 is in equipmentgroup 69 Wed Oct 31 04:08:57 2007 alertEngine User-6-sendEmail: ingeborg(1001); EMAIL ingeborg.hellemo(a)cc.uit.no Subject: Service http is down on adbweb.uit.no Wed Oct 31 04:09:08 2007 alertEngine User-6-queueAlert: ingeborg(1001); Queued alert 4819 to address 1005 Wed Oct 31 04:10:08 2007 alertEngine NewAlerts-7-collectInfo: found 0 new alerts Wed Oct 31 04:10:08 2007 alertEngine QueuedAlerts-7-collectInfo: collecting info about queued alerts Wed Oct 31 04:10:08 2007 alertEngine User-7-checkAlertQueue: borge(1000); Checking queued alerts for user Wed Oct 31 04:10:08 2007 alertEngine User-7-checkAlertQueue: ingeborg(1001); Checking queued alerts for user Wed Oct 31 04:10:08 2007 alertEngine User-7-checkAlertQueue: ingeborg(1001); Checking queued alert 0 Wed Oct 31 04:10:08 2007 alertEngine User-7-checkActiveProfile: ingeborg(1001); Checking active profile for user Wed Oct 31 04:10:08 2007 alertEngine User-7-collectTimePeriod: ingeborg(1001); Collected 2 alarm addresses Wed Oct 31 04:10:08 2007 alertEngine EquipmentGroups-7-checkAlert: checking to see if alertid 4819 is in equipmentgroup 69 Wed Oct 31 04:10:08 2007 alertEngine Alert-7-getInfo: collecting info from table cat column catid Wed Oct 31 04:10:08 2007 alertEngine Alert-7-collecttable: collecting info from table: select c.* from cat c, netbox n where n.netboxid=136 and n.catid=c.catid Wed Oct 31 04:10:08 2007 alertEngine EquipmentGroups-7-checkMatch: datatype=0 type=0 value=SRV info=SRV ret=1 Wed Oct 31 04:10:08 2007 alertEngine EquipmentGroups-7-checkAlert: Alertid 4819 is in equipmentgroup 69 Wed Oct 31 04:10:08 2007 alertEngine EquipmentGroups-7-checkAlert: checking to see if alertid 4819 is in equipmentgroup 69 Wed Oct 31 04:10:08 2007 alertEngine Alert-7-getInfo: collecting info from table cat column catid Wed Oct 31 04:10:08 2007 alertEngine EquipmentGroups-7-checkMatch: datatype=0 type=0 value=SRV info=SRV ret=1 Wed Oct 31 04:10:08 2007 alertEngine EquipmentGroups-7-checkAlert: Alertid 4819 is in equipmentgroup 69 Wed Oct 31 04:10:08 2007 alertEngine User-6-sendEmail: ingeborg(1001); EMAIL ingeborg.hellemo(a)cc.uit.no Subject: Service http is down on adbweb.uit.no Wed Oct 31 04:10:10 2007 alertEngine QueuedAlerts-7-deleteAlert: deleting queued alert 0 Wed Oct 31 04:10:10 2007 alertEngine Alert-7-delete: deleted alertqid=4819 --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg(a)cc.uit.no (Univ. of Troms?, Norway)

1 0

Home > IP Device Center > Services - "We're terribly sorry"
by morten.brekkevold＠uninett.no 30 Okt '07

30 Okt '07

Ingeborg Hellemo <Ingeborg.Hellemo(a)cc.uit.no> writes: > https://<nav-host>/browse/service/ looks like this: > > All services > dns (3) > ftp (1) > http (15) > https (4) > ... > > > If i click one of the services with a count larger than 1 i get [...] > ProgrammingError: ERROR: IN types character varying and integer cannot be > matched [...] > Please fix. This appears to related to the same problem reported in this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1792351&group_id=1… I.e. stricter type checking in PostgreSQL 8.2. I don't know whether there might be an option in postgresql.conf which allows you to reduce the strictness as a workaround, though. I've posted the bug here: http://sourceforge.net/tracker/index.php?func=detail&aid=1822760&group_id=1… -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Tue Oct 30 14:42:23 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Tue Oct 30 14:42:28 2007 Subject: [Nav-users] Home > IP Device Center > Services - "We're terribly sorry" In-Reply-To: <yyl7il4vj1x.fsf(a)voldsminde.uninett.no> (Morten Brekkevold's message of "Tue, 30 Oct 2007 14:16:58 +0100") References: <200710291222.l9TCM0oV047496(a)barnetv.cc.uit.no> <yyl7il4vj1x.fsf(a)voldsminde.uninett.no> Message-ID: <yyl1wbcvhvk.fsf(a)voldsminde.uninett.no> Morten Brekkevold <morten.brekkevold(a)uninett.no> writes: > I.e. stricter type checking in PostgreSQL 8.2. I don't know whether > there might be an option in postgresql.conf which allows you to reduce > the strictness as a workaround, though. > > I've posted the bug here: > http://sourceforge.net/tracker/index.php?func=detail&aid=1822760&group_id=1… Ingeborg, if you can, please try the attached patch for this problem (I have no Postgres 8.2 to test on). -- mvh Morten Brekkevold UNINETT

1 0

PHP-errors from AlertProfiles
by Ingeborg.Hellemo＠cc.uit.no 30 Okt '07

30 Okt '07

morten.brekkevold(a)uninett.no said: > I think he based this on the fact that whatever error messages Alert Profiles > spat at us under PHP5, anything we did in the Alert Profiles interface would > still work as before. > Are your changes saved properly, despite the errors? Yes, I later found out that everything works, you just have to ignore the large yellow warning signs. --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg(a)cc.uit.no (Univ. of Troms?, Norway)

2 1

smsd is throwing exceptions at me
by Ingeborg.Hellemo＠cc.uit.no 30 Okt '07

30 Okt '07

morten.brekkevold(a)uninett.no said: > 1. Set loglevel: DEBUG >From etc/smsd.conf # Logging settings # Valid options are DEBUG, INFO, WARNING, ERROR, CRITICAL loglevel: DEBUG morten.brekkevold(a)uninett.no said: > 2. Restarted smsd? /#/usr/local/nav/bin/nav start smsd Starting: smsd morten.brekkevold(a)uninett.no said: > 3. Watched smsd.log until a message has been attempted dispatched? /#tail smsd.log [2007-10-30 12:09:27,590] [DEBUG] [pid=2062 nav.smsd] Starting loop. [2007-10-30 12:09:27,633] [INFO] [pid=2062 nav.smsd] Found 1 user(s) with unsent messages. [2007-10-30 12:09:27,636] [INFO] [pid=2062 nav.smsd] Found 12 unsent message(s) for 98668305. [2007-10-30 12:09:27,636] [CRITICAL] [pid=2062 nav.smsd] Sending failed permanently. Exiting. (No dispatchers available. None configured or all dispatchers failed permanently. After this smsd dies. Before i changed smsd.conf the [DEBUG]-line was missing. But nothing from dispatcher.py or gammudispatcher.py --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg(a)cc.uit.no (Univ. of Tromsø, Norway)

1 0

snmptrapd with ImportError
by morten.brekkevold＠uninett.no 30 Okt '07

30 Okt '07

Ingeborg Hellemo <Ingeborg.Hellemo(a)cc.uit.no> writes: > The module is where it is supposed to be, > PYTHONPATH=/usr/local/nav/lib/python. Other python-parts of NAV is > working as expected (or at least not complaining about missing > modules...). > > Morten, you have a user on po.uit.no. Feel free to poke around. Thanks, I had a poke, and now I know what the problem is. Your immediate fix is to do the following as root: touch /usr/local/nav/lib/python/nav/snmptrapd/__init__.py which will make Python actually recognize nav.snmptrapd as a proper Python package. The reason I was unable to reproduce the problem on my end was that I assumed this occurred when you started the daemon, but it seems it actually occurs every time a trap is received (and I had nothing configured to send traps to my daemon). The problem being that snmptrapd imports the handler modules every time it receives a trap, and not just once at the start of the process (which I think it should). I've filed this as two separate bugs in the tracker: 1. http://sourceforge.net/tracker/index.php?func=detail&aid=1822650&group_id=1… 2. http://sourceforge.net/tracker/index.php?func=detail&aid=1822651&group_id=1… -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Tue Oct 30 11:07:04 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Tue Oct 30 11:07:07 2007 Subject: [Nav-users] Nagios+lampp In-Reply-To: <Pine.LNX.4.64.0710261910340.3828(a)tyholt.uninett.no> (Vidar Faltinsen's message of "Fri, 26 Oct 2007 19:11:39 +0200 (CEST)") References: <20071026092109.wzj2jfan2c08084s(a)charlie.vbnet.com.br> <Pine.LNX.4.64.0710261910340.3828(a)tyholt.uninett.no> Message-ID: <yylabq0x6ev.fsf(a)voldsminde.uninett.no> Vidar Faltinsen <vidar.faltinsen(a)uninett.no> writes: > On Fri, 26 Oct 2007, marcos.sandrini(a)embryo.com.br wrote: > >> Bom dia! > > Bom dia, to you, too! Hi Marcos, I think what Vidar is trying to say, is that nobody on this list can read Portugese, so if you really want an answer, you should try again in English :-) -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Tue Oct 30 11:13:59 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Tue Oct 30 11:14:01 2007 Subject: [Nav-users] PHP-errors from AlertProfiles In-Reply-To: <200710260823.l9Q8N64N014697(a)barnetv.cc.uit.no> (Ingeborg Hellemo's message of "Fri, 26 Oct 2007 10:23:06 +0200") References: <200710260823.l9Q8N64N014697(a)barnetv.cc.uit.no> Message-ID: <yyl3avsx63c.fsf(a)voldsminde.uninett.no> Ingeborg Hellemo <Ingeborg.Hellemo(a)cc.uit.no> writes: > NAV 3.3.0 and php5 > > > If I try to add a new profile I get: > > AlertProfiles PHP Errorhandler [snip] > Any ideas? I had a chat with Arne, one of the original developers of the alert system (since I haven't touched PHP in many years now), as we tried to upgrade to PHP5. He suggested that these errors had been present all along, but that previous php versions suppressed them by default. I think he based this on the fact that whatever error messages Alert Profiles spat at us under PHP5, anything we did in the Alert Profiles interface would still work as before. Are your changes saved properly, despite the errors? -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Tue Oct 30 11:35:18 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Tue Oct 30 11:35:43 2007 Subject: [Nav-users] smsd is throwing exceptions at me In-Reply-To: <200710300901.l9U91Pvl076327(a)barnetv.cc.uit.no> (Ingeborg Hellemo's message of "Tue, 30 Oct 2007 10:01:25 +0100") References: <200710300901.l9U91Pvl076327(a)barnetv.cc.uit.no> Message-ID: <yylve8ovqjd.fsf(a)voldsminde.uninett.no> Ingeborg Hellemo <Ingeborg.Hellemo(a)cc.uit.no> writes: > Ingeborg.Hellemo(a)cc.uit.no said: >> How can I turn on more debugging? > > I have put > loglevel: DEBUG > into etc/smsd.conf, but this only makes a difference in logging from > /usr/local/nav/bin/smsd.py. I still don't see any log messages from > dispatcher.py You have of course: 1. Set loglevel: DEBUG 2. Restarted smsd? 3. Watched smsd.log until a message has been attempted dispatched? I do get log messages from nav.smsd.dispatcher here when debug logging is turned on. -- mvh Morten Brekkevold UNINETT >From Ingeborg.Hellemo at cc.uit.no Tue Oct 30 12:01:08 2007 From: Ingeborg.Hellemo at cc.uit.no (Ingeborg Hellemo) Date: Tue Oct 30 12:01:14 2007 Subject: [Nav-users] snmptrapd with ImportError In-Reply-To: Your message of "Tue, 30 Oct 2007 11:03:16 +0100." <yylfxzsx6l7.fsf(a)voldsminde.uninett.no> Message-ID: <200710301101.l9UB18tK078731(a)barnetv.cc.uit.no> morten.brekkevold(a)uninett.no said: > Your immediate fix is to do the following as root: > touch /usr/local/nav/lib/python/nav/snmptrapd/__init__.py > which will make Python actually recognize nav.snmptrapd as a proper Python > package. Cool! Then we immediately move on to new interesting errors. Now we have a "TypeError": [2007-10-30 11:54:14,375] [DEBUG] [pid=1422 nav.snmptrapd.linkupdown] Module linkupdown got trap .1.3.6.1.6.3.1.1.5.3 LINKDOWN [2007-10-30 11:54:14,376] [DEBUG] [pid=1422 nav.snmptrapd.linkupdown] SELECT netboxid, vendorid FROM netbox LEFT JOIN type USING (typeid) WHERE ip = %s [2007-10-30 11:54:14,377] [DEBUG] [pid=1422 nav.snmptrapd.linkupdown] SELECT swportid, module.deviceid, module.module, swport.interface FROM netbox LEFT JOIN module USING (netboxid) LEFT JOIN swport USING (moduleid) WHERE ip=%s AND ifindex = %s [2007-10-30 11:54:14,379] [ERROR] [pid=1422 nav.snmptrapd] Error when handling trap with nav.snmptrapd.handlers.linkupdown: unsubscriptable object Traceback (most recent call last): File "/usr/local/nav/bin/snmptrapd.py", line 300, in trapHandler accepted = mod.handleTrap(trap, config=config) File "/usr/local/nav/lib/python/nav/snmptrapd/handlers/linkupdown.py", line 110, in handleTrap subid = idres['swportid'] TypeError: unsubscriptable object

1 0

Ranked Statistics: 12334963.32 percent
by Ingeborg.Hellemo＠cc.uit.no 30 Okt '07

30 Okt '07

12334963.32 percent is a nice number if you talk about increase in wages, but not if you talk about mortgage rates or CPU load. Something is wrong with our "Ranked Statistics". Top 20 CPU Routers show 6 boxes with impossible values, but if i click on the "Target"-link, the graph shows normal values (but not high enough to put it into Top 20). The rest of the boxes show normal values. The other views shows just as erroneous behaviour. Is this a result of us using RRDtool version 1.2.23? --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg(a)cc.uit.no (Univ. of Troms?, Norway)

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