Favicon du blog, Twitter, LinkedIn, Github, Gitlab, YouTube, NextInpact, Steam, et désormais Mastodon, si vous me suivez quelque part vous n’êtes pas sans avoir que je suis fan d’un certain univers. Pourtant, à la faveur d’une remarque sur l’effroi que peut générer cette image, je me rends compte que peu de gens comprennent sa signification. C’est subtil, à l’image de ce que propose le premier volet cinématographique dudit univers.

Voilà le message qui m’a un peu trigger, tout en souriant évidemment devant le ton humoristique sur lequel il est écrit :

Et il s’avère que si j’ai pu partager de vive voix, notamment avec certains collègues de boulot (oui je mets pas ma photo sur mon compte pro non plus :D), sur la subtilité de cet avatar, non seulement la référence du film n’est pas évident pour tout le monde, mais la signification de cet avatar en particulier l’est du coup encore moins. Il est donc temps de faire honneur à cette image, dont l’utilisation s’avère, on est d’accord, un poil tendancieuse sur le terrain du droit d’auteur.

The Matrix, un de mes films préférés, dans le Top 5

Le film est sorti en 1999, alors je pars du principe que la plupart l’ont vu. Si vous n’avez pas encore visionné ce chef d’œuvre du cinéma de science-fiction (certains diraient presque d’anticipation, mais faut pas pousser), il me semble qu’il est possible de le voir sur Netflix, en location sur Amazon Prime – oui oui, en plus de l’abonnement qui vient d’augmenter de 20 balles – , ou en Bluray 4K dont je suis peu fan du traitement colorimétrique dont il a fait l’objet, on verra pourquoi dans un instant. Et une fois que c’est visionné, revenez pour la suite. Ou si vous êtes motivés, vous vous pavez la trilogie, mais comme mon avatar fait référence au premier, tant que vous revenez, après, hein…

Oui, j’évite volontairement de parler de Resurrections – le 4 quoi -, c’est pour votre bien

Si vous vous en tapez un peu, pas grave, voici un petit résumé. Sorti de nulle part, écrit et réalisé par deux frangins (oui à l’époque elles étaient encore des hommes), dont c’est le deuxième film seulement, le film nous embarque dans un univers plus que dystopique, ou l’humanité sert de batteries pour des machines intelligentes, humanité au cerveau branché en direct dans une sorte d’open world ++, La Matrice, et dont tout est fait pour qu’ils restent « endormis » dans ce monde afin d’exploiter tout le potentiel électrique jusqu’à leur mort. Certains se sont réveillés et enfuits, débranchés, reviennent de temps en temps dans ce monde comme des pirates pour tenter de réveiller toujours plus de personnes. Ces pirates mènent aussi une guerre bien réelle cette fois en dehors du monde virtuel contre les machines qui exploitent l’énergie, machines qui tentent évidemment de garder leur pré carré, voire d’aller débusquer les humains où ils se cachent pour les détruire.

Parmi ces pirates, l’un tente de trouver « l’élu », un mec ou une nana plus éveillée que les autres et capable de dépasser les règles du monde conçu par les machines, pouvant alors prendre l’avantage sur les machines depuis l’intérieur du système afin de libérer toute l’humanité. On passera sur l’aspect religieux à peine voilé de l’histoire (qui devient carrément gênant dans le troisième film), pour revenir au chercheur d’or. Il s’appelle Morpheus, fait un peu office d’évangéliste chez les humains – tout le monde ne croit pas forcément en cette histoire d’Élu -, et c’est donc le personnage que l’on voit dans mon avatar. À un moment du film, Morpheus se fait capturer pour permettre à Neo, qui est censé être l’Élu (c’est pas encore clair pour les personnages encore à ce moment-là), de s’échapper de la Matrice. Il est donc capturé, toujours « branché » à la Matrice, et torturé par des « agents », sorte d’antivirus locaux, parce que le bougre étant un ponte dans le milieu des humains, il est censé détenir des codes d’accès pour la seule cité humaine bien loin dans les profondeurs du sol terrestre. Pour la suite et la fin du film, ben je vous laisse le regarder (ou lire le synopsis complet sur Wikipedia pour les plus flemmards).

La subtilité qui fait tout

Dans le film, la distinction entre le monde réel et la Matrice se fait principalement sur la colorimétrie de l’image. Dans la Matrice, tout a une teinte un peu verdâtre, et l’image est ultra propre et lumineuse. Dans le monde réel au contraire, c’est bleu, voire gris, et beaucoup plus sombre. Il serait difficile de faire autrement puisqu’on apprend que dans la guerre contre les machines, à une époque où humains et machines vivaient uniquement d’énergie solaire, les humains ont salopé toute l’atmosphère pour plonger le monde dans une nuit éternelle. D’où la solution des machines de se servir des humains directement, pas folles les guêpes

Bref, pendant le fameux interrogatoire, Morpheus est donc, dans le monde réel, allongé sur son fauteuil de dentiste, la tête branchée à un ordinateur pour le plonger dans la Matrice, et c’est dans cette Matrice que son esprit est attaqué pour lui faire cracher les fameux codes. Donc cette image de torture avec les électrodes dans le film, vous la voyez en vert, ce qui traduit donc une lutte pour échapper au monde virtuel, en tout cas à ses geôliers. Mais mon avatar, vous l’aurez compris, n’est pas teinté de vert, mais bien teinté de bleu, et avec la grille de lecture de la scène, on peut penser que Morpheus essaie cette fois d’échapper au monde réel.

C’est pas cool comme image du coup, pour illustrer ce qui n’est qu’un avatar numérique ? Moi j’adore Je l’ai trouvé à une époque où je me sentais beaucoup mieux en ligne que dans le monde réel, et même si c’est beaucoup moins le cas désormais (je me soigne un peu, deux ans de Covid n’ont pas aidé par contre), j’ai du mal à vouloir en changer. Le monde réel ne va toujours pas mieux, mais désormais ça se ressent aussi en ligne, pas évident. Je garde le même en le foutant en noir et blanc peut-être ?

La salle d’interrogation originale, avec sa teinte verte

Oui, j’en fais peut-être un peu trop

Je ne me souviens plus comment je suis tombé sur cette image, qui n’est probablement qu’une simple photo de tournage (d’ailleurs il ne me semble pas avoir ce plan en particulier dans le montage final du film), il n’y a donc pas forcément de volonté de jouer avec ces codes. Mais c’est comme les passages interminables de bouquins centenaires d’auteurs chiants comme la pluie dont on sur-interprète les écrits pour remplir les cours de littérature de « première » de lycée sous prétexte de développer l’esprit critique des jeunes, comme si les auteurs avaient vraiment juste envie de dire autre chose que de décrire une scène chiante au possible sur trois pages, jusqu’à la couleur des moustaches d’un chat sans intérêt.

Dans tous les cas, je me répète, Matrix, c’est génial. Et même si les films suivants ne sont pas à la hauteur du premier pour moi – mal rythmés/montés, effets spéciaux vieillissants sur certains plans-, ça reste un univers marquant du cinéma, qui aura débordé ensuite sur des BD, du jeu vidéo (même si c’est pas glorieux comme résultat), du court-métrage d’animation avec The Animatrix, bref, il continue de nourrir l’imaginaire collectif plus de 20 ans après. Ce n’est pas pour rien, d’autant que les sujets d’IA sont de plus en plus nombreux, sans être plus réjouissante et la vision est moins pessimiste qu’un Terminator

PS : Et même s’il a peu de chance de lire ça, un grand merci à Laurence Fishburne de me permettre de m’illustrer de manière marquante sur le net

Oui je sais, plusieurs mois sans article, et là, juste un « message de service ». Non pas que ça soit dingue comme opération en plus, surtout que j’ai quand même bien dérivé de mon objectif initial (un peu comme pour le smarpthone), mais il fallait le mentionner. Petit retour rapide sur le pourquoi du comment, le déroulé, certains choix, etc.

L’historique de la bête

Ça fait un moment que l’idée de déménager le serveur me trotte dans la tête. En effet, le vénérable MiniSP 2014, qui date en fait de 2013, va donc sur ses neuf ans. Ça fait un bail que j’ai des soucis de performances disque avec, et il a eu chaud dans tous les sens du terme avec l’incendie de l’année dernière. Il est passé par une quantité de méthodes d’installation, la dernière en date est un Proxmox 5.4, oui je sais, ça fait un moment que le 7 est sorti, mais bon, vu l’âge de la machine, j’ai envie de dire, hein, pas pressé. Mais si j’envisageais déjà un déménagement l’année dernière, ça fait partie des choses qui sont passées en arrière-plan, entre procrastination et changements de priorités. Tout juste j’avais préparé un plan de migration, qui on le verra, a été grandement remanié pour l’occasion. Et pour cause…

Remember…

La mauvaise surprise d’OVH

Mais coup de tonnerre, OVH m’a envoyé un mail voilà quelques temps pour m’annoncer que SBG4, le datacenter où se trouve mon serveur rescapé, va être reconstruit, et que donc pour l’occasion, ils coupent tout, sans intention de rallumer; Date butoir : 28 février 2022. Les malins, ça leur permet de se débarrasser des anciennes gammes qui étaient encore à prix contenus, pas pour rien non plus que je le gardais sous le coude pépère… ils me proposent d’aller voir dans d’autres gammes, avec à la clé, si je reste chez OVH (pour des histoires d’adresse IP si je voulais les conserver), un tarif augmenté de 20€ par mois minimum. Branle-bas de combat, s’agirait de se bouger donc.

On ressort le plan de migration, direction Hetzner, comparaison des prix et des gammes de serveurs chez OVH toujours; non pas Scaleway, pas envie/besoin de créer un énième compte en ligne. Au passage, OVH m’a créé un ticket de support pour proposer son aide pour migrer les données, enfin surtout dire qu’ils filent un petit pourliche pour le premier mois d’un nouveau serveur. Quand j’ai répondu que j’étais en train de déménager ailleurs, le ticket a été vite fermé. Ils sont plus réactifs que quand on leur pose une vraie question…

La commande chez Hetzner, presque un sans faute, mais aussi une (très) mauvaise surprise

Je suis déjà client, je joue régulièrement avec le public cloud, mais là, on passe aux choses sérieuses. Le serveur, c’est celui que je visais au départ, l’AX41-NVMe, avec la fiche technique qui fait se lécher les babines, dont voici les principaux critères :

• AMD Ryzen 5 3600 (6C12T, 3.6GHz)
• 64Go de RAM
• 2x SSD 512Go
• Réseau Gigabit

Aucune surprise sur le prix du serveur, la disponibilité, et la rapidité d’installation (que j’ai du refaire, j’y reviendrai). C’est sur le réseau où j’ai pris une sacrée piqure : depuis milieu d’année dernière, Hetzner se voit contraint de reporter sur les clients finaux les couts d’achat des blocs d’IP, en raison d’explosion des tarifs liés à la pénurie et aux brokers qui s’en foutent plein les poches; et ils n’ont pas la taille d’un OVH pour absorber ces couts. Et non, je n’envisage pas encore de me passer d’IP supplémentaire et tout faire en IPv6, c’est pas encore possible partout (coucou NordNet, pouvez-pas demander à Orange de vous mettre à jour, après tout vous utilisez leur backbone). Mais voilà, au niveau tarif, on est sur un 182€ le setup :

Pour ceux qui ont l’habitude du manager OVH, on est sur du formulaire plus qu’austère, mais qui est ultra-léger et qui fonctionne, je n’ai pas eu à rafraichir ou recommencer plusieurs fois. Le serveur était marqué disponible « within minutes » et en effet, il a été livré à la vitesse de l’éclair. On peut directement passer sa clé SSH pour l’installation, c’est toujours plus sympathique que de voir arriver un mot de passe root par mail…

Le faux départ, et ensuite, que du bonheur

Par contre, j’ai perdu un peu de temps parce que j’ai commencé à configurer l’OS tout de suite, avant de me rendre compte que le partitionnement n’irait pas pour Proxmox : il manque LVM ! En effet, par défaut, le script d’installation d’Hetzner configure certes les disques en RAID1, mais ce sont des groupes de RAID pour chaque partition créée. Fort heureusement, on peut redémarrer en rescue et relancer le script d’installation qui va tout refaire from scratch, par contre, débutants, vous transpirerez quelques minutes sur la gestion du partitionnement. En effet, j’ai voulu rester en RAID1, mais je ne savais pas comment il allait s’occuper du mix RAID + LVM. Je n’ai pas mis longtemps à trouver la solution, mais la documentation gagnerait quelques exemples supplémentaires.

Ensuite, l’installation de Proxmox est triviale, on suit les instructions de Julien qui sont un peu plus à jour que la doc d’Hetzner, et une fois redémarré, Proxmox est prêt à l’emploi. Il faut quand même passer par la case configuration du réseau. La documentation suffit, sinon quelques recherches feront l’affaire. Sans surprise parce que je suis mauvais en réseau, j’ai raté l’étape IPv6, mais il semblerait que la solution ne soit pas loin, donc affaire à suivre. Je suis allé au plus simple, parce que je manquais de temps, donc affectation directe d’IP, et je verrai ensuite pour le firewalling.

Pour le déménagement en lui-même, même si j’avais prévu de refaire certaines VMs de zéro, je n’avais clairement pas le temps de tout faire. Je suis donc parti sur une des forces de l’utilisation des machines virtuelles : l’utilisation des sauvegardes ! Comme je n’ai pas un gros besoin de disponibilité, j’ai prévenu un peu en avance que j’allais déménager des trucs, et le jour où j’ai voulu bouger, j’ai coupé les machines, créé une sauvegarde (format lzo, fichier unique), transféré via rsync sur le nouveau serveur, une petite commande de restauration, et voilà. Enfin presque voilà, on reconfigure une partie du matériel (genre CPU pour repasser sur le défaut, la plateforme qu’on passe à q35 parce que pourquoi pas, et on vire une carte réseau inutile), on démarre, on reconfigure le réseau pour utiliser une de nos chères IPs, un test rapide, et hop bascule DNS de l’alias principal; ah oui, j’avais préparé cette partie en amont pour me réduire la charge de travail de ce côté-là. Le petit bémol vient dans le transfert vers Hetzner, avec un vieux serveur OVH bridé à 250Mbit/s, ça prend du temps, 1h pour les plus grosses machines transférées.

Ça m’a rappelé ce vieux truc sur AOL…

Et quand je disais que j’avais donc dévié du plan initial, au-delà de l’absence de recréation des VMs from scratch, j’ai aussi fait l’impasse sur certaines machines qui n’étaient plus en utilisation. Ça permet de gagner du temps et de l’espace, car un des gros points faibles de ce nouveau serveur est clairement l’espace libre disponible : 430Go effectif, c’est léger, mais c’est en partie parce qu’en l’état certaines machines sont surdimensionnées et je n’ai pas encore mis en place les backups externalisés. La migration aura au final tenu dans seulement deux machines effectivement restaurées (même si j’ai quand même fait une copie de certaines autres, au cas où), dont la configuration aura été simplifiée au maximum. Ce qui veut dire que oui, pour l’instant le blog tourne toujours sur une machine dépassée, qu’il est plus que nécessaire de remplacer.

Ce qui va mieux, ce qui sera mieux

Clairement, quand je vois la réactivité de la machine qui héberge le blog, c’est un truc de fou. Dites-vous bien que le backup de la VM a pris un peu plus d’une heure à être réalisé, pour seulement 100Go de données. L’écriture ne dépassait pas les 30Mo/s… Même le SSH prenait du temps à me donner la main sur le serveur, maintenant, les actions sur les services et les redémarrages VM sont instantanés ou presque. Parcourez le blog, si vous avez l’impression d’être sur un site statique, non, c’est toujours WordPress. Mais clairement, on sent la différence notamment sur les opérations en backoffice.

J’ai aussi décidé de tester le firewall embarqué dans Proxmox. Déjà parce que pourquoi pas. Ensuite parce qu’au bout de deux jours, j’ai pris un mail d’abuse me disant que le BSI, un quasi équivalent de l’ANSSI chez nous, avait détecté des services en écoute sur mes IPs qui sont exploitables pour des attaques par réflexion/amplification. Et c’était vrai. Et ça m’a permis aussi de voir, en faisant l’inventaire sur les différentes VMs, que c’était assez bordélique et qu’il trainait aussi des reliquats de trucs que j’avais jamais utilisé. Le truc le moins trivial de cette activation de firewall, c’est le fait qu’il faille l’activer au niveau de la VM, mais aussi de la carte réseau de la VM, sinon, ça ne s’active pas. Surprenant. En tout cas j’ai eu la bonne surprise de voir qu’il était ready pour l’IPv6, et que les règles que j’ai créé seront appliquées directement. La configuration est relativement simple :

• un IPset par host avec les IPs 4 et 6 associés
• des alias ou des IPset pour les machines externes (genre celle pour le monitoring)
• un Security group par host, avec des règles ciblant l’IPset
• J’affecte chaque security group à la VM associée

Ça sera probablement amélioré dans le futur, du style créer des security groups pour les règles communes à toutes les machines (ICMP, SSH et monitoring), ou créer des alias pour les IPs et ajouter ces alias dans les IPset, mais c’est déjà un gros plus par rapport à la situation précédente. Et aussi, contrairement à ce que j’ai pu faire sur un des VPS que j’ai déployé ou le firewall est géré par ufw via ansible, je trouve ça plus avancé et souple à l’usage. Le seul bémol, c’est que pour l’instant, je n’ai pas l’impression qu’on puisse gérer ce firewall via d’autres outils que l’interface web. Ni Ansible ni le provider terraform ne semblent armés, dommage. Je chercherai peut-être à mettre en front un firewall type pfsense, mais là aussi, l’industrialisation des règles de flux sera importante, et pfsense ne semble pas plus exploitable que Proxmox, donc ça sera à chercher, encore.

Un autre point qui va clairement être aussi géré dans un avenir proche, c’est l’accès au Proxmox. Je viens de passer le MFA sur le compte root via TOTP, mais l’idée, c’est d’arrêter de m’en servir pour mieux identifier qui fait les actions, y compris les miennes (nous serons au moins deux sur le serveur). Pareil, tout repose uniquement sur l’interface web.

Et enfin, les backups, ça c’est le boulot des jours qui viennent. Ça tombe bien, Hetzner vient de baisser le tarif des storage box, on va donc pouvoir mettre en place un espace déporté pour que les VMs soient directement stockées en Finlande. Sans exclure une petite copie sur mon NAS parce que pourquoi pas

Quand je ne suis pas en réunion/call/conférence Teams, et même en dehors du boulot, j’ai une tendance facile à laisser traîner un live youtube en mode « radio » (il en existe une foultitude). Mais l’âge du PC, la lourdeur de YouTube (son manque d’optimisation « standard »), font que je cherchais une solution plus légère. J’ai trouvé une solution de geek évidemment…

Ma machine date technologiquement : un Intel Core i5 6300U, ça reste encore vaillant, mais face à l’agression constante d’un Microsoft Teams, et d’un Firefox aux dizaines d’onglets ouverts, certains particulièrement consommateurs (consoles de cloud providers, entre autres), malgré les 16Go de RAM et le Crucial P2, certains moments deviennent pénible. Ajoutez que sous Linux, l’accélération vidéo dans les navigateurs reste problématique, et que malgré les solutions apportées sur le papier, j’ai toujours pas réussi personnellement alors que les plateformes Intel sont pourtant réputées faciles à exploiter. Le load s’envole à tout va, les latences dans la moindre action devient problématique, la seule chose qui reste constante, c’est le shell.

Je n’ai pas de capture d’écran à partager, mais voilà, lors d’un test « au repos », avec juste un onglet Youtube d’ouvert sur une des radios que j’écoute, le load atteint vite les 4/5 avec tous les cœurs à 100%, sur une machine qui n’a que deux cœurs physiques avec HyperTreading. Teams est déjà une purge quand il est tout seul, pareil pour Firefox avec tous les sites qui ne sont maintenant validés qu’avec Chrome (l’impression d’un retour en arrière de 20 ans, mais en remplaçant Microsoft par Google, on se sentirait presque Bill Murray). Je me suis donc mis en tête de chercher des alternatives plus légères, d’autant plus que seul l’audio est ma cible.

Une flopée de déceptions

VLC en tête d’ailleurs. C’est le seul logiciel à qui j’ai pu faire avaler le moteur de décodage vidéo du GPU intégré Intel, il portait donc beaucoup d’espoir. Mais depuis un certain temps, alors que pas mal d’articles, certains datant même de plusieurs années, ou parlant de la version de développement, mentionnent qu’il suffit normalement de lui passer l’URL d’une vidéo pour qu’il s’en charge, pas moyen ici de lui faire avaler celle de mon flux favori.

D’autres recherches m’ont envoyées vers différents logiciels de différents niveaux de finition. Une fois encore, la facilité apportée par AUR dans l’installation des logiciels et de leurs dépendance rend l’expérience de test beaucoup plus simple et rapide. Mais pas le résultat. Certains logiciels ne fonctionnaient pas du tout, d’autres étaient encore plus lourds qu’un navigateur. J’avais pourtant déjà exclus d’emblée toute application Electron, parce que bon, si c’est pour lancer un Chromium et ouvrir un site, autant utiliser Chromium qui est déjà fréquemment ouvert (j’avais déjà parlé de ça dans l’utilisation des proxy Socks). Ce n’est cependant pas ce que je cherchais.

Il y a une application qui a tenu deux minutes avant que je la supprime. Elle paraissait intéressante, mais elle ne supporte pas correctement les flux « stream », et changeait de vidéo au bout de 10 secondes. C’est particulièrement frustrant. Au total ce sont quatre ou cinq applications qui sont passées sur le grill et qui n’ont pas tenu l’objectif. Avec en plus des recherches entrecoupées d’actions liées purement au boulot, et des appels fréquents en ce moment (vacances, départs, on devient vite « seul au monde »), je désespérais de trouver une solution.

Le Graal encore une fois en « console »

Je finis sur une discussion qui parle de youtube-viewer. Quand on cherche juste youtube-viewer sur un moteur de recherche, on tombe sur plusieurs projets, mais celui-ci est en perl (ouais, je troll souvent sur le langage, mais voilà, parfois, ça fait le taf). C’est finalement un gros script, il n’est là que pour manipuler les API YouTube, et passer la vidéo à un lecteur adapté. Les premiers essais avec mplayer échouent (j’ai suivi les exemples dans la discussion), un rapide coup d’œil dans les issues github me confirment que le lecteur n’est plus supporté et que mpv doit lui être préféré; un coup de yay plus tard j’entends enfin mon premier son stable pendant plus d’une minute !

Je ne vais pas détailler toutes les possibilités de youtube-viewer, sachez que si vous comptez exploiter la recherche de vidéos, il faudra générer une clé d’API sur… votre compte YouTube/Google. Eh ouais, l’utilisation en mode « anonyme » ne peut se faire que via le navigateur ou les applications officielles, histoire de bien enregistrer le moindre de vos faits et gestes… Dans mon cas, vu que je passe l’URL directe du flux, ça n’est pas nécessaire, la documentation devrait vous aider.

Le dernier point qui me dérangeait, c’était que ça prenait un onglet dans Guake, et j’en ouvre déjà beaucoup trop j’ai donc monté un petit prototype de script qui ne sert pas à grand chose à part démarrer youtube-viewer en mode « arrière-plan » :

#!/bin/bash

screen -dmS mpv-youtube youtube-viewer --video-player=mpv --no-video $@

Ah oui, ce n’est pas mentionné, mais il faut installer youtube-dl pour que l’extraction des flux d’une URL fonctionne, il n’est qu’en dépendance optionnelle sur le paquet AUR. Et pour screen, c’est pas non plus installé par défaut. L’avantage, c’est que sous Manjaro/Arch, c’est d’une facilité déconcertante à installer.

C’est du prototype hein, donc ça se limite à dire « lance youtube-viewer, avec le lecteur mpv, sans aucun décodage vidéo, avec l’URL fournie au lancement du script. Le tout dans un screen pour rendre la main à la console. Les plus alertes auront compris qu’il n’y a aucun contrôle de lecture ou de volume du coup. En effet, pour couper le son pendant les appels, je me repose sur pulseaudio, qui a aussi le bon goût de pouvoir envoyer la lecture d’mpv sur la sortie « enceintes » du laptop, pour laisser le casque à Teams. Je n’ai pas besoin de contrôler la lecture, pour une bonne et simple raison…

Réduction du load : achievement unlocked

Je me suis remis dans la configuration du test initial pour mesurer le load : moins de 2, avec mêmes des descentes à presque 1. Le CPU respire et les latences sont réduites dans plusieurs situations, j’ai donc moins de frustrations à l’accumulation de ces micro-attentes qui se répètent à longueur de journée. Par conséquent, le manque de contrôle de la lecture n’est pas un problème fondamental, dans la mesure ou il n’y a plus qu’à couper le son pour ne pas être dérangé, la lecture peut continuer sans avoir d’impact important sur mon quotidien.

Voilà, une grosse astuce qui méritait un peu plus qu’une petite place dans un « astuces diverses » (on vient de dépasser les 1000 mots). Et oui, j’ai encore trouvé une solution qui n’est pas à la portée de tout le monde, mais quand les outils pour monsieur tout le monde deviennent trop pénibles, la console nous sauve tous. Et il n’est pas dit que j’aurais pu trouver une solution simple sous Windows (bon ceci dit, l’accélération vidéo sous Windows, ça fonctionne mieux, alors…).

Il n’est pas rare, pour des plateformes Kubernetes à destination des clients, qu’on déploie aussi un serveur Gitlab pour gérer les sources des packages Helm et autres Dockerfile à l’usage des applications qui seront déployées. Ce serveur voit ses accès filtrés par IP, du coup, avec une IP dynamique (merci Orange), compliqué de gérer en permanence des règles de flux pour y accéder. Il y a heureusement une solution qui demande un peu de taf.

C’est dans le titre, l’idée va être de faire passer les connexions git et gitlab via un proxy Socks, créé par une connexion SSH. Cette connexion doit se faire sur une machine qui remplit deux critères, avoir une ip fixe, et avoir accès au serveur Gitlab. Si on établit la connexion SSH au serveur en question, c’est parfait ! Et cette connexion passe par un rebond au travers du VPN du boulot, rebond connecté au réseau privé du gitlab par un autre VPN. Ouais le réseau c’est chiant, mais c’est souvent comme ça qu’on procède, pas de connexions SSH via réseau public (et pas question de laisser le SSH ouvert à grand vent).

Notez bien que la configuration « proxy » est utilisable même avec un setup de rebond tel que je l’ai déjà présenté par le passé. C’est pas génial ça ?

On commence donc par créer la connexion/proxy. Il s’agit simplement d’ouvrir un port dynamique qui sera automatiquement paramétré en tant que proxy Socks. Avec OpenSSH sous Linux (ou Windows via WSL), c’est super simple :

$ ssh -D 9999 gitlab.domain.tld

À partir de là, on peut configurer nos différents clients pour utiliser ce proxy afin de joindre le domaine utilisé pour le gitlab. Si vous voulez ouvrir le port systématiquement, vous pouvez passer par le fichier ~/.ssh/config :

Host gitlab.domain.tld
  DynamicForward 9999

À ajouter aux autres éventuels réglages spécifiques pour cette connexion (user, clé SSH particulière, etc).

Pourquoi pas le localforward ?

J’ai déjà joué au localforward par le passé, par exemple pour le master k3s. Ça fonctionne bien dans ce cas-là, mais pour Gitlab, l’interface web me mixait des liens en 127.0.0.1:9999/groupe/projet/... et des liens en gitlab.domain.tld/groupe/projet/... et ces liens-là tombaient naturellement dans le vide. Pas du tout pratique donc, le proxy permet d’être complètement transparent, et de ne pas avoir à jouer avec son fichier hosts, ce qui n’est déjà pas une sinécure sous Linux, encore moins sous Windows.

D’ailleurs en parlant des windowsiens, pour ceux qui seraient coincés en enfer et qui utiliseraient encore PuTTY, voire MobaXTerm (oui y’a des masochistes), autant j’ai réussi à faire un truc avec PuTTY honteux au point que je ne détaillerai pas ici, autant MobaXTerm m’a résisté, impossible de créer un tunnel sur une machine derrière un rebond. Windows 10 et 2021, préférez WSL, ça fonctionnera très bien. Vous n’êtes pas obligés d’utiliser un navigateur dans WSL pour pouvoir accéder au port en question, c’est pas super ça ?

Git, tellement souple

En ligne de commande, git est particulièrement intéressant pour l’utilisation de proxy Socks. Pour un clone de départ, il suffit de paramétrer la variable ALL_PROXY avant de faire son clone :

$ ALL_PROXY=socks5://127.0.0.1:9999 git clone https://gitlab.domain.tld/group/project.git

Quoi, c’est tout, c’est aussi simple ? Ben oui, par contre, c’est valable que pour la session en cours. Git est heureusement incroyablement intelligent, et vous pouvez configurer ce proxy pour le dépot de manière persistante :

$ git config http.proxy socks5://127.0.0.1:9999

Les prochaines commandes sur le dépôt tenteront d’interagir avec l’upstream via le proxy configuré. Et foireront si vous oubliez d’ouvrir la session SSH évidemment. Nickel.

UPDATE: je suis tombé sur un article dont j’ai perdu le lien qui explique que sur du git récent on peut carrément définir le proxy pour tout un domaine dans la conf globale. Donc dans le ~/.gitconfig, ça ressemble à ça:

[http "https://gitlab.domain.tld/"]
    proxy = socks5://127.0.0.1:9999

Du coup plus besoin de faire ALL_PROXY=... et git config ..., ça le fait automatiquement, y compris pour les nouveaux clones

Gitlab, une affaire de navigateurs

Pour les navigateurs, c’est un poil différent. Pour Firefox, les paramètres sont natifs, ouvrez le menu des préférences et cherchez proxy, vous verrez le bouton qui va bien.

Il suffit de configurer un proxy Socks 5, sans authentification, avec les mêmes paramètres qu’au dessus. Attention, ça implique de passer toutes les connexions de tous les onglets en cours dans le proxy, car le paramètre est global. Pour une gestion plus fine, il faudra une extension permettant plus de contrôles.

Pour les navigateurs basés sur Chromium, c’est plus compliqué. Par défaut, il n’embarque aucun paramètre natif et repose, notamment sous Windows, sur le proxy global déclaré dans les paramètres réseau. Il faut donc obligatoirement une extension pour faire le boulot, j’ai sélectionné Proxy SwitchyOmega qui m’a donné satisfaction.

Elle permet de déclarer plusieurs proxys, de facilement switcher entre les proxys, il y a même un mode dynamique qui permet de switcher entre plusieurs proxys en fonction du domaine (je n’utilise Chromium que pour des besoins ultra ciblés, malgré tout, il arrive de devoir basculer rapidement d’un projet à l’autre). Bref, vous aurez toutes les clés pour accéder comme il faut à l’interface de votre serveur Gitlab sans risque de conflits de liens/domaines.

Pas que pour Gitlab

Ce système de tunnel SSH est exploitable comme alternative aux VPN qu’on nous vend ad nauseam dans les vidéos Youtube. Il m’est arrivé de tester rapidement des accès à une plateforme par ce biais via plusieurs serveurs dans différents réseaux, pour évacuer un problème dépendant du fournisseur d’accès (déjà eu un incident client déclaré mais au final lié à Orange). Par contre, une des promesses des VPN est de pouvoir contourner les géoblocages mis en place par des plateformes de fourniture de contenu par abonnement, mais la plupart des ranges des hébergeurs sont déjà identifiés et bloqués (vécu par un collègue avec un VPS chez OVH au Canada pour tenter d’accéder au catalogue Netflix US).

Dans l’absolu, vous pouvez faire passer tout type de trafic et d’applications, soit de manière native, soit de manière un peu détournée. Entre le début et la fin de l’écriture/mise en forme de cet article, j’ai rajouté tsocks à ma trousse à outils qui me permet de faire passer… des connexions SSH au travers du proxy SOCKS ouvert… par une autre connexion SSH. Oui, c’est assez tordu, et un jour je vous expliquerai peut-être l’immense bêtise qui m’a poussé à devoir procéder de la sorte.

Je pensais que vu le caractère exceptionnel et les impacts, ça aurait dépassé la sphère du monde de l’informatique. Mais non, l’incendie important qui a touché OVH, premier hébergeur d’Europe, et paralysé plusieurs milliers de clients, est finalement resté sous le radar du grand public. J’ai fait partie des victimes, et j’avais envie de vous partager un peu mon ressenti pendant ces deux semaines compliquées. Et comment je compte m’adapter.

Vous ne verrez pas ici de grosse critique de ma part sur la situation, hébergeur n’est pas mon métier, et je n’ai pas assez de connaissances concernant les normes d’infrastructures informatiques pour donner des leçons. En dehors même des vrais reproches qu’on pourrait faire à OVH, aussi bien sur des problèmes passés qu’actuels, j’en ai beaucoup plus à propos des réactions des clients, mais je vais tenter de me retenir aussi. La communication d’OVH pourrait aussi en prendre pour son grade, hein.

Petit descriptif chronologique

Donc pour rappel, au petit matin du 10 mars dernier, un important incendie a débuté dans l’un des datacenters d’OVH, au petit nom d’SBG2, entrainant la perte complète du datacenter en question, et donc tout ce qu’il contenait de machines, de réseau, de stockage : VPS, serveurs dédiés, clusters VMware, datastores, et quelques backups, tout y passe. La proximité avec les autres datacenters faut que le voisin historique, SBG1, a pris aussi une bonne claque dans la gueule, avec à ce moment-là la perte confirmée de 4 « salles » sur les 12 qui le constituaient. Je met « salle » entre guillemets car la construction d’SBG1 reposait sur un concept maison, sous forme de container maritime, une salle = un container. Je vais pas m’étendre trop sur le sujet, à savoir qu’au final sur le site de Strasbourg, il y a actuellement 5 « DC », et qu’ils ont coupé électriquement les SBG1 à 4 par sécurité pendant tout ce bordel.

Je découvre ça le matin à 6h30, les pompiers sont eux en train de se battre courageusement contre le feu, et je me demande où était le serveur dédié. De son côté, mon LibreNMS m’inonde de messages sur Telegram pour me dire que tout est HS. Je colle une bonne grosse maintenance pour lui couper la chique et me concentrer effectivement sur le serveur. Où était-il ? En effet, il remonte à 2013, on l’a récupéré courant 2014, et j’avoue que jusque là, à part savoir qu’il était géographiquement à Strasbourg, et que ça avait impacté négativement le ping sur les serveurs Call of Duty, ça n’avait jamais plus intéressé. À ce moment-là, les clients ne sont pas tous réveillés, donc je peux encore accéder au manager OVH et voir que le serveur serait à SBG4. Donc, en l’état le serveur ne serait que éteint. Je suis pas forcément super rassuré, vu l’âge du machin, on est pas à l’abri qu’il ne redémarre pas, mais au moins il n’a pas fondu. J’attaque donc ma journée de boulot moins inquiet que prévu.

Dans une certaine mesure seulement, nous gérons quelques infrastructures hébergées par OVH pour des clients, et on est salement touché : une plateforme mutualisée qui contenait une centaine de machines virtuelles est partie en fumée, une autre dédiée à un client a sauté aussi, au total, bref, une vingtaine de clients se sont retrouvés la tête dans la fumée. Nos services managers se retrouvent à jongler avec leur(s) téléphone(s) toute la journée, et deux semaines après, certains sont encore particulièrement en difficulté, mais ce n’est pas le sujet ici. De mon côté, je surveille surtout les annonces notamment d’Octave Klaba, le patron d’OVH, qui pour l’anecdote est mon deuxième abonné Twitter lors de mon inscription en 2012. On a donc confirmation de la destruction complète d’SBG2, partielle sur SBG1, SBG3 a été épargné, le 4 qui est derrière le 3 aussi. Tout ce petit monde est en coupure de sécurité. Le feu est maitrisé dans la journée, les premiers constats commencent avec le retour des employés sur site, l’inventaire commence pour trouver des solutions aux clients. De mon côté, on m’annonce un rallumage à partir du 15, une fois l’électricité remise en place et le réseau contrôlé. Je met un message sur Twitter qui a dû en faire sourire plus d’un.

Donc pour info, le #blog est HS suite à la coupure électrique sur #OVH #SBG . Comme je suis un gros flemmard et que le rallumage est prévu pour lundi prochain, j'attendrais jusque là. Pendant ce temps-là, je vais préparer le nouveau serveur que je dois faire depuis six mois

— Seboss666 (@Seboss666) March 10, 2021

Si vous avez déroulé le fil Twitter en question, vous avez la suite, mais bon, je résume : le serveur est rallumé le 18 mars au soir vers 22h, mais je ne reçois pas le mail avec les infos du mode rescue. C’est une particularité d’OVH, et une première bêtise de ma part, le contact utilisé pour envoyer le mail est le contact technique. Celui-ci est différent du contact administrateur. Sauf que la boite mail que le contact technique utilise… est normalement hébergée sur le serveur dans une machine virtuelle dédiée. Qui est donc éteinte. Donc pas d’infos. Et pour accéder au manager OVH avec ce compte et consulter la copie du mail envoyé, il faut rentrer un second facteur… envoyé par mail aussi. L’ouvre boite dans la boite, c’est génial Je ne percute pas tout de suite, je suis claqué, je vais me coucher pour réfléchir aux solutions le lendemain matin. Et donc, vendredi matin, je tente avec ce que je connais déjà comme info (la clé SSH enregistrée sur le compte technique), et j’accède donc au mode rescue permettant de procéder au diagnostic, à savoir vérifier l’état du RAID, des systèmes de fichiers, pour écarter tout risque de corruption de données. Bref, tout à l’air OK, et on redémarre sur les disques. Je passe sur quelques difficultés de certains services à redémarrer, je les relance à la main, le blog est de retour, youpi, je bip sur Twitter et je retournes bosser. Je suis quand même content de retrouver mon FreshRSS pour pouvoir reprendre ma veille (et mes abonnements YouTube).

Le soir, je continue à dépiler les quelques 800+ entrées, et d’un coup sans prévenir, plus rien ne répond. Mon premier réflexe, une fois ma connexion vérifiée, c’est que le serveur a dû crash; encore une fois, il n’est plus tout jeune. Je demande confirmation à Arowan, qui n’accède plus non plus, pour découvrir moins de 10 minutes plus tard, un nouveau message d’Octave, qui annonce avoir recoupé SBG1 et SBG4 pour vérification. Un peu plus tard, on apprend que c’est un deuxième départ de feu, sur un jeu de batteries d’onduleur, qui a du être maîtrisé très vite. Mais sur SBG1, qui pour rappel, avait déjà pris une bonne sauce avec le premier feu. Je termine la soirée sur un message encourageant indiquant un potentiel redémarrage le lendemain dans l’après-midi.

Samedi matin, apparemment c’est plus grave que prévu : il est décidé d’abandonner SBG1, de déménager une partie des machines sur SBG3, ou carrément Roubaix, soit plusieurs centaines de kilomètres entre les deux. De reconstruire l’électricité de SBG4 from scratch, et de remplacer le réseau présent dans SBG1 par une nouvelle installation dans SBG5. Les dégâts sont donc plus importants que prévus. Et tout ça repousse le redémarrage effectif de SBG4 au 24 mars. Je reviendrai dessus tout à l’heure, mais comme j’ai plus que jamais besoin de mes flux RSS, je m’attaque à l’accès à mes sauvegardes au moins pour celui-là, et ça prendra un peu de temps. Je met à jour le fil Twitter concernant le blog. En fin de journée, j’ai récupéré mon FreshRSS via une stack lamp déployée avec docker-compose sur mon laptop, et il reste encore 250 flux RSS à vraiment lire/visionner.

Fast-forward parce qu’il n’y a pas grand chose à dire entre temps, une mise à jour indique un redémarrage des serveurs le 25 mars, et finalement c’est le bien 24 mars dans la soirée. J’ai encore le souci de services qui ont du mal à cause de lenteurs disque, mais je remet tout en ligne, et depuis, tout va bien.

Le gros problème : les sauvegardes

On va rentrer un peu dans le détail technique, sans pour autant rentrer dans le très dur. Ma machine est donc un serveur dédié, ce qui s’appelle maintenant « bare metal » dans le catalogue d’OVH, à savoir, un vrai « PC » pour moi tout seul. Le service associé comprend un espace de backup de 500Go, sachant que le serveur a une capacité de 2To. Ouais, faut faire des choix, ceci dit il existe des options (payantes et pas qu’un peu) pour augmenter cet espace. La particularité et l’intérêt de cet espace, c’est qu’il est géographiquement loin : serveur à Strasbourg, backup à Roubaix. Il y a cependant plusieurs inconvénients, dont certains ont eu des conséquences sur mon usage réel de cet espace, et sur son accès. Le premier, c’est sa performance : c’est tout simplement une catastrophe. Les débits sont infernalement bas. Au départ, j’ai tenté de plugger directement les backups de Proxmox dessus, mais les taux de transferts étant anémiques (on parle d’1Mo/s, voire moins), ça prenait plusieurs heures même pour une petite machine. J’ai donc laissé tomber cette approche, et me suis concentré sur une sauvegarde « fichiers » des principaux sites webs de la machine vox, via backup-manager. Et au final, je n’ai pas fait grand chose de plus en termes de backup, ce qui n’est pas la meilleure chose, puisqu’il y a aussi sur ce serveur, une machine virtuelle « pare-feu » dont la configuration n’était pas sauvegardée, un machine virtuelle « mail » (celle que j’ai évoqué, qui contient les mails pour réparer le serveur…), une machine virtuelle contenant plusieurs serveurs de jeu Call of Duty, Minecraft, une machine Windows que je venais de remonter pour un ami qui voulait un serveur Hurtworld (parce que monsieur connait pas Linux…), bref, beaucoup de monde qui était sans filet.

Chat = données, panier = backup storage

Quand bien même j’aurais pu sauvegarder tout ce beau monde, il reste l’accès à ces sauvegardes. OVH a une approche conservatrice, à savoir que via le manager, seules les adresses IP associées au serveur peuvent être autorisées à accéder à l’espace backup. Sauf que toutes les IPs étant sur le serveur qui était éteint, j’étais coincé. La première solution apportée par OVH, c’est de commander une autre machine, de « déplacer » une des IPs failover sur cette nouvelle machine, et hop, on a accès au backup. Oui mais non, c’est pas au programme, les machines chez OVH ont doublé de tarif depuis, c’est aussi pour ça que le serveur a huit ans. Sans parler qu’on a un historique peu glorieux en matière de fiabilité de déplacement d’IP entre serveur, et en ce moment le support technique a d’autres chats à fouetter. La deuxième solution qui a failli être bien sauf pour les humains, c’est l’utilisation de l’API pour ajouter une IP autre que celles du service. L’espoir d’accéder directement aux backups depuis chez moi a cependant été vite douché par une petite mise à jour de la documentation spécifiant que l’adresse IP doit être celle d’un service OVH. Le lot de consolation donc que cette IP n’a pas besoin d’être déplacée d’un serveur à un autre, ni qu’on doit prendre un truc de la mort, un simple VPS à 3€ par mois suffit. Ça tombe bien, le LibreNMS est sur un VPS OVH, je l’ajoute donc via l’API (en vrai, via l’interface web c’est assez facile), et quelques minutes plus tard, j’ai enfin accès à l’espace backup, et je peux récupérer mes backups, les derniers datant du 9 au soir, soit juste avant le début de l’incendie.

Et je m’en suis sorti comme ça en attendant le rallumage. Mais le fait est que si j’avais été encore plus négligeant, ou que le serveur avait été détruit, j’aurais tout perdu (ce qui était arrivé à Nicolargo par exemple).

Quels sont les constats de toute cette histoire ?

Déjà, que je suis chanceux : ma machine n’a pas été détruite ou endommagée par l’incendie, alors que certains ont tout perdu. Pour le dire rapidement, certains avaient leurs sauvegardes physiquement proche de leurs machines, et tout à été détruit en même temps. La recommandation est d’avoir son backup géographiquement éloigné, sauf que la plupart du temps, l’option coûte vite assez cher : le Backup as a Service des offres Private Cloud fait un x3 sur le tarif quand on veut que les backups soient stockés à Roubaix quand le cluster est à Strasbourg. Et ceux qui laissent volontairement tout backup de côté pour gratter quelques euros vont maintenant payer beaucoup plus cher d’avoir tout perdu (j’avais dit que les clients allaient prendre un taquet ?).

À Copier 200 fois

Ensuite, que ma politique de sauvegarde est salement incomplète : je l’ai dit, j’avais carrément laissé tomber certaines machines virtuelles, mais ce que j’ai également constaté en fouillant dans les backups disponibles, c’est que si je sauvegarde les fichiers et les bases de données des sites web, je n’ai rien gardé des configurations de Nginx ni de PHP que j’ai utilisé pour les différents sites. Donc même avec les fichiers, il me manque certains éléments pour remonter à l’identique, en tout cas dans une configuration la plus proche possible, un environnement d’exécution pour les sites. Je n’avais non plus aucune méthode sur le moment pour accéder à l’espace de backup avant qu’OVH finisse par communiquer dessus. Je suis donc resté plusieurs jours sans pouvoir restaurer certains éléments même de manière temporaire (mes flux RSS) le temps de rétablir le service. Au passage, le VPS n’est sauvegardé nulle part, et je l’ai appris avec douleur lors d’une mauvaise manipulation qui a supprimé beaucoup plus de fichiers que prévu sur le site web de mon équipe. Ce VPS étant à Gravelines, il est déjà géographiquement à part du serveur, ce qui était justement un des buts recherchés.

Pour discuter en dehors de ma situation, j’ai vu quantité de messages et d’articles sur le sujet. On se croirait dans la situation de la pandémie, avec un épidémiologiste derrière chaque compte Twitter, et une cohorte de cerveaux lavés aux discours des « cloud providers » américains qui pensent qu’OVH faisait gratuitement plusieurs copies géographiques de toutes les données de tous les services de tous les clients. La même réflexion qu’on avait pu voir quand des clients mutualisés avaient souffert lors de la perte du SAN mutu-pro deux ans auparavant, suite à une fuite de watercooling. Des boutiques en ligne, donc une activité commerciale, hébergées sur des offres à 3€, aux garanties et services très faibles donc, et qui demandent des comptes à l’hébergeur… Je pratique AWS, GCP et Azure au quotidien, et s’il est certainement plus facile de mettre en place des gardes-fous, sauvegardes, réplications multi-zones/régions, rien n’est automatique ou presque, et surtout, rien n’est gratuit. Une instance CloudSQL (Database as a Service), en haute disponibilité, ben ça vous coûte deux fois plus cher que sans la haute disponibilité. Mais si à la main c’est chiant à faire, là, vous cochez une case et tout est fait pour vous. Et la case n’est pas cochée par défaut. Donc tous ceux qui se plaignent sont ceux qui ne veulent pas sortir leur portefeuille pour fiabiliser leur activité.

Et avec tous les clients qui ont vu passer l’incident et qui nous font chier sur l’absence de DRP/PRA (parce qu’à un moment donné il faut le dire), on leur rappelle que la facture serait deux à trois fois plus élevée s’ils en voulaient. Et dans la quasi-totalité des cas, ça se finit en « ouais finalement on va rester comme ça, à la limite si les backups pouvaient être multi-zones ? ». Et allez pas croire que même les plus grosses structures sortent les moyens plus facilement, c’est même souvent l’inverse.

Qu’est-ce que je prévois de faire pour éviter les futurs problèmes, et surtout m’en remettre plus facilement ?

J’ai déjà modifié la configuration de backup-manager pour inclure PHP et Nginx, en plus des fichiers et bases de données. Pour le reste, je n’ai pas prévu de pousser beaucoup plus dans l’immédiat, pour la bonne et simple raison que j’avais déjà prévu, mais je vais accélérer, le déménagement de tout ce bazar vers une installation plus récente, et surtout, pas chez OVH : comme je l’ai dit, je n’ai pas envie de rester chez eux pour ce besoin-là en particulier parce que l’offre n’est plus intéressante. La gamme OVH est devenu inintéressante techniquement (Intel Only), notamment dans les gammes de prix que je vise, un remplaçant actuel me coûterait presque deux fois plus cher. La gamme « SYS » utilise du matériel qui la plupart du temps date de l’époque de mon serveur actuel, donc niet. Et l’offre Scaleway actuelle ne m’attire absolument pas.

Celui qui m’a fait de l’œil et que j’ai sélectionné, c’est Hetzner. La petite pousse allemande propose des gammes Intel et surtout AMD dans des prix beaucoup plus intéressants par rapport à OVH pour la prestation proposée. Les Storage Box sont beaucoup plus souples à utiliser que le Backup Storage fourni chez OVH, je m’oriente donc vers un serveur en Allemagne et une Storage box en Finlande. Et au final, je ne vais pas détruire mon budget. Il est prévu de copier certaines machines virtuelles en l’état, et d’en refaire de zéro (celle du blog va enfin passer sur Debian 10, ou 11 en fonction du plus rapide à se bouger le fion :D). Les fichiers du VPS seront aussi sauvegardés sur cette Storage Box. Et je vais remettre en service comme il faut les backups des VMs. Les refaire de zéro permet aussi de remettre à plat leur stockage. Cerise sur le gâteau, on vise une installation full firewallé via pfSense, et la mise en place de l’IPv6. Un programme ambitieux donc

Et pour les autres clients d’OVH ?

Chacun sa merde ? Plus sérieusement, je ne peux réellement parler que des projets de nos clients. Certains n’ont pas de données stockées sur les infras détruites, et sont en capacité de redéployer leur application n’importe où : on a donc reconstruit des machines from scratch dans l’urgence ailleurs pour qu’ils redéploient leur application et fassent pointer leur domaine dessus. Pour les autres, c’est plus délicat : dans le cadre des Private Cloud, si les sauvegardes sont intactes, on n’a plus qu’à remonter un cluster from scratch pour qu’OVH procède aux restaurations. Une petite reconfiguration réseau plus tard, et les machines pourront revenir en ligne. Pour les sauvegardes perdues, le dernier espoir est une sauvegarde interne des datastores effectués par OVH. Mais ces sauvegardes ont peut-être été détruites aussi en fonction de leur emplacement. N’étant pas au cœur de l’action dans les équipes concernées, je n’en dirai pas plus, surtout que ces opérations peuvent prendre du temps, et les équipes d’OVH travaillent d’arrache-pied pour les milliers de clients touchés. Je leur tire mon chapeau dans tous les cas pour le boulot qu’ils abattent depuis un mois pour remettre tout le monde sur pied d’une manière ou d’une autre.

Là encore, dans les enseignements qu’on va en tirer, je pense qu’on aura pas trop le choix que de payer plus cher pour avoir un système de sauvegarde plus solide. Le problème, et je parlais de la communication chez OVH, c’est qu’historiquement, le Backup as a Service n’avait qu’une seule option pour un seul prix. Quand ils ont fait évoluer le service pour ajouter les options géographiques, personne ne l’a su et on a pas adapté la stratégie en amont. On en paie donc les conséquences aujourd’hui. Certains clients vont nous demander de quitter OVH, sauf que ça leur coûtera inévitablement plus cher. D’autres nous feront payer des pénalités parce que notre métier est de garantir la disponibilité et l’intégrité de leur plateforme. De notre côté, il est certain qu’une fois la tension retombée, la bataille sera contractuelle et juridique pour réclamer les dédommagements de rigueur à OVH.

De mon côté, je vais accepter le fameux mois offert de compensation, et pendant ce temps-là, je vais préparer la nouvelle infra. Je ne garderai que le VPS, et je cherche encore un système de stockage pas cher pour gérer une bouée de secours pour les backups de VMs les plus lourdes, qui ne tiendrons pas sur la Storage Box (sauf à la prendre beaucoup plus grosse, mais ça coûte beaucoup plus cher). Bref, tout est bien qui finit bien.

On s’est retrouvé récemment au boulot face à un petit souci : le mot de passe root par défaut d’une machine fraîchement déployée n’était pas accepté. J’ai donc voulu, de mon côté, trouver le mot de passe par des moyens moins conventionnels. Avec ma première tentative d’utilisation d’un outil incontournable quand on veut se lancer dans le cracking de mot de passe.

La machine virtuelle est donc une CentOS 7 déployée à partir d’un template vmware préparé avec Packer, et configuré via Kickstart, l’outil d’installation automatisée de Redhat. Dans la configuration kickstart, la version « hashée » du mot de passe, au format final sous Linux, est utilisée. J’ai donc voulu partir de ce hash pour retrouver le mot de passe initial.

Hashcat, la rolls des crackers de mot de passe, quand on a le matos

Historiquement, les gens qui voulaient casser du mot de passe linux utilisaient JohnTheRipper, qui reste encore populaire, mais dont l’âge se fait sentir semble-t-il. Le problème, c’est que John ne fonctionne qu’avec le CPU, alors que depuis quelques années, la puissance brute de nos cartes graphiques dépasse largement celle du CPU. Hashcat est capable de fonctionner avec les deux, soit en même temps, soit seulement avec l’un ou l’autre, et exploiter la parallélisation des architectures modernes pour être toujours plus efficace. Il a aussi le bon goût d’être opensource, multiplateforme, bref, que du bonheur. Par contre, comme souvent sous Linux pour certains usages GPU, mieux vaut utiliser une carte Nvidia, les outils AMD pour faire de l’OpenCL sont… Enfin bref, de toute façon, les tests qui vont suivre ont été faits sous Windows, ce qui ne demande finalement qu’un pilote assez récent.

Au départ, je pensais pouvoir utiliser le laptop du boulot, sous Linux. Aucun problème particulier pour le lancer, mais entre la chaleur dégagée et la lenteur, j’ai vite lâché l’affaire. Le fait est qu’on a pu identifier que le souci qu’on rencontrait était un problème d’ICC, j’ai donc arrêté mes tests, et ça m’arrangera pour la suite, quand j’ai attaqué les tests avec la Radeon RX5700XT à ma disposition.

Une brute de calcul, oui mais…

Je rentre donc à la maison et rouvre ma note enregistrée via nb. Je récupère le hash, le met dans un fichier, et démarre les hostilités. Premier constat, avec les options que j’ai utilisé, ça reste super long, et surtout, je teste toutes les possibilités, même celles dont je suis sur de ne pas avoir besoin (toutes les combinaisons inférieures à 8 caractères). Au bout de plusieurs heures, je ne suis pas encore arrivé à 8 caractères, qui était au final le résultat attendu.

Je vois que le nombre de hashs par seconde est particulièrement faible, aux alentours de 9500kH/s. Pourtant, l’algorithme affiché semble être du MD5 (mon hash commence par $1), et quand on voit les chiffres dans cet article d’impact-hardware, on sent qu’il se passe quelque chose :

Image INpact-Hardware

Je devrais donc tourner aux alentours de 26000MH/s, ce qui commence déjà à devenir sérieux (on parle d’un facteur x2600 quand même). Alors bon, est-ce que j’ai des soucis ? L’avantage d’Hashcat, c’est qu’il peut enregistrer la session pour revenir dessus plus tard. J’enregistre donc la session en cours, et relance un test avec une version « md5 » simple du mot de passe, généré avec un petit « echo -n pass |md5sum », et là, magie :

Session..........: hashcat
Status...........: Running
Hash.Name........: MD5
Hash.Target......: 84de940c098f17f071c1307f135f42dd
Time.Started.....: Sun Apr 04 13:52:10 2021 (13 secs)
Time.Estimated...: Sun Apr 04 13:56:08 2021 (3 mins, 45 secs)
Guess.Mask.......: ?1?2?2?2?2?2?2?3 [8]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined
Guess.Queue......: 8/15 (53.33%)
Speed.#1.........: 23089.7 MH/s (6.89ms) @ Accel:256 Loops:512 Thr:64 Vec:1
Recovered........: 0/1 (0.00%) Digests
Progress.........: 318137958400/5533380698112 (5.75%)
Rejected.........: 0/318137958400 (0.00%)
Restore.Point....: 3932160/68864256 (5.71%)
Restore.Sub.#1...: Salt:0 Amplifier:13312-14336 Iteration:0-1024
Candidates.#1....: Tfc50n07 -> kjj6d9ce
Hardware.Mon.#1..: N/A

Ça bourre, donc ça colle, ce n’est pas un souci matériel. J’ai une confirmation via une publication de résultats du mode benchmark que je suis dans les ordres de grandeurs que je peux attendre de ma carte :

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)

Speed.#1.........:  8992.2 kH/s (69.33ms) @ Accel:256 Loops:500 Thr:256 Vec:1

Je décide quand même de laisser tomber mon premier test, pour en refaire un en retouchant rapidement mes options. Et je patiente. Longtemps… Très longtemps… Mais il trouve. Je reviendrai tout à l’heure sur les raisons profondes qui font la différence, spoiler je suis bête comme mes pieds.

Paie ta ref de vieux

La surprise du brute-force par défaut

En effet, au début, je n’avais pas laissé le mode bruteforce par défaut sur md5 tourner longtemps, l’objectif était d’abord de valider les chiffres de performance. Mais à un moment donné, comme je voulais comparer avec le mode unix, j’ai refait le test et laissé tourner. Mon mot de passe fait huit caractères, ça devrait donc être assez rapide. Sauf que je le vois tourner, et passer à 9 caractères sans avoir trouvé. Il n’y a pourtant que des majuscules et minuscules !

J’investigue donc ce problème, relance en nettoyant d’éventuelles traces d’exécutions précédentes, rien, il passe encore sur toute. Et puis je vois un truc :

Guess.Mask.......: ?1?2?2?2?2?2?2?3 [8]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined

Prenons quelques secondes pour déchiffrer ça. Il applique donc un masque sur le premier caractère, un deuxième sur les six suivants, et un autre encore sur le dernier. Le premier masque dit « majuscule, minuscule, chiffre », le deuxième dit « minuscule et chiffre », le troisième dit « minuscule chiffre et certains caractères spéciaux ».

Surprenant ? En fait non, avec un historique de fuites de mots de passe, de statistiques, et la présence de nombreuses politiques de mot de passes similaires présentes sur les formulaires web, on s’est rendu compte que ce format était le plus répandu. Il est donc souvent intéressant de le prendre comme choix par défaut. Oui mais voilà, ça veut dire qu’il ne teste pas toutes les possibilités. Mon petit mot de passe a une majuscule en plein milieu, et ça suffit à passer à travers ce masque !

J’ai retenté en forçant le même masque sur tous les caractères, qui est le premier sélectionné, et là, paf :

84de940c098f17f071c1307f135f42dd:TotoToto

Session..........: brut
Status...........: Cracked
Hash.Name........: MD5
Hash.Target......: 84de940c098f17f071c1307f135f42dd
Time.Started.....: Sun Apr 04 14:09:09 2021 (35 secs)
Time.Estimated...: Sun Apr 04 14:09:44 2021 (0 secs)
Guess.Mask.......: ?1?1?1?1?1?1?1?1 [8]
Guess.Charset....: -1 ?l?d?u, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 23263.4 MH/s (7.00ms) @ Accel:128 Loops:1024 Thr:64 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 829563863040/218340105584896 (0.38%)
Rejected.........: 0/829563863040 (0.00%)
Restore.Point....: 3440640/916132832 (0.38%)
Restore.Sub.#1...: Salt:0 Amplifier:57344-58368 Iteration:0-1024
Candidates.#1....: O8cdiqss -> 4mnMX3ll
Hardware.Mon.#1..: N/A

35 secondes pour le faire sauter, sachant qu’on connaissait les limitations, et que j’ai volontairement évité les mots de passe plus courts. Quand on vous dit que la taille compte quand il s’agit de mot de passe (j’en ai parlé y’a assez longtemps maintenant, mais l’idée est toujours d’actualité), et que certains militent pour des phrases de passe, ce n’est pas un hasard. Car l’impact sur les temps nécessaires pour les casser n’est pas linéaire, c’est donc très intéressant.

De l’importance du sel, et de ma confusion

Le sel est un minéral à la fois nécessaire et toxique pour le corps humain, c’est pour ça qu’on doit le consommer avec modération. Euh, je m’égare…

En informatique, un sel est le nom qu’on donne à un élément qu’on ajoute à une information avant de la chiffrer/hasher. L’idée, rendre l’information à encoder plus longue, et donc ralentir le travail des casseurs. C’est exactement ce qui se passe avec mon fameux mot de passe unix. Le format complet est le suivant :

$1$1Z6lMk9Q$T3XVqBcgF1fY9PlKlU9Oz0

Dans la pratique, cela veut dire qu’il y a un sel de sept caractères appliqué au mot de passe de huit. Sous Linux, chaque mot de passe a son propre hash qui est régénéré à chaque changement de mot de passe, ce qui élimine toute capacité de gain de temps lié à la récupération d’un seul d’entre eux. Ajoutez à ça que le md5 est en fait un md5crypt, soit un dérivé d’md5 avec donc d’autres opérations (je vous laisse le détail de l’algo ici, à lire au repos), et voilà, vous avez la raison de la différence de la performance par rapport à un md5 standard, et de mon interrogation sur les performances de ma bête.

Un sysadmin qui protège des mots de passe

D’ailleurs, le md5 n’est plus considéré comme un algorithme sur. Non seulement, les performances actuelles pour le brute-forcer le rendent faible, mais en plus, il a été prouvé mathématiquement puis par l’exemple qu’on pouvait générer le même hash à partir de deux contenus complètement différent. Alors que l’objectif de base était justement l’unicité des hash. Dans la pratique pour les mots de passe, ça veut dire qu’on peut trouver au moins deux mots de passe différents pour un même hash. Pas glop.

On m’a fait remarquer dans l’oreillette que le md5 n’était pas très reluisant sur un OS en 2021. C’est juste qu’on a repris le hash sur un ancien modèle de 2014, et de toute façon on le change lors de la phase de configuration de l’OS. Donc après, c’est du SHA512crypt qui est utilisé, pout tous les mots de passe générés/modifiés.

Le monde merveilleux du cassage de mot de passe

Mon expérimentation s’arrête ici. Ce qui est rigolo, c’est que ce billet a démarré deux semaines avant la parution dans le Journal du Hacker de cet autre article sur hashcat, qui présente grosso modo les options dont j’ai eu besoin pour arriver à mes fins, et comprendre les erreurs que j’ai faites ou rencontrées. Il y a aussi cet épisode du Comptoir Sécu sur les mots de passe avec un expert sur le sujet. Et pour le hardware porn, je vous laisse chercher « password cracking rig » sur un moteur de recherche d’images pour voir les machines de l’enfer !