Tmux en la práctica: sesiones tmux locales y remotas anidadas

Discutimos las características de tmux, su relevancia para escenarios locales y remotos, y cómo instalar y configurar tmux para soportar sesiones anidadas

Esta es la primera parte de mi serie de artículos sobre tmux en la práctica. Se trata de usar y configurar tmux v2, el uso de sesiones tmux locales y remotas, y cómo admitir un escenario en el que una sesión tmux remota se anidará dentro de una sesión tmux local.

Antes de comenzar a leer, aquí hay un ejemplo de trabajo de mi máquina. Tenemos una sesión tmux local en OSX dentro de iTerm2 (se ejecuta en modo de pantalla completa). La sesión local tiene 2 ventanas: "zsh" y "nodo".

La ventana "zsh" está dividida en 2 paneles: en ambos paneles conectamos SSH a los hosts remotos (CentOS7 y Ubuntu14) y saltamos a las sesiones remotas de tmux allí.

El panel inferior con la sesión remota de Ubuntu14 se divide en 2 paneles y tenemos 3 ventanas: shell, mon y logs.

Si tiene curiosidad por saber cómo funciona todo junto, continúe leyendo.

Caracteristicas

Primero, repasemos rápidamente las características y ventajas de tmux, para comprender su relevancia en escenarios locales o remotos. Deberíamos aclararnos a nosotros mismos por qué necesitamos este "tmux anidado en tmux", porque a primera vista parece bastante loco.

  1. Multiplexación de terminales, ventanas con nombre, ventana dividida en varios paneles. Esto tiene más sentido para el entorno local, cuando decide sobrecargar su emulador de terminal, que de otra manera no es compatible con las funciones antes mencionadas. Por ejemplo, iTerm o Terminator ya son capaces de multiplexar un terminal.
  2. Configure e inicie la sesión tmux con un conjunto preconfigurado de ventanas y paneles, su disposición y comandos se ejecutan en el interior para evitar la molestia de configurarlos repetidamente una y otra vez desde cero. Por ejemplo:

    - Sesión "dev", que incluye la ventana "# 1: shell" con 2 paneles para uso ad-hoc

    - Ventana "# 2: supervisión" con paneles htopysysdig

    - Ventana "# 3: registro" con paneles journalctlytail -f app.log

    - nodeServidor en ejecución de la ventana "# 4: nodo"

    tmux le permite escribir un script para lograr esto, y si prefiere el enfoque similar a la configuración, eche un vistazo a tmuxinator. Esto es relevante tanto para escenarios locales como remotos.

  3. Mantenga su estado de trabajo, para que pueda desconectarse y reanudar más tarde con el mismo estado en el que lo dejó. Al trabajar localmente con varios proyectos, puede configurar varias sesiones tmux por proyecto y cambiar de contexto fácilmente

    En la máquina remota, puede desconectarse de la sesión al final de la jornada laboral y volver a la misma sesión desde su casa por la noche.

  4. Sobrevive a caídas de conexión abruptas. Esta es una de las características más importantes. Supongamos que utiliza SSH en un host remoto y tiene un proceso de larga duración allí. Si se pierde la conexión SSH o se produce una caída de la red física, la señal SIGHUP se enviaría al shell remoto, y este y todos sus procesos secundarios terminarían. Tmux hace que sus procesos remotos sean resistentes a tales riesgos.

Las características menos importantes, pero dignas de mención, son las siguientes:

  1. Una vez que configure el entorno tmux, dependerá menos del emulador de terminal principal y su conjunto único de características , y puede cambiar a otro emulador de terminal con menos complicaciones. Dado que soy un usuario de iTerm2 en OSX, puedo migrar a Terminator o konsole en Linux instalando mi configuración tmux allí y obtener el mismo entorno conocido al que ya estoy acostumbrado.
  2. Comparta su sesión remota con su colega, para que pueda colaborar en tiempo real. Creo que es de uso poco común en el mundo real, pero suena genial. Sí, programación en pareja y otras palabras de moda interesantes. ?

Entonces, para concluir, tmux es responsable de dos cosas principales :

  1. Multiplexación de terminales, gestión de sesiones / ventanas / paneles
  2. Conservar el estado de la sesión y sobrevivir a las desconexiones para escenarios remotos

Donde tmux realmente brilla es (2). Con respecto a (1), algunas personas argumentan que tmux rompe la filosofía de Unix, porque está tratando de hacer 2 cosas, en lugar de hacer una y hacerlo bien, y que (1) no debería ser una responsabilidad de tmux.

Sesiones locales y remotas anidadas

Entonces, dado todo eso, algunas personas prefieren usar tmux en la máquina local solo en la parte superior de su emulador de terminal, supercargándolo con multiplexación y administración de ventanas en primer lugar. Las personas que pasan la mayor parte de su tiempo SSH en hosts remotos, hacen uso de la naturaleza de sesión persistente y la resistencia a las desconexiones de la red.

Pero, ¿los casos locales y remotos tienen que ser mutuamente excluyentes? ¿Puedo combinarlos? Sí, es legal usar SSH en un host remoto e iniciar la sesión tmux allí, mientras ya se encuentra en un entorno tmux localmente.

Esto se denomina sesiones anidadas, pero tiene algunos obstáculos:

En primer lugar, se enfrenta a la pregunta: ¿cómo puede controlar las sesiones internas, ya que todas las combinaciones de teclas son capturadas y manejadas por sesiones externas?

La solución más común es presionar prefixdos veces (el prefijo es una combinación de teclas que pone tmux en un modo de comando, por lo general lo es C-b, pero algunas personas prefieren reasignarlo a una pantalla C-a). La primera pulsación de tecla de prefijo es capturada por la sesión externa, mientras que la segunda se pasa a la sesión interna. No es necesario realizar pasos adicionales, y esto funciona de inmediato.

Sin embargo, las combinaciones de teclas de root, aquellas que se escuchan globalmente, no en el modo de comando, siguen siendo capturadas solo por la sesión externa. Y encontré que es realmente molesto presionar dos veces prefix. Para mí es incluso molesto presionarlo una vez, en iTerm2 no existe el modo de comando, y simplemente presiono “ ⌘⌥→” para seleccionar el panel de la derecha, en lugar de enviar dos pulsaciones de teclas separadas C-a RightArrow.

Otra solución es configurar 2 prefijos individuales, por ejemplo, C-bpara una sesión local, mientras que C-apara una remota. Con la siguiente configuración, significa que presionar C-alocalmente enviaría el prefijo predeterminado C-ba la sesión remota. Encontré esta solución aquí.

set -g prefix C-bbind-key -n C-a send-prefix

Pero realmente se siente como:

La mejor solución sería usar la misma tabla de teclas tanto en sesiones locales como remotas, sin prefijos separados ni presionar dos veces el prefijo, y desactivar todas las combinaciones de teclas y el manejo de prefijos en la sesión externa, cuando se trabaja con la interna. Créditos y este problema de Github.

Entonces, cuando voy a trabajar en la sesión interna, simplemente presiono F12y cambio de OFFmodo en la sesión externa. Cuando eso sucede, la sesión externa muestra el OFFindicador visual en la línea de estado y cambia el estilo visual de la línea de estado para enfatizar aún más que la sesión está en modo APAGADO.

Aquí hay una esencia de mi configuración tmux de trabajo, que elaboré recientemente (solo se incluyen las piezas relevantes):

Básicamente, configuramos la F12combinación de teclas para la tabla de claves raíz. Cuando se presiona, establecemos el prefijo en None, offcambiamos la tabla de teclas actual a , luego cambiamos los estilos de la línea de estado y forzamos a tmux a actualizar la línea de estado. Se toma un paso adicional para cancelar el modo de copia del panel actual, si está presente. Tan pronto como cambiamos a offpara la tabla de teclas y desactivamos el manejo de prefijos, la sesión externa no escucha ninguna pulsación de tecla. Todas las pulsaciones de teclas se pasan a la sesión interna sin ser interceptadas por la externa.

Todo eso es genial, pero de alguna manera necesitamos volver y convertir la sesión externa en modo de trabajo normal. Es por eso que configuramos una combinación F12de teclas única en la tabla de teclas off, que revierte el efecto de la F12pulsación inicial de la tecla.

Además, configuramos un indicador visual para la línea de estado, que muestra cuándo está la tabla de claves actual offy se oculta de lo contrario.

Para concluir, dada esta configuración, puede configurar una sola sesión local con 1 ventana con 2 paneles que contiene sesiones remotas anidadas para diferentes hosts (vea la imagen al comienzo de la publicación).

Configuración de sesión específica remota

En el ejemplo anterior, puede notar que la línea de estado de la sesión externa se coloca en la parte superior, donde la sesión interna tiene su línea de estado en la parte inferior. Eso proporciona una distinción visual agradable y no hace que las líneas de estado se apilen unas sobre otras.

Pero, ¿cómo es posible aplicar diferentes configuraciones basadas en condiciones?

Bueno, eso es bastante fácil. Podemos detectar si la sesión es remota o local por la existencia de la SSH_CLIENTvariable de entorno.

if-shell 'test -n "$SSH_CLIENT"' \ 'source-file ~/.tmux/tmux.remote.conf'

Y el ~/.tmux/tmux.remote.confarchivo contiene la configuración que se aplicará solo a la sesión remota. Allí cambiamos la posición de la línea de estado y eliminamos algunos widgets (como el reloj y la batería) porque simplemente replican los mismos widgets de la sesión local.

Eso es todo. Si desea ver todo esto en acción, consulte mi repositorio tmux-config.

Recursos y enlaces

tmux / tmux: código fuente de tmux - //github.com/tmux/tmux

Uso de Tmux de forma remota dentro de una sesión local de Tmux | Simplemente Ian - //simplyian.com/2014/03/29/using-tmux-remotely-within-a-local-tmux-session/

Tmux anidado - //stahlke.org/dan/tmux-nested/

activar / desactivar todas las combinaciones de teclas · Edición n. ° 237 · tmux / tmux - //github.com/tmux/tmux/issues/237

samoshkin / tmux-config: configuración de Tmux, que sobrealimenta su tmux para construir un entorno de terminal agradable y fresco - //github.com/samoshkin/tmux-config