Created attachment 416505 [details] kerberos ldif Description of problem: After dropping in a new schema file then loading some schema online 99user.ldif gets more than just the online updates. Version-Release number of selected component (if applicable): 389-ds-base-1.2.6-0.3.a3.fc12.x86_64 Steps to Reproduce: 1. setup-ds.pl to install new basic instance. I took all defaults. 2. cp 60kerberos.ldif to /etc/dirsrv/slapd-INSTANCE/schema 3. service dirsrv restart 4. ldapmodify -x -D "cn=Directory Manager" -W < update.ldif Actual results: 99user.ldif contains the online updates as well as the contents of 60kerberos.ldif. I've also seen other attributes end up in there. Twice I've seen: objectClasses: ( 2.16.840.1.113730.3.2.4 NAME 'mailGroup' DESC 'mailGroup' SUP top STRUCTURAL MUST mail MAY ( cn $ mgrpRFC822MailMember ) X-ORIGIN 'user d efined' ) Expected results: Just the online schema
Created attachment 416506 [details] online update file
mailGroup is in your update.ldif file? That's why it ends up in 99user.ldif - you are allowed to override schema definitions, but it is usually not a good idea
Ok, freaky, that is an oversight. This schema is to support the Sun LDAP configuration tool and I guess they assume this attribute isn't available. I cut-and-pasted this. I'll make a note to remove this attribute since it is already there. Still, this doesn't explain why the kerberos schema is included.
(In reply to comment #3) > Ok, freaky, that is an oversight. This schema is to support the Sun LDAP > configuration tool and I guess they assume this attribute isn't available. I > cut-and-pasted this. I'll make a note to remove this attribute since it is > already there. > > Still, this doesn't explain why the kerberos schema is included. right - that's a bug
Created attachment 417013 [details] 0001-Bug-595874-99user.ldif-getting-overpopulated.patch
the bug seems to be similar to https://bugzilla.redhat.com/show_bug.cgi?id=474254 and https://bugzilla.redhat.com/show_bug.cgi?id=529258
(In reply to comment #6) > the bug seems to be similar to > https://bugzilla.redhat.com/show_bug.cgi?id=474254 and > https://bugzilla.redhat.com/show_bug.cgi?id=529258 It is related to those. But those fixes missed the case where a user could provide a "standard" schema file like 60kerberos.ldif with no X-ORIGIN.
To ssh://git.fedorahosted.org/git/389/ds.git 84b40e3..df777e3 Directory_Server_8_2_Branch -> Directory_Server_8_2_Branch commit df777e3de911e3b5428938a7f1c91b76678fb0e2 Author: Rich Megginson <rmeggins> Date: Wed May 26 12:18:34 2010 -0600 8e6e740..2e8fc55 master -> master commit 2e8fc55fcc185577d0973eae58f1f8f26cbd442b Author: Rich Megginson <rmeggins> Date: Wed May 26 12:18:34 2010 -0600 Fix Description: The schema code was adding X-ORIGIN 'user defined' to all schema elements that had no X-ORIGIN. It should only add user defined to schema elements from the user defined schema file, not to schema defined in standard (read only) schema files. It looks like the code should work fine if the schema element has no origin, so there is no reason to add an origin for schema other than user defined schema. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no
1. placed 60kerberos.ldif in schema directory 2. restarted the directory server 3. did online schema update with the update.ldif 4. only the update schema is in the 99user.ldif file Is this enough to verify this bug? Thanks!
(In reply to comment #10) > 1. placed 60kerberos.ldif in schema directory > 2. restarted the directory server > 3. did online schema update with the update.ldif > 4. only the update schema is in the 99user.ldif file > > Is this enough to verify this bug? Yes. > Thanks!
Thanks Rich - marking verified - RHEL 4 version: redhat-ds-base-8.2.0-2010060704.el4dsrv