Running The Population Wizard

The first thing we’re going to want to do once the Connections applications successfully install is test them by logging in as a regular user.  To do that the user must have a profile in the PEOPLEDB or Connections will throw an error and the easiest way to ensure that exists is to run the Population Wizard.

The Population Wizard is a simple tool that asks a series of questions such as where is your LDAP directory, where are your DB2 databases, and where is TDI and uses those answers to run a one off script using TDI to import all users into Connections, creating them a profile along the way.  It’s designed to work in only one direction (you can pull information from LDAP to databases only, not the other way around).

For a test environment or a very small manually-maintained environment you could run the PopulationWizard to update the databases whenever you want but for production it’s not really workable.  However, this is just to ensure we have some data in place that we can use for testing.  We will work with the custom TDI scripts later to fine tune what we want.

To run the population wizard look in the “Wizards” directory from the ConnectionsWizards download.  The file will be called populationWizard.sh (or populationWizard.bat).

skitch.6

skitch.5

The JDBC drive path must contain the drivers for your database platform.  If you aren’t running TDI on the same server as your databases you will need to copy the drivers from the database server to the TDI server to reference them here.

The User ID is the account granted full rights to the PEOPLEDB database.  This can often be a custom account and not (as in this case) the instance owner.

skitch.4

Here we tell the wizard where our LDAP server is and how to connect to it.  If you are using a secure port such as 636 make sure you check the box for “Use SSL communication”

skitch.3

These are the bind credentials to login and query LDAP.  They aren’t stored anywhere in this activity or used for any purpose other than running this one-off wizard so any credentials would do.

skitch.2

This shows the sample mapping of LDAP attributes to database fields. For example “mail” in LDAP will map to the field “Office Email”.  On this screen we can choose what attributes to map where and even if we want to map attributes at all.  Anything we don’t map won’t be populated with data and will appear as empty in Connections.

Once the populationWizard completes it should report that it imported your users.  To do this it wrote instructions to properties files and ran script files stored in the location:

/Wizards/TDIPopulation/linux/TDI –

The files it wrote our instructions to are:

profiles_tdi.properties
solutions.properties
mapdb_repos_from_source.properties

The script files it ran were:

collect_dns.sh
populate_from_dn_file.sh

The activity is recorded in /Wizards/TDIPopulation/linux/TDI/Logs.

We’ll come back to this later when we start customising our syncing activity.

Installing TDI

Tivoli Directory Integrator is used to move data between our LDAP source (in this case Domino) and our DB2 (or SQL or Oracle) profiles database (PEOPLEDB).  IBM supply a range of Wizards and batch files to achieve this and they all depend on having TDI installed somewhere.

Once the TDI installer is extracted we run ./launchpad.sh in Linux (or launchpad.exe in Windows) to start installing TDI.

On linux this may fail because there is a script that validates if a supported browser version is installed.  The script is a bit old and only checks for Firefox numbers beginning 1x and 2x – we’re currently on Firefox 35 and growing. To workaround that validation modify the file browser.sh in the launchpad directory as follows

skitch.13

The regedit syntax using [1-9][0-9] should cover any version Mozilla release for a couple of years 🙂

Now launchpad.sh should run

skitch.10

skitch.9

I choose a custom install because we only need a limited set of features installed for our purposes.

skitch.8

In theory I only need the Server component – the CE (Configuration Editor) is for creating and managing AssemblyLines.  In a simple install we don’t use it but I like to install it regardless and it’s very likely we will use it to customise our directory sync activity.

skitch.7

The working directory should not be a static choice. Each time one of our TDI scripts runs, the parameters for that script will come from the directory it exists in.  By not setting a working directory we are able to run multiple scripts from different locations with different settings.

Once TDI 7.1.1 is installed we need to patch it to fixpack 5 before doing anything further. After downloading the fixpack (7.1.1-TIV-TDI-FP0005.zip) and extracting it there will be a file called UpdateInstaller.jar in the extracted directory.

Copy the new UpdateInstaller.jar file to /opt/IBM/TDI/V7.1.1/maintenance

Copy the extracted fix TDI-7.1.1-FP0005.zip to a convenient location – in this case I’m using the directory where I’m going to run the update from /opt/IBM/TDI/V7.1.1/bin

skitch.1

To apply the fixpack we run ./applyUpdates.sh -update <fixpackfilelocation>

 

skitch

Once the updates have been applied we can verify it ran successfully using:

./applyUpdate.sh -queryreg

which shows us both components installed and patch levels for each.

In our environment we are installing TDI on the same server where DB2 is installed but if we weren’t we would have to copy the DB2 library files over to the TDI server so the two can communicate.