Bug 77538

Hmm, it works for me.

for example, I added 172.16.2.154    www.hihihi.org in /etc/hosts.
And it works as expected.

It only works for me when using Mozilla and Galeon. Konqueror times out.    
My /etc/hosts file:    
127.0.0.1       localhost.localdomain   localhost noname    
192.168.1.5     eric.thewunders.org     eric    upstairs    
192.168.1.2     www.thewunders.org thewunders.org downstairs.thewunders.org downstairs    
www.sufathersclub.org    
    
www.thewunders.org, thewunders.org, www.sufathersclub.org all time out with konqueror. They all    
work in Mozilla. downstairs.thewunders.org works in konqueror, as does localhost.   
    
Potential problems I see with your test:    
If the Domain name you used doesn't resolve, the fall back could be the /etc/hosts file, so you get   
a name resolution failure via DNS and konqueror then sources /etc/hosts. My domain    
names, www.thewunders.org and sufathersclub.org are resolvable via DNS, but are not loadable    
because of my firewall (a Freesco router).    
  
Did you disconnect from the Internet before testing? 

OK. I did your test this time, I added 
192.168.1.2 www.hihihi.org
to my /etc/hosts file, and it resolved fine, my local home page displayed. I
then added 
192.168.1.2 www.excite.com
and the *real* excite page loaded. So you *must* test this with a *resolvable*,
*real* domain name.

Mozilla behaves properly.

I will be updating KDE to 3.0.5 shortly, using the RPMs found at kde.org and
will post an update.

i confirm this problem

I can also confirm that Konqueror does not work well 
with /etc/hosts. 
 
I have in my /etc/hosts: 
 
	10.25.150.2	www.isthe.com www.dmz.isthe.com www 
 
The host www.isthe.com, via DNS, resolves to 64.81.78.68.  My RH8.0 
system is behind a firewall where 64.81.78.68 is not accessible. 
The host www.dmz.isthe.com is a private name for the web server 
and is NOT resolvable via DNS.  It only exists in my /etc/hosts 
as a private-10 IP address. 
 
In /etc/nsswitch.conf I have: 
 
	hosts:      files dns 
 
So resolving should first check /etc/hosts and then with DNS. 
 
Now I am able to access with Konqueror: 
 
	http://10.25.150.2/ 
	http://www.dmz.isthe.com/ 
 
Both of those URLs resolve to port 80 on 10.25.150.2. 
However when I try to access: 
 
	http://www.isthe.com/ 
 
Konqueror fails to find the web server.  A tcpdump of eth0 shows 
that Konqueror is attempting to use the DNS IP address of 64.81.78.69 
instead of 10.20.150.2. 
 
NOTE: Both Mozilla and Netscape correctly resolve www.isthe.com 
via the /etc/hosts file.  Prior to my upgrade to RH8.0, I was using 
RH7.3.   Konqueror correctly used /etc/hosts prior to the RH8.0 
upgrade. 
 
This is really a problem for me as I depend on such private hostnames 
resolving via /etc/hosts. 
 

p.s. In my previous comment when I said: 
 
	... 
	instead of 10.20.150.2. 
 
I should have said: 
 
	... 
	instead of 10.25.150.2. 
 
Sorry for the typo. 

This is the same as bug 76543.  Seems pretty serious to me and is actually 
keeping me from deploying 8.0 on lots of machines.  From my experience the only 
thing that isn't affected by this is ping.  Telnet, ssh, ftp, etc. all break.

I can confirm that many apps such as telnet, ssh, ftp, etc. all break.   
(Perhaps there is a bug in the resolver library that is ignoring or   
not correctly processing hosts entry in nsswitch.conf?)   
   
For what it is worth, we have halted testing on RH8.0 because we   
cannot move forward on RH7.3 upgrades on production systems because   
of this general problem.  I hope a general fix (that covers the many  
other apps) is in the works! 
 
Please re-prioritize this bug from Normal to High. 

Just adding some additional information that might help solving the problem. I have 
talked a lot with Tim Wunder (the original reporter) and he's done quite a bit of testing. 
 
First of all, all the programs that have been mentioned here as not working use 
getaddrinfo(3) as its resolution function. The other ones that are working use the 
conventional gethostbyname(3) calls, even those IPv6-enabled such as Mozilla (uses 
gethostbyname2(3)). 
 
A small test test program using getaddrinfo(3) shows the very same problem. I can 
provide this test program. 
 
I wrote another test program. I made it call directly the _nss_files_gethostbyname2_r 
function inside /lib/libnss_files.so.2, which is the actual function that reads /etc/hosts 
and returns an address. It did succeed in finding the proper address. 
 
If you call gethostbyname2_r(3), which is what getaddrinfo(3) uses (see 
sysdeps/posix/getaddrinfo.c, macro gethosts), the correct addresses are found as 
well. 
 
My current conclusion is that somewhere, somehow, getaddrinfo(3) chose to use 
another address than the one gethostbyname2_r returned. That might be connected 
to the fact that gethostbyname2_r is called twice: once for IPv6 and once for IPv4. 
 
In time, I should note that I'm using glibc 2.3.1 on a Conectiva system and it does not 
appear to be affected. 
 
Bug# 76543 is certainly related. 

Oh, I've just remembered. 
 
An strace of the getaddrinfo(3) test program showed that all the NSS libraries were 
called twice (files, nis, nisplus, dns). The first must be the IPv6 query, which has 
probably failed on all domains. The second one, the IPv4 query, should have stopped 
in the files NSS, as it does in my system, but it doesn't. The other NSS libraries are 
searched until the dns one returns a success. 

Changing priority to High because of additional information posted that may
prove beneficial in resolving the bug.

Just today I tried installing glibc-, glibc-common-, and glibc-devel-2.3.1-38
from rawhide on a machine with a mainly-fresh RH 8.0 install.  I was amazed it
worked with a simple 'rpm -U'.  However, it doesn't seem to have fixed the
problem reported here;  my nsswitch.conf like others' searches NIS first, then
files, then DNS, but 'nslookup' failed to find an entry in NIS.  An HP-UX system
in the same NIS domain and with the same policy in its nsswitch.conf found the
NIS entry.

This also happens in a recent install of Debian (3.0) here on my laptop.  From 
what I am seeing, this is a glibc bug.  I also read that a workaround (sort of) 
for it, is whatever you want to put into /etc/hosts, do it like this:

# /etc/hosts
192.168.0.1    foo.bar.com
192.168.0.1    foo.bar.com.

The first line takes care of things like ping, and the second takes care of 
telnet/ssh/etc.  Is this something to do with gethostbyname vs. getaddrinfo ?

So I guess any/ALL distributions that use one of these versions of glibc is 
affected.  

Again, it looks like this only started in RH 8.0.  <= 7.3 seems to work fine 
for me.

FWIW, if you have multiple hosts resolving to a single IP, you can enter thusly:
# /etc/hosts
192.168.0.1    foo.bar.com foo1.bar1.com foo2.bar2.com
192.168.0.1    foo.bar.com. foo1.bar1.com. foo2.bar2.com.

Many, many thanks to brandon for the workaround.

See also bug 84105: 
 
	excessive IPv6 lookups done even when /etc/hosts resolves to IPv4 
 
The excess . hack-a-round is another symptom of the more general 
glibc resolver problem.  As noted in the bug 84105, the ignoring 
of /etc/resolv.conf and the excessive IPv6 lookups can cause 
serious delays.  In one case a full minute is wasted as 12 DNS 
lookups (between 2 DNS servers that are unreachable) takes place. 
 
I hope people don't think that this excess . hack-a-round is a fix! 

It appears that this ignoring /etc/hosts problem has been resolved in
rawhide. See:

    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84105#c6

for details.

ok, upgrade glibc-2.3.1-54 or later fix this problem

A clarification on: 
 
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84105#c6 
 
You should NOT install those RPMs on a production system.  Rawhide 
is raw bits.  Those RPMs were only in relationship to various DNS 
issues.  Those rpms have a number of non-DNS related problems. 
For example, they cause the rpm command to dump core.  They did, 
however,  resolve the DNS issues, with the possible exception of 
excessive IPv6 lookups.