diff --git a/fr_FR.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/advanced-networking/chapter.sgml index f14bd3f4d6..23ce271e2b 100644 --- a/fr_FR.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,5049 +1,5049 @@ Administration réseau avancée &trans.a.fonvieille; Synopsis Ce chapitre abordera certains nombre de sujets réseau avancés. Après la lecture de ce chapitre, vous connaîtrez: Les bases sur les passerelles et les routes. Comment configurer les périphériques IEEE 802.11 et &bluetooth;. Comment utiliser &os; en tant que pont (“bridge”). Comment configurer le démarrage via le réseau pour une machine sans disque dur. Comment configurer la translation d'adresse réseau. Comment connecter deux ordinateurs via PLIP. Comment configurer l'IPv6 sur une machine &os;. Comment configurer ATM sous &os; 5.X. Avant de lire ce chapitre, vous devrez: Comprendre les bases des procédures /etc/rc. Etre familier avec la terminologie réseau de base. Savoir comment configurer et installer un nouveau noyau &os; (). Savoir comment installer des logiciels tierce-partie (). Coranth Gryphon Contribution de Passerelles et routes routage passerelles sous-réseau Pour qu'une machine soit en mesure d'en contacter une autre, il faut que soit mis en place un mécanisme qui décrive comment aller de l'une à l'autre. C'est ce que l'on appelle le routage. Une “route” est définie par une paire d'adresses: une “destination” et une “passerelle”. Cette paire signifie que pour atteindre cette destination, vous devez passer par cette passerelle. Il y a trois sortes de destination: les machines individuelles, les sous-réseaux, et “default”—la destination par défaut. La route par défaut (“default route”) est utilisée lorsqu'aucune autre route n'est applicable. Nous parlerons un peu plus des routes par défaut par la suite. Il existe également trois sortes de passerelles: les machines individuelles, les interfaces (aussi appelées “liens”), et les adresses Ethernet matérielles (adresses MAC). Un exemple Pour illustrer différents aspects du routage, nous utiliserons l'exemple suivant, qui est produit par la commande netstat: &prompt.user; netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 route par défaut Les deux premières lignes définissent la route par défaut (dont nous parlerons dans la section suivante) et la route localhost. interface en boucle L'interface (colonne Netif) qu'il est indiqué d'utiliser pour localhost est lo0, aussi appelée interface “loopback”—en boucle. Ce qui veut dire que tout le trafic vers cette destination doit rester interne, au lieu d'être envoyé sur le réseau local, puisqu'il reviendra de toute façon à son point de départ. Ethernet adresse MAC Ce qui se remarque ensuite, ce sont les adresses commençant par 0:e0:. Ce sont les adresses Ethernet matérielles, qui sont également connues sous le nom d'adresses MAC. &os; reconnaîtra automatiquement toute machine (test0 dans l'exemple) sur le réseau local Ethernet et ajoutera une route vers cette machine, directement via l'interface Ethernet ed0. Il y a aussi un délai (colonne Expire) associé à ce type de route, qui est utilisé si l'on entend plus parler de cette machine pendant un laps de temps précis. Quand cela arrive, la route vers cette machine est automatiquement supprimée. Ces machines sont identifiées par un mécanisme appelé RIP (“Routing Information Protocol”—protocole d'information de routage), qui met en place des routes vers les machines locales en déterminant le chemin le plus court. sous-réseau &os; ajoutera également des routes de sous-réseau pour le sous-réseau local (10.20.30.255 est l'adresse de diffusion pour le sous-réseau 10.20.30, et example.com est le nom de domaine associé à ce sous-réseau). La dénomination link#1 fait référence à la première carte Ethernet de la machine. Vous constaterez qu'il n'y a pas d'autre interface associée à ces routes. Ces deux types de routes (vers les machines du réseau local et les sous-réseaux locaux) sont automatiquement configurés par un “daemon” appelé routed. S'il ne tourne pas, alors seules les routes définies comme statiques (i.e. explicitement définies) existeront. La ligne host1 fait référence à votre machine, qui est identifiée par l'adresse Ethernet. Puisque nous sommes l'émetteur, &os; sait qu'il faut utiliser l'interface en “boucle” (lo0) plutôt que d'envoyer les données sur l'interface Ethernet. Les deux lignes host2 montrent ce qui se passe quand on utilise un alias avec &man.ifconfig.8; (lisez la section sur l'Ethernet pour savoir pour quelles raisons on peut vouloir cela). Le symbole => qui suit l'interface lo0 indique que non seulement nous utilisons l'interface en “boucle” (puisque cette adresse correspond également à la machine locale), mais que c'est plus spécifiquement un alias. Ce type de route n'apparaît que sur la machine pour laquelle est défini l'alias; sur toutes les autres machines du réseau local il n'y aura q'une ligne link#1 pour cette machine. La dernière ligne (le sous-réseau destinataire 224) concerne le multicasting (diffusion pour plusieurs destinataires), qui sera abordé dans une autre section. Et enfin, diverses caractéristiques de chaque route sont indiquées dans la colonne Flags (indicateurs). Ci-dessous, une courte table présente certains de ces indicateurs et leur signification: - + U Active (“Up”): la route est active. H Machine (“Host”): la destination de la route est une machine. G Passerelle (“Gateway”): envoyer tout ce qui concerne cette destination sur la machine distante indiquée, qui déterminera à qui transmettre ensuite. S Statique (“Static”): cette route a été configurée manuellement et non pas générée automatiquement par le système. C Clone: génère une nouvelle route sur la base de celle-ci pour les machines auxquelles nous nous connectons. Ce type de route est normalement utilisé pour les réseaux locaux. W Clonée (“WasCloned”): cette route a été auto-configurée (Clone) à partir d'une route pour le réseau local. L Lien (“Link”): la route fait référence à une adresse matérielle Ethernet. Routes par défaut route par défaut Quand le système local doit établir une connexion avec une machine distante, il consulte la table de routage pour voir s'il existe déjà une route connue. Si la machine distante appartient à un sous-réseau auquel le système sait se connecter (routes clonées), alors le système vérifie s'il peut se connecter via cette interface. Si toutes les routes connues échouent, il reste alors au système une dernière option: la route par “défaut”. Cette route est un type particulier de route passerelle (c'est généralement la seule du système), et est toujours marquée avec un c dans le champ des indicateurs. Pour les machines du réseau local, cette passerelle est définie avec la machine qui est directement connectée au monde extérieur (que ce soit par une liaison PPP, DSL, cable, T1, ou toute autre interface réseau). Si vous configurez la route par défaut sur une machine qui fonctionne comme passerelle vers le monde extérieur, alors la route par défaut sera la passerelle de votre Fournisseur d'Accès à Internet (FAI). Examinons un exemple de route par défaut. Voici une configuration classique: [Local2] <--ether--> [Local1] <--PPP--> [FAI-Serv] <--ether--> [T1-GW] Les machines Local1 et Local2 sont sur votre site. Local1 est connectée au serveur du FAI via une liaison PPP par modem. Ce serveur PPP est connecté par l'intermédiaire d'un réseau local à un autre ordinateur passerelle relié au point d'entrée Internet du FAI. Les routes par défaut sur chacune de vos machines seront: - + Machine Passerelle par défaut Interface Local2 Local1 Ethernet Local1 T1-GW PPP Une question qui revient souvent est “Pourquoi (ou comment) définir T1-GW comme passerelle par défaut pour Local1, plutôt que le serveur du FAI auquel elle est connectée?“. Rappelez-vous, puisque l'interface PPP utilise, de votre côté de la connexion, une adresse IP du réseau local du FAI, les routes vers toute autre machine du réseau local du FAI seront automatiquement générées. Par conséquent vous savez déjà comment atteindre la machine T1-GW, il n'y a donc pas besoin d'étape intermédiaire qui passe par le serveur du FAI. Il est habituel d'attribuer l'adresse X.X.X.1 à la passerelle sur votre réseau local. Donc (dans notre exemple), si votre espace d'adresse de classe C local était 10.20.30 et que votre FAI utilisait l'espace 10.9.9, alors les routes par défaut seraient: - + Machine Route par défaut Local2 (10.20.30.2) Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) T1-GW (10.9.9.1) Vous pouvez aisément définir la route par défaut via le fichier /etc/rc.conf. Dans notre exemple, sur la machine Local2, nous avons ajouté la ligne suivante dans /etc/rc.conf: defaultrouter="10.20.30.1" Il est également possible de faire directement cela à partir de la ligne de commande avec la commande &man.route.8;: &prompt.root; route add default 10.20.30.1 Pour plus d'informations sur la manipulation à la main des tables de routage réseau, consultez la page de manuel &man.route.8;. Machines sur deux réseaux machines sur deux réseaux Il y a un autre type de configuration dont il faut parler, c'est celle d'une machine qui est connectée à deux réseaux différents. Techniquement, toute machine servant de passerelle (comme dans l'exemple ci-dessus, en utilisant une connexion PPP) est une machine sur deux réseaux. Mais ce terme n'est normalement utilisé que pour faire référence à une machine qui est sur deux réseaux locaux différents. Selon le cas, la machine dispose de deux cartes Ethernet, ayant chacune une adresse sur des sous-réseaux séparés. Alternativement, la machine peut ne disposer que d'une seule carte Ethernet, et utiliser des alias avec &man.ifconfig.8;. Le permier cas correspond à l'utilisation de deux réseaux Ethernet physiquement séparés, le deuxième cas est employé s'il n'y a qu'un seul réseau physique mais deux sous-réseaux logiquement distincts. Dans les deux cas, les tables de routage sont définies de telle sorte que chaque sous-réseau sache que cette machine est la passerelle (route entrante) vers l'autre sous-réseau. Cette configuration, où la machine sert de routeur entre les deux sous-réseaux, est souvent utilisée quand il faut mettre en place un dispositif de sécurité: filtrage de paquets ou coupe-feu, dans l'une ou dans les deux directions. Si vous voulez que cette machine transmette réellement les paquets entre les deux interfaces, vous devez demander à &os; d'activer cette fonctionnalité. Lisez la section suivante pour plus de détails sur comment faire cela. Mettre en place un routeur routeur Un routeur est un système qui transmet les paquets d'une interface à une autre. Les standards de l'Internet et de bons principes d'ingénierie empêchent le projet &os; d'activer cette fonction par défaut sous &os;. Vous pouvez l'activer en positionnant à YES la variable suivante du fichier &man.rc.conf.5;: gateway_enable=YES # Set to YES if this host will be a gateway Cette option fixera la variable &man.sysctl.8; net.inet.ip.forwarding à la valeur 1. Si vous devez arrêter temporairement le routage, vous pouvez positionner la variable momentanément à 0. Votre nouveau routeur aura besoin de route pour savoir où envoyer le trafic. Si votre réseau est suffisamment simple vous pouvez utiliser des routes statiques. &os; est également fourni avec le “daemon” de routage BSD standard &man.routed.8;, qui comprend et utilise les protocoles RIP (version 1 est 2) et IRDP. Le support de BGP v4, OSPF v2, et d'autres protocoles de routage sophistiqué est disponible avec le logiciel net/zebra. Des produits commerciaux comme &gated; sont également disponibles comme solutions avancées de routage. BGP RIP OSPF Même quand &os; est configuré de cette manière, il ne respecte pas complètement les standards Internet en matière de routeur. Il en est cependant suffisamment proche pour une utilisation ordinaire. Al Hoang Contribution de Configurarion des routes statiques Configuration manuelle Supposons que nous avons un réseau comme celui-ci: INTERNET | (10.0.0.1/24) Routeur Internet | |Interface xl0 |10.0.0.10/24 +------+ | | RouteurA | | (passerelle FreeBSD) +------+ | Interface xl1 | 192.168.1.1/24 | +--------------------------------+ Réseau interne 1 | 192.168.1.2/24 | +------+ | | RouteurB | | +------+ | 192.168.2.1/24 | Réseau interne 2 Dans ce scénario, RouteurA est notre machine &os; qui joue le rôle de routeur pour l'Internet. Elle a une route par défaut vers 10.0.0.1 qui permet de se connecter au reste du monde extérieur. Nous supposerons que la machine RouteurB est correctement configurée et sait comment transmettre vers n'importe quelle destination (D'après notre schéma c'est relativement simple. Ajoutez juste une route par défaut sur RouterB en utilisant 192.168.1.1 comme passerelle). Si nous regardons la table de routage de RouteurA nous verrions quelque chose comme: &prompt.user; netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1 Avec la table de routage actuelle, RouterA ne sera pas en mesure d'atteindre notre réseau interne 2. Elle ne dispose pas de route pour 192.168.2.0/24. Une manière de résoudre cela est d'ajouter manuellement la route. La commande suivante ajouterait le réseau interne 2 à la table de routage de RouterA en utilisant 192.168.1.2 comme point intermédiaire: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Maintenant RouteurA peut joindre n'importe quelle machine du réseau 192.168.2.0/24. Configuration persistante L'exemple précédent est parfait pour configurer une route statique sur un système en fonctionnement. Cependant, le problème est que l'information de routage ne sera pas conservée si vous redémarrez votre machine &os;. L'addition d'une route statique doit se faire dans votre fichier /etc/rc.conf: # Add Internal Net 2 as a static route static_routes="internalnet2" route_internalnet2="-net 192.168.2.0/24 192.168.1.2" La variable static_routes est une liste de chaîne de caractères séparées par une espace. Chaque chaîne fait référence à un nom de route. Dans notre exemple nous avons qu'une seule chaîne dans static_routes. Cette chaîne est internalnet2. Nous ajoutons ensuite une variable de configuration appelée route_internalnet2 dans laquelle nous mettons tous les paramètres de configuration que nous passerions à la commande &man.route.8;. Pour nous exemple précédent nous aurions utilisé la commande: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 nous avons donc besoin de "-net 192.168.2.0/24 192.168.1.2". Comme cela a été précisé, nous pouvons avoir plus d'une chaîne dans la variable static_routes. Cela nous permet de créer plusieurs routes statiques. Les lignes suivantes donnent un exemple d'ajout de routes statiques pour les réseaux 192.168.0.0/24 et 192.168.1.0/24 sur un routeur imaginaire: static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1" Propagation de route propagation de route Nous avons déjà expliqué comment définir nos routes vers le monde extérieur, mais pas comment le monde extérieur apprend à nous localiser. Nous savons déjà que les tables de routages peuvent être renseignées pour que tout le trafic pour un espace d'adresses donné (dans nos exemples, un sous-réseau de classe C) soit envoyé à une machine précise de ce réseau, qui transmettra les paquets entrants. Lorsqu'il attribue un espace d'adresses à votre site, votre fournisseur d'accès définira ses tables de routage de sorte que tout le trafic destiné à votre sous-réseau vous soit envoyé sur votre liaison PPP. Mais comment les sites à l'autre bout du pays savent-ils qu'ils doivent passer par votre fournisseur d'accès? Il existe un mécanisme (assez semblable au système d'information distribué du DNS) qui conserve un enregistrement de tous les espaces d'adresses affectés, et définit leur point de connexion à la dorsale Internet (“backbone”). La “dorsale” comprend les liaisons principales qui véhiculent le trafic Internet à travers le pays et le monde entier. Chaque machine de la dorsale dispose d'une copie de l'ensemble des tables maîtresses qui aiguillent le trafic pour un réseau donné vers le transporteur correspondant de la dorsale, et de là par l'intermédiaire de fournisseurs d'accès successifs, jusqu'à atteindre votre réseau. C'est le rôle de votre fournisseur d'accès d'annoncer aux sites de la dorsale qu'il est le point de connexion (et par conséquent la route entrante) pour votre site. C'est ce que l'on appelle la propagation de route. En cas de problème traceroute Il se peut qu'il y ait parfois un problème avec la propagation de route et que certains sites ne puissent vous atteindre. La commande probablement la plus utile pour déterminer où une route est défaillante est la commande &man.traceroute.8;. Elle est également utile si vous n'arrivez pas à vous connecter à une machine distante (i.e. lorsque &man.ping.8; échoue). La commande &man.traceroute.8; prend comme paramètre le nom de la machine distante avec laquelle vous essayez d'établir une connexion. Elle vous donnera la liste de passerelles intermédiaires jusqu'à la machine cible, ou jusqu'à ce qu'il n'y ait plus de connexion. Pour plus d'informations, consultez la page de manuel de &man.traceroute.8;. Routage multicast multicast options MROUTING &os; supporte nativement les applications et le routage multicast (diffusion pour plusieurs destinataires). Les applications multicast ne nécessitent pas de configuration spécifique de &os;, généralement, elles fonctionneront directement. Le routage multicast demande à ce que le support soit compilé dans le noyau: options MROUTING De plus, le “daemon” de routage multicast, &man.mrouted.8; doit être configuré par l'intermédiaire du fichier /etc/mrouted.conf pour mettre en place des tunnels et le protocole DVMRP. Plus de détails sur la configuration du routage multicast peuvent être trouvés dans la page de manuel de &man.mrouted.8;. Eric Anderson Ecrit par Réseau sans fil réseau sans fil 802.11 réseau sans fil Introduction Il peut être très utile de pouvoir utiliser un micro-ordinateur sans le désagrément d'être constamment relié à un câble réseau. &os; peut être utilisé comme client sans fil, et même comme “point d'accès” sans fil. Modes de fonctionnement des systèmes sans fils Il existe deux manières différentes de configurer les périphériques sans fil 802.11: les modes BSS et IBSS. Mode BSS Le mode BSS est le mode généralement utilisé. Le mode BSS est également appelé mode infrastructure. Dans ce mode, plusieurs points d'accès sans fils sont connectés à un réseau câblé. Chaque réseau sans fil possède son propre nom. Ce nom est ce que l'on appelle le “SSID” du réseau. Les clients sans fils se connectent à ces points d'accès sans fils. La norme IEEE 802.11 définie le protocole que les réseaux sans fils utilisent pour les connexions. Un client sans fil peut être attaché à un réseau particulier quand un SSID est fixé. Un client peut s'attacher à n'importe quel réseau en ne définissant pas explicitement de SSID. Mode IBSS Le mode IBSS, également appelé mode “ad-hoc”, est conçu pour les connexions point à point. Il existe en fait deux types de mode ad-hoc. Le premier est le mode IBSS, également appelé mode ad-hoc ou IEEE ad-hoc. Ce mode est défini par les normes IEEE 802.11. Le deuxième mode est appelé ad-hoc démo ou encore mode ad-hoc Lucent (et parfois, ce qui prête à confusion, mode ad-hoc). C'est l'ancien mode ad-hoc pré-standard 802.11 et ne devrait être utilisé qu'avec d'anciennes installations. Nous ne parlerons pas des modes ad-hoc dans ce qui suit. Mode infrastructure Points d'accès Un point d'accès est un périphérique sans fil qui permet à un ou plusieurs clients sans fils d'utiliser ce périphérique comme un hub. Quand ils utilisent un point d'accès, tous les clients communiquent par l'intermédiaire de ce point d'accès. Plusieurs points d'accès sont souvent utilisés pour couvrir l'intégralité d'une zone géographique comme une maison, une entreprise, ou un parc avec un réseau sans fil. Les points d'accès ont généralement plusieurs connexions réseaux: la carte réseaux sans fil, et une ou plusieurs cartes réseaux Ethernet pour les connexions avec le reste du réseau. Les points d'accès peuvent être achetés tout fait, ou vous pouvez construire le votre avec &os; et une carte réseau sans fil supportée. De nombreux constructeurs proposent des points d'accès et des cartes réseaux sans fils avec diverses fonctionnalités. Construire un point d'accès avec &os; réseau sans fil point d'accès Pré-requis En vue de mettre en place un point d'accès sans fil sous &os;, vous avez besoin d'une carte réseau sans fil compatible. Actuellement seule les cartes basées sur le circuit Prism sont supportées. Vous aurez également besoin d'une carte réseau câblée supportée par &os; (cela ne devrait pas être difficile à trouver, &os; supporte de nombreuses cartes). Dans le cadre de cette section, nous supposerons que le trafic passera par un pont entre la carte sans fil et le réseau relié à la carte réseau classique. Le mode point d'accès implémenté par &os; fonctionne mieux avec certaines versions de firmware. Les cartes utilisant un circuit Prism 2 devraient utiliser un firmware 1.3.4 ou plus récent. Les cartes Prism 2.5 et Prism 3 devraient utiliser la version 1.4.9. Des versions de firmware plus anciennes pourront ne pas fonctionner correctement. Actuellement, la seule manière de mettre à jour vos cartes est d'utiliser les outils de mise à jour du firmware pour &windows; disponibles auprès du constructeur de votre carte. Configuration Assurez-vous tout d'abord que votre système voit la carte réseau sans fil: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 Ne vous préoccupez pas des détails, verifiez juste que s'affiche quelque chose qui vous indique qu'une carte réseau sans fil est installée. Si vous avez des problèmes à voir l'interface réseau sans fil correspondante, et que vous utilisez une carte de type PC Card, vous devriez consultez les pages de manuel &man.pccardc.8; et &man.pccardd.8; pour plus d'information. Ensuite, vous devrez charger un module afin de mettre en place la partie de &os; faisant office de pont pour le point d'accès. Pour charger le module &man.bridge.4;, exécutez la commande suivante: &prompt.root; kldload bridge Vous ne devriez pas voir apparaître de message d'erreur lors du chargement du module. Si ce n'est pas le cas, vous devrez peut-être compiler le support &man.bridge.4; dans votre noyau. La section sur le Bridging de ce manuel devrait pouvoir vous aider dans cette tâche. Maintenant que cette partie est assurée, nous devons dire à &os; entre quelles interface le pont doit être installé. Nous effectuons cette configuration en utilisant &man.sysctl.8;: &prompt.root; sysctl net.link.ether.bridge=1 &prompt.root; sysctl net.link.ether.bridge_cfg="wi0,xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 Sous &os; 5.2-RELEASE et versions suivantes, vous devez utiliser à la place les options suivantes: &prompt.root; sysctl net.link.ether.bridge.enable=1 &prompt.root; sysctl net.link.ether.bridge.config="wi0,xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 Il est maintenant possible de configurer la carte. La commande suivante positionnera la carte en mode point d'accès: &prompt.root; ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP" La ligne &man.ifconfig.8; active l'interface wi0, fixe son paramètre SSID à la valeur my_net, et fixe le nom de station à FreeBSD AP. L'option positionne la carte dans le mode 11Mbps et est nécessaire pour que le paramètre soit pris en compte. L'option place l'interface dans le mode point d'accès. L'option fixe le canal 802.11b à employer. La page de manuel &man.wicontrol.8; donne les options de canaux valides en fonction de votre zone géographique. Vous devez maintenant disposer d'un point d'accès opérationnel et en fonctionnement. Vous êtes encouragés à lire les pages de manuel &man.wicontrol.8;, &man.ifconfig.8;, et &man.wi.4; pour plus d'amples informations. Il est également conseillé de lire la section qui suit sur le chiffrage. Information d'état Une fois que le point d'accès est configuré et opérationnel, les opérateurs voudront voir quels clients sont associés avec le point d'accès. A n'importe quel instant, l'opérateur pourra taper: &prompt.root; wicontrol -l 1 station: 00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15 Ceci nous montre qu'une station est associée, ainsi que son paramétrage. Les informations indiquées concernant le signal devraient être utilisées uniquement comme une indication relative sur sa puissance. Sa conversion en dBm ou tout autre unité varie en fonction des différentes versions de firmware. Clients Un client sans fil est un système qui se connecte à un point d'accès ou un autre client directement. Typiquement, les clients sans fils disposent d'une seule interface réseau, la carte réseau sans fil. Il existe quelques manières différentes de configurer un client sans fil. Elles sont basées sur les différents modes sans fils, généralement les modes BSS (mode infrastructure, qui nécessite un point d'accès), et IBSS (mode ad-hoc, ou mode point à point). Dans notre exemple, nous utiliserons le plus populaire des deux, le mode BSS, pour discuter avec un point d'accès. Pré-requis Il n'y a qu'un seul pré-requis pour configurer &os; comme client sans fil. Vous aurez besoin d'une carte sans fil supportée par &os;. Configurer un client sans fil &os; Avant de commencer, vous aurez besoin de connaître certaines choses concernant le réseau sans fil auquel vous désirez vous connecter. Dans cet exemple, nous rejoignons un réseau ayant pour nom my_net, et avec le chiffrage des liaisons désactivé. Dans cet exemple, nous n'utilisons pas le chiffrage des liaisons, ce qui est une situation dangereuse. Dans la section suivante, nous verrons comment activer le chiffrage, pourquoi il est important de le faire, et pourquoi certaines technologies de chiffrage ne vous protégerons pas complètement. Assurez-vous que votre carte est reconnue par &os;: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 Maintenant, nous pouvons configurer la carte suivant les paramètres de notre réseau: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net Remplacez 192.168.0.20 et 255.255.255.0 avec une adresse IP ainsi qu'un masque de sous-réseau valides de votre réseau câblé. Rappelez-vous, notre point d'accès joue le rôle de pont entre le réseau sans fil et le réseau câblé, il apparaîtra aux autres cartes sur votre réseau que vous êtes sur le même réseau câblé. Une fois cela effectué, vous devriez être en mesure d'utiliser &man.ping.8; pour atteindre les machines sur le réseau câblé de la même façon que si vous étiez connecté en utilisant un câble réseau standard. Si vous rencontrez des problèmes avec votre connexion sans fil, vérifiez que vous êtes associé—“associated” (connecté) avec le point d'accès: &prompt.root; ifconfig wi0 devrait retourner un certain nombre d'information; et vous devriez voir s'afficher: status: associated Si associated n'est pas affiché, alors il se peut que vous soyez hors de portée du point d'accès, que vous ayez le chiffrage activé, ou peut-être que vous ayez un problème de configuration. Chiffrement réseau sans fil chiffrement L'utilisation du chiffrement sur un réseau sans fil est important parce que vous n'avez plus la possibilité de conserver le réseau dans une zone protégée. Vos données sans fil seront diffusées dans tout le voisinnage, et toute personne désirant y accéder pourra le faire. C'est ici que le chiffrement entre en jeu. En chiffrant les données qui sont envoyées par les ondes, vous rendez plus difficile l'interception de celles-ci par quiconque d'intéressé. Les deux méthodes les plus courantes de chiffrage des données entre un client et un point d'accès sont le protocol WEP et &man.ipsec.4;. WEP WEP WEP est l'abbrévation de “Wired Equivalency Protocol“. Le protocole de chiffrage WEP est une tentive de rendre les réseaux sans fils aussi sûrs et sécurisés qu'un réseau filaire. Malheureusement, il a été craqué, et est relativement simple à déjouer. Cela signifie que l'on ne doit pas lui faire confiance quand il est nécessaire de chiffrer des données sensibles. Cela reste mieux que rien du tout, utilisez ce qui suit pour activer WEP sur votre nouveau point d'accès &os;: &prompt.root; ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap Et vous pouvez activer WEP sur un client avec la commande: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890 Notez que vous devriez remplacer 0x1234567890 par une clé plus personnelle. IPsec &man.ipsec.4; est un outil bien plus puissant et robuste pour chiffer des données sur un réseau. C'est la méthode à préferer pour chiffrer les données sur un réseau sans fil. Vous pouvez obtenir plus de détails concernant &man.ipsec.4; et comment l'implémenter dans la section IPsec de ce manuel. Outils Il existe un petit nombre d'outils disponibles pour le débogage et la configuration d'un réseau sans fil, et nous tenterons ici d'en décrire certains ainsi que leurs fonctionnalités. La suite <application>bsd-airtools</application> La suite bsd-airtools est une trousse à outils complète qui comprend des outils d'audit sans fil pour le craquage du système WEP, la détection de points d'accès, etc. Les utilitaires bsd-airtools peuvent être installés à partir du logiciel porté net/bsd-airtools. Des instructions sur l'installation des logiciels portés peuvent être trouvées dans le de ce manuel. Le programme dstumbler est l'outil qui permet la recherche de points d'accès et la mesure du rapport signal sur bruit. Si vous avez des difficultés à mettre en place et à faire fonctionner votre point d'accès, dstumbler pourra vous aider dans ce sens. Pour tester la sécurité de votre réseau sans fil, vous pouvez choisir d'employer les outils “dweputils” (dwepcrack, dwepdump et dwepkeygen) pour vous aider à déterminer si WEP répond à vos besoins en matière de sécurité au niveau de votre réseau sans fil. Les utilitaires <command>wicontrol</command>, <command>ancontrol</command> et <command>raycontrol</command> Il existe des outils que vous pouvez utiliser pour contrôler le comportement de votre carte réseau sans fil sur le réseau sans fil. Dans les exemples précédents, nous avons choisi d'employer &man.wicontrol.8; puisque notre carte sans fil utilise l'interface wi0. Si vous avez une carte sans fil Cisco, elle apparaîtrait comme an0, et vous utiliseriez alors le programme &man.ancontrol.8;. La commande <command>ifconfig</command> ifconfig La commande &man.ifconfig.8; propose plusieurs options identiques à celles de &man.wicontrol.8;, cependant il manque quelques options. Consultez la page de manuel d'&man.ifconfig.8; pour les différents paramètres et options en ligne de commande. Cartes supportées Points d'accès Les seules cartes actuellement supportées pour le mode BSS (points d'accès) sont celles basées sur les circuits Prism 2, 2.5, ou 3. Pour une liste complète, consultez la page de manuel de &man.wi.4;. Clients 802.11b Presque toutes les cartes réseaux sans fil 802.11b sont supportées sous &os;. La plupart des cartes basées sur les circuits Prism, Spectrum24, Hermes, Aironet, et Raylink fonctionneront dans le mode IBSS (ad-hoc, point à point, et BSS). Clients 802.11a & 802.11g Le pilote de périphérique &man.ath.4; supporte les normes 802.11a et 802.11g. Si votre carte est basée sur un circuit Atheros, vous devriez être en mesure d'utiliser ce pilote. 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 &os; 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 µsoft.windows;. La plupart des développeurs, y compris ceux impliqués dans &os;, ont choisi cette dernière approche. Grâce aux contributions de Bill Paul (wpaul), depuis &os; 5.3-RELEASE, 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 &os; (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;. Cette fonctionnalité est relativement nouvelle, mais semble fonctionner correctement dans la plupart des tests. Pour utiliser le NDISulator, vous avez besoin de trois choses: les sources du noyau; le pilote binaire &windowsxp; (extension .SYS); le fichier de configuration du pilote &windowsxp; (extension .INF). Vous aurez besoin de compiler le module d'interface du mini-pilote &man.ndis.4;. En tant que root: &prompt.root; cd /usr/src/sys/modules/ndis &prompt.root; make && make install 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. L'étape suivante est de compiler le pilote binaire dans un module chargeable du noyau. Pour effectuer cela, en tant que root, rendez vous dans le répertoire du module if_ndis et copiez-y les fichiers du pilote &windows;: &prompt.root; cd /usr/src/sys/modules/if_ndis &prompt.root; cp /path/to/driver/W32DRIVER.SYS ./ &prompt.root; cp /path/to/driver/W32DRIVER.INF ./ Nous utiliserons maintenant l'utilitaire ndiscvt pour générer le fichier d'entête ndis_driver_data.h du pilote pour la compilation du module: &prompt.root; ndiscvt -i W32DRIVER.INF -s W32DRIVER.SYS -o ndis_driver_data.h Les options et précisent respectivement le fichier de configuration et le fichier binaire. Nous utilisons l'option car le Makefile recherchera ce fichier lors de la compilation du module. Certains pilotes &windows; nécessitent des fichiers supplémentaires pour fonctionner. Vous pouvez les ajouter avec ndiscvt en utilisant l'option . Consultez la page de manuel &man.ndiscvt.8; pour plus d'information. Nous pouvons enfin compiler et installer le module du pilote: &prompt.root; make && make install Pour utiliser le pilote, vous devez charger les modules appropriés: &prompt.root; kldload ndis &prompt.root; kldload if_ndis La première commande charge le pilote d'interface NDIS, la seconde charge l'interface réseau. Contrôlez la sortie de &man.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 quel périphérique sans fil (e.g. wi0) et consulter les premières sections de ce chapitre. Pav Lucistnik Ecrit par
pav@oook.cz
 Bluetooth Bluetooth Introduction &bluetooth; est une technologie sans fil pour créer des réseaux personnels sans fils fonctionnant dans la bande 2.4 GHz ne nécessitant pas d'autorisation, avec une portée de 10 mètres. Les réseaux étant généralement composés de périphériques nomades comme les téléphones portables, les assistants personnels et les ordinateurs portables. Contrairement à l'autre technologie sans fil, Wi-Fi, &bluetooth; offre un niveau plus élevé de profils de service, par exemple des serveurs de fichiers semblables à FTP, “file pushing”, transport de la voix, émulation de lignes séries, et bien plus. La pile &bluetooth; sous &os; utilise le système Netgraph (voir &man.netgraph.4;). Une large gamme d'adaptateurs USB &bluetooth; sont supportés par le pilote &man.ng.ubt.4;. Les périphériques &bluetooth; basés sur le circuit Broadcom BCM2033 sont supportés par les pilotes &man.ubtbcmfw.4; et &man.ng.ubt.4;. La carte 3Com &bluetooth; PC Card 3CRWB60-A demande le pilote &man.ng.bt3c.4;. Les périphériques &bluetooth; de type série et UART sont supportés via les pilotes &man.sio.4;, &man.ng.h4.4; et &man.hcseriald.8;. Cette section décrit l'utilisation d'un adaptateur USB &bluetooth;. Le support &bluetooth; est disponible sur les systèmes 5.0 et suivants. Branchement du périphérique Par défaut les pilotes de périphériques &bluetooth; sont disponibles sous la forme de modules du noyau. Avant de brancher le périphérique, vous devrez charger le pilote dans le noyau: &prompt.root; kldload ng_ubt Si le périphérique &bluetooth; est présent au démarrage du système, chargez le module à partir de /boot/loader.conf: ng_ubt_load="YES" Branchez votre clé USB. Une sortie semblable à celle-ci devrait s'afficher sur la console (ou dans les journaux du système): ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 Copiez /usr/share/examples/netgraph/bluetooth/rc.bluetooth à un emplacement adapté, comme /etc/rc.bluetooth. Cette procédure est utilisée pour démarrer et arrêter la pile &bluetooth;. C'est une bonne idée d'arrêter la pile avant de débrancher le périphérique, mais ce n'est pas (généralement) fatal. Quand la pile démarre, vous devriez avoir des messages similaires aux suivants: &prompt.root; /etc/rc.bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 HCI Interface de contrôle de l'hôte (HCI) L'interface de contrôle de l'hôte (HCI) fournit une interface de commande pour le contrôleur de la bande de base et le gestionnaire de liaisons, et l'accès à l'état du matériel et aux registres de contrôle. Cette interface offre une méthode uniforme d'accès aux fonctions de la bande de base &bluetooth;. La couche HCI de l'hôte échange des données et des commandes avec le firmware HCI du matériel &bluetooth;. Le pilote de la couche de transport du contrôleur d'hôte (i.e. le bus physique) fournit aux deux couches HCI la possibilité d'échanger des informations entre elles. Un seul noeud Netgraph de type hci est créé pour un périphérique &bluetooth;. Le noeud HCI est normalement connecté au noeud du pilote &bluetooth; (flux descendant) et au noeud L2CAP (flux montant). Toutes les opérations HCI doivent être effectuées sur le noeud HCI et non pas sur le noeud du pilote de périphérique. Le nom par défaut pour le noeud HCI est “devicehci”. Pour plus de détails consultez la page de manuel &man.ng.hci.4;. Une des tâches les plus courantes est la recherche de périphériques &bluetooth; dans le voisinage hertzien. Cette opération est appelée inquiry (enquête, recherche). Cette recherche et les autres opérations relatives à HCI sont effectuées par l'utilitaire &man.hccontrol.8;. L'exemple ci-dessous montre comment déterminer quels périphériques &bluetooth; sont dans le voisinnage. Vous devriez obtenir une listes de périphériques au bout de quelques secondes. Notez qu'un périphérique distant ne répondra à la recherche que s'il est placé dans le mode discoverable. &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] BD_ADDR est l'adresse unique d'un périphérique &bluetooth;, similaire à l'adresse MAC d'une carte réseau. Cette adresse est nécessaire pour communiquer avec un périphérique. Il est possible d'assigner un nom humainement compréhensible à l'adresse BD_ADDR. Le fichier /etc/bluetooth/hosts contient des informations concernant les hôtes &bluetooth; connus. L'exemple suivant montre comment obtenir le nom qui a été assigné au périphérique distant: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39 Si vous effectuez une recherche sur un périphérique &bluetooth; distant, vous devriez trouver votre ordinateur en tant que “votre.machine.nom (ubt0)”. Le nom affecté au périphérique local peut être modifié à tout moment. Le système &bluetooth; fournit une connexion point à point (seules deux matériels &bluetooth; sont concernés), ou une connexion point à multipoints. Dans le cas d'une connexion point à multipoints, la connexion est partagés entre plusieurs périphériques &bluetooth;. L'exemple suivant montre comment obtenir la liste des connexions en bande de base actives pour le périphérique local: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN Une manipulation de la connexion est utile quand la fin d'une connexion en bande de base est nécessaire. Notez qu'il n'est normalement pas nécessaire de le faire à la main. La pile mettra fin automatiquement aux connexions en bande de base inactives. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] Référez-vous à la commande hccontrol help pour une liste complète des commandes HCI disponibles. La plupart des commandes HCI ne nécessitent pas les privilèges du super-utilisateur. L2CAP Protocole d'adaptation et de contrôle de lien logique (L2CAP) Le protocole d'adaptation et de contrôle de lien logique (L2CAP) fournit des services orientés connexion ou non aux protocoles de niveaux supérieurs, et cela avec des possibilités de multiplexage de protocoles, de segmentation et de réassemblage. L2CAP permet aux applications et aux protocoles de niveaux supérieurs de transmettre et recevoir des paquets L2CAP d'une taille allant jusqu'à 64 Ko. L2CAP est basé sur le concept de canaux. Un canal est une connexion logique au sommet de la connexion en bande de base. Chaque canal est attaché à un protocole suivant le schéma plusieurs-vers-un. Plusieurs canaux peuvent être attachés au même protocole, mais un canal ne peut être attachés à plusieurs protocoles. Chaque paquet L2CAP reçu sur un canal est dirigé vers le protocole de niveau supérieur approprié. Plusieurs canaux peuvent partager la même connexion en bande de base. Un seul noeud Netgraph de type l2cap est créé pour un périphérique &bluetooth;. Le noeud L2CAP est normalement connecté au noeud HCI &bluetooth; (flux descendant) et aux noeuds des “sockets” &bluetooth; (flux montant). Le nom par défaut pour le noeud L2CAP est “device2cap”. Pour plus de détails consultez la page de manuel &man.ng.l2cap.4;. Une commande utile est &man.l2ping.8;, qui peut être utilisée pour “pinguer” les autres périphériques. Certaines implémentations de &bluetooth; peuvent ne pas renvoyer toutes les données qui leur sont envoyées, aussi 0 bytes dans ce qui suit est normal. &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 L'utilitaire &man.l2control.8; est employé pour effectuer diverses opérations sur les noeuds L2CAP. Cet exemple montre comment obtenir la liste des connexions logiques (canaux) et la liste des connexions en bande de base pour le périphérique local: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN &prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN Un autre outil de diagnostic est &man.btsockstat.1;. Il effectue un travail similaire à celui de &man.netstat.1;, mais relatif aux structures de données réseau &bluetooth;. L'exemple ci-dessous montre la même connexion logique que &man.l2control.8; ci-dessus. &prompt.user; btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN RFCOMM Protocole RFCOMM Le protocole RFCOMM permet l'émulation du port série au-dessus du protocole L2CAP. Le protocole est basé sur la norme ETSI TS 07.10. RFCOMM est un protocole de transport simple, avec les dispositions supplémentaires pour émuler les 9 circuits (signaux) d'un port série RS232 (EIATIA-232-E). Le protocole RFCOMM supporte jusqu'à 60 connexions simultanées (canaux RFCOMM) entre deux périphériques &bluetooth;. Dans le cas de RFCOMM, l'établissement d'une communication implique deux applications tournant sur des périphériques différents (les extrémités de la communication) avec un segment de communication entre eux. RFCOMM est prévu pour couvrir les applications faisant usage des ports séries des périphériques sur lesquels elles résident. Le segment de communication est une liaison &bluetooth; d'un périphérique vers un autre (connexion directe). RFCOMM est seulement concerné par la connexion entre périphériques dans le cas d'un raccordement direct, ou entre le périphérique et un modem dans le cas d'un réseau. RFCOMM peut supporter d'autres configurations, comme les modules qui communiquent par l'intermédiaire de la technologie sans fil &bluetooth; d'un côté et utilise une interface câblée de l'autre côté. Sous &os;, le protocole RFCOMM est implémenté au niveau de la couche des “sockets” &bluetooth;. couplage Couplage des périphériques Par défaut, une communication &bluetooth; n'est pas authentifiée, et n'importe quel périphérique peut parler avec n'importe quel autre périphérique. Un périphérique &bluetooth; (par exemple un téléphone portable) peut choisir de demander une authentification pour fournir un service particulier (par exemple un service de connexion téléphonique). L'authentification &bluetooth; est généralement effectuée avec des codes PIN. Un code PIN est une chaîne ASCII d'une longueur de 16 caractères. L'utilisateur doit entrer le même code PIN sur les deux périphériques. Une fois que l'utilisateur a entré le code PIN, les deux périphériques génèrent une clé de liaison (link key). Ensuite la clé peut être enregistrée soit dans les périphériques eux-mêmes ou sur un moyen de stockage non-volatile. La fois suivante les deux périphériques utiliseront la clé précédemment générée. La procédure décrite est appelée couplage. Si la clé de liaison est perdue par un des périphériques alors l'opération de couplage doit être répétée. Le “daemon” &man.hcsecd.8; est responsable de la gestion de toutes les requêtes d'authentification &bluetooth;. Le fichier de configuration par défaut est /etc/bluetooth/hcsecd.conf. Un exemple de section pour un téléphone portable avec un code PIN arbitraire de “1234” est donné ci-dessous: device { bdaddr 00:80:37:29:19:a4; name "Pav's T39"; key nokey; pin "1234"; } Il n'y pas de limitation sur les codes PIN (en dehors de la longueur). Certains périphériques (comme les casques-micro &bluetooth;) peuvent avoir un code PIN définitivement fixé. Le paramètre force le “daemon” &man.hcsecd.8; à rester en tâche de fond, il est donc aisé de voir ce qu'il se passe. Configurez le périphérique distant pour recevoir le couplage et initier la connexion &bluetooth; vers le périphérique distant. Le périphérique distant devrait annoncer que le couplage a été accepté, et demander le code PIN. Entrez le même code PIN que celui que vous avez dand le fichier hcsecd.conf. Maintenant votre PC et le périphérique distant sont couplés. Alternativement, vous pouvez initier le couplage sur le périphérique distant. Ce qui suit est une partie de la sortie du “daemon” hcsecd: hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 SDP Le protocole de découverte de service (SDP) Le protocole de découverte de service (SDP) offre aux applications clientes les moyens de découvrir l'existence des services fournis par les applications serveurs ainsi que les propriétés (attributs) de ces services. Les attributs d'un service comprennent le type ou la classe du service offert et le mécanisme ou l'information sur le protocole nécessaire pour utiliser le service. Le SDP implique la communication entre un serveur SDP et un client SDP. Le serveur maintient une liste d'enregistrements de services qui décrit les caractéristiques des services associés avec le serveur. Chaque enregistrement de service contient l'information sur un seul serveur. Un client peut récupérer l'information à partir d'un enregistrement de service maintenu par le serveur SDP en émettant une requête SDP. Si le client, ou une application associée avec le client, décide d'utiliser un service, il doit ouvrir une connexion séparée avec le fournisseur du service afin d'utiliser ce service. Le SDP fournit un mécanisme pour découvrir les services et leur attributs, mais n'offre pas de mécanisme pour utiliser ces services. Généralement, un client SDP recherche les services sur la base de caractéristiques de services désirées. Cependant, il est parfois désirable de découvrir quel type de services sont décrits par les enregistrements de services d'un serveur SDP sans aucune information préalable sur les services. Ce processus de recherche des services offerts est appelé navigation (“browsing”). Le serveur SDP &bluetooth; &man.sdpd.8; et le client en ligne de commande &man.sdpcontrol.8; font partie de l'installation &os; standard. L'exemple suivant montre comment effectuer un requête de navigation (“browse”) SDP: &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 ... et ainsi de suite. Remarquez que chaque service a une liste d'attributs (canal RFCOMM par exemple). En fonction du service vous pourrez avoir besoin de prendre note de certains de ces attributs. Certaines implémentations &bluetooth; ne supportent pas les requêtes de navigation et peuvent renvoyer une liste vide. Dans ce cas il est possible de chercher un service spécifique. L'exemple ci-dessous montre comment chercher le service OBEX Object Push (OPUSH): &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH Offrir des services sous &os; aux clients &bluetooth; se fait à l'aide du serveur &man.sdpd.8;: &prompt.root; sdpd L'application serveur locale qui désire offrir un service &bluetooth; à des clients distants enregistrera le service auprès du “daemon” SDP local. Un exemple d'une telle application est &man.rfcomm.pppd.8;. Une fois démarré, il enregistrera un service de réseau local &bluetooth; auprès du serveur SDP local. La liste des services enregistrés auprès du serveur SDP local peut être obtenue en émettant une requête de navigation (“browse”) SDP par l'intermédiaire du canal de contrôle: &prompt.root; sdpcontrol -l browse Les profils Dial-Up Networking (DUN) et accès au réseau local avec PPP (LAN) Le profil Dial-Up Networking (DUN) est principalement utilisé avec les modems et les téléphones portables. Les cas de figure couverts par ce profil sont les suivants: Utilisation d'un téléphone portable ou d'un modem par un ordinateur comme modem sans fil pour se connecter à un serveur d'accès Internet, ou pour l'utilisation de services accessibles par téléphone; Utilisation d'un téléphone portable ou d'un modem par un ordinateur pour recevoir des appels avec transmission de données. Le profil d'accès au réseau local avec PPP (LAN) peut être utilisé dans les situations suivantes: Accès au réseau local pour un périphérique &bluetooth;; Accès au réseau local pour plusieurs périphériques &bluetooth;; Liaison PC à PC (en utilisant le protocole PPP sur une émulation de câble série). Sous &os; les deux profils sont implémentés par &man.ppp.8; et &man.rfcomm.pppd.8;—un “wrapper” convertit la connexion &bluetooth; RFCOMM en quelque chose d'utilisable par PPP. Avant qu'un profil ne soit utilisable, un nouveau label doit être créé dans le fichier /etc/ppp/ppp.conf. Consultez la page de manuel &man.rfcomm.pppd.8; pour des exemples. Dans l'exemple suivant &man.rfcomm.pppd.8; sera employé pour ouvrir un connexion RFCOMM avec le périphérique distant avec une adresse BD_ADDR 00:80:37:29:19:a4 sur un canal DUN RFCOMM. Le numéro de canal RFCOMM réel sera obtenu du périphérique distant par l'intermédiaire de SDP. Il est possible de préciser le canal RFCOMM à la main, dans ce cas &man.rfcomm.pppd.8; n'émettra pas de requête SDP. Utilisez &man.sdpcontrol.8; pour trouver le canal RFCOMM sur le périphérique distant. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup Afin de fournir un service d'accès au réseau local avec PPP, le serveur &man.sdpd.8; doit être en fonctionnement. Une nouvelle entrée pour les clients du réseau local doit être créée dans le fichier /etc/ppp/ppp.conf. Consultez la page de manuel &man.rfcomm.pppd.8; pour des exemples. Enfin, lancez le serveur RFCOMM PPP sur un numéro de canal RFCOMM valide. Le serveur RFCOMM PPP enregistrera automatiquement un service &bluetooth; LAN auprès du “daemon” SDP local. L'exemple ci-dessous montre comment démarrer le serveur RFCOMM PPP: &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server OBEX Le profil OBEX Object Push (OPUSH) OBEX (échange d'objets) est un protocole très largement utilisé pour les tranferts de fichiers entre périphériques mobiles. Son utilisation principale se trouve dans les communications par infrarouge, où il est utilisé pour le tranfert des fichiers entre ordinateurs portables ou PDAs, et pour envoyer des cartes de visite électronique ou des éléments d'agenda entre téléphones portables et d'autres périphériques disposant d'applications de gestion d'informations personnelles (PIM). Le serveur et le client OBEX sont implémentés dans le logiciel tierce-partie obexapp, qui est disponible sous la forme du logiciel porté comms/obexapp. Le client OBEX est employé pour “pousser” et/ou “tirer” des objets du serveur OBEX. Un objet peut être, par exemple, une carte de visite ou un rendez-vous. Le client OBEX peut obtenir un numéro de canal RFCOMM d'un périphérique distant par l'intermédiaire de SDP. Cela peut être fait en spécifiant le nom du service plutôt que le numéro du canal RFCOMM. Les noms de service supportés sont: IrMC, FTRN et OPUSH. Il est possible de préciser le canal RFCOMM par un nombre. Un exemple de session OBEX est présenté ci-dessous, où l'objet information du périphérique d'un téléphone portable est récupéré, et un nouvel objet (carte de visite) est envoyé dans le répertoire du téléphone. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get get: remote file> telecom/devinfo.txt get: local file> devinfo-t39.txt Success, response: OK, Success (0x20) obex> put put: local file> new.vcf put: remote file> new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) Afin de fournir le service OBEX Object Push, le serveur &man.sdpd.8; doit tourner. Un dossier racine où tous les objets entrant seront stockés doit être créé. Le chemin d'accès par défaut du répertoire racine est /var/spool/obex. Le serveur OBEX enregistrera automatiquement le service OBEX Object Push auprès du “daemon” SDP local. L'exemple ci-dessous montre comment démarrer le serveur OBEX: &prompt.root; obexapp -s -C 10 Le profil port série (SPP) Le profil port série (SPP) permet aux périphériques &bluetooth; d'émuler un câble série RS232 (ou similaire). Ce profil traite avec les applications classiques en utilisant &bluetooth; comme un câble de remplacement, à travers une abstraction de port série virtuel. L'utilitaire &man.rfcomm.sppd.1; implémente le profil port série. Un pseudo terminal est utilisé comme abstraction de port série virtuel. L'exemple ci-dessous montre comment se connecter à un service port série d'un périphérique distant. Notez que vous n'avez pas besoin d'indiquer un canal RFCOMM — &man.rfcomm.sppd.1; peut l'obtenir auprès du périphérique distant via SDP. Si vous désirez forcer cela, spécifiez un canal RFCOMM sur la ligne de commande. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... Une fois connecté, le pseudo-terminal peut être utilisé comme un port série: &prompt.root; cu -l ttyp6 Dépannage Un périphérique distant ne peut pas se connecter Certains anciens périphériques &bluetooth; ne supportent pas de changement de rôle. Par défaut, quand &os; accepte une nouvelle connexion, il tente d'effectuer un changement de rôle et de devenir maître. Les périphériques qui ne supportent pas cela ne seront pas en mesure de se connecter. Notez qu'un changement de rôle est effectué quand une nouvelle connexion est établie, il n'est donc pas possible de demander au périphérique distant s'il supporte le changement de rôle. Il existe une option HCI pour désactiver le changement de rôle au niveau local: &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 Quelque chose ne va pas, puis-je voir ce qui se passe exactement? Bien sûr. Utilisez le logiciel tierce-partie hcidump-1.5 qui peut être téléchargé depuis . L'utilitaire hcidump est similaire à &man.tcpdump.1;. Il peut être utilisé pour afficher le contenu des paquets &bluetooth; à l'écran et les sauvegarder dans un fichier. Steve Peterson Ecrit par Bridging Introduction sous-réseau IP bridge/pont Il est parfois utile de diviser un réseau physique (comme un réseau Ethernet) en deux réseaux séparés sans avoir à créer de sous-réseaux IPs et à utiliser un routeur pour connecter ces réseaux entre eux. Le périphérique qui connecte ensemble deux réseaux de cette manière est appelé “bridge”—pont. Un système &os; avec deux cartes réseaux peut faire fonction de pont. Le pont apprend les adresses MAC (adresses Ethernet) des périphériques branchés sur chacune de ses interfaces réseaux. Il transmet le trafic entre deux réseaux uniquement quand la source et la destination sont sur des réseaux différents. Sous de nombreux aspects, un pont ressemble à un switch (commutateur) Ethernet avec très peu de ports. Situations où l'utilisation d'un pont est appropriée Il existe deux situations dans lesquelles un pont est de nos jours utilisé. Trafic important sur un segment La première situation apparaît quand un segment physique d'un réseau est submergé par le trafic, mais vous ne voulez pas, pour différentes raisons, subdiviser le réseau et interconnecter les sous-réseaux à l'aide d'un routeur. Prenons comme exemple un journal où les bureaux de la rédaction et de la production sont sur le même sous-réseau. Les utilisateurs de la rédaction utilisent tous le serveur de fichiers A, et les utilisateurs de la production le serveur B. Un réseau Ethernet est utilisé pour connecter ensemble les utilisateurs, et des surcharges du réseau ralentissent les échanges. Si les utilisateurs de la rédaction peuvent être cantonné sur un segment, et les utilisateurs de la production sur un autre, les deux réseaux pourront être connectés par un pont. Seul le trafic réseau destiné aux interfaces réseaux situées de l'“autre” côté du pont sera transmis à l'autre réseau, réduisant ainsi les congestions sur chaque segment. Coupe-feu filtrant/régulant le trafic coupe-feu translation d'adresses La deuxième situation est quand un coupe-feu est nécessaire mais sans translation d'adresses (NAT). Un exemple est une compagnie qui est connectée à son fournisseur d'accès internet par l'intermédiaire d'une connexion ISDN ou DSL. Elle dispose de 13 adresses IP routables fournies par le fournisseur d'accès et dispose de 10 PCs sur son réseau. Dans cette situation, utiliser un coupe-feu/routeur est complexe en raison des problèmes de sous-réseaux. routeur DSL ISDN Un coupe-feu basé sur un pont peut être configuré et positionné dans le flux juste en aval de leur routeur DSL/ISDN sans aucun problème d'adressage IP. Configuration d'un pont Choix des cartes réseaux Un pont nécessite au moins deux cartes réseaux pour fonctionner. Malheureusement toutes les cartes réseaux ne supportent pas le mode bridging. Lisez la page de manuel &man.bridge.4; pour des détails sur les cartes supportées. Installez et testez les deux cartes réseaux avant de poursuivre. Modification de la configuration du noyau options du noyau options BRIDGE Pour activer le support nécessaire pour mettre en place un pont ajouter la ligne suivante: options BRIDGE à votre fichier de configuration du noyau, et recompilez votre noyau. Support du coupe-feu coupe-feu Si vous projetez d'utiliser un pont en tant que coupe-feu, vous devrez également ajouter l'option IPFIREWALL. Lisez la pour des informations générales sur la configuration d'un pont en tant que coupe-feu. Si vous avez besoin de permettre le passage à travers le pont des paquets non-IP (comme ARP), il existe une option du coupe-feu qui doit être activée. Cette option est IPFIREWALL_DEFAULT_TO_ACCEPT. Prennez note que cela modifie le fonctionnement par défaut du coupe-feu, ce dernier acceptera alors tous les paquets. Assurez-vous de savoir ce que ce changement signifie pour votre ensemble de règles de filtrage avant de l'effectuer. Support de la régulation du trafic Si vous désirez utiliser le pont comme régulateur de trafic, vous devrez ajouter l'option DUMMYNET à votre fichier de configuration du noyau. Consultez la page de manuel &man.dummynet.4; pour plus d'information. Activer le pont Ajoutez la ligne: net.link.ether.bridge=1 au fichier /etc/sysctl.conf pour activer le pont au démarrage, et la ligne: net.link.ether.bridge_cfg=if1,if2 pour activer le mode bridging sur les interfaces spécifiées (remplacez if1 et if2 par les noms de vos interfaces réseaux). Si vous désirez que les paquets traversant le pont soient filtrés par &man.ipfw.8;, vous devrez ajouter également la ligne: net.link.ether.bridge_ipfw=1 Pour &os; 5.2-RELEASE et versions suivantes, utilisez les lignes suivantes: net.link.ether.bridge.enable=1 net.link.ether.bridge.config=if1,if2 net.link.ether.bridge.ipfw=1 Informations supplémentaires Si vous désirez être en mesure de vous connecter au pont par l'intermédiaire de &man.ssh.1;, il est correct d'ajouter à l'une des cartes réseaux une adresse IP. Il existe un consensus sur le fait qu'assigner une adresse aux deux cartes est une mauvaise idée. Si vous avez plusieurs ponts sur votre réseau, il ne peut y en avoir plus d'un sur le chemin qui sera emprunté par le trafic entre deux stations de travail. Techniquement, cela signifie qu'il n'y a pas de support pour la gestion du “spanning tree”. Un pont peut ajouter des temps de latence lors de l'utilisation de &man.ping.8;, et tout particulièrement dans le cas du trafic d'un segment vers un autre. Jean-François Dockès Mis à jour par Alex Dupre Réorganisé et augmenté par Système sans disque dur station de travail sans disque dur système sans disque dur Une machine &os; peut démarrer via le réseau et fonctionner sans disque dur local, en utilisant des systèmes de fichiers montés à partir d'un serveur NFS. Aucune modification du système n'est nécessaire en dehors des fichiers de configuration standards. Un tel système est facile à mettre en oeuvre comme tous les éléments sont directement disponibles: Il y a au moins deux métodes possibles pour charger un noyau via le réseau: PXE: l'environnement d'exécution préalable au démarrage d'&intel; (Preboot eXecution Environment) est une sorte de ROM intelligente présente sur certaines cartes réseau ou cartes mère. Consultez la page de manuel &man.pxeboot.8; pour plus de détails. Le logiciel porté Etherboot (net/etherboot) produit un code stockable dans une ROM pour démarrer des noyaux via le réseau. Le code peut être soit implanté dans une PROM de démarrage sur une carte réseau, soit chargé à partir d'une disquette (ou d'un disque dur local), ou à partir d'un système &ms-dos; en fonctionnement. De nombreuses cartes réseau sont supportées. Une procédure d'exemple (/usr/share/examples/diskless/clone_root) facilite la création et la maintenance du système de fichiers racine de la station de travail sur le serveur. La procédure demandera sûrement quelques modifications mais vous permettra de démarrer rapidement. Des fichiers de démarrage du système existent dans le répertoire /etc pour détecter et supporter le démarrage d'un système sans disque dur. La pagination, si nécessaire, peut être faite par l'intermédiaire d'un fichier NFS ou sur un disque local. Il existe plusieurs façons de configurer des stations de travail sans disque dur. Plusieurs éléments entrent en oeuvre, et la plupart peuvent être ajustés en fonction des besoins locaux. Ce qui suit décrit des variations sur la configuration d'un système complet, mettant en avant le simplicité et la compatibilité avec les procédures standards de démarrage de &os;. Le système décrit présente les caractéristiques suivantes: Les stations de travail sans disque dur utilisent des systèmes de fichiers / et /usr partagés et en lecture seule. Le système de fichiers racine est une copie d'une racine &os; standard (généralement celle du serveur), avec certains fichiers de configuration remplacés par des versions spécifiques à un fonctionnement sans disque dur, et parfois à la station de travail auxquels ils appartiennent. Les parties de la racine qui doivent être inscriptibles sont remplacées par des systèmes de fichiers &man.mfs.8; (&os; 4.X) ou &man.md.4; (&os; 5.X). Toute modification sera perdue au redémarrage du système. Le noyau est transféré et chargé soit à l'aide d'Etherboot soit de PXE comme certaines situations peuvent exiger l'utilisation de l'une ou l'autre méthode. Ainsi décrit, le système n'est pas sécurisé. Il devrait se trouver dans une partie protégée du réseau, et les autres machines ne devraient pas lui faire confiance aveuglément. Toutes les instructions de cette section ont été testées sous &os; 4.9-RELEASE et 5.2.1-RELEASE. Le texte est destiné à l'origine pour une utilisation sous 4.X. Des notes on été insérées aux endroits nécessaires pour indiquer les modifications concernant la branche 5.X. Information de fond Mettre en place des stations de travail sans disque dur est à la fois relativement simple et enclin aux erreurs. Ces dernières sont parfois difficiles à diagnostiquer pour de nombreuses raisons. Par exemple: Des options de compilation peuvent donner lieu à des comportements différents à l'exécution. Les messages d'erreurs sont souvent cachés ou totalement absents. Dans ce contexte, avoir quelques connaissances des mécanismes sousjacents impliqués est très utile pour résoudre les problèmes qui peuvent surgir. Plusieurs opérations doivent être effectutées pour un amorçage réussi: La machine doit obtenir des paramètres de base comme son adresse IP, le nom du fichier exécutable, le nom du serveur, l'emplacement de la racine. Ceci est fait en utilisant le protocole DHCP ou le protocole BOOTP. DHCP est une extension compatible de BOOTP, et utilise les mêmes numéros de ports et son format de paquets basic. Il est possible de configurer un système pour n'utiliser que BOOTP. Le programme serveur &man.bootpd.8; fait partie du système de base de &os;. Cependant, DHCP présente plusieurs avantage sur BOOTP (des fichiers de configuration plus lisibles, la possibilité d'utiliser PXE, plus de nombreux autres avantages n'ayant pas de relation directe avec les systèmes sans disque dur), et nous décrirons principalement une configuration DHCP, avec des exemples équivalent utilisant &man.bootpd.8; quand cela est possible. L'exemple de configuration utilisera le logiciel ISC DHCP (la version 3.0.1.r12 était installée sur le serveur de test). La machine a besoin de transférer un ou plusieurs programmes en mémoire locale. TFTP ou NFS sont utilisés. Le choix entre TFTP et NFS est à de nombreux endroits une option sélectionnée lors de la compilation. Une source d'erreur courante est d'indiquer des noms de fichiers pour le mauvais protocole: TFTP transfère généralement tous les fichiers à partir d'un seul répertoire sur le serveur, et attendra des noms de fichiers relatifs à ce répertoire. NFS a besoin de chemins d'accès absolus. Les éventuels programmes d'amorce intermédiaires et le noyau doivent être initialisés et exécutés. Il existe plusieurs variations à ce niveau: PXE chargera &man.pxeboot.8;, qui est une version modifiée du chargeur. Le chargeur (&man.loader.8;) récupérera la plupart des paramètres nécessaires au démarrage du système, et les transmettra au noyau avant de lui abandonner le contrôle du système. Dans ce cas il est possible d'utiliser un noyau GENERIC. Etherboot, chargera directement le noyau avec moins de préparation. Vous devrez compiler un noyau avec des options particulières. PXE et Etherboot fonctionnent aussi bien l'un que l'autre avec des systèmes 4.X. Comme le noyau des systèmes 5.X laisse au chargeur (&man.loader.8;) un peu plus de travail à effectuer, PXE est préféré pour les systèmes 5.X. Si votre BIOS et vos cartes réseau supportent PXE, vous devriez probablement l'utiliser. Cependant, il est toujours possible de démarrer un système 5.X à l'aide d'Etherboot. Et enfin, la machine a besoin d'accéder à ses systèmes de fichiers. NFS est utilisé dans tous les cas. Consultez également la page de manuel &man.diskless.8;. Configuration Configuration utilisant <application>ISC DHCP</application> DHCP système sans disque dur Le serveur ISC DHCP peut répondre aux requêtes BOOTP et DHCP. Avec la version 4.9, ISC DHCP 3.0 ne fait pas partie du système de base. Vous devrez installer le logiciel porté net/isc-dhcp3-server ou la version pré-compilée correspondante. Une fois ISC DHCP installé, il nécessite un fichier de configuration pour fonctionner (normalement appelé /usr/local/etc/dhcpd.conf). Voici un exemple commenté, où la machine margaux utilise Etherboot et où la machine corbieres emploie PXE: default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "example.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; host margaux { hardware ethernet 01:23:45:67:89:ab; fixed-address margaux.example.com; next-server 192.168.4.4; filename "/data/misc/kernel.diskless"; option root-path "192.168.4.4:/data/misc/diskless"; } host corbieres { hardware ethernet 00:02:b3:27:62:df; fixed-address corbieres.example.com; next-server 192.168.4.4; filename "pxeboot"; option root-path "192.168.4.4:/data/misc/diskless"; } } Cette option dit à dhcpd d'envoyer le paramètre des déclarations host comme nom de machine pour la machine sans disque dur. Une autre méthode aurait été d'ajouter option host-name margaux à l'intérieur des déclarations host. La directive next-server désigne le serveur TFTP ou NFS à utiliser pour télécharger le chargeur ou le noyau (le comportement par défaut étant d'utiliser la même machine que le serveur DHCP). La directive filename précise le fichier que chargera Etherboot ou PXE à la prochaine étape. Il doit être défini en fonction de la méthode de transfert utilisée. Etherboot peut être compilé pour utiliser NFS ou TFTP. Le logiciel porté pour &os; utilisera NFS par défaut. PXE emploie TFTP, c'est pourquoi un chemin d'accès relatif est utilisé ici (cela peut dépendre de la configuration du serveur TFTP, mais devrait être plutôt classique). De plus, PXE charge pxeboot, et non pas le noyau. Il existe d'autres possibilités intéressantes, comme le chargement de pxeboot à partir du répertoire /boot d'un CD-ROM &os; (comme &man.pxeboot.8; peut charger un noyau GENERIC cela rend possible l'utilisation de PXE pour démarrer à partir d'un lecteur de CD-ROM distant). L'option root-path définie le chemin d'accès au système de fichiers racine, suivant la notation classique de NFS. En utilisant PXE, il est possible de ne pas préciser l'adresse IP de la machine dès lors que vous n'activez pas l'option BOOTP du noyau. Le serveur NFS sera alors le même que le serveur TFTP. Configuration utilisant BOOTP BOOTP système sans disque dur Ce qui suit présente une configuration bootpd équivalente (réduite à un seul client). Elle se trouverait sous /etc/bootptab. Veuillez noter qu'Etherboot doit être compilé avec l'option NO_DHCP_SUPPORT (qui n'est pas activée par défaut) afin d'utiliser BOOTP et que PXE nécessite DHCP. The seul avantage évident de bootpd est qu'il est disponible dans le système de base. .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ :ds=192.168.4.1:\ :gw=192.168.4.1:\ :hd="/tftpboot":\ :bf="/kernel.diskless":\ :rp="192.168.4.4:/data/misc/diskless": margaux:ha=0123456789ab:tc=.def100 Préparation d'un programme de démarrage avec <application>Etherboot</application> Etherboot Le site Web d'Etherboot propose une documentation importante principalement destinée aux systèmes Linux, mais contenant néamoins des informations utiles. Ce qui suit présente comment vous utiliseriez Etherboot sur un système &os;. Vous devez tout d'abord installer le logiciel porté net/etherboot ou sa version pré-compilée. Vous pouvez modifier la configuration d'Etherboot (i.e. pour utiliser TFTP au lieu de NFS) en éditant le fichier Config dans le répertoire des sources d'Etherboot. Pour notre configuration nous utiliserons une disquette de démarrage. Pour d'autres méthodes (PROM, ou un programme &ms-dos;), consultez la documentation d'Etherboot. Pour créer une disquette de démarrage, insérez une disquette dans le lecteur de la machine où vous avez installé Etherboot, puis rendez-vous dans le répertoire src de l'arborescence Etherboot et tapez: &prompt.root; gmake bin32/devicetype.fd0 devicetype dépend du type de carte Ethernet se trouvant dans la station de travail sans disque dur. Référez-vous au fichier NIC dans le même répertoire pour déterminer la valeur devicetype correcte. Démarrer avec <acronym>PXE</acronym> Par défaut le chargeur &man.pxeboot.8; charge le noyau via NFS. Il peut être compilé pour utiliser TFTP à la place en spécifiant l'option LOADER_TFTP_SUPPORT dans le fichier /etc/make.conf. Lisez les commentaires dans le fichier /etc/defaults/make.conf (ou /usr/share/examples/etc/make.conf pour les systèmes 5.X) pour plus de détails. Il existe deux autres options de make.conf non-documentées qui peuvent être utiles pour la configuration d'une machine faisant fonction de console série sans disque dur: BOOT_PXELDR_PROBE_KEYBOARD, et BOOT_PXELDR_ALWAYS_SERIAL (cette dernière n'existe que sous &os; 5.X). Pour utiliser PXE quand la machine démarre, vous aurez normalement besoin de sélectionner l'option Boot from network dans votre BIOS, ou d'appuyer sur une touche de fonction lors de l'initialisation du PC. Configuration des serveurs <acronym>TFTP</acronym> et <acronym>NFS</acronym> TFTP système sans disque dur NFS système sans disque dur Si vous utilisez PXE ou Etherboot configurés pour employer TFTP, vous devez activer tftpd sur le serveur de fichier: Créez un répertoire à partir duquel tftpd proposera les fichiers, e.g. /tftpboot. Ajoutez la ligne suivante à votre fichier /etc/inetd.conf: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot Il apparaît que certaines versions de PXE veulent la version TCP de TFTP. Dans ce cas, ajoutez une seconde ligne, en remplaçant dgram udp par stream tcp. Demandez à inetd de relire son fichier de configuration: &prompt.root; kill -HUP `cat /var/run/inetd.pid` Le répertoire tftpboot peut être placé n'importe où sur le serveur. Assurez-vous que son emplacement est défini dans les fichiers inetd.conf et dhcpd.conf. Dans tous les cas, vous devez également activer NFS et exporter le système de fichiers approprié sur le serveur NFS. Ajoutez ce qui suit au fichier /etc/rc.conf: nfs_server_enable="YES" Exportez le système de fichiers contenant le répertoire racine du système sans disque dur en ajoutant ce qui suit au fichier /etc/exports (ajustez le point de montage et remplacez margaux corbieres avec les noms des stations de travail sans disque dur): /data/misc -alldirs -ro margaux corbieres Demandez à mountd de relire son fichier de configuration. Si vous avez eu besoin d'activer NFS dans /etc/rc.conf lors du premier point, vous voudrez probablement plutot redémarrer la machine. &prompt.root; kill -HUP `cat /var/run/mountd.pid` Compilation d'un noyau pour système sans disque dur système sans disque dur configuration du noyau Si vous utilisez Etherboot, vous devez créer un fichier de configuration du noyau pour le client sans disque dur avec les options suivantes (en plus des options habituelles): options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info Vous pouvez vouloir également employer les options BOOTP_NFSV3, BOOT_COMPAT et BOOTP_WIRED_TO (réferez-vous au fichier LINT sous 4.X ou NOTES sous 5.X). Les noms de ces options sont historiques et légèrement trompeur comme elles activent indifférement l'utilisation de DHCP et BOOTP dans le noyau (il est également possible de forcer une utilisation stricte de BOOTP ou DHCP). Compilez le noyau (voir ), et copiez-le à l'emplacement indiqué dans dhcpd.conf. Quand on utilise PXE, la compilation d'un noyau avec les options précédentes n'est pas strictement nécessaire (bien que conseillé). Les activer causera un plus grand nombre de requêtes DHCP générées lors du démarrage du noyau, avec un petit risque d'inconsistence entre les nouvelles valeurs et celles récupérées par &man.pxeboot.8; dans certains cas particuliers. L'avantage de leur utilisation est que le nom de la machine sera forcément défini. Sinon vous devrez définir le nom de la machine par une autre méthode, par exemple dans un fichier rc.conf particulier au client. Afin d'être chargeable par Etherboot, un noyau 5.X doit être compilé avec les “device hints”. Vous définirez normalement l'option suivante dans le fichier de configuration (voir le fichier de commentaires sur la configuration: NOTES): hints "GENERIC.hints" Préparer le système de fichiers racine système de fichiers racine système sans disque dur Vous devez créer un système de fichiers racine pour les stations de travail sans disque dur, à l'emplacement défini par root-path dans le fichier dhcpd.conf. Les sections suivantes décrivent deux manières de le faire. Utilisation de la procédure <filename>clone_root</filename> C'est la méthode la plus rapide pour créer un système de fichiers racine, mais elle est, pour le moment, uniquement supportée sous &os; 4.X.. Cette procédure est située à l'emplacement /usr/share/examples/diskless/clone_root et demande quelques modifications, pour au moins ajuster l'emplacement du système de fichiers à créer (la variable DEST). Référez-vous aux commentaires situés en début de la procédure pour information. Ils expliquent comment le système de fichiers de base est construit, et comment les fichiers peuvent être remplacés de façon sélective par des versions spécifiques à un fonctionnement sans disque dur, ou à un sous-réseau, ou encore à une station de travail particulière. Ils donnent également des exemples de fichiers /etc/fstab et /etc/rc.conf pour un fonctionnement sans disque dur. Les fichiers README dans le répertoire /usr/share/examples/diskless contiennent beaucoup d'information de fond, mais, avec les autres exemples du répertoire diskless, ils documentent une méthode de configuration qui est distincte de celle utilisée par clone_root et les procédures de démarrage du système de /etc, ce qui est un peu à l'origine de confusions. Utilisez-les comme référence uniquement, à moins que vous préfériez la méthode qu'ils décrivent, dans quel cas vous devrez modifier les procédures rc. Utilisation de la procédure <command>make world</command> standard Cette méthode s'applique aussi bien à &os; 4.X qu'à &os; 5.X et installera un système complet (et non pas uniquement le système de fichiers racine) dans le répertoire défini par DESTDIR. Tout ce dont vous avez besoin de faire est d'exécuter la procédure suivante: #!/bin/sh export DESTDIR=/data/misc/diskless mkdir -p ${DESTDIR} cd /usr/src; make world && make kernel cd /usr/src/etc; make distribution Une fois cela terminé, vous devrez personaliser vos fichiers /etc/rc.conf et /etc/fstab situés dans DESTDIR en fonction de vos besoins. Configuration de l'espace de pagination Si nécessaire, un fichier de pagination situé sur le serveur peut être utilisé via NFS. Une des méthodes couramment utilisées pour cela n'est plus supportée sous 5.X. Pagination via <acronym>NFS</acronym> sous &os; 4.X L'emplacement et la taille du fichier de pagination peuvent être spécifiés avec les options BOOTP/DHCP 128 et 129 spécifiques à &os;. Des exemples de fichiers de configuration pour ISC DHCP 3.0 ou bootpd suivent: Ajoutez les lignes suivantes au fichier dhcpd.conf: # Global section option swap-path code 128 = string; option swap-size code 129 = integer 32; host margaux { ... # Standard lines, see above option swap-path "192.168.4.4:/netswapvolume/netswap"; option swap-size 64000; } swap-path est le chemin d'accès vers un répertoire où les fichiers de pagination sont situés. Chaque fichier sera nommé swap.ip-client. Les anciennes version de dhcpd utilisaient une syntaxe du type option option-128 "..., qui n'est plus supportée. /etc/bootptab utiliserait la syntaxe suivante à la place: T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00 Dans le fichier /etc/bootptab, la taille de l'espace de pagination doit être exprimée en hexadécimal. Sur le serveur du fichier de pagination par NFS, créez le(s) fichier(s) de pagination: &prompt.root; mkdir /netswapvolume/netswap &prompt.root; cd /netswapvolume/netswap &prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 &prompt.root; chmod 0600 swap.192.168.4.6 192.168.4.6 est l'adresse IP du client sans disque dur. Sur le serveur du fichier de pagination par NFS, ajoutez la ligne suivante au fichier /etc/exports: /netswapvolume -maproot=0:10 -alldirs margaux corbieres Ensuite demandez à mountd à relire le fichier exports, comme plus haut. Pagination via <acronym>NFS</acronym> sous &os 5.X Le noyau ne supporte pas l'activation de la pagination par NFS au démarrage. L'espace de pagination doit être activé par les procédures de démarrage, en montant un système de fichiers accessible en écriture et en créant et en activant un fichier de pagination. Pour créer un fichier de pagination de la taille appropriée, vous pouvez effectuer ce qui suit: &prompt.root; dd if=/dev/zero of=/path/to/swapfile bs=1k count=1 oseek=100000 Pour ensuite l'activer, vous devez ajouter la ligne suivante à votre fichier rc.conf: swapfile=/path/to/swapfile Problèmes divers Utilisation d'un <filename>/usr</filename> en lecture seule système sans disque dur /usr en lecture seule Si la station de travail sans disque dur est configurée pour exécuter X, you devrez ajuster le fichier de configuration de XDM, qui envoie le journal d'erreurs sur /usr par défaut. Utilisation d'un serveur non-&os; Quand le serveur pour le système de fichiers racine ne fait pas tourner &os;, vous devrez créer le système de fichiers racine sur une machine &os;, puis le copier vers sa destination en utilisant tar ou cpio. Dans cette situation, il y a parfois des problèmes avec les fichiers spéciaux de périphériques dans /dev, en raison de différences de taille sur les entiers. Une solution à ce problème est d'exporter un répertoire à partir du serveur non-&os;, de monter ce répertoire sur une machine &os;, et exécuter MAKEDEV sur la machine &os; pour créer les entrées de périphériques correctes (&os; 5.X et les versions suivantes utilisent &man.devfs.5; pour l'allocation des fichiers spéciaux de périphériques de manière transparente pour l'utilisateur, exécuter MAKEDEV sur ces versions est inutile). ISDN ISDN—(RNIS) Une bonne source d'information sur la technologie et le matériel ISDN (RNIS) est la page ISDN de Dan Kegel. Voici un rapide aperçu à propos de l'ISDN: Si vous résidez en Europe, vous devriez étudier la section sur les cartes ISDN. Si vous envisagez d'utiliser l'ISDN avant tout pour vous connecter à l'Internet par l'intermédiaire d'un fournisseur d'accès Internet et d'une ligne téléphoniaue non dédiée, vous devriez vous intéresser aux Adaptateurs Terminaux. C'est la solution la plus souple, qui vous posera le moins de problèmes si vous changez de fournisseur d'accès. Si vous interconnectez deux réseaux locaux, ou si vous vous connectez à l'Internet avec une liaison ISDN dédieé, vous devriez envisager un pont/routeur autonome. Le coût est un facteur déterminant de la solution que vous choisirez. Les options suivantes sont listées de la moins chère à la plus chère. Hellmuth Michaelis Contribution de Cartes ISDN ISDN cartes L'implémentation ISDN de &os; ne supporte que la norme DSS1/Q.931 (ou Euro-ISDN) utilisant des cartes passives. Depuis &os; 4.4, quelques cartes actives sont supportées où le firmware supporte également d'autres protocoles au niveau des signaux, cela inclut les premières cartes supportées du type “Primary Rate ISDN” (PRI). Le logiciel isdn4bsd vous permet de vous connecter à d'autres routeurs ISDN soit en utilisant l'IP sur de l'HDLC de base, soit en utilisant PPP synchrone: en employant PPP intégré au noyau avec isppp, une version modifiée du pilote de périphérique &man.sppp.4;, ou en employant &man.ppp.8; en mode utilisateur. L'utilisation de &man.ppp.8; en mode utilisateur rend possible l'agrégation de deux ou plus canaux ISDN de type B. Une application capable de répondre aux appels téléphoniques est également disponible, tout comme de nombreux utilitaires comme un modem logiciel 300 bauds. Un nombre croissant de cartes ISDN pour PC sont supportées sous &os; et les retours montrent qu'elles sont utilisées avec succès dans toute l'Europe et dans de nombreuses autres parties du monde. Les cartes ISDN passives supportées sont principalement celles avec le circuit ISDN ISAC/HSCX/IPAC d'Infineon (précédemment Siemens), mais également les cartes avec des circuits en provenance de Cologne Chip (cartes ISA uniquement), les cartes PCI avec les circuits Winbond W6692, quelques cartes avec les circuits Tiger300/320/ISAC et quelques cartes avec des circuits spécifiques comme l'AVM Fritz!Card PCI V.1.0 de l'AVM Fritz!Card PnP. Actuellement les cartes ISDN actives supportées sont les cartes AVM B1 (ISA et PCI) BRI et les cartes PCI AVM T1 PRI. Pour de la documentation sur isdn4bsd, consultez le répertoire /usr/share/examples/isdn/ sur votre système &os; ou sur la page web d'isdn4bsd qui propose également des astuces, des erratas et bien plus de documentation que le manuel d'isdn4bsd. Au cas où vous seriez intéressé par l'ajout du support pour un protocole ISDN différent, d'une carte ISDN pour PC non encore supportée ou par l'amélioration d'isdn4bsd, veuillez contacter &a.hm;. Pour les questions concernant l'installation, la configuration et le dépannage d'isdn4bsd, une liste de diffusion &a.isdn.name; est disponible. Adaptateurs terminaux ISDN Les adaptateurs terminaux—“Terminal adapters (TA)”; sont l'équivalent ISDN des modems pour les lignes téléphoniques ordinaires. modem La plupart des TA utilisent le jeu de commandes standard des modems Hayes, et peuvent être utilisés en remplacement d'un modem. Un TA fonctionne essentiellement de la même manière qu'un modem à la différence que la vitesse de la connexion sera plus élevée qu'avec votre vieux modem. Vous devrez configurer PPP de façon exactement identique que pour un modem classique. Assurez-vous de fixer la vitesse de votre port série la plus haute possible. PPP Le principal avantage d'utiliser un TA pour vous connecter à votre fournisseur d'accès Internet est de pouvoir utiliser PPP en mode dynamic. Comme l'espace d'adressage IP disponible devient de plus en plus restreint, la plupart des fournisseurs d'accès ne désirent plus vous fournir d'adresse IP statique. La plupart des routeurs autonomes ne peuvent pas fonctionner avec une allocation dynamique d'adresse IP. Les fonctionnalités et la stabilité de la connexion des adaptateurs terminaux reposent complètement sur le “daemon” PPP. Cela vous permet de passer facilement d'un modem classique à l'ISDN sur une machine &os;, si vous avez déjà configuré PPP. Cependant, les problèmes que vous avez éventuellement rencontrés avec PPP persisteront. Si vous désirez un maximum de stabilité, utilisez PPP intégré au noyau, à la place du PPP en mode utilisateur. Les adaptateurs suivants sont connus pour fonctionner avec &os;: Motorola BitSurfer et Bitsurfer Pro Adtran La plupart des adaptateurs terminaux fonctionneront probablement également, les fabricants de TA font en sorte que leurs produits acceptent la plupart du jeu de commandes AT des modems. Le vrai problème avec les adaptateurs terminaux est que comme pour les modems, il vous faudra une bonne interface série dans votre ordinateur. Vous devriez lire le document sur les ports série sous &os; pour comprendre en détail le fonctionnement des périphériques série et les différences entre les ports séries asynchrones et synchrones. Un adaptateur terminal sur un port série PC standard (asynchrone) vous limite à 115.2 Kbs, même si vous disposez d'une connexion à 128 Kbs. Pour utiliser complètement les 128 Kbs offert par l'ISDN, vous devez brancher l'adaptateur sur une carte série synchrone. Ne vous imaginez pas qu'il suffit d'acheter un adaptateur terminal interne pour s'affranchir du problème synchrone/asynchrone. Les adaptateurs internes disposent simplement d'un port série PC standard. Tout ce que vous y gagnerez sera d'économiser un câble série et de libérer une prise électrique. Une carte synchrone avec un adaptateur terminal est au moins aussi rapide qu'un routeur autonome, piloté par une simple machine &os;, et probablement plus souple. Le choix entre carte synchrone/adaptateur ou routeur autonome est une question de goût. Ce sujet a été aborbé dans les listes de diffusion. Nous vous suggerons de chercher dans les archives pour obtenir l'intégralité de la discussion. Ponts/Routeurs ISDN autonomes ISDN ponts/routeurs autonomes Les ponts ou routeurs ISDN ne sont pas spécifiques à &os; ou à tout autre système d'exploitation. Pour une description complète de la technologie du routage et des ponts, veuillez vous reportez à un ouvrage de référence sur les réseaux. Dans le contexte de cette section, les termes de routeur et de pont seront utilisés indifféremment. Comme le prix des routeurs/ponts ISDN d'entrée de gamme baissent, il est probable qu'ils deviennent un choix de plus en plus populaire. Un routeur ISDN est une petite boîte qui se branche directement sur votre réseau Ethernet, et gère sa propre connexion aux autres ponts/routeurs. Il intègre le logiciel nécessaire au support du protocole PPP et d'autres protocoles. Un routeur vous offrira un débit plus élevé qu'un adaptateur terminal standard, puisqu'il utilisera une connexion ISDN synchrone. Le principal problème avec les routeurs et ponts ISDN est que l'intéropérabilité entre les matériels des différents contructeurs n'est pas toujours garantie. Si vous projetez de vous connecter à un fournisseur d'accès Internet, vous devriez discuter de vos besoins avec ce dernier. Si vous envisagez de connecter ensemble deux réseaux locaux, comme le réseau de votre domicile et celui de votre bureau, c'est la solution la plus simple et celle qui demande le moins de maintenance. Etant donné que vous êtes la personne qui achète les équipements pour les deux extrémités, vous êtes sûr que cela fonctionnera. Par exemple pour connecter un ordinateur personnel situé à son domicile ou le réseau d'une agence à celui du siège social, la configuration suivante pourra être utilisée: Réseau d'agence ou à domicile 10 base 2 Le réseau utilise une topologie en bus avec une connectique Ethernet 10 base 2 (“thinnet”). Connectez le routeur au réseau à l'aide d'un émetteur/récepteur AUI/10BT si nécessaire. ---Station de travail Sun | ---Machine FreeBSD | ---Windows 95 | Routeur autonome | Liaison ISDN BRI Ethernet 10 Base 2 Si votre réseau de domicile/d'agence n'est constitué que d'un seul ordinateur, vous pouvez utiliser une paire torsadée croisée pour le connecter directement au routeur autonome. Siège social ou autre réseau 10 base T Le réseau utilise une topologie en étoile avec une connectique Ethernet 10 base T (“paire torsadée”). -------Serveur Novell | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | |___---Routeur autonome | Liaison ISDN BRI Architecture du Réseau ISDN Un des principaux avantages de la plupart des routeurs/ponts est le fait qu'ils permettent d'avoir deux connexions PPP séparées et indépendantes vers deux sites différents et cela en même temps. Ceci n'est pas supporté par la plupart des adaptateurs terminaux, en dehors de modèles spécifiques (en général coûteux) qui disposent de deux ports série. Ne confondez pas cette possibilité avec l'agrégation de canaux, MPP, etc. Ceci peut être une fonctionnalité très utile si, par exemple, vous disposez d'une connexion ISDN dédiée au bureau et vous voudriez en profiter mais vous ne voulez pas acquérir une nouvelle ligne ISDN. Un routeur au bureau peut gérer un canal B dédié (64 Kbps) vers l'Internet et utiliser l'autre canal B pour une autre connexion. Le deuxième canal B peut être utilisé pour les connexions entrantes, sortantes ou pour l'agrégation de canaux (MPP, etc.) avec le premier canal B pour augmenter la bande passante. IPX/SPX Un pont Ethernet vous permettra de transmettre autre chose que juste du trafic IP. Vous pouvez également faire passer de l'IPX/SPX ou tout autre protocole que vous utilisez. Chern Lee Contribution de Translation d'adresses Généralités natd Le “daemon” de translation d'adresses (“Network Address Translation”—NAT) de &os;, généralement connu sous le nom de &man.natd.8; est un “daemon” qui accepte les paquets IP entrants, change l'adresse de la source par celle de la machine locale et ré-injecte les paquets dans le flux sortant des paquets IP. Le programme &man.natd.8; effectue cela en changeant l'adresse IP et le port source de sorte quand les données réponse arrivent il soit en mesure de déterminer la provenance des données d'origine et les transférer à l'émetteur original. Partage de connexion Internet IP masquerading L'utilisation classique de NAT est le partage de connexion Internet. Architecture du réseau En raison de la diminution du nombre d'adresses IP libres sous IPv4, et de l'augmentation du nombre d'utilisateurs de lignes haut-débit comme le câble ou l'ADSL, le besoin d'utiliser une solution de partage de connexion est donc en constante augmentation. La possibilité de connecter plusieurs ordinateurs par l'intermédiaire d'une connexion et d'une adresse IP fait de &man.natd.8; une solution de choix. Plus généralement, un utilisateur dispose d'une machine connecté sur la câble ou une ligne ADSL avec une adresse IP et désire utiliser cet ordinateur connecté pour fournir un accès Internet à d'autres machines du réseau local. Pour cela, la machine &os; sur Internet doit jouer le rôle de passerelle. Cette machine passerelle doit avoir deux cartes réseaux—l'une pour se connecter au routeur Internet, l'autre est connectée au réseau local. Toutes les machines du réseau local sont connectées par l'intermédiaire d'un hub ou d'un switch. _______ __________ _________ | | | | | | | Hub |-----| Client B |-----| Routeur |----- Internet |_______| |__________| |_________| | ____|_____ | | | Client A | |__________| Organisation du réseau Une telle configuration est communément utilisée pour partager une connexion Internet. Une des machines du réseau local est connectée à Internet. Le reste des machines accède à Internet par l'intermédiaire de cette machine “passerelle”. noyau configuration Configuration Les options suivantes doivent être présentes dans le fichier de configuration du noyau: options IPFIREWALL options IPDIVERT De plus, les options suivantes peuvent également être utiles: options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE Ce qui suit doit figurer dans le fichier /etc/rc.conf: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" Configure la machine comme passerelle. Exécuter sysctl net.inet.ip.forwarding=1 aurait le même effet. Active au démarrage les règles du coupe-feu se trouvant dans le fichier /etc/rc.firewall. Cela spécifie un ensemble de règles prédéfinies pour le coupe-feu qui autorise tous les paquets entrant. Consultez le fichier /etc/rc.firewall pour d'autres ensembles de régles. Indique à travers quelle interface transférer les paquets (l'interface connectée à l'Internet). Toutes options de configuration supplémentaires passées à &man.natd.8; au démarrage. Le fait d'avoir les options précédentes définies dans le fichier /etc/rc.conf lancera la commande /etc/rc.conf au démarrage. Cette commande peut être également exécutée à la main. Il est également possible d'utiliser un fichier de configuration pour &man.natd.8; quand il y a trop d'options à passer. Dans ce cas, le fichier de configuration doit être défini en ajoutant la ligne suivante au fichier /etc/rc.conf: natd_flags="-f /etc/natd.conf" Le fichier /etc/natd.conf contiendra une liste d'options de configuration, une par ligne. Par exemple le cas de figure de la section suivante utiliserait le fichier suivant: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 Pour plus d'information concernant le fichier de configuration, consultez la page de manuel de &man.natd.8; au sujet de l'option . A chaque machine et interface derrière le réseau local doit être assigné une adresse IP de l'espace d'adresses privées comme défini par la RFC 1918 et doit disposer d'une passerelle par défaut qui est l'adresse IP interne de la machine &man.natd.8;. Par exemple, les clients A et B du réseau local ont les adresses IP 192.168.0.2 et 192.168.0.3, tandis que l'interface sur le réseau local de la machine natd a pour adresse IP 192.168.0.1. La passerelle par défaut des clients A et B doit être l'adresse 192.168.0.1 de la machine natd. L'interface externe ou Internet de cette dernière ne demande aucune modification spécifique pour que &man.natd.8; puisse fonctionner. Redirection de ports L'inconvénient avec &man.natd.8; est que les clients du réseau local ne sont pas accessibles depuis l'Internet. Les clients sur le réseau local peuvent établir des connexions sortantes vers le monde extérieur mais ne peuvent recevoir de connexions entrantes. Cela présente un problème si l'on tente de faire tourner des services Internet sur une des machines du réseau local. Une solution simple à ce problème est de rediriger les ports Internet sélectionnés de la machine natd vers le client sur le réseau local. Par exemple, un serveur IRC tourne sur le client A, et un serveur web sur le client B. Pour que cela fonctionne correctement, les connections reçues sur les ports 6667 (IRC) et 80 (web) doivent être redirigées vers les machines correspondantes. L'option doit être passée à &man.natd.8; avec les autres options adéquates. La syntaxe est la suivante: -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] Dans l'exemple précédent, l'argument passé à la commande devrait être: -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 Cela va rediriger les ports tcp voulus vers les machines du réseau local. L'option peut être utilisée pour indiquer une plage de ports plutôt que des ports individuels. Par exemple tcp 192.168.0.2:2000-3000 2000-3000 redirigerait toutes les connexions reçues sur les ports 2000 à 3000 vers les ports 2000 à 3000 du client A. Ces options peuvent être utilisées quand on exécute directement &man.natd.8;, placées dans l'option natd_flags="" du fichier /etc/rc.conf, ou passées par l'intermédiaire d'un fichier de configuration. Pour plus d'éléments et d'options de configuration consultez la page de manuel &man.natd.8; Redirection d'adresses redirection d'adresses La redirection d'adresses est utile si plusieurs adresses IP sont disponibles mais doivent se trouver sur une seule machine. Avec cela, &man.natd.8; peut assigner à chaque client du réseau local sa propre adresse IP externe. Le programme &man.natd.8; récrit alors les paquets sortant des clients du réseau local avec l'adresse IP externe correcte et redirige tout le trafic entrant sur une adresse IP particulière vers la machine du réseau local correspondante. Ce principe est également connu sous le nom de translation d'adresses statique. Par exemple, les adresses IP 128.1.1.1, 128.1.1.2, et 128.1.1.3 appartiennent à la passerelle natd. L'adresse 128.1.1.1 peut être utilisée comme adresse IP externe de la passerelle natd, tandis que 128.1.1.2 et 128.1.1.3 sont redirigées vers les machines A et B du réseau local. La syntaxe de l'option est la suivante: -redirect_address localIP publicIP - + localIP L'adresse IP interne du client sur le réseau local. publicIP L'adresse IP externe correspondant au client sur le réseau local. Dans l'exemple, les arguments passés à la commande seraient: -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 Comme pour l'option , ces options peuvent être placées dans l'option natd_flags="" du fichier /etc/rc.conf, ou passées par l'intermédiaire d'un fichier de configuration. Avec la redirection d'adresse, il n'y a pas besoin de redirection de ports puisque toutes les données reçues sur une IP particulière sont redirigées. Les adresses IP sur la machine natd doivent être active et pointer sur l'interface externe. Consultez la page de manuel &man.rc.conf.5; pour cela. IP sur liaison parallèle (PLIP) PLIP IP sur liaison parallèle PLIP nous permet d'utiliser le protocole TCP/IP entre ports parallèles. C'est utile sur des machines sans cartes réseaux, ou pour effectuer une installation sur ordinateur portable. Dans cette section nous aborderons: La fabrication d'un câble parallèle (“laplink”). La connexion de deux ordinateurs via PLIP. Fabriquer un câble parallèle Vous pouvez acheter un câble parallèle auprès de la plupart des vendeurs de matériel informatique. Si ce n'est pas le cas, ou désirez savoir comment est fait un tel câble, le tableau suivant montre comment en faire un à partir d'un câble parallèle d'imprimante. Câblage d'un câble parallèle pour réseau A-name A-End B-End Descr. Post/Bit DATA0 -ERROR 2 15 15 2 Data 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Data 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Data 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Strobe 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Data 0/0x10 1/0x80 GND 18-25 18-25 GND -
Configurer PLIP Tout d'abord procurez-vous un câble “laplink”. Vérifiez ensuite que les deux ordinateurs disposent d'un noyau avec le support pour le pilote de périphérique &man.lpt.4;. &prompt.root; grep lp /var/run/dmesg.boot lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port Le port parallèle doit fonctionner sous interruption, sous &os; 4.X vous devriez avoir une ligne semblable à la ligne suivante dans le fichier de configuration du noyau: device ppc0 at isa? irq 7 Sous &os; 5.X, le fichier /boot/device.hints devrait contenir les lignes suivantes: hint.ppc.0.at="isa" hint.ppc.0.irq="7" Ensuite vérifiez si le fichier de configuration du noyau contient une ligne device plip ou si le module plip.ko est chargé. Dans les deux cas l'interface réseau parallèle devrait apparaître quand vous utilisez directement la commande &man.ifconfig.8;. Sous &os; 4.X de cette manière: &prompt.root; ifconfig lp0 lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 et sous &os; 5.X: &prompt.root; ifconfig plip0 plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 Le nom de périphérique utilisé pour l'interface parallèle est différent entre &os; 4.X (lpX) et &os; 5.X (plipX). Branchez le câble “laplink” sur les interfaces parallèles des deux ordinateurs. Configurez les paramètres de l'interface réseau des deux côtés en tant que root. Par exemple, si vous voulez connecter la machine host1 fonctionnant sous &os; 4.X avec la machine host2 tournant sous &os; 5.X: host1 <-----> host2 IP Address 10.0.0.1 10.0.0.2 Configurez l'interface sur host1 en tapant: &prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2 Configurez l'interface sur host2 en tapant: &prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1 Vous devriez avoir maintenant une connexion qui fonctionne. Veuillez consulter les pages de manuel &man.lp.4; et &man.lpt.4; pour plus de détails. Vous devriez également ajouter les deux noms de machines dans le fichier /etc/hosts: 127.0.0.1 localhost.my.domain localhost 10.0.0.1 host1.my.domain host1 10.0.0.2 host2.my.domain Pour vérifier le bon fonctionnement de la connexion, aller sur les deux machines et effectuez un “ping” vers l'autre machine. Par exemple, sur host1: &prompt.root; ifconfig lp0 lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.root; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire host2 host1 UH 0 0 lp0 &prompt.root; ping -c 4 host2 PING host2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- host2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Aaron Kaplan Ecrit original de Tom Rhodes Restructuré et ajouté par Brad Davis Complété par IPv6 L'IPv6 (également connu sous le nom de IPng “IP nouvelle génération”) est la nouvelle version du très célèbre protocole IP (aussi connu sous le nom d'IPv4). Comme les autres systèmes BSD, &os; utilise l'implémentation IPv6 KAME. Votre système &os; est donc fourni avec tout ce dont vous aurez besoin pour tester l'IPv6. Cette section se concentre sur la configuration et l'utilisation d'IPv6. Au début des années 90, on a pris conscience de la diminution rapide de l'espace d'adresses IPv4. Etant donné le taux d'expansion de l'Internet, deux problèmes majeurs apparaissaient: Le manque d'adresses. Aujourd'hui ce n'est plus vraiment un problème puisque les espaces d'adresses privées (10.0.0.0/8, 192.168.0.0/24, etc.) et la translation d'adresses (NAT) sont utilisés. Les tables des routeurs devenaient trop importantes. C'est toujours un problème actuellement. L'IPv6 rémédie à ces problèmes et à de nombreux autres: Espace d'adressage sur 128 bits. Ou plus précisément, il y a 340 282 366 920 938 463 463 374 607 431 768 211 456 adresses disponibles. Cela équivaut à approximativement 6.67 * 10^27 adresses IPv6 par kilomètre-carré de surface de notre planète. Les routeurs ne stockeront que des regroupements d'adresses dans leurs tables de routage réduisant donc l'espace moyen d'une table de routage à 8192 entrées. IPv6 présente également de nombreuses autres intéressantes fonctionnalités telles que: L'autoconfiguration des adresses (RFC2462) Adresses unicast (“une parmi plusieurs”) Adresses multicast (multidestinataires) obligatoires IPsec (protocole de sécurité IP) Struture d'entête simplifiée IP mobile Mécanismes de transistion IPv6-vers-IPv4 Pour plus d'informations consultez les références suivantes: Généralités sur l'IPv6 à playground.sun.com KAME.net 6bone.net Les adresses IPv6 Il existe différent types d'adresses IPv6: unicast, anycast et multicast. Les adresses unicast (mono-destinataire) sont les adresses classiques. Un paquet envoyé à une adresse unicast arrive à l'interface correspondant à l'adresse. Les adresses anycast ne sont normalement pas distinguables des adresses unicast mais correspondent à un groupe d'interfaces. Un paquet destiné à une adresse anycast arrivera à l'interface la plus proche (en terme d'unité de distance du protocole de routage). Les adresses anycast devraient n'être utilisées que par les routeurs. Les adresses multicast identifient un groupe d'interfaces. Un paquet destiné à une adresse multicast arrivera sur toutes les interfaces appartenant au groupe multicast. L'adresse de diffusion IPv4 (généralement xxx.xxx.xxx.255) est exprimée par des adresses multicast en IPv6. Adresses IPv6 réservées Adresse IPv6 Longueur du préfixe (bits) Description Notes :: 128 bits non-spécifiée similaire à 0.0.0.0 sous IPv4 ::1 128 bits adresse de boucle similaire à 127.0.0.1 sous IPv4 ::00:xx:xx:xx:xx 96 bits IPv4 encapsulé Les 32 bits de poids faible sont l'adresse IPv4. Egalement appelée “adresse IPv6 compatible IPv4”. ::ff:xx:xx:xx:xx 96 bits adresse IPv6 mappée IPv4 Les 32 bits de poids faible sont l'adresse IPv4. Destinées aux machines ne supportant pas l'IPv6. fe80:: - feb:: 10 bits lien-local similaire à l'interface de boucle sous IPv4 fec0:: - fef:: 10 bits site-local   ff:: 8 bits multicast   001 (base 2) 3 bits unicast globale Toutes les adresses unicast globales sont assignées à partir de ce pool. Les trois premiers bits de l'adresse sont “001”.
Lecture des adresses IPv6 La forme canonique est représentée suivant le schéma: x:x:x:x:x:x:x:x, où chaque “x” est une valeur héxadécimale sur 16 bits. Par exemple FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 Souvent dans une adresse on aura de longues sous-parties constituées de zéros, une telle sous-partie peut être abrégée par “::”. Les trois 0s de poids fort de chaque quartet hexadécimal peuvent également être omis. Par exemple fe80::1 correspond à la forme canonique fe80:0000:0000:0000:0000:0000:0000:0001. Une troisième forme est d'écrire les derniers 32 bits dans le style IPv4 bien connu (décimal) avec des points “.” comme séparateurs. Par exemple 2002::10.0.0.1 correspond à la représentation canonique (hexadécimale) 2002:0000:0000:0000:0000:0000:0a00:0001 qui est à son tour équivalente à l'écriture 2002::a00:1. Maintenant le lecteur devrait être en mesure de comprendre ce qui suit: &prompt.root; ifconfig rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active fe80::200:21ff:fe03:8e1%rl0 est une adresse de lien local configurée automatiquement. Elle est générée à partir de l'adresse MAC dans le cas de l'autoconfiguration. Pour plus d'informations sur la structure des adresses IPv6 consultez la RFC3513. Se connecter Actuellement, il y a quatre façons de se connecter à des machines et des réseaux utilisants l'IPv6: Rejoindre le réseau expérimental 6bone Obtenir un réseau IPv6 auprès de votre fournisseur d'accès. Contactez votre fournisseur d'accès Internet pour plus d'informations. Utilisation d'un tunnel 6-vers-4 (RFC3068) Utilisation du logiciel porté net/freenet6 si vous utilisez une connexion par modem. Ici nous ne parlerons que de la manière de se connecter au réseau 6bone puisque cela semble être aujourd'hui la méthode de connexion la plus populaire. Consultez tout d'abord le site 6bone et recherchez une connexion 6bone proche de vous. Contactez le responsable et avec un peu de chance on vous donnera les instructions à suivre pour configurer votre connexion. Généralement cela implique la mise en place d'un tunnel GRE (gif). Voici un exemple typique de configuration d'un tunnel &man.gif.4;: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 &prompt.root; ifconfig gif0 tunnel MON_ADR_IPv4 SON_ADR_IPv4 &prompt.root; ifconfig gif0 inet6 alias MON_ADR_IPv6_ASSIGNEE_A_LAUTRE_BOUT_DU_TUNNEL Remplacez les mots en majuscules par les informations que vous avez reçues du point d'accès 6bone. Ceci établit le tunnel. Vérifiez si le tunnel fonctionne en utilisant &man.ping6.8; sur l'adresse ff02::1%gif0. Vous devriez récevoir les réponses aux requêtes ping. Au cas où vous seriez intrigué par l'adresse ff02:1%gif0, sachez que c'est une adresse multicast. %gif0 précise que l'adresse multicast de l'interface gif0 doit être utilisée. Puisque nous utilisons ping sur une adresse multicast, l'autre bout du tunnel devrait également répondre. Désormais, la mise en place d'une route vers votre lien 6bone devrait être relativement directe: &prompt.root; route add -inet6 default -interface gif0 &prompt.root; ping6 -n MON_LIEN_MONTANT &prompt.root; traceroute6 www.jp.FreeBSD.org (3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms La sortie pourra être différente d'une machine à une autre. Maintenant vous devriez être en mesure d'atteindre le site IPv6 www.kame.net et de voir la tortue dansante — et cela si vous disposez d'un navigateur supportant l'IPv6 comme www/mozilla, Konqueror qui fait partie du logiciel x11/kdebase3, ou www/epiphany. DNS dans le monde IPv6 A l'origine, il existait deux types d'enregistrement DNS pour l'IPv6. L'organisme IETF a déclaré obsolète l'enregistrement A6. Les enregistrements AAAA sont aujourd'hui le standard. L'utilisation des enregistrements AAAA est assez direct. Assignez votre nom de machine à la nouvelle adresse IPv6 que vous venez d'obtenir en ajoutant: MYHOSTNAME AAAA MYIPv6ADDR à votre fichier de zone DNS primaire. Dans le cas où vous ne gérez pas vos propres zones DNS contactez le responsable de votre DNS. Les versions actuelles de bind (version 8.3 et 9) et dns/djbdns (avec le correctif IPv6) supportent les enregistrements AAAA. Effectuer les changements nécessaires dans le fichier <filename>/etc/rc.conf</filename> Paramétrage du client IPv6 Ces paramètres vous permettront de configurer une machine qui sera sur votre réseau local et sera un client, non pas un routeur. Pour que &man.rtsol.8; configure automatiquement votre interface réseau au démarrage tout ce dont vous avez besoin d'ajouter est: ipv6_enable="YES" Pour assigner une adresse IP statique telle que 2001:471:1f11:251:290:27ff:fee0:2093, à votre interface fxp0, ajoutez: ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093" Pour assigner le routeur par défaut 2001:471:1f11:251::1, ajoutez ce qui suit au fichier /etc/rc.conf: ipv6_defaultrouter="2001:471:1f11:251::1" Paramétrage d'un routeur/passerelle IPv6 Ceci vous aidera à mettre en oeuvre les instructions que votre fournisseur de tunnel, tel que 6bone, vous a donné et à les convertir en paramètres qui seront conservés à chaque démarrage. Pour rétablir votre tunnel au démarrage, utilisez quelque chose comme ce qui suit dans le fichier /etc/rc.conf: Listez les interfaces génériques de tunnel qui seront configurées, par exemple gif0: gif_interfaces="gif0" Pour configurer l'interface avec une adresse (extrémité) locale MY_IPv4_ADDR vers une adresse (extrémité) distante REMOTE_IPv4_ADDR: gifconfig_gif0="MY_IPv4_ADDR REMOTE_IPv4_ADDR" Pour utiliser l'adresse IPv6 que l'on vous a assigné en vue d'être utilisée pour votre extrémité du tunnel IPv6, ajoutez: ipv6_ifconfig_gif0="MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR" Ensuite tout ce qu'il reste à faire est de définir la route par défaut pour l'IPv6. C'est l'autre extrémité du tunnel IPv6: ipv6_defaultrouter="MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR" Annonce du routeur et auto-configuration Cette section vous aidera à configurer &man.rtadvd.8; pour l'annonce de la route IPv6 par défaut. Pour activer &man.rtadvd.8;, vous devrez ajouter ce qui suit à votre fichier /etc/rc.conf: rtadvd_enable="YES" Il est important que vous indiquiez l'interface sur laquelle le routeur IPv6 sera sollicité. Par exemple pour que &man.rtadvd.8; utilise fxp0: rtadvd_interfaces="fxp0" Nous devons maintenant créer le fichier de configuration /etc/rtadvd.conf. Voici un exemple: fxp0:\ :addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether: Remplacez fxp0 avec l'interface que vous allez utiliser. Ensuite remplacez 2001:471:1f11:246:: avec votre préfixe. Si vous êtes un sous-réseau /64 dédié, il ne sera pas nécessaire de modifier quelque chose d'autre. Sinon, vous devrez modifier prefixlen# avec la valeur correcte. Harti Brandt Contribution de ATM (<quote>Asynchronous Transfer Mode</quote>) sous &os; 5.X Configuration IP conventionnelle sur ATM (PVCs) L'IP conventionnelle sur ATM (“Classical IP over ATM”—CLIP) est la méthode la plus simple pour utiliser ATM (Asynchronous Transfer Mode) avec l'IP. Elle peut être utilisée en mode non connecté (“Switched Virtual Connections”—SVCs) et en mode connecté (“Permanent Virtual Connections”—PVCs). Cette section décrit comment configurer un réseau basé sur les PVCs. Configurations en réseau maillé La première méthode de configuration CLIP avec des PVCs est de connecter entre elles chaque machine du réseau par l'intermédiaire d'une PVC dédiée. Bien que cela soit simple à configurer, cela tend à devenir impraticable avec un nombre important de machines. Notre exemple suppose que nous avons quatre machines sur le réseau, chacune connectée au réseau ATM à l'aide d'une carte réseau ATM. La première étape est d'établir le plan des adresses IP et des connexions ATM entre machines. Nous utilisons le plan suivant: - + Machine Adresse IP hostA 192.168.173.1 hostB 192.168.173.2 hostC 192.168.173.3 hostD 192.168.173.4 Pour réaliser un réseau maillé, nous avons besoin d'une connexion ATM entre chaque paire de machines: - + Machines Couple VPI.VCI hostA - hostB 0.100 hostA - hostC 0.101 hostA - hostD 0.102 hostB - hostC 0.103 hostB - hostD 0.104 hostC - hostD 0.105 Les valeurs VPI et VCI à chaque extrémité de la connexion peuvent bien évidemment être différentes, mais par souci de simplicité nous supposerons quelles sont identiques. Ensuite nous devons configurer les interfaces ATM sur chaque machine: hostA&prompt.root; ifconfig hatm0 192.168.173.1 up hostB&prompt.root; ifconfig hatm0 192.168.173.2 up hostC&prompt.root; ifconfig hatm0 192.168.173.3 up hostD&prompt.root; ifconfig hatm0 192.168.173.4 up en supposant que l'interface ATM est hatm0 sur toutes les machines. Maintenant les PVCs doivent être configurées sur hostA (nous supposons qu'elles sont déjà configurées sur les switches ATM, vous devez consulter le manuel du switch sur comment réaliser cette configuration). hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr Bien évidemment des contrats de trafic autres qu'UBR (“Unspecified Bit Rate”) peuvent être utilisés dès que la carte ATM les supportent. Dans ce cas le nom du contrat de trafic est suivi par les paramètres du trafic. De l'aide concernant l'outil &man.atmconfig.8; peut être obtenue avec: &prompt.root; atmconfig help natm add ou dans la page de manuel de &man.atmconfig.8;. La même configuration peut être faite par l'intermédiaire de /etc/rc.conf. Pour la machine hostA cela ressemblerait à: network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="hostB hostC hostD" route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr" route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr" route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr" L'état de toutes les routes CLIP peut être obtenu avec: hostA&prompt.root; atmconfig natm show diff --git a/fr_FR.ISO8859-1/books/handbook/basics/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/basics/chapter.sgml index 94d8c79a9e..bac824c651 100644 --- a/fr_FR.ISO8859-1/books/handbook/basics/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/basics/chapter.sgml @@ -1,2970 +1,2970 @@ Chris Shumway Réécrit par Quelques bases d'UNIX &trans.a.fonvieille; Synopsis bases Le chapitre suivant couvrira les commandes et fonctionnalités de base du système d'exploitation FreeBSD. La plupart de ces informations sera valable pour n'importe quel système d'exploitation &unix;. Soyez libre de passer ce chapitre si vous êtes familier avec ces informations. Si vous êtes nouveau à FreeBSD, alors vous voudrez certainement lire attentivement ce chapitre. Après la lecture de ce chapitre, vous saurez: Comment utiliser les “consoles virtuelles” de &os;. Comment les permissions de fichier d'&unix; fonctionnent. L'architecture par défaut du système de fichiers sous &os;. L'organisation des disques sous &os;. Comment monter et démonter des systèmes de fichier. Ce que sont les processus, daemons et signaux. Ce qu'est un interpréteur de commande, et comment changer votre environnement de session par défaut. Comment utiliser les éditeurs de texte de base. Ce que sont les périphériques et les fichiers spéciaux de périphérique. Quel est le format des binaires utilisé sous &os;. Comment lire les pages de manuel pour plus d'information. Consoles virtuelles & terminaux consoles virtuelles terminaux FreeBSD peut être utilisé de diverses façons. L'une d'elles est en tapant des commandes sur un terminal texte. Une bonne partie de la flexibilité et de la puissance d'un système d'exploitation &unix; est directemtent disponible sous vos mains en utilisant FreeBSD de cette manière. Cette section décrit ce que sont les “terminaux” et les “consoles”, et comment les utiliser sous FreeBSD. La console console Si vous n'avez pas configuré FreeBSD pour lancer automatiquement un environnement graphique au démarrage, le système vous présentera une invite d'ouverture de session après son démarrage, juste après la fin des procédures de démarrage. Vous verrez quelque chose de similaire à: Additional ABI support:. Local package initialization:. Additional TCP options:. Fri Sep 20 13:01:06 EEST 2002 FreeBSD/i386 (pc3.example.org) (ttyv0) login: Les messages pourront être différents sur votre système, mais cela devrait y ressembler. Les deux dernières lignes sont celles qui nous intéressent actuellement. La seconde de ces lignes nous donne: FreeBSD/i386 (pc3.example.org) (ttyv0) Cette ligne contient quelques éléments d'information sur le système que vous venez de démarrer. Vous êtes en train de lire une console “FreeBSD”, tournant sur un processeur Intel ou compatible de la famille x86 C'est ce que signifie i386. Notez que même si vous faites tourner FreeBSD sur un CPU Intel 386, cela sera i386. Ce n'est pas le type de votre microprocesseur, mais “l'architecture” du microprocesseur qui est donnée ici. . Le nom de cette machine (chaque machine &unix; a un nom) est pc3.example.org, et vous regardez actuellement sa console système—le terminal ttyv0. Et enfin, la dernière ligne est toujours: login: C'est le moment où vous êtes supposé taper votre “nom d'utilisateur” pour vous attacher au système FreeBSD. La section suivante décrit comment procéder. Ouvrir une session sur un système FreeBSD FreeBSD est un système multi-utilisateur, multi-processeur. C'est la description formelle qui est habituellement donnée pour un système qui peut être utilisé par différentes personnes, qui exécutent simultanément de nombreux programmes sur une machine individuelle/ Chaque système multi-utilisateur a besoin d'un moyen pour distinguer un “utilisateur” du reste. Sous FreeBSD (et sous tous les systèmes de type &unix;), cela est effectué en demandant à chaque utilisateur de “s'attacher” au système avant d'être en mesure d'exécuter des programmes. Chaque utilisateur possède un nom unique (le nom d'utilisateur) et une clé secrète personnelle (le mot de passe). FreeBSD demandera ces deux éléments avant d'autoriser un utilisateur à lancer un programme. procédures de démarrage Juste après que FreeBSD ait démarré et en ait terminé avec l'exécution des procédures de démarrage Les procédures de démarrage sont des programmes qui sont exécutés automatiquement pas FreeBSD au démarrage. Leur fonction principale est de configurer le système pour permettre l'exécution de tout programme, et de démarrer tout service que vous avez configuré pour tourner en tâche de fond et exécuter des choses utiles. , il présentera une invite et demandera un nom d'utilisateur valide: login: Pour cet exemple, supposons que votre nom d'utilisateur est john. Tapez john à cette invite puis appuyez sur Entrée. Alors vous devrez être invité à entrer un “mot de passe”: login: john Password: Tapez maintenant le mot de passe de john, et appuyez sur Entrée. Le mot de passe n'est pas affiché! Vous n'avez pas à vous préoccuper de cela maintenant. Il suffit de penser que cela est fait pour des raisons de sécurité. Si vous avez tapé correctement votre mot de passe, vous devriez être maintenant attaché au système et prêt à essayer toutes les commandes disponibles. Vous devriez voir apparaître le MOTD ou message du jour suivi de l'invite de commande (un caractère #, $, ou %). Cela indique que vous avez ouvert avec succès une session sous &os;. Consoles multiples Exécuter des commandes &unix; dans une console est bien beau, mais FreeBSD peut exécuter plusieurs programmes à la fois. Avoir une seule console sur laquelle les commandes peuvent être tapées serait un peu du gaspillage quand un système d'exploitation comme FreeBSD peut exécuter des dizaines de programmes en même temps. C'est ici que des “consoles virtuelles” peuvent être vraiment utiles. FreeBSD peut être configuré pour présenter de nombreuses consoles virtuelles. Vous pouvez basculer d'une console virtuelle à une autre en utilisant une combinaison de touches sur votre clavier. Chaque console a son propre canal de sortie, et FreeBSD prend soin de rediriger correctement les entrées au clavier et la sortie vers écran quand vous basculez d'une console virtuelle à la suivante. Des combinaisons de touches spécifiques ont été réservées par FreeBSD pour le basculement entre consoles Une description assez technique et précise de tous les détails de la console FreeBSD et des pilotes de clavier peut être trouvée dans les pages de manuel de &man.syscons.4;, &man.atkbd.4;, &man.vidcontrol.1; et &man.kbdcontrol.1;. Nous ne nous étendrons pas en détails ici, mais le lecteur intéressé peut toujours consulter les pages de manuel pour explication plus détaillée et plus complète sur le fonctionnement des choses. . Vous pouvez utiliser AltF1, AltF2, jusqu'à AltF8 pour basculer vers une console virtuelle différente sous FreeBSD. Quand vous basculez d'une console à une autre, FreeBSD prend soin de sauvegarder et restaurer la sortie d'écran. Il en résulte l'“illusion” d'avoir plusieurs écrans et claviers “virtuels” que vous pouvez utiliser pour taper des commandes pour FreeBSD. Les programmes que vous lancez sur une console virtuelle ne cessent pas de tourner quand cette console n'est plus visible. Ils continuent de s'exécuter quand vous avez basculé vers une console virtuelle différente. Le fichier <filename>/etc/ttys</filename> La configuration par défaut de FreeBSD démarre avec huit consoles virtuelles. Cependant ce n'est pas un paramétrage fixe, et vous pouvez aisément personnaliser votre installation pour démarrer avec plus ou moins de consoles virtuelles. Le nombre et les paramétrages des consoles virtuelles sont configurés dans le fichier /etc/ttys. Vous pouvez utiliser le fichier /etc/ttys pour configurer les consoles virtuelles de FreeBSD. Chaque ligne non-commentée dans ce fichier (les lignes qui ne débutent pas par le caractère #) contient le paramétrage d'un terminal ou d'une console virtuelle. La version par défaut de ce fichier livrée avec FreeBSD configure neuf consoles virtuelles, et en active huit. Ce sont les lignes commençant avec le terme ttyv: # name getty type status comments # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure Pour une description détaillée de chaque colonne de ce fichier et toutes les options que vous pouvez utiliser pour configurer les consoles virtuelles, consultez la page de manuel &man.ttys.5;. Console en mode mono-utilisateur Une description détaillée de ce qu'est le mode mono-utilisateur peut être trouvée dans . Il est important de noter qu'il n'y a qu'une console de disponible quand vous exécuter FreeBSD en mode mono-utilisateur. Il n'y a aucune console virtuelle de disponible. Le paramétrage de la console en mode mono-utilisateur peut être également trouvé dans le fichier /etc/ttys. Recherchez la ligne qui commence avec le mot console: # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off secure Comme l'indiquent les commentaires au-dessus de la ligne console, vous pouvez éditer cette ligne et changer secure pour insecure. Si vous faites cela, quand FreeBSD démarrera en mode mono-utilisateur, il demandera le mot de passe de root. Cependant faites attention quand vous modifiez cela pour insecure. Si vous oubliez le mot de passe de root, le démarrage en mode mono-utilisateur sera condamné. Il est encore possible, mais cela pourra être relativement compliqué pour quelqu'un qui n'est pas à l'aise avec le processus de démarrage de FreeBSD et les programmes entrant en jeu. Permissions UNIX FreeBSD, étant un descendant direct de l'&unix; BSD, est basé sur plusieurs concepts clés d'&unix;. Le premier, et le plus prononcé, est le fait que FreeBSD est un système d'exploitation multi-utilisateurs. Le système peut gérer plusieurs utilisateurs travaillant tous simultanément sur des tâches complètement indépendantes. Le système est responsable du partage correct et de la gestion des requêtes pour les périphériques matériels, la mémoire, et le temps CPU de façon équitable entre chaque utilisateur. Puisque le système est capable de supporter des utilisateurs multiples, tout ce que le système gère possède un ensemble de permissions définissant qui peut écrire, lire, et exécuter la ressource. Ces permissions sont stockées sous forme de trois octets divisés en trois parties, une pour le propriétaire du fichier, une pour le groupe auquel appartient le fichier, et une autre pour le reste du monde. Cette représentation numérique fonctionne comme ceci: permissions permissions de fichier - + Valeur Permission Contenu du répertoire 0 Pas d'accès en lecture, pas d'accès en écriture, pas d'accès en exécution --- 1 Pas d'accès en lecture, pas d'accès en écriture, exécution --x 2 Pas d'accès en lecture, écriture, pas d'accès en exécution -w- 3 Pas d'accès en lecture, écriture, exécution -wx 4 Lecture, pas d'accès en écriture, pas d'accès en exécution r-- 5 Lecture, pas d'accès en écriture, exécution r-x 6 Lecture, écriture, pas d'accès en exécution rw- 7 Lecture, écriture, exécution rwx ls répertoires Vous pouvez utiliser l'option avec la commande &man.ls.1; pour afficher le contenu du répertoire sous forme une longue et détaillée qui inclut une colonne avec des informations sur les permissions d'accès des fichiers pour le propriétaire, le groupe, et le reste du monde. Par exemple un ls -l dans un répertoire quelconque devrait donner: &prompt.user; ls -l total 530 -rw-r--r-- 1 root wheel 512 Sep 5 12:31 myfile -rw-r--r-- 1 root wheel 512 Sep 5 12:31 otherfile -rw-r--r-- 1 root wheel 7680 Sep 5 12:31 email.txt ... Voici comment est divisée la première colonne de l'affichage généré par ls -l: -rw-r--r-- Le premier caractère (le plus à gauche) indique si c'est un fichier normal, un répertoire, ou un périphérique mode caractère, une socket, ou tout autre pseudo-périphérique. Dans ce cas, - indique un fichier normal. Les trois caractères suivants, rw- dans cet exemple, donnent les permissions pour le propriétaire du fichier. Les trois caractères qui suivent, r--, donnent les permissions pour le groupe auquel appartient le fichier. Les trois derniers caractères, r--, donnent les permissions pour le reste du monde. Un tiret signifie que la permission est désactivée. Dans le cas de ce fichier, les permissions sont telles que le propriétaire peut lire et écrire le fichier, le groupe peut lire le fichier, et le reste du monde peut seulement lire le fichier. D'après la table ci-dessus, les permissions pour ce fichier seraient 644, où chaque chiffre représente les trois parties des permissions du fichier. Tout cela est bien beau, mais comment le système contrôle les permissions sur les périphériques? En fait FreeBSD traite la plupart des périphériques sous la forme d'un fichier que les programmes peuvent ouvrir, lire, et écrire des données dessus comme tout autre fichier. Ces périphériques spéciaux sont stockés dans le répertoire /dev. Les répertoires sont aussi traités comme des fichiers. Ils ont des droits en lecture, écriture et exécution. Le bit d'exécution pour un répertoire a une signification légèrement différente que pour les fichiers. Quand un répertoire est marqué exécutable, cela signifie que l'on peut être traversé, i.e. il est possible d'utiliser “cd” (changement de répertoire). Ceci signifie également qu'à l'intérieur du répertoire il est possible d'accéder aux fichiers dont les noms sont connues (en fonction, bien sûr, des permissions sur les fichiers eux-mêmes). En particulier, afin d'obtenir la liste du contenu d'un répertoire, la permission de lecture doit être positionnée sur le répertoire, tandis que pour effacer un fichier dont on connaît le nom, il est nécessaire d'avoir les droits d'écriture et d'exécution sur le répertoire contenant le fichier. Il y a d'autres types de permissions, mais elles sont principalement employées dans des circonstances spéciales comme les binaires “setuid” et les répertoires “sticky”. Si vous désirez plus d'information sur les permissions de fichier et comment les positionner, soyez sûr de consulter la page de manuel &man.chmod.1;. Tom Rhodes Contribution de Permissions symboliques Permissionssymboliques Les permissions symboliques, parfois désignées sous le nom d'expressions symboliques, utilisent des caractères à la place de valeur en octal pour assigner les permissions aux fichiers et répertoires. Les expressions symboliques emploient la syntaxe: (qui) (action) (permissions), avec les valeurs possibles suivantes: - + Option Lettre Représente (qui) u Utilisateur (qui) g Groupe (qui) o Autre (qui) a Tous (le monde entier) (action) + Ajouter des permissions (action) - Retirer des permissions (action) = Fixe les permissions de façon explicite (permissions) r Lecture (permissions) w Ecriture (permissions) x Exécution (permissions) t bit collant (sticky) (permissions) s Exécuter avec l'ID utilisateur (UID) ou groupe (GID) Ces valeurs sont utilisées avec la commande &man.chmod.1; comme précédemment mais avec des lettres. Par exemple, vous pourriez utiliser la commande suivante pour refuser l'accès au fichier FICHIER à d'autres utilisateurs: &prompt.user; chmod go= FICHIER Une liste séparé par des virgules peut être fournie quand plus d'un changement doit être effectué sur un fichier. Par exemple la commande suivante retirera les permissions d'écriture aux groupes et au “reste du monde” sur le fichier FICHIER, puis ajoutera la permission d'exécution pour tout le monde: &prompt.user; chmod go-w,a+x FICHIER Organisation de l'arborescence des répertoires hiérarchie des répertoires L'organisation de l'arborescence des répertoires de FreeBSD est essentielle pour obtenir une compréhension globale du système. Le concept le plus important à saisir est celui du répertoire racine, “/”. Ce répertoire est le premier a être monté au démarrage et il contient le système de base nécessaire pour préparer le système d'exploitation au fonctionnement multi-utilisateurs. Le répertoire racine contient également les points de montage pour tous les autres systèmes de fichiers que vous pourriez vouloir monter. Un point de montage est un répertoire où peuvent être greffés des systèmes de fichiers supplémentaires au système de fichiers racine. Les points de montage standards incluent /usr, /var, /mnt, et /cdrom. Ces répertoires sont en général référencés par des entrées dans le fichier /etc/fstab. /etc/fstab est une table des divers systèmes de fichiers et de leur point de montage utilisé comme référence par le système. La plupart des systèmes de fichiers présents dans /etc/fstab sont montés automatiquement au moment du démarrage par la procédure &man.rc.8; à moins que l'option soit présente. Consultez la page de manuel de &man.fstab.5; pour plus d'information sur le format du fichier /etc/fstab et des options qu'il contient. Une description complète de l'arborescence du système de fichiers est disponible dans la page de manuel &man.hier.7;. Pour l'instant, une brève vue d'ensemble des répertoires les plus courants suffira. - + Répertoire Description / Répertoire racine du système de fichiers. /bin/ Programmes utilisateur fondamentaux aux deux modes de fonctionnement mono et multi-utilisateurs. /boot/ Programmes et fichiers de configuration utilisés durant le processus de démarrage du système. /boot/defaults/ Fichiers de configuration par défaut du processus de démarrage; voir la page de manuel &man.loader.conf.5;. /dev/ Fichiers spéciaux de périphérique; voir la page de manuel &man.intro.4;. /etc/ Procédures et fichiers de configuration du système. /etc/defaults/ Fichiers de configuration du système par défaut; voir la page de manuel &man.rc.8;. /etc/mail/ Fichiers de configuration pour les agents de transport du courrier électronique comme &man.sendmail.8;. /etc/namedb/ Fichiers de configuration de named; voir la page de manuel &man.named.8;. /etc/periodic/ Procédures qui sont exécutées de façon quotidienne, hebdomadaire et mensuelle par l'intermédiaire de &man.cron.8;; voir la page de manuel &man.periodic.8;. /etc/ppp/ Fichiers de configuration de ppp; voir la page de manuel &man.ppp.8;. /mnt/ Répertoire vide habituellement utilisé par les administrateurs système comme un point de montage temporaire. /proc/ Le système de fichiers pour les processus; voir les pages de manuel &man.procfs.5;, &man.mount.procfs.8;. /root/ Répertoire personnel du compte root. /sbin/ Programmes systèmes et utilitaires systèmes fondamentaux aux environnements mono et multi-utilisateurs. /stand/ Programmes utilisés dans un environnement autonome. /tmp/ Fichiers temporaires, généralement un système de fichiers en mémoire &man.mfs.8; (le contenu de /tmp n'est en général PAS préservé par un redémarrage du système). /usr/ La majorité des utilitaires et applications utilisateur. /usr/bin/ Utilitaires généraux, outils de programmation, et applications. /usr/include/ Fichiers d'en-tête C standard. /usr/lib/ Ensemble des bibliothèques. /usr/libdata/ Divers fichiers de données de service. /usr/libexec/ Utilitaires et daemons système (exécutés par d'autres programmes). /usr/local/ Exécutables, bibliothèques, etc... Egalement utilisé comme destination de défaut pour les logiciels portés pour FreeBSD. Dans /usr/local, l'organisation générale décrite par la page de manuel &man.hier.7; pour /usr devrait être utilisée. Exceptions faites du répertoire man qui est directement sous /usr/local plutôt que sous /usr/local/share, et la documentation des logiciels portés est dans share/doc/port. /usr/obj/ Arborescence cible spécifique à une architecture produite par la compilation de l'arborescence /usr/src. /usr/ports Le catalogue des logiciels portés (optionnel). /usr/sbin/ Utilitaires et daemons système (exécutés par les utilisateurs). /usr/share/ Fichiers indépendants de l'architecture. /usr/src/ Fichiers source FreeBSD et/ou locaux. /usr/X11R6/ Exécutables, bibliothèques etc... de la distribution d'X11R6 (optionnel). /var/ Fichiers de traces, fichiers temporaires, et fichiers tampons. /var/log/ Divers fichiers de trace du système. /var/mail/ Boîtes aux lettres des utilisateurs. /var/spool/ Divers répertoires tampons des systèmes de courrier électronique et d'impression. /var/tmp/ Fichiers temporaires qui sont conservés durant les redémarrages. /var/yp Tables NIS. Organisation des disques Le plus petit élément qu'utilise FreeBSD pour retrouver des fichiers est le nom de fichier. Les noms de fichiers sont sensibles à la casse des caractères, ce qui signifie que readme.txt et README.TXT sont deux fichiers séparés. FreeBSD n'utilise pas l'extension (.txt) d'un fichier pour déterminer si ce fichier est un programme, un document ou une autre forme de donnée. Les fichiers sont stockés dans des répertoires. Un répertoire peut ne contenir aucun fichier, ou en contenir plusieurs centaines. Un répertoire peut également contenir d'autre répertoires, vous permettant de construire une hiérarchie de répertoires à l'intérieur d'un autre. Cela rend plus simple l'organisation de vos données. Les fichiers et les répertoires sont référencés en donnant le nom du fichier ou du répertoire, suivi par un slash, /, suivi par tout nom de répertoire nécessaire. Si vous avez un répertoire foo, qui contient le répertoire bar, qui contient le fichier readme.txt, alors le nom complet, ou chemin (“path”) vers le fichier est foo/bar/readme.txt. Les répertoires et les fichiers sont stockés sur un système de fichiers. Chaque système de fichiers contient à son niveau le plus haut un répertoire appelé répertoire racine pour ce système de fichiers. Ce répertoire racine peut alors contenir les autres répertoires. Jusqu'ici cela est probablement semblable à n'importe quel autre système d'exploitation que vous avez pu avoir utilisé. Il y a quelques différences: par exemple, &ms-dos; utilise \ pour séparer les noms de fichier et de répertoire, alors que MacOS utilise :. FreeBSD n'utilise pas de lettre pour les lecteurs, ou d'autres noms de disque dans le chemin. Vous n'écrirez pas c:/foo/bar/readme.txt sous FreeBSD. Au lieu de cela, un système de fichiers est désigné comme système de fichiers racine. La racine du système de fichiers racine est représentée par un /. Tous les autres systèmes de fichiers sont alors montés sous le système de fichiers racine. Peu importe le nombre de disques que vous avez sur votre système FreeBSD, chaque répertoire apparaît comme faisant partie du même disque. Supposez que vous avez trois systèmes de fichiers, appelés A, B, et C. Chaque système de fichiers possède un répertoire racine, qui contient deux autres répertoires, nommés A1, A2 (et respectivement B1, B2 et C1, C2). Appelons A le système de fichiers racine. Si vous utilisiez la commande ls pour visualiser le contenu de ce répertoire, vous verriez deux sous-répertoires, A1 et A2. L'arborescence des répertoires ressemblera à ceci: / | +--- A1 | `--- A2 Un système de fichiers doit être monté dans un répertoire d'un autre système de fichiers. Supposez maintenant que vous montez le système de fichiers B sur le répertoire A1. Le répertoire racine de B remplace A1, et les répertoires de B par conséquent apparaissent: / | +--- A1 | | | +--- B1 | | | `--- B2 | `--- A2 Tout fichier de B1 ou B2 peut être atteint avec le chemin /A1/B1 ou /A1/B2 si nécessaire. Tous les fichiers qui étaient dans A1 ont été temporairement cachés. Ils réapparaîtront si B est démonté de A. Si B a été monté sur A2 alors le diagramme sera semblable à celui-ci: / | +--- A1 | `--- A2 | +--- B1 | `--- B2 et les chemins seront /A2/B1 et respectivement /A2/B2. Les systèmes de fichiers peuvent être montés au sommet d'un autre. En continuant l'exemple précédent, le système de fichiers C pourrait être monté au sommet du répertoire B1 dans le système de fichiers B, menant à cet arrangement: / | +--- A1 | `--- A2 | +--- B1 | | | +--- C1 | | | `--- C2 | `--- B2 Où C pourrait être monté directement sur le système de fichiers A, sous le répertoire A1: / | +--- A1 | | | +--- C1 | | | `--- C2 | `--- A2 | +--- B1 | `--- B2 Si vous êtes familier de &ms-dos;, ceci est semblable, bien que pas identique, à la commande join. Ce n'est normalement pas quelque chose qui doit vous préoccuper. Généralement vous créez des systèmes de fichiers à l'installation de FreeBSD et décidez où les monter, et ensuite ne les modifiez jamais à moins que vous ajoutiez un nouveau disque. Il est tout à fait possible de n'avoir qu'un seul grand système de fichiers racine, et de ne pas en créer d'autres. Il y a quelques inconvénients à cette approche, et un avantage. Avantages des systèmes de fichiers multiples Les différents systèmes de fichiers peuvent avoir différentes options de montage. Par exemple, avec une planification soigneuse, le système de fichiers racine peut être monté en lecture seule, rendant impossible tout effacement par inadvertance ou édition de fichier critique. La séparation des systèmes de fichiers inscriptibles par l'utilisateur permet leur montage en mode nosuid; cette option empêche les bits suid/guid des exécutables stockés sur ce système de fichiers de prendre effet, améliorant peut-être la sécurité. FreeBSD optimise automatiquement la disposition des fichiers sur un système de fichiers, selon la façon dont est utilisé le système de fichiers. Aussi un système de fichiers contenant beaucoup de petits fichiers qui sont écrits fréquemment aura une optimisation différente à celle d'un système contenant moins, ou de plus gros fichiers. En ayant un seul grand système de fichiers cette optimisation est perdue. Les systèmes de fichiers de FreeBSD sont très robustes même en cas de coupure secteur. Cependant une coupure secteur à un moment critique pourrait toujours endommager la structure d'un système de fichiers. En répartissant vos données sur des systèmes de fichiers multiples il est plus probable que le système redémarre, vous facilitant la restauration des données à partir de sauvegardes si nécessaire. Avantage d'un système de fichiers unique Les systèmes de fichiers ont une taille fixe. Si vous créez un système de fichiers à l'installation de FreeBSD et que vous lui donnez une taille spécifique, vous pouvez plus tard vous apercevoir que vous avez besoin d'une partition plus grande. Cela n'est pas facilement faisable sans sauvegardes, recréation du système de fichiers, et enfin restauration des données. FreeBSD 4.4 et suivants disposent d'une commande, &man.growfs.8;, qui permettra d'augmenter la taille d'un système de fichiers au vol, supprimant cette limitation. Les systèmes de fichiers sont contenus dans des partitions. Cela n'a pas la même signification que l'utilisation commune du terme partition (par exemple une partition &ms-dos;), en raison de l'héritage Unix de FreeBSD. Chaque partition est identifiée par une lettre de a à h. Chaque partition ne contient qu'un seul système de fichiers, cela signifie que les systèmes de fichiers sont souvent décrits soit par leur point de montage typique dans la hiérarchie du système de fichiers, soit par la lettre de la partition qui les contient. FreeBSD utilise aussi de l'espace disque pour l'espace de pagination (“swap”). L'espace de pagination fournit à FreeBSD la mémoire virtuelle. Cela permet à votre ordinateur de se comporter comme s'il disposait de beaucoup plus de mémoire qu'il n'en a réellement. Quand FreeBSD vient à manquer de mémoire il déplace certaines données qui ne sont pas actuellement utilisées vers l'espace de pagination, et les rapatrie (en déplaçant quelque chose d'autre) quand il en a besoin. Quelques partitions sont liées à certaines conventions. Partition Convention a Contient normalement le système de fichiers racine b Contient normalement l'espace de pagination c Normalement de la même taille que la tranche (“slice”) contenant les partitions. Cela permet aux utilitaires devant agir sur l'intégralité de la tranche (par exemple un analyseur de blocs défectueux) de travailler sur la partition c. Vous ne devriez normalement pas créer de système de fichiers sur cette partition. d La partition d a eu dans le passé une signification spécifique, c'est terminé maintenant. A ce jour, quelques outils peuvent fonctionner curieusement si on leur dit de travailler sur la partition d, aussi sysinstall ne créera normalement pas de partition d. Chaque partition contenant un système de fichiers est stockée dans ce que FreeBSD appelle une tranche (“slice”). Tranche - “slice” est le terme FreeBSD pour ce qui est communément appelé partition, et encore une fois, cela en raison des fondations Unix de FreeBSD. Les tranches sont numérotées, en partant de 1, jusqu'à 4. slices tranches partitions mode dédié Les numéros de tranche suivent le nom du périphérique, avec le préfixe s, et commencent à 1. Donc “da0s1” est la première tranche sur le premier disque SCSI. Il ne peut y avoir que quatre tranches physiques sur un disque, mais vous pouvez avoir des tranches logiques dans des tranches physiques d'un type précis. Ces tranches étendues sont numérotées à partir de 5, donc “ad0s5” est la première tranche étendue sur le premier disque IDE. Elles sont utilisées par des systèmes de fichiers qui s'attendent à occuper une tranche entière. Les tranches, les disques “en mode dédié”, et les autres disques contiennent des partitions, qui sont représentées par des lettres allant de a à h. Cette lettre est ajoutée au nom de périphérique, aussi “da0a” est la partition a sur le premier disque da, qui est en “en mode dédié”. “ad1s3e” est la cinquième partition de la troisième tranche du second disque IDE. En conclusion chaque disque présent sur le système est identifié. Le nom d'un disque commence par un code qui indique le type de disque, suivi d'un nombre, indiquant de quel disque il s'agit. Contrairement aux tranches, la numérotation des disques commence à 0. Les codes communs que vous risquez de rencontrer sont énumérés dans le . Quand vous faites référence à une partition, FreeBSD exige que vous nommiez également la tranche et le disque contenant la partition, et quand vous faites référence à une tranche vous devrez également faire référence au nom du disque. Faites cela en écrivant le nom du disque, s, le numéro de la tranche, et enfin la lettre de la partition. Des exemples sont donnés dans l'. L' montre un exemple de l'organisation d'un disque qui devrait aider à clarifier les choses. Afin d'installer FreeBSD vous devez tout d'abord configurer les tranches sur votre disque, ensuite créer les partitions dans la tranche que vous utiliserez pour FreeBSD, et alors créer un système de fichiers (ou espace de pagination) dans chaque partition, et décider de l'endroit où seront montés les systèmes de fichiers. Codes des périphériques disques Code Signification ad Disque ATAPI (IDE) da Disque SCSI acd CDROM ATAPI (IDE) cd CDROM SCSI fd Lecteur de disquette
Exemples d'appellation de disques, tranches et partitions Nom Signification ad0s1a Première partition (a) sur la première tranche (s1) du premier disque IDE (ad0). da1s2e Cinquième partition (e) sur la seconde tranche (s2) du deuxième disque SCSI (da1). Modèle conceptuel d'un disque Ce diagramme montre comment FreeBSD voit le premier disque IDE attaché au système. Supposons que le disque a une capacité de 4 GO, et contient deux tranches de 2 GO (partitions &ms-dos;). La première tranche contient un disque &ms-dos;, C:, et la seconde tranche contient une installation de FreeBSD. Dans cet exemple l'installation de FreeBSD a trois partitions, et une partition de pagination. Les trois partitions accueilleront chacune un système de fichiers. La partition a sera utilisée en tant que système de fichiers racine, la partition e pour le contenu du répertoire /var, et f pour l'arborescence du répertoire /usr. .-----------------. --. | | | | DOS / Windows | | : : > Première tranche, ad0s1 : : | | | | :=================: ==: --. | | | Partition a, montée en tant que / | | | > référencée ad0s2a | | | | | :-----------------: ==: | | | | Partition b, utilisée comme swap | | | > référencée ad0s2b | Partition c, | | | | pas de :-----------------: ==: | système de | | | Partition e, utilisée en /var > fichiers | | > référencée ad0s2e | intégralité | | | | de la tranche :-----------------: ==: | FreeBSD ad0s2c | | | | : : | Partition f, utilisée en /usr | : : > référencée ad0s2f | : : | | | | | | | | --' | `-----------------' --' Monter et démonter des systèmes de fichiers Le système de fichiers peut être vu comme un arbre enraciné sur le répertoire /. /dev, /usr, et les autres répertoires dans le répertoire racine sont des branches, qui peuvent avoir leurs propres branches, comme /usr/local, et ainsi de suite. système de fichiers racine Il y a diverses raisons pour héberger certains de ces répertoires sur des systèmes de fichiers séparés. /var contient les répertoires log/, spool/, et divers types de fichiers temporaires, et en tant que tels, peuvent voir leur taille augmenter de façon importante. Remplir le système de fichiers racine n'est pas une bonne idée, aussi séparer /var de / est souvent favorable. Une autre raison courante de placer certains répertoires sur d'autres systèmes de fichiers est s'ils doivent être hébergés sur des disques physiques séparés, ou sur des disques virtuels séparés, comme les systèmes de fichiers réseau, ou les lecteurs de CDROM. Le fichier <filename>fstab</filename> systèmes de fichiers montés avec fstab Durant le processus de démarrage, les systèmes de fichiers listés dans /etc/fstab sont automatiquement montés (à moins qu'il ne soient listés avec l'option ). Le fichier /etc/fstab contient une liste de lignes au format suivant: device /mount-point fstype options dumpfreq passno device Un nom de périphérique (qui devrait exister), comme expliqué dans la . mount-point Un répertoire (qui devrait exister), sur lequel sera monté le système de fichier. fstype Le type de système de fichiers à indiquer à &man.mount.8;. Le système de fichiers par défaut de FreeBSD est l'ufs. options Soit pour des systèmes de fichiers à lecture-écriture, soit pour des systèmes de fichiers à lecture seule, suivi par toute option qui peut s'avérer nécessaire. Une option courante est pour les systèmes de fichiers qui ne sont normalement pas montés durant la séquence de démarrage. D'autres options sont présentées dans la page de manuel &man.mount.8;. dumpfreq C'est utilisé par &man.dump.8; pour déterminer quels systèmes de fichiers nécessitent une sauvegarde. Si ce champ est absent, une valeur de zéro est supposée. passno Ceci détermine l'ordre dans lequel les systèmes de fichiers devront être vérifiés. Les systèmes de fichiers qui doivent être ignorés devraient avoir leur passno positionné à zéro. Le système de fichiers racine (qui doit être vérifié avant tout le reste) devrait avoir son passno positionné à un, et les options passno des autres systèmes fichiers devraient être positionnées à des valeurs supérieures à un. Si plus d'un système de fichiers ont le même passno alors &man.fsck.8; essaiera de vérifier les systèmes de fichiers en parallèle si c'est possible. La commande <command>mount</command> systèmes de fichiers montage La commande &man.mount.8; est ce qui est finalement utilisé pour monter des systèmes de fichiers. Dans sa forme la plus simple, vous utilisez: &prompt.root; mount device mountpoint Il y beaucoup d'options, comme mentionné dans la page de manuel &man.mount.8;, mais les plus courantes sont: Options de montage Monte tous les systèmes de fichiers listés dans /etc/fstab. Exception faite de ceux marqués comme “noauto”, ou exclus par le drapeau , ou encore ceux qui sont déjà montés. Tout effectuer à l'exception de l'appel système de montage réel. Cette option est utile conjointement avec le drapeau pour déterminer ce que &man.mount.8; est en train d'essayer de faire. Force le montage d'un système de fichiers non propre (dangereux), ou force la révocation de l'accès en écriture quand on modifie l'état de montage d'un système de fichiers de l'accès lecture-écriture à l'accès lecture seule. Monte le système de fichiers en lecture seule. C'est identique à l'utilisation de l'argument avec l'option . fstype Monte le système de fichiers comme étant du type de système donné, ou monte seulement les systèmes de fichiers du type donné, si l'option est précisée. “ufs” est le type de système de fichiers par défaut. Mets à jour les options de montage sur le système de fichiers. Rends la commande prolixe. Monte le système de fichiers en lecture-écriture. L'option accepte une liste d'options séparées par des virgules, dont les suivantes: nodev Ne pas prendre en compte les périphériques spéciaux sur le système de fichiers. C'est une option de sécurité utile. noexec Ne pas autoriser l'exécution de binaires sur ce système de fichiers. C'est également une option de sécurité utile. nosuid Ne pas prendre en compte les indicateurs setuid ou setgid sur le système de fichiers. C'est également une option de sécurité utile. La commande <command>umount</command> systèmes de fichiers démontage La commande &man.umount.8; prend, comme paramètre, un des points de montage, un nom de périphérique, ou l'option ou . Toutes les formes acceptent pour forcer de démontage, et pour le mode prolixe. Soyez averti que l'utilisation de n'est généralement pas une bonne idée. Démonter de force des systèmes de fichiers pourrait faire planter l'ordinateur ou endommager les données sur le système de fichiers. Les options et sont utilisées pour démonter tous les systèmes de fichiers actuellement montés, éventuellement modifié par les types de systèmes de fichiers listés après l'option . Cependant l'option , n'essaye pas de démonter le système de fichiers racine. Processus FreeBSD est un système d'exploitation multi-tâches. Cela veut dire qu'il semble qu'il y ait plus d'un programme fonctionnant à la fois. Tout programme fonctionnant à un moment donné est appelé un processus. Chaque commande que vous utiliserez lancera au moins un nouveau processus, et il y a de nombreux processus système qui tournent constamment, maintenant ainsi les fonctionnalités du système. Chaque processus est identifié de façon unique par un nombre appelé process ID (identifiant de processus), ou PID, et, comme pour les fichiers, chaque processus possède également un propriétaire et un groupe. Les informations sur le propriétaire et le groupe sont utilisées pour déterminer quels fichiers et périphériques sont accessibles au processus, en utilisant le principe de permissions de fichiers abordé plus tôt. La plupart des processus ont également un processus parent. Le processus parent est le processus qui les a lancés. Par exemple, si vous tapez des commandes sous un interpréteur de commandes, alors l'interpréteur de commandes est un processus, et toute commande que vous lancez est aussi un processus. Chaque processus que vous lancez de cette manière aura votre interpréteur de commandes comme processus parent. Une exception à cela est le processus spécial appelé &man.init.8;. init est toujours le premier processus, donc son PID est toujours 1. init est lancé automatiquement par le noyau au démarrage de FreeBSD. Deux commandes sont particulièrement utiles pour voir les processus sur le système, &man.ps.1; et &man.top.1;. La commande ps est utilisée pour afficher une liste statique des processus tournant actuellement, et peut donner leur PID, la quantité de mémoire qu'ils utilisent, la ligne de commande par l'intermédiaire de laquelle ils ont été lancés, et ainsi de suite. La commande &man.top.1; affiche tous les processus, et actualise l'affichage régulièrement, de sorte que vous puissiez voir de façon intéractive ce que fait l'ordinateur. Par défaut, &man.ps.1; n'affiche que les commandes que vous faites tourner et dont vous êtes le propriétaire. Par exemple: &prompt.user; ps PID TT STAT TIME COMMAND 298 p0 Ss 0:01.10 tcsh 7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14) 37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14) 48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi 48730 p0 IW 0:00.00 (dns helper) (navigator-linux-) 72210 p0 R+ 0:00.00 ps 390 p1 Is 0:01.14 tcsh 7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y 6688 p3 IWs 0:00.00 tcsh 10735 p4 IWs 0:00.00 tcsh 20256 p5 IWs 0:00.00 tcsh 262 v0 IWs 0:00.00 -tcsh (tcsh) 270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16 280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16 284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc 285 v0 S 0:38.45 /usr/X11R6/bin/sawfish Comme vous pouvez le voir dans cet exemple, la sortie de &man.ps.1; est organisée en un certain nombre de colonnes. PID est l'identifiant de processus discuté plus tôt. Les PIDs sont assignés à partir de 1, et vont jusqu'à 99999, et puis repassent à 1 quand le maximum est atteint. La colonne TT donne le terminal sur lequel tourne le programme, et peut être pour le moment ignoré sans risque. STAT affiche l'état du programme, peut être également ignoré. TIME est la durée d'utilisation du CPU—ce n'est généralement pas le temps écoulé depuis que vous avez lancé le programme, comme la plupart des programmes passent beaucoup de temps à attendre que certaines choses se produisent avant qu'ils n'aient besoin de dépenser du temps CPU. Et enfin, COMMAND est la ligne de commande qui a été utilisée lors du lancement du programme. &man.ps.1; supporte un certain nombre d'options différentes pour modifier les informations affichées. Un des ensembles d'options les plus utiles est auxww. affiche l'information au sujet de tous les processus tournant, et pas seulement les vôtres. donne le nom de l'utilisateur du propriétaire du processus, ainsi que l'utilisation de la mémoire. affiche des informations sur les processus “daemon”, et oblige &man.ps.1; à afficher la ligne de commande complète, plutôt que de la tronquer quand elle est trop longue pour tenir à l'écran. La sortie de &man.top.1; est semblable. Un extrait de session ressemble à ceci: &prompt.user; top last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10 47 processes: 1 running, 46 sleeping CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free Swap: 256M Total, 38M Used, 217M Free, 15% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top 7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14 281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA 296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm 48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu 175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd 7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt ... La sortie est divisée en deux sections. L'entête (les cinq premières lignes) donne le PID du dernier processus lancé, la charge système moyenne (qui est une mesure de l'occupation du système), la durée de fonctionnement du système (le temps écoulé depuis le dernier redémarrage), et l'heure actuelle. Les autres éléments de l'entête concernent le nombre de processus en fonctionnement (47 dans notre cas), combien d'espace mémoire et d'espace de pagination sont occupés, et combien de temps le système passe dans les différents états du CPU. En dessous il y a une série de colonnes contenant des informations semblables à celles données par &man.ps.1;. Comme précédemment vous pouvez lire le PID, le nom d'utilisateur, la quantité de temps CPU consommée, et la commande qui a été lancée. &man.top.1; vous affiche par défaut la quantité d'espace mémoire utilisée par chaque processus. Cela est divisé en deux colonnes, une pour la quantité totale, et une autre pour la quantité résidente—la quantité totale représente l'espace mémoire dont a eu besoin l'application, et la quantité résidente représente l'espace qui est en fait utilisé actuellement. Dans cet exemple vous pouvez voir que &netscape; a exigé presque 30 MO de RAM, mais utilise actuellement seulement 9MO. &man.top.1; actualise l'affichage toutes les deux secondes; cela peut être modifié avec l'option . Daemons, signaux, et comment tuer un processus Quand vous utilisez un éditeur il est facile de le contrôler, de lui dire de charger des fichiers, et ainsi de suite. Vous pouvez faire cela parce que l'éditeur fournit les possibilités de le faire, et parce qu'un éditeur est attaché à un terminal. Certains programmes ne sont pas conçus pour fonctionner avec un dialogue constant avec l'utilisateur, et donc ils se déconnectent du terminal à la première occasion. Par exemple, un serveur web passe son temps à répondre aux requêtes web, il n'attend normalement pas d'entrée de votre part. Les programmes qui transportent le courrier électronique de site en site sont un autre exemple de cette classe d'application. Nous appelons ces programmes des daemons (démons). Les “daemons” étaient des personnages de la mythologie Grec; ni bon ni mauvais, c'étaient de petits esprits serviteurs qui, généralement, ont été à l'origine de choses utiles à l'humanité. Un peu comme les serveurs web ou de courrier d'aujourd'hui nous sont utiles. C'est pourquoi la mascotte BSD a été, pendant longtemps, un démon à l'apparence joyeuse portant des chaussures de tennis et une fourche. Il existe une convention pour nommer les programmes qui fonctionnent normalement en tant que daemons qui est d'utiliser une terminaison en “d”. BIND est le “Berkeley Internet Name Daemon” (et le programme réel qui est exécuté s'appelle named), le programme correspondant au serveur web Apache est appelé httpd, le daemon de gestion de la file d'attente de l'imprimante est lpd, et ainsi de suite. C'est une convention, mais pas une obligation pure et simple; par exemple le daemon principal de gestion du courrier électronique pour l'application Sendmail est appelé sendmail, et non pas maild, comme vous pourriez l'imaginer. Parfois vous devrez communiquer avec un processus daemon. Ces communications sont appelées signaux, et vous pouvez communiquez avec un daemon (ou avec tout processus en fonctionnement) en lui envoyant un signal. Il existe un certain nombre de signaux différents que vous pouvez envoyer—certains d'entre eux ont une signification précise, d'autres sont interprétés par l'application, et la documentation de l'application vous indiquera comment l'application interprète ces signaux. Vous ne pouvez envoyer de signaux qu'aux processus dont vous êtes le propriétaire. Si vous envoyez un signal à un processus appartenant à quelqu'un d'autre avec &man.kill.1; ou &man.kill.2; vous obtiendrez un refus de permission. Il existe une exception à cela: l'utilisateur root, qui peut envoyer des signaux aux processus de chacun. Dans certain cas FreeBSD enverra également aux applications des signaux. Si une application est mal écrite, et tente d'accéder à une partie de mémoire à laquelle elle n'est pas supposée avoir accès, FreeBSD envoie au processus le signal de violation de segmentation (SIGSEGV). Si une application a utilisé l'appel système &man.alarm.3; pour être avertie dès qu'une période de temps précise est écoulée alors lui sera envoyé le signal d'alarme (SIGALRM), et ainsi de suite. Deux signaux peuvent être utilisés pour arrêter un processus, SIGTERM et SIGKILL. SIGTERM est la manière polie de tuer un processus; le processus peut attraper le signal, réaliser que vous désirez qu'il se termine, fermer les fichiers de trace qu'il a peut-être ouvert, et généralement finir ce qu'il était en train de faire juste avant la demande d'arrêt. Dans certains cas un processus peut ignorer un SIGTERM s'il est au milieu d'une tâche qui ne peut être interrompue. SIGKILL ne peut être ignoré par un processus. C'est le signal “Je me fiche de ce que vous faites, arrêtez immédiatement”. Si vous envoyez un SIGKILL à un processus alors FreeBSD stoppera le processus Ce n'est pas tout à fait vrai—il y a quelques cas où les choses ne peuvent être interrompues. Par exemple, si le processus est en train d'essayer de lire un fichier qui est sur un autre ordinateur sur le réseau, et que l'autre ordinateur n'est plus accessible pour quelque raison (a été éteint, ou le réseau a un problème), alors le processus est dit “non interruptible”. Par la suite le processus entrera en pause, typiquement après deux minutes. Dès que cette pause sera effective le processus sera tué. . Les autres signaux que vous pourriez avoir envie d'utiliser sont SIGHUP, SIGUSR1, et SIGUSR2. Ce sont des signaux d'usage général, et différentes applications se comporteront différemment quand ils sont envoyés. Supposez que vous avez modifié le fichier de configuration de votre serveur web—vous voudriez dire à votre serveur web de relire son fichier de configuration. Vous pourriez arrêter et relancer httpd, mais il en résulterait une brève période d'indisponibilité de votre serveur web, ce qui peut être indésirable. La plupart des daemons sont écrits pour répondre au signal SIGHUP en relisant leur fichier de configuration. Donc au lieu de tuer et relancer httpd vous lui enverriez le signal SIGHUP. Parce qu'il n'y a pas de manière standard de répondre à ces signaux, différents daemons auront différents comportements, soyez sûr de ce que vous faites et lisez la documentation du daemon en question. Les signaux sont envoyés en utilisant la commande &man.kill.1;, comme cet exemple le montre: Envoyer un signal à un processus Cet exemple montre comment envoyer un signal à &man.inetd.8;. Le fichier de configuration d'inetd est /etc/inetd.conf, et inetd relira ce fichier de configuration quand un signal SIGHUP est envoyé. Trouvez l'identifiant du processus (PID) auquel vous voulez envoyer le signal. Faites-le en employant &man.ps.1; et &man.grep.1;. La commande &man.grep.1; est utilisée pour rechercher dans le résultat la chaîne de caractères que vous spécifiez. Cette commande est lancée en tant qu'utilisateur normal, et &man.inetd.8; est lancé en tant que root, donc les options doivent être passées à &man.ps.1;. &prompt.user; ps -ax | grep inetd 198 ?? IWs 0:00.00 inetd -wW Donc le PID d'&man.inetd.8; est 198. Dans certains cas la commande grep inetd pourrait aussi apparaître dans le résultat. C'est à cause de la façon dont &man.ps.1; recherche la liste des processus en fonctionnement. Utilisez &man.kill.1; pour envoyer le signal. Etant donné qu'&man.inetd.8; tourne sous les droits de l'utilisateur root vous devez utilisez &man.su.1; pour devenir, en premier lieu, root. &prompt.user; su Password: &prompt.root; /bin/kill -s HUP 198 Comme la plupart des commandes &unix;, &man.kill.1; n'affichera rien si la commande est couronnée de succès. Si vous envoyez un signal à un processus dont vous n'êtes pas le propriétaire alors vous verrez kill: PID: Operation not permitted. Si vous avez fait une erreur dans le PID, vous enverrez le signal soit à un mauvais processus, ce qui peut être mauvais, soit, si vous êtes chanceux, vous enverrez le signal à un PID qui n'est pas actuellement utilisé, et vous verrez kill: PID: No such process. Pourquoi utiliser <command>/bin/kill</command>? De nombreux interpréteurs de commandes fournissent la commande kill comme commande interne; c'est à dire, que l'interpréteur de commandes enverra directement le signal, plutôt que de lancer /bin/kill. Cela peut être utile, cependant les différents interpréteurs ont une syntaxe différente pour spécifier le nom du signal à envoyer. Plutôt que de tenter de les apprendre toutes, il peut être plus simple de juste employer directement la commande /bin/kill .... Envoyer d'autres signaux est très semblable, substituez juste TERM ou KILL dans la ligne de commande si nécessaire. Tuer au hasard des processus sur le système peut être une mauvaise idée. En particulier, &man.init.8;, processus à l'identifiant 1, qui est très particulier. Lancer la commande /bin/kill -s KILL 1 est une manière rapide d'arrêter votre système. Vérifiez toujours à deux fois les arguments que vous utilisez avec &man.kill.1; avant d'appuyer sur Entrée. Interpréteurs de commandes - “Shells” interpréteurs de commandes ligne de commande Sous FreeBSD, beaucoup du travail quotidien est effectué sous une interface en ligne de commande appelée interpréteur de commandes ou “shell”. Le rôle principal d'un interpréteur de commandes est de prendre les commandes sur le canal d'entrée et de les exécuter. Beaucoup d'interpréteurs de commandes ont également des fonctions intégrées pour aider dans les tâches quotidiennes comme la gestion de fichiers, le mécanisme de remplacement et d'expansion des jokers (“file globbing”), l'édition de la ligne de commande, les macros commandes, et les variables d'environnement. FreeBSD est fournit avec un ensemble d'interpréteurs de commandes, comme sh, l'interpréteur de commandes Bourne, et tcsh, l'interpréteur de commandes C-shell amélioré. Beaucoup d'autres interpréteurs de commandes sont disponibles dans le catalogue des logiciels portés, comme zsh et bash. Quel interpréteur de commandes utilisez-vous? C'est vraiment une question de goût. Si vous programmez en C vous pourriez vous sentir plus à l'aise avec un interpréteur de commandes proche du C comme tcsh. Si vous venez du monde Linux ou que vous êtes nouveau à l'interface en ligne de commande d'&unix; vous pourriez essayer bash. L'idée principale est que chaque interpréteur de commandes à des caractéristiques uniques qui peuvent ou ne peuvent pas fonctionner avec votre environnement de travail préféré, et que vous avez vraiment le choix de l'interpréteur de commandes à utiliser. Une des caractéristiques communes des interpréteurs de commandes est de pouvoir compléter les noms de fichiers (“filename completion”). En tapant les premières lettres d'une commande ou d'un fichier, vous pouvez habituellement faire compléter automatiquement par l'interpréteur de commandes le reste de la commande ou du nom du fichier en appuyant sur la touche Tab du clavier. Voici un exemple. Supposez que vous avez deux fichiers appelés respectivement foobar et foo.bar. Vous voulez effacer foo.bar. Donc ce que vous devriez taper sur le clavier est: rm fo[Tab].[Tab]. L'interpréteur de commandes devrait afficher rm foo[BEEP].bar. Le [BEEP] est la sonnerie de la console, c'est l'interpréteur de commande indiquant qu'il n'est pas en mesure de compléter totalement le nom du fichier parce qu'il y a plus d'une possibilité. foobar et foo.bar commencent tous les deux par fo, mais il fut capable de compléter jusqu'à foo. Si vous tapez ., puis appuyez à nouveau sur Tab, l'interpréteur de commandes devrait pouvoir compléter le reste du nom du fichier pour vous. variables d'environnement Une autre caractéristique de l'interpréteur de commandes est l'utilisation de variables d'environnement. Les variables d'environnement sont une paire variable-valeur stockées dans l'espace mémoire d'environnement de l'interpréteur de commandes. Cet espace peut être lu par n'importe quel programme invoqué par l'interpréteur de commandes, et contient ainsi beaucoup d'éléments de configuration des programmes. Voici une liste des variables d'environnement habituelles et ce qu'elles signifient: variables d'environnement - + Variable Description USER Le nom d'utilisateur de la personne actuellement attachée au système. PATH La liste des répertoires, séparés par deux points, pour la recherche des programmes. DISPLAY Le nom réseau de l'affichage X11 auquel on peut se connecter, si disponible. SHELL Le nom de l'interpréteur de commandes actuellement utilisé. TERM Le nom du terminal de l'utilisateur. Utilisé pour déterminer les capacités du terminal. TERMCAP L'entrée de la base de données des codes d'échappement pour permettre l'exécution de diverses fonctions du terminal. OSTYPE Type du système d'exploitation, e.g. FreeBSD. MACHTYPE L'architecture du CPU sur lequel tourne actuellement le système. EDITOR L'éditeur de texte préferé de l'utilisateur. PAGER Le visualisateur de page de texte préferré de l'utilisateur. MANPATH La liste des répertoires, séparés par deux points, pour la recherche des pages de manuel. Bourne shells Fixer une variable d'environnement diffère légèrement d'un interpréteur de commandes à l'autre. Par exemple, dans le style de l'interpréteur de commandes de type C-shell comme tcsh et csh, vous utiliseriez setenv pour fixer le contenu d'une variable d'environnement. Sous les interpréteurs de commandes Bourne comme sh et bash, vous utiliseriez export pour configurer vos variables d'environnement. Par exemple, pour fixer ou modifier la variable d'environnement EDITOR, sous csh ou tcsh une commande comme la suivante fixera EDITOR à /usr/local/bin/emacs: &prompt.user; setenv EDITOR /usr/local/bin/emacs Sous les interpréteurs de commandes Bourne: &prompt.user; export EDITOR="/usr/local/bin/emacs" Vous pouvez faire afficher à la plupart des interpréteurs de commandes la variable d'environnement en plaçant un caractère $ juste devant son nom sur la ligne de commande. Par exemple, echo $TERM affichera le contenu de $TERM, car l'interpréteur de commande complète $TERM et passe la main à echo. Les interpréteurs de commandes traitent beaucoup de caractères spéciaux, appelés métacaractères, en tant que représentation particulière des données. Le plus commun est le caractère *, qui représente zéro ou plusieurs caractères dans le nom du fichier. Ces métacaractères spéciaux peuvent être utilisés pour compléter automatiquement le nom des fichiers. Par exemple, taper echo * est presque la même chose que taper ls parce que l'interpréteur de commandes prendra tous les fichiers qui correspondent à * et les passera à echo pour les afficher. Pour éviter que l'interpréteur de commande n'interprète les caractères spéciaux, ils peuvent être neutralisés en ajoutant un caractère antislash (\) devant. echo $TERM affichera votre type de terminal. echo \$TERM affichera $TERM tel quel. Changer d'interpréteur de commandes La méthode la plus simple pour changer votre interpréteur de commandes est d'utiliser la commande chsh. En lançant chsh vous arriverez dans l'éditeur correspondant à votre variable d'environnement EDITOR; si elle n'est pas fixée, cela sera vi. Modifiez la ligne “Shell:” en conséquence. Vous pouvez également passer le paramètre à chsh; cela modifiera votre interpréteur de commandes sans avoir à utiliser un éditeur. Par exemple, si vous vouliez changer votre interpréteur de commandes pour bash, ce qui suit devrait faire l'affaire: &prompt.user; chsh -s /usr/local/bin/bash Utiliser chsh sans paramètres et modifier votre interpréteur de commandes directement à partir de là devrait également fonctionner. L'interpréteur de commandes que vous désirez utiliser doit être présent dans le fichier /etc/shells. Si vous avez installé l'interpréteur de commandes à partir du catalogue des logiciels portés, alors cela a dû déjà être fait pour vous. Si vous avez installé à la main l'interpréteur de commandes, vous devez alors le faire. Par exemple, si vous avez installé bash à la main et l'avez placé dans /usr/local/bin, vous devrez faire: &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells Puis relancer chsh. Editeurs de texte éditeurs de texte éditeurs Beaucoup de configurations sous FreeBSD sont faites en éditant des fichiers textes. Aussi ce serait une bonne idée de se familiariser avec un éditeur de texte. FreeBSD est fourni avec quelques-uns en tant qu'éléments de système de base, et beaucoup d'autres sont disponibles dans le catalogue des logiciels portés. ee L'éditeur de plus facile et le plus simple à apprendre est un éditeur appelé ee, qui signifie l'éditeur facile (easy editor). Pour lancer ee, on taperait sur la ligne de commande ee fichier où fichier est le nom du fichier qui doit être édité. Par exemple, pour éditer /etc/rc.conf, tapez ee /etc/rc.conf. Une fois sous ee, toutes les commandes pour utiliser les fonctions de l'éditeur sont affichées en haut de l'écran. Le caractère ^ représente la touche Ctrl sur le clavier, donc ^e représente la combinaison de touches Ctrle. Pour quitter ee, appuyez sur la touche Echap, ensuite choisissez “leave editor”. L'éditeur vous demandera s'il doit sauver les changements si le fichier a été modifié. vi éditeurs vi emacs éditeurs emacs FreeBSD est également fourni avec des éditeurs de texte plus puissants comme vi en tant qu'élément du système de base, alors que d'autres éditeurs, comme Emacs et vim, en tant qu'élément du catalogue des logiciels portés de FreeBSD (editors/emacs et editors/vim). Ces éditeurs offrent beaucoup plus de fonctionnalités et de puissance aux dépens d'être un peu plus compliqués à apprendre. Cependant si vous projetez de faire beaucoup d'édition de texte, l'étude d'un éditeur plus puissant comme vim ou Emacs vous permettra d'économiser beaucoup plus de temps à la longue. Périphériques et fichiers spéciaux de périphérique Un périphérique est un terme utilisé la plupart du temps pour les activités en rapport avec le matériel présent sur le système, incluant les disques, les imprimantes, les cartes graphiques, et les claviers. Quand FreeBSD démarre, la majorité de ce qu'affiche FreeBSD est la détection des périphériques. Vous pouvez à nouveau consulter les messages de démarrage en visualisant le fichier /var/run/dmesg.boot. Par exemple, acd0 est le premier lecteur de CDROM IDE, tandis que kbd0 représente le clavier. La plupart de ces périphériques sous un système d'exploitation &unix; peuvent être accédés par l'intermédiaire de fichiers appelés fichiers spéciaux de périphérique (“device node”), qui sont situés dans le répertoire /dev. Créer des fichiers spéciaux de périphérique Quand vous ajoutez un nouveau périphérique à votre système, ou compilez le support pour des périphériques supplémentaires, vous aurez peut être besoin de créer un ou plusieurs fichiers spéciaux de périphérique pour les nouveaux périphériques. MAKEDEV Script Sur les systèmes sans DEVFS (cela concerne toutes les versions de FreeBSD antérieures à la 5.0), les fichiers spéciaux de périphérique doivent être créés à l'aide de la procédure &man.MAKEDEV.8; comme montré ci-dessous: &prompt.root; cd /dev &prompt.root; sh MAKEDEV ad1 Cet exemple devrait créer les fichiers spéciaux de périphérique corrects pour le second disque IDE quand il est installé. <literal>DEVFS</literal> (“DEVice File System” - Système de fichiers de périphérique) Le système de fichiers de périphérique, ou DEVFS, fournit un accès à l'espace nom des périphériques du noyau dans l'espace nom du système de fichiers global. Au lieu d'avoir à créer et modifier les fichiers spéciaux de périphérique, DEVFS maintient ce système de fichiers particulier pour vous. Voir la page de manuel de &man.devfs.5; pour plus d'information. DEVFS est utilisé par défaut sous FreeBSD 5.0 et suivantes Le format des fichiers binaires Afin de comprendre pourquoi &os; utilise le format &man.elf.5;, vous devez d'abord connaître quelques détails concernant les trois formats “dominants” d'exécutables actuellement en vigueur sous &unix;: &man.a.out.5; Le plus vieux et le format objet “classique” d'&unix;. Il utilise une entête courte et compacte avec un nombre magique au début qui est souvent utilisé pour caractériser le format (voir la page de manuel &man.a.out.5; pour plus de détails). Il contient trois segments chargés: .text, .data, et .bss plus une table de symboles et une table de chaînes de caractères. COFF Le format objet SVR3. L'entête comprend une table de section, de telle sorte que vous avez plus de sections qu'uniquement .text, .data et .bss. &man.elf.5; Le successeur de COFF, qui permet des sections multiples et des valeurs possibles de 32 bits et 64 bits. Un inconvénient majeur: ELF a aussi été conçu en supposant qu'il y aurait qu'un seul ABI par architecture système. Cette hypothèse est en fait assez incorrecte, et même dans le monde SYSV (qui a au moins trois ABIs: SVR4, Solaris, SCO) cela ne se vérifie pas. &os; essaye de contourner ce problème en fournissant un utilitaire pour marquer un exécutable connu ELF avec des informations sur l'ABI qui va avec. Consultez la page de manuel de &man.brandelf.1; pour plus d'informations. &os; vient du camp “classique” et a utilisé le format &man.a.out.5;, une technologie employée et éprouvée à travers des générations de BSDs, jusqu'aux débuts de la branche 3.X. Bien qu'il fut possible de compiler et d'exécuter des binaires natifs ELF (et noyaux) sous &os; avant cela, &os; a initiallement résisté à la “pression” de passer à ELF comme format par défaut. Pourquoi? Bien, quand le camp Linux ont fait leur pénible transition vers ELF, ce n'est pas tant fuir le format a.out qui rendait difficile la construction de bibliothèques partagée pour les développeurs mais le mécanisme de bibliothèques partagées basé sur des tables de sauts inflexible. Puisque les outils ELF disponibles offraient une solution au problème des bibliothèques partagées et étaient perçus comme “le chemin à suivre” de toute façon, le coût de la migration a été accepté comme nécessaire, et la transition a été réalisée. Le mécanisme &os; de bibliothèques partagées se rapproche plus du style de mécanisme de bibliothèques partagées de &sunos; de Sun, et est très simple à utiliser. Pourquoi existe-t-il tant de formats différents? Dans un obscure et lointain passé, il y avait du matériel simple. Ce matériel simple supportait un simple petit système. a.out était complètement adapté pour réprésenter les binaires sur ce système simple (un PDP-11). Au fur et à mesure que des personnes portaient &unix; à partir de ce système simple, ils ont maintenus le format a.out parce qu'il était suffisant pour les premiers portages d'&unix; sur des architectures comme le Motorola 68k, les VAX, etc. Alors un certain ingénieur matériel brillant a décidé qu'il pourrait forcer le matériel à faire des choses bizarre, l'autorisant ainsi à réduire le nombre de portes logiques et permettant au coeur du CPU de fonctionner plus rapidement. Bien qu'on l'a fait fonctionner avec ce nouveau type de matériel (connu de nos jour sous le nom de RISC), a.out n'était pas adapté à ce matériel, aussi beaucoup de formats ont été développés pour obtenir de meilleures performances de ce matériel que ce que pouvait offrir le simple et limité format qu'était a.out. Des choses comme COFF, ECOFF, et quelques autres obscures formats ont été inventé et leur limites explorées avant que les choses ne se fixent sur ELF. En outre, les tailles des programmes devenaient énormes alors que les disques (et la mémoire physique) étaient toujours relativment petits, aussi le concept de bibliothèque partagée est né. Le système de VM (mémoire virtuelle) est également devenu plus sophistiqué. Tandis que chacune de ces avancées était faites en utilisant le format a.out, son utilité a été élargie de plus en plus avec chaque nouvelle fonction. De plus les gens ont voulu charger dynamiquement des choses à l'exécution, ou se débarasser de partie de leur programme après l'initialisation pour économiser de l'espace mémoire et de pagination. Les langages sont devenus plus sophistiqués et les gens ont voulu du code appelé automatiquement avant la partie principale du programme. Beaucoup de modifications ont été apportées au format a.out pour rendre possible toutes ces choses, et cela a fonctionné pendant un certain temps. Avec le temps, a.out n'était plus capable de gérer tous ces problèmes sans une augmentation toujours croissante du code et de sa complexité. Tandis ELF résolvait plusieurs de ces problèmes, il aurait été pénible de quitter un système qui a fonctionné. Ainsi ELF a dû attendre jusqu'au moment où il était plus pénible de rester avec a.out que d'émigrer vers ELF. Cependant, avec le temps, les outils de compilation desquels ceux de &os; sont dérivés (l'assembleur et le chargeur tout spécialement) ont évolué en parallèle. Les développeurs &os; ajoutèrent les bibliothèques partagées et corrigèrent quelques bogues. Les gens de chez GNU qui ont à l'origine écrit ces programmes, les récrivèrent et ajoutèrent un support plus simple pour la compilation multi-plateformes, avec différents formats à volonté, et ainsi de suite. Lorsque beaucoup de personnes ont voulu élaborer des compilateurs multi-plateformes pour &os;, elles n'eurent pas beaucoup de chance puisque les anciennes sources que &os; avait pour as et ld n'étaient pas adaptées à cette tâche. Le nouvel ensemble d'outils de GNU (binutils) supporte la compilation multi-plateformes, ELF, les bibliothèques partagées, les extensions C++, etc. De plus, de nombreux vendeurs de logiciels fournissent des binaires ELF, et c'est une bonne chose pour permettre leur exécution sous &os;. ELF est plus expressif qu'a.out et permet plus d'extensibilité dans le système de base. Les outils ELF sont mieux maintenus, et offrent un support pour la compilation multi-plateformes, ce qui est important pour de nombreuses personnes. ELF peut être légèrement plus lent qu'a.out, mais tenter de mesurer cette différence n'est pas aisé. Il y a également de nombreux détails qui diffèrent entre les deux dans la façon dont ils mappent les pages mémoire, gère le code d'initialisation, etc. Dans le futur, le support a.out sera retiré du noyau GENERIC, et par la suite retiré des sources du noyau une fois que le besoin d'exécuter d'anciens programmes a.out aura disparu. Pour plus d'information Les pages de manuel pages de manuel La documentation la plus complète sur FreeBSD est sous la forme de pages de manuel. Presque chaque programme sur le système est fournit avec un court manuel de référence expliquant l'utilisation de base et les diverses options. Ces manuels peuvent être visualisés avec la commande man. L'utilisation de la commande man est simple: &prompt.user; man command command est le nom de la commande à propos de laquelle vous désirez en savoir plus. Par exemple, pour en savoir plus au sujet de la commande ls tapez: &prompt.user; man ls Les manuels en ligne sont divisés en sections numérotées: Commandes utilisateur. Appels système et numéros d'erreur. Fonctions des bibliothèques C. Pilotes de périphérique. Formats de fichier. Jeux et autres divertissements. Information diverse. Commandes de maintenance et d'utilisation du système. Information de développement du noyau. Dans certains cas, le même sujet peut apparaître dans plus d'une section du manuel en ligne. Par exemple, il existe une commande utilisateur chmod et un appel système chmod(). Dans ce cas, vous pouvez préciser à la commande man laquelle vous désirez en spécifiant la section: &prompt.user; man 1 chmod Cela affichera la page de manuel de la commande utilisateur chmod. Les références à une section particulière du manuel en ligne sont traditionnellement placées entre parenthèses, ainsi &man.chmod.1; se rapporte à la commande utilisateur chmod et &man.chmod.2; se rapporte à l'appel système. C'est parfait si vous connaissez le nom de la commande et vous souhaitez simplement savoir comment l'utiliser, mais qu'en est-il si vous ne pouvez pas vous rappelez du nom de la commande? Vous pouvez utiliser man pour rechercher des mots-clés dans les descriptions de commandes en employant l'option : &prompt.user; man -k mail Avec cette commande on vous affichera la liste des commandes qui ont le mot-clé “mail” dans leurs descriptions. C'est en fait équivalent à l'utilisation de la commande apropos. Ainsi, vous regardez toutes ces commandes fantaisistes contenues dans /usr/bin mais vous n'avez pas la moindre idée de ce quelles font vraiment? Faites simplement: &prompt.user; cd /usr/bin &prompt.user; man -f * ou &prompt.user; cd /usr/bin &prompt.user; whatis * ce qui fait la même chose. Fichiers GNU Info Free Software Foundation Fondation pour le Logiciel Libre FreeBSD inclut beaucoup d'applications et d'utilitaires produit par la Fondation pour le Logiciel Libre ( Free Software Foundation). En plus des pages de manuel, ces programmes sont fournis avec des documents hypertexte appelés fichiers info qui peuvent être lus avec la commande info ou, si vous avez installé emacs, dans le mode info d'emacs. Pour utiliser la commande &man.info.1;, tapez simplement: &prompt.user; info Pour une brève introduction, tapez h. Pour une référence rapide sur la commande, tapez ?. diff --git a/fr_FR.ISO8859-1/books/handbook/config/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/config/chapter.sgml index 92ec40718e..3ef74c442d 100644 --- a/fr_FR.ISO8859-1/books/handbook/config/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/config/chapter.sgml @@ -1,3641 +1,3641 @@ Chern Lee Ecrit par Mike Smith Basé sur un guide rédigé par Matt Dillon Egalement basé sur la page de manuel tuning(7) écrite par Configuration et optimisation &trans.a.fonvieille; Synopsis configuration du système optimisation du système 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: Pourquoi et comment dimensionner, organiser, et positionner efficacement les partitions des systèmes de fichiers et de pagination sur votre disque dur. 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 (). Etre familier avec la configuration et la compilation du noyau (). Configuration initiale Organisation des partitions organisation des partitions /etc /var /usr Partitions de base Quand vous organisez votre système de fichiers à l'aide de &man.disklabel.8; ou &man.sysinstall.8;, il est important de se rappeler que les disques durs peuvent transférer des données plus rapidement depuis les pistes externes que depuis celles à l'intérieur. En sachant cela, vous devriez placer vos systèmes de fichiers les plus petits, auxquels on accède le plus souvent, comme la racine et l'espace de pagination, proche de la partie externe du disque, alors que les grandes partitions, comme /usr, devraient être plus à l'intérieur. Pour faire cela, c'est une bonne idée de créer les partitions dans l'ordre suivant: racine, pagination, /var, /usr. La taille de votre partition /var reflète l'utilisation prévue de votre machine. /var est principalement utilisée pour héberger les boîtes aux lettres, les fichiers journaux, les queues d'impression. Les boîtes aux lettres et les fichiers journaux, en particulier, peuvent croître vers des tailles inattendues en fonction du nombre d'utilisateurs de votre système et de combien de temps sont conservés ces fichiers. Si vous avez l'intention de faire fonctionner un serveur de courrier électronique, une partition La plupart des utilisateurs n'auront jamais besoin de plus d'un gigaoctet, mais rappelez-vous que /var/tmp doit être assez grand pour contenir tout logiciel pré-compilé que vous pourrez vouloir ajouter. La partition /usr contient la majeure partie des fichiers nécessaires au système, le catalogue des logiciels portés (recommandé) et le code source du système (optionnel). Les deux étant optionnels à l'installation. Utiliser au moins 2 gigaoctets pour cette partition est recommandé. Quand vous dimensionnez vos partitions, gardez à l'esprit les besoins en espace pour permettre à votre système de se développer. Manquer d'espace sur une partition alors qu'il y en a plein sur les autres peut être très frustrant. Certains utilisateurs qui ont employé l'option Auto-defaults de l'outil de partitionnement de &man.sysinstall.8; ont trouvé plus tard que leurs partitions racine et /var étaient trop petites. Partitionnez généreusement et avec sagesse. Partition de pagination dimensionnement de l'espace de pagination partition de pagination Par principe, votre espace de pagination devrait typiquement avoir une taille double de la quantité de mémoire principale. Par exemple, si la machine possède 128 mégaoctets de mémoire, le fichier de pagination devrait être de 256 mégaoctets. Les systèmes avec peu de mémoire pourront avoir de meilleures performances avec beaucoup plus d'espace de pagination. Il n'est pas recommandé d'avoir moins de 256 mégaoctets d'espace de pagination sur un système et vous devriez garder à l'esprit les futures extensions de mémoire quand vous dimensionnez votre partition de pagination. Les algorithmes de pagination du noyau sont optimisés pour une meilleure efficacité avec une partition de pagination d'au moins deux fois la taille de la mémoire principale. Configurer trop peu d'espace de pagination peut conduire à une certaine inefficacité du code de pagination de la mémoire virtuelle comme à l'apparition de problèmes ultérieurement si vous ajoutez plus de mémoire à votre machine. Et enfin, sur des systèmes importants avec de multiples disques SCSI (ou de multiples disques IDE fonctionnant sur différents contrôleurs), il est vivement recommandé que vous configuriez un espace de pagination sur chaque disque (jusqu'à quatre disques). Les partitions de pagination sur les différents disques devront avoir approximativement la même taille. Le noyau peut gérer des tailles arbitraires mais les structures de données internes sont dimensionnées pour 4 fois la taille de la plus grande partition de pagination. Garder la taille des partitions de pagination proche permettra au noyau de répartir de manière optimale l'espace de pagination entre les disques. Ne vous inquiétez pas trop si vous les surdimensionnez, l'espace de pagination est un des avantages d'Unix. Même si vous n'utilisez normalement pas beaucoup de cet espace, il peut vous permettre d'avoir plus temps pour récupérer face à programme incontrôlable avant d'être forcé à relancer la machine. Pourquoi des Partitions? Pourquoi des partitions? Pourquoi ne pas créer une seule grande partition racine? Ainsi je n'aurais pas à me soucier d'avoir sous-dimensionné certaines choses! Pour plusieurs raisons cela n'est pas une bonne idée. Tout d'abord, chaque partition a différentes caractéristiques d'utilisation et les séparer autorise le système de fichiers à s'optimiser lui-même pour ces caractéristiques. Par exemple, les partitions racine et /usr sont surtout lues, et rarement utilisées en écriture, alors que de nombreuses opérations de lecture et écriture pourront avoir lieu sur /var et /var/tmp. En partitionnant correctement votre système, la fragmentation introduite sur les partitions plus petites et plus chargées en écriture ne s'étendra pas sur les partitions principalement utilisées en lecture. De plus, avoir les partitions principalement utilisées en écriture proche du bord du disque, par exemple avant la grande partition au lieu qu'après dans la table des partitions, augmentera les performances d'E/S sur les partitions qui le demandent le plus. Maintenant il est également vrai que vous avez besoin de performances d'E/S sur les grandes partitions, mais elles sont si grandes que les déplacer plus vers l'extérieur du disque ne donnera pas lieu à une augmentation significative des performances alors que le déplacement de /var vers le bord peut avoir un sérieux impact. Et enfin, il y a également des raisons de sécurité. Avoir une partition racine petite et ordonnée qui est essentiellement en lecture seule lui donne plus de chance de rester intacte après un crash sévère. Configuration principale fichiers rc rc.conf 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 un autre fichier comme /etc/rc.conf.site, puis ensuite inclure ce fichier dans /etc/rc.conf, qui ne contiendra seulement que les informations spécifiques au système. Comme rc.conf est lu par &man.sh.1; il est assez trivial d'effectuer cela. Par exemple: rc.conf: . rc.conf.site hostname="node15.example.com" network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 10.1.1.1" rc.conf.site: defaultrouter="10.1.1.254" saver="daemon" blanktime="100" Le fichier rc.conf.site peut être distribué à l'ensemble des systèmes en utilisant rsync ou un programme semblable, tandis que le fichier rc.conf reste unique. Mettre à jour le système en employant &man.sysinstall.8; ou make world n'écrasera pas le fichier rc.conf, les informations de configuration du système ne seront donc pas perdues. 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. /usr/local/etc 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é. Tom Rhodes Contribution de Démarrer des services services Nombreux sont les utilisateurs qui choisissent d'installer des logiciels tierce partie sous &os; à 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/apache13 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 &os;, la plupart des services offerts, comme &man.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 &os,; 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. Avant l'avènement du système rcNG, les applications plaçaient une procédure simple de lancement dans le répertoire /usr/local/etc/rc.d qui était + class="directory">/usr/local/etc/rc.d qui était lue par les scripts d'initialisation du système. Ces procédures étant alors exécutées lors des dernières étapes du démarrage du système. Bien que de nombreuses personnes aient passé des heures à tenter de fusionner l'ancien mode de configuration avec le nouveau, il reste que certains utilitaires tierce partie ont toujours besoin d'un script placé dans le répertoire précédemment évoqué. Les différences subtiles dans les scripts dépend de si le système rcNG est utilisé ou non. Avant &os; 5.1 l'ancien style de configuration était utilisé et dans presque tous les cas la nouvelle procédure fonctionnera sans problème. Bien que chaque procédure doit remplir certains pré-requis minimum, la plupart du temps ils seront indépendants de la version de &os;. Chaque procédure doit avoir une extension .sh et doit être exécutable par le système. Ce dernier point peut être réalisé en utilisant la commande chmod et en fixant les permissions à 755. Il doit y avoir, au minimum, une option pour démarrer (start) l'application et une autre pour l'arrêter (stop). La procédure de démarrage la plus simple ressemblera à celle-ci: #!/bin/sh echo -n ' utility' case "$1" in start) /usr/local/bin/utility ;; stop) kill -9 `cat /var/run/utility.pid` ;; *) echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0 Cette procédure offre des options stop et start pour une application appelée ici utility. Cette application pourra alors avoir la ligne suivante la concernant dans le fichier /etc/rc.conf: utility_enable="YES" L'application pourra être lancée manuellement avec: &prompt.root; /usr/local/etc/rc.d/utility.sh start Bien que toutes les applications tierce partie ne nécessitent pas de ligne dans le fichier rc.conf, chaque jour un nouveau logiciel porté sera modifié pour accepter cette configuration. Contrôlez l'affichage final lors de l'installation de l'application pour plus d'information à ce sujet. Certains logiciels fourniront des procédures qui permettrons à l'application d'être utilisée avec le système rcNG, cela sera abordé dans la section suivante. Configuration étendue des applications Maintenant que &os; dispose du système rcNG, la configuration du démarrage des applications est plus aboutie, en effet elle propose plus de possibilités. En utilisant les mots clés présentés dans la section sur le système rcNG, 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 # BEFORE: LOGIN # KEYWORD: FreeBSD shutdown # # DO NOT CHANGE THESE DEFAULT VALUES HERE # SET THEM IN THE /etc/rc.conf FILE # utility_enable=${utility_enable-"NO"} utility_flags=${utility_flags-""} utility_pidfile=${utility_pidfile-"/var/run/utility.pid"} . /etc/rc.subr name="utility" rcvar=`set_rcvar` command="/usr/local/sbin/utility" load_rc_config $name pidfile="${utility_pidfile}" start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utility_flags} ${command_args}" run_rc_command "$1" Cette procédure s'assurera que l'application utility sera lancée avant le service login mais après le service daemon. Elle fournie également une méthode de suivi du PID, ou encore ID (identifiant) de processus. Cette nouvelle 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 &man.rcorder.8; et fournie une configuration plus aisée par l'intermédiaire du fichier rc.conf. Dans l'état actuel, cette procédure pourrait même être placée dans le répertoire /etc/rc.d. Cependant, cela pourra + class="directory">/etc/rc.d. Cependant, cela pourra déranger l'utilitaire &man.mergemaster.8; lors de mise à jour logicielles. Utiliser des services pour démarrer d'autres services Certains services, comme les serveurs POP3, IMAP, etc., peuvent être démarrés en utilisant &man.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 &man.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 &man.cron.8; est lancé, normalement lors de l'initialisation du système. Tom Rhodes Contribution de Configuration de l'utilitaire <command>cron</command> cron configuration Un des utilitaires les plus importants de &os; est &man.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 + class="directory">/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. La seule différence entre ces deux formats est le sixième champ. Dans le fichier crontab système, le sixième champ est le nom de l'utilisateur sous lequel doit être exécutée la commande. Cela donne la possibilité au fichier crontab système d'exécuter les commandes sous n'importe quel utilisateur. Dans le fichier crontab d'un utilisateur, le sixième champ est la commande a exécuter et toutes les commandes sont exécutées sous l'utilisateur qui a créé le fichier crontab; c'est un aspect sécurité important. 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). En raison de l'existence du fichier crontab système, 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 &os; # # $&os;: 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 &os;, 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. Quand un utilisateur installe son fichier crontab, il n'aura pas cette option. Pour finir, l'option commande est listée. C'est le dernier champ, qui naturellement devrait désigner 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épendemment du jour ou du mois. Pour plus d'informations sur la commande atrun, consultez la page de manuel de &man.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. Installer un fichier crontab Vous ne devez pas utiliser la procédure décrite ci-dessous pour éditer/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 fraichement 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: &prompt.root; 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 à 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. Si vous désirez plus tard effacer votre crontab utilisateur complètement, utilisez la commande crontab avec l'option . Tom Rhodes Contribution de Utilisation du système rc sous &os; 5.X rcNG Le système rc.d de NetBSD pour l'initialisation du système a récemment été intégré à &os;. Les utilisateurs noteront les fichiers présents dans le répertoire /etc/rc.d. Plusieurs de ces + class="directory">/etc/rc.d. Plusieurs de ces fichiers sont destinés aux services de base qui peuvent être contrôlés avec les options , , et . Par exemple, &man.sshd.8; peut être relancé avec la commande suivante: &prompt.root; /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 dès qu'ils sont spécifiés dans le fichier &man.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 est déjà présente, modifiez alors le par . 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 , et 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 à 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 “force”. Par exemple pour redémarrer sshd indépendemment du paramétrage du fichier /etc/rc.conf, exécutez la commande suivante: &prompt.root; /etc/rc.d/sshd forcerestart 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 . Ainsi, un administrateur peut contrôler que sshd est réellement activé dans /etc/rc.conf en exécutant: &prompt.root; /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 est disponible. Par exemple pour vérifier que sshd a réellement été lancé: &prompt.root; /etc/rc.d/sshd status sshd is running as pid 433. Il est également possible de recharger un service avec l'option . 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. La structure rcNG 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 &man.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 peuvent être présents en tête de chaque fichier de démarrage: PROVIDE: indique les services que fournit ce fichier. 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. KEYWORD: &os; ou NetBSD. Ceci est utilisé pour des fonctionnalités propres au système d'exploitation. En utilisant ce système, un administrateur peut facilement contrôler les services du système sans avoir à se battre avec les “runlevels” comme sur d'autres systèmes d'exploitation &unix;. Des informations supplémentaires concernant le système rc.d de &os; 5.X peuvent être trouvées dans les pages de manuel &man.rc.8; et &man.rc.subr.8;. Marc Fonvieille Contribution de Configuration des cartes réseaux 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. Déterminer le bon pilote de périphérique configuration des cartes réseaux déterminer le 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. Le fichier /usr/src/sys/i386/conf/LINT vous donnera 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 dc0: Ethernet address: 00:a0:cc:da:da:da miibus0: <MII bus> on dc0 ukphy0: <Generic IEEE 802.3u media interface> on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 dc1: Ethernet address: 00:a0:cc:da:da:db miibus1: <MII bus> on dc1 ukphy1: <Generic IEEE 802.3u media interface> on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Dans cet exemple, nous voyons que deux cartes utilisant le pilote de périphérique &man.dc.4; sont présentes sur le système. Pour utiliser votre carte réseau, vous devrez charger le pilote de périphérique correct. Cela peut être accompli de deux façons. La plus simple est de charger le module pour votre carte réseau avec &man.kldload.8;. Un module n'est pas disponible pour toutes les cartes réseaux (les cartes ISA ou celles utilisant le pilote &man.ed.4;, par exemple). Alternativement, vous pouvez compiler en statique le support pour votre carte dans votre noyau. Consultez /usr/src/sys/i386/conf/LINT et la page de manuel du pilote de périphérique pour savoir ce qu'il faut ajouter à votre fichier de configuration de votre noyau. Pour plus d'information sur la recompilation de votre noyau, veuillez lire le . Si votre carte a été détectée au démarrage par votre noyau (GENERIC) vous n'avez pas à compiler un nouveau noyau. Configuration de la carte réseau configuration des cartes réseaux configuration 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: &prompt.user; ifconfig dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:a0:cc:da:da:da media: Ethernet autoselect (100baseTX <full-duplex>) status: active dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:a0:cc:da:da:db media: Ethernet 10baseT/UTP status: no carrier lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 D'anciennes versions de FreeBSD pourront nécessiter l'option après &man.ifconfig.8;, pour plus de détails au sujet de la syntaxe d'&man.ifconfig.8;, veuillez vous référer à la page de manuel. Notez également que les entrées concernant l'IPv6 (inet6 etc...) ont été omises dans cet exemple. Dans cet exemple, les périphériques suivants ont été affichés: dc0: La première interface Ethernet dc1: La seconde interface Ethernet lp0: L'interface du port parallèle lo0: L'interface “en boucle” (“loopback”) tun0: L'interface “tunnel” utilisée par ppp 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 &man.sis.4;. Dans cet exemple, le périphérique dc0 est actif et en fonctionnement. Les indicateurs importants sont: UP signifie que la carte est configurée et prête. La carte possède une adresse Internet (inet) (dans ce cas-ci 192.168.1.3). Elle a un masque de sous-réseau valide (netmask; 0xffffff00 est équivalent à 255.255.255.0). Elle a une adresse de diffusion valide (dans ce cas-ci 192.168.1.255). L'adresse MAC de la carte (ether) est 00:a0:cc:da:da:da 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. 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 &man.ifconfig.8; est similaire à: dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 ether 00:a0:cc:da:da:da 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 &man.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'&man.ifconfig.8; pour plus de détails sur les options autorisées et également la page de manuel de &man.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 &man.hosts.5; et au fichier /usr/share/examples/etc/hosts. 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. Une fois que le système a été redémarré, vous devrez tester les interfaces réseau. Tester la carte Ethernet configuration des cartes réseaux test de la carte 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: &prompt.user; 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 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 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: &prompt.user; ping -c5 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms --- 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. Dépannage configuration des cartes réseaux 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 &os;? Consultez toujours les notes concernant le matériel avant d'envoyer un rapport de bogue. Mettez à jour votre version de &os; 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 &man.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 . 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 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 &man.tuning.7;. Hôtes virtuels hôtes virtuels alias IP 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 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" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" Fichiers de configuration Organisation du répertoire <filename>/etc</filename> 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 &man.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 &man.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. Nom d'hôtes nom d'hôte DNS <filename>/etc/resolv.conf</filename> 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: - + nameserver L'adresse IP du serveur de noms auquel le résolveur devrait envoyer ses requêtes. 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, &man.dhclient.8; réécrit habituellement resolv.conf avec l'information reçue du serveur DHCP. <filename>/etc/hosts</filename> 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 &man.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. # 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 myname.my.domain 127.0.0.1 localhost localhost.my.domain myname.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. PLEASE PLEASE PLEASE do not try # to invent your own network numbers but instead get one from your # network provider (if any) or from the Internet Registry (ftp to # rs.internic.net, directory `/templates'). # /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 &man.hosts.5; pour plus d'informations. Configuration des fichiers de trace fichiers de trace <filename>syslog.conf</filename> syslog.conf syslog.conf est le fichier de configuration du programme &man.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 &man.syslog.conf.5; pour plus d'informations. <filename>newsyslog.conf</filename> newsyslog.conf newsyslog.conf est le fichier de configuration de &man.newsyslog.8;, un programme qui est normalement programmé &man.cron.8; pour s'exécuter périodiquement. &man.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 &man.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 &man.newsyslog.8; pour plus d'informations. <filename>sysctl.conf</filename> sysctl.conf sysctl 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. Un exemple de sysctl.conf désactivant la trace signaux fatals de fin de processus et faisant savoir aux programmes Linux qu'ils tournent sous FreeBSD. kern.logsigexit=0 # Do not log fatal signal exits (e.g. sig 11) compat.linux.osname=FreeBSD compat.linux.osrelease=4.3-STABLE Optimisation avec sysctl sysctl optimisation avec sysctl &man.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 à &man.sysctl.8;. &man.sysctl.8; remplit deux fonctions: lire et modifier les paramétrages du système. Pour afficher toutes les variables lisibles: &prompt.user; sysctl -a Pour lire une variable particulière, par exemple, kern.maxproc: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 Pour fixer une variable particulière, utilisez la syntaxe intuitive variable=valeur : &prompt.root; 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 &man.sysctl.conf.5; et la . Tom Rhodes Contribution de Variables &man.sysctl.8; en lecture seule Dans certains cas, il peut être nécessaire de modifier des variables &man.sysctl.8; en lecture seule. Bien que cela n'est pas recommandé, c'est parfois inévitable. Par exemple sur certains modèles d'ordinateurs portables le périphérique &man.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 &man.sysctl.8; par défaut qui sont en lecture seule. Pour palier à ces situations un utilisateur peut placer un paramétrage (“OID”—Object IDentifier) &man.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 dans le fichier précédemment indiqué. Désormais le périphérique &man.cardbus.4; devrait fonctionner normalement. Optimiser les disques Les variables sysctl <varname>vfs.vmiodirenable</varname> 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. <varname>vfs.write_behind</varname> 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. <varname>vfs.hirunningspace</varname> 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. Depuis &os; 4.3, le système VM effectue un très bon travail d'auto-optimisation. <varname>vm.swap_idle_enabled</varname> 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. <varname>hw.ata.wc</varname> 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 &man.ata.4;. <literal>SCSI_DELAY</literal> (<varname>kern.cam.scsi_delay</varname>) 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). Les versions de &os; récentes (5.0 et suivantes) devraient utiliser l'option de démarrage kern.cam.scsi_delay. Cette option de démarrage et celle de configuration du noyau acceptent des valeurs en millisecondes et non pas en secondes. Les “Soft Updates” Soft Updates tunefs Le programme &man.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: &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem Un système de fichiers ne peut être modifié avec &man.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. Depuis FreeBSD 4.5, il est possible d'activer les “Soft Updates” au moment de la création du système de fichiers, avec l'utilisation de l'option -U de la commande &man.newfs.8;. 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. Plus de détails à propos des “Soft Updates” Soft Updates détails 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, &man.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 &man.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”. &man.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, &man.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. Optimisation des limitations du noyau Optimisation limitations du noyau Limitations sur les fichiers et les processus <varname>kern.maxfiles</varname> 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. La valeur par défaut de kern.maxfile est fixée par l'option dans votre fichier de configuration du noyau. kern.maxfiles augmente proportionnellement avec la valeur de . 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. A partir de FreeBSD 4.5, positionner à 0 dans votre fichier de configuration du noyau, le système choisira une valeur raisonnable par défaut basée sur la quantité de mémoire présente sur votre système. <varname>kern.ipc.somaxconn</varname> 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 environement 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. &man.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 (DoS). 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 recommendons 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 de &man.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 &os; 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 &man.sendfile.2;, il peut être nécessaire d'augmenter le nombre de tampons &man.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 &man.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 &man.sendfile.2; sur la socket non-bloquante peut résulter en un blocage de l'appel &man.sendfile.2; jusqu'à ce que suffisament de struct sf_buf soient libérées. <varname>net.inet.ip.portrange.*</varname> net.inet.ip.portrange.* Les variables net.inet.ip.portrange.* contrôlent les intervalles de ports automatiquement alloués aux sockets 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 est conseillé de diminuer net.inet.ip.portrange.first. Le produit délai-bande passante TCP limitation du produit délai-bande passante TCP net.inet.tcp.inflight_enable 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édiare 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 minimas é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. 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. Espace de pagination sur un nouveau disque dur La meilleur façon d'ajouter de l'espace de pagination, bien sûr, est d'utiliser ceci comme excuse pour ajouter un autre disque dur. Vous pouvez toujours utiliser un autre disque après tout. Si vous pouvez faire cela, allez relire la discussion sur l'espace de pagination dans la du Manuel pour des suggestions sur la meilleure façon d'arranger votre espace de pagination. 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. Avoir son espace de pagination sur NFS sera lent et inefficace sur les versions de FreeBSD antérieures à la branche 4.X. c'est raisonnablement rapide et efficace sur 4.0-RELEASE et suivante. Même avec une version récente de FreeBSD, la pagination sur NFS sera limitée par la bande passante du réseau et sera un fardeau supplémentaire pour le serveur NFS. 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. Créer un fichier de pagination sous FreeBSD 4.X Soyez sûr que votre configuration de noyau inclut le pilote vnode. Ce n'est pas le cas dans les versions récentes de GENERIC. pseudo-device vn 1 #Vnode driver (turns a file into a device) Créez un périphérique vn: &prompt.root; cd /dev &prompt.root; sh MAKEDEV vn0 Créez un fichier de pagination (/usr/swap0): &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Fixez les bonnes permissions sur /usr/swap0: &prompt.root; chmod 0600 /usr/swap0 Activez le fichier de pagination dans /etc/rc.conf: swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. Redémarrez la machine ou activez directement le fichier de pagination: &prompt.root; vnconfig -e /dev/vn0b /usr/swap0 swap Créer un fichier de pagination sous FreeBSD 5.X Assurez-vous que votre configuration de noyau inclut le pilote de disque mémoire (&man.md.4;). Il se trouve par défaut dans le noyau GENERIC. device md # Memory "disks" Créez un fichier de pagination (/usr/swap0): &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Fixez les bonnes permissions sur /usr/swap0: &prompt.root; chmod 0600 /usr/swap0 Activez le fichier de pagination dans /etc/rc.conf: swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. Redémarrez la machine ou activez directement le fichier de pagination: &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 Hiten Pandya Ecrit par Tom Rhodes Gestion de l'énergie et des ressources Il est vraiment important d'utiliser les ressources matérielles d'une manière efficace. Avant l'apparition de l'ACPI, il était très 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 contrôlé par certaines interfaces du BIOS, comme le système Plug and Play BIOS (PNPBIOS), l'Advanced Power Management (APM) et ainsi de suite. 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 eventuellement 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. Soyez conscient que l'ACPI est disponible sur les systèmes FreeBSD 5.X et suivants par défaut sous la forme d'un module noyau. Sous &os; 4.9, l'ACPI peut être activé en ajoutant la ligne device acpica à la configuration du noyau et en le recompilant. 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” actuelles (comme l'APM, qui est utilisé sous FreeBSD 4.X), avant l'apparition de l'ACPI. L'ACPI est le descendant direct de l'APM (Advanced Power Management - gestion avancée de l'énergie). 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 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èment, 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 suffisament 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 &os; est documenté dans la page de manuel &man.apm.4;. Configurer l'<acronym>ACPI</acronym> Le pilote acpi.ko est par défaut chargé par le &man.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 n'est pas très utile, et dans certain cas peut même être fatal. Dans le doute, 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é avec l'utilitaire &man.acpiconf.8;. En fait la plupart des interactions avec ACPI peuvent être effectuées via &man.acpiconf.8;. A la base cela signifie que si quelque chose en rapport avec l'ACPI apparaît dans la sortie de &man.dmesg.8;, alors c'est déjà en fonctionnement. L'ACPI et l'APM ne peuvent coéxister et devraient être utilisé séparément. Le dernier chargé s'arrêtera s'il détecte l'autre en focntionnement. Dans sa plus simple forme, l'ACPI peut être utilisé pour mettre en veille un système avec &man.acpiconf.8;, les options et 1-5. La plupart des utilisateurs n'auront besoin que de 1. L'option 5 provoquera un arrêt de l'alimentation par logiciel, effet identique à un: &prompt.root; halt -p D'autres options sont disponibles. Consultez la page de manuel d'&man.acpiconf.8; pour plus d'informations. Nate Lawson Ecrit par Peter Schultz Avec la collaboration de Tom Rhodes Utiliser et déboguer l'<acronym>ACPI</acronym> sous &os; 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 &os;, 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 &os; à 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. 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 manisfester s'il est nouveau. La sortie de &man.dmesg.8; après un boot -v, y compris tout message généré lors de la manifestation du bogue. La sortie de &man.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: &prompt.root; acpidump -t -d > 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 &a.current; mais soumettez également les problèmes rencontrés à la liste &a.acpi.name; 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 &man.send-pr.1;. Quand vous remplirez un PR, veillez à inclure les mêmes informations que celles précisées précedemment. Cela nous aidera à cerner et à résoudre le problème. N'envoyez pas de PR sans avoir contacté auparavant la liste &a.acpi.name; é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. 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 accèptent des informations en provenance du sous-système ACPI. Pour &os;, &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 + class="directory">src/sys/contrib/dev/acpica. Le code glu permettant à ACPI-CA de fonctionner sous &os; 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. + class="directory">src/sys/dev/acpica. 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. 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 é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 &a.acpi.name; 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. 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 à 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 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 &os; et déterminer quel pilote est responsable des disfonctionnements nous aidera à corriger le problème. Notez que les personnes qui maintiennent l'ACPI sous &os; 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 &a.current.name; et communiqué au responsable du pilote. Si vous vous sentez une âme d'aventurier, commencez à ajouter des &man.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. 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 ALTESC 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. 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 ) ou la configuration d'une partition &man.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 . Consultez la page de manuel &man.acpi.4; pour des exemples. 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 &man.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. 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. <acronym>ASL</acronym>, <command>acpidump</command>, et <acronym>IASL</acronym> 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 innofensifs 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 &man.acpidump.8;. Vous devriez utiliser de paire les options (qui affiche le contenu des tables fixes) et (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: &prompt.root; iasl your.asl Correction de votre <acronym>ASL</acronym> 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 µsoft; (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 µsoft; et les reproduire de manière à permettre à &os; 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 &man.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: Dépendances _OS Certains AMLs supposent que le monde n'est fait de que différentes versions de &windows;. Vous pouvez demander à &os; 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. <errorname>Missing Return statements</errorname> Certaines méthodes ne renvoient pas explicitement une valeur comme la norme le demande. Bien qu'ACPI-CA ne gère pas cela, &os; 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 . Remplacer l'<acronym>AML</acronym> par défaut Après avoir personnalisé votre.asl, vous voudrez le compiler, pour cela exécutez: &prompt.root; iasl your.asl Vous pouvez ajouter l'option 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. + /boot. Obtenir d'<acronym>ACPI</acronym> 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 &man.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 noayu. 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: &prompt.root; 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 + class="directory">/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 évenement 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. Références Plus d'information au sujet de l'ACPI peut être trouvé aux emplacements suivants: La liste de diffusion &a.acpi; Les archives de la liste de diffusion ACPI Les archives de l'ancienne liste de diffusion ACPI La spécification ACPI 2.0 Les pages de manuel: &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;, &man.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.) diff --git a/fr_FR.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/cutting-edge/chapter.sgml index 308b79c949..3c18e5beb7 100644 --- a/fr_FR.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,2202 +1,2202 @@ Jim Mock Restructuré, réorganisé, et en partie mis à jour par Jordan Hubbard Travail original de Poul-Henning Kamp John Polstra Nik Clayton Questions avancées &trans.a.fonvieille; Synopsis &os; est en constant développement entre deux versions. Pour ceux désirant toujours être à jour, il existe plusieurs mécanismes simples pour maintenir votre système synchronisé avec les derniers développements. Soyez prévenus—cela ne s'adresse pas à tout le monde! Ce chapitre vous aidera à décider si vous voulez suivre les développements, ou vous en tenir aux versions publiées. Après la lecture de ce chapitre, vous connaîtrez: La différence entre les deux branches de développement: &os.stable; et &os.current;. Comment maintenir votre système à jour avec CVSup, CVS, ou CTM. Comment recompiler et réinstaller l'intégralité du système de base avec la commande make buildworld (etc.). Avant de lire ce chapitre, vous devrez: Correctement configurer votre connexion réseau (). Savoir comment installer des logiciels tiers (). &os.current; contre &os.stable; -CURRENT -STABLE Il existe deux branches de développement de FreeBSD: &os.current; et &os.stable;. Cette section détaillera un peu chacune d'elles et décrira comment garder à jour votre système avec chaque arborescence respective. &os.current; sera tout d'abord traité, suivit de &os.stable;. Se synchroniser avec la version -CURRENT de &os; En lisant ces lignes, gardez à l'esprit que &os.current; représente “les tout derniers” développement de &os;. On attend des utilisateurs de &os.current; un degré élevé de compétences techniques, et devraient être capables de résoudre des problèmes système compliqués par eux-mêmes. Si vous êtes nouveau à &os;, pensez à deux fois avant de l'installer. Qu'est-ce que &os.current;? instantané &os.current; est la toute dernière version des sources de &os; en cours de développement. Cela inclut des évolutions en cours, des modifications expérimentales, et des mécanismes de transition qui feront ou ne feront pas partie de la prochaine version officielle du logiciel. Bien que de nombreux développeurs de &os; compilent les sources de &os.current; quotidiennement, il arrive que celles-ci ne soient pas compilables pendant une certaine période de temps. Ces problèmes sont résolus aussi rapidement que possible, mais que &os.current; soit à l'origine d'un désastre ou de l'apport d'une nouvelle fonctionnalité attendue peut parfois dépendre que du moment auquel vous avez chargé le code source. Qui a besoin de &os.current;? &os.current; est mis à disposition pour 3 types de personnes: - Les membres du groupe &os; qui travaillent + Les membres de la communauté &os; qui travaillent activement sur une partie de l'arborescence des sources et pour qui rester constamment à jour est une nécessité absolue. - Les membres du groupe &os; qui participent + Les membres de la communauté &os; qui participent activement aux tests et sont disposés à passer du temps à résoudre les problèmes pour garantir que &os.current; reste aussi saine que possible. Il y a également ceux qui désirent faire des suggestions dans certains domaines sur les modifications à faire et la direction générale que prend &os;, et soumettent des correctifs pour les implémenter. Ceux qui veulent simplement garder un oeil sur les évolutions, ou utiliser les dernières sources comme référence (e.g. pour les lire, et non pour les utiliser). Ces personnes font parfois des remarques ou contribuent au code. Qu'est-ce que <emphasis>n'est pas</emphasis> &os.current;? Un raccourci pour se procurer des pré-versions parce que vous avez entendu dire qu'il y a de nouvelles fonctionnalités géniales et que vous voulez être le premier du coin à les avoir. Etre le premier à avoir la nouvelle fonctionnalité signifie être le premier à avoir les nouveaux bogues également. Une moyen rapide d'avoir des corrections de bogues. N'importe quelle version de &os.current; apportera probablement de nouveaux bogues comme elle corrigera ceux déjà présents. Nous ne le “supportons officiellement” en aucun cas. Nous faisons du mieux que nous pouvons pour aider les personnes qui font vraiment partie des trois groupes “légitimes” à qui s'adresse &os.current;, mais nous n'avons tout simplement “pas le temps” de fournir un support technique. Ce n'est pas parce que nous sommes des personnes détestables qui n'aiment pas aider les autres (nous ne ferions pas &os; si tel était le cas), nous ne pouvons simplement pas répondre à des centaines de messages par jour et travailler sur FreeBSD! Entre améliorer &os; et répondre à de nombreuses questions sur le code expérimental, les développeurs optent pour le premier choix. Utiliser &os.current; -CURRENT utilisation Inscrivez-vous à la &a.current; et la &a.cvsall;. Ce n'est pas seulement une bonne idée, c'est indispensable. Si vous n'êtes pas sur la liste &a.current.name;, vous ne verrez pas les commentaires qui sont faits sur l'état courant du système et vous vous retrouverez probablement confrontés à de nombreux problèmes que d'autres ont déjà identifiés et résolus. Encore plus grave, vous manqueriez des bulletins importants potentiellement critiques pour la bonne santé de votre système. La liste &a.cvsall.name; vous permettra de voir les courriers de trace des soumissions de toutes les modifications dès qu'elles sont faites et des informations pertinentes sur les éventuels effets de bord. Pour vous inscrire à ces listes, ou à une autre, rendez vous à &a.mailman.lists.link; et cliquez sur la liste à laquelle vous désirez vous inscrire. Des instructions sur le reste de la procédure sont alors données. Récupérez les sources sur un site miroir &os;. Vous pouvez le faire de deux manières: cvsup cron -CURRENT Synchronisation avec CVSup Utilisez le programme cvsup avec le fichier supfile nommé standard-supfile disponible dans le répertoire /usr/share/examples/cvsup. C'est la méthode recommandée, puisqu'elle permet de récupérer la totalité des sources la première fois et par la suite uniquement ce qui a été modifié. De nombreuses personnes exécutent cvsup depuis cron et maintiennent ainsi automatiquement à jour leurs sources. Vous devez personnaliser l'exemple de supfile précédent, et configurer cvsup pour votre environnement. -CURRENT Synchroniser avec CTM Utilisez CTM. Si vous disposez d'une mauvaise connexion (connexions chères ou seulement un accès au courrier électronique) CTM est une bonne solution. Cependant, c'est une source de problèmes et peut donner lieu à des fichiers endommagés. C'est pourquoi cette méthode est rarement utilisée, ce qui augmente les chances que cela ne fonctionne pas pendant d'assez longue périodes. Nous recommandons d'utiliser CVSup à tous ceux disposant d'un modem 9600 bps ou d'une connexion plus rapide. Si vous récupérez les sources pour compiler un système opérationnel, et pas simplement pour les lire, alors récupérez tout &os.current;, et pas uniquement certaines portions. La raison de cela est que diverses parties des sources dépendent de modifications effectuées ailleurs, et si vous essayez de compiler juste une partie des source, il est quasiment certain que vous aurez des problèmes. -CURRENT compilation Avant de compiler &os.current;, lisez attentivement le Makefile dans /usr/src. Vous devriez au moins la première fois installer un nouveau noyau et recompiler le système, comme étape nécessaire à votre processus de mise à jour. La lecture de la &a.current; et du fichier /usr/src/UPDATING vous tiendra au courant des autres procédures de transition qui sont parfois nécessaires lorsque nous préparons la prochaine version. Participez! Si vous utilisez &os.current;, nous aimerions savoir ce que vous en pensez, tout particulièrement si vous avez des améliorations à nous suggérer ou des corrections de bogues à nous soumettre. Les suggestions accompagnées de code sont accueillies avec enthousiasme! Se synchroniser avec la version -STABLE de &os; Qu'est-ce que &os.stable;? -STABLE &os.stable; est notre branche de développement à partir de laquelle sont extraites les versions majeures. Les modifications sur cette branche se font à une allure différente, et en supposant généralement qu'elles ont été tout d'abord testées sur &os.current;. Cela reste cependant toujours une branche de développement, et cela signifie qu'à certains moments, les sources de &os.stable; pourront être ou pas utilisables pour une quelconque raison. C'est tout simplement une autre branche de mise au point, et non pas une ressource pour l'utilisateur final. Qui a besoin de &os.stable;? Si vous désirez suivre ou contribuer au processus de développement de FreeBSD, tout particulièrement si cela a rapport avec la prochaine version de FreeBSD, alors vous devriez penser à suivre &os.stable;. Bien qu'il soit vrai que les correctifs de sécurité vont également dans la branche &os.stable;, vous n'avez pas besoin de suivre &os.stable; pour cela. Chaque rapport de sécurité concernant FreeBSD explique comment corriger le problème sur les versions affectées Ceci n'est pas tout à fait vrai. Nous ne pouvons continuer à supporter les anciennes versions de FreeBSD éternellement, bien que nous les supportions pendant de nombreuses années. Pour une description complète de la politique de sécurité actuelle pour les anciennes versions de FreeBSD, veuillez consulter http://www.FreeBSD.org/security/. + url="&url.base;/security/">http://www.FreeBSD.org/security/. , et suivre intégralement une branche de développement juste pour des raisons de sécurité apportera également de nombreux changements non désirés. Bien que nous tentons de nous assurer que la branche &os.stable; soit compilable et constamment stable, cela ne peut être garanti. De plus, alors que le code est développé sous &os.current; avant de l'inclure dans &os.stable;, le nombre de personnes utilisant &os.stable; est plus nombreux que celui utilisant &os.current;, aussi il est inévitable que des bogues et des problèmes pourront parfois apparaître sous &os.stable; alors qu'ils n'existaient pas sous &os.current;. Pour ces raisons, nous ne recommandons pas de suivre aveuglément &os.stable;, et il est tout particulièrement important que vous ne mettiez pas à jour des serveurs de production sous &os.stable; sans avoir tout d'abord testé le code dans votre environnement de travail. Si vous ne disposez pas des ressources pour faire cela alors nous recommandons que vous utilisiez la version de FreeBSD la plus récente, et que vous utilisiez le mécanisme de mise à jour binaire pour passer d'une version à une autre. Utiliser &os.stable; -STABLE utilisation Inscrivez-vous à à la liste &a.stable.name;. Vous serez tenu au courant des dépendances de compilation qui peuvent apparaître dans la branche &os.stable; ou de tout autre problème demandant une attention particulière. Les développeurs publieront également des annonces sur cette liste lorsqu'ils envisagent une correction ou modification controversée, offrant la possibilité aux utilisateurs de répondre s'ils ont des questions à soulever en rapport avec la modification proposée. La liste &a.cvsall.name; vous permettra de voir les courriers de trace des soumissions de toutes les modifications dès qu'elles sont faites et des informations pertinentes sur les éventuels effets de bord. Pour vous inscrire à ces listes, ou à une autre, rendez vous à &a.mailman.lists.link; et cliquez sur la liste à laquelle vous désirez vous inscrire. Des instructions sur le reste de la procédure sont alors données. Si vous installez un nouveau système et voulez qu'il soit aussi stable que possible, vous pouvez simplement récupérer le dernier instantané en date de la branche à partir de et l'installer comme toute autre version. Ou vous pouvez installer la version &os.stable; la plus récente à partir des sites miroirs et suivre les instructions ci-dessous pour mettre à jour votre système avec les sources &os;stable; les plus récentes. Si vous faites tourner une version précédente de &os; et que vous désirez mettre à jour via les sources vous pouvez aisément le faire à partir d'un site miroir &os;. Cela peut être fait de deux manières: cvsup cron -STABLE Synchronisation avec CVSup Utilisez le programme cvsup avec le fichier supfile nommé stable-supfile disponible dans le répertoire /usr/share/examples/cvsup. C'est la méthode recommandée, puisqu'elle permet de récupérer la totalité des sources la première fois et par la suite uniquement ce qui a été modifié. De nombreuses personnes exécutent cvsup depuis cron et maintiennent ainsi automatiquement à jour leurs sources. Vous devez personnaliser l'exemple de supfile précédent, et configurer cvsup pour votre environnement. -STABLE Synchroniser avec CTM Utilisez CTM. Si vous ne disposez pas d'une connexion Internet rapide et peu coûteuse, c'est la méthode que vous devriez penser à utiliser. Avant tout, si vous avez besoin d'un accès rapide à la demande aux sources et que la bande passante n'est pas un problème, utilisez cvsup ou ftp. Sinon, utilisez CTM. -STABLE compilation Avant de compiler &os.stable;, lisez attentivement le Makefile dans /usr/src. Vous devriez au moins la première fois installer un nouveau noyau et recompiler le système, comme étape nécessaire à votre processus de mise à jour. La lecture de la &a.stable; et du fichier /usr/src/UPDATING vous tiendra au courant des autres procédures de transition qui sont parfois nécessaires lorsque nous préparons la prochaine version. Synchroniser vos sources Il existe différentes façons d'utiliser une connexion Internet (ou le courrier électronique) pour garder à jour les sources de n'importe quelle partie, ou de l'ensemble, du projet &os;, selon ce qui vous intéresse. Les principaux services que nous fournissons sont le CVS anonyme, CVSup, et CTM. Alors qu'il est possible de mettre à jour seulement certaines parties de l'arbre des sources, la seule procédure de mise à jour supportée est celle consistant à mettre à jour l'intégralité de l'arborescence et de recompiler les sources des applicatifs de base—“userland” (i.e., tous les programmes qui tournent dans l'espace utilisateur, comme ceux des répertoires /bin et /sbin) et du noyau. Ne mettre à jour qu'une partie des sources, uniquement le noyau, ou seul le “userland” mènera souvent à des problèmes. Ces problèmes pourront aller d'erreurs de compilation à des paniques du noyau ou même des corruptions de données. CVS anonyme CVS anonyme et CVSup utilisent une méthode de mise à jour pilotée par le client—pull. Dans le cas de CVSup, l'utilisateur (ou une procédure cron) appelle le programme cvsup, qui interagit avec un serveur cvsupd distant, pour mettre à jour vos fichiers. Les mises à jour que vous recevez sont les plus récentes, et vous ne les recevez seulement lorsque vous le désirez. Vous pouvez aisément restreindre vos mises à jour aux fichiers ou répertoires particuliers qui vous intéressent. Les mises à jour sont générées à la volée par le serveur, en fonction de ce que vous avez déjà et de ce que vous voulez. CVS anonyme est plus simpliste que CVSup, car ce n'est qu'une extension de CVS qui permet de récupérer des modifications directement d'une archive CVS distante. Pour cela, CVSup est bien plus efficace mais CVS anonyme est plus facile à utiliser. CTM CTM, à l'inverse, ne compare pas interactivement les sources dont vous disposez avec celles qui sont sur l'archive de référence. Au lieu de cela, une procédure qui identifie les modifications intervenues depuis qu'elle a été exécutée pour la dernière fois, est lancée plusieurs fois par jour sur la machine CTM de référence (maître), les modifications détectées sont compressées, affectées d'un numéro de séquence et encodées pour pouvoir être envoyées par courrier électronique (en ASCII imprimable uniquement). Une fois reçus, ces “deltas CTM” peuvent être passés à l'utilitaire &man.ctm.rmail.1; qui décodera, contrôlera et appliquera automatiquement les modifications à l'exemplaire des sources de l'utilisateur. Cette méthode est beaucoup plus efficace que CVSup et consomme beaucoup moins de ressources sur notre serveur, parce que c'est un modèle piloté par le serveur—push plutôt que par l'utilisateur—pull. Il y a, bien sûr, quelques contreparties. Si vous effacez par inadvertance des parties de votre archive, CVSup s'en apercevra et vous reconstruira les parties endommagées. CTM ne le fera pas, et si vous effacez des parties de votre l'arborescence des sources (et que vous n'avez pas fait de sauvegarde) alors vous devrez repartir de zéro (à partir du plus récent “delta de base” CVS) et tout reconstituer avec CTM ou CVS anonyme, effacer les parties endommagées et resynchroniser. Recompiler le système recompiler le système Une fois que vous avez synchronisé votre arborescence des sources avec une version donnée de &os; (&os.stable;, &os.current;, et ainsi de suite) vous pouvez alors utiliser cette arborescence des sources pour recompiler le système. Faites une sauvegarde On n'insistera jamais assez sur l'importance de faire une sauvegarde de votre système avant tout autre chose. Bien qu'il soit facile de “refaire le monde” (recompiler FreeBSD), si vous suivez ces instructions, vous ferez inévitablement des erreurs à un moment ou un autre, ou d'autres feront des erreurs au niveau de l'arborescence des sources qui empêcheraient votre système de redémarrer. Assurez-vous que vous avez bien fait une sauvegarde. Ayez une disquette de maintenance, ou un CD démarrable à portée de la main. Vous ne l'utiliserez probablement pas, mais prudence est mère de sûreté! S'abonner à la bonne liste de diffusion liste de diffusion Les branches &os.stable; et &os.current; sont, par nature, en développement. Les personnes qui participent à &os; sont des humains, et des erreurs se produisent occasionnellement. Ces erreurs sont parfois bénignes, provocant simplement l'affichage d'un nouveau message d'avertissement par votre système. Elles peuvent aussi être catastrophiques, et empêcher votre système de redémarrer ou détruire vos systèmes de fichiers (ou pire). Quand de tels problèmes se produisent, un avertissement “heads up” est posté sur la liste de diffusion appropriée, décrivant la nature du problème et quels systèmes sont concernés. Un message “all clear” est posté quand le problème est résolu. Si vous tentez de suivre &os.stable; ou &os.current; et que vous ne lisez pas la &a.stable; ou la &a.current;, vous allez au devant d'ennuis. N'utilisez pas la commande <command>make world</command> De nombreuses anciennes documentations préconisent d'utiliser la commande make world. Cette commande n'effectue pas un certain nombre d'étapes importantes et ne devrait être utilisée que si vous êtes sûr de ce que vous faites. Dans presque tout les cas make world n'est pas une bonne chose à faire, et la procédure décrite dans la suite de ce document devrait être utilisée à la place. La méthode générique de mise à jour du système Pour mettre à jour votre système, vous devriez utiliser la procédure suivante: &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; reboot Vous devriez démarrer en mode mono-utilisateur (en utilisant par exemple la commande boot -s à l'invite du chargeur). Exécutez ensuite: &prompt.root; mergemaster -p &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Lisez les explications supplémentaires La séquence décrite ci-dessus n'est qu'un court résumé pour vous aider à démarrer. Vous devriez cependant lire les sections suivantes afin de comprendre clairement chaque étape, tout particulièrement si vous désirez utiliser une configuration du noyau personnalisée. Lire <filename>/usr/src/UPDATING</filename> Avant tout autre chose, lisez /usr/src/UPDATING (ou le fichier équivalent en fonction de l'endroit où se trouve vos sources). Ce fichier devrait contenir les informations importantes au sujet des problèmes que vous pourriez rencontrer, ou indique l'ordre dans lequel vous devriez exécuter certaines commandes. Si le fichier UPDATING contredit quelque chose d'écrit ici, UPDATING prime sur tout le reste. La lecture du fichier UPDATING n'est pas un substitut à l'abonnement à la liste de diffusion correcte, comme décrit précédemment. Ces deux prérequis sont complémentaires, et non pas exclusifs. Contrôler <filename>/etc/make.conf</filename> make.conf Contrôlez les fichiers /usr/share/examples/etc/make.conf (appelé /etc/defaults/make.conf sous  4.X) et /etc/make.conf. Le premier contient des paramètres par défaut – la plupart étant placés en commentaires. Pour les utiliser quand vous recompilez votre système à partir des sources, rajoutés-les au fichier /etc/make.conf. Gardez à l'esprit que tout ce que vous ajoutez au fichier /etc/make.conf est utilisé chaque fois que vous invoquez la commande make, il est donc bon de s'assurer que les valeurs par défaut sont appropriées à votre système. Un utilisateur typique voudra probablement copier les lignes CFLAGS et NOPROFILE se trouvant dans /usr/share/examples/etc/make.conf (ou dans /etc/defaults/make.conf sous &os; 4.X) vers /etc/make.conf et les décommenter. Examinez les autres définitions (COPTFLAGS, NOPORTDOCS et ainsi de suite) et décidez si elles vous conviennent. Mettre à jour les fichiers dans <filename>/etc</filename> Le répertoire /etc contient la plupart des informations de configuration de votre système, ainsi que les procédures de démarrage. Certaines de ces procédures changent d'une version à l'autre de FreeBSD. Certains fichiers de configuration sont également utilisés en permanence par le système. En particulier /etc/group. Il est arrivé que la phase d'installation “make installworld” ait besoin que certains utilisateurs et groupes existent. Il y a de fortes chances qu'ils n'aient pas été définis avant la mise à jour. C'est une source de problèmes. Dans certains cas “make buildworld” contrôlera si ces utilisateurs ou groupes existent. Un exemple récent de cela fut l'addition de l'utilisateur smmsp. Le processus d'installation échouait quand mtree tentait de créer /var/spool/clientmqueue. La solution est d'examiner le fichier /usr/src/etc/group et de comparer sa liste de groupe avec la votre. S'il y a des groupes dans le nouveau fichier qui sont absents du votre, alors rajoutez-les. De même vous devriez renommer tous les groupes dans /etc/group qui ont le même GID mais un nom différent que ceux présents dans /usr/src/etc/group. Depuis 4.6-RELEASE vous pouvez exécuter &man.mergemaster.8; dans le mode pré-“buildworld” en ajoutant l'option . Cela effectuera la comparaison uniquement des fichiers essentiels pour le succès de la procédure buildworld ou installworld. Si votre vieille version de mergemaster ne supporte pas l'option , utilisez la nouvelle version présente dans l'arborescence des sources quand vous l'exécutez pour la première fois: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Si vous êtes particulièrement paranoïaque, vous pouvez contrôler votre système afin de voir quels fichiers appartiennent au groupe que vous renommez ou effacez: &prompt.root; find / -group GID -print affichera les fichiers appartenant au groupe GID (qui peut être soit un nom de groupe ou un identifiant numérique de groupe). Passer en mode mono-utilisateur mode mono-utilisateur Il vaut mieux recompiler le système en mode mono-utilisateur. En dehors du fait que cela sera légèrement plus rapide, la réinstallation va modifier un grand nombre de fichiers systèmes importants, tous les binaires de base du système, les bibliothèques, les fichiers d'include et ainsi de suite. Les modifier sur un système en fonctionnement (en particulier s'il y a des utilisateurs connectés à ce moment là), c'est aller au devant de problèmes. mode multi-utilisateurs Une autre méthode consiste à compiler le système en mode multi-utilisateurs, et passer dans le mode mono-utilisateur pour l'installation. Si vous désirez utiliser cette méthode, conservez les étapes suivantes pour le moment où la compilation sera terminée. Vous pouvez reporter le passage en mode mono-utilisateur jusqu'à l'exécution de installkernel ou installworld. En tant que super-utilisateur, vous pouvez exécuter la commande: &prompt.root; shutdown now sur un système en fonctionnement, pour passer en mode mono-utilisateur. Ou bien, redémarrer le système, et à l'invite de démarrage, entrez l'indicateur . Le système démarrera alors en mode mono-utilisateur. A l'invite de l'interpréteur de commandes, exécutez alors: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Cela effectue une vérification des systèmes de fichiers, remonte / en mode lecture/écriture, et monte tous les autres systèmes de fichiers UFS listés dans le fichier /etc/fstab, puis active la pagination. Si votre horloge CMOS est réglée sur l'heure locale et non pas sur le fuseau GMT (cela est vrai si la sortie de la commande date ne donne pas l'heure et le fuseau correct), vous aurez également peut-être besoin d'exécuter la commande suivante: &prompt.root; adjkerntz -i Cela permettra de s'assurer que vos paramètres de fuseaux horaires sont correctement configurés — sans cela, vous risquez de faire face, plus tard, à des problèmes. Effacer <filename>/usr/obj</filename> Au fur et à mesure que les différentes parties du système sont recompilées, elles sont placées dans des répertoires qui (par défaut) sont sous /usr/obj. Les répertoires sont agencés comme sous /usr/src. Vous pouvez accélérer le processus “make buildworld”, et également vous éviter d'éventuels problèmes de dépendances en effaçant ce répertoire. Certains fichiers dans /usr/obj peuvent avoir l'indicateur immuable positionné (consultez la page de manuel &man.chflags.1; pour plus d'informations) qui doit être retiré en premier. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Recompiler les sources Enregistrer la sortie C'est une bonne idée d'enregistrer la sortie de &man.make.1; dans un fichier. Si quelque chose se passe mal, vous aurez une trace des messages d'erreur. Même si cela ne vous aide pas à diagnostiquer ce qui n'a pas fonctionné, cela peut aider les autres si vous postez votre problème sur une des listes de diffusion de &os;. La méthode la plus aisée pour faire cela est d'utiliser la commande &man.script.1;, avec en paramètre le nom du fichier où enregistrer les résultats. Vous devez faire cela immédiatement juste avant de recompiler le système, et taper exit une fois que c'est terminé. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … Si vous le faites, n'enregistrez pas le résultat dans /tmp. Ce répertoire peut être vidé au prochain redémarrage du système. Un meilleur endroit de sauvegarde est /var/tmp (comme dans l'exemple précédent) ou dans le répertoire utilisateur de root. Compiler le nouveau système Vous devez être dans le répertoire /usr/src: &prompt.root; cd /usr/src (à moins, bien sûr, que votre code source ne soit ailleurs, auquel cas vous devrez aller dans le répertoire correspondant). make Pour recompiler le système, on utilise la commande &man.make.1;. Cette commande lit ses instructions dans le fichier Makefile, qui décrit comment devraient être reconstruits les programmes qui constituent &os;, dans quel ordre, et ainsi de suite. Le format général de la ligne de commande que vous taperez sera la suivante: &prompt.root; make -x -DVARIABLE cible Dans cet exemple, est une option que vous passez à &man.make.1;. Reportez-vous à la page de manuel pour un exemple d'options que vous pouvez passer. transmet un variable au fichier Makefile. Le comportement du Makefile est défini par ces variables. Ce sont les mêmes variables que l'on trouve dans /etc/make.conf, et c'est un autre moyen de les positionner. &prompt.root; make -DNOPROFILE cible est une autre manière de dire qu'il ne faut pas compiler les bibliothèques profilées et correspond à la ligne: NOPROFILE= true # Avoid compiling profiled libraries dans /etc/make.conf. cible indique à &man.make.1; ce que vous voulez faire. Chaque Makefile définit un certain nombre de “cibles”, et votre choix de cible détermine ce qui se passe. Certaines cibles listées dans le fichier Makefile, ne doivent pas être employées. Ce sont des étapes intermédiaires utilisées par le processus de recompilation pour décomposer les étapes importantes de la recompilation du système en sous-étapes. La plupart du temps, vous n'aurez pas besoin de passer de paramètres à &man.make.1;, et votre commande ressemblera à ceci: &prompt.root; make cible A partir de la version 2.2.5 de &os; (en fait, c'est apparu en premier sur la branche &os.current;, et ensuite intégré dans la branche &os.stable; entre les versions 2.2.2 et 2.2.5) la cible world a été décomposée en deux parties: buildworld et installworld. Avec la version 5.3 de &os; la cible world est modifiée et ne fonctionnera pas par défaut et est en fait dangereuse pour la plupart des utilisateurs. Comme leurs noms l'indiquent, buildworld reconstruit la nouvelle arborescence dans /usr/obj, et installworld l'installe sur la machine. Ceci est très utile pour deux raisons. Tout d'abord cela vous permet de recompiler en toute sûreté en sachant qu'aucun composant du système actuel ne sera affecté. La compilation est “autonome”. En raison de cela vous pouvez exécuter buildworld sur une machine en mode multi-utilisateurs sans redouter d'effets fâcheux. Il est néanmoins recommandé de toujours exécuter l'étape installworld en mode mono-utilisateur. En second lieu, cela vous permet d'utiliser des systèmes montés par NFS pour mettre à jour plusieurs machines de votre réseau. Si vous avez trois machines A, B et C que vous voulez mettre à jour, exécutez make buildworld et make installworld sur A. B et C doivent ensuite monter par NFS /usr/src et /usr/obj depuis A, et vous pouvez alors exécuter make installworld pour installer le système recompilé sur B et C. Bien que la cible world existe toujours, vous êtes fortement encouragé à ne pas l'utiliser. Exécutez: &prompt.root; make buildworld Il est maintenant possible de passer l'option à &man.make.1; ce qui lui permettra d'exécuter plusieurs processus simultanément. C'est particulièrement utile sur une machine avec plusieurs processeurs. Cependant, comme la compilation est plus gourmande en E/S plutôt qu'en CPU, c'est également utile sur des machines mono-processeur. Typiquement sur une machine mono-processeur, vous exécuteriez: &prompt.root; make -j4 buildworld &man.make.1; pourra exécuter jusqu'à 4 processus simultanément. Des constatations empiriques postées sur les listes de diffusion montrent que c'est en général ce qui apporte le plus de gain en performances. Si vous avez une machine multi-processeurs et que vous avez configuré un noyau SMP, essayez des valeurs entre 6 et 19 et voyez quel bénéfice vous en tirez. Soyez conscient que c'est toujours quelque peu expérimental, et que des modifications de l'arborescence des sources rendent parfois cette possibilité inutilisable. Si la recompilation échoue avec ce paramètre, essayez sans avant de signaler votre problème. Durée Compilation du système durée De nombreux facteurs influencent la durée de compilation, mais actuellement un &pentium; III à 500 MHz avec 128 MO de RAM met environ 2 heures pour compiler l'arborescence &os.stable;, sans modification ni raccourcis durant le processus. Une arborescence &os.current; nécessitera un peu plus de temps. Compiler et installer un nouveau noyau noyau compilation Pour tirer pleinement parti de votre nouveau système, vous devrez recompiler le noyau. C'est pratiquement indispensable, parce que certaines structures mémoires peuvent avoir changées, et des programmes comme &man.ps.1; et &man.top.1; ne fonctionneront pas tant que le système et le noyau n'utilisent pas les mêmes versions de code source. La manière la plus simple et la plus sûre est de compiler et installer un noyau basé sur le noyau GENERIC. Alors que le noyau GENERIC peut ne pas comporter les pilotes de périphériques nécessaires pour votre système, il devrait contenir tout ce qui est nécessaire pour faire démarrer votre système en mode mono-utilisateur. C'est une bonne façon de tester le fonctionnement de votre nouveau système. Après avoir démarré à partir du noyau GENERIC et vérifié que votre système fonctionne vous pouvez alors compiler un nouveau noyau basé sur votre fichier de configuration normal du noyau. Sur les versions récentes de &os;, il est important de recompilé le système avant de compiler un nouveau noyau. Si vous désirez compiler un noyau personnalisé, et que vous avez déjà un fichier de configuration, utilisez juste KERNCONF=MONNOYAU comme suit: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MONNOYAU &prompt.root; make installkernel KERNCONF=MONNOYAU Sous FreeBSD 4.2 et versions antérieures vous devez remplacer KERNCONF= par KERNEL=. Une version 4.2-STABLE qui a été récupérée avant le 2 février 2001 ne reconnaît pas le paramètre KERNCONF=. Notez que si vous avez augmenté la variable kern.securelevel à une valeur supérieure à 1 et que vous avez positionné l'indicateur noschg ou similaire sur votre noyau, il sera intéressant de passer en mode mono-utilisateur pour utiliser installkernel. Sinon vous devriez être en mesure d'exécuter ces commandes à partir du mode multi-utilisateur sans problèmes. Voir la page de manuel de &man.init.8; pour plus de détails à propos de kern.securelevel et la page &man.chflags.1; pour des informations sur les différents indicateurs de fichiers. Si vous mettez à jour vers une version de &os; antérieure à la 4.0, vous devriez utiliser l'ancienne procédure de compilation du noyau. Cependant, il est recommandé d'utiliser la nouvelle version de &man.config.8;, en utilisant une ligne de commande comme celle-ci: &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME Redémarrer en mode mono-utilisateur mode mono-utilisateur Vous devriez redémarrer en mode mono-utilisateur pour tester le fonctionnement du nouveau noyau. Pour cela suivez les instructions de . Installer les nouveaux binaires système Si vous avez compilé une version de &os; assez récente pour avoir utilisé make buildworld alors vous devriez utiliser maintenant installworld pour installer les nouveaux binaires système. Lancez: &prompt.root; cd /usr/src &prompt.root; make installworld Si vous spécifiez des variables sur la ligne de commande de make buildworld, vous devez utiliser les mêmes variables avec la commande make installworld. Cela ne reste pas forcément vrai pour d'autres options; par exemple, ne doit jamais être utilisée avec installworld. Par exemple, si vous exécutez: &prompt.root; make -DNOPROFILE buildworld vous devrez ensuite installer les résultats avec: &prompt.root; make -DNOPROFILE installworld sinon il essayera d'installer les bibliothèques profilées qui n'ont pas été recompilées à l'étape make buildworld. Mettre à jour les fichiers non modifiés par <command>make installworld</command> La recompilation du système ne mettra pas à jour certains répertoires (en particulier, /etc, /var et /usr) avec les fichiers nouveaux ou modifiés. La manière la plus simple de mettre à jour ces fichiers est d'utiliser &man.mergemaster.8;, bien qu'il soit possible de le faire manuellement si vous le désirez. Indépendamment de la manière que vous choisissez, assurez-vous de faire une sauvegarde du répertoire /etc au cas où quelque chose se passerait mal. Tom Rhodes Contribution de <command>mergemaster</command> mergemaster L'utilitaire &man.mergemaster.8; est une procédure Bourne qui vous aidera à déterminer les différences entre vos fichiers de configuration dans le répertoire /etc, et les fichiers de configuration dans l'arborescence des sources /usr/src/etc. C'est la solution recommandée pour maintenir à jour les fichiers de configuration du système avec ceux situés dans l'arborescence des sources. L'outil &man.mergemaster.8; a été intégré dans la base de FreeBSD entre la version 3.3-RELEASE et la version 3.4-RELEASE, ce qui signifie qu'il est présent dans tous les systèmes -STABLE et -CURRENT depuis la version 3.3. Pour commencer, tapez simplement mergemaster à l'invite, et observez-le travailler. mergemaster commencera à constituer une arborescence temporaire, à partir de /, et la remplira avec divers fichiers de configuration. Ces fichiers sont alors comparés avec ceux actuellement installés sur votre système. A ce point, les fichiers qui diffèrent seront affichés dans le format &man.diff.1;, avec le signe représentant les lignes modifiées ou ajoutées, et le représentant les lignes qui seront soit complètement supprimées, soit remplacées avec une nouvelle ligne. Voir la page de manuel &man.diff.1; pour plus d'informations au sujet de la syntaxe &man.diff.1; et comment sont affichées les différences. &man.mergemaster.8; vous affichera ensuite chaque fichier présentant des différences, et vous aurez à ce moment-là le choix de soit supprimer le nouveau fichier (le fichier temporaire), soit d'installer le fichier temporaire non modifié, soit de fusionner le fichier temporaire et le fichier actuellement installé, soit enfin de revoir les résultats de l'opération &man.diff.1;. Choisir de supprimer le fichier temporaire indiquera à &man.mergemaster.8; que nous désirons conserver notre fichier actuel intacte, et effacera la nouvelle version. Cette option n'est pas recommandée, à moins que vous ne voyez aucune raison de modifier le fichier actuel. Vous pouvez obtenir de l'aide à n'importe quel moment en tapant ? à l'invite de &man.mergemaster.8;. Si l'utilisateur choisit de passer un fichier, il sera présenté à nouveau une fois que tous les autres fichiers auront été traités. Choisir d'installer un fichier temporaire intact remplacera le fichier actuel avec le nouveau. Pour la plupart des fichiers non modifiées, c'est la meilleure option. Choisir de fusionner le fichier, vous affichera un éditeur de texte, et le contenu des deux fichiers. Vous pouvez maintenant les fusionner en les visionnant côte à côte sur l'écran, et en sélectionnant des parties des deux fichiers pour créer un fichier final. Quand les fichiers sont comparés côte à côte, la touche l sélectionnera le contenu de gauche et la touche r sélectionnera celui de droite. Le résultat final sera un fichier constitué des deux parties, qui peut alors être installé. Cette option est habituellement utilisée pour les fichiers où les des paramètres ont été modifiés par l'utilisateur. Choisir de revoir les résultats de l'opération &man.diff.1; vous affichera les différences entre fichiers tout comme la fait &man.mergemaster.8; avant de vous demander un choix. Après que &man.mergemaster.8; en ait terminé avec les fichiers système, il vous proposera de nouvelles opérations. &man.mergemaster.8; vous demandera si vous désirez reconstruire le fichier des mots de passe et/ou exécuter &man.MAKEDEV.8; si vous utilisez une version de FreeBSD antérieure à la 5.0, et terminera avec la possibilité de supprimer les fichiers temporaires restants. Mise à jour manuelle Si vous désirez faire la mise à jour manuellement, vous ne pouvez cependant pas vous contenter de copier les fichiers de /usr/src/etc dans /etc pour que cela fonctionne. Certains de ces fichiers doivent d'abord être “installés”. En effet le répertoire /usr/src/etc “n'est pas” une copie de ce que devrait contenir votre répertoire /etc. De plus, il a des fichiers qui doivent être dans /etc et qui ne sont pas dans /usr/src/etc. Si vous utilisez &man.mergemaster.8; (comme recommandé), vous pouvez passer directement à la section suivante. La façon la plus simple de procéder est d'installer les fichiers dans un nouveau répertoire, puis de passer en revue les différences. Sauvegardez votre répertoire <filename>/etc</filename> actuel Bien qu'en principe rien ne sera modifié automatiquement dans ce répertoire, prudence est mère de sûreté. Copiez donc votre répertoire /etc dans un endroit sûr. Quelque chose du genre: &prompt.root; cp -Rp /etc /etc.old conviendra; l'option fait une copie récursive, préserve la date, les autorisations des fichiers et ainsi de suite. Vous devez créer un ensemble de répertoires provisoires pour y installer les fichiers du répertoire /etc et autres. /var/tmp/root est un bon choix, il y a un certain nombre de sous-répertoires à créer également: &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Cela va créer l'arborescence nécessaire et y installera les fichiers. Un grand nombre des sous-répertoires créés dans /var/tmp/root sont vides et devront être supprimés. La façon la plus simple de le faire est: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Ceci supprimera tous les répertoires vides (la sortie d'erreur standard est redirigée vers /dev/null pour empêcher les avertissements à propos des répertoires non vides). /var/tmp/root contient maintenant tous les fichiers à installer à l'endroit requis sous /. Vous devez maintenant examiner chacun de ces fichiers pour déterminer en quoi ils diffèrent de vos propres fichiers. Notez que certains des fichiers qui seront installés dans /var/tmp/root commencent par un “.”. Au moment où sont écrites ces lignes, les seuls fichiers concernés sont les fichiers d'initialisation des interpréteurs de commandes dans /var/tmp/root/ et /var/tmp/root/root/, mais il pourrait y en avoir d'autres (cela dépend de quand vous lirez ces lignes). Assurez-vous d'utiliser la commande ls -a pour ne pas les oublier. La manière la plus simple de procéder est d'utiliser la commande &man.diff.1; pour comparer les deux fichiers: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Cela vous indiquera les différences entre votre fichier /etc/shells et le nouveau fichier /var/tmp/root//etc/shells. A partir de là, décidez si vous aller reporter les modifications que vous y avez apportée ou si vous allez simplement recopier le nouveau fichier. Donnez au nouveau répertoire racine (<filename>/var/tmp/root</filename>) un nom qui inclue une date, pour pouvoir facilement comparer les différentes versions Si vous recompilez fréquemment votre système, cela signifie que vous devez également souvent mettre à jour le répertoire /etc, ce qui peut rapidement devenir une corvée. Vous pouvez accélérer le processus en conservant une copie du dernier ensemble de fichiers modifiés que vous avez reportés dans /etc. La procédure suivante présente une façon de faire. Recompilez le système comme à l'accoutumé. Au moment de mettre à jour /etc et les autre répertoires, donnez au répertoire cible un nom basé sur la date du jour. Si vous faisiez cela le 14 février 1998, vous pourriez procéder comme suit: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Reporter les modifications depuis ce répertoire comme décrit plus haut. Ne supprimez pas le répertoire /var/tmp/root-19980214 quand vous aurez terminé. Quand vous récupérez la dernière version des sources et la recompilerez, suivez l'étape 1. Vous aurez alors un nouveau répertoire, qui pourrait s'appeler /var/tmp/root-19980221 (si vous faites une mise à jour chaque semaine). Vous pouvez maintenant voir les modifications intervenues d'une semaine à l'autre en utilisant &man.diff.1; pour afficher les différences entre tous les fichiers deux répertoires: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Généralement, il y aura beaucoup moins de différences qu'entre /var/tmp/root-19980221/etc et /etc. Comme il y a beaucoup moins de différences, il est beaucoup plus facile de les reporter dans le répertoire /etc. Vous pouvez maintenant supprimer le plus ancien des deux répertoires /var/tmp/root-*: &prompt.root; rm -rf /var/tmp/root-19980214 Répétez l'opération chaque fois que vous devez reporter des modifications dans /etc. Vous pouvez utiliser &man.date.1; pour automatiser la génération des noms de répertoires: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Mettre à jour <filename>/dev</filename> DEVFS DEVFS Si vous utilisez FreeBSD 5.0 ou suivante vous pouvez sans risque passer cette section. Ces versions utilisent &man.devfs.5; pour allouer les fichiers spéciaux de périphériques de façon transparente pour l'utilisateur. Dans la plupart des cas, l'outil &man.mergemaster.8; déterminera quand il sera nécessaire de mettre à jour les fichiers spéciaux de périphériques, et proposera de le faire automatiquement. Les instructions suivantes expliquent comment mettre à jour les fichiers spéciaux de périphériques manuellement. Pour des raisons de sécurité, cette mise à jour se fait en plusieurs étapes. Copiez /var/tmp/root/dev/MAKEDEV dans /dev: &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev MAKEDEV Si vous avez utilisé &man.mergemaster.8; pour mettre à jour /etc, alors votre procédure MAKEDEV a dû déjà être mise à jour, bien que cela ne peut pas faire de mal de la contrôler (avec &man.diff.1;) et la copier manuellement si nécessaire. Maintenant, prenez une photographie de l'état de votre répertoire /dev. Cette photographie doit contenir les droits, propriétaires et les codes majeur et mineur de fichier spécial de périphérique, mais pas leur date de dernière mise à jour. La façon la plus aisée de procéder est d'utiliser la commande &man.awk.1; pour éliminer les informations inutiles: &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out Recréez tous les fichiers spéciaux de périphériques: &prompt.root; sh MAKEDEV all Reprenez une autre photographie du répertoire, cette fois-ci dans /var/tmp/dev2.out. Comparez maintenant ces deux fichiers pour voir si certains fichiers spéciaux de périphériques manquant n'ont pas été créés. Cela ne devrait pas être le cas, mais prudence est mère de sûreté. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out Il manquera peut-être des descripteurs de partitions, il vous faudra alors exécuter des commandes du type: &prompt.root; sh MAKEDEV sd0s1 pour les recréer. Les détails dépendent de votre installation. Mettre à jour <filename>/stand</filename> Cette étape n'est décrite que pour être exhaustif. Elle peut être omise sans risque. Si vous utilisez &os; 5.2 ou suivante, le répertoire /rescue est automatiquement mis à jour avec des binaires compilés en statique lors de l'opération make installworld, rendant par conséquent obsolète la mise à jour du répertoire /stand/. Pour être exhaustif, vous pouvez également mettre à jour les fichiers du répertoire /stand. Ces fichiers sont des liens physiques vers le binaire /stand/sysinstall. Cet exécutable doit être compilé en statique, pour qu'il soit utilisable sans qu'aucun autre système de fichiers (et en particulier /usr) ne soit monté. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install Redémarrer Vous en avez terminé. Après avoir vérifié que tout semble être en place, vous pouvez alors redémarrez votre système. Un simple &man.shutdown.8; devrait suffire: &prompt.root; shutdown -r now C'est fini Vous devriez maintenant avoir mis à jour avec succès votre système &os;. Félicitations. Si les choses se sont légèrement mal passées, il est facile de recompiler un élément particulier du système. Par exemple, si vous avez accidentellement effacé /etc/magic lors de la mise à jour de /etc, la commande &man.file.1; ne fonctionnerait plus. Dans ce cas, la solution serait d'exécuter: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Questions Dois-je refaire le monde à chaque évolution? Il n'y a pas de réponse toute faite à cette question, tout dépend de la nature des évolutions. Par exemple, si vous venez juste d'exécuter CVSup, et que les fichiers suivants on été mis à jour: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk cela ne vaut probablement pas la peine de recompiler tout le système. Vous pouvez tout simplement aller dans les sous-répertoires appropriés, exécuter make all install, et c'est à peu près tout. Mais s'il y a des évolutions importantes, par exemple sur src/lib/libc/stdlib alors vous devrez soit refaire le monde, ou recompiler au moins toutes les parties du système qui sont liées statiquement (de même que tout ce vous pourriez avoir ajouté qui y serait lié statiquement). C'est à vous de voir. Vous préférerez peut-être recompiler votre système tous les quinze jours, et laisser les modifications s'empiler pendant quinze jours. Ou bien vous préférerez ne recompiler que ce qui a changé et vous faire confiance pour tout ce qui en dépend. Et, bien sûr, cela dépend de la fréquence avec laquelle vous voulez faire vos mises à jour, et de si vous suivez la branche &os.stable; ou &os.current;. Ma compilation échoue avec de nombreuses erreurs “signal 11” (ou tout autre numéro de signal). Que s'est-il passé? signal 11 Cela indique généralement un problème matériel. (Re)compiler le système est un bon moyen de mettre votre matériel sous pression, et mettra souvent en évidence des défaillances de la mémoire vive. Elles se manifestent normalement d'elles-mêmes, la compilation échouant lors de la réception de mystérieux signaux. Un bon indicateur de cet état de fait, est que vous pouvez relancer la compilation et qu'elle échouera en un endroit différent. Dans ce cas, vous ne pouvez guère faire autre chose que d'intervertir les différents composants de votre matériel pour déterminer lequel est en cause. Puis-je effacer /usr/obj après avoir fini? Une réponse courte est oui. /usr/obj contient tous les fichiers objets générés à la compilation. Normalement, une des premières étapes de “make buildworld” est de supprimer ce répertoire et de repartir à zéro. Dans ce cas, conserver le répertoire /usr/obj après avoir terminé ne sert pas à grand chose, alors que vous économiseriez pas mal d'espace disque (actuellement environ 340 MO). Cependant, si vous savez ce que vous faites, vous pouvez faire en sorte que “make buildworld” saute cette étape. Cela rendra les compilations ultérieures plus rapides, puisque la plupart des sources n'auront pas besoin d'être recompilées. Le revers de la médaille est que des problèmes subtils de dépendance peuvent se manifester, provoquant l'échec de votre compilation de manière étrange. Cela génère fréquemment du bruit sur les listes de diffusion de &os;, quand quelqu'un se plaint que sa mise à jour a échoué, sans réaliser que c'est parce qu'il a tenté de brûler les étapes. Une recompilation interrompue peut-elle être reprise? Tout dépend de jusqu'où vous êtes aller avant de rencontrer un problème. En général (et ceci n'est pas une règle absolue) “make buildworld” crée de nouveaux exemplaires des outils indispensables (comme &man.gcc.1; et &man.make.1;) et des bibliothèques système. Ces outils et bibliothèques sont ensuite installés. Puis ils sont utilisés pour se reconstruire eux-mêmes, et installés de nouveau. L'intégralité du système (y compris maintenant les programmes utilisateurs classiques, comme &man.ls.1; ou &man.grep.1;) est alors recompilé avec les nouveaux fichiers système. Si vous êtes à cette dernière étape, et que vous le savez (parce que vous avez consulté les résultats que vous avez enregistrés) alors vous pouvez (sans trop de risque) faire: … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNOCLEAN all Cela ne détruira pas les résultats du travail qu'à déjà effectué “make buildworld”. Si vous voyez le message: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- dans les comptes-rendus de “make buildworld” alors cette façon de procéder est probablement bonne. Si vous ne voyez pas ce message, ou que vous doutez de vous, alors prudence est mère de sûreté, et il vaut mieux tout reprendre depuis le début. Comment puis-je accélérer la compilation du système? Passez en mode mono-utilisateur. Mettez les répertoires /usr/src et /usr/obj sur des systèmes de fichiers et des disques différents. Si possible, installez ces disques sur des contrôleurs différents. Encore mieux, mettez ces systèmes de fichiers sur plusieurs disques utilisant le système &man.ccd.4; (pilote de disques concaténés). Ne compilez pas les bibliothèques profilées (mettez “NOPROFILE=true” dans le fichier /etc/make.conf). Vous n'en avez certainement pas besoin. Egalement dans /etc/make.conf, positionnez CFLAGS à quelque chose comme . L'optimisation est bien plus lente, et la différence d'optimisation entre et est en général négligeable. demande au compilateur d'utiliser des tuyaux à la place de fichiers temporaires, ce qui économise des accès disque (mais utilise plus de mémoire). Passez l'option à &man.make.1; pour permettre l'exécution de plusieurs processus en parallèle. Cela améliore généralement les choses, que vous ayez une machine mono- ou multi-processeurs. Le système de fichiers qui contient /usr/src peut être monté (ou remonté) avec l'option . Cela empêche l'enregistrement des dates d'accès aux fichiers par le système de fichiers. Vous n'avez de toute façon probablement pas besoin de cette information. &prompt.root; mount -u -o noatime /usr/src Cet exemple suppose que /usr/src constitue à lui seul un système de fichiers. Si ce n'est pas le cas (s'il fait partie de /usr par exemple) vous devez alors indiquer le point de montage de ce système de fichiers, et non /usr/src. Le système de fichiers où se trouve /usr/obj peut être monté (ou remonté) avec l'option . Les écritures sur le disque se feront alors de façon asynchrone. En d'autres termes, le programme reprend immédiatement la main, et l'écriture des données sur le disque se fait quelques secondes plus tard. Cela permet le groupement des écritures sur le disque, et le gain en performance peut être spectaculaire. Gardez à l'esprit que cette option rend votre système de fichiers plus fragile. Avec cette option, les risques ne sont accrus qu'en cas de coupure d'alimentation, le système de fichiers soit irrécupérable quand la machine redémarrera. S'il n'y a que /usr/obj sur ce système de fichiers, ce n'est alors pas un problème. Si vous avez d'autres données importantes sur ce système de fichiers, assurez-vous que vos sauvegardes soient à jour avant d'activer cette option. &prompt.root; mount -u -o async /usr/obj Comme auparavant, si /usr/obj ne constitue pas un système de fichiers en soit, remplacez-le dans l'exemple par le nom du point de montage approprié. Que faire si quelque chose se passe mal? Soyez absolument sûr que votre environnement ne contient pas des restes de compilation précédentes. Cela est plutôt simple: &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir En effet, make cleandir doit vraiment être exécutée deux fois. Ensuite relancez l'ensemble du processus, en commençant avec make buildworld. Si vous avez toujours des problèmes, envoyez l'erreur et le résultat de la commande uname -a à la &a.questions;. Tenez-vous prêt à répondre à d'autres concernant votre configuration! Mike Meyer Contribution de Suivre les mises à jour pour plusieurs machines NFS installation de multiples machines Si vous avez plusieurs machines dont vous voulez maintenir à jour l'arborescence des sources, alors faire télécharger et recompiler à chacune d'entre elles les sources semble un gaspillage de ressources: espace disque, bande passante réseau, et cycles CPU. C'est en effet bien le cas, et la solution est d'avoir une machine qui fait la majeure partie du travail, pendant que le reste des machines montent ce travail par NFS. Cette section décrit une façon de le faire. Préliminaires Premièrement, identifiez un ensemble de machines qui va utiliser le même ensemble de binaires, que nous appellerons un ensemble de compilation. Chaque machine peut avoir un noyau personnalisé, mais elles exécuteront les mêmes binaires utilisateur du système de base. Dans cet ensemble de machine, choisissez une machine qui sera la machine de compilation. Cela sera la machine sur laquelle le monde et le noyau seront compilés. Idéalement, cela devrait être une machine rapide avec un CPU suffisamment disponible pour exécuter la commande make buildworld et make buildkernel. Vous voudrez également utiliser une machine de test, qui testera les mises à jour logicielles avant d'être utilisées en production. Cela doit être une machine que vous pouvez vous permettre d'avoir hors service pour une longue période. Cela peut être la machine de compilation, mais cela n'est pas obligatoire. Toutes les machines de cet ensemble de compilation doivent monter /usr/obj et /usr/src à partir de la même machine, et du même point de montage. Idéalement, ces derniers sont sur deux disques différents sur la machine de compilation, mais peuvent également être montés par NFS sur cette machine. Si vous avez plusieurs ensembles de compilation, /usr/src devrait être sur une machine de compilation, et monté par NFS sur les autres. Finalement assurez-vous que /etc/make.conf sur toutes les machines de l'ensemble de compilation est en accord avec la machine de compilation. Cela signifie que la machine de compilation doit compiler toutes les parties du système de base que toute machine de l'ensemble de compilation va installer. De plus, chaque machine de compilation devra avoir son nom de noyau défini avec KERNCONF dans /etc/make.conf, et la machine de compilation devrait tous les lister dans KERNCONF, en listant son noyau en premier. La machine de compilation doit avoir les fichiers de configuration des noyaux de chaque machine dans /usr/src/sys/arch/conf si elle va compiler leur noyau. Le système de base Maintenant que tout est configuré, vous êtes fin prêt pour tout compiler. Compilez le noyau et le monde sur la machine de compilation comme décrit dans la , mais n'installez rien. La compilation une fois termninée, allez sur la machine de test, et installez le noyau que vous venez juste de compiler. Si la machine monte /usr/src et /usr/obj via NFS, quand vous redémarrez en mode mono-utilisateur vous devrez activer le réseau et monter ces répertoires. La méthode la plus simple est de démarrer en mode multi-utilisateur, puis exécutez shutdown now pour passer en mode mono-utilisateur. Une fois à ce niveau, vous pouvez installer le nouveau noyau et monde puis exécuter mergemaster comme vous le feriez habituellement. Une fois cela effectué, redémmarez pour retourner en mode multi-utilisateur pour cette machine. Après que vous soyez certain que tout fonctionne correctement sur la machine de test, utilisez la même procédure pour installer le nouvel ensemble logiciel sur chacune des autres machines de l'ensemble de compilation. Les logiciels portés La même idée peut être utilisée pour le catalogue des logiciels portés. La première étape critique est de monter /usr/ports depuis la même machine vers toutes les machines de l'ensemble de compilation. Vous pouvez alors configurer correctement /etc/make.conf pour partager les archives. Vous devrez faire pointer DISTDIR sur un répertoire de partage commun dans lequel peut écrire n'importe quel utilisateur utilisé pour correspondance de l'utilisateur root par vos montages NFS. Chaque machine devrait faire pointer WRKDIRPREFIX sur une répertoire de compilation local. Et enfin, si vous projetez de compiler et distribuer des logiciels précompilés, vous devriez fixer PACKAGES sur un répertoire similaire à DISTDIR. diff --git a/fr_FR.ISO8859-1/books/handbook/desktop/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/desktop/chapter.sgml index 557b83f203..d7e1bacb0a 100644 --- a/fr_FR.ISO8859-1/books/handbook/desktop/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/desktop/chapter.sgml @@ -1,1347 +1,1409 @@ Christophe Juniet Contribution de Bureautique &trans.a.fonvieille; Synopsis FreeBSD peut faire fonctionner une large variété d'applications de bureautique, comme des navigateurs et des traitements de textes. La plupart de ces derniers sont disponibles sous forme pré-compilée ou peuvent être compilé automatiquement à partir du catalogue des logiciels portés. De nombreux utilisateurs s'attendent à trouver ces types d'applications dans leur environnement de travail. Ce chapitre vous montrera comment installer quelques unes des applications de bureautique les plus populaires sans trop d'effort, soit à partir de versions pré-compilées soit à partir du catalogue des logiciels portés. Notez que lorsque l'on installe des programmes à partir du catalogue des logiciels portés, ils sont compilés à partir des sources. Cela peut prendre un temps relativement long, en fonction de ce que vous compilez et de la puissance de votre machine. Si la compilation à partir des sources requiert un temps prohibitif, vous pouvez installer la plupart des programmes de l'arbre des ports à partir de version pré-compilées. Comme FreeBSD dispose d'un système de compatibilité avec les binaires Linux, de nombreuses applications développées à l'origine pour Linux sont disponibles pour votre environnement de travail. Il est vivement recommandé que vous lisiez le avant d'installer des applications Linux. De nombreux logiciels portés utilisant la compatibilité binaire Linux débutent avec le terme “linux-”. Souvenez-vous de cela quand vous recherchez un logiciel porté bien particulier, par exemple à l'aide de &man.whereis.1;. Dans le reste de ce chapitre on suppose que vous avez activé la compatibilité Linux avant d'installer des applications Linux. Voici les catégories d'applications couvertes par ce chapitre: Navigateurs (comme Mozilla, &netscape;, Opera, Firefox, Konqueror) Productivité (comme KOffice, AbiWord, The GIMP, OpenOffice.org) Lecteurs de document (comme &acrobat.reader;, gv, Xpdf, GQview) Finance (comme GnuCash, Gnumeric, Abacus) Avant de lire ce chapitre, vous devrez: Savoir comment installer des logiciels tiers (). Savoir comment installer des logiciels pour Linux (). Pour des informations sur comment mettre en place un environnement multimédia, lisez le . Si vous désirez configurer et utiliser le courrier électronique, veuillez vous référer au . Navigateurs FreeBSD n'est pas livré avec un navigateur particulier installé. Au lieu de cela, le répertoire www du catalogue des logiciels portés contient de nombreux navigateurs prêts à être installés. Si vous n'avez pas le temps de tout compiler (cela peut prendre un temps relativement long dans certains cas) nombres d'entre eux sont disponibles sous forme pré-compilée. KDE et GNOME fournissent déjà un navigateur HTML. Veuillez vous référer au pour plus d'information sur comment configurer ces environnements de travail. Si vous êtes à la recherche de navigateurs légers, vous devriez consulter le catalogue des logiciels portés pour www/dillo, www/links, ou www/w3m. Cette section couvre les applications suivantes: - + Nom de l'application Ressources nécessaires Installation à partir du catalogue des logiciels portés Dépendances principales Mozilla importantes lourde Gtk+ &netscape; importantes légère Compatibilité binaire Linux Opera faibles légère Version native FreeBSD et Linux disponibles. La version Linux dépend de la compatibilité binaire Linux et de linux-openmotif. Firefox moyennes lourde Gtk+ Konqueror moyennes lourde Bibliothèques KDE Mozilla Mozilla Mozilla est peut-être le navigateur le plus adapté pour votre bureau FreeBSD. Il est moderne, stable, et complètement porté pour FreeBSD. Il présente un moteur d'affichage HTML qui respecte vraiment les normes. Il fournit un lecteur de courrier électronique et forums. Il possède même un éditeur HTML si vous projetez d'écrire vous-même quelques pages Web. Les utilisateurs de &netscape; trouveront des similitudes avec la suite Communicator, étant donné que les deux navigateurs partagent la même base. Sur les machines lentes, avec une vitesse de processeur de moins de 233MHz ou avec moins de 64MO de RAM, Mozilla peut être trop consommateur en ressources pour être vraiment utilisable. Vous pourrez vouloir essayer à la place le navigateur Opera décrit plus tard dans ce chapitre. Si vous ne pouvez ou ne voulez compiler Mozilla pour une quelconque raison, l'équipe GNOME de FreeBSD l'a déjà fait pour vous. Installez juste la version pré-compilée à partir du réseau avec: &prompt.root; pkg_add -r mozilla Si la version pré-compilée n'est pas disponible, et que vous avez suffisamment de temps et d'espace disque, vous pouvez obtenir les sources pour Mozilla, le compiler et l'installer sur votre système. Cela s'effectue en faisant: &prompt.root; cd /usr/ports/www/mozilla &prompt.root; make install clean Le logiciel porté Mozilla s'assure d'une initialisation correcte en exécutant la configuration de la base de registre chrome avec les privilèges de root privilèges. Cependant si vous désirez récupérer des modules additionnels comme “mouse gestures”, vous devez exécuter Mozilla en tant que root pour obtenir une installation correcte de ces modules. Une fois que vous avez achevé l'installation de Mozilla, vous n'avez plus besoin d'être sous root. Vous pouvez lancer Mozilla en tant que navigateur en tapant: &prompt.user; mozilla Vous pouvez lancer directement les lecteurs de courrier électronique et de forums comme montré ci-dessous: &prompt.user; mozilla -mail Tom Rhodes Contribution de Mozilla, &java;, et ¯omedia; &flash; Installer Mozilla est simple, mais malheureusement isntaller Mozilla avec le support de modules additionnels comme &java; et ¯omedia; &flash; consomme beaucoup de temps et d'espace disque. La première chose à faire est de télécharger les fichiers qui seront utilisé avec Mozilla. Pointez votre navigateur Web vers et créez un compte sur leur site. Pensez à sauver quelque part le nom d'utilisateur et le mot de passe car ils seront nécessaires prochainement. Téléchargez une copie du fichier j2sdk-1_3_1-src.tar.gz et placez le dans le répertoire /usr/ports/distfiles/ comme le port ne le téléchagera pas automatiquement. Cela en raison de restriction de licence. Tant que nous y sommes, téléchargeons “l'environnement java” à partir de . Le nom du fichier est j2sdk-1_3_1_08-linux-i586.bin, et est assez gros (environ 25 mégaoctets!). Comme précédemment, ce ficheir doit être placé dans /usr/ports/distfiles/. Enfin téléchargez une copie du “java patchkit” à partir de l'adresse et placez-le dans /usr/ports/distfiles/. Installez le port java/jdk13 avec la commande classique make install clean puis installez le port www/flashpluginwrapper. Ce port nécessite emulators/linux_base qui est un port important en taille. Il est vrai que d'autres greffons &flash; existent, cependant ils n'ont jamais fonctionné dans mon cas. Installez le port www/mozilla, si Mozilla n'est pas déjà installé. Maintenant copiez les fichiers du greffon &flash; avec les commandes: &prompt.root; cp /usr/local/lib/flash/libflashplayer.so \ /usr/X11R6/lib/browser_plugins/libflashplayer_linux.so &prompt.root; cp /usr/local/lib/flash/ShockwaveFlash.class \ /usr/X11R6/lib/browser_plugins/ Maintenant ajoutez les lignes suivantes au début (juste en dessous de la ligne #!/bin/sh) de la procédure de démarrage de Mozilla: /usr/X11R6/bin/mozilla. LD_PRELOAD=/usr/local/lib/libflashplayer.so.1 export LD_PRELOAD Cela activera le greffon &flash;. Maintenant lancez juste Mozilla avec: &prompt.user; mozilla & Et cliquez sur l'option About Plug-ins du menu Help. Une liste devrait apparaître avec tous les greffons disponibles. &java; et &shockwave; &flash; devraient y être. &netscape; Netscape Le catalogue des logiciels portés contient plusieurs versions du navigateur &netscape;. Puisque les versions natives pour FreeBSD sont victimes d'un bogue de sécurité sérieux, leur installation est fortement déconseillée. A la place, utilisez une version plus récente pour Linux ou DIGITAL UNIX. La dernière version stable du navigateur &netscape; est la version &netscape; 7. Elle peut être installée à partir du catalogue des logiciels portés: &prompt.root; cd /usr/ports/www/linux-netscape6 &prompt.root; make install clean Il existe des versions localisées dans les catégories French, German, et Japanese du catalogue. Les versions &netscape; 4.x ne sont pas recommandées car elles ne sont pas conformes aux standards actuels. Cependant, &netscape; 7.x et les versions plus récentes ne sont disponibles que pour la plate-forme &i386;. Opera Opera Opera est un navigateur très rapide, complet, et respectant les standards. Il est disponible en deux versions: une version “native” pour FreeBSD et une version utilisant l'émulation Linux. Pour chaque système d'exploitation, il existe une version gratuite du navigateur affichant des publicités et affichant des publicités et une autre payante sans publicités qui peut être achetée sur le site d'Opera. Pour naviguer sur le Web avec la version FreeBSD d'Opera, installez la version pré-compilée: &prompt.root; pkg_add -r opera Certains sites FTP n'ont pas toutes les versions pré-compilées, mais le même résultat peut être obtenu avec le catalogue des logiciels portés en tapant: &prompt.root; cd /usr/port/www/opera &prompt.root; make install clean Pour installer la version Linux d'Opera, utilisez linux-opera à la place d'opera dans les exemples précédents. La version Linux est utile dans les situations demandants l'utilisation de greffons qui sont uniquement disponibles pour Linux, comme &acrobat.reader;. Dans tous les autres aspects, les versions FreeBSD et Linux sont identiques. Firefox Firefox Firefox est la génération suivante de navigateurs basés sur le code de Mozilla. Mozilla est une suite complète d'applications, comme un navigateur, un client de messagerie, un client de discussion et bien plus. Firefox est juste un navigateur, ce qui le rend plus petit et plus rapide. Installez la version pré-compilée du logiciel en tapant: &prompt.root; pkg_add -r firefox Vous pouvez également utiliser le catalogue des logiciels portés si vous désirez effectuer la compilation à partir des sources: &prompt.root; cd /usr/ports/www/firefox &prompt.root; make install clean Konqueror Konqueror Konqueror fait partie de KDE mais peut être également utilisé en dehors de KDE en installant x11/kdebase3. Konqueror est plus qu'un navigateur, c'est également un gestionnaire de fichiers et une visionneuse multimedia Konqueror est fourni avec un ensemble de greffons disponible dans misc/konq-plugins. Konqueror supporte également &flash; et un tutorial est disponible à l'adresse . Productivité Quand on parle de productivité, les nouveaux utilisateurs recherchent souvent une bonne suite bureautique ou un traitement de texte convivial. Bien que certains environnements de travail comme KDE fournissent déjà une suite de bureautique, il n'y a pas d'application par défaut dans ce domaine. FreeBSD fournit tout ce qui est nécessaire, indépendamment de votre environnement de travail. Cette section couvre les applications suivantes: - + Nom de l'application Ressources nécessaires Installation à partir du catalogue des logiciels portés Dépendances principales KOffice légères lourde KDE AbiWord légères lourde Gtk+ ou GNOME The Gimp légères lourde Gtk+ OpenOffice.org importantes très lourde GCC 3.1, &jdk; 1.3, Mozilla KOffice KOffice suite de bureautique KOffice La communauté KDE propose son environnement de travail avec une suite de bureautique qui peut être utilisée en dehors de KDE. Elle comprend quatre composants standard que l'on peut trouver dans d'autres suites. KWord est le traitement de texte, KSpread est le tableur, KPresenter est le programme pour gérer des présentations, et Kontour vous permet de créer des documents graphiques. Avant d'installer la dernière version de KOffice, soyez sûr d'avoir une version à jour de KDE. Pour installer KOffice à partir de la version pré-compilée, utilisez la commande suivante: &prompt.root; pkg_add -r koffice Si la version pré-compilée n'est pas disponible, vous pouvez utiliser le catalogue des logiciels portés. Par exemple, pour installer KOffice pour KDE3, faites: &prompt.root; cd /usr/ports/editors/koffice-kde3 &prompt.root; make install clean AbiWord AbiWord AbiWord est un traitement de texte gratuit similaire au niveau de l'apparence et de la prise en main à µsoft; Word. Il convient pour taper des lettres, des rapports, des mémos, et ainsi de suite. Il est très rapide, dispose de nombreuses fonctions, et très convivial. AbiWord peut importer et exporter dans de nombreux formats de fichiers, dont certains formats propriétaires comme le .doc de Microsoft. AbiWord est disponible sous forme pré-compilée. Vous pouvez l'installer avec: - &prompt.root; pkg_add -r AbiWord-gnome + &prompt.root; pkg_add -r AbiWord2 Si la version pré-compilée n'est pas disponible, il peut être compilé à partir du catalogue des logiciels portés. Le catalogue devra être plus à jour. Cela peut être fait de cette façon: - &prompt.root; cd /usr/ports/editors/AbiWord + &prompt.root; cd /usr/ports/editors/AbiWord2 &prompt.root; make install clean The GIMP The GIMP Pour la création et la retouche d'image The GIMP est un programme de manipulation d'image très sophistiqué. Il peut être utilisé comme un simple programme de dessin ou comme une suite de retouche d'image de qualité photo. Il supporte un grand nombre de modules additionnels et présente une interface de création de procédures. The GIMP peut lire et écrire dans un très grand nombre de formats de fichiers. Il supporte l'interfaçage avec des scanners et des tablettes graphiques. Vous pouvez installer la version pré-compilée en utilisant cette commande: &prompt.root; pkg_add -r gimp Si votre site FTP ne dispose pas de la version pré-compilée, vous pouvez utiliser le catalogue des logiciels portés. Le répertoire graphics du catalogue contient également le Manuel de The Gimp. Voici comment les installer: - &prompt.root; cd /usr/ports/graphics/gimp1 + &prompt.root; cd /usr/ports/graphics/gimp &prompt.root; make install clean &prompt.root; cd /usr/ports/graphics/gimp-manual-pdf &prompt.root; make install clean Le répertoire graphics du catalogue des logiciels portés contient la version de développement de The GIMP dans graphics/gimp-devel. - Des versions HTML et &postscript; du Manuel de - The Gimp sont dans - graphics/gimp-manual-html et - graphics/gimp-manual-ps. + Une version HTML du Manuel de The Gimp + est disponible à partir de graphics/gimp-manual-html. OpenOffice.org OpenOffice.org suite de bureautique OpenOffice.org OpenOffice.org comprend toutes les applications indispensables d'une suite de bureautique complète: un traitement de texte, un tableur, un programme de gestion de présentation, et un logiciel de dessin. Son interface utilisateur est très proche de celle d'autres suites de bureautique, et elle peut importer et exporter dans divers formats de fichiers populaires. Elle est disponible dans de nombreuses langues et cela pour l'interface, les correcteurs orthographiques, et les dictionnaires. Le traitement de texte d'OpenOffice.org utilise un format de fichier natif en XML pour augmenter la portabilité et la flexibilité. Le tableur dispose d'un langage de macro et il peut être interfacé avec des bases de données extérieures. OpenOffice.org est déjà stable et fonctionne en natif sous &windows;, &solaris;, Linux, FreeBSD, et &macos; X. Plus d'information à propos d'OpenOffice.org peut être trouvé sur le site Web d'OpenOffice. Pour une information spécifique à &os;, et pour télécharger directement les versions précompilées utilisez le site Web de - l'Equipe &os; + l'Equipe &os; de portage d'OpenOffice. Pour installer OpenOffice.org, faites: &prompt.root; pkg_add -r openoffice Une fois l'installation effective, vous devez exécuter le programme de configuration et sélectionner une . Exécutez cette commande en tant que l'utilisateur qui utilisera OpenOffice.org: &prompt.user; openoffice-setup Si les version pré-compilées d'OpenOffice.org ne sont pas disponibles, vous avez toujours la possibilité de compiler le logiciel porté. Cependant, vous devez garder à l'esprit que cela demande beaucoup d'espace disque et un temps de compilation relativement long. - &prompt.root; cd /usr/ports/editors/openoffice + &prompt.root; cd /usr/ports/editors/openoffice-1.1 &prompt.root; make install clean Une fois cela effectué, exécutez le programme de configuration en tant que l'utilisateur qui utilisera OpenOffice.org et sélectionnez une en faisant: - &prompt.user; cd /usr/ports/editors/openoffice + &prompt.user; cd /usr/ports/editors/openoffice-1.1 &prompt.user; make install-user Si vous désirez installer un version localisée, voici les versions portées disponibles: - + Langue Logiciel porté - - - Arabe - editors/openoffice-ar - - - - Danois - editors/openoffice-dk - - - - Espagnol - editors/openoffice-es - - - - Grec - editors/openoffice-gr - - - - Italien - editors/openoffice-it - - - - Hollandais - editors/openoffice-nl - - - - Suédois - editors/openoffice-se - - - - Turc - editors/openoffice-tr - - - - Français - french/openoffice - - - - Allemand - german/openoffice - - - - Japonais - japanese/openoffice - - - - Coréen - korean/openoffice - - - - Polonais - polish/openoffice - - - - Portugais - portuguese/openoffice - - - - Russe - russian/openoffice - - - + + + Catalan + editors/openoffice-1.1-ca + + + + Tchèque + editors/openoffice-1.1-cs + + + + Danois + editors/openoffice-1.1-dk + + + + Grec + editors/openoffice-1.1-el + + + + Espagnol + editors/openoffice-1.1-es + + + + Estonien + editors/openoffice-1.1-et + + + + Finlandais + editors/openoffice-1.1-fi + + + + Italien + editors/openoffice-1.1-it + + + + Hollandais + editors/openoffice-1.1-nl + + + + Suédois + editors/openoffice-1.1-se + + + + Slovaque + editors/openoffice-1.1-sk + + + + Slovène + editors/openoffice-1.1-sl_SI + + + + Turc + editors/openoffice-1.1-tr + + + + Arabe + arabic/openoffice-1.1 + + + + Chinois (simplifié) + chinese/openoffice-1.1-zh_CN + + + + Chinois (traditionnel) + chinese/openoffice-1.1-zh_TW + + + + Français + french/openoffice-1.1 + + + + Allemand + german/openoffice-1.1 + + + + Hongrois + hungarian/openoffice-1.1 + + + + Japonais + japanese/openoffice-1.1 + + + + Coréen + korean/openoffice-1.1 + + + + Polonais + polish/openoffice-1.1 + + + + Portugais (Brésil) + portuguese/openoffice-1.1-pt_BR + + + + Portugais + portuguese/openoffice-1.1-pt_PT + + + + Russe + russian/openoffice-1.1 + + + Lecteurs de document Certains nouveaux formats de documentation ont récemment gagné en popularité. Les lecteurs standard qu'ils nécessitent peuvent ne pas être disponibles dans le système de base. Nous verrons, dans cette section, comment les installer. Cette section couvre les applications suivantes: - + Nom de l'application Ressources nécessaires Installation à partir du catalogue des logiciels portés Dépendances principales &acrobat.reader; faibles légère Compatibilité binaire Linux gv faibles légère Xaw3d Xpdf faibles légère FreeType GQview faibles légère Gtk+ ou GNOME &acrobat.reader; Acrobat Reader PDF lecture De nombreux documents sont désormais distribués sous forme de fichiers PDF, qui signifie “Format Portable de Document” - Portable Document Format. Un des lecteurs recommandé est &acrobat.reader;, sorti par Adobe pour Linux. Comme FreeBSD peut exécuter les binaires Linux, il est également disponible pour FreeBSD. Pour installer la version pré-compilée d'&acrobat.reader; 5, faire: - &prompt.root; pkg_add -r acroread5 + &prompt.root; pkg_add -r acroread Comme à l'accoutumé, si la version pré-compilée n'est pas disponible ou que vous désirez la toute dernière version, vous pouvez également utiliser le catalogue des logiciels portés: &prompt.root; cd /usr/ports/print/acroread5 &prompt.root; make install clean - - &acrobat.reader; est - disponible sous différentes versions. A l'heure de - l'écriture de ces lignes, existent: - print/acroread (version 3.0.2), - print/acroread4 (version 4.0.5), et - print/acroread5 (version 5.0.6). - Elles peuvent ne pas avoir été - pré-compilées pour votre version de FreeBSD. - Le catalogue des logiciels portés contiendra toujours la toute - dernière version. - gv gv PDF lecture PostScript lecture gv un lecteur de fichier &postscript; et PDF. Il est a l'origine basé sur ghostview mais présente un plus bel aspect grâce à la bibliothèque Xaw3d. Il est rapide et son interface est simple. gv possède de nombreuses fonctionnalités comme l'orientation, le format du papier, l'échelle, l'anticrénelage. Presque toutes les opérations peuvent être effectuées soit à partir du clavier soit à la souris. Pour installer gv à partir de la version pré-compilée, faites: &prompt.root; pkg_add -r gv Si vous ne pouvez obtenir la version pré-compilée, vous pouvez utiliser le catalogue des logiciels portés: &prompt.root; cd /usr/ports/print/gv &prompt.root; make install clean Xpdf Xpdf PDF lecture Si vous désirez un petit lecteur de fichiers PDF, Xpdf est léger et efficace. Il demande très peu de ressources et est très stable. Il utilise les polices de caractères standards de X et ne requiert pas &motif; ou tout autre ensemble d'éléments graphiques pour X. Pour installer la version pré-compilée d'Xpdf utilisez la commande suivante: &prompt.root; pkg_add -r xpdf Si la version pré-compilée n'est pas disponible ou que vous préfériez utiliser le catalogue des logiciels portés, faites: &prompt.root; cd /usr/ports/graphics/xpdf &prompt.root; make install clean Une fois l'installation achevée, vous pouvez lancer Xpdf et utiliser le bouton droit de la souris pour activer le menu. GQview GQview GQview est un gestionnaire d'image. Vous pouvez visualiser un fichier avec un simple clic, lancer un éditeur externe, obtenir une pré-visualisation par vignettes, et bien plus. Il propose également un mode présentation et quelques possibilités d'opérations sur fichiers de base. Vous pouvez gérer des collections d'images et trouver facilement les doublons. GQview supporte l'affichage plein écran et l'internationalisation de l'interface. Si vous désirez installer la version pré-compilée de GQview, faites: &prompt.root; pkg_add -r gqview Si la version pré-compilée n'est pas disponible ou que vous préférez utiliser le catalogue des logiciels portés, faites: &prompt.root; cd /usr/ports/graphics/gqview &prompt.root; make install clean Finance Si, pour diverses raisons, vous voudriez gérer vos finances personnelles sous FreeBSD, il existe quelques applications puissantes et simples d'emploi prêtes à être installées. Certaines d'entre elles sont compatibles avec des formats de fichiers très répandus comme ceux des documents Quicken ou Excel. Cette section couvre les applications suivantes: - + Nom de l'application Ressources nécessaires Installation à partir du catalogue des logiciels portés Dépendances principales GnuCash faibles lourde GNOME Gnumeric faibles lourde GNOME Abacus faibles légère Tcl/Tk GnuCash GnuCash GnuCash fait partie de l'effort GNOME en vue de fournir des applications puissantes et conviviales pour l'utilisateur final. Avec GnuCash, vous pouvez suivre vos crédits et débits, vos comptes bancaires, ou vos actions. Il présente une interface intuitive tout en restant très professionnel. GnuCash fournit un registre intelligent, un système hiérarchique pour les comptes, de nombreux raccourcis clavier et des systèmes d'autocomplémentation de la frappe au clavier. Il peut diviser une simple transaction en plusieurs étapes plus détaillées. GnuCash peut importer et fusionner des fichiers QIF de Quicken. Il supporte également la plupart des formats internationaux de date et de monnaies. Pour installer GnuCash sur votre système, faites: &prompt.root; pkg_add -r gnucash Si la version pré-compilée n'est pas disponible, vous pouvez utiliser le catalogue des logiciels portés: &prompt.root; cd /usr/ports/finance/gnucash &prompt.root; make install clean Gnumeric Gnumeric tableur Gnumeric Gnumeric est un tableur, faisant partie de l'environnement de travail GNOME. Il dispose d'un système automatique “devinant” le type d'entrée de l'utilisateur en fonction du format de la cellule et d'un système de remplissage automatique pour de nombreuses séquences d'utilisation. Il peut importer des fichiers de nombreux formats populaires comme ceux d'Excel, Lotus 1-2-3, ou Quattro Pro. Gnumeric supporte l'affichage de graphiques grâce au programme de tracé math/guppi. Il dispose d'un grand nombre de fonctions intégrées et permet tous les formats de cellule habituels comme le format numérique, monétaire, date, temps, et bien plus. Pour installer Gnumeric sous forme pré-compilée, tapez: &prompt.root; pkg_add -r gnumeric Si la version pré-compilée n'est pas disponible, vous pouvez utiliser le catalogue des logiciels portés en faisant: &prompt.root; cd /usr/ports/math/gnumeric &prompt.root; make install clean Abacus Abacus tableur Abacus Abacus est un tableur léger et facile d'emploi. Il incorpore de nombreuses fonctions utiles dans plusieurs domaines comme les statistiques, la finance, et les mathématiques. Il peut importer et exporter en format Excel. Abacus peut produire des sorties en &postscript;. Pour installer Abacus à partir de la version pré-compilée, faites: &prompt.root; pkg_add -r abacus Si la version pré-compilée n'est pas disponible, vous pouvez utiliser le catalogue des logiciels portés en faisant: &prompt.root; cd /usr/ports/deskutils/abacus &prompt.root; make install clean Résumé Alors que FreeBSD est populaire parmi les fournisseurs d'accès à Internet pour ses performances et sa stabilité, il est quasiment prêt pour une utilisation quotidienne en tant que station de travail. Avec plusieurs milliers d'applications disponibles sous forme pré-compilées ou dans le catalogue des logiciels portés, vous pouvez vous construire l'environnement de travail qui vous conviendra le mieux. Une fois l'installation de votre environnement de travail, vous pourrez vouloir aller plus loin avec misc/instant-workstation. Ce “meta-logiciel porté” vous permet de compiler un ensemble typique de logiciels portés pour une station de travail. Vous pouvez le personnaliser en éditant le fichier /usr/ports/misc/instant-workstation/Makefile. Suivez la syntaxe utilisée pour l'ensemble par défaut pour ajouter ou retirer des logiciels, et les compiler suivant la procédure habituelle. Par la suite, vous pourrez créer un gros “package” qui correspond à votre environnement de travail personnel et l'installer sur vos autres stations de travail! Voici un bref rappel de toutes les applications abordées dans ce chapitre: - + Nom de l'application Nom du logiciel pré-compilé Nom du logiciel porté Mozilla mozilla www/mozilla &netscape; linux-netscape7 www/netscape7 Opera - linux-opera - www/linux-opera + opera + www/opera Firefox firefox www/firefox KOffice koffice-kde3 editors/koffice-kde3 AbiWord - AbiWord-gnome - editors/AbiWord + AbiWord2 + editors/AbiWord2 The GIMP gimp - graphics/gimp1 + graphics/gimp OpenOffice.org openoffice - editors/openoffice + editors/openoffice-1.1 &acrobat.reader; - acroread5 + acroread print/acroread5 gv gv print/gv Xpdf xpdf graphics/xpdf GQview gqview graphics/gqview GnuCash gnucash finance/gnucash Gnumeric gnumeric math/gnumeric Abacus abacus deskutils/abacus