[Fedora-directory-users] Advantages of using FDS vs OpenLDAP?

Pete Rowley pete at openrowley.com
Fri Jul 8 18:57:18 UTC 2005


> -----Original Message-----
> From: fedora-directory-users-bounces at redhat.com 
> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf 
> Of Sam Tran
> Sent: Friday, July 08, 2005 10:59 AM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Advantages of using FDS 
> vs OpenLDAP?
> However according to that paper multi-master replication could lead to
> inconsistencies:
> http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt
> What do you think?

Well, the paper is not wrong - MMR is not an atomic write model (everything
in that draft stems from this fact), rather it is a loosley consistent one.
However that doesn't mean that MMR is not right for your deployment.  You
must consider how likely those problems are to turn up in your deployment,
how much that will matter, and how easily and quickly you can recover from
them - only you can answer that.

Balance the issues raised in that draft versus having only one master, which
means a single point of write failure without any write load balancing.  In
many (most?) larger deployments (and even small distributed ones) these
advantages far outweigh any issues that arise from lack of MMR lack of

To address some of those points directly:

4.2 allocation serial numbers

True the delete/add value trick to ensure atomicity of serial numbers does
fall down.  But nobody says you have to keep the entry in the replicated
portion of the dit (or in other words, the same entry), with just a little
admin overhead it should be simple enough to manually partition the
uidNumber space between servers - 4 billion possible values ought to provide
enough partition space such that it can be done once and forgotten about.

4.3 Allocation of single-valued authority information

A rehash of 4.2 but an example where the work around for 4.2 won't work.  I
wonder how many real world applications really do this though.

4.4  Entry resurrection

Actually I agree with this.  It has been something I have argued vigourously
against (and failed) in the past.  MMR still obeys the order of events of
operations (eventually) just like a single server for all operations EXCEPT
for delete which it will _reverse_, all other operations if replayed on a
single server will result in the entry ending up the same.  I called them
the undead entries.  Though Kurt does not raise the issue, I consider this a
security risk too.  Imagine a deployment where employees can update certain
attributes of their entry.  A simple script could keep a fired employee
entry from getting deleted (though _I hope_ that deployments use the account
inactivation features in such situations - you see my point.)

More information about the Fedora-directory-users mailing list