Ingeborg Hellemo <Ingeborg.Hellemo@cc.uit.no> writes:

/#tail /usr/local/nav/var/log/snmptrapd.log [2007-10-12 09:49:46,546] [ERROR] [pid=6655 nav.snmptrapd] Module nav.snmptrapd.handlers.linkupdown did not compile - No module named snmptrapd.handlers.linkupdown Traceback (most recent call last): File "/usr/local/nav/bin/snmptrapd.py", line 293, in trapHandler mod = __import__(name, globals(), locals(), [parent]) ImportError: No module named snmptrapd.handlers.linkupdown [2007-10-12 09:49:46,547] [ERROR] [pid=6655 nav.snmptrapd] Module nav.snmptrapd.handlers.airespace did not compile - No module named snmptrapd.handlers.airespace Traceback (most recent call last): File "/usr/local/nav/bin/snmptrapd.py", line 293, in trapHandler mod = __import__(name, globals(), locals(), [parent]) ImportError: No module named snmptrapd.handlers.airespace

Any ideas?

I've tried to reproduce this on Python 2.4.4 on a Debian GNU/Linux machine, without any luck. Could we have stumbled upon some FreeBSD specific thing or bug in Python? What seems to be happening here is that snmptrapd attempts to import a trap handler module called 'nav.snmptrapd.handlers.linkupdown' (as configured by snmptrapd.conf). Yet, the import fails, and Python reports that a module named 'snmptrapd.handlers.linkupdown' was not found. What happened to the 'nav' prefix? Can you confirm that your system has a Python module named nav.snmptrapd.handlers.linkupdown (i.e. nav/snmptrapd/handlers/linkupdown.py) installed and available on the Python library path? It should be there, along with all the other NAV Python libraries. -- mvh Morten Brekkevold UNINETT

From morten.brekkevold at uninett.no Mon Oct 29 16:03:40 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Mon Oct 29 16:03:45 2007 Subject: [Nav-users] Pilot installation and some problems In-Reply-To: <Pine.GSO.4.64.0710161602190.10415@pogostick.net> (Rikard Stemland Skjelsvik's message of "Tue, 16 Oct 2007 16:41:37 +0200 (MEST)") References: <Pine.GSO.4.64.0710161602190.10415@pogostick.net> Message-ID: <yyllk9mm08j.fsf@voldsminde.uninett.no>

Rikard Stemland Skjelsvik <rskjels@pogostick.net> writes:

I have installed Network Administration Visualized 3.3.0 on Debian Etch. I have installed NAV through aptitude. I'm very impressed with the amount of work and thought that have gone into this software package.

Thank you for your kind words :-)

However, i do have several problems.

I can not see any informastion in the section called "Port View" when i click on a device in Home > Report > Devices in Operation

Could this be some snmpproblem? I installed net-snmp and could do a snmpwalk against the device.

Yes and no. You have a problem with the Java Virtual Machine installed on your system, and this is causing the Drexel JavaSNMP library to spew NullPointerExceptions instead of doing something useful. This is evident because of the excerpt from getDeviceData-stderr.log you posted.

Also serveral devices report Availability like this one: Availability -4.1e+180% -5.1e+175% -3.8e+166% (day / week / month)

Could this be snmpversion troubles?

No. This looks similar to other RRD related problems we have seen when using rrdtool version 1.2.15. Something seems to be wrong with the Python binding provided by this version of rrdtool, and this causes many calculations based on RRD data to fail. One of our developers is looking in to this specific problem. Hopefully, we will have a solution for the NAV 3.3.1 release.

When i try click on the Traffic Map, all i get is a new page showing a java aplet that just show the java logo. I have tried this with both firefox and IE. The only way to exit is to kill the browser process.

Could this be a java version problem.

I doubt it. Please see this posting from the archives about common Traffic Map problems: http://desperados.itea.ntnu.no/pipermail/nav-users/2007-October/001705.html I think we need to update the Traffic Map FAQ point (although the current traffic map will be replaced in the not too distant future).

getDeviceData.log is zero size.

The default log level for NAV's Java processes in the Debian package is 3, which means only detected errors are logged. If you wish to see more information in the logs of the Java processes (getDeviceData, eventEngine, getBoksMacs, networkDiscovery), you should change the log level in /etc/nav/nav.conf.

In /var/log/nav/getDeviceData/getDeviceData-stderr.log contains:

Tracebacks of both handled and unhandled exceptions are written to stderr, which is redirected to this file.

java.lang.NullPointerException at snmp.SNMPSequence.setValue(Unknown Source) at snmp.SNMPVariablePair.<init>(Unknown Source) at snmp.SNMPv1CommunicationInterface.getNextMIBEntry(Unknown Source) at [...]

And this is, as I mentioned above, a problem with your installed Java Virtual Machine. We recommend using Sun's JVM, but Debian does not install this as the default Java alternative unless you explicitly ask it to. You should install the package sun-java5-jdk from Debian's non-free section, and use the command 'update-alternatives --config java' to select this Java VM as the correct alternative for the java command. You'll need to restart the eventEngine and getDeviceData daemons after this step.

Could this be related to the missing port view section?

Yes. You don't have any info in the port view section, because no info has been collected from your devices. Once your SNMP problem has been corrected, NAV should be able to collect the proper information from your devices. Take a look at the "IP Devices in operation" report (/report/netbox is the URL). This should give you a good overview of that NAV has detected on your devices, such as module and port counts. Also important is the SNMP column of this report, which tells you the number of known SNMP OIDs getDeviceData has found a device to be compatible with. Clicking a number in this column will bring you to a report showing the list of OIDs that were found compatible. All SNMP-enabled devices you have configured with a read-community in EditDB should have a number greater than zero in this column (unless you've just added the device, in which case NAV might not have had time to test it for compatibility yet). Good luck! -- mvh Morten Brekkevold UNINETT

From morten.brekkevold at uninett.no Tue Oct 30 08:44:51 2007 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Tue Oct 30 08:44:56 2007 Subject: [Nav-users] Could not connect to servlet In-Reply-To: <58B7A531794E6A49B3BAD57E3332254402515740@engexc11.archstonesmith.com> (Nestor Pabon's message of "Tue, 16 Oct 2007 09:27:55 -0600") References: <58B7A531794E6A49B3BAD57E333225440249A320@engexc11.archstonesmith.com> <470F2EFC.1090408@uninett.no> <58B7A531794E6A49B3BAD57E3332254402515740@engexc11.archstonesmith.com> Message-ID: <yylabq1m4gc.fsf@voldsminde.uninett.no>

"Pabon, Nestor" <NPabon@archstonesmith.com> writes:

I'm still having the same issue.

The output of "invoke-rc.d tomcat5.5 status" is

"Tomcat servlet engine is running with Java pid /var/lib/tomcat5.5/temp/tomcat5.5.pd"

The only changes I've made are those specified in: "/usr/share/doc/nav/README.Debian"

Thank you for taking the time to address this problem.

Nestor, please verify the following: * In /etc/tomcat5.5/server.xml you should have a line like the following: <Connector port="8180" maxHttpHeaderSize="8192" I.e. it defines a Tomcat HTTP/1.1 connector to listen on port 8180. * In /usr/lib/python2.4/site-packages/nav/web/pyproxy/proxy.py you should have a line (ca. line 42) that says: SERVERPORT=8180 If you can verify this, please restart Tomcat and try Network Explorer again. If it still does not work, please verify that you can actually reach Tomcat using your browser, by directing it to http://yourserver:8180/ -- mvh Morten Brekkevold UNINETT

From Ingeborg.Hellemo at cc.uit.no Tue Oct 30 09:19:11 2007 From: Ingeborg.Hellemo at cc.uit.no (Ingeborg Hellemo) Date: Tue Oct 30 09:19:41 2007 Subject: [Nav-users] snmptrapd with ImportError In-Reply-To: Your message of "Mon, 29 Oct 2007 15:40:19 +0100." <yylwst6m1bg.fsf@voldsminde.uninett.no> Message-ID: <200710300819.l9U8JBtD075294@barnetv.cc.uit.no>

morten.brekkevold@uninett.no said:

Can you confirm that your system has a Python module named nav.snmptrapd.handl ers.linkupdown (i.e. nav/snmptrapd/handlers/linkupdown.py) installed and available on the Python library path? It should be there, along with all the other NAV Python libraries.

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. --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg@cc.uit.no (Univ. of Troms?, Norway)