openldap-bugs October 2018

openldap-bugs@openldap.org

16 participants
44 discussions

Re: (ITS#8125) MMR throws away valid changes causing drift
by hyc＠symas.com 15 Oct '18

15 Oct '18

Ond=C5=99ej Kuzn=C3=ADk wrote: > On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc(a)symas.com wrote: >> ondra(a)mistotebe.net wrote: >>> Also, whenever we fall back from deltasync into plain syncrepl, we >>> should make sure that the accesslog entries we generate from this = are >>> never used for further replication which might be thought to be a >>> separate issue. >> >> That should already be the case, since none of these ops will have a v= alid CSN. >=20 > I faintly remember Quanah seeing these accesslog entries used by > consumers at some point, but I might be mistaken. >=20 > The more general point is making sure its potential syncrepl consumer > not even try and use the accesslog entries we added before these - the > refresh has created a strange gap in the middle (or worse, duplicated > ops if a contextCSN element jumped backwards). But if we enforced that, > the question is how to get modifications originating from this replica > replicated elsewhere - unless we decide they can't be salvaged? We could set the replica to reject user mods while in refresh phase. Not = sure how friendly that is, whether apps would be smart enough to retry somewhe= re else. > And should the contextCSN reset terminate not just all inbound syncrepl > sessions, but the outbound ones as well? Need to be careful about race conditions here, or you could end up with a= ll nodes just terminating each other and everything halting. --=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#8125) MMR throws away valid changes causing drift
by ondra＠mistotebe.net 15 Oct '18

15 Oct '18

On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> This is my understanding of the above discussion: >> - deltasync consumer has just switched to full refresh (but is ahead >> from this provider in some ways) >> - provider sends the present list >> - consumer deletes extra entries, builds a new cookie >> - problem is that the new cookie is built to reflect the union of both >> the local and received cookies even though we may have undone some of >> the changes which we then ignore >> >> If that's accurate, there are some approaches that could fix it: >> >> 1. Simple one is to remember the actual cookie we got from the server >> and refuse to delete entries with entryCSN ahead of the provided CSN >> set. Problem is that we get even further from being able to replicate >> from a generic RFC4533 provider. >> >> 2. Instead, when present phase is initiated, we might terminate all >> other sessions, adopt the complete CSN set and restart them only once >> the new CSN set has been fully established. > > (2) makes sense. >> >> Also, whenever we fall back from deltasync into plain syncrepl, we >> should make sure that the accesslog entries we generate from this are >> never used for further replication which might be thought to be a >> separate issue. > > That should already be the case, since none of these ops will have a valid CSN. I faintly remember Quanah seeing these accesslog entries used by consumers at some point, but I might be mistaken. The more general point is making sure its potential syncrepl consumer not even try and use the accesslog entries we added before these - the refresh has created a strange gap in the middle (or worse, duplicated ops if a contextCSN element jumped backwards). But if we enforced that, the question is how to get modifications originating from this replica replicated elsewhere - unless we decide they can't be salvaged? And should the contextCSN reset terminate not just all inbound syncrepl sessions, but the outbound ones as well? -- 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#8125) MMR throws away valid changes causing drift
by hyc＠symas.com 15 Oct '18

15 Oct '18

ondra(a)mistotebe.net wrote: > This is my understanding of the above discussion: > - deltasync consumer has just switched to full refresh (but is ahead > from this provider in some ways) > - provider sends the present list > - consumer deletes extra entries, builds a new cookie > - problem is that the new cookie is built to reflect the union of both > the local and received cookies even though we may have undone some of > the changes which we then ignore > > If that's accurate, there are some approaches that could fix it: > > 1. Simple one is to remember the actual cookie we got from the server > and refuse to delete entries with entryCSN ahead of the provided CSN > set. Problem is that we get even further from being able to replicate > from a generic RFC4533 provider. > > 2. Instead, when present phase is initiated, we might terminate all > other sessions, adopt the complete CSN set and restart them only once > the new CSN set has been fully established. (2) makes sense. > > Also, whenever we fall back from deltasync into plain syncrepl, we > should make sure that the accesslog entries we generate from this are > never used for further replication which might be thought to be a > separate issue. That should already be the case, since none of these ops will have a valid CSN. > Maybe the ITS#8486 work might be useful for this if > we have a way of signalling to accesslog to reset minCSN accordingly > to the new CSN set. > > The former is simpler, but the latter feels like the only one that > actually addresses these problems in full. > -- -- 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#8125) MMR throws away valid changes causing drift
by ondra＠mistotebe.net 15 Oct '18

15 Oct '18

This is my understanding of the above discussion: - deltasync consumer has just switched to full refresh (but is ahead from this provider in some ways) - provider sends the present list - consumer deletes extra entries, builds a new cookie - problem is that the new cookie is built to reflect the union of both the local and received cookies even though we may have undone some of the changes which we then ignore If that's accurate, there are some approaches that could fix it: 1. Simple one is to remember the actual cookie we got from the server and refuse to delete entries with entryCSN ahead of the provided CSN set. Problem is that we get even further from being able to replicate from a generic RFC4533 provider. 2. Instead, when present phase is initiated, we might terminate all other sessions, adopt the complete CSN set and restart them only once the new CSN set has been fully established. Also, whenever we fall back from deltasync into plain syncrepl, we should make sure that the accesslog entries we generate from this are never used for further replication which might be thought to be a separate issue. Maybe the ITS#8486 work might be useful for this if we have a way of signalling to accesslog to reset minCSN accordingly to the new CSN set. The former is simpler, but the latter feels like the only one that actually addresses these problems in full. -- 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:Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 14 Oct '18

14 Oct '18

--Apple-Mail=_375D3C00-4B90-466D-8A3B-98B223B1B007 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Quanah, Run ' ldd /usr/local/bin/ldapsearch' in ubuntu client, result: linux-vdso.so.1 =3D> (0x00007ffd6a0f2000) libssl.so.1.0.0 =3D> /lib/x86_64-linux-gnu/libssl.so.1.0.0 = (0x00007f659a72a000) libcrypto.so.1.0.0 =3D> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 = (0x00007f659a2e6000) libresolv.so.2 =3D> /lib/x86_64-linux-gnu/libresolv.so.2 = (0x00007f659a0cb000) libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 = (0x00007f6599d01000) libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2 = (0x00007f6599afd000) /lib64/ld-linux-x86-64.so.2 (0x00007f659a993000) =20 Run ' ldd /usr/local/openldap.2.4.46/bin/ldapsearch' in Redhat, result: linux-vdso.so.1 =3D> (0x00007ffd959d6000) libsasl2.so.3 =3D> /lib64/libsasl2.so.3 (0x00007fae80012000) libssl.so.10 =3D> /lib64/libssl.so.10 (0x00007fae7fd9f000) libcrypto.so.10 =3D> /lib64/libcrypto.so.10 =20 Run ' ldd /usr/local/ssl/bin/openssl' in both, result : linux-vdso.so.1 =3D> (0x00007ffff61fb000) libssl.so.1.1 =3D> /usr/local/ssl/lib/libssl.so.1.1 = (0x00007f1ca0272000) libcrypto.so.1.1 =3D> /usr/local/ssl/lib/libcrypto.so.1.1 = (0x00007f1c9fd8e000) libz.so.1 =3D> /lib64/libz.so.1 (0x00007f1c9fb78000) libdl.so.2 =3D> /lib64/libdl.so.2 (0x00007f1c9f974000) libpthread.so.0 =3D> /lib64/libpthread.so.0 (0x00007f1c9f757000) libc.so.6 =3D> /lib64/libc.so.6 (0x00007f1c9f38a000) /lib64/ld-linux-x86-64.so.2 (0x00007f1ca0519000) =20 They are not use same libssl.so.1.1, when I changed the ubuntu /redhat = libssl.so link to the libssl.so.1.1 and libcrypto.so link to = libcrypto.so.1.1, and make the openldap.2.4.46 again, it will pop out an = error, =20 cc -g -O2 -o apitest apitest.o ./.libs/libldap.a = /home/openldap-soft/openldap-2.4.46/libraries/liblber/.libs/liblber.a = ../../libraries/liblber/.libs/liblber.a = ../../libraries/liblutil/liblutil.a -lsasl2 -lssl -lcrypto -lresolv ./.libs/libldap.a(os-ip.o): In function `ldap_pvt_is_socket_ready': /home/openldap-soft/openldap-2.4.46/libraries/libldap/os-ip.c:262: = warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' = instead /home/openldap-soft/openldap-2.4.46/libraries/libldap/os-ip.c:262: = warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' = instead ./.libs/libldap.a(tls_o.o): In function `tlso_session_chkhost': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:629: = undefined reference to `sk_num' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:633: = undefined reference to `sk_value' ./.libs/libldap.a(tls_o.o): In function `tlso_ctx_init': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:415: = undefined reference to `SSL_CTX_set_tmp_rsa_callback' ./.libs/libldap.a(tls_o.o): In function `tlso_ca_list': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:169: = undefined reference to `sk_new_null' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:174: = undefined reference to `sk_free' ./.libs/libldap.a(tls_o.o): In function `tlso_ctx_new': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:245: = undefined reference to `SSLv23_method' ./.libs/libldap.a(tls_o.o): In function `tlso_destroy': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:227: = undefined reference to `EVP_cleanup' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:233: = undefined reference to `ERR_free_strings' ./.libs/libldap.a(tls_o.o): In function `tlso_init': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:201: = undefined reference to `SSL_load_error_strings' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:202: = undefined reference to `SSL_library_init' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:203: = undefined reference to `OpenSSL_add_all_digests' ./.libs/libldap.a(tls_o.o): In function `tlso_ctx_ref': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:255: = undefined reference to `CRYPTO_add_lock' collect2: error: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory = `/home/openldap-soft/openldap-2.4.46/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory = `/home/openldap-soft/openldap-2.4.46/libraries' make: *** [all-common] Error 1 =20 And we found in openldap2.4.46 code in line 629 of = libraries/libldap/tls_o.c will call sk_GENERAL_NAME_num from openssl = code, we checked the openssl1.1.1 code, it does not have = sk_GENERAL_NAME_num, but it could be find in openssl1.0. Thanks a lot, best regards, nancy --Apple-Mail=_375D3C00-4B90-466D-8A3B-98B223B1B007 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial" class=""><div class=""><span style="font-family: Arial" class="">Hi</span><span style="font-family:"Microsoft YaHei"" class=""></span> Quanah<span style="font-family:"Microsoft YaHei"" class="">,<br class=""></span></div><div class=""><br class=""><span style="font-family:"Microsoft YaHei"" class=""></span></div><div style="margin: 0in;" class=""><span style="font-family:"Microsoft YaHei";font-size: 10.0pt;color:black" lang="en-US" class="">Run '</span><span style="font-family:Calibri; font-size:11.0pt" lang="zh-CN" class=""> ldd /usr/local/bin/ldapsearch</span><span style="font-family:"Microsoft YaHei";font-size:10.0pt;color:black" lang="en-US" class="">' in ubuntu client, result: </span></div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class="">linux-vdso.so.1 =><span style="mso-spacerun:yes" class="">  </span>(0x00007ffd6a0f2000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f659a72a000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f659a2e6000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f659a0cb000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6599d01000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6599afd000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>/lib64/ld-linux-x86-64.so.2 (0x00007f659a993000)</div><p style="margin:0in;font-family:Calibri;font-size:11.0pt" lang="zh-CN" class=""> </p><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class="">Run '</span><span lang="zh-CN" class=""> ldd /usr/local/openldap.2.4.46/bin/ldapsearch</span><span lang="en-US" class="">' in Redhat, result: </span></div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class=""><span style="mso-spacerun:yes" class="">        </span></span><span lang="zh-CN" class="">linux-vdso.so.1 =><span style="mso-spacerun:yes" class="">  </span>(0x00007ffd959d6000)</span></div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007fae80012000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libssl.so.10 => /lib64/libssl.so.10 (0x00007fae7fd9f000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class=""><span style="mso-spacerun:yes" class="">       </span></span><span lang="zh-CN" class=""><span style="mso-spacerun:yes" class=""> </span>libcrypto.so.10 => /lib64/libcrypto.so.10 </span></div><p style="margin:0in;font-family:Calibri;font-size:11.0pt" class=""> </p><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class="">Run '</span><span lang="zh-CN" class=""> ldd /usr/local/ssl/bin/openssl</span><span lang="en-US" class="">' in both, result :</span></div><div style="margin: 0in; font-size: 11pt;" class=""><span style="font-family:"Microsoft YaHei"" lang="en-US" class=""><span style="mso-spacerun:yes" class="">      </span></span><span style="font-family:Calibri" lang="zh-CN" class=""><span style="mso-spacerun:yes" class=""> </span>linux-vdso.so.1 =><span style="mso-spacerun:yes" class="">  </span>(0x00007ffff61fb000)</span></div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libssl.so.1.1 => /usr/local/ssl/lib/libssl.so.1.1 (0x00007f1ca0272000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libcrypto.so.1.1 => /usr/local/ssl/lib/libcrypto.so.1.1 (0x00007f1c9fd8e000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libz.so.1 => /lib64/libz.so.1 (0x00007f1c9fb78000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libdl.so.2 => /lib64/libdl.so.2 (0x00007f1c9f974000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1c9f757000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libc.so.6 => /lib64/libc.so.6 (0x00007f1c9f38a000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>/lib64/ld-linux-x86-64.so.2 (0x00007f1ca0519000)</div><p style="margin:0in;font-family:Calibri;font-size:11.0pt" class=""> </p><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class="">They are not use same </span><span lang="zh-CN" class=""><span style="mso-spacerun:yes" class=""> </span>libssl.so.1.1</span><span lang="en-US" class="">, when I changed the ubuntu /redhat libssl.so link to the libssl.so.1.1 and </span><span lang="zh-CN" class="">libcrypto.so</span><span lang="en-US" class=""> link to </span><span lang="zh-CN" class="">libcrypto.so.1.1</span><span lang="en-US" class="">, and make the openldap.2.4.46 again, it will pop out an error,</span></div><p style="margin:0in;font-family:Arial;font-size:11.0pt" class=""> </p><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">cc -g -O2 -o apitest apitest.o ./.libs/libldap.a /home/openldap-soft/openldap-2.4.46/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a ../../libraries/liblutil/liblutil.a -lsasl2 -lssl -lcrypto -lresolv</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(os-ip.o): In function `ldap_pvt_is_socket_ready':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/os-ip.c:262: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/os-ip.c:262: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_session_chkhost':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:629: undefined reference to `sk_num'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:633: undefined reference to `sk_value'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_ctx_init':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:415: undefined reference to `SSL_CTX_set_tmp_rsa_callback'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_ca_list':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:169: undefined reference to `sk_new_null'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:174: undefined reference to `sk_free'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_ctx_new':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:245: undefined reference to `SSLv23_method'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_destroy':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:227: undefined reference to `EVP_cleanup'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:233: undefined reference to `ERR_free_strings'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_init':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:201: undefined reference to `SSL_load_error_strings'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:202: undefined reference to `SSL_library_init'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:203: undefined reference to `OpenSSL_add_all_digests'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_ctx_ref':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:255: undefined reference to `CRYPTO_add_lock'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">collect2: error: ld returned 1 exit status</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make[2]: *** [apitest] Error 1</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make[2]: Leaving directory `/home/openldap-soft/openldap-2.4.46/libraries/libldap'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make[1]: *** [all-common] Error 1</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make[1]: Leaving directory `/home/openldap-soft/openldap-2.4.46/libraries'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make: *** [all-common] Error 1</div><p style="margin:0in;font-family:Calibri;font-size:11.0pt" class=""> </p><div style="margin: 0in;" class=""><span style="font-family:Calibri;font-size:11.0pt" lang="en-US" class="">And we found in openldap2.4.46 code in line 629 of<span style="mso-spacerun:yes" class="">  </span></span><span style="font-family:Calibri; font-size:11.0pt" lang="zh-CN" class="">libraries/libldap/tls_o.c</span><span style="font-family:Calibri;font-size:11.0pt" lang="en-US" class=""> will call<span style="mso-spacerun:yes" class="">  </span></span><span style="font-family:Arial; font-size:10.0pt" lang="en-US" class="">sk_GENERAL_NAME_num from openssl code, we checked the openssl1.1.1 code, it does not have sk_GENERAL_NAME_num, but it could be find in openssl1.0. </span></div> <br class=""><br class=""><div id="spnEditorSign" style="position:relative;zoom:1" class=""></div><div id="divNeteaseMailCard" class=""></div><div class=""><br class=""></div><div class="">Thanks a lot,</div><div class=""><br class=""></div><div class="">best regards,</div><div class="">nancy</div><div class=""><br class=""></div> </div></body></html> --Apple-Mail=_375D3C00-4B90-466D-8A3B-98B223B1B007--

1 0

Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 12 Oct '18

12 Oct '18

--On Friday, October 12, 2018 5:27 PM +0000 quanah(a)symas.com wrote: > So this should succeed, and yet it fails. Need to figure out why. I dug into this further with Ondrej, and the issue is that ppolicy was never updated to work correctly in a delta-sync MMR environment. ppolicy on the receiving server currently has logic to test if it is a shadow (i.e., replica) and if so, change its behavior. But there is no similar logic to handle the case if the receiving server is an MMR node (i.e., a shadow and a master). The following 3 changes to the code base for ppolicy would alleviate this issue and other potential issues: - test we're a replicated op, not just on shadow - issue MOD_REPLACE (concurrent binds could have cleared that attribute on the other servers) - expect MOD_REPLACE as well as MOD_DELETE on replicated ops --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#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 12 Oct '18

12 Oct '18

--On Friday, October 12, 2018 4:14 PM +0000 quanah(a)symas.com wrote: > --On Thursday, October 11, 2018 9:25 PM +0000 quanah(a)openldap.org wrote: > >> When the second action is performed (c), all consumers will go into >> REFRESH mode: > > There appears to be a serious bug in ppolicy. If I look at the accesslog > data that was written out, the "pwdFailureTime" attribute is cleared on > two different entries instead of just the user entry that had its > password reset. I.e., pwdFailureTime is cleared on the user AND the DN > of the manager entry that made the change. Ok, this was a red herring. The idmgmt user had a pwdFailure attribute set. I removed that, and still the underlying err=16 problem occurs, but the idmgmt user reset does not (which is correct now). The user entry on the other masters has the following set after the password failure: pwdFailureTime: 20181012161037.177876Z The MOD op recorded for it on the master accepting changes has: reqMod: userPassword:= {SSHA}He+QPQcFD+1/j9uGZl617/eP50B3/QKj reqMod: pwdChangedTime:= 20181012161047Z reqMod: pwdFailureTime:- reqMod: entryCSN:= 20181012161047.202928Z#000000#001#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqMod: modifyTimestamp:= 20181012161047Z So this should succeed, and yet it fails. Need to figure out why. --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#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 12 Oct '18

12 Oct '18

--On Thursday, October 11, 2018 9:25 PM +0000 quanah(a)openldap.org wrote: > When the second action is performed (c), all consumers will go into > REFRESH mode: There appears to be a serious bug in ppolicy. If I look at the accesslog data that was written out, the "pwdFailureTime" attribute is cleared on two different entries instead of just the user entry that had its password reset. I.e., pwdFailureTime is cleared on the user AND the DN of the manager entry that made the change. dn: reqStart=20181012145703.000000Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145703.000000Z reqEnd: 20181012145703.000001Z reqType: modify reqSession: 1003 reqAuthzID: cn=ldaproot,dc=example,dc=com reqDN: uid=user1,ou=user,dc=example,dc=com reqResult: 0 reqMod: pwdFailureTime:+ 20181012145703.125562Z reqMod: entryCSN:= 20181012145703.125803Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145703Z reqEntryUUID: ac657c60-e60a-412d-b015-522fc451e89a entryUUID: d2b4a16c-627a-1038-9d4c-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145703Z entryCSN: 20181012145703.125803Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145703Z dn: reqStart=20181012145706.000000Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145706.000000Z reqEnd: 20181012145706.000001Z reqType: modify reqSession: 1003 reqAuthzID: cn=ldaproot,dc=example,dc=com reqDN: cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqResult: 0 reqMod: pwdFailureTime:- reqMod: entryCSN:= 20181012145706.147871Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145706Z reqEntryUUID: bf72bf9a-6079-102b-83cd-8572a998cec3 entryUUID: d4822668-627a-1038-9d4d-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145706Z entryCSN: 20181012145706.147871Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145706Z dn: reqStart=20181012145706.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145706.000002Z reqEnd: 20181012145706.000003Z reqType: modify reqSession: 1003 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqDN: uid=user1,ou=user,dc=example,dc=com reqResult: 0 reqMod: userPassword:= {SSHA}y8UHEPuMnrOwrZnufP3XrG7ofbHKRpT0 reqMod: pwdChangedTime:= 20181012145706Z reqMod: pwdFailureTime:- reqMod: entryCSN:= 20181012145706.171028Z#000000#001#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145706Z reqEntryUUID: ac657c60-e60a-412d-b015-522fc451e89a entryUUID: d4845d20-627a-1038-9d4e-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145706Z entryCSN: 20181012145706.171028Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145706Z --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#8926) glue records + syncrepl
by frederic.goudal＠bordeaux-inp.fr 11 Oct '18

11 Oct '18

> Le 11 oct. 2018 =C3=A0 18:32, Howard Chu <hyc(a)symas.com> a =C3=A9crit = : >=20 > goudal(a)bordeaux-inp.fr wrote: >> Full_Name: Fr.d.ric Goudal >>=20 >> Solution=20 >> -remove by hand the dn: uid=3Dfoo,ou=3Dbar,dc=3Dmy,dc=3Ddomain, = that remove the >> glue object >> - create by hand the ou=3Dbar,dc=3Dmy,dc=3Ddomain >>=20 >> What IMHO slapd should do : >> - either check that it does not add an object before its parent = objects >=20 > No. This behavior is already documented in the Syncrepl specification. >=20 >> - either convert the glue object to the correct object when the real = creation is >> needed. >=20 > The slapd consumer already does this when running on a local database. = It would > require Manage privileges when running through back-ldap. Check your = back-ldap configuration. Well=E2=80=A6 I=E2=80=99v read 5 time the documentation on my setup, = never seen the manage privilege mentioned anywhere=E2=80=A6 Even in the example given for the backend configuration the acls don=E2=80= =99t mention this =C2=AB manage =C2=BB privilege : =46rom page : = https://www.openldap.org/doc/admin24/replication.html#Syncrepl # Give the replica DN unlimited read access. This ACL may need to be # merged with other ACL statements. access to * by dn.base=3D"cn=3Dreplicator,dc=3Dsuretecsystems,dc=3Dcom" = write by * break access to dn.base=3D"" by * read access to dn.base=3D"cn=3DSubschema" by * read access to dn.subtree=3D"cn=3DMonitor" by dn.exact=3D"uid=3Dadmin,dc=3Dsuretecsystems,dc=3Dcom" = write by users read by * none access to * by self write by * read Wel.. I can accept it=E2=80=99s a documentation bug=E2=80=A6but where is = the correct documentation ? f.g.

1 0

Re: (ITS#8926) glue records + syncrepl
by frederic.goudal＠bordeaux-inp.fr 11 Oct '18

11 Oct '18

> Le 11 oct. 2018 =C3=A0 18:32, Howard Chu <hyc(a)symas.com> a =C3=A9crit = : >=20 > goudal(a)bordeaux-inp.fr wrote: >> Full_Name: Fr.d.ric Goudal >>=20 >> Solution=20 >> -remove by hand the dn: uid=3Dfoo,ou=3Dbar,dc=3Dmy,dc=3Ddomain, = that remove the >> glue object >> - create by hand the ou=3Dbar,dc=3Dmy,dc=3Ddomain >>=20 >> What IMHO slapd should do : >> - either check that it does not add an object before its parent = objects >=20 > No. This behavior is already documented in the Syncrepl specification. >=20 >> - either convert the glue object to the correct object when the real = creation is >> needed. >=20 > The slapd consumer already does this when running on a local database. = It would > require Manage privileges when running through back-ldap. Check your = back-ldap configuration. Well=E2=80=A6 I=E2=80=99v read 5 time the documentation on my setup, = never seen the manage privilege mentioned anywhere=E2=80=A6 Even in the example given for the backend configuration the acls don=E2=80= =99t mention this =C2=AB manage =C2=BB privilege : =46rom page : = https://www.openldap.org/doc/admin24/replication.html#Syncrepl # Give the replica DN unlimited read access. This ACL may need to = be # merged with other ACL statements. access to * by dn.base=3D"cn=3Dreplicator,dc=3Dsuretecsystems,dc=3Dcom" = write by * break access to dn.base=3D"" by * read access to dn.base=3D"cn=3DSubschema" by * read access to dn.subtree=3D"cn=3DMonitor" by dn.exact=3D"uid=3Dadmin,dc=3Dsuretecsystems,dc=3Dcom" = write by users read by * none access to * by self write by * read Wel.. I can accept it=E2=80=99s a documentation bug=E2=80=A6but where is = the correct documentation ? f.g.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2018