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