Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Thomas Hood]

Op 8 aug. 2013 17:49 schreef "Tom H"  het volgende:
> The output below is from Debian Sid with libnss-myhostname installed [...]
> [root@debdeb:/etc]# cat hostname
> debdeb
> [root@debdeb:/etc]# cat hosts
> 127.0.0.1 localhost
> [root@debdeb:/etc]# getent hosts 127.0.1.1
> 192.168.1.250   debdeb

This is interesting.
-- 
Thomas

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Tom H]

On Mon, 5 Aug 2013 13:08:28 -0400, Thomas Hood wrote:

(I had an exchange of emails with Thomas off-list and he suggested that 
I reply on-list.)


> With the nsswitch configuration
>
> hosts: files ... dns ... myhostname
>
> myhostname resolves the system hostname if nothing else does so
> first. So it can be overridden either by DNS or by /etc/hosts. If
> the system hostname changes, no file has to be edited. Nice.
>
> Also nice is the fact that myhostname resolves the system hostname
> to an external address if there is one, increasing the chances that
> the result is similar to what would be obtained from DNS.

The output below is from Debian Sid with libnss-myhostname installed
and Fedora 19.

On Debian, getent outputs the system's IP address for 127.0.1.1,
whereas on Fedora, getent outputs 127.0.0.2 for 127.0.0.2.


Debian Sid

[root@debdeb:/etc]# cat hostname
debdeb

[root@debdeb:/etc]# cat hosts
127.0.0.1 localhost

[root@debdeb:/etc]# getent hosts 127.0.1.1
192.168.1.250   debdeb


Fedora 19

[root@fedfed:/etc]# cat hostname
fedfed.defdef

[root@fedfed:/etc]# cat hosts
127.0.0.1 localhost

[root@fedfed:/etc]# getent hosts 127.0.0.2
127.0.0.2   fedfed.defdef



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5204124c.7030...@gmail.com

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Thomas Hood]

Op 7 aug. 2013 10:33 schreef "Wouter Verhelst"  het
volgende:
> Historically, "localhost" has always been "127.0.0.1". It feels wrong to
> change that, simply because "localhost" starts showing up in places it
> was never meant to show up in.

To clarify, no one is proposing that 'localhost' be assigned any (IPv4)
address other than 127.0.0.1 in /etc/hosts.

The question is what IP address the system hostname should be assigned when
the machine has no static external IP address. Currently it is assigned
127.0.1.1 and the proposal is to assign it 127.0.0.1 with 'localhost'
becoming a mere alias. I have already expressed my opinion about that
proposal.
-- 
Thomas

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Philipp Kern]

On Wed, Aug 07, 2013 at 10:29:01AM -0700, Russ Allbery wrote:
> I think RFC 1912 is interesting here:
> 
>The "localhost" address is a "special" address which always refers to
>the local host.  It should contain the following line:
> 
>localhost.  IN  A   127.0.0.1

RFC 6761 has a bunch of clarifications, especially towards localhost use
for IPv6 as well.

 Users may assume that IPv4 and IPv6 address queries for localhost names
 will always resolve to the respective IP loopback address.

This conviently ignores the question what should be returned if you're
interested in an answer that does not specify either IPv4 or IPv6.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Russ Allbery]

Wouter Verhelst  writes:
> On 05-08-13 19:08, Thomas Hood wrote:

>> In that case 'hostname.domain' is the canonical name for alias
>> 'localhost'.

> Which is fine. "localhost" is *supposed* to be an alias, it is not a
> canonical name (there are far too many machines called "localhost" for
> it to be a canonical name of any use...)

This may be a matter of style (and possibly even a matter of semantics),
but I consider the "localhost" name to be the canonical name for the
127.0.0.1 IP address, which always refers to the local loopback.  It's a
different type of canonical name, but I still consider that a canonical
name.

IMO, 127.0.0.1 resolving to anything other than localhost, or 127.0.0.1
resolving to any name other than localhost, is simply broken and not
behavior I want on any of my systems.  Obviously, other people's mileage
may vary, and I'm not saying this to try to change anyone's mind about how
they want to run their systems, simply to register a contrary opinion from
a long-time UNIX user.

I think RFC 1912 is interesting here:

   The "localhost" address is a "special" address which always refers to
   the local host.  It should contain the following line:

   localhost.  IN  A   127.0.0.1

   The "127.0" file should contain the line:

   1PTR localhost.

   There has been some extensive discussion about whether or not to
   append the local domain to it.  The conclusion is that "localhost."
   would be the best solution.  The reasons given include:

  "localhost" by itself is used and expected to work in some
  systems.

  Translating 127.0.0.1 into "localhost.dom.ain" can cause some
  software to connect back to the loopback interface when it didn't
  want to because "localhost" is not equal to "localhost.dom.ain".

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9ktif4y@windlord.stanford.edu

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Wouter Verhelst]

On 05-08-13 19:08, Thomas Hood wrote:
> Wouter Verhelst wrote:
>> The right way, in my opinion, is that /etc/hosts should
>> look like this:
>>
>> 127.0.0.1 localhost
>> 127.0.0.1 hostname.domain hostname
> 
> Strictly speaking there should be no more than one line per
> IP address, so that would be

In practice, however, glibc parses that and it does not cause problems.
Any program directly parsing /etc/hosts is broken.

At any rate, I also said:

>> or, alternatively:
>>
>> 127.0.0.1 hostname.domain hostname localhost
> 
> In that case 'hostname.domain' is the canonical name for alias 'localhost'.

Which is fine. "localhost" is *supposed* to be an alias, it is not a
canonical name (there are far too many machines called "localhost" for
it to be a canonical name of any use...)

I believe a canonical name should always be an FQDN; there are, in fact,
some systems that break when this assumption is not adhered to (MIT
Kerberos and gridengine spring to mind, but I'm sure there are others).

> Before any move is made to conflate the system hostname with
> 'localhost' in this way I'd like to see some proof that this no longer
> causes any malfunction, or if it does cause malfunction (e.g.,
> 'localhost' appearing in log files)

The first entry on any line in /etc/hosts, AIUI, is supposed to be the
canonical name, with other entries being aliases. If "localhost" appears
in log messages, that would be because "localhost" is listed first on
that line. Fixing that is a simple case of "don't do that, then".

> then I'd like to see the
> malfunctioning packages fixed in advance of the transition from
> 127.0.1.1 to 127.0.0.1. And before making this potentially disruptive
> change, I'd like to see evidence that the current practice actually
> causes problems --- problems that can't easily be solved by patching
> individual packages either to make them listen on 127.0.1.1 on the one
> hand or to make them talk to localhost on the other.

It is, in theory, always possible to fix system-wide issues by patching
individual packages, but that isn't necessarily the right thing to do.

Historically, "localhost" has always been "127.0.0.1". It feels wrong to
change that, simply because "localhost" starts showing up in places it
was never meant to show up in. Yes, the change to 127.0.1.1 may have
fixed that particular issue, but it's ugly.

If applications were logging with "localhost" as their name, then either
these applications are buggy (not using the canonical name when they
should), or the order is not defined as clearly as I thought it was.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52025a99.6040...@debian.org

Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Thomas Hood]

Sorry I'm a bit late contributing to this discussion.

Christoph Anton Mitterer wrote:
> The eventual result[1] was that Debian nowadays ships
> /etc/hosts like these per default:
>
> 127.0.0.1 localhost
> 127.0.1.1 . 
>
> As also described in the Debian reference[2].

That's not entirely accurate. Wheezy and Ubuntu Desktop install
an /etc/hosts like the following, without a domain_name.

   127.0.0.1 localhost
   127.0.1.1 

The Debian Reference is out of date.

Some years ago it was the case that if a machine had a static
external IP address then this was listed instead of '127.0.1.1'.
I presume that this is still the case but I haven't checked
(and I am on the road, so can't easily check, sorry).

> The hostname is not necessarily a domain name, at least not
> de jure.

Right. Ideally nothing would blindly treat the system hostname
as a domain name. I don't know how that practice ever got
started, but it overlooked the fact that machines can have
multiple domain names and multiple IP addresses, any of
which can be externally administered and any of which can
be changed at any time. The machine itself doesn't even know
when its domain names change.

> But in reality, many programs and people rely or are at least
> used to the hostname being resolvable.
> That practise won't change and we cannot do much about it.

That seems too pessimistic to me.  If there are broken programs
we can patch them.

> - Most applications that listen to the loopback actually
> only listen to 127.0.0.1 (and perhaps ::1) but often not
> to 127.0.0.0/8.

Last time I checked, most applications that listen on 127.0.0.1
listen on all addresses, thus including 127.0.0.0/8.  This is why
resolving the hostname to 127.0.1.1 actually causes few if any
problems in practice.

> => so the overall proposal (I) is:
> If no one has any technical reasons against, can we stop using
> 127.0.1.1 and let the hostname point to 127.0.0.1 as in:
> 127.0.0.1   localhost
> 127.0.0.1   foobar[.bar.net foobar]

Strictly speaking, each IP address in /etc/hosts should be
represented by no more than one line.

Your proposal has the consequence that 'localhost' is the
canonical name for 'foobar'. Please don't do this. I don't
want to return to the days of 'localhost' appearing in log
files and command line prompts.

Simon McVittie wrote:
> 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.

This is exactly what you need if you need the system hostname
to be resolvable to an IP address. (And I am prepared to believe
that we still need that, even though I haven't tested it recently.)

With the nsswitch configuration

hosts:  files ... dns ... myhostname

myhostname resolves the system hostname if nothing else does
so first. So it can be overridden either by DNS or by /etc/hosts.
If the system hostname changes, no file has to be edited.  Nice.

Also nice is the fact that myhostname resolves the system hostname
to an external address if there is one, increasing the chances that
the result is similar to what would be obtained from DNS.

Wouter Verhelst wrote:
> The right way, in my opinion, is that /etc/hosts should
> look like this:
>
> 127.0.0.1 localhost
> 127.0.0.1 hostname.domain hostname

Strictly speaking there should be no more than one line per
IP address, so that would be

127.0.0.1 localhost hostname.domain hostname

in which case 'localhost' is the canonical name for alias 'hostname'.

> or, alternatively:
>
> 127.0.0.1 hostname.domain hostname localhost

In that case 'hostname.domain' is the canonical name for alias 'localhost'.

Before any move is made to conflate the system hostname with
'localhost' in this way I'd like to see some proof that this no longer
causes any malfunction, or if it does cause malfunction (e.g.,
'localhost' appearing in log files) then I'd like to see the
malfunctioning packages fixed in advance of the transition from
127.0.1.1 to 127.0.0.1. And before making this potentially disruptive
change, I'd like to see evidence that the current practice actually
causes problems --- problems that can't easily be solved by patching
individual packages either to make them listen on 127.0.1.1 on the one
hand or to make them talk to localhost on the other.
--
Thomas Hood


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cajn8kfcqbzh6scduqya1udjn397xo3wwvaj1mbfvzhvghkk...@mail.gmail.com