Installing WebSphere

We can’t install Connections until both WebSphere and the DB2 (or Oracle or SQL) databases are in place so let’s start with WebSphere.  On previous posts we looked at installing Installation Manager (IM) and setting up a software repository to point to the WebSphere installers

skitch.21

My first check is to decide what version and fixpack I need and I do that by checking the System Requirements. These can change any time so I make a point to check them just before doing an install.   According to the current requirements Connections 5.5 needs a minimum of WebSphere Application Server Network Deployment 8.5.5 Fixpack 6. Since the requirement is a minimum I could install the most recent Fixpack 8 but for my purposes I’m sticking with Fixpack 6 today.

skitch.20

Even though at this point I’m not installing IHS I can see on the system requirements that it only supports 8.5.5 fixpack 6 of IHS.  This is something I need to remember later.

skitch23

When  launching IM and clicking “Install” I am presented with serveral products with their latest versions and options.  I have to click the checkbox “Show All Versions” to choose an earlier fixpack such as Fixpack 6

skitch.19

There are now hundreds of products and versions to choose from so to make it easier I type “network deployment” in the search bar at the top to filter the product choices (and so I don’t accidentally choose the wrong one). I then select 8.5.5.6 as the version I want to install. I haven’t downloaded 8.5.5.6, only 8.5.5 so I’m relying on IM to get the fixpack from the Passport Advantage site.

skitch.18

There are already several fixes available for 8.5.5.6 but, having checked the System Requirements to ensure there are no specifics fixes I need, I let IM choose the recommended ones only.

skitch.17

I now identify two locations, The first is the location for the shared resources directory used by IM.  This is the location for IM to store the installers, fixes and rollback files, not the location of the WebSphere program itself.

skitch.16

Now I can tell IM where to install WebSphere.  The default “WebSphere” directory will always be /IBM/WebSphere/AppServer and I would only change this if I was installing multiple WebSphere versions on the same machine (unlikely).  On Linux this defaults to /opt/IBM/WebSphere/AppServer and on Windows I try to put it on a separate drive partition from the OS such as D:\IBM\WebSphere\AppServer.  This location is your “WebSphere program directory” that is referred to in documentation.

skitch.15

These are the standard features I install for Connections.  At this point the total install size should be about 2.5GB across both directories.

skitch.14

Our confirmation screen just before the install starts shows what products will be installed into which locations.  Read the target location details at the top of this screen to confirm you have entered them correctly.

skitch.13

Our WebSphere install is now complete (love that big green tick) but now I need to create profiles to set up the servers.  Selecting OK here will launch the profile management GUI tool but this can also be launched later off the GUI menu or you can create profiles by using the /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh command

skitch.12

Since this is the first server in my deployment I need to create a new cell which will include both a deployment manager and an application server.  I often like to create the deployment manager standalone on its own machine if I’m building a HA cluster but for our purposes in Connections101 I’m just locating both the deployment manager and my first application server together.  These are the first servers on “bogart” as shown below.  If I were creating an additional Application Sever on “marlowe” then I would be creating an Application Server profile only at this point.

WebSphereExamples

 

skitch.11

Often during profile creation I would just choose the “Typical” option which is a far simpler series of choices with some default settings.  I’m choosing Advanced profile creation here to show you all the settings available to you.  The difference between “Typical” and “Advanced” is purely the ability to custom set options like ports, certificates and passwords – all of which can also be changed later after the profile already exists.

skitch.10

I always want to deploy the administrative console if I’m deploying a new cell because that’s how I’m going to manage all the servers.  If I add an existing Application server into an existing cell by federating it, its administrative console will be removed so it can be managed only by the deployment manager.

I often choose not to deploy the default applications for security reasons because it just gives me more things to have to lock down.  It can be useful for WAS troubleshooting but I rarely use it.

skitch.9

The first deployment manager on a node is usually put in a profile Dmgr01, similarly the first application server is put in the profile AppSrv01.  You can change both of these to something more meaningful if you want.  I never usually do. One thing to note in WebSphere world is to stay away from anything that could be a special character for path names or passwords.  As I mentioned on the previous post, all WAS configuration is stored in XML files and often encrypted so decrypting those special characters can fail and cause WebSphere itself to stop working.

Specific special characters to avoid for anything WebSphere related include

\/*,;:=+?{}[]<>_%^&$'”^()

but I like to avoid anything that could be problematic including accented characters.  Longer passwords can be just as effective.

skitch.8

The hostname for the server is picked up from the server’s local settings or host file. You need to make sure it’s a fully qualified name and not just “bogart”.  It also needs to be fully resolvable with an IPV4 address from itself and any other server.  The default deployment manager and application node names will be “servername”CellManager01 and “servername”Node01.  This is important because the servers will be installed with these names and a lot of nested directories will use the names.  IBM recommend your server name is no longer than 8 characters for this reason (avoiding creating very very long filepaths) but if your servername is long you can change the node names here to something shorter..

The cell name and node names cannot be changed post install and will be used to reference the servers internally.  It will always be possible to add another resolvable fully qualified hostname like “hammett.connecitons101.info” as an alias later but you can never fully remove these names.

skitch.6

When WebSphere is installed new SSL certificates are created using an IBM internal Certificate Authority and the servers’ hostnames and roles.  These certificates are usually replaced by me post install with valid SSL certificates from a public or internal provider.  If however you have a wildcard certificate for your organisation already you could add it during the install and avoid having to replace the internal IBM certificate later.  You would still need to add the trusted root though and I’m a control freak so I like to let IBM create its certificates then manually go in and replace them later.

skitch.5

The default certificates that are created (assuming you didn’t choose to replace them on the previous screen) will have keystore passwords of WebAS.  This is well known as IBM’s  default keystore password and for that reason WebSphere will see it as a security issue if you don’t change the password for keystores on a running server.

Again I prefer to let it install and then change it later but you can change it here during the install process.

skitch.4

There are three pages of ports that WebSphere will use for different services.  Unless there’s a specific reason you can’t use one of the default ports I suggest leaving these as they are (in a “Typical” install you never see these screens).  If you must change them I would suggest only incrementing them by “1” until you get to a port number you are happy with.

skitch.3

On Linux and Windows you are presented with the option to add the Deployment Manager to run as a service when the server starts.  You don’t get that option for either the nodeagent or any of the application servers which you will have to add manually after all the install work is complete.

skitch.2

Finally I get the option to create an IHS server definition.  I will need to do this at some point since we are going to put IHS in front of our Connections servers but I haven’t installed IHS yet and so I’m going to leave this for later.

That’s our WebSphere install complete.  It should take anywhere from 15 mins to an hour depending on your disk write speed.

skitch.1

Once installed, if you have a GUI, you will see IBM Websphere on the Application menu. From here you can find the profiles that were created as well as create new ones and start or stop individual servers.

skitch

The above screenshot shows me checking the install completed successfully.

First I do an “ls” to see there are both profiles there.  The system shows me Dmgr01 (the deployment manager profile) and AppSrv01 (the application server profile).  That’s good.

Now I navigate to /opt/IBM/WebSphere/AppServer/Dmgr01/bin and run ./startManager.sh (note case sensitivity).  This should start the deployment manager from within its own profile.

Once it has started I want to check it’s listening and I know the deployment manager listens on port 9043 for the Integrated Solutions Console so I type

netstat -tulvn |grep :9043 to find if that service is listening.

We now have WebSphere installed.  If you are setting up multiple servers on different boxes you would now need to go and repeat the install but this time choosing to create only an Application Server profile on each of those boxes.  Remember to keep your WAS version on every server in your cell aligned at 8.5.5.6.

A WebSphere Primer..

Before you start installing WebSphere you should really understand some core concepts behind its architecture and options. This is going to make it easier to decide where and how to build servers.

Connections uses WebSphere 8.5.5 Network Deployment.  When you go to install your Connections applications you’re going to need at least one instance of WAS to install onto, however a single WAS install may be running multiple independent servers each running different applications. Our Connections environment could therefore be a single host machine with multiple WebSphere servers or multiple host machines each with single WebSphere servers.

Every WAS server must be installed into what is called a Node  and similarly each Node must exist inside what is called a Cell. For Connections101 I am building two “nodes” on two physical hosts with each running multiple WAS instances hosting different applications.

Each Cell has one process called a Deployment Manager whose job it is to manage the configuration settings and changes for all servers in its cell.

Each server then also has another parent process called the Node Agent. Its job is to talk to the Deployment Manager and receive the latest sync information (XML files) for the server it is managing. It’s also responsible for starting and stopping the server.  You cannot start any WAS server unless its corresponding node agent is also running.  You can’t stop any WAS server unless its corresponding node agent is also running.

Here’s an example diagram of how the architecture for Connections101 might be designed. In this design I have built a deployment manager and two separate nodes which are full clusters of each other.

WebSphereExamples

In WebSphere terms only individual servers need to be clustered, not entire nodes so I could easily just cluster the busiest components in my environment such as Cluster2 which contains search , homepage and profiles.  This is why it’s important to think about WebSphere design as well as the locations of the applications and which ones you may want to cluster, before starting the install.

The Deployment Manager directory holds XML files for every server.  It copies those files into the individual server directories when you Sync the servers.   You do all your configuration by logging into the administrative interface for the deployment manager (the Integrated Solutiions Console) and from there any changes push out to the managed servers.

Based on this there are important things to bear in mind

  1. Each server will have only one node agent
  2. Each node agent can manage multiple servers
  3. So from this we know that every single WAS cell will have, at minimum, one deployment manager, one node agent and the application server itself.
  4. Changes made to server configuration on the deployment manager will need to sync down to the nodes before the server itself will pick them up
  5. Syncing basically results in copies of the XML files for a server being sent from the Deployment Manager’s directory to the Server’s directory
  6. This means there will be at least 2 copies of every configuration file for a server, one owned by the Deployment Manager and one by the Server
  7. If you try and change a server setting in the Deployment Manager without syncing, the server won’t take the change
  8. If you try and change a server setting directly on the server without updating the Deployment Manager, it will be overwritten
  9. If you install the deployment manager and server on the same machine, it still has to sync to push out changes.  From a file system perspective, there are multiple copies of the same files.  If the servers are on different boxes the files will be too,  WAS is designed to work as if all servers are physically different and isolated from each other regardless of hardware infrastructure.  Sometimes you will be asked to locate a certain file, and you may find more than one.  It’s important to learn the locations of files and their purposes (i.e are you looking at the deployment manager’s copy of the file, or the servers’).  We will get to file locations in a later post.
  10. There are a lot of restarting servers required when working with WebSphere since server changes don’t just happen on the fly, they require a sync and a server restart to take effect as the XML files can be read as the server starts up.

Working With Installation Manager

Now we have Installation Manager (IM) installed it’s going to be our primary go to place for installing everything else so let’s have a look at how it works.

skitch.26

If you use a GUI you should see IBM Installation Manager added to the programs menu and you can run it from there, but you can also run it from the command line.  Navigate to the install directory /opt/IBM/Installation Manager/eclipse (beware case sensitivity) and run ./IBMIM.  I am using sudo to run it with the appropriate (root) rights because I’m not logged in as a root user.

skitch.25

 

skitch.24

The Installation Manager main menu gives us several options for working with software

Install:  adding new software such as WebSphere or Connections itself

Update: applying fixes and updates to already installed software

Modify:  changing the options for already installed software such as adding or removing features

Roll back: taking software back to an earlier release level for example rolling back WebSphere from an applied fix or IF

Uninstall: there’s no way back from this, uninstall the software and it’s gone completely

skitch.23

The file menu on the IM allows us to view what software , versions and locations exist.  We also use this menu to set up file repositories where IM can find installers.  We’ll look at that on our next blog entry “Installing WebSphere”.

As you can see, running our installs and updates through IM gives us much more flexibility and control over versions and upgrades.  Since IM maintains records of all installed software, location, patches and features it can’t be uninstalled whilst the owned software is still in place.  And by “can’t” I mean “won’t”.  If you try and uninstall IM it will simply refuse to uninstall itself until you have used its “uninstall” option to remove its owned software.

Installation Manager takes only a few minutes to install but think carefully about who installs it, who has rights to run it, and most importantly its install location

Setting Up Repositories

For IM to install software you must first tell it where to find the software you want to install.  Let’s take WebSphere as an example.

The WebSphere New Deployment installers come in 3 compressed files.  We extract all of those to the same directory using the syntax

unzip filename (eg WASND_v8.5.5_1of3.zip) -d {directoryname]

if you don’t use -d as a parameter the file will unzip into the directory you are currently running the command in.

skitch.6

 

Unzipped you should have 3 folders disk1, disk2 and disk3 and a repository.config file.  The repository.config is what IM looks for to determine how to install the software.

skitch.5

You want to add repositories for any software you plan to install by choosing File – Preferences from the IM menu and then “Add Repository”

skitch.4

Browse to the location of the extracted installers and find the repository.config file then select it.

skitch.3

 

skitch.2

One of the advantages of IM is that it can store previous versions of the software to enable you to rollback at any point, however the files needed for rollback need to stored on the file system and take up space.  You can go into this section of IM and choose to remove the saved rollback files at any point once you know you won’t need to rollback. If you do remove the files it should still be possible to rollback but you will need to be able to supply the original versions of the installers you want to rollback to.

skitch.1

When updating or installing software you can optionally be prompted for credentials to Passport Advantage in order for IM to find the files online.  This tells IM to find any updates available on Passport Advantage. It saves you the trouble of finding and downloading WAS fixes and patches but does require that the server has access to the internet.

skitch

Now when you go to Install or Update software IM will prompt you to login to Passport Advantage and optionally save the credentials so it won’t ask again.

Now we’re ready to install WebSphere.

 

Installing Installation Manager

Installation Manager (IM) is the IBM management tool that controls and manages the installation of IBM software. The big advantage of IM is that it creates its own library of what it installed and that enables you to easily rollback or update anything it manages.

Let’s start by installing IM – the compressed installers are different for each platform.  In Connections101 I will be installing both Linux and Windows components so I will eventually need both versions of IM (beginning agent.installer.”OS”) – extracted and shown below.

Installing IM 1

From the extracted directory run the file ./install on Linux , this will launch using a graphical interface so you will need to either have a GUI and browser installed or you will need to have set up X11 forwarding to your workstation.  There is a silent installer that you can run which won’t use the graphical interface and instead uses a response file to determine who to install. That uses file ./installc and instructions for that are here

 

Installing IM 2

 

Confirm you are installing the correct version of IM.  In our case, the newer the better.

Installing IM 3

This is the location of the Installation Manager files.  /opt/IBM/InstallationManager/eclipse by default on Linux C:\Program Files\Installation Manager\eclipse on Windows.  Change this to whatever location you want but make sure you will never run out of space on that location, or need to reassign it, as Installation Manager cannot be moved without first uninstalling all the software it manages (like Connections, WebSphere etc!).

Installing IM 4

The final screen before install confirms the location and details of the program.

Installing IM 5

On this screen you can see the “Target Location”, including the Package Group Name and the Installation Directory.  For each new piece of software IM installs it creates a new Package Group to manage it.  This is what is going to allow us to upgrade, rollback, patch and modify later one.

Installing IM 6

Having installed IM manager we can now use it to install other things.

Installing DB2

I am going to use DB2 as our Database server rather than SQL or Oracle because that’s part of our Connections entitlement.  If you have expertise and licensing for either Oracle or SQL and prefer those servers then I would go with them instead.  This DB2 install for our Connections101 server is very simple, a single instance and standard accounts. Depending on your requirements for HA and/or your number of users you may need to give that more thought.

I downloaded and use the DB2 10.5.0.5 (fixpack 5) universal installer.  You can install this without installing 10.5 first.  I extracted the compressed file v10.5fp5_ntx64_universal_fixpack then checked the OS meets the install requirements using the pre-requisite check

From the directory /DB2/univeral run ./prereqcheck

DB2PreReqCheck

the pre requisite check is going to validate if all the correct OS libraries and settings are in place.  In my first check I was missing several necessary files including 32bit versions of some libraries that even the 64bit DB2 installer needs.

Installing Dependencies

Any libraries that are missing can be installed using yum – in this case I was missing gcc which I resolved with “yum install gcc”.  This is why I strongly recommend you don’t attempt a Linux install without a subscription in place to help you find and install all the libraries you need.

Each time I successfully installed a missing library I re-ran prereqcheck again.  In total it took less than 10 minutes to get all the libraries installed.

The final pre-requisite you may fail on is ensuring SELinux is disabled on the OS. By default it will be enabled and to disable it you can edit the file /etc/selinux/conf (in my RedHat deployment) using:

sudo vi /etc/selinux/config and setting SELINUX=disabled

Disable SELinux

Once all the pre-requisites are passed we can go ahead and install DB2 which we do by running ./db2setup from the “universal” directory the installer created (the same directory we ran db2prereqcheck from).

The default installer uses a GUI so you can either configure your SSH connection to use X11 forwarding or (I prefer) use either NoMachine or VNC.  X11 works well but can be very slow to redraw screens.

db2setup 1

I choose to “Install a Product” and in this case I’m installing the DB2 Workgroup Server Edition which is all that I need to host the Connections101 databases.

db2setup 2

I like to choose the custom install so I can minimise what features are added and ensure no unnecessary services are listening or available.  Having services I don’t need installed just exposes access via a route I may forget exists and so don’t secure properly.

db2setup 4

Here are the features I chose – I don’t for example install LDAP or SSH services with my DB2 server for Connections.

Bear in mind that although DB2 itself will install into /opt/ibm/db2/v10.5, the actual databases will install into the home directory of the instance owner – /home/db2inst1. If your Linux partition isn’t set up correctly to allow plenty of space in /home (which by default it often isn’t) you will hit space problems.

Similarly when installing on Windows look at the install screens carefully and note where it wants to use c:\programdata for storing DB2 information. Even if you choose to install the program files on an E drive you need to make sure you check all locations to avoid filling up your C drive by default.

db2setup 6

Now we need to set up users who will have administrative access to the DB2 services. In Windows the default user is a local account called db2admin.  In Linux it’s a local account called db2inst1.  At this point of the install neither account exists, the installer will both create them and grant them the access they need.

It’s important to note what you use on the next few screens for the account names and passwords.  You will need to switch to these accounts at various points to work with DB2

db2setup 8

DB2 can create multiple instances which run in isolation from each other with their own assigned memory and resources.  In larger environments this is useful for sharing the load of many databases across the resources of a large server.

I’m choosing to create a single DB2 instance and install all the databases into it.  In a large environment I would often have multiple instances to ensure I can manage resources effectively and that I can share the Connections databases across them.

db2setup 9

The local db2inst1 account which will be created during install is the account you use to perform all the DB2 maintenance work including creating the Connections databases using the DBWizard and running the update or maintenance scripts.  Post install you can also grant other users rights to do this work if you want.

db2setup 11

DB2 installs listening on port 5000, you can easily change this during the install if you need to.  Some people choose other ports to obfuscate security so that DB2 can’t easily be found on its known port.  If that’s all the security you have in place then you should worry 🙂

db2setup 12

 

db2setup 13

Once the install is complete you can verify it by checking you can login or switch (su)  to db2inst1 (which confirms the account is created) or , if Windows, that you can login to the server using local account db2admin.

You should also verify that the new server is listening on port 50000 or whatever you chose during install.  I like to do this after a clean restart of the OS to ensure the DB2 server does start automatically on OS launch.

Linux

netstat -tulvn | grep :50000

or on Windows

netstat -an | find /i “50000”

Finally we need to activate our DB2 install.  Download the activation file CN3Z2ML from Passport Advantage.  

skitch.25

Unzip the download and find the file db2ese_u.lic which should be in the top directory.

Login to the server as db2inst1 and run

db2licm -a <pathto db2ese_u.lic>

Verify the license has applied by typing db2licm -l

skitch.24

Organising The Software

The first task after I’ve built the Deployment manager OS is to get all the installers and fixes downloaded.  In this environment we will have both Linux 64bit and Windows elements and so both copies of Installation Manager are downloaded for instance.

Here’s my directory structure – I use this and either scp or winscp to copy files onto other servers for installation.  It’s entirely a personal preference but I find having all the software organised into folders in a single location makes it easier to identify what I installed and ensures I don’t miss anything.

The jre was purely for using download manager on the IBM software site 🙂

Organising Software

Linux Setup And Tools

I like installing on Linux and know just enough about RHEL and SLES to get the work done that I need to do. I wouldn’t call myself an expert but I know what works for me to build Connections.  For instance there are several things I have on my checklist when deploying a Linux OS for Connections.

  1. I always deploy using supported distros.  That means for me specifically RHEL or SLES. I know people deploy using CentOS and others – I don’t.  Partly because it’s not supported so if it goes wrong I can’t expect IBM to help me and partly because I’m providing a Connections installation consultancy not Linux consultancy – when I quote work it’s to install Connections not to go down a rabbit hole of Linux workarounds.  I would feel bad charging people for Linux consultancy, there are far better Linux experts out there!
  2. I always take a subscription so I can update the OS and download any tools or libraries I need.  For this demo build which is only going to run for a few months I’m using a 30 day RHEL trial license so I can set it up properly.  Once more it’s about time. It costs a lot more in my time to manually find, download, place and install packages without subscription then a single license costs.  When you install RHEL the first thing you are going to want to do is update and add packages, with subscription you can do that in minutes rather than hours.
  3. I like to use gedit for editing XML files in place (yum install gedit) rather than vi or another text editor. The display of the structure and attributes is very clear which makes it easy for me to find content and spot typos. Connections is all about XML files
  4. I use WinSCP to copy files from a Windows machine over to a Linux one.  If I’m using my Mac I just use scp from within terminal but often I am on a remote server on a customer site and winscp is easier to deploy and use.  It’s also really easy to recursively copy entire directories like the log directories off the server to read.  Whenever I’m analysing logs, for all but the simplest reviews, I prefer to offload them from the server and review them on my workstation
  5. I use AQT (Advanced Query Tool) for opening and reviewing databases and install it on my Windows workstation.  It’s not expensive and supports all ODBC connections and a lot more. I have a blog piece on it here
  6. I install a graphical interface on Linux (usually GNOME) because I prefer working with that for things like Installation Manager and because X11 forwarding is too slow through most customer VPNs to make it workable for me.  If you’re not a seasoned Linux expert having a GUI will save you a lot of stress and make you better able to manage the environment.
  7. I use NoMachine as a remote desktop on Linux which ensures my session activity doesn’t timeout even if I go away, shut my laptop, get some sleep.  It also means other people can connect and takeover my session where I left it.
  8. I edit the /etc/hosts file and ensure that I have explicit entries for the local server, whatever hostnames it may use and all the other servers in my Connections environment with their hostnames.  I could rely on DNS to do this.  I choose to have more direct control over name resolution by using the hosts file.

So all of that is in place and now I’m ready to get started.