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

Wed Mar 29 23:41:07 UTC 2017

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>