[Pkg-openldap-devel] Automate access to cn=config from package maintainer scripts

[P. Kaluza]

Hi Mathias,

Mathias Gug wrote:
> Hi,
>
> Building on the work done to migrate to cn=config I've started to
> extract some common functionalities from slapd.scripts-common into a
> separate script (slapd-cfg). I'd like to get your input on the proposal.
>
> Here are two use cases:
>
> * Provide a package that creates a new slapd database using
>   back_ldap+pcache+nss_overlay.
>   
cool idea, i could think of a usecase for this ;-)
i guess the libnss-ldapd package should be split into two seperate
packages for nss module and daemon.

> * Create a package that creates a new slapd database using back_hdb and
>   loads a set of modules, schemas and DIT.
>   
Are you aware of the ldap-schema-common package I proposed last year ?
(
http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/2008-August/002980.html
)

It can already handle converting schema files into cn=config format, but
only allows offline insertion until now. Somebody from ubuntu (maybe
even you ? can 't find the mail, sorry) asked me to provide a version
that handles online import. Unfortunately I haven't found the time for
this until now, because I hadn't managed to solve the password problem
in a satisfactory way.

> All of that without prompting for a password to access the local slapd
> daemon at installation time.
>
> Design Overview:
>
> * use Authz module to map the local root user (authenticated via
>   SLAPI+peercred SASL) to a defined user (cn=localroot,cn=config) and
>   grant complete access to this user to the cn=config tree.
>   
This sounds like a much better solution than keeping files with admin
passwords lying around. The peercred access has to be set up offline,
but that could just happen on the next slapd upgrade.
This would of course only work for local script runs, which might be
enough for your usecases. (I'm mainly interested in automatic schema
installation from a daemon package postinst - but when this daemon is
running in a different (v)server, it's better to explicitly ask for
admin credentials on each installation anyhow.)

> * extract common functionalities from slapd.scripts-common into a
>   separate script that can be called by any maintainer scripts.
>   
I'd suggest for this script to have a not-slapd-specific name, so it can
later be extended to support 389ds (if that ever makes it off the ground
in debian-verse) without upgrading all affected maintainer scripts.

> Implementation:
>
> I've written a proof of concept available on launchpad [1]. As mentioned
> in the README file:
>
> [1]: https://code.launchpad.net/~mathiaz/+junk/slapd-scripts-upstream
>   
Looks sensible on first inspection. I will take it for a ride in the
next 1-2 weeks.

> slapd-scripts is a python module and a CLI to perform standard
> operations on slapd using cn=config:
>
>  * initialize a slapd configuration
>  * load a schema
>  * load a module
>  * load an ldif file
>   
longterm, you might also want to keep the following in mind:
 * exporting to ldif file (we already have this; other packages might
want to do backups on upgrade too)
 * unloading a module
 * uninstalling a schema (proved quite tricky, even offline, see my old
mail)
 * upgrading a schema ?
 * upgrading other parts of an automatically installed DIT (module
configuration etc.)

> It uses either the slap* command (offline mode - when slapd is not
> running) or python-ldap (online mode - when slapd is running) to modify
> the configuration of slapd.
>   
does it make sense to factor out the online / offline mode into two
subclasses, instead of the
   if self.slapd_conn is None
checks ?  They will only diverge more from here on.

Also atomicity would be a nice property to have (but short of
implementing a full scale backup / rollback solution will be near
impossible in the slapadd codepath).

Thank you for your good work !
  Philipp