Bug 250702

Summary: not all the addresses associated with listenhost are bound to listen sockets
Product: [Retired] 389 Reporter: Noriko Hosoi <nhosoi>
Component: Directory ServerAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: low Docs Contact:
Priority: low    
Version: 1.0.4CC: jgalipea
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:56:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 240316, 427409    
Attachments:
Description Flags
cvs diff message
none
listenhost test cases and resuts
none
revised diffs
none
cvs commit message none

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