Nav-users

nav-users@lister.sikt.no

1379 discussions

Removing HP SwitchStack support from NAV
by Morten Brekkevold 17 Sep '08

17 Sep '08

Hi everyone, for quite some time we've been aware of many fundamental problems with the way support for HP SwitchStacks has been implemented in NAV. HP SwitchStack support was implemented in NAV 3.0 at NTNU, whose HP equipment consisted solely of HP SwitchStacks at that time. The result is code which is heavily biased towards SwitchStacks, to the point that NAV thinks HP devices are always SwitchStacks, no matter what. While we have been pondering alternative ways to model HP SwitchStacks (and consequently, Cisco switch clusters, which are basically the same thing), NTNU has entirely stopped using SwitchStacks. Today, they're experiencing bad side effects of the existing HP-related code in NAV. They're using some HP devices for routing, which NAV cannot handle at all (because of said "HP=SwitchStack only" view). No router ports are collected for these routers. Also, they seem to have many errors in topology information when HP devices are involved. Realizing that NTNU have stopped using SwitchStacks, we also do not know of anyone else who does, so now we are considering dropping support for SwitchStacks entirely from NAV. This way, the existing NAV code can treat HP devices like everything else. Preliminary tests of these changes at NTNU show promising results. So my question to the users of NAV is: Does anyone actually use virtually stacked HP switches? Will anyone miss support for this if removed from NAV? If there is no feedback on this issue, we will likely remove this support starting from NAV 3.5. -- mvh Morten Brekkevold UNINETT

2 3

Re: Announcement: NAV 3.4.2 released
by Tim Chown 12 Sep '08

12 Sep '08

On Wed, Sep 10, 2008 at 11:26:36AM +0200, Morten Brekkevold wrote: > > The SQL script fails because of a typo, i.e. a line was appended after > a line that it was meant to replace, causing an SQL error. > > For more details on this bug, see > https://bugs.launchpad.net/nav/+bug/260330 , which is part of NAV > 3.4.3, slated for release next week. > > You can fix it yourself by simply deleting the first of the two > WHERE-lines, as commented by Kristian Klette here: > https://bugs.launchpad.net/nav/+bug/260330/comments/1 Thanks, that appears to have run fine. -- Tim

1 0

Re: Announcement: NAV 3.4.2 released
by Tim Chown 10 Sep '08

10 Sep '08

On Tue, Sep 09, 2008 at 03:31:00PM +0200, Morten Brekkevold wrote: > On Tue, 9 Sep 2008 13:58:07 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > > Is there any gotcha to doing a straight aptitude update from a previous > > version (3.4.1) to the new version on a live system? > > There shouldn't be. But make sure to do a "/etc/init.d/apache2 > force-reload" after the upgrade, to make sure Apache/mod_python is > using the new NAV code. The upgrade seemed to work fine. I followed the info about the sql update but got errors: # psql -f 3.4.2.sql manage nav Password for user nav: BEGIN CREATE RULE CREATE RULE CREATE RULE psql:3.4.2.sql:46: ERROR: syntax error at or near "WHERE" at character 1 psql:3.4.2.sql:46: LINE 1: WHERE key='serviceid' AND value=old.serviceid::text; psql:3.4.2.sql:46: ^ ROLLBACK We have psql 8.1, but I assumed the patch was required because we did install 3.4.1 from scratch. The comment in the patch file also says "NAV 3.4.1 and 3.4.1 were shipped with a manage.sql..." which I assume should say "NAV 3.4 and 3.4.1". Is the patch failing because we don't need it, or some other issue? :) Thanks, -- Tim

2 1

Re: Announcement: NAV 3.4.2 released
by Tim Chown 09 Sep '08

09 Sep '08

Hi, Probably an unecessary question, but we'd like to be sure... Is there any gotcha to doing a straight aptitude update from a previous version (3.4.1) to the new version on a live system? We have deb http://pkg-nav.alioth.debian.org/debian/ etch local as our source. Thanks, -- Tim

3 2

Announcement: NAV 3.4.2 released
by Morten Brekkevold 09 Sep '08

09 Sep '08

NAV 3.4.2 is now available for download at SourceForge: http://sourceforge.net/projects/nav/ This is a bugfix release, the changelog is attached to this message. Binary packages for Debian will be hopefully be available soon. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. Morten will most likely be on vacation and paternity leave for most of August, so we can't make any promises. FWIW, the Debian 3.4.1 package already contains the fixes for the database issues (manage.sql) mentioned earlier on this list; these issues are the most important ones addressed by the 3.4.2 version. For those upgrading their existing NAV installation, please see the added section about upgrading to 3.4.2 in the attached release notes. Happy NAVing everyone! -- mvh Morten Brekkevold UNINETT

2 1

Feature request hidden in Launchpad?
by Stokkenes Vidar 05 Sep '08

05 Sep '08

Hello, I might be the one not searching good enough, but I couldn't really find anywhere to put a feature request on Launchpad. As I've seen quite a few suggestions on stuff on this list, I might as well give it a shot here. One of many NAV features we've found handy, is the Module State warning feature. What I really don't understand, is why NAV haven't built in a PSU State warning system. There are numerous of MIBs under the CISCO-ENVMON-MIB <http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName…> tree for this task. A Cisco specific MIB for the general PSU status would be "1.3.6.1.4.1.9.9.13.1.5.1", and would give you the following result on: Cisco 65XX series: SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.1 = STRING: "Power Supply 1, WS-CAC-2500W" SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.2 = STRING: "Power Supply 2, WS-CAC-2500W" SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.1 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.2 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.1 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.2 = INTEGER: 2 Cisco 35XX series: SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.1003 = STRING: "Sw1, PS1 Normal, RPS NotExist" SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.1003 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.1003 = INTEGER: 2 Cisco 45XX series: SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.1 = STRING: "Power Supply 1" SNMPv2-SMI::enterprises.9.9.13.1.5.1.2.2 = STRING: "Power Supply 2" SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.1 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.3.2 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.1 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.13.1.5.1.4.2 = INTEGER: 2 The status integers for the power supply MIB are pretty much alike the Module State warning integers, so implementing such a feature wouldn't be a big problem. And the graphical interface/warning would look pretty much the same as the Module State thing when browsing a device, or as a Power Supply failure on the Status page.. I don't know about others, but I like to get a warning when my power equipment fails, or we're having a power failure :) Any thoughts? ------------------------------------------------------ Vidar Stokkenes Konsulent Nettverk Seksjon for nettverk og telekom HN IKT - Tromsø Tlf: 76 16 61 87 / 77 66 99 55 Mobil: 95 87 99 42 e-post: vidar.stokkenes(a)hn-ikt.no<mailto:vidar.stokkenes@hn-ikt.no> [cid:image001.png@01C90F3D.BA283A30]

3 4

Re: Question on SNMP/tempInlet
by Tim Chown 05 Sep '08

05 Sep '08

On Fri, Sep 05, 2008 at 09:42:44AM +0200, Morten Brekkevold wrote: > > > > # The e-mail address of the NAV system administrator. All cron error > > # messages will be sent to this address. > > ADMIN_MAIL=systjc(a)ecs.soton.ac.uk > > > > I suggest you add another option > > > > CRON_MAIL=.... > > > > so you can still have an admin contact on the NAV system/web view, but > > direct cron stuff easily to nowhere. Or maybe a variable for just the > > Cricket cron outputs if NAV cron output is useful :) > > The ADMIN_MAIL setting has no relation to what is displayed as a > contact anywhere on the NAV web; that's just regular HTML configured > by the administrators in the webfront config/template files. > > The point of ADMIN_MAIL is to have something to fall back to if all > other methods of getting attention fail. Ah my bad, I assumed the contact info that by default is bottom right of the NAV home was take from there. But it isn't :) > One thing you can do is edit /etc/nav/cron.d/cricket and redirect > everything from the collect-subtrees cricket command to /dev/null and > then run "nav restart cricket" to reinstall the cron snippet into > navcron's crontab. > > If you do that, you can still find cricket's messages in its log > files. It's default loglevel is more verbose than just error > messages, so you'd either have to grep the logs for errors or adjust > the loglevel in cricket-conf.pl. Nice tip, thanks. -- Tim

1 0

Re: Question on SNMP/tempInlet
by Tim Chown 05 Sep '08

05 Sep '08

On Thu, Sep 04, 2008 at 10:11:39AM +0200, Morten Brekkevold wrote: > On Thu, 28 Aug 2008 15:18:12 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > >> b1-l1-cat1 may have indexed one of its temperature sensors as 1 > >> during the initial import into NAV, and then changed its mind at a > >> later time. That would account for the problem you're having. > > > > Thanks for the explanation. What then is the recommended way to > > suppress errors related to this OID? NAV kindly generates email > > alerts for errors when querying devices, we just have a few too many > > related to this OID :) > > There is no recommended way, really. Cricket is a noisy fellow, > complaining about every little thing that annoys it, and since it > normally runs every five minutes, it annoys the heck out of many a > sysadmin during the course of a day. Now I realise why it is called cricket. Nothing to do with the game :) > Most installations I've run into either direct cron-mail from Cricket > into /dev/null, or put it into a mailbox they check less often than > their inbox. It's output is not all terribly useful. OK, so a suggestion is that in nav.conf you currently have (for example): # The e-mail address of the NAV system administrator. All cron error # messages will be sent to this address. ADMIN_MAIL=systjc(a)ecs.soton.ac.uk I suggest you add another option CRON_MAIL=.... so you can still have an admin contact on the NAV system/web view, but direct cron stuff easily to nowhere. Or maybe a variable for just the Cricket cron outputs if NAV cron output is useful :) > > Is there a recommended way to configure NAV to not poll our 3750 > > stacks for temp data? > > You could re-profile them and see whether NAV notices that they don't > support that OID anymore. Thanks for the explanation, it does help a lot to understand it, though reprofiling had no effect :/ > > A week ago I knew far less about OIDs and I think I was better for > > it :) > > Welcome to the wonderful world of SNMP ;) We've just started looking at our 1230 series Cisco APs and including them in NAV. Fun with OIDs there too. I think that will be for a separate mail later ;) Thanks again for the excellent support/explanations. -- Tim

2 1

Re: Device names query
by Tim Chown 04 Sep '08

04 Sep '08

On Thu, Sep 04, 2008 at 10:52:14AM +0200, Morten Brekkevold wrote: > On Thu, 28 Aug 2008 15:31:01 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > > Regarding the database change offer, we'd be up for trying it if you can > > provide the magic incantation :) > > Sure, these two statements should reset the sysname of all CAM/ARP > entried related to devices which are registered in your NAV at the > moment: > > UPDATE arp SET sysname=n.sysname FROM netbox n WHERE n.netboxid=arp.netboxid; > UPDATE cam SET sysname=n.sysname FROM netbox n WHERE n.netboxid=cam.netboxid; > > You can connect to the database using the psql command line tool, > e.g. "psql manage nav" to connect to the manage database as the nav > user. Use the password from NAV's db.conf. > > I must warn you that these statements can be quite slow, depending on > the number of records you have in the two tables. If you have made > any actual device renames during NAV's runtime, these devices' records > will also be falsified by these statements. We have only been running for a month or so on 15 stacks, so it was actually very quick :) manage=> UPDATE arp SET sysname=n.sysname FROM netbox n WHERE n.netboxid=arp.netboxid; UPDATE 12824 manage=> UPDATE cam SET sysname=n.sysname FROM netbox n WHERE n.netboxid=cam.netboxid; UPDATE 68724 As far as we can see, all the old historic IP-names are now updated to names, which has added consistency to the searches and machine tracker. Many thanks :) > > If you want to use this essentially as a way to test how you'd add a > > conversion option to NAV, we're happy to test. > > I don't think we want that. We value the historic accuracy of cam and > arp records; we'd rather make sure the machine tracker can search > records across name changes. I agree - the above fix is a useful tip for when a new site like us doesn't have reverse DNS capability in place before firing up NAV, to 'clean' the data. -- Tim

1 0

Re: Device names query
by Tim Chown 04 Sep '08

04 Sep '08

On Thu, Aug 28, 2008 at 03:51:51PM +0200, Morten Brekkevold wrote: > On Fri, 22 Aug 2008 15:43:25 +0100 Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > > > We since ensured the names resolved, and NAV figured this out, with > > new data being linked to the devices by name, rather than the 'IP name'. > > > > The problem seems to be though that the 'IP name' causes some problems > > when searching on data, e.g. a search based on the new name won't > > match against the old 'IP name'. > > > > Is there a neat way to fix this? e.g. perhaps to simply remove all records > > for the 'IP name' devices? > > You didn't specify what you mean by "data" and searching said "data", > but I will assume you are referring to the Machine Tracker. > > CAM and ARP data are basically stored as logs in the database and used > by the Machine Tracker. Since a CAM/ARP entry in NAV is a historic > record, it retains historic names of the originating devices. > > When you search for a sysname in Machine Tracker, it searches for > records matching that exact/partial name. > > We do however store a reference to the IP device record of the > originating device with each CAM/ARP entry. As long as an IP device > stays registered in NAV, any name changes can be inferred from its > recorded CAM/ARP data. Once the IP device is removed from NAV, the > historic CAM/ARP data remains, but can no longer be used to infer name > changes over time for that particular device. > > So, in short, we could actually add a feature to the Machine Tracker > to find CAM/ARP entries recorded under other names than the one used > in the search form. You're welcome to add this as a wishlist priority > item at https://bugs.launchpad.net/nav if it sounds like something you > would want. I suspect a few people will make the smae 'mistake' that we did, to enter systems by name, but these are converted to IP-names because a reverse lookup is not available. I think this warning was in the small print of the docs, but we were too excited during install and missed it. We'll check out the new bugtracker very soon! Regarding the database change offer, we'd be up for trying it if you can provide the magic incantation :) The switch stacks are: 10.78.64.61 b86-l1-cat1 10.78.64.63 b59-l2-cat1 10.78.64.64 b59-l3-cat1 10.78.64.65 b59-l4-cat1 10.78.64.66 b1-l1-cat1 10.78.64.67 b16-l2-cat1 10.78.64.68 b1-l1-cat2 10.78.64.69 b32-l3-cat1 10.78.64.70 b32-l3-cat2 10.78.64.71 b32-l4-cat1 10.78.64.72 b32-l4-cat2 10.78.64.75 b59-l3-cat2 10.78.64.76 b53-l2-cat1 10.78.64.77 b53-l3-cat1 10.78.64.78 b53-l4-cat1 10.78.64.79 b53-l4-cat2 Some were added after we arranged reverse DNS to work (added a local /etc/hosts entry for convenience) so may not have the problem, but most of them do. If you want to use this essentially as a way to test how you'd add a conversion option to NAV, we're happy to test. -- Tim

3 2

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