- Nav-users - lister.unit.no

Announcement: NAV 4.1.1 released
by Morten Brekkevold 14 Aug '14

14 Aug '14

The first maintenance release of the NAV 4.1 series is now available, version 4.1.1. The source code is available for download at Launchpad [1]. A new package for Debian Wheezy has been published in our APT repository [2]. Changes ======= The following reported issues have been fixed in the new release: * LP#1052804 (NoReverseMatch error on multiple pages when adding IPv6 host with no DNS name) * LP#1316599 (NoReverseMatch exception when trying to load netmap) * LP#1333170 (Disused prefixes aren't properly deleted from the database) * LP#1338548 (Searching for an apparently "invalid" hostname crashes ipdevinfo) * LP#1339575 (Room and organization data keys cannot be added using SQL without first checking for NULL values) * LP#1340193 (NAV gets confused when re-using VLAN tags for multiple broadcast domains) * LP#1340576 (Virtual status of router addresses cycles back and forth, causing net type to swing back and forth between lan and link) * LP#1355693 (Interface names not present in linkState alert messages) * LP#1355923 (dump.py -t room crash) Please refer to the release notes [3] for further information on upgrading from versions prior to 4.1. Happy NAVing everyone! Links ===== [1] https://launchpad.net/nav/4.1/4.1.1 [2] https://nav.uninett.no/wiki/nav_on_debian [3] https://nav.uninett.no/doc/4.1/release-notes.html -- Morten Brekkevold UNINETT AS

1 0

Graphite update frequency
by Bruno Galindro da Costa 14 Aug '14

14 Aug '14

How many times NAV input data into graphite per day for a given switch port? I need to know what is the graphite update frequency of collected data of my switch ports. Is each 1 min/ 5 min...? -- Att. Bruno Galindro da Costa

3 4

Netmap showing gray traffic
by Bruno Galindro da Costa 13 Aug '14

13 Aug '14

Why netmap is showing gray traffic of my interfaces? See this print (I've removed the net prefix for security reasons): [image: Imagem inline 1] In the above example, I've put in evidence the conection beetween 251.245 and 251.247. Here are those interface graphs: *251.245:* [image: Imagem inline 3] *251.247:* [image: Imagem inline 4] -- Att. Bruno Galindro da Costa

3 9

NAV not getting LLDP information from switches
by Bruno Galindro da Costa 13 Aug '14

13 Aug '14

I've two switches: xxx.xxx.251.245 and xxx.xxx.252.121. 250.121 is connected to GigabitEthernet 1/0/5 of 251.245 251.245 is connected to GigabitEthernet 1/48 of 250.121 251.245 is a 5500G-EI 24-Port (3Com Switch 5500G-EI 24-Port Software Version 3Com OS V3.03.02s168p22 from 3com) 250.121 is a DGS-3120-48TC (DGS-3120-48TC Gigabit Ethernet Switch from dlink) All of them has LLDP enabled. This is the neighbor information on switch port 1/48 of 250.121: Port ID : 1:48 ------------------------------------------------------------------------------- Remote Entities Count : 1 Entity 1 Chassis ID Subtype : MAC Address Chassis ID : 00-1E-C1-ED-78-80 Port ID Subtype : Interface Name Port ID : GigabitEthernet1/0/5 Port Description : GigabitEthernet1/0/5 System Name : xxxxxx System Description : Switch 5500G-EI 24-Port System Capabilities : Bridge, Router Management Address Count : 1 Port PVID : 1 PPVID Entries Count : 0 VLAN Name Entries Count : 1 Protocol ID Entries Count : 0 MAC/PHY Configuration/Status : (See Detail) Power Via MDI : (See Detail) Link Aggregation : (See Detail) Maximum Frame Size : 1522 Unknown TLVs Count : 0 This is the neighbor information on switch port 1/0/5 of 251.245: LLDP neighbor-information of port 5[GigabitEthernet1/0/5]: Neighbor index : 1 Update time : 80 days,21 hours,14 minutes,30 seconds Chassis type : MAC address Chassis ID : 2810-7B68-9D90 Port ID type : MAC address Port ID : 2810-7B68-9DC0 Port description : D-Link DGS-3120-48TC R2.00.010 Port 48 on Unit 1 System name : xxxxxx System description : Gigabit Ethernet Switch System capabilities supported : Repeater,Bridge System capabilities enabled : Repeater,Bridge Management address type : ipV4 Management address : xxx.xxx.252.121 Management address interface type : IfIndex Management address interface ID : 5121 Management address OID : In NAV, the DIRECT NEIGHBORSHIP CANDIDATES reports that *another.host* is a candidate neighbor to 1/0/5 of 251.245. BUT *another.host* is physically connected in switch port 1/2 of 252.121, as reported bellow: [image: Imagem inline 3] AFAIK, Nav will use LLDP over CAM to build the network topology. But, in this case, maybe is occurring something wrong, because seems that Nav isn't collecting LLDP informations from switches to build the network topology. Another strange thing is the UNRECOGNIZED NEIGHBORS report. It is reporting that 251.245 is an unrecognized neighbor of 252.121 with lldp as source. Why?? [image: Imagem inline 4] Morten, I'll send to you by e-mail the result of these commands: root@nav:~# ipdevpolld -J topo -n xxx.xxx.252.121 root@nav:~# snmpwalk -v2c -c 1brass12 xxx.xxx.252.121 .1.0.8802.1.1.2.1.4 root@nav:~# snmpwalk -v2c -c 1brass12 xxx.xxx.252.121 .1.0.8802.1.1.2.1.3 root@nav:~# ipdevpolld -J topo -n xxx.xxx.251.245 root@nav:~# snmpwalk -v2c -c 1brass12 xxx.xxx.251.245 .1.0.8802.1.1.2.1.4 root@nav:~# snmpwalk -v2c -c 1brass12 xxx.xxx.251.245 .1.0.8802.1.1.2.1.3 -- Att. Bruno Galindro da Costa

2 6

Sysname () is already in database
by jorr＠streamguys.com 13 Aug '14

13 Aug '14

Hello, I am demoing out the NAV appliance and we have a number of physical and virtual hosts that do not have reverse DNS entries available, resolution of the IPs belonging to the hosts results in unknown.domainname.tld. When attempting to add multiple hosts to the NAV seed database, I receive errors when NAV attempts to resolve the DNS name of the host, claiming that the host already exists, despite all unique information with the exception of the failed resolution of the fqdn. Is there a work-around so that NAV does not lookup the DNS name of said devices? Sincerely, Jesse

3 4

dump.py -t room error
by Sigurd Mytting 12 Aug '14

12 Aug '14

Hi! Trying to dump rooms I get this: # /usr/lib/nav/dump.py -t room #roomid[:locationid:descr:opt1:opt2:opt3:opt4:position] Traceback (most recent call last): File "/usr/lib/nav/dump.py", line 233, in <module> main() File "/usr/lib/nav/dump.py", line 229, in main handler() File "/usr/lib/nav/dump.py", line 102, in room line.extend(['%s=%s' % x for x in room.data.items()]) AttributeError: 'str' object has no attribute 'items' Can anyone verify the same problem with Debian and UNINETT 4.1 packages? Cheers, -Sigurd

2 1

nav installation, error 500
by Alexander Zubkov 12 Aug '14

12 Aug '14

Hello. I have installed NAV on Ubuntu 14.04 using this manual: https://nav.uninett.no/wiki/nav_on_debian But when I try to connect to server with my browser, I receive "500 Internal Server Error". This is what I see in apache's error.log: [Thu Jul 31 20:59:00.541666 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] mod_wsgi (pid=938): Exception occurred processing WSGI script '/usr/share/pyshared/nav/wsgi.py'. [Thu Jul 31 20:59:00.541733 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] Traceback (most recent call last): [Thu Jul 31 20:59:00.541775 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 206, in __call__ [Thu Jul 31 20:59:00.541851 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] response = self.get_response(request) [Thu Jul 31 20:59:00.541889 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 185, in get_response [Thu Jul 31 20:59:00.541934 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] resolver, sys.exc_info()) [Thu Jul 31 20:59:00.541980 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 232, in handle_uncaught_exception [Thu Jul 31 20:59:00.542044 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] if resolver.urlconf_module is None: [Thu Jul 31 20:59:00.542079 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 360, in urlconf_module [Thu Jul 31 20:59:00.542138 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] self._urlconf_module = import_module(self.urlconf_name) [Thu Jul 31 20:59:00.542173 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/utils/importlib.py", line 40, in import_module [Thu Jul 31 20:59:00.542216 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] __import__(name) [Thu Jul 31 20:59:00.542249 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/nav/django/urls.py", line 22, in <module> [Thu Jul 31 20:59:00.542313 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] from django.conf.urls.defaults import patterns, include, url [Thu Jul 31 20:59:00.542357 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] ImportError: No module named defaults What is wrong with my installation?

2 1

GnuPG key transition
by Morten Brekkevold 12 Aug '14

12 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1,SHA256 This is to certify that I have transitioned from my old 1024 bit GnuPG key to a new 4096 bit one (for those of you who actually care to verify my signatures on tarballs, Debian packages and e-mails). My old key will continue to be valid until I publish a revocation certificate for it at a later date, but I will only be using the new key for signatures from now on. My old key was: pub 1024D/4A5C3A44 2003-03-31 Key fingerprint = 4321 140D DC2A 7789 32A2 371D 5F12 25D2 4A5C 3A44 My new key is: pub 4096R/04D271B4 2014-07-24 Key fingerprint = 38C0 CC84 CEE3 E55E 2A07 3298 61D9 2617 04D2 71B4 To fetch my new key from a public key server, you can simply do: gpg --keyserver subkeys.pgp.net --recv-key 04D271B4 If you already know my old key, you can now verify that the new key is signed by the old one: gpg --check-sigs 04D271B4 - -- Best regards, Morten Brekkevold UNINETT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPqEgwACgkQXxIl0kpcOkRvBwCfUsUhbBqG607LLOS4Yirhdq2d B4gAoIEU7TgwMLS0AGY3girVFM9RAD1QiQIcBAEBCAAGBQJT6hIMAAoJEGHZJhcE 0nG09fYQAKsruDg3JIxlOfb6lPYjzRtYVh3r9fhpZ9T7daKHX5bLbTs/nw7NxqqM eUf14U1IIFI4fj190SklJFV5UR5sPdB/n3sbFMg6lZO4PJ7SwtmZ1CmIYbyHJ/7A FHtbwRX2TyIBrZNO+QF9Xh9/OtOuYrBjsFPlx7E6cUL4HProX9L+8ZfnX3MfLC0/ oOQI3/lbcthSoJyujGCnjg7Ko1e9YjU8F776rdq6YgGNdd5zHIZzV2mHgbcwGyoN z+qdOtC6ZFRc4VRTidDme7i3ywTYjsdMvhz7+ZRWV+12GBT/I6DavRGIhOWDJsx/ dyvFespk9haUX0wmYsVSTKEeJln9AJ25FxOuqorl/9j3Hfne2hMs8aLSalR6Tgva aeBIUxJTF2TA8XWmQq9366SwIBvy2/opJcaloeGGcjBgUKEFbaWoufaVLPllRFzQ kSBacUjArBY7C9jbUOdtgp2a5un1Aw+eJlCML9npTRLTWabCT8YfL2Ut2E8mWBYv hAI6fMTJhIB+kfgGLys6lU3cLHUg7wDhUkTFVPpTNbaGdsWahDUG2xQDHMHjFoWF kylHjvKBwoNfQWoFpOkWGT9R7/7nQACTXK5DoxFNmFGVeMPoBA9egY1KBPhZ6fyR bvWqDGd7dJ+/nuHofnkgzIsW11wHvKj0T3C3JiM8xmu9LBpIxgJl =TvjZ -----END PGP SIGNATURE-----

1 0

Re: NAV not getting LLDP information from switches
by Morten Brekkevold 26 Jul '14

26 Jul '14

On Wed, 9 Jul 2014 10:34:49 -0300 Bruno Galindro da Costa <bruno.galindro(a)gmail.com> wrote: > See attached files. There may be another fault lurking in here: > 2014-07-09 08:05:27,217 [DEBUG jobs.jobhandler] [topo x.x.251.245] Now calling plugin: nav.ipdevpoll.plugins.lldp.LLDP(u'x.x.251.245') > 2014-07-09 08:05:27,234 [DEBUG timestamps.timestampchecker] [topo x.x.251.245] 'lldp': timestamps appear unchanged since last run As I wrote in another post, NAV will not do LLDP processing on this device until the timestamp of the lldpRemTable changes. If the LLDP neighbors were unidentifiable on the first run, but have become identifiable at a later time, this will not be rectified by NAV until this device changes this timestamp and causes NAV to process it again. If you search for the MAC addreses using the Machine Tracker and interface reports, as I asked, and found the MAC addresses to be identifiable, you may be able to kickstart a new processing of the LLDP information by deleting NAV's stored timestamps. Something like this would do it: sudo -u postgres psql nav \ -c "DELETE FROM netboxinfo WHERE key='poll_times' AND var='lldp'" It may be a better strategy for NAV here to invalidate these timestamps on set intervals to force reprocessing of the LLDP information; just not on every run of the LLDP collector. -- Morten Brekkevold UNINETT

2 4

ipdevpolld topo job error
by Bruno Galindro da Costa 23 Jul '14

23 Jul '14

This is the error reported by ipdevpolld when I execute it in a netbox: root@nav:/etc/nav# ipdevpolld -J topo -n 192.168.250.252 2014-07-03 14:39:07,331 [INFO nav.ipdevpoll] --- Starting ipdevpolld topo --- 2014-07-03 14:39:07,332 [DEBUG plugins] Importing plugin system= 2014-07-03 14:39:07,337 [DEBUG plugins] found plugin class System in <module 'nav.ipdevpoll.plugins.system' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/system.pyc'> 2014-07-03 14:39:07,337 [DEBUG plugins] Importing plugin uptime= 2014-07-03 14:39:07,337 [DEBUG plugins] found plugin class Uptime in <module 'nav.ipdevpoll.plugins.uptime' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/uptime.pyc'> 2014-07-03 14:39:07,337 [DEBUG plugins] Importing plugin interfaces= 2014-07-03 14:39:07,343 [DEBUG plugins] found plugin class Interfaces in <module 'nav.ipdevpoll.plugins.interfaces' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/interfaces.pyc'> 2014-07-03 14:39:07,343 [DEBUG plugins] Importing plugin bridge= 2014-07-03 14:39:07,343 [DEBUG plugins] found plugin class Bridge in <module 'nav.ipdevpoll.plugins.bridge' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/bridge.pyc'> 2014-07-03 14:39:07,343 [DEBUG plugins] Importing plugin typeoid= 2014-07-03 14:39:07,344 [DEBUG plugins] found plugin class TypeOid in <module 'nav.ipdevpoll.plugins.typeoid' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/typeoid.pyc'> 2014-07-03 14:39:07,344 [DEBUG plugins] Importing plugin dot1q= 2014-07-03 14:39:07,350 [DEBUG plugins] found plugin class Dot1q in <module 'nav.ipdevpoll.plugins.dot1q' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/dot1q.pyc'> 2014-07-03 14:39:07,351 [DEBUG plugins] Importing plugin ciscovlan= 2014-07-03 14:39:07,359 [DEBUG plugins] found plugin class CiscoVlan in <module 'nav.ipdevpoll.plugins.ciscovlan' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/ciscovlan.pyc'> 2014-07-03 14:39:07,359 [DEBUG plugins] Importing plugin prefix= 2014-07-03 14:39:07,396 [DEBUG plugins] found plugin class Prefix in <module 'nav.ipdevpoll.plugins.prefix' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/prefix.pyc'> 2014-07-03 14:39:07,396 [DEBUG plugins] Importing plugin virtualrouter= 2014-07-03 14:39:07,398 [DEBUG plugins] found plugin class VirtualRouter in <module 'nav.ipdevpoll.plugins.virtualrouter' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/virtualrouter.pyc'> 2014-07-03 14:39:07,398 [DEBUG plugins] Importing plugin arp= 2014-07-03 14:39:07,399 [DEBUG plugins] found plugin class Arp in <module 'nav.ipdevpoll.plugins.arp' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/arp.pyc'> 2014-07-03 14:39:07,399 [DEBUG plugins] Importing plugin cam= 2014-07-03 14:39:07,404 [DEBUG plugins] found plugin class Cam in <module 'nav.ipdevpoll.plugins.cam' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/cam.pyc'> 2014-07-03 14:39:07,404 [DEBUG plugins] Importing plugin lldp= 2014-07-03 14:39:07,404 [DEBUG plugins] found plugin class LLDP in <module 'nav.ipdevpoll.plugins.lldp' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/lldp.pyc'> 2014-07-03 14:39:07,405 [DEBUG plugins] Importing plugin cdp= 2014-07-03 14:39:07,407 [DEBUG plugins] found plugin class CDP in <module 'nav.ipdevpoll.plugins.cdp' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/cdp.pyc'> 2014-07-03 14:39:07,407 [DEBUG plugins] Importing plugin modules= 2014-07-03 14:39:07,407 [DEBUG plugins] found plugin class Modules in <module 'nav.ipdevpoll.plugins.modules' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/modules.pyc'> 2014-07-03 14:39:07,407 [DEBUG plugins] Importing plugin ciscosup= 2014-07-03 14:39:07,408 [DEBUG plugins] found plugin class CiscoSup in <module 'nav.ipdevpoll.plugins.ciscosup' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/ciscosup.pyc'> 2014-07-03 14:39:07,408 [DEBUG plugins] Importing plugin extremevlan= 2014-07-03 14:39:07,412 [DEBUG plugins] found plugin class ExtremeVlan in <module 'nav.ipdevpoll.plugins.extremevlan' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/extremevlan.pyc'> 2014-07-03 14:39:07,413 [DEBUG plugins] Importing plugin linkstate= 2014-07-03 14:39:07,413 [DEBUG plugins] found plugin class LinkState in <module 'nav.ipdevpoll.plugins.linkstate' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/linkstate.pyc'> 2014-07-03 14:39:07,413 [DEBUG plugins] Importing plugin sensors= 2014-07-03 14:39:09,685 [DEBUG plugins] found plugin class Sensors in <module 'nav.ipdevpoll.plugins.sensors' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/sensors.pyc'> 2014-07-03 14:39:09,685 [DEBUG plugins] Importing plugin psu= 2014-07-03 14:39:09,691 [DEBUG plugins] found plugin class PowerSupplyUnit in <module 'nav.ipdevpoll.plugins.psu' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/psu.pyc'> 2014-07-03 14:39:09,691 [DEBUG plugins] Importing plugin snmpcheck= 2014-07-03 14:39:09,692 [DEBUG plugins] found plugin class SnmpCheck in <module 'nav.ipdevpoll.plugins.snmpcheck' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/snmpcheck.pyc'> 2014-07-03 14:39:09,692 [DEBUG plugins] Importing plugin propserial= 2014-07-03 14:39:09,696 [DEBUG plugins] found plugin class ProprietarySerial in <module 'nav.ipdevpoll.plugins.propserial' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/propserial.pyc'> 2014-07-03 14:39:09,696 [DEBUG plugins] Importing plugin statports= 2014-07-03 14:39:09,696 [DEBUG plugins] found plugin class StatPorts in <module 'nav.ipdevpoll.plugins.statports' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/statports.pyc'> 2014-07-03 14:39:09,696 [DEBUG plugins] Importing plugin statsystem= 2014-07-03 14:39:09,824 [DEBUG plugins] found plugin class StatSystem in <module 'nav.ipdevpoll.plugins.statsystem' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/statsystem.pyc'> 2014-07-03 14:39:09,824 [DEBUG plugins] Importing plugin statsensors= 2014-07-03 14:39:09,825 [DEBUG plugins] found plugin class StatSensors in <module 'nav.ipdevpoll.plugins.statsensors' from '/usr/lib/python2.7/dist-packages/nav/ipdevpoll/plugins/statsensors.pyc'> 2014-07-03 14:39:09,825 [INFO plugins] Imported 24 plugin classes, 24 classes in plugin registry 2014-07-03 14:39:09,825 [INFO nav.ipdevpoll] Running single 'topo' job for 192.168.250.252 2014-07-03 14:39:09,825 [DEBUG config] parsed jobs from config file: ['inventory', 'dns', 'ip2mac', 'topo', 'linkcheck', 'snmpcheck', '5minstats', '1minstats'] 2014-07-03 14:39:09,826 [DEBUG jobs.jobhandler] [topo 192.168.250.252] Job 'topo' initialized with plugins: ['cam', 'lldp', 'cdp'] 2014-07-03 14:39:09,827 [DEBUG jobs.jobhandler] [topo 192.168.250.252] AgentProxy created for 192.168.250.252: <nav.ipdevpoll.snmp.pynetsnmp.AgentProxy object at 0x5562bd0> 2014-07-03 14:39:09,846 [DEBUG jobs.jobhandler] [topo 192.168.250.252] no unwilling plugins 2014-07-03 14:39:09,846 [DEBUG jobs.jobhandler] [topo 192.168.250.252] willing plugins: ['Cam', 'LLDP', 'CDP'] 2014-07-03 14:39:09,846 [DEBUG jobs.jobhandler] [topo 192.168.250.252] Starting job 'topo' for 192.168.250.252 2014-07-03 14:39:09,846 [DEBUG jobs.jobhandler] [topo 192.168.250.252] Now calling plugin: nav.ipdevpoll.plugins.cam.Cam(u'192.168.250.252') 2014-07-03 14:39:38,419 [DEBUG plugins.cam.cam] [topo 192.168.250.252] Q-BRIDGE-MIB: 0 MAC addresses found on 0 ports 2014-07-03 14:44:48,865 [DEBUG plugins.cam.cam] [topo 192.168.250.252] BRIDGE-MIB: 4223 MAC addresses found on 2 ports 2014-07-03 14:44:48,895 [DEBUG plugins.cam.cam] [topo 192.168.250.252] up/downlinks: [4] 2014-07-03 14:44:48,895 [DEBUG plugins.cam.cam] [topo 192.168.250.252] access ports: [539] 2014-07-03 14:44:48,895 [DEBUG plugins.cam.cam] [topo 192.168.250.252] 4 sees the following monitored mac addresses: set(['00:16:e0:ee:58:01', '00:16:e0:ee:55:81', '00:18:74:2e:f4:80']) 2014-07-03 14:47:39,441 [DEBUG plugins.cam.cam] [topo 192.168.250.252] found 4 STP blocking ports on 114 vlans: [(1, 'vlan1505'), (2, 'vlan1505'), (543, 'vlan1137'), (1, 'vlan1006'), (1, 'vlan1200'), (543, 'vlan1200'), (544, 'vlan1200'), (1, 'vlan1123'), (543, 'vlan253'), (544, 'vlan253'), (1, 'vlan1054'), (1, 'vlan1545'), (1, 'vlan254'), (543, 'vlan254'), (544, 'vlan254'), (543, 'vlan1223'), (544, 'vlan1223'), (544, 'vlan1115'), (1, 'vlan1045'), (544, 'vlan1045'), (543, 'vlan1619'), (1, 'vlan1511'), (1, 'vlan1138'), (543, 'vlan1138'), (543, 'vlan108'), (1, 'vlan1162'), (543, 'vlan1162'), (544, 'vlan1162'), (543, 'vlan1037'), (1, 'vlan1009'), (543, 'vlan1129'), (1, 'vlan1191'), (543, 'vlan1191'), (1, 'vlan1093'), (543, 'vlan1093'), (543, 'vlan1811'), (544, 'vlan1811'), (1, 'vlan1055'), (1, 'vlan1636'), (543, 'vlan255'), (1, 'vlan1224'), (543, 'vlan1224'), (544, 'vlan1224'), (544, 'vlan1116'), (1, 'vlan1176'), (544, 'vlan1084'), (543, 'vlan1139'), (1, 'vlan1204'), (543, 'vlan1204'), (544, 'vlan1204'), (1, 'vlan1106'), (2, 'vlan1106'), (543, 'vlan1038'), (543, 'vlan1130'), (543, 'vlan1192'), (543, 'vlan1030'), (1, 'vlan301'), (1, 'vlan1225'), (543, 'vlan1225'), (544, 'vlan1225'), (544, 'vlan1085'), (1, 'vlan1700'), (1, 'vlan1140'), (543, 'vlan1140'), (1, 'vlan1107'), (543, 'vlan1805'), (544, 'vlan1630'), (1, 'vlan1039'), (544, 'vlan1039'), (544, 'vlan1605'), (1, 'vlan1012'), (1, 'vlan1242'), (2, 'vlan1242'), (543, 'vlan1131'), (544, 'vlan1131'), (1, 'vlan2'), (2, 'vlan2'), (1, 'vlan1095'), (543, 'vlan1031'), (1, 'vlan1585'), (1, 'vlan302'), (1, 'vlan1226'), (543, 'vlan1226'), (544, 'vlan1226'), (1, 'vlan1118'), (543, 'vlan1118'), (544, 'vlan1118'), (1, 'vlan1701'), (1, 'vlan1524'), (544, 'vlan1806'), (1, 'vlan1075'), (1, 'vlan1040'), (1, 'vlan1243'), (2, 'vlan1243'), (1, 'vlan3'), (2, 'vlan3'), (543, 'vlan1194'), (544, 'vlan1098'), (543, 'vlan1032'), (544, 'vlan1032'), (1, 'vlan1248'), (543, 'vlan1134'), (1, 'vlan1227'), (544, 'vlan1227'), (1, 'vlan1100'), (544, 'vlan1180'), (543, 'vlan1087'), (544, 'vlan1087'), (544, 'vlan1049'), (1, 'vlan1591'), (543, 'vlan1228'), (1, 'vlan1120'), (543, 'vlan1120'), (1, 'vlan250'), (543, 'vlan250'), (544, 'vlan250'), (1, 'vlan1211'), (1, 'vlan1088'), (544, 'vlan1088'), (1, 'vlan1170'), (543, 'vlan1170'), (1, 'vlan1076'), (1, 'vlan1041'), (544, 'vlan1041'), (1, 'vlan1110'), (544, 'vlan1110'), (1, 'vlan4'), (2, 'vlan4'), (544, 'vlan1195'), (1, 'vlan1077'), (1, 'vlan1155'), (1, 'vlan1033'), (544, 'vlan1033'), (1, 'vlan1340'), (1, 'vlan1135'), (543, 'vlan1135'), (543, 'vlan1197'), (544, 'vlan1050'), (1, 'vlan1025'), (1, 'vlan251'), (543, 'vlan251'), (544, 'vlan251'), (544, 'vlan1188'), (544, 'vlan1089'), (1, 'vlan1052'), (1, 'vlan4008'), (1, 'vlan1042'), (544, 'vlan1042'), (544, 'vlan1111'), (544, 'vlan1043'), (543, 'vlan1034'), (543, 'vlan1136'), (1, 'vlan1001'), (2, 'vlan1001'), (1, 'vlan1070'), (1, 'vlan252'), (2, 'vlan252'), (543, 'vlan252'), (544, 'vlan252'), (1, 'vlan1189'), (543, 'vlan1189'), (1, 'vlan1090'), (1, 'vlan1053'), (543, 'vlan1533'), (544, 'vlan1222'), (1, 'vlan1113'), (543, 'vlan1113'), (544, 'vlan1113'), (1, 'vlan1044'), (2, 'vlan1044')] 2014-07-03 14:47:39,447 [DEBUG jobs.jobhandler] [topo 192.168.250.252] Now calling plugin: nav.ipdevpoll.plugins.lldp.LLDP(u'192.168.250.252') 2014-07-03 14:47:39,883 [DEBUG timestamps.timestampchecker] [topo 192.168.250.252] 'lldp': None in timestamp list: (None,) 2014-07-03 14:47:39,883 [WARNING timestamps.timestampchecker] [topo 192.168.250.252] 'lldp': retrieved empty timestamp 2014-07-03 14:49:59,504 [DEBUG plugins.lldp.lldp] [topo 192.168.250.252] LLDP neighbors: [LLDPNeighbor(ifindex=1, chassis_id=macAddress('00:22:57:74:1f:00'), port_id=interfaceName('TenGigabitEthernet1/1/2'), port_desc='TenGigabitEthernet1/1/2', sysname='SeTIC-251.247'), LLDPNeighbor(ifindex=539, chassis_id=macAddress('00:22:b0:bc:35:f8'), port_id=interfaceName('1:23'), port_desc='Ethernet Interface', sysname='ENS-Nova[86-4]'), LLDPNeighbor(ifindex=544, chassis_id=macAddress('b0:fa:eb:62:c2:80'), port_id=interfaceName('Te1/31'), port_desc='TenGigabitEthernet1/31', sysname='CFH-243.ufsc.br'), LLDPNeighbor(ifindex=543, chassis_id=macAddress('44:03:a7:e9:17:c0'), port_id=interfaceName('Te1/31'), port_desc='TenGigabitEthernet1/31', sysname='CSE-246.ufsc.br'), LLDPNeighbor(ifindex=2, chassis_id=macAddress('00:16:e0:ee:55:80'), port_id=interfaceName('TenGigabitEthernet1/1/2'), port_desc='TenGigabitEthernet1/1/2', sysname='SeTIC-252.247')] 2014-07-03 14:49:59,543 [DEBUG jobs.jobhandler] [topo 192.168.250.252] Now calling plugin: nav.ipdevpoll.plugins.cdp.CDP(u'192.168.250.252') 2014-07-03 14:49:59,553 [DEBUG timestamps.timestampchecker] [topo 192.168.250.252] 'cdp': timestamps have changed: (12700620L,) / (12703533L,) 2014-07-03 14:49:59,573 [DEBUG plugins.cdp.cdp] [topo 192.168.250.252] found CDP cache data: [CDPNeighbor(ifindex=4, ip=IP('150.162.103.251'), deviceid='SeTIC-251.ufsc.br', deviceport='TenGigabitEthernet1/1'), CDPNeighbor(ifindex=562, ip=IP('150.162.251.240'), deviceid='UFSC-QinQ[200.17].ufsc.br', deviceport='GigabitEthernet0/27'), CDPNeighbor(ifindex=543, ip=IP('150.162.250.246'), deviceid='CSE-246.ufsc.br', deviceport='TenGigabitEthernet1/31'), CDPNeighbor(ifindex=544, ip=IP('150.162.250.243'), deviceid='CFH-243.ufsc.br', deviceport='TenGigabitEthernet1/31'), CDPNeighbor(ifindex=1, ip=IP('150.162.0.82'), deviceid='VPN', deviceport='FastEthernet0/0')] 2014-07-03 14:49:59,634 [DEBUG shadows.interface.interfacemanager] [topo 192.168.250.252] resolving link state alerts for these ifcs: [] 2014-07-03 14:49:59,643 [DEBUG shadows.adjacency.adjacencymanager] [topo 192.168.250.252] existing: {(1164, 1, u'cam'): <AdjacencyCandidate: 192.168.250.252:Te1/4 at 192.168.250.252 cam candidate 150.162.251.245:None>, (1164, 12, u'cam'): <AdjacencyCandidate: 192.168.250.252:Te1/4 at 192.168.250.252 cam candidate 150.162.250.253:None>, (1164, 11, u'cam'): <AdjacencyCandidate: 192.168.250.252:Te1/4 at 192.168.250.252 cam candidate 150.162.252.247:None>, (1164, 8, u'cam'): <AdjacencyCandidate: 192.168.250.252:Te1/4 at 192.168.250.252 cam candidate 150.162.251.247:None>, (1164, 2, u'cam'): <AdjacencyCandidate: 192.168.250.252:Te1/4 at 192.168.250.252 cam candidate 150.162.252.245:None>} 2014-07-03 14:49:59,673 [DEBUG shadows.adjacency.adjacencymanager] [topo 192.168.250.252] missing: [<AdjacencyCandidate: 192.168.250.252:Te1/4 at 192.168.250.252 cam candidate 150.162.251.245:None>, <AdjacencyCandidate: 192.168.250.252:Te1/4 at 192.168.250.252 cam candidate 150.162.251.247: None>] 2014-07-03 14:49:59,673 [DEBUG shadows.adjacency.adjacencymanager] [topo 192.168.250.252] sources: set(['lldp', 'cdp', 'cam']) 2014-07-03 14:49:59,682 [DEBUG shadows.cam.cammanager] [topo 192.168.250.252] existing=134 (reclaimable=28) / found=131 (known=107 new=24 missing=27) 2014-07-03 14:49:59,687 [ERROR jobs.jobhandler] [topo 192.168.250.252] Caught exception during save. Last manager = None. Last model = None Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/jobs.py", line 409, in perform_save self._log_containers("containers before save") File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/jobs.py", line 439, in _log_containers pprint.pformat(dict(self.containers))) File "/usr/lib/python2.7/pprint.py", line 60, in pformat return PrettyPrinter(indent=indent, width=width, depth=depth).pformat(object) File "/usr/lib/python2.7/pprint.py", line 119, in pformat self._format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.7/pprint.py", line 137, in _format rep = self._repr(object, context, level - 1) File "/usr/lib/python2.7/pprint.py", line 230, in _repr self._depth, level) File "/usr/lib/python2.7/pprint.py", line 242, in format return _safe_repr(object, context, maxlevels, level) File "/usr/lib/python2.7/pprint.py", line 286, in _safe_repr vrepr, vreadable, vrecur = saferepr(v, context, maxlevels, level) File "/usr/lib/python2.7/pprint.py", line 284, in _safe_repr for k, v in _sorted(object.items()): File "/usr/lib/python2.7/pprint.py", line 79, in _sorted return sorted(iterable) File "/usr/lib/python2.7/dist-packages/IPy.py", line 745, in __eq__ return self.__cmp__(other) == 0 File "/usr/lib/python2.7/dist-packages/IPy.py", line 708, in __cmp__ if self._prefixlen < other.prefixlen(): AttributeError: 'macAddress' object has no attribute 'prefixlen' 2014-07-03 14:49:59,689 [ERROR jobs.jobhandler] [topo 192.168.250.252] Save stage failed with unhandled error *--- Failure #6 --- /usr/lib/python2.7/threading.py:525: __bootstrap(...) /usr/lib/python2.7/threading.py:552: __bootstrap_inner(...) /usr/lib/python2.7/threading.py:505: run(...) [Capture of Locals and Globals disabled (use captureVars=True)] --- <exception caught here> --- /usr/lib/python2.7/dist-packages/twisted/python/threadpool.py:207: _worker(...) /usr/lib/python2.7/dist-packages/twisted/python/context.py:118: callWithContext(...) /usr/lib/python2.7/dist-packages/twisted/python/context.py:81: callWithContext(...) /usr/lib/python2.7/dist-packages/nav/ipdevpoll/db.py:152: _reset(...) /usr/lib/python2.7/dist-packages/nav/ipdevpoll/db.py:111: _autocommit(...) /usr/lib/python2.7/dist-packages/nav/ipdevpoll/db.py:130: _cleanup(...) /usr/lib/python2.7/dist-packages/nav/ipdevpoll/jobs.py:368: complete_save_cycle(...) /usr/lib/python2.7/dist-packages/nav/ipdevpoll/jobs.py:409: perform_save(...) /usr/lib/python2.7/dist-packages/nav/ipdevpoll/jobs.py:439: _log_containers(...) /usr/lib/python2.7/pprint.py:60: pformat(...) /usr/lib/python2.7/pprint.py:119: pformat(...) /usr/lib/python2.7/pprint.py:137: _format(...) /usr/lib/python2.7/pprint.py:230: _repr(...) /usr/lib/python2.7/pprint.py:242: format(...) /usr/lib/python2.7/pprint.py:286: _safe_repr(...) /usr/lib/python2.7/pprint.py:284: _safe_repr(...) /usr/lib/python2.7/pprint.py:79: _sorted(...) /usr/lib/python2.7/dist-packages/IPy.py:745: __eq__(...) /usr/lib/python2.7/dist-packages/IPy.py:708: __cmp__(...) [Capture of Locals and Globals disabled (use captureVars=True)] exceptions.AttributeError: 'macAddress' object has no attribute 'prefixlen' *--- End of Failure #6 --- 2014-07-03 14:49:59,689 [DEBUG jobs.jobhandler-timings] [topo 192.168.250.252] Job 'topo' timings for 192.168.250.252: Cam : 0:08:29.600778 LLDP : 0:02:20.095687 CDP : 0:00:00.054041 ---------------------------- Plugin total: 0:10:49.750506 ---------------------------- Job total : 0:10:49.842300 Job overhead: 0:00:00.091794 2014-07-03 14:49:59,689 [ERROR jobs.jobhandler] [topo 192.168.250.252] Job 'topo' for 192.168.250.252 aborted: Job aborted due to save failure (cause=AttributeError("'macAddress' object has no attribute 'prefixlen'",)) root@nav:/etc/nav# nav version NAV 4.1.0 root@nav:/etc/nav# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 7.5 (wheezy) Release: 7.5 Codename: wheezy root@nav:/etc/nav# python --version Python 2.7.3 -- Att. Bruno Galindro da Costa

2 7

Re: Overdue ipdevpoll jobs
by Bruno Galindro da Costa 08 Jul '14

08 Jul '14

OK Morten, tks... I'm sorry that I've sent e-mails directly to you. I had not realized until you talk... 2014-07-08 5:22 GMT-03:00 Morten Brekkevold <morten.brekkevold(a)uninett.no>: > On Mon, 7 Jul 2014 09:01:23 -0300 Bruno Galindro da Costa < > bruno.galindro(a)gmail.com> wrote: > > > After set the interval to 30m in [job_topo] section > > of /etc/nav/ipdevpoll.conf, this problem was solved, but I dont know why > :( > > If you're happy with collecting CAM and topology data that seldom, then > sure, fine. It could also be just because you restarted ipdevpoll. > > -- > Morten Brekkevold > UNINETT > > -- > Att. > Bruno Galindro da Costa > >

1 0

NAV 4 hardware/installation recommendation
by Sigurd Mytting 02 Jul '14

02 Jul '14

Hi all! I'm looking into doing an upgrade of our NAV installation, we're on 3.15 and it's time to move on to 4. I'm looking for advice on hardware setup, filesystem layouts and so on. Currently we have about 1500 devices, 99% routers and switches, in the database (mostly Catalysts ranging from 2940 to 3750, a few 6500 and Nexus 7k/5k, Juniper SRX/EX and a Juniper QFX, around 50 virtual Cisco ASA contexts as well). Hardware is a single server, 2x dual core opteron 2.6GHz, 32GB ram and several raid1's (in hardware). I've put postgres on its own 15k RPM raid1, the same with /var/lib/nav and confined /var/log/nav to the OS-drives with its own partition. I have been and will be using the excellent debian-packages from UNINETT for my installation. I've done some tricks for optimizing disk performance, by using the "noop" disk scheduler I see a big difference in system sluggishness, even when I have loads around 30. This is mostly related to my hardware raid, the default debian scheduler does not give a good performance when operating on a hardware raid (same thing with SSDs). I'm planning a new installation, this time on two servers, but I have yet to determine disk and raid layouts and what to put on each server. Postgres away from the collector is rather given, I'm unfamiliar with graphite, could/should it be put on another server? (I might find a third server if its recommended.) What will be the default datastores be? I'd like to set up separate partitions before installing the NAV-packages to make sure filesystems like /var don't run out of space when NAV logs grow, postgres goes wild and/or graphite stores what I'm actually asking it to store... What will typically be hit hard with random IO, sequential read/write and so on? Any input would be apreciated. Cheers, -Sigurd

2 3

Announcement: NAV 4.1.0 released
by Morten Brekkevold 26 Jun '14

26 Jun '14

The feature release of the new NAV 4.1 series is now available. The source code is available for download at Launchpad [1]. A new package for Debian Wheezy has _not yet_ been published in our APT repository [2], but will be sometime tomorrow, Friday. Changes ======= The following new features and changes have been introduced: * LP#744951 (show % usage for smaller subnets in subnet matrix) * LP#1062298 (Watchdog feature to monitor internal status of NAV processes) * LP#1169557 (Room and Organization opt fields should be replaced with an arbitrary variable=value scheme) * LP#1248092 (ipdevpoll CAM collection optimizations) * LP#1319657 (ipdevinfo alert tab does not display alerttype) * LP#1312648 (Remember user's preference for number of rows per page in SeedDB list views) * LP#1311205 (Change administrative status of interface from PortAdmin) * LP#1334243 (REST API) Please refer to the release notes [3] for further information on upgrading. Because the 3.15 and 4.0 series have been maintained in parallel with the 4.1 development line, you may need to use the -o option if you are executing the `navsyncdb` program manually for schema upgrades. Also, as the release notes describe, `navsyncdb` will need postgres superuser access to install the required `hstore` extension. Happy NAVing everyone! Links ===== [1] https://launchpad.net/nav/4.1/4.1.0 [2] https://nav.uninett.no/wiki/nav_on_debian [3] https://nav.uninett.no/doc/4.1/release-notes.html -- Morten Brekkevold UNINETT AS

1 0

Announcement: NAV 4.0.3 released
by Morten Brekkevold 26 Jun '14

26 Jun '14

The third maintenance release of the NAV 4.0 series is now available, version 4.0.3. The source code is available for download at Launchpad [1] and a new package for Debian Wheezy has been published in our APT repository [2]. Changes ======= The following reported bugs have been fixed: * LP#1255978 (Add Arnold-information in ipdevinfo Port Details) * LP#1301191 (Portadmin vlan change for many interfaces takes a long time) * LP#1318534 (Publish timestamps is set to Default when editing a Message) * LP#1321246 (vlan search result should be sorted by vlan) * LP#1321251 (search for Netbios in Machine Tracker widget) * LP#1321634 (Some alerts are never resolved when devices have moved around) * LP#1323206 (device history-link in ipdevinfo not working as intended) * LP#1324108 (arnold fails to manually detain when sysname is uppercase) * LP#1327098 (ipdevpoll jobs are marked as successful when nothing was done) * LP#1333167 (Netbox.up sometimes out of sync with actual alert-based box state) * LP#1334258 (Geomap fails to load any data if a single Graphite metric causes an error) Because the 3.15 and 4.0 series have been maintained in parallel, you may need to use the -o option if you are executing the `navsyncdb` program manually for schema upgrades. Happy NAVing everyone! Links ===== [1] https://launchpad.net/nav/4.0/4.0.3 [2] https://nav.uninett.no/wiki/nav_on_debian -- Morten Brekkevold UNINETT AS

1 0

Announcement: NAV 3.15.10 released
by Morten Brekkevold 26 Jun '14

26 Jun '14

The tenth and final maintenance release of the NAV 3.15 series has been released today, version 3.15.10. As of this release, we consider the 3.15 series to have reached its end-of-life. The source code is available for download at Launchpad [1] and a new package for Debian Wheezy has been published in our APT repository [2]. Changes ======= The following reported bugs have been fixed: * LP#1321634 (Some alerts are never resolved when devices have moved around) * LP#1327098 (ipdevpoll jobs are marked as successful when nothing was done) * LP#1333167 (Netbox.up sometimes out of sync with actual alert-based box state) Happy NAVing everyone! Links ===== [1] https://launchpad.net/nav/3.15/3.15.10 [2] https://nav.uninett.no/wiki/nav_on_debian -- Morten Brekkevold UNINETT AS

1 0

Graphite connection issues
by Ukeme Noah 06 Jun '14

06 Jun '14

Greetings Everyone, I recently installed NAV 4.0.2 on Debian (by compiling) using instructions from https://nav.uninett.no/doc/latest/intro/install.html All dependencies were installed successfully. Python modules were installed using PIP. Graphite and Carbon appear to be installed and working as well (at this point, I launch carbon and graphite using the scripts " carbon-cache.ph" and "run-graphite-devel-server.py" located in "/opt/graphite/bin". Access to NAV (as well as Graphite's) main page over a web browser present no issues however, Availability under Status reads "Graphite unreachable". In addition, the Graphite web interface presents entries for Carbon and none for NAV. I am lead to believe that the carbon backend is working given the contents of the folder "/var/lib/graphite/whisper/nav" includes entries for NAV seeded devices. On that note, any assistance/suggestions that could lead to resolving this issue would greatly be appreciated. I can provide additional information where required. Thanks, Ukeme

2 5

Announcement: NAV 4.0.2 released
by Morten Brekkevold 15 Mai '14

15 Mai '14

The second maintenance release of the NAV 4.0 series is now available, version 4.0.2. The source code is available for download at Launchpad [1] and a new package for Debian Wheezy has been published in our APT repository [2]. Changes ======= The following reported bugs have been fixed: * LP#1302403 (Unplugged HP power supplies are marked with "unknown" state) * LP#1303804 (No graphs are rendered if graphite base url doesn't end with a slash) * LP#1304279 (values in threshold alerts are always 100) * LP#1304455 (Submitting an empty search form crashes Arnold) * LP#1314503 (migrate_to_whisper.py crashes on mismatches between RRD files and database) * LP#1316091 (pping dies when carbon is unavailable) * LP#1316600 (external tools have no icons) * LP#1316965 (NAV 4.0 collects port traffic stats from EDGE devices) Because the 3.15 and 4.0 series are maintained in parallel, you may need to use the -o option if you are executing the `navsyncdb` program manually for schema upgrades. Happy NAVing everyone! Links ===== [1] https://launchpad.net/nav/4.0/4.0.2 [2] https://nav.uninett.no/wiki/nav_on_debian -- Morten Brekkevold UNINETT AS

1 0

Announcement: NAV 3.15.9 released
by Morten Brekkevold 15 Mai '14

15 Mai '14

The ninth maintenance release of the NAV 3.15 series has been released today, version 3.15.9. The source code is available for download at Launchpad [1] and a new package for Debian Wheezy has been published in our APT repository [2]. Changes ======= The following reported bugs have been fixed: * LP#1302403 (Unplugged HP power supplies are marked with "unknown" state) * LP#1304455 (Submitting an empty search form crashes Arnold) Happy NAVing everyone! Links ===== [1] https://launchpad.net/nav/3.15/3.15.9 [2] https://nav.uninett.no/wiki/nav_on_debian -- Morten Brekkevold UNINETT AS

1 0

NAV 4.0 on debian jessie/testing
by Mischa Diehm 09 Mai '14

09 Mai '14

Hi, I was just wondering if you guys also build debian packages for jessie? If yes how can I retrieve it? Thanks, Mischa -- Mischa Diehm | Network Operations Center (NOC) UniBasel | UniRechenZentrum (URZ) Klingebergstr. 70 | CH-4056 Basel Tel. +41 61 267 1574 | http://urz.unibas.ch

2 1

Integration with GIS
by Corey Thompson 09 Mai '14

09 Mai '14

Before I start doing such, I'm wondering if anyone has done any integration between NAV and a PostGIS based GIS system (mostly using QGIS for "frontend"), as I would rather add to existing work rather than repeating it...I thinking of just creating views in postgres referencing NAV data for the GIS to use to retrieve device inventory, status, and statistics in spatial queries. If it becomes successful and useful, I will do a writeup. -- Corey Thompson Technology Manager East Grand Forks Water and Light 1010 5th Avenue Northeast East Grand Forks, Minnesota 56721 218-399-3310 direct cthompson(a)egf.mn

2 1

Manually adjust topology - [interface] table changes
by davide＠wpweb.com 09 Mai '14

09 Mai '14

I read https://nav.uninett.no/doc/3.15/howto/debugging-topology.html but I can't resolve the error in topology discovering on my network. I have some Catalyst 3550 with stackable modules that automaticaly are not correclty connected. I changed the [interface] table to adjust my topology and all is okay but my changes are lost from automatic discover. How can I permanently change the [interface] table? Thank you NAV 4.0.1

3 3

Setting up NAV from scratch/non-OVA (Graphite-issues)
by Joachim Tingvold 29 Apr '14

29 Apr '14

Hi, Decided to install NAV from 'scratch' (i.e. not use the OVA-package). Got NAV running fine, but had some hiccups getting Graphite working as it should. Found no documentation on this what-so-ever (neither on the NAV-pages, or the Graphite-pages), so had to try-and-fail some. Thought I'd share. - Debian Wheezy (not OVA) - NAV via apt (from https://nav.uninett.no/debian) root@tardis:~# dpkg -s nav|grep Vers Version: 4.0.1-3 1) Fixed /etc/nav/graphite.conf; base=http://localhost:8888/ 2) Copied content of '/usr/share/graphite-web/apache2-graphite.conf' into own VHost; <VirtualHost localhost:8888> ( + add NameVirtualHost + Listen in /etc/apache2/ports.conf) 3) Set 'CARBON_CACHE_ENABLED=true' in '/etc/default/graphite-carbon' Set 'ENABLE_UDP_LISTENER = True' in '/etc/carbon/carbon.conf' Set 'SECRET_KEY = <longsecretstring>' in '/etc/graphite/local_settings.py' Set 'TIME_ZONE = '<Gallifrey>' in '/etc/graphite/local_settings.py' 4) cd /usr/share/pyshared/graphite python manage.py syncdb 5) Started carbon-cache (/etc/init.d/carbon-cache start) 6) Started NAV + apache Should work. Some of the errors I got along the road; <http://files.jocke.no/b/nav-graphite-error.txt>. -- Joachim

2 4

Setting up NAV from scratch/non-OVA (Graphite-issues)
by Joachim Tingvold 27 Apr '14

27 Apr '14

Hi, Decided to install NAV from 'scratch' (i.e. not use the OVA-package). Got NAV running fine, but had some hiccups getting Graphite working as it should. Found no documentation on this what-so-ever (neither on the NAV-pages, or the Graphite-pages), so had to try-and-fail some. Thought I'd share. - Debian Wheezy (not OVA) - NAV via apt (from https://nav.uninett.no/debian) root@tardis:~# dpkg -s nav|grep Vers Version: 4.0.1-3 1) Fixed /etc/nav/graphite.conf; base=http://localhost:8888/ 2) Copied content of '/usr/share/graphite-web/apache2-graphite.conf' into own VHost; <VirtualHost localhost:8888> ( + add NameVirtualHost + Listen in /etc/apache2/ports.conf) 3) Set 'CARBON_CACHE_ENABLED=true' in '/etc/default/graphite-carbon' Set 'ENABLE_UDP_LISTENER = True' in '/etc/carbon/carbon.conf' Set 'SECRET_KEY = <longsecretstring>' in '/etc/graphite/local_settings.py' Set 'TIME_ZONE = '<Gallifrey>' in '/etc/graphite/local_settings.py' 4) cd /usr/share/pyshared/graphite python manage.py syncdb 5) Started carbon-cache (/etc/init.d/carbon-cache start) 6) Started NAV + apache Should work. Some of the errors I got along the road; <http://files.jocke.no/b/nav-graphite-error.txt>. -- Joachim

1 1

Is there a way to change the default 10 rows in the lists?
by davide＠wpweb.com 23 Apr '14

23 Apr '14

It should be useful if I can change the default 10 rows in the "Show xx entries" in the lists. I searched through the configuration file and in the .js but I can't change this. I wish to put 50 rows or at least "all". Thank you

2 1

Problem with uplink detecion
by Martin.Jaburek＠cah.cz 22 Apr '14

22 Apr '14

Hi, I just face another problém with uplink detection. I tried to follow documentation about troubleshooting topology, but it yielded no results. I check switchport report of both connected devices and there it is showed in the columnt labeled as connected to. I also check cdp and it also report it correctly. I also found another problém when it displays an actual uplink, but with empty from device (which seems to me quite strange). In other case an uplink is showed only on one device but not the other. Is there any limit about number of uplinks? (I have more then ten uplinks on one box) Brgds Mat -----Original Message----- From: nav-users-request(a)uninett.no [mailto:nav-users-request@uninett.no] On Behalf Of Morten Brekkevold Sent: Thursday, March 27, 2014 3:09 PM To: nav-users(a)uninett.no Subject: Announcement: NAV 3.15.7 released For those of you who wish to continue running NAV 3.15 for while, the seventh maintenance release of this series is now available for download at Launchpad: https://launchpad.net/nav/3.15/3.15.7 This release fixes 12 reported issues: * LP#1251211 (portadmin wishlist: option to reset active interface whene changing vlan) * LP#1285601 (Switch ports on non-existant VLANs on Cisco switches don't appear as switch ports in NAV) * LP#1287700 (SeedDB will readily accept serial numbers with trailing spaces) * LP#1289219 (affected displays no information on nodes not in topology) * LP#1289320 (Submitting invalid alert subscription forms cause crash instead of error message) * LP#1291956 (LDAP auth against MS AD broken since NAV 3.14.1592653) * LP#1291978 (User supplied login name is not escaped in LDAP search filters, causing possible injection vulnerabilities) * LP#1292513 (sysname/reverse dns lookups are inconsistent or lacking after a bulk import) * LP#1293621 (missing cascade in table accounttool) * LP#1295092 (Only modules and power supplies on first member are collected from stacked HP 2920) * LP#1297200 (powersupplywatch crashes when there are more than ~1024 devices to poll) * LP#1297767 (Django exposes sensitive data like: username/password) Please report further bugs at https://launchpad.net/nav/+filebug A binary package for Debian Wheezy has been made available in our APT repository, as usual. Happy NAVing everyone! -- Morten Brekkevold UNINETT AS

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users