Nav-users

nav-users@lister.sikt.no

1372 discussions

New user, cron error, some confusion, debian lenny-test packages
by Nils Olav Fossum 11 Jan '10

11 Jan '10

Hi, Something must have stopped over night as I have gaps in cricket graphs and all lines in netmap have gone grey. Im not sure if this has was the case at previous nights. Im using the lenny-test packages on Debian Lenny. Running "/usr/share/cricket/collect-subtrees normal" as navcron I get these messages: --- snip --- Error and the lines leading up to it: [06-Jan-2010 11:45:17 ] Retrieved data for 10.0.20.2 (): 0,0,45486572,20045736,17856320 [06-Jan-2010 11:45:17 ] Retrieved data for 10.7.0.11 (): 0,0,0,0,48601868,6105112,2442848594 [06-Jan-2010 11:45:18 ] Retrieved data for 10.7.0.9 (): 9,8,81827916,35395284,1346517318,26 Use of uninitialized value in split at /usr/share/cricket/collector line 274. [06-Jan-2010 11:45:18*] Could not find any datasources for target type 10.7.0.10. [06-Jan-2010 11:45:18*] No data retrieved. Skipping RRD update. --- snip --- And the list goes on. This is the line in usr/share/cricket/collector: 274 my(@targetDSs) = split(/\s*,\s*/, $ttRef->{'ds'}); I hope someone can give me a clue where to look.. mvh Nils Olav Fossum

2 3

installation on ubuntu 9.04
by vvatikiotis＠gmail.com 07 Jan '10

07 Jan '10

Hello all, I'm trying to install nav on ubuntu 9.04 and this fails cause of 2 (only 2) dependency failures. a) python < 2.5. 9.04 has python 2.6. b) postgress = 8.1. Ubuntu has postgres 8.3 Is it necessary to pin these 2 dependency versions ? I have knowledge of python but I'd assume that 2.6 is good enough against 2.5 source code. Same goes for postgres Correct me if I'm wrong. In the mean time I'l try to force install nav. btw, seems VERY promising. thx all vassilis

4 4

Temperature OID on SW, how to exclude it from cricket
by Jan I. Ellertsen 06 Jan '10

06 Jan '10

Hello all I have an issue with SW boxes, and nav/cricket tryes to collection data from an not existing oid 1.3.6.1.4.1.9.9.13.1.3.1.3.1 We use Catalyst 3560E switches as core building switches, and therefor I want to put them in SW mode for having them on the netmap. Does anyone know where I set that I do not want that OID polled on a 3560 switch ? -- Regards; Jan I. Ellertsen phone w:+4755584009 f:+4755584070 desk:+4755584201 e-mail: Jan.Ellertsen(a)uib.no - IT-Dept, University of Bergen.

2 2

Possible maintainers of a Redhat/EPEL NAV package
by Stokkenes Vidar 25 Nov '09

25 Nov '09

Hello everyone, This is probably a very delicate request, so I'll try to keep myself short. Due to our companys policies, we are trying to run everything in production on Redhat Linux servers. This is a problem when it comes to NAV, as the maintainer of the old Redhat RPM package is MIA, and no one else have really stepped forward to continue his work. I am aware of that compiling NAV from source is a viable option for someone, but considering I'm a repository maniac I would like to see Redhat on a somewhat "public" Redhat repository. We are currently undermanned and don't really have time to develop or maintain the package ourselves. However we do have resources to hire an external consulant to make the package for us. So therefor I am wondering. Lets say we hire someone to get NAV packed for Redhat Linux and submit it to EPEL, are there anyone more RPM/EPEL experienced than me who are interested in maintaining and committing new changes to the package? I've already contacted consulants at (Linpro) Redpill and gotten a time/cost estimate to develop the package. Now I just need someone volunteers to maintain the package once it's been initially set up (preferably people with commit access on EPEL) Any help or inputs would be appreciated! Best regards, ------------------------------------------------------ Vidar Stokkenes Networking Consulant Networking and telecom Department Helse Nord IKT - Tromsø Phone: (+47) 76 16 61 87 or (+47) 77 66 99 55 Cell: (+47) 95 87 99 42 e-mail: vidarst(a)hn-ikt.no

1 0

Cabling and patch data removed in NAV 3.6?
by Vidar Faltinsen 13 Nov '09

13 Nov '09

nav-users, As you might know there is ongoing work on preparing a NAV 3.6beta. In 3.6 there are some changes to the database, i.e the interfaces will now relate directly to the netbox (switch or router), not to a module. We will still keep module information, but the strict mapping from interface to module is changed. This effects a number of front end (and back end) tools and we are in the process of updating it all. One system that is effected is the seed database subtool where you can add data on your twisted pair cabling and your patches from switch to jack in the wiring closets. We are seriously considering _not_ to maintain/keep this tool from 3.6. Our feeling is that _not_ many people use this part of NAV. It has never given full effect since the machine tracker does not include these data in its search results (which has been our intention of course). We also argue that by using sensible interface description naming standards you will in effect document the same data. I.e. if you set the jack number and room number as description of the switch ports that are patched to your end users/offices you have these data. The "details" link under interface in the MAC search results in machine tracker give this information (it displays the interface view of ip device info). In my opinion you should in fact do this documentation as part of your interface description, because this is useful when working directly with the switch through the CLI. Should you then double the work and do it both in the seed database patch register in addition?... Another argument is that other systems do cabling documentation more comprehensive. NAV has i.e. no support for documenting your fibre cabling. A system like Telemator (http://www.mxdata.no/) or equivalent cabling information systems do this better. Looking at integration between these systems and NAV is of course interesting. I know the University of Tromsø has done some interesting work here. Yet another mishap with the NAV patch register is that when you replace your switch with a new one, you will in the process loose your patch data for the switch and will have to do this registering from scratch again. So people out there - who is going to miss the patch and cabling part of NAV? Best regards, - Vidar

1 0

Re: EdgeCore ES4612 no port info
by Morten Brekkevold 10 Nov '09

10 Nov '09

On Mon, 09 Nov 2009 14:49:55 +0200 Kostua <kostua(a)innkom.zp.ua> wrote: >> I hope I will find something useful from the getDeviceData.log that >> can tell me why this happens. >> >> > ok, done. sending attachment. [...] > Nov 08 10:34:57 2009 172.16.2.49_13 CGW_DEVHANDLER-4-PROCESS_CGW Oidkeys [ifDescr, ifSpeed] are required, but not supported by 172.16.2.49, type ES4612, unable to fetch data! This tells me that the OID profile of the device is lacking, for some unknown reason. Please browse to Toolbox -> Report and search for 172.16.2.49 in the "IP Device Report" search box. What is the number in the "snmp" column? What is the list of oidkeys reported when you click on the number in the snmp column? To make getDeviceData re-profile the device, browse to Toolbox -> SeedDB -> IP Devices Edit, find 172.16.2.49 and edit it. Don't change anything, just click the "Update" button and finish the procedure. To speed things up, you can then restart getDeviceData. Tail getDeviceData.log and verify that you get several log messages from OID_TESTER about 172.16.2.49. When the messages stop appearing, please check the snmp column in the IP device report again. -- mvh Morten Brekkevold UNINETT

1 0

Re: EdgeCore ES4612 no port info
by Kostua 06 Nov '09

06 Nov '09

Ok. I recently moved NAV from vmware to dedicated server, and Cricket began to draw traffic graph. In "IP Device Info" show right numbers of ports (8) but port status of all ports indicated "Not active"

2 1

FYI: FreeBSD and XMPP
by Ingeborg Hellemo 21 Okt '09

21 Okt '09

In case someone wants to configure XMPP on FreeBSD the correct python-library to install is net-im/py-xmpppy (not net-im/py-pyxmpp...) --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no Dep. of Information Technology --- Univ. of Tromsø

1 0

Re: VS: Radius service monitor
by Istvan Bernath 16 Okt '09

16 Okt '09

Thanks for the kind reply! Right now all our active switches are registered in NAV. There are about 130 pcs. 2510-48 and a couple of 2600-8, 2610, 2626, 2650, 2810 and 2824. The core switches are two 5406 and a single 5412. Traffic data is collected from the switches correctly. Statistics are presented fine via Cricket. Alerts, like firmware upgrade and cold start, are all noticed via Alert Manager as it should. Topology right now is totally missing, but luckily I've cached a hint of topology with a single 2824 in the middle and one 2626 one 2650 and a 2510 as the neighbors before my colleague, sorry to say, have updated to the latest firmware. The magic surely was, that the 2824 had a complete CDP and LLDP implementation in the old firmware, while all the new HP firmware has only a crippled Receive Only CDP implementation. The missing topology is rather crucial since we can be flooded by SMS and mails in case a box at the top fails. MAC information is collected, so it is possible to find a MAC number belonging to an IP number, but the MAC is not associated to any switch port, so we can not trace MAC, and use Arnold. Service monitoring is rather important for us, since our server people do need a better identification of a functioning server than a simple ping. Needless to say that a process can fail while the server still is pingable. Right now we are monitoring DNS, HTTP, IMAP, SMB, SMTP with success. The only service we are missing, for the time beeing, is the RADIUS. If I can help the developers with any tests, I would be more than happy to do it! Thanks again! Istvan >>> Morten Brekkevold <morten.brekkevold(a)uninett.no> 10/15/09 11:14 AM >>> On Fri, 02 Oct 2009 12:12:41 +0200 "Istvan Bernath" <ibe(a)life.ku.dk> wrote: > Sorry about the inconvenience! > > I've been on the sidelines in the past 3 years, receiving all > messages from the nav-users list and running a maintained and > updated test installation all that time. > > To my pleasure this time it will be official, and the Faculty of > Life Sciences, Copenhagen University gives NAV a chance as the > global monitoring tool of all the new HP 2510 switches our net is > now upgraded to. Music to my ears. Although I'm curious as to how NAV will perform on an all HP network. We've had some problems with HP in the past. Not all of them are completely behind us, but they hopefully will be in NAV 3.6. > Monitoring of several services will also be crucial. NAV's service monitoring capabilities have been somewhat downplayed by UNINETT, due to lack of resources. We've left maintenance of those systems in the capable hands of the University of Tromsø. Hopefully, their developers can answer your questions, as I don't know radius or the service monitor all that well. I've prodded one of their guys to look at your servicemon question. > I have though problems with monitoring the Radius service, and booth > topology and MAC behind a port do not work with the new HP ProCurve > switches. Your topology problems are intriguing. Are you experiencing a total lack of topology information, or just plain wrong topology? I've had reports of the latter from other HP-heavy installations. Are you able to search any MAC data for any of your switches? > I hope somebody can help me rectifying the last problems. It might take some Q&A, but hopefully we can be of assistance :) -- mvh Morten Brekkevold UNINETT

3 2

Re: VS: Radius service monitor
by Istvan Bernath 15 Okt '09

15 Okt '09

Sorry about the inconvenience! I've been on the sidelines in the past 3 years, receiving all messages from the nav-users list and running a maintained and updated test installation all that time. To my pleasure this time it will be official, and the Faculty of Life Sciences, Copenhagen University gives NAV a chance as the global monitoring tool of all the new HP 2510 switches our net is now upgraded to. Monitoring of several services will also be crucial. I have though problems with monitoring the Radius service, and booth topology and MAC behind a port do not work with the new HP ProCurve switches. I hope somebody can help me rectifying the last problems. Kind Regards Istvan

2 1

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