[Pkg-openldap-devel] slapd: Replace default nis schema (with Puppet and replication)

[Ryan Tandy]

Hi Georg,

On Wed, Sep 14, 2016 at 12:21:03PM +0200, georg at riseup.net wrote:
>As I would like to user the 'memberof' module and overlay, to get
>'memberof' mapping working, I want to remove the currently default (?)
>nis schema and replace it with rfc2307bis. One way to do this is to
>manually stop slapd, remove the schema and replace it, fix permissions
>and ownership etc., and start slapd again.
>
>As this is setup is done via Puppet, I'm not really sure how do to this:
>At first I've tried to just do it after the installation, _before_
>setting up replication. However, this leads to errors like "empty
>syncUUID", which breaks the replication, I guess because of me doing
>this "by hand".

That's possible/probable, depending on what you mean by "remove the 
schema and replace it".

If you're currently using Puppet to manage or modify files under 
/etc/ldap/slapd.d - I advise strongly against that, as slapd considers 
them to be its private data (should really be in /var, #626911) and 
assumes the contents have been processed and validated already. Besides 
that, those files contain operational attributes that are internal to 
slapd (I guess you already discovered this) and are not really possible 
to manage externally.

>The other way works: Set up replication first, and after this change the
>schema. However, I'm still searching for a clever way to handle this via
>Puppet, because this task should be synchronized on all the servers.
>
>Quoting "New Features and Enhancements in 2.4" [1]:
>"In 2.3 you were only able to add new schema elements, not delete or
>modify existing elements. In 2.4 you can modify schema at will. (Except
>for the hardcoded system schema, of course.)" Up until now I've failed
>to find more information about this while digging trough the Internets:
>All sources which I read so far talk about the manual way.
>
>So, three questions:
>- Is it currently possible to remove the nis schema and replace it with
>  rfc2307bis, right from the beginning?
>- Does someone know of a "better way" to change the schema than doing it
>  manually?
>- Besides: Any hints, clever ideas, whatever, how to deal with this?

I'm aware of the following options for managing an existing directory 
via Puppet:

1- avoid cn=config altogether, ensure /etc/ldap/slapd.d => absent and 
   manage a slapd.conf file. This may stop working in a future OpenLDAP 
   release (maybe 2.6), but still works fine for now. You can still 
   declare a database instance using the 'config' backend if you want to 
   inspect the running config.

2- manage a static slapd.ldif file used to seed the config database; 
   whenever it's updated, stop slapd, remove the existing 
   /etc/ldap/slapd.d contents, and slapadd the updated configuration. 
   IMO this has no advantage over the slapd.conf approach.

3- find a module that teaches Puppet to speak LDAP protocol rather than 
   static files, and use this to manage the contents of the cn=config 
   tree, but not the files on disk. I think such a module might exist, 
   but I'm not able to link to it off the top of my head. In this case 
   you'd be able to declare that cn=schema,cn=config should have certain 
   child entries, that these entries should have certain 
   olcAtttributeTypes values and certain olcObjectClasses values, and so 
   on. Schemas may be fully managed in an online config, as you quoted 
   above.

There is also a preseedable debconf flag, slapd/no_configuration. It has 
the limitation that dpkg fails to completely install the package until 
it has been configured enough to be able to start the service (#596777), 
so it's not so useful with Puppet, which just considers the package as 
failing to install.

The way recommended by upstream is either to include the config you need 
in the initial ldif file used to bootstrap the config database (cf.  
/usr/share/slapd/slapd.init.ldif in Debian; #2 above if you have to make 
changes after the inital setup), or use LDAP operations to manipulate a 
running slapd (#3 above). Note that it is also possible (if less common) 
to replicate the config database from a master server; of course in this 
case you have the issue that your slapd configuration is managed 
separately from your other services' configuration.

Hope this helps.