dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder
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
14 years, 2 months
Re: thread pools, performance
by Howard Chu
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/
15 years, 3 months
LDAP/Samba 4 summary
by Andrew Bartlett
(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
15 years, 6 months
Dynamic syntax support
by Howard Chu
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/
15 years, 6 months
back-ldap & rewrite engine
by Dieter Kluenter
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
15 years, 7 months
Estimated cost to develop OpenLDAP: $9,621,793
by Gavin Henry
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/
15 years, 7 months
Re: ldap_int_sasl_bind() and canonical Kerberos names
by Geert Jansen
-----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-----
15 years, 7 months
Re: thread pools, performance
by Howard Chu
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/
15 years, 7 months
Re: ldap_int_sasl_bind() and canonical Kerberos names
by Quanah Gibson-Mount
--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
15 years, 7 months
servers/slapd/overlays/slapover.txt
by Gavin Henry
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/
15 years, 7 months
