Bug 480384 - online schema update fails with SUP
online schema update fails with SUP
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.1.3
All Linux
low Severity high
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2009-01-16 14:42 EST by Rob Crittenden
Modified: 2015-01-04 18:35 EST (History)
4 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:09:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Rob Crittenden 2009-01-16 14:42:26 EST
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 14:52:31 EST
I wonder if this is related to the other schema problems we're currently seeing.
Comment 2 Nathan Kinder 2009-01-19 14:34:11 EST
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 15:33:13 EST
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 15:37:39 EST
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 15:40:05 EST
Created attachment 329398 [details]
CVS Diffs

Allow attribute aliases to be used as superior in attribute definitions.
Comment 6 Nathan Kinder 2009-01-19 16:27:55 EST
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 Galipeau 2009-04-09 15:34:17 EDT
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 17:38:27 EDT
(In reply to comment #7)
> Is this sufficient to verify this bug?
> 

Yes, that is sufficient.
Comment 9 Chandrasekar Kannan 2009-04-29 19:09:28 EDT
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.