openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 05 Apr '16

05 Apr '16

--On Tuesday, April 05, 2016 11:35 PM +0000 Frank.Swasey(a)uvm.edu wrote: It's ok, it is trivial to run through a mime decoder. So the regression was added in 2.4.43. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 05 Apr '16

05 Apr '16

U2Vjb25kIGF0dGVtcHQgLSBzb21ldGhpbmcgYWJvdXQgbXkgZmlyc3QgYXR0ZW1wdCBzZWVtcyB0 byBoYXZlIHRyaXBwZWQgdGhlIHNwYW0gZmlsdGVyIGF0IGdhdXNzLg0KDQpUb2RheSwgSSBoYXZl IGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIgd2l0aG91dCB0aGUg bm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUgYmFzZS4gIEkgaGF2 ZSBmb3VuZCB0aGF0IGJvdGggMi40LjQ0IGFuZCAyLjQuNDMgaGF2ZSB0aGlzIGZhaWx1cmUgd2l0 aGluIGFuIGhvdXIgb2Ygc3RhcnRpbmcgdGhlIHByaW1hcnkgc2VydmVyIGFuZCBvbmNlIGFuIGhv dXIgYWZ0ZXIgaXQgZmlyc3QgaGFwcGVucy4gIFRoZSAyLjQuNDIgY29kZSBoYXMgYmVlbiBydW5u aW5nIGZvciBvdmVyIHR3byBob3VycyBub3cgKGFuZCBqdXN0IGFzIGluIG15IHByb2R1Y3Rpb24g ZW52aXJvbm1lbnQpIGhhcyBub3QgZmFpbGVkIGF0IGFsbC4NCg0KVGhlIG9wdGlvbnMgSSBhbSB1 c2luZyB3aXRoIGNvbmZpZ3VyZSBhcmU6DQoNCmV4cG9ydCBDRkxBR1M9Ii1ETkRFQlVHIC1EX1JF RU5UUkFOVCAtZlBJQyINCmV4cG9ydCBMSUJTPSItbHB0aHJlYWQiDQouL2NvbmZpZ3VyZSBcDQog ICAgICAgIC1xIFwNCiAgICAgICAgLS1lbmFibGUtZHluYW1pYyBcDQogICAgICAgIC0tZW5hYmxl LXN0YXRpYyBcDQogICAgICAgIC0td2l0aC10aHJlYWRzPXBvc2l4IFwNCiAgICAgICAgLS13aXRo LXRscz1vcGVuc3NsIFwNCiAgICAgICAgLS13aXRoLWN5cnVzLXNhc2wgXA0KICAgICAgICAtLWVu YWJsZS13cmFwcGVycyBcDQogICAgICAgIC0tZW5hYmxlLXBhc3N3ZCBcDQogICAgICAgIC0tZW5h YmxlLWNsZWFydGV4dCBcDQogICAgICAgIC0tZW5hYmxlLWNyeXB0IFwNCiAgICAgICAgLS1lbmFi bGUtc3Bhc3N3ZCBcDQogICAgICAgIC0tZW5hYmxlLWxtcGFzc3dkIFwNCiAgICAgICAgLS1lbmFi bGUtbW9kdWxlcyBcDQogICAgICAgIC0tZW5hYmxlLWlwdjYgXA0KICAgICAgICBcDQogICAgICAg IC0tZW5hYmxlLXNsYXBkIFwNCiAgICAgICAgLS1lbmFibGUtYmFja2VuZHM9bW9kIFwNCiAgICAg ICAgLS1kaXNhYmxlLW5kYiBcDQogICAgICAgIC0tZGlzYWJsZS1zcWwgXA0KICAgICAgICAtLWRp c2FibGUtcGVybCBcDQogICAgICAgIC0tZGlzYWJsZS1zaGVsbCBcDQogICAgICAgIC0tZW5hYmxl LW92ZXJsYXlzPW1vZA0KDQoNCuKAlA0KRnJhbmsgU3dhc2V5DQpTeXN0ZW1zIEFyY2hpdGVjdHVy ZSAmIEFkbWluaXN0cmF0aW9uDQo=

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 05 Apr '16

05 Apr '16

VG9kYXksIEkgaGF2ZSBidWlsdCBhbmQgdGVzdGVkIDIuNC40NCwgMi40LjQzLCBhbmQgMi40LjQy IHdpdGhvdXQgdGhlIG5vcm1hbCBtb2RpZmljYXRpb25zIHRoYXQgSSBtYWtlIHRvIHRoZSBjb2Rl IGJhc2UuICBJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUgdGhp cyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZlciBh bmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNvZGUg aGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciB0d28gaG91cnMgbm93IChhbmQganVzdCBhcyBpbiBt eSBwcm9kdWN0aW9uIGVudmlyb25tZW50KSBoYXMgbm90IGZhaWxlZCBhdCBhbGwuDQoNClRoZSBv cHRpb25zIEkgYW0gdXNpbmcgd2l0aCBjb25maWd1cmUgYXJlOg0KDQpleHBvcnQgQ0ZMQUdTPSIt RE5ERUJVRyAtRF9SRUVOVFJBTlQgLWZQSUMiDQpleHBvcnQgTElCUz0iLWxwdGhyZWFkIg0KLi9j b25maWd1cmUgXA0KICAgICAgICAtcSBcDQogICAgICAgIC0tZW5hYmxlLWR5bmFtaWMgXA0KICAg ICAgICAtLWVuYWJsZS1zdGF0aWMgXA0KICAgICAgICAtLXdpdGgtdGhyZWFkcz1wb3NpeCBcDQog ICAgICAgIC0td2l0aC10bHM9b3BlbnNzbCBcDQogICAgICAgIC0td2l0aC1jeXJ1cy1zYXNsIFwN CiAgICAgICAgLS1lbmFibGUtd3JhcHBlcnMgXA0KICAgICAgICAtLWVuYWJsZS1wYXNzd2QgXA0K ICAgICAgICAtLWVuYWJsZS1jbGVhcnRleHQgXA0KICAgICAgICAtLWVuYWJsZS1jcnlwdCBcDQog ICAgICAgIC0tZW5hYmxlLXNwYXNzd2QgXA0KICAgICAgICAtLWVuYWJsZS1sbXBhc3N3ZCBcDQog ICAgICAgIC0tZW5hYmxlLW1vZHVsZXMgXA0KICAgICAgICAtLWVuYWJsZS1pcHY2IFwNCiAgICAg ICAgXA0KICAgICAgICAtLWVuYWJsZS1zbGFwZCBcDQogICAgICAgIC0tZW5hYmxlLWJhY2tlbmRz PW1vZCBcDQogICAgICAgIC0tZGlzYWJsZS1uZGIgXA0KICAgICAgICAtLWRpc2FibGUtc3FsIFwN CiAgICAgICAgLS1kaXNhYmxlLXBlcmwgXA0KICAgICAgICAtLWRpc2FibGUtc2hlbGwgXA0KICAg ICAgICAtLWVuYWJsZS1vdmVybGF5cz1tb2QNCg0KDQrigJQNCkZyYW5rIFN3YXNleQ0KU3lzdGVt cyBBcmNoaXRlY3R1cmUgJiBBZG1pbmlzdHJhdGlvbg0KDQoNCg0KDQoNCg==

1 0

Re: (ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠zimbra.com 04 Apr '16

04 Apr '16

--On Sunday, April 03, 2016 3:34 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) Closing this ITS, it was related to a bug in the code in our side that sets the DH Param bits for slapd, that has a race condition, where the file may be 0 sized initially. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 04 Apr '16

04 Apr '16

Full_Name: Francis Swasey Version: 2.4.44 OS: Red Hat Enterprise Linux Server release 7.2 (Maipo) URL: http://www.uvm.edu/~fcs/openldap_its/syncprov_files.tar.gz Submission from: (NULL) (132.198.104.198) Once an hour, the primary server logs a syncprov_sendresp that does not include a csn. When that happens, the replica misses that there were changes and does not update and therefore falls behind. The URI provides files for the primary and replica. replica/slapd_db.ldif -- starting database replica/slapd.conf -- replica's slapd configuration file (you'll need to create your own ssl certs) replica/syncrepl_audit.sh -- Runs on the replica (edit the email address and the path to check_syncrepl replica/check_syncrepl -- Used by nagios to report csn being in sync or not primary/slapd_db.ldif -- starting database (almost exactly like the replica's version) primary/slapd.conf -- primary's slapd configuration file (you'll need to create your own ssl certs) primary/syncprov_audit.sh -- greps the system log (edit the path) looking for the syncprov error primary/makechanges.sh -- edit to change the name of the ldap server and run this to make constant changes The bad log entries that coincide with check_syncrepl finding the replica has fallen behind are like: Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 They appear once an hour.

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 04 Apr '16

04 Apr '16

My initial report was garbled. What I mean is that a protection violation occurs in mdb.c when I add a 13'th item to a multiset and I compile with one of the mentioned compilers and with -fPIC -O3. The code works fine when compiled with older GCC compilers or with -O0 or with -fno-strict-aliasing. Given what I read at https://gcc.gnu.org/bugs/ under section "Casting does not work as expected when optimization is turned on", I suspect the problem is simply that a pointer variable is not following the ISO C aliasing rules and breaks with the new, more aggressive compiler optimization. Here is the part that fails: for (i=0; i<NUMKEYS(fp); i++) mp->mp_ptrs[i] = fp->mp_ptrs[i] + offset; If this turns out to not be straightforward, I can try building a small test program to reproduce the problem. On 04/03/2016 09:44 AM, Howard Chu wrote: > bdallen(a)nps.edu wrote: >> Full_Name: Bruce Allen >> Version: 2.4.44 >> OS: Fedora 23 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (205.155.65.226) >> >> >> LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when >> compiled >> using these compilers: >> * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) >> * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW >> 5.2.0-1.fc23) >> >> The crash happens afterrititing the 12'th item (with the same key but >> different >> value using flags MDB_NODUPDATA and MDB_DUPSORT). > > Your message appears garbled here. Please send a test case with steps > to reproduce. >> >> The problem goes away when compiling mdb.c with the >> -fno-strict-aliasing flag. >> >> > >

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by hyc＠symas.com 03 Apr '16

03 Apr '16

bdallen(a)nps.edu wrote: > Full_Name: Bruce Allen > Version: 2.4.44 > OS: Fedora 23 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.155.65.226) > > > LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled > using these compilers: > * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) > * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) > > The crash happens afterrititing the 12'th item (with the same key but different > value using flags MDB_NODUPDATA and MDB_DUPSORT). Your message appears garbled here. Please send a test case with steps to reproduce. > > The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag. > > -- -- 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#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠openldap.org 02 Apr '16

02 Apr '16

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) While testing the new DH params code for slapd, we found that there is an interval in which slapd will break for startTLS connections while it loads in the DH key. Example: Slapd is up and running, accepts startTLS connections just fine: Apr 2 21:13:08 zre-ldap002 slapd[4844]: conn=1004 fd=13 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=AES256-SHA256 Then we update olcTLSDHParamFile to add a DH key: Apr 2 21:13:09 zre-ldap002 slapd[4844]: conn=1005 op=22 MOD dn="cn=config" Apr 2 21:13:09 zre-ldap002 slapd[4844]: conn=1005 op=22 MOD attr=olcTLSDHParamFile Immediately after this, all startTLS attempts fail for the next few minutes: Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 fd=14 ACCEPT from IP=10.137.242.52:48327 (IP=10.137.242.52:389) Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 STARTTLS Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 RESULT oid= err=52 etime=0.000078 text=Could not initialize TLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1008 op=1 UNBIND Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1008 fd=14 closed Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 fd=14 ACCEPT from IP=10.137.242.52:48328 (IP=10.137.242.52:389) Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 STARTTLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 RESULT oid= err=52 etime=0.000054 text=Could not initialize TLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=1 UNBIND Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 fd=14 closed Apr 2 21:13:17 zre-ldap002 slapd[4844]: connD1D1010 fd=14 ACCEPT from IP=10.137.242.52:48329 (IP=10.137.242.52:389) Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 STARTTLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 RESULT oid= err=52 etime=0.000124 text=Could not initialize TLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=1 UNBIND Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 fd=14 closed Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 fd=14 ACCEPT from IP=10.137.242.52:48330 (IP=10.137.242.52:389) Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=0 STARTTLS Apr 2 21:13:18 zre-lda0202 slapd[4844]: conn=1011 op=0 RESULT oid= err=52 etime=0.000075 text=Could not initialize TLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=1 UNBIND Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 fd=14 closed Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 fd=14 ACCEPT from IP=10.137.242.52:48331 (IP=10.137.242.52:389) Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 STARTTLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 RESULT oid= err=52 etime=0.000098 text=Could not initialize TLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=1 UNBIND Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 fd=14 closed Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 fd=14 ACCEPT from IP=10.137.242.52:48332 (IP=10.137.242.52:389) Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 STARTTLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 RESULT oid= err=52 etime=0.000062 text=Could not initialize TLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=1 UNBIND Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 fd=14 closed Apr 2 21:13"22 zre-ldap0 s slapd[4844]: conn=1014 fd=14 ACCEPT from IP=10.137.242.52:48333 (IP=10.137.242.52:389) Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 STARTTLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 RESULT oid= err=52 etime=0.000108 text=Could not initialize TLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=1 UNBIND Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 fd=14 closed Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 fd=14 ACCEPT from IP=10.137.242.52:48334 (IP=10.137.242.52:389) Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 STARTTLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 RESULT oid= err=52 etime=0.000066 text=Could not initialize TLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=1 UNBIND .... Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022d%d=14 ACCEPT from IP=10.137.242.52:48339 (IP=10.137.242.52:389) Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 STARTTLS Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 RESULT oid= err=52 etime=0.000143 text=Could not initialize TLS Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 fd=14 closed (connection lost) Eventually it recovers: Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 fd=14 ACCEPT from IP=10.137.242.52:48340 (IP=10.137.242.52:389) Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 op=0 STARTTLS Apr 2 21:16:02 zre-ldap002 slapd[4844]: connD1D1027 op=0 RESULT oid= err=0 etime=0.000085 text= Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 fd=14 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.2 tls_cipher=AES128-SHA256 My guess is that startTLS is essentially broken while slapd spends time loading in the DH key. I would think that during this time, slapd should be deferring connections rather than accepting them immediately.

1 0

(ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 01 Apr '16

01 Apr '16

Full_Name: Bruce Allen Version: 2.4.44 OS: Fedora 23 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.155.65.226) LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled using these compilers: * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) The crash happens afterrititing the 12'th item (with the same key but different value using flags MDB_NODUPDATA and MDB_DUPSORT). The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag.

1 0

(ITS#8393) LMDB - MDB_GET_BOTH broken on non-dup value
by hyc＠openldap.org 27 Mar '16

27 Mar '16

Full_Name: Howard Chu Version: 0.9.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.228.110) Submitted by: hyc Using mdb_cursor_get(MDB_GET_BOTH) doesn't return the data item if the record is not a dup (i.e., there's only a single value under the key) even though it matches. This doesn't affect slapd because (1) when we use this command, the key always has more than 1 value and (2) when we use it, the data item we passed in is exactly the same as what we would get returned, on a match. This affects other apps where both (1) and (2) are not true, e.g. a compare function is used that only compares a subset of the data, in order to retrieve the full record.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs