[Pkg-openldap-devel] Adding schemas and ACL's to slapd.conf

[Soren Hansen]

On Sun, Jul 29, 2007 at 11:03:41AM -0700, Russ Allbery wrote:
> > b) I really think the most common case is that if you're installing
> > something that has its own schemas (samba, for instance), you want
> > your LDAP server to know about them.
> This may very well be the case, but I think there are major examples
> where it isn't.  It's certainly the wrong behavior for all of my
> directory servers, for instance.  On the other hand, I suppose that I
> can just not include schemas.conf, when schemas.conf is defined to
> include all the current schemas that are installed.  So I think I'm
> becoming convinced.

\o/  :)

> > This corresponds completely to web applications automatically adding
> > stuff to /etc/apache2/conf.d.
> I hate this behavior, and I've not been so unfortunate as to run into
> a web application package that does this.  It's almost always
> completely broken in the presence of virtual hosts.  All the web
> applications I use document the necessary configuration in
> README.Debian.

I believe the rationale is: If you start from a clean system, and just
apt-get install the-package, you should end up with something that is as
close to usable as possible without manual tweaking. I think it makes
sense (at least in the "I have no better suggestion" sense).

> > What is the canonical example of a package that provides a schema
> > that you'd not want to have installed?
> Samba comes to mind, although in that case maybe it would work to
> break the schema out into a separate package (there was some
> discussion of this at Debconf as well, but I don't remember it as
> completely). 

Seems sensible, if it's something people generally don't want.

> Also, there has been a lot of discussion of a separate
> openldap-schemas package that provides a variety of common schemas,
> and obviously not all of those should be enabled.

No, definitely not. Any package that would need slapd to use this schema
could create the proper symlink for it.

> I thought that didn't always work in edge cases with symlinks.  There
> was a bunch of discussion about that a while back.
> 
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421344
> 
> I'm not sure if symlinks in /etc get marked as conffiles; I'd have to do
> some experimentation.

Gah, you seem to be right. I consider this a dpkg bug, though.

>> I still think the idea of running the script from the init scripts is
>> the optimal solution. All it ever touches are the new acl.conf and
>> schemas.conf which clearly say "THIS IS AUTOGENERATED" or something
>> to that effect, so no local changes should be overwritten by
>> surprise.
> Ah, yes, okay.  I think I'm starting to get it now.  And people who
> don't want that behavior can just not include those files.

Exactly.

>> What I set out to do was to provide a for packages to add schemas to
>> the ldap server in a safe way, and I belive the result is just what
>> section 10.7.4 of Debian Policy suggests. I think it's completely
>> reasonable for a packaged to want to add a schema to the ldap server,
>> and I also find it completely reasonable to allow it do to so without
>> forcing the admin to fiddle with slapd.conf and manually run a script
>> from time to time.  If an admin really doesn't want this
>> functionality, it's really easy to stop using it (just remove the
>> "include /etc/ldap/schemas.conf" and insert only the includes he
>> really wants).
> 
> > What is the canonical way to add schemas to the ldap server now?
> There isn't one.  It's certainly a problem that needs to be fixed; no
> question on that.

I'm glad we agree!

So, to sum up: If I make the update-slapd-{acl,schemas} ignore
*.dpkg-{old,new} my patch could be considered for inclusion?

-- 
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20070729/6979c06a/attachment.pgp