“localdomain” is not a registered top-level domain and hopefully never will be, so it is safe to use locally as it won’t cause communication problems.

Pierre Machard

“localdomain” is not a registered top-level domain and hopefully never will be, so it is safe to use locally as it won’t cause communication problems.

It is not safe to use unregistered domains. and I dont see a reason for .localdmain at all.

Bernd Eckenfels

It is not safe to use unregistered domains. and I dont see a reason for .localdmain at all.

IIRC The main reason was described in #247734

Pierre Machard

IIRC The main reason was described in #247734

The only reason I find is that RedHat use it. But RedHat shouldn’t be debians requirement of quality. It should be other way around. RedHat is such a buggy distribution. And it gets more and more worse every upgrade.

.localdomain is such a peace of shit which only makes troubles. So please hold the high quality of debian and do not polute it with such grab.

Klaus Ethgen

.localdomain is such a peace of shit which only makes troubles. So

Please explain which troubles.

Marco d’Itri

Please explain which troubles.

I cannot specify it. But I remember that I did search for problemes in the past long time to find a error. And it was an entry of localhost.localdomain in a /etc/hosts. Maybe it was PVM or MySQL or other. I’m not sure.

If you think for localhost you will never anticipate that it is called localhost.localdomain on one system. The Phrase “localhost” is for historical reasons such often used in scripts and programms. It whould create many manyears of troubleshooting putting this .localdomain on the end.

Klaus Ethgen

I cannot specify it. But I remember that I did search for problemes in

In other words, you don’t know and are just handwaving. Next?

Marco d’Itri

In other words, you don’t know and are just handwaving. Next?

No, I just do not remember which software it was. I absolutely remember THAT it was a problem with localhost.localdomain and THAT it takes me long time to debug.

Klaus Ethgen

No, I just do not remember which software it was. I absolutely remember THAT it was a problem with localhost.localdomain and THAT it takes me long time to debug.

So you know about an unspecified issue with an unspecified program. It’s not much to argue that the current behaviour is broken.

Klaus Ethgen

No, I just do not remember which software it was. I absolutely remember THAT it was a problem with localhost.localdomain and THAT it takes me long time to debug.

That’s not helpful.

Problems can have many causes. One of them may be that localhost.localdomain is unexpected; another may be that the software you were using is buggy, or misconfigured. Also, it could be that the problem you experienced back then has been fixed in the mean time.

There’s only one way to be sure, and that is to examine the problem in detail. If it is clear from your example that localhost.localdomain does indeed cause many problems, we could consider not using it by default anymore. However, if we find that the problem is just a bug, it would be better to fix it rather than removing something which many people expect to be there.

Since you’re not providing details, however, this isn’t possible, and the only sensible course of action is to ignore your claims.

Wouter Verhelst

That’s not helpful.

True. Thats the reason why I give more helpfull information too in the first mail.

Wouter Verhelst

indeed cause many problems, we could consider not using it by default anymore. However, if we find that the problem is just a bug, it would be better to fix it rather than removing something which many people expect to be there.

But why changing “localhost” to “localhost.localdomain” only for the reason that RedHat doing it? There was everythink OK with the proven “localhost”-entry. No problemes was encounted with it. The problemes was at first encounted when changing this localhost entry. It is absolutely irrelevant if the problemes are exactely specified or not. The point is that localhost.localdomain MAKES problemes. And it is nothing what makes sense either.

Wouter Verhelst

Since you’re not providing details, however, this isn’t possible, and the only sensible course of action is to ignore your claims.

Just do what you whant with it. I do not whant to fight. I know how to edit /etc/hosts. But why the hell should there be so many traps for users who do not know.

Klaus Ethgen

Thats the reason why I give more helpfull information too in the first mail.

You haven’t given enough information.

Klaus Ethgen

But why changing “localhost” to “localhost.localdomain”...

It wasn’t changed. “localhost.localdomain” was added. “localhost” is still there.

Klaus Ethgen

There was everythink OK with the proven “localhost”-entry. No problemes was encounted with it.

There were problems that the addition of “localhost.localdomain” were intended to solve. You may not have personally experienced them but many others did.

Klaus Ethgen

It is absolutely irrelevant if the problemes are exactely specified or not.

If the addition of “localhost.localdomain” caused you a problem we need to know exactly what it was so that we can fix it.

John Hasler

It wasn’t changed. “localhost.localdomain” was added. “localhost” is still there.

The first entry is the canonical name, and it is what the reverse maps to. So yes, it WAS changed, and very much so.

John Hasler

There were problems that the addition of “localhost.localdomain” were intended to solve. You may not have personally experienced them but many others did.

Now, that is interesting. Which problems? I honestly don’t know of any.

Henrique de Moraes Holschuh

The first entry is the canonical name, and it is what the reverse maps to. So yes, it WAS changed, and very much so.

The OP seemed to me to be implying that “localhost” had been deleted and replaced by “localhost.localdomain”.

Henrique de Moraes Holschuh

Now, that is interesting. Which problems? I honestly don’t know of any.

Read the discussion in the bug report. I think “localhost.localdomain” is ugly, but adding it seems much more feasible than fixing all the broken software.

John Hasler

Read the discussion in the bug report. I think “localhost.localdomain” is

I did. “localhost.localdomain” solved no problems, it was not even related to the problem they were trying to fix, and it certainly is not part of the best compromise solution (add another IP to loopback and use that for the canonical hostname).

Wouter Verhelst

Problems can have many causes. One of them may be that localhost.localdomain is unexpected; another may be that the software you were using is buggy, or misconfigured. Also, it could be that the problem you experienced back then has been fixed in the mean time.

When proposing a variation from long-standing historical practice, shouldn’t the onus be on the on making the change? What problem does ‘localhost.localdomain’ solve? Why is is better than just ‘localhost’, which has been common practice for oh, what, 20+ years?

Steve Greenland

When proposing a variation from long-standing historical practice, shouldn’t the onus be on the on making the change? What problem does ‘localhost.localdomain’ solve? Why is is better than just ‘localhost’, which has been common practice for oh, what, 20+ years?

It’s being long-standing does not mean it’s correct. I started looking for any standards or RFCs that require that the address 127.0.0.1 should resolve to “localhost” but I could only find some recommendations for DNS administrators, and nothing about /etc/hosts. Therefore I’d be inclined to say that if an application does not accept 127.0.0.1 being resolved to e.g. “foo” then it is is broken, and this is not changed by the fact that it has been broken for 20+ years.

There are other long-standing misunderstanding in network setup (just think about the stupidity of “@hostname —fqdn@”). Let’s fix the bugs in the applications instead of religiously following bad assumptions made in the past.

Gabor Gombas

It’s being long-standing does not mean it’s correct. I started looking

But it means it is a de-facto standard, which it is. Every *nix system I have mucked around with in the last five years, with the exception of a few Linux distributions, uses plain “localhost”.

Gabor Gombas

DNS administrators, and nothing about /etc/hosts. Therefore I’d be

/etc/hosts is a local implementation detail, it won’t make it to RFCs while there is still a bit of sanity in the world. It is probably in a POSIX-like standard, though.

Gabor Gombas

inclined to say that if an application does not accept 127.0.0.1 being resolved to e.g. “foo” then it is is broken, and this is not changed by the fact that it has been broken for 20+ years.

That is correct, yes.

Gabor Gombas

It’s being long-standing does not mean it’s correct.

No, but it doesn’t make changing it correct, either.

Again: what actual technical problem is solved by ‘localhost.localdomain”? Is solving that problem worth the potential breakage of existing code that assumes gethostbyaddr(127.0.0.1) == “localhost”. Note that I’m not arguing such code is correct, but I don’t see the need to pointlessly break it.

There are lots of long-standing characteristics of Unix systems that are not required by RFCs or Posix standards, yet we don’t go about arbitrarily changing them.

Gabor Gombas

It’s being long-standing does not mean it’s correct. I started looking for any standards or RFCs that require that the address 127.0.0.1 should resolve to “localhost” but I could only find some recommendations for DNS administrators, and nothing about /etc/hosts.

Having the DNS and /etc/hosts give different results is asking for trouble. RFC 1912 says that this discussion was had in the past and the conclusion was “localhost.”.

Lionel Elie Mamane

Having the DNS and /etc/hosts give different results is asking for trouble. RFC 1912 says that this discussion was had in the past and the conclusion was “localhost.”.

Note that that discussion was about appending the local (i.e. a real, existing) domain to localhost, and that indeed is problematic (first of all, there is no single “local domain” for multi-homed machines).

Appending a non-existent TLD to localhost is somewhat different, and is not addressed in the RFC.

Klaus Ethgen

I cannot specify it. But I remember that I did search for problemes in the past long time to find a error. And it was an entry of localhost.localdomain in a /etc/hosts. Maybe it was PVM or MySQL or other. I’m not sure.

IIRC leafnode complains about “localhost.localdomain” refusing to suck news unless you manually specify a domainname in its configuration file. Maybe you remember that trouble?

Still, I’ve ever considered that an issue with leafnode, not of “localhost.localdomain”.

Stefano Zacchiroli

IIRC leafnode complains about “localhost.localdomain” refusing to suck news unless you manually specify a domainname in its configuration file. Maybe you remember that trouble?

Still, I’ve ever considered that an issue with leafnode, not of “localhost.localdomain”.

It’s complaining because upstream wishes to strongly encourage users to configure things so that they have a globally unique hostname part to message IDs that are generated by Leafnode in order to minimise the risk of collisions. It will do the same thing for a few other things that look like default or incomplete configurations.

Mark Brown

It’s complaining because upstream wishes to strongly encourage users to configure things so that they have a globally unique hostname part to message IDs that are generated by Leafnode in order to minimise the risk

IMHO is too much to inhibit the use of the program as a whole just to minimize the collision risk, a warning would have been enough. But we are getting OT(hread) here …

Stefano Zacchiroli

IMHO is too much to inhibit the use of the program as a whole just to minimize the collision risk, a warning would have been enough. But we are getting OT(hread) here …

I don’t believe I indicated anything except the views of upstream there.

Stefano Zacchiroli

IMHO is too much to inhibit the use of the program as a whole just to minimize the collision risk, a warning would have been enough.

Particularly considering that there are better ways to assure the uniqueness of message-ids anyway.

Marco d’Itri

Please explain which troubles.

Some programs will try to solve the reverse for 127.0.0.1, during normal operations (not to verify WHAT 127.0.0.1 points to, but because it is doing reverse DNS for every connection, and one just came over lo).

Some of these programs, due to utter braindamage, special-case the string “localhost”. Change that, and they break. Mysql is the highest profile case, apparently.

Still, WHAT does a canonical name of localhost.localdomain. for 127.0.0.1 brings us? It is completely useless, it adds no extra functionality over a plain canonical name of “localhost”. And it breaks badly designed applications. While it pains me to say so (I absolutely loathe bad design), reverting that completely useless change looks like a very good idea to me.

Marco d’Itri

Please explain which troubles.

See the news.software.nntp traffic with people having strange problems with pathnames and message ID generation because of .localdomain. There have been a few separate cases of that over the past year or so.

Russ Allbery

See the news.software.nntp traffic with people having strange problems with pathnames and message ID generation because of .localdomain. There have been a few separate cases of that over the past year or so.

Not relevant. They would have the same problems with 127.0.0.1 = localhost.

(Not that I’m arguing either way, anyway.)

Marco d’Itri

Not relevant. They would have the same problems with 127.0.0.1 = localhost.

No, they won’t, because INN ignores hostnames that do not contain a period for the purposes of generating external identifiers, specifically to keep from using things like localhost or other unqualified names that aren’t globally unique. Adding the pointless .localdomain thing breaks that sort of simple sanity check.

Russ Allbery

No, they won’t, because INN ignores hostnames that do not contain a period for the purposes of generating external identifiers, specifically to keep from using things like localhost or other unqualified names that aren’t globally unique.

Relying on hostnames either with or without periods for uniqueness is both broken and unnecessary.

John Hasler

Relying on hostnames either with or without periods for uniqueness is both broken and unnecessary.

Would you like to propose an alternate approach that satisfies all of the constraints that INN is operating under? Presumably, given that you feel capable of expressing this strong of an opinion, you already know what all of those constraints are and are already familiar with the issues.

Russ Allbery

No, they won’t, because INN ignores hostnames that do not contain a period for the purposes of generating external identifiers, specifically to keep from using things like localhost or other unqualified names that aren’t globally unique. Adding the pointless .localdomain thing breaks that sort of simple sanity check.

Hmm, how would INN react if it sees a “normal-looking” name (like foo.bar.com) that in turn resolves to 127.0.0.1? It’s been a long time since I last run a news server and I used Diablo instead of INN so I’m not familiar with INN’s internals. But it seems INN is relying on a broken heuristics…

Gabor Gombas

Hmm, how would INN react if it sees a “normal-looking” name (like foo.bar.com) that in turn resolves to 127.0.0.1? It’s been a long time since I last run a news server and I used Diablo instead of INN so I’m not familiar with INN’s internals. But it seems INN is relying on a broken heuristics…

INN applies the following heuristic to determine the Path header and the hostname for the message ID if not otherwise configured:

• Obtain the system host name with gethostname().
• Look up an IP address for that host with gethostbyname().
• Look up the names associated with that address with gethostbyaddr().
• Walk the alias list of the result and find the first name containing a period.

A simple line of:

127.0.0.1  localhost localhost.localdomain

by itself doesn’t cause problems. It does, however, make it much easier for a common misconfiguration to result. That misconfiguration happens when users put the unqualified local hostname on the 127.0.0.1 line (a configuration that follows an old mistaken but common Unix practice, putting the unqualified hostname on every line of /etc/hosts). Then, the above algorithm ends up returning localhost.localdomain rather than the actual system hostname if the standard practice of listing 127.0.0.1 first is followed.

A user misconfiguration is needed on top of localhost.localdomain for this to be a problem, but that misconfiguration is not uncommon and (most tellingly) having localhost.localdomain there solves no actual real-world problems. It’s just a time bomb.

You can see from the above that if the user puts their complete hostname on 127.0.0.1, INN does just fine provided that localhost.localdomain isn’t listed before it. It also does fine if the user explicitly configures this part of INN, but as with most software, it’s best to figure out reasonable defaults where possible. This code has worked reasonably well for 13 years, except on systems with localhost.localdomain and this misconfiguration.

We could special-case localhost.localdomain, but why? What purpose does it serve to have that name in /etc/hosts?

Russ Allbery

* Obtain the system host name with gethostname().
* Look up an IP address for that host with gethostbyname().

The bug is here. This is completely wrong but sadly very common practice. It is common because it is portable and works with some simple configurations (namely, single-homed machines with static IP address).

Russ Allbery

* Look up the names associated with that address with gethostbyaddr().
* Walk the alias list of the result and find the first name containing a period.

The proper fix would be to enumerate all IP addresses of all network interfaces and select one that has an appropriate name. Unfortunately this is non-trivial and highly OS-dependent, although the libdumbnet1 package provides a platform-independent API for this (among other things).

Gabor Gombas

The proper fix would be to enumerate all IP addresses of all network interfaces and select one that has an appropriate name. Unfortunately this is non-trivial and highly OS-dependent, although the libdumbnet1 package provides a platform-independent API for this (among other things).

Wouldn’t the proper fix be to not use source address based authentication?

Olaf van der Spek

Wouldn’t the proper fix be to not use source address based authentication?

This is not authentication. INN just need a string to uniquely identify a host. Using a FQDN is OK, it’s just the way of obtaining that FQDN that is problematic.

Gabor Gombas

This is not authentication. INN just need a string to uniquely identify a host. Using a FQDN is OK, it’s just the way of obtaining that FQDN that is problematic.

Ah, I was thinking about the MySQL case.

Gabor Gombas

The bug is here. This is completely wrong but sadly very common practice. It is common because it is portable and works with some simple configurations (namely, single-homed machines with static IP address).

Well, I don’t really agree with the statement that it’s completely wrong, but I do understand what you’re saying about the semantic mismatch at work here.

Gabor Gombas

The proper fix would be to enumerate all IP addresses of all network interfaces and select one that has an appropriate name. Unfortunately this is non-trivial and highly OS-dependent, although the libdumbnet1 package provides a platform-independent API for this (among other things).

You’ve pretty much covered in that paragraph the reasons why INN can’t take that approach. :) I know how hard this is from watching MIT Kerberos try to solve this problem and don’t want to touch this portability nightmare with a ten-foot pole.

Marco d’Itri

Please explain which troubles.

Mine with MySQL. And the reason why I initiated this thread. :)

MySQL definitely chokes on localhost.localdomain. And although MySQL will adopt to distributions using “localhost.localdomain” instead of “localhost” doesn’t mean it’s correct. MySQL by default expects “localhost” as the hostname assigned to the loopback interface. And there is difference between “localhost” (special meaning) and “localhost.localdomain” (some hostname) for MySQL.

“RedHat does it” isn’t a good argument for me either. Inheriting unneeded entries should be thought about. I don’t think it’s the right way to expect all the software to add hacks to detect “localhost.localdomain”.

So still I’m removing the localhost.localdomain after every installation. Somehow I’m not happy about it.

Apparently this discussion has been done a year ago already and nothing resulted from it. I hope we are getting somewhere this time.

Klaus Ethgen

The only reason I find is that RedHat use it. But RedHat shouldn’t be debians requirement of quality. It should be other way around. RedHat is such a buggy distribution. And it gets more and more worse every upgrade.

Klaus Ethgen

But why changing “localhost” to “localhost.localdomain” only for the reason that RedHat doing it?

Christoph Haas

“RedHat does it” isn’t a good argument for me either.

I’d just like to point out that the whole idea that this was somehow influenced by Red Hat is a red er, herring. d-i is a thouroguhly NIH enterprise, we obviously don’t follow the lead of Red Hat.

In the future, please try to limit your posts to those that contain provable facts.jk

Christoph Haas

MySQL definitely chokes on localhost.localdomain. And although MySQL will adopt to distributions using “localhost.localdomain” instead of “localhost” doesn’t mean it’s correct. MySQL by default expects “localhost” as the hostname assigned to the loopback interface.

No, MySQL is happy to use whatever name the loopback interface has; it is the MySQL documentation that stresses the “localhost” string without mentioning that it depends on the naming service configuration.

So the bug is that the documentation does not describe what the code really does; you have to fix one or the other. Upstream went with modifying the code rather than the documentation, and I agree with them.

Gabor Gombas

No, MySQL is happy to use whatever name the loopback interface has; it is the MySQL documentation that stresses the “localhost” string without mentioning that it depends on the naming service configuration.

Thanks for the clarification. Since I didn’t feel like reading the source code of MySQL I relied on its documentation. And it was a bit confusing (not only to me). So MySQL is happy with whatever name is bound to the lo interface. Good to know.

Gabor Gombas

No, MySQL is happy to use whatever name the loopback interface has; it is the MySQL documentation that stresses the “localhost” string without mentioning that it depends on the naming service configuration.

Thats not completely true. MySQL use the name “localhost” to select a other connection methode (socket). If you use the ip or localhost.localdomain it tries to connect bei network which is much slower.

Pierre Machard

IIRC The main reason was described in #247734

ARGH!

If that bug was the reason why the localhost entry in /etc/hosts was changed, then please fix it right back to what it was.

The localhost.localdomain stuff appeared from nowhere in an email by Pierre Machard during the discursion, and stayed on all other examples while people tried to fix an issue (which has a fucking old proper solution, which is to use another loopback IP and if needed, another lo alias) that had nothing to do with it.

Pierre, WHY do you need localhost.localdomain? That is NOT clear in the bug report. And the rest of the bug report is about another issue completely, dealing with people not being able to grasp the idea that if you need a canonical hostname other than localhost, you need another interface (which can be “lo” just as well, but give it another IP).

Henrique de Moraes Holschuh

ARGH!

If that bug was the reason why the localhost entry in /etc/hosts was changed, then please fix it right back to what it was.

The localhost.localdomain stuff appeared from nowhere in an email by Pierre Machard during the discursion, and stayed on all other examples while people tried to fix an issue (which has a fucking old proper solution, which is to use another loopback IP and if needed, another lo alias) that had nothing to do with it.

I can not remember precisely. I think that at that time I was testing the debian-installer and I saw it was taken a long while to boot. I saw that my system had no FQDN (hostname -f). When you add .localdomain, the FQDN is complete and it helps to solve timeout in several application.

Anyway I do not understand why this issue is a problem since we simply add an alias to localhost. Nobody say that we will remove localhost and exchange it by localhost.localdomain.

Pierre Machard

I can not remember precisely. I think that at that time I was testing the debian-installer and I saw it was taken a long while to boot. I saw that my system had no FQDN (hostname -f). When you add .localdomain, the FQDN is complete and it helps to solve timeout in several application.

So it was just papering over a real bug, namely the existence of the “-f” option of hostname. “hostname -f” assumes that the hostname (as returned by gethostname(3)) has something to do with networking, which is false. It also assumes that the system has just one IP address with one FQDN which is also false.

This is a perfect example of a long-standing assumption that was wrong from the start but tended to work in the past when the wast majority of computers had really just one network interface with one IP address, and the few machines having multiple NICs/multiple IP addresses had good sysadmins who could deal with the breakage caused by this assumption.

Nowadays even desktop boards start to come with multiple NICs on-board so this “one IP – one FQDN” assumption must be stopped. “hostname -f” must be killed, and everything that uses it must be fixed. Well, it may take some time to sort out all the details, there are a lot of broken programs out there…

Pierre Machard

Anyway I do not understand why this issue is a problem since we simply add an alias to localhost. Nobody say that we will remove localhost and exchange it by localhost.localdomain.

Broken software compares reverse_lookup({127.0.0.1}) with the string “localhost” and is surprised when it gets FALSE due to the reverse lookup returning “localhost.localdomain” instead of just “localhost”.

Gabor Gombas

So it was just papering over a real bug, namely the existence of the “-f” option of hostname. “hostname -f” assumes that the hostname (as returned by gethostname(3)) has something to do with networking, which is false. It also assumes that the system has just one IP address with one FQDN which is also false.

Those asumptions are not false, they are what they are: asumptions. If you dont want to configure your system that way, just dont use it.

Bernd Eckenfels

Those asumptions are not false, they are what they are: asumptions. If you dont want to configure your system that way, just dont use it.

That is what I say: every Debian package that uses “hostname -f” is bogus, because it relies on a certain system configuration.

Gabor Gombas

That is what I say: every Debian package that uses “hostname -f” is bogus, because it relies on a certain system configuration.

Umm, I guess all debian packages relies on certain configurations.

Pierre Machard

Anyway I do not understand why this issue is a problem since we

Because instead of doing this:

127.0.0.1 localost localhost.localdomain

It was done like this:

127.0.0.1 localhost.localdomain localhost

Thus changing the canonical name of the loopback interface. PLEASE do not do this unless you have extremely good reasons to do so. An untracked DNS timeout is definately not one. If you can still reproduce the problem, we can work on tracking that thing down without the localhost.localdomain.

Add a new loopback interface (say, 127.0.0.2) and name it however you want. That will not break anything at all, and it allows you to name your system in whatever way you might want. This is what d-i should be doing, it is the maximum compatibility path.

You don’t even need to add a new interface if you use iproute instead of outdated ifconfig crap, and you might get away without even that much (but I wouldn’t try it, I don’t think trying to bind a socket to an IP that is not local (even if it pings because of lo and the /8 netmask) is a very safe thing to do).

Henrique de Moraes Holschuh

Because instead of doing this:

127.0.0.1 localost localhost.localdomain

It was done like this:

127.0.0.1 localhost.localdomain localhost

Thus changing the canonical name of the loopback interface. PLEASE do not do this unless you have extremely good reasons to do so. An untracked DNS

Agreed.

Another point is that it would be bad to have 127.0.0.1 resolve differently in /etc/hosts and DNS (we ship a 127.in-addr.arpa zone).

Henrique de Moraes Holschuh

Because instead of doing this:

127.0.0.1 localost localhost.localdomain

It was done like this:

127.0.0.1 localhost.localdomain localhost

Thus changing the canonical name of the loopback interface. PLEASE do not do this unless you have extremely good reasons to do so. An untracked DNS timeout is definately not one. If you can still reproduce the problem, we can work on tracking that thing down without the localhost.localdomain.

The fact is that nobody complained about that… and my bug was repported more than one year and a half ago. Plus It was disscussed on debian-devel. Please do not argue with me!

I do not pretend that I know anything in name resolution, however I proposed something that worked on my system. It was widely discussed. I joined this current thread to show people who do not read -devel every day that we have already talk about it. Nothing more, nothing less.

Please have a look at Subject: /etc/hosts: Two lines with the same IP address? by Thomas Hood

Pierre Machard

The fact is that nobody complained about that… and my bug was

Now we are :)

Pierre Machard

repported more than one year and a half ago. Plus It was disscussed on debian-devel. Please do not argue with me!

It is nothing personal… it is just that your email was the first one mentioning the .localdomain thing, I wanted to know why you needed it.

Heck, I had never noticed that all my new sarge installs had this broken thing in them (but now I will have to quadruple-check mysql to make sure it is not doing something idiotic behind my back. I am pleasantly surprised that it did not go up in flames, so maybe they fixed their localhost braindamage).

Pierre Machard

proposed something that worked on my system. It was widely discussed. I joined this current thread to show people who do not read -devel every day that we have already talk about it. Nothing more, nothing less.

It was useful, at least now we know the history of the change, and thus we can deal better with it. Thanks.

Pierre Machard

Please have a look at Subject: /etc/hosts: Two lines with the same IP address? by Thomas Hood

With a subject line like that, I certain would never expect it to be related to 127.0.0.1 canonical naming… no wonder I never noticed the thread.

Henrique de Moraes Holschuh

Because instead of doing this:

127.0.0.1 localost localhost.localdomain

It was done like this:

127.0.0.1 localhost.localdomain localhost

Thus changing the canonical name of the loopback interface. PLEASE do not do this unless you have extremely good reasons to do so. An untracked DNS timeout is definately not one. If you can still reproduce the problem, we can work on tracking that thing down without the localhost.localdomain.

FWIW, it was done as a result of bug #247734, which includes details on how every possible choice seems to break something and the reasoning that led to the current choice.

Henrique de Moraes Holschuh

Add a new loopback interface (say, 127.0.0.2) and name it however you want. That will not break anything at all, and it allows you to name your system in whatever way you might want. This is what d-i should be doing, it is the maximum compatibility path.

Already done:

netcfg (1.13) unstable; urgency=low

[ 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.

— Frans Pop Fri, 19 Aug 2005 21:08:39 +0200

Joey Hess

FWIW, it was done as a result of bug #247734, which includes details on how every possible choice seems to break something and the reasoning that led to the current choice.

I read that bug report VERY carefully. Twice. There is nothing there that seems to have been fixed/addressed by .localdomain, except maybe a DNS timeout in Pierre’s machine. Everything else deals with the hostname.

Or am I getting confused and d-i uses localhost.localdomain as the default hostname, and say, if I had told it that my machine is named “twerk”, domain “foo.bar” I would get a

127.0.0.1 twerk.foo.bar twerk localhost

entry in /etc/hosts?

That would explain a lot… but still make such a “fix” quite a bad idea.

Joey Hess

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.

This could cause trouble that is easily avoided by actually adding an extra loopback address to lo (or a lo:1 alias if you have to use ifconfig) of 127.0.1.1. This is harmless and could be added statically and unconditionally to /etc/network/interfaces.

Henrique de Moraes Holschuh

Or am I getting confused and d-i uses localhost.localdomain as the default hostname, and say, if I had told it that my machine is named “twerk”, domain “foo.bar” I would get a

127.0.0.1 twerk.foo.bar twerk localhost

entry in /etc/hosts?

That would explain a lot… but still make such a “fix” quite a bad idea.

There was certainly a problem at one point where attempting to cannoicalise the hostname of a freshly installed system would result in a localhost address. That was fixed prior to the sarge release and IIRC the localhost.localdomain thing was already there before this was fixed, though I’ve not checked.

Henrique de Moraes Holschuh

I read that bug report VERY carefully. Twice. There is nothing there that seems to have been fixed/addressed by .localdomain, except maybe a DNS timeout in Pierre’s machine. Everything else deals with the hostname.

FWIW, I completely agree with Henrique here (and pretty much in all past messages in this thread)—I also read that bug report VERY carefully, and I do not see how adding .localdomain had anything to do with the resolution of that bug.

I believe that localhost.localdomain should be removed, as it is both unnecessary and arbitrary.

Henrique de Moraes Holschuh

Or am I getting confused and d-i uses localhost.localdomain as the default hostname, and say, if I had told it that my machine is named “twerk”, domain “foo.bar” I would get a

127.0.0.1 twerk.foo.bar twerk localhost

entry in /etc/hosts?

That would explain a lot… but still make such a “fix” quite a bad idea.

No, on all of my sarge and sid machines the entry looked like:

127.0.0.1 localhost.localdomain localhost foobar

Where foobar was the name I gave during the install process.

Henrique de Moraes Holschuh

I read that bug report VERY carefully. Twice. There is nothing there that seems to have been fixed/addressed by .localdomain, except maybe a DNS timeout in Pierre’s machine. Everything else deals with the hostname.

I don’t have the stamina that you do, so I’ve only read random bits of it a half-dozen times. The localhost.localdomain does seems to kind of appear out of the blue half way through and looks very likely to have been glommed in with the rest of the changes by mistake. It’s hard to tell looking back at the history.

Anyway, please bear in mind that it’s very easy for me to go in and change this line of code:

fprintf(fp, "127.0.0.1\tlocalhost.localdomain\tlocalhost\n");

To this:

fprintf(fp, "127.0.0.1\tlocalhost\n");

But it’s then very hard to see if this breaks anything. After all, the relevant change was made in netcfg in July of 2004. For an entire year, it was in every system installed, and nobody complained, although a few of us noticed it and thought it looked a bit strange. Debian released and for months after the release nobody apparently saw fit to complain or report any problems until this thread.

If I make any changes, I don’t want to have them pop up and result in another thread like this¹ in 1.5 years time when we’re trying to release, or have just released, etch. Also, I don’t pretend to be any kind of expert on the absurdly fragile and unintuitive behavior the system exhibits with different flavours of localhost entry in the /etc/hosts file. I’m just a guy who happens to know where the code is and how to change if it I get a clear explanation of why it’s broken and why a given change is thuroughly correct.

So far, this thread has not yeilded anything I can trust to that degree.

Of course this change doesn’t have to go through me. Joshua Kwan has maintained netcfg in less busy times in his life. Thomas Hood comes as close as any developer does to “owning” Debian’s local resolver setup. Pulling them into a discussion about this would be a very productive thing to do. They’d probably be a lot more willing to look at the issues in depth and quickly make an appropriate change.

Oh yeah, I should point out that I’ve been seeing various programs in Debian not properly work with various /etc/hosts settings for at least ten years. I belive that the typical thing a sysadmin does when their current /etc/hosts setting breaks some program is to change it to somerthing else, wait for the next thing to break, and ignore the problem otherwise. So I don’t think this is necessarily really a new problem, and I don’t know that there is actually a fix that fixes all the problems, and I understand why we don’t seem to get any feedback evne if it’s broken. :-/

Joey Hess

But it’s then very hard to see if this breaks anything. After all, the relevant change was made in netcfg in July of 2004. For an entire year, it was in every system installed, and nobody complained, although a few of us noticed it and thought it looked a bit strange.

I had this problem since then because I use MySQL very intensively. But I just didn’t ask here. That doesn’t mean that I made this up. Sometimes bugs are reported long times after they appeared. The complaint is not about the “strange looks” but about interoperation problems.

Joey Hess

If I make any changes, I don’t want to have them pop up and result in another thread like this¹ in 1.5 years time when we’re trying to release, or have just released, etch.

It is surely difficult to just remove it since newer applications may rely on it. But shouldn’t we better announce that intended change to debian-devel-announce and ask for feedback if it breaks someone else’s work? Similar to library transitions.

Joey Hess

So far, this thread has not yeilded anything I can trust to that degree.

IIRC it yielded the fact that localhost.localdomain is has been added to fix applications without being aware that it may break other applications. That’s a lot more than the first postings saying “you are inventing things”, “it’s a known bug for MySQL” or “use localhost.localdomain in MySQL then” which all weren’t satisfying.

Joey Hess

¹ Especially not given the quantity of whining, hot air, uninformed comments, stupid comparisons to red hat, etc that have made portions of this thread such a positive joy to read.

Why so rude? I asked for comments on the “why“s. And all we had were assumptions since nobody knew for sure. And even we now know how that entry appeared we can’t figure out why it went there and if it’s safe to remove it. I would stop emitting “hot air” if it wouldn’t break other applications. But it does. And this is not my workplace where my boss tells me “it has always been like that”. Let’s change it.

Christoph Haas

IIRC it yielded the fact that localhost.localdomain is has been added to fix applications

Not that I’ve noticed. Maybe I just missed it, but what applications or what problems does .localdomain fix? I don’t remember hearing so far that it does anything positive at all.

If anybody knows anything at all about a problem .localdomain solves, I would love to hear about it. Never mind the alleged applications that break, I’m more interested in whether there are even two sides to this story in the first place.

The change from ‘localhost’ to ‘localhost.localdomain’ was made in svn revision 16759. The Debian changelog entry added at that time refers to bug report #247734. Looking at #247734 I see that ‘localhost.localdomain’ appeared without anyone either supporting its inclusion or objecting to it. This wasn’t what the conversation was about.

I see no reason not to revert the change. If the presence of ‘localhost.localdomain’ causes trouble and if standard practice is to have ‘localhost’ only then I think that that is reason enough to revert.

However, I think that applications should work properly whether /etc/hosts contains

127.0.0.1 localhost.localdomain localhost

or

127.0.0.1 localhost

especially considering the fact that the sarge installer writes /etc/hosts with the former.

Thomas Hood

The change from ‘localhost’ to ‘localhost.localdomain’ was made in svn revision 16759. The Debian changelog entry added at that time refers to bug report #247734. Looking at #247734 I see that ‘localhost.localdomain’ appeared without anyone either supporting its inclusion or objecting to it. This wasn’t what the conversation was about.

I see no reason not to revert the change. If the presence of ‘localhost.localdomain’ causes trouble and if standard practice is to have ‘localhost’ only then I think that that is reason enough to revert.

However, I think that applications should work properly whether /etc/hosts contains

127.0.0.1 localhost.localdomain localhost

or

127.0.0.1 localhost

especially considering the fact that the sarge installer writes /etc/hosts with the former.

Others on this list have pointed out that some applications expect 127.0.0.1 to resolve to localhost. When the resolver uses /etc/hosts, it returns the first host in the list and the others are considered aliases. In the first example above, localhost.localdomain would be returned when resolving 127.0.0.1; this is because it is listed before localhost. If /etc/hosts were changed to:

127.0.0.1 localhost localhost.localdomain

Resolution of 127.0.0.1 would properly return localhost.

I’ve been unable to find any specific reference to a required structure of a hosts file nor any specific requirement that a resolver should resolve 127.0.0.1 to localhost. However, consider the following two points:

1. When configuring DNS, 127.0.0.1 must resolve to localhost and vice versa [1]. Configuring an /etc/hosts file that resolves 127.0.0.1 to localhost.localdomain is inconsistent. On the same host, resolving 127.0.0.1 by gethostbyname() and running nslookup will return two different answers (provided nsswitch.conf is configured with “files dns”). [1] RFC 1912 – http://www.ietf.org/rfc/rfc1912.txt
2. Virtually all systems with a hosts file read something like this:

127.0.0.1 localhost <alias> <another alias> <...>

There is a long historical precedent for listing localhost first, followed by other aliases. This results in the resolver properly returning localhost when resolving 127.0.0.1.

In summary: (1) It’s reasonable to expect DNS and file based resolution to function the same in regard to 127.0.0.1/localhost (proper DNS resolution of 127.0.0.1 is documented in RFC 1912). (2) There is a long historical precedent for localhost preceding all aliases of 127.0.0.1 in a hosts file.

Jeff Stevens

If /etc/hosts were changed to:

127.0.0.1 localhost localhost.localdomain

Resolution of 127.0.0.1 would properly return localhost.

Yeah, but that’s all beside the point. There is no point in swapping the order of the two names unless there be any point in having “localhost.localdomain” in there at all.

So far, I haven’t heard any reason.

In other words, rather than say “here is how we could change the hosts file so that localhost.localdomain does not cause buggy apps to break”, we are (or should be) asking “why should localhost.localdomain be in there at all?”

Jeff Stevens

2. Virtually all systems with a hosts file read something like this:

127.0.0.1 localhost <...>

There is a long historical precedent for listing localhost first,

Well, that’s not quite true. As someone else pointed out earlier, AIX lists “loopback localhost”. (He said AIX 5.1 or 5.2, but I first noticed it in 4.1.) I always thought it was kind of strange and nonstandard … but on the other hand, most everything in AIX is kind of strange and nonstandard.

Peter Samuelson

Well, that’s not quite true. As someone else pointed out earlier, AIX lists “loopback localhost”.

On a fresh OpenBSD 3.7 install:

::1 localhost.home localhost
127.0.0.1 localhost.home localhost

(“home” is the domain used on my vmware intranet). So “localhost” is not the first alias here either.

Gabor Gombas

On a fresh OpenBSD 3.7 install:

::1 localhost.home localhost
127.0.0.1 localhost.home localhost

Heh, I’m just surprised it’s not:

127.0.0.1 OpenLocalHOST localhost

OK, I have modified netcfg so that it writes

127.0.0.1   localhost

to /etc/hosts.

From now on let’s consider at least the following two phenomena to be bugs:

• The application expects to be able to resolve ‘localhost.localdomain’ to an IP address.
• The application breaks if ‘localhost.localdomain’ is included on the 127.0.0.1 line in /etc/hosts.

Thomas Hood

OK, I have modified netcfg so that it writes

127.0.0.1 localhost

to /etc/hosts.

Thank you! Yay for purging ugly non-standardness! =)

Thomas Hood

From now on let’s consider at least the following two phenomena to be bugs:

* The application expects to be able to resolve ‘localhost.localdomain’ to an IP address.
* The application breaks if ‘localhost.localdomain’ is included on the 127.0.0.1 line in /etc/hosts.

Yes, I totally agree here. =)

Thomas Hood

OK, I have modified netcfg so that it writes

127.0.0.1 localhost

to /etc/hosts.

From now on let’s consider at least the following two phenomena to be bugs:

* The application expects to be able to resolve ‘localhost.localdomain’ to an IP address.
* The application breaks if ‘localhost.localdomain’ is included on the 127.0.0.1 line in /etc/hosts.

Fantastic! Might I add that it is not a bug for an application to expect resolution of 127.0.0.1 to return localhost? That is, localhost shall precede any other aliases in /etc/hosts.

Again, thank you. Attention to detail is quite important; in this case detail is the location and/or existence of a mere 21 bytes.

Thomas Hood

OK, I have modified netcfg so that it writes

127.0.0.1 localhost

to /etc/hosts.

Thank you very much. My fellow sysadmins will appreciate that. And of course I’m very glad that after a lot of global warming the thread finally got somewhere. :)

Thomas Hood

OK, I have modified netcfg so that it writes

127.0.0.1 localhost

to /etc/hosts.

Excellent. Thank you. :)

Jeff Stevens

1. When configuring DNS, 127.0.0.1 must resolve to localhost and vice versa [1].

No, the RFC does not say “must”, it only says “should” (and it is not even a “SHOULD”).

An regardless if localhost.localdomain is removed from /etc/hosts or not, finding & fixing applications that choke on it is a good thing.

Pierre Machard

I can not remember precisely. I think that at that time I was testing the debian-installer and I saw it was taken a long while to boot. I saw that my system had no FQDN (hostname -f). When you add .localdomain, the FQDN is complete and it helps to solve timeout in several application.

Nope, hostname is not responsible for this.

Yes you need to configure the FQDN in hosts, but not with the 127.0.0.1 entry. And hostname should also never return this stupid dummy FQDN (however it does not avoid to do so).

Pierre Machard

Anyway I do not understand why this issue is a problem since we simply add an alias to localhost.

The problem is that it is the first alias.

Pierre Machard

Anyway I do not understand why this issue is a problem since we simply add an alias to localhost. Nobody say that we will remove localhost and exchange it by localhost.localdomain.

If what you wanted to do was to add an alias, you should have read the documentation on how to add an alias without changing the canonical hostname for 127.0.0.1. This documentation is available in hosts(5).

This manual page describes the format of the /etc/hosts file. This file is a simple text file that associates IP addresses with hostnames, one line per IP address. For each host a single line should be present with the following information:

IP_address canonical_hostname aliases

Changing the canonical hostname changes the output of everything that resolves IP address, including “lsof” and “netstat”.

Any script or program dependent on this output need to be checked and possibly changed if it is to behave as it should. This includes local scripts created by our users.

It should also be consistent with bind9, and I do not think that changing bind is the correct way to do things.

iostat:~# getent hosts 127.0.0.1
127.0.0.1       localhost.localdomain localhost iostat
iostat:~# dig -x 127.0.0.1 @localhost
; <<>> DiG 9.2.4 <<>> -x 127.0.0.1 @localhost
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11671
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.                IN      PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 604800  IN      PTR     localhost.

;; AUTHORITY SECTION:
127.in-addr.arpa.       604800  IN      NS      localhost.

;; ADDITIONAL SECTION:
localhost.              604800  IN      A       127.0.0.1

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Fri Oct  7 07:19:19 2005
;; MSG SIZE  rcvd: 93

Pierre Machard

I can not remember precisely. I think that at that time I was testing the debian-installer and I saw it was taken a long while to boot. I saw that my system had no FQDN (hostname -f). When you add .localdomain, the FQDN is complete and it helps to solve timeout in several application.

Anyway I do not understand why this issue is a problem since we simply add an alias to localhost. Nobody say that we will remove localhost and exchange it by localhost.localdomain.

The problem is probably that the “localhost.localdomain” stands before “localhost” in that line. So if you “reverse resolve” 127.0.0.1 you end up with “localhost.localdomain” which some applications don’t understand.

Christoph Haas

The problem is probably that the “localhost.localdomain” stands before “localhost” in that line. So if you “reverse resolve” 127.0.0.1 you end up with “localhost.localdomain” which some applications don’t understand.

Christopher hits the nail on the head. There are two separate issues:

1. Is there a reason to have localhost.localdomain
2. If there is localhost.localdomain should not precede localhost!

I’m not going to comment on the former but the latter is a BIG deal. The current Debian /etc/hosts file is flat out wrong. When a call to gethostbyname(3) or gethostbyaddr(3) and an IPV4 address of 127.0.0.1 is supplied, it should return “localhost”. Provided resolv.conf is configured to use files and then dns, gethostbyname/gethostbyaddr is going to query /etc/hosts. In /etc/hosts multiple hostnames can be assigned to a single address, but when resolving an address to a hostname, the first hostname in the list is returned by gethostbyname/gethostbyaddr.

Every sane implementation of IP returns “localhost” when querying 127.0.0.1. It doesn’t matter if the implementation uses /etc/hosts, /etc/inet/hosts, /boot/beos/etc/hosts, or (*gulp*) c:\winnt\system32\drivers\etc\hosts.

Of course, other systems ship with a default hosts file containing something in addition to “localhost” that resolves to 127.0.0.1. The issue with Debian is that “localhost.localdomain” comes before “localhost”. A call to gethostbyname() to resolve localhost returns a struct referring to 127.0.0.1. A call to gethostbyname() to resolve 127.0.01 returns a struct referring to localhost.localdomain. This is wrong.

This has been mentioned before, but I’ll say it again. This is solely because the Debian /etc/hosts reads:

127.0.0.1       localhost.localdomain localhost

“localhost.localdomain” and “localhost” must be swapped. The first entry in the list of hosts must be “localhost”.

Just as a sanity check, Solaris ships with:

127.0.0.1   localhost loghost

FreeBSD ships with:

127.0.0.1       localhost localhost.my.domain myname.my.domain

I don’t have access to AIX, HPUX or other major Unices, but I bet in the hosts file, 127.0.0.1 is immediately followed by localhost — and other aliases follow localhost. “localhost” must be first.

Jeff Stevens

I don’t have access to AIX, HPUX or other major Unices, but I bet in the hosts file, 127.0.0.1 is immediately followed by localhost — and other aliases follow localhost. “localhost” must be first.

AIX 5.2:      127.0.0.1 loopback localhost
HP-UX 11.00:  127.0.0.1 localhost loopback
IRIX 6.5:     127.0.0.1 localhost
Tru64 4.0G:   127.0.0.1 localhost

Jeff Stevens

“localhost.localdomain” and “localhost” must be swapped. The first entry in the list of hosts must be “localhost”.

You make quite a lot of noise it this mail, but I fail to find any real arguments. (Unless you consider saying “this should be so” or “this is wrong” an argument.)

You give nice explanations how things work, but fail to say anywhere why having localhost.localdomain first is so wrong. What breaks? What standards (with reference please) are not honored? What alternative solutions do you propose for the problems that led up to it being included?

Frans Pop

You give nice explanations how things work, but fail to say anywhere why having localhost.localdomain first is so wrong. What breaks? What standards (with reference please) are not honored?

An obvious problem is that gethostbyaddr and DNS queries will now return a different answer.

Frans Pop

What alternative solutions do you propose for the problems that led up to it being included?

It has already been explained that a better solution with no side effects would be to add an alias like 127.1.0.1

Frans Pop

You make quite a lot of noise it this mail, but I fail to find any real arguments. (Unless you consider saying “this should be so” or “this is wrong” an argument.)

You give nice explanations how things work, but fail to say anywhere why having localhost.localdomain first is so wrong. What breaks? What standards (with reference please) are not honored?

Well, even if Jeff didn’t provide anything helpful in this regard, the thread does show at least two specific packages that break when using localhost.localdomain as the canonical name for 127.0.0.1: mysql, and inn. Yes, it is appropriate to fix both of these applications to be more robust; however,

Frans Pop

What alternative solutions do you propose for the problems that led up to it being included?

I can’t actually see anything in the bug log to indicate that localhost.localdomain does solve any of the issues that were raised.

Frans Pop

You make quite a lot of noise it this mail, but I fail to find any real arguments. (Unless you consider saying “this should be so” or “this is wrong” an argument.)

You give nice explanations how things work, but fail to say anywhere why having localhost.localdomain first is so wrong. What breaks? What standards (with reference please) are not honored? What alternative solutions do you propose for the problems that led up to it being included?

You are correct that there probably are not any documented standards requiring “127.0.0.1” to resolve to “localhost” except when DNS is used. That is, if DNS is queried to resolve “127.0.0.1” it is expected to resolve to “localhost” — nothing else. I don’t believe such a written standard exists for resolution through /etc/hosts.

I’m simply trying to illustrate that there are years of precedent. It has been safe to assume that a resolver will resolve “127.0.0.1” to “localhost” — even if resolution is completed by using a hosts file.

Taking into consideration:

• DNS is expected to resolve “127.0.0.1” to “localhost”
• Applications expect resolution of “127.0.0.1” to “localhost”
• Consistent cross vendor resolution of “127.0.0.1” to “localhost”

There may not be a written standard but a de facto standard certainly exists.

Gabor Gombas

Ok, after a quick googling I found that this bug has already been reported for MySQL: http://bugs.mysql.com/11822 and is fixed in MySQL 5.0.11. So if it bothers you, you should upgrade.

Changing the canonical name of localhost is an arbitrary change that breaks more than MySQL. It also violates the principle of least astonishment.

“We’ve changed something, we’re not sure why, but it breaks MySQL. If it bothers you, you should upgrade MySQL”

Nah, I don’t think that is what we want to tell our users.

Stig Sandbeck Mathisen

Changing the canonical name of localhost is an arbitrary change that breaks more than MySQL. It also violates the principle of least astonishment.

Then fix those other broken things as well. If you want localhost-style authentication, you should do the comparison on the IP address rather than the resolved name for several reasons:

• The IP address range for the loopback interface is standardized (127.0.0.0/8). The value returned by the reverse lookup is not.

• Doing the reverse lookup may introduce an attack vector because it relies on the whole NSS being configured right. Avoiding the reverse lookup avoids this attack vector.

• Doing the reverse lookup is just unneccessary, avoiding it saves CPU cycles (this may be important if you want to serve lots of connection attempts)

Gabor Gombas

Then fix those other broken things as well.

Contrary to popular belief among our users, system administrators does not have access to every server on the internet. Therefore, I can not help you solve this issue in this way.

Instead, I propose we return the content of the Debian /etc/hosts file to the way it was before the change.

Gabor Gombas

If you want localhost-style authentication, you should do the comparison on the IP address rather than the resolved name for several reasons:

[snip good reasons]

I don’t trust client address/name resolving for any authentication of clients. I resent the implication that I do.