[SATLUG] Active directory vs Linux

[Thomas Cameron]

On Sat, 2006-12-23 at 13:48 -0600, Justizin wrote:
> On 12/23/06, Thomas Cameron <thomas.cameron at camerontech.com> wrote:
> > On Fri, 2006-12-22 at 13:34 -0600, Justizin wrote:
> > > On 12/22/06, Thomas Cameron <thomas.cameron at camerontech.com> wrote:
> > > > On Wed, 2006-12-20 at 18:07 -0800, samuel detal wrote:
> > > > > How can I create a network in a active directory alike structure?? is it possible or in this aspect Windows is better than Linux....
> > > >
> > > > Not exactly AD, but you can use Fedora Directory Server, which is a
> > > > newer (and MUCH better) release of the Netscape Directory Server.
> > > >
> > > > http://directory.fedora.redhat.com/
> > >
> > > OpenLDAP also shares a history with FDS -
> >
> > Wrong.  OpenLDAP and Red Hat/Fedora Directory Server are from non-common
> > codebases.  They adhere to the same standards, but they go about it in
> > different ways.
> >
> 
> I consider this to be rather authoritative:
> 
> http://directory.fedora.redhat.com/wiki/FAQ#How_is_Fedora_Directory_Server_different_from_OpenLDAP.3F

Read it again.  The original developers of OpenLDAP moved on and
developed Netscape Directory Server.  Although there are definite
similarities, they are *not* from a common codebase.  Netscape DS was
proprietary code before Red Hat made it Open Source.

Have a look at http://directory.fedora.redhat.com/wiki/Features for the
features that RHDS has which OpenLDAP does not offer.

Not trashing the OpenLDAP project - it is obviously a highly capable
product.

> > > the main point of difference
> > > between these two is a theoretical debate over the nature of
> > > multi-master replication.  The developers of OpenLDAP, for some pretty
> > > sound reasons, depending on your implementation, maintain that
> > > multi-master replication can destroy the reliability of an LDAP store.
> >
> > Which is why the Netscape developers (who now work at Red Hat) coded a
> > highly reliable multi-master design.  RHDS provides highly reliable
> > time-based conflict resolution and very fast replication.  It also
> > provides for read/write and read-only replication (master and slave).
> >
> 
> Two-stage commit?

Natch.

> > > For instance, let's say you have some websites connected to your LDAP,
> > > and one allows people to update their mail address, while others send
> > > mail, say order status, based on this value.
> > >
> > > With Multi-Master replication, it's possible for the second site to
> > > fail to pick up the change from the first site, whereas with single
> > > master replication, while having less attractive failover potential,
> > > if there were a directory problem, it would be clearer because the
> > > e-mail would refuse to save.
> >
> > In large environments, most of my clients don't let any apps actually
> > talk to the master.  It's all through the slaves.  Any master-master
> > replication would happen "above" the layer where the apps talk to the
> > directory.
> >
> 
> That's immaterial - if I talk to a slave and its' master is out of
> sync, it's out of sync, piling slaves on top of replication nodes does
> not make replication faster.

Which is why the masters are left alone by client requests and allowed
to pass replication information among each other.  Decreases the risk of
those masters being out of sync.  Nothing can prevent all cases of
failure, dumb-ass fiber cuts and the like still happen, but the guys
from Netscape have done some pretty impressive work making sure that
replication is not going to be one of the issues you have to deal with.

> > > Again, this is something where you'll have to make choices.  I'm
> > > betting Google uses Multi-Master replication based on their
> > > master-less network topology.
> > >
> > > > If you need a commercially supported version of this product, see Red
> > > > Hat Directory Server at http://www.redhat.com/software/rha/directory/
> > >
> > > Yes and what's fun is even if you have a license for umpteen RHEL
> > > machines, you have to purchase a separate support contract for
> > > FDS/RHDS, afaik.  Even if you don't care about money, this can really
> > > slow your project down.
> >
> > RHDS support is available via a subscription, just like RHEL.  And
> > unlike many competing commercially-supported LDAP server (think Sun
> > One), Red Hat charges a per-server subscription as opposed to a per
> > object rate.  Compared to pretty much any other commercially supported
> > directory on the market, it's cheap - list price for RHDS master is
> > something like $13,500, no matter how many objects you have.
> >
> 
> I wonder if that's more than we pay for Oracle, which packages an LDAP gateway..

Couldn't tell you, but I suspect that RHDS is a lot more feature-rich
than Oracle's add-on LDAP stuff.

> > > I've decided to bypass caring about the difference in replication for
> > > time being, at ACM, by pointing our OpenLDAP at an Oracle 10g storage,
> > > though I'm not entirely excited about it.  BDB has major deadlock
> > > issues which arise in svn and I'd prefer never to see that happen to
> > > my directory.
> >
> > So quit messing with OpenLDAP and fire up FDS or RHDS.  It's easy, the
> > interface is straightforward, and it's time-tested.  When Netscape was
> > bought by AOL, the server products languished.  Red Hat bought the
> > server product line and got the staff at the same time.  Interestingly,
> > the vast majority of the Netscape staff have stayed at Red Hat.  They're
> > a pretty incredible group of folks.
> >
> 
> I hear similar things about the OpenLDAP folks..

No arguments there.  The OpenLDAP project kicks ass, no questions.  I
just think RHDS is better.  Of course, I *am* biased.

> Afaict, RHDS/FDS are still using BDB, which has serious deadlock
> issues.  

Not sure how "serious" I would call it.  You can potentially deadlock
but there are ways to make sure it doesn't happen (albeit at the cost of
lowered concurrency).

> I cannot for the life of me come up with another alternative
> to SQL RDBMS for storing LDAP data, as inappropriate as it is.

I am not 100% sure it is "inappropriate."  I absolutely understand where
it can be problematic, but I also see where using an RDBMS has a lot of
benefit.  I am torn.

> At least from where I sit, it's not a clear-cut decision..  

/me nods.

> I'm not
> convinced that RedHat has done any better at multi-master replication
> than anyone else.

I think Red Hat has a product which is at least as good as its
competition, and in most cases better.  Since Red Hat contributes more
the the F/OSS community than pretty much any other vendor out there, I
think it makes sense to buy from them.  BTW, it's "Red Hat," two words,
not RedHat.

> I do know that PostgreSQL can do some pretty neat
> stuff with slony these days.

Yup, although I like MySQL Cluster for sync replication and basic MySQL
replication for one-way async replication.  But then I'm a MySQL fan,
not nearly as familiar with PostgreSQL as I should be.

Thomas