Génération Linux - Auto hébergement

Libérons le cloud avec Cozy

Frank — Tue, 14 May 2013 09:00:00 +0200

Aujourd'hui petite exception, ce n'est pas moi qui vais rédiger cet article. Je laisse la parole à des passionnés d'auto-hébergement qui nous présente leur projet de Cloud personnel libre : Cozy !

Bonjour à tous, chez Cozy Cloud, une jeune startup, nous sommes de fervents défenseurs du logiciel libre et de sa culture. Et comme en plus, nous ne sommes pas satisfaits du modèle actuel des services web, nous cherchons à redonner le contrôle de ses données et services à l'utilisateur. Pour cela nous vous proposons un projet libre auto-hébergeable nommé Cozy.

Cozy renverse le modèle existant en donnant un serveur à chaque utilisateur sur lequel il centralise ses données. Un Cozy n'est pas une distribution Linux mais une collection d'applications webs. Les applications partagent les données et des fonctionnalités entre elles permettant une intégration forte et de nouveaux usages. En effet, nous pensons que cette architecture est propice à l'émergence d'applications innovantes tirant parti des données personnelles en toute transparence (restitutions de données, quantified-self, objets connectés, ...). Des services plus classiques comme le partage de fichiers/photos, la prise de notes/todos et les emails sont bien évidement de la partie.

Pour rentrer dans les détails techniques et concrets, on peut dire que c'est une suite d'application écrite en Node.js accolées à une base de donnée Couchdb et à un serveur d'indexation écrit en Python. Un des modules permet de télécharger, démarrer et arrêter facilement des applications écrites en Node.js. Ce qui veut dire que vous pouvez très facilement ajouter votre propre application (plus de détails sur l'architecture ici).

Installation (pour Debian/Ubuntu)

Pour faciliter l'installation, nous mettons à votre disposition un script d'installation Fabric. Fabric est une technologie permettant d'exécuter des commandes sur un serveur distant depuis votre machine locale. Il vous faudra donc d'abord installer python, Fabric et son extension Fabtools, sur votre machine locale pour pouvoir ensuite déployer la « stack » Cozy sur votre serveur distant.

Attention : Certaines commandes et déploiement d'applications prennent un certain temps.



apt-get install python python-pip


sudo pip install fabric fabtools

Téléchargez ensuite le script Fabric qui lancera les commandes sur votre serveur distant :

wget https://raw.github.com/mycozycloud/cozy-setup/master/fabfile.py

Pour finir, démarrez le script en indiquant le sudoer ou l'utilisateur root de votre serveur ainsi que l'adresse IP de votre serveur (celui ci doit autoriser un accès SSH).

fab -H user@ip install

Le script vous demandera une série d'informations pour générer le certificat HTTPS. Vous pouvez entrer ce que vous voulez. Il vous réclamera aussi un nom de domaine qui correspond au domaine où vous hébergez votre Cozy. Cela est utile pour générer des urls dans le mail d'oubli de mot de passe.

NB: En raison du nombre de technologies installées, nous vous recommandons l'installation dans une machine virtuelle ou dans un conteneur si votre serveur le permet.

Démarrage

Lorsque l'installation est terminée, vous n'avez plus qu'à vous enregistrer sur : https://IP.

Attention : Si vous voyez seulement la page d'accueil de NGINX c'est qu'il vous faut utiliser le protocole HTTPS.

Ensuite vous accédez à vos apps en un clic.

Un clic sur le bouton Apps en haut à droite vous donne accès au repository d'applications. Écran dans lequel vous pouvez aussi indiquer l'url du dépôt git d'une application que vous avez créée.

Pour mettre à jour ou supprimer une application, il faut simplement revenir sur la page d'accueil, cliquer sur le bouton manage et cliquer sur le bouton update/remove de l'application concernée :

Voilà vous savez déjà comment administrer votre cloud perso avec Cozy ! Si vous avez besoin d'aide vous pouvez nous retrouver sur #cozycloud sur freenode.net ou tout simplement nous envoyer un mail à contact@cozycloud.cc . Vous trouverez également dans la suite quelques liens qui pourront vous être utile.

Site du projet

Guide de création d'applications

Détail de l'installation de Cozy

Site de la société (solution d'hébergements)

Sauvegardes distantes chiffrées avec un Raspberry Pi, Truecrypt et Rsync

Benjamin — Mon, 29 Apr 2013 16:07:00 +0200

Je vous l'avait dit, je voulais mettre en place un système de sauvegarde distante de mon serveur perso. Ces sauvegardes devaient être automatiques, sécurisées et peu coûteuses en énergie. J'ai trouvé mon bonheur avec la mise en place d'un Raspberry Pi, loin de chez moi, sur lequel j'ai branché un disque dur externe chiffré et où mes sauvegardes sont exportées (synchronisées) toutes les nuits. Voici comment j'ai fait :

Rappel des besoins

Voici ma "politique de sauvegarde" actuelle : j'ai mon serveur personnel chez moi dans lequel se trouve deux disques durs : un principal, sur lequel se trouve mon OS et mes données et un autre disque, sur lequel je synchronise les données à sauvegarder présentes sur mon premier (j'avais expliqué comment je faisais tout ça dans cet article).

Je voulais mettre en place une sauvegarde distante automatique, sécurisée et pas chère. L'objectif est de dupliquer mon deuxième disque dur sur un disque externe distant chiffré. J'ai trouvé mon bonheur avec ce matériel :

Un Raspberry Pi
Un Hub alimenté
Un disque dur externe chiffré

Coût total du projet : Raspberry Pi + Boitier + Carte SD + Clé WiFi + Disque dur externe d'occasion = environ 70€

Cette mise en place se déroule en 3 grandes étapes que je vais expliquer :

Installation du Raspberry Pi
Déchiffrage du disque dur
Synchronisation des données

Installation du Raspberry Pi

Matériel

J'ai donc décidé de mettre en place le Raspberry Pi chez mes beaux parents. Il sera placé dans le fin fond d'une pièce, dans une belle boite prévue à cet effet :

WiFi

Le premier problème à été de mettre en place le WiFi. La box de mes beaux parents étant configuré en WEP, j'ai eu du mal à y associer le Raspberry Pi. Après quelques essais infructueux, j'ai décidé de les passer en WPA, ce qui augmente la sécurité et (surtout) facilite la configuration de mon Raspberry. Je n'ai eu plus qu'à suivre ma documentation pour configurer le tout correctement.

IP dynamique

Ensuite est venu un deuxième gros problème : mes beaux parents sont chez Orange et ont donc une adresse IP dynamique. Comme mon nom de domaine est géré chez OVH, j'ai suivi leur documentation pour paramétrer un champ DynHost et associer une URL à la livebox de manière permanente. J'ai tout de même patché le petit programme qu'ils fournissent en modifiant cette ligne du fichier dynhost :

IP=`/sbin/ifconfig $IFACE | fgrep "inet ad" | cut -f2 -d":" | cut -f1 -d" "`

par celle-ci :

IP=`wget http://checkip.dyndns.org/ -O - -o /dev/null | awk '{ print $6 }' | cut -d "<" -f 1`

Sans ce patch, l'IP renvoyée à OVH (et associée à mon URL) est l'IP privée de mon Raspberry et non pas l'IP publique de la Livebox (sic).

C'est prêt

Une fois toutes ces choses faites, j'ai bien un Raspberry Pi qui tourne dans un coin de chambre à 100 Km de chez moi et qui répond toujours à la même URL (malgré son IP dynamique).

Déchiffrage du disque dur

Le Raspberry Pi n'étant pas chez moi (je ne peux pas savoir qui rentre et sors chez mes beaux parents), je voulais chiffrer mon disque dur afin que mes données soient illisibles en cas de vol de mon disque dur externe.

Pour faire cela, j'ai déjà dû, dans un premier temps, "l'initialiser" (le chiffrer). J'ai utilisé le logiciel Truecrypt et j'ai expliqué cette manipulation dans cet article. Sur mon Raspberry Pi, il me suffit ensuite d'installer Truecrypt afin de déchiffrer et d'exploiter ce disque.

Installation de Truecrypt

L'installation de truecrypt est un peu compliquée sur le Raspberry Pi. En effet, le processeur de ce dernier est un ARM. L'installeur de truecrypt est compatible avec les architectures x84 et x64. Autrement dit, l'installation "facile" (que j'avais expliquée dans mon article) ne marche pas sur le Raspberry et il faut compiler soi même le programme.

Par manque de temps (et par fainéantise), j'ai préféré récupérer un binaire déjà compilé (en version 7.1a) plutôt que de le faire moi-même (pourquoi réinventer la roue ?). Je vous le propose à mon tour : vous pouvez le récupérer en tapant cette commande en tant que root sur votre Raspberry Pi :

wget http://www.generation-linux.fr/dl/truecrypt -O /usr/local/bin/truecrypt && chmod +x /usr/local/bin/truecrypt

Cette commande va :

récupérer le binaire trucrypt compatible avec le Raspberry Pi (fonctionne avec la Raspbian Wheezy) ;
le mettre dans le répertoire /usr/local/bin (pourquoi ce répertoire ?) ;
le rendre exécutable.

Désormais, vous pouvez utiliser truecrypt en l'appelant simplement dans votre ligne de commande :

truecrypt --version

Montage (déchiffrage) du disque dur externe

Une fois que truecrypt est installé, je vais pouvoir l'utiliser pour déchiffrer mon disque dur externe. Avant cela, un df me montre que mon disque n'est pas encore monté sur mon système :

root@yoshi:~# df
Sys. fich.     1K-blocks   Util. Disponible Uti% Monté sur
rootfs          15443952 2076020   12583668 15% /
/dev/root       15443952 2076020   12583668 15% /
devtmpfs          240516       0     240516   0% /dev
tmpfs              49756     260      49496   1% /run
tmpfs               5120       0       5120   0% /run/lock
tmpfs              99500       0      99500   0% /run/shm
/dev/mmcblk0p1     57288   21056      36232 37% /boot

Pour le monter, il suffit de taper la commande suivante : truecrypt /dev/sda1 /mnt/
Truecrypt me demande le mot de passe associé à mon disque dur, mon keyfile (tapez entrer directement si vous n'en avez pas) et s'il faut monter un dossier caché. Une fois ceci fait, vous verrez que le disque est bien monté dans le répertoire /mnt/ :

root@yoshi:~# truecrypt /dev/sda1 /mnt/
Enter password for /dev/sda1:
Enter keyfile [none]:
Protect hidden volume (if any)? (y=Yes/n=No) [No]:

root@yoshi:~# df
Sys. fich.             1K-blocks    Util. Disponible Uti% Monté sur
rootfs                  15443952 2076028   12583660 15% /
/dev/root               15443952 2076028   12583660 15% /
devtmpfs                  240516        0     240516   0% /dev
tmpfs                      49756      264      49492   1% /run
tmpfs                       5120        0       5120   0% /run/lock
tmpfs                      99500        0      99500   0% /run/shm
/dev/mmcblk0p1             57288    21056      36232 37% /boot
/dev/mapper/truecrypt1 153835300 67334292   78686572 47% /mnt

Un petit ls -l /mnt/ me confirme bien que mon disque est monté et lisible :

root@yoshi:~# ls -l /mnt/
total 28
drwxr-xr-x 2 root root 4096 avril 9 05:27 Papiers
drwxrwxr-x 3 root pi 4096 avril 20 15:54 Photos
-rw-r--r-- 1 root root 0 avril 25 07:49 truecryptok

Notez qu'à chaque redémarrage du Raspberry Pi, il faudra vous y connecter et remonter le volume truecrypt.

Synchronisation des données

Script de synchronisation

J'ai décider d'utiliser rsync pour synchroniser les données présentes sur le deuxième disque dur de mon serveur avec le Raspberry Pi distant. Voici le script que je vais utiliser :

#/bin/bash AUTH="root@raspi.distant.fr" FICHIER_LOG="./logs/backup_raspi.log" /bin/rm $FICHIER_LOG /usr/bin/touch $FICHIER_LOG FileExists=`ssh -p 2345 ${AUTH} "test -e /mnt/truecryptok && echo 1 || echo 0"` if [ ${FileExists} = 0 ] then #echo "non" echo "Le volume truecrypt n'est pas monté sur raspi" | /usr/bin/mail -s "Problème sauvegarde raspi" mon@mail.fr else #Le répertoire est monté #/usr/bin/rsync -rlpgotD -e ssh --compress --stats --verbose --delete --force /backup/* ${AUTH}:/mnt/ >> $FICHIER_LOG /usr/bin/rsync -rlpgotD --rsh='ssh -p2345' --compress --stats --verbose --delete --force /backup/* ${AUTH}:/mnt/ >> $FICHIER_LOG fi

Voici les explications des points spéciaux :

Mon script doit avant tout tester si le volume truecrypt est bien monté sur le Raspberry Pi. Pour faire cela, dans le disque dur externe (chiffré) du Raspberry, j'ai créé le fichier truecryptok. Ce fichier n'apparaît donc que lorsque le volume est monté (déchiffré). La commande passée dans la variable FileExist va contrôler à distance que ce fichier est bien présent. Si la commande renvoi 0 c'est qu'il n'est pas présent (ou que la connexion SSH ne marche pas), je m'envoie donc un mail pour m'avertir de monter le volume et de relancer la sauvegarde. Sinon, c'est que le volume est déjà monté et je lance ma commande de synchro rsync. Notez que j'ai ouvert mon serveur SSH sur le port 2345, mes commandes incluent ce port différent.

Désormais, en lançant mon script depuis mon serveur perso, il me demande le mot de passe de mon Raspberry Pi et la synchronisation se passe correctement.

Connexion automatique

Une dernière chose à régler pour automatiser le tout c'est d'empêcher la demande de mot de passe SSH quand on lance une synchro. Pour ce faire, on va établir une authentification SSH avec clés publique/privée entre mon serveur et mon Raspberry Pi. J'avais expliqué ce mécanisme dans cet article il y a un peu plus de 5 ans (déjà !).

Pour résumé, sur mon serveur perso, j'ai tapé la commande ssh-keygen -t rsa (puis entrée à chaque fois), ce qui m'a généré une clé publique et une clé privée dans mon répertoire .ssh. J'ai ensuite utilisé la commande ssh-copy-id "-p 2345 root@raspi.distant.fr" pour envoyer la clé publique ainsi générée sur mon Raspberry Pi.

Ceci étant fait, comme je n'avais mis aucune passphrase lors de la génération de mes clés, je peux désormais me connecter (avec le compte qui m'a servi à générer les clés) en tant que root sur le Raspberry Pi sans aucune demande de mot de passe.

De cette manière, j'ai pu automatiser la synchro en faisant exécuter mon script via un cron toutes les nuits (à 23h15) :

15 23 * * * /rep/de/script/backup_raspi.sh >/dev/null 2>&1

Conclusion

La mise en place est terminée. Le disque de backup de mon serveur est désormais synchronisé toutes les nuits sur un disque dur externe distant et chiffré.

Si vous avez des remarques, si vous avez des conseils pour améliorer mon système et/ou mes scripts, n'hésitez pas, je suis tout ouïe :)

Retour d'expérience après 2 ans d'auto-hébergement

Benjamin — Fri, 05 Apr 2013 17:17:00 +0200

Cela fait un peu plus de 2 ans que j'auto-héberge presque tous mes services en ligne. J'avais fais plusieurs articles pour expliquer ce que je voulais héberger, comment je voulais le faire et avec quoi je voulais le faire.

Dans cet article, je vais faire une synthèse de l'utilisation de mon serveur à la maison, les applications que j'utilise le plus, les choses que je recommande et que je déconseille, fort de ces 2 ans d'expérience. Vous pourrez peut-être y découvrir des applis et/ou piocher des idées ;)

Partie matérielle

Un retour d'abord sur mon serveur à proprement parlé (le côté matériel). Pour mémoire, j'avais choisi cette configuration. Depuis, j'ai juste acheté un disque dur 2.5" supplémentaire pour faire mes sauvegardes (mon boîtier peut accueillir 2 disques durs).

Pour faire court, je suis extrêmement satisfait de cette configuration. Mes 1Go de RAM me suffisent amplement, mon CPU n'est jamais trop chargé, mon disque dur n'explose pas, le boîtier est complètement silencieux, bref, tout est parfait. Le seul point d'engorgement que j'ai c'est ma bande passante (j'ai 100kb/s en upload, cela devient, de temps en temps, trop peu).

Un collègue à moi souhaite se mettre à l'auto-hébergement, je lui ai donc recommandé le même genre de configuration que la mienne (je dis le même genre car ma carte mère n'est plus disponible à la vente semble t-il). Il souhaite faire en plus du Tomcat, je pense que ça tiendra largement la charge (avec 1Go de RAM en plus au cas où).

Partie logicielle

Sécurité

Concernant la sécurité de mon serveur, j'ai été agréablement surpris. Les outils que j'ai mis en place (fail2ban, la sécurisation de mon PHP, le changement du port SSH et quelques autres broutilles) ont largement suffit. Ceci dit, je reste toujours très vigilent sur les applications que je mets en place et les maintiens toutes à jour (applications ou OS). D'ailleurs, la semaine dernière, j'ai du bannir une IP (via les iptables) qui s'amusait à télécharger 200 fois le même fichier sur une période plusieurs heures. Comme quoi, il faut vraiment rester vigilent :)

Sauvegardes

Pour mes sauvegardes, voici ce que j'avais mis en place : sauvegarde de mes bases de données et des répertoires importants de mon serveur (/etc, /var/www, etc.). C'est bien connu, on ne se rends compte du bienfait des sauvegardes en cas de pépin uniquement. Depuis 2 ans, je n'ai eu besoin d'avoir recours à ces sauvegardes qu'une seule fois, il y a 1 mois, quand une mise à jour Piwik s'est mal passée, tout mon système de stats était planté, j'ai donc pu revenir en arrière grâce à mes sauvegardes de la veille.

Pour résumer, je sauvegarde mon /var/www ainsi que les dumps MySQL et tout mon /home/ sur le deuxième disque dur de mon boîtier (en rsync, toutes les nuits). Je fais également une sauvegarde du /var/www et les dumps MySQL sur une clé USB branchée en permanence sur le serveur (une fois par mois).

Applications

Voici la liste des applications que j'utilise chez moi. Je vais m'attarder sur les plus importantes et lister les autres en vrac par la suite :

Lecteur RSS

Mon lecteur de flux RSS est l'application que j’utilise le plus sur mon serveur. Je l'utilise plusieurs fois par jour sans exception. À la mise en place de mon serveur, j'utilisais Tiny Tiny RSS pour lire mes flux RSS. L'application était plutôt sympa mais je lui reprochait deux choses : une certaine lourdeur à l’exécution et surtout une consommation de base de données excessive. Au bout de quelques mois, ma base de données atteignait plusieurs centaines de Mo. C'était ingérable à plus long terme, j'ai donc cherché autre chose et je suis tombé sur une perle : RSS Lounge !

Je trouve RSS Lounge parfait. Il est simple à installer, très léger, gère les raccourcis claviers et surtout ne consomme presque rien en base de données (on voit bien que les vieux flux sont purgés de la base, contrairement à TTRSS). À titre de comparaison, je l'utilise depuis plus d'un an et demi et ma BDD pèse seulement 1,50Mo !

Malheureusement, le développeur a abandonné le projet au profit de selfoss. J'ai testé ce dernier, je n'aime pas du tout. Du coup, je reste sur RSS Lounge pour le moment (et certainement pour un bon bout de temps). J'espère que le projet sera forké :)

Lecteur de musique

Le deuxième service que j'utilise le plus après RSS Lounge est mon lecteur de musique. En effet, quand je suis au boulot, j'ai quasiment toujours mon casque sur les oreilles avec de la musique. Je n'écoute pas la radio (sauf parfois Streaming Soundtracks), je n'écoute que mes musiques. Mes musiques étant stockées chez moi (sur mon serveur justement), j'ai du chercher un logiciel qui me les diffusent sur Internet. J'ai trouvé mon bonheur il y a quelques années : Subsonic. Ce logiciel est vraiment une tuerie ! Il me joue mes fichiers musicaux et vidéos en streaming (peut importe le dossier où ils se trouvent sur mon serveur), me télécharge mes poadcasts tous les jours, me génère des playlists aléatoires en piochant dans tous mes albums, etc. Et le fin du fin, j'ai une application Android qui permet de lire mes musiques partout avec mon téléphone :)

Blogs / Sites

Mon serveur héberge pas mal de sites web et de blogs. Depuis que je l'ai, j'ai récupéré quasiment l'intégralité de ces sites hébergés par-ci par-là. Il y a différents CMS :

Dotclear pour ce blog et mon blog perso ;
Wordpress pour le blog de ma chérie, un blog sur notre bébé que nous tenons pour notre famille et le site d'une association ;
Moonmoon pour le planet Raspberry Pi.

Wiki

Comme j'ai une mémoire de mouche, j'ai toujours pris l'habitude de documenter tout ce que je fais (en informatique). Du coup, dès que j'ai mis en place mon serveur, j'ai installé un système de wiki dokuwiki pour pouvoir tout documenter. J'adore dokuwiki, le fait qu'il n'utilise pas de base de données, qu'il soit régulièrement mis à jour (et que je l'ai mis en place à l’université où je travaille) y sont pour quelque chose :) Je l'utilise également pour mes notes personnelles. Bref, un indispensable là encore !

Divers

J'ai mis une webcam sur mon serveur (qui se trouve dans le salon). Ainsi, avec le logiciel motion (que j'avais utilisé sur mon Raspberry Pi), je peux regarder ma chérie et mon bébé dans le salon pendant que je suis au boulot.
Je suis un grand lecteur de comics, je les télécharge et les lis sur mon ordinateur. Un jour, je me suis demandé si je ne pouvais pas avoir mes comics sur mon serveur avec une application de lecture de comics en ligne. J'ai trouvé mon bonheur avec php-cbviewer. Cette application va extraire et lire les fichiers cbr à la volée, c'est super pratique !

J'ai fait un petit script qui va extraire mes logs d'erreur apache et me les transformer les dernières lignes en une page HTML toutes les 5 minutes. Ainsi, je peux accéder à mes logs depuis n'importe quel navigateur, même si je ne dispose d'aucun accès SSH. Par ailleurs, tout est agrégé dans cette même page, cela me permet donc d'avoir une vue d'ensemble rapidement.
J'ai codé une petite page HTML qui me sert de page d'accueil sur tous mes navigateurs. J'y ai mis des liens vers les principaux sites sur lesquels je vais ainsi qu'un champ de recherche Google. Je ne peux plus me passer de cette page (merci à HacKurz pour la bonne idée) :)

J'utilise Piwik pour afficher mes statistiques d'accès à mes différents sites web. La base de données de piwik va bientôt atteindre les 1Go, il va falloir que je regarde pour purger tout ça.

Il me fallait une application d'upload de fichiers rapide (un exemple d'utilisation, j'upload via une interface web un PDF sur mon serveur et je donne le lien pour qu'un ami le télécharge). J'utilise pour cela une petit appli toute simple KOLoad. Cette appli liste le contenu d'un répertoire et permet d'y uploader où d'y télécharger un fichier. On peut faire en sorte que l'accès soit public ou privé. C'est simple, c'est bien :)

Un bon serveur a toujours son système de téléchargement. J'utilise le plus connu d'entre eux : transmission. L'avantage de transmission est qu'il est simple d'utilisation et possède une interface web super sympa. Du coup, je peux mettre des trucs à télécharger depuis n'importe où.

Applications/Services abandonnés

Voici une liste des services que j'ai installé, utilisé puis abandonné :

Owncloud : j'ai testé la version 5, je la trouve vraiment beaucoup trop lourde, pas très jolie et buggée. Bref, je n'en suis pas satisfait et ne l'utilise plus ;
ma galerie photos : j'avais mis en place une galerie photos sur mon serveur (grâce à iGalerie). Je me rends compte au final qu'elle n'est jamais utilisée, je vais donc la supprimer. Je ne pense pas la remplacer. Il n'y a pas beaucoup de photos que je souhaite mettre en ligne finalement ;
Tiny Tiny RSS : Pour les raisons que j'ai évoqué plus haut dans l'article ;
SimpleID : J'avais présenté SimpleID dans cet article. Il permet d'être son propre fournisseur d'identité OpenID. Force est de constater qu'OpenID ne se repends pas sur le web, je ne l'utilise donc plus non plus (je crois que j'ai du l'utiliser une seule fois "en vrai" depuis que je l'ai mis en place (il y a 2 ans)) ;
ejabberd : Le fameux serveur XMPP. J'utilisais ce serveur Jabber pour faire un tchat intégré à un site (avec Jappix Mini). Le site à été modifié, le tchat supprimé et je ne me sers plus de mon server Jabber (je ne communique pas en messagerie instantanée).

Projets/améliorations à venir

Voici les choses que j'aimerais faire cette année :

Chiffrage des données

C'est quelque chose que je souhaite faire depuis pas mal de temps : chiffrer les données sensibles présentes sur mon serveur. Je n'ai jamais pris le temps de regarder comment cela marchait. Après quelques recherches, mon choix s'est porté sur Truecrypt. Je vais avoir deux cas d'utilisations avec mes futurs projets (voir juste en dessous).

Politique de sauvegarde

Un point très important pour l'auto-hébergement, c'est la sauvegarde. Cela m'a toujours trotté dans la tête, j'ai toujours voulu avoir une politique de sauvegarde complète pour mon serveur et mes données.

Comme je l'ai déjà dit, mon serveur est actuellement composé d'un disque dur "principal", d'un autre disque dur sur lequel sont répliqués les répertoires les plus importants du premier (via Rsync) et une clé USB branchée en permanence qui contient les backups importants (MySQL + www). Il y a 2 problèmes à ce système :

d'une part, si mon appartement brûle ou est cambriolé, je perds tout ;
d'autre part, si quelqu'un vient simplement prendre la clé USB branchée au cul du serveur, il repart avec tout mon serveur MySQL sous le coude...

Pour résoudre ces problèmes, j'ai commencé un projet : le cryptage et l'externalisation de mes backups :

je vais externaliser mes sauvegardes chez mes beaux parents (à 100km de là) grâce à un disque dur externe chiffré et branché sur un Raspberry Pi accessible depuis chez moi uniquement ;
je vais chiffrer tous mes supports de sauvegarde.

Je ferai un article bien plus complet et précis sur tout ça quand ça sera en place. J'ai commandé 8 Raspberry Pi ce matin, dans 15 jours ça sera bon :)

Synchronisations de mes dossiers

Owncloud et SparkleShare ne m'ont pas convaincu (j'explique ici pourquoi), mais je n'ai pas perdu l'envie de synchroniser des répertoires avec mon serveur et mes différents PC. Je pense donc faire cela avec Unison (ou SSHFS si Unison ne me convient pas). À suivre donc.

Héberger mes mails

J'ai mon serveur depuis plus de deux ans et je n'héberge toujours pas mes mails. Peur de la disponibilité de mon serveur et surtout mauvaise maîtrise des logiciels. Je voudrais bien sauter le pas tout de même. Pour cela, il faut que je me documente et que je comprenne un peu les rouages de Postfix & Co. Je ne veux pas juste suivre un tuto pas à pas, je veux comprendre tout ça et ça prends du temps. Dès que j'en ai, je m'y attelle :)

Dématérialiser mes documents administratifs

Je n'ai jamais réussi à ranger correctement les papiers importants. J'ai juste une grosse pile de papiers dans laquelle je remets le nez quand j'ai besoin d'un papier en particulier. Ça me gonfle à chaque fois. J'ai donc pensé scanner tout ça et les ranger correctement sur mon serveur. Cela implique de chiffrer l'ensemble. Je ne pense pas utiliser de logiciel de GED pour tout gérer, un simple SSHFS sera suffisant pour déposer ou récupérer ces papiers quand j'en aurai besoin. Petit problème, je n'ai aucune idée de la volumétrie nécessaire pour stocker tout ça.

Conclusion

Voila pour un petit retour de l'utilisation de mon serveur. Comme vous le voyez, il me reste encore plein de projets en tête. Comme d'habitude, tout sera documenté et expliqué sur ce blog. J'espère que cet article vous aura fait découvrir des choses et/ou donné des idées. Si vous avez des questions ou des remarques, comme d'habitude, n'hésitez pas ;)

Installation d'un serveur Sparkleshare sur Debian et d'un client Sparkleshare sur Ubuntu

Benjamin — Wed, 20 Mar 2013 22:35:00 +0100

Depuis quelques temps, j'ai en tête un "projet" que j'aimerais bien mettre en place chez moi : un cloud personnel. Ayant un serveur@home avec deux disques durs (avec réplication de l'un sur l'autre), je souhaitais en faire un serveur de stockage de mes données (présentes sur plusieurs PC fixes et portables) via un logiciel de cloud. Au départ, j'ai testé Owncloud (version 5) mais je n'ai pas été convaincu donc j'ai cherché un autre logiciel. Le deuxième plus "connu" est Sparkleshare, j'ai décidé de le tester.

Voici comment j'ai installé le serveur sur une Debian Squezze et le client sur une Ubuntu 10.04 et une 12.04. Je vous donnerai ensuite mes impressions sur cette solution.

I. Serveur

Installation

Nous allons utiliser un assistant très pratique pour installer et configurer le serveur Sparkleshare. Cet assistant s'appelle dazzle. Pour l'obtenir, il suffit de lancer cette commande (en tant que root) :

curl https://raw.github.com/hbons/Dazzle/master/dazzle.sh --output /usr/bin/dazzle && chmod +x /usr/bin/dazzle

Une fois installé, vous devez utiliser la commande dazzle pour configurer le serveur :

dazzle setup

L'assistant effectuera toutes les actions nécessaires pour la mise en place de Sparkleshare :

Vérification de la présence de git et installation si nécessaire
Création d'un compte utilisateur "storage" qui sera utilisé pour utiliser Sparkleshare
Configuration du compte "storage" (en particulier des accès SSH, car tout se fait en SSH)
Rechargement du serveur SSH

Note : À ce moment, j'ai eu une erreur avec mon serveur SSH. Il refusait de redémarrer et m'affichait l'erreur suivante :

/etc/ssh/sshd_config line 93: Directive 'AuthorizedKeysFile' is not allowed within a Match block

Il s'agit d'une erreur due aux lignes ajoutées par Sparkleshare à la fin du fichier /etc/ssh/sshd_config (utilisée pour l'accès SSH au compte "storage"). Après pas mal de recherches, je me suis rendu compte que l'erreur était due à la version de mon openssh-server. Sur ma Debian Squeeze, la version installée était la 5.5 (1:5.5p1-6+squeeze3). La configuration ajoutée par Sparkleshare n'est compatible qu'avec la version d'openssh-server 6.x.

Pour remédier à ce problème, j'ai dû mettre à jour mon openssh-server via les dépôts testing de Debian (ce qui a nécessité une mise à jour du paquet libc6-dev) au passage. Cela a installé la version 6 (1:6.0p1-4) d'openssh-server et cela a résolu mon problème.

Configuration

Maintenant que mon serveur est installé, j'ai créé (toujours via dazzle) un répertoire destiné à accueillir mes données à synchroniser. Pour ce faire, il faut utiliser la commande suivante :

dazzle create DOSSIER

ou en crypté :

dazzle create-encrypted DOSSIER_CRYPTE

Voici le résultat de la commande :

Creating encrypted project "DOSSIER_CRYPTE"...
-> /usr/bin/git init --bare /home/storage/DOSSIER_CRYPTE-crypto
-> /usr/bin/git config --file /home/storage/DOSSIER_CRYPTE-crypto/config receive.denyNonFastForwards true
-> echo "*.DMG -delta" >> /home/storage/DOSSIER_CRYPTE-crypto/info/attributes
-> chown --recursive storage:storage /home/storage
-> chmod --recursive o-rwx /home/storage/DOSSIER_CRYPTE-crypto

Project "DOSSIER_CRYPTE-crypto" was successfully created.
To link up a SparkleShare client, enter the following
details into the "Add Hosted Project..." dialog:

Address: ssh://storage@mon_ip:mon_port
Remote Path: /home/storage/DOSSIER_CRYPTE-crypto

To link up (more) computers, use the "dazzle link" command.

On voit que le dossier est créé dans le répertoire /home/storage (qui est la homedir de notre utilisateur storage).

Voila, la partie serveur est presque terminée, il faudra faire une dernière action lors de la configuration de notre client mais nous verrons cela plus bas.

II. Client

Installation

Sparkleshare n'est pas officiellement packagé pour Ubuntu dans ses versions 10.04 jusqu'à 11.10. Ceci dit, un dépôt PPA est disponible (compatible avec Ubuntu 10.04 -> 11.10). Il ne s'agit pas des dépôt officiels, aussi, installez-le en connaissance de cause. Vous devez l'ajouter et lancer l'installation grâce à ces commandes :

sudo add-apt-repository ppa:warp10/sparkleshare sudo apt-get update sudo apt-get install sparkleshare libwebkit1.1-cil git-core python-nautilus

Depuis la version 12.04, tout est packagé de base, donc cette commande sera suffisante :

sudo apt-get install sparkleshare libwebkit1.1-cil git-core python-nautilus

Configuration

Le premier lancement du client vous permettra de renseigner quelques informations (nom, prénom, adresse mail) et vous affichera un petit tuto. Une fois passé cette présentation, il va falloir "relier" le client avec le serveur. Pour cela, récupérez le contenu du fichier présent dans le répertoire SparkleShare de votre homedir (il s'agit de la clé publique du client). Retournez sur le serveur puis lancez la commande suivante :

dazzle link

Après avoir appuyé sur Entrée, vous n'avez plus qu'à coller la clé publique de votre client, valider une dernière fois et le tour est joué.

Dernière étape, l'ajout du nouveau dépôt (le répertoire que nous avons créé ci-dessus) sur le client. Pour cela, il suffit de cliquer sur l'icône Sparkleshare de votre zone de notification puis "Ajouter un projet hébergé" :

Choisissez ensuite "on my own server" (notez que vous pouvez vous brancher sur des serveurs git publics tels que Github) puis renseignez l'adresse de votre serveur et le répertoire de destination (il s'agit des données que vous avez eu lors de la configuration du répertoire sur le serveur) :

Address: ssh://storage@mon_ip:mon_port
Remote Path: /home/storage/DOSSIER_CRYPTE-crypto

Après avoir validé, vous avez accès à votre répertoire (qui sera synchronisé avec tous les clients en temps réel).

Note : Je n'ai pas testé les clients Mac et Windows mais je suppose que l'installation et surtout la configuration sont à peu près identiques.

III. Conclusion

Sparkleshare est un très bon logiciel. Les échanges sont chiffrés (via SSH), rapides, l'installation n'est pas trop difficile et c'est basé sur git. Malheureusement, le gros point noir qui est vraiment rédhibitoire pour moi c'est que je ne peux pas retrouver mes fichiers directement sur le serveur. Dans le fameux répertoire créé sur le serveur, tout est hashé, crypté, bref, complètement inutilisable :

Autrement dit, il faut obligatoirement avoir un client pour accéder aux données. Moi je voulais pouvoir avoir les données disponibles depuis les clients mais également directement sur mon serveur. Sparkleshare ne propose pas cela.

C'est la raison pour laquelle je n'irai pas plus loin dans mon utilisation de cet outil. Il faut que j'en trouve un autre. Si vous avez des idées, faites-moi signe :)

Edit : Du coup, voici ce que j'ai fait pour supprimer Sparkleshare :

userdel storage rm -rf /home/storage/ rm /usr/bin/dazzle #Modification du fichier /etc/ssh/sshd_config pour supprimer les liens avec /home/storage puis : /etc/init.d/ssh reload

GIT reste installé sur le serveur mais ça c'est pas bien grave.

L'auto-hébergement, n'est-ce seulement qu'un truc de geek ?

Benjamin — Sun, 07 Aug 2011 20:52:00 +0200

J'avais envie de faire un petit état des lieux de ce qu'est l'auto-hébergement à l'heure actuelle. Cet article fait suite à celui où je vous demandais vos témoignages et votre façon de vous auto-héberger. Ici, je vais exposer mon point de vue et tenter de déterminer si, à l'heure actuelle, l'auto-hébergement n'est (ou pas) qu'un truc de geek barbu puis j'essayerai de voir comment faire pour que l'auto-hébergement se démocratise encore plus, en particulier chez les novices.

I. L'auto-hébergement, ça date de quand ?

Par définition, l'auto-hébergement date de la création de l'Internet. Au début de l'Internet, la plupart des clients étaient également serveurs. À cette époque, il n'y avait que très peu de centralisation de services.

Assez rapidement, les entreprises se sont "accaparées" cet outil (Internet) et y ont mis des ressources à disposition pour permettre à n'importe qui, novice ou professionnel, de créer son adresse mail, d'avoir un espace perso ou un blog rapidement, facilement et gratuitement. Au fil du temps, les activités de ces entreprises ont malheureusement pris des proportions de plus en plus importantes et inquiétantes.

Certains utilisateurs ont commencé à se rendre compte du potentiel danger de laisser leurs informations personnelles sur des machines qu'ils ne pouvaient contrôler, perdant ainsi tout contrôle quant à l'utilisation qu'il était faite de leurs données. Certains se sont rendus compte de cela par eux-mêmes, depuis très longtemps, d'autres (comme moi) s'en sont rendu compte suite à une conférence de Benjamin Bayart, Internet libre, ou Minitel 2.0 présentée (et enregistrée) aux 8e rencontres mondiales du logiciel libre, à Amiens, le 13 juillet 2007.

La bonne parole continue de se répandre, ce qui fait que 4 ans après cette conférence, l'auto-hébergement se démocratise toujours de plus en plus et fait de plus en place parler de lui.

II. Est-ce une nécessité pour tout le monde ?

Note : ce que je vais dire ci-dessous n'engage que moi, je comprendrai que d'autres personnes n'adhèrent pas à mes convictions. On peut en débattre dans les commentaires.

L'auto-hébergement est-il une nécessité pour tout le monde ? La logique voudrait que oui, que chacun ait son serveur chez lui, que tous les services soient décentralisés.

Oui mais non.

Évidemment, je pense que l'auto-hébergement ne doit pas s'adresser uniquement aux personnes souhaitant à tout prix protéger leur vie privée. Néanmoins, demander à tout le monde de s'auto-héberger n'est pas non plus la meilleure idée.

Un exemple tout simple : admettons qu'une personne souhaite juste mettre en ligne une vidéo, rien d'autre. L'auto-hébergement ne se justifie pas forcément. Nous savons que les débits actuels de nos lignes ADSL (en particulier l'upload) ne nous permettent pas de mettre correctement des vidéos à disposition. Ici, l'auto-hébergement ne serait vu que d'une manière négative (le coût du serveur, la difficulté de mise en place d'un système de streaming, la disponibilité du service et le faible débit).

Cependant, comme je le disais, l'auto-hébergement ne doit pas être réservé qu'à ceux qui font très attention à leur vie privée. Combien de fois j'ai entendu "moi, je m'en fiche de tout mettre ailleurs que chez moi, j'ai rien à me reprocher". Je trouve cet argument très bête.

Alors où est la limite ? Quand doit-on franchir le pas ?
Les avis divergeront toujours sur cette question, c'est une question de point de vue. Pour ma part, je pense que dès qu'un internaute devient auteur sur Internet, qu'il possède un blog, qu'il a des choses à dire, que ce soit pour héberger son blog personnel avec ses photos de vacances ou bien de faire un site critiquant méchamment la Société et ses dirigeants, c'est la même chose. Dès lors que l'internaute veut mettre du contenu sur Internet, il doit, selon moi, s'auto-héberger.

III. Est-ce vraiment à la portée de tous ?

On ne va pas se mentir, à l'heure actuelle, l'auto-hébergement n'est pas du tout à la portée de tout le monde. Aujourd'hui, seuls les geeks et/ou informaticiens (en général pro-linux) s'auto-hébergent. La plupart des gens ne savent simplement pas qu'il est possible d'avoir son blog, son site ou ses mails chez soi. Ceux qui le savent ne voient pas forcément l'intérêt de s'auto-héberger, ceux qui le voient, ne savent pas forcément comment le faire.

Il faut donc réunir plusieurs éléments pour qu'une personne fasse la démarche de s'auto-héberger :

Qu'elle sache qu'il est possible de le faire
Qu'elle sache pourquoi le faire
Qu'elle sache comment le faire

IV. Que peut-on faire pour changer cela ?

Je vais reprendre les trois arguments évoqués ci-dessus.

Savoir qu'il est possible de le faire

La plupart des internautes n'ont aucune notion du fonctionnement de l'Internet. Combien de fois j'ai entendu des questions du genre "ce site là, je l'ai sur mon ordinateur, mais Michel il peut aussi l'avoir sur le sien ?"...
Alors bien sûr, on ne leur demande pas de connaitre les 7 couches du modèle OSI mais connaître la notion de client-serveur serait, je pense, un minimum. Ainsi, les gens se rendraient compte qu'un serveur c'est pas forcément une machine énorme comme on voit dans les films, ça peut aussi être un simple ordinateur tout droit récupéré de la décharge (merci Khady pour la photo de ton serveur) et que donc, chacun est capable d'avoir son serveur à moindre frais.

Savoir pourquoi le faire

Pourquoi s'auto-héberger ? Je vais indiquer ici les principales raisons (reprises du compte rendu de vos témoignages) :

Garder le contrôle sur ses données
Curiosité, apprentissage
Faire du vrai Internet
Indépendance, liberté
Avoirs ses fichiers à disposition partout
C'est cool et amusant
Le prix (c'est moins chez de faire de l'auto-hébergement que de louer un serveur dédié)
Choix et qualité des services (pas de pub, PHP 5, etc.)

Alors bien sûr, ce sont là des raisons d'informaticien, qui, la plupart du temps ont déjà leur propre serveur. La Madame Michu n'aura pas tout à fait les mêmes raison de s'auto-héberger.
Là encore, c'est à nous de définir quelques bonnes raisons irréfutables, simples à expliquer et à illustrer (je pense notamment à la publicité de Gmail Man). Par la suite, il ne reste qu'à faire un maximum de publicité autour de nous, sur nos sites, dans nos commentaires, nos repas de famille, nos conversations entre amis, etc.

Certes, la route est longue, mais n'en vaut-elle pas la peine ?

Savoir comment le faire

Une fois que la personne sait qu'un serveur est une machine comme les autres et qu'elle peut en avoir un chez elle pour héberger ses services, la question qui vient est la suivante : "Comment je fais pour m'auto-héberger ?". Je pense à ça notamment suite à un mail d'Antoine sur la liste de diffusion auto-hébergement :

Bonjour,
Je souhaite me lancer dans un site web auto hébergé.
Je cherche des documents et tuto pour apprendre.
J'ai du mal pour trouver des tutos bien fait sur le net qui expliquent tout de A à Z.
Avez vous un livre ou des liens avec des explications facilement compréhensible par un débutant ?
Merci
Antoine

Il convient, ici, de distinguer 2 populations, les informaticiens et les non-informaticiens.

Pour les informaticiens, tous les tutoriels existent déjà sur Internet. Le plus difficile est de savoir par où commencer. Là, je n'ai pas de réponse toute faite. En fait, tout va dépendre des besoin de l'utilisateur. Toujours est-il qu'un bon point de départ peut être le wiki auto-hébergement. J'ai également trouvé, il y a quelques mois, un PDF de 69 pages qui explique l'installation de très nombreux logiciels auto-hébergés (un lecteur de musique, un hébergeur d'images, un outils de statistiques, un forum, un serveur jabber, etc.). Ce petit livre a été écrit par l'auteur du site FreelyDifferent. Enfin, il y a aussi pas mal de documentation sur le wiki de Beedbox, en particulier dans la catégorie Beedbox from scratch. Et bien sûr, il y a aussi la liste de diffusion auto-hébergement sur laquelle je vous invite à écrire et répondre.

Pour les non-informaticiens, c'est à nous, informaticiens, de leur proposer des outils accessibles, rapides et simple d'utilisation. C'est là qu'interviennent des projets comme BeedBox. Je vous en ai déjà parlé, BeedBox est un projet de création d'une distribution dédiée à l'auto-hébergement "pour les nuls". Cette distribution sera disponible au téléchargement, pour permettre à ceux qui ont déjà un serveur perso de l'installer sur celui-ci, mais elle sera également distribuée avec un petit serveur, prêt à fonctionner "out of the box". L'utilisateur n'aura donc plus qu'à brancher ce petit serveur sur sa box, à configurer son ou ses comptes utilisateurs via une interface web et voilà tout. Tout sera ensuite disponible, parfaitement fonctionnel et utilisable immédiatement (un serveur mail perso, serveur web avec, par exemple, un moteur de blog intégré, un système de partage de photos, de vidéos, un lecteur de flux RSS, etc.).
Si ce projet vous intéresse, que vous souhaitez y participer ou même simplement suivre son état d'avancement, je vous invite fortement à aller faire un tour sur le forum de BeedBox. Une communauté super sympa vous y attends ;)

V. Conclusion

Nous l'avons vu, évidemment que l'auto-hébergement n'est encore qu'un truc de geek. Ceci dit, de plus en plus de geeks s'y mettent, ce qui est très encourageant. Je vois assez souvent des articles fleurir "Mes premiers pas vers l'auto-hébergement". Le dernier en date est celui de Sciunto "Premiers pas vers l'auto-hébergement". Quand tous les geeks s'auto-hébergeront, les utilisateurs novices s'y mettrons également.

Par ailleurs, à mon avis, avec ces lois toujours plus liberticides qui sont en train d'être adoptées par nos chers députés tous plus incompétents les uns que les autres, l'auto-hébergement passera d'un statut de "phénomène de mode/geek" à celui d'une nécessité indispensable à la liberté d'expression. Les plus optimistes verront le côté positif de cette phrase, les autres y verront le côté négatif. C'est l'histoire du verre d'eau, vous savez ;)

rssLounge, un excellent gestionnaire de flux RSS !

Benjamin — Sat, 02 Jul 2011 14:46:00 +0200

J'utilise Tiny Tiny RSS depuis déjà quelques temps. Quand je cherchais des alternatives à Netvibes (début 2009), Tiny Tiny RSS m'avait semblé être le meilleur outil disponible pour lire ses flux RSS à partir de son serveur (toujours dans mon optique d'auto-hébergement).

Après avoir lu l'article de ®om, je me suis rendu compte que pas mal de gens se plaignaient de TTRSS (pour des raisons que j'évoquerai dans cet article) et préféraient rssLounge. Étant également un peu insatisfait de TTRSS (j'en parlerai là aussi plus en détail), j'ai décidé de tester rssLounge. Un excellent logiciel que j'ai adopté et que je vous invite à découvrir :

I. Le changement

Je vais tout d'abord vous détailler les raisons qui m'ont fait abandonner Tiny Tiny RSS au profit d'une nouvelle solution de gestion de flux RSS :

Le temps de chargement : c'est l'inconvénient qui revenait le plus souvent (forcément), je viens de chronométrer, Tiny Tiny RSS met précisément 9 secondes entre le temps où je valide mes identifiants et où l'application est opérationnelle. 9 secondes ça peut paraitre peu, mais pour un temps de chargement de page web, je vous assure que c'est énorme ! Par ailleurs, la navigation au sein des différentes catégories, des flux RSS ou dans la configuration est assez longue également.
L'espace pris par la base de données : Mon installation actuelle de TInty Tiny RSS date d'un peu plus de 6 mois et ma base de données fait déjà 60 Mo ! Alors j'ai bien vu qu'il y avait une option de purge. Cependant, comme je l'ai évoqué ici, je n'ai pas réussi à la faire fonctionner (et c'est pas faute d'avoir essayé). J'avais beau mettre une purge pour les articles plus vieux de 3 jours, j'avais encore tous mes articles en base de données...
L'installation pénible : J'ai trouvé cela pénible de devoir, lors de l'installation, créer sa base de données et la peupler "à la main" avec un banal fichier .sql. Un installeur est simple à mettre en place, je n'ai pas compris pourquoi il n'y en avait pas.
Un système de mise à jour des flux pas très intuitif : J'ai trouvé le système de mise à jour des flux assez "difficile" à comprendre et n'est pas très bien expliqué dans la documentation officielle.

Ce sont donc les principales raisons qui m'ont fait abandonner Tiny Tiny RSS. Comme vous pouvez le constater, ce ne sont pas des problèmes bloquants, mais c'est juste que mis les uns à la suite des autres, l'utilisation finale ne devient plus très agréable.

J'ai donc décidé de tester rssLounge.

II. Fonctionnalités

Voici ses principales caractéristiques traduites du site officiel :

Un lecteur RSS très complet
Permet de définir des priorités pour des flux et n'afficher que certaines priorités (et donc certains flux)
Supporte les images et photos, et permet de suivre facilement les photoblogs et les sites du genre deviantart, flickr, tumblr
Une belle interface (ajax), très intuitive et facile à utiliser (drag & drop, etc.)
Un système de plugins pour définir de nouvelles sources de données, permettant ainsi de suivre des pages ne supportant pas les RSS
Possibilité de définir des expressions régulières pour filtrer les messages
Supporte les mises à jour ajax et via crontab
Import/export OPML
Multilingue

Voici un screenshot de mon rrsLounge actuel (où on peut voir un photoblog (tumblr) en haut des articles). Cliquez pour agrandir :

III. Installation

Pour commencer, il faut aller récupérer l'application sur le site officiel puis le mettre en place sur un serveur web. Pensez à donner les droits d'apache sur votre répertoire (chown -R www-data:www-data /var/www/rss). Il n'y a plus qu'à aller sur l'URL en question. Un installeur s'affiche.

Ici, j'avais 2 erreurs, j'ai voulu vous les montrer pour que vous sachiez comment faire si vous les rencontriez. La première, mod_rewrite non chargé c'est parce que le fichier .htaccess de votre application n'est pas interprété. Dans le répertoire de rssLounge, il y a un fichier .htaccess indispensable.
Chez moi, c'est parce que dans ma configuration apache, j'avais AllowOverride None (qui empêche l'interprétation d'un fichier .htaccess). Je l'ai changé pour AllowOverride All.

La deuxième erreur m'annonce qu'il me manque l'extension GD pour PHP. En général, cette extension est packagée, j'ai donc simplement fait un apt-get install php5-gd.

Je redémarre le serveur apache et voilà :

L'installeur me demande les identifiants de la base de données (il faut que vous ayez déjà créé une base de données vide) puis plus bas (non affiché ci-dessus), me demande un nom d'utilisateur, un mot de passe et une case à cocher pour savoir sur rssLounge doit être public (accessible à tous sans mot de passe) ou privé (accessible uniquement avec un mot de passe).
J'ai choisi privé et ai validé.

C'est déjà fini, il ne me reste plus qu'à aller sur rssLounge :

Je rentre les identifiants et arrive sur la page de mon rssLounge vide :

L'installation est déjà terminée !

Récupération des flux

Il y a 2 manières de récupérer les flux. Si vous n'avez pas mis en place d'automatisation de récupération des flux, les flux seront mis à jour au moment où vous vous connecterez sur rssLounge (c'est bien pratique quand on a pas accès à la configuration du cron sur son serveur).

Pour mettre les flux à jour automatiquement, il suffit de déclarer une ligne dans la crontab :

*/30 * * * * curl http://<rsslounge url>/update/silent >/dev/null 2>&1

Cette ligne va lancer toutes les 30 minutes un appel via curl à la mise à jour de rssLounge. Notez qu'il faut que curl soit installé sur votre machine (apt-get install curl).

IV. Migration de Tiny Tiny RSS vers rssLounge

Avant d'aller plus loin dans la découverte de l'outil, je vais rapatrier mes flux RSS de Tiny Tiny RSS vers rssLounge. Pour cela, je vais utiliser l'import/export OPML disponible dans TTRSS et rrsLounge.

Export

Dans Tiny Tiny RSS, je vais dans "Configuration" puis l'onglet "Flux" et "OPML". Je clique sur "Exporter en OPML" puis enregistre le fichier opml.php sur mon Bureau.

Import

Je vais maintenant importer mes flux dans rssLounge. Il suffit de cliquer sur l'icône des préférences (en haut à droite, les rouages) puis de cliquer sur "OPML Import".
Il ne reste qu'à choisir le fichier OPML.php et rssLounge importe tout ça, c'est très simple :

Le rendu une fois terminé (cliquez sur l'image pour agrandir) :

V. Présentation

Maintenant que j'ai de la matière, je vais pouvoir vous présenter les possibilités de cette application.

Affichage des différents flux

Par défaut, les flux les plus récents et non lus seront affichés en tête de liste. Vous pouvez choisir de n'afficher que les flux non-lus ou tous les flux, dans l'ordre que vous voulez.

Une fonctionnalité assez intéressante est celle du calendrier. Si vos flux ne sont pas purgés, vous pouvez cliquer sur le calendrier en haut à gauche pour afficher les flux d'un jour en particulier (ou d'une tranche de jours) :

Ajout de flux

En cliquant sur "Ajouter un flux" en haut à gauche, vous afficherez cette fenêtre d'ajout :

Sur la gauche, vous pouvez choisir le type de flux que vous voulez ajouter (RSS simple, images, etc.). Vous renseignerez aussi le nom du flux, son URL, sa catégorie (j'en parlerai après), sa priorité (vous pouvez ensuite n'afficher que les flux de priorité comprise entre 3 et 5 par exemple), mettre l'URL d'un favicon (bien que celui-ci soit en général récupéré automatiquement) et positionner un filtre.

Pour paramétrer rssLounge, il faut cliquer sur la petite icône en forme de rouage en haut à droite de la fenêtre :

Gestion des catégories

Comme je l'ai dit juste au dessus, en ajoutant un flux RSS, on peut choisir de l'ajouter dans une catégorie. Voici l'interface de gestion des catégories :

Là encore, tout est très intuitif.

Gestion des paramètres

Contrairement à Tiny Tiny RSS, il y a peu d'options dans rssLounge, uniquement l'essentiel, c'est très appréciable :

Comme vous le voyez, là encore, tout est très intuitif et très simple. Ça se passe même d'explication :) La souscription aux flux présentée tout en bas est vraiment très pratique !

Concernant l'anomyzer, il semblerait que l'option permette de récupérer les flux via anonym.to. Du coup, le site accédé ne peut pas connaitre l'origine de la requête et permet donc a rsslounge d’être "anonyme" (merci thom).

VI. Mes impressions

Voici mes impressions, un peu en vrac, de mon utilisation de rssLounge (que j'utilise depuis maintenant 2 semaines).

rssLounge est très simple à installer et à paramétrer (contrairement à Tiny Tiny RSS)
La navigation est très rapide, que ce soit au démarrage, à la lecture, au changement des catégories, etc. (contrairement à Tiny Tiny RSS)
Une base de données qui prend très peu de place. Actuellement, j'ai gardé tous mes flux depuis 15 jours et j'en suis à 3Mo de BDD. Pour tester, j'ai purgé mes articles plus vieux de 5 jours et j'ai désormais 1.15Mo de BDD. Je vais également afficher certains chiffres de Cyrille BORNE : 175 flux suivis, 7500 articles stockés : 14 Mo de BDD !
Les raccourcis claviers sont bien sympas (J pour faire défiler), (Ctrl+M pour tout marquer comme lu), etc.
rssLounge affiche en rouge les flux RSS morts, ce qui permet de voir les sites qui n'existent plus ou qui ont changé d'adresse (merci cborne)
On peut définir des articles favoris (étoiles) et n'afficher, par la suite, que ses favoris.
L'interface n'est pas divisée en 3 parties comme dans Tiny Tiny RSS, quand on clique sur un article, il s'ouvre juste en dessous (et se referme quand on re-clique dessus). C'est un peu perturbant au début si on a l'habitude de TTRSS mais moi je préfère ça maintenant !

J'en oublie certainement, il y a tellement de bons côtés à cette application !

Cependant, le projet est encore jeune, quelques fonctionnalités ou détails sont encore à perfectionner. Voici quelques exemples :

La traduction française n'est pas complète et est mal encodée.
Il est actuellement impossible de changer de thème. L'interface est un peu trop chargée à mon gout. J'avais l'habitude de mon Tiny Tiny RSS qui était très clair, très épuré. J'ai hâte qu'une possibilité de changement de thème soit offerte.

VII. Conclusion

J'ai fait cet article pour vous présenter ce nouvel outil que je trouve absolument génial. J'ai abandonné Tiny Tiny RSS au profit de rssLounge et je ne le regrette vraiment pas !

Si vous avez des questions, si vous utilisez rssLounge et que vous voulez témoigner, n'hésitez pas à vous exprimer ;)

Et si vous voulez une démo, rendez-vous sur cette page.

Auto-hébergment : mon système de sauvegarde

Benjamin — Sun, 19 Jun 2011 18:58:00 +0200

La sauvegarde est un élément très important dans l'auto-hébergement. On oublie la sauvegarde, ça crash, on a plus rien...
Pendant quelques semaines après avoir mis en place mon auto-hébergement, je n'avais toujours qu'un seul disque dur dans mon serveur, je lui faisais confiance :)

Et puis j'ai eu un petit problème sur un serveur au boulot, problème qui a miraculeusement été résolu grâce à une sauvegarde efficace. Je me suis donc décidé à investir un peu de mon temps dans la sauvegarde de mon serveur perso.

Le boitier de mon serveur permet d'accueillir deux disques dur format 2"1/5. Le premier étant utilisé pour mon système, j'ai décidé d'en ajouter un deuxième et de répliquer les données du premier dessus.

J'aurai pu choisir de mettre en place un système de RAID1 entre les deux disques mais j'ai préféré opter pour une synchronisation d'un disque vers l'autre plusieurs fois par semaine. Cela me permet de revenir en arrière si besoin. Par exemple, je fais une mise à jour qui se passe mal ou j'écrase un fichier involontairement. Je peux facilement récupérer la configuration ou le fichier de la veille, stocké sur mon deuxième disque, chose qui aurait été impossible en RAID1.

J'ai organisé ma sauvegarde en deux étapes : la base de données MySQL et les répertoires/fichiers de mon système.

Sauvegarde des bases de données

J'ai écrit un script bash qui me permet de faire des dumps de mes bases de données :

#!/bin/sh
#
# Il faut que le user dump ait un droit general de SELECT et RELOAD
 
MYSQL_BIN_PATH=/usr/bin
MYSQL_DATA_PATH=/var/lib/mysql
MYSQL_HOME=/mysql
FIC_ERR=$MYSQL_HOME/dump/erreur.txt
HOSTNAME=`hostname`
SYSTEME="mail@me.fr"
 
USER=dump
PASSWD="xxdumpxx"
 
/bin/rm  $MYSQL_HOME/dump/*
 
LISTE_BASES=`/usr/bin/find $MYSQL_DATA_PATH/* -maxdepth 0 -type d -printf "%f\n" `
for DB in $LISTE_BASES
do
DATABASE=`echo $DB | sed 's/@002d/-/'`
 
echo base $DATABASE
$MYSQL_BIN_PATH/mysqldump -u $USER --password=$PASSWD --opt --databases --result-file $MYSQL_HOME/dump/$DATABASE.dump $DATABASE 2>>$FIC_ERR
 
RET=$?
RETOUR=`expr $RETOUR + $RET`
if [ $RET -gt 0 ]
then
MESSAGE="$MESSAGE Erreur de dump de la base $DATABASE\n"
fi
 
/bin/gzip $MYSQL_HOME/dump/$DATABASE.dump
 
done
 
/bin/chmod -R 600 $MYSQL_HOME/dump
/bin/chmod -R 700 $MYSQL_HOME/dump*
 
if [ $# -gt 0 ] && [ $RETOUR -gt 0 ]
then
echo $MESSAGE | /bin/mail -s "mysql sur $HOSTNAME. Erreur dump des bases" $SYSTEME
fi

Ce script va interroger le nom de mes différentes bases de données stockées sur mon serveur et en fait un dump séparé. Au final, j'obtiens un répertoire /mysql/dump/ qui contiendra les différents dumps de mes différentes bases de données.

Note : L'utilisateur qui fera le dump doit avoir les droits de SELECT, RELOAD et LOCK TABLES sur les bases de données.

Sauvegarde des répertoires/fichiers de mon serveur

Une fois mes bases de données sauvegardées, je vais copier tous les fichiers importants sur le deuxième disque dur. Pour cela, j'utilise rsync :

#!/bin/bash
# $? = code de retour de la dernière commande. 0 si pas de problème
# on additionne les codes de retour à chaque fin de chaque commande, si ça dépasse 0, c'est qu'il y a eu une erreur quelque part
 
/bin/bash /scripts/dump_mysql.sh
 
FICHIER_LOG="/scripts/backup_rsync.log"
/bin/rm $FICHIER_LOG
/usr/bin/touch $FICHIER_LOG
 
echo "*****************************************************************" >> $FICHIER_LOG
/bin/date >> $FICHIER_LOG

echo "*************Dump MySQL *************" >> $FICHIER_LOG
/usr/bin/rsync -rlpgotD --stats --delete --force /mysql/ /backup/mysql/ >> $FICHIER_LOG
RET=$?
RETOUR=`expr $RETOUR + $RET` 
echo "*************Configuration Apache /etc/apache2 *************" >> $FICHIER_LOG
/usr/bin/rsync -rlpgotD --stats --delete --force /etc/apache2/ /backup/etc/apache2/ >> $FICHIER_LOG
RET=$?
RETOUR=`expr $RETOUR + $RET`
echo "*********************Home /home/*********************" >> $FICHIER_LOG
/usr/bin/rsync -rlpgotD --stats --delete --force /home/ /backup/home/ >> $FICHIER_LOG
RET=$?
RETOUR=`expr $RETOUR + $RET`
/bin/date >> $FICHIER_LOG
RET=$?
RETOUR=`expr $RETOUR + $RET`
echo "*****************************************************************" >> $FICHIER_LOG
 
if [ $RETOUR -ne 0 ]
then
echo "Le script de rsync a echoue. Code erreur : "$RETOUR | /usr/bin/mail -s "Erreur script rsync" mail@me.fr
fi

Ce script va faire une sauvegarde (miroir) des répertoires /home/, /mysql/ et /etc/apache2/ vers /backup/home/, /backup/mysql/ et /backup/etc/apache2. /backup étant le point de montage de mon disque de sauvegarde.

Voici une explication des arguments de rsync :

rsync : appelle le programme rsync
-r : parcours le dossier indiqué et tous ses sous-dossiers
-l : copie les liens symboliques comme liens symboliques
-t : préserve les dates
-g : préserve le groupe
-o : mettre le propriétaire du fichier de destination identique à celui du fichier source
-D : préserve les périphériques
-p : provoque la mise à jour des permissions sur la destination pour qu'elles soient identiques aux permissions sur la source.
--force : force la suppression de répertoires même non-vides
--stats : affiche quelques statistiques de transfert de fichiers, ce qui permet de vérifier l'efficacité de la sauvegarde.
--delete : efface avant le transfert les fichiers qui n'existent pas sur la source.

On voit qu'au début de ce script appel le script de dump des bases de données. Il nous suffit donc d'appeler uniquement ce dernier script pour avoir une sauvegarde des bases de données et de nos répertoires sur /backup.

Automatisation de la sauvegarde

Je n'ai plus qu'à appeler le script ci-dessus à la fréquence à laquelle je souhaite faire mes sauvegardes dans le cron. Voici ma crontab :

30 23 * * 1,4,6 /root/scripts/backup_rsync.sh >/dev/null 2>&1

Ainsi, tous les lundis, jeudis et samedi à 23h30, je sauvegarde les répertoires importants de mon disque 1 vers mon disque 2.

Bonus

Je fais également une sauvegarde de mes bases de données et de mon répertoire www sur une clé USB une fois par mois avec ce script :

#!/bin/bash
# $? = code de retour de la dernière commande. 0 si pas de problème
# on additionne les codes de retour à chaque fin de chaque commande, si ça dépasse 0, c'est qu'il y a eu une erreur quelque part
 
MAIL_CONTACT='mail@gmail.com'
FICHIER_LOG="/root/scripts/logs/backup_usb.log"
REP_DEST="/mnt/usb/`date +%d%m%Y`"
/bin/rm $FICHIER_LOG
/usr/bin/touch $FICHIER_LOG
 
/bin/mount /dev/sdc1 /mnt/usb/
/bin/rm -rf /mnt/usb/*
/bin/mkdir $REP_DEST
 
echo "*****************************************************************" >> $FICHIER_LOG
/bin/date >> $FICHIER_LOG
 
echo "*************Copie des répertoires /mysql *************" >> $FICHIER_LOG
/bin/cp -pr /mysql/ $REP_DEST
RET=$?
RETOUR=`expr $RETOUR + $RET`
echo "*************Copie du répertoire /www *************" >> $FICHIER_LOG
/bin/cp -pr /www/ $REP_DEST
RET=$?
RETOUR=`expr $RETOUR + $RET`
 
/bin/date >> $FICHIER_LOG
RET=$?
RETOUR=`expr $RETOUR + $RET`
echo "*****************************************************************" >> $FICHIER_LOG
 
if [ $RETOUR -ne 0 ]
then
echo "Le script de backup USB a echoue. Code erreur : "$RETOUR | /usr/bin/mail -s "Erreur script backup USB" $MAIL_CONTACT
fi
 
/bin/umount /mnt/usb/

Si vous cherchiez des pistes pour sauvegarder votre serveur, j'espère vous avoir un peu éclairé.
Comme toujours, si vous avez des suggestions à me proposer ou si vous souhaitez des précisions supplémentaires sur ces scripts, n'hésitez pas à demander.
Par ailleurs, je serais curieux de connaitre vos moyens de sauvegarde en auto-hébergement :)

Sauvegarder automatiquement ses sites web distants chez soi

Benjamin — Sat, 04 Jun 2011 13:11:00 +0200

Je m'occupe et administre plusieurs sites hébergés ailleurs que chez moi, sur un serveur d'hébergement mutualisé. Autrement dit, je n'ai qu'un accès FTP au répertoire www. Aucune sauvegarde n'est donc faite sur ces machines. de temps en temps, quand j'y pense, je fais un backup "manuel" en me connectant en FTP et en rapatriant les données chez moi, puis je vais sur l'interface phpmyadmin et fait un export de la base. Une solution pas terrible, vous en conviendrez.

Depuis que j'ai mon serveur perso chez moi, je me suis dit qu'il serait intéressant d'automatiser cette sauvegarde. Je n'aurai donc plus à me soucier de le faire "manuellement" une fois par mois.

Voici les scripts que j'ai utilisé, ma procédure, mon automatisation, bref, un petit tuto pour sauvegarder automatiquement ses sites web hébergés loin de chez soi.

I. L'environnement

Je m'occupe actuellement de 3 "gros" sites 'propulsés par Joomla' hébergés chez un hébergeur qui me propose un accès FTP sur le répertoire www ainsi qu'une base de données que j'administre via phpmyadmin.

Je vais prendre l'exemple du plus gros site que j'administre et que je veux sauvegarder chez moi automatiquement :

Un répertoire www de 1,2 Go (1945 répertoires et 20017 fichiers) accessible uniquement en FTP
Une base de donnée de plusieurs dizaines de Mo et d'une centaine de tables
La base de données n'est pas accessible à distance (je ne peux pas faire un mysqldump de chez moi sur la base)
Les modifications sur le www ne sont pas fréquentes, en revanche, les modifications sur la base sont nombreuses et quotidiennes
Les backups du www via FTP durent environ 1h30, 2h (très grand nombre de petits fichiers et grosses photos)
Je veux une sauvegarde mensuelle pour le répertoire www et une sauvegarde hebdomadaire pour la base de données.

Voila pour les données de base. Voici comment je fais pour sauvegarder tout ça.

II. La sauvegarde

La sauvegarde va se dérouler en 3 étapes : la sauvegarde de la base de données (qui, elle aussi, va se découper en 2 temps), la sauvegarde du répertoire www et enfin, l'automatisation de tout cela.

La base de données

Comme je vous l'ai dit, je ne peux pas accéder directement à la base depuis chez moi. Si j'avais pu, un simple mysqldump aurait fait l'affaire. Si vous avez un accès distant sur votre base, vous pouvez passer cette étape. Ici, c'est un peu plus compliqué : il faut générer un mysqldump sur la machine distante puis récupérer le dump en FTP.

Il faut donc, dans un premier temps, écrire le script de génération de dump. Ce sera un script php que nous appelleront, via curl, dans notre script shell de backup (voir après).

<?php
$host = 'myhost';
$user = 'myuser';
$db = 'mydatabase';
$password = 'mypassword';
 
system("mysqldump --host=$host --user=$user --password=$password $db > $db.sql");
#On vire l'ancienne version gzippée du dump
system("rm $db.sql.gz");
#On gzip la nouvelle version
system("gzip $db.sql");
?>

À ma racine www, j'ai créé un répertoire backup dans lequel j'ai ajouté ce script backup.php. Ainsi, dès qu'on appellera la page http://monsite.fr/backup/backup.php, un dump mydatabase.sql.gz sera généré dans ce répertoire backup.

Ensuite, sur mon serveur je créé mon script shell de backup de mysql :

#!/bin/bash
#Ce script fait un backup de la BDD et la récupère en ftp
#
FICHIER_DUMP='/www/backup/mydatabase.sql.gz'
FICHIER_DEST='/sauvegardes/monsite/mysql/mydatabase.sql.gz'
MAIL_CONTACT='mail@me.fr'
 
#On génère le fichier sur le serveur (voir ci-dessus)
curl -s http://monsite.fr/backup/backup.php
sleep 10

#On vire l'ancienne version sur le serveur
rm -f $FICHIER_DEST
 
#On ramène le fichier sauvegardé via ftp sur notre serveur
lftp ftp://login:pass@ftp.monsite.fr -e "get $FICHIER_DUMP -o $FICHIER_DEST ; quit"
 
  RET=$?
  if [ $RET -gt 0 ]
  then
    MESSAGE="Erreur de dump de la base $FICHIER_DUMP"
   echo $MESSAGE | /usr/bin/mail -s "Erreur sur le serveur" $MAIL_CONTACT
  fi

lftp ftp://login:pass@ftp.monsite.fr -e "rm $FICHIER_DUMP ; quit"

Explications :

La variable FICHIER_DUMP contient le chemin sur le serveur distant du dump généré avec le script php backup.php
La variable FICHIER_DEST contient le chemin où sera stocké le dump sur mon serveur
Le MAIL_CONTACT est l'adresse mail où sera envoyé un mail d'erreur (s'il y en a une)
Grâce à curl, j'interroge mon script php qui, nous l'avons vu, génère mon dump sur le serveur distant
J'enlève l'ancien backup de mon serveur
J'utilise le programme lftp pour rapatrier, en FTP, le dump ainsi généré. La commande est assez claire je pense
Je contrôle que la commande s'est bien passée, le cas contraire, j'envoie un mail
Enfin, je supprime le dump sur le site distant (par précaution, merci JN)

On a désormais un script qui génère le dump sur le site distant et le ramène sur notre serveur. Nous verrons après pour l'automatisation de ce script.

Le répertoire www

Maintenant que ma base de données est sauvegardée, je vais sauvegarder mon répertoire www. Pour ce faire, j'ai fait ce script :

#!/bin/bash
#Ce script fait un backup du www en ftp
#
REP_DUMP='/www/'
REP_DEST='/sauvegardes/monsite/www/'
FICHIER_LOG='/sauvegardes/monsite/backup.log'
MAIL_CONTACT='mail@me.fr'
 
 
echo "*****************************************************************" >> $FICHIER_LOG
/bin/date >> $FICHIER_LOG
echo "Backup en cours" >> $FICHIER_LOG


#Ici, on sauvegarde tout sauf le répertoire compteur
lftp ftp://login:pass@ftp.monsite.fr -e "mirror -e -x cours/ -x logs/ $REP_DUMP $REP_DEST ; quit"
 
  RET=$?
  RETOUR=`expr $RETOUR + $RET`
  if [ $RET -gt 0 ]
  then
    MESSAGE="Erreur de backup sur $REP_DEST\n"
   echo $MESSAGE | /usr/bin/mail -s "Erreur sur le serveur" $MAIL_CONTACT
  fi


/bin/date >> $FICHIER_LOG
/usr/bin/du -hs $REP_DEST >> $FICHIER_LOG
echo "Backup terminé" >> $FICHIER_LOG
echo "*****************************************************************" >> $FICHIER_LOG

   echo "Voir fichier $FICHIER_LOG" | /usr/bin/mail -s "Backup monsite OK" $MAIL_CONTACT

Explications :

La variable REP_DUMP contient le nom du répertoire distant à sauvegarder
La variable REP_DEST et FICHIER_LOG contiennent respectivement le chemin où sera sauvegardé le site sur mon serveur et le fichier de log qu'il génèrera
Le MAIL_CONTACT est l'adresse mail où sera envoyé un mail d'erreur (s'il y en a une)
Je commence par écrire l'heure de départ du script dans le fichier de log puis "Backup en cours"
J'utilise, là aussi, lftp pour rapatrier le site. La commande mirror permet d'avoir une copie parfaite du site distant (les répertoires supprimées du www seront effacés aussi sur mon serveur, etc.). Le paramètre -x me permet d'exclure certain répertoires de la sauvegarde. Voir cette page pour plus de détails sur la commande lftp.
Je contrôle que la commande s'est bien passée, le cas contraire, j'envoie un mail
J'écris la date et l'heure de fin du script dans le fichier de log.

On a désormais un script qui récupère et synchronise notre site distant sur notre serveur.
Notez qu'on pourrait, si on voulait être bien synchro, lancer l'exécution du script de sauvegarde de la base de données dans ce script. Ainsi, on ferait un backup de la base et on rapatrierait l'ensemble en même temps.

III. L'automatisation

Une fois que ces scripts sont prêts (ont peut les tester "à la main" pour s'en assurer), il ne nous reste plus qu'à tout automatiser grâce au cron. Pour ceux qui ne connaissent pas le cron, j'en ai fait un cours dans cet article.

Pour faire rapide, voici ma crontab :

#Backup des BDD des sites distants (hebdomadaire, le dimanche soir)
45 23 * * 0 /home/moi/scripts/backup_mysql_sitedistant.sh >/dev/null 2>&1

#Backup du www des sites distants (une fois par mois, la premiere nuit)
0 1 1 * * /home/moi/scripts/backup_www_sitedistant.sh >/dev/null 2>&1

Explications :

J'exécute mon script de sauvegarde de la base de données tous les dimanches à 23h45
J'exécute mon script de sauvegarde du répertoire www tous les 1er du mois à 1h du matin

IV. Conclusion

Voici donc comment je sauvegarde mes sites distants, en attendant de tous les remettre directement sur mon serveur, ce qui simplifiera bien les choses.
Je pense que ces scripts sont perfectibles, si vous avez des idées, n'hésitez pas à me les suggérer, je suis toujours à l'affut des bons conseils :)

Edit : Pour ceux qui essayent, les chemins d'accès on tous été changés dans mes scripts d'exemple et c'est pas mon blog que je sauvegarde automatiquement, donc n'essayez plus d'aller sur generation-linux.fr/backup ;)

Auto-hébergement : Mon experience, mes problèmes, mes idées

Benjamin — Thu, 31 Mar 2011 21:38:00 +0200

Il est inutile de rappeler les (nombreuses) raisons qui m'ont poussé à m'auto-héberger (contrôle de ses données, indépendance, faire du vrai Internet, etc.). J'ai décidé de faire un article sur mon expérience dans l'auto-hébergement. Mes interrogations, mes succès, mes échecs, où j'en suis actuellement, les difficultés rencontrées, comment je les ai résolues.

Cela suscitera peut-être des "vocations" d'auto-hébergement chez certaines personnes hésitant encore.

I. L'idée

J'ai commencé à penser à l'auto-hébergement début 2009. L'article de rom a été une petite révélation. À cette époque, j'étais en licence pro ASRALL. J'avais donc déjà des bonnes notions d'administration système.
L'envie de mettre mes compétences en pratique a fait que je me suis très vite intéressé et renseigné sur l'auto-hébergement. Mes recherches m'ont permis de découvrir la fameuse conférence de Benjamin Bayart "Internet libre, ou Minitel 2.0".

Suite à cette conférence, j'ai voulu auto-héberger ce blog. Là sont apparues quelques interrogations :

Quelle sera la "qualité de service" et la disponibilité de ce blog ?

J'étais alors hébergé chez tuxfamily et n'avais pas à me soucier de la bande passante ou de la disponibilité. À l'époque, ce blog recevait environ 2000 visites par jour, je voulais donc assurer une certaine qualité de service.
Concernant la bande passante, je ne me faisais pas trop de soucis car j'étais chez Numéricable et avais un débit en upload de plus d'un Mbps. Le problème chez Numéricable, c'est que je n'avais jamais une semaine sans une coupure d'au moins une heure. Ce point me posait un peu plus de problèmes.

Sachant que j'allais bientôt déménager (et donc changer de FAI), je me suis décidé à reporter l'auto-hébergement de ce blog et j'ai eu l'idée de commencer par héberger des petits services (perso) tels qu'un agrégateur de flux RSS, Tiny Tiny RSS.

Quelle machine utiliser pour m'auto-héberger ?

À cette époque, j'étais étudiant, et je n'avais pas de job à côté, donc une fois le loyer, les charges, l'essence et la bouffe payés, il ne restait plus grand chose à la fin du mois. Je ne pouvais donc pas me payer un petit serveur et devais faire avec les moyens du bord.

J'avais alors 3 machines : mon PC de bureau, sous Ubuntu, assez bruyant, un gros serveur Dell qu'on m'avait donné, lui aussi très bruyant, et un EeePC 900 sous CrunchEee.

Habitant dans un petit 2 pièces, il me fallait évidemment quelque chose de silencieux (et qui ne consomme pas trop). C'est donc assez naturellement que j'ai décidé d'utiliser mon EeePC pour faire office de serveur.

II. Premier essai, mon serveur EeePC

C'était donc parti, au mois d'avril 2009, pour la transformation de mon EeePC en serveur sous Debian Lenny. Mes interrogations, questions et réponses se trouvent sur l'article que j'avais fait à l'époque.

Tout s'est bien passé pendant quelques semaines. Depuis le début, c'est le disque SSD de l'EeePC qui me faisait peur. Les disques SSD ne supportent pas très bien le fait de rester allumé 24h/24. Qui plus est, les disques SSD de l'EeePC ne sont pas d'une excellente qualité (à ce prix, faut pas rêver).

Mes craintes se sont confirmées. Au bout de 2 ou 3 semaines d'utilisation H24, le disque SSD a grillé. HS, plus rien quoi. Heureusement que j'avais conservé le ticket de caisse, je l'ai renvoyé en SAV et on m'a remplacé ce disque SSD.

Suite à cela, je n'ai pas voulu réitérer l'expérience. J'ai décidé d'attendre d'avoir une vraie machine dédiée à cela...

III. Deuxième essai

Fin 2010, je me décide enfin à acheter une machine dédiée. Après avoir fait de looooongues recherches, j'ai fini par choisir un serveur composé de la sorte : carte mère Asus AT5NM10-I, boitier Antec ISK300-65, disque dur 2.5" Western Digital Scorpio - 160 Go et 1 Go de RAM. J'explique les raisons de ces choix sur cet article.

Depuis cet article, j'ai acheté un autre disque dur 2.5 que j'ai ajouté dans l'emplacement prévu à cet effet. Ainsi, je peux faire mes sauvegardes sur ce deuxième disque. Je n'ai pas choisi de faire du RAID, je fais simplement un rsync des principaux répertoires de mon disque "principal" vers le "secondaire".

Une fois ce serveur reçu et assemblé, j'y ai installé une Debian Lenny (netinstall après boot sur une clé USB). Par la suite, je l'ai réinstallé avec une Debian Squeeze.

Globalement, je suis extrêmement satisfait par ce serveur. Le processeur atom dual core fait très bien son travail et chauffe peu. Je peux régler la vitesse du ventilateur. Il y en a 3. En première vitesse, on entend absolument rien à 2 mètres du serveur. À cette vitesse, la température du processeur et du disque dur varient entre 25 et 35 °C. Dans mon salon, le serveur étant en bas d'une fenêtre, les températures varient légèrement en fonction de la température extérieure. Pour preuve, voici, dans l'ordre, les graphs hebdomadaires de la température extérieure, de celle du processeur et celle des disques dur :

Conclusion, cette machine est un excellent rapport qualité/prix et ventilation/bruit/température :)

IV. Les applications que j'héberge

Après avoir vu le côté matériel, je vais faire un petit compte-rendu de l'utilisation actuelle de mon serveur.

Côté web :

Mon profil : Un site statique avec 2, 3 pages
Mon blog perso : Un blog dotclear avec un thème que j'ai fait ressembler à celui de mon profil
Mes feeds RSS : Avec le célèbre Tiny Tiny RSS
Mes musiques : Utilisant Subsonic, je peux écouter mes musiques au travail, à la maison, partout !
Mes téléchargements : J'utilise pour cela torrentflux-b4rt
GaCoMa : Avec un blog dotclear et un wiki dokuwiki
Mon identité OpenID : Avec SimpleID, j'ai mon identité chez moi :)
Une galerie photos : Avec l'application iGalerie
Un wiki perso : Utilisant dokuwiki
Génération Linux : Ce blog, propulsé par dotclear
Un dépôt de fichiers public, utilisant l'application KOLoad

Côté système :

Serveur mail : postfix, dovecot (en cours)
Monitoring : Munin
fail2ban avec quelques jails perso en plus

V. Les difficultés

Voici les principales difficultés auxquelles j'ai été confrontées et comment je les ai résolues :

La bande passante

Ce sont les histoires de bande passante qui m'ont le plus dérangé. Comme je l'ai évoqué ci-dessus, quand j'étais chez Numéricable, je ne me posais pas trop la question de la bande passante car j'avais 1 Mbps en upload. En revanche, depuis que je suis chez Free, je suis tombé à 100 kbps... Autrement dit, la douche froide... Quand je ne mettais que des petits services pour moi sur ce serveur, je ne me posais pas trop de question. Mes musiques passaient bien en upload (via subsonic) et c'était tout ce qui m'importait.

Je me suis posé bien plus de questions quand j'ai voulu migrer ce blog (alors chez tuxfamily) sur mon serveur. OK, je n'ai pas 10 000 visites par jour, mais quand même suffisamment pour que cela m'inquiète. Après, c'était une question de choix. Est-ce que je laisse mon blog ailleurs que chez moi mais avec une bande passante irréprochable ou bien est-ce que je "ramène" mon blog chez moi, au détriment de la vitesse. Le choix de faire du vrai Internet a été dominant, j'ai donc migré mon blog sur ma machine.

La différence est quand même de taille. J'ai presque doublé le temps d'accès. J'avais faits des tests, chez tuxfamily, ma page d'accueil se chargeait en 3 secondes, chez moi, elle se charge en un peu moins de 6 secondes.

Comment j'ai "résolu" ce problème ? Avec une astuce toute simple : activer le module deflate d'apache. Il permet de compresser le flux HTTP envoyé par le serveur. Ce flux est ensuite décompressé chez le client. Ainsi, j'ai diminué assez significativement la masse d'envoi de flux HTTP.
Actuellement, j'ai activé ce module uniquement pour mon blog. Voici une capture d'écran de Munin vous illustrant le changement. Je pense que je n'ai pas besoin de vous dire à quel moment j'ai activé le module ;)

La disponibilité

Ma deuxième inquiétude a été la disponibilité de mon blog. Là encore, je n'avais jamais eu à me soucier de cela avec tuxfamily. Par contre, une fois mon blog chez moi, je n'aurai pas une disponibilité aussi importante. Là encore, la même réflexion : "Disponibilité parfaite mais pas chez moi ou disponibilité imparfaite mais chez moi". J'ai tranché, à nouveau, pour faire du vrai Internet.

Ici, je ne peux pas faire grand chose. Heureusement, je n'ai jamais eu de coupure chez Free, donc la disponibilité est correcte. Je redémarre de temps en temps mon serveur, c'est juste là que peut intervenir l'indisponibilité temporaire.

Voila les 2 grandes questions que je me suis posé avant de me lancer dans l'auto-hébergement. Je pense que ce sont 2 questions récurrentes.

VI. Conclusion

Pour conclure cet article, je peux dire que s'auto-héberger est une chose formidable pour de nombreuses raisons :

Cela nous fait acquérir de nombreuses compétences en tout genre (sécurité, administration, optimisation, etc.)
Cela nous permet d'avoir une machine à disposition 24h/24 et accessible depuis n'importe où.
On n'a plus à se casser la tête pour trouver un hébergeur pour un service.
Garder le contrôle sur ses données et avoir la possibilité de couper sa machine du réseau à tout moment.
Et une certaine fierté de dire "c'est moi qui héberge mon blog et mes services" :)

Auto-hébergement : compte-rendu de vos témoignages

Benjamin — Sat, 15 Jan 2011 22:30:00 +0100

Vous avez été nombreux à répondre aux questions que je vous avais posé sur l'article Auto-hébergement : vos témoignages m'intéressent !.
Merci à tous !

Je vais donc faire un résumé de vos réponses, réponses qui m'ont fait découvrir de nombreux logiciels, beaucoup de matériel et qui m'a montré que l'auto-hébergement se démocratise de plus en plus.

Préambule

Voici la liste des questions que j'ai posé :

Vous auto-hébergez-vous ? Pourquoi ? Quelles sont les motivations qui font que vous vous auto-hébergez (ou pas) ?
Depuis combien de temps ?
Quelle machine utilisez-vous ? Les avantages/inconvénient de votre machine.
Quels services/logiciels hébergez-vous ?
Quels sont les visiteurs de votre serveur (perso, famille, amis, inconnus, etc.)
Quelles sont les difficultés les plus importantes que vous ayez rencontrées ?
Selon vous, le principal avantage et le principal inconvénient à l'auto-hébergement ?
Un chantier en cours sur votre auto-hébergement ?
Des applications à recommander ?

Dans cet article, je vais reprendre les questions les plus importantes une par une et vous faire une synthèse des réponses apportées.

I. Vous auto-hébergez-vous ? Pourquoi ? Quelles vos motivations ?

Garder le contrôle sur ses données (SES données chez SOI) : 17%
Curiosité, apprentissage (comment on fait un serveur mail, web, etc.) : 17%
Faire du vrai Internet (cf Benjamin Bayart) : 16%
Indépendance, liberté : 15%
Avoirs ses fichiers à disposition partout : 9.5%
C'est cool, amusant et "ça fait geek" (bien que je trouve le mot geek plutôt péjoratif) : 9.5%
Prix (c'est moins chez de faire de l'auto-hébergement que de louer un serveur dédié) : 9.5%
Choix et qualité des services (pas de pub, PHP 5, etc.) : 6.5%

Nous pouvons nous rendre compte que le premier facteur d'auto-hébergement est le facteur idéologique : je veux faire du vrai Internet et garder le contrôle de mes données.

II. Depuis combien de temps vous auto-hébergez vous ?

0 - 6 mois : 12.5%
6 mois - 1an : 15.5%
1an - 2ans : 28%
2 ans et plus : 44%

L'auto-hébergement est "à la mode" en ce moment, on en parle de plus en plus depuis peu de temps, cependant, nous pouvons nous rendre compte que de nombreuses personnes s'auto-hébergent depuis bien longtemps !

III. Quelle machine utilisez-vous ?

Vieux PC, récupération : 24%
Petit PC (à base de mini ITX/atom) : 19%
Tout petits PC (FitPC, Efika Mx, Linutop, etc.): 19%
Netbook / PC portable : 12%
Grosse configuration, neuf, silencieux : 8%
NAS : 8%
Plug (sheevaplug par exemple) : 5%
Serveur dédié : 5%

Les PC de récupération sont régulièrement utilisés. Ils ont l'avantage de ne rien couter (ou presque). Cependant, ils peuvent vite devenir assez consommateurs et surtout bruyant, c'est une raison pour laquelle de plus en plus de monde se tourne vers des solutions de petit PC (à base de mini ITX) ou de très petits PC (type FitPC ou Linutop).

IV. Quels services/logiciels hébergez-vous ?

Ici, je vais lister les différents logiciels allant de celui que vous avez évoqué le plus à celui que vous avez évoqué le moins (oui, j'ai compté chez moi).

Note : Les applications en gras sont celles qui ont été particulièrement recommandées (ma dernière question).

Système

Serveur mail (postfix, imap, pop, anti-spam)
NFS, Samba, FTP
Serveur Jabber
Bind (serveur DNS)
Subversion, Git
Nagios (supervision)
Squid (proxy)
Rsync (synchronisation de fichiers, sauvegarde)
OpenLDAP (annuaire LDAP)
Asterisk (téléphonie IP)
phpMyAdmin
Serveur de listes de diffusion
Nessus/Metasploit
unison (synchronisation de fichiers)
VNC
DHCP
plowshare (wget-like pour megaupload, rapidshare, etc.)
iredmail
NTP (serveur de temps)
screen (gestionnaire de terminal)
Folding@Home (projet d'ordinateurs distribués)
sslh (accès ssh sur le port 443)

Applications Web

Lecteurs, gestionnaires de musique

Gestionnaires de téléchargement

Autres

Tiny Tiny RSS (lecteur de flux RSS)
Roundcube (webmail)
Piwik (statistiques web)
Piwigo (galerie photos)
Diaspora (réseau social libre)
SemanticScuttle (gestionnaire de marque pages)
OwnCloud
Gallery2 (galerie photos)
Squirelmail (webmail)
Dokuwiki (plate-forme de wikis)
Munin (monitoring)
iTheora (diffusion de fichiers multimédia)
aptoide (dépot android indépendant)
Jappix (réseau social libre)
BackupPC (outil de sauvegarde)
Mumble/Teamspeak (tchat vocal)
SimpleID, Community-id (providers OpenID)
eyeos (bureau virtuel)
Webmin (administration système)
AWStats (statistiques web)
minbif (messagerie instantanée)
motion (vidéosurveillance)
jyraphe (megaupload-like)
Chevreto (imageshack-like)
Ajaxplorer (gestionnaire de fichiers)
ajaxterm (accès basique SSH n'importe où et sans install)

V. Quelles sont les principales difficultés que vous ayez rencontrées ?

Problème de ligne ADSL (mauvais débits, ip dynamique, nom de domaine, etc.) : 23%
Mise en place de la sécurité, de la sauvegarde : 20.5%
Technique générale, documentation, connaissance des logiciels : 20.5%
Mettre en place un serveur mail : 13%
Aucun problème : 10%
Ressources machine ou problème matériel : 8%
Manque de temps : 5%

Les limitations du FAI sont les principaux problèmes rencontrés, qu'il s'agisse du débit, de l'adresse IP et d'autres raisons, les FAI n'encouragent en rien leurs utilisateurs à passer à l'auto-hébergement (ce n'est pas dans leur intérêt de toutes façons). La sécurisation de son serveur est également une difficulté importante rencontrée par beaucoup d'entre vous.

VI. Selon vous, quels sont les principaux avantages et inconvénients de l'auto-hébergement ?

Avantages

Liberté, indépendance : 42.5%
Garder le contrôle de ses données : 21%
Apprentissage, découverte : 10.5%
Prix : 9%
Adaptabilité, capacité de stockage : 9%
Satisfaction de faire du vrai Internet : 4%
Données disponibles partout : 4%

Inconvénients

Problèmes liés à la ligne ASDL (débit, IP dynanique, etc.) : 28.5%
Problèmes électriques (coupure de courant, etc.) : 19%
Sécurisation, sauvegarde, restauration : 19%
Cela prends beaucoup de temps : 16.5%
Risques matériels : 10%
Prix : 7%

Conclusion

Merci encore pour toutes vos réponses, j'ai découvert pas mal de nouveaux logiciels grâce à vous. J'ai également découvert beaucoup de petits PC. Je n'ai pas synthétisé toutes vos réponses, si vous souhaitez toutes les voir, rendez-vous dans les commentaires de l'article en question.

J'ai conclu rapidement pour chaque question, néanmoins, si vous souhaitez apporter vos propres conclusions sur les résultats de ce sondage, je vous écoute et suis prêt à en discuter avec vous :)