<div dir="ltr">Manuel,<br><div><br></div><div>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.</div><div><br></div><div>thanks again,</div><div><br></div><div>Spike</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 29, 2017 at 12:11 PM Manuel Wolfshant <<a href="mailto:wolfy@nobugconsulting.ro">wolfy@nobugconsulting.ro</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<div class="m_6789191083456688293moz-cite-prefix gmail_msg">On 03/29/2017 06:35 PM, Spike wrote:<br class="gmail_msg">
</div>
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div dir="ltr" class="gmail_msg">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.
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">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 <a href="https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#s-net-dns" class="gmail_msg" target="_blank">https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#s-net-dns</a>):</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">127.0.0.1 localhost</div>
<div class="gmail_msg">127.0.1.1 server1 server1.domain
(notice the two entries, with and without domain)</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">I then have bind configured on the
network to resolve server1 to 192.168.0.1</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">If at this point I install NUT and set
upsd.conf as a server and set the line such as:</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">LISTEN server1.domain 3493</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">I expect nut to listen on the local lan
interface with ip 192.168.0.1 , ie I expect it to be
equivalent to:</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">LISTEN 192.168.0.1 3493</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">But it's not, the latter will listen on
that ip while the former will listen on 127.0.0.1.</div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
There is a slight misunderstanding here from your part. <br class="gmail_msg">
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 ) .<br class="gmail_msg">
In your case, because /etc/nsswitch.conf contains ( by default ) a
stanza saying:<br class="gmail_msg">
<code class="m_6789191083456688293literal gmail_msg">hosts: files dns</code><br class="gmail_msg">
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 )</div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">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.</div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
right...</div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg"> This is my experience with configuring
other daemons </div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
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 <a class="m_6789191083456688293moz-txt-link-freetext gmail_msg" href="http://webserver" target="_blank">http://webserver</a>
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
<a class="m_6789191083456688293moz-txt-link-abbreviated gmail_msg" href="http://www.yahoo.com" target="_blank">www.yahoo.com</a> to a local server which replies with "you are not
allowed to access <a href="http://yahoo.com" class="gmail_msg" target="_blank">yahoo.com</a> while at work".</div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">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.</div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
nut will behave exactly as you expect it to once you ditch the
offending ( and useless ) line</div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">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.</div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
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
!)</div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">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.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">The other problem is that none of the
fixes as far as I can see is particularly
clean/straightforward:</div>
<div class="gmail_msg">- 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<br class="gmail_msg">
</div>
<div class="gmail_msg">- using an ip is not possible if DHCP
is in the mix or just inconvenient as it often is to
hardcode ips in configs</div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
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</div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">- 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)</div>
<div class="gmail_msg"><br class="gmail_msg">
<div class="gmail_msg">what am I missing?</div>
</div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
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 <code class="m_6789191083456688293literal gmail_msg">127.0.1.1</code> in the second line of this
example may not be found on some other Unix-like systems. The <a class="m_6789191083456688293ulink gmail_msg" href="http://en.wikipedia.org/wiki/Debian-Installer" target="_blank">Debian
Installer</a> creates this entry for a system without a permanent
IP address as a workaround for some software (e.g., GNOME) as
documented in the <a class="m_6789191083456688293ulink gmail_msg" href="http://bugs.debian.org/719621" target="_blank">bug #719621</a>." 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.<br class="gmail_msg">
<br class="gmail_msg">
</div>
_______________________________________________<br class="gmail_msg">
Nut-upsuser mailing list<br class="gmail_msg">
<a href="mailto:Nut-upsuser@lists.alioth.debian.org" class="gmail_msg" target="_blank">Nut-upsuser@lists.alioth.debian.org</a><br class="gmail_msg">
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser</a></blockquote></div>