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 928e6f5685..36f116afa3 100644 --- a/fr_FR.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,8988 +1,9714 @@ Administration réseau avancée &trans.a.fonvieille; Synopsis Ce chapitre abordera certains des services réseaux les plus fréquemment utilisés sur les systèmes &unix;. Nous verrons comment définir, mettre en place, tester et maintenir tous les services réseaux qu'utilise &os;. De plus, des exemples de fichier de configuration ont été inclus tout au long de ce chapitre pour que vous puissiez en bénéficier. 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 système de fichiers réseau. Comment configurer le démarrage via le réseau pour une machine sans disque dur. Comment mettre en place un serveur d'information sur le réseau pour partager les comptes utilisateurs. Comment configurer le paramétrage réseau automatique en utilisant DHCP. Comment configurer un serveur de noms de domaine. Comment synchroniser l'heure et la date, et mettre en place en serveur de temps, avec le protocole NTP. Comment configurer la translation d'adresse réseau. Comment gérer le “daemon” inetd. 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. 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 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). - - Bluetooth ** Traduction en Cours ** - + + + + 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. Tom Rhodes Réorganisé et augmenté par Bill Swingle Ecrit par NFS NFS Parmi les différents systèmes de fichiers que &os; supporte se trouve le système de fichiers réseaux, connu sous le nom de NFS. NFS permet à un système de partager des répertoires et des fichiers avec d'autres systèmes par l'intermédiaire d'un réseau. En utilisant NFS, les utilisateurs et les programmes peuvent accéder aux fichiers sur des systèmes distants comme s'ils étaient des fichiers locaux. Certains des avantages les plus remarquables offerts par NFS sont: Les stations de travail utilisent moins d'espace disque en local parce que les données utilisées en commun peuvent être stockées sur une seule machine tout en restant accessibles aux autres machines sur le réseau. Les utilisateurs n'ont pas besoin d'avoir un répertoire personnel sur chaque machine du réseau. Les répertoires personnels pourront se trouver sur le serveur NFS et seront disponibles par l'intermédiaire du réseau. Les périphériques de stockage comme les lecteurs de disquettes, de CDROM, de disquettes ZIP peuvent être utilisés par d'autres machines sur le réseau. Cela pourra réduire le nombre de lecteurs de medias amovibles sur le réseau. Comment <acronym>NFS</acronym> fonctionne NFS consiste en deux éléments principaux: un serveur et un ou plusieurs clients. Le client accède à distance aux données stockées sur la machine serveur. Afin que tout cela fonctionne correctement quelques processus doivent être configurés et en fonctionnement. Avec &os; 5.X, l'utilitaire portmap a été remplacé par rpcbind. Aussi sous &os; 5.X l'utilisateur doit remplacer chaque instance de portmap avec rpcbind dans les exemples qui suivent. Sur le serveur, les “daemons” suivants doivent tourner: NFS serveur portmap mountd nfsd Daemon Description nfsd Le “daemon” NFS qui répond aux requêtes des clients NFS. mountd Le “daemon” de montage NFS qui traite les requêtes que lui passe &man.nfsd.8;. portmap Le “daemon portmapper” permet aux clients NFS de trouver le port que le serveur NFS utilise. Le client peut également faire tourner un “daemon” connu sous le nom de nfsiod. Le “daemon” nfsiod traite les requêtes en provenance du serveur NFS. Ceci est optionnel, et améliore les performances, mais n'est pas indispensable pour une utilisation normale et correcte. Consultez la page de manuel &man.nfsiod.8; pour plus d'informations. Configurer <acronym>NFS</acronym> NFS configuration La configuration de NFS est une opération relativement directe. Les processus qui doivent tourner peuvent tous être lancés au démarrage en modifiant légèrement votre fichier /etc/rc.conf. Sur le serveur NFS, assurez-vous que les options suivantes sont configurées dans le fichier /etc/rc.conf: portmap_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd est automatiquement exécuté dès que le serveur NFS est activé. Sur le client, assurez-vous que cette option est présente dans le fichier /etc/rc.conf: nfs_client_enable="YES" Le fichier /etc/exports indique quels systèmes de fichiers NFS devraient être exportés (parfois on utilise le terme de “partagés”). Chaque ligne dans /etc/exports précise un système de fichiers à exporter et quelles machines auront accès à ce système de fichiers. En plus des machines qui auront accès, des options d'accès peuvent également être présentes. Ces options sont nombreuses mais seules quelques unes seront abordées ici. Vous pouvez aisément découvrir d'autres options en lisant la page de manuel &man.exports.5;. Voici quelques exemples d'entrées du fichier /etc/exports: NFS exemples d'exportation Les exemples suivants donnent une idée de comment exporter des systèmes de fichiers bien que certains paramètres peuvent être différents en fonction de votre environnement et votre configuration réseau. Par exemple, pour exporter le répertoire /cdrom pour les trois machines d'exemple qui appartiennent au même domaine que le serveur (d'où l'absence du nom de domaine pour chacune d'entre elles) ou qui ont une entrée dans votre fichier /etc/hosts. Le paramètre limite l'accès en lecture seule au système de fichiers exporté. Avec ce paramètre, le système distant ne pourra pas écrire sur le système de fichiers exporté. /cdrom -ro host1 host2 host3 La ligne suivante exporte /home pour les trois machines en utilisant les adresses IP. C'est une configuration utile si vous disposez d'un réseau privé sans serveur DNS configuré. Le fichier /etc/hosts pourrait éventuellement être configuré pour les noms de machines internes, consultez la page de manuel &man.hosts.5; pour plus d'information. Le paramètre autorise l'utilisation des sous-répertoires en tant que point de montage. En d'autres termes, il ne montera pas les sous-répertoires mais autorisera le client à ne monter que les répertoires qui sont nécessaires ou désirés. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 La ligne suivante exporte /a pour que deux clients d'un domaine différent puissent y accéder. Le paramètre autorise l'utilisateur root du système distant à écrire des données sur le système de fichiers exporté en tant que root. Si le paramètre -maproot=root n'est pas précisé, même si un utilisateur dispose d'un accès root sur le système distant, il ne pourra pas modifier de fichiers sur le système de fichiers exporté. /a -maproot=root host.example.com box.example.org Afin de pouvoir accéder à un système de fichiers exporté, le client doit avoir les permissions de le faire. Assurez-vous que le client est mentionné dans votre fichier /etc/exports. Dans /etc/exports, chaque ligne représente l'information d'exportation d'un système de fichiers vers une machine. Une machine distante ne peut être spécifiée qu'une fois par système de fichiers, et ne devrait avoir qu'une seule entrée par défaut. Par exemple, supposons que /usr soit un seul système de fichiers. Le fichier /etc/exports suivant serait invalide: /usr/src client /usr/ports client Un système de fichiers, /usr, a deux lignes précisant des exportations vers la même machine, client. Le format correct pour une telle situation est: /usr/src /usr/ports client Les propriétes d'un système de fichiers exporté vers une machine donnée devraient apparaître sur une ligne. Les lignes sans client sont traitées comme destinée à une seule machine. Cela limite la manière dont vous pouvez exporter les systèmes de fichiers, mais pour la plupart des gens cela n'est pas un problème. Ce qui suit est un exemple de liste d'exportation valide, où les répertoires /usr et /exports sont des systèmes de fichiers locaux: # Exporte src et ports vers client01 et client02, mais seul # client01 dispose des privilèges root dessus /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # Les machines clientes ont les privilèges root et peuvent monter tout # de /exports. N'importe qui peut monter en lecture seule # /exports/obj /exports -alldirs -maproot=root client01 client02 /exports/obj -ro Vous devez relancer mountd à chaque fois que vous modifiez /etc/exports pour que les changements puissent prendre effet. Cela peut être effectué en envoyant le signal HUP au processus mountd: &prompt.root; kill -HUP `cat /var/run/mountd.pid` De plus, un redémarrage permettra à &os; de tout configurer proprement. Un redémarrage n'est cependant pas nécéssaire. Exécuter les commandes suivantes en tant que root devrait mettre en place ce qui est nécessaire. Sur le serveur NFS: &prompt.root; portmap &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Sur le client NFS: &prompt.root; nfsiod -n 4 Maintenant il devrait être possible de monter un système de fichiers distant. Dans nos exemples le nom du serveur sera serveur et le nom du client client. Si vous voulez monter temporairement un système de fichiers distant ou vous voulez simplement tester la configuration, exécutez juste une commande comme celle-ci en tant que root sur le client: NFS montage &prompt.root; mount serveur:/home /mnt Cela montera le répertoire /home situé sur le serveur au point /mnt sur le client. Si tout est correctement configuré vous devriez être en mesure d'entrer dans le répertoire /mnt sur le client et de voir tous les fichiers qui sont sur le serveur. Si vous désirez monter automatiquement un système de fichiers distant à chaque démarrage de l'ordinateur, ajoutez le système de fichiers au fichier /etc/fstab. Voici un exemple: server:/home /mnt nfs rw 0 0 La page de manuel &man.fstab.5; liste toutes les options disponibles. Exemples pratiques d'utilisation Il existe de nombreuses applications pratiques de NFS. Les plus communes sont présentés ci-dessous: NFS utilisations Configurer plusieurs machines pour partager un CDROM ou un autre médium. C'est moins cher et souvent une méthode plus pratique pour installer des logiciels sur de multiples machines. Sur les réseaux importants, il peut être plus pratique de configurer un serveur NFS central sur lequel tous les répertoires utilisateurs sont stockés. Ces répertoires utilisateurs peuvent alors être exportés vers le réseau, les utilisateurs devraient alors toujours avoir le même répertoire utilisateur indépendamment de la station de travail sur laquelle ils ouvrent une session. Plusieurs machines pourront avoir un répertoire /usr/ports/distfiles commun. De cette manière, quand vous avez besoin d'installer un logiciel porté sur plusieurs machines, vous pouvez accéder rapidement aux sources sans les télécharger sur chaque machine. Wylie Stilwell Contribution de Chern Lee Réécrit par Montages automatiques avec <application>amd</application> amd daemon de montage automatique &man.amd.8; (“automatic mounter daemon”—“daemon” de montage automatique) monte automatiquement un système de fichiers distant dès que l'on accède à un fichier ou un répertoire contenu par ce système de fichiers. Les systèmes de fichiers qui sont inactifs pendant une certaine période seront automatiquement démontés par amd. L'utilisation d'amd offre une alternative simple aux montages permanents qui sont généralement listés dans /etc/fstab. amd opère en s'attachant comme un serveur NFS aux répertoires /host et /net. Quand on accède à un fichier à l'intérieur de ces répertoires, amd recherche le montage distant correspondant et le monte automatiquement. /net est utilisé pour monter un système de fichiers exporté à partir d'une adresse IP, alors que /host est utilisé pour monter un système de fichiers exporté à partir d'un nom de machine distant. Un accès à un fichier dans /host/foobar/usr demandera à amd de tenter de monter l'export /usr sur la machine foobar. Monter un systèmes de fichiers exporté avec <application>amd</application> Vous pouvez voir les systèmes de fichiers exportés par une machine distante avec la commande showmount. Par exemple, pour voir les répertoires exportés par une machine appelée foobar, vous pouvez utiliser: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr Comme on le voit dans l'exemple, showmount liste /usr comme une exportation. Quand on change de répertoire pour /host/foobar/usr, amd tente de résoudre le nom de machine foobar et de monter automatiquement le système exporté désiré. amd peut être lancé par les procédures de démarrage en ajoutant les lignes suivantes dans le fichier /etc/rc.conf: amd_enable="YES" De plus, des paramètres peuvent être passés à amd à l'aide de l'option amd_flags. Par défaut, l'option amd_flags est possitionnée à: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" Le fichier /etc/amd.map définit les options par défaut avec lesquelles les systèmes exportés sont montés. Le fichier /etc/amd.map définit certaines des fonctionnalités les plus avancées de amd. Consultez les pages de manuel de &man.amd.8; et &man.amd.conf.5; pour plus d'informations. John Lind Contribution de Problèmes d'intégration avec d'autres systèmes Certaines cartes Ethernet ISA présentent des limitations qui peuvent poser de sérieux problèmes sur un réseau, en particulier avec NFS. Ce n'est pas une particularité de &os;, mais &os; en est également affecté. Ce problème se produit pratiquement à chaque fois que des systèmes (&os;) PC sont sur le même réseau que des stations de travail très performantes, comme celles de Silicon Graphics, Inc. et Sun Microsystems, Inc. Les montages NFS se feront sans difficulté, et certaines opérations pourront réussir, puis soudain le serveur semblera ne plus répondre au client, bien que les requêtes vers ou en provenance d'autres systèmes continueront à être traitées normalement. Cela se manisfeste sur la machine cliente, que ce soit le système &os; ou la station de travail. Sur de nombreux systèmes, il n'est pas possible d'arrêter le client proprement une fois que ce problème apparaît. La seule solution est souvent de réinitialiser le client parce que le problème NFS ne peut être résolu. Bien que la solution “correcte” est d'installer une carte Ethernet plus performante et de plus grande capacité sur le système &os;, il existe une solution simple qui donnera satisfaction. Si le système &os; est le serveur, ajoutez l'option lors du montage sur le client. Si le système &os; est le client, alors montez le système de fichiers NFS avec l'option . Ces options peuvent être spécifiées dans le quatrième champ de l'entrée fstab sur le client pour les montages automatiques, ou en utilisant le paramètre de la commande &man.mount.8; pour les montages manuels. Il faut noter qu'il existe un problème différent, que l'on confond parfois avec le précédent, qui peut se produire lorsque les serveurs et les clients NFS sont sur des réseaux différents. Si c'est le cas, assurez-vous que vos routeurs transmettent bien les informations UDP nécessaires, ou vous n'irez nulle part, quoi que vous fassiez par ailleurs. Dans les exemples suivants, fastws est le nom de la station de travail (interface) performante, et freebox celui d'une machine (interface) &os; avec une carte Ethernet moins performante. /sharedfs est le système de fichiers NFS qui sera exporté (consulter la page de manuel &man.exports.5;), et /project sera le point de montage sur le client pour le système de fichiers exporté. Dans tous les cas, des options supplémentaires, telles que et seront peut-être nécessaires pour vos applications. Exemple d'extrait du fichier /etc/fstab sur freebox quand le système &os; (freebox) est le client: fastws:/sharedfs /project nfs rw,-r=1024 0 0 Commande de montage manuelle sur freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Exemple d'extrait du fichier /etc/fstab sur fastws quand le système &os; est le serveur: freebox:/sharedfs /project nfs rw,-w=1024 0 0 Commande de montage manuelle sur fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Presque n'importe quelle carte Ethernet 16 bits permettra d'opérer sans l'utilisation des paramètres restrictifs précédents sur les tailles des tampons de lecture et d'écriture. Pour ceux que cela intéresse, voici ce qui se passe quand le problème survient, ce qui explique également pourquoi ce n'est pas récupérable. NFS travaille généralement avec une taille de “bloc” de 8 k (bien qu'il arrive qu'il les fragmente en de plus petits morceaux). Comme la taille maximale d'un paquet Ethernet est de 1500 octets, le “bloc” NFS est divisé en plusieurs paquets Ethernet, bien qu'il soit toujours vu comme quelque chose d'unitaire par les couches supérieures du code, et doit être réceptionné, assemblé, et acquitté comme tel. Les stations de travail performantes peuvent traiter les paquets qui composent le bloc NFS les uns après les autres, pratiquement aussi rapidement que le standard le permet. Sur les cartes les plus petites, de moindre capacité, les derniers paquets d'un même bloc écrasent les paquets précédents avant qu'ils aient pû être transmis à la machine et le bloc ne peut être réassemblé ou acquitté. Avec pour conséquence, le dépassement du délai d'attente sur la station de travail qui recommence alors la transmission, mais en renvoyant l'intégralité des 8 K, et ce processus se repète à l'infini. En définissant la taille de bloc inférieure à la taille d'un paquet Ethernet, nous nous assurons que chaque paquet Ethernet complet sera acquitté individuellement, évitant ainsi la situation de blocage. Des écrasements peuvent toujours survenir quand des stations de travail performantes surchargent un système PC de données, mais avec de meilleures cartes, de tels écrasements ne sont pas systématiques pour les “blocs” NFS. Quand un écrasement apparaît, les blocs affectés sont retransmis, et ils y a de fortes chances pour qu'ils soient reçus, assemblés et acquittés. 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. Veuillez vous référer au pour des informations sur les logiciels portés et les logiciels pré-compilés. 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. Bill Swingle Ecrit par Eric Ogren Augmenté par Udo Erdelhoff NIS/YP Qu'est-ce que c'est? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS, qui signifie “Network Information Services” (services d'information réseau), fut développé par Sun Microsystems pour centraliser l'administration de systèmes &unix; (à l'origine &sunos;). C'est devenu aujourd'hui un standard industriel; tous les systèmes importants de type &unix; (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os;, etc.) supportent NIS. yellow pagesNIS NIS était appelé au départ “Yellow Pages” (page jaunes), mais étant donné que c'était marque déposée, Sun changea le nom. L'ancienne appelation (et yp) est toujours rencontrée et utilisée. NIS domaines C'est un système client/serveur basé sur les RPCs qui permet à un groupe de machines d'un domaine NIS de partager un ensemble de fichiers de configuration communs. Cela permet à un administrateur système de mettre en place des clients NIS avec un minimum de configuration et d'ajouter, modifier ou supprimer les informations de configuration à partir d'un unique emplacement. Windows NT C'est similaire au système de domaine &windowsnt;; bien que l'implémentation interne des deux n'est pas du tout identique, les fonctionnalités de base sont comparables. Termes/processus à connaître Il existe plusieurs termes et processus utilisateurs que vous rencontrerez lors de la configuration de NIS sous &os;, que vous vouliez mettre en place un serveur NIS ou un client NIS: portmap Terme Description Nom de domaine NIS Un serveur maître NIS et tous ses clients (y compris ses serveurs esclaves) ont un domaine NIS. Similaire au nom de domaine &windowsnt;, le nom de domaine NIS n'a rien à voir avec le système DNS. portmap Doit tourner afin d'activer les RPC (Remote Procedure Call, appel de procédures distantes, un protocole réseau utilisé par NIS). Si portmap ne tourne pas, il sera impossible de faire fonctionner un serveur NIS, ou jouer le rôle d'un client NIS. ypbind Fait pointer un client NIS vers son serveur NIS. Il récupérera le nom de domaine NIS auprès du système, et en utilisant les RPC, se connectera au serveur. ypbind est le coeur de la communication client-serveur dans un environnement NIS; si ypbind meurt sur une machine cliente, elle ne sera pas en mesure d'accéder au serveur NIS. ypserv Ne devrait tourner que sur les serveurs NIS, c'est le processus serveur en lui-même. Si &man.ypserv.8; meurt, alors le serveur ne pourra plus répondre aux requêtes NIS (avec un peu de chance, un serveur esclave prendra la relève). Il existe des implémentations de NIS (mais ce n'est pas le cas de celle de &os;), qui n'essayent pas de se reconnecter à un autre serveur si le serveur utilisé précédement meurt. Souvent, la seule solution dans ce cas est de relancer le processus serveur (ou même redémarrer le serveur) ou le processus ypbind sur le client. rpc.yppasswdd Un autre processus qui ne devrait tourner que sur les serveurs maître NIS; c'est un “daemon” qui permettra aux clients de modifier leur mot de passe NIS. Si ce “daemon” ne tourne pas, les utilisateurs devront ouvrir une session sur le serveur maître NIS et y changer à cet endroit leur mot de passe. Comment cela fonctionne-t-il? Dans un environnement NIS il y a trois types de machines: les serveurs maîtres, les serveurs esclaves et les clients. Les serveurs centralisent les informations de configuration des machines. Les serveurs maîtres détiennent l'exemplaire de référence de ces informations, tandis que les serveurs esclaves en ont un double pour assurer la redondance. Les clients attendent des serveurs qu'ils leur fournissent ces informations. Le contenu de nombreux fichiers peut être partagé de cette manière. Les fichiers master.passwd, group, et hosts sont fréquemment partagés par l'intermédiaire de NIS. A chaque fois qu'un processus d'une machine cliente a besoin d'une information qu'il trouverait normalement localement dans un de ces fichiers, il émet une requête au serveur NIS auquel il est rattaché pour obtenir cette information. Type de machine NIS serveur maître Un serveur NIS maître. Ce serveur, analogue à un contrôleur de domaine &windowsnt; primaire, gère les fichiers utilisés par tous les clients NIS. Les fichiers passwd, group, et les autres fichiers utilisés par les clients NIS résident sur le serveur maître. Il est possible pour une machine d'être un serveur NIS maître pour plus qu'un domaine NIS. Cependant, ce cas ne sera pas abordé dans cette introduction, qui suppose un environnement NIS relativement petit. NIS serveur esclave Serveurs NIS esclaves. Similaire aux contrôleurs de domaine &windowsnt; de secours, les serveurs NIS esclaves possèdent une copie des fichiers du serveur NIS maître. Les serveurs NIS esclaves fournissent la redondance nécessaire dans les environnements importants. Ils aident également à à la répartition de la charge du serveur maître: les clients NIS s'attachent toujours au serveur NIS dont ils reçoivent la réponse en premier, y compris si c'est la réponse d'un serveur esclave. NIS client Clients NIS. Les clients NIS, comme la plupart des stations de travail &windowsnt;, s'identifient auprès du serveur NIS (ou le contrôleur de domaine &windowsnt; dans le cas de stations de travail &windowsnt;) pour l'ouverture de sessions. Utiliser NIS/YP Cette section traitera de la configuration d'un exemple d'environnement NIS. Dans cette section on suppose que vous utilisez &os; 3.3 ou une version suivante. Les instructions fournies fonctionneront probabablement avec n'importe quelle version de &os; supérieure à 3.0, mais il n'y a aucune garantie que cela soit le cas. Planification Supposons que vous êtes l'administrateur d'un petit laboratoire universitaire. Ce laboratoire dispose de 15 machines &os;, et ne possède pas actuellement de point central d'administration; chaque machine a ses propres fichiers /etc/passwd et /etc/master.passwd. Ces fichiers sont maintenus à jour entre eux grâce à des interventions manuelles; actuellement quand vous ajoutez un utilisateur pour le laboratoire, vous devez exécuter adduser sur les 15 machines. Cela doit changer, vous avez donc décidé de convertir le laboratoire à l'utilisation de NIS en utilisant deux machines comme serveurs. La configuration du laboratoire ressemble à quelque chose comme: Nom de machine Adresse IP Rôle de la machine ellington 10.0.0.2 Maître NIS coltrane 10.0.0.3 Esclave NIS basie 10.0.0.4 Station de travail bird 10.0.0.5 Machine cliente cli[1-11] 10.0.0.[6-17] Autres machines clientes Si vous mettez en place un système NIS pour la première fois, c'est une bonne idée de penser à ce que vous voulez en faire. Peu importe la taille de votre réseau, il y a quelques décisions à prendre. Choisir un nom de domaine NIS NIS nom de domaine Ce n'est pas le “nom de domaine” dont vous avez l'habitude. Il est plus exactement appelé “nom de domaine NIS”. Quand un client diffuse des requêtes pour obtenir des informations, il y inclut le nom de domaine NIS auquel il appartient. C'est ainsi que plusieurs serveurs d'un même réseau peuvent savoir lequel d'entre eux doit répondre aux différentes requêtes. Pensez au nom de domaine NIS comme le nom d'un groupe de machines qui sont reliées entre elles. Certains choississent d'utiliser leur nom de domaine Internet pour nom de domaine NIS. Ce n'est pas conseillé parce que c'est une source de confusion quand il faut résoudre un problème réseau. Le nom de domaine NIS devrait être unique sur votre réseau et est utile s'il décrit le groupe de machines qu'il représente. Par exemple, le département artistique de Acme Inc. pourrait avoir “acme-art” comme nom de domaine NIS. Pour notre exemple, nous supposerons que vous avez choisi le nom test-domain. SunOS Cependant, certains systèmes d'exploitation (notamment &sunos;) utilisent leur nom de domaine NIS pour nom de domaine Internet. Si une ou plusieurs machines sur votre réseau présentent cette restriction, vous devez utiliser votre nom de domaine Internet pour nom de domaine NIS. Contraintes au niveau du serveur Il y a plusieurs choses à garder à l'esprit quand on choisit une machine destinée à être un serveur NIS. Un des problèmes du NIS est le degré de dépendance des clients vis à vis du serveur. Si un client ne peut contacter le serveur de son domaine NIS, la plupart du temps la machine n'est plus utilisable. L'absence d'information sur les utilisateurs et les groupes bloque la plupart des systèmes. Vous devez donc vous assurer de choisir une machine qui ne sera pas redémarrée fréquement, ni utilisée pour du développement. Idéalement, le serveur NIS devrait être une machine dont l'unique utilisation serait d'être un serveur NIS. Si vous avez un réseau qui n'est pas très chargé, il peut être envisagé de mettre le serveur NIS sur une machine fournissant d'autres services, gardez juste à l'esprit que si le serveur NIS n'est pas disponible à un instant donné, cela affectera tous vos clients NIS. Serveurs NIS La copie de référence de toutes les informations NIS est stockée sur une seule machine appelée serveur NIS maître. Les bases de données utilisées pour le stockage de ces informations sont appelées tables NIS (“NIS maps”). Sous &os; ces tables se trouvent dans /var/yp/[domainname] où [domainname] est le nom du domaine NIS concerné. Un seul serveur NIS peut gérer plusieurs domaines à la fois, il peut donc y avoir plusieurs de ces répertoires, un pour chaque domaine. Chaque domaine aura son propre jeu de tables. Les serveurs NIS maîtres et esclaves traitent toutes les requêtes NIS à l'aide du “daemon” ypserv. ypserv reçoit les requêtes des clients NIS, traduit le nom de domaine et le nom de table demandés en chemin d'accès à la base de données correspondante et transmet l'information de la base de données au client. Configurer un serveur NIS maître NIS configuration du serveur Selon vos besoins, la configuration d'un serveur NIS maître peut être relativement simple. &os; offre par défaut un support direct du NIS. Tout ce dont vous avez besoin est d'ajouter les lignes qui suivent au fichier /etc/rc.conf, et &os; s'occupera du reste pour vous. nisdomainname="test-domain" Cette ligne définie le nom de domaine NIS, test-domain, à la configuration du réseau (e.g. au démarrage). nis_server_enable="YES" Demandera à &os; de lancer les processus du serveur NIS dès que le réseau est en fonctionnement. nis_yppasswdd_enable="YES" Ceci activera le “daemon” rpc.yppasswdd, qui, comme mentionné précedement, permettra aux utilisateurs de modifier leur mot de passe à partir d'une machine cliente. Selon votre configuration NIS, vous aurez peut-être à ajouter des entrées supplémentaires. Consultez la section sur les serveurs NIS qui sont également des clients NIS, plus bas, pour plus de détails. Maintenant, tout ce que vous devez faire est d'exécuter la commande /etc/netstart en tant que super-utilisateur. Elle configurera tout en utilisant les valeurs que vous avez définies dans /etc/rc.conf. Initialisation des tables NIS NIS tables Les tables NIS sont des fichiers de base de données, qui sont conservés dans le répertoire /var/yp. Elles sont générées à partir des fichiers de configuration du répertoire /etc du serveur NIS maître, avec une exception: le fichier /etc/master.passwd. Et cela pour une bonne raison, vous ne voulez pas divulguer les mots de passe pour l'utilisateur root et autres comptes d'administration aux autres serveurs du domaine NIS. Par conséquent, avant d'initialiser les tables NIS, vous devrez faire: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Vous devrez effacer toutes les entrées concernant les comptes système (bin, tty, kmem, games, etc.), tout comme les comptes que vous ne désirez pas propager aux clients NIS (par exemple root et tout autre compte avec un UID 0 (super-utilisateur)). Assurez-vous que le fichier /var/yp/master.passwd n'est pas lisible par son groupe ou le reste du monde (mode 600)! Utilisez la commande chmod si nécessaire. Tru64 UNIX Cela achevé, il est temps d'initialiser les tables NIS! &os; dispose d'une procédure appelée ypinit pour le faire à votre place (consultez sa page de manuel pour plus d'informations). Notez que cette procédure est disponible sur la plupart des systèmes d'exploitation du type &unix;, mais pas tous. Sur Digital UNIX/Compaq Tru64 UNIX, elle est appelée ypsetup. Comme nous voulons générer les tables pour un maître NIS, nous passons l'option à ypinit. Pour générer les tables NIS, en supposant que vous avez effectué les étapes précédentes, lancez: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit devrait avoir créé /var/yp/Makefile à partir de /var/yp/Makefile.dist. Une fois créé, ce fichier suppose que vous être dans un environnement composé uniquement de machines &os; et avec un seul serveur. Comme test-domain dispose également d'un serveur esclave, vous devez éditer /var/yp/Makefile: ellington&prompt.root; vi /var/yp/Makefile Vous devez commenter la ligne NOPUSH = "True" (si elle n'est pas déjà commentée). Configurer un serveur NIS esclave NIS serveur esclave Configurer un serveur NIS esclave est encore plus simple que de configurer un serveur maître. Ouvrez une session sur le serveur esclave et éditez le fichier /etc/rc.conf comme précédemment. La seule différence est que nous devons maintenant utiliser l'option avec ypinit. L'option a besoin du nom du serveur NIS maître, donc notre ligne de commande ressemblera à: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Vous devriez avoir un répertoire appelé /var/yp/test-domain. Des copies des tables du serveur NIS maître devraient se trouver dans ce répertoire. Vous devrez vous assurer que ces tables restent à jour. Les entrées suivantes dans /etc/crontab sur vos serveurs esclaves s'en chargeront: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Ces deux lignes obligent le serveur esclave à synchroniser ses tables avec celles du serveur maître. Bien que ces entrées ne soient pas indispensables puisque le serveur maître essaye de s'assurer que toute modification de ses tables NIS soit répercutée à ses serveurs esclaves et comme l'information sur les mots de passe est vitale pour les systèmes qui dépendent du serveur, il est bon de forcer les mises à jour. C'est d'autant plus important sur les réseaux chargés où il n'est pas certain que les mises à jour soient intégrales. Maintenant, exécutez la commande /etc/netstart sur le serveur esclave, ce qui lancera le serveur NIS. Clients NIS Un client NIS établit une connexion avec un serveur NIS donné par l'intermédiaire du “daemon” ypbind. ypbind consulte le nom de domaine par défaut du système (défini par la commande domainname), et commence à diffuser des requêtes RPC sur le réseau local. Ces requêtes précisent le nom de domaine auquel ypbind essaye de se rattacher. Si un serveur configuré pour ce domaine reçoit une des requêtes diffusées, il répond à ypbind, qui enregistrera l'adresse du serveur. S'il y a plusieurs serveurs disponibles (un maître et plusieurs esclaves par example), ypbind utilisera l'adresse du premier à répondre. Dès lors, le système client dirigera toutes ses requêtes NIS vers ce serveur. ypbind enverra de temps en temps des requêtes “ping” au serveur pour s'assurer qu'il fonctionne toujours. S'il ne reçoit pas de réponse dans un laps de temps raisonnable, ypbind considérera ne plus être attaché au domaine et recommencera à diffuser des requêtes dans l'espoir de trouver un autre seveur. Configurer un client NIS NIS configuration du client Configurer une machine &os; en client NIS est assez simple. Editez le fichier /etc/rc.conf et ajoutez les lignes suivantes afin de définir le nom de domaine NIS et lancez ypbind au démarrage du réseau: nisdomainname="test-domain" nis_client_enable="YES" Pour importer tous les mots de passe disponibles du serveur NIS, effacez tous les comptes utilisateur de votre fichier /etc/master.passwd et utilisez vipw pour ajouter la ligne suivante à la fin du fichier: +::::::::: Cette ligne permet à chaque utilisateur ayant un compte valide dans les tables de mots de passe du serveur d'avoir un compte sur le client. Il y a plusieurs façons de configurer votre client NIS en modifiant cette ligne. Consultez la section groupes réseau plus bas pour plus d'informations. Pour en savoir plus, reportez-vous à l'ouvrage Managing NFS and NIS de chez O'Reilly. Vous devriez conservez au moins un compte local (i.e. non-importé via NIS) dans votre fichier /etc/master.passwd et ce compte devrait également être membre du groupe wheel. Si quelque chose se passe mal avec NIS, ce compte peut être utilisé pour ouvrir une session à distance, devenir root, et effectuer les corrections nécessaires. Pour importer tous les groupes disponibles du serveur NIS, ajoutez cette ligne à votre fichier /etc/group: +:*:: Une fois que c'est fait, vous devriez être en mesure d'exécuter ypcat passwd et voir la table des mots de passe du serveur NIS. Sécurité du NIS De façon générale, n'importe quel utilisateur distant peut émettre une requête RPC à destination de &man.ypserv.8; et récupérer le contenu de vos tables NIS, en supposant que l'utilisateur distant connaisse votre nom de domaine. Pour éviter ces transactions non autorisées, &man.ypserv.8; dispose d'une fonctionnalité appelée “securenets” qui peut être utilisée pour restreindre l'accès à un ensemble donné de machines. Au démarrage, &man.ypserv.8; tentera de charger les informations sur les “securenets” à partir d'un fichier nommé /var/yp/securenets. Ce chemin d'accès peut varier en fonction du chemin d'accès défini par l'option . Ce fichier contient des entrées sous la forme de définitions de réseau et d'un masque de sous-réseau séparé par une espace. Les lignes commençant par un “#” sont considérées comme des commentaires. Un exemple de fichier securenets peut ressembler à ceci: # autorise les connexions depuis la machine locale -- obligatoire 127.0.0.1 255.255.255.255 # autorise les connexions de n'importe quelle machine # du réseau 192.168.128.0 192.168.128.0 255.255.255.0 # autorise les connexions de n'importe quelle machine # entre 10.0.0.0 et 10.0.15.255 # y compris les machines du laboratoire de test 10.0.0.0 255.255.240.0 Si &man.ypserv.8; reçoit une requête d'une adresse qui satisfait à ces règles, il la traite normalement. Si une adresse ne correspond pas aux règles, la requête sera ignorée et un message d'avertissement sera enregistré. Si le fichier /var/yp/securenets n'existe pas, ypserv autorisera les connexions à partir de n'importe quelle machine. Le programme ypserv supporte également l'outil tcpwrapper de Wietse Venema. Cela permet à l'administrateur d'utiliser les fichiers de configuration de tcpwrapper pour contrôler les accès à la place de /var/yp/securenets. Bien que ces deux mécanismes de contrôle d'accès offrent une certaine sécurité, il sont, de même que le test du port privilégié, vulnérables aux attaques par “usurpation” d'adresses. Tout le trafic relatif à NIS devrait être bloqué par votre coupe-feu. Les serveurs utilisant /var/yp/securenets pourront échouer à traiter les requêtes de clients NIS légitimes avec des implémentation TCP/IP archaïques. Certaines de ces implémentations positionnent à zéro les bits de la partie machine de l'adresse IP lors de diffusions et/ou sont incapables respecter le masque de sous-réseau lors du calcul de l'adresse de diffusion. Alors que certains de ces problèmes peuvent être corrigés en modifiant la configuration du client, d'autres problèmes peuvent forcer le retrait des systèmes clients fautifs ou l'abandon de /var/yp/securenets. Utiliser /var/yp/securenets sur un serveur avec une implémentation TCP/IP archaïque est une mauvaise idée et sera à l'origine de pertes de la fonctionnalité NIS pour une grande partie de votre réseau. tcpwrapper L'utilisation du système tcpwrapper augmente les temps de latence de votre serveur NIS. Le délai supplémentaire peut être suffisament long pour dépasser le délai d'attente des programmes clients, tout particulièrement sur des réseaux chargés ou avec des serveurs NIS lents. Si un ou plusieurs de vos systèmes clients souffrent de ces symptômes, vous devrez convertir les systèmes clients en question en serveurs esclaves NIS et les forcer à se rattacher à eux-mêmes. Interdire l'accès à certains utilisateurs Dans notre laboratoire, il y a une machine basie qui est supposée être une station de travail de la faculté. Nous ne voulons pas retirer cette machine du domaine NIS, le fichier passwd sur le serveur maître NIS contient les comptes pour la faculté et les étudiants. Que pouvons-nous faire? Il existe une méthode pour interdire à certains utilisateurs d'ouvrir une session sur une machine, même s'ils sont présents dans la base de données NIS. Pour cela, tout ce dont vous avez besoin de faire est d'ajouter -nom_utilisateur à la fin du fichier /etc/master.passwd sur la machine cliente, où nom_utilisateur est le nom de l'utilisateur auquel vous désirez refuser l'accès. Ceci doit être fait de préférence avec vipw, puisque vipw contrôlera vos changements au fichier /etc/master.passwd, et regénérera automatiquement la base de données à la fin de l'édition. Par exemple, si nous voulions interdire l'ouverture de session à l'utilisateur bill sur la machine basie nous ferions: basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Contribution de Utiliser les groupes réseau (“netgroups”) groupes réseau La méthode présentée dans la section précédente fonctionne relativement bien si vous avez besoin de règles spécifiques pour un petit nombre d'utilisateurs et/ou de machines. Sur les réseaux plus important, vous oublierez d'interdire l'accès aux machines sensibles à certains utilisateurs, ou vous devrez même modifier chaque machine séparément, perdant par là même les avantages du NIS: l'administration centralisée. La solution des développeurs du NIS pour ce problème est appelé groupes réseau (“netgroups”). Leur objet et définition peuvent être comparés aux groupes utilisés par les systèmes &unix;. La principale différence étant l'absence d'identifiants (ID) numériques et la capacité de définir un groupe réseau à l'aide de comptes utilisateur et d'autres groupes réseau. Les groupes réseau furent développés pour gérer des réseaux importants et complexes avec des centaines de machines et d'utilisateurs. C'est une bonne option si vous êtes forcés de faire avec une telle situation. Cependant leur complexité rend impossible une explication avec des exemples simples. L'exemple utilisé dans le reste de cette section met en évidence ce problème. Supposons que l'introduction avec succès de NIS dans votre laboratoire a retenu l'attention de vos supérieurs. Votre mission suivante est d'étendre la couverture de votre domaine NIS à d'autres machines sur le campus. Les deux tables contiennent les noms des nouveaux utilisateurs et des nouvelles machines ainsi qu'une courte description de chacuns. Nom(s) d'utilisateurs Description alpha, beta Les employés du département IT (“Information Technology“) charlie, delta Les nouveaux apprentis du département IT echo, foxtrott, golf, ... Les employés ordinaires able, baker, ... Les internes actuels Nom(s) de machines Description war, death, famine, pollution Vos serveurs les plus importants. Seuls les employés du département IT sont autorisés à ouvrir des sessions sur ces machines. pride, greed, envy, wrath, lust, sloth Serveurs moins importants. Tous les membres du laboratoire IT sont autorisés à ouvrir des sessions sur ces machines. one, two, three, four, ... Stations de travail ordinaires. Seuls les employés réels sont autorisés à utiliser ces machines. trashcan Une très vielle machine sans données sensibles. Même les internes peuvent utiliser cette machine. Si vous avez essayé d'implémenter ces restrictions en bloquant séparément chaque utilisateur, vous avez dû ajouter une ligne -utilisateur à chaque fichier passwd de chaque système pour chaque utilisateur non-autorisé à ouvrir une session sur le système. Si vous ometter ne serait-ce qu'une entrée, vous aurez des problèmes. Il doit être possible de faire cela lors de la configuration initiale, cependant vous finirez par oublier d'ajouter les lignes pour de nouveaux utilisateurs lors d'opérations quotidiennes. Après tout, Murphy était quelqu'un d'optimiste. Traiter cette situation avec les groupes réseau présente plusieurs avantages. Chaque utilisateur n'a pas besoin d'être traité séparément; vous assignez un utilisateur à un ou plusieurs groupes réseau et autorisez ou refusez l'ouverture de session à tous les membres du groupe réseau. Si vous ajoutez une nouvelle machine, vous n'aurez à définir les restrictions d'ouverture de session que pour les groupes réseau. Ces modifications sont indépendantes les unes des autres, plus de “pour chaque combinaison d'utilisateur et de machine faire...” Si votre configuration NIS est réfléchie, vous n'aurez à modifier qu'une configuration centrale pour autoriser ou refuser l'accès aux machines. La première étape est l'initialisation de la table NIS du groupe réseau. La version &os; d'&man.ypinit.8; ne crée pas de table par défaut, mais son implémentation NIS la supportera une fois créée. Pour créer une table vide, tapez simplement ellington&prompt.root; vi /var/yp/netgroup et commencez à ajouter du contenu. Pour notre exemple, nous avons besoin de quatre groupes réseau: les employées du département IT, les apprentis du département IT, les employés normaux et les internes. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP etc. sont les noms des groupes réseau. Chaque groupement entre parenthèses ajoute un ou plusieurs comptes utilisateurs aux groupes. Les trois champs dans un groupement sont: Le nom de la/les machine(s) où les éléments suivants sont valides. Si vous ne précisez pas un nom de machine, l'entrée est valide sur toutes les machines. Si vous précisez un nom de machine, vous pénétrerez dans un royaume obscure, d'horreur et de confusion totale. Le nom du compte qui appartient au groupe réseau. Le domaine NIS pour le compte. Vous pouvez importer les comptes d'autres domaines NIS dans votre groupe réseau si vous êtes une de ces personnes malchanceuses avec plus d'un domaine NIS. Chacun de ces champs peut contenir des jokers. Consultez la page de manuel &man.netgroup.5; pour plus de détails. groupes réseau Les noms de groupes réseau plus long que 8 caractères ne devraient pas être utilisés, tout particulièrement si vous avez des machines utilisant d'autres systèmes d'exploitation dans votre domaine NIS. Les noms sont sensibles à la casse des caractères; utiliser des majuscules pour vos noms de groupes réseau est une méthode simple pour distinguer les utilisateurs, les machines et les noms de groupes réseau. Certains clients NIS (autres que &os;) ne peuvent gérer les groupes réseau avec un grand nombre d'entrées. Par exemple, certaines anciennes versions de &sunos; commencent à causer des problèmes si un groupe réseau contient plus de 15 entrées. Vous pouvez contourner cette limite en créant plusieurs sous-groupes réseau avec 15 utilisateurs ou moins et un véritable groupe réseau constitué des sous-groupes réseau: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Vous pouvez répéter ce processus si vous avez besoin de plus de 255 utilisateurs dans un seul groupe réseau. Activer et propager votre nouvelle table NIS est simple: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Ceci générera les trois tables NIS netgroup, netgroup.byhost et netgroup.byuser. Utilisez &man.ypcat.1; pour contrôler si vos nouvelles tables NIs sont disponibles: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser La sortie devrait être semblable au contenu de /var/yp/netgroup. La deuxième commande ne produira pas de sortie si vous n'avez pas précisé les groupes réseau spécifiques à une machine. La troisième commande peut être utilisée pour obtenir les listes des groupes réseau pour un utilisateur. La configuration du client est plutôt simple. Pour configurer le serveur war, vous devez lancer &man.vipw.8; et remplacer la ligne +::::::::: par +@IT_EMP::::::::: Maintenant, seules les données pour les utilisateurs définis dans le groupe réseau IT_EMP sont importées dans la base de données de mots de passe de war et seuls ces utilisateurs sont autorisés à ouvrir une session. Malheureusement, cette limitation s'applique également à la fonction ~ de l'interpréteur de commandes et toutes les routines de conversion entre nom d'utilisateur et identifiant numérique d'utilisateur. En d'autres termes, cd ~utilisateur ne fonctionnera pas, et ls -l affichera l'ID numérique à la place du nom d'utilisateur et find . -user joe -print échouera avec le message d'erreur No such user. Pour corriger cela, vous devrez importer toutes les entrées d'utilisateurs sans leur autoriser l'ouverture de session sur vos serveurs. Cela peut être fait en ajoutant une autre ligne au fichier /etc/master.passwd. Cette ligne devrait contenir: +:::::::::/sbin/nologin, signifiant “Importer toutes les entrées mais remplacer l'interpréteur de commandes avec /sbin/nologin dans les entrées importées”. Vous pouvez remplacer n'importe quel champ dans l'entrée passwd en plaçant une valeur par défaut dans votre fichier /etc/master.passwd. Assurez-vous que +:::::::::/sbin/nologin est placée après +@IT_EMP:::::::::. Sinon, tous les comptes utilisateur importés du NIS auront /sbin/nologin comme interpréteur de commandes. Après cette modification, vous ne devrez uniquement que modifier une des tables NIS si un nouvel employé rejoint le département IT. Vous pourrez utiliser une approche similaire pour les serveurs moins importants en remplaçant l'ancienne ligne +::::::::: dans leur version locale de /etc/master.passwd avec quelque chose de semblable à ceci: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Les lignes correspondantes pour les stations de travail normales seraient: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin Tout était parfait jusqu'au changement de politique quelques semaines plus tard: le département IT commença à engager des internes. Les internes du département IT sont autorisés à utiliser les stations de travail normales et les serveurs les moins importants; les apprentis du département IT sont autorisés à ouvrir des sessions sur les serveurs principaux. Vous ajoutez alors un nouveau groupe réseau IT_INTERN, ajoutez les nouveaux internes IT à ce groupe réseau et commencez à modifier la configuration sur chaque machine... Comme disait l'ancien: “Erreurs dans la planification centralisée mènent à un désordre général”. La capacité de NIS à créer des groupes réseau à partir d'autres groupes réseau peut être utilisée pour éviter de telles situations. Une possibilité est la création de groupes réseau basés sur le rôle du groupe. Par exemple vous pourriez créer un groupe réseau appelé BIGSRV pour définir les restrictions d'ouverture de session pour les serveurs importants, un autre groupe réseau appelé SMALLSRV pour les serveurs moins importants et un troisième groupe réseau nommé USERBOX pour les stations de travail normales. Chacun de ces groupes réseau contient les groupes réseau autorisés à ouvrir des sessions sur ces machines. Les nouvelles entrées pour la table NIS de groupes réseau devrait ressembler à ceci: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS Cette méthode qui consiste à définir des restrictions d'ouverture de session fonctionne relativement bien si vous pouvez définir des groupes de machines avec des restrictions identiques. Malheureusement, ceci est une exception et pas une généralité. La plupart du temps, vous aurez besoin de définir des restrictions d'ouverture de session par machine. La définition de groupes réseau spécifiques aux machines est une autre possibilité pour traiter la modification de politique soulignée précédement. Dans ce scénario, le fichier /etc/master.passwd de chaque machine contient deux lignes débutant par “+”. La première ajoute un groupe réseau avec les comptes autorisés à ouvrir une session sur cette machine, la seconde ajoute tous les comptes avec l'interpréteur de commandes /sbin/nologin. C'est une bonne idée d'utiliser des majuscules pour le nom de la machine ainsi que celui du groupe réseau. Dans d'autres termes, les lignes en question devraient être semblables à: +@NOMMACHINE::::::::: +:::::::::/sbin/nologin Une fois cette tâche achevée pour toutes vos machines, vous n'aurez plus jamais à modifier les versions locales du fichier /etc/master.passwd. Tous les changements futurs peuvent être gérés en modifiant la table NIS. Voici un exemple d'une table de groupes réseau possible pour ce scénario avec quelques petits plus: # Définir tout d'abord les groupes d'utilisateurs IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Définir, maintenant, des groupes basés sur les rôles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # Et un groupe pour les tâches spéciales # Permettre à echo et golf d'accéder à notre machine anti-virus SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # les groupes réseau basés sur un ensemble de machines # Nos principaux serveurs WAR BIGSRV FAMINE BIGSRV # L'utilisateur india a besoin d'un accès à ce serveur POLLUTION BIGSRV (,india,test-domain) # # Celle-ci est très importante et nécessite plus de restrictions d'accès DEATH IT_EMP # # La machine anti-virus mentionnée précédemment ONE SECURITY # # Restreindre l'accès à une machine à un seul utilisateur TWO (,hotel,test-domain) # [...d'autres groupes suivent] Si vous utilisez une sorte de base de données pour gérer vos comptes utilisateur, vous devriez pouvoir créer la première partie de la table avec les outils de votre base de données. De cette façon, les nouveaux utilisateurs auront automatiquement accès aux machines. Dernier avertissement: il n'est pas toujours conseillé d'utiliser des groupes réseau basés sur les machines. Si vous déployez quelques douzaines ou même centaines de machines identiques pour des laboratoires pour étudiants, vous devriez utiliser des groupes basés sur les types d'utilisateurs plutôt que sur les machines pour conserver la taille de la table NIS dans des limites raisonables. Les choses importantes à ne pas oublier Il y a un certain nombre de choses que vous devrez effectuer différement maintenant que vous êtes dans un environnement NIS. A chaque fois que vous désirez ajouter un utilisateur au laboratoire, vous devez l'ajouter uniquement sur le serveur NIS et vous devez ne pas oublier de reconstruire les tables NIS. Si vous oubliez de le faire, le nouvel utilisateur ne pourra pas ouvrir de session en dehors du serveur maître NIS. Par exemple, si nous devons ajouter au laboratoire un nouvel utilisateur jsmith, nous ferions: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Vous pouvez lancer adduser jsmith à la place de pw useradd jsmith. Conservez les comptes d'administration en dehors des tables NIS. Vous ne voulez pas propager les comptes et mots de passe d'administration sur les machines qui auront des utilisateurs qui ne devraient pas avoir accès à ces comptes. Sécurisez les serveurs maître et esclave NIS, et reduisez leur temps d'arrêt. Si quelqu'un tente soit d'attaquer soit de simplement arrêter ces machines, de nombreuses personnes ne pourront plus ouvrir de session dans le laboratoire. C'est la principale faiblesse d'un système d'administration centralisée. Si vous ne protégez pas vos serveurs NIS, vous aurez à faire face à de nombreux utilisateurs mécontents! Compatibilité NIS version 1 ypserv sous &os; offre un support des clients NIS version 1. L'implémentation NIS de &os; utilise uniquement le protocole NIS version 2, cependant d'autres implémentations disposent du support pour le protocole version 1 pour des raisons de compatibilité avec d'anciens systèmes. Les “daemons” ypbind fournis avec ces systèmes tenteront de s'attacher à un serveur NIS version 1 même s'ils n'en ont pas besoin (et ils pourront continuer à diffuser des requêtes pour en trouver un même après avoir reçu une réponse d'un serveur NIS version 2). Notez que bien que les requêtes des clients normaux soient supportées, cette version d'ypserv ne supporte pas les requêtes de tranfert de tables version 1; par conséquent il n'est pas possible de l'utiliser comme serveur maître ou esclave avec des serveurs NIS plus anciens qui ne supportent que la version 1 du protocole. Heureusement, il n'y a, aujourd'hui, presque plus de serveurs de ce type actifs. Serveurs NIS qui sont aussi des clients NIS Il faut faire attention quand on utilise ypserv dans un domaine avec plusieurs serveurs NIS qui sont également des clients NIS. Il est en général préférable de forcer les serveurs de se rattacher à eux-mêmes plutôt que de les laisser diffuser des requêtes de rattachement et eventuellement se rattacher réciproquement les uns aux autres. Il peut en résulter de curieux problèmes si l'un des serveurs tombe et que d'autres en dépendent. Tous les clients finiront par dépasser leur délai d'attente et se tenteront de se rattacher à d'autres serveurs, mais ce délai peut être considérable et le problème persistera puisque les serveurs peuvent à nouveau se rattacher les uns aux autres. Vous pouvez obliger une machine à se rattacher à un serveur particulier en exécutant ypbind avec l'option . Si vous ne désirez pas faire cela à la main à chaque fois que vous redémarrez votre serveur NIS, vous pouvez ajouter les lignes quivantes à votre fichier /etc/rc.conf: nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" Voir la page de manuel de &man.ypbind.8; pour plus d'informations. Formats des mots de passe NIS formats des mots de passe Un des problèmes les plus courants que l'on rencontre en mettant en oeuvre NIS est celui de la compatibilité des formats de mots de passe. Si votre serveur NIS utilise des mots de passe chiffrés avec l'algorithme DES, il ne supportera que les clients utilisant également DES. Par exemple, si vous avez des client NIS &solaris; sur votre réseau, alors vous aurez presque certainement besoin d'utiliser des mots de passe chiffrés avec le système DES. Pour déterminer quel format vos serveurs et clients utilisent, consultez le fichier /etc/login.conf. Si la machine est configurée pour utiliser des mots de passe chiffrés avec DES, alors la classe default contiendra une entrée comme celle-ci: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Entrées suivantes omises] D'autres valeurs possibles pour la capacité passwd_format sont blf et md5 (respectivement pour les chiffrages de mots de passe Blowfish et MD5). Si vous avez modifié le fichier /etc/login.conf, vous devrez également regénérer la base de données des capacités de classes de session, ce qui est accompli en exécutant la commande suivante en tant que root: &prompt.root; cap_mkdb /etc/login.conf Le format des mots de passe utilisés dans /etc/master.passwd ne sera pas mis à jour avant qu'un utilisateur ne change son mot de passe pour la première fois après la regénération de la base de données des capacités de classes de session. Ensuite, afin de s'assurer que les mots de passe sont chiffrés avec le format que vous avez choisi, vous devez vérifier que l'entrée crypt_default dans le fichier /etc/auth.conf donne la priorité au format de mots de passe choisi. Par exemple, quand les mots de passe DES sont utilisés, l'entrée serait: crypt_default = des blf md5 En suivant les points précédents sur chaque serveur et client NIS sous &os;, vous pouvez être sûr qu'ils seront tous d'accord sur le format de mot de passe utilisé dans le réseau. Si vous avez des problèmes d'authentification sur un client NIS, c'est probablement la première chose à vérifier. Rappelez-vous: si vous désirez mettre en place un serveur NIS pour un réseau hétérogène, vous devrez probablement utiliser DES sur tous les systèmes car c'est le standard le plus courant. Greg Sutter Ecrit par DHCP Qu'est-ce que DHCP? Dynamic Host Configuration Protocol DHCP Internet Software Consortium (ISC) DHCP, le protocole d'attribution dynamique des adresses (“Dynamic Host Configuration Protocol”), décrit les moyens par lesquels un système peut se connecter à un réseau et obtenir les informations nécessaires pour dialoguer sur ce réseau. &os; utilise l'implémentaion DHCP de l'ISC (Internet Software Consortium), aussi toutes les informations spécifiques à l'implémentation, ici, concernent la version distribuée par l'ISC. Ce que traite cette section Cette section décrit les composants côté client et côté serveur du système DHCP ISC. Le programme client, dhclient, est intégré à &os;, la partie serveur est disponible à partir du logiciel porté net/isc-dhcp3-server. Les pages de manuel &man.dhclient.8;, &man.dhcp-options.5;, et &man.dhclient.conf.5;, en plus des références données plus bas, sont des ressources utiles. Comment cela fonctionne-t-il? UDP Quand dhclient, le client DHCP, est exécuté sur la machine cliente, il commence à diffuser des requêtes de demandes d'information de configuration. Par défaut, ces requêtes sont effectuées sur le port UDP 68. Le serveur répond sur le port UDP 67, fournissant au client une adresse IP et d'autres informations réseau importantes comme le masque de sous-réseau, les routeurs, et les serveurs DNS. Toutes ces informations viennent sous la forme d'un “bail” DHCP qui est uniquement valide pendant un certain temps (configuré par l'administrateur du serveur DHCP). De cette façon, les adresses IP expirées pour les clients qui ne sont plus connectés peuvent être automatiquement récupérées. Les clients DHCP peuvent obtenir une grande quantité d'informations à partir du serveur. Une liste eshaustive est donnée dans la page de manuel &man.dhcp-options.5;. Intégration dans &os; Le client DHCP ISC, dhclient, est complètement intégré à &os;. Le support du client DHCP est fourni avec l'installeur et le système de base, rendant évident le besoin d'une connaissance détaillée des configurations réseaux pour n'importe quel réseau utilisant un serveur DHCP. dhclient fait partie de toutes les versions de &os; depuis la version 3.2. sysinstall DHCP est supporté par sysinstall. Quand on configure une interface réseau sous sysinstall, la première question posée est: “Voulez-vous tenter la configuration DHCP de cette interface?”. Répondre par l'affirmative à cette question lancera dhclient, et en cas de succès, complètera automatiquement les informations de configuration réseau. Vous devez faire deux choses pour que votre système utilise DHCP au démarrage: DHCP prérequis Assurez-vous que le périphérique bpf est compilé dans votre noyau. Pour cela, vous devez ajouter la ligne device bpf (pseudo-device bpf sous &os; 4.X) à votre fichier de configuration du noyau, et recompiler le noyau. Pour plus d'informations sur la compilation de noyaux, consultez le . Le périphérique bpf est déjà présent dans le noyau GENERIC qui est fourni avec &os;, vous ne devez donc pas créer de noyau spécifique pour faire fonctionner DHCP. Ceux qui sont particulièrement conscients de l'aspect sécurité devraient noter que bpf est également le périphérique qui permet le fonctionnement de “renifleurs” de paquets (de tels programmes doivent être lancés sous l'utilisateur root). bpf est nécessaire pour utiliser DHCP, mais si vous êtes très sensible à la sécurité, vous ne devriez probablement pas ajouter bpf à votre noyau parce que vous projetez d'utiliser DHCP dans le futur. Editez votre fichier /etc/rc.conf pour y ajouter ce qui suit: ifconfig_fxp0="DHCP" Assurez-vous de bien remplacer fxp0 par l'interface que vous voulez configurer de façon dynamique comme décrit dans la . Si vous utilisez un emplacement différent pour dhclient, ou si vous désirez passer des arguments supplémentaires à dhclient, ajoutez ce qui suit (en effectuant des modifications si nécessaire): dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP serveur Le serveur DHCP, dhcpd, fait partie du logiciel porté net/isc-dhcp3-server disponible dans le catalogue des logiciels portés. Ce logiciel porté contient le serveur DHCP ISC et sa documentation. Fichiers DHCP fichiers de configuration /etc/dhclient.conf dhclient nécessite un fichier de configuration, /etc/dhclient.conf. Généralement le fichier ne contient que des commentaires, les valeurs par défaut étant suffisantes. Ce fichier de configuration est décrit par la page de manuel &man.dhclient.conf.5;. /sbin/dhclient dhclient est lié statiquement et réside dans le répertoire /sbin. La page de manuel &man.dhclient.8; donne beaucoup plus d'informations au sujet de dhclient. /sbin/dhclient-script dhclient-script est la procédure de configuration du client DHCP spécifique à &os;. Elle est décrite dans la page de manuel &man.dhclient-script.8;, mais ne devrait pas demander de modification de la part de l'utilisateur pour fonctionner correctement. /var/db/dhclient.leases Le client DHCP conserve une base de données des baux valides, qui est écrite comme un fichier journal. La page de manuel &man.dhclient.leases.5; en donne une description légèrement plus longue. Lecture supplémentaire Le protocole DHCP est intégralement décrit dans la RFC 2131. Des informations sont également disponibles à l'adresse dhcp.org. Installer et configurer un serveur DHCP Ce que traite cette section Cette section fournit les informations nécessaires à la configuration d'un système &os; comme serveur DHCP en utilisant l'implémentation ISC (Internet Software Consortium) de l'ensemble DHCP. La partie serveur n'est pas fournie dans le système de base de &os;, et vous devrez installer le logiciel porté net/isc-dhcp3-server pour bénéficier de ce service. Lisez le pour plus d'information sur l'utilisation du catalogue des logiciels portés. Installation d'un serveur DHCP DHCP installation Afin de configurer votre système &os; en serveur DHCP, vous devrez vous assurer que le support du périphérique &man.bpf.4; est compilé dans votre noyau. Pour cela ajouter la ligne device bpf (pseudo-device bpf sous &os; 4.X) dans votre fichier de configuration du noyau. Pour plus d'information sur la compilation de noyaux, consultez le . Le périphérique bpf est déjà présent dans le noyau GENERIC qui est fourni avec &os;, vous ne devez donc pas créer de noyau spécifique pour faire fonctionner DHCP. Ceux qui sont particulièrement conscients de l'aspect sécurité devraient noter que bpf est également le périphérique qui permet le fonctionnement de “renifleurs” de paquets (de tels programmes nécessitent également un accès avec privilèges). bpf est nécessaire pour utiliser DHCP, mais si vous êtes très sensible à la sécurité, vous ne devriez probablement pas ajouter bpf à votre noyau parce que vous projetez d'utiliser DHCP dans le futur. Il vous reste ensuite à éditer le fichier dhcpd.conf d'exemple qui a été installé par le logiciel porté net/isc-dhcp3-server. Par défaut, cela sera /usr/local/etc/dhcpd.conf.sample, et vous devriez le copier vers /usr/local/etc/dhcpd.conf avant de commencer vos modifications. Configuration du serveur DHCP DHCP dhcpd.conf dhcpd.conf est composé de déclarations concernant les masques de sous-réseaux et les machines, il est peut-être plus facile à expliquer à l'aide d'un exemple: option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } Cette option spécifie le domaine qui sera donné aux clients comme domaine par défaut. Consultez la page de manuel de &man.resolv.conf.5; pour plus d'information sur sa signification. Cette option donne une liste, séparée par des virgules, de serveurs DNS que le client devrait utiliser. Le masque de sous-réseau qui sera fourni aux clients. Un client peut demander un bail d'une durée bien précise. Sinon par défaut le serveur alloue un bail avec cette durée avant expiration (en secondes). C'est la durée maximale d'allocation autorisée par le serveur. Si un client demande un bail plus long, le bail sera accordé mais il ne sera valide que durant max-lease-time secondes. Cette option indique si le serveur DHCP doit tenter de mettre à jour le DNS quand un bail est accepté ou révoqué. Dans l'implémentation ISC, cette option est obligatoire. Ceci indique quelles adresses IP devraient être utilisées dans l'ensemble des adresses réservées aux clients. Les adresses comprises dans l'intervalle spécifiée sont allouées aux clients. Définit la passerelle par défaut fournie aux clients. L'adresse matérielle MAC d'une machine (de manière à ce que le serveur DHCP puisse reconnaître une machine quand elle envoie une requête). Indique que la machine devrait se voir attribuer toujours la même adresse IP. Notez que l'utilisation d'un nom de machine ici est correct, puisque le serveur DHCP effectuera une résolution de nom sur le nom de la machine avant de renvoyer l'information sur le bail. Une fois l'écriture de votre fichier dhcpd.conf terminée, vous pouvez lancer le serveur en tapant la commande suivante: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start Si vous devez, dans le futur, effectuer des changements dans la configuration de votre serveur, il est important de savoir que l'envoi d'un signal SIGHUP à dhcpd ne provoque pas le rechargement de la configuration, contrairement à la plupart des “daemons”. Vous devrez envoyer un signal SIGTERM pour arrêter le processus, puis le relancer en utilisant la commande ci-dessus. Fichiers DHCP fichier de configuration /usr/local/sbin/dhcpd dhcpd est lié statiquement et réside dans le répertoire /usr/local/sbin. La page de manuel &man.dhcpd.8; installée avec le logiciel porté donne beaucoup plus d'informations au sujet de dhcpd. /usr/local/etc/dhcpd.conf dhcpd nécessite un fichier de configuration, /usr/local/etc/dhcpd.conf avant de pouvoir commencer à offrir ses services aux client. Ce fichier doit contenir toutes les informations à fournir aux clients qui seront traités, en plus des informations concernant le fonctionnement du serveur. Ce fichier de configuration est décrit par la page de manuel &man.dhcpd.conf.5; installée par le logiciel porté. /var/db/dhcpd.leases Le serveur DHCP conserve une base de données des baux qu'il a délivré, qui est écrite comme un fichier journal. La page de manuel &man.dhcpd.leases.5; installée par le logiciel porté en donne une description légèrement plus longue. /usr/local/sbin/dhcrelay dhcrelay est utilisé dans les environements avancés où un serveur DHCP fait suivre la requête d'un client vers un autre serveur DHCP sur un réseau séparé. Si vous avez besoin de cette fonctionnalité, installez alors le logiciel porté net/isc-dhcp3-server. La page de manuel &man.dhcrelay.8; fournie avec le logiciel porté contient plus de détails. Chern Lee Contribution de DNS Généralités BIND &os; utilise, par défaut, BIND (Berkeley Internet Name Domain), qui est l'implémentation la plus courante du protocole DNS. Le DNS est le protocole qui effectue la correspondance entre noms et adresses IP, et inversement. Par exemple une requête pour www.FreeBSD.org aura pour réponse l'adresse IP du serveur Web du projet &os;, et une requête pour ftp.FreeBSD.org renverra l'adresse IP de la machine FTP correspondante. De même, l'opposé est possible. Une requête pour une adresse IP retourne son nom de machine. Il n'est pas nécessaire de faire tourner un serveur DNS pour effectuer des requêtes DNS sur un système. DNS Le DNS est coordonné sur l'Internet à travers un système complexe de serveurs de noms racines faisant autorité, et d'autres serveurs de noms de plus petites tailles qui hébergent, directement ou font office de “cache”, l'information pour des domaines individuels. Ce document fait référence à BIND 8.x, comme c'est la version stable utilsée dand &os;. BIND 9.x peut être installée à l'aide du logiciel porté net/bind9. Les RFC1034 et RFC1035 régissent le protocole DNS. Actuellement, BIND est maintenu par l'Internet Software Consortium (www.isc.org). Terminologie Pour comprendre ce document, certains termes relatifs au DNS doivent être maîtrisés. Terme Definition “Forward“ DNS Correspondance noms de machine vers adresses IP. Origine Fait référence au domaine couvert par un fichier de zone particulier. named, BIND, serveur de noms Noms courants pour le serveur de noms BIND de &os; resolveur Resolveur Un processus système par l'intermédiaire duquel une machine contacte un serveur de noms pour obtenir des informations sur une zone. DNS inverse DNS inverse C'est l'inverse du DNS “classique” (“Forward“ DNS). C'est la correspondance adresses IP vers noms de machine. zone racine Zone racine Début de la hiérarchie de la zone Internet. Toutes les zones sont rattachées à la zone racine, de la même manière qu'un système de fichier est rattaché au répertoire racine. Zone Un domaine individuel, un sous-domaine, ou une partie des noms administrés par un même serveur faisant autorité. zones exemples Exemples de zones: . est la zone racine org. est une zone sous la zone racine example.org est une zone sous la zone org. foo.example.org. est un sous-domaine, une zone sous la zone example.org. 1.2.3.in-addr.arpa est une zone faisant référence à toutes les adresses IP qui appartiennent l'espace d'adresse 3.2.1.*. Comme on peut le remarquer, la partie la plus significative d'un nom de machine est à sa gauche. Par exemple, example.org. est plus spécifique que org., comme org. est à son tour plus spécifique que la zone racine. La constitution de chaque partie d'un nom de machine est proche de celle d'un système de fichiers: le répertoire /dev se trouve sous la racine, et ainsi de suite. Les raisons de faire tourner un serveur de noms Les serveurs de noms se présentent généralement sous deux formes: un serveur de noms faisant autorité, et un serveur de noms cache. Un serveur de noms faisant autorité est nécessaire quand: on désire fournir des informations DNS au reste du monde, être le serveur faisant autorité lors des réponses aux requêtes. un domaine, comme par exemple example.org, est enregistré et des adresses IP doivent être assignées à des noms de machine appartenant à ce domaine. un bloc d'adresses IP nécessite des entrées DNS inverses (IP vers nom de machine). un serveur de noms de secours, appelé esclave, doit répondre aux requêtes quand le serveur primaire est tombé ou inaccessible. Un serveur de noms cache est nécessaire quand: un serveur de noms local peut faire office de cache et répondre plus rapidement que l'interrogation d'un serveur de noms extérieur. une réduction du trafic réseau global est désirée (il a été mesuré que 5% ou plus du trafic Internet total concerne le trafic DNS). Quand on émet des requêtes pour www.FreeBSD.org, le résolveur interroge généralement le serveur de noms du fournisseur d'accès, et récupère la réponse. Avec un serveur DNS cache local, la requête doit être effectuée qu'une seule fois vers le monde extérieur par le serveur DNS cache. Chaque interrogation suivante n'aura pas à être transmise en dehors du réseau local, puisque l'information est désormais disponible localement dans le cache. Comment cela fonctionne-t-il? Sous &os; le “daemon” BIND est appelé named pour des raisons évidentes. Fichier Description named le “daemon” BIND ndc le programme de contrôle du “daemon” /etc/namedb répertoire où se trouvent les informations sur les zones de BIND /etc/namedb/named.conf le fichier de configuration du “daemon” Les fichiers de zone sont généralement stockés dans le répertoire /etc/namedb, et contiennent les informations concernant les zones DNS gérées par le serveur de noms. Lancer BIND BIND lancement Puisque BIND est installé par défaut, sa configuration est relativement simple. Pour s'assurer que le “daemon” named est lancé au démarrage, ajoutez la ligne suivante dans /etc/rc.conf: named_enable="YES" Pour démarrer le “daemon” manuellement (après l'avoir configuré): &prompt.root; ndc start Fichiers de configuration BIND fichiers de configuration Utilisation de <command>make-localhost</command> Assurez-vous d'effectuer: &prompt.root; cd /etc/namedb &prompt.root; sh make-localhost pour générer correctement le fichier de zone DNS inverse /etc/namedb/localhost.rev. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Reportez-vous à la page de manuel named(8) pour plus de // détails. Si vous devez configurer un serveur primaire // assurez-vous d'avoir compris les détails épineux du // fonctionnement du DNS. Même avec de simples erreurs, vous // pouvez rompre la connexion entre les parties affectées, ou // causer un important trafic Internet inutile. options { directory "/etc/namedb"; // En plus de la clause "forwarders", vous pouvez forcer votre serveur // de noms à ne jamais être à l'origine de // requêtes, mais plutôt faire suivre les demandes en // activant la ligne suivante: // // forward only; // Si vous avez accès à un serveur de noms au niveau de // votre fournisseur d'accès, ajoutez ici son adresse IP, et // activez la ligne ci-dessous. Cela vous permettra de // bénéficier de son cache, réduisant ainsi le // trafic Internet. /* forwarders { 127.0.0.1; }; */ Comme les commentaires le précisent, pour bénéficier d'un cache en amont de votre connexion, le paramètre forwarders peut être activé. Dans des circonstances normales, un serveur de noms interrogera de façon récursive certains serveurs de noms jusqu'à obtenir la réponse à sa requête. Avec ce paramètre activé, votre serveur interrogera le serveur de noms en amont (ou le serveur de noms fourni) en premier, en bénéficiant alors de son cache. Si le serveur en question gère beaucoup de trafic, et est un serveur rapide, activer cette option peut en valoir la peine. 127.0.0.1 ne fonctionnera pas ici. Remplacez cette adresse IP par un serveur de noms en amont de votre connexion. /* * S'il y a un coupe-feu entre vous et les serveurs de noms * avec lesquels vous voulez communiquer, vous aurez * peut-être besoin de décommenter la directive * query-source ci-dessous. Les versions * précédentes de BIND lançaient des * requêtes à partir du port 53, mais depuis la * version 8.1, BIND utilise * par défaut un port quelconque non * réservé. */ // query-source address * port 53; /* * Si exécution dans un "sandbox", vous pourrez avoir * à indiquer un emplacement différent pour le * fichier de sortie de la base de données. */ // dump-file "s/named_dump.db"; }; // Note: ce qui suit sera supporté dans une future version. /* host { any; } { topology { 127.0.0.0/8; }; }; */ // Configurer des serveurs secondaires est plus simple et le principe // général est présenté plus bas. // // Si vous activez un serveur de noms local, n'oubliez pas d'entrer // 127.0.0.1 dans votre fichier /etc/resolv.conf de sorte que ce // serveur soit interrogé le premier. Assurez-vous // également de l'activer dans /etc/rc.conf. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "localhost.rev"; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { type master; file "localhost.rev"; }; // NB: N'utilisez pas les adresses IP ci-dessous, elles sont factices, // et ne servent que pour des besoins de // démonstration/documentation! // // Exemple d'entrées de configuration de serveur secondaire. // Il peut être pratique de devenir serveur secondaire pour la // zone à laquelle appartient votre domaine. Demandez à // votre administrateur réseau l'adresse IP du serveur primaire // responsable de la zone. // // N'oubliez jamais d'inclure la résolution de la zone inverse // (IN-ADDR.ARPA)! // (Ce sont les premiers octets de l'adresse IP, en ordre inverse, // auxquels ont a ajouté ".IN-ADDR.ARPA".) // // Avant de commencer à configurer une zone primaire, il faut // être sûr que vous avez parfaitement compris comment le // DNS et BIND fonctionnent. Il apparait parfois des pièges // peu évidents à saisir. En comparaison, configurer un // serveur secondaire est plus simple. // // NB: N'activez pas aveuglément les exemples ci-dessous. :-) // Utilisez des noms et des adresses réelles. // // NOTE!!! &os; exécute BIND dans un "sandbox" (voir l'option // named_flags dans rc.conf). Le répertoire contenant les // zones secondaires doit être accessible à BIND en // écriture. La séquence suivante est // suggérée: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s Pour plus d'informations sur l'exécution de BIND dans un “sandbox” (bac à sable), consultez la section Exécution de named dans un sandbox. /* zone "example.com" { type slave; file "s/example.com.bak"; masters { 192.168.1.1; }; }; zone "0.168.192.in-addr.arpa" { type slave; file "s/0.168.192.in-addr.arpa.bak"; masters { 192.168.1.1; }; }; */ Dans named.conf, ce sont des exemples d'entrées d'un serveur esclave. Pour chaque nouvelle zone gérée, une nouvelle entrée de zone doit être ajoutée au fichier named.conf. Par exemple, l'entrée de zone la plus simple possible pour example.org serait: zone "example.org" { type master; file "example.org"; }; Ce sera un serveur maître pour la zone, comme indiqué par l'option , concervant ses informations de zone dans le fichier /etc/namedb/example.org comme précisé par l'option . zone "example.org" { type slave; file "example.org"; }; Dans le cas d'un esclave, les informations concernant la zone seront transférées à partir du serveur maître pour la zone en question, et sauvegardées dans le fichier indiqué. Si ou lorsque le serveur maître tombe ou est inaccessible, le serveur esclave disposera des informations de la zone transférée et sera capable de les diffuser. Fichiers de zone Un exemple de fichier de zone maître pour example.org (défini dans /etc/namedb/example.org) suit: $TTL 3600 example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL ; Serveurs DNS @ IN NS ns1.example.org. @ IN NS ns2.example.org. ; Noms de machine localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 ; Alias www IN CNAME @ ; Enregistrement MX @ IN MX 10 mail.example.org. Notez que chaque nom de machine se terminant par un “.” est un nom de machine complet, alors que tout ce qui se termine pas par un “.” est référencé par rapport à une origine. Par exemple, www sera traduit en www.origine. Dans notre fichier de zone fictif, notre origine est example.org., donc www sera traduit en www.example.org. Le format d'un fichier de zone est le suivant: nom-enregistrement IN type-enregistrement valeur DNS enregistrements Les enregistrements DNS les plus couramment utilisés: SOA début des données de zone NS serveur de noms faisant autorité A adresse d'une machine CNAME alias d'un nom de machine MX serveur de messagerie recevant le courrier pour le domaine PTR un pointeur sur un nom de domaine (utilisé dans le DNS inverse) example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day example.org. le nom de domaine, également l'origine pour ce fichier de zone. ns1.example.org. le serveur de noms primaire/faisant autorité pour cette zone. admin.example.org. la personne responsable pour cette zone avec le caractère “@” remplacé. (admin@example.org devient admin.example.org) 5 le numéro de série de ce fichier. Celui-ci doit être incrémenté à chaque modification du fichier de zone. De nos jours, de nombreux administrateurs préfèrent un format du type aaaammjjrr pour le numéro de série. 2001041002 signifierait dernière modification le 10/04/2001, le 02 indiquant que c'est la seconde fois que ce fichier a été révisé ce jour. Le numéro de série est important puisqu'il indique aux serveurs de noms esclaves pour la zone une modification de celle-ci. @ IN NS ns1.example.org. C'est une entrée de type NS. Tous les serveurs de noms qui doivent faire autorité pour la zone devront inclure une de ces entrées. Le caractère @ aurait pu être remplacé par example.org.. Le caractère @ étant équivalent à l'origine. localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 Un enregistrement de type A indique des noms de machine. Comme présenté ci-dessus ns1.example.org sera résolu en 3.2.1.2. Ici encore, le symbôle d'origine, @, signifie que example.org donnera pour résolution d'adresse l'adresse 3.2.1.30. www IN CNAME @ L'enregistrement de type CNAME est généralement utilisé pour créer des alias à une machine. Dans l'exemple, www est un alias de la machine correspondant à l'origine, ou encore example.org (3.2.1.30). Les enregistrements CNAME peuvent être utilisés pour fournir des alias à des noms de machines, ou permettre la rotation (“round robin”) d'un nom de machine entre plusieurs machines. MX record @ IN MX 10 mail.example.org. L'enregistrement MX indique quels serveurs de messagerie sont responsables de la gestion du courrier entrant pour la zone. mail.example.org est le nom de machine du serveur de messagerie, et 10 étant la priorité du serveur de messagerie. On peut avoir plusieurs serveurs de messagerie, avec des priorités de 3, 2, 1. Un serveur de messagerie tentant de transmettre du courrier au domaine example.org essaiera en premier le MX avec la plus haute priorité, puis celui venant en second, etc, jusqu'à ce que le courrier puisse être correctement délivré. Pour les fichiers de zone in-addr.arpa (DNS inverse), le même format est utilisé, à l'exception du fait que des entrées PTR seront utilisées en place de A ou CNAME. $TTL 3600 1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum @ IN NS ns1.example.org. @ IN NS ns2.example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 10 IN PTR mail.example.org. 30 IN PTR example.org. Ce fichier donne la correspondance entre adresses IP et noms de machines de notre domaine fictif. Serveur de noms cache BIND serveur de noms cache Un serveur de noms cache est un serveur de noms qui ne fait autorité pour aucune zone. Il émet simplement des requêtes, et se souvient du résultat pour une utilisation ultérieure. Pour mettre en place un tel serveur, configurez le serveur de noms comme à l'accoutumé, en prenant bien soin de n'inclure aucune zone. Exécution <application>named</application> dans un “sandbox” BIND exécution dans un sandbox chroot Pour plus de sécurité, il peut être préférable d'exécuter &man.named.8; sous un utilisateur sans privilèges, et le configurer pour modifier l'emplacement de la racine du système de fichiers (&man.chroot.8;) vers le répertoire du “sandbox” (bac à sable). Ceci rend inaccessible au “daemon” named tout ce qui est situé en dehors de l'environnement “sandbox”. Si named est compromis, cela réduira l'impact des dommages. Par défaut, &os; dispose d'un utilisateur et d'un groupe appelé bind, destiné à cet usage. De nombreuses personnes recommanderont qu'à la place de configurer named à “chrooter”, vous devriez exécuter named dans un environnement &man.jail.8;. Cette section ne traitera pas ce cas de figure. Puisque named ne sera pas en mesure d'avoir accès à des éléments extérieur au “sandbox” (comme aux bibliothèques partagées, aux “sockets” pour l'enregistrements des journaux, etc.), il y a un certain nombre d'étapes à suivre afin de permettre à named un fonctionnement correct. Dans la liste d'opérations qui suit, on suppose que l'emplacement du “sandbox” est /etc/namedb et que vous n'avez pas précédemment modifié le contenu de ce répertoire. Effectuez les étapes suivantes en tant que root: Créer tous les répertoires que named s'attend à trouver: &prompt.root; cd /etc/namedb &prompt.root; mkdir -p bin dev etc var/tmp var/run master slave &prompt.root; chown bind:bind slave var/* named n'a besoin uniquement que d'un accès en écriture à ces répertoires, c'est tout ce que nous lui donnerons. Réarranger les fichiers de configuration et créer la zone: &prompt.root; cp /etc/localtime etc &prompt.root; mv named.conf etc && ln -sf etc/named.conf &prompt.root; mv named.root master &prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master &prompt.root; cat > master/named.localhost $ORIGIN localhost. $TTL 6h @ IN SOA localhost. postmaster.localhost. ( 1 ; serial 3600 ; refresh 1800 ; retry 604800 ; expiration 3600 ) ; minimum IN NS localhost. IN A 127.0.0.1 ^D Ceci permet à named d'utiliser des dates correctes lors de l'envoie des journaux à &man.syslogd.8;. Si vous utilisez une version de &os; antérieure à 4.9-RELEASE, compilez une version liée en statique de named-xfer, et copiez-la dans le “sandbox”: &prompt.root; cd /usr/src/lib/libisc &prompt.root; make cleandir && make cleandir && make depend && make all &prompt.root; cd /usr/src/lib/libbind &prompt.root; make cleandir && make cleandir && make depend && make all &prompt.root; cd /usr/src/libexec/named-xfer &prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all &prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer Après avoir installé votre version statique de named-xfer, un peu de nettoyage est nécessaire pour éviter de conserver des copies inutiles de bibliotèques ou de programmes dans votre arborescence des sources: &prompt.root; cd /usr/src/lib/libisc &prompt.root; make cleandir &prompt.root; cd /usr/src/lib/libbind &prompt.root; make cleandir &prompt.root; cd /usr/src/libexec/named-xfer &prompt.root; make cleandir Il a été signalé que cette étape peut parfois échouer. Si cela vous arrive, tapez alors la commande: &prompt.root; cd /usr/src && make cleandir && make cleandir et effacez votre arborescence /usr/obj: &prompt.root; rm -fr /usr/obj && mkdir /usr/obj Cela devrait supprimer les éventuels “scories” de votre arborescence des sources, puis en réessayant les opérations ci-dessus cela devrait enfin fonctionner. Si vous utilisez &os; 4.9-RELEASE ou une version suivante, alors la version de named-xfer se trouvant dans le répertoire /usr/libexec est liée en statique par défaut, et vous pouvez tout simplement utiliser la commande &man.cp.1; pour la copier dans l'environnement “sandbox”. Créer un fichier spécial de périphérique dev/null dans lequel named peut lire et écrire: &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 &prompt.root; chmod 666 null Créer un lien symbolique de /var/run/ndc vers /etc/namedb/var/run/ndc: &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc Ceci évite tout simplement d'avoir à spécifier l'option à &man.ndc.8; à chaque fois que vous l'exécutez. Comme le contenu du répertoire /var/run est effacé au démarrage, si vous trouvez cela utile vous pouvez vouloir ajouter cette commande dans le fichier crontab de l'utilisateur root, en utilisant l'option . Consultez la page de manuel &man.crontab.5; pour plus d'informations à ce sujet. Configurer &man.syslogd.8; pour qu'il créé une “socket” supplémentaire log sur laquelle named dispose d'un accès en écriture. Pour cela, ajoutez -l /etc/namedb/dev/log à la variable syslogd_flags du fichier /etc/rc.conf. S'arranger à ce que named démarre et se “chroot” lui-même dans l'environnement “sandbox” en ajoutant ce qui suit au fichier /etc/rc.conf: named_enable="YES" named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" Notez que l'emplacement du fichier de configuration /etc/named.conf est référencé par rapport un chemin complet relatif au “sandbox”, i.e. dans la ligne au-dessus, le fichier auquel on fait référence est en fait /etc/namedb/etc/named.conf. L'étape suivante est d'éditer le fichier /etc/namedb/etc/named.conf pour que named puisse savoir quelles zones charger et où les trouver sur le disque. Un exemple commenté suit (tout ce qui n'est pas spécifiquement commenté ici n'est pas différent de la configuration d'un serveur DNS ne tournant pas dans un “sandbox”): options { directory "/"; named-xfer "/bin/named-xfer"; version ""; // Ne pas révéler la version de BIND query-source address * port 53; }; // socket de contrôle ndc controls { unix "/var/run/ndc" perm 0600 owner 0 group 0; }; // Les zones: zone "localhost" IN { type master; file "master/named.localhost"; allow-transfer { localhost; }; notify no; }; zone "0.0.127.in-addr.arpa" IN { type master; file "master/localhost.rev"; allow-transfer { localhost; }; notify no; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { type master; file "master/localhost-v6.rev"; allow-transfer { localhost; }; notify no; }; zone "." IN { type hint; file "master/named.root"; }; zone "private.example.net" in { type master; file "master/private.example.net.db"; allow-transfer { 192.168.10.0/24; }; }; zone "10.168.192.in-addr.arpa" in { type slave; masters { 192.168.10.2; }; file "slave/192.168.10.db"; }; L'option directory est définie par /, puisque tous les fichiers dont named a besoin sont dans ce répertoire (ceci est équivalent au fichier /etc/namedb d'un utilisateur “normal”). Indique le chemin d'accès complet du binaire named-xfer (à partir de l'arborescence utilisée pour named). Ceci est nécessaire puisque named est compilé pour chercher named-xfer par défaut dans le répertoire /usr/libexec. Indique le nom de fichier (relatif à la valeur de directory plus haut) où named le fichier de zone pour cette zone. Indique le nom de fichier (relatif à la valeur de directory plus haut) où named devrait trouver une copie du fichier de zone pour cette zone après l'avoir transféré avec succès à partir du serveur maître. C'est pourquoi nous avons eu besoin de changer le propriétaire du répertoire slave pour bind dans les étapes de configuration précédentes. Après avoir complétées les étapes précédentes, redémarrez votre serveur ou relancez &man.syslogd.8; et démarrez &man.named.8;, en s'assurant de bien utiliser les nouvelles options spécifiées dans les variables syslogd_flags et named_flags. Vous devriez disposez maintenant d'une version de named tournant dans un environnement “sandbox”! Sécurité Bien que BIND soit l'implémentation la plus courante du DNS, le problème de la sécurité subsiste toujours. De possibles problèmes de sécurité exploitables sont parfois découvert. C'est une bonne idée de lire les avis de sécurité du CERT et de s'inscrire à la &a.security-notifications; pour se maintenir au courant des problèmes de sécurité actuels de l'Internet et de &os;. Si un problème surgit, conserver les sources à jour et disposer d'une version compilée de named récente ne seront pas de trop. Lectures supplémentaires Les pages de manuel de BIND/named: &man.ndc.8; &man.named.8; &man.named.conf.5;. Page officielle ISC concernant BIND FAQ BIND DNS et BIND 4ème Edition de chez O'Reilly RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification Tom Hukins Contribution de NTP NTP Généralités Avec le temps, l'horloge d'un ordinateur tend à dériver. Comme le temps passe, l'horloge de l'ordinateur devient moins précise. Le protocole NTP (“Network Time Protocol”) est une des manières pour s'assurer que votre horloge est correcte. De nombreux services Internet ont besoin, ou tirent partie, de la précision des horloges des ordinateurs. Par exemple, un serveur Web, peut recevoir des requêtes pour n'envoyer un fichier que s'il a été modifié depuis un certain temps. Des services comme &man.cron.8; exécutent des commandes à des moments précis. Si l'horloge n'est pas précise, ces commandes peuvent de pas fonctionner au moment désiré. NTP ntpd &os; est fourni avec le serveur NTP &man.ntpd.8; qui peut être utilisé pour contacter d'autres serveurs NTP pour régler l'horloge de votre machine ou pour jouer le rôle de serveur de temps pour d'autres. Choisir les serveurs NTP appropriés NTP choisir les serveurs Afin de synchroniser votre horloge, vous devrez trouver un ou plusieurs serveurs NTP. Votre administrateur réseau ou votre FAI peuvent avoir mis en place un serveur NTP dans cet objectif—consultez leur documentation pour voir si c'est le cas. Il existe une liste de serveurs NTP accessibles par le publique que vous pouvez utiliser pour trouver un serveur NTP proche de vous. Assurez-vous d'avoir pris connaissance de la politique d'utilisation des serveurs que vous choisissez, et demandez la permission si nécessaire. Choisir plusieurs serveurs NTP non-connectés entre eux est une bonne idée au cas où un des serveurs que vous utilisez devient inaccessible ou que son horloge n'est plus fiable. &man.ntpd.8; utilise intelligemment les réponses qu'il reçoit d'autres serveurs—il favorisera les plus fiables par rapport aux moins fiables. Configuration de votre machine NTP configuration Configuration de base ntpdate Si vous désirez synchroniser votre horloge uniquement lors du démarrage de la machine, vous pouvez alors employer &man.ntpdate.8;. Cela peut être approprié pour certaines machines de bureau qui sont fréquemment rédémarrées et qui ne nécessites qu'une synchronisation épisodique, cependant la plupart des machines devraient utiliser &man.ntpd.8;. Utiliser &man.ntpdate.8; au moment du démarrage est également une bonne idée pour les machines qui exécutent &man.ntpd.8;. Le programme &man.ntpd.8; modifie l'horloge graduellement, alors que &man.ntpdate.8; change directement l'horloge, peu importe la différence entre l'heure actuelle de la machine et l'heure correcte. Pour activer &man.ntpdate.8; au démarrage, ajoutez la ligne ntpdate_enable="YES" au fichier /etc/rc.conf. Vous devrez également préciser tous les serveurs avec lesquels vous désirez vous synchroniser et tous les indicateurs devant être passés à &man.ntpdate.8; avec ntpdate_flags. NTP ntp.conf Configuration générale NTP est configuré par l'intermédiaire du fichier /etc/ntp.conf suivant le format décrit dans la page de manuel &man.ntp.conf.5;. Voici un exemple simple: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift L'option server précise quels serveurs doivent être utilisés, avec un serveur listé par ligne. Si un serveur est spécifié avec l'argument prefer, comme c'est le cas pour ntplocal.example.com, ce serveur est préféré par rapport aux autres serveurs. Une réponse en provenance d'un serveur préféré sera ignorée si elle diffère de façon significative des réponses des autres serveurs, sinon elle sera utilisée sans considérer les autres réponses. L'argument prefer est normalement employé pour les serveurs NTP qui sont connus pour leur grande précision, comme ceux avec des systèmes spéciaux de contrôle du matériel. L'option driftfile précise quel fichier est utilisé pour stocker le décalage de fréquence de l'horloge. Le programmme &man.ntpd.8; l'utilise pour compenser automatiquement la dérive naturelle de l'horloge, permettant de maintenir un réglage raisonnablement correct même s'il est coupé d'autres sources extérieures de temps pendant une certaine période. L'option driftfile précise également quel fichier est utilisé pour stocker l'information concernant les réponses précédentes des serveurs NTP que vous utilisez. Il ne devrait pas être modifié par un autre processus. Contrôler l'accès à votre serveur Par défaut, votre serveur NTP sera accessible par toutes les machines sur l'Internet. L'option restrict du fichier /etc/ntp.conf vous permet de contrôler quelles machines peuvent accéder à votre serveur. Si vous voulez refuser à tout le monde l'accès à votre serveur NTP, ajoutez la ligne suivante au fichier /etc/ntp.conf: restrict default ignore Si vous désirez autoriser uniquement l'accès aux machines de votre réseau pour qu'elles puissent synchroniser leur horloge, tout en vous assurant qu'elles ne peuvent configurer le serveur ou être utilisées comme point de de synchronisation, ajoutez: restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap à la place, où 192.168.1.0 est une adresse IP de votre réseau et 255.255.255.0 est votre masque de sous-réseau. Le fichier /etc/ntp.conf peut contenir plusieurs options restrict. Pour plus de détails, lisez la section Access Control Support de la page de manuel &man.ntp.conf.5;. Exécuter le serveur NTP Pour s'assurer que le serveur NTP est lancé au démarrage, ajoutez la ligne xntpd_enable="YES" dans le fichier /etc/rc.conf. Si vous désirez passer des indicateurs supplémentaires à &man.ntpd.8;, éditez les paramètres de l'option xntpd_flags dans /etc/rc.conf. Pour lancer le serveur sans redémarrer votre machine, exécutez ntpd en étant sûr de préciser tout paramètre supplémentaire de xntpd_flags dans /etc/rc.conf. Par exemple: &prompt.root; ntpd -p /var/run/ntpd.pid Sous &os; 5.X, diverses options du fichier /etc/rc.conf ont été renommées. Ainsi, vous devez remplacer chaque xntpd par ntpd dans les options ci-dessus. Utiliser ntpd avec une connexion Internet temporaire Le programme &man.ntpd.8; n'a pas besoin d'une connexion permanente à l'Internet pour fonctionner correctement. Cependant, si vous disposez d'une connextion temporaire qui est configurée de telle sorte qu'il y ait établissement de la connexion à la demande, c'est une bonne idée d'empêcher le trafic NTP de déclencher la numérotation ou de maintenir constamment établie la connexion. Si vous utilisez PPP en mode utilisateur, vous pouvez employer les directives filter dans le fichier /etc/ppp/ppp.conf. Par exemple: set filter dial 0 deny udp src eq 123 # Empêche le trafic NTP de lancer une connexion set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Empêche le trafic NTP entrant de garder la connexion établie set filter alive 1 deny udp dst eq 123 # Empêche le trafic NTP sortant de garder la connexion établie set filter alive 2 permit 0/0 0/0 Pour plus de détails lisez la section PACKET FILTERING de la page de manuel &man.ppp.8; et les exemples du répertoire /usr/share/examples/ppp/. Certains fournisseurs d'accès Internet bloquent les ports dont le numéro est faible, empêchant NTP de fonctionner puisque les réponses n'atteingnent jamais votre machine. Information supplémentaire La documentation pour le serveur NTP peut être trouvé dans le répertoire /usr/share/doc/ntp/ sous le format HTML. 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="" gateway_enable="YES" Configure la machine comme passerelle. Exécuter sysctl net.inet.ip.forwarding=1 aurait le même effet. firewall_enable="YES" Active les règles du coupe-feu se trouvant dans le fichier /etc/rc.firewall au démarrage. firewall_type="OPEN" 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. natd_interface="fxp0" Indique à travers quelle interface transférer les paquets (l'interface connectée à l'Internet). natd_flags="" 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. Chern Lee Contribution de Le “super-serveur” <application>inetd</application> Généralités On fait souvent référence à &man.inetd.8; comme étant le “super-serveur Internet” parce qu'il gére les connexions pour plusieurs “daemons”. Les programmes assurant des services réseau sont généralement connus sous le nom de “daemon”. inetd joue le rôle de serveur de régulateur pour les autres “daemon”s. Quand une connexion est reçue par inetd, ce dernier détermine à quel “daemon” la connexion est destinée, invoque le “daemon” en question et lui délègue la “socket”. Exécuter une instance d'inetd réduit la charge système globale par rapport à l'exécution de chaque “daemon” individuellement en mode autonome. inetd est utilisé pour invoquer d'autres “daemon”s, mais plusieurs protocoles triviaux sont gérés directement, comme chargen, auth, et daytime. Cette section abordera la configuration de base d'inetd à travers ses options en ligne de commande et son fichier de configuration /etc/inetd.conf. Configuration inetd est initialisé par l'intermédiaire du système /etc/rc.conf. L'option inetd_enable est positionnée à la valeur NO par défaut, mais est activée par sysinstall avec le profil de sécurité modéré. Placer inetd_enable="YES" ou inetd_enable="NO" dans /etc/rc.conf peut activer ou désactiver le démarrage d'inetd à la mise en route du système. De plus, différentes options de ligne de commande peuvent être passées à inetd par l'intermédiaire de l'option inetd_flags. Options en ligne de commande Synopsis d'inetd: -d Active le débogage. -l Active le journal des connexions réussies. -w Active le “TCP Wrapping” pour les services externes (actif par défaut). -W Active le “TCP Wrapping” pour les services internes qui font partie d'inetd (actif par défaut). -c maximum Spécifie le nombre maximal par défaut d'invocations simultanées pour chaque service; il n'y a pas de limite par défaut. Cette option peut être surchargée pour chaque service à l'aide du paramètre . -C taux Précise le nombre maximal de fois qu'un service peut être invoqué à partir d'une unique adresse IP et cela sur une minute. Ce paramètre peut être configuré différemment pour chaque service avec le paramètre . -R taux Précise le nombre maximal de fois qu'un service peut être invoqué par minute; la valeur par défaut est 256. Un taux de 0 autorise un nombre illimité d'invocations. -a Indique l'adresse IP sur laquelle le trafic sera attendu. Alternativement, un nom de machine peut être utilisé, dans ce cas l'adresse IPv4 ou IPv6 correspondant à la machine sera utilisée. Généralement, un nom de machine est précisé quand inetd est exécuté à l'intérieur d'un environnement &man.jail.8;, dans quel cas le nom de machine correspond à l'environnement &man.jail.8;. Quand un nom de machine est utilisé et que l'on doit être à l'écoute sur une adresse IPv4 et IPv6, une entrée avec le protocole adapté pour chaque type d'adresse est nécessaire pour chaque service dans /etc/inetd.conf. Par exemple, un service de type TCP nécessitera deux entrées, une utilisant tcp4 pour le protocole et une autre utilisant tcp6. -p Spécifie un fichier différent dans lequel stocker l'indentifiant du processus. Ces options peuvent être passées à inetd en utilisant l'option inetd_flags de /etc/rc.conf. Par défaut, inetd_flags est positionné à -wW, ce qui active le “TCP wrapping” pour les services internes et externes d'inetd. Pour un utilisateur de base ces paramètres ne doivent généralement pas être modifiés ou même ajoutés au fichier /etc/rc.conf. Un service externe est un “daemon” indépendant d'inetd, qui est invoqué quand une connexion lui étant destinée est reçue. D'autre part, un service interne est un service qu'inetd peut offrir directement. <filename>inetd.conf</filename> La configuration d'inetd se fait par l'intermédiaire du fichier /etc/inetd.conf. Quand le fichier /etc/inetd.conf est modifié, inetd peut être forcé de relire son fichier de configuration en envoyant un signal “HangUP” au processus inetd comme suit: Envoyer un signal “HangUP” à <application>inetd</application> &prompt.root; kill -HUP `cat /var/run/inetd.pid` Chaque ligne du fichier de configuration ne mentionne qu'un seul “daemon”. Les commentaires dans le fichier sont précédés par un “#”. Le format du fichier /etc/inetd.conf est le suivant: nom-du-service type-de-socket protocole {wait|nowait}[/nb-max-enfants[/nb-connexions-max-par-minute]] utilisateur[:groupe][/classe-session] programme-serveur arguments-du-programme-serveur Un exemple d'entrée pour le “daemon” ftpd utilisant l'IPv4: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l nom-du-service C'est le nom de service du “daemon” en question. Il doit correspondre à un des services listés dans le fichier /etc/services. Cela détermine quel port inetd doit écouter. Si un nouveau service est créé, il doit être ajouté en premier lieu dans /etc/services. type-de-socket Soit stream, soit dgram, soit raw, ou seqpacket. stream doit être utilisé pour les “daemon”s TCP, alors que dgram est utilisé pour les “daemon”s utilisant le protocole UDP. protocole Un des suivants: Protocole Explication tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 et v6 udp46 UDP IPv4 et v6 {wait|nowait}[/nb-max-enfants[/nb-max-connexions-par-ip-par-minute]] indique si le “daemon” invoqué par inetd est capable ou non de gérer sa propre “socket”. Les “socket”s de type doivent utiliser l'option , alors que les “daemons à socket stream”, qui sont généralement multi-threadés, devraient utiliser . L'option a généralement pour conséquence de fournir plusieurs “socket”s à un “daemon”, tandis que l'option invoquera un “daemon” enfant pour chaque nouvelle “socket”. Le nombre maximal de “daemon”s qu'inetd peut invoquer peut être fixé en utilisant l'option . Si une limite de dix instances pour un “daemon” est nécessaire, /10 devra être placé après . En plus de , une autre option limitant le nombre maximal de connexions à partir d'un emplacement vers un “daemon” particulier peut être activée. L'option est l'option en question. Ici, une valeur de dix limiterait à dix le nombre de tentatives de connexions par minute pour une adresse IP particulière. C'est utile pour empêcher l'abus intentionnel ou par inadvertance des ressources et les attaques par déni de service (“Denial of Service—DOS”). Dans ce champ, ou est obligatoire. et sont optionnelles. Un “daemon” utilisant un flux de type multi-threadé sans limites ou sera tout simplement affecté de l'option nowait. Le même “daemon” avec une limite maximale de dix “daemon” serait: nowait/10. De plus, la même configuration avec une limite de vingt connexions par adresse IP par minute et une limite maximale de dix “daemon”s enfant serait: nowait/10/20. Ces options sont utilisées comme valeurs par défaut par le “daemon” fingerd, comme le montre ce qui suit: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s utilisateur C'est l'utilisateur sous lequel le “daemon” en question est exécuté. En général les “daemon”s tournent sous l'utilisateur root. Pour des questions de sécurité, il est courant de rencontrer des serveurs tournant sous l'utilisateur daemon, ou sous l'utilisateur avec le moins de privilèges: nobody. programme-serveur Le chemin complet du “daemon” qui doit être exécuté quand une requête est reçue. Si le “daemon” est un service fourni en interne par inetd, alors l'option devrait être utilisée. arguments-programme-serveur Cette option va de pair avec en précisant les arguments, en commençant avec argv[0], passés au “daemon” lors de son invocation. Si mydaemon -d est la ligne de commande, mydaemon -d sera la valeur de l'option . Ici également, si le “daemon” est un service interne, utilisez . Sécurité En fonction du profil de sécurité choisi à l'installation, plusieurs “daemon”s peuvent être activés par défaut. S'il n'y a pas de raison particulière à l'utilisation d'un “daemon”, désactivez-le! Ajoutez un caractère “#” devant le “daemon” en question, et envoyer un signal hangup à inetd. Certains “daemon”s comme fingerd, devraient être évités parce qu'ils donnent trop d'informations aux personnes malveillantes. Certains “daemon”s n'ont aucune conscience des problèmes de sécurité, ou n'ont pas de délai limite d'expiration pour les tentatives de connexions. Cela permet à une personne malveillante d'envoyer régulièrement et de manière espacée des demandes de connexions à un “daemon” particulier, avec pour conséquence de saturer les ressources disponibles. Cela peut être une bonne idée de placer des limitations et sur certains “daemon”s. Par défaut, le “TCP wrapping” est activé. Consultez la page de manuel &man.hosts.access.5; pour plus d'information sur le placement de restrictions TCP pour divers “daemon”s invoqués par inetd. Divers daytime, time, echo, discard, chargen, et auth sont des services fournis en interne par inetd. Le service auth fournit les services réseau d'identification (ident, identd), et est configurable à un certain degré. Consultez la page de manuel de &man.inetd.8; pour plus d'informations. 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: gif_config_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 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 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