- openldap-bugs - openldap.org

Re: (ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by khng300＠gmail.com 17 May '19

17 May '19

Bump. Ka Ho

1 0

Re: (ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 5:02 PM +0000 khng300(a)gmail.com wrote: > Full_Name: Ka Ho Ng > Version: mdb.master > OS: FreeBSD 12.0-RELEASE > URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch > Submission from: (NULL) (2001:470:fa95:1300::3) > > By the way, please help close ITS#8986 as this version is a resend of the > patch. The correct path is to follow up to your original ITS, not submit a new one. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by khng300＠gmail.com 17 May '19

17 May '19

Full_Name: Ka Ho Ng Version: mdb.master OS: FreeBSD 12.0-RELEASE URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch Submission from: (NULL) (2001:470:fa95:1300::3) Starting from __FreeBSD_version 1200059 union semun definition was removed from userspace headers in order to comply with POSIX. In order to resurrect the defintion we need to define _WANT_SEMUN before including sys/sem.h for __FreeBSD_version >= 1200059. I tried to touch as small amount of code as possible here to avoid interfering with other platforms I do not use. By the way, please help close ITS#8986 as this version is a resend of the patch.

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 4:09 PM +0000 "AYANIDES, JEAN-PHILIPPE" <jpayanides(a)prosodie.com> wrote: > > > Hello Quanah, > > I am not very familiar with gdb. Can you help me doing that? Start slapd on the server that's crashing Get the process ID of slapd gdb /path/to/slapd PID For example, if slapd is located in /usr/sbin, and the process ID is 1234: gdb /usr/sbin/slapd 1234 At the (gdb) prompt, enter the command "cont" to continue execution Run your operation that causes slapd to crash. This should drop you back to the (gdb) prompt. Then run the command: thr apply all bt full This will provide the full backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 17 May '19

17 May '19

--_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Quanah, I am not very familiar with gdb. Can you help me doing that? ________________________________ De : Quanah Gibson-Mount <quanah(a)symas.com> Envoy=E9 : vendredi 17 mai 2019 16:58:59 =C0 : AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org Objet : Re: (ITS#9023) crash using ppolicy chaining from slave to master --On Friday, May 17, 2019 3:50 PM +0000 jpayanides(a)prosodie.com wrote: > Full_Name: JPh Ayanides > Version: 2.4.47 > OS: Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.46.216.78) > > > Hello, I cannot succeed in making the following configuration to work. > Instead of that, openldap crashes. > > I have 2 openldap servers in master-slave: the slave is installed on a > machine named rada, and a master is installed on another machine named > simby. The ppolicy is activated on rada and simby, and I use chain and > updateref in order to sync failures in ppolicy coming from rada back to > simby. When I test that feature, with trying a bind with a wrong > password, openldap on the slave crashes. I failed in understanding why, > even with gdb. Ensure you have debugging symbols installed, and provide a full backtrace of all threads from gdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> This message contains information that may be privileged or confidential an= d is the property of the Capgemini Group. It is intended only for the perso= n to whom it is addressed. If you are not the intended recipient, you are n= ot authorized to read, print, retain, copy, disseminate, distribute, or use= this message or any part thereof. If you receive this message in error, pl= ease notify the sender immediately and delete all copies of this message. --_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Helvetica,sans-serif;" dir=3D"ltr"> <p style=3D"margin-top:0;margin-bottom:0">Hello Quanah,</p> <p style=3D"margin-top:0;margin-bottom:0">I am not very familiar with gdb. = Can you help me doing that?<br> </p> <strong><span style=3D"font-family:"Arial","sans-serif"= ; color:#0098CC"></span></strong> <div id=3D"Signature"></div> </div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>De :</b> Quanah Gibson-Mount &l= t;quanah(a)symas.com><br> <b>Envoy=E9 :</b> vendredi 17 mai 2019 16:58:59<br> <b>=C0 :</b> AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org<br> <b>Objet :</b> Re: (ITS#9023) crash using ppolicy chaining from slave to ma= ster</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">--On Friday, May 17, 2019 3:50 PM +0000 jpayan= ides(a)prosodie.com wrote:<br> <br> > Full_Name: JPh Ayanides<br> > Version: 2.4.47<br> > OS: Linux Debian<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o= rg/incoming/</a><br> > Submission from: (NULL) (195.46.216.78)<br> ><br> ><br> > Hello, I cannot succeed in making the following configuration to work.= <br> > Instead of that, openldap crashes.<br> ><br> > I have 2 openldap servers in master-slave: the slave is installed on a= <br> > machine named rada, and a master is installed on another machine named= <br> > simby. The ppolicy is activated on rada and simby, and I use chain and= <br> > updateref in order to sync failures in ppolicy coming from rada back t= o<br> > simby. When I test that feature, with trying a bind with a wrong<br> > password,  openldap on the slave crashes. I failed in understandi= ng why,<br> > even with gdb.<br> <br> Ensure you have debugging symbols installed, and provide a full backtrace <= br> of all threads from gdb.<br> <br> --Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com">http://www.symas.com</a>><br> <br> </div> </span></font></div> <span style=3D"font-size: 9px; line-height: 10px;">This message contains in= formation that may be privileged or confidential and is the property of the= Capgemini Group. It is intended only for the person to whom it is addresse= d. If you are not the intended recipient, you are not authorized to read, p= rint, retain, copy, disseminate, distribute, or use this message or any par= t thereof. If you receive this message in error, please notify the sender i= mmediately and delete all copies of this message.</span></body> </html> --_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_--

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 3:50 PM +0000 jpayanides(a)prosodie.com wrote: > Full_Name: JPh Ayanides > Version: 2.4.47 > OS: Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.46.216.78) > > > Hello, I cannot succeed in making the following configuration to work. > Instead of that, openldap crashes. > > I have 2 openldap servers in master-slave: the slave is installed on a > machine named rada, and a master is installed on another machine named > simby. The ppolicy is activated on rada and simby, and I use chain and > updateref in order to sync failures in ppolicy coming from rada back to > simby. When I test that feature, with trying a bind with a wrong > password, openldap on the slave crashes. I failed in understanding why, > even with gdb. Ensure you have debugging symbols installed, and provide a full backtrace of all threads from gdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 17 May '19

17 May '19

Full_Name: JPh Ayanides Version: 2.4.47 OS: Linux Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.46.216.78) Hello, I cannot succeed in making the following configuration to work. Instead of that, openldap crashes. I have 2 openldap servers in master-slave: the slave is installed on a machine named rada, and a master is installed on another machine named simby. The ppolicy is activated on rada and simby, and I use chain and updateref in order to sync failures in ppolicy coming from rada back to simby. When I test that feature, with trying a bind with a wrong password, openldap on the slave crashes. I failed in understanding why, even with gdb. Here is the configuration of rada: --------------------------- allow bind_v2 sizelimit size.hard=10000 sizelimit size.soft=500 # Schema and objectClass definitions include /appli/openldap/etc/openldap/schema/core.schema include /appli/openldap/etc/openldap/schema/cosine.schema include /appli/openldap/etc/openldap/schema/nis.schema include /appli/openldap/etc/openldap/schema/inetorgperson.schema include /appli/openldap/etc/openldap/schema/ppolicy.schema pidfile /appli/openldap-preprod/var/run/slapd.pid argsfile /appli/openldap-preprod/var/run/slapd.args loglevel -1 conn_max_pending 250 idletimeout 600 timelimit time.soft=60 timelimit time.hard=60 modulepath /appli/openldap/libexec/openldap moduleload back_bdb moduleload ppolicy moduleload back_ldap moduleload pw-sha2 password-hash {SSHA512} TLSVerifyClient never TLSCertificateKeyFile /appli/openldap-preprod/etc/private/auth.gdr.key TLSCertificateFile /appli/openldap-preprod/etc/certs/auth.gdr.crt TLSCACertificatePath /appli/openldap-preprod/etc/ca/ overlay chain chain-uri ldaps://simby.example:637 chain-idassert-bind bindmethod="simple" binddn="uid=mirrormode,dc=example" credentials="secret" mode="self" tls_reqcert=allow chain-tls none chain-return-error TRUE database bdb suffix "dc=example" rootdn "cn=admin,dc=example" rootpw {SSHA}XXXXXXXXXXXXXXXXXXXXXX dbconfig set_cachesize 0 128000000 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 directory "/appli/openldap-preprod/var/openldap-data" index objectClass,entryCSN,entryUUID eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub overlay ppolicy ppolicy_default "cn=pwdDefault,ou=policies,dc=example" ppolicy_hash_cleartext ppolicy_use_lockout ppolicy_forward_updates lastmod on syncrepl rid=002 provider=ldap://simby.example:390 binddn="uid=mirrormode,dc=example" credentials=secret bindmethod=simple searchbase="dc=example" schemachecking=off type=refreshAndPersist retry="60 +" tls_cacert="/appli/openldap-preprod/etc/ca/CADSI.pem" tls_reqcert=allow starttls=yes updateref ldaps://simby.example:637 access to attrs=userPassword by dn="cn=admin,dc=example" write by dn="cn=acadmin,dc=example" write by dn="uid=mirrormode,dc=example" read by dn="uid=rsasecureid,dc=example" auth by anonymous auth by dn="uid=test,ou=People,dc=example" none by * none access to attrs=shadowLastChange by dn="cn=admin,dc=example" write by dn="uid=mirrormode,dc=example" read by dn="uid=test,ou=People,dc=example" none by * read access to dn="uid=test,ou=People,dc=example" by dn="cn=admin,dc=example" write by * read database monitor access to * by * read ----------------------------- and here is the configuration file on the master: ---------------------------- allow bind_v2 sizelimit size.hard=10000 sizelimit size.soft=500 include /appli/openldap/etc/openldap/schema/core.schema include /appli/openldap/etc/openldap/schema/cosine.schema include /appli/openldap/etc/openldap/schema/nis.schema include /appli/openldap/etc/openldap/schema/inetorgperson.schema include /appli/openldap/etc/openldap/schema/ppolicy.schema pidfile /appli/openldap-preprod/var/run/slapd.pid argsfile /appli/openldap-preprod/var/run/slapd.args loglevel -1 modulepath /appli/openldap/libexec/openldap moduleload back_bdb moduleload syncprov moduleload ppolicy moduleload pw-sha2 password-hash {SSHA512} TLSCertificateKeyFile /appli/openldap-preprod/etc/private/simby.example.key TLSCertificateFile /appli/openldap-preprod/etc/certs/simby.example.pem TLSCACertificatePath /appli/openldap-preprod/etc/ca TLSverifyClient never database bdb suffix "dc=example" rootdn "cn=admin,dc=example" rootpw {SSHA}XXXXXXXXXXXXXXXXXXX directory "/appli/openldap-preprod/var/openldap-data" index objectclass,entryCSN,entryUUID eq index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 overlay ppolicy ppolicy_default "cn=pwdDefault,ou=policies,dc=example" ppolicy_use_lockout ppolicy_hash_cleartext lastmod on access to attrs=userPassword by dn="cn=admin,dc=example" write by dn="uid=mirrormode,dc=example" read by dn="cn=acadmin,dc=example" write by dn="cn=rsasecureid,dc=example" auth by anonymous auth by dn="uid=test,ou=People,dc=example" none by dn="cn=iam,dc=example" write by * none access to attrs=shadowLastChange by dn="cn=admin,dc=example" write by dn="uid=mirrormode,dc=example" read by dn="cn=acadmin,dc=example" write by dn="uid=test,ou=People,dc=example" none by dn="cn=iam,dc=example" write by * read access to dn="uid=test,ou=People,dc=example" by dn="cn=admin,dc=example" write by * read access to * by dn="uid=test,ou=People,dc=example" none by dn="uid=mirrormode,dc=example" read by dn="cn=admin,dc=example" write by dn="cn=acadmin,dc=example" write by dn="cn=iam,dc=example" write by * read access to dn="ou=People,dc=example" by dn="cn=acadmin,dc=example" write by * read database monitor access to * by * read --------------------------- In the log of the slave, I get at the end: May 17 16:37:12 rada slapd[546]: ==> bdb_bind: dn: uid=user1,ou=People,dc=example May 17 16:37:12 rada slapd[546]: bdb_dn2entry("uid=user1,ou=people,dc=example") May 17 16:37:12 rada slapd[546]: => access_allowed: result not in cache (userPassword) May 17 16:37:12 rada slapd[546]: => access_allowed: auth access to "uid=user1,ou=People,dc=example" "userPassword" requested May 17 16:37:12 rada slapd[546]: => acl_get: [1] attr userPassword May 17 16:37:12 rada slapd[546]: => acl_mask: access to entry "uid=user1,ou=People,dc=example", attr "userPassword" requested May 17 16:37:12 rada slapd[546]: => acl_mask: to value by "", (=0) May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: cn=admin,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: cn=acadmin,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: uid=mirrormode,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: uid=rsasecureid,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: ou=capge002,ou=application,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: anonymous May 17 16:37:12 rada slapd[546]: <= acl_mask: [6] applying auth(=xd) (stop) May 17 16:37:12 rada slapd[546]: <= acl_mask: [6] mask: auth(=xd) May 17 16:37:12 rada slapd[546]: => slap_access_allowed: auth access granted by auth(=xd) May 17 16:37:12 rada slapd[546]: => access_allowed: auth access granted by auth(=xd) May 17 16:37:12 rada slapd[546]: send_ldap_result: conn=1000 op=0 p=3 May 17 16:37:12 rada slapd[546]: send_ldap_result: err=49 matched="" text="" May 17 16:37:12 rada slapd[546]: => bdb_entry_get: ndn: "uid=user1,ou=people,dc=example" May 17 16:37:12 rada slapd[546]: => bdb_entry_get: oc: "(null)", at: "(null)" May 17 16:37:12 rada slapd[546]: bdb_dn2entry("uid=user1,ou=people,dc=example") May 17 16:37:12 rada slapd[546]: => bdb_entry_get: found entry: "uid=user1,ou=people,dc=example" May 17 16:37:12 rada slapd[546]: bdb_entry_get: rc=0 May 17 16:37:12 rada slapd[546]: bdb_dn2entry("uid=user1,ou=people,dc=example") May 17 16:37:12 rada slapd[546]: send_ldap_result: conn=1000 op=0 p=3 May 17 16:37:12 rada slapd[546]: send_ldap_result: err=10 matched="" text="" May 17 16:37:12 rada slapd[546]: send_ldap_result: referral="ldaps://simby.example:637/uid=user1,ou=People,dc=example" May 17 16:37:12 rada slapd[546]: >>> dnPrettyNormal: <uid=user1,ou=People,dc=example> May 17 16:37:12 rada slapd[546]: <<< dnPrettyNormal: <uid=user1,ou=People,dc=example>, <uid=user1,ou=people,dc=example> May 17 16:37:12 rada slapd[546]: conn=1000 op=0 ldap_chain_op: ref="ldaps://simby.example:637/uid=user1,ou=People,dc=example" -> "ldaps://simby.example:637" May 17 16:37:12 rada slapd[546]: conn=1000 op=0 ldap_chain_op: ref="ldaps://simby.example:637/uid=user1,ou=People,dc=example": URI="ldaps://simby.example:637" found in cache May 17 16:37:12 rada slapd[546]: =>ldap_back_getconn: conn=1000 op=0: lc=0x838b4a8 inserted refcnt=1 rc=0 May 17 16:37:12 rada slapd[546]: daemon: activity on 1 descriptor May 17 16:37:12 rada slapd[546]: daemon: activity on: May 17 16:37:12 rada slapd[546]: May 17 16:37:12 rada slapd[546]: daemon: epoll: listen=7 active_threads=1 tvp=zero May 17 16:37:12 rada slapd[546]: daemon: epoll: listen=8 active_threads=1 tvp=zero May 17 16:37:12 rada slapd[546]: daemon: epoll: listen=9 active_threads=1 tvp=zero May 17 16:37:12 rada slapd[546]: daemon: epoll: listen=10 active_threads=1 tvp=zero and then the slave crashes with a code 0177 In the log of the master, I get: May 17 16:37:12 simby slapd[18544]: => slap_access_allowed: auth access granted by auth(=xd) May 17 16:37:12 simby slapd[18544]: => access_allowed: auth access granted by auth(=xd) May 17 16:37:12 simby slapd[18544]: conn=1001 op=0 BIND dn="uid=mirrormode,dc=example" mech=SIMPLE ssf=0 May 17 16:37:12 simby slapd[18544]: do_bind: v3 bind: "uid=mirrormode,dc=example" to "uid=mirrormode,dc=example" May 17 16:37:12 simby slapd[18544]: send_ldap_result: conn=1001 op=0 p=3 May 17 16:37:12 simby slapd[18544]: send_ldap_result: err=0 matched="" text="" May 17 16:37:12 simby slapd[18544]: => bdb_entry_get: ndn: "uid=mirrormode,dc=example" May 17 16:37:12 simby slapd[18544]: => bdb_entry_get: oc: "(null)", at: "(null)" May 17 16:37:12 simby slapd[18544]: bdb_dn2entry("uid=mirrormode,dc=example") May 17 16:37:12 simby slapd[18544]: => bdb_entry_get: found entry: "uid=mirrormode,dc=example" May 17 16:37:12 simby slapd[18544]: bdb_entry_get: rc=0 May 17 16:37:12 simby slapd[18544]: send_ldap_response: msgid=1 tag=97 err=0 May 17 16:37:12 simby slapd[18544]: conn=1001 op=0 RESULT tag=97 err=0 text= May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: activity on 3 descriptors May 17 16:37:12 simby slapd[18544]: daemon: activity on: May 17 16:37:12 simby slapd[18544]: 12r May 17 16:37:12 simby slapd[18544]: 15r May 17 16:37:12 simby slapd[18544]: May 17 16:37:12 simby slapd[18544]: daemon: read active on 12 May 17 16:37:12 simby slapd[18544]: connection_get(12) May 17 16:37:12 simby slapd[18544]: connection_get(12): got connid=1000 May 17 16:37:12 simby slapd[18544]: connection_read(12): checking for input on id=1000 May 17 16:37:12 simby slapd[18544]: ber_get_next on fd 12 failed errno=0 (Success) May 17 16:37:12 simby slapd[18544]: connection_read(12): input error=-2 id=1000, closing. May 17 16:37:12 simby slapd[18544]: connection_closing: readying conn=1000 sd=12 for close May 17 16:37:12 simby slapd[18544]: connection_close: conn=1000 sd=12 May 17 16:37:12 simby slapd[18544]: daemon: removing 12 May 17 16:37:12 simby slapd[18544]: conn=1000 fd=12 closed (connection lost) May 17 16:37:12 simby slapd[18544]: daemon: read active on 15 May 17 16:37:12 simby slapd[18544]: connection_get(15) May 17 16:37:12 simby slapd[18544]: connection_get(15): got connid=1001 May 17 16:37:12 simby slapd[18544]: connection_read(15): checking for input on id=1001 May 17 16:37:12 simby slapd[18544]: ber_get_next on fd 15 failed errno=0 (Success) May 17 16:37:12 simby slapd[18544]: connection_read(15): input error=-2 id=1001, closing. May 17 16:37:12 simby slapd[18544]: connection_closing: readying conn=1001 sd=15 for close May 17 16:37:12 simby slapd[18544]: connection_close: conn=1001 sd=15 May 17 16:37:12 simby slapd[18544]: daemon: removing 15 May 17 16:37:12 simby slapd[18544]: conn=1001 fd=15 closed (connection lost) May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: activity on 1 descriptor May 17 16:37:12 simby slapd[18544]: daemon: activity on: May 17 16:37:12 simby slapd[18544]: May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=10 active_threads=0 tvp=NULL ----------------------------- I am not sure to using the right configuration, but anyway, openldap should not crash.

1 0

Re: (ITS#8755) invalid file descriptor when closing tls connection
by ondra＠mistotebe.net 14 May '19

14 May '19

On Mon, May 13, 2019 at 03:32:19PM +0000, ondra(a)mistotebe.net wrote: > Yes, it looks like the main SockBuf closing is run twice, once in > ldap_free_connection and once directly in ldap_ld_free. I think we don't > enforce that SockBuf implementations set sb_fd != AC_SOCKET_INVALID, so > not sure yet if we can gate calling sb_close on that or something else. > > I'll see if there's a way to make this work better. There's a proposed patch at https://github.com/mistotebe/openldap/tree/its8755 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9008) module rpath incorrect
by quanah＠symas.com 14 May '19

14 May '19

--On Wednesday, April 17, 2019 11:19 AM +0000 ondra(a)openldap.org wrote: > Full_Name: Ondrej Kuznik > Version: re24/master > OS: Linux > URL: https://github.com/mistotebe/openldap/tree/its9008 > Submission from: (NULL) (82.10.24.68) > > > Modules that link against libraries not already present in slapd will > only try to look in the rpaths encoded in the module, not in slapd. And > there is no point encoding $(moduledir) there, since we never install > anything of substance there. All the while the libraries we need probably > live in $(libdir). > > The linked patch fixes this and makes it possible for $(moduledir) (the > path modules will be installed into) to be set at configure time. This patch depends on a custom version of libtool that is not available to others and can cause significant build breakage when building under a packaging system. More work needed, either removing libtool from the build process for OpenLDAP, or modifications to this work to allow it to work properly with a non-custom version of libtool. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8755) invalid file descriptor when closing tls connection
by ondra＠mistotebe.net 13 May '19

13 May '19

On Thu, Oct 12, 2017 at 10:01:35PM +0000, info(a)christianknueppel.de wrote: > I currently developing on a c software which is using Openldap with TLS > authentication. My software is working fine, but when i test it with valgrind, i > always get an invalid file descriptor when closing the connection. > > Here is the stacktrace from valgrind: > [...] > --> In function ldap_close_handle i call ldap_unbind_ext_s(ld, NULL, NULL). > > The connection is built with ldap_initialize(&ld, config.ldap_url) and > ldap_start_tls_s(ld, NULL, NULL). Options set with ldap_set_option() are > LDAP_OPT_X_TLS_REQUIRE_CERT to 2 (LDAP_OPT_X_TLS_DEMAND) and > LDAP_OPT_X_TLS_CACERTFILE are set to all SSL CA-Certificates > (/etc/ssl/certs/ca-certificates.crt). I run the ldap_unbind_ext_s command (for > test purpose) shortly after the start_tls command is finished. > When i use ldap_sasl_interactive_bind_s with DIGEST-MD5 instead of > ldap_start_tls_s, the warning doesn't appear. When i use both, tls and sasl, the > warning also appears. > > My computer running on Ubuntu 16.04.3 LTS (uname: 4.4.0-97-generic x86_64) with > libldap-2.4-2 (2.4.42+dfsg-2ubuntu3.2) and libgnutls30 (3.4.10-4ubuntu1.4). I > also tested it with the newest Ubuntu Artful Aardvark and the newest openldap > (2.4.45+dfsg-1ubuntu1) and gnutls(3.5.8-6ubuntu3) release, but it didn't has any > effect in my case. > > I also tryed to compiled openldap against openssl to see, if it might be a > gnutls bug, but the invalid file descriptor occurs again. The lower valgrind > stacktrace is done with openldap 2.4.45 and openssl 1.0.2g on the newest Artful > Aardvark 17.10. > [...] Yes, it looks like the main SockBuf closing is run twice, once in ldap_free_connection and once directly in ldap_ld_free. I think we don't enforce that SockBuf implementations set sb_fd != AC_SOCKET_INVALID, so not sure yet if we can gate calling sb_close on that or something else. I'll see if there's a way to make this work better. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8799) slaptest fails to properly convert chain configuration
by ondra＠mistotebe.net 13 May '19

13 May '19

On Wed, May 08, 2019 at 01:31:48PM +0000, ondra(a)mistotebe.net wrote: > On Mon, Jan 22, 2018 at 11:57:38PM +0000, ondra(a)mistotebe.net wrote: >> On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah(a)openldap.org wrote: >>> After doing conversion, the resulting cn=config database has *two* ldap backends >>> defined: >>> >>> dn: olcDatabase={-1}frontend,cn=config >>> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config >>> dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf >> >> This is the catchall database used to handle referrals that are not >> handled by any other database you configure by hand. It collects all the >> chain-* settings that appear before the first chain-uri. >> >>> dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf >>> >>> The first instance ({0}ldap,...) isn't even valid. If you remove the entire >>> chain configuration from this database, and then attempt to import it, you get >>> the following: >> >> Yeah that is a problem. > > Turns out the problem is different yet. When the overlay is started up > after adding its entry, it generates a default backend internally. On > adding the above backend it now thinks it has a default one already (even > though there is no entry for it yet) and rejects it. There is now a patch here that exploits the above to know if the common backend has been added from slapd.conf/explicitly or implicitly like in the original report. https://github.com/mistotebe/openldap/tree/its8799 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8700) Compile error
by quanah＠symas.com 11 May '19

11 May '19

--On Thursday, July 27, 2017 1:04 AM +0000 papachoco(a)gmail.com wrote: > I am getting the error below while compiling openldap 2.4.45 on the > latest macOS sierra (10.12.6). I am only setting two configuration options > > configure-options = > --disable-slapd > --disable-slurpd > > Undefined symbols for architecture x86_64: > "_ERR_remove_thread_state", referenced from: > _tlso_destroy in libldap.a(tls_o.o) Hello, What version of OpenSSL were you linking against? Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9022) Force slapadd to rewrite all entryCSN values
by quanah＠openldap.org 11 May '19

11 May '19

Full_Name: Quanah Gibson-Mount Version: OpenLDAP 2.4 OS: 2.4.47 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) Per the slapadd man page: -S SID Server ID to use in generated entryCSN. Also used for contextCSN if -w is set as well. Defaults to 0. However, if this is run against an export that already has entryCSN values in the entries, those values are not updated. This is problematic when wanting to update a database from single provider (SID0) to MMR (SID1+). I generally think that if the -S option is provided, and is non-zero, that all entryCSN values that currently have a "0" serverID in the entryCSN field should be updated to the specified -S value. In the above case, it would be critical to additionally flag -w on the end user part. This helps to clean up data when doing migrations.

1 0

Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by darshankmistry＠yahoo.com 10 May '19

10 May '19

------=_Part_582781_95096894.1557523728570 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable thank you, this case can be closed. appreciate all your help and clarificat= ion. thanks agian Thank you, Darshankumar Mistry darshankmistry(a)yahoo.com =20 On Friday, May 10, 2019, 1:53:16 PM PDT, Howard Chu <hyc(a)symas.com> wro= te: =20 =20 darshankmistry(a)yahoo.com wrote: > ------=3D_Part_545863_1662769086.1557520342175 > Content-Type: text/plain; charset=3DUTF-8 > Content-Transfer-Encoding: quoted-printable >=20 > thank you very much for quick response and openldap behavior configuratio= n.=3D > =3DC2=3DA0 > how we can ignore to look server name in subject of certificate so I can = us=3D > e LDAP server ip address instead of host name?=3DC2=3DA0 > Also want to know if there is any open CVE which says it is vulnerabiliti= es=3D >=C2=A0 to use LDAP server ip address instead of name in ldap configuration= .=3DC2=3DA0 Add the IP address in a subjectALternativeName extension to your server cer= tificate. The behavior here is specified in RFC4513. >=20 >=20 > Thank you, > Darshankumar Mistry > darshankmistry(a)yahoo.com > =3D20 >=20 >=C2=A0 =C2=A0 On Friday, May 10, 2019, 12:58:38 PM PDT, Quanah Gibson-Moun= t <quanah@s=3D > ymas.com> wrote: =3D20 > =3D20 >=C2=A0 --On Friday, May 10, 2019 8:52 PM +0000 darshankmistry(a)yahoo.com wr= ote: >=20 >> Full_Name: Darshankumar Mistry >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) >> >> >> I would like to know why Open LDAP behavior was changed where we must >> have to configure FQDN name mentioned in certificate in order to work LD= A=3D > P >> authentication... else TLS start failing. >=20 > OpenLDAP has worked this way since I first started using it in 2002.=3DC2= =3DA0 =3D > This=3D20 > behavior is nothing new.=3DC2=3DA0 And this is the correct behavior. >=20 > This ITS will be closed. >=20 > --Quanah >=20 >=20 > -- >=20 > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >=20 >=C2=A0 =3D20 > ------=3D_Part_545863_1662769086.1557520342175 > Content-Type: text/html; charset=3DUTF-8 > Content-Transfer-Encoding: quoted-printable >=20 > <html><head></head><body><div class=3D3D"ydpf9876065yahoo-style-wrap" sty= le=3D > =3D3D"font-family:verdana, helvetica, sans-serif;font-size:13px;"><div><d= iv>t=3D > hank you very much for quick response and openldap behavior configuration= .&=3D > nbsp;</div><div><br></div><div>how we can ignore to look server name in s= ub=3D > ject of certificate so I can use LDAP server ip address instead of host n= am=3D > e? </div><div><br></div><div>Also want to know if there is any open = CV=3D > E which says it is vulnerabilities to use LDAP server ip address instead = of=3D >=C2=A0 name in ldap configuration. </div><div><br></div><div><br></di= v><div>=3D > <br></div><div class=3D3D"ydpf9876065signature"><div><span class=3D3D"ydp= f98760=3D > 65yui_3_7_2_102_1375813203128_121" style=3D3D"font-family:arial, sans-ser= if;c=3D > olor:rgb(80, 0, 80);">Thank you,</span><br class=3D3D"ydpf9876065yui_3_7_= 2_10=3D > 2_1375813203128_122" style=3D3D"font-family:arial, sans-serif;color:rgb(8= 0, 0=3D > , 80);"><span class=3D3D"ydpf9876065yui_3_7_2_102_1375813203128_123" styl= e=3D3D=3D > "font-family:arial, sans-serif;color:rgb(80, 0, 80);">Darshankumar Mistry= </=3D > span><br class=3D3D"ydpf9876065yui_3_7_2_102_1375813203128_124" style=3D3= D"font=3D > -family:arial, sans-serif;color:rgb(80, 0, 80);"><a href=3D3D"mailto:dars= hank=3D > mistry(a)yahoo.com" class=3D3D"ydpf9876065yui_3_7_2_102_1375813203128_125" = styl=3D > e=3D3D"color:rgb(17, 85, 204);font-family:arial, sans-serif;" rel=3D3D"no= follow=3D > " target=3D3D"_blank">darshankmistry(a)yahoo.com</a><br></div></div></div> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <div><br></div><div><br></div> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </div><div id=3D3D"ydpb3d55fc2yahoo_quoted_756= 2650282" class=3D3D"ydpb3=3D > d55fc2yahoo_quoted"> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <div style=3D3D"font-family:'Hel= vetica Neue', Helvetica, Arial, s=3D > ans-serif;font-size:13px;color:#26282a;"> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <div> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On F= riday, May 10, 2019, 12:58:38 PM PDT, Quanah Gibson=3D > -Mount <quanah(a)symas.com> wrote: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </div> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <div><br></div> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <div><br></div> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <div>--On Friday, = May 10, 2019 8:52 PM +0000 <a href=3D3D"mai=3D > lto:darshankmistry@yahoo.com" rel=3D3D"nofollow" target=3D3D"_blank">dars= hankmi=3D > stry(a)yahoo.com</a> wrote:<br><br>> Full_Name: Darshankumar Mistry<br>&= gt=3D > ; Version:<br>> OS:<br>> URL: <a href=3D3D"ftp://ftp.openldap.org/i= ncom=3D > ing/" rel=3D3D"nofollow" target=3D3D"_blank">ftp://ftp.openldap.org/incom= ing/</=3D > a><br>> Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac)= <b=3D > r>><br>><br>> I would like to know why Open LDAP behavior was ch= an=3D > ged where we must<br>> have to configure FQDN name mentioned in certif= ic=3D > ate in order to work LDAP<br>> authentication... else TLS start failin= g.=3D > <br><br>OpenLDAP has worked this way since I first started using it in 20= 02=3D > .  This <br>behavior is nothing new.  And this is the correct b= eh=3D > avior.<br><br>This ITS will be closed.<br><br>--Quanah<br><br><br>--<br><= br=3D >> Quanah Gibson-Mount<br>Product Architect<br>Symas Corporation<br>Package= d,=3D >=C2=A0 certified, and supported LDAP solutions powered by OpenLDAP:<br>&lt= ;<a hre=3D > f=3D3D"http://www.symas.com" rel=3D3D"nofollow" target=3D3D"_blank">http:= //www.sy=3D > mas.com</a>><br><br></div> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </div> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </div></body></html> > ------=3D_Part_545863_1662769086.1557520342175-- >=20 >=20 >=20 >=20 --=20 =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.symas.= com =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 http://highlandsun.com/hyc/ =C2=A0 Chief Architect, OpenLDAP=C2=A0 http://www.openldap.org/project/ =20 ------=_Part_582781_95096894.1557523728570 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div class=3D"ydp2c59819dyahoo-style-wrap" style= =3D"font-family:verdana, helvetica, sans-serif;font-size:13px;"><div><div>t= hank you, this case can be closed. appreciate all your help and clarificati= on. thanks agian</div><div><br></div><div class=3D"ydp2c59819dsignature"><d= iv><span class=3D"ydp2c59819dyui_3_7_2_102_1375813203128_121" style=3D"font= -family:arial, sans-serif;color:rgb(80, 0, 80);">Thank you,</span><br class= =3D"ydp2c59819dyui_3_7_2_102_1375813203128_122" style=3D"font-family:arial,= sans-serif;color:rgb(80, 0, 80);"><span class=3D"ydp2c59819dyui_3_7_2_102_= 1375813203128_123" style=3D"font-family:arial, sans-serif;color:rgb(80, 0, = 80);">Darshankumar Mistry</span><br class=3D"ydp2c59819dyui_3_7_2_102_13758= 13203128_124" style=3D"font-family:arial, sans-serif;color:rgb(80, 0, 80);"= ><a href=3D"mailto:darshankmistry@yahoo.com" class=3D"ydp2c59819dyui_3_7_2_= 102_1375813203128_125" style=3D"color:rgb(17, 85, 204);font-family:arial, s= ans-serif;" rel=3D"nofollow" target=3D"_blank">darshankmistry(a)yahoo.com</a>= <br></div></div></div> <div><br></div><div><br></div> =20 </div><div id=3D"ydp4544e9c6yahoo_quoted_7723269985" class=3D"ydp45= 44e9c6yahoo_quoted"> <div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s= ans-serif;font-size:13px;color:#26282a;"> =20 <div> On Friday, May 10, 2019, 1:53:16 PM PDT, Howard Chu &lt= ;hyc(a)symas.com> wrote: </div> <div><br></div> <div><br></div> <div><div dir=3D"ltr"><a href=3D"mailto:darshankmistry@yaho= o.com" rel=3D"nofollow" target=3D"_blank">darshankmistry(a)yahoo.com</a> wrot= e:<br></div><div dir=3D"ltr">> ------=3D_Part_545863_1662769086.15575203= 42175<br></div><div dir=3D"ltr">> Content-Type: text/plain; charset=3DUT= F-8<br></div><div dir=3D"ltr">> Content-Transfer-Encoding: quoted-printa= ble<br></div><div dir=3D"ltr">> <br></div><div dir=3D"ltr">> thank yo= u very much for quick response and openldap behavior configuration.=3D<br><= /div><div dir=3D"ltr">> =3DC2=3DA0<br></div><div dir=3D"ltr">> how we= can ignore to look server name in subject of certificate so I can us=3D<br= ></div><div dir=3D"ltr">> e LDAP server ip address instead of host name?= =3DC2=3DA0<br></div><div dir=3D"ltr">> Also want to know if there is any= open CVE which says it is vulnerabilities=3D<br></div><div dir=3D"ltr">&gt= ;  to use LDAP server ip address instead of name in ldap configuration= .=3DC2=3DA0<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Add the IP= address in a subjectALternativeName extension to your server certificate.<= br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">The behavior here is s= pecified in RFC4513.<br></div><div dir=3D"ltr">> <br></div><div dir=3D"l= tr">> <br></div><div dir=3D"ltr">> Thank you,<br></div><div dir=3D"lt= r">> Darshankumar Mistry<br></div><div dir=3D"ltr">> <a href=3D"mailt= o:darshankmistry@yahoo.com" rel=3D"nofollow" target=3D"_blank">darshankmist= ry(a)yahoo.com</a><br></div><div dir=3D"ltr">> =3D20<br></div><div dir=3D"= ltr">> <br></div><div dir=3D"ltr">>    On Friday, May 10, = 2019, 12:58:38 PM PDT, Quanah Gibson-Mount <<a href=3D"mailto:quanah@s" = rel=3D"nofollow" target=3D"_blank">quanah@s</a>=3D<br></div><div dir=3D"ltr= ">> ymas.com> wrote: =3D20<br></div><div dir=3D"ltr">> =3D20<br></= div><div dir=3D"ltr">>  --On Friday, May 10, 2019 8:52 PM +0000 <a = href=3D"mailto:darshankmistry@yahoo.com" rel=3D"nofollow" target=3D"_blank"= >darshankmistry(a)yahoo.com</a> wrote:<br></div><div dir=3D"ltr">> <br></d= iv><div dir=3D"ltr">>> Full_Name: Darshankumar Mistry<br></div><div d= ir=3D"ltr">>> Version:<br></div><div dir=3D"ltr">>> OS:<br></di= v><div dir=3D"ltr">>> URL: <a href=3D"ftp://ftp.openldap.org/incoming= /" rel=3D"nofollow" target=3D"_blank">ftp://ftp.openldap.org/incoming/</a><= br></div><div dir=3D"ltr">>> Submission from: (NULL) (2001:420:10b:12= 72:fc1b:1ea:d311:6cac)<br></div><div dir=3D"ltr">>><br></div><div dir= =3D"ltr">>><br></div><div dir=3D"ltr">>> I would like to know w= hy Open LDAP behavior was changed where we must<br></div><div dir=3D"ltr">&= gt;> have to configure FQDN name mentioned in certificate in order to wo= rk LDA=3D<br></div><div dir=3D"ltr">> P<br></div><div dir=3D"ltr">>&g= t; authentication... else TLS start failing.<br></div><div dir=3D"ltr">>= <br></div><div dir=3D"ltr">> OpenLDAP has worked this way since I first= started using it in 2002.=3DC2=3DA0 =3D<br></div><div dir=3D"ltr">> Thi= s=3D20<br></div><div dir=3D"ltr">> behavior is nothing new.=3DC2=3DA0 An= d this is the correct behavior.<br></div><div dir=3D"ltr">> <br></div><d= iv dir=3D"ltr">> This ITS will be closed.<br></div><div dir=3D"ltr">>= <br></div><div dir=3D"ltr">> --Quanah<br></div><div dir=3D"ltr">> <b= r></div><div dir=3D"ltr">> <br></div><div dir=3D"ltr">> --<br></div><= div dir=3D"ltr">> <br></div><div dir=3D"ltr">> Quanah Gibson-Mount<br= ></div><div dir=3D"ltr">> Product Architect<br></div><div dir=3D"ltr">&g= t; Symas Corporation<br></div><div dir=3D"ltr">> Packaged, certified, an= d supported LDAP solutions powered by OpenLDAP:<br></div><div dir=3D"ltr">&= gt; <<a href=3D"http://www.symas.com" rel=3D"nofollow" target=3D"_blank"= >http://www.symas.com</a>><br></div><div dir=3D"ltr">> <br></div><div= dir=3D"ltr">>  =3D20<br></div><div dir=3D"ltr">> ------=3D_Part= _545863_1662769086.1557520342175<br></div><div dir=3D"ltr">> Content-Typ= e: text/html; charset=3DUTF-8<br></div><div dir=3D"ltr">> Content-Transf= er-Encoding: quoted-printable<br></div><div dir=3D"ltr">> <br></div><div= dir=3D"ltr">> <html><head></head><body><div = class=3D3D"ydpf9876065yahoo-style-wrap" style=3D<br></div><div dir=3D"ltr">= > =3D3D"font-family:verdana, helvetica, sans-serif;font-size:13px;">&= lt;div><div>t=3D<br></div><div dir=3D"ltr">> hank you very much= for quick response and openldap behavior configuration.&=3D<br></div><= div dir=3D"ltr">> nbsp;</div><div><br></div><= div>how we can ignore to look server name in sub=3D<br></div><div dir=3D= "ltr">> ject of certificate so I can use LDAP server ip address instead = of host nam=3D<br></div><div dir=3D"ltr">> e?&nbsp;</div><d= iv><br></div><div>Also want to know if there is any op= en CV=3D<br></div><div dir=3D"ltr">> E which says it is vulnerabilities = to use LDAP server ip address instead of=3D<br></div><div dir=3D"ltr">>&= nbsp; name in ldap configuration.&nbsp;</div><div><br&gt= ;</div><div><br></div><div>=3D<br></div><div = dir=3D"ltr">> <br></div><div class=3D3D"ydpf9876065signat= ure"><div><span class=3D3D"ydpf98760=3D<br></div><div dir=3D"lt= r">> 65yui_3_7_2_102_1375813203128_121" style=3D3D"font-family:arial, sa= ns-serif;c=3D<br></div><div dir=3D"ltr">> olor:rgb(80, 0, 80);">Thank= you,</span><br class=3D3D"ydpf9876065yui_3_7_2_10=3D<br></div><di= v dir=3D"ltr">> 2_1375813203128_122" style=3D3D"font-family:arial, sans-= serif;color:rgb(80, 0=3D<br></div><div dir=3D"ltr">> , 80);"><span= class=3D3D"ydpf9876065yui_3_7_2_102_1375813203128_123" style=3D3D=3D<br></= div><div dir=3D"ltr">> "font-family:arial, sans-serif;color:rgb(80, 0, 8= 0);">Darshankumar Mistry</=3D<br></div><div dir=3D"ltr">> span>= <br class=3D3D"ydpf9876065yui_3_7_2_102_1375813203128_124" style=3D3D"fo= nt=3D<br></div><div dir=3D"ltr">> -family:arial, sans-serif;color:rgb(80= , 0, 80);"><a href=3D3D"mailto:darshank=3D<br></div><div dir=3D"ltr">= > <a href=3D"mailto:mistry@yahoo.com" rel=3D"nofollow" target=3D"_blank"= >mistry(a)yahoo.com</a>" class=3D3D"ydpf9876065yui_3_7_2_102_1375813203128_12= 5" styl=3D<br></div><div dir=3D"ltr">> e=3D3D"color:rgb(17, 85, 204);fon= t-family:arial, sans-serif;" rel=3D3D"nofollow=3D<br></div><div dir=3D"ltr"= >> " target=3D3D"_blank"><a href=3D"mailto:darshankmistry@yahoo.com" = rel=3D"nofollow" target=3D"_blank">darshankmistry(a)yahoo.com</a></a>&l= t;br></div></div></div><br></div><div dir=3D"ltr">>=         <div><br></div><div>&l= t;br></div><br></div><div dir=3D"ltr">>      &nb= sp; =3D20<br></div><div dir=3D"ltr">>        </d= iv><div id=3D3D"ydpb3d55fc2yahoo_quoted_7562650282" class=3D3D"ydpb3= =3D<br></div><div dir=3D"ltr">> d55fc2yahoo_quoted"><br></div><div di= r=3D"ltr">>            <div style=3D3D= "font-family:'Helvetica Neue', Helvetica, Arial, s=3D<br></div><div dir=3D"= ltr">> ans-serif;font-size:13px;color:#26282a;"><br></div><div dir=3D= "ltr">>                =3D20<br>= </div><div dir=3D"ltr">>             =   <div><br></div><div dir=3D"ltr">>      &nb= sp;             On Friday, May 10, 2019, 12:= 58:38 PM PDT, Quanah Gibson=3D<br></div><div dir=3D"ltr">> -Mount &l= t;<a href=3D"mailto:quanah@symas.com" rel=3D"nofollow" target=3D"_blank">qu= anah(a)symas.com</a>&gt; wrote:<br></div><div dir=3D"ltr">>  &nbs= p;             </div><br></div><div di= r=3D"ltr">>                <= div><br></div><br></div><div dir=3D"ltr">>    &= nbsp;           <div><br></div>= <br></div><div dir=3D"ltr">>            &n= bsp;   <div>--On Friday, May 10, 2019 8:52 PM +0000 <a href= =3D3D"mai=3D<br></div><div dir=3D"ltr">> lto:<a href=3D"mailto:darshankm= istry(a)yahoo.com" rel=3D"nofollow" target=3D"_blank">darshankmistry(a)yahoo.co= m</a>" rel=3D3D"nofollow" target=3D3D"_blank">darshankmi=3D<br></div><di= v dir=3D"ltr">> <a href=3D"mailto:stry@yahoo.com" rel=3D"nofollow" targe= t=3D"_blank">stry(a)yahoo.com</a></a> wrote:<br><br>&gt= ; Full_Name: Darshankumar Mistry<br>&gt=3D<br></div><div dir=3D"l= tr">> ; Version:<br>&gt; OS:<br>&gt; URL: <a href= =3D3D"<a href=3D"ftp://ftp.openldap.org/incom=3D" rel=3D"nofollow" target= =3D"_blank">ftp://ftp.openldap.org/incom=3D</a><br></div><div dir=3D"ltr">&= gt; ing/" rel=3D3D"nofollow" target=3D3D"_blank"><a href=3D"ftp://ftp.op= enldap.org/incoming/" rel=3D"nofollow" target=3D"_blank">ftp://ftp.openldap= .org/incoming/</a></=3D<br></div><div dir=3D"ltr">> a><br>&a= mp;gt; Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac)<b= =3D<br></div><div dir=3D"ltr">> r>&gt;<br>&gt;<br&gt= ;&gt; I would like to know why Open LDAP behavior was chan=3D<br></div>= <div dir=3D"ltr">> ged where we must<br>&gt; have to configure= FQDN name mentioned in certific=3D<br></div><div dir=3D"ltr">> ate in o= rder to work LDAP<br>&gt; authentication... else TLS start failin= g.=3D<br></div><div dir=3D"ltr">> <br><br>OpenLDAP has worke= d this way since I first started using it in 2002=3D<br></div><div dir=3D"l= tr">> .&nbsp; This <br>behavior is nothing new.&nbsp; And = this is the correct beh=3D<br></div><div dir=3D"ltr">> avior.<br>&= lt;br>This ITS will be closed.<br><br>--Quanah<br><= br><br>--<br><br=3D<br></div><div dir=3D"ltr">>> Qu= anah Gibson-Mount<br>Product Architect<br>Symas Corporation<= br>Packaged,=3D<br></div><div dir=3D"ltr">>  certified, and supp= orted LDAP solutions powered by OpenLDAP:<br>&lt;<a hre=3D<br>= </div><div dir=3D"ltr">> f=3D3D"<a href=3D"http://www.symas.com" rel=3D"= nofollow" target=3D"_blank">http://www.symas.com</a>" rel=3D3D"nofollow" ta= rget=3D3D"_blank"><a href=3D"http://www.sy=3D" rel=3D"nofollow" target= =3D"_blank">http://www.sy=3D</a><br></div><div dir=3D"ltr">> mas.com<= /a>&gt;<br><br></div><br></div><div dir=3D"ltr">&g= t;            </div><br></div><div dir= =3D"ltr">>        </div></body></htm= l><br></div><div dir=3D"ltr">> ------=3D_Part_545863_1662769086.15575= 20342175--<br></div><div dir=3D"ltr">> <br></div><div dir=3D"ltr">> <= br></div><div dir=3D"ltr">> <br></div><div dir=3D"ltr">> <br></div><d= iv dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">-- <br= ></div><div dir=3D"ltr">  -- Howard Chu<br></div><div dir=3D"ltr">&nbs= p; CTO, Symas Corp.          <a href=3D"http://ww= w.symas.com" rel=3D"nofollow" target=3D"_blank">http://www.symas.com</a><br= ></div><div dir=3D"ltr">  Director, Highland Sun    <a href= =3D"http://highlandsun.com/hyc/" rel=3D"nofollow" target=3D"_blank">http://= highlandsun.com/hyc/</a><br></div><div dir=3D"ltr">  Chief Architect, = OpenLDAP  <a href=3D"http://www.openldap.org/project/" rel=3D"nofollow= " target=3D"_blank">http://www.openldap.org/project/</a><br></div></div> </div> </div></body></html> ------=_Part_582781_95096894.1557523728570--

1 0

Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by hyc＠symas.com 10 May '19

10 May '19

darshankmistry(a)yahoo.com wrote: > ------=_Part_545863_1662769086.1557520342175 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > thank you very much for quick response and openldap behavior configuration.= > =C2=A0 > how we can ignore to look server name in subject of certificate so I can us= > e LDAP server ip address instead of host name?=C2=A0 > Also want to know if there is any open CVE which says it is vulnerabilities= > to use LDAP server ip address instead of name in ldap configuration.=C2=A0 Add the IP address in a subjectALternativeName extension to your server certificate. The behavior here is specified in RFC4513. > > > Thank you, > Darshankumar Mistry > darshankmistry(a)yahoo.com > =20 > > On Friday, May 10, 2019, 12:58:38 PM PDT, Quanah Gibson-Mount <quanah@s= > ymas.com> wrote: =20 > =20 > --On Friday, May 10, 2019 8:52 PM +0000 darshankmistry(a)yahoo.com wrote: > >> Full_Name: Darshankumar Mistry >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) >> >> >> I would like to know why Open LDAP behavior was changed where we must >> have to configure FQDN name mentioned in certificate in order to work LDA= > P >> authentication... else TLS start failing. > > OpenLDAP has worked this way since I first started using it in 2002.=C2=A0 = > This=20 > behavior is nothing new.=C2=A0 And this is the correct behavior. > > This ITS will be closed. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > =20 > ------=_Part_545863_1662769086.1557520342175 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > <html><head></head><body><div class=3D"ydpf9876065yahoo-style-wrap" style= > =3D"font-family:verdana, helvetica, sans-serif;font-size:13px;"><div><div>t= > hank you very much for quick response and openldap behavior configuration.&= > nbsp;</div><div><br></div><div>how we can ignore to look server name in sub= > ject of certificate so I can use LDAP server ip address instead of host nam= > e? </div><div><br></div><div>Also want to know if there is any open CV= > E which says it is vulnerabilities to use LDAP server ip address instead of= > name in ldap configuration. </div><div><br></div><div><br></div><div>= > <br></div><div class=3D"ydpf9876065signature"><div><span class=3D"ydpf98760= > 65yui_3_7_2_102_1375813203128_121" style=3D"font-family:arial, sans-serif;c= > olor:rgb(80, 0, 80);">Thank you,</span><br class=3D"ydpf9876065yui_3_7_2_10= > 2_1375813203128_122" style=3D"font-family:arial, sans-serif;color:rgb(80, 0= > , 80);"><span class=3D"ydpf9876065yui_3_7_2_102_1375813203128_123" style=3D= > "font-family:arial, sans-serif;color:rgb(80, 0, 80);">Darshankumar Mistry</= > span><br class=3D"ydpf9876065yui_3_7_2_102_1375813203128_124" style=3D"font= > -family:arial, sans-serif;color:rgb(80, 0, 80);"><a href=3D"mailto:darshank= > mistry(a)yahoo.com" class=3D"ydpf9876065yui_3_7_2_102_1375813203128_125" styl= > e=3D"color:rgb(17, 85, 204);font-family:arial, sans-serif;" rel=3D"nofollow= > " target=3D"_blank">darshankmistry(a)yahoo.com</a><br></div></div></div> > <div><br></div><div><br></div> > =20 > </div><div id=3D"ydpb3d55fc2yahoo_quoted_7562650282" class=3D"ydpb3= > d55fc2yahoo_quoted"> > <div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s= > ans-serif;font-size:13px;color:#26282a;"> > =20 > <div> > On Friday, May 10, 2019, 12:58:38 PM PDT, Quanah Gibson= > -Mount <quanah(a)symas.com> wrote: > </div> > <div><br></div> > <div><br></div> > <div>--On Friday, May 10, 2019 8:52 PM +0000 <a href=3D"mai= > lto:darshankmistry@yahoo.com" rel=3D"nofollow" target=3D"_blank">darshankmi= > stry(a)yahoo.com</a> wrote:<br><br>> Full_Name: Darshankumar Mistry<br>&gt= > ; Version:<br>> OS:<br>> URL: <a href=3D"ftp://ftp.openldap.org/incom= > ing/" rel=3D"nofollow" target=3D"_blank">ftp://ftp.openldap.org/incoming/</= > a><br>> Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac)<b= > r>><br>><br>> I would like to know why Open LDAP behavior was chan= > ged where we must<br>> have to configure FQDN name mentioned in certific= > ate in order to work LDAP<br>> authentication... else TLS start failing.= > <br><br>OpenLDAP has worked this way since I first started using it in 2002= > .  This <br>behavior is nothing new.  And this is the correct beh= > avior.<br><br>This ITS will be closed.<br><br>--Quanah<br><br><br>--<br><br= >> Quanah Gibson-Mount<br>Product Architect<br>Symas Corporation<br>Packaged,= > certified, and supported LDAP solutions powered by OpenLDAP:<br><<a hre= > f=3D"http://www.symas.com" rel=3D"nofollow" target=3D"_blank">http://www.sy= > mas.com</a>><br><br></div> > </div> > </div></body></html> > ------=_Part_545863_1662769086.1557520342175-- > > > > -- -- 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

Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by quanah＠symas.com 10 May '19

10 May '19

--On Friday, May 10, 2019 9:32 PM +0000 darshan mistry <darshankmistry(a)yahoo.com> wrote: > how we can ignore to look server name in subject of certificate so I can > use LDAP server ip address instead of host name? If you want to allow connecting over the IP address with TLS, then add it as a subjectAltName value in the certificate, for example: subjectAltName=IP:1.2.3.4 > Also want to know if there is any open CVE which says it is > vulnerabilities to use LDAP server ip address instead of name in ldap > configuration. I'm not aware of any such CVE or why there would be one. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by darshankmistry＠yahoo.com 10 May '19

10 May '19

------=_Part_545863_1662769086.1557520342175 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable thank you very much for quick response and openldap behavior configuration.= =C2=A0 how we can ignore to look server name in subject of certificate so I can us= e LDAP server ip address instead of host name?=C2=A0 Also want to know if there is any open CVE which says it is vulnerabilities= to use LDAP server ip address instead of name in ldap configuration.=C2=A0 Thank you, Darshankumar Mistry darshankmistry(a)yahoo.com =20 On Friday, May 10, 2019, 12:58:38 PM PDT, Quanah Gibson-Mount <quanah@s= ymas.com> wrote: =20 =20 --On Friday, May 10, 2019 8:52 PM +0000 darshankmistry(a)yahoo.com wrote: > Full_Name: Darshankumar Mistry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) > > > I would like to know why Open LDAP behavior was changed where we must > have to configure FQDN name mentioned in certificate in order to work LDA= P > authentication... else TLS start failing. OpenLDAP has worked this way since I first started using it in 2002.=C2=A0 = This=20 behavior is nothing new.=C2=A0 And this is the correct behavior. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> =20 ------=_Part_545863_1662769086.1557520342175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div class=3D"ydpf9876065yahoo-style-wrap" style= =3D"font-family:verdana, helvetica, sans-serif;font-size:13px;"><div><div>t= hank you very much for quick response and openldap behavior configuration.&= nbsp;</div><div><br></div><div>how we can ignore to look server name in sub= ject of certificate so I can use LDAP server ip address instead of host nam= e? </div><div><br></div><div>Also want to know if there is any open CV= E which says it is vulnerabilities to use LDAP server ip address instead of= name in ldap configuration. </div><div><br></div><div><br></div><div>= <br></div><div class=3D"ydpf9876065signature"><div><span class=3D"ydpf98760= 65yui_3_7_2_102_1375813203128_121" style=3D"font-family:arial, sans-serif;c= olor:rgb(80, 0, 80);">Thank you,</span><br class=3D"ydpf9876065yui_3_7_2_10= 2_1375813203128_122" style=3D"font-family:arial, sans-serif;color:rgb(80, 0= , 80);"><span class=3D"ydpf9876065yui_3_7_2_102_1375813203128_123" style=3D= "font-family:arial, sans-serif;color:rgb(80, 0, 80);">Darshankumar Mistry</= span><br class=3D"ydpf9876065yui_3_7_2_102_1375813203128_124" style=3D"font= -family:arial, sans-serif;color:rgb(80, 0, 80);"><a href=3D"mailto:darshank= mistry(a)yahoo.com" class=3D"ydpf9876065yui_3_7_2_102_1375813203128_125" styl= e=3D"color:rgb(17, 85, 204);font-family:arial, sans-serif;" rel=3D"nofollow= " target=3D"_blank">darshankmistry(a)yahoo.com</a><br></div></div></div> <div><br></div><div><br></div> =20 </div><div id=3D"ydpb3d55fc2yahoo_quoted_7562650282" class=3D"ydpb3= d55fc2yahoo_quoted"> <div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s= ans-serif;font-size:13px;color:#26282a;"> =20 <div> On Friday, May 10, 2019, 12:58:38 PM PDT, Quanah Gibson= -Mount <quanah(a)symas.com> wrote: </div> <div><br></div> <div><br></div> <div>--On Friday, May 10, 2019 8:52 PM +0000 <a href=3D"mai= lto:darshankmistry@yahoo.com" rel=3D"nofollow" target=3D"_blank">darshankmi= stry(a)yahoo.com</a> wrote:<br><br>> Full_Name: Darshankumar Mistry<br>&gt= ; Version:<br>> OS:<br>> URL: <a href=3D"ftp://ftp.openldap.org/incom= ing/" rel=3D"nofollow" target=3D"_blank">ftp://ftp.openldap.org/incoming/</= a><br>> Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac)<b= r>><br>><br>> I would like to know why Open LDAP behavior was chan= ged where we must<br>> have to configure FQDN name mentioned in certific= ate in order to work LDAP<br>> authentication... else TLS start failing.= <br><br>OpenLDAP has worked this way since I first started using it in 2002= .  This <br>behavior is nothing new.  And this is the correct beh= avior.<br><br>This ITS will be closed.<br><br>--Quanah<br><br><br>--<br><br= >Quanah Gibson-Mount<br>Product Architect<br>Symas Corporation<br>Packaged,= certified, and supported LDAP solutions powered by OpenLDAP:<br><<a hre= f=3D"http://www.symas.com" rel=3D"nofollow" target=3D"_blank">http://www.sy= mas.com</a>><br><br></div> </div> </div></body></html> ------=_Part_545863_1662769086.1557520342175--

1 0

Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by quanah＠symas.com 10 May '19

10 May '19

--On Friday, May 10, 2019 8:52 PM +0000 darshankmistry(a)yahoo.com wrote: > Full_Name: Darshankumar Mistry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) > > > I would like to know why Open LDAP behavior was changed where we must > have to configure FQDN name mentioned in certificate in order to work LDAP > authentication... else TLS start failing. OpenLDAP has worked this way since I first started using it in 2002. This behavior is nothing new. And this is the correct behavior. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by darshankmistry＠yahoo.com 10 May '19

10 May '19

Full_Name: Darshankumar Mistry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) I would like to know why Open LDAP behavior was changed where we must have to configure FQDN name mentioned in certificate in order to work LDAP authentication... else TLS start failing. I am getting below error and I know that I am using IP address of LDAP server in my configuration instead of certificate subject name (FQDN of ldap server) TLS: can't connect: TLS: hostname does not match CN in peer certificate

1 0

Re: (ITS#8708) SASL EXTERNAL binds and sasl-secprops minssf
by quanah＠symas.com 09 May '19

09 May '19

--On Wednesday, May 08, 2019 12:56 PM -0400 David Hawes <dhawes(a)vt.edu> wrote: >> Hi David, >> >> I believe this was fixed with ITS#8796 (part of the 2.4.46 release). Can >> you confirm? > > Confirmed. ITS#8796 fixes #8708. Hi David, Thanks for the quick confirmation! I've closed ITS#8708 and noted that the fix for ITS#8796 resolved it. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9020) Inconsistent cn=config objectClasses for overlays
by quanah＠openldap.org 09 May '19

09 May '19

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) The majority of supported overlays use an objectClass of the format: olcOVERLAYConfig However, there are two overlays that do *not* follow this format, which is confusing. memberOf -> olcMemberOf dynlist -> olcDynamicList For 2.5, I would suggest we change these to be consistent with all the other overlays and document this change in the Admin Guide section on upgrade notes etc.

1 0

Re: (ITS#8708) SASL EXTERNAL binds and sasl-secprops minssf
by quanah＠symas.com 08 May '19

08 May '19

--On Tuesday, August 08, 2017 7:08 PM +0000 dhawes(a)gmail.com wrote: > Full_Name: David Hawes > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:468:c80:2103:0:523:da5e:da5e) Hi David, I believe this was fixed with ITS#8796 (part of the 2.4.46 release). Can you confirm? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8799) slaptest fails to properly convert chain configuration
by ondra＠mistotebe.net 08 May '19

08 May '19

On Mon, Jan 22, 2018 at 11:57:38PM +0000, ondra(a)mistotebe.net wrote: > On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah(a)openldap.org wrote: >> After doing conversion, the resulting cn=config database has *two* ldap backends >> defined: >> >> dn: olcDatabase={-1}frontend,cn=config >> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config >> dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf > > This is the catchall database used to handle referrals that are not > handled by any other database you configure by hand. It collects all the > chain-* settings that appear before the first chain-uri. > >> dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf >> >> The first instance ({0}ldap,...) isn't even valid. If you remove the entire >> chain configuration from this database, and then attempt to import it, you get >> the following: > > Yeah that is a problem. Turns out the problem is different yet. When the overlay is started up after adding its entry, it generates a default backend internally. On adding the above backend it now thinks it has a default one already (even though there is no entry for it yet) and rejects it. >> This is because the first instance ({0}) is *missing* the required olcDbURI >> attribute. In addition, it generates completely bogus attribute values (See >> ITS#8693) > > Maybe we just need to inherit objectclass: olcLdapDatabase somehow in > olcChainOverlay and keep these settings in the overlay entry, or specify > a bogus URI to be configured there. Whatever is most useable and still > allows for seamless expansion. Still thinking making the overlay objectclass inherit the attributes from olcLdapDatabase instead of creating a fake DB but that can't be done for 2.4 and I have no idea how to properly go about that yet anyway. For 2.4 at least it might make sense to just use the flags on the default backend to say it has no entry associated with it (yet) and: - clear that in ldap_chain_cfadd_apply so we know it can be replaced later - also create the entry if slapd is just starting up (How about cn=config replication though? Upgrades need to be planned) - maybe only let a default backend be added if there really is no other backend yet (including the temporary ones used during normal operation), since those will get some defaults from it -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9019) NSSDB + OpenLDAP
by quanah＠symas.com 07 May '19

07 May '19

--On Tuesday, May 07, 2019 10:35 AM +0000 vangelier(a)hotmail.com wrote: > Full_Name: Victor Angelier > Version: OpenLDAP: slapd 2.4.44 > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.78.44.170) > > > When using OpenLDAP with NSS DB in HA setup you can not change the TLS > certificate name through LDIF with ldapmodify. Hello, The MozNSS implementation was done by RedHat. It has since been abandoned by RedHat, although they have left a MozNSS/OpenSSL bridge in place. Any issues with MozNSS and OpenLDAP or OpenLDAP and RedHat's OpenSSL to MozNSS bridge needs to be filed with RedHat as it is not an OpenLDAP issue. If you can reproduce the problem with an OpenLDAP build that is directly linked to OpenSSL without RedHat's MozNSS bridge, please follow up. This ITS will be closed until any such follow up is provided. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9019) NSSDB + OpenLDAP
by vangelier＠hotmail.com 07 May '19

07 May '19

Full_Name: Victor Angelier Version: OpenLDAP: slapd 2.4.44 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.78.44.170) When using OpenLDAP with NSS DB in HA setup you can not change the TLS certificate name through LDIF with ldapmodify. The only way to update the TLS certificate name is by editing the cn=config.ldif file with breaches the signature. This is especially with HA setup a serious issue. Reproduce. Install and setup OpenLDAP in HA (I have 2 nodes) Configure it so that it uses NSS DB cn=config.ldif cat /etc/openldap/slapd.d/cn\=config.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 13782a66 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSProtocolMin: 3.3 olcTLSCipherSuite: ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!EXP:!SSLV2:!eNULL:!SSLV3 olcTLSDHParamFile: /etc/openldap/ssl/dhparams structuralObjectClass: olcGlobal entryUUID: ef483c7c-da8d-1038-907a-df6f97fe6ec7 creatorsName: cn=config createTimestamp: 20190314101611Z olcTLSCACertificatePath: /etc/openldap/ssl olcTLSCACertificateFile: /etc/pki/tls/certs/ca-bundle.crt olcTLSCertificateFile: "Cyberdyne Security" olcTLSCertificateKeyFile: /etc/openldap/ssl/password olcTLSVerifyClient: allow olcServerID: 1 ldaps://ldap-n1.cyberdynesecurity.ae olcServerID: 2 ldaps://ldap-n2.cyberdynesecurity.ae olcLogFile: /var/log/slapd.log entryCSN: 20190507074650.989216Z#000000#001#000000 modifiersName: cn=Manager,dc=cyberdynesecurity,dc=ae modifyTimestamp: 20190507074650Z contextCSN: 20190507074650.989216Z#000000#001#000000 contextCSN: 20190402094130.452589Z#000000#002#000000 Now try change "olcTLSCertificateFile" through LDIF vi change.ldif dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: "new certificate name" ldapmodify -Y EXTERNAL -H ldapi:/// -f edit.ldif -v ldap_initialize( ldapi:///??base ) SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 replace olcTLSCertificateFile: "new certificate name" modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) If "olcTLSCertificateFile" is set to an existing file like /tmp/certificate.crt it works fine.

1 0

Re: (ITS#8349) fix ppolicy issue
by hamano＠osstech.co.jp 07 May '19

07 May '19

Sorry for my late reply. https://www.osstech.co.jp/download/hamano/openldap/ppolicy_fix_pwdInHistory… The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Open Source Solution Technology Corporation. Open Source Solution Technology Corporation has not assigned rights and/or interest in this work to any party. I, HAMANO Tsukasa am authorized by Open Source Solution Technology Corporation, my employer, to release this work under the following terms. Open Source Solution Technology Corporation hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. On Fri, 08 Sep 2017 01:21:42 +0900, Quanah Gibson-Mount wrote: > > --On Tuesday, January 12, 2016 7:28 AM +0000 hamano(a)osstech.co.jp wrote: > > > Full_Name: HAMANO Tsukasa > > Version: 2.4.43 > > OS: Linux > > URL: > > https://www.osstech.co.jp/download/hamano/openldap/ppolicy_fix_pwdInHisto > > ry.patch Submission from: (NULL) (240b:10:2640:bf0:290:4cff:fe0d:f43e) > > > > > > We fixed several issue around ppolicy. > > > > 1) reduce pwdInHistory > > If set pwdInHistory to 5 then reduce pwdInHistory to 3, > > We expect to check password with three history, but ppolicy check > > password with all pwdHistory attribute. > > > > 2) reduce pwdInHistory to zero > > If set pwdInHistory to 5 then reduce pwdInHistory to 0, > > We expect that ppolicy password checking will be disbale. but the > > pwdHistory attribute are remains, so password checking is still > > enabled. > > We need to remove pwdHistory attribute. > > Hi, > > I'm working on catching up on old ITS submissions. This submission is > missing an IPR and cannot be included until it is provided. Please > see <http://www.openldap.org/devel/contributing.html> for information > on the IPR requirements. > > Thanks, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > -- Open Source Solution Technology Corporation HAMANO Tsukasa <hamano(a)osstech.co.jp>

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 06 May '19

06 May '19

--On Friday, February 15, 2019 2:37 PM +0000 hyc(a)openldap.org wrote: > Full_Name: Howard Chu > Version: 2.5 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.233.42.124) > Submitted by: hyc > > > IDLs used for index slots are hardcoded to a max of 65536 elements in the > DB and twice that in memory. Sites with larger DBs tend to need larger > IDLs; if they're running with sufficient memory it ought to be possible > to configure larger IDLs. Per the documentation, this new setting appears to be a new type of "global" option that affects all MDB databases in the configuration. This new setting, per the documentation, must be configured in a "backend mdb" section. However, there appear to be some problems with the implmentation. Issue #1: "backend mdb" requires a "directory" directive Since this is a new "global" concept, "directory" should not be required (and in fact, seems problematc). Issue #2: If a "directory" statement is supplied (see above), slapd core dumps when attempting to convert this configuration to cn=config: The slapd.conf file I'm using to test is: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema modulepath /usr/local/lib64/openldap moduleload back_mdb backend mdb idlexp 32 database mdb directory /var/openldap-data suffix dc=example,dc=com index default eq index objectClass (The directory line location was moved to the "backend" section after initial testing due to issue #1). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 03 May '19

03 May '19

--_E0C027EF-451F-4EC6-B6DE-2F6B94348BB5_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For the sake of putting this in the email thread (other code discussion in = GitHub), here is the latest squashed commit of the proposed patch (with the= on-demand, retained overlapped array to reduce re-malloc and opening event= handles): https://github.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d4= 53aab75ee222072b990f Thanks, Kris From: Kris Zyp Sent: April 30, 2019 12:43 PM To: Howard Chu; openldap-its(a)OpenLDAP.org Subject: RE: (ITS#9017) Improving performance of commit sync in Windows > What is the point of using writemap mode if you still need to use WriteFi= le > on every individual page? As I understood from the documentation, and have observed, using writemap m= ode is faster (and uses less temporary memory) because it doesn=E2=80=99t r= equire mallocs to allocate pages (docs: =E2=80=9CThis is faster and uses fe= wer mallocs=E2=80=9D). To be clear though, LMDB is so incredibly fast and e= fficient, that in sync-mode, it takes enormous transactions before the time= spent allocating and creating the dirty pages with the updated b-tree is a= nywhere even remotely close to the time it takes to wait for disk flushing,= even with an SSD. But the more pertinent question is efficiency, and measu= ring CPU cycles rather than time spent (efficiency is more important than j= ust time spent). When I ran my tests this morning of 100 (sync) transaction= s with 100 puts per transaction, times varied quite a bit, but it seemed li= ke running with writemap enabled typically averages about 500ms of CPU and = with writemap disabled it typically averages around 600ms. Not a huge diffe= rence, but still definitely worthwhile, I think. Caveat emptor: Measuring LMDB performance with sync interactions on Windows= is one of the most frustratingly erratic things to measure. It is sunny ou= tside right now, times could be different when it starts raining later, but= , this is what I saw this morning... > What is the performance difference between your patch using writemap, and= just > not using writemap in the first place? Running 1000 sync transactions on 3GB db with a single put per transaction,= without writemap map, without the patch took about 60 seconds. And it took= about 1 second with the patch with writemap mode enabled! (there is no sig= nificant difference in sync times with writemap enabled or disabled with th= e patch.) So the difference was huge in my test. And not only that, without= the patch, the CPU usage was actually _higher_ during that 60 seconds (clo= se to 100% of a core) than during the execution with the patch for one seco= nd (close to 50%). =C2=A0Anyway, there are certainly tests I have run where= the differences are not as large (doing small commits on large dbs accentu= ates the differences), but the patch always seems to win. It could also be = that my particular configuration causes bigger differences (on an SSD drive= , and maybe a more fragmented file?). Anyway, I added error handling for the malloc, and fixed/changed the other = things you suggested. Be happy to make any other changes you want. The upda= ted patch is here: https://github.com/kriszyp/node-lmdb/commit/25366dea9453749cf6637f43ec17b9b= 62094acde > OVERLAPPED* ov =3D malloc((pagecount - keep) * sizeof(OVERLAPPED)); > Probably this ought to just be pre-allocated based on the maximum number = of dirty pages a txn allows. I wasn=E2=80=99t sure I understood this comment. Are you suggesting we mall= oc(MDB_IDL_UM_MAX * sizeof(OVERLAPPED)) for each environment, and retain it= for the life of the environment? I think that is 4MB, if my math is right,= which seems like a lot of memory to keep allocated (we usually have a lot = of open environments). If the goal is to reduce the number of mallocs, how = about we retain the OVERLAPPED array, and only free and re-malloc if the pr= evious allocation wasn=E2=80=99t large enough? Then there isn=E2=80=99t unn= ecessary allocation, and we only malloc when there is a bigger transaction = than any previous. I put this together in a separate commit, as I wasn=E2= =80=99t sure if this what you wanted (can squash if you prefer): https://gi= thub.com/kriszyp/node-lmdb/commit/2fe68fb5269c843e2e789746a17a4b2adefaac40 Thank you for the review!=20 Thanks, Kris From: Howard Chu Sent: April 30, 2019 7:12 AM To: kriszyp(a)gmail.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9017) Improving performance of commit sync in Windows kriszyp(a)gmail.com wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.23 > OS: Windows > URL: https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74= a0ab9332b7fc4ce9 > Submission from: (NULL) (71.199.6.148) >=20 >=20 > We have seen very poor performance on the sync of commits on large databa= ses in > Windows. On databases with 2GB of data, in writemap mode, the sync of eve= n small > commits is consistently well over 100ms (without writemap it is faster, b= ut > still slow). It is expected that a sync should take some time while waiti= ng for > disk confirmation of the writes, but more concerning is that these sync > operations (in writemap mode) are instead dominated by nearly 100% system= CPU > utilization, so operations that requires sub-millisecond b-tree update > operations are then dominated by very large amounts of system CPU cycles = during > the sync phase. >=20 > I think that the fundamental problem is that FlushViewOfFile seems to be = an O(n) > operation where n is the size of the file (or map). I presume that Window= s is > scanning the entire map/file for dirty pages to flush, I'm guessing becau= se it > doesn't have an internal index of all the dirty pages for every file/map-= view in > the OS disk cache. Therefore, the turns into an extremely expensive, CPU-= bound > operation to find the dirty pages for (large file) and initiate their wri= tes, > which, of course, is contrary to the whole goal of a scalable database sy= stem. > And FlushFileBuffers is also relatively slow as well. We have attempted t= o batch > as many operations into single transaction as possible, but this is still= a very > large overhead. >=20 > The Windows docs for FlushFileBuffers itself warns about the inefficienci= es of > this function (https://docs.microsoft.com/en-us/windows/desktop/api/filea= pi/nf-fileapi-flushfilebuffers). > Which also points to the solution: it is much faster to write out the dir= ty > pages with WriteFile through a sync file handle (FILE_FLAG_WRITE_THROUGH)= . >=20 > The associated patch > (https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab= 9332b7fc4ce9) > is my attempt at implementing this solution, for Windows. Fortunately, wi= th the > design of LMDB, this is relatively straightforward. LMDB already supports > writing out dirty pages with WriteFile calls. I added a write-through han= dle for > sending these writes directly to disk. I then made that file-handle > overlapped/asynchronously, so all the writes for a commit could be starte= d in > overlap mode, and (at least theoretically) transfer in parallel to the dr= ive and > then used GetOverlappedResult to wait for the completion. So basically > mdb_page_flush becomes the sync. I extended the writing of dirty pages th= rough > WriteFile to writemap mode as well (for writing meta too), so that WriteF= ile > with write-through can be used to flush the data without ever needing to = call > FlushViewOfFile or FlushFileBuffers. I also implemented support for write > gathering in writemap mode where contiguous file positions infers contigu= ous > memory (by tracking the starting position with wdp and writing contiguous= pages > in single operations). Sorting of the dirty list is maintained even in wr= itemap > mode for this purpose. What is the point of using writemap mode if you still need to use WriteFile on every individual page? > The performance benefits of this patch, in my testing, are considerable. = Writing > out/syncing transactions is typically over 5x faster in writemap mode, an= d 2x > faster in standard mode. And perhaps more importantly (especially in envi= ronment > with many threads/processes), the efficiency benefits are even larger, > particularly in writemap mode, where there can be a 50-100x reduction in = the > system CPU usage by using this patch. This brings windows performance wit= h > sync'ed transactions in LMDB back into the range of "lightning" performan= ce :). What is the performance difference between your patch using writemap, and j= ust not using writemap in the first place? --=20 =C2=A0=C2=A0-- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 http://www.symas.com =C2=A0 Director, Highland Sun=C2=A0=C2=A0=C2=A0=C2=A0 http://highlandsun.co= m/hyc/ =C2=A0 Chief Architect, OpenLDAP=C2=A0 http://www.openldap.org/project/ --_E0C027EF-451F-4EC6-B6DE-2F6B94348BB5_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1><p class=3DMsoNormal>For the sake of putting this in the = email thread (other code discussion in GitHub), here is the latest squashed= commit of the proposed patch (with the on-demand, retained overlapped arra= y to reduce re-malloc and opening event handles): https://github.com/kriszy= p/node-lmdb/commit/726a9156662c703bf3d453aab75ee222072b990f</p><p class=3DM= soNormal><o:p> </o:p></p><p class=3DMsoNormal>Thanks,<br>Kris</p><p cl= ass=3DMsoNormal><o:p> </o:p></p><div style=3D'mso-element:para-border-= div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><= p class=3DMsoNormal style=3D'border:none;padding:0cm'><b>From: </b><a href= =3D"mailto:kriszyp@gmail.com">Kris Zyp</a><br><b>Sent: </b>April 30, 2019 1= 2:43 PM<br><b>To: </b><a href=3D"mailto:hyc@symas.com">Howard Chu</a>; <a h= ref=3D"mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</a><br><= b>Subject: </b>RE: (ITS#9017) Improving performance of commit sync in Windo= ws</p></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>= > What is the point of using writemap mode if you still need to use Writ= eFile<o:p></o:p></p><p class=3DMsoNormal>> on every individual page?<o:p= ></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>A= s I understood from the documentation, and have observed, using writemap mo= de is faster (and uses less temporary memory) because it doesn=E2=80=99t re= quire mallocs to allocate pages (docs: =E2=80=9CThis is faster and uses few= er mallocs=E2=80=9D). To be clear though, LMDB is so incredibly fast and ef= ficient, that in sync-mode, it takes enormous transactions before the time = spent allocating and creating the dirty pages with the updated b-tree is an= ywhere even remotely close to the time it takes to wait for disk flushing, = even with an SSD. But the more pertinent question is efficiency, and measur= ing CPU cycles rather than time spent (efficiency is more important than ju= st time spent). When I ran my tests this morning of 100 (sync) transactions= with 100 puts per transaction, times varied quite a bit, but it seemed lik= e running with writemap enabled typically averages about 500ms of CPU and w= ith writemap disabled it typically averages around 600ms. Not a huge differ= ence, but still definitely worthwhile, I think.<o:p></o:p></p><p class=3DMs= oNormal><o:p> </o:p></p><p class=3DMsoNormal>Caveat emptor: Measuring = LMDB performance with sync interactions on Windows is one of the most frust= ratingly erratic things to measure. It is sunny outside right now, times co= uld be different when it starts raining later, but, this is what I saw this= morning...<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p clas= s=3DMsoNormal>> What is the performance difference between your patch us= ing writemap, and just<o:p></o:p></p><p class=3DMsoNormal>> not using wr= itemap in the first place?<o:p></o:p></p><p class=3DMsoNormal><o:p> </= o:p></p><p class=3DMsoNormal>Running 1000 sync transactions on 3GB db with = a single put per transaction, without writemap map, without the patch took = about 60 seconds. And it took about 1 second with the patch with writemap m= ode enabled! (there is no significant difference in sync times with writema= p enabled or disabled with the patch.) So the difference was huge in my tes= t. And not only that, without the patch, the CPU usage was actually _<i>hig= her</i>_ during that 60 seconds (close to 100% of a core) than during the e= xecution with the patch for one second (close to 50%).  Anyway, there = are certainly tests I have run where the differences are not as large (doin= g small commits on large dbs accentuates the differences), but the patch al= ways seems to win. It could also be that my particular configuration causes= bigger differences (on an SSD drive, and maybe a more fragmented file?).<o= :p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal= >Anyway, I added error handling for the malloc, and fixed/changed the other= things you suggested. Be happy to make any other changes you want. The upd= ated patch is here:<o:p></o:p></p><p class=3DMsoNormal>https://github.com/k= riszyp/node-lmdb/commit/25366dea9453749cf6637f43ec17b9b62094acde<o:p></o:p>= </p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>><spa= n class=3Dblob-code-inner><span style=3D'font-size:9.0pt;font-family:Consol= as;color:#24292E'> OVERLAPPED* ov =3D </span></span><span class=3Dpl-c1><sp= an style=3D'font-size:9.0pt;font-family:Consolas;color:#005CC5'>malloc</spa= n></span><span class=3Dblob-code-inner><span style=3D'font-size:9.0pt;font-= family:Consolas;color:#24292E'>((pagecount - keep) * </span></span><span cl= ass=3Dpl-k><span style=3D'font-size:9.0pt;font-family:Consolas;color:#D73A4= 9'>sizeof</span></span><span class=3Dblob-code-inner><span style=3D'font-si= ze:9.0pt;font-family:Consolas;color:#24292E'>(OVERLAPPED));</span></span><s= pan class=3Dblob-code-inner><span style=3D'font-size:9.0pt;font-family:Cons= olas;color:#24292E'><o:p></o:p></span></span></p><p class=3DMsoNormal><span= class=3Dblob-code-inner><span style=3D'font-size:9.0pt;font-family:Consola= s;color:#24292E'>> </span></span><span style=3D'font-size:10.5pt;font-fa= mily:"Segoe UI",sans-serif;color:#24292E;background:white'>Probably this ou= ght to just be pre-allocated based on the maximum number of dirty pages a t= xn allows.</span><span style=3D'font-size:10.5pt;font-family:"Segoe UI",san= s-serif;background:white'><o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#24292E;b= ackground:white'><o:p> </o:p></span></p><p class=3DMsoNormal><span sty= le=3D'font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#24292E;back= ground:white'>I wasn=E2=80=99t sure I understood this comment. Are you sugg= esting we </span>malloc(MDB_IDL_UM_MAX * sizeof(OVERLAPPED)) for each envir= onment, and retain it for the life of the environment? I think that is 4MB,= if my math is right, which seems like a lot of memory to keep allocated (w= e usually have a lot of open environments). If the goal is to reduce the nu= mber of mallocs, how about we retain the OVERLAPPED array, and only free an= d re-malloc if the previous allocation wasn=E2=80=99t large enough? Then th= ere isn=E2=80=99t unnecessary allocation, and we only malloc when there is = a bigger transaction than any previous. I put this together in a separate c= ommit, as I wasn=E2=80=99t sure if this what you wanted (can squash if you = prefer): https://github.com/kriszyp/node-lmdb/commit/2fe68fb5269c843e2e7897= 46a17a4b2adefaac40<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p>= <p class=3DMsoNormal>Thank you for the review! <span style=3D'font-size:10.= 5pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white'><o:p>= </o:p></span></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNo= rmal>Thanks,<br>Kris<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></= p><div style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0c= m 0cm 0cm'><p class=3DMsoNormal><b>From: </b><a href=3D"mailto:hyc@symas.co= m">Howard Chu</a><br><b>Sent: </b>April 30, 2019 7:12 AM<br><b>To: </b><a h= ref=3D"mailto:kriszyp@gmail.com">kriszyp(a)gmail.com</a>; <a href=3D"mailto:o= penldap-its(a)OpenLDAP.org">openldap-its(a)OpenLDAP.org</a><br><b>Subject: </b>= Re: (ITS#9017) Improving performance of commit sync in Windows<o:p></o:p></= p></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>kris= zyp(a)gmail.com wrote:<o:p></o:p></p><p class=3DMsoNormal>> Full_Name: Kri= stopher William Zyp<o:p></o:p></p><p class=3DMsoNormal>> Version: LMDB 0= .9.23<o:p></o:p></p><p class=3DMsoNormal>> OS: Windows<o:p></o:p></p><p = class=3DMsoNormal>> URL: https://github.com/kriszyp/node-lmdb/commit/7ff= 525ae57684a163d32af74a0ab9332b7fc4ce9<o:p></o:p></p><p class=3DMsoNormal>&g= t; Submission from: (NULL) (71.199.6.148)<o:p></o:p></p><p class=3DMsoNorma= l>> <o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class=3DM= soNormal>> We have seen very poor performance on the sync of commits on = large databases in<o:p></o:p></p><p class=3DMsoNormal>> Windows. On data= bases with 2GB of data, in writemap mode, the sync of even small<o:p></o:p>= </p><p class=3DMsoNormal>> commits is consistently well over 100ms (with= out writemap it is faster, but<o:p></o:p></p><p class=3DMsoNormal>> stil= l slow). It is expected that a sync should take some time while waiting for= <o:p></o:p></p><p class=3DMsoNormal>> disk confirmation of the writes, b= ut more concerning is that these sync<o:p></o:p></p><p class=3DMsoNormal>&g= t; operations (in writemap mode) are instead dominated by nearly 100% syste= m CPU<o:p></o:p></p><p class=3DMsoNormal>> utilization, so operations th= at requires sub-millisecond b-tree update<o:p></o:p></p><p class=3DMsoNorma= l>> operations are then dominated by very large amounts of system CPU cy= cles during<o:p></o:p></p><p class=3DMsoNormal>> the sync phase.<o:p></o= :p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class=3DMsoNormal>> I= think that the fundamental problem is that FlushViewOfFile seems to be an = O(n)<o:p></o:p></p><p class=3DMsoNormal>> operation where n is the size = of the file (or map). I presume that Windows is<o:p></o:p></p><p class=3DMs= oNormal>> scanning the entire map/file for dirty pages to flush, I'm gue= ssing because it<o:p></o:p></p><p class=3DMsoNormal>> doesn't have an in= ternal index of all the dirty pages for every file/map-view in<o:p></o:p></= p><p class=3DMsoNormal>> the OS disk cache. Therefore, the turns into an= extremely expensive, CPU-bound<o:p></o:p></p><p class=3DMsoNormal>> ope= ration to find the dirty pages for (large file) and initiate their writes,<= o:p></o:p></p><p class=3DMsoNormal>> which, of course, is contrary to th= e whole goal of a scalable database system.<o:p></o:p></p><p class=3DMsoNor= mal>> And FlushFileBuffers is also relatively slow as well. We have atte= mpted to batch<o:p></o:p></p><p class=3DMsoNormal>> as many operations i= nto single transaction as possible, but this is still a very<o:p></o:p></p>= <p class=3DMsoNormal>> large overhead.<o:p></o:p></p><p class=3DMsoNorma= l>> <o:p></o:p></p><p class=3DMsoNormal>> The Windows docs for FlushF= ileBuffers itself warns about the inefficiencies of<o:p></o:p></p><p class= =3DMsoNormal>> this function (https://docs.microsoft.com/en-us/windows/d= esktop/api/fileapi/nf-fileapi-flushfilebuffers).<o:p></o:p></p><p class=3DM= soNormal>> Which also points to the solution: it is much faster to write= out the dirty<o:p></o:p></p><p class=3DMsoNormal>> pages with WriteFile= through a sync file handle (FILE_FLAG_WRITE_THROUGH).<o:p></o:p></p><p cla= ss=3DMsoNormal>> <o:p></o:p></p><p class=3DMsoNormal>> The associated= patch<o:p></o:p></p><p class=3DMsoNormal>> (https://github.com/kriszyp/= node-lmdb/commit/7ff525ae57684a163d32af74a0ab9332b7fc4ce9)<o:p></o:p></p><p= class=3DMsoNormal>> is my attempt at implementing this solution, for Wi= ndows. Fortunately, with the<o:p></o:p></p><p class=3DMsoNormal>> design= of LMDB, this is relatively straightforward. LMDB already supports<o:p></o= :p></p><p class=3DMsoNormal>> writing out dirty pages with WriteFile cal= ls. I added a write-through handle for<o:p></o:p></p><p class=3DMsoNormal>&= gt; sending these writes directly to disk. I then made that file-handle<o:p= ></o:p></p><p class=3DMsoNormal>> overlapped/asynchronously, so all the = writes for a commit could be started in<o:p></o:p></p><p class=3DMsoNormal>= > overlap mode, and (at least theoretically) transfer in parallel to the= drive and<o:p></o:p></p><p class=3DMsoNormal>> then used GetOverlappedR= esult to wait for the completion. So basically<o:p></o:p></p><p class=3DMso= Normal>> mdb_page_flush becomes the sync. I extended the writing of dirt= y pages through<o:p></o:p></p><p class=3DMsoNormal>> WriteFile to writem= ap mode as well (for writing meta too), so that WriteFile<o:p></o:p></p><p = class=3DMsoNormal>> with write-through can be used to flush the data wit= hout ever needing to call<o:p></o:p></p><p class=3DMsoNormal>> FlushView= OfFile or FlushFileBuffers. I also implemented support for write<o:p></o:p>= </p><p class=3DMsoNormal>> gathering in writemap mode where contiguous f= ile positions infers contiguous<o:p></o:p></p><p class=3DMsoNormal>> mem= ory (by tracking the starting position with wdp and writing contiguous page= s<o:p></o:p></p><p class=3DMsoNormal>> in single operations). Sorting of= the dirty list is maintained even in writemap<o:p></o:p></p><p class=3DMso= Normal>> mode for this purpose.<o:p></o:p></p><p class=3DMsoNormal><o:p>=  </o:p></p><p class=3DMsoNormal>What is the point of using writemap mo= de if you still need to use WriteFile<o:p></o:p></p><p class=3DMsoNormal>on= every individual page?<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p= ></p><p class=3DMsoNormal>> The performance benefits of this patch, in m= y testing, are considerable. Writing<o:p></o:p></p><p class=3DMsoNormal>&gt= ; out/syncing transactions is typically over 5x faster in writemap mode, an= d 2x<o:p></o:p></p><p class=3DMsoNormal>> faster in standard mode. And p= erhaps more importantly (especially in environment<o:p></o:p></p><p class= =3DMsoNormal>> with many threads/processes), the efficiency benefits are= even larger,<o:p></o:p></p><p class=3DMsoNormal>> particularly in write= map mode, where there can be a 50-100x reduction in the<o:p></o:p></p><p cl= ass=3DMsoNormal>> system CPU usage by using this patch. This brings wind= ows performance with<o:p></o:p></p><p class=3DMsoNormal>> sync'ed transa= ctions in LMDB back into the range of "lightning" performance :).= <o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorm= al>What is the performance difference between your patch using writemap, an= d just<o:p></o:p></p><p class=3DMsoNormal>not using writemap in the first p= lace?<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMs= oNormal>-- <o:p></o:p></p><p class=3DMsoNormal>  -- Howard Chu<o:= p></o:p></p><p class=3DMsoNormal>  CTO, Symas Corp.   &= nbsp;       http://www.symas.com<o:p></o:p></= p><p class=3DMsoNormal>  Director, Highland Sun   &nbsp= ; http://highlandsun.com/hyc/<o:p></o:p></p><p class=3DMsoNormal>  Chi= ef Architect, OpenLDAP  http://www.openldap.org/project/<o:p></o:p></p= ><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> = </o:p></p></div></body></html>= --_E0C027EF-451F-4EC6-B6DE-2F6B94348BB5_--

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by quanah＠symas.com 03 May '19

03 May '19

--On Wednesday, April 24, 2019 9:23 PM +0000 siddjain(a)live.com wrote: > --_000_MWHPR08MB2400D7AE5E8EEC3D17192FACB53C0MWHPR08MB2400namp_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Thank you. we tried using another openldap image and that worked. so it > see= ms the problem is with the osixia docker image we were using to run > openlda= p. it is based on debian (which uses GnuTLS per your email) so > tbh we are s= urprised it would have such a bug in it. the image that > worked for us is ba= sed on alpine. > https://github.com/osixia/docker-light-baseimage/blob/stable/image/Docker > fi= le > https://github.com/tiredofit/docker-openldap/blob/master/Dockerfile > but back to your comment, how can one isolate what TLS/SSL library > OpenLDAP= is linked to in the environment you're using? Use the "ldd" command or similar to see what libraries it is linked to. I see you filed a bug against Osixia, however the bug should be filed against GnuTLS, as that's where the issue is. This ITS will be closed as it is not OpenLDAP related. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8314) ldap_back_is_proxy_authz returned 0 - misconfigured uri? - Maybe a Bug?
by quanah＠symas.com 03 May '19

03 May '19

--On Friday, May 03, 2019 5:22 PM +0000 dominiks.mail(a)gmx.net wrote: > 2. flags=3Doverride > After I added the flags=3Doverride setting in the idassert-bind section > the problem was gone and everything works for me. I don't know if it's a > good approach but at least it works for now with our openLDAP backend > server. Prior to OpenLDAP 2.4.33 where ITS#7403 was fixed (8829115c76), back-ldap would always behave as if the "override" flag had been set if the idassert-bind directive has been configured. I.e., the previously working configuration depended upon a bug and that bug was fixed. This ITS will be closed as back-ldap is functioning as designed and documented in the slapd-ldap(5) man page. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8314) ldap_back_is_proxy_authz returned 0 - misconfigured uri? - Maybe a Bug?
by dominiks.mail＠gmx.net 03 May '19

03 May '19

Hi, I know this topic is years old but I faced the same issue today, running the current version of OpenLDAP. The problem can also occur when using the translucent backend. While troubleshooting the issue, I found two possible workarounds for our setup. 1. acl-bind Instead of using idassert-bind I used acl-bind. The connection problem "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?" didn't happen anymore, but since I got different results with my search filters, it wasn't sufficient. 2. flags=3Doverride After I added the flags=3Doverride setting in the idassert-bind section the problem was gone and everything works for me. I don't know if it's a good approach but at least it works for now with our openLDAP backend server. =2D- Regards Dominik

1 0

(ITS#8314) ldap_back_is_proxy_authz returned 0 - misconfigured uri? - Maybe a Bug?
by dominiks.mail＠gmx.net 03 May '19

03 May '19

Hi, I know this topic is years old but I faced the same issue today, running the current version of OpenLDAP. The problem can also occur when using the translucent backend. While troubleshooting the issue, I found two possible workarounds for our setup. 1. acl-bind Instead of using idassert-bind I used acl-bind. The connection problem "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?" didn't happen anymore, but since I got different results with my search filters, it wasn't sufficient. 2. flags=3Doverride After I added the flags=3Doverride setting in the idassert-bind section the problem was gone and everything works for me. I don't know if it's a good approach but at least it works for now with our openLDAP backend server. =2D- Regards Dominik

1 0

(ITS#9018) dynlist don't close connection
by i.harbuz＠velcom.by 02 May '19

02 May '19

Full_Name: Ihar Harbuz Version: 2.4.44 OS: RHEL 7.6 URL: http://ftp.openldap.org/incoming/ Submission from: (NULL) (128.140.241.193) Good day. I have next configuration: ######################################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/nis.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap moduleload back_ldap.la moduleload back_meta.la moduleload dynlist.la moduleload memberof.la moduleload deref.la overlay dynlist dynlist-attrset posixGroup labeledURI database meta suffix "dc=main,dc=company,dc=by" uri "ldap://dc1-cont.main.company.by/dc=main,dc=company,dc=by" "ldap://dc2-cont.main.company.by/" idassert-bind bindmethod=simple binddn="CN=ldapproxy,OU=ServiceAccounts,DC=MAIN,DC=company,DC=BY" credentials="XXXXXXXXXXXXXXX" mode=none idassert-authzFrom * rebind-as-user yes subordinate rewriteEngine on rewriteContext searchFilter rewriteRule "RecursiveMemberOf=(.*),dc=by" "memberOf:1.2.840.113556.1.4.1941:=%1,dc=by" ":" database meta suffix "dc=external,dc=company,dc=by" uri "ldap://edc1-cont.main.company.by/dc=external,dc=company,dc=by" "ldap://edc2-cont.main.company.by/" idassert-bind bindmethod=simple binddn="CN=ldapproxy,DC=external,DC=company,DC=by" credentials="XXXXXXXXXXXXXXXXXXXX" mode=none idassert-authzFrom * rebind-as-user yes subordinate rewriteEngine on rewriteContext searchFilter rewriteRule "RecursiveMemberOf=(.*),dc=by" "memberOf:1.2.840.113556.1.4.1941:=%1,dc=by" ":" database hdb suffix "dc=company,dc=by" directory /var/lib/ldap rootdn cn=ldapadm,dc=company,dc=by rootpw "XXXXXXXXXX" index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub database monitor ##################################################################################### Any ldapsearch commands work fine if request doesn't hit into dynlist. If request hit in dynlist then it output information and hanged up. slapd -d -1 write: ber_flush2: 1441 bytes to sd 15 0000: 30 82 05 9d 02 01 02 64 82 05 96 04 4c 63 6e 3d 0......d....Lcn= 0010: 53 47 5f 4f 53 5f 53 4f 4c 41 52 49 53 2c 6f 75 SG_OS_SOLARIS,ou 0020: 3d 53 65 63 75 72 69 74 79 20 47 72 6f 75 70 73 =Security Groups ................. ldap_write: want=1441, written=1441 0000: 30 82 05 9d 02 01 02 64 82 05 96 04 4c 63 6e 3d 0......d....Lcn= 0010: 53 47 5f 4f 53 5f 53 4f 4c 41 52 49 53 2c 6f 75 SG_OS_SOLARIS,ou 0020: 3d 53 65 63 75 72 69 74 79 20 47 72 6f 75 70 73 =Security Groups ................. 5ccac7d7 <= send_search_entry: conn 1000 exit. ldap_msgfree And wait while I interrupt request on client. After it: 5ccac856 daemon: activity on 1 descriptor 5ccac856 daemon: activity on: 15r 5ccac856 daemon: read active on 15 5ccac856 daemon: epoll: listen=7 active_threads=0 tvp=NULL 5ccac856 daemon: epoll: listen=8 active_threads=0 tvp=NULL 5ccac856 connection_get(15) 5ccac856 connection_get(15): got connid=1000 5ccac856 connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=8, got=0 5ccac856 ber_get_next on fd 15 failed errno=0 (Success) 5ccac856 connection_read(15): input error=-2 id=1000, closing. 5ccac856 connection_closing: readying conn=1000 sd=15 for close 5ccac856 connection_close: deferring conn=1000 sd=15 5ccac856 daemon: activity on 1 descriptor 5ccac856 daemon: activity on: 5ccac856 daemon: epoll: listen=7 active_threads=0 tvp=NULL 5ccac856 daemon: epoll: listen=8 active_threads=0 tvp=NULL 5ccac856 connection_resched: attempting closing conn=1000 sd=15 5ccac856 connection_close: conn=1000 sd=15 5ccac856 =>meta_back_conn_destroy: fetching conn=1000 DN="cn=solaris,dc=company,dc=by" 5ccac856 =>meta_back_conn_destroy: destroying conn 1000 refcnt=0 flags=0x00000100 ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 18 0000: 30 05 02 01 04 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 04 42 00 0....B. ldap_free_connection: actually freed ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 17 0000: 30 05 02 01 04 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 04 42 00 0....B. ldap_free_connection: actually freed ldap_msgfree 5ccac856 =>meta_back_conn_destroy: fetching conn=1000 DN="cn=solaris,dc=company,dc=by" 5ccac856 daemon: removing 15 5ccac856 conn=1000 fd=15 closed (connection lost) In client side it's look like: ldapsearch -b .... ... USERPRINCIPALNAME: test1(a)MAIN.COMPANY.BY USERPRINCIPALNAME: test2(a)MAIN.COMPANY.BY ^C

1 0

RE: (ITS#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 30 Apr '19

30 Apr '19

--_F6B70E9A-5F12-495E-A3D8-F48F4F20717D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > What is the point of using writemap mode if you still need to use WriteFi= le > on every individual page? As I understood from the documentation, and have observed, using writemap m= ode is faster (and uses less temporary memory) because it doesn=E2=80=99t r= equire mallocs to allocate pages (docs: =E2=80=9CThis is faster and uses fe= wer mallocs=E2=80=9D). To be clear though, LMDB is so incredibly fast and e= fficient, that in sync-mode, it takes enormous transactions before the time= spent allocating and creating the dirty pages with the updated b-tree is a= nywhere even remotely close to the time it takes to wait for disk flushing,= even with an SSD. But the more pertinent question is efficiency, and measu= ring CPU cycles rather than time spent (efficiency is more important than j= ust time spent). When I ran my tests this morning of 100 (sync) transaction= s with 100 puts per transaction, times varied quite a bit, but it seemed li= ke running with writemap enabled typically averages about 500ms of CPU and = with writemap disabled it typically averages around 600ms. Not a huge diffe= rence, but still definitely worthwhile, I think. Caveat emptor: Measuring LMDB performance with sync interactions on Windows= is one of the most frustratingly erratic things to measure. It is sunny ou= tside right now, times could be different when it starts raining later, but= , this is what I saw this morning... > What is the performance difference between your patch using writemap, and= just > not using writemap in the first place? Running 1000 sync transactions on 3GB db with a single put per transaction,= without writemap map, without the patch took about 60 seconds. And it took= about 1 second with the patch with writemap mode enabled! (there is no sig= nificant difference in sync times with writemap enabled or disabled with th= e patch.) So the difference was huge in my test. And not only that, without= the patch, the CPU usage was actually _higher_ during that 60 seconds (clo= se to 100% of a core) than during the execution with the patch for one seco= nd (close to 50%). Anyway, there are certainly tests I have run where the = differences are not as large (doing small commits on large dbs accentuates = the differences), but the patch always seems to win. It could also be that = my particular configuration causes bigger differences (on an SSD drive, and= maybe a more fragmented file?). Anyway, I added error handling for the malloc, and fixed/changed the other = things you suggested. Be happy to make any other changes you want. The upda= ted patch is here: https://github.com/kriszyp/node-lmdb/commit/25366dea9453749cf6637f43ec17b9b= 62094acde > OVERLAPPED* ov =3D malloc((pagecount - keep) * sizeof(OVERLAPPED)); > Probably this ought to just be pre-allocated based on the maximum number = of dirty pages a txn allows. I wasn=E2=80=99t sure I understood this comment. Are you suggesting we mall= oc(MDB_IDL_UM_MAX * sizeof(OVERLAPPED)) for each environment, and retain it= for the life of the environment? I think that is 4MB, if my math is right,= which seems like a lot of memory to keep allocated (we usually have a lot = of open environments). If the goal is to reduce the number of mallocs, how = about we retain the OVERLAPPED array, and only free and re-malloc if the pr= evious allocation wasn=E2=80=99t large enough? Then there isn=E2=80=99t unn= ecessary allocation, and we only malloc when there is a bigger transaction = than any previous. I put this together in a separate commit, as I wasn=E2= =80=99t sure if this what you wanted (can squash if you prefer): https://gi= thub.com/kriszyp/node-lmdb/commit/2fe68fb5269c843e2e789746a17a4b2adefaac40 Thank you for the review!=20 Thanks, Kris From: Howard Chu Sent: April 30, 2019 7:12 AM To: kriszyp(a)gmail.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9017) Improving performance of commit sync in Windows kriszyp(a)gmail.com wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.23 > OS: Windows > URL: https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74= a0ab9332b7fc4ce9 > Submission from: (NULL) (71.199.6.148) >=20 >=20 > We have seen very poor performance on the sync of commits on large databa= ses in > Windows. On databases with 2GB of data, in writemap mode, the sync of eve= n small > commits is consistently well over 100ms (without writemap it is faster, b= ut > still slow). It is expected that a sync should take some time while waiti= ng for > disk confirmation of the writes, but more concerning is that these sync > operations (in writemap mode) are instead dominated by nearly 100% system= CPU > utilization, so operations that requires sub-millisecond b-tree update > operations are then dominated by very large amounts of system CPU cycles = during > the sync phase. >=20 > I think that the fundamental problem is that FlushViewOfFile seems to be = an O(n) > operation where n is the size of the file (or map). I presume that Window= s is > scanning the entire map/file for dirty pages to flush, I'm guessing becau= se it > doesn't have an internal index of all the dirty pages for every file/map-= view in > the OS disk cache. Therefore, the turns into an extremely expensive, CPU-= bound > operation to find the dirty pages for (large file) and initiate their wri= tes, > which, of course, is contrary to the whole goal of a scalable database sy= stem. > And FlushFileBuffers is also relatively slow as well. We have attempted t= o batch > as many operations into single transaction as possible, but this is still= a very > large overhead. >=20 > The Windows docs for FlushFileBuffers itself warns about the inefficienci= es of > this function (https://docs.microsoft.com/en-us/windows/desktop/api/filea= pi/nf-fileapi-flushfilebuffers). > Which also points to the solution: it is much faster to write out the dir= ty > pages with WriteFile through a sync file handle (FILE_FLAG_WRITE_THROUGH)= . >=20 > The associated patch > (https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab= 9332b7fc4ce9) > is my attempt at implementing this solution, for Windows. Fortunately, wi= th the > design of LMDB, this is relatively straightforward. LMDB already supports > writing out dirty pages with WriteFile calls. I added a write-through han= dle for > sending these writes directly to disk. I then made that file-handle > overlapped/asynchronously, so all the writes for a commit could be starte= d in > overlap mode, and (at least theoretically) transfer in parallel to the dr= ive and > then used GetOverlappedResult to wait for the completion. So basically > mdb_page_flush becomes the sync. I extended the writing of dirty pages th= rough > WriteFile to writemap mode as well (for writing meta too), so that WriteF= ile > with write-through can be used to flush the data without ever needing to = call > FlushViewOfFile or FlushFileBuffers. I also implemented support for write > gathering in writemap mode where contiguous file positions infers contigu= ous > memory (by tracking the starting position with wdp and writing contiguous= pages > in single operations). Sorting of the dirty list is maintained even in wr= itemap > mode for this purpose. What is the point of using writemap mode if you still need to use WriteFile on every individual page? > The performance benefits of this patch, in my testing, are considerable. = Writing > out/syncing transactions is typically over 5x faster in writemap mode, an= d 2x > faster in standard mode. And perhaps more importantly (especially in envi= ronment > with many threads/processes), the efficiency benefits are even larger, > particularly in writemap mode, where there can be a 50-100x reduction in = the > system CPU usage by using this patch. This brings windows performance wit= h > sync'ed transactions in LMDB back into the range of "lightning" performan= ce :). What is the performance difference between your patch using writemap, and j= ust not using writemap in the first place? --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --_F6B70E9A-5F12-495E-A3D8-F48F4F20717D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1><p class=3DMsoNormal>> What is the point of using writ= emap mode if you still need to use WriteFile<o:p></o:p></p><p class=3DMsoNo= rmal>> on every individual page?</p><p class=3DMsoNormal><o:p> </o:= p></p><p class=3DMsoNormal>As I understood from the documentation, and have= observed, using writemap mode is faster (and uses less temporary memory) b= ecause it doesn=E2=80=99t require mallocs to allocate pages (docs: =E2=80= =9CThis is faster and uses fewer mallocs=E2=80=9D). To be clear though, LMD= B is so incredibly fast and efficient, that in sync-mode, it takes enormous= transactions before the time spent allocating and creating the dirty pages= with the updated b-tree is anywhere even remotely close to the time it tak= es to wait for disk flushing, even with an SSD. But the more pertinent ques= tion is efficiency, and measuring CPU cycles rather than time spent (effici= ency is more important than just time spent). When I ran my tests this morn= ing of 100 (sync) transactions with 100 puts per transaction, times varied = quite a bit, but it seemed like running with writemap enabled typically ave= rages about 500ms of CPU and with writemap disabled it typically averages a= round 600ms. Not a huge difference, but still definitely worthwhile, I thin= k.</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Caveat= emptor: Measuring LMDB performance with sync interactions on Windows is on= e of the most frustratingly erratic things to measure. It is sunny outside = right now, times could be different when it starts raining later, but, this= is what I saw this morning...<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbs= p;</o:p></p><p class=3DMsoNormal>> What is the performance difference be= tween your patch using writemap, and just<o:p></o:p></p><p class=3DMsoNorma= l>> not using writemap in the first place?<o:p></o:p></p><p class=3DMsoN= ormal><o:p> </o:p></p><p class=3DMsoNormal>Running 1000 sync transacti= ons on 3GB db with a single put per transaction, without writemap map, with= out the patch took about 60 seconds. And it took about 1 second with the pa= tch with writemap mode enabled! (there is no significant difference in sync= times with writemap enabled or disabled with the patch.) So the difference= was huge in my test. And not only that, without the patch, the CPU usage w= as actually _<i>higher</i>_ during that 60 seconds (close to 100% of a core= ) than during the execution with the patch for one second (close to 50%). = =C2=A0Anyway, there are certainly tests I have run where the differences ar= e not as large (doing small commits on large dbs accentuates the difference= s), but the patch always seems to win. It could also be that my particular = configuration causes bigger differences (on an SSD drive, and maybe a more = fragmented file?).</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3D= MsoNormal>Anyway, I added error handling for the malloc, and fixed/changed = the other things you suggested. Be happy to make any other changes you want= . The updated patch is here:<o:p></o:p></p><p class=3DMsoNormal>https://git= hub.com/kriszyp/node-lmdb/commit/25366dea9453749cf6637f43ec17b9b62094acde<o= :p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal= >><span class=3Dblob-code-inner><span style=3D'font-size:9.0pt;font-fami= ly:Consolas;color:#24292E'> OVERLAPPED* ov =3D </span></span><span class=3D= pl-c1><span style=3D'font-size:9.0pt;font-family:Consolas;color:#005CC5'>ma= lloc</span></span><span class=3Dblob-code-inner><span style=3D'font-size:9.= 0pt;font-family:Consolas;color:#24292E'>((pagecount - keep) * </span></span= ><span class=3Dpl-k><span style=3D'font-size:9.0pt;font-family:Consolas;col= or:#D73A49'>sizeof</span></span><span class=3Dblob-code-inner><span style= =3D'font-size:9.0pt;font-family:Consolas;color:#24292E'>(OVERLAPPED));<o:p>= </o:p></span></span></p><p class=3DMsoNormal><span class=3Dblob-code-inner>= <span style=3D'font-size:9.0pt;font-family:Consolas;color:#24292E'>> </s= pan></span><span style=3D'font-size:10.5pt;font-family:"Segoe UI",sans-seri= f;color:#24292E;background:white'>Probably this ought to just be pre-alloca= ted based on the maximum number of dirty pages a txn allows.<o:p></o:p></sp= an></p><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:"Se= goe UI",sans-serif;color:#24292E;background:white'><o:p> </o:p></span>= </p><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:"Segoe= UI",sans-serif;color:#24292E;background:white'>I wasn=E2=80=99t sure I und= erstood this comment. Are you suggesting we </span>malloc(MDB_IDL_UM_MAX * = sizeof(OVERLAPPED)) for each environment, and retain it for the life of the= environment? I think that is 4MB, if my math is right, which seems like a = lot of memory to keep allocated (we usually have a lot of open environments= ). If the goal is to reduce the number of mallocs, how about we retain the = OVERLAPPED array, and only free and re-malloc if the previous allocation wa= sn=E2=80=99t large enough? Then there isn=E2=80=99t unnecessary allocation,= and we only malloc when there is a bigger transaction than any previous. I= put this together in a separate commit, as I wasn=E2=80=99t sure if this w= hat you wanted (can squash if you prefer): https://github.com/kriszyp/node-= lmdb/commit/2fe68fb5269c843e2e789746a17a4b2adefaac40</p><p class=3DMsoNorma= l><o:p> </o:p></p><p class=3DMsoNormal>Thank you for the review! <span= style=3D'font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#24292E;= background:white'><o:p></o:p></span></p><p class=3DMsoNormal><o:p> </o= :p></p><p class=3DMsoNormal>Thanks,<br>Kris</p><p class=3DMsoNormal><o:p>&n= bsp;</o:p></p><div style=3D'mso-element:para-border-div;border:none;border-= top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal sty= le=3D'border:none;padding:0cm'><b>From: </b><a href=3D"mailto:hyc@symas.com= ">Howard Chu</a><br><b>Sent: </b>April 30, 2019 7:12 AM<br><b>To: </b><a hr= ef=3D"mailto:kriszyp@gmail.com">kriszyp(a)gmail.com</a>; <a href=3D"mailto:op= enldap-its(a)OpenLDAP.org">openldap-its(a)OpenLDAP.org</a><br><b>Subject: </b>R= e: (ITS#9017) Improving performance of commit sync in Windows</p></div><p c= lass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>kriszyp(a)gmail.co= m wrote:</p><p class=3DMsoNormal>> Full_Name: Kristopher William Zyp</p>= <p class=3DMsoNormal>> Version: LMDB 0.9.23</p><p class=3DMsoNormal>>= OS: Windows</p><p class=3DMsoNormal>> URL: https://github.com/kriszyp/n= ode-lmdb/commit/7ff525ae57684a163d32af74a0ab9332b7fc4ce9</p><p class=3DMsoN= ormal>> Submission from: (NULL) (71.199.6.148)</p><p class=3DMsoNormal>&= gt; </p><p class=3DMsoNormal>> </p><p class=3DMsoNormal>> We have see= n very poor performance on the sync of commits on large databases in</p><p = class=3DMsoNormal>> Windows. On databases with 2GB of data, in writemap = mode, the sync of even small</p><p class=3DMsoNormal>> commits is consis= tently well over 100ms (without writemap it is faster, but</p><p class=3DMs= oNormal>> still slow). It is expected that a sync should take some time = while waiting for</p><p class=3DMsoNormal>> disk confirmation of the wri= tes, but more concerning is that these sync</p><p class=3DMsoNormal>> op= erations (in writemap mode) are instead dominated by nearly 100% system CPU= </p><p class=3DMsoNormal>> utilization, so operations that requires sub-= millisecond b-tree update</p><p class=3DMsoNormal>> operations are then = dominated by very large amounts of system CPU cycles during</p><p class=3DM= soNormal>> the sync phase.</p><p class=3DMsoNormal>> </p><p class=3DM= soNormal>> I think that the fundamental problem is that FlushViewOfFile = seems to be an O(n)</p><p class=3DMsoNormal>> operation where n is the s= ize of the file (or map). I presume that Windows is</p><p class=3DMsoNormal= >> scanning the entire map/file for dirty pages to flush, I'm guessing b= ecause it</p><p class=3DMsoNormal>> doesn't have an internal index of al= l the dirty pages for every file/map-view in</p><p class=3DMsoNormal>> t= he OS disk cache. Therefore, the turns into an extremely expensive, CPU-bou= nd</p><p class=3DMsoNormal>> operation to find the dirty pages for (larg= e file) and initiate their writes,</p><p class=3DMsoNormal>> which, of c= ourse, is contrary to the whole goal of a scalable database system.</p><p c= lass=3DMsoNormal>> And FlushFileBuffers is also relatively slow as well.= We have attempted to batch</p><p class=3DMsoNormal>> as many operations= into single transaction as possible, but this is still a very</p><p class= =3DMsoNormal>> large overhead.</p><p class=3DMsoNormal>> </p><p class= =3DMsoNormal>> The Windows docs for FlushFileBuffers itself warns about = the inefficiencies of</p><p class=3DMsoNormal>> this function (https://d= ocs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-flushfilebuf= fers).</p><p class=3DMsoNormal>> Which also points to the solution: it i= s much faster to write out the dirty</p><p class=3DMsoNormal>> pages wit= h WriteFile through a sync file handle (FILE_FLAG_WRITE_THROUGH).</p><p cla= ss=3DMsoNormal>> </p><p class=3DMsoNormal>> The associated patch</p><= p class=3DMsoNormal>> (https://github.com/kriszyp/node-lmdb/commit/7ff52= 5ae57684a163d32af74a0ab9332b7fc4ce9)</p><p class=3DMsoNormal>> is my att= empt at implementing this solution, for Windows. Fortunately, with the</p><= p class=3DMsoNormal>> design of LMDB, this is relatively straightforward= . LMDB already supports</p><p class=3DMsoNormal>> writing out dirty page= s with WriteFile calls. I added a write-through handle for</p><p class=3DMs= oNormal>> sending these writes directly to disk. I then made that file-h= andle</p><p class=3DMsoNormal>> overlapped/asynchronously, so all the wr= ites for a commit could be started in</p><p class=3DMsoNormal>> overlap = mode, and (at least theoretically) transfer in parallel to the drive and</p= ><p class=3DMsoNormal>> then used GetOverlappedResult to wait for the co= mpletion. So basically</p><p class=3DMsoNormal>> mdb_page_flush becomes = the sync. I extended the writing of dirty pages through</p><p class=3DMsoNo= rmal>> WriteFile to writemap mode as well (for writing meta too), so tha= t WriteFile</p><p class=3DMsoNormal>> with write-through can be used to = flush the data without ever needing to call</p><p class=3DMsoNormal>> Fl= ushViewOfFile or FlushFileBuffers. I also implemented support for write</p>= <p class=3DMsoNormal>> gathering in writemap mode where contiguous file = positions infers contiguous</p><p class=3DMsoNormal>> memory (by trackin= g the starting position with wdp and writing contiguous pages</p><p class= =3DMsoNormal>> in single operations). Sorting of the dirty list is maint= ained even in writemap</p><p class=3DMsoNormal>> mode for this purpose.<= /p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>What is t= he point of using writemap mode if you still need to use WriteFile</p><p cl= ass=3DMsoNormal>on every individual page?</p><p class=3DMsoNormal><o:p>&nbs= p;</o:p></p><p class=3DMsoNormal>> The performance benefits of this patc= h, in my testing, are considerable. Writing</p><p class=3DMsoNormal>> ou= t/syncing transactions is typically over 5x faster in writemap mode, and 2x= </p><p class=3DMsoNormal>> faster in standard mode. And perhaps more imp= ortantly (especially in environment</p><p class=3DMsoNormal>> with many = threads/processes), the efficiency benefits are even larger,</p><p class=3D= MsoNormal>> particularly in writemap mode, where there can be a 50-100x = reduction in the</p><p class=3DMsoNormal>> system CPU usage by using thi= s patch. This brings windows performance with</p><p class=3DMsoNormal>> = sync'ed transactions in LMDB back into the range of "lightning" p= erformance :).</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoN= ormal>What is the performance difference between your patch using writemap,= and just</p><p class=3DMsoNormal>not using writemap in the first place?</p= ><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>-- </p><p c= lass=3DMsoNormal>=C2=A0=C2=A0-- Howard Chu</p><p class=3DMsoNormal>=C2=A0 C= TO, Symas Corp.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= http://www.symas.com</p><p class=3DMsoNormal>=C2=A0 Director, Highland Sun= =C2=A0=C2=A0=C2=A0=C2=A0 http://highlandsun.com/hyc/</p><p class=3DMsoNorma= l>=C2=A0 Chief Architect, OpenLDAP=C2=A0 http://www.openldap.org/project/</= p><p class=3DMsoNormal><o:p> </o:p></p></div></body></html>= --_F6B70E9A-5F12-495E-A3D8-F48F4F20717D_--

1 0

Re: (ITS#9017) Improving performance of commit sync in Windows
by hyc＠symas.com 30 Apr '19

30 Apr '19

kriszyp(a)gmail.com wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.23 > OS: Windows > URL: https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab933… > Submission from: (NULL) (71.199.6.148) > > > We have seen very poor performance on the sync of commits on large databases in > Windows. On databases with 2GB of data, in writemap mode, the sync of even small > commits is consistently well over 100ms (without writemap it is faster, but > still slow). It is expected that a sync should take some time while waiting for > disk confirmation of the writes, but more concerning is that these sync > operations (in writemap mode) are instead dominated by nearly 100% system CPU > utilization, so operations that requires sub-millisecond b-tree update > operations are then dominated by very large amounts of system CPU cycles during > the sync phase. > > I think that the fundamental problem is that FlushViewOfFile seems to be an O(n) > operation where n is the size of the file (or map). I presume that Windows is > scanning the entire map/file for dirty pages to flush, I'm guessing because it > doesn't have an internal index of all the dirty pages for every file/map-view in > the OS disk cache. Therefore, the turns into an extremely expensive, CPU-bound > operation to find the dirty pages for (large file) and initiate their writes, > which, of course, is contrary to the whole goal of a scalable database system. > And FlushFileBuffers is also relatively slow as well. We have attempted to batch > as many operations into single transaction as possible, but this is still a very > large overhead. > > The Windows docs for FlushFileBuffers itself warns about the inefficiencies of > this function (https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-flu…). > Which also points to the solution: it is much faster to write out the dirty > pages with WriteFile through a sync file handle (FILE_FLAG_WRITE_THROUGH). > > The associated patch > (https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab933…) > is my attempt at implementing this solution, for Windows. Fortunately, with the > design of LMDB, this is relatively straightforward. LMDB already supports > writing out dirty pages with WriteFile calls. I added a write-through handle for > sending these writes directly to disk. I then made that file-handle > overlapped/asynchronously, so all the writes for a commit could be started in > overlap mode, and (at least theoretically) transfer in parallel to the drive and > then used GetOverlappedResult to wait for the completion. So basically > mdb_page_flush becomes the sync. I extended the writing of dirty pages through > WriteFile to writemap mode as well (for writing meta too), so that WriteFile > with write-through can be used to flush the data without ever needing to call > FlushViewOfFile or FlushFileBuffers. I also implemented support for write > gathering in writemap mode where contiguous file positions infers contiguous > memory (by tracking the starting position with wdp and writing contiguous pages > in single operations). Sorting of the dirty list is maintained even in writemap > mode for this purpose. What is the point of using writemap mode if you still need to use WriteFile on every individual page? > The performance benefits of this patch, in my testing, are considerable. Writing > out/syncing transactions is typically over 5x faster in writemap mode, and 2x > faster in standard mode. And perhaps more importantly (especially in environment > with many threads/processes), the efficiency benefits are even larger, > particularly in writemap mode, where there can be a 50-100x reduction in the > system CPU usage by using this patch. This brings windows performance with > sync'ed transactions in LMDB back into the range of "lightning" performance :). What is the performance difference between your patch using writemap, and just not using writemap in the first place? -- -- 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#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 30 Apr '19

30 Apr '19

Full_Name: Kristopher William Zyp Version: LMDB 0.9.23 OS: Windows URL: https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab933… Submission from: (NULL) (71.199.6.148) We have seen very poor performance on the sync of commits on large databases in Windows. On databases with 2GB of data, in writemap mode, the sync of even small commits is consistently well over 100ms (without writemap it is faster, but still slow). It is expected that a sync should take some time while waiting for disk confirmation of the writes, but more concerning is that these sync operations (in writemap mode) are instead dominated by nearly 100% system CPU utilization, so operations that requires sub-millisecond b-tree update operations are then dominated by very large amounts of system CPU cycles during the sync phase. I think that the fundamental problem is that FlushViewOfFile seems to be an O(n) operation where n is the size of the file (or map). I presume that Windows is scanning the entire map/file for dirty pages to flush, I'm guessing because it doesn't have an internal index of all the dirty pages for every file/map-view in the OS disk cache. Therefore, the turns into an extremely expensive, CPU-bound operation to find the dirty pages for (large file) and initiate their writes, which, of course, is contrary to the whole goal of a scalable database system. And FlushFileBuffers is also relatively slow as well. We have attempted to batch as many operations into single transaction as possible, but this is still a very large overhead. The Windows docs for FlushFileBuffers itself warns about the inefficiencies of this function (https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-flu…). Which also points to the solution: it is much faster to write out the dirty pages with WriteFile through a sync file handle (FILE_FLAG_WRITE_THROUGH). The associated patch (https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab933…) is my attempt at implementing this solution, for Windows. Fortunately, with the design of LMDB, this is relatively straightforward. LMDB already supports writing out dirty pages with WriteFile calls. I added a write-through handle for sending these writes directly to disk. I then made that file-handle overlapped/asynchronously, so all the writes for a commit could be started in overlap mode, and (at least theoretically) transfer in parallel to the drive and then used GetOverlappedResult to wait for the completion. So basically mdb_page_flush becomes the sync. I extended the writing of dirty pages through WriteFile to writemap mode as well (for writing meta too), so that WriteFile with write-through can be used to flush the data without ever needing to call FlushViewOfFile or FlushFileBuffers. I also implemented support for write gathering in writemap mode where contiguous file positions infers contiguous memory (by tracking the starting position with wdp and writing contiguous pages in single operations). Sorting of the dirty list is maintained even in writemap mode for this purpose. The performance benefits of this patch, in my testing, are considerable. Writing out/syncing transactions is typically over 5x faster in writemap mode, and 2x faster in standard mode. And perhaps more importantly (especially in environment with many threads/processes), the efficiency benefits are even larger, particularly in writemap mode, where there can be a 50-100x reduction in the system CPU usage by using this patch. This brings windows performance with sync'ed transactions in LMDB back into the range of "lightning" performance :). All of these changes in the associated patch should only affect Windows. I actually had started with the approach of using a flag to indicate write-through behavior (here https://github.com/kriszyp/node-lmdb/commit/435ca423d0e13936f2a5f0193e994f5… if anyone wants to test it or play with it further). However, I didn't really see any substantive improvements in unix. It is possible that maybe with the use of dsync writes that are done asynchronously in parallel and wait for the completion (aio_write/aio_suspend), there might be a performance benefit opportunity, but I was less interested in this, and I assume you probably have already thoroughly explored these options already. In the end, I think it makes more sense to just make this the default behavior for Windows where the major improvement is, and don't change the unix behavior. Also, I don't think you can write to files that have an open writeable mapped region, so the implementation would be limited on unix anyway. Anyway, this is certainly a more involved patch, in a sophisticated code-base, so I humbly present this for consideration. I have tested both the performance and the sync safety of this code. Our application has a high enough intensity of db interaction that it is actually pretty easy to reproduce LMDB data corruption by powering off a VM with the app running, if sync-mode is not enabled. And with my testing so far, sync-mode with this patch seems to preserve the rock-solid crash-proof design of LMDB. But I'd be glad to make any changes or cleanup needed, or if you want the patch to be submitted differently (it seems like using patches from my node repo fork has worked in the past though).

1 0

Re: (ITS#7632) ldap_start_tls_s core dumps for 64 bit
by quanah＠symas.com 30 Apr '19

30 Apr '19

--On Wednesday, June 26, 2013 6:20 AM +0000 a16474(a)gmail.com wrote: > Full_Name: Amit Sinha > Version: openldap-2.4.35 > OS: Linux 2.6.18-308.11.1.el5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.163.217.105) > > > When i compile and run the below code on linux 64 bit, it core dumps in > ldap_start_tls_s(). Hello, Thank you for the report! I apologize for the (very very long) delay in response. This issue no longer seems to occur with current OpenLDAP/OpenSSL releases (nor does it happen with OpenLDAP/GnuTLS). I believe one of the many fixes to OpenLDAP's TLS code has since resolved this issue. I tested with both OpenSSL 1.0.2k and 1.1.1b. This ITS will be closed. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by ondra＠mistotebe.net 26 Apr '19

26 Apr '19

On Wed, Apr 24, 2019 at 01:30:18PM +0000, ondra(a)mistotebe.net wrote: > On Tue, Apr 23, 2019 at 11:28:40PM +0000, quanah(a)symas.com wrote: >> The consumer did not replicate the database as a part of the initial >> search, so I don't think it qualifies as "up to date". I.e., it's primary >> DB remains empty. > > Ah, that wasn't mentioned, my assumption was that the source DB was > actually empty. > > This is coming from ITS#8281 fix in cd8ff37629012c1676ef79de164a159da9b2ae89. I've pushed a change that makes sure we end up with a contexCSN, generating one if necessary whenever we're configured to be a master (olcMirrorMode is set or no olcSyncrepl exists) here: https://github.com/mistotebe/openldap/tree/its9015 It's kind of a followup on this (reverting part of ITS#8281 above): https://www.openldap.org/lists/openldap-devel/201904/msg00015.html -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by siddjain＠live.com 24 Apr '19

24 Apr '19

--_000_MWHPR08MB2400D7AE5E8EEC3D17192FACB53C0MWHPR08MB2400namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you. we tried using another openldap image and that worked. so it see= ms the problem is with the osixia docker image we were using to run openlda= p. it is based on debian (which uses GnuTLS per your email) so tbh we are s= urprised it would have such a bug in it. the image that worked for us is ba= sed on alpine. https://github.com/osixia/docker-light-baseimage/blob/stable/image/Dockerfi= le https://github.com/tiredofit/docker-openldap/blob/master/Dockerfile but back to your comment, how can one isolate what TLS/SSL library OpenLDAP= is linked to in the environment you're using? [https://avatars0.githubusercontent.com/u/23528985?s=3D400&v=3D4]<https://g= ithub.com/tiredofit/docker-openldap/blob/master/Dockerfile> docker-openldap/Dockerfile at master =B7 tiredofit/docker-openldap =B7 GitH= ub<https://github.com/tiredofit/docker-openldap/blob/master/Dockerfile> Docker OpenLDAP Container w/TLS & Replication Support S6 Overlay, and Zabbi= x Monitoring based on Alpine - tiredofit/docker-openldap github.com [https://avatars0.githubusercontent.com/u/23528985?s=3D400&v=3D4]<https://g= ithub.com/tiredofit/docker-openldap/blob/master/Dockerfile> docker-openldap/Dockerfile at master =B7 tiredofit/docker-openldap =B7 GitH= ub<https://github.com/tiredofit/docker-openldap/blob/master/Dockerfile> Docker OpenLDAP Container w/TLS & Replication Support S6 Overlay, and Zabbi= x Monitoring based on Alpine - tiredofit/docker-openldap github.com ________________________________ From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Wednesday, April 24, 2019 1:06 PM To: siddjain(a)live.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate bef= ore sending it to client --On Wednesday, April 24, 2019 6:43 PM +0000 hyc(a)symas.com wrote: > siddjain(a)live.com wrote: >> --_000_MWHPR08MB24000D77048AFCF7465C4397B53C0MWHPR08MB2400namp_ >> Content-Type: text/plain; charset=3D"iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> could you send me output of running >> >> openssl version -a >> >> on your system? thanks > >> openssl version -a > OpenSSL 1.1.1 11 Sep 2018 > built on: Tue Dec 4 13:15:09 2018 UTC > platform: debian-amd64 I would also note that not all OpenLDAP builds use OpenSSL. For example, OpenLDAP built on Debian/Ubuntu uses GnuTLS. OpenLDAP built on some versions of RedHat 7 use MozNSS. Current RedHat 7 builds use OpenSSL but have an odd MozNSS bridge for backwards compatibilty, and there may be all sorts of odd bugs in that. Apple links OpenLDAP to its own custom SSL libary. So really your first step should be isolating what TLS/SSL library OpenLDAP is linked to in the environment you're using. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.sym= as.com&data=3D02%7C01%7C%7C349b90be6afe4991a54b08d6c8f068b4%7C84df9e7fe= 9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917332202918260&sdata=3DNifWEVt269= tCTuar98XYUfNkaHWSFMffI3M4%2FJ7j8zI%3D&reserved=3D0> --_000_MWHPR08MB2400D7AE5E8EEC3D17192FACB53C0MWHPR08MB2400namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> Thank you. we tried using another openldap image and that worked. so it see= ms the problem is with the osixia docker image we were using to run openlda= p. it is based on debian (which <span style=3D"color: rgb(51, 51, 51);= font-family: "Segoe UI", "Segoe UI Web (West European)&quot= ;, "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica = Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 25= 5, 255); display: inline !important">uses GnuTLS per your email</span>) so tbh we are surprised it would have such a= bug in it. the image that worked for us is based on alpine. </div> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> <a href=3D"https://github.com/osixia/docker-light-baseimage/blob/stable/ima= ge/Dockerfile">https://github.com/osixia/docker-light-baseimage/blob/stable= /image/Dockerfile</a><br> </div> <div> <div id=3D"appendonsend"></div> <div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col= or:rgb(0,0,0)"> <a href=3D"https://github.com/tiredofit/docker-openldap/blob/master/Dockerf= ile" id=3D"LPlnk147820">https://github.com/tiredofit/docker-openldap/blob/m= aster/Dockerfile</a></div> <div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col= or:rgb(0,0,0)"> but back to your comment, how can one <span style=3D"color: rgb(51, 51= , 51); font-family: "Segoe UI", "Segoe UI Web (West European= )", "Segoe UI", -apple-system, system-ui, Roboto, "Helv= etica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(2= 55, 255, 255); display: inline !important">isolate what TLS/SSL library OpenLDAP<span> </span></span><span style=3D"colo= r: rgb(51, 51, 51); font-family: "Segoe UI", "Segoe UI Web (= West European)", "Segoe UI", -apple-system, system-ui, Robot= o, "Helvetica Neue", sans-serif; font-size: 14.6667px; background= -color: rgb(255, 255, 255); display: inline !important">is linked to in the environment you're using? </span><br style=3D"color:= rgb(51, 51, 51); font-family: "Segoe UI", "Segoe UI Web (We= st European)", "Segoe UI", -apple-system, system-ui, Roboto,= "Helvetica Neue", sans-serif; font-size: 14.6667px; background-c= olor: rgb(255, 255, 255)"> <br> <div id=3D"LPBorder_GTaHR0cHM6Ly9naXRodWIuY29tL3RpcmVkb2ZpdC9kb2NrZXItb3Blb= mxkYXAvYmxvYi9tYXN0ZXIvRG9ja2VyZmlsZQ.." class=3D"LPBorder213343" contented= itable=3D"false" style=3D"width: 100%; margin-top: 16px; margin-bottom: 16p= x; position: relative; max-width: 800px; min-width: 424px;"> <table id=3D"LPContainer213343" role=3D"presentation" style=3D"padding: 12p= x 36px 12px 12px; width: 100%; border-width: 1px; border-style: solid; bord= er-color: rgb(200, 200, 200); border-radius: 2px;"> <tbody> <tr valign=3D"top" style=3D"border-spacing: 0px;"> <td> <div id=3D"LPImageContainer213343" style=3D"position: relative; margin-righ= t: 12px; height: 160px; overflow: hidden;"> <a target=3D"_blank" id=3D"LPImageAnchor213343" href=3D"https://github.com/= tiredofit/docker-openldap/blob/master/Dockerfile"><img id=3D"LPThumbnailIma= geId213343" alt=3D"" height=3D"160" style=3D"display: block;" width=3D"160"= src=3D"https://avatars0.githubusercontent.com/u/23528985?s=3D400&v=3D4= "></a></div> </td> <td style=3D"width: 100%;"> <div id=3D"LPTitle213343" style=3D"font-size: 21px; font-weight: 300; margi= n-right: 8px; font-family: wf_segoe-ui_light, "Segoe UI Light", &= quot;Segoe WP Light", "Segoe UI", "Segoe WP", Taho= ma, Arial, sans-serif; margin-bottom: 12px;"> <a target=3D"_blank" id=3D"LPUrlAnchor213343" href=3D"https://github.com/ti= redofit/docker-openldap/blob/master/Dockerfile" style=3D"text-decoration: n= one; color: var(--themePrimary);">docker-openldap/Dockerfile at master =B7 = tiredofit/docker-openldap =B7 GitHub</a></div> <div id=3D"LPDescription213343" style=3D"font-size: 14px; max-height: 100px= ; color: rgb(102, 102, 102); font-family: wf_segoe-ui_normal, "Segoe U= I", "Segoe WP", Tahoma, Arial, sans-serif; margin-bottom: 12= px; margin-right: 8px; overflow: hidden;"> Docker OpenLDAP Container w/TLS & Replication Support S6 Overlay, and Z= abbix Monitoring based on Alpine - tiredofit/docker-openldap</div> <div id=3D"LPMetadata213343" style=3D"font-size: 14px; font-weight: 400; co= lor: rgb(166, 166, 166); font-family: wf_segoe-ui_normal, "Segoe UI&qu= ot;, "Segoe WP", Tahoma, Arial, sans-serif;"> github.com</div> </td> </tr> </tbody> </table> </div> <br> <div id=3D"LPBorder_GTaHR0cHM6Ly9naXRodWIuY29tL3RpcmVkb2ZpdC9kb2NrZXItb3Blb= mxkYXAvYmxvYi9tYXN0ZXIvRG9ja2VyZmlsZQ.." class=3D"LPBorder356508" contented= itable=3D"false" style=3D"width: 100%; margin-top: 16px; margin-bottom: 16p= x; position: relative; max-width: 800px; min-width: 424px;"> <table id=3D"LPContainer356508" role=3D"presentation" style=3D"padding: 12p= x 36px 12px 12px; width: 100%; border-width: 1px; border-style: solid; bord= er-color: rgb(200, 200, 200); border-radius: 2px;"> <tbody> <tr valign=3D"top" style=3D"border-spacing: 0px;"> <td> <div id=3D"LPImageContainer356508" style=3D"position: relative; margin-righ= t: 12px; height: 160px; overflow: hidden;"> <a target=3D"_blank" id=3D"LPImageAnchor356508" href=3D"https://github.com/= tiredofit/docker-openldap/blob/master/Dockerfile"><img id=3D"LPThumbnailIma= geId356508" alt=3D"" height=3D"160" style=3D"display: block;" width=3D"160"= src=3D"https://avatars0.githubusercontent.com/u/23528985?s=3D400&v=3D4= "></a></div> </td> <td style=3D"width: 100%;"> <div id=3D"LPTitle356508" style=3D"font-size: 21px; font-weight: 300; margi= n-right: 8px; font-family: wf_segoe-ui_light, "Segoe UI Light", &= quot;Segoe WP Light", "Segoe UI", "Segoe WP", Taho= ma, Arial, sans-serif; margin-bottom: 12px;"> <a target=3D"_blank" id=3D"LPUrlAnchor356508" href=3D"https://github.com/ti= redofit/docker-openldap/blob/master/Dockerfile" style=3D"text-decoration: n= one; color: var(--themePrimary);">docker-openldap/Dockerfile at master =B7 = tiredofit/docker-openldap =B7 GitHub</a></div> <div id=3D"LPDescription356508" style=3D"font-size: 14px; max-height: 100px= ; color: rgb(102, 102, 102); font-family: wf_segoe-ui_normal, "Segoe U= I", "Segoe WP", Tahoma, Arial, sans-serif; margin-bottom: 12= px; margin-right: 8px; overflow: hidden;"> Docker OpenLDAP Container w/TLS & Replication Support S6 Overlay, and Z= abbix Monitoring based on Alpine - tiredofit/docker-openldap</div> <div id=3D"LPMetadata356508" style=3D"font-size: 14px; font-weight: 400; co= lor: rgb(166, 166, 166); font-family: wf_segoe-ui_normal, "Segoe UI&qu= ot;, "Segoe WP", Tahoma, Arial, sans-serif;"> github.com</div> </td> </tr> </tbody> </table> </div> <br> </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co= lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Quanah Gibson-Mount &= lt;quanah(a)symas.com><br> <b>Sent:</b> Wednesday, April 24, 2019 1:06 PM<br> <b>To:</b> siddjain(a)live.com; openldap-its(a)OpenLDAP.org<br> <b>Subject:</b> Re: (ITS#9014) OpenLDAP modifies user provided TLS certific= ate before sending it to client</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"= > <div class=3D"PlainText">--On Wednesday, April 24, 2019 6:43 PM +0000 h= yc(a)symas.com wrote:<br> <br> > siddjain(a)live.com wrote:<br> >> --_000_MWHPR08MB24000D77048AFCF7465C4397B53C0MWHPR08MB2400namp_<br= > >> Content-Type: text/plain; charset=3D"iso-8859-1"<br> >> Content-Transfer-Encoding: quoted-printable<br> >><br> >> could you send me output of running<br> >><br> >> openssl version -a<br> >><br> >> on your system? thanks<br> ><br> >> openssl version -a<br> > OpenSSL 1.1.1  11 Sep 2018<br> > built on: Tue Dec  4 13:15:09 2018 UTC<br> > platform: debian-amd64<br> <br> I would also note that not all OpenLDAP builds use OpenSSL.  For examp= le, <br> OpenLDAP built on Debian/Ubuntu uses GnuTLS.  OpenLDAP built on some <= br> versions of RedHat 7 use MozNSS.  Current RedHat 7 builds use OpenSSL = but <br> have an odd MozNSS bridge for backwards compatibilty, and there may be all = <br> sorts of odd bugs in that.  Apple links OpenLDAP to its own custom SSL= <br> libary.<br> <br> So really your first step should be isolating what TLS/SSL library OpenLDAP= <br> is linked to in the environment you're using.<br> <br> --Quanah<br> <br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3= A%2F%2Fwww.symas.com&amp;data=3D02%7C01%7C%7C349b90be6afe4991a54b08d6c8= f068b4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917332202918260&= amp;sdata=3DNifWEVt269tCTuar98XYUfNkaHWSFMffI3M4%2FJ7j8zI%3D&amp;reserv= ed=3D0">https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2F= www.symas.com&amp;data=3D02%7C01%7C%7C349b90be6afe4991a54b08d6c8f068b4%= 7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917332202918260&amp;sda= ta=3DNifWEVt269tCTuar98XYUfNkaHWSFMffI3M4%2FJ7j8zI%3D&amp;reserved=3D0<= /a>><br> <br> </div> </span></font></div> </div> </body> </html> --_000_MWHPR08MB2400D7AE5E8EEC3D17192FACB53C0MWHPR08MB2400namp_--

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by quanah＠symas.com 24 Apr '19

24 Apr '19

--On Wednesday, April 24, 2019 6:43 PM +0000 hyc(a)symas.com wrote: > siddjain(a)live.com wrote: >> --_000_MWHPR08MB24000D77048AFCF7465C4397B53C0MWHPR08MB2400namp_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> could you send me output of running >> >> openssl version -a >> >> on your system? thanks > >> openssl version -a > OpenSSL 1.1.1 11 Sep 2018 > built on: Tue Dec 4 13:15:09 2018 UTC > platform: debian-amd64 I would also note that not all OpenLDAP builds use OpenSSL. For example, OpenLDAP built on Debian/Ubuntu uses GnuTLS. OpenLDAP built on some versions of RedHat 7 use MozNSS. Current RedHat 7 builds use OpenSSL but have an odd MozNSS bridge for backwards compatibilty, and there may be all sorts of odd bugs in that. Apple links OpenLDAP to its own custom SSL libary. So really your first step should be isolating what TLS/SSL library OpenLDAP is linked to in the environment you're using. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by hyc＠symas.com 24 Apr '19

24 Apr '19

siddjain(a)live.com wrote: > --_000_MWHPR08MB24000D77048AFCF7465C4397B53C0MWHPR08MB2400namp_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > could you send me output of running > > openssl version -a > > on your system? thanks > openssl version -a OpenSSL 1.1.1 11 Sep 2018 built on: Tue Dec 4 13:15:09 2018 UTC platform: debian-amd64 options: bn(64,64) rc4(8x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-DovhWu/openssl-1.1.1=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific > > ________________________________ > From: Howard Chu <hyc(a)symas.com> > Sent: Wednesday, April 24, 2019 10:04 AM > To: Siddharth Jain; openldap-its(a)OpenLDAP.org > Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate bef= > ore sending it to client > > Siddharth Jain wrote: >> Wow! Thanks for responding so fast. This could be a bug in docker-openlda= > p then. we have repro'ed this in two different environments - mac and ubunt= > u. Do you >> have a recommendation for docker image for openldap? > > As I said before, OpenLDAP doesn't touch the certificate files, it merely t= > ells the TLS > library where they are. You must likely have a broken TLS library. -- -- 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

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by siddjain＠live.com 24 Apr '19

24 Apr '19

--_000_MWHPR08MB24000D77048AFCF7465C4397B53C0MWHPR08MB2400namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable could you send me output of running openssl version -a on your system? thanks ________________________________ From: Howard Chu <hyc(a)symas.com> Sent: Wednesday, April 24, 2019 10:04 AM To: Siddharth Jain; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate bef= ore sending it to client Siddharth Jain wrote: > Wow! Thanks for responding so fast. This could be a bug in docker-openlda= p then. we have repro'ed this in two different environments - mac and ubunt= u. Do you > have a recommendation for docker image for openldap? As I said before, OpenLDAP doesn't touch the certificate files, it merely t= ells the TLS library where they are. You must likely have a broken TLS library. -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------ > *From:* Howard Chu <hyc(a)symas.com> > *Sent:* Wednesday, April 24, 2019 9:42 AM > *To:* Siddharth Jain; openldap-its(a)OpenLDAP.org > *Subject:* Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate= before sending it to client > > Siddharth Jain wrote: >> we have documented complete steps to repro the bug here <https://nam01.s= afelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fsiddjain%= 2Fopenldap-bug&data=3D02%7C01%7C%7Cdeffc420629649af454408d6c8d6f129%7C8= 4df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917222820865922&sdata=3Dsx= jXXBtCMOjbK5AZCpLTObP%2BIlJRAxXUK7LpLzUDD%2FM%3D&reserved=3D0> with > container logs. > > I see no error here. > > Using your cert/key files: > There is no OpenLDAP bug here. Your server environment is broken. -- -- Howard Chu CTO, Symas Corp. https://nam01.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.symas.com&data=3D02%7C01%7C%7Cdeffc420629649af= 454408d6c8d6f129%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6369172228208= 65922&sdata=3DX5JT6j5%2BQ2BAsKGfNslnC%2FkQj%2BcSU4GAdTqmqqc3lWo%3D&= reserved=3D0 Director, Highland Sun https://nam01.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fhighlandsun.com%2Fhyc%2F&data=3D02%7C01%7C%7Cdeffc= 420629649af454408d6c8d6f129%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63= 6917222820865922&sdata=3DSHju26Gxu5dToV%2BuCYDxBMZQS5qJZvREcg9q0CEg2bo%= 3D&reserved=3D0 Chief Architect, OpenLDAP https://nam01.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&data=3D02%7C01%7C%7C= deffc420629649af454408d6c8d6f129%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0= %7C636917222820865922&sdata=3DfJ7LIrWHv%2FG4CJGrx%2BClsFoldJfri%2Bdk7WN= 59Bt45jU%3D&reserved=3D0 --_000_MWHPR08MB24000D77048AFCF7465C4397B53C0MWHPR08MB2400namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> could you send me output of running  <p style=3D"margin: 0px; font: 11px Menlo; background-color: rgb(255, 255, = 255); margin: 0px; background-color: rgb(255, 255, 255)"> <span style=3D"font-variant-ligatures: no-common-ligatures; font-variant-li= gatures: no-common-ligatures">openssl version -a</span></p> <p style=3D"margin: 0px; font: 11px Menlo; background-color: rgb(255, 255, = 255); margin: 0px; background-color: rgb(255, 255, 255)"> <span style=3D"font-variant-ligatures: no-common-ligatures; font-variant-li= gatures: no-common-ligatures">on your system? thanks</span></p> </div> <div> <div id=3D"appendonsend"></div> <div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col= or:rgb(0,0,0)"> <br> </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co= lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Howard Chu <hyc@sy= mas.com><br> <b>Sent:</b> Wednesday, April 24, 2019 10:04 AM<br> <b>To:</b> Siddharth Jain; openldap-its(a)OpenLDAP.org<br> <b>Subject:</b> Re: (ITS#9014) OpenLDAP modifies user provided TLS certific= ate before sending it to client</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"= > <div class=3D"PlainText">Siddharth Jain wrote:<br> > Wow! Thanks for responding so fast. This could be a bug in docker-open= ldap then. we have repro'ed this in two different environments - mac and ub= untu. Do you<br> > have a recommendation for docker image for openldap?<br> <br> As I said before, OpenLDAP doesn't touch the certificate files, it merely t= ells the TLS<br> library where they are. You must likely have a broken TLS library.<br>   --------------------------------------------------------------------= ---------------------------------------------------------------------------= -----------------<br> > *From:* Howard Chu <hyc(a)symas.com><br> > *Sent:* Wednesday, April 24, 2019 9:42 AM<br> > *To:* Siddharth Jain; openldap-its(a)OpenLDAP.org<br> > *Subject:* Re: (ITS#9014) OpenLDAP modifies user provided TLS certific= ate before sending it to client<br> >  <br> > Siddharth Jain wrote:<br> >> we have documented complete steps to repro the bug here <<= a href=3D"https://nam01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fgithub.com%2Fsiddjain%2Fopenldap-bug&amp;data=3D02%7C01%7C%7Cdeffc42= 0629649af454408d6c8d6f129%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6369= 17222820865922&amp;sdata=3DsxjXXBtCMOjbK5AZCpLTObP%2BIlJRAxXUK7LpLzUDD%= 2FM%3D&amp;reserved=3D0">https://nam01.safelinks.protection.outlook.com= /?url=3Dhttps%3A%2F%2Fgithub.com%2Fsiddjain%2Fopenldap-bug&amp;data=3D0= 2%7C01%7C%7Cdeffc420629649af454408d6c8d6f129%7C84df9e7fe9f640afb435aaaaaaaa= aaaa%7C1%7C0%7C636917222820865922&amp;sdata=3DsxjXXBtCMOjbK5AZCpLTObP%2= BIlJRAxXUK7LpLzUDD%2FM%3D&amp;reserved=3D0</a>> with<br> > container logs.<br> > <br> > I see no error here.<br> > <br> > Using your cert/key files:<br> <br> > There is no OpenLDAP bug here. Your server environment is broken.<br> <br> <br> -- <br>   -- Howard Chu<br>   CTO, Symas Corp.        &nbs= p;  <a href=3D"https://nam01.safelinks.protection.outlook.com/?url=3Dh= ttp%3A%2F%2Fwww.symas.com&amp;data=3D02%7C01%7C%7Cdeffc420629649af45440= 8d6c8d6f129%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917222820865922= &amp;sdata=3DX5JT6j5%2BQ2BAsKGfNslnC%2FkQj%2BcSU4GAdTqmqqc3lWo%3D&a= mp;reserved=3D0"> https://nam01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.syma= s.com&amp;data=3D02%7C01%7C%7Cdeffc420629649af454408d6c8d6f129%7C84df9e= 7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917222820865922&amp;sdata=3DX5J= T6j5%2BQ2BAsKGfNslnC%2FkQj%2BcSU4GAdTqmqqc3lWo%3D&amp;reserved=3D0</a><= br>   Director, Highland Sun     <a href=3D"https://na= m01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighlandsun.com%2F= hyc%2F&amp;data=3D02%7C01%7C%7Cdeffc420629649af454408d6c8d6f129%7C84df9= e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917222820865922&amp;sdata=3DSH= ju26Gxu5dToV%2BuCYDxBMZQS5qJZvREcg9q0CEg2bo%3D&amp;reserved=3D0"> https://nam01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighland= sun.com%2Fhyc%2F&amp;data=3D02%7C01%7C%7Cdeffc420629649af454408d6c8d6f1= 29%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917222820865922&amp;= sdata=3DSHju26Gxu5dToV%2BuCYDxBMZQS5qJZvREcg9q0CEg2bo%3D&amp;reserved= =3D0</a><br>   Chief Architect, OpenLDAP  <a href=3D"https://nam01.safelinks.p= rotection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&amp= ;amp;data=3D02%7C01%7C%7Cdeffc420629649af454408d6c8d6f129%7C84df9e7fe9f640a= fb435aaaaaaaaaaaa%7C1%7C0%7C636917222820865922&amp;sdata=3DfJ7LIrWHv%2F= G4CJGrx%2BClsFoldJfri%2Bdk7WN59Bt45jU%3D&amp;reserved=3D0"> https://nam01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.open= ldap.org%2Fproject%2F&amp;data=3D02%7C01%7C%7Cdeffc420629649af454408d6c= 8d6f129%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917222820865922&amp= ;amp;sdata=3DfJ7LIrWHv%2FG4CJGrx%2BClsFoldJfri%2Bdk7WN59Bt45jU%3D&amp;r= eserved=3D0</a><br> </div> </span></font></div> </div> </body> </html> --_000_MWHPR08MB24000D77048AFCF7465C4397B53C0MWHPR08MB2400namp_--

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by hyc＠symas.com 24 Apr '19

24 Apr '19

Siddharth Jain wrote: > Wow! Thanks for responding so fast. This could be a bug in docker-openl= dap then. we have repro'ed this in two different environments - mac and u= buntu. Do you > have a recommendation for docker image for openldap? As I said before, OpenLDAP doesn't touch the certificate files, it merely= tells the TLS library where they are. You must likely have a broken TLS library. -----------------------------------------------------------------------= -------------------------------------------------------------------------= ---------------- > *From:* Howard Chu <hyc(a)symas.com> > *Sent:* Wednesday, April 24, 2019 9:42 AM > *To:* Siddharth Jain; openldap-its(a)OpenLDAP.org > *Subject:* Re: (ITS#9014) OpenLDAP modifies user provided TLS certifica= te before sending it to client > =A0 > Siddharth Jain wrote: >> we have documented complete steps to repro the bug=A0here <https://eur= 04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fsid= djain%2Fopenldap-bug&data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3= cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&= sdata=3D8VfRtnCNPd%2BFo2Sps%2BLftBG3XcC57ReIFFphK6noyLc%3D&reserved=3D= 0>=A0with > container logs. >=20 > I see no error here. >=20 > Using your cert/key files: > There is no OpenLDAP bug here. Your server environment is broken. --=20 -- 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

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by siddjain＠live.com 24 Apr '19

24 Apr '19

--_000_MWHPR08MB2400F5334463D5A204E8CF88B53C0MWHPR08MB2400namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wow! Thanks for responding so fast. This could be a bug in docker-openldap = then. we have repro'ed this in two different environments - mac and ubuntu.= Do you have a recommendation for docker image for openldap? ________________________________ From: Howard Chu <hyc(a)symas.com> Sent: Wednesday, April 24, 2019 9:42 AM To: Siddharth Jain; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate bef= ore sending it to client Siddharth Jain wrote: > we have documented complete steps to repro the bug here <https://eur04.sa= felinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fsiddjain%2= Fopenldap-bug&data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84= df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&sdata=3D8Vf= RtnCNPd%2BFo2Sps%2BLftBG3XcC57ReIFFphK6noyLc%3D&reserved=3D0> with cont= ainer logs. I see no error here. Using your cert/key files: > ls -l /tmp/jnj total 12 -rw-r--r-- 1 hyc hyc 1592 Apr 24 17:34 jnj-ca-chain.pem -rw-r--r-- 1 hyc hyc 241 Apr 24 17:34 jnj-ldap-server-tls.key -rw-r--r-- 1 hyc hyc 1111 Apr 24 17:34 jnj-ldap-server-tls.pem ### With this slapd config vielle:~/OD/hobj/tests> cat testrun/slapd.1.conf include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/openldap.schema include ./schema/nis.schema include ./testdata/test.schema pidfile /home/hyc/OD/hobj/tests/testrun/slapd.1.pid argsfile /home/hyc/OD/hobj/tests/testrun/slapd.1.args sockbuf_max_incoming 4194303 TLSCAcertificatefile /tmp/jnj/jnj-ca-chain.pem TLSCertificateFile /tmp/jnj/jnj-ldap-server-tls.pem TLSCertificateKeyFile /tmp/jnj/jnj-ldap-server-tls.key database mdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DManager,dc=3Dexample,dc=3Dcom" rootpw secret directory /home/hyc/OD/hobj/tests/testrun/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub maxsize 33554432 database monitor ### And this slapd invocation from the OpenLDAP build tree vielle:~/OD/hobj/tests> ../servers/slapd/slapd -f testrun/slapd.1.conf -h l= daps://:9011 -s0 -d7 I get no verification error: > openssl s_client -connect localhost:9011 -state -nbio -CAfile jnj-ca-chai= n.pem -showcerts CONNECTED(00000005) Turned on non blocking io SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write R BLOCK SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:TLSv1.3 read encrypted extensions depth=3D2 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN = =3D rca-jnj verify return:1 depth=3D1 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU = =3D client + OU =3D jnj, CN =3D rca-jnj-admin verify return:1 depth=3D0 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU = =3D client + OU =3D jnj, CN =3D jnj-ldap-server verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL_connect:TLSv1.3 read server certificate verify SSL_connect:SSLv3/TLS read finished SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished read R BLOCK --- Certificate chain 0 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D c= lient + OU =3D jnj, CN =3D jnj-ldap-server i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D c= lient + OU =3D jnj, CN =3D rca-jnj-admin -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIUcxrGrCSwJwlQhBEuKztfLgRrtygwCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzANBgNVBAsTBmNsaWVudDAKBgNV BAsTA2puajEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MjIxNzE0MDBa Fw0yMDA0MjExNzE5MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMA0G A1UECxMGY2xpZW50MAoGA1UECxMDam5qMRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARutu4G452HY8vYKJLw9VXmIuz+ X1XNNwyI6q7KzzwNmTwzWyHIVzxjqNTsTRqY0L0lLI1cko2LsIACqnJTed7yo4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTPS+Zc8+ZDmpVS9XerpVD1gYL7 cjAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQDBbbexORUa nrBJG8iSkADdOIW/ZOK7kbpLJ4x6GdTO8gIgfzOqW/9ZJKFM3PBls6bEVacoRLX9 AklAHxajASZK+UU=3D -----END CERTIFICATE----- 1 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D c= lient + OU =3D jnj, CN =3D rca-jnj-admin i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D r= ca-jnj -----BEGIN CERTIFICATE----- MIICQTCCAeegAwIBAgIUBU9O3Wb3BDS8YuWRLYaKClbA9ZcwCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjMxOTAwWhcNMjQwMTMxMjMyNDAwWjB+MQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEbMA0GA1UECxMGY2xpZW50MAoGA1UECxMDam5qMRYwFAYDVQQDEw1y Y2Etam5qLWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEk4b8f5mWq+jf iMKQBVI8uU7btAF/LSSdXoOXYPW8JyJ23v5wtwRiQ/g4Al/6aIchvAC4QhJRUnz0 DMKuI7GCp6NmMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFNuvs8Q9fpkg3oA+i2OEuR3qE96oMB8GA1UdIwQYMBaAFBGV3Han Nf1T5i8fvDh239lt5W9DMAoGCCqGSM49BAMCA0gAMEUCIQD/4+AUOMBdofQEVsH2 2A6UGiJQvuplLEBA9in0cZTcCQIgcV5K+KCs3a5RNYUWdllakGx8c1f6ISrmk4an gjeXphQ=3D -----END CERTIFICATE----- 2 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D r= ca-jnj i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D r= ca-jnj -----BEGIN CERTIFICATE----- MIIB/TCCAaOgAwIBAgIUSsxdq02aJCyaIHkIRxRdKvWYG9swCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjExNDAwWhcNMzQwMTI4MjExNDAwWjBbMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEQMA4GA1UEAxMHcmNhLWpuajBZMBMGByqGSM49AgEGCCqGSM49AwEH A0IABCF30Cn+O5sD/9n6d3IQQEGiceCTD7gG/5t4dHR4xmvm84HNgRngGKGF4fny 6BXkPSyDguP+L5zozdWDb8dWTQejRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEBMB0GA1UdDgQWBBQRldx2pzX9U+YvH7w4dt/ZbeVvQzAKBggq hkjOPQQDAgNIADBFAiEAkCQcOP+PmyVIMgr/cUsk04qH8lXYO4DqDuH1WSNvGfEC IBZQGRehpZ604FgkD0YqmiGRV/OzU99em0g3jkmWJbJY -----END CERTIFICATE----- --- Server certificate subject=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU = =3D client + OU =3D jnj, CN =3D jnj-ldap-server issuer=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU = =3D client + OU =3D jnj, CN =3D rca-jnj-admin --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2254 bytes and written 391 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 4E6019F281D63D69D1C800DF4D2441CC918FF4A3AFA8A0A6D6D05FFB544= E91F2 Session-ID-ctx: Resumption PSK: A00E7F64B5EA00718122A6F34EF0EC9167F437BDB832D9C64834D18= F367E8AD2AD5F9BCF9649330D321DC19D0AB49882 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90 .~[.=3Do.Ix...= .xX. 0010 - 00 78 10 a6 94 fb 36 96-f9 8b 17 53 8b 27 14 b5 .x....6....S.'= .. 0020 - 5d 2d 28 3b db 26 71 44-65 c3 43 d6 8e e8 46 a8 ]-(;.&qDe.C...= F. 0030 - 05 8a 34 57 c0 42 71 03-4f 70 ad 20 07 74 fc 94 ..4W.Bq.Op. .t= .. 0040 - e8 e4 9d 89 d0 45 db 2c-62 4a 28 b6 31 f9 3f af .....E.,bJ(.1.= ?. 0050 - 46 7c f7 f8 9f b1 0b 7c-ea 70 a1 f0 4c 2f 62 0a F|.....|.p..L/= b. 0060 - e3 e9 83 47 0e f2 e5 71-a5 0c ba 2a 8d 7d f8 e2 ...G...q...*.}= .. 0070 - 21 84 1a 1a 86 4f 02 0a-4c 9a 17 77 af 9e 64 1f !....O..L..w..= d. 0080 - 72 c5 e5 45 d1 bb 92 0a-ae fe e9 b1 bc 46 7d 13 r..E.........F= }. 0090 - aa 2b 9b c1 3d 92 8b 1d-08 6c 11 12 a0 b7 c8 a3 .+..=3D....l..= .... 00a0 - b2 bb 2b d9 bd 70 86 0d-91 45 5c 23 b6 b0 6a 3a ..+..p...E\#..= j: 00b0 - 61 1d 3a c1 4a 36 48 b4-b3 03 a9 8b 41 94 fd 67 a.:.J6H.....A.= .g 00c0 - 53 a6 03 a4 ab c6 a0 7e-e9 39 98 a8 c9 01 bc c0 S......~.9....= .. Start Time: 1556123794 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: A7B81922756F8F5B986C7B38E0F29399F8127F52D042EB7D0DCEDB8D4CD= 577B5 Session-ID-ctx: Resumption PSK: 5FDD5DF642126A4F04D05EBBECDBB92BBCBAB6A7E05051224D64669= 3BBD0B964C039185F933442D400BBCBC92A832913 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90 .~[.=3Do.Ix...= .xX. 0010 - d3 10 28 b9 01 6b 4b 92-1e 3e ae 3b 7f 4e cc 6c ..(..kK..>.;.N= .l 0020 - 19 d3 0b ac 9c b9 21 4d-ed 78 2c 35 d3 03 ba 11 ......!M.x,5..= .. 0030 - 22 59 1c 0d 91 a5 da 93-a0 0a 54 88 aa 81 be 89 "Y........T...= .. 0040 - e0 2e 74 71 8e c8 fd f7-9d 5c 99 15 42 23 47 cf ..tq.....\..B#= G. 0050 - 0d 56 97 10 f3 f8 02 fe-69 65 e6 1c fa 7d 96 fe .V......ie...}= .. 0060 - 86 d2 c2 64 2c 6e 96 3d-14 e2 87 47 91 69 ef df ...d,n.=3D...G= .i.. 0070 - 14 d5 75 0d ff da 61 04-26 56 5d 8b d3 4d 2d 2d ..u...a.&V]..M= -- 0080 - 78 fa 65 6d ad ef 15 ba-14 45 f0 ba a6 85 fb 95 x.em.....E....= .. 0090 - dc e5 9b 1c ac e4 66 de-c2 6e 3f e7 1e 47 09 25 ......f..n?..G= .% 00a0 - 89 b0 c3 c0 4c 93 64 de-23 3e 58 67 ae f3 7e e4 ....L.d.#>Xg..= ~. 00b0 - d5 af 4d 31 40 24 87 da-ec e7 3f 8a 48 b5 9d 23 ..M1@$....?.H.= .# 00c0 - d4 53 01 fa 18 39 79 0f-9b 9c ea ed 71 63 c5 2f .S...9y.....qc= ./ Start Time: 1556123794 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL3 alert read:warning:close notify closed SSL3 alert write:warning:close notify vielle:/home/software/openldap-bug> ### There is no OpenLDAP bug here. Your server environment is broken. -- -- Howard Chu CTO, Symas Corp. https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.symas.com&data=3D02%7C01%7C%7Caca4f78e53324b52= 690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6369172093154= 07238&sdata=3DyzZvZLe34LJJfhMqjtBoGhJqMXnLSPdeBExlpYnMKqY%3D&reserv= ed=3D0 Director, Highland Sun https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fhighlandsun.com%2Fhyc%2F&data=3D02%7C01%7C%7Caca4f= 78e53324b52690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63= 6917209315407238&sdata=3Dc%2B1myt04g7sv1kXBUCwd1bUgQV4HGrjAgYgsPoAXLpA%= 3D&reserved=3D0 Chief Architect, OpenLDAP https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&data=3D02%7C01%7C%7C= aca4f78e53324b52690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0= %7C636917209315407238&sdata=3DbMFyP0JzruNwnxXozQQnUVYg2WrYvQJ1PFDWdgkd6= zc%3D&reserved=3D0 --_000_MWHPR08MB2400F5334463D5A204E8CF88B53C0MWHPR08MB2400namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> Wow! Thanks for responding so fast. This could be a bug in docker-openldap = then. we have repro'ed this in two different environments - mac and ubuntu.= Do you have a recommendation for docker image for openldap? </div> <div> <div id=3D"appendonsend"></div> <div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col= or:rgb(0,0,0)"> <br> </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co= lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Howard Chu <hyc@sy= mas.com><br> <b>Sent:</b> Wednesday, April 24, 2019 9:42 AM<br> <b>To:</b> Siddharth Jain; openldap-its(a)OpenLDAP.org<br> <b>Subject:</b> Re: (ITS#9014) OpenLDAP modifies user provided TLS certific= ate before sending it to client</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"= > <div class=3D"PlainText">Siddharth Jain wrote:<br> > we have documented complete steps to repro the bug here <<a hr= ef=3D"https://eur04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= ithub.com%2Fsiddjain%2Fopenldap-bug&amp;data=3D02%7C01%7C%7Caca4f78e533= 24b52690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63691720= 9315407238&amp;sdata=3D8VfRtnCNPd%2BFo2Sps%2BLftBG3XcC57ReIFFphK6noyLc%= 3D&amp;reserved=3D0">https://eur04.safelinks.protection.outlook.com/?ur= l=3Dhttps%3A%2F%2Fgithub.com%2Fsiddjain%2Fopenldap-bug&amp;data=3D02%7C= 01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa= %7C1%7C0%7C636917209315407238&amp;sdata=3D8VfRtnCNPd%2BFo2Sps%2BLftBG3X= cC57ReIFFphK6noyLc%3D&amp;reserved=3D0</a>> with container logs.<br> <br> I see no error here.<br> <br> Using your cert/key files:<br> <br> > ls -l /tmp/jnj<br> total 12<br> -rw-r--r-- 1 hyc hyc 1592 Apr 24 17:34 jnj-ca-chain.pem<br> -rw-r--r-- 1 hyc hyc  241 Apr 24 17:34 jnj-ldap-server-tls.key<br> -rw-r--r-- 1 hyc hyc 1111 Apr 24 17:34 jnj-ldap-server-tls.pem<br> <br> ###<br> <br> With this slapd config<br> vielle:~/OD/hobj/tests> cat testrun/slapd.1.conf<br> <br> include         ./schema/core.schem= a<br> include         ./schema/cosine.sch= ema<br> include         ./schema/inetorgper= son.schema<br> include         ./schema/openldap.s= chema<br> include         ./schema/nis.schema= <br> include         ./testdata/test.sch= ema<br> <br> pidfile         /home/hyc/OD/hobj/t= ests/testrun/slapd.1.pid<br> argsfile        /home/hyc/OD/hobj/tests/= testrun/slapd.1.args<br> <br> sockbuf_max_incoming 4194303<br> <br> TLSCAcertificatefile /tmp/jnj/jnj-ca-chain.pem<br> TLSCertificateFile /tmp/jnj/jnj-ldap-server-tls.pem<br> TLSCertificateKeyFile /tmp/jnj/jnj-ldap-server-tls.key<br> <br> <br> database        mdb<br> suffix          "dc=3Dexa= mple,dc=3Dcom"<br> rootdn          "cn=3DMan= ager,dc=3Dexample,dc=3Dcom"<br> rootpw          secret<br> directory       /home/hyc/OD/hobj/tests/testr= un/db.1.a<br> index           objectCla= ss     eq<br> index           cn,sn,uid=        pres,eq,sub<br> maxsize 33554432<br> <br> database        monitor<br> ###<br> <br> And this slapd invocation from the OpenLDAP build tree<br> vielle:~/OD/hobj/tests> ../servers/slapd/slapd -f testrun/slapd.1.conf -= h ldaps://:9011 -s0 -d7<br> <br> I get no verification error:<br> > openssl s_client -connect localhost:9011 -state -nbio -CAfile jnj-ca-c= hain.pem -showcerts<br> CONNECTED(00000005)<br> Turned on non blocking io<br> SSL_connect:before SSL initialization<br> SSL_connect:SSLv3/TLS write client hello<br> SSL_connect:error in SSLv3/TLS write client hello<br> write R BLOCK<br> SSL_connect:SSLv3/TLS write client hello<br> SSL_connect:SSLv3/TLS read server hello<br> SSL_connect:TLSv1.3 read encrypted extensions<br> depth=3D2 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= CN =3D rca-jnj<br> verify return:1<br> depth=3D1 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D rca-jnj-admin<br> verify return:1<br> depth=3D0 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D jnj-ldap-server<br> verify return:1<br> SSL_connect:SSLv3/TLS read server certificate<br> SSL_connect:TLSv1.3 read server certificate verify<br> SSL_connect:SSLv3/TLS read finished<br> SSL_connect:SSLv3/TLS write change cipher spec<br> SSL_connect:SSLv3/TLS write finished<br> read R BLOCK<br> ---<br> Certificate chain<br>  0 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D jnj-ldap-server<br>    i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Joh= nson, OU =3D client + OU =3D jnj, CN =3D rca-jnj-admin<br> -----BEGIN CERTIFICATE-----<br> MIIDBzCCAq2gAwIBAgIUcxrGrCSwJwlQhBEuKztfLgRrtygwCgYIKoZIzj0EAwIw<br> fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa<br> MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzANBgNVBAsTBmNsaWVudDAKBgNV<br> BAsTA2puajEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MjIxNzE0MDBa<br> Fw0yMDA0MjExNzE5MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP<br> BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMA0G<br> A1UECxMGY2xpZW50MAoGA1UECxMDam5qMRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2<br> ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARutu4G452HY8vYKJLw9VXmIuz+<br> X1XNNwyI6q7KzzwNmTwzWyHIVzxjqNTsTRqY0L0lLI1cko2LsIACqnJTed7yo4IB<br> BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF<br> BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTPS+Zc8+ZDmpVS9XerpVD1gYL7<br= > cjAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q<br> bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp<br> YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi<br> LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQDBbbexORUa<br> nrBJG8iSkADdOIW/ZOK7kbpLJ4x6GdTO8gIgfzOqW/9ZJKFM3PBls6bEVacoRLX9<br> AklAHxajASZK+UU=3D<br> -----END CERTIFICATE-----<br>  1 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D rca-jnj-admin<br>    i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Joh= nson, CN =3D rca-jnj<br> -----BEGIN CERTIFICATE-----<br> MIICQTCCAeegAwIBAgIUBU9O3Wb3BDS8YuWRLYaKClbA9ZcwCgYIKoZIzj0EAwIw<br> WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa<br> MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN<br> MTkwMjAxMjMxOTAwWhcNMjQwMTMxMjMyNDAwWjB+MQswCQYDVQQGEwJVUzELMAkG<br> A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg<br> Sm9obnNvbjEbMA0GA1UECxMGY2xpZW50MAoGA1UECxMDam5qMRYwFAYDVQQDEw1y<br> Y2Etam5qLWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEk4b8f5mWq+jf<br> iMKQBVI8uU7btAF/LSSdXoOXYPW8JyJ23v5wtwRiQ/g4Al/6aIchvAC4QhJRUnz0<br> DMKuI7GCp6NmMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw<br> HQYDVR0OBBYEFNuvs8Q9fpkg3oA+i2OEuR3qE96oMB8GA1UdIwQYMBaAFBGV3Han<br> Nf1T5i8fvDh239lt5W9DMAoGCCqGSM49BAMCA0gAMEUCIQD/4+AUOMBdofQEVsH2<br> 2A6UGiJQvuplLEBA9in0cZTcCQIgcV5K+KCs3a5RNYUWdllakGx8c1f6ISrmk4an<br> gjeXphQ=3D<br> -----END CERTIFICATE-----<br>  2 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= CN =3D rca-jnj<br>    i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Joh= nson, CN =3D rca-jnj<br> -----BEGIN CERTIFICATE-----<br> MIIB/TCCAaOgAwIBAgIUSsxdq02aJCyaIHkIRxRdKvWYG9swCgYIKoZIzj0EAwIw<br> WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa<br> MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN<br> MTkwMjAxMjExNDAwWhcNMzQwMTI4MjExNDAwWjBbMQswCQYDVQQGEwJVUzELMAkG<br> A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg<br> Sm9obnNvbjEQMA4GA1UEAxMHcmNhLWpuajBZMBMGByqGSM49AgEGCCqGSM49AwEH<br> A0IABCF30Cn+O5sD/9n6d3IQQEGiceCTD7gG/5t4dHR4xmvm84HNgRngGKGF4fny<br> 6BXkPSyDguP+L5zozdWDb8dWTQejRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB<br> Af8ECDAGAQH/AgEBMB0GA1UdDgQWBBQRldx2pzX9U+YvH7w4dt/ZbeVvQzAKBggq<br> hkjOPQQDAgNIADBFAiEAkCQcOP+PmyVIMgr/cUsk04qH8lXYO4DqDuH1WSNvGfEC<br> IBZQGRehpZ604FgkD0YqmiGRV/OzU99em0g3jkmWJbJY<br> -----END CERTIFICATE-----<br> ---<br> Server certificate<br> subject=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D jnj-ldap-server<br> <br> issuer=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, = OU =3D client + OU =3D jnj, CN =3D rca-jnj-admin<br> <br> ---<br> No client certificate CA names sent<br> Peer signing digest: SHA256<br> Peer signature type: ECDSA<br> Server Temp Key: X25519, 253 bits<br> ---<br> SSL handshake has read 2254 bytes and written 391 bytes<br> Verification: OK<br> ---<br> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384<br> Server public key is 256 bit<br> Secure Renegotiation IS NOT supported<br> Compression: NONE<br> Expansion: NONE<br> No ALPN negotiated<br> Early data was not sent<br> Verify return code: 0 (ok)<br> ---<br> SSL_connect:SSL negotiation finished successfully<br> SSL_connect:SSL negotiation finished successfully<br> ---<br> Post-Handshake New Session Ticket arrived:<br> SSL-Session:<br>     Protocol  : TLSv1.3<br>     Cipher    : TLS_AES_256_GCM_SHA384<br>     Session-ID: 4E6019F281D63D69D1C800DF4D2441CC918FF4A3AFA8= A0A6D6D05FFB544E91F2<br>     Session-ID-ctx:<br>     Resumption PSK: A00E7F64B5EA00718122A6F34EF0EC9167F437BD= B832D9C64834D18F367E8AD2AD5F9BCF9649330D321DC19D0AB49882<br>     PSK identity: None<br>     PSK identity hint: None<br>     SRP username: None<br>     TLS session ticket lifetime hint: 7200 (seconds)<br>     TLS session ticket:<br>     0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90&n= bsp;  .~[.=3Do.Ix....xX.<br>     0010 - 00 78 10 a6 94 fb 36 96-f9 8b 17 53 8b 27 14 b5&n= bsp;  .x....6....S.'..<br>     0020 - 5d 2d 28 3b db 26 71 44-65 c3 43 d6 8e e8 46 a8&n= bsp;  ]-(;.&qDe.C...F.<br>     0030 - 05 8a 34 57 c0 42 71 03-4f 70 ad 20 07 74 fc 94&n= bsp;  ..4W.Bq.Op. .t..<br>     0040 - e8 e4 9d 89 d0 45 db 2c-62 4a 28 b6 31 f9 3f af&n= bsp;  .....E.,bJ(.1.?.<br>     0050 - 46 7c f7 f8 9f b1 0b 7c-ea 70 a1 f0 4c 2f 62 0a&n= bsp;  F|.....|.p..L/b.<br>     0060 - e3 e9 83 47 0e f2 e5 71-a5 0c ba 2a 8d 7d f8 e2&n= bsp;  ...G...q...*.}..<br>     0070 - 21 84 1a 1a 86 4f 02 0a-4c 9a 17 77 af 9e 64 1f&n= bsp;  !....O..L..w..d.<br>     0080 - 72 c5 e5 45 d1 bb 92 0a-ae fe e9 b1 bc 46 7d 13&n= bsp;  r..E.........F}.<br>     0090 - aa 2b 9b c1 3d 92 8b 1d-08 6c 11 12 a0 b7 c8 a3&n= bsp;  .+..=3D....l......<br>     00a0 - b2 bb 2b d9 bd 70 86 0d-91 45 5c 23 b6 b0 6a 3a&n= bsp;  ..+..p...E\#..j:<br>     00b0 - 61 1d 3a c1 4a 36 48 b4-b3 03 a9 8b 41 94 fd 67&n= bsp;  a.:.J6H.....A..g<br>     00c0 - 53 a6 03 a4 ab c6 a0 7e-e9 39 98 a8 c9 01 bc c0&n= bsp;  S......~.9......<br> <br>     Start Time: 1556123794<br>     Timeout   : 7200 (sec)<br>     Verify return code: 0 (ok)<br>     Extended master secret: no<br>     Max Early Data: 0<br> ---<br> SSL_connect:SSLv3/TLS read server session ticket<br> read R BLOCK<br> SSL_connect:SSL negotiation finished successfully<br> SSL_connect:SSL negotiation finished successfully<br> ---<br> Post-Handshake New Session Ticket arrived:<br> SSL-Session:<br>     Protocol  : TLSv1.3<br>     Cipher    : TLS_AES_256_GCM_SHA384<br>     Session-ID: A7B81922756F8F5B986C7B38E0F29399F8127F52D042= EB7D0DCEDB8D4CD577B5<br>     Session-ID-ctx:<br>     Resumption PSK: 5FDD5DF642126A4F04D05EBBECDBB92BBCBAB6A7= E05051224D646693BBD0B964C039185F933442D400BBCBC92A832913<br>     PSK identity: None<br>     PSK identity hint: None<br>     SRP username: None<br>     TLS session ticket lifetime hint: 7200 (seconds)<br>     TLS session ticket:<br>     0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90&n= bsp;  .~[.=3Do.Ix....xX.<br>     0010 - d3 10 28 b9 01 6b 4b 92-1e 3e ae 3b 7f 4e cc 6c&n= bsp;  ..(..kK..>.;.N.l<br>     0020 - 19 d3 0b ac 9c b9 21 4d-ed 78 2c 35 d3 03 ba 11&n= bsp;  ......!M.x,5....<br>     0030 - 22 59 1c 0d 91 a5 da 93-a0 0a 54 88 aa 81 be 89&n= bsp;  "Y........T.....<br>     0040 - e0 2e 74 71 8e c8 fd f7-9d 5c 99 15 42 23 47 cf&n= bsp;  ..tq.....\..B#G.<br>     0050 - 0d 56 97 10 f3 f8 02 fe-69 65 e6 1c fa 7d 96 fe&n= bsp;  .V......ie...}..<br>     0060 - 86 d2 c2 64 2c 6e 96 3d-14 e2 87 47 91 69 ef df&n= bsp;  ...d,n.=3D...G.i..<br>     0070 - 14 d5 75 0d ff da 61 04-26 56 5d 8b d3 4d 2d 2d&n= bsp;  ..u...a.&V]..M--<br>     0080 - 78 fa 65 6d ad ef 15 ba-14 45 f0 ba a6 85 fb 95&n= bsp;  x.em.....E......<br>     0090 - dc e5 9b 1c ac e4 66 de-c2 6e 3f e7 1e 47 09 25&n= bsp;  ......f..n?..G.%<br>     00a0 - 89 b0 c3 c0 4c 93 64 de-23 3e 58 67 ae f3 7e e4&n= bsp;  ....L.d.#>Xg..~.<br>     00b0 - d5 af 4d 31 40 24 87 da-ec e7 3f 8a 48 b5 9d 23&n= bsp;  ..M1@$....?.H..#<br>     00c0 - d4 53 01 fa 18 39 79 0f-9b 9c ea ed 71 63 c5 2f&n= bsp;  .S...9y.....qc./<br> <br>     Start Time: 1556123794<br>     Timeout   : 7200 (sec)<br>     Verify return code: 0 (ok)<br>     Extended master secret: no<br>     Max Early Data: 0<br> ---<br> SSL_connect:SSLv3/TLS read server session ticket<br> read R BLOCK<br> SSL3 alert read:warning:close notify<br> closed<br> SSL3 alert write:warning:close notify<br> vielle:/home/software/openldap-bug><br> ###<br> <br> There is no OpenLDAP bug here. Your server environment is broken.<br> -- <br>   -- Howard Chu<br>   CTO, Symas Corp.        &nbs= p;  <a href=3D"https://eur04.safelinks.protection.outlook.com/?url=3Dh= ttp%3A%2F%2Fwww.symas.com&amp;data=3D02%7C01%7C%7Caca4f78e53324b5269000= 8d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238= &amp;sdata=3DyzZvZLe34LJJfhMqjtBoGhJqMXnLSPdeBExlpYnMKqY%3D&amp;res= erved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.syma= s.com&amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84df9e= 7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp;sdata=3DyzZ= vZLe34LJJfhMqjtBoGhJqMXnLSPdeBExlpYnMKqY%3D&amp;reserved=3D0</a><br>   Director, Highland Sun     <a href=3D"https://eu= r04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighlandsun.com%2F= hyc%2F&amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84df9= e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp;sdata=3Dc%= 2B1myt04g7sv1kXBUCwd1bUgQV4HGrjAgYgsPoAXLpA%3D&amp;reserved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighland= sun.com%2Fhyc%2F&amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc= 09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp;= sdata=3Dc%2B1myt04g7sv1kXBUCwd1bUgQV4HGrjAgYgsPoAXLpA%3D&amp;reserved= =3D0</a><br>   Chief Architect, OpenLDAP  <a href=3D"https://eur04.safelinks.p= rotection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&amp= ;amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84df9e7fe9f640a= fb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp;sdata=3DbMFyP0JzruNw= nxXozQQnUVYg2WrYvQJ1PFDWdgkd6zc%3D&amp;reserved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.open= ldap.org%2Fproject%2F&amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c= 8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp= ;amp;sdata=3DbMFyP0JzruNwnxXozQQnUVYg2WrYvQJ1PFDWdgkd6zc%3D&amp;reserve= d=3D0</a><br> </div> </span></font></div> </div> </body> </html> --_000_MWHPR08MB2400F5334463D5A204E8CF88B53C0MWHPR08MB2400namp_--

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by hyc＠symas.com 24 Apr '19

24 Apr '19

Siddharth Jain wrote: > we have documented complete steps to repro the bug=A0here <https://gith= ub.com/siddjain/openldap-bug>=A0with container logs. I see no error here. Using your cert/key files: > ls -l /tmp/jnj total 12 -rw-r--r-- 1 hyc hyc 1592 Apr 24 17:34 jnj-ca-chain.pem -rw-r--r-- 1 hyc hyc 241 Apr 24 17:34 jnj-ldap-server-tls.key -rw-r--r-- 1 hyc hyc 1111 Apr 24 17:34 jnj-ldap-server-tls.pem ### With this slapd config vielle:~/OD/hobj/tests> cat testrun/slapd.1.conf include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/openldap.schema include ./schema/nis.schema include ./testdata/test.schema pidfile /home/hyc/OD/hobj/tests/testrun/slapd.1.pid argsfile /home/hyc/OD/hobj/tests/testrun/slapd.1.args sockbuf_max_incoming 4194303 TLSCAcertificatefile /tmp/jnj/jnj-ca-chain.pem TLSCertificateFile /tmp/jnj/jnj-ldap-server-tls.pem TLSCertificateKeyFile /tmp/jnj/jnj-ldap-server-tls.key database mdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DManager,dc=3Dexample,dc=3Dcom" rootpw secret directory /home/hyc/OD/hobj/tests/testrun/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub maxsize 33554432 database monitor ### And this slapd invocation from the OpenLDAP build tree vielle:~/OD/hobj/tests> ../servers/slapd/slapd -f testrun/slapd.1.conf -h= ldaps://:9011 -s0 -d7 I get no verification error: > openssl s_client -connect localhost:9011 -state -nbio -CAfile jnj-ca-ch= ain.pem -showcerts CONNECTED(00000005) Turned on non blocking io SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write R BLOCK SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:TLSv1.3 read encrypted extensions depth=3D2 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, C= N =3D rca-jnj verify return:1 depth=3D1 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, O= U =3D client + OU =3D jnj, CN =3D rca-jnj-admin verify return:1 depth=3D0 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, O= U =3D client + OU =3D jnj, CN =3D jnj-ldap-server verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL_connect:TLSv1.3 read server certificate verify SSL_connect:SSLv3/TLS read finished SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished read R BLOCK --- Certificate chain 0 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D= client + OU =3D jnj, CN =3D jnj-ldap-server i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D= client + OU =3D jnj, CN =3D rca-jnj-admin -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIUcxrGrCSwJwlQhBEuKztfLgRrtygwCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzANBgNVBAsTBmNsaWVudDAKBgNV BAsTA2puajEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MjIxNzE0MDBa Fw0yMDA0MjExNzE5MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMA0G A1UECxMGY2xpZW50MAoGA1UECxMDam5qMRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARutu4G452HY8vYKJLw9VXmIuz+ X1XNNwyI6q7KzzwNmTwzWyHIVzxjqNTsTRqY0L0lLI1cko2LsIACqnJTed7yo4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTPS+Zc8+ZDmpVS9XerpVD1gYL7 cjAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQDBbbexORUa nrBJG8iSkADdOIW/ZOK7kbpLJ4x6GdTO8gIgfzOqW/9ZJKFM3PBls6bEVacoRLX9 AklAHxajASZK+UU=3D -----END CERTIFICATE----- 1 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D= client + OU =3D jnj, CN =3D rca-jnj-admin i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D= rca-jnj -----BEGIN CERTIFICATE----- MIICQTCCAeegAwIBAgIUBU9O3Wb3BDS8YuWRLYaKClbA9ZcwCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjMxOTAwWhcNMjQwMTMxMjMyNDAwWjB+MQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEbMA0GA1UECxMGY2xpZW50MAoGA1UECxMDam5qMRYwFAYDVQQDEw1y Y2Etam5qLWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEk4b8f5mWq+jf iMKQBVI8uU7btAF/LSSdXoOXYPW8JyJ23v5wtwRiQ/g4Al/6aIchvAC4QhJRUnz0 DMKuI7GCp6NmMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFNuvs8Q9fpkg3oA+i2OEuR3qE96oMB8GA1UdIwQYMBaAFBGV3Han Nf1T5i8fvDh239lt5W9DMAoGCCqGSM49BAMCA0gAMEUCIQD/4+AUOMBdofQEVsH2 2A6UGiJQvuplLEBA9in0cZTcCQIgcV5K+KCs3a5RNYUWdllakGx8c1f6ISrmk4an gjeXphQ=3D -----END CERTIFICATE----- 2 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D= rca-jnj i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D= rca-jnj -----BEGIN CERTIFICATE----- MIIB/TCCAaOgAwIBAgIUSsxdq02aJCyaIHkIRxRdKvWYG9swCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjExNDAwWhcNMzQwMTI4MjExNDAwWjBbMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEQMA4GA1UEAxMHcmNhLWpuajBZMBMGByqGSM49AgEGCCqGSM49AwEH A0IABCF30Cn+O5sD/9n6d3IQQEGiceCTD7gG/5t4dHR4xmvm84HNgRngGKGF4fny 6BXkPSyDguP+L5zozdWDb8dWTQejRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEBMB0GA1UdDgQWBBQRldx2pzX9U+YvH7w4dt/ZbeVvQzAKBggq hkjOPQQDAgNIADBFAiEAkCQcOP+PmyVIMgr/cUsk04qH8lXYO4DqDuH1WSNvGfEC IBZQGRehpZ604FgkD0YqmiGRV/OzU99em0g3jkmWJbJY -----END CERTIFICATE----- --- Server certificate subject=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, O= U =3D client + OU =3D jnj, CN =3D jnj-ldap-server issuer=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU= =3D client + OU =3D jnj, CN =3D rca-jnj-admin --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2254 bytes and written 391 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 4E6019F281D63D69D1C800DF4D2441CC918FF4A3AFA8A0A6D6D05FFB5= 44E91F2 Session-ID-ctx: Resumption PSK: A00E7F64B5EA00718122A6F34EF0EC9167F437BDB832D9C64834D= 18F367E8AD2AD5F9BCF9649330D321DC19D0AB49882 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90 .~[.=3Do.Ix.= ...xX. 0010 - 00 78 10 a6 94 fb 36 96-f9 8b 17 53 8b 27 14 b5 .x....6....S= .'.. 0020 - 5d 2d 28 3b db 26 71 44-65 c3 43 d6 8e e8 46 a8 ]-(;.&qDe.C.= ..F. 0030 - 05 8a 34 57 c0 42 71 03-4f 70 ad 20 07 74 fc 94 ..4W.Bq.Op. = .t.. 0040 - e8 e4 9d 89 d0 45 db 2c-62 4a 28 b6 31 f9 3f af .....E.,bJ(.= 1.?. 0050 - 46 7c f7 f8 9f b1 0b 7c-ea 70 a1 f0 4c 2f 62 0a F|.....|.p..= L/b. 0060 - e3 e9 83 47 0e f2 e5 71-a5 0c ba 2a 8d 7d f8 e2 ...G...q...*= .}.. 0070 - 21 84 1a 1a 86 4f 02 0a-4c 9a 17 77 af 9e 64 1f !....O..L..w= ..d. 0080 - 72 c5 e5 45 d1 bb 92 0a-ae fe e9 b1 bc 46 7d 13 r..E........= .F}. 0090 - aa 2b 9b c1 3d 92 8b 1d-08 6c 11 12 a0 b7 c8 a3 .+..=3D....l= ...... 00a0 - b2 bb 2b d9 bd 70 86 0d-91 45 5c 23 b6 b0 6a 3a ..+..p...E\#= ..j: 00b0 - 61 1d 3a c1 4a 36 48 b4-b3 03 a9 8b 41 94 fd 67 a.:.J6H.....= A..g 00c0 - 53 a6 03 a4 ab c6 a0 7e-e9 39 98 a8 c9 01 bc c0 S......~.9..= .... Start Time: 1556123794 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: A7B81922756F8F5B986C7B38E0F29399F8127F52D042EB7D0DCEDB8D4= CD577B5 Session-ID-ctx: Resumption PSK: 5FDD5DF642126A4F04D05EBBECDBB92BBCBAB6A7E05051224D646= 693BBD0B964C039185F933442D400BBCBC92A832913 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90 .~[.=3Do.Ix.= ...xX. 0010 - d3 10 28 b9 01 6b 4b 92-1e 3e ae 3b 7f 4e cc 6c ..(..kK..>.;= .N.l 0020 - 19 d3 0b ac 9c b9 21 4d-ed 78 2c 35 d3 03 ba 11 ......!M.x,5= .... 0030 - 22 59 1c 0d 91 a5 da 93-a0 0a 54 88 aa 81 be 89 "Y........T.= .... 0040 - e0 2e 74 71 8e c8 fd f7-9d 5c 99 15 42 23 47 cf ..tq.....\..= B#G. 0050 - 0d 56 97 10 f3 f8 02 fe-69 65 e6 1c fa 7d 96 fe .V......ie..= .}.. 0060 - 86 d2 c2 64 2c 6e 96 3d-14 e2 87 47 91 69 ef df ...d,n.=3D..= .G.i.. 0070 - 14 d5 75 0d ff da 61 04-26 56 5d 8b d3 4d 2d 2d ..u...a.&V].= .M-- 0080 - 78 fa 65 6d ad ef 15 ba-14 45 f0 ba a6 85 fb 95 x.em.....E..= .... 0090 - dc e5 9b 1c ac e4 66 de-c2 6e 3f e7 1e 47 09 25 ......f..n?.= .G.% 00a0 - 89 b0 c3 c0 4c 93 64 de-23 3e 58 67 ae f3 7e e4 ....L.d.#>Xg= ..~. 00b0 - d5 af 4d 31 40 24 87 da-ec e7 3f 8a 48 b5 9d 23 ..M1@$....?.= H..# 00c0 - d4 53 01 fa 18 39 79 0f-9b 9c ea ed 71 63 c5 2f .S...9y.....= qc./ Start Time: 1556123794 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL3 alert read:warning:close notify closed SSL3 alert write:warning:close notify vielle:/home/software/openldap-bug> ### There is no OpenLDAP bug here. Your server environment is broken. --=20 -- 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

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by siddjain＠live.com 24 Apr '19

24 Apr '19

--_000_MWHPR08MB24001BB2C0F56927A628AF69B53C0MWHPR08MB2400namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable we have documented complete steps to repro the bug here<https://github.com/= siddjain/openldap-bug> with container logs. ________________________________ From: Howard Chu <hyc(a)symas.com> Sent: Monday, April 22, 2019 10:15 AM To: siddjain(a)live.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate bef= ore sending it to client siddjain(a)live.com wrote: > Full_Name: SIDDHARTH JAIN > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (173.226.196.10) > > > In some cases, OpenLDAP will modify the TLS certificate given to it befor= e > sending it over to the client resulting in a certificate signature error.= An > example of certificate it modifies is given below: OpenLDAP never touches the certificates you configure. If you're getting a = corrupted certificate then there's either a bug in your storage/filesystem or in your= SSL/TLS library. -- -- Howard Chu CTO, Symas Corp. https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.symas.com&data=3D02%7C01%7C%7Cb0dec02e090a48ff= 954b08d6c7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6369155015543= 63548&sdata=3D7ca82woC2PGsf9x0qYDT1izZ5MSqJbxA4T9m8kq5y2Y%3D&reserv= ed=3D0 Director, Highland Sun https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fhighlandsun.com%2Fhyc%2F&data=3D02%7C01%7C%7Cb0dec= 02e090a48ff954b08d6c7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63= 6915501554363548&sdata=3DFr3v%2FI3WSXtWqXOFDY%2F9Z4%2FqS%2F%2FvC4YMJQDR= GNjx8Lo%3D&reserved=3D0 Chief Architect, OpenLDAP https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&data=3D02%7C01%7C%7C= b0dec02e090a48ff954b08d6c7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0= %7C636915501554373561&sdata=3DJ%2B926RRaeQIx6%2BIvx70BnHqZ0zj4SO5ilR6VP= vdiTsk%3D&reserved=3D0 --_000_MWHPR08MB24001BB2C0F56927A628AF69B53C0MWHPR08MB2400namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> <span style=3D"color: rgb(36, 41, 46); font-family: -apple-system, system-u= i, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Em= oji", "Segoe UI Emoji", "Segoe UI Symbol"; font-si= ze: 14px; background-color: rgb(255, 255, 255); display: inline !important"= >we have documented complete steps to repro the bug<span> </span></span><= a href=3D"https://github.com/siddjain/openldap-bug" style=3D"box-sizing: bo= rder-box; background-color: rgb(255, 255, 255); color: rgb(3, 102, 214); fo= nt-family: -apple-system, system-ui, "Segoe UI", Helvetica, Arial= , sans-serif, "Apple Color Emoji", "Segoe UI Emoji", &q= uot;Segoe UI Symbol"; font-size: 14px">here</a><span style=3D"color: r= gb(36, 41, 46); font-family: -apple-system, system-ui, "Segoe UI"= , Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe = UI Emoji", "Segoe UI Symbol"; font-size: 14px; background-co= lor: rgb(255, 255, 255); display: inline !important"><span> </span>wit= h container logs.</span><br> </div> <div> <div id=3D"appendonsend"></div> <div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col= or:rgb(0,0,0)"> <br> </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co= lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Howard Chu <hyc@sy= mas.com><br> <b>Sent:</b> Monday, April 22, 2019 10:15 AM<br> <b>To:</b> siddjain(a)live.com; openldap-its(a)OpenLDAP.org<br> <b>Subject:</b> Re: (ITS#9014) OpenLDAP modifies user provided TLS certific= ate before sending it to client</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"= > <div class=3D"PlainText">siddjain(a)live.com wrote:<br> > Full_Name: SIDDHARTH JAIN<br> > Version: 2.4.45<br> > OS: Linux<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o= rg/incoming/</a><br> > Submission from: (NULL) (173.226.196.10)<br> > <br> > <br> > In some cases, OpenLDAP will modify the TLS certificate given to it be= fore<br> > sending it over to the client resulting in a certificate signature err= or. An<br> > example of certificate it modifies is given below:<br> <br> OpenLDAP never touches the certificates you configure. If you're getting a = corrupted<br> certificate then there's either a bug in your storage/filesystem or in your= SSL/TLS library.<br> <br> -- <br>   -- Howard Chu<br>   CTO, Symas Corp.        &nbs= p;  <a href=3D"https://eur04.safelinks.protection.outlook.com/?url=3Dh= ttp%3A%2F%2Fwww.symas.com&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b0= 8d6c7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554363548= &amp;sdata=3D7ca82woC2PGsf9x0qYDT1izZ5MSqJbxA4T9m8kq5y2Y%3D&amp;res= erved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.syma= s.com&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c7462da0%7C84df9e= 7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554363548&amp;sdata=3D7ca= 82woC2PGsf9x0qYDT1izZ5MSqJbxA4T9m8kq5y2Y%3D&amp;reserved=3D0</a><br>   Director, Highland Sun     <a href=3D"https://eu= r04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighlandsun.com%2F= hyc%2F&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c7462da0%7C84df9= e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554363548&amp;sdata=3DFr= 3v%2FI3WSXtWqXOFDY%2F9Z4%2FqS%2F%2FvC4YMJQDRGNjx8Lo%3D&amp;reserved=3D0= "> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighland= sun.com%2Fhyc%2F&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c7462d= a0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554363548&amp;= sdata=3DFr3v%2FI3WSXtWqXOFDY%2F9Z4%2FqS%2F%2FvC4YMJQDRGNjx8Lo%3D&amp;re= served=3D0</a><br>   Chief Architect, OpenLDAP  <a href=3D"https://eur04.safelinks.p= rotection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&amp= ;amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c7462da0%7C84df9e7fe9f640a= fb435aaaaaaaaaaaa%7C1%7C0%7C636915501554373561&amp;sdata=3DJ%2B926RRaeQ= Ix6%2BIvx70BnHqZ0zj4SO5ilR6VPvdiTsk%3D&amp;reserved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.open= ldap.org%2Fproject%2F&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c= 7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554373561&amp= ;amp;sdata=3DJ%2B926RRaeQIx6%2BIvx70BnHqZ0zj4SO5ilR6VPvdiTsk%3D&amp;res= erved=3D0</a><br> </div> </span></font></div> </div> </body> </html> --_000_MWHPR08MB24001BB2C0F56927A628AF69B53C0MWHPR08MB2400namp_--

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by ondra＠mistotebe.net 24 Apr '19

24 Apr '19

On Tue, Apr 23, 2019 at 11:28:40PM +0000, quanah(a)symas.com wrote: > --On Tuesday, April 23, 2019 8:56 PM +0200 Ond=C5=99ej Kuzn=C3=ADk=20 > <ondra(a)mistotebe.net> wrote: >> Going by what I think I remember of the consumer code did: >> - on set up, it finds out there's no cookie to go by so it goes into >> refresh on the main DB >> - main DB responds with success but no/empty cookie >> - consumer starts over but again finds itself with no cookie, so it goes >> to step one >> >> But the consumer is actually up to date at that point as the search >> suggested, so it should just go ahead and do the refreshAndPersist on >> accesslog as it planned to originally. And as operations hit the main >> DB, they will replicate accordingly, even if that were to happen after >> the original search and before this one[0]. > > The consumer did not replicate the database as a part of the initial > search, so I don't think it qualifies as "up to date". I.e., it's primary > DB remains empty. Ah, that wasn't mentioned, my assumption was that the source DB was actually empty. This is coming from ITS#8281 fix in cd8ff37629012c1676ef79de164a159da9b2ae89. There are two scenarios that need different treatment: 1. We start with no servers and no data and want to set up MMR from there 2. We start with a live server and want to move over to MMR The bootstrap scenario is the one I outlined in my response above, the consumers should be able to deal with it correctly if they do what I say. However the provider should make it possible for the client to know that's what's happening, so it should only send an empty cookie-less response in the case DB is empty. The conversion to MMR should be dealt with differently. AFAIK, the correct order of set up is: - prepare original master: - serverID == 0 - add syncprov - change serverID accordingly - connect other servers: - set serverIDs - add olcSyncrepl everywhere (including original master) - wait for things to settle, you're done I agree it is necessary we make sure not following the above still results either with a helpful error or that it also Just Works(tm). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9016) cn=config should fail on EMIT if target directory not empty
by michael＠stroeder.com 24 Apr '19

24 Apr '19

This is a cryptographically signed message in MIME format. --------------ms030705030102060301060203 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/24/19 1:32 PM, ondra(a)openldap.org wrote: > Since it's not feasible to clean up properly, it should just return an = error > instead? Yes. In general I prefer fail-early-fail-hard with clear error messages. Ciao, Michael. --------------ms030705030102060301060203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyEwggUzMIIEG6ADAgECAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODEyMTYwMDAw MDBaFw0xOTEyMTYyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ryb2VkZXIu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvdaCPHlSjB9Wb51jh60x+6OO lOP14FSXRNDYWcuaCwey30JdrJxw9VMiBEJo7Q7fHWcpna9l9oVKuvjO3VepiyTlQoinvwSG gQrBburWskKupOJPwv0QH8nWpc9KnP7LnOqfepwHNrqhweijxeGg95TQeDfOVbQmGwqnaCtp CBuCu3gyxe/wVkKnr6uqwHFUoGSNIrLAdLFcnFbpKGoYvZvahkdLNglCRLpeSVu9/O0MqkGt gGp6nPcTHwbZYSoGqFJQjPeTlczubTKo9DWYhZ0vMB2fjdadSqZxUgqqdElLRWSqRD1jCm3U xShVkPJDQg3tkQq6Yw4C1Z9+L9KxJQIDAQABo4IB6jCCAeYwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFLn0/ESCAOEV6clL6lYXzOwKIKlyMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wDQYJKoZIhvcNAQELBQADggEB ALFD55CXI+vy81ngFjheHu+TjKJuxrYfw71qz54pmYwR4UYBTSLNvESJXwOfSi7UxBh97xjB bjy5rDByXl1IWAFXcnoHPKJNZL8wOa0MNz4o3X0of7JHZHYlyXJRnZV90+KtZQdn5ZP2hBmg SHxcjdgCMU9p6VoOlJLhpEKN1TmbHq/elcwZKknnGN+54Vn2RhVP0x3998yyhIkiHNAqQImT cqY5QkpGxyocLz54NXudIZSvXyvQI4d7FYl4JKn6gw4PRXht0/xzB/GGGKGWSrgdPCUJ4Rif cGpO43inEBxWlW19cjYSXjqZetq2ZIJnrADxTttTJoUQsGuoT5ZMf2UwggXmMIIDzqADAgEC AhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra 0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr 5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTq Rvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDa ElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEA AaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIB ADARBgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21v ZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUH AQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FB ZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0G CSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj 6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxm gUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTC kk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlL WPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzOb XYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtF OI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3C VJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wk yk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCBDUwggQxAgEB MIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXMmH IQX8SWTc7x5fq9i6IjANBglghkgBZQMEAgEFAKCCAlkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDI0MTIwMzU1WjAvBgkqhkiG9w0BCQQxIgQgn56E SGO4wXtKJNZ055HSw53D3LbVbJTHd7PGKrb0KSkwbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXMmHIQX8SWTc 7x5fq9i6IjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBAQUA BIIBAJD4gv8eWV6VCHuVWTALdiWdt2YNBvDN7tyVNwURCnW+mlB9gPxBR1uJMp2L49dEdESO 0Dg/A61z0sO35S0wJYCLU8L7RuNahsjkZg8/CSaAPpnbG2xs3jaLNzhaPb1WULR9qbNyJ8dp xwdMSp19gMNUpgTLmHYmsTeAvtujjp4eZwh9VufCbcFstJOMWYO2fyBpJilG4RIouM2bPCLo ii4tAzSDONIeF7W1W1G73xLkw1lmSS4N1zBg1dFJgMTp9bcrGkBqzJajrpeWN2nUGuZBl+xi ucV4w8hezAnVVE8UFofDxn8i1JPsMoCjr1tBcSQg4NQzA5p3nnrOb5ERpDcAAAAAAAA= --------------ms030705030102060301060203--

1 0

(ITS#9016) cn=config should fail on EMIT if target directory not empty
by ondra＠openldap.org 24 Apr '19

24 Apr '19

Full_Name: Ondrej Kuznik Version: re24/master OS: URL: Submission from: (NULL) (82.10.24.68) Running slapd/slaptest to convert a slapd.conf to cn=config will happily reuse the target directory. However if there was some existing configuration present already, slaptest reports a successful conversion, even though the resulting directory most likely won't represent the slapd.conf used - existing .ldif files won't be replaced or removed. Depending on the differences between slapd.conf and slapd.d in place, the result might not even be a useable cn=config anymore. Since it's not feasible to clean up properly, it should just return an error instead?

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by quanah＠symas.com 24 Apr '19

24 Apr '19

--On Tuesday, April 23, 2019 8:56 PM +0200 Ond=C5=99ej Kuzn=C3=ADk=20 <ondra(a)mistotebe.net> wrote: > Going by what I think I remember of the consumer code did: > - on set up, it finds out there's no cookie to go by so it goes into > refresh on the main DB > - main DB responds with success but no/empty cookie > - consumer starts over but again finds itself with no cookie, so it goes > to step one > > But the consumer is actually up to date at that point as the search > suggested, so it should just go ahead and do the refreshAndPersist on > accesslog as it planned to originally. And as operations hit the main > DB, they will replicate accordingly, even if that were to happen after > the original search and before this one[0]. The consumer did not replicate the database as a part of the initial=20 search, so I don't think it qualifies as "up to date". I.e., it's primary=20 DB remains empty. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs