Install WAS 8 using IBM Installation Manager

Installation logs

The IIM logs events as it is installing the WAS product. If there is a problem with your installation, you can consult the logs. The IIM logs files are located at the following location:

1. For Linux:
/var/logs

2. For Windows non-administrator:
C:\Documents and Settings\All Users\Application Data\IBM\Installation Manager\logs

3. For Windows administrator:
C:\Documents and Settings\<user id>\Application Data\IBM\Installation Manager\logs

 

Agent data location

Previously in WAS 7 the installer stored application registry information in a file called vdp.properties (Vital Produt properfiles file), which is now no longer the case. IIM will store data in the agent data location, or appDataLocation, and it is this directory that IIM uses for data that is associated with an application. Associated data includes the state and history of operations that the Installation Manager completes.

There is a file called the cic.appDataLocation property, which is set in the config.ini file and can be located at:

1. For Linux:
<iim_root>/eclipse/configuration
2. For Windows:
<iim_root>\eclipse\configuration

By editing the cic.appDataLocation property within the config.ini file, you can choose the specific location where you want IIM to store the agent data location.

Creating a WAS profile

the base binaries serve no purpose. We must create a profile which is essentially an application server definition.

We use the Profile Management Tool (PMT) to create WAS profiles using a GUI.

The tool is Java-based. To manually run it, type the following command:

1. For Linux:
<was_root>/bin/ProfileManagement/pmt.sh
2. For Windows:
<was_root>\bin\ProfileManagement\pmt.bat

3. Once the PMT has loaded, the option to Create a profile will be available. Click the Create button to start the actual profile-creation wizard:

4. In the environment screen you will be asked to either create a Management profile or an Application server profile. The two profile types are explained in the following :

Management — A management profile includes an administrative agent server and services for managing multiple application server environments. An administrative agent manages application servers that are on the same machine.

Application — server A standalone application server environment runs your enterprise applications. The application server is managed from its own administrative console and functions independently of all other application servers.

—–> WebSphere Application Server requires at least one profile to be functional as an actual server.

5. Ensure the Application server option is selected and click Next to continue:

6. In the Profile Creation options screen as shown in the following screenshot, select Advanced profile creation. Choosing this option allows for greater choice, flexibility, and control of our profile creation as opposed to using a default configuration. Default configurations are set by the wizard, and use naming conventions and settings that you may not wish to use, but are useful if you are needed to quickly build a test/development environment:

 

 

7. On the next screen, we can see that the there are some optional choices. The Deploy the administrative console (recommend) option will install a special web application allowing an administrator to configure WAS using a webbased UI. Please ensure the Deploy the administrative console (recommend) option is selected before continuing.

8. There is also an option to Deploy the default application. The default application contains some very useful testing features,Administrative Features when we look at IBM HTTP Server (IHS).

For now, uncheck this option. Click on Next to continue to the profile name and location screen:

9. In the Profile name and location screen we determine the actual name for our first profile and the location within the filesystem where it will be created. The profile will make up our application server definition. Enter appsrv01 in the Profile name field and <was_root>/profiles/appsrv01 in the Profile directory field, as shown in the following screenshot:

 

—-> Using lowercase for all folder names prompted in a wizard makes it easier to remember especially when typing folder paths in Linux, as Linux is case-sensitive.

If you are going to stop and start the server many times, it is recommended that we turn this option ON to save time when waiting for server restarts.

The following table describes the three runtime-performance options:
Standard — The Standard option invokes conservative settings optimized for general purpose usage. The performance monitoring infrastructure service is enabled to gather statistics so you can further tune the server.

Development — The Development option sets settings to ensure WAS is optimized for performance when updates to applications are requested as would be for a development and/or testing environment.

Production — The Production option sets settings to ensure WAS is optimized for performance when updates to applications are infrequent.

 

1. Click Next to move on to the next screen.

2. The next screen is the Node and Host Names screen. The Node name is an important part of the installation process. It is recommended to keep this name as short as possible.The Server name is the actual name of the application server’s JVM. This name will be referred to in logging and configuration.The Host name will automatically be taken from the OS host’s file and can be changed in the wizard at this point to suit your requirements. You can use a hostname, or Fully Qualified Domain Name (FQDN). If you decide to change the hostname in the wizard, ensure that the change is reflected in your host file or DNS as required.

 

3. Enter the values listed in the following table into the fields on the Nodes and Host Names screen:
Node name — node01

Server name — server01

Host name In the examples, we have used node01.waslocal.com, which has been added to the local host file and points to 127.0.0.1 (localhost)

4. You can see the application of these values in the following screenshot.

5. Click Next to move on to the Administrative Security screen.
6. In the Administrative Security screen, we will disable administrative security for now.It is recommended for production environments that you enable administrative security right from the start to secure against unwanted changes being made to your server configuration by non-administrators. Leave the option Enable administrative security unchecked and click Next to move on to the security certificate screens.

7. The next screen is the Security Certificate (Part 1) screen. This is a new feature of the WAS installation wizard available since version  In previous versions of WAS, the security certificate screens were not available. The options available are: to use default certificates, use an existing keystore, or create one from another Certificate Authority (CA). For now, we will use the default keystore as generated by the installer.We will accept the default settings. Click Next to go to the Security Certificate (Part 2) screen.

8. The next screen is the Security Certificate (Part 2) screen. When a browser connects to a page using SSL, it presents the hostname of the URL used to gain access to that page. If the SSL certificate within WAS doesn’t match this hostname, then an exception will be displayed. The reason for this is that SSL provides a secure connection. If you connect to a host and the actual hostname doesn’t match the hostname associated with the SSL certificate presented by the server, then you need to be informed whether to trust the site or not. The wizard will generate a self-signed certificate as part of the installation process. By updating the distinguished name of the self-signed certificate that WAS generates, we can stop browser exceptions.

In the Issued to distinguished name field, type the following:

cn=node01.waslocal.com,ou=Node01Cell,ou=node01,o=IBM,c=US

In the Issued by distinguished name field type the following:

cn=node01.waslocal.com,ou=RootCertificate,ou=Node01Cell,ou=node01,o=IBM,c=US

 

9. Click Next to move on to the Port Value Assignment screen.

10. WAS requires the use of several ports during runtime. It is wise to ensure that no other application is already using the ports that you wish to use. The wizard is quite clever and will detect port usage, even including older versions of WAS, and recommend free ports; however, it is good practice to use the Linux/Windows command netstat –an to ensure that no other processes are using these ports. Use the following steps to check for used ports:

°° Open a secure shell to your Linux server, or for Windows simply open a command prompt.

°° Type the following command:

netstat –an

°° Within the report that is generated, you are looking to see if ports have already been used.

The following table shows the default ports that WAS will use:

 

11. Since this is our first WAS profile, we will use the defaults recommended by the wizard. If you see different ports than the default ones, then it means you must have other processes running on these ports, or another version of WAS is already installed.

— The administrative console port is very important. We will use this port to gain access to the administration console. Please take note of the Administrative console port (Default 9060), before you move on to the next step.

 

12. Click Next to go to the next step of the installation, where we choose whether we want WAS to automatically restart on reboot. If you wish to have WAS automatically start up again when a server is rebooted, then you can enable this option. In our examples, we don’t require WAS to start on reboot, so we will leave the Run the application server process as a Linux service checkbox unchecked.

°° Linux users: If enabled, the wizard will generate an automatic start and stop script in the init.d directories as required by the Linux run levels. We will not be discussing Linux run levels in this book; please consult your Linux distribution’s documentation.

°° Windows users: For those of you who have chosen to install WAS on Windows, the equivalent screen will provide an option to install Windows service. You will require administrative privileges to ensure that the service can start and stop WAS correctly.

Automatic start and stop scripts are recommended for production environments. However, Linux administrators may wish to craft their own start-up scripts. If you wish to learn how these startup scripts work, then enable the creation of the Linux Service Definition to view the resulting script and it is also recommended that you consult how Linux run levels work.

If you wish to add a service definition post-install and have appropriate access, you can run the WAS Linux command script <was_root>/bin/wasservice.sh or the Windows command script <was_root>\bin\wasservice.bat, which will create the appropriate start and stop scripts.

 

13. Click Next to enter the Web Server Definition screen.we will skip this screen, leaving the Create a Web server definition checkbox unchecked. Click Next to move on to the Profile Creation Summary screen. If webserver required then check this option.

14. The final step of the wizard is Profile Creation Summary. The wizard presents a summary of your configuration options. If you are not happy with your configuration, you can go back and change your settings. If your settings are correct, click Create, which will start the profile creation.

 

First steps console

Once the profile creation is complete, you can choose to run the First steps console, which offers a few checks that you can run to verify that the installation and profile creation was successful. To verify your GUI-based installation, it is best to ensure that you run all the checks within, and ensure that your installation and profile creation was successful and get quick proof that WAS is actually functional. 1. Launch the First steps console by selecting the on-screen option labeled Launch the First steps console, and click Finish which will trigger the console to load. You can see the console in the following screenshot:

2. Click on the Installation verification option in the First steps console as shown in the previous screenshot. If there were no problems with the installation, WAS will be started and a report similar to the following screenshot will be generated:

 

 

3. Now that we have proven the application server was able to start, we can now stop the server by clicking on Stop the server. The First steps console should now report that server01 has stopped. This is shown in the following screenshot:

 

4. You can now close down the First steps console window. When you exit the First steps console and return back to the Profile Management Tool, you will see that the new profile is listed in the profile list, as shown in the following screenshot:

 

 

5. You have now successfully installed the WebSphere Application Server. You can close the PMT.

 

Profile Manager Tools (PMT) logs and files

Similar to the installation logs, the Profile Management Tool (PMT) also leaves a small footprint of logs detailing the profile creations.

Logs

During the creation of a profile, the PMT logs to a file called pmt.log in the <was_root>/logs/manageprofiles folder. This log file can be used to help diagnose causes of issues when a profile creation fails. This file most probably will not need to be consulted very often.

Files

After a profile is created, a useful file called AboutThisProfile.txt is created in the profile’s logs folder; for example, <was_root>/profiles/appsrv01/logs. This file can be useful to determine basic information about the profile-like ports and general settings.

Also located in the logs folder is a file called ivtClient.log, which contains the logging information, reported previously in the First steps console..

 

Administrative console

To test our application server is functioning correctly, we will log in to the administration console. The administration console is a web application, which is used to configure the WebSphere Application Server. You can use it to perform tasks such as:

• Add, delete, start, and stop application servers

• Deploy new applications to a server

• Start and stop existing applications, and modify certain configurations

• Add, delete, and edit resource providers

• Configure security, including access to the administrative console.

• Collect data for performance and troubleshooting purposes

Currently, the application server is in a stopped state. Before we can log in to the admin console, we must start the newly created application server. To start the application server, we can use a special command script. Command scripts are found in the <was_profile_root> directory.

 

There are two scripts that we will use often throughout the book to start and stop WAS.

startServer.sh — (Linux)
StartServer.bat — (Windows)

Used to start a given application server.

Example usage: startServer.sh <servername>

stopServer.sh (Linux)
StopServer.bat (Windows)

Used to stop a given application server.

Example usage: stopServer.sh <servername>

To start our application server, we will use the startServer.sh command as follows:

<was_profile_root>/bin/startServer.sh server01

Once you run the script, you will see the following output in the Linux SSH session or command-line console if you are using Windows:

ADMU0116I: Tool information is being logged in file /apps/was8/profiles/appsrv01/logs/server01/startServer.log
ADMU0128I: Starting tool with the appsrv01 profile
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.

When the server has actually started, you will see an extra line mentioning that the server has started and its associated UNIX Process ID (PID).

ADMU3000I: Server server01 open for e-business; process id is 3813

Now that the application server has started, we can navigate to the admin console URL.

We can craft the URL as follows:

http://<hostname>:<port>/ibm/console

We noted earlier that an important port was the admin_default port, which in our case is 9060. By using this port and the IP address/hostname/FQDN of our server, we can access the admin console with our favorite web browser using a URL similar to the following URL:

http://node01.waslocal.com:9060/ibm/console

If you made a host-file modification on our desktop machine, we would be able to use a hostname or FQDN to access the admin console  from your workstation as by default, the hostname on the server will not be known to a client machine unless you use DNS. If you are  able to browse from the local server machine where the application server is running, you can use

http://localhost:9060/ibm/console

When we navigate to the admin console URL, we see the following login screen:

During the installation, we opted not to turn on global security, and so we can log in using any username and no password is required.

Once logged in, we can see the administration console welcome screen and the main navigation panel on the left-hand side (LHS). Looking at the LHS panel shown in the following screenshot, we can see a list of all the configuration items, that is features and resources that are available for WAS administration:

 

 

The administration panel provides a GUI that allows administrators to administer WAS. There is also an interactive command-line interface called wsadmin.sh for Linux or wsadmin.bat for Windows, which is used for administering WAS without using the admin console.

Uninstalling WAS

 

It is important to know how to uninstall WAS correctly because if you don’t, residual folders and files can be left behind. If you try to install WAS over an existing WAS installation, the wizard will exit in error. So if you purposely want to re-install again into the same folder path, you need to ensure that WAS is removed correctly before you do so.

First we need to stop the WAS process using the stop server command located in the following folder <was_root>/<profile_root>/bin

1. For Linux:
<was_profile_root>/bin/stopServer.sh server01
2. For Windows:
<was_profile_root\bin\stopServer.bat server01

 

Manually deleting profiles
Before uninstalling WAS binaries it is good practice to remove profiles ahead of uninstalling WAS. To delete a profile, you can use the manageprofiles.sh command-line script. Using a SSH/Terminal session for Linux (or command prompt in the case of Windows), navigate to <was_profile_root>/bin and then type the following command:

1. For Linux:
./manageprofiles.sh -listProfiles

2. For Windows:
manageprofiles.bat -listProfiles

The result will be:
[appsrv01]

To delete the appsrv01 profile, run the following command:

1. For Linux:
./manageprofiles.sh -delete -profileName appsrv01

2. For Windows:
manageprofiles.bat -delete -profileName appsrv01

You can use the help switch of the manageprofiles. sh/manageprofiles.bat command to list the available command-line arguments.

Uninstalling WAS using IIM

You can use the IIM GUI to uninstall WAS using the following steps:

1. Load IIM and click on the Uninstall button, as shown in the following screenshot:

2. In the Uninstall Packages screen, select the IBM WebSphere Application Server Trial v8.0 package, as shown in the following screenshot and click Next to continue:

 

3. The wizard will then provide a summary screen; click Uninstall to continue. IIM will then remove all WAS profiles for that particular WAS package, and then remove the WAS binaries. The entire repository located in the <iim_ shared_resources> folder will also be deleted. Once the uninstall process is complete, a screen will be presented giving you the option to view the uninstall logs:

 

4. Click Finish to return to the IIM workbench. You can now close the IIM.
5. Delete the <was_root> installation folder.

Uninstalling WAS using command line

IIM has some new features for uninstalling WAS. You can work with response files and Installation Manager to uninstall the product silently in a variety of ways. You can use a response file by:

• Recording a new response file and using the GUI

°° The process of recording a response file is the same as recording an installation response file.

• Using a response file

°° IIM provides a simple sample-response file called uninstall.xml, which can be used as part of a silent uninstall. We will cover how to do this in the following paragraph.

Running the uninstaller script with no parameters will automatically launch the IIM, and then you will be provided with the same process as mentioned previously. However, if you need to run the install in headless mode (with no GUI) you can use the commands which follow. To uninstall via the command line using the default sample response.xml file as created by IIM during the installation, navigate to the <iim_root>/eclipse directory and run the following command:

1. For Linux:
./IBMIM --launcher.ini silent-install.ini -input <was_root>/uninstall/uninstall.xml -log /var/tmp/uninstall_log.xml

2. For Windows:
IBMIM.exe --launcher.ini silent-install.ini -input <was_root>\uninstall\uninstall.xml -log c:\temp\uninstall_log.xml

Following a successful uninstall you will need to remove the original folder where you installed WAS, as contained within are the logs from the installation process. You cannot install WAS into the same location a second time if it is not empty.

The uninstaller will now unregister the WebSphere 8.0.0.0 package group we installed earlier and then it will delete the WAS binaries from the filesystem. Once the uninstall process has completed, you can delete the <was_root> folder and all its contents, allowing you to re-install into the same location at a later stage.

 

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.