https://bugzilla.redhat.com/show_bug.cgi?id=643979
Description of problem: I've been using OpenLDAP to talk to Fedora DS, and my bindings weren't working! This was quite vexing, so I did some investigation. I finally pinpointed the error to ldap_get_values_len() returning a NULL pointer for nsslapd-referral, with no error code. Sounds sort of like a bug in OpenLDAP, no? Yes it does, but it's a bug that's only tickled in very strange circumstances. If you use ldapvi, well, that links to OpenLDAP, but it ignores NULLs so that's why you never see a nsslapd-referral in your cn=config entry. I made a dump of the buffer that OpenLDAP was parsing values out of (I think this was what was transmitted over the network.) Exhibit A (byte sequence containing nsslapd-referral): 0<14><04><10>nsslapd-referral1<00>0<19><04><12> Exhibit B (byte sequence containing nsslapd-localhost): 0,<04><11>nsslapd-localhost1<17><04><15>cats-whiskers.mit.edu0#<04><16> As you can see, the byte sequence for nsslapd-referral appears to have no textual data associated with it. Howard responded to the OpenLDAP list with this: > But it's certainly stupid for the server to attach the attribute to the > response with no values, since this is obviously NOT an attrsOnly search > response. Sounds like you ought to file a bug report against the Fedora > Directory Server. [1] Version-Release number of selected component (if applicable): 1.2.6 How reproducible: Always. Steps to Reproduce: 1. Attempt to retrieve the cn=config object with the OpenLDAP library and observe the ldap_get_values_len output for nsslapd-referral. If requested, I could probably create a C test script. Actual results: nsslapd-referral is sent with weird byte sequence. Expected results: nsslapd-referral is omitted from results.
I'm not familiar with openLDAP. Does it have its own ldapsearch? It is unlcear what you are doing to reproduce this behavior.
Can you please provide the exact testcase?
Thanks, Mark
Is the testcase described in the bz 643979 comment 7 detailed enough? https://bugzilla.redhat.com/show_bug.cgi?id=643979#c7 =============================================================================== I am testing this bug fix, and got : [root@amitesthost scripts]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w xyz -b "cn=config" | grep nsslapd-referral nsslapd-referralmode:
Which I guess violating this rule "The cn=config is not supposed to store empty attribute." =============================================================================== This bug has a history. The original bug was supposed to be fixed, but it failed in the verification phase. So, the "Description of problem" may not be a help...
Side note, from a LDAP standard point of view, there is nothing wrong with attributes without values.
Question, is the problem with "nsslapd-referral" or "nsslapd-referralmode"? There is a conflict between bugzilla and trac. I saw an empty nsslapd-referralmode in my cn=config entry, but I did not see nsslapd-referral. Also, there were many attributes in the returned cn=config that did not have values, not just nsslapd-referralmode.
I wrote a ldap client, and I do not see nsslapd-referral being returned when searching on cn=config. I think this was fixed by 643979, and that QE got confused when they saw nsslapd-referralmode.
In regards to some of the attributes being returned with "" values, that would need to be handled in a new bug, but we know where the issue is happening, and it is by design. Changing the behaviour could cause issues with existing ldap clients.
Closing bug...
Mark
Added initial screened field value.
At Rich's suggestion I am reopening this bug.
http://lists.fedoraproject.org/pipermail/389-users/2012-August/015015.html
To recap: when logged in as the directory administrator (cn=root in my case) and selecting the "Configuration" tab for a server in the 389-console, I receive a message stating I do have the necessary permissions and am prompted to login as a different user.
When running in 389-console in debug mode, I see these messages which I think are relevant:
DSEntrySet.getAttributes(): failed to get attribute nsslapd-referral in cn=config ServerSettingsPanel.ReferralText.show:<> DSEntrySet.show(): some of the attributes of cn=config could not be read. Either they are not present in the entry or there is an ACI which prevents that attribute from being read. Try authenticating as a user with more access
389-admin-console-1.1.8-1.el5.noarch 389-admin-console-doc-1.1.8-1.el5.noarch 389-console-1.1.7-3.el5.noarch 389-ds-console-1.2.6-1.el5.noarch 389-ds-console-doc-1.2.6-1.el5.noarch
CentOS release 5.7 (Final)
I can not reproduce the issue on RHEL 6 (DS master source code).
here is my comparable output from the console:
DSEntrySet.getAttributes(): nsslapd-lastmod was found, setting value from entry DSEntrySet.getAttributes(): nsslapd-readonly was found, setting value from entry DSEntrySet.getAttributes(): nsslapd-schemacheck was found, setting value from entry DSEntrySet.getAttributes(): failed to get attribute nsslapd-referral in cn=config DSEntrySet.getAttributes(): created attribute nsslapd-referral in cn=config DSEntrySet.getAttributes(): nsslapd-referral was found, setting value from entry ServerSettingsPanel.ReferralText.show: <>
Getting the DS logs would be very useful, as well as a copy of the "cn=config" entry from the dse.ldif.
Any update? If there is no response this will be closed at the end of next week. It can always be reopened.
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.1
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/78
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Invalid)
Login to comment on this ticket.