Nav-users

nav-users@lister.sikt.no

1372 discussions

Anna Liu/Almaden/IBM is out of the office.
by Anna Liu 07 Okt '08

07 Okt '08

I will be out of the office starting 09/26/2008 and will not return until 10/17/2008. I will respond to your message when I return.

1 0

Announcement: NAV 3.5.0b1 released
by Morten Brekkevold 07 Okt '08

07 Okt '08

NAV 3.5.0b1 is now available for download at Launchpad: https://launchpad.net/nav/3.5/3.5.0b1 This is a beta test release of the new features in the 3.5 series; the changelog is attached to this message. While we do already have four dedicated beta testers, we could always do with more. Please register at Launchpad and report all bugs at https://bugs.launchpad.net/nav . Binary packages for Debian will be available soon. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. For upgrading from 3.4, it is important that you remember to merge your databases into a single NAV database before running the regular SQL upgrade procedure. See the release notes for more information. Happy NAVing everyone! -- mvh Morten Brekkevold UNINETT

1 0

Problem with services
by hugo.doria＠tjse.jus.br 22 Sep '08

22 Sep '08

Hi, I just setup nav. I can access the webpage and panel administration. The problem is: None of the services i added is being showed in nav's webpage. Also, all services are down . I followed these instructions: http://metanav.uninett.no/seedessentials What's wrong? -- Hugo

2 1

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

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