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

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>

oh, my bad, actually, you even mentioned it, the other option would be to
listen on 0.0.0.0 . I guess that'd work even tho it'd then be a good
thing
to have local firewall as you suggested. So maybe just have that in the
docs too? I still think it'd be worth clarifying, if I got that right, that
using _hostname_ is not sufficient to make it listen on any interface other
than lo.

On Wed, Mar 29, 2017 at 8:35 AM Spike <spike at drba.org> wrote:
> 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/eef61212/attachment-0001.html>

On 03/29/2017 06:35 PM, Spike wrote:
> 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.
There is a slight misunderstanding here from your part.
If nut ( or any other network daemon actually ) is configured to use a 
specific IP address ( as opposed to a hostname ) it can do ( and will do 
) a direct bind on that specific IP and things are done. On the other 
hand, if its configuration contains a hostname, it must pass that 
hostname to a resolver which in turn will provide the IP to use ( "man 
gethostbyname" for details ) .
In your case, because /etc/nsswitch.conf contains ( by default ) a 
stanza saying:
|hosts: files dns|
glibc ( i.e. the resolver ) will look FIRST in /etc/hosts  ( because of 
the "files" directive ) and since it gets a successful hit on that 
hostname it will pass on the corresponding IP ("127.0.1.1" for your 
case) to the daemon that asked for said hostname without even trying to 
interrogate  the domain server. Therefore in your case nut will listen 
on 127.0.1.1. If and only if in /etc/hosts there is no entry for the 
queried hostname ( i.e. if you remove the "127.0.1.1 server1 
server1.domain" line ) will the resolver ask the global name server ( 
following the "dns" directive from /etc/nsswitch.conf )
>
> 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.
right...
> This is my experience with configuring other daemons
ALL daemons and any network application as well will follow the process 
I described earlier. One of the easiest way for so-called developers to 
test stuff that run on a web server without really uploading that to the 
real server is to configure their local machine to act as web server and 
add an entry like "127.0.0.1 webserver" in /etc/hosts. Any subsequent 
query for http://webserver on that machine will then hit their local 
webserver instead of the real one. I love to make fun of colleagues and 
add stuff like www.yahoo.com to a local server which replies with "you 
are not allowed to access yahoo.com while at work".
> 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.
nut will behave exactly as you expect it to once you ditch the offending 
( and useless ) line
>
> 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.
The hostname is sufficient. You need to properly configure your machine. 
Either ditch that second line or reverse the order between "files" and
"dns" ( which in turn will mean that you MUST add
"localhost" to the
global DNS zone otherwise you will face other very nasty problems due to 
your resolver never seeing a match for it !)

>
> 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
it is as convenient as it can be once you ditch that useless line. it is 
meant to exist there only to compensate a lack of entry in (or access 
to) the real DNS server


> - 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?
With my 23 year old RedHat admin hat on, I'd say you were hit by a poor 
decision taken a long time ago as workaround for idiotic software.I 
quote from the URL you mentioned "The IP address |127.0.1.1| in the 
second line of this example may not be found on some other Unix-like 
systems. The Debian Installer 
<http://en.wikipedia.org/wiki/Debian-Installer> creates this entry for a 
system without a permanent IP address as a workaround for some software 
(e.g., GNOME) as documented in the bug #719621 
<http://bugs.debian.org/719621>." If you further dig, you will notice
that the bug entry references another 15 year old bug. Ditch that line 
after you install the system and things will behave properly. To be 
honest I never heard of any system in the last 10 years that would have 
been affected by that bug. I might be mistaken but AFAIR RedHat also did 
use to do a similar thing but they quit doing this like 5 years ago 
exactly because the fact that it created far more issues than it solved.

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

Manuel,

I very much appreciate you taking the time to share such depth of
experience, that makes a lot of sense and clearly things out very
thoroughly. I will amend my ansible common playbook to get rid of that line
and will test to see if I can find any problems elsewhere, but otherwise
that sounds like the best solution.

thanks again,

Spike

On Wed, Mar 29, 2017 at 12:11 PM Manuel Wolfshant <wolfy at
nobugconsulting.ro>
wrote:
> On 03/29/2017 06:35 PM, Spike wrote:
>
> 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.
>
> There is a slight misunderstanding here from your part.
> If nut ( or any other network daemon actually ) is configured to use a
> specific IP address ( as opposed to a hostname ) it can do ( and will do )
> a direct bind on that specific IP and things are done. On the other hand,
> if its configuration contains a hostname, it must pass that hostname to a
> resolver which in turn will provide the IP to use ( "man
gethostbyname" for
> details ) .
> In your case, because /etc/nsswitch.conf contains ( by default ) a stanza
> saying:
>                 hosts: files dns
> glibc ( i.e. the resolver ) will look FIRST in /etc/hosts  ( because of
> the "files" directive ) and since it gets a successful hit on
that hostname
> it will pass on the corresponding IP ("127.0.1.1" for your case)
to the
> daemon that asked for said hostname without even trying to interrogate  the
> domain server. Therefore in your case nut will listen on 127.0.1.1. If and
> only if in /etc/hosts there is no entry for the queried hostname ( i.e. if
> you remove the "127.0.1.1 server1 server1.domain" line ) will the
resolver
> ask the global name server ( following the "dns" directive from
> /etc/nsswitch.conf )
>
>
>
> 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.
>
> right...
>
>
> This is my experience with configuring other daemons
>
> ALL daemons and any network application as well will follow the process I
> described earlier. One of the easiest way for so-called developers to test
> stuff that run on a web server without really uploading that to the real
> server is to configure their local machine to act as web server and add an
> entry like "127.0.0.1  webserver" in /etc/hosts. Any subsequent
query for
> http://webserver on that machine will then hit their local webserver
> instead of the real one. I love to make fun of colleagues and add stuff
> like www.yahoo.com to a local server which replies with "you are not
> allowed to access yahoo.com while at work".
>
>
> 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.
>
> nut will behave exactly as you expect it to once you ditch the offending (
> and useless ) line
>
>
>
> 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.
>
> The hostname is sufficient. You need to properly configure your machine.
> Either ditch that second line or reverse the order between
"files" and
> "dns" ( which in turn will mean that you MUST add
"localhost" to the global
> DNS zone otherwise you will face other very nasty problems due to your
> resolver never seeing a match for it !)
>
>
>
>
> 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
>
> it is as convenient as it can be once you ditch that useless line. it is
> meant to exist there only to compensate a lack of entry in (or access to)
> the real DNS server
>
>
>
>
> - 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?
>
> With my 23 year old RedHat admin hat on, I'd say you were hit by a poor
> decision taken a long time ago as workaround for idiotic software.I quote
> from the URL you mentioned "The IP address 127.0.1.1 in the second
line
> of this example may not be found on some other Unix-like systems. The
Debian
> Installer <http://en.wikipedia.org/wiki/Debian-Installer> creates
this
> entry for a system without a permanent IP address as a workaround for some
> software (e.g., GNOME) as documented in the bug #719621
> <http://bugs.debian.org/719621>." If you further dig, you will
notice
> that the bug entry references another 15 year old bug. Ditch that line
> after you install the system and things will behave properly. To be honest
> I never heard of any system in the last 10 years that would have been
> affected by that bug. I might be mistaken but AFAIR RedHat also did use to
> do a similar thing but they quit doing this like 5 years ago exactly
> because the fact that it created far more issues than it solved.
>
> _______________________________________________
> 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/2c6748ab/attachment-0001.html>