Install Admin Node

Prerequisites

Must have unzip installed.
Have either of the following installed:
- DB/2 Runtime client installed (if database is remote)
- full DB/2 install (if database is local)
Make sure you have enough space available in the partition where you will be installing WebSphere. About 325 MB is a comfortable amount of free space for the install.
Create a database for WebSphere. The current database name is nerwasp4 for production and nerwst1 for testing. It can be remote or local. If a WebSphere 4.0 database already exists (should only be the case for practice install/reinstall cycles), you will need to drop the existing database.

As the DB2 instance user:
```
db2 "CREATE DATABASE <dbname> WITH \"WebSphere v4 Database\""
	    
```
Make the comment "WebSphere v4 Database (Test)" for the test server DB, to differentiate it from the DB for the production server.

There are two things that are special about this database and its instance.
1. The database instance must be modified using the following commands:
```
 
export EXTSHM=ON 
db2set DB2ENVLIST=EXTSHM 
		  
```
2. The database must be modified by running:
```
 
db2 update db config for <dbname> using applheapsz 256 
		  
```
  You may need to run this from the local database node.
If the database is remote, remember to catalog the database and the node in db2axs.
- As the db2axs user, on the WebSphere node:
```
db2 "CATALOG DATABASE <dbname> AS <dbalias> AT NODE <dbnode> with \"WebSphere v4 Database\""
		  
```
  Make the comment "WebSphere v4 Database (Test)" for the test server DB, to differentiate it from the DB for the production server.
According to convention, <dbname>, <dbalias>, and <dbnode> should be the same name, (e.g. nerwst1 for the test DB).
Remember to bind the database to the necessary packages. For more info about how to do this see the DB2 documentation. (During my test installs, I didn't have to bind anything. - Drake).

WebSphere 4.0 Installation

By default WebSphere is installed to /usr/IBMWebAS4 so make sure there is at least 325 Mb free in /usr.
We do not want the WebSphere installer to modify our Apache configuration, so we have it add lines to some dummy files for manual inspection (and use) later. To do this touch the following file:
```
touch /tmp/httpd.conf
```
Make necessary changes to the file:
```
/nerdc/src/bff/websphere/v4.0.1/aix/custom/adminserver-install.script
	    
```
- DBUser - nerwas1
- DBPassword - <password>
- DBName - nerwasp4 for production, nerwst1 for test.
- DBHome - /u/db2axs
You may not have to make any changes. Note that the DBUser and DBPassword currently reflect the "WebSphere Administrator" user in the local OS.

You can now install websphere. The install directory is currently located at /nerdc/src/bff/websphere/v4.0.1/aix/.

	Note
	When installing WAS4.0, make sure you are root, but with the osg user's environment. In other words, when becoming root, enter: su - osg su So, you first become the osg user with the osg user's environment. Then you "su" to root while still retaining the same environment.

Run the following command:

./install.sh -silent -responseFile custom/adminserver-install.script

The installer should not give you any errors. The install script writes output to /tmp/install.log

Start the application server to make sure that it was installed correctly. As root:
```
/usr/IBMWebAS4/bin/startupServer.sh &
	    
```
You can watch the log /usr/IBMWebAS4/logs/tracefile to see the startup progress, and to find any errors.

Installing WebSphere Fixpacks

At this point, you want to apply IBM's fixes/upgrades for WAS. To install WebSphere fixpacks, refer to this document.
Restart the server (you shut it down to install the fixpack).
If you had to drop an existing WAS admin database, now is a good time to use XMLConfig to import your saved data. (Trying to import this data before installing the latest fixpack may not work):
```
$ <WAS_install_dir>/bin/XMLConfig.sh -adminNodeName <new_node> -import config.xml
	  
```

Testing

Try running the admin client:
```
/usr/IBMWebAS4/bin/adminclient.sh &
	    
```
Make sure it starts OK, and check that the WAS object tree (hierarchy of nodes, application servers, enterprise applications, etc.) looks healthy.
With the admin GUI, try stopping/starting an Enterprise Application and then an Application Server, checking tracefile for any errors.

Set Up Security and Permissions

We want to set up security so that non-root users in the dunx group can run clients, such as XMLConfig, without having to input the WebSphere admin user's password.

Edit /usr/IBMWebAS4/properties/sas.client.props and change the following entries:

com.ibm.CORBA.loginSource=properties
com.ibm.CORBA.loginUserid=cn\=aa480100\\2fapp\\2fosg, dc\=ufl, dc\=edu
com.ibm.CORBA.loginPassword=<osg user password>

Of course, you should use the loginUserid and loginPassword that apply in your case.

If you don't like having the bare password displayed in this file, you can run the PropFilePasswordEncoder utility which comes with WebSphere:
- First add this line to the /usr/IBMWebAS4/bin/PropFilePasswordEncoder.sh script:
```
export CLASSPATH=$CLASSPATH:$WAS_HOME/lib/security.jar
		  
```
  It's not clear to me why IBM didn't include the security.jar in the script's classpath, since the utility won't run without it.
- Now run the script:
```
/usr/IBMWebAS4/bin/PropFilePasswordEncoder.sh /usr/IBMWebAS4/properties/sas.client.props -SAS
		  
```
  The passwords in sas.client.props should now be XOR encoded (but not encrypted - important distinction!).

Now we must make certain directories and files owned by the group was, which every application server is a member of. This will allow every application server to access these shared resources.

cd /usr/IBMWebAS4
chgrp was bin
chmod g+rwX bin
chgrp was bin/admin.config
chmod g+rw bin/admin.config
chgrp -R was config
chmod -R g+rwX config
chmod o-r config
chgrp -R was etc
chmod -R g+rwX etc
chmod -R o-rw etc
chgrp -R was logs
chmod -R g+rwX logs
chmod -R o-rw logs
chgrp -R was properties 
chmod -R g+rwX properties
chmod -R o-rw properties
chgrp was temp/spnode??
chmod g+rwX temp/spnode??
chmod o-rwX temp/spnode??

Start up WebSphere and open the Security Center.
- Under the "General" tab, Check the box "Enable Security".
- Under the "Authentication" tab, check "Lightweight Third Party Authentication (LTPA)". Set "Token Expiration" to 150 minutes. Set "Domain" to "ufl.edu".
- Under "LDAP Settings", set "Security Server ID" and "Bind Distinguished Name" to "cn=aa480100\2fapp\2fosg, dc=ufl, dc=edu". Set "Security Server Password" and "Bind Password" to the OSG special user password. Set "Host" to "dir.ufl.edu". Set "Base Distinguished Name" to "dc=ufl, dc=edu". Change "Directory Type" to "Custom".
- Click the "Advanced" button. Set "User Filter" to "(&(uid=%v)(objectclass=person))". Set "User ID Map" to "*:uid".

Add Crontab Entries

Add these lines to root's crontab (it's an external link because the long lines mess up the formatting of this page). These tasks are useful for WebSphere maintenance.

The first line exports the full XMLConfig dump from WebSphere's admin repository each night. This dump is handy for backup and reference purposes, and is also used by the config2sh script described below.
The config2sh script regenerates nightly the customized scripts we use to administer WebSphere, based on the latest XMLConfig dump.
The plugin-poller.sh script checks up on, and if necessary regenerates, the plugin configuration every three minutes.
The delete-old-backups.sh script removes backups that are over a certain number of days old from the backup directory, /nerdc/servlets/v4/backup, the interest of preserving disk space. The backups are created as part of the application reinstall process.