-- Marco Barbieri - CeSIA - 059-2055218 >From morten.brekkevold at uninett.no Thu Sep 6 11:35:14 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Thu Sep 6 10:35:38 2007 Subject: [Nav-users] Problem with NAV 3.2.2 and Hp 9304M - WRONG DATA - SORRY In-Reply-To: 200708310840.46033.barbieri.marco@unimore.it References: 200708310840.46033.barbieri.marco@unimore.it Message-ID: 46DFBBC2.2050000@uninett.no Marco Barbieri wrote, On 31-08-2007 08:40: > Hi again, > i'm sorry i've posted the wrong data, in the previous post you can find a > HP5412zl that NAV detects well. > > Here there's the data about HP9304M (it's marked HP but it's a Foundry > machine) that has the problem, it's a chassis with 4 slots, 3 of them are > loaded with 8 gbic sockets boards. Given the OID compatibility report you sent, NAV should be able to detect the ports on this routing switch; the ports are detected using standard mibs. Yet you say that _no_ ports are detected? If that is so, I would like to see what getDeviceData.log says when it collects from this device. When it comes to modules, I must admit that NAV's support for HP equipment is lacking in several respects. The HP support was written and tested using the equipment that was available at the Norwegian University of Science and Technology at the time, and these were all HP SwitchStacks. Consequently, NAV only recognizes virtual stacking in HP equipment, and cannot at all recognize modules in your HP chassis. It is in our plans to implement more generic module support through interpreting the ENTITY-MIB. I'm guessing your HP9304M presents a fairly correct view of its physical contents through its entPhysicalTable? Since I have no access to a 9304M myself, but am planning to code the ENTITY-MIB support, I would greatly appreciate it if you could provide me with the output of this table from your device; running this command on your NAV server should do it: snmptable -Ci -Cb -v2c -c <community> <ip> entPhysicalTable -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Thu Sep 6 12:12:49 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Thu Sep 6 11:13:05 2007 Subject: [Nav-users] Centos 5 and NAV 3.2.2 In-Reply-To: 200709031022.52942.barbieri.marco@unimore.it References: 200709031022.52942.barbieri.marco@unimore.it Message-ID: 46DFC491.4070702@uninett.no Marco Barbieri wrote, On 03-09-2007 10:22: > first of all i'm trying to run NAV 3.2.2 on a Centos 5 and i know it's not > supported, That depends on what you mean by "supported" :) We do not guaruantee support to anyone, but you should be able to have NAV up and run on any Linux distro. The most common obstacle seems to be when some software that NAV depends on comes out with a new version that breaks some backwards compatibility. > I get some errors from: > > Cron navcron@nav $BINDIR/getBoksMacs.sh $NUM_THREADS > > the body of the message is at the end of this msg, there's something i can do > to fix it or the set of libs that comes with Centos5 is too much different to > let NAV work as it is? > > Thanks for reading and my best regards, Marco barbieri. > > ---Body--- > org.postgresql.util.PSQLException: This statement has been closed. > at > org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(postgresql-jdbc-8.1.407.jar.so) [...] I think I've seen this before, and it happened when we upgraded our PostgreSQL JDBC driver to version 8.1. I'm not sure what changed, since the API should remain the same - only the driver should work better against PostgreSQL 8.1. I assume that your CentOS installation runs the PostgreSQL 8.1 server as well? Our temporary workaround was to downgrade the JDBC driver to the 7.4 version. You could try and see if that works. If CentOS 5 doesn't provide that version of the driver, you can get it from http://jdbc.postgresql.org/ -- mvh Morten Brekkevold UNINETT >From mels at mels-kooijman.nl Thu Sep 6 22:01:53 2007 From: mels at mels-kooijman.nl (Mels) Date: Thu Sep 6 21:02:09 2007 Subject: [Nav-users] Centos 5 and NAV 3.2.2 In-Reply-To: 46DFC491.4070702@uninett.no References: 200709031022.52942.barbieri.marco@unimore.it 46DFC491.4070702@uninett.no Message-ID: 46E04EA1.3010906@mels-kooijman.nl Hi all, I started this week with a clean system, installing nav on Suse 10.2 There was a problem with connecting to a remote database, for the time i use the local database, witch is OK for nav. I get 3 problems: 1 I installed py-rrdtool-1.0b1, with the installation off py-rrdtool-0.2.1 I get a error: building 'rrdtool._rrdtool' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC -I/usr/local/include -I/usr/include/python2.5 -c src/_rrdtoolmodule.c -o build/temp.linux-i686-2.5/src/_rrdtoolmodule.o src/_rrdtoolmodule.c: In function ?PyRRD_graph?: src/_rrdtoolmodule.c:239: error: too few arguments to function ?rrd_graph? error: command 'gcc' failed with exit status 1 from the cron I get a mail with the next text: File "/usr/local/nav/bin/thresholdMon.py", line 46, in <module> from nav.rrd import presenter File "/usr/local/nav/lib/python/nav/rrd/presenter.py", line 54, in <module> import rrdtool ImportError: dynamic module does not define init function (initrrdtool) 2 and 3 pping and servicemon failed to start, I tried a nav start pping servicemon a couple of time, also a start separate. but they whon't start. I changed DEBUG_LEVEL = 6 in nav.conf, but can't find any reason in the log files. Mels