SheevaBoite

Il y a un peu plus de trois mois (que le temps passe vite), je vous expliquais comment créer un serveur capable de stocker et partager des dépôts git. Mais nous avons mis en place un système qui n'est utilisable uniquement à partir de la console.
Aujourd'hui, nous allons toujours utiliser la console afin de faire des installations mais le résultat final s'utilisera cette fois dans un navigateur...

Dans la première partie de l'installation d'un serveur Git nous avons vu comment installer un serveur Git sur son propre serveur. Pour rappel, il y a deux moyens d'installer son serveur :

• soit, on configure tout à la main si on est seul à commiter,
• soit, on utilise gitolite qui gère bien plus de choses.

Quel est l'objectif de cette partie ?

Dans cette seconde partie du tutorial, nous allons tout simplement mettre en place une webapp qui permettra d'accéder facilement à ses dépots à partir d'un navigateur.
En effet, avec Github, bitbucket, ou encore Assembla il est possible d'accéder facilement au contenu de ces dépots ce qui est extrêmement pratique si l'on ne veut pas ou si l'on ne peut pas télécharger un dépôt sur une machine.

Pour quelles contraintes ?

Comme je suis auto-hébergé, je ne dispose pas d'une machine puissante, donc il me faut un système qui ait le moins de dépendances possible, qui soit le plus léger possible afin de ne pas surcharger la machine et surtout je veux mettre en place une webapp qui est maintenue (mine de rien cela a son importance pour moi).
Pour faire simple, je ne veux pas installer de nouvelles dépendances pour faire fonctionner ma webapp, donc je ne me suis pas tourné vers une solution en ruby, par exemple Gitorious.

Ces contraintes étant particulièrement fortes, je n'ai pas identifié beaucoup de solutions pouvant convenir, seulement deux !

Deux solutions disponibles, une seule retenue

Ces deux alternatives sont uniquement le fruit de mes recherches sur l'ami Google. Il est tout à fait possible qu'il existe de meilleur solution et je serai ravi de les connaitre. Voici les deux solutions que j'ai testées avant de faire mon choix !

gitweb

gitweb est un projet en python 2.6, qui est simple à installer (un apt-get suffit) mais qui nécessite de fonctionner avec CGI sur votre serveur web. La capture suivante utilise un thème qui permet de le faire ressembler à Github, ce qui n'est pas désagréable.
Le script gitweb est utilisé pour afficher les commits des kernels Linux

Cette solution me semblait pas mal, mais les performances n'étaient pas au rendez-vous. En effet, la génération des pages prenait entre 2 et 5 secondes qui est beaucoup trop pour moi !

viewgit

viewgit est un script PHP qui du coup très simple à installer et qui est très rapide. En effet, la navigation dans le code est beaucoup plus fluide que sur gitweb. En revanche l'interface laisse un peu à désirer, mais c'est secondaire...

Au final, c'est viewgit que j'ai choisi de garder principalement à cause des performances et parce que je parle d'avantage le PHP que le Python.

Conclusion

Installer son propre serveur git n'est pas très compliqué, je n'ai pas traité la partie de l'installation du service et de la sécurité. Pour l'installation, cela me paraissait tellement évident que je n'ai pas jugé la faire. Pour ce qui est de la sécurité, sachez que si vous voulez garder votre code privé il sera nécessaire de vous pencher sur cette problématique.

Github est aujourd'hui la référence pour ce qui est du "social coding", malheureusement il est un peu trop social à mon gout. En effet, il n'est pas possible d'avoir de dépôt privé à moins de payer 7$ par mois et de ne pas savoir ou seront stockés mes données que je veux garder pour moi.
Bref, il peut être intéressant de créer son propre serveur git personnel, pour contrôler parfaitement son code...

Vous l'aurez probablement compris, mais l'installation d'un serveur privé va se faire en plusieurs partie. Dans cette première partie, nous allons voir comment installer et configurer notre serveur Git sur un serveur Debian pour héberger ces propres dépôts git.
Après cette première partie, il sera possible de rapatrier du code sur sa machine locale, de le modifier et d'envoyer au serveur les modifications, par exemple :

git clone git@mon-serveur.fr:mon-depot.git

Ce tutoriel se veut simple et s'adresse aux personnes qui souhaitent être seules à pouvoir commiter du code sur le serveur.

Installation de git

L'installation de git à proprement parler n'est pas compliquée puisqu'il est généralement disponible dans les gestionnaires de paquets des différentes distributions Linux et j'ose espérer qu'il est déjà installer sur votre machine.
Si ce n'est pas le cas, la commande à saisir pour installer git est la suivante :

sudo apt-get install git

Un peu de patience et voilà git installé sur votre serveur.

Création de l'utilisateur git

Bon maintenant, il faut créer un utilisateur git qui permettra de se connecter sur la machine en SSH.
On va donc créer un utilisateur git ainsi que son groupe, l'utilisateur n'aura pas de mot de passe et sa "home" se trouvera dans le répertoire `/var/git` :

sudo adduser --system --shell /bin/bash --group --disabled-password --home /var/git/ git

Normalement le répertoire `/var/git` existe déjà (il est créé lors de l'installation de git), donc ne vous inquiétez pas si des "warning" apparaissent lors de la création de l'utilisateur. Cependant, il va falloir changer le propriétaire du répertoire `/var/git/` pour l'utilisateur `git` :

sudo chown git:git /var/git

L'utilisateur `git` est désormais créé sur votre serveur, mais pour l'instant il n'est pas possible de se connecter en tant qu'utilisateur `git`.

Configuration SSH du client

Puisque l'on ne peut pas se connecter à l'utilisateur, il va falloir configurer l'accès à cet utilisateur. Puisque l'on va y accéder à partir de machines distantes, on va utiliser SSH pour se connecter en tant qu'utilisateur git, ce qui nécessite un peu de configuration sur votre machine locale.

Pour configurer cet accès, il faut créer des clés SSH avec la commande suivante :

ssh-keygen -t rsa

Cette commande va générer une clef SSH privée et une clef publique qui se trouveront dans le répertoire `~/.ssh`. Avec la commande que nous venons de saisir, la clef privée s'appelle `id_rsa` et la clé publique `id_rsa.pub`. Ces clef permettront de s'authentifier sur votre serveur sans avoir à saisir d'identifiant. Visualisez le contenu de votre clé publique puisque c'est le contenu de la clé publique qui sera nécessaire pour la configuration SSH du serveur.

Avant de passer à l'étape suivante, veuillez vérifier les droits de votre configuration SSH :

chmod 755 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

Je suppose que vous utilisez une machine SSH avec le port par défaut, sinon il faudra ajuster votre configuration SSH.

Si vous voulez accéder aux dépôts à partir de plusieurs machines, il faudra transférer votre clef SSH dans le répertoire `.ssh` sur votre seconde machine.

Configuration SSH du serveur

Maintenant que votre machine de développement est configurée, il faut maintenant finir la configuration SSH sur votre serveur qui hébergera les dépôts git.
Voici les commandes à saisir pour terminer la configuration sur le serveur :

sudo mkdir /var/git/.ssh
sudo touch /var/git/.ssh/authorized_keys

Il faut maintenant écrire le contenu de votre clé publique que vous venez de générer dans le fichier `authorized_keys`. Faites cela avec la commande suivante :

echo "CONTENU_DE_LA_CLE" >> /var/git/.ssh/authorized_keys

Dernière étape, vérifier bien les droits de vos fichiers de configuration SSH :

chmod 755 ~/.ssh
chmod 644 ~/.ssh/authorized_keys

Et voila, la configuration du serveur git est terminée. Pour vérifier qu'il n'y a pas d'erreur, on peut vérifier que l'on peut se connecter sur le serveur en SSH avec l'utilisateur git :

ssh git@mon-serveur.fr

Normalement, vous devriez être connecté et vous pouvez naviguer dans l'arborescence de fichiers.

Création d'un dépôt

Toujours sur le serveur, il faut maintenant créer un dépôt git sur le serveur et l'initialiser, rien de bien compliqué puisqu'il suffit de saisir les commandes suivantes :

sudo mkdir /var/git/mon-depot.git
sudo cd /var/git/mon-depot.git
sudo git init --bare
sudo chown -R git:git /var/git/mon-depot.git

La ligne `giti init --bare` permet d'initialiser le dépôt. C'est terminé pour de bon de la configuration du serveur.

Clone et commit

Rendez-vous sur votre machine locale, nous allons rapatrier le projet `on-depot.git` sur la machine. Toujours très simple, un petit clone suffit :

git clone git@mon-serveur.fr:mon-depot.git

Vous avez maintenant un répertoire local nommé mon-depot.git.Normalement, un warning vous indique que vous venez de cloner un repository vide, ce qui est le cas donc pas de panique. Il ne vous reste plus qu'à coder et commiter...

echo "console.log('Hello NodeJS');" > helloworld.js
git add helloworld.js
git commit -m "Initial commit" helloworld.js
git push origin master

La dernière ligne est importante puisque sans elle vous ne pourrez pas commiter votre code! En effet, nous venons d'installer un dépôt vide, donc git ne parvient pas à faire de synchro entre les fichiers locaux et les fichiers sur le serveur. La commande `git push origin master` permet de pousser les premières modifications sur le serveur git.
Par la suite, vous pourrez comme d'habitude utiliser `git push` pour commiter votre code.

Conclusion

Voilà la première partie est terminée, la mise en place de ce service est peu longue je le concède. Mais le fait d'avoir ses propres dépôt stockés sur son propre serveur est quelque chose de très agréable lorsque l'on ne veut pas envoyer ses données sur Github.

Dans la seconde partie, nous verrons comment importer des dépôts Github sur notre nouveau serveur puis comment mettre en place une web interface sur les dépôts...

La FreedomBox Foundation ou FBF a pour but de fournir des moyens sécurisés de communiquer et de publier des contenus sur internet pour éviter la censure.
Pour atteindre cet objectif, il est important de ne plus dépendre sur des webapps hébergés par des grosses sociétés style Google, Yahoo, etc.

La FBF a publié une page "Leaving the cloud" sur son wiki ou elle ressemble l'ensemble des services que l'on peut utiliser sur internet et propose des alternatives gratuites. Dans le même genre il y a également une page du wiki autonomo.us qui propose des alternatives libres.

Dernièrement, j'avais fait un petit billet sur la suppression des dépôts de Jaunty pour les architectures ARMv5 en disant que Canonical considérait les Sheevaplugs comme obsolètes.
Heureusement, j'ai été trop vite en besogne et les dépôts ont été remis en ligne sur un autre domaine qui permettent de réinstaller Ubuntu 9.04 sur un Sheevaplug pour le restaurer...

En effet, les dépôts n'ont pas été supprimés mais ils ont été bougés sur un autre domaine. Ainsi pour accéder aux dépôts il suffit de se connecter en root et de saisir la commande suivante qui va modifier les sources utilisées par votre système avec les dépôts qui contiennent les anciens paquets :

cat > /etc/apt/sources.list << EOF
deb http://old-releases.ubuntu.com/ubuntu/ jaunty main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ jaunty-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ jaunty-security main restricted universe multiverse
EOF
apt-get update

C'est tout et vous pourrez toujours installer les paquets que vous souhaitez puisque la copie depuis l'ancien domaine semble complète d'après les premiers tests...

Source : Le forum plug-computer.net

Les SheevaPlug sont des machines qui sont disponibles depuis mars 2009, ce qui en informatique est une période assez longue. Par défaut le plug est livré avec la distribution Jaunty (alias 9.04) d'Ubuntu compatible avec les processeurs ARMv5 des SheevaPlugs.
Malheureusement Jaunty ne faisait pas partie des distributions LTS et c'est bien dommage pour le plug-computing...

En effet, c'est vraiment dommage car Canonical, la société qui édite Ubuntu, vient de couper les dépots de binaires ARMv5 de Jaunty. Ainsi il est tout simplement impossible de mettre à jour un plug dans sa configuration standard, c'est à dire utilisant Ubuntu. Ce qui s'avère particulièrement gênant puisque les sheevaplugs sont toujours commercialisés.

Canonical préfère se concentrer sur la nouvelle architecture ARMv7 (dont certains plug sont équipés) en dépit du parc de machine avec un processeur ARMv5 qui est considérable puisque c'est l'architecture de nombreux plug-computer (sheevaplug, guruplug, NSLU2,...)

En conclusion, ne supprimez pas le contenu de la nand de votre plug sous peine de plus pouvoir le mettre à jour car pour l'instant il n'y a pas de mirroirs disponible, mais la résistance commence à s'organiser.

Source : Maisondouf sur forum-plugcomputer.net

La réponse est bien évidement OUI, sinon cet article n'aurai pas lieu d'exister. Mais c'est une question que toute personne intéressée par l'auto-hébergement peux se poser avant de se lancer parce qu'il y a tout de même des paramètres qui entrent en compte et sur lesquels on ne peut pas influer. Le meilleur exemple étant la connection dont on dispose à son domicile.
Mais cela n'empêche pas de faire un site auto-hébergé rapide…

Introduction

Les données qui sont utilisées pour rédiger cet article ont été générés avant, pendant et après mon déménagement, afin de comparer les performances de la SheevaBoite en auto-hébergement et sur un serveur dédié. Pour commencer, voici un bête comparatif de performances entre les deux serveurs qui ont hébergés la SheevaBoite :

Je tiens à préciser que mon débit descendant est bien supérieur à 200 ko/s, cette mesure a été prise avec la télévision en fonctionnement, ce qui est le cas la majorité du temps. Lorsque la télé est éteinte mon débit descendant frôle le 1 Mo/s.

On voit très clairement que au niveau des performances "pures", la SheevaBoite est clairement à la ramasse par rapport au serveur dédié. Mais sans maîtrise, la puissance n'est rien…

Analyse des performances web

Avant de déménager, j'ai mis en place un petit monitoring sur la homepage avec l'excellent outil GTMetrix qui m'a permis d'automatiser des tests quotidiens sur le chargement de la SheevaBoite dont voici le graphique qui résume les 3 mois qui ont été nécessaire pour le déménagement :

Il y a deux marqueurs rouges présents sur l'image, ils représentent les deux jours ou la SheevaBoite a été migrée d'un environnement à un autre.
On voit donc que les performances de chargement de la page se sont améliorées lors du passage sur le serveur dédié avec une diminution du temps de chargement d'environ 300 ms. Et on remarque le contraire lorsque la SheevaBoite est repassée en mode auto-hébergement, augmentation du chargement de la page d'environ 300 ms.

Bon c'est le comportement auquel je m'attendais et qui est totalement normal. Il faut tout de même noter que le delta est important puisque cela représente environ une augmentation de 30% du temps de chargement entre les deux serveurs.
Mais au final afficher une page en moins de 1,5 secondes est une performance tout à fait correcte de nos jours, surtout si l'on est un visiteur du Canada (les serveur de monitoring sont situés à Vancouver)... Et cela est encore plus correct lorsque l'on sait que le site est hébergé chez soi.

Mais cela demande tout de même quelques petits efforts, car comme vous l'avez remarqué la SheevaBoite n'est pas une bête de performances...

Quelques conseils pour un site auto-hébergé rapide…

Voici quelques conseils qui valent ce qu'ils valent mais qui prennent encore plus de valeur lorsque l'on parle dauto-hébergement, ils permettent d'optimiser le temps de chargement :

1. Une home légère,
   C'est une bonne pratique du développement web, mais ce principe est encore plus vrai pour un site auto héberge car c'est la page la plus chargée. Si elle n'est pas optimisée, elle pourrait même faire tomber votre petit serveur…
2. Un CMS adapté,
   Si votre serveur n'est pas très puissant, ne gaspiller pas de la puissance à vouloir faire tourner un Drupal ou un WordPress. J'ai fait le choix de PluXml qui utilise directement des fichiers XML en lieu et place d'une base de données pour sa légèreté et sa rapidité à générer les pages.
3. Utiliser peu d'images,
   Les images sont le nerf de la guerre de la bande passante. Il faut donc les éviter dans la mesure du possible, dans votre thème, dans vos articles. Attention, il ne faut pas les proscrire mais les utiliser à bon escient et surtout les optimiser…
4. Optimisations web O-B-L-I-G-A-T-O-I-R-E,
   Concaténation, minification des ressources avant la mise en prod est une étape obligatoire
5. Utilisez un serveur web performant,
   Aujourd'hui le meilleur choix est nginx qui est beaucoup plus rapide qu'Apache en performance pure. Si vous n'utilisez pas des fonctions spécifiques d'Apache pourquoi ne pas passer à nginx ?

La liste n'est pas exhaustive, ce sont juste les bonnes pratiques qui me sont directement venues à l'esprit lorsque je pensais à de l'auto-hébergement avec un plug-computer…

Conclusion

Vous devez vous en rendre compte en navigant sur la SheevaBoite, faire un site auto-hébergé rapide avec un plug-computer est possible, la SheevaBoite en est l'exemple. Comme je l'ai dit dans l'article cela nécessite de faire quelques petits efforts afin d'alléger le travail du serveur mais ce n'est pas irréalisable...

Auto-héberger son site ou son blog n'est pas un chemin de tout repos. En effet, lorsque vous payez pour un hébergement, c'est la société qui gère les serveurs qui doit intervenir pour régler les problèmes lorsqu'ils se produisent. Ils disposent de nombreux outils de monitoring pour détecter les problèmes au plus vite et ainsi pouvoir les traiter rapidement.
En auto-hébergement, même si on ne dispose pas des mêmes moyens, il faut être capable de réagir vite et généralement lorsque les problèmes surviennent, on est pas chez soi...

Préambule

Dans cet article, je vais parler d'applications pour smartphone, je ne vais traiter que les iPhones et les appareils fonctionnant sous Android. Mais ne disposant pas d'un appareil Android, il est probable que je fasse quelques petites erreurs pour ces appareils.
N'hésitez pas à laisser un commentaire si vous détectez une erreur et je corrigerai si besoin. Et je vais essayer de ne pas faire de troll Apple vs Android...

Monitorer son serveur

Si on veut bien faire son auto-hébergement et que l'on veut obtenir un petit peu de trafic, il faut essayer d'avoir son serveur up au maximum, s'assurer de cela s'appelle du monitoring. On peu surveiller différents aspects de son serveur : la rapidité de la réponse à une requête, la durée pendant laquelle le serveur a été "hors-ligne", ...
Ce qui est important selon moi dans le monitoring, c'est de savoir quand son serveur ne répond plus. Pour savoir cela, il faut faire appel à un service externe qui va s'assurer à un intervalle de temps régulier que le serveur répond. Pour réaliser cette tâche j'ai choisi le service PingDom.

L'application PingDom

Pour monitorer les downtimes de mon blog, j'ai choisi d'utiliser les services de PingDom. Pourquoi avoir choisi ce service alors qu'il en existe des dizaines sur le net ? Je ne me souviens pas d'une raison particulière, mais PingDom propose des fonctionnalités gratuites très intéressantes pour monitorer le status d'un serveur et propose des applications gratuites compatibles pour les appareils iPhone et Android.

Parmi les fonctionnalités intéressantes de cette solutions :

• Notifications en cas de down-time (iphone & android),
• Visualisation de l'historique du monitoring et des temps de réponses,
• Envoi d'un rapport mensuel avec la disponibilité du serveur,
• Configuration du "check" sur la durée (toutes les X minutes) et sur le service (SMTP, FTP, HTTP).

Cependant tout n'est pas rose, il y a quelques petits inconvénients avec PingDom :

• Obligation de créer un compte sur leur site,
• Possibilité de monitorer 1 seul serveur dans la version gratuite.

Et c'est à peu près tout dans les inconvénients... Mais malgré, cela, PingDom est une excellente solution pour monitorer son serveur auto-hébergé et être capable d'agir le plus rapidement possible.

Télécharger gratuitement l'appli PingDom : AppStore – AndroidMarket

Que faire en cas de down time ?

C'est très simple, il faut se connecter au serveur et découvrir ce qui ne va pas... Les causes peuvent être multiples avec un auto-hébergement :

• Plus de connexion internet,
• Reboot du modem, routeur, box de FAI,
• Un service a crashé,
• L'espace disque vient à manquer,
• Tentative de hacking.

L'objectif va être simple, il va falloir se connecter en SSH pour découvrir ce qui se passe, c'est pour cela qu'il peut être ultra pratique d'avoir une application de connexion SSH sur son smartphone. Contrairement à PingDom qui est compatible avec les iPhones et Android, je n'ai pas trouvé d'appli de connexion SSH multi plate-forme. J'ai donc fais des recherches pour Android, mais concernant mon iPhone, j'utilise l'excellente application Prompt lorsque je dois me connecter à un serveur lorsque je suis en déplacement...

L'application Prompt

Prompt est une application iPhone+iPad réalisé par le studio de développement Panic qui est un éditeur apprécié et respecté sur Mac.
Prompt n'est pas gratuit, il coute 3,99€, mais le logiciel fonctionne très bien, en particulier lorsque la connexion réseau n'est pas parfaite. Il faut juste tolérer une latence entre le moment de la saisie au clavier virtuel (amélioré pour faire du bash) et l'affichage dans le terminal.

Télécharger l'application Prompt

L'application ConnectBot

Comme je le disais en introduction, je n'ai pas de téléphone Android, donc je me suis servi de Google pour voir le logiciel de connexion SSH le plus répandu. Il semble que c'est ConnectBot qui est l'appli préférée des utilisateurs Android (je peux me tromper).

Télécharger gratuitement l'application ConnectBot

Conclusion

L'objectif de ce post n'était pas de vous faire acheter ou installer une application, mais de vous faire comprendre que l'on peut être amené à tout moment à devoir faire des actions sur son serveur, cela peut être dans le RER le matin, au restaurant le midi, dans un bar en soirée... Je ne dis pas non plus qu'il faut absolument être d'astreinte pour son serveur 24h/7j mais qu'il convient d'être prêt et d'agir ou non en fonction de ces priorités...
Depuis le mois de mars, je n'ai eu à me connecter sur mon serveur qu'une seule fois pour redémarrer nginx après une configuration foireuse du logrotate dans le bus pour aller au RER... J'étais bien content d'avoir Prompt d'installé sur mon iPhone ce jour là...

Dans l'objectif d'être le plus pro possible, il vaut mieux essayer de minimiser les durées des down-times de son serveur, ça je l'ai déjà dit. Et malgré les applications sur votre iPhone, une excellent couverture 3G, il peut arriver que l'on ne puisse rien faire et qu'il faille attendre d'avoir un accès physique à la machine pour corriger un problème, mais au moins on aura le sentiment d'avoir essayé...

Si vous avez des astuces sur ces problématiques, faites m'en part dans les commentaires, j'en suis très friand. Merci d'avoir tout lu !

L'auto-hébergement est un sujet à la mode, de plus en plus de personnes s'y intéressent et on voit germer des initiatives ayant l'objectif de le démocratiser.
J'ai découvert l'auto-hébergement par hasard alors que je cherchais à monter un serveur personnel pour mon domicile et j'ai longtemps réfléchis avant de me lancer dans cette aventure, voici quelques pensées qui m'ont aidées à prendre ma décision et à me lancer...

Préambule

Tout d'abord, je tiens à dire que j'ai longtemps tergiversé sur la question. J'ai commencé ma démarche au mois de septembre 2010, à l'époque je désirais juste monter un petit serveur pour faire du développement Web et ainsi pourvoir éteindre mon portable lorsque je n'étais pas chez moi.
Lors de mes recherches je suis tombé sur le plug-computing et c'est là que j'ai découvert que certains hébergeaient leur site sur ces "mini-ordinateurs". Ayant envie de me lancer dans la création d'un nouveau blog orienté plus geek, l'auto-hébergement était la solution idéale pour répondre à mes besoins...

Les avantages

Il y a de nombreux avantages d'avoir son serveur auto-hébergé,

• Maîtrise totale de la plateforme

  Lorsque l'on dispose d'un serveur auto-hébergé, on peut faire ce que l'on veut sur le serveur puisque l'on en est le propriétaire. Libre de choisir l'OS que vous voulez y installer, les logiciels que vous utiliserez et de faire la maintenance quand vous voulez...

• Gain de compétences en administration Unix

  En tant que développeur j'ai quelques connaissances en administration, mais depuis que j'ai mon serveur auto-hébergé en fonctionnement j'ai énormément appris dans ce domaine secondaire du web, mais au combien important lorsque l'on héberge un blog par exemple...

• Diminution des coûts d'hébergement

  Une fois le serveur acheté, les dépenses pour le serveur sont quasi-nulles. Certes il faut payer l'électricité et la connexion ADSL mais ce sont des frais que je considère comme normaux dans la vie de tous les jours donc qui n'entre pas dans le coût d'utilisation du serveur.
  Mais mis à part le nom de domaine à renouveler tous les ans, vous n'avez aucun frais pour faire tourner votre serveur.

• Gratification personnelle

  Qui n'a jamais entendu : "C'est moi qui l'a fait" ? Une fois le serveur en ligne, fonctionnel et rapide, il y a un sentiment de fierté qui n'est pas désagréable car en faisant cela, vous êtes un original... La majorité des gens payent un service et pas vous, vous vous débrouillez seul.

• Moins de dépendances des services en lignes

  Une fois le serveur en ligne, vous pouvez y installer autant de web-services que vous voulez : un lecteur de flux RSS, un player de vos MP3, un webmail, un gestionnaire de contact,...
  Cette liste n'est pas exhaustive mais vous pouvez vous affranchir de la dépendance que l'on a de certains géants du web (Google par exemple).

Les inconvénients

Malheureusement, avoir son serveur auto-hébergé n'est pas aussi simple pour tout le monde car il y a tout de même quelques inconvénients...

• Quel sera la disponibilité du serveur ?

  Un domicile n'est pas un centre d'hébergement, c'est logique et on ne peux pas mettre en place toutes les sécurité dont dispose les hébergeurs professionnels. Toutes les coupures internet, les coupures d'électricité, les erreurs de manipulations vont avoir un impact sur les disponibilité de votre serveur et on ne peux pas maitriser tous ces aspects...

• Grosse dépendance sur la connexion ADSL

  On ne maitrise pas la connexion internet, on ne maitrise pas les débits, les incidents réseaux et les problèmes de box qui peuvent survenir à n'importe quel moment. La ligne ADSL est vraiment le "Big Point Of Failure" d'un serveur auto-hébergé, sans connexion à internet le serveur ne sers à rien.

• La machine sera-t-elle suffisament puissante ?

  Au début, on ne sait pas exactement quels seront les services que l'on mettra en place. Personnellement, je pensais mettre en place juste un NAS et un serveur web. Mais aujourd'hui, je suis limité par les capacités du SheevaPlug qui atteint ces limites assez rapidement. Je vais devoir trouver une solution pour continuer l'installation des services que je souhaite mettre en place.

• Gros investissement personnel pour la maintenance

  Comme je l'ai dit en introduction, je ne suis pas administrateur système et il peut arriver que certaines tâches mérite une grosse recherche, de nombreux tests avant de parvenir à un résultat satisfaisant. N'est pas admin sys qui veut...

• Comment auto-hébergé et rester dans la légalité ?

  Colundrum a fait un excellent retour sur le self-hosting et la législation francaise. Il est très compliqué de rester dans la législation tout en hébergeant un site chez soi. Personnellement, je sais que mon blog ne respecte pas les lois, mais mon trafic est faible et je vérifie les commentaires très souvent pour éviter les problèmes.
  Il faut également espérer que son serveur n'est pas hacké, mais c'est une autre histoire.

Conclusion

Au final, auto-héberger son site et ses web-services n'est pas une mince affaire, c'est un investissement qui peut valoir le coup dans le monde du web et apporter une ligne supplémentaire à un CV. Cela peut faire la différence et aider à comprendre les problématiques d'autres travailleurs du web (administrateurs systèmes, responsables d'exploitations,...).
Cela ne fait que deux mois que le serveur est en ligne (quoique pas aujourd'hui) mais c'est vraie satisfaction de voir ce que l'on peut faire avec un tout petit serveur (gros comme un chargeur électrique) et quelques lignes de configuration.

Si vous hésitez à vous lancer, j'espère que cet article vous aura donné envie de le faire et venez partager vos craintes si vous en avez...

Le site plugcomputer.org est le repère de la communauté du plug computing mais ce dernier n'a pas évolué depuis bien longtemps...
Annoncé dans une newsletter et sur leur homepage, ils ont la bonne idée de commencer leur travail de refonte en demandant des retours à la communauté du plug-computing. Une initiative que je juge excellente. Je partage dans la suite les améliorations que je leur ai proposées...

Déjà, je tiens à dire que la charte graphique me convient et que je ne la vois pas changer en tout cas pour le site et le blog. Histoire de partager un peu les améliorations que j'aimerai voir apparaitre sur le site, voici ma liste d'idées...

La partie Forum

• Mettre un lien vers le forum dans le header, le forum est difficile à trouver
• Modification du design avec un thème plus blanc

La partie Blog

• Amélioration du design et de l'affichage des articles
• Refaire la navigation du blog
• Plus de news

En espérant que le site va s'améliorer pour continuer à drainer des utilisateurs experts qui permettent au plug-computing de se démocratiser...

Le principe même de l'auto-hébergement est d'héberger des services web à son domicile. Mais que se passe-t-il lorsque l'on est amené à déménager ?
C'est exactement le problème que je vais rencontrer bientôt pour ce blog et que je n'avais pas anticipé lors de la création de ce blog. Voici quelques explications pour gérer au mieux cette épreuve...

L'objectif est de n'avoir aucune interruption de services pour les visiteurs mais également pour Google. Voici le plan d'action que je vais suivre pour essayer de ne pas être trop impacté par ce déménagement...

Sauvegardez, backupez

Déménager un serveur pour un professionnel est toujours une étape périlleuse, car il y a de multiples risques. On ne sait pas si le transport va bien se passer, on ne sait pas si la machine va redémarrer dans son nouvel emplacement, le réseau est-il prêt, a-t-il été testé auparavant...

C'est exactement la même chose pour un déménagement privé avec un serveur personnel, bien sur je ne souhaite à personne un déménagement galère mais n'oubliez pas de sauvegardez les données de votre serveur de la manière la plus efficace.
Personnellement, j'ai choisi de sauvegarder les données de configuration de l'OS sur une clé USB ainsi que sur un serveur SVN dans les nuages, à priori je suis couvert... Je n'ai pas besoin d'autres backup pour l'instant...

Créer le serveur temporaire

Pendant que le serveur sera hors-ligne, il faut avoir un autre serveur qui va prendre le relais, il existe des hébergements gratuits :

• votre FAI peut fournir un service de page perso,
• des hébergeurs proposent d'héberger gratuitement des pages webs (cas de AlwaysData),
• des hébergeurs offrent un hébergement si vous avez acheté un NDD chez eux (cas de OVH)

C'est l'option AlwaysData que j'ai retenu, bien que l'espace disque du serveur est restreint à 10Mo et le trafic 1Go par mois, c'est la meilleur solution pour mon cas.

Une fois l'option choisie, il faut recréer le serveur avec toutes les fonctionnalités de la prod si possible. Malheureusement si vous n'aviez pas la possibilité de le faire, je vous conseille de prévenir vos utilisateurs que le service est dégradé en raison d'un déménagement avec un bandeau ou un post par exemple.
Bien sur, n'oubliez pas de tester en long en large et en travers votre serveur temporaire pour qu'il colle le plus possible au serveur déménagé.

ATTENTION : Avant de choisir votre hébergement, assurez vous qu'il dispose bien d'une IP statique !!!

Modifier les DNS pour pointer vers le serveur temporaire

Une fois que le serveur de remplacement est prêt et à environ 5 jours du déménagement physique il va falloir modifier les DNS pour qu'ils pointent vers le serveur temporaire. De ce coté là, je n'ai pas de conseil particulier à vous donner, mais faites bien pointer tous les sous-domaines vers la bonne IP.

N'oubliez pas que la propagation DNS prend un peu de temps, en général 5 jours sont suffisants, mais personnellement je ferai la bascule des DNS au minimum une semaine avant mon déménagement physique.

Retour à la normale

Une fois le déménagement physique terminé, il y a la deux étapes pour revenir comme avant, c'est à dire votre sheevaplug redevient votre serveur :

1. reporter les modifications du serveur temporaire vers le serveur,
2. restaurer les DNS pour qu'ils pointent vers votre nouvelle IP fixe.

Une fois ces actions effectués, il faudra attendre encore quelques jours pour que la propagation DNS fasse son travail et pour voir à nouveau des visiteurs sur votre serveur.

Conclusion

Déménager un serveur personnel n'est pas une mince affaire comme pour les professionnels il va falloir prendre des précautions pour garantir la meilleur disponibilité possible. La création d'un serveur temporaire est également une bonne chose dans l'éventualité ou votre serveur crame, vous disposez d'une roue de secours qui sera bien agréable d'avoir en cas de problème. Donc une fois le serveur remis en place, ne supprimez pas les données sur le serveur temporaire.

Si vous avez déjà déménagé votre serveur auto-hébergé, n'hésitez pas à raconter comme cela c'est passé, si vous avez rencontré des galères auxquelles je n'avais pas pensées...