Hasta la fecha se han realizado los siguientes avances con respecto a la implementación del proyecto.

• Se incluyó un apartado acerca del envío de trabajos al cluster Condor cuando no se cuenta con un sistema de archivos compartido.
• Se documentó un problema que sucede cuando se envían scripts con el universo Vanilla sin el correspondiente shebang.
• Se documentó el error de GSS authentication failure que sucede cuando el hostname del servidor no coincide con el certificado de máquina.
• Se documentó el error que impide la ejecución del servidor GAHP y que a su vez evita el envío de trabajos al nodo Grid.
• Se complementó el procedimiento de instalación del cliente Grid y se realizó en (Nodo9@UAM).
• Se realizó la documentación del error que sucede cuando un usuario no autorizado en el gridmap-file intenta enviar trabajos al nodo Grid.
• Se realizaron múltiples pruebas de instalación del nodo Grid con sistemas operativos de 32 y 64 bits para verificar el envío de trabajos con las herramientas de Globus desde el CE y el Cliente, mientras que el envío de trabajos con CondorG sólo puede ser realizado desde el Cliente.  Se envió correo a Grid Colombia para confirmar este hallazago.
• Se realizó la instalación de Octave 3.2.4 a partir de fuentes (en UR) tanto en el nodo principal como en los nodos trabajadores.  Así mismo se documentó el problema de instalación en cluster encontrado.
• Se documentó el envío de trabajos al cluster Condor con Octave mediante el universo Vanilla.

Durante las últimas dos semanas se realizaron los siguientes avances con respecto a la implementación del proyecto.

• Se documento el procedimiento de instalación del cliente OSG.
• Se realizaron algunos ajustes a las pruebas locales del CE (Compute Element).
• Se determinó que los mensajes informativos relacionados con el paquete Globus-Base-Info recibidos durante la instalación del CE no revisten mayor gravedad y pueden ignorarse.
• En el cluster de la Universidad del Rosario se realizaron los siguientes avances.
  • Se actualizaron los paquetes del sistema operativo en todos los nodos.
  • Se corrigió el hostname del CE.
  • Se realizó la instalación y configuración de Condor de acuerdo a los estándares y procedimientos del proyecto.  Se realizaron algunos ajustes a la documentación de estos.  Tanto el head como los worker nodes fueron modificados.
  • Se realizó la instalación del Cliente OSG en el nodo 7.
  • Se realizó la instalación y configuración del CE (nodo 4).
  • Se corrigió el soporte para el universo Java en todos los nodos del cluster.
  • Se reiniciaron los nodos del cluster y se verificó el correcto funcionamiento de los servicios (NFS y SSH) y de Condor (nodos y Java).
• En el cluster de la Universidad Autónoma de Manizales se realizaron los siguientes avances.
  • Se realizó la instalación del Cliente OSG en el nodo 9.
  • Se corrigió el soporte para el universo Java en todos los nodos del cluster.

Entre las universidades del eje cafetero aparentemente persisten los problemas de conectividad los cuales actualmente impiden la posibilidad de realizar pruebas de conectividad entre los nodos de la Grid con la Universidad Autónoma de Manizales.

Continúa pendiente verificar la integración entre Condor y Globus ya que las pruebas locales al respecto no han sido satisfactorias aún.

Durante la instalación de los paquetes del CE (Compute Element) se generan los siguientes mensajes informativos cuando se realiza la instalación sobre una arquitectura de 64 bits.

INFO: The Globus-Base-Info-Server package is not supported on this platform
INFO: The Globus-Base-Info-Client package is not supported on this platform

Según se investigó y hasta el momento se ha verificado durante la experiencia de instalación, configuración y pruebas, es seguro ignorar estos mensajes.

Durante el mes de enero y los primeros días del mes de febrero se realizaron los siguientes avances en el proyecto los cuales fueron documentados en su sitio wiki.

• Con respecto a los certificados se documentaron los procedimientos para solicitar, obtener, instalar y registrar los certificados de los usuarios; y solicitar e instalar los certificados de las máquinas.
• Con respecto al CE (Compute Element) se realizó su instalación y configuración general, la cual incluye además la configuración del uso del gridmap-file y las pruebas locales para verificar su funcionamiento.
• Se formalizó la documentación del hardware de los servidores involucrados en los nodos Grid del proyecto.
• Se agregó un nuevo nodo (nodo9) al nodo de la Universidad Autónoma de Manizales en el cual se realizó la configuración para anexarlo al cluster.
• Se realizaron mejoras a la configuración del nodo8 que tenía problemas de autenticación con el cluster y por esto no estaba siendo tenido en cuenta por Condor.

Durante la presente semana se formalizó en la documentación del wiki del proyecto la instalación y configuración de equipos externos que tendrán Condor única y exclusivamente para el envío de trabajos al cluster (nodos submitter).  Esta tarea se analizó desde las siguientes distribuciones: convertir un nodo trabajador a nodo submitter, Ubuntu desde paquetes .tgz y paquetes .deb, y Scientific Linux desde paquetes .tgz.  Se determinó el método para restringir los equipos que pueden conectarse al pool del cluster, esto incluye a los nodos trabajadores y a los emisores de trabajos.

Se realizaron pruebas con Condor para Windows pero por ahora en esa plataforma no fue posible configurar la autenticación basada en contraseña que requiere el cluster.

También se documentó el procedimiento para permitirle a los nodos trabajadores acceder a las redes externas como Internet utilizando al nodo principal del cluster como puerta de enlace utilizando iptables y las facilidades nativas de Linux.

Se realizaron ajustes a los permisos y propietarios de la instalación de InterProScan para permitir que este pudiera ser ejecutado por usuarios no administradores del sistema operativo.

La semana pasada asistimos a un curso de capacitación en la Universidad Autónoma de Manizales dictado por la empresa española MaatG enfocado al uso y desarrollo de su plataforma grid, haciendo un principal énfasis en su módulo de e-learning que es utilizado ampliamente por el proyecto de Colciencias que venimos desarrollando.

Se aprovechó también para realizar la instalación del OSG Client en el servidor principal del cluster de la Autónoma e iniciar la instalación del Computer Element (CE) de su próximamente nodo Grid.  De este último se realizó la instalación de los certificados de máquina, los servicios adicionales requeridos y el gestor de paquetes de OSG.  Al respecto estamos listos para continuar con la instalación del CE previa verificación del funcionamiento del cliente cuando se obtengan certificados de usuario para realizar las pruebas por parte de Grid Colombia.

Adicionalmente se realizó la instalación y configuración inicial del software de bioinformática InterProScan en el cluster que es requerido por los compañeros de Cenicafé.

Durante estas últimas semanas se ha trabajado en el documento del anteproyecto el cual está pendiente de una revisión final por parte de las asesoras técnicas y metodológicas para su visto bueno.

Se modificó la distribución de la información en el wiki para facilitar su acceso rápdio, además se agregaron las siguientes secciones nuevas en el Wiki del proyecto.

1. Envío de múltiples trabajos al clúster.
   1. Utilizando múltiples argumentos.
   2. Utilizando diferentes directorios de trabajo.
2. Como determinar la finalización de los trabajos enviados al clúster.
3. Determinar el estado y los problemas de los trabajos enviados al clúster.

Se agregaron dos nuevas secciones en el wiki bajo Clúster con las actividades por hacer en la cual se relacionan las tareas pendientes y los temas que sería bueno profundizar pero que en este momento no hacen parte de los intereses principales del proyecto.  Una segunda sección se encarga de listar otras herramientas de clusterización que puede ser interesante incluír en el clúster pero que también, en este momento no hacen parte directa de los intereses del proyecto.

Se actualizaron los sistemas operativos de los nodos (máquinas virtualizadas con KVM) del clúster de desarrollo con las actualizaciones de octubre sin que se presentaran problemas aparentes.

Se realiza la planeación incial para la instalación de los elementos del nodo grid local: GUMS, Compute Element y Grid Client.  De igual manera se consideró necesario investigar acerca del Storage Element.

En la presente semana se espera realizar el contacto con los ingenieros de Grid Colombia para coordinar las actividades.

Problema.

Condor inicia de manera exitosa manualmente, sin embargo no se inicia automáticamente durante el inicio del sistema operativo.

Los logs del nodo, tanto de Condor como del sistema operativo, no muestran ningún mensaje de error, sin embargo se muestra el siguiente mensaje durante el inicio de los servicios del sistema operativo.

Neither the enviroment variable CONDOR_CONFIG,
/etc/condor, ~condor/ contain a condor_config source.
Either set CONDOR_CONFIG to point to a valid config source,
or put a “condor_config” file /etc/condor or ~condor/

Explicación.

Condor durante su inicio automático no está encontrando su configuración básica.

Solución.

Especifique cual es el archivo de configuración básica de Condor mediante la especificación de la variable de ambiente CONDOR_CONFIG o mediante la ubicación (a través de un enlace) del archivo, ya sea en /etc/condor (ubicación especificada con el parámetro –local-dir durante la instalación) o en ~condor/.

Para este caso, el problema se resolverá mediante la segunda opción: creando un enlace al archivo de configuración desde ~condor/.

# ln -s /opt/condor/current/etc/condor_config ~condor/condor_config

Problema.

Condor no inicia en un nodo específico.  En sus logs se encuentran mensajes como los siguientes.

CollectorLog

08/11 21:59:35 AUTHENTICATE: handshake failed!
08/11 21:59:35 ERROR: SECMAN:2004:Failed to create security session to <192.168.1.230:9180> with TCP.|AUTHENTICATE:1002:Failure performing handshake|AUTHENTICATE:1004:Failed to authenticate using PASSWORD

MasterLog

08/11 22:00:36 DC_AUTHENTICATE: authenticate failed: AUTHENTICATE:1002:Failure performing handshake|AUTHENTICATE:1004:Failed to authenticate using PASSWORD
08/11 22:00:36 condor_write(): Socket closed when trying to write 297 bytes to <192.168.1.230:45838>, fd is 10
08/11 22:00:36 Buf::write(): condor_write() failed
08/11 22:00:36 SECMAN: Error sending response classad!
08/11 22:00:36 error: SEC_PASSWORD_FILE must be owned by Condor’s real uid

Explicación.

El archivo donde se almacena la contraseña del cluster para la autenticación basada en las mismas, tiene un propietario o unos permisos incorrectos.

Solución.

Identificar la ubicación del archivo de contraseñas.

# condor_config_val SEC_PASSWORD_FILE

/etc/condor/condor_credential

Verificar sus permisos y propietario.

# ls -l /etc/condor/condor_credential

-rw-r–r– 1 condor root 256 Aug 11 21:47 /etc/condor/condor_credential

Corregir sus permisos y propietario.

# chown root:root /etc/condor/condor_credential

# chmod 600 /etc/condor/condor_credential

# ls -l /etc/condor/condor_credential

-rw——- 1 root root 256 Aug 11 21:47 /etc/condor/condor_credential

Problema.

Al intentar enlazar un programa en C/C++ con las librerías de Condor mediante condor_compile se obtiene el siguiente mensaje de error.

$ condor_compile gcc test.c -o test

LINKING FOR CONDOR : /usr/bin/ld -L/opt/condor/current/lib -Bstatic –eh-frame-hdr -m elf_x86_64 –hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test /opt/condor/current/lib/condor_rt0.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginT.o -L/opt/condor/current/lib -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccawslhh.o /opt/condor/current/lib/libcondorzsyscall.a /opt/condor/current/lib/libcondor_z.a /opt/condor/current/lib/libcomp_libstdc++.a /opt/condor/current/lib/libcomp_libgcc.a /opt/condor/current/lib/libcomp_libgcc_eh.a –as-needed –no-as-needed -lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv -lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv -lcondor_c /opt/condor/current/lib/libcomp_libgcc.a /opt/condor/current/lib/libcomp_libgcc_eh.a –as-needed –no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o
/usr/bin/ld: skipping incompatible /opt/condor/current/lib/libcondor_c.a when searching for -lcondor_c
/usr/bin/ld: skipping incompatible /opt/condor/current/lib/libcondor_c.a when searching for -lcondor_c
/usr/bin/ld: cannot find -lcondor_c
collect2: ld returned 1 exit status

Explicación.

La arquitectura de la distribución de Condor no coincide con la de la máquina en la cual se instaló.

Solución.

Identifique la arquitectura de la máquina en la cual se está instalando Condor de la siguiente manera.

# uname -i

x86_64

Verifique que esta coincida con la arquitectura del paquete de Condor que se descargó del sitio web.

condor-*-linux-x86-rhel5-dynamic.tar.gz
condor-*-linux-x86_64-rhel5-dynamic.tar.gz

Reinstale Condor con la arquitectura correcta.