Nav-users

nav-users@lister.sikt.no

3 participants
1372 discussions

Newbie Problem loading NAV on CentOS 4.4
by rkillick＠niagara.com 17 Nov '06

17 Nov '06

Hello: I am trying to load NAV 3.1.1 onto a basic CentOS4.4 installation. My problem is likely embarrassingly simple and concerns a point near the start of the "InstallingOnRHEL4" document for NAV3.1.1. .. at the section. ## ## Make a local user ## useradd -c "John Doe" nn passwd nn .. I create a simple user called "NAVNIA" as well as an appropriate password. Soon thereafter you are asked to reboot and log in as the new user. .. Logged in as NAVNIA, that user has no root privilege or access to root level commands that now have to be executed to complete the install. While I know it is best practice not to run as root, I just don't get what I need to do to have the new user (NAVNIA) complete the install. It doesn't seem right to simply su root every time you need that privilege. As I siad. a very basic question I'm sure, but my MS-Windows admin experience is simply no help here and my access to Linux help is simply zero. I am quite interested in getting NAV up and running as a means of show-casing the OpenSource possibilities as well as hhoping to see a viable alternative to our Pergrine PND NMS. Our network has about 1600 devices and NAV looks very inviting! Any insight would be appreciated. Bob Killick

2 1

Installing NAV on SLES9
by morten.brekkevold＠uninett.no 14 Nov '06

14 Nov '06

Martin Roll wrote, On 10-11-2006 16:09: > But when I open the browser to look at the interface (on localhost) the > only thing I see is the NAV webroot directory. > Do you have any idea what could be wrong? Looks like a problem with your Apache configuration. Two questions: Is mod_python loaded by your Apache configuration? Is AllowOverride set to "All" for NAV's webroot directory? -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Mon Nov 13 13:51:13 2006 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Mon Nov 13 13:51:28 2006 Subject: [Nav-users] CentOS RPMs for NAV 3.1.1 Message-ID: <45586A41.1080402(a)uninett.no> Hi everyone, Alexander Krapivin has most graciously provided us with updated NAV RPM packages for CentOS 4, also compatible with RHEL 4. Further install instructions for these can be found at the metanav wiki. The RPMs have not been completely tested yet, and Alexander has asked that those who use the packages report any problems to him. The packages can be downloaded at the files area on SourceForge: http://sourceforge.net/project/showfiles.php?group_id=107608 -- mvh Morten Brekkevold UNINETT >From fuchs at rrz.uni-koeln.de Mon Nov 13 16:05:15 2006 From: fuchs at rrz.uni-koeln.de (Hans-Peter Fuchs) Date: Mon Nov 13 16:05:21 2006 Subject: [Nav-users] Trying to install nav 3.1.1 Message-ID: <455897BB.16234.87A563E3(a)fuchs.rrz.uni-koeln.de> Hello list, I want to install and test nav3.1.1 The configure + make + make install run without error. Afterthat I am able to connect to the webinterface and to login. But editdb gives the error: Mod_python error: "PythonHandler editdb" Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line 287, in HandlerDispatch log=debug) File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line 457, in import_module module = imp.load_module(mname, f, p, d) File "/usr/local/nav/apache/webroot/editdb/editdb.py", line 29, in ? import editTables,nav.Snmp,sys,re,copy,initBox,forgetSQL,nav.web File "/usr/local/nav/lib/python/nav/Snmp.py", line 33, in ? from pysnmp import role, v1, v2c, asn1 ImportError: cannot import name role I see that this means python is unable to find module: role but this is in: /usr/lib/python2.3/site-packages/pysnmp/mapping/udp Before I tested with nav3.1.0 under rhel-as4 and installed as described in: Installing on RHEL4. The pysnmp is from this install. What am I missing or has something changed ? Gr??e Hans-Peter Fuchs Hans-Peter Fuchs - RRZK Zimmer 20 Zentrum f?r angewandte Informatik - Universit?tsweiter Service RRZK Universit?t zu K?ln - Tel: 0221-470-6972

2 1

missing FROM-clause in databaseHandler.php
by morten.brekkevold＠uninett.no 09 Nov '06

09 Nov '06

Ingeborg Hellemo wrote, On 09-11-2006 12:58: > If somebody wants to fix one of these errors, it is located in > /usr/local/nav/apache/webroot/alertprofiles/databaseHandler.php > on line [868] > > pg_exec() [function.pg-exec]: Query failed: ERROR: missing FROM-clause entry > for table "accountgroup" If you have more of these, then please, bring'em on! r3725 on trunk saves you this time ;) -- mvh Morten Brekkevold UNINETT >From martin.roll at elementum.info Fri Nov 10 16:09:30 2006 From: martin.roll at elementum.info (Martin Roll) Date: Fri Nov 10 16:09:39 2006 Subject: [Nav-users] Installing NAV on SLES9 Message-ID: <4554962A.6060104(a)elementum.info> Hi! I recently tried to install NAV on a SLES machine according to http://metanav.ntnu.no/moin.cgi/InstallingOnSLES but I think something went wrong. I installed all of the prerequisites and configured it as described (at least I think so). When I start NAV using the "nav start" command everything seems fine. But when I open the browser to look at the interface (on localhost) the only thing I see is the NAV webroot directory. Do you have any idea what could be wrong? I can send you any configuration file to check if you want. Thanks in advance! Martin

1 0

Database problem
by morten.brekkevold＠uninett.no 09 Nov '06

09 Nov '06

Christian Goutrie wrote, On 08-11-2006 15:28: > sql by hand means, that I passed the statement directly via the psql: > > ------------------------------------- > > me@it005:~> psql -U nav -d manage > Password for user nav: > Welcome to psql 8.1.3, the PostgreSQL interactive terminal. > > manage=# SELECT AccountInGroup.accountid, groupid FROM AccountInGroup WHERE > (AccountInGroup.accountid='0'); > > accountid | groupid > -----------+--------- > (0 rows) > > manage=#\q That's your problem, right there. You did not follow the database instructions properly. The table you just selected from is not supposed to be in the `manage` database, but rather in the `navprofiles` database. Please read doc/sql/README over again. If there are any problems with the instructions there that made you misunderstand, please report back so we can write better instructions. -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Thu Nov 9 10:53:09 2006 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Thu Nov 9 10:53:24 2006 Subject: [Nav-users] Garbage in alertengine.pid In-Reply-To: <200611090714.kA97ENQU070237(a)barnetv.cc.uit.no> References: <200611090714.kA97ENQU070237(a)barnetv.cc.uit.no> Message-ID: <4552FA85.5080507(a)uninett.no> Ingeborg Hellemo wrote, On 09-11-2006 08:14: > Freshly installed NAV 3.1.1. FreeBSD 6.1-RELEASE-p10 > > /# /usr/local/nav/bin/nav status > networkDiscovery: Up > > ... > > pping.py (pid 65207) is running... > ps: process id too large: 1162996552 > alertengine (pid 65218) is running... > > /# cat /usr/local/nav/var/run/alertengine.pid > 65218 1162996552 > > The first number in the pid-file is indeed the pid, but why the garbage at the > end? Ah. I discovered that myself while creating the bug you just pointed out ;) I got tired of AlertEngine's incessant verbosity when start/stopping and querying for status, so I changed its init-script to use the shell-script based pid-file probing. The "garbage" is actually a unix timestamp, referring to when the alertEngine daemon was started. When querying the alertengine program directly (as in pre-3.1.1), it would use this to tell you how long it had been running. Why on earth the author put it in the pid file, I don't know. I thought about removing the timestamp completely from the pid file as I changed the init script, as it bothered me somewhat - but in my Linux-centric world it worked fine without removing it. Looks like I'll have to reconsider... -- mvh Morten Brekkevold UNINETT >From morten.brekkevold at uninett.no Thu Nov 9 11:17:28 2006 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Thu Nov 9 11:17:46 2006 Subject: [Nav-users] Garbage in alertengine.pid In-Reply-To: <4552FA85.5080507(a)uninett.no> References: <200611090714.kA97ENQU070237(a)barnetv.cc.uit.no> <4552FA85.5080507(a)uninett.no> Message-ID: <45530038.7090207(a)uninett.no> Ingeborg Hellemo wrote, On 09-11-2006 08:14: >> /# cat /usr/local/nav/var/run/alertengine.pid >> 65218 1162996552 >> >> The first number in the pid-file is indeed the pid, but why the garbage at the >> end? Morten Brekkevold wrote, On 09-11-2006 10:53: > I thought about removing the timestamp completely from the pid file as I > changed the init script, as it bothered me somewhat - but in my > Linux-centric world it worked fine without removing it. Looks like I'll > have to reconsider... Ingeborg, if you're still in the patching business, you can grab r3724 from Subversion and apply it (or the ports maintainer could do it) to fix this problem. -- mvh Morten Brekkevold UNINETT >From Ingeborg.Hellemo at cc.uit.no Thu Nov 9 12:58:06 2006 From: Ingeborg.Hellemo at cc.uit.no (Ingeborg Hellemo) Date: Thu Nov 9 12:58:23 2006 Subject: [Nav-users] missing FROM-clause in databaseHandler.php Message-ID: <200611091158.kA9Bw6bs077593(a)barnetv.cc.uit.no> The problem of "missing FROM-clause" errors when using postgres 8.1 has been mentioned on this list earlier. The workaround is to add the line add_missing_from = on to postgresql.conf, but the solution is to write correct sql-queries. If somebody wants to fix one of these errors, it is located in /usr/local/nav/apache/webroot/alertprofiles/databaseHandler.php on line [868] pg_exec() [function.pg-exec]: Query failed: ERROR: missing FROM-clause entry for table "accountgroup" --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg(a)cc.uit.no (Univ. of Troms?, Norway)

1 0

Garbage in alertengine.pid
by Ingeborg.Hellemo＠cc.uit.no 09 Nov '06

09 Nov '06

Freshly installed NAV 3.1.1. FreeBSD 6.1-RELEASE-p10 /# /usr/local/nav/bin/nav status networkDiscovery: Up ... pping.py (pid 65207) is running... ps: process id too large: 1162996552 alertengine (pid 65218) is running... /# cat /usr/local/nav/var/run/alertengine.pid 65218 1162996552 The first number in the pid-file is indeed the pid, but why the garbage at the end? The problem is there in 3.1.0 and earlier versions too, but then 'nav status' didn't mind. --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg(a)cc.uit.no (Univ. of Troms?, Norway)

1 0

Database problem
by goutrie＠rapideye.de 08 Nov '06

08 Nov '06

Hi, i'm trying to get NAV running, because I am mainly interested in the network discovery part. After following the instructions in INSTALL, generating the databases, configuring apache2 and recompiling templates, I get this error-message: --------------------------------------------------------------------- Mod_python error: "PythonHeaderParserHandler nav.web" Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/lib/python2.4/nav/web/__init__.py", line 59, in headerparserhandler nav.web.auth.authenticate(req) File "/usr/lib/python2.4/nav/web/auth.py", line 97, in authenticate if not checkAuthorization(user, req.unparsed_uri): File "/usr/lib/python2.4/nav/web/auth.py", line 49, in checkAuthorization return nav.auth.hasPrivilege(user, 'web_access', uri) File "/usr/lib/python2.4/nav/auth.py", line 48, in hasPrivilege user.cachePrivileges() File "/usr/lib/python2.4/nav/auth.py", line 90, in cachePrivileges groups = account.getChildren(navprofiles.Accountingroup) File "/usr/local/lib/python2.4/site-packages/forgetSQL.py", line 811, in getChildren return forgetter.getAll(whereList, orderBy=orderBy) File "/usr/local/lib/python2.4/site-packages/forgetSQL.py", line 679, in getAll ids = cls.getAllIDs(where, orderBy=orderBy) File "/usr/local/lib/python2.4/site-packages/forgetSQL.py", line 743, in getAllIDs curs.execute(sql) ProgrammingError: ERROR: relation "accountingroup" does not exist SELECT AccountInGroup.accountid, groupid FROM AccountInGroup WHERE (AccountInGroup.accountid='0') ------------------------------------------------------------------------------ I If I try sql by hand in the CLI, it works. I'm puzzled now. Any idea, how to get it working? Some case-sensitive related problems? Some further Information: SuSE 10.1 Nav 3.1.0. from source Python 2.4.2 from RPM postgres 8.1.3 from RPM CHEETAH 1.0 (could not use v2, there were some syntax changes?!) from source apache 2.2.0 from RPM mod_python 3.2.10 from source perl v5.8.8 from RPM java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode) from RPM Thanks in advcance Christian >From morten.brekkevold at uninett.no Wed Nov 8 14:38:52 2006 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Wed Nov 8 14:39:37 2006 Subject: [Nav-users] Announcement: NAV 3.1.1 is out Message-ID: <4551DDEC.7010009(a)uninett.no> NAV 3.1.0 is now available for download at SourceForge, see http://sourceforge.net/projects/nav :-) This is mainly a bugfix release, and some serious issues have been fixed in this version, including one security vulnerability discovered by Jim Gallacher. Binary packages for Debian will be available at a later time. The Debian package is maintained by Morten Werner Olsen, and he is currently polishing his nearly finished packaging of the 3.1.0 release. We would also like to welcome anyone interested in maintaining packages for RPM-based distributions! -- mvh Morten Vold UNINETT

2 1

Installation of NAV on CentOS 4.4
by kaa＠msu.net 19 Okt '06

19 Okt '06

Hi, Tor Pretorius wrote: > Hello, > > I try to install Nav-3.1-0-1 on CentOS-4.4 and get a error > > rpm -ivh nav-3.1.0-1.noarch.rpm > error: Failed dependencies: > perl(Pg) is needed by nav-3.1.0-1.noarch This is known issue. Just add --nodep. This rpm works in the way described at http://metanav.ntnu.no/moin.cgi/InstallingOnRHEL4 > > > I have install pgsql_perl5-1.9.0 > > > > Mvh > Tor Pretorius > ITAS -- With best regards, Alexander Krapivin mailto:kaa@msu.net NOC MSUNET ICQ UIN:3967345 MSU, Moscow, Russia

1 0

Cisco port numbering, suggestions?
by morten.brekkevold＠uninett.no 12 Okt '06

12 Okt '06

Greetings everyone, This post may become rather lengthy, but if you are interested in Cisco module issues and port numbering vs. interface names, please bear with me. I would really appreciate some feedback from our users, as the changes we are implementing will affect everyone. Removing the "submodule hack" ----------------------------- This summer I worked on fixing some of the problems with module detection on Cisco equipment. There were several problems related to the fact that gDD attempts to map Cisco's submodule paradigm in to NAV's data model by assigning module number 10 to submodule 1/0, number 11 to submodule 1/1 and so forth. Apparently, there isn't much equipment that actually employs submodules, and oftentimes these modules will not be self-sustainable devices, as in the case of the 3750 Metro. The basic metro reports two submodules, the first (1/0) contains 24 Fa ports and two Gi ports, while the second (1/1) contains two Gi ports. Basically, the Metro is just one physical device, and with the code changes I've made, the Metro will appear in NAV as one single module with 28 ports. Meaning that submodules are largely ignored by NAV, which now attaches the ports of all submodules to the top module itself. Port numbering -------------- As you may know, NAV assigns port numbers to switch interfaces. I'm told this is an old convention stemming from the old CatOS CLI implementation, where interfaces only had port numbers and not names. In many parts of the user interface, NAV refers to switch interfaces only by their module and assigned port numbers. In the Cisco case, NAV assigns (or rather, used to assign) port numbers by interpreting interface names and/or descriptions. This means that Fa1/5 would become port 5 on module 1, and Fa2/0/3 would become port 3 on module 20 (!). On devices with both Fa and Gi interfaces, Cisco reuses these numbers. A module would have both an Fa1/1 and a Gi1/1 interface. NAV would assign the port number 1 to the Fa1/1 interface, and when it found the Gi1/1 interface, it would see a port numbering conflict and assign the ifindex value of the Gi1/1 interface as its port number (typically resulting in something like 10101 as its port number). With the submodule changes described above, the code will rely more on the the portIfIndex table from the CISCO-STACK-MIB [1]. This table enumerates the interfaces of a Cisco stack into modules and port numbers. For a Metro 3750, this table will actually enumerate all 28 interfaces as port 1 through 28 on module 1. I've received some criticism for this from people running NAV from the latest trunk revisions, though. Apparently, many Cisco devices will enumerate Gi interfaces before Fa interfaces, meaning that Gi1/1, Gi1/2 and Fa1/1 will become ports 1, 2 and 3 in that order. This represents a change in the port number assignments that NAV has made earlier. Previously, it would have started assigning port numbers to the Fa interfaces first (either because their ifindex values are lower, or because they sort first alphabetically). Consequently, if you upgrade your NAV installation to the trunk (or the upcoming 3.1.1 version), any switch you have that has both GigabitEthernet and FastEthernet interfaces will have its ports renumbered in NAV. The complaints I've received about this largely revolve around the fact that some users have implemented external systems that relate to NAV by referring to module and port numbers, and that this reference breaks when NAV suddenly decides to assign new port numbers. A typical example of this would be that when searching for a MAC address in the Machine Tracker before the change, you might be told a machine is connected to foo-sw, module 1, port *5*. Then you upgrade NAV, perform the same search in the Machine Tracker, and now you are told the machine in question is connected to foo-sw, module 1, port *7*. The interface name in these two cases will remain the same, e.g. "FastEthernet1/0/5" or "Fa1/0/5", but this string is not available in the Machine Tracker (yet). Numbering vs. names ------------------- Now, other feedback we've received (both internal and external) tells us that today, port numbers are largely irrelevant in real world situations. Several network engineers have told us that they care about interface names (the ones they see on the CLI, such as Fa1/5), rather than arbitrary port numbers. Their viewpoint is that NAV should place more importance on interface names than on port numbers, meaning we should put interface names in all parts of the user interface that has port numbers today, including the Machine Tracker. The NAV dev-team is leaning towards the latter solution, but this is too big a change for the 3.1.1 bug release, and we might not even have time to do it for version 3.2, which is scheduled for late October. The question is, what do you, the users, think about this? The situation, as it stands, is that a new port number assignment scheme will turn up in the 3.1.1 bug release, because of the submodule bugfix. This may confuse some people, as interface names are not readily available in many parts of the user interface. Should we try to stay with a numbering scheme compatible with the old one for the 3.1.1 release, and wait for interface names in the UI before we change the port numbers? This might delay the 3.1.1 release even further, as we need to make changes to the standing bugfix before the release. Is it okay to renumber ports in the 3.1.1 release, as long as interface names become more prominent in the UI in the 3.2 or 3.3 release? Should we prioritize more prominent interface names in the 3.2 release, or is it okay to wait until the 3.3 release? Now's your chance to influence these decisions, before further implementation takes place. [1] http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1… -- mvh Morten Brekkevold UNINETT

1 1

Nav 3.0 makecricketconfig.pl error
by morten.brekkevold＠uninett.no 06 Okt '06

06 Okt '06

Erik Weber wrote, On 05-10-2006 15:39: > Still using Nav 3.0 (latest debian release, anyone know if a 3.1 is > gonna be released soon?) Actually, Morten Werner is sitting next to me working on that right now. He came up here from Oslo on Wednesday to have a little brainstom/workshop with us. He's also uploaded a preliminary 3.1 package to the official Debian unstable archives, which hopefully means that NAV 3.1 will be part of the next Debian stable release. That said, he's also backporting a 3.1 package for the current stable release. These new packages will also feature automatic database initialization and upgrades on install. > Anyway, when running makecricketconfig.pl i get this error message: > > Use uninitialized value in pattern match (m//) at > /usr/lib/nav/makecricketconfig.pl line 927 > > This happens when it process a switch named nara-sw002-01 (catalyst > 3524XL) > > Anyone know about a fix for it? I don't. But what's on line 927 of /your/ makecricketconfig.pl anyway? I'm looking at makecricketconfig.pl from NAV 3.0.1 (which is in the latest Debian package), and that line is a comment: # Write to file. -- mvh Morten Brekkevold UNINETT

1 0

Field Length of orgid
by mturczan＠nyp.org 03 Okt '06

03 Okt '06

Folks, I tried to import a record with the proper orgid set as follows: F-1196A:10.10.10.10:Org_East_Campus:SW:ro::rw:Access Layer Switch:::: And I received the following error: Syntax error: Field 'orgid' exceeds max field length I assigned the Organisation field the same way, and it seems like the field itself can hold a maximum of 30 characters. Is there another identifier somewhere that corresponds to 'orgid' in the IP Devices bulk import? Regards, Mark -------------------- This electronic message is intended to be for the use only of the named recipient, and may contain information that is confidential or privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and delete and destroy all copies of this message. Thank you.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users