hosts.cfg "mutlihomed" tag broken?
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
On 3/25/2015 7:53 PM, Gavin Stone-Tolcher wrote:
- snip -
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.
It is working in my installation of 4.3.17 where I have entries of the sort: 0.0.0.0 foo.bar.com # multihomed 0.0.0.0 baz.bar.com # ssh multihomed
What are the symptoms which lead you to believe the tag is not working? In my case, prior to appending this tag to the hosts, I was getting "Multi-source statuses" under the xymond test reported on my server.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
Gavin
I fear you may have misunderstood the purpose of multihomed. It only suppresses a log message. It doesn't override access restrictions imposed by running xymond with "--status-senders".
On 26 Mar 2015 2:54 pm, "Gavin Stone-Tolcher" <g.stone-tolcher at its.uq.edu.au> wrote:
By default, Xymon will warn if it sees data for one host coming
from different
The man page you quoted says "warn" not "reject".
169 xmh_item_key[XMH_FLAG_MULTIHOMED] = "MULTIHOMED";
Is that looking for “MULTIHOMED” in CAPS, not “multihomed” lowercase?
Yes. But elsewhere is code that parses the hosts.cfg file to find multihomed and then set MULTIHOMED.
Also, should line 170 have "XMH_FLAG_MULTIHOMED" rather than "XMH_MULTIHOMED"
No because it's setting the item name not the item key.
Xymon will be using some forms of the name as internal variable names and environment variables and so they might not mean what you think they mean.
Doing a xymondborad query against a host with “multihome” produces no result for that field:
Is it "multihome" like you have here or is it "multihomed"?
xymon localhost "xymondboard host=pf-parkingguide.pf.uq.edu.au fields=XMH_FLAG_MULTIHOMED"
I think this should work. What do you get from "xymongrep multihomed"? What do you get from your xymondboard command if you don't specify "fields=..."?
This section in xymond.c from line 1520 seems to be the code doing a check that XMH_FLAG_MULTIHOMED is NULL:
Yep. And you'll notice that it all boils down to whether or not to run this line:
log_multisrc(log, sender);
Any ideas on this one? Currently I have to add multihomed hosts to “--status-senders” otherwise.
You could disable --statussenders. Or you could add dummy host entries with the alternate IP addresses.
J
Is it "multihome" like you have here or is it "multihomed"?
Yes that extra “d” really does make a difference! I was using “multihome” in my hosts.cfg. My only excuse is I must not have had enough caffeine. I also apologise for my inept attempts at interpreting c code ☹
You could disable --statussenders. Or you could add dummy host entries with the alternate IP addresses.
Hmm, seems I misunderstand what “multihomed” is supposed to do. I thought it would allow a multihomed client to report in from more than one IP without the addition of said IPs to xymond “–status-senders”.
We have a quite a few multihomed windows systems where for some reason the default interface for transmission seems to randomly change. The MS guys responsible for the systems don’t seem to be able to configure it them to come from the same IP reliably. This seems to particularly be the case if the IPs are on the same subnet and interface. I just want the client tests to not turn purple when this happens and continue working. I point out that we are mainly still running the old BBNT client, slowly migrating to Powershell Xymon client. I would prefer not disabling the “—status-senders” if at all possible. Maybe this is not possible?
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
From: Jeremy Laidman [mailto:jlaidman at rebel-it.com.au] Sent: Friday, 27 March 2015 6:37 AM To: Gavin Stone-Tolcher Cc: xymon at xymon.com Subject: Re: [Xymon] hosts.cfg "mutlihomed" tag broken?
Gavin
I fear you may have misunderstood the purpose of multihomed. It only suppresses a log message. It doesn't override access restrictions imposed by running xymond with "--status-senders".
On 26 Mar 2015 2:54 pm, "Gavin Stone-Tolcher" <g.stone-tolcher at its.uq.edu.au<mailto:g.stone-tolcher at its.uq.edu.au>> wrote:
By default, Xymon will warn if it sees data for one host coming from different
The man page you quoted says "warn" not "reject".
169 xmh_item_key[XMH_FLAG_MULTIHOMED] = "MULTIHOMED";
Is that looking for “MULTIHOMED” in CAPS, not “multihomed” lowercase?
Yes. But elsewhere is code that parses the hosts.cfg file to find multihomed and then set MULTIHOMED.
Also, should line 170 have "XMH_FLAG_MULTIHOMED" rather than "XMH_MULTIHOMED"
No because it's setting the item name not the item key.
Xymon will be using some forms of the name as internal variable names and environment variables and so they might not mean what you think they mean.
Doing a xymondborad query against a host with “multihome” produces no result for that field:
Is it "multihome" like you have here or is it "multihomed"?
xymon localhost "xymondboard host=pf-parkingguide.pf.uq.edu.au<http://pf-parkingguide.pf.uq.edu.au> fields=XMH_FLAG_MULTIHOMED"
I think this should work. What do you get from "xymongrep multihomed"? What do you get from your xymondboard command if you don't specify "fields=..."?
This section in xymond.c from line 1520 seems to be the code doing a check that XMH_FLAG_MULTIHOMED is NULL:
Yep. And you'll notice that it all boils down to whether or not to run this line:
log_multisrc(log, sender);
Any ideas on this one? Currently I have to add multihomed hosts to “--status-senders” otherwise.
You could disable --statussenders. Or you could add dummy host entries with the alternate IP addresses.
J
On 27 Mar 2015 11:09 am, "Gavin Stone-Tolcher" < g.stone-tolcher at its.uq.edu.au> wrote:
Is it "multihome" like you have here or is it "multihomed"?
Yes that extra “d” really does make a difference!
Glad you got it worked out. Caffeine always helps.
Hmm, seems I misunderstand what “multihomed” is supposed to do. I thought it would allow a multihomed client to report in from more than one IP without the addition of said IPs to xymond “–status-senders”.
If this were the case then there wouldn't be much point setting --status-senders at all. Any host that was tagged multihomed would be vulnerable to spoofed status messages. If you're going to allow other addresses but not all addresses then you have to specify the other addresses somewhere.
Perhaps create a new page that you don't display anywhere, and add the alternative IP addresses with the same hostname but with nodisp, noconn and dialup. It's not illegal to define a hostname twice.
J
participants (3)
-
g.stone-tolcher＠its.uq.edu.au
-
jlaidman＠rebel-it.com.au
-
john.thurston＠alaska.gov