>>> Christopher Paul <[email protected]> schrieb am 26.09.2018 um >>> 15:10 in Nachricht <[email protected]>: > 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: [email protected] > > [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: [email protected] > > 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: [email protected] > 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.
