[Nut-upsuser] upsd/upsc, LISTEN and hostname resolution in master/slave

[Arnaud Quette]

2017-03-29 5:49 GMT+02:00 Spike <spike at drba.org>:

> Hi,
>

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.
>

no
simply add 1 or more LISTEN lines, with the DNS resolvable names (if DHCP
served)


> 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

LISTEN myhostname.domain1
LISTEN myhostname.domain2

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,
cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170329/6a2eec1a/attachment.html>