MouTonLibre

10 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.

Aucun commentaire

C'est un peu l'actualité du moment dans le monde des distributions GNU/Linux : des nouvelles méthodes d'empaquetage d'application débarquent sur à peu près toutes les distributions et sont annoncées comme révolutionnaires. Mais qu'en est-il vraiment ?

Je vous préviens tout de suite, je ne suis pas un expert dans ce domaine et il se peut qu'il y ait quelques imprécisions. J'ai essayé de me renseigner au maximum avant d'écrire cet article afin de ne pas trop écrire d'aberrations, mais je n'ai pas fait une étude approfondie du code source pour être sûr de ce que j'avance. De toute façon même si je le voulais je n'en aurais pas les capacités. ;) Mais surtout n'hésitez pas à apporter des précisions dans les commentaires, dans d'autres articles, etc.

Dans cet article, je ne parlerai que de deux types de paquets dits "universels" :

  • Flatpak, proposé par freedesktop.org (un projet chargé de proposer des solutions pour favoriser l'interopérabilité dans le secteur des environnements de bureaux libres) ;
  • Snap, proposée par Canonical (la société derrière Ubuntu).

L'existence même des ces types de paquet repose sur la volonté de lancer les applications dans des "bacs à sable". Il s'agit en fait d'isoler les applications du système d'exploitation. L'application évolue de façon autonome et les interactions avec le système hôte ne sont possibles qu'en cas d'accord explicite de la part de l'utilisateur/administrateur. Cela reprend un peu le fonctionnement des applications, Android, iOS qui demandent par exemple la permission d'utiliser la webcam, ou la connexion réseau.

Commençons déjà par décrire le fonctionnement de Flatpak, un poil plus conventionnel que Snap à mes yeux. Accrochez-vous, mais sachez que si vous comprenez la méthodologie utilisée par Flatpak, vous comprendrez le fonctionnement de Snap.

Flatpak repose sur une approche basée sur 2 couches :

  • les runtimes ;
  • l'application.

Un runtime peut être vu comme une librairie partagée et étendue. Alors pourquoi étendue ? Car en plus de la communication vers le système d'exploitation (comme cela se fait actuellement), le runtime est aussi chargé de gérer les accès vers le système hôte. Il est chargé d'ouvrir tel ou tel droit (comme l'accès au réseau, aux fichiers de l’utilisateur) aux applications qui utiliseront ce runtime.

Le paquet à proprement parler intègre l'application mais aussi toutes ses dépendances annexes. Il faut bien comprendre que seul un runtime peut-être partagé entre plusieurs applications. Toutes les autres dépendances doivent être intégrées de façon brute au paquet.

Prenons l'exemple de l'installation de Firefox (en version Gtk idéalement) par le biais d'un paquet Flatpak. Firefox nécessitera le runtime org.gnome.Platform 3.xx (qui propose Gnome SDK) pour les accès au réseau, ainsi que la bibliothèque Gtk (ce qui permet d'alléger l'application). Bien sûr l'idée est aussi de pouvoir gérer de façon précise les droits en verrouillant/déverrouillant certains accès comme bon vous semble. Le fait de baser une application sur un certain runtime, ne donne pas accès à tout les droits gérés par ce runtime. Imaginez maintenant que vous vouliez que la langue de Firefox s'adapte à votre locale. Alors l'application Firefox devra également se baser sur le runtime org.gnome.Locale 3.xx qui se chargera de gérer les accès à la locale du système. Toutes les autres dépendances de Firefox (SQLite, ffmpeg, mesa, python, etc.) sont directement intégrées au paquet et ne pourront pas être partagées avec une autre application.

Dernier point concernant Flatpak, il est actuellement impossible de faire communiquer deux paquets ensemble. Dans le cas de LibreOffice et de son utilisation via Flatpak, il est par exemple impossible d'ouvrir un navigateur via un clic sur un lien hypertexte présent dans un document. De même, il est impossible d'accéder à une aide en ligne, ou même une aide locale sous forme html sans intégrer un moteur de rendu html... Vous sentez venir les emmerdes non ?

Pour ce qui est de Snap, le fonctionnement est légèrement différent. Chaque package comprend l'application ainsi que l'intégralité de ses dépendances, enfin jusqu'à un certain niveau (vous allez comprendre après la lecture des prochains paragraphes), afin de fonctionner en totale indépendance.

En revanche, il existe des paquets Snap un peu spéciaux. Ces paquets ne sont pas des applications (qui je le rappelle fonctionnent en toute indépendance les unes envers les autres) mais des "frameworks". En fait il s'agit d'extensions au système initial (ubuntu-core pour le moment) qui ont des privilèges un peu spéciaux. On va dire que les frameworks sont relativement libres. Les applications communiquent ensuite directement avec ce framework et la gestion des droits se fait donc entre les Snaps "applications" et les Snaps "framework". Comme framework disponible sur Snappy Ubuntu Core, il y a par exemple Docker. Vous commencez à comprendre le truc ? On peut finalement voir de grandes similitudes entre les frameworks de Snap et les runtimes de Flatpak, mais à différents niveaux (Flatpak pour le bureau, Snap pour des services).

À noter que le logiciel chargé de communiquer directement avec le système d'exploitation est lui même considéré comme un paquet Snap. Mais il est spécial dans le sens que les frameworks se basent dessus, et que des applications peuvent également s'en servir comme base. Pour l'instant il n'existe que "ubuntu-core" mais ces derniers jours l'annonce a été faite que Snap serait adapté à la majorité des grandes distributions GNU/Linux.

Cependant, à la différence de Flatpak, il est possible de faire communiquer différents Snaps entre eux via un système d'interfaces. Un Snap peut proposer un "slot" (voyez cela comme la prise dans le mur), tandis que les autres snaps ont la possibilité d'utiliser ce slot pour s'y brancher et démarrer des communications (en utilisant une fiche adaptée à la prise). En listant les interfaces, il est alors possible de visionner l'ensemble des "slots" ainsi que les "plugs" (paquets connectés) associés. Il faut bien comprendre que chaque application basée sur un paquet Snap est capable de se lancer de façon totalement autonome, mais peut cependant communiquer avec les autres applications via un système normalisé permettant un contrôle fin des droits.

Voilà pour le fonctionnement. Si je pouvais résumer les similitudes et les différences je dirai que les deux types de paquets que j'ai présenté sont donc capables de lancer des applications de façon sécurisée (bac à sable) et avec un contrôle précis des droits. Mais Flatpak ne permet pas aux applications de communiquer entre elles, ce qui peut vite devenir embêtant comme on l'a vu avec LibreOffice. Pour les paquets Snap, ceux-ci doivent intégrer l'ensemble des librairies nécessaire à la construction de l'application (pas de liens dynamiques). Ce qui entraîne des tailles de paquet énormes... On repassera donc pour la légèreté des systèmes d'exploitation avec cette méthode...

En fait, après étude de ces nouveaux types de paquets, il me semble que toute cette technologie n'est pas encore assez mature mais semble prometteuse pour certaines applications. L'idéal serait d'arriver à rassembler la légèreté des paquets Flatpak avec les possibilités offertes par les paquets Snap.

Je comprends bien l'intérêt d'avoir des paquets "universels" à des fins de tests ou des applications isolées dans le cadre d'une gestion de serveurs mais je n'arrive pas à comprendre en quoi cela serait "révolutionnaire" et pourquoi cela est présenté comme la méthode d'empaquetage du futur.

Les créateurs de ces paquets insistent bien sur le fait que ces technologies sont complémentaires aux méthodes d'empaquetage "traditionnelles" (rpm, deb, etc.) mais j'ai peur que ces nouvelles méthodes ne soient utilisées à tout bout de champ sans raison valable par les développeurs et en oublient les paquets traditionnels (voir par exemple cet article). Avec Snap et Flatpak il devient très facile de créer son paquet (plus qu'un deb en tout cas) et il y a un effet de "hype" du fait de la nouveauté. Mais franchement, ça n'a quasiment aucun intérêt dans le cas d'une utilisation bureautique. Le seul intérêt concerne la sécurité dans le cas d'une application vérolée... Ce qui reste relativement rare dans le cadre des logiciels libres. J'ai par exemple du mal à saisir l'intérêt de proposer un Snap pour FreeCad. Si ce n'est pour s'amuser...

Mais parlons sécurité justement, car il s'agit bien de l'argument majeur en faveur du déploiement d'applications isolées. Les applications Snap et Flatpak sont empaquetées avec l'ensemble des librairies nécessaires à leur fonctionnement. Ce qui implique que le paquet doit immédiatement être mis à jour lors de la détection d'une faille de sécurité dans une des librairies... Et je ne pense pas que le développeur d'un logiciel proposant son paquet universel pour être tranquille avec le déploiement dans tout l'écosystème GNU/Linux soit plus réactif que des mainteneurs uniquement en charge de la librairie... Imaginez en plus si une faille est découverte dans OpenSSL (toute ressemblance avec un événement réel est purement fortuite). Un administrateur système devra alors s'amuser à chercher tous les paquets ayant empaqueté les versions compromises de OpenSSL (ah oui car en plus, la gestion des versions est totalement libre) pour les désactiver un par un en attendant que tous les créateurs de paquets les remettent à jour... Voilà voilà, je vous laisse méditer là dessus.

J'ai vraiment cherché à me faire une idée de mon côté. En repartant de la base et du fonctionnement de ces nouvelles méthodes d'empaquetage. Et je dois dire que le seul usage que je peux y trouver est un usage de test. On installe une application dans un bac à sable en veillant bien à limiter les droits d'accès au système, on teste un peu, puis on supprime le tout sans laisser de traces. Pour le reste... Très peu pour moi.

J'espère donc que les développeurs ne sauteront pas sur Snap ou Flatpak comme si c'était la solution à tous les problèmes. Restez sur les bonnes vieilles méthodes... S'il vous plaît.

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.

8 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 ! Merci à toi.

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

LCL niveau C blog 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.

32 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.