openldap-devel

openldap-devel@openldap.org

1416 discussions

Use of gethostbyaddr_r on openSUSE
by Michael Ströder 02 Jul '15

02 Jul '15

HI! I'm still fighting with building newer OpenLDAP RPMs for openSUSE. Originally Ralf Haferkamp generated the .spec files several years ago but is not involved anymore. He added this patch: https://build.opensuse.org/package/view_file/home:stroeder:branches:network… This patch seems to fail now (see below). I'm inclined to remove it but I wonder whether it might be still needed/useful today. Ciao, Michael. ------------------------ snip ------------------------ [ 85s] configure:20167: cc -c -Wno-format-extra-args -fno-strict-aliasing -DSLAP_CONFIG_DELETE -DSLAP_SCHEMA_EXPOSE -DLDAP_COLLECTIVE_ATTRIBUTES conftest.c >&5 [ 85s] configure:20167: $? = 0 [ 85s] configure:20189: result: 6 [ 85s] configure:20204: checking number of arguments of gethostbyaddr_r [ 85s] configure:20229: cc -c -Wno-format-extra-args -fno-strict-aliasing -DSLAP_CONFIG_DELETE -DSLAP_SCHEMA_EXPOSE -DLDAP_COLLECTIVE_ATTRIBUTES conftest.c >&5 [ 85s] conftest.c: In function 'main': [ 85s] conftest.c:139:43: warning: passing argument 7 of 'gethostbyaddr_r' from incompatible pointer type [-Wincompatible-pointer-types] [ 85s] alen, AF_INET, &hent, buffer, bufsize, &h_errno); [ 85s] ^ [ 85s] In file included from conftest.c:129:0: [ 85s] /usr/include/netdb.h:172:12: note: expected 'struct hostent ** restrict' but argument is of type 'int *' [ 85s] extern int gethostbyaddr_r (const void *__restrict __addr, __socklen_t __len, [ 85s] ^ [ 85s] conftest.c:138:9: error: too few arguments to function 'gethostbyaddr_r' [ 85s] (void)gethostbyaddr_r( (void *)&(add.s_addr), [ 85s] ^ [ 85s] In file included from conftest.c:129:0: [ 85s] /usr/include/netdb.h:172:12: note: declared here [ 85s] extern int gethostbyaddr_r (const void *__restrict __addr, __socklen_t __len, [ 85s] ^ [ 85s] configure:20229: $? = 1 [ 85s] configure: failed program was: [ 85s] | /* confdefs.h */

2 2

Re: OpenLDAP 2.4.41 available
by Clément OUDOT 02 Jul '15

02 Jul '15

Hi, congratulations for the release! It seems the changelog has not been updated on this page: http://www.openldap.org/software/release/changes.html Clément. 2015-07-01 22:11 GMT+02:00 OpenLDAP Project <project(a)openldap.org>: > OpenLDAP 2.4.41 is now available for download as detailed on our download > page: > > http://www.openldap.org/software/download/ > > and should soon be available on all official mirrors: > > ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS > > This is a maintenance release and is made available for general use. Users > of OpenLDAP Software are encouraged to upgrade. > > > Significant contributors are: > > Howard Chu (Symas Corp) > Hallvard Furuseth (University of Oslo) > Quanah Gibson-Mount (Zimbra, Inc) > Ryan Tandy > > > OpenLDAP 2.4.41 Release (2015/06/21) > Fixed ldapsearch to explicitly flush its buffer (ITS#8118) > Fixed libldap async connections (ITS#8090) > Fixed libldap double free of request during abandon (ITS#7967) > Fixed libldap error string for LDAP_X_CONNECTING (ITS#8093) > Fixed libldap segfault in ldap_sync_initialize (ITS#8001) > Fixed libldap ldif-wrap off by one error (ITS#8003) > Fixed libldap handling of TLS in async mode (ITS#8022) > Fixed libldap null pointer dereference (ITS#8028) > Fixed libldap mutex handling with LDAP_OPT_SESSION_REFCNT (ITS#8050) > Fixed slapd slapadd config db import of minimal frontend entry > (ITS#8150) > Fixed slapd slapadd onetime leak with -w (ITS#8014) > Fixed slapd sasl auxprop crash with invalid config (ITS#8092) > Fixed slapd syncrepl delta-mmr issue with overlays and slapd.conf > (ITS#7976) > Fixed slapd syncrepl mutex for cookie state (ITS#7968) > Fixed slapd syncrepl memory leaks (ITS#8035) > Fixed slapd syncrepl to free presentlist at end of refresh mode > (ITS#8038) > Fixed slapd syncrepl to streamline presentlist (ITS#8042) > Fixed slapd syncrepl concurrency when CHECK_CSN is enabled (ITS#8120) > Fixed slapd rootdn checks for hidden backends (ITS#8108) > Fixed slapd segfault when using matched values control (ITS#8046) > Fixed slapd-ldap reconnection behavior on remote failure (ITS#8142) > Fixed slapd-mdb minor case typo (ITS#8049) > Fixed slapd-mdb one-level search (ITS#7975) > Fixed slapd-mdb heap corruption (ITS#7965) > Fixed slapd-mdb crash after deleting in-use schema (ITS#7995) > Fixed slapd-mdb minor code cleanup (ITS#8011) > Fixed slapd-mdb to return errors when using incorrect env flags > (ITS#8016) > Fixed slapd-mdb to correctly update search candidates (ITS#8036, > ITS#7904) > Fixed slapd-mdb when there were more than 65535 aliases in scope > (ITS#8103) > Fixed slapd-mdb alias deref when objectClass is not indexed > (ITS#8146) > Fixed slapd-meta TLS initialization with ldaps URIs (ITS#8022) > Fixed slapd-meta to have better error logging (ITS#8131) > Fixed slapd-perl conversion to cn=config (ITS#8105) > Fixed slapd-sql autocommit config variable (ITS#8129,ITS#6613) > Fixed slapo-collect segfault (ITS#7797) > Fixed slapo-constraint with 0 count constraint (ITS#7780,ITS#7781) > Fixed slapo-deref with empty attribute list (ITS#8027) > Fixed slapo-memberof to correctly reject invalid members (ITS#8107) > Fixed slapo-sock result parser for CONTINUE (ITS#8048) > Fixed slapo-syncprov synprov_matchops usage of test_filter (ITS#8013) > Fixed slapo-syncprov segfault on disconnect/abandon > (ITS#5452,ITS#8012) > Fixed slapo-syncprov memory leak (ITS#8039) > Fixed slapo-syncprov segfault on disconnect/abandon (ITS#8043) > Fixed slapo-syncprov deadlock when autogroup is in use (ITS#8063) > Fixed slapo-syncprov potential loss of changes when under load > (ITS#8081) > Fixed slapo-unique enforcement of uniqueness with manageDSAit control > (ITS#8057) > Build Environment > Fixed libdb detection with gcc 5.x (ITS#8056) > Fixed ftello reference for Win32 (ITS#8127) > Enhanced contrib modules build paths (ITS#7782) > Fixed contrib/autogroup internal operation identity > (ITS#8006) > Fixed contrib/autogroup to skip internal ops with accesslog > (ITS#8065) > Fixed contrib/passwd/sha2 compiler warning (ITS#8000) > Fixed contrib/noopsrch compiler warning (ITS#7998) > Fixed contrib/dupent compiler warnings (ITS#7997) > Test suite: Added vrFilter test (ITS#8046) > Contrib > Added pbkdf2 sha256 and sha512 schemes (ITS#7977) > Fixed autogroup modification callback responses (ITS#6970) > Fixed nssov compare with usergroup (ITS#8079) > Fixed nssov password change behavior (ITS#8080) > Fixed nssov updated to 0.9.4 (ITS#8097) > Documentation > Added ldap_get_option(3) LDAP_FEATURE_INFO_VERSION > information (ITS#8032) > Added ldap_get_option(3) LDAP_OPT_API_INFO_VERSION > information (ITS#8032) > Fixed slapd-config(5), slapd.conf(5) tls_cipher_suite option > (ITS#8099) > Fixed slapd-meta(5), slapd-ldap(5) tls_cipher_suite option > (ITS#8099) > Fixed slapd-meta(5) fix minor typo (ITS#7769) > > > MD5 (openldap-2.4.41.tgz) = 3f1a4cea52827e18feaedfdc1634b5d0 > SHA1 (openldap-2.4.41.tgz) = c6880df9fec928a5f010b78a4285b497e8a12d6b > >

2 2

unbind requests to all backends?
by Michael Ströder 01 Jul '15

01 Jul '15

HI! Are unbind requests always propagated to all backends? Ciao, Michael.

2 1

back-sock: Format of RESULT
by Michael Ströder 27 Jun '15

27 Jun '15

HI! I'm really confused by this part of slapd-sock(5): ----------------------------- snip ----------------------------- If the overlay is configured to send response messages to the external program, they will appear as an extended RESULT message or as an ENTRY message, defined below. The RESULT message is similar to the one above, but also includes the msgid and any configured extensions: RESULT msgid: <message id> code: <integer> matched: <matched DN> info: <text> <blank line> Typically both the msgid and the connid will be needed to match a result message to a request. The ENTRY message has the form ENTRY msgid: <message id> <entry in LDIF format> <blank line> ----------------------------- snip ----------------------------- Especially the wording "both the msgid and the connid will be needed" seems logical to me but does not match any format description in the man-page. I'd also appreciate if the back-sock protocol would be more robust: Why not require connid and msgid consistently in *every* operation sock request and result sock request and *all* responses returned by the external listener even in CONTINUE? Ciao, Michael.

1 0

enhancements for back-sock, especially MONITOR
by Michael Ströder 26 Jun '15

26 Jun '15

HI! I'm currently working on implementing a generic back-sock listener in Python and two special instances of it. Mainly the current use-case is overlay usage intercepting bind requests. Of course I'd like to monitor the back-sock listeners (internal state like counters etc.), probably via LDAP ideally with access control enforced by slapd itself. Accessing the monitoring data could be done via search operations but I'd like to avoid mandating a generic "sockops search" overlay configuration just for monitoring data because every search request would be passed to the external listener even though the listener does not handle them (except for the monitoring data). I could add additional backends with own suffixes pointing to the same back-sock listener. But having two or three separate listeners would require configuring the same number of database sections. Also having to implement to much access control in the database listeners is also not ideal. It would be really nice if requests going to a back-sock listener configured as overlay could be pre-filtered by slapd configuration. Something like sockops search ldap:///cn=sock-listener-monitor,dc=example,dc=com??base?(objectClass=monitorSubEntry) Would pass the search request only to the external listener of the search operation matches all parameters in the given LDAP URL. This would be also handy for other operations. What do you think? Ciao, Michael. P.S.: These ITS would also improve back-sock (overlay) usage: (ITS#8172) RFE: back-sock CONTINUE to get modified parameters (ITS#8177) RFE: back-sock to receive controls (ITS#8178) back-sock: Timeout to avoid locking

1 0

Update/drop cruft: LDAP_DEPRECATED, CLDAP, C version
by Hallvard Breien Furuseth 21 Jun '15

21 Jun '15

Some wishes for RE25: Expose most LDAP_DEPRECATED functions again. This code is not going away, or it'd be gone by now after 16 years of deprecation. I usually #define LDAP_DEPRECATED anyway. What's the point of trying to make me pass 2 extra NULL args to a bunch of functions? And making a "SASL bind" function the proper way to do Simple Bind is silly and confusing. OTOH some depreciation make sense, like ldap_get_values() which returns char** instead of berval**. Add --enable-cldap as "experimental". Add tests and some fixes. The CLDAP code isn't going away either, so i seems better to support it properly. People are submitting libldap ITSes, but slapd and ldapsearch usage remain broken. slapd looks easy to fix, ldapsearch depends on vestiges of libldap code to ignore Bind requests. Dunno if I want to bother tracking that down in libldap or just omit the Bind in ldapsearch. Maybe RedHat has a fix. ...or do the opposite, kill LDAP_DEPRECATED and CLDAP. I hope not, but that's better than eternally deprecated/code-rotting features. Kill K&R1 support, i.e. the LDAP_P(()) stuff. Supposedly the headers support K&R1, but OpenLDAP-2.0 broke this (ITS#6171). Nobody has cared enough to fix it, and I refuse to fix it. See if we can require C99 to build OpenLDAP, but keep the headers C90-compliant. In particular, replace Debug() with a varargs macro, initially without changing the calls to Debug(). If we get away with that, we can kill the extra ,0,0,0 arguments to Debug() later so gcc -Wformat will catch missing/spurious args. -- Hallvard

3 4

slapd-sock: extensions always UTF-8
by Michael Ströder 19 Jun '15

19 Jun '15

HI! Are these extensions guaranteed to be always sent by back-sock as raw UTF-8 in one line? Or does the listener also has to handle base64 encoding and line-folding like in LDIF for these extension lines? binddn: <bound DN> peername: IP=<address>:<port> ssf: <SSF value> connid: <connection ID> Ciao, Michael.

1 0

Relaxed mode for delta-sync MMR
by Quanah Gibson-Mount 10 Jun '15

10 Jun '15

After having deployed delta-sync MMR at several customer sites, the general handling of conflict resolution in MMR mode is significantly sub optimal, and routinely causes the MMR nodes to get further out of sync, worsening things significantly (Mainly due to ITS#8125). The main issues I see are the following: a) Two masters get different change requests at approximately the same time to add a value X to an attribute. b) Two masters get different change requests at approximately the same time to delete a value X from an attribute. In these two specific cases, in relaxed mode, rather than falling back and re-syncing the entire database, I think the conflict should be discarded (skipped), and logged as such. I.e., there is no actual discrepancy in the object. It still has X present in the add case, and X gone in the delete case. At best, if we're going to do fallback, then we should only see about resyncing the specific entry. The overall behavior I'm seeing from OpenLDAP is the masters get in an endless cycle of re-sync, and the more they do so, the more out of sync they become, leading to a point at which you have to stop all masters, export all their DBs, sort them, find missing entries between all sets of masters, and build a brand new DB with which to reload them, until they get massively out of sync again. I.e., the current strategy of resync is doing no favors to anyone. It may work OK on very small DBs, where a resync only takes seconds, but on larger dbs were such syncs take 30+ minutes to hours, it is not a useful methodology. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Infinite loop with "mdb_search: 124xxxx1 scope not okay" while adding an entry
by Benjamin Dauvergne 02 Jun '15

02 Jun '15

Hi, I'm using OpenLDAP debian package from wheezy-backports (version 2.4.31+really2.4.40+dfsg) which is a 2.4.40 but backported I think under another version number to allow the jessie package to execute its migration when upgrade time will come. When trying to initialize a new DB by loading an LDIF file using ldapvi, looking like that: add dc=coin2,dc=fr objectClass: organization objectClass: dcObject objectClass: eduOrg objectClass: supannOrg dc: coin2 o: whatever supannEtablissement: {UAI}ccc add ou=people,dc=coin2,dc=fr objectClass: organizationalUnit ou: people add uid=admin,ou=people,dc=coin2,dc=fr objectClass: inetOrgPerson objectClass: eduPerson objectClass: supannPerson uid: admin cn: Administrateur annuaire displayName: Administrateur annuaire givenName: Administrateur sn: annuaire supannListeRouge: TRUE userPassword: xxxx supannEtablissement: {UAI}COIN It blocks on adding the ou=people. After setting loglever to 255 I got my syslog filled with such messages, soon filling the virtual machine virtual disk: Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 1 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 2 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 3 scope not okay etc... The log of the query finishing like that is: Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_get(15) Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_get(15): got connid=1001 Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_read(15): checking for input on id=1001 Jun 2 02:34:26 ldap1-psl slapd[12159]: op tag 0x68, time 1433205266 Jun 2 02:34:26 ldap1-psl slapd[12159]: conn=1001 op=9 do_add Jun 2 02:34:26 ldap1-psl slapd[12159]: conn=1001 op=9 do_add: dn (ou=people,dc=coin2,dc=fr) Jun 2 02:34:26 ldap1-psl slapd[12159]: >>> dnPrettyNormal: <ou=people,dc=coin2,dc=fr> Jun 2 02:34:26 ldap1-psl slapd[12159]: <<< dnPrettyNormal: <ou=people,dc=coin2,dc=fr>, <ou=people,dc=coin2,dc=fr> Jun 2 02:34:26 ldap1-psl slapd[12159]: ==> unique_add <ou=people,dc=coin2,dc=fr> Jun 2 02:34:26 ldap1-psl slapd[12159]: ==> unique_search (|(objectClass=organizationalUnit)(ou=people)) Jun 2 02:34:26 ldap1-psl slapd[12159]: str2filter "(|(objectClass=organizationalUnit)(ou=people))" Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter Jun 2 02:34:26 ldap1-psl slapd[12159]: OR Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter_list Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter Jun 2 02:34:26 ldap1-psl slapd[12159]: EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0 Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter Jun 2 02:34:26 ldap1-psl slapd[12159]: EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0 Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter_list Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_search Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_dn2entry("dc=coin2,dc=fr") Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_dn2id("dc=coin2,dc=fr") Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_dn2id: got id=0x1 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_entry_decode: Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_entry_decode Jun 2 02:34:26 ldap1-psl slapd[12159]: => access_allowed: search access to "dc=coin2,dc=fr" "entry" requested Jun 2 02:34:26 ldap1-psl slapd[12159]: <= root access granted Jun 2 02:34:26 ldap1-psl slapd[12159]: => access_allowed: search access granted by manage(=mwrscxd) Jun 2 02:34:26 ldap1-psl slapd[12159]: search_candidates: base="dc=coin2,dc=fr" (0x00000001) scope=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011OR Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_list_candidates 0xa1 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (objectClass) Jun 2 02:34:26 ldap1-psl slapd[12159]: => key_read Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_idl_fetch_key: [b49d1940] Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_index_read: failed (-30798) Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: id=0, first=0, last=0 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=0 first=0 last=0 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011OR Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_list_candidates 0xa1 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (objectClass) Jun 2 02:34:26 ldap1-psl slapd[12159]: => key_read Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_idl_fetch_key: [9bee355f] Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_index_read: failed (-30798) Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: id=0, first=0, last=0 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=0 first=0 last=0 Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (ou) Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: (ou) not indexed Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_list_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_list_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search_candidates: id=-1 first=1 last=-1 Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 1 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 2 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 3 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 4 scope not okay Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 5 scope not okay etc... I don't know why it's doing a search on an add but seeing the message "(ou) not indexed" I though that maybe adding an equality index on this attribute would help, and effectively it did. Now the add ou=people passed, but it started looping again when adding the uid=admin entry. The infinite loop happen in server/slapd/back-mdb/search.c in mdb_search(). If you have any idea I can continue investigating or add debug logs. The debian package has the following patches applied over openldap 2.4.40: add-tlscacert-option-to-ldap-conf autogroup-makefile contrib-modules-use-dpkg-buildflags do-not-second-guess-sonames evolution-ntlm fix-build-top-mk getaddrinfo-is-threadsafe heimdal-fix index-files-created-as-root ITS6035-olcauthzregex-needs-restart.patch ITS7975-fix-mdb-onelevel-search.patch ITS8027-deref-reject-empty-attr-list.patch ITS8046-fix-vrFilter_free-crash.patch lastbind-makefile ldap-conf-tls-cacertdir ldapi-socket-place libldap-symbol-versions man-slapd no-AM_INIT_AUTOMAKE no-bdb-ABI-second-guessing pw-sha2-makefile sasl-default-path slapi-errorlog-file smbk5pwd-makefile switch-to-lt_dlopenadvise-to-get-RTLD_GLOBAL-set.diff wrong-database-location

1 2

Does a LMDB database file ever shrink, after row deletion, if so when?
by Tinker 23 May '15

23 May '15

Hi! Is there any mechanism in LMDB to give back disk space after some particular amount of row deletion, how does this work, if not are there any plans for it now? If there's not, as a user I need 2x disk space and some mechanism to be able to migrate, so automatic shrinking would be a great thing. Thanks!! Tinker

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel