2015-11-28 3:25 GMT-02:00 Crystal Wood :
> ;)
You shutdow use Bottom-posting [0]. :-)
0 - http://idallen.com/topposting.html
Albino
;)
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
> practi
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, emai
pends 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 Ethgen
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
>
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 m
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 FQ
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 prob
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-i
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 l
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. MySQ
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
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]
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 fina
lication 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
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. Landa
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 app
[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
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
> 'lo
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
it
[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
o
ince 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
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
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".
> Y
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 th
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 gethos
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 h
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
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 l
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
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
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 pro
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, em
gt;
> > 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
ted 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
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
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 reli
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
> globall
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
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
>&
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 s
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
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 syste
enrique 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 arbit
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 gl
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 UNSUBSCRI
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 wit
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 th
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
&g
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
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 ev
here 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 "twer
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 w
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
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 no
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 s
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
>
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 t
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 th
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
body 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
looku
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 I
or
> > > .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 stuf
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 c
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 pro
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.
Th
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&quo
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
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
, 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 abso
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 '
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" w
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'
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
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?
g. 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 unexp
> 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 SIGNATU
are 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
-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 remembe
oblemes 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&qu
-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)
iD8DBQFDRP57FGfw
-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
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
ers 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 serv
27;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 PROTE
> 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
remov
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 localh
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
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
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 a
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.l
> > 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
ers`
> > 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
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
> > >
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)
>
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.localdoma
Howdy...
is there a reason that the default entry for 127.0.0.1 in /etc/hosts
reads "127.0.0.1 localhost.localdomain localhost"? This has hit me
several times and is especially problematic when accessing a MySQL
database locally. MySQL quickly complains like this:
..warning: connec
98 matches
Mail list logo
