Introduction to IBM WebSphere Portal

Server and Lotus Web Content Mgmt

Standard Edition
In This Lab We Will
In this lab we will launch IBM WebSphere Portal Server and Lotus Web Content Mgmt Standard Edition
as a virtual computer instance in the Amazon Web Services (AWS) cloud, and then save a copy of the
image as a private version with our customizations.

You will launch the lab using a courtesy account, if you do not already have one. If you prefer to sign up
for your own account (or if you already have one) you will be assigned a coupon that will ensure that
your lab costs net to zero, as long as you stop the server and delete any disk drives when you finish.
Because the coupon is valued at $50, there could be a financial advantage if you use your own account.

Specific lab steps are as follows:

1. Sign up for an AWS account, S3 and EC2, if applicable

2. Launch an EC2 instance using the AWS console

3. Configure WebSphere Portal and modify the home page

4. There are some extra credit steps at the end

Why Should I Consider Running IBM Software in the Cloud?

IBM and AWS have worked together to enable use of key IBM products in the Cloud.

The Benefits of Amazon Web Services

The advantages of this new operational environment are many; including an innovative price model, a
durable and resilient execution environment, and an elastic infrastructure.

Prices
There are two ways in which you can run IBM software in the Amazon Cloud. One way is BYOL, or
bring your own license. In this model you are able to use IBM PVUs to execute IBM software in
Amazons environment.

The second approach is a pay as you go model, and is subdivided into development vs. production
Amazon Machine Images (AMIs), which are the virtual computer images that you can launch. You pay
only for what you use, and there is never a sign-up fee or monthly minimum. Development versions of
IBM products are offered at no additional charge beyond what Amazon charges for the underlying
infrastructure. Production images are competitively priced.

AWS is divided into Regions and Availability Zones. Regions are self explanatory for example US East or
EU West. Availability zones are similar to physical data centers, and separate facilities in a common
metro area. These zones are far enough apart to be completely independent of each other; yet close
enough together to offer very low latency between zones. There is no extra cost for this sort of
resiliency.

The Benefit of Running IBM in the AWS Environment

You can launch one, or one thousand, servers on an as-needed basis. Because the environment is
virtualized, standardization is built in with the result that testing is easy and scalable. Amazon even
offers a set of services that will load balance your environment, based on rules that you set up.

In this lab we will show you how to customize an AMI and then create a private copy for future use. We
expect that almost every developer will want to do this.

About This AMI

IBM WebSphere Portal Server V6.1 is an enterprise portal solution with the complete portal services
necessary to deliver a single point of personalized interaction with applications, content, business
processes, and people. The unified user experience can help you improve overall productivity and
customer satisfaction.

IBM Lotus Web Content Management, V6.1 enables companies to rapidly build next generation Web
sites based on Web 2.0 technologies with new enhancements that can be used throughout the entire
content lifecycle. Improvements in authoring, management, and delivery enable companies to interact
with their customers, partners, and employees in new ways.
The WebSphere Portal Server & Lotus Web Content Management Standard Edition Developer AMI
provides Amazon EC2 users with a fully configurable portal server and web content management
solution.

Out of the box a number of key capabilities are provided as part of start up:

Sample portal sites, including Intranet and internet

A New Site Wizard to instantiate new sites as virtual portals from templates

Theme Customizer to easily customize the look and feel of the portals/sites to meet your needs

Integration with a local instance of IBM DB2

Root and default user password setup

Localization of each IBM product

Amazon Web Services configuration screens

EBS storage configuration screens

Instances created based on this AMI are configured for root-level access over secure shell (SSH) using
the keypair you specify at instance creation.

Sign up for an AWS account, S3 and EC2

This step is required only if you are not already signed up for Amazon S3 and Amazon EC2.

1. Go to the AWS home page (http://aws.amazon.com).

2. Click the Sign Up Now button. If you dont already have an Amazon account, you will be
prompted to create one.

3. Follow the on-screen instructions

4. Go to the S3 home page (aws.amazon.com/s3) and click the Sign up for This Service button.

5. Go to the EC2 home page (aws.amazon.com/ec2) and click the Sign up for This Service button.

6. Apply your AWS training promotional code at the Promotional Code Redemption Page at
https://aws-portal.amazon.com/gp/aws/developer/account/index.html?
ie=UTF8&action=credits.

7. Verify that the credit has been applied to your account by visiting the Account Activity page.
Launch an EC2 Instance Using the AWS Console
There are a number of ways to manage the Amazon EC2 environment, however in this lab we will use
just one: the AWS Console. This console is a Web page hosted by Amazon Web Services, and is the only
instance where you are able to use your Amazon email address and password to log in directly. Thats
because the page is hosted by Amazon any other method requires authentication using a public key
and secret key, or certificate-based files.

In order to use this AMI, or Amazon Machine Image, you must first purchase it. In fact IBM
makes the AMI available at no cost beyond what you pay for the AWS infrastructure; however
you still need to agree to their terms of use thus the purchase process.

This process starts at http://developer.amazonwebservices.com/connect/entry.jspa?

externalID=2048&categoryID=229 although for this lab we already enrolled your lab account

Navigate to http://aws.amazon.com/console (the url should be bookmarked in your lab

machines browser).

Click on the button that says Sign in to the AWS Console, as indicated in the screenshot below.
Note that email addresses serve as a username in this management console. Use the default
drop-down selection that says EC2.
 Log in using either the email address assigned to you, or your own account email address, as
appropriate.
 Confirm that you are operating in the US East region. The console allows you to select from
either the US or Europe. As you can tell from the names, additional regions will be available in
the future.

This initial dashboard provides an overview of the AWS EC2 environment within the region
selected. For instance, the screen shot above shows that there is one running instance
(computer), and that there is one EBS volume (network-mountable disk drive), etc. If you click
on the Launch Instances button near the center of the screen, a wizard will pop up that lets
you choose from a short list of popular Amazon Machine Images (AMIs) that represent popular
operating system and virtual machine choices. We will not use the wizard in this lab, because we
are launching a specific IBM AMI, which is not part of the list in the wizard.
 Click on the AMIs link near the left-hand side of the screen.
 The AMI section of the Console shows a list of all available AMIs, grouped into pages of 50
choices per screen. In the screenshot below, the right-hand circle shows that we are viewing a
list of the first 50 of 2783 different choices! In other words, there is a wide selection of choices
in the AWS environment. The left-hand circle highlights the tools that help you narrow the list
down to just the AMIs that are relevant to you. You are able to select by platform, operating
system, etc. You can also use the text box to search for specific AMI names. That is what were
going to do

In the text box next to the All Platforms drop-down list, type in ami-ee779087, which is the
developer version of WebSphere Portal Server with Lotus Web Content Management. Note that
if you paste the name in from this document, trailing spaces are significant. Youll need to
remove the space in order for the search to return results.
 Select the AMI by highlighting it, then click on the launch button above the selected line.

A launch wizard will pop up. There are a total of four parameters that you need to specify before
actually launching an instance of this server. Well address them slightly out of order in this lab
exercise, because this order makes the most sense in terms of what were doing today. In this
step we are going to create a key pair, which will serve as root password for this server.

Click on the create button circled in the screenshot below.

 Enter a name for the key. Use a name that makes sense to you there is no reason that you
need to copy the example below. Spaces in the name are fine.

Click on Create and Download your Key Pair, then save the file on your local computer. Make
certain that you know which directory you stored it in! And it is essential that you download this
file in order to complete the lab. There is no way to download it later, so if a pop-up blocker
created some sort of issue then you will need to create another key pair after you resolve the
browser issue on your local computer.

Click continue once the file is downloaded.

 Next well create a security group for this server. You could use the default security group;
however we will use a custom one in order to separate this server from others that might be
running under the same EC2 account.

Security groups are essentially firewall settings. Each inbound packet is routed thru one of these
groups, where it is inspected to determine what the rules say. More on the rules in a moment;
for now, just click create.
 Pick a name for your group. The name is not important; however it must be a name that is not
already in use. The wizards suggested name (default) cant be used for this reason.

The wizard is smart enough to know that this is a Linux AMI, so it will automatically add port 22
as an allowed port in order that you will be able to log into the server via SSH. Later, we will add
access via port 80 for HTTP. You need to explicitly allow each protocol and port required for
your server, because these security groups are a nothing allowed by default approach to
access.

Click continue.
 Back at the main launch wizard screen, we are ready to actually launch an instance of the server.

Enter 1 as the number of servers to launch. If you wanted to launch multiple instances at once,
you can accomplish that by entering a different number here. Note that by default you are
allowed to have up to 20 instances running at a time. If you need access to more instances than
20, there is a self-serve form on aws.amazon.com where you can request a higher limit at
http://aws.amazon.com/contact-us/ec2-request/.

Amazon Web Services offers a variety of virtual machine configurations. The wizard only displays
the choices appropriate to the AMI that you selected, which in this case is the standard (small)
instance or a high-horsepower variation of the standard virtual computer. We will use the
standard size (m1.small). This computer is a virtual server equivalent to one with 1.7 GB of
memory, 1 virtual core, 160 GB of instance storage, on a 32-bit platform.

Make certain that the key pair displays the key pair that you created and downloaded. You will
not be able to log in to the server if this setting is incorrect, and you wont be able to change this
setting unless you re-launch a separate instance of the AMI.

Select the security group that you just created. It is possible to assign a given server to multiple
security groups, and the wizard will suggest both your group and the default group. We are only
using the custom group because one best practice is that you should never use the default
security group. The philosophy behind this best practice is that if you dont open any ports in the
default group, then you wont inadvertently allow access to servers that auto-assigned
themselves to the default group. And not assigning the group at all is a belt-and-suspenders
approach that avoids future security accidents, caused by someone opening ports in the
default group.

Click Launch
 Close the wizard

Click on the link that says instances. You will see a list of instances most likely only the one
that you just launched. Initially the instance will be in pending state. The screen shot below
shows an additional (unrelated) instance, that is already up and running.

This screen doesnt always update itself as instances change from one state to another. You can
refresh this Web page manually in order to verify that what you see is indeed the most current
view of your Amazon EC2 environment.
 While youre waiting for the instance to launch, you can complete some other tasks. First, the
security group needs to authorize access via port 80.

Click on the Security Groups link, then select the group that you created earlier.

The bottom of the screen will show details for this group. The wizard already authorized access
to port 22 for SSH; and you can see that its possible to restrict access further to a single IP
address or a range of IP addresses. 0.0.0.0/0 means all computers on the Internet, which is
probably not what you want in production. Well leave this setting alone for now though,
because this is just a lab exercise.
 Click on the drop-down list, choose HTTP, then click Save.

SSH access is used to log in to your running instance. Many operating systems have SSH built in
to the operating system; however Windows does not. We are going to use a client known as
PuTTY, along with a utility known as PuttyGen. You can ignore this step when using a non-
Windows computer; however you will need to determine how to use the key pair in whatever

The first step is to convert the key pair that you downloaded into a format that PuTTY
understands. Most SSH clients can use the native key pair format, so this step only applies if
youre using PuTTY.

Find PuttyGen on the Windows Desktop. Click on Conversions and then Import Key. Locate
the key pair file that you downloaded, which will end in .pem. Then click OK to import the file.
 Then click on File -> Save Private Key to save the PuTTY version of this file. Use the same name
with a .ppk file extension (e.g. LabKey.ppk). There is no technical reason that you need to use
the same file name; however its easier to remember whats going on when you follow this
convention.

The program will ask if you really want to save the key without a passphrase. There is no
compelling reason to password protect this file for this lab, so ignore the warning.

Exit PuttyGen once youve saved the file.

Launch PuTTY from the Desktop. Well set up the program for access to the AMI using the key
pair.

Expand the SSH node in the configuration tree and then browse for the key that you just
generated.
 Make certain that the preferred SSH protocol version is set to 2. Your key pair will not be
properly recognized if the preferred version is 1.

Refresh the console, and by now the instance that you launched is probably running.

Highlight the instance, then copy the public DNS name as shown in the screenshot. The address
assigned to your instance will be different than the screen shot, of course. And dont worry
about that long name you can change the name via your own DNS server later.
 Back in PuTTY, click on Session to display the text box where you will enter the DNS name for
this instance. Then paste in that DNS name and click Open.
 As you connect, there will be a box warning you about an unknown fingerprint, which is
simply warning you that this keypair and that instance have never met each other before. Click
on yes to continue, then log in as root.
Configure, Start, and Access WebSphere Portal
Once youve logged in to your instance, there are a series of screens that you need to walk thru in order
to configure the instance. Some of these screens are related to licensing; while others are related to
specifying where you want your database located. The IBM WebSphere Portal and Lotus Web Content
Management Amazon Machine Image (AMI) Get Started Guide contains details about the process. You
can download the guide, and also learn much more about IBM and Amazons combined offering at
http://www.ibm.com/developerworks/downloads/ls/wps-wcmse/ec2.html.

In this lab we are going to create the database on the drive intrinsically associated with the instance you
just launched. That drive persists for the life of the instance, so one best practice says that you should
create an Elastic Block Storage (EBS) drive, then mount it to the running instance. EBS drives are
persistent past the lifespan of an instance, so they are the logical choice for a database that needs to be
durable. See the extra credit section for instructions on how to work with EBS volumes.

After establishing an SSH session with your new instance, following the procedure in the previous
section, proceed with the startup screens as follows:

On the first screen, select the default language you wish to use for the instance. The default
(English) is suggested. Use the Tab key to move between input options until Accept is highlighted,
then hit Enter to continue to the next screen.

On the next two panels, hit Enter to accept the Novel SuSE license agreement and continue to
the next panel.
 On the next three panels, enter the passwords for the root and virtuser accounts. Virtuser is a
non-root user in UNIX that also serves as the administrative user for WebSphere Application Server
and WebSphere Portal. The password you set here for virtuser will be the same password you use
when accessing WebSphere Portal and WebSphere Application Server consoles. Hit Enter to
continue.
 On the next set of panels, you are asked to enter AWS credential information and EBS volume
information for creating and connecting an EBS volume to this instance, establishing persistent
storage beyond the life of this instance. As indicated at the beginning of this section, you will be
using local storage for the lab, so we will bypass these options. Extra Credit exercises at the end of
this lab cover how to use EBS volumes with your instances. So, on the first panel, select Skip AWS
Credential Setup and hit Next to continue, then select Yes in the resulting confirmation dialog,
then hit Enter finally to leave the AWS credential setup screens.
 On the next 2 screens, you are specifying to use internal, volatile storage for this instance. Select
Next to continue, then finally End to leave the EBS setup panels.
 On the following screen, an automated series of steps are configuring the instance to use local
storage to contain the WebSphere Portal configuration and database data instead of an EBS volume.
This process will take several minutes, and once complete, the next panel will appear which will
provide a progress indicator following the reconfiguration of WebSphere Application Server and
WebSphere Portal based on the new EC2 network configuration information. After several minutes,
once the progress indicator goes to 100%, hit Next to continue, then hit Enter to get past the
configuration result output screen.
 Lastly, the HTTP Server plugin configuration is regenerated before returning the UNIX prompt.
 Now that the instance has been fully initialized and configured, it is time to start WebSphere
Portal and the HTTP Server. First, navigate to the /opt/IBM/WebSphere/wp_profile/bin directory
and start WebSphere Portal using the startServer.sh script as follows:

./startServer.sh WebSphere_Portal
 Then, change to the /opt/IBM/HTTPServer/bin directory and start the HTTP Server using the
apachectl command as follows:

./apachectl start
 Now that everything is started, you can access WebSphere Portal from the browser. Open a
Firefox browser instance and navigate to portal using the following URL:

http://<server>/wps/portal

Where <server> is the public DNS name of your new instance, taken from the AWS Console, such as
ec2-75-101-212-192.compute-1.amazonaws.com from the previous section. On the Portal login
screen, enter the virtuser user ID and password and click Log in to go to the Portal home page.
WebSphere Portal is now ready for you to use. Remember that anything you do with this instance of
WebSphere Portal will last as long as this instance is kept active. If you terminate this instance, all
customizations of WebSphere Portal will be lost.

Some of the things you may consider doing with this instance include:

Create additional users besides virtuser (necessary for use with some features like the New Site
Wizard), under Administration -> Access -> Users and Groups.

Use the New Site Wizard to generate new micro sites based on a site template and site style of
your choosing (requires using a user ID besides virtuser), under Home -> New Site Wizard.

Play with the sample Internet and Intranet content management micro sites under
http://<server>/wps/portal/internet and http://<server>/wps/portal/intranet, respectively. You
can use the Web Content Management (WCM) inline edit features to customize the content in
the context of the portal page itself.

Use the Theme Customizer to customize the look and feel of your portal pages, available under
Administration -> Portal User Interface -> Theme Customizer, or from the pencil icon on portal
pages created by the New Site Wizard.
Create an Elastic Block Storage Volume
The core lab instructions create a database on the drive that is intrinsically associated with the instance
you just launched. That drive persists for the life of the instance, so one best practice says that you
should create an Elastic Block Storage (EBS) drive, then mount it to the running instance. EBS drives are
persistent past the lifespan of an instance, so they are the logical choice for a database that needs to be
durable.

The Getting Started Guide explains how to use EBS from your instance.

Extra Credit Steps

1. Create an EBS volume during instance setup, customize portal, then terminate the instance.
Then create a new instance to reuse the old EBS volume and see how you get your customized
portal back.

Creating an EBS volume will require that you have available an X.509 security certificate
associated with your Amazon account. You can download them from you AWS account on the
AWS Site. The certificate includes a private and public key file. Once downloaded to your local
system, they must then be uploaded to your new machine instance in EC2 before the AWS
account information panels are filled during instance creation.

The Core FTP application has been preloaded on your Windows desktop. Before connecting,
ensure that the SSH/SFTP checkbox is checked. It also must be configured with the same private
keypair used for Putty access to your instances, under the Advanced Site Settings -> SSH
configuration panel, as follows:
 Please note that you should NOT try to access your instance using Core FTP until the
passwords for the root and virtuser users have been set, as premature access before this
occurs can cause the instance to terminate.

2. Create a snapshot of an EBS volume from a customized portal, then create a new EBS volume
from the snapshot that a new instance connects to, then observe how you get an identical
portal using this process.

You can manage EBS volumes and snapshots within the AWS Console.

3. Start 2 instances, and reconfigure one to use the DB2 instance on the other, and have the HTTP
Server on the other point to the Portal instance on the original.

Note that DB2 is always running on an instance, so you dont need to do anything special to
prepare a DB2 instance to be usable from another instance. In the same instance you plan to run
DB2, you should also configure the HTTP Server to point to WebSphere Portal on the other
instance. To do that, all you need to do is copy the plugin configuration from the Portal instance
to the same location on the DB2/HTTP Server instance. The plugin-cfg.xml file can be found
under /opt/IBM/HTTPServer/Plugins/config/webserver1 on the instance where WebSphere
Portal will be running. After copying this file to the DB2/HTTP Server instance, in the same
location, restart the HTTP Server using the apachectl command as follows:

cd /opt/IBM/HTTPServer/bin
 ./apachectl stop
./apachectl start
Reconfiguring WebSphere Portal to use a different database is simply a matter of reconfiguring
the application server datasources to point to a different, remote Database than the local
instance. You can access the WebSphere Admin Console at http://<server>:10027/ibm/console,
then login using the virtuser account. Then go to Resources -> JDBC -> Datasources. Click on
each of the listed datasources, then scroll down in the resulting dialogs and change the Server
name value to be the internal host name of the other instance where you will have DB2 running.
You can get the internal host name from the AWS Console for the instance, which will start with
domU

Click OK after each host name change, then at the end, click the Save link at the top to commit
changes to the configuration.
Now WebSphere Portal must be restarted for this change to take effect. After it has been
restarted, you should be able to access WebSphere Portal from the DB2/HTTP Server instance
using the http://<DB2HTTPserver>/wps/portal.