Stein Magnus,
As I understand it IP Device Info will be feature complete for 3.5 and will be included as a new tool, now also seen from the toolbox.
Will you use the RJ45 jack as icon (the one from IP Info center)? Perhaps better with an icon of a switch or something? How about "stealing" the Device Management icon? And then for the new Device History use a faded router icon, perhaps surrounded with a graph or cornered with a clock indicating history?
Suggestion for the text in toolbox: "IP Device Info displays all recorded information about a given IP address. If the device is a NAV registered switch or router a port view with details on status and activity is also shown"
Even if you are not reimplementing IP Info Center, is it possible to remove this as a tool from the toolbox and instead invoke the tool from the query page of ipdevinfo, in the case the given ip is not a NAV registered box?
I think leaving the two tools in the toolbox will confuse users (as indeed is the reason for merging the tools in the end).
I further suggest IP Device Info is listed in the toolbox after report.
BTW - Morten; The first box in the report links today to "IP Device Center" and leads to /browse Change to "IP Device Info" and go to /ipdevinfo It seems this change has to be done all over the place in report; swap links for /browse with /ipdevinfo
Morten; I guess we should work through more of the text from the toolbar. Also the text for the verktøykasse nfsen, here I suggest: "NFSen integrates with NAV to analyze and display your netflow traffic data"
- Vidar
On Wed, 2008-09-10 at 09:55 +0200, Vidar Faltinsen wrote:
As I understand it IP Device Info will be feature complete for 3.5 and will be included as a new tool, now also seen from the toolbox.
We'll have to see about that, but I'll do my best.
We should maybe consider updating tools with beta status in the minor/bugfix releases, and not only in the major releases, as with all other tools. It would be nice for the developers to get user feedback on new features/development more often than every sixth month and I think we all can live with the beta tools beeing a bit more volatile than the stable tools.
Will you use the RJ45 jack as icon (the one from IP Info center)? Perhaps better with an icon of a switch or something? How about "stealing" the Device Management icon? And then for the new Device History use a faded router icon, perhaps surrounded with a graph or cornered with a clock indicating history?
Personally, I really don't like the Cisco router icon, and try to stick to the Tango icon theme used for most of the tools. I've now changed to a "network server" icon on navdev. A network server is maybe not the most common IP device in a typical NAV setup, but an IP device none the less.
Suggestion for the text in toolbox: "IP Device Info displays all recorded information about a given IP address. If the device is a NAV registered switch or router a port view with details on status and activity is also shown"
I've just added: "Displays all recorded information about a given IP device or address. If the device is a NAV registered switch or router a port view with details on status and activity is also shown."
Even if you are not reimplementing IP Info Center, is it possible to remove this as a tool from the toolbox and instead invoke the tool from the query page of ipdevinfo, in the case the given ip is not a NAV registered box?
I think leaving the two tools in the toolbox will confuse users (as indeed is the reason for merging the tools in the end).
What cases do we have for host lookup in IP Info?
a) Host unknown to NAV (example: 129.241.93.17) - ipinfo: Shows DNS information. - ipdevinfo: Shows DNS information. b) Host known to NAV (example: voldsminde) - ipinfo: Links to devBrowser. Shows DNS, subnet, vlan, org. Shows ARP and MAC data, and where least seen (switch,module,port). - ipdevinfo: Shows everything devBrowser does (soon), DNS, subnet, vlan, org. Does not show ARP, MAC, last seen. c) Host known to NAV and matching rule sin the "local output configuration" (i.e. usage=='sby') - ipinfo: Same as for b) and additional links to external systems as decided by configuration. - ipdevinfo: Same as for b).
Any cases I've forgotten, misunderstood or which are incomplete?
For case b), ipdevinfo can get the missing data quite easily.
For case c), if one can live without this feature either permanently or hidden from the toolbox for some time, we can surely remove the ipinfo tool from the toolbox without linking to it at all. Alternatively, one could link to ipinfo from the "Actions" list in ipdevinfo until this last ipinfo feature are added to ipdevinfo.
I further suggest IP Device Info is listed in the toolbox after report.
Fixed.
BTW - Morten; The first box in the report links today to "IP Device Center" and leads to /browse Change to "IP Device Info" and go to /ipdevinfo It seems this change has to be done all over the place in report; swap links for /browse with /ipdevinfo
I think we should wait with changing links from /browse to /ipdevinfo in case ipdevinfo does not satisfy all needs covered by devBrowser at the time of release. (I'd prefer timeboxing to featureboxing. Take features out instead of pushing the release date.)
Further, let i.e. Jørgen's changes to the report tool be merged to the default branch before we change any of that code.
Morten; I guess we should work through more of the text from the toolbar. Also the text for the verktykasse nfsen, here I suggest: "NFSen integrates with NAV to analyze and display your netflow traffic data"
That would be a welcome revision :-)
Now to all the private suggestions you sent me yesterday.
On Thu, 11 Sep 2008 16:45:44 +0200 Stein Magnus Jodal stein.magnus.jodal@uninett.no wrote:
We should maybe consider updating tools with beta status in the minor/bugfix releases, and not only in the major releases, as with all other tools. It would be nice for the developers to get user feedback on new features/development more often than every sixth month and I think we all can live with the beta tools beeing a bit more volatile than the stable tools.
I have no problem with introducing small features into existing code for our micro-releases, but each case will have to be judged separately. I will not allow schema changes into the micro-releases, though. We only do that if there are actual bugs in the schemas themselves, which we've had some problems with in the 3.4.x series.
For the beta tools, I've had no problem with introducing new features willy-nilly into micro-releases, but hardly any new features have been pushed to the 3.4.x series. I won't sit down and cherrypick changesets from the individual feature branches or the default branch at random; the devs themselves need to promote the changesets they feel are worthy for inclusion in 3.4.x. But, we can revisit that theme when 3.5.0 final is released and the 3.5.x series becomes the stable branch.
Personally, I really don't like the Cisco router icon, and try to stick to the Tango icon theme used for most of the tools. I've now changed to a "network server" icon on navdev. A network server is maybe not the most common IP device in a typical NAV setup, but an IP device none the less.
A challenge for you, then, is to stylize a Cisco router icon into a Tango-style icon ;-)
What cases do we have for host lookup in IP Info?
a) Host unknown to NAV (example: 129.241.93.17)
- ipinfo: Shows DNS information.
- ipdevinfo: Shows DNS information.
b) Host known to NAV (example: voldsminde)
- ipinfo: Links to devBrowser. Shows DNS, subnet, vlan, org. Shows ARP and MAC data, and where least seen (switch,module,port).
- ipdevinfo: Shows everything devBrowser does (soon), DNS, subnet, vlan, org. Does not show ARP, MAC, last seen.
c) Host known to NAV and matching rule sin the "local output configuration" (i.e. usage=='sby')
- ipinfo: Same as for b) and additional links to external systems as decided by configuration.
- ipdevinfo: Same as for b).
Any cases I've forgotten, misunderstood or which are incomplete?
For case b), ipdevinfo can get the missing data quite easily.
For case c), if one can live without this feature either permanently or hidden from the toolbox for some time, we can surely remove the ipinfo tool from the toolbox without linking to it at all. Alternatively, one could link to ipinfo from the "Actions" list in ipdevinfo until this last ipinfo feature are added to ipdevinfo.
For 3.5.0, I vote for your alternative solution. That is, if the actions list is also present when searching for a host unknown to NAV.
Some of the information (arp/mac/lastseen) displayed by ipinfo is downright confusing to some, since there can be an absolute mismatch between the arp and cam records used in the display. The arp record could be five weeks old, while the cam record is current, meaning that the IP is not active and the machine that last had it now probably has a different IP altogether.
The only reason all this information was mashed together in a single view was to enable the local output configuration, which can use all the variables from an ipinfo page to construct its output.
NTNU will definitely miss the local output configuration. They need it to link to an external web application which contains information about the dormitory address a switchport is patched through to, and a record of which student lives at that address.
The ipinfo tool was originally written as a generic means to achieve this functionality.
What we've previously discussed is to rewrite this local output configuration feature into something more specific. The idea is to implement some sort of hook or configuration ability into NAV, which will enable a NAV administrator to define templates for linking to external information about a given port.
It should also be possible to define what criteria need to be present for a template to be used and displayed. Using the specific example from NTNU's needs, a link to said external web application should be displayed if a port is on a specific set of subnets which belong to the student dormitories.
Candidate pages for displaying such a link is the port details view in ipdevinfo, and result rows in the machine tracker (the latter is a request from NTNU because they don't want to click through from the machine tracker to the port details page to find the link).
I think we should wait with changing links from /browse to /ipdevinfo in case ipdevinfo does not satisfy all needs covered by devBrowser at the time of release. (I'd prefer timeboxing to featureboxing. Take features out instead of pushing the release date.)
I've always had a predilection for timeboxing, which we've tried to apply to NAV. However, my experience is that we've delayed many NAV feature releases because we had no significant features finished in time for the release.
For the 3.5.0 release, the rewritten alert profiles and alert engine subsystems are a must. 3.5 will not be released without them.
Also, if a feature is not complete in time for 3.5, and is not a good candidate for inclusion in a stable micro-release, it could very well be that we will shorten the waiting time for a 3.6 release, while pushing back some of the existing goals for 3.6 until 3.7. Being a very small development group, I think we can afford that level of luxury and flexibility :)
Anyway, there is no hurt in preparing a patch to fix all the links, and then commit it when ipdevinfo is ready.
Further, let i.e. Jørgen's changes to the report tool be merged to the default branch before we change any of that code.
I merged the default branch onto Jørgen's report branch yesterday. It is just a short code review away from being pushed to the default branch.
On Fri, 2008-09-12 at 10:39 +0200, Morten Brekkevold wrote:
What cases do we have for host lookup in IP Info?
a) Host unknown to NAV (example: 129.241.93.17)
- ipinfo: Shows DNS information.
- ipdevinfo: Shows DNS information.
b) Host known to NAV (example: voldsminde)
- ipinfo: Links to devBrowser. Shows DNS, subnet, vlan, org. Shows ARP and MAC data, and where least seen (switch,module,port).
- ipdevinfo: Shows everything devBrowser does (soon), DNS, subnet, vlan, org. Does not show ARP, MAC, last seen.
c) Host known to NAV and matching rule sin the "local output configuration" (i.e. usage=='sby')
- ipinfo: Same as for b) and additional links to external systems as decided by configuration.
- ipdevinfo: Same as for b).
Any cases I've forgotten, misunderstood or which are incomplete?
Nothing? I'm a bit surprised if I have an approximately complete understanding of IP Info already. Lets get back to it when I'll start working on replacing IP Info.
For case b), ipdevinfo can get the missing data quite easily.
For case c), if one can live without this feature either permanently or hidden from the toolbox for some time, we can surely remove the ipinfo tool from the toolbox without linking to it at all. Alternatively, one could link to ipinfo from the "Actions" list in ipdevinfo until this last ipinfo feature are added to ipdevinfo.
For 3.5.0, I vote for your alternative solution. That is, if the actions list is also present when searching for a host unknown to NAV.
Fixed, for both known and unknown hosts.
Some of the information (arp/mac/lastseen) displayed by ipinfo is downright confusing to some, since there can be an absolute mismatch between the arp and cam records used in the display. The arp record could be five weeks old, while the cam record is current, meaning that the IP is not active and the machine that last had it now probably has a different IP altogether.
The only reason all this information was mashed together in a single view was to enable the local output configuration, which can use all the variables from an ipinfo page to construct its output.
So, I should not add any of these (arp/mac/lastseen) to the IP device view?
NTNU will definitely miss the local output configuration. They need it to link to an external web application which contains information about the dormitory address a switchport is patched through to, and a record of which student lives at that address.
The ipinfo tool was originally written as a generic means to achieve this functionality.
I'll leave this as is until devBrowser is completely replaced.
What we've previously discussed is to rewrite this local output configuration feature into something more specific. The idea is to implement some sort of hook or configuration ability into NAV, which will enable a NAV administrator to define templates for linking to external information about a given port.
It should also be possible to define what criteria need to be present for a template to be used and displayed. Using the specific example from NTNU's needs, a link to said external web application should be displayed if a port is on a specific set of subnets which belong to the student dormitories.
I think we'll have to discuss this a bit when I'm ready to start working on it.
Candidate pages for displaying such a link is the port details view in ipdevinfo, and result rows in the machine tracker (the latter is a request from NTNU because they don't want to click through from the machine tracker to the port details page to find the link).
Both seems reasonable.
On Fri, 12 Sep 2008 11:53:56 +0200 Stein Magnus Jodal stein.magnus.jodal@uninett.no wrote:
Any cases I've forgotten, misunderstood or which are incomplete?
Nothing? I'm a bit surprised if I have an approximately complete understanding of IP Info already. Lets get back to it when I'll start working on replacing IP Info.
Vidar posted the scenario you missed: That the IP is not monitored by NAV, but exists in ARP data.
Alternatively, one could link to ipinfo from the "Actions" list in ipdevinfo until this last ipinfo feature are added to ipdevinfo.
For 3.5.0, I vote for your alternative solution. That is, if the actions list is also present when searching for a host unknown to NAV.
Fixed, for both known and unknown hosts.
Confirmed, just what I wanted :-)
Some of the information (arp/mac/lastseen) displayed by ipinfo is downright confusing to some, since there can be an absolute mismatch between the arp and cam records used in the display. The arp record could be five weeks old, while the cam record is current, meaning that the IP is not active and the machine that last had it now probably has a different IP altogether.
The only reason all this information was mashed together in a single view was to enable the local output configuration, which can use all the variables from an ipinfo page to construct its output.
So, I should not add any of these (arp/mac/lastseen) to the IP device view?
To swallow ipinfo functionality into ipdevinfo, yes you do.
So far, all you do is the DNS lookup. For any IP address you can check whether it matches any of the prefices registered in NAV. If it matches, we want to show details about the prefix and the associated VLAN: CIDR of subnet, vlan id, vlan usage, vlan description, vlan organization, and perhaps organizational contact data (opt1-3).
The next thing you can do is check if there are any ARP entries for the given IP address. Instead of doing the ipinfo "confusion-operation" at this point, you could display the end_time timestamp of the latest ARP record that matches the IP address and make that text a hyperlink to the machine tracker IP search.
By implementing this, you'll have replaced all but one feature of the ipinfo tool, and that's the local output config feature. Which we need to rewrite into something else, as described in my previous post.
Writing a blueprint, designing and implementing that in time for 3.5.0, though, is improbable (but not impossible ;) ), which is why we're keeping ipinfo around for the time being.
Stein Magnus Jodal wrote:
On Wed, 2008-09-10 at 09:55 +0200, Vidar Faltinsen wrote:
As I understand it IP Device Info will be feature complete for 3.5 and will be included as a new tool, now also seen from the toolbox.
We'll have to see about that, but I'll do my best.
Your best is good! In effect ipdevinfo will not be much used before we actually swap the links from browse to ipdevinfo in report, and I would very much like to see this for 3.5.
We should maybe consider updating tools with beta status in the minor/bugfix releases, and not only in the major releases, as with all other tools. It would be nice for the developers to get user feedback on new features/development more often than every sixth month and I think we all can live with the beta tools beeing a bit more volatile than the stable tools.
Will you use the RJ45 jack as icon (the one from IP Info center)? Perhaps better with an icon of a switch or something? How about "stealing" the Device Management icon? And then for the new Device History use a faded router icon, perhaps surrounded with a graph or cornered with a clock indicating history?
Personally, I really don't like the Cisco router icon, and try to stick to the Tango icon theme used for most of the tools. I've now changed to a "network server" icon on navdev. A network server is maybe not the most common IP device in a typical NAV setup, but an IP device none the less.
"network server" is approved. Discussed it with Morten also.
In addition - can you find an icon for "Device History"? We should get rid of the router icon here as it gives a too strong indication that this tool has info about a router. A better icon is one that indicates that this is historic information. A timeline of log file icon or something...
Suggestion for the text in toolbox: "IP Device Info displays all recorded information about a given IP address. If the device is a NAV registered switch or router a port view with details on status and activity is also shown"
I've just added: "Displays all recorded information about a given IP device or address. If the device is a NAV registered switch or router a port view with details on status and activity is also shown."
ok
Even if you are not reimplementing IP Info Center, is it possible to remove this as a tool from the toolbox and instead invoke the tool from the query page of ipdevinfo, in the case the given ip is not a NAV registered box?
I think leaving the two tools in the toolbox will confuse users (as indeed is the reason for merging the tools in the end).
What cases do we have for host lookup in IP Info?
a) Host unknown to NAV (example: 129.241.93.17)
- ipinfo: Shows DNS information.
- ipdevinfo: Shows DNS information.
b) Host known to NAV (example: voldsminde)
- ipinfo: Links to devBrowser. Shows DNS, subnet, vlan, org. Shows ARP and MAC data, and where least seen (switch,module,port).
- ipdevinfo: Shows everything devBrowser does (soon), DNS, subnet, vlan, org. Does not show ARP, MAC, last seen.
c) Host known to NAV and matching rule sin the "local output configuration" (i.e. usage=='sby')
- ipinfo: Same as for b) and additional links to external systems as decided by configuration.
- ipdevinfo: Same as for b).
Any cases I've forgotten, misunderstood or which are incomplete?
On b) there are two cases:
b1) known to NAV as a registered NAV device b2) known to NAV, but only as found in the ARP data and possibly the CAM data
Anyway, I agree with Morten's conclusion, that we can remove ipinfo from the tool box, but that we always should provide a link from ipdevinfo as Morten explained, i.e. from your "Action row" with the extra bullet: "View in IP info"
Actually - as I write - you have implemented this. Wow :)
- Vidar
Vidar Faltinsen wrote:
In addition - can you find an icon for "Device History"? We should get rid of the router icon here as it gives a too strong indication that this tool has info about a router. A better icon is one that indicates that this is historic information. A timeline of log file icon or something...
Perhaps your server icon with your magnifying glass on top, as you do it for syslog analyzer?
- Vidar
On Fri, 2008-09-12 at 11:44 +0200, Vidar Faltinsen wrote:
Vidar Faltinsen wrote:
In addition - can you find an icon for "Device History"? We should get rid of the router icon here as it gives a too strong indication that this tool has info about a router. A better icon is one that indicates that this is historic information. A timeline of log file icon or something...
Perhaps your server icon with your magnifying glass on top, as you do it for syslog analyzer?
Icon created and committed to the default branch.
Magnus, which owns the Device History branch, may change his tool file to use: icon=/images/toolbox/tools/devicehistory.png
(I've temporarily patched the installed tool file at navdev to use the icon.)
-
Morten Brekkevold -
Stein Magnus Jodal -
Vidar Faltinsen