Unsupported Class Version Error

The error:
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file

Explanation:
This happens when you have compiled a jar file with a newer version of Java and executing it with an older version of Java.

The Solution:
Either upgrade that Java version on the executing machine or recompile the code with the correct version.

Invalid Encoding Name in Tomcat 6

Here's an error message you may come across when deploying Globus to Tomcat 6. This error message happens when Tomcat is started.


SEVERE: Parse Fatal Error at line 1 column 40: Invalid encoding name "cp1252".org.xml.sax.SAXParseException: Invalid encoding name "cp1252".

Use the following procedure to correct the error:

1. Change directory to %CATALINA_HOME%\conf
2. Open tomcat-users.xml in a text editor
3. Look at the first line of the file and change encoding='cp1252' to encoding='utf-8'
4. Save the file and restart Tomcat

Correcting Globus Handshake Errors

The Problem:
When Globus-WS is deployed to Tomcat 5.5.x within Windows, a Handshake error is thrown when secure Globus commands are issued. The secure commands run fine in a standalone container but fail when Globus is deployed to Tomcat.

Example:
C:\>counter-client -m conv -z none -s https://192.168.20.120:8443/wsrf/services/Se
cureCounterService

Error: ; nested exception is:
javax.xml.rpc.soap.SOAPFaultException: ; nested exception is:
org.globus.common.ChainedIOException: Authentication failed [Caused by:
Failure unspecified at GSS-API level [Caused by: Handshake failure]]

The Solution:
(Commands are based on JDK 1.5.x)

This is caused when the SSL client does not trust the CA that signed the certificate. The solution is to add the CA certificate as a trustedCA.


1. Create a Java Key Store:

keytool -genkey -alias servercert -keyalg RSA -dname "CN=Your_host_name, OU=yoursite.net, O=your_organization, L=city, ST=state C=country" -keypass changeit -keystore server.jks -storepass changeit

2. Create a PKCS12 Keystore:

keytool -genkey -alias globus -keystore globus.p12 -storetype pkcs12 -keyalg RSA -dname "CN=Your_host_name, OU=yoursite.net, O=your_organization, L=city, ST=state C=country" -keypass changeit -storepass changeit

3. Export your PKCS12 Keystore:
keytool -export -alias globus -file globus.cer -keystore globus.p12 -storetype pkcs12 -storepass changeit

4. Import your PKCS12 Ketstore file into you Java Keystore:

keytool -import -keystore server.jks -alias globus -file globus.cer -v -trustcacerts -noprompt -storepass changeit

5. Import the 3rd Party CA into your Java Keystore as a Trusted CA

keytool -import -keystore server.jks -alias globusCA -file c:\etc\grid-security\certificates\31f15ec4.0 -v -trustcacerts -noprompt -storepass changeit

6. Import the host certificate issued by the 3rd Party CA into your Java Keystore.

keytool -import -keystore server.jks -alias containercert -file c:\etc\grid-security\importcontainercert.pem -v -trustcacerts -noprompt -storepass changeit

Based on the proceedure above, your server.xml file should look like this:

className="org.globus.tomcat.coyote.net.HTTPSConnector"
port="8443" maxThreads="150"
minSpareThreads="25" maxSpareThreads="75"
autoFlush="true" disableUploadTimeout="true"
scheme="https" enableLookups="true"
acceptCount="10" debug="0"
protocolHandlerClassName="org.apache.coyote.http11.Http11Protocol"
socketFactory="org.globus.tomcat.catalina.net.BaseHTTPSServerSocketFactory"
keystoreFile="C:\apache-tomcat-5.5.27\conf\server.jks"
keystorePass="changeit"
cacertdir="c:\etc\grid-security\certificates"
encryption="true"/>

---------------------------------------------------------
The commands change slightly when using JDK 1.6.x.

1. Create a Java Key Store:

keytool -genkeypair -alias servercert -keyalg RSA -dname "CN=Your_host_name, OU=yoursite.net, O=your_organization, L=city, ST=state C=country" -keypass changeit -keystore server.jks -storepass changeit

2. Create a PKCS12 Keystore:

keytool -genkeypair -alias globus -keystore globus.p12 -storetype pkcs12 -keyalg RSA -dname "CN=Your_host_name, OU=yoursite.net, O=your_organization, L=city, ST=state C=country" -keypass changeit -storepass changeit

3. Export your PKCS12 Keystore.

keytool -exportcert -alias globus -file globus.cer -keystore globus.p12 -storetype pkcs12 -storepass changeit

4. Import your PKCS12 Ketstore file into you Java Keystore.

keytool -importcert -keystore server.jks -alias globus -file globus.cer -v -trustcacerts -noprompt -storepass changeit

5. Import the 3rd Party CA into your Java Keystore as a Trusted CA.

keytool -importcert -keystore server.jks -alias globusCA -file c:\etc\grid-security\certificates\31f15ec4.0 -v -trustcacerts -noprompt -storepass changeit

6. Import the host certificate issued by the 3rd Party CA into your Java Keystore.

keytool -importcert -keystore server.jks -alias containercert -file c:\etc\grid-security\importcontainercert.pem -v -trustcacerts -noprompt -storepass changeit

Authentication failed [Caused by: Unknown CA]

This post is in reference to the following Globus Error:

Authentication failed [Caused by: Failure unspecified at GSS-API level [Caused by: Unknown CA]]

This error is generated when the client does not trust the server CA. This error can be corrected by adding the server CA file (.0) to the Globus client's .globus\certificates directory.

This error is also generated when the .0 file is corrupted. You must verify that the md5checksum is correct on both the remote server and local Globus node. Please see the follow link for an example of this procedure.

http://www.globus.org/mail_archive/gt-user/2007/09/msg00103.html

SSTS on Windows

Multiple Windows absolute and relative path names were added to the SSTS jndi-config.xml file, but the service continues to return the following error:

An error has occurred, error message = java.io.EOFException

This leads me to believe the service code needs to be modified in order to support Windows nodes.

Windows Node Errors

The SSTS service has been installed on the Windows node, but I don't think it is compatible with Windows in it's current stage of development. I think the path names need to be modified within the code in order for it to be compatible with Windows. Below is an example of the error message received while trying to connect to the SSTS hosted on a Windows node.

Current Error:
An error has occurred, error message = java.net.ConnectException: Connection timed out: connect

Here's an excerpt from the logs:

Feb 23, 2009 2:48:26 PM org.apache.catalina.loader.WebappClassLoader validateJarFileINFO: validateJarFile(C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\caGridTransfer\WEB-INF\lib\servlet.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
Feb 23, 2009 2:48:28 PM org.apache.axis.utils.JavaUtils isAttachmentSupportedWARNING: Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled.
Feb 23, 2009 2:48:29 PM org.cagrid.transfer.service.TransferServiceImpl INFO: Starting the TransferService ImplementationFeb 23, 2009 2:48:29 PM org.cagrid.transfer.service.TransferServiceImpl INFO: etc path directory = C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\wsrf\WEB-INF\etc/cagrid_TransferService
Feb 23, 2009 2:48:29 PM org.cagrid.transfer.service.TransferServiceImpl

The bold portion of the log is the path that should be corrected in the code. Going forward, I think we should test code on both Linux and Windows.

Succesful DRN Test

The following tests were successfully conducted with the Geisinger SAS server:

1. List files on remote SAMBA share with SST service
2. Upload a SAS file via SST
3. Run SAS program on a remote SAS server
4. Download SAS output file in CSV format via SST
5. View output on client node

Lessons Learned:

The following errors were thrown by the SST service for various reasons:

Command: java -jar caGrid-Transfer-client-1.0.jar list .
Error Message: An error has occurred, error message = org.globus.gsi.GlobusCredentialException: Proxy file (/tmp/x509up_[uid-number]) not found
Explanation: You need to create a proxy before running SST commands. Run the grid-proxy-init command to correct this problem.

Command: java -jar caGrid-Transfer-client-1.0.jar list .
Error message: An error has occurred, error message = java.netSocketException: Connection Reset
Explanation: You client has trust issues with the remote node. Make sure the remote node has your user credentials has been entered into the grid-map file and your signing CA is trusted by the remote node.

Command: java -jar caGrid-Transfer-client-1.0.jar list .
Error message: An error has occurred, error message = java.lang.NullPointerException
Explanation: This means there is no data in the simpleTransfer directory.

Command: java -jar caGrid-Transfer-client-1.0.jar upload [file name]
Error message: An error has occurred, error message = java.io.IOException: Internal Server Error
Explanation: This means the mapped user account is unable to write to the simpleTransfer directory. You will need to create the directory or check the directory permissions to correct this issue.

Order of operation for SST installation:

1. Start Globus Container with the Root user
2. Copy the caGridTransfer.war to $CATALINA_HOME/webapps
3. Run the globus-deploy-gar command on cagrid_TransferService.gar
4. Run the ant command to deploy Globus to Tomcat
5. Shutdown the old Globus instance
6. Start Tomcat with the Globus user (This starts Globus within Tomcat)
7. Verify Globus is listening on the correct ports
8. Run the grid-proxy-init command on the client node
9. Test SST

DRN Notes

DRN Notes:

Current error message:
An error has occurred, error message = java.lang.ClassCastException: org.globus.gsi.gssapi.GlobusGSSContextImpl

Actions Taken:

1.Verified that a valid proxy was created for the SST Client side
2.Verified all Globus user and host certificates were installed with the correct permissions.
3.Checked the grid-mapfile to verify the remote user DN was mapped to a valid user account
4.Created a simpleTransfer directory at the default location. (Permissions may need to be changed – Action for tomorrow)
5.Verified the permissions were set correctly for containercert.pem and containerkey.pem
6.Viewed the Tomcat server.xml to verify the paths for the cert, key, and cacertdir variables were set correctly
7.Decided to do a full service SST redeploy. Currently in progress - Shut down Tomcat and deleted the webapps/caGridTransfer and wsrf directories
8.Remote Admin had to leave during the operation. We will continue the redeploy first thing in the morning.

Next Steps:

1.Start Globus via VDT
2.Run the globus-deploy-gar command on the SST gar file
3.Shutdown VDT Globus
4.Redeploy Globus to Tomcat
5.Start Tomcat
6.Test Transfer

Other Notes:

We were able to generate output with the SAS code and the SAS Template that was provided by Roy.

Dallas Network Issues

• The Tarrant node is back online. The root cause of the problem was the VM failed to restart after a host server reboot. The VM was manually restarted successfully.

• The Dallas node is experiencing slow response times due to network issues that are currently being addressed by the Dallas network team. They are in the process of investigating the root cause of the issue. This issue currently affects the RPDSAdai demo and any data transfers to and from the Dallas node. I was informed that this issue would be corrected by close of business on 01-06-2009.

Update: Globus on Windows

Corrected the following error by setting these variables:

set X509_USER_CERT=C:\Documents and Settings\bubba-gump\.globus\usercert.pem
set X509_USER_KEY=C:\Documents and Settings\bubba-gump\.globus\userkey.pem
set X509_CA_CERT=1234abcd.0
set X509_CERT_DIR=C:\etc\grid-security\certificates

The corrected error:

C:\gt4\bin>grid-proxy-init
Your identity: O=Grid,CN=bubba-gump
Enter GRID pass phrase for this identity:
Creating proxy, please wait...
Proxy verify failed: Unable to load CA ceritificates


New Error Message:

C:\gt4\bin>grid-proxy-init
Your identity: O=Grid,CN=bubba-gump
Enter GRID pass phrase for this identity:
Creating proxy, please wait...
Proxy verify failed: "/O=Grid/CN=bubba-gump" violates the signing policy defined for CA "/O=xxx/OU=zzz/OU=szzzz/CN=xxxx
Simple CA" in file "C:\etc\grid-security\certificates\1234abcd.signing_policy"
C:\gt4\bin>


Next step:
Create a new certificate request with the correct subject line. This should fix the security issue.

Globus on Windows

I'm able to run the Java WSCore container with no security, but I get an error when I try to start the container with a certificate. The next step will be to recreate the Linux based certificate directory structure on the Windows machine and troubleshoot from there. I will also try to load the ca-setup file from the internal grid machine.

FAILURE:
C:\gt4\bin>grid-proxy-init -debugFiles used: proxy : C:\DOCUME~1\bubba-gump\LOCALS~1\Temp\x509up_u_bubba-gump user key : C:\Documents and Settings\bubba-gump\.globus\userkey.pem user cert : C:\Documents and Settings\bubba-gump\.globus\usercert.pemYour identity: xxx xxx xxx Enter GRID pass phrase for this identity:Using 512 bits for private keyCreating proxy, please wait...Proxy verify failed: Unable to load CA ceritificatesjava.lang.Exception: Unable to load CA ceritificates at org.globus.tools.ProxyInit.verify(ProxyInit.java:131) at org.globus.tools.DefaultProxyInit.verify(ProxyInit.java:595) at org.globus.tools.ProxyInit.createProxy(ProxyInit.java:225) at org.globus.tools.ProxyInit.main(ProxyInit.java:530) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:114) at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:41)C:\gt4\bin>globus-start-container[JWSCORE-114] Failed to start container: [JWSCORE-200] Container failed to initialize [Caused by: [JWSSEC-248] Secure container requires valid credentials. No container descriptor file configured and default proxy not found. Run grid-proxy-init to create default proxy credential.]

SUCCESS:
C:\gt4\bin>globus-start-container -nosecStarting SOAP server at http://127.0.0.1:8080/wsrf/services/
With the following services:
[1]: http://127.0.0.1:8080/wsrf/services/AdminService[2]: http://127.0.0.1:8080/wsrf/services/AttachmentTestService[3]: http://127.0.0.1:8080/wsrf/services/AuthzCalloutTestService[4]: http://127.0.0.1:8080/wsrf/services/ContainerRegistryEntryService[5]: http://127.0.0.1:8080/wsrf/services/ContainerRegistryService[6]: http://127.0.0.1:8080/wsrf/services/CounterService[7]: http://127.0.0.1:8080/wsrf/services/DeployService[8]: http://127.0.0.1:8080/wsrf/services/JWSCoreVersion[9]: http://127.0.0.1:8080/wsrf/services/LoggingService[10]: http://127.0.0.1:8080/wsrf/services/ManagementService[11]: http://127.0.0.1:8080/wsrf/services/NotificationConsumerFactoryService[12]: http://127.0.0.1:8080/wsrf/services/NotificationConsumerService[13]: http://127.0.0.1:8080/wsrf/services/NotificationTestService[14]: http://127.0.0.1:8080/wsrf/services/PersistenceTestSubscriptionManager[15]: http://127.0.0.1:8080/wsrf/services/QueryTestService[16]: http://127.0.0.1:8080/wsrf/services/RPParamTestService[17]: http://127.0.0.1:8080/wsrf/services/SAMLAuthzTestService[18]: http://127.0.0.1:8080/wsrf/services/SampleAuthzService[19]: http://127.0.0.1:8080/wsrf/services/SecureCounterService[20]: http://127.0.0.1:8080/wsrf/services/SecurityTestService[21]: http://127.0.0.1:8080/wsrf/services/ShutdownService[22]: http://127.0.0.1:8080/wsrf/services/SubscriptionManagerService[23]: http://127.0.0.1:8080/wsrf/services/TestAuthzService[24]: http://127.0.0.1:8080/wsrf/services/TestEnumService[25]: http://127.0.0.1:8080/wsrf/services/TestLoginModuleService[26]: http://127.0.0.1:8080/wsrf/services/TestParamAuthzService[27]: http://127.0.0.1:8080/wsrf/services/TestRPCService[28]: http://127.0.0.1:8080/wsrf/services/TestService[29]: http://127.0.0.1:8080/wsrf/services/TestServiceRequest[30]: http://127.0.0.1:8080/wsrf/services/TestServiceWrongWSDL[31]: http://127.0.0.1:8080/wsrf/services/Version[32]: http://127.0.0.1:8080/wsrf/services/WidgetNotificationService[33]: http://127.0.0.1:8080/wsrf/services/WidgetService[34]: http://127.0.0.1:8080/wsrf/services/gsi/AuthenticationService

Troubleshooting Northrop Grumman Node

Troubleshooting the Northrop Grumman Node. I will be on site at 10am working with Marcelo on solving this issue.

530-globus_xio_gssapi_ftp.c:globus_l_xio_gssapi_ftp_decode_adat:846:
530-Authentication Error
530-GSS Major Status: Authentication Failed
530-accept_sec_context.c:gss_accept_sec_context:183:
530-SSLv3 handshake problems
530-globus_i_gsi_gss_utils.c:globus_i_gsi_gss_handshake:890:
530-Unable to verify remote side's credentials
530-globus_i_gsi_gss_utils.c:globus_i_gsi_gss_handshake:863:
530-SSLv3 handshake problems: Couldn't do ssl handshake
530-OpenSSL Error: s3_srvr.c:2010: in library: SSL routines, function SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
530-globus_gsi_callback.c:globus_gsi_callback_handshake_callback:531:
530-Could not verify credential
530-globus_gsi_callback.c:globus_i_gsi_callback_cred_verify:681:
530-Can't get the local trusted CA certificate: Cannot find issuer certificate for local credential with subject: /O=HealthGrid/OU=Globus Toolkit/OUxxxx/OU=xxxxx/CN=xxxx
530 End.

3rd Party Certificates within Globus

Verisign Certificates within Globus

grid-proxy-init ERROR: Couldn't verify the authenticity of the user's credential to generate a proxy from.

grid_proxy_init.c:1070:globus_gsi_cred_handle.c:globus_gsi_cred_verify_cert_chain:1733:
Error verifying credential: Failed to verify credential
globus_gsi_callback.c:globus_i_gsi_callback_create_proxy_callback:442:
Could not verify credential
globus_gsi_callback.c:globus_i_gsi_callback_cred_verify:681:
Can't get the local trusted CA certificate: Cannot find issuer certificate for local credential with subject: DATA-REMOVED-BY-DAN

GridFTP Error:

error: globus_ftp_client_state.c:globus_l_ftp_client_connection_error:4217:
the server responded with an error
530 530-globus_xio: Authentication Error
530-globus_gsi_callback_module: Could not verify credential
530-globus_gsi_callback_module: Error with signing policy
530-globus_gsi_callback_module: Error in OLD GAA code: CA policy violation:

Solution Summary:

The certificates were extracted using the Portecle application in PEM format. The entire certificate chain should be used in each hash file. Remove the private key data from the file.

The commands:

openssl x509 -issuer_hash -in [file_name].pem was used to determine the hash name the file should be named after.

openssl x509 -issuer -in [file_name].pem was used to determine the access_id_CA that should be used in the signing policy.

openssl x509 -subject -in [file_name].pem was used to determine the cond_subjects that should be used in the signing policy.

The step by step solution:

1. Export your certificate with Internet Explorer using the Personal Information Exchange PKCS12 option.

2. Check the, “Include all certificates and certificate paths” box. NOTE: This should be the only option checked.

3. Upload the exported certificates to the Globus node. (Root, Intermediate, and Private)

4. Use Portecle to view the exported certificates. Portcle is started using the following command: java -jar portecle.jar

5. Right click on the certificate, then use the PEM Encoded option to export private key and public key certificate within Portecle.

6. Remove the private key data from the PEM file that was created.

7. Create a hash name for the PEM file that was created using the following command:

openssl x509 -issuer_hash -in [file_name].pem was used to determine the hash name the file should be named after.
openssl x509 -issuer -in [file_name].pem was used to determine the access_id_CA that should be used in the signing policy.
openssl x509 -subject -in [file_name].pem was used to determine the cond_subjects that should be used in the signing policy.

openssl x509 -in yourfile.pem -noout -hash

8. Rename the file to the hash number displayed in the following format: hash.0

9. .Manually create a signing policy named (hash.signing_policy)

10. Copy the new files to /etc/grid-security/certificates

11. Create a duplicate copy of the hash.0 file for the Issuer_Hash and the hash. Example: awd2dq.0 7847a3s.0 ( There should be two hash files that contain the same certificate chain. Only the names are different)

12. Create signing policy files for each hash file based on Intermediate and Root certificates.

x509 Issue

• Exported CDC private key and certificates to the testing node.
• Tested the certificates using the issuer_hash
• Created a new usercert.pem file from a certificate that used the "strong protection" option
• Removed the Root certificate from the TRUSTED_CA and tested using the Intermediate certificate
• Named Intermediate certificate based on the issuer_hash

Results:

ERROR: Couldn't verify the authenticity of the user's credential to generate a proxy from.

grid_proxy_init.c:1070:globus_gsi_cred_handle.c:globus_gsi_cred_verify_cert_chain:1733:
Error verifying credential: Failed to verify credential
globus_gsi_callback.c:globus_i_gsi_callback_create_proxy_callback:442:
Could not verify credential
globus_gsi_callback.c:globus_i_gsi_callback_cred_verify:681:
Can't get the local trusted CA certificate: Cannot find issuer certificate for local credential with subject: DATA-REMOVED-BY-DAN

x509 Certificates

Deleted the namespaces file from the certificates directory. (This will be recreated later)
Modified the cond_subjects parameter of the root signing policy

Results:
The system still creates a proxy, but fails to create a proxy when the -verify switch is used.

Researching the current error message:

error: globus_ftp_client_state.c:globus_l_ftp_client_connection_error:4217:
the server responded with an error
530 530-globus_xio: Authentication Error
530-globus_gsi_callback_module: Could not verify credential
530-globus_gsi_callback_module: Error with signing policy
530-globus_gsi_callback_module: Error in OLD GAA code: CA policy violation:
530 End.

Next steps:
Try using the issuer_hash for the root and hash for the intermediate certificates.
View the CDC certificate in Portecle to make sure there are no changes in the subject lines
Test transfers between 1001 and 1003 nodes
Contact Ron Price about a possible solution. I discovered an old listserv message where he was having the same problem back in 2004.
http://www.globus.org/mail_archive/discuss/2004/02/msg00112.html

Unknown CA Error: Fix

Globus was recently reinstalled on the Ubuntu node. Instead of installing the certificates in the /etc/grid-security directory, I choose to use the non-root install and install the certificates in the $GLOBUS_LOCATION/etc directory.

I received the following error in the $GLOBUS_LOCATION/var/container.log file when I tried to start the Globus container:

Remote exception was ;nested exception is: org.globus.common.ChainedIOException: Authentication failed [Caused by:Failure unspecified at GSS-API level [Caused by: Unknown CA]]

I knew the certificates were good, but it seemed like Globus was unable to locate the installed certificates. After researching the issue, I came across Globus Bug# 4303.
Link: http://bugzilla.globus.org/globus/show_bug.cgi?format=multiple&id=4303

Based on the information in the Bug Report, I discovered that Globus was looking for the certificates in the default, /etc/grid-security/certificates directory. To correct the problem I created two symbolic links. The first was a link from $GLOBUS_LOCATION/etc to /etc/grid-security. The second was a link from $GLOBUS_LOCATION/etc/certificates to $GLOBUS_LOCATION/TRUSTED_CA.

After creating the links, the Globus container started up.

Postgres Errors

The Postgres database on the staging node was failing to start the postmaster due to a recent IP address change. I updated the postgresql.conf file to reflect the recent IP change. Postgres started fine after the configuration file was modified.
Postgres version: 8.1
Original Postgres Error: autovacuum not started because of misconfiguration
Fix: Modified the /var/lib/pgsql/data/postgresql.conf


Tested 100+ MB file GridFTP and RFT file transfers with Anurag.

Container issues on 1005

Globus node 1005 is failing to start the Globus container. I am currently troubleshooting the following error on node 1005:

: 55: ==: unexpected operator
.................................. ^[[31m*^[[39;49m
### 2008-06-24 10:09:56 vdt-control(do_init) enabling the init service 'globus-ws'
### 2008-06-24 10:09:56 vdt-control(do_init) starting globus-ws: /etc/init.d/globus-ws start
### 2008-06-24 10:09:56 vdt-control(system) /etc/init.d/globus-ws start
[: 55: ==: unexpected operator
WARNING: It seems like the container died directly
Please see $GLOBUS_LOCATION/var/container.log for more information
Starting Globus container. PID: 7047
### 2008-06-24 10:10:06 vdt-control(do_init) starting 'globus-ws' failed: 1024
### 2008-06-24 10:10:06 vdt-control(clean_up) all done

Make that two non-functional OD boxes

Well, I got the Ubuntu box set up for running Globus and Tomcat... downloaded and built OGSA-DAI, deployed it to tomcat and the Globus container... created a resource, deployed the resource, and tried to run a SQLClient against the resource... and got this..

Exception in thread "main" uk.org.ogsadai.client.toolkit.exception.RequestCompletedWithErrorException: [1208374501596:4] uk.org.ogsadai.client.toolkit.REQUEST_COMPLETED_WITH_ERROR : ogsadai-1195888958d
at uk.org.ogsadai.client.toolkit.resource.BaseDataRequestExecutionResource.checkSynchronousExecutionIsComplete(Unknown Source)
at uk.org.ogsadai.client.toolkit.resource.BaseDataRequestExecutionResource.execute(Unknown Source)
at uk.org.ogsadai.client.toolkit.resource.BaseDataRequestExecutionResource.execute(Unknown Source)
at SQLClient.executePipeline(SQLClient.java:167)
at SQLClient.main(SQLClient.java:290)

It is the same error I was getting with the second SuSE box that I gave up on... let me tell you what this error does not tell me:

* I do not know what the error really was. Because I don't know what error "ogsadai-1195888958d" is and there is no documentation for it.
* This error does not tell me what broke.
* I am apparently incapable of turning on the logging so that better errors are thrown closer to the problem source.

After narrowing down that other things work (The DRER is accessible via tomcat, MySQL is up and running, the logins.txt file has all the appropriate information, the jdbc file I used worked during the data creation, and the MySQLDataResource file looks to be correct) I have no idea what is broken. I mean maybe something was written wrong in the MYSQL resource, but I thought I fixed it and restarted tomcat and it should work and it doesn't.

I think I am going to have to get with the Edinburgh folks early tomorrow, start up a webex and just have them look at the boxes to see what was mis-configured or allow them to try setting up a resource and get the logging working... because I am running out of ideas that aren't just pure churn. I will also talk to them about making a more robust resource making client that will test resources being created for validity and connectivity before being deployed.