Pretty sure FQDN or not is asked when you compile the server.<br><br clear="all">Josh Luthman<br>Office: 937-552-2340<br>Direct: 937-552-2343<br>1100 Wayne St<br>Suite 1337<br>Troy, OH 45373<br><br>"When you have eliminated the impossible, that which remains, however improbable, must be the truth."<br>
--- Sir Arthur Conan Doyle<br>
<br><br><div class="gmail_quote">On Fri, Sep 18, 2009 at 11:42 AM, Ryan Novosielski <span dir="ltr"><<a href="mailto:novosirj@umdnj.edu">novosirj@umdnj.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div><div></div><div class="h5">Buchan Milne wrote:<br>
> ----- "Ryan Novosielski" <<a href="mailto:novosirj@umdnj.edu">novosirj@umdnj.edu</a>> wrote:<br>
><br>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1<br>
>><br>
>> Greg Hubbard wrote:<br>
>>> The CLIENT tag is used to tell the Xymon server how the incoming<br>
>> client<br>
>>> data will be tagged. You use this when your Xymon agent and the<br>
>> Xymon<br>
>>> server do not agree on which name to use -- usually because one<br>
>>> of<br>
>> the<br>
>>> entries has FQDN and the other does not. This is the "cheap fix"<br>
>>><br>
>> for<br>
>>> "ghost" clients -- see the ghost report.<br>
>> That's what I figured. On Solaris, it seems I run into this on all<br>
>> of the hosts. uname -n always seems to return a short name. In<br>
>> fact, it does not appear as if Solaris has much of a concept of a<br>
>> domain name,<br>
><br>
> <a href="mailto:bgmilne@merga.ourdomain.com">bgmilne@merga.ourdomain.com</a><br>
> uname -n <a href="http://merga.ourdomain.com" target="_blank">merga.ourdomain.com</a><br>
> <a href="mailto:bgmilne@merga.ourdomain.com">bgmilne@merga.ourdomain.com</a><br>
> hostname <a href="http://merga.telkomsa.net" target="_blank">merga.telkomsa.net</a><br>
> <a href="mailto:bgmilne@merga.ourdomain.com">bgmilne@merga.ourdomain.com</a><br>
> uname -a SunOS <a href="http://merga.ourdomain.com" target="_blank">merga.ourdomain.com</a> 5.9<br>
> Generic_117171-07 sun4u sparc SUNW,Sun-Fire-V210<br>
><br>
> (Of course, don't try 'hostname -d').<br>
<br>
</div></div>Have you been able to find in writing anyplace that the hostname is<br>
supposed to be the FQDN? I haven't been able to, and I've seen a lot of<br>
references to the short name belonging in /etc/hostname.<if> and<br>
/etc/nodename. Most OS' separate hostname and domain name out, but it<br>
would seem that using the FQDN would at least fix the problems that<br>
require me to use CLIENT: on Solaris machines in my setup.<br>
<div><div></div><div class="h5"><br>
>> Apparently not, and in my opinion, this is somewhat broken, unless<br>
>> I'm misconfiguring something. Xymon appears to only have one notion<br>
>> of a "server." If you're running a network test machine, it asks<br>
>> you for your server name (example pasted):<br>
>><br>
>> BBSERVERHOSTNAME="<a href="http://xymon.umdnj.edu" target="_blank">xymon.umdnj.edu</a>" # The hostname of<br>
>> your server BBSERVERIP="130.219.34.102" # The<br>
>> IP-address of your server. Use the real one, not 127.0.0.1 .<br>
>> BBSERVEROS="sunos" # The operating system of<br>
>> your server. linux,freebsd,solaris,hpux,aix,osf<br>
>><br>
>> The "bbtest" test, with a solely "BBNET" machine configured this<br>
>> way, appears as if it comes from the "BBNET" machine (status<br>
>> message received from IP is the "BBNET" machine), but the test<br>
>> shows up under whatever server name is defined in those above<br>
>> variables in hobbitserver.cfg.<br>
><br>
> You only set *one* of those, BBSERVERHOSTNAME, which it uses in the<br>
> status message, which it sends to BBSERVERIP.<br>
><br>
> See e.g. line 2321 of bbnet/bbtest-net.c sprintf(msgline, "status<br>
> %s.%s %s %s\n\n", xgetenv("MACHINE"), egocolumn, colorname(color),<br>
> timestamp);<br>
><br>
> (In lib/environ.c, MACHINE is created from MACHINEDOTS if MACHINE<br>
> does not exist, and by default MACHINEDOTS=$BBSERVERHOSTNAME in<br>
> hobbitserver.cfg).<br>
><br>
> I guess the descriptions of BBSERVERHOSTNAME and BBSERVERIP could be<br>
> improved in hobbitserver.cfg and hobbitserver.cfg(5), and<br>
> BBSERVERHOSTNAME could possibly default to the machine's hostname<br>
> instead ...<br>
><br>
> BBSERVERHOSTNAME is the name of the host running that instance of<br>
> xymon as you would like it to be displayed in any messages about the<br>
> xymon processes, and BBSEVERIP is the IP of the Xymon server (hobbitd<br>
> or bbproxy) to which all status messages should be sent.<br>
<br>
</div></div>OK, this makes a huge difference. Note that even the description is<br>
written to re-inforce that these both should be the same value:<br>
<div class="im"><br>
# The hostname of your server<br>
</div><div class="im"># The IP-address of your server. Use the real one, not 127.0.0.1 .<br>
<br>
</div>...assuming that "your server"="your server", as well as the fact that<br>
both say BBSERVER*=BBSERVER*. That is one thing that I'd alluded to<br>
earlier: the terminology that BB uses to call the BBDISPLAY machine and<br>
the BBNET machine make it clear what to put in the various config<br>
options. If they both reside on the same machine, it's obvious what to<br>
do, as opposed to the reverse (if they both say one machine and you've<br>
got two).<br>
<div class="im"><br>
> I might be able to fix some of these issues in future.<br>
<br>
</div>Should be fairly simple documentation patches. I'm no programmer, but if<br>
that's necessary, I should be able to handle some of it.<br>
<div class="im"><br>
>> If you set that server name to the name of the BBNET machine, as I<br>
>> expected I was supposed to do initially, you get "connection<br>
>> refused" errors, as it tries to connect to itself and cannot as<br>
>> it's not running the server component that listens on the port.<br>
>><br>
>> I'm starting to believe that while you CAN separate the BBNET and<br>
>> BBDISPLAY nodes with Xymon, no one is really doing it and it<br>
>> doesn't work that cleanly.<br>
><br>
> I've been doing it since hobbit-4.1.0, and I have had no problems<br>
> (with more complex setups including bbproxy to have a staged<br>
> migration from bb).<br>
<br>
</div>Thrilled to stand corrected. The changes I've made so far have made a<br>
difference. I guess we'll see going forward if I run into anything else.<br>
I'm running 4.2.3 incidentally, so I suppose it's possible that the<br>
latest changes are not in my version if any have been made.<br>
<div class="im"><br>
- --<br>
---- _ _ _ _ ___ _ _ _<br>
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II<br>
|$&| |__| | | |__/ | \| _| |<a href="mailto:novosirj@umdnj.edu">novosirj@umdnj.edu</a> - 973/972.0922 (2-0922)<br>
\__/ Univ. of Med. and Dent.|IST/CST - NJMS Medical Science Bldg - C630<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org" target="_blank">http://enigmail.mozdev.org</a><br>
<br>
</div>iEYEARECAAYFAkqzqmYACgkQmb+gadEcsb4WMwCfWFWRhqIy+PKO/H9KYS/p0LJ/<br>
DuMAoLRhbY33h0/ElWTOi2nbmzrEB9PA<br>
=9tju<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>To unsubscribe from the hobbit list, send an e-mail to<br>
<a href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a><br>
<br></blockquote></div><br>