Bug 436046 - openldap-servers RPM unnecessarily does dump / restore of database
openldap-servers RPM unnecessarily does dump / restore of database
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap (Show other bugs)
All Linux
low Severity high
: rc
: ---
Assigned To: Jan Safranek
Depends On:
  Show dependency treegraph
Reported: 2008-03-04 18:22 EST by Frode Nordahl
Modified: 2009-01-20 15:53 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 15:53:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Frode Nordahl 2008-03-04 18:22:54 EST
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 :-)

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.

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.

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:

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 Product and Program Management 2008-06-02 16:15:44 EDT
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
Comment 4 Jan Safranek 2008-08-13 08:53:02 EDT
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 15:53:41 EST
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.


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