I’ve been traveling a little bit last week, visiting a major customer in the UK (helping with their OpenDJ based directory service that has grown from 13 Millions entries to 17 Millions in a about 6 months).
Last week was also a busy week in term of news for ForgeRock. First, we’ve announced the release of OpenIDM 2.0, a major version of our real-time identity life-cycle management, provisioning and synchronization software product. OpenIDM 2.0 is a new release, but is already running in production at a few happy customers.
ForgeRock and Qubera Solutions have announced a partnership for the delivery of Standard-based Identity Services based on ForgeRock I3 Open Platform. Qubera Solutions offers workshops and migration tools to help former Sun Microsystems customers to move away legacy software solutions.
I’ve also came across a blog post from Martin Sandren, that positions ForgeRock as one of the challengers on the Identity and Access Management market. It’s an interesting reading and it looks like the previous announcement does start to address some of his concerns.
Martin was not the only one to talk about ForgeRock. Scott Mc Nealy has been nicely advertising about us on Twitter.
And finally, we’re expanding and therefore we’ve published a few job postings on our web site. I’m pretty confident that these are just a few to start with and we will have more, including some in our Grenoble Engineering Center.
Enabling replication between multiple instances of the OpenDJ LDAP directory server is pretty simple and straightforward. You can check for yourself in the Replication chapter of the Administration Guide.
But fully disabling replication can be tricky with OpenDJ 2.4, mostly because of a known issue with the dsreplication disable –disableAll command : OPENDJ-249 : Doing dsreplication disable –disableAll is throwing a javax.naming.CommunicationException when removing contents of “cn=admin data”.
We are fixing this issue in OpenDJ 2.5, but for those who have deployed OpenDJ 2.4 and want to know how to fully remove all references to a replica in the topology, here are the steps to manually disable replication :
Note, all these steps should be done using ldapmodify, or an LDAP browser such as OpenDJ Control-Panel’s Manage Entry or Apache Directory Studio.
- For each replica to be disabled connect to it on the admin port (4444) and:
- MANDATORY: set the “ds-cfg-enabled” property to “false” in “cn=Multimaster Synchronization,cn=Synchronization Providers,cn=config”
- OPTIONAL: recursively remove the entries beneath “cn=Multimaster Synchronization,cn=Synchronization Providers,cn=config” using individual delete operations. Note that the configuration backend does not support the sub-tree delete control, so this has to be done iteratively. This step is also not mandatory, since replication was fully disabled in the previous step
- MANDATORY: remove each entry beneath “cn=Servers,cn=admin data” except the entry itself. I find the easiest way to do this is to perform a sub-tree delete and then add back the base entry
- OPTIONAL: remove (purge) unused instance keys from beneath “cn=instance keys,cn=admin data” *except* own key. This step is really independent of replication: administrators should periodically purge unused instance keys anyway when they are sure that they are no longer needed (e.g. used for signing backups, etc)
- MANDATORY: delete “uniqueMember” in “cn=all-servers,cn=Server Groups,cn=admin data”
- On one of the remaining enabled replicas, connect to it via the admin port and:
- MANDATORY: remove each disabled server beneath “cn=Servers,cn=admin data”
- OPTIONAL: remove (purge) each disabled instance key beneath “cn=Servers,cn=admin data” (see 1.4)
- MANDATORY: remove each disabled server from uniqueMember in “cn=all-servers,cn=Server Groups,cn=admin data”
- MANDATORY: get list of all remaining servers from “cn=all-servers,cn=Server Groups,cn=admin data”
- For each of the remaining enabled replicas obtained in step 2.4 connect to it via the admin port and:
- MANDATORY: remove each disabled server(rsPort) from ds-cfg-replication-server in “cn=replication server,cn=Multimaster Synchronization,cn=Synchronization Providers,cn=config”
- MANDATORY: remove each disabled server(rsPort) from ds-cfg-replication-server in “cn=*,cn=domains,cn=Multimaster Synchronization,cn=Synchronization Providers,cn=config”
As I’ve posted last week, we organize a training on OpenDJ in Paris from Jan 24 to 27, 2012.
I’ve been told that there is a special one time offer on this training. If you book the training by Friday January 13th, there is a 20 % discount on the course fee, which bring down the price of the 4 days course down to 2350€.
Don’t wait and register today at email@example.com.
And if you still hesitate, here’s a couple of quotes from the people involved in the review of the materials :
“Firstly, I’m pretty blown away by the quantity and quality of the material. It is extremely impressive, well done! :-)”
“Hell, this is going to be a GREAT directory server course!”
The OpenDJ Administration, Maintenance and Tuning (FR-462) training is taking place in Paris from Tuesday January 24th to Friday January 27th 2012.
The course is mix of lecture and labs and is designed for system administrators, integrators, consultants, architects and developers that will be installing, configuring, administering and maintaining ForgeRock OpenDJ LDAP directory server. I’ve been reviewing the course materials, and I must say I’m really excited by it. The amount of information available in the materials is huge, and the hands-on exercises are very detailed and practical.
The training is definitely a must for anyone who is or will be deploying and managing OpenDJ. And as this is the first training for OpenDJ in Europe, I will be attending it as an observer, gathering feedback on both product and course, also possibly as an assistant to the trainer Bill Nelson.
The session will be hosted in Astec training facilities, right in the heart of Paris, close to Gare Saint Lazare and Boulevard Haussmann.
There are still some slots available, so enroll quickly by email to firstname.lastname@example.org.
2011 is gone and we’re back to work. Welcome in 2012. We ended the year beautifully and we’re hoping the new one is starting the same way. So far the signs are good.
On behalf of ForgeRock and more specifically ForgeRock Grenoble Engineering Center, I’d like to wish you a very Happy New Year ! May the year be even better than last one…