Bug 474254

Summary: Default schema ends up in 99user.ldif
Product: [Retired] 389 Reporter: Nathan Kinder <nkinder>
Component: Directory ServerAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: low    
Version: 1.1.3CC: benl, jgalipea, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: 8.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-29 23:08:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 249650, 493682    
Attachments:
Description Flags
CVS Diffs none

Description Nathan Kinder 2008-12-02 23:32:58 UTC
Created attachment 325450 [details]
CVS Diffs

A number of the default attribute and objectclass definitions end up in 99user.ldif if you add any custom schema over LDAP.

  - Install DS.
  - Add a new attributeType to "cn=schema" over LDAP.
  - 99user.ldif will contain many other attribute and objectclass
    definitions in it aside from your new custom attribute.

The default schema definitions should not end up in 99user.ldif.

The cause of these definitions being copied to 99user.ldif are due to either duplicate definitions within the default schema, or from missing X-ORIGIN elements.  These two conditions cause DS to think that the schema definitions have been redefined, or they are user defined.

The fix is to simply remove the duplicates and to add the missing X-ORIGIN elements.

Comment 1 Nathan Kinder 2008-12-03 00:04:08 UTC
Checked into ldapserver (HEAD).  Thanks to Rich for his review!

Checking in ldap/schema/01common.ldif;
/cvs/dirsec/ldapserver/ldap/schema/01common.ldif,v  <--  01common.ldif
new revision: 1.3; previous revision: 1.2
done
Checking in ldap/schema/60autofs.ldif;
/cvs/dirsec/ldapserver/ldap/schema/60autofs.ldif,v  <--  60autofs.ldif
new revision: 1.2; previous revision: 1.1
done
Checking in ldap/schema/60eduperson.ldif;
/cvs/dirsec/ldapserver/ldap/schema/60eduperson.ldif,v  <--  60eduperson.ldif
new revision: 1.2; previous revision: 1.1
done
Checking in ldap/schema/60mozilla.ldif;
/cvs/dirsec/ldapserver/ldap/schema/60mozilla.ldif,v  <--  60mozilla.ldif
new revision: 1.2; previous revision: 1.1
done
Checking in ldap/schema/60pureftpd.ldif;
/cvs/dirsec/ldapserver/ldap/schema/60pureftpd.ldif,v  <--  60pureftpd.ldif
new revision: 1.2; previous revision: 1.1
done
Checking in ldap/schema/60rfc2739.ldif;
/cvs/dirsec/ldapserver/ldap/schema/60rfc2739.ldif,v  <--  60rfc2739.ldif
new revision: 1.2; previous revision: 1.1
done
Checking in ldap/schema/60rfc3712.ldif;
/cvs/dirsec/ldapserver/ldap/schema/60rfc3712.ldif,v  <--  60rfc3712.ldif
new revision: 1.2; previous revision: 1.1
done
Checking in ldap/schema/60sabayon.ldif;
/cvs/dirsec/ldapserver/ldap/schema/60sabayon.ldif,v  <--  60sabayon.ldif
new revision: 1.2; previous revision: 1.1
done
Checking in ldap/schema/60trust.ldif;
/cvs/dirsec/ldapserver/ldap/schema/60trust.ldif,v  <--  60trust.ldif
new revision: 1.2; previous revision: 1.1
done

Comment 2 Nathan Kinder 2008-12-03 00:04:58 UTC
To verify:

  - Install DS.
  - Add a new attributeType to "cn=schema" over LDAP.
  - 99user.ldif should only contain your new custom attribute.

Comment 3 Jenny Severance 2009-04-06 20:01:53 UTC
Fix verified with one confirmation needed - the 99user.ldif contains 4 acis in addition to the extended schema.  I believe this is correct.  Please confirm.
Thanks


[root@jennyv4 en]#  ldapmodify -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -a -f addmozattr 
modifying entry "cn=schema"

[root@jennyv4 en]# ldapmodify -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 <<EOF
> dn: cn=schema
> changetype: modify
> add: objectclasses
> objectclasses: ( 1.22.333.4444 NAME 'myMozOC' DESC 'Objectclass that contains MozillaAttribute' SUP top STRUCTURAL MUST ( cn $ MozillaAttribute ) )
> EOF
modifying entry "cn=schema"


99user.ldif:

[root@jennyv4 schema]# more 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: 20090406195831Z
objectClasses: ( 1.22.333.4444 NAME 'myMozOC' DESC 'Objectclass that contains 
 MozillaAttribute' SUP top STRUCTURAL MUST ( cn $ MozillaAttribute ) X-ORIGIN
  'user defined' )
attributeTypes: ( 8.9.10.11.12.13.14 NAME 'MozillaAttribute'  SYNTAX 1.3.6.1.4
 .1.1466.115.121.1.15 X-ORIGIN ( 'Mozilla Dummy Schema' 'user defined' ) )
nsSchemaCSN: 49da5ee7000000000000

Comment 4 Nathan Kinder 2009-04-06 20:34:28 UTC
The aci's are expected.  You can mark this one VERIFIED.

Comment 5 Jenny Severance 2009-04-06 20:39:45 UTC
verified RHEL 4 DS 8.1

Comment 6 Chandrasekar Kannan 2009-04-29 23:08:25 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