Description of problem:
Trying to update some schema online with the following modification:
attributetypes: ( 2.16.840.1.1137184.108.40.206.5 NAME 'memberUser' DESC 'Reference to a principal that performs an action (usually user).' SUP distinguishedName X-ORIGIN 'IPA v2' )
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):
Steps to Reproduce:
1. Create DS instance
2. ldapmodify -x -d "cn=directory manager" -W < update.ldif
This may succeed if you replace distinguishedName with dn
If you attempt to add another, similar attribute say:
( 2.16.840.1.1137220.127.116.11.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
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]
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
Is this sufficient to verify this bug?
[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
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
aci: (targetattr="*")(version 3.0; acl "Configuration Administrator"; allow (a
ll) userdn="ldap:///uid=admin,ou=Administrators, ou=TopologyManagement, o=Ne
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
attributeTypes: ( 2.16.840.1.113718.104.22.168.5 NAME 'memberUser' DESC 'Reference
to a principal that performs an action (usually user).' SUP distinguishedNam
e SYNTAX 22.214.171.124.4.1.14126.96.36.199.12 X-ORIGIN ( 'IPA v2' 'user defined' )
(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.