Hi!

I'm currently test-migrating from 2.4 to 2.5. Basically the new server is up, 
but there may be some undetected problems:
Trying to move to "delta syncrepl" I configured two accesslog mdb databases 
that have odd effects:
I can slapcat them, and the contents looks OK, but I cannot ldapsearch them: 
One variant produces no output, while the other one reliably crashes slapd. 
Like this (SLES15 SP6 version):
                                                  Stack trace of thread 13852:
                                                  #0  0x000055759350a1be n/a 
(slapd + 0x281be)
                                                  #1  0x0000557593599523 
overlay_op_walk (slapd + 0xb7523)
                                                  #2  0x00005575935996ae n/a 
(slapd + 0xb76ae)
                                                  #3  0x0000557593527e54 
fe_op_search (slapd + 0x45e54)
                                                  #4  0x0000557593527726 
do_search (slapd + 0x45726)
                                                  #5  0x000055759352518f n/a 
(slapd + 0x4318f)
                                                  #6  0x000055759352598d n/a 
(slapd + 0x4398d)
                                                  #7  0x00007f166bf1eda0 n/a 
(libldap-2.5.releng.so.0 + 0x48da0)
                                                  #8  0x00007f166bca758c 
start_thread (libc.so.6 + 0xa758c)
                                                  #9  0x00007f166bd2ea28 
__clone3 (libc.so.6 + 0x12ea28)

                                                  Stack trace of thread 13849:
                                                  #0  0x00007f166bca3c4e 
__futex_abstimed_wait_common (libc.so.6 + 0xa3c4e)
                                                  #1  0x00007f166bca91a3 
__pthread_clockjoin_ex (libc.so.6 + 0xa91a3)
                                                  #2  0x00005575935221ca 
slapd_daemon (slapd + 0x401ca)
                                                  #3  0x000055759350588e main 
(slapd + 0x2388e)
                                                  #4  0x00007f166bc40e6c 
__libc_start_call_main (libc.so.6 + 0x40e6c)
                                                  #5  0x00007f166bc40f35 
__libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35)
                                                  #6  0x000055759350590a _start 
(slapd + 0x2390a)

                                                  Stack trace of thread 13851:
                                                  #0  0x00007f166bd2ee86 
epoll_wait (libc.so.6 + 0x12ee86)
                                                  #1  0x000055759351f07b n/a 
(slapd + 0x3d07b)
                                                  #2  0x00007f166bca758c 
start_thread (libc.so.6 + 0xa758c)
                                                  #3  0x00007f166bd2ea28 
__clone3 (libc.so.6 + 0x12ea28)

                                                  Stack trace of thread 13889:
                                                  #0  0x00007f166bca3c4e 
__futex_abstimed_wait_common (libc.so.6 + 0xa3c4e)
                                                  #1  0x00007f166bca6890 
pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890)
                                                  #2  0x00007f166bf1ee40 n/a 
(libldap-2.5.releng.so.0 + 0x48e40)
                                                  #3  0x00007f166bca758c 
start_thread (libc.so.6 + 0xa758c)
                                                  #4  0x00007f166bd2ea28 
__clone3 (libc.so.6 + 0x12ea28)

                                                  Stack trace of thread 13854:
                                                  #0  0x00007f166bca3c4e 
__futex_abstimed_wait_common (libc.so.6 + 0xa3c4e)
                                                  #1  0x00007f166bca6890 
pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890)
                                                  #2  0x00007f166bf1ee40 n/a 
(libldap-2.5.releng.so.0 + 0x48e40)
                                                  #3  0x00007f166bca758c 
start_thread (libc.so.6 + 0xa758c)
                                                  #4  0x00007f166bd2ea28 
__clone3 (libc.so.6 + 0x12ea28)
                                                  ELF object binary 
architecture: AMD x86-64

Still, my configuration may be wrong, but be warned.
The other thing I'm investigating is the inability to use SSHA256: I could load 
pw-sha2.so, but I cannot add olcPasswordHash to the frontend database. Maybe 
the schemata slapadded from 2.4 need updating; I'm unsure.

Kind regards,
Ulrich Windl

> -----Original Message-----
> From: Dirk Kastens <[email protected]>
> Sent: Tuesday, March 11, 2025 8:24 AM
> To: [email protected]
> Subject: [EXT] Re: Request for Guidance on Upgrading from 2.4.x(BDB with
> ppolicy) to 2.6.9
> 
> Hi Anil,
> 
> I did the upgrade last year without any problems. You have to export
> your data to ldif and then import it to the 2.6 server, which is using
> mdb. The ppolicy attributes are included in the schema. You have to load
> the ppolicy module. This is my new configuration:
> 
> cn=config/cn=module{0}.ldif:olcModuleLoad: {3}ppolicy.la
> cn=config/olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:dn:
> olcOverlay={2}ppolicy
> cn=config/olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:objectClass:
> olcPPolicyConfig
> cn=config/olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:olcOverlay:
> {2}ppolicy
> cn=config/olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:olcPPolicyDefault:
> cn=default,ou=policies,dc=uni-osnabrueck,dc=de
> cn=config/olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:olcPPolicyHashCle
> artext:
> TRUE
> cn=config/olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:olcPPolicyUseLock
> out:
> FALSE
> cn=config/olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:olcPPolicyForward
> Updates:
> FALSE
> cn=config/olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:structuralObjectCl
> ass:
> olcPPolicyConfig
> 
> I described my upgrade procedure in this list:
> 
> https://lists.openldap.org/hyperkitty/list/openldap-
> [email protected]/thread/BACEHZPE6UYGKVTI5UYTVL7ONND6CRCI/#
> BACEHZPE6UYGKVTI5UYTVL7ONND6CRCI
> 
> Am 10.03.2025 um 17:01 schrieb [email protected]:
> > Dear LDAP Community,
> >
> > We are planning to upgrade our setup from OpenLDAP 2.4.x to 2.6.9 (latest
> version) and would appreciate your guidance on the following:
> >
> >      Is a direct upgrade from 2.4.x to 2.6.9 possible, or are there 
> > intermediate
> steps required?
> >      We are currently using BDB with ppolicy. Does 2.6.9 support BDB, or is
> migration to MDB mandatory?
> >      Is ppolicy still supported in 2.6.9?
> >      Are the ppolicy module and schema included in 2.6.9, or do they need to
> be obtained externally?
> >      If a migration from BDB with ppolicy to MDB with ppolicy is required,
> could you kindly provide step-by-step guidance?
> >
> > We greatly appreciate any insights, documentation, or recommendations
> you can share.
> >
> > Thank you for your support!
> > Regards,
> > Anil P
> 
> --
> Viele Gruesse,
> 
> Dirk Kastens
> Universitaet Osnabrueck, Rechenzentrum (Computer Center)
> Nelson-Mandela-Str. 4, 49076 Osnabrueck, Germany
> Tel.: +49-541-969-2347, FAX: -2470

Reply via email to