<div class="gmail_quote">On Wed, May 16, 2012 at 4:15 AM, Michael Beatty <span dir="ltr"><<a href="mailto:Michael.Beatty@sherwin.com" target="_blank">Michael.Beatty@sherwin.com</a>></span> wrote:<br><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

However, the hostname on that system is generic and doesn't resolve to<br>
the correct DNS.  In other words the host name on that system (1.2.3.4)<br>
is hostname.  However, "hostname" resolves over the network as 4.3.2.1.<br>
So, when the ping test runs, it runs for 4.3.2.1.</blockquote><div><br></div><div>You can add "testip" to the hosts.cfg file on the server, and it will use the IP address defined in hosts.cfg rather than what's in the DNS.  See the "Testing sites by IP-address" section in the hosts.cfg(5) man page.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">   Another thing to<br>
note is that on the ghost screen, there is a ghost showing as reporting<br>
from that host... but also shows that the same host name is a<br>
Candidate.  How do I tell Xymon that they are the same thing?<br></blockquote><div><br></div><div>Xymon will extract the name from the status message and look it up in the hosts.cfg file, tring to match it exactly.  The most common problem with this is when one side uses the FQDN and the other side uses the short name, and this can be remedied by adding a "CLIENT:othername" setting in hosts.cfg.  However, in your case it appears that both are the same.  I would double-check the status messages as they get to the server with something like this:</div>

<div><br></div><div>  sudo -u xymon xymond_channel --channel=status grep "^status"</div><div><br></div><div>This will show you every status message coming to the server, including the full hostname being presented (with dots replaced by commas).  You can then compare with the entry in hosts.cfg and confirm that they match exactly.  You might need to check both status and data channels.</div>

<div><br></div><div>Alternatively, you can add "--ghosts=allow" to the execution of xymond (in tasks.cfg) to let these in, or use "--ghosts=match" to have xymond try to match after stripping the domain names.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am having another problem on the client whereas I'm getting a<br>
"connection refused" when trying to send the the xymon command.  I have<br>
to assume this means that this is local to that machine.  However, I've<br>
got my firewall turned off, so I'm not sure I understand how that can be.</blockquote><div><br></div><div>What is the command-line you're using for the xymon command?  You'd get a "connection refused" message if you're specifying localhost as the second parameter to "xymon" instead of specifying the server IP address (or $XYMSRV).</div>

<div><br></div><div>You might get more information about the problem by appending "--debug".</div><div><br></div><div>Cheers</div><div>Jeremy</div><div><br></div></div>