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