I'm going to describe this fairly succinctly so you can get up and running in as little time as possible. That being said you will probably need a small dose of luck as I've not experienced the same install of an IBM product the same way twice.

I also did the initial install on a VM using VMWare which came in handy as I had to nuke the VM a couple times getting over some hurdles. Additionally I did almost if not all the work from the Linux command line/Bash as root user.

I installed CentOS 6 64bit on my Mac as a VM (with GNOME). I previously had downloaded the various parts and pieces that make up the WebSphere 7 installer and manually combined them together from the ZIP's and TAR's provided (yes the parts came in two different compression formats). I downloaded this from the IBM PartnerWorld site so your experience may vary depending on where you get the software.

CentOS6 and WebSphere CM 7 installation

The installer I manually pieced together required certain 32bit Linux libraries to run despite the installer mentioning 64bit compatibility. If you install a clean version of the 64bit Linux version of your choice you may need to also download and install the packages mentioned on the website below:


The link is for Red Hat Enterprise Linux which CentOS is a free version of. CentOS does not come with Java installed. There are some good links on getting Java installed (and the symbolic link created for Java) online but I simply used the Package Manager to install Java and the 32bit packages. If you're missing Java it will tell you there is a problem with when running .'/install.sh' but it may simply die on you without warning if you are missing a 32bit package. For the longest time I could not figure out why the installer would fail until I switched to a 32bit CentOS VM and saw the installer work fine. (I then Googled and switched back to the 64bit VM)

With the correct 32bit packages and Java installed the installer should now work by running ‘./install.sh' from the directory you put the installer and it's files. Once the graphical installer pops up just follow the prompts. Once it starts installing feel free to read over the rest of this document or begin the OpenLdap installation. It took me about an hour for the installer to run all the way through. There are multiple status bars so don't get your hope up when you see the progress jump from 1% to 50% fairly quickly, there are still "6 steps" the installer will go through before finally doing some automated configuration.

OpenLdap 2.4 installation

Simply download the TAR and extract it and run the install script from the command line. I went with the Berkeley DB option. You may opt for the Package Manager instead of downloading the TAR. I prefer to go with the Package Manager only when it comes to core Linux packages as I'm somewhat of a neat freak with it comes to where non-core software is installed. I consider Java to be a core file and I don't understand why certain Linux flavors and Windows do not come with it pre-installed.

For the 2.4 version of OpenLdap there is a new configuration scheme. The typical slapd.conf file is no longer used and in fact in the package I installed actually came labeled like so: slapd.conf.bak. I had done an OpenLdap install on a Windows 2008 server VM a few weeks beforehand and that still used the slapd.conf file so either I caught OpenLdap between versions or the Windows version is different now.

To configure OpenLdap there are only a few lines in the config that need to be changed. Go to: /etc/openldap/slapd.d/cn=config/ . If you then do a ‘ls –l' command in the ‘cn=config' directory you'll see a few LDIF files. This is how OpenLdap, at least on Linux, is configured.

You'll want to edit (I used VI) the ‘olcDatabase={1}bdb.ldif ‘file. I changed the olcRootDN and had to add the olcRootPW which I created from the command line using the ‘slappasswd' command. Using ‘slappasswd' creates an encrypted password you can copy and paste from the command line into the LDIF file. Also change the olcSuffix property.

This is enough to do a ‘service slapd start' to start OpenLdap but you may want to copy over a DB config file first. Otherwise you may get a warning when starting up OpenLdap complaining the DB is not optimized or something only the lines of poor performance.

I ran this on the command line which moves the example config, renames it and puts it where it needs to be based on where OpenLdap installed it's files for me:

‘cp /usr/share/doc/openldap-servers.2.4.19/DB_CONFIG.example /var/lib/ldap/DB_CONFIG'

Feel free to run ‘service slapd start' after that and OpenLdap should be up and running!

I downloaded the free version of Apache Directory Studio which provides a nice graphical interface for configuring and setting up the various groups and users you'll need in OpenLdap. Also it is a great way to test your credentials work when connecting to OpenLdap.

You will need the following groups and of course at least one person in each group to satisfy WAS and WCM. They are (and feel free to use a scheme different from this, just pay attention to the CN and the object type which is groupOfUniqueNames):






To start with I simply had one person who was in all the groups, just to ensure basic functionality:

DC=justin,DC=com,OU=people,UID=admin (LDAP object of type inetOrgPerson)

Pay attention to the LDAP object types I've chosen here as you will use them when configuring the WebSphere properties and XML files to hook OpenLdap into WebSphere.

Once you have OpenLdap directory structure created and you are able to connect properly it is time for the hard part. Connecting it with WebSphere.

Configuring WCM to use OpenLdap

There are two files we need to be concerned with. One of which won't be mentioned in any of the installation documentation (read: Google searches) and you will know it is configured improperly because you will have errors in your start logs for WebSphere (located at /opt/IBM/WebSphere/wp_profile/logs/). Actually this is a good time to mention the logs, which you are bound to become very familiar with. With WCM you are going to be starting two servers. The WAS and the WCM. Each will have it's own folder in the /opt/IBM/WebSphere/wp_profile/logs/ directory assuming you went with the default wp_profile name during setup. In my directory I have both a server1 folder and a WebSphere_Portal server folder as well as a ffdc folder that WebSphere adds for additional log files. In this case server1 was my WAS and WebSphere_Portal was my WCM server each running on a different port.

The first property file you need to edit is:


You will need to change all the ‘standalone' properties in this file. The link below points at which properties you have to change as well as mentions some handy command line programs you must use to validate and configure the various bits and pieces of WebSphere that rely on this property file:


Apart from listing each of the items you must modify the link has some important steps which I've copy and pasted below:

1. Run the ./ConfigEngine.sh wp-modify-ldap-security -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory, to set the stand-alone LDAP user registry.

2. Stop and restart the appropriate servers to propagate the changes. For specific instructions, see the following link under Related tasks: Starting and stopping servers, deployment managers, and node agents.

3. Run the ./ConfigEngine.sh wp-validate-standalone-ldap-attribute-config -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory, to check that all defined attributes are available in the configured LDAP user registry.

You MUST get a ‘Build Successful' when you run the steps above otherwise something is wrong. It is easier to figure out what is wrong, if something does go wrong, in these steps than it is to start the server and parse through logs to locate the cause of the problem.

It is within these steps that I found a large problem. I believe either step 1 or step 3 for me failed to build successfully and it was thanks to a colleague, Phil Kedy, that I was able to figure out what was going wrong. The problem lied with this file:


One of the above steps modifies this file based on the properties you edit. Unfortunately for some reason, and this has happened twice in a row doing the exact same install, it missed two nodes in the XML. When these nodes are missing the configuration fails.

Under the parent node:

In this XML node you should have the following:





If the PersonAccount and Group nodes are missing you should add them manually and run back through all 3 steps.

Once all 3 steps work you can start up the servers and everything should be OK!

Refer to the logs for any start-up errors and bare in mind sometimes classloader errors in the logs may be referring to an incorrect WebSphere LDAP setting.

Good Luck!