|Summary:||Updating openldap deletes database if slapd.conf is used|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Christian Hoffmann <hoffmann>|
|Component:||openldap||Assignee:||Jan Synacek <jsynacek>|
|Status:||CLOSED ERRATA||QA Contact:||Patrik Kis <pkis>|
|Version:||6.6||CC:||ebenes, jsynacek, pkis|
|Target Milestone:||rc||Keywords:||EasyFix, Patch|
|Fixed In Version:||openldap-2.4.40-4.el6||Doc Type:||Bug Fix|
Prior to this update, user data was deleted after updating openldap when the slapd.conf file was used to store the configuration, but the slapd.d/ directory also existed. This update fixes incorrect logic in the post-installation script, and user data is no longer deleted in the described situation.
|Last Closed:||2015-07-22 06:18:49 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Christian Hoffmann 2015-02-17 14:09:18 UTC
Description of problem: Updating openldap deletes the database if a slapd.conf-style config is used while also having an (unused) slapd.d directory. How reproducible: Reproducible in a VM snapshot, seen multiple times at customer sites. Steps to Reproduce: 1. Install RHEL system with OpenLDAP < 2.4.39 (we had openldap-servers-2.4.23-34.el6_5.1.x86_64) 2. Set up slapd with slapd.conf (not slapd.d); use a root dn other than dc=my-domain,dc=com (both as "suffix" in slapd.conf and in the actual database) 3. Run ldapsearch -x and see non-empty results 4. Upgrade to a newer openldap-servers version (here: 2.4.39-8.el6) Actual results: ldap tree is empty (ldapsearch -x yields no results) Expected results: OpenLDAP should behave the same as before the update; ldapsearch -x should return entries. Additional info: Bug #707586 looks similar; however, in our case a standard slapd.conf is used; no non-standard paths have been inserted in SLAPD_OPTIONS: # grep SLAPD_OPTIONS /etc/sysconfig/ldap SLAPD_OPTIONS="-f /etc/openldap/slapd.conf" Analysis: I have tracked down the actual issue to the openldap-servers %post section. During version upgrades, an LDIF backup is created in backup.TIMESTAMP during %pre (line ~481). Both old-style configs (slapd.conf) and new-style configs (slapd.d) are handled in theor own ways there. During %post, the LDIF file is supposed to be re-imported using slapadd (line ~535). However, no config style differentiation is done at this place (neither -f or -F are passed). This makes slapadd default to slapd.d if existing and only fall back to slapd.conf if slapd.d does not exist. This is contrary to the export logic in %pre. Due to the different default, slapadd fails. No indication about the failure is visible. slapd happily serves a now empty database. Manually running the slapadd command confirms this suspicion: # [root@centos6 ~]# service slapd stop Stopping slapd: [ OK ] # runuser -m -s /usr/sbin/slapadd -- ldap -q -l /var/lib/ldap/backup.1424177044/backup.ldif 54e33860 The first database does not allow slapadd; using the first available one (2) 54e33860 bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=my-domain,dc=com". slapadd: line 1: database #2 (dc=my-domain,dc=com) not configured to hold "dc=changed-domain,dc=local"; no database configured for that naming context _ 2.06% eta none elapsed none spd 1.4 M/s Closing DB... Explicitly passing the config file path makes slapadd succeed and restores functionality: # runuser -m -s /usr/sbin/slapadd -- ldap -f /etc/openldap/slapd.conf -q -l /var/lib/ldap/backup.1424177044/backup.ldif 54e338b8 /etc/openldap/slapd.conf: line 145: rootdn is always granted unlimited privileges. 54e338b8 bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=yaffas,dc=local". 54e338b8 bdb_monitor_db_open: monitoring disabled; configure monitor database to enable _#################### 100.00% eta none elapsed none fast! Closing DB... Circumstances: This bug only occurs on slapd.conf-style openldap setups where a slapd.d directory exists as well (maybe with example content). Suggested changes: I would expect openldap-servers to handle this case. I propose to add the same logic (-f vs. -F) to the slapadd call which is already present for the slapcat call. In any case, the config selection logic for slapcat and slapadd should match each other. Also, slapadd failures should be made visible; the user should be given some clue on what went wrong and how to fix it (point to the backup) instead of silently breaking the LDAP database. Workaround: Moving /etc/openldap/slapd.d out of the way if it only contains example data would probably avoid this problem as well. Please note that my tests have been done on CentOS test systems, but the RPM postinst has been verified to contain the error in the official RedHat Source RPM.
Comment 4 Jan Synacek 2015-03-25 08:24:55 UTC
Thanks for catching this! It should be fixed in the next stable release.
Comment 8 errata-xmlrpc 2015-07-22 06:18:49 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1292.html