Re: Re: localhost.localdomain

[Albino B Neto]

2015-11-28 3:25 GMT-02:00 Crystal Wood :
> ;)

You shutdow use Bottom-posting [0]. :-)

0 - http://idallen.com/topposting.html

  Albino

Re: Re: localhost.localdomain

[Crystal Wood]

;)

Re: localhost.localdomain

[Russ Allbery]

Gabor Gombas <[EMAIL PROTECTED]> writes:
> On Fri, Oct 07, 2005 at 11:18:57AM -0700, Russ Allbery wrote:

>>  * 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).

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.

>>  * 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).

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.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Miles Bader]

Gabor Gombas <[EMAIL PROTECTED]> writes:
> 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

-miles
-- 
Quidquid latine dictum sit, altum viditur.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Do den 20. Okt 2005 um 16:01 schrieb 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.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ1exOJ+OKpjRpO3lAQJH0wf/UTwNaQcI/4mhcLj4o/ZhgfJNXFSUyroM
Ok/mkrwpww/4LPjD4ZnsgmZVi/MWScfO4eFNm29Tc+K5aHrbvxqqEpIFXXDuLiHb
IvZZXxyRAkO5RD/M0Jjo9oxmLl7GpQy4yIQn3KCSSLu6b4TtoOv9ZZt0Mh67x60W
MujnKp90NJEDsHGfAFYvBSpzewYevEH6nCG543YfKq66FwniAKQAyCPelWbWgwx3
aCf71In8PxIrZoZw5K6PGG8vgEH/gBnwJoxGZdqHgufyUx34O9QY0SakTdUc/A+g
xfnUR1FLj1w+HE9Pe2oADBwlqNDN6kF0octUnGPQlkeu6trrDMm7AA==
=vGLk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Christoph Haas]

On Thursday 20 October 2005 16:01, Gabor Gombas wrote:
> On Fri, Oct 07, 2005 at 04:15:18PM +0200, Christoph Haas wrote:
> > 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.

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.

Regards
 Christoph


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 14, 2005 at 03:25:53AM -0500, Peter Samuelson wrote:

> 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Olaf van der Spek]

On 10/20/05, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 20, 2005 at 04:16:40PM +0200, Olaf van der Spek wrote:
>
> > 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.

Ah, I was thinking about the MySQL case.

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 20, 2005 at 04:16:40PM +0200, Olaf van der Spek wrote:

> 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Olaf van der Spek]

On 10/20/05, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> 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?

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 13, 2005 at 12:35:11PM -0700, Jeff Stevens wrote:

> 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").

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

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 07, 2005 at 04:15:18PM +0200, Christoph Haas wrote:

> 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 07, 2005 at 11:18:57AM -0700, Russ Allbery wrote:

>  * 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).

>  * 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Stig Sandbeck Mathisen]

Thomas Hood wrote:


OK, I have modified netcfg so that it writes

   127.0.0.1localhost

to /etc/hosts.
 


Excellent.  Thank you.  :)



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Christoph Haas]

Thomas...

On Friday 14 October 2005 10:47, Thomas Hood wrote:
> 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. :)

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Jeff Stevens]

On Fri, 2005-10-14 at 10:47 +0200, Thomas Hood wrote:
> 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.

-Jeff


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Wesley J. Landaker]

On Friday 14 October 2005 02:47, Thomas Hood wrote:
> 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! =)

> 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. =)

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgplsRX5lyUm5.pgp
Description: PGP signature

Re: localhost.localdomain

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

-- 
Thomas Hood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Peter Samuelson]

[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?"

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


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Jeff Stevens]

On Thu, 2005-10-13 at 16:02 +0200, Thomas Hood wrote:
> 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

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

Thanks!

-Jeff  




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Peter Samuelson]

  [Joey Hess]
> > So far, this thread has not yeilded anything I can trust to that degree.

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


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Christoph Haas]

On Sat, Oct 08, 2005 at 06:53:28PM -0400, Joey Hess wrote:
> 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.

> If I make any changes, I don't want to have them pop up and result in
> another thread like this[1] 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.

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

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

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Jeff Stevens]

On Sat, 2005-10-08 at 23:04 +0200, Frans Pop wrote:
> On Saturday 08 October 2005 22:07, Jeff Stevens wrote:
> > On Fri, 2005-10-07 at 16:26 +0200, Christoph Haas wrote:
> > "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?

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.

Thank you,

-Jeff


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Steve Langasek]

On Sat, Oct 08, 2005 at 11:04:09PM +0200, Frans Pop wrote:
> On Saturday 08 October 2005 22:07, Jeff Stevens wrote:
> > "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?

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,

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

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Stig Sandbeck Mathisen]

Gabor Gombas wrote:

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.



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.


--
Stig Sandbeck Mathisen


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Marco d'Itri]

On Oct 08, Frans Pop <[EMAIL PROTECTED]> wrote:

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

> 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

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Joey Hess]

Henrique de Moraes Holschuh wrote:
> 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[1] 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. :-/

-- 
see shy jo

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


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Joey Hess]

Klaus Ethgen wrote:
> 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 wrote:
> But why changing "localhost" to "localhost.localdomain" only for the
> reason that RedHat doing it? 

Christoph Haas wrote:
> "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.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Frans Pop]

On Saturday 08 October 2005 22:07, Jeff Stevens wrote:
> On Fri, 2005-10-07 at 16:26 +0200, Christoph Haas wrote:
> "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?


pgplxqRS4XKm0.pgp
Description: PGP signature

Re: localhost.localdomain

[Russ Allbery]

Jeff Stevens <[EMAIL PROTECTED]> writes:

> 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

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Jeff Stevens]

On Fri, 2005-10-07 at 16:26 +0200, Christoph Haas wrote:

> 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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Russ Allbery]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> 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 ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Bernd Eckenfels]

On Fri, Oct 07, 2005 at 02:04:44PM +0200, Gabor Gombas wrote:
> 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.

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Christoph Haas]

On Thu, Oct 06, 2005 at 07:44:42PM +0200, Pierre Machard wrote:
> Hi,
> 
> On Thu, Oct 06, 2005 at 12:24:12PM -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 06 Oct 2005, Pierre Machard wrote:
> > > 
> > > 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.
> 
> 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.

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Christoph Haas]

On Thu, Oct 06, 2005 at 12:37:47PM +0200, Marco d'Itri wrote:
> On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:
> 
> > .localdomain is such a peace of shit which only makes troubles. So
> 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. 

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 07, 2005 at 07:10:07AM +0200, Stig Sandbeck Mathisen wrote:

> 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 07, 2005 at 04:45:24AM +0200, Bernd Eckenfels wrote:

> 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 06, 2005 at 12:44:34PM -0700, Russ Allbery wrote:

> 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Oct 07, 2005 at 08:12:38AM +0200, Lionel Elie Mamane wrote:

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

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Lionel Elie Mamane]

On Thu, Oct 06, 2005 at 03:25:15PM +0200, Gabor Gombas wrote:
> On Thu, Oct 06, 2005 at 07:31:37AM -0500, Steve Greenland wrote:

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

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Stig Sandbeck Mathisen]

Pierre Machard <[EMAIL PROTECTED]> writes:

> 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


-- 
Stig Sandbeck Mathisen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Stig Sandbeck Mathisen]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> 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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> 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.

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Wesley J. Landaker]

On Thursday 06 October 2005 14:02, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Oct 2005, Joey Hess wrote:
> > 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.

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.

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

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpBYGTLWzRBg.pgp
Description: PGP signature

Re: localhost.localdomain

[Russ Allbery]

John Hasler <[EMAIL PROTECTED]> writes:
> Russ Allbery writes:

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

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 ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[John Hasler]

Stefano Zacchiroli writes:
> 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.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[John Hasler]

Russ Allbery writes:
> 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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Mark Brown]

On Thu, Oct 06, 2005 at 10:41:13PM +0200, Stefano Zacchiroli wrote:
> On Thu, Oct 06, 2005 at 09:38:03PM +0100, Mark Brown wrote:

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

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

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Mark Brown]

On Thu, Oct 06, 2005 at 05:02:55PM -0300, Henrique de Moraes Holschuh wrote:

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

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Stefano Zacchiroli]

On Thu, Oct 06, 2005 at 09:38:03PM +0100, Mark Brown wrote:
> 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 -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Mark Brown]

On Thu, Oct 06, 2005 at 03:17:53PM +0200, Stefano Zacchiroli wrote:

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

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Joey Hess wrote:
> 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.

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

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Pierre Machard wrote:
> The fact is that nobody complained about that... and my bug was

Now we are :)

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

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

> Please have a look at:
> http://lists.debian.org/debian-devel/2004/06/thrd2.html
> 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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Russ Allbery]

Marco d'Itri <[EMAIL PROTECTED]> writes:
> On Oct 06, Russ Allbery <[EMAIL PROTECTED]> wrote:

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

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 ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Joey Hess]

Henrique de Moraes Holschuh wrote:
> 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.

> 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 <[EMAIL PROTECTED]>  Fri, 19 Aug 2005 21:08:39 +0200

-- 
see shy jo


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> 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).

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

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Pierre Machard]

On Thu, Oct 06, 2005 at 03:23:45PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Oct 2005, Pierre Machard wrote:
> > 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.

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:
http://lists.debian.org/debian-devel/2004/06/thrd2.html
Subject: /etc/hosts: Two lines with the same IP address? by Thomas Hood

Cheers,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



signature.asc
Description: Digital signature

Re: localhost.localdomain

[Marco d'Itri]

On Oct 06, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

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

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Marco d'Itri]

On Oct 06, Russ Allbery <[EMAIL PROTECTED]> wrote:

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

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Pierre Machard wrote:
> 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).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 06, 2005 at 07:44:42PM +0200, Pierre Machard wrote:

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

> 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Russ Allbery]

Marco d'Itri <[EMAIL PROTECTED]> writes:
> On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:

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

> 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 ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Pierre Machard]

Hi,

On Thu, Oct 06, 2005 at 12:24:12PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Oct 2005, Pierre Machard wrote:
> > On Sat, Sep 24, 2005 at 08:33:25PM +0200, Bernd Eckenfels wrote:
> > > In article <[EMAIL PROTECTED]> you wrote:
> > > > "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.
> > 
> > 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.

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.

Cheers,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



signature.asc
Description: Digital signature

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, John Hasler wrote:
> 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).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Pierre Machard wrote:
> On Sat, Sep 24, 2005 at 08:33:25PM +0200, Bernd Eckenfels wrote:
> > In article <[EMAIL PROTECTED]> you wrote:
> > > "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.
> 
> 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).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[John Hasler]

I wrote:
> It wasn't changed.  "localhost.localdomain" was _added_.  "localhost" is
> still there.

Henrique de Moraes Holschuh writes:
> 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".

> 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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Steve Greenland]

On 06-Oct-05, 08:25 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote: 
> 
> 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.

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, John Hasler wrote:
> > But why changing "localhost" to "localhost.localdomain"...
> 
> 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.

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

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Gabor Gombas wrote:
> 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".

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

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

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Marco d'Itri wrote:
> On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:
> > .localdomain is such a peace of shit which only makes troubles. So
> 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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 06, 2005 at 07:31:37AM -0500, Steve Greenland wrote:

> 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

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[John Hasler]

Klaus Ethgen writes:
> Thats the reason why I give more helpfull information too in the first
> mail.

You haven't given enough information.

> But why changing "localhost" to "localhost.localdomain"...

It wasn't changed.  "localhost.localdomain" was _added_.  "localhost" is
still there.

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

> 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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Stefano Zacchiroli]

On Thu, Oct 06, 2005 at 01:43:29PM +0200, Klaus Ethgen wrote:
> 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 -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Steve Greenland]

On 06-Oct-05, 07:22 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote: 
> On Thu, Oct 06, 2005 at 02:04:44PM +0200, Klaus Ethgen wrote:
> 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

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Am Do den  6. Okt 2005 um 14:22 schrieb Wouter Verhelst:
> That's not helpful.

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

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

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

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ0Ub05+OKpjRpO3lAQJh1AgAibpUAgROgm+C+2IoqxztMaV4nuNU2y1N
pnNisnml740mjTOW3mNj2ow46lguEWytW/gGDq0AVrKA8+ULEO8Z5u/evpbHL1Ny
oSCizcMCXcRyk1FT1WOxzzisFoUZ9+g6WPCs8CPRZ6l6ld4KJH/5BdFT32k9R8F0
zh3cQCT7XVYq6fzynadM0ZwjJ9GpBiVz/eO/ULou/U2LtEDBWmNyh+Xd+PAzbaXm
0dIPTx+EQIW9G2THpx91LR/YjyRD6X/soTYgoQ9G9K2Oi5IvxfymrTfylBsWrHZF
02u2Sqmt4pBXnPCuY0DiCMfDOZIH0iNJfpuA69yPe3N/O+6OB3sU8w==
=GdtM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Wouter Verhelst]

On Thu, Oct 06, 2005 at 02:04:44PM +0200, Klaus Ethgen wrote:
> Hi Marco,
> 
> unfortunality your mail address is not valid so I answer you here.
> 
> Am Do den  6. Okt 2005 um 13:48 schrieb 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.

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.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Marco d'Itri]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:

> unfortunality your mail address is not valid so I answer you here.
My email address is perfectly valid, it's your system which is
misconfigured:

Oct  6 13:42:11 picard postfix/smtpd[4344]: NOQUEUE: reject: RCPT from 
static-195-068.catv.glattnet.ch[80.242.195.68]: 554 : Helo command 
rejected: unqualified HELO hostname; from=<[EMAIL PROTECTED]> to=<[EMAIL 
PROTECTED]> proto=ESMTP helo=

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

- -- 
ciao,
Marco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRRY1FGfw2OHuP7ERAl/5AJ919fsQCh6fdK1hJvqR51O/dUc03wCfYl4E
2oZhNKKt3X69uJQmd+bUvAE=
=tOXX
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Marco,

unfortunality your mail address is not valid so I answer you here.

Am Do den  6. Okt 2005 um 13:48 schrieb 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.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ0US3J+OKpjRpO3lAQKm/Qf8CvgeZAZ3wcOkaNZKxDCGcYqBqpc/8GlN
pzdtTE91XcVve4vMri2BIITJru/ch86D8lGWTpYB1AJRSaFnSX2VpMtoRYUFlwkJ
75fYuhy47iJI11+kLhYgtjMb3j69i1oM9tWMxoZmvudygnR13U7FoOXn0K2Sh0OY
7m5dC4KUPxz66+Yxw9TBEI8NflKa3Wa165jCV5juGhpZefzUsEwKZYXJsdhVyFW2
97KQ9Qsp+XgAwqQko8FDCQu/aXmNyWblPfbFzXMY2YlNZ0r+vJLNrVJoRA29JqVK
MgF+f0Y482unI8f04ntxuak7XZBbg+wIP7rhU7n1kBcmbJUhgpil/w==
=uOnq
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Marco d'Itri]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:

> Am Do den  6. Okt 2005 um 12:37 schrieb Marco d'Itri:
> > > .localdomain is such a peace of shit which only makes troubles. So
> > Please explain which troubles.
> 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?

- -- 
ciao,
Marco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRQ8iFGfw2OHuP7ERApM3AKCCGy0jpyKaCHimIfTwXQtOiXnwPgCfU0yn
lSNqR02tM/ZFhRWkFTln6wk=
=1GG+
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Marco,

Am Do den  6. Okt 2005 um 12:37 schrieb Marco d'Itri:
> > .localdomain is such a peace of shit which only makes troubles. So
> 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.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ0UN4Z+OKpjRpO3lAQKwpQf+P0oEJyklcLU+htTuTXg/9KSbqxQl3CtN
1cbcwWacwmhZsHBfsMSBCEheKUFEXl2ZYsG1xOeOQabCk56MdBgSB8OGETBoZI+y
SKlIpAlLpfW+2GzHBHEDukGksk9b2p5Hzk9uNkAI8guHsAHk65loAg99y0w5LmoH
mdXlbgr9vKfYNyiyMbsrpZu8YDitmO9GQkGigm18gEFCdUWHm20G7yUbXH+XIFZ2
VURIHR8uu3kaMzJOneYh0PdxO22eKvNUEgyFWvowDjPodbzLdU6ddl63EIipB4wV
Qygamc+wavijiGHrcvK5tzQ2yAeoddNNcIk48wfpXfoRiuJNdMD4zA==
=oLvm
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Marco d'Itri]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:

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

- -- 
ciao,
Marco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRP57FGfw2OHuP7ERAkZRAJ9DqA/m17uX1aH9bvapR6JVWDnfYgCghyYs
j7aAgYW87Caonmw/uI+0LyI=
=rn9l
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Am Do den  6. Okt 2005 um  9:10 schrieb 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.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ0TXpJ+OKpjRpO3lAQKXDQgAlbwriA493n0nz2bokES+vU5/k9rwvHPI
68xXHcidn7n0iidB1vDpcRnwA/NrSjZ4Wym6IiQTT2tGbDv5Ot3bv+6pmNvWviGf
GblGGbXwNpvjMhyPORLS9Mg8yqjxFukzKdBlnju5B+JnlqiT0bxiTx67h+wnInZy
62jNLnnXiG7AMPW3hQkTGObzu6NZBOVBA2djHfo7ScSsdEuPPoDORFA+LCrf83CE
/VS9EFoqk4zpI4UPl1CaXmX3C10W6L6nkddgGd0NyqLjKMJ+LpmARVcxnk+uCqEy
5a3YZyWetY0nm/4CEk03BlR4RJP02pyP0t9KiBcUmsDVLsfbYt5hNw==
=nUuy
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Pierre Machard]

On Sat, Sep 24, 2005 at 08:33:25PM +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > "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.

IIRC The main reason was described in #247734

Cheers,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



signature.asc
Description: Digital signature

Re: localhost.localdomain

[Bob Proulx]

Christoph Haas wrote:
> Actually I second that. I still haven't seen a reason to use it since I
> don't understand the "historical reasons".

I have always wondered about the historical reasons too.  Because it
never made sense to me either.

> On my servers I have always removed the "localhost.localdomain"
> entry and never encountered any problems.

I have always removed the .localdomain part too as part of a normal
configuration of the machine after installation.  In fact I automate
it with scripts so that it consistently happens to my servers when
they are installed.

> Perhaps we finally get to the conclusion that it doesn't belong there.
> :)

Let's hope so.

Bob


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Russ Allbery]

Christoph Haas <[EMAIL PROTECTED]> writes:

> That's exactly the explanation what I was looking for. I incorrectly
> assumed that more than just MySQL is affected. But it appears like other
> services do not care about the reverse resolution of 127.0.0.1.

I've never seen the dumb localhost.localdomain thing help either, though.
INN isn't affected by default but is affected in a few misconfigurations
that are exacerbated by this.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Christoph Haas]

On Sat, Sep 24, 2005 at 08:33:25PM +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > "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.

Actually I second that. I still haven't seen a reason to use it since I
don't understand the "historical reasons". On my servers I have always
removed the "localhost.localdomain" entry and never encountered any
problems.

Perhaps we finally get to the conclusion that it doesn't belong there.
:)

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Michal Politowski]

On Sat, 24 Sep 2005 19:35:09 +0200, Gabor Gombas wrote:
[...]
> "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.

Maybe it's relatively safe, but I'd say that it's still safer to use
the localhost TLD, which is explicitely reserved in RFC 2606 (BCP 32)
for the purpose of being mapped to the loopback address.

-- 
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Roger Leigh]

Christoph Haas <[EMAIL PROTECTED]> writes:

> That's exactly the explanation what I was looking for. I incorrectly
> assumed that more than just MySQL is affected. But it appears like other
> services do not care about the reverse resolution of 127.0.0.1.

This is also the case for CUPS, but is now fixed upstream.  See

http://www.cups.org/str.php?L989+P0+S1+C0+I0+E0+Qrleigh.debian

The sad thing is, this is special cased primarily because of broken
/etc/hosts files preventing reverse name lookups...


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> "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.

Gruss
Bernd
y


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Christoph Haas]

On Sat, Sep 24, 2005 at 07:35:09PM +0200, Gabor Gombas wrote:
> On Fri, Sep 23, 2005 at 08:01:05PM +0200, Christoph Haas wrote:
> 
> > It appears like MySQL does that. It seems to check the IP address of the
> > connecting client to find the permissions in it's internal `users`
> > table. So it sees "127.0.0.1" and looks up "localhost.localdomain" which
> > it cannot find since it expects "localhost".
> 
> Well, I don't think it's MySQL that expects "localhost", it's more like
> you have added users in the form of "[EMAIL PROTECTED]" instead of
> "[EMAIL PROTECTED]". These two forms are _not_ the same as far
> as MySQL is concerned.
> 
> 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.

That's exactly the explanation what I was looking for. I incorrectly
assumed that more than just MySQL is affected. But it appears like other
services do not care about the reverse resolution of 127.0.0.1.

Thank you for your explanation and the references. I'm maintaining a
tutorial for setting up mail servers on Debian. And I wanted to tell the
readers the correct way to handle these MySQL authorization problems.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Sep 23, 2005 at 08:01:05PM +0200, Christoph Haas wrote:

> It appears like MySQL does that. It seems to check the IP address of the
> connecting client to find the permissions in it's internal `users`
> table. So it sees "127.0.0.1" and looks up "localhost.localdomain" which
> it cannot find since it expects "localhost".

Well, I don't think it's MySQL that expects "localhost", it's more like
you have added users in the form of "[EMAIL PROTECTED]" instead of
"[EMAIL PROTECTED]". These two forms are _not_ the same as far
as MySQL is concerned.

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.

> > The latter is completely wrong. First, there is no such thing as
> > "myrealdomain". A machine may have multiple network interfaces, every
> > interface may have multiple addresses, every address resolving to a
> > different domain. You cannot even order them in any sensible way.
> 
> Then you can hoepfully tell why "localhost.localdomain" is right. I don't
> see any references to "localdomain" in an RFC. So "localdomain" is no
> real domain either.

"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. On the other hand at least RFC1537 describes
"localhost.realdomain" as problematic and to be avoided (RFC1537 is
about DNS server configuration errors but the reason is valid for
/etc/hosts as well).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Olaf van der Spek]

On 9/23/05, Christoph Haas <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 23, 2005 at 08:07:54PM +0200, Olaf van der Spek wrote:
> > On 9/23/05, Christoph Haas <[EMAIL PROTECTED]> wrote:
> > > It appears like MySQL does that. It seems to check the IP address of the
> > > connecting client to find the permissions in it's internal `users`
> > > table. So it sees "127.0.0.1" and looks up "localhost.localdomain" which
> > > it cannot find since it expects "localhost".
> >
> > Put % in the host field and base authentication on passwords.
>
> http://dev.mysql.com/doc/mysql/en/connection-access.html reads:
>
> ---snip-
> # A Host value may be a hostname or an IP number, or 'localhost' to
>indicate the local host.
> # You can use the wildcard characters '%' and '_' in Host column values.
>These have the same meaning as for pattern-matching operations 
> performed
>with the LIKE operator. For example, a Host value of '%' matches any
>hostname, whereas a value of '%.mysql.com' matches any host in the
>mysql.com domain.
> ---snap-
>
> So 'localhost' means the current host and '%' is a wildcard for other
> hosts.

Eh? Why would % not match localhost?

> IIRC MySQL will not accept '%' if I connect from the same machine
> (unless I explicitly connect to an IP on an interface other than 'lo').

Re: localhost.localdomain

[Christoph Haas]

On Fri, Sep 23, 2005 at 08:07:54PM +0200, Olaf van der Spek wrote:
> On 9/23/05, Christoph Haas <[EMAIL PROTECTED]> wrote:
> > It appears like MySQL does that. It seems to check the IP address of the
> > connecting client to find the permissions in it's internal `users`
> > table. So it sees "127.0.0.1" and looks up "localhost.localdomain" which
> > it cannot find since it expects "localhost".
> 
> Put % in the host field and base authentication on passwords.

http://dev.mysql.com/doc/mysql/en/connection-access.html reads:

---snip-
# A Host value may be a hostname or an IP number, or 'localhost' to
indicate the local host.
# You can use the wildcard characters ‘%’ and ‘_’ in Host column values.
These have the same meaning as for pattern-matching operations performed
with the LIKE operator. For example, a Host value of '%' matches any
hostname, whereas a value of '%.mysql.com' matches any host in the
mysql.com domain. 
---snap-

So 'localhost' means the current host and '%' is a wildcard for other
hosts. IIRC MySQL will not accept '%' if I connect from the same machine
(unless I explicitly connect to an IP on an interface other than 'lo').

And I still wonder where .localdomain comes from. :)

 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Olaf van der Spek]

On 9/23/05, Christoph Haas <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 23, 2005 at 04:59:52PM +0200, Gabor Gombas wrote:
> > On Fri, Sep 23, 2005 at 02:47:58PM +0200, Christoph Haas wrote:
> > > ..warning: connect to mysql server foobar: Access denied for user
> > > 'whoever'@'localhost.localdomain' (using password: YES)
> >
> > Well, I had seen several machines having "127.0.0.1
> > localhost.localdomain localhost" in /etc/hosts and running MySQL without
> > problems, so you could be a bit more specific about how do you get this
> > error.
>
> An example is running Postfix with MySQL lookups.
>
> > > because it expected to resolve 127.0.0.1 to the name "localhost".
> >
> > Expected by whom?
>
> It appears like MySQL does that. It seems to check the IP address of the
> connecting client to find the permissions in it's internal `users`
> table. So it sees "127.0.0.1" and looks up "localhost.localdomain" which
> it cannot find since it expects "localhost".

Put % in the host field and base authentication on passwords.

Re: localhost.localdomain

[Christoph Haas]

On Fri, Sep 23, 2005 at 04:59:52PM +0200, Gabor Gombas wrote:
> On Fri, Sep 23, 2005 at 02:47:58PM +0200, Christoph Haas wrote:
> > ..warning: connect to mysql server foobar: Access denied for user
> > 'whoever'@'localhost.localdomain' (using password: YES)
> 
> Well, I had seen several machines having "127.0.0.1
> localhost.localdomain localhost" in /etc/hosts and running MySQL without
> problems, so you could be a bit more specific about how do you get this
> error.

An example is running Postfix with MySQL lookups.

> > because it expected to resolve 127.0.0.1 to the name "localhost".
> 
> Expected by whom?

It appears like MySQL does that. It seems to check the IP address of the
connecting client to find the permissions in it's internal `users`
table. So it sees "127.0.0.1" and looks up "localhost.localdomain" which
it cannot find since it expects "localhost".

> > Shouldn't it just be "127.0.0.1 localhost"? Or at most 
> > "127.0.0.1 localhost localhost.$myrealdomain"?
> 
> The latter is completely wrong. First, there is no such thing as
> "myrealdomain". A machine may have multiple network interfaces, every
> interface may have multiple addresses, every address resolving to a
> different domain. You cannot even order them in any sensible way.

Then you can hoepfully tell why "localhost.localdomain" is right. I don't
see any references to "localdomain" in an RFC. So "localdomain" is no
real domain either.

> > Or should it rather be replaced during the installer's network base
> > configuration or the `base-config`? Or is the user supposed to change
> > "localdomain" to the real domain after the installation? Few people
> > actually seem to do that. :)
> 
> They don't do that because that's wrong.

There is probably a reason why "localhost.localdomain" is listed there.
But if you claim my assumption is completely wrong you may want to give
pointers why "localdomain" is right - and what it's used for.

 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: localhost.localdomain

[Gabor Gombas]

On Fri, Sep 23, 2005 at 02:47:58PM +0200, Christoph Haas wrote:

> ..warning: connect to mysql server foobar: Access denied for user
> 'whoever'@'localhost.localdomain' (using password: YES)

Well, I had seen several machines having "127.0.0.1
localhost.localdomain localhost" in /etc/hosts and running MySQL without
problems, so you could be a bit more specific about how do you get this
error.

> because it expected to resolve 127.0.0.1 to the name "localhost".

Expected by whom?

> Shouldn't it just be "127.0.0.1 localhost"? Or at most 
> "127.0.0.1 localhost localhost.$myrealdomain"?

The latter is completely wrong. First, there is no such thing as
"myrealdomain". A machine may have multiple network interfaces, every
interface may have multiple addresses, every address resolving to a
different domain. You cannot even order them in any sensible way.

> Or should it rather be replaced during the installer's network base
> configuration or the `base-config`? Or is the user supposed to change
> "localdomain" to the real domain after the installation? Few people
> actually seem to do that. :)

They don't do that because that's wrong.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]