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

[P. Kaluza]

Hi Alessandro,

Alessandro De Zorzi wrote:
> P. Kaluza wrote: 
>   
> 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.
>   
Yeah, although I really want to make schemas available easily, 
collecting all will be impossible.
Some schemas are licensed very... interestingly.

That's why I intended update-ldap-schema to be called by other packages 
from the beginning.

At the moment you just drop the schema in a certain dir.
Probably I should add a call like
   update-ldap-schema --register phamm-ldap.schema
to be future-proof.

> Package that provide schema can specify Conflict with other to avoid
> error, because we know certain schema
> are in conflict.
schemas shouldn't generally conflict IMHO, if they are packaged and 
maintained properly.
(At least if two schemas contain the same attribute we can package 
around that. If they choose the same name for two different attributes, 
we're in trouble though.)

Schema dependencies on the other hand are yet to be solved.
> When package removed, schema will be removed, but data
> in LDAP base will be retain,
> this is not a problem for slapd ;-)
>   
Erm.. yes it can be, e.g. when the system-wide ACLs name an attribute 
specifically.
In that case slapd will complain loudly on the next start.

> 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.
>   
phamm is a good example. I was planning to include the phamm schema in 
the package, until I saw that phamm-ldap is mostly a schema package already.

> 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.
>   
agreed, that's what I want to eliminate first and foremost.
So i'll continue collecting schemas for now.

> 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
>   
That's what update-ldap-schema does for slapd.conf style setups.
Try
    touch /etc/ldap/slapd.conf
    update-ldap-schema --enable evolutionperson
    cat /etc/ldap/slapd-schema.conf

> 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 :-(
>   
at least the ACLs would have to be written very carefully and included 
in a known order.
Soren did something ACL-installation related last year.

probably this only make sense where your package manages part of the DIT 
completely on its own (like your ou=hosting), not where you reuse e.g. 
the existing ou=People.
overall I think in-tree ACLs will be the way to go here eventually.
> create own database is operation should do the package, ag.
> phamm-ldap.postinst create own ou=hosting
> and a role in this way:
> [...]
>   
Also remember upgrades. Your package maybe will want to automatically 
adapt the DIT structure.

BTW. using organizationalRole for this kind of programmatic account is 
interesting, at least when you can map it to a known administrator. I've 
just been using account for that until now.


Ciao,
  Philipp