Bug 1044179

The problem is caused when the child objectclass MUST or MAY attribute list has some of the same attributes in it as the parent.  For example, our default schema:

organizationalPerson:
  SUP person
  MAY ( title $ x121Address $ registeredAddress $
        destinationIndicator $ preferredDeliveryMethod $
        telexNumber $ teletexTerminalIdentifier $
        telephoneNumber $ internationalISDNNumber $
        facsimileTelephoneNumber $ street $ postOfficeBox $
        postalCode $ postalAddress $ physicalDeliveryOfficeName $
        ou $ st $ l )

person:
  MAY ( userPassword $
        telephoneNumber $
        seeAlso $ description )

Note that person is the parent of organizationalPerson, and both contain 'telephoneNumber' in the MAY attribute list.

When the server reads in the schema, it tries to give the child objectclass the set of unique attributes from both lists.  The bug was that it would stop reading the child list when it found the first duplicate in the parent list.  For example, take a look at the output below:

oid 2.5.6.7 NAME 'organizationalPerson' SUP person
	may differs: [('title', 'x121Address', 'registeredAddress', 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', 'teletexTerminalIdentifier', 'telephoneNumber', 'internationalISDNNumber', 'facsimileTelephoneNumber', 'street', 'postOfficeBox', 'postalCode', 'postalAddress', 'physicalDeliveryOfficeName', 'ou', 'st', 'l')] vs. [('title', 'x121Address', 'registeredAddress', 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', 'teletexTerminalIdentifier')]

The first list is from the schema file.  The second list is from LDAP.  You can see that the second list is truncated.

The way to reproduce and verify is to run the attached script compareschema.py like this:

$ python compareschema.py ldap://host:port/cn=schema\?attributeTypes,objectclasses /etc/dirsrv/slapd-instance/schema/*.ldif

This will compare the schema on disk in the schema files in the instance with the schema found via ldap for the instance.

Created attachment 950111 [details]
compareschema.py

Hello Rich,

$ rpm -qa | grep 389-ds
389-ds-base-libs-1.3.3.1-11.el7.x86_64
389-ds-base-devel-1.3.3.1-11.el7.x86_64
389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64
389-ds-base-1.3.3.1-11.el7.x86_64

$ ./compareschema.py ldap://localhost:389/cn=schema\?attributeTypes,objectclasses /etc/dirsrv/slapd-rhel7ds/schema/*.ldif
name automountMap oid 1.3.6.1.1.1.2.16
	desc differs: [Automount Map information] vs. [An group of related automount objects]
	must is missing ['ou']
	must is missing ['automountMapName']
	may is missing ['description']
name automount oid 1.3.6.1.1.1.2.17
	desc differs: [Automount information] vs. [An entry in an automounter map]
	must is missing ['cn']
	must is missing ['automountKey']
name automountInformation oid 1.3.6.1.1.1.1.33
	desc differs: [Automount information] vs. [Information used by the autofs automounter]
	syntax differs: [1.3.6.1.4.1.1466.115.121.1.26] vs. [1.3.6.1.4.1.1466.115.121.1.15]
skipping file due to parsing errors /etc/dirsrv/slapd-rhel7ds/schema/99user.ldif

Does this output look OK to you?

(In reply to Viktor Ashirov from comment #5)
> Hello Rich,
> 
> $ rpm -qa | grep 389-ds
> 389-ds-base-libs-1.3.3.1-11.el7.x86_64
> 389-ds-base-devel-1.3.3.1-11.el7.x86_64
> 389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64
> 389-ds-base-1.3.3.1-11.el7.x86_64
> 
> $ ./compareschema.py
> ldap://localhost:389/cn=schema\?attributeTypes,objectclasses
> /etc/dirsrv/slapd-rhel7ds/schema/*.ldif
> name automountMap oid 1.3.6.1.1.1.2.16
> 	desc differs: [Automount Map information] vs. [An group of related
> automount objects]
> 	must is missing ['ou']
> 	must is missing ['automountMapName']
> 	may is missing ['description']
> name automount oid 1.3.6.1.1.1.2.17
> 	desc differs: [Automount information] vs. [An entry in an automounter map]
> 	must is missing ['cn']
> 	must is missing ['automountKey']
> name automountInformation oid 1.3.6.1.1.1.1.33
> 	desc differs: [Automount information] vs. [Information used by the autofs
> automounter]
> 	syntax differs: [1.3.6.1.4.1.1466.115.121.1.26] vs.
> [1.3.6.1.4.1.1466.115.121.1.15]
> skipping file due to parsing errors
> /etc/dirsrv/slapd-rhel7ds/schema/99user.ldif
> 
> Does this output look OK to you?

No.  Can you provide me with access to this machine?

(In reply to Rich Megginson from comment #6)
> No.  Can you provide me with access to this machine?
I've sent you details in an email.

This happens in the IPA environment. I had additional schema ldifs from IPA installed in my setup. 

On a clean installation with only 389-ds provided schemas compareschema.py doesn't produce such output.

Created attachment 979340 [details]
updated compareschema.py script

Looks like you found some bugs in my schema compare script - try this one.

I'm not sure why you got the original errors parsing 99user.ldif.  I first did ipactl restart to make sure the server read in the correct schema - then it worked fine.

(In reply to Rich Megginson from comment #8)
> Created attachment 979340 [details]
> updated compareschema.py script
> 
> Looks like you found some bugs in my schema compare script - try this one.
> 
Thank you for the updated script!

# python ./compareschema.py ldap://localhost:389/cn=schema\?attributeTypes,objectclasses /etc/dirsrv/slapd-EXAMPLE-COM/schema/*.ldif
replacing oc oid 2.16.840.1.113730.3.2.4 name mailGroup from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/15rfc2307bis.ldif with def from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/50ns-mail.ldif
replacing at oid 2.16.840.1.113730.3.1.30 name mgrpRFC822MailMember from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/15rfc2307bis.ldif with def from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/50ns-mail.ldif
replacing oc oid 1.3.6.1.1.1.2.16 name automountMap from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/60autofs.ldif with def from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif
replacing oc oid 1.3.6.1.1.1.2.17 name automount from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/60autofs.ldif with def from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif
replacing at oid 1.3.6.1.1.1.1.33 name automountInformation from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/60autofs.ldif with def from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif
replacing oc oid 2.16.840.1.113730.3.2.4 name mailGroup from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/50ns-mail.ldif with def from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/99user.ldif
replacing oc oid 1.3.6.1.1.1.2.16 name automountMap from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif with def from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/99user.ldif
replacing oc oid 1.3.6.1.1.1.2.17 name automount from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif with def from file /etc/dirsrv/slapd-EXAMPLE-COM/schema/99user.ldif
END OK - schema matches

Looks good to me, I'll mark as VERIFIED if you agree.

> I'm not sure why you got the original errors parsing 99user.ldif.  I first
> did ipactl restart to make sure the server read in the correct schema - then
> it worked fine.
My original error message was observed on a system, where I had vanilla 389-ds-base plus 60basev2.ldif and 60basev3.ldif from IPA (hence the mentions of automount). 99user.ldif is the same as in https://fedorahosted.org/389/browser/ldap/schema/99user.ldif, but in IPA it also contains structural objectclasses and cn. So in my setup I got errors because it's actually not really correct ldif file.

(In reply to Viktor Ashirov from comment #9)
> (In reply to Rich Megginson from comment #8)
> > Created attachment 979340 [details]
> > updated compareschema.py script
> > 
> > Looks like you found some bugs in my schema compare script - try this one.
> > 
> Thank you for the updated script!
> 
> # python ./compareschema.py
> ldap://localhost:389/cn=schema\?attributeTypes,objectclasses
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/*.ldif
> replacing oc oid 2.16.840.1.113730.3.2.4 name mailGroup from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/15rfc2307bis.ldif with def from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/50ns-mail.ldif
> replacing at oid 2.16.840.1.113730.3.1.30 name mgrpRFC822MailMember from
> file /etc/dirsrv/slapd-EXAMPLE-COM/schema/15rfc2307bis.ldif with def from
> file /etc/dirsrv/slapd-EXAMPLE-COM/schema/50ns-mail.ldif
> replacing oc oid 1.3.6.1.1.1.2.16 name automountMap from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/60autofs.ldif with def from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif
> replacing oc oid 1.3.6.1.1.1.2.17 name automount from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/60autofs.ldif with def from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif
> replacing at oid 1.3.6.1.1.1.1.33 name automountInformation from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/60autofs.ldif with def from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif
> replacing oc oid 2.16.840.1.113730.3.2.4 name mailGroup from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/50ns-mail.ldif with def from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/99user.ldif
> replacing oc oid 1.3.6.1.1.1.2.16 name automountMap from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif with def from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/99user.ldif
> replacing oc oid 1.3.6.1.1.1.2.17 name automount from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/60basev2.ldif with def from file
> /etc/dirsrv/slapd-EXAMPLE-COM/schema/99user.ldif
> END OK - schema matches
> 
> Looks good to me, I'll mark as VERIFIED if you agree.
> 
> > I'm not sure why you got the original errors parsing 99user.ldif.  I first
> > did ipactl restart to make sure the server read in the correct schema - then
> > it worked fine.
> My original error message was observed on a system, where I had vanilla
> 389-ds-base plus 60basev2.ldif and 60basev3.ldif from IPA (hence the
> mentions of automount). 99user.ldif is the same as in
> https://fedorahosted.org/389/browser/ldap/schema/99user.ldif, but in IPA it
> also contains structural objectclasses and cn. So in my setup I got errors
> because it's actually not really correct ldif file.

Ok  This looks verified

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html