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

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>

On 03/29/2017 02:28 PM, Arnaud Quette wrote:
>
>
> 2017-03-29 12:32 GMT+02:00 Arnaud Quette <arnaud.quette at gmail.com 
> <mailto:arnaud.quette at gmail.com>>:
>
>
>
>     2017-03-29 5:49 GMT+02:00 Spike <spike at drba.org
>     <mailto: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...
I'd use "IP address or hostname" rather than "IP address or
name"
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170329/76930ff4/attachment.html>

thank you Arno, I'm with Manuel on the "IP address or hostname",
maybe I
didn't understand your previous explanation, but to me there's still a
bigger issue/unclear behavior.

Let's say I just installed ubuntu on a machine with hostname server1 and ip
192.168.0.1 . In /etc/hosts I end up with two lines (per
https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#s-net-dns):

127.0.0.1 localhost
127.0.1.1 server1 server1.domain (notice the two entries, with and without
domain)

I then have bind configured on the network to resolve server1 to 192.168.0.1

If at this point I install NUT and set upsd.conf as a server and set the
line such as:

LISTEN server1.domain 3493

I expect nut to listen on the local lan interface with ip 192.168.0.1 , ie
I expect it to be equivalent to:

LISTEN 192.168.0.1 3493

But it's not, the latter will listen on that ip while the former will
listen on 127.0.0.1.

If I want nut to only listen locally I would use 127.0.0.1 or localhost as
in the examples on the nut's manual. This is my experience with configuring
other daemons and how I'd expect nut to behave, again this doesn't mean
it's right, just trying to explain where my problems are coming from.

So, if we agree that that's how it's working and that the behavior is
correct, the documentation should imho explicitly point that out that using
the hostname is not sufficient to have nut listen on the external ip.

Does that make sense? If we agree on that then the statement "Bind a
listening port to the interface specified by its Internet address or name"
is incorrect or at least unintuitive because I'd think of server1 to refer
to the lan interface, not lo.

The other problem is that none of the fixes as far as I can see is
particularly clean/straightforward:
- adding a second line with the domain does not help because of what's in
/etc/hosts, so you still end up with NUT listening on localhost
- using an ip is not possible if DHCP is in the mix or just inconvenient as
it often is to hardcode ips in configs
- adding a line to /etc/hosts with the external ip would make it work, but
again auto generating that from dhcp with a hook script isn't
straightforward (not sure if there's a better way)

what am I missing?

thank you for your help,

Spike


On Wed, Mar 29, 2017 at 4:57 AM Manuel Wolfshant <wolfy at
nobugconsulting.ro>
wrote:

On 03/29/2017 02:28 PM, Arnaud Quette wrote:



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

I'd use "IP address or hostname" rather than "IP address or
name"
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170329/d05c87a4/attachment.html>