The K Blag

I needed to determine the update time for a particular attribute for one of my customers.  I knew I had ran across how to get it from a csn attribute.

If you can obtain the CSN of an attribute, ie: from the nscpentrywsi operational attribute), the timestamp is the first 8 bytes of the CSN, in hex format.

ie:

nscpentrywsi: cn;adcsn-494d685d000000010000;vucsn-494d685d000000010000: The K

The timestamp in hex is: 494d685d

With a bit of perl magic, we can obtain the localtime value:

perl -e ‘print localtime(hex(”494d685d”)) . “\n”;’

Which returns:

Sat Dec 20 16:49:17 2008

bookmark to

One of the largest problems that I have noticed when doing directory deployments, are either invalid, or non-existent backups of their directory information.  They often assure peace of mind when things unexpectedly go wrong (a la unexpected power outages).

I’ve found a good reference to how to do backups with Directory Server 6; and won’t rehash them here.

In essence, it may become necessary to have a single instance dedicated to doing routine backups in a large environment.  This is because you need to be able to turn the instance to read-only for the duration of the backup.

bookmark to

Once the directory server replica’s are configured and initialized, the final step is to enable them to accept updates.

This step was added as there is a necessary catch-up time when initializing MMR (especially in a busy environment); where by the time an instance is initialized, it is out-of-date until all the subsequent updates have been propagated. When I had to do this the first time, I was working off static data, and didn’t need to worry about performing this when the updates have been propagated, as there were no updates.

The only instance and suffixes that do not need to be enabled are those on ultimate master, which had all the data initially. All other instances need to be enabled after the replica’s have caught up.

In summary, those instances are:

ds0: nothing needs to be enabled

ds1: user/group, o=internet, o=piserverdb, o=pab, o=comms-config, o=netscaperoot

ds2: user/group, o=internet, o=piserverdb, o=pab, o=comms-config, o=netscaperoot

ds3: user/group, o=internet, o=piserverdb, o=pab, o=comms-config, o=netscaperoot

ds4: user/group, o=internet, o=piserverdb, o=pab, o=comms-config, o=netscaperoot

ds5: user/group, o=internet, o=piserverdb, o=pab, o=comms-config, o=netscaperoot

I’ve created an example command set to enable a directory server backend.

bookmark to

In a MMR agreement, the consumer instance backend that has been initialized needs to be enabled before it can begin accepting replication updates. This is a feature to allow a newly replicated master to catch-up on changes that have occurred during the initialization.

An example LDIF of how to enable a backend:

dn: cn=replica, cn=“suffix“,cn=mapping tree,cn=config
changetype: modify
add: ds5BeginReplicaAcceptUpdates
ds5BeginReplicaAcceptUpdates: start

I created and saved the LDIF to enable this backend suffix as /tmp/enablesuffix.ldif; and ran the ldapmodify command to perform the enable.

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

More information about MMR convergence from Sun.

bookmark to

To be usable in an MMR, all the suffixes on each instance that are part of the MMR (or replication in general) need to be initialized from the ultimate master (where the data was initially loaded). As some of the instances are not directly replicated from this instance (as there are a maximum of 3 MMR agreements from this instance); but instances which do replicate to them can initialize that data.

In order to successfully initialize all the replica’s in a short amount of time, the first master ( where all the initial data was loaded ), first replicates to a counterpart; then they both replicate to another instance that had not been replicated before. With alot of data, this can take hours to perform.

One methodology I’ve used is:

1. ds0 initializes all suffixes on ds3
2. ds0 initializes all suffixes on ds1 & ds3 initializes all suffixes on ds4
3. ds0 initializes all suffixes on ds5 & ds3 initializes all suffixes on ds2

Do so in this manner will allow you to initialize all the instance suffices in a relatively short amount of time.

After initializing a suffix, before it can accept updates, it needs to have its database back-end enabled, which I’ll write about at a different time.

I’ve created a short example of how to initialize a replica.

bookmark to