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]) http://www.eyrie.org/~eagle/


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

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

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

[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

[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

[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

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

[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

[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] xmpp:[EMAIL PROTECTED]
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgplsRX5lyUm5.pgp
Description: PGP signature

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

[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

[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

[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

[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 alias another alias ...
There is a long historical precedent for listing localhost first,
followed by other aliases.  This results in the resolver properly
returning localhost when resolving 127.0.0.1.

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

Thanks!

-Jeff  




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

[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

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

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]) http://www.eyrie.org/~eagle/


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

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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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]) http://www.eyrie.org/~eagle/


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

[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

[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

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:

 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

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:

 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 ikki: Helo command 
rejected: unqualified HELO hostname; from=[EMAIL PROTECTED] to=[EMAIL 
PROTECTED] proto=ESMTP helo=ikki

 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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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]) http://www.eyrie.org/~eagle/


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

[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

[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

[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

[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

[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

[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

[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]) http://www.eyrie.org/~eagle/


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

[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

[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

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

[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

[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

[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

[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]) http://www.eyrie.org/~eagle/


-- 
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] xmpp:[EMAIL PROTECTED]
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpBYGTLWzRBg.pgp
Description: PGP signature

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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]) http://www.eyrie.org/~eagle/


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

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

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