openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6016) Make moduleload automatic
by ando＠sys-net.it 12 Mar '09

12 Mar '09

hyc(a)symas.com wrote: > Right. I think we'll go with another approach instead - Samba will always spit > out moduleload directives. We'll change moduleload to check for > already-existing backends or overlays, and silently succeed in those cases. Well, I think we could also provide sort of an off-line means to check what is statically built-in and what's not. In principle, one could implement tool mode in back-monitor and perform a echo "database monitor" > slapd.conf slapcat -f slapd.conf -s "cn=Backends,cn=Monitor" | grep whatever slapcat -f slapd.conf -s "cn=Overlays,cn=Monitor" | grep whatever to find what's available. If it fails, back-monitor itself is needed; then echo "modulepath path/to/back-monitor" > slapd.conf echo "moduleload back_monitor.la" >> slapd.conf echo "database monitor" >> slapd.conf slapcat -f slapd.conf -s "cn=Backends,cn=Monitor" | grep whatever slapcat -f slapd.conf -s "cn=Overlays,cn=Monitor" | grep whatever Looks like an overkill, but it might be of general usefulness. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6016) Make moduleload automatic
by hyc＠symas.com 12 Mar '09

12 Mar '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> As a further clarification - we're only considering this for backends and >> overlays; other dynamically loaded elements' (like syntaxes, password hashes, >> whatever) behavior will not be changed. > > I see quite a few issues (unless already discussed). For example, one > would typically discover the need to load back_monitor.la only close to > the end of the configuration, while the module defines some specific > schema and even some specific calls that may be needed by other backends > instantiated earlier in order to allow custom monitoring. I guess the > problem can be generalized. Right. I think we'll go with another approach instead - Samba will always spit out moduleload directives. We'll change moduleload to check for already-existing backends or overlays, and silently succeed in those cases. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6016) Make moduleload automatic
by ando＠sys-net.it 12 Mar '09

12 Mar '09

hyc(a)symas.com wrote: > abartlet(a)samba.org wrote: >> Full_Name: Andrew Bartlett >> Version: 2.4.15 >> OS: Fedora 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (59.167.251.137) >> >> >> In Samba4, we generate a slapd.conf for OpenLDAP as part of our >> provision-backend process. This avoids administrators needing to guess at >> Samba's specific requirements. >> >> However, this places the Samba4 software in the position of having to guess how >> this host's OpenLDAP installation was compiled. In particular, we need to guess >> if the required overlays are built in, or modules. >> >> Work was done a while back to avoid us having to guess what the module path is >> (the default is is now hard-coded in the binary), but we still have to guess >> which set of modules to load. Currently this is done in 'make test' by guessing >> different sets of modules in an included 'modules.conf' and running slaptest >> until we find a combination that works. >> >> We (Samba4) would really like it if the slapd binary would load modules >> (assuming a one-to-one mapping between overlay/backend names and modules) from >> that default path, if not found static in the binary. >> >> This way, Samba would not specify modules at all in the slapd.conf, but they >> would be loaded as required, if required. >> >> Thanks, >> >> Andrew Bartlett >> >> (As discussed with Howard Chu on #openldap-devel) >> > As a further clarification - we're only considering this for backends and > overlays; other dynamically loaded elements' (like syntaxes, password hashes, > whatever) behavior will not be changed. I see quite a few issues (unless already discussed). For example, one would typically discover the need to load back_monitor.la only close to the end of the configuration, while the module defines some specific schema and even some specific calls that may be needed by other backends instantiated earlier in order to allow custom monitoring. I guess the problem can be generalized. > And before we go there, what if we just provided a slapd option to dump out > all of its compiled-in paths? Then you could inspect the modulepath and see > whether any modules of interest reside there. ? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6017) Implement parentGUID or similar in OpenLDAP
by abartlet＠samba.org 12 Mar '09

12 Mar '09

--=-IfMlemfEuIIh4cVKP58C Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I found the formal spec in MS-ADTS: It currently reads: 3.1.1.4.5.28 parentGUID This attribute is not present on an object that is the root of an NC. For all other objects, let TO be the object from which the parentGUID attribute is being read and let TP be TO!parent. TO!parentGUID is equal to TP!objectGUID. --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-IfMlemfEuIIh4cVKP58C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJuINDz4A8Wyi0NrsRAovEAJ9ENJCjmWM0oiK43uK9GWLOWzhzBACbBGpS geE0JFNIqoWTAWYGV5JpJNo= =l42G -----END PGP SIGNATURE----- --=-IfMlemfEuIIh4cVKP58C--

1 0

(ITS#6017) Implement parentGUID or similar in OpenLDAP
by abartlet＠samba.org 12 Mar '09

12 Mar '09

Full_Name: Andrew Bartlett Version: 2.4.15 OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) Samba4 would find it most helpful if OpenLDAP would be able to present an operational attribute 'parentGUID' similar to the one that Windows 2008 has implemented in AD. http://msdn.microsoft.com/en-us/library/cc221277(PROT.13).aspx Formalised details of the required semantics are not very clear at this point (I will request clarification from Microsoft on this), but for now: The root entries on a partition have no parentGUID All other entries have a value parentGUID equal to the objectGUID of the parent This value is available in search results if requested. As Samba handles the translation from text to binary, feel free to use the existing entryUUID formatting. Implementing this would avoid Samba having to perform an auxillary search to find this information, which should be very cheaply available to hdb when it is resolving the DN. Thanks, Andrew Bartlett (Discussed with Howard Chu on #openldap-devel)

1 0

Re: (ITS#6016) Make moduleload automatic
by hyc＠symas.com 12 Mar '09

12 Mar '09

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: 2.4.15 > OS: Fedora 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.167.251.137) > > > In Samba4, we generate a slapd.conf for OpenLDAP as part of our > provision-backend process. This avoids administrators needing to guess at > Samba's specific requirements. > > However, this places the Samba4 software in the position of having to guess how > this host's OpenLDAP installation was compiled. In particular, we need to guess > if the required overlays are built in, or modules. > > Work was done a while back to avoid us having to guess what the module path is > (the default is is now hard-coded in the binary), but we still have to guess > which set of modules to load. Currently this is done in 'make test' by guessing > different sets of modules in an included 'modules.conf' and running slaptest > until we find a combination that works. > > We (Samba4) would really like it if the slapd binary would load modules > (assuming a one-to-one mapping between overlay/backend names and modules) from > that default path, if not found static in the binary. > > This way, Samba would not specify modules at all in the slapd.conf, but they > would be loaded as required, if required. > > Thanks, > > Andrew Bartlett > > (As discussed with Howard Chu on #openldap-devel) > As a further clarification - we're only considering this for backends and overlays; other dynamically loaded elements' (like syntaxes, password hashes, whatever) behavior will not be changed. And before we go there, what if we just provided a slapd option to dump out all of its compiled-in paths? Then you could inspect the modulepath and see whether any modules of interest reside there. ? -- -- 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#6016) Make moduleload automatic
by abartlet＠samba.org 12 Mar '09

12 Mar '09

Full_Name: Andrew Bartlett Version: 2.4.15 OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) In Samba4, we generate a slapd.conf for OpenLDAP as part of our provision-backend process. This avoids administrators needing to guess at Samba's specific requirements. However, this places the Samba4 software in the position of having to guess how this host's OpenLDAP installation was compiled. In particular, we need to guess if the required overlays are built in, or modules. Work was done a while back to avoid us having to guess what the module path is (the default is is now hard-coded in the binary), but we still have to guess which set of modules to load. Currently this is done in 'make test' by guessing different sets of modules in an included 'modules.conf' and running slaptest until we find a combination that works. We (Samba4) would really like it if the slapd binary would load modules (assuming a one-to-one mapping between overlay/backend names and modules) from that default path, if not found static in the binary. This way, Samba would not specify modules at all in the slapd.conf, but they would be loaded as required, if required. Thanks, Andrew Bartlett (As discussed with Howard Chu on #openldap-devel)

1 0

(ITS#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by arun_patel＠yahoo.com 11 Mar '09

11 Mar '09

Full_Name: Arun Patel Version: 2.2.13 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.207.175.192) Here is the scenario. 1) Add new user (example testid) dn: uid=testid,o=xyz.com (with the attibutes and its values, etc) 2) ldapsearch -LLL -x -b uid=tesid,xyz.com finds the testid 3) Delete the user (testid) dn: uid=testid,o=xyz.com changemodify: delete 4) ldapsearch -LLL -x -b uid=tesid,xyz.com No match for DN (Good) 5) Add same user back (testid) dn: uid=testid,o=xyz.com (with the attibutes and its values, etc) 6) ldapsearch -LLL -x -b uid=tesid,xyz.com unable to retrieve the testid (Problem) I know the testid is in ldap, because went thru ldap browser and did see the entry. I then did /etc/init.d/ldap stop and /etc/init.d/ldap start After entering ldapsearch -LLL -x -b uid=tesid,xyz.com, it works, Why does this happen? Help is highly appreciated. Arun

1 0

Re: (ITS#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by d＠delphij.net 11 Mar '09

11 Mar '09

This is a multi-part message in MIME format. --------------060204070408080909040407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Here is a patch that intends to fix #6014. getpassphrase() (which in turn would be a getpass() call, or lutil_getpass() call), returns a pointer from a static char * pointer, which should never be free()'ed. Therefore, a strdup() should be called. Note that, since both getpass() implementation could return NULL, we can not strdup() directly. Instead, we need to detect whether it's NULL and handle separately. Cheers, -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! --------------060204070408080909040407 Content-Type: text/plain; name="patch-ITS6014" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-ITS6014" Index: clients/tools/ldapcompare.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapcompare.c,v retrieving revision 1.52 diff -u -p -r1.52 ldapcompare.c --- clients/tools/ldapcompare.c 21 Jan 2009 23:40:09 -0000 1.52 +++ clients/tools/ldapcompare.c 11 Mar 2009 17:22:58 -0000 @@ -182,6 +182,7 @@ main( int argc, char **argv ) { char *compdn = NULL, *attrs = NULL; char *sep; + const char *passphrase; int rc; LDAP *ld = NULL; struct berval bvalue = { 0, NULL }; @@ -233,7 +234,8 @@ main( int argc, char **argv ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup(passphrase) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapdelete.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapdelete.c,v retrieving revision 1.130 diff -u -p -r1.130 ldapdelete.c --- clients/tools/ldapdelete.c 21 Jan 2009 23:40:09 -0000 1.130 +++ clients/tools/ldapdelete.c 11 Mar 2009 17:22:58 -0000 @@ -162,6 +162,7 @@ int main( int argc, char **argv ) { char buf[ 4096 ]; + const char *passphrase; FILE *fp; LDAP *ld; int rc, retval; @@ -191,7 +192,8 @@ main( int argc, char **argv ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup(passphrase) : 0; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapexop.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapexop.c,v retrieving revision 1.16 diff -u -p -r1.16 ldapexop.c --- clients/tools/ldapexop.c 21 Jan 2009 23:40:09 -0000 1.16 +++ clients/tools/ldapexop.c 11 Mar 2009 17:22:58 -0000 @@ -70,6 +70,7 @@ main( int argc, char *argv[] ) LDAP *ld = NULL; char *matcheddn = NULL, *text = NULL, **refs = NULL; + const char *passphrase; LDAPControl **ctrls = NULL; int id, code; LDAPMessage *res; @@ -91,7 +92,8 @@ main( int argc, char *argv[] ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup( passphrase ) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapmodify.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapmodify.c,v retrieving revision 1.209 diff -u -p -r1.209 ldapmodify.c --- clients/tools/ldapmodify.c 21 Jan 2009 23:40:09 -0000 1.209 +++ clients/tools/ldapmodify.c 11 Mar 2009 17:22:58 -0000 @@ -237,6 +237,7 @@ int main( int argc, char **argv ) { char *rbuf = NULL, *rejbuf = NULL; + const char *passphrase; FILE *rejfp; struct LDIFFP *ldiffp, ldifdummy = {0}; char *matched_msg, *error_msg; @@ -286,7 +287,8 @@ main( int argc, char **argv ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup( passphrase ) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapmodrdn.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapmodrdn.c,v retrieving revision 1.124 diff -u -p -r1.124 ldapmodrdn.c --- clients/tools/ldapmodrdn.c 21 Jan 2009 23:40:09 -0000 1.124 +++ clients/tools/ldapmodrdn.c 11 Mar 2009 17:22:58 -0000 @@ -151,6 +151,7 @@ int main(int argc, char **argv) { char *entrydn = NULL, *rdn = NULL, buf[ 4096 ]; + const char *passphrase; FILE *fp; LDAP *ld; int rc, retval, havedn; @@ -192,7 +193,8 @@ main(int argc, char **argv) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup( passphrase ) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldappasswd.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldappasswd.c,v retrieving revision 1.148 diff -u -p -r1.148 ldappasswd.c --- clients/tools/ldappasswd.c 7 Mar 2009 23:08:09 -0000 1.148 +++ clients/tools/ldappasswd.c 11 Mar 2009 17:22:59 -0000 @@ -205,8 +205,9 @@ main( int argc, char *argv[] ) if( want_oldpw && oldpw.bv_val == NULL ) { /* prompt for old password */ - char *ckoldpw; - oldpw.bv_val = strdup(getpassphrase(_("Old password: "))); + const char *oldpassphrase, *ckoldpw; + oldpassphrase = getpassphrase(_("Old password: ")); + oldpw.bv_val = oldpassphrase ? strdup(oldpassphrase) : NULL; ckoldpw = getpassphrase(_("Re-enter old password: ")); if( oldpw.bv_val == NULL || ckoldpw == NULL || @@ -217,7 +218,7 @@ main( int argc, char *argv[] ) goto done; } - oldpw.bv_len = strlen( oldpw.bv_val ); + oldpw.bv_len = oldpw.bv_val ? strlen( oldpw.bv_val ) : 0; } if( newpwfile ) { @@ -230,8 +231,9 @@ main( int argc, char *argv[] ) if( want_newpw && newpw.bv_val == NULL ) { /* prompt for new password */ - char *cknewpw; - newpw.bv_val = strdup(getpassphrase(_("New password: "))); + const char *newpassphrase, *cknewpw; + newpassphrase = getpassphrase(_("New password: ")); + newpw.bv_val = newpassphrase ? strdup(newpassphrase) : NULL; cknewpw = getpassphrase(_("Re-enter new password: ")); if( newpw.bv_val == NULL || cknewpw == NULL || @@ -242,7 +244,7 @@ main( int argc, char *argv[] ) goto done; } - newpw.bv_len = strlen( newpw.bv_val ); + newpw.bv_len = newpw.bv_val ? strlen( newpw.bv_val ) : 0; } if ( pw_file ) { @@ -253,7 +255,9 @@ main( int argc, char *argv[] ) } } else if ( want_bindpw ) { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + const char *bindpassphrase; + bindpassphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = bindpassphrase ? strdup(bindpassphrase) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } Index: clients/tools/ldapsearch.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapsearch.c,v retrieving revision 1.262 diff -u -p -r1.262 ldapsearch.c --- clients/tools/ldapsearch.c 7 Mar 2009 00:31:34 -0000 1.262 +++ clients/tools/ldapsearch.c 11 Mar 2009 17:22:59 -0000 @@ -718,6 +718,7 @@ int main( int argc, char **argv ) { char *filtpattern, **attrs = NULL, line[BUFSIZ]; + const char *passphrase; FILE *fp = NULL; int rc, rc1, i, first; LDAP *ld = NULL; @@ -831,7 +832,8 @@ main( int argc, char **argv ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup(passphrase) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapwhoami.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapwhoami.c,v retrieving revision 1.50 diff -u -p -r1.50 ldapwhoami.c --- clients/tools/ldapwhoami.c 21 Jan 2009 23:40:09 -0000 1.50 +++ clients/tools/ldapwhoami.c 11 Mar 2009 17:22:59 -0000 @@ -112,6 +112,7 @@ main( int argc, char *argv[] ) LDAP *ld = NULL; char *matcheddn = NULL, *text = NULL, **refs = NULL; char *retoid = NULL; + const char *passphrase; struct berval *retdata = NULL; int id, code = 0; LDAPMessage *res; @@ -134,7 +135,8 @@ main( int argc, char *argv[] ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup(passphrase) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } --------------060204070408080909040407--

1 0

Re: (ITS#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by ando＠sys-net.it 11 Mar '09

11 Mar '09

Isn't getpass() deprecated and removed from POSIX? p. yuri.pankov(a)gmail.com wrote: > Full_Name: Yuri Pankov > Version: 2.4.15 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.175.25.104) > > > Running ldap{add,modify} with -W switch leads to following coredump (introduced > in rev.1.121 of clients/tools/common.c): >> ldapadd -x -D "cn=root,dc=darklight,dc=homeunix,dc=org" -W -f root.ldif > Enter LDAP Password: > adding new entry "dc=darklight,dc=homeunix,dc=org" > > Assertion failed: (arena != NULL), function arena_dalloc, file > /usr/src/lib/libc/stdlib/malloc.c, line 3843. > Abort (core dumped) > > We shouldn't try to free() result returned by getpass(): > > --- ./clients/tools/common.c.orig 2009-03-11 19:24:18.523596600 +0300 > +++ ./clients/tools/common.c 2009-03-11 19:24:52.443459786 +0300 > @@ -255,9 +255,11 @@ > ber_memfree( binddn ); > } > > +#ifndef HAVE_GETPASS > if ( passwd.bv_val != NULL ) { > ber_memfree( passwd.bv_val ); > } > +#endif > } > > void > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

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