[SATLUG] Active directory vs Linux

[Justizin]

On 12/23/06, Thomas Cameron <thomas.cameron at camerontech.com> wrote:
> 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.
>

Why so aggressive in rebutting.  I really think you've been taken for
a ride on how much different RHDS is..

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

No, not at alll, actually, according to the website.  There is no
two-phase/stage commit in FDS, it's a timestamped "last one wins"
algorith, not "Multi-Version Concurrency Control" like you find in
Oracle, PostgreSQL, ZODB, and other "Modern" storage..

I'm gonna wrinkle my nose at this one.

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

What happens when you stretch 1,,500-7,000 miles of fiber between the masters?

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

How is it feature rich?  It complies with a standard.  That's like
calling a web server feature rich.

I want stable, reliable, and highly concurrent.

Feature rich is the last thing I want to hear in marketing for an LDAP server.

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

.. biased because .. ?

> > 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 would call it serious, and every programmer I know calls it serious.

Leave it to the career sysadmin who refuses to learn programming to
brush off complicated topics like 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.
>

It's inappropriate because the whole frakking point of LDAP is to have
a specialized database with more structure than an RDBMS.  RDBMS can
be used directly for authentication, but then you may have to write
SQL in 19 different apps so that they can all agree on a nonstandard
schema to use.

So, then if you put slapd on top you probably have a bunch of
writeable views and, meh, how many layers of translation can ya have?

I really think I am approaching the days of serving LDAP out of Zope.

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

Actually, Sun is the world's #1 Open-Source contributor today.

And, btw, it's "GNU/Linux" ;)

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

MySQL's replication sucks, which is why Google doesn't use it.  Tell
me what happens with 25 machines.

MySQL is just a step above BDB and SQLite.  These are tools for novice
programmers who are afraid to deal with their own i/o and concurrency.
 Basically, you buy into the assumption that MySQL offers you more
concurrency than you'd otherwise get, which is true if you don't know
what a semaphore is.

Meanwhile, my Zope applications serve data out of object cache when
the db master is down.

-- 
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/