[Samba] Samba and LDAP backend - howto docs problems?

[Graham Leggett]

John H Terpstra wrote:

> This is completely correct. It took me 6 weeks to document, test, and
> validate Chapter 6 of "Samba-3 by Example" - and it took 50 or so pages to
> sufficiently describe the steps that must be followed.
> 
> While entirely essential, documentation that is logical, comprehensive and
> comprehendable is not a trivial process.

 From my experience over the last few days trying to get Samba 
installed, I don't think the documentation is at fault - there are some 
basic design flaws in Samba that you only see if you come to Samba with 
new eyes, ie you haven't configured Samba + LDAP before.

1) Duplicated configuration

Samba's LDAP configuration exists in the smb.conf file. pam_ldap / 
nss_ldap's configuration exists in the ldap.conf file.

As these are two separate config files, what this tells me as a new user 
of Samba, is that Samba's LDAP handling is completely independant of 
nss_ldap's LDAP handling.

I learn however that this is _not_ so - if nss_ldap is not configured 
correctly, Samba + LDAP won't work. Which leads me on to ask: Why does 
Samba not read the LDAP configuration from ldap.conf by default, instead 
of asking for the same information a second time?

This is also a security issue - the root DN password for the LDAP server 
is stored twice. It is also a usability issue - six months from now is 
my replacement going to know that the LDAP password needs to be set in 
two places? Of course not.

Then comes smbldap-tools. This package is written in perl, which has all 
sorts of magic string handling available, to extract the info it needs 
from either ldap.conf or smb.conf. But instead - it has it's own config 
file, with it's own definition of the LDAP server contact details, and a 
_third_ copy of the LDAP root DN password. At this point, security is 
out the window, as is any hope that I will remember how the password is 
changed six months down the line.

2) Too Much Rope

When users / groups / etc are added to Samba via the normal Windows 
based admin tools, Samba allows the user to specify a script to do the 
job. This as a virtually infinitely flexible solution.

But the average (99% of cases) system administrator does not need an 
infinitely flexible system, but rather a system that will get the job 
done with as little fuss as possible, and in as standard a way as 
possible, so that third party LDAP database editing tools need not be 
modified for this particular system's quirks.

Too much rope here is a huge hinderance - as smbldap-tools does not seem 
to be laid out the same way as the Samba HOWTO suggests things should be 
laid out (as far as I can tell anyway), I must now go into code and edit 
it - which means I must brush up on my perl skills again to see what is 
going on.

To have to learn perl before you can configure something as mainstream 
as Samba means that something has been designed wrong.

Note: I am not pointing these things out so as to knock developers of a 
piece of software that once it's configured correctly, works great. I am 
pointing these things out because as a developer, it is hard to 
anticipate the approach that will be taken by a new user of the 
software, as opposed to an experienced user of the software.

Regards,
Graham
--