Cet article chez sciunto m'a inspiré. En effet je m'auto-héberge moi aussi depuis 1 an et demi et l'heure est venue de faire un premier point. Voici les services que j'héberge actuellement :

• Serveur mail Postfix, comptes locaux, stockage Maildir et accès IMAP-SSL avec Dovecot.
• Serveur Jabber propulsé par Prosody.
• Serveur web pour l'upload d'images avec jyraphe et la synchronisation de fichiers avec owncloud.
• Serveur DNS pour mon LAN.

Et mes équipements :

• Un réseau à base de VLAN et de pfSense
• Un serveur à base d'Atom 32 bits et 1GB de ram

Motivations

• Apprendre et acquérir de l'expérience

Parce qu'en faisant et refaisant les choses, on apprend. On découvre ainsi les imprévus auxquels on doit faire face et on apprend les bons réflexes pour diagnostiquer les pannes. Avec du recul j'ai l'impression d'avoir acquis de solides bases dans les systèmes unix-like, mais je suis loin d'être un spécialiste et il y a toujours plus à apprendre.

• La liberté sur le choix des composants

Parce qu'on peut avoir envie d'utiliser lighttpd et postresql sur son serveur alors que tous les hébergeurs ne proposent que apache + mysql.

• Indépendance

Parce que je n'étais pas satisfait de mon hébergeur email tant pour des raisons techniques que philosophiques. Mais j'ai appris qu'on ne peut pas avoir la même chose que GMail. Les solutions s'en approchant telles que SOGo induisent un tel niveau de complexité que j'ai fait le choix de rester sur quelque chose de simple. Zimbra est également un bon choix mais demande un serveur "puissant" (avec du 64 bits et 2GB de ram au minimum). Owncloud m'a tuer.

• L'amusement

Parce que mettre un serveur en place pour moi est amusant, je me sens un peu comme un enfant devant une caisse de legos.

Systèmes d'exploitation

• Debian Squeeze

Le premier que j'ai utilisé sur mon serveur. Il est très robuste, très stable, léger, et les paquets sont très nombreux. Je trouve cependant dommage qu'il y ait un tel retard dans les versions des logiciels. Par exemple c'est encore Dovecot 1.x qui est proposé, alors que la 2.x dispose de fichiers de configuration séparés qui sont très utiles. Même remarque pour LXC qui est bien peu mature dans Squeeze.

• NetBSD

C'est avec ce système que j'ai vraiment plongé dans l'univers "des BSD". C'est là que j'ai réellement commencé à utiliser vi, et que j'ai compris la différence entre le système et les ports (pkgsrc). J'ai bien aimé NetBSD mais Debian est plus simple à administrer et mettre à jour.

• OpenBSD

C'est un système humainement compréhensible et très instructif à utiliser. Il est malheureusement en retard au niveau des pilotes et des ports, mais il colle parfaitement dans les rôles orientés sécurité (routeur, passerelle, mta...). J'en garde un bon souvenir.

• CentOS

Je n'ai pas beaucoup eu l'occasion de l'utiliser, parce que les ressources de mon serveur m'orientent vers LXC alors que CentOS se focalise sur KVM. C'est néanmoins un système très robuste et fonctionnel. Il y a beaucoup de différences par rapport à Debian notamment dans l'implémentation des logiciels comme Apache. Le fonctionnement est plus "basique" il n'y a par exemple pas d'outil comme a2enmod.

• Ubuntu Server LTS

Ubuntu Server est une bonne solution, surtout pour les containers LXC. On y retrouve les bons côtés de Debian, avec des logiciels plus à jour. J'ai beaucoup hésité avec Debian Wheezy mais les templates LXC sont bugués. Je tourne donc actuellement avec Ubuntu Server 12.04 LTS.

Sécurité

Pour de l'auto-hébergement les règles de sécurité de base sont suffisantes, par exemple choisir des bons mots de passe, ne pas ouvrir le port SSH si ce n'est pas nécessaire, penser à mettre à jour assez souvent le serveur si celui-ci utlise des composants à risque (php...).

Pour pousser les choses plus loin j'ai isolé chaque service dans un container avec LXC, ce qui ajoute une couche supplémentaire de sécurisation. Le serveur lui-même est situé sur une vraie DMZ gérée par pfSense. Je comptais mettre en place des passerelles SMTP, IMAP et HTTP afin de ne pas exposer directement le serveur sur internet, mais là encore la complexité engendrée m'a découragé.

Dans les logs Apache je note des tentatives d'attaques, des erreurs indiquant que "/phpmyadmin n'a pas été trouvé" (normal car je ne l'utilise pas). Ces tentatives sont probablement automatisées et peu dangereuses si le serveur et les applications sont bien à jour.

Continuité de service

L'endroit où j'habite est plutôt épargné par les coupures électriques ce qui me permet d'avoir un bon uptime. Je n'ai eu qu'un seul gros souci, au mois de Décembre, avec une journée sans électricité suivi d'une semaine sans adsl. J'ai donc loué un serveur kimsufi (le moins cher) pour y installer le rôle de serveur mail (le plus important). Suite au rétablissement de l'adsl chez moi je n'ai pas renouvelé ma souscription au kimsufi.

Si on met de côté cet incident, il faut bien avouer qu'un serveur ça tourne tout seul et demande bien peu d'interventions.

Bruit et consommation

Je dors dans la même pièce que mes équipements réseau et mon serveur, le silence est donc un point primordial pour moi. Le serveur n'a pas de ventilateur et utilise un SSD, ce qui le rend inaudible. Il était historiquement alimenté par du 12V et ~10W, c'est donc une consommation très faible. Suite à une panne du transfo il tourne maintenant sur un chargeur universel. Il est donc tout à fait possible de "cohabiter" avec un serveur.

Conclusion

L'auto-hébergement a toujours été satisfaisant et suffisant pour moi. Je me suis souvent intéressé aux serveurs dédiés ou aux VPS, mais au final je me suis toujours demandé "pourquoi?". Mon serveur bien que faiblard est suffisant pour mes besoins.

J'encourage toute personne motivée à se lancer. Je suis également disposé à donner un coup de main à ceux qui ont besoin !

Liens à consulter

• NetBSD Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6 et conclusion.
• OpenBSD Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6, Épisode 7 et conclusion.
• Retour sur pfSense.
• Me passer des services Google Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5 et conclusion.
• Faire son serveur mail sous Ubuntu.
• Serveur mail sous CentOS.
• Serveur mail sous NetBSD.
• Linux, NetBSD, OpenBSD.
• Un serveur mail sous OpenBSD
• Un aperçu de SOGo.

Ce n'est que mon avis, mais pour moi la neutralité du net est une question de réseau. Or dans le cas de Free, le blocage de la pub s'opère sur la freebox, et surtout il est complètement désactivable. La Freebox elle même est optionnelle et ne fait pas partie du réseau, on peut donc dire que ce blocage (désactivable) porte sur un service de Free et non pas sur internet.

Un cas d'atteinte à la neutralité du net est par exemple l'Angleterre qui bloque l'accès à TPB. Tous les FAI de ce pays ont pour consigne de ne pas acheminer les paquets vers certaines adresses IP, ce qui pour le cas est une atteinte à la neutralité. Plus proche de nous il y a également les FAI interdisant l'usage du port 25 tcp sortant, nous empêchant ainsi de faire un vrai serveur mail.

J'aimerais que l'on laisse la neutralité du net là où elle est, qu'elle soit invoquée uniquement dans les affaires graves et pas quand un blogueur ou un site monte au créneau contre Free.

EDIT : apparemment Benjamin Bayart pense la même chose. Merci jsupejve.

Voilà maintenant 4 mois que mon serveur tourne sous Ubuntu 12.04 et propulse des VPS sous LXC. J'aime le côté prêt à l'emploi, en quelques lignes on obtient un container fonctionnant aussi bien qu'un serveur physique. A titre de comparaison je me suis cassé les dents avec les jails de FreeBSD, puisque named (daemon DNS) ne semble pas fonctionner (par défaut il essaie de se lancer en chroot, chose visiblement impossible dans une jail).

Par contre cela a aussi des inconvénients, par exemple l'implémentation LXC de ubuntu fournit un réseau avec du NAT par défaut. Ceci est idéal quand on est pressé, mais pas quand on veut paramétrer proprement son réseau avec un parefeu en amont, cela oblige à modifier la configuration.

J'ai testé jusque là 5 systèmes (disponibles en templates ou par bidouillages) :

• Ubuntu : OK
• Debian : OK
• OpenSuse : OK
• Fedora : ECHEC (yum n'est pas présent donc le template échoue)
• Archlinux : ECHEC (malgré une procédure identique à opensuse je n'ai pas réussi à le booter)

Je trouve que LXC est une très bonne solution d'appoint pour créer des VPS et fonctionne aussi bien que la virtualisation KVM, à condition de faire tourner des systèmes Linux. J'ai hâte de voir ce que nous réserve l'avenir, et j'attends beaucoup de l'intégration libvirt et openvswitch ;)

$ sudo lxc-list
RUNNING
  dns
  jabber
  mail
  mx
  web

A bientôt !

DragonflyBSD est un système d'exploitation visant à obtenir de meilleures performances que FreeBSD dont il est dérivé. C'est probablement l'un des plus discrets à côté de FreeBSD, NetBSD et OpenBSD et je n'y avais jamais touché avant que ce journal sur linuxfr ne m'en donne envie.

Les développeurs sont partis de FreeBSD 4 et ont opté pour des choix techniques différents dans la gestion des processeurs multiples (SMP). Ils ont aussi lancé un nouveau système de fichiers HAMMER offrant plus de souplesse et de performances qu'UFS.

Dans cet aperçu je me contenterai de l'aspect serveur, qui est pour moi le plus intéressant. J'ajouterai que ce n'est pas un retour d'expérience, je ne l'ai pas mis en production (ça viendra peut-être), mais juste un premier essai.

Installation

On peut difficilement faire plus simple puisqu'il s'agit d'une suite de menus permettant de partitionner son disque en choisissant le système de fichiers UFS ou bien HAMMER. Pas de choix dans les sets d'installation, tout va à l'essentiel. Il est tout de même possible de configurer son clavier, horloge, réseau, mot de passe root.

Sources du système et logiciels tiers

DragonflyBSD, tout comme les autres systèmes *BSD, est en fait un système d'exploitation avec plusieurs logiciels intégrés dans les branches de développement qui reçoivent du support et des correctifs (SSH, sendmail...). Si l'utilisateur souhaite installer un autre logiciel (par exemple Dovecot) il peut le récupérer par l’intermédiaire de pkgsrc. Un logiciel ne faisant pas partie du système ne reçoit pas de patchs de l'équipe de développement, il s'agit en fait de la version "normale" (vanilla) avec un jeu de scripts permettant le lancement sur le système.

Les sources du système servent pour les mises à jour et la compilation de pilotes ou de certains outils. Elles ne sont pas fournies sur CD mais on peut les télécharger en entrant tout simplement la commande suivante :

cd /usr
make src-create

Pour les logiciels additionnels, DragonflyBSD utilise pkgsrc, issu de NetBSD, contrairement à FreeBSD qui utilise les ports. Au final le principe reste tout de même plus ou moins indentique. Pour récupérer pkgsrc, la commande est la suivante :

cd /usr
make pkgsrc-create

J'aime bien ce principe qui est assez simple pour récupérer les sources ! Notez cependant que la documentation recommande de passer par les packages précompilés ou bien par pkgin (gestionnaire de paquets un peu plus abouti).

Les mises à jour du système se font par compilation, il faut tout d'abord récupérer les sources puis lancer un buildworld suivi des commandes suivantes qui vont bien, comme pour FreeBSD.

Administration

DragonflyBSD utilise un fichier rc.conf dans lequel on indique les paramètres du système (nom d'hôte, réseau...) ainsi que les services à démarrer. Rien de neuf de ce côté, mais c'est donc simple et efficace.

Pour gérer les services, il faut invoquer les scripts rc. Par exemple, pour lancer le daemon ssh :

# /etc/rc.d/sshd start

On peut automatiser le démarrage de sshd en ajoutant dans notre rc.conf la ligne suivante :

sshd_enabled="yes"

On garde un fonctionnement et une administration faciles à comprendre, à la portée de tous. Les habitués des systèmes *BSD ne seront pas dépaysés.

Difficultés

J'ai eu beaucoup de mal à récupérer pkgsrc, car pour une raison étrange le système arrivait à court de mémoire et de swap. J'avais pourtant respectivement 1GB et 2GB, ce qui me semble largement suffisant pour un système en mode texte.

Comme je faisais mes tests sous VMware je suis passé sous VirtualBox mais là encore le problème s'est reproduit.

Je suis allé faire un tour sur le salon IRC de dragonflybsd pour y exposer mon problème, et on m'a conseillé d'éditer /usr/Makefile pour y commenter les lignes contenant la commande :

git gc --aggressive

Et le problème est résolu.

Conclusion

Le système est globalement très proche de FreeBSD mais apporte une valeur ajoutée sur beaucoup de composants. Il est simple à utiliser et à administrer. Un excellent choix pour un serveur, j'espère avoir un jour l'occasion de travailler avec et d'en apprendre plus.

Si vous essayez d'installer Windows 8 dans Linux-KVM vous allez rencontrer le bug suivant :

Your PC needs to restart.
Please hold down the power button
Error Code: 0x0000005D
Parameters:
0x03060203
0x756E6547
0x49656E69
0x6C64746E

Il s'agit d'une réaction au type de CPU affiché par Linux-KVM (Qemu Processur), la solution consiste à copier la configuration du CPU hôte afin que ce dernier s'y retrouve. Pour cela ouvrez les paramètres de votre VM, allez dans "Processor" puis "Configuration" et cliquez sur "Copier la configuration CPU de l'hôte".

Vous pouvez maintenant virtualiser Windows 8 sous Linux sans devoir installer VirtualBox ou VMware !

Merci à Regardt van de Vyver