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

[Ryan Novosielski]

On Jan 10, 2017, at 00:31, J.C. Cleaver <cleaver at terabithia.org<mailto:cleaver at terabithia.org>> wrote:

On Mon, January 9, 2017 4:39 pm, Ryan Novosielski wrote:
Having an odd problem that I??Tm 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??Tt want displaying on the Xymon website and,
even though I??Tve 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??Tt 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<http://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<http://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.

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).

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?

--
____
|| \\UTGERS,       |---------------------------*O*---------------------------
||_// the State     |         Ryan Novosielski - novosirj at rutgers.edu<mailto:novosirj at rutgers.edu>
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ     | Office of Advanced Research Computing - MSB C630, Newark
    `'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20170110/fd33e0a7/attachment.html>