As GridWay relies on Globus services, it is assumed that a Globus grid infrastructure has been installed and configured.
gwuser@gridway:~$ grid-proxy-init || voms-proxy-init Your identity: /DC=es/DC=irisgrid/O=ucm/CN=gridway.user Enter GRID pass phrase for this identity: Creating proxy ......................................... Done Your proxy is valid until: Wed Dec 16 00:42:41 2009
You can perform the following tests to verify your Globus pre-WS installation, and to ensure that it will work with GridWay. Here we assume you have some resource (worker node front-end) where the Globus container is already initialized (in this case is gilda-ce.rediris.es
please change where appropriate for your tests):
gwuser@gridway:~$ globusrun -a -r gilda-ce.rediris.es GRAM Authentication test successfulThen everything is working as expected. If on the contrary you get
GRAM Authentication test failure: connecting to the job manager failed. Possible reasons: job terminated, invalid job contact, network problems, ...
then probably is because you are trying to access a computing element not properly configured or unreachable.
gwuser@gridway:~$ globus-job-run gilda-ce.rediris.es /bin/uname -a Linux gilda-ce.rediris.es 2.6.9-89.0.16.EL #1 Tue Nov 3 21:09:04 CST 2009 i686 athlon i386 GNU/LinuxYou should see the complete output of the
uname
command. But quite often we found that the errorGRAM Job submission failed because the job manager failed to open stderr (error code 74)
appears. The reason is probably that either the GLOBUS_TCP_PORT_RANGE variable has not been set to incoming opened ports, or the globus-hostname
command does not return a full qualified domain name accessible from outside.
gwuser@gridway:~$ globus-url-copy -v file:///etc/hostname gsiftp://gilda-ce.rediris.es/tmp/test_`hostname -f` Source: file:///etc/ Dest: gsiftp://gilda-ce.rediris.es/tmp/ hostname -> test_gridway.dacya.ucm.esConversely you might retrieve your data back to your system:
gwuser@gridway:~$ globus-url-copy -v gsiftp://gilda-ce.rediris.es/tmp/test_`hostname -f` file:///tmp/test_`hostname -f` Source: gsiftp://gilda-ce.rediris.es/tmp/ Dest: file:///tmp/ test_gridway.dacya.ucm.esThe contents of files
/etc/hostname
and /tmp/test_gridway.dacya.ucm.es
should be identical.You can perform the following tests to verify your Globus WS installation, and to ensure that it will work with GridWay:
Note |
---|
Change localhost to the name of the host your want to test. |
$ globusrun-ws -submit -F localhost -s -c /bin/uname -aYou should see the output of the
/bin/uname -a
command (along with other information about submission progress).$ globus-url-copy file:///etc/hosts gsiftp://localhost/tmp/hosts1 $ globus-url-copy gsiftp://localhost/tmp/hosts1 file:///tmp/hosts2The contents of files /etc/hosts, /tmp/hosts1 and /tmp/hosts2 should be identical.
$ wsrf-query -s https://localhost:8443/wsrf/services/DefaultIndexServiceYou should see a lot of information in XML format.
Note |
---|
XML documents from wsrf-query should not contain any DEBUG messages. SOAP Message Logging for the client tools has to be disabled in $GLOBUS_LOCATION/log4j.properties . |
If a binary distribution of the Globus Toolkit is installed, you may be required to manually install globus_core (used to detect the compiler and platform settings of the computer that the Toolkit is installed on). The following command can be used to perform this operation:
$ $GLOBUS_LOCATION/sbin/gpt-build -nosrc <flavor>
More information about this procedure is available (here).
GridWay is distributed as a source package, required software to compile it:
sudo
command (only required for multiple-user mode)Optional
You can install GridWay in two different ways:
Next sections describe in detail the installation process for these two cases.
In this scenario, GridWay is installed by each end-user in his client host.
Login as your user account and follow these steps:
$HOME
directory gridway_5.6.1
directory:$ tar xzf gridway_5.6.1.tgz $ cd gridway_5.6.1
$ source $GLOBUS_LOCATION/etc/globus-devel-env.shor
$ . $GLOBUS_LOCATION/etc/globus-devel-env.cshdepending on the shell you are using.
./configure OPTIONSPossible options for configure are:
Option | Description |
---|---|
--prefix | Sets final GridWay installation dir. Defaults to /usr/local/gw. |
--with-flavor=flavor | The configure script will try to detect the flavor (eg. gcc32dbg) of the Globus toolkit installed in your system. However, if the configure script is not able to detect it, specify it with this option. |
--disable-drmaa | Don't build drmaa support. Default is enabled. |
--enable-drmaa-ruby | Build ruby drmaa support. Default is disabled. |
--enable-nordugrid | Build support for nordugrid. Default is disabled. |
--enable-ldap | Build ldap support. Default is disabled. |
--enable-ssh | Build ssh support. Default is disabled. |
--disable-prews | Don't build pre-web-services support. Default is enabled. |
--disable-ws | Don't build web-services support. Default is enabled. |
--enable-jsdl | Does compile jsdl support. Default is enabled. Disabled for GT builds. |
--disable-gridftp | Does not compile gridftp mad. Default is enabled. |
--with-db=path_to_db | Specify the Berkeley Database path to build accounting support. |
--enable-globus-scheme | Install GridWay inside $GLOBUS_LOCATION . Default is disabled. Enabled for GT builds. |
--with-tests | Install tests |
$ make
$ make install
$GW_LOCATION/ | +--- bin/ executables | +--- etc/ gwd.conf and job_template.default configuration files | +--- share/ include examples and [Optionally] documentation | +--- include/ header files | +--- lib/ compiled libraries | +--- libexec/ wrapper and monitor scripts | +--- test/ test suite [Optional] | +--- var/ lock, port and log files | +--- xml_schema/ schema for xml output validation
In this scenario, the installation of GridWay is performed by the system manager and the users are able to submit, control and monitor their jobs from a front-end (GridWay server host) or from client hosts, which may not require a GridWay/Globus installation. This means that there is one GridWay installation for each organization that provides support for multiple intra-organization users.
Important |
---|
The instructions here described assumes that you are going to install GridWay in its own directory ($GW_LOCATION , e.g. /opt/gridway/5.6.1 ). Also it is assumed that the installation, configuration and service execution will be performed by an special account (gwadmin ).GridWay can be also installed within the Globus Toolkit tree. To do this you have to use the flag --enable-globus-scheme when calling configure script and set the prefix to $GLOBUS_LOCATION . In this case, the gwadmin user will be the user account that performed the Globus Toolkit installation. When you install it this way you also have to note that $GW_LOCATION/var and $GW_LOCATION/etc directories will be $GLOBUS_LOCATION/var/gridway and $GLOBUS_LOCATION/etc/gridway . |
Note that GridWay daemon SHOULD NOT be run as root. Only part of the installation will require privileged access. |
Login as root account and follow the next steps:
<gwgroup>
. We recommend to create a new group (call gwusers
, for example), and assure that all GridWay user accounts are members of this new group.<adminuser>
, can be an existing administrative login or a new login. We recommend creating a new account for the GridWay administration user (call gwadmin
, for example). This account will own all of the files in the GridWay installation, all of the daemons in the GridWay execution and it can be used to configure GridWay once it is installed. Primary group of <adminuser>
should be <gwgroup>
./opt/gridway
directory# tar xzf gridway_5.6.1.tgz # chown -R gwadmin:gwusers /opt/gridway # chmod 755 /opt/gridwayBecome GridWay administrator user, and change to
gridway_5.6.1
directory:# su gwadmin $ cd gridway_5.6.1
$ source $GLOBUS_LOCATION/etc/globus-devel-env.shor
$ . $GLOBUS_LOCATION/etc/globus-devel-env.cshdepending on the shell you are using.
./configure OPTIONS
$ make
$ make install
$GW_LOCATION/ | +--- bin/ executables | +--- etc/ gwd.conf and job_template.default configuration files | +--- share/ Include examples and [Optionally] documentation | +--- include/ header files | +--- lib/ compiled libraries | +--- libexec/ wrapper and monitor scripts | +--- test/ test suite [Optional] | +--- var/ lock, port and log files | +--- xml_schema/ schema for xml output validation
/etc/sudoers
file of the sudo
command should include the following... # User alias specification Runas_Alias GWUSERS = %gwusers # GridWay entries gwadmin ALL=(GWUSERS) NOPASSWD: /opt/gridway/5.6.1/bin/gw_em_mad_prews * gwadmin ALL=(GWUSERS) NOPASSWD: /opt/gridway/5.6.1/bin/gw_em_mad_ws * gwadmin ALL=(GWUSERS) NOPASSWD: /opt/gridway/5.6.1/bin/gw_em_mad_ssh * gwadmin ALL=(GWUSERS) NOPASSWD: /opt/gridway/5.6.1/bin/gw_tm_mad_ftp * gwadmin ALL=(GWUSERS) NOPASSWD: /opt/gridway/5.6.1/bin/gw_tm_mad_dummy * gwadmin ALL=(GWUSERS) NOPASSWD: /opt/gridway/5.6.1/bin/gw_tm_mad_ssh * gwadmin ALL=(GWUSERS) NOPASSWD: /opt/globus/4.2.1/bin/grid-proxy-info *
Usually sudo clears all environment variables for security reasons. However MADs need the GW_LOCATION and GLOBUS_LOCATION (and GLOBUS_TCP_PORT_RANGE if existing) variables to be set. To preserve those variables in the MAD environment, add the following line to your “sudoers” file:
Defaults>GWUSERS env_keep="GW_LOCATION GLOBUS_LOCATION GLOBUS_TCP_PORT_RANGE"
The following line shouldn't be in the sudoers file, otherwise gridway could not use sudo as it will ask for a tty:
Defaults requiretty
Please refer to the sudo manual page for more information. Additionally you can configure your drivers environment by using the gwrc
interface (see Section “MAD Environment Configuration”). To test the sudo
command configuration try to execute a MAD as a user in the gwusers
group, for example:
$ sudo -u gwuser /opt/gridway/5.6.1/bin/gw_em_mad_prewsFollowing previous steps, the end-users must login to the GridWay server host to be able to execute GridWay commands and use the DRMAA libraries.
Additionally, client hosts, that are not required to have GridWay/Globus installed, could be deployed to remotely interface to the GridWay server host. In such a case, user accounts and home directories must be shared between the GridWay server and the client hosts, via for example NIS and NFS; and $GW_LOCATION
directory should be readable on all client hosts. The $GW_LOCATION
directory may be available via for example NFS by exporting $GW_LOCATION
from GridWay server, creating the directory in the client hosts, changing its ownership to gwadmin:gwusers
and mounting the $GW_LOCATION
directory exported by the GridWay server on the $GW_LOCATION
of the client hosts.
Following those steps, a user logged in a client hosts is able to interface to the GridWay daemon in the GridWay server host. However, the grid-proxy-init
command must be executed in the server host in order to create a proxy by, for example, executing:
$ ssh <GridWay server> grid-proxy-init
GridWay has been run on the following platforms:
Problems have been reported on Fedora Core platforms when using 32 bit JSDK binaries on AMD64 architectures.
No known issues.
No known issues. Tested on Mac OS X 10.4 (Tiger).
No known issues.
GridWay should run smoothly on any linux based distribution and it is also likely to work on any unix based operating system, although it just have been tested in the aforementioned platforms.