openldap-technical September 2008

openldap-technical@openldap.org

54 participants
58 discussions

Check errors from Jexplore!
by Nguyen Quang Huy 10 Sep '08

10 Sep '08

Hi all! Im Setup Openldapv2.x, Im setup following guide: http://www.linuxmail.info/openldap-setup-howto/ Im connect from Jexplore to Openldap --> OK, I can open no-ip..vv, but I open org --> error appear: Im dont know check location.. Help me! ************************************************* Nguyen Quang Huy Add: Tang 4 - Trung Tâm Tin Hoc So 8 Le Thai To - Hoan Kiem - Ha Noi Mob: 0914-257-830 Tel: 04-9288858 ext 425 Fax: + 84 4 928 9213 Email: <mailto:quanghuy@vpb.com.vn> quanghuy(a)vpb.com.vn LinQ: <mailto:kquanghuy@web.vpb.com.vn> quanghuy(a)web.vpb.com.vn

2 1

Problem With postfix
by LITLE TUX 09 Sep '08

09 Sep '08

Hi peoples .... i'm tryng configure openldap with postfix but qhen try add the below entry i receive next error: gheorghe:~/difs # ldapadd -f base.ldif -x -D cn=Administrator,dc=domain,dc=com-w 123456 adding new entry "relativeDomainName=@, ou=dns,dc=domain,dc=com" ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax My ldif file: dn: relativeDomainName=@, ou=dns,dc=domain,dc=com objectClass: dNSZone relativeDomainName: @ zoneName: domain.com dNSTTL: 3600 dNSClass: IN sOARecord: ns3.domain.com. administrator.domain.com. 2001030201 3600 1800 604800 86400 nSRecord: ns3.domain.com. mXRecord: 30 mail.domain.com. My include schemas: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/qmail.schema include /etc/openldap/schema/postfix.schema Any help is welcome...!!!! Best Regards!

3 2

Help: Slow LDAP search with high %iowait
by Victor 08 Sep '08

08 Sep '08

Hi , I did quite a bit reading and research before I send email to this list for help. If I have missed some basic concepts here, please execuse my ignorance. Thanks for your help and time in advance. 1. Summary The initial search in my prototyping with OpenLDAP (slapd + BDB) seemed to be slow. What is the reason and How could I fix it? 2. Configuration 2.1 Environment Linux CentOS, 1 hard disk (therefore unfortunately the BDB transaction logs and database files are written to the same disk), 120GB disk space (80% unused), 1GB RAM, reserved for this prototyping, OpenLDAP 2.3.39 with default BDB installation 2.2 slapd.conf (modified trivially for discussion purpose) # global configuration loglevel 0 # BDB database bdb suffix "dc=test,dc=dummy,dc=com" rootdn "cn=Manager,dc=test,dc=dummy,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data #Other DB configuration idlcachesize 60000 cachesize 20000 # Indices to maintain # the indexes are to support search in first name, last name and email for both exact match and wild cards in the end index objectClass eq index gn pres,eq,sub index sn pres,eq,sub index mail pres,eq,sub 2.3 DB_CONFIG (for BDB) set_cachesize 0 52428800 1 set_lg_bsize 2097512 set_flags DB_LOG_AUTOREMOVE set_lg_regionmax 262144 2.4 Data setup 2 million records (users with gn, sn, email, mobile, street address, etc. in the BDB; all records are indexed using the index in the above slapd.conf; grouped by the first character of lastName. For example, dn: ou=Z,dc=test,dc=dummy,dc=com objectclass: organizationalUnit ou: Z Sample LDIF entry: #Directory Entry dn: uid=ABCDEFGHIJKLMNOPQRSTUVWXYZ123459,ou=F,dc=test,dc=dummy,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: ABCDEFGHIJKLMNOPQRSTUVWXYZ123459 ...... (details omitted) 3. Symptom/Problem It was very slow in the first (fresh) search if I searched by wildcard firstname only like "Larry*" (which returned 478 entries/users). The response time was generally higher than 5 seconds Depending the count of records found, the response time might exceed 20 or even 50 seconds. During the search, the "iostat" result showed +95% %iowait, await was much higher that svctm, the device %util was over 96%. Here is the "iostat" output: Time: 10:51:34 AM avg-cpu: %user %nice %sys %iowait %idle 3.10 0.00 1.40 95.50 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util hda 0.00 2.90 64.94 65.33 1322.68 580.22 661.34 290.11 14.61 51.99 343.51 7.44 96.92 dm-0 0.00 0.00 64.94 72.53 1322.68 580.22 661.34 290.11 13.84 55.44 330.62 7.06 96.99 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 However, The subsequent search (using the exact search criteria) is much faster (within 200ms). I believe it is because of the cache. I did a "db_stat -m" check and saw +90% cache hit rate (I guess it is normal?). The detailed output is in the attachment. 4. Questions The "iostat" output showed obvious I/O bottleneck. Assuming I can't upgrade my hardware (for example, adding another disk specifically for writing transaction logs to), assuming I won't set a limit to the max number of entried returned, is there anything else I can do (typically BDB/slapd tuning or configuration) to make the fresh/first search much faster (say within 2 seconds for the worst case)? Did I do anything wrong? Please advise. Thanks a lot! Vic

1 0

AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Hauke Coltzau 08 Sep '08

08 Sep '08

Hi Quanah, thanks again for your answer. > Did you make sure the GSSAPI module was installed with Cyrus-SASL? IIRC, > it's a separate package under Ubuntu. > > p libgssapi2-heimdal > - Heimdal Kerberos - GSSAPI support library > p libsasl2-modules-gssapi-heimdal > - Pluggable Authentication Modules for SASL (GSSAPI) > p libsasl2-modules-gssapi-mit > - Cyrus SASL - pluggable authentication modules (GSSAPI) ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\ Cyrus SASL - pluggable authentication module > > (b) saslauthd and SASL/GSSAPI are unrelated. I.e., you don't need to be > > running saslauthd for SASL/GSSAPI to work. > > Now I'm confused. I always understood the way to use > > Kerberos authentication for accessing the ldap directory > > to be: > > > > LDAP->SASL->Kerberos > > > > and that I have to fill the SASL part with something real, > > like saslauthd. What did I miss here? > > SASL/GSSAPI uses the existing Kerberos ticket to auth a user to LDAP > > When using saslauthd, you do a simple bind to the LDAP server, which then > connects to the KDC, gets a ticket, and auths the user. > > Two very different things. I.e., the first, the user already has authed to > the KDC. In the second, they haven't. I see the difference, but still have some questions: - In the first approach, the user already has a TGT and asks the KDC for a "ldap/fqdn@REALM-ticket"? This is done by ldapsearch, not by slapd? Hence, slapd "only" needs access to its keytab to be able to decrypt the clients messages? - And in the second one, the user provides username and password (plain), slapd converts the username into a principle (user@REALM) and forwards this to saslauthd? So this should be secured via TLS? I'm just looking for a setup that restricts access to LDAP to authenticated users (except, of course, information neccessary for authentication purposes). I need to use Kerberos for authentication, because I want to use NFSv4. There used to be a well-known howto for all this at http://www.bayour.com/LDAPv3-HOWTO.html but the site is offline for some days now. Thanks again for your help, Hauke --

1 0

AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Hauke Coltzau 08 Sep '08

08 Sep '08

Hi Quanah, thank you for your immediate reply. (a) Which Kerberos implementation are you using? MIT Kerberos 5 as shipped with Hardy (1.6.dfsg.3~beta1-2ubuntu1) (b) saslauthd and SASL/GSSAPI are unrelated. I.e., you don't need to be running saslauthd for SASL/GSSAPI to work. Now I'm confused. I always understood the way to use Kerberos authentication for accessing the ldap directory to be: LDAP->SASL->Kerberos and that I have to fill the SASL part with something real, like saslauthd. What did I miss here? Thanks again, Hauke p.s.: ZCS fan here ;-) --

2 1

Simple binds with SASL/GSSAPI (Resource temporarily unavailable)
by Hauke Coltzau 08 Sep '08

08 Sep '08

Hi all, I have a problem to make simple binds with authentication done by kerberos5. I use OpenLDAP to store all user account information and have everything set up so far that users can login: $ su - testuser Password: $ klist Ticket cache: FILE:/tmp/krb5cc_2000_yukVIJ Default principal: testuser@REALM Valid starting Expires Service principal 09/08/08 16:54:16 09/09/08 02:54:16 krbtgt/REALM@REALM renew until 09/09/08 16:54:16 Kerberos 4 ticket cache: /tmp/tkt2000 klist: You have no tickets cached $ id uid=2000(testuser) gid=2000(dusers) groups=2000(dusers) uid, gid,etc. have been successfully taken from the LDAP directory. But then, ldapsearch fails: $ ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) $ Details: ======== Currently, the KDC and the LDAP-Server reside on the same host, running Ubuntu 8.04 x64_64. I made sure that principals exist for <fqdn>@REALM ldap/<fqdn>@REALM host/<fqdn>@REALM and exported them to /etc/krb5.keytab as well as /etc/ldap/ldap.keytab, which is now owned by the openldap user. # ktutil ktutil: rkt /etc/krb5.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 6 ldap/<fqdn>@REALM 2 6 ldap/<fqdn>@REALM 3 4 host/<fqdn>@REALM 4 4 host/<fqdn>@REALM 5 4 <fqdn>@REALM 6 4 <fqdn>@REALM ktutil: ktutil: clear ktutil: rkt /etc/ldap/ldap.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 6 ldap/<fqdn>@REALM 2 6 ldap/<fqdn>@REALM 3 4 host/<fqdn>@REALM 4 4 host/<fqdn>@REALM 5 4 <fqdn>@REALM 6 4 <fqdn>@REALM # ll /etc/ldap/ldap.keytab -rw------- 1 openldap openldap 512 2008-09-08 15:23 /etc/ldap/ldap.keytab (Even tried 666, but that didn't change anything. If I move this file, slapd complains, so I'm pretty sure it's actually been used) Next, I set START=yes and MECHANISMS="kerberos5" in /etc/default/saslauthd, started saslauthd and tested: # testsaslauthd -u testuser -p <secret> 0: OK "Success." As recommended, I used sasl-sample-server and /-client to test the configuration SASSL/GSSAPI <-> Kerberos: # sasl-sample-client -s ldap -m GSSAPI -n <fqdn> (partial output) service=ldap Waiting for mechanism list from server... Forcing use of mechanism GSSAPI Choosing best mechanism from: GSSAPI Using mechanism GSSAPI Preparing initial. Sending initial response... C: .... ... Username: testuser@REALM SSF: 56 Waiting for encoded message... recieved decoded message 'srv message 1' sending encrypted message 'client message 1' On the sample-server side, it's the same, 'client message 1' was successfully decoded. Next thing I did was to add following lines to /etc/ldap/slapd.conf sasl-secprops noplain,noactive,noanonymous sasl-regexp uid=(.*),cn=<domain>,cn=gssapi,cn=auth ldap:///dc=...??sub?uid=$1 sasl-regexp uid=(.*),cn=<domain>,cn=gssapi,cn=auth uid=$1,dc=... and created /usr/lib/sasl2/slapd.conf mech_list: gssapi digest-md5 cram-md5 external pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux keytab: /etc/ldap/ldap.keytab Then I chgrouped /var/run/saslauthd to openldap and gave g=rwx permissions to the directory: # ls -al /var/run/saslauthd/ total 0 drwxrwxr-x 2 root openldap 100 2008-09-08 16:36 . drwxr-xr-x 15 root root 580 2008-09-08 12:13 .. srwxrwxrwx 1 root root 0 2008-09-08 16:36 mux -rw------- 1 root root 0 2008-09-08 16:36 mux.accept -rw------- 1 root root 0 2008-09-08 16:36 saslauthd.pid.lock But now, when trying ldapsearch on the same machine, it fails: $ klist Ticket cache: FILE:/tmp/krb5cc_2000_tA7220 Default principal: testuser@REALM Valid starting Expires Service principal 09/08/08 16:33:05 09/09/08 02:33:05 krbtgt/REALM@REALM renew until 09/09/08 16:33:05 09/08/08 16:33:46 09/09/08 02:33:05 ldap/<fqdn>@REALM renew until 09/09/08 16:33:05 Kerberos 4 ticket cache: /tmp/tkt2000 klist: You have no tickets cached $ ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) $ And on the server side: # echo $KRB5_KTNAME /etc/ldap/ldap.keytab # slapd -d127 -h "ldap:///" -u openldap -g openldap ... >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=GSSAPI datalen=583 SASL [conn=0] Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable) send_ldap_result: conn=0 op=1 p=3 send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable)" send_ldap_response: msgid=2 tag=97 err=80 ber_flush2: 158 bytes to sd 13 ... and saslauthd is not contacted at all: # saslauthd -d -a kerberos5 saslauthd[7243] :main : num_procs : 5 saslauthd[7243] :main : mech_option: NULL saslauthd[7243] :main : run_path : /var/run/saslauthd saslauthd[7243] :main : auth_mech : kerberos5 saslauthd[7243] :ipc_init : using accept lock file: /var/run/saslauthd/mux.accept saslauthd[7243] :detach_tty : master pid is: 0 saslauthd[7243] :ipc_init : listening on socket: /var/run/saslauthd/mux saslauthd[7243] :main : using process model saslauthd[7244] :get_accept_lock : acquired accept lock saslauthd[7243] :have_baby : forked child: 7244 saslauthd[7243] :have_baby : forked child: 7245 saslauthd[7243] :have_baby : forked child: 7246 saslauthd[7243] :have_baby : forked child: 7247 <no more output> What did I do wrong this time ;-) ? Best regards, Hauke --

2 2

ldapadd of LDIF files with attribute 'apple-generateduid' not allowed [Resolved]
by Alexander Hartner 07 Sep '08

07 Sep '08

At it turns out the problem was with the objectClasses. I should have used : objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: extensibleObject Instead of objectClass: top objectClass: person objectClass: inetOrgPerson Adding the extra attributes to the objectClass resolved this problem. Thanks for all your help. Regards Alex On 21 Feb 2008, at 11:56, Alexander Hartner wrote: > I am trying to import a simple LDIF file into OpenDirectory on OS X > 10.5.2 Leopard Server. > > However when I issue the following ldapadd command I get an error : > > ldapadd -D [rootdn] -x -w [secretPassword] -f Import.ldif > > Error : 65 Object class violation" > attribute 'apple-generateduid' not allowed > > > I would have thought that I had specified apple-generateduid, but I > didn't. > > This is my import file > -----------BEGIN----------- > # Alexander Hartner > dn: cn=Alexander Hartner2,cn=people,dc=macbook-znet,dc=local > objectClass: top > objectClass: person > objectClass: inetOrgPerson > displayName: Alexander Hartner2 > cn: Alexander Hartner2 > givenName: Alexander > sn: Hartner > mail: alex(a)j2anywhere.com > initials: A > o: j2anywhere.com > -----------END----------- > > I know this might not be the best forum for OS X support, but I am a > bit stuck on this. > Thanks in advance. > Alex > > >

2 2

anish_patil wants to keep up with you on Twitter
by anish_patil 07 Sep '08

07 Sep '08

To find out more about Twitter, visit the link below: http://twitter.com/i/6de68cfefa92375374ca938a55b8e865fa2162ab Thanks, -The Twitter Team About Twitter Twitter is a unique approach to communication and networking based on the simple concept of status. What are you doing? What are your friends doing—right now? With Twitter, you may answer this question over SMS, IM, or the Web and the responses are shared between contacts. This message was sent by a Twitter user who entered your email address. If you'd prefer not to receive emails when other people invite you to Twitter, click here: http://twitter.com/i/optout/dd31dad00025fa765c3307138c272038991bea18

1 0

Re: RHEL 5 will not do TLS/SSL authentication
by Dat Duong 05 Sep '08

05 Sep '08

Does anyone have the answer to my problem? thanks ----- Original Message ---- From: Dat Duong <datduong2000(a)yahoo.com> To: Buchan Milne <bgmilne(a)staff.telkomsa.net> Cc: openldap-technical(a)openldap.org Sent: Wednesday, September 3, 2008 7:45:45 AM Subject: Re: RHEL 5 will not do TLS/SSL authentication The slapd.conf is on Solaris 10 machine. This is how I compiled from the source for Openssl and Openldap. #cd openssl.0.98h # ./config shared # make clean # make # make install # cd openldap-2.4.11 # env LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:/usr/local/BerkeleyDB.4.2/lib:/usr/local/ssl/lib" LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.2/lib -R/usr/local/ssl/lib" CPPFLAGS="-I/usr/local/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/include" ./configure --enable-bdb --enable-crypt --with-tls --without-cyrus-sasl # make depend # make clean ----- Original Message ---- From: Buchan Milne <bgmilne(a)staff.telkomsa.net> To: Dat Duong <datduong2000(a)yahoo.com> Cc: openldap-technical(a)openldap.org Sent: Wednesday, September 3, 2008 5:17:14 AM Subject: Re: RHEL 5 will not do TLS/SSL authentication On Wednesday 03 September 2008 09:49:54 Dat Duong wrote: > I'm thinking, if the gnutls which installed by default, was causing the > problem?? It doesn't matter if gnutls is installed, what matters is what OpenLDAP was compiled against. Now, you stated that you are using RHEL 5, and gave no other details of what software you installed, so it would be logical to assume you are using only the RHEL 5 packages. On RHEL 5, OpenLDAP 2.3.27 is compiled against openssl 0.9.8b. But, since you have some weird paths reflected in your slapd.conf etc., maybe you have built your own software. If you have, you need to supply the details thereof, or we are all wasting our time. Regards, Buchan

1 0

Re: Help needed to set up N-way multimaster replication
by piyush joshi 04 Sep '08

04 Sep '08

I have added serverid 1 to first server and serverid 2 to secondserver and rid=001 with syncrepl on both the server also added mirrormode true on both node but now when i make changes to one server that is not reflected to another one while before adding mirrormode true whenever i was trying to make changes in dir it gives me error [ Sep 4 10:18:39 mail slapd[20141]: conn=5 op=1 RESULT tag=103 err=53 text=shadow context; no update referral ] So now no idea where I am wrong. Please help me ... On Wed, Sep 3, 2008 at 6:25 PM, Miguel Jinez <miguel.jinez(a)gmail.com> wrote: > Hello, maybe try with a mirrormode line, look the comments in red > > Migue > > 2008/9/3 piyush joshi <joy.piyush(a)gmail.com> > > >> *Dear All,* >> *I am using openldap-2.4.11 version and trying to use >> N-way multimaster replication so that changes made to first server reflects >> to second and* *vice versa but with my current set up if i use syncprov >> overlay and syncrepl on both server then it doesn't allow me to make changes >> in any ldap server but if i configure syncprov overlay on one server and >> configure syncrepl on another server it allow me to make changes and as well >> reflect the changes to another however still i can't make changes to second >> ldap server my both server configuration is as follows. please let me know >> what is wrong with this configuration or what all changes to be made >> to running it.* >> >> Configuration on First LDAP Server >> >> allow bind_v2 >> include /usr/local/openldap/etc/openldap/schema/core.schema >> include /usr/local/openldap/etc/openldap/schema/corba.schema >> include /usr/local/openldap/etc/openldap/schema/cosine.schema >> include /usr/local/openldap/etc/openldap/schema/nis.schema >> include >> /usr/local/openldap/etc/openldap/schema/inetorgperson.schema >> pidfile /usr/local/openldap/var/run/slapd.pid >> argsfile /usr/local/openldap/var/run/slapd.args >> modulepath /usr/local/openldap/libexec/openldap >> moduleload syncprov >> password-hash {SSHA} >> database hdb >> suffix "dc=***,dc=com" >> rootdn "cn=root,dc=***,dc=com" >> rootpw {SSHA}yZkqhHmELfmUTsaQyfxgXBqq95gugTA4 >> directory /usr/local/openldap/var/openldap-data >> index uid pres,eq >> index cn,sn pres,eq,approx,sub >> index objectClass eq >> index entryCSN,entryUUID eq >> syncrepl rid=001 >> provider=ldap://192.168.1.12 >> type=refreshAndPersist >> retry="5 5 300 +" >> searchbase="dc=***,dc=com" >> attrs=* >> binddn="cn=root,dc=***,dc=com" >> credentials=secret >> > mirrormode true > > >> overlay syncprov >> syncprov-checkpoint 50 10 >> database monitor >> loglevel 256 >> >> >> Configuration on Second LDAP Server >> >> allow bind_v2 >> include /usr/local/openldap/etc/openldap/schema/core.schema >> include /usr/local/openldap/etc/openldap/schema/corba.schema >> include /usr/local/openldap/etc/openldap/schema/cosine.schema >> include /usr/local/openldap/etc/openldap/schema/nis.schema >> include >> /usr/local/openldap/etc/openldap/schema/inetorgperson.schema >> pidfile /usr/local/openldap/var/run/slapd.pid >> argsfile /usr/local/openldap/var/run/slapd.args >> >> modulepath /usr/local/openldap/libexec/openldap >> moduleload syncprov >> password-hash {SSHA} >> >> database hdb >> suffix "dc=***,dc=com" >> rootdn "cn=root,dc=***,dc=com" >> rootpw {SSHA}9nbNE9l1rTvPCoU95zgo6vVoL3nMRzMI >> directory /usr/local/openldap/var/openldap-data >> index uid pres,eq >> index cn,sn pres,eq,approx,sub >> index objectClass eq >> index entryCSN,entryUUID eq >> syncrepl rid=001 >> provider=ldap://192.168.1.8 >> type=refreshAndPersist >> retry="5 5 300 +" >> searchbase="dc=***,dc=com" >> attrs=* >> binddn="cn=root,dc=***,dc=com" >> credentials=secret >> mirrormode true >> > > >> overlay syncprov >> syncprov-checkpoint 50 10 >> database monitor >> loglevel 256 >> >> >> Thanks Regards >> >> Piyush Joshi >> 9415414376 >> >> >> >> >> >> > > -- Regards Piyush Joshi 9415414376

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2008