Re: [tlug] next meeting

[Blomberg David <dblomber@example.com>]

On Wed, 2004-01-14 at 12:56, Masato Taruishi wrote:
> On Wed, 14 Jan 2004 11:49:05 +0900
> Blomberg David <dblomber@example.com> wrote:
> 
> > > > > I just joined this mailing list because I'll have a speech about LDAP
> > > > > at the next meeting. Unfortunately I'm not good at English, so I'd like
> > > > > to say sorry about the speech. 
> > > > Does this mean you can explain all the strangness of getting LDAP up and
> > > > running correctly :)
> > > 
> > > I can explain if it's in Japanese :)
> > > 
> > > I won't speak about getting started LDAP environment, but the syncbackup idea
> > > itself because I'd like to practice English before explaining syncabckup to
> > > LDAP guys of IETF and because I can't explain the strangeness of getting LDAP up
> > > in English. If this topic is not appropriate for tlec metting, I won't have the
> > > speech itself.
> > We are looking over your web site (A colleague of mine who also works
> > Linux and is helping me on a few LDAP issues)  I am a little unclear on
> > one matter that does not seem to be addressed on the site ----
> > 
> > How do you compare to OpenLDAP in multimaster compiled mode??? and what
> > advantages do you offer over multimaster as I still need to recompile
> > either way :) ???
> 
> At first, syncbackup can be used in multimaster environment, too. 
> syncbackup is nothing but one way to replicate modifications to other servers.
> If we compare multimaster, we should compare it with single-master.
> 
> So if we compare syncbackup, we should compare it with slurpd based replication.
> This can't guarantee complete consistency between several LDAP servers because
> of slurpd design problems itself and also because of asynchronous replication.
> 
> One big problem of slurpd is that it doesn't have consistency framework but just
> makes reject file. If one modification fails, then all other modifications may
> fail because of the previous failure. In addition, slurpd is difficult to setup
> slave servers on demand. We must synchronize the initial database of a slave server
> and the begging of replication to the server.
> 
> In openldap 2.2, it provides syncrepl which supports eventual consistency. This makes
> easy to maintain several slave servers, but it's a still asynchronous replication.
> If the server is broken before propagating modifications, these modifications which
> are not propagated to other servers are lost. syncbackup doesn't conflict with syncrepl.
> Actually, syncbackup uses syncrepl internally. syncbackup provides guarantees such that
> modifications are actually propagated because syncbackup waits for the success result
> from other servers, while syncrepl doesn't, it only sends modifications.
> 
> I guess 'multimaster or single-master' is a different topic. Do you want to discuss
> about this topic, too?
oouch I may have been working on a sync issue for a while now for no
reason then (its an inconsistent link and using slurpd for
replication-and well its been inconsistent in the data as well.)

Actually I have been digging for more info on Multimaster set ups and I
have the basic how to but openldap mailing list is very quiet on the
subject.
(I am working on a distributed setup premise one ldap master in US and
the other here and making sure they stay in sync without too much
administrative overhead)
> 
> --- 
> Masato Taruishi - VA Linux Systems Japan Inc. <taru@example.com>
>                 - Debian Project <taru@example.com>
>                 - Debian JP Project <taru@example.com>
-- 
David Blomberg
AIS, APS, ASE, CCNA, LCP, LCA, Linux+, LPI I, MCP, MCSA, MCSE, RHCE, Server+
Nihon Libertec
dblomber@example.com