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

Carnet 1 – Fibre

Depuis maintenant un peu plus de 24h, je suis raccordé au réseau par une connexion fibre. Saluons ici l’efficacité du technicien qui a procédé au raccordement en moins d’une heure. Passons rapidement sur l’installation bancale de la partie réseau du logement que j’occupe, et qui oblige à dévisser le panneau pour accéder aux gaines alors qu’un montage correct à l’installation aurait permis de simplement dé-clipser le « panneau » réseau.

À noter également que les techniciens ne disposent plus de boîtiers fibres en réserve lors de leurs interventions, comme j’ai pu le lire sur un forum. Je n’ai donc pas encore réellement commencé à tester, à jouer avec le débit offert par cette nouvelle connexion, car la box fournie par l’opérateur traîne au niveau du tableau électrique. Tableau électrique qui doit rester ouvert dans l’attente du boîtier fibre que l’assistance dit m’envoyer sous 3 à 4 jours. Cet élément en ma possession, je serais alors en mesure de déplacer la box à l’emplacement de mon modem actuel et de reconnecter mon matériel en filaire.

En attendant, je me suis documenté sur la manière de se passer de la box de l’opérateur. Je n’ai pas choisi d’option TV et n’ai pas besoin de la ligne téléphonique fournie par l’opérateur, ce qui devrait simplifier les choses. A priori, mes diverses lectures m’indiquent que cela ne devrait pas poser de problème pour configurer mon routeur sous AdvancedTomato. À voir dans les prochains jours, une fois l’ONT réceptionné. Pour ceux qui s’interrogent, la box à remplacer est une livebox, donc bonjour configuration de vlan, priorité des vlans et options dhcp 70 et 90 !

Ce changement sera l’occasion de revoir l’organisation de mon LAN. Je pense notamment au recâblage complet, redistribution des branchements électriques sur les multiprises disponibles et configuration de vlan. L’occasion de dépoussiérer et d’enrichir certaines notions apprises pendant mes études. Ce serait peut-être aussi le moment d’investir dans une baie de brassage, de centraliser l’ensemble du réseau et du matériel en un point unique, et de disposer ainsi d’un câblage propre. Un onduleur serait également un ajout utile pour palier aux éventuelles coupures de courant et éteindre correctement et automatiquement les appareils en fonctionnement si la coupure se prolonge.

Si le changement de box s’effectue correctement, j’ai particulièrement hâte de tester les possibilités de connexion VPN vers mon LAN, qui permettrait d’envisager de nouveaux usages (connexion VPN permanente côté android, accès NAS, streaming musical, …). Par ailleurs, l’augmentation de mon débit montant (x1000 d’après un test en ligne) me permet d’envisager la sauvegarde de certaines données froides dans le cloud en un délai raisonnable.

En attendant, j’avais prévu aujourd’hui de migrer unicoda.com vers un nouveau vps, à l’aide d’un jeu d’instructions ansible écrit ces derniers jours, mais j’ai bêtement atteint la limite hebdomadaire du nombre de certificats générés via Let’s Encrypt lors de mes tests successifs. La migration est donc repoussée de quelques jours et je suis impatient de vérifier que restauration, programmation de la sauvegarde et certificat wildcard fonctionnent correctement !

Voilà qui clôt ce court « bilan » des occupations du moment, auxquelles s’ajoutent quelques courtes incursions dans le monde des ESP8266 et de l’électronique.

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.