Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 389127 [details] This is the trace when slapd crashes Description of problem: I'm trying to configure openldap on Fedora. I have noticed that when I configure the database to use the hdb backend, slapd crashes on delete operations. The exactly same configuration is working if I switch to bdb. I'm attaching the slapd.conf file (I use the old style slapd.conf as I prefer it over the new cn=config way, slapd.d directory has been deleted to be sure slapd.conf is used) Version-Release number of selected component (if applicable): Fedora 12 x86_64 fully up to date (bug also present in x86) openldap-2.4.19-1.fc12.x86_64 openldap-servers-2.4.19-1.fc12.x86_64 openldap-clients-2.4.19-1.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1. Run slapd whith your database configured to use hdb 2. Load some sample data 3. Delete an entry with: ldapdelete -D cn=admin,dc=domain,dc=tld -w secret uid=myuser,ou=Users,dc=domain,dc=tld Actual results: slapd crashes immediately, before the delete occurs. ldapdelete returns: ldap_result: Can't contact LDAP server (-1) Expected results: deletes operations should work (of course ;)) Additional info: To debug this issue, I ran slapd manually (without the initscript) with the following command: slapd -u ldap -h ldap://127.0.0.1/ -d 1 -f /etc/openldap/slapd.conf
Created attachment 389128 [details] slapd.conf
Created attachment 389130 [details] /var/lib/ldap/DB_CONFIG file I used the default DB_CONFIG file from /usr/share/doc/openldap-servers-2.4.19/DB_CONFIG.example (not sure if it can be related)
It is because of this http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/dn2id.c.diff?r1=1.168&r2=1.169&hideattic=1&sortbydate=0&f=h I had a conversation with one of the OpenLDAP developers and he said to try that and it worked. He also said that that error appears only when it is compiled with -D_FORTIFY_SOURCE=2. That problem persisted from 2.4.19 (AFAIK) to 2.4.21-3. It is still not resolved in F13 (rawhide).
So as I understand this, it's a Fedora specific bug and because of that I suppose upstream is not planning to do anything here. Am I right or did I miss something?
(In reply to comment #4) > So as I understand this, it's a Fedora specific bug and because of that I > suppose upstream is not planning to do anything here. Am I right or did I miss > something? From what I have understood it is due to a modification to gcc ... but I'm not sure. It is easy to patch it so Fedora could add it easily to the RPM. It is just a code line and is the same to all the OpenLDAP releases from 2.4.19 to 2.4.21. They (the OpenLDAP developers) know about that and it will be (maybe) added to the next release. The problem is that F12 has 2.4.19 and only F13 has 2.4.21 ... and that modification will appear, maybe, in 2.4.22 ... and I don't know if that will be part of F12 or F13 .... or just F14 ... I don't understand the update politics of Fedora.
Please ignore my last comment. After a while of research I already realized the link you posted is actually a fix, not a cause. I will post this fix to both Fedora 12 and 13 before Openldap is rebased there.
openldap-2.4.19-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/openldap-2.4.19-3.fc12
openldap-2.4.21-4.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/openldap-2.4.21-4.fc13
openldap-2.4.21-4.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openldap'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2854
openldap-2.4.21-4.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
openldap-2.4.19-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.