FAQs

This page is currently for staff only. When it's linked to the main site, it will be made accessible by all users.

Platforms

The Development Kit and Campus Grid Toolkit (CGT) are supported on specific platforms, as described inSupport platforms in the preface of the Development Kit Installation guide. The Development Kit and CGT may also work on other platforms,as described in the FAQs below.

Installation on Ubuntu

Ubuntu users may find:

• installation of Development Kit or CGT fails,
• sh does not recognize the bash command 'source'
• sh does not recognize short hand 'test' syntax

This problem can be caused by the Development Kit installer assuming that /bin/sh is /bin/bash (this is the case with most Linux distributions). However, in the case of Ubuntu /bin/sh is /bin/dash. The following webpage describes how to change shells: Ubuntu help page.

Postgres problems: Database connection test to localhost:5432 failed

You may encounter the following error message when installing the Development Kit or Campus Grid Toolkit:

Database connection test to localhost:5432 failed

There are three potential causes:

1. If SELinux is enabled, this can cause the problem connecting to localhost.
2. This problem may be caused by Java 1.6u13. If you are running this version of Java, try using a different version.
3. The Postgres server may be listening on IPV6 rather than IPV4. If this is the case, edit postgres/data/postgresql.conf and add the line listen_address='*'.

Postgres problems: binaries not available

You may experience the following error message during installation of the Development Kit or Campus Grid Toolkit:

Sorry, there are no Postgres binaries available for your platform at the OMII repository. Exiting. at ./OMIIpostgresInstall1.pl line 84.

Different problems may lead to this error. We suggest following this procedure:

1. Determine whether you need to install Postgres. If you do not intend to use AHE or OGSA-DAI with the Development Kit, then you do not need to install Postgres so there is no need to rectify the problem.
2. The problem may be caused by the lack of support for Postres binaries on your platform. If this is the cause, install Postgres on a supported platform and use it with your installation of the Development Kit or Campus Grid Toolkit (see the page Installing PostgreSQL on Mac OS X found in the Further information section of the Server Installation chapter of the Installation guide. Despite the page's title, the instructions are not only applicable to Mac OS X)).
3. The problem may be caused because you are installing as root. Try installing as non-root to rectify the problem.
4. If none of the above solutions work, contact OMII-UK through the helpdesk or by sending an email to support

Note that there are known issues related to building re-locatable postgress binaries - the solution is to build postgres from source (i.e. the same as recommended in step 2 above)

Connecting OMII-UK software to the outside world

How do I use the Development Kit with firewalls?

There are a number of general considerations to be taken into account when using the Development Kit with a firewall.

Firewalls may exist at the following levels:

• User's machine, e.g. Windows firewall
• Departmental level
• Corporate or Company level
• Special filters used by ISP (Internet Service Provider) to block, e.g. virus attacks

As a user, your machine-level firewall ‘’may’’ be under your control, but you should consult a Systems Administrator to check whether departmental, corporate or ISP-level firewalls are present, since these may interfere with your use of the Development Kit. For example, does access need to be enabled to your machine from the external network?

When gaining access through a firewall, you will need to know the ports that the Development Kit uses. The default ports are listed below, but please note that you may have elected to use non-default options when installing the Development Kit.

How do I send jobs to NGS (Globus) nodes through a GridSAM server?

The NGS has a GridSAM service hosted at the Oxford e-Research Centre and provides access to the Oxford PBS cluster via their Globus service. In order to submit jobs through GridSAM, as a user, to this resource the following is firstly required:

• A GridSAM client installation
• A MyProxy client installation
• A valid UK e-Science certificate

Please see the documentation regarding installation of the GridSAM client and configuration with an e-Science certificate _link_. For a MyProxy client, either an installation of Globus or the Java CoG Kit is suggested. Alternatively, the NGS provide a proxy certificate upload tool, accessible through a Java-enabled browser. You can find more details, and access to the tool, here.

Once this has been achieved, prior to job submission, the following is required and covered in the next sections:

• Upload of a valid proxy certificate to a MyProxy service secured against a username and password. This proxy certificate will enable the GridSAM service to submit jobs to the NGS Globus resource on your behalf
• Specification of proxy credential details to access that proxy within the JSDL. This informs the GridSAM service where and how to obtain your proxy certificate.
• Destroy the proxy certificate on the MyProxy service. It is also a good idea to destroy the uploaded proxy certificate once the job (and anything else that depends on it) has completed.

Upload of a valid proxy certificate to a MyProxy service

Use of the MyProxy service at myproxy.ngs.ac.uk is strongly recommended. For example, using the Java CoG Kit, and assuming valid e-Science credentials installed in the user's .globus directory:

$COG_INSTALL_PATH/bin/grid-proxy-init

This will generate a temporary proxy certificate which will be uploaded, and a password may be requested to the installed e-Science credential.

$COG_INSTALL_PATH/bin/myproxy -S -l myproxy_username
    -h myproxy.ngs.ac.uk put

This will upload the generated proxy certificate to the myproxy.ngs.ac.uk MyProxy service under the myproxy_username username. A password will be requested to secure the credential under the myproxy_username, and another password may requested to access the installed e-Science credential to validate the action.

Specification of proxy credential details within the JSDL

To inform the GridSAM service where to obtain the proxy certificate, the following needs to be included in the JSDL (as a child of the JobDefinition element):

<myproxy:MyProxy xmlns:myproxy="urn:gridsam:myproxy">
    <myproxy:ProxyServer>myproxy.ngs.ac.uk</myproxy:ProxyServer>
    <myproxy:ProxyServerDN>/C=UK/O=eScience/OU=CLRC/L=RAL/CN=myproxy.ngs.ac.uk/E=sct-certificates@stfc.ac.uk</myproxy:ProxyServerDN>
    <myproxy:ProxyServerPort>7512</myproxy:ProxyServerPort>
    <myproxy:ProxyServerUserName>myproxy_username</myproxy:ProxyServerUserName>
    <myproxy:ProxyServerPassPhrase>myproxy_password</myproxy:ProxyServerPassPhrase>
    <myproxy:ProxyServerLifetime>10</myproxy:ProxyServerLifetime>
</myproxy:MyProxy>

Where each attribute is the following:

• ProxyServer: the hostname of the MyProxy service to use
• ProxyServerDN: the Distinguished Name (DN) of the certificate used to secure the MyProxy service
• ProxyServerPort: the port number for the MyProxy Service (default is 7512)
• myproxy_username & myproxy_password: the username and password used to secure the proxy certificate when it was uploaded to the MyProxy service
• ProxyServerLifetime: the expected lifetime of the proxy certificate, given in hours

When considering data that requires the proxy credential to access (for input and output staging purposes), the above 'myproxy' element can be included within JSDL DataStaging elements. For example, for an input file required by the job:

<DataStaging>
    <FileName>input.txt</FileName>
    <CreationFlag>overwrite</CreationFlag>
    <Source>
        <URI>gsiftp://ngs.oerc.ox.ac.uk/data/input.file</URI>
    </Source>
    <ac:Credential xmlns:ac="http://schemas.ogf.org/hpcp/2007/11/ac">
        <myproxy:MyProxy xmlns:myproxy="urn:gridsam:myproxy">
             <myproxy:ProxyServer>myproxy.ngs.ac.uk</myproxy:ProxyServer>
            <myproxy:ProxyServerDN>/C=UK/O=eScience/OU=CLRC/L=RAL/CN=myproxy.ngs.ac.uk/E=sct-certificates@stfc.ac.uk</myproxy:ProxyServerDN>
            <myproxy:ProxyServerPort>7512</myproxy:ProxyServerPort>
            <myproxy:ProxyServerUserName>myproxy_username</myproxy:ProxyServerUserName>
            <myproxy:ProxyServerPassPhrase>myproxy_password</myproxy:ProxyServerPassPhrase>
            <myproxy:ProxyServerLifetime>10</myproxy:ProxyServerLifetime>
        </myproxy:MyProxy>
    </ac:Credential>
</DataStaging>

This ensures that the specified proxy credential will be obtained from the MyProxy service and used for authenticating with the GridFTP service (on ngs.oerc.ox.ac.uk) to access the file data/input.file in the certificate owner's directory on the Oxford resources.

Additional (different) MyProxy credentials for other GridFTP resources can be specified in this way within other DataStaging elements.

Prior to submitting the job, this input file can be uploaded to the location above by using the Java CoG Kit, for example:

$COG_INSTALL_PATH/bin/globus-url-copy file:///home/user/input.file gsiftp://ngs.oerc.ox.ac.uk/data/input.file

Submitting the JSDL Job to NGS GridSAM and Monitoring

Once this has been specified within the JSDL, along with the executable and data requirements for the job itself, it can be submitted to the NGS GridSAM service e.g.:

./gridsam-submit -s https://gridsam.oerc.ox.ac.uk:18443/gridsam/
    services/gridsam -j myjsdl.jsdl

Which will return a unique ID for the job as usual. The job can then be monitored as normal, using e.g.:

./gridsam-status -s https://gridsam.oerc.ox.ac.uk:18443/gridsam/
    services/gridsam -j <the_unique_job_id>

Destroy the proxy certificate on the MyProxy service

It is recommended that the uploaded proxy certificate should be destroyed following the job's completion (if it is not going to used for any other immediate purpose). For example, using the Java CoG Kit:

$COG_INSTALL_PATH/bin/myproxy -S -l myproxy_username
    -h myproxy.ngs.ac.uk destroy