Rational Application Developer Pattern tips and tricks

Authors: VictorSosa
Build basis: Rational Application Developer Pattern

Introduction

IBM Software Delivery and Lifecycle Patterns is a set of patterns that simplify and accelerates the procurement of development environments on private clouds based on IBM PureApplication Systems (PureApp) and IBM Workload Deployer (IWD).

This offering contains a Virtual System Pattern (VSP) for quickly deployment of Rational Application Developer (RAD) environments. This pattern is called Rational Application Developer Pattern v8.5.1 iFix 1.

This article shows some tips and tricks to make the procurement of RAD instances in a more standard way across development teams while providing more flexibility in the customization of the deployments.

Shorten the deployment parameters amount

The RAD pattern contains a lot of deployment parameters which allow a great customization for each deployment, but sometimes standardization across environments is more desired.

In order to achieve this, you can provide default values to the deployment parameters in the pattern and lock them. This way, you will have less parameters to fill and will speed up your manual provisioning steps.

In theory, passwords are the only parameters that should be kept open so that each instance has its own credentials at deployment time. In practice, the deployer can specify generic passwords (defaulted and locked for agility) and let users to customize them. In this case is preferred to have script packages that forces the user to change passwords once he/she is logged in for the first time. See Force users to change temporary passwords section.

Clone RAD pattern for different customizations

On of the most simplest yet powerful features in PureApplication Systems is cloning artifacts. This allows you to copy the content of an artifact so you can customize in a different way but reusing the functionality.

This is very useful in virtual system patterns context where you can import one single pattern and reuse the topology but with different deployment scenarios by defaulting, locking and unlocking the deployment parameters.

In RAD pattern, there are some deployment parameters that can be grouped in a separate pattern and then default the values. For instance:

• Jazz Server instance URI: Different Jazz server instances for different development teams
• RAD Workspace: To control file system paths standardization among different development teams.
• Use JDK 7 as default for new WAS 8.5 profiles: Not all development products are targeted for the newer platforms. Many times, the development project is for maintaining an old application that doesn't use JDK 7.
• VNC uses SSH Tunneling: Due to different security concerns, an end-to-end connection between the developer and the RAD instance may or may not need SSH tunneling to encrypt the communication.

These patterns, depending on different business needs, may be grouped so you can capture different needs in different patterns.

Other reason to clone the RAD pattern is the inclusion of other script packages that will customize the instance in different ways. For instance, a deployer will have the default non-root user pattern already imported in PureApp and a clone that may contain Rational enable root VNC script package.

Default the RAD workspace

RAD pattern has a parameter where you can specify the workspace used by RTC client to create a Repository Connection. Even if you provide a workspace and valid RTC parameters, the workspace will not be persisted as the predetermined workspace when you launch RAD. You will be prompted for a workspace by the Workspace Launcher dialog.

This scenario also applies if you don't want to use a RTC connection, i.e. using a different software management system. You may want to have standardized paths for your projects in RAD to avoid file system mismatches between developers.

To set a default workspace for a RAD instance (and this actually applies to any Eclipse-based application) there is one directive, osgi.instance.area, that needs to be specified in the config.ini file from the Eclipse installation. This config.ini file is located under /home/virtuser/IBM/SDP/configuration directory.

This can be provided at deployment time using a script package. This script package can take the workspace value and using some command-line tools, such as sed or awk, you can specify that value in the osgi.instance.area directive

Listing 1. Using sed to write a default workspace in config.ini

$ sed -i “s/osgi.instance.area=[^ ]*/osgi.instance.area=$WORKSPACE/g” config.ini

Note: If using RTC Repository Connection script (“RAD Workspace” parameter when specifying valid Jazz values during deployment) and creating a script like the one depicted in this section for defaulting the Workspace Launcher, make sure both parameter values are the same.

Provide WAS profiles

RAD pattern comes with installations of WebSphere Application Server (WAS) versions 7.0, 8.0, 8.5 and Liberty Profile 8.5, but no profiles have been created. This means, that, while no profile is created, every time a developer launches RAD, a new profile creation dialog will come up asking to whether create it or no.

In the case that a developer chooses to create the profile, it may take several minutes to complete, and of course the more profiles you create, the more time it will take.

Since this is a repeatable process, creating a script package sounds the right way to go. This script package should contain a cbscript.json file describing the script package itself and the the script file which will call WAS' manageprofiles script. The most basic call of this command is as follows:

Listing 2. manageprofiles command usage.

$ cd <WAS_Installation_path>/bin
$ manageprofiles.sh -create -profileName <profile_name> -profilePath <profile_path> -templatePath <template_path>

Where:

• <WAS_Installation_path>: Directory where WAS is installed. In RAD pattern, an installation folder is created for each WAS version under /home/virtuser/IBM/WebSphere. It is convenient to have this value as a parameter in the script package.
• <profile_name>: Name of the profile, it should be unique for this WAS installation (the name can be shared among WAS version profiles).
• <profile_path>: Directory where the profile will be placed.
• <template_path>: Template from which the profile will be based. This template can be found under <WAS_Installation_path>/profileTemplates. Note that for WAS 7.0, there are several templates, you should choose the correct one or well you can use the basic template and then augment it after creation.

Of course, there are many other arguments that are allowed to create a profile, like password or port numbers. Refer to WebSphere information center for details.

You should keep an eye on:

1. How many parameters (of the manageprofiles command) are going to be hardcoded in the script (if any).
2. Which parameters are going to be provided to allow customization, i.e. Parameters specified in the script package.
3. Which parameters are going to be requested at deployment time (See Shorten the deployment parameters amount section).

It is highly recommended that, in order to keep simplicity in the script packages, you have one script package for each of the WAS installations. In order to make this quick, you can just create a clone of it the script package and ask for the WAS installation path as a parameter. This will shorten your time work while you provide atomicity to the pattern.

Force users to change temporary passwords

While the deployer provides OS and VNC passwords at deployment time, there is a need to enforce the security of the instance that is being created. This means that only the person (or persons in very particular scenarios) has access to the virtual machine, either through command-line or remote desktop.

The password changes need to be done at two levels:

1. OS password.
2. VNC password.

Usage of SSH tunnels and enforcing all users to change passwords at login is the recommended setup.

Forcing a user to change OS password upon login

One more thing to thought about is, did you enable SSH tunneling? If the answer is yes, then the OS password changing is easy to enforce with Linux commands like chage.

Listing 3. Forcing virtuser password change with chage command.

# chage -d 0 virtuser

Note that with this method, the user need to enter a strong password whose rules are defined by PAM authentication rules.

If using SSH tunnel, there is no need to change the VNC password, since any intruder will not be able to open the UI through a VNC viewer without the OS password.

Forcing a user to change VNC password upon login

There is only one way to do this and it cannot be automated, i.e. prompting the user to change the password upon first login on VNC, the VNC server needs to for a new password. This is done with vncpasswd command and needs to be executed by the user who pretends to have a new VNC password. This will allow the user to type the password and then verify it.

Listing 4. Changing the VNC password.

$ vncpasswd

Note: This command need to be executed by the developer in a terminal.

External links:

• IBM
• Learn more about IBM Software Delivery and Lifecycle Patterns
• WebSphere Application Server v8.5 Information Center
• manageprofiles command in WAS 8.5
• Learn how to deploy IBM Software Delivery and Lifecycle patterns