Bug 1193519

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.