Cli

Il y a fort longtemps (non) dans une vie lointaine (non) j’ai rédigé un tutoriel pour mes collègues (oui) afin que tous sachent comment chiffrer des supports de stockages et que les données sensibles de l’entreprise ne se baladent plus à la merci d’une clé USB perdue.

Ce texte était au départ dans un wiki interne. Mais vu qu’il a été rédigé sur mon temps libre, je le récupère pour le mettre ici.

Ce matin, un lapin, a voulu merger; C’était un lapin, qui jouait à git.

Je m’égare, je m’égare. Ce matin, un collègue chargé d’une revue de code a déclaré ne pas pouvoir vérifier le diff entre deux versions d’un fichier chiffré avec ansible-vault.

D’un côté, il a raison, ce n’est pas possible dans l’interface de gitlab. Pour se faire il faut nécéssairement avoir le mot-de-passe pour déchiffrer les versions avant et après modifications pour les comparer. De l’autre, localement, c’est tout à fait possible. Voici un petit script qui simplifie la vie dans ce cas de figure.

Clap est une bibliothèque permettant de gérer les arguments en ligne de commande pour les programmes écrits en rust.

Une bibliothèque supplémentaire, clap_complete permet de générer le code nécessaire à l’autocomplétion pour les interpréteurs comme bash ou zsh.

Cet article porte sur le peu de code nécessaire à le faire fonctionnner.

Au début, il suffisait d’un mot de passe, c’était simple : password. Puis, il a fallu le changer tous les six mois, qu’à cela ne tienne, password0, password1 et les suivants faisaient l’affaire. Mais après le mot de passe devait contenir au moins une majuscule, puis un chiffre, puis un ou plusieurs caractères spéciaux et sont apparus Password, Passw0rd et autres Pass/w0rd.

On le sait désormais, utiliser le même mot de passe pour des services différents et choisir des mots de passe faciles à mémoriser deviner sont de mauvaises pratiques. Mais trouver et se souvenir de trop nombreux mots de passe différents n’est pas aisé.

Et puis au fond, pourquoi s’embêter à les trouver? Autant les générer aléatoirement. Et tant qu’on y est, pourquoi s’embêter à les mémoriser? Un ordinateur fait ça tellement mieux que nous.

Je passe la majeure partie de mon temps de travail dans un terminal. Dans ce terminal, j’utilise l’interpréteur de commande bash. Et, bien que je trouve cela généralement plus intuitif que les clicodromes, il reste quelque recoins sombres que je continue à oublier. Cette page est un pense-bête pour le moi du futur qui ne désire plus rechercher encore et encore les solutions aux mêmes problèmes.

Cela va faire bientôt quinze ans que j’utilise des systèmes UNIX, que ce soit GNU/Linux ou Mac OS. Depuis tout ce temps, je me sers de la commande sudo pour bon nombre de tâches d’administration de mes machines. Ayant toujours été administrateur de mes propres machines, je n’ai jamais pris le temps de me pencher sur la gestion des droits en détail: C’moi l’patron, j’fais c’que j’veux.

Sauf que voilà, dans mon travail, j’administre des serveurs. Je les installe, les maintiens, les remplace. Plus récemment même, avec l’avènement du cloud ☁️ et de l’infrastructure as code, je les provisionne et programme leur (dé)commissionnement automatique. Je ne suis plus le patron, je ne fais plus ce que je veux.

Cet article est un pense-bête pour le moi du futur à propos de comment donner uniquement les droits nécessaires et suffisants à chaque groupe et utilisateur via la configuration de sudo.