This issue seems to be caused by the fact that the openldap packages switched
from using v4.2 to v4.7 of the Berkeley Database libraries, as mentioned in the
changelog.Debian.gz file:
openldap (2.4.14-0ubuntu1) jaunty; urgency=low
[...]
* Build against db4.7 instead of db4.2 at last! Closes: #421946.
[...]
-- Mathias Gug <[email protected]> Wed, 18 Feb 2009 18:44:00 -0500
(Since this happened during the Jaunty timeframe, it would make sense
that an upgrade from Hardy to Lucid would be affected.)
The best discussion about changing to a new BDB version that I found was an old
README.db4.4 that was part of the Debian "subversion" package back in 2006.
The document has since been removed from that package, once Subversion started
handling the DB conversion automatically, but the text is still available from
the source repository for the subversion package:
http://svn.debian.org/wsvn/pkg-subversion/src/tags/1.4.0-1/debian/README.db4.4
The OpenLDAP changelog files and other discussions out on the web imply
that slapd normally does automatic "recovery" of the BDB data files,
which I understand should transparently take care of situations where
the library version has changed.
However, in the case of the Ubuntu package upgrade, the "slaptest"
command is getting executed before the new version of "slapd" is run,
and (given the error that is occuring) it would appear that "slaptest"
does not performat that same automatic recovery operation....
More specifically, the slapd.postinst script is attempting to use the
"slaptest" command to migrate the slapd.conf config file to new slapd.d
format, but in the case where old-BDB-version database files exist under
/var/lib/ldap, that command errors out, thus causing the postinst script
to abort.
In my case, I was able to get past this situation by using the commands
described in the above-mentioned README.db4.4 file, as follows:
(first, install the db4.2-util package)
# cd /var/lib/ldap
# db4.2_checkpoint -1
# db4.2_recover
# db4.2_archive -d
After that I was able to run a plain "slaptest" command manually without
getting the "Program version" error, and when I did another
# dpkg --pending --configure
, the slapd.postinst script's attempt to convert the configuration info was
finally successful.
As far as I know there was nothing unusual about my slapd instance and
associated data files before the upgrade -- but I don't have any other
installation to compare them to, so it's possible that not all Hardy ->
Lucid upgrades will trigger this issue. Still, I'm wondering if there
is any way that the slapd.postinst script could detected and avoid this
situation without requiring manual intervention. (And if not, whether
this issue should be mentioned on the Lucid release notes?)
--
slapd package configuration aborts with "Program version 4.7 doesn't match
environment version 0.44" error during Hardy -> Lucid upgrade
https://bugs.launchpad.net/bugs/536958
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
