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