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