Bug 480384 - online schema update fails with SUP
Summary: online schema update fails with SUP
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.1.3
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
 
Reported: 2009-01-16 19:42 UTC by Rob Crittenden
Modified: 2015-01-04 23:35 UTC (History)
4 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-29 23:09:28 UTC


Attachments (Terms of Use)
CVS Diffs (1.01 KB, patch)
2009-01-19 20:40 UTC, Nathan Kinder
no flags Details | Diff

Description Rob Crittenden 2009-01-16 19:42:26 UTC
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.

Comment 1 Rich Megginson 2009-01-16 19:52:31 UTC
I wonder if this is related to the other schema problems we're currently seeing.

Comment 2 Nathan Kinder 2009-01-19 19:34:11 UTC
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.

Comment 3 Rob Crittenden 2009-01-19 20:33:13 UTC
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.

Comment 4 Nathan Kinder 2009-01-19 20:37:39 UTC
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".

Comment 5 Nathan Kinder 2009-01-19 20:40:05 UTC
Created attachment 329398 [details]
CVS Diffs

Allow attribute aliases to be used as superior in attribute definitions.

Comment 6 Nathan Kinder 2009-01-19 21:27:55 UTC
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

Comment 7 Jenny Severance 2009-04-09 19:34:17 UTC
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

Comment 8 Nathan Kinder 2009-04-09 21:38:27 UTC
(In reply to comment #7)
> Is this sufficient to verify this bug?
> 

Yes, that is sufficient.

Comment 9 Chandrasekar Kannan 2009-04-29 23:09:28 UTC
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


Note You need to log in before you can comment on or make changes to this bug.