Description of problem: Trying to update some schema online with the following modification: dn: cn=schema changetype:modify add: attributetypes attributetypes: ( 2.16.840.1.113730.3.8.3.5 NAME 'memberUser' DESC 'Reference to a principal that performs an action (usually user).' SUP distinguishedName X-ORIGIN 'IPA v2' ) Fails with: ldap_modify: Type or value exists (20) additional info: attribute type memberUser: Missing parent attribute syntax OID Version-Release number of selected component (if applicable): fedora-ds-base-1.1.3-2.fc9.i386 How reproducible: Every time Steps to Reproduce: 1. Create DS instance 2. ldapmodify -x -d "cn=directory manager" -W < update.ldif Additional info: This may succeed if you replace distinguishedName with dn If you attempt to add another, similar attribute say: ( 2.16.840.1.113730.3.8.3.7 NAME 'memberHost' DESC 'Reference to a principal that performs an action (usually user).' SUP dn X-ORIGIN 'IPA v2' ) It will fail with the Missing parent attribute syntax.
I wonder if this is related to the other schema problems we're currently seeing.
With current ldapserver code, I do get the same failure as rob when using "distinguishedName" instead of "dn" as the parent, but I do not get a failure when using dn at all.
Try adding another attribute that also SUP to dn. In my case it failed. I also tried resetting 99user.ldif back to standard and sometimes I would be able to add a SUP dn schema and sometimes not.
The current code doesn't handle using attribute aliases as the superior attribute in a schema definition. I have a patch for that which will be attached shortly. I see no reason why using "SUP dn" wouldn't work, and it has worked in my tests. My testing was done with the fix for bug 474945 in place, which could have been causing the inconsistencies that Rob experienced. Without the fix for bug 474945, it's possible that attribute syntax info was free'd when it should not have been. Perhaps the syntaxinfo object for "dn" was free'd from memory in Rob's testing, which got his server in a state where it was unable to find the parent attribute of "dn".
Created attachment 329398 [details] CVS Diffs Allow attribute aliases to be used as superior in attribute definitions.
Checked into ldapserver (HEAD). Thanks to Noriko for the review! Checking in ldap/servers/slapd/schema.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/schema.c,v <-- schema.c new revision: 1.19; previous revision: 1.18 done
Is this sufficient to verify this bug? with distinguishedName: [root@jennyv4 jenny]# ldapmodify -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -f schema.ldif modifying entry "cn=schema" [root@jennyv4 jenny]# more /etc/dirsrv/slapd-jennyv4/schema/99user.ldif dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymo us, no acis"; allow (read, search, compare) userdn = "ldap:///anyone";) aci: (targetattr="*")(version 3.0; acl "Configuration Administrators Group"; a llow (all) groupdn="ldap:///cn=Configuration Administrators, ou=Groups, ou=T opologyManagement, o=NetscapeRoot";) aci: (targetattr="*")(version 3.0; acl "Configuration Administrator"; allow (a ll) userdn="ldap:///uid=admin,ou=Administrators, ou=TopologyManagement, o=Ne tscapeRoot";) aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "l dap:///cn=slapd-jennyv4, cn=Red Hat Directory Server, cn=Server Group, cn=je nnyv4.bos.redhat.com, ou=bos.redhat.com, o=NetscapeRoot";) modifiersName: cn=directory manager modifyTimestamp: 20090409193223Z attributeTypes: ( 2.16.840.1.113730.3.8.3.5 NAME 'memberUser' DESC 'Reference to a principal that performs an action (usually user).' SUP distinguishedNam e SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN ( 'IPA v2' 'user defined' ) ) nsSchemaCSN: 49de4d47000000000000
(In reply to comment #7) > Is this sufficient to verify this bug? > Yes, that is sufficient.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html