- openldap-bugs - openldap.org

(ITS#8498) slapadd complains about missing attrs
by quanah＠openldap.org 09 Sep '16

09 Sep '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44+ITS8432 OS: Linux 3.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) When slapadding a database rooted at "" on a replica, it outputs the following warning: zimbra@zre-ldap014:~$ time ./libexec/zmslapadd /home/build/ldap.bak.20160909144406 57d32561 slapadd: warning, missing attrs entryUUID,entryCSN from entry dn="" -######## 42.58% eta 01m39s elapsed 01m13s spd 292.8 k/s Interestingly enough, when slapadded to a master with cn=accesslog in play, it doesn't output anything: zimbra@zre-ldap008:~$ ./libexec/zmslapadd /home/build/ldap.bak.20160909144406 *#################### 100.00% eta none elapsed 02m45s spd 3.1 M/s Closing DB... I'd generally expect the warning to be consistently shown (or not). I don't think it's valid in the case of "".

1 0

Re: (ITS#8490) changes not written to accesslog, causing replicas to loop syncing
by quanah＠zimbra.com 09 Sep '16

09 Sep '16

--On Thursday, September 01, 2016 9:50 AM +0000 quanah(a)zimbra.com wrote: I finally was able to reproduce this in a new lab of servers I set up. The easiest way to reproduce this problem is to have 2 masters, and 6 replicas. 3 replicas pointing to each master. In my case, I have ldap07 through ldap014. 07/08 are the masters. Odd number replicas (9,11,13) point to 07, even number replicas point to 08 (10, 12, 14). What we find based on the logs is two MODRDNs coming in at approximately the same time: Sep 9 15:29:40 zre-ldap007 slapd[13794]: conn=1389 op=3179 MODRDN dn="uid=user.345,ou=people,dc=zre-ldap007,dc=eng,dc=zimbra,dc=com" Sep 9 15:29:40 zre-ldap007 slapd[13794]: conn=1120 op=2919 MODRDN dn="uid=user.250404,ou=people,dc=zre-ldap007,dc=eng,dc=zimbra,dc=com" Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_queue_csn: queueing 0xa046e80 20160909192940.809794Z#000000#001#000000 Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_queue_csn: queueing 0xa046a40 20160909192940.809794Z#000000#001#000000 Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_queue_csn: queueing 0xa07b740 20160909192940.810205Z#000000#001#000000 Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_graduate_commit_csn: removing 0xa046a40 20160909192940.809794Z#000000#001#000000 Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_queue_csn: queueing 0xa07bdc0 20160909192940.810205Z#000000#001#000000 Sep 9 15:29:40 zre-ldap007 slapd[13794]: conn=1389 op=3179 RESULT tag=109 err=0 etime=0.001278 text= Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_graduate_commit_csn: removing 0xa046e80 20160909192940.809794Z#000000#001#000000 Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_graduate_commit_csn: removing 0xa07bdc0 20160909192940.810205Z#000000#001#000000 Sep 9 15:29:40 zre-ldap007 slapd[13794]: conn=1120 op=2919 RESULT tag=109 err=0 etime=0.001597 text= Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_graduate_commit_csn: removing 0xa07b740 20160909192940.810205Z#000000#001#000000 But in the accesslog, we only find the one MODRDN logged: dn: reqStart=20160909192940.809465Z,cn=accesslog objectClass: auditModRDN structuralObjectClass: auditModRDN reqStart: 20160909192940.809465Z reqEnd: 20160909192940.810148Z reqType: modrdn reqSession: 1389 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=user.345,ou=people,dc=zre-ldap007,dc=eng,dc=zimbra,dc=com reqResult: 0 reqMod: entryCSN:= 20160909192940.809794Z#000000#001#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20160909192940Z reqNewRDN: uid=renamed-user.345 reqDeleteOldRDN: TRUE reqEntryUUID: c63b246a-0a20-1036-82cb-a772509d7f53 entryUUID: 7f740e6c-0b0f-1036-8c00-b1b4f08a59fc creatorsName: cn=config createTimestamp: 20160909192940Z entryCSN: 20160909192940.809794Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20160909192940Z Possibly a DN collision in writing the entry to the accesslog DB that causes the second OP to get lost. Likely the same root issue as ITS#8493. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8497) userPassword attribute in password policy
by quanah＠zimbra.com 09 Sep '16

09 Sep '16

--On Friday, September 09, 2016 3:38 PM +0000 sagar437(a)gmail.com wrote: > Full_Name: Sagar Bhattarai > Version: 2.4.40-9 > OS: CentOS Linux release 7.2.1511 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.174.102.218) The ITS system is for reporting bugs, not asking usage questions. Questions should be sent to the openldap-technical(a)openldap.org email list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8497) userPassword attribute in password policy
by sagar437＠gmail.com 09 Sep '16

09 Sep '16

Full_Name: Sagar Bhattarai Version: 2.4.40-9 OS: CentOS Linux release 7.2.1511 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.174.102.218) I am trying to push the password policy with the following content of ldif file. dn: cn=passwordDefault4,ou=policy,dc=vivox,dc=com objectClass: pwdPolicy objectclass: device objectClass: top cn: passwordDefault4 pwdAttribu%3: userPassword pwdCheckQuality: 0 pwdMinAge: 0 pwdMaxAge: 0 pwdMinLength: 5 pwdInHistory: 5 pwdMaxFailure: 3 pwdFailureCountInterval: 0 pwdLockout: TRUE pwdLockoutDuration: 0 pwdAllowUserChange: TRUE pwdExpireWarning: 0 pwdGraceAuthNLimit: 0 pwdMustChange: TRUE pwdSafeModify: TRUE I keep getting the following error when trying to add the above policy. ldap_add: Invalid syntax (21) additional info: pwdAttribute: value #0 invalid per syntax However id i change the pwdattribute vae frfrom "userPassword" to OID number i am able to add this policy but none of these policies work on my systems.

1 0

Re: (ITS#8495) slaped service unable to restart
by quanah＠zimbra.com 09 Sep '16

09 Sep '16

--On Friday, September 09, 2016 8:34 AM +0000 ritesh.s(a)litmusit.com wrote: > Full_Name: Ritesh Supatkar > Version: Openldap-2.4.40 > OS: Rhel 7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.14.160.193) This looks like an issue with systemd and Redhat. I advise contacting Redhat support. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8496) Error while launching LDAP
by quanah＠zimbra.com 09 Sep '16

09 Sep '16

--On Friday, September 09, 2016 8:56 AM +0000 kshtijdasture(a)gmail.com wrote: > Full_Name: Kshitij Dasture > Version: 2.4.41 > OS: Windos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.99.214.118) > > > I am starting the LAP by the below command.Below is the show stopper for > the execution of Start command. > > > -bash-4.3$ ./slapd -f slapd.conf -d 1 > ldap.log The ITS system is for reporting bugs, not usage questions. If you have questions on how to use OpenLDAP correctly, please use the openldap-technical list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8496) Error while launching LDAP
by kshtijdasture＠gmail.com 09 Sep '16

09 Sep '16

Full_Name: Kshitij Dasture Version: 2.4.41 OS: Windos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.99.214.118) I am starting the LAP by the below command.Below is the show stopper for the execution of Start command. -bash-4.3$ ./slapd -f slapd.conf -d 1 > ldap.log . . . 57d25b6b backend_startup_one: starting "dc=gnf,dc=telekom,dc=m%m" 57d25b6b bdb_db_open: database "dc=gnf,dc=telekom,dc=com": database already in use. 57d25b6b backend_startup_one (type=bdb, suffix="dc=gnf,dc=telekom,dc=com"): bi_db_open failed! (-1) 57d25b6b slapd shutdown: initiated 57d25b6b ====> bdb_cache_release_all 57d25b6b slapd destroy: freeing system resources. 57d25b6b slapd stopped. -bash-4.3$

1 0

(ITS#8495) slaped service unable to restart
by ritesh.s＠litmusit.com 09 Sep '16

09 Sep '16

Full_Name: Ritesh Supatkar Version: Openldap-2.4.40 OS: Rhel 7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.14.160.193) [bbpsadm@hydbbpsldp01 ~]$ sudo systemctl status slapd ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: active (running) since Thu 20169-9-08 18:18:20 IST; 18h ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 44574 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 44531 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 44575 (slapd) CGroup: /system.slice/slapd.service └6%6#9472;44575 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: <= bdb_equality_candidates: (uid) not indexed Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 09 12:34:45 hydbbpsl0101 slapd[47575]: conn=1020 op=2 SRCH base="dc=npci,dc=co,dc=in" scope=2 deref=0 filter="(&(memberUid=bbpsadm)(objectClass=posixGr...ber=0))))" Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=2 SRCH attr=objectClass cn userPassword gidNumber modifyTimestamp modifyTimestamp Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: <= bdb_equality_candidates: (memberUid) not indexed Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=3 SRCH base="dc=npci,dc=co,dc=in" scope=2 deref=0 filter="(&(gidNumber=1001)(objectClass=posixGroup...ber=0))))" Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=3 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: <= bdb_equality_candidates: (gidNumber) not indexed Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=3 SEARCH RESULT tag=101 err=0 nentries=2 text= Hint: Some lines were ellipsized, use -l to show in full. [bbpsadm@hydbbpsldp01 ~]$ [bbpsadm@hydbbpsldp01 ~]$ sudo systemctl restart slapd Error getting authority: Error initializing authority: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An SELinux policy prevents thisesender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus) (g-dbus-error-quark, 9) [bbpsadm@hydbbpsldp01 ~]$

1 0

(ITS#8494) doc: Rename 'TLSEphemeralDHParamFile' to 'TLSDHParamFile'
by georg＠riseup.net 08 Sep '16

08 Sep '16

Full_Name: Georg Faerber Version: 2.4 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.64.110.191) http://www.openldap.org/doc/admin24/tls.html mentions directive 'TLSEphemeralDHParamFile' whereas slapd.conf(5) mentions 'TLSDHParamFile'. (See [1] as well). [1] http://www.openldap.org/lists/openldap-technical/201309/msg00094.html

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 07 Sep '16

07 Sep '16

Actually, ignore me this is still connecting when it should fail. Don't close. ;)

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 07 Sep '16

07 Sep '16

This seems to have been resolved at some point in the past in one of the updates: now functions as expected. Fine to close from my perspective.

1 0

Re: (ITS#8493) Under heavy modrdn load, masters desync
by quanah＠zimbra.com 03 Sep '16

03 Sep '16

--On Saturday, September 03, 2016 4:51 PM +0000 quanah(a)zimbra.com wrote: > --On Saturday, September 03, 2016 6:15 AM +0000 quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.44+ITS8432 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.52.177) >> >> >> Trying to reproduce another ITS, I discovered a new bug. When doing >> MODRDN ops on one master, the other master keeps going out of sync. >> Specifically: >> >> Sep 3 01:12:17 zre-ldap002 slapd[29206]: syncrepl_message_to_op: rid=100 >> be_modrdn uid=user.924,ou=people,dc=zre-ldap002,dc=eng,dc=zimbra,dc=com >> (32) Sep 3 01:12:17 zre-ldap002 slapd[29206]: do_syncrep2: rid=100 >> delta-sync lost sync on (reqStart=20160903051215.747829Z,cn=accesslog), >> switching to REFRESH > > > Note that this master also has a replica. The replica never rejected a > single one of these MODRDNs coming from this master. Which means that > either: > > a) The data on the master spontaneously corrupted at some point > > or > > b) The master wrote the MODRDNs to the accesslog, which the replica > picked up, but did not itself make the MODRDN changes to its database. > > In the end, of the 50,000 MODRDNs it was processing, it threw an error 32 > for 441 of them. After the master that was not accepting direct writes re-sync'd with the master accepting writes, it still had 403/50000 entries wrong. So did its replica. So the master isn't writing the changes to the accesslog. So it's option c. The master rejects a valid op, never sync's correctly, and in the end 2/3rds of my servers have invalid databases. I see zero indication that using a sessionlog works around <http://www.openldap.org/its/index.cgi/?findid=8125> at all. I still end up with missed entries even with everything *in* the sessionlog. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8493) Under heavy modrdn load, masters desync
by quanah＠zimbra.com 03 Sep '16

03 Sep '16

--On Saturday, September 03, 2016 6:15 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44+ITS8432 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > Trying to reproduce another ITS, I discovered a new bug. When doing > MODRDN ops on one master, the other master keeps going out of sync. > Specifically: > > Sep 3 01:12:17 zre-ldap002 slapd[29206]: syncrepl_message_to_op: rid=100 > be_modrdn uid=user.924,ou=people,dc=zre-ldap002,dc=eng,dc=zimbra,dc=com > (32) Sep 3 01:12:17 zre-ldap002 slapd[29206]: do_syncrep2: rid=100 > delta-sync lost sync on (reqStart=20160903051215.747829Z,cn=accesslog), > switching to REFRESH Note that this master also has a replica. The replica never rejected a single one of these MODRDNs coming from this master. Which means that either: a) The data on the master spontaneously corrupted at some point or b) The master wrote the MODRDNs to the accesslog, which the replica picked up, but did not itself make the MODRDN changes to its database. In the end, of the 50,000 MODRDNs it was processing, it threw an error 32 for 441 of them. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8486) Syncprov sessionlog is inefficient, kills perf
by quanah＠zimbra.com 03 Sep '16

03 Sep '16

--On Monday, August 29, 2016 9:16 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) In doing testing for ITS#8491, I encountered this problem in my lab. Any time a single replica is parsing the session log, all other operations on the server come to a complete halt. I.e., slapd does *nothing* other than handle the sessionlog query. This seems like a fatal problem. --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8493) Under heavy modrdn load, masters desync
by quanah＠openldap.org 03 Sep '16

03 Sep '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44+ITS8432 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) Trying to reproduce another ITS, I discovered a new bug. When doing MODRDN ops on one master, the other master keeps going out of sync. Specifically: Sep 3 01:12:17 zre-ldap002 slapd[29206]: syncrepl_message_to_op: rid=100 be_modrdn uid=user.924,ou=people,dc=zre-ldap002,dc=eng,dc=zimbra,dc=com (32) Sep 3 01:12:17 zre-ldap002 slapd[29206]: do_syncrep2: rid=100 delta-sync lost sync on (reqStart=20160903051215.747829Z,cn=accesslog), switching to REFRESH

1 0

RE: (ITS#8492) signal 11 in ldap_new_connection
by quanah＠zimbra.com 02 Sep '16

02 Sep '16

--On Friday, September 02, 2016 7:35 AM +0000 htjain(a)sandvine.com wrote: > After some more debugging looks like ld->ldc->ldc_options.ldo_defludp > varia= ble is causing this issue, its null when its passed to > ldap_new_connection. How does it populated? Please confirm your encounter the issue with a current release. 2.4.40 and 2.4.41 both had significant issues. --Quanah -- Quanah Gibson-Mount

1 0

RE: (ITS#8492) signal 11 in ldap_new_connection
by htjain＠sandvine.com 02 Sep '16

02 Sep '16

After some more debugging looks like ld->ldc->ldc_options.ldo_defludp varia= ble is causing this issue, its null when its passed to ldap_new_connection. How does it populated? (gdb) p ld->ldc->ldc_options $13 =3D {ldo_valid =3D 255, ldo_debug =3D 0, ldo_version =3D 3, ldo_deref = =3D 0, ldo_timelimit =3D 0, ldo_sizelimit =3D 0, ldo_tm_api =3D {tv_sec =3D= -1, tv_usec =3D 0}, ldo_tm_net =3D {tv_sec =3D 5, tv_usec =3D 0}, ldo_defl= udp =3D 0x0, ldo_defport =3D 389, ldo_defbase =3D 0x0, ldo_defbinddn =3D 0x0, ldo_keepalive_idle =3D 0, ldo= _keepalive_probes =3D 0, ldo_keepalive_interval =3D 0, ldo_refhoplimit =3D = 5, ldo_sctrls =3D 0x0, ldo_cctrls =3D 0x0, ldo_rebind_proc =3D 0x0, ldo_reb= ind_params =3D 0x0, ldo_nextref_proc =3D 0x0, ldo_nextref_params =3D 0x0, ldo_urllist_proc = =3D 0x0, ldo_urllist_params =3D 0x0, ldo_conn_cbs =3D 0x0, ldo_booleans =3D= 34, ldo_peer =3D 0x0, ldo_cldapdn =3D 0x0, ldo_is_udp =3D 0, ldo_tls_ctx = =3D 0x0, ldo_tls_connect_cb =3D 0x0, ldo_tls_connect_arg =3D 0x0, ldo_tls_info =3D= {lt_certfile =3D 0x0, lt_keyfile =3D 0x0, lt_dhfile =3D 0x0, lt_cacertfile= =3D 0x0, lt_cacertdir =3D 0x0, lt_ciphersuite =3D 0x0, lt_crlfile =3D 0x0,= lt_randfile =3D 0x0, lt_protocol_min =3D 0}, ldo_tls_mode =3D 0, ldo_tls_require_cert =3D 2,= ldo_tls_impl =3D 0, ldo_tls_crlcheck =3D 0, ldo_def_sasl_mech =3D 0x0, ldo= _def_sasl_realm =3D 0x0, ldo_def_sasl_authcid =3D 0x0, ldo_def_sasl_authzid= =3D 0x0, ldo_sasl_secprops =3D {min_ssf =3D 0, max_ssf =3D 2147483647, maxbufsize = =3D 16777215, security_flags =3D 17, property_names =3D 0x0, property_value= s =3D 0x0}} (gdb) p ld->ldc->ldc_options.ldo_defludp $14 =3D (LDAPURLDesc *) 0x0 -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Friday, September 2, 2016 11:50 AM To: Hemant Jain Subject: Re: (ITS#8492) signal 11 in ldap_new_connection *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report = has been assigned the tracking number ITS#8492. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunte= ers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue repo= rt, you may do so by replying to this message. Note that any mail sent to = openldap-its(a)openldap.org with (ITS#8492) in the subject will automatically= be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#8492) You may follow the progress of this report by loading the following URL in = a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D8492 Please remember to retain your issue tracking number (ITS#8492) on any furt= her messages you send to us regarding this report. If you don't then you'l= l just waste our time and yours because we won't be able to properly track = the report. Please note that the Issue Tracking System is not intended to be used to se= ek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#8492) signal 11 in ldap_new_connection
by htjain＠sandvine.com 02 Sep '16

02 Sep '16

Full_Name: hemant jain Version: openldap-2.4.40-8 OS: RHEL 7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.63.202.166) Hi, We are facing a strange core dump in ldap_new_connection function while trying to bind a stopped Openldap server. following is the stack trace: #0 0x00007f9336898f53 in ldap_new_connection (ld=ld@entry=0x7f931f43cd60, srvlist=srvlist@entry=0x7f931f48b298, use_ldsb=use_ldsb@entry=1, connect=connect@entry=1, bind=bind@entry=0x0, m_req=m_req@entry=0, m_res=m_res@entry=0) at request.c:481 #1 0x00007f933688530f in ldap_open_defconn (ld=ld@entry=0x7f931f43cd60) at open.c:41 #2 0x00007f933689a248 in ldap_send_initial_request (ld=ld@entry=0x7f931f43cd60, msgtype=msgtype@entry=96, dn=dn@entry=0x7f931f827718 "cn=Manager,dc=test,dc=com", ber=ber@entry=0x7f931f457150, msgid=msgid@entry=1) at request.c:130 #3 0x00007f933688f178 in ldap_sasl_bind (ld=0x7f931f43cd60, dn=0x7f931f827718 "cn=Manager,dc=test,dc=com", mechanism=<optimized out>, cred=0x7f931f4296b0, sctrls=0x0, cctrls=<optimized out>, msgidp=0x7f92243ed8dc) at sasl.c:148 #4 0x00007f9340f571da in ldap::Connection::Bind (this=this@entry=0x7f931c043478, msg_id=@0x7f92243ed98c: -1) at support/ldapconnection.cpp I have installed corresponding debug rpm for Openldap library. Following the source info. core dump is coming at line 481 of request.c file.A%A for ( srvp = srvlist; *srvp != NULL; srvp = &(*srvp)->lud_next ) // Here srvp is NULL so *srvp dumping core. if ( connect ) { LDAPURLDesc **srvp, *srv = NULL; async = LDAP_BOOL_GET( &ld->ld_options, LDAP_BOOL_CONNECT_ASYNC ); for ( srvp = srvlist; *srvp != NULL; srvp = &(*srvp)->lud_next ) { int rc; rc = ldap_int_open_connection( ld, lc, *srvp, async ); if ( rc != -1 ) { srv = *srvp; if ( ld->ld_urllist_proc && ( !async || rc != -2 ) ) { ld->ld_urllist_proc( ld, srvlist, srvp, ld->ld_urllist_params ); } break; } } Any idea how to fix it ?

1 0

(ITS#8491) slapdelete test needed
by quanah＠openldap.org 02 Sep '16

02 Sep '16

Full_Name: Quanah Gibson-Mount Version: RE25 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) We need to add a test script for slapdelete for 2.5 alpha

1 0

Re: (ITS#8490) changes not written to accesslog, causing replicas to loop syncing
by quanah＠zimbra.com 01 Sep '16

01 Sep '16

--On Thursday, September 01, 2016 8:58 AM +0000 quanah(a)zimbra.com wrote: > In looking at the LDAP accesslog, what I see is that what should have > been a modRDN op was stored in the accesslog as a MOD op (the one I > noted before). This seems particularly bizarre, because ldap01 should > have rejected this change as well. It appears we may have a problem > where the accesslog DB is updated, but then the change got rejected by > the unique overlay. Ok, actually the server (ldap01) accepted the change (renamed the entry). Looking at the database, it was correctly done as a MODRDN to ldap01, but /written/ as a MOD to accesslog?! --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8490) changes not written to accesslog, causing replicas to loop syncing
by quanah＠zimbra.com 01 Sep '16

01 Sep '16

--On Thursday, September 01, 2016 8:05 AM +0000 quanah(a)zimbra.com wrote: > --On Thursday, September 01, 2016 7:52 AM +0000 quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: OpenLDAP 2.4.44 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.52.177) >> >> >> In a 2-node MMR setup. Node 1 is getting a lot of write traffic. Both >> node 1 and node 2 have 3 replicas each. At some point, a change is >> received by node 1, which writes the change to its accesslog DB and its >> primary DB. It's 3 replicas are all correctly updated. MMR node 2 >> receives the change, updates its primary DB, but *fails* to write the >> change to the accesslog DB. However, it *does* write the CSN update to >> the accesslog DB successfully. This causes all of its replicas to also >> update their CSN. Then a change comes in triggering a constraint >> violation on the replicas, but fully accepted by their master. > > So the above summary is incorrect. While 3 replicas did go out of > sync... 2 belonged to the primary master (node1), and 1 belonged to the > secondary master (node 2). So really, 4 systems didn't log the change > (MMR node 2, ldap05, ldap07, ldap09). Ok, so that's not correct either. I now have the correct topography: ldap01 has the following replicas: ldap02, ldap05, ldap07, ldap09 ldap02 has the following replicas: ldap01, ldap06, ldap08, ldap10 So the replicas of ldap01 received the change and rejected it. ldap02 just skipped writing the entry to the accesslog, and as a result, none of its replicas ever got the change, and thus they never hit the failure issue of err 19, but they all are now lacking this modification entirely. I would note that every server was loaded today from the same ldap backup, so they were all perfectly in sync. In looking at the LDAP accesslog, what I see is that what should have been a modRDN op was stored in the accesslog as a MOD op (the one I noted before). This seems particularly bizarre, because ldap01 should have rejected this change as well. It appears we may have a problem where the accesslog DB is updated, but then the change got rejected by the unique overlay. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8490) changes not written to accesslog, causing replicas to loop syncing
by quanah＠zimbra.com 01 Sep '16

01 Sep '16

--On Thursday, September 01, 2016 7:52 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: OpenLDAP 2.4.44 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > In a 2-node MMR setup. Node 1 is getting a lot of write traffic. Both > node 1 and node 2 have 3 replicas each. At some point, a change is > received by node 1, which writes the change to its accesslog DB and its > primary DB. It's 3 replicas are all correctly updated. MMR node 2 > receives the change, updates its primary DB, but *fails* to write the > change to the accesslog DB. However, it *does* write the CSN update to > the accesslog DB successfully. This causes all of its replicas to also > update their CSN. Then a change comes in triggering a constraint > violation on the replicas, but fully accepted by their master. So the above summary is incorrect. While 3 replicas did go out of sync... 2 belonged to the primary master (node1), and 1 belonged to the secondary master (node 2). So really, 4 systems didn't log the change (MMR node 2, ldap05, ldap07, ldap09). So I have no explanation at the moment why ldap06, ldap08, and ldap10 were not affected. --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8490) changes not written to accesslog, causing replicas to loop syncing
by quanah＠openldap.org 01 Sep '16

01 Sep '16

Full_Name: Quanah Gibson-Mount Version: OpenLDAP 2.4.44 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) In a 2-node MMR setup. Node 1 is getting a lot of write traffic. Both node 1 and node 2 have 3 replicas each. At some point, a change is received by node 1, which writes the change to its accesslog DB and its primary DB. It's 3 replicas are all correctly updated. MMR node 2 receives the change, updates its primary DB, but *fails* to write the change to the accesslog DB. However, it *does* write the CSN update to the accesslog DB successfully. This causes all of its replicas to also update their CSN. Then a change comes in triggering a constraint violation on the replicas, but fully accepted by their master. Node 1 records the following change in its accesslog DB: dn: reqStart=20160901025119.904382Z,cn=accesslog objectClass: auditModify structuralObctctClass: auditModify reqStart: 20160901025119.904382Z reqEnd: 20160901025119.906625Z reqType: modify reqSession: 7780 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=renamed-trackp,ou=people,dc=xxxxxxxx,dc=co,dc=za reqResult: 0 reqM%3: zimbraMailWhitelistMaxNumEntries:= 0 reqMod: zimbraPrefMailLocalDeliveryDisabled:= FALSE reqMod: zimbraHideInGal:= TRUE reqMod: userPassword:= {SSHA} reqMod: mail:= renamed-trackp(a)xxxxxxx.co.za reqMod: displayName:= trackp(a)xxxxxxxx.co.za reodod: objectClass:= inetOrgPerson reqMod: objectClass:= zimbraAccount reqMod: objectClass:= amavisAccount reqMod: zimbraMailHost:= store328-dc01.cm.xxxxxxxxxxx reqMod: zimbraPasswordMustChange:= FALSE reqMod: cn:= trackp(a)xxxxxxxxxxxxx.co.za reqMod: zimbraPasswordModifiedTime:= 20160121142933Z reqMod: zimbraMailStatus:= enabled reqMod: zimbraIsDelegatedAdminAccount:= FALSE reqMod: zimbraPrefOutOfOfficeReplyEnabled:= FALSE reqMod: zimbraMailBlacklistMaxNumEntries:= 0 reqMod: zimbraAccountStatus:= locked reqMod: zimbraPrefTimeZoneId:= Africa/Harare reqMod: zimbraId:= 403c7b67-eea0-4315-9b10-a2853c6cf70b reqMod: zimbraMailTransport:= lmtp:store328-dc01.cm.xxxxxxxxxx:7025 reqMod: sn:= trackp(a)xxxxxxxxxxx.co.za reqMod: zimbraCOSId:= 1daeb979-365f-46b7-bb3f-2ad46f4576c1 reqMod: zimbraCreateTimestamp:= 20160121142933Z reqMod: zimbraMailDeliveryAddress:= renamed-trackp(a)xxxxxxx.co.za reqMod: entryCSN:= 20160901025119.904589Z#000000#002#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20160901025119Z reqEntryUUID: 2293af38-5497-1035-8bd6-1d34a55b9433 entryUUID: b46d8728-043a-1036-8ab7-9bf2e127fe3b creatorsName: cn=config createTimestamp: 20160901025119Z entryCSN: 20160901025119.904589Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20160901025119Z On the other master, we find in the accesslog two sequential CSN updates: dn: reqStart=20160901025119.904218Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20160901025119.904218Z reqEnd: 20160901025119.905035Z reqType: modify reqSession: 201 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20160901025119.902062Z#000000#002#000000 reqMod: contextCSN:= 20160901015920.689225Z#000000#003#000000 reqEntryUUID: 78143fa2-7af5-48cc-8d5e-6e15f68dd3b2 entryUUID: b46d48a8-043a-1036-81a5-b3dead5e3175 creatorsName: cn=config createTimestamp: 20160901025119Z entryCSN: 20160901025119.902062Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20160901025119Z dn: reqStart=20160901025119.908257Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20160901025119.908257Z reqEnd: 20160901025119.908439Z reqType: modify reqSession: 201 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20160901025119.904589Z#000000#002#000000 reqMod: contextCSN:= 20160901015920.689225Z#000000#003#000000 reqEntryUUID: 78143fa2-7af5-48cc-8d5e-6e15f68dd3b2 entryUUID: b46dcdaa-043a-1036-81a6-b3dead5e3175 creatorsName: cn=config createTimestamp: 20160901025119Z entryCSN: 20160901025119.904589Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20160901025119Z Note the CSN update in the second case is for 20160901025119.904589Z. Note that this was the CSN of the change that in node 1 was a real update. The atribute with a constraint in this case is ZimbraID, which is colliding with the zimbraID of the original entry it was renamed from.

1 0

Re: (ITS#8489) LMDB: C_EOF not cleared on cursor in mdb_cursor_put
by hyc＠symas.com 01 Sep '16

01 Sep '16

juerg.bircher(a)gmail.com wrote: > Full_Name: Juerg Bircher > Version: LMDB (master) > OS: MacOS / Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.82.36.179) > > > > The function mdb_cursor_put does not clear possibly set C_EOF flag on cursor. > Therefore an successive mdb_cursor_get call using MDB_NEXT may get an > MDB_NOTFOUND result even thought not having put the new value at the end of the > database. > > The following example should illustrate the issue: Thanks for the report, fixed now in mdb.master -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8489) LMDB: C_EOF not cleared on cursor in mdb_cursor_put
by juerg.bircher＠gmail.com 31 Aug '16

31 Aug '16

Full_Name: Juerg Bircher Version: LMDB (master) OS: MacOS / Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.82.36.179) The function mdb_cursor_put does not clear possibly set C_EOF flag on cursor. Therefore an successive mdb_cursor_get call using MDB_NEXT may get an MDB_NOTFOUND result even thought not having put the new value at the end of the database. The following example should illustrate the issue: Assume an database having two committed values "0" and "5". Begin a new transaction and open an cursor for the next steps: step 1 put 1 get next => returns 5 ==> ok step 2 put 6 get next 3E r returns MDB_NOTFOUND as at end of the database (sets C_EOF on cursor) ==> ok step 3 put 2 get next => should return 5 but due to the set C_EOF flag returns MDB_NOTFOUND ==> failure The fix could be to clear C_EOF on any successful mdb_cursor_put calls. The following code can be used to verify the issue. #include "lmdb.h" #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> static char *env_name = "/tmp/testdb"; static char *db_name = "tt"22; #define MAX_MAP_SIZ (1024 * 1024) #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define RES(err, expr) ((rc = expr) == (err) || (CHECK(!rc, #expr), 0)) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf%2tdtderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) static MDB_env *env; static MDB_dbi dbi; static void createTestValue(int num, MDB_val *key, MDB_val *val) { static char buf[16]; sprintf(buf, "%03d", num); key->mv_data = (void *)buf; key->mv_size = strlen((const char *)buf); val->mv_data = key->mv_data; val->mv_size = key->mv_size; } static void setup() { int rc; MDB_txn *txn; MDB_cursor *cursor; MDB_val key, val; E(mdb_env_create(&env)); E(mdb_env_set_maxreaders(env, 2)); E(mdb_env_set_maxdbs(env, 10)); E(mdb_env_set_mapsize(env, MAX_MAP_SIZ)); E(mdb_env_open(env, env_name, 0, 0664)); E(mdb_txn_begin(env, NULL,%0, &txn)); E(mdb_dbi_open(txn, db_name, MDB_CREATE, &dbi)); E(mdb_cursor_open(txn, dbi, &cursor)); createTestValue(0, &key, &val); E(mdb_cursor_put(cursor, &key, &val, 0)); createTestValue(5, &key, &val); E(mdb_cursor_put(cursor, &key, &val, 0)); mdb_cursor_close(cursor); E(mdb_txn_commit(txn)); } static int step1(MDB_cursor *cursor) { int rc; MDB_val key, val, rkey, rval; createTestValue(1, &key, &val); E(mdb_cursor_put(cursor, &key, &val, MDB_NOOVERWRITE)); E(mdb_cursor_get(cursor, &rkey, &rval, MDB_NEXT)); // ==> returns 5 return 0; } static int step2(MDB_cursor *cursor) { int rc; MDB_val key, val, rkey, rval; createTestValue(6, &key, &val); E(mdb_cursor_put(cursor, &key, &val, MDB_NOOVERWRITE)); rc = mdb_cursor_get(cursor, &rkey, &rval, MDB_NEXT); // ==> return nothing as 6 is the last one if (rc != MDB_NOTFOUND) { fprintf(stderr, "step2 failed\n"); return -1; } return 0; } static int step3(MDB_cursor *cursor) { int rc; MDB_val key, val, rkey, rval; createTestValue(2, &key, &val); E(mdb_cursor_put(cursor, &key, &val, MDB_NOOVERWRITE)); E(mdb_cursor_get(cursor, &rkey, &rval, MDB_NEXT)); // ==> should return 5 return 0; } static void test() { int rc; MDB_txn *txn; MDB_cursor *cursor; E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_cursor_open(txn, dbi, &cursor)); step1(cursor); step2(cursor); step3(cursor); mdb_cursor_close(cursor); E(mdb_txn_commit(txn)); } static void cleanup() { mdb_dbi_close(env, dbi); mdb_env_close(env); char name[1024]; sprintf(name% "22%s/data.mdb", db_name); unlink(name); sprintf(name, "%s/lock.mdb", db_name); unlink(name); } int main(int argc,char * argv[]) { setup(); test(); cleanup(); }

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs