- Nav-users - lister.unit.no

no VLAN information in NAV
by kreide＠online.no 19 Jan '05

19 Jan '05

>===== Original Message From woj(a)tstd.pl ===== >ok, changed descriptons on routers according to guide lines and it worked :) >only switches left. Good to hear! Hopefully the switches will also get the vlan set the next time networkDiscovery is run now that it is correct wrt routers. If not, send me the output of: select module,port,ifindex,vlan,vlanid from netbox join module using(netboxid) join swport using(moduleid) left join swportvlan using(swportid) where ip='<ip>'; Where <ip> is the IP of a switch missing VLAN info. -- Kristian

2 2

no VLAN information in NAV
by kreide＠online.no 19 Jan '05

19 Jan '05

>But in logs, that I send you, and in some tables in database I can find some >vlan numbers... Your suggestion is to use these guide lines: >http://metanav.ntnu.no/moin.cgi/SubnetsAndVlans ? We try to find VLAN numbers on a best-effort basis, and for most devices this works. Where it doesn't, you can specify it manually in the interface descrption: see "Guide lines for configuring router interface descriptions" >> Are you able to look at the output written to the console by the applet? >> There it writes the URL it uses to fetch data from the server; if you could >> paste that link into a browser and provide the output it would be very >> helpful in debugging this issue. >In which log I can find this? You need to look at the Java console. On Windows you can find this by right-clicking the Java tray icon. -- Kristian

2 3

no VLAN information in NAV
by kreide＠online.no 19 Jan '05

19 Jan '05

>> snmpwalk -c public <ip> 1.3.6.1.4.1.9.9.68.1.2.2.1.2 >positive You mean it lists the VLANs? Could you copy a couple of lines so I can verify? But NAV should be able to find the VLAN info in that case. Could you give me the output of the following SQL command? select oidkey from snmpoid join netboxsnmpoid using (snmpoidid) join netbox using(netboxid) where ip='<ip>'; Replace <ip> with the IP of one of your devices. -- Kristian

2 1

no VLAN information in NAV
by woj＠tstd.pl 19 Jan '05

19 Jan '05

Dnia ?roda, 19 stycznia 2005 14:09, Kristian Eide napisa?: > snmpwalk -c public <ip> 1.3.6.1.4.1.9.9.68.1.2.2.1.2 positive -- Wojciech (Woj) Kozicki

1 0

no VLAN information in NAV
by woj＠tstd.pl 19 Jan '05

19 Jan '05

Dnia ?roda, 19 stycznia 2005 13:53, Kristian Eide napisa?: > >> We try to find VLAN numbers on a best-effort basis, and for most devices > > > >and what about switches - should I put some descriptons there too? > > This should normally not be necessary; NAV will be able to do this > automatically. well, this is mine main problem - NAV can't see my vlans from cisco 2900, 2900xl -- Wojciech (Woj) Kozicki

1 0

no VLAN information in NAV
by woj＠tstd.pl 19 Jan '05

19 Jan '05

Hi, for me NAV is very good piece of work :) I have plans to use it in my company, but I have some questions. 1. How serious You are about hunting bugs and making new releases? I know, that Morten Werner Olsen and some guys are porting NAV do Debian (I'm using this packet), the feedback is very good so far :) 2. What about cricket bug in Debian - no descriptons in stats for routers interfaces? 3. Vlans... I know, that there is problem with cisco, and info about vlans. Is there a chance that it will be solved? I will try change my interface descripions according to guide lines from nav web, but this is some inconvenience. 4. New release? When? I want to make clean Debian install of NAV, but would be nice if I could make this on some new version. Thanks for developing NAV, best regards -- Wojciech (Woj) Kozicki >From morten.vold at ntnu.no Wed Jan 19 11:25:00 2005 From: morten.vold at ntnu.no (Morten Vold) Date: Wed Jan 19 11:25:03 2005 Subject: SV: [Nav-users] Cheetah compile errors in deviceManagementTemplate.tmpl In-Reply-To: <41EE19A6.1070305(a)ntnu.no> References: <B1272BF7DAE6094E8D302FF90A391808DFBD8C(a)DIGITALIS.hitos.no> <41EE19A6.1070305(a)ntnu.no> Message-ID: <41EE357C.4030503(a)ntnu.no> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Morten Vold wrote: > I will have to investigate further, possibly installing an updated > Cheetah to track down all the errors. So I did. I have checked in r3104 in Subversion, which should fix syntax errors in all the templates that Cheetah 0.9.16 would complain about. - -- Morten Vold NTNU ITEA Integrasjonsgruppen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7jV8XxIl0kpcOkQRApXaAKCNrp4B5Pa1dbCYyvgXCeKDiPF93ACfYFqd cy05Au8p6uEhjUPCukusQew= =JTo6 -----END PGP SIGNATURE----- >From kreide at online.no Wed Jan 19 13:53:06 2005 From: kreide at online.no (Kristian Eide) Date: Wed Jan 19 13:53:22 2005 Subject: [Nav-users] no VLAN information in NAV Message-ID: <41EF455E(a)epostleser.online.no> >> We try to find VLAN numbers on a best-effort basis, and for most devices >and what about switches - should I put some descriptons there too? This should normally not be necessary; NAV will be able to do this automatically. -- Kristian

1 0

List language
by morten.vold＠ntnu.no 19 Jan '05

19 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In light of the recent postings from non-Norwegians, and the fact that NAV is now available to a much larger public, we have come to the conclusion that the primary language of this mailing list should be English, from now on. (If there should be anyone in the Norwegian higher education community that are uncomfortable with this decision, I would suggest lobbying Uninett to establish a similar mailing list for their member institutions - but I would still recommend continued use of this list) - -- Morten Vold NTNU ITEA Integrasjonsgruppen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7hjAXxIl0kpcOkQRAoRWAKCI0NpFWQ15K6Kr+TE6HWx6K+gxpQCfbzk/ XGNiQazEGYoMjU0F6xwDTPs= =tbr+ -----END PGP SIGNATURE----- >From morten.vold at ntnu.no Wed Jan 19 09:26:14 2005 From: morten.vold at ntnu.no (Morten Vold) Date: Wed Jan 19 09:26:18 2005 Subject: SV: [Nav-users] Cheetah compile errors in deviceManagementTemplate.tmpl In-Reply-To: <B1272BF7DAE6094E8D302FF90A391808DFBD8C(a)DIGITALIS.hitos.no> References: <B1272BF7DAE6094E8D302FF90A391808DFBD8C(a)DIGITALIS.hitos.no> Message-ID: <41EE19A6.1070305(a)ntnu.no> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnsen, ?ge Olai wrote: > Smooth :) > I've tested that. The syntax aint that complicated, so i've changed > some of the source to make it compile. But after the third > change/error i gave up. I see.. taking a closer look, I do see there are more errors that are silently ignored by our version of Cheetah. I will have to investigate further, possibly installing an updated Cheetah to track down all the errors. - -- Morten Vold NTNU ITEA Integrasjonsgruppen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7hmmXxIl0kpcOkQRAovLAJ4raaVcBNNCaYEJJHisi0NBwmJOIACeLnMN 1Mp+KcAUnIVjJd6LfL/Mq9Y= =czzR -----END PGP SIGNATURE----- >From woj at tstd.pl Wed Jan 19 09:29:12 2005 From: woj at tstd.pl (Wojciech Kozicki) Date: Wed Jan 19 09:29:28 2005 Subject: [Nav-users] List language In-Reply-To: <41EE18C0.2030404(a)ntnu.no> References: <41EE18C0.2030404(a)ntnu.no> Message-ID: <200501190929.12561.woj(a)tstd.pl> Dnia ?roda, 19 stycznia 2005 09:22, Morten Vold napisa?: > In light of the recent postings from non-Norwegians, and the fact that > NAV is now available to a much larger public, we have come to the > conclusion that the primary language of this mailing list should be > English, from now on. > > > (If there should be anyone in the Norwegian higher education community > that are uncomfortable with this decision, I would suggest lobbying > Uninett to establish a similar mailing list for their member > institutions - but I would still recommend continued use of this list) Very good idea. The archives will be usable for people from other countries... :) best regards -- Wojciech (Woj) Kozicki

1 0

Cheetah compile errors in deviceManagementTemplate.tmpl
by morten.vold＠ntnu.no 19 Jan '05

19 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnsen, ?ge Olai wrote: > Cheetah 0.9.16a1 [...] > Cheetah.Parser.ParseError: > > #end if found, expected #end def at line 362, column 1 in file > deviceManagementTemplate.tmpl Good catch! Our development server runs Cheetah 0.9.15, which, for some strange reason, silently ignores this syntax error. In other words: It works for us ;-) I'll be checking in a fix for this shortly - just remove line 361 (or comment it out) from deviceManagementTemplate.tmpl and try again. - -- Morten Vold NTNU ITEA Integrasjonsgruppen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7hY6XxIl0kpcOkQRAm+jAJwLlbiYke9DxHPIvkDw9m/Lbe3bVgCfeupT s613eX7nASNvMmy58lfBGWM= =SERo -----END PGP SIGNATURE----- >From Aage.Olai.Johnsen at hitos.no Wed Jan 19 09:25:38 2005 From: Aage.Olai.Johnsen at hitos.no (Johnsen, Åge Olai) Date: Wed Jan 19 09:22:13 2005 Subject: SV: [Nav-users] Cheetah compile errors in deviceManagementTemplate.tmpl Message-ID: <B1272BF7DAE6094E8D302FF90A391808DFBD8C(a)DIGITALIS.hitos.no> Smooth :) I've tested that. The syntax aint that complicated, so i've changed some of the source to make it compile. But after the third change/error i gave up. I've also tested compiling the file with cheetah 0.9.15 with python 2.2.2 on a another box, and it runs smoothly there. (silently ignores the errors) Error #2, after editing line 362; Line|Line contents ----|------------------------------------------------------------- 745 |#for $value,$option in $args['orgList'] 746 | <option value="$value">$option</option> 747 |#end if 748 | </select> ^ 749 | </td> 750 | <td><input type="text" name="cn_retailer"></td> 751 | <td><input type="text" name="cn_ordernr"></td> And so on.. -Åge > -----Opprinnelig melding----- > Fra: Morten Vold [mailto:morten.vold@ntnu.no] > Sendt: 19. januar 2005 09:12 > Til: Johnsen, Åge Olai > Kopi: nav-users(a)itea.ntnu.no > Emne: Re: [Nav-users] Cheetah compile errors in > deviceManagementTemplate.tmpl > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Johnsen, Åge Olai wrote: > > > Cheetah 0.9.16a1 > [...] > > Cheetah.Parser.ParseError: > > > > #end if found, expected #end def at line 362, column 1 in file > > deviceManagementTemplate.tmpl > > Good catch! Our development server runs Cheetah 0.9.15, > which, for some > strange reason, silently ignores this syntax error. In other > words: It > works for us ;-) > > I'll be checking in a fix for this shortly - just remove line 361 (or > comment it out) from deviceManagementTemplate.tmpl and try again. > > - -- > Morten Vold > NTNU ITEA Integrasjonsgruppen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFB7hY6XxIl0kpcOkQRAm+jAJwLlbiYke9DxHPIvkDw9m/Lbe3bVgCfeupT > s613eX7nASNvMmy58lfBGWM= > =SERo > -----END PGP SIGNATURE----- > > ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/

1 0

no VLAN information in NAV
by woj＠tstd.pl 18 Jan '05

18 Jan '05

Dnia wtorek, 18 stycznia 2005 10:31, Kristian Eide napisa?: [cut] > >In VlanPlot I have 4 routers (I didnt include all routers in NAV), after > >clicking one of them there is always an error: > >"An error occured fetching data from server > I just checked - it started to work, I dont know why, I didn't change NAV config, but today we have some big config changes on that router (deleting some int, adding some int)... best regards :) -- Wojciech (Woj) Kozicki

1 0

no VLAN information in NAV
by woj＠tstd.pl 18 Jan '05

18 Jan '05

Dnia wtorek, 18 stycznia 2005 10:31, Kristian Eide napisa?: > >In /editdb/prefix/edit/ if I will take some prefix, implicitly put some > > VLAN number to it, then in Vlan Plot, and some other toolbox stuff this > > Vlan will be visible. But this is not automatic process. > > This is a well-known issue with some Cisco devices; unfortunately we have > not (yet) found a way to fetch the vlan numer via SNMP. > > We have the vlan number as part of the router interface description and NAV > is able to parse this. Could you do something similar? I admit this is not > an ideal situation, however, and we are looking for a better way. > But in logs, that I send you, and in some tables in database I can find some vlan numbers... Your suggestion is to use these guide lines: http://metanav.ntnu.no/moin.cgi/SubnetsAndVlans ? > >In VlanPlot I have 4 routers (I didnt include all routers in NAV), after > >clicking one of them there is always an error: > >"An error occured fetching data from server > > Are you able to look at the output written to the console by the applet? > There it writes the URL it uses to fetch data from the server; if you could > paste that link into a browser and provide the output it would be very > helpful in debugging this issue. In which log I can find this? -- Wojciech (Woj) Kozicki

1 0