Can XYMSRV be a fqdn/hostname not an IP 🔗 link

simple question...? as time marches on etc has xymon/hobbit reached a stage yet when XYMSRV can be set to a hostname rather than an IP address?

eg? rather than

XYMSRV = "10.10.10.10"

we could have

XYMSRV = "xymonhost"

where "xymonhost" resolves in dns to 10.10.10.10?

This would be a huge benefit where anytime a xymon server is migrated to another system eg underling EOL OS, one wouldn't have to go around changing every single client server's xymon configs to a new Ip...? all that would be required is a reset in an appropriate dns zonefile so dns just provides the new IP after the TTL passes etc.

???

cheers
ian

On Tue, February 13, 2024 07:53, Ian Diddams wrote:

Hi,

Yes, $XYMSRV (or the recipient specified directly on the command line to
the 'xymon' client program) can be a FQDN, even in 4.3.30, and a lookup
will be performed.

It's fine to do this, just with the caveat that this introduces working
DNS resolution as a requirement for client log submission. This might be
an OK tradeoff if, as you say, you're doing migration, or have a floating
xymon VIP, or are doing other things with xymonproxy and need admin
flexibility w/o touching every machine.

-jc

Thanks!

Sent from Yahoo Mail on Android 

 
  On Tue, 13 Feb 2024 at 18:25, J.C. Cleaver<user-87556346d4af@xymon.invalid> wrote:   
On Tue, February 13, 2024 07:53, Ian Diddams wrote:

Hi,

Yes, $XYMSRV (or the recipient specified directly on the command line to
the 'xymon' client program) can be a FQDN, even in 4.3.30, and a lookup
will be performed.

It's fine to do this, just with the caveat that this introduces working
DNS resolution as a requirement for client log submission. This might be
an OK tradeoff if, as you say, you're doing migration, or have a floating
xymon VIP, or are doing other things with xymonproxy and need admin
flexibility w/o touching every machine.

-jc

On 2/13/24 12:25?PM, J.C. Cleaver wrote:

Minor nitpick:  This requires working /name/ /resolution/.  Anything that provides name resolution; DNS being one option, will suffice.

I've been using /etc/hosts with great success in an environment without otherwise functional DNS.

I also assume that NIS(+) could be used for name resolution.  I wonder if LDAP could be used like NIS(+) can be.  <thinking face>

This might be an OK tradeoff if, as you say, you're doing migration, or have a floating xymon VIP, or are doing other things with xymonproxy and need admin flexibility w/o touching every machine.

One *BIG* advantage for me to use the "xymonhost" name is that configuration files are consistent in the Xymon client.  That way the Xymon client files can be common / identical across multiple clients. The thing that needs to be different is in /etc/hosts which is dedicated to each client.  --  Think /usr being a read only NFS mount.

I have /usr/local/hobbit/client/tmp and /usr/local/hobbit/client/logs (? singular / plural ??? not enough caffeine to be fully awake?) be sym-links to /tmp/hobbit.d which -- like /etc -- is also specific to clients.  The rest of the clients on the system have identical configuration.

I naively assume that the fully qualified domain name would work.  I similarly assume that a partially qualified domain name would also work with the rest of the systems name resolution configuration; e.g. <host>.<site> would work in conjunction with numdots (?memory?) setting to make the system treat a single dot as unqualified while treating two (or more) dots as fully qualified; thereby making <host>.<site> compatible with search domains.  }:-)


-- 
Grant. . . .
unix || die