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

Wed Mar 29 18:12:43 UTC 2017

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>