The K Blag

In the Sun Directory Server, the Replication Manager has a special purpose; it is the ID which is used to push updates to replication consumer directory server instances. By this, it means it can update ANY entry in the replication consumer’s directory that is allowed to be replicated to. This ID must exist outside of any replication scope (ie: in the cn=config tree); there can be multiple replication managers if such a need arises (ie: one per replicated backend).

An example LDIF for creating a replication manager:

dn: cn=Replication Manager, cn=replication, cn=config
changetype: add
objectClass: top
objectClass: person
cn: Replication Manager
sn: Replication Manager
userPassword: password

Create a file with the above contents and save it to disk (I saved mine as /tmp/createrepman.ldif).

Update your directory server instance via ldapmodify to create the changelog database.

/usr/bin/ldapmodify -h host -p port -D ‘rootdn‘ -w ‘password‘ -c -f /tmp/createrepman.ldif

Official Sun documentation on the replication manager.

bookmark to

In order to configure replication in Directory Server 5.2, a changelog database is required on each master and replication hub instance in the topology.

As each of the 6 instances in this topology are going to be master instances, each is required to have its own changelog.

To simply things (at the expense of performance for larger installations), I created the changelog database inside the filesystem path of the installation (ie: /opt/ldap/slapd-ds0) for each instance.

The paths I used for the changelogdb are as follows:

ds0: /opt/ldap/slapd-ds0/changelogdb
ds1: /opt/ldap/slapd-ds1/changelogdb
ds2: /opt/ldap/slapd-ds2/changelogdb
ds3: /opt/ldap/slapd-ds3/changelogdb
ds4: /opt/ldap/slapd-ds4/changelogdb
ds5: /opt/ldap/slapd-ds5/changelogdb

I also have posted instructions on how to create a changelogdb.

bookmark to

For a changelog to be created, either the parent directory of where the changelog is to be created needs to be owned (and writable!) by the directory server user, or the changelog directory itself needs to be owned by the directory server user. In the LDIF example below, the changelog is created in the installation directory (/opt/ldap/slapd-ds0) with the maximum number of active entries to keep in the changelog of 999999, and the maximum number of days to keep information in the changelog of 7d.

dn: cn=changelog5,cn=config
changetype: add
objectClass: extensibleObject
objectClass: top
cn: changelog5
nsslapd-changelogdir: /opt/ldap/slapd-ds0/changelogdb
nsslapd-changelogmaxentries: 999999
nsslapd-changelogmaxage: 7d

Create a file with the above contents and save it to disk (I saved mine as /tmp/createchangelogdb.ldif).

Update your directory server instance via ldapmodify to create the changelog database.

/usr/bin/ldapmodify -h host -p port -D ‘rootdn‘ -w ‘password‘ -c -f /tmp/createchangelogdb.ldif

bookmark to

After installation, initial (non-replicated) configuration, and import of data into the initial master, we are now ready to configure these instances for replication. I’ve chosen to include command line examples; but if you wanted, you can do many of these steps via the console GUI.

The steps we need to perform are:

• Create the changelog
• Create the replication manager
• Enabling replication, per database back-end
• Create replication agreements, per database back-end
• Initialize replication agreements
• Enable the backends

bookmark to

Once upon a project, there was a requirement to create a 6-way MMR configuration. However, due to the limited (at the time) ability of replication to scale (supported) past 4-way MMR, a creative solution was needed.

For our purposes, we have 6 identical machines, named simply ds0 though ds5. The primary application for these directory servers was Sun JES Messaging Server 6.2 .

Installation of the directory server bits on ds0 was a custom installation, with itself (ds0) being the destination for any and all configuration information, both user and configuration.

Installation of the subsequent directory server instances were very similar, with the exception that they all pointed to the first instance (ds0) for configuration data.

This is an ideal time to perform any custom schema changes and/or indexing that is required on these instances.

The last step in this section is to import any user-data that will need to be replicated into the ds0 directory instance, as that is going to the instance that will initialize the others.

bookmark to