Auto-hébergement, le retour

Au détour d’un coin de web, je suis tombé par hasard sur un article sur serveur410 demandant des retours d’expérience autour de l’auto-hébergement. L’article de synthèse ayant été publié quelques jours après que j’ai pris connaissance du premier et avant que j’aie eu le temps de commencer à écrire, j’en profite donc pour produire ici un article dédié au sujet et qui me permettra, par la même occasion, de faire un bilan de ses quelques années d’auto-hébergement. Entrons dans le vif du sujet.

Mon aventure de l’auto-hébergement commence en même temps que les prémices d’Unicoda, durant les rencontres mondiales du logiciel libre 2011 à Strasbourg. C’est à ce moment-là que, conférence après conférence, discussion après discussion, atelier après atelier, je prends la décision de me lancer dans l’aventure pour créer mon bout d’internet. Les motivations sont variées, mais le premier objectif est de disposer d’un espace de publication que je contrôle et où les données m’appartiennent. L’autre élément clé de l’histoire: ma soif d’apprendre. Après deux années de classes préparatoires, pendant lesquelles j’ai laissé de côté mon apprentissage de la programmation et mes expériences avec PHP et MySQL, commencés au lycée en autodidacte (l’option informatique en CPGE étant plutôt dédié à la résolution ou l’analyse de problèmes mathématiques avec l’outil informatique, que de la technique informatique), j’ai décidé de m’engager dans un cursus d’ingénieur en informatique, et enfin, plus simplement, le sujet m’intéresse et me passionne.

Il faudra néanmoins attendre début 2012, pour que je pose les premières pierres d’Unicoda. Achat du nom de domaine, location d’un serveur chez RedHerberg (association qui proposait à des formules d’hébergement très accessible financièrement pour débuter), installation et déploiement de WordPress, configuration d’un serveur web, modification de zone DNS, autant d’éléments à apprendre au fur et à mesure.

Dans les années qui suivront, Unicoda migrera vers OVH sur un serveur Kimsufi avec davantage de puissance et de mémoire. Ce serveur me permettra de continuer mes expérimentations: sous-domaines, installation d’Owncloud, mise en place de certificats HTTPS sur l’ensemble des domaines avec StartSSL et test de nombreux services pour construire ce que je désigne comme mon nuage de services auto-hébergés. De nombreux articles témoignent de ces essais et de cet apprentissage progressif et des évolutions de l’ensemble au fil des ans.

Avance rapide quelques années plus tard, je décide de pousser l’expérience plus loin et d’héberger l’ensemble des services chez moi, à l’exception d’Unicoda, qui reste comme service unique sur une machine virtuelle chez OVH, afin de garantir une certaine disponibilité de service et de disposer d’une généreuse bande passante (bien davantage que l’upload de ma connexion ADSL à ce moment là). Je recycle une machine assemblée pendant mes années de lycée et qui sans être très performante, permet de faire fonctionner convenablement les services que j’utilise.

Peu après, je m’intéresse à l’énergie consommée par cette machine et décide que 35 Watts minimum pour une machine majoritairement en mode idle est un peu trop élevé à mon goût (bien que ridicule par rapport à la consommation de mon PC fixe en utilisation). Je migre donc l’ensemble vers un Pi 3, ordinateur de poche consommant 4 à 5 Watts en mode idle, avec des pics de consommation mesurés à 7 Watts sur une période d’un mois. La facture d’électricité s’allège un peu. Je profite de la migration pour mettre en place un Pi 1 remplissant le rôle de passerelle et permettant de faire cohabiter les deux machines, le temps de migrer chaque service l’un après l’autre.

En parallèle, s’ajoute la mise en place d’une sauvegarde automatique, pour éviter d’effectuer le tout à la main périodiquement, d’abord avec duplicity vers hubic, puis duplicity vers Backblaze B2 et enfin, restic vers Backblaze, avec duplicity version allégé en complément de secours. Une fois la sauvegarde en place, j’ai pu me concentrer sur l’écriture de script de déploiement automatique pour être en mesure de redéployer l’ensemble de mes services rapidement et avec peu d’intervention humaine à partir de la sauvegarde journalière. Plus récemment, cette quête de stabilité a vu l’ajout d’un onduleur au système, pour parer aux éventuels problèmes d’alimentation électrique.

Il est clair que décider de s’auto-héberger, c’est faire le choix de passer plusieurs heures par semaines et parfois par jour, pour installer les services, puis les maintenir, les mettre à jour, les protéger et parfois investiguer les problèmes de fonctionnement. Est-ce que cela en vaut la peine… oui ! Et d’autant plus si vous exercez, ou voulez exercer un métier dans le domaine de l’informatique, ou simplement par intérêt ou passion pour le domaine. L’élément le plus chronophage restant la montée de version des services, surtout lorsque celle-ci est effectuée peu après la sortie de la mise à jour. Pour l’anecdote, j’ai en mémoire une soirée complète passée à mettre à jour Gitlab et déboguer la configuration, alors que le but principal était d’écrire quelques lignes de code sur l’un de mes programmes du moment.

En conclusion, il ne faut pas hésiter à se lancer dans l’aventure de l’auto-hébergement, à condition d’être conscient des enjeux et des responsabilités qui viennent avec. Faire simple, commencer petit et surtout disposer du temps et de l’envie d’apprendre !

Récupération de variables système sur Windows

Aujourd’hui j’ai installé Python et Django sur mon système Windows pour essayer de faire un petit site web rapidement, disons avant la fin de la journée.

Je commence donc ma configuration sur mon système Windows et en parallèle je fais la même chose en SSH sur une console MSYS2,une VM en mode console d’un système linux pour faire simple.

Sur windows je teste alors que sur la console MYSYS je suis connecté à mon serveur dédié de l’autre côté de la France mon serveur de production en quelque sorte.

Arrivé à l’étape d’installation de Django sur mon Windows, j’ai un message qui attire mon attention. Il semblerait qu’il manque un chemin dans PATH.

Pas de soucis. Touche Windows, j’écris « path » et j’appuie sur entrée. Je me retrouve sur les propriétés système.

Un clic de plus sur « Variables d’environnement… » et je me retrouve devant deux choix.

  • Variables utilisateur pour MonOrdinateur
  • Variables système

Dans les deux cas j’ai accès à une variable PATH que je peux modifier. Je ne me pose pas plus de questions et je modifie la variable Path dans variables système et y ajoute mon chemin.

Je valide tout, je suis content, tout va marcher et la commande

django-admin --version

devrait enfin m’afficher quelque chose à l’écran. Mais ce n’est pas le cas…

Je retourne dans les propriétés système et je commence vraiment à avoir peur. Plus aucuns chemins n’est accessible dans la liste PATH des variables système. Je pose la question à mon moteur de recherche qui m’indique qu’une restauration est le seul moyen de retrouver mes données perdues. Mais pour cela, il faut un point de restauration.

Je n’ai pas de point de restauration actif, la protection du système semble désactivée.

Je continue les recherches avec de moins en moins d’espoir de pouvoir redémarrer mon système dans de bonne condition. Pour ce qui ne le savent pas, les variables système dans PATH conditionnent beaucoup de chemins vers des exécutables utiles au bon fonctionnement de votre ordinateur.

Plus d’une heure passe, en désespoir de cause je récupère quelques PATH sur un autre ordinateur et un ami m’envoie les siens, mais je vois bien qu’il n’y a pas tous les chemins que j’avais avant de tout casser.

Quand mes recherches prennent un tournant inattendu. Je trouve enfin quelque chose d’intéressant. On peut exécuter la commande set pour lister et modifier les variables d’environnement et système propre à l’exécution d’un interpréteur de commande (CMD). D’ailleurs si on modifie des chemins dans l’interpréteur et qu’on le quitte, les chemins ajoutés ne sont pas sauvegardés. De la même manière si j’ai modifié les variables PATH par l’interface graphique sans relancer l’interpréteur celui-ci connait encore les anciennes valeurs de PATH.

J’ai un sursaut d’excitation. Est-ce que j’ai encore une CMD ouverte ?

Malheureursment non. Je n’ai plus aucune CMD ouvertes dans la barre des tâches. Par contre il y a toujours MYSYS ouvert avec une connexion SSH en cours vers mon serveur.

Se pourrait-il que j’avais la solution pour récupérer mes variables système PATH sous les yeux depuis le début ?

Après avoir mis fin à la connexion ssh avec le serveur. Le verdict. Je tape au hasard la commande Windows « SET » dans l’interpréteur MYSYS Linux. Un résultat ! Peut être que j’ai de la chance après tout ? Je fracasse la molette pour remonter rapidement tout en haut de la sortie affichée, quand enfin j’ai ce que je cherchais !

Toutes mes variables PATH gardées en mémoire par MSYS2. Avec pour seul inconvénient un typage Unix et non Windows. Dix minutes plus tard j’ai mes variables système PATH d’origine. Et en bonus, j’ai même compris mon erreur. J’aurais du mettre mon chemin dans les variables utilisateur et vérifier qu’il était bien écrit. En plus j’aurais pu tester que tout fonctionne en le faisant avec la commande set en console avant de faire la modification réel.

Conclusion

Si vous perdez toutes vos variables système ou variables utilisateur sur Windows vous pouvez les récupérer en dernier recours si il vous reste une console ouverte avant la réalisation des modifications qui ont détruits vos chemins. Pour les trouver il suffit de taper la commande « set » ou « path » dans cette console et de récupérer et mettre en forme les chemins, puis de les réinsérer par l’interface graphique dans PATH en vérifiant si ce sont des variables utilisateur ou système.

Pour la petite astuce, ne faites pas comme moi et pensez à faire des points de restauration système réguliers.

[Nextcloud] Mise à jour

En ce qui concerne la mise à jour de mon instance Nextcloud, fonctionnant sur un Pi 3, avec des performances acceptables, étant le seul utilisateur, je constate à l’usage qu’il est préférable de déclencher la mise à jour en passant par la ligne de commande.

Pour référence, une fois dans le dossier de Nextcloud, on exécutera la commande suivante pour déclencher l’intégralité de la procédure de mise à jour, comprenant, sauvegarde préalable, récupération de la nouvelle version, etc.

sudo -u www-data php updater/updater.phar

On pourra aussi utiliser l’option --no-interaction afin d’enchaîner toutes les étapes conduisant à la mise à jour sans demander la validation de l’utilisateur.

Référence : Upgrade via built-in updater

Restauration d’un dossier à partir de la sauvegarde avec duplicity

Pour une raison obscure, ma dernière tentative de mise à jour de Nextcloud a échoué et laissé le contenu du dossier dans un état instable. J’ai donc récupéré la dernière version stable depuis la sauvegarde de la veille.

sudo pip install --upgrade b2
sudo duplicity restore --force --file-to-restore path/to/nextcloud -t now b2://[applicationKeyId]:[application key]@[B2 bucket name] /path/to/nextcloud

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.