xymon client host name not including domain name in systemd scripts

list Thomas Eckert
Mon, 05 Feb 2018 07:41:05 +0100
Message-Id: <user-1bfbc232d62f@xymon.invalid>

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 Feb 5, 2018 07:22, Phil Crooker wrote:

No, that made no difference - "10.11.12.13 FQDN   hostname" is the default order in SuSE, anyway... Interesting.

cheers, P

From: Ralph Mitchell
Sent: Saturday, 3 February 2018 3:24 AM
To: Phil Crooker
Cc: xymon@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

And this checked in as "server.domain.com"

     10.12.34.56   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 <user-e8e31cd73303@xymon.invalid> 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 -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 Click Here.

Xymon@xymon.com

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.

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.