Hello,
Le 03/05/2023 à 18:37, Quanah Gibson-Mount a écrit :
Futhermore, can this explain the crashes/stops?
No. From the logs, something is telling slapd to stop, you need to
figure out what that is.
I am returning here to provide an update on this matter long after our
initial exchanges and in case it might be useful to someone. Our
migration to OpenLDAP 2.5 having been delayed multiple times, I was
unable to investigate this issue until now. I finally handled the
migration today and encountered the same error as in 2023: when the
slave server connected to the master server to initiate synchronization,
the master server would shut down without any clear explanation.
As Stefan Kania noted in 2023 (many thanks to him), we had an issue with
multiple DSNs in the LDAP database. I had dismissed this problem based
on advice from Quanah Gibson-Mount without delving deeper into it at the
time. Today, after reproducing the error, I decided to address this
multiple DNS issue. We hadn't discussed a method to do this, but my
improvised method seems to have worked:
service slapd stop
slapcat | grep -vE '^(entryCSN|contextCSN): ' > /tmp/ldif
rm -f /var/lib/ldap/*.mdb
slapadd -q -l /tmp/ldif
chown openldap: -R /var/lib/ldap/
service slapd start
I then reset the database of our secondary server from a new dump of the
master server, and following that, the synchronization was functional
and, most importantly, no longer caused the master server to crash!
Thank you again for the help received here, and I hope this testimony
will be useful to someone.
Best regards,
P.S.: There must still be an underlying bug, as a crash is never a
normal occurrence (an error message would have been more appropriate
;)). Apparently, syncprov does not like databases with multiple values
in the contextCSN attribute (we had three in our case).
--
Benjamin Renard - Easter-eggs
44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité
Phone: +33 (0) 1 43 35 00 37 - mailto:[email protected]
