openldap-bugs April 2009

openldap-bugs@openldap.org

49 participants
141 discussions

(ITS#6078) Slapd.exe crashes when writing entries while reading many entries.
by Frank.Offermanns＠caseris.de 27 Apr '09

27 Apr '09

Full_Name: Frank Offermanns Version: 2.4.16 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.242) Hello, i am using OpenLDAP 2.4.16 with Windows XP, compiled with msys/mingw with Windows XP and the berkeley DB 4.7.25 NC The database runs without any replication (though with replication it also crashes) I use the "hdb" Backend. I started the datatbase with "slapd -F slapd.d". Now i add about 21000 Entries under the DN: o=test6,ou=Users,o=caesar. When this is finished i start adding another 21000 Entries under the DN: o=test7,ou=Users,o=caesar. While adding these seconds entries i use the LDAPAdmin 1.1.0.0 to view the subtree at "o=test6,ou=Users,o=caesar". LDAPAdmin starts to read the Users and fails at about the 4000 Entry. At this time my slapd.exe crashed. I also did the test with "slapd -d 1 -F slapd.d" and found the following entries in the logfile: ber_flush2: 77 bytes to sd 2268 ber_get_next: tag 0x30 len 93 contents: <= send_search_entry: conn 0 exit. ber_get_next conn=2 op=4017 do_modify entry_decode: "" ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: <= entry_decode() >>> dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar> <<< dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar>, <cn=10250,o=test7,ou=users,o=caesar> bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => send_search_entry: conn 0 dn="cn=12034,o=test6,ou=Users,o=caesar" => hdb_dn2id("cn=10250,o=test7,ou=users,o=caesar") ber_flush2: 77 bytes to sd 2268 <= hdb_dn2id: got id=0x53da <= send_search_entry: conn 0 exit. entry_decode: "" entry_decode: "" <= entry_decode() <= entry_decode() bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => send_search_entry: conn 0 dn="cn=12035,o=test6,ou=Users,o=caesar" ber_flush2: 77 bytes to sd 2268 entry_decode: "" <= entry_decode() <= send_search_entry: conn 0 exit. bdb_modify_internal: 0x000053da: c²0250 entry_decode: "" <= entry_decode() entry failed schema check: unrecongized attribute type(s) in RDN hdb_modify: modify failed (34) send_ldap_result: conn=2 op=4017 p=3 send_ldap_response: msgid=1026718 tag=103 err=34 => send_search_entry: conn 0 dn="cn=12036,o=test6,ou=Users,o=caesar" ber_flush2: 53 bytes to sd 2336 ber_flush2: 77 bytes to sd 2268 <= send_search_entry: conn 0 exit. entry_decode: "" <= entry_decode() connection_get(4): got connid=2 connection_read(4): checking for input on id=2 ber_get_next ber_get_next: tag 0x30 len 87 contents: ber_get_next conn=2 op=4018 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: >>> dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar> <<< dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar>, <cn=10250,o=test7,ou=users,o=caesar> bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => hdb_dn2id("cn=10250,o=test7,ou=users,o=caesar") <= hdb_dn2id: got id=0x53da entry_decode: "" <= entry_decode() The pointer at "bdb_modify_internal" seems to be dangling. When i didn't read the entries while writing, there seems to be no problem. The Version 2.4.13 also does not seem to have this problem. (I couldn't get the 2.4.13 Version crashing and the 2.4.16 crashes every time after a short time) Additional Info: I am not sure, if this could be a reason for this error, so i am writing this problem also. Starting at Version 2.4.14 the configure command creates makefiles which are not linkable at mingw/msys at windows. I manually added "-lws2_32" in the makefiles at the lines: AC_LIBS = -lregex -lws2_32 I apologize me for my bad english and hope you can understand me. Regards, Frank Offermanns

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 25 Apr '09

25 Apr '09

This is a multi-part message in MIME format. --------------080405020304060402030808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Fixing this for unique_add seams easy enough (see preliminary attached patch) - fixing it for modrdn/modify seems to be another difficulty level as in order to properly apply the filter I think the full modifications have to be applied... If wanted I can produce a patch for this as well, but I would like to know if that is appreciated and if my plan for fixing looks sensible: - Pull the "modification simulation" code out of constraint.c (line 959:1040 and some more in 2.4.16) into constraints.c - Add a overlay-int.h - Make constraint.c and unique.c use that As I dont really know the openldap codebase my analysis could be completely wrong - I would appreciate some feedback. Andres --------------080405020304060402030808 Content-Type: text/x-diff; name="slapd-unique-overlay-spurious-failure-fix-add.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-unique-overlay-spurious-failure-fix-add.patch" --- openldap-2.4.16.saved/servers/slapd/overlays/unique.c 2009-04-23 23:51:37.925387747 +0200 +++ openldap-2.4.16/servers/slapd/overlays/unique.c 2009-04-26 01:58:54.566927667 +0200 @@ -1071,6 +1071,24 @@ && !dnIsSuffix( &op->o_req_ndn, &uri->ndn )) continue; + if (uri->filter.bv_val && uri->filter.bv_len){ + Filter *f = str2filter_x(op, + uri->filter.bv_val); + if(f == NULL) { + op->o_bd->bd_info = (BackendInfo *) on->on_info; + send_ldap_error(op, rs, LDAP_OTHER, + "unique_search invalid filter"); + return(rs->sr_err); + } + + if(test_filter(NULL, op->ora_e, f) == LDAP_COMPARE_FALSE){ + Debug(LDAP_DEBUG_TRACE, "==> unique_add_skip<%s>\n", + op->o_req_dn.bv_val, 0, 0); + continue; + } + filter_free_x(op, f, 1); + } + if(!(a = op->ora_e->e_attrs)) { op->o_bd->bd_info = (BackendInfo *) on->on_info; send_ldap_error(op, rs, LDAP_INVALID_SYNTAX, --------------080405020304060402030808--

1 0

Re: (ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by daniel＠pluta.biz 25 Apr '09

25 Apr '09

Hallvard B Furuseth schrieb: > Yes, the on-th-fly sorting combined with the delete-single-value > code seems broken. I'm not sure if delete-single-value could ever > be invoked Of course could it be "invoked" before: just use slapd 2.4.16 together with slapo-collect and your favorit ldapmodify client. Right after the "invocation" you'll get an error message complaining about a missing equality rule. Thus there's no hint within collect's source that the single-value delete is faulty I inserted an equality rule and began to wonder... > before you inserted an EQUALITY matching rule though. Do you mean the single-value-delete functionality has been silently "disabled" by removing the EQUALITY matching rule leaving slapo-collect's by design defective single-value-delete code block knowingly unchanged/uncommented? This seems very strange to me even more because slapo-collect is advertises as demonstration overlay (ok, a "quick hacked" one but nevertheless questionable). > I too don't know cn=config all that well:-( <speculation> Instead of correcting handling this issue only in collect.c there perhabs exists a more general possibility to pimp the cn=config internal add mechanisms regarding the handling of ordered config values? In my opinion a very important feature concerning "overlapping"... Á la: cfg_value_add(.., .., SLAPD_CFG_VALSORT_ALPHA|SLAPD_CFG_VALSORT_DN|..) only problem seems to be how to sort a configuration value like: '"ou=test,dc=foo,dc=bar" l,st' by DN's depth </speculation>

1 0

(ITS#5535) smbk5pwd uses private heimdal functions
by admin＠dmarkey.com 24 Apr '09

24 Apr '09

--000e0cd1e8fc2040e9046856eee5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review http://dmarkey.com/~dmarkey/smbk5pwd.patch to fix this. Against 2.4.16 smbk5pwd. --000e0cd1e8fc2040e9046856eee5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review <a href="http://dmarkey.com/~dmarkey/smbk5pwd.patch">http://dmarkey.com/~dmarkey/smbk5pwd.patch</a> to fix this. Against 2.4.16 smbk5pwd. --000e0cd1e8fc2040e9046856eee5--

1 0

(ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 24 Apr '09

24 Apr '09

Full_Name: Andres Freund Version: 2.4.16 OS: Linux URL: Submission from: (NULL) (85.178.193.10) If I read the code correctly the unique overlay does not check if the current operation matches the filter of a domain before doing a uniqeness check. This leads to wrongly reported errors. I noticed this after adding a uniqueness constraint on gidNumber on all posixGroup objects (i.e. ldap:///?gidNumber?sub?(objectClass=posixGroup)) - it was not possible anymore to add posixAccounts with that gidNumber. Thanks, Andres Here a modification of the testscript to reproduce the issue: --- openldap-2.4.16.saved/tests/scripts/test024-unique 2009-04-23 23:51:37.942051631 +0200 +++ openldap-2.4.16/tests/scripts/test024-unique 2009-04-25 02:50:40.975257488 +0200 @@ -425,6 +425,7 @@ changetype: modify add: olcUniqueURI olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) - delete: olcUniqueURI olcUniqueURI: ldap:///?description?one @@ -445,6 +446,7 @@ olcOverlay: {0}unique olcUniqueURI: ldap:///?employeeNumber,displayName?sub olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) EOF diff $TESTDIR/third-config.ldif $TESTDIR/third-reference.ldif > /dev/null 2>&1 @@ -473,6 +475,27 @@ exit -1 fi + +echo "Adding a record unique in all domains because of filter conditions " + +$LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \ + $TESTOUT 2>&1 << EOF +dn: uid=empty,ou=users,o=unique +objectClass: inetOrgPerson +uid: edgar +cn: empty +sn: empty +EOF + +RC=$? +if test $RC != 0 ; then + echo "spurious unique error ($RC)!" + test $KILLSERVERS != no && kill -HUP $KILLPIDS + exit -1 +fi + + + echo "Adding a record unique in one domain, non-unique in the filtered domain..." $LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \

1 0

24 Apr '09

Yes, the on-th-fly sorting combined with the delete-single-value code seems broken. I'm not sure if delete-single-value could ever be invoked before you inserted an EQUALITY matching rule though. I too don't know cn=config all that well:-( -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

oops, lost a few words: I wrote: > I'll fix that and a few other comments and close this ITS, > since you've clarified issue here in ITS#6076. Since you've clarified _the other_ issue here in ITS#6076. -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

Daniel Pluta writes: > cite: "... this means longer dn's (i.e. more specific dn's) will be > found first when searching..." > > But, longer DNs do not neccessarily are more specific: > > ou=openldap,o=rockz,c=it > dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific) It's just the comment which is unclear. It should be saying that sorting normalized DNs by reverse length ensures that a DN is stored after any of its subordinate DNs. I'll fix that and a few other comments and close this ITS, since you've clarified issue here in ITS#6076. -- Hallvard

1 0

(ITS#6076)
by Daniel.Pluta＠lrz.de 24 Apr '09

24 Apr '09

sorry, there's a small cut&paste error regarding step 12.) Please ignore the first 4 lines. Only the last two lines contain the corresponding output regarding step 11.) Thanks!

1 0

(ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by daniel＠pluta.biz 24 Apr '09

24 Apr '09

Full_Name: Daniel Pluta Version: OPENLDAP_STABLE OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090424.patch Submission from: (NULL) (2001:4ca0:0:f000:ecb9:edd3:5b88:63f0) As already assumed in (ITS6072 FollowUp 5) there seems to be a bug regarding the mapping of c->valx and the to-be-deleted value of the ci->ci_next list. The origin seems to be the on-the-fly manipulation (sorting) of the ci-list that is done by insert_ordered()) whenever a new config value is added... To illustrate the problem in detail I've added some debugging output into collect.c's LDAP_MOD_DELETE-section: case LDAP_MOD_DELETE: if ( c->valx == -1 ) { /* Delete entire attribute */ collect_info *ci; while (( ci = on->on_bi.bi_private )) { on->on_bi.bi_private = ci->ci_next; ch_free( ci->ci_dn.bv_val ); ch_free( ci ); } } else { /* Delete just one value */ collect_info **cip, *ci; int i; cip = (collect_info **)&on->on_bi.bi_private; Debug(LDAP_DEBUG_TRACE, "collect_cf: LDAP_MOD_DELETE: c->valx=%d\n", c->valx, 0, 0); for ( i=0; i <= c->valx; i++, cip = &ci->ci_next ) { ci = *cip; Debug(LDAP_DEBUG_TRACE, "collect_cf: LDAP_MOD_DELETE: i=%d <--> dn=%s\n", i, ci->ci_dn.bv_val, 0); } *cip = ci->ci_next; Debug(LDAP_DEBUG_TRACE, "collect_cf: free: dn=%s\n", ci->ci_dn.bv_val, 0, 0); ch_free( ci->ci_dn.bv_val ); ch_free( ci ); } The patch against OPENLDAP_STABLE could be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-090424.patch This patch also includes the mini-enhancement proposed in ITS6072 and the micro-bugfix provided in ITS6075. ITS6075 solves a small schema-specific bug which wrongly denied deletion of single olcCollectInfo configuration values at all. Here are my 12 steps to reproduce the crash... 1.) edit collect's configuration setup in slapd.conf by adding the following lines: overlay collect collectinfo ou=customer_A,dc=foo,dc=bar l,st collectinfo ou=customer_B,dc=foo,dc=bar l,st collectinfo ou=customer_C,dc=foo,dc=bar l,st collectinfo ou=customer_D,dc=foo,dc=bar l,st collectinfo ou=customer_E,dc=foo,dc=bar l,st collectinfo ou=customer_F,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_A,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_B,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_C,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_D,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_E,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_F,dc=foo,dc=bar l,st 2.) convert ".conf" into "cn=config" format, by running: slaptest -f ... -F ... The resulting collect cn=config ldif should be similar to: dn: olcOverlay={0}collect objectClass: olcOverlayConfig objectClass: olcCollectConfig olcOverlay: {0}collect olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_a,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_a,dc=foo,dc=bar" l,st structuralObjectClass: olcCollectConfig entryUUID: 51c7d5fa-c50a-102d-9657-f3a43e5eeda2 creatorsName: cn=config createTimestamp: 20090424105633Z entryCSN: 20090424105633.913345Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090424105633Z 3.) start slapd using the generated config (slapd -F ...) 4.) start browsing cn=config everything is fine 5.) delete the follwing olcCollectInfo Value using this ldif: dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=customer_a,dc=foo,dc=bar" l,st - 6.) examine the log based on the above patch (which delivers the following debugging output) collect_cf: LDAP_MOD_DELETE: c->valx=11 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=1 <--> dn=ou=users,ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=2 <--> dn=ou=users,ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=3 <--> dn=ou=users,ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=4 <--> dn=ou=users,ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=5 <--> dn=ou=users,ou=customer_f,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=6 <--> dn=ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=7 <--> dn=ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=8 <--> dn=ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=9 <--> dn=ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=10 <--> dn=ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=11 <--> dn=ou=customer_f,dc=foo,dc=bar collect_cf: free: dn=ou=customer_f,dc=foo,dc=bar ==> Holy sh..! ou=customer_f,dc=foo,dc=bar has been deleted, instead?!?!?! 7.) Though slapd still runs, lets ask about some more details using ldapsearch: dn: olcoverlay={0}collect,olcdatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcCollectConfig olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_a,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_b,dc=foo,dc=bar" l,st olcOverlay: {0}collect ==> Impressive! It seems to be that ou=customer_a,dc=foo,dc=bar has been deleted(?!?!) 8.) ok, once again we try to delete a value: dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st - 9.) but the logging output tells us: "customer_b" gets deleted now... collect_cf: LDAP_MOD_DELETE: c->valx=7 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=1 <--> dn=ou=users,ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=2 <--> dn=ou=users,ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=3 <--> dn=ou=users,ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=4 <--> dn=ou=users,ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=5 <--> dn=ou=users,ou=customer_f,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=6 <--> dn=ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=7 <--> dn=ou=customer_b,dc=foo,dc=bar collect_cf: free: dn=ou=customer_b,dc=foo,dc=bar 10.) analog to point 7.) ldapsearch reports "customer_e" has been deleted... 11.) so far so good, now lets try to increase our level of fun and delete another olcCollectInfo-value: #!RESULT OK #!CONNECTION ldap://10.111.1.1:3890 #!DATE 2009-04-24T11:36:18.343 dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st - 12.) slapd immediatly crashes, the logging output shows: collect_cf: LDAP_MOD_DELETE: c->valx=0 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: free: i=1 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: c->valx=6 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=(null) ==> segfault, ZONK! In my opinion it seems that the crash depends on the on-th-fly sorting of the DN-list which directly depends on the timely order the DNs have been added (processed by "insert_ordered()"). I'm not sure how to "fix" this bug providing an elegant solution because I don't understand the direct/slapd-internal mapping of i to ci->cn_next in detail (usually ldap results are unordered, perhabs something special regarding back-config?). The problem seems to be located here: for ( i=0; i <= c->valx; i++, cip = &ci->ci_next ) These were my two first thoughts regarding a possible workaround: - Always deleting and adding all values, in case one value gets modified? - Using ordered-format "{n}" seems to result in "always delete / add all values", too. I would appreciate your advice!

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2009