Bug 474254 - Default schema ends up in 99user.ldif
Summary: Default schema ends up in 99user.ldif
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.1.3
Hardware: All
OS: All
low
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
 
Reported: 2008-12-02 23:32 UTC by Nathan Kinder
Modified: 2015-01-04 23:35 UTC (History)
3 users (show)

Fixed In Version: 8.1
Clone Of:
Environment:
Last Closed: 2009-04-29 23:08:25 UTC
Embargoed:


Attachments (Terms of Use)
CVS Diffs (41.83 KB, patch)
2008-12-02 23:32 UTC, Nathan Kinder
no flags Details | Diff

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


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