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
Remove SunOS LWP support
by Hallvard B Furuseth
libraries/libldap_r/thr_lwp.c (SunOS LWP) has since 1999 (rev 1.5) said:
/* This implementation NEEDS WORK. It currently does not compile */
I suggest we kill LWP support. Has anyone tried to use it since 1999?
Note, configure --with-threads=lwp turns into either Solaris
threads (#define HAVE_THR) or SunOS LWP (#define HAVE_LWP).
--
Hallvard
15 years, 2 months
back-bdb flaw
by Howard Chu
There appears to be a long-standing problem with back-bdb and entries with
more than BDB_IDL_DB_MAX immediate children. If the entryIDs of the children
are non-contiguous, then attempts to delete the subtree of the entry will
fail, because the IDL range for the OneLevel index in the dn2id DB will never
zero out.
back-hdb doesn't have this problem.
Not sure what an appropriate fix is. Ideally, when deleting an entry whose ID
corresponds to either the lower or upper bound of the range, we should update
the range with the ID of the next remaining sibling. But there's no easy way
to search for that ID, so we just increment/decrement the range by 1. The
OneLevel index is the only structure that can quickly tell us what the
siblings are, and it's obviously useless when this situation arises.
The only way to search would be to [inc/dec]rement the ID and retrieve the
corresponding entry's DN to see if it is a sibling of the deleted entry, and
loop until a sibling is found or we run into the opposite range boundary. On a
large DB this will be extremely slow.
Seems like the best fix is to deprecate back-bdb and only use back-hdb from
now on.
--
-- 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, 2 months
RE24 testing
by Quanah Gibson-Mount
Please test RE24, thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 2 months
SLAP_BUILTIN_SASL
by Quanah Gibson-Mount
Is SLAP_BUILTIN_SASL suppose to be triggered if Cyrus-sasl isn't found? I
was grepping the 2.4 source, and all I see is several lines in
servers/slapd/sasl.c along the lines of:
#elif defined(SASL_BUILTIN_SASL)
i.e., nothing that ever defines (enables) it.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 2 months
RE23 testing
by Quanah Gibson-Mount
Please test RE23. It has been tagged for 2.3.43, and considered ready for
release unless something showstopping is reported. Latest change was to
fix ppolicy (ITS#5569).
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 2 months
No tests using rwm-rewriteEngine?
by Gavin Henry
Hi All,
I'm trying to provide an example config for slapo-rwm and not use the man
page.
The only tests I can find that mention rwm are:
test028-idassert
test030-relay
test039-glue-ldap-concurrency
test047-ldap
Should there be a test for this?
--
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/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.
15 years, 2 months
RE23 testing
by Quanah Gibson-Mount
Please test RE23, thanks!
Only minor fixes plus the security fix.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 2 months
