L'interface d'administration de la BBox est accessible via l'url suivante : gestionbbox.lan. Utiliser l'adresse IP (par défaut 192.168.1.254) redirige vers gestionbbox.lan. Que se passe-t-il si vous utilisez un serveur DNS perso et pas celui de la BBox ? Réponse : le nom de domaine gestionbbox.lan n'existe pas, et l'interface est alors inaccessible. Heureusement cela peut se corriger rapidement, il suffit de créer une zone. Voici les paramètres à ajouter pour bind.

/etc/bind/named.conf.local (ou named.conf selon la distribution) :

zone "gestionbbox.lan" {
        type master;
        file "/etc/bind/gestionbbox.lan";
};

/etc/bind/gestionbbox.lan :

$TTL    604800
@       IN      SOA     gestionbbox.lan.     hostmaster.gestionbbox.lan. (
                                1               ; Serial
                                604800          ; Refresh
                                86400           ; Retry
                                2419200         ; Expire
                                604800 )        ; Negative Cache TTL

;
@       IN      NS      gestionbbox.lan.
@       IN      A       192.168.1.254

Les jails permettent de créer des VPS sur un système FreeBSD. Les processus sont emprisonnés dans un niveau d'exécution et un environnement distinct. L'équivalent sur Linux est OpenVZ / VServer / LXC mais le système de jails sous FreeBSD est intégré au système et plutôt mature.

La documentation de FreeBSD décrit le processus manuel de création de jails. Je recommande la lecture et le suivi de l’exercice proposé afin d'acquérir les bases. Il est aussi mentionné la possibilité d'utiliser un "squelette" commun à toutes les jails, ces dernières n'ayant que les répertoires susceptibles d'être modifié. Cela évite d'avoir 10 fois la même arborescence alors que beaucoup d'éléments sont communs. ezjail est un outil permettant d'automatiser tout ceci, et nous allons voir que c'est plutôt bien foutu.

Installation de FreeBSD

Depuis la version 9, l'installeur a été simplifié au point qu'il n'est plus nécessaire de le détailler. Le choix des sets importe peu sur le résultat final, mais personnellement j'ajoute les sources car j'estime que cela fait partie de l'OS.

La suite de l'installation ne nécessite pas de paramétrage particulier.

Configuration

Vous pouvez commencer par mettre à jour le système :

# freebsd-update fetch
# freebsd-update install
# reboot

Nous allons maintenant installer ezjail. Il y a deux solutions : le compiler à partir des ports, ou le télécharger sous forme binaire avec pkg_add.

Méthode 1 : ports

Commencez par télécharger l'arbre des ports :

# portsnap fetch extract

Puis compilez et installez sysutils/ezjail :

# cd /usr/ports/sysutils/ezjail
# make install clean

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Méthode 2 : pkg_add

Utilisez la commande suivante :

# pkg_add -r ezjail

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Création de la jail de base

La commande suivante va préparer la jail de base :

# ezjail-admin install

Création d'une jail

Utilisez la commande suivante :

# ezjail-admin create dns 'em0|192.168.0.2'

Démarrer une jail

Voici la commande :

# ezjail-admin start dns

Arrêt d'une jail

ezjail-admin stop dns

Mise à jour des jails

La jail de base va être mise à jour, ce qui va répandre les modifications sur toutes les jails.

# ezjail-admin update -u

Suppression d'une jail

La commande est la suivante :

# ezjail-admin delete -wf dns

Modifier le "modèle" des jail

Cas concret : vous voulez activer SSH sur toutes les jails créées. C'est faisable ! La jail "modèle" est située ici : /usr/jails/newjail. Donc il faut éditer/créer le fichier /usr/jails/newjail/etc/rc.conf :

# echo sshd_enable="YES" >> /usr/jails/newjail/etc/rc.conf

Et voilà !

Documentation

D'autres usages sont possibles, certains seront intéressés par les possibilités offertes avec l'intégration ZFS.

• Site officiel ezjail : Très pauvre, mais les bases sont là.
• Utiliser la commande man ezjail-admin directement sur FreeBSD, c'est très complet.

Dans l'épisode 1 je signalais des freezes à répétition sur DragonflyBSD fonctionnant dans VMware. Le problème s'est reproduit sur une autre VM qui avait été épargnée jusqu'ici. J'ai donc migré de VMware à VirtualBox (il suffit de créer une VM en utilisant le disque .vmdk existant, puis de changer le contrôleur IDE en SAS) pour voir si les choses s'améliorent.

Les warning kernel qui s'affichaient semblent avoir disparu... en revanche j'ai toujours des avertissements relatifs à "sendmail/postfix" (quoi ? sendmail ? je me suis battu des heures pour qu'il se taise car j'utilise postfix !! ). L'autre point étrange c'est que je reçois par mail des rapports de fonctionnement (logwatch) qui me signalent l'existence de vulnérabilités dans les paquets tiers installés :

Fetching package vulnerabilities database:

Checking pkgsrc packages for vulnerabilities:
Package perl-5.14.2nb5 has a arbitrary-code-execution vulnerability, see http://secunia.com/advisories/51498/
Package perl-5.14.2nb5 has a denial-of-service vulnerability, see http://secunia.com/advisories/52472/
Package dovecot-2.1.9 has a denial-of-service vulnerability, see http://secunia.com/advisories/51455/
Package curl-7.27.0 has a remote-system-access vulnerability, see http://secunia.com/advisories/52103/
Package curl-7.27.0 has a remote-information-disclosure vulnerability, see http://secunia.com/advisories/53051/
Package scmgit-base-1.7.12nb1 has a man-in-the-middle-attack vulnerability, see http://secunia.com/advisories/52361/

C'est très bien mais... que puis-je faire ? Ces logiciels ont été installés à partir de pkgin et ils sont déjà à jour. A quoi bon me signaler l'existence de vulnérabilités puisque je ne peux rien faire à part attendre que ce soit corrigé dans les dépôts de pkgin ? Mieux : pourquoi y a-t-il autant de vulnérabilités sur les logiciels fournis par pkgin ???

Du côté de FreeBSD difficile de juger, puisque l'outil pkgng (équivalent de pkgin) n'est pas pleinement utilisable. En effet les dépôts publics sont fermés depuis plusieurs mois suite à des problèmes de sécurité ! Donc le seul moyen de tester pkgng c'est de créer vous-même votre dépôt... Ce que je n'ai pas vraiment envie de faire.

DragonflyBSD offre beaucoup de points intéressants, mais semble avoir des problèmes de comportement en environnement VMware et avec certains logiciels tiers. FreeBSD est encore en phase de transition vers pkgng mais se comporte plutôt bien dans les différents cas où je l'ai testé.

J'ai mis en place plusieurs machines virtuelles sous VMware qui ont les rôles suivants :

• Un serveur DNS sous FreeBSD 9.1 amd64
• Un serveur Jabber sous DragonflyBSD 3.2 x86_64
• Un serveur mail sous DragonflyBSD 3.2 x86_64
• Un serveur web sous CentOS 6.4 x86_64

FreeBSD et CentOS se comportent bien, en revanche DragonflyBSD ne semble pas aimer VMware. Parfois le boot n'aboutit pas, parfois le système se freeze. A l'heure où j'écris ce billet, le serveur Jabber ne répond pas, alors que le mail oui. Ce qui me laisse penser que la VM Jabber a planté.

La gestion des ports (tous systèmes *BSD confondus) est à mon sens problématique, surtout lors de l'installation d'un logiciel qui en remplace un autre dans le système de base (Postfix pour Sendmail par exemple). DragonflyBSD embarque pkgin qui facilite l'installation mais pas la configuration. Cas concret : j'ai installé Postfix sur DragonflyBSD pour remplacer Sendmail (car je ne le connais pas du tout). La configuration s'est bien passé, la réception des mails fonctionne. En revanche en installant fetchmail je me suis rendu compte que le système s'appuyait sur Sendmail. Or comme ce dernier n'est pas configuré, les messages ont été envoyés dans une dimension parallèle.

Une distribution Linux sous forme de paquets RPM ou DEB me semble donc bien plus propre que la séparation "world" et "port" que l'on trouve sous FreeBSD et les autres. Sous Debian l'installation de Postfix retire complètement Exim les risques de confusion sont donc réduits. Sous FreeBSD et dérivés, l'impossibilité de retirer Sendmail (sauf par recompilation du world avec le bon src.conf) peut au contraire poser des problèmes.

Je dois quand même dire que Pkgin est un excellent outil qui permet d'avoir une vraie gestion des paquets et de leur mises à jour. Étant implémenté dans NetBSD et DragonflyBSD il est amené à évoluer assez rapidement. Quelques exemples d'utilisation :

# pkgin update
# pkgin search postfix
# pkgin install postfix
# pkgin upgrade

Si on s'en tient au système de base, tout va beaucoup mieux. L'implémentation de Bind sous FreeBSD est très correct et chrootée par défaut. Les fichiers sont situés dans /var/named/etc/namedb mais vus par l'application comme /etc/namedb. La mise en place de mon fichier de zone s'est bien passé, ainsi que l'ajout d'un fichier named.conf.local appelé par un Include (oui je suis trop habitué à Debian et aux fichiers de configuration modulaires).

A bientôt pour de nouvelles aventures.

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.