8:51 a.m.
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(a)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
9:02 a.m.
--On Wednesday, May 22, 2019 12:51 PM -0400 Christopher Wood
<christopher_wood(a)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>
9:14 a.m.
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.
10:08 a.m.
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!
1405
days inactive
1405
days old
openldap-technical@openldap.org
3 comments
3 participants
participants (3)
-
Christopher Wood -
Michael Ströder -
Quanah Gibson-Mount