I ran into ITS#8100 (replication item) with 2.4.45 and went to upgrade; one of the pre-upgrade slapcats complained about schema errors. The odd part is that the schema does indeed exist under cn=schema,cn=config and the attributes in question do exist in the resulting ldif. I was unable to find any reference to similar behaviour via ITS or Google search.
Does this ring a bell with anybody? Does this have any implications for a subsequent slapadd after upgrading my custom-compiled openldap rpm? Will this affect future OpenLDAP upgrades? Have I missed a manpage??
Background and more details as follows.
This is how I found out about ITS#8100:
https://www.openldap.org/lists/openldap-technical/201706/msg00078.html https://www.openldap.org/its/index.cgi/Software%20Bugs?id=8100
The schema I had added:
https://github.com/credativ/postfix-ldap-schema
Adding the custom schema went fine apart from the replication issue:
---------- dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop ))
modifying entry "cn=schema,cn=config" ----------
The custom bits are indeed in the directory:
[root@mailhost man]# /opt/openldap/bin/ldapsearch -D cn=config -W -s sub -b cn=schema,cn=config -o ldif-wrap=no | egrep 'postfixUser|maildrop|mailacceptinggeneralid' Enter LDAP Password: olcAttributeTypes: {245}( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: {246}( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcObjectClasses: {49}( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop ))
slapschema thinks something is odd, although I can ldapsearch and retrieve entries with these attributes just fine:
[root@mailhost man]# /opt/openldap/sbin/slapschema -bdc=me -F/opt/openldap/etc/openldap/slapd.d 5ce5693b UNKNOWN attributeDescription "MAILACCEPTINGGENERALID" inserted. 5ce5693b UNKNOWN attributeDescription "MAILDROP" inserted. # (65) Object class violation: unrecognized objectClass 'postfixUser' dn: uid=mail1,dc=fake1.example,dc=me
# (65) Object class violation: unrecognized objectClass 'postfixUser' dn: cn=mail1@somedomain.com,dc=fake1.example,dc=me
slapcat only reports the attribute item, but not the objectClass item:
[root@mailhost man]# /opt/openldap/sbin/slapcat -bdc=me -F/opt/openldap/etc/openldap/slapd.d -l'/var/tmp/dc=me.ldif' 5ce55367 UNKNOWN attributeDescription "MAILACCEPTINGGENERALID" inserted. 5ce55367 UNKNOWN attributeDescription "MAILDROP" inserted.
For completeness, here's showing that the custom schema exists in the exports. Pardon the redactions, not listing people's names save for myself in a list post.
[root@mailhost man]# egrep -i 'postfixUser|maildrop|mailacceptinggeneralid' /var/tmp/dc=me.ldif | cut -d: -f1 objectClass MAILACCEPTINGGENERALID MAILACCEPTINGGENERALID MAILDROP MAILDROP objectClass MAILACCEPTINGGENERALID MAILACCEPTINGGENERALID MAILDROP MAILDROP
[root@mailhost man]# egrep -i 'postfixUser|maildrop|mailacceptinggeneralid' /var/tmp/cn=config.ldif olcAttributeTypes: {1}( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Pos olcObjectClasses: {0}( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'P ostfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ ma
--On Wednesday, May 22, 2019 12:51 PM -0400 Christopher Wood christopher_wood@pobox.com wrote:
Adding the custom schema went fine apart from the replication issue:
dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop ))
You did this wrong. You shouldn't be appending it to cn=schema, which is internal. You need to add it as its own schema object. I suggest looking at other schema objects such as inetOrgPerson, etc.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 5/22/19 6:02 PM, Quanah Gibson-Mount wrote:
--On Wednesday, May 22, 2019 12:51 PM -0400 Christopher Wood
Adding the custom schema went fine apart from the replication issue:
dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop ))
You did this wrong. You shouldn't be appending it to cn=schema, which is internal. You need to add it as its own schema object. I suggest looking at other schema objects such as inetOrgPerson, etc.
The 2nd thing which is asking for trouble is hijacking the OID space 1.3.6.1.4.1.4203.666 which will sooner or later clash with schema or other extensions defined by OpenLDAP project (the owner of the OID tree 1.3.6.1.4.1.4203).
Ciao, Michael.
Thank you, adding attributes directly to cn=schema,cn=config was my problem! No more schema issues now.
For posterity, and in case I managed to klutz something else, ahem:
---------- dn: cn=postfix,cn=schema,cn=config changetype: add cn: postfix objectClass: olcSchemaConfig olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop )) ----------
That did three things for me:
a) schema errors on slapcat/slapschema stopped b) postfix attributes no longer available from cn=schema,cn=config via ldapsearch c) fixed other slapd after replication
I had a look under the hood and the attributes still exist in cn=schema,cn=config. Removing a specific attribute is being a bit recalcitrant ("olcObjectClasses: no such value"), I will figure that out later. The attributes under cn=schema,cn=config are at least defanged.
Very much appreciate it!
openldap-technical@openldap.org
-
Christopher Wood -
Michael Ströder -
Quanah Gibson-Mount