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@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@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
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
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
--On Wednesday, September 26, 2018 3:27 PM -0400 Chris Paul chris.paul@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
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
--On Thursday, September 27, 2018 7:09 PM -0700 Christopher Paul chris.paul@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
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).
--On Thursday, September 27, 2018 8:16 PM -0700 Christopher Paul chris.paul@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@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@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@example.com mail: joe@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
On 9/28/18 7:11 PM, Quanah Gibson-Mount wrote:
--On Thursday, September 27, 2018 8:16 PM -0700 Christopher Paul chris.paul@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.modli...
[2] https://www.python-ldap.org/en/latest/reference/ldap.html#ldap.LDAPObject.mo...
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@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@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@example.com mail: joe@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
--On Friday, September 28, 2018 2:10 PM -0700 Christopher Paul chris.paul@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
On 9/28/18 10:14 PM, Quanah Gibson-Mount wrote:
--On Friday, September 28, 2018 2:10 PM -0700 Christopher Paul chris.paul@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.
Hi Chris,
--On Wednesday, September 26, 2018 10:10 AM -0400 Christopher Paul chris.paul@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
--On Wednesday, September 26, 2018 3:17 PM -0700 Quanah Gibson-Mount quanah@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
On 9/26/18 11:22 PM, Quanah Gibson-Mount wrote:
--On Wednesday, September 26, 2018 3:17 PM -0700 Quanah Gibson-Mount quanah@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.
--On Thursday, September 27, 2018 12:31 AM +0200 Michael Ströder michael@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
On 9/26/18 11:52 PM, Quanah Gibson-Mount wrote:
--On Thursday, September 27, 2018 12:31 AM +0200 Michael Ströder michael@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.
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@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.
--On Thursday, September 27, 2018 3:02 AM +0200 Michael Ströder michael@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
Quanah Gibson-Mount quanah@symas.com schrieb am 27.09.2018 um 02:45 in
Nachricht <C7915030A7A58C6F89027FDC@[192.168.1.39]>:
--On Thursday, September 27, 2018 3:02 AM +0200 Michael Ströder michael@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
On 9/27/18 2:45 AM, Quanah Gibson-Mount wrote:
--On Thursday, September 27, 2018 3:02 AM +0200 Michael Ströder michael@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.
Christopher Paul chris.paul@rexconsulting.net schrieb am 26.09.2018 um 15:10
in Nachricht f23d83db-f263-63d6-cbcf-34b23ed462a0@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@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 equalitymatching 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@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@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.
openldap-technical@openldap.org
-
Chris Paul -
Christopher Paul
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl