Nav-users

nav-users@lister.sikt.no

1376 discussions

Status page fails after bulk import
by Rikard Stemland Skjelsvik 09 Okt '08

09 Okt '08

After bulk importing 100 GSW devices with the same amount of locations ,also bulk imported, the status page failes. All other tools seems to be working. The error is: Mod_python error: "PythonHandler status" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/var/www/nav/status/status.py", line 71, in handler output = indexInternal(req) File "/var/www/nav/status/status.py", line 108, in indexInternal statusPage = StatusPage(req,prefs) File "/var/www/nav/status/status.py", line 130, in __init__ for section in prefs.sections: TypeError: iteration over non-sequence I tried a reboot of the server, but to no advantage -- Rikard

2 2

Possible bug in Syslog Analyzer
by Rikard Stemland Skjelsvik 08 Okt '08

08 Okt '08

After installing a clean Nav on Debian with the Debian packages, i have discoverd that the table with origins only display ip-adresses and not the hostname. This is purly cosmetic, but NAV both IP Info Center and IP Device Info (beta) recoqnizes both the ip-adress and the hostname. I even tried to add an entry in the /etc/hostfile and that did not help. -- Rikard

2 3

Announcement: NAV 3.4.3 released
by Morten Brekkevold 08 Okt '08

08 Okt '08

NAV 3.4.3 is now available for download at Launchpad: https://launchpad.net/nav/3.4/3.4.3 This is a bugfix release, the changelog is attached to this message. Binary packages for Debian will be available soon. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. For those upgrading their existing NAV installation, please see the added section about upgrading to 3.4.3 in the attached release notes. The SQL upgrade script provided with 3.4.2 contained a bug which prevented the SQL changes from taking place, and the updated upgrade script must be run. Happy NAVing everyone! -- mvh Morten Brekkevold UNINETT

4 6

Issues with servicemon
by Stokkenes Vidar 08 Okt '08

08 Okt '08

Hello, Ever since I migrated to a seperate PostgreSQL server, I've had various issues with dying NAV processes/daemons. The most common one is this error, appearing in servicemon.log after enabling DEBUG in the nav.conf file: FROM serviceproperty order BY serviceid [2008-10-08 12:38:58] servicemon.py:__init__:61 [Notice] Setting checkinterval=60 [2008-10-08 12:38:58] servicemon.py:__init__:63 [Notice] Reading database config [2008-10-08 12:38:58] servicemon.py:__init__:64 [Notice] Setting up runqueue [2008-10-08 12:38:58] RunQueue.py:__init__:98 [Notice] Setting maxthreads=20 [2008-10-08 12:38:58] RunQueue.py:__init__:100 [Notice] Setting maxRunCount=50 [2008-10-08 12:38:58] db.py:cursor:85 [Critical] Could not get cursor. Trying to reconnect... [2008-10-08 12:38:58] db.py:connect:72 [Notice] Successfully (re)connected to NAVdb [2008-10-08 12:38:58] db.py:query:108 [Debug] Executing: SELECT serviceid, property, value FROM serviceproperty order BY serviced I even had the servicemon developer over at my office, and he couldn't really tell why I was getting this error as he was able to grab the cursor when issuing it from a python shell. I've made some postgres.conf tweaks to allow harder work, as I have a quite big NAV database. Here are the changes I've made: <snip> work_mem = 98088 maintenance_work_mem = 131072 shared_buffers = 20000 vacuum_cost_delay = 50 checkpoint_segments = 20 checkpoint_timeout = 900 stats_start_collector = on stats_row_level = on max_fsm_pages = 500000 max_fsm_relations = 2000 wal_buffers = 512 max_locks_per_transaction = 512 </snip> Even though I've made these changes, I still seem to get: LOG: unexpected EOF on client connection LOG: unexpected EOF on client connection LOG: unexpected EOF on client connection .. in my postgresql server logs... The PostgreSQL server itself is a Quad core CPU box with 8GB of ram, and should not be overloaded in any way. Load is ~0.10 at all times. Any ideas why my PostgreSQL server keeps rejecting cursors and giving me these EOF errors? Any help appreicated ------------------------------------------------------ Vidar Stokkenes Konsulent Nettverk Seksjon for nettverk og telekom HN IKT - Tromsø Tlf: 76 16 61 87 / 77 66 99 55 Mobil: 95 87 99 42 e-post: vidar.stokkenes(a)hn-ikt.no<mailto:vidar.stokkenes@hn-ikt.no> [cid:image001.png@01C92945.5BD3A8D0]

1 0

Anna Liu/Almaden/IBM is out of the office.
by Anna Liu 07 Okt '08

07 Okt '08

I will be out of the office starting 09/26/2008 and will not return until 10/17/2008. I will respond to your message when I return.

1 0

Announcement: NAV 3.5.0b1 released
by Morten Brekkevold 07 Okt '08

07 Okt '08

NAV 3.5.0b1 is now available for download at Launchpad: https://launchpad.net/nav/3.5/3.5.0b1 This is a beta test release of the new features in the 3.5 series; the changelog is attached to this message. While we do already have four dedicated beta testers, we could always do with more. Please register at Launchpad and report all bugs at https://bugs.launchpad.net/nav . Binary packages for Debian will be available soon. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. For upgrading from 3.4, it is important that you remember to merge your databases into a single NAV database before running the regular SQL upgrade procedure. See the release notes for more information. Happy NAVing everyone! -- mvh Morten Brekkevold UNINETT

1 0

Problem with services
by hugo.doria＠tjse.jus.br 22 Sep '08

22 Sep '08

Hi, I just setup nav. I can access the webpage and panel administration. The problem is: None of the services i added is being showed in nav's webpage. Also, all services are down . I followed these instructions: http://metanav.uninett.no/seedessentials What's wrong? -- Hugo

2 1

Removing HP SwitchStack support from NAV
by Morten Brekkevold 17 Sep '08

17 Sep '08

Hi everyone, for quite some time we've been aware of many fundamental problems with the way support for HP SwitchStacks has been implemented in NAV. HP SwitchStack support was implemented in NAV 3.0 at NTNU, whose HP equipment consisted solely of HP SwitchStacks at that time. The result is code which is heavily biased towards SwitchStacks, to the point that NAV thinks HP devices are always SwitchStacks, no matter what. While we have been pondering alternative ways to model HP SwitchStacks (and consequently, Cisco switch clusters, which are basically the same thing), NTNU has entirely stopped using SwitchStacks. Today, they're experiencing bad side effects of the existing HP-related code in NAV. They're using some HP devices for routing, which NAV cannot handle at all (because of said "HP=SwitchStack only" view). No router ports are collected for these routers. Also, they seem to have many errors in topology information when HP devices are involved. Realizing that NTNU have stopped using SwitchStacks, we also do not know of anyone else who does, so now we are considering dropping support for SwitchStacks entirely from NAV. This way, the existing NAV code can treat HP devices like everything else. Preliminary tests of these changes at NTNU show promising results. So my question to the users of NAV is: Does anyone actually use virtually stacked HP switches? Will anyone miss support for this if removed from NAV? If there is no feedback on this issue, we will likely remove this support starting from NAV 3.5. -- mvh Morten Brekkevold UNINETT

2 3

Re: Announcement: NAV 3.4.2 released
by Tim Chown 12 Sep '08

12 Sep '08

On Wed, Sep 10, 2008 at 11:26:36AM +0200, Morten Brekkevold wrote: > > The SQL script fails because of a typo, i.e. a line was appended after > a line that it was meant to replace, causing an SQL error. > > For more details on this bug, see > https://bugs.launchpad.net/nav/+bug/260330 , which is part of NAV > 3.4.3, slated for release next week. > > You can fix it yourself by simply deleting the first of the two > WHERE-lines, as commented by Kristian Klette here: > https://bugs.launchpad.net/nav/+bug/260330/comments/1 Thanks, that appears to have run fine. -- Tim

1 0

Re: Announcement: NAV 3.4.2 released
by Tim Chown 10 Sep '08

10 Sep '08

On Tue, Sep 09, 2008 at 03:31:00PM +0200, Morten Brekkevold wrote: > On Tue, 9 Sep 2008 13:58:07 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > > Is there any gotcha to doing a straight aptitude update from a previous > > version (3.4.1) to the new version on a live system? > > There shouldn't be. But make sure to do a "/etc/init.d/apache2 > force-reload" after the upgrade, to make sure Apache/mod_python is > using the new NAV code. The upgrade seemed to work fine. I followed the info about the sql update but got errors: # psql -f 3.4.2.sql manage nav Password for user nav: BEGIN CREATE RULE CREATE RULE CREATE RULE psql:3.4.2.sql:46: ERROR: syntax error at or near "WHERE" at character 1 psql:3.4.2.sql:46: LINE 1: WHERE key='serviceid' AND value=old.serviceid::text; psql:3.4.2.sql:46: ^ ROLLBACK We have psql 8.1, but I assumed the patch was required because we did install 3.4.1 from scratch. The comment in the patch file also says "NAV 3.4.1 and 3.4.1 were shipped with a manage.sql..." which I assume should say "NAV 3.4 and 3.4.1". Is the patch failing because we don't need it, or some other issue? :) Thanks, -- Tim

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