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: [email protected],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
