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.