Installing GT 4.2.1

Any JVM options can also be passed using the GLOBUS_OPTIONS environment property.

The vast majority of the environment variables that effect the Globus XIO framework are defined by the driver in use. The following are links to descriptions of the more common driver environment variables:

Refer to Chapter 2, Configuring for environment variables. Note that the above environment variables do not supersede any settings provided in security descriptors.

Refer to the environment variable interface for details.

The environment variables described above only affect the selection of credentials if no credentials are specified in any of the applicable security descriptors.

All CAS client programs use the following environment variables to determine the appropriate URL to connect to and server identity to expect. In all cases, the command line options takes precedence over the environment variables.

The GSI-enabled OpenSSHD needs to be able to find certain files and directories in order to properly function.

The items that OpenSSHD needs to be able to locate, their default location and the environment variable to override the default location are:

The GridFTP server or client libraries do not read any environment variable directly, but the security and networking related variables described below may be useful.

The only environment variable that needs to be set for RFT is GLOBUS_LOCATION, in order to run the command line clients, which should be set to the location of the globus installation.

	Important
	You should include the following environment variables in your shell configuration file. (example $HOME/.bashrc)

In order to set the user environment, follow these steps:

This script prompts you for information about the CA you wish to create:

The unique subject name for this CA is:
cn=Globus Simple CA, ou=simpleCA-mayed.mcs.anl.gov, ou=GlobusTest, o=Grid

Do you want to keep this as the CA subject (y/n) [y]:

where:

Press y to keep the default subject name (recommended).

The next prompt looks like:

Enter the email of the CA (this is the email where certificate
requests will be sent to be signed by the CA):

Enter the email address where you intend to receive certificate requests. It should be your real email address that you check, not the address of the globus user.

Then you'll see:

The CA certificate has an expiration date. Keep in mind that 
once the CA certificate has expired, all the certificates 
signed by that CA become invalid.  A CA should regenerate 
the CA certificate and start re-issuing ca-setup packages 
before the actual CA certificate expires.  This can be done 
by re-running this setup script.  Enter the number of DAYS 
the CA certificate should last before it expires.
[default: 5 years (1825 days)]:

This is the number of days for which the CA certificate is valid. Once this time expires, the CA certificate will have to be recreated, and all of its certificates regranted.

Accept the default (recommended).

Next you'll see:

Generating a 1024 bit RSA private key
........++++++
................++++++
writing new private key to '/home/globus/.globus/simpleCA//private/cakey.pem'
Enter PEM pass phrase:

The passphrase of the CA certificate will be used only when signing certificates (with grid-cert-sign). It should be hard to guess, as its compromise may compromise all the certificates signed by the CA.

Enter your passphrase.

	Important:
	Your passphrase must not contain any spaces.

Finally you'll see the following:

A self-signed certificate has been generated 
for the Certificate Authority with the subject: 

/O=Grid/OU=GlobusTest/OU=simpleCA-mayed.mcs.anl.gov/CN=Globus Simple CA

If this is invalid, rerun this script 

setup/globus/setup-simple-ca

and enter the appropriate fields.

-------------------------------------------------------------------

The private key of the CA is stored in /home/globus/.globus/simpleCA//private/cak ey.pem
The public CA certificate is stored in /home/globus/.globus/simpleCA//cacert.pem

The distribution package built for this CA is stored in

/home/globus/.globus/simpleCA//globus_simple_ca_68ea3306_setup-0.17.tar.gz

This information will be important for setting up other machines in your grid. The number 68ea3306 in the last line is known as your CA hash. It will be an 8 hexadecimal digit string.

Press any key to acknowledge this screen.

Your CA setup package finishes installing and ends the procedure with the following reminder:

***************************************************************************

Note: To complete setup of the GSI software you need to run the
following script as root to configure your security configuration
directory:

/opt/gt4/setup/globus_simple_ca_68ea3306_setup/setup-gsi

For further information on using the setup-gsi script, use the -help
option.  The -default option sets this security configuration to be 
the default, and -nonroot can be used on systems where root access is 
not available.

***************************************************************************

setup-ssl-utils: Complete
			

We'll run the setup-gsi script in the next section. For now, just notice that it refers to your $GLOBUS_LOCATION and the CA Hash from the last message.

To finish the setup of GSI, we'll run the script noted in the previous step.

Run the following as root (or, if no root privileges are available, add the -nonroot option to the command line):

$GLOBUS_LOCATION/setup/globus_simple_ca_CA_Hash_setup/setup-gsi -default

The output should look like:

setup-gsi: Configuring GSI security
Installing /etc/grid-security/certificates//grid-security.conf.CA_Hash...
Running grid-security-config...
Installing Globus CA certificate into trusted CA certificate directory...
Installing Globus CA signing policy into trusted CA certificate directory...
setup-gsi: Complete

As root, run:

grid-cert-request -host 'hostname'

This creates the following files:

Note: If you are using your own CA, follow their instructions about creating a hostcert (one which has a commonName (CN) of your hostname), then place the cert and key in the /etc/grid-security/ location. You may then proceed to User certificates.

The certificate should be owned by root, and read-only for other users.

The key should be read-only by root.

As your normal user account (not globus), run:

grid-cert-request

After you enter a passphrase, this creates

Email the usercert_request.pem file to the SimpleCA maintainer.

The certificate should be owned by the user, and read-only for other users.

The key should be read-only by the owner.

To deploy a service into Java WS Core container use the globus-deploy-gar tool. To undeploy a service use globus-undeploy-gar.

It is recommended to increase the maximum heap size of the JVM when running the container. By default on Sun JVMs a 64MB maximum heap size is used. The maximum heap size can be set using the -Xmx JVM option. Example:

$ setenv GLOBUS_OPTIONS -Xmx512M 
$ GLOBUS_LOCATION/bin/globus-start-container

The above example will make the container start with maximum heap size set to 512MB.

It is also recommended to experiment with other JVM settings to improve performance. For example, the -server option on Sun JVMs enables a server VM which can deliver better performance for server applications.

You may have to edit <tomcat.dir>/webapps/wsrf/WEB-INF/web.xml if you are running Tomcat on a non-default port, that is if not using port 8443 (HTTPS). For example, if you run Tomcat on port 443 using HTTPS then the WSRF servlet entry should be modified to have the following defaultProtocol and defaultPort parameters:

<web-app> ... <servlet>
      <servlet-name>WSRFServlet</servlet-name>
      <display-name>WSRF Container Servlet</display-name>
      <servlet-class> org.globus.wsrf.container.AxisServlet
      </servlet-class> <init-param>
      <param-name>defaultProtocol</param-name>
      <param-value>https</param-value> </init-param>
      <init-param> <param-name>defaultPort</param-name>
      <param-value>443</param-value> </init-param>
      <load-on-startup>true</load-on-startup> </servlet>
      ... </web-app>

Alternatively, you can use the setDefaults Ant task to set the default protocol/port in the web.xml file:

$ cd $GLOBUS_LOCATION $ ant -f share/globus_wsrf_common/tomcat/tomcat.xml setDefaults \
        -Dtomcat.dir=<tomcat.dir> \
        -DdefaultPort=<port>
        -DdefaultProtocol=<protocol>
    

Also, by default the webContext property is set to the directory name of the web application on the file system. However, sometimes the context under which the web application is published might be different from the directory name of the application. In such cases it is necessary to explicitly configure the published context name in the web.xml file. To configure the web application context name set the webContext parameter in web.xml file. For example (assuming services are published under http://localhost:8080/foo/services) the webContext should be set to:

<web-app> ... <servlet>
      <servlet-name>WSRFServlet</servlet-name> ...
      <init-param> <param-name>webContext</param-name>
      <param-value>foo</param-value> </init-param> ...
      <load-on-startup>true</load-on-startup> </servlet>
      ... </web-app>

To create a .war of a Java WS Core installation do:

$ cd $GLOBUS_LOCATION $ ant -f share/globus_wsrf_common/tomcat/tomcat.xml war
        -Dwar.file=<war.file>
    

Where <war.file> specifies the absolute path of the war file.

Please note that deploying a war file might not be enough to have a working Java WS Core deployment. For example, in some cases the xalan.jar must be placed in the endorsed directory of the container.

Assuming Java WS Core is already deployed into Apache Tomcat (as described in Deploying Java WS Core), use the globus-deploy-gar tool with the -tomcat <tomcat.dir> option to deploy your GT service directly into Tomcat. Similarly, to undeploy a service, use the globus-undeploy-gar tool with the -tomcat <tomcat.dir> option to undeploy the service from Tomcat.

Alternatively, to indirectly deploy a service into Tomcat, first deploy the service into a regular GT installation using the globus-deploy-gar tool and then redeploy the GT installation into Tomcat (as described in Deploying Java WS Core). Similarly, to undeploy a service, first undeploy the service from a regular GT installation using globus-undeploy-gar tool and then redeploy the GT installation into Tomcat.

	Note
	Some GT services may not work properly in Tomcat.

Individual services can be configured with or without message security, but transport security is a characteristic of the entire container (either using ssl or plain tcp). Authentication and authorization of clients is performed using a callback mechanism.

[security]
ssl = 1
certfile =
keyfile = 

Globus XIO is a framework for creating network protocols. Several existing protocols, such as TCP, come built into the framework. XIO itself introduces no known security risks. However, all network applications expose systems to the risks inherent when outsiders can connect to them. Also included in the XIO distribution is the GSI driver, which provides a driver that allows for secure connections.

pyGlobus has a security module which allows for proxy creation, signing, encryption, and the creation and inquiry of security contexts. Care must be taken when developing applications which use GSI to ensure that authentication information will not be compromised. When creating a security context, one must ensure that the context will have the properties that they desire. For example, should the context use confidentiality or integrity? These concerns are not specific to pyGlobus but rather to any application developer who is using low level security APIs.

You should choose a well-protected host to run the myproxy-server on. Consult with security-aware personnel at your site. You want a host that is secured to the level of a Kerberos KDC, that has limited user access, runs limited services, and is well monitored and maintained in terms of security patches.

For a typical myproxy-server installation, the host on which the myproxy-server is running must have /etc/grid-security created and a host certificate installed. In this case, the myproxy-server will run as root so it can access the host certificate and key.

GSI-OpenSSH is a modified version of OpenSSH and includes full OpenSSH functionality. For more information on OpenSSH security, see the OpenSSH Security page.

Security recommendations include:

Security recommendations include:

By default, the aggregator sources do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information. If a user or administrator changes that configuration so that a service's aggregator source uses credentials to acquire non-privileged data, then that user or administrator must configure the service's aggregator sink to limit access to authorized users.

By default, the WebMDS plugins distributed as part of the Toolkit do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information.

The ResourcePropertyNodeSource and ResourcePropertyQueryNodeSource plugins can be configured either to allow users to specify what resources they want to query or to only allow users to query resources pre-configured by the web administrator. The standard WebMDS deployment allows users to specify the resources they want to query; to disallow this (for example, to ensure that people don't use your site's bandwidth to view information about some other site's services), remove the files $GLOBUS_LOCATION/lib/webmds/conf/openEndedRP and $GLOBUS_LOCATION/lib/webmds/conf/openEndedQuery.

Security recommendations for this component include:

No special security considerations exist at this time.

The following usage statistics are sent by Java WS Core by default in a UDP packet (in addition to the Java WS Core component code, packet version, timestamp, and the source IP address):

If you wish to disable this feature, please see the "Usage Statistics Configuration" section of Section 2.4, “Usage Statistics Configuration” for instructions.

Also, please see our policy statement on the collection of usage statistics.

The following usage statistics are sent by C WS Core by default in a UDP packet :

It sends it at container startup (globus-wsc-container) and receipt of that packet tells us that the container started.

If you wish to disable this feature, you can set the following environment variable before running the C container:

export GLOBUS_USAGE_OPTOUT=1

By default, these usage statistics UDP packets are sent to usage-stats.globus.org:4180 but can be redirected to another host/port or multiple host/ports with the following environment variable:

export GLOBUS_USAGE_TARGETS="myhost.mydomain:12345 myhost2.mydomain:54321"

You can also dump the usage stats packets to stderr as they are sent (although most of the content is non-ascii). Use the following environment variable for that:

export GLOBUS_USAGE_DEBUG=MESSAGES

Also, please see our policy statement on the collection of usage statistics.

The following usage statistics are sent by default in a UDP packet at the end of life time of each RFT Resource (or when a RFT resource is destroyed).

We have made a concerted effort to collect only data that is not too intrusive or private, and yet still provides us with information that will help improve the RFT component. Nevertheless, if you wish to disable this feature, please see the "Usage Statistics Configuration" section of Configuring Java WS Core for instructions.

Also, please see our policy statement on the collection of usage statistics.

The following GridFTP-specific usage statistics are sent in a UDP packet at the end of each transfer, in addition to the standard header information described in the Usage Stats section.

	Note
	The client (globus-url-copy) does NOT send any data. It is the servers that send the usage statistics.

We have made a concerted effort to collect only data that is not too intrusive or private and yet still provides us with information that will help improve and gauge the usage of the GridFTP server. Nevertheless, if you wish to disable this feature for GridFTP only, use the -disable-usage-stats option of globus-gridftp-server. Note that you can disable transmission of usage statistics globally for all C components by setting "GLOBUS_USAGE_OPTOUT=1" in your environment.

Also, please see our policy statement on the collection of usage statistics.

The following usage statistics are sent by RLS Server by default in a UDP packet:

The RLS sends the usage statistics at server startup, server shutdown, and once every 24 hours when the service is running.

If you wish to disable this feature, you can set the following environment variable before running the RLS:

export GLOBUS_USAGE_OPTOUT=1

By default, these usage statistics UDP packets are sent to usage-stats.globus.org:4180 but can be redirected to another host/port or multiple host/ports with the following environment variable:

export GLOBUS_USAGE_TARGETS="myhost.mydomain:12345 myhost2.mydomain:54321"

You can also dump the usage stats packets to stderr as they are sent (although most of the content is non-ascii). Use the following environment variable for that:

export GLOBUS_USAGE_DEBUG=MESSAGES

Also, please see our policy statement on the collection of usage statistics.

The WS RLS does not collect usage statistics in addition to what the RLS collects. Please consult the RLS documentation to familiarize yourself with usage statistics collected by it.

Also, please see our policy statement on the collection of usage statistics.

The following usage statistics are sent by default in a UDP packet (in addition to the GRAM component code, packet version, timestamp, and source IP address) at the end of each job (i.e. when Done, Failed, UserTerminateDone or UserTerminateFailed state is entered).

If you wish to disable this feature, please see the "Usage Statistics Configuration" section of Configuring Java WS Core for instructions.

Also, please see our policy statement on the collection of usage statistics.