gpg et pinentry

J’ai réalisé une modification du paramètre pinentry-program du côté de mon fichier de configuration de l’agent gpg à savoir ~/.gnupg/pgp-agent.conf :

# Ancienne valeur :
# pinentry-program /usr/bin/pinentry-curses
# Nouvelle valeur :
pinentry-program /usr/bin/pinentry

Ceci a pour effet d’utiliser le pinentry par défaut, soit pinentry-gtk-2 dans mon cas. J’effectue ce changement, car pinentry-curses n’arrive pas à s’afficher correctement si le déclencheur n’est pas une application lancée dans un terminal. J’ai notamment rencontré des problèmes au démarrage de Webstorm, lorsque celui-ci lance des commandes git en arrière plan pour rechercher d’éventuelles nouveautés. Si un terminal était déjà ouvert, l’interface curses y apparaissait, mais impossible d’y saisir correctement le PIN. Problème similaire en testant passmenu: pas d’affichage de l’interface.

Une fois la modification de configuration effectuée, on redémarre notre agent :

gpg-connect-agent reloadagent /bye

Sauvegarde vers Backblaze B2 avec duplicity

Étant donné les difficultés rencontrées lors de la dernière restauration de mon serveur à partir des données sauvegardées dans hubic, mais également lors de la tentative de restauration précédente, je suis parti à la recherche d’un second lieu de sauvegarde. Après quelques recherches, je me suis décidé à essayer le service fournit par la société Backblaze, en particulier avec sa solution B2 Cloud Storage.

Parmi les points qui m’ont orienté ma décision, on notera :

  • la compatibilité avec duplicity, outil que j’utilise actuellement pour réaliser mes sauvegardes.
  • 10 GB de stockage gratuit
  • Pas de nécessité de saisir des informations de paiement pour pouvoir tester.
  • Un coût de stockage de 0,005$ par GB et par mois.

Du côté tarification, nous sommes proches de ce qu’on retrouve du côté d’Amazon Glacier qui propose une tarification à 0,004$ par Go/mois pour le choix des régions de stockage les moins chers. Si les offres Amazon peuvent également être intéressantes, mais l’utilisation avec duplicity n’est pas disponible en l’état. De plus, il semble que la difficulté se situe au minimum du côté de l’option verify qu’il faudrait désactiver car comptant comme une demande de restauration. Une autre difficulté se situe du côté de la restauration des fichiers à proprement parlé, étant donné le temps nécessaire à Glacier pour rendre les fichiers disponibles après leur sauvegarde. Bref, à tester, mais dans un autre contexte.

Passons à la configuration de duplicity pour B2. Une version de duplicity v0.7.12 ou plus récente est nécessaire. La vérification s’effectue avec :

duplicity --version

La version installée sur mes serveurs depuis les dépôts de Debian était trop ancienne, j’ai donc compilé le programme à partir des sources du projet disponible sur le site du projet. Après récupération du dossier compressé des sources, petit tour dans le README pour prendre connaissance des pré-requis et des instructions de compilation. On procède donc à l’installation des dépendances demandées :

sudo aptitude install python-dev librsync-dev intltool python-fastener

Passage ensuite à l’étape de compilation, après décompression des sources :

python setup.py build

Puis désinstallation de la version en provenance du gestionnaire de paquet et installation de la version compilée à l’instant.

sudo aptitude remove duplicity
sudo python setup.py install

Enfin, vérification de la version de duplicity installée et vérification de l’emplacement de l’exécutable.

duplicity --version
which duplicity

Après mon premier test de sauvegarde, j’ai noté que les composants suivants sont également nécessaires au bon fonctionnement de duplicity avec B2 :

pip install b2
pip install backports.functools_lru_cache

À ce stade, on peut passer à un premier test de sauvegarde vers la solution de stockage de Backblaze. La commande duplicity reste des plus classiques et prends la forme suivante :

duplicity ~ b2://[applicationKeyId]:[application key]@[B2 bucket name]

Attention, la clé d’application doit être sauvegardée dans un endroit sûr, au hasard, dans son gestionnaire de mot de passe préféré. En effet, une fois la fenêtre contenant la clé fermée, il n’est plus possible d’afficher la clé et une nouvelle clé devra être générée en cas de perte de la première.

Autre point, la documentation Backblaze est en partie erronée dans la structure de la commande duplicity proposée, puisque y est fait mention d’un paramètre account_id en lieu et place du paramètre applicationKeyId ci-dessus. C’est bien ce dernier paramètre qu’il faut choisir, car utiliser l’account_id ne conduira qu’à des erreurs d’autorisation et à de la frustration

Quelques lignes encore pour terminer cet article. Je dispose désormais d’une double sauvegarde de mes serveurs vers hubic et maintenant B2. Le volume de données sauvegardées n’excède pas, pour l’instant, la tranche gratuite du service. Par la suite, j’envisage de tester d’autres outils de sauvegarde en particulier Restic et Borg. En outre le coût relativement faible du stockage m’encourage à envisager la sauvegarde externe de données froides comme mes photos numériques et ma bibliothèque de musique. La réflexion suit son cours.

Formatage de code avec husky et prettier

Petit point rapide pour la mise en place d’un formatage automatique des portions de code modifiées au moment du commit (en environnement JS : Angular/Node).

Installation des dépendances :

npm install --save-dev husky prettier precise-commits

Configuration à ajouter dans package.json :

"husky": {
"hooks": {
"pre-commit": "precise-commits"
}
},

À noter que prettier n’arrive pas toujours à formater un extrait de fichier JSON, l’intérêt de precise-commits peut s’en voir grandement diminuer si le projet contient de nombreux fichiers JSON régulièrement modifiés.

Modification des informations d’auteur d’un commit

Après avoir récupéré l’ensemble de mes dépôts git avec repo, je souhaitais effectuer un peu de « nettoyage » dans mes informations d’auteur de commit afin de les harmoniser. Bien entendu, cette opération n’est pas du tout neutre puisqu’elle implique une réécriture de l’historique, et dans le cas d’un changement d’email, cela concerne chaque SHA-1 des commits de l’historique (car un commit contient le SHA-1 de son parent).

Intéressons-nous à la commande de changement des informations d’auteur à proprement parler. Celle-ci est extraite de la documentation de github (si besoin, en cas d’opération successive, ajouter l’option -f avant –env-filter):

$ git filter-branch --env-filter '

OLD_EMAIL="your-old-email@example.com"
CORRECT_NAME="Your Correct Name"
CORRECT_EMAIL="your-correct-email@example.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_AUTHOR_NAME="$CORRECT_NAME"
export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

Avant d’être en mesure de réécrire les commits, on commence par déterminer les informations existantes à l’aide de la commande suivante (que l’on pourra par ailleurs exécuter sur tous les dépôts avec repo forall -c <commande>) :

git log | grep Author: | sort | uniq

Une fois les changements terminés, on pousse ces derniers vers le serveur:

git push --force --tags origin 'refs/heads/*'

En cas de message du type :

erreur fatale: 'origin' does not appear to be a git repository

Il convient de vérifier le remote configuré avec git remote -v, soit dans mon cas :

github  ssh://git@github.com/vvision/eslint-config (fetch)
github ssh://git@github.com/vvision/eslint-config (push)

On remplace alors origin par github dans la commande git push et le tour est joué (configuration héritée de repo).

De cette manière, l’ensemble de mes dépôts dispose désormais des informations de contact nettoyées.