Matériel

Toujours le vieux XPS de 2015 derrière la Freebox. Rien n'a vraiment changé finalement. On peut dire qu'il est amorti !

Logiciel

La base n'a pas changé non plus (à part les versions bien sûr) : Fedora Server sur le XPS – que j'administre à partir de l'interface web Cockpit –, qui gère une machine virtuelle #Yunohost.

Ce Yunohost gère quant à lui deux domaines, le perso calut.fr et un autre pro, avec les e-mails bien sûr.

Blog

J'ai laissé tombé Pelican pour WriteFreely. J'aimais beaucoup le côté statique de Pelican, et ma bidouille pour le faire marcher avec Nextcloud était presque pas trop mal. Mais force est de constater que je ne m'en suis pas servi !

Avec #WriteFreely, je me dis que la diffusion sur le fediverse me motivera un peu plus. J'ai rapatrié mes posts #Pelican (il y a une fonction d'import, pas trop d'effort à fournir), l'interface est ultra-sobre... On verra !

Microblog

Plus ça allait, et plus mon instance #Misskey me faisait soucis. Le “Drive” intégré ne me permettait plus de télécharger des fichiers, plus de photos à partager donc, plus d'image de profil, et la documentation est peu instructive tout comme les fils des tickets github.

Après tergiversations et scrutation du catalogue yunohost, j'ai décidé de migrer vers une instance #mastodon. @djelouze@social.calut.fr est donc devenu @djelouze@mstdn.calut.fr, parce que je n'ai pas trouvé le moyen de conservé le sous-domaine social.

La migration n'a pas été compliquée, à part quelques bidouillages côté misskey pour l'export des abonnements. J'y reviendrai dans un autre post je pense.

Cloud

#Nextcloud est toujours en service, c'est la plus vieille application de mon yunohost et je lui ai adjoint #Collabora pour de l'édition WYSIWYG.

Gestionnaire de mot de passe

Je suis en train de passer de KeepassXC (que j'utilisais sur mes différents terminzux grâce à nextcloud) à Vaultwarden, un fork de Bitwarden. Le but est de proposer le service à une personne que je ne vois pas gérer des synchronisations nextcloud.

En vrac

• Dépôt de code : #Forgejo est très mieux, j'en ai deux, mais je les utilise peu
• Funkwhale, toujours là, je n'utilise pas la fédération pour l'instant
• Calibre-web pour partager mes livres avec mes collègues
• Dolibarr pour la gestion de ma petite entreprise
• SoGo pour que le fiston puisse aller voir ses mails de partout
• Kresus pour la gestion des finances quotidiennes
• Et plein d'autres que je teste !

Ceci n'est pas un billet technique

Ou pas que. La sortie d'hibernation concerne uniquement ce blog, qui n'a pas eu de nouveau billet depuis 2 ans. Et il s'en est passé, des choses, depuis...

(À commencer par ma reprise d'étude, que j'espérais raconter depuis la décision en 2021!)

Évolution de mon auto-hébergement

Donc voyons voir. À l'époque, je me lançais dans l'auto-hébergement. Une machine à la maison (XPS de 2015) derrière une freebox pour différents services ludiques, un VPS chez hetzner pour un nextcloud familial et un nom de domaine chez gandi qui gérait également mes mails.

Le XPS est sur une Fedora server pour gérer quelques machines virtuelles, dont une Yunohost – et c'est la seule, finalement !

Yunohost a fait largement ses preuves depuis, et je ne l'ai pas épargné : installation d'applications en tout genre “pour voir”, désinstallation évidemment parce que “en fait je m'en sers pas”, serveur minetest pour l'ado qui finalement préfère fortnite sur switch, mon instance Misskey qui me relie au fédivers,...

La première grande évolution a été de laisser Yunohost gérer mes mails perso, Gandi ne devenant plus qu'un fournisseur de nom de domaine. Ça fait maintenant plus d'un an que c'est le cas. Je n'ai pas souvenir de problème de configuration, éventuellement quelques passages en spam chez quelques destinataires, mais rien d'alarmant.

La deuxième évolution importante : rapatrier mon nextcloud (et accessoirement un serveur Calibre et ce blog) à la maison pour fermer le VPS et faire quelques économies. Encore une fois, Yunohost gère très bien Nextcloud, Pelican et Calibre-web donc à part le temps de transfert des données ça n'a pas été très difficile[1]. J'ai juste fait attention avec les enregistrements DNS, les IP ayant changé ! Et justement...

Dernière évolution : le passage de Gandi à Infomaniak pour le nom de domaine. Là, j'ai perdu un peu de confort, car Yunohost gére automatiquement les enregistrements DNS avec Gandi. Ce n'est pas le cas (pour l'instant ?) avec Infomaniak. J'ai commencé par exporter les enregistrements Gandi, effectuer le transfert vers infomaniak, puis mettre à jour quelques enregistrements. Et voilà (en anglais dans le texte).

Aujourd'hui

Pour résumer, tout est chez moi sur un PC de 10 ans d'âge. Le serveur Fedora avec son interface Cockpit ne gère qu'une seule VM Yunohost, aussi je me tâte à tout simplement installer Yunohost directement sur la machine. Mais je dois avouer que pour les sauvegardes, faire un petit snapshot de la VM de temps en temps, c'est facile quand même 😅

Le passage à Yunohost 12 a quand même fait une victime collatérale : mon instance Funkwhale[^2], que j'appréciais pour écouter mes musiques ailleurs que chez moi. Je n'ai pas le temps de m'occuper de ça, et heureusement mon audiothèque est intacte. Pour l'instant, je laisse Nextcloud me proposer son player mais j'aimais bien le côté fédéré de funkwhale.

Depuis mes migrations récentes, Yunohost gère aussi mon nom de domaine pro, ses mails, son nextcloud et son dolibarr. Encore une fois, rien à redire. J'ai remplacé Gitea par Forgejo, sans avoir eu l'occasion de tester.

Pour ce blog, j'ai tâtonné concernant les droits d'accès des fichiers de façon à pouvoir synchroniser les fichiers “sources” de Pelican avec Nextcloud. C'est chose faite : j'édite les billets en markdown sur ma machine (j'ai installé et découvre Apostrophe[^3] qui est très bien) ou directement dans le navigateur depuis mon nextcloud. Quand je sauvegarde, les fichiers HTML du blog sont générés automatiquement. J'aurais voulu passer à WriteFreely pour la fédération, mais une erreur m'empêche de l'installer sur Yunohost.

Plus tard...

La prochaine étape serait de migrer mon Misskey (ma porte d'entrée vers le fedivers) vers une instance Pleroma, mais l'application n'est plus disponible sur Yunohost. J'ai été déçu par une mise à jour récente, qui m'a imposé des fonctionnalités de gamification qui ne m'intéressent pas. Mais je n'ai pas le courage/temps/argent d'installer un autre serveur.

Dorénavant ce serveur auto-hébergé qui tourne comme une horloge va servir surtout à soutenir ma reprise d'étude. Je tenterai donc quelques expériences qui lient médecine, cours, et informatique (serveur d'image médicale, différents projets autour de Anki pour la préparation du concours EDN,...)

[1]: Je ne me suis pas lancé dans une migration de serveur : sur le VPS, l'installation avait été faite “à la main”, et je préfère laisser Yunohost gérer la configuration à la maison. Donc transfert “à l'ancienne” du répertoire nextcloud-data et resynchronisation finale. [^2]: C'est un problème connu, et la solution est... d'attendre :) [^3]: Dépôt gnome d'Apostrophe

#selfHosting #yunohost #nextcloud #pelican

Contexte

Un Galaxy A5 (2016 ou A510F) en bout de course, c'est dommage. Plus de mise à jour d'Android, et pourtant une mémoire saturée en tout point, une batterie qui tient à peine une journée... Il fallait faire quelque-chose.

J'ai déjà installé LineageOS sur mon One Plus en mode extrémiste (aka pas de Google Service). L'utilisation prévue de ce A5 est un peu différente, et je ne peux pas imposer un no-google absolu.

Je suis depuis longtemps (le début ?) les avancées de /e/ OS, et il me semble que le compromis est tout à fait acceptable. Le A5 2016 est supporté et on a accès aux applis du Play Store en mode anonyme. Bref, je tente.

(Presque) pas de mauvaises surprises

La documentation proposée sur le site de la fondation /e/ est complète, claire et suffisante. À suivre donc, pas à pas. Dans mon cas cependant, j'ai dû bidouiller un peu :

• Le recovery TWRP ne se chargeait pas avec heimdall. Il m'a fallu changer les droits de l'image pour autoriser l'execution (+x)
• La grande frayeur : au redémarrage après le chargement du custome recovery, logo, puis écran noir ! Aurais-je “briqué” la bête ?? Seul le mode download était accessible avec un comportement de reboot plutôt lunatique... Je suis allé récupérer l'avant-dernière version de TWRP pour cet appareil, et j'ai retrouvé un boot recovery fonctionnel. Ouf.

Une prise en main agréable

La suite de l'installation s'est faite sans encombre, /e/OS démarre et me propose les configurations initiales classiques sans création de comptes bidons, de CLUF intempestifs et autres joyeusetés.

“ça juste marche”.

Premier réflexe : installation de nextcloud. Le store d'application peut être configuré pour ne montrer que les apps libres. Sinon, une connexion en mode anonyme sur le Play Store permet d'installer des apps moins propres si besoin. J'installe Davx5 (agenda, contacts synchronisé avec Nextcloud), KeepassDX (gestion de mot de passe, la base de donnée est synchronisée sur Nextcloud), je configure les mails.

re “ça juste marche”.

Nickel. La batterie a perdu moins de 10% en une journée.

#Android #Samsung #eos #recovery #twrp

Une conjoncture favorable me motive à tenter un auto-hébergement avancé :

• L'écran de mon Dell XPS de 2015 donne des signes de faiblesse, mais reste une configuration honorable (i7, 16G RAM, 500Go SSD)
• Le macbook de la même année revit grâce à une Fedora 35, il devient mon ordinateur quotidien (voir ce billet)
• J'ai le temps

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 :

• Misskey ou Pleroma, en remplacement de Mastodon et ainsi décharger Framasoft de mon compte framapiaf
• Peertube, pour voir
• Funkwhale, pour voir
• EtherPad, EtherCalc, pour la collaboration dans différentes assos
• Serveur XMPP, pour montrer d'autres solutions de messagerie instantanée autour de moi
• ... et en fonction des besoins, on verra bien.

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.

Test local

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.

Grandeur nature

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.

Bridge

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

Yunohost

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 :

• je désactive les mails entrants/sortants et garde XMPP
• je lance la configuration DNS. Heureusement je suis chez [Gandi] et tout cela semble automatisé !

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.

La foire aux services

Yunohost est fonctionnel, et avec lui le catalogue d'application qui me happe. Résultat :

• Pleroma ne fonctionne pas sur ma configuration, erreur à l'installation
• Misskey s'installe correctement, mais j'ai tâtonné pour créer le premier utilisateur.
• Etherpad, easy peazy
• Funkwhale, easy peazy. Le système de fédération reste obscur pour moi, mais je vais creuser ça
• Excalidraw s'installe correctement mais reste bloqué sur Loading scene lors d'une visite sur la page
• Peertube s'installe proprement, mais le LDAP et l'envoi de mail ne fonctionne pas

Bidouilles

Peertube

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.

Misskey

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.

Premiers soucis !

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.

Redondance

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)

Ma musiiiiiiiique !

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.

Conclusion

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é !).

#selfHosting #yunohost #misskey #peertube #funkwhale

Sous fedora 35, le groupe PAM est audio.

Reboot plutôt que juste fermer/rouvrir la session

sudo dnf install a2jmidid qjackctl raysession midisport-firmware sooperlooper guitarix ardour6 hydrogen musescore calf

Problèmes de latence Jack/Pipewire

Solution Leodagan (“Tout cramer pour repartir sur des bases saines”)

sudo dnf --allowerasing install jack-audio-connection-kit

Problème : plus de son sur les haut-parleurs via jack.

Solution

• Editer le fichier /usr/share/pipewire/jack.conf
• changer #node.latency = 1024/48000 en node.latency = 256/48000

#fedora #mao

Mon matériel informatique commence à dater un peu :

• Dell XPS 13 de 2015
• Macbook Pro 13 de 2015 également

Il ne m'a pourtant jamais fait défaut. Le Dell héberge un Windows, utilisé uniquement dans mon ancien cadre professionnel (finalement assez peu) et une Fedora, ma distribution préférée depuis bientôt 20 ans. Le MacBook a subi ses mises à jour régulièrement jusqu'à Mojave (MacOS 10.14).

Hélas, le Dell fatigue physiquement : scintillement d'écran dès le démarrage, donc pas lié au système d'exploitation, batterie complétement rincée (5 min d'autonomie) et impossible de la trouver en pièce détachée.

Je me décide donc à faire valser tout ça : le Dell gérera le centre multimédia familial et j'installerai Fedora sur le Mac. Je vais suivre la démarche d'Eric Schabell

Préparation des ressources

Je voulais rester sur le Mac. Je récupère le Fedora Media Writer sur le site Fedora pour la bonne plateforme. Première déconvenue : il me faut un MacOS 10.15 pour installer le package, alors que je suis sur 10.14. Contraint, je lance la mise à jour proposée vers Monterey.

Une fois la mise à jour terminée, j'execute le Fedora Media Writer et suis les instructions. Le téléchargement de Fedora 35 à proprement parler commence.

Une fois téléchargé, l'utilitaire copie l'image sur la clé sélectionnée. C'est à la fin de la copie que j'ai le message “Ce disque n'est pas lisible par le système”. Merci ! Quand je relance l'utilitaire, j'ai pourtant un message “Vous avez inséré xxx qui contient un système live”. Dans le doute, je contenu la procédure : reboot en appuyant sur “alt”. Et ma clé n'apparait pas dans la liste...

Je tente de refaire une clé avec BalenaEtcher, un utilitaire de flashage.

• Je formate la clé pour Mac –> elle est détectée par le système
• J’exécute balena en choisissant l'iso de Fedora Live (téléchargé par Fedora Media Writer )
• “Flash Complete! 1 Successful Target”. C'est de bonne augure ?
• Hé bien non : une pop-up système apparait en même temps : “Le disque que vous avez connecté n'est pas lisible par cet ordinateur”

Idem, dans le doute je redémarre la machine, et cette fois la clé est visible dans le menu de boot. C'est parti pour l'installation de Fedora !

Installation

Petite entorse à ma règle, j'accepte l'utilisation de dépôts tiers. Mon peu de connaissances du matériel Apple me pousse à éventuellement installer des pilotes propriétaires, si besoin.

Pour le reste, c'est une installation de Fedora tout ce qu'il a de plus classique et ce n'est pas le sujet ici !

Dès que j'ai un environnement opérationnel, je lance

$> sudo dnf update

Le wifi cafouille un peu, je dois déconnecter/reconnecter pour avoir une connexion stable. Ce ne sera plus le cas pour le reste de l'installation.

Le double écran marche sans réglage particulier. Après l'installation du client Nextcloud et une synchronisation sans douleur, je passe sur le mac pour continuer la rédaction de ce billet.

C'est donc une Fedora tout à fait opérationnelle que j'ai le plaisir de voir s'égayer sur mon écran retina. La webcam n'est cependant pas reconnue nativement, mais je ne l'utilise pas.

Par contre, je n'ai pas de son ! Et ça c'est plus embêtant. Une fois ce problème réglé, il me restera à voir si les périphériques audio sont bien gérés : clavier MIDI/USB et interface 6 entrées/sorties USB. Je n'ai pas d'USB-C, mais deux connecteurs Thunderbolt 2 et 2 connecteurs USB.

Épilogue

Voici deux semaines que j'utilise ce macbook comme ordinateur principal. J'ai acheté un hub USB3 qui étend le nombre de ports à 3 USB et un ethernet.

L'environnement audio fonctionne correctement (un billet est en préparation, mais pas trop de surprise de ce côté-là).

Le réveil de la machine après fermeture du capot est long, plus de 30s. D'après journalctl, la dernière action avant une pose longue est :

SERVICE_STOP [...] NetworkManager-dispatcher [...]

L'étape finale sera de gonfler la RAM en passant de 8Go à 16Go, mais pour ça il me faut le tournevis qui va bien, évidemment ! Pentalobe P5 1.2, si ça vous intéresse.

#fedora #linux #recyclage

Contexte

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.

Le début des problèmes

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/pelican

J'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.

Constat amiable

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.

Configuration SSL

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 donc
• https://xxx.calut.fr est bien mon instance nextcloud

Mais ! – 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 :

• une entrée type A pour xxx qui renvoie vers l'IP de mon VPS
• une entrée type A pour djelly qui renvoie vers l'IP de mon VPS
• pas d'entrée pour yyy

Petite analyse :

• J'ai une erreur pour yyy.calut.fr : normal, le navigateur ne sait pas où aller chercher les fichiers
• http://xxx ou http://djelly renvoient tous les deux vers /var/www/html/pelican
• https://xxx ou https://djelly renvoient tous les deux vers /var/www/html/nextcloud

On dirait que le VirtualHost de djelly écrase celui de nextcloud...

La réponse !

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 apache
• ssl-nextcloud.conf déclare le VirtualHost pour nextcloud
• ssl-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

#Web #SSL #Pelican #Nextcloud #selfHosting

Dure tâche que de choisir un moteur de site personnel. En bon(?) ingénieur, la première chose à faire est de définir les besoins :

• Publication de billets type blog
• Pages statiques de présentations
• Gestion de la syndication de contenu
• Catégorisation des billets
• Étiquetage des billets

Contraintes perso

À ces besoins s'ajoutent des contraintes éthiques :

• Hébergeable sur un VPS
• Basé sur des logiciels libres
• Respectueux de la vie privée
• Faible consommation de ressources

Ces contraintes sont très subjectives, et on pourrait débattre du “pourquoi” sans trouver d'issue honorable. Pour le volet technique, j'ai suffisamment de bagage pour me lancer dans différentes expérimentations tout en connaissant mes limites.

Tentatives

Par le passé, j'ai tenté Dotclear^1 et WordPress^2. Je n'avais aucune envie de me relancer dans la gestion de bases de données – j'ai déjà un Nextcloud^3 en place –, et, concernant WordPress, je trouve que c'est un bien gros morceau pour la finalité recherchée : ce site perso me servira plus à archiver mes pensées, éventuellement partager modestement certaines expériences, mais pas plus.

Encore plus loin dans le temps (~2005), j'avais construit ma page de CV à la main en PHP. Avec gestion fr/en et génération de bibliographie bibtex ! Mais je suis trop vieux pour ces conneries.

Le statique c'est fantastique

De plus, la contrainte de faible consommation de ressources dictée par le rapport du GIEC[^4] m'a conduit, par les conseils de gens qui savent, vers la génération de sites statiques. Il s'agit d'éditer “à l'ancienne” les fichiers html qui seront servies par un serveur http classique.

Ce billet vous est donc offert par Pelican[^5], générateur de site statique, nettement mieux décrit sur cette page que ce que je pourrais faire.

Hackerman, ou la publication via Nextcloud

Lors de la génération d'un nouveau projet, l'assistant propose plusieurs types de publication : FTP, SSH, Github Pages,... Aucune ne me convenait : je sors d'une petite déception avec Pico, integré dans Nextcloud grâce à une App très bien faite. Mais finalement, mes limites techniques ont eu raison de ma persevérence (notamment sur la configuration de la réécriture d'URL, j'y reviendrai).

Mais j'ai gardé à l'esprit cette démarche : je veux pouvoir éditer mes billets confortablement sur ma machine locale et publier le contenu sur mon VPS qui héberge aussi mon instance Nextcloud.

Facile : mon espace disque Nextcloud est synchronisé localement. Il suffit donc d'éditer les fichiers de content/ !

Lors de la publication, le contenu généré en html va dans un répertoire output, toujours dans mon espace Nextcloud partagé localement : j'ai donc simplement créé un lien symbolique vers ce répertoire dans le DocumentRoot de mon serveur apache (/var/www/html chez moi).

Il y a deux méthodes de publication :

• $> pelican content/
• $> make publish

La première utilise le fichier de configuration pelicanconf.py. La deuxième utilise publishconf.py, qui ne fait que reprendre les valeurs du premier et réécrit certaines autres. Afin de créer une sorte de pre-release, le repertoire de sortie de pelicanconf.py est output/draft/. Cela me permet de tester dans le navigateur la génération de contenu. Le fichier publishconf.py réécrit OUTPUT_PATH = 'output/'

Et après...

Il me reste à gérer correctement le SSL et les réécritures d'URL, la présence de Nextcloud sur le même serveur ne me simplifie pas la tâche. Surtout parce que j'ai laissé faire une installation “par défaut”. A priori, la configuration d'Apache est telle qu'elle considère Nextcloud comme le seul point d'entrée sur le serveur.

Vous pouvez tenter https://djelly.calut.fr. Vous serez renvoyés sur mon cloud, avec une erreur de domaine non approuvé (ce qui est un peu rassurant quand même !)

Et bien sûr, personnaliser tout cela de belle façon – pour l'instant, le thème par défaut est utilisé.

Disclaimer: ne vous syndiquez pas pour l'instant !!

[^4]: Page des rapports du GIEC[^5]: https://blog.getpelican.com/