[Xymon] Strange MACHINE vs. CLIENTHOSTNAME behavior, Terebithia Xymon 4.3.28-0.6.1.el5

[J.C. Cleaver]

On Mon, January 9, 2017 4:39 pm, Ryan Novosielski wrote:
> Having an odd problem that I’m having trouble tracking down on an
> RHEL5.11 machine. The symptom is that the client shows with the real
> hostname, which is one I don’t want displaying on the Xymon website and,
> even though I’ve changed the name in the client, my one external script
> that uses $MACHINE/$MACHINEDOTS is sending as the actual server name. I
> define $CLIENTHOSTNAME in /etc/sysconfig/xymon-client, which is looped in
> by an include at the top of /etc/xymon/xymonclient.cfg. I see in
> /usr/libexec/xymon-client/xymonclient.sh that if $CLIENTHOSTNAME exists,
> $MACHINE/$MACHINEDOTS ought to make use of it. However,
> $MACHINE/$MACHINEDOTS are still my real hostname.
>
> Any suggestions? I don’t really understand how this could be happening.


Unfortunately, I believe this is actually a logic flaw on my side.

The problem (and I didn't realize it was one until now) stems from the
move of the CLIENTHOSTNAME logic from pre-execution of the client's
xymonlaunch into the xymonclient.sh script. That's all fine and well for
the existing (standard) client, but external scripts that are running
directly (via xymonlaunch) don't have the same logic prefix any more --
they'd have to handle it themselves.

(xymoncmd is capable of handling this, but it's always configured all
default values before loading environment files -- including, via include,
/etc/sysconfig/xymon-client.)


There are two possible workarounds here -- neither of them great. The
first is to add these two variable entries manually into
/etc/sysconfig/xymon-client after the client line:

CLIENTHOSTNAME="foobar.example.com"
MACHINEDOTS="$CLIENTHOSTNAME"
MACHINE="foobar,example,com"


The second would be to trick xymoncmd into doing the right thing by adding
this to /etc/sysconfig/xymonlaunch:

export MACHINEDOTS=foobar.example.com


This will apply the change early enough to affect everything -- including
any server-side processes you might have running (if this is also a xymond
server). Because we have commas in $MACHINE, it's more difficult to handle
using the pseudo-shell syntax available in our own .cfg files.

You'll need to bounce the xymon-client service after either change.


I'm not sure what the best way to handle this going forward is since
there's some chicken-and-egg with reading environments to begin with. It
might be something best special-cased as part of all environment file
reading (instead of just xymoncmd). (A bash-like "assign if undefined"
operator might be a useful additional syntax.)


4.4 has a radically different environment load section (each binary has
the potential to try to set its own environment) but also appears to show
the same symptoms at the moment.


HTH,
-jc