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

[John H Terpstra]

On Wed, 10 Mar 2004, Graham Leggett wrote:

> John H Terpstra wrote:
>
> >>Samba's LDAP configuration exists in the smb.conf file. pam_ldap /
> >>nss_ldap's configuration exists in the ldap.conf file.
>
> > Samba works with OpenLDAP, Sun iPlanet (Identity Server), IBM Tivoli
> > Directory server, CA's product, Novell eDirectory, etc. So precisely how
> > do you suggest we integrate all of these plus Samba so there is no
> > duplication _AND_ so that the resulting code can be maintained?
>
> All the software you've listed are LDAP servers, I was referring to
> nss_ldap, an LDAP client whose config is found in /etc/ldap.conf, which
> as you explain below is required for a proper functioning Samba + LDAP
> system.
>
> I understand that nss_ldap runs on a number of platforms, which means it
> is reasonably safe to assume that /etc/ldap.conf will be there, and if
> it's not there, the existing LDAP config directives can be used as a
> fallback, or Samba can be taught other places to look for the system's
> LDAP config.

This gets very complex. The nss_ldap ldap.conf file has so far been
located in:
	/etc/ldap.conf
	/etc/openldap/ldap.conf
	/opt/nss_ldap/ldap.con
	/lib/nss_ldap/ldap.con
	/usr/local/etc/ldap.conf

just from sites and systems I have had to deal with.

>
> > In my opinion, Samba has to remain independant of ALL system tools.
>
> I agree, but Samba requires nss_ldap - if Samba is to maintain a
> separate LDAP config from nss_ldap, then I would say that Samba should
> not need the services of nss_ldap - it should be able to query this
> information for itself.

Nope. I covered that already. If Samba deals with identity resolution
directly then that will impose a priority that may invalidate particular
site needs to use NIS or some other form of identity resolution. Consider
the site that wants NSS operation:

passwd: ldap files nis winbind

A premeditated Samba based solution adds complexity and limits use. What
we have now permits the administrator to use the this type of solution.

>
> > Given that Samba is Open Source software, who has responisbility to affect
> > perfect integration? How will all the projects get integrated security and
> > authentication support?
> >
> > Just remember:
> > 	- The Samba-Team is not a massive corporation
> > 	- We do not control any other project we may depend on
> >
> > So precisely HOW can we solve all these difficulties? I can not provide a
> > better answer, other than the need for Open Source and Commercial open
> > public software standards - something I am already working towards
> > privately.
>
> By starting to address the fact that Samba is IMHO unnecessarily
> complex. Work should be done on finding ways to simplify the config and
> the operation of Samba, by looking for duplication and over-complex
> elements, and finding elegant ways to simplify them. Samba's ability to
> perform useful things doesn't amount to anything, if it takes a PHD to
> figure out how those useful things work.

In fairness, I believe the Samba-Team are doing this all the time. But
every time we add functionality it takes a while to arrive at sensible
defaults. Just look over the history of the project - you will see that
many things that once had to be condigured now default to sensible values.
We are addressing specifically new bleeding edge issues here.

>
> > The HOWTO is a document that aims to expound HOW the tools can be used.
> > The Samba-3 by Example book aims to provide working solutions. It is
> > unrealistic to attempt to do both in one book. Even as it is, the HOWTO is
> > too big. The major improvement I have planned for the HOWTO is improved
> > indexing - in time this will happen. As to content - please contribute.
>
> I think it would be far more valuable to spend time simplifying the
> software rather than trying to add even more documentation, of which
> there is already a significant amount.

That is happening, as I said above. Each of us who contributes to Samba
has to find some way to sustain our activities. I would encourage you to
contribute both ideas and code as your circumstances permit.

I appreciate the voice you have given this.

Cheers,
John T.
-- 
John H Terpstra
Email: jht at samba.org