Tip:
Highlight text to annotate it
X
The first step is to copy the content of the RRDI_Server directory into a new CLM server directory.
This new CLM server directory will act as an area where you can do all the merging for all three application servers that will eventually
be hosted on this plugin configuration.
As you can see, all files have been moved to this directory.
The next task is to update the plugin-cfg.xml file in the new location.
This is to reflect the new path
for the configuration file.
You can change the location of the log file, but
the real point at this time is to update the keyring and the stashfile values for the server tags within the server cluster.
Make sure you update the keyring and stashfile locations.
Take an opportunity to look at the plugin-cfg.xml file. As you can see, there is quite a bit of configuration here
talking about the ports, the server locations and the servers within those clusters.
There is also the URI group mapping which defines the context mapping that exists for the particular profiles on that server.
Be familar with this file, because many updates will occur further on in this video.
Understanding the properties and values for this file improves your ability to implement this solution.
The next step is to update the "httpd.conf" file
to reflect the new keyfile and plugin location.
Update the KeyFile location to the "clmserver" merged area you created.
You must also update the WebSphere plugin config value for the merged area location.
Next, log into the "clmexample" machine.
Create a web server profile on the first profile created on the "clmexample" machine.
Log into the console, expand Servers,
Server Types, and click Web servers.
Create a new server.
Call the server "CLM_Server1", identifying the first profile on the clmexample machine.
The host name is the previously configured HTTP server, clmserver.ibm.com. Make sure you choose the right platform.
Next.
Next. The default values are required here.
On this panel, assume the path as if you are on the "oraexample" machine. This is to make sure that the plugin file that will be created refers
to the right path for the eventual merger.
Make sure you provide the credentials of the admin server.
Note that the admin server and HTTP server must be running when creating this profile.
Next.
Select the default. Finish.
Save the master configuration.
Now you have a new web server on the first profile of the clmexample machine.
Next step is to generate the plugin.
Select the checkbox beside CLM_Server1.
Generate Plug-in.
Notice the path for the plugin.
This path is the path specified on the profile.
As an example: If you try to Propagate Plug-in here you will get an error, since the location of
the web server does not exist on this machine. It refers to a path on another machine.
You will have to
move those configuration files manually to the IBM HTTP Server.
To do this, you have to navigate to the location of the plugin-cfg.xml file on the AppSrv01 profile.
Notice that the link was copied from the path, making it easy to navigate to this location.
If you open the plugin-cfg.xml file,
you can review the entries generated by CLM_Server1.
As you can see, the log path will not be good but it will not be used in the merge process.
The values important for the merge process will be the VirtualHostGroup,
the ServerCluster,
the Server entry,
the UriGroup, which defines the mapping for all the applications on this profile,
and the Route, which defines the location of the server itself.
Now it is time to move the plugins to the "oraexample" machine.
Using security FTP, open a connection to the "oraexample" machine.
Once logged in, navigate to the Plugins config directory.
Create a directory called "CLM_Server1".
The name is selected to make sure it clearly identifies where and what configuration files will be used in this location.
The first file to move into this server is the plugin-cfg.xml file.
The first file to open is the new plugin-cfg file from "CLM_Server1".
The second file
is the plugin-cfg file in the "clmserver" folder you created to support the merge area on the "oraexample" machine.
To the left is the "CLM_Server1" machine. To the right is the "clmserver" configuration.
The first plugin-cfg tag to verify and update is the "VirtualHostGroup".
Since you are using app server 1 on "oraexample" the port will be identify and
no new port updates will be required for the "VirtualHostGroup" mapping here.
The next three sections "ServerCluster", "UriGroup", and Route will be copied to be transferred to the merged
plugin-cfg.xml in the "clmserver" location.
After copied these sections, paste them underneath the last Route
in the "clmserver" plugin-cfg.xml file.
This paste is not enough. You must make sure you pay attention to
the key file definitions and the path to that particular key file.
In this case, you need to correct
the two properties from the ServerCluster area you just pasted into this file.
To do so, copy the location you have for "clmserver"
and then move to the "ServerCluster" you just pasted into the file.
Then update
the "keyring" and "stashfile" location
with the path you copied earlier.
Next task is to update the UriGroup from the node that you recently tested with Snoop.
Do this to avoid having two Snoop servlets being server by the HTTP server.
This is to make sure that when you test the Snoop servlet, you test with the Snoop servlet
targetted for the merge you are completing right now.
In the "UriGroup" mapping that was previously defined as the group mapping for "clmserver",
you modify the "UriGroup" to only
support the "ivt".
Save the file.
Note where your plugin log files will be in case you need them.
Once this is complete,
or anytime you update a plugin-cfg file, it will be required
to stop and start the application server.
It is also good to review your updates to make sure that all your values are pertinent to what you are trying to accomplish.
At the time of creating "CLM_Server1"
in the location where you generated the plugin you will find
the key file and a key stash file for certificate management.
You can also navigate to your console and open the Servers > Server Types > Web servers location.
Select the "CLM_Server1" you created and navigate to the plugin properties.
In this panel you will find a button called "Manage keys and certificates".
By clicking this button
you are able to find the path to the key file generated when creating "CLM_Server1".
Using this path, you can build based off the app server home,
the location, or the path to this particular file.
This point is that you will require the .kdb file to merge some of the client side certificate into the "clmserver"
.kdb file that you use to manage the application server and plugins.
Using secure FTP, log into the "oraexample" machine.
Navigate to
The WebSphere plugin configuration folder.
Particulary for "CLM_Server1".
Once that is completed,
the next step is to
use the IKeyMan tool to merge the plugin files.
From the HTTP bin directory on the "oraexample" machine, open the IkeyMan tool.
Browse to the "clmserver" .kdb file to open it.
Provide the "WebAS" password.
Once you are in, click the Export/Import button.
Browse to the "CLM_Server1" are you created earlier.
Open the plugin file from that directory. Select Import. Click OK. You will be prompted for a password. Enter "WebAS".
Once opened, you get a list of all the keys available in the file. Find the key that defines the
certificate for client side requests. In this case, it is the first line in this file.
You can select the line and enter a new label to identify it clearly. In this example, since the OU
specifies "clmexample" node 1, it is clear where the certificate is coming from.
You can now explore the certificates that are installed in the "clmserver" key file.
You can see that you have
the certificate you imported as well.
You also have the self-signed certificate.
You can close the file at this point.
After recycling the HTTP server, you can now try to test with Snoop
on the application server.
It appears to be working correctly.