Back to Documentation | English Version

Guías para la instalación de Globus Toolkit 4 (Linux)

Versión 1.0 - 07/06/2006

GuiaInstalacionGlobus.doc (596 KB)

1 Introducción. 4

1.1 Propósito y alcance de este documento. 4

1.2 Definiciones de términos y abreviaturas 4

2 Conceptos generales 6

2.3 WSRF y Web Services Container 6

3 Instalación de Globus 8

4 Configuración posterior 25

4.1 Lanzar el container mediante un script en /etc/init.d. 25

4.2 Lanzar el container automáticamente en el inicio. 26

5 Herramientas recomendadas 26

1 Introducción

1.1 Propósito y alcance de este documento

Este documento describe los pasos a seguir para instalar el Globus Toolkit 4. Globus Toolkit 4 consiste en un conjunto de herramientas que permiten implementar servicios y funcionalidades necesarias para construir un grid.

Este documento no realiza presunciones respecto de software ya instalado, excepto por aquellas herramientas indicadas expresamente en la sección de prerrequisitos.

1.2 Definiciones de términos y abreviaturas

Los siguientes términos y abreviaturas son utilizados en el presente documento:

Término o Abreviatura	Definición
GT	Globus Toolkit, cuando la sigla sea seguida por un número, éste se referirá a la versión
GRAM	Globus Resource Allocation and Management
GSI	Grid Security Infrastructure
MDS	Monitoring and Discovery Service
GRIS	Grid Resource Information Service
GIIS	Grid Index Information Service
RFT	Reliable File Transfer
RLS	Replica Location Service
OGSA	Open Grid Services Architecture
SOAP	Simple Object Access Protocol
XML	Extensible Markup Language
WS	Web Service
WSRF	Web Services Resource Framework
JDBC	Java Database Connectivity
CA	Certificate Authority (entidad certificadora)
PEM	Privacy-Enhanced Mail (referido a encriptación)
W3C	World Wide Web Consortium
DN	Distinguished Name
CN	Common Name
OU	Organizational Unit
GGF	Global Grid Forum
GUI	Graphical User Interface

1.3 Referencias

A continuación se detallan los documentos relacionados:

Documento	Descripción

2 Conceptos generales

2.1 Grid

Grid, o grid computing, consiste en un modelo computacional destinado a integrar recursos distribuidos en la forma de un recurso poderoso único. Su nombre se debe a una analogía con el sistema de distribución eléctrica, en el que un recurso se enchufa a la red de distribución, y simplemente recibe la energía, sin importar de dónde proviene dicha energía (tan solo que está disponible y se puede acceder a ella).

Un grid permite compartir no sólo poder de procesamiento, sino también espacio de almacenamiento. Los dispositivos que integra pueden ser tanto computadoras como otros dispositivos, por ejemplo sensores.

Los grids tienen aplicación en la resolución de problemas computacionales complejos, especialmente aquellos que pueden ser divididos en tareas para ser ejecutadas en forma paralela y los que tienen grandes requerimientos de espacio para datos, así como también problemas que requieren alto poder de procesamiento en general.

En un grid hay más heterogeneidad que en un cluster, se pueden integrar recursos que no son de naturaleza netamente computacional (como sensores o instrumentos), y se puede realizar la integración a través de múltiples dominios administrativos. Además, en un cluster existe un administrador de recursos centralizado, mientras que en un grid los nodos son autónomos.

2.2 Middleware

El término middleware hace referencia a una capa de software que se ubica por encima del sistema operativo, pero por debajo de las aplicaciones (de ahí su nombre). En un sistema distribuido, esta capa tiene como función homogeneizar hacia las capas superiores los aspectos de hardware, sistemas operativos, y protocolos de comunicación. También oculta la propia distribución (es decir, el hecho de que los recursos están distribuidos). Además, provee interfaces para que las aplicaciones puedan conectarse e interoperar, y provee un conjunto de servicios para llevar a cabo tareas de propósito general.

2.3 WSRF y Web Services Container

Cabe recordar, en primer lugar, que un Web Service consiste en software que expone operaciones que otro software puede utilizar. Se trata de una tecnología de computación distribuida con las ventajas de independencia de la plataforma y el lenguaje. Los Web Services hacen uso de tecnologías, lenguajes y protocolos estándar como XML y HTTP.

Debido a su bajo acoplamiento, la tecnología de Web Services es ideal para el modelo de Grid. Sin embargo, los Web Services comunes, tal como los define el W3C, son generalmente "stateless". Esto es, un web service de este tipo no recuerda información entre ejecuciones. En contraste, las aplicaciones Grid suelen requerir mantener estado, por lo que hacen uso de servicios web "stateful".

El Web Services Resource Framework es una especificación de cómo realizar servicios web de tipo "stateful". La OGSA requiere Web Services de este tipo, y el WSRF los especifica.

Un servidor que exponga web services debe con ciertos elementos de software. Además de los Web Services, se utiliza un software que permite generar e interpretar pedidos y respuestas de los mismos. Para el método más común de invocación de web services, que es utilizando SOAP, este software es una SOAP engine, y Apache Axis es la más común (y la que Globus utiliza). Para poder recibir pedidos de los clientes, esto se engloba dentro de un Application Server (un servlet container más propiamente dicho, en el caso de Tomcat). Finalmente, para poder comunicarse por http, es necesario un HTTP Server (Web Server), en caso de que el Application Server no incluya uno.

Lo antedicho puede resumirse en el siguiente diagrama:

The server side in a Web Services application

Imagen extraída de http://gdp.globus.org/gt4-tutorial/multiplehtml/ch01s02.html

Al conjunto de SOAP Engine, Application Server y Web Server se lo denomina comúnmente Web Services Container. En el presente documento, la palabra "container" hará referencia al Web Services Container de Globus, salvo que expresamente se aclare lo contrario.

2.4 Globus

En el presente documento, el término Globus hará referencia a su acepción como Globus Toolkit, salvo que expresamente se indique lo contrario. El término Globus puede referirse también a la comunidad de usuarios y desarrolladores involucrados en el desarrollo del GT, o a la infraestructura que subyace al funcionamiento de dicha comunidad (repositorios, listas de correo, etc.), representada por el sitio globus.org.

Globus Toolkit consiste en un middleware que permite que todos los elementos del grid participen de un entorno unificado. GT provee un conjunto de servicios que permiten resolver problemas comunes que ocurren en este tipo de modelo distribuido. En particular, provee servicios que permiten administrar la ejecución de trabajos, los datos, y la seguridad, y encontrar recursos adecuados para la ejecución de dichos trabajos.

A continuación se presenta un diagrama de arquitectura de GT4.

Imagen extraída de: http://gdp.globus.org/gt4-tutorial/multiplehtml/ch01s04.html#id2565979

Como puede observarse en el gráfico, la mayoría de los componentes de GT4 están basados en Web Services.

3 Instalación de Globus

3.1 Prerrequisitos

J2SE 1.4.2+

Instalar J2SE. Esto puede hacerse descargando el archivo .bin correspondiente del sitio http://java.sun.com o a través de un paquete.
Agregar la variable de entorno JAVA_HOME, cuyo valor será el directorio en el que reside JAVA. Esto puede hacerse insertando la línea export JAVA_HOME=dir_de_java en el archivo /etc/profile.
Agregar el directorio $JAVA_HOME/bin al PATH. Esto puede hacerse en el archivo /etc/profile. Es recomendable que, de existir más de una máquina virtual instalada, el directorio donde se encuentran los archivos de J2SE sea referenciado por el PATH en primer lugar (de esta manera se evitan warnings relacionados).

Ant 1.5.1+ (1.6.1+ si se usa JDK 1.5+)

Instalar Ant. Esto puede hacerse descargando el archivo correspondiente de http://ant.apache.org
Agregar la variable de entorno ANT_HOME, cuyo valor será el directorio en el que reside Ant. Esto puede hacerse insertando la línea export ANT_HOME=dir_de_ant en el archivo /etc/profile.
Agregar el directorio $ANT_HOME/bin al PATH. Esto puede hacerse en el archivo /etc/profile.

Compilador C. En caso que sea gcc, no utilizar las versiones 3.2 o 3.2.1 (pueden utilizarse las versiones 2.95.x)
zlib 1.1.4+ (en el caso de Debian, será el paquete zlib1g)
GNU tar
GNU sed
GNU make
sudo
Motor de bases de datos que permita conectividad por JDBC. Se recomienda PostgreSQL 7.1+ y se han experimentado problemas con MySQL 5 en conjunto con MySQL Connector/J 3.1 y 5.0
Opcional: IODBC, si se utilizará RLS
Opcional: Tomcat Servlet Container, si se utilizará WebMDS

Instalar Tomcat. Esto puede hacerse descargando el archivo correspondiente de http://tomcat.apache.org
Agregar la variable de entorno CATALINA_HOME, cuyo valor será el directorio en el que reside Tomcat. Esto puede hacerse insertando la línea export CATALINA_HOME=dir_de_tomcat en el archivo /etc/profile.

3.2 Configuración previa

Antes de instalar Globus, será necesario contar con un usuario que se utilizará para realizar tareas administrativas relacionadas con los servicios de GT.

3.2.1 Creación del usuario globus

Para crear el usuario globus, ejecutar:

Como usuario root:

adduser globus

3.2.2 Configuración del directorio origen de la instalación

El usuario globus debe ser dueño del directorio que contiene el instalador, en caso que esto no sea así ejecutar:

chown -R globus:globus dir_instalador

3.2.3 Configuración del directorio destino de la instalación

Crear el directorio que contendrá el GT4, de ahora en más referido como $GLOBUS_LOCATION.

Incluir $GLOBUS_LOCATION como variable de entorno.

Para ello agregar en /etc/profile la línea que se indica a continuación:

Como usuario root agregar:

export $GLOBUS_LOCATION=dir_elegido

Asegurarse de que el usuario globus sea el dueño de dicho directorio, ejecutando:

chown globus:globus $GLOBUS_LOCATION

3.2.4 Configuración del archivo de hosts

El archivo /etc/hosts debe estar correctamente configurado. A fines de que los servicios web puedan ser accedidos, debe exponerse la IP externa del host (en contraposición a la de loopback). Para que Globus reconozca correctamente la IP, ubicar en la primera línea del archivo /etc/hosts de la máquina en la que corre el container el IP externo y el dominio completo, quedando:

ip.ip.ip.ip      nombreHost.dominio.com    nombreHost

 Donde ip.ip.ip.ip es la IP externa de la máquina.

3.3 Instalación

3.3.1 Globus

Descargar la última versión de GT (http://www.globus.org).

Existe la posibilidad de descargar GT con sus fuentes o como binario para la distribución correspondiente. Lo expuesto en el presente documento es válido para ambos casos. En caso de descargar GT como binario, se observará un menor tiempo de ejecución en el caso de los comandos make y makeinstall.

En primer lugar, loguearse como usuario globus.

Descomprimir el archivo descargado en el directorio origen de la instalación.

Posicionado en el directorio origen de la instalación, ejecutar:

Como usuario globus:

./configure --prefix=$GLOBUS_LOCATION --with-iodbc=/usr/lib

El modificador -with-iodbc puede omitirse si no se desea tener RLS. El directorio indicado (en este caso /usr/lib) debe ser aquel que contiene las librerías de iodbc.

Tanto para el caso de instalación a partir de fuentes como de binarios, ejecutar el make y makeinstall correspondiente:

Como usuario globus:

make 2>&1 | tee /home/globus/make-globus-yyyy-mm-dd

make install | tee /home/globus/makeinstall-globus-yyyy-mm-dd

El pipe al comando tee no es imprescindible, pero permite guardar un log de potenciales errores al momento de la instalación.

GT trae archivos que permiten configurar variables de entorno. Agregar una llamada a dichos archivos en el /etc/profile:

Como usuario root agregar:

source $GLOBUS_LOCATION/etc/globus-user-env.sh

source $GLOBUS_LOCATION/etc/globus-devel-env.sh

3.3.2 SimpleCA

3.3.2.1 Crear la CA

SimpleCA es una entidad certificadora, que permite emitir certificados a los hosts y usuarios que intervienen en el grid, posibilitando el uso de los servicios de Globus.

La instalación de Globus expuesta contiene un instalador de simpleCA en el directorio $GLOBUS_LOCATION/setup/globus. Para instalar SimpleCA, ejecutar:

Como usuario globus:

$GLOBUS_LOCATION/setup/globus/setup-simple-ca

Este setup requerirá un subject name, que puede ser por ejemplo:

simpleCA-nombreHost-dominio.com

También pedirá una dirección de mail a la cual deberían enviarse las solicitudes de certificados, y solicitará que se defina un tiempo de vigencia de la entidad certificadora (el default son 5 años). Pasada la fecha de expiración de la CA, todos los certificados firmados por la misma pierden validez, por lo que antes de esta fecha una CA debería regenerar todos los certificados.

Finalmente, solicitará una PEM pass phrase. Esta es una clave que se utilizará cada vez que se firme un certificado. El acrónimo PEM se refiere al algoritmo de encriptación utilizado.

Luego de realizados estos pasos, se tendrá la información de la simpleCA generada en /home/globus/.globus/simpleCA. En particular, dicho directorio contendrá un archivo .tar.gz que consiste en un paquete de distribución que servirá para que otras máquinas confíen en la CA recién generada.

El último paso para que quede instalada la CA generada en la máquina que contiene la simpleCA, es ejecutar:

Como root:

$GLOBUS_LOCATION/setup/globus_simple_ca_HASH_setup/setup-gsi -default

Donde globus_simple_ca_HASH_setup coincide con el nombre del archivo .tar.gz antes mencionado (reemplazar HASH por el valor que corresponda). El modificador default indica que la simpleCA correspondiente al HASH será la simpleCA default para los comandos para los que no se indique qué simpleCA utilizar (una máquina puede confiar en más de una CA).

Observar que en directorio /etc/grid-security/certificates se tendrán los archivos que establecen la confianza en la CA recién creada. Notar en particular la presencia de dos archivos HASH.0 y HASH.signing_policy.

3.3.2.2 Establecer confianza en una CA

Para establecer confianza en una CA, se cuenta con un paquete de distribución en el directorio /home/globus/.globus/simpleCA de la máquina que contiene la CA. Dicho paquete de distribución se llama de la forma globus_simple_ca_HASH_setup.tar.gz, donde HASH es el número correspondiente a la CA.

Estos pasos no son necesarios en la máquina que contiene la CA, sino que sirven para establecer confianza en dicha CA en otra máquina.

Los pasos a seguir consisten en copiar el archivo .tar.gz a la máquina que confiará en la CA, en un directorio con permisos para el usuario globus de esa máquina. Luego, en esta segunda máquina, ejecutar desde el directorio donde se haya copiado el .tar.gz:

Como usuario globus:

gpt-build globus_simple_ca_HASH_setup.tar.gz

gpt-postinstall

WARNING: The following packages were not set up correctly:

        globus_simple_ca_HASH_setup-noflavor-pgm

Check the package documentation or run postinstall -verbose to see what happened

Luego, posicionarse en el directorio $GLOBUS_LOCATION/setup/globus_simple_ca_HASH_setup y ejecutar:

Como root:

setup-gsi -default

WARNING:  Can't match the previously installed GSI configuration files

          to a CA certificate. For the configuration files ending in

          "00000000" located in /etc/grid-security/certificates/,

          change the "00000000" extension to the hash of the correct

          CA certificate.

El modificador default indica que esta será la CA default para los comandos en los cuales no se especifique qué CA utilizar. Si no se desea que esta CA sea la default, omitir dicho modificador.

Los warnings transcriptos son normales y pueden desestimarse.

3.3.2.3 Obtener un certificado de host

Todos los hosts que contienen globus deben tener un certificado de host. Para obtenerlo, en la máquina para la que se desea obtener el certificado ejecutar:

Como root:

grid-cert-request -host nombreHost.dominio.com

Esto crea una private key en /etc/grid-security/hostkey.pem y un host certificate request en /etc/grid-security/hostcert_request.pem. Este host certificate request es el archivo que debe enviarse a la dirección de mail indicada para la simpleCA, que firmará el certificado y lo devolverá. Notar también que se ha generado un archivo /etc/grid-security/hostcert.pem, vacío, que luego deberá ser reemplazado por el certificado firmado.

El host certificate request debe ser llevado a la máquina que tiene la entidad certificadora para que sea firmado. La forma más común de hacer esto es enviarlo por mail ejecutando:

cat hostcert_request.pem | mail direccion_indicada

Otras posibilidades involucran copiar el archivo o, si se trata de la máquina que contiene la entidad certificadora, simplemente omitir este paso.

En la máquina que contiene la entidad certificadora, debe firmarse el certificado. Para esto es necesario loguearse en la máquina que contiene el simpleCA como usuario globus. Si el certificate request se envió por mail, debe guardarse a un archivo.

Los pasos a seguir son:

Como usuario globus:

grid-ca-sign -in hostcert_request.pem -out hostsigned.pem

Incluir de ser necesario la ruta a los archivos. El nombre hostsigned.pem es arbitrario y podría ser otro. Al ejecutar grid-ca-sign se solicitará la PEM pass phrase de la simpleCA que firma el certificado.

Luego, el certificado firmado debe enviarse a la máquina que lo requirió (nuevamente una opción es hacerlo por mail), y grabarse como hostcert.pem en el directorio /etc/grid-security de la misma.

Para ello, en la máquina que solicitó el certificado, copiar como root el archivo como /etc/grid-security/hostcert.pem sobrescribiendo el archivo de 0 bytes creado al ejecutar grid-cert-request -host.

Si al realizar la instalación se recibió un warning como el siguiente:

Reading gatekeeper configuration file...

Warning: Host cert file: /etc/grid-security/hostcert.pem not found.  Re-run

         setup-globus-gram-job-manager after installing host cert file.

Ejecutar como globus:

$GLOBUS_LOCATION/setup/globus/setup-globus-gram-job-manager

3.3.2.4 Obtener un certificado de usuario

Todos los usuarios que deban utilizar los servicios de globus (esto es, ejecutar comandos del GT para, por ejemplo, la ejecución de trabajos o la copia de archivos) necesitan contar con un certificado de usuario emitido por la entidad certificadora.

Para ello, loguearse como el usuario que solicitará el certificado, por ejemplo, usuario1, y ejecutar:

Como usuario usuario1:

grid-cert-request

Se solicitará una PEM pass phrase para el usuario, que será requerida cada vez que se inicialice un proxy para poder utilizar los servicios de globus. El acrónimo PEM hace referencia al algoritmo de encriptación utilizado.

Al ejecutar el comando indicado, se generarán en /home/usuario1/.globus los archivos userkey.pem, conteniendo la clave privada, y usercert_request.pem y usercert.pem, este último vacío.

El user certificate request (usercert_request.pem) debe ser llevado a la máquina que tiene la entidad certificadora para que sea firmado. La forma más común de hacer esto es enviarlo por mail ejecutando:

cat usercert_request.pem | mail direccion_indicada

Otras posibilidades involucran copiar el archivo o, si se trata de la máquina que contiene la entidad certificadora, simplemente omitir este paso.

Los pasos a seguir son:

Como usuario globus:

grid-ca-sign -in usercert_request.pem -out usersigned.pem

Incluir de ser necesario la ruta a los archivos. El nombre usersigned.pem es arbitrario y podría ser otro. Al ejecutar grid-ca-sign se solicitará la PEM pass phrase de la simpleCA que firma el certificado.

Luego, el certificado firmado debe enviarse a la máquina que lo requirió (nuevamente una opción es hacerlo por mail), y grabarse como usercert.pem en el directorio /home/usuario1/.globus de la misma (reemplazando el archivo vacío generado al hacer el request).

Finalmente, en las máquinas en las que podrán ejecutarse comandos lanzados por el usuario1, editar como root el archivo /etc/grid-security/grid-mapfile y agregar una línea que indique el subject name del propietario del certificado de usuario, seguida de un nombre de usuario local en la máquina en la que se encuentra el grid-mapfile.

Por ejemplo, si el usuario1 podrá ejecutar procesos en la máquina máquina2, el grid-mapfile de la máquina2 contendrá una línea similar a la siguiente:

"/O=Grid/OU=GlobusTest/OU=simpleCA-nombreHost.dominio.com/OU=localdomain/CN=Usuario 1" usrMaq2

Es importante que el Distinguished Name (DN) esté encerrado entre comillas, ya que contiene espacios. Para averiguar el DN, ejecutar como en la máquina en la que reside usuario1:

Como usuario1:

grid-cert-info -subject

3.3.2.5 Permitir al container el acceso a las credenciales

Normalmente, el container de web services de Globus correrá como el usuario globus. Para permitir el acceso del container a las credenciales de host de la máquina, debe hacerse copia de los archivos que contienen la clave y el certificado a archivos sobre los que el usuario globus tendrá permisos.

Para ello, ejecutar, posicionado en el directorio /etc/grid-security:

Como root:

cp hostkey.pem containerkey.pem

cp hostcert.pem containercert.pem

chown globus:globus containerkey.pem containercert.pem

3.3.2.6 Establecer una CA default

Para establecer una CA default para aquellos comandos en los cuales no se especifique qué CA utilizar, ejecutar:

Como root:

grid-default-ca

Y elegir la CA default de la lista presentada.

Para verificar cuál CA es la default, ejecutar:

grid-default-ca -list

3.3.2.7 Establecer confianza cruzada entre CA de distintas organizaciones

Para compartir recursos de dos organizaciones separadas, en las que cada una cuenta con su propia CA, los hosts de ambas organizaciones deberán confiar en ambas CA. Para ello, se debe establecer confianza en ambas CA en todos los hosts. Esto puede hacerse de la manera detallada en la sección correspondiente ("Establecer confianza en una CA"). También es posible establecer confianza en una CA simplemente copiando los archivos HASH.0 y HASH.signing_policy al directorio /etc/grid-security de la máquina que confiará en la CA identificada por el HASH (recordar que el directorio /etc/grid-security sólo puede ser escrito por root). Es común hacer deploy del paquete .tar.gz de distribución de la CA en una máquina, y establecer la confianza del resto por copia, como se describe en esta sección.

Debe recordarse editar el grid-mapfile en todas las ubicaciones a las que un usuario deba acceder, mapeando los Distinguished Names a identidades locales de cada una de las máquinas. Es decir, que en las máquinas en las que podrán ejecutarse comandos lanzados por el usuario1, se debe editar como root el archivo /etc/grid-security/grid-mapfile y agregar una línea que indique el subject name del propietario del certificado de usuario, seguida de un nombre de usuario local en la máquina en la que se encuentra el grid-mapfile.

Por ejemplo, si el usuario1 podrá ejecutar procesos en la máquina máquina2, el grid-mapfile de la máquina2 contendrá una línea similar a la siguiente:

"/O=Grid/OU=GlobusTest/OU=simpleCA-nombreHost.dominio.com/OU=localdomain/CN=Usuario 1" usrMaq2

Es importante que el Distinguished Name (DN) esté encerrado entre comillas, ya que contiene espacios. Para averiguar el DN, ejecutar como en la máquina en la que reside usuario1:

Como usuario1:

grid-cert-info -subject

3.3.3 GridFTP

Las herramientas de GridFTP conforman uno de los componentes para movimiento de datos que provee el Globus Toolkit. GridFTP es un protocolo definido por el GGF que procura lograr transferencia de datos segura, robusta, rápida y eficiente. GT4 provee tanto un server (globus-gridftp-server) como un cliente de línea de comando (globus-url-copy). En esta sección se explicará cómo configurar el server.

3.3.3.1 Configuración de /etc/services

Debe configurarse el servicio para que sea ejecutado por el sistema. Para ello debe editarse el archivo /etc/services.

Como root:

Agregar al archivo /etc/services:

gsiftp          2811/tcp

En este caso, 2811 es el puerto elegido, que coincide con el default y además es el valor recomendado para evitar configuraciones adicionales en otros servicios (en particular, WS GRAM).

3.3.3.2 Configuración para correr bajo xinetd

El método recomendado para correr el servidor de GridFTP es bajo xinetd. Para configurar este aspecto, debe hacerse lo siguiente en cada máquina en la que se desee tener un server de GridFTP:

Como root:

Crear el archivo /etc/xinetd.d/gridftp con el contenido

service gsiftp

instances               = 100

socket_type             = stream

wait                    = no

user                    = root

env                     += GLOBUS_LOCATION=dir_de_globus

env                     += LD_LIBRARY_PATH=dir_de_globus/lib

server                  = dir_de_globus/sbin/globus-gridftp-server

server_args             = -i

log_on_success          += DURATION

nice                    = 10

disable                 = no

Ejecutar:

/etc/init.d/xinetd reload

 En el archivo transcripto, dir_de_globus debe reemplazarse por el directorio en el que globus se encuentra instalado (no utilizar la variable de entorno $GLOBUS_LOCATION, sino escribir literalmente el directorio de instalación).

Este método es excluyente con el que se explica en la sección de "Configuración para correr bajo inetd".

3.3.3.3 Configuración para correr bajo inetd

Como root:

Agregar al archivo /etc/inetd.conf, todo en una línea:

gsiftp stream tcp nowait root /usr/bin/env env GLOBUS_LOCATION=dir_de_globus LD_LIBRARY_PATH=dir_de_globus/lib dir_de_globus/sbin/globus-gridftp-server -i

En el archivo transcripto, dir_de_globus debe reemplazarse por el directorio en el que globus se encuentra instalado (no utilizar la variable de entorno $GLOBUS_LOCATION, sino escribir literalmente el directorio de instalación).

Luego, debe reiniciarse el daemon inetd para reflejar los cambios.

Este método es excluyente con el que se explica en la sección de "Configuración para correr bajo xinetd".

3.3.4 RFT

El servicio Globus Reliable File Transfer (RFT) es un componente de GT para movimiento de datos. Este componente utiliza internamente GridFTP (por lo que requiere un servidor de GridFTP), pero provee algunas características adicionales que lo hacen más propicio en determinadas situaciones.

RFT es un web service, y permite recuperarse de fallas en el cliente, cosa que GridFTP no permite. Permite además consultar el estado de la transferencia.

Dado que es un web service, el container de Globus deberá estar corriendo, y el servicio RFT deberá estar registrado en él (esto último es así por default).

3.3.4.1 Configuración de la base de datos (PostgreSQL)

RFT utiliza una base de datos para administrar los pedidos y transferencias. El motor de bases de datos recomendado es PostgreSQL. En esta sección se explica cómo configurar dicho motor para el funcionamiento de RFT.

PostgreSQL corre como un daemon llamado postmaster. El primer paso es configurar este daemon para que acepte conexiones por TCP. Esto se hace editando el archivo /etc/postgresql/postmaster.conf de la siguiente manera:

Como root, editar el archivo modificando la opción correspondiente:

POSTMASTER_OPTIONS="-i"

Luego ejecutar:

/etc/init.d/postgresql restart

Configurar las opciones de seguridad para la base de RFT, que se llamará rftDatabase. Para ello, editar el archivo /etc/postgresql/pg_hba.conf agregando la línea indicada. Las reglas de este archivo se interpretan en orden, por lo que debe cuidarse de agregar la línea antes de cualquier otra regla que prohiba el acceso (en particular, la última línea del archivo rechaza todas las conexiones no abarcadas por las líneas anteriores, por lo que debe ubicarse la nueva regla como mínimo por encima de la última). El IP debería ser el externo de la máquina. Si por alguna razón debe agregarse una entrada con el IP loopback, deberá tenerse cuidado adicional con las reglas enunciadas en el archivo, que intentan autenticar por método IDENT para todas las bases (en el caso particular de la rftDatabase, se utilizará el método TRUST, por lo que la regla deberá anteceder al resto de las reglas para el IP loopback).

Como root, agregar al archivo pg_hba.conf la línea:

host rftDatabase "globus" "host-ip" 255.255.255.255 trust

Luego ejecutar:

/etc/init.d/postgresql restart

En dicha línea, host-ip es el IP del host en el que corre el servicio RFT. globus es un usuario de PostgreSQL, dueño de la base rftDatabase.

Para crear el usuario globus en PostgreSQL, deberá utilizarse el usuario postgres (si no se tiene el password del mismo, acceder desde root mediante su postgres). Luego crear el usuario de la siguiente manera:

Como usuario postgres:

createuser globus

Este usuario podrá crear bases y no podrá crear usuarios.

Resta crear la base de datos con el schema correspondiente, para ello:

Como usuario globus:

createdb rftDatabase

psql -d rftDatabase -f $GLOBUS_LOCATION/share/globus_wsrf_rft/rft_schema.sql

El archivo rft_schema.sql contiene un script para PostgreSQL, que permite crear el schema de la base.

Finalmente, deben configurarse los parámetros de conexión a la base por parte del servicio RFT. Para ello debe editarse el archivo $GLOBUS_LOCATION/etc/globus_wsrf_rft/jndi-config.xml.

Como usuario con permisos sobre jndi-config.xml (ej. globus):

Modificar el userName y password para que sean el username password del usuario globus de Linux.

Modificar la connectionString para referenciar el nombre de dominio (o IP) de la máquina que contiene la base. Por ejemplo: jdbc:postgresql://nombeHost.dominio.com/rftDatabase

3.3.5 Gatekeeper

Globus Gatekeeper es un proceso que corre en la máquina que ejecuta un trabajo y que administra los pedidos de trabajos que se le hacen a esa máquina. Es necesario tener el gatekeeper configurado para poder enviar trabajos a la máquina utilizando los comandos de globus que no están basados en web services (globus-job-run, globus-job-submit y globusrun). Esta sección explica cómo configurar el gatekeeper.

3.3.5.1 Configuración de /etc/services

Debe configurarse el servicio para que sea ejecutado por el sistema. Para ello debe editarse el archivo /etc/services.

Como root:

Agregar al archivo /etc/services:

gsigatekeeper   2119/tcp

En este caso, 2119 es el puerto elegido, que coincide con el default.

3.3.5.2 Configuración para correr bajo xinetd

El método recomendado para correr el gatekeeper es bajo xinetd. Para configurar este aspecto, debe hacerse lo siguiente en cada máquina en la que se desee tener un proceso gatekeeper:

Como root:

Crear el archivo /etc/xinet.d/gsigatekeeper con el contenido

service gsigatekeeper

socket_type = stream

protocol = tcp

wait = no

user = root

env += LD_LIBRARY_PATH=dir_de_globus/lib

server = dir_de_globus/sbin/globus-gatekeeper

server_args = -conf dir_de_globus/etc/globus-gatekeeper.conf

disable = no

log_type = FILE dir_de_globus/var/xinetd-gatekeeper.log

Ejecutar:

/etc/init.d/xinetd reload

 En el archivo transcripto, dir_de_globus debe reemplazarse por el directorio en el que globus se encuentra instalado (no utilizar la variable de entorno $GLOBUS_LOCATION, sino escribir literalmente el directorio de instalación).

Este método es excluyente con el que se explica en la sección de "Configuración para correr bajo inetd".

3.3.5.3 Configuración para correr bajo inetd

Como root:

Agregar al archivo /etc/inetd.conf, todo en una línea:

gsigatekeeper stream tcp nowait root /usr/bin/env env LD_LIBRARY_PATH=dir_de_globus/lib dir_de_globus/sbin/globus-gatekeeper -conf dir_de_globus/etc/globus-gatekeeper.conf

Luego, debe reiniciarse el daemon inetd para reflejar los cambios.

Este método es excluyente con el que se explica en la sección de "Configuración para correr bajo xinetd".

3.3.6 WS GRAM

GRAM es el componente de GT que permite administrar la ejecución de trabajos. Este servicio permite iniciar, monitorear y administrar la ejecución de tareas computacionales en computadoras remotas. WS GRAM es la implementación basada en servicios web de este componente.

WS GRAM utiliza una herramienta llamada sudo para tener acceso a cuentas de usuario sin requerir privilegios de superusuario. Este método reemplaza al gatekeeper utilizado en la implementación de GRAM no basada en web services.

La información de sudo está contenida en el archivo /etc/sudoers, que se edita con el comando visudo. Esta utilidad proporciona verificaciones de seguridad y consistencia.

La definición en este caso es permitir al usuario globus correr, en cualquier host, el comando especificado en cada una de las líneas, sin necesidad de autenticarse (hecho denotado por la opción NOPASSWD), y como cualquiera de los usuarios especificados entre paréntesis.

Para agregar al archivo sudoers las líneas necesarias proceder de la siguiente manera:

Como root:

Ejecutar visudo

Agregar las siguientes dos líneas:

globus ALL=(usuario1,usuario2) NOPASSWD: dir_de_globus/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /opt/gt4/libexec/globus-job-manager-script.pl *

globus ALL=(usuario1,usuario2) NOPASSWD: dir_de_globus/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /opt/gt4/libexec/globus-gram-local-proxy-tool *

Donde usuario1 y usuario2 representan los usuarios como los cuales se quieren ejecutar trabajos.

3.3.7 WebMDS

3.3.7.1 Index Server a monitorear

MDS es el componente de GT que permite identificar recursos o servicios con las características deseadas, y monitorear dichos recursos.

WebMDS consiste en un front-end que puede ser accedido desde un navegador y que provee una interfaz amigable para ver información tal como los servicios web expuestos por un container, transferencias/trabajos encolados y ejecutados, y otras consultas no preconfiguradas. WebMDS requiere que Tomcat esté instalado.

El primer paso consiste en editar el archivo $GLOBUS_LOCATION/lib/webmds/conf/indexinfo que es el que contiene la información del index server a monitorear. Es posible que el valor default (que involucra el IP de loopback) sea adecuado, pero en caso de no serlo debe cambiarse el valor del parámetro endpoint, para ello:

Como usuario globus (o usuario con permiso de escritura sobre el archivo indexinfo) editar el archivo de manera que se lea (fragmento):

<name>endpoint</name>

<value>https://nombreHost.dominio.com:8443/wsrf/services/DefaultIndexService</value>

</parameter>

Luego debe hacerse deploy del servlet en Tomcat. La aplicación reside en $GLOBUS_LOCATION/lib/webmds, puede observarse que dentro de dicha ubicación se encuentra el directorio WEB-INF, característico de los servlets.

Los cambios en este archivo se reflejarán al reiniciar Tomcat.

3.3.7.2 Deploy en Tomcat mediante archivo de contexto

La forma indicada en la documentación para hacer deploy del servlet en Tomcat es sin mover los archivos de la ubicación indicada, creando un archivo de contexto.

Para ello, debe ejecutarse:

Como usuario globus:

$GLOBUS_LOCATION/lib/webmds/bin/webmds-create-context-file $CATALINA_HOME/conf/Catalina/localhost

El comando indicado creará, dentro del directorio $CATALINA_HOME/conf/Catalina/localhost, el archivo webmds.xml.

Este método es excluyente con el que se explica en la sección de "Deploy en Tomcat mediante la GUI de administración".

3.3.7.3 Deploy en Tomcat mediante la GUI de administración

Tomcat provee una GUI para, entre otras cosas, administrar gráficamente los componentes que se encuentran instalados en el servlet container. Esta utilidad se llama Tomcat Manager, y requiere un paso previo de configuración que se describe a continuación.

Como usuario con permisos sobre el directorio de Tomcat:

Editar el archivo $CATALINA_HOME/conf/tomcat-users.xml

Agregar en caso que no existan, los roles admin. y manager:

<role rolename="manager"/>

<role rolename="admin"/>

Agregar un usuario con ambos roles:

<user username="NombreUsrAdmin" password="password" roles="admin,manager"/>

El nombre del usuario y su password son arbitrarios.

Luego, para acceder a la interfaz hacerlo ingresando mediante un navegador a la dirección:

http://ip.ip.ip.ip:8080/manager/

Donde ip.ip.ip.ip es el IP del host en el que reside Tomcat, o alternativamente un nombre de dominio correspondiente a dicho host.

Al ingresar, se observará que existe la posibilidad de hacer deploy de nuevas aplicaciones web. Completar los datos del formulario como se muestra a continuación:

Context Path (optional): /webmds

XML Configuration file URL: dejar en blanco

WAR or Directory URL: file:/opt/gt4/lib/webmds

Luego de hacer el deploy con estos parámetros, se observará que se habrá copiado el contenido del directorio $GLOBUS_LOCATION/lib/webmds a $CATALINA_HOME/webapps/webmds.

Este método es excluyente con el que se explica en la sección de "Deploy en Tomcat mediante archivo de contexto".

3.3.7.4 Configuración del CLASSPATH

En caso que al realizar consultas a través del servicio WebMDS, el servlet container (es decir, Tomcat) arroje un error indicando que no encuentra clases necesarias, esto puede deberse a que no se estén cargando en el CLASSPATH los archivos .jar que se encuentran dentro del directorio $GLOBUS_LOCATION/lib/webmds/WEB-INF/lib. De ser este el caso, se propone el siguiente "workaround":

Como usuario con permisos sobre el directorio de Tomcat:

Editar el archivo setclasspath.sh:

Verificar el efecto de este script sobre la variable de entorno CLASSPATH, y procurar que incluya el CLASSPATH definido en el entorno desde el que se lanza el script.

Por ejemplo, para un script que inicialmente indique:

# First clear out the user classpath

CLASSPATH=

Modificarlo de manera que se lea:

# First clear out the user classpath

CLASSPATH=$CLASSPATH

El script setclasspath.sh es invocado por el script catalina.sh, a su vez invocado por startup.sh. Se propone entonces lanzar Tomcat mediante el script startup.sh, y no hacerlo como daemon.

Para incluir los archivos .jar del directorio $GLOBUS_LOCATION/lib/webmds/WEB-INF/lib, escribir un script como el siguiente:

for i in ${GLOBUS_LOCATION}/lib/webmds/WEB-INF/lib/*.jar

CP=$CP:"$i"

done

if [ -z "$CLASSPATH" ] ; then

CLASSPATH=$CP

else

CLASSPATH=$CP:$CLASSPATH

export CLASSPATH

Este script incluye en el classpath del entorno del usuario los archivos mencionados. Debe incluirse una llamada al mismo, para ello puede, por ejemplo, incluirse una llamada en el archivo /etc/profile. Deberá lanzarse Tomcat en forma manual una vez iniciado el sistema, en vez de hacerlo automáticamente al inicio (se ha experimentado llamando a dicho archivo desde los scripts de /etc/init.d, linkeados por los archivos de inicio, sin éxito respecto de la modificación del classpath).

3.3.8 MyProxy

GSI involucra un sistema de criptografía asimétrica (es decir, de clave pública y privada). La clave privada es protegida mediante un password, denominado passphrase. De acuerdo con GSI, cada usuario o servicio es identificado mediante un certificado, que contiene identificación que permite su autenticación. Esta información incluye el subject name del objeto o persona representado por el certificado, su clave pública, la identidad de la CA que firmó el certificado, y la firma digital de la CA.

GSI provee un mecanismo para evitar la necesidad de ingresar repetidamente la passphrase. Este mecanismo se basa en la generación de un Proxy, que consiste en un nuevo certificado junto con una clave privada.

Normalmente, es necesario tener claves privadas y certificados en cada máquina. MyProxy evita esto, dado que es un repositorio online de credenciales. Teniendo un servidor de MyProxy, es posible guardar credenciales en el repositorio y obtener un proxy a partir de ellas utilizando un cliente de MyProxy. MyProxy también se utiliza para autenticación en portales de Grid y para renovación de credenciales con administradores de trabajos.

3.3.8.1 Archivo de configuración de MyProxy

En primer lugar, debe modificarse el archivo $GLOBUS_LOCATION/share/myproxy/myproxy-server.config de acuerdo a las necesidades y copiar a $GLOBUS_LOCATION/etc/myproxy-server.config o a /etc/myproxy-server.config.

El siguiente contenido de ejemplo para el archivo myproxy-server.config permite todas las características que provee MyProxy:

accepted_credentials       "*"

authorized_retrievers      "*"

default_retrievers         "*"

authorized_renewers        "*"

default_renewers           "none"

authorized_key_retrievers  "*"

default_key_retrievers     "none"

3.3.8.2 Configuración de /etc/services

En la máquina en la que corra el server de myproxy, debe configurarse el servicio para que sea ejecutado por el sistema. Para ello debe editarse el archivo /etc/services.

Como root:

Agregar al archivo /etc/services:

myproxy-server   7512/tcp

3.3.8.3 Configuración para correr bajo xinetd

En la máquina en la que corra el server de myproxy, debe hacerse lo siguiente:

Como root:

Copiar el archivo $GLOBUS_LOCATION/share/myproxy/etc.xinetd.myproxy a /etc/xinetd.d/myproxy y editar los paths de forma que quede:

service myproxy-server

  socket_type  = stream

  protocol     = tcp

  wait         = no

  user         = root

  server       = dir_de_globus/sbin/myproxy-server

  env          = GLOBUS_LOCATION=dir_de_globus LD_LIBRARY_PATH=dir_de_globus/lib

  disable      = no

Ejecutar:

/etc/init.d/xinetd reload

 En el archivo transcripto, dir_de_globus debe reemplazarse por el directorio en el que globus se encuentra instalado (no utilizar la variable de entorno $GLOBUS_LOCATION, sino escribir literalmente el directorio de instalación).

4 Configuración posterior

4.1 Lanzar el container mediante un script en /etc/init.d

Para lanzar el container de Globus mediante un script en /etc/init.d, se proponen los siguientes pasos.

Como usuario globus, crear el script start-stop en el directorio $GLOBUS_LOCATION:

#! /bin/sh

set -e

export GLOBUS_LOCATION=/opt/gt4

export GLOBUS_OPTIONS="-Xms256M -Xmx512M"

. $GLOBUS_LOCATION/etc/globus-user-env.sh

cd $GLOBUS_LOCATION

case "$1" in

    start)

        $GLOBUS_LOCATION/sbin/globus-start-container-detached -p 8443

;;

    stop)

        $GLOBUS_LOCATION/sbin/globus-stop-container-detached

;;

*)

        echo "Usage: globus {start|stop}" >&2

        exit 1

;;

esac

exit 0

De ser necesario, incluir en este script también las líneas entre los export:

export JAVA_HOME=

export ANT_HOME=

Ubicando luego del signo = el path correspondiente.

Como usuario globus, dar permiso de ejecución a este script:

chmod +x $GLOBUS_LOCATION/start-stop

Luego debe crearse el correspondiente script en /etc/init.d, para ello:

Como usuario root, crear el archivo /etc/init.d/globus-4.0.2 con el contenido:

#!/bin/sh -e

case "$1" in

  start)

      su - globus dir_de_globus/start-stop start

;;

  stop)

      su - globus dir_de_globus/start-stop stop

;;

  restart)

      $0 stop

      sleep 1

      $0 start

;;

*)

      printf "Usage: $0 {start|stop|restart}\n" >&2

      exit 1

;;

esac

exit 0

En el archivo transcripto, dir_de_globus debe reemplazarse por el directorio en el que globus se encuentra instalado (no utilizar la variable de entorno $GLOBUS_LOCATION, sino escribir literalmente el directorio de instalación).

Como usuario root, darle permisos de ejecución al archivo con:

chmod +x /etc/init.d/globus-4.0.2

4.2 Lanzar el container automáticamente en el inicio

Para lanzar el container automáticamente en el inicio, debe configurarse el link correspondiente desde el directorio /etc/rcN.d (donde N es el runlevel). El procedimiento consiste en hacer un softlink al archivo /etc/init.d/globus-4.0.2. En cuanto al número de orden a asignar, se propone que sea al menos posterior al link que lanza PostgreSQL, dado que el container se conecta a la base de RFT al ser lanzado.

También puede utilizarse la utilidad update-rc.d o similar, según la distribución de Linux utilizada.

5 Herramientas recomendadas