Bug 250702 - not all the addresses associated with listenhost are bound to listen sockets
Summary: not all the addresses associated with listenhost are bound to listen sockets
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.0.4
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 240316 FDS1.1.0
TreeView+ depends on / blocked
 
Reported: 2007-08-03 01:19 UTC by Noriko Hosoi
Modified: 2015-12-07 16:56 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:56:11 UTC
Embargoed:


Attachments (Terms of Use)
cvs diff message (36.12 KB, patch)
2007-08-03 01:37 UTC, Noriko Hosoi
no flags Details | Diff
listenhost test cases and resuts (2.51 KB, text/plain)
2007-08-03 01:56 UTC, Noriko Hosoi
no flags Details
revised diffs (36.81 KB, patch)
2007-08-03 22:13 UTC, Noriko Hosoi
no flags Details | Diff
cvs commit message (959 bytes, text/plain)
2007-08-03 22:15 UTC, Noriko Hosoi
no flags Details

Description Noriko Hosoi 2007-08-03 01:19:29 UTC
Description of problem:
When listenhost is set, the host could be associated with multiple net addresses
in the IPv6 enabled environment. Directory Server calls PR_GetAddrInfoByName
(which internally calls getaddrinfo) to get the addresses from the listenhost
name, which could be more than one.  The server should listen on all the sockets 
bound to the addresses returned by PR_GetAddrInfoByName.

Comment 1 Noriko Hosoi 2007-08-03 01:37:14 UTC
Created attachment 160570 [details]
cvs diff message

Files:
 ldapserver/ldap/servers/slapd/fe.h
			       slap.h
			       daemon.c
			       main.c
Description:
listen socket used to be prepared one for the ordinary port, one for ssl, and
one for UNIX socket.  The first 4 slots of the connection table were used for
the listen sockets (one out of 4 is SIGNAL PIPE).  We need to extend the
hardcoded slot to dynamic depending upon the returned addresses from
PR_GetAddrInfoByName.

Comment 2 Noriko Hosoi 2007-08-03 01:56:28 UTC
Created attachment 160571 [details]
listenhost test cases and resuts

Comment 3 Nathan Kinder 2007-08-03 04:45:10 UTC
The changes look good in general.  My only questions are around the ldapi code.

There are parts of the code that look like they deal with a list of ldapi
sockets,  but I was under the impression that the server only listens on one
socket for ldapi.  Are there any tests we can try to verify that ldapi works
properly with these changes?

Comment 4 Pete Rowley 2007-08-03 17:04:48 UTC
Yes, ldapi has only one socket, though listening on more than one might be
useful in some cases. I guess there is some value in having all the sockets work
the same way in the code in any case. To test, compile in ldapi, configure it,
start server, fire a search at it through ldapi. I think that would be
sufficient to be sure it was not broken by these changes since they all involve
actually establishing the socket. 

Comment 5 Noriko Hosoi 2007-08-03 17:05:58 UTC
(In reply to comment #3)
> The changes look good in general.  My only questions are around the ldapi code.
> 
> There are parts of the code that look like they deal with a list of ldapi
> sockets,  but I was under the impression that the server only listens on one
> socket for ldapi.  Are there any tests we can try to verify that ldapi works
> properly with these changes?

Your questions are valid and shared with me. :)  DS does listen on one socket
for LDAPI.  I applied the same change to LDAPI only because they share the same
function to open the socket. I could break the function -- createprlistensocket
-- into 2: one for LDAPI and another is for TCP, which could be easier to
maintain.  Also, I can resurrect the macro the FDS_I_UNIX and assign 1 and TCP
socket always could start from 2 in the fd list in the connection-table.  That
way we don't have to put the PR_Listen for the LDAPI socket in the loop.  If
they sound reasonable, I'm making the changes and run the test again.


Comment 6 Noriko Hosoi 2007-08-03 17:08:07 UTC
(In reply to comment #4)
> Yes, ldapi has only one socket, though listening on more than one might be
> useful in some cases. I guess there is some value in having all the sockets work
> the same way in the code in any case. To test, compile in ldapi, configure it,
> start server, fire a search at it through ldapi. I think that would be
> sufficient to be sure it was not broken by these changes since they all involve
> actually establishing the socket. 

Oh, okay.  There's some possibility it could listen on more than one socket... 
Then, I'll leave it as is...  Thanks, Pete!

Comment 7 Pete Rowley 2007-08-03 17:31:28 UTC
Well, listening on one socket is not something it can do right now, but I can
imagine that at some point it might be added. In any case, having all the
sockets work mostly the same way and therefore have similar looking code for
each is quite valuable I think.

Comment 8 Noriko Hosoi 2007-08-03 19:09:07 UTC
Sweet.  It works!!

$ ldapsearch -H ldapi://%2fvar%2frun%2ffedora-ds%2fslapd-ID.socket -x -b "" -s
base "(objectclass=*)" dn
# extended LDIF
#
# LDAPv3
# base <> with scope base
# filter: (objectclass=*)
# requesting: dn
#

#
dn:

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


Comment 9 Rich Megginson 2007-08-03 21:08:51 UTC
Ok.  It looks as though there are a couple of places where we do not have #ifdef
ENABLE_LDAPI around some ldapi code - can you add those?  Thanks.

Comment 10 Noriko Hosoi 2007-08-03 22:13:11 UTC
Created attachment 160674 [details]
revised diffs

Thank you for reviewing the changes, Rich.  I'm attaching the revised diffs.

Comment 11 Noriko Hosoi 2007-08-03 22:15:45 UTC
Created attachment 160675 [details]
cvs commit message

Checked in into HEAD.

Comment 14 Michael Gregg 2007-11-19 19:56:18 UTC
verified fixed aginst:
1195501819 redhat-ds-base-8.0.0-11.el5dsrv Mon Nov 19 2007 
1195501821 redhat-ds-admin-8.0.0-1.15.el5dsrv Mon Nov 19 2007 
1195501823 redhat-admin-console-8.0.0-9.el5dsrv Mon Nov 19 2007 
1195501823 redhat-ds-console-8.0.0-8.el5dsrv Mon Nov 19 2007 


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