Node:Instance, Next:, Previous:WAS, Up:Top



Installing an Alternate Instance

You need to make up a name for the new instance. This document hereafter uses <INST> to refer to this name. Note that this is the "unqualified" instance name. The full instance name is <INST>_<NODE>). You will need a range of 14 available consecutive (for sanity's sake) IP ports. (Since you're running as non-root, they must be > 1023). You also need to pick a $USER_INSTALL_ROOT, the directory in which to install this instance (commonly under your personal home directory somewhere). This document calls the UNIX user who will "own" and "run" the new instance <INST_OWNER>.

Chown the $USER_INSTALL_ROOT to <MAIN_OWNER>. (It won't stay this way. This is only needed to do the install). (N.b: This is <MAIN_OWNER> here, not <INST_OWNER>!)

You have to be <MAIN_OWNER> to perform the following actions.

  1. Put $WAS_HOME/bin in your search path (wsinstance.sh depends on this).
  2. cd $WAS_HOME/bin/wsinstance.
  3. cp portdef.props <NODE>_<INST>_portdef.props.

N.b.

  1. This filename uses an inverted instance name. The full instance name is <INST>_<NODE>, but the props file uses <NODE>_<INST>.
  2. The WS docs incorrectly state the the props file uses the former, but it actually uses the latter.
  3. (In general, always be careful of what order is required in different circumstances, because they do vary).

Now edit the new file and change the port numbers to your 14 available ports. The order of the values in the .props file is arbitrary, but the order of the ports may not be, so, to be safe, assign port numbers in the following sequence (this sample uses the port sequence beginning at 4002). (I recommend that you edit a copy of portdef.props instead of what I supply here, in case IBM has changed anything in your version).

         HTTPS_TRANSPORT_ADMIN=4002
         HTTP_TRANSPORT_ADMIN=4003
         CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=4004
         HTTP_TRANSPORT=4005      #  Can connect directly to this
         HTTPS_TRANSPORT=4006
         INTERNAL_JMS_SERVER=4007
         BOOTSTRAP_ADDRESS=4008
         SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=4009
         SOAP_CONNECTOR_ADDRESS=4010
         DRS_CLIENT_ADDRESS=4011
         CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=4012
         JMSSERVER_QUEUED_ADDRESS=4013
         JMSSERVER_DIRECT_ADDRESS=4014
         ORB_LISTENER_ADDRESS=4015
     

Many of these ports are very important. The bootstrap port (BOOTSTRAP_ADDRESS) must be supplied to the dumpNameSpace.sh command (with the -port switch). HTTP*_TRANSPORT_ADMIN are the Administrative console ports. (int this example, you'd use https://localhost:4002/admin for the SSL Admin server). HTTP*_TRANSPORT are the direct HTTP ports to use the App Server (as opposed to going through a standalone web server). The default ports for the default instance are listed at the bottom of http://publib7b.boulder.ibm.com/wasinfo1/en/info/aes/ae/rins_portnumber.html.

Run the command

         ./wsinstance.sh -name <INST> -path $USER_INSTALL_ROOT -host <NODE> -create
     
(N.b. you specify the node name, not the host name. The switch name and the WAS docs are wrong). Watch for error messages. (If you mess up, you must run ./wsinstance.sh ./wsinstance.sh -name <INST> -path $USER_INSTALL_ROOT -host <NODE> -delete to remove the bad instance before recreating).

Become root.

Fix perms so that <INST_OWNER> can access what he needs. $WAS_HOME and the following subdirs of $WAS_HOME must be rx-able to <INST_OWNER>:

         bin, java, properties, deploytool, config, lib, classes, null, samples, web.
     
And the same for bin/setupCmdLine.sh. (Most of these will probably be ok since the instance user is in the group <MAIN_OWNER>, but that depends on the umask and env. when install was run). Chown $USER_INSTALL_ROOT to <INST_OWNER>.
         chown -R <INST_OWNER>:<INST_OWNER> $USER_INSTALL_ROOT
     
Make sure that $USER_INSTALL_ROOT/config and all parent directories rx-able to all (<MAIN_OWNER> and the IWS user need access*). Make sure that the UNIX user who IWS runs as* has read access to the file $USER_INSTALL_ROOT/config/cells/plugin-cfg.xml.
* Ignore the IWS user stuff if you are on Linux or arent' setting up iPlanet web server.

Skip the next two paragraphs if you are on Linux or aren't setting up iPlanet web server.

Back up and edit <IWS_INST_HOME>/config/obj.conf. Search for the attribute "bootstrap.properties". Change the value of this attribute to $USER_INSTALL_ROOT/config/cells/plugin-cfg.xml (If you have multiple iWS instances, or multiple virtual sites within one obj.conf file, you can just copy the 3 lines containing ("libns41_http.so", ".../plugin-cfg.xml", and the following Service line) to the target obj.conf files or obj.conf virtual site blocks.

Change the WebSpherePluginConfig value to $USER_INSTALL_ROOT/config/cells/plugin-cfg.xml. (If you have virtual sites, you can have different virtual sites using plugin-cfg.xml files from different WAS instances). Restart the web server

         <IWS_INST_HOME>/restart
     

Become <INST_OWNER> and test things out.

Export the variable $WAS_HOME

         export WASROOT=$WAS_HOME     # If you're running korn or bash shell
     
Source $USER_INSTALL_ROOT/bin/setupCmdLine.sh
         . $USER_INSTALL_ROOT/bin/setupCmdLine.sh
     
and run some commands, like
         $WAS_HOME/bin/startServer.sh server1
         http://localhost:4003 (where the number is the HTTP_TRANSPORT_ADMIN above).
         dumpNameSpace.sh -port 4008 (where the number is the BOOTSTRAP_ADDRESS above).
     
(Note that the sample apps will not be available unless you install them. The wsinstace.sh command copies only the Admin Console application).

Our security strategy is to permit Admin Console access only via https on the localhost. If you are on another host, you can use VNC, X forwarding, or SSH X forwarding to run your Admin Console browser on the target server. You can always enter any username to access the Console. We do not turn on global security because that requires the instance to be run as root, or access to an external LDAP server. It would be nice if IBM let you set your own source IP list for access (like you can with Tomcat and pretty much every web server), but they don't. If you have iptables or other firewall software installed, it is easy and more flexible to use that than to run the Admin service on localhost as explained below.

Now disable services that we don't use (non-HTTPS Admin Console and HTTPS web access), and tighten up access. Stop WAS

         $WAS_HOME/bin/stopServer.sh server1
     
Back up, then edit the following file.
         $USER_INSTALL_ROOT/config/cells/<NODE>/nodes/<NODE>_<INST>/servers/server1/server.xml
     
Remove the <transport... </transports> stanzas which contain the following strings:
         HTTPTransport_1, HTTPTransport_2, HTTPTransport_3
     
if you are using an external web server; and
         HTTPTransport_2, HTTPTransport_3
     
if you are using only the built-in HTTP service. In the HTTPTransport_4 stanza, change the value of host from "" to "localhost". Back up, then edit the following file.
         $USER_INSTALL_ROOT/config/cells/<NODE>/virtualhosts.xml.
     
Remove the lines containing the following strings.
         HostAlias_1, HostAlias_3, HostAlias_4
     
if you are using an external web server; and
         HostAlias_2, HostAlias_3, HostAlias_4).
     
if you are using only the built-in HTTP service. Start WAS back up.
         $WAS_HOME/bin/startServer.sh server1
     

From here on, you must access the Admin Console at https://localhost:4002/admin from a local login. (Use the port number specified for HTTPTransport_4 in the server.xml file, which you edited above.

You access the end-user interface through your external web server (if you have set one up), or at the HTTP_TRANSPORT port otherwise (see the file $IWS_HOME/bin/wsinstance/<NODE>_<INST>_portdef.props).