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 bf6d6c53b5..423ec9f266 100644 --- a/fr_FR.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,1124 +1,1126 @@ Administration Réseau Avancée &trans.a.haby; Passerelles et routes Contribution de &a.gryphon;.6 Octobre 1995. Pour qu'une machine puisse en contacter une autre, il faut que soit installé 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 deux adresses : une “destination” et une “passerelle”. Cette paire signifie que pour atteindre cette destination, vous devez passer par cette passerelle. Il y a trois sorte de destinations: les machines elles-mêmes, les sous-réseaux, et default - la destination “par défaut”. La default route - “route par défaut” - est utilisée lorsqu'aucune autre route n'est applicable. Nous parlerons un peu plus des routes par défaut par la suite. Il y a aussi trois sortes de passerelles: les machines elles-mêmes, les interfaces (aussi appelées “liens”), et les adresses Ethernet matériel. Un exemple Pour illustrer différents aspects du routage, nous utiliserons l'exemple suivant, qui est le résultat de la commande netstat -r: 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 foobar.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.foobar.com link#1 UC 0 0 224 link#1 UC 0 0 Les deux premières lignes définissent la route par défaut (dont nous parlerons dans la section suivante) et la route localhost. L'interface (colonne Netif) qu'il est indiqué d'utiliser pour localhost est lo0, que l'on appelle aussi interface loopback - “en boucle”. Ce qui signifie 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. Les adresses 0:e0:... sautent ensuite aux yeux. Ce sont les adresses Ethernet matériel. FreeBSD reconnaîtra automatiquement toute machine (test0 dans l'exemple) sur le réseau Ethernet local et ajoutera une route vers celle-ci, directement via l'interface Ethernet, ed0. Il y a aussi un délai (colonne Expire) associé à ce type de route, qui sert lorsque nous n'entendons plus parler de cette machine pendant un certain temps. Dans ce cas, la route est automatiquement supprimée. Ces machines sont identifiées par un mécanisme appelé RIP (Routing Information Protocol - “protocole d'information de routage”), qui construit les routes vers les machines locales en déterminant le chemin le plus court. FreeBSD ajoutera aussi de routes de sous-réseau pour le sous-réseau local (10.20.30.255 est l'adresse de diffusion du sous-réseau 10.20.30, et foobar.com est le nom de domaine associé à ce sous-réseau). La dénomination link#1 se rapporte à la première interface Ethernet de la machine. Vous constaterez qu'il n'y a pas d'autre interface associée à ces routes. Ces deux types de routes sont automatiquement configurées par un “démon” appelé routed. Si ce dernier ne tourne pas, il ne pourra y avoir que des routes statiques (i.e. explicitement définies). La ligne host1 se rapporte à notre machine, qui est identifiée par son interface Ethernet. Comme nous sommes l'émetteur, FreeBSD sait qu'il faut utiliser l'interface “en boucle”, plutôt que d'envoyer les données sur l'interface Ethernet. Les deux lignes host2 montrent ce qui ce passe quand on utilise un alias avec ifconfig (voyez la section sur Ethernet pour savoir pour quelles raisons on peut vouloir faire cela). Le symbole => qui suit l'interface lo0 indique que non seulement nous utilisons la “boucle” (puisque c'est aussi une adresse qui se rapporte à la machine locale), mais que c'est, plus précisement, 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 qu'une ligne link#1 pour cette machine. La dernière ligne (sous-réseau destinataire 224) concerne le MultiCasting - diffusion sur plusieurs réseaux, dont nous parlerons dans une autre section. L'autre colonne dont il faut parler est la colonne Flags. Chaque route a différentes caractéristiques que décrit cette colonne. Voici une courte table qui liste certains de ces indicateurs et leurs significations: U Active (“Up”): La route est active. H Hôte: La destination de la route est une machine. G Passerelle (“Gateway”): Envoyer tout ce qui regarde cette destination sur la machine distante indiquée, qui saura à qui transmettre ensuite. S Statique: Cette route a été configurée à la main et non générée automatiquement par le système. C Clone: Générer 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 Link: La route fait référence à une adresse Ethernet matérielle. Routes 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 y a déjà une route connue. Si la machine distante appartient à un sous-réseau auquel il sait comment se connecter (routes clonées), alors le système teste s'il peut se connecter via cette interface. Si toutes les routes connues échouent, il reste au système une dernière option: la route “par défaut”. C'est un type particulier de route passerelle (c'est généralement la seule du système), auquel est toujours associé l'indicateur c. Pour les machines du réseau local, cette fonction de passerelle est affectée à la machine qui est directement connectée au monde extérieur (que ce soit par une liasion PPP, ou via un dispositif matériel relié à une ligne dédiée). Si vous configurez la route par défaut sur la machine qui fonctionne comme passerelle vers le monde extérieur, la route par défaut sera la passerelle du site de votre Fournisseur d'Accès Internet (FAI). Examinons un exemple de route par défaut. Voici une configuration habituelle: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] Les machines Local1 et Local2 sont sur votre site, la première étant votre connexion PPP au concentrateur de votre fournisseur d'accès. Le réseau local de votre fournisseur d'accès comporte entre autres un dispositif (T1-GW) relié à son point d'entrée sur l'Internet. Les routes par défaut sur chacune de vos machines seront: hôte passerelle par défaut interface Local2 Local1 Ethernet Local1 T1-GW PPP On demande souvent “Pourquoi (ou comment) définir T1-GW comme passerelle par défaut pour Local1, plutôt que le serveur du fournisseur auquel elle est connectée?”. N'oubliez pas que l'interface PPP utilise, de votre côté de la connexion, une adresse sur le réseau local de votre fournisseur. Les routes vers les autres machines sur le réseau local de votre fournisseur seront générées automatiquement. Vous savez déjà comment atteindre la machine T1-GW, il n'y a donc pas besoin d'une étape intermédiaire qui passe par le serveur de votre fournisseur. Dernière remarque, il est habituel d'attribuer l'adresse ...1 à la passerelle sur votre réseau local. Donc (dans notre exemple), si votre espace d'adresses de classe C local est 10.20.30 et celui de votre fournisseur 10.9.9, alors les routes par défaut sont: 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) Machines sur deux réseaux Il y a un autre type de de configuration dont il faut parler, c'est celle d'une machine qui est connectée à deux réseaux différents. Techniquement, une machine qui sert de passerelle (comme dans l'exemple ci-dessus, en utilisant une connexion PPP) est une machine sur deux réseaux. Mais l'on utilise de fait cette expression (dual-homed host) pour désigner les machines qui sont sur deux réseaux locaux différents. Selon le cas, cette machine peut avoir deux cartes Ethernet, chacune ayant une adresse sur l'un des deux sous-réseaux. Elle peut aussi avoir une seule carte Ethernet, on utilise alors un alias avec ifconfig. Le premier cas de figure correspond à deux réseaux Ethernet physiquement séparés, alors qu'on utilise la deuxième configuration lorsqu'il n'y a qu'un seul segment 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 (inbound route - route entrante) vers l'autre sous-réseau. Cette configuration, où la machine sert de pont entre les deux sous-réseaux, est souvent employé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. 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 sait comment nous joindre. Nous savons déjà comment renseigner les tables de routage pour que tout le trafic pour un espace d'adresses donné (un sous-réseau de classe C dans notre exemple) soit envoyé à une machine précise de ce réseau, qui transmettra les paquets entrants. Lorsqu'il attribue une espace d'adresses à votre site, votre fournisseur d'accès définit 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 autres 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 enregistre tous les espaces d'adresses affectés, et définit leur point de connexion à la dorsale Internet. Le Backbone - “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'un ensemble de tables maîtresses, qui aiguillent le trafic pour un réseau donné vers le transporteur correspondant sur la dorsale, et de là, par l'intermédiaire de fournisseurs d'accès successifs, jusqu'à votre sous-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 donc la route entrante) de votre site. C'est ce que l'on appelle la propagation de route. En cas de problème Il peut arriver qu'il y ait un problème avec la propagation de route et que certains sites ne puissent vous atteindre. La commande probablement la plus utile pour savoir si une route commence à avoir des défaillances est la commande traceroute8. Elle peut aussi vous servir lorsque vous n'arrivez apparemment pas à vous connecter à une autre machine (i.e. lorsque ping8 échoue). La commande traceroute8 prend comme paramètre le nom de la machine avec laquelle vous essayer d'établir une connexion. Elle vous donne la liste des passerelles intermédiaires jusqu'à la machine cible, ou jusqu'à ce qu'il n'y ait plus de liaison. Pour plus d'informations, voyez les pages de manuel de traceroute8. NFS - Contribution de &a.jlind;. + Contribution de John Lind + john@starfire.MN.ORG. Certaines cartes Ethernet ISA ont des limites qui peuvent poser de sérieux problèmes sur un réseau, en particulier avec NFS. Ce n'est pas une particularité propre à FreeBSD, mais elle affecte aussi les systèmes FreeBSD. Ce problème ce produit pratiquement tout le temps quand les systèmes (FreeBSD) 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 font sans difficulté et certaines opérations réussissent, puis tout-à-coup, il semble que le serveur ne réponde pas au client, bien que les échanges avec les autres systèmes continuent à se dérouler normalement. Cela se manifeste sur la machine cliente, que ce soit un système FreeBSD ou une station de travail. Sur de nombreux systèmes, il n'y a pas moyen d'arrêter proprement le client 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” soit d'installer une carte Ethernet plus performante et de plus grande capacité sur le système FreeBSD, il y a une solution de contournement simple qui fournit un palliatif satisfaisant. Si le système FreeBSD est le serveur, utilisez l'option avec mount sur le client. Si le système FreeBSD est le client, alors montez le système de fichiers NFS avec l'option . Vous pouvez mettre ces options dans le quatrième champ de l'entrée fstab sur le client, pour les montages automatiques, ou avec le paramètre de la commande mount 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 qui suivent, fastws est le nom de la station de travail (interface) de haute performance et freebox celui de la machine (interface) FreeBSD avec une carte Ethernet moins performante. /sharedfs est le système de fichiers NFS qui sera exporté (voyez man exports), et /project le point de montage pour ce système de fichiers exporté, sur le client. Dans tous les cas, des options supplémentaires, comme ou et seront peut-être nécessaires pour vos applications. Exemple lorsque le système FreeBSD (freebox) est le client: dans /etc/fstab de freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 commande de montage manuel sur freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Exemple lorsque le système FreeBSD (freebox) est le serveur: dans /etc/fstab de fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 commande de montage manuel sur fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Presque toutes les cartes Ethernet 16-bit permettront d'utiliser les restrictions ci-dessus à la taille du tampon de lecture/écriture. Pour ceux que cela intéresse, voici ce qui provoque le problème, ce qui explique aussi qu'il ne soit pas récupérable. NFS utilise habituellement une taille de “bloc” de 8k (bien qu'il arrive qu'il les fragmente en plus petits morceaux). Comme la taille maximum d'un paquet Ethernet est de 1500 bits, le block NFS est réparti sur plusieurs paquets Ethernet, bien qu'il soit toujours vu comme un ensemble par les couches supérieures du code, et doit être reçu, 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 plus petites et de moindre capacité, les derniers paquets d'un même groupe écrasent les précédents, avant qu'ils aient été transmis, et l'ensemble ne peut être reconstruit et acquitté. En conséquence, le délai est dépassé sur la station de travail, et elle recommence l'opération, mais elle renvoie tous les 8k, et le phénomène se reproduit à l'infini. En définissant la taille de “bloc” en deçà de la taille d'un paquet Ethernet, nous sommes sûrs que chaque paquet Ethernet entier sera acquitté individuellement, ce qui évite la situation d'inter-bloquage. Il peut toujours y avoir écrasement lorsque des stations de travail performantes surchargent un système PC de données, mais avec les meilleures cartes, de tels écrasements ne sont pas systématiques pour les “unités” NFS. En cas d'écrasement, les blocs affectés sont retransmis, et il y a de fortes chances qu'ils soient reçus, assemblés et acquittés. Station sans disque dur Contribution de &a.martin;. netboot.com/netboot.rom vous permettent de démarrer votre machine FreeBSD via le réseau et d'exécuter FreeBSD sans disque dur sur le client. Avec la version 2.0, il est maintenant possible d'avoir de l'espace de pagination local. Il est toujours possible de paginer via NFS. Les cartes Ethernet supportées sont: Western Digital/SMC 8003, 8013, 8216 et compatibles; NE1000/NE2000 et compatibles (il faut recompiler). Configuration Choisissez la machine qui sera votre serveur. Cette machine doit disposer de suffisamment d'espace disque pour y mettre les exécutables de FreeBSD 2.0 et les services bootp, tftp, et NFS. Machines testées: HP9000/8xx sous HP-UX 9.04 ou ultérieurs (cela ne marche pas avec les versions antérieures à la 9.04). Sun/Solaris 2.3. (vous devrez peut-être vous procurer bootp). Installez un serveur bootp pour fournir au client son adresse IP, son masque de réseau et une passerelle: sans-disque:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: Installez un serveur TFTP (sur la même machine que le serveur bootp) pour fournir au client les informations de démarrage. Le nom du fichier de configuration est cfg.X.X.X.X (ou /tftpboot/cfg.X.X.X.X, il cherchera les deux), où X.X.X.X est l'adresse IP du client. Ce fichier peut contenir n'importe quelles commandes netboot valides. Dans la version 2.0, les commandes de netboot sont les suivantes: help affiche une liste d'aide ip affiche/définit l'adresse IP du client server affiche/définit l'adresse IP du serveur bootp/tftp netmask affiche/définit le masque de réseau hostname nom affiche/définit le nom de machine kernel affiche/définit le nom du noyau rootfs affiche/définit le nom du système de fichiers racine swapfs affiche/définit le nom du système de fichiers de pagination swapsize définit la taille de l'espace de pagination de la station sans disque dur en Koctets diskboot démarrer depuis le disque autoboot continuer le processus de démarrage trans | active/désactive l'émetteur-récepteur - transceiver flags définit les indicateurs de démarrage Un fichier cfg pour une machine sans disque peut typiquement contenir: rootfs 192.1.2.3:/rootfs/monclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname monclient.mondomain Un fichier cfg pour une machine avec espace de pagination local peut par exemple contenir: rootfs 192.1.2.3:/rootfs/monclient hostname monclient.mondomain Vérifiez que votre serveur NFS exporte bien le système de fichiers racine (et le système de fichiers de pagination, le cas échéant) vers le client, et que ces systèmes de fichiers sont accessibles avec les droits super-utilisateur sur le client. Le fichier /etc/exports sur un système FreeBSD ressemblera typiquement à: /rootfs/monclient -maproot=0:0 monclient.mondomain /swapfs -maproot=0:0 monclient.mondomain Et sur HP-UX: /rootfs/myclient -root=monclient.mondomain /swapfs -root=monclient.mondomain Si vous paginez via NFS (configuration sans aucun disque dur), créez un fichier de pagination pour votre client avec dd. Si votre commande swapfs a pour argument le système de fichiers /swapfs et 20000 comme taille, comme dans l'exemple ci-dessus, le fichier de pagination du client s'appelera /swapfs/swap.X.X.X.X où X.X.X.X est l'adresse IP du client, e.g.: &prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 Comme l'espace de pagination du client peut contenir des informations sensibles, dès lors qu'il y a pagination, veillez à restreindre les droits en lecture et en écriture sur ce fichier pour éviter les accès non autorisés: &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 Recopiez le système de fichiers racine sur le répertoire qui servira de système de fichiers racine pour le client (/rootfs/monclient dans l'exemple ci-dessus). Sur les systèmes HP-UX: Le serveur doit être soit HP-UX 9.04 ou ultérieur pour les machines de la gamme HP9000/800. Les versions antérieures ne permettent pas de créer de fichiers spéciaux de périphérique via NFS. Lorsque vous recopiez /dev dans /rootfs/monclient, faites attention au fait que certains systèmes (HP-UX) ne créeront pas les fichiers spéciaux de périphérique dont FreeBSD a besoin. Vous devrez peut-être passer en mode mono-utilisateur au premier démarrage (appuyez sur Ctrl-c pendant la phase de démarrage), cd /dev puis sh ./MAKEDEV all sur le client, pour régler ce problème. Lancez netboot.com sur le client ou copiez le fichier netboot.rom dans une EPROM. Utiliser des systèmes de fichiers <filename>/</filename> and <filename>/usr</filename> partagés Cette façon de faire n'est pas actuellement officiellement sanctionnée, mais j'ai utilisé un système de fichiers /usr partagé et un système de fichiers / individuel sur chaque client. Si quelqu'un a des suggestions sur la façon propre de le faire, qu'il me la communique, ou à l'&a.core;. Compiler netboot pour des configurations particulières Netboot peut être compilé pour supporter les cartes NE1000/2000 en modifiant sa configuration dans le fichier /sys/i386/boot/netboot/Makefile. Voyez les commentaires au début de ce fichier. ISDN - Dernières modifications de &a.wlloyd;. + Dernières modifications de Bill Lloyd + wlloyd@mpd.ca. Il y a de bonnes informations sur la technologie et le matérial ISDN sur la page ISDN de Dan Kegel. Voici un aperçu simple et rapide à propos de l'ISDN: Si vous habitez en Europe, je vous suggère d'é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éphonique non dédiée, je vous conseille de lire la section sur les Adaptateurs Terminaux. C'est la solution la plus souple, et qui vous posera le moins de problèmes, si vous changer de fournisseur. Si vous interconnectez deux réseaux locaux ou si vous vous connectez à l'Internet avec une liaison ISDN dédiée, je vous suggère d'envisager un pont/routeur autonome. Le coût est un facteur déterminant de la solution que vous choisirez. Les options ci-dessous sont envisagées de la plus chère à la moins chère. Cartes ISDN Contribution originale de &a.hm;. Cette section ne s'applique qu'aux utilisateurs Européens de l'ISDN. Les cartes supportées ne sont pas encore(?) disponibles pour les normes Nord-Américaines. Vous devez savoir que le code est largement en cours de développement. En particulier, il n'y a de pilotes spécifiques que pour les cartes de deux constructeurs. Les cartes ISDN pour PC supportent toute la bande passante de l'ISDN, 128Kbs. Ces cartes sont souvent les équipements ISDN les moins chers. Sous FreeBSD 2.1.0 et 2.1.5, il y a un premier code ISDN inachevé dans le répertoire /usr/src/gnu/isdn. Ce code est obsolète et ne doit pas être utilisé. Si vous voulez emprunter cette voie, procurez-vous le code bisdn. Ce code a été retiré de l'arborescence des sources depuis FreeBSD 2.2. Le logiciel ISDN bisdn pour FreeBSD 2.1-release, FreeBSD-current et NetBSD se trouve sur hub.freebsd.org. la version la plus récente se trouve sur ce serveur ftp dans le répertoire isdn, dans le fichier bisdn-097.tar.gz. Il y a des pilotes pour les cartes suivantes: Toutes les cartes Teles (passives) et compatibles sont actuellement supportées avec les protocoles EuroISDN (DSS1) et 1TR6. Dr. Neuhaus - Niccy 1016 Le logiciel bisdn présentent quelques limitations. Les fonctionnalités suivantes, habituellement associées à l'ISDN, ne sont pas supportées: Pas de support PPP, HDLC de base uniquement. Cela signifie qu'il n'est pas possible de se connecter à la plupart des routeurs autonomes. Le protocole de contrôle des ponts - Bridging Control Protocol - n'est pas supporté. Support pour une seule carte, uniquement. Pas de bande passante à la demande. Pas de liaison des canaux. Il existe une liste de diffusion. Pour vous y inscrire, envoyez un courrier électronique à &a.majordomo; et avec: subscribe freebsd-isdn comme texte de votre message. Adaptateurs terminaux ISDN Les adapteurs terminaux - Terminal adapters(TA), sont l'équivalent ISDN des modems pour les lignes téléphoniques ordinaires. La plupart des adaptateurs utilisent le jeu de commandes standard des modems Hayes et peuvent être utilisés à la volée en remplacement d'un modem. Un adaptateur fonctionne essentiellement comme un modem sinon que la vitesse de la connexion est bien plus rapide qu'avec votre vieux modem. Vous devrez configurer PPP exactement comme pour un modem. Assurez-vous d'utiliser la vitesse la plus élevée possible sur le port série. Le principal avantage des adaptateurs terminaux pour vous connecter à votre Fournisseur d'Accès Internet est de pouvoir utiliser PPP en mode dynamique. Comme l'espace d'adressage IP disponible devient de plus en plus restreint, la plupart des fournisseurs ne proposent plus désormais d'adresse IP statique. La plupart des routeurs autonomes ne peuvent pas fonctionner avec l'allocation dynamique d'adresse IP. Les fonctionnalités et la stabilité de la connexion des adaptateurs reposent complètement sur le “démon” PPP que vous exécuter. Cela vous permet de passer simplement d'un modem à l'ISDN sur une machine FreeBSD, si vous avez déjà configuré PPP. De ce fait, cependant, les problèmes que vous rencontrez avec PPP persisteront aussi. Si vous voulez le maximum de stabilité, utilisez PPP intégré au noyau au lieu de PPP en mode utilisateur. On sait que les adapteurs suivants fonctionnent avec FreeBSD: Motorola BitSurfer et Bitsurfer Pro Adtran La plupart des adaptateurs terminaux fonctionneront probablement aussi, les fabricants d'adaptateurs font en sorte que leurs produits acceptent la plupart des commandes AT des modems. Le vrai problème avec les adaptateurs externes est que, comme pour les modems, il vous faut une bonne carte série. Vous devriez lire la section Ports série de ce manuel pour comprendre en détail le fonctionnement des périphériques série et les différences entre les ports série synchrones et asynchrones. Un adaptateur sur un port série PC standard (asynchrone) vous limite à 115.2Kbs, bien que vous ayez une liaison à 128Kbs. Pour utiliser les 128Kbs que peut atteindre l'ISDN, il vous faut relier l'adaptateur à une carte série synchrone. N'imaginez pas qu'il vous suffise d'acheter un adaptateur interne pour éviter l'alternative synchrone/asynchrone. Les adaptateurs internes incluent simplement une puce port série standard. Tout ce que vous y gagnerez sera d'économiser un câble série et de récupérer une prise électrique. Une carte synchrone avec un adaptateur est au moins aussi rapide qu'un routeur autonome, et pilotée par une simple machine FreeBSD, probablement plus souple. Le choix entre carte synchrone/adaptateur ou routeur autonome est largement question de dogme. Cela a été quelque peu discuté dans les listes de diffusion. Je vous suggère de regarder dans les archives pour suivre l'intégralité du débat. Ponts/Routeurs ISDN autonomes Les ponts ou les routeurs ISDN ne sont en rien propres à FreeBSD ou à tout autre système d'exploitation. Pour une description complète de la technologie des ponts et des routeurs, reportez-vous s'il vous plaît à un ouvrage de référence sur les réseaux. Dans le contexte de ce manuel, j'utiliserai indifféremment les termes routeur et pont. Comme le prix des ponts/routeurs ISDN d'entrée de gamme baisse continuellement, il est probable qu'ils deviennent un choix plus courant. Un routeur ISDN est une petite boîte que se branche directement sur votre réseau (ou votre carte) 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 procurera une liaison plus rapide qu'un adaptateur standard, puisqu'il utilisera toute la connexion ISDN synchrone. Le principale problème avec les ponts et les routeurs ISDN est encore l'interopérabilité entre les matériels des différents constructeurs. Si vous envisagez de vous connecter à un fournisseur d'accès Internet, je vous recommande d'en discuter avec lui. Si vous envisagez de relier entre eux deux réseaux locaux, i.e.: le réseau de votre domicile et le réseau de votre bureau, c'est la solution la plus simple et qui demande le moins de maintenance. Etant donné que vous achetez les équipements pour les deux extrémités de la liaison, vous êtes sûr que cela fonctionnera. Pour connecter par exemple votre ordinateur à domicile ou le réseau d'une agence à celui du siège, vous pourriez utiliser la configuration qui suit. Réseau d'agence ou à domicile Réseau Ethernet 10 Base T. Connecter le routeur au câble réseau avec un émetteur-récepteur - transceiver - AUI/10BT, si nécessaire. ---Station de travail Sun | ---Machine FreeBSD | ---Windows 95 (N'avouez pas qu'elle est à vous) | Routeur autonome | Liaison ISDN BRI Si vous n'avez qu'un seul ordinateur à domicile ou dans l'agence, vous pouvez utiliser une paire torsadée croisée pour le connecter directement au routeur. Siège ou autre réseau Réseau Ethernet paire torsadée. -------Serveur Novell | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | |___---Routeur autonome | Liaison ISDN BRI Un sérieux avantage de la plupart des ponts/routeurs est qu'ils vous permettent d'avoir deux connexions PPP séparées et indépendantes en même temps. Ce n'est pas possible avec la plupart des adaptateurs, sauf certains modèles particuliers (coûteux) qui ont deux ports série. Ne confondez pas cela avec avec le couplage de canaux, MPP, etc. Ce peut être une fonctionnalité très utile, par exemple si vous avez une connexion ISDN Internet dédiée au bureau et voudriez en profiter mais ne voulez pas acquérir de nouvelle ligne ISDN. Un routeur au bureau peut gérer un canal B dédié (64 Kbs) vers l'Internet et utiliser l'autre canal B pour une autre connexion. Le deuxième canal B peut être utilisé pour des connexions entrantes, sortantes ou dynamiquement liée au premier canal B pour augmenter la bande passante. Un pont Ethernet vous permettra aussi de transmettre autre chose que du trafic IP, vous pourrez aussi faire passer de l'IPX/SPX ou tout autre protocole que vous utilisiez. diff --git a/fr_FR.ISO8859-1/books/handbook/contrib/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/contrib/chapter.sgml index 217bf94071..98e18dd6a4 100644 --- a/fr_FR.ISO8859-1/books/handbook/contrib/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/contrib/chapter.sgml @@ -1,5888 +1,5888 @@ Collaborer à FreeBSD &trans.a.dntt; Contribution de &a.jkh;. Alors, comme ça vous voulez collaborer à FreeBSD ? C'est génial ! Toute aide peut toujours servir, et FreeBSD est un de ces systèmes qui s'appuie sur les contributions de sa base d'utilisateurs pour survivre. Vos contributions ne sont pas seulement appréciées, elles sont vitales pour la progression de FreeBSD ! Contrairement à ce que certaines personnes et peut-être vous-même pouvez croire, vous n'avez pas à être un expert programmeur ou un ami très proche de l'équipe principale de FreeBSD pour faire accepter votre contribution. Le développement du projet FreeBSD est fait par une grande et toujours plus nombreuse, équipe de collaborateurs à travers le monde, dont les âges et l'expertise techniques sont très variables, et il y aura toujours plus de travail à faire que de gens qui peuvent le faire. Comme le projet FreeBSD est responsable de tout l'environnement du système d'exploitation (et de son installation) et pas seulement juste du noyau ou de quelques utilitaires éparpillés, notre liste TODO (à faire) s'étend sur une large gamme de tâches, depuis la documentation, les beta-test et présentation jusqu'à des types de développement du noyau hautement spécialisés. Quelque soit votre niveau de compétence, il y aura sûrement quelque chose que vous pourrez faire pour aider le projet ! Les entités commerciales engagées dans des entreprises relatives à FreeBSD sont encouragées à nous contacter. Vous avez besoin d'une extension spéciale pour faire marcher votre produit ? Vous nous trouverez attentifs à votre requête, du moment que celle-ci ne soit pas trop hors-sujet. Vous travaillez sur un produit à valeur ajoutée ? Dites-le nous ! Nous serons peut-être capable de coopérer sur certains aspects. Le monde du logiciel libre va à l'encontre de nombreuses suppositions sur la manière dont les logiciels sont développés, vendus et maintenus durant son cycle de vie, et nous vous invitons à lui donner au moins un second regard. Les besoins La liste de tâches et de sous-projets qui suit, représente une sorte d'amalgame des différentes listes TODO de l'équipe de base, et des demandes d'utilisateurs que nous avons regroupés depuis ces derniers mois. Lorsque cela a été possible, nous avons rangés ces tâches par degré d'urgence. Si vous êtes interessé par le fait de travailler sur l'une des tâches que vous voyez ici, envoyez un mail au coordinateur en cliquant sur leur nom. Si aucun coordinateur n'a été désigné, peut-être voudriez-vous vous désigner ? Tâches de première priorité Les tâches suivantes sont considérées comme urgentes, généralement parce qu'elles représentent quelque chose posant des problèmes, ou parce qu'on en a désespérement besoin. démarrage en 3 étapes. coordination globale : &a.hackers; Faire un marquage de disque compatible WinNT de telle sorte que la troisième étape puisse fournir un mapping précis de la géométrie BIOS pour les disques. Problèmes du système de fichiers. Coordination globale : &a.fs; Corriger le système de fichiers MSDOS. Nettoyer et documenter le code du système de fichier nullfs. Coordination : &a.eivind; Corriger le système de fichiers d'union. Coordination : &a.dg; Implémenter le pilote de disque Int13 vm86. Coordination : &a.hackers; Nouvelle architecture bus. Porter les pilotes ISA existant vers la nouvelle architecture. Déplacer tous le code de gestion d'interruption vers les parties appropriées des pilotes de bus. Porter les sous-système PCI à la nouvelle architecture. Coordination : &a.dfr; Chercher la bonne manière pour manier les périphériques extractibles, puis utiliser ceci comme base pour l'implémentation de support de PC-Card et CardBus. Résoudre une fois pour toute, le problème de priorité de détection / attachement. Déplacer tous les bus restants vers la nouvelle architecture. Problèmes relatifs au noyau. Coordination globale : &a.hackers; Ajouter une infrastructure pour une meilleure sécurité pro-active. Coordination globale : &a.security; Construire quelque chose comme Tripwire (TM) dans le noyau, avec une partie distante et une partie locale. Il y a un certain nombre de problèmes de cryptographie à prendre en compte pour bien le réaliser. Contacter le coodinateur pour plus de détails. Coordination : &a.eivind; Faire de telle sorte que tout le noyau utilise suser() au lieu de comparer avec 0. Pour l'instant, on n'utilise que la moitié de chaque. Coordination : &a.eivind; Découper les niveaux de sécurité en plusieurs parties, afin de permettre à un administrateur de jeter les privilèges qu'il peut jeter. Mettre en place tous ces niveaux de sécurité devra avoir malgrès tout les mêmes effets qu'actuellement. Coordination : &a.eivind; Rendre possible le chargement de “programmes autorisés à utiliser BPF” puis bloquer BPF pour qu'il ne puisse pas accepter d'autres programmes. Cela permettrait à BPF d'être utilisé par exemple par DHCP, ceci sans permettre à un attaquant de prendre contrôle du réseau local. Mettre à jour les scripts de vérification de sécurité. Nous devrions au moins pouvoir récupérer toutes les vérifications d'autres dérivés BSD, et ajouter une vérification qu'un système ayant un niveau de sécurité ainsi augmenté puisse aussi avoir un témoin raisonnable sur les parties concernées. Coordination : &a.eivind; Ajouter une infrastructure d'autorisation au noyau, afin de permettre diverses politiques d'autorisation. Une partie de ceci pourrait être fait en modifiant suser(). Coordination : &a.eivind; Ajouter du code à la couche NFS afin que l'on ne puisse pas faire un chdir ("..") en dehors d'une partition NFS, Par exemple : /usr est une partition UFS avec la partition NFS /usr/src exportée. Il est à présent possible d'utiliser le gestionnaire de fichier NFS pour /usr/src pour obtenir l'accès à /usr. Tâches de moyenne priorité Les tâches suivantes doivent être effectuées, mais sans urgence particulière : Support et gestion de configuration de tous les pilotes basés sur KLD. Ecrire un gestionnaire de configuration (dans la troisième partie du démarrage ?) qui détecterait votre matériel de manière propre, et garderait seulement les KLDs requis pour votre matériel, etc. PCMCIA/PCCARD. Coordination : &a.msmith; et &a.phk; Documentation ! Opération fiable du pilote pcic (besoin de test). Reconnaissance et prise en charge de sio.c (presque fait). >Reconnaissance et prise en charge de ed.c (presque fait). Reconnaissance et prise en charge de ep.c (presque fait). Reconnaissance et prise en charge du mode utilisateur (partiellement fait). Gestionnaire d'énergie avancé. Coordination : &a.msmith; et &a.phk; sous-pilote APM (presque fait). sous-pilote de disques IDE/ATA (partiellement fait). sous-pilote syscons/pcvt. Intégration avec les pilotes PCMCIA/PCCARD (suspendu / en cours). Tâches de moindre priorité Les tâches suivantes sont purement esthètiques et représentent un tel investissement qu'il semblerait qu'elles seront pas accomplie de sitôt : Les premiers points sont de Terry Lambert terry@lambert.org Chargeur serveur NetWare (pilote ODI en mode protégé) et sous-services pour autoriser l'utilisation de pilotes de cartes ODI avec des cartes réseaux. Même chose avec les pilotes NDIS et les pilotes NetWare SCSI. Uni option "évolution système" marchant sur des machines sous Linux et pas seulement sur des machines sous une version plus anciennes de FreeBSD. Multi-processeur symétrique avec préemption du noyau (requiert une préemption du noyau). Un effort concerté sur les ordinateurs portables. Cela est en quelque sorte pris en charge en changeant les règles de passage PCMCIA et en traitant le gestionnaire d'énergie. Mais il y a certaines choses comme la détection de l'affichage interne vs. externe et l'utilisation d'une résolution d'écran différente en considérant ce fait, ne pas arrêter le disque si la machine est refermée, et autoriser les cartes pour portable à disparaitre sans empêcher la machine de démarrer (même problème que pour le PCMIA). Tâches moins lourdes La plupart des tâches citées dans la section précédente nécessitent soit un investissement important en temps, soit une connaissance en profondeur du noyau (ou les deux). Quoiqu'il en soit, il y a de nombreuses tâches utiles pour les "programmeurs occasionnels", ou les personnes sans compétences en programmation. Si vous utilisez FreeBSD-current et que vous avez une bonne connexion Internet, il y a une machine current.freebsd.org qui construit une version complète tous les jours — à chaque fois, essayer et installer la dernière version depuis ceci et reporter toutes les erreurs durant le processus. Lire les messages de la liste de diffusion freebsd-bugs. Il peut y avoir un problème que vous pouvez commenter de manière constructive ou alors des patches que vous pouvez tester. Vous pouvez aussi essayer de résoudre un de ces problèmes vous-même. Lisez la FAQ et le manuel régulièrement, si quelque chose est mal expliqué, pas à jour ou simplement complètement faux, dites le nous. Mieux, envoyez nous le correctif (SGML n'est pas difficile à apprendre, mais il n'y a pas d'objection à des soumissions au format ASCII). Aidez à traduire la documentation FreeBSD dans votre langue (si elle n'est pas déjà disponible) — envoyez juste un courrier électronique à &a.doc; demandant si quelqu'un est en train d'y travailler. Notez que vous ne vous engagez pas à traduire chacun des documents FreeBSD ce faisant — en fait la documentation dont on a le plus souvent besoin est les instructions d'installation. Lire la liste de diffusion freebsd-questions. et les newsgroup comp.unix.bsd.freebsd.misc de temps en temps (ou même régulièrement). Il peut être très satisfaisant de partager ses expérience et aider les gens à résoudre leurs problèmes; parfois, vous pouvez même ainsi apprendre de nouvelles choses ! Ces forums peuvent parfois être une source d'idées sur ce qu'il faut travailler. Si vous connaissez un correctif appliqué avec succès à -current mais qui n'a pas été appliqué à -stable après un intervalle de temps raisonnable (normalement quelques semaines), envoyer aux collaborateurs un rappel poli. Déplacer les logiciels de collaboration de src/contrib dans l'arborescence source. Assurez vous que le code dans src/contrib est à jour. Cherchez les bugs de l'an 2000 (et corrigez ceux que vous trouvez !) Construire l'arbre des sources (ou une partie) avec les messages de tous les avertissements activés et faire de sorte à ce qu'il n'y ait plus ces avertissements. Corriger les avertissements pour les ports qui réalisent des choses obsolètes comme gets () ou les inclusions de malloc.h. Si vous avez collaboré à un des ports, envoyez vos correctifs à leurs auteurs originaux (cela leur facilitera la vie lors de la sortie de la prochaine version) Suggèrez d'autres tâches pour cette liste ! Comment participer Les contributions au systèmes tombent générallement dans l'une de ces 6 catégories : Rapports de bogues et commentaires généraux Une idée ou une suggestion d'interêt technique général devrait être envoyée à &a.hackers;. les personnes interessées par cela (et qu'un grand volume de courrier électronique ne dérange pas, devraient s'abonner à la liste de diffusion hackers en envoyant un courrier électronique à &a.majordomo;. Voir les listes de diffusions lists pour plus d'informations pour ceci et les autres listes de diffusions. Si vous trouvez un bug ou si vous soumettez un changement spécifique, enregistrez le en utilisant le programme send-pr (1) ou son équivalent web. Essayez de remplir chaque champ de l'enregistrement de bug. A moins qu'ils ne dépassent 65KB, y inclure tous les correctifs directement dans l'enregistrement. Penser à les compresser et à utiliser uuencode (1); s'ils dépassent 20KB. Charger les grosses soumissions vers ftp.freebsd.org:/pub/FreeBSD/incoming/ Après avoir rempli la fiche d'enregistrement, vous devriez recevoir une confirmation avec un numéro d'enregistrement. Gardez ce numéro afin que vous puissiez nous soumettre plus de détails à propos du problème en envoyant un courrier électronique à bug-followup@FreeBSD.ORG. Utilisez le numéro comme sujet du message, par exemple "Re: kern/3377". Toute information supplémentaire sur un bug enregistré devrait être soumise de la même manière. Si vous ne recevez aucune confirmation en un temps raisonnable (de 3 jours à une semaine suivant votre connexion pour le courrier) ou qu'il vous est, pour une raison quelconque, impossible d'utiliser la commande send-pr (1), vous pouvez demander à quelqu'un de le faire pour vous en envoyant un courrier électronique à &a.bugs;. Modifications de la documentation Les modifications dans la documentation sont supervisées par &a.doc;. Envoyez les soumissions et les modifications (même les plus petites sont les bienvenus !) en utilisant la commande send-pr comme décrit dans Soumission de bug et commentaires généraux. Modification dans le code source existant Un ajout ou modification dans le code source existant est une autre affaire, et dépend beaucoup de votre version par rapport à l'état courant du développement de base de FreeBSD. Il y a une version spéciale du FreeBSD en cours de développement, connu sous le nom de “FreeBSD-current” qui est disponible de diverses manières pour le confort des développeurs qui travaillent activement sur le système. Voir Etre à jour avec FreeBSD pour plus d'informations sur la manière d'obtenir et d'utiliser FreeBSD-current. Déveloper avec des sources plus anciennes signifie que vos modifications peuvent parfois devenir trop obsolète ou trop divergentes pour permettre une ré-intégration dans FreeBSD. On peut limiter cela en souscrivant aux listes de diffusion &a.announce; et &a.current; où des discussions sur l'état courant du système ont lieu. En supposant que vous pouvez vous arranger pour avoir de manière sûre des sources à jour comme base pour vos modifications, l'étape suivante consiste à produire un ensemble de diffs à envoyer à ceux qui sont chargés de maintenir FreeBSD. Cela est fait par l'intermédiaire de la commande diff (1), avec une préférence pour le formulaire “contexte diff”. Par exemple : &prompt.user; diff -c oldfile newfile ou &prompt.user; diff -c -r olddir newdir génèrera un ensemble de contexte diffs pour un fichier source ou une hiérarchie de répertoires donné. Voir les pages de manuel pour diff (1) pour plus de détails. Une fois que vous avez l'ensemble des diffs (que vous pouvez tester avec la commande patch(1), vous devriez les soumettre pour qu'ils puissent être inclus dans FreeBSD. Utilisez le programme send-pr (1) comme décrit dans Rapport de bugs et commentaires généraux. Ne pas simplement envoyer les diffs à &a.hackers; ou ils seront perdus ! Nous apprécions beaucoup vos soumissions (c'est un projet fait par des volontaires !), mais parce que nous sommes très occupé, nous ne pourrons pas les étudier immédiatement, mais cela restera dans la base de données jusqu'à ce que nous le fassions. Si cela vous semble approprié (par exemple si vous avez renommé les fichiers), mettre vos modifications dans un fichier tar et lancer le programme uuencode (1) dessus. Les archives shar sont aussi les bienvenues. Si vos modifications sont potentiellement sensibles, par exemple si vous n'êtes pas sûr des problèmes de copyright concernant sa distribution, ou si vous n'êtes simplement pas prêt à le distribuer sans y avoir jeté un coup d'oeil, alors vous devriez l'envoyer directement à &a.core; plutôt que de le soumettre avec send-pr(1). La liste de diffusion principale atteint un petit groupe de personnes qui réalise la plupart du travail quotidien de FreeBSD. Notez que ce groupe est aussi très occupé, et donc que vous ne devriez leur envoyer un courrier électronique que lorsque cela est réellement nécessaire. Se réferrer à man 9 intro et man 9 style pour plus d'informations sur la manière de coder. Nous apprécierons le fait que vous soyez au moins au courant de cette information avant de nous soumettre du code. Nouveau code source ou logiciel à valeur ajoutée importante Dans les rares cas d'une collaboration importante, ou de l'addition d'une importante fonctionnalité à FreeBSD, il devient presque nécessaire d'envoyer les modification en les uuncodant dans des fichiers tar et en les chargeant sur notre site FTP ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming. Lorsque l'on travaille avec un grand volume de code, le sujet sensible du copyright revient invariablement. Les copyrights acceptables pour le code inclu dans FreeBSD sont : Le copyright BSD. Ce copyright est le plus apprécié par son côté “sans attaches” et son attractivité générale pour les entreprises commerciales. Loin de décourager un tel usage commercial, le projet FreeBSD encourage activement une telle participation avec interêts commerciaux pour ceux qui seraient éventuellement tenté d'investir quelque chose dans FreeBSD. La licence publique GNU, ou “GPL”. Cette licence n'est pas aussi populaire chez nous à cause du volume d'efforts supplémentaires demandés à celui qui voudrait utiliser le code dans un but commercial. Mais étant donné la quantité de code de code GPL dont nous avons actuellement besoin (compilateur, assembleur, formatteur de texte, etc), il serait absurde de refuser des collaborations sous cette licence. Le code sous GPL va dans une différente partie de l'arborescence des répertoires : /sys/gnu ou /usr/src/gnu, et est de ce fait très identifiable par quelqu'un dont la licence GNU poserait un problème. Les collaborations venant avec un autre type de copyright doivent être soigneusement vérifié avant leur inclusion dans FreeBSD. Les contributions où des restrictions commerciales particulières s'appliquent sont généralement rejetées. Les auteurs sont toujours encouragés à mettre ces modifications disponibles par leur propre moyens. Pour mettre un copyright de “style BSD” sur votre travail, inclure le texte suivant au tout début de chaque code source que vous voulez protéger, en remplaçant le texte entre les %% par l'information appropriée. Copyright (c) %%annee%% %%votre_nom_ici%%, %%votre_ville%% %%votre_code_postal%%. Tous droits réservés La redistribution et l'utilisation des sources et des formes binaires, avec ou sans modifications, sont autorisées si les conditions suivantes soient réunies : 1. Les redistributions du code source doivent conserver la notification de copyright ci-dessus, cette liste de conditions et le démenti suivant comme premières lignes de ce fichier, ceci non modifiés. 2. Les redistributions sous forme binaire doivent reproduire la notification de copyright ci-dessus, cette liste de conditions et le démenti suivant en documentation et/ou sur les autres supports de la distribution. CE LOGICIEL EST FOURNI EN L'ETAT PAR ''%%VOTRE_NOM_ICI%%'' ET TOUTES GARANTIES EXPRES OU IMPLICITES, Y COMPRIS, MAIS NON LIMITE A, LES GARANTIES IMPLICITES DE LA VALEUR MARCHANDE ET PHYSIQUE DANS UN BUT PARTICULIER SONT DEMENTIES. EN AUCUN CAS %%VOTRE_NOM_ICI%% SERA RESPONSABLE DES DOMMAGES DIRECTS, INDIRECTS, FORTUITS, SPECIAUX, EXEMPLAIRES, OU CONSECUTIFS (COMPRENANT, MAIS NON LIMITÉ A : REMPLACEMENT DES MARCHANDISES OU SERVICES; PERTE DE DONNEES, OU DE BENEFICES ; OU INTERRUPTION D'AFFAIRES) CAUSEE ET SUR TOUTE THEORIE DE RESPONSABILITE, SI DANS LE CONTRAT, LA RESPONSABILITE SANS FAUTE INTENTIONNELLE, OU TORT (NEGLIGENCE Y COMPRIS OU AUTRES) SURGISSANT EN CONSEQUENCE DE L'UTILISATION DE CE LOGICIEL, CECI, MĘME SI INFORME DE LA POSSIBILITE D'UN TEL DOMMAGE. $Id$ Pour votre convenance, une copie de ce texte peut être trouvée dans /usr/share/examples/etc/bsd-style-copyright. Contribution financière, matériel ou accès Internet Nous sommes toujours très heureux de recevoir des donations pour poursuivre la cause du projet FreeBSD, et dans un effort volontaire comme le nôtre, un rien peut faire du chemin ! Les donations de matériel sont également très importantes pour augmenter notre liste de périphériques supportés puisque nous manquons souvent de fonds pour acheter de tels éléments nous-mêmes. <anchor id="donations">Donation de fonds Comme le projet FreeBSD n'est pas une corporation 501(c)(3) (charitable), et par conséquent ne peut offrir des réductions fiscales, toute donation sera acceptée avec reconnaissance au nom du projet par FreeBSD, inc. FreeBSD, Inc. a été fondé au début de l'année 1995 par &a.jkh; et &a.dg; avec le but de promouvoir les objectifs du projet de FreeBSD et de lui donner une présence minimale de corporation. Tout fond donné (ainsi que tous bénéfices qui peuvent par la suite être réalisés par FreeBSD, inc.) seront exclusivement employés à poursuivre les buts du projet. Tous les chèques doivent être adressés à l'ordre de FreeBSD, Inc. et envoyés à l'adresse suivante :
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(utilisant l'adresse de Walnut Creek CDROM en attendant qu'une boite postale puisse être ouverte) Les transferts de fonds peuvent être directement envoyés à :
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routage #: 121-000-358 Compte #: 01411-07441 (FreeBSD, Inc.)
Toute correspondance à propos de dons, devrait être envoyé directement à Jordan Hubbard jkh@FreeBSD.org, soit par courrier électronique, soit à l'adresse postale de FreeBSD, Inc. donnée ci-dessus. Si vous ne voulez pas être listé dans notre section donateur le spécifier lors de votre don, merci ! Contribution matérielle La contribution en matériel tombant dans une des trois catégories suivantes sont joyeusement acceptées par le projet FreeBSD : Le matériel à caractère général comme les disques, la mémoire ou des systèmes complets doivent être envoyés à l'adresse de FreeBSD, Inc. donnée dans la section donation de fonds. Le matériel pour tests de compatibilité en cours est apprécié. Nous sommes actuellement en train de rassembler un laboratoire de test pour tous les composants supportés par FreeBSD, ceci afin que des tests de regressions puissent être effectués à chaque nouvelle version. Nous manquons actuellement d'importants composants (cartes éthernet, cartes mère, etc) et si vous voulez faire un tel don, contactez &a.dg; pour des informations sur le matériel dont nous avons toujours besoin. Du matériel non supporté actuellement par FreeBSD et que vous voudriez voir supporté. Contactez &a.core; avant de nous envoyer ces articles car il faut que nous trouvons un développeur acceptant de se charger de cette tâche avant d'accepter ce nouveau matériel. Contribution d'accès Internet Nous pouvons toujours utiliser de nouveaux sites mirroirs pour les FTP, WWW ou cvsup. Si vous voulez devenir un tel mirroir, contactez les administrateurs du projet FreeBSD admin@FreeBSD.ORG pour plus d'informations. Les donateurs Le projet FreeBSD est en dette envers les donateurs suivants et voudrait les remercier publiquement ici ! Contributeurs au projet du serveur central : Les personnes à titre privé ou commercial suivantes ont rendu possible pour le projet FreeBSD de construire la machine serveur centrale pour éventuellement remplacer freefall.freebsd.org en donnant les articles suivants : Ade Barkah mbarkah@freebsd.org et son employeur, Hemisphere Online, ont donné un Pentium Pro (P6) 200Mhz CPU ASA Computers ont donné une carte mère Tyan 1662. Joe McGuckin joe@via.net de ViaNet Communications a donné un contrôleur ethernet Kingston. Jack O'Neill jack@diamond.xtalwind.net a donné une carte contrôleur NCR 53C875 SCSI. Ulf Zimmermann ulf@Alameda.net de Alameda Networks a donné 128MB de mémoire , un disque de 4 Gb et la valise. Fonds directs : Les personnes suivantes ont généreusement contribué - à titre privé ou commercial - directement aux fonds du projet : Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU Matt Dillon dillon@best.net Epilogue Technology Corporation Sean Eric Fagan Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris Chuck Robey chuckr@freebsd.org Kenneth P. Stox ken@stox.sa.enteract.com de Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 du Japon (une partie de leur bénéfice de la vente de leurs différents CD-ROM de FreeBSD. Fuki Shuppan Publishing Co. ont donné une partie de leur bénéfice sur Hajimete no FreeBSD (débuter sous FreeBSD) aux projets FreeBSD et XFree86. ASCII Corp. ont donné une partie de leur bénéfice de vente sur des produits sur FreeBSD. Yokogawa Electric Corp ont généreusement donné des fonds significatifs au projet FreeBSD. BuffNET Pacific Solutions Contribution matérielle : Les personnes suivantes à titre privé ou commercial, ont généreusement contribué en matériel pour les tests et le développement/support des pilotes de périphérique : Walnut Creek CDROM pour avoir fourni le Pentium P5-90 et le 486/DX2-66 EISA/VL qui sont actuellement utilisés pour notre travail de développement, cela sans parler de l'accès réseau et d'autres dons de matériels. TRW Financial Systems, Inc. nous a fourni 130 PC, trois serveurs de fichiers 68 GB, douze Ethernets, deux routeurs et un commutateur ATM pour déboguer un code sans disque. Dermot McDonnell a donné un lecteur CDROM Toshiba XM3401B actuellement utilisé dans freefall. - &a.chuck; a contribué par son lecteur de + Chuck Robey a contribué par son lecteur de bande pour le travail expérimental. Larry Altneu larry@ALR.COM, and &a.wilko;, ont donné des lecteurs de bandes Wangtek and Archive QIC-02 afin d'améliorer les wt pilotes. Ernst Winter ewinter@lobo.muc.de a contribué par son lecteur de disquette 2.88 MB au projet. Cela augmentera la pression pour réécrire le pilote du lecteur de disquette.;-) Tekram Technologies a envoyé chacun de leur carte adapteur hôte DC-390, DC-390U et DC-390F FAST and ULTRA SCSI pour les tests de regression des pilotes NCR et AMD avec leur cartes. Ils peuvent être aussi acclamé pour avoir rendu leurs sources de pilotes disponibles sur les serveur FTP pour les systèmes s'exploitation libres.ftp://ftp.tekram.com/scsi/FreeBSD. Larry M. Augustin ont contribué non seulement avec une carte Symbios Sym8751S SCSI mais aussi par un ensemble de livres de données, y compris la prochaine puce Sym53c895 chip avec support Ultra-2 et LVD, et pour le dernier manuel de programmation avec des informations sur la manière d'utiliser sûrement les fonctionnalités avancées de la dernière puce Symbios SCSI chips. Merci beaucoup ! Christoph Kukulies kuku@freebsd.org a donné un lecteur CDROM FX120 12 vitesse Mitsumi pour le développement de pilote CDROM IDE. Contributeurs spéciaux : Walnut Creek CDROM a donné plus que nous pourrions le dire (voir le document de l'historique pour plus de détails. En particulier, nous voudrions les remercier pour le matériel original utilisé pour freefall.FreeBSD.ORG, notre principale machine de développement, et pour thud.FreeBSD.ORG, une machine de test et de construction. Nous leur sommes aussi gré pour le financement de plusieurs collaborateurs au fil des années, et pour nous avoir fourni un accès illimité à leur connexion T1 à l'Internet. interface business GmbH, Dresden qui ont patiemment supportés &a.joerg; qui a souvent préféré le travail FreeBSD au travail pour lequel il était payé, et a utilisé leur (coûteuse) connexion EUnet Internet lorsque sa connexion privée devenait trop lente pour tavailler décemment avec ... Berkeley Software Design, Inc. ont contribué en donnant leur émulateur DOS au reste du monde BSD, qui est utilisé dans la commande dosemu. Les anciens de l'équipe principale Les personnes suivantes ont été membre de l'équipe de base de FreeBSD durant la période indiquée. Nous les remercions de leurs efforts passés au service du projet FreeBSD. Dans un ordre chronologique brut : Guido van Rooij (1995 - 1999) John Dyson (1993 - 1998) Nate Williams (1992 - 1996) Rod Grimes (1992 - 1995) Andreas Schulz (1992 - 1995) Geoff Rehmet (1993 - 1995) Paul Richards (1992 - 1995) Scott Mace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Collaborateurs des logiciels dérivés Ce logiciel dérive originelement du 386BSD version 0.1 de William F. Jolitz. Ce logiciel a été essentiellement réimplémenté depuis la version 4.4BSD-Lite fourni par le Computer Science Research Group (CSRG) à l'université de Californie à Berkeley et des académies collaboratices associées. Il ya aussi des portions de NetBSD et OpenBSD qui ont été intégrés dans le code FreeBSD, et nous voulons de ce fait remercier tous les collaborateurs de NetBSD et OpenBSD pour leur travail. (Dans l'order alphabétique par le prénom) : ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@tau.veritas.com Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adrian Colley aecolley@ois.ie Adrian Hall adrian@ibmpcug.co.uk Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alan Cox alc@cs.rice.edu Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Alex garbanzo@hooked.net Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex G. Bulushev bag@demos.su Alex Le Heux alexlh@funk.org Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby nickerne@nome.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Zakhvatov andy@icc.surw.chel.su Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Antti Kaipila anttik@iki.fi Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Assar Westerlund assar@sics.se Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Smithurst ben@scientia.demon.co.uk Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd R. Faulkner faulkner@asgard.bga.com Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Gillespie brandon@roguetrader.com - &a.wlloyd + Bill Lloyd wlloyd@mpd.ca Bob Wilcox bob@obiwan.uucp Boyd Faulkner faulkner@mpd.tandem.com Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.physics.montana.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian F. Feldman green@unixhelp.org Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce A. Mah bmah@ca.sandia.gov Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Cejka Rudolf cejkar@dcse.fee.vutbr.cz Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@srv.net Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Choi Jun Ho junker@jazz.snu.ac.kr Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Piazza cpiazza@home.net Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@bigeye.rhein-neckar.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Clive Lin clive@CiRX.ORG Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@neosoft.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dai Ishijima ishijima@tri.pref.osaka.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Walters hannibal@cyberstation.net Daniel Baker dbaker@crash.ops.neosoft.com Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@umiacs.umd.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo filo@yahoo.com David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Malone dwmalone@maths.tcd.ie David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com Derek Inksetter derek@saidev.com Dima Sivachenko dima@Chg.RU Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Don Croyle croyle@gelemna.ft-wayne.in.us &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Doug Barton studded@dal.net Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Duncan Barclay dmlb@ragnet.demon.co.uk Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Eiji-usagi-MATSUmoto usagi@clave.gr.jp ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eric A. Griff eagriff@global2000.net Eric Blood eblood@cs.unr.edu Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank Volf volf@oasis.IAEhv.nl Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Garance A Drosehn gad@eclipse.its.rpi.edu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gerard Roudier groudier@club-internet.fr Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giles Lean giles@nemeton.com.au Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hidetoshi Shimokawa simokawa@sat.t.u-tokyo.ac.jp Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Hiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jp Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagaio kuma@jp.freebsd.org Horikawa Kazuo k-horik@mail.yk.rim.or.jp Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Ian Dowse iedowse@maths.tcd.ie Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilya V. Komarov mur@lynx.ru Issei Suzuki issei@jp.FreeBSD.org Itsuro Saito saito@miv.t.u-tokyo.ac.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@best.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com J.T. Jang keith@email.gcn.net.tw Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu James da Silva jds@cs.umd.edu Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@ito.uni-stuttgart.de Jeremy Allison jallison@whistle.com Jeremy Chatfield jdc@xinside.com Jeremy Lea reg@shale.csir.co.za Jeremy Prior unknown Jeroen Ruigrok/Asmodai asmodai@wxs.nl Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Mock jim@phrantic.phear.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart unknown Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton sutton@aardvark.apana.org.au Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Baldwin jobaldwi@vt.edu John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John W. DeBoskey jwd@unx.sas.com John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Josef Grosch jgrosch@superior.mooseriver.com Josef Karthauser joe@uk.freebsd.org Joseph Stein joes@seaport.net Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jua@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk Julian H. Stacey jhs@freebsd.org Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.freebsd.org Junji SAKAI sakai@jp.freebsd.org Junya WATANABE junya-w@remus.dti.ne.jp K.Higashino a00303@cc.hc.keio.ac.jp KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com Kato Takenori kato@eclogite.eps.nagoya-u.ac.jp Kauzo Horikawa h-horik@yk.rim.or.jp Kawanobe Koh kawanobe@st.rim.or.jp Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp Kazuo Horikawa horikawa@jp.FreeBSD.org Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kiroh HARADA kiroh@kh.rim.or.jp Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Lars Köller Lars.Koeller@Uni-Bielefeld.DE Larry Altneu larry@ALR.COM Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.com M.C. Wong unknown MANTANI Nobutaka nobutaka@nobutaka.com MIHIRA Sanpei Yoshiro sanpei@sanpei.org MITA Yoshio mita@jp.FreeBSD.ORG MITSUNAGA Noriaki mitchy@er.ams.eng.osaka-u.ac.jp MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.freebsd.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Malte Lance malte.lance@gmx.net Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marcel Moolenaar marcel@scc.nl Mario Sergio Fujikawa Ferreira lioux@gns.com.br Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk Martin Birgmeier Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Renters martin@tdc.on.ca Martti Kuparinen erakupa@kk.etx.ericsson.se Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Mas.TAKEMURA unknown Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ncs.co.jp Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew N. Dodd winter@jurai.net Matthew Stein matt@bdd.net Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Micha Class michael_class@hpbbse.bbn.hp.com Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.ORG Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Searle searle@longacre.demon.co.uk Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@shiva.the-park.com Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.ziplink.net Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW Mitsuru IWASAKI iwasaki@pc.jaring.my Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com Mostyn Lewis mostyn@mrl.com Motoyuki Kasahara m-kasahr@sra.co.jp Motoyuki Konno motoyuki@snipe.rim.or.jp Munechika Sumikawa sumikawa@kame.net Murray Stokely murray@cdrom.com N.G.Smith ngs@sesame.hensa.ac.uk NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@zeisei.dpri.kyoto-u.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp NIIMI Satoshi sa2c@and.or.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Nadav Eiron nadav@barcode.co.il Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Neil Blakey-Milner nbm@rucus.ru.ac.za Niall Smart rotel@indigo.ie Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Sayer nsayer@quack.kfu.com Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name ZW6T-KND@j.asahi-net.or.jp No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.freebsd.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.ORG Noriyuki Soda soda@sra.co.jp Olaf Wagner wagner@luthien.in-berlin.de Oleg Sharoiko os@rsu.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@freebsd.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Gardella patrick@cre8tivegroup.com Patrick Hausen unknown Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Saab paul@mu.org Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com R. Kym Horsell Rajesh Vaidheeswarran rv@fore.com Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@drmemory.fnal.gov Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Watson robert@cyrus.watson.org Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka unknown Ruslan Belkin rus@home2.UA.net Ruslan Ermilov ru@ucb.crimea.ua Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com SANETO Takanori sanewo@strg.sony.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp SUGIMURA Takashi sugimura@jp.FreeBSD.ORG SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp Satoshi Taoka taoka@infonets.hiroshima-u.ac.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Seigou TANIMURA tanimura@naklab.dnj.ynu.ac.jp Serge A. Babkin babkin@hq.icb.chel.su Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Potapov sp@alkor.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Sheldon Hearn axl@iafrica.com Shigio Yamaguchi shigio@wafu.netgate.net Shunsuke Akiyama akiyama@jp.freebsd.org Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sune Stjerneby stjerneby@usa.net Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp Takahashi Yoshihiro nyan@dd.catv.ne.jp Takahiro Yugawa yugawa@orleans.rim.or.jp Takanori Watanabe takawata@shidahara1.planet.sci.kobe-u.ac.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Tatsumi HOSOKAWA hosokawa@jp.FreeBSD.org Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon unknown Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Gellekum thomas@ghpc8.ihf.rwth-aachen.de Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Hukins tom@eborcom.com Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Torbjorn Granlund tege@matematik.su.se Toshihiko ARAI toshi@tenchi.ne.jp Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wilfredo Sanchez wsanchez@apple.com Wiljo Heinen wiljo@freeside.ki.open.de Wilko Bulte wilko@yedi.iaf.nl Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko OHTA yohta@bres.tsukuba.ac.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yukihiro Nakai nacai@iname.com Yusuke Nawano azuki@azkey.org Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw arci vega@sophia.inria.fr der Mouse mouse@Collatz.McRCIM.McGill.EDU frf frf@xocolatl.com Ege Rekk aagero@aage.priv.no Collaborateurs pour les correctif 386BSD (En ordre alphabétique par prénom) : Adam Glass glass@postgres.berkeley.edu Adrian Hall adrian@ibmpcug.co.uk Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@freebsd.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.ORG Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il diff --git a/fr_FR.ISO8859-1/books/handbook/linuxemu/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/linuxemu/chapter.sgml index 45a5234038..d08c1dd447 100644 --- a/fr_FR.ISO8859-1/books/handbook/linuxemu/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/linuxemu/chapter.sgml @@ -1,973 +1,973 @@ Emulation Linux - Contribution de &a.handy; et &a.rich; + Contribution de Brian N. Handy et &a.rich; &trans.a.haby; Comment installer l'émulateur Linux L'émulation de Linux sous FreeBSD a atteint un point où il est possible d'exécuter une grande partie des binaires Linux et au format a.out et au format ELF. L'émulation Linux de la branche 2.1-stable peut exécuter les versions Linux de Doom et Mathematica; la version de l'émulateur sous &rel.current;-release a encore plus de possibilités et exécute en plus de ces programmes, les versions Linux de Quake, Abuse, IDL, netrek et bien d'autres programmes. Il y a quelques particularités du système d'exploitation Linux qui ne sont pas supportées sous FreeBSD. Les binaires Linux ne fonctionneront pas sous FreeBSD s'ils utilisent le système de fichiers /proc de Linux (qui diffère du système de fichiers /proc optionnel de FreeBSD) ou des appels i386 spécifiques, comme l'activation du mode virtuel 8086. Selon la version de FreeBSD que vous utilisez, la mise en oeuvre de l'émulation Linux se fait de façon légèrement différente : Installer l'émulation Linux sous 2.1-stable Le noyau GENERIC de 2.1-stable n'est pas configuré pour être compatible Linux, vous devez donc le reconfigurer pour cela. Il y a deux façons de faire : Lier statiquement l'émulateur Linux au noyau lui-même, Configurer le noyau pour qu'il charge dynamiquement le module Linux. Pour mettre en oeuvre l'émulateur, ajoutez la ligne suivante à votre fichier de configuration du noyau (c.f. /sys/i386/conf/LINT) : options COMPAT_LINUX Si vous voulez utiliser Doom ou d'autres applications qui utilisent les mémoires partagées, ajoutez aussi : options SYSVSHM Les appels système Linux ont besoin de la compatibilité 4.3BSD. Vérifiez que vous avez bien la ligne : options "COMPAT_43" Si vous préférez lier statiquement l'émulateur au noyau plutôt qu'utiliser le module du noyau à chargement dynamique - loadable kernel module (LKM), ajoutez aussi : options LINUX Configurez et installez ensuite le nouveau noyau comme décrit au chapitre Configurer le noyau de FreeBSD. Si vous avez choisi d'utiliser le LKM, vous devez aussi installer le module. Une incompatibilité de version entre le noyau et le module à chargement dynamique peut planter le noyau. La façon la plus sûre de procéder est donc de réinstaller le LKM en même temps que le noyau : &prompt.root; cd /usr/src/lkm/linux &prompt.root; make all install Une fois que vous avez installé le noyau et le LKM, vous pouvez utiliser linux sous le compte super-utilisateur root pour charger le LKM : &prompt.root; linux Linux emulator installed Module loaded as ID 0 Pour vérifier que le LKM est chargé, utilisez modstat : &prompt.user; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator Il y a deux façons de charger le LKM au démarrage. Sous FreeBSD 2.2.1-release et 2.1-stable, activez-le dans /etc/sysconfig : linux=YES en remplaçant NO par YES. Sous FreeBSD 2.1-release et antérieurs, cette ligne n'existe pas. Vous devez donc éditer /etc/rc.local et y ajouter la ligne : linux Installer l'émulation Linux sous 2.2.2-release et ultérieurs Il n'y a plus besoin de préciser options LINUX ou options COMPAT_LINUX. L'émulation Linux est réalisée par un module du noyau à chargement dynamique - LKM (“Loadable Kernel Module”) - et peut donc être installée à la volée sans avoir à redémarrer le système. Vos fichiers de démarrage devront néanmoins comporter les instructions suivantes : Dans /etc/rc.conf, la ligne suivante : linux_enable=YES Ce qui ensuite active les commandes ci-dessous dans /etc/rc.i386 : # Start the Linux binary emulation if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi Si vous voulez vérifier que l'émulation est active, utilisez modstat : &prompt.user; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod On a cependant signalé des cas où cela ne marchait pas avec certains systèmes 2.2-release et ultérieurs. Si pour une raison ou une autre vous ne pouvez pas charger le LKM Linux, liez alors statiquement l'émulateur au noyau en ajoutant la ligne : options LINUX à votre fichier de configuration du noyau. Configurez et installez ensuite le nouveau noyau comme décrit au chapitre Configurer le noyau de FreeBSD. Installer les bibliothèques Linux Installation à l'aide du “logiciel porté” <filename>linux_lib</filename> La plupart des applications Linux utilisent des bibliothèques partagées, vous n'avez donc pas tout ce qu'il vous faut tant que vous n'avez pas installé les bibliothèques partagées. Vous pouvez le faire à la main, mais il est beaucoup plus facile d'installer le logiciel porté linux_lib : &prompt.root; cd /usr/ports/emulators/linux_lib &prompt.root; make all install et votre émulation Linux devrait fonctionner. La légende et les archives du courrier électronique :-) veulent que l'émulation Linux fonctionne mieux avec des binaires Linux liés avec les bibliothèques ZMAGIC; Les bibliothèques QMAGIC (telles celles utilisées par la distribution Slackware V2.0) peuvent avoir tendance à donner des maux d'estomac au “Linuxlateur”. Attendez-vous aussi à ce que certains programmes se plaignent de versions mineures incorrectes de bibliothèques système. Ce n'est cependant généralement pas un problème. Installer les bibliothèques à la main Si vous n'avez pas installé la distribution pour les “logiciels portés”, vous pouvez à la place installer les bibliothèques à la main. Il vous faudra les bibliothèques partagées Linux dont a besoin le programme et l'éditeur de liens dynamiques. Vous devrez aussi créer un répertoire racine “masquant” - shadow root - /compat/linux pour les bibliothèques Linux sur votre système FreeBSD. Les bibliothèques partagées ouvertes par les programmes Linux exécutés sous FreeBSD iront d'abord voir dans cette arborescence. Ainsi, si un programme Linux charge par exemple, /lib/libc.so, FreeBSD essayera d'abord d'ouvrir /compat/linux/lib/libc.so, puis, si cette bibliothèque n'existe pas, /lib/libc.so. Les bibliothèques partagées doivent donc être installées sous l'arborescence /compat/linux/lib plutôt que sous les chemins d'accès mentionnés par la commande Linux ld.so. Le fonctionnement de FreeBSD-2.2-release et ultérieurs est légèrement différent en ce qui concerne /compat/linux : tous les fichiers, et pas seulement les bibliothèques, sont recherchés dans l'arborescence “shadow root” /compat/linux. Habituellement, vous n'aurez à chercher à savoir de quelles bibliothèques partagées dépendent les binaires Linux que les premières fois que vous installerez des exécutables Linux sur votre système FreeBSD. Après quelques temps, vous disposerez d'un jeu suffisant de bibliothèques partagées Linux sur votre système pour pouvoir exécuter les binaires Linux nouvellement importés sans installation supplémentaire. Comment installer des bibliothèques partagées supplémentaires Comment faire si vous avez installé le logiciel porté linux_lib et que votre application se plaint toujours qu'il lui manque des bibliothèques partagées ? Comment savoir de quelles bibliothèques partagées ont besoin les binaires Linux, et où se les procurer ? Il y a habituellement deux possibilités (si vous suivez les instructions ci-dessous , vous devrez être en session sous le compte super-utilisateur root pour effectuer les étapes nécessaires à l'installation). Si vous avez accès un système Linux, déterminez de quelles bibliothèques partagées l'application a besoin et copiez-les sur votre système FreeBSD. Supposons que vous veniez de télécharger le binaire Linux de Doom. Installez-le sur le système Linux auquel vous avez accès, et vérifiez de quelles bibliothèques partagées il a besoin avec la commande ldd linuxxdoom : &prompt.user; ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 Vous devrez récupérer tous les fichiers mentionnés dans la dernière colonne et les installer sous /compat/linux, en utilisant les noms de la première colonne comme liens symboliques qui pointent dessus. Ce qui signifie que vous aurez éventuellement les fichiers suivants sur votre système FreeBSD : /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 Remarquez que si vous avez déjà une bibliothèque partagée de même numéro de version majeure que celle indiquée par la première colonne du résultat de ldd, il est inutile de copier le fichier décrit par la dernière colonne sur votre système, celui que vous avez déjà devrait suffire. Il est cependant recommandé de recopier malgré tout la bibliothèque partagée si c'est une version plus récente. Vous pouvez supprimer la version plus ancienne, du moment que le lien symbolique pointe sur la nouvelle. Par exemple, si vous avez les bibliothèques suivantes sur votre système : /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 et que vous trouvez un nouveau binaire qui, d'après le résultat de la commande ldd semble avoir besoin d'une version plus récente : libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 Si vous n'avez qu'une ou deux versions de retard sur le dernier indice, ne vous souciez pas d'installer la version /lib/libc.so.4.6.29 plus récente, parce que le programme devrait fonctionner sans problème avec une version légèrement antérieure. Vous pouvez néanmoins décider de remplacer libc.so, ce qui devrait vous donner quelque chose comme : /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 Le mécanisme de lien symbolique n'est nécessaire que pour les binaires Linux. L'éditeur de liens dynamiques de FreeBSD se charge lui-même de trouver les numéros de versions majeures adéquats et vous n'avez pas à vous en préoccuper. Configurer <filename>ld.so</filename>—pour FreeBSD 2.2-release et ultérieurs Cette section ne s'applique qu'à FreeBSD 2.2-release et ultérieurs. Ceux qui utilisent 2.1-stable peuvent l'ignorer. Pour finir, si vous utilisez FreeBSD 2.2-release, vous devez vérifier que vous disposez de l'éditeur de liens dynamiques Linux et de ses fichiers de configuration sur votre système. Vous devez copier ces fichiers du système Linux à l'endroit approprié sur votre système FreeBSD (dans l'arborescence /compat/linux) : /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config Si vous n'avez pas accès à un système Linux, vous devrez récupérer les fichiers supplémentaires de différents sites ftp. Des informations sur où trouver les divers fichiers sont données plus bas. Supposons pour l'instant que vous savez où récupérer les fichiers. Téléchargez les fichiers suivants (du même site ftp pour éviter les incompatibilités de version) et installez-les sous /compat/linux (i.e., /foo/bar est installé sous /compat/linux/foo/bar): /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so ldconfig et ldd n'ont pas obligatoirement besoin d'être sous l'arborescence /compat/linux; vous pouvez aussi les installer ailleurs sur votre système. Veillez cependant à ce qu'il n'y ait pas de conflit avec leurs équivalents FreeBSD. C'est une bonne idée de les mettre dans /usr/local/bin où sont ldconfig-linux et ldd-linux. Créez le fichier /compat/linux/etc/ld.so.conf, décrivant les répertoires où l'éditeur de liens dynamiques Linux devra chercher les bibliothèques partagées. C'est un fichier texte ordinaire, avec un nom de répertoire par ligne. /lib and /usr/lib sont standard, vous pourriez ajouter les lignes suivantes : /usr/X11/lib /usr/local/lib Quand un binaire Linux ouvre une bibliothèque telle que /lib/libc.so, l'émulateur effectue en interne la correspondance avec /compat/linux/lib/libc.so. Toutes les bibliothèques Linux doivent être installées sous /compat/linux (e.g., /compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so, etc.) pour que l'émulateur puisse les trouver. Ceux qui utilisent FreeBSD 2.2-release doivent exécuter le programme ldconfig Linux. &prompt.root cd /compat/linux/lib &prompt.root; /compat/linux/sbin/ldconfig ldconfig est lié statiquement, il n'a donc pas besoin des bibliothèques partagées pour s'exécuter. Il crée le fichier /compat/linux/etc/ld.so.cache qui contient les noms de toutes les bibliothèques partagées, et doit être réexécuté pour recréer ce fichier chaque fois que vous installez de nouvelles bibliothèques partagées. Sous 2.1-stable, n'installez pas /compat/linux/etc/ld.so.cache et n'exécutez pas ldconfig; sous 2.1-stable, les appels système sont implémentés différemment et ldconfig n'est ni utile ni utilisé. Tout devrait être maintenant en place pour les binaires Linux qui n'ont besoin que d'une bibliothèque libc partagée. Vous pouvez le tester en exécutant la commande ldd Linux sur elle-même. Supposons que vous l'ayez installé sous le nom ldd-linux, le résultat devrait ressembler à quelque chose comme : &prompt.root; ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 Une fois que c'est fait, vous êtes prêt à installer de nouveaux binaires Linux. Toutes les fois que vous installez un nouveau programme Linux, vous devriez vérifier s'il a besoin de nouvelles bibliothèques partagées, et si tel est le cas, les installer dans l'arborescence /compat/linux. Pour cela, vous exécutez la version Linux de ldd sur le nouveau programme et consultez le résultat. ldd (reportez-vous aussi aux pages de manuel de &man.ldd.1;) imprimera la liste des bibliothèques partagées dont dépend le programme, sous la forme nom principal (référence de version) => nom complet. S'il imprime not found au lieu du nom complet, cela signifie qu'il vous faut une nouvelle bibliothèque. La bibliothèque dont vous avez besoin est celle indiquée par son nom principal sous forme libXXXX.so.N. Il faudra que vous trouviez libXXXX.so.N.mm sur un site ftp Linux et que vous l'installiez sur votre système. XXXX (nom) et N (numéro de version majeure) doivent correspondre; le(s) numéro(s) de version(s) mineure(s) sont moins importants, bien qu'il soit conseillé de prendre la version la plus récente. Installer des binaires Linux ELF Il y a parfois besoin d'une étape supplémentaire pour les binaires ELF : “le marquage”. Si vous essayez d'exécuter un binaire ELF non marqué vous aurez un message d'erreur ressemblant à ce qui suit : &prompt.user; ./mon-binaire-elf-linux ELF binary type not known Abort Pour que le noyau de FreeBSD puisse distinguer entre un binaire ELF FreeBSD et un binaire Linux, vous devez employer l'utilitaire &man.brandelf.1;. &prompt.user; brandelf -t Linux mon-binaire-elf-linux Les outils GNU incorporent maintenant automatiquement les marques nécessaires dans les binaires ELF, vous aurez donc de moins en moins besoin de passer par cette étape à l'avenir. Configurer le solveur de noms de domaines Si le DNS ne fonctionne pas, ou si vous avez les messages : resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword vous devez renseigner un fichier /compat/linux/etc/host.conf contenant : order hosts, bind multi on où l'ordre ci-dessus spécifie qu'il faut d'abord regarder dans le fichier /etc/hosts puis interroger le DNS. Si le fichier /compat/linux/etc/host.conf n'est pas installé, les applications Linux trouvent le fichier /etc/host.conf de FreeBSD et se plaignent de sa syntaxe FreeBSD incompatible. Supprimez bind, si vous n'avez pas configuré de serveur de noms avec le fichier /etc/resolv.conf. Enfin, ceux qui utilisent 2.1-stable doivent définir une variable d'environnement RESOLV_HOST_CONF pour que les applications sachent comment chercher dans les tables de noms de machines. Si vous êtes sous FreeBSD 2.2-release ou ultérieurs, vous pouvez vous en passer. Avec l'interpréteur de commandes /bin/csh, utilisez : &prompt.user; setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf Avec /bin/sh, utilisez : &prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF Trouver les fichiers nécessaires Les informations qui suivent sont valables à la date de rédaction de ce document, mais certains détails, tels que les noms des sites ftp, des répertoires ou des distributions peuvent avoir changé au moment où vous le lirez. Linux est distribué par plusieurs groupes donc chacun constitue l'ensemble de programmes qu'il distribue. Chaque distribution a son propre nom, “Slackware” ou “Yggdrasil”, par exemple. Ces distributions sont disponibles sur nombre de sites ftp. Les fichiers sont parfois individualisés, et vous pouvez récupérer uniquement les fichiers dont vous avez besoin, mais ils sont généralement archivés par distributions, compactées et compressées avec tar 1 et gzip 1. Les sites ftp principaux pour les distributions sont : sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions Quelques sites miroirs européens : ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/unix/linux src.doc.ic.ac.uk:/packages/linux/distributions Pour simplifier, nous nous concentrerons sur la Slackware. Cette distribution est composée d'un certain nombre de sous-répertoires, contenant des paquetages séparés. Ils sont normalement contrôlés par un programme d'installation, mais vous pouvez aussi les récupérer à la main. Vous devrez d'abord aller voir dans le sous-répertoire contents de la distribution. Vous y trouverez de nombreux petits fichiers texte décrivant le contenu de chacun des paquetages. La façon la plus rapide de retrouver quelque chose est de récupérer tous les fichiers de ce sous-répertoire et d'y rechercher avec grep 1 le fichier dont vous avez besoin. Voici un exemple d'une liste de fichiers dont vous pourriez avoir besoin et où vous les trouveriez en cherchant dans les fichiers de contenu : Bibliothèque Paquetage ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf_lib libXt.so.6.0 xf_lib libX11.so.3 oldlibs libXt.so.3 oldlibs Dans ce cas donc, vous auriez besoin des paquetages ldso, shlibs, xf_lib et oldlibs. Dans chacun des fichiers de contenu de ces paquetages, recherchez la ligne PACKAGE LOCATION, qui vous dira sur quel “disque” le paquetage se trouve; dans notre cas, cela nous dira dans quel sous-répertoire il faut regarder. Pour notre exemple, nous trouverions : Paquetage Localisation ldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9 Les localisations appelées “diskXX” se rapportent aux sous-répertoires slakware/XX de la distribution, d'autres peuvent se trouver dans le sous-répertoire contrib. Dans notre cas, nous pouvons maintenant télécharger les paquetages dont nous avons besoin en récupérant les fichiers suivants (à partir du répertoire racine de l'arborescence de la distribution Slackware) : slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs/tgz slakware/x9/xf_lib.tgz Extrayez les fichiers de ces archives compressées dans le répertoire /compat/linux (en ommettant ou en supprimant ensuite les fichiers dont vous n'avez pas besoin) et vous aurez tout ce qu'il vous faut. Consultez aussi : ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README et /usr/src/sys/i386/ibcs2/README.iBCS2 Comment installer Mathematica sous FreeBSD - Contribution de &a.rich; et &a.chuck; + Contribution de &a.rich; et Chuck Robey Ce document explique comment installer la distribution binaire Linux de Mathematica 2.2 sous FreeBSD 2.1. Mathematica supporte en natif Linux mais pas FreeBSD. Une fois donc que vous avez configuré votre système pour qu'il soit compatible Linux, vous avez à peu près tout ce qu'il vous faut pour utiliser Mathematica. Pour ceux qui ont déjà la version “étudiant&rdquo de Mathematica pour DOS, la mise à jour pour Linux coûtait, quand ce document a été rédigé, en Mars 1996, $45.00. Vous pouvez la commander directement à Wolfram au (217) 398-6500 et payer par carte de crédit. Décompacter la distribution de Mathematica Les binaires sont actuellement distribués par Wolfram sur CD-ROM. Il y a une douzaine de fichiers d'archive sur le CD-ROM, chacun contenant une distribution binaire pour une des architectures supportées. Celle pour Linux s'appelle LINUX.TAR. Vous pouvez, par exemple, la décompacter dans /usr/local/Mathematica : &prompt.root; cd /usr/local &prompt.root; mkdir Mathematica &prompt.root; cd Mathematica &prompt.root; tar -xvf /cdrom/LINUX.TAR Obtenir votre mot de passe pour Mathematica Avant de pouvoir utiliser Mathematica, vous devrez obtenir de Wolfram un mot de passe qui corresponde à l'“IDentifiant” de votre machine : Une fois que vous avez installé les bibliothèques pour la compatibilité Linux et décompacté Mathematica, vous pouvez connaître l'“IDentifiant” de votre machine en exécutant le programme mathinfo dans le répertoire d'installation : &prompt.root; cd /usr/local/Mathematica/Install &prompt.root; mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 Ici, par exemple, l'“IDentifiant” de la machine richc est 9845-03452-90255. Ne vous souciez pas du message à propos de l'ioctl qui n'est pas implémenté. Cela ne vous empèchera pas d'utiliser Mathematica, bien que vous aurez ce message toutes les fois que vous exécuterez Mathematica. Quand vous vous enregistrerez auprès de Wolfram, par courrier électronique, téléphone, ou fax, vous leur communiquerez l'“IDentifiant” de la machine et ils vous donneront en réponse le mot de passe correspondant qui consiste en groupes de chiffres. Vous devrez ajouter les deux, ainsi que le nom de la machine et le numéro de licence, dans votre fichier mathpass. Vous pouvez le faire en utilisant : &prompt.root; cd /usr/local/Mathematica/Install &prompt.root; math.install Il vous demandera votre numéro de licence et le mot de passe que Wolfram vous a fourni. Si vous vous trompez ou si pour une raison ou une autre math.install échoue, ce n'est pas un problème; vous pouvez simplement éditer le fichier mathpass, qui se trouve dans le même répertoire, pour corriger à la main ces informations. Après le mot de passe, math.install vous demandera si vous voulez utiliser la configuration d'installation par défaut ou si vous préférez définir la vôtre. Si vous êtes comme nous et n'avez pas confiance dans les programmes d'installation, vous voudrez certainement indiquer vous-même les répertoires d'installation. Attention. Bien que math.install vous demande les noms des répertoires, il ne les crée pas à votre place, vous devriez donc ouvrir une deuxième fenêtre pour le faire avant de donner leurs noms au programme d'installation. Ou, si vous échouez, vous pouvez créer les répertoires puis relancer le programme math.install. Nous avons choisi de créer au préalable et d'indiquer à math.install les répertoires suivants : /usr/local/Mathematica/bin pour les binaires /usr/local/Mathematica/man/man1 pour les pages de manuel /usr/local/Mathematica/lib/X11 pour le fichier XKeysymb Vous pouvez aussi lui dire d'utiliser /tmp/math.record comme fichier d'enregistrement système, dans lequel il conserve les traces des sessions. math.install continuera ensuite en décompactant la distribution et en mettant les fichiers là où il faut. La fonction calepin de Mathematica est fournie séparement, de même que l'interface X, et vous devez les installer à part. Pour que l'interface X soit correctement installée, allez dans le répertoire /usr/local/Mathematica/FrontEnd et exécutez la procédure xfe.install. Vous devrez lui dire où mettre les fichiers, mais vous n'aurez pas de répertoire à créer, parce qu'elle utilise les mêmes que ceux qui ont été créés pour math.install. Finalement, il doit y avoir une nouvelle procédure appelée mathematica dans le répertoire /usr/local/Mathematica/bin. Pour finir, vous devrez modifier chacune des procédures que Mathematica a installé pour y ajouter la ligne suivante : &prompt.user; XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB Cela pour dire à Mathematica où trouver sa propre version du fichier de correspondance clavier XKeysymDB, sinon vous aurez des messages d'erreur dus à des correspondances de touches manquantes. Sous 2.1-stable, vous devrez aussi ajouter la ligne suivante : &prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF pour dire à Mathematica d'utiliser la version Linux de host.conf. Ce fichier a une syntaxe différente de celui de FreeBSD, vous aurez donc un message d'erreur à propos de /etc/host.conf si vous oubliez cette modification. Vous voudrez peut-être aussi modifier votre fichier /etc/manpath.config pour lire le nouveau répertoire pour les pages de manuel, et aurez peut-être besoin d'éditer votre fichier ~/.cshrc pour ajouter /usr/local/Mathematica/bin à vos chemins d'accès par défaut. C'est à peu près tout. Vous devriez maintenant pouvoir taper mathematica et obtenir un calepin Mathematica vraiment “nickel”. Mathematica a inclu des interfaces utilisateurs Motif, mais elles sont liées statiquement, vous n'avez donc pas besoin des bibliothèques Motif. Bonne chance pour votre propre installation ! Bogues Il est connu que l'interface calepin se bloque parfois à la lecture de certains fichiers calepin avec des messages d'erreur du type : File .../Untitled-1.mb appears to be broken for OMPR.257.0 Nous n'en avons pas trouvé la raison, mais cela ne touche que l'interface calepin X, et non le moteur Mathematica lui-même. L'interface en ligne de commande invoquée par math n'est pas affectée par ce bogue. Remerciements Remerciements bien mérités à &a.sos; et &a.peter; qui ont fait de l'émulation Linux ce qu'elle est aujourd'hui, et à Michael Smith qui les a poussé au point qu'elle exécute les binaires Linux mieux que Linux lui-même ! :-) diff --git a/fr_FR.ISO8859-1/books/handbook/mail/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/mail/chapter.sgml index c6e37f3993..49724eb78f 100644 --- a/fr_FR.ISO8859-1/books/handbook/mail/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/mail/chapter.sgml @@ -1,653 +1,653 @@ Courrier électronique - Contribution de &a.wlloyd;. + Contribution de Bill Lloyd wlloyd@mpd.ca. &trans.a.haby; De nombreux ouvrages d'Administration Système traitent de la configuration du courrier électronique. Si vous envisagez de faire plus que configurer un seul serveur de courrier sur votre réseau, il vous faut de la documentation de qualité industrielle. Certaines parties de la configuration du courrier électronique sont confiées au Système de Noms de Domaines (DNS). Si vous gérez votre propre serveur DNS, consultez /etc/namedb et man -k named pour plus d'informations. Notions de base Voici les principaux programmes impliqués dans un échange de courrier électronique. Le “serveur de courrier” est responsable de l'expédition et de la réception du courrier pour votre machine, voire votre réseau. Le programme utilisateur C'est un programme comme elm, pine, mail, ou un outil plus sophistiqué tel un navigateur WWW. Ce programme transmet simplement toutes les transactions concernant le courrier électronique au “serveur de courrier” local, soit en invoquant sendmail, soit via TCP. Le “démon” serveur de courrier C'est habituellement sendmail ou smail, s'exécutant en tâche de fond. Vous le désactivez ou modifiez les options de sa ligne de commande dans le fichier /etc/rc.conf (ou, pour les versions antérieures à FreeBSD 2.2.2, /etc/sysconfig). Il vaut mieux le laisser actif, à moins que vous n'ayez une bonne raison de ne pas le faire tourner, par exemple, si vous configurez un coupe-feu. Vous devez savoir que sendmail est un maillon potentiellement faible sur un site sécurisé. Certaines versions de sendmail ont des trous de sécurité connus. sendmail accomplit deux tâches. Il se charge d'envoyer et de recevoir le courrier. Lorsque sendmail doit expédier du courrier depuis votre site, il consulte le DNS pour savoir quelle machine reçoit le courrier pour la destination voulue. S'il agit comme expéditeur, sendmail prendra le message dans la file d'attente locale et le délivrera via l'Internet à un autre sendmail sur la machine qui doit le recevoir. DNS - Système de Noms de Domaines Le système de noms de domaines (DNS), et son “démon” named, gèrent la base de données qui fait correspondre nom de machine et adresse IP, et nom de machine et serveur de courrier. L'adresse IP est définie par un enregistrement A. L'enregistrement MX définit le serveur qui recevra votre courrier. S'il n'y a pas d'enregistrement MX associé à votre machine, cette dernière recevra directement le courrier. A moins que vous n'ayez votre propre serveur DNS, vous ne pouvez pas modifier vous-même les informations du DNS. Si vous passez par un fournisseur d'accès Internet, voyez cela avec lui. Serveur POP Ce programme récupère le courrier dans votre boîte aux lettres et le transmet à votre navigateur. Si vous voulez faire tourner un serveur POP sur votre machine, vous devrez faire deux choses: Récupérez le logiciel POP du catalogue des logiciels portés, que vous trouverez dans le répertoire /usr/ports, ou du catalogue des logiciels précompilés. Ce manuel comprend une section qui décrit exhaustivement l'installation des logiciels portés. Modifiez /etc/inetd.conf pour lancer le serveur POP. Il y aura des instructions avec le serveur POP. Lisez-les. Configuration Les bases Avec votre système FreeBSD “prêt-à-l'emploi”[TM], vous devriez pouvoir envoyer du courrier électronique à l'extérieur, dès que vous aurez configuré /etc/resolv.conf ou si vous faites tourner un serveur DNS. Si vous voulez que votre courrier soit délivré à une machine particulière, il y a deux méthodes: Faire tourner un serveur DNS (man -k named) et avoir votre propre domaine, i.e.: petitemine.com. Faire en sorte que le courrier soit envoyé à l'adresse (nom de machine) DNS de votre machine, i.e.: refectoire6.maison.ecole.edu. Quelle que soit la méthode choisie, pour que le courrier soit directement délivré à votre machine, elle doit être référencée sur l'Internet. Vous devez avoir une adresse IP permanente. Donc pas de PPP dynamique. Si vous êtes derrière un coupe-feu, il faut qu'il vous passe le trafic SMTP (Simple Mail Transfer Protocol - protocole élémentaire de transport de courrier électronique). D'après /etc/services: smtp 25/tcp mail #Simple Mail Transfer Si vous voulez recevoir le courrier sur la machine elle-même, vous devez vous assurez que l'entrée MX du DNS pointe sur cette machine, ou qu'il n'y a pas d'entrée MX correspondant à son nom dans le DNS. Essayez: &prompt.root; hostname newbsdbox.freebsd.org &prompt.root; host newbsdbox.freebsd.org newbsdbox.freebsd.org has address 204.216.27.xx Si c'est la seule réponse que vous obtenez, le courrier adressé à root@newbsdbox.freebsd.org arrivera sans problème. Si au lieu de cela, vous obtenez: &prompt.root; host newbsdbox.freebsd.org newbsdbox.FreeBSD.org has address 204.216.27.xx newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.org Tout le courrier adressé directement à votre machine arrivera sur freefall, adressé au même utilisateur. Cette information est configurée par votre serveur de noms de domaines. C'est la machine définie comme serveur de noms primaire dans /etc/resolv.conf. L'enregistrement du DNS qui contient l'information de routage du courrier est l'entrée MX (Mail eXchange). S'il n'y a pas d'entrée MX, le courrier est envoyé directement à la machine en utilisant l'entrée Addresse. Voici ce que fut à l'occasion l'entrée MX pour freefall.freebsd.org:. freefall MX 30 mail.crl.net freefall MX 40 agora.rdrop.com freefall HINFO Pentium FreeBSD freefall MX 10 freefall.FreeBSD.org freefall MX 20 who.cdrom.com freefall A 204.216.27.xx freefall CNAME www.FreeBSD.org freefall a plusieurs entrées MX. Celle dont le numéro est le plus faible reçoit en définitive le courrier. Les autres le mettent temporairement dans leur file d'attente, si freefall est occupé ou hors-service. Les sites MX de secours doivent avoir une connexion séparée à l'Internet, pour être vraiment utiles. Un fournisseur d'accès ou un site amical peuvent vous fournir ce service. dig, nslookup, et host sont ici vos alliés. Courrier pour votre domaine (réseau). Pour configurer un serveur de courrier pour votre réseau, vous devez éviter que le courrier arrive à toutes vos stations de travail. En d'autres termes, vous devez détourner tout le courrier pour *.petitemine.com vers une seule machine, votre “serveur de courrier”. Dans la grande majorité des cas, les utilisateurs du réseau récupèreront leur courrier sur leurs stations de travail avec POP ou telnet. Il faut qu'il y ait un compte utilisateur avec le même nom sur les deux machines. Utilisez adduser pour ce faire. Si vous définissez /nonexistent comme interpréteur de commandes (sur le serveur de courrier), les utilisateurs ne pourront pas y ouvrir de session. Votre serveur de courrier sera défini comme Mail eXchange pour chaque station de travail. Cela doit être défini dans le DNS (i.e.: BIND, named). Reportez-vous s'il vous plaît à un ouvrage d'administration réseau pour avoir des informations détaillées. Vous devez essentiellement ajouter les lignes suivantes à la configuration de votre serveur DNS: pc24.petitemine.com A xxx.xxx.xxx.xxx ; Adresse IP de la station de travail MX 10 smtp.petitemine.com ; Serveur de courrier Vous ne pouvez le faire vous-même que si vous gérez un serveur de noms. Si vous ne voulez pas faire tourner un serveur de noms, trouvez quelqu'un, votre fournisseur d'accès Internet par exemple, pour le faire à votre place. Le courrier adressé à une station de travail sera envoyé à votre machine Mail eXchange. Quelle que soit la machine sur laquelle pointe l'enregistrement A, le courrier arrivera sur la machine MX. On peut utiliser cela pour implémenter un hébergement virtuel du courrier électronique. Exemple: J'ai un client qui a comme domaine foo.bar, et je veux que tout le courrier pour foo.bar arrive sur ma machine smtp.smalliap.com. Il faut configurer une entrée comme suit pour le serveur DNS: foo.bar MX 10 smtp.smalliap.com ; mon serveur de courrier Il n'y a pas besoin d'enregistrement A si l'on ne veut que le courrier pour le domaine. i.e.: ne vous attendez pas à ce que ping foo.bar fonctionne, à moins qu'il n'y ait aussi un enregistrement d'Addresse pour foo.bar. Sur la machine qui reçoit le courrier pour le distribuer dans une boîte aux lettres, il faut dire à sendmail pour quelle machine il accepte du courrier. Ajoutez pc24.petitemine.com à /etc/sendmail.cw (si vous utilisez FEATURE(use_cw_file)), ou ajoutez une ligne Cw myhost.smalliap.com à /etc/sendmail.cf. Si vous envisagez d'utiliser sérieusement sendmail, vous devriez installer les sources de sendmail. Ils sont accompagnés de beaucoup de documentation. Vous trouverez de l'information sur la façon d'obtenir le source de sendmail à la section Configurer UUCP. Configurer UUCP. Emprunté à la FAQ. La configuration de sendmail livrée avec FreeBSD convient à des sites directement connectés à l'Internet. Les sites qui veulent échanger du courrier par UUCP doivent installer un autre fichier de configuration de sendmail. Bidouiller /etc/sendmail.cf à la main est généralement considéré comme une occupation de puriste. La version 8 de sendmail s'accompagne d'une nouvelle manière de générer les fichiers de configuration avec le pré-processeur m4, grâce auquel le travail de configuration à la main se fait à un niveau d'abstraction plus élevé. Utilisez les fichiers de configuration du répertoire /usr/src/usr.sbin/sendmail/cf. Si vous n'avez pas installé la totalité du source sur votre système, les fichiers et outils de sendmail ont été scindés en plusieurs fichiers d'archive, pour plus de commodités. En supposant que vous ayez monté le CD-ROM, tapez: &prompt.root; cd /usr/src &prompt.root; tar -xvzf /cdrom/dists/src/ssmailcf.aa Pas de panique, il n'y a que quelques centaines de kilo-octets. Le fichier README du répertoire cf est une bonne introduction de base à la configuration avec m4. Pour le transfert par UUCP, le mieux est d'utiliser la fonctionnalité mailertable. Elle construit une base de données que sendmail peut utiliser pour prendre ses décisions de routage. Vous devez d'abord créer un fichier .mc. Le répertoire /usr/src/usr.sbin/sendmail/cf/cf contient ces fichiers. Jetez-y un coup d'oeil, il y a déjà quelques exemples. Supposons que vous ayez appelé votre fichier foo.mc, tout ce que vous avez à faire pour le convertir en un fichier sendmail.cf valide est: &prompt.root; cd /usr/src/usr.sbin/sendmail/cf/cf &prompt.root; make foo.cf Si vous n'avez pas de répertoire /usr/obj, alors: &prompt.root; cp foo.cf /etc/sendmail.cf Sinon: &prompt.root; cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cf Un fichier .mc typique ressemblerait à: include(`../m4/cf.m4') VERSIONID(`Votre numéro de version') OSTYPE(bsd4.4) FEATURE(nodns) FEATURE(nocanonify) FEATURE(mailertable) define(`UUCP_RELAY', votre.relais.uucp) define(`UUCP_MAX_SIZE', 200000) MAILER(local) MAILER(smtp) MAILER(uucp) Cw votre.alias.nom.machine Cw votrenomdenoeuduucp.UUCP Les fonctionnalités nodns et nocanonify évitent le recours au DNS pour délivrer le courrier. La clause UUCP_RELAY est nécessaire pour d'obscures raisons, ne me demandez pas lesquelles. Mettez-y simplement un nom de machine Internet qui soit capable de comprendre les adresses du pseudo-domaine .UUCP; vous y mettrez vraisemblablement le nom du relais de courrier électronique de votre fournisseur d'accès. Un fois que cela est fait, il vous faut le fichier appelé /etc/mailertable. De nouveau, un exemple typique de cette variété: # # makemap hash /etc/mailertable.db < /etc/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom:sax Comme vous pouvez le constater, c'est un exemple d'après nature. Les trois premières lignes prennent en charge les cas particuliers où le courrier adressé au domaine ne doit pas être expédié sur la route par défaut, mais à un voisin UUCP pour “raccourcir” le trajet. La ligne suivante gère le courrier sur le domaine local Ethernet, qui peut être délivré par SMTP. Pour finir, les voisins UUCP sont référencés avec la notation utilisant le pseudo-domaine .UUCP pour permettre la surcharge des règles par défaut uucp-voisin!destinataire. Il y a toujours un simple point (“.”) sur la dernière ligne, qui correspond à tout le reste, et permet l'expédition UUCP à un voisin UUCP qui vous sert de passerelle universelle pour le courrier au reste du monde. Tous les noms de noeuds après le mot-clé uucp-dom: doivent être des voisins UUCP valables, ce que vous pouvez contrôler avec uuname. Pour vous rappeler que ce fichier doit être converti en base de données DBM avant d'être utilisable, c'est une bonne idée de mettre la ligne de commande qui le fait en tête du fichier mailertable. Vous devez l'exécuter chaque fois que vous modifiez mailertable. Dernier point: si vous n'êtes pas sûr qu'une route donnée fonctionne, rappelez-vous l'option de sendmail. Elle lance sendmail en mode “test d'addresse”; entrez simplement 0, puis l'adresse dont vous voulez tester la route, la dernière ligne vous donnera l'agent de transport de courrier utilisé en interne, la machine destinatrice que vous avez donnée en paramètre, et l'adresse (éventuellement traduite). Vous quittez ce mode en tapant Ctrl-D. &prompt.user; sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 0 foo@interface-business.de rewrite: ruleset 0 input: foo @ interface-business . de … rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ interface-business . de FAQ Emprunts à la FAQ. Pourquoi faut-il que j'utilise les FQDN (“Fully Qualified Domain Name” - noms Internet complets) pour les machines de mon site? Vous vous rendrez probablement compte que la machine est en fait dans un domaine différent; par exemple, si vous êtes dans le domaine foo.bar.edu et que vous voulez atteindre la machine mumble du domaine bar.edu, vous devrez utiliser son nom de domaine complet, mumble.bar.edu, au lieu de mumble. C'était traditionnellement admis par les solveurs BIND BSD. Néanmoins, la version de BIND qui est maintenant livrée avec FreeBSD ne sait pas compléter les noms de domaines abrégés autrement qu'avec le nom de votre domaine. Donc le nom non qualifié mumble doit correspondre à mumble.foo.bar.edu, sans quoi il sera recherché dans le domaine racine. Cela diffère du comportement antérieur, où la recherche se prolongeait à mumble.bar.edu, puis mumble.edu. Consultez la RFC 1535 pour savoir pourquoi cela était considéré comme une manière incorrecte de faire, voire un trou de sécurité. Comme palliatif, vous pouvez mettre la ligne: search foo.bar.edu bar.edu à la place de: domain foo.bar.edu dans votre fichier /etc/resolv.conf. Assurez-vous cependant que la recherche ne franchit pas la “limite entre l'administration locale et publique” selon l'expression de la RFC 1535. Sendmail affiche le message d'erreur <errorname>mail loops back to myself</errorname> La réponse donnée dans la FAQ de Sendmail est la suivante: * J'ai des messages "Local configuration error", du style: 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error Comment puis-je résoudre ce problème? Vous avez demandé que le courrier pour un domaine (e.g., domain.net) soit transmis à une machine donnée (dans ce cas précis, relay.domain.net) avec un enregistrement MX, mais la machine relais ne se connaît pas elle-même comme domain.net. Ajoutez domain.net à /etc/sendmail.cw (si vous utilisez FEATURE(use_cw_file)) ou ajoutez "Cw domain.net" à /etc/sendmail.cf. La FAQ Sendmail se trouve dans /usr/src/usr.sbin/sendmail. Je vous en recommande la lecture si vous voulez “bidouiller” votre configuration du courrier électronique. Comment puis-je gèrer le courrier électronique avec une connexion téléphonique PPP? Vous voulez connecter une machine FreeBSD du réseau local à l'Internet. Cette machine servira de passerelle de courrier pour le réseau local. La connexion PPP n'est pas dédiée. Il y a au moins deux façons de faire. L'une d'elle est d'utiliser UUCP. Voici l'autre. Le point clé est d'obtenir d'un site Internet qu'il vous fournisse les services MX secondaires pour votre domaine. Par exemple: bigco.com. MX 10 bigco.com. MX 20 smalliap.com. Il doit y avoir une seule machine comme destinataire final (ajoutez Cw bigco.com au fichier /etc/sendmail.cf de bigco.com). Quand les sendmail expéditeurs essayeront de vous délivrer du courrier, ils essayerons de vous contacter via votre liaison modem. Ce qui échouera très probablement sur dépassement de délai puisque vous n'êtes pas en ligne. sendmail enverra automatiquement le courrier au site MX secondaire, i.e.: votre fournisseur d'accès. Celui-ci essayera toutes les 15 minutes (sendmail_flags = "-bd -q15m" dans /etc/rc.conf) de se connecter à votre machine pour expédier le courrier au site MX primaire. Vous pouvez utiliser quelque chose comme ceci comme procédure de connexion: #!/bin/sh # Mettez-moi dans /usr/local/bin/pppbigco ( sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct pppbigco Si vous définissez une procédure de connexion particulière pour un utilisateur, vous pouvez utiliser sendmail -qRbigco.com au lieu de la procédure ci-dessus. Cela forcera le traitement immédiat de tout le courrier dans la file d'attente pour bigco.com. On peut encore affiner comme suit la configuration: Message emprunté à la liste de diffusion freebsd-isp. > Nous fournissons un MX secondaire à un client. Le client se connecte > à notre service automatiquement plusieurs fois par jour pour acheminer > le courrier sur son MX primaire (nous n'appelons pas son site lorsque > du courrier lui arrive). Notre sendmail envoie le courrier de la file > d'attente toutes les demi-heures. Pour l'instant, il doit rester une > demi-heure en ligne pour être sûr que tout le courrier soit arrivé au > MX primaire. > > Y-a-t-il une commande qui permette de dire à sendmail d'envoyer > sur-le-champ tout le courrier? L'utilisateur n'a évidemment pas > les droits super-utilisateur sur la machine. Dans la section 'indicateurs de confidentialité' de sendmail.cf, il y a la définition : Opgoaway,restrictqrun Supprimer restrictqrun permet à d'autres utilisateurs que le super-utilisateur de lancer le traitement de la file d'attente. Vous pouvez aussi redéfinir les MXs. Nous sommes le premier MX pour les utilisateurs de ce type et nous avons défini: # Si nous sommes le meilleur MX pour une machine, essayer directement au lieu # d'émettre des messages d'erreur de configuration locale. OwTrue De cette façon, un site distant vous enverra le courrier, sans essayer de se connecter chez votre client. Vous le lui transmettez ensuite. Cela ne marche qu'avec "hosts", vous n'avez donc pas besoin que votre client appelle son serveur de courrier "client.com" ou "machine.client.com" dans le DNS. Mettez seulement un enregistrement A pour "client.com" dans le DNS. diff --git a/fr_FR.ISO8859-1/books/handbook/ports/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/ports/chapter.sgml index 461ba197cb..a4dc1e25f6 100644 --- a/fr_FR.ISO8859-1/books/handbook/ports/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/ports/chapter.sgml @@ -1,5197 +1,5197 @@ Installer des applications du “Catalogue des logiciels portés” - Contribution de &a.jraynard;. + Contribution de James Raynard. &trans.a.haby; Le catalogue des logiciels portés de FreeBSD vous permet de compiler et d'installer une grande variété d'applications avec un minimum d'efforts. Malgré toutes les déclarations exagérées sur les standards ouverts, faire fonctionner un programme sur différentes versions d'Unix peut en réalité être fastidieux et délicat, comme tous ceux qui ont essayé le savent. Vous aurez peut-être la chance d'arriver à compiler, installer où il faut et exécuter sans incident le programme que vous voulez “tel quel”, mais c'est malheureusement assez rare. Dans la plupart des cas, vous devrez vous creuser un peu la tête, et il y a un certain nombre de programmes qui vous donneront prématurement des cheveux blancs, ou même une calvitie chronique... Certaines distributions de logiciels ont résolu ce problème en fournissant des procédures de configuration. Certaines sont très sophistiquées, mais ont une fâcheuse tendance à vous annoncer triomphalement que votre système est d'une espèce dont vous n'avez jamais entendu parler et à vous poser un tas de questions qui ressemblent plus à un examen de programmation système Unix. (La fonction gethitlist de votre système vous rend-elle un pointeur const sur un schmilblick ou un pointeur sur un schmilblick const? Avez-vous la gestion des exceptions inconnues de style Foonix? Et sinon, pourquoi?) Heureusement, grâce au catalogue des logiciels portés, tout le travail pénible a déjà été fait, et il vous suffit de taper make install pour avoir un logiciel qui fonctionne. Pourquoi un catalogue des logiciels portés? Le système FreeBSD de base comporte une grande variété d'outils et d'utilitaires système, mais de nombreux logiciels d'usage courant n'en font pas partie, et il y a de bonnes raisons à cela: Il y a des programmes dont certains ne peuvent se passer et que d'autres ne peuvent pas voir en peinture, un certain éditeur basé sur Lisp, par exemple. Certains programmes sont trop spécialisés pour faire partie du système de base (Conception Assistée par Ordinateur, bases de données). Les programmes de la catégorie “Je devrais y jeter un coup d'oeil quand j'aurais cinq minutes”, et qui n'ont rien d'indispensable (certains langages, peut-être). Les programmes qui sont bien trop amusants pour être fournis avec un système d'exploitation sérieux comme FreeBSD ;-) Peut importe la quantité de programmes fournis de base, les gens en veulent toujours plus, et il faut définir une séparation quelque part (sans quoi les distributions de FreeBSD deviendraient absolument énormes). Il serait évidemment irréaliste d'attendre que chacun porte ses programmes favoris à la main (sans mentionner la quantité invraisemblable de travail refait à chaque fois), le Projet FreeBSD a donc mis en place une méthode ingénieuse d'utilisation d'outils standard pour automatiser le processus. C'est, au passage, une excellente illustration de la “manière Unix” de faire en combinant un jeu d'outils simples mais souples pour arriver à un mécanisme très puissant. Comment fonctionne le catalogue des logiciels portés? Les logiciels sont typiquement distribués sur l'Internet sous forme d'archives incluant un fichier Makefile, le code source du programme et habituellement quelques instructions (qui ne sont pas toujours aussi instructives qu'elles pourraient l'être), avec peut-être aussi une procédure de configuration. Le scénario standard consiste à télécharger l'archive par FTP, l'extraire quelque part, parcourir les instructions, faire les modifications qui vous paraissent nécessaires, lancer la procédure de configuration pour mettre tout au point et utiliser la commande make habituelle pour compiler et installer le programme à partir du source. Les logiciels portés de FreeBSD utilisent toujours le mécanisme des archives, mais se servent d'un squelette qui renferme la “connaissance” nécessaire pour pouvoir obtenir un logiciel utilisable sous FreeBSD, plutôt que d'attendre de l'utilisateur qu'il se débrouille. Ils comportent aussi leurs propres Makefiles, de sorte que presque tous les logiciels portés se compilent et s'installent de la même façon. Si vous regardez le squelette pour un logiciel porté (soit sur votre machine FreeBSD, soit sur le site FTP), et espérez y trouver toutes sortes de techniques d'avant-garde, vous serez déçu par les quelques fichiers et répertoires sans éclat que vous y verrez. (Nous parlerons bientôt de la façon de Se procurer un logiciel porté). Je vous entends d'ici: “Comment diable cela peut-il arriver à faire quoi que ce soit? Le code source n'y est même pas!” Ne craignez rien, aimable lecteur, tout va s'éclairer (espérons-le). Examinons ce qui se passe lorsque nous essayons d'installer un logiciel porté. J'ai choisi ElectricFence, un bon outil pour les développeurs, car son squelette est plus explicite que la plupart. Si vous essayez de le faire chez vous, vous devez être super-utilisateur. &prompt.root; cd /usr/ports/devel/ElectricFence &prompt.root; make install >> Checksum OK for ElectricFence-2.0.5.tar.gz. ===> Extracting for ElectricFence-2.0.5 ===> Patching for ElectricFence-2.0.5 ===> Applying FreeBSD patches for ElectricFence-2.0.5 ===> Configuring for ElectricFence-2.0.5 ===> Building for ElectricFence-2.0.5 [une tonne de résultats de compilation...] ===> Installing for ElectricFence-2.0.5 ===> Warning: your umask is "0002". If this is not desired, set it to an appropriate value and install this port again by ``make reinstall''. install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3 ===> Compressing manual pages for ElectricFence-2.0.5 ===> Registering installation for ElectricFence-2.0.5 Pour éviter la confusion, je n'ai pas donné les résultats de la compilation. Si vous avez essayé de votre côté, vous avez peut-être obtenu au début quelque chose du genre: &prompt.root; make install >> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/. Le programme make s'est rendu compte que vous n'aviez pas de copie locale du source et a essayé de le télécharger pour pouvoir continuer son travail. J'avais déjà le source, il n'a donc pas eu besoin d'aller le chercher. Continuons et voyons ce que le programme make a fait: Localiser l'archive du code source. Si elle n'est pas localement disponible, aller la chercher sur un site FTP. Lancer un test de la somme de contrôle sur le fichier d'archive pour s'assurer qu'il a bien été récupéré, et non accidentellement tronqué, téléchargé en mode ASCII, ou bombardé de neutrinos pendant le transfert. Extraire l'archive dans un répertoire temporaire. Appliquer les “patches” - mises à jour - nécessaires à la compilation et à l'exécution sous FreeBSD. Lancer les procédures de configuration nécessaires à la compilation et répondre correctement aux questions posées. (Finalement!) Compiler le code. Installer le programme exécutable et les autres fichiers qui vont avec, pages de manuel, etc. dans un sous-répertoire de /usr/local, où ils ne se mélangeront pas avec vos programmes système. Cela garantit aussi que tous les logiciels portés soient au même endroit, au lieu d'être éparpillés à droite et à gauche sur votre système. Enregistrez l'installation dans une base de données. Si vous ne voulez pas conserver le programme par la suite, vous pourrez le désinstaller proprement de votre système. Parcourez les résultats de make et voyez si vous retrouvez ces différentes étapes. Si vous n'étiez pas encore impressionné, vous devriez l'être maintenant! Se procurer un logiciel porté pour FreeBSD Il y a deux façons d'obtenir la version portée pour FreeBSD d'un logiciel. Il vous faut soit le CD-ROM FreeBSD, soit une connexion Internet. Compiler les logiciels portés depuis le CD-ROM Si vous avez répondu oui à la question “Do you want to link the ports collection to your CD-ROM?” - “Voulez-vous créer un lien symbolique sur le catalogue des logiciels portés du CD-ROM?” - pendant la configuration de l'installation de FreeBSD, le programme aura déjà effectué à votre place les étapes préliminaires. Sinon, vérifiez que le CD-ROM FreeBSD est bien dans le lecteur et monté sur, par exemple, /cdrom. puis tapez: &prompt.root; mkdir /usr/ports &prompt.root; cd /usr/ports &prompt.root; ln -s /cdrom/ports/distfiles distfiles pour que le mécanisme d'installation puisse trouver les archives (il s'attend à ce qu'elles soient dans le répertoire /usr/ports/distfiles, c'est la raison pour laquelle nous avons créé un lien symbolique du répertoire d'archive du CD-ROM sur ce répertoire). Supposons maintenant que nous voulions installer le programme gnats qui se trouve dans le répertoire des bases de données. Voici comment nous procéderions: &prompt.root; cd /usr/ports &prompt.root; mkdir databases &prompt.root; cp -R /cdrom/ports/databases/gnats databases &prompt.root; cd databases/gnats &prompt.root; make install Si vous utilisez sérieusement les bases de données et que vous voulez comparer toutes celles qui sont disponibles au catalogue, tapez: &prompt.root; cd /usr/ports &prompt.root; cp -R /cdrom/ports/databases . &prompt.root; cd databases &prompt.root; make install (oui, il y a vraiment un “.” à la fin de la commande cp, ce n'est pas une erreur. C'est une “Unixerie” qui veut dire: “le répertoire courant”) et le système d'installation des logiciels portés compilera et installera automatiquement tous les logiciels de base de données disponibles! Si cette méthode ne vous convient pas, voici une façon entièrement différente de faire: Créez une “arborescence de liens” vers le catalogue en vous servant de la commande lndir1 de la distribution de XFree86. Trouvez un endroit où vous avez de la place, créez-y un répertoire et placez-vous dans ce répertoire avec cd. Utilisez maintenant la commande lndir1 avec comme premier argument le chemin d'accès complet au répertoire ports du CD-ROM et un “.” (le répertoire courant) comme second argument. Quelque chose du genre: &prompt.root; lndir /cdrom/ports . Vous pouvez alors installer les logiciels portés directement à partir du CD-ROM en le faisant depuis l'arborescence de liens que vous venez de créer. Remarquez que les sources d'origine de certains logiciels ne peuvent être fournis sur le CD-ROM, pour des questions de licence. Dans ce cas, vous devrez vous reporter à la section Installer de logiciels portés via une connexion Internet. Installer des logiciels portés via une connexion Internet Si vous n'avez pas de CD-ROM, ou voulez être sûr d'avoir la toute dernière version d'un logiciel, vous devrez télécharger le squelette associé au logiciel porté. Cela peut paraître une combine pleine d'embûches, mais c'est en réalité très simple. Le secret est que le serveur FTP FreeBSD peut vous générer des archives à la volée. Voici comment cela fonctionne, avec toujours comme exemple le programme gnats du répertoire des bases de données (les textes entre crochets sont des commentaires. Ne le tapez pas si vous essayez cela de votre côté!): &prompt.root; cd /usr/ports &prompt.root; mkdir databases &prompt.root; cd databases &prompt.root; ftp ftp.freebsd.org [ouvrez une session en tant qu'utilisateur `ftp' et donnez votre adresse de courrier électronique quand on vous demande un mot de passe. N'oubliez pas d'utiliser le mode binaire (appelé aussi 'image')!] > cd /pub/FreeBSD/ports/databases > get gnats.tar [archive et récupère le squelette de gnats] > quit &prompt.root; tar xf gnats.tar [extrait le squelette de gnats] &prompt.root; cd gnats &prompt.root; make install [compile et installe gnats] Que se passe-t-il? Nous nous sommes connectés comme à l'ordinaire au serveur FTP et sommes allés dans son sous-répertoire des bases de données. Quand nous lui avons donné la commande get gnats.tar, le serveur FTP a créé une archive du répertoire gnats à notre usage. Nous avons alors extrait de cette archive le squelette pour gnats qu'elle contenait et sommes allés dans le répertoire gnats pour compiler et installer le logiciel. Comme nous l'avons expliqué plus haut, le processus d'installation s'est rendu compte que nous n'avions pas de copie locale des sources, en a téléchargé une avant de l'extraire, de la mettre à jour et de la compiler. Essayons maintenant quelque chose de plus ambitieux. Au lieu de récupérer un seul squelette, récupérons un sous-répertoire complet, par exemple, tous les squelettes pour les bases de données du catalogue des logiciels portés. La façon de procéder est quasi identique: &prompt.root; cd /usr/ports &prompt.root; ftp ftp.freebsd.org [ouvrez une session en tant qu'utilisateur `ftp' et donnez votre adresse de courrier électronique quand on vous demande un mot de passe. N'oubliez pas d'utiliser le mode binaire (appelé aussi 'image')!] > cd /pub/FreeBSD/ports > get databases.tar [archive et récupère les squelettes pour les bases de données] > quit &prompt.root; tar xf databases.tar [extrait les squelettes de toutes les bases de données] &prompt.root; cd databases &prompt.root; make install [compile et installe les logiciels de base de données portés] Avec une demi-douzaine de commandes élémentaires, nous disposons maintenant d'un éventail de logiciels de base de données sur notre machine FreeBSD. La seule différence avec l'installation d'un seul logiciel est que nous avons récupéré et compilé d'un seul coup tout un répertoire de programmes. Impressionnant, non? Si vous envisagez d'installer de nombreux logiciels portés, cela vaut probablement la peine de télécharger tous les répertoires du catalogue. Les squelettes Une bande de programmeurs compulsifs qui ont oublié de manger lors d'une tentative désespérée de respecter une échéance? Des choses désagréables hantant les sous-sols de FreeBSD? Non, un squelette est un environnement minimal qui contient tout ce qu'il faut pour que la magie des logiciels portés fonctionne. <filename>Makefile</filename> Le composant le plus important d'un squelette est le fichier Makefile. Il contient les divers ordres qui précisent comment le logiciel doit être compilé et installé. Voici le Makefile pour ElectricFence: # New ports collection makefile for: Electric Fence # Version required: 2.0.5 # Date created: 13 November 1997 # Whom: jraynard # # $Id$ # DISTNAME= ElectricFence-2.0.5 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_SUNSITE} MASTER_SITE_SUBDIR= devel/lang/c MAINTAINER= jraynard@freebsd.org MAN3= libefence.3 do-install: ${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib ${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3 .include <bsd.port.mk> Les lignes qui commencent par un “#” sont des commentaires à l'intention des lecteurs humains (comme dans la plupart des procédures Unix). DISTNAME donne le nom, sans extension, de l'archive. CATEGORIES indique de quel type de logiciel il s'agit. Dans le cas présent, c'est un outil pour les développeurs. MASTER_SITES est l'URL(s) du site FTP principal, d'où sera téléchargé l'archive, si elle n'est pas disponible sur la machine locale. C'est un site considéré comme fiable, normalement celui de la distribution officielle (dans la mesure où un logiciel peut être “officiellement” distribué sur l'Internet). MAINTAINER est l'adresse électronique de la personne responsable de la maintenance du squelette, qui intervient lorsque, par exemple, il sort une nouvelle version du programme. Sautons pour l'instant quelques lignes, la ligne .include <bsd.port.mk> indique que les autres directives et commandes nécessaires se trouvent dans le fichier générique bsd.port.mk. Comme ce sont les mêmes pour tous les logiciels portés, il n'y a pas de raison de les dupliquer à chaque fois, elles sont donc enregistrées dans un fichier standard. Ce n'est probablement pas l'endroit où expliquer en détail comment le Makefile fonctionne; il suffit de préciser que la ligne qui commence par MAN3 garantit que les pages de manuel d'ElectricFence seront compressées après installation, pour économiser votre précieux espace disque. Le logiciel d'origine ne définissait pas de cible install, les trois lignes qui commencent à do-install veillent à ce que les fichiers générés soient bien placés là où il faut. Le répertoire <filename>files</filename> Le fichier qui contient la somme de contrôle pour ce logiciel s'appelle md5, du nom de l'algorithme MD5 utilisé pour la calculer. Il se trouve dans un répertoire au nom quelque peu trompeur de files. Ce répertoire peut aussi contenir divers fichiers nécessaires au portage et qui n'ont pas de raison particulière d'être ailleurs. Le répertoire <filename>patches</filename> Ce répertoire contient les mises à niveau qu'il faut appliquer pour que tout fonctionne correctement sous FreeBSD. Le répertoire <filename>pkg</filename> Ce répertoire contient trois fichiers assez utiles: COMMENT - une description en une seule ligne du logiciel. DESCR - une description plus détaillée. PLIST - la liste de tous les fichiers qui seront créés quand le logiciel sera installé. Que faire quand un portage échoue? Oh. Il y a quatre (4) choses que vous pouvez faire : Corriger le problème vous-même. Vous trouverez des détails techniques sur le mécanisme des portages à la section Faire vous-même un portage. Rouspéter. Cela ne se fait que par courrrier électronique! adressez-vous à la &a.ports; et précisez s'il vous plaît le nom et la version du logiciel, sur quel site vous avez récupéré le squelette et l'(les) archive(s) et quel message d'erreur vous obtenez. Faire une croix dessus. C'est la méthode la plus facile pour la plupart des gens - il y a bien peu de programmes du catalogue qui soient vraiment essentiels! Récupérer la version précompilée sur un serveur ftp. Le catalogue de référence des logiciels précompilés se trouve sur le serveur FTP de FreeBSD dans le répertoire des logiciels précompilés, bien que nous souhaiterions s'il vous plaît que vous consultiez d'abord vos sites miroirs locaux! Il y a globalement plus de chances que cela marche, que lorsque vous essayez de les compiler d'après les sources, et cela va de plus beaucoup plus vite. Servez-vous du programme pkg_add1 pour installer le fichier contenant un logiciel précompilé sur votre système. Quelques questions et leurs réponses Q. Je pensais que cela allait être une discussion sur les modems??! R. Ah. Vous pensiez peut-être aux “ports” série sur la face arrière de votre ordinateur. Nous utilisons ici le terme “port” - logiciels portés - pour parler du résultat du “portage” d'un logiciel d'une version d'Unix à une autre. (Les informaticiens ont la fâcheuse habitude d'employer le même mot pour parler de choses différentes.) Q. Je pensais qu'il fallait utiliser des “paquetages” pour installer des logiciels supplémentaires. R. Oui, c'est habituellement la façon la plus rapide et la plus facile de le faire. Q. Pourquoi alors se préoccuper de logiciels portés? R. Il y a plusieurs raisons: Les licences de certains logiciels stipulent qu'ils doivent être distribués sous forme de sources et non de binaires. Certains ne font pas confiance aux distributions sous forme binaire. Avec le code source, vous pouvez au moins (en théorie) le lire pour y repérer d'éventuels problèmes. Si vous avez des corrections/évolutions qui vous sont propres, vous avez besoin des sources pour les appliquer. Vous pouvez vouloir compiler le programme avec des options différentes de celles qu'a utilisées la personne qui a construit le “paquetage” - certains ont des opinions bien arrêtées sur la manière dont il faut optimiser, sur le fait qu'il faut ou non disposer de versions débogables et y inclure ou non les symboles, etc. Certains aiment disposer du code source, pour pouvoir le lire en cas de problème, le modifier, en emprunter des morceaux (si la licence le permet, bien sûr!), et ainsi de suite. Si vous n'avez pas le source, ce n'est pas du logiciel! ;-) Q. Qu'est-ce qu'un “patch” - mise à jour? R. Un “patch” est (habituellement) un petit fichier qui précise comment passer d'une version à une autre. Il contient du texte qui dit, par exemple, des choses comme “effacez la ligne 23”, “ajoutez ces deux lignes après la ligne 468” ou “modifiez comme suit la ligne 197”. On appelle aussi cela un “diff” parce qu'il est généré avec un programme du même nom. Q. Que sont les archives? R. C'est un fichier d'extension .tar ou .tar.gz (avec des variantes du style .tar.Z, ou même .tgz si vous voulez utiliser ces noms de fichiers avec un systèmes de fichiers DOS). C'est essentiellement une arborescence de répertoires qui a été archivée en un seul fichier (.tar) et éventuellement compressé (.gz). Cette technique était à l'origine utilisée pour les “Tape” - bande - “ARchives” (d'où le nom tar), mais c'est une méthode très utilisée pour distribuer du code source sur l'Internet. Vous pouvez avoir la liste des fichiers qu'elles contiennent, ou même les extraire vous-même, avec le programme Unix standard tar, qui fait partie du système FreeBSD de base, comme ceci: &prompt.user; tar tvzf foobar.tar.gz # connaître le contenu de foobar.tar.gz &prompt.user; tar xzvf foobar.tar.gz # extraire le contenu de foobar.tgz dans le répertoire courant &prompt.user; tar tvf foobar.tar # connaître le contenu de foobar.tar &prompt.user; tar xvf foobar.tar # extraire le contenu de foobar.tar dans le répertoire courant Q. Et une somme de contrôle? R. C'est un nombre calculé en additionnant tout ce que contient le fichier. Si un caractère change, la somme de contrôle n'est plus la même, et une simple comparaison vous permettra de repérer la différence. (En pratique, le calcul est un peu plus compliqué pour pouvoir repérer des problèmes comme les permutations de caractères, ce que ne permettrait pas une simple addition.) Q. J'ai suivi vos indications au paragraphe Compiler les logiciels portés depuis le CD-ROM et ça a marché sans problème jusqu'à ce que j'essaie d'installer kermit &prompt.root; make install >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/. Pourquoi ne le trouve-t-il pas? Ai-je un CD-ROM endommagé? R. La licence de kermit ne nous permet pas d'inclure l'archive sur le CD-ROM, vous devrez donc la récupérez vous-même - désolé! Vous avez tous ces messages d'erreur parce que vous n'étiez pas alors connecté à l'Internet. Une fois que vous l'avez téléchargé à partir de l'un des sites mentionnés, vous pouvez recommencer l'installation (essayez et choisissez le site le plus proche, pour économiser votre temps et de la bande passante); Q. Je l'ai fait, mais quand j'ai essayé de la mettre dans /usr/ports/distfiles, j'ai eu des erreurs à propos de permissions que je n'avais pas. R. Le mécanisme des logiciels portés cherche les archives dans /usr/ports/distfiles, mais il ne peut rien y copier parce que c'est un lien symbolique sur le CD-ROM, sur lequel on ne peut que lire. Vous pouvez lui dire de chercher ailleurs avec: &prompt.root; make DISTDIR=/where/you/put/it install Q. Le système des logiciels portés ne fonctionne-t-il qu'avec /usr/ports? Mon administrateur système veut que je mette tout dans /u/people/guests/wurzburger, mais cela ne marche apparemment pas. R. Vous pouvez utiliser les variables PORTSDIR et PREFIX pour dire au mécanisme des logiciels portés de travailler dans d'autres répertoires. Par exemple: &prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports install compilera le logiciel dans /u/people/guests/wurzburger/ports et l'installera dans /usr/local. &prompt.root; make PREFIX=/u/people/guests/wurzburger/local install le compilera dans /usr/ports et l'installera dans /u/people/guests/wurzburger/local. Et bien sûr: &prompt.root; make PORTSDIR=.../ports PREFIX=.../local install combinera les deux (c'est trop long pour tenir entièrement sur la page, mais je suis sûr que vous avez compris le principe). Si vous ne voulez pas avoir à retaper tout cela à chaque fois que vous installez un logiciel (et pour être honnête, pourquoi le feriez-vous?), c'est une bonne idée de définir ces deux variables dans votre environnement par défaut. Q. Je n'ai pas le CD-ROM FreeBSD, mais je voudrais avoir les archives sous la main sur mon système pour ne pas avoir à attendre la fin du téléchargement chaque fois que j'installe un logiciel. y-a-t-il une façon simple de tout récupérer d'un coup? R. Pour récupérer toutes les archives du catalogue des logiciels portés, tapez: &prompt.root; cd /usr/ports &prompt.root; make fetch Pour avoir toutes les archives d'un seul sous-répertoire, utilisez: &prompt.root; cd /usr/ports/directory &prompt.root; make fetch et pour un seul port - bon, je suppose que vous avez déjà deviné. Q. Je sais qu'il est probablement plus rapide de récupérer les archives de sites miroir FreeBSD proches. Y'a-t-il un moyen de dire au mécanisme de s'adresser à d'autres serveurs que ceux listés dans les MASTER_SITES? R. Oui. Si vous savez que, par exemple, ftp.FreeBSD.ORG est plus près que les sites listés dans MASTER_SITES, faites comme dans l'exemple suivant: &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch Q. Je veux savoir de quels fichiers j'aurai besoin, avant d'essayer de les télécharger. R. make fetch-list affichera la liste des fichiers nécessaires pour installer un logiciel porté. Q. Y-a-t il un moyen de faire en sorte que le logiciel ne soit pas compilé. Je veux modifier les sources avant de le compiler et c'est fastidieux de surveiller ce qui ce passe à chaque fois et de toujours taper Ctrl-C. R. make extract ne fait que récupérer et extraire le code source. Q. J'essaie de faire mon propre portage, et voudrais qu'il ne soit pas compilé avant que j'ai pu vérifier que les mises à jour aient été correctement appliquées. Y-a-t-il un équivalent de make extract, pour les mises à jour? A. Oui, make patch est ce qu'il vous faut. Vous trouverez peut-être aussi utile l'option . Et, au passage, merci de vos efforts! Q. J'ai entendu dire que certaines options du compilateur posait des problèmes. Est-ce exact? Comment puis-je être sûr que je compile les logiciels avec les bonnes options? R. Oui, avec la version 2.6.3 de gcc (la version livrée avec FreeBSD 2.1.0 et 2.1.5), l'option pouvait générer du code bogué, à moins que vous n'utilisiez en même temps l'option . (La plupart des logiciels portés n'utilisent pas l'option ). Vous devriez pouvoir préciser au compilateur les options à utiliser avec quelque chose comme: &prompt.root; make CFLAGS='-O2 -fno-strength-reduce' install ou en éditant /etc/make.conf, mais tous les logiciels portés n'en tiennent malheureusement pas compte. Le plus sûr est d'utiliser make configure, puis d'aller dans le répertoire des sources et de regarder ce que font les Makefiles, mais cela peut devenir fastidieux s'il y a de nombreux sous-répertoires avec chacun leurs Makefiles. Q. Il y a tellement de logiciels portés qu'il est difficile de trouver celui que je veux. Y-a-t-il quelque part une liste des logiciels portés? R. Regardez dans le fichier INDEX du répertoire /usr/ports. Q. J'ai installé le logiciel foo mais le mécanisme s'est soudainement interrompu et a commencé à compiler le logiciel bar. Que se passe-t-il? R. Le logiciel foo a besoin de quelque chose qui fait partie de bar - par exemple, si foo utilise des graphiques, bar peut comporter une bibliothèque avec des sous-programmes graphiques utiles. Ou bien bar est un outil nécessaire à la compilation du logiciel foo. Q. J'ai installé le logiciel grizzle du catalogue et c'est franchement du gaspillage d'espace disque. Je veux le supprimer mais je ne sais pas où il a mis tous les fichiers. Des indications? R. Pas de problème, tapez simplement: &prompt.root; pkg_delete grizzle-6.5 Q. Une minute, il faut connaître le numéro de version pour utiliser cette commande. Vous ne vous attendez sérieusement pas à ce que je l'ai retenu, n'est-ce pas? R. Absolument pas, vous pouvez le trouver en tapant: &prompt.root; pkg_info -a | grep grizzle Information for grizzle-6.5: grizzle-6.5 - La méthode de piano, l'interpréteur LOGO et le casse-briques tout en un. Q. A propos d'espace disque, le catalogue des logiciels portés occupe apparemment énormément de place. Est-il possible d'y faire du ménage? R. Oui, si vous avez installé un programme et êtes à peu près certain que vous n'aurez plus besoin des sources, il est inutile de les garder. La meilleure façon de faire est: &prompt.root; cd /usr/ports &prompt.root; make clean qui parcourera tous les sous-répertoires et supprimera tout ce qui se rapporte aux logiciels sauf les squelettes. Q. J'ai essayé, mais il reste toujours toutes ces archives, quelque soit le nom que vous leur donniez, dans le répertoire distfiles. Puis-je aussi les effacer? R. Oui, si vous êtes sûr d'en avez terminé avec elles, vous pouvez aussi les supprimer. Q. J'aime avoir quantité de logiciels pour les tester? Y-a-t-il un moyen de tous les installer d'un seul coup? R. Tapez simplement: &prompt.root; cd /usr/ports &prompt.root; make install Q. OK, j'ai essayé, mais comme je pensais que cela allait prendre beaucoup de temps, j'ai laissé la machine telle quelle et je suis allé me coucher. Ce matin, quand j'ai jeté une coup d'oeil à l'ordinateur, je n'avais que trois logiciels et demi installés. Quelque chose s'est-il mal passé? R. Non, le problème est que certains logiciels ont des questions à vous poser auxquelles ils ne peuvent répondre à votre place (par exemple, “Voulez-vous imprimer au format A4 ou au format légal US?”) et il faut donc que quelqu'un y réponde sur le moment. Q. Je ne veux pas passer toute la journée planté devant l'écran. Une meilleure idée? A. OK, avant d'aller au lit/travail/jardin public, tapez: &prompt.root cd /usr/ports &prompt.root; make -DBATCH install Cela installera tous les logiciels sans interaction avec l'utilisateur. A votre retour, tapez: &prompt.root; cd /usr/ports &prompt.root; make -DIS_INTERACTIVE install Pour terminer les installations. Q. Au bureau, nous utilisons frobble, qui fait partie de votre catalogue des logiciels portés, mais nous l'avons un peu modifié pour nos besoins propres. Y-a-t-il un moyen de faire notre propre “paquetage” pour le distribuer plus facilement sur nos sites? R. Pas de problème, si vous savez comment générer les “patches” pour vos modifications: &prompt.root; cd /usr/ports/somewhere/frobble &prompt.root; make extract &prompt.root; cd work/frobble-2.8 [Appliquer vos mises à jour] &prompt.root; cd ../.. &prompt.root; make package Q. Ce système des logiciels portés est vraiment génial. Je désespère de comprendre comment vous avez fait. Quel est votre secret? R. Il n'y a absolument pas de secret, jetez juste un coup d'oeil aux fichiers bsd.ports.mk et bsd.ports.subdir.mk du répertoire des makefiles. Cette lecture est déconseillée à ceux que les procédures de commandes compliquées rebutent...) ** Faire vous-même un portage Contribution de &a.jkh;, &a.gpalmer;, &a.asami; &a.obrien; et &a.hoek;. 28 Août 1996. Donc, vous voulez faire vous-même votre propre portage? Génial! Voici quelques indications sur la façon de créer un nouveau portage d'un logiciel pour FreeBSD. L'essentiel du travail est fait par /usr/share/mk/bsd.port.mk, qui est inclus dans le Makefile de chaque logiciel porté. Reportez-vous s'il vous plaît à ce fichier pour avoir plus de détails sur le fonctionnement interne du catalogue des logiciels portés. Même si vous n'écrivez pas tous les jours des Makefiles, il est pas mal commenté, et vous en apprendrez malgré tout beaucoup de choses. Seule une partie des variables surchargeables (VAR) est décrite dans ce document. La plupart (sinon toutes) sont explicitées au début de bsd.port.mk. Ce fichier utilise des tabulations non standard. Emacs et Vim devraient reconnaître cette configuration au chargement du fichier. vi ou ex peuvent être configurés avec la valeur adéquate après avoir chargé le fichier en tapant :set tabstop=4. Portage rapide Cette section vous explique comment faire un portage rapide. La plupart du temps, ce n'est pas suffisant, mais nous verrons cela par la suite. Commencez par récupérer le fichier d'archive d'origine et mettez-le dans DISTDIR, par défaut c'est le répertoire /usr/ports/distfiles. Nous supposerons dans ce qui suit que le source a compilé “tel quel”, i.e., il n'y a absolument pas eu de modification à y apporter pour qu'il tourne sur votre machine FreeBSD. Si vous avez dû changer quelque chose, vous devrez aussi vous reporter à la section suivante. Ecrire le <filename>Makefile</filename> Le Makefile minimal ressemblera à ceci : # Nouveau makefile du catalogue pour: oneko # Version correspondante: 1.1b # Date de création: 5 Décembre 1994 # Par: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk> Voyez si vous y comprenez quelque chose. Ne vous occupez pas de la ligne $Id$, elle sera automatiquement renseignée par CVS quand le logiciel sera importé dans notre arborescence principale des logiciels portés. Vous trouverez un exemple plus détaillé à la section Exemple de Makefile. Créer les fichiers de description Il y a trois fichiers de description indispensables à chaque logiciel porté, qu'il soit ou non précompilé. Ce sont les fichiers COMMENT, DESCR et PLIST, du sous-répertoire pkg. <filename>COMMENT</filename> C'est une description en une seule ligne du logiciel. S'il vous plaît, n'incluez pas le nom du logiciel (ni son numéro de version) dans le commentaire. Voici un exemple : Un chat poursuit une souris à travers l'écran. <filename>DESCR</filename> C'est une description plus longue du logiciel. Un à quelques paragraphes, expliquant succintement ce qu'il fait, suffisent. Ce n'est pas un manuel, ni une description détaillée de la manière de compiler et d'utiliser le logiciel. Faites s'il vous plaît attention si vous la recopiez du README ou des pages de manuel; trop souvent, ce ne sont pas des descriptions concises et elles sont mal formatées (e.g., les pages de manuel sont justifiées avec des espaces). S'il y a une page Web officielle pour le logiciel, vous devriez la mentionner ici. Il vous est recommandé de signer en fin de fichier, comme suit: C'est le portage de “oneko”, le chat qui poursuit la pauvre souris sur tout l'écran.  : (etc.) http://www.oneko.org/ - Satoshi asami@cs.berkeley.edu <filename>PLIST</filename> C'est la liste de tous les fichiers installés pour ce logiciel. On l'appelle aussi “liste de paquetage” parce que le “paquetage” sera généré en archivant tous les fichiers de cette liste. Les chemins d'accès sont relatifs à /usr/local ou /usr/X11R6). Si vous utilisez des variables MANn (comme vous devriez le faire), n'y listez pas les pages de manuel. Voici un court exemple: bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko Reportez-vous aux pages de manuel de pkg_create1 pour plus de détails sur la “liste de paquetage”. Vous devez lister tous les fichiers, mais pas les noms des répertoires. Par contre, s'il y a des répertoires créés à l'installation, veillez à ajouter les lignes @dirrm nécessaires pour qu'ils soient détruits si le logiciel est désinstallé. Il est recommandé de lister les fichiers dans l'ordre alphabétique. Cela facilite beaucoup les contrôles lors des mises à jour. Créer le fichier pour la somme de contrôle Tapez simplement make makesum. Les règles de construction des logiciels portés génèreront automatiquement le fichier files/md5. Tester le portage Vous devez vérifiez que les règles de construction du logiciel porté font exactement ce que vous voulez. Voici les points importants à contrôler: PLIST ne contient rien d'autre que ce qu'installe votre logiciel. PLIST contient tout ce qu'installe votre logiciel. Le logiciel peut être installé plusieurs fois de suite en utilisant la cible reinstall. Le mécanisme de portage du logiciel fait le ménage lors de la désinstallation. Ordre de test recommandé make install make package make deinstall pkg_add `make nom_du_paquetage` make deinstall make reinstall make package Vérifiez qu'il n'y a aucun message d'avertissement aux étapes package et deinstall. Après l'étape 3, vérifiez que tous les répertoires créés ont bien été détruits. Essayez aussi d'utilisez le logiciel après l'étape 4, pour vous assurer qu'il fonctionne correctement après installation sous forme de “paquetage”. Vérifier votre portage avec <command>portlint</command> Utilisez s'il vous plaît la commande portlint pour contrôler que votre portage se conforme à nos recommandations. Le programme portlint fait partie du catalogue des logiciels portés. En particulier, vous devriez vérifier que votre Makefile est bien construit et que le nom du paquetage est correct. Soumettre le portage Veillez d'abord à lire la section A faire et à ne pas faire. Maintenant que vous êtes satisfait de votre portage, la seule chose qui reste à faire est de le mettre dans l'arborescence principale des logiciels portés de FreeBSD de façon à ce que tout le monde en profite. Nous n'avons pas besoin de votre répertoire work ni de votre fichier nom_du_paquetage.tgz, effacez-les donc maintenant. Incluez simplement ensuite le résultat de la commande shar `find répertoire_portage` dans un rapport de bogue et envoyez-le nous avec le programme send-pr 1 . (Voyez Rapports de bogues et commentaires généraux pour plus d'informations sur send-pr 1 .) Si le logiciel porté non compressé fait plus de 20KB, vous devrez en faire une archive compressée et utiliser uuencode 1 avant de l'inclure dans le rapport (les archives “tar” “uuencodées” sont admises même si le rapport de bogue fait moins de 20KB, quoique non souhaitées dans ce cas). Veillez à classer le rapport dans la catégorie ports - “portages” et la classe change-request - “demande de modification”. (Ne classez pas le rapport confidential - “confidentiel” !) Encore une fois, n'incluez pas la distribution originale du source, le répertoire work ni le “paquetage” construit avec make package. Dans le passé, nous demandions que les soumissions de logiciels portés passent par notre site ftp (ftp.freebsd.org). Ce n'est plus souhaitable parce que l'accès en lecture est interdit sur le répertoire incoming/ de ce site du fait de la trop grande quantité de logiciels piratés qui y atterrissaient. Nous regarderons votre portage, vous contacterons si nécessaire, et le mettrons dans l'arborescence. Votre nom apparaîtra aussi dans la liste des “Autres collaborateurs de FreeBSD” du manuel FreeBSD et dans d'autres fichiers. Génial, non?!? :) Portage évolué Bon, ce n'était en fait pas si simple, et il a fallu modifier le code pour que le portage fonctionne. Dans cette section, nous allons expliquer, étape par étape, comment faire dans ce cas pour appliquer le paradigme des logiciels portés. Comment les choses fonctionnent Pour commencer, voici ce qui se passe lorsque l'utilisateur tape make dans le répertoire de votre logiciel porté. Ouvrir le fichier bsd.port.mk dans une autre fenêtre pendant que vous lisez ceci vous en facilitera la compréhension. Ne vous inquiétez pas si vous ne comprenez pas complètement ce que fait bsd.port.mk, peu de gens y arrivent... :> La cible fetch est exécutée. La cible fetch est chargée de faire en sorte que l'archive soit localement disponible dans DISTDIR. Si fetch ne trouve pas les fichiers dans DISTDIR, elle regardera à l'URL MASTER_SITES, définie dans le Makefile, et sur notre site ftp principal dans ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/ où nous avons mis les archives validées, à titre de copie de secours. Elle essayera alors de rapatrier le fichier de la distribution avec FETCH, en présumant que la machine qui fait la demande a un accès direct à l'Internet. En cas de succès, le fichier est sauvegardé dans DISTDIR pour la suite, et le traitement peut continuer. La cible extract est ensuite exécutée. Elle cherche le fichier de distribution de votre portage (typiquement une archive créée par tar et compressée avec gzip) dans DISTDIR et en extrait le contenu dans un sous-répertoire temporaire défini par WRKDIR (par défaut work). La cible suivante est patch. Dans un premier temps, tous les fichiers de mise à jour définis dans PATCHFILES sont appliqués. Ensuite, s'il y a des fichiers de mise à jour dans PATCHDIR (le sous-répertoire patches par défaut), ils sont appliqués, dans l'ordre alphabétique cette fois-ci. Vient ensuite configure qui peut faire l'une des opérations suivantes: Si elle existe, exécuter la procédure scripts/configure. Si HAS_CONFIGURE ou GNU_CONFIGURE est définie, exécuter WRKSRC/configure. Si USE_IMAKE est définie, exécuter XMKMF (par défaut: xmkmf -a). La dernière cible est build. Elle passe dans le sous-répertoire de travail du portage (WRKSRC) et se charge de la compilation. Si la variable USE_GMAKE est définie, la commande make GNU est utilisée, sinon c'est la commande make du système qui est employée. Ce sont les opérations par défaut. Vous pouvez en plus définir des cibles pre-quelque_chose ou post-quelque_chose, ou mettre des procédures du même nom dans le sous-répertoire scripts, et elles précéderont ou suivront les opérations par défaut. Par exemple, si vous avez défini une cible post-extract dans votre Makefile, et créé un fichier pre-build dans le sous-répertoire scripts, la cible post-extract sera invoquée après l'opération habituelle d'extraction et la procédure pre-build exécutée avant d'appliquer les règles de compilation par défaut. Il est recommandé d'utiliser des cibles dans le Makefile si les actions sont suffisamment élémentaires, car il est alors plus facile à quelqu'un d'autre de voir quelles sont les opérations supplémentaires effectuées lors du portage. Les opérations par défaut sont prises en charge par les cibles do-quelque_chose du fichier bsd.port.mk. Par exemple, les commandes d'extraction sont définies par la cible do-extract. Si la cible par défaut ne vous convient pas, vous pouvez rédefinir do-quelque_chose dans votre Makefile. Les cibles “principales” (e.g., extract, configure, etc.) ne font rien d'autre que de s'assurer que les étapes qui les précèdent se sont bien déroulées et appellent les vrais cibles ou procédures. Elles ne doivent donc pas être modifiées. Si vous voulez changer la méthode d'extraction, redéfinissez do-extract, mais ne modifiez pas extract ! Maintenant que vous avez compris ce qui se passe quand l'utilisateur tape make, passons en revue les étapes conseillées pour créer le portage parfait. Obtenez les sources d'origine Récupérez les sources d'origine (normalement) sous forme d'archive compressée (foo.tar.gz ou foo.tar.Z) et copiez-les dans DISTDIR. Utilisez toujours des sources de première main si vous le pouvez. Si vous ne trouvez pas de site ftp/http correctement accessible sur le réseau, ou ne trouvez que des sites qui utilisent des formats non standard, vous voudrez peut-être mettre une copie sur un serveur ftp ou http fiable que vous contrôlez (e.g., votre page personnelle). Veillez à définir MASTER_SITES pour refléter ce choix. Si vous ne trouvez aucun endroit adéquat et fiable où mettre la distribution (si vous y êtes autorisé, vous pouvez la mettre dans votre sous-répertoire public_html/ sur freefall), nous pouvons en dernier ressort “l'accueillir” nous-même en la mettant dans ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/. Définissez cette adresse dans MASTER_SITE_LOCAL. Adressez un courrier électronique à la &a.ports;, si vous n'êtes pas sûr de ce qu'il faut faire. Si la distribution est fréquemment modifiée sans raison valable, envisagez de la recopier sur votre page personnelle et listez-la en premier dans MASTER_SITES. Cela évitera que les utilisateurs aient des erreurs “checksum mismatch” sur les sommes de contrôle, et réduira aussi le travail des personnes chargées de maintenir notre site ftp. D'autre part, s'il n'y a qu'un seul site pour le logiciel d'origine, il est recommandé que vous ayez une sauvegarde sur votre site et qu'elle soit mentionnée en second lieu dans MASTER_SITES. S'il faut d'autres “patches” disponibles sur l'Internet pour ce portage, récupérez-les aussi et mettez-les dans DISTDIR. Ce n'est pas un problème s'ils proviennent d'autres sites que la distribution de base, nous pouvons gérer cette situation (voyez plus bas la description de PATCHFILES). Modifier les sources Extrayez le contenu de l'archive dans un sous-répertoire privé et faites-y les modifications nécessaires pour que le logiciel compile correctement avec la version courante de FreeBSD. Gardez avec soin trace de tout ce que vous faites, car vous allez bientôt automatiser ces opérations. Tout, y compris suppressions, ajouts et modifications de fichiers doit pouvoir être fait par des procédures ou fichiers de mise à jour une fois que vous aurez terminé le portage. Si le portage demande l'intervention ou des choix de l'utilisateur à la compilation ou à l'installation, vous devriez jeter un oeil aux procédures classiques Configure de Larry Wall, et peut-être faire quelque chose du même genre. L'objectif du nouveau catalogue des logiciels portés est que chaque logiciel soit aussi “prêt-a-l'emploi” que possible pour l'utilisateur final, tout en utilisant le minimum d'espace disque. Sauf si vous le précisez explicitement, tous les fichiers de mise à jour, procédures et fichiers que vous aurez créés et introduits comme contribution au catalogue des logiciels portés sont supposés couverts par les conditions standard de copyright BSD. Modifications Les fichiers ajoutés ou modifiés pendant la mise au point du portage peuvent être identifiés avec un diff récursif pour générer ensuite les fichiers de mise à jour - patches. Chaque ensemble de mise à jour que vous souhaitez appliquer doit être rassemblé dans un fichier patch-xx, où xx correspond au rang de cette mise à jour dans la séquence d'application de ces modifications - elles sont traitées en ordre alphabétique, donc aa d'abord, ab en second et ainsi de suite. Ces fichiers doivent être placés dans PATCHDIR, d'où ils seront automatiquement appliqués. Toutes les modifications doivent être relatives à WRKSRC (c'est habituellement le répertoire où l'archive s'extrait elle-même, et où se fera la compilation). Pour simplifier les corrections et les mises à niveau, vous devriez éviter d'avoir plus d'un fichier de mise à jour s'appliquant au même fichier source (e.g., patch-aa et patch-ab modifiant tous deux WRKSRC/foobar.c). Configuration Ajoutez toutes les autres commandes de mise au point à votre procédure configure et enregistrez-la dans le sous-répertoire scripts. Comme on l'a dit plus haut, vous pouvez aussi utiliser les cibles du Makefile et/ou les procédures pre-configure ou post-configure. Interactions avec l'utilisateur Si vos procédures de compilation, configuration ou installation ont besoin d'interagir avec l'utilisateur, définissez la variable IS_INTERACTIVE dans votre Makefile. Cela permettra aux “compilations de nuits” d'ignorer le logiciel que vous avez porté, si l'utilisateur définit dans son environnement la variable BATCH (s'il définit la variable INTERACTIVE, seuls les logiciels portés pour lesquels il faut des réponses de l'utilisateur sont compilés). Il est aussi recommandé, s'il y a des réponses par défaut raisonnables à vos questions, de tester la variable PACKAGE_BUILDING et de désactiver la partie interactive de la procédure si cette variable est définie. Cela permet de compiler les “paquetages” pour les CD-ROMs et les sites ftp. Configurer le Makefile Il est assez facile de configurer le Makefile, et nous vous suggérons à nouveau de jeter un coup d'oeil aux exemples existants avant de commencer. Il y a aussi un exemple de Makefile dans ce manuel, consultez-le donc et respectez s'il vous plaît l'ordre des variables et des sections de ce modèle pour que votre portage soit plus facile à lire pour les autres. Envisageons maintenant les problèmes suivants en séquence au fur et à mesure que vous mettez au point votre nouveau Makefile : Le source original Se trouve-t-il dans DISTDIR sous forme standard d'archive compressée avec gzip 1. Si ce n'est pas le cas, vous devriez envisager de surcharger une des variables EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX ou DISTFILES selon le degré de non-conformité du fichier de distribution de votre logiciel à porter. (Le cas le plus fréquent est EXTRACT_SUFX=.tar.Z, quand l'archive est compressée avec compress 1 et non gzip 1.) Dans le pire des cas, vous pouvez simplement créer votre propre cible do-extract pour surcharger la cible par défaut, bien que ce ne soit que rarement, sinon jamais, nécessaire. <makevar>DISTNAME</makevar> Vous devez affecter à DISTNAME le nom de fichier de votre logiciel à porter. Les règles par défaut veulent que le fichier de distribution (DISTFILES) s'appelle DISTNAMEEXTRACT_SUFX qui, si c'est un fichier d'archive habituel, sera quelque chose du style foozolix-1.0.tar.gz si DISTNAME=foozolix-1.0. Les règles par défaut veulent aussi que l(es) archive(s) soi(en)t extraite(s) dans un sous-répertoire appelé work/DISTNAME, e.g., work/foozolix-1.0/. Toutes ces conventions peuvent bien sûr être surchargées; ce sont simplement les valeurs par défaut qui font gagner le plus de temps. Pour un logiciel à porter pour lequel il y a plusieurs fichiers de distribution, définissez simplement explicitement DISTFILES. S'il n'y a qu'un sous-ensemble de DISTFILES qui est effectivement constitué d'archives extractibles, définissez-les dans EXTRACT_ONLY, qui surchargera la liste de DISTFILES au moment de l'extraction, les autres restant dans DISTDIR pour usage ultérieur. <makevar>PKGNAME</makevar> Si DISTNAME n'est pas conforme à nos recommandations pour un bon nom de paquetage, vous devriez affecter à la variable PKGNAME une meilleure valeur. Reportez-vous aux recommandations mentionnées ci-dessus pour plus de détails. <makevar>CATEGORIES</makevar> Quand un paquetage est crée, il est mis dans /usr/ports/packages/All et des liens sont définis dans un ou plusieurs sous-répertoires de /usr/ports/packages. Les noms de ces sous-répertoires sont spécifiés par la variable CATEGORIES. L'objectif est de faciliter la vie de l'utilisateur qui erre dans la quantité de paquetages sur le site ftp ou le CD-ROM. Jettez un oeil s'il vous plaît aux catégories existantes et choisissez celles qui conviennent à votre logiciel à porter. Cette liste détermina aussi où le logiciel sera importé dans l'arborescence du catalogue des logiciels portés Si vous y mentionnez plus d'une catégorie, les fichiers iront dans le sous-répertoire de même nom que la première de ces catégories. Reportez-vous à la section Catégories pour plus d'informations sur la manière de sélectionner les bonnes catégories. Si votre logiciel à porter appartient vraiment à une autre catégorie que celles qui sont déjà définies, vous pouvez même créer une nouvelle catégorie. Dans ce cas, envoyez s'il vous plaît un courrier électronique à la &a.ports; pour proposer la création d'une nouvelle catégorie. Il n'y a pas de contrôle des noms de catégorie. make paquetage créera sans sourcillier un nouveau sous-répertoire si vous orthographiez mal le nom de la catégorie, soyez donc prudent ! <makevar>MASTER_SITES</makevar> Indiquez le répertoire de l'“URL” ftp/http où se trouve l'archive originale dans MASTER_SITES. N'oubliez pas le “slash” final (/) ! Les macros-instructions make essayerons d'utiliser cette valeur pour récupérer le fichier de distribution avec FETCH, si elles ne le trouvent pas sur votre système. Il est conseillé de mentionner plusieurs sites dans cette liste, si possible sur des continents différents. Cela constituera un garde-fou contre les problèmes du réseau mondial, et nous envisageons même d'ajouter la détermination automatique du site de référence le plus proche, pour aller y chercher la distribution ! Si l'archive d'origine se trouve sur l'une des archives classiques suivantes : X-contrib, GNU, Perl CPAN, TeX CTAN ou Linux Sunsite, vous pouvez y faire référence sous forme plus compacte en vous servant de MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN et MASTER_SITE_SUNSITE. Affectez simplement à MASTER_SITE_SUBDIR le chemin d'accès au fichier dans l'archive. En voici un exemple : MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications L'utilisateur peut aussi configurer les variables MASTER_SITE_* dans /etc/make.conf pour surcharger vos choix, et utiliser à la place ses sites miroir favoris pour ces archives. <makevar>PATCHFILES</makevar> Si votre logiciel à porter a besoin de correctifs - patches - disponibles via ftp ou http, affectez à PATCHFILES les noms des fichiers et à PATCH_SITES l'“URL” du répertoire où ils se trouvent (le format est le même que pour MASTER_SITES). Si le correctif ne s'applique pas à la racine de l'arborescence des sources (i.e., WKRSRC) parce qu'il contient des chemins d'accès supplémentaires, définissez PATCH_DIST_STRIP en conséquence. Par exemple, si tous les noms de fichiers dans le correctif sont précédés de foozolix-1.0/, configurez alors PATCH_DIST_STRIP=-p1. Ne vous inquiétez pas si les correctifs sont compressés, ils seront automatiquement décompressés si les noms des fichiers se terminent par .gz ou .Z. Si le correctif est distribué avec d'autres fichiers, de la documentation par exemple, sous forme d'archive compressée avec gzip 1, vous ne pouvez pas utiliser PATCHFILES. Dans ce cas, ajoutez le nom et la localisation du correctif à DISTFILES et MASTER_SITES. Puis, appliquez le correctif depuis la cible pre-patch, soit en y exécutant la commande patch, soit en copiant le correctif dans le répertoire PATCHDIR et en l'appelant patch-xx. Remarquez que cette archive sera extraite en même temps que le source de base, il n'est donc pas nécessaire de l'extraire explicitement si elle est normalement compressée avec gzip 1 ou compress 1. Si vous le faites néanmoins, faites attention à ne rien écraser de ce qui existe dans le répertoire. Et n'oubliez pas non plus d'ajouter une commande pour supprimer le correctif recopié à la cible pre-clean. <makevar>MAINTAINER</makevar> Indiquez ici votre adresse électronique. S'il vous plaît. :) Pour une description détaillé de la responsabilité du chargé de la maintenance, reportez-vous à la section MAINTAINER des Makefiles. Dépendances De nombreux logiciels portés dépendent d'autres logiciels. Il y a cinq variables que vous pouvez utiliser pour vous assurer qu'il y a tout ce qu'il faut sur la machine de l'utilisateur. Il y a aussi des variables prédéfinies pour les cas les plus courants, et quelques autres pour contrôler le comportement vis-à-vis des dépendances. <makevar>LIB_DEPENDS</makevar> Cette variable définit les bibliothèques partagées dont dépend le logiciel à porter. C'est une liste de tuples biblothèque:répertoire:cible où bibliothèque est le nom de la bibliothèque partagée, répertoire est le nom du répertoire où la trouver si elle n'est pas encore installée et cible celui de la cible à exécuter dans ce répertoire. Par exemple : LIB_DEPENDS= jpeg\\.9\\.:${PORTSDIR}/graphics/jpeg:install cherchera une bibliothèque partagée jpeg avec le numéro de version majeure 9 et descendra dans le sous-répertoire graphics/jpeg de l'arborescence du catalogue des logiciels portés pour la compiler et l'installer, s'il ne la trouve pas. La cible peut être omise si elle est égale à DEPENDS_TARGET (dont la valeur par défaut est install). bibliothèque est passé en argument à ldconfig -r | grep -wF. Cette variable ne doit pas comporter d'expression régulière. La dépendance est vérifiée deux fois, une première fois depuis la cible extract et ensuite par la cible install. Le nom de la dépendance est aussi enregistré dans le paquetage de sorte que pkg_add l'installe automatiquement si elle n'est pas disponible sur le système de l'utilisateur. <makevar>RUN_DEPENDS</makevar> Cette variable définit quels exécutables et fichiers doivent être présents pour pouvoir utiliser le logiciel porté. C'est une liste de tuples chemin d'accès:répertoire:cible où chemin d'accès est le nom de l'exécutable ou du fichier, répertoire est le répertoire où le trouver s'il n'est pas encore installé et cible est la cible à exécuter dans ce répertoire. Si chemin d'accès commence par un “slash (/), il est traité comme un fichier et son existence est testée avec test -e ; sinon, on suppose que c'est un exécutable, et c'est la commande which -s qui est utilisée pour voir si le programme existe dans les chemins d'accès par défaut de l'utilisateur. Par exemple : RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \                wish8.0:${PORTSDIR}/x11-toolkits/tk80 regardera si le fichier ou le répertoire /usr/local/etc/innd existe, et le compilera et l'installera dans le sous-répertoiree news/inn de l'arborescence du catalogue des logiciels portés s'il ne le trouve pas. Il s'assurera aussi de la présence d'un exécutable appelé wish8.0 dans vos chemins d'accès par défaut, et ira dans le sous-répertoire x11-toolkits/tk80 de l'arborescence du catalogue des logiciels portés pour le compiler et l'installer s'il ne le trouve pas. Dans ce cas, innd est en fait un exécutable ; si un programme n'est pas à la place normale où on s'attend à le trouver dans les chemins d'accès par défaut de l'utilisateur, il faut utiliser son nom complet depuis la racine. La dépendance est vérifiée par la cible install. Le nom de la dépendance est aussi enregistré dans le paquetage de sorte que pkg_add l'installe automatiquement si elle n'est pas disponible sur le système de l'utilisateur. La cible peut être omise si elle est égale à DEPENDS_TARGET. <makevar>BUILD_DEPENDS</makevar> Cette variable définit quels exécutables et fichiers sont nécessaires pour installer le logiciel. Comme RUN_DEPENDS, c'est une liste de tuples chemin d'accès:répertoire:cible. Par exemple : BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip recherchera un exécutable appelé unzip et ira dans le sous-répertoire archivers/unzip de l'arborescence du catalogue des logiciels portés pour le compiler et l'installer s'il ne le trouve pas. “installer” recouvre ici tout le processus, de l'extraction à la compilation. La dépendance est vérifiée par la cible extract. La cible peut être omise si elle est égale à DEPENDS_TARGET. <makevar>FETCH_DEPENDS</makevar> Cette variable définit quels exécutables le logiciel a besoin de récupérer. Comme les deux précédentes, c'est une liste de tuples chemin d'accès:répertoire:cible. Par exemple : FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 recherchera un exécutable appelé ncftp2 et descendera dans le sous-répertoire net/ncftp2 de l'arborescence du catalogue des logiciels portés pour le compiler et l'installer s'il ne le trouve pas. La dépendance est vérifiée par la cible fetch. La cible peut être omise si elle est égale à DEPENDS_TARGET. <makevar>DEPENDS</makevar> S'il y a une dépendance qui ne rentre pas dans les quatre catégories précédentes ou si votre logiciel à porter a besoin que les sources d'un autre logiciel soient installés en plus de ce logiciel lui-même, utilisez cette variable. C'est une liste de répertoire:cible, puisqu'il n'y a rien à vérifier, à l'inverse des quatre précédentes. La cible peut être omise si elle est égale à DEPENDS_TARGET. Variables prédéfinies Utilisez USE_XLIB=yes si votre logiciel à porter a besoin que le système X Window soit installé (c'est implicite avec USE_IMAKE). Utilisez USE_GMAKE=yes si votre logiciel à porter a besoin de GNU make au lieu de BSD make. Utilisez USE_AUTOCONF=yes si votre logiciel à porter a besoin que GNU autoconf soit exécuté. Utilisez USE_QT=yes si votre logiciel utilise la boîte à outils Qt. Utilisez USE_PERL5=yes si votre logiciel à porter a besoin de la version 5 du langage perl. (Cette dernière variable est particulièrement importante parce que certaines versions de FreeBSD comportent perl 5 installé de base, mais d'autres non.) Notes à propos des dépendances Comme indiqué plus haut, la cible à appeler par défaut quand il y a un dépendance requise est DEPENDS_TARGET. Sa valeur par défaut est install. C'est une variable utilisateur. Elle n'est jamais définie dans le Makefile d'un logiciel à porter. Si votre logiciel à porter a besoin qu'une dépendance soit gérée d'une façon particulière, utilisez la partie :cible des variables *_DEPENDS au lieu de redéfinir DEPENDS_TARGET. Quand vous tapez make clean, les dépendances sont aussi purgées. Si vous ne voulez pas qu'il en soit ainsi, définissez la variable NOCLEANDEPENDS dans votre environnement. Pour dépendre sans condition d'un autre logiciel porté, il est habituel d'utiliser l'indication nonexistent comme premier champ de BUILD_DEPENDS ou RUN_DEPENDS. N'utilisez cela que si vous avez besoin du source d'un autre logiciel porté. Vous pouvez aussi avec cette cible économiser du temps de compilation. Par exemple : BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract ira toujours dans le répertoire du logiciel porté JPEG pour l'extraire. N'utilisez DEPENDS que s'il n'y a pas d'autre moyen d'obtenir ce que vous voulez. Cela provoquera toujours la compilation (et par défaut l'installation) d'autres logiciels portés et la dépendance sera aussi inclue aux paquetages. Si c'est vraiment ce dont vous avez besoin, je vous recommande d'utiliser BUILD_DEPENDS et RUN_DEPENDS à la place—au moins votre intention sera claire. Mécanismes de compilation Si votre paquetage utilise GNU make, positionnez USE_GMAKE=yes. Si votre paquetage utilise configure, positionnez HAS_CONFIGURE=yes. Si votre paquetage utilise GNU configure, positionnez GNU_CONFIGURE=yes (ce qui implique HAS_CONFIGURE). Si vous voulez passer des arguments supplémentaires à configure (la liste d'arguments par défaut est --prefix=${PREFIX} pour GNU configure et elle est vide pour les autres versions de configure), définissez ces arguments complémentaires avec la variable CONFIGURE_ARGS. Si votre paquetage utilise GNU autoconf, positionnez USE_AUTOCONF=yes. Cela implique GNU_CONFIGURE, et provoquera l'exécution d'autoconf avant celle de configure. Si votre paquetage est une application X qui génère des Makefiles à partir d'Imakefiles avec imake, positionnez alors USE_IMAKE=yes. A l'étape de configuration, la commande xmkmf -a sera automatiquement exécutée. Si l'option pose une problème pour votre portage, positionnez XMKMF=xmkmf. Si le portage utilise imake mais ne comprend pas la cible install.man, il faut alors définir NO_INSTALL_MANPAGES=yes. De plus, l'auteur d'origine du logiciel devrait être “fusillé”. :> Si le Makefile d'origine du logiciel que vous portez utilise une autre cible principale que all, définissez en conséquence ALL_TARGET. Il en va de mê:me pour install et INSTALL_TARGET. Considérations particulières Il y a quelques autres points à prendre en compte lorsque vous portez un logiciel. Cette section détaille les plus fréquemment rencontrés. <command>ldconfig</command> Si votre portage installe une bibliothèque partagée, ajoutez une cible post-install à votre Makefile qui exécute ${LDCONFIG} -m sur le répertoire où la nouvelle bibliothèque est installée (habituellement PREFIX/lib) pour l'enregistrer dans le cache de bibliothèque partagée. Ajoutez aussi une ligne @exec /sbin/ldconfig -m et la ligne @unexec /sbin/ldconfig -R correspondante à votre fichier pkg/PLIST de façon à ce que l'utilisateur qui installe le paquetage puisse utiliser immédiatement la bibliothèque partagée et qu'à la désinstallation, le système sache que la bibliothèque n'est plus là. Ces lignes doivent suivre immédiatement celle qui concerne la bibliothèque partagée elle-même, comme dans : lib/libtvl80.so.1 @exec /sbin/ldconfig -m %D/lib @unexec /sbin/ldconfig -R N'ajoutez jamais, mais vraiment jamais de ligne qui ne contienne que ldconfig sans argument à votre Makefile ou à votre pkg/PLIST. Cela réinitialisera le cache de bibliothèque partagée avec le contenu de /usr/lib uniquement, et vérolera royalement la machine de l'utilisateur (“A l'aide, xinit ne fonctionne plus depuis que j'ai installé ce logiciel porté !). Quiconque commet ce crime sera fusillé et découpé en 65.536 morceaux avec un couteau rouillé, son foie sera déchiqueté par une bande de corbeaux et il rôtira éternellement au tréfonds de l'enfer (pas nécessairement dans cet ordre…) Support ELF Comme FreeBSD passe à ELF peu de temps aprè 3.0-release, il faut convertir de nombreux ports qui compilent des biblothèques partagées pour qu'ils supportent ELF. Cette tâche est compliquée par le fait qu'un système 3.0 peut s'exécuter à la fois en ELF et en a.out et que nous voulons supporter la version 2.2 aussi longtemps que possible. Voici quelques indications pour la conversion de logiciels portés a.out pour qu'ils supportent à la fois la compilation en a.out et ELF. Certains points cités ne s'appliquent qu'à la conversion elle-même. Ils resteront mentionnés néanmoins quelque temps pour le cas où vous tomberiez sur un ancien logiciel porté que vous voulez mettre à niveau. Mettre de côté les bibliothèques a.out Les bibliothèques a.out doivent être déplacées de /usr/local/lib et autres vers un sous-répertoire aout. (Si vous ne les mettez pas de côté, les logiciels portés ELF les écraseront sans sourciller.) La cible move-aout-libs du src/Makefile de 3.0-current (appelé par aout-to-elf) le fera pour vous. Elle ne déplacera que les bibliothèques a.out, il n'y a donc pas de risque à l'appeler sur un système où il y a à la fois des bibliothèques ELF et a.out dans les répertoires standard. Format L'arborescence du catalogue des logiciels portés compilera les paquetages au format utilisé par la machine, c'est-à-dire a.out en 2.2 et a.out ou ELF en 3.0 selon ce que retourne la commande `objformat`. D'autre part, un fois que les utilisateurs déplacent les bibliothèques a.out dans un sous-répertoire, la compilation des bibliothèques a.out ne sera plus supporté. (i.e., cela peut encore marcher si vous savez ce que vous faites, mais vous devrez vous débrouiller par vous-même.) Si un logiciel porté ne fonctionne qu'en a.out, affectez à BROKEN_ELF une chaîne de caractères qui décrive pourquoi. Ces logiciels ne seront pas générés à la compilation sur un système ELF. <makevar>PORTOBJFORMAT</makevar> bsd.port.mk affectera à PORTOBJFORMAT la valeur aout ou elf et l'exportera dans les environnements CONFIGURE_ENV, SCRIPTS_ENV et MAKE_ENV. (Ce sera toujours aout sous 2.2-STABLE). Elle est aussi passée à PLIST_SUB sous la forme PORTOBJFORMAT=${PORTOBJFORMAT}. (Reportez-vous aux explications concernant ldconfig plus bas.) Cette variable est définie par la ligne suivante de bsd.port.mk : PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout Le processus de compilation des logiciels portés devrait toujours utiliser cette variable pour décider de ce qu'il faut faire. Cependant, si la procédure configure associée détecte déjà automatiquement un système ELF, il n'est pas nécessaire de se référer à PORTOBJFORMAT. Compilation des bibliothèques partagées Ce qui suit décrit les différences de gestion des bibliothèques partagées entre les formats ELF et a.out. Versions de bibliothèques partagées Une bibliothèque partagée ELF doit s'appeler libfoo.so.M, où M est un unique numéro de version et une bibliothèque partagée a.out doit s'appeler libfoo.so.M.N, où M est le numéro de version majeure et N celui de version mineure. Ne confondez pas ; n'installez jamais de bibliothèque partagée ELF appelée libfoo.so.N.M ou de bibliothèque partagée A.out (ou de lien symbolique dessus) appelée libfoo.so.N. Ligne de commande de l'éditeur de liens En supposant que cc -shared soit utilisé plutôt que ld directement, la seule différence est qu'il faut ajouter sur la ligne de commande pour ELF. Il faut définir un lien symbolique de libfoo.so vers libfoo.so.N pour que les éditeurs de liens ELF s'y retrouvent. Comme il doit être aussi mentionné dans PLIST, cela ne posera pas de problème dans le cas de a.out (pour certains logiciels portés, il faut même que ce lien existe pour l'édition de liens dynamiques), vous devriez définir ce lien quelle que soit la valeur de la variable PORTOBJFORMAT. <makevar>LIB_DEPENDS</makevar> Tous les Makefiles des logiciels portés sont à modifier pour supprimer les numéros de versions mineures de LIB_DEPENDS, ainsi que le support des expressions réqulières (e.g., foo\\.1\\.\\(33|40\\) devient foo.2.) La correspondance sera effectuée par grep -wF. <filename>PLIST</filename> PLIST doit contenir les noms courts (ELF) des bibliothèques partagées si leur numéro de version mineure a.out est zéro et les noms longs (a.out) dans le cas contraire. bsd.port.mk ajoutera automatiquement le .0 à la fin des noms courts de bibliothèques partagées si PORTOBJFORMAT vaut aout, et supprimera le numéro de version mineure des noms longs si PORTOBJFORMAT vaut elf. Au cas où vous auriez vraiment besoin d'installer des bibliothèques partagées avec deux numéros de version sur un système ELF ou avec un seul numéro de version sur un système a.out (par exemple, pour les logiciels portés qui installent des bibliothèques pour la compatibilité avec d'autres systèmes d'exploitation), définissez la variable NO_FILTER_SHLIBS. Cela inhibera le mécanisme de modification de PLIST décrit au paragraphe précédent. <literal>ldconfig</literal> La ligne ldconfig des Makefiles doit contenir : ${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m .... Dans PLIST, il doit y avoir : @exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ... @unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -R Cela pour garantir que la bonne commande ldconfig sera appelée en fonction du format du paquetage et non du format par défaut sur le système. <makevar>MASTERDIR</makevar> Si votre logiciel porté a besoin de générer des versions légèrement différentes des paquetages en fonction de la valeur d'une variable (la résolution ou le format de page par exemple), créez un sous-répertoire par paquetage pour qu'il soit plus facile aux utilisateurs de savoir quoi faire, mais essayez de partager autant de fichiers que possible entre logiciels portés. Vous aurez normalement besoin d'un Makefile très court dans tous les sous-répertoires à l'exception d'un seul. Dans ces Makefiles, vous pouvez utiliser la variable MASTERDIR pour indiquer le répertoire où se trouvent le reste des fichiers. Utilisez aussi une variable pour une partie de PKGNAME de façon à ce que les paquetages aient des noms différents. Cela sera plus clair avec un exemple. C'est un extrait de japanese/xdvi300/Makefile : PKGNAME= ja-xdvi${RESOLUTION}-17 : # default RESOLUTION?= 300 .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \        ${RESOLUTION} != 300 && ${RESOLUTION} != 400        @${ECHO} "Erreur: valeur incorrecte pour RESOLUTION: \"${RESOLUTION}\""        @${ECHO} "Les valeurs acceptables sont : 118, 240, 300 (par défaut) et 400."        @${FALSE} .endif japanese/xdvi300 contient aussi les fichiers de “patches”, paquetages, etc. Si vous y tapez make, la valeur de la résolution sera prise par défaut (300) et le logiciel porté compilera normalement. Poue les autres résolutions, voici le xdvi118/Makefile complet : RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include ${MASTERDIR}/Makefile (xdvi240/Makefile et xdvi400/Makefile sont identiques). La définition de MASTERDIR dit à bsd.port.mk que le jeu de sous-répertoires habituels tels que PATCHDIR et PKGDIR se trouvent dans xdvi300. La ligne RESOLUTION=118 surchargera la ligne RESOLUTION=300 de xdvi300/Makefile et le logiciel porté sera compilé avec une résolution de 118. Versions des biblothèques partagées Lisez tout d'abord s'il vous plaît nos Instructions à propos des versions de bibliothèques partagées pour savoir comment gérer de façon générale les versions de bibliothèques. Ne supposez pas aveuglement que les auteurs des logiciels savent ce qu'ils font; ce n'est, la plupart du temps, pas le cas. Il est très important que ces détails soient attentivement examinés, parce que nous nous trouvons dans une situation assez particulière dans laquelle nous devons faire cohabiter des douzaines de logiciels potentiellement incompatibles. Les importations à la va-vite de logiciels ont posé dans le passé de gros problèmes en ce qui concerne les bibliothèques partagées (vous êtes vous jamais demandé pourquoi le numéro de version de la bibliothèque partagée jpeg-6b était 0.9?). En cas de doute, envoyez un message à &a.ports;. La plupart du temps, votre tâche se limitera à déterminer la bonne version de bibliothèque partagée et à appliquer les bonnes mises à niveau - patches - pour l'implémenter. Néanmoins, s'il y a une bibliothèque portée qui n'est qu'une même version de la même bibliothèque partagée déjà présente au catalogue, la situation est beaucoup plus complexe. Brièvement, l'implémentation sous FreeBSD ne permet pas à l'utilisateur de préciser à l'éditeur de liens avec quelle version de bibliothèque partagée effectuer l'édition de liens (l'éditeur de liens choisira toujours le numéro de version le plus élevé). Cela signifie que, s'il y a sur le système une libfoo.so.3.2 et une libfoo.so.4.0, il n'y a aucun moyen de dire à l'éditeur de liens qu'une application donnée doit être liée avec libfoo.so.3.2. c'est totalement masqué au moment de l'édition de liens. Dans ce cas, il n'y a qu'une seule solution, renommer la base du nom de la bibliothèque partagée. Par exemple, modifier libfoo.so.4.0 en libfoo4.so.1.0 pour que les versions 3.2 et 4.0 puissent être liées avec d'autres logiciels portées. Pages de manuel Les variables MAN[1-9LN] ajouteront automatiquement toutes les pages de manuel à pkg/PLIST (cela signifie que vous ne devez pas lister les pages de manuel dans PLIST—reportez-vous à la section Modifier PLIST sur la base des variables du make pour plus de détails). Cela provoquera aussi la compression ou la décompression de pages de manuel selon le contenu de la variable NOMANCOMPRESS dans /etc/make.conf. Pour indiquer si les pages de manuel doivent être compressées à l'installation, utilisez la variable MANCOMPRESSED. Cette variable peut prendre trois valeurs, yes, no et maybe. yes signifie que les pages de manuel sont installées déjà compressées, no signifie qu'elles ne le sont pas, et maybe signifie que le logiciel s'aligne toujours sur la valeur de NOMANCOMPRESS de sorte que bsd.port.mk n'a rien à faire de spécial. MANCOMPRESSED est automatiquement définie à yes si USE_IMAKE est définie et que NO_INSTALL_MANPAGES ne l'est pas, et à no sinon. Vous n'avez pas à la définir explicitement, à moins que la valeur par défaut ne convienne pas à votre logiciel à porter. Si votre logiciel à porter installe ses pages de manuel ailleurs que dans PREFIX, vous pouvez utiliser MANPREFIX pour l'indiquer. Si ce sont seulement certaines pages de manuel qui ne doivent pas être installées dans le répertoire habituel, comme c'est le cas pour certains modules portés Perl, vous pouvez définir des répertoires individualisés pour les pages de manuel avec MANsectionPREFIX (où sect est une valeur de 1-9, ou L ou N). Si vos pages de manuel vont dans des sous-répertoires dépendant de la langue, définissez les noms de ces langues dans MANLANG. La valeur par défaut de cette variable est "" (i.e., Anglais seulement). Voici un exemple qui rassemble tout cela : MAN1= foo.1 MAN3= bar.3 MAN4= baz.4 MANLANG= "" ja MAN3PREFIX= ${PREFIX}/share/foobar MANCOMPRESSED= yes Ce qui veut dire que six fichiers sont installés par ce logiciel porté : ${PREFIX}/man/man1/foo.1.gz ${PREFIX}/man/ja/man1/foo.1.gz ${PREFIX}/share/foobar/man/man3/bar.3.gz ${PREFIX}/share/foobar/man/ja/man3/bar.3.gz ${PREFIX}/man/man4/baz.4.gz ${PREFIX}/man/ja/man4/baz.4.gz Les logiciels portés qui ont besoin de Motif Il y a de nombreux programmes qui ont besoin d'une bibliothèque Motif pour compiler (disponible auprès de plusieurs distributeurs commerciaux, et dont il existe un clone libre, qui est capable de faire fonctionner pas mal d'applications, dans x11-toolkits/lesstif). Comme c'est un boîte à outils très utilisée et que ses licences autorisent habituellement la redistribution de binaires si la bibliothèque est liée statiquement, nous avons prévu un mécanisme pour gérer les logiciels portés qui ont besoin de Motif de façon à pouvoir facilement compiler des binaires soit liés dynamiquement (pour ceux qui utilisent le catalogue des logiciels portés) ou statiquement (pour ceux qui distribuent des paquetages). <makevar>REQUIRES_MOTIF</makevar> Si votre logiciel à porter a besoin de Motif, définissez cette variable dans le Makefile. cela empéchera que ceux qui ne disposent pas de Motif puissent ne serait-ce qu'essayer de compiler votre logiciel. <makevar>MOTIFLIB</makevar> Cette variable sera définie par bsd.port.mk pour référencer la version appropriée de la bibliothèque Motif. Ajoutez s'il vous plaît un correctif - patch - au source pour qu'il utilise cette variable chaque fois que la bibliothèque Motif est référencé dans le Makefile ou le Imakefile. Il y a deux cas de figure courants : Si le logiciel à porter désigne la bibliothèque Motif avec -lXm dans son Makefile ou Imakefile, remplacez-le simplement par ${MOTIFLIB}, Si le logiciel à porter utilise XmClientLibs dans son Imakefile, remplacez-le par ${MOTIFLIB} ${XTOOLLIB} ${XLIB}. Remarquez que la variable MOTIFLIB est (habituellement) remplacée par -L/usr/X11R6/lib -lXm ou /usr/X11R6/lib/libXm.a, il n'y a donc pas besoin d'y inclure le -L ou -l. Polices X11 Si votre logiciel à porter installe des polices de caractères pour le Système X Window, mettez-les dans X11BASE/lib/X11/fonts/local. Ce répertoire est une nouveauté de XFree86 version 3.3.3. S'il n'existe pas, créez-le s'il vous plaît et émettez un message pour suggérer à l'utilisateur de passer à la version 3.3.3, ou ultérieure, de XFree86, ou ajoutez au moins ce répertoire aux chemins d'accès aux polices de caractères dans /etc/XF86Config. Fichiers “Info” La nouvelle version de texinfo (depuis 2.2.2-RELEASE) comporte un utilitaire appelé install-info pour ajouter ou supprimer des entrées dans le fichier dir. Si votre logiciel à porter installe des documents “info”, suivez s'il vous plaît les instructions ci-dessous pour que votre logiciel porté/précompilé mette correctement à jour le fichier PREFIX/info/dir de l'utilisateur. (Excusez-moi de la longueur de cette section, mais il est impératif d'assembler correctement ensemble tous les fichiers “info;”. Si c'est proprement fait, il en résultera une belle édition, accordez-moi donc s'il vous plaît votre attention.) Voici ce que vous devez en premier lieu savoir (pour porter un logiciel) :Traduction : &prompt.user; install-info --help install-info [OPTION]... [INFO-FILE [DIR-FILE]] Installe INFO-FILE dans le répertoire “Info” DIR-FILE. Options: --delete supprime les entrées existantes dans INFO-FILE;                     n'insère aucune nouvelle entrée.  : --entry=TEXT Insère un entrée pour le répertoire “Info;”.  : --section=SEC Ajoute les entrées de ce fichier à la section SEC de ce répertoire. : &prompt.user; install-info --help install-info [OPTION]... [INFO-FILE [DIR-FILE]] Install INFO-FILE in the Info directory file DIR-FILE. Options: --delete Delete existing entries in INFO-FILE;                     don't insert any new entries.  : --entry=TEXT Insert TEXT as an Info directory entry.  : --section=SEC Put this file's entries in section SEC of the directory. : Ce programme n'installe en fait pas de fichiers “info”; il ne fait qu'insérer ou supprimer des entrées au fichier dir. Voici une procédure en sept étapes pour adapter les logiciels à porter pour qu'ils utilisent install-info. Je prendrais comme exemple editors/emacs : Consultez les sources texinfo et construisez un fichier de mise à jour qui insère des instructions @dircategory et @direntry aux fichiers où il n'y en a pas. Voici un extrait de mon “patch” : --- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@ -2,6 +2,10 @@  @setfilename ../info/vip  @settitle VIP +@dircategory The Emacs editor and associated tools +@direntry +* VIP: (vip). A VI-emulation for Emacs. +@end direntry  @iftex  @finalout  : Cela doit pouvoir se passer d'explications. De nombreux auteurs mettent dans leur arborescence des sources un fichier dir qui contient toutes les entrées dont vous avez besoin, regardez donc à droite et à gauche avant de le créer vous-même. Veillez aussi à consulter les entrées pour les logiciels en rapport avec le voˆtre, pour que vos noms de sections et indentations soient en cohérence (nous recommandons de mettre les libellés après la quatrième position de tabulation). Remarquez que vous ne pouvez mettre qu'une entrée “info” par fichier, à cause d'un bogue dans install-info --delete, qui ne supprime que la première entrée de la section @direntry si vous en indiquez plusieurs. Vous pouvez donner les entrées dir comme arguments à install-info ( et ) au lieu de rectifier les sources de texinfo. Je ne trouve pas que cela soit une bonne idée parce que vous devez répéter la même information à trois endroits différents (Makefile et @exec/@unexec de PLIST; voyez plus bas). Néanmoins, si vous avez des fichiers “info” en Japonais (ou codés sur plusieurs octets), vous devrez utiliser les paramètres supplémentaires d'install-info parce que makeinfo ne sait pas gérer ces sources texinfo. (Consultez le Makefile et PLIST de japanese/skk pour avoir un exemple de la manière de procéder.) Retournez dans le répertoire de votre logiciel porté, faites un make clean; make et vérifiez que les fichiers “info” sont régénérés à partir des sources texinfo. Comme ces derniers sont plus récents que les fichiers “info”, ils doivent être reconstruits par le make; mais de nombreux Makefiles ne comportent pas les dépendances correctes pour les fichiers “info”. Dans le cas d'emacs, j'ai dû rectifier le Makefile.in principal pour qu'il aille dans le sous-répertoire man pour reconstruire les pages “info” : --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Tue Apr 15 00:15:28 1997 @@ -184,7 +184,7 @@  # Sous-répertoires à reconstruire récursivement. `lisp' n'est pas inclus  # parce que les fichiers lisp compilés font partie de la distribution  # et que vous ne pouvez pas les recompiler sans installer d'abord Emacs -SUBDIR = lib-src src +SUBDIR = lib-src src man  # makefile des sous-répertoires listés dans $SUBDIR.  SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile --- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996 +++ ./man/Makefile.in Tue Apr 15 00:29:52 1997 @@ -66,6 +66,7 @@  ${srcdir}/gnu1.texi \  ${srcdir}/glossary.texi +all: info  info: $(INFO_TARGETS)  dvi: $(DVI_TARGETS) La deuxième modification est nécessaire parce que la cible par défaut dans le sous-répertoire man s'appelle info, alors que le Makefile veut exécuter la cible all. J'ai aussi supprimé l'installation du fichier “info” parce que nous en avons déjà un de même nom dans /usr/share/info (cette correction n'apparaît pas dans l'exemple). Si le fichier dir est installé par des instructions quelque part dans le Makefile, supprimez-les. Votre logiciel à porter ne doit pas le faire. Supprimez aussi toutes les autres commandes qui “saliraient” le fichier dir. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Mon Apr 14 23:38:07 1997 @@ -368,14 +368,8 @@         if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \         then \           (cd ${infodir}; \ - if [ -f dir ]; then \ - if [ ! -f dir.old ]; then mv -f dir dir.old; \ - else mv -f dir dir.bak; fi; \ - fi; \            cd ${srcdir}/info ; \ - (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \ - (cd $${thisdir}; chmod a+r ${infodir}/dir); \            for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \              (cd $${thisdir}; \               ${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \               chmod a+r ${infodir}/$$f); \ (Cette étape n'est nécessaire que si vous modifiez un logiciel porté déjà existant.) Consultez pkg/PLIST et supprimez tout ce qui essaye d'appliquer des rectificatifs à info/dir. Cela peut se produire dans pkg/INSTALL ou un autre fichier, faites donc une recherche détaillée : Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/04/15 06:32:12 @@ -15,9 +15,6 @@  man/man1/emacs.1.gz  man/man1/etags.1.gz  man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir  info/cl  info/cl-1  info/cl-2 Ajoutez une cible post-install au Makefile pour créer un fichier dir s'il n'y en a pas. Appelez aussi install-info pour les fichiers “info” installés : Index: Makefile =================================================================== RCS file: /usr/cvs/ports/editors/emacs/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 1996/11/19 13:14:40 1.26 +++ Makefile 1997/05/20 10:25:09 1.28 @@ -20,5 +20,11 @@  post-install:  .for file in emacs-19.34 emacsclient etags ctags b2m        strip ${PREFIX}/bin/${file}  .endfor + if [ ! -f ${PREFIX}/info/dir ]; then \ + ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \ + fi +.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode + install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir +.endfor  .include <bsd.port.mk> N'utilisez rien d'autre que /usr/share/info/dir et la commande ci-dessus pour créer un nouveau fichier “info”. J'ai en fait ajouté les trois premières lignes du rectificatif ci-dessus à bsd.port.mk pour le cas o` vous ne l'auriez pas fait par vous-même dans PLIST. Editez PLIST et ajoutez les instructions @exec ainsi que @unexec équivalentes pour pkg_delete. Vous n'avez pas besoin de supprimer info/dir avec @unexec : Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/05/20 10:25:12 1.17 @@ -16,7 +14,15 @@  man/man1/etags.1.gz  man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir  : +@unexec install-info --delete %D/info/ccmode %D/info/dir  info/cl  info/cl-1 @@ -87,6 +94,18 @@  info/viper-3  info/viper-4 +@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir +@exec install-info %D/info/emacs %D/info/dir  : +@exec install-info %D/info/ccmode %D/info/dir  libexec/emacs/19.34/i386--freebsd/cvtmail  libexec/emacs/19.34/i386--freebsd/digest-doc Les commandes @unexec install-info --delete doivent être placées avant les fichiers “info” eux-mêmes pour qu'elles puissent lire les fichiers. Il faut aussi placer les commandes @exec install-info après les fichiers “info” et la commande @exec qui crée le fichier dir file. Testez et admirez votre oeuvre. :). Vérifiez le fichier dir avant et après chaque étape. Le sous répertoire <filename>pkg/</filename> Il y a quelques astuces dont je n'ai pas encore parlé à propos du sous-répertoire pkg/ qui sont parfois utiles. <filename>MESSAGE</filename> Si vous avez besoin d'afficher un message lors de l'installation, vous pouvez le mettre dans pkg/MESSAGE. Cette fonctionnalité sert souvent à informer des étapes d'installation qui doivent être effectuées après pkg_add ou pour afficher des informations à propos de la licence. Il n'y a pas besoin d'ajouter le fichier pkg/MESSAGE à pkg/PLIST. D'autre part, il ne sera pas affiché automatiquement si l'utilisateur installe le logiciel porté au lieu du logiciel précompilé, vous devriez donc probablement l'afficher vous-même depuis la cible post-install. <filename>INSTALL</filename> S'il faut exécuter des commandes lors de l'installation du logiciel précompilé avec pkg_add, vous pouvez le faire avec la procédure pkg/INSTALL. Cette procédure sera automatiquement ajoutée au paquetage et exécutée deux fois par pkg_add. La première fois sous la forme INSTALL ${PKGNAME} PRE-INSTALL et la seconde fois sous la forme INSTALL ${PKGNAME} POST-INSTALL. Vous pouvez tester $2 pour savoir comment la procédure a été appelée. La variable d'environnement PKG_PREFIX contient le chemin d'accès au répertoire d'installation du logiciel. Reportez-vous aux pages de manuel de &man.pkg.add.1; pour plus d'informations. Cette procédure n'est pas exécutée automatiquement si le logiciel porté est installé avec make install. Si vous avez besoin qu'elle le soit, vous devrez l'appeler explicitement depuis le Makefile du logiciel porté. <filename>REQ</filename> Si votre logiciel à porter doit déterminer s'il doit être installé ou non, vous pouvez créer une procédure pkg/REQ - “requis”. Elle sera appelée automatiquement lors de l'installation et de la désinstallation pour décider s'il faut ou non effectuer l'opération. Modifier <filename>PLIST</filename> sur la base de variables du <command>make</command> Certains logiciels portés, en particulier les logiciels p5-..., doivent modifier leur PLIST selon les options avec lesquelles ils sont configurés (ou la version de perl, dans le cas des logiciels p5-...). Pour rendre les choses plus faciles, toutes les occurrences de %%OSREL%%, %%PERL_VER%% et %%PERL_VERSION%% dans la PLIST seront remplacées par les valeurs appropriées. La valeur de %%OSREL%% est le numéro de version du système d'exploitation (e.g., 2.2.7). %%PERL_VERSION%% est le numéro de version complet de perl (e.g., 5.00502) et %%PERL_VER%% est le numéro de version de perl, sans le niveau de “patch” (e.g., 5.005). Si vous avez besoin d'autres substitutions, vous pouvez renseigner la variable PLIST_SUB avec une liste de doublets VAR=VALUE et toutes les occurrences de %%VAR%% seront remplacées par VALUE dans la PLIST. Par exemple, si votre logiciel à porter installe de nombreux fichiers dans un sous-répertoire différent selon la version, vous pouvez mettre quelque chose comme : OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} dans le Makefile et utiliser %%OCTAVE_VERSION%% chaque fois que la version apparaît dans la PLIST. De cette façon, lorsque vous mettez à jour le logiciel, vous n'aurez pas à modifier des douzaines (dans certains cas, des centaines) de lignes dans la PLIST. Cette substitution (de même que l'ajout des pages de manuel) est faite entre les cibles do-install et post-install, en lisant PLIST et en écrivant dans TMPPLIST (par défaut : WRKDIR/.PLIST.mktmp). Si votre logiciel à porter construit PLIST à la volée, faites-le alors dans ou avant do-install. De plus, si votre logiciel a besoin de modifier le fichier obtenu, faites-le dans post-install et dans un fichier appelé TMPPLIST. Changer les noms des fichiers du sous-répertoire <filename>pkg</filename> Tous les noms de fichier du sous-répertoire pkg sont définis par des variables, vous pouvez donc les changer dans votre Makefile si besoin est. C'est particulièrement utile si vous partager le même sous-répertoire pkg entre plusieurs logiciels portés ou devez écrire dans l'un de ces fichiers (voyez la section Ecrire ailleurs que dans WRKDIR pour savoir pourquoi c'est une mauvaise idée d'écrire directement dans le sous-répertoire pkg. Voici la liste de ces variables et leurs valeurs par défaut : Variable Valeur par défaut COMMENT ${PKGDIR}/DESCR DESCR ${PKGDIR}/DESCR PLIST ${PKGDIR}/PLIST PKGINSTALL ${PKGDIR}/PKGINSTALL PKGDEINSTALL ${PKGDIR}/PKGDEINSTALL PKGREQ ${PKGDIR}/REQ PKGMESSAGE ${PKGDIR}/MESSAGE Modifiez s'il vous plaît ces variables plutôt que de surcharger PKG_ARGS. Si vous modifiez PKG_ARGS, ces fichiers ne seront pas correctement installés dans /var/db/pkg lors de l'installation sous forme de logiciel porté. Problèmes de licence Certains logiciels ont des licences qui imposent des restrictions ou peuvent violer la loi. (Le brevet de PKP sur la cryptographie ` clé publique et ITAR - exportation de logiciel de cryptographie - pour ne citer que deux exemples). Ce que nous pouvons en faire varie beaucoup, selon les termes exacts de leurs licences respectives. Il est de votre responsabilité, pour le logiciel que vous porter, de lire les termes de la licence et de vous assurer que le projet FreeBSD ne pourra pas être accusé de les violer en redistribuant le source ou les binaires compilés que ce soit par ftp ou sur CD-ROM. En cas de doute, contactez-la &a.ports;. Il y a deux variables que vous pouvez définir dans le Makefile pour gérer les situations qui se produisent souvent : Si le logiciel à porter a une licence de type “non commercialisable” affectez à la variable NO_CDROM une chaîne de caractères expliquant pourquoi. Nous vérifierons que ces logiciels ne soient pas sur le CD-ROM au moment de la parution. Les archives du source et le paquetage seront cependant disponibles par ftp. S'il faut recompiler le logiciel porté sur chaque site, ou si le logiciel précompilé ne peut pas être redistribué du fait de sa licence, affectez à la variable NO_PACKAGE une chaîne de caractères expliquant pourquoi. Nous vérifierons que ces logiciels précompilés ne soient pas sur le site ftp ni sur le CD-ROM au moment de la parution. Les archives du source seront cependant disponibles sur les deux. S'il y a des restrictions légales à l'utilisation du logiciel (e.g., cryptographie) ou que la licence est du type “pas d'usage commercial”, affectez à la variable RESTRICTED une chaîne de caractères expliquant pourquoi. Pour ces logiciels, ni les archives du source ni le logiciel précompilé ne seront même disponibles sur nos sites ftp. La Licence Publique Générale GNU - GNU General Public License (GPL), version 1 et 2, ne pose normalement pas de problème pour les logiciels portés. Si vous êtes “committer”, veillez à mettre aussi à jour le fichier ports/LEGAL. Mises à jour Si vous constatez qu'un logiciel porté n'est pas synchronisé avec la plus récente version des auteurs originaux, vérifiez d'abord que vous avez la dernière version du logiciel porté. Vous la trouverez dans le répertoire ports/ports-current des sites miroir ftp. Envoyez ensuite un courrier électronique au responsable de la maintenance, s'il est mentionné dans le Makefile du logiciel. Il est peut-être déjà en train de travailler sur la mise à jour, ou a une bonne raison de ne pas la faire (par exemple à cause de problèmes de stabilité de la nouvelle version). Si le responsable de la maintenance vous demande de mettre le logiciel à jour ou s'il n'y a tout simplement pas de responsable, faites cette mise à jour et envoyez un delta récursif (soit contextuel soit unifié, mais les responsables de l'arborescence des logiciels portés préfèrent le format unifié) entre les anciens et les nouveaux répertoires du logiciel (e.g., si votre répertoire modifié s'appelle superedit et l'original tel que dans notre arborescence superedit.bak, envoyez nous alors le résultat de diff -ruN superedit.bak superedit). Contrôlez-le s'il vous plaît pour vérifier que toutes les modifications sont cohérentes. La meilleure façon de nous l'envoyer est de l'inclure dans un &man.send-pr.1; (catégorie ports). Précisez s'il vous plaît quels sont les fichiers ajoutés et supprimés, parce qu'il faut explicitement les indiquez à CVS au moment de le mise à jour. Si le delta fait plus de 20Ko, compressez-le et codez-le avec uuencode; sinon, incluez-le seulement tel quel dans le PR. Une fois encore, utilisez s'il vous plaît &man.diff.1; et non &man.shar.1; pour nous envoyer les mises à jour des logiciels portés. <anchor id="porting-dads">A faire à ne pas faire Voici une liste de ce qu'il faut habituellement faire ou éviter lors d'un portage. Vous devriez utiliser cette liste pour valider votre propre portage et vous pouvez aussi contrôler les logiciels que d'autres ont soumis dans la base des données des rapports d'incidents. Transmettez tous vos commentaires au sujet des logiciels portés dans la rubrique Rapports d'incidents et commentaires généraux - Bug Reports and General Commentary. Validez les logiciels portés mentionnés dans la base nous permettra de les intégrer plus rapidement et prouvera en même temps que vous savez ce que vous faites. Nettoyez les binaires Supprimez les informations inutiles - strip - des binaires. Si c'est déjà fait par le source d'origine, tant mieux; sinon ajoutez une règle à la cible post-install pour le faire vous-même. Voici un example : post-install:         strip ${PREFIX}/bin/xdl Utilisez la commande &man.file.1; sur l'exécutable installé pour voir s'il est déjà nettoyé. Si elle ne vous répond pas not stripped, c'est déjà fait. macros-instruction INSTALL_* Utilisez les macros-instructions fournies par bsd.port.mk pour être sûr que les droits sur les fichiers sont correctement gérés par vos cibles *-install. Ce sont : INSTALL_PROGRAM pour installer les binaires exécutables, INSTALL_SCRIPT pour installer les procédures exécutables, INSTALL_DATA pour installer les données partageables, INSTALL_MAN pour installer les pages de manuel et autres documentations (cela ne compresse rien). Ces macros-instructions sont essentiellement composées d'une commande install avec les options appropriées. Vous trouverez plus bas un exemple de leur utilisation. <makevar>WRKDIR</makevar> N'écrivez rien en dehors de WRKDIR. WRKDIR est le seul endroit où vous êtes sûr de pouvoir écrire pendant la compilation d'un logiciel porté (reportez-vous à la section compiler les logiciels portés depuis un CD-ROM pour avoir un example de compilation de logiciels portés dans une arborescence en lecture seule). example of building ports from a read-only tree). S'il vous faut modifier un fichier dans PKGDIR, faites-le en redéfinissant une variable, non en l'écrasant. <makevar>WRKDIRPREFIX</makevar> Veillez à utiliser WRKDIRPREFIX. Cela ne concerne pas la plupart des logiciels portés. Mais, en particulier si vous faites référence au WRKDIR d'un autre logiciel, notez que la référence correcte est WRKDIRPREFIXPORTSDIR/sous-répertoire/nom/work et non PORTSDIR/sous-répertoire/nom/work ou .CURDIR/../../sous-répertoire/nom/work ou autre chose encore. Par ailleurs, si vous définissez vous-même WRKDIR, veillez à bien le faire commencer par ${WKRDIRPREFIX}${.CURDIR}. Distinguer les systèmes d'exploitation et leurs versions Vous pouvez tomber sur du code qui doit être modifié ou compilé conditionnellement selon la version d'Unix sur laquelle il s'exécutera. Si vous avez besoin de faire ce type de modifications du code ou de mettre en place une compilation conditionelle, veillez à ce que vos modifications soient aussi générales que possible, de sorte que nous puissions rétroporter le code sur les systèmes FreeBSD 1.x et le porter sur les autres systèmes BSD tels que 4.4BSD du CSRG, BSD/386, 386BSD, NetBSD et OpenBSD. La solution appropriée pour distinguer 4.3BSD/Reno(1990) et les versions ultérieures de BSD est d'utiliser la macro-instruction BSD définie dans <sys/param.h>. Avec de la chance, ce fichier est déjà inclus; si ce n'est pas le cas, ajoutez : #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif à l'endroit voulu dans le fichier .c. Nous estimons que tous les systèmes qui définissent ces deux symboles disposent d'un sys/param.h. Si vous tombez sur un système pour lequel ce n'est pas le cas, nous aimerions le savoir. Envoyez un courrier électronique à la &a.ports;. L'autre moyen est d'utiliser le style GNU autoconf de faire ce genre de choses : #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif N'oubliez pas d'ajouter -DHAVE_SYS_PARAM_H à CFLAGS dans le Makefile dans ce cas. Une fois que vous avez inclus sys/param.h vous pouvez utiliser : #if (defined(BSD) && (BSD >= 199103)) pour savoir si le code est compilé sur un système basé sur 4.3 Net2 ou sur une version ultérieure (e.g., FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 et antérieurs). Utilisez : #if (defined(BSD) && (BSD >= 199306)) pour savoir si le code est compilé sur un système basé sur 4.4 ou sur une version ultérieure (e.g., FreeBSD 2.x, 4.4, NetBSD 1.0, 386BSD, BSD/386 2.0 et ultérieurs). La macro-instruction BSD prend la valeur 199506 lorsque le code est basé sur 4.4BSD-Lite2. Ceci n'est donné qu'à titre d'information et ne doit pas être utilisé pour distinguer les versions de FreeBSD basées sur 4.4-Lite de celles qui ont intégré les modifications introduites avec 4.4-Lite2. Il faut utiliser pour cela la macro-instruction __FreeBSD__. Utilisez avec modération : __FreeBSD__ est définie dans toutes les versions de FreeBSD. Utilisez-la si vos modifications ne concernent que FreeBSD. Des trucs de portage tel que remplacer strerror() par sys_errlist[] sont propres aux systèmes Berkeley, et non à FreeBSD. Sous FreeBSD 2.x, __FreeBSD__ prend la valeur 2. Dans les versions antérieures, elle vaut 1. Les versions suivantes l'augmenteront pour qu'elle soit égale à leur numéro de version majeure. Si vous avez besoin de faire la différence entre un système FreeBSD 2.x et un système 3.x, la bonne manière de faire est normalement d'utiliser les macros-instructions BSD décrites plus haut. S'il y a effectivement des modifications spécifiques à FreeBSD (une option particulière pour une bibliothèque partiagée avec ld), vous pouvez alors à juste titre utiliser __FreeBSD__ et #if __FreeBSD__ > 1 pour tester s'il s'agit d'un système FreeBSD 2.x ou ultérieur. Si vous avez besoin d'une particularisation plus fine des systèmes FreeBSD à partir de 2.0-release, vous pouvez vous servir de : #if __FreeBSD__ >= 2 #include <osreldate.h> # if __FreeBSD_version >= 199504 /* code propre à la version 2.0.5 et ultérieures */ # endif #endifi Version de FreeBSD __FreeBSD_version 2.0-RELEASE 119411 2.1-CURRENTs 199501, 199503 2.0.5-RELEASE 199504 2.2-CURRENT avant 2.1 199508 2.1.0-RELEASE 199511 2.2-CURRENT aprè 2.1.5 199512 2.1.5-RELEASE 199607 2.2-CURRENT aprés 2.1.6 199608 2.1.6-RELEASE 199612 2.1.7-RELEASE 199612 2.2-RELEASE 220000 2.2.1-RELEASE 220000 (pas de changement) 2.2-STABLE after 2.2.1-RELEASE 220000 (pas de changement) 2.2-STABLE après introduction de texinfo-3.9 221001 2.2-STABLE après introduction de top 221002 2.2.2-RELEASE 222000 2.2-STABLE après 2.2.2-RELEASE 222001 2.2.5-RELEASE 225000 2.2-STABLE après 2.2.5-RELEASE 225001 2.2-STABLE après fusion avec ldconfig -R 225002 2.2.6-RELEASE 226000 2.2.7-RELEASE 227000 2.2-STABLE après 2.2.7-RELEASE 227001 2.2-STABLE après modification de semctl 2 227002 2.2.8-RELEASE 228000 2.2-STABLE après 2.2.8-RELEASE 228001 3.0-CURRENT avant modification de mount 2 300000 3.0-CURRENT après modification de mount 2 change 300002 3.0-CURRENT après modification des arguments de ioctl 300003 3.0-CURRENT après conversions au format ELF 300004 3.0-RELEASE 300005 3.0-CURRENT après 3.0-RELEASE 300006 3.0-STABLE après introduction de la branche 4.x 300007 3.1-RELEASE 310000 3.1-STABLE après 3.1-RELEASE 310001 4.0-CURRENT après introduction de la branche 4.x 400000 Remarquz que 2.2-stable s'identifie parfois elle-même comme “2.2.5-stable” après la 2.2.5-release. La clé était autrefois l'année suivie du mois, mais nous avons décidé d'en changer pour un système plus explicite constitué des numéros de versions majeure et mineure à partir de la 2.2. Cela parce que le développement parallèle sur plusieurs branches rendait impossible le classement des versions simplement par leur date effective de livraison. Si vous portez aujourd'hui un logiciel, vous n'avez pas à vous soucier des anciennes versions -currents; elles ne sont mentionnées ici qu'à titre de référence. Dans les centaines de logiciels qui ont été portés, il n'y a qu'un ou deux cas où il fallait effectivement utiliser __FreeBSD__. Ce n'est pas parce qu'un portage antérieur n'a pas été bien fait et s'en est servi à tort qu'il faut perséverer. Mettre quelque chose après <filename>bsd.port.mk</filename> Ne mettez rien après la ligne .include <bsd.port.mk>. Cela peut être le plus souvent évité en incluant bsd.port.pre.mk quelque part au milieu de votre Makefile et bsd.port.post.mk à la fin. Vous devez inclure soit le couple pre.mk/post.mk soit bsd.port.mk uniquement; ne mélangez pas les deux. bsd.port.pre.mk ne définit que quelques variables, qui peuvent être testées dans le Makefile, bsd.port.post.mk prend en charge tout le reste. Voici quelques unes des variables importantes qui sont définies dans bsd.port.pre.mk (ce n'est pas une liste exhaustive, reportez-vous s'il vous plaît à bsd.port.mk pour avoir une liste complète). Variable Description ARCH L'architecture sous le même forme que le résultat de uname -m (e.g., i386) OPSYS Le système d'exploitation, sous le même forme que le résultat de la commande uname -s (e.g., FreeBSD) OSREL La version du système d'exploitation (e.g., 2.1.5 ou 2.2.7) OSVERSION La version sous forme numérique du système d'exploitation, identique à __FreeBSD_version. PORTOBJFORMAT Le format “objet” du système (aout or elf) LOCALBASE La racine de l'arborescence “locale” (e.g., /usr/local/) X11BASE La racine de l'arborescence “X11” (e.g., /usr/X11R6) PREFIX Où le logiciel s'installe lui-même (Reportez-vous à la section PREFIX pour plus d'informations). Si vous avez besoin de définir les variables USE_IMAKE, USE_X_PREFIX ou MASTERDIR, faites-le avant d'inclure bsd.port.pre.mk. Voici quelques exemples de ce que vous pouvez mettre après bsd.port.pre.mk : # il est inutile de compiler lang/perl5 si perl5 fait déjà partie du système .if ${OSVERSION} > 300003 BROKEN= perl fait partie du système .endif # un seule numéro de version de bibliothèque partagée en ELF .if ${PORTOBJFORMAT} == "elf" TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR} .else TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif # le logiciel fait déjà les liens pour ELF, mais pas pour a.out post-install: .if ${PORTOBJFORMAT} == "aout"         ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so .endif Installer des documentations supplémentaires Si votre logiciel à porter est accompagné d'autres documentations que les habituelles pages de manuel ou “info”, que vous trouvez utiles, installez-les dans PREFIX/share/doc. Vous pouvez le faire de même, comme expliqué plus haut avec la cible post-install. Créez un nouveau sous-répertoire pour votre logiciel à porter. Le nom de ce sous-répertoire devrait faire référence à son contenu. Cela signifie la plupart du temps que ce sera le PKGNAME sans le numéro de version. Si vous pensez toutefois que l'utilisateur voudra peut-être installer différentes versions du logiciel, utilisez alors le PKGNAME complet. Paramétrez l'installation en utilisant la variable NOPORTDOCS pour que les utilisateurs puissent ne pas installer ces documentations, en se servant de /etc/make.conf, s'ils le souhaitent, comme suit : post-install: .if !defined(NOPORTDOCS)         ${MKDIR}${PREFIX}/share/doc/xv         ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif N'oubliez pas de les ajouter aussi à pkg/PLIST ! (Ne vous souciez pas ici de NOPORTDOCS; il n'y a aujourd'hui aucun moyen pour que les procédures d'installation des logiciels précompilés lisent les variables de /etc/make.conf.) Vous pouvez aussi vous servir du fichier pkg/MESSAGE pour afficher des messages à l'installation. Reportez-vous à la section sur l'utilisation de pkg/MESSAGE pour plus d'informations. Il n'y a pas besoin d'ajouter MESSAGE à pkg/PLIST. <makevar>DIST_SUBDIR</makevar> Evitez que votre logiciel n'encombre /usr/ports/distfiles. S'il doit rapatrier de nombreux fichiers ou comporte un fichier dont le nom est déjà utilisé par un autre logiciel (e.g., Makefile), donnez à DIST_SUBDIR le nom du logiciel (PKGNAME sans le numéro de version devrait faire l'affaire). Cela modifiera DISTDIR de /usr/ports/distfiles par défaut, en /usr/ports/distfiles/DIST_SUBDIR et mettra effectivement tout ce dont a besoin votre logiciel à porter dans ce sous-répertoire. Le sous-répertoire du même nom sur le site principal de secours ftp.freebsd.org sera aussi consulté (Positionner explicitement DISTDIR dans votre Makefile n'aboutira pas au même résultat, utilisez s'il vous plaît DIST_SUBDIR.) Cela n'a pas d'effet sur les MASTER_SITES que vous définissez dans votre Makefile. Informations sur le paquetage Ne mettez pas les informations sur le paquetage, i.e. COMMENT, DESCR et PLIST dans pkg. Notez bien que ces fichiers ne sont plus utilisés uniquement pour la version précompilée et sont maintenant indispensables, même si la variable NO_PACKAGE est définie. Chaînes RCS Ne mettez pas les chaînes RCS dans les fichiers de mise à niveau - patches. CVS les modifiera quand nous mettrons les fichiers dans l'arborescence des logiciels portés et de nouveau lorsque nous les extrairons ensuite et les mises à jour échouerons. Les chaînes RCS sont encadrées par des caractères “dollar” ($), et commencent typiquement par $Id ou $RCS. “diff” récursifs Il est bien d'utiliser la récursivité () avec diff pour générer les fichiers de mise à jour, mais examinez s'il vous plaît le résultat pour vous assurer qu'il n'est pas pollué par trop de choses inutiles. En particulier, les deltas entre fichiers dupliqués pour sauvegarder la version originale, les Makefiles alors que le logiciel à porter utilise Imake ou GNU configure, etc., sont inutiles et doivent être supprimés. Si vous avez dû modifier configure.in et utiliser autoconf pour mettre à jour configure, n'incluez pas le delta pour configure (il contient souvent plusieurs centaines de lignes !) ; définissez USE_AUTOCONF=yes et donnez les deltas pour configure.in. Si vous avez par ailleurs eu à supprimer un fichier, vous pouvez le faire avec la cible post-extract plutôt qu'en vous servant du fichier de mise à jour. Une fois que le delta vous convient, découpez-le s'il vous plaît pour qu'il y ait un fichier de mise à jour pour chaque fichier source. <makevar>PREFIX</makevar> Faites en sorte que votre logiciel s'installe sous l'arborescence PREFIX. (Cette variable prend la valeur de LOCALBASE (par défaut /usr/local), à moins que USE_X_PREFIX ou USE_IMAKE ne soient définies, auquel cas ce sera X11BASE (par défaut /usr/X11R6).) Le fait de ne coder nulle part en dur /usr/local ou /usr/X11R6 dans le source rend le portage plus souple et facilite son adaptation aux besoins d'autres sites. Pour les logiciels X qui se servent de imake, c'est automatique; dans les autres cas, il suffit souvent de faire en sorte que /usr/local (ou /usr/X11R6 pour les logiciels X qui n'utilisent pas imake) soit remplacé par la valeur de PREFIX dans les différentes procédures et Makefiles du logiciel, puisque cette variable est toujours transmise à chaque étape du processus de compilation et d'installation. N'utilisez pas USE_X_PREFIX à mois d'en avoir vraiment besoin (i.e., l'édition de liens utilise les bibliothèques X ou vous avez besoin de faire référence à des fichiers de X11BASE). La variable PREFIX peut être redéfinie dans votre Makefile ou dans l'environnement de l'utilisateur. Il est néanmoins fortement déconseillé de la définir explicitement dans les Makefiles de logiciels. Utilisez aussi les variables précédentes pour faire référence à des programmes ou fichiers d'autres logiciels portés et non en donnant les chemins d'accès complets. Par exemple, si votre logiciel a besoin que la macro-instruction PAGER donne le chemin d'accès à less, utilisez l'indicateur : -DPAGER=\"${PREFIX}/bin/less\" du compilateur, ou : -DPAGER=\"${LOCALBASE}/bin/less\" si c'est un logiciel X, au lieu de -DPAGER=\"/usr/local/bin/less\". Cela aura plus de chances de marcher si votre administrateur système a déplacé toute l'arborescence /usr/local ailleurs. Sous-répertoires Essayez de faire en sorte que le logiciel à porter installe ses fichiers dans les bons sous-répertoires de PREFIX. Certains logiciels regroupent tout dans un sous-répertoire portant le nom du logiciel, ce qui est incorrect. De nombreux logiciels mettent aussi tout, sauf les binaires, fichiers d'en-tête et pages de manuel dans un sous-répertoire de lib, ce qui ne fait pas bon ménage avec le paradigme BSD. La plupart des fichiers doivent être déplacés vers : etc (fichiers d'initialisation et de configuration), libexec (exécutables démarrés par le système), sbin (exécutables pour les super-utilisateurs/administrateurs), info (documentations au format “info”) ou share (fichiers indépendants de l'architecture). Reportez-vous aux pages de manuel de &man.hier.7; pour plus de détails au sujet des règles qui régissent /usr, la plus grande partie s'applique aussi à /usr/local. Les logiciels en rapport avec les “news” USENET font exception. Ils peuvent se servir de PREFIX/news pour y mettre leurs fichiers. Supprimer les répertoires vides Faites en sorte que le logiciel fasse le ménage lors de sa désinstallation. Cela se fait habituellement en ajoutant des lignes @dirrm pour tous les répertoires spécifiquement créés par le logiciel. Il faut supprimer les sous-répertoires avant de supprimer leurs répertoires parents.  : lib/X11/oneko/pixmaps/cat.xpm lib/X11/oneko/sounds/cat.au  : @dirrm lib/X11/oneko/pixmals @dirrm lib/X11/oneko/sounds @dirrm lib/X11/oneko Il arrive parfois que @dirrm émette un message d'erreur parce que d'autres logiciels partagent le même sous-répertoire. Vous pouvez invoquer rmdir depuis @unexec pour ne supprimer que les sous-répertoires vides sans messages d'avertissement. @unexec rmdir %D/share/doc/gimp 2>/dev/null || true Il n'y aura alors ni message d'erreur, ni fin anormale de pkg_delete même si PREFIX/share/doc/gimp n'est pas vide parce que d'autres logiciels y ont installé des fichiers. <literal>UID</literal>s Si votre logiciel a besoin qu'un utilisateur particulier existe sur le système, appelez pw dans la procédure pkg/INSTALL pour le créer automatiquement. Voyez net/cvsup-mirror pour avoir un exemple. Si votre logiciel à porter a besoin du même IDdentifiant d'utilisateur/groupe qui a servi à sa compilation quand on installe le paquetage binaire, vous devez choisir un UID libre entre 50 et 99 et l'enregistrer ci-dessous. Voyez japanese/Wnn pour avoir un exemple. Veillez à ne pas utiliser un UID déjà employé par le système ou d'autres logiciels. Voici la liste des UIDs entre 50 et 99. majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent wnn:*:69:7:Wnn:/nonexistent:/nonexistent ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent qmaill:*:83:81:QMail user:/var/qmail:/nonexistent qmaild:*:82:81:QMail user:/var/qmail:/nonexistent qmailq:*:85:82:QMail user:/var/qmail:/nonexistent qmails:*:87:82:QMail user:/var/qmail:/nonexistent qmailp:*:84:81:QMail user:/var/qmail:/nonexistent qmailr:*:86:82:QMail user:/var/qmail:/nonexistent msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh Signalez s'il vous plaît que vous réservez un UID ou GID dans cette plage, quand vous soumettez un logiciel (ou une mise à niveau). Cela nous permet de tenir à jour la liste des IDs réservés. Faites les choses rationnellement Le Makefile doit faire des choses simples et logiques. Si vous pouvez le raccourcir et le rendre plus lisible, faites-le. Utilisez par exemple un instruction .if de make, au lieu d'un if de l'interpréteur de commandes, ne redéfinissez pas do-extract si vous pouvez utiliser EXTRACT* à la place et servez-vous de GNU_CONFIGURE au lieu de CONFIGURE_ARGS += --prefix=${PREFIX}. Prennez en compte <makevar>CFLAGS</makevar> Le logiciel à porter doit prendre en considération CFLAGS. Si ce n'est pas le cas, ajoutez s'il vous plaît NO_PACKAGE=ignores cflags au Makefile. Fichiers de Configuration Si votre logiciel a besoin de fichiers de configuration dans PREFIX/etc, ne les installez pas et ne les listez pas dans pkg/PLIST. pkg_delete supprimerait alors des fichiers renseignés avec soin par les utilisateurs et une réinstallation les écraserait. Au lieu de cela, installez des fichiers d'exemple avec un suffixe (nom_de_fichier.sample fonctionnera bien) et affichez un message pour signaler à l'utilisateur qu'il devra copier et modifier le fichier pour que le logiciel soit utilisable. Portlint Contrôlez votre travail avec portlint avant de le soumettre ou de le mettre dans l'arborescence des sources. Retours d'information Envoyez vos modifications et mises à niveau à l'auteur ou au responsable de la maintenance pour qu'il les inclue dans la prochaine version du code. Cela ne fera que vous faciliter le travail pour la prochaine fois. Divers Les fichiers pkg/DESCR, pkg/COMMENT et pkg/PLIST doivent chacun être revérifiés. Si vous passez un logiciel en revue et pensez qu'ils peuvent être mieux étre mieux écrits, faites-le. Ne mettez pas de nouvelles copies de la Licence Publique Générale GNU - GPL - sur notre système, s'il vous plaît. Notez s'il vous plaît soigneusement toutes les considérations d'ordre légal. Ne nous laissez pas distribuer illégalement du logiciel ! Si vous êtes bloqué… Consultez les exemples existants et bsd.port.mk avant de nous poser des questions ! ;) Posez-nous des questions si vous avez des problèmes ! Ne vous cognez pas la tête contre les murs ! :) Un exemple de <filename>Makefile</filename> Voici un exemple de Makefile dont vous pouvez vous servir pour porter un nouveau logiciel. Veillez à supprimer les commentaires excédentaires (ceux qui sont entre crochets) ! Il est souhaitable que vous respectiez ce format (ordre des variables, espacements entre sections, etc.). Il est conçu pour qu'il soit facile de repérer les informations les plus importantes. Nous vous recommandons d'utiliser portlint pour vérifier le Makefile. [l'en-tête...pour qu'il nous soit plus facile d'identifier les logiciels.] # New ports collection makefile for: xdvi [l'en-tête de version obligatoire doit être mise à jour  en même temps que le logiciel.] # Version required: pl18 [des choses du genre "1.5alpha" conviennent aussi] [C'est la date de création de la première version de ce Makefile.  Ne la modifiez jamais lors d'une mise à jour.] # Date created: 26 May 1995 [C'est la personne qui a fait le premier portage sous FreeBSD, en particulier,  celle qui a écrit la première version de ce Makefile. Rappelez-vous  que vous ne devez plus modifier ce nom par la suite.] # Whom: Satoshi Asami <asami@FreeBSD.ORG> # # $Id$ [ ^^^^ Ce sera automatiquement remplacé par la chaîne RCS par CVS  ensuite, lors de l'intégration à nos archives.] # [Cette section décrit le logiciel et le site d'origine - DISTNAME  viens toujours en premier, suivi de PKGNAME (si nécessaire), CATEGORIES,  puis de MASTER_SITES, qui peut être suivi de MASTER_SITE_SUBDIR.  EXTRACT_SUFX ou DISTFILES peuvent éventuellement être précisés ensuite.] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [N'oubliez pas le “slash” ("/") à la fin !  si vous ne vous servez pas des macros-instructions MASTER_SITE_*] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [A définir si le source n'est pas au format ".tar.gz"] EXTRACT_SUFX= .tar.Z [Section pour les mises à jour de la distribution -- peut être vide] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [Responsable de la maintenance; *obligatoire* ! C'est la personne  (de préférence avec les droits d'écriture sur l'arborescence  des sources) que les utilisateurs peuvent contacter si questions ou rapports  d'anomalie - ce doit être la personne qui a fait le portage ou quelqu'un  qui peut lui transmettre les questions dans un délai raisonnable. Si vous  ne voulez vraimant pas que votre adresse apparaisse ici, mettez  "ports@FreeBSD.ORG".] MAINTAINER= asami@FreeBSD.ORG [Dépendances -- peuvent être vides] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm [Cette section est réservée aux autres variables bsd.port.mk  qui n'ont pas leur place dans les sections précédentes] [S'il y a des questions lors de la configuration, de la compilation,  de l'installation ...] IS_INTERACTIVE= yes [Si l'extraction se fait dans un autre répertoire que ${DISTNAME}...] WRKSRC= ${WRKDIR}/xdvi-new [Si les mises à jour de la distribution ne sont pas relatives à ${WRKSRC},  vous devrez peut-être utiliser cette variable] PATCH_DIST_STRIP= -p1 [S'il faut exécuter une procédure "configure" générée par GNU autoconf] GNU_CONFIGURE= yes [S'il faut compiler avec GNU make, et non /usr/bin/make, ...] USE_GMAKE= yes [Si c'est une application X et qu'il faut utiliser "xmkmf -a" ...] USE_IMAKE= yes [et cetera.] [Variables non-standard pour les règles qui les suivent] MY_FAVORITE_RESPONSE= "oui, pour sûr" [Les règles particulières, dans l'ordre où faut les appeler] pre-fetch:         Ouais, il faut récupérer quelque chose post-patch:         Génial, j'ai quelque chose à faire après la mise à jour pre-install:         et d'autres choses encore après l'installation [et l'épilogue] .include <bsd.port.mk> Noms des paquetages Voici les conventions à respecter pour les noms des paquetages. Cela pour qu'il soit facile de parcourir notre répertoire des paquetages, parce qu'il y en a déjà beaucoup et que cela va rebuter les utilisateurs s'ils s'y usent les yeux ! Le nom du paquetage doit être de la forme langue-nom-particularités.de.compilation-numéros.de.version. Si votre DISTNAME n'est pas de ce type, définissez PKGNAME en respectant ce format. FreeBSD essayer d'intégrer les supports des langues maternelles de ses utilisateurs. Le préfixe langue- doit être le sigle de deux lettres défini par la convention ISO-639, si le logiciel est propre à une langue particulière. Par exemple, ja pour le Japonais, ru pour le Russe, vi pour le Vietnamien, zh pour le Chinois, ko pour le Coréen et de pour l'Allemand. Le nom doit toujours être en minuscules, sauf pour les paquetages particulièrement importants (qui comportent de nombreux programmes). XFree86 ou ImageMagick par exemple appartiennent à cette catégorie. Sinon, mettez le nom (ou au moins la première lettre) en minuscules. Si les majuscules ont un sens dans le nom (par exemple pour les noms d'une seule lettre comme R ou V), vous pouvez utiliser des majuscules si vous le souhaitez. Il est de tradition d'appeler les modules Perl 5 en les faisant précéder de p5- et en remplaçant les deux deux-points par un tiret; par exemple, le module Data::Dumper devient p5-Data-Dumper. S'il y a des numéros, tirets ou soulignés dans le nom, vous pouvez aussi les conserver (par exemple, kinput2). Si le logiciel peut-être compilé avec différentes valeurs par défaut codées en dur (ce qui fait d'habitude partie du nom de répertoire d'une famille de logiciels), les -particularités.de.compilation doivent indiquer quelles sont ces valeurs (le tiret n'est pas obligatoire). On peut donner en exemple la résolution des polices ou le format de papier. La version doit être une suite d'entiers séparés par des points ou un unique caractère alphabétique. La seule exception concerne la chaîne pl (“patchlevel” - niveau de mise à jour), qui ne peut être utilisée que lorsque qu'il n'y a pas de numéros de version majeure et mineure du logiciel. Voici quelques exemples (réels) de la manière de convertir un DISTNAME en un PKGNAME : Nom de la Distribution Nom du Paquetage Raison mule-2.2.2. mule-2.2.2 Pas de changement nécessaire XFree86-3.1.2 XFree86-3.1.2 Pas de changement nécessaire EmiClock-1.0.2 emiclock-1.0.2 Pas de majuscules pour les programmes individuels gmod1.4 gmod-1.4 Il faut un tiret avant les numéros de version xmris.4.0.2 xmris-4.0.2 Il faut un tiret avant les numéros de version rdist-1.3alpha rdist-1.3a Les chaînes de caractères comme alpha ne sont pas autorisées es-0.9-beta1 es-0.9b1 Les chaînes de caractères comme beta ne sont pas autorisées v3.3beta021.src tiff-3.3 C'était quoi exactement ? tvtwm tvtwm-pl11 Il doit toujours y avoir une version piewm piewm-1.0 Il doit toujours y avoir une version xvgr-2.10pl1 xvgr-2.10.1 pl n'est autorisé que lorsqu'il n'y a pas de numéro de version majeure/mineure gawk-2.15.6 ja-gawk-2.15.6 Version Japonaise psutils-1.13 psutils-letter-1.13 Taille de page en dur à la compilation pkfonts pkfonts300-1.0 Paquetage pour les polices 300dpi S'il n'y a nulle part d'information sur la version et qu'il y a peu de chances que l'auteur sorte une nouvelle version, prennez 1.0 comme numéro de version (comme pour piewm ci-dessus). Sinon, posez la question à l'auteur ou servez-vous de la date (aa.mm.jj) comme version. Catégories Comme vous le savez déjà, les logiciels portés sont répartis en différentes catégories. Mais, il est important, pour que cette classification fonctionne, que les responsables des portages et les utilisateurs comprennent ce qu'est chaque catégorie et comment nous choisissons la catégorie dans laquelle nous classons un logiciel. Liste actuelle des catégories Voici tout d'abord la liste des catégories à ce jour. Celles qui sont suivies d'une astérisque (*) sont des catégories virtuelles—il n'y a pas de sous-répertoires correspondant dans le catalogue des logiciels portés. Pour les catégories réelles, il y a une ligne de description dans le fichier pkg/COMMENT du sous-répertoire correspondant (e.g., archivers/pkg/COMMENT). Catégorie Description afterstep* Logiciels pour le gestionnaire de fenêtres AfterStep archivers Outils d'archivage astro Logiciels d'astronomie audio Son benchmarks Outils de mesure de performances biology Logiciels en rapport avec la biologie cad Conception assistée par ordinateur chinese Support de la langue Chinoise comms Logiciels de communication. Essentiellement des logiciels qui dialoguent avec votre port série converters Convertisseurs de codes de caractéres databases Bases de données deskutils Ce que l'on avait sur son bureau avant l'invention des ordinateurs devel Outils de développement. N'y mettez pas de bibliothèques simplement parce que ce sont des bibliothèques—à moins qu'elles n'aient vraiment pas leur place ailleurs, elles ne doivent pas être dans cette catégorie editors Editeurs généraux. Les éditeurs spécialisés vont dans la catégorie correspondante (e.g., un éditeur de formules mathématiques ira dans math) elisp Logiciels Emacs-lisp emulators Emulateurs d'autres systèmes d'exploitation. Les émulateurs de terminaux ne rentrent pas dans cette catégorie—ceux pour X vont dans x11 et les émulateurs en mode texte dans comms ou misc, selon leur fonction exacte games Jeux german Support de la langue Allemande graphics Utilitaires graphiques japanese Support de la langue Japonaise kde* Logiciels qui constituent “K Desktop Environment” (kde) korean Support de la langue Coréenne lang Langages de programmation mail Logiciels de courrier électronique math Logiciels de calcul numérique et autres outils mathématiques mbone Applications MBone misc Utilitaires variés—essentiellement ceux qui n'ont pas leur place ailleurs. C'est la seul catégorie qui ne doit pas apparaître en même temps qu'une autre catégorie non virtuelle. S'il y a misc et autre chose dans votre ligne CATEGORIES, cela signifie que vous pouvez sans risque supprimer misc et mettre le logiciel dans cet autre sous-répertoire net Outils réseau divers news Logiciels pour les listes de discussion USENET offix* Logiciels de la suite OffiX palm Logiciels à utiliser avec la gamme 3Com Palm(tm) perl5* Logiciels qui nécessitent Perl version 5 plan9* Programmes divers de Plan9. print Logiciels d'impression. Les logiciels de publication (prévisualiseurs, etc.) appartiennent aussi à cette catégorie python* Logiciels écrits en Python russian Support de la langue Russe security Outils de sécurité shells Interpréteurs de commandes sysutils Utilitaires système tcl75* Logiciels qui nécessitent Tcl 7.5 tcl76* Logiciels qui nécessitent Tcl 7.6 tcl80* Logiciels qui nécessitent Tcl 8.0 tcl81* Logiciels qui nécessitent Tcl 8.1 textproc Outils de traitement de texte, sauf les logiciels de publication assistée par ordinateur, qui vont dans print/ tk41* Logiciels qui nécessitent Tk 4.1 tk42* Logiciels qui nécessitent Tk 4.2 tk80* Logiciels qui nécessitent Tk 8.0 tk81* Logiciels qui nécessitent Tk 8.1 vietnamese Support de la langue Vietnamienne windowmaker* Logiciels pour le gestionnaire de fenêtres WindowMaker www Logiciels en rapport avec le World Wide Web. Ce qui concerne le langage HTML a aussi sa place ici x11 Le système X window et consorts. Cette catégorie ne concerne que les logiciels directement en rapport avec X Window. N'y mettez pas les applications X ordinaires. Si votre logiciel est une application X, définissez USE_XLIB (implicite avec USE_IMAKE) et mettez le dans la catégorie appropriée. Un grand nombre d'entre eux vont dans les autres catégories x11-* (voir plus bas) x11-clocks Horloges X11 x11-fm Gestionnaires de fichiers X11 x11-fonts Polices de caractères X11 et outils associés x11-toolkits Boîtes à outils X11 x11-wm Gestionnaires de fenêtres X11 Choisir la bonne catégorie Comme de nombreuses catégories ont des logiciels en commun, vous devez souvent décider laquelle sera la catégorie principale de votre logiciel. Voici une liste de priorités, par ordre décroissant : Les catégories liées à la langue viennent en premier. Par exemple, si vous installez des polices X11 Japonaise, alors vous mettrez japanese x11 dans votre ligne CATEGORIES. Les catégories les plus spécifiques viennent avant celles qui le sont moins. Par exemple, un éditeur HTML doit être listé dans www editors, et non l'inverse. Vous n'avez par ailleurs pas besoin de mettre net si le logiciel appartient à l'une des catégories mail, mbone, news, security ou www. x11 n'est une catégorie secondaire que lorsque la catégorie principale est une langue nationale. En particulier, il ne faut pas mettre x11 pour les applications X. Si votre logiciel ne va vraiment nulle part ailleurs, mettez-le dans misc. SI vous n'êtes pas sûr de la catégorie, mettez s'il vous plaît un commentaire à ce sujet lorsque vous soumettez votre send-pr pour que nous puissions en discuter avant de l'intégrer. (Si vous avez l'accès en écriture, envoyez une note à &a.ports; pour qu'il y ait discussion au préalable—les nouveaux logiciels sont trop souvent importés dans la mauvaise catégorie et doivent être déplacés immédiatement après.) Modifications de ce document et du système des logiciels portés Si vous maintenez de noombreux logiciels portés, vous devriez vous abonner à &a.ports;. Les modifications importantes au fonctionnement du catalogue des logiciels portés y seront annoncées. Vous aurez toujours des informations plus détaillées sur les dernières modifications en consultant les traces CVS pour bsd.port.mk. That is It, Folks! C'est vraiment un long chapitre, n'est-ce-pas ? Merci de nous avoir suivi jusqu'ici. Vous savons donc maintenant comment porter un logiciel. Allons-y et convertissons le monde entier en logiciel portés ! C'est la façon la plus simple de commencer à contribuer au projet FreeBSD ! :) diff --git a/fr_FR.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml index 4ca6f4bf84..5b88098fe6 100644 --- a/fr_FR.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml @@ -1,2783 +1,2781 @@ PPP et SLIP &trans.a.haby; Si vous vous connectez à l'Internet avec un modem ou si vous voulez offrir à d'autres la possibilité de se connecter à l'Internet par l'intermédiaire d'un système FreeBSD, vous pouvez utiliser PPP ou SLIP. Il y a par ailleurs deux versions de PPP: en mode utilisateur (aussi appelé iijppp) et intégré au noyau. Ce chapitre décrit les procédures de configuration des deux variantes de PPP et de mise en oeuvre de SLIP. Configurer PPP en mode utilisateur La version utilisateur de PPP est apparue avec la version 2.0.5 de FreeBSD en supplément à l'implémentation existante de PPP dans le noyau. Qu'a donc de différent cette nouvelle version de PPP qui justifie son ajout? Pour citer les pages de manuel:
Ceci est le logiciel PPP sous forme de processus utilisateur. PPP est normalement implémenté dans le noyau (e.g. le “démon” pppd) et est alors plus difficile à déboguer ou à modifier. A l'inverse, la présente implémentation se présente sous forme de processus utilisateur utilisant le pilote de périphérique “tunnel” (tun).
Cela signifie essentiellement qu'au lieu de lancer un “démon” PPP, le programme ppp peut être exécuté quand et de la façon que l'on veut. Il n'y a pas besoin de compiler d'interface PPP dans le noyau, parce que le programme peut utiliser le pilote “tunnel” générique pour échanger des données avec le noyau. A partir de maintenant, le programme utilisateur ppp sera simplement appelé ppp, à moins qu'il ne faille explicitement faire la distinction entre lui et d'autres logiciels PPP client/serveur comme pppd. Sauf indications contraires, toutes les commandes mentionnées dans cette section doivent être exécutées par le super-utilisateur root. Il y a de nombreuses améliorations dans la version 2 de ppp. Vous pouvez savoir quelle est la version que vous utilisez en lançant ppp sans argument et en tapant show version à l'invite. Il est facile de passer à la version la plus récente de ppp (sur n'importe quelle version de FreeBSD) en téléchargeant la dernière version archivée sur www.Awfulhak.org. Avant de commencer Ce document suppose que vous en êtes à peu près à ce point: Vous avez un compte chez un fournisseur d'accès Internet (FAI) qui vous permet d'utiliser PPP. Vous avez de plus un modem (ou un autre périphérique) installé et correctement configuré avec lequel vous pouvez vous connecter chez votre fournisseur d'accès. Vous devrez avoir les informations suivantes à portée de main: Le(s) numéro(s) de téléphone de votre fournisseur d'accès. Votre identifiant utilisateur et votre mot de passe. Selon le cas, ce seront soit un identifiant et un mot de passe Unix classiques, soit un identifiant et un mot de passe PPP PAP ou CHAP. Les adresses IP d'un ou plusieurs serveurs de noms de domaines. Votre fournisseur doit normalement vous donner deux adresses IP. Vous devez avoir cette information pour PPP version 1.x, à moins que vous n'ayez votre propre serveur de noms de domaines. A partir de la version 2, PPP supporte la négociation des adresses des serveurs de noms. Si votre fournisseur dispose de cette fonctionnalité, alors la commande enable dns dans votre fichier de configuration dit à PPP de définir à votre place les serveurs de noms. Les informations suivantes vous ont peut-être aussi été données par votre fournisseur d'accès, mais ce n'est pas absolument indispensable: L'adresse IP de la passerelle de votre fournisseur. La passerelle est la machine à laquelle vous vous connecterez et qui deviendra votre route par défaut - “default route”. S'il ne vous l'a pas donnée, vous pouvez en fabriquer une et le serveur PPP de votre fournisseur vous donnera l'adresse exacte quand vous vous connecterez. ppp connaît ce numéro IP sous l'appellation HISADDR. Le masque de sous-réseau de votre fournisseur d'accès. S'il ne vous l'a pas donné, vous pouvez sans risque utiliser la valeur 255.255.255.0. Si votre fournisseur vous procure une adresse IP fixe et un nom de machine, vous pouvez aussi introduire ces informations dans votre configuration. Sinon, nous le laisserons simplement nous attribuer l'adresse IP qui lui convient. Si vous n'avez pas l'une des informations requises, contactez votre fournisseur et assurez-vous qu'il vous la donne. Compiler un noyau pour ppp Comme on l'a vu dans la description qu'en donnent les pages de manuel, ppp utilise le pilote tun du noyau. Il faut vous assurez que le support de ce pseudo-périphérique est bien inclus dans votre noyau. Pour cela, allez dans votre répertoire de configuration du noyau (/sys/i386/conf ou /sys/pc98/conf) et consultez votre fichier de configuration. Il doit comporter quelque part la ligne pseudo-device tun 1 Elle figure en standard dans le noyau GENERIC, donc, si vous n'avez pas installé de noyau sur-mesure ou n'avez pas de répertoire /sys, vous n'avez rien à changer. Si la ligne n'est pas dans le fichier de configuration de votre noyau, ou si vous avez besoin de plus d'un périphérique tun (par exemple, si vous installez un serveur qui puisse fournir 16 connexions simultanées vers l'extérieur, vous devrez mettre 16 au lieu de 1), il vous faut alors ajouter la ligne, recompiler, réinstaller et redémarrer avec le nouveau noyau. Reportez-vous s'il vous plaît au chapitre Configurer le noyau de FreeBSD pour plus d'informations sur la marche à suivre. Vous pouvez voir de combien de pseudo-périphériques tun dispose votre noyau avec la commande suivante: &prompt.root; ifconfig -a tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 Dans cette exemple, il y a quatre périphériques “tunnel”, dont deux sont déjà configurés et utilisés. Remarquez que l'indication RUNNING signifie que l'interface a déjà été utilisée à un moment donné - ce n'est pas une erreur si votre interface n'apparaît pas comme RUNNING. Si votre noyau n'inclut pas de pseudo-périphérique tun et que vous ne pouvez pas le recompiler pour une raison ou une autre, tout n'est pas perdu. Vous devriez pouvoir charger dynamiquement le code. Voyez les pages de manuel de modload8 et lkm4 appropriées pour plus de détails. Vous voudrez peut-être en profiter pour configurer en même temps un coupe-feu. Vous trouverez plus de détails à la section Coupe-Feux. Tester le périphérique <devicename>tun</devicename> La plupart des utilisateurs n'auront besoin que d'un périphérique tun (/dev/tun0). Si vous en avez définis plus d'un (i.e., une autre valeur que 1 à la ligne pseudo-device du fichier de configuration du noyau), adaptez toutes les références à tun0 dans ce qui suit à votre cas particulier. La meilleure façon de vous assurez que votre périphérique tun0 est correctement configuré est de recréer le fichier spécial de périphérique. Pour cela, exécutez les commandes suivantes: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun0 Si vous avez 16 périphériques “tunnel” dans votre noyau, il vous faudra créer plus que tun0: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun15 Pour vérifier encore que votre noyau est correctement configuré, la commande ci-dessous devrait vous donner le même résultat: &prompt.root; ifconfig tun0 tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 L'indication RUNNING n'est peut-être pas encore présente, auquel cas vous verriez: &prompt.root; ifconfig tun0 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 Configuration du solveur de noms Le solveur est la partie du système qui convertit les adresses IP en noms de machines et vice versa. Il est configurable pour consulter des tables de correspondances entre adresses et noms qui peuvent se trouver à deux endroits différents. La première est le fichier /etc/hosts (man 5 hosts). La seconde est le service de noms de domaines Internet (“Domain Name Service” - DNS), une base de données distribuée dont la description déborde le cadre du présent document. Cette section décrit brièvement comment configurer votre solveur. Le solveur est un ensemble d'appels système qui font la conversion, mais vous devez leur dire où trouver l'information. Cela se fait en modifiant le fichier /etc/host.conf. N'appelez pas ce fichier /etc/hosts.conf (Remarquez le s en trop), cela pourrait poser des problèmes. Renseigner le fichier <filename>/etc/host.conf</filename> Ce fichier doit contenir les deux lignes suivantes (dans cet ordre): hosts bind Cela dit au solveur de chercher d'abord dans le fichier /etc/hosts, puis de consulter le DNS s'il n'a pas trouvé le nom recherché. Renseigner le fichier <filename>/etc/hosts</filename>(5) Ce fichier doit contenir les noms et les adresses IP des machines de votre réseau. Il doit au grand minimum contenir les entrées pour la machine sur laquelle tournera ppp. Supposons qu'elle s'appelle foo.bar.com et que son adresse IP soit 10.0.0.1, /etc/hosts devra comporter: 127.0.0.1 localhost 10.0.0.1 foo.bar.com foo La première ligne définit l'adresse localhost comme synonyme de la machine elle-même. Quelle que soit votre propre adresse IP, l'adresse IP sur cette ligne doit toujours être 127.0.0.1. La deuxième ligne affecte au nom foo.bar.com (et au raccourci foo) l'adresse IP 10.0.0.1. Si votre fournisseur vous a donné une adresse IP statique et un nom de machine, mettez-les à la place de l'entrée 10.0.0.1. Renseigner le fichier <filename>/etc/resolv.conf</filename> /etc/resolv.conf dit au solveur ce qu'il doit faire. Si vous avez en service votre propre DNS, vous pouvez le laisser vide. Vous devez normalement y mettre la(les) ligne(s) suivante(s): nameserver x.x.x.x nameserver y.y.y.y domain bar.com x.x.x.x et y.y.y.y sont les adresses que votre fournisseur vous a données. Mettez autant de lignes nameserver qu'il vous a donné d'adresses. La ligne domain se réfère par défaut au nom de domaine de votre machine, et est probablement inutile. Consultez les pages de manuel de resolv.conf pour plus de détails sur les autres entrées possibles dans ce fichier. Si vous utilisez la version 2 ou ultérieure de PPP, la commande enable dns dira à PPP de demander à votre fournisseur de confirmer les informations sur les serveurs de noms. S'il vous donne des adresses différentes (ou s'il n'y a pas de ligne nameserver dans /etc/resolv.conf), PPP récrira dans le fichier les valeurs que votre fournisseur lui aura données. Configurer <command>ppp</command> Le programme utilisateur ppp et le “démon” pppd (l'implémentation de PPP dans le noyau) emploient tous deux des fichiers de configuration qui se trouvent dans le répertoire /etc/ppp. Les fichiers de configuration fournis en exemple sont une bonne référence pour ppp en mode utilisateur, ne les effacez pas. Pour configurer ppp, vous devrez, selon vos besoins, renseigner un certain nombre de fichiers. Ce que vous y mettrez dépend entre autres du fait que votre fournisseur vous alloue une adresse IP statique (i.e., on vous donne une adresse IP et vous utilisez toujours la même) ou dynamique (i.e., votre adresse IP peut être différente à chaque session PPP). PPP et les adresses IP statiques Vous devrez créer un fichier de configuration appelé /etc/ppp/ppp.conf. Il ressemblera à l'exemple ci-dessous: Les lignes qui se terminent par : commencent en première colonne. Toutes les autres lignes doivent être indentées avec des espaces ou des tabulations comme dans l'exemple donné. 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT" 5 provider: 6 set phone "(0123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns Ne mettez pas les numéros de ligne, ils ne sont là que pour pouvoir y faire référence dans la suite de cette documentation. Ligne 1: Définit l'entrée par défaut. Les commandes de cette entrée sont automatiquement exécutées au lancement de ppp. Ligne 2: Identifie le périphérique auquel est connecté le modem. COM1: correspond à /dev/cuaa0 et COM2: à /dev/cuaa1. Ligne 3: Fixe la vitesse à laquelle vous voulez vous connecter. Si 115200 ne marche pas (cela devrait fonctionner avec n'importe quel modem assez récent), essayez avec 38400. Ligne 4: La chaîne d'appel. PPP en mode utilisateur utilise une syntaxe “commande envoyée/réponse attendue” semblable à celle du programme chat8. Reportez-vous aux pages de manuel pour plus d'informations sur les caractéristiques de ce langage. Ligne 5: Définit une entrée pour un fournisseur appelé “provider”. Ligne 6: Donne le numéro de téléphone de ce fournisseur. On peut indiquer plusieurs numéros de téléphone avec les caractères : ou | comme séparateur. La différence entre les deux est décrite dans les pages de manuel de ppp. En résumé, si vous voulez utiliser les numéros les uns après les autres, utilisez :. Si vous voulez toujours essayer d'appeler le premier numéro et n'utiliser les autres qu'en cas d'échec, servez-vous de |. Mettez toujours la série de numéros de téléphone entre guillemets comme dans l'exemple. Ligne 7: La séquence d'ouverture de session suit la même syntaxe de style “chat” que la séquence d'établissement de la connexion. Dans l'exemple donné, la séquence correspond à un service où l'ouverture de session ressemble à: J. Random Provider login: foo password: bar protocol: ppp Vous devrez modifier cette procédure pour l'adapter à vos besoins. Quand vous la mettez pour la première fois au point, activez la trace de “chat” pour vérifier que la conversation se déroule conformément à votre attente. Si vous utilisez PAP ou CHAP, il n'y aura pas à ce stade d'ouverture de session, la séquence peut donc être laissée à blanc. Voyez la section authentification PAP et CHAP pour plus de détails. Ligne 8: Définit le délai de connexion par défaut (en secondes). Ici, la connexion sera automatiquement coupée après 300 secondes d'inactivité. Si vous ne voulez pas de coupure automatique après un temps d'inactivité donné, mettez cette valeur à zéro. Ligne 9: Donne les adresses des interfaces. La chaîne x.x.x.x doit être remplacée par l'adresse IP que votre fournisseur vous a allouée. La chaîne y.y.y.y doit être remplacée par l'adresse IP que votre fournisseur vous a donnée comme passerelle (la machine à laquelle vous vous connectez). Si votre fournisseur ne vous a pas indiqué d'adresse pour la passerelle, utilisez 10.0.0.2/0. Si vous devez “deviner” cette adresse, veillez à créer une entrée dans /etc/ppp/ppp.linkup comme expliqué à la section PPP et les adresses IP dynamiques. Si cette ligne manque, ppp ne pourra pas être utilisé en mode ou . Ligne 10: Ajoute une route par défaut vers la passerelle de votre fournisseur. Le mot réservé HISADDR est remplacé par l'adresse de la passerelle donnée à la ligne 9. Il est important que cette ligne apparaisse après la précédente, sans quoi le valeur de HISADDR n'est pas encore initialisée. Ligne 11: Cette ligne dit à PPP de demander à votre fournisseur de confirmer que les adresses des serveurs de noms sont correctes. Si votre fournisseur supporte cette fonctionnalité, PPP peut alors mettre à jour les entrées pour les serveurs de noms dans /etc/resolv.conf avec les bonnes valeurs. Il n'est pas utile d'ajouter une entrée au fichier ppp.linkup lorsque vous avez une adresse IP statique car les entrées de votre table de routage sont correctes avant même que vous vous soyez connecté. Vous pouvez malgré tout vouloir ajouter des entrées pour lancer des programmes une fois que vous êtes déjà connecté. C'est expliqué plus bas dans l'exemple pour sendmail. Il y a des exemples de fichiers de configuration dans le répertoire /etc/ppp. PPP et les adresses IP dynamiques Si votre fournisseur ne vous donne pas d'adresse IP statique, ppp peut être configuré pour négocier les adresses locale et éloignée. Cela se fait en “devinant” l'adresse IP et en laissant ppp la rectifier avec le protocole de configuration IP (“IP Configuration Protocol” - IPCP) une fois la connexion établie. Le fichier de configuration ppp.conf est le même que pour PPP et les addresses IP statiques, aux modifications suivantes près: 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Encore une fois, ne mettez pas les numéros de ligne, ils ne sont là que pour y faire référence dans le suite des explications. Indentez avec au moins un blanc. Ligne 9: Le nombre qui suit le caractère / est le nombre de bits de l'adresse que ppp ne négociera pas. Vous voudrez peut être utiliser des adresses IP plus adaptées à votre cas particulier, mais l'exemple donné marchera dans tous les cas de figure. Le dernier argument (0.0.0.0) dit à PPP de négocier en utilisant l'adresse 0.0.0.0 plutôt que 10.0.0.1. Ne mettez pas 0.0.0.0 en premier argument de set ifaddr parce que cela empêche PPP de définir la route initiale en mode . Si vous utilisez la version 1.x de PPP, il vous faudra aussi une entrée dans /etc/ppp/ppp.linkup. ppp.linkup est utilisé après que la connexion ait été établie. A ce stade, ppp connaît les adresses IP réelles. L'entrée qui suit supprimera les routes erronées existantes et créera les routes valides: 1 provider: 2 delete ALL 3 add 0 0 HISADDR Ligne 1: A l'établissement de la connexion, ppp parcourera les entrées de ppp.linkup selon le principe suivant. Il essayera d'abord de trouver le même libellé que celui qui a été employé dans ppp.conf. S'il échoue, il cherchera une entrée pour l'adresse IP de la passerelle. C'est une entrée dont le libellé est composé de quatre entiers (pour les quatre octets). S'il ne la trouve pas non plus, il cherchera l'entrée MYADDR. Line 2: Cette ligne dit à ppp de supprimer toutes les routes existantes pour l'interface tun qu'il utilise (sauf la route directe). Ligne 3: Cette ligne dit à ppp d'ajouter une route par défaut vers HISADDR. HISADDR sera remplacée par l'adresse IP de la passerelle négociée par IPCP. Voyez l'entrée “pmdemand” dans les fichiers /etc/ppp/ppp.conf.sample et /etc/ppp/ppp.linkup.sample pour avoir un exemple détaillé. La version 2 de PPP introduit les “routes persistantes”. Toutes les lignes add ou delete qui contiennent MYADDR ou HISADDR sont mémorisées et chaque fois que la valeur de MYADDR ou HISADDR change, les routes sont redéfinies. Il n'est donc plus nécessaire de répéter ces lignes dans ppp.linkup. Recevoir des appels entrants avec <command>ppp</command> Cette section vous explique comment configurer ppp pour l'utiliser comme serveur. Quand vous configurez ppp pour recevoir des appels entrants sur une machine connectée à un réseau local, vous devez décider si vous transmettrez des paquets vers le réseau local. Si c'est le cas, vous devrez allouer à la machine distante une adresse IP sur votre sous-réseau local et utiliser la commande enable proxy dans le fichier ppp.conf. Vous devrez aussi vous assurer que le fichier /etc/rc.conf (ce fichier s'appelait auparavant /etc/sysconfig) contienne la ligne: gateway=YES Quel “getty”? La section Connexions téléphoniques décrit en détail la mise en oeuvre des connexions entrantes avec “getty”. Une alternative à getty est mgetty, une version de getty spécialement conçue pour les connexions téléphoniques. Un des avantages de mgetty est qu'il discute avec les modems, ce qui signifie que si le port est marqué “off” dans /etc/ttys, votre modem ne décrochera pas le téléphone. Les dernières versions de mgetty (à partir de la 0.99bêta) suportent aussi la détection automatique des fluxs PPP, ce qui permet à vos clients d'accéder au serveur sans exécuter de procédures particulières. Voyez Mgetty et AutoPPP pour plus d'informations sur mgetty. Autorisations pour PPP ppp doit normalement être exécuté avec un IDentifiant utilisateur de 0. Cependant, si vous voulez autoriser l'exécution du serveur ppp, comme décrit ci-dessous, sous un compte utilisateur ordinaire, vous devez autoriser ces utilisateurs à exécuter ppp en les ajoutant au groupe network dans /etc/group. Vous devrez aussi leur donner accès à une ou plusieurs sections du fichier de configuration avec la commande allow: allow users fred mary Si vous mettez cette commande dans la section default, vous donnez aux utilisateurs mentionnés accès à tout. Installer une procédure PPP pour les utilisateurs avec des adresses IP dynamiques Créez un fichier appelé /etc/ppp/ppp-shell comme suit: #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP pour $CALLEDAS sur $TTY" echo "Démarrage PPP pour $IDENT" exec /usr/sbin/ppp -direct $IDENT Cette procédure doit être exécutable. Créez maintenant un lien symbolique appelé ppp-dialup sur cette procédure avec la commande: &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup Utilisez cette procédure comme interpréteur de commandes pour tous vos utilisateurs qui se connectent avec ppp. Voici une exemple de fichier /etc/password avec un utilisateur PPP appelé pchilds. (n'oubliez pas de ne pas éditer directement le fichier passwd, utilisez vipw): pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup Créez un répertoire /home/ppp que tout le monde puisse lire, avec le fichier vide suivant: -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts ce qui évite que le contenu du fichier /etc/motd soit affiché à l'ouverture de session. Installer une procédure PPP pour les utilisateurs avec des adresses IP statiques Créez le fichier ppp-shell comme décrit ci-dessus, et pour chaque compte auquel est assignée une adresse IP fixe, créez un lien symbolique sur ppp-shell. Par exemple, si vous avez trois clients appelés fred, sam, et mary, qui se connectent par téléphone et pour qui vous servez de passerelle sur des réseaux de classe C, vous taperez les commandes suivantes: &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary Vous devez définir comme interpréteur de commandes de chacun de ces comptes les liens symboliques que vous venez de créer. (ie. /etc/ppp/ppp-mary pour mary, etc.) Renseigner ppp.conf pour les utilisateurs avec des adresses IP dynamiques Le fichier /etc/ppp/ppp.conf doit contenir quelque chose qui ressemble à: default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy L'indentation est importante. La section default: est utilisée pour chaque session. Créez une entrée semblable à celle pour ttyd0: ci-dessus pour chaque ligne activée dans /etc/ttys. Vous devez attribuer à chaque ligne une adresse IP dans votre plage d'adresses IP dynamiques. Renseigner <filename>ppp.conf</filename> pour les utilisateurs avec des adresses IP statiques En plus de ce que vous avez déjà introduit dans le fichier /etc/ppp/ppp.conf d'exemple ci-dessus vous devez ajouter une section pour chaque utilisateur auquel est assignée une adresse IP fixe. En continuant avec notre exemple pour fred, sam et mary: fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 Vous devez aussi, si besoin est, donnez les informations de routage dans /etc/ppp/ppp.linkup pour chaque utilisateur ayant une adresse IP fixe. La première ligne ci-dessous ajoute une route vers le réseau de classe C 203.14.101.0 via la liaison ppp du client. fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR A propos de <command>mgetty</command>, AutoPPP et des extensions Microsoft <command>mgetty</command> et AutoPPP Configurer et compiler mgetty avec l'option AUTO_PPP permet à mgetty de détecter la phase LCP des connexions PPP et de lancer automatiquement une procédure adaptée à ppp. Cependant, comme il n'y a pas alors d'ouverture de session avec invite et demande de mot de passe, il est nécessaire d'authentifier les utilisateurs en utilisant soit PAP, soit CHAP. Nous supposerons dans cette section que vous avez déjà réussi à configurer, compiler et installer une version de mgetty avec l'option AUTO_PPP (v0.99bêta ou ultérieure). Assurez-vous que le fichier /usr/local/etc/mgetty+sendfax/login.config contienne bien la ligne suivante: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup Cela dit à mgetty d'exécuter la procédure ppp-pap-dialup lorsqu'il reconnaît une connexion PPP. Créez un fichier /etc/ppp/ppp-pap-dialup (ce fichier doit être exécutable) avec pour contenu: #!/bin/sh exec /usr/sbin/ppp -direct pap$IDENT Pour chaque ligne d'appel activée dans le fichier /etc/ttys, créez une entrée correspondante dans le fichier /etc/ppp/ppp.conf. Ces entrées peuvent sans problème exister conjointement aux entrées que nous avons déjà créées plus haut. pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy Chaque utilisateur se connectant de cette manière devra disposer d'une entrée “nom d'utilisateur/mot de passe” dans le fichier /etc/ppp/ppp.secret, ou bien vous pouvez ajouter l'option: enable passwdauth pour identifier les utilisateurs avec pap en utilisant le fichier /etc/password. Si vous voulez affecter à certains utilisateurs une adresse IP statique, vous pouvez donner ce numéro comme troisième argument de /etc/ppp/ppp.secret. Le fichier /etc/ppp/ppp.secret.sample vous en donne des exemples. Extentions Microsoft Il est possible de configurer PPP pour qu'il fournisse à la demande les adresses des serveurs DNS et NetBIOS. Pour mettre en service ces extensions avec PPP version 1.x, ajoutez les lignes suivantes à la section adéquate de /etc/ppp/ppp.conf: enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 Et pour PPP version 2 et ultérieures: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 Cela donnera aux clients les adresses des serveurs DNS primaire et secondaire et du serveur de noms netbios. A partir de la version 2, si la ligne set dns n'est pas mentionnée, PPP utilise les valeurs données par /etc/resolv.conf. Authentification PAP et CHAP Certains fournisseurs d'accès configurent leurs systèmes de sorte que la phase d'authentification de votre connexion se fasse par PAP ou CHAP. Si tel est le cas, il n'y a pas d'invite login: quand vous vous connectez, le dialogue s'établit immédiatement avec PPP. PAP est moins sécurisé que CHAP, mais la sécurité n'est normalement pas un problème dans ce cas, parce que les mots de passe, bien que transmis en clair, ne sont transmis que sur une liaison série, ce qui la rend très difficile à espionner par un pirate. Par rapport aux exemples donnés aux sections PPP et les adresses IP statiques ou PPP et les adresses IP dynamiques, vous devez faire les modifications suivantes: 7 set login ... 12 set authname MonNomUtilisateur 13 set authkey MonMotDePasse Comme toujours, ne mettez pas les numéros de ligne, ils ne sont là que pour y faire référence dans les explications qui suivent. Il faut indenter avec au moins un espace. Ligne 7: Votre fournisseur ne vous demandera normalement pas d'ouvrir de session sur le serveur si vous utilisez PAP ou CHAP. Vous devez donc désactiver votre séquence “set login”. Ligne 12: Cette ligne donne votre nom d'utilisateur PAP/CHAP. Remplacez MonNomUtilisateur par la bonne valeur. Ligne 13: Cette ligne donne votre mot de PAP/CHAP. Remplacez MonMotDePasse par la bonne valeur. Peut-être voudrez-vous ajouter une ligne supplémentaire: 15 accept PAP ou 15 accept CHAP pour que l'intention soit claire, mais PAP et CHAP sont tous deux acceptés par défaut. Modifier à chaud votre configuration <command>ppp</command> Il est possible de dialoguer avec le programme ppp tandis qu'il s'exécute en tâche de fond, mais vous devez avoir configuré un port de diagnostic qui convienne. Pour cela, ajoutez à votre configuration la ligne suivante: set server /var/run/ppp-tun%d MotDePasseDeDiagnostic 0177 Cela dit à PPP d'écouter sur la “prise” - socket - Unix indiquée, et de demander au client de lui donner le mot de passe mentionné avant de lui autoriser l'accès. Le %d est à remplacer par le numéro du périphérique “tunnel” utilisé. Une fois que la “prise” - socket - a été créée, le programme pppctl8 peut être utilisé par des procédures qui veulent agir sur la configuration du programme ppp actif. Configuration finale du système ppp est maintenant configuré, mais il y a encore quelques petites choses à faire avant de pouvoir l'utiliser. Il faut pour cela modifier le fichier /etc/rc.conf (qui s'appelait auparavant /etc/sysconfig). En le parcourant de haut en bas, vérifiez que la valeur hostname= est bien renseignée, e.g.: hostname=foo.bar.com Si votre fournisseur d'accès vous a donné une adresse IP statique et un nom de machine, le mieux est d'utiliser ce nom comme nom de votre machine. Cherchez la variable network_interfaces. Si vous voulez configurer votre système pour vous connecter à la demande chez votre fournisseur, vérifiez que le périphérique tun0 est bien dans la liste, sinon ajoutez-le. network_interfaces="lo0 tun0" ifconfig_tun0= La variable ifconfig_tun0 doit être vide. Il faut créer un fichier /etc/start_if.tun0 avec la ligne: ppp -auto mysystem Cette procédure est exécutée lors de la configuration du réseau au démarrage et lance le “démon” ppp en mode automatique. Si cette machine sert de passerelle sur un réseau local, vous pouvez aussi ajouter l'indicateur . Reportez-vous aux pages de manuel pour plus de détails. Donnez NO comme valeur pour le programme de routage avec la ligne: router_enable=NO (/etc/rc.conf) router=NO (/etc/sysconfig) Il est important que le “démon” routed ne soit pas lancé (il est démarré par défaut) parce que routed a tendance à effacer les entrées par défaut créées dans la table de routage par ppp. Il vaut probablement la peine de vérifier que la ligne sendmail_flags ne comporte pas l'option , sans quoi sendmail jettera de temps à autre un oeil au réseau, ce qui peut amener votre machine à ouvrir la connexion. Vous pouvez essayez: sendmail_flags="-bd" L'inconvénient est que vous devrez forcer sendmail à réexaminer la file d'attente du courrier électronique chaque fois que la liaison ppp sera activée, en tapant: &prompt.root; /usr/sbin/sendmail -q Vous pouvez utiliser la commande !bg de ppp.linkup pour le faire automatiquement: 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m Si cela ne vous convient pas, il est possible de mettre en place un “dfilter” pour bloquer le trafic SMTP. Consultez les fichiers d'exemple pour plus de détails. Vous n'avez plus qu'à redémarrer votre machine. Apres qu'elle ait redémarré, vous pouvez taper soit: &prompt.root; ppp puis dial provider pour initialiser la session PPP ou, si vous voulez que ppp lance la session automatiquement lorsqu'il y a du trafic sortant (et que vous n'avez pas créé le fichier start_if.tun0), tapez: &prompt.root; ppp -auto provider Résumé Pour récapituler, les étapes suivantes sont nécessaires lors de la première configuration de ppp: Côté client: Vérifier que le pilote de périphérique tun soit inclus dans le noyau. Vérifier que le fichier spécial de périphérique tunX existe dans le répertoire /dev. Créer une entrée dans /etc/ppp/ppp.conf. L'exemple pmdemand doit suffire pour la plupart des fournisseurs d'accès. Dans le cas d'une adresse IP dynamique, créer une entrée dans /etc/ppp/ppp.linkup. Modifier le fichier /etc/rc.conf (ou sysconfig). Créer une procédure start_if.tun0 dans le cas d'une connexion automatique à la demande. Côté serveur: Vérifier que le pilote de périphérique tun soit inclus dans le noyau. Vérifier que le fichier spécial de périphérique tunX existe dans le répertoire /dev. Créer une entrée dans /etc/passwd (avec le programme vipw8). Créer un profil dans le répertoire de cet utilisateur qui exécute ppp -direct direct-server ou quelque chose d'équivalent. Créer une entrée dans /etc/ppp/ppp.conf. L'exemple direct-server devrait suffire. Créer une entrée dans /etc/ppp/ppp.linkup. Modifier le fichier /etc/rc.conf (ou sysconfig). Remerciements La dernière mise à jour de cette section du manuel a été effectuée le Lundi 10 Août 1998 par &a.brian;. Merci aux personnes suivantes pour les informations, commentaires et suggestions qu'elles m'ont transmis: &a.nik; - &a.dirkvangulik; - - &a.pjc; - Configurer PPP intégré au noyau - Contribution de &a.gena;. + Contribution de Gennady B. Sorokopud + gena@NetVision.net.il. Avant de lancer PPP sur votre machine, vérifiez que pppd est bien dans le répertoire /usr/sbin et que le répertoire /etc/ppp existe. pppd fonctionne de deux façons: comme “client”, i.e. si vous voulez connecter votre machine au monde extérieur via un liaison PPP série ou un modem. comme “serveur”, i.e. si votre machine est sur le réseau et sert à y connecter d'autres ordinateurs avec PPP. Dans les deux cas, vous devrez renseigner un fichier d'options (/etc/ppp/options ou ~/.ppprc s'il y a plus d'un utilisateur sur votre machine qui utilisent PPP). Il vous faudra aussi un logiciel “modem/série” (de préférence kermit) pour appeler et établir la connexion avec la machine distante. Utiliser le client PPP J'ai utilisé le fichier /etc/ppp/options suivant pour me connecter à la liaison PPP d'un concentrateur CISCO. crtscts # contrôle de flux matériel modem # liaison par modem noipdefault # adresse IP affectée par le serveur PPP distant # si la machine distante ne vous donne pas d'adresse IP # lors de la négociation IPCP, ne mettez pas cette option passive # attendre les paquets LCP domain ppp.foo.com # mettez ici votre nom de domaine :<ip_éloigné> # mettez ici l'adresse IP de la machine PPP distante # elle servira à router des paquets via la liaison PPP # si vous n'avez pas utilisé l'option noipdefault # changez cette ligne en <ip_local>:<ip_éloigné> defaultroute # mettez cette ligne si vous voulez que le serveur PPP soit # votre routeur par défaut Pour vous connecter: Appelez la machine éloignée avec kermit (ou un autre programme pour modem) et donnez votre nom et votre mot de passe (ou ce qu'il faut pour activer PPP sur la machine distante). Quittez kermit (sans raccrocher la ligne). Entrez: &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 Utilisez la vitesse et le nom de périphérique adéquats. Votre ordinateur est maintenant connecté par PPP. Si la connexion échoue pour une raison ou une autre, vous pouvez ajouter l'option au fichier /etc/ppp/options et consulter les messages à la console pour trouver la cause du problème. La procédure /etc/ppp/pppup ci-dessous fera tout cela automatiquement: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'arrêt de pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'arrêt de kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 /etc/ppp/kermit.dial est la procédure kermit qui appelle et fournit les informations d'authentification à la machine distante. (Il y a une exemple de procédure de ce type à la fin de ce document.) Utilisez la procédure /etc/ppp/pppdown ci-dessous pour terminer la session PPP et vous déconnecter: #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'arrêt de pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'arrêt de kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest Pour voir si PPP tourne toujours (/usr/etc/ppp/ppptest): #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd actif : PID=' ${pid-NONE} else echo 'Pas de pppd actif.' fi set -x netstat -n -I ppp0 ifconfig ppp0 Pour raccrocher la ligne modem (/etc/ppp/kermit.hup): set line /dev/tty01 ; mettez ici le périphérique pour votre modem set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit Voici une autre méthode qui utilise chat au lieu de kermit: - Contribution de &a.rhuff;. + Contribution de Robert Huff + rhuff@cybercom.net. Les deux fichiers suivants suffisent à établir une liaison ppp. /etc/ppp/options: /dev/cuaa1 115200 crtscts # contrôle de flux matériel modem # liaison par modem connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # adresse IP affectée par le serveur PPP distant # si la machine distante ne vous donne pas d'adresse IP # lors de la négociation IPCP, ne mettez pas cette option passive # attendre les paquets LCP domain ppp.foo.com # mettez ici votre nom de domaine :<ip_éloigné> # mettez ici l'adresse IP de la machine PPP distante # elle servira à router des paquets via la liaison PPP # si vous n'avez pas utilisé l'option noipdefault # changez cette ligne en <ip_local>:<ip_éloigné> defaultroute # mettez cette ligne si vous voulez que le serveur PPP soit # votre routeur par défaut /etc/ppp/login.chat.script: (Ceci doit être tapé sur une seule ligne.) ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<numéro.de.téléphone> CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <nom-d-utilisateur> TIMEOUT 5 sword: <mot-de-passe> Une fois que ces fichiers sont installés et contiennent ce qu'il faut, vous n'avez plus qu'à taper: &prompt.root; pppd Cet exemple est avant tout basé sur des informations fournies par: Trev Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> et utilisées avec son autorisation. Utiliser le serveur PPP /etc/ppp/options: crtscts # contrôle de flux matériel netmask 255.255.255.0 # masque de sous-réseau ( facultatif ) 192.114.208.20:192.114.208.165 # adresses IP des machines locales et distantes # l'adresse locale ne doit pas être la même que # celle que vous avez assignée à l'interface # Ethernet ( ou autre ) de la machine. # l'adresse IP de la machine distante est # l'adresse qui lui sera affectée domain ppp.foo.com # votre nom de domaine passive # attendre LCP modem # liaison modem La procédure /etc/ppp/pppserv ci-dessous lancera le serveur ppp sur votre machine: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'arrêt de pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'arrêt de kermit, PID=' ${pid} kill -9 ${pid} fi # réinitialiser l'interface ppp ifconfig ppp0 down ifconfig ppp0 delete # activer le mode réponse automatique kermit -y /etc/ppp/kermit.ans # lancer ppp pppd /dev/tty01 19200 Utilisez cette procédure /etc/ppp/pppservdown pour arrêter le serveur: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'arrêt de pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'arrêt de kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans La procédure kermit ci-dessous active ou désactive le mode réponse automatique de votre modem (/etc/ppp/kermit.ans): set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; remplacez par ATS0=0\13 pour désactiver ; le mode réponse automatique inp 5 OK echo \13 exit La procédure /etc/ppp/kermit.dial établit la connexion et ouvre la session sur la machine distante. Vous devrez l'adapter à vos besoins propres. Mettez-y votre nom d'utilisateur et votre mot de passe, et modifiez aussi les chaînes attendues en réponse selon ce que vous envoient votre modem et la machine distante. ; ; mettez ici la liaison série à laquelle est raccordé le modem: ; set line /dev/tty01 ; ; mettez ici la vitesse du modem: ; set speed 19200 set file type binary ; transfert 8 bits set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; puis SET CARRIER si nécessaire, set dial display on ; puis SET DIAL si nécessaire, set input echo on set input timeout proceed set input case ignore def \%x 0 ; compteur d'ouverture de session goto slhup :slcmd ; met le modem en mode commande echo Modem en mode commande. clear ; vide le tampon d'entrée pause 1 output +++ ; séquence d'échappement Hayes input 1 OK\13\10 ; attendre un OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; si le modem ne répond pas OK, réessayer :slhup ; raccrocher clear ; vider le tampon d'entrée pause 1 echo On raccroche. output ath0\13 ; commande HAYES pour raccrocher input 2 OK\13\10 if fail goto slcmd ; si pas de réponse OK, passez en mode commande :sldial ; composer le numéro pause 1 echo On appelle. output atdt9,550311\13\10 ; mettre ici le numéro de téléphone assign \%x 0 ; mettre le compteur de secondes à 0 :look clear ; vider le tampon d'entrée increment \%x ; compter les secondes input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; ouverture de session assign \%x 0 ; mettre le compteur de secondes à 0 pause 1 echo Attente de l'invite de session. :slloop increment \%x ; compter les secondes clear ; vider le tampon d'entrée output \13 ; ; Mettez ici l'invite que vous attendez: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; essayer 10 fois d'avoir l'invite else goto slhup ; raccrocher et recommencer après 10 échecs :sluid ; ; Mettez ici votre nom d'utilisateur: ; output nom-d-utilisateur-ppp\13 input 1 {Password: } ; ; Mettez ici votre mot de passe: ; output mot-de-passe-ppp\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7Pas de tonalité. Vérifiez votre ligne téléphonique!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: Configurer un client SLIP Contribution de &a.asami;8 Août 1995. Cette section décrit une manière de configurer une machine FreeBSD pour utiliser SLIP sur un réseau où le nom de machine est statique. Si le nom de machine est affecté dynamiquement (i.e., votre adresse change à chaque connexion), vous devrez probablement employer une méthode plus sophistiquée. Déterminez d'abord sur quel port série votre modem est branché. J'utilise un lien symbolique de /dev/modem vers /dev/cuaa1, et n'utilise que ce lien dans mes fichiers de configuration. Cela évite qu'il devienne laborieux de modifier un certain nombre de fichiers de /etc et les .kermrc pour l'ensemble du système! /dev/cuaa0 correspond à COM1 et cuaa1 à COM2, etc. Vérifiez que la ligne: pseudo-device sl 1 est bien présente dans votre fichier de configuration du noyau. Elle existe dans le noyau GENERIC, ce n'est donc un problème que si vous l'avez supprimée. Ce que vous n'aurez à faire qu'une seule fois Ajoutez votre machine, la passerelle et les serveurs de noms de domaines à votre fichier /etc/hosts. Voici à quoi ressemble le mien: 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 Au passage, silvia est le nom de la voiture que j'avais quand je suis retourné au Japon (on l'appelle 2?0SX ici aux Etats-Unis). Vérifiez que vient avant dans votre fichier /etc/host.conf. Sinon, il peut se passer des choses bizarres. Modifiez le fichier /etc/rc.conf. Si votre version de FreeBSD est antérieure à la version 2.2.2, c'est le fichier /etc/sysconfig qu'il faut modifier à la place. Définissez votre nom de machine à la ligne: hostname=myname.my.domain Vous devez donner votre nom Internet de machine en entier. Ajouter sl0 à la liste des interfaces réseau en modifiant la ligne: network_interfaces="lo0" en: network_interfaces="lo0 sl0" Définissez les paramètres de configuration de sl0 en ajoutant une ligne: ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" Précisez la passerelle par défaut en modifiant la ligne: defaultrouter=NO en: defaultrouter=slip-gateway Créez un fichier /etc/resolv.conf qui contienne: domain HIP.Berkeley.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 Comme vous le constatez, c'est la définition des serveurs de noms de domaines. Bien entendu, les noms et les adresses de ceux-ci sont fonction de votre environnement particulier. Donnez des mots de passe à root et toor (et à tous les autres comptes qui n'auraient pas de mot de passe). Employez passwd, ne modifiez pas les fichiers /etc/passwd ou /etc/master.passwd! Redémarrez la machine et vérifiez qu'elle a bien le nom voulu. Etablir une connexion SLIP Téléphonez, tapez slip à l'invite, entrez votre nom d'utilisateur et votre mot de passe. Ce que vous avez à faire dépend de votre environnement. J'utilise une procédure kermit comme celle-ci: # configuration kermit set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # La macro-instruction qui suit téléphone et établit la connexion define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a (vous devez bien sur remplacer le nom et le mot de passe par les vôtres). Vous pouvez alors entrer simplement slip à l'invite de kermit pour vous connecter. Laisser votre mot de passe en clair dans un quelconque fichier est en général une MAUVAISE idée. Faites-le à vos risques et périls. Je suis simplement trop paresseux. Laissez maintenant kermit tel que (vous pouvez le mettre en arrière-plan avec z) et, sous le compte super-utilisateur, tapez: &prompt.root; slattach -h -c -s 115200 /dev/modem Si vous arriver à envoyer un ping à des machines situées de l'autre côté du routeur, vous êtes connecté! Si cela ne marche pas, vous pouvez essayer l'option au lieu de l'option de slattach. Comment couper la connexion Tapez: &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` (en étant super-utilisateur root) pour tuer slattach. Revenez maintenant sous kermit (fg si vous l'avez mis en tâche de fond) et quittez-le (q). Les pages de manuel de slattach disent que vous devez employer ifconfig sl0 down pour indiquer que l'interface n'est plus active, mais cela ne change apparement rien pour moi. (Les diagnostics de ifconfig sl0 sont identiques.) Il arrive parfois que votre modem refuse de raccrocher (le mien le fait souvent). Dans ce cas, relancez kermit et quittez-le de nouveau. Cela marche en général au deuxième essai. En cas de problèmes Si cela ne marche pas, n'hésitez pas à me contacter. Voici les problèmes que certains ont rencontrés jusqu'ici: Ne pas utiliser l'option ou de slattach (Je n'ai aucune idée de pourquoi cela pose problème, mais le fait de mettre cet indicateur a au moins fourni la solution dans un cas). Mettre au lieu (avec certaines polices de caractères, il est parfois difficile de faire la différence). Essayez ifconfig sl0 pour contrôler la configuration de votre interface. J'obtiens: &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 De même, netstat -r vous affichera la table de routage, au cas où ping vous renverrait des messages “no route to host”. Voici la mienne: &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) (cela après transfert d'un certain nombre de fichiers, vous devriez avoir des valeurs moins importantes). Configurer un serveur SLIP Contribution de &a.ghelmer;. v1.0, 15 Mai 1995. Ce document vous donne des indications pour mettre en oeuvre un serveur SLIP sur un système FreeBSD, ce qui signifie typiquement configurer votre système pour ouvrir une connexion à l'ouverture d'une session depuis une machine distante. L'auteur l'a rédigé en se basant sur sa propre expérience; néanmoins, comme votre système et vos besoins peuvent être différents, il ne répond peut-être pas à toutes vos questions, et l'auteur ne peut pas être tenu pour responsable des dégâts que vous causeriez à votre système ou des données que vous auriez perdues en essayant de suivre les indications données ici. Ce guide a été à l'origine écrit pour le serveur SLIP de la version 1.x de FreeBSD. Il a été adapté pour prendre en compte les modifications de chemins d'accès et la suppression des indicateurs de compression de l'interface SLIP des premières versions 2.x de FreeBSD, qui sont apparemment les seuls différences importantes entre ces versions. Si vous trouvez des erreurs, envoyez s'il vous plaît à l'auteur un courrier électronique suffisamment détaillé pour qu'il puisse les corriger. Prérequis Ce document est très technique, il vous faut donc quelques connaissances de base. On suppose que vous connaissez le protocole réseau TCP/IP, et, en particulier, l'adressage des réseaux et des noeuds, les masques de réseau, les sous-réseaux, le routage et les protocoles de routage tels que RIP. Ce sont des choses que vous devez connaître pour configurer les services SLIP sur un serveur de connexions, et si ce n'est pas le cas, lisez s'il vous plaît TCP/IP Network Administration par Craig Hunt chez O'Reilly & Associates, Inc. (ISBN 0-937175-82-X)N.d.T.: traduit en français sous le titre “TCP/IP, Administration de réseau TCP/IP”, chez le même éditeur, ou le livre de Douglas Comer sur le protocole TCP/IP. On suppose aussi que vous avez déjà installé vos modems et configuré les fichiers système appropriés pour permettre l'ouverture de session via vos modems. Si vous ne l'avez pas encore fait, reportez-vous au guide de configuration des connexions entrantes; si vous disposez d'un navigateur World Wide Web, parcourez la liste des guides sur http://www.freebsd.org/; sinon, regardez là où vous avez trouvé le présent document et cherchez un document appelé dialup.txt où quelque chose du même genre. Vous pouvez aussi consulter les pages de manuel de sio4 pour plus d'informations sur le pilote de port série et de ttys5, gettytab5, getty8 et init8 en ce qui concerne la configuration du système pour qu'il autorise des connexions de l'extérieur par modem et peut-être aussi celles de stty1 pour avoir des renseignements sur le paramètrage des ports série (comme clocal pour les interfaces série directement connectées). Brève vue d'ensemble Une configuration typique d'utilisation de FreeBSD comme serveur SLIP fonctionne de la façon suivante: un utilisateur SLIP appelle votre serveur SLIP FreeBSD et ouvre une session sous un IDentifiant utilisateur SLIP particulier qui lance /usr/sbin/sliplogin à la place de l'interpréteur de commandes. Le programme sliplogin consulte le fichier /etc/sliphome/slip.hosts pour trouver une ligne correspondant à cet utilisateur, et s'il la trouve, connecte la ligne série à une interface SLIP disponible et lance ensuite la procédure /etc/sliphome/slip.login pour configurer cette interface SLIP. Un exemple d'ouverture de session sur un serveur SLIP Par exemple, si Shelmerg est un IDentifiant utilisateur SLIP, l'entrée pour Shelmerg dans /etc/master.passwd ressemblera à ce qui suit (sinon que tout sera sur une seule ligne): Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin Quand Shelmerg ouvre une session, sliplogin cherche dans /etc/sliphome/slip.hosts la ligne qui contient cet IDentifiant utilisateur; il peut, par exemple, y avoir dans /etc/sliphome/slip.hosts la ligne: Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp sliplogin la trouvera alors, affectera la ligne série à la prochaine interface SLIP disponible et exécutera /etc/sliphome/slip.login avec les arguments suivants: /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp Si tout se passe bien, /etc/sliphome/slip.login exécutera un ifconfig sur l'interface SLIP que s'est attribuée sliplogin (l'interface slip 0, dans l'exemple ci-dessus, qui est le premier paramètre passé à slip.login) pour définir l'adresse IP locale (dc-slip), l'adresse IP de la machine éloignée (sl-helmer), le masque de sous-réseau de l'interface SLIP (0xfffffc00) et tout autre indicateur supplémentaire (autocomp). Si quelque chose se passe mal, sliplogin fournit en général des messages d'informations valables en utilisant la fonctionnalité de trace du “démon” syslog, qui les enregistre habituellement dans /var/log/messages (reportez-vous au pages de manuel de syslogd8 et syslog.conf5, et regardez peut-être aussi dans /etc/syslog.conf pour voir où syslogd enregistre les messages). OK, assez d'exemples - attelons-nous maintenant à la configuration du système. Configuration du noyau Les noyaux par défaut de FreeBSD définissent habituellement deux interfaces SLIP (sl0 et sl1); vous pouvez vérifier avec netstat -i si ces interfaces sont définies dans votre noyau. Exemple de résultats de la commande netstat -i: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 <Link> 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0 0 Les interfaces sl0 et sl1 apparaissent dans les sorties de netstat -i, il y a donc deux interfaces SLIP dans le noyau. (Les astérisques après sl0 et sl1 indiquent que les interfaces sont “inactives” - down.) Cependant, les noyaux par défaut de FreeBSD ne sont pas configurés pour transmettre des paquets (i.e., votre machine FreeBSD ne fonctionnera pas comme routeur) à cause des spécifications imposées par les RFC Internet (reportez-vous à la RFC's 1009 [Spécifications des passerelles Internet], 1122 [Spécifications des machines Internet - Couches de communication], et peut-être aussi 1127 [Une perspective sur le RFCs de spécifications des machines]), donc, si vous voulez que votre serveur SLIP serve de routeur, vous devez modifier votre fichier /etc/rc.conf (appelé /etc/sysconfig dans les versions de FreeBSD antérieures à la 2.2.2) et affecter à la variable gateway. Si vous avez un système plus ancien qui n'a même pas de fichier /etc/sysconfig, ajoutez alors la commande: sysctl -w net.inet.ip.forwarding = 1 à votre fichier /etc/rc.local. Vous devrez alors redémarrer votre système pour que ce nouveau paramètrage soit pris en compte. Vous remarquerez à la fin du fichier de configuration par défaut du noyau (/sys/i386/conf/GENERIC) la ligne: pseudo-device sl 2 C'est cette ligne qui définit le nombre de périphériques SLIP disponibles dans le noyau; le nombre en fin de ligne est le nombre maximum de connexions SLIP qui peuvent être simultanément actives. Reportez-vous s'il vous plaît au chapitre Configurer le noyau de FreeBSD pour des indications sur la manière de configurer votre noyau. Configuration de sliplogin Comme on l'a dit plus haut, il y a trois fichiers dans le répertoire /etc/sliphome qui servent à la configuration de /usr/sbin/sliplogin (voyez sliplogin8 pour avoir les pages de manuel de sliplogin): slip.hosts, qui définit les utilisateurs SLIP et les adresses IP qui leur sont affectées; slip.login, qui ne fait en général que configurer l'interface SLIP; et (facultatif) slip.logout, qui fait le travail inverse de slip.login quand la connexion série est terminée. Configuration de <filename>slip.hosts</filename> /etc/sliphome/slip.hosts contient des lignes avec au moins quatre champs, séparés par des blancs: L'IDentifiant d'utilisateur SLIP, L'addresse locale (locale au serveur SLIP) de la liaison SLIP, L'adresse de l'autre extrémité de la liaison SLIP, Le masque de réseau. Les adresses locale et éloignée peuvent être des noms de machines (qui seront converties en adresses IP via /etc/hosts ou par le service de noms de domaines, selon ce que contient /etc/host.conf), et je crois que le masque de réseau peut être un nom qui sera converti en consultant le fichier /etc/networks. Pour notre exemple plus haut, /etc/sliphome/slip.hosts contiendrait: # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp La ligne se termine par une ou plusieurs des options:  - pas de compression des en-têtes,  - compression des en-têtes,  - compression des en-têtes si la machine distante l'autorise,  - interdire les paquets ICMP (de sorte que les paquets “ping” seront ignorés au lieu de consommer votre bande passante). Remarquez que le programme sliplogin des premières versions de FreeBSD 2 ignorait les options que FreeBSD 1.x reconnaissait, de sorte que les options , , et restaient sans effet, jusqu'à ce que leur support soit ajouté à FreeBSD 2.2 (à moins que votre procédure slip.login n'inclue le code nécessaire à la prise en compte de ces indicateurs). Les choix des adresses pour les deux extrémités des liaisons SLIP dépend du fait que vous leur dédiiez un sous-réseau ou que vous comptiez utiliser “proxy ARP” sur votre serveur SLIP (ce n'est pas du “vrai” proxy ARP, mais c'est la terminologie que nous utiliserons dans ce document pour le désigner). Si vous n'êtes pas sûr de la méthode à choisir ou de la facon d'assigner les adresses IP, référez-vous s'il vous plaît aux ouvrages mentionnés à la section Prérequis et/ou consultez l'administrateur de votre réseau IP. Si vous comptez dédier un sous-réseau IP à vos clients SLIP, vous devrez définir l'adresse de sous-réseau à partir de l'adresse de réseau qui vous est affectée et attribuer à chacun de vos clients SLIP une adresse IP sur ce sous-réseau. Vous devrez alors probablement configurer une route statique vers votre sous-réseau SLIP via votre serveur SLIP, sur votre routeur le plus proche, ou installer gated sur votre serveur SLIP FreeBSD et le configurer pour qu'il dialogue avec les protocoles appropriés avec les autres routeurs, pour leur annoncer la route de votre serveur SLIP vers le sous-réseau SLIP. Sinon, si vous utilisez la méthode “proxy ARP”, vous devrez assigner à vos client SLIP des adresses sur le sous-réseau Ethernet de votre serveur SLIP, et vous devrez aussi adapter vos procédures /etc/sliphome/slip.login et /etc/sliphome/slip.logout pour qu'elles utilisent arp8 pour gérer les entrées proxy-ARP dans la table ARP de votre serveur SLIP. Configuration de <filename>slip.login</filename> Le fichier /etc/sliphome/slip.login ressemble typiquement à ceci: #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # procédure d'ouverture de session générique pour une liaison slip # sliplogin l'appelle avec les paramètres: # # 1 2 3 4 5 6 7-n # interface vitesse nom adresse-locale adresse-éloignée masque optionnels # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 Ce fichier slip.login ne fait qu'exécuter ifconfig sur l'interface SLIP appropriée avec comme paramètres les adresses locales et distantes et le masque de réseau de l'interface SLIP. Si vous avez choisi la méthode “proxy ARP” (au lieu d'affecter un sous-réseau distinct à vos clients SLIP), votre fichier /etc/sliphome/slip.login devra ressembler à: #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # procédure d'ouverture de session générique pour une liaison slip # sliplogin l'appelle avec les paramètres: # # 1 2 3 4 5 6 7-n # interface vitesse nom adresse-locale adresse-éloignée masque optionnels # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # # répondre aux requêtes ARP concernant le client SLIP # pour notre adresse Ethernet # /usr/sbin/arp -s $5 00:11:22:33:44:55 pub La ligne supplémentaire arp -s $5 00:11:22:33:44:55 pub de ce fichier slip.login crée une entrée ARP dans la table ARP du serveur SLIP. Cette entrée ARP fait que le serveur SLIP répond en donnant sa propre adresse MAC lorsqu'un autre noeud IP du réseau Ethernet demande à parler avec le client SLIP qui a cette adresse IP. Dans l'exemple donné ci-dessus, remplacez bien l'adresse MAC Ethernet (00:11:22:33:44:55) par l'adresse MAC de la carte Ethernet de votre système, sans quoi votre “proxy ARP” ne fonctionnera définitivement pas! Vous pouvez connaître cette adresse MAC en regardant le résultat de la commande netstat -i; la seconde ligne des sorties doit ressembler à ce qui suit: ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 Cela indique que l'adresse MAC Ethernet de ce système est 00:02:c1:28:5f:4a - il faut remplacer les “.” dans les adresses MAC Ethernet que donne netstat -i par des “:” et ajouter un “0” devant les valeurs hexadécimales qui ne sont données que sur un seul caractère pour obtenir des adresses telles que arp8 les demande; voyez les pages de manuel de arp8 pour avoir des informations complètes sur ces conventions. Quand vous créez les fichiers /etc/sliphome/slip.login - et /etc/sliphome/slip.logout - , le bit “exécutable” doit être positionné (i.e., chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout), sinon sliplogin ne pourra pas exécuter la procédure. Configuration de <filename>slip.logout</filename> /etc/sliphome/slip.logout n'est pas strictement indispensable (à moins que vous n'implémentiez “proxy ARP”), mais, si vous décidez de la créer, voici un exemple de procédure slip.logout élémentaire: #!/bin/sh - # # slip.logout # # procédure de fermeture de session générique pour une liaison slip # sliplogin l'appelle avec les paramètres: # # 1 2 3 4 5 6 7-n # interface vitesse nom adresse-locale adresse-éloignée masque optionnels # /sbin/ifconfig sl$1 down Si vous utilisez “proxy ARP”, vous voudrez que /etc/sliphome/slip.logout supprime l'entrée ARP pour le client SLIP: #!/bin/sh - # # slip.logout # # procédure de fermeture de session générique pour une liaison slip # sliplogin l'appelle avec les paramètres: # # 1 2 3 4 5 6 7-n # interface vitesse nom adresse-locale adresse-éloignée masque optionnels # /sbin/ifconfig sl$1 down # Cessez de répondre aux requêtes ARP concernant le client SLIP /usr/sbin/arp -d $5 arp -d $5 supprime l'entrée ARP que la procédure slip.login pour “proxy arp” a ajouté quand le client SLIP a ouvert la session. Il n'est pas inutile de répéter: vérifiez que le bit “exécutable” de la procédure /etc/sliphome/slip.logout est positionné après que vous l'ayez créée (i.e., chmod 755 /etc/sliphome/slip.logout). A propos du routage Si vous n'utilisez pas “proxy ARP” pour router les paquets entre vos clients SLIP et le reste de votre réseau (et peut-être l'Internet), vous devrez probablement soit ajouter des routes statiques vers votre(vos) routeur(s) par défaut le(s) plus proche(s) pour router le sous-réseau de vos clients SLIP via votre serveur SLIP, soit installer et configurer gated sur votre serveur SLIP FreeBSD de sorte qu'il fournisse à vos routeurs, en utilisant les protocoles de routage appropriés, les informations qui concernent votre sous-réseau SLIP. Routes statiques Ajouter des routes statiques vers vos routeurs les plus proches peut être problématique (voire impossible, si vous n'avez pas les autorisations pour ...). Si vous avez un réseau avec des routeurs divers, certains d'entre eux, tels les Cisco et les Proteon, devront non seulement avoir la route statique vers votre sous-réseau SLIP, mais devront aussi savoir quelles routes statiques ils doivent annoncer aux autres routeurs, il faudra donc quelques compétences, de la mise au point ou de la “bidouille” pour que vos routes statiques fonctionnent. Utiliser <command>gated</command> Une alternative aux maux de tête que provoquent les routes statiques est d'installer gated sur votre serveur SLIP FreeBSD et de le configurer pour qu'il utilise les protocoles de routage appropriés (RIP/OSPF/BGP/EGP) pour annoncer aux autres routeurs votre sous-réseau SLIP. Vous pouvez utiliser la version de gated du catalogue des logiciels portés ou le télécharger depuis le site ftp anonyme de GateD et le compiler vous-même; Je crois que la dernière version au moment où j'écris ceci est gated-R3_5Alpha_8.tar.Z, qui inclut la version pour FreeBSD “prête-à-l'usage”. Des informations complètes et la documentation de gated sont disponibles sur le Web sur le site du Merit GateD Consortium. Compilez-le et installez-le, et créez ensuite un fichier /etc/gated.conf pour le configurer; voici un exemple, semblable à celui que l'auteur a utilisé sur un serveur SLIP FreeBSD: # # fichier de configuration de gated dc.dsu.edu; # pour la version 3.5alpha5 de gated # simplement diffuser les informations RIP pour xxx.xxx.yy # via l'interface Ethernet "ed" # # options de trace # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # fournir des informations de trace sur l'interface au noyau: kernel { traceoptions remnants request routes info interface ; } ; # # Propager la route vers xxx.xxx.yy via l'Ethernet interface et RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accepter les routes de RIP via les interfaces Ethernet "ed" import proto rip interface ed { all ; } ; L'exemple ci-dessus de fichier gated.conf diffuse l'information de routage concernant le sous-réseau SLP xxx.xxx.yy en utilisant RIP sur l'interface Ethernet; si vous utilisez un pilote Ethernet autre que ed, vous devrez modifier en conséquence les références à l'interface ed. Ce fichier d'exemple active aussi les traces sur /var/tmp/gated.output pour pouvoir déboguer le fonctionnement de gated; vous pouvez certainement désactiver ces options de trace si gated fonctionne comme vous le voulez. Vous devrez remplacer les xxx.xxx.yy par l'adresse réseau de votre propre sous-réseau SLIP (veillez à remplacer aussi le masque de réseau dans la clause proto direct). Une fois que vous avez compilé et installé gated et créer son fichier de configuration, vous devrez lancer gated au lieu de routed sur votre système FreeBSD; modifiez les paramètres de démarrage de routed/gated dans /etc/netstart comme requis par votre système. Consultez s'il vous plaît les pages de manuel de gated pour avoir des informations sur les paramètres de la ligne de commande de gated. Remerciements Merci aux personnes suivantes pour leurs commentaires et leurs conseils à propos de ce guide: &a.wilko; Piero Serini Piero@Strider.Inet.IT diff --git a/fr_FR.ISO8859-1/books/handbook/printing/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/printing/chapter.sgml index 0767427ef8..b8606bba2a 100755 --- a/fr_FR.ISO8859-1/books/handbook/printing/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/printing/chapter.sgml @@ -1,5375 +1,5375 @@ Imprimer - Contribution de &a.kelly;30 Septembre + Contribution de Sean Kelly30 Septembre 1995 &trans.a.haby; Pour imprimer avec FreeBSD, vous devrez configurer l'utilisation de vos imprimantes avec le gestionnaire de queues d'impression de Berkeley, connu aussi sous le nom de gestionnaire d'impression (“spooling system”) LPD (“Line Printer Daemon”). C'est le gestionnaire d'impression standard de BSD. Cette section décrit le gestionnaire d'impression LPD - souvent abrégé en LPD. Si vous connaissez déjà LPD ou un autre gestionnaire de files d'impression, vous pouvez passer directement à la section Configurer le gestionnaire d'impression. Que fait le gestionnaire d'impression ? LPD contrôle tout ce qui concerne les imprimantes. Il assume un certain nombre de fonctions: Il contrôle l'accès aux imprimantes locales et aux imprimantes connectées à d'autres machines du réseau. Il permet aux utilisateurs de soumettre des fichiers à l'impression; Ces demandes d'impression sont appelées travaux. Il empêche l'accès simultané de plusieurs utilisateurs à une même imprimante en gérant une queue pour chaque imprimante. Il peut imprimer des pages d'en-tête (appelées aussi bannières ou pages “burst” (qui sautent aux yeux) de façon à ce que les utilisateurs retrouvent facilement leurs travaux au milieu d'une pile de documents imprimés. Il gère les paramètres de communication pour les imprimantes raccordées sur un port série. Il peut envoyer des travaux au gestionnaire LPD d'une autre machine du réseau. Il peut exécuter des filtres pour formater les impressions en fonction des possibilités et du langage compris par les différentes imprimantes. Il peut comptabiliser l'utilisation d'une imprimante. Avec un fichier de configuration et en fournissant les programmes de filtrage spécifiques, vous pouvez confier à LPD tout ou une partie de ces tâches, pour une large gamme de matériels d'impression. Pourquoi faut-il utiliser le gestionnaire d'impression ? Si vous êtes l'unique utilisateur de votre système, vous pouvez vous demander pourquoi vous devriez vous compliquer la vie en utilisant le gestionnaire d'impression, alors que vous n'avez pas besoin de contrôle d'accès, de pages d'en-tête ou de comptabilité. Bien qu'il soit possible d'accéder directement à l'imprimante, il vaut mieux passer malgré tout par le gestionnaire d'impression parce que: LPD imprime les travaux en tâches de fond; vous n'avez pas besoin d'attendre que l'imprimante ait reçu vos données. LPD peut appliquer des filtres aux travaux pour ajouter des en-têtes avec la date et l'heure ou convertir des fichiers d'un format particulier (comme les fichiers DVI de TeX) vers un format compréhensible par l'imprimante. Vous n'avez pas besoin de faire tout cela à la main. De nombreux logiciels libres ou commerciaux disposent d'une fonctionnalité d'impression prévue pour utiliser le gestionnaire d'impression. En installant le gestionnaire d'impression, vous aurez moins de problèmes avec les logiciels que vous installerez ensuite ou qui sont déjà sur votre système. Configurer le gestionnaire d'impression Pour imprimer avec le gestionnaire d'impression, il vous faut configurer et vos imprimantes et le logiciel LPD. Ce document décrit les deux étapes de cette configuration: Lisez la section Configuration simple d'une imprimante pour apprendre à connecter une imprimante, dire à LPD comment communiquer avec et imprimer des fichiers texte. Lisez la section Configuration avancée d'une imprimante pour savoir comment imprimer différents formats de fichiers, imprimer des pages d'en-tête, imprimer via le réseau, contrôler l'accès aux imprimantes et comptabiliser leur utilisation. Configuration simple d'une imprimante Cette section vous explique comment configurer l'imprimante et le logiciel LPD pour pouvoir imprimer. Elle vous fournit les informations de base: La section Configuration du matériel vous donne des indications sur la connexion de l'imprimante à votre ordinateur. La section Configuration du logiciel vous explique comment renseigner le fichier de configuration /etc/printcap de LPD. Si vous installez une imprimante qui utilise une protocole réseau pour recevoir les données à imprimer et non une imprimante sur l'interface série ou parallèle, reportez-vous à la section Imprimantes avec une interface réseau. Bien que cette section soit intitulée “Configuration simple d'une imprimante”, elle est en fait assez complexe. Arriver à faire fonctionner l'imprimante avec votre ordinateur et le gestionnaire d'impression LPD est le plus difficile. Les options avancées comme les pages d'en-tête et la comptabilité sont faciles à mettre en place une fois que l'impression fonctionne. Configuration du matériel Cette section vous détaille les différentes façons de connecter une imprimante à votre PC. Elle traite des types de ports et de câbles et de la manière de configurer votre noyau pour que FreeBSD puisse communiquer avec l'imprimante. Si votre imprimante est déjà connectée et que vous pouvez imprimer avec un autre système d'exploitation, vous pouvez peut-être passer directement à la section Configuration du logiciel. Ports et Câbles Pratiquement toutes les imprimantes actuelles pour PC supportent l'une ou l'autre interface suivante  - ou les deux: Les interfaces série utilisent un des ports série de votre ordinateur pour envoyer des données à l'imprimante. Les interfaces série sont courantes dans l'industrie informatique et les câbles existent prêts à l'emploi et sont faciles à réaliser soi-même. Certaines interfaces série ont besoin de câbles particuliers ou d'une configuration un peu complexe des options de communication. Les interfaces parallèles utilisent un port parallèle de votre ordinateur pour envoyer des données à l'imprimante. Les interfaces parallèles sont courantes sur le marché des PCs. Les câbles existent prêts à l'emploi, mais sont plus difficiles à faire soi-même. Il n'y a habituellement pas d'option de communication particulière pour les interfaces parallèles, leur configuration est donc extrêmement simple. Les interfaces parallèles sont parfois appelées interfaces “Centronics”, du nom du type de connecteur de l'imprimante. D'une façon générale, les interfaces série sont plus lentes que les interfaces parallèles. Les interfaces parallèles ne permettent normalement la communication que dans un seul sens (de l'ordinateur vers l'imprimante) alors que la communication est bi-directionnelle avec les interfaces série. De nombreux ports parallèles récents peuvent aussi recevoir des données de l'imprimante, mais seules quelques imprimantes savent renvoyer des données à l'ordinateur. Et FreeBSD ne supporte pas la communication parallèle bi-directionnelle. Normalement, vous n'avez besoin de communication bi-directionnelle qu'avec les imprimantes qui parlent PostScript. Les imprimantes PostScript peuvent être très bavardes. En fait, les travaux PostScript sont des programmes envoyés à l'imprimante; ils ne produisent pas nécessairement d'impression et peuvent renvoyer directement leurs résultats à l'ordinateur. PostScript utilise aussi la communication bi-directionnelle pour avertir l'ordinateur de problèmes, d'erreurs dans le programme PostScript ou d'un bourrage papier, par exemple. Cela peut être très apprécié de vos utilisateurs. De plus, la façon la plus efficace de gérer la comptabilité avec une imprimante PostScript passe par un dialogue avec l'imprimante: vous lui demandez la valeur de son compteur de pages (combien de pages elle a déjà imprimées dans sa vie) puis envoyez le travail de l'utilisateur et lui redemandez ensuite la valeur de son compteur de pages. La différence entre les deux valeurs vous donne le nombre de pages à facturer à l'utilisateur. Quelle interface devez-vous donc utiliser? Si vous avez besoin de la communication bi-directionnelle, utilisez le port série. FreeBSD ne supporte pas encore la communication bi-directionnelle sur le port parallèle. Si vous n'avez pas besoin de la communication parallèle et avez le choix entre le port série et le port parallèle, préférez le port parallèle. Le port série reste alors disponible pour d'autres périphériques - comme un terminal ou un modem - et le port parallèle est la plupart du temps plus rapide. Il est aussi plus facile à configurer. En dernier lieu, utilisez ce qui fonctionne. Ports parallèles Pour brancher l'imprimante sur l'interface parallèle, reliez-la à l'ordinateur avec un câble Centronics. La documentation de l'ordinateur, de l'imprimante, ou les deux, devraient vous donner toutes les indications nécessaires. Rappelez-vous quel port parallèle vous avez utilisé. FreeBSD connaît le premier port parallèle sous le nom /dev/lpt0; le second comme /dev/lpt1, et ainsi de suite. Ports série Pour brancher l'imprimante sur l'interface série, reliez-la à l'ordinateur avec le câble série approprié. La documentation de l'ordinateur, de l'imprimante, ou les deux, devrait vous donner toutes les indications nécessaires. Si vous n'êtes pas certain de quel est “le câble série approprié”, vous pouvez tester une des possibilités suivantes: Un câble modem connecte directement chaque broche d'une des extrémité de la liaison à la broche correspondante de l'autre extrémité. On appelle aussi ce type de câble “DTE-à-DCE”. Un câble “null-modem” connecte certaines broches directement, en intervertit d'autres (donnée émise vers donnée reçue) et en court-circuite certaines à chaque extrémité. On appelle aussi ce type de câble “DTE-à-DTE”. Un câble pour imprimante série, dont ont besoin certaines imprimantes non standard, est semblable à un câble “null-modem” mais transmet certains signaux broche à broche au lieu de les court-circuiter. Vous devrez aussi définir les paramètres de communication de l'imprimante, soit avec le panneau de contrôle frontal, soit par l'intermédiaire de commutateurs DIP. Choisissez la vitesse en bps (bits par seconde, on dit parfois vitesse en bauds) la plus rapide que votre ordinateur et votre imprimante acceptent tous les deux. Choisissez entre des données 7 ou 8 bits, une parité paire, impaire ou pas de contrôle de parité; et un ou deux bits de fin. Sélectionnez aussi le protocole de contrôle de flux: soit aucun, soit XON/XOFF (appelé aussi “en ligne” ou “logiciel”). Notez bien ces paramètres pour l'étape suivante de configuration du logiciel. Configuration du logiciel Cette section explique comment configurer le logiciel pour imprimer sous FreeBSD avec le gestionnaire d'impression LPD. Voici un résumé des étapes nécessaires: Recompiler votre noyau au besoin pour le port sur lequel vous connectez votre imprimante; la section Configuration du noyau vous dit ce que vous devez faire. Définir le mode de communication du port parallèle, si c'est celui que vous utilisez; la section Définir le mode de communication avec le port parallèle vous décrit cette étape en détails. Vérifier que le système d'exploitation peut envoyer des données à l'imprimante; la section Tester la communication avec l'imprimante vous donne quelques indications pour cela. Configurer LPD pour cette imprimante en modifiant le fichier /etc/printcap; la section Activer le gestionnaire d'impression : le fichier /etc/printcap vous explique comment. Configuration du noyau Le noyau du système d'exploitation est compilé pour fonctionner avec une sélection de périphériques donnée. Les interfaces série ou parallèle de l'imprimante en font partie. En conséquence, il peut être nécessaire d'ajouter le suppport d'un port série ou parallèle si votre noyau n'est pas déjà configuré pour cela. Pour savoir si le noyau que vous utilisez supporte une interface série, tapez: &prompt.root; dmesg | grep sioN où N est le numéro du port série, zéro ou plus. Si vous obtenez quelque chose qui ressemble à: sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A alors le port est bien configuré dans le noyau. Pour savoir si le noyau que vous utilisez supporte une interface parallèle, tapez: &prompt.root; dmesg | grep lptN où N est le numéro du port parallèle, zéro ou plus. Si vous obtenez quelque chose qui ressemble à: lpt0 at 0x378-0x37f on isa alors le port est bien configuré dans le noyau. Vous devrez peut-être reconfigurer votre noyau pour que le système d'exploitation reconnaisse et puisse utiliser le port série ou parallèle que vous affectez à votre imprimante. Pour ajouter le support d'un port série, reportez-vous au chapitre Configurer le noyau de FreeBSD. Pour ajouter le support d'un port parallèle, reportez-vous au chapitre sur la configuration du noyau et lisez la section suivante. Ajouter les entrées pour les ports dans le répertoire <filename>/dev</filename> Même si le noyau supporte déjà les communications sur le port série ou parallèle, il vous faut encore une interface logicielle pour que les programmes puissent envoyer et recevoir des données. C'est à cela que servent les entrées du répertoire /dev. Pour ajouter une entrée pour un port au répertoire /dev: Devenez super-utilisateur avec la commande su. Entrez le mot de passe super-utilisateur quand on vous le demande. Allez dans le répertoire /dev: &prompt.root; cd /dev Tapez: &prompt.root; ./MAKEDEV port où port est l'entrée (fichier spécial de périphérique) que vous voulez créer. Utilisez lpt0 pour le premier port parallèle, lpt1 pour le second, et ainsi de suite; utilisez ttyd0 pour le premier port série, ttyd1 pour le second, etc... Tapez: &prompt.root; ls -l port pour vous assurer que l'entrée a bien été créée. Définir le mode de communication avec le port parallèle Si vous utilisez l'interface parallèle, vous pouvez choisir que FreeBSD communique avec l'imprimante en l'interrogeant régulièrement ou par interruptions. La méthode pilotée par interruptions est la méthode par défaut du noyau GENERIC. Le système d'exploitation utilise dans ce cas une ligne IRQ pour savoir si l'imprimante est prête à recevoir des données. La méthode par interrogations demande au système d'interroger à intervalles réguliers l'imprimante pour savoir si elle peut accepter de nouvelles données. Dès que la réponse est positive, le noyau lui envoie de nouvelles données. La méthode par interruptions est plus rapide mais mobilise une ligne IRQ précieuse. Utilisez ce qui fonctionne. Vous pouvez définir le mode de communication de deux façons: en configurant le noyau ou avec la commande lptcontrol. Pour définir le mode de communication à la configuration du noyau: Editez votre fichier de configuration du noyau et cherchez ou ajoutez l'entrée lpt0. Si vous utilisez le second port parallèle, mettez lpt1 à la place, lpt2 pour le troisième port, et ainsi de suite. Si vous voulez utiliser le mode par interruptions, ajoutez l'indicateur irq: device lpt0 at isa? port? tty irq N vector lptintr où N est le numéro d'IRQ du port parallèle de votre ordinateur. Si vous voulez le mode par interrogations, ne mettez pas l'indicateur irq: device lpt0 at isa? port? tty vector lptintr Sauvegardez le fichier. Puis configurez, compilez et installez le noyau, et redémarrez votre système. Reportez-vous au chapitre Configurer le noyau de FreeBSD pour plus de détails. Pour définir le mode de communication avec le programme lptcontrol: Tapez: &prompt.root; lptcontrol -i -u N pour utiliser le mode par interruptions avec lptN. Tapez: &prompt.root; lptcontrol -p -u N pour utiliser le mode par interrogations avec lptN. Vous pouvez introduire ces commandes dans votre fichier /etc/rc.local pour définir le mode à chaque redémarrage. Voyez lptcontrol8 pour plus d'informations. Tester la communication avec l'imprimante Avant de passer à la configuration du gestionnaire d'impression, vous devriez vous assurer que le système d'exploitation arrive à envoyer des données à l'imprimante. Il est plus facile de mettre séparement au point la communication avec l'imprimante et la configuration du gestionnaire d'impression. Pour tester l'imprimante, nous lui enverrons du texte. Pour les imprimantes qui impriment immédiatement les caractères qu'on leur envoie, le programme lptest est idéal: il génère les 96 caractères ASCII imprimables sur 96 lignes. Pour une imprimante PostScript (ou tout autre imprimante utilisant un langage), il nous faut un test plus sophistiqué. Un petit programme PostScript, comme celui qui suit, fera l'affaire: %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Is this thing working?) show showpage Quand dans ce document j'utilise l'expression “langage d'impression”, je me réfère à un langage du type PostScript et non du genre PCL de Hewlett Packard, bien que PCL ait d'excellentes fonctionnalités - on peut insérer du texte au milieu de ses séquences d'échappement. PostScript ne peut imprimer directement du texte, et c'est pour ce genre de langage qu'il y a des mesures particulières à prendre. Tester une imprimante parallèle Cette section vous explique comment tester si FreeBSD peut communiquer avec une imprimante connectée sur un port parallèle. Pour tester une imprimante sur un port parallèle: Devenez super-utilisateur avec su. Envoyez des données à l'imprimante. Si l'imprimante accepte directement du texte, utilisez lptest. Tapez: &prompt.root; lptest > /dev/lptN où N est le numéro du port parallèle, à partir de zéro. Si l'imprimante comprend PostScript ou un autre langage d'impression, alors envoyez-lui un petit programme. Tapez: &prompt.root; cat > /dev/lptN Puis tapez votre programme ligne à ligne avec soin car vous ne pouvez pas corriger la ligne une fois que vous avez tapé Entrée. Quand vous avez fini de saisir votre programme, tapez CONTROL+D, ou une autre combinaison particulière de touches, pour indiquer la fin du fichier. Vous pouvez aussi mettre votre programme dans un fichier et taper: &prompt.root; cat fichier > /dev/lptN où fichier est le nom du fichier contenant le programme que vous voulez envoyer à l'imprimante. Vous devriez obtenir une impression. Ne vous inquiétez pas si le texte ne s'imprime pas correctement; nous réglerons ces problèmes ensuite. Tester une imprimante série Cette section vous explique comment tester si FreeBSD peut communiquer avec une imprimante connectée sur un port série. Pour tester une imprimante sur un port série: Devenez super-utilisateur avec su. Editez le fichier /etc/remote. Ajoutez la ligne suivante: printer:dv=/dev/port:br#bps:pa=parité où port est le fichier spécial de périphérique pour le port série (ttyd0, ttyd1, etc...), bps est la vitesse de communication en bits par seconde, et parité est la parité requise par l'imprimante (soit even (paire), odd (impaire), none (aucune), ou zero (toujours nulle) ). Voici un exemple pour une imprimante connectée par une ligne série au troisième port série, à 19200 bps, sans contrôle de parité: printer:dv=/dev/ttyd2:br#19200:pa=none Connectez-vous à l'imprimante avec tip. Tapez: &prompt.root; tip printer Si cela ne marche pas, éditez de nouveau le fichier /etc/remote et essayez de remplacer /dev/ttydN par /dev/cuaaN. Envoyez des données à l'imprimante. Si l'imprimante accepte directement du texte, utilisez lptest. Tapez: ~$lptest Si votre imprimante comprend PostScript ou un autre langage d'impression, envoyez-lui alors un petit programme. Tapez le programme, ligne à ligne, en faisant très attention car le retour arrière ou d'autres touches d'éditions peuvent vouloir dire autre chose pour l'imprimante. Vous devrez peut-être aussi utiliser un caractère particulier de fin de fichier pour que l'imprimante sache qu'elle a reçu tout le programme. Pour les imprimantes PostScript, tapez CONTROL+D. Vous pouvez aussi enregistrer votre programme dans un fichier et taper: ~>fichier où fichier est le nom du fichier contenant le programme. Après que tip ait envoyé le fichier, appuyez sur la touche de fin de fichier adéquate. Vous devriez obtenir une impression. Ne vous inquiétez pas si le texte ne s'imprime pas correctement; nous réglerons ces problèmes ensuite. Activer le gestionnaire d'impression: Le fichier <filename>/etc/printcap</filename> A ce stade, votre imprimante devrait être connectée, votre noyau configuré (au besoin) pour communiquer avec, et vous devriez avoir réussi à lui envoyer un minimum de données. Nous sommes maintenant prêt à configurer LPD pour qu'il contrôle l'accès à votre imprimante. Vous configurez LPD en éditant le fichier /etc/printcap. Le gestionnaire d'impression LPD lit ce fichier chaque fois qu'il est fait appel à lui, les modifications s'appliquent donc immédiatement. Le format du fichier printcap est explicite. Utilisez votre éditeur de texte préféré pour le modifier. Son format est similaire à celui des fichiers associés à d'autres utilitaires comme /usr/share/misc/termcap et /etc/remote. Pour une description complète de ce format, reportez-vous à cgetent3. Une configuration de base du gestionnaire d'impression passe par les étapes suivantes: Choisissez un nom (et quelques alias utiles) pour l'imprimante et introduisez-le(s) dans le fichier /etc/printcap; reportez-vous à la section Donner un nom à l'imprimante. Désactivez l'impression des pages d'en-tête (qui sont en service par défaut) en insérant la fonctionnalité sh; reportez-vous à la section Supprimer l'impression des pages d'en-tête. Créez un répertoire pour la file d'attente, et indiquez où il se trouve avec l'option sd; reportez-vous à la section Créer le répertoire tampon. Identifiez l'entrée /dev à utiliser avec cette imprimante et reportez-la dans le fichier /etc/printcap avec l'option lp; reportez-vous à la section Définir le périphérique associé à l'imprimante. Si l'imprimante est sur un port série, vous devez aussi préciser les paramètres de communication avec les options fs, fc, xs, et xc; reportez-vous à la section Configurer les paramètres de communication du gestionnaire d'impression. Installez un filtre pour l'impression de fichiers texte; reportez-vous à la section Installer le filtre texte. Testez la configuration en imprimant quelque chose avec la commande lpr; reportez-vous aux sections Tester la configuration et Régler les problèmes. Les imprimantes qui utilisent un langage, comme les imprimantes PostScript, ne savent pas imprimer directement du texte. La configuration simple résumée ci-desssus, et décrite dans ce qui suit, suppose que si vous installez ce type d'imprimante, vous lui enverrez uniquement des fichiers qu'elle comprenne. Les utilisateurs s'attendent souvent à pouvoir imprimer du texte simple sur toutes les imprimantes de votre système. Les programmes qui font appel à LPD font la même supposition. Si vous installez ce type d'imprimante et que vous voulez utiliser le langage d'impression et imprimer aussi des fichiers texte, je vous conseille fortement d'ajouter une étape supplémentaire à la procédure résumée ci-dessus: installez un filtre de conversion automatique des fichiers texte en PostScript (ou tout autre langage d'impression). La section Imprimer du texte sur des imprimantes PostScript vous explique comment faire. Donner un nom à l'imprimante La première étape (facile) consiste à donner un nom à l'imprimante. Cela n'a pas d'importance que vous lui donniez un nom fonctionnel ou nom bizarre parce que vous pouvez aussi définir un certain nombre d'alias. Au moins l'une des imprimantes que vous définirez dans le fichier /etc/printcap devrait s'appeler lp. C'est le nom de l'imprimante par défaut. Si les utilisateurs ne définissent pas leur variable d'environnement PRINTER et ne précisent pas le nom de l'imprimante avec une des commandes de LPD, alors lp est l'imprimante par défaut à laquelle ils s'adressent. Il est aussi d'usage que le dernier alias d'une imprimante la décrive complètement, marque et modèle y compris. Un fois que vous avez choisi un nom et quelques alias courants, introduisez-les dans le fichier /etc/printcap. Le nom de l'imprimante doit être écrit au début de la ligne. Séparez chaque alias par une barre verticale et mettez un “:” après le dernier alias. L'exemple suivant montre un fichier /etc/printcap de base, qui définit deux imprimantes (une imprimante ligne Diablo 630 et une imprimante laser PostScript Panasonic KX-P4455): # # /etc/printcap pour la machine rose # rattan|line|diablo|lp|Imprimante Ligne Diablo 630: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: Dans cet exemple, la première imprimante s'appelle rattan et a pour alias line, diablo, lp, et Imprimante Ligne Diablo 630. Comme lp est un de ses alias, c'est aussi l'imprimante par défaut. La seconde s'appelle bamboo, et a pour alias ps, PS, S, panasonic, et Panasonic KX-P4455 PostScript v51.4. Supprimer l'impression de pages d'en-tête Le gestionnaire d'impression générera par défaut une page d'en-tête pour chaque travail d'impression. La page d'en-tête affiche le nom de l'utilisateur qui l'a soumis, le nom de la machine d'où il a été lancé et le nom du travail d'impression, le tout en grosses lettres. Malheureusement, tout ce texte supplémentaire complique la mise au point de la configuration des imprimantes, aussi supprimerons-nous les pages d'en-tête. Pour supprimer les pages d'en-tête, ajoutez la fonctionnalité sh à l'entrée associée à l'imprimante dans le fichier /etc/printcap. Voici un exemple de fichier /etc/printcap où l'on a ajouté sh: # # /etc/printcap pour la machine rose - pas de pages d'en-tête # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: Notez bien le format correct. La première ligne commence immédiatement à gauche, et les lignes suivantes sont indentées avec un seul caractère Tab. Chaque ligne d'une même entrée, sauf la dernière, se termine par une barre oblique inverse. Créer le répertoire tampon L'étape suivante de la configuration de base du gestionnaire d'impression consiste à créer un répertoire tampon, où les travaux d'impression attendent d'être traités et où se trouvent aussi un certain nombre de fichiers nécessaires au gestionnaire d'impression. Comme le contenu de ces répertoires tampon est transitoire, il est habituel de les mettre dans le répertoire /var/spool. Ces répertoires n'ont pas non plus besoin d'être archivés. Il suffit d'un simple mkdir pour les recréer. L'usage veut que l'on donne au répertoire le même nom qu'à l'imprimante, comme ci-dessous: &prompt.root; mkdir /var/spool/imprimante Cependant, s'il y a beaucoup d'imprimantes sur votre réseau, vous voudrez peut-être regrouper tous les répertoires tampon dans un seul répertoire qui sera réservé à l'impression par LPD. C'est ce que nous ferons pour nos deux imprimantes rattan et bamboo: &prompt.root; mkdir /var/spool/lpd &prompt.root; mkdir /var/spool/lpd/rattan &prompt.root; mkdir /var/spool/lpd/bamboo Si la confidentialité des travaux d'impression de vos utilisateurs vous préoccuppe, vous pouvez protéger le répertoire tampon pour qu'il ne soit pas accessible à tout le monde. Les répertoires tampon doivent appartenir, être accessibles en lecture et en écriture et pouvoir être parcourus par l'utilisateur daemon et le groupe daemon. C'est ce que nous ferons pour les imprimantes de notre exemple: &prompt.root; chown daemon.daemon /var/spool/lpd/rattan &prompt.root; chown daemon.daemon /var/spool/lpd/bamboo &prompt.root; chmod 770 /var/spool/lpd/rattan &prompt.root; chmod 770 /var/spool/lpd/bamboo En dernier lieu, il faut donner à LPD les noms de ces répertoires par l'intermédiaire du fichier /etc/printcap. Cela se fait avec la fonctionnalité sd: # # /etc/printcap pour la machine rose - ajout des répertoires tampon # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: Notez bien que le nom de l'imprimante commence en première colonne, que toutes les autres lignes doivent être indentées par une tabulation et que toutes les lignes sauf la dernière se terminent par une barre oblique inverse. Si vous ne définissez pas le répertoire tampon avec sd, le gestionnaire d'impression utilisera /var/spool/lpd par défaut. Définir le périphérique associé à l'imprimante Dans la section Ajouter les entrées pour les ports dans le répertoire /dev, nous avons identifié l'entrée du répertoire /dev via laquelle FreeBSD communiquera avec l'imprimante. Il faut maintenant donner cette information à LPD. Quand le gestionnaire aura un travail à imprimer, il ouvrira le fichier spécial pour les besoins du programme filtre (qui envoie les données à l'imprimante). Indiquez l'entrée /dev utilisée avec la fonctionnalité lp dans le fichier /etc/printcap. Supposons que, dans notre exemple, l'imprimante rattan soit sur le premier port parallèle et et l'imprimante bamboo sur le sixième; voici ce qu'il faut ajouter au fichier /etc/printcap: # # /etc/printcap pour la machine rose # définition des périphériques à utiliser # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: Si vous ne donnez pas de valeur lp à une imprimante dans le fichier /etc/printcap, LPD utilise /dev/lp par défaut. /dev/lp n'existe actuellement pas sous FreeBSD. Si l'imprimante est connectée à un port parallèle, allez directement à la section Installer le filtre texte. Sinon, suivez bien les instructions de la prochaine section. Configurer les paramètres de communication du gestionnaire d'impression Pour les imprimantes sur des ports série, LPD peut définir la vitesse en bps, la parité et les autres paramètres de communication série, pour les besoins du programme filtre, qui envoie les données à l'imprimante. C'est intéressant parce que: Cela vous permet de tester des valeurs différentes des paramètres en modifiant simplement le fichier /etc/printcap; vous n'avez pas besoin de recompiler le programme filtre. Cela permet au gestionnaire d'impression d'utiliser le même programme filtre pour différentes imprimantes qui n'ont pas les mêmes paramètres de communication. Les fonctionnalités suivantes de /etc/printcap contrôlent les paramètres de communication série du périphérique spécifié avec la fonctionnalité lp: br#vitesse_en_bps Fixe la vitesse de communication à vitesse_en_bps, où vitesse_en_bps peut prendre les valeurs 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, ou 38400 bits par seconde. fc#bits_à_réinitialiser Réinitialise les indicateurs bits_à_réinitialiser de la structure sgttyb après avoir ouvert le fichier spécial de périphérique. fs#bits_à_positionner Positionne les indicateurs bits_à_positionner de la structure sgttyb. xc#bits_à_réinitialiser Réinitialise les indicateurs du mode local bits_à_rénitialiser après avoir ouvert le fichier spécial de périphérique. xs#bits_à_positionner Positionne les indicateurs du mode local bits_à_positionner. Pour plus d'informations sur les bits manipulés par les fonctionnalités fc, fs, xc, et xs, reportez-vous au fichier /usr/include/sys/ioctl_compat.h. Quand LPD ouvre le périphérique défini par la fonctionnalité lp, il lit les indicateurs de la structure sgttyb; il réinitialise les bits définis par la fonctionnalité fc, puis positionne ceux définis par la fonctionnalité fs et applique le paramètrage ainsi défini. Il fait de même pour les indicateurs du mode local. Complétons notre exemple pour l'imprimante sur le sixième port série. Nous fixerons la vitesse à 38400 bps. Nous positionnerons les indicateurs TANDEM, ANYP, LITOUT, FLUSHO, et PASS8, et les indicateurs du mode local LITOUT et PASS8: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000c1:xs#0x820: Installer le filtre texte Nous sommes maintenant prêts à dire à LPD quel filtre texte utiliser pour envoyer les travaux à l'imprimante. Un filtre texte, aussi appelé filtre d'entrée, est un programme que LPD exécute quand il a un travail à imprimer. Quand LPD exécute un filtre texte pour une imprimante, il affecte à l'entrée standard du filtre le travail à imprimer et à sa sortie standard le fichier spécial de périphérique défini par la fonctionnalité lp. Le filtre est supposé lire le travail sur l'entrée standard, effectuer le transcodage nécessaire et envoyer le résultat sur la sortie standard. Pour plus d'informations sur les filtres texte, reportez-vous à la section Comment fonctionnent les filtres. Pour notre exemple de configuration simple, le filtre texte peut être une petite procédure qui exécute seulement /bin/cat pour envoyer le travail à l'imprimante. FreeBSD est livré avec un autre filtre appelé lpf qui gère les retours arrière et les soulignés pour les imprimantes qui ne traitent pas bien ces caractères de contrôle. Et, bien sûr, vous pouvez utilisez le filtre que vous voulez. Le filtre lpf est décrit en détail à la section lpf: un filtre texte. Créons d'abord le filtre texte élémentaire /usr/local/libexec/if-simple. Avec votre éditeur de texte favori, donnez à ce fichier le contenu suivant: #!/bin/sh # # if-simple - filtre texte élémentaire pour lpd # fichier /usr/local/libexec/if-simple # # copie simplement stdin dans stdout. Ne prend aucun argument. /bin/cat && exit 0 exit 2 Mettez les droits d'exécution sur le fichier: &prompt.root; chmod 555 /usr/local/libexec/if-simple Et précisez maintenant à LPD de l'utiliser avec la fonctionnalité if de /etc/printcap. Nous l'affecterons aux deux imprimantes que nous avons déjà dans notre exemple de /etc/printcap: # # /etc/printcap pour la machine rose - ajout du filtre texte # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\ :if=/usr/local/libexec/if-simple: Tester la configuration Vous avez terminé la configuration simple de LPD. Malheureusement, les félicitations ne sont pas encore de mise, il nous faut d'abord faire une essai et régler tous les problèmes. Pour tester la configuration, essayez d'imprimer quelque chose. Pour imprimer avec le gestionnaire LPD, vous invoquez la commande lpr, qui soumet un travail d'impression. Vous pouvez combiner lpr et le programme lptest, dont nous avons parlé à la section Tester la communication avec l'imprimante, pour générer du texte pour le test. Tester la configuration simple de LPD: Tapez: &prompt.root; lptest 20 5 | lpr -Pimprimante où imprimante est le nom d'une imprimante (ou un alias) définie dans /etc/printcap. Pour tester l'imprimante par défaut, tapez lpr sans argument . Encore une fois, si vous tester une imprimante qui attend du PostScript, envoyez-lui un programme PostScript au lieu d'utiliser lptest. Vous pouvez le faire en mettant ce programme dans un fichier et en tapant lpr fichier. Avec une imprimante PostScript, vous devriez voir les résultats du programme. Si vous utilisez lptest, alors le résultat devrait ressembler à ce qui suit: !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678 Pour faire d'autres essais, envoyez des programmes plus longs (aux imprimantes qui comprennent un langage) ou exécutez lptest avec d'autres arguments. Par exemple, lptest 80 60 qui générera 60 lignes de 80 caractères chacune. Si l'imprimante ne fonctionne pas, voyez la section suivante Régler les problèmes. Régler les problèmes Après le test élémentaire avec lptest, vous pouvez avoir rencontré l'un des problèmes suivants, au lieu d'obtenir une impression correcte: Cela a marché quelque temps; ou, l'imprimante n'a pas éjecté la page. L'imprimante a bien imprimé les résultats du test ci-dessus, puis s'est arrêtée et n'a rien fait. Il vous aurait peut être fallu appuyer sur le bouton “Avance Papier” ou “Continuer l'Impression” pour obtenir la suite. Dans ce cas, l'imprimante attendait probablement la suite de votre travail avant d'imprimer quoi que ce soit. Pour régler le problème, vous pouvez modifier le filtre texte pour qu'il envoie un caractère de saut de page (“FORM FEED”) - ou tout autre caractère nécessaire - à l'imprimante. Cela suffit généralement pour que l'imprimante traite immédiatement le texte qu'elle a encore en mémoire. C'est aussi utile pour être sûr que chaque travail d'impression se termine sur une page complète, de sorte que le travail suivant ne commence pas sur la dernière page du travail qui le précède. Voici une procédure /usr/local/libexec/if-simple modifiée qui envoie un saut de page à la fin du travail d'impression: #!/bin/sh # # if-simple - filtre texte élémentaire pour lpd # fichier /usr/local/libexec/if-simple # # copie simplement stdin dans stdout. Ne prend aucun argument. # envoie un caractère de saut de page (\f) en fin d'impression. /bin/cat && printf "\f" && exit 0 exit 2 Le texte s'est imprimé “en escalier.” Si vous obtenez ce qui suit: !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 $%&'()*+,-./0123456 vous êtes la nouvelle victime de l'effet d'escalier, dû à une interprétation divergente des caractères de saut de ligne. Les systèmes d'exploitation de type Unix utilisent un seul caractère: le code ASCII 10, ou saut de ligne (LF - “Line Feed”). MS-DOS, OS/2 et d'autres utilisent deux caractères, le code ASCII 10 et le code ASCII 13 (le retour-chariot ou CR - “Carriage Return”). De nombreuses imprimantes emploient les conventions MS-DOS pour passer à la ligne. Quand vous imprimez avec FreeBSD, votre texte ne contient que le caractère de saut de ligne. L'imprimante passe alors à la ligne suivante, mais ne revient pas en début de ligne. C'est à cela que sert le retour-chariot: revenir au début de ligne avant d'imprimer le prochain caractère. Voici ce que FreeBSD attend de votre imprimante: L'imprimante reçoit L'imprimante imprime CR CR LF CR + LF Il y a plusieurs façons d'y arriver: Utilisez les interrupteurs du panneau de contrôle de l'imprimante pour modifier la façon dont elle interprète ces caractères. Voyez le mode d'emploi de votre imprimante pour savoir comment faire. Si vous utilisez aussi sur votre machine d'autres systèmes d'exploitation que FreeBSD, vous devrez peut-être configurer votre imprimante pour qu'elle interprète CR et LF en fonction de la manière dont ces autres systèmes d'exploitation les utilisent. Vous préférerez alors une des autres solutions ci-dessous. Faire en sorte que le pilote de liaison série de FreeBSD convertisse les LF en CR+LF. Cela ne marche, bien entendu, qu'avec les imprimantes sur des ports série. Pour cela, positionnez le bit CRMOD de la fonctionnalité fs de l'imprimante dans le fichier /etc/printcap. Envoyer une séquence d'échappement à l'imprimante pour qu'elle traite temporairement les caractères LF de façon différente. Consultez la documentation de votre imprimante pour connaître la commande adéquate. Une fois que vous l'avez trouvée, modifiez le filtre pour qu'il envoie cette commande avant le travail d'impression. Voici un exemple de filtre texte pour les imprimantes qui acceptent les séquences d'échappement du langage PCL de Hewlett-Packard. Ce filtre envoie la commande qui dit à l'imprimante de traiter les caractères LF comme un CR et un LF, puis le travail d'impression et enfin un saut de page pour éjecter la dernière page. Il devrait être utilisable avec presque toutes les imprimantes Hewlett-Packard. #!/bin/sh # # hpif - filtre texte élémentaire pour lpd # pour les imprimantes compatibles HP-PCL # fichier /usr/local/libexec/hpif # # copie simplement stdin dans stdout. Ne prend aucun argument. # dit à l'imprimante de traiter LF comme un CR+LF # envoie un caractere de saut de page (\f) en fin d'impression. printf "\033&k2G" && cat && printf "\f" && exit 0 exit 2 Voici un exemple de fichier /etc/printcap pour une machine appelée orchid. Elle a une seule imprimante sur son premier port parallèle, une LaserJet 3Si Hewlett-Packard appelée teak. Elle utilise la procédure ci-dessus comme filtre texte: # # /etc/printcap pour la machine orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: Les lignes se superposent. L'imprimante n'a jamais avancé d'une ligne. Toutes les lignes sont imprimées les unes sur les autres. C'est le problème “inverse” de l'effet d'escalier décrit ci-dessus, et c'est plus rare. Pour une raison quelconque, les caractères LF que FreeBSD emploie en fin de ligne sont compris comme des caractères CR de retour en début de ligne, sans passage à la ligne. Utilisez les interrupteurs du panneau de contrôle de l'imprimante pour modifier comme suit son interprétation des caractères LF et CR. L'imprimante reçoit L'imprimante imprime CR CR LF CR + LF L'imprimante perd des caractères. En cours d'impression, l'imprimante perd quelques caractères de chaque ligne. Cela peut aller de mal en pis, de plus en plus de caractères se perdent. Le problème tient à ce que l'imprimante ne suit pas le rythme auquel l'ordinateur lui envoie des données sur la ligne série. (Ce problème ne devrait pas se produire avec les imprimantes sur des ports parallèles.) Il y a deux façons de résoudre ce problème: Si l'imprimante gère le contrôle de flux XON/XOFF, faites en sorte que FreeBSD l'utilise en positionnant le bit TANDEM de la fonctionnalité fs. Si l'imprimante gère le contrôle de flux matériel, positionnez le bit MDMBUF de la fonctionnalité fs. Vérifiez que le câble qui relie l'imprimante à l'ordinateur est bien conçu pour transmettre les signaux de contrôle de flux (CTS/RTS). Si l'imprimante ne gère aucun protocole de contrôle de flux, utilisez la bonne combinaison de bits NLDELAY, TBDELAY, CRDELAY, VTDELAY, et BSDELAY de la fonctionnalité fs pour introduire les délais appropriés dans le flot de données envoyé à l'imprimante. Cela imprime n'importe quoi. Ce qui s'imprime ressemble à tout, sauf au texte attendu. C'est en général un autre symptôme d'un paramétrage incorrect de la communication avec une imprimante série. Vérifiez la vitesse en bps de la fonctionnalité br, et les bits de parité des fonctionnalités fs et fc; assurez-vous que l'imprimante utilise les mêmes paramètres que ceux définis dans le fichier /etc/printcap. Il ne se passe rien. S'il ne se passe rien, le problème vient probablement de FreeBSD et non du matériel. Ajoutez la fonctionnalité de trace (lf) à l'entrée associée à l'imprimante que vous testez, dans le fichier /etc/printcap. Par exemple, voici l'entrée pour rattan, avec la fonctionnalité lf: rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log Refaites ensuite un essai d'impression et consultez le fichier de trace (/var/log/rattan.log, dans notre exemple) pour voir s'il y a des messages d'erreur. Essayez ensuite de corriger le problème au vu de ces messages. Si vous n'utilisez pas la fonctionnalité lf, LPD utilise /dev/console par défaut. Utiliser les imprimantes Cette section vous explique comment utiliser les imprimantes que vous avez configurées pour FreeBSD. Voici un résumé des commandes utilisateur: lpr Imprime les travaux. lpq Consulte la file d'attente. lprm Retire des travaux de la file d'attente. Il y a aussi une commande d'administration, lpc, décrite dans la section Administrer les imprimantes, qui sert à gérer les imprimantes et leurs files d'attente. Chacune des trois commandes lpr, lprm, et lpq accepte l'option pour préciser à quelle imprimante/file d'attente, définie dans le fichier /etc/printcap, elle s'applique. Vous pouvez alors soumettre, annuler et consulter l'état de vos travaux sur les différentes imprimantes. Si vous omettez l'option , ces commandes s'appliquent à l'imprimante définie par la variable d'environnement PRINTER. En dernier ressort, si vous n'avez pas défini la variable d'environnement PRINTER, ces commandes s'appliquent par défaut à l'imprimante appelée lp. Dans ce qui suit, le terme imprimante par défaut désigne donc l'imprimante définie par la variable d'environnement PRINTER, ou l'imprimante appelée lp s'il n'y a pas de variable d'environnement PRINTER. Imprimer Pour imprimer des fichiers, tapez: &prompt.user; lpr fichier ... Cela imprime chacun des fichiers indiqués sur l'imprimante par défaut. Si vous ne donnez pas de nom de fichier, lpr lit les données à imprimer sur l'entrée standard. Par exemple, la commande: &prompt.user; lpr /etc/host.conf /etc/hosts.equiv imprime des fichiers système importants. Pour choisir l'imprimante, tapez: &prompt.user; lpr -P imprimante fichier ... Cet exemple imprime la liste longue du répertoire courant sur l'imprimante appelée rattan: &prompt.user; ls -l | lpr -P rattan Comme on n'a pas donné de nom de fichier à la commande lpr, elle lit les données à imprimer sur l'entrée standard, qui est ici le résultat de la commande ls -l. La commande lpr accepte une grande variété d'options pour contrôler le format, convertir les fichiers, imprimer plusieurs copies et ainsi de suite. Pour plus d'informations, reportez-vous à la section Au-delà du simple texte : options d'impression. Consulter l'état de la file d'attente Quand vous imprimez avec lpr, les données que vous voulez imprimer sont regroupées dans un “travail d'impression”, qui est envoyé au gestionnaire LPD. Chaque imprimante a sa file d'attente des travaux d'impression, et le votre y est mis en attente avec vos autres travaux et ceux des autres utilisateurs. L'imprimante les traite sur la base du premier arrivé, premier servi. Pour connaître l'état de la file d'attente de l'imprimante par défaut, tapez: lpq. Pour une imprimante particulière, utilisez l'option . Par exemple, la commande: &prompt.user; lpq -P bamboo affiche la file d'attente de l'imprimante appelée bamboo. Voici un exemple de résultat de la commande lpq: bamboo is ready and printing Rank Owner Job Files Total Size active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes 2nd kelly 10 (standard input) 1635 bytes 3rd mary 11 ... 78519 bytes Il y a trois travaux dans la file d'attente de bamboo. Le premier, soumis par l'utilisateur kelly, a été affecté du “numéro de travail” 9. A chaque travail est attribué un numéro de travail unique. La plupart du temps, vous n'avez pas besoin de le connaître, sauf si vous voulez annuler l'impression; reportez-vous à la section Annuler des impressions pour plus de détails. Le travail numéro neuf comporte deux fichiers à imprimer; lorsque plusieurs noms de fichiers sont donnés en paramètres de la commande lpr, ils sont traités en un seul travail d'impression. C'est le travail en cours (ce qu'indique la mention active dans la colonne “Rank”), ce qui signifie que l'imprimante devrait être en train de l'imprimer. Le deuxième travail est constitué par des données passées de l'entrée standard à la commande lpr. Le troisième travail vient de l'utilisateur mary; il est bien plus volumineux. Les noms des fichiers qu'elle veut imprimer sont trop longs, c'est pourquoi la commande lpq n'affiche que trois points. La première ligne du résultat de lpq est aussi utile: elle dit ce que l'imprimante est en train de faire (ou tout du moins, ce que LPD pense qu'elle est en train de faire). La commande lpq accepte aussi l'option qui génère une sortie détaillée. Voici un exemple de résultat de lpq -l: waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes Annuler des impressions Si vous changez d'avis quant à un travail d'impression, vous pouvez le retirer de la file d'attente avec la commande lprm. La plupart du temps, vous pouvez même utiliser lprm pour annuler une impression en cours, mais il se peut que tout ou une partie du travail soit malgré tout imprimé. Pour annuler une impression sur l'imprimante par défaut, utilisez lpq pour connaître le numéro du travail. Puis tapez: &prompt.user; lprm numéro_du_travail Pour annuler une impression sur une imprimante donnée, ajoutez l'option . La commande qui suit retire le travail d'impression numéro 10 de la file d'attente de l'imprimante bamboo: &prompt.user; lprm -P bamboo 10 La commande lprm accepte différents raccourcis: lprm - Annule tous les travaux (sur l'imprimante par défaut) qui vous appartiennent. lprm utilisateur Annule tous les travaux (sur l'imprimante par défaut) qui appartiennent à l'utilisateur. Le super-utilisateur peut annuler les travaux d'impression des autres utilisateurs; vous ne pouvez retirer que vos propres travaux. lprm Sans numéro de travail, nom d'utilisateur, ou sur la ligne de commande, lprm retire le travail en cours de la file d'attente de l'imprimante par défaut, s'il vous appartient. Le super-utilisateur peut annuler n'importe quel travail en cours. Employez simplement l'option avec les raccourcis ci-dessus pour les appliquer à une autre imprimante que l'imprimante par défaut. La commande suivante, par exemple, retire tous les travaux de l'utilisateur courant de la file d'attente de l'imprimante appelée rattan: &prompt.user; lprm -P rattan - Si vous travaillez dans un environnement en réseau, vous ne pourrez annuler de travaux avec lprm que depuis la machine à partir de laquelle ils ont été soumis, même si l'imprimante concernée est accessible depuis d'autres machines. C'est ce qu'illustre la séquence suivante: &prompt.user; lpr -P rattan myfile &prompt.user; rlogin orchid &prompt.user; lpq -P rattan Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes &prompt.user; lprm -P rattan 13 rose: Permission denied &prompt.user; logout &prompt.user; lprm -P rattan 13 dfA013rose dequeued cfA013rose dequeued Au-delà du simple texte: options d'impression La commande lpr accepte un certain nombre d'options qui contrôlent la mise en page, la conversion des graphiques et d'autres formats de fichiers, le nombre de copies, et autres. Cette section décrit ces options. Options de mise en page et de conversion Les options de lpr ci-dessous contrôlent la mise en page des fichiers d'un travail d'impression. Utilisez-les si vos fichiers ne contiennent pas uniquement du texte ou si vous voulez formater du texte avec l'utilitaire pr. Par exemple, la commande suivante imprime un fichier DVI (produit par le traitement de texte TeX) appelé rapport-poissons.dvi sur l'imprimante appelée bamboo: &prompt.user; lpr -P bamboo -d rapports-poissons.dvi Ces options sont valables pour tous les fichiers du travail d'impression, vous ne pouvez donc pas mélanger des fichiers DVI et ditroff (par exemple). Vous devez les soumettre dans des travaux séparés avec des options de conversion différentes pour chaque travail. Toutes ces options, sauf et impliquent que les filtres de conversion soient installés pour les imprimantes utilisées. Pour l'option , par exemple, il faut le filtre de conversion DVI. La section Filtres de conversion vous explique cela en détail. Imprime des fichiers cifplot. Imprime des fichiers DVI. Imprime des programmes FORTRAN. Imprime des graphiques pour un traceur (“plot”). Indente la sortie de nombre de colonnes; si vous ne précisez pas nombre, indente de 8 colonnes. Cette option ne s'applique qu'à certains filtres de conversion. Ne mettez pas de blanc entre et le nombre. Imprime le texte tel quel, y compris les caractères de contrôle. Imprime des données ditroff (troff indépendant du périphérique - “device independent troff”). -p Formate du texte avec pr avant de l'imprimer. Voyez pr1 pour plus informations. Utilise titre comme en-tête pr au lieu du nom de fichier. Cette option ne s'applique qu'avec l'option . Imprime des données troff. Imprime des images point par point. Voici un exemple: cette commande imprime une version proprement formatée des pages de manuel de ls sur l'imprimante par défaut: &prompt.user; zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -t La commande zcat décompresse le source des pages de manuel de ls et les passe à la commande troff, qui les convertit au format GNU troff et le passe à lpr, qui soumet le travail au gestionnaire d'impression. Comme nous avons utilisé l'option de la commande lpr, le gestionnaire d'impression convertira le format GNU troff en un format compréhensible par l'imprimante. Options de traitement Les options lpr qui suivent indiquent à LPD les traitements particuliers à appliquer à un travail d'impression: -# nombre Produit le nombre de copies de chaque fichier du travail d'impression, au lieu d'une seule. L'administrateur peut désactiver cette option pour réduire l'usure de l'imprimante et encourager l'utilisation de la photocopieuse. Reportez-vous à la section Restreindre l'impression de plusieurs exemplaires. Cet exemple imprime trois exemplaires du fichier analyseur.c suivis de trois exemplaires de analyseur.h sur l'imprimante par défaut: &prompt.user; lpr -#3 analyseur.c analyseur.h -m Envoie un courrier électronique à la fin du travail d'impression. Avec cette option, LPD vous envoie un courrier électronique quand il a fini de traiter votre travail d'impression. Son message vous dit si le travail s'est normalement déroulé ou s'il y a eu une erreur, et (la plupart du temps) quelle était l'erreur. -s Ne recopie pas les fichiers dans le répertoire tampon, mais utilise des liens symboliques. Vous utiliserez certainement cette option si vous avez des travaux d'impression volumineux. Cela fait gagner de la place dans le répertoire tampon (votre travail pourrait saturer le système de fichiers où se trouve le répertoire tampon). Cela fait aussi gagner du temps, car LPD n'a pas besoin de recopier votre travail d'impression dans le répertoire tampon. Il y a cependant une restriction: comme LPD utilisera les fichiers d'origine, vous ne pourrez pas les modifier ou les supprimer avant qu'ils aient été imprimés. Si vous imprimez sur une imprimante à distance, LPD copiera les fichiers de la machine locale vers la machine distante, donc l'option ne fera gagner de place que sur la machine locale, mais pas sur la machine distante. Cela reste néanmoins utile. -r Détruit les fichiers après les avoir copiés dans le répertoire tampon, ou après les avoir imprimés avec l'option . Soyez prudents avec cette option! Options pour la page d'en-tête Ces options de lpr influent sur le texte qui est normalement imprimé sur la page d'en-tête du travail d'impression. Si les pages d'en-tête sont désactivées pour l'imprimante destinataire, ces options n'ont pas d'effet. Voyez la section Pages d'en-tête pour savoir comment gérer les pages d'en-tête. -C texte Remplace le nom de machine sur la page d'en-tête par texte. Le nom de machine est normalement celui de la machine d'où le travail a été soumis. -J texte Remplace le nom du travail sur la page d'en-tête par texte. Le nom du travail est normalement le nom du premier fichier à imprimer, ou stdin si vous imprimez depuis l'entrée standard. -h N'imprime pas de page d'en-tête. Sur certains sites, cette option n'a pas d'effet, selon la façon dont les pages d'en-tête sont générées. Voyez la section Pages d'en-tête pour plus de détails. Administrer les imprimantes En tant qu'administrateur de vos imprimantes, vous avez dû les installer, les configurer et les tester. Avec la commande lpc, vous pouvez encore agir d'autres façons sur vos imprimantes. Avec lpc, vous pouvez: Démarrer et arrêter les imprimantes. Activer et désactiver leurs files d'attente. Réordonner les travaux de chaque file d'attente. Une remarque tout d'abord sur la terminologie: si une imprimante est arrêtée, elle n'imprimera plus rien de ce qui se trouve dans sa file d'attente. Les utilisateurs peuvent toujours soumettre leurs travaux, qui attendront dans la file d'attente que l'imprimante soit redémarrée ou la file d'attente vidée. Si une file d'attente est désactivée, aucun utilisateur (sauf le super-utilisateur) ne peut soumettre de travail à cette imprimante. Une file d'attente active autorise la soumission de travaux d'impression. Une imprimante peut être démarrée pour une file d'attente inactive, auquel cas, elle continue à imprimer les travaux jusqu'à ce que la file d'attente soit vidée. En général, vous devrez avoir les droits du super-utilisateur pour utiliser la commande lpc. Les utilisateurs ordinaires ne peuvent utiliser lpc que pour interroger l'état d'une imprimante et redémarrer une imprimante qui s'est interrompue. Voici un résumé des commandes lpc. La plupart de ces commandes prennent un argument imprimante qui dit à quelle imprimante elles s'appliquent. Vous pouvez utiliser l'argument all comme imprimante pour qu'elles s'appliquent à toutes les imprimantes listées dans le fichier /etc/printcap. abort imprimante Annule le travail en cours et arrête l'imprimante. Les utilisateurs peuvent toujours soumettre leurs travaux si la file d'attente est active. clean imprimante Nettoie le repertoire tampon. Il arrive que les fichiers associés à un travail d'impression ne soient pas correctement supprimés par LPD, en particulier s'il s'est produit des erreurs lors de l'impression ou s'il y a eu beaucoup d'activité d'administration. Cette commande recherche les fichiers qui n'ont plus lieu d'être dans le répertoire tampon et les supprime. disable imprimante Interdit la mise en file d'attente de nouveaux travaux. Si l'imprimante est active, elle continuera à imprimer les travaux qui y sont déjà. Le super-utilisateur (root) peut toujours soumettre des travaux d'impression, même à une file d'attente désactivée. Cette commande est utile si vous testez une nouvelle imprimante ou un nouveau filtre: désactivez la file d'attente et soumettez vos travaux en étant super-utilisateur. Les autres utilisateurs ne pourront pas soumettre de travaux tant que vous n'aurez pas fini vos tests et réactivé la file d'attente avec la commande enable. down imprimante message Arrête complètement une imprimante. C'est l'équivalent de disable suivie de stop. Le message est affiché quand un utilisateur interroge l'état de la file d'attente avec la commande lpq ou lpc status. enable imprimante Active la file d'attente d'une imprimante. Les utilisateurs peuvent soumettre leurs travaux, mais ils ne seront imprimés que quand l'imprimante aura été démarrée. help commande Affiche de l'aide sur la commande. Sans commande, affiche un résumé des commandes disponibles. restart imprimante Démarre l'imprimante. Les utilisateurs normaux peuvent utiliser cette commande si des circonstances extraordinaires interrompent le bon fonctionnement de LPD, mais ils ne peuvent pas l'employer pour redémarrer une imprimante arrêtée avec la commande stop ou down. La commande restart est l'équivalent de abort suivie de start. start imprimante Démarre l'imprimante. Elle imprimera les travaux de sa file d'attente. stop imprimante Arrête l'imprimante. Elle terminera l'impression du travail en cours puis cessera d'imprimer ce qui se trouve dans sa file d'attente. Même si l'imprimante est arrêtée, les utilisateurs peuvent toujours soumettre des travaux à une file d'attente active. topq imprimante travaux_ou_utilisateur Réordonne la file d'attente de l'imprimante en plaçant les travaux dont les numéros sont donnés ou ceux qui appartiennent à l'utilisateur en tête de la file. Vous ne pouvez pas utiliser all comme imprimante avec cette commande. up imprimante Met en service une imprimante. C'est l'inverse de la commande down et équivaut à start suivie de enable. lpc accepte toutes les commandes précédentes depuis la ligne de commande. Si vous ne donnez aucune commande, lpc passe en mode interactif et vous pouvez entrer vos commandes jusqu'à ce que vous tapiez exit, quit, ou fin_de_fichier. Configuration avancée d'une imprimante Cette section décrit les filtres pour des formatages particuliers, les pages d'en-tête, l'impression en réseau, les restrictions et la comptabilisation de l'utilisation des imprimantes. Filtres Bien que LPD prenne en charge le protocole réseau, la gestion de la file d'attente, le contrôle d'accès et d'autres aspects des tâches d'impression, la plupart du travail effectif est confié aux filtres. Les filtres sont des programmes qui communiquent avec l'imprimante et se chargent de leurs caractéristiques et exigences particulières. Lors de la configuration simple, nous avons installé un filtre texte - un filtre très élémentaire qui devrait marcher avec la plupart des imprimantes. (cf. section Installer le filtre texte). Cependant, pour profiter de la conversion de format, de la comptabilisation des impressions, des particularités de certaines imprimantes, et ainsi de suite, il est utile de comprendre comment fonctionnent les filtres. En dernier ressort, ce sont les filtres qui gèreront ces fonctionnalités. La mauvaise nouvelle est que la plupart du temps, vous devrez vous-même fournir ces filtres. La bonne nouvelle est que beaucoup sont déjà disponibles; quand ce n'est pas le cas, ils sont en général faciles à écrire. FreeBSD est aussi livré avec un filtre, /usr/libexec/lpr/lpf, qui fonctionne avec nombre d'imprimantes capables d'imprimer du texte. (Il gère les retours arrière, les tabulations et la comptabilité, mais c'est à peu près tout ce qu'il fait.) Il y a aussi plusieurs filtres ou composants de filtres au catalogue des logiciels portés. Voici ce que vous trouverez dans cette section: La section Comment fonctionnent les filtres essaie de vous donner une vue d'ensemble du rôle du filtre dans le processus d'impression. Vous devriez lire cette section pour comprendre ce qui se passe “dans la coulisse” quand LPD utilise les filtres. Cela peut vous aider à anticiper et remédier aux problèmes que vous rencontrerez au fur et à mesure que vous installerez de plus en plus de filtres sur chacune de vos imprimantes. LPD s'attend à ce que, par défaut, chaque imprimante soit capable d'imprimer du texte. C'est un problème avec les imprimantes PostScript (ou d'autres imprimantes qui utilisent un langage d'impression), qui ne savent pas imprimer directement du texte. La section Imprimer du texte sur des imprimantes PostScript vous explique comment résoudre ce problème. Je vous recommande de la lire si vous avez une imprimante PostScript. PostScript est un format de sortie populaire pour beaucoup de programmes. Certaines personnes (moi y-compris) écrivent directement du code PostScript. Mais les imprimantes PostScript sont chères. La section Emuler PostScript sur des imprimantes Non-PostScript vous explique comment vous pouvez ajuster le filtre texte d'une imprimante pour accepter et imprimer des données PostScript sur une imprimante qui n'est pas PostScript. Je vous recommande de le lire si vous n'avez pas d'imprimante PostScript. La section Filtres de conversion vous donne une méthode pour automatiser la conversion de formats de fichiers particuliers, comme des données graphiques ou issues d'un traitement de texte, vers un format compréhensible pour votre imprimante. Après avoir lu cette section, vous devriez être capable de configurer vos imprimantes pour que les utilisateurs puissent taper lpr -t pour imprimer des données troff, lpr -d pour imprimer des données DVI produit par TeX, ou lpr -v pour imprimer des images point à point, et ainsi de suite. Je conseille la lecture de cette section. La section Filtres de sortie introduit une possibilité rarement utilisée de LPD: les filtres de sortie. A moins que vous n'imprimiez des pages d'en-tête (voyez la section Pages d'en-tête), vous pouvez probablement sauter cette section. La section lpf: un filtre texte décrit lpf, un filtre texte assez complet, quoique simple, pour les imprimantes ligne (et les imprimantes laser qui fonctionnent comme des imprimantes ligne) et qui est livré avec FreeBSD. S'il vous faut un moyen simple pour comptabiliser le fonctionnement d'une imprimante en mode texte, ou si vous avez une imprimante qui fume lorsqu'elle aperçoit un retour arrière, vous devriez absolument envisager d'utiliser lpf. Comment fonctionnent les filtres Comme expliqué plus haut, un filtre est un programme exécuté par LPD pour gérer ce qui dépend de l'imprimante dans la communication avec celle-ci. Quand LPD veut imprimer un fichier appartenant à un travail d'impression, il démarre un programme de filtre. Il affecte à l'entrée standard du filtre le fichier à imprimer, à sa sortie standard l'imprimante et à son fichier d'erreur standard le fichier de trace (défini par la fonctionnalité lf de /etc/printcap, ou /dev/console par défaut). Quel filtre LPD utilise et avec quels arguments dépend du contenu du fichier /etc/printcap et des arguments qu'a donnés l'utilisateur sur la ligne de commande de lpr pour ce travail d'impression. Par exemple, s'il a utilisé lpr -t, LPD démarrera le filtre troff, indiqué par la fonctionnalité tf pour l'imprimante destinataire. Si l'utilisateur veut imprimer du texte, il lancera le filtre if (c'est vrai la plupart du temps, voyez la section Filtres de sortie pour plus de détails). Il y a trois sortes de filtres que vous pouvez définir dans /etc/printcap: Le filtre texte, inexactement appelé filtre d'entrée dans la documentation de LPD, se charge de l'impression du texte ordinaire. Considérez-le comme le filtre par défaut. LPD suppose que toutes les imprimantes savent par défaut imprimer du texte, et c'est le rôle du filtre texte de faire en sorte que les retours arrière, tabulations et autres caractères spéciaux ne posent pas de problèmes à l'imprimante. Si vous êtes dans un environnement où vous devez comptabiliser l'utilisation des imprimantes, le filtre texte doit aussi s'en charger, habituellement en comptant le nombre de lignes et en le comparant au nombre de lignes par page accepté par l'imprimante. Le filtre texte est exécuté avec les arguments suivants: nom_du_filtre -c -wlargeur -lhauteur -iindentation -n utilisateur -h hôte fichier_comptable où: est utilisé si le travail a été soumis par lpr -l, largeur est la valeur donnée avec la fonctionnalité pw (largeur de page - “page width”) dans /etc/printcap, 132 par défaut, length est la valeur indiquée par la fonctionnalité pl (hauteur de page - “page length”), 66 par défaut, indentation indentation précisée par lpr -i, 0 par défaut, utilisateur est le nom (de session) de l'utilisateur imprimant le fichier, hôte est le nom de la machine d'où le travail a été soumis, fichier_comptable est le nom du fichier de comptabilité spécifé par la fonctionnalité af. Un filtre de conversion convertit un format de fichier particulier en un format que l'imprimante comprend. Par exemple, des données provenant du traitement de texte ditroff ne peuvent pas être imprimées directement, mais vous pouvez installer un filtre de conversion pour les fichiers ditroff pour transformer les fichiers ditroff de façon à ce que l'imprimante les digère et les imprime. La section Filtres de conversion vous dit tout ce que vous devez savoir sur ces filtres. Les filtres de conversion doivent aussi gérer la comptabilité, si vous en avez besoin. Les filtres de conversion sont exécutés avec les arguments suivants: nom_du_filtre -xlargeur_du_pixel -yhauteur_du_pixel -n utilisateur -h hôte fichier_comptable où largeur_du_pixel est la valeur définie par la fonctionnalité px (0 par défaut) et hauteur_du_pixel celle définie par py (0 par défaut). Le filtre de sortie n'est utilisé que s'il n'y a pas de filtre texte, ou que les pages d'en-tête sont activées. D'après mon expérience personnelle, les filtres de sortie sont rarement utilisés. La section Filtres de sortie les décrit. Un filtre de sortie n'a que deux arguments: nom_du_filtre -wlargeur -lhauteur qui sont identiques aux arguments et du filtre texte. Les filtres doivent aussi retourner (“exit”) avec l'un des codes retour suivants: exit 0 Le filtre a correctement imprimé le fichier. exit 1 Le filtre n'a pas pu imprimer le fichier mais veut que LPD tente une nouvelle impression. LPD relancera le filtre s'il retourne ce code. exit 2 Le filtre n'a pas pu imprimer le fichier et ne veut pas que LPD relance l'impression. LPD supprimera le fichier de la file d'attente. Le filtre texte livré avec la distribution de FreeBSD, /usr/libexec/lpr/lpf, utilise les arguments définissant la largeur et la hauteur de page pour déterminer quand envoyer un saut de page et pour gérer la comptabilité. Il se sert du nom d'utilisateur, du nom de machine et de celui du fichier comptable pour tenir à jour les enregistrements comptables. Si vous cherchez des filtres, vérifiez qu'ils sont compatibles avec LPD. S'ils le sont, ils doivent accepter les arguments décrits ci-dessus. Si vous envisagez d'écrire des filtres, vous devez faire en sorte qu'ils acceptent ces arguments et gèrent les bons codes retour. Imprimer du texte sur des imprimantes PostScript Si vous êtes le seul utilisateur de votre ordinateur et d'une imprimante PostScript (ou d'une autre imprimante fonctionnant avec un langage d'impression) et êtes certain de ne jamais envoyer de simples fichiers texte à l'imprimante ou de ne jamais utiliser les options de différents programmes qui feraient de même, alors vous n'avez pas besoin de vous préoccuper du contenu de cette section. Mais, si vous voulez envoyer et du PostScript et de simples fichiers texte à l'imprimante, alors je vous conjure d'adapter la configuration de votre imprimante. Pour cela, nous ferons en sorte que le filtre texte distingue entre les travaux d'impression qui envoient du texte et ceux qui envoient du PostScript. Tous les travaux PostScript commencent par %! (pour les autres langages, consultez la documentation de votre imprimante). Si nous avons ces deux caractères au début du travail d'impression, alors c'est du PostScript, et nous pouvons l'envoyer tel quel. Sinon, le filtre convertira le texte en PostScript et imprimera le résultat. Comment réaliser cela? Avec une imprimante série, il suffit d'installer lprps. lprps est un filtre d'impression PostScript qui dialogue avec l'imprimante. Il met à jour le fichier d'état de l'imprimante en fonction des informations que celle-ci lui fournit, les utilisateurs et les administrateurs peuvent donc savoir exactement quel est l'état de l'imprimante (comme manque d'encre ou bourrage). Mais, c'est plus intéressant, il comporte un programme appelé psif qui détecte si le prochain travail est du texte et invoque textps (un autre programme qui fait partie de lprps) pour le convertir en PostScript. Il utilise ensuite lprps pour l'envoyer à l'imprimante. lprps fait partie du catalogue des logiciels portés de FreeBSD (voyez le chapitre Installer des Logiciels au “Catalogue des Logiciels Portés”). Vous pouvez le télécharger, le compiler et l'installer vous-même, bien sûr. Après avoir installé lprps, donnez juste le chemin d'accès au programme psif qui fait partie de lprps. Si vous avez installé lprps depuis le catalogue des logiciels portés, utilisez ce qui suit dans la définition de l'imprimante série PostScript dans /etc/printcap: :if=/usr/local/libexec/psif: Vous devez aussi activer la fonctionnalité rw qui dit à LPD d'ouvrir l'imprimante en lecture/écriture. Si vous avez une imprimante PostScript parallèle (et donc ne pouvez pas communiquer dans les deux sens avec l'imprimante, ce qui est indispensable à lprps), vous pouvez utilisez la procédure qui suit comme filtre texte: #!/bin/sh # # psif - Imprime du PostScript ou du texte # version Procédure; Ce N'EST PAS la version qui accompagne lprs # fichier /usr/local/libexec/psif # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # Travail PostScript; l'imprimer. # echo $first_line && cat && printf "\004" && exit 0 exit 2 else # # Texte simple, le convertir, puis l'imprimer. # ( echo $first_line; cat ) | /usr/local/bin/textps && printf "\004" && exit 0 exit 2 fi Dans la procédure ci-dessus, textps est un programme que nous avons installé séparément pour convertir du texte en PostScript. Vous pouvez utiliser le programme de conversion de votre choix. Le catalogue des logiciels portés de FreeBSD (voyez le chapitre Installer des Logiciels au “Catalogue des Logiciels Portés”) comporte un programme complet de conversion de texte en PostScript appelé a2ps auquel vous pourriez jeter un coup d'oeil. Emuler PostScript sur des imprimantes Non-PostScript PostScript est le standard de facto du traitement de texte et de l'impression de qualité. PostScript est, toutefois, un standard coûteux. Heureusement, Alladin Enterprises fournit un émulateur PostScript libre, appelé Ghostscript, qui fonctionne sous FreeBSD. Ghostscript peut lire la plupart des fichiers PostScript et les convertir pour divers modèles d'imprimantes dont de nombreuses imprimantes non-PostScript. En installant Ghostscript et avec un filtre texte adapté à votre imprimante, vous pouvez utiliser votre imprimante comme une vraie imprimante PostScript. Ghostscript devrait être dans le catalogue des logiciels portés de FreeBSD, d'où vous pouvez l'installer. Vous pouvez aussi facilement le télécharger, le compiler et l'installer. Pour émuler PostScript, nous ferons en sorte que le filtre texte reconnaisse les fichiers PostScript. Quand ce n'est pas le cas, le filtre enverra directement le fichier à l'imprimante. Sinon, il utilisera Ghostscript pour convertir le fichier en un format que l'imprimante comprenne. Voici un exemple: cette procédure est un filtre texte pour les imprimantes Hewlett Packard DeskJet 500. Pour d'autres imprimantes, modifiez l'argument de l'option de la commande gs (Ghostscript). (Tapez gs -h pour avoir la liste des périphériques supportés par la version courante de Ghostscript.) #!/bin/sh # # ifhp - Imprime du PostSCript émulé par Ghostscript sur une DeskJet 500 # fichier /usr/local/libexec/hpif # # traiter LF comme CR+LF: # printf "\033&k2G" || exit 2 # # Lit les deux premiers caractères du fichier # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # Si c'est du PostScript; utiliser Ghostscript pour convertir, et imprimer. # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \ && exit 0 else # # Texte ou HP/PCL, donc, imprimer directement; envoyer ensuite un saut # de page pour éjecter la dernière page. # echo $first_line && cat && printf "\f" && exit 0 fi exit 2 Pour finir, il faut spécifier le filtre à LPD avec la fonctionnalité if: :if=/usr/local/libexec/hpif: C'est tout. Vous pouvez maintenant taper lpr texte.simple et lpr quoique-ce-soit.ps et les deux devraient s'imprimer. Filtres de conversion Après avoir terminé l'étape de Configuration simple d'une imprimante, la première chose que vous voudrez probablement faire sera d'installer des filtres de conversion pour vos formats de fichiers favoris (autres que le simple texte ASCII). Pourquoi installer des filtres de conversion? Les filtres de conversion facilitent l'impression de différents types de fichiers. Supposons, par exemple, que nous utilisions beaucoup le logiciel de traitement de texte TeX, et que nous ayons une imprimante PostScript. Chaque fois que nous générons un fichier DVI avec TeX, nous ne pouvons l'imprimer directement sans le convertir auparavant en PostScript. La séquence de commande pour le faire est la suivante: &prompt.user; dvips anaylse-algues.dvi &prompt.user; lpr analyse-algues.ps En installant un filtre de conversion pour les fichiers DVI, nous pourrons nous dispenser de la conversion manuelle à chaque fois, en laissant LPD le faire à notre place. Quand nous aurons un fichier DVI, l'impression se fera en une seule étape: &prompt.user; lpr -d analyse-algues.dvi L'option dit à LPD que c'est un fichier DVI à convertir. La section Options de mise en page et de conversion liste les options de conversion. Pour chaque option de conversion que vous voulez que l'imprimante supporte, installez un filtre de conversion et donnez son chemin d'accès dans /etc/printcap. Un filtre de conversion est similaire au filtre texte de notre configuration simple (voir section Installer le filtre texte) sinon qu'au lieu d'imprimer du texte, il convertit le fichier en un format compréhensible pour l'imprimante. Quels filtres de conversion dois-je installer? Installez les filtres de conversion que vous prévoyez d'utiliser. Si vous avez beaucoup de données DVI, un filtre de conversion DVI s'impose. Si vous voulez imprimer beaucoup de troff, c'est une bonne idée d'installer un filtre troff. La table ci-dessous résume les caractéristiques des filtres que LPD utilise, elle donne le type de fichier, la fonctionnalité correspondante dans le fichier /etc/printcap et l'option à utiliser avec la commande lpr. Type de fichier Fonctionnalité /etc/printcap Option de lpr cifplot cf DVI df format traceur (“plot”) gf ditroff nf programme FORTRAN rf troff rf image point à point (“raster”) vf texte if aucune, , ou Dans notre exemple, la commande lpr -d signifie que l'imprimante doit invoquer la fonctionnalité df de sa définition dans /etc/printcap. Malgré ce que d'aucuns en pensent, des formats tels que FORTRAN ou “traceur” sont probablement obsolètes. Sur votre site, vous pouvez changer la signification de ces options, ou de n'importe quelle option de conversion, en installant des filtres personnalisés. Imaginons, par exemple, que vous vouliez imprimer directement des fichiers Printerleaf (des fichiers créés avec le logiciel de Publication Assistée par Ordinateur Interleaf), mais n'imprimerez jamais de fichier traceur. Vous pouvez installer un filtre de conversion Printerleaf pour la fonctionnalité gf et prévenir vos utilisateur que lpr -g signifie “imprimer des fichiers Printerleaf.” Installer des filtres de conversion Les filtres de conversion sont des programmes qui ne font pas partie de la distribution standard de FreeBSD, ils ont logiquement leur place dans /usr/local. Le répertoire /usr/local/libexec est l'endroit habituel où les mettre, parce que ce sont des programmes réservés à LPD que les utilisateurs ordinaires ne devraient jamais employer. Pour mettre en service un filtre de conversion, indiquez son chemin d'accès à la fonctionnalité correspondante pour l'imprimante destinatrice dans /etc/printcap. Nous allons ajouter à notre exemple un filtre de conversion DVI pour l'imprimante appelée bamboo. Voici notre nouveau fichier /etc/printcap avec la fonctionnalité df pour l'imprimante bamboo: # # /etc/printcap pour la machine rose - ajout du filtre df pour bamboo # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Le filtre DVI est une procédure appelée /usr/local/libexec/psdf. Voici cette procédure: #!bin/sh # # psdf - filtre de conversion de DVI en PostScript # fichier /usr/local/libexec/psdf # # appelé quand l'utilisateur invoque lpr -d # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" Cette procédure exécute dvips en mode filtre (l'argument ) sur l'entrée standard, qui est le travail d'impression. Elle lance ensuite le filtre d'impression PostScript lprps (reportez-vous à la section Imprimer du texte sur des imprimantes PostScript) en lui passant les arguments donnés à LPD. lprps utilisera ces arguments pour comptabiliser les pages imprimées. Autres exemples de filtres de conversion La méthode pour installer des filtres de conversion n'étant pas toujours la même, il vaut mieux que je vous donne d'autres exemples, dont vous pourrez vous inspirer pour mettre en oeuvre vos propres filtres. Utilisez-les tels quels, au besoin. Voici une procédure pour convertir des fichiers graphiques point à point (en fait, des fichiers GIF) pour une imprimante Hewlett Packard LaserJet III-Si: #!/bin/sh # # hpvf - Convertit des fichiers GIF en HP/PCL, et les imprime # fichier /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 Elle convertit le fichier GIF en format portable universel, puis en format portable noir et blanc, puis en format portable “bitmap” et enfin en données compatibles LaserJet/PCL. Voici le fichier /etc/printcap avec une entrée pour une imprimante utilisant ce filtre: # # /etc/printcap pour la machine rose # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: La procédure suivante convertit des données troff produites par le traitement de texte groff pour l'imprimante PostScript bamboo: #!/bin/sh # # pstf - Convertit des données troff de groff en PS, et les imprime # fichier /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" Cette procédure utilise de nouveau lprps pour communiquer avec l'imprimante. Si l'imprimante était sur un port parallèle, il faudrait utiliser une autre méthode: #!/bin/sh # # pstf - Convertit des donnees troff de groff en PS, et les imprime # fichier /usr/local/libexec/pstf # exec grops C'est tout. Voici ce qu'il faut mettre dans /etc/printcap pour utiliser ce filtre: :tf=/usr/local/libexec/pstf: Voici un exemple qui prend en charge la sauce FORTRAN. C'est un filtre pour les programmes FORTRAN pour n'importe quelle imprimante capable d'imprimer directement du texte. Nous l'installerons pour l'imprimante teak: #!/bin/sh # # hprf - filtre de conversion pour FORTRAN pour LaserJet 3si: # fichier /usr/local/libexec/hprf # printf "\033&k2G" && fpr && printf "\f" && exit 0 exit 2 Et nous mettrons la ligne suivante dans /etc/printcap pour l'imprimante teak pour activer ce filtre: :rf=/usr/local/libexec/hprf: Voici un dernier exemple, quelque peu plus complexe. Nous allons installer un filtre DVI pour l'imprimante LaserJet teak de l'exemple précédent. Commençons par le plus facile: mettre à jour /etc/printcap en lui donnant le chemin d'accès au filtre DVI: :df=/usr/local/libexec/hpdf: Et maintenant, la partie compliquée: créer le filtre. Il nous faut un programme de conversion de DVI en PCL pour LaserJet. Il y en a un au catalogue des logiciels portés de FreeBSD (voyez le chapitre Installer des Logiciels au “Catalogue des Logiciels Portés”): dvi2xx est le nom du logiciel. En l'installant, nous récupérons le programme dont nous avons besoin, dvilj2p, qui convertit du DVI en instructions compatibles LaserJet IIp, LaserJet III et LaserJet 2000. dvilj2p rend le filtre hpdf assez complexe, parce que dvilj2p ne sait pas lire sur l'entrée standard. Il lui faut un nom de fichier. Pire encore, ce fichier doit avoir l'extension .dvi, nous ne pouvons donc pas utiliser /dev/fd/0 qui correspond à l'entrée standard. Nous contournons le problème avec un lien (symbolique) d'un fichier temporaire (avec l'extension .dvi) vers /dev/fd/0, forçant ainsi dvilj2p à lire l'entrée standard. Il y a cependant une mouche dans le potage. Nous ne pouvons pas créer de lien symbolique temporaire dans /tmp. Les liens symboliques appartiennent à l'utilisateur et au groupe bin. Le filtre est exécuté par l'utilisateur daemon. Et le bit “sticky (persistant)” du répertoire /tmp est positionné. Le filtre peut créer le lien, mais ne pourra pas le détruire après avoir fait son travail, puisque le lien appartient à un autre utilisateur. Le filtre créera donc le lien dans le répertoire courant, qui est le répertoire tampon pour la file d'attente des travaux d'impression (défini par la fonctionnalité sd dans /etc/printcap). C'est l'endroit idéal pour que les filtres accomplissent leur tâche, en particulier parce qu'il y a (parfois) plus de place dans le répertoire tampon que dans /tmp. Voici, enfin, le filtre: #!/bin/sh # # hpdf - Imprime du DVI sur une imprimante HP/PCL # fichier /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Définit une fonction pour détruire nos fichiers temporaires. Ces fichiers # sont dans le répertoire courant, qui est le répertoire de file d'attente de # l'imprimante # cleanup() { rm -f hpdf$$.dvi } # # Définit une fonction de gestion des erreurs fatales : imprime le message # d'erreur et retourne le code d'erreur 2. Ce code dit à LPD de ne pas # relancer le travail d'impression. # fatal() { echo "$@" 1>&2 cleanup exit 2 } # # Si l'utilisateur annule le travail d'impression, LPD envoie SIGINT, # il faut donc capturer SIGINT (et quelques autres signaux) # pour faire ensuite le ménage nous-mêmes. # trap cleanup 1 2 15 # # Assurons-nous de ne pas avoir de conflit de nom avec des fichiers existants. # cleanup # # Lien symbolique du fichier DVI sur l'entrée standard (fichier à imprimer). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # LF = CR+LF # printf "\033&k2G" || fatal "Cannot initialize printer" # # Convertit et imprime. Le code retour de dvilj2p ne semble pas fiable, # nous l'ignorons. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Fait le ménage et termine la procédure # cleanup exit 0 La conversion automatique: une alternative aux filtres de conversion Tous ces filtres de conversion améliorent votre environnement d'impression, mais ils obligent l'utilisateur à préciser (sur la ligne de commande de lpr) lequel utiliser. Si vos utilisateurs ne sont pas particulièrement compétents en informatique, cela leur sera une gêne. Pire encore, une erreur d'option de filtrage peut lancer un filtre sur le mauvais type de fichier et provoquer l'impression de centaines de pages inutiles. Au lieu d'installer des filtres de conversion, vous pouvez essayer de faire en sorte que le filtre texte (qui est le filtre par défaut) reconnaisse le type de fichier qu'il doit imprimer et exécute automatiquement le filtre de conversion adéquat. Des utilitaires comme file peuvent être employés pour cela. Il sera bien sûr difficile de faire la différence entre certains types de fichiers - dans ce cas, vous pouvez toujours fournir des filtres de conversion juste pour ces fichiers. Le catalogue des logiciels portés de FreeBSD inclut un filtre texte appelé apsfilter qui effectue la conversion automatique. Il sait reconnaître les fichiers texte, PostScript et DVI, effectuer la conversion adéquate et imprimer. Filtres de sortie Le gestionnaire d'impression LPD supporte encore un autre type de filtre dont nous n'avons pas encore parlé: le filtre de sortie. Un filtre de sortie sert à imprimer du texte uniquement, comme le filtre texte, mais il est grandement simplifié. Si vous utilisez un filtre de sortie, et pas de filtre texte, alors: LPD exécute le filtre de sortie une seule fois par travail d'impression et non une fois pour chaque fichier d'un travail d'impression. LPD ne s'inquiète pas de détecter le début et la fin de chaque fichier pour les besoins du filtre de sortie. LPD ne passe pas le nom de la machine et de l'utilisateur au filtre, qui ne peut donc être utilisé pour la comptabilité. De fait, il n'a que deux arguments: nom_du_filtre -wlargeur -lhauteur où largeur est la valeur définie par la fonctionnalité pw et hauteur est la valeur définie par la fonctionnalité pl associée à l'imprimante en question. Ne soyez pas abusé par la simplicité du filtre de sortie. Si vous voulez que chaque fichier d'un travail d'impression commence sur une nouvelle page, le filtre de sortie ne convient pas. Utilisez un filtre texte (appelé aussi filtre d'entrée); voyez la section Installer le filtre texte. De plus, un filtre de sortie est en fait plus complexe car il doit examiner le flot de données pour voir s'il contient des caractères spéciaux et s'envoyer des signaux à lui-même au lieu que ce soit LPD qui le fasse. Un filtre de sortie est toutefois nécessaire si vous voulez avoir des pages d'en-tête et devez envoyer des séquences d'échappement ou d'autres commandes d'initialisation pour pouvoir imprimer ces pages d'en-tête. (Il est cependant inutilisable si vous voulez facturer ces pages d'en-tête à l'utilisateur, puisque LPD ne donne pas d'informations sur l'utilisateur et la machine au filtre de sortie.) Pour une même imprimante, LPD vous autorise à avoir à la fois un filtre texte, un filtre de sortie et d'autres filtres. Dans ce cas, LPD utilisera le filtre de sortie pour imprimer la page d'en-tête (voyez la section Pages d'en-tête) uniquement. LPD s'attend à ce que le filtre de sortie s'interrompe ensuite lui-même quand il lui envoie les deux octets: ASCII 031 suivi de ASCII 001. Quand un filtre de sortie reçoit cette séquence (031, 001), il doit s'interrompre en s'envoyant le signal SIGSTOP. Quand LPD en a fini avec les autres filtres, il réactive le filtre de sortie en lui envoyant un SIGCONT. S'il y a un filtre de sortie mais pas de filtre texte et que LPD traite une impression de texte, LPD se sert du filtre de sortie pour faire le travail. Comme déjà dit plus haut, le filtre de sortie imprimera les fichiers en continu, sans saut de page ou autre commande d'avance papier entre eux, ce qui n'est probablement pas ce que vous attendez. Dans la plupart des cas, vous aurez besoin d'un filtre texte. Le programme lpf, que nous avons cité auparavant comme filtre texte, peut aussi être utilisé comme filtre de sortie. Si vous avez besoin d'un filtre de sortie grossier et ne voulez pas écrire le code pour tester les octets et envoyer les signaux, essayez lpf. Vous pouvez aussi encapsuler lpf dans une procédure qui prenne en charge les codes d'initialisation dont l'imprimante aurait besoin. <command>lpf</command>: un filtre texte Le programme /usr/libexec/lpr/lpf qui fait partie de la distribution de FreeBSD est un filtre texte (filtre d'entrée) qui sait indenter le résultat (commande lpr -i), imprimer littéralement le texte (commande lpr -l), se positionner à la bonne colonne d'impression pour gérer les retours arrière et les tabulations et comptabiliser les pages imprimées. Il peut aussi servir de filtre de sortie. lpf convient à de nombreux environnements d'impression. Et bien qu'il ne sache pas envoyer de séquences d'initialisation à l'imprimante, il est facile d'écrire une procédure qui effectue les initialisations requises et exécute ensuite lpf. Pour que lpf comptabilise correctement les pages, il faut que les valeurs définies par les fonctionnalités pw et pl du fichier /etc/printcap soient correctement renseignées. Ces valeurs sont utilisées pour savoir quelle quantité de texte tient sur une page, et combien de pages comporte le travail d'impression d'un utilisateur. Pour plus d'informations sur la comptabilisation des impressions, voyez la section Comptabiliser l'utilisation des imprimantes. Pages d'en-tête Si vous avez beaucoup d'utilisateurs, employant tous différentes imprimantes, alors vous devrez envisager les pages d'en-tête comme un mal nécessaire. Les pages d'en-tête, appelées aussi bannières ou pages qui sautent aux yeux (burst) identifient les propriétaires des travaux après qu'ils aient été imprimés. Elles sont généralement imprimées en gros caractères gras, parfois encadrés, de façon à ce qu'elles se distinguent facilement des documents eux-mêmes dans une pile d'impressions. Elles permettent aux utilisateurs de répérer rapidement leurs propres travaux. L'inconvénient en est que cela fait une page supplémentaire à imprimer à chaque fois, d'usage éphémère - quelques minutes au plus, et qui finissent à la corbeille ou au recyclage. (Notez que comme il n'y a qu'une page d'en-tête par travail d'impression et non une pour chaque fichier, le gaspillage n'est peut-être pas si grave.) Le système LPD peut générer automatiquement les pages d'en-tête si votre imprimante sait imprimer directement du texte. Si vous avez une imprimante PostScript, il vous faudra un programme supplémentaire pour les générer; reportez-vous à la section Pages d'en-tête sur les imprimantes PostScript. Activer les pages d'en-tête Dans la Configuration simple d'une imprimante, nous avons supprimé l'impression des pages d'en-tête en ajoutant sh (pour “suppress header” - supprimer les en-têtes) dans le fichier /etc/printcap. Pour les mettre en service sur une imprimante, il suffit d'enlever la fonctionnalité sh. Cela parait trop facile, non? Vous avez raison. Vous devrez peut-être fournir un filtre de sortie pour envoyer une séquence d'initialisation à votre imprimante. Voici un exemple de filtre de sortie pour une imprimante compatible avec le langage PCL de Hewlett Packard: #!/bin/sh # # hpof - filtre de sortie pour les imprimantes compatibles Hewlett Packard PCL # fichier /usr/local/libexec/hpof printf "\033&k2G" || exit 2 exec /usr/libexec/lpr/lpf Donnez le chemin d'accès du filtre de sortie avec la fonctionnalité of. Voyez la section Filtres de sortie pour plus d'informations. Voici par exemple le fichier /etc/printcap pour l'imprimante teak déjà utilisée plus haut; nous mettons en service les pages d'en-tête et ajoutons le filtre de sortie ci-dessus: # # /etc/printcap pour la machine orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: Maintenant, quand nous utilisateurs imprimeront sur teak, ils auront une page d'en-tête pour chaque travail. S'ils préférent perdre du temps à retrouver leurs impressions, ils peuvent supprimer les pages d'en-tête en soumettant leurs travaux avec lpr -h; voyez la section Options pour la page d'en-tête pour connaître les autres options de lpr. LPD imprime un caractère de saut de page après chaque page d'en-tête. Si votre imprimante utilise un caractère ou une séquence différente pour éjecter une page, précisez-la avec la fonctionnalité ff dans /etc/printcap. Configurer les pages d'en-tête Si les pages d'en-tête sont actives, LPD produira un en-tête long, une page entière en gros caractères, donnant le nom de l'utilisateur, de la machine et du travail d'impression. En voici un exemple (kelly a imprimé un travail appelé outline depuis la machine rose): k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 LPD ajoute un saut de page après ce texte de sorte que le travail commence en début de page (à moins que vous n'ayez mis sf - supprimer les sauts de page - dans l'entrée correspondant à l'imprimante destinatrice dans /etc/printcap). Si vous le préférez, LPD peut générer des en-têtes courts; spécifiez sb (en-tête court - “short banner”) dans le fichier /etc/printcap. La page d'en-tête ressemblera alors à ceci: rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 Par défaut, LPD imprime la page d'en-tête avant le contenu du travail. Vous pouvez faire l'inverse avec hl (en-tête à la fin - “header last”) dans /etc/printcap. Comptabiliser les pages d'en-tête Avec les pages d'en-tête pré-programmées de LPD, vous en êtes réduits à appliquer la politique suivante: les pages d'en-tête doivent être gratuites. Pourquoi? Le filtre de sortie est le seul programme additionnel qui puisse savoir quand sont imprimées les pages d'en-tête et comme il ne connait ni l'utilisateur, ni la machine, pas plus que le nom du fichier comptable, il ne peut pas savoir qui facturer. Il ne suffit pas de simplement “ajouter une page” par l'intermédiaire du filtre texte ou de l'un des filtres de conversion (qui connaissent l'utilisateur et la machine), puisque les utilisateurs peuvent supprimer les pages d'en-tête avec lpr -h. Ils seraient alors facturés pour des pages d'en-tête qu'ils n'ont pas imprimées. Les utilisateurs écologistes préféreront employer lpr -h, mais vous n'avez pas moyen de les y inciter. Il ne suffit pas non plus de faire générer les pages d'en-tête par les différents filtres (ce qui permet de les facturer). Si les utilisateurs veulent alors les supprimer avec lpr -h, ils les auront malgré tout et seront facturés pour, parce que LPD ne passe l'information fournie par l'option à aucun des filtres. Que pouvez-vous donc faire? Vous pouvez : Accepter la politique de LPD et ne pas facturer les pages d'en-tête. Installer l'une des alternatives à LPD, comme LPDng ou PLP. La section Alternatives au gestionnaire d'impression standard vous en dit plus sur les autres gestionnaires d'impression qui peuvent se substituer à LPD. Ecrire un filtre de sortie intelligent. Le filtre de sortie n'a normalement rien d'autre à faire que d'initialiser l'imprimante et effectuer quelques conversions simples de caractères. Il convient pour les pages d'en-tête et l'impression de textes (quand il n'y a pas de filtre texte - ou d'entrée). Mais, s'il y a un filtre texte, le filtre de sortie n'est utilisé que pour les pages d'en-tête. Le filtre de sortie peut alors déterminer quel utilisateur ou quelle machine facturer en fonction du contenu de la page d'en-tête. Le seul problème avec cette méthode est que l'on ne sait toujours pas quel est le fichier comptable (son nom, défini par la fonctionnalité af, n'est pas transmis au filtre de sortie), mais si son nom est standard, vous pouvez le codez “en dur” dans le filtre de sortie. Pour faciliter l'analyse du contenu de la page d'en-tête, utilisez la fonctionnalité sh (en-tête courte) dans /etc/printcap. Cependant, c'est peut-être se donner beaucoup de mal, alors que les utilisateurs apprécieront certainement plus l'administrateur système qui leur fait cadeau des pages d'en-tête. Pages d'en-tête sur les imprimantes PostScript Comme décrit ci-dessus, LPD peut générer une page d'en-tête texte qui convient pour de nombreuses imprimantes. PostScript ne peut pas imprimer directement du texte, donc dans ce cas, les pages d'en-tête de LPD sont inutilisables - ou presque. Une méthode triviale pour obtenir des pages d'en-tête est de confier leur génération à chaque filtre de conversion et au filtre texte. Ces filtres se serviront des noms d'utilisateur et de machine pour remplir correctement la page d'en-tête. L'inconvénient de cette méthode est que les utilisateurs auront toujours une page d'en-tête, même s'ils soumettent leurs travaux avec lpr -h. Voyons comment cela fonctionne. La procédure ci-dessous a trois arguments (le nom de l'utilisateur, celui de la machine et celui du travail d'impression) et génère une page d'en-tête PostScript simple: #!/bin/sh # # make-ps-header - affiche une page d'en-tête PostScript sur la sortie standard # fichier /usr/local/libexec/make-ps-header # # # Ce sont les unités PostScript (72 par pouce). # A modifier pour le format A4 ou autre. # page_width=612 page_height=792 border=72 # # contrôle des arguments # if [ $# -ne 3 ]; then echo "Usage: `basename $0` <user> <host> <job>" 1>&2 exit 1 fi # # Les mémoriser, pour la lisibilité du code PostScript qui suit. # user=$1 host=$2 job=$3 date=`date` # # Envoyer le code PostScript sur la sortie standard. # exec cat <<EOF %!PS % % Pour ne pas interférer avec le travail de l'utilisateur qui suivra. % save % % Un cadre large et désagréable autour de la page. % $border $border moveto $page_width $border 2 mul sub 0 rlineto 0 $page_height $border 2 mul sub rlineto currentscreen 3 -1 roll pop 100 3 1 roll setscreen $border 2 mul $page_width sub 0 rlineto closepath 0.8 setgray 10 setlinewidth stroke 0 setgray % % Le nom de l'utilisateur en gros caractères. % /Helvetica-Bold findfont 64 scalefont setfont $page_width ($user) stringwidth pop sub 2 div $page_height 200 sub moveto ($user) show % % Les caractéristiques ennuyeuses % /Helvetica findfont 14 scalefont setfont /y 200 def [ (Job:) (Host:) (Date:) ] { 200 y moveto show /y y 18 sub def } forall /Helvetica-Bold findfont 14 scalefont setfont /y 200 def [ ($job) ($host) ($date) ] { 270 y moveto show /y y 18 sub def } forall % % C'est tout. % restore showpage EOF Chacun des filtres de conversion et le filtre texte peuvent maintenant utiliser cette procédure pour produire les pages d'en-tête avant d'imprimer le travail de l'utilisateur. Voici le filtre de conversion DVI décrit plus haut dans ce chapitre, modifié pour inclure la génération des pages d'en-tête: #!/bin/sh # # psdf - filtre de conversion de DVI en PostScript # fichier /usr/local/libexec/psdf # # Utilisé par lpd quand l'utilisateur emploie lpr -d # orig_args="$@" fail() { echo "$@" 1>&2 exit 2 } while getopts "x:y:n:h:" option; do case $option in x|y) ;; # Ignore n) login=$OPTARG ;; h) host=$OPTARG ;; *) echo "LPD started `basename $0` wrong." 1>&2 exit 2 ;; esac done [ "$login" ] || fail "Pas de nom d'utilisateur" [ "$host" ] || fail "Pas de nom de machine" ( /usr/local/libexec/make-ps-header $login $host "DVI File" /usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_args Remarquez la façon dont le filtre analyse les arguments pour connaître le nom de l'utilisateur et celui de la machine. Ce serait la même pour les autres filtres de conversion. Le filtre texte a un jeu d'arguments légèrement différent (voyez la section Comment fonctionnent les filtres). Comme nous l'avons déjà dit, cette méthode, quoique assez simple, empêche d'utiliser l'option de “suppression de la page d'en-tête” (l'option ) de la commande lpr. Si les utilisateurs voulaient épargner un arbre (ou quelques centimes, si vous facturez les pages d'en-tête), ils ne pourront pas, puisque tous les filtres imprimeront une page d'en-tête pour chaque travail. Pour permettre aux utilisateurs de désactiver les pages d'en-tête, vous devrez utiliser l'astuce décrite à la section Comptabiliser les pages d'en-tête: écrire un filtre de sortie qui analyse la page d'en-tête générée par LPD et en produire une version PostScript. Si l'utilisateur soumet son travail avec lpr -h, LPD ne génère pas de page d'en-tête, et donc le filtre de sortie non plus. Dans le cas contraire, votre filtre de sortie lira le texte produit par LPD et enverra le code PostScript de la page d'en-tête à l'imprimante. Si votre imprimante PostScript est sur une interface série, vous pouvez utiliser lprps, qui inclut un filtre de sortie, psof, qui se charge de cela. Remarquez que psof ne facture pas les pages d'en-tête. Impression en réseau FreeBSD supporte l'impression en réseau pour envoyer des travaux sur des imprimantes distantes. Imprimer en réseau veut en général dire deux choses différentes: Accéder à une imprimante connectée à une machine distante. Vous installez une imprimante avec une interface série ou parallèle classique sur une machine. Vous pouvez alors configurer LPD pour permettre l'accès à cette imprimante depuis d'autres machines du réseau. La section Imprimantes installées sur des machines distantes vous explique comment faire. Accéder à une imprimante connectée directement au réseau. L'imprimante a une interface réseau en plus (ou à la place) de l'interface série ou parallèle habituelle. Une imprimante de ce type peut fonctionner comme suit: Elle peut comprendre le protocole LPD, voire même gérer une file d'attente de travaux venant de machines distantes. Dans ce cas, elle se comporte comme une machine distante exécutant LPD. Suivez la même procédure qu'à la section Imprimantes installées sur des machines distantes pour configurer ce type d'imprimante. Elle ne peut que recevoir un flot de données venant du réseau. Dans ce cas, vous la “reliez” à une machine du réseau en confiant à cette machine la gestion de la file d'attente et l'envoi des travaux à l'imprimante. La section Imprimantes avec une interface réseau donne quelques indications sur l'installation de ce type d'imprimante. Imprimantes installées sur des machines distantes Le système LPD inclut ce qu'il faut pour envoyer des travaux sur d'autres machines qui exécutent aussi LPD (ou sont compatibles avec). Cela vous permet d'installer une imprimante sur une machine et de la rendre accessible à d'autres machines. Cela marche aussi avec les imprimantes qui ont une interface réseau qui comprend le protocole LPD. Pour utiliser ce type d'impression en réseau, installez d'abord l'imprimante sur une machine, la machine d'impression, en utilisant la Configuration simple d'une imprimante. Utilisez les options nécessaires de la Configuration avancée d'une imprimante. Veillez à tester l'imprimante et vous assurez qu'elle marche avec les options de LPD que vous avez choisies. Si vous utilisez une imprimante avec une interface réseau compatible avec LPD, alors la machine d'impression dont nous parlerons ci-dessous est l'imprimante elle-même, et le nom de l'imprimante est le nom que vous avez utilisé pour configurer votre imprimante. Consultez la documentation de votre imprimante ou de son interface réseau. Ensuite, sur les autres machines depuis lesquelles vous voulez pouvoir accéder à cette imprimante, ajouter une entrée dans leurs fichiers /etc/printcap de la façon suivante: Nommez cette entrée comme vous voulez. Pour plus de simplicité, vous utiliserez éventuellement le même nom et les mêmes alias que sur la machine d'impression. Laissez explicitement la fonctionnalité lp non renseignée (:lp=:). Créez un répertoire tampon et donnez son chemin d'accès avec la fonctionnalité sd. LPD y mettra les travaux avant de les envoyer à la machine d'impression. Donnez le nom de l'imprimante avec la fonctionnalité rm. Donnez le nom de l'imprimante telle qu'elle est connue sur la machine d'impression avec la fonctionnalité rp. C'est tout. Vous n'avez pas besoin de préciser les filtres, les dimensions de la page ou quoi que ce soit d'autre dans le fichier /etc/printcap. Voici un exemple. Il y a deux imprimantes sur la machine rose, bamboo et rattan. Nous allons permettre aux utilisateurs de la machine orchid d'utiliser ces imprimantes. Voici le fichier /etc/printcap de la machine orchid (repris de la section Activer les pages d'en-tête). Il contenait déjà une entrée pour l'imprimante teak; nous avons ajouté les entrées pour les deux imprimantes de la machine rose: # # /etc/printcap pour la machine orchid # ajout des imprimantes (distantes) sur rose # # teak est locale; elle est connectée directement à orchid: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # rattan est connectée à rose; envoyer les travaux pour rattan à rose: # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # bamboo est aussi connectée à rose: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: Nous n'avons plus qu'à créer les répertoires tampon sur orchid: &prompt.root; mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo &prompt.root; chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo &prompt.root; chown daemon.daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo Les utilisateurs d'orchid peuvent maintenant imprimer sur rattan et bamboo. Si, par exemple, un utilisateur d'orchid tape: &prompt.user; lpr -P bamboo -d appreciations-sushi.dvi Le système LPD d'orchid copiera le travail dans le répertoire tampon /var/spool/lpd/bamboo et notera que c'est un travail DVI. Dès qu'il y aura de la place dans le répertoire tampon pour bamboo sur la machine rose, les deux LPD transfèreront le fichier sur rose. Il attendra d'être imprimé dans la file d'attente de rose. La conversion de DVI en PostScript (puisque bamboo est une imprimante PostScript) sera faite par rose. Imprimantes avec une interface réseau La plupart du temps, quand vous achetez une carte d'interface réseau pour une imprimante, vous avez le choix entre deux versions: l'une (la plus chère) émule un gestionnaire d'impression, l'autre (la moins chère) ne vous permet que de lui envoyer des données comme si elle était sur un port parallèle ou série. C'est l'utilisation de cette dernière que décrit la présente section. Pour la version la plus chère, voyez la section précédente, Imprimantes installées sur des machines distantes. Le format du fichier /etc/printcap vous permet d'indiquer quelle interface série ou parallèle utiliser, et (si vous utilisez une interface série), quelle est la vitesse en baud, s'il faut utiliser un contrôle de flux, les délais pour les tabulations, la conversion des sauts de ligne, et ainsi de suite. Mais il n'y a rien pour décrire la connexion d'une imprimante qui écoute sur un port TCP/IP ou un autre port réseau. Pour envoyer des données à une imprimante réseau, il vous faut un programme de communication qui soit appelé par le filtre texte et les filtres de conversion. En voici une exemple: la procédure netprint récupère toutes les données qui arrivent sur l'entrée standard et les envoie à une imprimante réseau. Nous donnons comme premier argument de netprint le nom de machine de l'imprimante et comme deuxième argument le numéro du port auquel se connecter. Remarquez que la communication est à sens unique (de FreeBSD vers l'imprimante); nombre d'imprimantes réseau sont capables de communiquer dans les deux sens, et vous voudrez peut-être en profiter (pour connaître l'état de l'imprimante, gérer la comptabilité, etc.). #!/usr/bin/perl # # netprint - filtre texte pour une imprimante réseau # fichier /usr/local/libexec/netprint # $#ARGV eq 1 || die "Usage: $0 <printer-hostname> <port-number>"; $printer_host = $ARGV[0]; $printer_port = $ARGV[1]; require 'sys/socket.ph'; ($ignore, $ignore, $protocol) = getprotobyname('tcp'); ($ignore, $ignore, $ignore, $ignore, $address) = gethostbyname($printer_host); $sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address); socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol) || die "Impossible de créer la socket TCP/IP: $!"; connect(PRINTER, $sockaddr) || die "Impossible de contacter $printer_host: $!"; while (<STDIN>) { print PRINTER; } exit 0; Nous pouvons utiliser cette procédure avec différents filtres. Supposons que nous ayons une imprimante ligne Diablo 750-N sur notre réseau. Cette imprimante reçoit les données à imprimer sur le port 5100. Son nom de machine est scrivener. Voici le filtre texte pour cette imprimante: #!/bin/sh # # diablo-if-net - filtre texte pour l'imprimante Diablo `scrivener' à l'écoute # sur le port 5100. fichier /usr/local/libexec/diablo-if-net /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100 Restreindre l'accès aux imprimantes Cette section vous donne des informations sur les restrictions d'accès aux imprimantes. Le système LPD vous permet de contrôler quels sont les utilisateurs qui peuvent accéder aux imprimantes, locales et distantes, s'ils ont le droit d'imprimer en plusieurs exemplaires, quelle taille peut avoir leurs travaux, et quelle peut être la taille maximale de la file d'attente. Restreindre l'impression de plusieurs exemplaires Avec le système LPD, il est facile pour les utilisateurs d'imprimer en plusieurs exemplaires. Il leur suffit d'utiliser lpr -#5 (par exemple) pour obtenir 5 exemplaires de chaque fichier de leur travail d'impression. C'est à vous de décider si c'est une bonne chose. Si vous pensez que les impressions multiples usent inutilement vos imprimantes, vous pouvez désactiver l'option de lpr en ajoutant la fonctionnalité sc au fichier /etc/printcap. Quand les utilisateurs soumettront des travaux avec l'option , ils auront le message : lpr: multiple copies are not allowed (L'impression en plusieurs exemplaires n'est pas autorisée.) Notez bien que si vous avez défini une entrée pour une imprimante distante (voyez la section Imprimantes installées sur des machines distantes), vous devrez aussi définir la fonctionnalité sc dans le fichier /etc/printcap de la machine, ou bien les autres utilisateurs pourrons envoyer des impressions multiples depuis d'autres machines. Voici un exemple. C'est le fichier /etc/printcap de la machine rose. L'imprimante rattan est assez robuste, nous y autoriserons les impressions multiples, mais l'imprimante laser bamboo est un peu plus fragile, nous y désactiverons donc les impressions en plusieurs exemplaires en ajoutant la fonctionnalité sc: # # /etc/printcap pour la machine rose # interdire plusieurs exemplaires sur bamboo # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Il nous faut encore ajouter la fonctionnalité sc dans /etc/printcap sur la machine orchid (et pendant que nous y sommes, désactivons les exemplaires multiples sur l'imprimante teak): # # /etc/printcap pour la machine orchid - pas d'impression en plusieurs # exemplaires sur l'imprimante locale teak ni sur l'imprimante distante bamboo # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: Avec la fonctionnalité sc, nous empêchons d'utiliser la commande lpr -#, mais cela n'évite pas que les utilisateurs exécutent plusieurs fois lpr, ou soumettent plusieurs fois les mêmes fichiers dans un même travail, comme ceci: &prompt.user; lpr a-vendre.annonce a-vendre.annonce a-vendre.annonce Il y a de nombreux moyens d'empêcher ce type d'abus que vous êtes libre d'essayer (y compris l'ignorer). Restreindre l'accès aux imprimantes Vous pouvez contrôler qui imprime sur quelle imprimante avec le mécanisme des groupes d'UNIX et la fonctionnalité rg dans /etc/printcap. Définissez les utilisateurs auxquels vous voulez autoriser l'accès à une imprimante dans un groupe précis et donnez ce groupe en paramètre de la fonctionnalité rg. Les utilisateurs qui n'appartiennent pas à ce groupe (y compris le super-utilisateur) seront accueillis par: lpr: Not a member of the restricted group (Vous n'appartenez pas au groupe autorisé.) s'ils essaient d'utiliser l'imprimante en question. De même que pour la fonctionnalité sc (suppressions des exemplaires multiples), vous devez spécifier rg sur les machines distantes qui ont accès à l'imprimante, si cela vous paraît indiqué (voyez la section Imprimantes installées sur des machines distantes). Par exemple, nous ne laisserons pas tout le monde imprimer sur rattan, mais seuls les utilisateurs du groupe artists pourront utiliser bamboo. Voici notre habituel fichier /etc/printcap pour la machine rose: # # /etc/printcap pour la machine rose - restriction d'accès à bamboo # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Laissons tel quel l'autre fichier /etc/printcap (de la machine orchid). Bien sûr, tous les utilisateurs d'orchid peuvent alors imprimer sur bamboo. Selon le cas, nous voudrons restreindre ou non l'accès à certains utilisateurs d'orchid. Avec cette fonctionnalité, il ne peut y avoir qu'un seul groupe d'utilisateurs autorisé par imprimante. Contrôler la taille des travaux soumis Si de nombreux utilisateurs accèdent à vos imprimantes, vous voudrez probablement limiter la taille des fichiers qu'ils peuvent imprimer. Après tout, l'espace disponible sur les systèmes de fichiers où se trouvent les files d'attente n'est pas illimité, et vous devez aussi faire en sorte qu'il y ait de la place pour les travaux de tous les utilisateurs. LPD vous permet de définir une taille maximum en octets que peut avoir un fichier à imprimer grâce à la fonctionnalité mx. L'unité est le bloc BUFSIZ, qui est de 1024 octets. Si vous donnez en paramètre de cette fonctionnalité la valeur zéro, la taille des fichiers ne sera pas limitée. Cette limite s'applique à la taille des fichiers d'un travail d'impression, et non au volume total du travail. LPD ne refusera pas d'imprimer un fichier trop volumineux. Il en mettra autant que la limite donnée dans la file d'attente. Cette partie sera imprimée, le reste sera ignoré. Est-ce la bonne méthode, le débat reste ouvert. Ajoutons des limites aux imprimantes rattan et bamboo de notre exemple. Comme les fichiers PostScript de nos artistes sont assez volumineux, nous les limiterons à 5 méga-octets. Nous ne mettrons pas de limitation à l'utilisation de l'imprimante texte: # # /etc/printcap pour la machine rose # # # Pas de limite à la taille des fichiers: # rattan|line|diablo|lp|Imprimante Ligne Diablo 630:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Pas plus de 5 méga-octets # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Encore une fois, ces limitations s'appliquent aux utilisateurs locaux. Si ces imprimantes sont accessibles à distance, les utilisateurs distants ne seront pas assujettis à ces limites. Il vous faut aussi introduire la fonctionnalité mx dans les fichiers /etc/printcap des machines distantes. Voyez la section Imprimantes installées sur des machines distantes pour plus d'informations sur l'impression à distance. Il y a un autre moyen de limiter le volume des travaux d'impression à distance; voyez la section Contrôler les impressions à distance. Contrôler les impressions à distance Le système LPD fournit différents moyens de contrôler les impressions depuis des machines distantes: Restrictions selon les machines Vous pouvez contrôler de quelles machines distantes le “démon” LPD local acceptera des requêtes d'impression grâce aux fichiers /etc/hosts.equiv et /etc/hosts.lpd. LPD vérifie si la requête vient d'une machine mentionnée dans l'un de ces deux fichiers. Si ce n'est pas le cas, il refuse la requête. Le format de ces fichiers est trivial: un nom de machine par ligne. Notez que le fichier /etc/hosts.equiv est aussi utilisé par le protocole ruserok3, et affecte des programmes comme rsh et rcp, faites donc attention. Voici par exemple le fichier /etc/hosts.lpd de la machine rose: orchid violet madrigal.fishbaum.de Ce qui signifie que rose acceptera les demandes qui viennent des machines orchid, violet et madrigal.fishbaum.de. Si une autre machine fait appel au LPD de rose, il lui refusera l'accès. Restrictions de volume Vous pouvez contrôler combien il doit rester d'espace libre sur le système de fichiers où se trouve le répertoire de file d'attente. Créez un fichier appelé minfree dans le répertoire de file d'attente de l'imprimante local. Mettez-y un nombre de blocs disque (512 octets) qui sera l'espace qui devra être disponible pour qu'un travail d'impression à distance soit accepté. Vous vous assurez ainsi que les utilisateurs distants ne satureront pas votre système de fichiers. Vous pouvez aussi utiliser cette possibilité pour donner une certaine priorité aux utilisateurs locaux: ils pourront mettre des travaux en attente bien après que l'espace disponible soit descendu en dessous de la valeur indiquée par le fichier minfree. Définissons par exemple un fichier minfree pour l'imprimante bamboo. Nous regardons dans /etc/printcap pour savoir quel est son répertoire de file d'attente. Voici l'entrée pour bamboo: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Le répertoire de file d'attente est défini par la fonctionnalité sd. Nous fixerons à trois méga-octets (soit 6144 blocs disque) l'espace qui doit être libre pour que LPD accepte des impressions distantes: &prompt.root; echo 6144 > /var/spool/lpd/bamboo/minfree Restrictions sur les utilisateurs Vous pouvez contrôler quels utilisateurs distants peuvent utiliser les imprimantes locales avec la fonctionnalité rs dans /etc/printcap. Quand rs est mentionnée dans l'entrée correspondant à une imprimante locale, LPD acceptera les impressions venant de machines distantes si et seulement si l'utilisateur qui soumet le travail a un compte sous le même nom sur la machine locale. Sinon, le travail d'impression sera refusé. Cette fonctionnalité est particulièrement utile lorsque (par exemple) plusieurs départements partagent un réseau et certains utilisateurs sont à cheval sur plusieurs départements. En leur ouvrant un compte sur vos systèmes, ils peuvent utiliser les imprimantes de leur propre département. Si vous préférez qu'ils n'utilisent que vos imprimantes, mais pas vos machines, vous pouvez leur ouvrir des comptes “jeton”, sans répertoire utilisateur et avec un interpréteur de commandes inutilisable tel que /usr/bin/false. Comptabiliser l'utilisation des imprimantes Donc, vous voulez facturer les impressions. Et pourquoi pas? Le papier et l'encre coûtent de l'argent. Il y a aussi les coûts de maintenance. Les imprimantes ont des pièces mobiles qui ont tendance à casser. Vous avez fait un bilan du coût de vos imprimantes, consommables et frais de maintenance et avez calculé un coup à la page (ou au mètre, ou toute autre unité). Comment faites-vous maintenant pour comptabiliser les impressions? Bien, la mauvaise nouvelle est que le gestionnaire d'impression LPD n'aide pas beaucoup dans ce domaine. La facturation dépend dans une large mesure du type d'imprimante, du format utilisé, et de votre politique de facturation de l'utilisation des imprimantes. Pour mettre en oeuvre la facturation, vous devez modifier le filtre texte de l'imprimante (pour facturer l'impression de fichiers texte) et les filtres de conversion (pour les autres formats de fichiers), pour qu'ils comptent les pages ou interrogent l'imprimante pour connaître le nombre de pages imprimées. Vous ne pouvez pas vous en sortir avec un simple filtre de sortie, qui n'est pas capable de gérer la comptabilité. Voyez la section Filtres. D'une façon générale, il y a deux méthodes de faire la facturation: La facturation périodique est la méthode la plus courante, probablement parce que c'est la plus facile. Chaque fois que quelqu'un imprime, le filtre enregistre dans le fichier comptable le nom de l'utilisateur, celui de la machine et le nombre de pages imprimées. Tous les mois, semestres, années, ou avec la périodicité que vous voulez, vous récupérez les fichiers comptables des différentes imprimantes et facturez leur utilisation. Vous réinitialisez ensuite ces fichiers, et repartez à zéro pour la période suivante. La facturation à la volée est moins utilisée, certainement parce qu'elle est plus délicate. Avec cette méthode, les filtres facturent les utilisateurs dès qu'ils utilisent les imprimantes. Comme pour les quotas d'espace disque, la comptabilité est immédiate, Vous pouvez interdire aux utilisateurs d'imprimer dès qu'ils sont dans le rouge et leur fournir un moyen de consulter et modifier leurs “quotas d'impression”. Mais cette méthode demande de mettre en oeuvre une base de données pour gérer les utilisateurs et leurs quotas. Le gestionnaire d'impression LPD permet de mettre facilement en oeuvre les deux méthodes: de même que vous devez fournir des filtres (la plupart du temps, au moins), vous devez aussi écrire le code de facturation. Mais cela a un avantage: vous avez énormement de souplesse pour la méthode. Par exemple, vous pouvez choisir entre la facturation périodique ou à la volée. Vous pouvez choisir quelles informations utiliser: le nom d'utilisateur, le nom de machine, le type d'impression, le nombre de pages, la surface ou la quantité de papier utilisée, le temps qu'a pris l'impression, et ainsi de suite. Vous faites cela en modifiant le filtre pour qu'il archive ces informations. Facturation simplifiée FreeBSD inclut deux programmes que vous pouvez immédiatement configurer pour une facturation périodique de base. Ce sont le filtre texte lpf, décrit à la section lpf: un filtre texte, et pac, un programme qui rassemble et globalise les données des fichiers comptables. Comme indiqué à la section sur les filtres (Filtres), LPD exécute le filtre texte et les filtres de conversion en leur donnant en argument le nom du fichier comptable. Les filtres peuvent utiliser ce paramètre pour savoir où écrire l'enregistrement comptable. Le nom du fichier est précisé par la fonctionnalité af du fichier /etc/printcap, avec un chemin d'accès absolu ou relatif au répertoire de file d'attente. LPD exécute lpf avec comme paramètres la largeur et la hauteur de page (définies par les fonctionnalités pw et pl). lpf utilise ces arguments pour savoir combien il faudra de papier. Après avoir envoyé le fichier à l'imprimante, il génère alors un enregistrement dans le fichier comptable. Cet enregistrement ressemble à ce qui suit: 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang Il faut utiliser un fichier comptable différent pour chaque imprimante, car lpf ne sait pas verrouiller les fichiers, et deux lpf pourraient corrompre leurs enregistrements respectifs s'ils écrivaient en même temps dans le même fichier. Une façon simple d'être sûr que l'on a des fichiers différents pour chaque imprimante est d'utiliser af=acct dans /etc/printcap. On a alors dans les répertoires de file d'attente de chaque imprimante, un fichier comptable appelé acct. Quand vous voulez facturer les utilisateurs, exécutez le programme pac. Allez simplement dans le répertoire de file d'attente de l'imprimante dont vous voulez récupérer les informations comptables et tapez pac. Vous obtiendrez un résumé (en dollars) des coûts: Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 Voici les arguments qu'attend pac: L'imprimante dont on veut le résumé comptable. Cette option ne fonctionne que si l'on a donné un chemin d'accès absolu à la fonctionnalité af dans /etc/printcap. Trier par coûts au lieu d'utiliser l'ordre alphabétique des noms d'utilisateurs. Ne pas tenir compte du nom de machine indiqué pour la comptabilité. Avec cette option, l'utilisateur smith sur la machine alpha est le même utilisateur que smith sur la machine gamma. Sinon, ils sont considérés comme des utilisateurs différents. Calculer les coûts sur la base du prix en dollars par page ou par pied (“ft”) au lieu d'utiliser la valeur donnée avec la fonctionnalité pc dans /etc/printcap, ou deux centimes (la valeur par défaut). prix peut être un nombre en virgule flottante. Trier dans l'ordre inverse. Editer le résumé comptable et tronquer le fichier. nom ... N'imprimer les informations comptables que pour l'utilisateur nom. Dans le résumé que produit pac par défaut, vous avez le nombre de pages imprimées par chaque utilisateur sur chaque machine.Si, sur votre site, les machines n'ont pas d'importance (parce que les utilisateurs peuvent se servir de n'importe laquelle), utilisez pac -m, pour obtenir un récapitulatif qui ressemble à: Login pages/feet runs price andy 2.00 1 $ 0.04 kelly 182.00 105 $ 3.64 mary 118.00 35 $ 2.36 root 26.00 12 $ 0.52 zhang 9.00 1 $ 0.18 total 337.00 154 $ 6.74 Pour calculer la facture en dollars, pac utilise la fonctionnalité pc du fichier /etc/printcap (200 par défaut, soit 2 centimes par page). Donnez, en centièmes de centimes, le prix par page ou par pied que vous voulez facturer. Cette valeur peut être redéfinie quand vous utilisez pac avec l'option . Avec l'option , l'unité est le dollar et non plus le centième de centime. Par exemple: &prompt.root; pac -p1.50 facture chaque page un dollar cinquante centimes. Vous pouvez vraiment faire des affaires avec cette option. Enfin, utiliser pac -s sauvegardera le résumé dans un fichier comptable récapitulatif, de même nom que le fichier comptable associé à l'imprimante, mais suffixé par _sum. Le fichier comptable est ensuite tronqué. La prochaine fois que vous utiliserez pac, ce fichier récapitulatif sera relu et pris en compte pour recalculer les totaux, en y ajoutant ce qui est comptabilisé dans le fichier comptable normal. Comment compter le nombre de pages imprimées? Pour comptabliser correctement les impressions, même à distance, vous devez pouvoir calculer la quantité de papier consommée par chaque travail. C'est la difficulté principale liée à la facturation des impressions. Pour les impressions en mode texte, la difficulté n'est pas si grande: vous comptez le nombre de lignes à imprimer et le comparer au nombre de lignes que l'imprimante peut éditer par page. N'oubliez pas de prendre les retours arrière en compte, lorsqu'il y a sur-impression, de même que les lignes trop longues qui s'impriment sur plus d'une ligne. Le filtre texte lpf (décrit dans lpf: un filtre texte) prend tout cela en compte lorsqu'il gère la comptabilité. Si vous écrivez un filtre texte qui doit prendre la facturation en charge, vous devriez jeter un oeil au code source de lpf. Comment prendre les autres formats en compte? Pour les conversions de DVI en LaserJet ou PostScript, le filtre peut analyser la sortie de dvilj ou dvips pour y lire le nombre de pages converties. Vous devriez être en mesure de faire de même avec d'autres formats de fichiers et d'autres programmes de conversion. Ces méthodes sont toutefois limitées parce qu'elles ne prennent pas en compte le fait que l'imprimante n'imprimera peut-être pas toutes ces pages. Il peut par exemple y avoir bourrage ou manque d'encre - et l'utilisateur sera malgré tout facturé. Que pouvez-vous alors faire? Il n'y a qu'une seule méthode sûre pour tenir une comptabilité précise. Faire dire à l'imprimante combien de papier elle utilise, et la connecter sur un port série ou directement sur le réseau. Pratiquement toutes les imprimantes PostScript offrent cette possibilité. C'est aussi faisable avec d'autres modèles (les imprimantes laser réseau Imagen, par exemple). Modifiez les filtres de ces imprimantes pour lire le nombre de pages imprimées à la fin de chaque travail et reportez dans le fichier comptable des informations qui se basent uniquement là-dessus. Il n'y a alors pas besoin de compter les lignes ou d'un examen des fichiers qui peut être source d'erreurs. Vous pouvez toujours en définitive vous montrer généreux et instituer la gratuité des impressions. Alternatives au gestionnaire d'impression standard Si vous avez lu intégralement ce document jusqu'ici, vous savez maintenant à peu près tout ce qu'il faut savoir sur le gestionnaire d'impression LPD qui est livré avec FreeBSD. Vous pouvez juger de ses limitations, ce qui vous amène tout naturellement à vous demander s'il existe d'autres gestionnaires d'impression (qui fonctionnent sous FreeBSD). Malheureusement, je n'ai trouvé que deux alternatives - et elles sont quasiment semblables! Ce sont: PLP, le “Portable Line Printer Spooler” (gestionnaire d'impression en ligne portable) PLP est basé sur un logiciel développé par Patrick Powell puis maintenu par un groupe de développeurs sur Internet. Le site de référence pour ce logiciel est ftp://ftp.iona.ie/pub/plp. Il y a aussi une page Web. Il ressemble beaucoup au gestionnaire LPD de BSD, mais en améliore un grand nombre de fonctionnalités, dont: Meilleur support réseau, dont le support intégré des imprimantes réseau, fichiers printcap gérés par NIS, et montage NFS des répertoires tampons. Gestion sophistiquée des files d'attentes, permettant d'avoir plusieurs imprimantes sur la même file, le transfert de travaux d'une file à une autre, et la redirection des files d'attente. Fonctions de contrôle à distance des imprimantes. Gestion des priorités des travaux. Extensions aux options d'accès et de sécurité. LPRng LPRng, qui signifie “LPR: the Next Generation” (LPR : la génération suivante) est une réécriture complète de PLP. Patrick Powell et Justin Mason (le principal responsable de la maintenance de PLP) ont coopéré pour réaliser LPRng. Le site de référence de LPRng est ftp://dickory.sdsu.edu/pub/LPRng. Remerciements Je voudrais remercier les personnes suivantes pour l'aide qu'elles m'ont apportée pour réaliser ce document: Daniel Eischen deischen@iworks.interworks.org Qui a fourni une pléthore de programmes de filtre HP que j'ai pu réutiliser. &a.jehamby; Pour le filtre de conversion Ghostscript pour HP. Ma femme, Mary Kelly urquhart@argyre.colorado.edu Pour m'avoir laissé passer plus de temps avec FreeBSD qu'avec elle. diff --git a/fr_FR.ISO8859-1/books/handbook/security/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/security/chapter.sgml index 3198d08340..3a520d8214 100755 --- a/fr_FR.ISO8859-1/books/handbook/security/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/security/chapter.sgml @@ -1,1894 +1,1894 @@ Sécurité &trans.a.haby; DES, MD5, et Crypt Contribution de &a.wollman;24 Septembre 1995. Pour éviter que les mots de passe ne soient facilement accessibles sur les systèmes UN*X, ils ont traditionnellement été brouillés d'une façon ou d'une autre. Depuis la Septième Edition d'Unix de Bell Labs', les mots de passe ont été codés avec ce que les spécialistes de la sécurité appellent “un hachage irréversible”. Ce qui signifie que le mot de passe est transformé de telle sorte qu'une fois encodé, il ne puisse être décodé, sinon par la force, en parcourant l'éventail de toutes les possibilités. Malheureusement, la seule méthode accessible aux chercheurs d'AT&T était basée sur DES, le “Data Encryption Standard” (standard de cryptage des données). C'est un problème mineur pour les distributeurs de logiciels commerciaux, mais un obstacle sérieux pour un système d'exploitation comme FreeBSD, dont tout le code source est accessible librement, parce que, dans de nombreux pays, l'exportation de DES et d'autres logiciels de cryptage est restreinte. L'équipe de développement de FreeBSD s'est donc retrouvée face au dilemme suivant: comment rester compatible avec les autres systèmes Unix sans enfreindre la législation. Nous avons donc décidé d'une double approche: avoir une distribution qui ne comporte que du logiciel de hachage des mots de passe non restreint à l'exportation, et fournir une bibliothèque séparée pour le DES. L'algorithme de codage a été extrait de la bibliothèque C et déplacé dans une bibliothèque séparée appelée libcrypt, du nom de la fonction C crypt qui l'implémente. Dans FreeBSD 1.x et quelques instantanés de pré-versions 2.0, l'algorithme librement exportable utilise une fonction non sécurisée due à Nate Williams; dans les versions ultérieures, il a été remplacé par la fonction de hachage irréversible MD5 de RSA Data Security, Inc. Comme aucune de ces fonctions n'utilise de technique de cryptage, elles sont supposées librement exportables des Etats-Unis et importables dans de nombreux autres pays. Dans le même temps, nous avons aussi travaillé sur une fonction basée sur le cryptage DES. Tout d'abord, une version de la fonction crypt écrite en dehors des Etats-Unis a été importée, pour synchroniser le code américain et celui du reste du monde. Puis la bibliothèque a été modifiée et coupée en deux; la bibliothèque libcrypt DES ne contient que le code de hachage irréversible des mots de passe, et une deuxième bibliothèque libcipher contient les points d'entrée vers le code effectuant le cryptage. Le code a été découpé de cette façon pour obtenir plus facilement la licence d'exportation pour la bibliothèque compilée. Identifier votre mécanisme <command>crypt</command> Il est assez facile de savoir si un mot de passe a été codé avec un algorithme basé sur DES ou sur MD5. Les mots de passe MD5 commencent toujours par les caractères $1$. Les mots de passe DES n'ont pas de caractéristique particulière, mais sont plus courts que les mots de passe MD5 et utilisent un alphabet de 64 caractères qui ne contient pas le caractère $, une chaîne relativement courte qui ne commence pas par un “$” a donc de très fortes chances d'être un mot de passe DES. Savoir quelle bibliothèque est utilisée sur votre système est aussi facile pour la plupart des programmes, sauf pour ceux qui, comme init sont liés statiquement. (Pour ces programmes, il n'y a qu'un moyen: les utiliser avec un mot de passe connu et voir si cela marche.) Les programmes qui utilisent la fonction crypt sont liés avec la bibliothèque libcrypt, qui pour chaque type de codage, est un lien symbolique vers l'implémentation adéquate. Par exemple, sur un système utilisant la version DES: &prompt.user; cd /usr/lib &prompt.user; ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.a Sur un système utilisant les biblothèques basées sur le MD5, on trouvera les mêmes liens, mais ils pointeront sur libscrypt au lieu de libdescrypt. S/Key Contribution de &a.wollman;25 Septembre 1995. S/Key est un système de mots de passe non réutilisables basé sur une fonction de hachage irréversible (notre version est basée sur MD4 pour des raisons de compatibilité; d'autres versions utilisent MD5 et DES-MAC). S/Key est inclus en standard dans toutes les distributions de FreeBSD depuis la version 1.1.5, et est aussi implémenté sur un nombre toujours plus important d'autres systèmes. S/Key est une marque déposée de Bell Communications Research, Inc. Il y a trois types de mots de passe différents dont nous parlerons dans ce qui suit. Le premier est votre mot de passe Unix habituel ou un mot de passe Kerberos; nous l'appelerons “mot de passe Unix”. Le second est le mot de passe non réutilisable généré par le programme S/Key key et reconnu par le programme keyinit et l'invite de session; nous l'appelerons “mot de passe non réutilisable”. Le dernier type de mot de passe est le mot de passe secret que vous donnez au programme key (et parfois au programme keyinit) qui l'utilise pour générer des mots de passe non-réutilisables; nous l'appelerons “mot de passe secret” ou simplement “mot de passe”. Le mot de passe secret n'a rien à voir avec votre mot de passe Unix (ils peuvent être identiques, mais c'est déconseillé). Les mots de passe Unix sont limités à huit caractères, alors que les mots de passe secrets S/Key ont la longueur que vous voulez; j'utilise des phrases de sept mots. En général, le système S/Key fonctionne sans liaison avec le système de mots de passe Unix. Il y a en outre deux autres types de données utilisés par le système S/Key; l'un s'appelle “grain de sel” N.d.T.: “seed” dans l'original en langue anglaise. “salt” est aussi parfois utilisé pour désigner le préfixe utilisé pour perturber un algorithme de hachage. Voir crypt3. ou (cela prête à confusion) “clé” et est un mot de deux lettres et cinq chiffres, et l'autre est le “compteur d'itérations” compris entre 100 et 1. S/Key génère un mot de passe non réutilisable en concaténant le “grain de sel” et le mot de passe secret, en lui appliquant la fonction de hachage irréversible (la fonction sécurisée MD4 de RSA Data Security, Inc.) autant de fois qu'indiqué par le compteur d'itérations, et en convertissant le résultat en six courts mots anglais. Les programmes login et su enregistrent le dernier mot de passe non réutilisable employé, et l'utilisateur est authentifié si la valeur de hachage de son mot de passe est la même que celle de celui qu'il a utilisé auparavant. Comme le hachage utilisé est irréversible, il n'est pas possible de générer de mot de passe non réutilisable si l'on a surpris un de ceux qui a été utilisé avec succès; le compteur est décrémenté après chaque ouverture de session réussie, de sorte que l'utilisateur et le programme d'initialisation de session restent en phase. (Quand ce compteur passe à 1, il est temps de réinitialiser S/Key.) Il y a quatre programmes du système S/Key dont nous traiterons plus bas. Le programme key a comme paramètres un compteur d'itérations, un “grain de sel” et un mot de passe secret et génère un mot de passe non réutilisable. Le programme keyinit initialise S/Key et sert à modifier les mots de passe, les compteurs d'itérations et les “grains de sel”; Ses paramètres sont soit un mot de passe secret, soit un compteur d'itérations, soit un “grain de sel”, et un mot de passe non réutilisable. Le programme keyinfo consulte le fichier /etc/skeykeys et imprime la valeur du compteur d'itérations et le “grain de sel” de l'utilisateur qui l'a invoqué. Enfin, les programmes login et su incorporent la logique nécessaire pour reconnaître les mots de passe non réutilisables S/Key pour authentifier les utilisateurs. Le programme login est aussi capable d'interdire l'utilisation de mots de passe Unix en fonction de l'adresse d'origine de la connexion. Nous décrirons quatre sortes d'opérations. La première est l'utilisation du programme keyinit sur une connexion sécurisée pour initialiser S/Key, ou pour modifier votre mot de passe ou votre “grain de sel”. La seconde est l'emploi du programme keyinit sur une connexion non sécurisée, en même temps que du programme key sur une connexion sécurisée, pour faire la même chose. La troisième est l'utilisation du programme key pour ouvrir une session sur une connexion non sécurisée. La quatrième est l'usage du programme key pour générer un certain nombre de clés qui peuvent être notées ou imprimées et emportées avec vous quand vous allez quelque part ou il n'y a aucune connexion sécurisée (comme dans une conférence). Initialisation depuis une connexion sécurisée Pour initialiser S/Key, changer votre mot de passe ou changer votre “grain de sel” quand vous êtes en session, sous votre compte, sur une connexion sécurisée (e.g., sur la console d'une machine), utilisez la commande keyinit sans paramètres: &prompt.user; keyinit Updating wollman: ) ceci n'apparaît pas si vous Old key: ha73895 ) n'avez pas déjà utilisé S/Key Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. (Rappel - N'employez cette méthode que si vous êtes directement connecté. Si vous utilisez telnet ou rlogin, quittez sans donner de mot de passe et utilisez keyinit -s) Enter secret password: ) j'ai tapé ma phrase clé ici Again secret password: ) je l'ai retapée ID wollman s/key is 99 ha73896 ) voir ci-dessous SAG HAS FONT GOUT FATE BOOM ) Il y a beaucoup de choses là-dedans. A l'invite Enter secret password:, vous devez entrer un mot de passe ou une phrase (j'utilise des phrases d'au moins sept mots) qui servira à générer les mots de passe pour vos sessions. La ligne qui commence par “ID” vous liste vos paramètres S/Key: votre nom d'utilisateur, la valeur de votre compteur d'itérations et votre “grain de sel”. Quand vous ouvrirez une session avec S/Key, le système aura mémorisé ces valeurs et vous les redonnera, vous n'avez donc pas besoin de les retenir. La dernière ligne vous donne le mot de passe non réutilisable correspondant à ces paramètres et à votre mot de passe secret; si vous deviez vous reconnectez immédiatement, c'est ce mot de passe que vous utiliseriez. Initialisation depuis une connexion non sécurisée Pour initialiser S/Key, changer votre mot de passe ou changer votre “grain de sel” quand vous êtes en session sur une connexion non sécurisée, il vous faudra déjà avoir une connexion sécurisée sur une machine où vous pouvez utiliser le programme key; ce peut être depuis un accessoire de bureau sur un Macintosh ou depuis la ligne de commande d'une machine sûre (notre exemple illustre ce dernier cas). Il vous faudra donner une valeur au compteur d'itérations et indiquer un “grain de sel” ou utiliser la valeur aléatoire générée par le programme. Sur la connexion non sécurisée (à la machine que vous initialisez), employez la commande keyinit -s: &prompt.user; keyinit -s Updating wollman: Old key: kh94741 Reminder you need the 6 English words from the skey command. (Rappel - Il vous faut les 6 mots Anglais fournis par la commande skey.) Enter sequence count from 1 to 9999: 100 ) j'ai tapé cela Enter new key [default kh94742]: s/key 100 kh94742 Pour utiliser le “grain de sel” par défaut, (que le programme keyinit appelle une “clé” - key, ce qui prête à confusion), appuyez sur Entrée. Passez ensuite sur votre connexion sécurisée ou sur l'accessoire de bureau S/Key et donnez lui les mêmes paramètres: &prompt.user; key 100 kh94742 Reminder - Do not use this program while logged in via telnet or rlogin. (Rappel - N'utilisez pas ce programme avec une session telnet ou rlogin.) Enter secret password: ) j'ai tapé mon mot de passe secret HULL NAY YANG TREE TOUT VETO Retournez alors sur votre connexion non sécurisée, et donnez le mot de passe non réutilisable généré par la programme key au programme keyinit: s/key access password: HULL NAY YANG TREE TOUT VETO ID wollman s/key is 100 kh94742 HULL NAY YANG TREE TOUT VETO Le reste de la description du paragraphe précédent s'applique aussi ici. Diversion: une invite de session Avant d'expliquer comment générer les mots de passe non réutilisables, nous allons examiner une invite de session S/Key: &prompt.user; telnet himalia Trying 18.26.0.186... Connected to himalia.lcs.mit.edu. Escape character is '^]'. s/key 92 hi52030 Password: Remarquez qu'avant de nous demander un mot de passe, le programme d'initialisation de la session nous affiche le nombre d'itérations et le grain de sel dont nous aurons besoin pour générer la clé appropriée. Vous découvrirez aussi une possibilité intéressante (qui n'est pas illustrée ici); si vous tapez Entrée quand on vous demande votre mot de passe, le programme active l'écho au terminal, de sorte que vous voyez ce que vous tapez. C'est très utile si vous essayez de taper une S/Key à la main, à partir d'un résultat imprimé, par exemple. Si cette machine avait été configurée pour interdire l'emploi de mots de passe Unix depuis ma machine, l'annotation (s/key required) - “(s/key obligatoire)” aurait aussi figuré, précisant que seul un mot de passe S/Key non réutilisable serait accepté. Générer un unique mot de passe non réutilisable Pour générer le mot de passe non réutilisable dont nous avons besoin pour ouvrir la session, nous utilisons une machine sûre et le programme key. (Il y a des versions du programme key pour DOS et Windows, et il y a aussi un accessoire de bureau pour Macintosh.) La version en ligne de commande du programme key a pour paramètres le compteur d'itérations et le “grain de sel”; vous pouvez les couper-coller de l'invite de session, en commençant à key jusqu'à la fin de la ligne. Donc: &prompt.user; key 92 hi52030 ) collé du programme précédent Reminder - Do not use this program while logged in via telnet or rlogin. (Rappel - N'utilisez pas ce programme avec une session telnet ou rlogin.) Enter secret password: ) j'ai tapé mon mot de passe secret ADEN BED WOLF HAW HOT STUN et dans l'autre fenêtre: s/key 92 hi52030 ) de la section précédente Password: (turning echo on) Password:ADEN BED WOLF HAW HOT STUN Last login: Wed Jun 28 15:31:00 from halloran-eldar.l [etc.] C'est la méthode la plus simple si vous avez une machine sûre . Il y a une appliquette Java The Java OTP Calculator, que vous pouvez télécharger et exécuter sous n'importe quel navigateur supportant Java. Générer de multiples mots de passe non réutilisables Il vous faut parfois aller en des endroits où vous n'avez pas de connexion sécurisée disponible. Dans ce cas, vous pouvez utiliser la commande key pour générer en une seule fois plusieurs mots de passe non réutilisables; vous pouvez imprimer ces derniers. Par exemple: &prompt.user; key -n 25 57 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. (Rappel - N'utilisez pas ce programme avec une session telnet ou rlogin.) Enter secret password: 33: WALT THY MALI DARN NIT HEAD 34: ASK RICE BEAU GINA DOUR STAG ... 56: AMOS BOWL LUG FAT CAIN INCH 57: GROW HAYS TUN DISH CAR BALM L'option demande vingt-cinq clés en séquence; l'option indique le rang de la dernière itération; le reste a été décrit plus haut. Notez que les clés sont imprimées dans l'ordre inverse de celui où elles seront éventuellement utilisées. Si vous êtes vraiment paranoïde, vous pouvez les recopier à la main, sinon vous pouvez les couper-coller vers la commande lpr. Remarquez que chaque ligne liste et le nombre d'itérations et le mot de passe non réutilisable; vous trouverez cependant probablement pratique de rayer les mots de passe au fur et à mesure de leur utilisation. Restreindre l'utilisation des mots de passe Unix Le fichier de configuration /etc/skey.access peut servir à définir des restrictions d'utilisation des mots de passe Unix en fonction des noms de machine et d'utilisateur, de la ligne utilisée par le terminal ou de l'adresse IP de la machine connectée à distance. Le format détaillé de ce fichier est décrit dans la page de manuel de skey.access5; elle inclut aussi des avertissements relatifs à la sécurité qu'il faut lire avant de se fier à ce fichier pour sa sécurité. S'il n'y a pas de fichier /etc/skey.access (ce qui est le cas par défaut avec la distribution de FreeBSD), tous les utilisateurs pourront se servir de mots de passe Unix. Si le fichier existe, alors tous les utilisateurs devront passer par S/Key, à moins qu'ils ne soient explicitement autorisés à ne pas le faire par des instructions du fichier skey.access. Dans tous les cas, l'usage de mots de passe Unix est autorisé sur la console système. Voici un exemple de fichier de configuration qui illustre les trois types d'instructions les plus courants: permit internet 18.26.0.0 255.255.0.0 permit user jrl permit port ttyd0 La première ligne (permit internet) autorise les utilisateurs dont les adresses IP (ce qui rend vulnérable en cas d'usurpation) appartiennent au sous-réseau spécifié à employer des mots de passe Unix. Il ne faut pas considérer cela comme une mesure de sécurité, mais plutôt comme un moyen de rappeler aux utilisateurs qu'ils sont sur un réseau non sécurisé et qu'ils doivent utiliser S/Key pour s'authentifier. La seconde ligne (permit user) autorise l'utilisateur désigné à employer n'importe quand des mots de passe Unix. En général, il faut se servir de cette possibilité si les gens soit n'ont pas moyen d'utiliser le programme key, s'ils ont par exemple des terminaux passifs, soit s'ils sont définitivement réfractaires. La troisième ligne (permit port) autorise tous les utilisateurs d'un terminal sur une liaison particulière à utiliser des mots de passe Unix. On emploie cela pour les connexions téléphoniques. Kerberos Contribution de &a.markm; (sur la base d'une - contribution de &a.md;). + contribution de Mark Dapoz). Kerberos est un protocole réseau supplémentaire qui permet aux utilisateurs de s'authentifier en passant par l'intermédiaire d'un serveur sécurisé. Des services comme l'ouverture de session et la copie à distance, la copie sécurisée de fichiers entre systèmes et autres fonctionnalités à haut risque deviennent ainsi considérablement plus sûrs et contrôlables. Les instructions qui suivent peuvent être utilisées comme guide d'installation de Kerberos dans la version distribuée pour FreeBSD. Vous devriez cependant vous référer aux pages de manuel correspondantes pour avoir une description complète. La distribution Kerberos de FreeBSD n'est pas la distribution originale de 4.4BSD-Lite, mais eBones, qui avait été auparavant portée sous FreeBSD 1.1.5.1, et dont les sources ne proviennent pas des Etats-Unis/Canada, ce qui la rend disponible aux utilisateurs d'autres pays. Pour ces derniers, qui ont besoin d'une distribution légale de ce logiciel, s'il vous plait, ne vous la procurez pas depuis un site aux Etats-Unis ou au Canada. Vous lui causeriez de graves problèmes. Il y a une copie légale sur skeleton.mikom.csir.co.za, qui se situe en Afrique du Sud. Créer la base de données initiale Il faut faire cela uniquement sur le serveur Kerberos. Vérifiez d'abord qu'il ne traîne pas d'anciennes bases Kerberos. Allez dans le répertoire /etc/kerberosIV et assurez-vous qu'il ne contient que les fichiers suivants: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms S'il y a d'autres fichiers (comme principal.* ou master_key), utilisez la commande kdb_destroy pour supprimer l'ancienne base de données Kerberos, ou si Kerberos ne tourne pas, effacez simplement les fichiers excédentaires avec rm. Vous devez maintenant éditer les fichiers krb.conf et krb.realms pour définir votre domaine (“realm”) Kerberos. Pour notre exemple, le domaine sera GRONDAR.ZA et le serveur grunt.grondar.za. Nous éditons ou créons alors le fichier krb.conf: &prompt.root; cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov Les autres domaines n'ont pas besoin d'être mentionnés. Ils ne sont là que pour montrer comment une machine peut avoir connaissance de plusieurs domaines. Pour plus de simplicité, vous pouvez ne pas les inclure. La première ligne indique pour quel domaine cette machine agit. Les autres lignes définissent les autres domaines/machines. Chaque ligne comporte d'abord le nom du domaine, puis le nom de la machine qui est le “centre de distribution” de ce domaine. Les mots admin server qui suivent signifient que cette machine est aussi serveur d'administration de la base de données. Pour plus d'explication sur cette terminologie, consultez les pages de manuel de Kerberos. Il faut maintenant ajouter grunt.grondar.za au domaine GRONDAR.ZA et ajouter une entrée pour mettre toutes les machines du domaine DNS .grondar.za dans le domaine Kerberos GRONDAR.ZA. Le fichier krb.realms aura alors l'allure suivante: &prompt.root; cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU Encore une fois, les autres domaines n'ont pas besoin d'être mentionnés. Ils ne sont là que pour montrer comment une machine peut avoir connaissance de plusieurs domaines. Pour plus de simplicité, vous pouvez ne pas les inclure. La première ligne assigne un système particulier au domaine désigné. Les autres lignes montrent comment affecter par défaut les systèmes d'un sous-domaine DNS à un domaine Kerberos donné. Nous pouvons maintenant créer le base de données. Il n'y a à le faire que sur le serveur Kerberos (ou Centre de Distribution de Clés). Cela se fait avec la command kdb_init: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. (On vous demandera le Mot de Passe Maître de la base de données.) (Il est important de NE PAS PERDRE ce mot de passe.) Enter Kerberos master key: Nous devons maintenant sauvegarder la clé pour que les serveurs sur la machine locale puisse la lire, avec la commande kstash: &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! (Clé maître saisie. ATTENTION!) Le mot de passe maître encrypté est enregistré dans le fichier /etc/kerberosIV/master_key. Installer les services Il faut ajouter deux entrées (“principals” N.d.T.: L'“Introduction à Kerberos 5” du NCSA - http://www.ncsa.uuic.edu/General/CC/ACES/kerberos/introduction.html explicite cette notion: “Toute entité à laquelle il faut s'authentifier ou qui doit s'authentifier est un principal Kerberos ... chaque principal a un mot de passe secret qui n'est connu que de lui-même et du Centre de Distribution de Clés. Chaque principal a un nom ... de la forme primaire/instance@domaine.”) à la base de données pour chaque système qui sera sécurisé par Kerberos. Ce sont kpasswd et rcmd. Ces deux entrées sont définies pour chaque système. A chacune de leurs instances est attribuée le nom du système. Ces “démons”, kpasswd et rcmd permettent aux systèmes de changer les mots de passe Kerberos et d'exécuter des commandes comme rcp, rlogin et rsh. Ajoutons donc maintenant ces entrées: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- entrez RANDOM ici Verifying password New Password: <---- entrez RANDOM ici Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- entrez RANDOM ici Verifying password New Password: <---- entrez RANDOM ici Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- ne rien entrez ici permet de quitter le programme Créer le fichier des services Il faut maintenant extraire toutes les instances qui définissent les services sur chaque machine. Cela se fait avec la commande ext_srvtab. Elle crée un fichier qui doit être copié ou reporté par un moyen sûr dans le répertoire /etc/kerberosIV de chaque client Kerberos. Ce fichier doit exister sur tous les serveurs et tous les clients et est crucial au bon fonctionnement de Kerberos. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Cette commande ne génère qu'un fichier temporaire qui doit être renommé en srvtab pour que tous les serveurs puissent y accéder. Utilisez la commande mv pour l'installer sur le système d'origine: &prompt.root; mv grunt-new-srvtab srvtab Si le fichier est destiné à un client, et que le réseau n'est pas considéré comme sûr, copiez le fichier <client>-new-srvtab sur un support amovible et transportez-le par un moyen physiquement sûr. N'oubliez pas de le renommer srvtab dans le répertoire /etc/kerberosIV du client, et mettez-le bien en mode 600: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab Renseigner la base de données Il faut maintenant créer des entrées utilisateurs dans la base de données. Ajoutons une entrée pour l'utilisateur jeanne. Utilisez la commande kdb_edit pour cela: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jeanne Instance: <Not found>, Create [y] ? y Principal: jeanne, Instance: , kdc_key_ver: 1 New Password: <---- entrez un mot de passe sûr ici Verifying password New Password: <---- réentrez le mot de passe sûr là Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- ne rien entrer ici permet de quitter le programme Tester l'ensemble Il faut d'abord démarrer les “démons” Kerberos. NOTEZ que si vous avez correctement modifié votre fichier /etc/rc.conf, cela se fera automatiquement au redémarrage du système. Ce n'est nécessaire que sur le serveur Kerberos. Les clients Kerberos récupéreront automagiquement les informations dont ils ont besoin via leur répertoire /etc/kerberosIV. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead (S'il vous plait, n'utilisez pas kill -9 pour arrêter le programme, utilisez kill à la place) Current Kerberos master key version is 1. Master key entered. BEWARE! Vous pouvez maintenant utiliser la commande kinit pour obtenir un “ticket d'entrée” pour l'utilisateur jeanne que nous avons créé plus haut : &prompt.user; kinit jeanne MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jeanne" Password: Essayons de lister les informations associées avec la commande klist pour voir si nous avons vraiment tout ce qu'il nous faut: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jeanne@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA Essayons maintenant de changer de mot de passe avec la commande passwd pour voir si le “démon” kpasswd est autorisé à accéder à la base de données Kerberos: &prompt.user; passwd realm GRONDAR.ZA Old password for jeanne: New Password for jeanne: Verifying password New Password for jeanne: Password changed. Autoriser l'utilisation de la commande <command>su</command> Kerberos permet d'attribuer à chaque utilisateur qui a besoin des droits du super-utilisateur son propre mot de passe su. Nous pouvons créer un identifiant qui soit autorisé à utiliser su pour devenir root. Cela se fait en associant une instance root à l'identificateur de base. Avec la commande kdb_edit nous créons l'entrée jeanne.root dans la base de données Kerberos: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jeanne Instance: root <Not found>, Create [y] ? y Principal: jeanne, Instance: root, kdc_key_ver: 1 New Password: <---- entrez un mot de passe SUR ici Verifying password New Password: <---- réentrez le mot de passe là Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Laissez une valeur faible! Attributes [ 0 ] ? Edit O.K. Principal name: <---- ne rien entrer ici permet de quitter le programme Vérifions maintenant les caractéristiques associées pour voir si cela marche: &prompt.root; kinit jeanne.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jeanne.root" Password: Il faut maintenant ajouter l'utilisateur au fichier .klogin de root: &prompt.root; cat /root/.klogin jeanne.root@GRONDAR.ZA Essayons maintenant la commande su: &prompt.user; su Password: et voyons quelles sont nos caractéristiques: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jeanne.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA Utiliser d'autres commandes Dans l'exemple précédent, nous avons créé une entrée principale jeanne avec une instance root. Elle reposait sur un utilisateur ayant le même nom que l'entrée principale. C'est ce que fait Kerberos par défaut; une <entrée_principale>.<instance> de la forme <nom_d_utilisateur>.root autorisera <nom_d_utilisateur> à utiliser su pour devenir root si le fichier .klogin du répertoire utilisateur de root est correctement renseigné: &prompt.root; cat /root/.klogin jeanne.root@GRONDAR.ZA De même, s'il y a dans un répertoire utilisateur des lignes de la forme: &prompt.user; cat ~/.klogin jeanne@GRONDAR.ZA jacques@GRONDAR.ZA Cela permet à quiconque dans le domaine GRONDAR.ZA s'est authentifié en tant que jeanne ou jacques (avec kinit, voir plus haut) d'accéder avec rlogin au compte de jeanne ou à ses fichiers sur ce système (grunt) avec rlogin, rsh ou rcp. Par exemple, jeanne ouvre maintenant une session sur un autre système, avec Kerberos: &prompt.user; kinit MIT Project Athena (grunt.grondar.za) Password: %prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 ou bien jacques ouvre une session sur le compte de jeanne sur la même machine (jeanne ayant modifié son fichier .klogin comme décrit plus haut, et l'administrateur de Kerberos ayant défini une entrée principale jacques, sans instance: &prompt.user; kinit &prompt.user; rlogin grunt -l jeanne MIT Project Athena (grunt.grondar.za) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Coupe-Feux Contribution de &a.gpalmer; et &a.alex;. Les coupe-feux suscitent un intérêt croissant de la part de gens qui se connectent à l'Internet, et sont même installés sur des réseaux privés pour accroître leur sécurité. Cette section vise à vous expliquer ce que sont les coupe-feux, comment les utiliser et comment mettre en oeuvre les possibilités offertes par le noyau de FreeBSD pour les implémenter. Les gens pensent souvent qu'avoir un coupe-feu entre le réseau interne de leur entreprise et le “Grand Méchant Internet” résoud tous leurs problèmes de sécurité. Cela peut y concourir, mais une système de coupe-feu mal configuré présente pour la sécurité un risque plus grand que de ne pas en avoir du tout. Un coupe-feu ajoute une couche protectrice supplémentaire à votre système, mais ne sera pas capable d'empêcher un pirate réellement déterminé de pénétrer votre réseau interne. Si vous êtes laxiste quant à votre sécurité interne parce que vous croyez votre coupe-feu impénétrable, vous avez tout bonnement simplifié la tâche des pirates. Qu'est-ce qu'un coupe-feu? Il y a aujourd'hui deux types de coupe-feux différents d'utilisation courante sur l'Internet. Le premier est appelé plus justement routeur filtrant, quand le noyau d'une machine interconnectée à plusieurs réseaux sélectionne, en appliquant un ensemble de règles, les paquets qu'il transmet ou rejette. Le second, désigné par le terme de serveurs mandataires, s'appuie sur des “démons” pour assurer l'authentification et transmettre les paquets, éventuellement sur une machine interconnectée dont la transmission de paquets au niveau du noyau est désactivée. Les sites combinent parfois ces deux approches, de telle sorte qu'une machine seulement (appelée bastion) soit autorisée à envoyer des paquets, via un routeur filtrant, sur le réseau interne. Les services mandatés, qui sont généralement plus sûrs que les mécanismes habituels d'authentification, sont fournis par le bastion. Le noyau de FreeBSD inclut une fonctionnalité de filtrage de paquets (appelée IPFW), dont traite essentiellement la suite de cette section. Des serveurs mandataires sous FreeBSD peuvent être mis en oeuvre avec des logiciels extérieurs, mais il y a une telle variété de serveurs mandataires qu'il est impossible de les décrire dans ce document. Routeurs filtrants Un routeur est une machine qui transmet des paquets entre plusieurs réseaux. Le noyau d'un routeur filtrant comporte en plus du code qui applique à chaque paquet un jeu de règles pour décider de le transmettre ou non. La plupart des logiciels récents de routage IP comportent du code de filtrage de paquets. Pour l'utiliser, vous devez fournir au filtre un ensemble de règles sur la base desquelles il peut décider d'autoriser ou non la transmission des paquets. Pour décider si le paquet peut passer ou non, le code parcourt les règles jusqu'à ce qu'il en trouve une qui corresponde aux en-têtes du paquet. Il effectue alors l'opération associée à la règle. Ce peut être rejeter le paquet, le transmettre, ou même répondre par un message ICMP à l'émetteur. La première règle trouvée, en séquence, est seule prise en considération. On peut donc parler d'une “chaîne de règles”. Les critères de sélection des paquets varient selon les logiciels, mais vous pouvez typiquement définir des règles basées sur les adresses IP de l'émetteur et du destinataire, les ports source et destination (pour les protocoles qui supportent les ports), voir le type de paquet (UDP, TCP, ICMP, etc...). Serveurs mandataires Les serveurs mandataires sont des machines sur lesquelles les “démons” du système standard (telnetd, ftpd, etc) sont remplacés par des serveurs spéciaux. Ce sont ces serveurs que l'on appelle serveurs mandataires, car ils n'autorisent normalement que les connexions entrantes. Cela permet (par exemple), avec un serveur mandataire telnet sur votre bastion, aux gens de se connecter de l'extérieur et d'accéder à votre réseau interne, après avoir satisfait à un mécanisme d'authentification (inversement, des serveurs mandataires peuvent être utilisés pour les connexions du réseau interne vers l'extérieur). Les serveurs mandataires sont généralement plus sûrs que les serveurs ordinaires et disposent d'une plus grande variété de mécanismes d'authentification, dont les mots de passe “à usage unique”, de façon à ce que, même si quelqu'un arrive à surprendre votre mot de passe, il ne puisse l'utiliser pour accéder à vos systèmes, puisqu'il expire aussitôt. Comme ils ne donnent pas aux utilisateurs l'accès à la machine qui les héberge, il en est d'autant plus difficile d'installer une entrée dérobée dans votre système de sécurité. Les serveurs mandataires ont aussi souvent la possibilité de restreindre encore l'accès, de telle façon que seules certaines machines y soient autorisées, et peuvent aussi la plupart du temps être configurés pour définir quels utilisateurs peuvent accéder aux machines cibles. Là encore, les fonctionnalités disponibles dépendent des logiciels que vous choisissez. Que me permet de faire IPFW? IPFW, le logiciel fourni avec FreeBSD, est un système de filtrage de paquets et de comptabilité qui est intégré au noyau, et comporte un outil de configuration accessible à l'utilisateur, ipfw8. Ensemble, ils vous permettent de définir et de consulter les règles appliquées par le noyau pour prendre ses décisions de routage. IPFW comporte deux parties. Le coupe-feu s'occupe du filtrage de paquets. Il y a aussi une partie comptabilité IP, qui vous permet de tracer l'utilisation de votre routeur, sur la base de règles similaires à celle utilisée par le coupe-feu. Vous pouvez (par exemple) savoir quel trafic votre routeur reçoit d'une machine donnée, ou quel volume de requêtes WWW (“World Wide Web”) il transmet. De par la conception d'IPFW, vous pouvez l'utiliser sur une machine qui ne fait pas de routage, pour filtrer les connexions entrantes et sortantes. C'est un cas plus particulier d'application d'IPFW que l'usage général, qui se gère avec les mêmes commandes et les mêmes techniques. Activer IPFW sur FreeBSD Comme la majeure partie du système IPFW est intégrée au noyau, vous devrez ajouter une ou plusieurs options à votre fichier de configuration du noyau, selon les possibilités que vous voulez utiliser, et recompiler votre noyau. Reportez-vous au chapitre Configurer le noyau de FreeBSD pour plus de détails sur la recompilation du noyau. Il y a trois options de configuration du noyau qui concernent IPFW: options IPFIREWALL Intègre au noyau le code de filtrage de paquets. options IPFIREWALL_VERBOSE Donne au code la possibilité de tracer les paquets via syslogd8. Sans cette option et même si vous précisez dans vos règles que les paquets doivent être tracés, rien ne se passera. options IPFIREWALL_VERBOSE_LIMIT=10 Limite le nombre de paquets similaires tracés. Cette option peut être utile dans un environnement hostile, si vous voulez surveiller l'activité de votre coupe-feu, tout en évitant les attaques par refus de service qui submergeraient syslog. Quand une règle atteint le nombre limite de paquets identiques, la trace est désactivée pour cette règle. Pour la remettre en service, vous devrez réinitialiser le compteur associé avec l'utilitaire ipfw8: &prompt.root; ipfw zero 4500 où 4500 est le numéro de la règle que vous voulez de nouveau tracer. Il y avait, dans les versions antérieures de FreeBSD, une option IPFIREWALL_ACCT. Elle est maintenant obsolète. Le code du coupe-feu intègre désormais automatiquement les fonctions comptables. Configurer IPFW La configuration du logiciel IPFW se fait avec l'utilitaire ipfw8. La syntaxe de cette commande paraît assez compliquée, mais elle est relativement simple, une fois que vous en avez compris la structure. L'utilitaire comporte quatre catégories de commandes: ajout/suppression, liste, vidage, réinitialisation. On ajoute et l'on supprime des règles de filtrage. On liste les règles. On vide la séquence de règles, pour supprimer toutes les règles. On réinitialise les informations comptables. Modifier les règles IPFW La syntaxe pour ce type de commande est: ipfw -N commande index action log protocole adresses options Il n'y a qu'un seul indicateur avec ce type de commande: -N Résoudre les adresses et les noms de services dans les sorties. La commande peut être raccourcie à son abbréviation univoque la plus courte. Les commandes valides sont: add Ajoute une entrée à la liste des règles de filtrage/comptabilité. delete Supprime une entrée de la liste des règles de filtrage/comptabilité. Des versions antérieures d'IPFW séparaient les règles de filtrage et celles de comptabilité. La version actuelle autorise la comptabilisation de chaque règle de filtrage. L'index, s'il est renseigné, permet d'insérer la règle à un point précis de la séquence. Sinon, la règle est ajoutée en fin de séquence avec un index de 100 supérieur à la dernière règle existante (à l'exception de la règle par défaut, 65535, “deny”). L'option log active la trace de la règle à la console système, si le noyau a été compilé avec l'option IPFIREWALL_VERBOSE. Les actions valides sont: reject Refuse le paquet, et envoie un message ICMP hôte ou port non joignable (selon le cas) à l'émetteur. allow Transmet normalement le paquet (alias: pass et accept). deny Rejette le paquet. N'envoie pas de message ICMP à l'émetteur (tout ce passe comme si le paquet n'était jamais arrivé à destination). count Met à jour les informations comptables, mais le paquet n'est pas accepté/rejeté sur la base de cette règle. Le filtrage se poursuit avec la règle suivante de la séquence. Chaque action est identifiable par son abbréviation univoque la plus courte. Les protocoles qui peuvent être précisés sont: all N'importe quel paquet IP. icmp Les paquets ICMP. tcp Les paquets TCP. udp Les paquets UDP. Les adresses sont représentées comme suit: from adresse/masqueport to adresse/masqueport via interface Vous ne pouvez spécifier le port qu'avec les protocoles qui les supportent (UDP et TCP). Le paramètre est optionnel et définit soit l'adresse IP, soit le nom de domaine d'une interface IP locale, soit le nom d'une interface (e.g. ed0) pour que la règle ne s'applique qu'aux paquets passant par cette interface. Le numéro d'unité de l'interface peut être remplacé par un caractère de substitution. Par exemple, ppp* désigne toutes les interfaces associées au module PPP intégré au noyau. La syntaxe utilisée pour adresse/masque est: adresse ou: adresse/longueur_du_masque ou: adresse:masque_logique Un nom de machine valide peut remplacer l'adresse IP. est une valeur décimale indiquant combien de digits de l'adresse doivent correspondre. e.g. 192.216.222.1/24 génère un masque tel que toutes les adresses d'un sous-réseau de classe C (dans ce cas, 192.216.222) soient sélectionnées. est une adresse IP telle que le masque soit obtenu par intersection logique (“ET”) avec l'adresse associée. Le mot-clé any peut être utilisé pour indiquer “n'importe quelle adresse IP”. Les numéros des ports à bloquer sont indiqués par: port,port,port... pour donner un seul port ou une liste de ports, ou: port-port pour donner une plage de valeurs. On peut aussi combiner une seule plage et une liste, mais la plage doit toujours être indiquée en premier. Les options disponibles sont: frag Le paquet correspond si ce n'est pas le premier fragment d'un datagramme. in Le paquet correspond si c'est un paquet entrant. out Le paquet correspond si c'est un paquet sortant. ipoptions options Le paquet correspond si son en-tête IP contient les options - séparées par des virgules - de la liste d'options. Les options IP reconnues sont: ssrr (“strict source route” - routage strict par la source) lsrr (“loose source route” - routage souple par la source), rr (“record packet route” - enregistrer la route du paquet), et ts (“timestamp” - date). L'absence d'une option est indiquée en la faisant précéder d'un !. established Le paquet correspond s'il fait partie d'une connexion TCP déjà établie, (i.e. si le bit RST ou ACK est positionné). Vous pouver optimiser les performances du coupe-feu en introduisant une règle established assez tôt dans la séquence. setup Le paquet correspond si c'est un paquet qui initialise une connexion TCP (Le bit SYN est positionné mais pas le bit ACK). tcpflags indicateurs Le paquet correspond si son en-tête contient les indicateurs - séparés par des virgules - de la liste d'indicateurs. Les indicateurs reconnus sont fin, syn, rst, psh, ack, et urg. L'absence d'un indicateur donné est indiquée en le faisant précéder d'un !. icmptypes types Le paquet correspond si son type ICMP appartient à la liste types. La liste est donnée sous forme d'une combinaison de plages et/ou de types séparés par des virgules. Les types ICMP habituellement utilisés sont: 0 “echo reply” (réponse à un ping), 5 “redirect” (modification de la route), 8 “echo request” (émis par ping), et 11 “time exceeded” (utilisé pour indiquer que le TTL - “Time To Live” - durée de vie - ,a été atteint, avec traceroute8, par exemple). Lister les règles IPFW La syntaxe de cette forme de la commande est: ipfw -a -t -N l Il y a trois indicateurs valides avec ce type de commande: -a Affiche avec la liste, les valeurs des compteurs. Cette option est le seul moyen de consulter les informations comptables. -t Affiche la date de dernière concordance pour chaque règle de la séquence. Le format d'affichage n'est pas compatible avec la syntaxe d'entrée de l'utilitaire ipfw8. -N Essaye de résoudre les adresses et le noms des services. Vider les règles IPFW La commande pour vider les règles est: ipfw flush Toutes les règles de la séquence sont supprimées, sauf la règle par défaut définie par le noyau (index 65535). Faites attention quand vous utilisez cette commande, la règle par défaut “deny” isolera votre coupe-feu du réseau jusqu'à ce qu'une nouvelle règle “allow” soit ajoutée à la séquence. Réinitialiser les compteurs IPFW La syntaxe pour réinitialiser un ou plusieurs compteurs de paquets est: ipfw zero index Employée sans l'argument index, tous les compteurs sont réinitialisés. Si un index est précisé, l'opération ne s'applique qu'à la règle correspondante. Exemples de commandes IPFW Cette commande empêchera le routeur de transmettre tous les paquets venant de la machine sales.pirates.org vers le port “telnet” de la machine chics.types.org: &prompt.root ipfw add deny tcp from sales.pirates.org to chics.types.org 23 L'exemple suivant rejette tout trafic TCP venant du réseau pirates.org (un réseau de classe C) vers la machine chics.types.org machine (quel que soit le port). &prompt.root; ipfw add deny log tcp from sales.pirates.org/24 to chics.types.org Si vous ne voulez pas que l'on puisse ouvrir de sessions X sur votre réseau interne (un sous-réseau d'un réseau de classe C), la commande suivante applique le filtrage adéquat: &prompt.root; ipfw add deny tcp from any to mon.reseau.org/28 6000 setup Pour lister les informations comptables: &prompt.root; ipfw -a list ou en abrégé: &prompt.root; ipfw -a l Vous pouvez aussi voir la dernière date d'application d'une règle avec: &prompt.root; ipfw -at l Mettre en oeuvre un coupe-feu filtrant Les suggestions ci-dessous ne sont rien que des suggestions. Les contraintes varient d'un coupe-feu à l'autre et je ne peux pas vous dire comment mettre en place le coupe-feu qui réponde à votre besoin particulier. Lorsque vous commencez à configurer votre coupe-feu, à moins que vous n'ayez un banc d'essai pour faire vos tests dans un environnement que vous contrôlez, je vous conseille vivement d'utiliser les options de trace des commandes après avoir compilé un noyau supportant les traces du coupe-feu. Vous pourrez ainsi identifier rapidement les problèmes et y remédier sans provoquer trop de gêne. Même par la suite, je vous conseille de conserver l'option pour les commandes deny, ce qui vous permettra de tracer les attaques éventuelles et aussi de modifier vos règles si vos besoins évoluent. Tracer les commandes accept aboutit à de gros volumes de fichiers de trace, puisqu'il y a une ligne pour chaque paquet qui transite par le coupe-feu. Les transferts ftp/http importants ralentissent alors sérieusement le système. Cela augmente aussi le temps de latence pour ces paquets, parce que cela demande au noyau plus de traitement avant de les passer. syslogd utilisera aussi plus de temps CPU pour écrire toutes ces informations sur disque et peut même assez rapidement saturer la partition sur laquelle réside le répertoire /var/log. Tel qu'il est livré, FreeBSD ne sait pas charger les règles du coupe-feu au démarrage du système. Je vous suggère d'appeler une procédure ad-hoc depuis la procédure /etc/netstart. Mettez cette procédure assez tôt dans le fichier netstart, de sorte que le coupe-feu soit configuré avant les interfaces IP. Il n'y a ainsi pas de possibilité d'accès tant que votre réseau est encore ouvert. Employez la méthode que vous voulez pour charger les règles. La commande ipfw ne peut pas charger toutes les règles en une seule fois. Je procède de la façon suivante: &prompt.root; ipfw list pour écrire dans un fichier les règles que j'ai définies. Puis j'édite ce fichier pour ajouter ipfw au début de chaque ligne. La procédure peut alors être exécutée pour recharger les règles. C'est n'est peut-être pas la façon la plus efficace de procéder, mais cela marche. La question suivante est de savoir ce que votre coupe-feu doit réellement faire! Cela dépend dans une large mesure des accès que vous voulez autoriser de l'extérieur à votre réseau et vice-versa. Voici quelques règles générales: Bloquez tous les accès entrants sur des ports TCP en dessous de 1024. C'est là que les services les plus problématiques pour la sécurité se trouvent, comme finger, SMTP (courrier électronique) et telnet. Bloquez tout traffic UDP entrant. Il y a très peu de services utiles qui fonctionnent sur UDP, et les services qui sont utiles menacent généralement la sécurité (e.g. Les protocoles RPC et NFS de Sun). Cela présente l'inconvénient que, comme le protocole UDP est sans état, les réponses aux requêtes UDP sortantes sont aussi bloquées. Cela peut poser problème à des utilisateurs internes qui veulent interroger des serveurs archie (prospero) externes. Si vous voulez autoriser l'accès à archie, vous devez accepter les paquets UDP venant des ports 191 et 1525 sur n'importe quel port UDP interne. ntp est un autre service que vous pouver envisager d'autoriser; il utilise le port 123. Bloquez le trafic entrant vers le port 6000. Le port 6000 est utilisé pour accèder aux serveurs X11, et peut présenter des risques pour la sécurité (en particulier si les gens ont l'habitude d'utiliser xhost + sur leur station de travail). X11 peut en fait utiliser une plage de ports commençant au port 6000, la limite supérieure dépendant du nombre de sessions d'affichage qu'accepte la machine. La limite définie par la RFC 1700 est 6063. Répertoriez les ports utilisés par les serveurs internes (e.g. serveurs SQL, ...). C'est probablement une bonne idée de les bloquer aussi, car ils sont normalement hors de la plage 1-1024 décrite plus haut. Le CERT propose d'autres recommendations pour la configuration d'un coupe-feu à l'adresse ftp://ftp.cert.org/pub/tech_tips/packet_filtering. Comme je l'ai dit plus haut, ce ne sont que des propositions. Vous devrez définir vous-même les règles à appliquer à votre coupe-feu. Je ne peux endosser AUCUNE responsabilité si quelqu'un s'infiltre sur votre réseau, même si vous suivez les conseils donnés ci-dessus. diff --git a/fr_FR.ISO8859-1/books/handbook/serialcomms/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/serialcomms/chapter.sgml index 0c6273abe8..e8edf1703f 100644 --- a/fr_FR.ISO8859-1/books/handbook/serialcomms/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/serialcomms/chapter.sgml @@ -1,2351 +1,2351 @@ Communications série &trans.a.haby; Les bases Compilées à partir de la FAQ. Cette section devrait vous donner des informations générales sur les ports série. Si vous n'y trouvez pas ce que vous cherchez, consultez les sections de ce manuel consacrées aux terminaux et aux liaisons téléphoniques. Vos applications ouvrirons normalement le fichier spécial de périphérique ttydX (ou cuaaX). Quand un programme ouvre ce fichier, il retrouve normalement un ensemble de paramètres par défaut pour les entrées/sorties sur le terminal. Vous pouvez visualiser ces valeurs par défaut avec la commande: &prompt.root; stty -a -f /dev/ttyd1 Si vous modifiez le paramètrage de ce périphérique, ces modifications s'appliquent jusqu'à ce que vous fermiez le périphérique. A la prochaine ouverture, le paramètrage par défaut s'applique de nouveau. Pour changer le paramètrage par défaut, vous devez ouvrir et modifier l'“état initial” du périphérique. Par exemple, pour activer le mode CLOCAL, la transmission de données 8 bits et le contrôle de flux XON/XOFF par défaut pour la ligne ttyd5, tapez: &prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff Il est bien de confier cela à la procédure /etc/rc.serial. Ces paramètres par défaut s'appliqueront maintenant lorsqu'une application ouvrira ttyd5. Ce qui ne l'empêche pas de modifier ces valeurs, si besoin est. Vous pouvez aussi empêcher que certaines valeurs puissent être modifiées par une application en changeant l'“état verrouillé” du périphérique. Par exemple, pour fixer la vitesse de ttyd5 à 57600 bps, tapez: &prompt.root; stty -f /dev/ttyld5 57600 Si une application qui ouvre maintenant ttyd5 essaie de modifier la vitesse de ce port, elle sera contrainte de garder la valeur de 57600 bps. Vous devriez bien entendu n'autoriser l'écriture de l'état initial et de l'état bloqué du périphérique qu'au super-utilisateur root. La procédure MAKEDEV NE le fait PAS quand elle crée les fichiers spéciaux de périphériques. Terminaux - Contribution de &a.kelly;28 Juillet + Contribution de Sean Kelly28 Juillet 1996 Utiliser des terminaux est une solution commode et peu coûteuse pour disposer de la puissance de votre système FreeBSD lorsque vous n'êtes pas sur la console de l'ordinateur ou sur un réseau auquel il est connecté. Cette section vous explique comment utiliser des terminaux avec FreeBSD. Usages et types de terminaux Les premiers systèmes Unix n'avaient pas de console. Au lieu de cela, les gens ouvraient des sessions et exécutaient leurs programmes à partir de terminaux qui étaient connectés aux ports série de l'ordinateur. C'est un peu la même chose que lorsque l'on utilise un modem et un logiciel d'émulation de terminal pour se connecter à un système distant et travailler en mode texte. Les PCs d'aujourd'hui ont des consoles graphiques de haute résolution, mais la possibilité d'ouvrir une session sur un port série subsiste toujours sur presque tous les systèmes d'exploitation de type Unix; FreeBSD ne fait pas exception à la règle. Avec un terminal relié à un port série disponible, vous pouvez ouvrir une session et exécuter des programmes comme vous le feriez normalement à la console ou dans une fenêtre xterm avec le gestionnaire X Window. Pour un usage professionnel, vous pouvez connecter de nombreux terminaux à un système FreeBSD et les installer sur les bureaux de vos employés. Pour une usage domestique, un ordinateur inutilisé, un vieux PC ou Macintosh, peut servir de terminal sur un ordinateur plus puissant sous FreeBSD. Vous pouvez ainsi faire de ce qui serait sinon un système mono-utilisateur un puissant système multi-utilisateurs. FreeBSD connaît trois types de terminaux: Les Terminaux passifs, Les PCs servant de terminaux, Les Terminaux X. Les sections qui suivent décrivent chacun de ces types de terminaux. Terminaux passifs Les terminaux passifs sont des matériels spécialisés qui vous permettent de vous connecter à votre ordinateur via une ligne série. On les appelle “passifs” parce qu'ils ne savent qu'afficher, envoyer et recevoir du texte. Ils ne peuvent pas exécuter de programmes. C'est l'ordinateur auquel ils sont connectés qui dispose de tout ce qu'il faut pour faire tourner les logiciels de traitement de texte, les compilateurs, la messagerie électroniques, les jeux, et ainsi de suite. Il ya a des centaines de modèles de terminaux passifs de constructeurs différents, dont le VT-100 de Digital Equipment Corporation et le WY-75 de Wyse. Ils fonctionneront pratiquement tous avec FreeBSD. Certains terminaux haut de gamme peuvent même afficher des graphiques, mais seuls certains logiciels tireront parti de ces possibilités évoluées. Les terminaux passifs sont d'usage courant lorsque les utilisateurs n'ont pas besoin d'accéder à des outils graphiques tels que ceux que fournit le système X Window. PCs servant de terminaux Si un terminal passif ne sait qu'afficher, envoyer et recevoir du texte, alors n'importe quel ordinateur personnel inutilisé peut servir de terminal passif. Il vous faudra uniquement le câble adapté et un programme d'émulation de terminal qui tourne sur cet ordinateur. C'est un usage domestique courant. Si votre femme travaille sur votre console système FreeBSD, vous pouvez travailler en mode texte en même temps à partir d'une machine moins puissante connectée comme terminal à votre système FreeBSD. Terminaux X Les terminaux X sont les terminaux les plus sophistiqués, ils ne se connectent pas à un port série, mais habituellement à un réseau du type Ethernet. Au lieu d'être cantonnés au mode texte, ils peuvent afficher des applications X Window. Les terminaux X ne sont cités ici que pour être exhaustif. Ce chapitre ne décrit pas comment installer, configurer et utiliser des terminaux X. Câbles et Ports Pour relier un terminal à votre système FreeBSD, il vous faut le bon câble et un port série auquel le connecter. Cette section vous explique comment faire. Si vous savez déjà comment brancher votre terminal et quel type de câble il vous faut, passez à la section Configuration. Câbles Comme les terminaux utilisent les ports série, il vous faudra un câble série - appelé aussi RS-232C - pour relier le terminal à votre système FreeBSD. Il y a deux sortes de câbles série. Celui que vous utiliserez dépendra du type de terminal que vous voulez connecter: Si vous connectez un ordinateur personnel pour servir de terminal, utilisez un câble “null-modem”. Un câble “null-modem” relie deux ordinateurs ou deux terminaux entre eux. Si vous avez un vrai terminal, la meilleure source d'information pour savoir quel câble utiliser est la documentation du terminal. Si vous n'avez pas de documentation, essayez un câble “null-modem”. Si cela ne marche pas, alors essayez avec un câble standard. Il faudra aussi que les ports série de votre terminal et de votre système FreeBSD aient des connecteurs compatibles avec le câble que vous utilisez. Câbles “Null-modem” Un câble “null-modem” transmet directement certains signaux, le “signal à la terre”, par exemple, mais en permute d'autres, les broches “émission” et “réception” sont par exemple reliées entre elles, d'une extrémité sur l'autre. Si vous réalisez vous-même vos propres câbles, voici une table qui décrit la méthode recommandée pour fabriquer un câble “null-modem” pour les terminaux. Cette table donne les noms et les numéros de broches des signaux RS-232C sur un connecteur DB-25, Signal Broche # Broche # Signal TxD 2 reliée à 3 RxD RxD 3 reliée à 2 TxD DTR 20 reliée à 6 DSR DSR 6 reliée à 20 DTR SG 7 reliée à 7 SG DCD 8 reliée à 4 RTS [a] RTS 4 5 CTS CTS 5 reliée à 8 DCD Remarques : [a] reliez les broches 4 et 5 entre elles sur le connecteur et à la broche 8 de l'autre extrémité (côté ordinateur). Câbles RS-232C standard Un câble série standard transmet directement les signaux RS-232C. Ce qui signifie que la broche “émission” d'une extrémité est reliée à la broche “émission” de l'autre. C'est le câble que l'on utilise pour connecter un modem à un système FreeBSD, et dont ont besoin certains terminaux. Ports Les ports série sont les périphériques grâce auxquels l'information est échangée entre le terminal et l'ordinateur FreeBSD hôte. Cette section décrit les différents types de ports série existant et comment ils sont adressés par FreeBSD. Types de ports Il y a différents types de ports série. Avant d'acheter ou de monter un câble, vous devez vérifier qu'il soit adapté aux ports de votre terminal et de votre machine FreeBSD. La plupart des terminaux ont des ports DB25. Les ordinateurs personnels, dont les PCs sous FreeBSD, ont des ports DB25 ou DB9. Si vous avez une carte multi-ports série sur votre PC, vous pouvez avoir des ports RJ-12 ou RJ-45. Consultez la documentation de votre matériel pour connaître les spécifications des ports que vous allez utiliser. Un coup d'oeil aux ports suffit souvent aussi. Noms des ports Avec FreeBSD, vous accédez à chacun des ports série par une entrée dans le répertoire /dev. Il y a deux sortes d'entrées: Les ports d'appel entrant sont appelés /dev/ttydX où X est le numéro du port, à partir de zéro. Vous utilisez habituellement les ports d'appel entrant pour les terminaux. Avec ces ports, la ligne série doit émettre le signal “Data Carrier Detect” (DCD) - détection de porteuse - pour qu'ils fonctionnent. Les ports d'appel sortant sont appelés /dev/cuaaX. Vous n'utilisez normalement pas les ports d'appel sortant pour les terminaux, mais pour les modems. Vous pouvez les utiliser avec un terminal, si le câble série ou le terminal ne supportent pas le signal de détection de porteuse. Reportez-vous aux pages de manuel de sio4 pour plus d'informations. Si vous connectez un terminal au premier port série (COM1 en langage DOS), vous utiliserez alors /dev/ttyd0 pour faire référence au terminal. S'il est sur le second port série (aussi appelé COM2), ce sera /dev/ttyd1, et ainsi de suite. Notez bien que vous devrez peut-être configurer votre noyau pour y inclure le support de chaque port série, en particulier si vous avez une carte série multi-ports. Voyez le chapitre Configurer le noyau de FreeBSD pour plus d'informations. Configuration Cette section décrit ce que vous devez faire pour configurer votre système FreeBSD pour pouvoir ouvrir une session depuis un terminal. Elle suppose que vous avez déjà configuré votre noyau pour y inclure le support du port série auquel votre terminal est connecté - et que vous avez branché ce dernier. En un mot, vous devez demander au programme init, qui contrôle le lancement et l'exécution des processus, de lancer un processus getty, lequel se chargera de lire le nom d'utilisateur au début de la session et lancera à son tour le programme login. Pour cela, vous devez éditer le fichier /etc/ttys. Commencez par utiliser su pour devenir super-utilisateur. Modifiez ensuite de la façon suivante /etc/ttys: Ajoutez à /etc/ttys une ligne pour l'entrée du répertoire /dev correspondant au port série, si elle n'y est pas déjà. Précisez qu'il faut exécuter /usr/libexec/getty sur ce port et donnez le type de “getty” approprié, tel qu'il est défini dans le fichier /etc/gettytab. Donnez le type de terminal par défaut. Activez le port avec “on”. Indiquez si le port doit être “secure”. Faites relire le fichier /etc/ttys par init. En option, vous pouvez définir un type de getty sur-mesure pour l'étape 2 en ajoutant une entrée au fichier /etc/gettytab. Ce document ne vous explique pas comment le faire. Vous êtes invités à consulter les pages de manuel de gettytab5 et getty8 pour plus d'informations. Les sections qui suivent détaillent chacune de ces étapes, Dans l'exemple que nous prendrons pour cela, nous connecterons deux terminaux à notre système: un Wyse-50 et un vieil IBM PC 286 avec un logiciel d'émulation de terminal compatible VT-100. Nous connecterons le terminal Wyse au second port série et le 286 au sixième port série (sur une carte multi-ports). Pour plus d'informations sur le fichier /etc/ttys, lisez les pages de manuel de ttys5. Ajouter une entrée à <filename>/etc/ttys</filename> Vous devez d'abord ajouter une entrée au fichier /etc/ttys, à moins qu'il n'y en ait déjà une. Le fichier /etc/ttys liste tous les ports de votre système FreeBSD sur lesquels vous voulez autoriser l'ouverture de session. Par exemple, la première console virtuelle ttyv0 a une entrée dans ce fichier. Vous pouvez ouvrir une session à la console en utilisant cette entrée. Il y a des entrées dans le fichier pour les consoles virtuelles, les ports série et les “pseudo-tty”s. Pour les terminaux physiques, n'indiquez que l'entrée /dev du port série, sans le “/dev/”. A l'installation de votre système FreeBSD, le fichier /etc/ttys contient les entrées pour les quatre premiers ports série: de ttyd0 à ttyd3. Si vous connectez un terminal à l'un de ces ports, vous n'avez pas d'entrée à ajouter. Dans notre exemple, le Wyse-50 va sur le second port série, ttyd1, qui est déjà dans le fichier. Il nous suffit d'ajouter une entrée pour le PC 286 relié au sixième port série. Voici un extrait du fichier /etc/ttys après que nous ayons ajouté cette nouvelle entrée: ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd5 Définir le type de <emphasis remap=tt>getty</emphasis> Nous devons ensuite préciser quel est le programme à exécuter pour gérer les ouvertures de session depuis le terminal. Le programme standard de FreeBSD pour cela est /usr/libexec/getty. C'est lui qui affiche l'invite login:. Le programme getty a un argument (optionnel), le type de getty. Un type de getty décrit les caractéristiques de la ligne sur laquelle est le terminal, telle sa vitesse en bps et le type de contrôle de parité utilisé. le programme getty lit ces caractéristiques dans le fichier /etc/gettytab. Le fichier /etc/gettytab contient un grand nombre d'entrées pour des terminaux anciens et d'autres plus récents. Dans presque tous les cas, les entrées qui commencent par std fonctionneront avec les terminaux physiques. Ces entrées ignorent le contrôle de parité. Il y a un entrée std pour chaque vitesse en bps de 110 à 115200. Vous pouvez bien entendu ajouter vos propres entrées à ce fichier. Les pages de manuel de gettytab5 vous donnent plus d'informations. Quand vous définissez le type de getty dans le fichier /etc/ttys, vérifiez que les paramètres de communication du terminal soient les mêmes. Dans notre exemple, le Wyse-50 n'utilise pas de contrôle de parité et se connecte à 38400 bps. Le PC n'utilise pas de contrôle de parité et se connecte à 19200 bps. Voici le fichier /etc/ttys avec les définitions correspondantes (juste ce qui concerne les deux terminaux qui nous intéressent): ttyd1 "/usr/libexec/getty std.38400" unknown off secure ttyd5 "/usr/libexec/getty std.19200" Remarquez que le second champ - celui qui indique quel programme exécuter - est entre guillemets. C'est important, parce que sans cela le type donné en argument de getty serait interprété comme troisième champ. Définir le type de terminal par défaut Le troisième champ du fichier /etc/ttys donne le type de terminal par défaut sur le port. Pour les ports d'appel entrant, vous y mettez typiquement “unknown” - inconnu - ou dialup - appel - parce que les utilisateurs peuvent s'y connecter avec n'importe quel type de terminal ou de logiciel. Pour les terminaux physiques, le type de terminal ne varie pas, vous pouvez donc indiquer un vrai type de terminal dans ce champ. Habituellement, les utilisateurs emploient le programme tset depuis leur fichier .login ou .profile pour récupérer le type de terminal et demander de le préciser si nécessaire. En définissant le type de terminal dans le fichier /etc/ttys, vous leur évitez qu'on leur pose cette question. Pour savoir quels types de terminaux sont reconnus par FreeBSD, consultez le fichier /usr/share/misc/termcap. Il liste environ 600 terminaux. Vous pouvez en ajouter si vous le désirez. Voyez les pages de manuel de termcap5 pour plus d'informations. Dans notre exemple, le Wyse-50 est un terminal de type Wyse-50 (bien qu'il puisse émuler d'autres types de terminaux, nous le laisseront en mode Wyse-50). Le PC 286 PC utilise Procomm qui sera configuré pour émuler une VT-100. Voici les entrées adéquates, quoiqu'encore incomplètes du fichier /etc/ttys: ttyd1 "/usr/libexec/getty std.38400" wy50 off secure ttyd5 "/usr/libexec/getty std.19200" vt100 Activer le port Le champ suivant de /etc/ttys, le quatrième, indique s'il faut activer le port. Si vous y mettez on, alors le processus init démarrera le programme mentionné par le second champ, getty, qui affichera l'invite de session. Si vous y mettez off, il n'y aura pas de getty, et donc pas d'ouverture de session sur le port. Vous devez donc bien sûr préciser on dans ce champ. Voici de nouveau le fichier /etc/ttys. Nous avons activé les deux ports avec on: ttyd1 "/usr/libexec/getty std.38400" wy50 on secure ttyd5 "/usr/libexec/getty std.19200" vt100 on Définir les ports sécurisés Nous voici arrivé au dernier champ (enfin, presque: il y a un indicateur window optionnel, mais nous ne nous en préocupperons pas). Le dernier champ indique si le port est sécurisé. Que veut dire “sécurisé”? Cela veut dire que le compte super-utilisateur (ou tout compte avec un IDentifiant utilisateur de 0) peut ouvrir une session sur ce port. Les ports non-sécurisés n'autorisent pas l'ouverture de session super-utilisateur. Comment utiliser les ports sécurisés et non sécurisés? Lorsqu'un port est non sécurisé, le terminal qui y est connecté n'autorise pas l'ouverture de session super-utilisateur. Les gens qui connaissent le mot de passe super-utilisateur de votre système FreeBSD devront d'abord se connecter sous un compte utilisateur ordinaire. Ils devront ensuite utiliser la commande su pour avoir les droits du super-utilisateur. Grâce à cela, vous aurez deux enregistrements pour pouvoir repérer les accès super-utilisateur illégitimes: les deux commandes login et su rapportent leur emploi dans le fichier de trace système (les ouvertures de sessions sont aussi enregistrées dans le fichier wtmp). Lorsque le port est sécurisé, l'ouverture de session super-utilisateur est autorisée depuis le terminal. Les gens qui connaissent le mot de passe super-utilisateur peuvent directement se connecter en tant que tel. Vous n'avez plus les traces potentiellement utiles de l'ouverture de session et de l'utilisation de su. Que devez-vous utiliser? Utilisez “non sécurisé”. Utilisez “non sécurisé” même pour les terminaux qui ne sont pas accessibles à tout le monde ou sont dans des locaux fermés à clé. Il est facile d'ouvrir une session et d'utiliser su quand vous avez besoin des droits du super-utilisateur. Voici finalement les entrées complètes du fichier /etc/ttys accompagnées d'un commentaire qui indique où se trouvent les terminaux: ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Cuisine ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Salle de bains Obliger <command>init</command> à relire le fichier <filename>/etc/ttys</filename> Quand vous démarrez FreeBSD, le premier processus, init, lit le fichier /etc/ttys et démarre les programmes listés pour chacun des ports activés, pour afficher l'invite de session. Après avoir modifié /etc/ttys, vous aimeriez ne pas avoir à redémarrer le système pour qu'init voit vos modifications. C'est pourquoi init relit /etc/ttys lorsqu'il reçoit un signal SIGHUP (“hang up” - raccrocher). Donc, après avoir sauvegardé vos modifications au fichier /etc/ttys, envoyez un SIGHUP à init en tapant: &prompt.root; kill -HUP 1 (Le processus init a toujours l'IDentifiant de processus 1.) Si la configuration est correcte, les câbles en place, les terminaux sous tension, vous devriez voir les invites de session. Vos terminaux sont prêts à être utilisés pour la première fois! Régler les problèmes liés à votre connection Même en ayant porté la plus méticuleuse attention aux détails, il peut toujours y avoir quelque chose qui ne va pas lorsque vous installez un terminal. Voici une liste de symptômes et de suggestions de solutions. L'invite de session n'apparaît pas. Vérifiez que le terminal est branché et sous tension. Si c'est un ordinateur personnel utilisé comme terminal, vérifiez qu'il utilise bien le logiciel d'émulation de terminal sur le bon port. Assurez-vous que le câble est solidement raccordé sur le terminal et sur la machine FreeBSD. Vérifiez que c'est le bon type de câble. Contrôlez que le terminal et FreeBSD utilisent la même vitesse en bps et le même contrôle de parité. Si c'est un terminal vidéo, vérifiez que les contrôles de luminosité et de contraste ne soient pas au minimum. Si c'est un terminal papier, vérifiez qu'il y ait du papier et de l'encre. Vérifiez qu'il y ait bien un processus getty qui s'exécute pour ce terminal. Tapez: &prompt.root; ps -axww|grep getty pour avoir la liste des processus getty actifs. Vous devriez voir une entrée pour le terminal. Par exemple, la ligne suivante: 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 montre qu'il y a un getty qui s'exécute sur le port série ttyd1 et utilise l'entrée std.38400 de /etc/gettytab. S'il n'y a pas de processus getty actif, assurez-vous que vous avez activé le port dans /etc/ttys. Avez-vous aussi bien exécuté kill -HUP 1? Il y a n'importe quoi à la place de l'invite de session. Vérifiez que le terminal et FreeBSD définissent la même vitesse et le même contrôle de parité. Assurez-vous que le processus getty utilise le bon type de getty. Dans le cas contraire, corrigez /etc/ttys et exécutez kill -HUP 1. Les caractères sont redoublés; le mot de passe s'affiche quand on le tape. Passez le terminal (ou le logiciel d'émulation de terminal) du mode “half duplex” ou “echo local” en mode “full duplex”. Connexions téléphoniques Contribution de &a.ghelmer;. Ce document donne des indications sur la configuration d'un système FreeBSD pour qu'il accepte des connexions entrantes par modem. Ce document est basé sur l'expérience de son auteur avec les versions 1.0, 1.1 et 1.1.5.1 de FreeBSD (et l'expérience de configuration de modems sur d'autres systèmes d'exploitation de type Unix); il se peut cependant qu'il ne réponde pas à toutes vos questions et ne vous donne pas d'exemple suffisamment adapté à votre environnement. L'auteur ne saurait être tenu responsable des dégats que vous causeriez à vos systèmes ou des données que vous perdriez en essayant de suivre les suggestions qui vous sont données ici. Prérequis Pour commencer, l'auteur suppose que vous connaissez déjà FreeBSD. Il vous faudra un système FreeBSD installé. Vous devez savoir éditer des fichiers dans un environnement Unix et lire les pages de manuel. Comme précisé plus bas, il vous faudra des versions précises de FreeBSD, un minimum de vocabulaire et connaître les modems et le câblage. Version de FreeBSD On suppose tout d'abord que vous utilisez la version 1.1 de FreeBSD ou une version ultérieure (y compris les versions 2.x). La version 1.0 de FreeBSD comportait deux pilotes de périphérique série différents, ce qui complique la situation. Le pilote de périphérique série (sio) a aussi été largement amélioré avec chaque version successive de FreeBSD, les versions plus récentes de FreeBSD ont donc en principe des pilotes meilleurs et plus efficaces que les versions plus anciennes. Terminologie Une revue rapide de la terminologie: bps Bits par seconde - la vitesse à laquelle les informations sont transmises. DTE Data Terminal Equipment - dispositif de traitement de données - Par exemple, votre ordinateur. DCE Data Communications Equipment - dispositif de communication - votre modem. RS-232 Standard EIA pour les communications série physiques. S'il vous faut plus d'informations sur ces termes et sur les transmissions de données en général, l'auteur se rappelle avoir lu que la Bible RS-232 (quelqu'un connaît l'ISBN?) est une bonne référence. Pour parler de la vitesse de transmission des informations, l'auteur n'utilise pas le terme “baud”. Baud désigne le nombre de transitions d'état électrique qui peuvent se produire sur une période de temps donnée, alors que “bps” (bits par seconde) est le terme “correct” à employer (au moins, il ne dérange pas autant les adeptes de la quadri-section capillaire). Modems externes vs. modems internes Les modems externes semblent plus adaptés aux communications à la demande, parce qu'ils peuvent être configurés de façon quasi-permanente grâce à leurs paramètres enregistrés en mémoire non volatile et disposent habituellement de voyants lumineux qui affichent les signaux RS-232 les plus importants. Les lumières impressionnent les visiteurs, mais elles sont aussi très utiles pour savoir si les modems fonctionnent correctement. Les modems internes ne disposent pas généralement de mémoire non volatile, leur configuration peut se limiter au positionnement de cavaliers. Quand ils disposent de voyants, ils sont la plupart du temps difficilement visibles quand le boitier est refermé. Modems et Câbles On suppose que vous avez un minumum de notions sur le sujet: Vous savez connecter votre modem à votre ordinateur de façon à ce qu'ils puissent communiquer (à moins que vous n'ayez un modem interne qui n'a pas besoin de câble). Vous maîtrisez le jeu de commandes de votre modem, ou savez où trouver les commandes dont vous avez besoin. Vous savez configurer votre modem (a priori avec un programme de communication pour terminal) de facon à définir ses paramètres en mémoire non volatile. La première étape, connecter le modem, est généralement simple - la plupart des câbles séries standard fonctionneront sans problème. Vous aurez besoin du câble avec les bons connecteurs (DB-25 ou DB-9, et mâle ou femelle) à chaque extrémité, et il vous faudra un câble DCE-à-DTE avec le brochage suivant: Donnée émise (“Send Data”, SD), Donnée reçue (“Received Data”, RD), Demande d'émission (“Ready To Send”, RTS), Prêt à émettre (“Clear To Send”, CTS), Données prêtes (“Data Set Ready”, DSR), Disponible (“Data Terminal Ready”, DTR), Détection de porteuse(“Carrier Detect”, CD), Terre (“Signal Ground”, SG). FreeBSD a besoin des signaux RTS et CTS pour le contrôle de flux matériel aux vitesses supérieures à 2400bps, du signal CD pour savoir quand la ligne décroche et quand elle raccroche et du signal DTR pour réinitialiser le modem en fin de session. Certains câbles ne transmettent pas tous les signaux, donc, si vous avez des problèmes, comme par exemple, si la session reste ouverte alors que la ligne a raccroché, cela peut être un problème de câble. Le deuxième prérequis dépend du type de modem(s) que vous utilisez. Si vous ne connaissez pas les commandes de votre modem par coeur, gardez le guide de référence ou le manuel utilisateur de votre modem à portée de main. Des exemples de commandes seront donnés pour les modems externes USR Sportster 14.400, qui peuvent vous servir de référence pour les commandes de votre propre modem. Enfin, vous devez savoir comment configurer votre modem pour qu'il marche correctement avec FreeBSD. Comme les autres systèmes d'exploitation de type Unix, FreeBSD utilise les signaux matériels pour savoir quand la ligne a décroché ou raccroché et pour réinitialiser le modem quand la communication est terminée. FreeBSD vous évite d'avoir à envoyer des commandes au modem ou à vérifier ses informations d'état. Si vous avez l'habitude de connecter des modems à de systèmes de discussions (“BBS”) sur PC, cela vous semblera peut-être gênant. A propos de l'interface série FreeBSD supporte les interfaces de communication construites autour des NS8250, NS16450, NS16550, et NS16550A EIA RS-232C (CCITT V.24). Les périphériques 8250 et 16450 ont des tampon d'un caractère. Le 16550 a un tampon de 16 caractères, qui offre de meilleures performances. (Un bogue dans la version 16650 empêche de se servir du tampon de 16 caractères, utilisez donc si possible le modèle 16650A). Parce qu'un tampon d'un seul caractère demande plus de traitement au système d'exploitation qu'un tampon de 16 caractères, les cartes à base de 16650A sont recommandées. Si le système a de nombreux ports série actifs ou si la charge doit être importante, les cartes 16650A sont préférables pour avoir un taux d'erreur de communication plus faible. Résumé Voici comment FreeBSD accepte des communications téléphoniques entrantes. Un processus getty, lancé par init, attend patiemment le moment d'ouvrir le port série qui lui est assigné (/dev/ttyd0, dans notre exemple). On peut le voir avec la commande ps ax: 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 Quand un utilisateur appelle, la connexion s'établit avec le modem. Le modem active le signal CD. Le noyau s'aperçoit qu'une porteuse a été détectée et ouvre le port via getty. getty envoie l'invite login: à la vitesse initialement définie pour cette ligne. getty attend de recevoir des caractères valides, et si, dans un configuration habituelle, il reçoit n'importe quoi (probablement parce que la vitesse du modem et celle de getty ne sont pas identiques), getty essaie d'ajuster la vitesse jusqu'à ce qu'il reçoive des caractères qui paraissent sensés. Souhaitons que getty trouve la bonne vitesse et que l'utilisateur obtienne l'invite login:. Une fois que l'utilisateur a répondu par son nom, getty exécute /usr/bin/login, qui termine l'ouverture de la session en demandant à l'utilisateur son mot de passe et en lançant l'interpréteur de commandes affecté à cet utilisateur. Passons donc à la configuration... Configuration du noyau Les noyaux de FreeBSD sont habituellement livrés prêts à tester la présence de quatre ports série, connus dans le monde PC-DOS sous les noms de COM1:, COM2:, COM3:, et COM4:. FreeBSD peut aussi gérer les cartes série multi-ports “passives”, comme les cartes Boca 1008 et 2016 (reportez-vous s'il vous plaît aux pages de manuel de sio4 pour avoir des informations sur la configuration du noyau si vous avez une carte série multi-ports). Le noyau par défaut ne recherche, quant à lui, que les ports COM standards. Pour vérifier si votre noyau reconnaît vos ports série, regardez les messages au démarrage de votre système, ou employez la commande /sbin/dmesg pour les lister ensuite. Cherchez en particulier les messages qui commencent par sio. Tuyau: pour ne voir que les messages qui comportent le mot sio, utilisez la commande: &prompt.root; /sbin/dmesg | grep 'sio' Par exemple, sur un système avec quatre ports série, voici les messages de démarrage du noyau qui concernent les ports série: sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A Si votre noyau ne reconnait pas tous vos ports série, vous devrez probablement recompiler un noyau sur mesure pour votre système. Lisez le chapitre du Manuel de l'Administrateur Système BSD sur “Générer les noyaux Berkeley avec Config” [que vous trouverez dans le répertoire /usr/src/share/doc/smm] et les “Options de Configuration de FreeBSD” [dans /sys/conf/options et dans /sys/arch/conf/options.arch, ou arch vaut par exemple i386] pour plus d'informations sur la configuration et la recompilation des noyaux. Vous devrez peut-être installer les sources du noyau, si vous ne l'avez pas déjà fait, (srcdist/srcsys.?? pour FreeBSD 1.1, srcdist/sys.?? pour FreeBSD 1.1.5.1, ou les sources de toute la distribution pour FreeBSD 2.0) pour pouvoir configurer et recompiler des noyaux. Créez un fichier de configuration du noyau pour votre système (si vous ne l'avez pas déjà fait) en allant dans le répertoire /sys/i386/conf. Puis si, vous créez un nouveau fichier de configuration, copiez le fichier GENERICAH (ou GENERICBT, si vous avez un contrôleur SCSI BusTek avec FreeBSD 1.x) dans VOTRESYS, où VOTRESYS est le nom de votre système, en majuscules. Editez le fichier, et modifiez les lignes: device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr Vous pouvez commenter ou supprimer les lignes pour les périphériques que vous n'avez pas. Si vous avez une carte série multi-ports, comme la carte Boca BB2016, reportez-vous s'il vous plaît aux pages de manuel de sio4 pour avoir des informations complètes sur les lignes de configuration pour les cartes série multi-ports. Faites attention si vous partez d'un fichier de configuration utilisé pour une version antérieure de FreeBSD, parce que les indicateurs associés au périphérique peuvent avoir changé d'une version à l'autre. port "IO_COM1" est l'équivalent de port 0x3f8, IO_COM2 de 0x2f8, IO_COM3 de 0x3e8 et IO_COM4 de 0x2e8, qui sont les adresses respectives les plus courantes de ces ports série; les interruptions 4, 3, 5, et 9 sont les lignes d'interruption utilisées habituellement. Notez aussi que les ports série ordinaires ne peuvent pas partager d'interruption sur le bus ISA (les cartes multi-ports intègrent l'électronique nécessaire pour permettre au 16550A de la carte de partager une ou deux lignes d'interruption). Quand vous avez terminé de corriger votre fichier de configuration du noyau, utilisez le programme config en suivant la documentation fournie par “Générer les noyaux Berkeley avec Config” et les pages de manuel de config8 pour créer le répertoire de compilation du noyau, puis compilez, intallez et testez votre nouveau noyau. Fichiers spéciaux de périphérique La plupart des périphériques gérés par le noyau sont adressés par l'intermédiaire de “fichiers spéciaux de périphérique”, qui se trouvent dans le répertoire /dev. Les périphériques sio sont adressés via /dev/ttyd? (liaisons entrantes) et /dev/cua0? (liaisons sortantes). Avec les versions 1.1.5 et ultérieures de FreeBSD, il y a aussi des fichiers spéciaux d'initialisation (/dev/ttyid? et /dev/cuai0?) et des fichiers spéciaux de verrouillage (/dev/ttyld? et /dev/cual0?). Les fichiers d'initialisation sont utilisés pour initialiser les paramètres de communication du port chaque fois qu'il est ouvert, comme crtscts pour les modems qui emploient les signaux CTS/RTS pour le contrôle de flux. Les fichiers de verrouillage sont utilisés pour verrouiller des indicateurs sur les ports pour empêcher les utilisateurs ou les programmes de modifier certains paramètres; voyez les pages de manuel de termios4, sio4 et stty1 pour plus d'informations sur le paramétrage des terminaux, le verrouillage et l'initialisation des périphériques et la définition des options pour les terminaux, respectivement. Créer les fichiers spéciaux de périphérique La procédure MAKEDEV du répertoire /dev gère les fichiers spéciaux de périphérique. (Les pages de manuel MAKEDEV8 de FreeBSD 1.1.5 comportent pas mal d'erreurs sur ce qui concerne les ports COM, donc ignorez-les.) Pour utiliser MAKEDEV pour créer les fichiers spéciaux de périphérique pour les connexions sur COM1: (port 0), allez avec cd dans /dev et tapez la commande MAKEDEV ttyd0. De même, pour créer les fichiers spéciaux de périphérique pour COM2: (port 1), utilisez MAKEDEV ttyd1. La commande MAKEDEV ne crée pas uniquement les fichiers /dev/ttyd?, mais aussi les fichiers /dev/cua0? (et tous les fichiers d'initialisation et de verrouillage à partir de la version 1.1.5 de FreeBSD) et supprime le fichier spécial pour le terminal physique /dev/tty0?, s'il existe. Après avoir créé les nouveaux fichiers spéciaux de périphérique, vérifiez les droits sur ces fichiers (en particulier sur les fichiers /dev/cua*) pour vous assurer que seuls les utilisateurs qui doivent y accéder peuvent lire et écrire dessus - vous ne voulez probablement pas que l'utilisateur ordinaire puisse utiliser vos modems pour se connecter à l'extérieur. Les autorisations par défaut sur les fichiers /dev/cua* devraient suffire: crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01 crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01 crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01 Ces droits autorisent l'utilisateur uucp et les utilisateurs du groupe dialer à se servir des périphériques d'appel vers l'extérieur. Fichiers de Configuration Il y a trois fichiers de configuration du système dans le répertoire /etc que vous devrez probablement éditer pour autoriser les accès téléphoniques à votre système FreeBSD. Le premier, /etc/gettytab, contient les informations de configuration pour le “démon” /usr/libexec/getty. Le second, /etc/ttys contient les informations qui disent à /sbin/init sur quels périphériques tty doivent s'exécuter des processus getty. Enfin, vous pouvez mettre les commandes d'initialisation de ports dans la procédure /etc/rc.serial si vous utilisez FreeBSD 1.1.5.1 ou ultérieurs; sinon, vous pouvez initialiser les ports dans la procédure /etc/rc.local. Il y a deux écoles de pensée pour ce qui concerne la configuration des modems sous Unix. La première préfère configurer ses systèmes et ses modems de façon à ce que quelque soit la vitesse à laquelle l'utilisateur se connecte, l'interface RS-232 entre le système et le modem travaille toujours à la même vitesse. L'avantage de cette méthode est que l'utilisateur distant obtient toujours immédiatement l'invite de session. L'inconvénient est que le système ne sait pas quelle est la vitesse réelle de la connexion, de sorte que les programmes plein-écran comme Emacs n'adaptent pas leur mode d'affichage pour améliorer leurs temps de réponse avec des connexions lentes. L'autre école configure les interfaces RS-232 de ses modems de façon à ce qu'elles adaptent leur vitesse en fonction de la vitesse de la connexion de l'utilisateur. Par exemple, les connexions V.32bis (14.4 Kbps) au modem feront fonctionner l'interface RS-232 du modem à 19.2 Kbps, alors que les connexions à 2400 bps la feront fonctionner à 2400 bps. Comme getty ne comprend pas les informations que fournit le modem sur sa vitesse, getty affiche le message login: à la vitesse initiale et consulte la réponse qu'il reçoit. Si les utilisateurs voient n'importe quoi, ils sont censés savoir qu'ils doivent appuyer sur la touche <Entrée> jusqu'à ce qu'ils obtiennent une invite lisible. Si les vitesses ne correspondent pas, getty reçoit n'importe quoi quoi que l'utilisateur tape, essaie de passer à la vitesse suivante et renvoie l'invite login:. Cela peut durer indéfiniment, mais il suffit normalement d'un ou deux essais pour que l'utilisateur obtienne le message correct. Bien entendu, cette méthode d'ouverture de session n'est pas aussi propre que la première, mais un utilisateur dont la connexion est lente obtiendra de meilleurs temps de réponse des logiciels plein-écran. L'auteur essaiera de donner des informations de configuration objectives, mais la méthode qui consiste à ajuster la vitesse du modem à celle de la connexion a sa préférence. <filename>/etc/gettytab</filename> /etc/gettytab est un fichier de type termcap5 qui contient les informations de configuration de getty8. Reportez-vous s'il vous plaît aux pages de manuel de gettytab5 pour une description complète du format de ce fichier et la liste des fonctionnalités. Configuration à vitesse fixée Si vous verrouillez la vitesse de communication avec votre modem à une valeur donnée, vous n'aurez probablement pas à modifier le fichier /etc/gettytab. Configuration avec adaptation de la vitesse Vous devrez définir une entrée dans /etc/gettytab pour fournir à getty des informations sur la vitesse à laquelle vous voulez utiliser votre modem. Si vous avez un modem 2400 bps, vous pouvez probablement utiliser l'entrée D2400. Cette entrée existe déjà dans le fichier gettytab de FreeBSD 1.1.5.1, vous n'avez pas besoin de l'ajouter, à moins qu'elle n'existe pas dans votre version de FreeBSD: # # Terminaux (via téléphone) rapides # sélection 2400/1200/300 (dans l'un ou l'autre sens) # D2400|d2400|Accès-Rapide-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Accès-Rapide-1200:\ :nx=D300:tc=1200-baud: 5|D300|Accès-Rapide-300:\ :nx=D2400:tc=300-baud: Si vous avez un modem plus rapide, vous devrez certainement ajouter une entrée à /etc/gettytab; voici ce que vous pourriez utiliser pour un modem à 14.4 Kbps pour une vitesse maximum de l'interface de 19.2 Kbps: # # Ajouts pour un modem V.32bis # um|V300|Modem Grande Vitesse à 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|Modem Grande Vitesse à 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|Modem Grande Vitesse à 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|Modem Grande Vitesse à 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|Modem Grande Vitesse à 19200,8-bit:\ :nx=V9600:tc=std.19200: Avec FreeBSD 1.1.5 et ultérieurs, cela donnera une connexion 8-bit sans contrôle de parité. Avec FreeBSD 1.1, ajoutez les paramètres :np: aux entrées std.xxx en début de fichier, pour 8 bits, sans parité; sinon, le paramètrage par défaut est à 7 bits, parité paire. Avec l'exemple ci-dessus, la communication se fait initialement à 19.2 Kbps (pour une connexion V.32bis), puis passe à 9600 bps (pour V.32), 2400 bps, 1200 bps, 300 bps, et de nouveau à 19.2 Kbps. Ce parcours des vitesses est implémenté par la fonctionnalité nx= (“next table” - table suivante). Chaque ligne comporte une entrée tc= (“table continuation” - suite de la table) pour utiliser le reste de la configuration “standard” pour une vitesse donnée. Si vous avez un modem à 28.8 Kbps modem et/ou voulez profiter de la compression sur un modem à 14.4 Kbps, vous devez utiliser une vitesse de communication supérieure à 19.2 Kbps. Voici un exemple d'entrée gettytab commençant à 57.6 Kbps: # # Ajout pour un modem V.32bis ou V.34 # On commence à 57.6 Kbps # vm|V300|Modem Très Grande Vitesse à 300,8-bit:\ :nx=V19200:tc=std.300: vn|V1200|Modem Très Grande Vitesse à 1200,8-bit:\ :nx=V300:tc=std.1200: vo|V2400|Modem Très Grande Vitesse à 2400,8-bit:\ :nx=V1200:tc=std.2400: vp|V9600|Modem Très Grande Vitesse à 9600,8-bit:\ :nx=V2400:tc=std.9600: vq|V57600|Modem Très Grande Vitesse à 57600,8-bit:\ :nx=V2400:tc=std.9600: Si vous avez une CPU lente ou un système très chargé et pas de port série à base de 16550, vous aurez peut-être des erreurs “silo” de sio à 57.6 Kbps. <filename>/etc/ttys</filename> /etc/ttys est la liste des ttys qu'init doit gérer. /etc/ttys fournit aussi des informations de sécurité à login (le super-utilisateur root ne peut ouvrir de session que sur des ttys mentionnés comme secure). Voyez les pages de manuel de ttys5 pour plus d'informations. Vous devrez soit modifier les lignes existantes de /etc/ttys, soit ajouter de nouvelles lignes, pour qu'init exécute automatiquement les processus getty sur vos nouveaux ports d'appel. Le format général de la ligne sera le même, que vous utilisiez une configuration avec vitesse verrouilllée ou non: ttyd0 "/usr/libexec/getty xxx" dialup on Le premier champ de la ligne ci-dessus est le fichier spécial de périphérique pour cette entrée - ttyd0 signifie que /dev/ttyd0 est le fichier que ce getty surveillera. Le second champ, "/usr/libexec/getty xxx" (xxx est à remplacer par la fonctionnalité initiale de gettytab) est le processus qu'init lancera pour ce périphérique. Le troisième champ, dialup, est le type de terminal par défaut. Le quatrième paramètre, on, indique à init que cette ligne est opérationnelle. Il peut y avoir un cinquième paramètre, secure, mais il ne faut l'utiliser que pour les terminaux qui sont physiquement “sécurisés”, comme la console système. Le type de terminal par défaut (dialup dans l'exemple précédent) peut dépendre de vos préférences. dialup est le terminal par défaut traditionnel pour les lignes téléphoniques, de façon à ce que les utilisateurs puissent adapter leur procédure d'ouverture de session pour qu'elle sache que c'est un terminal dialup et ajuste en conséquence son type de de terminal. L'auteur préfère quant à lui utiliser vt102 comme type de terminal par défaut sur son site, car ses utilisateurs emploient l'émulation VT102 sur leurs systèmes distants. Après avoir modifié /etc/ttys, vous pouvez envoyer au processus init un signal HUP pour qu'il relise le fichier. Utilisez la commande: &prompt.root; kill -1 1 pour envoyer ce signal. Si c'est la première fois que vous configurer ce système, vous pouvez toutefois attendre que vos modems soient correctement configurés et connectés avant d'envoyer un signal à init. Configuration à vitesse fixée Dans une configuration où la vitesse est fixée, il faut une entrée destinée à getty dans le fichier ttys. Avec un modem pour lequel la vitesse du port série est fixée à 19.2 Kbps, l'entrée de ttys ressemblera à: ttyd0 "/usr/libexec/getty std.19200" dialup on Si vous utilisez une vitesse différente, remplacez l'entrée std.19200 par l'entrée std.vitesse appropriée à la vitesse de transmission de votre modem d'après la définition qui en est donnée dans le fichier /etc/gettytab. Configuration avec adaptation de la vitesse Dans une configuration où la vitesse s'adapte à celle de la connexion, l'entrée dans votre fichier ttys doit faire référence à l'entrée “auto-baud” (sic) initiale de /etc/gettytab. Avec l'exemple donné plus haut pour une configuration avec adaptation de la vitesse commençant à 19.2 Kbps (entrée de gettytab avec V19200 pour point de départ), l'entrée de ttys ressemblera à: ttyd0 "/usr/libexec/getty V19200" dialup on <filename>/etc/rc.serial</filename> ou <filename>/etc/rc.local</filename> Les modems à haut débit, comme les modems V.32, V.32bis, et V.34, doivent utiliser le contrôle de flux matériel (RTS/CTS). Vous pouvez ajouter des commandes stty dans /etc/rc.serial, pour FreeBSD 1.1.5.1 et ultérieurs, ou /etc/rc.local pour FreeBSD 1.1, pour positionner l'indicateur de contrôle de flux matériel du noyau de FreeBSD sur les ports où sont les modems. Voici un extrait d'un fichier /etc/rc.serial d'exemple pour un système FreeBSD 1.1.5.1: #!/bin/sh # # Configuration initiale des ports série stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts Cela positionne l'indicateur crtscts de termios pour les fichiers spéciaux d'initialisation des connexions entrantes et sortantes sur le port série numéro 1 (COM2:). Sur un vieux système FreeBSD 1.1, ces entrées devaient être ajoutées au fichier /etc/rc.local pour positionner l'indicateur crtscts pour les périphériques: # Configurer les ports série pour utiliser le contrôle de flux RTS/CTS stty -f /dev/ttyd0 crtscts stty -f /dev/ttyd1 crtscts stty -f /dev/ttyd2 crtscts stty -f /dev/ttyd3 crtscts Comme il n'y avait pas de fichiers spéciaux d'initialisation dans FreeBSD 1.1, il suffisait de positionner les indicateurs pour les fichiers spéciaux de périphériques, et d'espérer qu'ils ne seraient pas réinitialisés par un petit malin. Configuration des modems Si vous avez un modem dont le paramétrage est enregistré en mémoire RAM non volatile, vous devrez utiliser un programme de terminal (comme Telix sous PC-DOS ou tip sous FreeBSD) pour définir ces paramètres. Connectez-vous au modem à la vitesse de communication initiale que getty utilise et introduisez en mémoire RAM non volatile des valeurs telles que: Le signal CD soit activé quand la ligne est active, Le signal DTR soit activé en cours de fonctionnement; quand le signal DTR tombe, la ligne raccroche et le modem est réinitialisé, Le signal CTS soit activé en fin de transmission, Le contrôle de flux XON/XOFF soit désactivé, Le signal RTS soit activé en fin de réception, Le modem soit en mode silencieux (pas de code retour), Il n'y ait pas d'écho des commandes. Lisez s'il vous plaît la documentation de votre modem pour savoir quelles commandes et/ou quels positionnements des cavaliers utiliser. Par exemple, pour passer ces paramètres à un modem externe USRobotics Sportster 14.400, il faudrait lui passer les commandes suivantes: ATZ AT&C1&D2&H1&I0&R2&W Vous pouvez aussi en profiter pour définir d'autres options de configuration du modem, par exemple, s'il doit utiliser la norme V.42bis et/ou la compression MNP5. Il y a aussi des cavaliers à positionner sur le modem externe USR Sportster 14.400; pour d'autres modems, la configuration suivante peut peut-être servir d'exemple: Cavalier 1: HAUT - DTR normal, Cavalier 2: Pas d'importance (Codes retour explicites/numériques), Cavalier 3: HAUT - Pas de code retour, Cavalier 4: BAS - Pas d'écho, commandes hors-ligne, Cavalier 5: HAUT - Réponse automatique, Cavalier 6: HAUT - Détection de porteuse normale, Cavalier 7: HAUT - Charger les valeurs par défaut depuis la NVRAM (mémoire non volatile), Cavalier 8: Pas d'importance (Mode intelligent/passif). Il vaut mieux désactiver les codes retours pour les connexions entrantes pour éviter les problèmes qui peuvent se produire si getty envoie une invite login: alors que le modem est en mode commande et renvoie soit l'écho de la commande soit un code retour. J'ai entendu dire que cela peut engendrer une dialogue absurde et interminable entre getty et le modem. Configuration à vitesse fixée Pour une configuration à vitesse fixée, vous devrez configurer le modem pour qu'il communique toujours à la même vitesse avec l'ordinateur, quelle que soit la vitesse de la ligne. Sur un modem externe USR Sportster 14.400, les commandes suivantes figeront la vitesse de communication entre le modem et l'ordinateur à la vitesse utilisée pour envoyer ces commandes: ATZ AT&B1&W Configuration avec adaptation de la vitesse Dans une configuration où la vitesse peut varier, vous devrez configurer votre modem pour qu'il ajuste sa vitesse de communication sur le port série à la vitesse de l'appel entrant. Sur un modem externe USR Sportster 14.400, les commandes suivantes figeront la vitesse de transmission avec corrections d'erreur à la vitesse employée pour passer ces mêmes commandes, mais autoriseront une vitesse variable pour les connexions sans correction d'erreur: ATZ AT&B2&W Vérifier la configuration des modems La plupart des modems à haut débit disposent de commandes pour afficher leurs paramètres opérationnels courants sous une forme plus ou moins lisible. Sur les modems externes USR Sportster 14.400, la commande ATI5 affiche les valeurs stockées dans la RAM non volatile. Pour voir les valeurs réellement utilisées (compte tenu de la position des cavaliers), utilisez les commandes ATZ suivie de ATI4. Si vous avez une autre marque de modem, consultez le manuel de votre modem pour savoir comment vérifier les paramètres de configuration de votre modem. En cas de problème Voici différentes étapes à suivre pour vérifier le fonctionnement des modems sur votre système. Tester le système FreeBSD Connectez le modem à votre système FreeBSD, redémarrez le système, et, si votre modem a des voyants d'état lumineux, regardez si le voyant DTR s'allume lorsque l'invite login: s'affiche à la console système - si c'est la cas, cela veut normalement dire que FreeBSD a lancé un processus getty sur le port de communication approprié et attend que le modem reçoive un appel. Si le voyant DTR ne s'allume pas, ouvrez une session à la console système et passez la commande ps ax pour voir si FreeBSD essaie bien de lancer un processus getty sur le bon port. Parmi les processus affichés, vous devriez voir une ligne comme celle-ci: 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 Si vous voyez autre chose, par exemple: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 et que le modem n'a pas encore reçu d'appel, cela veut dire que getty a déjà ouvert le port de communication. Cela peut être dû à un problème de câblage ou à un modem mal configuré, parce que getty ne devrait pas pouvoir ouvrir le port de communication tant que le signal CD (détection de porteuse) n'a pas été activé par le modem. S'il n'y a pas de processus getty prêt à ouvrir le port ttyd? voulu, contrôlez vos entrées dans /etc/ttys pour voir s'il n'y a pas d'erreur. Consultez aussi le fichier de trace /var/log/messages pour voir s'il y a des messages d'init ou de getty indiquant un problème. S'il y a des messages, revérifiez les fichiers de configuration /etc/ttys et /etc/gettytab, et les fichiers spéciaux de périphériques /dev/ttyd? ad hoc, pour voir s'il y a des erreurs, s'il manque des entrées ou des fichiers spéciaux. Essayer de se connecter Essayez d'ouvrir une connexion par téléphone sur le système; Veillez à utiliser 8 bits, pas de contrôle de parité et 1 bit stop sur le système distant. Si vous n'obtenez pas tout de suite l'invite, ou obtenez n'importe quoi, essayez d'appuyer plusieurs fois sur <Entrée>, environ une fois par seconde. Si vous n'obtenez toujours pas l'invite login:, essayez d'envoyer un Attn (BREAK). Si vous utilisez un modem à haut débit, réessayez de vous connecter après avoir verrouillé la vitesse de l'interface du modem, (via AT&B1 sur un USR Sportster, par exemple). Si cela ne marche toujours pas, vérifiez encore le fichier /etc/gettytab et contrôlez que: Le nom de la fonctionnalité initiale de /etc/ttys pour cette liaison correspond bien à celui d'une fonctionnalité définie dans /etc/gettytab, Il y a une fonctionnalité gettytab de nom différent pour chaque entrée nx=, Il y a une fonctionnalité gettytab de nom différent pour chaque entrée tc=, Si vous appelez mais que le modem sur le système FreeBSD ne répond pas, assurez-vous que le modem est configuré pour répondre au téléphone lorsque le signal DTR est actif. Si le modem semble correctement configuré, vérifiez que le signal DTR est actif en regardant les voyants lumineux du modem (s'il en a). Si vous avez tout passé en revue plusieurs fois et que cela ne marche toujours pas, faites une pause et reprenez plus tard. Si vous en êtes toujours au même point, vous pouvez peut-être envoyer un courrier électronique à la &a.questions; décrivant votre modem et votre problème, et les bons samaritains de la liste essaieront de vous aider. Remerciements Merci aux personnes suivantes pour leurs conseils et leurs commentaires: - &a.kelly; + Sean Kelly kelly@ad1440.net pour nombre d'excellentes suggestions. Service d'appel sortant Informations reprises de la FAQ. Cette section fournit des indications pour connecter votre machine à une autre machine par modem. Cela peut servir à ouvrir une session sur une machine distante. C'est aussi utile pour vous connecter à un “BBS”. Ce type de connexion peut être très utile pour récupérer un fichier sur l'Internet si vous avez des problèmes avec PPP. Si vous avez besoin d'utiliser ftp et que PPP ne fonctionne pas, vous pouvez le faire en lançant ftp sur la session terminal. Utilisez ensuite zmodem pour recevoir le fichier sur votre machine. Pourquoi ne puis-je pas utiliser <command>tip</command> ou <command>cu</command>? Sur votre système, les programmes tip et cu ne sont probablement exécutables que par l'utilisateur uucp et le groupe dialer. Vous pouvez vous servir du groupe dialer pour contrôler qui a accès à vos modems et à vos systèmes distants. Ajoutez-vous donc au groupe dialer. Vous pouvez aussi autoriser tout le monde à utiliser tip et cu sur votre système en tapant: &prompt.root; chmod 4511 /usr/bin/tip Il est inutile de changer les droits sur la commande cu, car cu n'est qu'un lien physique sur tip. Mon modem compatible Hayes n'est pas supporté, que puis-je faire? En fait, les pages de manuel de tip ne sont pas à jour. Le support générique Hayes y est déjà incorporé. Mettez simplement at=hayes dans votre fichier /etc/remote. Le pilote Hayes n'est pas assez intelligent pour reconnaître les possibilités étendues des nouveaux messages des modems - BUSY, NO DIALTONE, ou CONNECT 115200 ne feront que lui poser des problèmes. Vous devez désactiver ces messages quand vous utilisez tip (avec ATX0&W). Par ailleurs, le délai d'appel de tip est de 60 secondes. Il devra être inférieur sur votre modem, sinon tip pensera qu'il y a un problème de communication. Essayez ATS7=45&W. Tel que livré, tip ne supporte pas encore cela complètement. Pour y remédier, il faut éditer le fichier tipconf.h du répertoire /usr/src/usr.bin/tip/tip. Il vous faut bien évidemment le source pour cela. Changez la ligne #define HAYES 0 en #define HAYES 1. Puis make et make install. Tout fonctionnera ensuite sans problème. Comment dois-je entrer toutes ces commandes AT? Mettez ce que l'on appelle une entrée “directe” dans le fichier /etc/remote. Par exemple, si votre modem est sur le premier port série. /dev/cuaa0, mettez la ligne suivante: cuaa0:dv=/dev/cuaa0:br#19200:pa=none Utilisez la vitesse en bps la plus rapide que votre modem accepte avec la fonctionnalité br. Tapez alors tip cuaa0 et vous serez connecté à votre modem. S'il n'y a pas de fichier spécial /dev/cuaa0 sur votre système, faites la chose suivante: &prompt.root; cd /dev &prompt.root; MAKEDEV cuaa0 Ou utilisez cu en tant que super-utilisateur avec la commande: &prompt.root; cu -lligne -svitesse ligne est le port série (e.g. /dev/cuaa0) et vitesse est la vitesse (e.g. 57600). Quand vous avez fini d'entrer vos commandes AT, tapez ~. pour quitter le programme. Le signe <literal>@</literal> ne marche pas avec la fonctionnalité pn! Le signe @ comme numéro de téléphone dit à tip de lire le numéro de téléphone dans /etc/phones. Mais @ est aussi un caractère spécial dans les fichiers qui définissent des fonctionnalités, comme /etc/remote. Faites-le précéder d'une barre oblique inverse: pn=\@ Comment puis-je appeler un numéro de téléphone depuis la ligne de commande? Mettez ce que l'on appelle un entrée “générique” dans votre fichier /etc/remote. Par exemple: tip115200|Appeler un numéro de téléphone à 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Appeler un numéro de téléphone à 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: Vous pouvez alors faire la chose suivante: &prompt.root; tip -115200 5551234 Si vous préférez cu à tip, mettez une entrée générique pour cu: cu115200|Utiliser cu pour appeler un numéro à 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: et tapez: &prompt.root; cu 5551234 -s 115200 Dois-je préciser la vitesse en bauds à chaque fois? Mettez un entrée pour tip1200 ou cu1200, mais donnez-y la vitesse en bps voulue avec la fonctionnalité br. tip pense que 1200 bps est une valeur par défaut convenable et cherche donc une entrée tip1200. Vous n'êtes cependant pas obligé d'y mettre la vitesse de 1200 bps. Je me connecte à plusieurs machines par l'intermédiaire d'un concentrateur. Au lieu d'attendre d'être connecté et de taper CONNECT <hôte> à chaque fois, utilisez la fonctionnalité cm de tip. Par exemple, ces entrées dans /etc/remote: pain|pain.deep13.com|la machine de Forrester:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|la machine de Frank:\ :cm=CONNECT muffin\n:tc=deep13: deep13:le concentrateur de l'Institut Gizmonics:\ :dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234: vous permettent d'utiliser tip pain ou tip muffin pour vous connecter aux machines pain ou muffin; et tip deep13 pour accéder à l'autre concentrateur. tip peut-il essayer d'appeler plusieurs numéros pour se connecter à un même site? C'est un problème fréquent dans les universités qui ont une batterie de modems et des milliers d'étudiants qui essayent de s'en servir... Définissez une entrée pour votre université dans /etc/remote et employez @ pour la fonctionnalité pn: super-universite:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: Mettez ensuite les numéros de téléphone de l'université dans /etc/phones: super-universite 5551111 super-universite 5551112 super-universite 5551113 super-universite 5551114 tip essayera d'appeler chacun de ces numéros dans l'ordre, puis abandonnera la tentative. Si vous voulez continuer à essayer de vous connecter, exécutez tip dans une boucle “tant que”. pourquoi dois-je taper CTRL+P deux fois pour envoyer un seul CTRL+P? CTRL+P est le caractère d'échappement - “force” par défaut, pour dire à tip que le caractère suivant est à comprendre tel quel. Vous pouvez changer de caractère d'échappement avec la commande ~s, qui signifie “définir une variable.” Tapez ~sforce=caractère suivie d'un saut de ligne. caractère peut être n'importe quel caractère. Si vous n'indiquez pas de caractère, alors le caractère d'échappement est le caractère “nul”, qui s'obtient en tapant CTRL+2 ou CTRL+barre d'espacement. Une bonne valeur à donner à caractère est SHIFT+CTRL+6, que je n'ai jamais vue utilisée ailleurs que sur certains concentrateurs. vous pouvez aussi donner la valeur que vous voulez au caractère d'échappement en mettant la ligne suivante dans votre fichier $HOME/.tiprc: force=<caractère> Tout ce que je tape s'affiche tout à coup en MAJUSCULES? Vous avez appuyé sur CTRL+A, c'est le caractère “majuscules” de tip, à l'usage particulier de ceux dont la touche “Majuscules” ne fonctionne pas. Utilisez ~s comme précédemment et donnez une valeur raisonnable à la variable raisechar. Vous pouvez d'ailleurs lui donner la même valeur qu'au caractère d'échappement, si vous n'avez pas l'intention de les utiliser l'un et l'autre. Voici une exemple de fichier .tiprc idéal pour les utilisateurs d'Emacs qui ont souvent besoin de CTRL+2 et CTRL+A: force=^^ raisechar=^^ ^^ équivaut à SHIFT+CTRL+6. Comment puis-je transférer des fichiers avec <command>tip</command>? Si vous dialoguez avec un autre système Unix, vous pouvez envoyer et recevoir des fichiers avec ~p (“put”) et ~t (“take”). Ces commandes lancent cat et echo sur le système distant pour qu'il reçoive et envoie des fichiers. La syntaxe est: ~p fichier_local fichier_distant ~t fichier_distant fichier_local Il n'y a aucun contrôle, vous devriez probablement utiliser un autre protocole, comme zmodem. Comment puis-je utiliser <command>zmodem</command> avec <command>tip</command>? Pour récupérer des fichiers, lancez le programmes de transfert sur la machine distante. Puis tapez ~C rz pour commencer à les recevoir. Pour transmettre des fichiers, lancer le programme de réception sur la machine distante. Puis, tapez ~C sz fichiers pour les lui envoyer. diff --git a/fr_FR.ISO8859-1/books/handbook/staff/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/staff/chapter.sgml index 1a68a2c364..004cbebd61 100644 --- a/fr_FR.ISO8859-1/books/handbook/staff/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/staff/chapter.sgml @@ -1,859 +1,790 @@ L'équipe du projet FreeBSD Le projet FreeBSD est géré et mis en oeuvre par les groupes de personnes suivantes : L'équipe de base FreeBSD - <foreignphrase>Core Team</foreignphrase> L'équipe de base de FreeBSD constitue le “Comité de Direction” du projet, responsable de définir les objectifs et l'orientation du projet ainsi que de la gestion de sections spécifiques de l'ensemble du projet FreeBSD. (par ordre alphabétique de patronyme) : &a.asami; &a.jmb; &a.ache; &a.bde; &a.gibbs; &a.dg; &a.jkh; &a.phk; &a.rich; &a.gpalmer; &a.jdp; &a.sos; &a.peter; &a.wollman; &a.joerg; Les développeurs FreeBSD Ce sont ceux qui ont les droits d'écriture et effectuent le travail d'ingénierie sur l'arborescence des sources. Tous les membres de l'équipe de base sont aussi développeurs. &a.ugen; &a.mbarkah; &a.stb; &a.pb; &a.abial; &a.jb; &a.torstenb; &a.dburr; &a.charnier; &a.luoqi; &a.ejc; &a.kjc; - - &a.gclarkii; - - &a.archie &a.cracauer; &a.adam; &a.dillon; &a.dufault; &a.uhclem; &a.tegge; &a.eivind; &a.julian; &a.rse; &a.se; &a.sef; &a.fenner; &a.jfieber; &a.jfitz; &a.scrappy; &a.lars; &a.dirk; &a.shige; &a.billf; &a.gallatin; &a.tg; &a.brandon; &a.graichen; &a.jgreco; &a.rgrimes; &a.jmg; &a.hanai; &a.thepish; &a.jhay; &a.helbig; &a.ghelmer; &a.erich; &a.nhibma; &a.flathill; &a.foxfair; &a.hosokawa; &a.hsu; &a.mph; &a.itojun; &a.mjacob; &a.gj; - - &a.nsj; - - &a.ljo; &a.kato; &a.andreas; &a.motoyuki; &a.jkoshy; &a.kuriyama; &a.grog; &a.jlemon; &a.truckman; &a.imp; &a.smace; &a.mckay; &a.mckusick; &a.ken; &a.hm; &a.tedm; &a.amurai; &a.markm; &a.max; &a.alex; &a.newton; &a.rnordier; &a.davidn; &a.obrien; &a.danny; &a.ljo; &a.fsmp; &a.smpatel; &a.wpaul; &a.jmacd; &a.wes; &a.steve; &a.mpp; &a.dfr; - - &a.jraynard; - - &a.darrenr; &a.csgr; &a.martin; &a.paul; &a.roberto; &a.chuckr; &a.guido; &a.dima; &a.sada; &a.nsayer; &a.wosch; - - &a.ats; - - &a.jseger; &a.simokawa; &a.vanilla; &a.msmith; &a.des; &a.brian; &a.mks; &a.stark; &a.karl; &a.taoka; &a.dt; &a.cwt; &a.pst; &a.hoek; &a.nectar; &a.swallace; &a.dwhite; &a.nate; &a.yokota; &a.jmz; Le projet de documentation de FreeBSD Le Projet de documentation de FreeBSD est responsable d'une série de services, chacun étant géré par une personne et ses adjoints (le cas échéant) : Gestion du projet de documentation &a.nik; Webmestre &a.wosch; Rédacteur en chef des Manuel de référence & Foire Aux Questions &a.faq; - - Rédacteur en chef pour les nouvelles - - - &a.nsj; - - Adjoint : &a.john; - - - Rédacteur en chef de la lettre d'information succinte de FreeBSD Chris Coleman chrisc@vmunix.com - - Rédacteur en chef de la galerie - - - &a.nsj; - - Adjoint : &a.cawimm; - - - - Rédacteur en chef commercial &a.mbarkah; Rédacteur en chef pour les modifications au site Web &a.mbarkah; - - Coordination du style (Polices) & graphisme - - - &a.opsys; - - - - - Ingénieur base de données - - - &a.mayo; - - - - - Ingénieur CGI - - - &a.stb; - - - - - Finalisation - - - &a.nsj; - - - Conversion de LinuxDoc à DocBook &a.nik; Qui est responsable de quoi Architecte principal &a.dg; Gestionnaire du projet de documentation &a.nik; Internationalisation &a.ache; Réseau &a.wollman; Postmaster &a.jmb; Coordination des versions &a.jkh; Relations publiques & avec les entreprises˛ &a.jkh; Officier de sécurité &a.imp; Gestionnaires des archives CVS Principal : &a.peter; Assistant : &a.jdp; International (Crypto) : &a.markm; Gestionnaire du catalogue des logiciels portés &a.asami; Liaison avec XFree86 Project, Inc. &a.rich; Support des forums de discussion &a.joerg; Administrateur GNATS &a.steve; Webmestre &a.wosch;