https://bugs.openldap.org/show_bug.cgi?id=10277
Issue ID: 10277 Summary: How to deal with desync between cn=config and back-ldif DNs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: ondra@mistotebe.net Target Milestone: ---
If someone deletes a cn=config entry offline (or through bugs in cn=config, they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous. cn=config papers over this internally at a cost of never being able to modify the entries affected.
Right now the only remedy is slapcat+slapadd of the whole config DB, is that the best we can do? When we detect this (doesn't always happen), should we fix the on-disk copy on startup?
https://bugs.openldap.org/show_bug.cgi?id=10277
--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #0)
If someone deletes a cn=config entry offline (or through bugs in cn=config, they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous. cn=config papers over this internally at a cost of never being able to modify the entries affected.
The files in a back-ldif directory comprise a database, no different from any other database. If someone mucks with the DB contents directly, instead of using the provided tools, then they've intentionally corrupted their DB, and that's all their own problem.
https://bugs.openldap.org/show_bug.cgi?id=10277
--- Comment #2 from Ondřej Kuzník ondra@mistotebe.net --- On Thu, Oct 24, 2024 at 03:15:16PM +0000, openldap-its@openldap.org wrote:
The files in a back-ldif directory comprise a database, no different from any other database. If someone mucks with the DB contents directly, instead of using the provided tools, then they've intentionally corrupted their DB, and that's all their own problem.
Take for example removing ppolicy schema from cn=schema, cn=config will refuse to delete a Cft_schema entry and back-ldif will not renumber entries on its own. Moreover 2.5 will refuse to slapcat the DB (see this[0] email in -technical), what is the official remedy in this case?
[0]. https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/t...
https://bugs.openldap.org/show_bug.cgi?id=10277
--- Comment #3 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #2)
On Thu, Oct 24, 2024 at 03:15:16PM +0000, openldap-its@openldap.org wrote:
The files in a back-ldif directory comprise a database, no different from any other database. If someone mucks with the DB contents directly, instead of using the provided tools, then they've intentionally corrupted their DB, and that's all their own problem.
Take for example removing ppolicy schema from cn=schema, cn=config will refuse to delete a Cft_schema entry and back-ldif will not renumber entries on its own. Moreover 2.5 will refuse to slapcat the DB (see this[0] email in -technical), what is the official remedy in this case?
[0]. https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/ thread/EJYPVGZLYC5BS3WESH6SOAUTJYZIYMJE/
Support for deleting Cft_schema entries should be added. Deleting individual schema elements is already supported, so deleting an entry just needs to be a wrapper around deleting all of its attributes.
https://bugs.openldap.org/show_bug.cgi?id=10277
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|--- |2.7.0
https://bugs.openldap.org/show_bug.cgi?id=10277
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |2.7.1
https://bugs.openldap.org/show_bug.cgi?id=10277
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.1 |2.7.2
-
openldap-its＠openldap.org