--On Sunday, July 9, 2023 9:28 AM +0200 awsome jang <jangaws...@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:
1) 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
