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 http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
Attachment:
signature.asc
Description: This is a digitally signed message part