[SATLUG] Active directory vs Linux

[Thomas Cameron]

On Sun, 2006-12-24 at 07:55 -0600, Justizin wrote:
> 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..

OpenLDAP is nice, no doubt.  But RHDS is a different product and is a
lot more capable and much easier to use.  I don't think I've been taken
for a ride.  I work with RHDS on a pretty regular basis and it is a
really solid set of tools.  I've always found OpenLDAP to be very
powerful but a PITA to work with.

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

You are correct, I was looking at a non-public specification document.
As of today, RHDS does not offer two-stage commit.

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

C'mon, Justin - what happens if monkeys fly out my butt?  You can
"what-if" all day long.  Bottom line is that multi-master replication
works fine with RHDS.  It's proven technology in use by a bunch of very
large enterprise customers.

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

Have you looked at
http://www.redhat.com/f/pdf/rhas/DirSecProductSheetDirectoryServer.pdf
at all?  I am talking not just about the ability to store and retrieve
data from the directory and present it in a standards-compliant manner.
I am talking about the security features, HA features, admin tools,
bundled apps like web based org chart and corporate phone book, things
like that.

> I want stable, reliable, and highly concurrent.
> 
> Feature rich is the last thing I want to hear in marketing for an LDAP server.

Well, with RHDS you get reliability, concurrency and rich features - if
you design it correctly.

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

Because I am employed by Red Hat.

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

What, did you all chat about it between passes of the one-hitter?

> Leave it to the career sysadmin who refuses to learn programming to
> brush off complicated topics like concurrency. :/

Too funny.  So tell me, what exactly does "Independent Interactivity
Architect" really mean?  Sounds like a euphemism for "I can't keep it
together to hold a real job so I'll call myself a consultant."

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

-1 for gratuitous geek reference to BSG.  :-)

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

Wow - you even gripe when I agree with you.  Some things never change,
eh Justin?  What's next, rambling, incoherent threats of calls to the
FBI left on my voice mail?  That was some seriously funny shit, you
ought to do something like that again.

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

Bwahahahahaaaa!  How on Earth do you figure that?  Have a look at
http://people.redhat.com/tcameron/.RHAT-and-OSS-Community/ and then tell
me what Sun has done to match.

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

Only in RMS's tweaked little mind.

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

<yawn>

I hoped that when I saw you active on this list again that it would be
possible to have a civil discourse.  I guess the leopard doesn't change
his spots after all.

Thomas