On Wed, 2013-07-31 at 01:30 +0100, Steve Langasek wrote: > What I'm missing your email is a problem statement explaining what it is > you're trying to solve. The current implementation has been working > reliably for years. If it ain't broke, don't fix it. You even extracted it yourself from my text: > > - 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. > That's correct. If you want to talk to a loopback-only service, you should > be connecting to 'localhost', *not* to the hostname. You don't want a > server to resolve its hostname to somewhere other than where all the other > machines on the network will resolve it. Well why not? Imagine that one server in a cluster serves a debian package repo (e.g. via http)... I have a common sources.list which all point to deb http://somehost.foo/debian main I don't want to make exceptions for the host itself, and have to change it http://localhost/debian there. So the only ways around would be: - set the hostname to the global IP -> has several drawbacks as I described originally - let the webserver listen as well on 127.0.1.1,... sure that works but it's rather ugly to make such special handling... and not all services are even able to bind to multiple addresses. > > - The system hostname (and domainname if any) should ALWAYS be > > resolvable, whether a network is up or not, regardless of which. > > (Assuming that lo is always up, if not, many things break anyway.) > The current implementation assures this. Not sure... IIRC, the installer currently asks, for a static IP, right? And sets this in /etc/hosts for the hostname. As I wrote in (II), experience has shown that that can break more easily than it always being resolved to 127.x.x.x > > This controls what reverse resolution leads to (e.g. what tools like > > netstat show). > > I personally would take the first ordering,... since one sees localhost > > then which usually makes it really clear what happens. > > You have overlooked the fact that only one of these can be the canonical > hostname of 127.0.0.1, and having the hostname and localhost canonicalize to > each other causes problems. Yeah,... I realised that, too, in the meantime,... but well... I think at least from the DNS side there is no guarantee that this should work. So if you have no hostname set at all in /etc/hosts and let DNS handle this... there is no guarantee that the domain name and reverse entry correspond. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature