[Date Prev][Date Next] [Chronological] [Thread] [Top]

Antw: issues with equality matching and slapd death



>>> 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 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.

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.