https://bugs.openldap.org/show_bug.cgi?id=10417
Issue ID: 10417 Summary: Objects not receivable anymore after schema attribute name /alias change Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: best@univention.de Target Milestone: ---
Created attachment 1100 --> https://bugs.openldap.org/attachment.cgi?id=1100&action=edit ITS10417.txt
We have objects in the directory which cannot be received anymore after we change the schema. The objects are returned in a search but using the DN as search base yields NO SUCH OBJECT error code.
The schema change: Add another NAME for the existing attribute and put it into the first (canonical) position. The attribute is used as RDN component for objects.
Schema change as (unified) diff:
```diff -attributetype ( 1.3.6.1.4.1.10176.4221.1.10 NAME 'univentionRecycleBinOriginalUniventionObjectIdentifier' +attributetype ( 1.3.6.1.4.1.10176.4221.1.10 + NAME ('univentionRecycleBinID' 'univentionRecycleBinOriginalUniventionObjectIdentifier') DESC 'Original univentionObjectIdentifier of the deleted object' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.10176.4221.2.2 NAME 'univentionRecycleBinObject' DESC 'Object stored in the Recycle Bin' SUP top STRUCTURAL MUST ( univentionRecycleBinOriginalDN $ univentionRecycleBinDeleteAt $ - univentionRecycleBinOriginalUniventionObjectIdentifier $ + univentionRecycleBinID $ univentionRecycleBinOriginalObjectClass $ univentionRecycleBinDeletionDate $ univentionRecycleBinOriginalEntryUUID $ univentionRecycleBinOriginalType ) MAY ( univentionObjectIdentifier $ univentionObjectType $ univentionRecycleBinReference ) ) ```
Now the proof script: It searches for a certain example object. And get its DN. (stored in a variable with correct LDAP DN escape sequences). Then it searches for that object. → no result Then it searches for a modified DN so that its RDN uses a new name → no result Then it searches for a modified DN so that its RDN uses the OID → no result
```bash start="$(date '+%Y-%m-%d %H:%M:%S')" sleep 1
ldaps () { ldapsearch -o ldif-wrap=no -ZZ -D cn=master,cn=dc,cn=computers,dc=ucs,dc=test -y /etc/machine.secret -LLL "$@" }
DN=$(ldaps -LLLb 'cn=recyclebin,cn=internal' univentionRecycleBinID=785c156b-bc84-4cb2-b34d-e10d78065a57 1.1 | sed -ne 's/^dn: //p') echo "$DN"
ldaps -b "$DN" 1.1 ldaps -b "$(echo "$DN" | sed 's/univentionRecycleBinOriginalUniventionObjectIdentifier/univentionRecycleBinID/g')" 1.1 ldaps -b "$(echo "$DN" | sed 's/univentionRecycleBinOriginalUniventionObjectIdentifier/1.3.6.1.4.1.10176.4221.1.10/g; s/univentionRecycleBinOriginalDN/1.3.6.1.4.1.10176.4221.1.5/')" 1.1
sleep 1 end="$(date '+%Y-%m-%d %H:%M:%S')" journalctl --since="$start" --until="$end" ``` The command output and logs are attached, with stripped date prefix.
The logs show, that OL normalizes the DN internally. So the search by OID, or alias is not a problem. I don't know yet, (but i would suspect it), if OL backends store object DNs internally by storing AVA-lists with OIDs: [[(OID, value, AVA_TYPE), …], …]
---
Background of our schema change reasoning:
We have very long RDN components now and reach some MDB limits. I don't know if the limit only affect RDN values or as well the RDN attribute-names. But also for user-friendly-ness we want to shorten the DN name.
ldap.OTHER: {'msgtype': 105, 'msgid': 3, 'result': 80, 'desc': 'Other (e.g., implementation specific) error', 'ctrls': []}
slapd[28205]: => mdb_dn2id_add 0x3fb: "univentionRecycleBinOriginalDN=uid\3Dumc_test_user_xvju2bhb6t\2Ccn\3Dintermediate_test_container\2Ccn\3Dbase_test_container\2Cdc\3Dautotest092\2Cdc\3Daaaa+univentionRecycleBinOriginalUniventionObjectIdentifier=675f8041-87d9-4483-9c46-e558f9f58c7f,cn=recyclebin,cn=internal" slapd[28205]: <= mdb_dn2id_add 0x3fb: -30781 slapd[28205]: mdb_add: dn2id_add failed: MDB_BAD_VALSIZE: Unsupported size of key/DB name/data, or wrong DUPFIXED size (-30781)
So we want to change: univentionRecycleBinOriginalDN = {DN} + univentionRecycleBinOriginalUniventionObjectIdentifier = {UUID} , cn = recyclebin , cn = internal to: univentionRecycleBinID = {UUID} , parent(DN) , cn = recyclebin , cn = internal
But we must be backward compatible to a certain degree for old productive systems.