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: [email protected]
Reporter: [email protected]
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.
--
You are receiving this mail because:
You are on the CC list for the issue.
