inuits/puppet-ds_389

Name: puppet-ds_389

Owner: Inuits

Description: Puppet module to manage 389 Directory Server

Created: 2018-02-23 14:20:08.0

Updated: 2018-02-23 14:20:10.0

Pushed: 2018-01-29 19:22:14.0

Homepage:

Size: 102

Language: Ruby

GitHub Committers

UserMost Recent Commit# Commits

Other Committers

UserEmailMost Recent Commit# Commits

README

389 Directory Server module for Puppet

Build Status

Table of Contents
  1. Description
  2. Setup - The basics of getting started with ds_389
  3. Usage - Configuration options and additional functionality
  4. Reference - An under-the-hood peek at what the module is doing and how
  5. Limitations - OS compatibility, etc.
  6. Development - Guide for contributing to the module
Description

This module allows you to install and manage 389 Directory Server, create and bootstrap 389 DS instances, configure SSL, replication, schema extensions and even load LDIF data.

SSL is enabled by default. If you already have an SSL cert you can provide the cert, key, and CA bundle, and they'll be imported into your instance. Otherwise, it'll generate self-signed certificates. Replication is supported for consumers, hubs, and suppliers (both master and multi-master), and there's a Puppet task to reinitialize replication.

Setup
What ds_389 affects
Beginning with ds_389
Examples Basic example 
ude ::ds_389

At a bare minimum, the module ensures that the 389 DS base package and NSS tools are installed, and increases the file descriptors for 389 DS.

You'll probably also want to create a 389 DS instance, though, which you can do by declaring a ds_389::instance resource:

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
rver_id    => $::hostname,
Usage
Instances

The primary resource for configuring 389 DS is the ds_389::instance define.

In our previous example, we created an instance with the server ID set to the hostname of the node. For a node with a hostname of foo, this would create an instance at /etc/dirsrv/slapd-foo that listens on the default ports of 389 and 636 (for SSL).

SSL

If you have existing SSL certificates you'd like to use, you'd pass them in to the instance with the ssl parameter. It expects a hash with paths (either local file paths on the node or a puppet:/// path) for the PEM files for your certificate, key, and CA bundle. It also requires the certificate nickname for the cert and every CA in the bundle. (pk12util sets the nickname for the certificate to the friendly name of the cert in the pkcs12 bundle, and the nickname for each ca cert to “${the common name(cn) of the ca cert subject} - ${the organization(o) of the cert issuer}“.)

To require StartTLS for non-SSL connections, you can pass in the minssf param to specify the minimum required encryption.

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
rver_id    => $::hostname,
nssf       => 128,
l          => {
'cert_path'      => 'puppet:///path/to/ssl_cert.pem',
'key_path'       => 'puppet:///path/to/ssl_key.pem',
'ca_bundle_path' => 'puppet:///path/to/ssl_ca.pem',
'ca_cert_names'  => [
  'Certificate nickname for the first CA cert goes here',
  'Certificate nickname for another CA cert goes here',
],
'cert_name'      => 'Certificate nickname goes here',
Replication

If you need to set up replication, you'd pass in the replication config via the replication parameter. At a minimum, it expects a hash with the replication bind dn, replication bind dn password, and replication role (either 'consumer', 'hub', or 'supplier').

Consumer

For a consumer, with our previous example:

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
rver_id    => $::hostname,
plication  => {
'replication_pass' => 'secret',
'role'             => 'consumer',

This would ensure that the replica bind dn and credentials are present in the instance.

Hub

For a hub, you can also pass in any consumers for the hub as an array of server IDs, and the replication agreement will be created and added to the instance.

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
rver_id    => $::hostname,
plication  => {
'replication_pass' => 'secret',
'role'             => 'hub',
'consumers'        => [
  'consumer1',
  'consumer2',
],
Supplier

For a supplier, you can pass in consumers, and also any hubs or other suppliers (if running in multi-master) that should be present in the instance. You'll also need to provide the replica ID for the supplier.

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
rver_id    => $::hostname,
plication  => {
'replication_pass' => 'secret',
'role'             => 'hub',
'suppliers'        => [
  'supplier1',
  'supplier2',
],
'hubs'             => [
  'hub1',
  'hub2',
],
'consumers'        => [
  'consumer1',
  'consumer2',
],
Initializing replication

Once replication has been configured on all of the desired nodes, you can initialize replication for consumers, hubs, and/or other suppliers by passing the appropriate parameters.

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
rver_id    => $::hostname,
plication  => {
'replication_pass' => 'secret',
'role'             => 'hub',
'suppliers'        => [
  'supplier1',
  'supplier2',
],
'hubs'             => [
  'hub1',
  'hub2',
],
'consumers'        => [
  'consumer1',
  'consumer2',
],
'init_suppliers'   => true,
'init_hubs'        => true,
'init_consumers'   => true,

You can also initialize (or reinitialize) replication with the Puppet task.

Schema extensions

If you need to add any schema extensions, you can can pass those in with the schema_extensions parameter. It expects a hash with the desired ldif filename as the key, and a source reference (either via puppet:/// or an absolute path on the node). Note that schema filenames are typically prefixed with a number that indicates the desired schema load order.

89::instance { 'example':
ot_dn           => 'cn=Directory Manager',
ot_dn_pass      => 'supersecret',
ffix            => 'dc=example,dc=com',
rt_db_pass      => 'secret',
hema_extensions => {
'99example_schema' => 'puppet:///path/to/example_schema.ldif',
Modifying existing LDIF data

If you need to modify any of the default ldif data, (typically configs) you can do so via the modify_ldifs parameter. It expects a hash with the desired ldif filename as the key, and a source reference (either via puppet:/// or an absolute path on the node). The ldif file is created and passed to ldapmodify to load it into the instance.

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
dify_ldifs => {
'example_ldif_modify' => 'puppet:///path/to/example_modify.ldif',

You can also declare those separately, by calling their define directly, but you'll need to provide the server id of the instance as well as the root dn and password.

89::modify { 'example_ldif_modify':
rver_id    => 'example',
urce       => 'puppet:///path/to/example_modify.ldif',
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
Adding new LDIF data

If you need to add any new ldif data, (typically configs) you can do so via the add_ldifs parameter. It expects a hash with the desired ldif filename as the key, and a source reference (either via puppet:/// or an absolute path on the node). These function similarly to the modify_ldifs param, but are passed to ldapadd instead of ldapmodify.

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
d_ldifs    => {
'example_ldif_add' => 'puppet:///path/to/example_add.ldif',

You can also declare those separately, by calling their define directly, but you'll need to provide the server id of the instance as well as the root dn and password.

89::add { 'example_ldif_add':
rver_id    => 'example',
urce       => 'puppet:///path/to/example_add.ldif',
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
Adding baseline LDIF data

If you need to load baseline ldif data that runs after any other ldif configuration changes, you can pass those in via the base_load_ldifs parameter.

89::instance { 'example':
ot_dn      => 'cn=Directory Manager',
ot_dn_pass => 'supersecret',
ffix       => 'dc=example,dc=com',
rt_db_pass => 'secret',
se_load_ldifs    => {
'example_ldif_baseline' => 'puppet:///path/to/example_baseline.ldif',

Note that while you can declare these via the ds_389::add define, puppet's resource load ordering may potentially result in it attempting to add the ldif before a configuration change that it requires.

Reference
Classes
Public classes Private classes Defined types

The following defines are typically called from an instance.

Tasks
Parameters
ds_389 ds_389::instance ds_389::modify ds_389::add ds_389::replication ds_389::schema ds_389::service ds_389::ssl
Limitations

This module is currently tested and working on RedHat and CentOS 6, and 7, Debian 8, and Ubuntu 14.04, and 16.04 systems.

Development

This module was developed with PDK.

Pull requests welcome. Please see the contributing guidelines below.

Contributing

  1. Fork the repo.

  2. Run the tests. We only take pull requests with passing tests, and it's great to know that you have a clean slate.

  3. Add a test for your change. Only refactoring and documentation changes require no new tests. If you are adding functionality or fixing a bug, please add a test.

  4. Make the test pass.

  5. Push to your fork and submit a pull request.

This work is supported by the National Institutes of Health's National Center for Advancing Translational Sciences, Grant Number U24TR002306. This work is solely the responsibility of the creators and does not necessarily represent the official views of the National Institutes of Health.