Re: MPD on localhost won't work if there's no Wifi!?
On Fri 13 Jun 2014 at 15:28:48 -0600, Bob Proulx wrote:
> Brian wrote:
> > Bob Proulx wrote:
> > > Brian wrote:
> > > > True. What do think about the lack of '127.0.1.1 localhost' in
>
> It is the "127.0.1.1 localhost" to which I was disagreeing. That
> would be unusual. It is still the loopback device so off the top of
> my head I think everything should still work okay. But for best
> compatibilty I think 127.0.0.1 should always be localhost the reverse.
There is quite extensive history attached to the use of 127.0.1.1 in
/etc/hosts. Parts of the most recent discussion is at:
https://lists.debian.org/debian-devel/2013/08/msg00095.html
and
https://lists.debian.org/debian-devel/2013/08/msg00151.html
> If the actual hostname of the system is "localhost" then there is no
> need for any other entry other than the 127.0.0.1 entry and the
> 127.0.1.1 entry isn't needed at all. (Now I need to verify that the
> installer doesn't add it in that case. I recall that it does not.)
Teresa had /etc/hostname as "localhost". If I do the same d-i writes my
127.0.1.1 line as
127.0.1.1 localhost.lan localhost.
during an expert install.
> Now that you mentioned the case of what happens if DHCP returns
> something unusual I think I would need to check. But I think it still
> behaves the same regardless. I don't think anything the DHCP server
> returns is going to affect this. But I can't say for certain without
> looking and testing. It might.
Not that I have any skills at all in understanding source code but
netcfg has
dhcp.c: if (netcfg_get_hostname(client, "netcfg/dhcp_hostname", interface->dhcp_hostname, 0))
dhcp.c: * If the netcfg/hostname preseed value is set use that
dhcp.c: * otherwise default to the hostname returned via DHCP, if any,
dhcp.c: * otherwise to the requested DHCP hostname
dhcp.c: * otherwise to the hostname found in DNS for the IP address
> I am more interested now in what happens in a CD#1 install completely
> offline.
The hostname will be either the default ("debian") or whatever is
preseeded with hostname= on the command line. I wouldn't expect there to
be a domain name.
dhcp.c: /* We don't have a domain name yet, but we need to write out the
dhcp.c: * Default to the domain name returned via DHCP, if any
dhcp.c: di_debug("Reading domain name returned via DHCP");
dhcp.c: di_debug("DHCP domain name is '%s'", domain);
netcfg-common.c: * Verify that the domain name (or FQDN) conforms to RFC 1123 s2.1, and
netcfg-common.c: } else { /* assume we have a valid domain name given */
netcfg-common.c: /* Global var 'domain' is holding a temporary domain name,
> > Suppose the server doesn't provide a domain name. Then she will have
> >
> > 127.0.1.1 foo
> >
> > because there is no need for an alias.
>
> That is a good question! But doesn't the installer ask you for a
> domain name specifically? I believe it does. Therefore the user
> should always enter a domain name. But if they don't then I don't
> know what the installer puts there by default.
The default is the domain name returned via DHCP. Blanking the field
results in no domain name.
> I _thought_ the installer put the special "localdomain" string there
> in the case that the user left it empty. Because sometimes there
> isn't any reasonable thing to put there. In that case it creates a
> consistent and valid configuration using localhost and localdomain.
> That way applications that require a domain name to be present will
> have a constructed one that will work even if bogus. (As I recall
> this predates RFC 2606 which created a .localhost domain.)
>
> The idea is that some applications such as Postfix for one example,
> along with others, that really want a fully qualified hostname can
> have a fully consistent configuration by using localhost.localdomain.
> The localdomain part is a created construct. But on an unconnected
> system everything can map consistently and everything can work
> regardless.
I don't pretend to understand this in its entirety, but from netcfg's
changelog:
[ Thomas Hood ]
* If there is no permanent IP address with which the system hostname
(i.e., that which is returned by the "hostname" command) can be
associated in /etc/hosts then associate it with address 127.0.1.1
rather than 127.0.0.1. Associating the system hostname with the
latter had the unwanted effect of making 'localhost.localdomain'
the canonical hostname associated with the system hostname.
That is, 'hostname --fqdn' returned 'localhost.localdomain'.
(Closes: #316099)
Programs that access local services at the IP address obtained by
resolving the system hostname SHOULD NOT DO THIS, but those that
do so will not be disappointed: most services that listen locally
listen on all 127/8 addresses, not just on 127.0.0.1
> > For an expert install the hostname and domain name can be specified, so
> > either
> >
> > 127.0.1.1 foo.example.com foo
> >
> > or, if the domain name is left blank,
> >
> > 127.0.1.1 foo
> >
> > would be seen.
>
> Doesn't it create an entry like this? I will need to test it in order
> to see what it creates in that case.
>
> 127.0.1.1 foo.localdomain foo
>
> I will try it later and report back. :-)
Please do.
> > With preseeding the hostname can be be preseeded but not the domain
> > name. So I'd expect both the previous two variants to be possible.
>
> The domain *can* be preseeded. I do that all of the time. Really!
> On the install command line. For me usually through the PXE network
> boot syslinux interface.
>
> hostname=junk domain=proulx.com
I really wanted this to work; I'm afraid it didn't. Tested with a
netinst image but I cannot see what difference it would make. The mini
iso is functionally equivalent to a PXE boot. I'll try it later.
What bothers me is that netcfg/get_domain is in the templates file but
netcfg/domain is not. Are you sure the domain name is not coming from
the network? Test with "domain=example.com"? "cat /etc/hosts" in a
console immediately after network configuration.
> > I do not think we are in serious disagreement.
>
> Sometimes we disagree but it is never serious. I always look forward
> to your postings Brian. They are always high quality helpful
> postings. I enjoy our discussions.
I'm going to run out of useful things to say soon. :)
Reply to: