Orgapy Blog

Auto-hébergement : initiation et pérégrinations

Étant pieux locuteur français, je m'efforce d'user de palabres approuvées par l'Académie française, en déplaise aux suppôts de la novlangue libérale.

L'auto-hébergement me permet de répondre à trois demandes, à savoir, mes préoccupations concernant mes données personnelles, ma curiosité technologique et le temps à perdre. Je synthétise ici mon expérience, résultat de deux ans d'essais et découvertes, à l'attention de nouveaux amateurs.

Matériel

Je fis mes premières armes sur des machines d'Amazon EC2, disposant de crédits pour ce faire. Cependant, ces solutions conviennent davantage à des professionnels, tant dans les moyens mis à disposition que dans les propositions commerciales. En outre, la recherche d'indépendance étant au cœur de ma démarche vers l'auto-hébergement, la dépendance à Amazon restait inconfortable. Je résiliai donc et cherchai autre chose.

La première pierre ajoutée à l'édifice fut une carte Raspberry Pi 3. La coquetterie accompagnera cet achat d'un boîtier muni d'un ventilateur. En ajoutant une carte mémoire de 64 Go, cet investissement me coûta 73,06 €.

Raspberry Pi avec un boîtier comporant un ventilateur

Une fois le colis arrivé, le premier objectif fut de pouvoir se connecter en SSH à la carte. La documentation officielle de la carte permet cela aisément. Par sécurité, il convient de modifier le nom d'utilisateur (pi par défaut), associé à un mot de passe robuste.

Rapidement, les premiers problèmes survinrent. En l'occurrence, il s'agit de la connexion à un serveur NTP / NTS, pour paramétrer automatiquement et précisément l'heure et la date de la carte. Le symptôme le plus critique était l'impossibilité d'établir des connexions sécurisées, le protocole SSL reposant sur des concordances temporelles. Trouver la solution se révéla être un défi de taille, qui se conclut par un contournement trouvé sur Stack Overflow :

sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

Une fois ces désagréments réglés, et quelques logiciels basiques installés, les choses sérieuses commencèrent.

Site Internet

Infrastructure serveur

Ma première page personnelle était hébergée statiquement sur un serveur de ByetHost (qui offrait en outre un accès à un serveur FTP personnel), puis sur le service Pages de GitHub. Aller plus loin nécessitait alors une architecture dynamique, que j'esquissai en PHP.

Assez vite le besoin d'une structure logicielle se fit sentir, tant pour la propreté du code que pour les performances et la sécurité. Je connaissais alors Laravel, basé sur PHP, mais préférai utiliser Django, basé sur Python. Django s'intègre aussi très facilement à un serveur Apache. La plupart des tutoriels disponibles proposent de configurer directement le fichier apache2.conf, mais il est possible d'inclure le serveur Django dans un VirtualHost. Les directives à renseigner sont les suivantes :

  • WSGIScriptAlias
  • WSGIDaemonProcess
  • WSGIProcessGroup

Outre l'élégance apportée, cela permet aussi de filtrer les requêtes ayant accès au serveur par nom de domaine et les port, ce qui permet la coexistence de plusieurs services.

Un dernier avantage de Django est sa modularité. Le serveur fonctionne comme un regroupement d'applications, qu'il est facile d'installer et de désinstaller.

Remarque : la migration vers Django 3.0.2 nécessite une version de Python supérieure à 3.6, or le module WSGI, qui permet la jonction entre Django et Apache, ne possède qu'un paquet pour Python 3.5 (libapache2-mod-wsgi-py3). La solution consiste à compiler manuellement WSGI, comme l'indiquent ces tutoriels :

Certification

La sécurisation du site via le protocole SSL nécessitait premièrement un nom de domaine. J'achetai donc chalier.fr sur Amazon Route 53. Deuxièmement, il me fallait des certificats signés par une autorité de confiance. SSL For Free propose ce service gratuitement et efficacement. Une fois signés, les certificats sont faciles à installer avec Apache, qui peut gérer directement la redirection HTTP vers HTTPS.

Routage

Là réside une part importante de l'auto-hébergement : la mise en disponibilité du serveur sur Internet. Ma carte était connectée au réseau local, mais indisponible depuis l'extérieur. Il fallait pour cela définir des règles de redirection de ports, via la fonction NAT de mon routeur. Mais je rencontrai deux problèmes.

Premièrement, l'attribution d'une adresse IP locale statique semblait dysfonctionnelle. Malgré mes nombreuses tentatives, il arrivait à ma Livebox Orange de changer arbitrairement l'adresse de ma carte Raspberry Pi sur le réseau local. Résoudre le problème nécessita un script Bash vérifiant périodiquement si l'adresse IP locale avait changé ; le cas échéant, une commande permet d'envoyer une requête pour demander de nouveau l'adresse précédente :

sudo ifconfig eth0 192.168.1.7 netmask 255.255.255.0

Deuxièmement, l'adresse IP publique de la Livebox était fréquemment modifiée par Orange, de sorte que le champ A du DNS ne pouvait pas suivre. Orange vend un service de DNS dynamique, mais il est possible de se débrouiller sans. Encore une fois, grâce à un script Bash vérifiant périodiquement si l'adresse IP publique avait changé ; le cas échéant, l'interface de ligne de commande AWS permet de mettre à jour manuellement le DNS.

Dans le futur, les seules modifications du système de routage seront les ports redirigés via NAT. Les sous-domaines de chalier.fr , renseignés dans le DNS comme entrées CNAME redirigeant vers l'entrée principale A du domaine Apex, suivront toutes les mises à jour automatiquement.

Communications

L'étape suivante fut l'implémentation de services de communications. Je fis une première tentative avec NodeJs (chrab sur GitHub), mais le résultat s'avéra manquer de fiabilité pour un usage autre que récréatif. Je me décidai donc d'installer des logiciels existants.

Sécurité

Assez rapidement, des premiers faisceaux de requêtes automatiques prirent le serveur pour cible. Ces robots cherchent les routes publiques laissées ouvertes par des utilisateurs imprudents, notamment en essayant les routes communes de WordPress. L'installation de Fail2ban permet de régler ce genre de problèmes. Aussi, il est recommandé d'effectuer des sauvegardes régulières des données du serveur, idéalement automatiquement, et de stocker ces sauvegardes sur un disque distant du serveur !

Courriels

Pour les courriels, je suivis un tutoriel de Sam Hobbs, accompagnant l'installation de Postfix (serveur SMTP) et Dovecot (serveur IMAP). Cette installation se révéla un peu difficile, principalement par l'impossibilité d'effectuer des tests contrôlés.

En outre, le port 25 n'est pas ouvrable chez Orange (contrairement aux autres FAI). Il est nécessaire de relayer son serveur SMTP au relais SMTP d'Orange. Si cela paraît compromettre la confidentialité des courriels, ces derniers ne sont pas protégés et auraient tout de même été surveillable par le FAI. La meilleure solution à ce problème est d'utiliser la norme OpenPGP.

Une fois les serveurs en place, se posa la question des clients à utiliser. J'optai pour Thunderbird (Windows et Linux) et K-9 Mail (Android). Le support d'OpenPGP nécessite l'extension Enigmail pour le premier et l'application OpenKeyChain pour le second.

L'installation de client en ligne tel que Roundcube est possible mais relativement lourde pour l'usage qui en est fait. Plus modestement, le module PHP php-imap permet d'effectuer des tâches basiques de gestion et d'affichages des messages, suffisant pour être utilisé en cas de secours.

Internet Chat Relay

Dans le milieu des communications plus informelles et rapides, le protocole IRC fait partie des plus légers et personnalisables. Cela détermina mon choix. Je suivis un nouveau tutoriel, ouvris quelques ports supplémentaires, et le tour était joué.

J'appris alors que le chat de Twitch utilisait lui-aussi le protocole IRC. Dans la lignée des Nighbot ou autres Moobot, l'envie me prit de développer un robot pour mon propre serveur. Le module irc pour Python fournit une interface relativement bas-niveau pour l'interaction avec le serveur IRC. Je l'incorporai donc dans un service Python dont le code est disponible sur GitHub (ircbot).

Services Google

Après la migration de ces services classiques pour l'auto-hébergement, je m'attelai à une tache peut-être moins commune. Les services de Google forment un écosystème monopolistique dont il est très difficile de se défaire, malgré le siphonnage flagrant de données qu'ils amènent. Mon objectif devint alors de me détacher au possible de ces services, pour favoriser des solutions libres de droit voire personnelles.

Agenda et Contacts

Afin de gérer la compatibilité avec un maximum de clients, il m'était nécessaire d'implémenter un protocole générique pour l'échange d'événements : CalDAV. La tâche étant de taille, j'optai pour une solution existante, Radicale. Implémentée en Python, elle gère les calendriers, les tâches, et les listes de contacts.

Keep

Pour la gestion de mes notes, je choisis de développer ma propre solution : Orgapy, sous la forme d'une application Django, facile donc à incorporer au site déjà existant. Le zèle me poussa à doter cette application de fonctionnalités plus avancées que pour la simple prise de notes, par exemple le balisage du texte en Markdown.

YouTube (et Twitch)

Pour ne plus dépendre de mon compte Google pour suivre mes abonnements YouTube, je développai une autre application Django : Notifpy.

Originellement, ce logiciel permettait d'être notifié lorsqu'une chaîne YouTube publiait une vidéo dont le titre satisfaisait un ensemble d'expressions régulières, ce qui permettait de filtrer le contenu de chaînes trop prolifiques, comme peuvent l'être les chaînes de revisionnage. Je l'adaptai donc pour en faire une application Django, et élargissais du même temps son champs d'utilisation.

Plus tard, j'ajoutai également la gestion des utilisateurs Twitch. L'application actuelle permet ainsi de consulter un flux d'abonnement comparable à celui d'un compte YouTube sans dépendre de la plateforme, et de même pour Twitch.

Bilan et poursuites

En l'état actuel de ma migration, je n'ai eu que peu de pannes à gérer, et souvent dues à des maladresses de ma part. L'expérience est très enrichissante, car elle permet de découvrir Internet comme ses pionniers l'ont imaginée, et d'en utiliser pleinement les capacités. La personnalisation complète de chaque élément intervenant dans le processus est une grande source de satisfaction. L'inconvénient majeur reste le temps à investir pour que ce projet aboutisse. Bien entendu, les choses peuvent être grandement accélérées en utilisant des services complets déjà développés, mais l'essence du projet en serait perdue.

Sur ce, ma route reste longue. Les composants actuels sont toujours améliorables, et d'autres viendront certainement s'y greffer. Par exemple :

  • un serveur Icecast, pour pouvoir diffuser des playlists musicales en continu ; quelques expériences m'ont montré cela possible mais nécessitant de plus de ressources,
  • un serveur GitLab, mais nécessitant aussi plus de ressources,
  • un serveur média, analogue à Plex.

Malheureusement, une simple carte Raspberry Pi ne possède pas les capacités nécessaires à ces derniers services. Par exemple, le simple hébergement de photos est difficile à gérer (j'utilise d'ailleurs Imgur). Un serveur NAS serait bien plus approprié pour ces besoins, mais représente un investissement bien plus conséquent. À voir, donc.


Yohan Chalier · Jan. 21, 2020