On Mon, 07 Mar 2005 10:20:36 +0100 Morten Vold morten.vold@ntnu.no wrote:
Vegard Vesterheim wrote:
I would like for NAV to *not do authentication at all*, but instead rely on 'higher powers' (in my case: Apache) to do this. In principle this would imply skipping the local authentication handling in NAV altogether. Apache does the authentication part, and NAV picks up the authenticated username and just does the authorization.
Although this type of authentication is not built in to NAV today, Bj?rn Ove has identified where to do it; follow the trail from subsystem/webFront/lib/nav/web/__init__.py in function headerparserhandler, which invokes the authentication module of NAV. Although the authentication bits aren't very modular today, they can easily be rewritten to take authentication tokens from the URL or from Apache headers.
OK, considering my limited python skills, and my total unfamiliarity with the NAV source code, I suspect that this rewriting will not be so 'easily' done, but thanks for the hints anyway. I'll take a quick stab at it soon, and report my findings back to the list.
Well, a kind of fallback mechanism with a local userdatabase in NAV could be useful. For instance if the central login-service is unavailable, a local emergency fallback could be helpful.
This is the reason why NAV performs the authentication step today, either through LDAP or locally. If it didn't, and the LDAP server (or another type of external authentication server) is unreachable, you will be unable to use NAV to debug the network problem, as you can't log in. If the Apache mechanism provides the fallback itself, that would be OK as well.
Yes, the authentication mechanism needs to be very robust.
As a sidenote, regardless of whether NAV performs authentication against the local NAVdb or the remote LDAP, an entry for the user that logs in must be placed in the NAVdb. This entry is used to store user preferences and NAV authorization information. If you do create a third authentication method, you must also make sure to create NAVdb entries for new users that are authenticated through the external system.
Yes, the user-databases needs to be synchronized, but this could be automated and should be transparent for the end user.
- Vegard -
From Vidar.Faltinsen at uninett.no Mon Mar 7 14:09:56 2005
From: Vidar.Faltinsen at uninett.no (Vidar Faltinsen) Date: Mon Mar 7 14:10:01 2005 Subject: SV: RE: [Nav-users] vlan information from cisco switches In-Reply-To: s226f859.067@HVO-3.hivolda.no References: s226f859.067@HVO-3.hivolda.no Message-ID: Pine.LNX.4.61.0503071348130.32236@valentin.uninett.no
On Thu, 3 Mar 2005, Peder Magne Sefland wrote:
In my nav3beta10 (debian) every switch shows vlan information on ports, except on my two cisco 2980.
model descr serial sw_ver hw_ver fw_ver WS-X2980GBRJ WS-X2980RJ 10/100BaseTx Ethernet Rev. 2.0 JAB05250BZH 5.5(18) 2.0 5.4(1)
model descr serial sw_ver hw_ver fw_ver WS-X2980GBRJ WS-X2980GBRJ 10/100/1000 Ethernet Rev. 1.2 JAB061906WQ 6.3(5) 1.2 6.1(4)
They are running CatOS, but my 5500 is also running CatOS and he is showing vlan information.
This is the information from the web-page /report/swport?b1.netboxid=38 interface module port link Mbps duplex media trunk vlan portname 2/17 2 17 y 100.0 h 0 UPS-Strom snmp
But the vlan information is collected, and I can find it tabell swport
swportid | moduleid | ifindex | port | interface | link | speed | duplex | media | vlan | trunk | portname | to_netboxid | to_swportid ----------+----------+---------+------+-----------+------+-------+--------+-------+------+-------+----------------+-------------+------------- 12069 | 824 | 25 | 17 | 2/17 | y | 100 | h | | 10 | f | UPS-Strom snmp | |
Any ideas?
Be aware that there is an additional table, swportvlan, that contains vlan informartion. It is this table that is used in the report, and I will explain why (Kristian can correct me if I am mistaking):
The gDD plugin that gathers swport data will find vlan values for all non-trunk ports along with other relevant swport data. This is what you see in the swport table.
In turn the networkdiscovery system detects the physical topology of your network. Based on the physical topology (with trunk port information) the vlandiscovery feature detects the actual deployment of the various vlans in your network. This latter process will fill data in swportvlan.
To be consistent, and thereby reveal vlan discovery bugs, we have decided to base the vlan information in the reports on the swportvlan information only (as a minimum we would anyway have to consult the table in order to retrieve vlan information for trunk ports).
My guess is that vlandiscovery is not running, or has a bug that effect you. Check:
1. is the requested information in the swportvlan table (probably not) 2. does "nav status" tell you that Networkdiscovery is running 3. is networkDiscovery-stderr.log updated reasently? does it give you a clue?
- Vidar