Bug #2637: Migration from Rudder 2.3 to 2.4 on Debian doesn't work with rudder-inventory-ldap package - Rudder - Issue Tracker

Actions

Copy link

Bug #2637

closed

Migration from Rudder 2.3 to 2.4 on Debian doesn't work with rudder-inventory-ldap package

Added by Nicolas PERRON over 12 years ago. Updated over 9 years ago.

Status:

Released

Priority:

1 (highest)

Assignee:

Jonathan CLARKE

Category:

Packaging

Target version:

2.4.0~beta2

Pull Request:

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

When trying to upgrade from Rudder 2.3 to 2.4 on a squeeze, aptitude terminate with error:

etting up rudder-inventory-ldap (2.4.0~beta1-squeeze0) ...
Stopping enhanced syslogd: rsyslogd.
Starting enhanced syslogd: rsyslogd.
slapd[7458]: [INFO] Using /etc/default/slapd for configuration
slapd[7463]: [INFO] Halting OpenLDAP...
slapd[7464]: [INFO] can't read PID file, to stop slapd try: /etc/init.d/slapd forcestop
slapd[7465]: [INFO] Halting OpenLDAP replication...
slapd[7466]: [INFO] no replica found in configuration, aborting stopping slurpd
slapd[7467]: [INFO] Launching OpenLDAP configuration test...
slapd[7469]: [OK] OpenLDAP configuration test successful
slapd[7470]: [INFO] Launching OpenLDAP replication...
slapd[7471]: [INFO] no replica found in configuration, aborting lauching slurpd
slapd[7472]: [INFO] no db_recover done
slapd[7473]: [INFO] Launching OpenLDAP...
slapd[7474]: [OK] file descriptor limit set to 1024
slapd[7478]: [ALERT] no PID file for slapd
invoke-rc.d: initscript slapd, action "restart" failed.
dpkg: error processing rudder-inventory-ldap (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
                                      Errors were encountered while processing:
 rudder-inventory-ldap
E: Sub-process /usr/bin/dpkg returned an error code (1)

If we check /var/log/rudder/ldap/slapd.log:

[...]
ul  6 17:46:59 squeezedev slapd[4729]: bdb(cn=rudder-configuration): Program version 4.8 doesn't match environment version 4.6
Jul  6 17:46:59 squeezedev slapd[4729]: hdb_db_open: database "cn=rudder-configuration" cannot be opened, err -30971. Restore from backup!
Jul  6 17:46:59 squeezedev slapd[4729]: bdb(cn=rudder-configuration): txn_checkpoint interface requires an environment configured for the transaction subsystem
Jul  6 17:46:59 squeezedev slapd[4729]: bdb_db_close: database "cn=rudder-configuration": txn_checkpoint failed: Invalid argument (22).
Jul  6 17:46:59 squeezedev slapd[4729]: backend_startup_one (type=hdb, suffix="cn=rudder-configuration"): bi_db_open failed! (-30971)
Jul  6 17:46:59 squeezedev slapd[4729]: bdb_db_close: database "cn=rudder-configuration": alock_close failed
Jul  6 17:46:59 squeezedev slapd[4729]: slapd stopped.
[...]

Actions

Copy link

Updated by Jonathan CLARKE over 12 years ago

Status changed from New to In progress
Assignee changed from Nicolas PERRON to Jonathan CLARKE
% Done changed from 0 to 50

I've written some upgrade logic to handle this, in Debian packaging only for now.

This is what it does:

Just before upgrading the package, the preinst script is called. This dumps the database in LDIF and stores the BerkeleyDB version in use at the time.
Just after upgrading the package, the postinst script is called. This checks if the current BerkeleyDB version is different from the backup we just made, and if so removes the existing DB and reimports it from the LDIF backup.

It needs testing, so I'm just commiting it for Debian now, so that: