openldap-devel

openldap-devel@openldap.org

1418 discussions

Re: Documentation Guidelines?
by Kurt D. Zeilenga 16 Dec '06

16 Dec '06

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

3 2

Comments on replication consistency models
by Howard Chu 16 Dec '06

16 Dec '06

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/

2 2

Re: Documentation Guidelines?
by Kurt D. Zeilenga 16 Dec '06

16 Dec '06

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.28&… 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

2 1

Documentation Guidelines?
by Gavin Henry 16 Dec '06

16 Dec '06

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.28&… And all looks well, but I want to query if we have or want some brief Doc Guidelines drafted? For example, some covering what we do and don't {{EX:}}, capitalisation, various tags we use etc. Thoughts? 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/

2 2

Problem using BDB replication in OpenLDAP
by 石斌(Seuler.shi) 15 Dec '06

15 Dec '06

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:)

2 2

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Quanah Gibson-Mount 15 Dec '06

15 Dec '06

--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

3 2

Re: commit: ldap/servers/slapd daemon.c slap.h aclparse.c acl.c
by Pierangelo Masarati 15 Dec '06

15 Dec '06

ando(a)OpenLDAP.org wrote: > implement full IPv6 support in ACLs; use URL notation (as suggested by Howard) to disambiguate parsing (ITS#4756) > OK, I see this breaks sasl_server_new() where it expects IPv6 iplocalport and ipremoteport in the form ip;port regardless of IPv4/6. I'll back part of this fix up. p.

1 0

Dropping slurpd, manage/Relax control
by Howard Chu 14 Dec '06

14 Dec '06

One feature that's still needed in some cases (e.g., using syncrepl to push updates to another slave thru back-ldap) is an updatedn identity with the privilege to write to unmodifiable operational attributes. I guess this isn't something the Relax control is intended to allow. We can keep using the updatedn but it feels like this is something that should be generalized. E.g. one might want to have a cluster of servers sending updates to each other, with a unique identity for each server, and all of them with privilege to write to operational attributes. I think the updatedn feature captures the idea ("this identity is a DSA") but it just needs to be more flexibly configured. -- -- 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/

3 4

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Howard Chu 14 Dec '06

14 Dec '06

石斌(Seuler.shi) wrote: > I just solve the problem and the BDB replication can work well with the > OpenLDAP. > > The back-bdb caching mechanism is not removed. I will test the > performance while > deploying back-bdb configuration in OpenLDAP. Have fun testing. You're getting well ahead of yourself; first you have to demonstrate that your code is correct, before testing its performance. Some of the most common replication scenarios for OpenLDAP will immediately fail with BDB replication, simply because BDB assumes identical configurations on all servers. As such, any performance measurements you make are purely academic. If you're looking for a good learning exercise, why not write some code that will actually be useful... > ----Seuler > > > 2006/12/14, Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>>: > > This is a pointless exercise. > > > --On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi )" > > <seuler.shi(a)gmail.com <mailto:seuler.shi@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. > > OpenLDAP mirrormode allows automatic promotion of a slave to a master. > > Using LDAP for the control protocol is far more portable. It provides an > open, standard protocol for managing all of the servers. Using > back-config on each server will allow you to tune all of the server > parameters, including the underlying BDB parameters, from anywhere on > the network, using any of a variety of LDAP-enabled clients. > > Using LDAP for the replication protocol is far more portable. It allows > data to be replicated to any LDAP-aware server, not just other OpenLDAP > servers. > > Relying solely on BDB replication does not provide such power or > flexibility. > > >> 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. > > Transmitting a single LDAP write operation over the network is far more > bandwidth-efficient than transmitting the many database pages that will > be dirtied by a single LDAP write operation. > > >> Would you tell me why OpenLDAP do not support BDB > >> replication? > > Because BDB replication offers no advantages for OpenLDAP's use cases. > > >> 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. > > The only way to make it work is by removing all of the back-bdb caching > mechanisms. Performance will be extremely slow. You will lose a > significant degree of usability and gain no benefit in return for this > effort. -- -- 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/

1 0

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Quanah Gibson-Mount 14 Dec '06

14 Dec '06

--On Thursday, December 14, 2006 3:58 PM +0800 "石斌(Seuler.shi)" <seuler.shi(a)gmail.com> wrote: > > I have solved the problem just now. The BDB replication can work well > with OpenLDAP. I doubt that it really does. In any case, if you want to discuss this, keep it to openldap-devel and not my address. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel