Node:Environment, Next:, Previous:Introduction, Up:Top


Environment Setup

You should run the programs in this document (other than web interfaces) as the owner of the web instance or via sudo. The environment for that account will need to be set up. If you own your own WAS instance, then, once your environment is set up, you can run all the WAS commands. If your instance is owned by a shared account, then you will have to log into that account or use sudo. Do not attempt to run these commands as any other user (especially root) unless you have explicitly set up environments for file sharing. (I recommend against it for WAS because it is very easy for one user to mess up everything for all other users).

N.b. In general, you should not do everything as the instance owner, but only stuff related to the WAS "server", such as deploying apps or restarting the WAS server. If you are a developer, you should do all of your editing and compiling and building using your personal account.

You must set and exported the following variables.

$WAS_HOME
Main directory where the WAS software is installed. WAS installs to /opt/IBM/WebSphere/AppServer by default.
$ORACLE_HOME
Home for the Oracle DB client or server software installation. This is typically something like /opt/oracle/product/8.1.7.3.
$LD_LIBRARY_PATH
On UNIX, this value should always be $ORACLE_HOME/lib.

If you are running an alternate instance, then you also must source $USER_INSTALL_ROOT/bin/setupCmdLine.sh, like 

         . /home/blaine/inst2/bin/setupCmdLine.sh
(If we have C-shell users, then let me know and I'll convert it to C-shell).

(In addition to other things, this will set the variable $USER_INSTALL_ROOT to the instance home directory. $USER_INSTALL_ROOT is not set for users using the default WAS instance.)

Add $WAS_HOME/bin to your search path.

To really make things easy, set up the login files for the account that you will run the WAS commands from.

  1. If your user own the instance, then this is your account.
  2. If your instance owner is a shared UNIX account and you plan to run the commands from that user's environment (like by running su - or sudo su -) then set up the instance owner account.
  3. If your instance owner is a shared UNIX account and you plan to run the commands via sudo from your personal account, then set up your personal account.
(In many situations, you will want the ability to use #2 or #3. In that case, set up both the shared account and your personal account.)

Download http://admc.com/blaine/howtos/was.profile and http://admc.com/blaine/howtos/was.kshrc and rename them to .profile and .kshrc in the user's home directory. Then edit .profile to enter your local path(s) as the file says to.

If you use some other shell, or if you have existing .profile and/or .kshrc file(s) that you don't want to clobber, then merge the contents of the downloaded files into your existing .profile and .kshrc files.

After you do this, verify that you can log in as this user and successfully run startServer.sh server1 and startServer.sh server1 (without making any manual environment settings).

The rest of this section is only applicable to setups using a shared account as the instance owner (i.e, your personal account is not the instance owner). If you own your instance, then you can safely skip the rest of this section.

For the remainder of this section, I use the name websphere to represent the WAS instance owner.

N.b. Note that if you just get a shell as the new user by running something like sudo -u websphere -s or sudo -u websphere ksh , you will not get a proper environment for the target user. If you want to get a full environment set up as if you logged in as the instance owner, then you need to run somethng like sudo su - websphere or su - websphere (or actually log into the server as websphere).