Red Hat Bugzilla – Bug 436046
openldap-servers RPM unnecessarily does dump / restore of database
Last modified: 2009-01-20 15:53:41 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):
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.
Several hours downtime to install a security update
A few minutes downtime to install a security update
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
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.
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.