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 <wo...@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@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
