Strange MACHINE vs. CLIENTHOSTNAME behavior, Terebithia Xymon 4.3.28-0.6.1.el5
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.
--
|| \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'
This may be too simple and not address your issue, but I have a problem with client names on my SUSE linux systems: uname doesn't return the full (ie FQDN) hostname. uname is what is called in the runclient.sh script:
MACHINEDOTS="`uname -n`" So I insert the following to get the correct name sent to the xymon server:
MACHINEDOTS="`hostname -f`" But this can just be set statically to whatever you like (of course). This is from a client I've compiled, I don't know what the RPM does, but with such an old version of RHat it should still be on SYSV / init and use this (or a similar script). I've never needed to set CLIENTHOSTNAME.
HTHs... Phil
Subject: [Xymon] Strange MACHINE vs. CLIENTHOSTNAME behavior, Terebithia Xymon 4.3.28-0.6.1.el5
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.
--
|| \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'
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
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 `'
When you install using source, it actually puts your hostname in the xymonserver.cfg file. Adding it to /etc/sysconfig/xymon* is not onerous for me. That was actually the first place I looked when I was experiencing a similar issue.
On a side note, for whatever reason, I had to set my hostname to fqdn via hostnamectl before my issue would clear up since both 'uname -n' and 'hostname -f' came up short (pun intended).
=G=
From: Xymon <xymon-bounces at xymon.com> on behalf of Ryan Novosielski <novosirj at rutgers.edu> Sent: Tuesday, January 10, 2017 1:48 AM To: J.C. Cleaver Cc: Xymon Mailing List Subject: Re: [Xymon] Strange MACHINE vs. CLIENTHOSTNAME behavior, Terebithia Xymon 4.3.28-0.6.1.el5
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 `'
participants (4)
-
cleaver＠terabithia.org
-
Galen.Johnson＠sas.com
-
novosirj＠rutgers.edu
-
Phil.Crooker＠orix.com.au