Wa2097 Rel 1 0 Eval Labguide

Student Labs
Web Age Solutions Inc.
EV
AL
U
AT
I
LY
WA2097 WebSphere Application

Server 8.5 Administration on Linux
Copyright 2013 Web Age Solutions Inc.
Table of Contents
EV
AL
U
AT
I
LY
Directory Paths Used in Labs..............................................................................................3

Lab Notes.............................................................................................................................4
Lab 1 - WebSphere 8.5 Installation......................................................................................5
Lab 2 - Install an Application.............................................................................................25
Lab 3 - IBM HTTP Server and Web Server Plug-in..........................................................38
Lab 4 - Solving Problems..................................................................................................73
Lab 5 - Logging With HPEL..............................................................................................86
Lab 6 - Install Database Application................................................................................105
Lab 7 - Enable JMS Messaging Using WebSphere MQ..................................................121
Lab 8 - Configure WebSphere Security...........................................................................137
Lab 9 - Configure Java EE Security................................................................................152
Lab 10 - Web Services.....................................................................................................180
Lab 11 - Monitor Performance.........................................................................................192
Lab 12 - Configuring and Analyzing Memory................................................................213
Lab 13 - Use wsadmin Scripting......................................................................................224
Lab 14 - Additional Jython Scripting...............................................................................241
Lab 15 - Create Deployment Manager Profile.................................................................263
Lab 16 - Configure Cell Architecture..............................................................................269
Lab 17 - Configure Cluster and Remote Web Server......................................................280
Lab 18 - Install Clustered Application.............................................................................297
Alternate Lab 1 - Enable JMS Messaging Using Default Messaging.............................320
Directory Paths Used in Labs

The following directories will be referred to often in the labs. To simplify lab
instructions there are many places where the variables listed below will be used in place
of the actual directory path.
Some directories which should already exist before you start the labs are listed below
with values. Please verify the location of these directories matches what is listed here
and make a note of the change if it does not. Also notify your instructor if anything does
not match.
Some directories will not yet exist as you will be installing software in the labs. These
are listed here so you can write down the appropriate directory here when installing the
software.
Directories that should exist already:
LY
<WAS_SOFTWARE_DIR>: /root/Software/WAS-ND-85
<LABFILES_DIR>: /root/LabFiles
AL
U
<MQ_ROOT>: /opt/mqm
AT
I
<DB2_ROOT>: /opt/ibm/db2/V9.5
EV
<JMETER_ROOT>: /root/Software/jakarta-jmeter-2.3.4
Directories created during labs:
<IM_ROOT>:
<WAS_ROOT>:
<IHS_ROOT>:
<PLUGIN_ROOT>:
Lab Notes
This section has notes that will be referred to throughout the labs. Various labs will have
you write down information in this section to document important settings or to use in
later labs.
Lab 1 - WebSphere 8.5 Installation

Profile name <profile>:
Node name <nodename>:
Host name <hostname>:
Lab 4 - Solving Problems
LY
System.out File Name (including path):
Lab 7 & Alternate Lab 1 - JMS Messaging
AT
I
JNDI Name for Queue:
JNDI Name for Connection Factory:
AL
U
JNDI Name of Activation Specification:
Lab 15 Create Deployment Manager Profile
EV
Node Name of Deployment Manager Profile:

Cell Name of Deployment Manager Profile:
Host name of Deployment Manager machine <DM-hostname>:
Admin Console port of Deployment Manager:
SOAP port of Deployment Manager (DM_SOAP_PORT):
Lab 1 - WebSphere 8.5 Installation

In this lab you will install the WebSphere Application Server 8.5. WebSphere
Application Server relies on TCP/IP networking. It is important to have networking
correctly configured before starting the installation and the host name must remain fixed.
Your lab machine should be configured correctly for the lab.
WebSphere Application Server 8.5 also uses a new installation method (since WebSphere
8.0) called the "Installation Manager". This is a separate software package that is
installed specifically to install and update the software required for WAS.
You will be logging in as the root user to install and configure WebSphere:
User ID:
root
password:
CentOS
At the end of this lab you will be able to:
LY
1. Install WebSphere Application Server 8.5
2. Explore the major WebSphere directories
3. Start the Application Server
AT
I
5. Stop the Application Server
4. Test the WebSphere Installation
AL
U
Part 1 - Install the Installation Manager
EV
The first step in installing WebSphere is to install the 'Installation Manager' software. In
this section you will use a custom script to install the 'Installation Manager' software
silently. This is a common approach to installing software instead of the graphical wizard
you could also run.
__1. Make sure that you are logged in as the administrative user listed above. If you are
not, log off and log back on as the user root above.
Note: You can install and run a WebSphere server as a non-root user. Search the
InfoCenter with the phrase non-root to find many topics about how to accomplish this.
In the labs, you will remain logged in as the root user to simplify the labs.
Be sure to check the platform specific installation instructions before installing
WebSphere on your own machines. The details about disk space and other requirements
will be detailed there. This lab should not be used as the only resource in preparing for
your WebSphere installation.
__2. Open a terminal window. You can do this by selecting 'Applications -> Accessories
-> Terminal'.
__3. Use the 'cd' command to navigate to the <LABFILES_DIR>/InstallWAS directory

substituting the value of the <LABFILES_DIR> variable with the location mentioned in
the list of directory paths at the beginning of these labs. Check with your instructor if
you can't find the directory listed.
__4. Execute the following command to verify the script is executable.
# chmod +x *
__5. Open a File Browser window. You can do this by selecting 'Applications -> System
Tools -> File Browser'.
LY
__6. Browse to /opt/IBM folder.
__7. Using the tools of the File Browser create the following new directory. Notice there
is an 'ITM' directory that already exists as part of the DB2 install but you are creating a
separate directory as shown below.
EV
AL
U
AT
I
/opt/IBM/IM
Note: This will make sure you can write to this directory which will be important later.
If for some reason you can't create this directory inform your instructor as you will need
to alter the 'IM_LOCATION' variable in the script that is run later.
__8. In the File Browser window navigate to the <LABFILES_DIR>/InstallWAS
directory substituting the value of the <LABFILES_DIR> variable with the location
mentioned in the list of directory paths at the beginning of these labs.
__9. Copy the 'custom_install_im.sh' file from this folder. Only copy this file. This file
is a custom file that will run the Installation Manager install process silently. The file is
customized already to help reduce install errors.
__10. Navigate to the <WAS_SOFTWARE_DIR>/InstallationManager/tools directory

substituting the value of the <WAS_SOFTWARE_DIR> variable with the location
mentioned in the list of directory paths at the beginning of these labs. Check with your
instructor if you can't find the directory listed.
__11. Paste the copied file into the
<WAS_SOFTWARE_DIR>/InstallationManager/tools directory.
LY
__12. In a terminal window, use the 'cd' command to navigate to the

<WAS_SOFTWARE_DIR>/InstallationManager/tools directory.
__13. Use the following command to show the content of the file you copied.
# cat custom_install_im.sh
EV
AL
U
AT
I
__14. Notice the main line in this file calls the 'imcl' program. Although there are various
ways to install the Installation Manager this method is the easiest to customize the
installation directory. We are also installing with 'nonAdmin' access rights which will
help avoid some potential security issues. Your needs for installing the Installation
Manager may be slightly different so refer to the Installation Manager documentation for
the difference in installation methods.
Note: One important option is the -installationDirectory option. By default for the
"nonadmin" installation it would be in the user home directory so we are setting a more
visible directory for this setting.
__15. Issue the following command to start the execution of the custom silent install.
You will not be immediately returned to the command prompt which indicates the silent
installation is proceeding. Leave the command prompt open.
# ./custom_install_im.sh
AT
I
LY
__16. After a few minutes check that you are returned to the command prompt with a
message about something being installed and without any errors being displayed.
EV
AL
U
__17. In a File Browser window navigate to the '/opt/IBM/IM' directory and verify you
see files installed as shown below.
__18. Write down this installation directory as the value of the <IM_ROOT> variable in
the list of directory paths at the beginning of these labs.
Part 2 - Record Response File

Although it is common to want to install software with a response file, coming up with
the syntax of these files can be difficult. Performing an installation using a GUI tool can
be easier since it can show you the various options and make it easier to supply values.
With the Installation Manager a hybrid solution can be used that will use the GUI install
tool to create the response file that can then be used in a command line software
installation. The key to doing this with the Installation Manager is to launch the tool in
"record" mode.
__1. Open a File Browser window.
__2. Navigate to the <LABFILES_DIR>/InstallWAS directory substituting the value of
the <LABFILES_DIR> variable with the location mentioned in the list of directory paths
at the beginning of these labs. Check with your instructor if you can't find the directory
listed.
LY
__3. Copy the 'custom_im_record.sh' file from this folder. Only copy this file. This file
is a custom file that will run the Installation Manager to record a response file. This can
only be done by supplying command line parameters when starting the Installation
Manager which is why this file is supplied for you.
AT
I
__4. Navigate to the <IM_ROOT> directory substituting the value of the <IM_ROOT>
variable with the location you wrote down in the list of directory paths at the beginning of
these labs.
EV
AL
U
__5. Paste the copied file into the <IM_ROOT> directory.
__6. In a terminal window, use the 'cd' command to navigate to the <IM_ROOT>
directory.
# cat custom_im_record.sh
__8. Notice the key options of -skipInstall which will prevent the Installation Manager
from actually installing anything and -record with the file to be created with the recorded
response file.
LY
Note: The directory used after -skipInstall (DATA_LOCATION above) should be a

directory used only when recording response files. The installation manager uses this to
track what has perhaps already been installed and using the same directory as a previous
use of the tool when recording a response file might corrupt that configuration. If using
one Installation Manager setup to record response files for different WebSphere
environments you would want to have a different data directory that tracks what has
been installed into each environment.
EV
AL
U
# ./custom_im_record.sh
AT
I
__9. Issue the following command to start the Installation Manager. Leave the command
prompt open.
__10. From the Installation Manager window that appears select 'File Preferences'.
__11. Next to what should be an empty list of repositories click the 'Add Repository'
button.
10
__12. Click the Browse button and navigate to the <WAS_SOFTWARE_DIR>/Main

directory.
LY
__13. Select the 'repository.config' file in this location as shown below and click the OK
button to select the file.
EV
AL
U
AT
I
__14. Back in the Installation Manager, make sure the proper location for the repository
configuration file is listed and click the OK button.
__15. Make sure the repository is listed and click the OK button to close the preferences.
11
__16. Back in the Installation Manager select 'File Open Install Packages'.
LY
__17. On the Install Packages screen check the box next to 'IBM WebSphere
Application Server Network Deployment' which should be listed and click the Next
button.
Note: If you see any issue with prerequisites check with your instructor.
AT
I
__18. After a few seconds the license screen should be shown. Accept the license and
click the Next button.
EV
AL
U
__19. Change the value of the shared resources directory to '/opt/IBM/IMShared' as

shown below. If you had to install the Installation Manager to a different location
because you didn't have write access to the hard drive let your instructor know so a
different directory could be chosen.
Note: You could install into the default which is in the user home directory which could
avoid issues with file permissions. We are using a different directory here to install
everything under '/opt/IBM'.
__20. Click the Next button once your shared resources directory is modified.
12
LY
__21. Change the value of the WebSphere installation directory to

'/opt/IBM/WebSphere/AppServer' as shown below.
__22. Write down the installation directory for the <WAS_ROOT> variable in the list of
directory paths at the beginning of these labs. This directory will be used later in the labs.
__23. Click the Next button once your WebSphere installation directory is modified.
__24. Leave the default options for installed languages and click the Next button.
EV
AL
U
AT
I
__25. Leave the default features selected and click the Next button.
Note: On 64-bit systems you would see a choice for the JDK version to install. On
systems that support it, you might normally select the 64-bit JDK, especially in
production.
13
LY
__26. Verify that the options are configured as below and click the 'Install' button.
AT
I
Note: This does not actually install anything but creates a response file with the
appropriate settings you configured going through the process.
EV
AL
U
__27. After just a few seconds you should see a message that the "installation" was
successful. Click the Finish button.
14
__28. In the Installation Manager select 'File Exit'.
LY
__29. Check in your <LABFILES_DIR> folder that you see the XML response file that
was recorded.
Part 3 - Install WebSphere with Response File
AL
U
AT
I
Now that you have recorded a response file, it can be used to install the WebSphere
software. If you were installing WebSphere on several machines you might only need to
record the response file once and on each machine you could install the Installation
Manager and the WebSphere software.
EV

listed.
__3. Copy the 'custom_install_WAS.sh' file from this folder. Only copy this file. This
file is a custom file that will run the Installation Manager to use the recorded response file
generated in the last section.
__4. Navigate to the <IM_ROOT> directory substituting the value of the <IM_ROOT>
variable with the location you wrote down in the list of directory paths at the beginning of
these labs.
15
__5. Paste the copied file into the <IM_ROOT> directory.
directory.
LY
# cat custom_install_WAS.sh
EV
AL
U
AT
I
__8. Notice the key option of 'input' which will point to the custom response file you
recorded.
Note: It is also important that you are using the 'imcl' from within the '/eclipse/tools'
subdirectory of the Installation Manager install. Even though this was the same thing
you used to install the Installation Manager, you should use the version from within the
Installation Manager once it is installed.
16
__9. Issue the following command to start the installation of WAS. You will not be
immediately returned to the command prompt which indicates the silent installation is
proceeding. Leave the command prompt open. You might want to take a quick break at
this point.
# ./custom_install_WAS.sh
LY
__10. After several minutes check that you are returned to the command prompt with a
message about WebSphere being installed and without any errors being displayed.
EV
AL
U
AT
I
__11. In a File Browser window navigate to the '/opt/IBM/' directory and verify you see
files installed as shown below. You should see the 'IMShared' and 'WebSphere' folders
that were not there before.
17
Part 4 - Create a WebSphere Profile

One of the last steps to having a working WebSphere installation is to create a "profile".
This is the configuration of the software which can include actual servers. Since we will
start out with a single server environment we will start by creating an "Application
Server" profile. This can be done graphically or with a response file as shown in this
section.
listed.
LY
__3. Copy the 'custom_create_profile.sh' file from this folder. Only copy this file. This
file is a custom file that will run the profile management tool with a few options. This
file is simply being provided to help prevent typos when running the profile management
tool.
__4. Navigate to the <WAS_ROOT>/bin directory substituting the value of the

<WAS_ROOT> variable with the location you wrote down in the list of directory paths at
the beginning of these labs.
EV
AL
U
AT
I
__5. Paste the copied file into the <WAS_ROOT>/bin directory.
__6. In a terminal window, use the 'cd' command to navigate to the <WAS_ROOT>/bin
directory.
# cat custom_create_profile.sh
18
__8. Notice the key options of -create and -templatePath which are the minimum options
needed when using the "default" profile as this command does. Some additional options
are provided to configure administrative security also.
LY
Note: Although there are a lot of options you can provide when creating a profile, the
"default" profile can provide defaults for all of them. It is a very useful template for a
quick profile configuration. The only reason you were provided a script file to run
instead of typing the command directly is to enable administrative security which would
require quite a bit of typing. By default administrative security is disabled so you will
enable it with this command.
EV
AL
U
AT
I
# ./custom_create_profile.sh
__9. Issue the following command to start the profile creation. Leave the command
prompt open. You might want to take a quick break at this point.
__10. After several minutes the command should complete and return to the command
prompt without errors. Make sure you get a message about 'INSTCONFSUCCESS' as
shown below.
19
__11. Open a File Browser window and navigate to the

<WAS_ROOT>/profiles/AppSrv01/logs directory.
__12. Open the 'AboutThisProfile.txt' file in a text editor. Select 'Display' if you are
given choices when double-clicking the file.
AL
U
AT
I
LY
__13. In the file that is opened, note the Profile name, Node name, and Host name.
Write these values down in the Lab Notes section at the beginning of the lab guide.
EV
__14. Close the text file showing the profile information.
20
Part 5 - Verify Application Server

Now that the profile exists it will be good to verify the server can start and can be
accessed.
__1. Start the Application Server. Do this by following the set of steps below:
Open a terminal window. You can do this by selecting 'Applications ->
Accessories -> Terminal'.
Use the 'cd' command to change to the <WAS_ROOT>/profiles/AppSrv01/bin

directory.
Issue the command './startServer.sh server1'.
LY
Note: Get familiar with opening a terminal window in this directory and running this
command as this will be the default way used to start the server.
EV
AL
U
AT
I
__2. Verify that you get a message that the server is "open for e-business". Leave the
terminal window open.
21
__3. Once the server is started, open a web browser and type the URL
'http://localhost:9080/snoop' into the address bar. You should see the output below.
__4. Close the web browser used to test the Application Server.
LY
__5. Stop the Application Server. Do this by following the set of steps below:

directory.
Issue the command './stopServer.sh server1'.
When prompted for security enter a user and password of wasadmin.
AL
U
AT
I
EV
Note: In the future, when you are asked to start and stop the server you will use the steps
outlined in this section.
You can also issue the following command to stop the server to avoid getting prompted
for security information each time:
./stopServer.sh server1 -username wasadmin -password wasadmin
The issue with supplying the user and password in the command is that these would be
visible to the 'ps' process listing command. This can be viewed as a security risk.
22
__6. Wait until you see the following result.
Part 6 - Explore Application Server Directory Structure

This section will point out some of the major directories in the WebSphere installation.
LY
__2. Navigate to the <WAS_ROOT> directory you wrote down in the notes at the
beginning of these labs. This should be the main installation directory for WebSphere.
__3. Look at some of the major directories and their contents:

bin executable programs, scripts, and DLLs
installableApps complete applications which can be installed
java JDK 1.6 files (supports Java SE v6)
lib library of various Java .jar files used by WebSphere
web documentation resources
profiles/AppSrv01/config configuration files for the installation
profiles/AppSrv01/etc default SSL files
profiles/AppSrv01/installedApps applications installed on the server
profiles/AppSrv01/logs default directory for various trace and log files
profiles/AppSrv01/properties configuration property files used by WebSphere
EV
AL
U
AT
I
__4. Look at some of the log files created during the installation and verification:
<WAS_ROOT>/logs/postinstall/postinstall.log - logs installation events
<WAS_ROOT>/logs/manageprofiles/AppSrv01_create.log - log messages

related to the creation of the AppSrv01 profile
<WAS_ROOT>/profiles/AppSrv01/logs/server1/SystemOut.log - main log file

for Application Server
23
__5. Close all File Browser windows.

__6. Close all terminal command prompts.
__7. Close all web browsers.
Part 7 - Review
In this lab you installed the WebSphere Application Server. You also ran some basics
tests of the server and familiarized yourself with some basic commands. You are now
able to start and stop the server and can identify some of the major directories in the
WebSphere installation.
One of the key things to take away from this lab is the role of the 'Installation Manager'
software. Even though we just saw this a little it will be a primary tool used to manage
WebSphere software installations.
EV
AL
U
AT
I
LY
Even though you installed the Network Deployment software, the profile that you created
is exactly what you would have after installing the Base edition of WebSphere. The
only difference is that when you install the Base edition you only get one option for the
type of environment to create.
24
Lab 2 - Install an Application

In this lab you will install a simple application to the Application Server. This application
has only one simple function, printing a message out to the screen. It does not use any
external resources. This is so you can concentrate on installing an application without
needing to configure any other resources first.
1. Use the Admin Console for administering applications on the server.
2. Install an application to the Application Server.
3. Test applications that have been deployed to the server by submitting web
requests.
Part 1 - Control Applications From the Admin Console
LY
In this section you will use the Admin Console to control applications deployed to the
server. You will also see an example of the response returned if a deployed application is
stopped.
__1. Start the Application Server. Do this by following the set of steps below:

directory.
Issue the command './startServer.sh server1'.
AL
U
AT
I
EV
__2. Start the Admin Console by opening a Web browser and entering the URL
http://localhost:9060/ibm/console/
25
__3. Since security is enabled you will get a warning about the server certificate. Accept
the certificate or continue to the website depending on the browser you are using.
Note: You will get this warning every time you access the Admin Console. You could
also Install the certificate in your web browser to indicate you trust the site to prevent
the warning.
AL
U
AT
I
LY
With Firefox you "Add an exception".
EV
__4. Enter a user ID and password of wasadmin and click Log in on the Login screen
of the Console.
26
LY
__5. Expand the Applications group in the Navigation tree, expand Application Types
and click on the link for WebSphere enterprise applications.
__6. Check the checkbox next to the DefaultApplication and press the Stop button. You
should get a message that the application was stopped and a red X in the status column.
__7. Open a separate Web browser and try to access the Snoop Servlet as in the last lab.
The URL is http://localhost:9080/snoop. You should get an error. This is because it is
part of the DefaultApplication which is stopped.
AL
U
AT
I
__8. In the Admin Console, check the checkbox next to the DefaultApplication and
press the Start button. You should get a message that the application was started and a
green arrow in the status column.
EV
__9. In the Web browser you used to access the Snoop Servlet, hit the refresh button.
You should see the normal output of the Snoop Servlet.
__10. Close the extra Web browser you were using to test the Snoop application.
27
Part 2 - Install an Application to the Server

In this section you will install an application to the server. After installing and starting
the application the Application Server will be able to handle requests that were not part of
the testing and verification applications that already come installed on the server. This
section will familiarize you with the basic process of installing an application.
__1. Return to the web browser you were using for the Admin Console. If you had
closed it you can open it at http://localhost:9060/ibm/console/ and login is wasadmin.
__2. In the Applications group in the navigation, click the link for New Application.
__3. Click the link for New Enterprise Application.
__4. Next to the Local file system box, press the Browse button.
AL
U
AT
I
LY
__5. Find the file <LABFILES_DIR>/InstallApp/HitCount.ear and select Open in the

file chooser dialog. Remember to substitute the value of the <LABFILES_DIR> variable
from the notes at the beginning of the labs.
__6. Press the Next button.
EV
__7. Check the option for Detailed installation. This will show all steps.
__8. Once you have the options specified as below, press the Next button.
28
Note: The next sequence of steps will vary depending on the application you are
installing. Since this application is fairly simple there are only a few steps and a
summary. There would be fewer steps if we had not checked the option for showing all
options.
__9. On step 1, check the Precompile JavaServer Pages files option and click Next.
LY
__10. Accept the default values on steps 2-14 by pressing the Next button on each step.
Some of these steps will only appear once you go through other steps. You should end up
at step 15 which is the summary. Some of the intermediate steps are explained below:
Step 2: Map modules to servers - This step would be more important in a multi-server
environment. This step will also be more important with web servers later.
AL
U
AT
I
Step 3: Provide options to compile JSPs - This step appears because of the option you
selected to precompile JSPs. Most of the time the code needed to compile JSPs is in the
application itself but if it is not you may need to supply additional options here.
EV
Step 4: Provide JSP reloading options for Web modules - This service can
automatically check if a new version of a JSP file has been deployed to the application
without restarting the entire application. Most of the time you would leave this service
on but you could increase the time interval in production.
Steps 5 & 6: Shared libraries - Shared libraries are shared code that is required by an
application but is not packaged with the application itself. If you have previously
configured a shared library you can map it to an application module with these steps.
Step 7: Provide JNDI names for beans & Step 8: Bind EJB Business These steps
are presented if the application includes EJBs. The JNDI name can be used by EJB
clients to locate the EJB. Some EJB clients can also obtain a reference to the EJB using
Java EE injection where the JNDI name may not be required. If your developers are
using Rational software this value may be filled in already. It would be important to
coordinate the values of these properties with developers.
29
Step 9: Map EJB references to beans An EJB reference is another way for an EJB
client to be linked to a target EJB. Again, this value may not be required if an application
uses Java EE injection.
Step 10: Map virtual hosts for Web modules - Virtual hosts affect the URL that is used
to access the application. This will be discussed more later.
Step 11: Map context roots for Web modules - The context root also makes up part of
the application URL. You could change it here if you wish. This will be discussed more
later.
Step 12: Map JASPI Provider Java EE 6 defined a way to integrate an external web
application security authentication mechanism. If you were using this feature here is
where you could provide those options for this application.
LY
Step 13: Metadata for modules Deployment information for applications can be
provided by XML deployment descriptors or through annotations in the code itself. If
you check the 'metadata-complete attribute' in this step for a module of the application,
any deployment information provided in code annotations is ignored. Developers may be
counting on some of these annotations being applied to configure an application so this is
another aspect to coordinate with developers.
AT
I
Step 14: Display module build Ids If installing modules with a build ID in the
MANIFEST.MF file of the module that value will be displayed here. It can't be changed
though and is only displayed. This is often used if using some of the automated build
tools available from IBM as part of the Rational family.
AL
U
__11. On step 15, the Summary, click the Finish button. Wait for it to complete the
installation and be sure you get a message that says Application HitCount installed
successfully.
EV
__12. Click the link to Review changes to the master configuration below the message
about the successful installation.
30
__13. On the Save screen, click the '+' sign to expand the list of changes that will be
made.
Note: The number of changed documents you see may be slightly different.
LY
__14. Click the Save button at the bottom of the page to save the master configuration.
__15. In the Applications group in the navigation, expand the Application Types section
and click the link for WebSphere enterprise applications.
EV
AL
U
AT
I
__16. Start the HitCount application by checking the checkbox next to it and clicking the
Start button.
Note: Sometimes you may see that the red 'X' doesn't turn to a green arrow after starting
an application until you hover your mouse over it.
31
Part 3 - Test the HitCount Application

Now that the application is installed and started you can test it. You will find out how to
submit a web request for an installed application by using properties available from the
Admin Console.
__1. Make sure that you are viewing the list of Enterprise Applications in the Admin
Console. If not, you can expand the 'Applications Application Types' group in the
navigation and click the link for 'WebSphere enterprise applications'.
__2. From the list of applications, click the link for the HitCount application by clicking
on the application name. This will show you a page of options and configuration related
to that particular application.
EV
AL
U
AT
I
LY
__3. From the list of Detail Properties associated with the HitCount application click the
link for View Deployment Descriptor.
32
LY
__4. In the text of the Deployment Descriptor find the value of the context-root. This is
what you can add to the host name and port of the server to access the application.
EV
AL
U
AT
I
__5. Open a new web browser and enter the URL http://localhost:9080/HitCountWeb.
Notice this URL ends in the context-root of the web application. You should see the
following page.
__6. Click the link of the home page of the application. You should get an initial count of
'1'.
__7. Refresh the page several times to see the count increase.
__8. Leave the web browser open that you are using to test the application.
33
__9. Return to your Admin Console web browser. If you closed it, open a new window to
the URL http://localhost:9060/ibm/console/. Make sure you leave the web browser
running the HitCount application open.
__10. Expand the 'Applications Application Types' group in the navigation and click
the link for 'WebSphere enterprise applications'.
__11. Check the checkbox next to the HitCount application and press the Stop button.
__12. Once the application is stopped, check the checkbox next to the HitCount
application again and press the Start button.
__13. Return to the web browser you were using to test the application and refresh the
page. The count should return to 1 even though you are using the same web browser.
The state of the stateful session EJB has been lost by restarting the application.
__14. Close the web browser you used to test the new application.
LY
Part 4 - Deploy Applications with a Monitored Directory
WebSphere Application Server 8.0 added a new way to deploy applications. The server
can be configured to monitor a directory and deploy applications copied into that
directory. This feature is disabled by default and must be enabled.
AT
I
__1. Return to your Admin Console web browser. If you closed it, open a new window to
the URL http://localhost:9060/ibm/console/. Make sure you leave the web browser
running the HitCount application open.
AL
U
__3. Check the checkbox next to the HitCount application and press the Stop button.
EV
__4. Once the application is stopped, check the checkbox next to the HitCount
application again and press the Uninstall button.
__5. Click the OK button to confirm you want to uninstall the application.
__6. In the messages that display at the top of the browser click the Save link.
34
__7. In the Applications group in the navigation, click the link for Global deployment
settings.
LY
__8. Check the box for the 'Monitor directory to automatically deploy applications'
and press the the Apply button. You can leave the default settings.
__9. In the messages that display at the top of the browser click the Save link.
__10. In the web browser showing the Admin Console click the Logout link near the top
of the Console. If you have unsaved changes save them before logging out.
AT
I
__11. Stop the Application Server. Do this by following the set of steps below:

directory.
Issue the command './stopServer.sh server1'.
When prompted for security enter a user and password of wasadmin.
EV
AL
U
__12. Once the server has stopped issue the command './startserver.sh server1' to restart
it. The server must be restarted after enabling monitored directory deployment.
35

__14. Navigate to the <LABFILES_DIR>/InstallApp directory substituting the value of
at the beginning of these labs.
__15. Copy the HitCount.ear file from the directory.
__16. Navigate to the following directory:
<WAS_ROOT>/profiles/AppSrv01/monitoredDeployableApps/servers/server1
LY
__17. Paste the HitCount.ear file in this directory.
__18. Return to your Admin Console web browser. If you closed it, open a new window
to the URL http://localhost:9060/ibm/console/.
AT
I
__19. Login to the Admin Console with a user and password of 'wasadmin'.
AL
U
EV
__21. Check that you see the HitCount application installed and running.
__22. Open a new web browser and enter the URL http://localhost:9080/HitCountWeb.
__23. Test the application as you did before and make sure it works.
36
__24. Close the web browser you used to test the new application.
__25. In the web browser showing the Admin Console click the Logout link near the top
of the Console.
__26. Close the web browser you were using for the Admin Console.
__27. Stop the application server. Do this with the './stopserver.sh server1' command in
a terminal command prompt in the <WAS_ROOT>/profiles/AppSrv01/bin directory.
Remember that you can use the command with credentials as './stopserver.sh server1
-user wasadmin -password wasadmin'.
__28. Close all open windows.
Part 5 - Review
LY
In this lab you installed a simple application and saw the main steps of installing an
application. Even though most applications will be much more complex and require
more steps during the installation the same basic process will be followed.
You also used the "monitored directory" deployment technique to deploy an application
to the server. This is often used most in development or test servers and is most useful if
the application doesn't need additional configuration during installation. If additional
configuration is needed it might be more desirable to develop a script to deploy the
application instead.
EV
AL
U
AT
I
You also saw how to access properties for installed applications to find out how to submit
web requests for testing. There are many other properties associated with applications
and you only saw a few but others are accessed in the same way, by clicking the name of
the application in the list of applications. In fact all configuration properties and options
available in the Admin Console are accessed in a similar fashion. When you click a link
on one page it displays another page with properties for that item.
37
Lab 3 - IBM HTTP Server and Web Server Plug-in

You have already seen how the WebSphere Application Server can handle HTTP requests
without a Web Server. For enhanced network security and performance it is often
desirable to use a Web Server. In this lab you will see how the Web Server and the
WebSphere Application Server work together in this environment.
AT
I
LY
You will be installing the IBM HTTP Server and Web Server Plug-in using the local
configuration which is shown below. In this configuration the web server, plug-in, and
WebSphere server are all on the same machine. Much of the plug-in configuration within
the WebSphere configuration will be done for you using a batch command generated
during the web server installation.
AL
U
1. Install the IBM HTTP Server and Web Server Plug-in.

2. Add a new host name to the IBM HTTP Server.
EV
3. Route requests for this new host name back to your own machine.
4. Configure applications in the WebSphere Application Server to use this host
name.
Part 1 - Install IBM HTTP Server

The first step will be to install the IBM HTTP Server. This has a separate installation
than the WebSphere installation. Although you will be installing the IBM HTTP Server
on the same machine as WebSphere, often this would be done on a different machine.
__1. Make sure you are logged in as the 'root' user ID.
38
__2. Open a terminal window. You can do this by selecting 'Applications -> Accessories
-> Terminal'.
directory.
__4. Issue the following command to start the Installation Manager. Leave the command
prompt open.
# ./eclipse/IBMIM &
LY
Note: We are benefiting from the fact that the Installation Manager was already installed
when WebSphere Application Server was installed. If you were installing the web
server and plugin on a different machine you would also have to install Installation
Manager as well.
You could also record a response file and then install from this as you did with
WebSphere Application Server. We will simply install directly from the Installation
Manager GUI.
AT
I
__5. From the Installation Manager window that appears select 'File Preferences'.
EV
AL
U
__6. Next to the list of repositories click the 'Add Repository' button.
__7. Click the Browse button and navigate to the

<WAS_SOFTWARE_DIR>/Supplement directory. Remember the
<WAS_SOFTWARE_DIR> directory is where the WebSphere software can be installed
FROM and not where WebSphere is currently installed.
39
LY
__8. Select the 'repository.config' file in this location as shown below and click the OK
button to select the file.
EV
AL
U
AT
I
__9. Back in the Installation Manager, make sure the proper location for the repository
configuration file is listed and click the OK button.
40
__10. Make sure the repository is listed and click the OK button to close the preferences.
LY
__11. Back in the Installation Manager select 'File Open Install Packages'.
__12. On the Install Packages screen check the box next to the following options:
IBM HTTP Server for WebSphere Application Server
Web Server Plug-ins for IBM WebSphere Application Server
WebSphere Customization Toolbox
EV
AL
U
AT
I
41
__13. Once the above options are selected click the Next button.
__14. After a few seconds the license screen should be shown. Accept the license and
click the Next button.
__15. From the list shown select each package that will be installed and Change the
installation directory so they will be installed to a subdirectory of the '/opt/IBM'
directory. The installation directories should be:
/opt/IBM/HTTPServer
Web Server Plug-ins
/opt/IBM/WebSphere/Plugins
Customization Toolbox
/opt/IBM/WebSphere/Toolbox
AT
I
LY
IBM HTTP Server
EV
AL
U
__16. Write down the installation directory for the HTTP Server as the <IHS_ROOT>
variable in the list of directory paths at the beginning of these labs. Also write down the
Web Server Plug-ins installation directory as the <PLUGIN_ROOT> variable. These
directories will be used later in the labs.
__17. Once your installation directories are configured as shown above click the Next
button.
42
__18. Leave the default features to install and click the Next button.
LY
__19. Check that your Web Server Configuration options show using port 80.
AT
I
__20. Once you have confirmed you see the proper web server configuration options,
leave the default settings and click the Next button.
EV
AL
U
__21. Verify that the options are configured as below and click the 'Install' button.
43
__22. After several minutes installing software you should see a success message. Leave
the option to launch the 'WebSphere Customization Toolbox' selected and click the
Finish button.
__23. Leave the 'WebSphere Customization Toolbox' open for the next section.
__24. Close the Installation Manager by selecting File Exit from the appropriate
window.
LY
Part 2 - Configure Web Server Plug-in
After the web server and plug-in software is installed it needs to be configured to link the
web server to the WebSphere Application Server configuration. This is done differently
in WebSphere 8.5 with the 'Web Server Plug-ins Configuration Tool'.
EV
AL
U
AT
I
__1. In the 'WebSphere Customization Toolbox' tool that appeared from the last section,
select the 'Web Server Plug-ins Configuration Tool' and click the Launch Selected
Tool button.
44
Note: If you do not have the WebSphere Customization Toolbox open you can run:
/opt/IBM/WebSphere/Toolbox/WCT/wct.sh
__2. In the tool that appears, next to the empty list of 'Web Server Plug-in Runtime
Locations' click the Add button.
AL
U
AT
I
LY
__3. Fill in a 'Name' value of 'Main Plugin' and use the Browse button to select the
<PLUGIN_ROOT> directory written down in the directory paths from early in this lab.
EV
__4. Once you settings appear as shown above click the Finish button.
45
LY
__5. With the new entry for the plug-in location selected above, click the Create button
next to the empty lower list of 'Web Server Plug-in Configurations'.
EV
AL
U
AT
I
__6. Leave the default option of IBM HTTP Server 8.5 selected and click the Next
button.
46
__7. In the options for the web server configuration file use the Browse button to select
the <IHS_ROOT>/conf/httpd.conf file if it is not already selected and click OK.
EV
AL
U
AT
I
LY
__8. Back in the wizard, make sure that you have the correct configuration file listed and
there is no error in the top margin. Also leave the default port of 80 and click the Next
button.
47
EV
AL
U
AT
I
LY
__9. In the options for the 'Setup IBM HTTP Server Administration Server' fill in a
userid, password and password confirmation of 'ihsadmin'. You may need to manually
expand the window size to see all fields. Leave the other default options and click the
Next button.
Note: This user and password is different than the WebSphere user so that it will be
clear of the difference between them in various situations. This step runs the 'htpasswd'
command from the IBM HTTP Server to configure a user and password that can be used
to remotely administer the web server.
This is also not a user for the operating system but for authentication with the
administration service.
48
LY
__10. On the next page, fill in a 'User ID' and 'Group' of 'ihsadmin'. Leave the option
checked to create a new unique system user ID and click the Next button.
AT
I
Note: This step runs the 'setupadm' command from the IBM HTTP Server to configure
what id will be used to run the HTTP Administration service. This will also change
permissions of various web server configuration directories. This user does have to be a
user on the operating system. If you do not already have a user you would like to use
you can leave the option checked, as we are doing and one will be created.
AL
U
The user from the previous step and this step do not need to be the same ID. This is
done in the labs to keep things simple.
EV
You can also run the htpasswd command from the previous step and the setupadm
command from this step manually. Doing this as part of the plug-in configuration can
be easier as the configuration wizard already knows what directories and files would
need to be modified. If you do not run these commands as part of the installation the
remote administration ability will be disabled until you run the commands manually.
__11. Leave the default value of the web server name and click the Next button.
Note: This is the name that you will see later in the WebSphere Admin Console.
49
LY
__12. Leave the default option of a "remote" scenario and fill in the value for the
<hostname> variable you wrote down in the lab notes section for the WebSphere
installation. You can also open a command prompt and run the 'hostname' command to
get the value. Click the Next button when you have configured the settings on this page.
EV
AL
U
AT
I
Note: Even though the web server and WebSphere server are on the same machine we
are choosing the "remote" scenario here because this will more accurately represent a
configuration where they are on different machines. This way, the steps you use when
they are on different machines will be similar to those done here.
50
LY
__13. Make sure that your settings match those shown below and click the Configure
button.
EV
AL
U
AT
I
__14. Make sure that you get a success message, uncheck the 'Launch the plug-in
configuration roadmap', and then click the Finish button. The roadmap could normally
be used to verify the next steps in the configuration of the web server and plug-in.
Note: Also notice there is a script that was created to configure the web server. This will
be used to configure WebSphere.
51
__15. Check that your new plug-in configuration is listed and select 'File Exit' to exit
the Customization Toolbox.
__16. Open a terminal window.

__17. Use the 'cd' command to change to the <WAS_ROOT>/profiles/AppSrv01/bin
directory.
__18. Issue the command './startServer.sh server1'.
LY
__19. Open another terminal window.
__20. Change directories using the 'cd' command to the <IHS_ROOT>/bin directory.
Be sure to substitute the value of <IHS_ROOT> from the Directory Paths page at the
beginning of the lab instructions.
AT
I
__21. Execute the following command to start the web server.
EV
AL
U
# ./apachectl start
__22. Execute the following command to start the HTTP administration service.
# ./adminctl start
52
Note: Although it is possible to register the IBM HTTP Server and HTTP administration
service to start automatically if the system reboots, we have not done this. If you restart
your machine you will need to execute these commands to be sure the web server and
the HTTP administration service are running. Generally they should remain running
unless you are told to stop or restart it.
__23. Open a File Browser window or use one you already have open.
__24. Navigate to the directory <PLUGIN_ROOT>/bin where the <PLUGIN_ROOT>
is the variable you wrote down from the IBM HTTP Server and Plugin installation in the
previous section.
EV
AL
U
AT
I
LY
__25. Find the file 'configurewebserver1.sh' in the directory. Check that you find the
correct file as there are several that start with 'configure...'.
__26. Copy the 'configurewebserver1.sh' file by right clicking and selecting Copy from
the popup menu.
__27. Open another File Browser and navigate to the directory <WAS_ROOT>/bin
where the <WAS_ROOT> is the variable you wrote down from the WebSphere
installation lab.
__28. Paste the 'configurewebserver1.sh' file into this directory by selecting Edit ->
Paste from the menus.
53
__29. Be sure you see the 'configurewebserver1.sh' file in the list of files.
LY
Note: Also note that there is a 'configureWebserverDefinition.jacl' file in the same

directory. This file will be called by the script you just copied in with parameters
configured during the web server installation.
__30. Make sure you have logged out of any previously open Admin Console browser
windows.
AL
U
AT
I
Note: It is important to logout because you will run a script in the next few steps as the
same user you used in the Admin Console. The script seems to have conflicts in this
situation.
EV
__32. Change directories using the 'cd' command to the <WAS_ROOT>/bin directory.
Be sure to substitute the value of <WAS_ROOT> from the Directory Paths page at the
beginning of the lab instructions.
54
__33. Enter the following command to check that the WebSphere server is started:
# ./serverStatus.sh -all -username wasadmin -password wasadmin
You should see on server1 started.
LY
__34. Enter the following command to configure the web server definition in the
WebSphere configuration. The command should all be entered on the same line even
though it wraps to a second line below.
# ./configurewebserver1.sh -profileName AppSrv01 -user wasadmin

-password wasadmin -ihsAdminPassword ihsadmin
EV
AL
U
AT
I
Note: It may take several seconds to show the results.
__35. Scroll back through the messages that were output and be sure you do not see any
errors.
__36. Close any extra command prompts or File Browser windows.
55
Part 3 - Configure Virtual Host on Web Server

The next step will be to configure the IBM HTTP Server to respond to a unique host
name that is not the same as the host name of the machine itself. This virtual hosting
will separate the physical hostnames of your network from the logical hostnames you
expose to the clients of the applications. You will use a host name of was.myhost.com.
In the labs there is not any static content hosted on the web server. This section is
provided to show how to use the WebSphere Admin Console to configure the web server.
The settings in this section configure the web server so it responds to the
'was.myhost.com' hostname we will use.
__1. Open a web browser and enter http://localhost:9060/ibm/console in the address
bar, the URL of the Admin Console. Remember to continue if you get any certificate
errors.
__2. Login as the 'wasadmin' user.
EV
AL
U
AT
I
__4. Click the link for webserver1 from the list.
LY
__3. Navigate to the Servers Server Types Web Servers section of the admin
console. Notice there is now a configuration for 'webserver1' which the script you ran
added.
__5. Under the Additional Properties click the link for Configuration File. If you get
an error displaying the configuration file let your instructor know as this likely means
there is a problem with your IHS administration password.
__6. Scroll to the very end of the file and add a few blank lines. It may be a little difficult
to scroll as you will have a scrollbar for the whole page in the browser as well as for the
configuration file itself.
56
__7. Add the following text exactly as it appears below at the end of the configuration
file.
<VirtualHost was.myhost.com>
ServerName was.myhost.com
ErrorLog logs/was.myhost.com-error_log
CustomLog logs/was.myhost.com-access_log common
</VirtualHost>
LY
__8. Check that your configuration appears as below and press the OK button.
__9. Go back to the list of web servers by navigating to the Servers Server Types
Web Servers section of the admin console.
EV
AL
U
AT
I
__10. Check the box next to the webserver1 entry and click the Stop button. Make sure
you get a message about the server stopping.
__11. Check the box next to webserver1 and click the Start button. If you have trouble
starting the web server check your configuration file syntax.
__12. Logout of the Admin Console.
57
Part 4 - Update Network Setup

You will now change the networking setup of your Windows machine to send requests for
this new host name back to your own machine. You will use the hosts file on the
machine to perform this mapping. Normally you would have other network components
perform this mapping but the hosts file will simplify the process for the lab. If this step
is not done then requests sent to the host name 'was.myhost.com' would not be redirected
back to you local machine.
__1. Open a File Browser window or use one you already have open.
__2. Navigate to the '/etc' directory.
__3. Find the 'hosts' file in this directory.
__4. Copy the 'hosts' file and rename the copy to something like 'hosts-backup'. This
will ensure you can restore the original if needed.
__5. Double-click on the hosts file and open it with a text editor like gedit.
LY
__6. If you do not already have a line that starts with the IP address 127.0.0.1 add it.
AL
U
AT
I
__7. Add to this line 'was.myhost.com' with spaces between the IP address and each of
the hostnames. Make sure to add any entries AFTER the real hostname as shown below.
The file should be similar to this:
EV
__8. Save the file and close the text editor.

58
__10. Be sure you can ping the new host name. Enter the command below. Be sure you
dont get an unknown host or request timed out error message.
# ping -c 4 was.myhost.com
LY
__11. Close the terminal window.
__12. Open a web browser window.
EV
AL
U
AT
I
__13. Enter the URL http://was.myhost.com in the address bar of the browser and hit
Return. You should see the homepage of the IBM HTTP Server running on your machine.
If you do not see this screen contact your instructor.
__14. Close out any extra terminal windows, web browsers, or File Browser windows
you may have open.
59
Part 5 - Test Plug-in

Now that you have tested the web server you should test that requests sent to the web
server can be forwarded to WebSphere through the Plug-in.
__1. Open a web browser and enter the URL http://localhost:9080/HitCountWeb/ in the
address bar and hit the Return key. You should see the normal output of the HitCount
application.
LY
__2. Test the function of the application to be sure it is working properly.
__3. Enter the URL http://localhost/HitCountWeb into the address bar of the web
browser and hit Return. You should see the same application. If you get any errors check
that your web server is running.
AL
U
AT
I
Note: The difference is that the URL above does not list the 9080 port. Because there is
no port listed it sends the request to the default HTTP port which is port 80. This is the
port the web server is listening on. The fact that you got the normal response proves that
the web server can forward requests for the HitCount application to WebSphere through
the Plug-in.
EV
__4. Test the application again to be sure the same behavior is shown even though the
requests are now being forwarded through the Plug-in.
__5. Enter the URL http://was.myhost.com/HitCountWeb/ into the address bar of the
web browser and hit Return. Again you should see the same HitCount application. This
is because you have configured the web server to respond to the host name
was.myhost.com. It can also forward requests for this host name to WebSphere.
Note: The hit count will be reset because it was associated with your web session that
was linked to the 'localhost' hostname. When you use a new hostname of
was.myhost.com the browser starts a new web session.
__6. Close the web browser you have been using to test.
60
Part 6 - Examine Plug-in Configuration

The configuration of the Plug-in is often a mystery. It is confusing to most people how
the Plug-in makes decisions about what requests to forward. In this section you will see
how you can examine the Plug-in configuration in the WebSphere Admin Console.
__1. Start the Admin Console by opening a Web browser and entering the URL
http://localhost:9060/ibm/console/
__2. Enter a user ID and password of wasadmin and click Log in on the Login screen
of the Console.
__3. In the navigation panel on the left expand the Servers Server Types group and
click the link for Web Servers.
__4. Click the link for the webserver1 web server.
__5. Under the Additional Properties for the web server click the link for Plug-in
properties.
EV
AL
U
AT
I
LY
__6. Press the View button next to the Plug-in configuration file name.
__7. Search through the configuration for the VirtualHostGroup element. This has the
definition of several VirtualHosts. These are the host name and port combinations the
Plug-in can expect to receive requests for. The host name is listed as an asterisk (*) right
now which means the Plug-in will accept requests for any host name the web server
responds to.
61
__8. Search through the configuration for the Server element. Within this element you
will see Transports which have values for the host name and port numbers of the
Application Server. This is how the Plug-in knows what host name and port to use to
forward requests to the Application Server.
LY
Note: The syntax for the server section in the Plug-in configuration can be confusing.
The parent tag in the configuration is ServerCluster. You do not have a cluster of
servers right now. This term is only used so that if you did have a cluster of servers in a
Network Deployment Cell the syntax of the Plug-in configuration would be the same.
Right now your Plug-in is configured as if you have a cluster with only one server in
it.
AL
U
AT
I
__9. Search through the configuration for the UriGroup element. Within this element
you should see an entry for '/HitCountWeb/*'. This is the entry that indicates the Plugin can forward requests to the HitCount application.
EV
__10. Search through the configuration for the Route entry. This links together the three
other parts of the Plug-in configuration you have looked at so far.
Note: The Route is probably the most important part of the configuration. This is
what the Plug-in uses to make decisions about what requests to forward and how. The
Route indicates that if a request comes in for a host name and port listed by the
VirtualHostGroup and for an application listed in the UriGroup that the request should
be forwarded to a server in the ServerCluster.
__11. Click the OK button on the bottom of the Plug-in configuration to close the view of
the configuration file.
62
Part 7 - Configure Virtual Host in WebSphere

Right now the Plug-in is forwarding lots of requests to the HitCount application.
Requests can be submitted using the hostnames localhost or was.myhost.com on one of
several different ports. This is because the current Plug-in configuration uses an asterisk
(*) for the host name of the VirtualHost definitions.
In certain situations you might want to restrict the host name and port combinations that
are mapped to your applications through the Plug-in. To do this you must add a
VirtualHost definition in the WebSphere configuration and configure the host aliases
that it will use. You would then map an application to this new VirtualHost you created
to indicate the application would only be available on the given host and port
combinations. Finally you would update the web server Plug-in configuration so it uses
the new rules for how to forward requests to your applications.
__1. In the WebSphere Admin Console expand the Environment navigation group and
click the link for Virtual hosts.
AL
U
AT
I
LY
__2. Notice that right now there are only two virtual hosts. One is the default_host
that you saw in the Plug-in configuration. The other is an admin_host that is used
only for the Admin Console.
__3. Click the New button above the list of virtual hosts.
EV
__4. Fill in a Name of myhost for the new virtual host and press the Apply button. Make
sure you hit the Apply button as the OK button will not keep you on the same screen.
63
__5. To the right under Additional Properties, click the link for Host Aliases.
__6. Right now there are no host aliases. Click the New button above the empty list of
host aliases.
__7. Change the Host Name to was.myhost.com and leave the default port of 80. Click
the OK button when you have the properties filled in as below.
AT
I
LY
__8. The new host alias now appears in the list. This is now the ONLY host name and
port that applications mapped to this virtual host will recognize.
EV
AL
U
__9. Click on the Save link in the list of messages near the top of the main Console area.
__10. In the navigation area of the Console expand the Applications Application
Types group and click the link for WebSphere enterprise applications.
__11. Click the link for the HitCount application.
64
__12. In the list of Web Module Properties on the right click the link for Virtual hosts.
__13. Use the drop down next to the HitCountWeb Web module to select the myhost
Virtual host from the list. Press the OK button when you have the properties set as
below.
__14. Back on the screen for the HitCount application, click the link for Manage
Modules in the Modules section of properties.
AL
U
AT
I
LY
__15. Notice that the Web module is already mapped to the webserver1 web server AND
the server1 Application Server. This indicates that requests for that application will pass
through the webserver1 web server on the way to server1. This is a critical setting for
configuring the web server Plug-in configuration for webserver1.
EV
Note: This mapping was already done for you even though you did not do it. This was
done by the script that you ran to configure the web server in the WebSphere
configuration. The script automatically mapped all of the applications that were
currently installed to the web server definition that it created for the Plug-in.
In the future, when you install applications that have Web modules, mapping them to a
web server will be an important step.
__16. Click on the Save link in the list of messages near the top of the main Console area.
65
__17. In the navigation panel on the left expand the Servers Server Types group and
click the link for Web Servers.
__18. Check the checkbox next to webserver1 and click the Generate Plug-in button.
AL
U
AT
I
LY
You will see the following message:
__19. Check the checkbox next to webserver1 and click the Propagate Plug-in button.
EV
You will see the following message:
66
__20. Click the link for the webserver1 web server.

__21. Under the Additional Properties for the web server click the link for Plug-in
properties.
__22. Press the View button next to the Plug-in configuration file name.
__23. If you look in the configuration you will notice there are now entries for the
myhost VirtualHostGroup you created and the UriGroup for the HitCountWeb Uri is
now listed separately. There is also a new Route entry that associates the entries relating
to the HitCount application. You may need to scroll around the file as there are many
other entries.
LY
.............
AT
I
__24. When you are done looking at the new Plug-in configuration, click the Logout link
in the Admin Console.
AL
U
Part 8 - Test the New Virtual Host
EV
Now that you have configured a new virtual host with only one host name and port
combination and associated the HitCount application with it you will want to see how this
affects the behavior of the application. No longer will you be able to send requests using
any host name or port besides was.myhost.com on port 80.
__2. Use the 'cd' command to change to the <WAS_ROOT>/profiles/AppSrv01/bin
directory. Be sure to substitute the value of <WAS_ROOT> from the Directory Paths
page at the beginning of the lab instructions.
67
__3. Issue the command:

# ./stopServer.sh server1 -username wasadmin -password wasadmin
__4. Issue the command to restart the server:

# ./startServer.sh server1
Note: You need to restart the Application Server because some of the configuration
changes you just made are only read when the server starts.
__5. Open a web browser and enter the URL http://was.myhost.com/HitCountWeb/
into the address bar of the web browser and hit Return. You will see the normal output of
the HitCount application. This is expected since the application is still registered to
respond to this host name and port combination.
LY
__6. Test the function of the application to verify it is working correctly.
__7. Notice the URL that appears in the browser for the page that displays the messages.
It is:
EV
AL
U
AT
I
http://was.myhost.com/HitCountWeb/HitCountServlet
68
__8. Enter the following URLs into the web browser that have worked before:
http://localhost/HitCountWeb
http://localhost:9080/HitCountWeb
http://was.myhost.com:9080/HitCountWeb
LY
Notice that all of these URLs now generate various page cannot be found 404 errors.
This is because these host name and port combinations are not listed as host aliases of the
virtual host that the HitCount application is mapped to. This is true even for URLs that
use the direct WebSphere port of 9080 and do not try to go through the web server.
AL
U
AT
I
Note: Using the 'Virtual Host' configuration in WebSphere is one way to control exactly
how clients can access an application. If web applications are configured to be available
through web servers and/or proxy servers for security reasons this configuration will
prevent users from bypassing that route to the application, even for "internal" users.
EV
__9. Close the web browser you were using for testing.
Part 9 - Investigate Application Settings (Optional)

So far in this lab you have seen how to change the host name and port an application will
respond to using a Virtual Host. In this section you will see where the other parts of the
URL are specified. You will use the Admin Console to display the Deployment
Descriptors that contain this information. Remember the URL you used to access the
application was:
__1. Open a web browser and enter http://localhost:9060/ibm/console in the address
bar, the URL of the Admin Console.
__2. Login as the 'wasadmin' user.
69
__3. In the navigation area of the Console expand the Applications Application
Types group and click the link for WebSphere enterprise applications.
__4. Click the link for the HitCount application.
__5. Under the Detail Properties section, click the link for View Deployment Descriptor.
LY
__6. Make sure all the entries are expanded and locate the 'context-root' element. This
forms the first part of the URL that comes after the host name and port. Notice this also
mentions a 'HitCountWeb.war' module for the application.
EV
AL
U
AT
I
__7. In the breadcrumb trail at the top of the page click the link for the HitCount
application. This will take you back to the properties of the application configuration.
__8. At the top of the page of properties for the HitCount application click the link for
Manage Modules under the Modules section of properties.
70
__9. In the list of modules click the link for the HitCountWeb module.
__10. On the right side, click the link for View Deployment Descriptor.
AT
I
LY
__11. Make sure all the entries are expanded and locate the 'servlet-mapping' element.
This links the servlet in the application to the URL suffix '/HitCountServlet'.
__12. Logout of the Admin Console and close the web browser.
EV
AL
U
__13. Stop the Application Server using the './stopServer.sh server1' command in a
command prompt in the <WAS_ROOT>/profiles/AppSrv01/bin directory. Remember
that you can use the command with credentials as './stopServer.sh server1 -user
wasadmin -password wasadmin'.
Note: You now know how to read the URLs used to access application components.
These are of the form:
<protocol>://<hostname>:<port>/<context root>/<URL mapping>
Applying this to the HitCountServlet URL:
<protocol> - HTTP
<hostname> - was.myhost.com
<port> - 80, this is the default HTTP port if none is listed
<context root> - HitCountWeb
<URL mapping> - /HitCountServlet
71
Part 10 - Review
This lab showed several different aspects of using web servers with WebSphere. The first
sections involved installing and configuring the IBM HTTP Server. This included
configuring the web server to respond to a virtual host which was different than the
actual host name of your machine. You also had to modify the network setup of your
machine to be sure that the requests for this host name would be routed back to your
machine and not sent out to the network.
The next sections tested the web server Plug-in. Because most of the initial setup of the
Plug-in was done by the plug-in customization and the script you ran there was not much
to do immediately after the script to get it to work. You also became familiar with how to
read the Plug-in configuration and discovered how the Plug-in will forward requests for
applications.
LY
In the last set of sections you reconfigured the HitCount application so it would only
respond to requests sent to the was.myhost.com host name on port 80. This may be
required when you need to have more control over how applications respond to requests.
The first step in this was to create a new virtual host and host alias that only included the
desired host name and port. You then changed the configuration of the HitCount
application to use this new virtual host. After restarting the servers you saw how these
settings restrict the host name and ports that you can use to submit requests.
EV
AL
U
AT
I
You also saw how to obtain some basic information about the internal settings of an
application using the Admin Console to view the deployment descriptors.
72

Wa2097 Rel 1 0 Eval Labguide

Uploaded by

Copyright:

Available Formats

Wa2097 Rel 1 0 Eval Labguide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wa2097 Rel 1 0 Eval Labguide

Uploaded by

Copyright:

Available Formats

Student Labs

Web Age Solutions Inc.

WA2097 WebSphere Application

Copyright 2013 Web Age Solutions Inc.

Directory Paths Used in Labs..............................................................................................3

Copyright 2013 Web Age Solutions Inc.

Directory Paths Used in Labs

Lab 1 - WebSphere 8.5 Installation

Lab 4 - Solving Problems

System.out File Name (including path):

Lab 7 & Alternate Lab 1 - JMS Messaging

JNDI Name for Queue:

JNDI Name for Connection Factory:

JNDI Name of Activation Specification:

Lab 15 Create Deployment Manager Profile

Node Name of Deployment Manager Profile:

Copyright 2013 Web Age Solutions Inc.

Lab 1 - WebSphere 8.5 Installation

At the end of this lab you will be able to:

1. Install WebSphere Application Server 8.5

2. Explore the major WebSphere directories

3. Start the Application Server

5. Stop the Application Server

4. Test the WebSphere Installation

Part 1 - Install the Installation Manager

Copyright 2013 Web Age Solutions Inc.

__3. Use the 'cd' command to navigate to the <LABFILES_DIR>/InstallWAS directory

__6. Browse to /opt/IBM folder.

Copyright 2013 Web Age Solutions Inc.

__10. Navigate to the <WAS_SOFTWARE_DIR>/InstallationManager/tools directory

__12. In a terminal window, use the 'cd' command to navigate to the

Copyright 2013 Web Age Solutions Inc.

Copyright 2013 Web Age Solutions Inc.

Part 2 - Record Response File

__5. Paste the copied file into the <IM_ROOT> directory.

Copyright 2013 Web Age Solutions Inc.

Note: The directory used after -skipInstall (DATA_LOCATION above) should be a

Copyright 2013 Web Age Solutions Inc.

__12. Click the Browse button and navigate to the <WAS_SOFTWARE_DIR>/Main

Copyright 2013 Web Age Solutions Inc.

__19. Change the value of the shared resources directory to '/opt/IBM/IMShared' as

Copyright 2013 Web Age Solutions Inc.

__21. Change the value of the WebSphere installation directory to

Copyright 2013 Web Age Solutions Inc.

Copyright 2013 Web Age Solutions Inc.

__28. In the Installation Manager select 'File Exit'.

Part 3 - Install WebSphere with Response File

__2. Navigate to the <LABFILES_DIR>/InstallWAS directory substituting the value of

Copyright 2013 Web Age Solutions Inc.

__5. Paste the copied file into the <IM_ROOT> directory.

Copyright 2013 Web Age Solutions Inc.

Copyright 2013 Web Age Solutions Inc.

Part 4 - Create a WebSphere Profile

__4. Navigate to the <WAS_ROOT>/bin directory substituting the value of the

__5. Paste the copied file into the <WAS_ROOT>/bin directory.

Copyright 2013 Web Age Solutions Inc.

Copyright 2013 Web Age Solutions Inc.

__11. Open a File Browser window and navigate to the

__14. Close the text file showing the profile information.

Copyright 2013 Web Age Solutions Inc.