openldap-bugs September 2019

openldap-bugs@openldap.org

24 participants
50 discussions

Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by ondra＠mistotebe.net 30 Sep '19

30 Sep '19

On Mon, Sep 23, 2019 at 09:22:45AM +0000, jrajalakshmi(a)juniper.net wrote: > (1) What problem/issue/behavior are you having trouble with? What do you expect > to see? > Using OpenLDAP version 2.4.44 we are not seeing Concurrency whereas in OpenLDAP > Version 2.4.23 we are seeing Concurrent LDAP Requests. > In our product OpenLDAP 2.4.23 was previously used and the concurrent request > for search using the API ' ldap_search_ext_s() ' was working as expected and our > product scalability was better. > We have recently upgraded LDAP to OpenLDAP 2.4.44. But with this version, the > api 'ldap_search_ext_s()' does not seem to work as expected, i.e concurrent > requests handling is not happening. Hi, if you want the project to investigate this, it would be useful if you provide a sample program that exhibits this behaviour with a vanilla build of 2.4.48 and doesn't exhibit that with an analogous build of 2.4.23. I would like to point out that since 2.4.23 is a very old release, it is also possible you have been relying on undocumented behaviour or a libldap_r bug that has since been fixed. That is what a sample program would also help to rule out. 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#9090) memory leak: ldap_unbind_* functions don't free 'ld_sb' field of LDAP structure
by ondra＠mistotebe.net 30 Sep '19

30 Sep '19

On Mon, Sep 30, 2019 at 11:04:08AM +0000, santucco(a)mail.ru wrote: > 3. Run the test, analyze AddressSanitizer output: > ================================================================= > ==29038==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 40 byte(s) in 1 object(s) allocated from: > #0 0x7f9d35ac23a8 in __interceptor_calloc > ../../../../libsanitizer/asan/asan_malloc_linux.cc:70 > #1 0x55d793627512 in ber_memcalloc_x (/tmp/test+0x67512) > #2 0x55d79362757b in ber_memcalloc (/tmp/test+0x6757b) > #3 0x55d793628a2d in ber_sockbuf_alloc (/tmp/test+0x68a2d) > #4 0x55d7935ee453 in ldap_create (/tmp/test+0x2e453) > #5 0x55d7935ee628 in ldap_initialize (/tmp/test+0x2e628) > #6 0x55d7935ede8e in main /tmp/test.c:14 > #7 0x7f9d3442c3d4 in __libc_start_main (/lib64/libc.so.6+0x223d4) > > 4. Possible patch: > > --- openldap/libraries/libldap/unbind.c.orig 2019-07-23 17:46:22.000000000 > +0300 > +++ openldap/libraries/libldap/unbind.c 2019-09-27 15:39:40.000000000 +0300 > @@ -134,6 +134,8 @@ > /* Should already be closed by ldap_free_connection which knows not to free > * this one */ > ber_int_sb_destroy( ld->ld_sb ); > + /* free memory to avoid of leak */ > + ber_memfree( ld->ld_sb ); > > LDAP_MUTEX_LOCK( &ld->ld_ldopts_mutex ); Dear Alexander, this looks like a duplicate of ITS#9081, fixed with commit 639e5f15fdeaf46941ec6da5c5d5f7ef707a976c. 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

(ITS#9090) memory leak: ldap_unbind_* functions don't free 'ld_sb' field of LDAP structure
by santucco＠mail.ru 30 Sep '19

30 Sep '19

Full_Name: Alexander Sychev Version: 2.4.48 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.103.66.207) Steps to reproduce: 1. Write a test: #include <ldap.h> int main() { LDAP* h = NULL; LDAPURLDesc u; memset(&u, 0, sizeof(LDAPURLDesc)); char* s = 0; u.lud_scheme = "ldap"; u.lud_host = "locahost"; u.lud_port = 8080; u.lud_scope = LDAP_SCOPE_DEFAULT ; s = ldap_url_desc2str(&u); ldap_initialize(&h, s); ldap_memfree(s); ldap_unbind_ext_s(h, NULL, NULL); return 0; } 2. Compile it with AddressSanitizer support: gcc test.c -g -fsanitize=address 3. Run the test, analyze AddressSanitizer output: ================================================================= ==29038==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f9d35ac23a8 in __interceptor_calloc ../../../../libsanitizer/asan/asan_malloc_linux.cc:70 #1 0x55d793627512 in ber_memcalloc_x (/tmp/test+0x67512) #2 0x55d79362757b in ber_memcalloc (/tmp/test+0x6757b) #3 0x55d793628a2d in ber_sockbuf_alloc (/tmp/test+0x68a2d) #4 0x55d7935ee453 in ldap_create (/tmp/test+0x2e453) #5 0x55d7935ee628 in ldap_initialize (/tmp/test+0x2e628) #6 0x55d7935ede8e in main /tmp/test.c:14 #7 0x7f9d3442c3d4 in __libc_start_main (/lib64/libc.so.6+0x223d4) SUMMARY: AddressSanitizer: 40 byte(s) leaked in 1 allocation(s). ================================================================= 4. Possible patch: --- openldap/libraries/libldap/unbind.c.orig 2019-07-23 17:46:22.000000000 +0300 +++ openldap/libraries/libldap/unbind.c 2019-09-27 15:39:40.000000000 +0300 @@ -134,6 +134,8 @@ /* Should already be closed by ldap_free_connection which knows not to free * this one */ ber_int_sb_destroy( ld->ld_sb ); + /* free memory to avoid of leak */ + ber_memfree( ld->ld_sb ); LDAP_MUTEX_LOCK( &ld->ld_ldopts_mutex );

1 0

Re: (ITS#8996) Please supply a pkg-config file for libldap
by hugh.mcmaster＠outlook.com 29 Sep '19

29 Sep '19

Dear OpenLDAP developers, I've rebased the above patches on the current master branch (as of 29 September) and replaced them on the FTP server. I'm hoping someone can review them as development begins on the 2.5 branch. Thank you, Hugh

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by quanah＠symas.com 27 Sep '19

27 Sep '19

--On Friday, September 27, 2019 10:50 AM +0000 Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net> wrote: > > > Hi Quanah, > > Can we have a solution for the issue reported at the earliest. Since we > have a release and the fix needs to be done. Hello Raji, If you need an immediate fix to an issue, you may wish to contact one of the companies that offers such services via the support page: <https://www.openldap.org/support/> The project itself cannot commit to when it will or will not have a specific issue resolved. 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#9088) Concurrency not seen in OpenLDAP 2.4.44
by jrajalakshmi＠juniper.net 27 Sep '19

27 Sep '19

--_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Quanah, Can we have a solution for the issue reported at the earliest. Since we hav= e a release and the fix needs to be done. Thanks, Raji -----Original Message----- From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Thursday, September 26, 2019 8:23 PM To: Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net>; openldap-its@OpenLDAP= .org Cc: Muthaiyan Vel <mvel(a)juniper.net> Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 --On Thursday, September 26, 2019 3:11 PM +0000 Rajalakshmi Jayaraman <jraj= alakshmi(a)juniper.net<mailto:jrajalakshmi@juniper.net>> wrote: > > > Hi, > > The FTP > "https://urldefense.com/v3/__ftp://ftp.openldap.org/incoming/__;!8WoA6 > RjC81c!WuKVskHw8TTh7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4ryH > U5-Z3$ " is not working. Hence pasted the pcap details, hope this > helps It's working just fine: quanah@ub18:~$ ftp ftp.openldap.org<ftp://ftp.openldap.org> Connected to www.openldap.org<http://www.openldap.org>. 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] Name (ftp.openldap.= org:quanah<ftp://ftp.openldap.org:quanah>): ftp 331 Anonymous login ok, send your complete email address as your password Password: 230 Anonymous access granted, restrictions apply Remote system type is UNIX= . Using binary mode to transfer files. ftp> pass Passive mode on. ftp> cd incoming 250 CWD command successful ftp> mkdir its9088 257 "/incoming/its9088" - Directory successfully created ftp> cd its9088 250 CWD command successful ftp> lcd /tmp Local directory now /tmp ftp> put blah local: blah remote: blah 227 Entering Passive Mode (23,92,27,230,156,55). 150 Opening BINARY mode data connection for blah 226 Transfer complete ftp> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <https://urldefense.com/v3/__http://www.symas.com__;!8WoA6RjC81c!WuKVskHw8T= Th7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4r6bEJRvo$ <https://urldef= ense.com/v3/__http:/www.symas.com__;!8WoA6RjC81c!WuKVskHw8TTh7xPBLQCayeOo0j= LoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4r6bEJRvo$%20> > Juniper Business Use Only --_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi Quanah,<o:p></o:p> Can we have a solution for the issue reported at = the earliest. Since we have a release and the fix needs to be done. <o:p></o:p> <o:p> </o:p> Thanks, Raji<o:p></o:p> <o:p> </o:p> -----Original Message----- From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Thursday, September 26, 2019 8:23 PM To: Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net>et>; openldap-its@Op= enLDAP.org Cc: Muthaiyan Vel <mvel(a)juniper.net> Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44<o:p></o:p><= /p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> --On Thursday, September 26, 2019 3:11 PM +00= 00 Rajalakshmi Jayaraman <<a href=3D"mailto:jrajalakshmi@juniper.net"><s= pan style=3D"color:windowtext;text-decoration:none">jrajalakshmi(a)juniper.ne= t</a>> wrote:<o:p></o:p> <o:p> </o:p> ><o:p> </o:p> ><o:p> </o:p> > Hi,<o:p></o:p> ><o:p> </o:p> > The FTP <o:p></o:p> > "https://urldefense.com/v3/__ftp://ftp.= openldap.org/incoming/__;!8WoA6<o:p></o:p> > RjC81c!WuKVskHw8TTh7xPBLQCayeOo0jLoA3scmo73f= pEyBwOwyP2lAUVT_sk-67s4ryH<o:p></o:p> > U5-Z3$ " is not working. Hence pasted t= he pcap details, hope this <o:p></o:p> > helps<o:p></o:p> <o:p> </o:p> It's working just fine:<o:p></o:p> <o:p> </o:p> quanah@ub18:~$ ftp <a href=3D"ftp://ftp.openldap.= org">ftp.openldap.org= </a><o:p></o:p> Connected to <a href=3D"http://www.openldap.org">= www.openldap.org</spa= n></a>.<o:p></o:p> 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.2= 7.230] Name (<a href=3D"ftp://ftp.openldap.org:quanah">ftp.openldap.org:quanah</a>): ftp<= o:p></o:p> 331 Anonymous login ok, send your complete email = address as your password<o:p></o:p> Password:<o:p></o:p> 230 Anonymous access granted, restrictions apply = Remote system type is UNIX.<o:p></o:p> Using binary mode to transfer files.<o:p></o:p></= p> ftp> pass<o:p></o:p> Passive mode on.<o:p></o:p> ftp> cd incoming<o:p></o:p> 250 CWD command successful<o:p></o:p> ftp> mkdir its9088<o:p></o:p> 257 "/incoming/its9088" - Directory suc= cessfully created<o:p></o:p> ftp> cd its9088<o:p></o:p> 250 CWD command successful<o:p></o:p> ftp> lcd /tmp<o:p></o:p> Local directory now /tmp<o:p></o:p> ftp> put blah<o:p></o:p> local: blah remote: blah<o:p></o:p> 227 Entering Passive Mode (23,92,27,230,156,55).<= o:p></o:p> 150 Opening BINARY mode data connection for blah<= o:p></o:p> 226 Transfer complete<o:p></o:p> ftp><o:p></o:p> <o:p> </o:p> <o:p> </o:p> --<o:p></o:p> <o:p> </o:p> Quanah Gibson-Mount<o:p></o:p> Product Architect<o:p></o:p> Symas Corporation<o:p></o:p> Packaged, certified, and supported LDAP solutions= powered by OpenLDAP:<o:p></o:p> <<a href=3D"https://urldefense.com/v3/__http:/= www.symas.com__;!8WoA6RjC81c!WuKVskHw8TTh7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP= 2lAUVT_sk-67s4r6bEJRvo$%20">https://urldefense.com/v3/__http://www.symas.com__;!8WoA6RjC81c!WuKV= skHw8TTh7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4r6bEJRvo$ </a>><o:p></o:p> <o:p> </o:p> Juniper Business Use Only</span= ><o:p></o:p> </div> </body> </html> --_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_--

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by quanah＠symas.com 26 Sep '19

26 Sep '19

--On Thursday, September 26, 2019 3:11 PM +0000 Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net> wrote: > > > Hi, > > The FTP "ftp://ftp.openldap.org/incoming/" is not working. Hence pasted > the pcap details, hope this helps It's working just fine: quanah@ub18:~$ ftp ftp.openldap.org Connected to www.openldap.org. 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] Name (ftp.openldap.org:quanah): ftp 331 Anonymous login ok, send your complete email address as your password Password: 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> pass Passive mode on. ftp> cd incoming 250 CWD command successful ftp> mkdir its9088 257 "/incoming/its9088" - Directory successfully created ftp> cd its9088 250 CWD command successful ftp> lcd /tmp Local directory now /tmp ftp> put blah local: blah remote: blah 227 Entering Passive Mode (23,92,27,230,156,55). 150 Opening BINARY mode data connection for blah 226 Transfer complete ftp> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by jrajalakshmi＠juniper.net 26 Sep '19

26 Sep '19

--_000_CH2PR05MB69514726BCB360A68DA761D2DF860CH2PR05MB6951namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The FTP "ftp://ftp.openldap.org/incoming/" is not working. Hence pasted the= pcap details, hope this helps As you can see, 9 requests from a single AAA server to LDAP server were ini= tiated at the same time (concurrent request). But from the LDAP, our unders= tanding is the 'searchRequest' is sequential..after every 'searchRequest' t= here is "searchResDone" before handling the subsequent request "searchReque= st' No Time Source Destination Protocol Length = Info 1 0.000000000 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D2, l=3D71) 2 0.000359909 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D7, l=3D71) 3 0.000512919 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D8, l=3D71) 4 0.001219680 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D9, l=3D71) 5 0.001228416 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D10, l=3D71) 6 0.001359636 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D11, l=3D71) 7 0.002419581 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D5, l=3D71) 8 0.002432108 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D6, l=3D71) 9 0.002435112 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D4, l=3D71) 10 0.002511929 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(52) "dc=3Dexample,dc=3Dcom" wholeSubtree 11 0.002637421 10.212.10.218 10.212.10.120 RADIUS 115 Access= -Request(1) (id=3D3, l=3D71) 12 0.004109740 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(52) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 13 0.004146613 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(52) success [2 results] 14 0.004348866 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(55) "dc=3Dexample,dc=3Dcom" wholeSubtree 15 0.004781891 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D7, l=3D76) 16 0.004952000 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(55) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 17 0.004962643 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(55) success [0 results] 18 0.005087014 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(57) "dc=3Dexample,dc=3Dcom" wholeSubtree 19 0.005153658 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D8, l=3D76) 20 0.005698130 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(57) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 21 0.005723767 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(57) success [1 result] 22 0.005915500 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D5, l=3D76) 23 0.006033219 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(59) "dc=3Dexample,dc=3Dcom" wholeSubtree 24 0.006566138 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(59) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 25 0.006578873 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(59) success [1 result] 26 0.006740243 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D6, l=3D76) 27 0.006831740 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(61) "dc=3Dexample,dc=3Dcom" wholeSubtree 28 0.007507468 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(61) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 29 0.007519658 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(61) success [1 result] 30 0.007650375 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(53) "dc=3Dexample,dc=3Dcom" wholeSubtree 31 0.007733127 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D4, l=3D76) 32 0.008406756 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(53) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 33 0.008418925 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(53) success [1 result] 34 0.008554053 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(54) "dc=3Dexample,dc=3Dcom" wholeSubtree 35 0.008629869 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D10, l=3D76) 36 0.008978083 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(54) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 37 0.008988019 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(54) success [1 result] 38 0.009107220 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(60) "dc=3Dexample,dc=3Dcom" wholeSubtree 39 0.009172870 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D9, l=3D76) 40 0.009654133 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(60) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 41 0.009667685 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(60) success [1 result] 42 0.009783997 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(56) "dc=3Dexample,dc=3Dcom" wholeSubtree 43 0.009882004 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D3, l=3D76) 44 0.010270458 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(56) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 45 0.010280926 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(56) success [1 result] 46 0.010400940 10.212.10.120 10.212.10.220 LDAP 124 searchReq= uest(58) "dc=3Dexample,dc=3Dcom" wholeSubtree 47 0.010474219 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D2, l=3D76) 48 0.010881808 10.212.10.220 10.212.10.120 LDAP 378 searchRes= Entry(58) "cn=3Dtest,dc=3Dexample,dc=3Dcom" 49 0.010891960 10.212.10.220 10.212.10.120 LDAP 82 searchResD= one(58) success [1 result] 50 0.011050696 10.212.10.120 10.212.10.218 RADIUS 120 Access= -Accept(2) (id=3D11, l=3D76) Thanks, Raji -----Original Message----- From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Thursday, September 26, 2019 6:52 PM To: Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net>; openldap-its@OpenLDAP= .org Cc: Muthaiyan Vel <mvel(a)juniper.net> Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 --On Thursday, September 26, 2019 2:19 PM +0000 Rajalakshmi Jayaraman <jraj= alakshmi(a)juniper.net<mailto:jrajalakshmi@juniper.net>> wrote: > > > Hi, > > Thanks for sharing the inputs. We have tried with the unmodified > release of OpenLDAP that was suggested. From the pcap, we have noticed > the LDAP search requests are sequential. (pl. find attached the pcap) > for reference Please put your pcap file on the FTP server rather than sending it via the = ITS system. Then respond to the ITS with a link to the file. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <https://urldefense.com/v3/__http://www.symas.com__;!8WoA6RjC81c!R398Hvv4fW= btEY6cojq9Y7NDCOui0Wmtxg3ZIwwbs-vEdcC_Ir4Odx8wrsWJSPM5qmj9$ <https://urldef= ense.com/v3/__http:/www.symas.com__;!8WoA6RjC81c!R398Hvv4fWbtEY6cojq9Y7NDCO= ui0Wmtxg3ZIwwbs-vEdcC_Ir4Odx8wrsWJSPM5qmj9$%20> > Juniper Business Use Only --_000_CH2PR05MB69514726BCB360A68DA761D2DF860CH2PR05MB6951namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi,<o:p></o:p> The FTP "<a href=3D"ftp://ftp.openldap.org/i= ncoming/">ftp://ftp.openldap.org/incoming/</a>" is not working. Hence = pasted the pcap details, hope this helps <o:p></o:p> As you can see, 9 requests from a single AAA serv= er to LDAP server were initiated at the same time (concurrent request). But= from the LDAP, our understanding is the ‘searchRequest’ is sequential..after every ‘searchReq= uest’ there is “searchResDone” before handling the subsequent requ= est “searchReques= t’<o:p></o:p> <o:p> </o:p> No   Time       Source &= nbsp;        Destination  &nbs= p;  Protocol        Length &nb= sp;        Info<o:p></o:p> 1    0.000000000     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D2, l=3D71)<o:p></o:p> 2    0.000359909     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D7, l=3D71)<o:p></o:p> 3    0.000512919     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D8, l=3D71)<o:p></o:p> 4    0.001219680     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D9, l=3D71)<o:p></o:p> 5    0.001228416     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D10, l=3D71)<o:p></o:p> 6    0.001359636     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D11, l=3D71)<o:p></o:p> 7    0.002419581     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D5, l=3D71)<o:p></o:p> 8    0.002432108     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D6, l=3D71)<o:p></o:p> 9    0.002435112     10.212.10.218&nb= sp;  10.212.10.120   RADIUS     115&nbsp= ; Access-Request(1) (id=3D4, l=3D71)<o:p></o:p> 10   0.002511929     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(52) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 11   0.002637421     10.212.10.218 &n= bsp; 10.212.10.120   RADIUS     115  Acc= ess-Request(1) (id=3D3, l=3D71)<o:p></o:p> 12   0.004109740     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(52) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 13   0.004146613     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(52) success  [2 results]<o:p></o:p> 14   0.004348866     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(55) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 15   0.004781891     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D7, l=3D76)<o:p></o:p> 16   0.004952000     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(55) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 17   0.004962643     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(55) success  [0 results]<o:p></o:p> 18   0.005087014     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(57) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 19   0.005153658     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D8, l=3D76)<o:p></o:p> 20   0.005698130     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(57) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 21   0.005723767     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(57) success  [1 result]<o:p></o:p> 22   0.005915500     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D5, l=3D76)<o:p></o:p> 23   0.006033219     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(59) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 24   0.006566138     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(59) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 25   0.006578873     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(59) success  [1 result]<o:p></o:p> 26   0.006740243     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D6, l=3D76)<o:p></o:p> 27   0.006831740     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(61) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 28   0.007507468     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(61) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 29   0.007519658     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(61) success  [1 result]<o:p></o:p> 30   0.007650375     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(53) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 31   0.007733127     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D4, l=3D76)<o:p></o:p> 32   0.008406756     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(53) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 33   0.008418925     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(53) success  [1 result]<o:p></o:p> 34   0.008554053     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(54) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 35   0.008629869     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D10, l=3D76)<o:p></o:p> 36   0.008978083     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(54) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 37   0.008988019     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(54) success  [1 result]<o:p></o:p> 38   0.009107220     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(60) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 39   0.009172870     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D9, l=3D76)<o:p></o:p> 40   0.009654133     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(60) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 41   0.009667685     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(60) success  [1 result]<o:p></o:p> 42   0.009783997     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(56) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 43   0.009882004     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D3, l=3D76)<o:p></o:p> 44   0.010270458     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(56) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 45   0.010280926     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(56) success  [1 result]<o:p></o:p> 46   0.010400940     10.212.10.120 &n= bsp; 10.212.10.220   LDAP 124     searchReque= st(58) "dc=3Dexample,dc=3Dcom" wholeSubtree <o:p></o:p> 47   0.010474219     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D2, l=3D76)<o:p></o:p> 48   0.010881808     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 378     searchResEn= try(58) "cn=3Dtest,dc=3Dexample,dc=3Dcom" <o:p></o:p> 49   0.010891960     10.212.10.220 &n= bsp; 10.212.10.120   LDAP 82     searchResDon= e(58) success  [1 result]<o:p></o:p> 50   0.011050696     10.212.10.120 &n= bsp; 10.212.10.218   RADIUS     120  Acc= ess-Accept(2) (id=3D11, l=3D76)<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Thanks,<o:p></o:p> Raji<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> -----Original Message----- From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Thursday, September 26, 2019 6:52 PM To: Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net>et>; openldap-its@Op= enLDAP.org Cc: Muthaiyan Vel <mvel(a)juniper.net> Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44<o:p></o:p><= /p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> --On Thursday, September 26, 2019 2:19 PM +00= 00 Rajalakshmi Jayaraman <<a href=3D"mailto:jrajalakshmi@juniper.net"><s= pan style=3D"color:windowtext;text-decoration:none">jrajalakshmi(a)juniper.ne= t</a>> wrote:<o:p></o:p> <o:p> </o:p> ><o:p> </o:p> ><o:p> </o:p> > Hi,<o:p></o:p> ><o:p> </o:p> > Thanks for sharing the inputs. We have tried= with the unmodified <o:p></o:p> > release of OpenLDAP that was suggested. From= the pcap, we have noticed <o:p></o:p> > the LDAP search requests are sequential. (pl= . find attached the pcap) <o:p></o:p> > for reference<o:p></o:p> <o:p> </o:p> Please put your pcap file on the FTP server rathe= r than sending it via the ITS system.  Then respond to the ITS with a = link to the file.<o:p></o:p> <o:p> </o:p> --Quanah<o:p></o:p> <o:p> </o:p> --<o:p></o:p> <o:p> </o:p> Quanah Gibson-Mount<o:p></o:p> Product Architect<o:p></o:p> Symas Corporation<o:p></o:p> Packaged, certified, and supported LDAP solutions= powered by OpenLDAP:<o:p></o:p> <<a href=3D"https://urldefense.com/v3/__http:/= www.symas.com__;!8WoA6RjC81c!R398Hvv4fWbtEY6cojq9Y7NDCOui0Wmtxg3ZIwwbs-vEdc= C_Ir4Odx8wrsWJSPM5qmj9$%20">https://urldefense.com/v3/__http://www.symas.com__;!8WoA6RjC81c!R398= Hvv4fWbtEY6cojq9Y7NDCOui0Wmtxg3ZIwwbs-vEdcC_Ir4Odx8wrsWJSPM5qmj9$ </a>><o:p></o:p> <o:p> </o:p> Juniper Business Use Only</span= ><o:p></o:p> </div> </body> </html> --_000_CH2PR05MB69514726BCB360A68DA761D2DF860CH2PR05MB6951namp_--

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by quanah＠symas.com 26 Sep '19

26 Sep '19

--On Thursday, September 26, 2019 2:19 PM +0000 Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net> wrote: > > > Hi, > > Thanks for sharing the inputs. We have tried with the unmodified release > of OpenLDAP that was suggested. From the pcap, we have noticed the LDAP > search requests are sequential. (pl. find attached the pcap) for > reference Please put your pcap file on the FTP server rather than sending it via the ITS system. Then respond to the ITS with a link to the file. --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#9018) dynlist don't close connection
by I.Harbuz＠A1.by 24 Sep '19

24 Sep '19

R29vZCBkYXksIE9uZMWZZWouDQoNCkkgaGF2ZSBjaGFuZ2VkIGJhY2stbWV0YSB0byB0aGUgYmFj ay1sZGFwLCBhbmQgaXQgcmVzb2x2ZWQgdGhpcyBwcm9ibGVtLg0KDQpCZXN0IHJlZ2FyZHMsDQpJ aGFyIEhhcmJ1eg0KPGh0dHA6Ly9pbnRyYW5ldC9TaXRlUGFnZXMvZW1wbG95ZWUuYXNweD9kZXBf aWQ9NTE1XzExOTMvNy8yPg0KU3lzdGVtIFNvbHV0aW9ucyBEZXZlbG9wbWVudCBhbmQgT3BlcmF0 aW9ucyBHcm91cA0KSVQgc29sdXRpb25zIERldmVsb3BtZW50IGFuZCBPcGVyYXRpb25zIERlcGFy dG1lbnQNCkNsb3VkIGFuZCBJQ1QgaW5mcmFzdHJ1Y3R1cmUgRGl2aXNpb24NCg0KVW5pdGFyeSBl bnRlcnByaXNlIEExDQpBMS1jZW50ZXINCnVsLiBJbnRlcm5hdHNpb25hbG5heWEsIDM2LTINCjIy MDAzMCwgTWluc2ssIEJlbGFydXMNClRlbC4gKzM3NSA0NCA3MTAtMTEtNzQNCnd3dy5BMS5ieTxo dHRwOi8vd3d3LnZlbGNvbS5ieS8+DQp3d3cuQTEuZ3JvdXA8aHR0cDovL3d3dy5hMS5ncm91cC8+ DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K0J7RgjogT25kxZllaiBL dXpuw61rIDxvbmRyYUBtaXN0b3RlYmUubmV0Pg0K0J7RgtC/0YDQsNCy0LvQtdC90L46IDI0INGB 0LXQvdGC0Y/QsdGA0Y8gMjAxOSDQsy4gMTI6MzMNCtCa0L7QvNGDOiBJaGFyIEhhcmJ1eg0K0JrQ vtC/0LjRjzogb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZw0K0KLQtdC80LA6IFJlOiAoSVRTIzkw MTgpIGR5bmxpc3QgZG9uJ3QgY2xvc2UgY29ubmVjdGlvbg0KDQpPbiBUaHUsIE1heSAwMiwgMjAx OSBhdCAxMDo0MDoyMUFNICswMDAwLCBpLmhhcmJ1ekB2ZWxjb20uYnkgd3JvdGU6DQo+IEFueSBs ZGFwc2VhcmNoIGNvbW1hbmRzIHdvcmsgZmluZSBpZiByZXF1ZXN0IGRvZXNuJ3QgaGl0IGludG8g ZHlubGlzdC4NCj4gSWYgcmVxdWVzdCBoaXQgaW4gZHlubGlzdCB0aGVuIGl0IG91dHB1dCBpbmZv cm1hdGlvbiBhbmQgaGFuZ2VkIHVwLg0KDQpIZWxsbyBJaGFyLA0KaXQgc2VlbXMgeW91IGhhdmUg Y29uZmlndXJlZCBkeW5saXN0IGFzIGEgZ2xvYmFsIG92ZXJsYXkuIEkgd291bGQgbm90ZQ0KdGhh dCBub3QgbWFueSBvdmVybGF5cyBmdWxseSBzdXBwb3J0IHRoaXMgdHlwZSBvZiBjb25maWd1cmF0 aW9uIGF0IHRoZQ0KbW9tZW50IGFuZCBtaWdodCBub3QgZnVuY3Rpb24gY29ycmVjdGx5Lg0KDQpJ dCBpcyBwb3NzaWJsZSB0aGF0IGR5bmxpc3Qgd2lsbCBkbyBqdXN0IGZpbmUgZm9yIHlvdXIgdXNl IGNhc2UuIE1ha2UNCnN1cmUgeW91IHRlc3Qgd2l0aCBhIHNpbXBsZXIgc2NlbmFyaW8gYXMgd2Vs bCAod2hlcmUgZGF0YWJhc2VzIGFyZSBub3QNCnN1Ym9yZGluYXRlIGFuZC9vciB3aXRob3V0IGJh Y2stbWV0YSBpbiB0aGUgcGljdHVyZSkgdG8gc2VlIGlmIHRoZXJlDQptaWdodCBiZSBpbnRlcmFj dGlvbiBiZXR3ZWVuIHRoZW0uDQoNCkRvIGxldCB1cyBrbm93IGlmIHlvdSBkZWNpZGUgdG8gaW52 ZXN0aWdhdGUgZnVydGhlciBhbmQgZmluZCBhIG1pbmltYWwNCnVzZSBjYXNlIHdoZXJlIHRoaW5n cyBzdGFydCB0byBicmVhay4gQWxzbyBhIGZ1bGwgdGVzdCBzY3JpcHQgdGhhdCBzZXRzDQp1cCBh IHNlbGYtY29udGFpbmVkIGVudmlyb25tZW50IGFuZCByZWxpYWJseSB0cmlnZ2VycyB0aGUgaXNz dWUgd291bGQNCmdyZWF0bHkgaW1wcm92ZSBvdXIgY2hhbmNlcyBvZiBkaWFnbm9zaW5nIGl0IGNv cnJlY3RseS4NCg0KVGhhbmtzLA0KDQotLQ0KT25kxZllaiBLdXpuw61rDQpTZW5pb3IgU29mdHdh cmUgRW5naW5lZXINClN5bWFzIENvcnBvcmF0aW9uICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vd3d3LnN5bWFzLmNvbQ0KUGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQ IHNvbHV0aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQDQo8cCBzdHlsZT0iZm9udDogMTJweCBhcmlh bCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYmEoMTAyLCAxMDIsIDEwMiwgMSk7Ij4gVGhpcyBlLW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyB0byBpdCBtYXkgY29udGFpbiBDT05GSURFTlRJQUwgT1Ig UFJPUFJJRVRBUlkgSU5GT1JNQVRJT04gb2YgQTEgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgcmVj aXBpZW50LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBieSBtaXN0YWtlIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSB0ZWxlcGhvbmUgb3IgcmVwbHkgdGhp cyBlLW1haWwgYW5kIERFTEVURSB0aGUgb3JpZ2luYWwgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIHRvIGl0IHdpdGhvdXQgbWFraW5nIGEgQ09QWS4gWW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgdW5hdXRob3JpemVkIHJldmlldywgdXNlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlv biBvZiB0aGlzIG1lc3NhZ2UgYW5kIGF0dGFjaG1lbnRzIHRvIGl0IGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIFRoaXMgZS1tYWlsIGFuZCBhdHRhY2htZW50cyB0byBpdCBtYXkgbm90IGJlIHJldHJh bnNtaXR0ZWQgdG8gYW55IHBhcnR5IG91dHNpZGUgb2YgdGhlIHJlY2lwaWVudCdzIG9yZ2FuaXph dGlvbiB3aXRob3V0IHRoZSBwcmlvciB3cml0dGVuIGNvbnNlbnQgb2YgdGhlIHNlbmRlci4NCjwv cD4NCg==

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2019