Habilidades en Datos Bioinformáticos

Capítulo 4. Trabajar con máquinas remotas

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

La mayoría de las tareas de procesamiento de datos en bioinformática requieren más potencia de cálculo de la que tenemos en nuestras estaciones de trabajo, lo que significa que debemos trabajar con grandes servidores o clusters informáticos. Para algunos proyectos bioinformáticos, es probable que trabajes predominantemente a través de una conexión de red con máquinas remotas. Como es lógico, trabajar con máquinas remotas puede ser bastante frustrante para los principiantes y puede lastrar la productividad de los bioinformáticos experimentados. En este capítulo, aprenderemos a trabajar con máquinas remotas con el menor esfuerzo posible, para que puedas centrar tu tiempo y tus esfuerzos en el propio proyecto.

Conectarse a máquinas remotas con SSH

Hay muchas formas de conectarse a otra máquina a través de una red, pero la más común con diferencia es mediante el shell seguro(SSH). Utilizamos SSH porque está encriptado (lo que hace que sea seguro enviar contraseñas, editar archivos privados, etc.), y porque está en todos los sistemas Unix. Cómo se configuran tu servidor, SSH y tu cuenta de usuario es algo que tú o el administrador de tu sistema determináis; este capítulo no cubrirá estos temas de administración del sistema. El material cubierto en esta sección debería ayudarte a responder a las preguntas habituales sobre SSH que pueda hacerte un administrador del sistema (por ejemplo, "¿Tienes una clave pública SSH?"). También aprenderás todo lo básico que necesitarás como bioinformático para acceder por SSH a máquinas remotas.

Para inicializar una conexión SSH a un host (en este caso, biocluster.miuniversidad.edu), utilizamos en el comando ssh:

$ ssh biocluster.myuniversity.edu
Password: 
Last login: Sun Aug 11 11:57:59 2013 from fisher.myisp.com
[e-mail]$ 

Cuando te conectes a un host remoto con SSH, se te pedirá la contraseña de tu cuenta de usuario remota.

Después de iniciar sesión con tu contraseña, se te concederá un intérprete de comandos en el host remoto. Esto te permite ejecutar comandos en el servidor remoto de la misma forma que los ejecutarías localmente.

SSH también funciona con direcciones IP: por ejemplo,. Podrías conectarte a una máquina con ssh 192.169.237.42. Si tu servidor utiliza un puerto diferente al predeterminado (puerto 22), o tu nombre de usuario en la máquina remota es diferente de tu nombre de usuario local, tendrás que especificar estos detalles al conectarte:

$ ssh -p 50453 [e-mail]

Aquí, hemos especificado el puerto con la bandera -p y el nombre de usuario utilizando la sintaxis user@domain. Si no puedes conectarte a un host, utilizarssh -v (-v para verbosidad) puede ayudarte a detectar el problema. Puedes aumentar la verbosidad utilizando -vv o -vvv; consulta man ssh para más detalles.

Almacenar tus hosts SSH frecuentes

Los bioinformáticos tienen que conectarse constantemente por SSH a servidores, y teclear direcciones IP o largos nombres de dominio puede llegar a ser bastante tedioso. También es pesado recordar y teclear detalles adicionales como el puerto del servidor remoto o tu nombre de usuario remoto. Los desarrolladores de SSH crearon una alternativa inteligente: el archivo de configuración SSH. Los archivos de configuración SSH almacenan detalles sobre los hosts a los que te conectas con frecuencia. Este archivo es fácil de crear, y los hosts almacenados en él funcionan no sólo con ssh, sino también con dos programas que conoceremos en el Capítulo 6: scp y rsync.

Para crear un archivo, sólo tienes que crear y editar el archivo en ~/.ssh/config. Cada entrada tiene la siguiente forma:

Host bio_serv
     HostName 192.168.237.42
     User cdarwin
     Port 50453

No necesitarás especificar Port y User a menos que difieran de los valores predeterminados del host remoto. Con este archivo guardado, puedes acceder mediante SSH a 192.168.236.42 utilizando el alias ssh bio_serv en lugar de escribir ssh -p 50453 cdarwin@192.169.237.42.

Si estás trabajando con muchas conexiones de máquinas remotas en muchas pestañas de terminal, a veces es útil estar seguro de que estás trabajando en el host que crees que estás. Siempre puedes acceder al nombre de host con el comando hostname:

$ hostname
biocluster.myuniversity.edu

Del mismo modo, si mantienes varias cuentas en un servidor (por ejemplo, una cuenta de usuario para análisis y una cuenta de administración más potente para tareas de administrador del sistema), puede ser útil comprobar qué cuenta estás utilizando. El comando whoami devuelve tu nombre de usuario:

$ whoami
cdarwin

Esto es especialmente útil si de vez en cuando te conectas con una cuenta de administrador con más privilegios: los riesgos potenciales asociados a cometer un error en una cuenta con privilegios de administrador son mucho mayores, por lo que siempre debes ausentarte cuando estés en esta cuenta (y minimizar este tiempo tanto como sea posible).

Autenticación rápida con claves SSH

SSH requiere que escribas tu contraseña para la cuenta en la máquina remota. Sin embargo, introducir una contraseña cada vez que te conectas puede resultar tedioso, y no siempre seguro (por ejemplo, la entrada del teclado podría ser monitoreada). Una alternativa más segura y sencilla es utilizar una clave pública SSH. La criptografía de clave pública es una tecnología fascinante, pero los detalles quedan fuera del alcance de este libro. Para utilizar claves SSH para iniciar sesión en máquinas remotas sin contraseñas, primero tenemos que generar un par de claves pública/privada. Lo hacemos con el comando ssh-keygen. Es muy importante que tengas en cuenta la diferencia entre tus claves pública y privada: puedes distribuir tu clave pública a otros servidores, pero tu clave privada debe mantenerse a salvo y segura y nunca compartirse.

Vamos a generar un par de claves SSH utilizando ssh-keygen:

$ ssh-keygen -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/username/.ssh/id_rsa.
Your public key has been saved in /Users/username/.ssh/id_rsa.pub.
The key fingerprint is:
e1:1e:3d:01:e1:a3:ed:2b:6b:fe:c1:8e:73:7f:1f:f0
The key's randomart image is:
+--[ RSA 2048]----+
|.o... ...        |
|  .  .   o       |
| .        *      |
|  .      o +     |
| .      S .      |
|  o    . E       |
|   +    .        |
|oo+..  . .       |
|+=oo... o.       |
+-----------------+

Esto crea una clave privada en ~/.ssh/id_rsa y una clave pública en~/.ssh/id_rsa.pub. ssh-keygen te da la opción de utilizar una contraseña vacía, pero generalmente se recomienda que utilices una contraseña real. Si te lo estás preguntando, el arte aleatorio que crea ssh-keygen es una forma de validar tus claves (hay más detalles sobre esto en man ssh si tienes curiosidad).

Para utilizar la autenticación sin contraseña mediante claves SSH, primero accede mediante SSH a tu host remoto e inicia sesión con tu contraseña. Cambia de directorio a ~/.ssh, y añade el contenido de tu archivo de clave pública(id_rsa.pub, ¡no tu clave privada!) a ~/.ssh/authorized_keys (ten en cuenta que ~ puede expandirse a/home/nombre_de_usuario o /Nombre_de_usuario dependiendo del sistema operativo remoto). Puedes añadir este archivo copiando tu clave pública desde tu sistema local y pegándola en el archivo ~/.ssh/authorized_keys del sistema remoto. Algunos sistemas tienen un comando ssh-copy-id que lo hace automáticamente por ti.

De nuevo, asegúrate de que utilizas tu clave pública, y no la privada. Si alguna vez se distribuye accidentalmente tu clave privada, esto compromete la seguridad de las máquinas en las que hayas configurado la autenticación basada en claves. La clave privada~/.ssh/id_rsa sólo tiene permisos de lectura/escritura para el creador, y estos permisos restrictivos deben mantenerse así.

Cuando hayas añadido tu clave pública al host remoto, intenta iniciar sesión varias veces. Te darás cuenta de que se te sigue pidiendo la contraseña de tu clave SSH. Si te estás rascando la cabeza preguntándote cómo esto ahorra tiempo, hay un truco más que debe conocer: ssh-agent. El programa ssh-agent se ejecuta en segundo plano en tu máquina local, y gestiona tu(s) clave(s) SSH. ssh-agent Te permite utilizar tus claves sin introducir sus contraseñas cada vez, exactamente lo que queremos cuando nos conectamos frecuentemente a servidores. El agente SSH suele estar ya en ejecución en los sistemas basados en Unix, pero si no es así, puedes utilizar eval ssh-agent para iniciarlo. A continuación, para informar a ssh-agent sobre nuestra clave, utilizamosssh-add:

$ ssh-add
Enter passphrase for /Users/username/.ssh/id_rsa:
Identity added: /Users/username/.ssh/id_rsa

Ahora, el proceso en segundo plano ssh-agent gestiona nuestra clave por nosotros, y no tendremos que introducir nuestra contraseña cada vez que nos conectemos a una máquina remota. Una vez calculé que me conecto a distintas máquinas unas 16 veces al día, y tardo unos dos segundos de media en introducir mi contraseña (teniendo en cuenta los errores de escritura). Si suponemos que no trabajo los fines de semana, esto equivale a unos 8.320 segundos, o 2,3 horas al año sólo de conexiones SSH. Después de 10 años, esto se traduce en casi un día entero malgastado sólo en conectarme a máquinas. Aprender estos trucos puede llevar una hora más o menos, pero a lo largo de una carrera, esto realmente ahorra tiempo.

Mantener trabajos de larga duración con nohup y tmux

En el Capítulo 3, comentamos brevemente cómo los procesos (tanto si se ejecutan en primer plano como en segundo plano) se terminan cuando cerramos la ventana de nuestro terminal. Los procesos también se terminan si nos desconectamos de nuestros servidores o si nuestra conexión de red se cae temporalmente. Este comportamiento es intencionado: tu programa recibirá la señal de colgado (denominada más técnicamenteSIGHUP), que en casi todos los casos hará que tu aplicación salga inmediatamente. Dado que en nuestro trabajo diario en bioinformática trabajamos continuamente con máquinas remotas, necesitamos una forma de evitar que los cuelgues detengan las aplicaciones de larga ejecución. Dejar abierta la conexión de tu terminal local a una máquina remota mientras se ejecuta un programa es una solución frágil: incluso las redes más fiables pueden sufrir breves cortes. Veremos dos soluciones preferibles: nohup y Tmux. Si utilizas un clúster, hay formas mejores de solucionar los cuelgues (por ejemplo, enviar trabajos por lotes al software de tu clúster), pero dependen de la configuración específica de tu clúster. En este caso, consulta a tu administrador del sistema.

nohup

nohup es un comando sencillo que ejecuta un comando y capta las señales de cuelgue enviadas desde el terminal. Como el comando nohup captura e ignora estas señales de cuelgue, el programa que estés ejecutando no se interrumpirá. Ejecutar un comando con nohup es tan fácil como añadir nohup antes de tu comando:

$ nohup program1 > output.txt & 
[1] 10900 

Ejecutamos el comando con todas las opciones y argumentos como haríamos normalmente, pero añadiendo nohup este programa no se interrumpirá si se cerrara tu terminal o se cayera la conexión remota. Además, es una buena idea redirigir la salida estándar y el error estándar tal y como hicimos en el Capítulo 3 para que puedas comprobar la salida más adelante.

nohup devuelve el número de identificación del proceso (o PID), que es como puedes monitorizar o terminar este proceso si lo necesitas (tratado en "Matar procesos"). Como perdemos el acceso a este proceso cuando lo ejecutamos a través de nohup, nuestra única forma de terminarlo es refiriéndonos a él por su ID de proceso.

Trabajar con máquinas remotas a través de Tmux

Una alternativa a nohup es utilizar un multiplexor de terminal. Además de resolver el problema del cuelgue, utilizar un multiplexor de terminal aumentará enormemente tu productividad cuando trabajes a través de una conexión remota. Nosotros utilizaremos un multiplexor de terminal llamado Tmux, pero una alternativa popular es GNU Screen. Tmux y Screen tienen una funcionalidad similar, pero Tmux se desarrolla más activamente y tiene algunas características adicionales interesantes.

Tmux (y los multiplexores de terminal en general) te permiten crear una sesión que contenga varias ventanas, cada una capaz de ejecutar sus propios procesos. Las sesiones de Tmux son persistentes, lo que significa que todas las ventanas y sus procesos pueden restaurarse fácilmente volviendo a conectar la sesión.

Cuando se ejecuta en una máquina remota, Tmux te permite mantener una sesión persistente que no se perderá si se cae la conexión o si cierras la ventana del terminal para irte a casa (o incluso si sales del programa de terminal). Por el contrario, todas las sesiones de Tmux pueden volver a conectarse al terminal en el que te encuentres: sólo tienes que volver a conectarte mediante SSH al host remoto y volver a conectar la sesión de Tmux. Todas las ventanas permanecerán intactas y todos los procesos seguirán ejecutándose.

Instalación y configuración de Tmux

Tmux está disponible a través de la mayoría de gestores de paquetes/puertos. En OS X, Tmux puede instalarse a través de Homebrew y en Ubuntu está disponible a través de apt-get. Después de instalar Tmux, te recomiendo encarecidamente que vayas al directorio de este capítulo en GitHub y descargues el archivo .tmux.conf en tu directorio personal. Al igual que tu shell carga las configuraciones desde ~/.profile o ~/.bashrc, Tmux cargará sus configuraciones desde ~/.tmux.conf. Las configuraciones mínimas de.tmux. conf facilitan el aprendizaje de Tmux proporcionándote una útil barra de visualización en la parte inferior y cambiando algunas de las combinaciones de teclas de Tmux por las que son más comunes entre los usuarios de Tmux.

Crear, separar y adjuntar sesiones Tmux

Tmux te permite tener varias sesiones, y dentro de cada sesión tiene varias ventanas. Cada sesión Tmux es un entorno independiente. Normalmente, utilizo una sesión para cada proyecto diferente en el que estoy trabajando; por ejemplo, podría tener una sesión para la llamada de SNP del maíz, otra para desarrollar una nueva herramienta y otra para escribir código R para analizar algunos datos de expresión génica de Drosophila. Dentro de cada una de estas sesiones, tendría varias ventanas. Por ejemplo, en mi proyecto de llamada de SNP de maíz, podría tener tres ventanas abiertas: una para interactuar con el intérprete de comandos, otra con un cuaderno de proyecto abierto en mi editor de texto, y otra con una página de manual de Unix abierta. Ten en cuenta que todas estas ventanas están dentro de Tmux; el concepto de pestañas y ventanas de tu programa terminal es totalmente distinto al de Tmux. A diferencia de Tmux, tu terminal no puede mantener sesiones persistentes.

Vamos a crear una nueva sesión Tmux. Para que nuestros ejemplos sean un poco más sencillos, vamos a hacerlo en nuestra máquina local. Sin embargo, para gestionar sesiones en un host remoto, necesitaríamos iniciar Tmux en ese host remoto (esto suele ser confuso para los principiantes). Ejecutar Tmux en un servidor remoto no es diferente; sólo tenemos que acceder mediante SSH a nuestro servidor e iniciar Tmux allí. Supongamos que queremos crear una sesión Tmux correspondiente a nuestro ejemplo anterior de llamada a SNP de Maize:

$ tmux new-session -s maize-snps

Tmux utiliza subcomandos; el subcomando new-session que acabamos de mostrar crea nuevas sesiones. La opción-s simplemente da un nombre a esta sesión para que sea más fácil identificarla después. Si estás siguiendo el proceso y has colocado correctamente el archivo .tmux.confen tu directorio personal, tu sesión Tmux debería parecerse ala Figura 4-1.

Figura 4-1. Tmux utilizando el archivo .tmux.conf proporcionado

Tmux tiene el mismo aspecto que un intérprete de comandos normal, excepto por la barra de estado que ha añadido en la parte inferior de la pantalla (hablaremos más de esto dentro de un rato). Cuando Tmux está abierto, interactuamos con Tmux mediante atajos de teclado. Todos estos atajos se basan en pulsar primero Control y a, y añadir después una tecla específica (soltando primero Control-a ). Por defecto, Tmux utiliza Control-b en lugar de Control-a, pero éste es un cambio que hemos hecho en nuestro .tmux.conf para seguir la configuración preferida por la mayoría de los usuarios de Tmux.

La característica más útil de Tmux (y de los multiplexores de terminal en general) es la posibilidad de separar y volver a unir sesiones sin perder nuestro trabajo. Veamos cómo funciona esto en Tmux. Primero introduzcamos algo en nuestro intérprete de comandos en blanco para que podamos reconocer esta sesión más tarde: echo "hello, tmux". Para desvincular una sesión, utilizamos Control-a, seguido de d (para desvincular). Después de introducir esto, deberías ver que Tmux se cierra y te devuelve a tu intérprete de comandos normal.

Después de separarnos, podemos ver que Tmux ha mantenido viva nuestra sesión llamando atmux con el subcomando list-sessions:

$ tmux list-sessions
maize-snps: 1 windows (created Mon Feb 10 00:06:00 2014) [180x41]

Ahora, volvamos a unir nuestra sesión. Reincorporamos sesiones con el subcomandoattach-session, pero también funciona el más corto attach:

$ tmux attach

Observa que, como sólo tenemos una sesión en ejecución (nuestra sesión maize-snps ), no tenemos que especificar qué sesión adjuntar. Si hubiera más de una sesión en ejecución, todos los nombres de sesión habrían aparecido en la lista cuando ejecutamoslist-sessions y podríamos volver a adjuntar una sesión concreta utilizando -t <session-name>. Con una sola sesión Tmux en ejecución, tmux attach equivale a tmux attach-session -t maize-snps.

Gestionar sesiones remotas con Tmux no es diferente de gestionar sesiones localmente como hicimos antes. La única diferencia es que creamos nuestras sesiones en el host remoto después de conectarnos con SSH. Cerrar nuestra conexión SSH (intencionadamente o no debido a una caída de la red) hará que Tmux desconecte cualquier sesión activa.

Trabajar con Tmux Windows

Cada sesión Tmux también puede contener varias ventanas. Esto es especialmente útil cuando se trabaja en máquinas remotas. Con las ventanas de Tmux, una única conexión SSH a un host remoto puede soportar múltiples actividades en diferentes ventanas. Tmux también te permite crear múltiples paneles dentro de una ventana que te permiten dividir tus ventanas en partes, pero para ahorrar espacio dejaré que el lector aprenda esta funcionalidad por su cuenta. Consulta la página del manual de Tmux (por ejemplo, con man tmux) o lee uno de los muchos y excelentes tutoriales de Tmux que hay en la Web.

Al igual que otras secuencias de teclas Tmux, creamos y cambiamos de ventana utilizando Control-ay luego otra tecla. Para crear una ventana, usamos Control-a c, y usamos Control-a n y Control-a p para ir a la ventana siguiente y anterior, respectivamente. Enla Tabla 4-1 se enumeran las secuencias de teclas Tmux más utilizadas. Consulta man tmuxpara obtener una lista completa, o pulsa Control-a ? desde dentro de una sesión Tmux.

Tabla 4-1. Secuencias de teclas comunes de Tmux

Secuencia de teclas	Acción
Control-ad	Separar
Control-ac	Crear nueva ventana
Control-an	Ir a la siguiente ventana
Control-ap	Ir a la ventana anterior
Control-a&	Matar la ventana actual (exit en shell también funciona)
Control-a,	Cambiar el nombre de la ventana actual
Control-a?	Lista todas las secuencias de teclas

Enla Tabla 4-2 se enumeran los subcomandos Tmux más utilizados.

Tabla 4-2. Subcomandos comunes de Tmux

Subcomando	Acción
tmux list-sessions	Enumera todas las sesiones.
tmux new-session -s session-name	Crea una nueva sesión llamada "nombre-sesión".
tmux attach-session -t session-name	Adjunta una sesión llamada "nombre-sesión".
tmux attach-session -d -t session-name	Adjunta una sesión llamada "nombre-sesión", separándola primero.

Si utilizas Emacs como editor de texto, te darás cuenta rápidamente de que la unión de teclas Control-a puede estorbar. Para introducir una Control-a literal (como la que se utiliza para ir al principio de la línea en Emacs o en el intérprete de comandos Bash), utiliza Control-aa.