Nav-users

nav-users@lister.sikt.no

1 participants
1378 discussions

Feature request - list more info about SRVs
by Ingeborg Hellemo 02 Sep '08

02 Sep '08

Most of our boxes of type SRV has a "Function" associated with it. This field can be seen via https://.../report/netbox?catid=SRV but not when you browse the individual box. Is it possible to add this field (together with Type, Organisation etc) to the output on <https://.../browse/foo.uit.no/) (and in the new <https://.../ipdevinfo/foo.uit.no/>) ? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg(a)cc.uit.no (Univ. of Tromsø, Norway)

2 3

Re: Unexpected link into ipdevinfo beta code?
by Tim Chown 28 Aug '08

28 Aug '08

On Thu, Aug 28, 2008 at 03:08:40PM +0200, Stein Magnus Jodal wrote: > On Thu, 2008-08-28 at 15:01 +0200, Morten Brekkevold wrote: > > The simplest way (and least intrusive) way of adding the permission to > > a running NAV installation is to add a new web_access privilege to the > > following regex pattern: ^/ipdevinfo/? > > > > That is also the only useful way to automatically update the > > permissions while upgrading to the next release, Stein Magnus. > > Upgrades should not touch existing privileges, only add new ones. > > On second thought, this is rather obvious and clearly the best way. I've > just changed the trunk.sql upgrade script in the ipdevinfo branch to > insert a new privilege instead of updating the old one. I edited the permissions as suggested, and now have a python error when clicking on the (details) link, so I guess some template file is missing somewhere or can't be read because wider permissions need to be added too? Here's the error: --- start --- Mod_python error: "PythonHandler django.core.handlers.modpython" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/var/lib/python-support/python2.4/django/core/handlers/modpython.py", line 189, in handler return ModPythonHandler()(req) File "/var/lib/python-support/python2.4/django/core/handlers/modpython.py", line 162, in __call__ response = self.get_response(request) File "/var/lib/python-support/python2.4/django/core/handlers/base.py", line 108, in get_response return callback(request, **param_dict) File "/var/lib/python-support/python2.4/django/views/defaults.py", line 79, in page_not_found t = loader.get_template(template_name) # You need to create a 404.html template. File "/var/lib/python-support/python2.4/django/template/loader.py", line 79, in get_template source, origin = find_template_source(template_name) File "/var/lib/python-support/python2.4/django/template/loader.py", line 72, in find_template_source raise TemplateDoesNotExist, name TemplateDoesNotExist: 404.html --- end --- I guess I should file a bug, but since we have a discussion running... :) -- Tim

2 1

Device names query
by Tim Chown 28 Aug '08

28 Aug '08

Hello again :) Hopefully a quicker query. When we first set up NAV, our networked devices, with their Net10 addresses(*), did not resolve to names, so our database populated with device names that were IP addresses. 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? Advice welcomed. -- Tim (*) historic reasons :)

2 2

Question on SNMP/tempInlet
by Tim Chown 28 Aug '08

28 Aug '08

Hi, I noticed our cricket cron is generating errors on one SNMP OID, i.e. [14-Aug-2008 14:40:01 ] Retrieved data for b1-l1-cat1 (): U,U,U,U,U,U,U,U [14-Aug-2008 14:40:01 ] Some data is missing for b1-l1-cat1 (). [14-Aug-2008 14:40:01*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1 Error and the lines leading up to it: [14-Aug-2008 14:40:01 ] Some data is missing for b1-l1-cat1 (). [14-Aug-2008 14:40:01*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1 And yet if I look at the SNMP OID support listed for the device as reported by NAV I see: b1-l1-cat1 tempInlet 1.3.6.1.4.1.9.9.13.1.3.1.3.1 CISCO-ENVMON-MIB ciscoEnvMonTemperatureStatusValue 21600 which implies the OID is supported, and is the device inlet temperature. Is there some additional IOS config required to make this particular data available to Cricket? Being new to OIDs, I'm confused as to why it seems to be available according to NAV, yet Cricket's getting an error. Thanks :) -- Tim

2 1

Unexpected link into ipdevinfo beta code?
by Tim Chown 28 Aug '08

28 Aug '08

Hi, One of our admins spotted this, not sure if a bug or feature, so not submitted it (yet) to the bug tracker. If you drill down, as an Authenticated User, into Machine Tracker / MAC Search / MAC Search results and then click the (details) link for an interface you are jumped into the /ipdevinfo code, and taken out of the main browse/report code. Since the default permissions for an Authenticated User does not include ipdevinfo, the user gets a permission denied :( I think the (details) link should take you to a link like /browse/b59-l2-cat1/module3/port1846/ rather than one like /ipdevinfo/b59-l2-cat1/module=3/swport=GigabitEthernet3/0/44/ but I assume this has been done in part to test the ipdevinfo beta code? Both pages seems to serve a similar function, one the old way, one (I assume) the new way under development? (The ipdevinfo page doesn't have the Cricket links in place yet) The problem is that Authenticated Users hit this permissions issue, but if we try to add |ipdevinfo| into the web_access permissions, it doesn't seem to resolve the permissions problem. Is that link to the newer stuff intended? If so, how should we correct the permissions problem? Thanks :) -- Tim

3 3

Unsupported SNMP protocol error on Cisco devices
by Christian Baensch 28 Aug '08

28 Aug '08

Hello, we have got some problems to add our Cisco routers to the database: Error: nav.Snmp.UnsupportedSnmpVersionError: Unsupported SNMP protocol version: 0 Unfortunately it happens to all our Cisco routers but not the Cisco switches. This Error Notify already occured in your mailling list with the hint: jar -tf /usr/local/nav/lib/java/SimpleSnmp.jar This is our output: nav:~# jar -tf /usr/local/nav/lib/java/SimpleSnmp.jar META-INF/ META-INF/MANIFEST.MF no/ no/ntnu/ no/ntnu/nav/ no/ntnu/nav/SimpleSnmp/ no/ntnu/nav/SimpleSnmp/SimpleSnmp.class no/ntnu/nav/SimpleSnmp/SimpleSnmpHP.class no/ntnu/nav/SimpleSnmp/TimeoutException.class What can we do? We are running actually NAV 3.3.3 with SunJava 1.4.2. Thanks in advance! With kind regards Christian Baensch -- Christian Baensch, Kommunikationssysteme Friedrich-Alexander-Universitaet Erlangen-Nuernberg, Germany Regionales Rechenzentrum Erlangen (RRZE) christian.baensch(a)rrze.uni-erlangen.de www.rrze.uni-erlangen.de

4 4

Re: Questions on prefixes and traffic maps
by Tim Chown 22 Aug '08

22 Aug '08

On Wed, Aug 20, 2008 at 07:25:40PM +0200, Vidar Faltinsen wrote: > Tim Chown wrote: > > >When we do add the 6509, how should we enter the prefix/scope information? > >I'm a little confused as to the meaning of static/reserved/scope for the > >'Add prefix' option in the Edit Database. We have maybe 25 vlans and > >subnets, and I assume we need to add them all here. I assume we use > >'scope' for devices we manage? > > When you add a router to NAV with ditto subnets, you simple add the > router (add IP device in Edit Databe) as category GW or GSW (the latter > if it also has layer 2 switch ports, in which a 6509 typically has). > > The subnets will then be autodetected and added to NAV. In cases where > the interfaces are virtual, NAV will also derive the subnet to vlan > mapping, i.e. Interface Vlan10 is a routerport for vlan 10. Hi Vidar, thanks for the explanation. That is indeed what happened when we added our router device(s). The vlan database was also populated and we can still edit scope data via the vlan editor (the two are quite closely coupled :) > You do not have to add a scope to NAV, if you do you do it for one > reason only, to give outer scope information to "the IP address scope - > graphical view" linked from the report tool. Read; > http://metanav.uninett.no/reporttool#ip_address_scope_-_graphical_view Ah, OK, so (for example) we could manually add our campus prefix of 152.78.0.0/16 and the other scopes would then be listed underneath (whether manually entered or autodiscovered)? That's nice. > >Second main question is on the traffic maps. It seems at first glance > >that these show traffic between router interfaces. Is it possible to > >have the traffic map show loads between trunk ports that connect switch > >stacks? That would be very useful for us if it could be configured. > > The traffic map of today is soon to be replaced with a new one, and this > will be able to show the traffic between trunk ports. When I say soon, > hopefully 3.5 in September, it may not be feature complete at that time, > but hopefully this will be in place. That would be really useful :) > You may be able to see the trunk port traffic on todays map as well if > you drill down on a relevant subnet to see the layer 2 structure. The information as you imply is all there, 'just' need a view of it. Certainly enjoying exploring NAV, it's very useful so far, many thanks for all the team's work on it :) -- Tim

1 0

Bugtracker moved from Sourceforge to Launchpad
by Kristian Klette 20 Aug '08

20 Aug '08

Hi all NAVers! Our new bugtracker is located at http://bugs.launchpad.net/nav All of the bugs that were reported on Sourceforge was imported, so all the data should be there. To simplefy bug-reporting for developers and other console-junkies, the nav-tip[0] now has a small tool called nav_bug.py in the contrib folder. Add this tool to your path and run nav_bug.py --help for more info about how to use the tool. I hope you all will enjoy using a more up-to-date bugtracker, and help us making NAV even better! - Kristian Klette [0]: http://metanav.uninett.no/hg/default -- Mvh Kristian Klette «Programs for sale: Fast, Reliable, Cheap: choose two.»

2 1

Questions on prefixes and traffic maps
by Tim Chown 20 Aug '08

20 Aug '08

Hi NAVers, We've just installed NAV on a Debian4 r3 system for our department network that has a core Cisco 6509 and a number of satellite 3750 stacks and Cisco wireless APs. At present our 3750 stacks are switching only, and thus in NAV we entered them as SW devices (Layer 2, many vlans). So far in NAV we have enabled monitoring of our 3750 stacks, but not yet the core 6509, so we only have layer 2 info/configs. We're getting data now for our switch port use, and cricket showing info on packet rates through the ports. When we do add the 6509, how should we enter the prefix/scope information? I'm a little confused as to the meaning of static/reserved/scope for the 'Add prefix' option in the Edit Database. We have maybe 25 vlans and subnets, and I assume we need to add them all here. I assume we use 'scope' for devices we manage? I notice we cannot add vlans directly; I assume this is implied from the vlan information added in the prefixes? Second main question is on the traffic maps. It seems at first glance that these show traffic between router interfaces. Is it possible to have the traffic map show loads between trunk ports that connect switch stacks? That would be very useful for us if it could be configured. Thanks for any comments or suggestions/tips! -- Tim

2 1

Announcement: NAV 3.4.1 released
by Morten Brekkevold 03 Aug '08

03 Aug '08

NAV 3.4.1 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 available soon. The Debian package is maintained by Morten Werner Forsbring, on commission from UNINETT. We are currently working on migrating NAV from SourceForge.net to Launchpad.net; downloads and issue trackers will be available there once the migration is complete (a separate announcement will be made). We are also working on complete rewrites of AlertEngine and AlertProfiles in Python, thereby ridding NAV entirely of PHP, and almost entirely of Perl. In the process we will also solve some of the basic problems that have plagued alert profiles and alert dispatching for a while. We are hoping to introduce these rewrites in NAV 3.5, scheduled for this fall. Happy NAVing everyone! -- mvh Morten Brekkevold UNINETT

4 7

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