[lpi-discuss] General comments on LPI levels (Openldap)

Bryan J. Smith b.j.smith at ieee.org
Mon Sep 19 12:26:55 EDT 2005

Matt Benjamin <matt at linuxbox.com> wrote:
> Let's not bother arguing about this, since we agree.

Fair enough.

> But if I wanted to fill up everyone's inbox with more
> unwanted blather about OGO, MAPI, and other things I
> didn't originally mention, I'm sure I could.  So there.

???  I'm not going to even respond to that.

> I know more about the OpenLDAP efforts than I do the
> Redhat ones, but I have reviewed their developer lists,
> and it doesn't appear they are eclipsed by NS DS (stading
> corrected to include the other stuff) or Redhat's new 
> strategy, so far.

As always, most OpenLDAP capabilities are also usable by NsDS
and, as Red Hat GPLs more and more, vice-versa.  My argument
was _not_ that NsDS should "replace" NsDS.

It was ...

> And part of my point, and I think the original poster's
> point was,

That any so-called "shortcomings" to OpenLDAP for which has
allegedly caused the situation that "Microsoft has won" was
simply not true in the least bit.  The original poster was
seemingly suggesting to remove anything but ADS from
consideration, making the point that the world is Microsoft,
and OpenLDAP and NDS/eDirectory were not capable.

I only offered NsDS as proof this very much was _not_ the

At this point, it only seems that you are taking one part of
my posts, and applying them to whatever viewpoint that
disagrees with yours.  I'm trying to show there _are_ capable
Linux-based solutions at the same time as _not_ trying to say
"we should only test on this one."  Please don't take my
posts as such, and I think we will be fine.

> the OpenLDAP efforts have been free software efforts 
> far longer.  That matters.

Yes, it does.  Which is why anything that is universal to any
Linux-based network authentication, directory, file and/or
naming should _start_ with such standard Freedomware.

Again, my statements with regard to the original poster were
on matters of limiting such to ADS-Samba services.  God knows
that OpenLDAP and NsDS used about the _exact_same_ client
configuration files, which are much, much different than

So, again, I ask you to recognize the _context_ my arguments
were made in.

> Also, sometimes an expensive commercial project that goes
> GPL is eclipsed by something else.

Of course.  But Red Hat has a good history of not doing such.
 They typically buy up the _most_popular_ solution for
mission critical enterprises and GPL it.  And in some cases,
when a former GPL vendor "closes shop" because they've
reached critical mass, Red Hat buys them to re-GPL their

> Surprisingly, OCFS2 may have eclipsed Redhat's Sistina GFS.

Some would differ.

> Redhat puts lots of people to work on a number of 
> things that will never shake the world, for that matter,
> not that we need to care.

They do control a lot of core Linux capability though.  And
their greatest contribution last year was gobbling up NsDS
with certificate services.

Again, I wasn't saying it should be favored over NsDS.  I
said native Linux network authentication, directory, file
and/or naming service should be favored over ADS-Samba. 
Since, from the client viewpoint, OpenLDAP and NsDS are very,
very similar, your projected arguments are moot.

> What?  Not to judge from the developer lists.  And whose do
> you suppose are busier?  Hint:  taint Fedora DS.

> Yet I have helped companies move OFF NS LDAP to other
> things, such as OpenLDAP, so I hardly see this as the
> panacea you do.

But what version were they running?  Many were running old
versions and did not want to pay for upgrades.  Now that NsDS
is Freedomware, I'm sure some wished they would have stayed
now that it's GPL.

> OpenLDAP does not severely lack a Java admin tool.  I doubt
> it lacks admin tools at all, for many applications.
> OpenLDAP has a "fully replicating back-end" using two
> replication protocols.  Syncrepl has properties that some
> sites would prefer to multi-master replication, in 
> fact.  But you already knew that.

I prefer multi-master replication.
But that's my professional choice, not an absolute.

> The AD synchronization and certificate service features are
> very interesting.  Maybe this is the killer, I don't know.

Again, I _only_ brought up this when the original poster went
on about ADS-Samba.  If authentication against ADS is the
key, let's do it in a way that not making the Linux network
ADS' bitch.  Sorry for the language, but that was my intent.

There are _other_ synchronization solutions out there --
mostly commercial.  NsDS is the only solution -- end-to-end
-- that is now GPL and well-integrated.  That was my only
point to the _original_ poster.

> As you point out, however, there are other ways to perform
> both these tasks, free and commercial, however, so maybe
> not, too.  And what about Samba4?  Their rolling their own,
> more power to them...

I see Samba taking on too much that is too specific.  They
are  moving from a piecemeal Windows services solution to an
all-in-one that is rather limiting in capability, while not
being a true all-in-one.

But that's just IMHO.
> The implication you have made is that OpenLDAP is much less
> than it is, in a manner that reads like IT glossy magazine
> cheerleading, and I am pointing it out, that is all.

In the context of the original poster, I made my points.
It was _not_ an argument that NsDS should be "the standard"
for any LPI test.  It should be a peer to OpenLDAP.

And from the standpoint of the client, there is little
difference between OpenLDAP and NsDS configuration anyway --
_unlike_ ADS-Samba.

Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)

More information about the lpi-discuss mailing list