GT 3.9.4 Java WS Core: System Administrator's Guide

Introduction

[introduces the guide to sysadmins AND points them to the Installation Guide for comprehensive basic installation/configuration info]

Building and Installing

Building From Source

1 Obtain the source code for Java WS Core:

From CVS

  1. To get the latest source from cvs execute: 
     cvs -d :pserver:anonymous@cvs.globus.org:/home/globdev/CVS/globus-packages \
     checkout wsrf
  2. Change into the wsrf directory. 
     cd wsrf

From Core-only source distribution

  1. Untar or unzip the distribution archive. 
     tar xvfz ws-core-XXX-src.tar.gz
  2. Change into the unpacked distribution directory. 
     cd ws-core-XXX
2 Set the GLOBUS_LOCATION environment variable to the absolute path of the target directory of your installation.

On Windows:

 set GLOBUS_LOCATION=c:\gt4

On Unix/Linux:

 setenv GLOBUS_LOCATION /soft/gt4/
or 
 export GLOBUS_LOCATION=/soft/gt4/

If GLOBUS_LOCATION is not set, an install directory will be created under the current directory.

3 Run: 
 ant all

Installing Core-only binary distribution

1 Untar or unzip the distribution archive. 
 tar xvfz ws-core-XXX-bin.tar.gz
2 Change into the unpacked distribution directory. 
 cd ws-core-XXX
3 Set the GLOBUS_LOCATION environment variable to the unpacked distribution directory.

On Windows:

 set GLOBUS_LOCATION=c:\gt4

On Unix/Linux:

 setenv GLOBUS_LOCATION /soft/gt4/
or 
 export GLOBUS_LOCATION=/soft/gt4/

Configuring

Information on configuration settings and environment variables can be found in the public interface guide.

Deploying

[information about deploying the component into various containers/environments]

Testing

To execute Java WS Core tests, first make sure you:

The Java WS Core tests are included in the following jars:

  • $GLOBUS_LOCATION/lib/wsrf_test_interop.jar (contains the basic interoperability tests)
  • $GLOBUS_LOCATION/lib/wsrf_test_unit.jar (contains all other tests)
To execute the tests, pass the selected jar file from the above to the test script as described in the Developer's Guide. Make sure to run the tests with -DbasicTestsOnly=true option enabled.

Security Considerations

Permissions of service configuration files

The service configuration files such as jndi-config.xml or server-config.wsdd (located under etc/<gar>/ directory) may contain private information such as database passwords, etc. Ensure that these configuration files are only readable by the user that is running the container.
The deployment process automatically sets the permissions of jndi-config.xml and server-config.wsdd files as user readable only. However, this might not work correctly on all platforms and this does not apply to any other configuration files.

Permissions of persistent data

The services using subscription persistence API or other basic persistence helper API will store all or part of its persistent data under the ~/.globus/persisted directory. Ensure that the entire ~/.globus/persisted directory is only readable by the user running the container.

Invocation of non-public service functions

A client can potentially invoke a service function that is not formally defined in the WSDL but it is defined in the service implementation class. There are two ways to prevent this from happening:

  1. Define all service methods in your service class as either private or protected.
  2. Configure appropriate allowedMethods or allowedMethodsClass parameter in the service deployment descriptor (please see the configuration interface for details).

Troubleshooting

globus-stop-container fails with an authorization error

By default globus-stop-container must be executed with the same credentials as the container is running with. If the ShutdownService or the container is configured with separate private key and certificate files (usually /etc/grid-security/containercert.pem and /etc/grid-security/containerkey.pem) do the following to stop the container: 

 $ grid-proxy-init -cert /etc/grid-security/containercert.pem \
                   -key /etc/grid-security/containerkey.pem \
                   -out containerproxy.pem
 $ setenv X509_USER_PROXY containerproxy.pem
 $ globus-stop-container
 $ unsetenv X509_USER_PROXY
 $ rm containerproxy.pem

Alternatively, the ShutdownService can be configured with a separate gridmap file to allow a set of users to stop the container. Please see the WS Authentication & Authorization section for details.

General troubleshooting information

In general, if you want to investigate a problem on your own please see the Debugging and Logging section for details on how to turn on debugging. Also, please note that most of the command line clients have -debug option that will display more detailed error messages including the error stack traces. Also, searching the mailing lists such as discuss@globus.org or developer-discuss@globus.org (before posting a message) can also be very fruitful. Finally, if you think you have found a bug please report it in our Bugzilla system. Please include as much as detail about the problem as possible.