On Thu, Aug 28, 2008 at 03:51:51PM +0200, Morten Brekkevold wrote:
On Fri, 22 Aug 2008 15:43:25 +0100 Tim Chown tjc@ecs.soton.ac.uk wrote:
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?
You didn't specify what you mean by "data" and searching said "data", but I will assume you are referring to the Machine Tracker.
CAM and ARP data are basically stored as logs in the database and used by the Machine Tracker. Since a CAM/ARP entry in NAV is a historic record, it retains historic names of the originating devices.
When you search for a sysname in Machine Tracker, it searches for records matching that exact/partial name.
We do however store a reference to the IP device record of the originating device with each CAM/ARP entry. As long as an IP device stays registered in NAV, any name changes can be inferred from its recorded CAM/ARP data. Once the IP device is removed from NAV, the historic CAM/ARP data remains, but can no longer be used to infer name changes over time for that particular device.
So, in short, we could actually add a feature to the Machine Tracker to find CAM/ARP entries recorded under other names than the one used in the search form. You're welcome to add this as a wishlist priority item at https://bugs.launchpad.net/nav if it sounds like something you would want.
I suspect a few people will make the smae 'mistake' that we did, to enter systems by name, but these are converted to IP-names because a reverse lookup is not available. I think this warning was in the small print of the docs, but we were too excited during install and missed it.
We'll check out the new bugtracker very soon!
Regarding the database change offer, we'd be up for trying it if you can provide the magic incantation :)
The switch stacks are:
10.78.64.61 b86-l1-cat1 10.78.64.63 b59-l2-cat1 10.78.64.64 b59-l3-cat1 10.78.64.65 b59-l4-cat1 10.78.64.66 b1-l1-cat1 10.78.64.67 b16-l2-cat1 10.78.64.68 b1-l1-cat2 10.78.64.69 b32-l3-cat1 10.78.64.70 b32-l3-cat2 10.78.64.71 b32-l4-cat1 10.78.64.72 b32-l4-cat2 10.78.64.75 b59-l3-cat2 10.78.64.76 b53-l2-cat1 10.78.64.77 b53-l3-cat1 10.78.64.78 b53-l4-cat1 10.78.64.79 b53-l4-cat2
Some were added after we arranged reverse DNS to work (added a local /etc/hosts entry for convenience) so may not have the problem, but most of them do.
If you want to use this essentially as a way to test how you'd add a conversion option to NAV, we're happy to test.
Tim,
Just a comment to this discussion. We have for long seen the disadvantages of only relying on reverse dns lookup for names. A long time back we actually based names on the snmp derived system.sysname, i.e. the name you configure on the box. Then we changed to dns.
We have thoughts on making this key issue more flexible, it has been on the task list for long, it may now have moved to launchpad, if not, and anyway, read this;
http://metanav.uninett.no/devel:tasklist#mb4collect_system.sysname_in_additi... That is:
o Today the netbox.sysname value is based upon dns. If dns does not resolve the ip address is used as name. We should in addition collect the name that is configured on the device, and perhaps make it configurable in a config file what should be the primary name source used in the front end tools.
o collect system.sysLocation and sysContact as well. Store it in netboxinfo (perhaps).
Not certain when we will commit this, but we will one day - that I can promise!
- Vidar
Tim Chown wrote:
On Thu, Aug 28, 2008 at 03:51:51PM +0200, Morten Brekkevold wrote:
On Fri, 22 Aug 2008 15:43:25 +0100 Tim Chown tjc@ecs.soton.ac.uk wrote:
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?
You didn't specify what you mean by "data" and searching said "data", but I will assume you are referring to the Machine Tracker.
CAM and ARP data are basically stored as logs in the database and used by the Machine Tracker. Since a CAM/ARP entry in NAV is a historic record, it retains historic names of the originating devices.
When you search for a sysname in Machine Tracker, it searches for records matching that exact/partial name.
We do however store a reference to the IP device record of the originating device with each CAM/ARP entry. As long as an IP device stays registered in NAV, any name changes can be inferred from its recorded CAM/ARP data. Once the IP device is removed from NAV, the historic CAM/ARP data remains, but can no longer be used to infer name changes over time for that particular device.
So, in short, we could actually add a feature to the Machine Tracker to find CAM/ARP entries recorded under other names than the one used in the search form. You're welcome to add this as a wishlist priority item at https://bugs.launchpad.net/nav if it sounds like something you would want.
I suspect a few people will make the smae 'mistake' that we did, to enter systems by name, but these are converted to IP-names because a reverse lookup is not available. I think this warning was in the small print of the docs, but we were too excited during install and missed it.
We'll check out the new bugtracker very soon!
Regarding the database change offer, we'd be up for trying it if you can provide the magic incantation :)
The switch stacks are:
10.78.64.61 b86-l1-cat1 10.78.64.63 b59-l2-cat1 10.78.64.64 b59-l3-cat1 10.78.64.65 b59-l4-cat1 10.78.64.66 b1-l1-cat1 10.78.64.67 b16-l2-cat1 10.78.64.68 b1-l1-cat2 10.78.64.69 b32-l3-cat1 10.78.64.70 b32-l3-cat2 10.78.64.71 b32-l4-cat1 10.78.64.72 b32-l4-cat2 10.78.64.75 b59-l3-cat2 10.78.64.76 b53-l2-cat1 10.78.64.77 b53-l3-cat1 10.78.64.78 b53-l4-cat1 10.78.64.79 b53-l4-cat2
Some were added after we arranged reverse DNS to work (added a local /etc/hosts entry for convenience) so may not have the problem, but most of them do.
If you want to use this essentially as a way to test how you'd add a conversion option to NAV, we're happy to test.
On Thu, 28 Aug 2008 15:31:01 +0100 Tim Chown tjc@ecs.soton.ac.uk wrote:
Regarding the database change offer, we'd be up for trying it if you can provide the magic incantation :)
Sure, these two statements should reset the sysname of all CAM/ARP entried related to devices which are registered in your NAV at the moment:
UPDATE arp SET sysname=n.sysname FROM netbox n WHERE n.netboxid=arp.netboxid; UPDATE cam SET sysname=n.sysname FROM netbox n WHERE n.netboxid=cam.netboxid;
You can connect to the database using the psql command line tool, e.g. "psql manage nav" to connect to the manage database as the nav user. Use the password from NAV's db.conf.
I must warn you that these statements can be quite slow, depending on the number of records you have in the two tables. If you have made any actual device renames during NAV's runtime, these devices' records will also be falsified by these statements.
If you want to use this essentially as a way to test how you'd add a conversion option to NAV, we're happy to test.
I don't think we want that. We value the historic accuracy of cam and arp records; we'd rather make sure the machine tracker can search records across name changes.
-
Morten Brekkevold -
Tim Chown -
Vidar Faltinsen