In this scenario we have two nodes and deployment manager in our cell, we want to check out a few things about the configuration of SSL certificates in our keystores.

You may have a situation where node 01 profile was created using the GUI ie the PMT wizard where you would have been prompted for the certificate details and optionally given the choice to use default certificates and ability to edit the OU names used.

However for node 02 the node profile was created using a command line tool. For example: the manageprofiles.bat –create command was used and in this case there is no option to specify/override the default certificate naming conventions.

This can present a miss match in naming conventions, and we should be able to tidy this up to ensure that both nodes are using the same naming convention for the certificates in their key stores.

Let’s see the difference in the certificate naming as a result of this situation

1. To view certificates issues navigate to Security | SSL certificate and key management

1. The SSL certificate and key management screen will be presented. Locate the Related items section and click Key stores and certificates to get a list of node certificates.

1. On the SSL certificate and key management | Key stores and certificates screen we get a list of each nodes SSL settings.

1. To compare each certificate we need to drill down into each certificate for each node for both key and trust stores. This means we will repeat the following action 2 times for both nodes.

   Click on the appropriate certificate, then

1. Locate the Personal certificates link in the related item section as seen below

1. The image below shows the personal certificate for node01.

1. Repeat the exercise for node01. The image below shows the result for node02 personal certificates.

1. You can see by the results that when we created Node01 using PMT we were able to specify/override the default SSL certificates OU hierarchy, however when we used the manageprofiles command line tool the OU’s were automatically given the same name as the node name.

   This may not be a problem in normal runtime operation, but in a larger system of many WAS cells and nodes at a time a time where certificates may expire, if the names are not consistent, then problem finding the root cause of certificate errors in multi-cell or cross-cell communication, could be difficult.

   It is recommended that you create both nodes the same method either using PMT or using the command line tool, this way you ensure the certificates naming convention is consistent.

Creating a new chained certificate using the Administrative console

1. What we can do now is create a new personal certificate for our key store and delete the old one. This is a very powerful feature as oppsed to WAS 6.1 where this was all done using the IBM ikeyan tool.
2. Select the Personal certificate screen for node 01 by navigating to:
   SSL certificate and key management | Key stores and certificates | NodeDefaultKeyStore | Personal certificates

3. Click Create | Chained Certificate
4. Fill out the fields as follows:

An example screen shot is below:

1. Click OK and then delete the default alias certificate that you want to re-create

2. Delete the previous “default” alias, by selecting the alias and clicking the Delete action button as seen below.

3. Save the changes. You will now see that the certificate alias has been removed.
4. What we need to do now is re-create a new default alias. We do this by re-creating a new alias using the same details as the default_node1 alias and ten we can delete the default_node01 alias.

   Why do we do this, well it is for neatness and stops confusion when dealing with certificate aliases.

5. Click OK and save the change when prompted to do so.

1. Select the default_node01 alias and click the Delete action button as seen below:

2. Save the changes
3. The result is not he following:

Summary

It is recommended practice that you create all nodes using the same method. What we mean here, is that you should earth use the Profile Management Tool GUI to create all nodes, or use the manageprofiles command line tool to create all nodes for the cell. This way you will have a universal naming convention for node names and personal SSL certificates.

If you wanted to use an external CA or use an internal Root CS, then you could essentially tell WAS to use your specific certifiers after the profiles are created. The manage profiles command does not provide SSL management. Administration scripting using wsadmin and jython is how we can automate SSL certificate management after node profiles are created.

I will be posting a follow up article on how to fully automate SSL certificate along with node profile creation/federation.

A chained personal certificate is a personal certificate that is created by using another personal certificate to sign it. This chaining allows a certificate to be signed with a certificate (a root certificate) that has a long life span. Root certificates are stored in the DmgrDefaultRootStore or NodeDefaultRootStore. The server’s default personal certificate is a chained certificate created when the profile is created. Chained certificates can also be created after profile creation

You use the administrative console to create a chained personal certificate.

Below is some sample jython code to create a chained certificate

</p><p>AdminTask.createChainedCertificate('[-keyStoreName NodeDefaultKeyStore -keyStoreScope (cell):cell01:(node):node01 -certificateAlias test -rootCertificateAlias root -certificateSize 2048 -certificateCommonName test -certificateOrganization myOrganisation -certificateOrganizationalUnit myOrgUinit -certificateLocality myLocality -certificateState myProvince -certificateZip myZip -certificateCountry GB -certificateValidDays 365 ]')
</p><p>AdminTask.getCertificate('[-keyStoreName NodeDefaultKeyStore -keyStoreScope (cell):cell01:(node):node01 -certificateAlias test ]')
</p><p>AdminTask.listPersonalCertificates('[-keyStoreName NodeDefaultKeyStore -keyStoreScope (cell):cell01:(node):node01 ]')
</p><p>AdminTask.getCertificateChain('[-certificateAlias default -keyStoreName NodeDefaultKeyStore -keyStoreScope (cell):cell01:(node):node01 ]')
</p><p>AdminTask.getCertificateChain('[-certificateAlias test -keyStoreName NodeDefaultKeyStore -keyStoreScope (cell):cell01:(node):node01 ]') 
</p><p>

[important]

Part 4 in a 5 part series

Part 1

Part 2

Part 3

Part 5

[/important]

Part 4 – Creating a second Node profile

Prerequisites:

Install WAS 8 ND using the new IBM Installation Manager on a Windows platform.

Create a Deployment Manager profile.
Create a node profile called node01

Note: It is possible to use this guide to install on Linux. The installation is almost exactly the same.

Steps to create a second node profile

1. Before we create the profile we will log into the Administrative console of our running deployment manager. We want to do this to see the status of all nodes in the cell. Navigate to the System administration section located in the left-hand-side panel of the admin console. Click Node agents.
2. In the Nodesscreen we get a listing of the available node agents running which manage our federated nodes. Since we currently have only one node called node 01 we only have one node agent.
   You can see above, that we have one node agent
3. To begin the process of creating a second node profile called node01 we will execute the following command to list help about the manageprofile –createProfile option.<was_root>/bin/

   The result will be as follows:

Function:

Creates, lists, alters or deletes profiles

Syntax:

manageprofiles -<mode> -<argument> <argument parameter> …

The available modes are:

create

augment

delete

unaugment

unaugmentAll

deleteAll

listProfiles

listAugments

backupProfile

restoreProfile

getName

getPath

validateRegistry

validateAndUpdateRegistry

getDefaultName

setDefaultName

response

help

Note: Command-line arguments are case sensitive.

Note: If argument accepts a parameter containing spaces, the parameter must be enclosed in “double quotes”.

Note: The default profile template is “default” and may be overridden by the -templatePath switch.

Note: Mode specific arguments are described in the detailed help for each mode.

To see the detailed help on each mode enter: -<mode> -helpC:\Program Files\IBM\WebSphere8\AppServer\bin>manageprofiles.bat -create -help

Function:

Creates a new profile

Syntax:

manageprofiles -create -<argument> <argument parameter> …

Arguments:

The following command line arguments are required for this mode:

-templatePath <argument parameter>: The fully qualified path name of the profile template that is located on th

e file system.

-profileName <argument parameter>: The name of the profile.

-profilePath <argument parameter>: The intended location of the profile in the file system.

The following command line arguments are optional, and have no default values:

-isDefault <argument parameter>: Make this profile the default target of commands that do not use their profile

parameter.

-omitAction <argument parameter>: Omit optional features.

Note: Command-line arguments are case sensitive.

Note: If argument accepts a parameter containing spaces, the parameter must be enclosed in “double quotes”.

Note: The default profile template is “default” and may be overridden by the -templatePath switch.

Note: Each profile template will have its own set of required and optional arguments.

Using the help reference we know that we have several settings which are required to define a creation of a new profile via the command line.

The following example is the full command line you need to run to define a node02 profile for cell01.

manageprofiles.bat -create -profileName node02 -profilePath C:\Progra~1\IBM\WebSphere8\AppServer\profiles\node02 -templatePath C:\Progra~1\IBM\WebSphere8\AppServer\profileTemplates\managed -cellName cell01 -hostName node02 -cellName node02 -nodeName node02 -enableAdminSecurity false

If Global security was turned on we would need to add the following options:

-adminUserName wasadmin -adminPassword wasadmin

1. Now that we have created a new node profile, we need to federate the node into the cell. To do this we use the addNode.bat command, which is located in the <was_profile_root> folder. for example <was_root>\profiles\<profile_name>Type the following command to see help about the addNode.bat command:

Usage: addNode dmgr_host [dmgr_port] [-conntype <type>] [-includeapps]

[-includebuses] [-startingport <portnumber>] [-portprops

<qualified-filename>] [-nodeagentshortname <name>] [-nodegroupname

<name>] [-registerservice] [-serviceusername <name>]

[-servicepassword <password>] [-coregroupname <name>] [-noagent]

[-statusport <port>] [-quiet] [-nowait] [-logfile <filename>]

[-replacelog] [-trace] [-username <username>] [-password <pwd>]

[-localusername <localusername>] [-localpassword <localpassword>]

[-profileName <profile>] [-excludesecuritydomains] [-asExistingNode]

[-help]

1. Type the following command to actually federate node02 into the cell.<was_root>\profiles\node02\addNode.bat dmgr 8879 -conntype soap –nodeagentshortname node02 -profileName node02

ADMU0116I: Tool information is being logged in file

C:\Progra~1\IBM\WebSphere8\AppServer\profiles\node02\logs\addNode.log

ADMU0128I: Starting tool with the node02 profile

CWPKI0308I: Adding signer alias “root_1″ to local keystore

“ClientDefaultTrustStore” with the following SHA digest:

6F:08:38:33:2D:63:24:40:11:02:2D:99:BB:C5:79:FE:89:A2:EB:C5

ADMU0001I: Begin federation of node node02 with Deployment Manager at

dmgr01:8879.

ADMU0009I: Successfully connected to Deployment Manager Server: dmgr01:8879

ADMU0507I: No servers found in configuration under:

C:\Progra~1\IBM\WebSphere8\AppServer\profiles\node02\config/cells/node02/nodes/node02/servers

ADMU2010I: Stopping all server processes for node node02

ADMU0024I: Deleting the old backup directory.

ADMU0015I: Backing up the original cell repository.

ADMU0012I: Creating Node Agent configuration for node: node02

ADMU0014I: Adding node node02 configuration to cell: cell01

ADMU0016I: Synchronizing configuration between node and cell.

ADMU0018I: Launching Node Agent process for node: node02

ADMU0020I: Reading configuration for Node Agent process: nodeagent

ADMU0022I: Node Agent launched. Waiting for initialization status.

ADMU0030I: Node Agent initialization completed successfully. Process id is:

6856

ADMU0505I: Servers found in configuration:

ADMU0506I: Server name: nodeagent

ADMU0300I: The node node02 was successfully added to the cell01 cell.

ADMU0306I: Note:

ADMU0302I: Any cell-level documents from the standalone cell01 configuration

have not been migrated to the new cell.

ADMU0307I: You might want to:

ADMU0303I: Update the configuration on the cell01 Deployment Manager with

values from the old cell-level documents.

ADMU0306I: Note:

ADMU0304I: Because -includeapps was not specified, applications installed on

the standalone node were not installed on the new cell.

ADMU0307I: You might want to:

ADMU0305I: Install applications onto the cell01 cell using wsadmin $AdminApp or

the Administrative Console.

ADMU0003I: Node node02 has been successfully federated.

1. Once the node has been successfully federated, then log into the Administrative console on the Deployment Manager and view the nodes. Navigate to System administration | Nodes to see that we have a new node
2. Congratulations, you now have a two node cell.

Verifying certificates

Now that we have two nodes and deployment manager in our cell, we want to check out a few things about the configuration of SSL certificates. You may remember that when we created the node 01 profile we used the PMT wizard and we were prompted for the certificate details (we chose to use default certificates), but we were able to edit the names used. However when we used the manageprofiles.bat –create command we had no option to specify the certificate naming conventions. Let’s see the difference in the certificate naming.

1. To view certificates issues navigate to Security | SSL certificate and key management

1. The SSL certificate and key management screen will be presented. Locate the Related items section and click Key stores and certificatesto get a list of node certificates.

1. On the SSL certificate and key management | Key stores and certificates screen we get a list of each nodes SSL settings.

1. To compare each certificate we need to drill down into each certificate for each node for both key and trust stores. This means we will repeat the following action 2 times for both nodes.Click on the appropriate certificate, then

1. Locate the Personal certificates link in the related item section as seen below

1. The image below shows the personal certificate for node01.

1. Repeat the exercise for node01. The image below shows the result for node02 personal certificates.

 CN=node01, OU=Node01Cell, OU=node01, O=IBM, C=US

CN=dmgr01, OU=Root Certificate, OU=cell01, OU=dmgr01, O=IBM, C=US

26634347123447

Valid from Oct 26, 2011 to Oct 25, 2012.

 Node02CN=node02, OU=node02, OU=node02, O=IBM, C=US

CN=dmgr01, OU=Root Certificate, OU=cell01, OU=dmgr01, O=IBM, C=US

9737447655777

Valid from Oct 27, 2011 to Oct 26, 2012.

1. You can see by the results that when we created Node01 using PMT we were able to specify/override the default SSL certificates OU hierarchy, however when we used the manageprofiles command line tool the OU’s were automatically given the same name as the node name.This may not be a problem in normal runtime operation, but in a larger system of many WAS cells and nodes at a time a time where certificates may expire, if the names are not consistent, then problem finding the root cause of certificate errors in multi-cell or cross-cell communication, could be difficult.

   It is recommended that you create both nodes the same method either using PMT or using the command line tool, this way you ensure the certificates naming convention is consistent.

When creating a node manually using the Deployment Manager’s administrative console, I am able to specify the hostname of the node. However when I use the addNode.bat command to federate the new node (node02) , it picks up the deployment manages, hostname. In this example I have a vertical scaled design ie the nodes and the dmgr are all on one box, but I want o ensure that each node is using each own hostname, how to do I solve this problem see image below:

Reason for issue:

You have created the node profile with an error, best to verify the command you used to create the profile. You can specify the hostname as an option when creating the profile.

Solution:

1. un-federate the node using removeNode.bat for example
   
   

removeNode.bat C:\Progra~1\IBM\WebSphere8\AppServer\profiles\node02\bin\removeNode.bat –profileName node02

1. Remove the profile

C:\Program Files\IBM\WebSphere8\AppServer\bin>manageprofiles.bat -delete -profileName node02

1. Re-create the profile

C:\Program Files\IBM\WebSphere8\AppServer\bin>manageprofiles.bat -create -profileName node02 -profilePath C:\Progra~1\IB

M\WebSphere8\AppServer\profiles\node02 -templatePath C:\Progra~1\IBM\WebSphere8\AppServer\profileTemplates\managed -cell

Name cell01 -hostName node02 -cellName node02 -nodeName node02 -enableAdminSecurity false

1. Federate the node into the cell using the addNode.bat command:

C:\Program Files\IBM\WebSphere8\AppServer\profiles\node02\bin>addNode.bat dmgr01 8879 -conntype soap -profileName node02

Result:

[important]

Part 5 in a 5 part series

Part 1

Part 2

Part 3

Part 4

[/important]

Creating cluster in a vertically scaled Cell design

This is the final part of this series; here we complete our Web sphere 8 ND installation where we have a deployment manager and two federated nodes. We created three profiles on the same physical system. Each profile was created with full instructions and commentary, so please refer to these previous documents.

Below is a simple diagram outlying what we ultimately wish to achieve on the competition of all 5 parts of this article series.

As you can see above we have a cluster called “Cluster 01″ which spans two nodes. Within the cluster we have two JVMs. Each JVM is known as a clone in IBM WAS terms. Remember the term Server and JVM are interchangeable in the context of WAS ND servers.

Each node profile defines the node on which JVMs will run. These could have been on different machines which would be referred to as a horizontal scaled design, however for simplicity and to allow you to trial the concept, we have used a vertically scaled design. Each profile defines a node agent. A node agent’s job in life is to ensure that configuration changes made to via the admin consol eon the deployment manager are synchronised to the nodes. The same goes with deployment of applications, JNDI namespaces and also the High Availability (HA) mechanics on the internals of WAS. Node agents can also monitor JVMs and automatically restart them upon failure. We won’t be discussing the internal in this document, we want to pick the fruit, not understand the chemical make of fruit and how we grow fruit. What I mean here is let’s get it working and then you can turn to other blog entries on the more specific details underlying WAS ND.

Creating a cluster

It is possible to create a cluster in to ways.

1. Create a JVM on one node then add it to a cluster, clone it and assign to another node.
2. Create the Cluster definition then add JVMs as required on specific nodes.

In our example we will create a JVM on node01, then upgrade it to a cluster and add another clone.

To create a server, follow these steps:

1. Select Server Type form the Server section located in the left-hand-side of the administrative console, then click WebSphere Application Servers.

1. In the Application server listing screen, click New.
2. Within the Create a new application server screen, select Node01 (we have two nodes on this system). Type server01 in the server namefield.Click Next.

3. On the following page, select DeveloperServer template. This makes the server start-up quicker.Note: Enabling this option might reduce application server start-up time because it changes some of the JVM settings, such as disabling bytecode verification, and reducing just-in-time (JIT) compiler compilation costs. Do not enable this setting on production servers. This setting is only available on an application server that is running in a Version 6.0 or later cell.

   In production you not use this option, you would use default.

   
   Click Next

1. The next screen will present an option to turn toggle the Generate unique portsoption. This setting generates unique port numbers for every transport that is defined in the source server, so that the resulting server that is created will not have transports which conflict with the original server or any other servers defined on the same node.When you are installing multiple JVMS on the same systems, you can get conflicts with port numbers. If you design your Cell to allow only one single JVM per node, then you could use the default port options, however this can be problematic.

   Note: If you more fine grained control, then server templates can be used and or administrative scripting using Jython can be used to create servers and cluster with specific ports set. In large enterprises you would control the port numbers of each an every port so you know at every turn what each Node Agent, and each JVMs port are. Knowing exactly what ports to expect can help with debugging connectivity issues with complex firewalls, load balanced and situations where third-party helper applications do not conflict with WAS.

1. Review and click Finish.

1. Once the server has been created, click Saveto ensure that the configuration is permanently stored.
   You can see that the server is currently stopped.

Validating the node synchronisation

1. If we quickly navigate to the Nodes view, we will see that the Nodes are now out of Sync.To display Node synchronisation status, then navigate to System Administration | Nodes

   Below is what you should see, if any of the nodes turn green it means they are one again in sync with the deployment manager.

   
   After a period of time the node will sync.

   A table of statuses:

   The Status Columns, indicates that the node is either synchronized, not synchronized, unknown, or not applicable.

Node status. Shows whether node changes are synchronized.
	Synchronized	The configuration files on this node are synchronized with the deployment manager.
	Not synchronized	The configuration files on this node are not synchronized with the deployment manager and are out-of-date. Perform a synchronize operation to get the latest configuration changes on the node.
	Unknown	The state of the configuration file cannot be determined because the node agent cannot be reached for this node.
	Not applicable	The status column is not applicable for this node because the node is an unmanaged node.

If you wish to manually force synchronisation, you can click “Synchronise“. Synchronizes the user configuration immediately. You can click Synchronize on the Nodes page if automatic configuration synchronization is disabled, or if the synchronization interval is set to a long time, and a configuration change is made to the cell repository that needs replicating to that node. A node synchronization operation is performed using the normal synchronization optimization algorithm. This operation is fast, but might not fix problems from manual file edits that occur on the node. It is possible for the node and cell configuration to be out of synchronization after this operation is performed. If problems persist, use Full Resynchronize.

The other option is to do a Full Synchronisation, which is the same as Synchronisation, except, this option clears all synchronization optimization settings and performs configuration synchronization again, so no mismatches occur between node and cell configuration after this operation is performed. This operation can take awhile to perform.

Note: All configuration done via the Administrative console is temporary and until saved does not exist in the master configuration. The same goes for running a Jython script, unless the appropriate save option is called in an admin script, the changes are not permanent. Once they are saved the deployment manager will communicate with the node agents on the all the nodes and will synchronise the master configuration.

If you wish to read up on the configuration files used in the master config you can refer to the following link. http://blog.webspheretools.com/2011/11/01/hierarchy-of-websphere-application-server-directories-and-summary-of-configuration-documents/

Starting the server

We will not start server01 using the console, then we will stop is via the command line after viewing the logs.

1. Navigate to Servers | Server Types | WebSphere applicationservers
2. Now we need to start the server and view the server’s logs.
   1. Click Start as seen above
   2. Open a command prompt or shell to <was_root>/profiles/node01/logs/server1
   3. Open the SystemOut.log
   4. Once you have opened the server’s log file, then scroll to the bottom of the log file and look for line similar to the following:[01/11/11 11:38:45:528 GMT] 00000000 WsServerImpl A WSVR0001I: Server server01 open for e-business

      Note: It is recommended you use a Windows tail command line tool like Wintail or install cygwin to allow you to use unix commands on Widows such as tail. Using tail allow you to open watch a log file as it is changing over time (New entries are continually appended line by line to the log and the tail command scroll the last few lines so you can see the log scroll upwards, in real-time). If you are using Linux then you can use the tail command in a shell.

   5. What this line is good for is to identify if the server has started successfully. If there has been issue then this message will not appear, or it will present a message that the server has started, but with errors.
3. Look at the state of the server in the administrative console, it should not be started.
4. We will now stop server01 using the command line tools.
   1. Open a command prompt <was_root>/profiles/node01/bin
   2. Type
      1. Windows
         stopServer.bat server01 <enter>
         or
      2. Linux
         stopServer.sh server01 <enter>
   3. The result will be something similar to the image below:
5. Now go back to the admin console and the server state will be stopped again.
6. We are not ready to create a cluster and convert the server into a clone within the new cluster.

Creating a cluster and clone from an existing server

In this section we take our existing JVM (server01) and make it into a clone (member) of a cluster.

Steps to create a cluster and convert a server into a clone

1. Navigate to Servers | Clusters | WebSphere application server clusters as seen below.

1. A list of clusters is presented. We have no cluster at this point, so it is empty. Click New to start the “Create a new cluster” wizard.
2. Type the name cluster01 into the Cluster namefield.

   To learn more about prefer local and HTTP session memory-to-memory replication settings by searching the WebSphere blog. Http://blog.webspheretools.com
   [Add link to document on the blog]

3. Click Next to move onto the Create first cluster member screen. In this example we want to convert an existing server to become a member of this cluster. Select the create the member using an existing application server as a templateoption as seen below
4. Click Nextto move onto the screen where you can add additional cluster members. In this case we are going to add a new member to Node02.
   Click the Add
   member button to add the new cluster member, the result is as seen below.

   
   If you would like to know more about Cluster weighting concepts then consult http://www.webspheretools.com.
   [Add link to document on the KB site]

5. Click Next to review the final summary screen, and then click Finishto create the cluster.
6. Click Saveto ensure the new cluster is saved.
7. The WebSphere application servers clusters view will list the current cluster in the cell.
8. Before we start the cluster we can drill down into the properties of Cluster 01. Click on cluster01 link as seen above.
9. Navigate to the Additional Properties section of the cluster01 properties careen and expand the Cluster membersexpandable category. This will show the members of the cluster.
   For now we won’t be covering the settings in this seem, however you can see are several related areas and settings which will need some explanation in another module.
10. Make sure you are back on the Cluster view screen and click Start
    You can see in the image above that the Status is Partially started. This is because each member (clone) will be started in sequence and once both servers (members) as started the console will report a green status meaning the cluster if full started. Full started means that all members of the cluster have started. Below is an example for a fully started cluster

11. We have now completed the essentials of the cluster creation process. What we need to do now is deploy an application to the cluster so we can verify that the Cluster works and we can access each server’s (cluster members) web-container.

Deploying an application to the cluster

In this section we will deploy an application called the “Default application” which is located in the <was_root>/installableapps folder. This application contains a servlet called “snoop” which is very useful to testing and verifying a server’s ability to service applications via the web-container.

Note: Snoop is very useful for during the debugging of Workload Management and load balancing issues when using IBM HTTP Server and WebSphere Plug-in with WAS ND.

You can find more about this topic in the IBM HTTP Server, WebSphere Plugin and Workload management module.

Follow the steps below to install the “Default Application”

1. Within the Administration console navigate to Applications | Application Types | WebSphere enterprise applications as seen below.
2. Click Installto begin the application deployment
3. Click the Remote file system option, as we want to install the DefaultApplication.EAR file from the servers file-system.
4. Pick the deployment manager node, and drill down until you come to the appropriate folder path.
   

   
   Click OK, then Next. Once the file path has been set.

5. In the next screen which is called the Preparing for the application installation screen, we will select the Fast Path option.You can select a Fast Path or select to see all installation options and parameters.

1. Click Next to continue onto Step 1: Select installation options. We will explain this screen in detail in another module, for now set the logical name of the application by typing “Default Application” into the Application name field. By default the Application name is set to the EAR file’s name.
2. Click Next to move onto Step2: the Map modules to Servers screen. Here the wizard has detected that there is a Web module and EJB contained within the EAR file and so there need to be an explicit mapping of which JVM or cluster each component is to run on. We want both to be run as separate instances within each member of the cluster (this is the default setting set by the wizard)More about modules and mapping is covered in another module.

   Note: the number of steps presented in the deployment wizard will depend on the artefacts contained with the EAR file.

3. Click Nextand review the summary, then click Finish and Save to compete the deployment to the cluster.
4. Navigate back to |Applications | Application Types | WebSphere enterprise applications and you will see the newly installed (deployed) application.
5. Start the application by clicking the Start button
6. The console will report that the Default Application has been started successfully on both nodes.
   Note: When there is a large application to deploy, it can take some time for the deployment manager to synchronise the application registry and the application’s (expanded EAR file) across all the nodes in the cluster. If you get an error informing that the nodes a re no synchronised, you can wait, or manually force a synchronisation even as discussed earlier.
7. To test our application we need to find out what port values the web container is running on for both servers in the cluster.Navigate to Servers | Server types | WebSphere application servers and you will see two servers. For example, click on server01 to enter the server’s properties screen.

   Locate the Communication section and expend the Ports section as seen below. Look for the port called WC_defaulthost. This port is server01′s Web container port and in this example it is port 9081.

8. Using the same process as above, locate the same port for server02. In this example it is port 9082.
9. Now that we have the two port numbers we can access the snoop servlet via a browser to confirm that the application is running on both nodes.
10. Navigate to http://<host_name>:9081/snoopYou will get the following error:

SRVE0255E: A WebGroup/Virtual Host to handle localhost:9081 has not been defined.

IBM WebSphere Application Server

It means that the virtual host definition have not yet been set. When you deployed the application you mapped the Default Application’s web module to the default_host. Each web module within an application must be mapped to a virtual host. The reason is simple. When a web request comes into the web container for a given server, the server is asked to server a resource. The URI of this resource is only part fo the answer, we also need a port. Virtual hosts defined what ports web requests can come into the container. The Web container will only server resources (content) on ports which it has been configured to do so. Let’s configure the default virtual_host to allow requests to the web container on port 9081.

1. To configure virtual hosts, navigate to Environment | Virtual hosts and click default_host
2. The next screen presented will allow you to locate the Host aliases assigned to the default host. Click on Host aliases as seen below.
3. There will now be a list of virtual hosts alias. Some are identified by “*”, other are identified by a host name. When a host alias is identified with a “*” it means any host can connect. If a named host is set as an alias, then only that host name can be used in the URL of a browser (ie the Browser will present that hostname in it’s host header) to connect to any resources in web apps bound to that virtual host.
4. Add a new host alias for both ports 9081 and 9082. These are the two ports of the Web containers in each server.Click on the New button to enter the add alias screen
5. Enter “*” for the Host name and enter the value 9081 in the Pot field. Click OK, then create a new alias for port 9082, then click OK and save both changes.
   The result will be two new host aliases added to the list of current host aliases.

6. Ensure your cluster is restarted and retry the URLs above, this time we should be able to access the snoop servlet on port 9081 and port 9082.Note: If you get the following error:

It means that the server you are accessing is not started. Ensure that the cluster is fully started.

Below is an example of what the snoop servlet will produce for server 01. Notice that the Server port is 9081 as we expected.

Below is the snoop output for server02. Notice that the server port is 9082 as expected.

We can see that the request method is GET as we have accessed the snoop servlet and the browser has done a Get which is the most common request method on the internet (reading page content in a browser almost 999 time our of 1000 is a GET. We use the POST method when we submit forms (HTML pages enabled for submission) containing field data or other client side data which needs to be sent to the server.

Note: The above sentence is only partially true when AJAX (Web 2.0) content and streaming content is being displayed)

1. Congratulations, you have competed this 5 part series.

In this series we have leaner dot install WAS 8 ND using the IBM Installation Manager, create nodes graphically using the WebSphere Customiszarion Toolbox and Profile Manageme Tool. We have also leaner dhow to manually create and federate a profile using the manageprofile and addNode command line utilities.

We learned how to create a cluster and and create virtual hosts aliases.

In the next series we will learn how to implement IBM HTTP Server and the WebSphere plug-in to show how to provide load balancing to an application and also cover more details about SSL integration between the two.

Then we will move on to some of these topics:

• Security Domains
• Asynchronous Beans and Workload Management
• EJB 3.0 Deployment
• EJB 2.1 WAS 8
• Understanding JNDI and namespaces with WAS
• Node Groups and Core Groups
• Auditing
• Security Domains
• JMS, Queues, Topics, WMQ, MQ Link and Activation spec.
• Application packaging, deployment descriptors and bindings.
• Kerberos and Single Sign On (SSO), LPTA and cross cell communication.
• LDAP and federated repositories
• Debugging practices, especially dealing with JVM memory leaks, Heap Dumps using IBM tools.
• Job Manager
• Administration Agent
• Session Affinity (session persistence, replication domains)
• WebSphere and JVM tuning
• JDBC tuning
• Custom JAAS modules
• Spring security in a WAS web application
• …and a whole lot more other JEE API examples.

http://www.ibm.com/developerworks/downloads/ws/wasnetwork/index.html

1. Register and Login using your IBM ID.
2. Agree to license

1. When you click to download the Linux 32 bit version using Firefox on the Linux box, you may find the following error:
   

Download Director applet cannot be loaded.

Java support must be enabled to run.

You can skip these next few steps and processed to step 7 and download the IBM installation Manager directly via HTTP.

1. What we need to do is verify that the appropriate Java Plug-in is installed. We are going to try using FF installed locally on the box. In my case I am using No Machines NX client to get a remote Gnome desktop.
   
   Go to http://java.com/en/
   
   
2. Click Linux RPM and download
   

1. Open a terminal session
   

   cd /root/Downloads
   

   chmod 755 ./jre-6u29-linux-i586-rpm.bin
   

   ./jre-6u29-linux-i586-rpm
   
   Restart FF.
   

2. If you cannot get the JRE to work, so that you can use the IBM HTTP Download director which requires a JRE for Firefox (This is because the FF JRE plug-in install is broke, then you can just download using HTTP
   

   
   
   
   

1. copy the IBMIM_linux_x86.zip to an appropriate folder for example /var/apps/iim and unzip
   
2. Ensure you are running win an X11 session and run the IBM Installation Manager by typing the following command:
   

   ./install
   
   

3. As seen below type in your IBM username and password:
   
   
   
   
4. The IIM workbench will load
   
   
   
   
5. Click Next
   
   The IIM will start to prepare the installation for WAS 8 ND. Essentially it is downloading the installation files from the WAS 8 ND online repository. This process will take a few minutes based on the speed of your internet connection.
   
   
   
6. On the Select Fixes to install screen, click Next.
   
   
   
   
   
7. On the License and Agreement screen, read and accept the license and click Next
   
   
   
   
   
8. Because this is a trial, IBM installation Manger will present a basic survey, fill out as required and click Next.
   
   
   
   
   
9. You will now be presented with the option to choose the location of the Shared Resources Directory. In this example the defaults are being used to keep thing simple. Click Next.
   
   
   
   
   
10. On the next screen you will be presented with an option to change the location of where the IBM WebSphere Application Serve Network Deployment binaries are going to be installed. In this example the default IBM suggested location is being used.
    
    
    
    Click Next
    
    

     

11. On the Languages screen select you preferred language.
    
    
    
    Click Next
    
    
    
12. On the Select features to install screen, check al l the options you require. If you are unsure, select all.
    
    In this example I have elected to have the sample application installed and also the EJB Deploy tool, so I can trial EJB2.1 installations if I so choose.
    
    
    
    
    
13. Click Next
    
    Once again the IIM will contact IBM
    
    
    
    
    
14. On the final summary screen review the options and click Install as seen below.
    
    
    
    
    
15. The total download size is just over 1GByte, it will take some time to download, once again the time it tales depends on your available bandwidth.
    
    
16. Choose whether to load and run the WebSphere Customisation Toolbox ie the Profile Management tool or create profiles using the manageprofiles.sh command.
    
    
    

Error:

ADMU3100I: Reading configuration for server: dmgr
ADMU0111E: Program exiting with error: java.io.FileNotFoundException:
           /var/was/profiles/my_dmgrProf/config/cells/myhostnameCell/nodes/my_dmgrMnode/servers/dmgr/server.xml
           (No such file or directory)

Solution:

When you created this profile using the manage profile command you used the wrong template. When creating profiles with manageprofiles.sh you need top pass the appropriate profile template. If this WebSphere Application Server Network Deployment install has been augmented with ESB, process Server or WebSphere eXtreme scale then you nee to ensure you use the appropriate template for example:

/opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh -create -profileName my_dmgrProf -profilePath /var/was/profiles/my_dmgrProf -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/xs_augment/dmgr -nodeName my_dmgrMnode -cellName myhostnameCell -hostname myhostname -portsFile /home/wasadmin/portdef.cust.props.dmgr -isDefault true -enableAdminSecurity true -adminUserName wasadmin -adminPassword was4dm1n -omitAction samplesInstallAndConfig

A good tip to check that your augmented WebSphere Application Server Network Deployment profile has been installed using the correct template is to check the manageprofles.sh log file.
The manageprofile command line tool will log to <was_root>/logs.

Below is en example of a stanza from the profile creation log.

<record>
<date>2011-11-14T08:32:25</date>
<millis>1321259545215</millis>
<sequence>5039</sequence>
<logger>com.ibm.wsspi.profile.WSProfile</logger>
<level>INFO</level>
<class>com.ibm.wsspi.profile.WSProfile</class>
<method>doAugment</method>
<thread>0</thread>
<message>Augmentation of profile my_dmgrProf at path /var/was/profiles/my_dmgrProf using profile template /opt/IBM/WebSphere/AppServer/profileTemplates/xs_augment/dmgr</message>
</record>

[important]Customised, remote and on-site WebSphere Application Server training[/important]

Based on real world experience, the training is done on Linux, Windows or AIX, containing enterprise experience and know-how based on tried and tested solutions from corporate experience.

Trainer:
The trainer is Steve Robinson who is a leading UK WebSphere expert still actively consulting in the industry for fortune 500 companies and is the author of the books IBM WebSphere Application Server 8.0 Administration Guide and WebSphere Application Server 7.0 Administration Guide.

Request information: Email websphere.training@webspheretools.com

Course options

• Both on-site and remote training options are available
• Remote Hourly @ £75 + VAT
• On-site Hourly @ £100 + VAT
• Course material can also be purchased.

Operating systems

• AIX
• Linux
• Windows

Sample topics

• WebSphere Messaging ie JMS (Activation spec, SIB, EJB-MDB) and WebSphere MQ integration inc MQLink
• WebSphere ND. High availability designs, clusters and work-load management
• SSL secrets
• Install WebSphere Application Server using both manual and automated methods
• Secure the WebSphere application server’s administrative console with different levels of access for administration
• Understand federated user and group repositories
• Understand J2EE Application packaging
• Understand class loading
• Install applications manually and understand how ti use ws_ant and wsadmin with Jython for automatic deployment
• Learn how to read, configure, and search your server logs
• Change application server configurations, stop and restart application servers, and create additional application servers from a single administrative console for WebSphere Application Server using the Administrative Agent for WebSphere Base
• Diagnose the problems using command-line tools when your WebSphere or applications are not running as they should
• How to configure message-aware applications
• Configure database-aware applications and configure JDBC providers and connection pooling
• Install IBM HTTP Server and WebSphere Plugin for Workload management and how to manage Web Servers from administrative console
• Analyse, Monitor and tune your WebSphere environment
• Keep your products up to date by using WebSphere product maintenance features

Books written by Steven Robinson …

IBM WebSphere Application Server 8.0 Administration Guide http://www.packtpub.com/ibm-websphere-application-server-8-0-administration-guide/book

WebSphere Application Server 7.0 Administration Guide http://www.packtpub.com/webSphere-application-server-7-0-administration-guide/book

When using the WebSphere eXtreme Scale (WXS) xsadmin.sh utility in WebSphere Application Server ND. The error “Exception was caught during execution, java.lang.IllegalStateException: Placement service MBean not available” is presented. You know yo have the correct BOOTSTRAP port of the deployment manager, so whats the problem?

Well the error below is presented when you try to call an WXS command such as placement and there is currently no catalog servers running. You need to create a catalog domain. Note: In WebSphere Application Server ND, you can use the Deployment manager and Nodeagents as catalog server. I personally do not recommend this as this means that when you stop and start these elements the Data Grid will stop working. What you should be doing is creating independent JVMs for catalog servers.

Here is the full error:

<profile_root>/bin/xsadmin.sh -dmgr -p 10003 -placementStatus

This Administrative Utility is provided as a sample only and is not to be
considered a fully supported component of the WebSphere eXtreme Scale product

Connecting to Catalog service at localhost:10003
Realm/Cell Name: defaultWIMFileBasedRealm
User Identity: wasadmin
User Password:
The following Exception was caught during execution, java.lang.IllegalStateException: Placement service MBean not available.
[]

This error may be caused by incorrect host, port, or configuration arguments
- Please consult the help statement for more information
java.lang.IllegalStateException: Placement service MBean not available.
[]
at com.ibm.websphere.samples.objectgrid.admin.OGAdmin.main(OGAdmin.java:1406)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:267)