Re: Slapd migrate from hdb to lmdb on 2.5.13

[Richard Rosner]

It seems to look like it's intended to look like this. I know this isn't the typical ldif syntax, but on the main instance that same file starts with this:

   dn: cn=config
   objectClass: olcGlobal
   cn: config
   olcArgsFile: /var/run/slapd/slapd.args
   olcLogLevel: none
   olcPidFile: /var/run/slapd/slapd.pid
   olcToolThreads: 1
   structuralObjectClass: olcGlobal
   entryUUID: 9a5b5f82-56d4-1039-8be0-4705b1c5590c
   creatorsName: cn=config
   createTimestamp: 20190819135427Z
   olcTLSCACertificateFile: /etc/ssl/certs/geant-intermediates.pem
   olcTLSCertificateFile: /etc/ssl/certs/auth.domain.de.cert.pem
   olcTLSCertificateKeyFile: /etc/ssl/private/auth.domain.de.private.pem
   entryCSN: 20230520140839.289572Z#000000#000#000000
   modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
   modifyTimestamp: 20230520140839Z
   contextCSN: 20230520140839.289572Z#000000#000#000000





Richard


Am 24.07.2023 um 17:26 schrieb Quanah Gibson-Mount:

so I guess the rest of the otherwise needed information comes from the command that's used to restore it, or maybe it's not meant to be an ldif file for this to work: slapadd -F/etc/ldap/slapd.d -n0 -l /var/backups/slapd-2.4.57+dfsg-3+deb11u1/cn\=config.ldif

--On Monday, July 24, 2023 6:16 PM +0200 Richard Rosner <rros...@fsmuw.rwth-aachen.de> wrote:

Hi,



an upstream change, but slapd 2.5 on Debian 12 doesn't support the HDB
and BDB backends

I just upgraded our servers from Debian 11 to 12. I'm not sure if this is

Deprecation of BDB based backends was announced years ago during the OpenLDAP 2.4 series lifecycle.

so the database needs to be migrated to LMDB.

slapadd: could not add entry dn="cn=config" (line=1):
 Closing DB...



The first set of lines in cn\=config.ldif reads

dn: cn=config
 objectClass: olcGlobal
 cn: config
 olcArgsFile: /var/run/slapd/slapd.args
 olcLogLevel: none
 olcPidFile: /var/run/slapd/slapd.pid
 olcToolThreads: 1
 structuralObjectClass: olcGlobal
 entryUUID: 71b384b4-aca9-1032-883a-d9850217023f
 creatorsName: cn=config
 createTimestamp: 20130908080726Z
 entryCSN: 20130908080726.757296Z#000000#000#000000
 modifiersName: cn=config
 modifyTimestamp: 20130908080726Z

Is it actually indented this way? Because that would not be valid LDIF.

--Quanah

smime.p7s
Description: S/MIME Cryptographic Signature