[Ansible] Liste des valeurs disponibles pour ansible_os_family

Petit pense-bête, pour éviter de perdre plusieurs dizaines de minutes à retrouver la liste des valeurs possibles pour la variable ansible_os_family dans ansible, après plusieurs semaines ou mois sans pratiquer.

La liste est par là:
ansible/ansible/module_utils/facts/system/distribution.py#L511

cmd#11 – GitHub – Clone de dépôt via HTTPS et token

De temps en temps, j’ai besoin de cloner l’un de mes dépôts GitHub, vers un poste de travail sur lequel je ne souhaite pas ou ne peut pas utiliser ma clef SSH pour réaliser l’opération. Dans ces cas là, je passe par la génération d’un token via Settings > Developer settings > Personal access tokens > Fined-grained tokens, auquel je ne n’assigne que l’autorisation « Content » avec « Read and Write », sur le dépôt concerné.

Avec une validité maximum d’un an, la sélection des dépôts concernés et une sélection minimale des permissions, je réduit ainsi grandement la surface d’exposition de mes dépôts. Une fois en possession du token généré, vient ensuite le moment de cloner le dépôt via git. Pour mémoire, voici la syntaxe à utiliser, par exemple, pour cloner mon dépôt yt-auto-dark:

git clone https://oauth2:<token>@github.com/vvision/yt-auto-dark.git

Voilà pour l’aide-mémoire.

Seul bémol de la solution, n’importe qui ayant accès au dépôt cloné pourra effectuer des modifications pendant toute la durée de validité du token, ou jusqu’à ce que ce dernier soit révoqué. A ne pas utiliser n’importe comment, n’importe où donc. En sacrifiant un peu de simplicité (et encore) et en fonction de l’environnement, on pourra préférer la génération d’une clef SSH spécifique à la machine, auquel on veillera bien à associer une pass phrase de qualité. On aura alors accès à tous nos dépôts, mais il faudra penser nous-même à retirer la clef des clefs autorisées lors de la décommission de la machine utilisée.

Bref, plusieurs solutions possibles en fonction des besoins et des environnements, à choisir en connaissance de cause.

Synapse – Mise à jour: Rust comme dépendance

Avec l’arrivée de la version v1.68.0 du serveur synapse, celui-ci vient désormais avec une dépendance vers Rust, qui doit donc être disponible sur le système en cas d’installation depuis les sources. La version de Rust demandée est une version récente, supérieure à la 1.58.1 si je me base sur la documentation de mise à jour.

Bien que n’utilisant pas le serveur synapse installé, je continue à le mettre à jour régulièrement pour suivre les avancées du projet, et avec l’espoir d’y faire migrer, un jour, mon cercle familial proche. Je ne pousse pas non plus à l’adoption pour le moment, car je souhaite d’abord m’occuper des procédures automatiques de déploiement et de sauvegarde.

Revenons à la mise à jour de synapse dans le cas d’une installation à partir des sources. Le point bloquant concerne l’installation de Rust pour que le programme soit correctement détecté lors de la mise à jour. Après quelques recherches, la solution consiste simplement à installer Rust pour l’utilisateur synapse, soit:

sudo su synapse
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Une fois l’installation effectuée, la mise à jour s’exécute sans erreur.

Réinstallation de mon environnement de gestion des mots de passe sous MacOS

Dans le cadre de mon emploi, j’ai pu procéder il y a peu à un changement de mon ordinateur car je commençais à m’approcher dangereusement des limites de ses capacités de stockage. Malgré une analyse du contenu du disque dur, difficile de trouver plus d’une dizaine de giga octets de place, même après nettoyage des anciennes versions de certains logiciels (versions restées sur le disque après mise à jour). Bref, qui dit changement de matériel, dit réinstallation de mon environnement de développement et une occasion à ne pas manquer de prendre quelques notes sur les étapes et autres réglages incontournables à ne pas oublier.

Avant de préciser les étapes d’installation, quelques mots sur la manière dont je gère mes mots de passe s’imposent.

Pour la gestion des mots de passe, j’utilise pass, petit utilitaire en ligne de commande, où chaque mot de passe est stocké dans un fichier chiffré sur le disque. La sauvegarde et la synchronisation sont réalisées via git. La clé de chiffrement est stockée sur un support externe de type « smartcard », une YubiKey en l’occurrence. Après maintenant trois ans d’utilisation quotidienne, le système a fait ses preuves et me convient parfaitement. Pour plus de détails, se référer aux articles de la catégorie Crypto autour de novembre 2018.

Récapitulons les éléments nécessaires:

  • gnupg.
  • pinentry, pour la saisie du mot passe protégeant la YubiKey.
  • Une YubiKey.
  • pass.
  • browserpass, pour une utilisation simplifiée dans les navigateurs.

Première étape, installer les briques logicielles nécessaires en utilisant brew.

brew install libyubikey yubikey-personalization gnupg pinentry pinentry-mac gpg-suite-pinentry pass amar1729/formulae/browserpass

Je n’entre pas dans les détails de l’étape intermédiaire de déploiement des fichiers de configuration de mon dossier dotfiles, celle-ci étant décrite dans l’article dotfiles, git et rcm. Mentionnons tout de même que ce déploiement permet la configuration de gnupg et de la variable d’environnement indiquant le chemin vers le dossier des mots de passe à pass.

Passons à la suite.

Lors de mes premiers tests, j’obtiens l’erreur suivante: gpg: WARNING: unsafe permissions on homedir '/home/path/to/user/.gnupg'. Problème de permission sur le répertoire de configuration .gnupg, une petite recherche concernant l’erreur, me donne un gist qui propose la solution ci-dessous:

chown -R $(whoami) ~/.gnupg/
# Set 600 for files
find ~/.gnupg -type f -exec chmod 600 {} \;
# Set 700 for directories
find ~/.gnupg -type d -exec chmod 700 {} \;

Je passe ensuite à la configuration de l’extension de navigateur browserpass sur les deux navigateurs que j’utilise: Firefox et Brave. Une fois l’extension installée, il faut déployer ce qui permettra à celle-ci de dialoguer en local avec pass. Ces commandes, ou une version similaire, sont rappelées à l’installation de browserpass via brew et je conseille vivement de faire une petite relecture du Readme du projet sur GitHub pour se remettre en tête la procédure.

PREFIX='/usr/local/opt/browserpass' make hosts-firefox-user -f '/usr/local/opt/browserpass/lib/browserpass/Makefile'

PREFIX='/usr/local/opt/browserpass' make hosts-brave-user -f '/usr/local/opt/browserpass/lib/browserpass/Makefile'

Je termine en configurant au niveau de l’extension le chemin vers le répertoire des mots de passe, celle-ci n’arrivant pas à utiliser la variable d’environnement dédiée et pourtant parfaitement accessible dans un terminal.

Je pensais en avoir terminé après cette opération, mais mes mots de passe restaient inaccessibles car pass ne parvenait pas à trouver les informations de clef nécessaires au déchiffrement. Après un test rapide de l’état de ma YubiKey avec gpg --card-status pour m’assurer que celle-ci était bien lisible et reconnue, je me suis souvenue qu’il me fallait importer ma clef publique. Après transfert du fichier la contenant, j’ai donc procédé à l’import via gpg --import < publickey.txt.

Nouveau test. C’est mieux, mais le programme se plaint de ne pas savoir quelle confiance accorder à la clef que je viens d’importer et limite donc grandement son utilisation. Pas de problème ! Accordons à cette clef une confiance absolue.

gpg --edit-keys <email_address> 
gpg> trust
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
gpg> quit

A l’issue de ces étapes de configuration, une nouvelle tentative d’accès à l’un de mes mots de passe se traduit cette fois par une récupération réussie de celui-ci.

La réinstallation de mon environnement de gestion des mots de passe sous MacOS s’est donc déroulée sans trop de difficulté et dans un temps plus que raisonnable, puisque je ne crois pas y avoir passé plus d’une heure. Il est toujours agréable de ne pas rencontrer trop d’erreurs en réinstallant et en reconfigurant ses outils, et de retrouver son environnement habituel propre, neuf et fonctionnel en peu de temps et sans avoir à y laisser un ou deux points de santé mentale.

Et un jour, qui sait, je disposerais peut-être enfin d’un script de réinstallation pour simplifier encore le processus.