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
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.
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.
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
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 184.108.40.206 as the version I want to install. I haven’t downloaded 220.127.116.11, only 8.5.5 so I’m relying on IM to get the fixpack from the Passport Advantage site.
There are already several fixes available for 18.104.22.168 but, having checked the System Requirements to ensure there are no specifics fixes I need, I let IM choose the recommended ones only.
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.
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.
These are the standard features I install for Connections. At this point the total install size should be about 2.5GB across both directories.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 22.214.171.124.