[Samba] Compareing backends

[Adam Tauno WIlliams]

> > How does the speed of SQL compare to the speed of LDAP?  If the speeds 
> > are comparable, why bother with LDAP, which doesn't handle writes very 
> > well?

Why won't this claim die?! LDAP handles writes just fine,  LDAP is not
an RDBMS, it is different.  Our DSA processes thousands of writes per
day without incident.

You are probably facing (a) poor configuration or (b) broken/buggy
packages.  The OpenLDAP packages of most distros are just terrible.

> I can't comment on the speed, 

Lookups in OpenLDAP are consistently faster than an RDBMS, at least in
rudimentary the tests we've run here (Informix Universal Server 9.40UC2
vs. OpenLDAP 2.2.14).  Assuming correct indexing of course.

If your OpenLDAP performance is bad, you need to look at your config -
and consult OpenLDAP specific forums.

> but as for the reasons for LDAP, some of 
> us need fully networkable and redundant directory information 

And if you don't need these things why no use the TDB backend?

> structure.  Also, aside from simply handling posix and sambaSam info, 
> ours also does automount information, as well as a custom built 
> directory security enfocement suite.  Our mail server runs aliases off 
> of it, and our intranet authenticates against it using posix groups for 
> permissioning. 

Yep.  And we have bind (DNS), DHCP, etc... using the Dit as well.  All
relevant information replicated and accesible via a single point, makes
administration much easier.

> Does sql do all that? oh yeah, and be distributed.
> Now here's one for you to try... if you want SQL someplace, how about 
> configuring your ldap (assuming openldap) daemon to use back_sql?  

back-sql is useful for proxying data from existing SQL datasources, but
really not useful as a general purpose backend; and you loose many
performance advantages.

> I've seen the complaints about berkely-db being shoddy, that should take it 
> out of the equation.

Berkeley Db is very stable.  We've been using OpenLDAP since 1.2.x and
ONCE had a corrupted database; probably my fault.