On 7/9/25 6:59 PM, Ryan Tandy wrote:

On Wed, Jul 09, 2025 at 10:21:55AM +0100, Kaya Saman wrote:

...

Has something with the configuration file changed in the meantime, or based off this line: "ldif_read_file: no entry file "/usr/local/etc/openldap//cn=config.ldif"" is it something to do with the slapd.ldif file in the openldap directory?

If need be I can post my slapd.conf file too.... any pointers would be great or at least if there was somewhere to increase the logging to say exactly what and where is wrong would be great.

Does your slapd command line include an -f or -F argument?

If I remember correctly, in 2.4 the default if not specified was to use a traditional config file (slapd.conf(5); -f .../slapd.conf).

In 2.5 (and later), I believe the default is a configuration database (slapd-config(5) aka cn=config; -F .../slapd.d).

You can use a slapd.conf file with 2.5. You just have to run slapd with an explicit '-f /usr/local/etc/openldap/slapd.conf'.

The slapd.ldif file is an example of an LDIF file for bootstrapping a cn=config database (input to slapadd(8)). It is not a usable config file on its own.

Ok I think I'm starting to get somewhere :-)

I didn't run the command like your example, instead I used -F /usr/local/etc/openldap

This is what your command gives me:

/usr/local/libexec/slapd -u ldap -g ldap -d 1 -s -1 -f /usr/local/etc/openldap/slapd.conf 686eb0f0.2c8e4201 0x829dda000 @(#) $OpenLDAP: slapd 2.5.20 (Jul  8 2025 21:55:10) $ @ldap.FQDN:/usr/ports/net/openldap25-server/work/openldap-2.5.20/servers/slapd 686eb0f0.2c9d5bf1 0x829dda000 daemon: SLAP_SOCK_INIT: dtblsize=231210 686eb0f0.2ca12125 0x829dda000 daemon_init: listen on ldap:/// 686eb0f0.2ca1e096 0x829dda000 daemon_init: 1 listeners to open... 686eb0f0.2ca283da 0x829dda000 ldap_url_parse_ext(ldap:///) 686eb0f0.2ca49d8e 0x829dda000 daemon: listener initialized ldap:/// 686eb0f0.2ca53316 0x829dda000 daemon_init: 1 listeners opened 686eb0f0.2ccc5977 0x829dda000 slapd init: initiated server. 686eb0f0.2cd8906a 0x829dda000 slap_sasl_init: initialized! 686eb0f0.2d182a50 0x829dda000 mdb_back_initialize: initialize MDB backend 686eb0f0.2d18fc75 0x829dda000 mdb_back_initialize: LMDB 0.9.33: (May 21, 2024) 686eb0f0.2de722c3 0x829dda000 could not stat config file "/usr/local/etc/openldap/schema/ppolicy.schema": No such file or directory (2) 686eb0f0.2de7f247 0x829dda000 slapd destroy: freeing system resources. 686eb0f0.2defbafd 0x829dda000 slapd stopped. 686eb0f0.2df084a5 0x829dda000 connections_destroy: nothing to destroy.

So now I have to figure out where to get the ppolicy schema file from as I can't remember if I grabbed it from the @port config or somewhere else.....

--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

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