contextCSN of subordinate syncrepl DBs
by Rein Tollevik
I've been trying to figure out why syncrepl used on a backend that is
subordinate to a glue database with the syncprov overlay should save the
contextCSN in the suffix of the glue database rather than the suffix of
the backend where syncrepl is used. But all I come up with are reasons
why this should not be the case. So, unless anyone can enlighten me as
to what I'm missing, I suggest that this be changed.
The problem with the current design is that it makes it impossible to
reliably replicate more than one subordinate db from the same remote
server, as there are now race conditions where one of the subordinate
backends could save an updated contextCSN value that is picked up by the
other before it has finished its synchronization. An example of a
configuration where more than one subordinate db replicated from the
same server might be necessary is the central master described in my
previous posting in
http://www.openldap.org/lists/openldap-devel/200806/msg00041.html
My idea as to how this race condition could be verified was to add
enough entries to one of the backends (while the consumer was stopped)
to make it possible to restart the consumer after the first backend had
saved the updated contextCSN but before the second has finished its
synchronization. But I was able to produce it by simply add or delete
of an entry in one of the backends before starting the consumer. Far to
often was the backend without any changes able to pick up and save the
updated contextCSN from the producer before syncrepl on the second
backend fetched its initial value. I.e it started with an updated
contextCSN and didn't receive the changes that had taken place on the
producer. If syncrepl stored the values in the suffix of their own
database then they wouldn't interfere with each other like this.
There is a similar problem in syncprov, as it must use the lowest
contextCSN value (with a given sid) saved by the syncrepl backends
configured within the subtree where syncprov is used. But to do that it
also needs to distinguish the contextCSN values of each syncrepl
backend, which it can't do when they all save them in the glue suffix.
This also implies that syncprov must ignore contextCSN updates from
syncrepl until all syncrepl backends has saved a value, and that
syncprov on the provider must send newCookie sync info messages when it
updates its contextCSN value when the changed entry isn't being
replicated to a consumer. I.e as outlined in the message referred to above.
Neither of these changes should interfere with ordinary multi-master
configurations where syncrepl and syncprov are both use on the same
(glue) database.
I'll volunteer to implement and test the necessary changes if this is
the right solution. But to know whether my analysis is correct or not I
need feedback. So, comments please?
--
Rein Tollevik
Basefarm AS
13 years, 10 months
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, 6 months
Re: commit: ldap/servers/slapd/back-bdb add.c back-bdb.h bind.c cache.c compare.c config.c delete.c dn2entry.c dn2id.c filterindex.c id2entry.c idl.c init.c key.c modify.c modrdn.c proto-bdb.h referral.c search.c tools.c
by Howard Chu
hyc(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb
>
> Modified Files:
> add.c 1.173 -> 1.174
> back-bdb.h 1.173 -> 1.174
> bind.c 1.54 -> 1.55
> cache.c 1.180 -> 1.181
> compare.c 1.57 -> 1.58
> config.c 1.107 -> 1.108
> delete.c 1.172 -> 1.173
> dn2entry.c 1.35 -> 1.36
> dn2id.c 1.156 -> 1.157
> filterindex.c 1.75 -> 1.76
> id2entry.c 1.86 -> 1.87
> idl.c 1.134 -> 1.135
> init.c 1.291 -> 1.292
> key.c 1.24 -> 1.25
> modify.c 1.176 -> 1.177
> modrdn.c 1.200 -> 1.201
> proto-bdb.h 1.159 -> 1.160
> referral.c 1.50 -> 1.51
> search.c 1.265 -> 1.266
> tools.c 1.127 -> 1.128
>
> Log Message:
> Use read-only txn's instead of read lockers. Support BDB 4.4-4.7
Please test... At the moment I've only run it with BDB 4.7.25. I'll be testing
with older releases over the next couple of days. In particular, take note of
any LDAP_OTHER/Internal Error results in the test suite. Right now it passes
all tests for me on bdb and hdb.
If push comes to shove we can probably create a new BerkeleyDB4.2.patch file
to get 4.2 working again, but at this point most people should already be on
something newer, and people stuck on 4.2 probably won't compile their own anyway.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years
postalAddress matching rule
by Brett ＠Google
Hello,
I've just submitted a patch to help make the collect overlay
(attribute inheritance) a bit more useful (ITS#5659).
As part of my testing work for the above i once accidentally created a
postalAddress attribute with two values. When i tried to remove the
extra attribute value it failed, the error i got was something like
that there is no matching rule for postalAddress, which if there
really isn't then it's probably a reasonable thing for slapd to
complain about, as it wont be able to tell the individual values of
postalAddress apart.
So to put it in a nutshell, i'm willing to have a go implementing a
postalAddress matching rule, but i was wondering if anyone has any
thoughts where i might begin, and/or any pointers as to which file(s)
implement the matching rules.
Cheers
Brett
15 years
poll/epoll patch for libldap?
by Nicholas Dronen
Hi:
I work on a commercial server application, a gateway, which uses pam_ldap to
authenticate users in some situations. As a server application, it can
easily exceed the 1024 default file descriptor limit of select(2), which has
bitten us recently. Since the server application ships in an appliance, we
can provide a patch in the form of an OpenLDAP RPM that's been recompiled
with -DOPENLDAP_FD_SETSIZE. That fixes the immediate problem for us, but
would you be willing to accept a patch to libldap that gave developers a
programmatic way to use poll or epoll instead of having to recompile?
Regards,
Nick
15 years
Re: commit: openldap-guide/admin replication.sdf
by ghenry＠OpenLDAP.org
----- ghenry(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/openldap-guide/admin
>
> Modified Files:
> replication.sdf 1.62 -> 1.63
>
> Log Message:
> To do list review: small typo quick fix.
This means the following list I've just compiled whilst reviewing the current state of the admin guide and my own todos:
# OpenLDAP Test suite
* Go through Samba stuff again
# OpenLDAP contrib scripts for generating LDIF etc.
# OpenLDAP Admin Guide -
* Intro
o Tighten "LDAP vs RDBMS"
o Check "What is slapd and what can it do?"
o "Replicated Directory Service" - add MultiMaster picture.
* "Configuring slapd" - check DIT layout is right
* "The slapd Configuration File" - check backends are correct and in above
* "Access Control" - Finish "Converting from slapd.conf(5) to a cn=config directory format"
* Backends section to finish
* Overlays section to finish
* Maintenance section to finish
* Monitoring section to finish
* Tuning section to finish
* More in Troubleshooting section
* More in Upgrading from 2.3.x section
* Check "Recommended OpenLDAP Software Dependency Versions" section
* Do some "Real World OpenLDAP Deployments and Examples"
* "OpenLDAP Software Contributions" to complete
* "Configuration File Examples" to complete
Just e-mailing here for reference. If anyone sees any quick grabs they are interested in ;-)
Thanks,
Gavin.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
15 years, 1 month
What happened to cvs.openldap.org?
by Michael Ströder
HI!
Since yesterday I can't reach the pserver on cvs.OpenLDAP.org anymore.
$ cvs up -Rd .
cvs [update aborted]: connect to cvs.OpenLDAP.org(204.152.186.56):2401
failed: Connection refused
Ciao, Michael.
15 years, 1 month
HEADS UP: tls restructuring
by Howard Chu
I've split all of the OpenSSL and GnuTLS-specific code into their own separate
source files, to clean up some of the #ifdef mess that was in tls.c before.
This approach actually allows support for both to be compiled in at the same
time. I'll probably add an LDAP_OPT_X option to select which implementation to
use at runtime. (It might make sense to make these dynamically loadable
modules, but for now I don't want to make libldap dependent on
ltdl/dlopen/whatever.)
I have not committed these changes yet. Probably will in the next day or two
unless there are objections.
There's one user-visible change: get_option(LDAP_OPT_X_TLS_SSL_CTX) now
returns a pointer to a privately defined structure. For GnuTLS this is in fact
the same behavior as before. For OpenSSL this is a change; it used to return
the actual (SSL *). If this is going to break something of yours, holler now...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 1 month
reduced DEFAULT_SEARCH_STACK_DEPTH
by Suhel Momin
Hi,
I want to understand what is the impact of changing following #defines
#define DEFAULT_SEARCH_STACK_DEPTH 16
#define MINIMUM_SEARCH_STACK_DEPTH 8
I can see that this value is used to allocate search_stack.
I modified these values to
#define DEFAULT_SEARCH_STACK_DEPTH 4
#define MINIMUM_SEARCH_STACK_DEPTH 2
This helped in reducing memory footprint however I am not sure about the
wide range impact.
Thanks,
Suhel
15 years, 1 month
