MouTonLibre

2 commentaires

tl;dr: Ceci est le dernier article sous le nom de domaine blog.moutonlibre.net. Je transfère le tout sous moutonlibre.net/blog donc pensez à mettre à jour l'adresse du flux RSS dans vos agrégateurs !

Ces derniers temps, et ce n'est pas près de changer, j'ai beaucoup moins de temps à consacrer à la gestion de mes services personnels en ligne (MouTonLibre quoi). Je compte en effet récupérer ce temps pour me consacrer à mes autres loisirs (développement, sport, photographie, etc.). En ça je rejoins globalement les conclusions de Cyrille, à savoir que l'auto-hébergement voir même l'hébergement en général n'est pas encore adapté au grand public. Je ne pense cependant pas que ce soit un problème de compétences, mais de temps : il faut du temps pour acquérir les compétences mais aussi pour la maintenance régulière de l'hébergement.

Ne souhaitant cependant absolument pas fermer cet espace, j'ai donc cherché à simplifier le backend de MouTonLibre et je souhaitais partager avec vous mes conclusions.

Le Raspberry, c'est une perte de temps pour les solutions d'auto-hébergement. Et cela pour deux raisons qui se résument en cinq lettres : SD et ARM. Balancer un OS sur une carte SD est une hérésie du fait de sa fragilité. Les erreurs d'écritures s'enchaînent et sur un OS ça fait très mal. J'en ai déjà malheureusement fait la désagréable expérience... Alors après le Raspberry 3 permet de booter sur un disque dur externe, mais le partage du port Ethernet avec le port USB me rebute un peu... De même un processeur ARM (et les différents drivers non-libres...) c'est bien pour la bidouille, mais cette technologie limite malheureusement énormément les choix techniques. On est limité à un choix restreint de distributions et de solutions techniques. Ce qui peut ne pas nous correspondre... Bref, préférez des solutions plus traditionnelles comme un Q-nap ou un NUC. Ce n'est pas beaucoup plus cher, mais la fiabilité n'a vraiment rien à voir.

Ma deuxième erreur, qui semble être un détail mais qui devient finalement chronophage, est la multiplication des sous-domaines. Chaque sous-domaine doit être paramétré entièrement, de la gestion du DNS jusqu'à la génération des certificats de sécurité. De plus en cas de changement dans la configuration il faut attendre la propagation sur les serveurs DNS pour que le service soit disponible. Et pour quels avantages ? Dans mon cas : aucun. Un dossier placé à la racine avec le bon nom et le service approprié suffit largement et c'est quand même vachement plus simple.

On en vient donc au dernier point, et je rejoins une nouvelle fois Cyrille, rien ne vaut un service installable avec seulement une copie de fichiers via FTP. On crée le dossier, on copie les fichiers, on se connecte et basta. Ainsi c'est facilement installable, les sauvegardes sont d'une simplicité déconcertante et cerise sur le gâteau une migration se fait les doigts dans le nez. C'est peut-être là l'erreur faite par les différentes solutions d'auto-hébergement : la simplicité ne repose pas sur une belle interface graphique mais bien sur une gestion ultra-simple via des outils traditionnels. Tout le monde sait se déplacer dans une arborescence et faire des copier/coller mais ne sait pas forcément aller chercher dans des fichiers de configuration obscurs pourquoi l'installation "one-click" ne s'est pas déroulée comme prévu (je n'ai jamais réussi à installer un serveur mail sur Yunohost par exemple).

Donc aujourd'hui MouTonLibre se limite donc un nom de domaine complètement paramétré par o2switch (y compris les certificats Let's Encrypt) et des sous-dossiers contenant mes applications "copier/coller" (BlogoText, BoZon). Et pour la page d'accueil, tout est géré par le petit moteur de page statique de Thuban : swx. Il se charge lui-même de lister mes sous-dossiers et de générer les liens correspondant. Et si je veux rajouter d'autres pages statiques, cela se fait en quelques secondes par l'ajout de fichiers formatés en txt2tags. Ultra-rapide. La mise en place était d'autant plus facile que j'ai piqué la configuration de http://3hg.toile-libre.org/... ;-)

Avec tous ces petits changement, je peux maintenant gérer mon domaine en quelques minutes. Ce qui peut se faire en coup de vent le soir. Gros changement puisqu'il me fallait facilement une demi-heure durant le weekend pour tout gérer lorsque je m'auto-hébergeait sur le Raspberry... Mais l'apprentissage est devenu très limité...

Malheureusement, la conséquence de tout cela est que les adresses des flux RSS et ATOM du blog ont migré aussi... Du coup si vous souhaitez toujours me suivre, à partir de maintenant ce sera à ces adresses :
https://moutonlibre.net/blog/rss.php ou https://moutonlibre.net/blog/atom.php.

12 commentaires

Ceux qui passent, ou passaient, de temps en temps sur ce blog se sont certainement rendus compte de sa longue indisponibilité. Et cet article est une bonne nouvelle puisqu'il annonce le retour de MouTonLibre, mais sous une forme un peu différente... Au travers de cet article, je vais tenter de vous expliquer les problèmes que j'ai rencontré et, bien plus important, je vais vous dire les conclusions que j'ai pu tirer de toute cette aventure.

TL;DR : Mon serveur a planté lors d'une mise à jour, pas de sauvegarde du système (pas bien), pas le temps de tout réinstaller immédiatement, fin de l'auto-hébergement pour les services publics. L'hébergement, c'est du sérieux.

Il y a un mois, je devais renouveler mes certificats LetsEncrypt. Étant connecté sur mon serveur, j'en ai profité pour mettre à jour, naïvement, Raspbian. Tout s'était bien passé, à première vue, mais au redémarrage ce fut le drame. Le Raspberry était bloqué sur l'écran de démarrage que tous les possesseurs de la framboise connaissent.

Pour une fois, et c'est toujours ainsi que ça se passe, j'avais oublié de faire une sauvegarde... Oui, j'avais opté pour la solution de facilité : sauvegarde manuelle et régulière des fichiers de mon blog. Pas de rsync et de cron. Non, pour le moment j'étais resté sur une solution de facilité. Mais voilà la dernière sauvegarde était antérieure à la rédaction du dernier article. Boulet.

Donc vous voyez venir le problème. Le Raspberry ne démarrait plus et pas moyen de sauver le truc après avoir écumer le web à trouver une solution. Il fallait donc que je réinstalle Raspbian et mes services de A à Z. Mais avec en plus des solutions de backup plus professionnelles. La flemme, et surtout pas le temps, et l'argent, pour cela.

Donc l'auto-hébergement est une expérience intéressante, mais à partir du moment où il faut penser à mettre en place des solutions professionnelles, ou qui y ressemblent, pour assurer la continuité du service, alors l'amateurisme n'est plus adapté. De plus, cela commençait à empiéter de façon importante sur le temps libre et il faut alors le dire : ça saoule.

J'en suis donc arrivé à la conclusion que je souhaitais héberger mon blog, et éventuellement d'autres services publics à l'avenir, sur une solution de qualité professionnelle. Et quoi de mieux alors que de faire appel aux professionnels ? Si on considère que le temps c'est de l'argent, et que pour arriver à une qualité de service acceptable, je devais investir dans divers disques durs, on réalise vite que payer un hébergement n'est pas la mer à boire. J'ai donc pris l'abonnement à 5€ par mois chez o2switch qui propose le tout illimité (bande passante, espace disque, etc.). Pratique.

Dernier problème, j'avais pris mon nom de domaine chez OVH. Et le changement de registar n'est pas immédiat... Il faut rajouter à tout cela, une semaine et demi de délai pour le transfert du nom de domaine. Rien à faire, tout est très simple, mais c'est un peu long.

Bref, une fois tout cela réglé, j'ai donc basculé mon blog (amputé d'un article) sur mon hébergement o2switch. Il faut encore que je règle deux trois détails je pense (notamment les alias, les certificats LetsEncrypt, etc.), mais le plus gros semble être fait.

Pour autant, je n'ai pas totalement abandonné l'auto-hébergement. Dans le fond, le seul avantage de l'auto-hébergement est d'avoir un contrôle de ses données personnelles. Quel est donc l'intérêt d'auto-héberger son blog, qui est un lieu public ? Aucun. En revanche, pour ce qui est de l'hébergement d'un cloud personnel, cela reste intéressant.

Donc aujourd'hui ma stratégie d'hébergement de mes services web est finalement assez simple :

  • les services publics (blog et galerie pour le moment, destinés à être visibles par des tiers) sont hébergés sur une solution professionnelle ;
  • les services privés (que je suis donc seul à utiliser) et recueillant des données personnelles sont auto-hébergés.

Je pense avoir trouvé ici un juste équilibre entre coût, contrôle des données personnelles, qualité du service et perte de temps. J'ai commencé l'auto-hébergement pour apprendre, et l'apprentissage doit être un jeu. Proposer des services publics fait quitter l'auto-hébergement du simple loisir, et il faut en être conscient avant de se lancer.

10 commentaires

J'ai failli appeler cet article « Bozon, c'est bon. Mangez-en ! » ou « Bozon, c'est pas de la bouse ! », mais voyez que j'arrive encore à me retenir... Toujours est-il que l'idée est là : BoZoN, dont j'ai appris l'existence par Cyrille, est un logiciel plutôt exceptionnel.

Du fait que j'auto-héberge mes services web sur Raspberry et que je débute dans ce domaine, j'ai besoin de services légers, faciles d'accès et facilement maintenables. Au contraire d'un Owncloud tendant vers l'usine à gaz (CozyCloud étant exclu car mono-utilisateur), BoZoN est une plateforme de stockage et partage de fichiers très minimaliste. Tout fonctionne sans base de données et repose uniquement sur le parcours de l''arborescence des dossiers utilisateurs et la création de liens de partage uniques, permettant une gestion complète (installation, sauvegardes, mises à jour, etc.) via de simples copier/coller. Et c'est le pied.

Je ne vais pas faire l'étalage de toutes les fonctionnalités ici, vous les retrouverez sur le site officiel, mais le seul manque éventuel est l'impossibilité de synchroniser des dossiers afin d'effectuer des sauvegardes facilement. Mais on finit par se faire aux *.zip.

Maintenant passons aux choses sérieuses. Premièrement, afin d'avoir un espace de stockage adapté au cloud (la carte SD du Raspberry étant un peu limite...), j'ai acheté un disque dur externe de 1.5 To. Ce qui laisse quand même pas mal de marge... À noter que ce disque dur est alimenté via une prise secteur, indispensable dans le cas d'un branchement sur Raspberry puisque ce dernier ne délivre nativement pas assez de puissance pour alimenter un disque dur via les ports USB. Afin que le disque dur soit monté automatiquement au démarrage du Raspberry, il faut rajouter une ligne au fstab. Pour cela, vous pouvez dans un premier temps brancher et monter votre disque dur puis copier la ligne correspondante dans le fichier /etc/mtab pour la coller dans le fichier /etc/fstab. Attention cependant, il est nécessaire de faire quelques adaptations. Dans mon cas, il a fallu modifier :

  1. l'identifiant de l'utilisateur à uid=33 pour qu'il corresponde à www-data ;
  2. l'identifiant du groupe à gid=33 pour qu'il corresponde également à www-data ;
  3. le point de montage vers l'emplacement sur le serveur ;
  4. le driver en ntfs-3g (et non ntfs) afin de pouvoir avoir accès en écriture au disque dur.

Ce qui donne finalement une ligne de ce type dans mon cas :

/dev/sda1 <emplacement sur le serveur> ntfs-3g rw,relatime,uid=33,gid=33,fmask=0177,dmask=077,nls=utf8,noserverino,errors=continue 0 0

Maintenant que le disque dur est monté automatiquement au démarrage, il ne reste plus qu'à installer BoZoN ! Pour cela, seules quelques étapes sont nécessaires.

  1. Téléchargez l'archive.
    wget https://github.com/broncowdd/BoZoN/archive/master.zip
  2. Décompressez l'archive (unzip est une dépendance à BoZoN, à installer au préalable).
    unzip master.zip
  3. Copiez le dossier vers la racine de votre site.
    cp -R BoZoN-master/* <emplacement sur votre serveur>
  4. Ajoutez la configuration Nginx suivante. (Attention à mettre à jour les différents champs.)
    server {
    	listen 80;
    	listen [::]:80; #ipv6
    	server_name <nom de domaine>;
    	return 301 https://$server_name$request_uri;
    }
    server {
    	listen 443 ssl;
    	listen [::]:443 ssl; #ipv6
    	server_name <nom de domaine>;
    
    	index index.php;
    	root <emplacement sur votre serveur>;
    	client_max_body_size XXXXM; # XXXX à remplacer avec la taille maximale autorisée pour l'envoi de fichiers. Attention à actualiser le fichier php.ini également.
    
    	location ~ \.php$ { 
    		try_files $uri = 404;
    		fastcgi_pass unix:/var/run/php5-fpm.sock;
    		include fastcgi_params;
    		fastcgi_intercept_errors on;
    		fastcgi_param HTTPS on;
    		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    	}
    
    	# On protège certains dossiers.
    	location / {
    		location ~ (uploads|private|thumbs) {
    			deny all;
    		}
    		location ~ core {
    			deny all;
    			location ~* \.js$ {
    				allow all;
    			}
    		}
    	}
    
    	# Configuration HTTPS
    	ssl_certificate <emplacement du certificat>;
    	ssl_certificate_key <emplacement de la clé>;
    	ssl_trusted_certificate <emplacement de la chaîne de contrôle de l'autorité de certification>;
    
    	ssl_protocols TLSv1.2;
    	ssl_ecdh_curve secp384r1;
    
    	ssl_ciphers EECDH+AESGCM:EECDH+AES;
    	ssl_prefer_server_ciphers on;
    
    	resolver 80.67.169.12 80.67.169.40 valid=300s;
    	resolver_timeout 5s;
    	ssl_stapling on;
    	ssl_stapling_verify on;
    
    	ssl_session_cache shared:SSL:10m;
    	ssl_session_timeout 5m;
    	ssl_session_tickets off;
    
    	add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload";
    }
    
  5. Relancez Nginx.
    service nginx reload

Rendez-vous sur votre site avec votre navigateur préféré, et il ne vous reste plus qu'à vous connecter ! À noter qu'à la première connexion, il vous sera demandé de créer le compte administrateur.

Le petit plus que j'apprécie vraiment est que suite à la copie de ma bibliothèque musicale sur BoZoN, je peux maintenant l'écouter n'importe où grâce au lecteur intégré. Allez si je peux me permettre une suggestion, il serait vraiment génial de pouvoir créer des playlists... La création de liens symboliques dans un dossier via BoZoN ne pourrait pas être envisageable ? ;)

À noter que, du fait de mon amateurisme, il se peut que la configuration de Nginx soit perfectible. BoZoN est prévue pour fonctionner de base avec Apache, et la configuration que je vous ai donnée relève du bricolage. N'hésitez donc surtout pas à me faire part de vos remarques.

9 commentaires

Suite aux différentes remarques reçues via les commentaires de mon article sur Let's Encrypt, j'ai décidé de remettre un peu les mains dans le cambouis.

Ma configuration de Nginx était un peu flaibarde et trop simpliste. Ce qui me donnait une note de B au SSL server test de Qualys SSL labs. En suivant le tutoriel donné par Angristan, j'ai donc remis à jour ma configuration de Nginx.

Cela aurait pu durer 5 minutes, le temps d'écrire les lignes, mais non. Disons que chez moi, ça ne marche jamais du premier coup. La faute à l'activation du protocole spdy qui, je ne sais pas pourquoi, fait tout planter... Pour résoudre le problème j'ai donc été forcé d'ignorer la ligne :

listen 443 ssl spdy;

pour réécrire la ligne « par défaut » :

listen 443 ssl;

Bon hormis ce petit problème, la configuration donnée par Angristan est géniale&nbsp! Merci à toi.

Et pour conclure je me permets donc de comparer ma configuration à celle de ma banque (haha). À vous de juger.

LCL niveau Cblog niveau A

11 commentaires

Suite à de nombreuses remarques quant à ma sécurisation SSL bidon dans les commentaires de mon précédent article, j'ai décidé de corriger ça ce soir.

Dans un premier temps, je me servais d'un certificat auto-signé. Et autant vous dire que les navigateurs ne me considéraient pas comme une entité de toute confiance. À raison. Non pas que je cherche à pirater des données personnelles, mais bien parce que techniquement je me classe dans la catégorie des amateurs. Et n'ayant même pas confiance en moi, je vois mal des organismes m'accorder la leur.

Donc pour faire un peu plus sérieux, et accessoirement pour sauver mon flux RSS, je suis passé par le service de certification gratuit "Let's Encrypt". Et il n'y a pas à dire, ça assure.

Pour générer des certificats, rien de plus simple. Dans un permier temps, on installe Let's Encrypt :

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

À partir de là, il faut couper le serveur (et comme je suis un fou, j'ai fait ça le soir pour faire chier le plus de personne possible) avec la commande suivante (avec Nginx comme logiciel de serveur web) :

service nginx stop

Et là vous vous hallucinez car vous reconnaissez SysV et non systemd... Oui j'aime nager à contre-courant (en fait je n'ai rien choisit mais on s'en fou, c'est pour la postérité). Mais là n'est pas la question et si jamais vous êtes sous systemd, la commande pour couper le service est :

systemctl stop nginx

À ce moment là, il ne reste plus qu'à générer les couples certificats/clés avec cette commande :

./letstencrypt-auto certonly --standalone --agree-tos --email email@exemple.org -d exemple.org

Après quelques secondes, vous retrouverez le certificat (fullchain.pem) et la clé (privkey.pem) dans le dossier suivant :

/etc/letsencrypt/live/exemple.org/

Et... C'est tout ! Il ne vous reste plus qu'à changer la configuration de Nginx pour prendre en compte les nouveaux certificats et le tour est joué. Simple comme bonjour.

Juste un détail, quand vous définissez l'adresse du certificat dans la configuration de Nginx, ne faites pas une erreur de frappe comme moi... Ça peut vous ruiner une soirée.

35 commentaires

Le fait que vous pouvez lire ce texte aujourd'hui ne repose que sur une seule raison.

Comme tout lecteur de blog, vous vous attendez certainement à ce que cette raison soit une envie de partage, le besoin d'une fenêtre afin d'exprimer publiquement ses opinions, le désir d'un espace d'échange, mais non ce n'est pas la raison principale. Disons que ces divers aspects sont en quelque sorte la cerise sur le gâteau. Assez de suspens maintenant, la principale raison est tout simplement... Le challenge !

De nos jours, ouvrir un blog n'est cependant pas un challenge en soit. En quelques clics, il est possible de s'acheter un espace sur bien des hébergeurs ou même des fournisseurs d'accès à internet. Mais le challenge que je me suis fixé est d'auto-héberger quelques services internet. Pas question d'utiliser un serveur chez un tiers, je dois le voir, le toucher et pouvoir brancher un clavier et un écran dessus. Ce n'est pas la solution la plus simple, la plus sécurisée aussi, de s'offrir un espace sur le web, mais elle a le mérite de forcer l'apprentissage. La lecture de tutoriels ou diverses documentations ne remplacera jamais l'expérience. Sans mettre les mains dans le cambouis, il est impossible de savoir si l'on est capable de le faire ou non. Voilà la vraie raison de l'ouverture de cet espace.

L'objectif initial reposait donc sur quatre choses :

  • disposer d'un serveur à domicile ;
  • ouvrir un blog ;
  • proposer un espace de cloud pour les proches ;
  • le tout devant être basé sur des technologies libres.

Pour cela, et comme un serveur est destiné à rester allumer 24h/24 et 7 jours/7, il est essentiel que la consommation électrique et la pollution sonore soient réduites à leur strict minimum. Les nano-ordinateurs à processeur ARM remplissent parfaitement ces critères. Si les premières versions de ces cartes avaient des ressources trop limitées pour servir de serveur, les nouvelles générations peuvent satisfaire la majorité des besoins. Pour un blog et un espace de cloud personnel limité à quelques utilisateurs, cela est amplement suffisant. Le Raspberry Pi 2 Model B, bien que pas forcément la carte la plus puissante, a la force d'être soutenu par une immense communauté. Ainsi il est très facile de trouver des ressources pour configurer un serveur grâce à un Raspberry Pi.

La configuration du serveur a été réalisée grâce à l'excellente documentation de mon Thuban adoré (qui sera, je n'en doute pas une seconde, le premier à déposer un commentaire sur ce blog). Cela consiste en l'installation d'une version minimale du système d'exploitation Raspbian (Debian pour Raspberry Pi), puis en l'installation progressive des différents services nécessaires à un serveur.

Les ressources d'un Raspberry étant limitées, il était impossible d'installer des usines à gaz comme système de gestion des contenus. Pour le blog, j'ai suivi les conseils de Thuban et j'ai installé BlogoText développé par Timo van Neerden. Ce moteur, actuellement en version 3.2.8, a l'avantage d'être très léger et de proposer un ensemble de services nécessaires à l'activité de blogueur (partage/sauvegarde de liens, partage de fichiers, micro-blogging, lecteur de flux rss, etc.). Tout repose sur une base de donnée SQLite qui n'agit que sur un fichier, ce qui facilite grandement les sauvegardes. J'utilise ce moteur dans l'ombre depuis quelques temps et je dois dire que j'en suis très satisfait. Le seul petit manque serait une gestion des pages statiques afin de réutiliser facilement le template du blog. Timo si tu m'entends... ;)

Pour le cloud personnel, j'ai longtemps hésité à vrai dire. Quand on parle de cloud dans le monde du logiciel libre, le premier nom qui vient à l'esprit est Owncloud. Ce logiciel, très complet, est certainement trop lourd pour une utilisation sur un Raspberry Pi. Je ne dis pas que c'est impossible, mais le choix d'un Raspberry Pi entraîne la recherche de logiciels minimalistes. Plus qu'une restriction imposée par le matériel, c'est aussi un choix (dicté par le principe KISS). Cozy ne disposant pas de fonctionnalités multi-utilisateurs, ce choix a également été mis de côté. Sans d'autres alternatives à ma connaissance il y a quelques semaines, Owncloud s'avérait être le choix par défaut. Mais voilà que le blogueur le plus radical (par ses avis plus que tranchés mais respectables) du logiciel libre, j'ai nommé Cyrille Borne, a jeté son dévolu sur un petit logiciel inconnu au doux nom de BoZoN. Après un déferlement de remarques comme lui seul peut le faire, Bronco a su tenir bon sous la charge de travail et a fournit une magnifique version 2.4. Après une installation des plus simples et l'ajout d'un disque dur externe de 1.5 To à mon Raspberry, je suis maintenant en mesure de proposer un espace de cloud gratuit à ma famille. Et autant le dire tout de suite, ça marche du tonnerre. :)

Les petites technologies libres rendues disponibles par des personnes avides de partage, mises bout à bout grâce à la volonté de certaines personnes de vouloir transmettre leur savoir, permettent à des petits gars comme moi sans bagage initial en informatique d'installer leur propre espace web.

C'est ça la magie du libre.