Bug 438121 - openldap-servers RPM unnecessarily does dump / restore of database
openldap-servers RPM unnecessarily does dump / restore of database
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap (Show other bugs)
4.6
All Linux
low Severity high
: rc
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-19 04:48 EDT by Jan Safranek
Modified: 2008-03-19 04:50 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-19 04:50:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Safranek 2008-03-19 04:48:42 EDT
+++ This bug was initially created as a clone of Bug #436046 +++

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 Jan Safranek 2008-03-19 04:50:47 EDT
sorry, I was looking at wrong .spec - RHEL 4.6 does not do database
backup/restore on .rpm update

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