Globus Toolkit 3.2: Installation Guide

• GT3.2 Core distribution
• A JDBC compliant database
• CAS distribution

There are two ways the CAS distribution can be obtained and installed.

• As a part of the toolkit release installer. In this case, start with step CAS Database.
• Source distribution of GT3.2 and CAS installed separately. In this case, start with the next step.

Listed below are commands to build and run container from GT3.2 core source distribution. But these may have changed and the documentation in GT3.2 core would be the best reference for the same.

To build GT3.2 core:

casadmin$ cd ogsa/impl/java
casadmin$ ant
casadmin$ ant setup

• code for the service
• command line clients to access the service
• tests for backend database access code and frontend service
• sample properties files

To check out the source code for CAS from CVS:

To login, run:

cvs -d :pserver:anonymous@cvs.globus.org:/home/globdev/CVS/globus-packages login

At password prompt, hit Enter.

To check out the trunk code, run:

cvs -d :pserver:anonymous@cvs.globus.org:/home/globdev/CVS/globus-packages co cas

The top level directory in this checkout is referred to as CAS_HOME.

The CAS_HOME/build.properties file needs to be modified or the properties need to be overridden with each ant command. The properties relevant to deployment are:

• ogsa.root : GT3.2 core install path. (GLOBUS_LOCATION)

Important Notes:

• If the container is already running, it needs to be re-started after the deploy for the service to be visible.
• For tests also to be deployed, Junit needs to be installed. The build script requires that junit.jar be on the classpath for the tests to be compiled and deployed. Typically this is placed in the "lib" directory of the Ant install.

To deploy server, client and tests:

casadmin$ ant deployAll

This script also generates all client scripts and places them in $GLOBUS_LOCATION/bin. This directory needs to be added to the PATH to be able to execute these scripts from other locations.

To deploy only the client side of CAS, from CAS_HOME:

casadmin$ ant deployClient

To deploy only the server, from CAS_HOME:

casadmin$ ant deployGar

The CAS service can run with its own set of credentials. Instructions to obtain service credentials may be found here.

You can use the standard administrator clients that come with the distribution to perform host authorization and expect that the CAS service have credentials that have service name "cas".

The command in the above mentioned webpage may be altered as follows:

casadmin$ grid-cert-request -service cas -host FQDN

The location of certificate and key files is referred to as CAS_CERT_FILE and CAS_KEY_FILE, respectively.

PostgreSQL has been used for development and testing. The drivers for the same are included in the distribution. If a different database is used, the corresponding driver should be added to GLOBUS_LOCATION/lib.

Brief instructions to install a JDBC compliant database and specifically PostGres can be found here. For more detailed instructions, please refer to specific database documentation.

Create a CAS database based on the schema found at:

GLOBUS_LOCATION/etc/databaseSchema/cas_database_schema.sql

For example, to create a database called casDatabase on a PostgreSQL install on a local machine, run:

casadmin$ createdb casDatabase 
casadmin$ psql -U casadmin -d casDatabase -f 
GLOBUS_LOCATION/etc/databaseSchema/cas_database_schema.sql 

Note: A list of notices may appear on the screen. Unless any of them say ERROR, these are just output for information.

Configure the CAS Server with a properties file. A sample file has been provided in the distribution, GLOBUS_LOCATION/etc/casDBProperties. Adjust the parameters to adjust for your particular database installation.

jdbc:postgresql://127.0.0.1/casDatabase  

Note: Since this file contains the database access username and password, set appropriate permissions to protect the file.

Modify the Server Configuration file ( <gt3-install-location>/etc/server-config.wsdd) to adjust for your particular installation.

Refer to GT3.2 Security documentation for more details.

These instructions are for using the GT3.2 standalone container. If you are using Tomcat or any other hosting environment, refer to the product's specific documentation for starting it up.

Note: Make sure an environment variable GLOBUS_LOCATION is set to point to the GT3.2 install location.

To start the GT3.2 container, run:

bin/globus-start-container

For example, on a local machine on port number 8888 in GLOBUS_LOCATION, the command would be:

casadmin$ bin/globus-start-container -p 8888

Note: If -port is not used, then a container is started up on port 8080.

The CAS service should now be available and you should see the following:

• a list of services that have been deployed at startup (this list appears if you used the GT3.2 standalone container)
• the CAS URL in the following format:

http://gt3host:gt3port /ogsa/services/base/cas/CASService

(gt3host and gt3port stand for the host and port on which the container is running.)

For example, if the container is running on localhost and port 8888, then the instance URL will look like:

http://localhost:8888/ogsa/services/base/cas/CASService

To stop the GT3.2 container, run:

bin/globus-stop-container -secure hard

For example, if the container is running on local machine on port number 8888 in GLOBUS_LOCATION, run:

casadmin$ bin/globus-stop-container -secure hard http://localhost:8888

The hard option forcefully shuts down the container even if there are errors. For more options, use -help.

12

The CAS distribution has two sets of tests built using Junit.

To compile and deploy these tests, you must have Junit.

If you installed using the source distribution, refer to Step 4 of the install.

If you used an installer, ensure that junit.jar is on your classpath at install time.

This test does not need any service set up and only requires a database set up and a file with database configuration .

The target used to run the tests picks up the path to the database configuration file from the property cas.db.properites. If not overridden with -Dcas.db.properties option while running the test, the value defaults to GLOBUS_LOCATION/etc/casDBProperties.

The database needs to be empty for this test. To delete any existing entries in the database, use the following script

For a PostGres install, run:

casadmin$ psql -U casadmin -d casDatabase -f GLOBUS_LOCATION/share/cas/database_delete.sql

To run the test:

casadmin$ ant -f GLOBUS_LOCATION/etc/cas-build.xml runDatabaseTests

There might some lines output on the screen which start with ERROR, but they are not any indication of failure of the test.

At the end of the run, a summary message appears indicating the number of tests run and the number that failed. A test report is generated in GLOBUS_LOCATION/cas-test-reports with the name:

TEST-org.globus.ogsa.impl.base.cas.server.databaseAccess.test.PackageTests.xml

These tests target the frontend CAS server capability and also can be used to simulate multi user scenarios.

Test properties: It is required that the CAS service be deployed and a GT3.2 container started up. The tests pick up the host and port of the GT3.2 container from following properties:

• GT3Host : Host name of the machine on which GT3.2 container will be run for tests. Default, 127.0.0.1
• GT3Port : Port number on which the GT3.2 container will be run for tests. Default, 8080.

If in any of the Ant commands below, you are accessing a container not running in the above said default, use the -D flag in Ant to override the variable as shown.

ant <targetName> -DGT3Host="your host name" -DGT3Port="your port number"       

There are two test targets that have been set up which can be run with different user proxies.

The first test target tests all self operations and sets up the database for the second user.

The second test target, run with another user's proxy then ensures that the set up was done correctly. While the first test only requires that the cas database is bootup with implicit objects only, the second test requires that the first test to have successfully run.

The steps outlined below also describe how two sets of proxies (one being an independent proxy) can be generated from one set of credentials.

Other than the database configuration file described for the previous test, this test also uses a test properties file that is picked up by the target using the property cas.test.properties . If not overridden with -Dcas.test.properties it defaults to GLOBUS_LOCATION/etc/casTestProperties. The following properties need to be set in that file,

• user1SubjectDN: The subject in the proxy that will be used to run the first set of tests.
• user2SubjectDN: The subject in the proxy that will be used to run the second set of tests.
• serverDN: The subject DN of the credential used by CAS server
• maxAssertionLifetime: The value set as the maximum assertion lifetime in server-config.wsdd as shown here

Ensure cog-jglobus.jar is on the classpath. This jar can be found in GLOBUS_LOCATION/lib.

This can be placed in the classpath by using the GLOBUS_LOCATION/etc/globus-devel-env.csh script (or bat script in the case of Windows)

casadmin$ source $GLOBUS_LOCATION/etc/globus-devel-env.csh       

In the test properties file, set user2SubjectDN to be the subject in your regular proxy.

The following returns the appropriate string:

 casadmin$ java org.globus.tools.CertInfo -subject -globus 

Generate an independent proxy using the following command:

 casadmin$ java org.globus.tools.ProxyInit -independent 

Set the identity in the proxy generated from the above step as user1SubjectDN in the test properties file.

The following command will return the relevant string:

 casadmin$ java org.globus.tools.ProxyInfo -subject -globus 

Delete all data from database.

The following command would do it for a PostGres install with database name casDatabase and database username casadmin

 casadmin$ psql -U casadmin -d casDatabase -f GLOBUS_LOCATION/share/cas/database_delete.sql 

Now the database needs to be populated with CAS server implicit data for these tests to run. This may be done using the following command. The -d option takes a path to a file with database configuration needs to be set as described here . (If prior steps we done, the file in $GLOBUS_LOCATION/etc/casDBProperties should be set with requires values.)

casadmin$ $GLOBUS_LOCATION/bin/cas-server-bootstrap -d $GLOBUS_LOCATION/etc/casDBProperties -implicit 

Start a GT3.2 container as described here .

The following command runs tests for self permissions and sets up the database for user with subjectDN that is user2SubjectDN. If you are not running container on default host/port, set properties as shown here.

casadmin$   ant -f GLOBUS_LOCATION/etc/cas-build.xml serverTestsUser1 

Test report will be generated in GLOBUS_LOCATION/cas-test-reports. The file will be named TEST-org.globus.ogsa.impl.base.cas.server.test.PackageTests.xml

To test as the second user, generate proxy for the subject DN specified for the second user.

casadmin$ java org.globus.tools.ProxyInit 

To test as second user, run the following. If you are not running container on default host/port, set properties as shown here.

casadmin$  ant -f GLOBUS_LOCATION/etc/cas-build.xml serverTestsUser2 

Test report will be generated in GLOBUS_LOCATION/cas-test-reports. The file will be named TEST-org.globus.ogsa.impl.base.cas.server.test.PostPackageTests.xml

After these tests, the CAS database needs to be reset. The following command will delete all entries from the database.

casadmin$  psql -U casadmin -d casDatabase -f GLOBUS_LOCATION/share/cas/database_delete.sql

A client to bootstrap the CAS backend database is in GLOBUS_LOCATION/bin. casadmin$ cas-server-bootstrap [options] -d dbPropFile [ -implicit | -b bootstrapFile]

where:

• options :
  • -help Prints usage message
  • -debug Runs client with debug trace
• -d dbPropFile : This option specifies a properties file that has database configuration information. The format and properties in the file are described here.
• -implicit : This option inserts data inherent to the CAS server. It also adds service/action and namespace that can be used with FTP.
• -b bootstrapFile : This option adds user specified data to the database. "bootstrapFile" is the path to the file with user data. The user data should have the format specified in GLOBUS_LOCATION/share/cas/bootstrapTemplate. A sample bootstrap file is in GLOBUS_LOCATION/share/cas/bootstrapSample

For example say a user with nickname "superUser" using a subject DN "/O=Grid/O=Globus/OU=something/CN=someone" and in a user group called "suGroup" needs to be added. Moreover say, the user's trust anchor is "someTrustAnchor" with "X509" as authentication method and a DN "/C=US/O=something/CN=Some CA". The bootstrap file should look like,

 ta-name=someTrustAnchor ta-authMethod=X509 ta-authData=/C=US/O=something/CN=Some
 CA user-name=superUser user-subject=/O=Grid/O=Globus/OU=something/CN=someone
 userGroupname=suGroup     

The following command from GLOBUS_LOCATION/bin should populate the database with data in bootstrap file and implicit data, provided casDbProperties is configured as described here .

casadmin$ cas-server-bootstrap -d GLOBUS_LOCATION/etc/casDbProperites -implicit -b bootstrap