Configuration Et Optimisation D'un Système FreeBSD

Configuration et optimisation d’un système FreeBSD
11.1. Synopsis
La configuration correcte d’un système peut sensiblement réduire la quantité de
travail impliquée dans la maintenance et la mise à jour. Ce chapitre décrit certains des
aspects de la configuration des systèmes FreeBSD.
Ce chapitre décrira également certains paramètres qui peuvent être modifiés pour
configurer un système FreeBSD pour des performances optimales.
Après la lecture de ce chapitre, vous saurez:
 Les bases de la configuration du fichier rc.conf et des fichiers de

démarrage /usr/local/etc/rc.d.
 Comment configurer et tester une carte réseau.
 Comment configurer des hôtes virtuels sur vos périphériques réseau.
 Comment utiliser les divers fichiers de configuration du répertoire /etc.
 Comment optimiser FreeBSD en utilisant les variables sysctl.
 Comment optimiser les performances des disques et modifier les limitations
du noyau.
Avant de lire ce chapitre, vous devrez:
 Comprendre les fondements d’UNIX® et de FreeBSD (Quelques bases d’UNIX).

 Etre familier avec la configuration et la compilation du noyau (Configurer le
noyau de FreeBSD).
11.2. Configuration principale

L’emplacement principal pour les données de configuration du système est le
fichier /etc/rc.conf. Ce fichier contient une large gamme d’informations de
configuration, principalement utilisées au démarrage du système pour configurer ce
dernier. Son nom le sous-entend; c’est l’information de configuration pour les
fichiers rc*.
Un administrateur devrait ajouter des entrées dans le fichier rc.conf pour remplacer
les valeurs par défaut du fichier /etc/defaults/rc.conf. Les fichiers de valeurs par
défaut ne devraient pas être copiés directement tels quels dans /etc - ils contiennent
des valeurs par défaut, et non pas des exemples. Tout changement spécifique au
système devrait être fait dans le fichier rc.conf.
Un certain nombre de stratégies peuvent être appliquées dans le cas d’applications
en grappe pour séparer la configuration d’un site de celle d’un système afin de
réduire le travail d’administration. L’approche recommandée est de placer la
configuration propre au site dans le fichier /etc/rc.conf.local. Par exemple:
 /etc/rc.conf:
 sshd_enable="YES"
 keyrate="fast"
defaultrouter="10.1.1.254"
 /etc/rc.conf.local:
 hostname="node1.example.org"
ifconfig_fxp0="inet 10.1.1.1/8"
Le fichier rc.conf peut être distribué à l’ensemble des systèmes en utilisant rsync ou
un programme semblable, tandis que le fichier rc.conf.local reste unique.
Mettre à jour le système en employant sysinstall(8) ou make world n’écrasera pas le

fichier rc.conf, les informations de configuration du système ne seront donc pas
perdues.
Le fichier de configuration /etc/rc.conf est analysé par sh(1). Cela permet aux
administrateurs système d’ajouter un certain niveau de logique à ce fichier, ce qui
peut aider à créer des scénaris de configuration complexes. Veuillez
consulter rc.conf(5) pour plus d’information sur ce sujet.
11.3. Configuration des applications

Généralement, les applications installées ont leurs propres fichiers de configuration,
avec leur propre syntaxe, etc… Il est important que ces fichiers soient séparés du
système de base, de sorte qu’ils soient facilement localisables et gérables par les
outils de gestion des logiciels installés.
Ces fichiers sont généralement installés dans le répertoire /usr/local/etc. Dans le cas
où une application possède un grand nombre de fichiers de configuration, un sous-
répertoire sera créé pour les héberger.
Normalement, quand un logiciel porté ou pré-compilé est installé, des exemples de

fichiers de configuration sont également installés. Ces derniers sont généralement
identifiés par un suffixe ".default". Si aucun fichier de configuration n’existe pour
l’application, on les créera en copiant les fichiers .default.
Par exemple, considérez le contenu du répertoire /usr/local/etc/apache:
-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf

-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default
-rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf
-rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default
-rw-r--r-- 1 root wheel 12205 May 20 1998 magic
-rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default
-rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types
-rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default
-rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf
-rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default
Les tailles des fichiers indiquent que seul le fichier srm.conf a été modifié. Une mise à
jour, plus tard, du logiciel Apache ne devrait pas écraser le fichier modifié.
11.4. Démarrer des services

Nombreux sont les utilisateurs qui choisissent d’installer des logiciels tierce partie
sous FreeBSD à partir du catalogue des logiciels portés. Dans de nombreuses
situations, il peut être nécessaire de configurer le logiciel de manière à ce qu’il soit
lancé au démarrage du système. Des services
comme mail/postfix ou www/apache22 sont deux exemples de logiciels parmi tant
d’autres qui peuvent être lancés à l’initialisation du système. Cette section explique
les procédures disponibles pour démarrer certains logiciels tierce partie.
Sous FreeBSD, la plupart des services offerts, comme cron(8), sont lancés par
l’intermédiaire des procédures de démarrage du système. Ces procédures peuvent
varier en fonction de la version de FreeBSD, ou du fournisseur; cependant, l’aspect le
plus important à considérer est que leur configuration de démarrage peut être gérée
à l’aide de procédures de démarrage simples.
11.4.1. Configuration étendue des applications
Maintenant que FreeBSD dispose du système rc.d, la configuration du démarrage des

applications est plus simple, et propose plus de possibilités. En utilisant les mots clés
présentés dans la section sur le système rc.d, les applications peuvent désormais être
paramétrées pour démarrer après certains services, par exemple le DNS, des
paramètres supplémentaires peuvent être passés par l’intermédiaire de rc.conf au
lieu d’utiliser des paramètres fixes dans les procédures de démarrage, etc. Une
procédure de base pourra ressembler à ce qui suit:
#!/bin/sh
#
# PROVIDE: utility
# REQUIRE: DAEMON
# KEYWORD: shutdown
. /etc/rc.subr
name=utility
rcvar=utility_enable
command="/usr/local/sbin/utility"
load_rc_config $name
#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
# SET THEM IN THE /etc/rc.conf FILE
#
utility_enable=${utility_enable-"NO"}
pidfile=${utility_pidfile-"/var/run/utility.pid"}
run_rc_command "$1"
Cette procédure s’assurera que l’application utility sera lancée après le le

service DAEMON. Elle fournie également une méthode de suivi du PID, ou encore ID
(identifiant) de processus.
Cette application pourra alors avoir la ligne suivante la concernant dans le

fichier /etc/rc.conf:
utility_enable="YES"
Cette méthode permet également une manipulation plus aisée des arguments en
ligne de commande, l’inclusion des fonctions offertes par défaut dans /etc/rc.subr,
offre une compatibilité avec l’utilitaire rcorder(8) et fournie une configuration plus
aisée par l’intermédiaire du fichier rc.conf.
11.4.2. Utiliser des services pour démarrer d’autres services
Certains services, comme les serveurs POP3, IMAP, etc., peuvent être démarrés en
utilisant inetd(8). Cela implique d’installer le service à partir du catalogue des logiciels
portés et avec une ligne de configuration ajoutée au fichier /etc/inetd.conf, ou en
décommentant une des lignes de configuration déjà présentes. L’utilisation d’inetd et
sa configuration sont décrits en profondeur dans la section concernant inetd.
Dans certains cas, il peut être plus approprié d’utiliser le "daemon" cron(8) pour
démarrer des services. Cette approche présente un certain nombre d’avantages parce
que cron exécute ces processus sous les privilèges du propriétaire de la
table crontab. Cela permet aux utilisateurs normaux de lancer et maintenir certaines
applications.
L’utilitaire cron offre une fonction unique, @reboot, qui peut être utilisée en
remplacement de la date d’exécution. Cela provoquera l’exécution de la tâche
quand cron(8) est lancé, normalement lors de l’initialisation du système.
11.5. Configuration de l’utilitaire cron

Un des utilitaires les plus importants de FreeBSD est cron(8). L’utilitaire cron tourne en
arrière plan et contrôle constamment le fichier /etc/crontab. L’utilitaire cron consulte
également le répertoire /var/cron/tabs, à la recherche de nouveaux fichiers crontab.
Ces fichiers crontab conservent les informations sur les tâches que cron est censé
exécuter à des moments donnés.
L’utilitaire cron utilise deux types différents de fichiers de configuration, le

fichier crontab système et les crontabs des utilisateurs. Ces deux formats diffèrent à
partir du sixième champ. Dans le fichier crontab système, cron exécutera la
commande en tant que l’utilisateur indiqué dans le sixième champ. Dans le
fichier crontab d’un utilisateur, toutes les commandes sont exécutées sous
l’utilisateur qui a créé ce fichier crontab, aussi le sixième champ est le dernier champ;
c’est un aspect sécurité important. Le dernier champ est toujours la commande à
exécuter.
Les fichiers crontab utilisateur permettent aux utilisateurs de planifier l’exécution de tâches
sans avoir besoin des privilèges du super-utilisateur root. Les commandes contenues dans le
fichier crontab d’un utilisateur s’exécutent avec les privilèges de l’utilisateur auquel appartient
ce fichier.
Le super-utilisateur root peut posséder un fichier crontab utilisateur comme tout autre
utilisateur. Ce fichier est différent de /etc/crontab (le crontab système). Etant donné que le
fichier crontab système invoque les commandes spécifiées en tant que root, il n’y a
généralement pas besoin d’un fichier crontab utilisateur pour root.
Examinons le fichier /etc/crontab (fichier crontab système):
# /etc/crontab - root's crontab for FreeBSD

#
# $FreeBSD: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $
#
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log
#
#
#minute heure date mois jour utilisateur commande
#
#
*/5 * * * * root /usr/libexec/atrun
Comme pour la plupart des fichiers de configuration de FreeBSD, le caractère # indique un

commentaire. Un commentaire peut être ajouté dans le fichier comme rappel de ce que fait
une action bien précise et pourquoi elle est effectuée. Les commentaires ne peuvent être
situés sur la même ligne qu’une commande ou sinon ils seront interprétés comme faisant
partie de la commande; ils doivent se trouver sur une nouvelle ligne. Les lignes vides sont
ignorées.
Tout d’abord, les variables d’environnement doivent être définies. Le caractère égal ( =) est
utilisé pour définir tout paramètre concernant l’environnement, comme dans notre exemple
où il a été utilisé pour les variables SHELL, PATH, et HOME. Si la ligne concernant l’interpréteur
de commande est omise, cron utilisera celui par défaut, qui est sh. Si la variable PATH est
omise, il n’y aura pas de valeur par défaut utilisée et l’emplacement des fichiers devra être
absolu. Si HOME est omise, cron utilisera le répertoire personnel de l’utilisateur qui l’invoque.
Cette ligne définie un total de sept champs. Sont listés ici les
valeurs minute, heure, date, mois, jour, utilisateur, et commande. Ces champs sont
relativement explicites. minute représente l’heure en minute à laquelle la commande sera
exécutée. L’option heure est semblable à l’option minute, mais en heures. Le
champ date précise le jour dans le mois. mois est similaire à heure et minute mais désigne le
mois. L’option jour représente le jour de la semaine. Tous ces champs doivent être des
valeurs numériques, et respecter un format horaire de vingt quatre heures. Le
champ utilisateur est spécial, et n’existe que dans le fichier /etc/crontab. Ce champ
précise sous quel utilisateur sera exécutée la commande. Le dernier champ désigne la
commande à exécuter.
Cette dernière ligne définie les valeurs discutées ci-dessus. Nous avons ici */5 suivi de
plusieurs caractères \*. Ces caractères * signifient "premier-dernier", et peuvent être
interprétés comme voulant dire à chaque instance. Aussi, d’après cette ligne, il apparaît que
la commande atrun sera invoquée par l’utilisateur root toutes les cinq minutes
indépendamment du jour ou du mois. Pour plus d’informations sur la commande atrun,
consultez la page de manuel de atrun(8). N’importe quel nombre d’indicateur peut être passé
à ces commandes; cependant, les commandes qui s’étendent sur de multiples lignes doivent
être "cassées" avec le caractère, contre-oblique \, de continuation de lignes.
Ceci est la configuration de base pour chaque fichier crontab, bien qu’il y ait une
différence dans celui présenté ici. Le sixième champ, où est précisé le nom
d’utilisateur, n’existe que dans le fichier système /etc/crontab. Ce champ devrait être
omis pour les fichiers crontab d’utilisateur.
11.5.1. Installer un fichier crontab

Ne pas utiliser la procédure décrite ci-dessous pour éditer et installer le
fichier crontab système. Utilisez directement votre éditeur: l’utilitaire cron remarquera le
changement au niveau de ce fichier et utilisera immédiatement la nouvelle version.
Consultez cette entrée de la FAQ pour plus d’information.
Pour installer un fichier crontab utilisateur fraîchement rédigé, tout d’abord utilisez
votre éditeur favori pour créer un fichier dans le bon format, ensuite utilisez
l’utilitaire crontab. L’usage le plus typique est:
# crontab fichier-crontab
Dans cet exemple, fichier-crontab est le nom d’un fichier crontab qui a été
précédemment créé.
Il existe également une option pour afficher les fichiers crontab installés, passez
simplement le paramètre -l à crontab et lisez ce qui est affiché.
Pour les utilisateurs désirant créer leur fichier crontab à partir de zéro, sans utiliser de
modèle, l’option crontab -e est disponible. Cela invoquera l’éditeur par défaut avec
un fichier vide. Quand le fichier est sauvegardé, il sera automatiquement installé par
la commande crontab.
Afin d’effacer le fichier crontab utilisateur complètement, utiliser la

commande crontab avec l’option -r.
11.6. Utilisation du système rc(8) sous FreeBSD

En 2002, le système rc.d de NetBSD pour l’initialisation du système a été intégré à
FreeBSD. Les utilisateurs noteront les fichiers présents dans le répertoire /etc/rc.d.
Plusieurs de ces fichiers sont destinés aux services de base qui peuvent être contrôlés
avec les options start, stop, et restart. Par exemple, sshd(8) peut être relancé avec la
commande suivante:
# /etc/rc.d/sshd restart
Cette procédure est similaire pour d’autres services. Bien sûr, les services sont
généralement lancés automatiquement au démarrage dès qu’ils sont spécifiés dans le
fichier rc.conf(5). Par exemple, activer le "daemon" de translation d’adresses au
démarrage est aussi simple que d’ajouter la ligne suivante au fichier /etc/rc.conf:
natd_enable="YES"
Si une ligne natd_enable="NO" est déjà présente, modifiez alors le NO par YES. Les
procédures rc chargeront automatiquement les autres services dépendants lors du
prochain redémarrage comme décrit ci-dessous.
Comme le système rc.d est à l’origine destiné pour lancer/arrêter les services au
démarrage/à l’arrêt du système, les options standards start, stop et restart ne seront
effectives que si les variables appropriées sont positionnées dans le
fichier /etc/rc.conf. Par exemple, la commande sshd restart ci-dessus ne
fonctionnera que si sshd_enable est fixée à YES dans /etc/rc.conf. Pour lancer, arrêter
ou redémarrer un service indépendemment des paramétrages du fichier /etc/rc.conf,
les commandes doivent être précédées par "one". Par exemple pour
redémarrer sshd indépendemment du paramétrage du fichier /etc/rc.conf, exécutez
la commande suivante:
# /etc/rc.d/sshd onerestart
Il est facile de contrôler si un service est activé dans le fichier /etc/rc.conf en

exécutant la procédure rc.d appropriée avec l’option rcvar. Ainsi, un administrateur
peut contrôler que sshd est réellement activé dans /etc/rc.conf en exécutant:
# /etc/rc.d/sshd rcvar
# sshd
$sshd_enable=YES
La seconde ligne (# sshd) est la sortie de la commande sshd et non pas une console root.
Pour déterminer si un service est actif, une option appelée status est disponible. Par
exemple pour vérifier que sshd a réellement été lancé:
# /etc/rc.d/sshd status
sshd is running as pid 433.
Dans certains cas, il est également possible de recharger un service avec

l’option reload. Le système tentera d’envoyer un signal à un service individuel, le
forçant à recharger ses fichiers de configuration. Dans la plupart des cas cela signifie
envoyer un signal SIGHUP au service. Le support de cette fonctionnalité n’est pas
disponible pour chaque service.
Le système rc.d n’est pas uniquement utilisée pour les services réseaux, elle participe
à la majeure partie de l’initialisation du système. Prenez par exemple le fichier bgfsck.
Quand cette procédure est exécutée, il affichera le message suivant:
Starting background file system checks in 60 seconds.
Donc ce fichier est utilisé pour les vérifications du système de fichiers en arrière plan,
qui sont uniquement effectuées lors de l’initialisation du système.
De nombreux services système dépendent d’autres services pour fonctionner

correctement. Par exemple, NIS et les autres services basés sur les RPCs peuvent
échouer s’ils sont lancés après le lancement du service rpcbind (portmapper). Pour
résoudre ce problème, l’information concernant les dépendances et autres méta-
données est inclue dans les commentaires au début de chaque procédure de
démarrage. Le programme rcorder(8) est alors utilisé pour analyser ces commentaires
lors de l’initialisation du système en vue de déterminer l’ordre dans lequel les services
système seront invoqués pour satisfaire les dépendances.
Les mots suivants doivent être présents en tête de tous les fichiers de démarrage (ils
sont nécessaires pour que rc.subr(8) active les procédures de démarrages):
 PROVIDE: indique les services que fournit ce fichier.
Les mots clés suivants peuvent être ajoutés au début de chaque fichier de démarrage.
Ils ne sont pas strictement nécessaires, mais sont utiles comme aide pour rcorder(8):
 REQUIRE:liste les fichiers dont dépend ce service. Ce fichier sera

exécuté après les services indiqués.
 BEFORE:liste les services qui dépendent du service présent. Ce fichier sera
exécuté avant les services indiqués.
En utilisant avec soin ces mots clés pour chaque fichier de démarrage, un
administrateur dispose d’un niveau de contrôle très fin de l’ordre d’exécution des
procédures de démarrage sans les inconvénients des "runlevels" comme sur d’autres
systèmes d’exploitation UNIX®.
Des informations supplémentaires concernant le système rc.d peuvent être trouvées

dans les pages de manuel rc(8) et rc.subr(8). Si vous êtes intéressé par l’écriture de
vos propres procédures rc.d ou pour l’amélioration des procédures existantes, vous
trouverez cette article utile.
11.7. Configuration des cartes réseaux

De nos jours il est impossible de penser à un ordinateur sans penser connexion à un
réseau. Installer et configurer une carte réseau est une tâche classique pour tout
administrateur FreeBSD.
11.7.1. Déterminer le bon pilote de périphérique
Avant de commencer, vous devez connaître le modèle de la carte dont vous disposez,
le circuit qu’elle utilise, et si c’est une carte PCI ou ISA. FreeBSD supporte une large
variété de cartes PCI et ISA. Consultez la liste de compatibilité matérielle pour votre
version de FreeBSD afin de voir si votre carte est supportée.
Une fois que vous êtes sûrs que votre carte est supportée, vous devez déterminer le
bon pilote de périphérique pour la carte. Les
fichiers /usr/src/sys/conf/NOTES et /usr/src/sys/arch/conf/NOTES vous
donneront la liste des pilotes de périphériques pour cartes réseaux avec des
informations sur les cartes/circuits supportés. Si vous avez des doutes au sujet du bon
pilote, lisez la page de manuel du pilote. La page de manuel vous donnera plus
d’information sur le matériel supporté et même les éventuels problèmes qui pourront
apparaître.
Si vous possédez une carte courante, la plupart du temps vous n’aurez pas à chercher
trop loin pour trouver un pilote. Les pilotes pour les cartes réseaux courantes sont
présents dans le noyau GENERIC, aussi votre carte devrait apparaître au démarrage,
comme suit:
dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38

000ff irq 15 at device 11.0 on pci0
miibus0: <MII bus> on dc0
bmtphy0: <BCM5201 10/100baseTX PHY> PHY 1 on miibus0
bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: Ethernet address: 00:a0:cc:da:da:da
dc0: [ITHREAD]
dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30
000ff irq 11 at device 12.0 on pci0
miibus1: <MII bus> on dc1
bmtphy1: <BCM5201 10/100baseTX PHY> PHY 1 on miibus1
bmtphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc1: Ethernet address: 00:a0:cc:da:da:db
dc1: [ITHREAD]
Dans cet exemple, nous voyons que deux cartes utilisant le pilote de
périphérique dc(4) sont présentes sur le système.
Si le pilote de votre carte n’est pas présent dans le noyau GENERIC, vous devrez
charger le module approprié pour pouvoir utiliser votre carte. Cela peut être effectué
de deux manières différentes:
 La méthode la plus simple est de charger le module pour votre carte réseau
avec kldload(8), ou automatiquement au démarrage du système en ajoutant la
ligne appropriée au fichier /boot/loader.conf. Tous les pilotes de cartes
réseau ne sont pas disponibles sous forme de modules; les cartes ISA sont un
bon exemple de périphériques pour lesquels les modules n’existent pas.
 Alternativement, vous pouvez compiler en statique le support pour votre carte
dans votre noyau.
Consultez /usr/src/sys/conf/NOTES, /usr/src/sys/arch/conf/NOTES et la
page de manuel du pilote de périphérique pour savoir ce qu’il faut ajouter au
fichier de configuration de votre noyau. Pour plus d’information sur la
recompilation de votre noyau, veuillez lire le Configurer le noyau de FreeBSD.
Si votre carte a été détectée au démarrage par votre noyau (GENERIC) vous
n’avez pas à compiler un nouveau noyau.
11.7.1.1. Utilisation des pilotes NDIS de Windows®
Malheureusement il y a toujours de nombreux fabricants qui ne fournissent pas à la

communauté des logiciels libres les informations concernant les pilotes pour leurs
cartes considérant de telles informations comme des secrets industriels. Par
conséquent, il ne reste aux développeurs de FreeBSD et d’autres systèmes
d’exploitation libres que deux choix: développer les pilotes en passant par un long et
pénible processus de "reverse engineering" ou utiliser les pilotes binaires existants
disponibles pour la plateforme Microsoft® Windows®. La plupart des développeurs,
y compris ceux impliqués dans FreeBSD, ont choisi cette dernière approche.
Grâce aux contributions de Bill Paul (wpaul), il existe un support "natif" pour la
spécification d’interface des pilotes de périphérique réseau (Network Driver Interface
Specification-NDIS). Le NDISulator FreeBSD (connu également sous le nom de Project
Evil) prend un pilote binaire réseau Windows® et lui fait penser qu’il est en train de
tourner sous Windows®. Etant donné que le pilote ndis(4) utilise un binaire
Windows®, il ne fonctionne que sur les systèmes i386™ et amd64. Les périphériques
PCI, CardBus, PCMCIA (PC-Card), et USB sont supportés.
Pour utiliser le NDISulator, trois choses sont nécessaires:
1. les sources du noyau;

2. le pilote binaire Windows® XP (extension .SYS);
3. le fichier de configuration du pilote Windows® XP (extension .INF).
Recherchez les fichiers spécifiques à votre carte. Généralement, ils peuvent être
trouvés sur les CDs livrés avec la carte ou sur le site du fabricant. Dans les exemples
qui suivent nous utiliseront les fichiers W32DRIVER.SYS et W32DRIVER.INF.
Le type de pilote doit correspondre à la version de FreeBSD. Pour FreeBSD/i386,

utiliser un pilote Windows® 32bits. Pour FreeBSD/amd64, un pilote Windows®
64bits est nécessaire.
L’étape suivante est de compiler le pilote binaire dans un module chargeable du

noyau. En tant que root, utilisez ndisgen(8):
# ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS
L’utilitaire ndisgen(8) est interactif, il sollicitera l’utilisateur pour d’éventuelles

informations complémentaires si nécessaire. Un nouveau module noyau est créé dans
le répertoire courant. Utiliser kldload(8) pour charger le nouveau module:
# kldload ./W32DRIVER_SYS.ko
Avec le module généré, vous devez également charger les

modules ndis.ko et if_ndis.ko. Cela devrait être fait automatiquement quand vous
chargez un module qui dépend de ndis(4). Si vous désirez les charger manuellement,
utilisez les commandes suivantes:
# kldload ndis
# kldload if_ndis
La première commande charge le pilote d’interface NDIS, la seconde charge

l’interface réseau.
Contrôlez maintenant la sortie de dmesg(8) à la recherche d’une quelconque erreur

au chargement. Si tout s’est bien passé, vous devriez obtenir une sortie ressemblant à
ce qui suit:
ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on

pci1
ndis0: NDIS API version: 5.0
ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5
ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps
A partir de là vous pouvez traiter le périphérique ndis0 comme n’importe quelle

interface réseau (par exemple dc0).
Vous pouvez configurer le système pour charger les modules NDIS au démarrage du
système de la même manière que pour n’importe quel autre module. Tout d’abord,
copiez le module généré, W32DRIVER_SYS.ko, dans le répertoire /boot/modules.
Ajoutez ensuite la ligne suivante au fichier /boot/loader.conf:
W32DRIVER_SYS_load="YES"
11.7.2. Configuration de la carte réseau
Une fois que le bon pilote de périphérique pour la carte réseau est chargé, la carte
doit être configurée. Comme beaucoup d’autres choses, la carte aura pu être
configurée à l’installation par sysinstall.
Pour afficher la configuration des interfaces réseaux de votre système, entrer la

commande suivante:
% ifconfig
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80008<VLAN_MTU,LINKSTATE>
ether 00:a0:cc:da:da:da
inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
dc1: flags=8802<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:a0:cc:da:da:db
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet 10baseT/UTP
status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
Dans cet exemple, les périphériques suivants ont été affichés:
 dc0: La première interface Ethernet

 dc1: La seconde interface Ethernet
 lo0: L’interface "en boucle" ("loopback")
FreeBSD utilise le nom du pilote de périphérique suivi par un chiffre représentant

l’ordre dans lequel la carte est détectée au démarrage du noyau pour nommer la
carte. Par exemple sis2 serait la troisième carte sur le système utilisant le pilote de
périphérique sis(4).
Dans cet exemple, le périphérique dc0 est actif et en fonctionnement. Les indicateurs
importants sont:
1. UP signifie que la carte est configurée et prête.

2. La carte possède une adresse Internet (inet) (dans ce cas-ci 192.168.1.3).
3. Elle a un masque de sous-réseau valide (netmask; 0xffffff00 est équivalent
à 255.255.255.0).
4. Elle a une adresse de diffusion valide (dans ce cas-ci 192.168.1.255).
5. L’adresse MAC de la carte (ether) est 00:a0:cc:da:da:da
6. La sélection du média est sur le mode d’autosélection ( media: Ethernet
autoselect (100baseTX full-duplex) ). Nous voyons que dc1 a été configurée
pour utiliser un matériel de type 10baseT/UTP. Pour plus d’information sur le
type de matériel disponible pour un pilote de périphérique, référez-vous à sa
page de manuel.
7. La liaison (status) est active, i.e. la porteuse est détectée. Pour dc1, nous
lisons status: no carrier. Cela est normal lorsqu’aucun câble n’est branché à
la carte.
Si le résultat de la commande ifconfig(8) est similaire à:
dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500

ether 00:a0:cc:da:da:da
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
cela indiquerait que la carte n’a pas été configurée.
Pour configurer votre carte, vous avez besoin des privilèges de l’utilisateur root. La
configuration de la carte réseau peut être faite à partir de la ligne de commande
avec ifconfig(8) mais vous aurez à répéter cette opération à chaque redémarrage du
système. Le fichier /etc/rc.conf est l’endroit où ajouter la configuration de la carte
réseau.
Ouvrez le fichier /etc/rc.conf dans votre éditeur favori. Vous devez ajouter une ligne
pour chaque carte réseau présente sur le système, par exemple dans notre cas, nous
avons ajouté ces lignes:
ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0"

ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP"
Vous devez remplacer dc0, dc1, et ainsi de suite, avec le périphérique correspondant
pour vos cartes, et les adresses avec celles désirées. Vous devriez lire les pages de
manuel du pilote de périphérique et d’ifconfig(8) pour plus de détails sur les options
autorisées et également la page de manuel de rc.conf(5) pour plus d’information sur
la syntaxe de /etc/rc.conf.
Si vous avez configuré le réseau à l’installation, des lignes concernant la/les carte(s)
réseau pourront être déjà présentes. Contrôler à deux fois le
fichier /etc/rc.conf avant d’y ajouter des lignes.
Vous devrez également éditer le fichier /etc/hosts pour ajouter les noms et les
adresses IP des diverses machines du réseau local, si elles ne sont pas déjà présentes.
Pour plus d’information référez-vous à la page de manuel hosts(5) et au
fichier /usr/shared/examples/etc/hosts.
S’il n’y a pas de serveur DHCP et qu’un accès à Internet est nécessaire, configurez
manuellement la passerelle par défaut et le serveur de noms:
# echo 'defaultrouter="your_default_router"' >> /etc/rc.conf

# echo 'nameserver your_DNS_server' >> /etc/resolv.conf
11.7.3. Test et dépannage
Une fois les modifications nécessaires du fichier /etc/rc.conf effectuées, vous devrez
redémarrer votre système. Cela permettra la prise en compte de la ou les
modifications au niveau des interfaces, et permettra de vérifier que le système
redémarre sans erreur de configuration. Sinon, une autre méthode pour faire prendre
en compte les modifications au niveau de la gestion du réseau consiste à utiliser la
commande:
# service netif restart
Si une passerelle par défaut a été configurée dans /etc/rc.conf, lancez également cette
commande:
# service routing restart
Une fois que le système a été redémarré, vous testez les interfaces réseau.
11.7.3.1. Tester la carte Ethernet
Pour vérifier qu’une carte Ethernet est configurée correctement, vous devez essayer
deux choses. Premièrement, "pinguer" l’interface, puis une autre machine sur le
réseau local.
Tout d’abord testons l’interface:
% ping -c5 192.168.1.3

PING 192.168.1.3 (192.168.1.3): 56 data bytes
64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms
--- 192.168.1.3 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms
Nous devons maintenant "pinguer" une autre machine sur le réseau:
% ping -c5 192.168.1.2

PING 192.168.1.2 (192.168.1.2): 56 data bytes
--- 192.168.1.2 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms
Vous pourrez utiliser le noms de la machine à la place de 192.168.1.2 si vous avez

configuré le fichier /etc/hosts.
11.7.3.2. Dépannage
Le dépannage de matériels ou de logiciels est toujours une tâche relativement

pénible, mais qui peut être rendue plus aisée en vérifiant en premier lieu certaines
choses élémentaires. Votre câble réseau est-il branché? Avez-vous correctement
configuré les services réseau? Le coupe-feu est-il bien configuré? Est-ce que la carte
réseau est supportée par FreeBSD? Consultez toujours les notes concernant le
matériel avant d’envoyer un rapport de bogue. Mettez à jour votre version de
FreeBSD vers la dernière version STABLE. Consultez les archives des listes de diffusion,
et faites même des recherches sur l’Internet.
Si la carte fonctionne mais les performances sont mauvaises, une lecture de la page
de manuel tuning(7) peut valoir la peine. Vous pouvez également vérifier la
configuration du réseau puisque des paramètres réseau incorrects peuvent donner
lieu à des connexions lentes.
Certains utilisateurs peuvent voir apparaître un ou deux messages device timeout, ce

qui est normal pour certaines cartes. Si ces messages se multiplient, assurez-vous que
la carte n’est pas en conflit avec un autre périphérique. Contrôlez à deux fois les
câbles de connexion. Peut-être que vous avez juste besoin d’une autre carte.
Parfois, des utilisateurs sont confrontés à des messages d’erreur watchdog timeout. La
première chose à faire dans ce cas est de vérifier votre câble réseau. De nombreuses
cartes demandent un slot PCI supportant le "Bus Mastering". Sur certaines cartes
mère anciennes, seul un slot PCI le permet (la plupart du temps le slot 0). Consultez la
documentation de la carte réseau et de la carte mère pour déterminer si cela peut
être à l’origine du problème.
Les messages No route to host surviennent si le système est incapable de router un

paquet vers la machine de destination. Cela peut arriver s’il n’y a pas de route par
défaut de définie, ou si le câble réseau est débranché. Vérifiez la sortie de la
commande netstat -nr et assurez-vous qu’il y a une route valide en direction de la
machine que vous essayez d’atteindre. Si ce n’est pas le cas, lisez la Administration
réseau avancée.
Les messages d’erreur ping: sendto: Permission denied sont souvent dus à un coupe-
feu mal configuré. Si ipfw est activé dans le noyau mais qu’aucune règle n’a été
définie, alors la politique par défaut est de refuser tout trafic, même les requêtes
"ping"! Lisez Firewalls pour plus d’informations.
Parfois les performances de la carte ne sont pas bonnes, ou en dessous de la

moyenne. Dans ce cas il est recommandé de passer la sélection du média du
mode autoselect au mode adéquat. Alors que cela fonctionne généralement pour la
plupart du matériel, il se peut que cela ne résolve pas le problème pour tout de
monde. Encore une fois, contrôlez les paramétrages réseau et consultez la page de
manuel tuning(7).
11.8. Hôtes virtuels

Une utilisation très courante de FreeBSD est l’hébergement de sites virtuels, où un
serveur apparaît pour le réseau comme étant plusieurs serveurs différents. Ceci est
possible en assignant plusieurs adresses réseau à une interface.
Une interface réseau donnée possède une adresse "réelle", et peut avoir n’importe
quel nombre d’adresses "alias". Ces alias sont normalement ajoutés en plaçant les
entrées correspondantes dans le fichier /etc/rc.conf.
Une entrée d’alias pour l’interface fxp0 ressemble à:
ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"
Notez que les entrées d’alias doivent commencer avec alias0 et continuer en ordre
croissant, (par exemple, _alias1, _alias2, et ainsi de suite). Le processus de
configuration s’arrêtera au premier nombre absent.
Le calcul des masques de réseau est important, mais heureusement assez simple.
Pour une interface donnée, il doit y avoir une adresse qui représente correctement le
masque de réseau de votre réseau. Tout autre adresse appartenant à ce réseau devra
avoir un masque de réseau avec chaque bit à 1 (exprimé soit sous la
forme 255.255.255.255 soit 0xffffffff).
Par exemple, considérez le cas où l’interface fxp0 est connectée à deux réseaux, le
réseau 10.1.1.0 avec un masque de réseau de 255.255.255.0 et le
réseau 202.0.75.16 avec un masque de 255.255.255.240. Nous voulons que le système
apparaisse de 10.1.1.1 jusqu’à 10.1.1.5 et à 202.0.75.17 jusqu’à 202.0.75.20. Comme
noté plus haut, seule la première adresse dans un intervalle réseau donné (dans ce
cas, 10.0.1.1 et 202.0.75.17) devrait avoir un masque de sous-réseau réel; toutes les
autres adresses (10.1.1.2 à 10.1.1.5 et 202.0.75.18 jusqu’à 202.0.75.20) doivent être
configurées avec un masque de sous-réseau de 255.255.255.255.
Les entrées suivantes du fichier /etc/rc.conf configurent la carte correctement pour

cet arrangement:
ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"

ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
11.9. Fichiers de configuration

11.9.1. Organisation du répertoire /etc
Il existe un certain nombre de répertoires dans lesquels se trouvent les informations

de configuration. Ceux-ci incluent:
/etc Information de configuration générique du système; les données ici sont

spécifiques au système.
/etc/defaults Version par défaut des fichiers de configuration du système.
/etc/mail Configuration de sendmail(8), et autres fichiers de configuration d’agent de

transmission du courrier électronique.
/etc/ppp Configuration pour les programmes PPP utilisateur et intégré au noyau.
/etc/namedb Emplacement par défaut pour les données de named(8).

Normalement named.conf et les fichiers de zone sont stockés dans ce
répertoire.
/usr/local/etc Fichiers de configuration pour les applications installées. Peut contenir des
sous-répertoires pour chaque application.
/usr/local/etc/rc.d Procédures de lancement/d’arrêt pour les applications installées.
/var/db Fichiers de bases de données automatiquement générés, spécifiques au

système, comme la base de données des logiciels installés, la base de données
de localisation des fichiers, et ainsi de suite.
11.9.2. Nom d’hôtes

11.9.2.1. /etc/resolv.conf
/etc/resolv.conf gère comment le résolveur de FreeBSD accède au système de nom

de domaine d’Internet (DNS).
Les entrées la plus classiques du fichier resolv.conf sont:
nameserve L’adresse IP du serveur de noms auquel le résolveur devrait envoyer ses requêtes.
r Les serveurs sont sollicités dans l’ordre listé avec un maximum de trois.
search Liste de recherche pour la résolution de nom de machine. Ceci est normalement
déterminé par le domaine de l’hôte local.
domain Le nom du domaine local.
Un fichier resolv.conf typique:
search example.com
nameserver 147.11.1.11
nameserver 147.11.100.30
Seule une des options search et domain devrait être utilisée.
Si vous utilisez DHCP, dhclient(8) réécrit habituellement resolv.conf avec

l’information reçue du serveur DHCP.
11.9.2.2. /etc/hosts
/etc/hosts est une simple base de données texte, une réminiscence des débuts
d’Internet. Il travaille en conjonction avec les serveurs DNS et NIS pour fournir les
correspondances nom vers adresse IP. Les ordinateurs locaux reliés par l’intermédiaire
d’un réseau local peuvent être ajoutés dans ce fichier pour une résolution de noms
simple plutôt que de configurer un serveur named(8). De plus /etc/hosts peut être
utilisé pour fournir un enregistrement local de correspondances de nom, réduisant
ainsi le besoin de requêtes vers l’extérieur pour les noms auxquels on accède
couramment.
# $FreeBSD$
#
#
# Host Database
#
# This file should contain the addresses and aliases for local hosts that
# share this file. Replace 'my.domain' below with the domainname of your
# machine.
#
# In the presence of the domain name service or NIS, this file may
# not be consulted at all; see /etc/nsswitch.conf for the resolution order.
#
#
::1 localhost localhost.my.domain
127.0.0.1 localhost localhost.my.domain
#
# Imaginary network.
#10.0.0.2 myname.my.domain myname
#10.0.0.3 myfriend.my.domain myfriend
#
# According to RFC 1918, you can use the following IP networks for
# private nets which will never be connected to the Internet:
#
# 10.0.0.0 - 10.255.255.255
# 172.16.0.0 - 172.31.255.255
# 192.168.0.0 - 192.168.255.255
#
# In case you want to be able to connect to the Internet, you need
# real official assigned numbers. Do not try to invent your own network
# numbers but instead get one from your network provider (if any) or
# from your regional registry (ARIN, APNIC, LACNIC, RIPE NCC, or AfriNIC.)
#
/etc/hosts suit le format simple suivant:
[Internet address] [official hostname] [alias1] [alias2] ...
Par exemple:
10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2
Consultez la page de manuel hosts(5) pour plus d’informations.
11.9.3. Configuration des fichiers de trace

11.9.3.1. syslog.conf
syslog.conf est le fichier de configuration du programme syslogd(8). Il indique quel

type de messages syslog sera enregistré dans des fichiers de traces particuliers.
# $FreeBSD$
#
# Spaces ARE valid field separators in this file. However,
# other *nix-like systems still insist on using tabs as field
# separators. If you are sharing this file between systems, you
# may want to use only tabs as field separators here.
# Consult the syslog.conf(5) manual page.
*.err;kern.debug;auth.notice;mail.crit /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.* /var/log/security
mail.info /var/log/maillog
lpr.info /var/log/lpd-errs
cron.* /var/log/cron
*.err root
*.notice;news.err root
*.alert root
*.emerg *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
#*.* /var/log/all.log
# uncomment this to enable logging to a remote log host named loghost
#*.* @loghost
# uncomment these if you're running inn
# news.crit /var/log/news/news.crit
# news.err /var/log/news/news.err
# news.notice /var/log/news/news.notice
!startslip
*.* /var/log/slip.log
!ppp
*.* /var/log/ppp.log
Consultez la page de manuel syslog.conf(5) pour plus d’informations.
11.9.3.2. newsyslog.conf
newsyslog.conf est le fichier de configuration de newsyslog(8), un programme qui

est normalement programmé cron(8) pour s’exécuter
périodiquement. newsyslog(8) détermine quand les fichiers de traces doivent être
archivés ou réorganisés. logfile devient logfile.0, logfile.0 devient à son
tour logfile.1, et ainsi de suite. D’autre part, les fichiers de traces peuvent être
archivés dans le format gzip(1), ils se nommeront alors: logfile.0.gz, logfile.1.gz, et
ainsi de suite.
newsyslog.conf indique quels fichiers de traces doivent être gérés, combien doivent
être conservés, et quand ils doivent être modifiés. Les fichiers de traces peuvent être
réorganisés et/ou archivés quand ils ont soit atteint une certaine taille, soit à une
certaine période/date.
# configuration file for newsyslog

# $FreeBSD$
#
# filename [owner:group] mode count size when [ZB] [/pid_file]
[sig_num]
/var/log/cron 600 3 100 * Z
/var/log/amd.log 644 7 100 * Z
/var/log/kerberos.log 644 7 100 * Z
/var/log/lpd-errs 644 7 100 * Z
/var/log/maillog 644 7 * @T00 Z
/var/log/sendmail.st 644 10 * 168 B
/var/log/messages 644 5 100 * Z
/var/log/all.log 600 7 * @T00 Z
/var/log/slip.log 600 3 100 * Z
/var/log/ppp.log 600 3 100 * Z
/var/log/security 600 10 100 * Z
/var/log/wtmp 644 3 * @01T05 B
/var/log/daily.log 640 7 * @T00 Z
/var/log/weekly.log 640 5 1 $W6D0 Z
/var/log/monthly.log 640 12 * $M1D0 Z
/var/log/console.log 640 5 100 * Z
Consultez la page de manuel newsyslog(8) pour plus d’informations.
11.9.4. sysctl.conf
sysctl.conf ressemble à rc.conf. Les valeurs sont fixées sous la forme variable=value.
Les valeurs spécifiées sont positionnées après que le système soit passé dans le mode
multi-utilisateurs. Toutes les variables ne sont pas paramétrables dans ce mode.
Pour désactiver l’enregistrement des signaux fatals de fin de processus et empêcher

les utilisateurs de voir les processus lancés par les autres, les variables suivantes
peuvent être paramétrées dans sysctl.conf:
# Do not log fatal signal exits (e.g., sig 11)

kern.logsigexit=0
# Prevent users from seeing information about processes that

# are being run under another UID.
security.bsd.see_other_uids=0
11.10. Optimisation avec sysctl(8)

sysctl(8) est une interface qui vous permet d’effectuer des changements de
paramétrage sur un système FreeBSD en fonctionnement. Cela comprend de
nombreuses options avancées de la pile TCP/IP et du système de mémoire virtuelle
qui peuvent améliorer dramatiquement les performances pour un administrateur
système expérimenté. Plus de cinq cent variables système peuvent être lues et
modifiées grâce à sysctl(8).
sysctl(8) remplit deux fonctions: lire et modifier les paramétrages du système.
Pour afficher toutes les variables lisibles:
% sysctl -a
Pour lire une variable particulière, par exemple, kern.maxproc:
% sysctl kern.maxproc
kern.maxproc: 1044
Pour fixer une variable particulière, utilisez la syntaxe intuitive variable=valeur :

# sysctl kern.maxfiles=5000
kern.maxfiles: 2088 -> 5000
Les valeurs des variables sysctl sont généralement des chaînes de caractères, des
nombres, ou des booléens (un variable booléenne étant 1 pour oui ou un 0 pour
non).
Si vous voulez fixer automatiquement certaines variables à chaque démarrage de la

machine, ajoutez-les au fichier /etc/sysctl.conf. Pour plus d’information consultez la
page de manuel sysctl.conf(5) et la sysctl.conf.
11.10.1. Variables sysctl(8) en lecture seule
Dans certains cas, il peut être nécessaire de modifier des variables sysctl(8) en lecture
seule. Bien que cela soit parfois inévitable, cela ne peut être fait qu’au (re)démarrage
de la machine.
Par exemple sur certains modèles d’ordinateurs portables le

périphérique cardbus(4) ne sondera pas le système à la recherche des zones
mémoires, et échouera avec des erreurs du type:
cbb0: Could not map register memory

device_probe_and_attach: cbb0 attach returned 12
Des cas comme le précédent demandent généralement la modification de

paramètres sysctl(8) par défaut qui sont en lecture seule. Pour palier à ces situations
un utilisateur peut placer un paramétrage ("OID"-Object IDentifier) sysctl(8) dans le
fichier local /boot/loader.conf.local. Les paramétrages par défaut se trouvent dans
le fichier /boot/defaults/loader.conf.
Pour corriger le problème précédent, il faudrait que l’utilisateur ajoute la

ligne hw.pci.allow_unsupported_io_range=1 dans le fichier précédemment indiqué.
Désormais le périphérique cardbus(4) devrait fonctionner normalement.
11.11. Optimiser les disques

11.11.1. Les variables sysctl
11.11.1.1. vfs.vmiodirenable
La variable sysctl vfs.vmiodirenable peut être positionnée soit à 0 (désactivée) soit à 1

(activée); elle est a 1 par défaut. Cette variable spécifie comment les répertoires sont
cachés par le système. La plupart des répertoires sont petits, utilisant juste un simple
fragment du système de fichiers (typiquement 1KO) et moins dans le cache en
mémoire (typiquement 512 octets). Avec cette variable désactivée (à 0), le cache en
mémoire ne cachera qu’un nombre fixe de répertoires même si vous disposez d’une
grande quantité de mémoire. Activée (à 1), cette variable sysctl permet au cache en
mémoire d’utiliser le cache des pages de mémoire virtuelle pour cacher les
répertoires, rendant toute la mémoire disponible pour cacher les répertoires.
Cependant, la taille minimale de l’élément mémoire utilisé pour cacher un répertoire
est une page physique (typiquement 4KO) plutôt que 512 octets. Nous
recommandons de conserver de cette option activée si vous faites fonctionner des
services qui manipulent un grand nombre de fichiers. De tels services peuvent être
des caches web, d’importants systèmes de courrier électronique, et des systèmes
serveurs de groupe de discussion. Conserver cette option activée ne réduira
généralement pas les performances même avec la mémoire gaspillée mais vous
devriez faire des expériences pour le déterminer.
11.11.1.2. vfs.write_behind
La variable sysctl vfs.write_behind est positionnée par défaut à 1 (activée). Elle

demande au système de fichiers d’effectuer les écritures lorsque des grappes
complètes de données ont été collectées, ce qui se produit généralement lors de
l’écriture séquentielle de gros fichiers. L’idée est d’éviter de saturer le cache tampon
avec des tampons sales quand cela n’améliorera pas les performances d’E/S.
Cependant, cela peut bloquer les processus et dans certaines conditions vous pouvez
vouloir désactiver cette fonction.
11.11.1.3. vfs.hirunningspace
La variable sysctl vfs.hirunningspace détermine combien d’opérations d’écriture

peuvent être mises en attente à tout moment au niveau des contrôleurs disques du
système. La valeur par défaut est normalement suffisante mais sur les machines avec
de nombreux disques, vous pouvez vouloir l’augmenter jusqu’à quatre ou cinq méga-
octets. Notez que fixer une valeur trop élevée (dépassant la limite d’écriture du cache
tampon) peut donner lieu à de très mauvaises performances. Ne fixez pas cette valeur
à une valeur élevée arbitraire! Des valeurs d’écriture élevées peuvent ajouter des
temps de latence aux opérations d’écriture survenant au même moment.
Il existent d’autres variables sysctl relatives aux caches tampons et aux pages VM.
Nous ne recommandons pas de modifier ces valeurs, le système VM effectue un très
bon travail d’auto-optimisation.
11.11.1.4. vm.swap_idle_enabled
La variable vm.swap_idle_enabled est utile dans le cas de systèmes multi-utilisateurs

importants où il y a beaucoup d’utilisateurs s’attachant et quittant le système et de
nombreux processus inactifs. De tels systèmes tendent à générer une pression assez
importante et continue sur les réserves de mémoire libres. Activer cette fonction et
régler l’hystéresis de libération de l’espace de pagination (en secondes d’inactivité)
par l’intermédiaire des variables vm.swap_idle_threshold1 et vm.swap_idle_threshold2,
vous permet de diminuer la priorité des pages mémoire associées avec les processus
inactifs plus rapidement qu’avec l’algorithme normal de libération. Cela aide le
"daemon" de libération des pages. N’activez cette option que si vous en besoin,
parce que la concession que vous faites est d’utiliser l’espace de pagination pour les
pages mémoire plus tôt qu’à l’accoutumé, consommant par conséquent plus
d’espace de pagination et de bande passante disque. Sur un petit système, cette
option aura un effet limité mais dans le cas d’un système important qui fait appel à
l’espace de pagination de façon modérée, cette option permettra au système VM de
transférer l’ensemble des processus de et vers la mémoire aisément.
11.11.1.5. hw.ata.wc
FreeBSD 4.3 a flirté avec la désactivation du cache en écriture des disques IDE. Cela
réduisit la bande passante en écriture des disques IDE mais fut considéré comme
nécessaire en raison de sérieux problèmes de cohérence de données introduits par
les fabricants de disques durs. Le problème est que les disques IDE mentent sur le
moment où une écriture est réellement terminée. Avec le cache en écriture IDE activé,
les disques durs IDE non seulement n’écriront pas les données dans l’ordre, mais
parfois retarderont l’écriture de certains blocs indéfiniment sous une charge disque
importante. Un crash ou une coupure secteur pourra être à l’origine de sérieuses
corruptions du système de fichiers. Par précaution le paramétrage par défaut de
FreeBSD fut modifié. Malheureusement, le résultat fut une telle perte de
performances que nous avons réactivé le cache en écriture après cette version de
FreeBSD. Vous devriez contrôler la valeur par défaut sur votre système en examinant
la variable sysctl hw.ata.wc. Si le cache en écriture des disques IDE est désactivé, vous
pouvez le réactiver en positionnant la variable à 1. Cela doit être fait à partir du
chargeur au démarrage. Tenter de le faire après le démarrage du noyau n’aura aucun
effet.
Pour plus d’informations, veuillez consulter la page de manuel ata(4).
11.11.1.6. SCSI_DELAY (kern.cam.scsi_delay)
L’option de configuration du noyau SCSI_DELAY peut être utilisée pour réduire le

temps de démarrage du système. Le délai par défaut est important et peut être
responsable de plus de 15 secondes d’attente lors du processus de démarrage.
Réduire ce délai à 5 secondes est généralement suffisant (tout particulièrement avec
les disques modernes). L’option de démarrage kern.cam.scsi_delay devrait être
utilisée. Cette option de démarrage et celle de configuration du noyau acceptent des
valeurs en millisecondes et non pas en secondes.
11.11.2. Les "Soft Updates"

Le programme tunefs(8) peut être utilisé pour régler finement un système de fichiers.
Ce programme dispose de nombreuses options différentes, mais pour l’instant nous
nous intéresserons uniquement à l’activation et la désactivation des "Soft Updates",
ce qui fait avec:
# tunefs -n enable /filesystem

# tunefs -n disable /filesystem
Un système de fichiers ne peut être modifié avec tunefs(8) tant qu’il est monté. Un
bon moment pour activer les "Soft Updates" est avant que les partitions ne soient
montées en mode mono-utilisateur.
Les "Soft Updates" améliorent de façon drastique les performances sur les méta-
données, principalement la création et la suppression de fichier, par l’utilisation d’un
cache mémoire. Nous recommandons d’activer les "Soft Updates" sur tous vos
systèmes de fichiers. Il y a deux inconvénients aux "Soft Updates" que vous devez
connaître: tout d’abord, les "Soft Updates" garantissent la cohérence du système de
fichiers en cas de crash mais pourront facilement être en retard de quelques
secondes (voir même une minute!) dans la mise à jour du disque. Si votre système
plante il se peut que vous perdiez plus de travail que dans d’autres cas.
Deuxièmement, les "Soft Updates" retardent la libération des blocs du système de
fichiers. Si vous avez un système de fichiers (comme le système de fichiers racine) qui
est presque plein, effectuer une mise à jour majeure, comme un make installworld,
peut mener à un manque d’espace sur le système de fichiers et faire échouer la mise
à jour.
11.11.2.1. Plus de détails à propos des "Soft Updates"
Il y a deux approches traditionnelles pour écrire les méta-données d’un système de

fichiers sur le disque (mise à jour des méta-données et mise à jour des éléments sans
données comme les inodes ou les répertoires).
Historiquement, le comportement par défaut était d’écrire les mises à jour des méta-
données de façon synchrone. Si un répertoire a été modifié, le système attendait
jusqu’à ce que le changement soit effectivement écrit sur le disque. Les tampons des
données de fichier (contenu du fichier) passaient par le cache mémoire et étaient
copiés sur le disque plus tard de façon asynchrone. L’avantage de cette
implémentation est qu’elle est effectuée sans risque. S’il y a un problème durant une
mise à jour, les méta-données sont toujours dans un état consistant. Un fichier est
soit créé complètement soit pas du tout. Si les blocs de données d’un fichier n’ont
pas trouvé leur chemin du cache mémoire vers le disque au moment du
crash, fsck(8) est capable de s’en apercevoir et de réparer le système de fichiers en
fixant la taille du fichier à 0. De plus, l’implémentation est claire et simple.
L’inconvénient est que la modification des méta-données est lente. Un rm -r, par
exemple, touche à tous les fichiers dans un répertoire séquentiellement, mais chaque
modification du répertoire (effacement d’un fichier) sera écrite de façon synchrone
sur le disque. Cela comprend les mises à jour du répertoire lui-même, de la table des
inodes, et éventuellement celles sur des blocs indirects alloués par le fichier. Des
considérations semblables s’appliquent à la création d’importantes hiérarchies (( tar -
x).
Le deuxième cas est la mise à jour asynchrone des méta-données. C’est le

comportement par défaut de Linux/ext2fs et de l’usage de mount -o async pour l’UFS
des systèmes BSD. Toutes les mises à jour des méta-données passent également par
l’intermédiaire d’un cache mémoire, c’est à dire, qu’elles seront mélangées aux mises
à jour des données du contenu du fichier. L’avantage de cette implémentation est
qu’il n’y a pas besoin d’attendre jusqu’à l’écriture sur le disque de chaque mise à jour
de méta-données, donc toutes les opérations qui sont à l’origine d’une grande
quantité de mise à jour de méta-données fonctionnent bien plus rapidement que
dans le cas synchrone. De plus, l’implémentation est toujours claire et simple, il y a
donc peu de risque qu’un bogue se cache dans le code. L’inconvénient est qu’il n’y a
aucune garantie du tout sur la cohérence du système de fichiers. S’il y a un problème
durant une opération qui met à jour une grande quantité de méta-données (comme
une coupure secteur, ou quelqu’un appuyant sur le bouton reset), le système de
fichiers sera laissé dans un état imprévisible. Il n’y a aucune opportunité d’examiner
l’état du système de fichiers quand le système est à nouveau relancé; les blocs de
données d’un fichier pourraient déjà avoir été inscrits sur le disque alors que la mise à
jour de la table des inodes ou du répertoire associé n’a pas été faite. Il est en fait
impossible d’implémenter un fsck qui est capable de nettoyer le chaos résultant
(parce que l’information nécessaire n’est pas disponible sur le disque). Si le système
de fichiers a été endommagé irrémédiablement, le seul choix est de le recréer
avec newfs(8) et de récupérer les données à partir de sauvegardes.
La solution commune pour ce problème fut d’implémenter une région de trace, dont
on fait souvent référence sous le terme de journalisation, bien que ce terme ne soit
pas toujours utilisé de façon cohérente et est occasionnellement utilisé pour d’autres
formes de transaction avec trace. Les mises à jour des méta-données sont toujours
écrites de façon synchrone, mais seulement sur une petite région du disque. Elles
seront plus tard déplacées vers leur emplacement correct. Parce que la région de
trace est une petite région contiguë sur le disque, il n’y a pas de grandes distances de
déplacement pour les têtes des disques, même durant les opérations importantes,
donc ces opérations sont plus rapides que les mises à jour synchrones. De plus la
complexité de l’implémentation est relativement limitée, donc le risque de présence
de bogues est faible. Un inconvénient est que toutes les méta-données sont écrites
deux fois (une fois dans la région de trace et une fois sur l’emplacement correct) donc
pour un fonctionnement normal, une baisse des performances pourra en résulter.
D’autre part, dans le cas d’un crash, toutes les opérations sur les méta-données en
attente peuvent rapidement être annulées ou complétées à partir de la zone de trace
après le redémarrage du système, ayant pour résultat un démarrage rapide du
système de fichiers.
Kirk McKusick, le développeur du FFS de Berkeley, a résolu le problème avec les "Soft
Updates": toutes les mises à jour des méta-données sont conservées en mémoire et
inscrites sur le disque selon une séquence ordonnée ("mise à jour ordonnée des
méta-données"). Ceci a pour effet, dans le cas d’un nombre d’opérations sur les
méta-données important, que les dernières mises à jour sur un élément "attrapent"
les premières si ces dernières sont encore en mémoire et n’ont pas encore été
inscrites sur le disque. Donc toutes les opérations sur, par exemple, un répertoire sont
généralement effectuées en mémoire avant que la mise à jour ne soit écrite sur le
disque (les blocs de données sont ordonnés en fonction de leur position de sorte à ce
qu’ils ne soient pas sur le disque avant leur méta-données). Si le système crash, cela
provoque un "retour dans les traces" implicite: toutes les opérations qui n’ont pas
trouvé leur chemin vers le disque apparaissent comme si elles n’avaient jamais existé.
Un état cohérent du système de fichiers est maintenu et apparaît comme étant celui
de 30 ou 60 secondes plus tôt. L’algorithme utilisé garantie que toutes les ressources
utilisées soient marquées avec leur bons "bitmaps": blocs et inodes. Après un crash,
les seules erreurs d’allocation de ressources qui apparaissent sont les ressources qui
ont été marquées comme "utilisées" et qui sont en fait "libre". fsck(8) reconnaît cette
situation, et libère les ressources qui ne sont plus utilisées. On peut ignorer sans
risque l’état "sale" d’un système de fichiers après un crash en forçant son montage
avec mount -f. Afin de libérer les ressources qui peuvent être inutilisées, fsck(8) doit
être exécuté plus tard. C’est l’idée qu’il y a derrière le "background fsck" (fsck en tâche
de fond): au démarrage du système, seule un "snapshot" (photographie) du système
de fichiers est prise. La commande fsck peut être exécutée plus tard sur ce système
de fichiers. Tous les systèmes de fichiers peuvent être montés "sales", donc le
système passe en mode multi-utilisateurs. Ensuite, les fsck en tâche de fond seront
programmés pour tous les systèmes de fichiers pour lesquels c’est nécessaire, pour
libérer les ressources qui peuvent être inutilisées (les systèmes qui n’utilisent pas les
"Soft Updates" ont toujours besoin du fsck en avant plan).
L’avantage est que les opérations sur les méta-données sont presque aussi rapides
que les mises à jour asynchrones (i.e. plus rapide qu’avec le "logging" - traçage, qui
doit écrire les méta-données deux fois). Les inconvénients sont la complexité du code
(impliquant un haut risque de bogues dans une zone qui est hautement sensible en
raison de risque perte de données utilisateur), et une plus grande consommation en
mémoire. De plus il y a quelques particularités que l’on peut rencontrer lors de
l’utilisation. Après un crash, l’état du système apparaît être en quelque sorte "plus
vieux". Dans des situations où l’approche synchrone classique aurait donné lieu à des
fichiers de taille nulle restant après le fsck, ces fichiers n’existent pas du tout avec un
système de fichiers utilisant les "Soft Updates" parce que ni les méta-données ni les
contenus de fichiers n’ont jamais été inscrits sur le disque. L’espace disque n’est pas
rendu tant que les mises à jour n’ont pas été inscrites sur le disque, ce qui peut se
produire quelques temps après l’exécution de rm. Cela peut être à l’origine de
problèmes quand on installe une grande quantité de données sur un système de
fichiers qui ne dispose pas de suffisamment d’espace pour contenir tous les fichiers
deux fois.
11.12. Optimisation des limitations du noyau

11.12.1. Limitations sur les fichiers et les processus
11.12.1.1. kern.maxfiles
Le paramètre kern.maxfiles peut être augmenté ou diminué en fonction des besoins

du système. Cette variable indique le nombre maximal de descripteurs de fichier sur
votre système. Quand la table de descripteurs de fichier est pleine, le message file:
table is full s’affichera régulièrement dans le tampon des messages système, qui
peut être visualisé avec la commande dmesg.
Chaque fichier ouvert, chaque "socket", ou chaque emplacement en pile utilise un

descripteur de fichier. Un serveur important peut facilement demander plusieurs
milliers de descripteurs de fichiers, en fonction du type et du nombre de services
s’exécutant en même temps.
Sous les anciennes versions de FreeBSD, la valeur par défaut de kern.maxfile est fixée
par l’option maxusers dans votre fichier de configuration du
noyau. kern.maxfiles augmente proportionnellement avec la valeur de maxusers.
Quand vous compilez un noyau sur mesure, il est bon de paramétrer cette option en
fonction de l’utilisation de votre système. Ce nombre fixe la plupart des limites pré-
définies du noyau. Même si une machine de production pourra ne pas avoir en réalité
256 utilisateurs connectés simultanément, les ressources requises pourront être
semblables pour un serveur web important.
La variable kern.maxusers est automatiquement ajustée au démarrage en fonction de

la quantité de mémoire disponible dans le système, sa valeur peut être connue
durant le fonctionnement du système en examinant la valeur de la variable sysctl en
lecture seule: kern.maxusers. Certains systèmes auront besoin de valeurs plus élevées
ou plus faibles pour kern.maxusers et pourront donc la fixer au chargement du
système; des valeurs de 64, 128, ou 256 ne sont pas inhabituelles. Nous
recommandons de ne pas dépasser 256 à moins que vous ayez besoin d’un grand
nombre de descripteurs de fichiers; plusieurs des variables dont la valeur par défaut
dépend de kern.maxusers peuvent être fixées individuellement au démarrage ou en
fonctionnement dans le fichier /boot/loader.conf (voir la page de
manuel loader.conf(5) ou le fichier /boot/defaults/loader.conf pour des exemples)
ou comme décrit en d’autres endroits dans ce document.
Sous les anciennes versions, le système auto-ajuste ce paramètre pour vous si vous le
fixez explicitement à 0. En paramétrant cette option, vous devrez fixer maxusers à 4 au
moins, en particulier si vous utilisez le système X Window ou compilez des logiciels.
La raison de cela est que la valeur la plus importante que dimensionne maxusers est le
nombre maximal de processus, qui est fixé à 20 + 16 * maxusers, donc si vous
positionnez maxusers à 1, alors vous ne pouvez avoir que 36 processus en simultanés,
comprenant les 18, environ, que le système lance au démarrage et les 15, à peu près,
que vous créerez probablement au démarrage du système X Window. Même une
tâche simple comme la lecture d’une page de manuel lancera jusqu’à neuf processus
pour la filtrer, la décompresser, et l’afficher. Fixer maxusers à 64 autorisera jusqu’à
1044 processus simultanés, ce qui devrait suffire dans la plupart des cas. Si, toutefois,
vous obtenez le message d’erreur tant redouté quand vous tentez d’exécuter un
nouveau programme, ou gérez un serveur avec un grand nombre d’utilisateurs en
simultanés (comme ftp.FreeBSD.org), vous pouvez toujours augmenter cette valeur et
recompiler le noyau.
maxusers ne limite pas le nombre d’utilisateurs qui pourront ouvrir une session sur votre
machine. Cette valeur dimensionne simplement différentes tables à des valeurs raisonnables en
fonction du nombre maximal d’utilisateur que vous aurez vraisemblablement sur votre système
et combien de processus chacun d’entre eux pourra utiliser.
11.12.1.2. kern.ipc.somaxconn
La variable sysctl kern.ipc.somaxconn limite la taille de la file d’attente acceptant les

nouvelles connexions TCP. La valeur par défaut de 128 est généralement trop faible
pour une gestion robuste des nouvelles connexions dans un environnement de
serveur web très chargé. Pour de tels environnements, il est recommandé
d’augmenter cette valeur à 1024 ou plus. Le "daemon" en service peut de lui-même
limiter la taille de la file d’attente (e.g. sendmail(8), ou Apache) mais disposera, la
plupart du temps, d’une directive dans son fichier de configuration pour ajuster la
taille de la file d’attente. Les files d’attentes de grandes tailles sont plus adaptées
pour éviter les attaques par déni de service ().
11.12.2. Limitations réseau
L’literal du noyau NMBCLUSTERS fixe la quantité de "Mbuf";s disponibles pour le

système. Un serveur à fort trafic avec un nombre faible de "Mbuf";s sous-emploiera
les capacités de FreeBSD. Chaque "cluster" représente approximativement 2 Ko de
mémoire, donc une valeur de 1024 représente 2 mégaoctets de mémoire noyau
réservée pour les tampons réseau. Un simple calcul peut être fait pour déterminer
combien sont nécessaires. Si vous avez un serveur web qui culmine à 1000
connexions simultanées, et que chaque connexion consomme un tampon de
réception de 16Ko et un tampon d’émission de 16 Ko, vous avez approximativement
besoin de 32 Mo de tampon réseau pour couvrir les besoin du serveur web. Un bon
principe est de multiplier ce nombre par 2, soit 2x32 Mo / 2 Ko = 64 Mo / 2 Ko
=32768. Nous recommandons des valeurs comprises entre 4096 et 32768 pour les
machines avec des quantités de mémoire plus élevées. Vous ne devriez, dans aucun
circonstance, spécifier de valeur élevée arbitraire pour ce paramètre étant donné que
cela peut être à l’origine d’un plantage au démarrage. L’option -m de netstat(1) peut
être utilisée pour observer l’utilisation des "clusters".
La variable kern.ipc.nmbclusters configurable au niveau du chargeur est utilisée pour

ajuster cela au démarrage. Seules les anciennes versions de FreeBSD vous
demanderont d’utiliser l’option de configuration du noyau NMBCLUSTERS.
Pour les serveurs chargés qui font une utilisation intensive de l’appel
système sendfile(2), il peut être nécessaire d’augmenter le nombre de
tampons sendfile(2) par l’intermédiaire de l’option de configuration du
noyau NSFBUFS ou en fixant sa valeur dans le fichier /boot/loader.conf (consultez la
page de manuel loader(8) pour plus de détails). Un indicateur de la nécessité d’ajuster
ce paramètre est lorsque des processus sont dans l’état sfbufa. La variable
sysctl kern.ipc.nsfbufs est un aperçu en lecture seule de la variable du noyau. Ce
paramètre s’ajuste de façon optimale avec kern.maxusers, il peut être cependant
nécessaire de l’ajuster en fonction des besoins.
Même si une "socket" a été marquée comme étant non-bloquante, un appel de sendfile(2) sur la
"socket" non-bloquante peut résulter en un blocage de l’appel sendfile(2) jusqu’à ce que
suffisamment de struct sf_buf soient libérées.
11.12.2.1. net.inet.ip.portrange.*
Les variables net.inet.ip.portrange.* contrôlent les intervalles de ports

automatiquement alloués aux "socket"s TCP et UDP. Il y a trois intervalles: un
intervalle bas, un intervalle par défaut, et intervalle un haut. La plupart des
programmes réseau utilisent l’intervalle par défaut qui est contrôlé
par net.inet.ip.portrange.first et net.inet.ip.portrange.last, qui ont pour valeur
par défaut respectivement 1024 et 5000. Ces intervalles de ports sont utilisés pour les
connexions sortantes, et il est possible de se trouver à court de ports dans certaines
conditions. Cela arrive le plus souvent quand votre système fait tourner un proxy web
très chargé. L’intervalle de ports n’est pas un problème quand vous exécutez des
serveurs qui ne gèrent principalement que des connexions entrantes, comme un
server web classique, ou qui ont un nombre de connexions sortantes limitées comme
un relai de messagerie. Pour les cas où vous risquez d’être à court de ports, il est
recommandé d’augmenter légèrement net.inet.ip.portrange.last. Une valeur
de 10000, 20000 ou 30000 doit être suffisante. Vous devriez également penser au
problème du coupe-feu lors du changement de l’intervalle des ports. Certains
coupes-feu peuvent bloquer de grands intervalles de ports (en général les ports
inférieurs) et s’attendent à ce que les systèmes utilisent les intervalles supérieurs pour
les connexions sortantes - pour cette raison il n’est pas conseillé de
diminuer net.inet.ip.portrange.first.
11.12.2.2. Le produit délai-bande passante TCP

La limitation du produit délai-bande passante TCP est semblable au TCP/Vegas sous
NetBSD. Elle peut être activée en positionnant à 1 la
variable net.inet.tcp.inflight.enable. Le système tentera alors de calculer le produit
délai-bande passante pour chaque connexion et limitera la quantité de données en
attente à la quantité juste nécessaire au maintient d’un flux de sortie optimal.
Cette fonctionnalité est utile si vous diffusez des données par l’intermédiaire de
modems, de connexions Ethernet Gigabit, ou même de liaisons hauts débits WAN (ou
toute autre liaison avec un produit délai-bande passante élevé), tout particulièrement
si vous utilisez également le dimensionnement des fenêtres d’émission ou que vous
avez configuré une fenêtre d’émission importante. Si vous activez cette option, vous
devriez également vous assurer que net.inet.tcp.inflight.debug est positionnée
à 0 (désactive le débogage), et pour une utilisation en production,
fixer net.inet.tcp.inflight.min à au moins 6144 peut être bénéfique. Notez,
cependant, que fixer des minima élevés peut désactiver la limitation de bande
passante selon la liaison. La fonction de limitation diminue la quantité de données
accumulées dans les files d’attente intermédiaire de routage et de commutation, et
diminue également la quantité de données présentes dans les files d’attente de
l’interface de la machine locale. Avec moins de paquets dans les files d’attente, les
connexions interactives, tout particulièrement sur des modems lents, seront en
mesure de fonctionner avec des temps d’aller-retour plus faible. Mais cette
fonctionnalité n’affecte que la transmission de données (transmission côté serveur).
Ceci n’a aucun effet sur la réception de données (téléchargement).
Modifier net.inet.tcp.inflight.stab n’est pas recommandé. Ce paramètre est fixé par

défaut à la valeur 20, représentant au maximum 2 paquets ajoutés à la fenêtre de
calcul du produit délai-bande passante. La fenêtre supplémentaire est nécessaire
pour stabiliser l’algorithme et améliorer la réponse aux changements de conditions,
mais il peut en résulter des temps de "ping" plus élevés sur les liaisons lentes (mais
cependant inférieurs à ce que vous obtiendriez sans l’algorithme de limitation). Dans
de tels cas, vous pouvez essayer de réduire ce paramètre à 15, 10, ou 5, et vous
pouvez avoir à réduire le paramètre net.inet.tcp.inflight.min (par exemple à 3500)
pour obtenir l’effet désiré. Ces paramètres ne doivent être réduits qu’en dernier
ressort.
11.12.3. Mémoire virtuelle

11.12.3.1. kern.maxvnodes
Un vnode est la représentation interne d’un fichier ou d’un répertoire. Augmenter le

nombre de vnodes disponibles pour le système d’exploitation diminue les accès
disque. Cela est normalement géré par le système d’exploitation et n’a pas besoin
d’être modifié. Dans certains cas où les accès aux disques sont un goulot
d’étranglement pour le système et que ce dernier est à cours de vnodes, ce nombre
aura besoin d’être augmenté. La quantité de RAM libre et inactive sera prise en
compte.
Pour connaître le nombre de vnodes actuellement utilisés:
# sysctl vfs.numvnodes
vfs.numvnodes: 91349
Pour connaître le maximum de vnodes utilisables:
# sysctl kern.maxvnodes
kern.maxvnodes: 100000
Si l’utilisation actuelle des vnodes est proche du maximum, augmenter de

1000 kern.maxvnodes est probablement une bonne idée. Gardez un oeil sur le
nombre vfs.numvnodes. S’il approche à nouveau le maximum, kern.maxvnodes devra
être augmenté de manière plus conséquente. Une modification dans votre utilisation
de la mémoire devrait être visible dans top(1). Une plus grande quantité de mémoire
devrait être annoncée comme active.
11.13. Ajouter de l’espace de pagination

Peu importe comment vous l’avez pensé, parfois un système ne fonctionne pas
comme prévu. Si vous trouvez que vous avez besoin de plus d’espace de pagination,
il est assez simple d’en rajouter. Vous avez trois manières d’augmenter votre espace
de pagination: ajouter un nouveau disque dur, activer la pagination sur NFS, et créer
un fichier de pagination sur une partition existante.
Pour des informations sur comment chiffrer l’espace de pagination, quelles options
existent pour mener à bien cette tâche et pourquoi on devrait le faire, veuillez vous
référer à la Chiffrage de l’espace de pagination du Manuel.
11.13.1. Espace de pagination sur un nouveau disque dur ou une

partition existante
Ajouter un nouveau disque pour l’espace de pagination donne de meilleures

performances qu’utiliser une partition sur un disque existant. La configuration des
partitions et des disques durs est expliquée dans la Ajouter des disques tandis que
la Choix du partitionnement aborde l’organisation des partitions et les problèmes
relatifs à la taille de la partition de l’espace de pagination.
Utiliser la commande swapon pour ajouter une partition de pagination au système. Par
exemple:
# swapon /dev/ada1s1b
Il est possible d’utiliser n’importe quelle partition actuellement non-montée, même si cette
dernière contient des données. Utiliser swapon sur une partition contenant des données écrasera
et effacera ces données. Assurez-vous que la partition à utiliser comme espace de pagination
est bien celle prévue à cet effet avant d’exécuter swapon.
Pour ajouter cette partition de pagination automatiquement au démarrage, ajouter

une entrée au fichier /etc/fstab:
/dev/ada1s1b none swap sw 0 0
Consulter fstab(5) pour plus d’explications sur les entrées du fichier /etc/fstab. Plus
d’informations sur swapon sont disponibles dans swapon(8).
11.13.2. Espace de pagination sur NFS
L’espace de pagination sur NFS n’est recommandé que si vous n’avez pas de disque
dur local sur lequel avoir l’espace de pagination; la pagination sur NFS sera limitée
par la bande passante du réseau et sera un fardeau supplémentaire pour le serveur
NFS.
11.13.3. Fichiers de pagination
Vous pouvez créer un fichier d’une taille spécifique pour l’utiliser comme fichier de
pagination. Dans notre exemple nous utiliserons un fichier de 64MO
appelé /usr/swap0. Vous pouvez, bien sûr, utiliser le nom de votre choix.
Exemple 1. Créer un fichier de pagination sous FreeBSD
1. Le noyau GENERIC inclut déjà le pilote de disque mémoire (md(4)) nécessaire

à cette opération. Lors de la compilation d’un noyau sur mesures, assurez-vous
d’inclure la ligne suivante dans le fichier de configuration:
device md
Pour plus d’information sur la compilation du noyau, veuillez vous réferer à

la Configurer le noyau de FreeBSD.
2. Créez un fichier de pagination (/usr/swap0):
# dd if=/dev/zero of=/usr/swap0 bs=1024k count=64
3. Fixez les bonnes permissions sur /usr/swap0:
# chmod 0600 /usr/swap0
4. Activez le fichier de pagination dans /etc/rc.conf:

swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired.
5. Redémarrez la machine ou activez directement le fichier de pagination:
# mdconfig -a -t vnode -f /usr/swap0 -u 0 swapon /dev/md0
11.14. Gestion de l’énergie et des ressources

Il est important d’utiliser les ressources matérielles d’une manière efficace. Avant
l’apparition de l’ACPI, il était difficile pour les systèmes d’exploitation de gérer
l’utilisation de l’alimentation et la température d’un système. Le matériel était géré
par le BIOS et donc l’utilisateur avait moins de contrôle et de visibilité sur le
paramétrage de la gestion de l’énergie. Une configuration limitée était accessible via
l'Advanced Power Management (APM). La gestion de l’énergie et des ressources est
un des éléments clés d’un système d’exploitation moderne. Par exemple, vous
pourrez vouloir qu’un système d’exploitation surveille certaines limites (et
éventuellement vous alerte), au cas où la température de votre système augmente de
façon inattendue.
Dans cette section, nous fournirons une information complète au sujet de l’ACPI. Il
sera fait référence à des documents supplémentaires en fin de section pour plus de
détails.
11.14.1. Qu’est-ce que l’ACPI?
L'"interface de configuration et d’alimentation avancée" (ACPI, Advanced

Configuration and Power Interface) est une norme créée par un ensemble de
constructeurs pour fournir une interface standard à la gestion des ressources et de
l’énergie. C’est un élément clé dans le contrôle et la configuration par le système
d’exploitation de de la gestion d’énergie, i.e., il permet plus de contrôle et flexibilité
au système d’exploitation. Les systèmes modernes ont "repoussé" les limites des
interfaces "Plug and Play" antérieures à l’apparition de l’ACPI. L’ACPI est le
descendant direct de l’APM (Advanced Power Management - gestion avancée de
l’énergie).
11.14.2. Les imperfections de la gestion avancée de l’énergie (APM)
Le système de gestion avancée de l’énergie (APM) gère l’utilisation de l’énergie par un

système en fonction de son activité. Le BIOS APM est fourni par le fabricant (du
système) et est spécifique à la plateforme matérielle. Un pilote APM au niveau du
système d’exploitation gère l’accès à l'interface logicielle APM qui autorise la gestion
des niveaux de consommation. L’APM devrait être toujours utilisé pour les systèmes
fabriqués en ou avant 2000.
L’APM présente quatre problèmes majeurs. Tout d’abord la gestion de l’énergie est
effectuée par le BIOS (spécifique au constructeur), et le système d’exploitation n’en a
aucune connaissance. Un exemple de ce problème, est lorsque l’utilisateur fixe des
valeurs pour le temps d’inactivité d’un disque dur dans le BIOS APM, qui une fois
dépassé, provoque l’arrêt du disque (par le BIOS) sans le consentement du système
d’exploitation. Deuxièmement, la logique de l’APM est interne au BIOS, et agit
indépendamment du système d’exploitation. Cela signifie que les utilisateurs ne
peuvent corriger les problèmes de leur BIOS APM qu’en flashant un nouveau BIOS;
c’est une opération dangereuse, qui si elle échoue peut laisser le système dans un
état irrécupérable. Troisièmement, l’APM est une technologie spécifique au
constructeur, ce qui veut dire qu’il y a beaucoup de redondances (duplication des
efforts) et de bogues qui peuvent être trouvées dans le BIOS d’un constructeur, et qui
peuvent ne pas être corrigées dans d’autres BIOS. Et pour terminer, le dernier
problème est le fait que le BIOS APM n’a pas suffisamment d’espace pour
implémenter une politique sophistiquée de gestion de l’énergie, ou une politique qui
peut s’adapter parfaitement aux besoins de la machine.
Le BIOS Plug and Play (PNPBIOS) n’était pas fiable dans de nombreuses situations. Le
PNPBIOS est une technologie 16 bits, le système d’exploitation doit utiliser une
émulation 16 bits afin de faire l'"interface" avec les méthodes PNPBIOS.
Le pilote APM FreeBSD est documenté dans la page de manuel apm(4).
11.14.3. Configurer l’ACPI
Le pilote acpi.ko est par défaut chargé par le loader(8) au démarrage et ne

devrait pas être compilé dans le noyau. La raison derrière cela est que les modules
sont plus facile à manipuler, par exemple pour passer à une autre version du
module acpi.ko sans avoir à recompiler le noyau. Cela présente l’avantage de rendre
les tests aisés. Une autre raison est que lancer l’ACPI après qu’un système ait terminé
son lancement donne souvent lieu à des dysfonctionnements. Si des problèmes
surviennent, vous pouvez désactiver l’ACPI. Ce pilote ne devrait et ne peut être
déchargé car le bus système l’utilise pour différentes intéraction avec le matériel.
L’ACPI peut être déactivé en ajoutant hint.acpi.0.disabled="1" dans le
fichier /boot/loader.conf ou directement à l’invite du chargeur (loader(8)).
L’ACPI et l’APM ne peuvent coexister et devraient être utilisé séparément. Le dernier chargé
s’arrêtera s’il détecte l’autre en fonctionnement.
L’ACPI peut être utilisé pour mettre en veille un système avec acpiconf(8), les
options -s et 1-5. La plupart des utilisateurs n’auront besoin que de 1 ou 3 (système
suspendu en RAM). L’option 5 provoquera un arrêt de l’alimentation par logiciel, effet
identique à un:
# halt -p
D’autres options sont disponibles via sysctl(8). Consultez les pages de
manuel acpi(4) et acpiconf(8) pour plus d’informations.
11.15. Utiliser et déboguer l’ACPI sous FreeBSD

L’ACPI est une nouvelle méthode de recherche des périphériques, de gestion de
l’énergie, et fourni un accès standardisé à différents matériels gérés auparavant par le
BIOS. Des progrès ont été fait vers un fonctionnement de l’ACPI sur tous les systèmes,
mais des bogues dans le "bytecode" du langage machine ACPI (ACPI Machine
Language-AML), des imperfections dans les sous-systèmes du noyau FreeBSD, et des
bogues dans l’interpréteur ACPI-CA d’Intel® continuent d’apparaître.
Ce document est destiné à vous permettre d’aider les développeurs du système ACPI
sous FreeBSD à identifier la cause originelle des problèmes que vous observez et à
déboguer et développer une solution. Merci de lire ce document et nous espérons
pouvoir résoudre les problèmes de votre système.
11.15.1. Soumettre des informations de débogage

Avant de soumettre un problème, assurez-vous d’utiliser la dernière version de votre BIOS, et
si elle est disponible, la dernière version du firmware du contrôleur utilisé.
Pour ceux désirant soumettre directement un problème, veuillez faire parvenir les
informations suivantes à la liste freebsd-acpi@FreeBSD.org:
 Description du comportement défectueux, en ajoutant le type et le modèle du

système et tout ce qui peut causer l’apparition du bogue. Notez également le
plus précisément possible quand le bogue a commencé à se manifester s’il est
nouveau.
 La sortie de dmesg(8) après un boot -v, y compris tout message généré lors de
la manifestation du bogue.
 La sortie de dmesg(8) après un boot -v avec l’ACPI désactivé, si cette
désactivation corrige le problème.
 La sortie de sysctl hw.acpi. C’est également un bon moyen de déterminer
quelles fonctionnalités sont offertes par votre système.
 Une URL où peut être trouvé votre code source ACPI (ACPI Source Language-
ASL). N’envoyez pas directement l’ASL sur la liste de diffusion, ce fichier peut
être très gros. Vous pouvez générer une copie de votre ASL en exécutant la
commande suivante:
# acpidump -dt > name-system.asl
(Remplacez name par votre nom d’utilisateur et system par celui du

constructeur/modèle. Par exemple: njl-FooCo6000.asl)
La plupart des développeurs lisent la liste liste de diffusion à propos de la branche
FreeBSD-CURRENT mais soumettez également les problèmes rencontrés à la liste liste
de diffusion concernant ACPI sous FreeBSD afin d’être sûr qu’ils seront vus. Soyez
patient, nous avons tous un travail à plein temps qui nous attend ailleurs. Si votre
bogue n’est pas immédiatement apparent, nous vous demanderons probablement de
soumettre un PR par l’intermédiaire de send-pr(1). Quand vous remplirez un PR,
veillez à inclure les mêmes informations que celles précisées précédemment. Cela
nous aidera à cerner et à résoudre le problème. N’envoyez pas de PR sans avoir
contacté auparavant la liste liste de diffusion concernant ACPI sous FreeBSD étant
donné que nous utilisons les PRs comme pense-bêtes de problèmes existants, et non
pas comme mécanisme de rapport. Il se peut que votre problème puisse avoir déjà
été signalé par quelqu’un d’autre.
11.15.2. Information de fond
L’ACPI est présent sur tous les ordinateurs modernes compatibles avec l’une des
architectures ia32 (x86), ia64 (Itanium), et amd64 (AMD). La norme complète définit
des fonctionnalités comme la gestion des performances du CPU, des contrôles des
niveaux d’énergie, des zones de températures, divers systèmes d’utilisation des
batteries, des contrôleurs intégrés, et l’énumération du bus. La plupart des systèmes
n’implémentent pas l’intégralité des fonctionnalités de la norme. Par exemple, un
ordinateur de bureau n’implémentera généralement que la partie énumération de
bus alors qu’un ordinateur portable aura également le support de la gestion du
refroidissement et de la batterie. Les ordinateurs portables disposent également des
modes de mise en veille et de réveil, avec toute la complexité qui en découle.
Un système compatible ACPI dispose de divers composants. Les fabricants de BIOS et

de circuits fournissent des tables de description (FADT) fixes en mémoire qui
définissent des choses comme la table APIC (utilisée par les systèmes SMP), les
registres de configuration, et des valeurs de configuration simples. De plus, est
fournie une table de "bytecode" (la table différenciée de description du système-
Differentiated System Description Table DSDT) qui spécifie sous forme d’une
arborescence l’espace des noms des périphériques et des méthodes.
Le pilote ACPI doit analyser les tables, implémenter un interpréteur pour le

"bytecode", et modifier les pilotes de périphériques et le noyau pour qu’ils acceptent
des informations en provenance du sous-système ACPI. Pour FreeBSD, Intel® fourni
un interpréteur (ACPI-CA) qui est partagé avec Linux et NetBSD. L’emplacement du
code source de l’interpréteur ACPI-CA est src/sys/contrib/dev/acpica. Le code "glu"
permettant à ACPI-CA de fonctionner sous FreeBSD se trouve
dans src/sys/dev/acpica/Osd. Et enfin, les pilotes qui gèrent les différents
périphériques ACPI se trouvent dans src/sys/dev/acpica.
11.15.3. Problèmes courants

Pour un fonctionnement correct de l’ACPI, il faut que toutes les parties fonctionnent
correctement. Voici quelques problèmes courants, par ordre de fréquence
d’apparition, et quelques contournements ou corrections possibles.
11.15.3.1. Problèmes avec la souris
Dans certains cas le réveil après une mise en veille sera à l’origine d’un
dysfonctionnement de la souris. Une solution connue est d’ajouter la
ligne hint.psm.0.flags="0x3000" au fichier /boot/loader.conf. Si cela ne fonctionne
pas, pensez à envoyer un rapport de bogue comme décrit plus haut.
11.15.3.2. Mise en veille/réveil
L’ACPI dispose de trois modes de mise en veille en RAM (STR-Suspend To

RAM), S1 à S3, et un mode de mise en veille vers le disque dur ( STD-Suspend To Disk),
appelé S4. Le mode S5 est un arrêt "soft" et est le mode dans lequel se trouve votre
système quand il est branché mais pas allumé. Le mode S4 peut être implémenté de
deux manières différentes. Le mode S4BIOS est une mise en veille vers le disque
assistée par le BIOS. Le mode S4OS est implémenté intégralement par le système
d’exploitation.
Commencez par examiner la sortie de sysctl hw.acpi à la recherche d’éléments

concernant les modes de mise en veille. Voici les résultats pour un Thinkpad:
hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.s4bios: 0
Cela signifie que nous pouvons utiliser acpiconf -s pour tester les modes S3, S4OS,
et S5. Si s4bios était égal à 1, nous disposerions d’un support S4BIOS à la place
de S4OS.
Quand vous testez la mise en veille et le réveil, commencez avec le mode S1, pour
voir s’il est supporté. Ce mode doit fonctionner dans la plupart des cas puisqu’il
nécessite peu de support. Le mode S2 n’est pas implémenté, mais si vous en disposez,
il est similaire au mode S1. La chose suivante à essayer est le mode S3. C’est le mode
STR le plus avancé et il nécessite un support du pilote important pour réinitialiser
correctement votre matériel. Si vous avez des problèmes au réveil de la machine,
n’hésitez pas à contacter la liste liste de diffusion concernant ACPI sous FreeBSD mais
ne vous attendez pas à ce que le problème soit résolu puisqu’il y a de nombreux
pilotes/matériels qui nécessitent plus de tests et de développement.
Un problème courant avec la mise en veille/le réveil est que de nombreux pilotes de
périphériques ne sauvegardent pas, ne restaurent pas, ou ne réinitialisent pas leurs
logiciel, registres ou mémoire proprement. En premier lieu pour débogguer le
problème, essayez:
# sysctl debug.bootverbose=1
# sysctl debug.acpi.suspend_bounce=1
# acpiconf -s 3
Ce test émule le cycle de mise en veille/réveil de tous les pilotes de périphériques

sans réellement passer dans l’état S3. Dans certains cas, les problèmes comme la
perte de l’état du périphérique, le dépassement du délai du chien de garde du
périphérique, les tentatives répétées, peuvent être capturés avec cette méthode.
Notez que le système n’entrera pas vraiment dans l’état S3, ce qui signifie que les
périphériques peuvent ne pas perdre leur alimentation, et nombreux fonctionneront
correctement même si les méthodes de mise en veille/réveil sont totalement
absentes, contrairement au cas d’un véritable état S3.
Les cas plus difficiles nécessitent un matériel supplémentaire, tel qu’un port série et
un câble pour débogguer à l’aide d’une console série, un port firewire et un câble
pour l’utilisation de dcons(4), et des compétences en debogguage du noyau.
Pour isoler le problème, retirez du noyau tous les pilotes de périphériques possibles.
Si cela fonctionne, vous pouvez alors identifier le pilote fautif en chargeant les pilotes
un à un jusqu’à l’apparition du problème. Généralement les pilotes binaires
comme nvidia.ko, les pilotes d’affichage X11, ou les pilotes USB seront victimes de la
plupart des problèmes tandis que ceux concernant les interfaces Ethernet
fonctionneront normalement. Si vous pouvez charger/décharger les pilotes de
périphériques correctement, vous pouvez automatiser cela en ajoutant les
commandes appropriées dans les fichiers /etc/rc.suspend et /etc/rc.resume. Il y a
un exemple en commentaire pour décharger ou charger un pilote. Essayez de
fixer hw.acpi.reset_video à zéro (0) si votre affichage est corrompu après un réveil de
la machine. Essayez des valeurs plus grandes ou plus faibles
pour hw.acpi.sleep_delay pour voir si cela aide.
Une autre méthode est d’essayer de charger une distribution Linux récente avec le
support ACPI et tester la mise en veille et le réveil sur le même matériel. Si cela
fonctionne sous Linux, c’est probablement donc un problème de pilotes FreeBSD et
déterminer quel pilote est responsable des dysfonctionnements nous aidera à
corriger le problème. Notez que les personnes qui maintiennent l’ACPI sous FreeBSD
ne s’occupe pas généralement des autres pilotes de périphériques (comme le son, le
système ATA, etc.), aussi tout rapport concernant un problème de pilote devrait
probablement en fin de compte être posté sur la liste liste de diffusion à propos de la
branche FreeBSD-CURRENT et communiqué au responsable du pilote. Si vous vous
sentez une âme d’aventurier, commencez à ajouter des printf(3)s de débogage dans
un pilote problématique pour déterminer à quel moment dans sa fonction de réveil il
se bloque.
Enfin, essayez de désactiver l’ACPI et d’activer l’APM à la place, pour voir si la mise en
veille et le réveil fonctionnent avec l’APM, tout particulièrement dans le cas de
matériel ancien (antérieur à 2000). Cela prend du temps aux constructeurs de mettre
en place le support ACPI et le matériel ancien aura sûrement des problèmes de BIOS
avec l’ACPI.
11.15.3.3. Blocages du système (temporaires ou permanents)
La plupart des blocages système sont le résultat d’une perte d’interruptions ou d’une
tempête d’interruptions. Les circuits ont beaucoup de problèmes en fonction de la
manière dont le BIOS configure les interruptions avant le démarrage, l’exactitude de
la table APIC (MADT), et le routage du System Control Interrupt (SCI).
Les tempêtes d’interruptions peuvent être distinguées des pertes d’interruptions en

contrôlant la sortie de la commande vmstat -i en examinant la ligne
mentionnant acpi0. Si le compteur s’incrémente plusieurs fois par seconde, vous êtes
victime d’une tempête d’interruptions. Si le système semble bloqué, essayez de
basculer sous DDB ( CTRL + ALT + ESC sous la console) et tapez show interrupts.
Votre plus grand espoir quand vous faites face à des problèmes d’interruptions est
d’essayer de désactiver le support APIC avec la ligne hint.apic.0.disabled="1" dans le
fichier loader.conf.
11.15.3.4. Paniques
Les paniques sont relativement rares dans le cas de l’ACPI et sont au sommet des
priorités en matière de problèmes à corriger. Le premier point est d’isoler les étapes
nécessaires à la reproduction de la panique (si possible) et d’obtenir une trace de
débogage. Suivez l’aide sur l’activation de options DDB et la configuration d’une
console série (lire la Entering the DDB Debugger from the Serial Line) ou la
configuration d’une partition dump(8). Vous pouvez obtenir une trace de débogage
sous DDB avec la commande tr. Si vous devez recopier à la main la trace de
débogage, assurez-vous de relever les cinq dernières lignes et les cinq premières
ligne de la trace.
Ensuite essayez d’isoler le problème en démarrant avec l’ACPI désactivé. Si cela

fonctionne, vous pouvez isoler le sous-système ACPI en utilisant différentes valeurs
pour l’option debug.acpi.disable. Consultez la page de manuel acpi(4) pour des
exemples.
11.15.3.5. Le système redémarre après une mise en veille ou un arrêt
Tout d’abord, essayez de fixer hw.acpi.disable_on_poweroff="0" dans loader.conf(5).

Cela empêche l’ACPI de désactiver divers événements lors du processus d’arrêt.
Certains systèmes ont besoin d’avoir cette valeur fixée à 1 (valeur par défaut) pour la
même raison. Cela corrige généralement le problème d’un système démarrant
spontanément après une mise en veille ou un arrêt.
11.15.3.6. Autres problèmes
Si vous rencontrez d’autres problèmes avec l’ACPI (impossible de travailler avec une
station d’amarrage, périphériques non détectés, etc.), veuillez envoyer un courrier
descriptif à la liste de diffusion; cependant, certains de ces problèmes peuvent être
relatifs à des partie incomplètes du sous-système ACPI et qui pourront prendre du
temps à être implémentées. Soyez patient et prêt à tester les correctifs que nous
pourront éventuellement vous envoyer.
11.15.4. ASL, acpidump, et IASL
Le problème le plus courant est le fait que les constructeurs fournissent des
"bytecodes" erronés (ou plus simplement bogués!). Cela se manifeste généralement
sur la console par des messages du noyau du type:
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\

(Node 0xc3f6d160), AE_NOT_FOUND
La plupart du temps vous pouvez corriger ces problèmes en mettant à jour votre
BIOS avec la dernière version disponible. La majorité des messages sur la console
sont inoffensifs mais si vous avez d’autres problèmes comme l’état de la batterie qui
ne fonctionne pas, ce sont de bonnes raisons pour commencer à jeter un oeil à ces
problèmes dans l’AML. Le "bytecode", connu sous le nom d’AML, est compilé à partir
d’un langage source appelé ASL. L’AML se trouve dans une table appelée DSDT. Pour
obtenir une copie de votre ASL, utilisez acpidump(8). Vous devriez utiliser de paire les
options -t (qui affiche le contenu des tables fixes) et -d (qui désassemble l’AML en
ASL). Consultez la section Soumettre des informations de déboguage pour un
exemple de syntaxe.
Le tout premier test que vous pouvez effectuer est de recompiler votre ASL à la
recherche d’erreurs. Les avertissements peuvent être généralement ignorés mais les
erreurs sont des bogues qui normalement empêchent l’ACPI de fonctionner
correctement. Pour recompiler votre ASL, utilisez la commande suivante:
# iasl your.asl
11.15.5. Correction de votre ASL
A long terme, notre objectif est que tout le monde puisse avoir un système ACPI
fonctionnant sans aucune intervention de l’utilisateur. Actuellement, nous sommes
toujours en train de développer des solutions pour contourner les erreurs courantes
faites par les fabricants de BIOS. L’interpréteur de Microsoft® (acpi.sys et acpiec.sys)
ne contrôle pas de façon stricte la conformité avec la norme, et par conséquent de
nombreux fabricants de BIOS qui testent l’ACPI uniquement sous Windows® ne
corrigent donc jamais leur ASL. Nous espérons poursuivre à identifier et documenter
avec exactitude les comportements non-standards autorisés par l’interpréteur de
Microsoft® et les reproduire de manière à permettre à FreeBSD de fonctionner sans
obliger les utilisateurs à corriger leur ASL. Comme solution et pour nous aider à
identifier ces comportements, vous pouvez corriger manuellement votre ASL. Si cela
fonctionne pour vous, veuillez nous envoyer un diff(1) de l’ancien et du nouveau ASL
de façon à ce que nous puissions corriger le comportement incorrect dans ACPI-CA
et rendre donc inutile à l’avenir votre correctif.
Voici une liste des messages d’erreur courants, leur cause, et comment les corriger:
11.15.5.1. Dépendances _OS
Certains AMLs supposent que le monde n’est fait de que différentes versions de
Windows®. Vous pouvez demander à FreeBSD de s’annoncer comme étant n’importe
quel système d’exploitation pour voir si cela corrige les problèmes que vous pouvez
rencontrer. Une manière simple de faire cela est de fixer la
variable hw.acpi.osname="Windows 2001" dans /boot/loader.conf ou avec une autre
chaîne de caractères que vous trouvez dans l’ASL.
11.15.5.2. Missing Return statements
Certaines méthodes ne renvoient pas explicitement une valeur comme la norme le

demande. Bien qu’ACPI-CA ne gère pas cela, FreeBSD contourne ce problème en
renvoyant implicitement la valeur. Vous pouvez également ajouter des "Return
statements" explicites où cela est nécessaire si vous connaissez la valeur à renvoyer.
Pour forcer iasl à compiler l’ASL, utilisez l’option -f.
11.15.5.3. Remplacer l’AML par défaut
Après avoir personnalisé votre.asl, vous voudrez le compiler, pour cela exécutez:
# iasl your.asl
Vous pouvez ajouter l’option -f pour forcer la création de l’AML, même s’il y a des
erreurs lors de la compilation. Rappelez-vous que certaines erreurs (e.g., missing
Return statements) sont automatiquement contournées par l’interpréteur.
DSDT.aml est le fichier de sortie par défaut pour iasl. Vous pouvez le charger à la
place de la version boguée de votre BIOS (qui est toujours présent dans la mémoire
flash) en éditant le fichier /boot/loader.conf comme suit:
acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/DSDT.aml"
Assurez-vous de bien copier votre fichier DSDT.aml dans le répertoire /boot.
11.15.6. Obtenir d’ACPI une sortie de débogage
Le pilote ACPI dispose d’une fonction de débogage très flexible. Elle vous permet de
spécifier un ensemble de sous-systèmes ainsi que le niveau de verbosité. Les sous-
systèmes que vous désirez déboguer sont indiqués sous la forme de "couches" et
sont divisés en composants ACPI-CA (ACPI_ALL_COMPONENTS) et en supports
matériel ACPI (ACPI_ALL_DRIVERS). La verbosité de la sortie de débogage est
spécifiée par un "niveau" et des intervalles de ACPI_LV_ERROR (rapporte juste les
erreurs) à ACPI_LV_VERBOSE (tout). Le "niveau" est un masque de bits séparés par des
espaces, aussi de nombreuses options peuvent être fixées à la fois. Dans la pratique,
vous voudrez utiliser un console série pour afficher la sortie si les informations de
débogage sont si importantes qu’elles dépassent le tampon des messages de la
console. Une liste complète des couches individuelles et des niveaux peut être
trouvée dans la page de manuel acpi(4).
L’affichage des informations de débogage n’est pas activé par défaut. Pour l’activer,
ajoutez la ligne options ACPI_DEBUG à votre fichier de configuration du noyau si l’ACPI
est compilé dans le noyau. Vous pouvez ajouter la ligne ACPI_DEBUG=1 à votre
fichier /etc/make.conf pour l’activer de façon globale. Si l’ACPI est sous forme de
module, vous pouvez recompiler votre module acpi.ko comme suit:
# cd /sys/modules/acpi/acpi
&& make clean &&
make ACPI_DEBUG=1
Installez acpi.ko dans le répertoire /boot/kernel et indiquez le niveau et la couche

désirée dans loader.conf. L’exemple suivant active les messages de débogage pour
tous les composants ACPI-CA et tous les pilotes de matériel ACPI (CPU, LID, etc.). Il
n’affichera que les messages d’erreur, c’est le niveau le moins verbeux.
debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
debug.acpi.level="ACPI_LV_ERROR"
Si l’information que vous voulez est déclenchée par un événement particulier (disons
par exemple une mise en veille suivi d’un réveil), vous pouvez abandonner les
modifications dans loader.conf et utiliser à la place sysctl pour indiquer la couche et
le niveau après le démarrage et préparer votre système pour cet événement
particulier. Les variables sysctl sont appelées de la même manière que dans le
fichier loader.conf.
11.15.7. Références
Plus d’information au sujet de l’ACPI peut être trouvé aux emplacements suivants:
 La liste de diffusion liste de diffusion concernant ACPI sous FreeBSD
 Les archives de la liste de diffusion
ACPI http://lists.freebsd.org/pipermail/freebsd-acpi/
 Les archives de l’ancienne liste de diffusion
ACPI http://home.jp.FreeBSD.org/mail-list/acpi-jp/
 La spécification ACPI
 Les pages de manuel: acpi(4), acpi_thermal(4), acpidump(8), iasl(8), acpidb(8)
 Ressource sur le débogage de la DSDT. (Utilise un exemple basé sur du
matériel Compaq mais qui est en général intéressant.)

Configuration Et Optimisation D'un Système FreeBSD

Transféré par

Droits d'auteur :

Formats disponibles

Configuration Et Optimisation D'un Système FreeBSD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Configuration Et Optimisation D'un Système FreeBSD

Transféré par

Droits d'auteur :

Formats disponibles

Configuration et optimisation d’un système FreeBSD

Après la lecture de ce chapitre, vous saurez:

 Les bases de la configuration du fichier rc.conf et des fichiers de

Avant de lire ce chapitre, vous devrez:

 Comprendre les fondements d’UNIX® et de FreeBSD (Quelques bases d’UNIX).

11.2. Configuration principale

Mettre à jour le système en employant sysinstall(8) ou make world n’écrasera pas le

11.3. Configuration des applications

Normalement, quand un logiciel porté ou pré-compilé est installé, des exemples de

Par exemple, considérez le contenu du répertoire /usr/local/etc/apache:

-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf

11.4. Démarrer des services

11.4.1. Configuration étendue des applications

Maintenant que FreeBSD dispose du système rc.d, la configuration du démarrage des

Cette procédure s’assurera que l’application utility sera lancée après le le

Cette application pourra alors avoir la ligne suivante la concernant dans le

11.4.2. Utiliser des services pour démarrer d’autres services

11.5. Configuration de l’utilitaire cron

L’utilitaire cron utilise deux types différents de fichiers de configuration, le

Examinons le fichier /etc/crontab (fichier crontab système):

# /etc/crontab - root's crontab for FreeBSD

Comme pour la plupart des fichiers de configuration de FreeBSD, le caractère # indique un

11.5.1. Installer un fichier crontab

Afin d’effacer le fichier crontab utilisateur complètement, utiliser la

11.6. Utilisation du système rc(8) sous FreeBSD

Il est facile de contrôler si un service est activé dans le fichier /etc/rc.conf en

Dans certains cas, il est également possible de recharger un service avec

Starting background file system checks in 60 seconds.

De nombreux services système dépendent d’autres services pour fonctionner

 PROVIDE: indique les services que fournit ce fichier.

 REQUIRE:liste les fichiers dont dépend ce service. Ce fichier sera

Des informations supplémentaires concernant le système rc.d peuvent être trouvées

11.7. Configuration des cartes réseaux

11.7.1. Déterminer le bon pilote de périphérique

dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38

11.7.1.1. Utilisation des pilotes NDIS de Windows®

Malheureusement il y a toujours de nombreux fabricants qui ne fournissent pas à la

Pour utiliser le NDISulator, trois choses sont nécessaires:

1. les sources du noyau;

Le type de pilote doit correspondre à la version de FreeBSD. Pour FreeBSD/i386,

L’étape suivante est de compiler le pilote binaire dans un module chargeable du

# ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS

L’utilitaire ndisgen(8) est interactif, il sollicitera l’utilisateur pour d’éventuelles

Avec le module généré, vous devez également charger les

La première commande charge le pilote d’interface NDIS, la seconde charge

Contrôlez maintenant la sortie de dmesg(8) à la recherche d’une quelconque erreur

ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on

A partir de là vous pouvez traiter le périphérique ndis0 comme n’importe quelle

11.7.2. Configuration de la carte réseau

Pour afficher la configuration des interfaces réseaux de votre système, entrer la

Dans cet exemple, les périphériques suivants ont été affichés:

 dc0: La première interface Ethernet

FreeBSD utilise le nom du pilote de périphérique suivi par un chiffre représentant

1. UP signifie que la carte est configurée et prête.

Si le résultat de la commande ifconfig(8) est similaire à:

dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500

cela indiquerait que la carte n’a pas été configurée.

ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0"

# echo 'defaultrouter="your_default_router"' >> /etc/rc.conf