1. L'OS en lui-même
FreeBSD est un Operating System complet. FreeBSD n'est pas un noyau agrémenté d'une collection de logiciels plus ou moins empaquetés autour, empaquetage fait par qui veut bien selon sa logique plus ou moins tordue et ses outils plus ou moins efficaces. FreeBSD est beau. FreeBSD est grand. FreeBSD dispose de sa propre libc. FreeBSD possède ses propres outils UNIX comme sed, awk, vi, cut, tr, ed, sh. FreeBSD n'utilise pas les autotools. FreeBSD utilise make(1). FreeBSD te rendra soyeux comme un pull en poils de bouquetins. FreeBSD est composé d'un noyau et d'un système de base, appelé dorénavant "basesystem". FreeBSD est cohérent dans son approche d'UNIX. FreeBSD a le même comportement quelle que soit la version de FreeBSD que tu utiliseras. FreeBSD est libre. FreeBSD est sécurisé. FreeBSD est taillé pour le réseau. FreeBSD est facile à installer. FreeBSD est multitâche, multi-thread, multi-CPU. FreeBSD est compatible POSIX. Amen.
2. Le FS (slices + partitions)
Le premier contact avec un OS se fait généralement à l'installation. Et là , FreeBSD diffère de GNU/Linux sur quelques points, notamment la gestion des systèmes de fichiers. En effet, FreeBSD dispose d'une "couche" en plus, qui permet de partitionner plus finement un disque. Cette couche s'appelle un slice, et on utilise généralement un slice qui couvre tout le disque. Néanmoins, on peut être assez dérouté par le nommage entraîné par les slices. Un slice est une partition MS-DOS encore appelée "partition primaire". C'est une spécificité des plateformes compatibles PC.
Exemple :
/dev/da0s1a 738M 45M 634M 7% / /dev/da0s1f 984M 110M 795M 12% /tmp /dev/da0s1g 29G 10G 16G 39% /usr /dev/da0s1e 984M 703M 202M 78% /var /dev/da0s1h 35G 29G 3.3G 90% /data/zone1 /dev/da1s1e 275G 138G 115G 54% /data/zone2
Décortiquons cela ensemble. Une entrée concernant une partition sous FreeBSD aura cette allure : /dev/daXsYz
da : nom d'un disque SCSI standard (man 4 da). Dans le cas d'un disque IDE, on aurait ad à la place (man 4 ad).
X : numéro du périphérique dans l'ordre du BIOS.
Y : numéro du slice.
z : lettre de la partition.
Les slices sont numérotés dans l'ordre des partitions DOS MBR présentes sur le disque. Il est à noter que FreeBSD ne reconnaît que les partitions primaires. Lorsque z est la lettre "c", cela représente le slice où FreeBSD est installé.
On peut également noter que les slices sont une spécificité du monde x86 (eh oui, sur SPARC, il n'y a pas de partitions DOS) et que si le seul OS est FreeBSD, on n'a même pas besoin de slices.
3. Le nom des périphériques (fxp/em/toussa vs eth)
Autre point déroutant pour une personne jouant avec le réseau : les noms des périphériques. Sous Linux, les cartes réseau "filaires" s'appellent ethX quelle que soit la carte. Sous BSD, le nom du périphérique est lié au driver : fxp pour les cartes Intel, rl pour les Realtek, ste pour les DLink... Assez perturbant au premier abord, ce système permet de savoir plus facilement sur quelle carte réseau (physique) on agit. Lié au ifconfig de BSD (cf. plus bas), cela se révèle un outil de diagnostic parfois salvateur (essayez sur une machine avec 6 interfaces réseau et vous serez convaincu).
4. La séparation nette système de base/ports
La séparation assez nette entre le système de base et les ports a une conséquence qui peut se révéler assez consommatrice de temps. Sous GNU/Linux, les configurations sont (dans 95% des cas) placées dans /etc, or FreeBSD possède 2 endroits pour stocker les configurations : /etc pour ce qui concerne le système de base (/etc/ssh par exemple) et /usr/local/etc pour ce qui concerne les ports (/usr/local/etc/postfix par exemple). Il en va de même pour les scripts rc avec /etc/rc.d et /usr/local/etc/rc.d.
5. Les ports/systèmes de paquetage
Pour installer un logiciel sous FreeBSD, on utilise un système appelé "port". De nombreux systèmes pour les exploiter existent (utilisation de base, portupgrade, portmaster) et permettent de choisir plus ou moins facilement entre les différentes versions des logiciels. De même, compiler ses programmes permet de choisir certaines options et d'en abandonner d'autres (les utilisateurs de Gentoo ne seront pas trop perturbés, puisque le système qu'ils utilisent est une adaptation des ports BSD). Mais cela se révèle parfois à double tranchant (un serveur LDAP qui ne démarre plus parce qu'on a activé une option liée aux threads et vous met votre authentification en l'air est un bon exemple). Mais les barbus ont pensé à ça, et les informations concernant les mises à jour se trouvent dans /usr/ports/UPDATING qu'il faut systématiquement consulter avant toute mise à jour.
6. Les versions
FreeBSD dispose de deux principaux axes de développement liés à son architecture : le basesystem et les ports. Chacun possède des versions, marquant une étape dans le développement.
Le système de base se voit ainsi attribuer 3 tags intéressants (pour nous) : RELENG_X_Y, RELENG_X et HEAD. RELENG_X_Y est fait pour les gens qui désirent avoir une version précise de FreeBSD avec les patches de sécurité inclus et les correctifs affectant la stabilité du système. X désigne le numéro de version majeure et Y le numéro de version mineure.
Exemple : RELENG_5_4 va installer la version 5.4 de FreeBSD ainsi que tous les patches de sécurité, ce qui donnera un 5.4-RELEASE-p11. Prendre un tag RELENG_X_Y est l'assurance d'avoir un système stable et surtout dénué de difficultés de mises à jour.
RELENG_6 va vous installer la version 6.x de FreeBSD la plus récente. C'est la branche appelée "STABLE", et lorsque le développement de FreeBSD fait que FreeBSD passe d'une version mineure à une autre, vous y allez aussi. Les auteurs de cet article utilisent STABLE sur des machines en production et n'ont pas rencontré de problèmes lors des mises à jour. Bien entendu, -STABLE bénéficie aussi des mises à jour de sécurité.
HEAD enfin, est la branche de développement de FreeBSD, aussi appelée "CURRENT". C'est bien entendu la branche la plus instable, étant donné que c'est elle qui contient toutes les dernières nouveautés du développement. Cette branche est déconseillée pour de la production.
Passons aux ports. Les ports possèdent aussi des tags qui, à vrai dire, ne servent que pour identifier les versions ayant servies à générer tous les packages fournis avec une release officielle de FreeBSD, et qui ne sont jamais mis à jour. On ne va donc s'intéresser qu'à HEAD (alias CURRENT alias ".") qui sert au quotidien. CURRENT intègre toutes les dernières modifications sur les ports que les développeurs de FreeBSD auront faites, ainsi que les correctifs de sécurité. Il est plus que recommandé de lire /usr/ports/UPDATING avant de faire une mise à jour d'un port. Par exemple, le port d'OpenLDAP a récemment subi une transformation et utilise maintenant BerkeleyDB en version 4.4 pour son backend au lieu de la version 4.3. Il est indiqué dans /usr/ports/UPDATING comment faire une sauvegarde, puis une restauration de sa base de données dans le cas où quelque chose se passerait mal pendant la mise à jour.
7. La mise à jour
Justement, la mise à jour. Il faut avant tout mettre à jour les sources du système. On peut voir cette opération comme l'équivalent du apt-get update de Debian, tandis que la mise à jour en elle même sera le apt-get dist-upgrade, qui se fera via recompilation dans /usr/src, ou utilisation de sysinstall(8) pour l'upgrade binaire du basesystem. La page de manuel build(7) de FreeBSD récapitule bien la procédure de mise à jour (recompilation du basesystem). La mise à jour des sources se fait généralement via l'outil cvsup, mais on lui préfèrera son successeur csup (écrit en C et inclus dans le basesystem depuis peu de temps), ainsi que portsnap(8) pour les ports. Il est également recommandé de lire /usr/src/UPDATING avant de tenter quoi que ce soit.
La mise à jour binaire et/ou source des ports se fait, elle, via un outil tiers comme portupgrade(1) ou portmaster(8). Il faut bien entendu avoir mis à jour au préalable les sources des ports. Voir pour tout ceci l'article traitant de ce sujet dans le présent magazine.
8. Les différences
8.1 La philosophie très carrée
FreeBSD, c'est un peu comme un sergent instructeur de film américain. C'est carré, bien rasé et ça a un t-shirt près du corps. Quand on installe un port, il faut spécifier (via la modification de /etc/rc.conf) si le logiciel doit être lancé au démarrage. Le système ne le fera pas pour nous. Pas de scripts de post-install qui vont tout configurer pour nous. Par contre, une documentation efficace est systématiquement fournie. Les exemples sont commentés, et généralement concrets (/usr/local/share/doc et /usr/local/share/examples pour les ports : enlever le local pour le basesystem).
8.2 Le système d'init
Le système d'init des BSD est quelque chose de complètement différent de l'init des SystemV.
Nous allons rapidement nous rappeler comment démarre un Unix System V, puis nous allons ensuite voir quelles sont les différences.
8.2.1 L'init System V
Sous Linux (qui est un clone d'UNIX System V), comme vous le savez, /sbin/init est le premier processus lancé par le noyau à la fin de sa phase de boot. Il se met alors à lire le fichier /etc/inittab, et démarre des daemons, des process de login, s'occupe de mettre la machine en réseau et effectue quelques tâches secondaires.
Voici un exemple d'inittab, que nous allons commenter ensemble.
id:2:initdefault:
Cette ligne indique que le runlevel par défaut est le runlevel 2. Sous Debian (la distribution dont nous avons extrait l'inittab), c'est le niveau d'exécution qui correspond au multi-utilisateur avec réseau, mais sans X. Le runlevel considéré est toujours placé dans le deuxième champ.
si::sysinit:/etc/init.d/rcS
Cette ligne indique que le script rcS est lancé une fois au démarrage de la machine. On voit qu'il n'y a pas de numéro de runlevel, pour la bonne raison qu'il est inutile ici.
l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Normally not reached, but fallthrough # in case of emergency. z6:6:respawn:/sbin/sulogin
Ces lignes indiquent quelle action effectuer suivant le runlevel désiré. On voit que c'est le script /etc/init.d/rc qui est appelé avec l'argument n, égal au runlevel désiré. /etc/init.d/rc s'occupe de lancer tous les daemons comme décrit plus bas.
1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3
On voit ici qu'init s'occupe également de la mise en place des terminaux virtuels. Chaque script de gestion de daemon est placé dans /etc/rc.d/init.d. Pour savoir si le daemon doit être lancé au démarrage de la machine ou pas, des liens symboliques sont créés dans /etc/rcX.d/YnnDaemon.sh, où X est le runlevel, Y la lettre "S" ou "K", et nn la priorité.
Il y a plusieurs niveaux d'exécution (appelés "runlevels") dans un Unix SystemV, et le niveau par défaut est indiqué dans une des lignes du fichier inittab. X représente ce niveau. En général, 0 représente l'arrêt de la machine, 1 est le mode mono-utilisateur, 2 est le mode multi-utilisateur (sans réseau sous les RedHat-like, avec sous les Debian-like), 3 et 4 ne sont pas toujours utilisés, 5 est le mode multi-utilisateur graphique en réseau et 6 est le reboot. Ensuite, vient la lettre qui détermine si le service doit être lancé ("S", comme Start) ou arrêté ("K", comme Kill). Le numéro qui vient ensuite est un numéro codé sur deux chiffres, qui détermine l'ordre dans lequel les services seront lancés (S20exim4 sera par exemple lancé avant S59ssh).
On voit déjà là que c'est un sacré bordel à gérer. Des distributions proposent des scripts pour améliorer cela, comme RedHat avec "service", ou Debian avec update-rc.d(8). Malheureusement, ce ne sont pas des outils unifiés, que l'on peut retrouver sur n'importe quelle distribution. D'autre part, toutes les distributions n'utilisent pas le même système d'init, les scripts ne sont pas tous à la même place, etc. La seule chose que l'on est sûr de retrouver n'importe où est ln(1).
8.2.2 L'init BSD
Sous BSD, la phase de démarrage est beaucoup plus simple. Il y a deux sous-types de démarrage : la vénérable école, représentée par OpenBSD, et la nouvelle école, fondée par NetBSD, puis rejointe par FreeBSD et DragonFlyBSD.
Sous OpenBSD, init(8) se contente de lancer le script /etc/rc, qui s'occupe de tout initialiser. Il prend sa configuration dans le fichier /etc/rc.conf et exécute optionnellement /etc/rc.local (pour des ajouts locaux à la machine). Ce grand script monolithique est lancé en cas de boot multi-utilisateur. Ceci est magnifiquement expliqué dans les splendides pages de manuel OpenBSD, que vous retrouverez en ligne sur le site http://www.openbsd.org/cgi-bin/man.cgi?query=init&sektion=8.
NetBSD et ses disciples ont un peu pris le meilleur de chaque monde (la simplicité de l'init BSD et la souplesse de l'init SystemV), sans les défauts de chaque (la rigidité de l'init BSD, la porcherie de l'init SystemV). Sous NetBSD, /etc/rc n'est plus un script monolithique comme sous NetBSD, mais est un tout petit morceau de script qui va s'occuper de lancer les sous-scripts présents dans /etc/rc.d. Vous allez nous dire que cela ressemble nettement à un init SysV, mais point du tout ! Les choses reprochables à l'init SysV ont disparu ! Le bricolage avec les liens symboliques a disparu, car la configuration se fait bêtement dans un fichier texte /etc/rc.conf et indique si un service doit être lancé ou pas.
user@netbsd % grep ssh /etc/rc.conf sshd=YES user@netbsd % grep sendmail /etc/rc.conf sendmail=NO
D'autre part, la gestion de l'ordre de lancement des services est effectuée par un système s'appelant rcorder(8).
# PROVIDE: named # REQUIRE: SERVERS # BEFORE: DAEMON # KEYWORD: chrootdir
Cet exemple, extrait de /etc/rc.d/named, nous montre que le service named(8) dépend des "SERVERS", fournit le service named, doit être lancé avant les DAEMON et utilise chrootdir.
Pour voir dans quel ordre les daemons peuvent être lancés, vous pouvez utiliser la commande /sbin/rcorder -s nostart /etc/rc.d/*. Nous indiquons "peuvent être lancés", car ils se lanceront si et seulement si nous l'avons indiqué dans /etc/rc.conf. Précisons aussi que c'est toujours le fichier /etc/rc.conf qui doit être édité afin de déterminer si un service se lance ou pas, que le service soit un service présent dans le basesystem ou dans les ports. Il reste à noter que sous OpenBSD, il faut éditer le fichier /etc/rc.conf.local et non pas le fichier /etc/rc.conf, qui, lui, contient les réglages par défaut (et est susceptible d'être écrasé lors d'une mise à jour). Le fichier contenant les réglages par défaut des daemons est /etc/default/rc.conf sous NetBSD et FreeBSD.
8.3 Les outils qui changent (route/Netstat, iptables/PF)
Le changement le plus flagrant entre les systèmes Linux et BSD se situe au niveau de ce qu'on utilise le plus : les programmes d'administration. En effet, certaines commandes existent toujours, mais n'ont plus la même syntaxe ou le même usage. Assez perturbant par exemple, l'affichage de la table de routage du noyau : là où, sous GNU/Linux, on tape route -n, il faut taper netstat -rn -f inet pour l'équivalent sous BSD. Notons que, sous OpenBSD, vous pouvez utiliser route -n show pour afficher les tables de routage.
Le nombre de commandes qui changent n'est pas mirobolant, mais la force de l'habitude n'a pas que du bon. Avoir un guru des systèmes BSD à ses cotés est l'idéal pour cette période de transition, sinon Google est un bon pote. À noter, un outil qui prend du galon lorsqu'on passe de Linux à FreeBSD : ifconfig permet par exemple de voir l'état du médium (connecté ou pas), de configurer le mode de transmission, et aussi (et surtout, dirais-je), de configurer les interfaces wifi aussi bien que les interfaces filaires. ifconfig permet aussi de lister les interfaces clonables avec le switch -C, de voir les stations wifi attachées lorsque l'interface est en mode access point et de scanner le réseau wifi à la recherche de points d'accès en mode monitor.
Exemple avec une interface cuivre :
user@freebsd % /sbin/ifconfig -m bge0
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
capabilities=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
inet6 fe80::204:76ff:fef0:4e1e%bge0 prefixlen 64 scopeid 0x3
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
ether 00:04:76:33:e:1
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
supported media:
media autoselect
media 1000baseTX mediaopt full-duplex
media 1000baseTX
media 100baseTX mediaopt full-duplex
media 100baseTX
media 10baseT/UTP mediaopt full-duplex
media 10baseT/UTP
media none
Exemple avec une interface wifi :
user@openbsd % /sbin/ifconfig -m ral0
ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:13:d3:d6:e6:e6
media: IEEE802.11 OFDM54 mode 11g hostap (autoselect mode 11g hostap)
status: active
ieee80211: nwid OpenLAND chan 2 bssid 00:13:d3:6d:6e:e6 100dBm
supported media:
media autoselect
media autoselect mediaopt ibss
media autoselect mediaopt hostap
media autoselect mediaopt monitor
[...]
media OFDM54
media OFDM54 mediaopt ibss
media OFDM54 mediaopt hostap
media OFDM54 mediaopt monitor
inet 10.0.1.254 netmask 0xffffff00 broadcast 10.0.1.255
inet6 fe80::213:d3ff:fe6d:6ee6%ral0 prefixlen 64 scopeid 0x2
user@netbsd % /sbin/ifconfig -C
bridge vlan stf gif gre tun tap strip sl pppoe ppp lo
8.4 En parlant de réseau...
Le réseau sous les BSD se configure différemment : sous FreeBSD, il se configure dans /etc/rc.conf (avec des variables ifconfig_ifX, voire le man de rc.conf(5)) et sous NetBSD/OpenBSD, dans de simples fichiers plats /etc/ifconfig.ifX et /etc/hostname.ifX. De même, la route par défaut se place dans /etc/mygate et le nom d'hôte dans /etc/hostname. N'est-ce pas beau ?
9. Ce qui me plaît
9.1 La stabilité
Les services essentiels d'une entreprise (comme le DNS, les bases de données ou même des routeurs) ne peuvent pas être interrompus de façon intempestive. Pas question de les rebooter parce que Gérard a décidé d'installer le SNMP dessus. Même si avoir un gros uptime ne rend pas les cheveux brillants et n'attire pas les guris, il est essentiel que la disponibilité des services soit maximale (Cf. les articles de messieurs aflab & HR dans ce même magazine). La qualité du code et sa robustesse ont prouvé que FreeBSD est une excellente base pour l'architecture d'un système informatique (Netcraft ne vous dira pas le contraire).
9.2 PF
PackerFilter (PF pour les intimes) a failli faire son apparition dans les outils qui changent, mais il est tellement beau et puissant qu'il DOIT (comme un MUST de RFC) être cité dans ce qui nous fait aimer FreeBSD. Pour tout ce qui est histoire et utilisation de PF, se rapporter à l'article de Gaston. PF, c'est avant tout une syntaxe claire comme de l'eau, qui se rapproche vraiment du langage naturel :
rdr on $ext1 proto {tcp, udp} \
from any to $ip_pub port 22 -> $box port 22
Refaire de la syntaxe iptables après avoir joué avec du PF, c'est de la torture, OUI MONSIEUR ! De plus, PF offre une foultitude de fonctionnalités conviviales, comme le binat qui pourra vous aider si vous avez une architecture un peu tordue.
Références
rc.d-NGexpliqué par le barbu l'ayant conçu :http://www.mewburn.net/luke/papers/rc.d.pdf
- Le
rc(8) old-school :http://www.openbsd.org/faq/faq10.html#rc
rc.d-NGsous FreeBSD :http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-rcd.html
- Schéma du boot d'OpenBSD:
http://www.formation.ssi.gouv.fr/stages/documentation/architecture_securisee/images/bsd-boot.png
- Autres :
http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.html
http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.html
http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php
