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, 6 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, 2 months
Compile warning using additonal CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W'
by John Smith
i,
Ive just downloaded and compiled openldap-2.4.10, but when I add the
CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W' I get the following
warnings that may require further investigation of an developer :
- declaration of 'foo' shadows a global declaration
- cast discards qualifiers from pointer target type
- missing initializer
- signed and unsigned type in conditional expression
- comparison between signed and unsigned
- comparison of unsigned expression >= 0 is always true
- comparison of unsigned expression < 0 is always false
- declaration of 'foo' shadows a previous local
- `foo' is deprecated; use `foobar' or `foo_r' instead
-
Perhaps this warrants some investigation by the developers ? Ive
attached the complete build log for the full details.
Regards,
John Smith.
14 years, 11 months
[BUG,PATCH] slapd unable to import CRL using GnuTLS backend
by arno＠natisbad.org
Hi,
When openldap is linked with gnutls for TLS support, a file containing
CRL in PEM format can be provided (in slapd.conf, using TLSCRLFile
parameter).
The following code in ldap_int_tls_init_ctx() (librairies/libldap/tls.c)
prevents the daemon to start when the option is used:
if ( lo->ldo_tls_crlfile ) {
rc = gnutls_certificate_set_x509_crl_file(
((tls_ctx*) lo->ldo_tls_ctx)->cred,
crlfile,
GNUTLS_X509_FMT_PEM );
if ( rc < 0 ) goto error_exit;
}
because gnutls_certificate_set_x509_crl_file() returns the number of CRL
files that have been imported which is stored in rc and returned later
in the function. Caller expects 0, otherwise it reports an error, the
value of rc (below, with 3 CRL in the file) and slapd fails to start:
.... main TLS init def ctx failed: 3
The patch below is for 2.4.10, but should apply against all versions (it
applies fine against current Debian version available under Unstable).
Tell me if you have issues.
I recompiled the Debian version with the patch applied and it works as
expected.
Cheers,
a+
14 years, 11 months
test suite data
by Howard Chu
I'm currently trying to run "make test" with back-ndb and most of the
comparisons fail even though the backend is behaving correctly.
1) back-ndb always fills in all objectclasses in the objectclass chain,
while the test.ldif files omit most of the superior classes.
2) back-ndb always returns attributes in the order they were defined in
their corresponding objectclass definition, instead of preserving whatever
order they were submitted in.
Any thoughts on how to address this?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 11 months
managing OpenLDAP / back-config
by Ralf Haferkamp
With the great features that back-config provides to configure OpenLDAP
servers at runtime it seems logical to start thinking about providing tools
that could help to leverage those features.
Currently to manage an OpenLDAP server through back-config you have the option
to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio,
web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or
homegrown software using one of the available LDAP APIs. I think it would be
helpful to have some more sophisticated management tools (Commandline and/or
GUI).
In order to get there I think it could be helpful to create an API dedicated
to provide an easy way to access the OpenLDAP configuration (databases,
overlays, schema, access control, ...). This API could then be used to create
different flavors of management tools.
I have not yet spend too much time thinking about the design of such an API.
Neither about the programming language that I'd use to implement something
like this (Python, C, C++, ?). I first like to get a feeling how others think
about this and if anybody is interested in collaborating on such an API. So
please feel free to reply with your comments and suggestions :)
--
regards,
Ralf
14 years, 11 months
Re: commit: ldap/contrib/slapd-modules README
by Hallvard B Furuseth
ghenry(a)OpenLDAP.org writes:
> Read over, update using work from hallvard and spell check.
Actually we both got that wrong. The posixgroup README says
compile it as plugin acl-posixgroup.
--
Hallvard
14 years, 11 months
[Fwd: LDAP Content Synchronization Operation (rfc4533)]
by Gavin Henry
Another use outside the project.
-------- Original Message --------
Subject: LDAP Content Synchronization Operation (rfc4533)
Date: Sat, 14 Jun 2008 21:01:36 +0200
From: Mathieu PARENT <math.parent(a)gmail.com>
To: perl-ldap(a)perl.org
Hi,
I have implemented LDAP Content Synchronization Operation (rfc4533) in
perl-ldap (See the attached patch). This is used by the OpenLDAP
server and provide features similar to Persistent Searches in a more
consistent way.
This is my first try in this code, any feedback is welcome.
I don't know how to handle the Sync Info Message which is an LDAP
Intermediate Response Message (see 2.5 in RFC). perl-ldap doesn't
seems to support intermediate responses in response to LDAP::Search.
What is the way to correct this ?
thanks
Mathieu Parent
--
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.
14 years, 11 months
Subschema missing entryCSN
by Michael Ströder
HI!
Any particular reason why attribute type 'entryCSN' is still missing in
the subschema? (testing with 2.4.10)
Ciao, Michael.
14 years, 11 months
Deleting overlays from cn=config
by Ralf Haferkamp
Hi,
as back-config does currently not have support for the delete operation
(config_back_delete() just returns LDAP_UNWILLING_TO_PERFORM
currently) I am trying to figure out what is needed to get at
least delete support for simple overlays (e.g. ppolicy or memberof)
running.
What I am currently doing is:
- renumber the indexes of the siblings of the overlay that's going to be
deleted
- remove the CfEntryInfo of the overlay from the internal config tree
- remove the Entry from the underlying LDIF database
Additionally I need to remove the overlay's slap_overinst structure from
the overlay list of the backend and in case it was the last overlay,
restore the original BackendInfo structure and delete the
SLAP_DBFLAG_GLOBAL_OVERLAY flag from the BackendDB structure of the
underlying database (for global overlays). Currently I use the
overlay_destroy_one() function for this task. This also calls the
db_destroy() hook of the overlay which should take are of free
resources held by the overlay.
I am a bit unsure about the db_destroy() part. Is that enough or is it
needed to call the db_close() hooks (when provided by the overlay)
before calling db_destroy()? Did I miss something else? Is anybody else
currently working on this?
Up to now I am testing this only with some simpler overlays (memberof,
pcache), I assume that deleting overlays that instantiate their own
databases (like pcache, translucent(?)) might get a little more hairy.
--
Ralf
14 years, 11 months
