Red Hat Bugzilla – Bug 250702
not all the addresses associated with listenhost are bound to listen sockets
Last modified: 2015-12-07 11:56:11 EST
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.
Created attachment 160570 [details]
cvs diff message
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
Created attachment 160571 [details]
listenhost test cases and resuts
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?
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.
(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.
(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!
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.
Sweet. It works!!
$ ldapsearch -H ldapi://%2fvar%2frun%2ffedora-ds%2fslapd-ID.socket -x -b "" -s
base "(objectclass=*)" dn
# extended LDIF
# base <> with scope base
# filter: (objectclass=*)
# requesting: dn
# search result
result: 0 Success
# numResponses: 2
# numEntries: 1
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.
Created attachment 160674 [details]
Thank you for reviewing the changes, Rich. I'm attaching the revised diffs.
Created attachment 160675 [details]
cvs commit message
Checked in into HEAD.
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