Nav-users

nav-users@lister.sikt.no

1373 discussions

Patching forgetSQL on Python 2.5/2.6
by Morten Brekkevold 22 Mar '10

22 Mar '10

Hi all, forgetSQL is an unmaintained piece of shi^H^Hoftware that NAV versions up to 3.5 depend on. While we have removed this dependency from the coming NAV 3.6, some will experience warnings when running NAV under Python 2.5, and outright failures on Python 2.6, due to problems with the forgetSQL module. The forgetSQL module raises string exceptions in three places, and these are deprecated in Python 2.5, and not supported in 2.6. You may see error messages such as these: /var/lib/python-support/python2.5/forgetSQL.py:212: DeprecationWarning: raising a string exception is deprecated raise "NotFound" or File "/var/lib/python-support/python2.6/forgetSQL.py", line 212, in __new__ raise "NotFound" TypeError: exceptions must be classes or instances, not str I'm attaching a quick forgetSQL patch I've written to overcome these problems until NAV 3.6 has reached a stable release. -- Morten Brekkevold UNINETT

2 1

automatic Switch configuration rediscovery
by Rudolph Bott 19 Mar '10

19 Mar '10

Hi List, is there a way to trigger some sort of automatic device rediscovery? We recently changed a lot of ports on our cisco 4500 series switches to trunk mode and although this happened more than 2 weeks ago, NAV still does not reflect these new settings in the switch overview/IP Device Info. Is NAV even supposed to see these kind of changes or might I be hitting a bug? We are currently using NAV 3.5.4 - I know its not the latest release but at least its close to it ;-) On top of that I couldnt find any hints regarding this problem in the latest changelog. -- Mit freundlichen Grüßen / with kind regards Rudolph Bott

2 3

Angående uoverenstemmelser med det vi har fra NAV
by kadaffi.nasir＠hil.no 19 Mar '10

19 Mar '10

Hei Jeg stusser på tidsrommet på det som ble registert av nav og det vi har mottatt fra CERT: Tidsrom: 2010-03-16 21:33:36.26 - 2010-03-16 23:13:18.90 (UTC) Maskin: 158.36.199.6 [] Kontaktet: 195.244.8.148 på 1311/tcp (442 TCP SYNs) Det som er registert på NAV er: 158.36.199.6 00:15:c5:a4:d1:cd 2010-03-17 10:34 2010-03-18 05:35 på den gitte IP-adresse, og at den mac-adressen som er oppgitt fra NAV er registert med en annen IP-adresse på den gitte tidsrom: 158.36.196.163 2010-03-17 10:41 2010-03-18 01:26 00:15:c5:a4:d1:cd 2010-03-16 20:43 2010-03-16 23:29 2010-03-15 21:27 2010-03-15 23:13 2010-03-14 16:27 2010-03-14 21:59 2010-03-12 07:42 2010-03-12 07:59 2010-03-11 17:57 2010-03-11 23:43 2010-03-10 17:57 2010-03-11 01:15 158.36.196.163 2010-03-15 19:13 2010-03-15 21:29 00:15:c5:a4:d1:cd 2010-03-11 11:42 2010-03-11 17:43 Har dere mulighet for å se hva som har skjedd her? Mvh Achmad Kadaffi Nasir Førstekonsulent / IT-Tjenesten Høgskolen i Lillehammer / Lillehammer University College 2626 LILLEHAMMER NORWAY Telefon +47 61288181

2 1

Occasionally hardware changes for no reason
by Stokkenes Vidar 16 Mar '10

16 Mar '10

Hello everyone, Ever since we installed NAV, we've had a couple of switches that occasionally report a change in hardware versions for no particular reason. The output of the email is the following: <snip> This is an automatically generated message from NAV: Hardware version changed to: V09 from: 14 </snip> Does anyone know why this would happen? These come from switches with 1 year++ uptime where the IOS or hardware version hasn't been touched for half a year. We also have switches that report sudden date changes, such as the following (in Norwegian): Dette er en automatisk generert melding fra NAV: Boks switchname.domain.com (XXX.XXX.XXX.XXX) har gjennomført en coldstart: Gammel oppe siden: 1970-01-01 01:00:00 Ny oppe siden : 2010-01-15 12:16:21.863+01 Could this be a defective mainboard battery? Or is it simply NAV playing tricks with me :( Any help would be appreciated :-) Best regards, Vidar Stokkenes Helse Nord IKT

2 1

Log-engine, timestamp
by ronny.raudstein 11 Mar '10

11 Mar '10

I have installed NAV 3.5.5 on Centos 5.4, and followed the instructions by Roger Aas. Think this has been an issue in earlier versions too. The log engine seems to timestamp the syslog messages when the cisco.log file is parsed rather than when the message is generated on the device. Messages in cisco.log has correct timestamp. Look at the sample below: Cisco.log Mar 7 11:27:45 host: Mar 7 2010 11:27:47: %SEC-6-IPACCESSLOGP: list fraDMZ denied tcp x.x.x.x(2173) -> y.y.y.y(9100), 1 packet NAV - Syslog Analyzer 2010-03-07 11:27:00 host SEC-6(6)-IPACCESSLOGP 'list fraDMZ denied tcp x.x.x.x(2171) -> y.y.y.y(9100), 1 packet' Regards, Ronny Raudstein Kvinnherad Kommune

2 1

Announcement: NAV 3.5.5 released
by Morten Brekkevold 11 Mar '10

11 Mar '10

NAV 3.5.5 is now available for download at Launchpad: https://launchpad.net/nav/3.5/3.5.5 This release fixes 17 bugs in NAV 3.5. The log of all changes to the 3.5 series is attached to this message. A binary package for Debian 4 and 5 (Etch and Lenny) will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. At the same time I would like to apologize for lack of responses to mailing list posts the last few months. We were hoping to have NAV 3.6 ready by now, but everything has been delayed due to the fact that I was away from work for more than two months (beginning around 20th November). Happy NAVing everyone! -- Morten Brekkevold UNINETT

4 9

Installing NAV on CentOS, new installation guide
by Roger Aas 25 Feb '10

25 Feb '10

I have now made available a new version of the installation guide of NAV on CentOS (a Red Hat Enterprise Linux clone). It is based on the latest versions of NAV and CentOS available. You will find it on this link on MetaNAV: http://metanav.uninett.no/installingoncentos5 Please give me feedback if you find any errors or omissions. Or if you just want to thank me for making this guide. Best regards, Roger Aas Atea AS

2 1

Jabber dispatcher clogs the whole alertqueue
by Ingeborg Hellemo 05 Feb '10

05 Feb '10

We have used the jabber dispatcher since december. We soon discovered that our XMPP-server implementation (Openfire) sometimes freeze. It does not crash completely, but takes forever to answer connections. When this freeze happens and NAV tries to send an alert via jabber, the whole alertqueue clogs up and no alerts gets sent at all - no email, no sms, nothing. When the jabber-daemon is restarted all the backed up alerts are sent right away. (This of course happened during the holidays and we have disabled the jabber dispatcher ever since.) Is it possible to add a timeout or something to jabber_dispatcher.py to prevent this to happen? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no Dep. of Information Technology --- Univ. of Tromsø

5 4

Observing Voice VLAN enabled ports?
by Stokkenes Vidar 05 Feb '10

05 Feb '10

Hello everyone, I am wondering if anyone have found a way to use NAV to see if a certain port is voice vlan enabled? I submitted a LP ticket about this quite some time back, but I didn't receive a reply or any feedback on it (https://bugs.launchpad.net/nav/+bug/362233) Typically we have VoIP-people dropping by our office asking "Is Port44 on switch-2.hostname.com voice enabled, and which voice vlan?" I thought maybe IP Device Info would show this in forms of another vlan, but it doesn't. It would be to great value for us atleast :-) ------------------------------------------------------ Vidar Stokkenes

1 0

Module mapping problems
by Geir Inge Jensen 02 Feb '10

02 Feb '10

Hi, I thought I should give NAV a tryout in a large service provider network. After some initial problems fetching the device information for some devices (had to remove the OSPF oid) I was finally up and running. I had to add all my device types but that was easily done (I have mostly Cisco 7600 and 7300 series devices). However, NAV has a huge problem trying to figure out which module each port belongs to (especially the 10Gb ports). Attached is a device info screen grab of one of my modules (module 5), and as you can see NAV things the module has ports from module 1, 2, 4 (and 5) as well as loopbacks and vlans. Other parts of NAV seems to get things correct (the explorer) however because of these problems they can't detect where the port connects to (link type "none"). Which sadly makes NAV useless. Is there a way I can fix this? Whenever the device info is able to pinpoint which module the port belongs to it is also able to detect the device the port connects to (including the 10Gb ports). However, that seems to be the exception and not the rule. FYI, the screen grab is from a 7609 running SRD1. Regards, Geir Inge Jensen

1 0

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