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.

Cela va bientôt faire 3 mois que j'utilise pfSense, un système d'exploitation FreeBSD orienté routeur. En 2011 j'avais déjà rédigé un article dessus, mais depuis Juillet 2012 je l'ai mis en "production" avec fonctionnement 24h/24 et conditions réelles. Plusieurs points m'ont particulièrement plu dans pfSense, je vais les décrire ci-dessous.

Voici les fonctionnalités que j'exploite actuellement :

• NAT et PAT
• Firewall (DMZ)
• Serveur DHCP
• Client OpenVPN
• Routes statiques
• 3 VLAN taggés sur un unique port
• Casé sur une carte CF
• 4 postes utilisateurs sur le VLAN30, 4 serveurs sur le VLAN20 (dmz)

Notez qu'il y en a de nombreuses autres que je n'utilise pas : serveur NTP, DNS, relai DHCP, IPSec, la liste est longue...

Fiabilité

Pour l'instant, 79 jours d'uptime, ça peut paraître peu mais comme je l'ai dit précédemment cela ne fait que 3 mois. Les derniers redémarrages ont été volontaires pour des opérations de mise à jour ou des coupures en cas d'orage. Il faut aussi comparer cela à une merdebox domestique qui nécessite un reboot quasi journalier pour rétablir l'accès à internet. Bref, pfSense c'est fiable, ça tourne sans interruption.

Fonctionnalités

J'apprécie particulièrement que cette petite boite noire (Alix 1.d) soit capable de gérer à elle toute seule l'intégralité du réseau. J'ai ainsi pu y "greffer" mon VPN, mais aussi un serveur DHCP. Et les autres points appréciables concernent les outils de diagnostic. On peut faire des ping, visualiser les tables de routage, arp, traceroute, et il y a même un sniffeur de réseau réglable sur plusieurs niveaux de verbosité.

Simplicité

Tout est bien organisé, facile à trouver et à utiliser. Les changements sont pris en compte sans devoir redémarrer le routeur (là encore, comparaison aux box domestiques) ce qui est appréciable. Les tableaux récapitulatifs des règles de parefeu sont assez bien pensés. La configuration peut être exportée dans un fichier XML si vous désirez "formater" la machine (pour une mise à jour par exemple).

Conclusion

Je ne regrette pas le choix de pfSense comme solution pour gérer mon réseau :D toutes les qualités que l'on peut rechercher y sont, avec la souplesse, la simplicité et la fiabilité. C'est une appliance excellente qui n'est pas prête de me lâcher !

J'ai installé FreeBSD 9.1RC sur un ordinateur portable équipé d'un processeur Sandy Bridge (puce graphique intégrée dedans, Intel® HD Graphics 3000). Les pilotes graphiques Intel sont très bien réputés car ils sont libres, à jour, et développés par le constructeur ! Que demander de mieux ?

C'est donc avec une (très) grande surprise que j'ai découvert que les puces graphiques Intel ne sont pas supportées sur FreeBSD. Si j'en crois cet article de Phoronix, la raison est qu'Intel ne travaille qu'en KMS (Kernel Mode Setting), disponible uniquement sur Linux. Donc, pour FreeBSD, toute machine tournant sur un processeur graphique Intel fonctionne sur le pilote vesa en 1024x768... et je ne parle pas de l'accélération 2D et 3D. Heureusement(?), FreeBSD est en train de développer son Kernel Mode Setting afin de pouvoir faire tourner les pilotes graphiques qui ne sont compatibles qu'avec ça. On peut trouver sur les forums une procédure pour activer KMS sur le système et compiler le pilote Intel qui va bien. Malheureusement c'est très long et le résultat est un peu aléatoire (j'ai réussi mais je n'avais plus de souris).

Etant donné qu'AMD ne fourni pas de pilotes pour FreeBSD, il semble que le seul "bon" constructeur sous cet OS soit Nvidia. En effet, même pour les cartes haut de gamme (GTX600), on trouve des pilotes FreeBSD.

Est-il acceptable de faire des pilotes pour Xorg fonctionnant uniquement sur Linux ? Cette dépendance est une des reproches que l'on fait à systemd et à Lennart Poettring [combo troll] pour ses propos sur les systèmes *BSD. La notion de "bon" constructeur ne se résume donc pas à la licence.

Voici une petite bidouille pour transférer un serveur OpenBSD physique vers une machine virtuelle (VMware dans mon cas, mais cela devrait fonctionner avec tous).

A moins de faire une mauvaise commande, il n'y a aucun risque pour le serveur car on ne modifie rien dessus.

Etape 1 : installation de la VM

Ici, rien de particulier. Récupérez une ISO d'OpenBSD et effectuez l'installation dans une machine virtuelle. Configurez le réseau afin d'avoir un accès SSH.

Etape 2 : lister l'essentiel sur le serveur physique

Si je liste ce que contient mon serveur, voilà ce que j'obtiens :

$ ls /
altroot boot    bsd.mp  dev     home    obsd    sbin    sys     usr
bin     bsd     bsd.rd  etc     mnt     root    stand   tmp     var

Mon serveur fait tourner OpenSMTPD dont la config se trouve dans /etc et les messages dans /home. Vient ensuite dovecot installé à partir des ports, ses fichiers se situent dans /usr (et la config dans /etc). Et pour finir, prosody qui vient lui aussi des ports et exploite une base de données située dans /var. La liste des répertoires à transférer est donc :

• /etc
• /home
• /usr
• /var

Etape 3 : sauvegarde des répertoires

On utilise un bon vieux tar (vous pouvez utiliser la compression en rajoutant l'argument z) :

# tar -pcvf etc.tar /etc/
# tar -pcvf home.tar /home/
# tar -pcvf usr.tar /usr/
# tar -pcvf var.tar /var/

Attention à ne pas travailler dans le répertoire /home lorsque vous faites la deuxième commande ! Sinon cela ne terminera jamais (il va archiver le fichier d'archive nouvellement créé, etc).

Etape 4 : transfert des archives sur la VM

Le plus simple est d'utiliser le protocole sftp (actif du moment que sshd est actif sur vos systèmes). Cela peut-être fait depuis Filezilla sur une tierce machine (avec les comptes root).

Etape 5 : Rétablissement des utilisateurs

Pour des raisons de sécurité, le fichier contenant les utilisateurs du système et leurs mots de passe est en lecture seule, même pour root (voir cette page). Vous devez utiliser l'outil vipw pour les importer.

Ouvrez vipw sur l'ordinateur hôte, copiez toutes les lignes situées après la ligne "nobody", et collez-là à la suite dans le vipw de la VM (vous pouvez faire cette opération depuis un ordinateur tiers et des connexions SSH).

Etape 6 : installation sur la VM

La procédure est classique, sauf qu'il faut penser à sauvegarder le fichier fstab car le partitionnement peut différer :

# tar -pxvf var.tar -C /
# tar -pxvf usr.tar -C /
# tar -pxvf home.tar -C /
# cp /etc/fstab /root/
# tar -pxvf etc.tar -C /
# cp /root/fstab /etc/
# reboot

Pensez à revoir la configuration du rc.conf, notamment le nom d'hôte et le réseau qui peuvent différer.

J'étais parti pour porter mon serveur sur FreeBSD et remplacer la virtualisation par un système de jails. L'installation est simple, on a notamment tout une page sur la mise en place d'applications ainsi que des tutos permettant de combler les parties manquantes, comme la configuration du réseau.

Si tout cela se fait presque les doigts dans le nez, je me suis rapidement heurté à un problème de poids : l'impossibilité de faire fonctionner les jails avec un réseau virtuel. En gros toutes vos jails sont en bridge (en vrai c'est un alias) sur votre interface principale, ce qui peut causer des soucis dans plusieurs cas :

• Votre serveur a une IP publique (unique, impossible d'en faire un bridge/alias)
• Votre routeur est une Livebox qui refuse de rediriger en aveugler un port vers une IP (elle veut absolument un PC qu'elle connaît sur le réseau)

La fonctionnalité de réseau virtuel semble en développement mais nécessite des patchs sur l'OS ainsi qu'une configuration fastidieuse... sur les forums nous apprenons également qu'il y a des fuites de mémoire (on parle d'une fonctionnalité expérimentale, rappelons-le).

Etant donné que je dispose d'une Livebox comme routeur, il m'est impossible de rediriger les ports extérieurs vers les jail. Donc mon plan tombe à l'eau, il ne me reste plus qu'à me tourner vers une solution Linux+LXC qui semble bien plus permissive sur ce point.

Pour info, la compilation de FreeBSD au complet sur un AMD Geode (500Mhz) prend environ 20 heures.