Sortie d'hibernation
Une mise en veille (un peu) longue
Une mise en veille (un peu) longue
Une conjoncture favorable me motive à tenter un auto-hébergement avancé :
Voici mon plan framasoftien pour participer, à mon humble niveau, à la décentralisation. Le XPS deviendra un simple gestionnaire de machines virtuelles dédiées à différents services. Le premier sera un serveur YunoHost, au coeur de la démarche de décentralisation.
Ce serveur hébergera des instances de plusieurs services en ligne :
Je ne compte pas ouvrir les inscriptions sur les instances sociales – je ne me sens pas l'âme d'un administrateur-modérateur. Tous les autres services anonymes seront eux bien accessibles, dans la limite des ressources réseaux disponibles.
Il est extrêmement facile de créer des machines virtuelles (VM) sur Linux. KVM est intégré au noyau, et le gestionnaire de VM souvent installé par défaut.
Une fois l'ISO de YunoHost récupéré, l'installation se fait sans douleur. L'interface d'administration est censée se trouver sur https://yunohost.local, mais pas dans mon cas : le gestionnaire de VM créé un sous-réseau. Je dois donc passer par l'IP pour afficher l'interface.
Par curiosité, je tente l'installation de Pleroma. A priori, ça fonctionne avec mon nom de domaine, même si je dois l'ajouter dans mon /etc/hosts pour cela – il faut que je change le mode réseau de la VM pour un mode bridge plutôt que NAT, à mon avis.
Mon compte Pleroma voit mon compte framapiaf \o/ La VM étant isolée, l'inverse n'est pas vrai, et la communication est perdue rapidement mais c'est prometteur.
Concernant XMPP : YunoHost installe automatiquement un serveur ! Je teste localement avec Gajim (un client XMPP pour linux) : ça marche \o/
Idem, je ne peux pas rejoindre de salon, mais c'est très certainement lié au caractère très local de ma configuration.
La première chose à faire est d'installer Fedora Server sur le XPS en faisant table rase du passé. Une fois l'installation terminée, j'ai accès à l'interface de gestion du serveur via Cockpit sur le réseau local. Une mise à jour des paquets et l'installation des outils de virtualisation est nécessaire avant de pouvoir installer l'application Machine qui offre une entrée Virtual Machines dans le menu principal.
Une petite bidouille nécessaire : éviter que la machine se mette en veille lorsqu'elle est fermée.
Les VM devront être sur le réseau local. Il faut configurer l'hôte de manière à proposer une interface réseau en mode Bridge
La première machine virtuelle installée sera donc YunoHost. Après la création de la VM, l'interface réseau choisie par défaut est le bridge, rien à faire donc de ce côté. Yunohost s'installe comme n'importe quel OS headless, l'interface de configuration est accessible par un navigateur sur une machine du réseau local. Contrairement à la documentation,
https://yunohost.local ne marche pas et je dois passer par l'IP que je trouve grâce à l'interface de configuration de la Freebox.
Ensuite, c'est la configuration du domaine :
Mais après la récupération de la clé d'API, j'obtiens :
Échec de l'enregistrement create AAAA/xxxx.org : list indices must be integers or slices, not str
Échec de l'enregistrement create CAA/xxxx.org : list indices must be integers or slices, not str
Et
Attente de la réponse du serveur
qui tourne en boucle sur [POST] /domains/xxx.org/dns/push?dry_run
Pourtant, dans ma configuration DNS Gandi, toutes les entrées de Yunohost apparaissent bien (sauf les deux entrées AAAA et CAA en erreurs évidemment).
Il n'y a que deux erreurs; je les crée à la main depuis l'interface de gestion de Gandi et c'est bon.
C'est la seule VM sur le réseau qui mérite d'être accessible depuis l'extérieur pour l'instant. J'active la DMZ de la Freebox de manière à rediriger tout le trafic entrant vers elle.
La génération d'un certificat avec letsencrypt passe sans soucis.
Yunohost est fonctionnel, et avec lui le catalogue d'application qui me happe. Résultat :
Je n'ai pas reçu le mail contenant le mot de passe initial de l'utilisateur root. Il s'agit sûrement d'un défaut de configuration au niveau Yunohost : en effet, je ne souhaite pas utiliser l'auto-hébergement des mails, mais je veux le même nom de domaine. Même si Peertube a son propre sous-domaine, l'envoi initial se fait sur xxx@domaine.tld et les journaux de service postfix et dovecot semble me dire que le mail a bien été envoyé et reçu, sans sortir de localhost après l'installation.
Je me connecte en SSH sur le serveur Yunohost et scrute le répertoire local du serveur de mail :
sudo ls /var/mail/xxx/new
Le dernier mail est bien celui contenant le mot de passe pour l'utilisateur root de Peertube !
En root sur Peertube, je configure le LDAP comme expliqué dans ce mail, puis je me connecte en tant que xxx (mon utilisateur principal Yunohost). L'utilisateur n'est pas connu. Je tente de le créer à la main : un utilisateur avec cet identifiant existe déjà !
Test rapide : je me connecte avec un autre utilisateur Yunohost qui n'est pas partie prenante dans l'installation.
Ça fonctionne. Il s'agit donc d'un conflit entre root et xxx, qui sont les mêmes utilisateurs Yunohost.
Je créé un utilisateur yunohost@ynh.domain.tld et j'en profite pour configurer le mail.
Je réinstalle Peertube avec cet utilisateur comme root, et c'est tout bon.
Peertube installe un service Prosody (serveur XMPP) pour le live chat, même si je ne l'utilise pas. Il entre en conflit avec Metronome, le serveur XMPP de Yunohost. À suivre.
Il faut que l'application soit dans les applications autorisées pour les visiteurs (Groupes et autorisations), sinon on a une page vide (à part les logos fork sur github et yunohost).
L'import de mes contacts framapiaf ne marchait pas. Le journal du service misskey de Yunohost indiquait
Blocked address : 127.0.0.1
Il y a effectivement une variable de configuration allowedPrivateNetworks qui permet d'autoriser localhost. Je le modifie en ligne de commande dans /var/www/misskey/.config/default.yml
Je redémarre le service misskey, et ça importe !
Je n'ai plus qu'à attendre que mes anciens contacts accepte ma demande de suivi et qu'elles et ils me suivent.
Il n'aura pas fallu longtemps pour mettre tout ça KO ! Et pas de mon fait : le switch optique sur lequel je suis connecté a subit un incident. Résultat : mon serveur Yunohost n'est plus accessible.
Dans l'idéal, il faudrait, je pense, une sorte de miroir qui prend le relais dans ces cas là. C'est beaucoup d'investissement pour pas grand chose. Au pire, je déplace le serveur ailleurs (rappel: c'est un XPS 13', donc très facile à transporter) et mets à jour le DNS chez mon fournisseur de nom de domaine.
Par contre, ça confirme que j'ai bien fait de garder mon Nextcloud sur un VPS externe. Si besoin, je me connecte en partage de connexion avec mon téléphone (ce que je fais pour publier ce billet)
Alors bien sûr, le web n'est pas mon métier, l'administration système non plus, donc il y en a qui vont bien rigoler. Soyez indulgent⋅es.
Mon instance Funkwhale est accessible depuis funkw.xxx.tld. Ce nom de domaine est défini par une entrée chez mon fournisseur de domaine. Donc... je ne peux pas accèder à ma musique en réseau local ! Il va me falloir me débrouiller pour que les connexions locales restent locales. À savoir : si je suis chez moi, la navigation vers funkw.xxx.tld me dirige directement vers 192.168.0.xx plutôt que <DNS> -> <fournisseur NDD> -> IP publique -> 192.168.0.xx.
Après une semaine d'auto-hébergement, je suis très satisfait. Les services supportés par Yunohost sont facilement déployés, même si il faut mettre un peu les mains dans le cambouis. Avec mes modestes connaissances, j'ai pu me dépatouiller seul donc je ne connais pas la réactivité de la communauté pour la résolution des problèmes – même si j'ai ma petite idée : j'ai eu quelques mentions en peu de temps sur le fediverse !
Funkwhale remplace maintenant totalement Kodi pour la musique, avec le gros avantage d'être accessible partout (sauf quand Free est cassé !).
Nextcloud et Pelican sont sur un bateau. Le https de Pelican tombe à l'eau, qui l'a poussé ?
J'ai un VPS chez Hetzner et mon nom de domaine chez Gandi. Par confort d'utilisation, c'est une Fedora qui tourne sur le VPS. Après plusieurs années d'utilisation d'une instance Nextcloud sur un Simple Hosting Gandi, j'ai voulu passer au niveau supérieur et gérer un serveur intégralement. La migration s'est plutôt bien passée : j'ai maintenant une instance Nextcloud sur mon VPS et j'y ai retrouvé toutes mes données[^1]. Le serveur http est Apache, encore une fois pour confort personnel.
J'ai directement configuré Nextcloud pour être servi via https en utilisant les outils recommandés dans la documentation de Nextcloud, en particulier certbot pour générer un certificat Let's encrypt.
Sans mettre les mains dans le cambouis, j'ai une configuration qui semble opérationnelle. Une redirection permanente permet, en bonus, de servir uniquement du https quand le navigateur pointe vers http.
Ce modeste blog vous est généré grâce à Pelican (cf À propos). Il s'agit donc d'un site statique, tout ce qu'il y a de plus basique à gérer pour un serveur Apache. Aucun inconvénient à ce qu'il cohabite sur le même serveur que Nextcloud, d'autant que je voulais justement faire interagir les deux[^2]. Je me retrouve alors avec deux racines de site :
/var/www/html/nextcloud/var/www/html/pelicanJ'ajoute un fichier de configuration pour le site .../pelican en me basant sur /etc/httpd/conf.d/nextcloud.conf mais en gardant uniquement ce que je connais : la configuration de Nextcloud a été plutôt transparente, et je ne maitrise pas les sections concernant les réécriture d'URL et les proxy. Tout au plus, je sais que je n'en ai pas besoin pour un site de simple facture. Ce qui donne :
<VirtualHost *:80>
DocumentRoot /var/www/html/pelican/
ServerName djelly.calut.fr
Redirect permanent / https://djelly.calut.fr/
<Directory /var/www/html/pelican/>
Require all granted
AllowOverride All
Options FollowSymLinks MultiViews
</Directory>
</VirtualHost>
J'ai alors dans mes fichiers de configuration http un pelican.conf (ci0-dessus) et un nextcloud.conf qui ressemble à celui-ci, mais pointant vers le DocumentRoot correct et un sous-domaine différent de djelly. Nul doute que les yeux avertis auront déjà repéré une bévue, mais ce n'est pas mon cas.
Après redémarrage du serveur apache sudo service httpd restart, la partie nextcloud est toujours fonctionnelle : http://... renvoie bien vers https://..., et les différentes synchronisations en place (contact sur Android, calendrier, fichiers en local) sont toujours actives.
Par contre, http://djelly.calut.fr redirige bien vers https://djelly.calut.fr, mais c'est le index.php de Nextcloud qui est affiché[^3] !
À noter que la navigation sur le site nextcloud à partir de ce sous-domaine est impossible :
Accès à partir d'un domaine non approuvé
Veuillez contacter votre administrateur. Si vous êtes un administrateur, éditez la variable “trusted_domains” dans le fichier config/config.php comme l'exemple dans le fichier config/config.sample.php.
Vous trouverez d'autres informations sur la configuration dans la documentation .
Je renomme nextcloud.conf en nextcloud.conf.old puis redémarre le service httpd (de cette manière, il ne prendra pas en compte la configuration nextcloud).
J'avais dans l'idée que http://xxx.calut.fr ne serait plus accessible. Que nenni ! Il renvoie vers toujours vers https://djelly.calut.fr/index.php
Donc de nouveau un fichier appartenant au DocumentRoot de nextcloud, mais avec le sous-domaine de ce site (djelly). Bien sûr, je parle de Pelican, mais il n'y est pour rien. D'ailleurs, il n'est même pas installé sur le VPS. Il ne fait que générer localement les fichiers html. Le problème se situe au niveau de la configuration Apache, j'en suis convaincu.
J'ai noté que les VirtualHostnextcloud et pelican sont définis pour le port 80... Mais où est donc 443, le port utilisé pour servir https ? Le répertoire /etc/httpd/conf.d contient un ssl.conf. Il ne fallait pas chercher bien loin ! On trouve assez rapidement :
<VirtualHost _default_:443>
# General setup for the virtual host, inherited from global configuration
DocumentRoot "/var/www/html/nextcloud"
ServerName xxx.calut.fr:443
...
Qu'est-ce que _default_:443 comparé à *:80 ? “RTFM!”[^3] ! Où l'on apprend que “La chaîne _default_, dont la signification est identique à celle du caractère * [...]“.
Rien à voir de ce côté là, donc. Mais par contre, je n'ai aucun VirtualHost pour un ServerName djelly.calut.fr:443... et pourquoi le sous-domaine djelly renvoie sur le VirtualHost nextcloud ?
Je supprime la ligne Redirect permanent / https://djelly.calut.fr/> de pelican.conf, et on commence à retrouver quelque chose de normal :
http://djelly.calut.fr sert bien ce site, en http donchttps://xxx.calut.fr est bien mon instance nextcloudMais !
– https://djelly.calut.fr sert toujours le index.php de nextcloud
– http://xxx.calut.fr sert le index.html de ce site!!
Je reste dubitatif : si le <VirtualHost *:80> n'existe pas pour ServerName xxx.calut.fr, pourquoi est-il quand même interprété comme DocumentRoot ".../pelican" ?
En testant avec un sous-domaine inexistant, j'ai bien une erreur de mon navigateur qui ne trouve pas le site.
Je pense, tout candide que je suis, que ma configuration DNS entre en jeu ici. J'ai :
A pour xxx qui renvoie vers l'IP de mon VPSA pour djelly qui renvoie vers l'IP de mon VPSyyyPetite analyse :
yyy.calut.fr : normal, le navigateur ne sait pas où aller chercher les fichiers/var/www/html/pelican/var/www/html/nextcloudOn dirait que le VirtualHost de djelly écrase celui de nextcloud...
Tout ça pour ça : en plus de ServerName, il faut aussi ServerAlias...
Je récupère un certificat let's encrypt pour djelly.calut.fr et sépare le fichier ssl.conf en 3 fichiers différents :
ssl.conf garde la configuration globale du SSL de ce serveur apachessl-nextcloud.conf déclare le VirtualHost pour nextcloudssl-pelican.conf déclare le VirtualHost pour ce site, en modifiant simplement les références à nextcloud et xxx pour correspondre à djelly.Je réactive la redirection permanente pour pelican.conf, redémarre httpd, et tout fonctionne à merveille.
Ce n'était pas si compliqué. Mais je ne sais toujours pas pourquoi ServerName ne suffit pas.
[^1]: Je ne suis pas passé par la migration de base de donnée documentée. J'ai simplement synchronisé mes comptes localement, installer le nouveau Nextcloud, et resynchronisé en changeant le nom du serveur. [^2]: Voir le billet Le choix d'un moteur de blog [^3]: Read The Fantastic/Funny/... Manual