6:10 a.m.
Hello Fellow OpenLDAP Techs,
I'm having an issue with equality matching and slapd death (just another
day in the life of an LDAP guy...).
version info:
OpenLDAP: slapd 2.4.44
Red Hat Enterprise Linux Server release 7.5 (Maipo)
RH package: openldap-servers-2.4.44-15.el7_5.x86_64
While planning for a migration, I ran into the following error:
$ ldapmodify -x -y ~/.ldappw
dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com
changetype: modify
add: mailAlternateAddress
mailAlternateAddress: cs5555(a)test.com
[CTRL-D]
modifying entry "uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com"
ldap_modify: Inappropriate matching (18)
additional info: modify/add: mailAlternateAddress: no equality
matching rule
I tried to fix this by updating the schema to add "EQUALITY
caseIgnoreMatch" to the attribute definition for mailAlternateAddress.
dn: cn={5}inetLocalMailRecipient,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {5}inetLocalMailRecipient
olcAttributeTypes: {0}( 2.16.840.1.113730.3.1.24 NAME
'mailRoutingAddress' DES
C 'iPlanet defined attribute type' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 X-ORI
GIN 'iPlanet Messaging Server' )
olcAttributeTypes: {1}( 2.16.840.1.113730.3.1.18 NAME 'mailHost' DESC
'iPlanet
defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN
'iPlan
et Messaging Server' )
olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.13 NAME
'mailAlternateAddress' D
ESC 'iPlanet defined attribute type'EQUALITY caseIgnoreMatchSYNTAX
1.3.6.1.
4.1.1466.115.121.1.15 X-ORIGIN 'iPlanet Messaging Server' )
olcObjectClasses: {0}( 2.16.840.1.113730.3.2.4 NAME
'inetLocalMailRecipient' D
ESC 'iPlanet defined objectclass' AUXILIARY MAY ( mailAlternateAddress
$ mail
Host $ mailRoutingAddress ) X-ORIGIN 'iPlanet Messaging Server' )
Now, after the schema change, the same ldapmodify kills slapd.
$ ldapmodify -x -y ~/.ldappw
dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com
changetype: modify
add: mailAlternateAddress
mailAlternateAddress: cs5555(a)test.com
modifying entry "uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com"
ldap_result: Can't contact LDAP server (-1)
Trying this with slapd running with olcLogLevel=-1, I get the following
output before slapd death:
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
connection_get(11)
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
connection_get(11): got connid=1008
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
connection_read(11): checking for input on id=1008
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
op tag 0x60, time 1537906659
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
conn=1008 op=0 do_bind
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
>> dnPrettyNormal: <cn=manager,dc=test,dc=com>
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
<<< dnPrettyNormal: <cn=manager,dc=test,dc=com>,
<cn=manager,dc=test,dc=com>
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
conn=1008 op=0 BIND dn="cn=manager,dc=test,dc=com" method=128
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
do_bind: version=3 dn="cn=manager,dc=test,dc=com" method=128
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
==> hdb_bind: dn: cn=manager,dc=test,dc=com
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
conn=1008 op=0 BIND dn="cn=manager,dc=test,dc=com" mech=SIMPLE ssf=0
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
do_bind: v3 bind: "cn=manager,dc=test,dc=com" to
"cn=manager,dc=test,dc=com"
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
send_ldap_result: conn=1008 op=0 p=3
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
send_ldap_result: err=0 matched="" text=""
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
send_ldap_response: msgid=1 tag=97 err=0
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
conn=1008 op=0 RESULT tag=97 err=0 text=
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: activity on 1 descriptor
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: activity on:
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]:
slapd.service: main process exited, code=killed, status=6/ABRT
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]:
Unit slapd.service entered failed state.
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]:
slapd.service failed.
Does anyone have any insight into this issue? somehow I've never run
into this one before.
Many thanks,
CP
--
Rex ConsultingChris Paul
Rex Consulting, Inc
5652 Florence Terrace, Oakland, CA 94611
email: chris.paul(a)rexconsulting.net
web: http://www.rexconsulting.net
phone, toll-free: +1 (888) 403-8996 ext 1
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons
or entities other than the intended recipient is prohibited.
Rex Consulting, Inc. has been a California Corporation since 2001.
11:27 a.m.
One more detail: I know “replace” will work but “add” would be more convenient. Also,
python-ldap does not support ldap.MOD_REPLACE apparently.
CP
11:52 a.m.
I found a solution to this. I changed the syntax of mailAlternateAddress:
olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.13 NAME 'mailAlternateAddress' D
ESC 'iPlanet defined attribute type' EQUALITY caseIgnoreIA5Match SUBSTR cas
eIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} X-ORIG
IN 'iPlanet Messaging Server' )
Seems to work OK.
CP
4:40 p.m.
--On Wednesday, September 26, 2018 3:27 PM -0400 Chris Paul
<chris.paul(a)rexconsulting.net> wrote:
One more detail: I know "replace" will work but
"add" would be
more convenient. Also, python-ldap does not support ldap.MOD_REPLACE
apparently.
Python has certainly worked with it just fine in the past, and I doubt it
suddenly stopped, because that'd break a lot of python applications...
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6:09 p.m.
On 9/27/18 4:40 PM, Quanah Gibson-Mount wrote:
--On Wednesday, September 26, 2018 3:27 PM -0400 Chris Paul wrote:
> One more detail: I know "replace" will work but "add" would be
> more convenient. Also, python-ldap does not support ldap.MOD_REPLACE
> apparently.
Python has certainly worked with it just fine in the past, and I doubt
it suddenly stopped, because that'd break a lot of python applications...
--Quanah
Hi Quanah,
According to this link, replace is not done using LDAP_MOD_REPLACE:
https://www.python-ldap.org/en/latest/reference/ldap-modlist.html.
As it is written there, "Replacing attribute values is always done with
a ldap.MOD_DELETE/ldap.MOD_ADD pair instead of ldap.MOD_REPLACE to
work-around potential issues with attributes for which no EQUALITY
matching rule are defined in the server’s subschema. This works
correctly in most situations but rarely fails with some LDAP servers
implementing (schema) checks on transient state entry during processing
the modify operation."
I'm not sure I get that rationale, but it is apparently the case when
using python-ldap's LDAPObject.modify_s.
CP
6:53 p.m.
--On Thursday, September 27, 2018 7:09 PM -0700 Christopher Paul
<chris.paul(a)rexconsulting.net> wrote:
As it is written there, "Replacing attribute values is always
done with a
ldap.MOD_DELETE/ldap.MOD_ADD pair instead of ldap.MOD_REPLACE to
work-around potential issues with attributes for which no EQUALITY
matching rule are defined in the server's subschema. This works
correctly in most situations but rarely fails with some LDAP servers
implementing (schema) checks on transient state entry during processing
the modify operation."
And this strategy would work just fine, because it deletes all values
before doing the add. It's essentially what the REPLACE op does anyway.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
7:16 p.m.
On 9/27/18 6:53 PM, Quanah Gibson-Mount wrote:
And this strategy would work just fine, because it deletes all values
before doing
the add. It's essentially what the REPLACE op does anyway.
--Quanah
Well yeah it works now, after adding the EQUALITY rule to the
attribute(*). Can someone pls explain this to me? I'm not getting why
LDAP_MOD_REPLACE won't work without an EQUALITY rule.
Also, please note my original post on this thread. I just wanted to add
one attribute. It seems a lot more efficient, if I just want to add one
attribute (in this case to a multi-valued attribute) to be able to use
LDAP_MOD_ADD, instead of LDAP_MOD_REPLACE (or especially instead of
LDAP_MOD_DELETE/LDAP_MOD_ADD pair).
Now that I'm taking another look at the python-ldap docs, I realize that
maybe I could get my sole LDAP_MOD_ADD if I abandon trying to use the
python module "ldap.modlist". It seems that I could generate my own list
instead of using "ldap.modlist" to generate the list, and thus specify
ldap.MOD_ADD as the 1st element in the tuple.
(*) Note this is only a test environment. I don't really care about
breaking anything. If I were to change the schema in production, I'd go
to a lot more effort validating that it would not break anything (or
just plan on the LDIF export/import).
10:11 a.m.
--On Thursday, September 27, 2018 8:16 PM -0700 Christopher Paul
<chris.paul(a)rexconsulting.net> wrote:
Well yeah it works now, after adding the EQUALITY rule to the
attribute(*). Can someone pls explain this to me? I'm not getting why
LDAP_MOD_REPLACE won't work without an EQUALITY rule.
If you mean the python LDAP_MOD_REPLACE, it's entire purpose is to ensure
it works whether or not there is an EQUALITY rule (from what I read). If
that's not working right, you probably need to take that up with the
python-ldap folks.
Also, please note my original post on this thread. I just wanted to
add
one attribute. It seems a lot more efficient, if I just want to add one
attribute (in this case to a multi-valued attribute) to be able to use
LDAP_MOD_ADD, instead of LDAP_MOD_REPLACE (or especially instead of
LDAP_MOD_DELETE/LDAP_MOD_ADD pair).
If you read back on my earlier responses, you'll note I mentioned
"normalization" of the values.
Basic breakdown:
If an attribute is defined in the schema with an EQUALITY rule, then the
values get normalized.
If an attribute is defined in the schema without an EQUALITY rule, there
are no normalized values.
Case a: Normalized values
You can use changetype: modify + add to add value(s) to an attribute
because slapd has the knowledge with which to check for duplicate values
based on the EQUALITY rule.
Case b: No normalized values
You cannot use changetype: modify + add to add value(s) to an attribute
because slapd has no knowledge about whether or not there are duplicate
values. You must use changetype: modify + replace.
I.e., if I have:
dn: uid=joe,cn=people,dc=example,dc=com
mail: joe(a)example.com
And in this case "mail" has no EQUALITY rule, if I try to do:
dn: uid=joe,cn=people,dc=example,dc=com
changetype: modify
add: joe(a)example2.com
it will fail, because there are no normalized values that slapd can use to
ensure I'm not adding a duplicate to what already exists. Instead, I must
do:
dn: uid=joe,cn=people,dc=example,dc=com
changetype: modify
replace: mail
mail: joe(a)example.com
mail: joe(a)example2.com
Hope that helps.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
10:36 a.m.
On 9/28/18 7:11 PM, Quanah Gibson-Mount wrote:
--On Thursday, September 27, 2018 8:16 PM -0700 Christopher Paul
<chris.paul(a)rexconsulting.net> wrote:
> Well yeah it works now, after adding the EQUALITY rule to the
> attribute(*). Can someone pls explain this to me? I'm not getting why
> LDAP_MOD_REPLACE won't work without an EQUALITY rule.
If you mean the python LDAP_MOD_REPLACE, it's entire purpose is to
ensure it works whether or not there is an EQUALITY rule (from what I
read). If that's not working right, you probably need to take that up
with the python-ldap folks.
Since I'm the one who wrote this code I should probably comment on this:
1. You don't have to use ldap.modlist.modifyModlist() [1]. It's just
provided for convenience in case you have old and entries and want to
let it craft the modification list for you. Still you can directly pass
whatever modlist you want to LDAPObject.modify_s() and friends.
2. The MOD_DELETE for complete deletion of all attributes values with
subsequent MOD_ADD of the new attribute value list was done because I
ran into issues with attributes without EQUALITY matching rule. This is
a rather old topic and I forgot the details.
Ciao, Michael.
[1]
https://www.python-ldap.org/en/latest/reference/ldap-modlist.html#ldap.mo...
[2]
https://www.python-ldap.org/en/latest/reference/ldap.html#ldap.LDAPObject...
1:10 p.m.
On 9/28/18 10:11 AM, Quanah Gibson-Mount wrote:
If you read back on my earlier responses, you'll note I mentioned
"normalization" of the values.
Basic breakdown:
If an attribute is defined in the schema with an EQUALITY rule, then
the values get normalized.
If an attribute is defined in the schema without an EQUALITY rule,
there are no normalized values.
Case a: Normalized values
You can use changetype: modify + add to add value(s) to an attribute
because slapd has the knowledge with which to check for duplicate
values based on the EQUALITY rule.
Case b: No normalized values
You cannot use changetype: modify + add to add value(s) to an
attribute because slapd has no knowledge about whether or not there
are duplicate values. You must use changetype: modify + replace.
I.e., if I have:
dn: uid=joe,cn=people,dc=example,dc=com
mail: joe(a)example.com
And in this case "mail" has no EQUALITY rule, if I try to do:
dn: uid=joe,cn=people,dc=example,dc=com
changetype: modify
add: joe(a)example2.com
it will fail, because there are no normalized values that slapd can
use to ensure I'm not adding a duplicate to what already exists.
Instead, I must do:
dn: uid=joe,cn=people,dc=example,dc=com
changetype: modify
replace: mail
mail: joe(a)example.com
mail: joe(a)example2.com
Hope that helps.
--Quanah
Hi Quanah,
Yes that does help. Thank you. So now then based on our understanding
here, do you agree then that the best solution here is to update the
schema and then make sure the data is normalized, via export/import aka
slapcat/slapadd, and subsequent data manipulations (assuming the
feasibility) as needed?
CP
1:14 p.m.
--On Friday, September 28, 2018 2:10 PM -0700 Christopher Paul
<chris.paul(a)rexconsulting.net> wrote:
Hi Quanah,
Yes that does help. Thank you. So now then based on our understanding
here, do you agree then that the best solution here is to update the
schema and then make sure the data is normalized, via export/import aka
slapcat/slapadd, and subsequent data manipulations (assuming the
feasibility) as needed?
Hi Chris,
As long as it's not an RFC defined schema, then yes, I would suggest
modifying it to suit your needs and then exporting/importing the data.
However, I would keep this in mind for any applications you're developing
if they will be using any RFC defined schema that do not have matching
rules defined to ensure they can handle this case correctly.
Warm regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2 p.m.
On 9/28/18 10:14 PM, Quanah Gibson-Mount wrote:
--On Friday, September 28, 2018 2:10 PM -0700 Christopher Paul
<chris.paul(a)rexconsulting.net> wrote:
> Yes that does help. Thank you. So now then based on our understanding
> here, do you agree then that the best solution here is to update the
> schema and then make sure the data is normalized, via export/import aka
> slapcat/slapadd, and subsequent data manipulations (assuming the
> feasibility) as needed?
As long as it's not an RFC defined schema, then yes, I would suggest
modifying it to suit your needs and then exporting/importing the data.
However, I would keep this in mind for any applications you're
developing if they will be using any RFC defined schema that do not have
matching rules defined to ensure they can handle this case correctly.
Thus I'd consider any attribute type description with non-binary syntax
but without EQUALITY matching rule to be worth an errata for this RFC.
It's a real pity that we didn't manage to resurrect ldapext WG.
This would be also a useful work item.
Ciao, Michael.
2:17 p.m.
Hi Chris,
--On Wednesday, September 26, 2018 10:10 AM -0400 Christopher Paul
<chris.paul(a)rexconsulting.net> wrote:
While planning for a migration, I ran into the following error:
ldap_modify: Inappropriate matching (18)
additional info: modify/add: mailAlternateAddress: no
equality matching rule
That's not an error. You should have done a changetype: replace rather
than changetype: modify since it has no matching rule. This has been
covered multiple times on the list over the years.
For example:
<http://www.openldap.org/lists/openldap-technical/201602/msg00132.html>
<https://www.openldap.org/lists/openldap-technical/201106/msg00190.html>
I tried to fix this by updating the schema to add "EQUALITY
caseIgnoreMatch" to the attribute definition for mailAlternateAddress.
Generally not a good idea if you have any existing data using this
attribute in your database.
olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.13 NAME
'mailAlternateAddress' D
ESC 'iPlanet defined attribute type'EQUALITY caseIgnoreMatchSYNTAX
1.3.6.1.
4.1.1466.115.121.1.15 X-ORIGIN 'iPlanet Messaging Server' )
You appear to be missing a space between the EQUALITY rule and SYNTAX.
Now, after the schema change, the same ldapmodify kills slapd.
If you already have entries in your database using that attribute, this may
be expected since the attribute now requires normalization due to the added
matching rule. You'd want to dump/reload your database via slapcat/slapadd
now that you've modified the schema for that attribute. I'd generally
advise not modifying the schema and using the correct steps to modify the
attribute.
Warm regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2:22 p.m.
--On Wednesday, September 26, 2018 3:17 PM -0700 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
That's not an error. You should have done a changetype: replace
rather
than changetype: modify since it has no matching rule. This has been
covered multiple times on the list over the years.
Err, changetype: modify with a replace action instead of an add action,
even. ;)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2:31 p.m.
On 9/26/18 11:22 PM, Quanah Gibson-Mount wrote:
--On Wednesday, September 26, 2018 3:17 PM -0700 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
> That's not an error. You should have done a changetype: replace rather
> than changetype: modify since it has no matching rule. This has been
> covered multiple times on the list over the years.
Err, changetype: modify with a replace action instead of an add action,
even. ;)
You're right. But back-config should not have accepted the add-value
operation before which probably resulted in a non-unique attribute
description in the subschema. :-/
Ciao, Michael.
2:52 p.m.
--On Thursday, September 27, 2018 12:31 AM +0200 Michael Ströder
<michael(a)stroeder.com> wrote:
You're right. But back-config should not have accepted the
add-value
operation before which probably resulted in a non-unique attribute
description in the subschema. :-/
Hi Michael,
The add was on a user entry:
dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com
not in cn=config.
I'm not sure what was done to modify the schema entry.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5:02 p.m.
On 9/26/18 11:52 PM, Quanah Gibson-Mount wrote:
--On Thursday, September 27, 2018 12:31 AM +0200 Michael Ströder
<michael(a)stroeder.com> wrote:
> You're right. But back-config should not have accepted the add-value
> operation before which probably resulted in a non-unique attribute
> description in the subschema. :-/
The add was on a user entry:
dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com
not in cn=config.
I'm not sure what was done to modify the schema entry.
Ah, you're right. But slapd should not have crashed during that operation.
@Chris: Could you reproduce all that with a recent OpenLDAP release?
Ciao, Michael.
5:41 p.m.
Michael Ströder wrote:
On 9/26/18 11:52 PM, Quanah Gibson-Mount wrote:
> --On Thursday, September 27, 2018 12:31 AM +0200 Michael Ströder
> <michael(a)stroeder.com> wrote:
>
>> You're right. But back-config should not have accepted the add-value
>> operation before which probably resulted in a non-unique attribute
>> description in the subschema. :-/
>
> The add was on a user entry:
>
> dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com
>
> not in cn=config.
>
> I'm not sure what was done to modify the schema entry.
Ah, you're right. But slapd should not have crashed during that operation.
We still like to assert() on nonsensical results, as occurred in this guy's log.
@Chris: Could you reproduce all that with a recent OpenLDAP release?
Ciao, Michael.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:45 p.m.
--On Thursday, September 27, 2018 3:02 AM +0200 Michael Ströder
<michael(a)stroeder.com> wrote:
Ah, you're right. But slapd should not have crashed during that
operation.
@Chris: Could you reproduce all that with a recent OpenLDAP release?
As I noted, adding an EQUALITY rule to the attribute schema definition when
it didn't have one prior means that the data for that attribute now has to
have normalized values stored in the database, regardless of whether or not
it is indexed. Schema changes when there is existing data can require a
database reload for the system to function properly afterwards. Thus the
reason an assert() was triggered and slapd exited (correctly).
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
11:06 p.m.
New subject: Antw: Re: issues with equality matching and slapd death
>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am
27.09.2018 um 02:45 in
Nachricht <C7915030A7A58C6F89027FDC(a)[192.168.1.39]>:
--On Thursday, September 27, 2018 3:02 AM +0200 Michael Ströder
<michael(a)stroeder.com> wrote:
> Ah, you're right. But slapd should not have crashed during that operation.
>
> @Chris: Could you reproduce all that with a recent OpenLDAP release?
As I noted, adding an EQUALITY rule to the attribute schema definition when
it didn't have one prior means that the data for that attribute
now has to
have normalized values stored in the database, regardless of whether or not
it is indexed. Schema changes when there is existing data can
require a
database reload for the system to function properly afterwards. Thus the
reason an assert() was triggered and slapd exited (correctly).
Would it be very complicated to implement a check before committing such a
schema change (assuming the change was done during runtime); if the change was
done offline, could it be checked during startup?
I think using assert()s is to detect programming errors. If something isn't
implemented or supported, there should be a helpful message before quitting.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
12:55 a.m.
On 9/27/18 2:45 AM, Quanah Gibson-Mount wrote:
--On Thursday, September 27, 2018 3:02 AM +0200 Michael Ströder
<michael(a)stroeder.com> wrote:
> Ah, you're right. But slapd should not have crashed during that
> operation.
>
> @Chris: Could you reproduce all that with a recent OpenLDAP release?
As I noted, adding an EQUALITY rule to the attribute schema definition
when it didn't have one prior means that the data for that attribute now
has to have normalized values stored in the database, regardless of
whether or not it is indexed. Schema changes when there is existing
data can require a database reload for the system to function properly
afterwards. Thus the reason an assert() was triggered and slapd exited
(correctly).
But IMO this completely defeats the availability promise of back-config.
Ciao, Michael.
10:53 p.m.
New subject: Antw: issues with equality matching and slapd death
>> Christopher Paul <chris.paul(a)rexconsulting.net> schrieb
am 26.09.2018 um 15:10
in Nachricht
<f23d83db-f263-63d6-cbcf-34b23ed462a0(a)rexconsulting.net>:
Hello Fellow OpenLDAP Techs,
I'm having an issue with equality matching and slapd death (just another
day in the life of an LDAP guy...).
version info:
OpenLDAP: slapd 2.4.44
Red Hat Enterprise Linux Server release 7.5 (Maipo)
RH package: openldap-servers-2.4.44-15.el7_5.x86_64
While planning for a migration, I ran into the following error:
$ ldapmodify -x -y ~/.ldappw
dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com
changetype: modify
add: mailAlternateAddress
mailAlternateAddress: cs5555(a)test.com
[CTRL-D]
modifying entry "uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com"
ldap_modify: Inappropriate matching (18)
additional info: modify/add: mailAlternateAddress: no equality
matching rule
I tried to fix this by updating the schema to add "EQUALITY
caseIgnoreMatch" to the attribute definition for mailAlternateAddress.
dn: cn={5}inetLocalMailRecipient,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {5}inetLocalMailRecipient
olcAttributeTypes: {0}( 2.16.840.1.113730.3.1.24 NAME
'mailRoutingAddress' DES
C 'iPlanet defined attribute type' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 X-ORI
GIN 'iPlanet Messaging Server' )
olcAttributeTypes: {1}( 2.16.840.1.113730.3.1.18 NAME 'mailHost' DESC
'iPlanet
defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN
'iPlan
et Messaging Server' )
olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.13 NAME
'mailAlternateAddress' D
ESC 'iPlanet defined attribute type'EQUALITY caseIgnoreMatchSYNTAX
1.3.6.1.
4.1.1466.115.121.1.15 X-ORIGIN 'iPlanet Messaging Server' )
olcObjectClasses: {0}( 2.16.840.1.113730.3.2.4 NAME
'inetLocalMailRecipient' D
ESC 'iPlanet defined objectclass' AUXILIARY MAY ( mailAlternateAddress
$ mail
Host $ mailRoutingAddress ) X-ORIGIN 'iPlanet Messaging Server' )
Now, after the schema change, the same ldapmodify kills slapd.
$ ldapmodify -x -y ~/.ldappw
dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com
changetype: modify
add: mailAlternateAddress
mailAlternateAddress: cs5555(a)test.com
modifying entry "uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com"
ldap_result: Can't contact LDAP server (-1)
Trying this with slapd running with olcLogLevel=-1, I get the following
output before slapd death:
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
connection_get(11)
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
connection_get(11): got connid=1008
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
connection_read(11): checking for input on id=1008
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
op tag 0x60, time 1537906659
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
conn=1008 op=0 do_bind
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
>>> dnPrettyNormal: <cn=manager,dc=test,dc=com>
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
<<< dnPrettyNormal: <cn=manager,dc=test,dc=com>,
<cn=manager,dc=test,dc=com>
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
conn=1008 op=0 BIND dn="cn=manager,dc=test,dc=com" method=128
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
do_bind: version=3 dn="cn=manager,dc=test,dc=com" method=128
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
==> hdb_bind: dn: cn=manager,dc=test,dc=com
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
conn=1008 op=0 BIND dn="cn=manager,dc=test,dc=com" mech=SIMPLE ssf=0
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
do_bind: v3 bind: "cn=manager,dc=test,dc=com" to
"cn=manager,dc=test,dc=com"
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
send_ldap_result: conn=1008 op=0 p=3
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
send_ldap_result: err=0 matched="" text=""
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
send_ldap_response: msgid=1 tag=97 err=0
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
conn=1008 op=0 RESULT tag=97 err=0 text=
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: activity on 1 descriptor
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: activity on:
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]:
daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]:
slapd.service: main process exited, code=killed, status=6/ABRT
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]:
Unit slapd.service entered failed state.
Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]:
slapd.service failed.
Does anyone have any insight into this issue? somehow I've never run
into this one before.
Hi!
My guess is that SIGABRT is triggered ny a failed assert(). Also when core dumps
aren't disabled you should get a core dump which will be quite helpful, especially if
you have debug symbols for the binary.
Regards,
Ulrich
Many thanks,
CP
--
Rex ConsultingChris Paul
Rex Consulting, Inc
5652 Florence Terrace, Oakland, CA 94611
email: chris.paul(a)rexconsulting.net
web: http://www.rexconsulting.net
phone, toll-free: +1 (888) 403-8996 ext 1
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons
or entities other than the intended recipient is prohibited.
Rex Consulting, Inc. has been a California Corporation since 2001.
1822
days inactive
1824
days old
openldap-technical@openldap.org
22 comments
6 participants
participants (6)
-
Chris Paul -
Christopher Paul
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl