[Nut-upsuser] upsd/upsc, LISTEN and hostname resolution in master/slave
arnaud.quette at gmail.com
Wed Mar 29 10:32:33 UTC 2017
2017-03-29 5:49 GMT+02:00 Spike <spike at drba.org>:
Hi again Spike ;)
I've been setting up a few Eatons 1500 USB in master/slave mode and run
> into what I'm thinking is a hostname resolution problem.
> Basically, to avoid hardcoding ips, I'd love to be able to add a LISTEN on
> the lan's ip which has hostname, let's say, server1.local .
> If I set up upsd.conf such as LISTEN server1.local 3493 what I end up with
> is upsd listening on 127.0.0.1 . I'm guessing it gets this value from
> /etc/hosts which overrides server1.local dns resolution.
probably /etc/hosts indeed.
however, server1 should resolve to a non local IP@, so that one should work
(need DNS resolution, possibly through DHCP bridging)
So basically if I want it to listen on anything other than localhost I need
> to hardcode an ip in upsd.conf or add a line to /etc/hosts, which is not
> quite convenient if the computer gets its ip from dhcp.
simply add 1 or more LISTEN lines, with the DNS resolvable names (if DHCP
> What's more, it seems that upsc does the same thing, so if I have a line
> such as:
> MONITOR eaton at server1.local ... that will fail if I specified the
> external ip. However this will succeed from the slave, because there's no
> server1.local in /etc/hosts I'm guessing so the name resolves to the same
> ip in the LISTEN.
upsd serves the data to the rest of the world, i.e. all NUT clients,
including upsc / upsrw / upscmd / upsmon
so the LISTEN line(s) impacts all these....
> Is this really the desired behavior? I can certainly work with it, but it
> seems it'd be nice if it could work with dns resolution (at least client
> side, the LISTEN statement I guess it's ok), but maybe I'm missing some
> good reason why this would cause other issues.
this is indeed undocumented (will fix it after this mail and a quick
lunch), but that works
We once had ACL (ACCEPT / REJECT) to refine the job, but that's really a
firewall job ;)
So another approach is to "LISTEN 0.0.0.0" (i.e. everything) and use your
firewall to restrict INPUT interfaces.
Hope it helps,
Eaton Data Center Automation Solutions - Opensource Leader -
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsuser