openldap-technical

openldap-technical@openldap.org

17 participants
9883 discussions

Re: [EXT] Re: Q: lastbind, pwdLastSuccess, and authTimestamp
by Ondřej Kuzník 06 May '25

06 May '25

On Mon, May 05, 2025 at 08:00:42AM +0000, Windl, Ulrich wrote: > And "core lastbind" means the "lastbind" module? Starting with 2.5 there are two "lastbind" implementations: - the old contrib/ overlay - OpenLDAP's own (what I mean by "core") implementation that doesn't require an overlay > From a user's perspective it's hard to tell why the "lastbind" module > would be "core" while "policy" module would not (if I undertood it > correctly). > Is it due to the progress of standardization? No it is just to make it possible to implement the latest ppolicy drafts. AFAIR the contrib/ overlay was incapable of this. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Message "slapd[2734]: config error processing olcDatabase={0}config,cn=config: <olcMultiProvider> database is not a shadow"
by Windl, Ulrich 29 Apr '25

29 Apr '25

Hi! While setting up an OpenLDAP-2.5-based MMR configuration I had set up the master node, then dumped the config database, copied the LDIF to the other node. However when starting slapd, it failed with the message slapd[2734]: config error processing olcDatabase={0}config,cn=config: <olcMultiProvider> database is not a shadow See also https://stackoverflow.com/q/6792212/6607497 The context of olcMultiProvider is: dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config ... olcMultiProvider: TRUE On the first node I had updated the config using this LDIF: dn: olcDatabase=${db},cn=config changetype: modify delete: olcMirrorMode olcMirrorMode: TRUE - add: olcMultiProvider olcMultiProvider: TRUE So I don't understand why this won't work on the second node. Specifically I can restart the first node without an issue. The only difference is that the primary node has a patch against crashing on an invalid olcAuthzRegexp (I had reported). Well can anybody explain what this message means? Update: Reading https://www.openldap.com/lists/openldap-technical/201807/msg00051.html ("Do you have a unique olcServerID set in cn=config for both masters")I realized that I forgot to specify "-S SID" for slapadd. Unfortunately even after using option -S, the error message remains the same. Kind regards, Ulrich Windl

2 3

Q: odd accesslog entry and unchanged attributes
by Windl, Ulrich 29 Apr '25

29 Apr '25

Hi! Debugging issues with my OpenLDAP configuration I inspected the changelog. One entry had some "odd" values (IMHO). Consider this example: dn: reqStart=20250423131324.000185Z,cn=audit objectClass: auditModify structuralObjectClass: auditModify reqStart: 20250423131324.000185Z reqEnd: 20250423131324.000188Z reqType: modify reqSession: 1024 reqAuthzID: cn=config reqDN: olcDatabase={4}mdb,cn=config reqResult: 0 reqMod: olcRootPW:= {SSHA256}REDACTED agNLQ== reqMod: entryCSN:= 20250423131324.377585Z#000000#005#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20250423131324Z reqOld: olcRootPW: REDACTED reqOld: entryCSN: 20250423131324.038419Z#000000#005#000000 reqOld: modifiersName: cn=config reqOld: modifyTimestamp: 20250423131324Z reqEntryUUID: 7b0b106c-b490-103f-8f46-3bae5e23549d entryUUID: 7b40af6a-b490-103f-8f7d-3bae5e23549d creatorsName: cn=audit createTimestamp: 20250423131324Z entryCSN: 20250423131324.377585Z#000000#005#000000 modifiersName: cn=audit modifyTimestamp: 20250423131324Z The change in entryCSN and modifyTimestamp are: OLD: 20250423131324.038419Z#000000#005#000000 NEW: 20250423131324.377585Z#000000#005#000000 OLD: 20250423131324Z NEW: 20250423131324Z So the change happened within the same second, and modifyTimestamp did not actually change. So the question is kind of philosophical: Are attibutes logged as changed when actually they did not change? This would apply to modifyTimestamp and modifyTimestamp in this case. Kind regards, Ulrich Windl

2 1

LDAP URI for slapcat -H
by Windl, Ulrich 29 Apr '25

29 Apr '25

Hi! After reading the manual of slapcat (for 2.5) it recommends using option -H and an URI instead of other obsolete options. So I tried it, but all I get is a usage message, even with "-v" and "-d9". Like this: # slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)' usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]] [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] However when I use # slapcat -H 'ldap://?entryCSN?dc=...,dc=de?sub?(objectClass=*)' I get output. The URI should be: scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]] Do I have tomatoes on my eyes? Anyway I think slapcat could provide a better error message. Even an ltrace did not enlighten me: # ltrace slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)?' ber_set_option(0, 0x8002, 0x55ad287ce980, 0x7f7d383ff680) = 0 ldap_pvt_thread_initialize(0x7f7d3862c1c0, 0x55ad287ce980, 32, 0x55ad287ce980) = 0 ldap_create(0x55ad287d6a78, 0, 0, 0) = 0 ldap_pvt_tls_set_option(0x55ad56df1a50, 0x6006, 0x7ffd5d8d1f6c, 48) = 0 strrchr("slapcat", '/') = nil strcmp("slapcat", "slapd") = -1 strcmp("slapcat", "slapadd") = 2 strcmp("slapcat", "slapcat") = 0 ldap_set_option(0, 0x5001, 0x55ad287d12d0, 0x7ffd5d8d2158) = 0 getopt(4, 0x7ffd5d8d2158, "a:b:cd:f:F:gH:l:n:o:s:v") = 100 __ctype_b_loc() = 0x7f7d384c1d60 strtoul(0x7ffd5d8d36a9, 0x7ffd5d8d1bb0, 0, 0) = 9 getopt(4, 0x7ffd5d8d2158, "a:b:cd:f:F:gH:l:n:o:s:v") = 72 ldap_url_parse_ext(0x7ffd5d8d36ae, 0x7ffd5d8d1cb0, 5, 0) = 10 __fprintf_chk(0x7f7d384004e0, 1, 0x55ad2877a9f0, 0x55ad2875c4ddusage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]]) = 88 fputs(" [-c]\n\t[-g] [-n databasenumber |"..., 0x7f7d384004e0 [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] ) = 1 exit(1 <no return ...> +++ exited (status 1) +++ Kind regards, Ulrich Windl

2 3

SBOM required!
by Sahil Sharma D 29 Apr '25

29 Apr '25

Hi team, Could you please provide the SBOM for OpenLDAP version REL_ENG_2_6_4 , or advise me on where I can locate the SBOMs for all versions? Regards, Sahil

2 1

MDB monitoring: How many free pages actually?
by Windl, Ulrich 25 Apr '25

25 Apr '25

Hi, Considering this monitoring information, I wonder: olmMDBPagesMax: 12800 olmMDBPagesUsed: 9229 olmMDBPagesFree: 3810 Is the number of actual free pages 12800 - 9229 + 3810, i.e. "unallocated (12800 - 9229)" plus "usable" (3810)? How many free pages are needed before updates stop working? Kind regards, Ulrich Windl

2 1

core dump when using olcSpSessionlogSource
by Windl, Ulrich 24 Apr '25

24 Apr '25

Hi! Configuring delta-syncrepl, I tried olcSpSessionlogSource instead of olcSPSessionlog. After slapd war started, it dumped core like this: … Apr 24 11:25:41 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix cn=config Apr 24 11:25:41 v05 slapd[5030]: conn=-1 op=0 syncprov_findcsn: mode=FIND_MAXCSN csn= Apr 24 11:25:41 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix dc=sap,dc=klinik,dc=uni-regensburg,dc=de Apr 24 11:25:41 v05 slapd[5030]: slapd starting Apr 24 11:25:41 v05 start[5017]: Starting ldap-server Apr 24 11:25:41 v05 systemd[1]: Started OpenLDAP Server Daemon. Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1000 op=1 generated new csn=20250424092541.888430Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a01217d0 20250424092541.888430Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a01217d0 20250424092541.888430Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5035]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1001 op=1 generated new csn=20250424092541.896113Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0122df0 20250424092541.896113Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: conn=1001 op=1 syncprov_checkpoint: running checkpoint Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0122df0 20250424092541.896113Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5037]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1002 op=1 generated new csn=20250424092541.900818Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0128240 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a012b820 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a012b820 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0128240 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5039]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1003 op=1 generated new csn=20250424092541.920778Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c106d00 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c107760 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c107760 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c106d00 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5041]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1004 op=1 generated new csn=20250424092541.937140Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c10c9f0 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c11c110 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c11c110 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c10c9f0 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5043]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1005 op=1 generated new csn=20250424092541.989098Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a012b920 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0107320 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0107320 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a012b920 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5044]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1006 op=1 generated new csn=20250424092542.004124Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a01277f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: index objectClass 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index entryCSN 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqEnd 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqResult 0x0004 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a02376f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a02376f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a01277f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 ldapmodify[5046]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1007 op=1 generated new csn=20250424092542.020297Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a010a230 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: index objectClass 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index entryCSN 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqEnd 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqResult 0x0004 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0117770 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0117770 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a010a230 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 ldapmodify[5048]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1008 op=1 generated new csn=20250424092542.036954Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0237570 20250424092542.036954Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix cn=changelog-0 Apr 24 11:25:42 v05 slapd[5030]: [71B blob data] Apr 24 11:25:42 v05 slapd[5030]: olcSpSessionlogSource: value #0: <olcSpSessionlogSource> failed startup (cn=changelog-0)! Apr 24 11:25:42 v05 systemd[1]: Started Process Core Dump (PID 5051/UID 0). Apr 24 11:25:42 v05 systemd-coredump[5052]: [🡕] Process 5030 (slapd) of user 1000 dumped core. Stack trace of thread 5034: #0 0x00007fd1b82a8dfc __pthread_kill_implementation (libc.so.6 + 0xa8dfc) #1 0x00007fd1b8257842 raise (libc.so.6 + 0x57842) #2 0x00007fd1b823f5cf abort (libc.so.6 + 0x3f5cf) #3 0x00007fd1b8240497 __libc_message.cold (libc.so.6 + 0x40497) #4 0x00007fd1b82b34b7 malloc_printerr (libc.so.6 + 0xb34b7) #5 0x00007fd1b82b5a69 _int_free (libc.so.6 + 0xb5a69) #6 0x00007fd1b82b81df free (libc.so.6 + 0xb81df) #7 0x00007fd1b8159bee n/a (syncprov.so + 0x3bee) #8 0x000056122f1a02ee overlay_destroy_one (slapd + 0xb82ee) #9 0x000056122f1156bd n/a (slapd + 0x2d6bd) #10 0x000056122f115fb0 n/a (slapd + 0x2dfb0) #11 0x000056122f19f533 overlay_op_walk (slapd + 0xb7533) #12 0x000056122f19f6be n/a (slapd + 0xb76be) #13 0x000056122f1319ad fe_op_add (slapd + 0x499ad) #14 0x000056122f1328d9 do_add (slapd + 0x4a8d9) #15 0x000056122f12b18f n/a (slapd + 0x4318f) #16 0x000056122f12b98d n/a (slapd + 0x4398d) #17 0x00007fd1b86bcda0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #18 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #19 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 5030: #0 0x00007fd1b82a3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007fd1b82a8b83 __pthread_clockjoin_ex (libc.so.6 + 0xa8b83) #2 0x000056122f1281ca slapd_daemon (slapd + 0x401ca) #3 0x000056122f10b88e main (slapd + 0x2388e) #4 0x00007fd1b8240e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007fd1b8240f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x000056122f10b90a _start (slapd + 0x2390a) Stack trace of thread 5038: #0 0x00007fd1b82a3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007fd1b82a6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007fd1b86bce40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 5032: #0 0x00007fd1b832e796 epoll_wait (libc.so.6 + 0x12e796) #1 0x000056122f12507b n/a (slapd + 0x3d07b) #2 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #3 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) ELF object binary architecture: AMD x86-64 Apr 24 11:25:42 v05 ldapmodify[5050]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 systemd[1]: slapd.service: Main process exited, code=dumped, status=6/ABRT Apr 24 11:25:42 v05 systemd[1]: slapd.service: Failed with result 'core-dump'. Apr 24 11:25:42 v05 systemd[1]: systemd-coredump(a)1-5051-0.service: Deactivated successfully. Looks a bit like a bad free() to me. I was adding the syncprov overlay with the accesslog DB being defined, but the accesslog overlay to set “olcAccessLogDB: cn=changelog-0” wasn’t done yet. The changelog-0 database may have contained outdated entries. Kind regards, Ulrich Windl

1 2

opt attribute oathHMACAlgorithm
by Stefan Kania 23 Apr '25

23 Apr '25

Hi to all, I would like to add the otp-attributes with the following LDIF: --------------- dn: ou=users,dc=example,dc=net changetype: modify add: objectClass objectClass: oathTOTPParams - add: oathOTPLength oathOTPLength: 6 - add: oathHMACAlgorithm oathHMACAlgorithm: 1.2.840.113549.2.11 - add: oathTOTPTimeStepPeriod oathTOTPTimeStepPeriod: 30 - add: oathTOTPTimeStepWindow oathTOTPTimeStepWindow: 3 --------------- But I'm getting: ----------- modifying entry "ou=users,dc=example,dc=net" ldap_modify: Invalid syntax (21) additional info: oathHMACAlgorithm: value #0 invalid per syntax ----------- If I switch to SHA1: ----------- oathHMACAlgorithm: 1.2.840.113549.2.7 ----------- it works. The manpage is telling me: ----------- oathHMACAlgorithm: <OID> The OID of the hash algorithm to use as defined in RFC 8018. Supported algorithms include SHA1, SHA224, SHA256, SHA384 and SHA512. ----------- and .11 is SHA512. Why is it not working? Do I have to give the OID in a different way? Stefan

3 4

slapcat compains "scheme not available" after using "olcPasswordHash: sha256"
by Windl, Ulrich 23 Apr '25

23 Apr '25

Hi! Using OpenLDAP 2.5 from SLES15 SP6 I added "olcPasswordHash: sha256" ("olcPasswordHash: {sha256}") to cn=config (I wanted to add it to the {-1}frontend database, but slapd refused. I was able to set {SHA256} RootPWs, but now when I try slapcat, I get an error saying: slapcat -n0 olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({SSHA256}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found slapcat: bad configuration file! For slapppasswd I can use option "-o module-load=pw-sha2", but slapcat does not have it: # slapcat -o module-load=pw-sha2 -n0 usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]] [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] Is it my error, or slapcat's? Regards, Ulrich

2 2

Adding syncprov overlay to cn=config seems to freeze the server
by Windl, Ulrich 22 Apr '25

22 Apr '25

Hi! I'm trying to script a reconfiguration of out OpenLDAP servers, also changing the replication details. After dropping the old syncrepl overlay, I tried to add a new one like this: dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig I deliberately did not add more specific attributes, because I wanted to add them later. However I forgot to set olcOverlay. The point is that both, ldapmodify and slapd become unresponsive using that LDIF, at least when provided as ldapmodify -Y EXTERNAL -H ldapi:/// <<LDIF ... LDIF Is this a bug? Seen in OpenLDAP 2.5 provided by SLES15 SP6. From a coredump I forced, I see that the threads are all waiting, using one of these: __pthread_clockjoin_ex pthread_cond_wait __pthread_clockjoin_ex Kind regards, Ulrich Windl

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical