Subsecciones

- 5.6.1 Instalación
  - Instalación desde paquetes RPM
  - Instalación desde las fuentes
- 5.6.2 Utilizando openMosixview
  - Aplicación principal
  - La ventana de configuración
  - Ejecución avanzada
  - La línea de comandos
  - El host-chooser
  - El host-chooser paralelo
- 5.6.3 openMosixprocs
  - Introducción
  - La ventana de migración
  - Administrando procesos remotamente
- 5.6.4 openMosixcollector
- 5.6.5 openMosixanalyzer
  - Una visión general de la carga del sistema
  - Estadísticas sobre los nodos del cluster
  - Monitorización de la memoria
- 5.6.6 openMosixhistory
- 5.6.7 openMosixview + SSH2
- 5.6.8 FAQ de openMosixview -preguntas más frecuentes

# 5.6 OPENMOSIXVIEW

El entorno openMosixview es la siguiente versión (y totalmente reescrita) de Mosixiew.

Es una interfície gráfica (GUI) libre para la adminstración y mantenimiento de un cluster openMosix que podemos bajarnos de la web del proyecto5.9.

La suite openMosixview contiene 7 aplicaciones altamente útiles y eficaces tanto para la administración como para la monitorización del cluster.

- openMosixview principal aplicación de monitorización y administración.
- openMosixprocs aplicación para la administración de procesos.
- openMosixcollector captura la información del cluster proporcionada por los demonios.
- openMosixanalyzer analizador de la información capturada por openMosixcollector.
- openMosixhistory historial de monitorización de procesos del cluster.
- openMosixmigmon visor que representa la migración de procesos.
- 3dmosmon visor para monitorización de datos en 3D.

Todos los componentes son accesibles desde la ventana de la aplicación principal. Este entorno facilita la interacción con el usuario puesto que le permite ejecutar los comandos de consola más comunes con unos pocos clicks de ratón.

## 5.6.1 Instalación

Requerimientos:

- tener instaladas las librerías QT según marque la versión,
- derechos de superusuario -root-,
- las herramientas de usuario de openMosix -userland-tools-.

### Instalación desde paquetes RPM

Los paquetes RPM tienen como directorio de instalación la ruta /usr/local/openMosixview-versión. Tras bajar la última versión de los paquetes RPM de openMosixview, habrá que instalarlos como cualquier otro paquete, sea desde l'inea de comandos:

`rpm -i openMosixview-versión-distribución.rpm`

Esto nos instalará los ficheros binarios en el directorio /usr/bin/. Para desinstalarlos ejecutaremos

`rpm -e openMosixview`

### Instalación desde las fuentes

Con la versión en forma de tarball y lo descomprimiremos -y desempaquetaremos- así:

`tar -zxvf openMosixview-versión.tar.gz`

SCRIPT DE CONFIGURACIÓN AUTOMÁTICO

Sólo será necesario entrar al directorio openMosixview y ejecutar:

`./setup [directorio_de_instalación_qt_versión]`

COMPILACIÓN MANUAL

Será necesario situar la variable QTDIR hacia el directorio de la distribución QT, por ejemplo:

`export QTDIR=/usr/lib/qt-2.3.0 (para bash)`

ó

`setenv QTDIR /usr/lib/qt-2.3.0 (para csh)`

Tras lo qual tendría que ejecutar con éxito la configuración y la compilación:

`./configure`

`make`

Luego será necesario hacer lo mismo en los subdirectorios de openMosixcollector, openMosixanalyzer, openMosixhistory and openMosixviewprocs, para poder disponer de los binarios ejecutables de estas aplicaciones. Tras este procedimiento copiaremos todos los binarios a /usr/bin/ siguiendo:

`cp openMosixview/openMosixview /usr/bin`

`cp openMosixviewproc/openMosixviewprocs/mosixviewprocs /usr/bin`

`cp openMosixcollector/openMosixcollector/openMosixcollector /usr/bin`

`cp openMosixanalyzer/openMosixanalyzer/openMosixanalyzer /usr/bin`

`cp openMosixhistory/openMosixhistory/openMosixhistory /usr/bin`

y el script de iniciación de `openMosixcollector` en el directorio de iniciación5.10:

`cp openMosixcollector/openMosixcollector.init /etc/init.d/openMosixcollector`

Ahora, si queremos que estas aplicaciones de monitorización puedan ejecutarse localmente en cualquier nodo, tendrán que copiarse los binarios a cada nodo del cluster -en el directorio /usr/bin/

## 5.6.2 Utilizando openMosixview

### Aplicación principal

Figura: openMosixview: Aplicación principal

La `Figura` muestra la ventana de la aplicación. El usuario podrá interaccionar con el API de openMosix a través de sus controles. Para cada nodo del cluster -cada fila-: una luz, un botón, un speed-slider, un número lcd, dos barras de progreso porcentual y un par de etiquetas.

Las luces de la izquierda nos muestran el ID del nodo y su estado. El fondo rojo significa que el nodo no se encuentra operativo, y verde lo contrario.

Si hacemos clic en el botón que muestra la dirección IP de un nodo habremos invocado al diálogo de configuración que nos mostrará los botones para ejecutar los comandos de `mosctl` más comunes -ver sección Las herramientas de área de usuario del capítulo 5.

Con los speed-sliders podemos establecer la velocidad que considerará el cluster para cada nodo. Este parámetro se muestra numéricamente en el display lcd dse su derecha. Hay que tener en cuenta que estos ajustes tienen un efecto directo sobre el algoritmo de balanceo de carga de openMosix, puesto que intervienen en la ponderación de velocidad que se debe considerar para cada nodo. De esta manera los procesos migrarán más fácilmente hacia un nodo cuya velocidad sea más elevada. Recordemos que este concepto de velocidad no tiene que ser el que realmente posea la computadora, es simplemente el parámetro que queremos que openMosix considere para cada máquina.

Las barras de progreso dan una idea general de la carga de cada nodo del cluster. La primera se refiere a la carga del procesador y muestra un porcentaje que será una aproximación del valor escrito por openMosix en el fichero /proc/hpc/nodes/x/load. La segunda barra nos muestra la memoria utilizada en cada nodo. El box de la izquierda nos muestra el total de memoria -en megabytes- que posee cada nodo. Finalmente el último box muestra el número de procesadores de cada nodo.

Hasta ahora se ha definido la interfaz para cada nodo en particular, no obstante la misma aplicación muestra información general del cluster.

El box load-balancing efficiency es un indicador de la eficiencia del algoritmo de balanceo de carga. Un valor próximo al 100% indica que la carga computacional ha podido dividirse equitativamente entre los nodos; este es precisamente el fin que persigue openMosix.

Bajo la barra de menús existen varios iconos que lanzan las demás aplicaciones del entorno openMosixview. Podemos utilizar los menús de `collector-` y `analyzer-` para administrar openMosixcollector y openMosixanalyzer, respectivamente.

Estas dos partes de las aplicaciones openMosixview son muy adecuadas para construir un historial del trabajo hecho -y la manera en como se ha hecho- en el cluster. Cuando hagamos iniciado la captura de datos el led etiquetado como `openMosixcollector status` se mostrará verde.

### La ventana de configuración

Figura: openMosixview: Propiedades de los nodos

Esta ventana emergente de la `Figura` aparecerá tras hacer clic en el botón de la IP de cualquier nodo, permite una fáci configuración de la máquina con dicha dirección.

Todos los comandos que esta ventana invoca pueden ser ejecutados a través de rsh o ssh en los nodos remotos -y también en el nodo local, evidentemente- siendo root y sin necesidad de contraseñas.

Si hay instalado `openMosixprocs` en los nodos remotos del cluster podremos clicar en el botón remote proc-box para invocar openMosixprocs remotamente.

Se nos mostrará en pantalla los parámetros [xhost+hostname] y serán configurados para apuntar a nuestro nodo local. Además el cliente es ejecutado en el remoto con rsh o ssh (recordemos que tendríamos que tener copiados los binarios de openmsoxiprocs en el directorio /usr/bin de cada nodo).

openMosixprocs nos permitirá una administración de nuestros programas.

Si hemos entrado a nuestro cluster desde una estación de trabajo remota podremos introducir nuestro nombre de nodo local en la edit-box, debajo de la remote proc-box. Luego openMosixprocs se nos mostrará en nuestra estación de trabajo y no en el nodo del cluster donde hemos entrado (podemos configurar [xhost+clusternode] en nuestra estación de trabajo). Podemos encontrar un historial en el combo-box así como el nombre de nodo que hayamos escrito.

### Ejecución avanzada

Si queremos iniciar trabajos en nuestro cluster el diálogo de advanced execution mostrado en la `Figura 3` podrá ayudarnos para convertirlo a modo gráfico.

Figura: openMosixview: Ejecución avanzada

Elegiremos el programa a iniciar con el botón `run-prog` (en File-Open-Icon) y especificaremos cuál y donde se encuentra el trabajo que queremos iniciar en este diálogo de ejecución. Hay diferentes opciones que se describen en la próxima tabla.

### La línea de comandos

Podremos especificar los argumentos a los que antes podíamos acceder gráficamente a través de comandos en el lineedit-widget en la parte superior de la ventana, tal como se muestra en la `Figura 3`.

Tabla: openMosixview: Condiciones de inicio avanzadas para procesos

no migration | iniciar un proceso local que no migrará
run home | iniciar un proceso local
run on | iniciar un trabajo en el nodo que elijamos con "nodo-chooser"
cpu job | iniciar un proceso cpu-intensivo en el nodo (nodo-chooser)
io job | iniciar un proceso IO-intensivo en el nodo (nodo-chooser)
no decay | iniciar un proceso sin decay (nodo-chooser)
slow decay | iniciar un proceso con decay lento (nodo-chooser)
fast decay | iniciar un proceso con decay rápido (nodo-chooser)
parallel | iniciar un proceso paralelo en todos o algunos nodos (special nodo-chooser)

### El host-chooser

Para todas las tareas que ejecutemos de manera remota sólo tenemos que elegir un nodo que la hospede con el dial-widget. El ID de openMosix del nodo se nos muestra también en forma de lcd. Luego pulsaremos execute para iniciar el trabajo.

### El host-chooser paralelo

Podemos configurar el primer y el último nodo con 2 spinboxes. Luego el comando será ejecutado en todos los nodos, desde el primero hasta el último. Podremos también invertir esta opción.

## 5.6.3 openMosixprocs

### Introducción

La ventana de procesos mostrada en la `Figura 4` es muy útil para la administración de los procesos de nuestro cluster.

Figura: openMosixprocs: Administración de procesos

Deberemos instalar esta aplicación en cada nodo. La lista de procesos da una idea de lo que se está ejecutando y donde. La segunda columna informa del ID del nodo donde se está ejecutando la tarea. Con un doble clic sobre cualquier proceso invocaremos la ventana para administrar su migración (siguiente figura).

Un `'0'` significa 'local', los demás valores significan 'remoto'. Los procesos migrados están marcados con un icono verde y a los procesos que no pueden migrar se les añade un cerradero.

Hay también varias opciones para migrar el proceso remoto: enviarle las señales SIGSTOP y SIGCONT o simplemente cambiarle la prioridad, con el comando `nice` por ejemplo.

Si hacemos clic en el botón manage procs from remote invocaremos a una ventana emergente (llamada remote-procs windows) que nos mostrará el proceso actualmente migrado hacia ese nodo.

### La ventana de migración

El diálogo de la `Figura 5` emergerá si clicamos sobre cualquier proceso en la ventana anterior.

Figura: openMosixprocs: La ventana de migrado de un proceso(1)

La ventana openMosixview-migrator muestra todos los nodos de nuestro cluster, arriba a la izquierda. Esta ventana sirve para administrar un proceso (con información adicional).

Si hacemos doble clic en un nodo migrará a este nodo.

Tras breves instantes el icono del proceso cambiará a verde, lo que significa que está siendo ejecutado remotamente.

El botón home envia un proceso a su nodo raíz. Con el botón best el proceso será enviado hacia el mejor nodo disponible en el cluster.

Esta migración se ve influenciada por la carga, velocidad, número de procesadores y su mayor o menor velocidad. Con el botón kill mataremos al proceso.

Para pausar un programa sólo tendremos que pulsar en el botón etiquetado como SIGSTOP y para reanudarlo, en SIGCONT.

Con el slider de `renice` podremos cambiar la prioridad de los procesos para una administración más completa, así el valor -20 se traduce en una mayor prioridad para terminar el trabajo, 0 le da prioridad normal y 20 le sitúa en una prioridad muy baja para tratarlo.

### Administrando procesos remotamente

El diálogo mostrado en la `Figura 6` aparecerá si clicamos en el botón manage procs from remote.

Figura: openMosixprocs: La ventana de migrado de un proceso(2)

Las pestañas muestran los procesos que han migrado al nodo local. De forma parecida a los 2 botones en la ventana de migrado, el proceso será enviado a su nodo raíz si pulsamos goto home node y enviado al mejor nodo si pulsamos goto best node.

## 5.6.4 openMosixcollector

openMosixcollector es un daemon (demonio) que debe/puede ser invocado en cualquier miembro del cluster.

Genera un historial de la carga de cada nodo del cluster al directorio /tmp/openMosixcollector/* Este historial puede servir de entrada para openMosixanalyser (explicado posteriormente) para ofrecer una vista general de la carga, memoria y procesos en nuestro nodo durante un intervalo de tiempo.

Existe otro historial principal llamado /tmp/openMosixcollector/cluster

Y adicionalemnte a éstos existen ficheros en los directorios donde se escriben los datos.

Al iniciar, openMosixcollector escribe su PID (ID del proceso) en /var/run/openMosixcollector.pid

El demonio de openMosixcollector reinicia cada 12 horas y guarda el actual historial a /tmp/openMosixcollector[date]/* Estos backups se hacen automaticamente pero siempre podremos lanzarlos manualmente.

Hay una opción que permite escribir un checkpoint al historial. Estos checkpoints podemos verlos gráficamente como una fina línea azul vertical si analizamos el historial con openMosixanalyser. Por ejemplo podemos poner un checkpoint cuando iniciamos cierto trabajo en el cluster y otro cuando éste finaliza.

Aquí tenemos una referencia de los posibles argumentos para la consola:

`openMosixcollector -d` //inicia el collector como un daemon
`openMosixcollector -k` //detiene el collector
`openMosixcollector -n` //escribe un checkpoint en el historial
`openMosixcollector -r` //guarda el actual historial y empieza uno de nuevo
`openMosixcollector` //saca por la salida estándar una ayuda rápida

Podemos iniciar este demonio con su script de iniciación, que se encuentra en /etc/init.d o en /etc/rc.d/init.d Hemos de tener un enlace simbólico a uno de los runlevels para un inicio automático.

La forma para analizar los historiales creados la describimos en la siguiente sección, el openMosixanalyzer.

## 5.6.5 openMosixanalyzer

### Una visión general de la carga del sistema

La siguiente figura nos muestra de forma gráfica la carga en el openMosixanalyzer.

Figura: openMosixanalyzer. Historial de actividad de procesamiento del cluster

Con el openMosixanalyzer tendremos un historial contínuo de nuestro cluster. Los historiales generados por openMosixcollector se mostrarán ahora de forma gráfica, además de contínua, lo que nos permitirá ver la evolución del rendimiento y demás parámetros de nuestro cluster a través del tiempo. openMosixanalyzer puede analizar los historiales a tiempo real (datos generados a tiempo real) y evidentemente también puede abrir antiguos backups con el menu File.

Los historiales serán guardados en /tmp/openMosixcollector/* (y los backups los tendremos en
/tmp/openMosixcollector[date]/*) y sólo tendremos que abrir el historial principal del cluster para visualizar antiguos historiales de informaciones de carga. (el campo [date] en los ficheros de backup se refiere a la fecha en que han sido guardados)

La hora de inicio del backup podemos verla en la parte superior.

Si utilizamos openMosixanalyzer para tratar historiales a tiempo real tendremos que activar el check refresh para que se actualice automáticamente.

Las líneas que indican la carga son normalmente de color negro. Si la carga se incrementa a 75 las líneas se volverán rojas.
Estos valores se obtienen desde los ficheros /proc/hpc/nodes/[openMosix ID]/*

El botón Find-out de cada nodo calcula diversos valores para las estadísticas. Si lo clicamos abriremos una nueva ventana en la cual veremos las medias de la carga y memoria y algunas informaciones adicionales (estáticas y dinámicas) sobre el nodo en concreto.

### Estadísticas sobre los nodos del cluster

Figura: openMosixanalyzer. Estadísticas de los nodos

Si hay checkpoints escritos en el historial (generado por openMosixcollector) podremos verlos traducidos como líneas azules verticales. Esto permite comparar valores de carga a posteriori de forma fácil. Véase la `Figura 8`.

### Monitorización de la memoria

Figura: openMosixanalyzer. Historial de actividad de memoria de nuestro cluster

La `Figura 9` muestra las gráficas de memoria proporcionadas por openMosixanalyzer

La filosofía de monitorización de la memoria es idéntica a la explicada anteriormente con la carga y evidentemente sirven también para poder ver como se ha comportado openMosix para administrar nuestros recursos de memoria, en este caso.

Igualmente podemos tener un monitorización a tiempo real o abrir antiguos historiales.

Para mostrar sus gráficas, openMosixnalyzer obtiene información de estos ficheros

/proc/hpc/nodes/[openMosix-ID]/mem.
/proc/hpc/nodes/[openMosix-ID]/rmem.
/proc/hpc/nodes/[openMosix-ID]/tmem.

Los checkpoints se muestran de igual forma que en la carga, con fina líneas verticales de color azul.

## 5.6.6 openMosixhistory

Figura: openMosixhistory. Un historial de los procesos ejecutados

Con openMosixhistory podremos acceder a la lista de procesos ejecutados en el pasado, véase `Figura 10`. Conseguiremos un lista de los procesos que se ejecutaron en cada nodo. openMosixcollector guarda la lista de procesos de cada nodo cuando lo iniciamos y con el openMosixhistory podremos navegar en dicha información para ver el comportamiento que desarrolló nuestro cluster.

Podremos cambiar facilmente el tiempo de navegación con un slider situado en la parte superior, para así ajustar la ventana del pasado.

openMosixhistory puede analizar en tiempo real los historiales, y también abrir antiguos de forma idéntica a como lo hemos podido hacer en los otros analizadores de datos explicados anteriormente.

Los historiales se obtienen nuevamente de /tmp/openMosixcollector/* y sólo tendremos que abrir el historial principal para poder navegar en los ficheros de información sobre la carga dada tiempo atrás.

El tiempo de inicio del monitorización podemos verlo en la parte superior y tenemos 12 horas de vista.

## 5.6.7 openMosixview + SSH2

Texto original Matthias Rechenburg. Todo error tipográfico, gramatical, semántico u ortográfico envíenlo al traductor: Marcelo (`kuntx@kx99.hn.org`).

Usted puede leer la razón por la que debe usar SSH en vez de RSH cada día en el diario, cuando otro script-kiddy haya hackeado un sistema/red inseguro. Entonces se dará cuenta que SSH es una buena decisión después de todo.

Libertad x seguridad = constante (sacado de un grupo de noticias de seguridad.)

Es por eso que es un poco difícil de instalar SSH. SSH es seguro incluso si usted lo usa para logarse sin usar contraseña. Seguidamente daremos una forma de como configuralo.

En principio es requerido que este corriendo el demonio del secure-shell.

Si no está instalado instálelo.

`rpm -i [sshd_rpm_package_from_your_linux_distribution_cd]`

Si no está ya corriendo inícielo con:

`/etc/init.d/ssh start`

Ahora usted debe generar en su computadora un par de llaves para el ssh hagalo con:

`ssh-keygen`

Se le pedirá una frase de contraseña para ese par de llaves creado. La frase de contraseña es normalmente más larga que la contraseña incluso llegando quizás a ser una oración completa. El par de llaves es encriptado con esa frase de contraseña y guardado en:
root/.ssh/identity`//su llave privada`
/root/.ssh/identity.pub`//su llave pública`
¡¡No le entregue su llave privada a nadie!!

Ahora copie el contenido completo de /root/.ssh/identity.pub (su llave pública que debería tener una longitud de una línea) en /root/.ssh/authorized_keys al host remoto (también copie el contenido de /root/.ssh/identity.pub a su (local)/root/.ssh/authorized_keys como usted hizo con el nodo remoto, debido a que openMosixview necesita logar al nodo local sin que se le pida una contraseña.

Si ahora usted se trata de conectar mediante ssh al host remoto se le preguntará por la frase de contraseña de su llave pública respondiendo correctamente debería poder loguearse. ¿Cuál es la ventaja entonces?
La frase de contraseña es normalmente más larga que la contraseña.
La ventaja usted la puede obtener usando el ssh-agent. Éste maneja la frase de contraseña durante el ssh login: `ssh-agent`

El ssh-agent es iniciado y entrega 2 variables de entorno Usted debe configurarlas (si no lo estan ya), escriba:

`echo $SSH_AUTH_SOCK`
y
`echo $SSH_AGENT_PID`
para ver si han sido exportadas a su shell. Si esto no es así corte y péguelas desde su terminal de la siguiente forma:

- Para bash-shell:

      SSH_AUTH_SOCK=/tmp/ssh-XXYqbMRe/agent.1065
      export SSH_AUTH_SOCK
      SSH_AGENT_PID=1066
      export SSH_AGENT_PID

- Para csh-shell:

      setenv SSH_AUTH_SOCK /tmp/ssh-XXYqbMRe/agent.1065
      setenv SSH_AGENT_PID 1066

Con estas variables el demonio sshd remoto puede conectarse a su ssh-agent local usando el archivo socket en /tmp (en este ejemplo /tmp/ssh-XXYqbMRe/agent.1065). El ssh-agent ahora puede darle la frase de contraseña al host remoto usando este socket (obviamente es una transferencia encriptada).

Usted apenas tiene que agregar su llave pública al ssh-agent con el comando ssh-add:

`ssh-add`

Ahora usted debe poder logarse usando ssh al host remoto sin que se le pida contraseña alguna. Usted puede (debe) agregar los comandos ssh-agent y ssh-add a su login profile:

`eval `ssh-agent``

`ssh-add`

Con ello será iniciado cada vez que se loguee en su estación de trabajo local. Felicidades, le deseo que tenga logins seguros de ahora en más con openMosixview.

Finalmente y ya para terminar con este COMO, hay una entrada en el menú de openmosixView que permite seleccionar con que trabajar rsh/ssh, actívela y usted prodrá usar openMosixview incluso en redes inseguras.También debe grabar esta configuración, (la posibilidad de grabar la configuración actual en openMosixview fue agregada a partir de la versión 0.7), porque toma datos de inicio del esclavo usando rsh ó ssh ( como usted lo haya configurado). Si usted elige un servicio que no está instalado correctamente openMosixview no funcionará.

Si usted no se puede conectar mediante rsh a un esclavo sin que se le pida una contraseña usted no podrá usar openMosixview con RSH.

Si usted no se puede conectar mediante ssh a un esclavo sin que se le pida una contraseña usted no podrá usar openMosixview con SSH.
Como creado por M. Rechenburg. Me olvidé de algo? Seguro. Envíeme un mail seguramente será agregado.

## 5.6.8 FAQ de openMosixview -preguntas más frecuentes

¡No puedo compilar openMosixview en mi equipo!

Antes que nada, como ya se ha comentado, es fundamental disponer de las librerías QT=2.3.x.

La variable de entorno QTDIR tiene que estar configurada en QT-installation como se describe en el fichero de instalación INSTALL.

En versiones anteriores a la 0.6 podemos ejecutar `make clean` y borrar los dos ficheros:

    /openmosixview/Makefile
    /openmosixview/config.cache

y probar ahora de compilar otra vez ya que el autor, Matt Rechenburg, ha dejado los binarios y los objetos en estas versiones más antiguas.

En caso de tener otro tipo de problemas podemos postear en la lista de correo o directamente informar al autor.

¿Puedo utilizar openMosixview con SSH?

Sí desde la versión 0.7 se ha incorporado soporte para SSH.
Tendr'iamos que ser capaces de acceder con ssh a cada nodo del cluster sin contraseña (lo mismo que es requerido para un acceso con rsh).

He intentado iniciar openMosixview pero se me bloquea antes de iniciarse. ¿Qué he hecho mal?

No deberemos ejecutar openMosixview en background, esto es llamarlo desde la consola con el comando `openMosixview&`.

También puede darse el caso que no podamos acceder a él a través de rsh/ssh (dependiendo de lo que usemos) como root sin contraseñas. Entonces deberíamos probar el comando `rsh hostname` como root. No se nos debería pedir ninguna contraseña pero se nos mostrará el shell para entrar nuestro login (nombre de usuario). Si estamos utilizando SSH el comando sería `ssh hostname`.

Tendremos que poder acceder como root en el sistema porque es el único modo de poder ejecutar los comandos administrativos que openMosixview requiere.

Si sólo tuviéramos instalado SSH en nuestro cluster, crearemos el fivhero /root/.openMosixview y escribiremos `1111` en él.

Éste es el fichero de configuración principal y el último `1` se refiere a utilizar ssh en lugar de rsh.

El cliente openMosixviewprocs/mosixview_client no funciona.

El cliente openMosixview_client se ejecuta por rsh (o ssh, lo que tengamos configurado) en el host remoto. Debe estar instalado en /usr/bin/ en cada nodo.

Si usamos RSH podemos probar

`xhost +hostname`

`rsh hostname /usr/bin/openMosixview_client -display nombre_de_host_local:0.0`

y si usamos SSH

`xhost +hostname`

`ssh hostname /usr/bin/openMosixview_client -display nombre_de_host_local:0.0`

Si esto funciona funcionará también en openMosixview.

openMosixview genera un segmentation fault

Puede que estemos utilizando versiones antiguas de openMosixview.

¿Por qué los botones del diálogo openMosixview-configuration no están preseleccionados? (automigración on/off, bloqueo on/off...)

Sería preferible que estuviesen preseleccionados, el problema se encuentra al obtener información del nodo.

Tenemos que logar en cada nodo ya que esta información no se encuentra dentro del cluster en sí .

El estado de cada nodo se guarda en el directorio /proc/hpc/admin/ de cada nodo.