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 `'