WAS6.1 Installation
This is a description of steps taken to install WebSphere Application Server 6.1 on a virtual machine. The OS used is Linux, more specifically CentOS 5.1.
I had the following goals when starting this installation:
- The complete configuration consists of WAS in the backend and IBM's Webserver as a frontend. The backend will be called was and it's IP address will be 192.168.212.128/24. The frontend will be called ihs and it's IP address will be 10.0.0.10/24.
- No centralized authentication infrastructure will be used.
- Trying to achieve maximally secure installation, i.e. no X or any other unnecessary package.
- Even though we strive to have as secure installation as possible, we'll disable SELinux.
Note, with regard to IP addresses, that frontend will usually be placed in separate network, e.g. in DMZ.
Finally, following this document will probably take some time until you successfully install WAS. Also you can expect problems which will further delay the installation process. But, when you do this several times, you'll be able to do it in a few hours. This is personal experience. :)
OS Installation
For the base OS installation please see CentOS Installation page.
Note that default installation of WebSphere puts it into /opt/IBM/WebSphere even though it's possible to change this location during install process. Anyway, be carefull to allocate enough space on whichever partition you intend to install WAS, or, use LVM so that you can later adjust partition size. Two installations of WAS 6.1 use 1.6G and 2.5G, while trial installation of WAS7 uses around 1.3G. Those installations are without applications and relatively fresh so count there logs also!
Additional customizations
Edit /etc/hosts file on both installations and add the following two lines:
192.168.212.128 was 10.0.0.10 ihs
If some of those names already appears in that file (probably it will) remove it so that the only occurence is one as shown above.
Turn off distribution's firewall as we'll add our rules!
# chkconfig iptables off
It's best at this point to restart the server as many changes have been done and it's goot time to verify if it's still boots. :)
The next step is to configure the firewall. I'm using the following rules, but you millage might vary. Also, be careful if you type over the network that you connection can broke in the middle of setup process! So, maybe the best approach would be to c/p these rules into /etc/rc.local file so that they are executed upon boot. Note that the character # is for comment, not a shell prompt. Finally, rules are on purpose very specific because I believe that's more secure approach.
The following assumptions hold for the rules:
- You have IHS front-end in the DMZ. The IP address of this host will be denoted as FRONTEND_IP
- The Websphere is in the internal network. The IP address of the Websphere is WEBSPHERE_IP and the network is WEBSPHERE_NET.
- Only SSL encrypted traffic is allowed between frontend and the Websphere.
- Management of the Websphere is done only from the local network and only using the SSL connection.
# Variables first, change them to match you setting FRONTEND_IP=10.0.0.2 WEBSPHERE_IP=192.168.212.128 WEBSPHERE_NET=192.168.212.0/24 # Change policy of INPUT and FORWARD to drop all the traffic by default /sbin/iptables -P INPUT DROP /sbin/iptables -P OUTPUT DROP # Allow all the traffic that we initiated and now returns /sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Allow all traffic to pass via the loopback interface /sbin/iptables -A INPUT -i lo -j ACCEPT /sbin/iptables -A OUTPUT -i lo -j ACCEPT # Allow SSH access to the Websphere for management purposes. This # is open from any address. Note that you have to properly customize # ssh server's configuration. /sbin/iptables -A INPUT -d $WEBSPHERE_IP -p tcp --dport ssh -j ACCEPT # For the management purposes of Websphere, allow access from the # local network to the appropriate port on the was: /sbin/iptables -A INPUT -s $WEBSPHERE_NET -d $WEBSPHERE_IP -p tcp --dport 9043 -j ACCEPT # Allow access to applications on WebSphere from the local network, # and from the frontend node: /sbin/iptables -A INPUT -s $WEBSPHERE_NET -d $WEBSPHERE_IP -p tcp --dport 9443 -j ACCEPT /sbin/iptables -A INPUT -s $FRONTEND_IP -d $WEBSPHERE_IP -p tcp --dport 9443 -j ACCEPT
There is one more thing you should remember. If, during installation process, you changed ports on which Websphere listens for connections, you'll have to change rules accordingly.
These are not the strictest rules possible. If you wont those, then you can also change the policy of OUTPUT chain and only allow selected traffic to go out.
WebSphere Installation
All this is done under the root account unless specifically told otherwise!
Preparation
Create user was (group was will be automatically created also):
# useradd was
Copy WAS installation directory somewhare on the machine. Any place will do.
As we don't have X installed it is necessary to use silent install. This means you should prepare response file that the installation process will use.
In the installation directory look for the file named responsefile.express.txt. It should be in the WAS directory. Make a copy, e.g. to was.txt, and modify it appropriately. The necessary changes are:
- -OPT silentInstallLicenseAcceptance="false"
This has to be changed to true. Note that this means you understand the terms of the licence and you accept them!
- -OPT disableOSPrereqChecking="true"
The only prerequisit checking I'm aware of is supported OS. As CentOS is not supported OS you should disable this check. There are other options (for one look into the respose file, the other is to change /etc/redhat-release file content)
- -OPT installType="installNew"
We are setting up new installation.
- -OPT installLocation="/opt/IBM/WebSphere/AppServer"
The directory where WAS will be installed.
- -OPT traceFormat=text
Log format is text, it's easier to find what went wrong in text file than in XML file!
- -OPT PROF_nodeName=wasnode
- -OPT PROF_hostName=was
- -OPT PROF_cellName=wascell
- -OPT PROF_isDeveloperServer="false"
We are not installing developer server!
- -OPT PROF_enableAdminSecurity="true"
In case you put this to false anyone will be able to connect to console and perform administrative tasks!
- -OPT PROF_adminUserName=admin
Replace with administrator login name here! Anything will do!
- -OPT PROF_adminUserPassword=theidiotcopieddefaultvalue
Password. You absolutely have to change this value!
Installation
The installation is simple. Just run it with the following command:
# ./install -options ./was.txt -silent
I assume that you are in WAS subdirectory of installation tree! In case anything goes wrong there will be waslogs/ subdirectory with log files in the home directory of the user that started the installation. In our case, that would be the root user, so the logs should be in the directory /root/waslogs!
Before checking that the installation works, change the owner of the installed WAS to already prepared was account:
# chown -R was.was /opt/IBM/WebSphere/AppServer
Now start the server under the user was:
# su - was
$ /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/startServer.sh server1
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/startServer.log
ADMU0128I: Starting tool with the AppSrv01 profile
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 25273
Note that AppSrv01 is the default profile name. In case you changed that parameter you'll have to change it in every command on this page where it appears!
The previous "screenshot" shows that WAS has successfully started. Now, you can access it's administrative console using Web browser. Point it to the following URL:
http://192.168.212.128:9060/
You should be redirected to port 9443 (secure connection) and login form has to appear. Type in the parameters you provided in the response file, look around a bit, and when you are finished we continue with the customization and hardening process.
While at this step, note the installed version (it should be written immediately after successful login)! In my case, it is 6.1.0.3.
To stop the server, execute the following command (still as user was):
$ /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/stopServer.sh server1
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/stopServer.log
ADMU0128I: Starting tool with the AppSrv01 profile
ADMU3100I: Reading configuration for server: server1
Realm/Cell Name:
Username:
Password:
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server server1 stop completed.
It's obvious that you have to provide admin username and password in order to stop the server.
Customization and hardening
The installation is basically finished. I would recommend two additional steps. Removal of sample applications, and adding users with specific privileges for accessing Web console.
To remove sample applications, start WAS and open it's Web console. After logging in, select Applications -> Enterprise Applications in the left pane. Then, in the right pane select all the applications and click on the Uninstall button!
There is option in response file that prevents installation of default applications so it's better to disable them there than to deinstall them after the installation!
Updating
The process of updating can be broken down into the following steps:
- Downloading necessary additional software and updates themselves
- Installing software
- Applying fixpack
After installing WAS our next step is to apply newest fixes. This step is not absolutely necessary, but during the fixpack selection process the application on the Web site will notify you if there is or is not any fix to be applied. My personal preference is to apply the newest fix anyway!
In order to install fixpack, you'll first have to install the application for applying updates, I'll call it updater.
The newest version of the updater can be downloaded from the following URL:
http://www-933.ibm.com/eserver/support/fixes/fixcentral/
Select Software/WebSphere, then under product WebSphere Application Server, select your installed version you noted in the previous step (which in my case is 6.1.0.3). Finally, select a platform, in my case it is Linux 32-bit,x86. Note that it is possible that your further options will be different based on the different installed version or platform! Don't forget to select Continue in order to proceed.
On the following screen select Browse fixes radio button, and then Continue.
Two packages have to be downloaded from this screen. The first one is the updater itself. In my case this was the file 6.1.0-WS-UPDI-LinuxX32-FP0000017. The second one is the fixpack, which again in my case was 6.1.0-WS-WAS-LinuxX32-FP0000017.
Copy the first archive to the destination host and unzip it. After unziping you'll have two directories: JDK and UpdateInstaller. Enter UpdateInstaller directory and copy response file responsefile.updiinstaller.txt to, e.g., updater.txt file. Now edit this file:
- -OPT silentInstallLicenseAcceptance="false"
This has to be changed to true. Note that this means you understand the terms of the licence and you accept them!
- -OPT disableOSPrereqChecking="true"
The only prerequisit checking I'm aware of is supported OS. As CentOS is not supported OS you should disable this check. There are other options (for one look into the respose file, the other is to change /etc/redhat-release file content)
- -OPT installLocation="/opt/IBM/WebSphere/UpdateInstaller"
The location where Updater will be installed. Note that by default the location for Windows machines is activated so you have to change this.
That's it. Now start the installation process:
# ./install -options ./updater.txt -silent
After the installation process finishes, you'll have the directory /opt/IBM/WebSphere/UpdateInstaller/. If there is no the directory, check logs which can be found in /tmp/niflogs. This will give you some clue why the installation failed!
Now the installation of fixpack. Copy the fixpack file to destination host and copy the file /opt/IBM/WebSphere/UpdateInstaller/responsefiles/install.txt somewhere locally. We'll assume that you copied it to root's home under the name fixpack17.txt. This is the response file for the update installation process. Edit it as follows:
- -W maintenance.package=/root/6.1.0-WS-WAS-LinuxX32-FP0000015.pak
Note that this has to be a full path name to the fixpack file on the destination host.
- -W product.location="/opt/IBM/WebSphere/AppServer"
The location of WAS you intend to update!
Now run the update process:
# /opt/IBM/WebSphere/UpdateInstaller/update.sh -options /root/fixpack17.txt -silent Executing command: /opt/IBM/WebSphere/UpdateInstaller/java/jre/bin/java -cp /opt/IBM/WebSphere/UpdateInstaller/update.jar -Xms48m -Xmx384m run -options /root/fixpack17.txt -silent
If the update process immediately terminates, there is probably an error (or you have the fastest machine on the Internet :)). So, for a logs, look into the following directory: /opt/IBM/WebSphere/UpdateInstaller/logs/tmpN.
Web Frontend Installation
- CentOS installation and removal of unnecessary packages
- IBM HTTPD installation Create ihs group and user Add ServerName to conf/admin.conf and change User/Group value to ihs Change ownership of conf/httpd.conf
- Update installer installation
- Fixpack installation
Certificate installation on Frontend
Probably you'll purchase certificate from some Certificate Authority. After receiving certificate you'll have to import it into the keystore of HTTP server. Here, I'll describe how to do that with Verisign provided certificate. There are several ways to handle certificates. The first one is via WebSphere administration console, then, you can use keytool tool provided with the Java SE, and finally you can use OpenSSL tool. I'll describe the use of the combination of OpenSSL and keytool.
The following steps have to be taken:
- TBD: Generate certificate request
- Go to the Verisign page
- If this is your first time requesting certificate, you'll have to register with Verisign.
- Login to access certificate handling page.
- TBD: Request certificate.
- Pay for certificate. First time Verisign will call you to verify that you have rights for a requested domain. Anyway, the time necessary to handle all this might stretch throught several weeks.
- Go again to your Verisign page, select certificate (if it's not selected) and request it. Download certificate in X.509 format.
- Put in one file certificate and a private key.
- Import this combination into keystore using the following command
$ openssl pkcs12 -export -in certificate.pem -inkey privkey.pem -out keystore.pkcs12 $ keytool -importkeystore \ -srckeystore keystore.pkcs12 -destkeystore keystore.jks \ -srcstoretype PKCS12 -deststoretype JKS
First, you'll be asked for keystore password. Then, the certificate will be shown and you'll be asked if you trust given certificate.
Troubleshooting
Some major problems I had were caused by the Web Console's not updating Plugin keystore on Web front end. This was easily checked by looking at the timestamp on the front end node.
Final notes
IBM should be more consistent, especially with respect where it places log files!
Notes added after writing this document
In CentOS 5.2 when you select minimal install (by deselecting all packages!) significat number of packages is not installed any more. So, the list of packages to be removed now is:
hdparm pm-utils dmidecode wireless-tools newt iptables-ipv6 gnu-efi kudzu dbus-glib checkpolicy usermode slang rhpl system-config-securitylevel-tui hal dbus cryptsetup-luks authconfig kbd policycoreutils setools selinux-policy selinux-policy-targeted