Re: commit: ldap/servers/slapd/overlays rwm.c
by Pierangelo Masarati
hyc(a)OpenLDAP.org wrote:
> Log Message:
> Remove redundant search cleanup
>
Howard,
note that among the issues in slapo-rwm there's the fact that it's
attaching a callback structure on the thread's private data instead of
malloc'ing (and freeing) it when required. As a consequence, this may
prevent slapo-rwm from being called more than once in an operation
execution sequence, because it could result in an endless loop or
unexpected execution sequences. In fact, when used with a regular
database, multiple calls shouldn't occur (one would need to explicitly
add more than one instance of slapo-rwm on the same database, which
makes little sense). However, gluing more than one database which
independently needs slapo-rwm is one such case of multiple calls in one
thread execution.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 3 months
auditContext in suffix entry?
by Pierangelo Masarati
I wonder why the auditContext is not implemented in slapo-accesslog. I
needed it in a similar overlay to provide (sort-of-)consumers a means to
locate the log db; should I port this fix to slapo-accesslog?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 3 months
Re: Documentation Guidelines?
by Kurt D. Zeilenga
Also, instead of a separate style guide, I suggest simply
adding a "conventions" section to the guide that covered
the basic elements of style from a reader's point of view.
Kurt
16 years, 3 months
Comments on replication consistency models
by Howard Chu
The Fedora folks have some comments defending their support of
multi-master replication here
http://directory.fedora.redhat.com/wiki/MMRConsideredHarmful
For the most part there's nothing noteworthy. Just wanted to address
their point "There is no way for any LDAP loosely coupled replication to
guarantee "read your writes" consistency." In fact, as we've discussed
here a few times in the past, this not true.
We can guarantee "read your writes" consistency with the help of a
tweaked chaining overlay. I.e.,
1) the client issues a write request to a slave
2) the slave chains the request to the master
3) when the chained write succeeds, the slave performs the write locally
4) the response is returned to the client
Assuming the client continues talking to the same slave, it will always
see consistent data.
It's a form of two-phase commit but a very special case. Since it only
requires waiting for one remote operation to succeed it's a lot more
efficient than managing generalized N-server two-phase commit.
As a further optimization, the chained request can carry a control
"don't loop back to me" telling the master not to propagate this update
back to the initiating slave. It only saves a small bit of bandwidth,
since with syncrepl, the subsequent redundant update would be idempotent.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 3 months
Re: Documentation Guidelines?
by Kurt D. Zeilenga
At 02:27 PM 12/15/2006, Gavin Henry wrote:
>Dear all,
>
>I was asked by Quanah to review a commit he did at:
>
>http://www.openldap.org/devel/cvsweb.cgi/admin/slapdconf2.sdf.diff?r1=1.2...
Not sure this is the best section to use for developing a
documentation guide. It's a bit new and hence has yet to
brought into line with the style established in some of
older chapters. The quick start guide is probably a
better chapter to use in forming a guide.
>And all looks well, but I want to query if we have or want some brief Doc
>Guidelines drafted?
I've committed updates here and there to fix up a few things.
-- Kurt
16 years, 3 months
Problem using BDB replication in OpenLDAP
by 石斌(Seuler.shi)
Problem using BDB replication in OpenLDAP
> Software version:
> Berkeley DB: 4.5.20
> OpenLDAP:2.3.30
>
> We want to configure the replication management in OpenLDAP's backend
> database. All write requests in OpenLDAP master site will spread to
> OpenLDAP client site for we have configured the backend database
> replication.
>
> We mend the source code the OpenLDAP according to the rep_mgr example
> provide by
>
> Berkeley DB.
>
> A test case is executed as follow:
>
> step 1: start openldap server site and client site;
> step 2: send write requests to the master site;
> step 3: search the master site and ensure the records are inserted in
> backend; database successfully;
>
> step 4: search the client site, but not ldap entry is displayed;
> step 5: kill the client site process and reboot it;
> step 5: search the client site right now after it reboot;
>
> Result: After step 5(reboot the client site), the search results from
> client site
> is same as the master site.
>
> At step 4: If we intend to insert an entry into the openLDAP server with
> BDB client configuration via ldapadd command, it will return "the entry
> already exists". After the failed insert operation, if search operation
> is executed, one entry will be displayed.Once a insert operation is
> tried, the number of entries in the subsequent search will increase by 1.
>
>
>
> My question:
>
> Why we can not search any info during the client is normally running? But
> once I rebooted the client site, it worked well and could accept search
> requests? How to solve this problem:)
16 years, 3 months
Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Quanah Gibson-Mount
--On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi)"
<seuler.shi(a)gmail.com> wrote:
>
> Dear Quanah:
>
> Because the replication features provided by OpenLDAP do not
> meet our software requirement.
> If there are N slaves and 1 master in a replication group in
> BDB, once the master crashes, a new
> master will be elected by BDB and the replication group can
> still work well. All the parameters
> concerning master election in BDB can be configured by user.
> This will be more portable.
>
> As the replication mechanism reaches synchronizations by
> transferring write requests to the replicas,
> this may be less efficient compared with BDB replication. So
> we need to compare these two method.
>
> Would you tell me why OpenLDAP do not support BDB
> replication?
>
> BDB replication mechanism will operate slave databases
> directly without inform the upper layer LDAP.
> The information such as index, ID and so on maintained by
> OpenLDAP may be inconsistent with the
> content of database. I try to mend the source code of
> OpenLDAP to let every "ldapsearch" operation
> find entry info in database directly, but I failed:(
>
> I am expecting your comments.
Because they aren't compatible. I'm guessing standby master may more meet
your needs, which will be a part of OpenLDAP 2.4.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 3 months
