[Bug libc/4980] gethostbyname() etc break for /etc/hosts with both ::1 and 127.0.0.1 localhost entries
tpeland at tkukoulu dot fi
sourceware-bugzilla@sourceware.org
Tue Apr 15 06:14:00 GMT 2008
------- Additional Comments From tpeland at tkukoulu dot fi 2008-04-15 06:13 -------
Created an attachment (id=2693)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=2693&action=view)
getaddrinfo fix for 2.6.1/2.7
>Of course it gains something, otherwise it would not have been added. And
>programs which don't handle multiple addresses are simply broken and must be
>fixed anyway. Stop defending broken code.
Seems you haven't cheked the code lately. I'll give you real life example
explaining why the mistake of thinking that all hostnames that resolve to ::1
also resolve to 127.0.0.1 is causing big problems to users.
I have ldap hosts defined as:
localldap.example.org ldap1.example.org ldap2.example.org
As I'm using TLS I must use hostname instead of ip-number.
File /etc/hosts contains following
::1 localhost localldap.example.org
127.0.0.1 localhost
As ldap services contain important data it is protected by internal
firewall. The firewall accepts connection to ldap port from ldap-master
and ::1. The reason for using localhost with ldap is that ldap is
started as early as possible in boot to provide user information. It is
started before any network other then localhost.
Now as glibc-implementation of getaddrinfo() was changed the first
connection is done to 127.0.0.1. Firewall blocks this connection and
after timeout of 15 seconds the connection is tried to ::1. At that
time it succeeds.
As you can see the program definately can support multiple addresses
form getaddrinfo() and can hardly be considered buggy.
As OSS camp often says: "talk is cheep, show the code". I have added a fix that
I have verified to work under 2.6.1. The code in question is identical in 2.7.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4980
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
More information about the Glibc-bugs
mailing list