[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: memberOf hidden?

On Tue, 2008-01-15 at 09:41 +0100, Pierangelo Masarati wrote:
> Andrew Bartlett wrote:
> >>> Or maybe one should recommend in a deployment note to
> >>> use this overlay with back-ldap?
> >> The deployment note should recommend to avoid using this overlay at all,
> >> except for the purpose it was designed.  I would recommend to avoid
> >> distributing it with OpenLDAP; rather, with samba4 for use with OpenLDAP.
> > 
> > While I don't want to be antagonistic about this, if it becomes a
> > situation where Samba4 has to distribute OpenLDAP overlays (rather than
> > have a reasonable expectation that distributions will pick them up as
> > part of OpenLDAP distributions), I'm worried about the logistics.
> > 
> > How would Samba best go about packaging, maintaining and distributing
> > OpenLDAP overlays?  How specific to particular versions of OpenLDAP are
> > overlays, when built as binaries?  
> > 
> > Also, how would I as an external package build an overlay against
> > OpenLDAP?  Would the normal results of an OpenLDAP installation be
> > enough?  (I'm just not familiar with this area). 
> > 
> > Fortunately, in this particular case I already handle on the client side
> > (where I prefer to handle most of this).  My philosophy is to do as much
> > as possible on the client side, as this will promote interoperability
> > with other directory servers, if and when they want to have Samba4
> > support as well.  But I like to at least ask the question, as the less
> > fiddling I have to do the better.  
> > 
> > I also think it could be useful to others in future, as transitions are
> > made from manual to automatic management of some attributes. 
> I was not speaking "officially"; I just wanted to note that we have a
> somewhat "loose" policy about external modules:
> - generally useful: get into servers/slapd/overlays/ and known to
> configure, so that they can either be statically built into slapd or
> built and installed as run-time modules
> - less generally useful: get distributed into contrib/slapd-modules/ and
> usually maintained lined up with the rest of the suite
> - even less generally useful: remain into the ITS in the contrib folder
> and, unless the contributor maintains them, they slowly fade away
> because of the evolution of slapd.

Thanks for spelling this out. 

> Specially developed modules that are mainly useful for interaction with
> Samba4, like those we're prototyping in these days, would be generally
> useful for Samba4 users/developers, but while in some cases they might
> be of really general usefulness even for non-Samba4 users, in other
> cases they are quite specific and occasionally violate LDAPv3 specs.  In
> that case, it is (as usual) a matter of drawing the line.
> I don't have any objection into maintaining and distributing, say, the
> contents of a folder contrib/slapd-samba4-modules, including a dedicated
> configure (or extending OpenLDAP's, or whatever), but I'd like to make
> it clear what modules are, let's say, recommended for general use and
> what are not, unless in the specific context of interoperating with Samba4.

This all seems quite reasonable.  I think we can make progress on this
basis, and if we are careful it should not hinder either Samba4 or
OpenLDAP's mission. 

Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

Attachment: signature.asc
Description: This is a digitally signed message part