xymon client host name not including domain name in systemd scripts
I've this issue with SUSE linux - SUSE just returns the plain hostname without the domain when it uses uname -n -- the xymon client then doesn't match the FQDN in the xymon hosts.cfg file, the entry goes purple and the client ends up in the ghost report. I'm compiling my own client and inserting the xymonlaunch.service file in /etc/systemd/system, etc -- somehow it doesn't send the correct hostname. I tried adding CLIENTNAME=blah.domain.com in xymonlaunch to no effect (also put it in the xymonclient config file, still no good). If I manually run /bin/hostname with the FQDN, that works, but is lost on the next reboot. And yes I ensured the FQDN is in /etc/hostname, etc... I do not want to have to put in a "CLIENT:whatever" statement in hosts.cfg for every host with a client, which works but is inelegant to me.
Looking at the old runclient.sh script that comes with the client (and is not used with systemd), the MACHINEDOTS variable is set before launch. In the good ol SYS5 init.d days, I used to insert MACHINEDOTS=hostname -f in the runclient.sh script, which worked. So, I found if you run: systemctl edit xymonlaunch.service and add the following, it works:
[Service]
Environment="MACHINEDOTS=whatever.domain.com"This creates a /etc/systemd/system/xymonlaunch.service.d/override.conf file and all is well. Unfortunately it doesn't work with hostname -f. There is a warning that if there is no override.conf in whatever.service.d/ the service won't run. That isn't true with SUSE SLES 12, it works fine w/o it (less the correct name, of course), but YMMV...
HTH Someone, Phil
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
FYI, my experience with RHEL5 was, if the /etc/hosts file had the short-form host name first, that's what the Xymon client used. Switching it around to put the FQDN name first fixed it. Didn't need to modify the Xymon script at all. Kinda ridiculous, I know...
i.e. This checked in to Xymon as "server" 10.12.34.56 server server.domain.com
And this checked in as "server.domain.com"
10.12.34.56 server.domain.com serverDunno if the same thing happens in SuSE, though.
Ralph Mitchell
On Fri, Feb 2, 2018 at 2:01 AM, Phil Crooker <Phil.Crooker at orix.com.au> wrote:
I've this issue with SUSE linux - SUSE just returns the plain hostname without the domain when it uses uname -n -- the xymon client then doesn't match the FQDN in the xymon hosts.cfg file, the entry goes purple and the client ends up in the ghost report. I'm compiling my own client and inserting the xymonlaunch.service file in /etc/systemd/system, etc -- somehow it doesn't send the correct hostname. I tried adding CLIENTNAME= blah.domain.com in xymonlaunch to no effect (also put it in the xymonclient config file, still no good). If I manually run /bin/hostname with the FQDN, that works, but is lost on the next reboot. And yes I ensured the FQDN is in /etc/hostname, etc... I do not want to have to put in a "CLIENT:whatever" statement in hosts.cfg for every host with a client, which works but is inelegant to me.
Looking at the old runclient.sh script that comes with the client (and is not used with systemd), the MACHINEDOTS variable is set before launch. In the good ol SYS5 init.d days, I used to insert MACHINEDOTS=
hostname -fin the runclient.sh script, which worked. So, I found if you run: systemctl edit xymonlaunch.service and add the following, it works:[Service] Environment="MACHINEDOTS=whatever.domain.com"This creates a /etc/systemd/system/xymonlaunch.service.d/override.conf file and all is well. Unfortunately it doesn't work with
hostname -f. There is a warning that if there is no override.conf in whatever.service.d/ the service won't run. That isn't true with SUSE SLES 12, it works fine w/o it (less the correct name, of course), but YMMV...HTH Someone, Phil
*Disclaimer*
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by *Mimecast Ltd*, an innovator in Software as a Service (SaaS) for business. Providing a *safer* and *more useful* place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here <http://www.mimecast.com/products/>.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
An HTML attachment was scrubbed... URL: <http://lists.xymon.com/pipermail/xymon/attachments/20180205/aee89d65/attachment.html>
[ resending in plain-text ] [ apologies to the list for a) the html-email and b) resending (in plain-text) ]
At least on Debian the reported hostname is configured in '/etc/default/xymon-client' (from what is in the rpm-directory of the source the rpm packages have a similar layout).
The contents of 'CLIENTHOSTNAME' in that file is determined at install time of the xymon package(s). So changeing it later des not take effect without additional steps.
Check if you habe '/etc/default/xymon-client' and the content of the variable. If you change thar file do not forget to restart the xymon-client.
All the best Thomas
On 05 Feb 2018, at 07:41, Thomas Eckert <tom at it-eckert.de> wrote:
At least on Debian the reported hostname is configured in '/etc/default/xymon-client' (from what is in the rpm-directory of the source the rpm packages have a similar layout).
The contents of 'CLIENTHOSTNAME' in that file is determined at install time of the xymon package(s). So changeing it later des not take effect without additional steps.
Check if you habe '/etc/default/xymon-client' and the content of the variable. If you change thar file do not forget to restart the xymon-client.
All the best Thomas
The hostname is set in /etc/sysconfig/network and/or /etc/sysconfig/network-scripts/eth0-ifcfg, generally for RHEL 5
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Phil Crooker Sent: Monday, February 05, 2018 12:22 AM To: Ralph Mitchell Cc: xymon at xymon.com Subject: Re: [Xymon] xymon client host name not including domain name in systemd scripts
No, that made no difference - "10.11.12.13 FQDN hostname" is the default order in SuSE, anyway... Interesting.
cheers, P
From: Ralph Mitchell <ralphmitchell at gmail.com<mailto:ralphmitchell at gmail.com>> Sent: Saturday, 3 February 2018 3:24 AM To: Phil Crooker Cc: xymon at xymon.com<mailto:xymon at xymon.com> Subject: Re: [Xymon] xymon client host name not including domain name in systemd scripts
FYI, my experience with RHEL5 was, if the /etc/hosts file had the short-form host name first, that's what the Xymon client used. Switching it around to put the FQDN name first fixed it. Didn't need to modify the Xymon script at all. Kinda ridiculous, I know... i.e. This checked in to Xymon as "server" 10.12.34.56 server server.domain.com<http://server.domain.com> And this checked in as "server.domain.com<http://server.domain.com>" 10.12.34.56 server.domain.com<http://server.domain.com> server Dunno if the same thing happens in SuSE, though. Ralph Mitchell
On Fri, Feb 2, 2018 at 2:01 AM, Phil Crooker <Phil.Crooker at orix.com.au<mailto:Phil.Crooker at orix.com.au>> wrote:
I've this issue with SUSE linux - SUSE just returns the plain hostname without the domain when it uses uname -n -- the xymon client then doesn't match the FQDN in the xymon hosts.cfg file, the entry goes purple and the client ends up in the ghost report. I'm compiling my own client and inserting the xymonlaunch.service file in /etc/systemd/system, etc -- somehow it doesn't send the correct hostname. I tried adding CLIENTNAME=blah.domain.com<http://blah.domain.com> in xymonlaunch to no effect (also put it in the xymonclient config file, still no good). If I manually run /bin/hostname with the FQDN, that works, but is lost on the next reboot. And yes I ensured the FQDN is in /etc/hostname, etc... I do not want to have to put in a "CLIENT:whatever" statement in hosts.cfg for every host with a client, which works but is inelegant to me.
Looking at the old runclient.sh script that comes with the client (and is not used with systemd), the MACHINEDOTS variable is set before launch. In the good ol SYS5 init.d days, I used to insert MACHINEDOTS=hostname -f in the runclient.sh script, which worked. So, I found if you run: systemctl edit xymonlaunch.service and add the following, it works:
[Service]
Environment="MACHINEDOTS=whatever.domain.com<http://whatever.domain.com>"This creates a /etc/systemd/system/xymonlaunch.service.d/override.conf file and all is well. Unfortunately it doesn't work with hostname -f. There is a warning that if there is no override.conf in whatever.service.d/ the service won't run. That isn't true with SUSE SLES 12, it works fine w/o it (less the correct name, of course), but YMMV...
HTH Someone, Phil
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here<http://www.mimecast.com/products/>.
Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
[http://web.orix.com.au/_resource/email/email-banner.jpg?rnd=201703091]
Please consider the environment before printing this e-mail
This message from ORIX Australia may contain confidential and/or privileged information. If you are not the intended recipient, any use, disclosure or copying of this message (or of any attachments to it) is not authorised. If you have received this message in error, please notify the sender immediately and delete the message and any attachments from your system. Please inform the sender if you do not wish to receive further communications by email.
ORIX has a Privacy Policy which outlines what kinds of personal information we collect and hold, how we may collect and handle it, and your rights regarding personal information. Please let us know if you would like a copy. The Privacy Policy and a Collection Statement are also available on our website<http://www.orix.com.au>.
We do not accept liability for any loss or damage caused by any computer viruses or defects that may be transmitted with this message. We recommend you carry out your own checks for viruses or defects.
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
participants (5)
-
Paul.Root＠CenturyLink.com
-
Phil.Crooker＠orix.com.au
-
ralphmitchell＠gmail.com
-
thomas.eckert＠it-eckert.de
-
tom＠it-eckert.de