Bug 436046

Summary: openldap-servers RPM unnecessarily does dump / restore of database
Product: Red Hat Enterprise Linux 5 Reporter: Frode Nordahl <frode>
Component: openldapAssignee: Jan Safranek <jsafrane>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: low    
Version: 5.1CC: christoph.maser, jplans
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-20 20:53:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Frode Nordahl 2008-03-04 23:22:54 UTC
Description of problem:
When not upgrading from one major version to another it is not necessary to dump / restore the BDB 
database with slapcat / slapadd.

We run several replicas of a large OpenLDAP database (> 6M records, 8 GB of data), and we cannot 
afford to have several hours of unnecessary downtime to install security updates. Since slapadd is run 
without the '-q' parameter and without cache settings optimized for importing an entire database it can 
actually run for days.

One of the key reasons to pay for RedHat EL is to save time and money on maintenance of systems by 
having long-lived releases and high quality automatic updates. Until now I have had faith in that RPMS 
released to RHEL updates contained smart and non-destructive pre/post installs scripts, but I was a bit 
discouraged by this event. I hope this bug report can help in making things better :-)

1)
During the lifetime of a RedHat release the major version of a package seldom (if ever) changes, 
making the price users has to pay for having this unnecessary step in the pre/post install process 
worse. The step should probably be removed from the RPM, or retained as a operation executed ONLY 
when upgrading from one major release to another.

2)
The upgrade process lacks error checking, on one of our servers there was not enough free disk space 
to complete the dump / restore, this resulted in that our database was moved away to 
/var/lib/ldap/rpmorig, and slapd was started up serving a empty, uninitialized database.

On a different server slapd serves multiple BDB databases located in subdirectories under /var/lib/ldap, 
by chance the pre/post install scripts was unable to make any damage here, but it sure tried to do so, 
oblivious of the fact that slapd was configured with multiple databases.

3)
From time to time upstream OpenLDAP releases changes the default BDB software distribution used in 
a minor version update, a dump / restore is still not needed, a slapd_db_upgrade on 
/var/lib/ldap/*.bdb will be enough and that operation completes within minutes.

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


How reproducible:
100%

Steps to Reproduce:
1. Populate a OpenLDAP database with a large number of records
2. Simulate a upgrade of openldap packages by running the %pre and %post scripts
3. Observe that it takes way too long and potentially results in a broken service, having in mind that 
the step is totally unnecessary in almost all upgrade situations.
  
Actual results:
Several hours downtime to install a security update

Expected results:
A few minutes downtime to install a security update

Additional info:

Comment 1 RHEL Program Management 2008-06-02 20:15:44 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 4 Jan Safranek 2008-08-13 12:53:02 UTC
I've applied the scripts from Fedora Rawhide, i.e.: 

- The openldap-servers package update should do the automatic database dump/restore  when really needed, i.e. when BDB version changes (and it _shouldn't_ change during RHEL 5 lifetime).

- When the openldap minor version changes (2.3.x -> 2.4.x), the db_upgrade should be called automatically (again, highly unlikely in RHEL 5).

- All these automatic operations are done only on BDB database stored in default directory, i.e. /var/lib/ldap. You must care about your databases manually if you have them somewhere else.

Comment 8 errata-xmlrpc 2009-01-20 20:53:41 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0090.html