<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>On Jan 10, 2017, at 00:31, J.C. Cleaver <<a href="mailto:cleaver@terabithia.org">cleaver@terabithia.org</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><span>On Mon, January 9, 2017 4:39 pm, Ryan Novosielski wrote:</span><br>
<blockquote type="cite"><span>Having an odd problem that Iâ?Tm having trouble tracking down on an</span><br>
</blockquote>
<blockquote type="cite"><span>RHEL5.11 machine. The symptom is that the client shows with the real</span><br>
</blockquote>
<blockquote type="cite"><span>hostname, which is one I donâ?Tt want displaying on the Xymon website and,</span><br>
</blockquote>
<blockquote type="cite"><span>even though Iâ?Tve changed the name in the client, my one external script</span><br>
</blockquote>
<blockquote type="cite"><span>that uses $MACHINE/$MACHINEDOTS is sending as the actual server name. I</span><br>
</blockquote>
<blockquote type="cite"><span>define $CLIENTHOSTNAME in /etc/sysconfig/xymon-client, which is looped in</span><br>
</blockquote>
<blockquote type="cite"><span>by an include at the top of /etc/xymon/xymonclient.cfg. I see in</span><br>
</blockquote>
<blockquote type="cite"><span>/usr/libexec/xymon-client/xymonclient.sh that if $CLIENTHOSTNAME exists,</span><br>
</blockquote>
<blockquote type="cite"><span>$MACHINE/$MACHINEDOTS ought to make use of it. However,</span><br>
</blockquote>
<blockquote type="cite"><span>$MACHINE/$MACHINEDOTS are still my real hostname.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Any suggestions? I donâ?Tt really understand how this could be happening.</span><br>
</blockquote>
<span></span><br>
<span>Unfortunately, I believe this is actually a logic flaw on my side.</span><br>
<span></span><br>
<span>The problem (and I didn't realize it was one until now) stems from the</span><br>
<span>move of the CLIENTHOSTNAME logic from pre-execution of the client's</span><br>
<span>xymonlaunch into the xymonclient.sh script. That's all fine and well for</span><br>
<span>the existing (standard) client, but external scripts that are running</span><br>
<span>directly (via xymonlaunch) don't have the same logic prefix any more --</span><br>
<span>they'd have to handle it themselves.</span><br>
<span></span><br>
<span>(xymoncmd is capable of handling this, but it's always configured all</span><br>
<span>default values before loading environment files -- including, via include,</span><br>
<span>/etc/sysconfig/xymon-client.)</span><br>
<br>
<span>There are two possible workarounds here -- neither of them great. The</span><br>
<span>first is to add these two variable entries manually into</span><br>
<span>/etc/sysconfig/xymon-client after the client line:</span><br>
<span></span><br>
<span>CLIENTHOSTNAME="<a href="http://foobar.example.com">foobar.example.com</a>"</span><br>
<span>MACHINEDOTS="$CLIENTHOSTNAME"</span><br>
<span>MACHINE="foobar,example,com"</span><br>
<br>
<span>The second would be to trick xymoncmd into doing the right thing by adding</span><br>
<span>this to /etc/sysconfig/xymonlaunch:</span><br>
<span></span><br>
<span>export MACHINEDOTS=<a href="http://foobar.example.com">foobar.example.com</a></span><br>
<br>
<span>This will apply the change early enough to affect everything -- including</span><br>
<span>any server-side processes you might have running (if this is also a xymond</span><br>
<span>server). Because we have commas in $MACHINE, it's more difficult to handle</span><br>
<span>using the pseudo-shell syntax available in our own .cfg files.</span><br>
<span></span><br>
<span>You'll need to bounce the xymon-client service after either change.</span><br>
<span></span><br>
<span></span><br>
<span>I'm not sure what the best way to handle this going forward is since</span><br>
<span>there's some chicken-and-egg with reading environments to begin with. It</span><br>
<span>might be something best special-cased as part of all environment file</span><br>
<span>reading (instead of just xymoncmd). (A bash-like "assign if undefined"</span><br>
<span>operator might be a useful additional syntax.)</span><br>
<br>
<span>4.4 has a radically different environment load section (each binary has</span><br>
<span>the potential to try to set its own environment) but also appears to show</span><br>
<span>the same symptoms at the moment.</span><br>
</div>
</blockquote>
<div><br>
</div>
I'm happy enough to know that it wasn't my mistake (I really looked at this for way too long, just a couple of days after trying to figure out why a hostname change in hosts.cfg wasn't working only to discover my config files all pointed to bb-hosts which somehow
unbecame a symlink during my last update -- argh).
<div><br>
</div>
<div>My temporary solution was adding MACHINE=$CLIENTHOSTNAME at the top of the external script, but I agree, those other solutions aren't ideal and I'm not sure I can think of one either. How did this used to work?</div>
<div><br>
<div><span style="background-color: rgba(255, 255, 255, 0);">--<br>
____<br>
|| \\UTGERS, |---------------------------*O*---------------------------<br>
||_// the State | Ryan Novosielski - <a dir="ltr" href="mailto:novosirj@rutgers.edu" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="18">novosirj@rutgers.edu</a><br>
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus<br>
|| \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark<br>
`'</span></div>
</div>
</body>
</html>