Optimiser son client ssh

le 25 août 2015, par Jean-Philippe Caruana

Dans mon travail quotidien, je me connecte très souvent à une multitude de serveurs, que ce soit pour aller sur le serveur de logs, pour faire une mise en production ou faire de la maintenance système. Je me connecte également très souvent (sans le savoir) aux serveurs de github à chacune de mes actions git pull et git push.

Il se trouve que ssh est un outil très complet, très configurable si on prend le temps de bien lire la documentation. J'ai ainsi découvert comment accélérer considérablement ma connexion à tous ces serveurs, passant d'un délai moyen compris entre 2 et 3 secondes à une connexion quasi instantannée (de mon point de vue humain).

Toutes les modification dont on va parler seront locales à un utilisateur, en éditant le fichier ~/.ssh/config.

Completion des noms de serveurs

Tout d'abord, il est possible d'avoir la completion des noms de serveurs depuis la ligne de commande. Ainsi, on peut taper ssh user@mons <TAB> et le shell nous remplit pour nous le reste (ssh user@monseveur.com). Par défaut, dans les distributions dérivées de debian, cette option est désactivée

~/.ssh/config :

HashKnownHosts no

Je vous recommande de supprimer votre fichier ~/.ssh/known_hosts après cela.

Accélérer la vitesse de connexion

Ensuite, pour accélérer la vitesse de connexion, il est très utile de désactiver le protocole kerberos lorsque vous tentez de vous connecter à vos serveurs.

~/.ssh/config :

GSSAPIAuthentication no
GSSAPIKeyExchange no
GSSAPIRenewalForcesRekey no

Rien qu'avec cela, vous devriez obtenir des vitesses de connexion beaucoup plus rapides (c'est ici que vous gagnez vos 2/3 secondes)

Compression des données

Pour un petit surcoût en CPU (côté client et côté serveur mais négligeable), vous pouvez également activer la compression des données pour toutes vos communications entre vous et votre serveur. J'ai choisi pour ma part de mettre le curseur au maximum en configurant un niveau de compression à 9.

~/.ssh/config :

Compression yes
CompressionLevel 9

Garder les connexions ouvertes

Enfin, il est possible de garder ses connexions ouvertes pendant un certain temps. Ssh peut ainsi garder des sockets ouvertes pendant la durée désirée. En outre, si vous établissez plusieurs connexions avec un même serveur, votre client ssh va réutiliser la socket existante et faire du multiplexage : autant dire que vos connexions seront instantannées. Ici, un paramétrage pour garder les connexions ouvertes pendant 1/2h :

~/.ssh/config :

ControlMaster auto
ControlPath ~/.ssh/%r@%h:%p
ControlPersist 30m

Vous pouvez lister le contenu de votre répertoire ~/.ssh dans lequel vous verrez des sockets dont le nom sera de la forme utilisateur@serveur:port.

Attention cependant si vous êtes sur un réseau wifi et que vous perdez votre connexion, ssh tentera d'utiliser la socket et vous ne pourrez pas vous connecter. Dans ce cas, vous pouvez diminuer cette durée ou demander à ssh de fermer cette connexion :

ssh -O close user@monseveur.com

Dire à ansible d'utiliser ce paramétrage

Ansible utilise déjà par défaut cette option ControlMaster mais paramétrée différement (lieu et durée de stockage des sockets). Si vous voulez réutiliser les mêmes sockets et pour une même durée en travaillant avec ansible, il faut le lui dire !

Ainsi, mon fichier ~/.ansible.cfg ressemble à ceci :

[ssh_connexion]
ssh_args = -o ControlMaster=auto -o ControlPersist=30m
control_path=~/.ssh/%%r@%%h:%%p

Et vous, quelles sont vos options pour votre client ssh qui améliorent votre vie ?


  • Mon fichier ~/.ssh/config complet :
# allow server name completion
HashKnownHosts no

# faster connexion
GSSAPIAuthentication no
GSSAPIKeyExchange no
GSSAPIRenewalForcesRekey no

# compress data to the max
Compression yes
CompressionLevel 9

# keep connexions open
ControlMaster auto
ControlPath ~/.ssh/%r@%h:%p
ControlPersist 30m

Retour sur l'Agile Conférence 2015

le 8 juillet 2015, par Bruno Thomas

La semaine dernière, nous avons retrouvé les oies et les canards du chalet de la porte jaune pour la 10e édition de la conférence agile (anciennement XP Days), pour une thématique "par delà l'agilité". Retour sur ce que nous avons retenu de l'ère post-agile, avec notre filtre forcément subjectif.

Le bagot du jour de l'an ou l'assert laxe

le 8 janvier 2015, par Bruno Thomas

Le 2 janvier est propice à la chasse au bagot : il est fréquent de rentrer encore un peu barbouillé des fêtes de fin d'années et d'être accueilli par une intégration continue rouge. Tests qui ne fonctionnent qu'en année bissextile, année codée en dur, numéro de mois qui va de 0 à 11, toutes les raisons sont bonnes.

Astuce - laisser nginx répondre robots.txt

le 7 janvier 2015, par Jean-Philippe Caruana

Sur le service sur lequel je travaille, j'ai observé de nombreuses erreurs 500 suite à des tentatives du Google Bot de trouver le fichier /robots.txt. Voici par exemple une log d'erreur de nginx :

Git - le message systématique qui agace

le 19 décembre 2014, par Jean-Philippe Caruana

A chaque git fetch ou git pull --rebase ou encore git merge branche, j'avais un message agaçant, même quand il n'y avait rien à faire (branche à jour). Par exemple :

Migrer un blog de Wordpress vers Jekyll

le 11 décembre 2014, par Jean-Philippe Caruana

Suite à la migration de notre blog vers un jekyll hébergé chez github, je vous propose quelques explications sur le sujet. Dans cet article, nous verrons :

Barre Verte a migré

le 5 décembre 2014, par Jean-Philippe Caruana

Nous venons de terminer la migration de Barre Verte : auparavant, nous nous hébergions nous-mêmes sous Wordpress chez Gandi, désormais, nous utilisons Jekyll hébergé (gratuitement) par Github.

MongoDb le cluster qui bagote

le 11 octobre 2014, par Philippe Blayo

Mug MongoDB Un soir, un développeur lâche en partant : « MongoDb c’est de la merde. Leur réplication ça marche pas. Je parie qu’on a aussi le bug en prod. Pour un peu j’en jetterais ma tasse mongo par la fenêtre. »

Les héros du bagot

le 19 juin 2014, par Bruno Thomas

hudson_trends

Cela fait 6 ans que nous faisons des tests fonctionnels (ou d'acceptance). Tests FitNesse, GreenPepper, Concordion avec ou sans IHM (Selenium par ex). Une chose reste constante, c'est la difficulté de stabiliser ces tests. Les approches sur le sujet dans les conférences sont variées, mais l'énergie mise dans la maintenance de ces tests semble toujours importante.

Le défi est double : avoir des tests qui s'exécutent rapidement, et dont la stabilité permet de détecter de manière certaine les régressions fonctionnelles. Ce que nous constatons sur les 4 projets qui ont mis en oeuvre des tests d'acceptance, c'est que le non-déterminisme de la plupart des tests provoque des bagotements (flaky tests). Tant et si bien que nous avons donné un nom à ces défauts de déterminisme : les bagots. Le soucis avec ces bagots, c'est qu'ils empêchent de décider si un test est rouge pour une bonne raison (une régression), ou pour une mauvaise raison (typiquement une mauvaise séquence d'accès concurrents du test).

Ces tests sont "probabilistes" : lorsque l'ordonnanceur partage équitablement le temps entre les différentes unités de calculs (process, threads), le test est vert. Avec une machine lente ces tests sont plus fréquemment rouges. Une sélection inattendue de ses maigres ressources provoquerait le même comportement. Dans une équipe avec le même environnement de développement (garanti par l'utilisation d'une image en chroot), le développeur ayant la plus mauvaise machine a le plus de chance de reproduire les bagots : un événement reste trop longtemps dans un bus de données, un réplicant mongoDB "laggue" alors que nous allons y lire une valeur... le test est rouge.

Il existe une multitude de manière de reconnaître ces tests. Un fort "smell" est constituée par l'utilisation d'un sleep : nous sommes alors dans le monde du test probabiliste. Le test est rouge ? Passons l'attente de 1 à 5 secondes. Allez, 10 secondes pour être sûr. Ça ne vous dit rien ? On me dit Courage ? Non, jamais entendu parler : supprimer ces 5 lettres suivies d'un entier est souvent un "refactoring" qui aura des répercussions profondes.

Sur notre dernier projet, nous avons beaucoup de code javascript exécuté dans le navigateur. L'ergonomie en est largement améliorée, mais la gageure des tests d'acceptance est encore plus grande. Nous avons parfois passé plusieurs jours, plusieurs semaines avant de résoudre un bagot (et parfois même échoué). Alors pour les héros qui ont pris leur courage à deux mains, et ont stabilisé ces tests, nous allons vous raconter leurs histoires, des histoires de bagots.