[Pkg-openldap-devel] Can a package modify slapd.conf in its maintainer script?

[Alessandro De Zorzi]

P. Kaluza wrote: 
> You have already stumbled upon the ldap-schema-common package i'm
> building currently.
> This was born out of a discussion at last year's DebConf, that
> shipping schema files within the daemon packages is not all that
> practical (as they often end up on different servers or vservers), and
> that we should ship more "commonly wanted" schemas¹ in an extra package.
I take a look at ldap-schema-common and seem a good solution use tools
to manipulate
ldap configuration (like update-ldap-schema) but I do not think include
ALL available schema
is possible and convenient.

My opinion is that package should provide own schema(s). And enable it
not directly but trough
a tool like update-ldap-schema or another way.

Package that provide schema can specify Conflict with other to avoid
error, because we know certain schema
are in conflict. When package removed, schema will be removed, but data
in LDAP base will be retain,
this is not a problem for slapd ;-)

I interested about this problem since a RC bug opened for phamm-ldap
package due my package edit
slapd.conf file (now phamm-ldap do not change anymore slapd.conf)
>
> The second task, that followed from this, is to register only the
> _wanted_ schemas with the LDAP daemon.
> I agree with Russ that we should only install schemas the admin
> explicitly asked for.
I agree, in my example "Phamm" (a front-end written in PHP that use LDAP
as back-end) provide 2 packages
phamm (only with a PHP code) and phamm-ldap provide phamm.schema, create
a empty ou=hosting DB,
provide custom acl and restart slapd.

In many case schema(s) provided by packages are inside the main package
(ag. samba.schema or amavis.schema)
if administrator want install LDAP base in different machine where samba
or amavis do not works, this forces to
install whole package.
> In your bugreport you propose a "schema drop" directory in two
> variants. (simple drop directory and schema-{available,enabled}
> symlink farm.)
> While theoretically slapd could even be patched to automatically pick
> up all schemas in a certain dir, the obvious and sometimes rather
> subtle interactions between schema files and existing databases
> require IMHO a more sophisticated approach. (E.g. you cannot slapadd
> database dumps referencing unknown schemas.)
Patch slapd to pick up schemas in a certain dir seem a hard work not
convenient if in future will be used cn=config

The idea I propose is very simple and start from a consideration:
"include lines" inside slapd.conf simply include lines of other files.
So it is possible include a empty file and file that contains other
includes lines, in this way:

slapd.conf ==include==> custom.schema ==include==> ?.schema

salpd.conf  always unchanged, slapd rewrite custom.schema (initially an
empty file) when restart and
if custom directory contains .schema (or schema enabled) slapd will
include these schema files.
> The other point you implicitly raised is also an important one: what
> changes in general can other packages make to slapd's configuration ?
> add ACschLs ? add their own databases ?
at this time packages need to provide and enable schema, unfortunately
provide ACL is more complex
because if installation-A with schema-A use ACL-A and installation-B
with schema-B use ACL-B and
I want to install both, I will include A.schema and B.schema
consecutively but this is not true for ACL :-(

create own database is operation should do the package, ag.
phamm-ldap.postinst create own ou=hosting
and a role in this way:

cat << EOF | ldapadd -x -D "$binddn" -w "$bindpw" -h localhost
dn:o=hosting,$basedn
objectClass: top
objectClass: organization
o: hosting
description: hosting root

dn:cn=phamm,o=hosting,$basedn
objectClass: top
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: phamm
userPassword: $phammpw
EOF

Alessandro De Zorzi