RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1044179 - objectclass may, must lists skip rest of objectclass once first is found in sup
Summary: objectclass may, must lists skip rest of objectclass once first is found in sup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-17 21:42 UTC by Nathan Kinder
Modified: 2020-09-13 20:52 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 09:32:26 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
compareschema.py (4.98 KB, text/python)
2014-10-23 22:36 UTC, Rich Megginson 		no flags Details
updated compareschema.py script (6.10 KB, text/python)
2015-01-12 20:42 UTC, Rich Megginson 		no flags Details
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 968 0 None None None 2020-09-13 20:52:50 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Nathan Kinder 2013-12-17 21:42:46 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47631

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')]

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

person is defined as this:
  MAY ( userPassword $
        telephoneNumber $
        seeAlso $ description )

When parsing the list of attrs in the child to see if the attr is already listed in the parent, once the parser hits the first one (in this case, telephoneNumber), it leaves out the rest.  In this case, telephoneNumber and everything after that (internationalISDNNumber, etc.)
Comment 3 Rich Megginson 2014-10-23 22:34:30 UTC 
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.
Comment 4 Rich Megginson 2014-10-23 22:36:49 UTC 
Created attachment 950111 [details]
compareschema.py
Comment 5 Viktor Ashirov 2015-01-12 14:11:54 UTC 
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?
Comment 6 Rich Megginson 2015-01-12 15:19:04 UTC 
(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?
Comment 7 Viktor Ashirov 2015-01-12 17:01:26 UTC 
(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.
Comment 8 Rich Megginson 2015-01-12 20:42:19 UTC 
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.
Comment 9 Viktor Ashirov 2015-01-12 22:36:12 UTC 
(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.
Comment 10 Rich Megginson 2015-01-12 22:56:58 UTC 
(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
Comment 12 errata-xmlrpc 2015-03-05 09:32:26 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.