[Xymon] hosts.cfg "mutlihomed" tag broken?

[Gavin Stone-Tolcher]

>From man hosts.cfg
GENERAL PER-HOST OPTIONS
multihomed
          Tell Xymon that data from the host can arrive from multiple IP-adresses.
          By default, Xymon will warn if it sees data for one host coming from different
          IP-adresses, because this usually indicates a mis-configuration of the hostname
          on at least one of the servers involved. Some hosts with multiple IP-adresses
          may use different IPâs  for  sending  data  to Xymon, however. This tag disables
          the check of source IP when receiving data.

In my testing, it appears the "multihomed" hosts.cfg tag is broken. i.e does not allow a client to report in if it comes from an alternate IP on that host.

Looking at 4.3.18 code.

I see in lib/loadhosts.c:

169 xmh_item_key[XMH_FLAG_MULTIHOMED]      = "MULTIHOMED";
170 xmh_item_name[XMH_FLAG_MULTIHOMED] = "XMH_MULTIHOMED";

Is that looking for "MULTIHOMED" in CAPS, not "multihomed" lowercase?

Also, should line 170 have "XMH_FLAG_MULTIHOMED" rather than "XMH_MULTIHOMED"
e.g.
xmh_item_name[XMH_FLAG_MULTIHOMED] = "XMH_FLAG_MULTIHOMED";

similar items appear to be that way?


"man 5 xymon-xmh" suggests the relevant xmh item should be:

XMH_FLAG_MULTIHOMED
              Value of the MULTIHOMED tag.


Doing a xymondborad query against a host with "multihome" produces no result for that field:

xymon localhost "xymondboard host=pf-parkingguide.pf.uq.edu.au fields=XMH_FLAG_MULTIHOMED"



This section in xymond.c from line 1520 seems to be the code doing a check that XMH_FLAG_MULTIHOMED is NULL:
xymond/xymond.c


1520           /*

                * If we have an existing status, check if the sender has changed.

                * This could be an indication of a mis-configured host reporting with

                * the wrong hostname.

                */

               if (*(log->sender) && (strcmp(log->sender, sender) != 0)) {

                       /*

                        * There are a few exceptions:

                        * - if sender is "xymond", then this is an internal update, e.g. a status going purple.

                        * - if the host has "pulldata" enabled, then the sender shows up as the host doing the

                        *   data collection, so it does not make sense to check it (thanks to Cade Robinson).

                        * - some multi-homed hosts use a random IP for sending us data.

                        */

                       if ( (strcmp(log->sender, "xymond") != 0) && (strcmp(sender, "xymond") != 0) && (strcmp(sender, "0.0.0.0") != 0))  {

                               if ((xmh_item(hinfo, XMH_FLAG_PULLDATA) == NULL) && (xmh_item(hinfo, XMH_FLAG_MULTIHOMED) == NULL)) {

                                      log_multisrc(log, sender);

                               }

                       }

               }

               strncpy(log->sender, sender, sizeof(log->sender)-1);

               *(log->sender + sizeof(log->sender) - 1) = '\0';

        }


Any ideas on this one? Currently I have to add multihomed hosts to "--status-senders" otherwise.


Cheers,
Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response
Information Technology Services
The University of Queensland
Level 4, Prentice Building, St Lucia 4072
T: +61 7 334 66645, M: +61 401 140 838
E: g.stone-tolcher at its.uq.edu.au<mailto:g.stone-tolcher at its.uq.edu.au> W: www.its.uq.edu.au<http://www.its.uq.edu.au>

ITS: Service. Team. Accountability. Results.

IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include.

Please consider the environment before printing this email.

CRICOS Code 00025B

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20150326/229a2d99/attachment.html>