openldap-bugs December 2017

openldap-bugs@openldap.org

15 participants
26 discussions

(ITS#8794) Fix implicit function declaration warnings
by jamegerwe＠fake-box.com 29 Dec '17

29 Dec '17

Full_Name: Jame Gerwe Version: 2.4.45 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.198.125.96) If openldap gets compiled with -DLDAP_CONNECTIONLESS, then /libraries/libldap/open.c: In function ldap_initialize: /libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url [-Wimplicit-function-declaration] if (ldap_is_ldapc_url(url)) ^~~~~~~~~~~~~~~~~ Independent of -DLDAP_CONNECTIONLESS we also have complaints about pthread_{set,get}concurrency(): /libraries/libldap_r/thr_posix.c: In function ldap_pvt_thread_set_concurrency: /libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency [-Wimplicit-function-declaration] return pthread_setconcurrency( n ); ^~~~~~~~~~~~~~~~~~~~~~ /libraries/libldap_r/thr_posix.c: In function ldap_pvt_thread_get_concurrency: /libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency [-Wimplicit-function-declaration] return pthread_getconcurrency(); ^~~~~~~~~~~~~~~~~~~~~~ Although thr_posix.c includes (indirectly) pthread.h, the home of these two functions, they are not declared in the _DEFAULT_SOURCE set of pthread.h (of glibc). To declare them use #define _GNU_SOURCE or similar prior to including pthread.h. Suggested patch for the first warning: Add ldap_is_ldapc_url() to ldap.h and include it by open.c: -------- [PATCH] Fix implicit-function-declaration in open.c If LDAP_CONNECTIONLESS is defined, then open.c uses 'ldap_is_ldapc_url()' which is defined in url.c but not part of any API (neither public nor private). Make the function part of the public API in ldap.h and include ldap.h in open.c. diff a/include/ldap.h b/include/ldap.h --- a/include/ldap.h +++ b/include/ldap.h @@ -2041,6 +2041,12 @@ LDAP_F( int ) ldap_is_ldapi_url LDAP_P(( LDAP_CONST char *url )); +#ifdef LDAP_CONNECTIONLESS +LDAP_F( int ) +ldap_is_ldapc_url LDAP_P(( + LDAP_CONST char *url )); +#endif + LDAP_F( int ) ldap_url_parse LDAP_P(( LDAP_CONST char *url, diff a/libraries/libldap/open.c b/libraries/libldap/open.c --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -33,6 +33,7 @@ #include <ac/unistd.h> #include "ldap-int.h" +#include "ldap.h" #include "ldap_log.h" /* Caller must hold the conn_mutex since simultaneous accesses are possible */

1 0

ITS#8793
by i＠maskray.me 16 Dec '17

16 Dec '17

> Wrong. > Closing this ITS. Sorry but can you re-visit this please? Suppose a MDB_IDL points to [5, 9,7,5,3,1] where the first element denotes the number of elements. [-inf, 1) => position 6; the first element less than or equal to 1 does not exist, thus it points outside of the list [1,3) => position 5 [3,5) => position 4 [5,7) => position 3 [7,9) => position 2 [9,inf) => position 1 Thanks!

1 0

Re: (ITS#8793) [PATCH] Fix comment in lmdb: greater -> less
by hyc＠symas.com 16 Dec '17

16 Dec '17

i(a)maskray.me wrote: > Full_Name: Fangrui Song > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/fangrui-song-171216.patch > Submission from: (NULL) (24.130.65.8) > > > ID Lists are in decreasing order and the search algorithms actually find the > first ID less than or equal to the argument. Wrong. Closing this ITS. -- -- 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#8793) [PATCH] Fix comment in lmdb: greater -> less
by i＠maskray.me 16 Dec '17

16 Dec '17

Full_Name: Fangrui Song Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/fangrui-song-171216.patch Submission from: (NULL) (24.130.65.8) ID Lists are in decreasing order and the search algorithms actually find the first ID less than or equal to the argument.

1 0

Re: (ITS#8759) mixed overlay nops & memberof cause segfault
by liuzx＠knownsec.com 15 Dec '17

15 Dec '17

IyBtb3JlIC9ldGMvb3BlbmxkYXAvc2xhcGQuY29uZg0KaW5jbHVkZSAgICAgICAgL2V0Yy9v cGVubGRhcC9zY2hlbWEvY29yZS5zY2hlbWENCmluY2x1ZGUgICAgICAgIC9ldGMvb3Blbmxk YXAvc2NoZW1hL2Nvc2luZS5zY2hlbWENCmluY2x1ZGUgICAgICAgIC9ldGMvb3BlbmxkYXAv c2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hDQppbmNsdWRlICAgICAgICAvZXRjL29wZW5s ZGFwL3NjaGVtYS9yZmMyMzA3YmlzLnNjaGVtYQ0KDQpwaWRmaWxlICAgICAgICAvcnVuL29w ZW5sZGFwL3NsYXBkLnBpZA0KYXJnc2ZpbGUgICAgICAgL3J1bi9vcGVubGRhcC9zbGFwZC5h cmdzDQoNCm1vZHVsZWxvYWQgICAgIG1lbWJlcm9mLnNvDQptb2R1bGVsb2FkICAgICBub3Bz LW92ZXJsYXkuc28NCg0KZGF0YWJhc2UgICAgICAgaGRiDQpzdWZmaXggICAgICAgICAibz1k ZW1vLGM9Y24iDQpyb290ZG4gICAgICAgICAiY249cm9vdCxvPWRlbW8sYz1jbiINCnJvb3Rw dyAgICAgICAgICIxMjM0NTYiDQpkaXJlY3RvcnkgICAgICAvdmFyL2xpYi9vcGVubGRhcC1k YXRhLw0KDQpvdmVybGF5IG1lbWJlcm9mDQptZW1iZXJvZi1ncm91cC1vYyBncm91cE9mTWVt YmVycw0KbWVtYmVyb2YtcmVmaW50ICAgdHJ1ZQ0KDQpvdmVybGF5IG5vcHMNCg0KIyBtb3Jl IC90bXAvMS5sZGlmDQpkbjogbz1kZW1vLGM9Y24NCm86IGRlbW8NCm9iamVjdENsYXNzOiBv cmdhbml6YXRpb24NCnN0cnVjdHVyYWxPYmplY3RDbGFzczogb3JnYW5pemF0aW9uDQoNCmRu OiBvdT1Hcm91cCxvPWRlbW8sYz1jbg0Kb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlvbmFsVW5p dA0Kb3U6IEdyb3VwDQoNCmRuOiBvdT1QZW9wbGUsbz1kZW1vLGM9Y24NCm9iamVjdENsYXNz OiBvcmdhbml6YXRpb25hbFVuaXQNCm91OiBQZW9wbGUNCg0KZG46IG91PUxlYXZlLG89ZGVt byxjPWNuDQpvYmplY3RDbGFzczogb3JnYW5pemF0aW9uYWxVbml0DQpvdTogTGVhdmUNCg0K ZG46IHVpZD1saXV6eCxvdT1QZW9wbGUsbz1kZW1vLGM9Y24NCmdpZE51bWJlcjogMjAwMDAN Cm9iamVjdENsYXNzOiBwb3NpeEFjY291bnQNCm9iamVjdENsYXNzOiBpbmV0T3JnUGVyc29u DQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IGluZXRPcmdQZXJzb24NCnVpZE51bWJlcjogMTAw MDANCnVpZDogbGl1engNCmhvbWVEaXJlY3Rvcnk6IC9ob21lL3VzZXJzL2xpdXp4DQpzbjog TGl1DQpjbjogWi4gTGl1DQptZW1iZXJPZjogY249dXNlcnMsb3U9R3JvdXAsbz1kZW1vLGM9 Y24NCm1vYmlsZTogMTM5MTA4MjM0NzUNCg0KZG46IGNuPXVzZXJzLG91PUdyb3VwLG89ZGVt byxjPWNuDQpvYmplY3RDbGFzczogZ3JvdXBPZk1lbWJlcnMNCmNuOiB1c2Vycw0KbWVtYmVy OiB1aWQ9bGl1engsb3U9UGVvcGxlLG89ZGVtbyxjPWNuDQoNCiMgc3VkbyAtdSBsZGFwIHNs YXBhZGQgLWwgMS5sZGlmDQojIHNlcnZpY2Ugc2xhcGQgc3RhcnQNCiMgcHMgfCBncmVwIHNs YXBkICMgY29uZmlybSBzbGFwZCBpcyBydW5uaW5nDQojIG1vcmUgfi90LmxkaWYNCmRuOiB1 aWQ9bGl1engsb3U9UGVvcGxlLG89ZGVtbyxjPWNuDQpjaGFuZ2V0eXBlOiBtb2Rkbg0KbmV3 cmRuOiB1aWQ9bGl1engNCmRlbGV0ZW9sZHJkbjogMQ0KbmV3c3VwZXJpb3I6IG91PUxlYXZl LG89ZGVtbyxjPWNuDQoNCiMgbGRhcG1vZGlmeSAtSCBsZGFwOi8vMTI3LjAuMC4xIC1EICdj bj1yb290LG89ZGVtbyxjPWNuJyAtdyAxMjM0NTYgIC1mIHQubGRpZg0KbW9kaWZ5aW5nIHJk biBvZiBlbnRyeSAidWlkPWxpdXp4LG91PVBlb3BsZSxvPWRlbW8sYz1jbiINCmxkYXBfcmVz dWx0OiBDYW4ndCBjb250YWN0IExEQVAgc2VydmVyICgtMSkNCg0KIyBwcyB8IGdyZXAgc2xh cGQgIyBjb25maXJtIHNsYXBkIGlzIGdvbmUNCg0Kc29tZXRpbWVzIGRtZXNnIGNhbiBzZWUg a2VybmVsIGxvZzoNCnRyYXBzOiBzbGFwZFsyNTU2MF0gZ2VuZXJhbCBwcm90ZWN0aW9uIGlw OjdmYWJmNjBiMGU3MiBzcDo3ZmFiZDk2OWJmZDAgZXJyb3I6MCBpbiBsaWJjLTIuMjMuc29b N2ZhYmY2MDY4MDAwKzE5ZjAwMF0NCnNsYXBkWzI2NDM3XTogc2VnZmF1bHQgYXQgNzM3MjY1 NjI2ZDgxIGlwIDAwMDAwMDAwMDA0YWE0ZDAgc3AgMDAwMDdmNjNjMmM3OTcxMCBlcnJvciA0 IGluIHNsYXBkWzQwMDAwMCsxNWEwMDBd

1 0

Re: (ITS#8791) OpenSSL 1.1.1 compat issue
by bbaetz＠google.com 14 Dec '17

14 Dec '17

--94eb2c05eb72af425f056056a2cc Content-Type: text/plain; charset="UTF-8" Done in ftp://ftp.openldap.org/incoming/bradley-baetz-20171215.patch On Fri, 15 Dec 2017 at 04:36 Howard Chu <hyc(a)symas.com> wrote: > bbaetz(a)google.com wrote: > > Full_Name: Bradley Baetz > > Version: 2.4.45 > > OS: linux > > URL: ftp://ftp.openldap.org/incoming/bradley-baetz-20171214.patch > > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) > > Thanks for the patch. The initialization of the static tlso_bio_method is > racy. One-time initializations should be done in tlso_init, and the > allocated > memory should be freed in tlso_destroy. > > > > > ITS#8533 added support for the OpenSSL's hiding of the bio_method_st > struct. > > > > However, it did this by re-defining the now-private structure, using the > OpenSSL > > 1.0 version. That will fail when OpenSSL changes their structure, which > they > > have already done for v1.1.1 - see > > > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=include/internal/bio… > > > > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUMBER > define, > > but has not yet hidden the struct definition. > > > > The attached file is derived from OpenLDAP Software. All of the > modifications to > > OpenLDAP Software represented in the following patch(es) were developed > by > > Google, LLC. Google, LLC has not assigned rights and/or interest in this > work to > > any party. I, Bradley Baetz am authorized by Google, LLC, my employer, to > > release this work under the following terms. > > > > The attached modifications to OpenLDAP Software are subject to the > following > > notice: > > Copyright 2017 Google, LLC. > > Redistribution and use in source and binary forms, with or without > modification, > > are permitted only as authorized by the OpenLDAP Public License. > > > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --94eb2c05eb72af425f056056a2cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Done in=C2=A0<a hre= f=3D"ftp://ftp.openldap.org/incoming/bradley-baetz-20171215.patch" style=3D= "font-size:small">ftp://ftp.openldap.org/incoming/bradley-baetz-20171215.pa= tch</a> </div> <d= iv class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 15 Dec 2017 at 04:36 Howa= rd Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:<br= ></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:bbaetz@google.com" = target=3D"_blank">bbaetz(a)google.com</a> wrote: > Full_Name: Bradley Baetz > Version: 2.4.45 > OS: linux > URL: <a href=3D"ftp://ftp.openldap.org/incoming/bradley-baetz-20171214= .patch" rel=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incomin= g/bradley-baetz-20171214.patch</a> > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) Thanks for the patch. The initialization of the static tlso_bio_method is<b= r> racy. One-time initializations should be done in tlso_init, and the allocat= ed memory should be freed in tlso_destroy. > > ITS#8533 added support for the OpenSSL's hiding of the bio_method_= st struct. > > However, it did this by re-defining the now-private structure, using t= he OpenSSL > 1.0 version. That will fail when OpenSSL changes their structure, whic= h they > have already done for v1.1.1 - see > <a href=3D"https://git.openssl.org/gitweb/?p=3Dopenssl.git;a=3Dblob;f= =3Dinclude/internal/bio.h;hb=3De1dd8fa00a1e06d27c8b024dac7657a8d8a9b451#l16= " rel=3D"noreferrer" target=3D"_blank">https://git.openssl.org/gitweb/?p=3D= openssl.git;a=3Dblob;f=3Dinclude/internal/bio.h;hb=3De1dd8fa00a1e06d27c8b02= 4dac7657a8d8a9b451#l16</a> > > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUM= BER define, > but has not yet hidden the struct definition. > > The attached file is derived from OpenLDAP Software. All of the modifi= cations to > OpenLDAP Software represented in the following patch(es) were develope= d by > Google, LLC. Google, LLC has not assigned rights and/or interest in th= is work to > any party. I, Bradley Baetz am authorized by Google, LLC, my employer,= to > release this work under the following terms. > > The attached modifications to OpenLDAP Software are subject to the fol= lowing > notice: > Copyright 2017 Google, LLC. > Redistribution and use in source and binary forms, with or without mod= ification, > are permitted only as authorized by the OpenLDAP Public License. > > -- =C2=A0 =C2=A0-- Howard Chu =C2=A0 =C2=A0CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a hr= ef=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www= .symas.com</a> =C2=A0 =C2=A0Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://hi= ghlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun= .com/hyc/</a> =C2=A0 =C2=A0Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap= .org/project/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org= /project/</a> </blockquote></div> --94eb2c05eb72af425f056056a2cc--

1 0

Re: (ITS#8791) OpenSSL 1.1.1 compat issue
by hyc＠symas.com 14 Dec '17

14 Dec '17

bbaetz(a)google.com wrote: > Full_Name: Bradley Baetz > Version: 2.4.45 > OS: linux > URL: ftp://ftp.openldap.org/incoming/bradley-baetz-20171214.patch > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) Thanks for the patch. The initialization of the static tlso_bio_method is racy. One-time initializations should be done in tlso_init, and the allocated memory should be freed in tlso_destroy. > > ITS#8533 added support for the OpenSSL's hiding of the bio_method_st struct. > > However, it did this by re-defining the now-private structure, using the OpenSSL > 1.0 version. That will fail when OpenSSL changes their structure, which they > have already done for v1.1.1 - see > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=include/internal/bio… > > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUMBER define, > but has not yet hidden the struct definition. > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Google, LLC. Google, LLC has not assigned rights and/or interest in this work to > any party. I, Bradley Baetz am authorized by Google, LLC, my employer, to > release this work under the following terms. > > The attached modifications to OpenLDAP Software are subject to the following > notice: > Copyright 2017 Google, LLC. > Redistribution and use in source and binary forms, with or without modification, > are permitted only as authorized by the OpenLDAP Public License. > > -- -- 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#8791) OpenSSL 1.1.1 compat issue
by bbaetz＠google.com 13 Dec '17

13 Dec '17

Full_Name: Bradley Baetz Version: 2.4.45 OS: linux URL: ftp://ftp.openldap.org/incoming/bradley-baetz-20171214.patch Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) ITS#8533 added support for the OpenSSL's hiding of the bio_method_st struct. However, it did this by re-defining the now-private structure, using the OpenSSL 1.0 version. That will fail when OpenSSL changes their structure, which they have already done for v1.1.1 - see https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=include/internal/bio… It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUMBER define, but has not yet hidden the struct definition. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Google, LLC. Google, LLC has not assigned rights and/or interest in this work to any party. I, Bradley Baetz am authorized by Google, LLC, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2017 Google, LLC. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#8790) N-Way MMR w/o serverID in at least one entry causes REFRESH
by quanah＠openldap.org 11 Dec '17

11 Dec '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) If one has configured N-WAY MMR in such a fashion that only one master ever gets the write ops (whether this is mirrormode or other methodologies), and there are zero entries in the database with an entryCSN of the other masters in the system, attempts to bring those other masters back up will result in a REFRESH phase on those masters, and potentially destabilize the entire cluster (See ITS#8789 for example). To avoid this, we should document that best practice involves having one object per master that is only ever modified by that master, so there is always a minimum of one object in the database with a CSN matching that master. This should avoid the REFRESH issue when bringing up a failed master.

1 0

(ITS#8789) syncrepl fallback can destabilize delta-sync MMR nodes
by quanah＠openldap.org 11 Dec '17

11 Dec '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) In a N-Way MMR setup, one node falling back to syncrepl REFRESH may destabilize other nodes, as it will incorrectly record changes it is receiving from the master that has write ops. If another node is using this master for its source, it will then be forced into fallback as well, further destabilizing the cluster. In the scenario above, triggered this via a 4-way MMR setup. serverID 1 master was the only master that had write ops. serverid 3 went into REFRESH for unknown reasons. serverid 2 was using serverid3 to pull in the changes for serverid 1, for unknown reasons. serverid 1 recorded the following change: dn: reqStart=20171206214129.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20171206214129.000002Z reqEnd: 20171206214129.000003Z reqType: modify reqSession: 2209 reqAuthzID: cn=ldaproot,dc=xxx,dc=edu reqDN: uid=cdxxxxx,ou=user,dc=xxx,dc=edu reqResult: 0 reqMod: pwdAccountLockedTime:= 20171206214129Z reqMod: pwdFailureTime:+ 20171206214129.121729Z reqMod: entryCSN:= 20171206214129.121794Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=xxx,dc=edu reqMod: modifyTimestamp:= 20171206214129Z reqEntryUUID: 41e02340-18f9-1027-900a-8ac8742d2008 entryUUID: f66c9be6-6f19-1037-9821-a35b555092e3 creatorsName: cn=accesslog createTimestamp: 20171206214129Z entryCSN: 20171206214129.121794Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20171206214129Z However, serverID 3 records the following for this same CSN instead: dn: reqStart=20171206214354.000006Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20171206214354.000006Z reqEnd: 20171206214354.000008Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=xxx,dc=edu reqDN: uid=cdxxxxx,ou=user,dc=xxx,dc=edu reqResult: 0 reqMod: userPassword:- reqMod: pwdFailureTime:+ 20171206214105.339881Z reqMod: pwdFailureTime:+ 20171206214105.504629Z reqMod: pwdFailureTime:+ 20171206214105.756105Z reqMod: pwdFailureTime:+ 20171206214106.117063Z reqMod: pwdFailureTime:+ 20171206214106.348441Z reqMod: pwdFailureTime:+ 20171206214106.575907Z reqMod: pwdFailureTime:+ 20171206214106.875082Z reqMod: pwdFailureTime:+ 20171206214107.175699Z reqMod: pwdFailureTime:+ 20171206214107.655344Z reqMod: pwdFailureTime:+ 20171206214107.915930Z reqMod: pwdFailureTime:+ 20171206214108.156601Z reqMod: pwdFailureTime:+ 20171206214108.431242Z reqMod: pwdFailureTime:+ 20171206214108.791469Z reqMod: pwdFailureTime:+ 20171206214109.033924Z reqMod: pwdFailureTime:+ 20171206214109.318285Z reqMod: pwdFailureTime:+ 20171206214109.565585Z reqMod: pwdFailureTime:+ 20171206214109.823744Z reqMod: pwdFailureTime:+ 20171206214110.110372Z reqMod: pwdFailureTime:+ 20171206214110.306955Z reqMod: pwdFailureTime:+ 20171206214110.638527Z reqMod: pwdFailureTime:+ 20171206214111.014705Z reqMod: pwdFailureTime:+ 20171206214111.370965Z reqMod: pwdFailureTime:+ 20171206214111.673694Z reqMod: pwdFailureTime:+ 20171206214112.011806Z reqMod: pwdFailureTime:+ 20171206214112.327727Z reqMod: pwdFailureTime:+ 20171206214112.584305Z reqMod: pwdFailureTime:+ 20171206214112.930555Z reqMod: pwdFailureTime:+ 20171206214113.269235Z reqMod: pwdFailureTime:+ 20171206214113.633844Z reqMod: pwdFailureTime:+ 20171206214113.928111Z reqMod: pwdFailureTime:+ 20171206214114.217342Z reqMod: pwdFailureTime:+ 20171206214114.539026Z reqMod: pwdFailureTime:+ 20171206214114.888149Z reqMod: pwdFailureTime:+ 20171206214115.262042Z reqMod: pwdFailureTime:+ 20171206214115.675217Z reqMod: pwdFailureTime:+ 20171206214116.030024Z reqMod: pwdFailureTime:+ 20171206214116.362739Z reqMod: pwdFailureTime:+ 20171206214116.616784Z reqMod: pwdFailureTime:+ 20171206214116.987779Z reqMod: pwdFailureTime:+ 20171206214117.293091Z reqMod: pwdFailureTime:+ 20171206214117.549392Z reqMod: pwdFailureTime:+ 20171206214117.838969Z reqMod: pwdFailureTime:+ 20171206214118.051355Z reqMod: pwdFailureTime:+ 20171206214118.275629Z reqMod: pwdFailureTime:+ 20171206214118.583510Z reqMod: pwdFailureTime:+ 20171206214118.866746Z reqMod: pwdFailureTime:+ 20171206214119.174928Z reqMod: pwdFailureTime:+ 20171206214119.483218Z reqMod: pwdFailureTime:+ 20171206214119.929568Z reqMod: pwdFailureTime:+ 20171206214120.147090Z reqMod: pwdFailureTime:+ 20171206214120.549317Z reqMod: pwdFailureTime:+ 20171206214120.869798Z reqMod: pwdFailureTime:+ 20171206214121.143126Z reqMod: pwdFailureTime:+ 20171206214121.476740Z reqMod: pwdFailureTime:+ 20171206214121.799935Z reqMod: pwdFailureTime:+ 20171206214122.066816Z reqMod: pwdFailureTime:+ 20171206214122.405710Z reqMod: pwdFailureTime:+ 20171206214122.761880Z reqMod: pwdFailureTime:+ 20171206214123.032806Z reqMod: pwdFailureTime:+ 20171206214123.280540Z reqMod: pwdFailureTime:+ 20171206214123.748973Z reqMod: pwdFailureTime:+ 20171206214124.085579Z reqMod: pwdFailureTime:+ 20171206214124.340470Z reqMod: pwdFailureTime:+ 20171206214124.638673Z reqMod: pwdFailureTime:+ 20171206214124.970374Z reqMod: pwdFailureTime:+ 20171206214125.302162Z reqMod: pwdFailureTime:+ 20171206214125.630451Z reqMod: pwdFailureTime:+ 20171206214125.921736Z reqMod: pwdFailureTime:+ 20171206214126.232407Z reqMod: pwdFailureTime:+ 20171206214126.564006Z reqMod: pwdFailureTime:+ 20171206214126.816303Z reqMod: pwdFailureTime:+ 20171206214127.168459Z reqMod: pwdFailureTime:+ 20171206214127.481267Z reqMod: pwdFailureTime:+ 20171206214127.779584Z reqMod: pwdFailureTime:+ 20171206214128.176611Z reqMod: pwdFailureTime:+ 20171206214128.429982Z reqMod: pwdFailureTime:+ 20171206214128.852280Z reqMod: pwdFailureTime:+ 20171206214129.121729Z reqMod: pwdAccountLockedTime:= 20171206214129Z reqMod: entryCSN:= 20171206214129.121794Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=xxx,dc=edu reqMod: modifyTimestamp:= 20171206214129Z reqMod: pwdFailureTime:- reqEntryUUID: 41e02340-18f9-1027-900a-8ac8742d2008 entryCSN: 20171206214129.121794Z#000000#001#000000 entryUUID: 4d10f56e-6f1a-1037-9a98-f5e2e6dad8c2 creatorsName: cn=accesslog createTimestamp: 20171206214129Z modifiersName: cn=accesslog modifyTimestamp: 20171206214129Z serverID2 is then unable to process the change for this CSN provided by serverID3, and goes into refresh mode.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2017