--On Sunday, July 9, 2023 9:28 AM +0200 awsome jang jangawsome@gmail.com wrote:
Hello,
Thank you for your response - it was very helpful.
Bug is registered with a solution proposal: https://bugs.openldap.org/show_bug.cgi?id=10077
Thanks!
I was wondering how to handle this issue in case there is already this negative context CSN in the database? So scenario would be as follow:
- do a backup create ldif (contains contextCSN:
20230410125515.-401856Z#000000#000#000000 or entryCSN with minus) 2) do an update of openldap, 3) restore backup from ldif. In this case restoring backup ends up with an error so there is no possibility to restore the backup database.
Could you please provide some guidance on how to clean up this corruption in a proper way? Should I remove the line with negative contextCSN/entryCSN or remove the minus in the ldif file to restore the backup?
If you only have a single server, I would do the following:
Stop server export database remove all entryCSN and contextCSN attributes load database with slapad, using the -w flag to regenerate the contextCSN value at the end.
However, I would only do the above if you have your suggested fix in place so the problem doesn't re-occur.
If you have > 1 server, you would need to stop all the servers, do the above on one server, and then after it's complete, export its db again with slapcat, then copy that over to the other servers and reload them with the fixed database. Again with the caveat about having fixed binaries in place.
Regards, Quanah