Journal Utiliser tmux aussi bien en local qu'en distant

Posté par  . Licence CC By‑SA.
Étiquettes :
19
6
juil.
2012

Salutations journal,

J'ai hésité à mettre ce journal en astuce, mais je n'aime pas trop les entrées du forum, alors je post ici. En plus, le titre n'est sûrement pas très clair, alors je vais expliciter.

J'utilise tmux depuis quelques temps, et je le conseille vraiment à tout le monde : autant je n'ai jamais supporté screen plus de 2 minutes, autant là c'est devenu mon shell par défaut. Il a remplacer les tabs de gnome-terminal, maintenant j'ai juste un terminal simple et tmux dedans.

J'avais un problème cependant, c'est quand je suis connecté en ssh à des machines distantes : soit elles n'ont pas tmux, et donc je dois lancer plusieurs ssh, soit elles ont tmux, mais alors ça ne s'imbrique pas très bien (il faut jouer du send-prefix, ça n'est pas pratique). Tout ça en faisant gaffe que mes sessions restent up !

Bref, j'ai cherché une solution à ça, et j'ai découvert quelques options bien sympas de ssh, comme le partage de connexion ssh pour différentes sessions. Cette option (voir ControlMaster et ControlPath, cf man ssh_config(5)) permet de lancer plusieurs shells parallèles sans avoir à se relogger. Cool ! Il me « suffit » donc de brancher ça à tmux pour que ça soit pratique. J'ai donc écrit le script suivant, qui permet de chopper la commande ssh actuellement utilisée, et d'ouvrir un nouveau pane/une nouvelle fenêtre avec :

#!/bin/sh

# From tmux, split the current pane and start a second ssh session if a
# first was running.
# To avoid having to login again, use the ControlMaster and ControlPath
# options of ssh_config(5).

# get the tty of the active pane
CTTY=`tmux list-panes -F '#{pane_active} #{pane_tty}' \
        | awk '/^1/ { print $2 }'`

# look for processes attached to this tty, checking for the controlling
# one, if it's named "ssh"; print the command as it was launched (same
# arguments)
COMMAND=`ps --no-headers -o pid,tpgid,args -t $CTTY \
                | awk '$1 == $2 && $3 ~ /^ssh\>/ { $1=$2="" ; print }'`

# no matching process was found
if [ -z "$COMMAND" ]; then
        exit 1
fi

case $1 in
        h) tmux split-window -h "exec $COMMAND"
                ;;
        v) tmux split-window -v "exec $COMMAND"
                ;;
        *) tmux new-window "exec $COMMAND"
                ;;
esac

(je le mets sous GPLv3)(oui, j'aime bien awk, ça me vient d'OpenWrt, qui est une référence à ce niveau pour moi)
Passez-lui l'argument que vous voulez pour ouvrir au choix un pane ou une fenêtre, et bindez ça sur une touche ; perso, j'utilise C-s pour splitter normalement, et C-q pour splitter une session ssh (je splitte majoritairement verticalement). Comme ça en plus ça m'empêche de faire le vrai ^s ou ^q par inadvertance, qui sont le contrôle de flux du terminal, chose que je n'utilise jamais et qui est plus chiante qu'autre chose. J'ai aussi C-t pour une nouvelle fenêtre : sur un bépo, les trois sont sous la main droite les uns à côté des autres. Dans le fichier de conf .tmux.conf, ça donne :

bind-key -n C-q run-shell "~/bin/split-ssh.sh v"

Et pour le ssh_config :

Host *
ControlMaster auto
ControlPath /home/mon_login/.ssh/%r@%h:%p

Comme ça maintenant, je peux splitter facilement soit en local, soit en distant. Génial.

En bonus, une autre fonctionnalité sympa de ssh, c'est le forwarding des autorisations : comme ça, on n'a pas besoin de mettre sa clé partout. Attention, comme indiqué dans le man, c'est à faire avec discernement, car ça peut être utilisé par l'admin de la machine sur laquelle on est connecté pour usurper votre identité. Donc à ne faire que sur des machines de confiance :

Host machine-de-confiance
ForwardAgent yes

Je l'utilise pour un truc très pratique : faire des montages sshfs en « retour » sur ma machine, afin de partager des fichiers avec cette machine distante (quand des allers-retours à coup de scp sont trop chiants). Il faut ajouter sa clé (publique) dans le authorized_keys de sa propre machine, et comme ça, quand on se logge en ssh sur la machine-de-confiance, on peut faire un :

sshfs ma-machine:quelque-part ici

Tout ça sans avoir à générer de clés sur la machine distante, clés qui seront oubliées quelques part, ou perdues, en bordel ; bref, ça simplifie la gestion de clé.

Voilà, j'espère que ces astuces vous seront utiles. Et n'oubliez pas, il n'est jamais trop tard pour se mettre à connaître et/ou utiliser certains outils qu'on utilise depuis des lustres, ou dont on entend parler depuis un bout de temps : pour moi, un peux plus de 10 ans pour un multiplexeur de terminal, et pareil pour le ssh_config…

  • # Le seul souci avec ControlMaster

    Posté par  (site web personnel) . Évalué à 4.

    C'est que la connexion maître ne peut pas être fermée tant que toutes les connexions qui l'utilisent ne sont pas closes. Parfois un peu embêtant quand on a une myriade de shells et qu'on ne sait pas lequel est la connexion maître… Personnellement, ca m'a fait renoncer à cette option qui a quand même l'avantage de réduire considérablement le temps d'attente lors d'une nouvelle connexion…

    YMMV.

  • # serie

    Posté par  (site web personnel) . Évalué à 5. 

    screen /dev/ttyUSB0

    Impossible à faire avec tmux… Dommage, c'est mon utilisation la plus courante presque.

    • [^] # Re: serie

      Posté par  . Évalué à 1.

      Comprendre : screen est aussi une cafetière !

    • [^] # Re: serie

      Posté par  . Évalué à 2.

      Bah justement, c'est ma deuxième ou troisième utilisation la plus courante, et je comptais aller faire un patch un jour. J'ai déjà regardé le code, ça me semble faisable pas trop difficilement. Si quelqu'un d'autre en a besoin, ça me motive d'autant plus.

      • [^] # Re: serie

        Posté par  . Évalué à 1.

        J'utilisais screen il y a longtemps, j'ai migré sur tmux, mais je suis "obligé" de garder screen justement pour cette utilisation. Minicom est vraiment trop casse pied dans notre contexte. Donc oui, si il y a un patch tmux pour ça, je serais content :p Je peux même sponsoriser en liquide (avec mousse ou glaçon suivant les goûts)…

        • [^] # Re: serie

          Posté par  . Évalué à 2.

          Bon alors en fait, je me suis penché un peu plus sur un autre utilitaire dont j'entends parler depuis quelques temps : socat [http://www.dest-unreach.org/socat/]. Parce que j'ai lu qu'il résolvait beaucoup de choses. Et bien il peut nous aider ici ! On peut lui demander de connecter l'entrée et la sortie standard sur un tty quelconque, comme ça on est indépendant de si c'est dans un screen/tmux/terminal directement. C'est extrait du man en plus, mais j'ai enlevé la conversion CR/NL :

           socat -,raw,echo=0,escape=0x0f /dev/ttyUSB0,raw,echo=0

          Comme ça, on a ^O (c'est le escape=0x0f) pour terminer socat, et il passera les autres séquences comme il faut. Allez voir la section sur les options termios dans le man pour voir tout ce qu'il est possible de configurer, comme la vitesse du port série, etc.

    • [^] # Re: serie

      Posté par  (site web personnel) . Évalué à 2.

      screen /dev/ttyUSB0

      Bonjour,

      qu'est ce que c'est sensé faire?

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: serie

        Posté par  (site web personnel) . Évalué à 4.

        Cela permet d'aller voir une console série. Cela évite minicom bien trop complexe à mon gout…

        Une console série ? Tous les commutateurs administrable en ont une, ainsi que les baies SAN… Bref, c'est très pratique pour piloter des engins.

        Ici, j'ai mis ttyUSB0 pour une console série (RS232) sur un adaptateur USB. Mais la console la plus classique sur un PC est ttyS0 (les nouveaux PC n'en ont pas toujours).

        • [^] # Re: serie

          Posté par  (site web personnel) . Évalué à 2.

          Cela permet d'aller voir une console série. Cela évite minicom bien trop complexe à mon gout…

          Et par rapport à des clients dédiés comme cu ou tip ? C'est intéressant ?

          • [^] # Re: serie

            Posté par  (site web personnel) . Évalué à 2.

            Oui car screen, c'est simple ;-) Il fait tout seul les réglages et via une petite option, il capture tout dans un fichier de log que tu envoi au support de ta baie / commutateur…

            J'ai pas essayer cu ou tip non plus…

            • [^] # Re: serie

              Posté par  (site web personnel) . Évalué à 2.

              Voila ce que j'ai trouvé sur ma debian pour cu

              Description-fr: Appeler un autre système
La commande cu est utilisée pour appeler un autre système et se comporte
comme un terminal de numérotation. Elle peut également assurer un
transfert de fichiers simple, sans vérification d'erreur.
.
cu fait partie du code source de UUCP, mais a été empaqueté séparément car
il peut être utile même si vous n'utilisez pas uucp.

              On peux dire qu'après cela, je n'en sais pas plus ;-)

              Qu'en a tip, rien trouvé dessus… Bref, si tu as des exemples, pourquoi pas. J'ai quand même des doutes vis à vis de la simplicité de screen tout d'un coup.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.