Can XYMSRV be a fqdn/hostname not an IP
On Tue, February 13, 2024 07:53, Ian Diddams wrote:
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
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<cleaver at terabithia.org> wrote:
On Tue, February 13, 2024 07:53, Ian Diddams wrote:
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
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:
It's fine to do this, just with the caveat that this introduces working DNS resolution as a requirement for client log submission.
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
participants (3)
-
cleaver＠terabithia.org
-
didds3＠yahoo.co.uk
-
gtaylor＠tnetconsulting.net