#142 device details shows incorrect device in some cases

[Alexander Demenshin]

Hi,

I had some exotic problem, caused by incorrect DNS mapping, which led to weird result - I click on device, but see details of completely different device.

The problem:

• I've device Y which has IP 10.0.0.1, and DNS name Y maps to this IP and vice versa.
• I've device X which has IP 10.0.0.2, and this IP has a PTR to Y (yes, misconfiguration)
• Device X gets into device_ip table and has "dns" column set to "Y"
• Device view correctly finds Y (as there is only one entry in "device" table for this name), but then tab "details" makes search again, and this time it is searching also in "device_ip.dns"
• this way, device X gets into sight and, due to ordering by DNS name ("X" < "Y"), it is the first one in the result set

So, query "/device?tab=details&q=Y&f=" returns details for X.

On one hand, this is a problem of incorrect DNS configuration. On the other hand, since this kind of misconfiguration is not so uncommon, it would be nice to correctly handle such cases, and I see two possible solutions:

• /device view must search exactly as other tabs do it (this is how I fixed it for myself)
• /device?tab=details (and other tabs) must use only result of original search

[Oliver Gorwits]

Hi Alexander,

I don't think I understand your explanation fully. You have used the letter Y to mean both the device Y and the DNS name Y ?

Also what is /device url? Do you mean /search?tab=device ?

I'm reluctant to alter the behaviour of Netdisco unless Netdisco itself is shown to be wrong in some way. I think your DNS is misconfigured and you should fix that. I don't think Netdisco is misbehaving.

If you can provide a better explanation and perhaps a patch, it might help.

regards,
oliver.

[Alexander Demenshin]

Hi Oliver,

Yes, both X and Y are DNS names. To make it clear, DNS is configured as follows:

X. A 10.0.0.2
Y. A 10.0.0.1
1.0.0.10.in-addr.arpa. PTR Y.
2.0.0.10.in-addr.arpa. PTR Y.

In other words, there are two PTR records which point to same name - yes, this is misconfiguration (though completely legal), but Netdisco should not choose blindly "first fit" when there is ambiguity.

/device URL is, well... /device, handled by App::Netdisco::Web::Device - query looks like /device?q=Y (there is only one entry with DNS name Y and this IP), and then switches to detail view (/device?tab=details&q=Y&f= - in App::Netdisco::Web::Plugin::Device::Details), where it again searches for device:

    my $device = schema('netdisco')->resultset('Device')
      ->search_for_device($q) or send_error('Bad device', 400);

This is exactly where the "magic" happens - search_for_device, given value Y in $q, will find this name not only in table "device" (column "dns"), but also in table "device_ip" (column "alias") - but with IP that belongs to X - and from this point result returns details for device X due to "order by" clause (as "X" < "Y").

Patch to fix this issue is trivial (and it should not break anything), it simply makes the search exactly like search_for_device does it:

--- lib/App/Netdisco/Web/Device.pm-  2014-08-25 16:05:20.000000000 +0200
+++ lib/App/Netdisco/Web/Device.pm   2014-09-05 12:57:35.000000000 +0200
@@ -173,7 +173,12 @@
     # if passed dns, need to check for duplicates
     # and use only ip for q param, if there are duplicates.
     my $first = $dev->first;

-    my $others = ($schema->search({dns => $first->dns})->count() - 1);
+    my $others = (
+        $schema->search(
+            { -or => [ 'me.dns' => $first->dns, 'device_ips.dns' => $first->dns ] },
+            { distinct => 1, join => 'device_ips' },
+        )->count() - 1
+    );

     params->{'tab'} ||= 'details';
     template 'device', {

Perhaps, better fix would be to avoid search again if device is already known.