1.0 Installation and Initial Configuration

1.1 Requirements and Installation Prerequisites

The Moab Access Portal_® server system must have a Java 1.4 compatiable JVM (Java Virtual Machine) installed and properly configured. (Examples of popular JVMs include Sun's JDK/SDK, IBM's JDK, and Blackdown's JDK.) Such a JVM can be downloaded free of charge from Sun Microsystems.
Access Portal is built using JSP/Servlet technologies and as such requires a working, compatiable servlet container. The servlet container must implement at least the Servlet 2.2 and JSP 1.1 specifications and use a Java 1.4 compliant SDK. Recommended containers include Tomcat, Jetty, WebSphere 5.1, BEA WebLogic, etc. Most of these containers can be integrated or run parallel with existing web server software (such as Apache).
An up-to-date version of the Moab Workload Manager_® (4.2.0 or higher) is required to be running on the cluster head node(s).
Workload Manager's configuration must allow all non-privileged users to have ADMIN4 access rights. To do this place ADMIN4 ALL in your moab.cfg file and restart Workload Manager.
The cluster head node must have SSH properly installed and configured along with users setup to use Workload Manager (the users must have a correct environment and permissions to ensure they can access and execute all the Workload Manager client commands: showq, mjobctl, mrsvctl, etc.).
End-users that wish to access the portal will need a modern browser that supports cookies, stylesheets, and at least JavaScript 1.2.
The initial release of Access Portal will require that the underlying Workload Manager communicates with the TORQUE resource manager, but subsequent releases will support the full spectrum of resource managers traditionally supported by Cluster Resources, Inc.
Access Portal is supported on all platforms with a 1.4 Java Virtual Machine available: Linux, AIX, OSF/Tru-64, Solaris, HP-UX, IRIX, other UNIX platforms, Windows 2000/XP, and Mac OS X.

1.2 Installing Access Portal

Acquire the Access Portal distribution file (it is packaged in tar.gz format).
Extract the contents of the compressed tarball into a temporary directory.
Run the "setup" script as a user with proper installation permissions.
Follow the interactive instructions on where and how to install the Access Portal configuration and web application files.
Next, check the "map.properties" file located in the newly created $CFGDIR directory. Ensure that the following key settings have been configured suitably for your system needs:
- CFGDIR - this should be the same directory as where the map.properties is
- UPLOADDIR - specify where uploaded scripts should be temporarily stored
- SCRIPTDIR - specify where custom scripts should be temporarily stored
- SSH-KEY-AUTH - specify whether or not you use SSH keys, instead of passwords, to authenticate users.
- NOTE: If you plan on using SSH-KEY-AUTH (SSH key authentication) also follow the SSH Key Configuration steps.
(For full documentation on configuration and customization see the configuration parameters.)
Stop the servlet container.
If the map.properties file is in the default $CFGDIR directory ("/etc/map") simply start the servlet container and skip the next step.
Start the servlet container, but pass in the absolute path of the map.properties file via the CONFIG-FILE system property. The "setup" script should provide exact details on how to do this, but also see below:
Specific instructions for popular containers include:
- Jetty: when starting Jetty (see "tools/startjetty" for an exmpale) pass in the -DCONFIG-FILE=<PATH> argument
- Tomcat 3.x: before starting Tomcat with the "startup.sh" script, set the TOMCAT_OPTS environment variable to "-DCONFIG-FILE="
- Tomcat 4.x,5.x: before starting Tomcat with the "startup.sh" or "catalina.sh start" script, set the CATALINA_OPTS environment variable to "-DCONFIG-FILE="
Configure the servlet container to recognize the newly installed Access Portal web application. This varies from container to container; most containers will automatically detect the new application after being restarted. Access Portal application should need no extra configuration, other than possible security privleges to read and write from sockets (SSH port 22) and read and write from files in the directories found in the map.properties file.
Test the installation by visiting http://servlet_container_domain/map/. A login screen should be visible.

1.3 Initial Configuration

The Access Portal is self-configuring utilizing auto-detection and the policies already setup within the Workload Manager. The only steps remaining are documented below:

Configure Head Node Information for SINGLE Cluster (Administrative Privleges Required): Go to the the Host Settings page (/admin/index.jsp) and enter in the IP address or resolvable hostname of the cluster head node. Also enter in a username and password that has Workload Manager ADMIN1 privleges on the head node so that the connection and cluster configuration can be confirmed. (Note: This head node must have SSH enabled for the Access Portal to communicate with it.)
Configure Head Node Information for MULTIPLE Clusters: If Access Portal will connect to multiple clusters refer to Multiple Cluster Configuration.

Please remember to restrict access permissions to the Host Settings page (/admin/index.jsp) to prevent non-authorized individuals from changing Access Portal's settings.

To ensure that non-privileged users (those who are not given a specific ADMIN role level in Workload Manager's configuration) have proper access to all Access Portal functionality it may be necessary to enable default ADMIN4 as the default role. To do this place ADMIN4 ALL in your moab.cfg file and restart Workload Manager.

1.4 Initial Testing

One way to test Access Portal is to first submit jobs to the cluster, using Workload Manager's console commands or by means of the Moab Cluster Manager_®. Once done, the same user can then log into Access Portal. With jobs submitted both with and without Access Portal, a comparison of these jobs can be made to confirm that Access Portal is properly communicating with the Workload Manager. One can also get more detailed information about each job or even submit jobs and then confirm on the console or in Cluster Manager that the jobs match.