Hide Forgot
Description of problem: When result set size is restricted on the server and a client tries to use the paged LDAP request API to obtain a query result set that is larger than the restricted result set size the server responds incorrectly following the fist set of results. The problem occurs on the architectures ppc64 (and probably s390x which I will be testing soon) only. Other architectures function properly. The sequence of calls for a paged LDAP query is: Use ldap_create_page_control() to create a page control object. Call ldap_search_ext_s() for the query using the page control. Parse the result using ldap_parse_result() to retrieve the control(s). Use ldap_parse_page_control() to parse the retrieved control. It is at this point that an incorrect result is received in the cookie used to indicate that more results are available after the first page of results is received. Specifically, if more results are available the contents of the field cookie->bv_val should be not be empty, which is the server telling use we can get another page of results if needed. On ppc64 the cookie bv_val is empty after receiving the first set of results which is the server saying there are no more results, when in fact there are. Version-Release number of selected component (if applicable): Sorry, I didn't check the version. If really needed I can check out a lab machine and re-run my test. How reproducible: always. Steps to Reproduce: The Beaker workflow-autofs subtest bz563956 demonstrates the failure provided autofs-5.0.1-0.rc2.155.el5 or later is used. The test sets up an automount map with 1100 entries and configures LDAP to allow an unlimited result set size, then checks LDAP is functioning. It then changes the LDAP configuration to a hard sizelimit of 2000 and a soft sizelimit of 1000 to test the paged query needed to read the automount map. The problem was identified by checking out a lab system with a current RHEL-5.7 install then adding debug prints to the automount program and carrying out the test steps manually.
Yanfu Wang and myself can help with any testing needed. I've set the priority to high because we have a z-stream bug held up in QA due to this difficulty. Any help or suggestions as to how this should be done differently, if that is the case, would be much appreciated.
Hi Ian, openldap in EL5 doesn't export ldap_create_page_control(). I quickly scanned autofs sources and they use their own implementation of this function. The problem appeared when the server was running on ppc64? Or client? Or both? I would like to write a minimal reproducer. Jan
(In reply to comment #2) > Hi Ian, > > openldap in EL5 doesn't export ldap_create_page_control(). I quickly scanned > autofs sources and they use their own implementation of this function. Ahh, thanks for your catching that obvious problem that I missed. That's done because in earlier versions of openldap a couple of the paged query functions were not declared in the header files but existed and in the libraries and functioned ok. So configure checks for them and if they aren't present autofs uses its own. I guess that means that the autofs internal functions need to be updated to also detect when paged result sets aren't supported by the server. Once again any suggestions would be appreciated. > > The problem appeared when the server was running on ppc64? Or client? Or both? > I would like to write a minimal reproducer. In this case the test sets up LDAP on the same machine as the autofs client so the ppc machine is both client and server.
(In reply to comment #3) > I guess that means that the autofs internal functions need to > be updated to also detect when paged result sets aren't supported > by the server. Once again any suggestions would be appreciated. I don't know yet. 'ldapsearch -E !pr=10/noprompt' obviously works on RHEL-5. Please, can you try reproducing it with ldapsearch?
(In reply to comment #4) > (In reply to comment #3) > > I guess that means that the autofs internal functions need to > > be updated to also detect when paged result sets aren't supported > > by the server. Once again any suggestions would be appreciated. > > I don't know yet. 'ldapsearch -E !pr=10/noprompt' obviously works on RHEL-5. > Please, can you try reproducing it with ldapsearch? OK, so loading up the LDAP server with 1100 entries, setting sizelimit.hard=2000 and sizelimit.soft=1000, and using "ldapsearch -E '!pr=1000/noprompt'" looks like it does do a paged query successfully against the ppc64 server. So I wonder what I'm doing wrong ....
Another bug has been opened to work on this issue. *** This bug has been marked as a duplicate of bug 700896 ***