Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 30/07/13 21:43, Christoph Anton Mitterer wrote:
> - Back then, Thomas pointed out several ides on who the resolution could
> be done (e.g. with a small nsswitch module)
libnss-myhostname is basically this, and is packaged. It tries to return
a public address if possible, only falling back to 127.0.0.2 (upstream),
127.0.1.1 (as patched in Debian) or ::1 (IPv6) if there's nothing more
suitable. Possibly it ought to try RFC1918 addresses before 127.x.y.z,
or ought to fall back to 127.0.0.1 instead; I'm sure there are valid
arguments each way.
I would be inclined to install libnss-myhostname by default, since it's
the 99% solution. People who feel strongly about this sort of thing can
uninstall or disable it, and apply whatever manual configuration they
want to.
> I) Switch the <host_name>.<domain_name> <host_name> to 127.0.0.1 unless
> there is any strong reason to have it on another address.
I think `getent hosts 127.0.0.1` should always return "localhost" and
`getent hosts localhost` should always return "127.0.0.1" (and possibly
also "::1", I'm not sure about that part).
I wouldn't have any particular objection to `getent host mymachine`
returning 127.0.0.1 *as well* if it makes things work better.
> Should the hostname point to a static IP address (or better said an
> address that is not the loopback)?
>
> Most people set the static IP address of a system for their hostname
> e.g.
> 127.0.0.1 localhost
> 66.66.66.66 foobar[.bar.net foobar]
[citation needed] for "most people" - hard-coding a non-loopback IP
address is never going to work for a laptop that's used in multiple
locations, and I hear those are quite popular these days :-)
> I must say though, that I have meet several programs which do some weird
> ways of interface discovery, and these will break when one doesn't set
> the global IP address.
> The problem with such is that they don't let you configure the bind
> address, but always use the hostname to detect it.
I suspect it might be quite common in Java apps developed on Windows.
InetAddress.getLocalhost() does approximately the same as
libnss-myhostname on Windows, so people who primarily test on Windows
will tend to assume that InetAddress.getLocalhost() is "the right thing"
(or at least not entirely useless); but on Linux it looks up
gethostname() in DNS. Minecraft had this bug, resulting in it listening
on 127.0.1.1 on Debian for a while.
I would argue that servers intending to listen on externally-accessible
addresses should default to listening on 0.0.0.0 and letting the kernel
do the work - that way, they'll continue to work correctly if you "roam"
from wired to wifi to 3G or whatever, or if you start them when you
didn't yet have an IP address at all. Applications that really need to
know about individual IP addresses can't safely make the assumption that
you have exactly one non-loopback IP address (because it has never been
true in general), and should use netlink.
> Now some people may argue, that they conveniently use the feature of
> some programs, which allow to configure the bind addresses via
> hostnames. If the address changes, you just adapt /etc/hosts,... and all
> these services will automatically pick it up (at the next start).
I think whether this is viable depends whether your networking is
basically static or dynamic. If your networking is basically static (a
typical server), almost anything is acceptable, because you won't have
to change it very often in any case. If your networking is basically
dynamic (a typical laptop), then hostname-to-IP-address configuration
will have to be either automatic, loopback-based, or "usually broken".
S
Reply to: