Nut upsuser - Mar 2017 - upsd/upsc, LISTEN and hostname resolution in master/slave

Hi,

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.

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.

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.

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.

best,

Spike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170329/3f20d093/attachment.html>

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>

2017-03-29 12:32 GMT+02:00 Arnaud Quette <arnaud.quette at gmail.com>:
>
>
> 2017-03-29 5:49 GMT+02:00 Spike <spike at drba.org>:
> (...)
>
>> 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
>
I've clarified a bit:
https://github.com/networkupstools/nut/commit/e83780337183d5369f892891df08775198231fe0

I'm interested in some feedback on whether this clarifies enough or not...

thanks and 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/683d7065/attachment.html>