Bug 707586 - updating openldap from RHEL6.0 to openldap-2.4.23-15 in RHEL6.1 breaks slapd
Summary: updating openldap from RHEL6.0 to openldap-2.4.23-15 in RHEL6.1 breaks slapd
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Jan Vcelak
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2011-05-25 13:00 UTC by Niranjan Mallapadi Raghavender
Modified: 2018-11-14 12:28 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-05-27 08:15:18 UTC
Target Upstream Version:

Attachments (Terms of Use)
slapd log when started with -f /etc/openldap/slapd.conf.bak and with -d1 (17.83 KB, application/octet-stream)
2011-05-25 13:01 UTC, Niranjan Mallapadi Raghavender
no flags Details

Description Niranjan Mallapadi Raghavender 2011-05-25 13:00:13 UTC
Description of problem:

Updating for RHEL6.0 to RHEL6.1 including openldap-servers package using yum causes slapd to fail. This happens when slapd.conf is used instead of slapd.d/cn=config.ldif as configuration file.

Version-Release number of selected component (if applicable):

Version of Openldap provided in RHEL6.0


Version of openldap provided in RHEL6.1


How reproducible:

1. Install RHEL6.0 , Configure slapd to use slapd.conf instead of /etc/openldap/slapd.d/cn=config.ldif

2. Edit /etc/sysconfig/ldap  and specify the slapd_options 
SLAPD_OPTIONS="-f /etc/openldap/slapd.conf.bak"

3. Start slapd 

4. Import some data 

5. Do an yum update  

$yum update openldap-servers

6.service slapd status
slapd dead but pid file exists

Start the slapd service 

 service slapd start
ln: creating hard link `/var/run/slapd.pid': File exists   [  OK  ]

[root@vm112 openldap]# service slapd status
slapd dead but pid file exists
[root@vm112 openldap]# 

Actual results:

slapd fails after upgrade

Expected results:

slapd should not fail.

Additional info:
Attaching the output of the command 
 # slapd -u ldap -g ldap -f /etc/openldap/slapd.conf -d1

Comment 1 Niranjan Mallapadi Raghavender 2011-05-25 13:01:22 UTC
Created attachment 500802 [details]
slapd log when started with -f /etc/openldap/slapd.conf.bak  and with -d1

Comment 2 Niranjan Mallapadi Raghavender 2011-05-25 13:04:41 UTC
To restore the database. 

Recovering from the above 

1. Edit /etc/sysconfig/ldap  and comment the line 
SLAPD_OPTIONS="-f /etc/openldap/slapd.conf.bak"

2. Yum update creates a backup directory,  move the backup directory to /tmp
$mv /var/lib/ldap/backup-xxxx /tmp/backup

3. Stop the slapd service if running 
service slapd stop 

4. Recreate the ldap database, make sure DB_CONFIG file is also copied to a different location 
$cp /var/lib/ldap/DB_CONFIG /tmp
rm -rf /var/lib/ldap/*

5. Copy the DB_CONFIG file back to /var/lib/ldap 

$cp /tmp/DB_CONFIG /var/lib/ldap
$chown ldap.ldap /var/lib/ldap/DB_CONFIG

6.Start and stop  the slapd service to create new bdb files in /var/lib/ldap

$service slapd start
$service slapd stop

7. Restore from backup 
slapadd -f /etc/openldap/slapd.conf.bak -l /tmp/backup/backup.ldif

8. Change the ownership of the files in /var/lib/ldap to user and group ldap 
$chown ldap.ldap /var/lib/ldap/* 

7. Start the slapd service 

$service slapd start

Comment 4 Jan Vcelak 2011-05-26 20:36:34 UTC
(In reply to comment #0)
> 2. Edit /etc/sysconfig/ldap  and specify the slapd_options 
> SLAPD_OPTIONS="-f /etc/openldap/slapd.conf.bak"

This is the cause of the problem. As the custom name of configuration file is set using SLAPD_OPTIONS, correct configuration file is not detected during the package upgrade. This setting also bypasses configuration file verification in slapd initscript.

It is impossible to write upgrade scripts so that every unusual configuration can be detected. This report is the case. I don't consider this report to be a bug.

Red Hat Enterprise Linux Deployment Guide suggests using /etc/openldap/slapd.d. The old configuration file slapd.conf should be used only if backends, which doesn't support runtime configuration, are needed. In both cases, the database is upgraded during package upgrade.

Note You need to log in before you can comment on or make changes to this bug.