Introduction
This guide contains advanced configuration information for system administrators working with C WS Core. It provides references to information on procedures typically performed by system administrators, including installation, configuring, deploying, and testing the installation.
![[Important]](/docbook-images/important.gif) | Important |
|---|---|
This information is in addition to the basic Globus Toolkit prerequisite, overview, installation, security configuration instructions in the Installing GT 4.2.0. Read through this guide before continuing! |
Table of Contents
If you want to install only C WS Core (as opposed to the entire Globus Toolkit), we describe two options below: from the installer and from CVS.
In order to build and install the C WS-Core component from an official release:
Table 1. Building C WS Core from installer
| 1 |
Obtain the latest GT 4.x.x release tarball installer from the Download webpage. |
| 2 |
Untar the tarball: tar xvfz
gt<version>-all-source-installer.tar.gz
|
| 3 |
Change to the installer directory: cd
gt<version>-all-source-installer
|
| 4 |
Run: ./configure -prefix=<path to install>
|
| 5 |
Run: make wsc
|
| 6 |
Run: make install
|
In order to build C WS Core from CVS:
Table 2. Building C WS Core from CVS
| 1 |
Obtain the source code for C WS Core from CVS:
|
| 2 | Set the GLOBUS_LOCATION environment variable to the
absolute path of the target directory of your installation.On Unix/Linux:
setenv GLOBUS_LOCATION /soft/gt4/or export
GLOBUS_LOCATION=/soft/gt4/
|
| 3 |
Run ./make-packages.pl -bundles=gt4-c-ws-core -deps -install=$GLOBUS_LOCATION
|
The C WS-Core does not require configuration/deployment steps. All parameter configuration is done programmatically at present.
The C WS-Core has a test suite that tests a number of different packages included in the
component. The tests can be built using either the wsctests
target tomake in the installer of a release, or they can be
built using thegt4-c-ws-core-test bundle in
the./make-packages.pl command mentioned previously.
The tests are installed into $GLOBUS_LOCATION/test, and can be run from the appropriate sub-directories.
Table of Contents
C WS-Core supports secure transport (https) and secure message (just X509 signing, not encryption).
With secure transport,
the entire container must be run over an
https transport. This is done by default for the C container. If
the user does not want security in the container,
or wants to use secure message instead
of secure transport, they should use the
-nosec argument to
globus-wsc-container.
For clients, the secure transport is enabled if the contact URI contains the 'https' scheme instead of 'http', so the client doesn't have to enable or disable it explicitly.
Table of Contents
As of 4.2.0, the Globus Toolkit provides system administration logs that are CEDPs best practices compliant.
To enable CEDPS logging, pass the -log PATH parameter to the globus-wsc-container program.
For more details on the CEDPS Logging format, including descriptions of reserved name-value pairs, see http://cedps.net/index.php/LoggingBestPractices:
The sample log file contains many log entries for various scenarios in the C WS container.
Table of Contents
For a list of common errors in GT, see Error Codes.
This is a new component. If you are having trouble using it, please let us know!
Table 1. C WS Core Errors
| Error Code | Definition | Possible Solutions |
|---|---|---|
globus_soap_message_module: Failed sending request
http://widgets.com/WidgetPortType/createWidgetRequest.
globus_xio: Unable to connect to grid.example.org:8080
globus_xio: System error in connect: Connection refused
globus_xio: A system call failed: Connection refused
| Unable to contact service container | Check that the service endpoint refers to a running container. |
globus_soap_message_module: Failed sending request
http://widgets.com/WidgetPortType/createWidgetRequest.
globus_xio_gsi: gss_init_sec_context failed.
GSS Major Status: Unexpected Gatekeeper or Service Name
globus_gsi_gssapi: Authorization denied: The name of the remote entity
(/C=US/O=Globus Alliance/OU=Service/CN=host/grid.example.org), and the
expected name for the remote entity
(/C=US/O=Globus Alliance/OU=Service/CN=host/cloud.example.org) do not
match
| Service is not running with the expected security credential. | Verify that the service credential being presented by the service (first parenthesized name) is a reasonable certificate name for the service. If so, set the GLOBUS_SOAP_MESSAGE_PEER_IDENTITY_KEY attribute on the soap message handle to that identity. For most command-line wsrf tools, this can be done by passing it as an argument to the -z command-line parameter. |
globus_soap_message_module: SOAP Fault
Fault code: Client
Fault string: globus_service_engine_module: Failed to find operation:
{XXXX}YYYY for service: {ZZZZ}BBBB
| The service port type {ZZZZ}BBBB does not contain a {XXXX}YYYY operation. | Verify that the client bindings are built from the same WSDL and XML Schema documents as the service. |
globus_soap_message_module: Failed receiving response
http://widgets.com/WidgetPortType/createWidgetResponse.
ws_addressing: Addressing header is a draft version of WS Addressing:
"http://schemas.xmlsoap.org/ws/2004/03/addressing". This could be a GT version
mismatch, client is GT 4.2.x and response is from GT 4.0.x
server
| The service is running on a container which is using a draft version of the WS-Addressing specification. This was used by GT 4.0.x | Update the service to work with GT 4.2.x or compile your client with GT 4.0.x libraries. |
globus_soap_message_module: Failed sending request
http://widgets.com/WidgetPortType/createWidgetRequest.
globus_xio: The GSI XIO driver failed to establish a secure connection. The
failure occured during a handshake read.
globus_xio: An end of file occurred
| The service container either did not support SSL authentication, or the service container did not trust the client certificate | Consult the service administrator to verify that the service container supports SSL and that your certificate is issued by a certificate authority trusted by the service. |
Table of Contents
The following usage statistics are sent by C WS Core by default in a UDP packet :
On container start
- ip address of container
- container id - random number
- event type - container startup
- list of deployed service names
On container shut down
- ip address of container
- container id - random number
- event type - container shutdown
- list of activated services
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.
B
- building and installing
- Core-only from CVS, Building and Installing
- Core-only from installer, Building and Installing
C
- configuring, Configuring
E
- errors, C WS Core Errors
I
- installing
- Core-only from CVS, Building and Installing
- Core-only from installer, Building and Installing
L
- logging, Logging
S
- security considerations, Security Considerations
T
- testing, Testing