openldap-devel October 2007

openldap-devel@openldap.org

20 participants
38 discussions

dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder 21 Mar '09

21 Mar '09

HI! Discussed this very briefly with Howard at LDAPcon 2007 based on an idea of Steve: Support for dITStructureRules and nameForms is still in OpenLDAP's TODO. In the meanwhile slapd could accept definitions for both in slapd.conf and simply pass them on to a schema-aware LDAP client for informational purpose without enforcing them. Same function like rootDSE <file> in slapd.conf. Opinions? Ciao, Michael. -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

2 4

Re: thread pools, performance
by Howard Chu 14 Feb '08

14 Feb '08

Rick Jones wrote: > There are definitely interrupt coalescing settings available with tg3-driven > cards, as well as bnx2 driven ones: > > ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt Yep, that helped. Raising rx-usecs from default 20 to 1000, and rx-frames from default 5 to 100, I'm getting 43k auths/sec with back-null (in 4 separate thread pools) and the core fielding the interrupts is only about 80% busy now instead of 100%. I'm afraid my load generators may be maxed out now, because I can't seem to drive up the load on the server any higher even though there's more idle CPU. The current code in HEAD (with only 1 thread pool) is reaching 36k auths/sec with back-null, so it's actually not far off from my experimental peak rate. Considering that HEAD was at 25k/sec last week (and now in 2.4.6) that's pretty decent. With back-bdb and 1 million users I'm getting 26.1k/sec with plaintext passwords (up from 19.3k/sec last week). With {SSHA} passwords that drops to 25.7k/sec (~1.5% difference). I have to put this tinkering on hold for a bit, to run some authrate tests against ActiveDirectory on this machine (using W2K3sp2 X64). Later on we'll do a W2K3 OpenLDAP build for comparison as well. Should be entertaining... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

7 22

LDAP/Samba 4 summary
by Andrew Bartlett 04 Dec '07

04 Dec '07

(please forgive the cross-posting to subscriber-only lists) Howard Chu helpfully wrote up this summary of the meeting we held at the CIFS Workshop on how Samba4 should work with an LDAP backend. The background is that Samba4 increasingly needs some things that an LDAP server could provide for us. In the short term, we need to add subtree renames to ldb_tdb, but OpenLDAP's hdb already provides this for us. Likewise, we have a desperate need for replication (because any site in need of Samba4's features will want multiple DCs) - and Fedora DS's replication seems like a very good, solid answer. (Sadly it doesn't give us subtree renames...). Another feature we don't yet do schema validation in Samba4, beyond checking that the objectClass list is valid. We need to extend that, but perhaps the LDAP server could do that validation for us? Finally, in the long term, we would like to have Samba4 play nice in a multi-use directory, and this presents a schema mapping problem. We agreed to get together and try and work out a schema that is compatible to Microsoft's extensions, without being too painful to see from a traditional client. I hope to put together a discussion on this in the near future. I expect we will continue to use and support ldb_tdb as a backend on Samba4, but for some features (which they will want), users should be directed to use LDAP as an important backend. Andrew Bartlett -------- Forwarded Message -------- From: Howard Chu <hyc(a)symas.com> To: OpenLDAP-devel(a)openldap.org Subject: [Fwd: LDAP/Samba 4 summary] Date: Fri, 28 Sep 2007 10:42:22 -0700 Yesterday afternoon at the CIFS Workshop we had a meeting to discuss Samba 4's use of LDAP going forward, and what obstacles remained. Among the attendees that I can remember were Andrew Bartlett, Andrew Tridgell, Simo Sorce, Stefan Metzmacher, and (one more, I've forgotten the name) from the Samba team. Nicole Jacque and another (sorry, don't remember the name) from Apple/OpenDirectory, Pete Rowley from FedoraDS, and myself and Marty Heyman for OpenLDAP and Symas. The upshot is that both the Samba and the LDAP sides have work to do, but there are no major roadblocks. LDAP will be Samba 4's default/recommended data store. As for OpenLDAP, most of what Samba 4 needs is either already implemented, or in progress. Schema design tends to still be a stumbling block; in a separate conversation we discussed some design issues in MIT's new Kerberos schema as well as missing features in Heimdal's existing Kerberos schema. That's a bit outside this openldap-devel scope but I've committed to working with the Samba and Kerberos communities to draft some changes to unify these two Kerberos schemas. -------- Forwarded Message -------- From: Howard Chu <hyc(a)symas.com> To: Andrew Bartlett <abartlet(a)samba.org> Subject: LDAP/Samba 4 summary Date: Thu, 27 Sep 2007 22:41:23 -0700 Missing features / wishlist bitwise ops. already in OpenLDAP, recently added to FedoraDS(?) USNs partially implemented in OpenLDAP, need more complete spec LDAP Transaction support draft-zelenga-ldap-txn - partially implemented in OpenLDAP some concerns because Samba's definition of transaction is not the canonical ACID definition. More like ACI, no Durability guarantee, doesn't play well with LDAP Multimaster Replication. We all agreed that if Samba doesn't care, neither do we. All that matters is that it provides tidy, painless rollback in event of intermediate failures. Access Controls my suggestion re: OpenLDAP - we support modular ACL engines, we should just write a module for native NT ACLs in OpenLDAP AD schema - we agreed that a new schema is necessary no matter how you slice it, we will all collaborate to define a superset of AD that everyone can support. Authentication mechanisms - generally Samba will handle this itself validation - Samba4 + LDAP must pass everything under Samba's "make test" suite. Transactions again - we may need things like memberOf and other linked attributes to be managed internally in the server. No problem, both OpenLDAP and FDS have memberOf plugins already available. Subtree renames - MS tools assume subtree renames work. Supported in OpenLDAP already (back-hdb, back-ldif, will be in back-tdb). Unfortunately not supported in FedoraDS, might be able to kludge it, but it will require additional mapping layers. And kludging will break base-scope searches, referential integrity, etc... -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com

5 11

Dynamic syntax support
by Howard Chu 27 Nov '07

27 Nov '07

Here's a project for someone fairly ambitious: The goal is to be able to dynamically add support for new syntaxes to slapd simply by feeding in their specifications. Typically this would mean feeding in an ABNF description from an IETF document, though it may also mean feeding in ASN.1 documents. E.g., we want to be able to insert (using ldapmodify) the ABNF into an LDAP entry somewhere and have it automatically converted into an executable parser. There are a couple of tools out there for working with ABNF. The IETF actually uses this one http://www.coasttocoastresearch.com/Apg5_0/Apg5_0_description.htm for validating IETF drafts. There's also this one http://www.2p.cz/en/abnf_gen I don't think either of these are suitable as they exist, because they don't generate output that is embeddable and directly executable. I guess you could feed the generated C code into an embedded C interpreter, but that seems like a ridiculously wasteful solution. Most of these existing tools will analyze a grammar and spit out source code to recognize it, but we don't want the source code, we just want the recognition action. I think a more practical route will involve embedding a Forth engine into the OpenLDAP code. There's already been a fair amount of work done with BNF in Forth, so it shouldn't be too hard to get started: http://www.zetetics.com/bj/papers/bnfparse.htm http://www-personal.umich.edu/~williams/archive/forth/strings/index.html http://www-personal.umich.edu/~williams/archive/forth/strings/expr.html The nice thing about Forth is that the core language is tiny, it's extremely portable, it's extremely extensible, and any implementation is inherently both an interpreter and a compiler. As interpreted languages goes, it beats pretty much every other common scripting language for memory and CPU efficiency. It ought to be straightforward to convert a grammar into a set of Forth words to recognize the grammar, for a slapd syntax validator. I'm not sure yet what we would do for Prettifiers or Normalizers, nor what to do for Matching rules. We could simply accept them as Forth source code. Personally I haven't written Forth in over 20 years but it seems to me that a TIL is the most suitable type of language for the job. On the whole it doesn't seem like new syntaxes pop up in LDAP specs very often. Some may say this is because they're not really needed. I believe they've been sorely needed, and people have just avoided them because they required too much work to properly support in existing implementations. We can fix that. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 5

back-ldap & rewrite engine
by Dieter Kluenter 27 Oct '07

27 Oct '07

Hi, I am testing REL_ENG_2_4 and HEAD back-ldap and rw with the same slapd.conf, and a sasl bind. While RE_2.4 just crashes with segfault, HEAD is not rewriting the sasl ID, that is proxy ID: cn=Dieter Kluenter,ou=partner,dc=dkluenter,dc=de master ID: cn=Dieter Kluenter,ou=partner,o=avci,c=de Based on this configuration earlier HEAD versions had rewriten sasl identity properly. My searchstring for back-ldap is: ldapsearch -Y digest-md5 -U dieter -w xxxx-H ldap://localhost:9004 -b "cn=dieter kluenter,ou=partner,dc=dkluenter,dc=de" -s sub "*" ,----[ slapd.conf back-ldap ] | modulepath /opt/openldap/libexec/openldap | moduleload back_meta.la | moduleload back_ldap.la | moduleload pcache.la | moduleload rwm.la | authz-regexp uid=(.*),cn=.*,cn=auth | ldap:///dc=dkluenter,dc=de??sub?uid=$1 | | access to * by * read | database ldap | suffix dc=dkluenter,dc=de | rootdn cn=admin,dc=dkluenter,dc=de | uri ldap://localhost:389 | acl-bind | bindmethod=sasl | saslmech=digest-md5 | authcId=admanager | credentials=xxxxx | idassert-bind | bindmethod=sasl | saslmech=digest-md5 | authcId=admanager | credentials=xxxx | mode=self | overlay rwm | rwm-rewriteEngine on | rwm-suffixmassage "dc=dkluenter,dc=de" "o=avci,c=de" | overlay pcache | proxycache bdb 10000 22 50 3600 | ... `---- ,----[ back trace of RE_2.4 ] | <= ldap_dn2bv(cn=dieter kluenter,ou=partner,o=avci,c=de)=0 | <<< dnPrettyNormal: <cn=Dieter Kluenter,ou=Partner,o=avci,c=de>, <cn=dieter kluenter,ou=partner,o=avc | ,c=de> | ber_scanf fmt ({xx) ber: | Program received signal SIGSEGV, Segmentation fault. | [Switching to Thread 0xb6d2fb90 (LWP 12590)] | 0x00000000 in ?? () | | (gdb) bt | #0 0x00000000 in ?? () | #1 0xb7826a2c in ldap_back_search (op=0xb6d2eadc, rs=0xb6d2ebb0) at search.c:338 | #2 0x080d51c0 in overlay_op_walk (op=0xb6d2eadc, rs=0xb6d2ebb0, which=op_search, oi=0x8251b80, | on=0x8253970) at backover.c:652 | #3 0x080d56ee in over_op_func (op=0xb6d2eadc, rs=0xb6d2ebb0, which=op_search) at backover.c:704 | #4 0x080b92b5 in slap_sasl2dn (opx=0x82ba8a0, saslname=0xb6d2ed70, sasldn=0xb6d2ece4, flags=2) | at saslauthz.c:2005 | #5 0x080bf2e3 in slap_sasl_getdn (conn=0xb753264c, op=0x82ba8a0, id=0xb6d2ed68, user_realm=0x0, | dn=0xb6d2ed70, flags=<value optimized out>) at sasl.c:2035 | #6 0x080c0725 in slap_sasl_canonicalize (sconn=0x82b8f70, context=0xb753264c, | in=0x82ba158 "dieter", inlen=6, flags=1, user_realm=0x0, out=0x82b9c81 "", out_max=1024, | out_len=0x82b97e0) at sasl.c:624 | #7 0xb7d4f2b8 in _sasl_canon_user () from /usr/lib/libsasl2.so.2 | #8 0xb7a20576 in ?? () from /usr/lib/sasl2/libdigestmd5.so | #9 0x082b8f70 in ?? () | #10 0x082ba158 in ?? () | #11 0x00000006 in ?? () | #12 0x00000001 in ?? () | #13 0x082b97d0 in ?? () | #14 0xb7f92ee0 in ?? () from /lib/ld-linux.so.2 | #15 0xb7f36161 in ber_flush2 (sb=0x113, ber=0xb6d2edd0, freeit=-1227689916) at io.c:256 | #16 0xb7d58b07 in sasl_server_step () from /usr/lib/libsasl2.so.2 | #17 0x080c0208 in slap_sasl_bind (op=0x0, rs=0x82b8f70) at sasl.c:1654 | #18 0x08091790 in fe_op_bind (op=0x82ba8a0, rs=0xb6d2f144) at bind.c:280 | #19 0x08092191 in do_bind (op=0x82ba8a0, rs=0xb6d2f144) at bind.c:205 | ---Type <return> to continue, or q <return> to quit--- | #20 0x08074431 in connection_operation (ctx=0xb6d2f238, arg_v=0x82ba8a0) at connection.c:1145 | #21 0x08074ace in connection_read_thread (ctx=0xb6d2f238, argv=0xf) at connection.c:1271 | #22 0xb7f4a2b2 in ldap_int_thread_pool_wrapper (xpool=0x821a7b8) at tpool.c:619 | #23 0xb7d67192 in start_thread () from /lib/libpthread.so.0 | #24 0xb7b3902e in clone () from /lib/libc.so.6 | (gdb) `---- ,----[ slapd-log on master with HEAD ] | slapd[3832]: => acl_mask: access to entry "cn=Dieter Kluenter,ou=Partner,o=avci,c=de", attr "entry" requested | slapd[3832]: => acl_mask: to all values by "cn=dieter kluenter,ou=partner,dc=dkluenter,dc=de", (=0) | slapd[3832]: <= check a_dn_pat: cn=$1,ou=Partner,o=avci,c=de | slapd[3832]: <= check a_group_pat: cn=administratoren,o=avci,c=de | slapd[3832]: => bdb_entry_get: found entry: "cn=administratoren,o=avci,c=de" | slapd[3832]: <= check a_dn_pat: * | slapd[3832]: <= acl_mask: [3] applying auth(=xd) (stop) | slapd[3832]: <= acl_mask: [3] mask: auth(=xd) | [3832]: => slap_access_allowed: search access denied by auth(=xd) | slapd[3832]: => access_allowed: no more rules `---- Is there anything wrong with my slapd.conf? Or is this a bug? -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Estimated cost to develop OpenLDAP: $9,621,793
by Gavin Henry 26 Oct '07

26 Oct '07

Quite an interesting output running sloccount over OpenLDAP HEAD: SLOC Directory SLOC-by-Language (Sorted) 138537 servers ansic=138092,cpp=254,perl=152,sh=39 60773 libraries ansic=60773 28054 contrib ansic=14646,sh=8765,cpp=4472,perl=126,tcl=45 20657 tests sh=17287,ansic=3370 9518 build sh=9515,ansic=3 6025 include ansic=6025 5657 clients ansic=5657 0 CVS (none) 0 doc (none) 0 top_dir (none) Totals grouped by language (dominant language first): ansic: 228566 (84.90%) sh: 35606 (13.23%) cpp: 4726 (1.76%) perl: 278 (0.10%) tcl: 45 (0.02%) Total Physical Source Lines of Code (SLOC) = 269,221 Development Effort Estimate, Person-Years (Person-Months) = 71.23 (854.72) (Basic COCOMO model, Person-Months = 2.4 (KSLOC**1.05)) Schedule Estimate, Years (Months) = 2.71 (32.51) (Basic COCOMO model, Months = 2.5 (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 26.29 Total Estimated Cost to Develop = $ 9,621,793 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL. SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to redistribute it under certain conditions as specified by the GNU GPL license; see the documentation for details. Please credit this data as "generated using David A. Wheeler's 'SLOCCount'." :-) -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: ldap_int_sasl_bind() and canonical Kerberos names
by Geert Jansen 25 Oct '07

25 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon, >> The patch unconditionally disables hostname canonicalisation for >> the sasl client. > > I think this will break GSSAPI connections to LDAP servers that are > behind DNS round robin style load balancers. > > Assume that you have 'ldap' that is a CNAME for ldap-1 and ldap2. > The LDAP library initiates a connection to 'ldap', and DNS points > it to 'ldap-1'. Providing you ask SASL to set up a connection to > 'ldap-1', you're fine (this is what the code does at the moment). > However, if you ask the SASL library for a connection to 'ldap' > (this is what your change does, as far as I can tell), and the > library does a canonicalisation step (as most Kerberos > implementations currently do), it will get 'ldap-2' back from the > DNS. So, you end up trying to negotiate a SASL connection with > 'ldap-2', when you're actually connected to 'ldap-1'. This tends > not to work. Thanks for the explanation and indeed I see that my patch would break this use case. I have come to the conclusion that one of the two reasons why I looked into this patch (do not keep realm data on the local system) is actually a problem that has nothing to do with canonicalisation. Realm referrals work just as well with the reverse-dns based canonical name as long as it is a valid principal. The other reason (be resilient against wrong reverse-dns setups) could still be a reason to use this patch, but now that I think of it it, it probably doesn't buy you much as you need proper forward dns anyway so better have a proper reverse dns too. Therefore I withdraw my patch. Regards, Geert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQEVAwUBRyDy7prPkVOV4lDgAQJD9gf+KzsoMxBtCf0K0f80q6kWM+DAB64EpwCV g2Lj9JdKK0BcxcyXpnz+vBrKPwuP8RP/1dkvNiBJrgcUVc9Yo25H+UNBHkff0wUt QPZZvf9p/nxz0AQHAYrHdh94fM748y2LuMD/oVkpu+Oi8HeC5P5fo2VMpsoJ9pcg 9ee23yyuT3EyjpG3YGnApOOdAPgEqgUirvI+DibFYXo4hLrzwL5PKRmY3ggMZKa1 OrHz2qjZjvcktbs3cSU0v17tG+KLW1DtKaO80bSrbjAqb0l4rVPI+a6ixN5IEbG7 RdGKzx9jP4hgTP+Xt06e+eNFg19u0e72mrlzmH2A29C5RA2cHVsMRg== =bLmO -----END PGP SIGNATURE-----

1 0

Re: thread pools, performance
by Howard Chu 25 Oct '07

25 Oct '07

Rick Jones wrote: >> The ethernet controllers are on a hub attached by HyperTransport to a >> single processor, I don't think you can usefully distribute the >> interrupts to anything beyond that socket. > > Well, it wouldn't necessarily be goodness from the standpoint of the time to do > any PIO reads, but from the standpoint of getting packet processing spread-out > and matching with the core on which the application thread runs it might be. > All depends I guess on how busy that HT link gets I guess and whether the NIC(s) > can do the spreading in the first place. I wonder if there are any pre-packaged > linux binaries out there to measure HT link utilization? Haven't looked. Would be interesting to see. > >>> Although, if there is still 10% idle, that probably needs to go next :) >> >> Heh heh. The 80/20 rule hits this with a vengeance. That's "10%" of >> "800%" total, which means really only about 1.2% of a CPU, which is >> almost totally indistinguishable from measurement error in the oprofile >> results. This is all intuition (guesswork) now, no more obvious hot >> spots left to attack. Maybe if I'm really bored over the holidays I'll >> spend some time on it. (Not likely.) > > My degree is in AppliedMath which means I cannot do math to save my life, but if > it was 10%agepoints of 800%agepoints total, that means 10% of 8 cores or 80% of > a core doesn't it? No, there are 800 %agepoints total for all 8 cores, and 10 out of 800 are idle. That's a total of 10% of a single core, but it's actually distributed across all 8 cores. So 1.25% of each core. > If it were 10% of one core, then it would be 1.25% of 800% IIRC. Yes. > And besides, the nature of single-threading bottlenecks seems to be that when > you go to 16 cores it will be rather more than 2X what it is today :) Yes, well, I haven't got a 16-core test system handy at the moment... The changes I just checked in hit the easy stuff, reducing mutex contention by about 25% on a read-only workload with a nice corresponding boost in throughput. I haven't gotten to the multiple pools yet. The most obvious one was using per-thread lists for the Operation free lists instead of a single global free list. This assumes that threads will get work allocated relatively uniformly; I guess we can add some counts and push free Ops onto a global list if a per-thread list gets too long. At the moment there's no checking, so once a few operations have been performed Operation allocation occurs with pretty much zero mutex activity. (This is probably redundant effort when using something like Google tcmalloc, but not everyone is using that...) The other change was using per-thread slap_counters for statistics instead of just a global statistics block. In this case, the global slap_counters structure still exists as the head of the list, and its mutex is used to protect list traversals/manipulations. But actual live data is accumulated in per-thread structures chained off the global. The head mutex is locked when allocating a new per-thread structure, deallocating a structure for an exiting thread, and whenever back-monitor wants to tally up data to present to a client. In normal operation, once the configured number of threads have been created, there will be no accesses to the global at all. If cn=config is used to decrease the number of threads, then some number of threads will exit and so they'll lock the list at that time and accumulate their stats onto the head structure before destroying themselves. So again, in normal operation, if nobody is querying cn=monitor, there will be zero mutex contention due to statistics counters. Something else I've been considering is padding certain structures to sizes that are multiples of a given cache line. Not sure I want to write autoconf tests for that, may just arbitrarily choose 64 bytes and let folks override it at compile time. The Connection array is the most likely candidate here. Something like #define ALIGN 64 typedef real_struct { whatever } real_struct; typedef padded_struct { real_struct foo; char pad[(sizeof(real_struct)+ALIGN-1) & ~(ALIGN-1)]; } padded_struct; -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ldap_int_sasl_bind() and canonical Kerberos names
by Quanah Gibson-Mount 24 Oct '07

24 Oct '07

--On October 24, 2007 10:42:43 PM +0100 Simon Wilkinson <simon(a)sxw.org.uk> wrote: > >> >> The patch unconditionally disables hostname canonicalisation for >> the sasl client. > > I think this will break GSSAPI connections to LDAP servers that are > behind DNS round robin style load balancers. > > Assume that you have 'ldap' that is a CNAME for ldap-1 and ldap2. The > LDAP library initiates a connection to 'ldap', and DNS points it to > 'ldap-1'. Providing you ask SASL to set up a connection to 'ldap-1', > you're fine (this is what the code does at the moment). However, if you > ask the SASL library for a connection to 'ldap' (this is what your change > does, as far as I can tell), and the library does a canonicalisation step > (as most Kerberos implementations currently do), it will get 'ldap-2' > back from the DNS. So, you end up trying to negotiate a SASL connection > with 'ldap-2', when you're actually connected to 'ldap-1'. This tends not > to work. Simon, Thanks! That'd completely destroy Stanford's setup. Ouch. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

servers/slapd/overlays/slapover.txt
by Gavin Henry 24 Oct '07

24 Oct '07

Anymore notes anywhere? CVS says: 1.1 Sat Mar 20 19:30:57 2004 UTC; 3 years, 7 months ago by hyc Overlay API notes. work in progress, please comment. It references docs that don't exist. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel October 2007