/#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)