De l’importance de la sauvegarde dans l’auto-hébergement

Le 29 au soir, mon Pi a fait une petite chute d’une vingtaine de centimètre lorsque le câble d’alimentation s’est pris dans l’un des pieds de ma chaise de bureau. J’ai d’abord cru que la chute avait été sans conséquences. Mais l’allumage d’une LED rouge fixe et l’extinction de la LED verte m’ont rapidement convaincu du contraire.

Après une tentative infructueuse de relancer le serveur, je retire la carte SD du Pi afin de l’examiner et constate une très légère pliure à sa surface. J’extrais la carte, l’insère dans un lecteur afin de vérifier son contenu. Pas de partitions détectées et montées automatiquement. C’est mauvais signe. Je teste un montage manuel, la réponse est sans appel : « mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/sdg, page de code ou programme auxiliaire manquant, ou autre erreur.« . Par ailleurs, la carte SD est particulièrement chaude au toucher lorsque je la retire du lecteur. Une seule conclusion s’impose, la carte SD est morte.

Je vérifie le contenu de mon fichier .hubic_credentials en local et demande l’état de la chaîne de sauvegarde :

duplicity collection-status cf+hubic://<container> 

Une sauvegarde complète date de la veille (28 janvier), je me lance dans une première récupération locale des données avec :

duplicity restore --force -t now cf+hubic://<container> data

Une fois en possession d’une nouvelle carte SD, j’ai donc réinstallé Raspbian pour pouvoir réinstaller mon serveur. A ce stade, j’ai la chance d’avoir passé plusieurs heures à écrire un script Ansible me permettant de déployer automatiquement mes différents services à partir de la sauvegarde effectuée par duplicity. Tout fonctionne plutôt bien, jusqu’à ce qu’on arrive à la récupération des fichiers sur hubic, où un nombre non négligeable de requête termine en erreur 404 et oblige à relancer le script jusqu’à obtenir une réponse. Pas vraiment de solution de ce côté-là à part changer d’endroit pour le stockage de la sauvegarde. Les requêtes en erreur finissant en général par répondre après un laps de temps aléatoire pouvant aller jusqu’à plusieurs jours. Bref, cette solution n’est pas satisfaisante du tout !

Après pas loin d’une dizaine d’heure de tentative, l’ensemble des fichiers nécessaires à duplicity est finalement disponible en local sur le système d’exploitation tout neuf. C’est le moment de tester les différents services. Wallabag et Shaarli fonctionne directement avec l’ensemble des données accessible. Ce n’est malheureusement pas le cas de Gitea, FreshRSS et Nextcloud.

Petit tour dans les logs de FreshRSS : « Access to database is denied« . J’arrête le service mysql, le redémarre et rafraîchis la page. Bingo ! L’interface s’affiche.

Pour Gitea, le problème se situe également du côté de la base de donnée et le ticket correspondant sur le projet est le numéro 2979 . Après connexion à la base, un simple

 set global innodb_large_prefix = `ON`; 

résous le problème. L’ensemble des données est présent. Pas de perte.

En ce qui concerne Nextcloud, le problème est à chercher du côté de la configuration de la sauvegarde. En effet, en y regardant de plus près, il semble que pour limiter la taille de la sauvegarde, je n’avais configuré que la sauvegarde du dossier data, au moment de la mise en place. En fait, après analyse, il s’avère que c’est bien pire, le dossier semble être présent dans la sauvegarde, mais pas son contenu. Étrange. Rien de catastrophique néanmoins, les données présentes sur mon instance Nextcloud sont toutes synchronisées soit sur mon ordinateur, soit sur mon téléphone, et par ailleurs, l’instance ne contient aucune donnée critique qui n’ait elle-même fait l’objet d’une sauvegarde sur un autre support.

Côté réinstallation, j’ai configuré Nextcloud pour utiliser la base existante réimportée à partir de la sauvegarde. Au passage, j’en ai profité pour faire la mise à jour vers la version 15. Les contacts, les calendriers et les tâches sont revenus à partir de la sauvegarde, j’ai perdu au passage l’enregistrement d’un événement, perte sans conséquence. La sauvegarde étant journalière, les pertes sont très limitées. Pour la partie fichier, c’est plus compliqué, puisque le dossier nextcloud du serveur n’est pas présent dans la sauvegarde. Les fichiers étant présent en totalité sur mon disque dur local, j’ai donc supprimé l’intégralité du contenu sur le serveur via l’interface web et j’ai forcé la synchronisation à partir du contenu local via le client Nextcloud.

Cette mésaventure m’a permis de tester ma procédure de sauvegarde et de déploiement automatisé du serveur et de ses services en conditions réelles. J’ai identifié quelques faiblesses, notamment du côté du système de stockage utilisé par duplicity, à savoir hubic et un problème de configuration du côté de la sauvegarde de Nextcloud. Au passage, pas de perte de données ou d’informations, ce qui est un point plus que positif. A cette occasion, j’en ai également profité pour mettre à jour certaines parties dépréciées de mon script Ansible. Des améliorations sont donc prévues, en particulier pour trouver une alternative correcte à hubic pour stocker les données de sauvegarde.

[Vidéo] Speed Skating Motivation

Lien vers la vidéo « Speed Skating Motivation ».

I don’t know what that dream is that you have. I don’t care how disappointing it might have been as you’ve been working toward that dream. But here is what I know, that that dream that you’re holding in your mind – that it’s possible.

See sometimes we can say I can do that, but what we can’t say, that it’s possible. That I can have my dream, as we run towards it, as we work on it days in and days out.

But people who are running towards their dreams, life has a special kind of meaning.

I was willing to take a chance, but most people won’t do that. Most of the people that you talk to, to try to bring them in the business. These are not risk takers. Most people have done all they’re ever going to do : they raise a family, they earn a living, and then they die.

You are going to incur a lot of disappointment, a lot of failure, a lot of pain. A lot of setbacks, a lot of defeat. But in the process of doing that, you will discover something about yourself that you don’t know right now. What you will realize is that you have greatness within you. That you are more powerful than you can ever begin to imagine. That you are greater than your circumstances.

The other thing is that most people, ladies and gentlemen, they get comfortable, they stop growing, they stop working on themselves, they stop stretching, they stop pushing themselves.

For you running towards that dream I applaud you for believing in yourself, because that what life is about. Stretching and challenging.

Looking for ways that you can begin to improve yourself.

Do it.
Your dream is possible.
Do it

People who are unstoppable and unreasonable.
People who are refusing to live life just as it is and who want more!

I believe that we are all connected as one people.

We will be able to work together, to struggle together, to stand up for freedom together.

Installer scdaemon sur un Pi déconnecté du réseau

Dans un article précédent décrivant la partie génération de clefs PGP et transfert sur YubiKey, j’avais évoqué qu’il était envisageable de réaliser le processus complet sur un ordinateur exclusivement réservé pour cet usage. Je me suis donc procuré un Raspberry Pi Zéro, afin de vérifier la validité de cette hypothèse.

Mes premiers tests ont néanmoins été quelque peu retardés, car il est nécessaire d’adjoindre au Pi un hub USB disposant d’une alimentation dédiée, afin de pouvoir connecter, et surtout utiliser les différents périphériques : clavier, YubiKey et support de sauvegarde.

Le principal point bloquant par rapport à la génération des clefs PGP testée la première fois, se situe du côté de l’absence dans le système du composant scdaemon. Sans lui, impossible de dialoguer avec la YubiKey et d’exporter les clefs. Passons donc aux étapes permettant son installation.

Dans un premier temps, et après avoir récupéré la dernière version de Raspbian, en étant particulièrement attentif à la vérification de l’image récupérée par comparaison des sommes de hachage, il faut également récupérer le paquet scdaemon. Une page du wiki debian nous indique par ailleurs, que la bonne architecture à choisir pour le Raspberry Pi Zéro est armel ou armhf, à priori.

Sur le site web du projet raspbian, je parviens par ailleurs à trouver la liste des paquets de la distribution disponible. Dans ce fichier, une recherche de la chaîne « Package: scdaemon », nous permet de déterminer le chemin (propriété filename) où trouver le paquet recherché dans l’arborescence du même site, à savoir ici :

pool/main/g/gnupg2/scdaemon_2.1.18-8~deb9u2_armhf.deb

Nous pouvons alors nous rendre sur la page suivante afin d’explorer les différents versions du paquet à notre disposition: https://archive.raspbian.org/raspbian/pool/main/g/gnupg2/. Une fois le paquet récupéré et le système installé sur la carte SD, on pourra alors monter le système de fichier présent sur la carte et déposer le .deb quelque part dans l’arborescence (par exemple, dans /home). On en profite également pour comparer la somme de hachage du paquet avec celle présente dans le fichier « Packages ». Il ne nous reste plus qu’à démarrer le système depuis le Pi et à exécuter la commande dpkg -i <paquet>.deb pour installer scdaemon.

À ce stade, nous disposons désormais d’un ordinateur ayant tous les pré-requis nécessaires à la génération et à l’exportation des clefs PGP sur la YubiKey. J’ai rencontré quelques difficultés lors des premières tentatives d’export vers la YubiKey, car cette dernière, bien que détectée, ne semblait pas disponible. Il semble que deux processus scdaemon étaient démarrés et j’ai donc pu résoudre mon problème avec un simple « killall scdaemon ». Autre point l’export devait être réalisé en mode root, l’option -E de sudo devient alors incontournable pour transmettre la variable d’environnement « GNUPGHOME ». Pas grand-chose à ajouter de plus, si ce n’est qu’il faut faire preuve de patience pour les opérations de génération des clefs, qui mettent plusieurs minutes à s’exécuter sur un Pi zéro.

Logs Android via adb

Avec le téléphone connecté en USB et le débogage activé, il est possible d’avoir accès aux logs du système en temps réel avec la commande adb logcat, à laquelle on pourra passer le paramètre -v color afin de disposer d’une coloration des logs par sévérité.

adb logcat -v color

Pour filtrer les résultats et n’afficher que les logs de certains services, on ajoutera la liste des services désirés en suivante la forme <nom-du-service>:<niveau-de-verbosité>. Ce qui nous donne par exemple, pour n’afficher que les logs des services NFC :

adb logcat -v color "NfcService:V NativeNfcTag:V *:S"

Ou encore, pour afficher toutes les erreurs :

adb logcat *:E

Qui nous donne :

10-21 22:26:53.699 25006 25006 E android.hardware.nfc@1.0-impl: hw_get_module nfc_nci failed: -2
10-21 22:26:53.699 25006 25006 E android.hardware.nfc@1.0-impl: Passthrough failed to load legacy HAL.
10-21 22:26:53.700 25006 25006 E android.hardware.nfc@1.0-service: Could not get passthrough implementation for android.hardware.nfc@1.0::INfc/default.

Ce qui laisse à penser que le NFC n’est pas prêt de fonctionner correctement avec ma YubiKey sur ma custom rom.

Pour toutes les autres options de la commande logcat, direction la documentation !