Bug 97687 - Hostname resolution with LDAP works only partially
Summary: Hostname resolution with LDAP works only partially
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-06-19 12:43 UTC by Olivier L'Heureux
Modified: 2016-11-24 14:54 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-11-05 18:48:30 UTC
Embargoed:


Attachments (Terms of Use)

Description Olivier L'Heureux 2003-06-19 12:43:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529

Description of problem:
On RedHat 7.3, 8 and 9, adding "ldap" to the "hosts" DB in "/etc/nsswitch.conf"
seems to work _partially_. It's OK for "ping" but not OK for many other apps
like "telnet", "ssh".
Its OK for "python1" but not OK for "python2". I think it comes from the
libc call: "ping" and "python1" use "gethostbyname()", while "telnet" and
"python2" use "getaddrinfo()". An interesting case: "getent hosts" lists
the hosts defined in the LDAP DB, but a match like "getent hosts <hostname>"
returns nothing if <hostname> is defined in LDAP, and does return
an answer if <hostname> is defined in "/etc/hosts".


Version-Release number of selected component (if applicable):
glibc-2.3.2-4.80.6

How reproducible:
Always

Steps to Reproduce:
1. Configure the hostname resolution to use LDAP. (Put a line
   "hosts: files dns ldap" in "/etc/nsswitch.conf")
2. Configure two hosts, one beeing resolved with LDAP, the other
   with the "/etc/hosts" file. (Put a line
   "192.168.100.26 ldap1 bugzilla" in "/etc/hosts". Put a record
   for "rx13" in the "ou=Hosts,dc=???,dc=com" LDAP DB.
3. Try to ping and telnet to "bugzilla" and "rx13":
   |> ping bugzilla
   |> telnet bugzilla
   |> ping rx13
   |> telnet rx13
   Output:
   |> [olheureu@wks13 olheureu]$ ping rx11
   |> PING rx11 (192.168.100.201) from 192.168.100.23 : 56(84) bytes    of data.
   |> 64 bytes from rx11 (192.168.100.201): icmp_seq=1 ttl=255    time=2.56 ms
   |> 64 bytes from rx11 (192.168.100.201): icmp_seq=2 ttl=255 time=1.85 ms
   |> 
   |> --- rx11 ping statistics ---
   |> 2 packets transmitted, 2 received, 0% loss, time 1010ms
   |> rtt min/avg/max/mdev = 1.856/2.212/2.569/0.359 ms
   |> [olheureu@wks13 olheureu]$ telnet rx11
   |> telnet: rx11: Name or service not known
   |> rx11: Unknown host
   |> [olheureu@wks13 olheureu]$



Actual Results:  With "bugzilla", ping and telnet find the host. With "rx13", ping
find the host but telnet doesn't.

Expected Results:  "rx13" beeing found by telnet as it is by ping.

Additional info:

This bug may be correlated with bug 54646.
Because Posix says "gethostbyname()" is obsolete and should be
replaced by "getaddrinfo()", I guess more and more apps will
use "getaddrinfo()" in the future.

Comment 1 Ulrich Drepper 2003-10-06 09:28:27 UTC
I tried to reproduce the problem with a RHL9 installation (the oldest I have in
the network with the LDAP server) but couldn't get nss_ldap to work.  Don't know
what up with it.

But the RHEL3 and Fedora Core test 2 code works fine.  With or without
getaddrinfo.  If you have FC test2, try

   getent ahosts <HOST>

where <HOST> is the name only available through LDAP.

I do not think spending much time on this for back releases is worth it.  We
haven't received any further complaints which might indicate that this
functionality actually works.  In fact, this is what I expect since getaddrinfo
in those releases simply calls the gethostbyname2 function.

If you want to investigate old release please run

   strace -o /tmp/SOMETMPFILE getent hosts <HOST>

and attach the /TMP/SOMETMPFILE to this bug.  Then use a program which calls
getaddrinfo (ideally, write a little program yourself) and run it with

  ltrace PROGRAM

and then

  strace -o /tmp/ANOTHERFILE PROGRAM


Comment 2 Ulrich Drepper 2003-11-05 18:48:30 UTC
No response in a month.  I don't see a bug.  Closing now.


Note You need to log in before you can comment on or make changes to this bug.