Hi!
As I've done the upgrade multiple times in a test environment, too, I can state that the "upgrade guide" found was highly incomplete for me. Actually I invented a script framework that allows to perform a range of adjustments, or just a single adjustment, or skip a specific adjustment. To get an idea this is what I had at last:
conversions/001-fix-config.sh conversions/002-start.sh conversions/003-add-MDB.sh conversions/004-add-syncprov.sh conversions/005-ppolicy.sh conversions/006-add-accesslog.sh conversions/010-certificate-mapping.sh conversions/020-syncrepl.sh conversions/021-syncrepl.sh conversions/100-changelog-0.sh conversions/101-changelog-1.sh conversions/110-syncprov.sh conversions/111-syncprov.sh conversions/120-accesslog.sh conversions/121-accesslog.sh conversions/130-delta-syncrepl.sh conversions/131-delta-syncrepl.sh
clean-all and load-all are helper scripts to clean or load the databases involved (it also cares about chown, etc.) the 001-fixconfig works with sed on the LDIF file to allow slapd to start at all, then I can use ldapmodify to make further adjustments. I deliberately added delta-syncrepl in a two-step design, because I'm not fully convinced about the stability of it (I had core dumps when the content was out of sync)
The first steps I do is: Dropping the contextCSNs, disable replication, refresh the schema data, drop obsolete schema definitions, delete policy attributes, delete policy-related ACLs from olcAccess, delete loading bdb or hdb modules, drop the database overlays and HDB databases
This allows slapadd to create the initial config from LDIF. The I fix olcDatabase={-1}frontend (old version was less picky about the objectclass being correct), adjust the module load path, and the modules to load.
THEN I was able to start slapd. After starting slapd in 003-add-MDB.sh, I re-add the databases dropped before. Next I re-add the syncprov overlays again, configuring them 005-ppolicy.sh re-adds the policy, and 006-add-accesslog.sh adds the accesslog again.
To that point it's mostly what I had before, next I'm adding some new features like authenticating for replication using certificates instead of passwords. Then I configure replication (for the test environment), next adding accesslogs for delta-syncrepl, thgen configure delta-syncrepl, and so on.
The script framework allows to re-try a specific step if it failed, or apply to specific changes to try.
For example a script to adjust the size for the main audit database (910-adjust-MDB-3.sh) looks like this: #!/bin/bash # Adjust size of main accesslog # (c) 2025 by Ulrich Windl set -u
. "$TOOLS_DIR/tools.sh" || exit 2
# DB='{3}mdb' progress "re-configure olcDbMaxSize for $DB..." modify <<LDIF || exit dn: olcDatabase=${DB},cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 157286400 LDIF # ----- So you get the idea that it's a bit more than just changing a few lines in a configuration file. Admittedly using the text config file instead of cn=config as an intermediate step would allow easier hacking I guess.
Kind regards, Ulrich Windl
-----Original Message----- From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Wednesday, July 9, 2025 8:40 PM To: Kaya Saman kayasaman@optiplex-networks.com; openldap- technical@openldap.org Subject: [EXT] Re: Openldap unable to start after upgrading from 2.4 to 2.5
Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die Echtheit überprüft haben.
--On Wednesday, July 9, 2025 8:31 PM +0100 Kaya Saman kayasaman@optiplex-networks.com wrote:
locate ppolicy.schema /usr/local/etc/openldap/schema/ppolicy.schema /usr/local/etc/openldap/schema/ppolicy.schema.sample /usr/local/etc/openldap.orig/schema/ppolicy.schema /usr/local/etc/openldap.orig/schema/ppolicy.schema.sample
I suggest re-reading the upgrade notes.
https://www.openldap.org/doc/admin25/appendix- upgrading.html#ppolicy%20overlay
--Quanah