Después de bastante tiempo, hay una nueva versión de uno de mis juegos preferidos: Burbujas.  Esta vez para el escritorio y la web, desarrollado con Processing.  Por este motivo es necesario contar con la máquina virtual de Java para su ejecución.

Bubbles 2

El código del pequeño juego ha sido publicado bajo la licencia Attribution-NonCommercial motivo por el cual su código fuente puede ser obtenido, estudiado y modificado.

Misión.

El juego se trata de la mayor cantidad de burbujas posibles.  Al hacer esto se debe tener en cuenta que sólo es posible explotar grupos de burbujas que reunan a por lo menos dos burbujas del mismo tipo en cualquiera de las cuatro direcciones: norte, sur, oriente y occidente.

El primer disparo selecciona las burbujas del mismo tipo que se encuentren adyacentes y el segundo disparo las hace explotar.  La selección de las burbujas puede hacerse con el ratón o con las flechas del teclado y los disparos pueden hacerse con el clic derecho del ratón o con la barra de espacio del teclado.

Otras teclas útiles en el juego son R (reset) reinicia el juego, H (hint) modo de ayuda y Q (quit) termina la sesión de juego.

Enlaces.

• Jugar Burbujas 2.
  http://demo.jorgeivanmeza.com/Processing/Bubbles2/20100822/applet/
• Descargar el código fuente.
  http://demo.jorgeivanmeza.com/Processing/Bubbles2/20100822/
• Processing.
  http://www.processing.org/

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

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

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.

Al curso asistieron 18 participantes quienes representaban a las principales instituciones educativas y de investigación del eje cafetero que están interesadas en la computación de alto desempeño.

Los temas tratados durante el curso fueron los siguientes.

1. Introducción al proyecto y conceptual.
2. Instalación del cluster.
   1. Instalación del sistema operativo Scientific Linux 5.5.
   2. Preparación básica del nodo cabeza y de los nodos trabajadores.
   3. Configuración del servicio de SSH.
   4. Configuración del servicio de NFS.
   5. Configuración de las cuentas de usuario.
3. Instalación de Condor en el nodo cabeza y en los nodos trabajadores.
4. Pruebas y uso básico del cluster.
5. Universos del cluster.
   1. Vanilla.
   2. Standard.
   3. Java.
6. Seguridad del cluster con firewall y host.allow/deny.

Se realizó también un práctica adicional que consistió en el cambio del hostname de los nodos, analizándolo desde la perspectiva de su implicación en la configuración del cluster.  La práctica final que consistía en la instalación individual de nodos en máquinas virtuales basadas en VirtualBox no pudo completarse satisfactoriamente debido a problemas con el hardware con que disponíamos en las salas de cómputo.

Participantes del curso de clusters y grids en julio de 2010 en la Universidad Autónoma de Manizales

Durante los tres días siguientes al curso de clusters contamos con la presencia del ingeniero Cesar Orlando Diaz quien en representación del proyecto Grid Colombia, complementó la jornada al dictarnos un curso práctico acerca de la conformación de la grid basada en los clusters que habíamos preparado previamente.

En este segundo curso se trataron los siguientes temas.

1. Introducción conceptual.
2. Instalación del cliente de la grid.
3. Tipos de certificados requeridos.
4. Instalación y configuración del computer element (CE).
5. Instalación y configuración del grid user management system (GUMS).

Participantes del curso de clusters y grids en julio de 2010 en la Universidad Autónoma de Manizales

En lo personal quiero agradecer a los participantes del curso por la asistencia al evento y felicitarlos por contar con la visión necesaria para aprovechar estas nuevas tecnologías, ya presentes en nuestra región: redes académicas de alta velocidad, computación de alto desempeño y mallas computacionales, a su quehacer diario, encontrando mejores formas de hacer las cosas, innovando y mejorando el progreso de nuestra región.

Los contenidos del curso y en general, del proyecto GridUAM pueden ser consultados en su Wiki, el cual está en constante complemento y actualización.  De igual manera recomiendo que sea consultado el Wiki de GridColombia para conocer mas información acerca de este proyecto.

Después de instalar OpenSim 0.7 el paso siguiente es verificar su funcionamiento.  Para esto se probaron los siguientes 4 visores compatibles con Second Life/OpenSim.

1. Second Life Client (1.23.5.136262).
2. Second Life Client (2.1.0.207030).
3. SnowGlobe (2.0.2.3576).
4. Hippo OpenSim Viewer (0.6.3).

Second Life Client v1	Second Life Client v2
SnowGlobe v2	Hippo OpenSim Viewer v0.6

Instalación y ejecución.

Todos, a excepción del Hippo, para instalarse deben simplemente descomprimirse en el directorio donde residirán finalmente.  Por el contrario, cuando se descomprime Hippo se obtiene un instalador, el cual al ejecutarse pregunta a través de diálogos la ubicación final donde se instalará el visor.

De manera similar, todos, a excepción de Hippo, se ejecutan de la siguiente manera.

$ ./<visor> -loginuri http://<host>:<port>

Donde <visor> es el archivo ejecutable (secondlife o snowglobe), <host> es el nombre o dirección IP del servidor de OpenSim y <port> es el puerto donde se está ejecutando el servicio (9000 por defecto).

Nuevamente Hippo se diferencia del resto ya que incluye desde su interfaz grafica (Edit > Preferences > Grids) la capacidad de administrar las grids a las cuales se va a realizar conexiones.

Hippo OpenSim Viewer, grid configuration

Conclusiones.

En una revisión rápida se encuentran las siguientes conclusiones.

• Aparentemente Second Life Client v1 y Hippo OpenSim Client se encuentran basados sobre la versión del software base, mientras que les sucede lo mismo al Second Life Client v2 y al SnowGlobe.
• Los clientes Second Life Client v2 y SnowGlobe presentan problemas para descargar y manipular el skin del avatar, así que en su defecto muestran una nube o un huevito (en gráficos con calidad menor).
• Debe tenerse en cuenta que la prueba se realizó desde un portátil con una tarjeta gráfica de muy bajo perfil (Intel 965) y que con una mejor configuración de hardware los resultados pueden variar.

Enlaces.

• Second Life Viewer.
  http://secondlife.com/support/downloads/
• SnowGlobe.
  http://snowglobeproject.org/
• Hippo OpenSim Viewer.
  http://mjm-labs.com/viewer/
• Connect to OpenSim.
  http://opensimulator.org/wiki/Configuration#Connecting_to_OpenSim

OpenSimulator es un servidor de aplicaciones 3D que puede ser utilizado para crear ambientes o mundos virtuales los cuales pueden ser accedidos a través de una variedad de clientes y  protocolos. Permite realizar los desarrollos con las tecnologías mas habituales gracias a un diseño flexible, fácilmente extendible mediante módulos cargables para crear con ellos configuraciones completamente personalizadas.  Este software se licencia bajo la BSD License, lo que permite que sea incluído en paquetes de código abierto o comerciales.   Por defecto, OpenSimulator puede simular un entorno virtual de Second Life™ (incluyendo la compatibilidad con su cliente). Otros ambientes, protocolos y características pueden ser soportadas mediante módulos añadidos.

Tomado de http://opensimulator.org/.

Instalar Mono.

# pacman -S mono unzip

# mono --version

Mono JIT compiler version 2.6.7 (tarball Sun Jul 25 19:50:39 CEST 2010)
Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com
TLS:           __thread
GC:            Included Boehm (with typed GC and Parallel Mark)
SIGSEGV:       altstack
Notifications: epoll
Architecture:  amd64
Disabled:      none

# vi /etc/rc.conf

DAEMONS=(... mono)

Crear usuario opensim.

# /usr/sbin/useradd -m -g users -s /bin/bash -c “OpenSimulator” opensim

# passwd -l opensim

Instalar OpenSim.

# wget http://dist.opensimulator.org/opensim-0.7-bin.tar.gz

# tar zxvf opensim-0.7-bin.tar.gz

# mv opensim-0.7-bin /home/opensim/0.7

# chown -R opensim:users /home/opensim/0.7

# ln -s /home/opensim/0.7 /opt/opensim

Iniciar OpenSim.

# su -c /opt/opensim/bin/opensim-ode.sh opensim

Configurar OpenSim por primera vez.

=====================================
We are now going to ask a couple of questions about your region.

You can press ‘enter’ without typing anything to use the default

the default is displayed between [ ]: brackets.
=====================================

New region name []: Playing Region
Region UUID [18d5fc00-1452-4876-bb46-6f75c06387a6]:
Region Location [1000,1000]:
Internal IP address [0.0.0.0]:
Internal port [9000]:
Allow alternate ports [False]:
External host name [SYSTEMIP]:

Your region is not part of an estate.
Do you wish to join an existing estate? [no]:
New estate name [My Estate]: Playing Estate

The current estate has no owner set.
Estate owner first name [Test]: Master
Estate owner last name [User]: Player
Password: testing
Email []:

Enlaces.

• Open Simulator.
  http://opensimulator.org/
  • Descargar.
    http://opensimulator.org/wiki/Download
  • Archivos de la distribución.
    http://dist.opensimulator.org/
• Running OpenSim for first time.
  http://opensimulator.org/wiki/Configuration#Running_OpenSim_for_the_first_time
• Instalación OpenSimulator 0.7 RC2.
  http://www.marlonj.com/blog/2010/07/pulsar-project-instalacion-opensimulator-0-7-rc-2/
• Mono, ArchLinux.
  http://wiki.archlinux.org/index.php/Mono

Una de las características interesantes de ArchLinux es que la instalación básica incluye únicamente los paquetes realmente necesarios para su funcionamiento inicial, siendo responsabilidad del administrador instalar los demás paquetes que se requieran.  Esto es muy importante ya que, a diferencia de otras distribuciones, se disminuye el tiempo de instalación, el consumo de recursos y se reducen los riesgos de seguridad.

ArchLinux inclusive no incluye por defecto el servicio de SSH el cual debe ser instalado manualmente.  En ese artículo se describe el proceso de instalación y configuración del servicio de SSH en ArchLinux.

Instalación.

# pacman -S openssh

Configuración.

Configuración del cliente.

# vi /etc/ssh/ssh_config

Port 22
Protocol 2
HashKnownHosts yes
StrictHostKeyChecking ask

Configuración del servidor.

# vi /etc/ssh/sshd_config

Port 22
Protocol 2
LoginGraceTime 2m
PermitRootLogin no

Configuración del servicio.

Configurar el inicio automático con el sistema operativo.

# vi /etc/rc.conf

DAEMONS=(... sshd)

Iniciarlo, detenerlo o reiniciarlo manualmente.

# /etc/rc.d/sshd {start|stop|restart}

Permitir el acceso al servicio desde otros equipos.

# vi /etc/hosts.allow

sshd: 192.168.1.

Enlaces.

• Servicio de SSH, ArchLinux.
  http://wiki.archlinux.org/index.php/SSH

$ sudo aptitude install build-essential

ArchLinux.

# pacman -S base-devel

ArchLinux es una distribución que me sigue pareciendo interesante, especialmente por su rapidez y transparencia en términos de los paquetes que instala: únicamente los solicitados.  Por ahora es la distribución que estoy utilizando para hacer las pruebas y experimentos que se me ocurren, a excepción del proyecto de Grid que requiere explícitamente utilizar nodos con Scientific Linux.

Aparentemente esta distribución no se encuentra basada en ninguna otra que haya utilizado anteriormente, esto trae para mi un agradable obstáculo ya que desconozco como realizar la mayoría de los procedimientos habituales como cambiar el hostname, activar sudo o actualizar sus paquetes entre muchas otras cosas.  Así que todo es nuevo y todo debe ser explorado y experimentado lo que me hace evocar recuerdos de hace mas de 10 años cuando cuando me iniciaba en el uso de Linux.

En este artículo se describe como realizar la configuración de una dirección IP dinámica gracias a DHCP y su contraparte estática, la cual tiene un detalle muy pequeño pero importante con su puerta de enlace.

Procedimiento.

Configuración de la IP dinámica.

# vi /etc/rc.conf

eth0=”dhcp”
INTERFACES=(eth0)

Configuración de una IP estática.

# vi /etc/rc.conf

eth0=”eth0 192.168.1.222 netmask 255.255.255.0 broadcast 192.168.1.255”
INTERFACES=(eth0)
gateway=”default gw 192.168.1.1”
ROUTES=(gateway)

Nótese que se removió el símbolo (!) de la variable gateway en la asignación de ROUTES, si esto no se realiza, el enrrutador por defecto no será agregado a las rutas estáticas definidas al inicio del sistema operativo.