diff --git a/documentation/content/fr/articles/building-products/_index.adoc b/documentation/content/fr/articles/building-products/_index.adoc index 97c3cf21e5..28622f82b5 100644 --- a/documentation/content/fr/articles/building-products/_index.adoc +++ b/documentation/content/fr/articles/building-products/_index.adoc @@ -1,355 +1,358 @@ --- title: Construire des produits avec FreeBSD authors: - author: Joseph Koshy email: jkoshy@FreeBSD.org organizations: - organization: Le Projet FreeBSD releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "general"] --- = Construire des produits avec FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple + +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] include::shared/fr/mailing-lists.adoc[] include::shared/releases.adoc[] - -ifeval::["{backend}" == "html5"] :imagesdir: ../../../images/articles/building-products/ endif::[] ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/mailing-lists.adoc[] +include::../../../../shared/fr/urls.adoc[] +include::../../../../shared/releases.adoc[] :imagesdir: ../../../../static/images/articles/building-products/ endif::[] ifeval::["{backend}" == "epub3"] :imagesdir: ../../../../static/images/articles/building-products/ endif::[] [.abstract-title] Résumé Le projet FreeBSD est un projet international, collaboratif et basé sur le volontariat, qui développe un système d'exploitation portable et de grande qualité. Le projet FreeBSD distribue le code source de ses produits avec une licence libérale dans l'intention d'encourager l'utilisation de son code. Collaborer avec le project FreeBSD peut aider les organisations à réduire leur délai de mise sur le marché, leurs coûts de développement, et améliorer la qualité de leurs produits. Cet article se penche sur les questions relatives à l'utilisation du code de FreeBSD dans les appareils informatiques et les logiciels. Il met en évidence les caractéristiques de FreeBSD qui en font un excellent support pour le développement de produits. Cet article conclut en suggérant quelques "bonnes pratiques" pour les organisations qui collaborent avec le projet FreeBSD. Version française de Frederic Culot ``. ''' toc::[] [[introduction]] == Introduction FreeBSD est reconnu aujourd'hui comme un système d'exploitation hautes performances pour serveurs. Il est déployé sur des millions de serveurs web et de machines connectées à internet de part le monde. Le code de FreeBSD fait aussi partie intégrante de beaucoup de produits depuis des appareils comme les routeurs réseau, pare-feux, et dispositifs de stockage, jusqu'aux ordinateurs personnels. Des parties de FreeBSD ont également été utilisées dans des produits commerciaux (voir <>). Dans cet article nous nous intéressons au link:https://www.FreeBSD.org/[projet FreeBSD] en tant que ressource pour la conception logicielle-une collection de briques de base et de processus que vous pouvez utiliser pour construire d'autres produits. Bien que les sources de FreeBSD soient distribuées librement au public, les organisations ont besoin de _collaborer_ avec le projet pour pouvoir pleinement apprécier les bénéfices de ce travail. Dans les sections suivantes de cet article nous présentons les moyens efficaces qui existent afin de collaborer avec le projet, ainsi que les pièges à éviter. *Avertissement au lecteur.* L'auteur pense que les caractéristiques du Projet FreeBSD telles que décrites dans cet article sont en grande partie vraies au moment où cet article a été conçu et rédigé (2005). Cependant, le lecteur doit garder en tête que les pratiques et processus utilisés par les communautés open-source peuvent changer au cours du temps, et que les informations contenues dans cet article devraient donc être considérées comme étant indicatives plutôt que prescriptives. === Public visé Ce document pourrait présenter un intérêt pour les groupes de personnes suivants: * Les preneurs de décisions dans les entreprises qui recherchent à améliorer la qualité de leurs produits, à réduire leur délai de mise sur le marché, et réduire leurs coûts de développement sur le long terme. * Les consultants en technologie à la recherche de bonnes pratiques pour tirer profit de l'"open-source". * Les spécialistes de l'industrie intéressés par la compréhension de la dynamique des projets open-source. * Les développeurs logiciels cherchant à utiliser FreeBSD et désirant contribuer au projet en retour. === Objectifs de l'article La lecture de cet article devrait vous apporter: * Une compréhension des buts du Projet FreeBSD ainsi que de la structure de son organisation. * Un aperçu des technologies disponibles dans le projet. * Une compréhension de son modèle de développement et de ses processus d'ingénierie. * Une compréhension des différences entre les processus de développement conventionnels que l'on retrouve chez les éditeurs de logiciels et ceux utilisés par le projet FreeBSD. * Une sensibilisation aux canaux de communication utilisés par le projet et le niveau de transparence auquel vous pouvez vous attendre. * Une connaissance des moyens optimaux qui existent pour travailler avec le projet-comment réduire au maximum les coûts de développement, améliorer le délai de mise sur le marché, gérer les failles de sécurité, et préserver la compatibilité future de votre produit avec les évolutions du projet FreeBSD. === Structure de l'article La suite de l'article est structurée de la façon suivante: * <> introduit le projet FreeBSD, présente sa structure organisationnelle, ses technologies clés et ses processus de développement. * <> décrit les moyens de collaborer avec le projet FreeBSD. Les pièges les plus courants rencontrés par les sociétés travaillant avec les projets basés sur le volontariat comme FreeBSD sont également présentés. * <> conclut. [[freebsd-intro]] == FreeBSD en tant que brique constitutive FreeBSD représente une excellente base sur laquelle construire des produits: * Le source code de FreeBSD est distribué avec une licence BSD libérale qui facilite grandement son utilisation dans les produits commerciaux <>. * Le projet FreeBSD a d'excellentes pratiques de développement qui peuvent être mises à profit. * Le projet offre une transparence exceptionnelle eu égard à son fonctionnement, permettant aux companies utilisant son code de planifier efficacement l'avenir. * La culture du projet FreeBSD, héritée du Groupe de Recherche sur la Science Informatique de l'Université de Berkeley en Californie <>, encourage le travail de grande qualité. Certaines fonctionnalités de FreeBSD sont considérés comme des références. <> examine avec plus de détails les raisons commerciales qui justifient l'utilisation de l'open-source. Les bénéfices que les sociétés peuvent tirer de l'utilisation de composants FreeBSD dans leurs produits comprennent un délai réduit de mise sur le marché, ainsi qu'une réduction des coûts et des risques liés au développement. === Construire avec FreeBSD Voici quelques utilisations que des sociétés ont faites de FreeBSD: * Comme source de code testé pour des bibliothèques ou utilitaires. + En étant "en aval" du projet, les organisations tirent profit des nouvelles fonctionnalités, corrections de bogues et tests dont le code en amont bénéficie. * En tant que système d'exploitation embarqué (par exemple, pour un routeur OEM ou un appareil servant de pare-feu). Dans ce modèle, les organisations utilisent un noyau FreeBSD adapté ainsi qu'un ensemble de logiciels appropriés conjointement avec une couche propriétaire de gestion de leur appareil. Les OEMs bénéficient des nouveaux supports matériels ajoutés par le projet FreeBSD en amont, ainsi que des tests effectués sur le système de base. + FreeBSD est diffusé avec un environnement de développement auto-hébergé qui permet de créer facilement de telles configurations. * En tant qu'environnement compatible UNIX(R) pour les fonctions de gestion des environnements de stockage et les appareils réseau, fonctionnant sur un "serveur lame" séparé. + FreeBSD fournit les outils nécessaires pour créer des systèmes d'exploitation dédiés et des images d'applications. Son implémentation basée sur une API BSD UNIX(R) est mature et testée. FreeBSD peut aussi fournir un environnement de développement croisé stable pour les autres composants de l'appareil final. * En tant que moyen d'obtenir une large base de tests et du support de la part d'une équipe de développeurs internationale pour tout ce qui a trait à la "propriété intellectuelle" non critique. + Dans ce modèle, les organisations apportent un ensemble d'infrastructures utiles au projet FreeBSD (voir par exemple man:netgraph[3]). L'importante exposition que le code acquiert aide pour l'identification rapide de problèmes de performance et de bogues. L'implication d'excellents développeurs apporte aussi des ajouts utiles à la base existante, ce dont l'organisation contributrice bénéficie également. * En tant qu'environnement de développement autorisant le développement croisé pour des systèmes embarqués tels que http://www.rtems.com/[RTEMS] et http://ecos.sourceware.org/[eCOS]. + Il existe une pléthore d'environnements de développement très complets dans le catalogue des {numports} applications portées et empaquetées pour FreeBSD. * Comme moyen de fournir une API Unix dans un système propriétaire par ailleurs, augmentant ainsi son attractivité pour les développeurs d'applications. + Dans ce cas des parties du noyau FreeBSD et des applications sont "portées" pour tourner conjointement avec d'autres tâches du système d'exploitation propriétaire. La disponibilité de l'implémentation d'une API Unix(TM) stable et bien testée peut réduire l'effort nécessaire pour porter des applications populaires sur le système propriétaire. Comme FreeBSD est fournit avec une documentation de grande qualité concernant ses mécanismes internes et assure une gestion efficace des vulnérabilités et des cycles de développement, les coûts pour se maintenir à jour sont bas. [[freebsd-technologies]] === Technologies Le projet FreeBSD supporte un grand nombre de technologies dont une sélection est présentée ci-dessous: * Un système complet qui peut faire de l'auto-hébergement croisé pour les architectures suivantes: alpha (jusqu'à FreeBSD version 6.X), amd64, ia64, i386, sparc64, powerpc (voir man:build[7]). * Le support pour les technologies, protocoles et standards suivants: ATA, ATAPI, ATM, Bluetooth(TM), CAM, CardBus(TM), DHCP, `DNS`, EISA(TM), Ethernet(TM), FDDI, Fibre Channel, GPIB, IEEE 1394, IPv4, IPv6, IPSEC, IPX(TM), ISDN, MAC, NIS, NFS, OpenSSH, OPIE, PAM, PCI(TM), PCMCIA, POSIX(TM), PnP, `RAID`, RPC, SATA, SCSI, SMB, `TCP`, USB, VESA, VLAN, VLB, WebNFS(TM). * Un noyau modulaire permettant le traitement symétrique multiprocesseurs, avec chargement possible de modules noyau et un système de configuration facile à utiliser. * Le support pour l'émulation de Linux(TM) et des binaires SVR4 à vitesse quasi-native et le support pour les pilotes réseau Windows(TM) (NDIS). * Des librairies pour de nombreuses tâches liées à la programmation: archivage, support FTP et HTTP, support des processus légers en plus d'un environnement de programmation POSIX(TM). * Des dispositifs de sécurité avancés : Mandatory Access Control (man:mac[9]), jails (man:jail[2]), ACLs, ainsi que le support d'un dispositif cryptographique au niveau noyau. * Des caractéristiques réseau avancées : dispositifs pares-feu, gestion de Qos, communications TCP/IP hautes performances avec support de nombreuses caractéristiques avancées. + Le système Netgraph (man:netgraph[4]) présent dans le noyau FreeBSD permet à des modules noyau de gestion des communications réseau d'être interconnectés de manière flexible. * Le support pour des technologies de stockage avancées: fibre, SCSI, RAID logiciel et matériel, ATA et SATA. + FreeBSD est capable de gérer plusieurs systèmes de fichiers différents, et son support natif du système de fichiers UFS2 autorise les soft updates, les sauvegardes instantanées, ainsi que les systèmes de fichiers très volumineux (16TB par système) <>. + Le système GEOM (man:geom[4]) présent dans le noyau FreeBSD permet de composer de manière flexible des modules noyau dédiés à la gestion du stockage. * L'accès à plus de {numports} applications portées, qu'elles soient commerciales ou open-source, gérées grâce à la collection des portages de FreeBSD. === Structure organisationnelle La structure organisationnelle de FreeBSD n'est pas hiérarchique. Il existe essentiellement deux types de contributeurs à FreeBSD, les utilisateurs de FreeBSD, et les développeurs qui ont les droits en écriture (connus sous le terme _committers_ dans notre jargon) et peuvent modifier les sources. Il existe plusieurs milliers de contributeurs dans le premier groupe, la vaste majorité des contributions à FreeBSD proviennent de personnes faisant partie de ce groupe. Les droits de commit (droits d'accès en écriture) sont accordés aux personnes qui contribuent au projet de manière récurrente. Ces droits viennent avec des responsabilités supplémentaires, et les nouveaux committers se voient attribuer des mentors pour les aider à apprendre les bases. .L'organisation FreeBSD image::freebsd-organization.png[] La résolution des conflits est assurée par une équipe ("Core Team") de neuf membres qui est élue par le groupe des committers. Les committers ne sont pas employés par FreeBSD. Il est exigé de la part des committers qu'ils prennent la responsabilité des changements qu'ils introduisent dans le code. Le link:{committers-guide}[Guide du Committer FreeBSD] <> documente les règles et responsabilités des committers. Le modèle de projet de FreeBSD est examiné en détails dans <>. === Les processus de développement des versions de FreeBSD Les processus de développement des versions de FreeBSD jouent un rôle majeur en assurant que les versions qui sont délivrées sont de grande qualité. À n'importe quel moment que l'on considère, les volontaires de FreeBSD assurent le développement de plusieurs branches de code (<>): * Les nouvelles fonctionnalités et le code expérimental sont incorporés sur la branche de développement, aussi connue sous le nom de branche _-CURRENT_. * Les branches _-STABLE_ représentent les lignes de code qui sont reprises de la HEAD à des intervalles de temps réguliers. Seul le code testé est autorisé sur une branche -STABLE. Les nouvelles fonctionnalités sont autorisées une fois qu'elles ont été testées et stabilisées sur la branche -CURRENT. * Les branches _-RELEASE_ sont maintenues par l'équipe sécurité de FreeBSD. Seuls les correctifs de bogues pour les problèmes critiques sont autorisés sur les branches -RELEASE. [[fig-freebsd-branches]] .Les branches FreeBSD image::freebsd-branches.png[] Les lignes de code sont maintenues aussi longtemps qu'il existe des utilisateurs et des développeurs qui s'y intéressent. Les architectures machine sont groupées en "niveaux". Les architectures de premier niveau (_Tier 1_) sont entièrement supportées par l'équipe en charge des versions et l'équipe sécurité. Les architectures de second niveau (_Tier 2_) sont supportées dans la mesure du possible, et les architectures expérimentales représentent le _Tier 3_. La liste des link:{committers-guide}#archs[architectures supportées] est incluse dans la documentation FreeBSD. L'équipe en charge des versions publie une link:https://www.FreeBSD.org/releng/[feuille de route] pour les futures versions de FreeBSD sur la page web du projet. Les dates qui sont mentionnées sur la feuille de route ne sont pas des dates butoirs: les versions de FreeBSD sont délivrées lorsque son code et sa documentation sont prêts. Les processus de développement des versions de FreeBSD sont décrits dans <>. [[freebsd-collaboration]] == Collaborer avec FreeBSD Les projets Open-source tels que FreeBSD offrent un code de très grande qualité <>. Des études ont examiné les effets de la disponibilité du code source sur le développement logiciel <>. Alors que l'accès à du code source de qualité peut réduire les coûts initiaux de développement, les coûts liés à la gestion des changements deviennent prédominants par la suite. Comme les environnements informatiques changent au fil du temps et que de nouvelles failles de sécurité sont découvertes, votre produit lui aussi a besoin de changements et d'adaptations. Utiliser du code open-source se conçoit plus comme un processus _continu dans le temps_ que comme quelque chose de ponctuel. Les meilleurs projets avec lesquels collaborer sont ceux qui sont __actifs__, c'est-à-dire ceux qui ont une communauté active, des objectifs clairs et des méthodes de travail transparentes. * FreeBSD possède une communauté active de développeurs gravitant autour du projet. Au moment de l'écriture de cet article, il existe plusieurs milliers de contributeurs vivant sur tous les continents peuplés de la planète et plus de 300 personnes possédant les droits d'accès aux dépôts des sources du projet. * Les objectifs du projet FreeBSD sont <>: ** De développer un système d'exploitation de grande qualité pour les architectures informatiques populaires, et ** Mettre notre travail à la disposition de tous sous couvert d'une licence libérale. * FreeBSD bénéficie d'une culture ouverte et transparente. Quasiment toutes les discussions au sein du projet se font par courrier électronique, sur les https://lists.freebsd.org/mailman/listinfo[listes publiques] qui sont aussi archivées pour la postérité. Les règles et pratiques du projet sont link:https://www.FreeBSD.org/internal/policies/[documentées] et maintenues en utilisant un système de gestion de versions. Participer au projet est ouvert à tous. [[freebsd-org]] === Comprendre la culture FreeBSD Afin de pouvoir travailler de manière efficace avec le projet FreeBSD, vous devez comprendre la culture qui règne au sein du projet. Les projets menés par des volontaires fonctionnent avec des règles différentes de celles utilisées par des organisations commerciales. Une des erreurs récurrentes faite par les entreprises lorsqu'elles s'aventurent dans le monde de l'open-source est de sous-estimer ces différences. *Motivation.* La plupart des contributions à FreeBSD sont faites de manière volontaire et aucune rétribution financière n'entre en jeu. Les facteurs qui motivent les contributeurs sont complexes, et parmi ceux-ci on peut citer l'altruisme ou un intérêt pour résoudre les genres de problèmes que FreeBSD tente de résoudre. Dans cette environnement, "l'élégance n'est jamais optionnelle"<>. *La Vision à Long Terme.* Les origines de FreeBSD remontent à presque vingt ans dans le passé avec le travail effectué au Groupe de Recherche en Science Informatique (CSRG) de l'Université de Berkeley en Californie.footnote:[Le dépôt des sources de FreeBSD contient l'historique du projet depuis sa création, et il existe des CDROMs qui contiennent du code plus ancien en provenance du CSRG.]Certains des développeurs originaux du CSRG sont toujours associés au projet. Le projet met l'accent sur les perspectives à long terme <>. Un acronyme fréquemment rencontré au sein du projet est DTRT qui signifie "Do The Right Thing" (Faites les Choses Correctement). *Les Processus de Développement.* Les programmes informatiques sont des outils de communication: à un certain niveau les programmeurs communiquent leurs intentions, en utilisant une notation précise, à un outil (un compilateur) qui traduit ces instructions en code exécutable. À un autre niveau, la même notation est utilisée entre deux programmeurs pour communiquer leurs intentions. Les spécifications formelles et les documents d'architecture sont rarement utilisés dans le projet. Du code clair et bien écrit ainsi que des rapports de changements (<>) eux aussi bien écrits sont utilisés à la place. Le développement de FreeBSD commence par "une ébauche de consensus et en faisant tourner du code"<>. [.programlisting] .... bde 2005-10-29 16:34:50 UTC FreeBSD src repository Modified files: lib/msun/src e_rem_pio2f.c Log: Use double precision to simplify and optimize arg reduction for small and medium size args too: instead of conditionally subtracting a float 17+24, 17+17+24 or 17+17+17+24 bit approximation to pi/2, always subtract a double 33+53 bit one. The float version is now closer to the double version than to old versions of itself - it uses the same 33+53 bit approximation as the simplest cases in the double version, and where the float version had to switch to the slow general case at |x| == 2^7*pi/2, it now switches at |x| == 2^19*pi/2 the same as the double version. This speeds up arg reduction by a factor of 2 for |x| between 3*pi/4 and 2^7*pi/4, and by a factor of 7 for |x| between 2^7*pi/4 and 2^19*pi/4. Revision Changes Path 1.14 +22 -97 src/lib/msun/src/e_rem_pio2f.c .... .Un example de rapport de modification [[fig-change-log]] La communication entre programmeurs est facilitée par l'utilisation d'un standard commun concernant le code man:style[9]. *Les canaux de communication.* Les contributeurs FreeBSD sont répartis dans le monde entier. Le courrier électronique (et dans une moindre mesure, l'IRC) est le moyen de communication prépondérant au sein du projet. === Les meilleures pratiques pour collaborer avec le projet FreeBSD Nous nous intéressons maintenant à quelques bonnes pratiques utiles pour tirer profit au maximum de l'utilisation de FreeBSD pour le développement de produits. Plan à long terme:: Mettre en place des processus qui simplifient le suivi du développement de FreeBSD. Par example: + *Suivre les changements dans le code source de FreeBSD.* Le projet rend la copie de son dépôt CVS aisée grâce à l'utilisation de link:{cvsup-advanced}[CVSup]. Avoir l'historique complet des sources est utile lors du déboguage de problèmes complexes et offre des indications utiles sur les intentions des développeurs. Utilisez un système de contrôle de sources efficace qui vous permette de facilement fusionner les changements entre le code FreeBSD et votre propre code. + La <> montre une partie d'un listing annoté du fichier dont le rapport de changement de la <> fait référence. L'origine de chacune des lignes du code source est clairement affichée. Les listings annotés montrant l'historique de chacun des fichiers faisant partie de FreeBSD sont http://cvsweb.freebsd.org/[disponibles sur Internet]. + [.programlisting] .... #LINE #REV #WHO #DATE #TEXT 62 1.1 (jkh 19-Aug-94): int32_t __ieee754_rem_pio2f(float x, float *y) 63 1.1 (jkh 19-Aug-94): { 64 1.14 (bde 29-Oct-05): double z,w,t,r,fn; 65 1.13 (bde 29-Oct-05): double tx[3]; 66 1.14 (bde 29-Oct-05): int32_t e0,i,nx,n,ix,hx; 67 1.1 (jkh 19-Aug-94): 68 1.1 (jkh 19-Aug-94): GET_FLOAT_WORD(hx,x); 69 1.1 (jkh 19-Aug-94): ix = hx&0x7fffffff; 70 1.1 (jkh 19-Aug-94): if(ix<=0x3f490fd8) /* |x| ~<= pi/4 , no need for reduction */ 71 1.1 (jkh 19-Aug-94): {y[0] = x; y[1] = 0; return 0;} 72 1.14 (bde 29-Oct-05): /* 33+53 bit pi is good enough for special and medium size cases */ 73 1.2 (bde 07-Apr-95): if(ix<0x4016cbe4) { /* |x| < 3pi/4, special case with n=+-1 */ 74 1.14 (bde 29-Oct-05): if(hx>0) { 75 1.15 (bde 06-Nov-05): z = x - pio2; 76 1.15 (bde 06-Nov-05): n = 1; 77 1.15 (bde 06-Nov-05): } else { 78 1.15 (bde 06-Nov-05): z = x + pio2; 79 1.15 (bde 06-Nov-05): n = 3; 80 1.9 (bde 08-Oct-05): } 81 1.15 (bde 06-Nov-05): y[0] = z; 82 1.15 (bde 06-Nov-05): y[1] = z - y[0]; 83 1.15 (bde 06-Nov-05): return n; 84 1.15 (bde 06-Nov-05): } 85 1.15 (bde 06-Nov-05): if(ix<0x407b53d1) { /* |x| < 5*pi/4, special case with n=+-2 */ .... .Un listing annoté généré par `cvs annotate` [[fig-cvs-annotate]] + *Utilisez un observateur.* Nommez un _observateur_ pour surveiller les développements de FreeBSD, pour déceler les changements qui pourraient potentiellement impacter vos produits. + *Remontez les bogues en amont.* Si vous détectez un bogue dans le code FreeBSD que vous utilisez, remplissez un link:https://www.FreeBSD.org/send-pr/[rapport de bogue]. Cette étape permet de faire en sorte que vous n'ayez pas à corriger le même bogue la prochaine fois que vous récupérerez les sources en amont. Tirez profit des efforts portés sur la gestion des versions:: Utilisez du code d'une branche de développement -STABLE de FreeBSD. Ces branches de développement sont officiellement supportées par les équipes en charge des versions et les équipes sécurité de FreeBSD et sont constituées de code testé. Donnez du code pour réduire les coûts:: La majeure partie des coûts associés au développement est liée à la maintenance. En donnant du code non critique au projet, vous bénéficiez du fait que votre code aura une diffusion bien plus importante que celle qu'il aurait eu sans ça. Ceci amène à ce que plus de bogues et de failles de sécurité soient éliminés et que les problèmes de performance soient identifiés et résolus. Recevez un soutien efficace:: Pour les produits avec des dates butoirs rapprochées, il est recommandé d'embaucher ou de s'attacher les services d'un développeur ou d'une firme qui a de l'expérience avec FreeBSD. La {freebsd-jobs} est un canal de communication utile si vous êtes à la recherche de talents dans le domaine. Le projet FreeBSD maintient une link:https://www.FreeBSD.org/commercial/consult_bycat/[liste des consultants et des firmes de consulting] assurant des travaux liés à FreeBSD. Le http://www.bsdcertification.org/[Groupe de Certification FreeBSD] propose des certifications pour la majorité des systèmes d'exploitation dérivés de BSD. + Pour les besoins moins critiques, vous pouvez demander de l'aide sur les http://lists.FreeBSD.org/mailman/listinfo[listes de diffusion du projet]. Un guide utile à suivre si vous souhaitez demander de l'aide est celui de <>. Faites de la publicité sur votre engagement:: Vous n'êtes pas obligé de faire de la publicité sur votre utilisation de FreeBSD, mais le faire permet à la fois de vous aider vous mais aussi le projet. + Faire valoir auprès de la communauté FreeBSD que votre société utilise FreeBSD améliore vos chances de pouvoir attirer des personnes talentueuses. Une longue liste de personnes habilitées à faire du support sur FreeBSD signifie aussi plus d'échanges d'idées entre les développeurs. Ceci permet de construire des fondations plus seines pour votre futur. Soutenez les développeurs de FreeBSD:: Parfois la manière la plus directe pour qu'une fonctionnalité dont on a besoin soit incluse dans FreeBSD est d'aider un développeur qui travaille déjà sur un problème ayant un rapport avec cette fonctionnalité. Ces aides peuvent prendre plusieurs formes, depuis le don de matériel jusqu'à des donations financières. Dans certains pays, les donations au projet FreeBSD peuvent bénéficier d'avantages au niveau des impôts. Le projet a un link:https://www.FreeBSD.org/donations/[interlocuteur dédié] pour assister les donateurs. Le projet maintien également une page web sur laquelle les développeurs link:https://www.FreeBSD.org/donations/wantlist/[recensent leurs besoins]. + Le projet FreeBSD met un point d'honneur à link:{contributors}[remercier] tous les donnateurs sur son site web. [[conclusion]] == Conclusion Les objectifs du projet FreeBSD sont de créer et proposer gratuitement le code source d'un système d'exploitation de grande qualité. En travaillant avec le projet FreeBSD vous pouvez réduire vos coûts de développement et améliorer vos délais de mise sur le marché dans un certain nombre de scénarios de développement de produits. Nous avons passé en revue les caractéristiques du projet FreeBSD qui en font un excellent choix pour faire partie d'une stratégie produit d'une entreprise. Nous avons ensuite présenté la culture du projet et examiné les différents moyens à disposition pour interagir avec ses développeurs. Cet article conclut avec une liste des bonnes pratiques qui peuvent être mises en place par les organisations pour collaborer avec le projet. :sectnums!: [bibliography] == Bibliography [[Carp1996]] [Carp1996] http://www.ietf.org/rfc/rfc1958.txt[The Architectural Principles of the Internet] B. Carpenter. The Internet Architecture Board.The Internet Architecture Board. Copyright(R) 1996. [[Com2004]] [Com2004] http://csdl.computer.org/comp/mags/so/2004/01/s1028.pdf[How is Open-Source Affecting Software Development?] Diomidis Spinellis. Clemens Szyperski.IEEE Computer Copyright(R) Jan/Feb 2004. IEEE Computer Society. [[ComGuide]] [ComGuide] link:{committers-guide}[Committer's Guide] The FreeBSD Project. Copyright(R) 2005. [[Cov2005]] [Cov2005] http://www.coverity.com/news/nf_news_06_27_05_story_9.html[Coverity study on kernel security holes in Linux and FreeBSD]Coverity Inc.. Copyright(R) 2005. [[GoldGab2005]] [GoldGab2005] http://dreamsongs.com/IHE/IHE.html[Innovation Happens Elsewhere: Open Source as Business Strategy] Ron Goldman. Richard Gabriel. Copyright(R) 2005. Morgan-Kaufmann. [[Hub1994]] [Hub1994] link:{contributing}[Contributing to the FreeBSD Project] Jordan Hubbard. Copyright(R) 1994-2005. The FreeBSD Project. [[McKu1999]] [McKu1999] http://www.usenix.org/publications/library/proceedings/usenix99/mckusick.html[Soft Updates: A Technique for Eliminating Most Synchronous Writes in the Fast Filesystem] Kirk McKusick. Gregory Ganger. Copyright(R) 1999. [[McKu1999-1]] [McKu1999-1] http://www.oreilly.com/catalog/opensources/book/kirkmck.html[Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable] Marshall Kirk McKusick. http://www.oreilly.com/catalog/opensources/book/toc.html[Open Sources: Voices from the Open Source Revolution] O'Reilly Inc.. Copyright(R) 1993. [[Mon2005]] [Mon2005] link:{bsdl-gpl}[Why you should use a BSD style license for your Open Source Project] Bruce Montague. The FreeBSD Project. Copyright(R) 2005. [[Nik2005]] [Nik2005] link:{dev-model}[A project model for the FreeBSD Project] Niklas Saers. Copyright(R) 2005. The FreeBSD Project. [[Nor1993]] [Nor1993] http://www.norvig.com/luv-slides.ps[Tutorial on Good Lisp Programming Style] Peter Norvig. Kent Pitman. Copyright(R) 1993. [[Nor2001]] [Nor2001] http://www.norvig.com/21-days.html[Teach Yourself Programming in Ten Years] Peter Norvig. Copyright(R) 2001. [[Ray2004]] [Ray2004] http://www.catb.org/~esr/faqs/smart-questions.html[How to ask questions the smart way] Eric Steven Raymond. Copyright(R) 2004. [[RelEngDoc]] [RelEngDoc] link:{releng}[FreeBSD Release Engineering] Murray Stokely. Copyright(R) 2001. The FreeBSD Project. diff --git a/documentation/content/fr/articles/filtering-bridges/_index.adoc b/documentation/content/fr/articles/filtering-bridges/_index.adoc index 54a3ebe520..dfd3acd4eb 100644 --- a/documentation/content/fr/articles/filtering-bridges/_index.adoc +++ b/documentation/content/fr/articles/filtering-bridges/_index.adoc @@ -1,229 +1,239 @@ --- title: Ponts filtrants authors: - author: Alex Dupre email: ale@FreeBSD.org releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "3com", "intel", "general"] --- = Ponts filtrants :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé Souvent il est utile de diviser un réseau physique (comme un réseau Ethernet) en deux segments séparés sans avoir à créer des sous-réseaux, et utiliser de routeur pour les relier ensemble. Le dispositif qui connecte les deux réseaux de cette manière est appelé un pont. Un système FreeBSD avec deux cartes réseau est suffisant pour jouer le rôle d'un pont. Un pont fonctionne en scannant les adresses au niveau MAC (adresses Ethernet) des cartes connectées à chacune de ses interfaces réseau et puis transfère le trafic entre les deux réseaux si la source et la destination sont situées sur un segment différent. Sous beaucoup de points de vue un pont est similaire à un commutateur (switch) Ethernet avec uniquement deux ports. Version française de Marc Fonvieille ``. ''' toc::[] [[filtering-bridges-why]] == Pourquoi utiliser un pont filtrant? De plus en plus fréquemment, grâce à la baisse des coûts des connexions Internet haut débit (xDSL) et aussi en raison de la réduction des adresses IPv4 disponibles, beaucoup de compagnies sont connectées à l'Internet 24 heures sur 24 et avec peu (parfois même pas une puissance de 2) d'adresses IP. Dans ces situations il est souvent désirable d'avoir un coupe-feu qui filtre le trafic entrant et sortant depuis et vers l'Internet, mais la solution d'un filtrage de paquet basé sur un routeur peut ne pas être applicable, soit en raison de problèmes de sous-réseau, le routeur appartient au fournisseur d'accès (ISP), ou parce qu'il ne supporte pas une telle fonction. Dans ces scénarios l'utilisation d'un pont filtrant est fortement conseillée. Un coupe-feu basé sur un pont peut être configuré et inséré entre le routeur xDSL et votre concentrateur/commutateur Ethernet sans aucun problème d'adresse d'IP. [[filtering-bridges-how]] == Comment l'installer Ajouter les fonctions de pont à un système FreeBSD n'est pas difficile. Depuis la 4.5-RELEASE il est possible de charger de telles fonctionnalités sous forme de module au lieu d'avoir à recompiler le noyau, simplifiant énormément la procédure. Dans les sous-sections suivantes j'expliquerai les deux méthodes d'installation. [IMPORTANT] ==== _Ne pas_ suivre les deux méthodes: une procédure _exclue_ l'autre. Choisissez la meilleure en fonction de vos besoins et capacités. ==== Avant d'aller plus loin, soyez sûr de disposer deux cartes Ethernet qui supportent le mode promiscuous pour la réception et la transmission, comme elles doivent être capables d'envoyer des paquets Ethernet avec n'importe quelle adresse, et non pas juste pour la leur. De plus, pour avoir de bonnes performances, les cartes devront être capable contrôler le bus PCI (PCI bus mastering). Les meilleurs choix sont toujours l'Intel EtherExpress(TM) Pro, suivie de la série 3c9xx de chez 3Com(R). Pour simplifier la configuration il peut être utile d'avoir deux cartes de différents constructeurs (utilisant un pilote de périphérique différent) afin de distinguer clairement quelle interface est connectée au routeur et quelle autre est connectée au réseau. [[filtering-bridges-kernel]] === Configuration du noyau Donc vous avez décidé d'utiliser la bonne vieille méthode d'installation. Pour commencer, vous devez ajouter les lignes suivantes à votre fichier de configuration du noyau: [.programlisting] .... options BRIDGE options IPFIREWALL options IPFIREWALL_VERBOSE .... La première ligne est pour compiler le support du pont, la seconde est le coupe-feu et la troisième sont les fonctions de traces du coupe-feu. Maintenant il est nécessaire de compiler et d'installer le nouveau noyau. Vous pourrez trouver des instructions détaillées dans la section link:{handbook}#kernelconfig-building[Compiler et installer un noyau sur mesures] du Manuel de FreeBSD. [[filtering-bridges-modules]] === Le chargement de modules Si vous avez choisi d'employer cette méthode nouvelle et plus simple; la seule chose à faire maintenant est d'ajouter la ligne suivante au fichier [.filename]#/boot/loader.conf#: [.programlisting] .... bridge_load="YES" .... De cette façon, durant le démarrage du système le module [.filename]#bridge.ko# sera chargé avec le noyau. Il n'est pas nécessaire de rajouter une ligne pour le module [.filename]#ipfw.ko#, étant donné qu'il sera chargé automatiquement après l'exécution des étapes présentées dans la section suivante. [[filtering-bridges-finalprep]] == Dernière préparation Avant de redémarrer afin de charger le nouveau noyau ou les modules nécessaires (selon la méthode d'installation précédemment retenue), vous devez faire quelques modifications dans le fichier de configuration [.filename]#/etc/rc.conf#. La règle de défaut du coupe-feu est de rejeter tous les paquets IP. Au départ nous configurerons un coupe-feu "ouvert", afin de vérifier son fonctionnement sans problème relatif au filtrage de paquet (dans le cas où vous faite cela à distance, une telle configuration vous évitera de rester isolé du réseau). Ajoutez les lignes suivantes dans [.filename]#/etc/rc.conf#: [.programlisting] .... firewall_enable="YES" firewall_type="open" firewall_quiet="YES" firewall_logging="YES" .... La première ligne activera le coupe-feu (et chargera le module [.filename]#ipfw.ko# s'il n'est pas compilé dans le noyau), la seconde le configurera dans le mode "ouvert" (comme expliqué dans [.filename]#/etc/rc.firewall#), la troisième ligne rendra le chargement des règles silencieux (sans affichage) et la quatrième activera le support de trace d'activité du coupe-feu. Au sujet de la configuration des interfaces réseau, la méthode la plus utilisée est d'assigner une adresse IP à une seule des cartes réseau, mais le pont fonctionnera à l'identique si les deux interfaces ou aucune n'ont d'adresse IP configurée. Dans le dernier cas (sans adresse IP) la machine faisant office de pont sera toujours cachée et inaccessible depuis le réseau: pour la configurer, vous devez vous attacher depuis la console ou à travers une troisième interface réseau séparée du pont. Parfois, durant le démarrage du système, certains programmes ont besoin d'accéder au réseau, par exemple pour la résolution de noms: dans ce cas il est nécessaire d'assigner une adresse IP à l'interface externe (celle connectée à l'Internet où le serveur `DNS` réside), puisque le pont sera activé à la fin de la procédure de démarrage. Cela signifie que l'interface [.filename]#fxp0# (dans notre cas) doit être mentionnée dans la section concernant ifconfig du fichier [.filename]#/etc/rc.conf#, mais pas [.filename]#xl0#. Assigner une adresse IP aux deux cartes réseau n'a pas beaucoup de sens, à moins que, durant la procédure de démarrage, des applications devront accéder à des services sur les deux segments Ethernet. Il y a une autre chose importante à savoir. Quand on utilise l'IP sur Ethernet, il y a en fait deux protocoles Ethernet utilisés: l'un est l'IP, l'autre est l'`ARP`. `ARP` effectue la conversion de l'adresse IP d'un hôte en son adresse Ethernet (couche MAC). Afin d'autoriser la communication entre deux hôtes séparés par le pont, il est nécessaire que le pont transmette les paquets `ARP`. Un tel protocole n'est pas inclus dans la couche IP, puisque qu'il n'apparaît qu'avec l'utilisation de l'IP sur Ethernet. Le coupe-feu de FreeBSD filtre exclusivement la couche IP et donc tous les paquets non-IP (`ARP` compris) seront transmis sans être filtrés, même si le coupe-feu est configuré pour ne rien laisser passer. Il est maintenant temps de redémarrer le système et de l'utiliser comme auparavant: il y aura de nouveaux messages concernant le pont et le coupe-feu, mais le pont ne sera pas activé et le coupe-feu, étant en mode "ouvert", n'interdira aucune opération. Si il y a un quelconque problème, vous devriez le corriger maintenant avant de continuer. [[filtering-bridges-enabling]] == Activer le pont A ce point, pour activer le pont, vous devez exécuter les commandes suivantes (en pensant bien de remplacer les noms des deux interfaces réseau [.filename]#fxp0# et [.filename]#xl0# avec les vôtres): [source,shell] .... # sysctl net.link.ether.bridge.config=fxp0:0,xl0:0 # sysctl net.link.ether.bridge.ipfw=1 # sysctl net.link.ether.bridge.enable=1 .... La première ligne spécifie quelles interfaces devront être activées par le pont, la seconde activera le coupe-feu sur le pont et enfin la troisième activera le pont. [NOTE] ==== Si vous utiliser FreeBSD 5.1-RELEASE ou une version précédente, les variables sysctl diffèrent. Consultez la page de manuel man:bridge[4] pour plus de détails. ==== A ce moment là, vous devriez être en mesure d'insérer la machine entre deux ensembles d'hôtes sans compromettre de capacités de communication entre eux. Ensuite, l'étape suivante est d'ajouter les parties `net.link.ether.bridge.[bla]=[bla]` de ces lignes dans le fichier [.filename]#/etc/sysctl.conf# afin de les exécuter au démarrage. [[filtering-bridges-ipfirewall]] == Configurer le coupe-feu Il est maintenant temps de créer votre propre fichier de règle personnalisé pour le coupe-feu, afin de sécuriser le réseau interne. Il y aura quelques complications à faire cela parce que toutes les fonctionnalités du coupe-feu ne sont pas disponibles sur un pont. En outre, il y a une différence entre les paquets qui sont en cours de transmission et les paquets qui sont reçus par la machine locale. En général, les paquets entrants traversent le coupe-feu une seule fois, et pas deux comme c'est normalement le cas; en fait ils sont filtrés à la réception, aussi les règles qui utilisent "out" ou "xmit" n'agiront jamais. Personnellement, j'utilise "in via" qui est une ancienne syntaxe, mais qui a un sens quand vous la lisez. Une autre limitation est que vous êtes réduit à l'utilisation seulement des commandes "pass" ou "drop" pour les paquets filtrés par un pont. Les choses sophistiquées comme "divert", "forward" ou "reject" ne sont pas disponibles. De telles options peuvent toujours être utilisées, mais uniquement sur le trafic à destination ou depuis le pont lui-même (s'il possède une adresse IP). Une nouveauté de FreeBSD 4.0, est le concept de filtrage avec gestion des états (stateful). C'est une grande amélioration pour le trafic `UDP`, qui typiquement est une requête de sortie, suivie peu de temps après par une réponse avec le même ensemble d'adresses IP et de numéro de ports (mais avec une source et une destination réservée, bien sûr). Pour les coupe-feux qui n'ont pas de gestion des états, il n'y a presque pas de possibilité de gérer ce type de trafic en une seule session. Mais avec un coupe-feu qui peut se "souvenir" d'un paquet `UDP` sortant et qui, pour quelques minutes, autorise une réponse, la gestion des services `UDP` est triviale. L'exemple suivant montre comment le faire. Il est possible de faire la même chose avec les paquets `TCP`. Cela vous permet d'éviter certaines attaques par refus de service et autres désagréables problèmes, mais augmente également rapidement la taille de votre table des états. Regardons un exemple de configuration. Notez tout d'abord qu'au début du fichier [.filename]#/etc/rc.firewall# il y a déjà des règles standards pour l'interface de boucle locale [.filename]#lo0#, aussi nous ne devrions pas y faire attention. Les règles personnalisées devraient être placées dans un fichier séparé (disons [.filename]#/etc/rc.firewall.local#) et chargées au démarrage du système, en modifiant la ligne de [.filename]#/etc/rc.conf# où nous avions défini le coupe-feu "ouvert": [.programlisting] .... firewall_type="/etc/rc.firewall.local" .... [IMPORTANT] ==== Vous devez préciser le chemin __complet__, sinon il ne sera pas chargé avec le risque de rester isolé du réseau. ==== Pour notre exemple imaginez que nous avons l'interface [.filename]#fxp0# connectée vers l'extérieur (Internet) et l'interface [.filename]#xl0# vers l'intérieur (LAN). Le pont possède une adresse IP `1.2.3.4` (il n'est pas possible que votre fournisseur d'accès puisse vous donner une adresse de classe A comme celle-ci, mais pour cet exemple cela ira). [.programlisting] .... # Les choses dont nous avons gardé l'état avant de continuer add check-state # Rejeter les réseaux RFC 1918 add drop all from 10.0.0.0/8 to any in via fxp0 add drop all from 172.16.0.0/12 to any in via fxp0 add drop all from 192.168.0.0/16 to any in via fxp0 # Autorise la machine pont à communiquer si elle le désire # (si la machine est sans adresse IP, ne pas inclure ces lignes) add pass tcp from 1.2.3.4 to any setup keep-state add pass udp from 1.2.3.4 to any keep-state add pass ip from 1.2.3.4 to any # Autorise les hôtes internes à communiquer add pass tcp from any to any in via xl0 setup keep-state add pass udp from any to any in via xl0 keep-state add pass ip from any to any in via xl0 # Section TCP # Autoriser SSH add pass tcp from any to any 22 in via fxp0 setup keep-state # Autoriser SMTP seulement vers le serveur de courrier add pass tcp from any to relay 25 in via fxp0 setup keep-state # Autoriser le transfert de zone seulement par le serveur de noms esclave [dns2.nic.it] add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state # Laisser passer les sondes d'ident. C'est préférable plutôt que d'attendre # qu'elles s'arrêtent add pass tcp from any to any 113 in via fxp0 setup keep-state # Laisser passer la zone de "quarantaine" add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state # Section UDP # Autorise le DNS seulement vers le serveur de noms add pass udp from any to ns 53 in via fxp0 keep-state # Laisser passer la zone de "quarantaine" add pass udp from any to any 49152-65535 in via fxp0 keep-state # Section ICMP # Laisser passer 'ping' add pass icmp from any to any icmptypes 8 keep-state # Laisser passer les messages d'erreurs générés par 'traceroute' add pass icmp from any to any icmptypes 3 add pass icmp from any to any icmptypes 11 # Tout le reste est suspect add drop log all from any to any .... Ceux qui parmi vous ont déjà installé des coupe-feux auparavant pourront noter l'absence de certaines choses. En particulier, il n'y a pas de règles contre le forgeage d'adresses, en fait nous n'avons _pas_ ajouté: [.programlisting] .... add deny all from 1.2.3.4/8 to any in via fxp0 .... Cela, bloque les paquets provenant de l'extérieur et clamant être en provenance de votre réseau. C'est quelque chose que vous devriez habituellement faire pour être sûr que personne n'essaie de passer outre votre filtre de paquet, en générant d'infames paquets qui sont comme s'il venaient de l'intérieur. Le problème avec cela est qu'il y a _au moins_ un hôte de l'extérieur que vous ne voulez pas ignorer: le routeur. Mais habituellement, les fournisseurs d'accès contrent le forgeage sur leur routeur, aussi nous ne devons pas nous en préoccuper plus que cela. La dernière règle semble être une copie conforme de la règle par défaut, qui ne laisse passer rien de ce qui n'est pas spécifiquement autorisé. Mais il y a une différence: tout le trafic suspect sera tracé. Il y a deux règles pour faire passer le trafic SMTP et `DNS` vers le serveur de courrier et le serveur de noms, si vous en avez. Evidemment l'ensemble du jeu de règle devra être arrangé selon vos goûts personnels, c'est juste un exemple particulier (le format des règles est décrit précisément dans la page de manuel man:ipfw[8]). Notez qu'afin que "relay" et "ns" puissent fonctionner, les services de résolution de nom doivent fonctionner _avant_ que le pont soit activé. C'est un exemple pour être sûr que vous avez configuré l'adresse IP sur la bonne carte réseau. Alternativement il est possible de spécifier l'adresse IP au lieu du nom (nécessaire si la machine est sans adresse IP). Les personnes qui ont l'habitude de configurer des coupe-feux ont probablement également utilisé soit une règle "reset" soit une règle "forward" pour les paquets ident (`TCP` port 113). Malheureusement, ce n'est pas une option applicable avec un pont, aussi la meilleure solution est de les laisser passer vers leur destination. Aussi longtemps que la machine de destination ne fait pas tourner un daemon ident, cela est relativement inoffensif. L'alternative est de bloquer les connexions sur le port 113, ce qui pose problème avec des services comme l'IRC (la sonde d'ident doit s'arrêter). La seule autre chose qui est un peu étrange que vous avez peut-être noté est qu'il y a une règle pour laisser le pont communiquer, et une autre pour les hôtes internes. Rappelez-vous que c'est parce que les deux ensembles de trafic prendront un chemin différent à travers le noyau et dans le filtre de paquet. Le réseau interne ira à travers le pont, alors que la machine locale utilisera la pile IP normale pour communiquer. Ainsi les deux règles s'occupent de cas différents. La règle "in via [.filename]#fxp0#" fonctionne pour les deux chemins. En général, si vous employez des règles "in via" dans tout le filtre, vous devrez faire une exception pour les paquets générés localement, parce qu'ils ne sont pas passés par une de nos interfaces. [[filtering-bridges-contributors]] == Participants Plusieurs parties de cet article proviennent, et furent mises à jour et adaptées d'un vieux texte sur les ponts, écrit par Nick Sayer. Cet article est également inspiré d'une introduction sur les ponts de Steve Peterson. Un grand merci à Luigi Rizzo pour l'implémentation du code de pont dans FreeBSD et pour le temps qu'il a passé à répondre à toutes mes questions à ce sujet. Un remerciement également à Tom Rhodes qui a supervisé mon travail de traduction de l'Italien (langue d'origine de cet article) à l'Anglais. diff --git a/documentation/content/fr/articles/ipsec-must/_index.adoc b/documentation/content/fr/articles/ipsec-must/_index.adoc index a1cd459988..d6d0ea1c06 100644 --- a/documentation/content/fr/articles/ipsec-must/_index.adoc +++ b/documentation/content/fr/articles/ipsec-must/_index.adoc @@ -1,262 +1,272 @@ --- title: Vérification indépendante du fonctionnement d'IPSec sous FreeBSD authors: - author: David Honig email: honig@sprynet.com releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "opengroup", "general"] --- = Vérification indépendante du fonctionnement d'IPSec sous FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé Vous avez installé IPSec et cela semble fonctionner. Comment pouvez-vous en être sûr? Je décris une méthode pour vérifier expérimentalement le fonctionnement d'IPSec. Version française de Marc Fonvieille ``. ''' toc::[] == Le problème Tout d'abord, supposons que vous avez <>. Comment savez-vous si cela <>? Bien sûr, votre connexion ne fonctionnera pas si elle est mal configurée, et fonctionnera quand vous l'aurez enfin correctement configurée. man:netstat[1] le fera apparaître. Mais pouvez-vous le confirmer de façon indépendante? == La solution Tout d'abord, quelques informations théoriques relatives à la cryptographie: . Les données chiffrées sont uniformément distribuées, i.e., ont une entropie maximale par symbole; . Les données brutes, non compressées sont en générale redondantes, i.e., n'ont pas une entropie maximale. Supposez que vous pourriez mesurer l'entropie des données à destination et en provenance de votre interface réseau. Alors vous pourriez voir la différence entre données non-chiffées et données chiffrées. Cela serait vrai même si certaines des données en "mode chiffré" n'étaient pas chiffrées --- comme l'en-tête IP externe, si le paquet doit être routable. [[MUST]] === MUST L'"Universal Statistical Test for Random Bit Generators"(http://www.geocities.com/SiliconValley/Code/4704/universal.pdf[MUST]) d'Ueli Maurer, ou encore le "test statistique universel pour les générateurs aléatoires de bits", mesure rapidement l'entropie d'un échantillon. Il utilise une sorte d'algorithme de compression. <> pour une variante qui mesure les morceaux (environ un quart de mégaoctet) successifs d'un fichier. [[tcpdump]] === Tcpdump Nous avons également besoin d'une manière de capturer les données réseau brutes. Un programme appelé man:tcpdump[1] vous permet de faire cela, si vous avez activé l'interface _Berkeley Packet Filter_ (Filtre de Paquet de Berkeley) dans votre <>. La commande [source,shell] .... tcpdump -c 4000 -s 10000 -w dumpfile.bin .... capturera 4000 paquets bruts dans le fichier _dumpfile.bin_. Dans cet exemple jusqu'à 10000 octets par paquets seront capturés. == L'expérience Voici l'expérience: [.procedure] ==== . Ouvrez une fenêtre sur un hôte IPSec et une autre sur un hôte non sécurisé. . Maintenant commencez à <>. . Dans la fenêtre "sécurisée", lancez la commande UNIX(R) man:yes[1], qui fera défiler le caractère `y`. Au bout d'un moment, arrêtez cela. Passez à la fenêtre non sécurisée, et faites de même. Au bout d'un moment, arrêtez. . Maintenant lancez <> sur les paquets capturés. Vous devriez voir quelque chose de semblable à ce qui suit. Ce qui est important de noter est que la connexion non sécurisée a 93% (6,7) de valeurs attendues (7,18), et la connexion "normale" a 29% (2,1) de valeurs attendues. + [source,shell] .... % tcpdump -c 4000 -s 10000 -w ipsecdemo.bin % uliscan ipsecdemo.bin Uliscan 21 Dec 98 L=8 256 258560 Measuring file ipsecdemo.bin Init done Expected value for L=8 is 7.1836656 6.9396 -------------------------------------------------------- 6.6177 ----------------------------------------------------- 6.4100 --------------------------------------------------- 2.1101 ----------------- 2.0838 ----------------- 2.0983 ----------------- .... ==== [[caveat]] == Mise en garde Cette expérience montre qu'IPSec _semble_ distribuer les données utiles _uniformément_ comme un chiffrement le devrait. Cependant, l'expérience décrite ici _ne peut pas_ détecter les problèmes possibles dans un système. Ceux-ci peuvent être la génération ou l'échange d'une clé faible, des données ou clés visibles par d'autres, l'utilisation d'algorithmes faibles, code du noyau modifié, etc... Etudiez les sources, maîtrisez le code. [[IPsec]] == IPSec - Définition Extensions de sécurité au protocole internet IPv4, requises pour l'IPv6. Un protocole pour le chiffrement et l'authentification au niveau IP (hôte à hôte). SSL sécurise uniquement une socket d'application; SSH sécurise seulement une session; PGP sécurise uniquement un fichier spécifique ou un message. IPSec chiffre tout entre deux hôtes. [[ipsec-install]] == Installation d'IPSec La plupart des versions récentes de FreeBSD ont le support IPSec dans leurs sources de base. Aussi vous devrez probablement ajouter l'option `IPSEC` dans votre configuration de noyau et, après la compilation et l'installation du noyau, configurer les connexions IPSec en utilisant la commande man:setkey[8]. Un guide complet sur l'utilisation d'IPSec sous FreeBSD est fourni dans le link:{handbook}#ipsec[Manuel de Freebsd]. [[kernel]] == src/sys/i386/conf/KERNELNAME Ce qui suit doit être présent dans le fichier de configuration du noyau afin de pouvoir capturer les données réseau avec man:tcpdump[1]. Soyez-sûr de lancer man:config[8] après avoir rajouté la ligne ci-dessous, et de recompiler et réinstaller. [.programlisting] .... device bpf .... [[code]] == Test statistique universel de Maurer (pour une longueur de bloc=8 bits) Vous pouvez trouver le même code source http://www.geocities.com/SiliconValley/Code/4704/uliscanc.txt[ici]. [.programlisting] .... /* ULISCAN.c ---blocksize of 8 1 Oct 98 1 Dec 98 21 Dec 98 uliscan.c derived from ueli8.c This version has // comments removed for Sun cc This implements Ueli M Maurer's "Universal Statistical Test for Random Bit Generators" using L=8 Accepts a filename on the command line; writes its results, with other info, to stdout. Handles input file exhaustion gracefully. Ref: J. Cryptology v 5 no 2, 1992 pp 89-105 also on the web somewhere, which is where I found it. -David Honig honig@sprynet.com Usage: ULISCAN filename outputs to stdout */ #define L 8 #define V (1< #include int main(argc, argv) int argc; char **argv; { FILE *fptr; int i,j; int b, c; int table[V]; double sum = 0.0; int iproduct = 1; int run; extern double log(/* double x */); printf("Uliscan 21 Dec 98 \nL=%d %d %d \n", L, V, MAXSAMP); if (argc < 2) { printf("Usage: Uliscan filename\n"); exit(-1); } else { printf("Measuring file %s\n", argv[1]); } fptr = fopen(argv[1],"rb"); if (fptr == NULL) { printf("Can't find %s\n", argv[1]); exit(-1); } for (i = 0; i < V; i++) { table[i] = 0; } for (i = 0; i < Q; i++) { b = fgetc(fptr); table[b] = i; } printf("Init done\n"); printf("Expected value for L=8 is 7.1836656\n"); run = 1; while (run) { sum = 0.0; iproduct = 1; if (run) for (i = Q; run && i < Q + K; i++) { j = i; b = fgetc(fptr); if (b < 0) run = 0; if (run) { if (table[b] > j) j += K; sum += log((double)(j-table[b])); table[b] = i; } } if (!run) printf("Premature end of file; read %d blocks.\n", i - Q); sum = (sum/((double)(i - Q))) / log(2.0); printf("%4.4f ", sum); for (i = 0; i < (int)(sum*8.0 + 0.50); i++) printf("-"); printf("\n"); /* refill initial table */ if (0) { for (i = 0; i < Q; i++) { b = fgetc(fptr); if (b < 0) { run = 0; } else { table[b] = i; } } } } } .... diff --git a/documentation/content/fr/articles/leap-seconds/_index.adoc b/documentation/content/fr/articles/leap-seconds/_index.adoc index 37195ed707..19bc5b27f9 100644 --- a/documentation/content/fr/articles/leap-seconds/_index.adoc +++ b/documentation/content/fr/articles/leap-seconds/_index.adoc @@ -1,80 +1,90 @@ --- title: Support des secondes intercalaires par FreeBSD releaseinfo: "$FreeBSD$" --- = Support des secondes intercalaires par FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] ''' toc::[] Version française de Marc Fonvieille ``. [[leapseconds-definition]] == Introduction Une _seconde intercalaire_ est une correction d'une seconde afin de synchroniser les échelles de temps atomique avec la rotation de la Terre. Cet article décrit comme FreeBSD gère les secondes intercalaires. Au moment de l'écriture de ce document, le prochain ajout d'une seconde intercalaire aura lieu le 30 Juin 2015 à 23:59:60 UTC. Cette seconde intercalaire se produira pendant un jour de travail pour le nord et le sud de l'Amérique ainsi que pour la région Asie-Pacifique. Les secondes intercalaires sont annoncées par l'http://datacenter.iers.org/[IERS] dans le http://datacenter.iers.org/web/guest/bulletins/-/somos/5Rgv/product/16[Bulletin C]. Le principe des secondes intercalaires est décrit dans la https://tools.ietf.org/html/rfc7164#section-3[RFC 7164]. Consultez à ce sujet également man:time2posix[3]. [[leapseconds-posix]] == Gestion par défaut de la seconde intercalaire sous FreeBSD La méthode la plus simple pour gérer les secondes intercalaires est l'ensemble des règles POSIX de gestion du temps qu'utilise par défaut FreeBSD combiné avec link:{handbook}#network-ntp[NTP]. Quand man:ntpd[8] tourne sur le système et que l'heure est synchronisée avec des serveurs NTP qui gèrent correctement les secondes intercalaires, la seconde intercalaire fera que le système répétera automatiquement la dernière seconde de la journée. Aucun autre ajustement ne sera nécessaire. Si les serveurs NTP de référence ne gèrent pas correctement les secondes intercalaires, man:ntpd[8] mettra à jour l'heure d'une seconde après que le serveur en amont ait constaté la modification de l'heure et qu'il se soit mis lui-même à l'heure. Si NTP n'est pas utilisé, un ajustement manuel de l'horloge système sera nécessaire après le passage de la seconde intercalaire. [[leapseconds-cautions]] == Mises en garde Les secondes intermédiaires sont ajoutées au même moment partout dans le monde à minuit UTC. Au Japon c'est au milieu de la manitée, à midi dans le Pacifique, en fin d'après-midi en Amérique, et la nuit en Europe. Nous pensons et nous nous attendons que FreeBSD, si on lui a fourni un service NTP correct et stable, se comporte comme attendu durant la seconde intercalaire, comme il le fit lors des secondes intercalaires précédentes. Cependant, nous attirons votre attention sur le fait que pratiquement aucune application n'a jamais rien demandé au noyau au sujet des secondes intercalaires. Notre expérience est que, telle qu'elles ont été prévues, les secondes intercalaires sont essentiellement une nouvelle répétition de la seconde précédant la seconde intercalaire, et cela est une surprise pour la plupart des programmeurs d'applications. D'autres systèmes d'exploitation et d'autres ordinateurs peuvent ou pas gérer la seconde intercalaire de la même manière que FreeBSD, et les systèmes sans service NTP correct et stable n'auront aucune connaissance des secondes intercalaires. Il est pas rare pour des ordinateurs de planter en raison des secondes intercalaires, et l'expérience a montré qu'une grande partie des serveurs NTP publiques pourront gérer et annoncer les secondes intercalaires de manière incorrecte. Essayez de vous assurer que rien d'horrible ne s'est produit à cause de la seconde intercalaire. [[leapseconds-testing]] == Test Il est possible de vérifier si une seconde intercalaire sera utilisée. En raison de la nature de NTP, le test pourra ne pas fonctionner 24 heures avant la seconde intercalaire. Certaines horloges de référence n'annoncent les secondes intercalaires qu'une heure avant leur ajout. Questionnons le démon NTP: [source,shell] .... % ntpq -c 'rv 0 leap' .... Un affichage comprenant le terme `leap_add_sec` indique un support des secondes intercalaires. Avant les 24 heures précédant la seconde intercalaire, ou après que la seconde intercalaire se soit écoulée, le terme `leap_none` sera affiché. [[leapseconds-conclusion]] == Conclusion En pratique, les secondes intercalaires ne sont pas un problème sous FreeBSD. Nous espérons que cette présentation aide à clarifier ce à quoi il faut s'attendre et comment rendre l'ajout de la seconde intercalaire plus aisé. diff --git a/documentation/content/fr/articles/linux-users/_index.adoc b/documentation/content/fr/articles/linux-users/_index.adoc index 42be916d26..e6b6c1a487 100644 --- a/documentation/content/fr/articles/linux-users/_index.adoc +++ b/documentation/content/fr/articles/linux-users/_index.adoc @@ -1,387 +1,397 @@ --- title: Guide rapide pour débuter avec FreeBSD à l'attention des utilisateurs de Linux® authors: - author: John Ferrell copyright: 2008 The FreeBSD Documentation Project releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "intel", "redhat", "linux", "unix", "general"] --- = Guide rapide pour débuter avec FreeBSD à l'attention des utilisateurs de Linux(R) :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé Ce document a pour but de familiariser rapidement les utilisateurs de Linux(R) de niveau intermédiaire à avancé avec les fondamentaux de FreeBSD. Version française de Frederic Culot ``. ''' toc::[] [[intro]] == Introduction Ce document met en évidence les différences entre FreeBSD et Linux(R) de telle sorte que les utilisateurs de Linux(R) d'un niveau intermédiaire jusqu'à avancé puissent se familiariser rapidement avec les fondamentaux de FreeBSD. Il s'agit ici simplement d'une courte introduction technique qui n'a pas pour objectif d'expliciter les différences "philosophiques" entre les deux systèmes d'exploitation. Ce document part du principe que vous avez déjà installé FreeBSD. Si vous n'avez pas installé FreeBSD ou que vous avez besoin d'aide pour mener à terme le processus d'installation, vous pouvez vous référer au chapitre link:{handbook}#install[Installer FreeBSD] du Manuel de Référence FreeBSD. [[shells]] == Interpréteurs de commandes: Pas de Bash? Ceux qui ont l'habitude de Linux(R) sont souvent surpris de voir que Bash n'est pas l'interpréteur de commandes par défaut de FreeBSD. En fait, Bash n'est même pas présent dans l'installation par défaut. À la place, FreeBSD utilise man:tcsh[1] comme interpréteur par défaut. Cependant, Bash ainsi que vos autres interpréteurs de commandes favoris sont disponibles dans les <> de FreeBSD. Si vous installez d'autres interpréteurs de commandes vous pouvez utiliser man:chsh[1] pour définir un interpréteur par défaut pour un utilisateur. Il est cependant recommandé de ne pas modifier l'interpréteur de commandes par défaut de `root`. La raison en est que les interpréteurs de commandes qui ne sont pas inclus dans la distribution de base sont normalement installés dans [.filename]#/usr/local/bin# ou [.filename]#/usr/bin#. Dans le cas d'un problème les systèmes de fichiers contenant [.filename]#/usr/local/bin# et [.filename]#/usr/bin# peuvent ne pas être montés. Dans ce cas `root` n'aurait pas accès à son interpréteur de commandes par défaut, ce qui empêcherait `root` de pouvoir se connecter. Pour cette raison un second compte `root`, le compte `toor`, a été créé pour l'utilisation avec des interpréteurs de commandes qui ne sont pas ceux par défaut. Vous pouvez consulter les questions fréquemment posées sur la sécurité concernant le link:{faq}#TOOR-ACCOUNT[compte toor] pour plus d'information. [[software]] == Paquetages et logiciels portés: ajouter des logiciels sous FreeBSD En plus de la traditionnelle méthode UNIX(R) d'installation de logiciels (télécharger les sources, extraire, éditer le code source, et compiler), FreeBSD offre deux autres méthodes pour installer des applications: les paquetages et les logiciels portés. Une liste complète de tous les logiciels portés et paquetages disponibles se trouve http://www.freebsd.org/ports/[ici]. [[packages]] === Paquetages Les paquetages sont des applications pré-compilées, les équivalents FreeBSD des fichiers [.filename]#.deb# pour les systèmes basés sur Debian/Ubuntu et des fichiers [.filename]#.rpm# pour les systèmes basés sur Red Hat/Fedora. Par exemple, la commande suivante installe Apache 2.2: [source,shell] .... # pkg_add /tmp/apache-2.2.6_2.tbz .... Utiliser l'option `-r` indique à man:pkg[add] de télécharger automatiquement le paquetage et de l'installer, ainsi que toutes ses dépendances: [source,shell] .... # pkg_add -r apache22 Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/apache22.tbz... Done. Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/All/expat-2.0.0_1.tbz... Done. Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/All/perl-5.8.8_1.tbz... Done. [snip] To run apache www server from startup, add apache22_enable="YES" in your /etc/rc.conf. Extra options can be found in startup script. .... [NOTE] ==== Si vous utilisez une version RELEASE de FreeBSD (6.2, 6.3, 7.0, etc., généralement installée depuis un CD-ROM) `pkg_add -r` téléchargera les paquetages compilés spécifiquement pour cette version. Ces paquetages peuvent _ne pas_ être la version la plus récente de l'application. Vous pouvez utiliser la variable `PACKAGESITE` pour surcharger ce comportement par défaut. Par exemple, assignez link:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/Latest/[ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/Latest/] à `PACKAGESITE` pour télécharger les paquetages les plus récents construits pour les versions 6.X. ==== Pour plus d'information concernant les paquetages vous pouvez vous référer à la section 4.4 du Manuel FreeBSD: link:{handbook}#packages-using[Utiliser le système des logiciels pré-compilés]. [[ports]] === Les logiciels portés Le catalogue des logiciels portés est la seconde méthode proposée par FreeBSD pour installer des applications. Le catalogue des logiciels portés a pour architecture un ensemble de [.filename]#Makefiles# et de fichiers correctifs spécifiquement adaptés pour pouvoir installer depuis les sources des applications diverses sur FreeBSD. Lors de l'installation d'un logiciel porté le système téléchargera le code source, appliquera tous les correctifs nécessaires, compilera le code, et installera l'application (et fera de même pour toutes ses dépendances). Le catalogue des logiciels portés, parfois appelée l'arbre des ports (ports tree en anglais), peut être trouvé dans [.filename]#/usr/ports#. Nous partons ici du principe que le catalogue des logiciels portés a été installé pendant le processus d'installation de FreeBSD. Si le catalogue des logiciels portés n'a pas été installé, il peut être ajoutée à partir des disques d'installation en utilisant man:sysinstall[8], ou bien récupéré depuis les serveurs FreeBSD en utilisant man:csup[1] ou man:portsnap[8]. Des instructions détaillées concernant l'installation du catalogue des logiciels portés peuvent être consultées dans la link:{handbook}#ports-using[section 4.5.1] du Manuel. Installer un logiciel porté est aussi simple (en général) que de se déplacer dans le répertoire du logiciel porté et de lancer le processus de compilation. L'exemple suivant installe Apache 2.2 depuis le catalogue des logiciels portés: [source,shell] .... # cd /usr/ports/www/apache22 # make install clean .... Un des avantages majeurs d'utiliser les logiciels portés pour installer des logiciels est de pouvoir adapter les options d'installation. Par exemple, lors de l'installation d' Apache 2.2 depuis une version portée, il vous est possible d'activer mod_ldap en fixant la variable `WITH_LDAP` de man:make[1]: [source,shell] .... # cd /usr/ports/www/apache22 # make WITH_LDAP="YES" install clean .... Vous pouvez vous référer à la section 4.5 du Manuel FreeBSD, link:{handbook}#ports-using[Utiliser le catalogue des logiciels portés], pour obtenir plus d'information concernant le catalogue des logiciels portés. [[which]] === Logiciel porté ou paquetage, lequel devrais-je utiliser? Les paquetages sont simplement des logiciels portés pré-compilés, donc il s'agit vraiment de choisir entre une installation depuis les sources (logiciels portés) ou une installation utilisant des binaires pré-compilés. Chaque méthode présente ses avantages: .Les paquetages (binaires) * Installation plus rapide (compiler de grosses applications peut prendre du temps). * Inutile de comprendre comment compiler un logiciel. * Inutile d'installer des compilateurs sur votre système. .Les logiciels portés (sources) * Possibilité d'adapter les options d'installation (les paquetages sont normalement compilés avec les options standards alors qu'avec les logiciels portés vous pouvez adapter diverses options comme la compilation de modules additionnels ou le changement de l'emplacement par défaut). * Vous pouvez appliquer vos propres fichiers correctifs si vous le souhaitez. Si vous n'avez pas de besoins particuliers, les paquetages seront probablement tout à fait adaptés à votre situation. S'il vous arrivait d'avoir des besoins spécifiques, les logiciels portés seraient plus appropriés (et n'oubliez pas que si vous devez effectuer des adaptations mais que vous préférez les paquetages, vous pouvez toujours compiler un paquetage personnalisé en utilisant make`package` et en copiant le paquetage sur d'autres serveurs). [[startup]] == Démarrage Système: où sont les niveaux d'exécution (run-levels)? Linux(R) utilise le système d'initialisation SysV alors que FreeBSD utilise le style traditionnel BSD avec man:init[8]. Avec man:init[8] il n'existe pas de niveaux d'exécution et pas de [.filename]#/etc/inittab#, mais à la place le démarrage est contrôlé par l'utilitaire man:rc[8]. Le script [.filename]#/etc/rc# lit [.filename]#/etc/defaults/rc.conf# et [.filename]#/etc/rc.conf# pour déterminer quels services doivent être démarrés. Les services déclarés sont alors démarrés en lançant les scripts d'initialisation du service considéré que l'on trouve dans [.filename]#/etc/rc.d/# et [.filename]#/usr/local/etc/rc.d/#. Ces scripts sont similaires aux scripts que l'on trouve dans [.filename]#/etc/init.d/# sur les systèmes Linux(R). **** _Pourquoi existe-t-il deux emplacements distincts pour les scripts d'initialisation de services ?_ Les scripts que l'on trouve dans [.filename]#/etc/rc.d/# sont pour les applications qui font partie du système de base (man:cron[8], man:sshd[8], man:syslog[3], et d'autres). Les scripts dans [.filename]#/usr/local/etc/rc.d/# sont pour les applications installées par les utilisateurs telles que Apache, Squid, etc. Quelle est la différence entre le système de "base" et les applications installées par l'utilisateur? FreeBSD est développé comme un système d'exploitation complet. En d'autres termes, le noyau, les bibliothèques système, et les utilitaires présents dans l'espace utilisateur (tels que man:ls[1], man:cat[1], man:cp[1], etc.) sont développés et distribués conjointement. C'est à cela que l'on fait référence en parlant de système de "base". Les applications installées par l'utilisateur sont des applications qui ne font pas partie du système de "base", telles que Apache, X11, Mozilla Firefox, etc. Ces applications sont généralement installées en utilisant le <> de FreeBSD. Afin de les conserver à l'écart du système de "base", les applications installées par l'utilisateur sont normalement placées dans [.filename]#/usr/local/#. Ainsi les binaires installés par l'utilisateur se trouvent dans [.filename]#/usr/local/bin/#, les fichiers de configuration dans [.filename]#/usr/local/etc/#, et ainsi de suite. **** Les services sont activés en spécifiant `NomDuService_enable="YES"` dans [.filename]#/etc/rc.conf# (man:rc.conf[5]). Pour vous faire une idée, vous pouvez consulter les valeurs par défaut du système dans [.filename]#/etc/defaults/rc.conf#, ces valeurs par défaut sont surchargées par celles trouvées dans [.filename]#/etc/rc.conf#. De plus, lors de l'installation de logiciels additionnels, veillez à consulter leur documentation pour déterminer de quelle manière sont activés les services associés, le cas échéant. Le bout de code suivant extrait de [.filename]#/etc/rc.conf# active man:sshd[8] et Apache 2.2. Il spécifie également que Apache devrait être lancé avec SSL. [.programlisting] .... # enable SSHD sshd_enable="YES" # enable Apache with SSL apache22_enable="YES" apache22_flags="-DSSL" .... Dès lors qu'un service a été activé dans [.filename]#/etc/rc.conf#, ce service peut être démarré depuis la ligne de commande (sans avoir à redémarrer le système): [source,shell] .... # /etc/rc.d/sshd start .... Si un service n'a pas été activé il peut être démarré depuis la ligne de commande en utilisant `forcestart`: [source,shell] .... # /etc/rc.d/sshd forcestart .... [[network]] == Configuration Réseau [[interfaces]] === Interfaces Réseau À la place d'un identifiant générique _ethX_ que Linux(R) utilise pour identifier une interface réseau, FreeBSD utilise le nom du pilote suivi d'un nombre en tant qu'identifiant. La sortie suivante de man:ifconfig[8] montre deux interfaces réseau Intel(R) Pro 1000 ([.filename]#em0# et [.filename]#em1#): [source,shell] .... % ifconfig em0: flags=8843 mtu 1500 options=b inet 10.10.10.100 netmask 0xffffff00 broadcast 10.10.10.255 ether 00:50:56:a7:70:b2 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 mtu 1500 options=b inet 192.168.10.222 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:50:56:a7:03:2b media: Ethernet autoselect (1000baseTX ) status: active .... [[ipaddress]] === Configuration IP Une adresse IP peut être assignée à une interface en utilisant man:ifconfig[8]. Cependant, pour assurer la persistence même après un redémarrage, la configuration IP doit être enregistrée dans [.filename]#/etc/rc.conf#. Dans l'exemple suivant sont spécifiés le nom de la machine, l'adresse IP, et la passerelle par défaut: [.programlisting] .... hostname="server1.example.com" ifconfig_em0="inet 10.10.10.100 netmask 255.255.255.0" defaultrouter="10.10.10.1" .... Utilisez ceci pour configurer une interface pour DHCP: [.programlisting] .... hostname="server1.example.com" ifconfig_em0="DHCP" .... [[firewall]] == Pare-feu Tout comme IPTABLES pour Linux(R), FreeBSD offre également un pare-feu au niveau du noyau; en fait FreeBSD offre trois pare-feux distincts: * link:{handbook}#firewalls-ipfw[IPFIREWALL] * link:{handbook}#firewalls-ipf[IPFILTER] * link:{handbook}#firewalls-pf[PF] IPFIREWALL ou IPFW (la commande pour gérer un jeu de règles IPFW est man:ipfw[8]) est le pare-feu développé et maintenu par les développeurs FreeBSD. IPFW peut être couplé avec man:dummynet[4] pour fournir des possibilités de régulation du trafic et simuler différents types de connections réseau. Voici un exemple de règle IPFW pour autoriser SSH en entrée: [.programlisting] .... ipfw add allow tcp from any to me 22 in via $ext_if .... IPFILTER est le pare-feu applicatif développé par Darren Reed. Celui-ci n'est pas spécifique à FreeBSD et a été porté sur de nombreux systèmes d'exploitation tels que NetBSD, OpenBSD, SunOS, HP/UX, et Solaris. Voici un exemple de règle IPFILTER pour autoriser SSH en entrée: [.programlisting] .... pass in on $ext_if proto tcp from any to any port = 22 .... Le dernier pare-feu, PF, est développé par le projet OpenBSD. PF a été créé pour remplacer IPFILTER, ce qui fait que la syntaxe de PF est très similaire à celle de IPFILTER. PF peut être couplé avec man:altq[4] pour fournir des possibilités de QoS. Voici un exemple de règle PF pour autoriser SSH en entrée: [.programlisting] .... pass in on $ext_if inet proto tcp from any to ($ext_if) port 22 .... [[updates]] == Mettre à jour FreeBSD Il existe trois méthodes différentes pour mettre à jour un système FreeBSD: à partir des sources, les mises à jour binaires, et les disques d'installation. Mettre à jour depuis les sources est la méthode la plus compliquée mais elle offre la plus grande flexibilité. Le processus implique de synchroniser une copie locale du code source de FreeBSD avec les serveurs CVS (Concurrent Versioning System - Système de gestion de Versions Concurrentes) de FreeBSD. Une fois que le code source local est à jour vous pouvez compiler les nouvelles versions du noyau et du système de base. Pour plus d'informations concernant les mises à jour depuis les sources vous pouvez consulter link:{handbook}#updating-upgrading[le chapitre sur la mise à jour] du manuel FreeBSD. Les mises à jour binaires ressemblent aux commandes `yum` ou `apt-get` utilisées pour mettre à jour un système Linux(R). La commande man:freebsd-update[8] téléchargera les nouvelles mises à jour et les installera. Les mises à jour peuvent être programmées par l'intermédiaire de man:cron[8]. [NOTE] ==== Si vous utilisez man:cron[8] pour programmer vos mises à jour, assurez-vous d'utiliser la commande `freebsd-update cron` dans votre man:crontab[1] pour réduire le nombre de machines récupérant les mises à jour au même moment. [.programlisting] .... 0 3 * * * root /usr/sbin/freebsd-update cron .... ==== La dernière méthode, qui permet de mettre à jour en utilisant les disques d'installation, est simple: démarrez depuis les disques d'installation et sélectionnez l'option de mise à jour. [[procfs]] == procfs: disparu mais pas oublié Avec Linux(R), il vous est peut-être arrivé de consulter [.filename]#/proc/sys/net/ipv4/ip_forward# pour déterminer si le routage IP était activé. Avec FreeBSD vous devriez utiliser man:sysctl[8] pour voir ce réglage ainsi que d'autres réglages système parce que man:procfs[5] a été abandonné dans les versions actuelles de FreeBSD (notez que `sysctl` est disponible aussi sous Linux(R)). Dans l'exemple du routage IP voici ce que vous utiliseriez pour déterminer si le routage IP est activé sur votre système FreeBSD: [source,shell] .... % sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0 .... L'option `-a` est utilisée pour lister tous les réglages du système: [source,shell] .... % sysctl -a kern.ostype: FreeBSD kern.osrelease: 6.2-RELEASE-p9 kern.osrevision: 199506 kern.version: FreeBSD 6.2-RELEASE-p9 0: Thu Nov 29 04:07:33 UTC 2007 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC kern.maxvnodes: 17517 kern.maxproc: 1988 kern.maxfiles: 3976 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: server1 kern.hostid: 0 kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 } kern.posix1version: 200112 ... .... [NOTE] ==== Certaines de ces valeurs `sysctl` sont uniquement accessibles en lecture. ==== procfs est parfois nécessaire comme pour faire fonctionner de vieux logiciels, pour examiner des appels système en utilisant man:truss[1], et pour la link:{handbook}#linuxemu[Compatibilité Binaire avec Linux(R)] (celle-ci utilise cependant son propre procfs, man:linprocfs[5]). Si vous avez besoin de monter procfs vous pouvez ajouter la ligne suivante dans [.filename]#/etc/fstab#: [source,shell] .... proc /proc procfs rw,noauto 0 0 .... [NOTE] ==== `noauto` fera en sorte que [.filename]#/proc# ne soit pas monté automatiquement lors du démarrage. ==== Et ensuite montez procfs avec: [source,shell] .... # mount /proc .... [[commands]] == Commandes Usuelles [[packageCommands]] === Gestion des Paquetages [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Commande Linux(R) (Red Hat/Debian) | Equivalent FreeBSD | Rôle |`yum install paquetage` / `apt-get install paquetage` |`pkg_add -r paquetage` |Installation de _paquetage_ depuis un dépôt distant |`rpm -ivh paquetage` / `dpkg -i paquetage` |`pkg_add -v paquetage` |Installation de _paquetage_ |`rpm -qa` / `dpkg -l` |`pkg_info` |Lister les paquetages installés |=== [[systemCommands]] === Gestion Système [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Commande Linux(R) | Equivalent FreeBSD | Rôle |`lspci` |`pciconf` |Lister les périphériques PCI |`lsmod` |`kldstat` |Lister les modules noyau chargés |`modprobe` |`kldload` / `kldunload` |Charger/Décharger les modules noyau |`strace` |`truss` |Examiner les appels système |=== [[conclusion]] == Conclusion Nous esperons que ce document vous a fourni suffisamment d'informations pour que vous puissiez faire vos premiers pas avec FreeBSD. Vous pouvez consulter link:{handbook}[le Manuel FreeBSD] pour une couverture plus complète des sujets abordés ici ainsi que de tous les autres sujets non abordés dans ce document. diff --git a/documentation/content/fr/articles/nanobsd/_index.adoc b/documentation/content/fr/articles/nanobsd/_index.adoc index 5e5fa26547..b81e5863e4 100644 --- a/documentation/content/fr/articles/nanobsd/_index.adoc +++ b/documentation/content/fr/articles/nanobsd/_index.adoc @@ -1,292 +1,302 @@ --- title: Introduction à NanoBSD authors: - author: Daniel Gerzo copyright: 2006 The FreeBSD Documentation Project releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "general"] --- = Introduction à NanoBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +endif::[] [.abstract-title] Résumé Ce document fournit des informations à propos des outils NanoBSD, qui peuvent être utilisés pour créer des images du système FreeBSD pour des applications embarquées, adaptées pour utiliser comme support une carte Compact Flash (ou tout autre support de stockage). Version française de Jean-Loic Tignon ``. ''' toc::[] [[intro]] == Introduction à NanoBSD NanoBSD est un outil actuellement développé par {phk-name}. Il permet de créer une image du système FreeBSD pour des applications embarquées, pouvant utiliser une carte Compact Flash comme support (ou un autre support de stockage) Il peut être utilisé pour créer des images d'installation spécialisées, conçues pour une installation et une maintenance aisées de systèmes communément appelés "appliances". Les appliances ont leur matériel et leur logiciel intégrés dans le produit, ce qui signifie que toutes les applications sont pré-installées. L'appliance est connectée à un réseau existant et peut entrer en fonction (presque) immédiatement. Les fonctionnalités de NanoBSD incluent: * Les logiciels portés et les paquetages fonctionnent comme sous FreeBSD - Chaque application peut être installée et utilisée dans une image NanoBSD, de la même façon que sous FreeBSD. * Aucune fonctionnalité ne manque - S'il est possible de faire quelque chose avec FreeBSD, il sera possible de faire la même chose avec NanoBSD, sauf si la fonctionnalité spécifique ou des fonctionnalités ont été explicitement supprimées de l'image NanoBSD lors de sa création. * Tout est en lecture seule pendant l'exécution - Débrancher le cordon d'alimentation est sans danger. Il n'est pas nécessaire d'exécuter man:fsck[8] après un arrêt inopiné du système. * Facile à créer et à personnaliser - A l'aide d'une seule procédure et d'un fichier de configuration il est possible de créer des images personnalisées et de taille réduite répondant à n'importe quel type de besoin. [[howto]] == Comment utiliser NanoBSD [[design]] === L'organisation de NanoBSD Une fois que l'image est présente sur le support, il est possible de démarrer NanoBSD. Le périphérique de stockage est divisé en trois parties par défaut: * Deux partitions image: `code#1` et `code#2`. * La partition de configuration, qui peut être montée sur le répertoire [.filename]#/cfg# à l'exécution. Ces partitions sont normalement montées en lecture seule. Les répertoires [.filename]#/etc# et [.filename]#/var# sont des disques man:md[4] (malloc). La partition de configuration est montée sur le répertoire [.filename]#/cfg#. Elle contient les fichiers du répertoire [.filename]#/etc# et est brièvement montée en lecture seule juste après le démarrage du système, par conséquent il est nécessaire de recopier les fichiers modifiés de [.filename]#/etc# vers le répertoire [.filename]#/cfg# si l'on souhaite que les changements soient encore effectifs après le redémarrage du système. .Apporter des changements permanents à [.filename]#/etc/resolv.conf# [example] ==== [source,shell] .... # vi /etc/resolv.conf [...] # mount /cfg # cp /etc/resolv.conf /cfg # umount /cfg .... ==== [NOTE] ==== La partition qui abrite [.filename]#/cfg# doit être montée uniquement au démarrage et lors de la copie des fichiers de configuration. Garder [.filename]#/cfg# monté en permanence n'est pas une bonne idée, en particulier si le système NanoBSD tourne sur un périphérique de stockage qui peut être endommagé par un grand nombre d'écritures sur la partition (c'est à dire quand le contenu des tampons de données est transféré sur les disques). ==== === Créer une image NanoBSD Une image NanoBSD est créée à l'aide d'une simple procédure [.filename]#nanobsd.sh#, qui peut être trouvée dans le répertoire [.filename]#/usr/src/tools/tools/nanobsd#. Ce programme crée une image, qui peut être copiée sur le support de stockage à l'aide de man:dd[1]. Les commandes nécessaires à la création d'une image NanoBSD sont: [source,shell] .... # cd /usr/src/tools/tools/nanobsd <.> # sh nanobsd.sh <.> # cd /usr/obj/nanobsd.full <.> # dd if=_.disk.full of=/dev/da0 bs=64k <.> .... <.> Se placer dans le répertoire de base du programme de création de NanoBSD. <.> Démarrer le processus de création. <.> Se placer dans le répertoire où les images ont été créees. <.> Installer NanoBSD sur le support de stockage. === Personnaliser une image NanoBSD C'est probablement la fonctionnalité la plus importante et la plus intéressante de NanoBSD. C'est aussi là où vous passerez le plus de temps lors de vos développements avec NanoBSD. L'invocation de la commande suivante va obliger [.filename]#nanobsd.sh# à lire sa configuration dans le fichier [.filename]#myconf.nano# situé dans le répertoire courant: [source,shell] .... # sh nanobsd.sh -c myconf.nano .... La personnalisation est effectuée de 2 façons: * à l'aide d'options de configuration * à l'aide de fonctions de personnalisation ==== Les options de configuration Grace aux paramètres de configuration, il est possible de configurer des options qui sont passées aux étapes `buildworld` et `installworld` du processus de compilation de NanoBSD, ainsi que des options internes qui sont passées au processus principal de compilation de NanoBSD. A l'aide de ces options, il est possible de diminuer la taille du système, de façon à ce qu'il tienne dans 64Mo. Vous pouvez utiliser les options de configuration pour réduire encore plus FreeBSD, jusqu'à ce qu'il ne consiste plus qu'en un noyau et 2 ou 3 fichiers dans le système de base. Le fichier de configuration consiste en une série d'options de configuration, qui surchargent les valeurs par défaut. Les directives les plus importantes sont: * `NANO_NAME` - Nom de compilation (utilisé pour créer le nom des répertoires de travail). * `NANO_SRC` - Chemin de l'arbre des sources utilisé pour construire l'image. * `NANO_KERNEL` - Nom du fichier de configuration utilisé pour compiler le noyau. * `CONF_BUILD` - Options passées à la phase `buildworld` de la compilation. * `CONF_INSTALL` - Options passées à la phase `installworld` de la compilation. * `CONF_WORLD` - Options passées aux étapes `buildworld` et `installworld`. * `FlashDevice` - Définit le type de support à utiliser. Consulter le fichier [.filename]#FlashDevice.sub# pour plus de détails. ==== Les fonctions de personnalisation Il est possible d'optimiser NanoBSD en utilisant des fonctions d'interpréteur de commandes dans le fichier de configuration. L'exemple suivant présente la trame de base des fonctions de personnalisation: [.programlisting] .... cust_foo () ( echo "bar=topless" > \ ${NANO_WORLDDIR}/etc/foo ) customize_cmd cust_foo .... Un exemple plus utile de fonction de personnalisation est le suivant, qui change la taille par défaut du répertoire [.filename]#/etc# de 5Mo à 30Mo: [.programlisting] .... cust_etc_size () ( cd ${NANO_WORLDDIR}/conf echo 30000 > default/etc/md_size ) customize_cmd cust_etc_size .... Il existe par défaut quelques fonctions de personnalisation prédéfinies et prêtes à être utilisées: * `cust_comconsole` - Désactive man:getty[8] sur les consoles VGA (les périphériques [.filename]#/dev/ttyv*#) et paramètre la console système sur le port série COM1. * `cust_allow_ssh_root` - Autorise l'ouverture de sessions `root` via man:sshd[8]. * `cust_install_files` - Installe les fichiers du répertoire [.filename]#nanobsd/Files#, qui contient des programmes utiles pour l'administration système. ==== Exemple de fichier de configuration Un exemple complet de fichier de configuration pour créer une image NanoBSD personnalisée peut être: [.programlisting] .... NANO_NAME=custom NANO_SRC=/usr/src NANO_KERNEL=MYKERNEL NANO_IMAGES=2 CONF_BUILD=' NO_KLDLOAD=YES NO_NETGRAPH=YES NO_PAM=YES ' CONF_INSTALL=' NO_ACPI=YES NO_BLUETOOTH=YES NO_CVS=YES NO_FORTRAN=YES NO_HTML=YES NO_LPR=YES NO_MAN=YES NO_SENDMAIL=YES NO_SHAREDOCS=YES NO_EXAMPLES=YES NO_INSTALLLIB=YES NO_CALENDAR=YES NO_MISC=YES NO_SHARE=YES ' CONF_WORLD=' NO_BIND=YES NO_MODULES=YES NO_KERBEROS=YES NO_GAMES=YES NO_RESCUE=YES NO_LOCALES=YES NO_SYSCONS=YES NO_INFO=YES ' FlashDevice SanDisk 1G cust_nobeastie() ( touch ${NANO_WORLDDIR}/boot/loader.conf echo "beastie_disable=\"YES\"" >> ${NANO_WORLDDIR}/boot/loader.conf ) customize_cmd cust_comconsole customize_cmd cust_install_files customize_cmd cust_allow_ssh_root customize_cmd cust_nobeastie .... === Mettre à jour NanoBSD Le processus de mise à jour de NanoBSD est relativement simple: [.procedure] ==== . Créer une nouvelle image NanoBSD, comme d'habitude. . Télécharger la nouvelle image dans une partition inutilisée d'une appliance NanoBSD opérationnelle. + La différence la plus importante de cette étape par rapport à l'installation initiale de NanoBSD est que maintenant au lieu d'utiliser le fichier [.filename]#\_.disk.full# (qui contient une image de la totalité du disque), l'image [.filename]#_.disk.image# est installée (qui contient seulement l'image d'une seule partition système). . Redémarrer le système sur la nouvelle partition. . Si tout s'est bien passé, la mise à jour est terminée. . Si quelque chose s'est mal passé, redémarrez de nouveau sur la partition précédente (qui contient l'ancienne image, fonctionnelle celle-ci), pour remettre le système en état de marche le plus rapidement possible. Corriger les problèmes de la nouvelle image, et répéter le processus. ==== Pour installer la nouvelle image sur le système NanoBSD opérationnel, il est possible d'utiliser la procédure [.filename]#updatep1# ou [.filename]#updatep2# située dans le répertoire [.filename]#/root#, en fonction de la partition qui est en cours d'utilisation sur le système. En fonction des services disponibles sur la machine qui dispose de la nouvelle image NanoBSD et du type de transfert qui est préféré, il est possible d'utiliser une de ces trois méthodes: ==== Utiliser man:ftp[1] Si la vitesse de transfert est la priorité, utiliser cet exemple: [source,shell] .... # ftp myhost get _.disk.image "| sh updatep1" .... ==== Utiliser man:ssh[1] Si un transfert sécurisé est préférable, considérer l'utilisation de cet exemple: [source,shell] .... # ssh myhost cat _.disk.image.gz | zcat | sh updatep1 .... ==== Utiliser man:nc[1] Utiliser cet exemple si la machine distante n'utilise ni man:ftp[1] ni man:sshd[8]: [.procedure] ==== . Tout d'abord, ouvrez un écouteur TCP sur la machine qui dispose de l'image et faites-lui envoyer l'image au client: + [source,shell] .... myhost# nc -l 2222 < _.disk.image .... + [NOTE] ====== Assurez vous que le port utilisé n'est pas bloqué par un pare-feu afin de recevoir les connexions entrantes de la machine NanoBSD. ====== . Se connecter à la machine qui dispose de la nouvelle image et exécuter la procédure [.filename]#updatep1#: + [source,shell] .... # nc myhost 2222 | sh updatep1 .... ==== diff --git a/documentation/content/fr/articles/new-users/_index.adoc b/documentation/content/fr/articles/new-users/_index.adoc index 321aafcba5..1afdde681b 100644 --- a/documentation/content/fr/articles/new-users/_index.adoc +++ b/documentation/content/fr/articles/new-users/_index.adoc @@ -1,429 +1,439 @@ --- title: Pour les Nouveaux Venus à FreeBSD et Unix authors: - author: Annelise Anderson email: andrsn@andrsn.stanford.edu releaseinfo: "$FreeBSD$" trademarks: ["freebsd", "ibm", "microsoft", "opengroup", "general"] --- = Pour les Nouveaux Venus à FreeBSD et Unix :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé Félicitations pour avoir installé FreeBSD! Cette introduction concerne les nouveaux venus à la fois à FreeBSD __et__ à Unix - elle commence donc par les bases. Elle suppose que vous utilisiez la version 2.0.5 ou une version ultérieure de FreeBSD telle que distribuée par Walnut Creek ou FreeBSD.ORG, que votre système n'a (jusqu'à présent) qu'un seul utilisateur (vous) - et que vous êtes probablement à l'aise avec DOS/Windows ou OS/2. Version française de Frédéric Haby ``. ''' toc::[] == Initialiser et Terminer une Session Utilisateur Ouvrez une session (quand vous obtenez à l'écran l'invite `login:`) avec le compte utilisateur que vous avez défini à l'installation ou sous le compte super-utilisateur _root_. (FreeBSD a déjà créé le compte root lors de l'installation; root peut accéder à tous les répertoires et tout faire, y compris effacer des fichiers essentiels, donc soyez prudents!). Les symboles % et # dans les exemples sont l'invite du système (la votre peut être différente), où % correspond à un utilisateur normal et # distingue le compte root. Pour terminer la session (vous obtiendrez à nouveau l'invite `login:`), tapez: [source,shell] .... # exit .... autant de fois que nécessaire. Bien sûr, n'oubliez pas la touche kbd:[Entrée] à la fin des commandes, et rappelez-vous qu'Unix fait la distinction entre les majuscules et les minuscules - `exit`, mais pas `EXIT`. Pour arrêtez l'ordinateur, tapez: [source,shell] .... # /sbin/shutdown -h now .... Ou, pour le redémarrer, tapez: [source,shell] .... # /sbin/shutdown -r now .... ou: [source,shell] .... # /sbin/reboot .... Vous pouvez aussi redémarrer avec: kbd:[Ctrl+Alt+Delete]. Laissez au système un peu de temps pour faire son travail. Cette séquence est, dans les plus récentes versions de FreeBSD, l'équivalent de la commande `/sbin/reboot`, et il est nettement préférable de l'employer que d'utiliser l'interrupteur de réinitialisation de votre machine. A moins que vous ne vouliez tout réinstaller ? == Créer un Nouveau Compte Utilisateur avec les Mêmes Droits que Root Si vous n'avez pas créé de compte utilisateur au moment de l'installation, et utilisez donc le compte root, vous devriez maintenant définir un nouvel utilisateur avec: [source,shell] .... # adduser .... La première fois que vous utiliserez adduser, le programme vous demandera peut-être de lui indiquer des options par défaut qu'il sauvegardera. Par exemple, vous préférez peut-être que l'interpréteur de commandes soit csh, s'il vous propose l'interpréteur sh. Sinon, tapez simplement Entrée pour conserver les valeurs par défaut. Celles-ci sont enregistrées dans le fichier [.filename]#/etc/adduser.conf#, que vous pouvez éditer. Supposons que vous ayez créé l'utilisateur _jacques_ dont le nom est __Jacques Dupont__. Attribuez un mot de passe à jacques si la sécurité (pourquoi pas, même des enfants pourraient pianoter sur le clavier) vous préoccupe. Quand le programme vous demande si vous voulez que jacques appartienne à d'autres groupes, répondez: [source,shell] .... Login group is ``jacques''. Invite jacques into other groups: wheel .... Vous pourrez alors ouvrir une session avec le compte __jacques__ puis utiliser la commande `su` pour devenir root. Vous n'aurez dorénavant plus besoin d'ouvrir immédiatement une session avec le compte root. Vous pouvez quitter `adduser` à tout moment en tapant kbd:[Ctrl+C], et pour finir vous pourrez valider le nouveau compte utilisateur ou simplement taper kbd:[n] pour non. Peut-être voudrez vous créer un second compte utilisateur (jeanne?), vous aurez ainsi une issue de secours si vous modifiez les fichiers de configuration de jacques et que quelque chose tourne mal. Une fois que vous avez fini, utilisez `exit` pour revenir à l'invite `login:` et ouvrez une session sous le compte __jacques__. Il est toujours préférable de travailler autant que possible avec un compte utilisateur ordinaire qui n'a pas autant de droits - et donc ne présente pas autant de risques - que root. Si vous avez déjà créé un compte et que vous voulez que cet utilisateur puisse utiliser `su` pour devenir root, vous pouvez devenir root et éditer le fichier [.filename]#/etc/group#, pour y ajouter jacques à la première ligne (le groupe wheel). Familiarisez-vous d'abord avec l'éditeur de texte `vi` - ou utilisez l'éditeur plus simple `ee`, présent sur les versions les plus récentes de FreeBSD. == Tour d'horizon Sous une session utilisateur ordinaire, faites un tour d'horizon et essayez quelques commandes qui vous fourniront des informations et de l'aide quand vous utiliserez FreeBSD. Voici quelques commandes et ce qu'elles font : `id`:: Vous dit qui vous êtes! `pwd`:: Vous dit où vous êtes - le répertoire de travail courant. `ls`:: Donne la liste des fichiers du répertoire courant. `ls -F`:: Donne la liste des fichiers du répertoire courant suivis d'une `\*` pour les exécutables, d'un `/` pour les répertoires, et d'une `@` pour les liens symboliques. `ls -l`:: Donne la liste détaillée des fichiers du répertoire courant - taille, date, autorisations. `ls -a`:: Liste tous les fichiers, y compris les fichiers "." cachés. Si vous êtes root, les fichiers "." sont visibles sans l'option `-a`. `cd`:: Change de répertoire courant. `cd ..` remonte d'un niveau dans l'arborescence; notez l'espace après `cd`. `cd /usr/local` va dans ce répertoire. `cd ~` va dans le répertoire de l'utilisateur courant - e.g., [.filename]#/usr/home/jacques#. Essayez `cd /cdrom`, puis `ls`, pour voir si votre CDROM est monté et fonctionne. `view nom_de fichier`:: Vous permet de visualiser le fichier `_nom_de_fichier_` sans le modifier. Essayez `view /etc/fstab`. `:q` pour quitter. `cat nom_de_fichier`:: Liste _nom_de_fichier_ à l'écran. S'il est trop long et que vous n'en voyez que la fin, appuyez sur kbd:[Arrêt Défil] et utilisez kbd:[flèche-vers-le-haut] pour revenir en arrière; vous pouvez aussi utiliser kbd:[Arrêt Défil] avec les pages de manuel. Appuyez à nouveau sur kbd:[Arrêt Défil] pour terminer votre lecture. Essayez `cat` sur quelques fichiers "." de votre répertoire utilisateur - `cat .cshrc`, `cat .login`, `cat .profile`. Notez les alias de quelques commandes `ls` dans le fichier [.filename]#.cshrc# (ils sont très pratiques). Vous pouvez créer d'autres alias en éditant le fichier [.filename]#.cshrc#. Vous pouvez aussi les mettre à disposition de tous les utilisateurs en les définissant dans le fichier de configuration général [.filename]#/etc/csh.cshrc#. == Obtenir de l'Aide et de l'Information Voici quelques moyens d'obtenir de l'aide. _Texte_ désigne quelque chose de votre choix - normalement une commande ou un nom de fichier - que vous tapez. `apropos texte`:: Tout ce qui contient la chaîne _texte_ dans la `base de données whatis`. `man texte`:: La page de manuel pour _texte_. C'est la principale source de documentation des systèmes Unix. `man ls` vous expliquera toutes les possibilités d'utilisation de la commande `ls`. Utilisez kbd:[Entrée] pour faire défiler le texte, kbd:[Ctrl+b] pour remonter d'une page, kbd:[Ctrl+f] pour passer à la page suivante, et kbd:[q] ou kbd:[Ctrl+c] pour quitter. `which texte`:: Vous dit où se trouve la commande _texte_ dans vos chemins d'accès. `locate texte`:: Tous les répertoires où l'on trouve la chaîne _texte_. `whatis texte`:: Vous dit ce qu'est la commande _texte_ et où se trouve la page de manuel correspondante. `whereis text`:: Cherche le fichier _texte_, et vous en donne le chemin d'accès complet. Essayez la commande `whatis` sur quelques utilitaires d'usage courant comme `cat`, `more`, `grep`, `mv`, `find`, `tar`, `chmod`, `chown`, `date` et `script`. `more` vous permet de lire une page à la fois comme sous DOS, e.g., `ls -l | more` ou `more nom_de_fichier`. `\*` sert de caractère de substitution - e.g., `ls w*` vous donnera la liste de tous les fichiers commençant par `w`. Certaines de ces commandes ne fonctionnent pas correctement? `locate` et `whatis` interrogent une base de données qui est reconstruite chaque semaine. Si votre machine n'est pas en service le weekend (et sous FreeBSD), vous devrez peut-être exécuter les commandes de maintenance quotidienne, hebdomadaire et mensuelle de temps à autre. Faites-le sous le compte root et attendez qu'elles se terminent avant de lancer la suivante. [source,shell] .... # /etc/daily sortie non mentionnée # /etc/weekly sortie non mentionnée # /etc/monthly sortie non mentionnée .... Si vous êtes las d'attendre, appuyez sur kbd:[Alt+F2] pour obtenir une nouvelle _console virtuelle_, et rouvrir une session. Après tout, c'est un système multi-utilisateurs, multi-tâches. Ces commandes afficheront probablement des messages à l'écran pendant qu'elles s'exécutent; vous pouvez taper `clear` pour effacer l'écran. Une fois qu'elles auront terminé, regardez le contenu des fichiers [.filename]#/var/mail/root# et [.filename]#/var/log/messages#. Utiliser de telles commandes est une des tâches d'administration système - étant seul utilisateur d'un système Unix, vous êtes votre propre administrateur système. Pratiquement tout ce que vous aurez à faire sous le compte root sera l'administration de votre système. Ces tâches sont souvent mal décrites dans les ouvrages volumineux sur Unix qui passent plus de temps à détailler les menus des gestionnaires de fenêtres. Procurez-vous l'un des deux ouvrages de référence sur l'administration système, soit Evi Nemeth et.al.'s UNIX System Administration Handbook (Prentice-Hall, 1995, ISBN 0-13-15051-7) - deuxième édition avec une couverture rouge; ou Æleen Frisch's Essential System Administration (O'Reilly & Associates, 1993, ISBN 0-937175-80-3)footnote:[N.d.T.: traduit en français sous le titre Les Bases de l'Administration Système, chez le même éditeur.]. J'ai personnellement utilisé Nemeth. == Editer des Fichiers Texte Pour configurer votre système, vous devez éditer des fichiers texte. Ils sont presque tous dans le répertoire [.filename]#/etc#; vous devrez utiliser la commande `su` pour devenir root pour les modifier. Vous pouvez vous servir de l'éditeur simple `ee`, mais à long terme, cela vaut la peine d'apprendre à utiliser `vi`. Il y a une excellente introduction à vi dans [.filename]#/usr/src/contrib/nvi/docs/tutorial# si vous l'avez installé. Sinon vous pouvez le télécharger par ftp sur link:ftp://ftp.cdrom.com[ftp://ftp.cdrom.com] dans le répertoire [.filename]#FreeBSD/FreeBSD-current/src/contrib/nvi/tutorial#. Avant d'éditer un fichier, faites-en une copie de sauvegarde. Supposons que vous vouliez modifier le fichier [.filename]#/etc/rc.conf#. Avec la commande `cd /etc` vous allez dans le répertoire [.filename]#/etc#, puis tapez: [source,shell] .... # cp rc.conf rc.conf.orig .... pour recopier le fichier [.filename]#rc.conf# dans [.filename]#rc.conf.orig#, de façon à pouvoir ensuite recopier [.filename]#rc.conf.orig# dans _rc.conf_ pour revenir à la version originale. Il serait encore mieux de le déplacer (renommer) puis de faire la copie en sens inverse: [source,shell] .... # mv rc.conf rc.conf.orig # cp rc.conf.orig rc.conf .... parce que la commande `mv` conserve la date et le nom du propriétaire d'origine du fichier. Vous pouvez maintenant éditer le fichier [.filename]#rc.conf#. Si vous voulez revenir à la version d'origine, utilisez alors `mv rc.conf rc.conf.myedit` (en supposant que vous vouliez conserver la version que vous avez modifiée) puis: [source,shell] .... # mv rc.conf.orig rc.conf .... pour remettre l'original à sa place. Pour éditer un fichier, tapez: [source,shell] .... # vi nom_de_fichier .... déplacez vous dans le fichier avec les touches flèches. kbd:[Echap] (la touche d'échappement) met `vi` en mode commande. Voici quelques-unes de ces commandes: `x`:: efface le caractère sur lequel se trouve le curseur. `dd`:: efface toute la ligne (même si elle dépasse la largeur de l'écran et s'affiche sur plus d'une ligne). `i`:: permet d'insérer du texte devant la position du curseur. `a`:: permet d'insérer du texte après la position du curseur. Après avoir tapé `i` ou `a`, vous pouvez insérer du texte. `Echap` vous ramène en mode commande. Vous pouvez alors taper: `:w`:: pour enregistrer le fichier modifié sur disque et continuer à l'éditer, `:wq`:: pour enregistrer le fichier modifié sur disque et quitter l'éditeur, `:q!`:: pour quitter l'éditeur sans enregistrer vos modifications, `/texte`:: recherche la prochaine occurrence de _texte_ et y positionne le curseur; `/Entrée` (la touche Entrée) recherche ensuite la prochaine occurrence de _texte_, `G`:: va à la fin du fichier, `nG`:: va à la __n__ième ligne du fichier, kbd:[Ctrl+L]:: rafraîchit l'affichage, kbd:[Ctrl+b] et kbd:[Ctrl+f]:: remonte ou descend d'une page, de la même façon qu'avec les utilitaires `more` et `view`. Entraînez-vous à utiliser `vi` dans votre répertoire utilisateur en créant un nouveau fichier avec `vi nom_de_fichier` puis ajoutez-y et effacez du texte, enregistrez le ficher et rééditez-le. `vi` peut vous réserver des surprises parce qu'il est assez complexe, et il vous arrivera de taper accidentellement des commandes au résultat inattendu. (Certains aiment vraiment `vi` - il est bien plus puissant qu'EDIT de DOS - voyez par exemple la commande `:r` command.) Utilisez kbd:[Echap] une ou plusieurs fois pour être sûr que vous êtes en mode commande quand vous êtes dans l'embarras, enregistrez régulièrement vos modifications avec la commande `:w`, et utilisez la commande `:q!` pour sortir et rééditer la dernière version enregistrée avec `:w` au besoin. Vous pouvez maintenant `cd` vers [.filename]#/etc#, `su` pour devenir root, utiliser `vi` pour éditer le fichier [.filename]#/etc/group#, et ajouter un utilisateur au groupe wheel pour qu'il ait les mêmes droits que root. Ajoutez juste une virgule puis le nom de l'utilisateur à la fin de la première ligne, appuyez sur kbd:[Echap], et utilisez la commande `:wq` pour enregistrer le fichier et quitter l'éditeur. La modification est aussitôt prise en compte par le système. (vous n'avez pas mis de blanc après la virgule, n'est-ce-pas?) == Imprimer des fichiers DOS A ce stade, vous n'avez probablement pas encore configuré FreeBSD pour pouvoir utiliser votre imprimante. Voici donc une méthode pour créer un fichier à partir d'une page de manuel, l'enregistrer sur disquette et l'imprimer sous DOS. Si par exemple, vous voulez lire dans le détail ce qui concerne la modification des droits d'accès aux fichiers (c'est assez important), la commande man chmod vous affiche la page de manuel. La commande: [source,shell] .... # man chmod > chmod.txt .... recopie la page de manuel dans le fichier [.filename]#chmod.txt# au lieu de l'afficher à l'écran. Mettez maintenant une disquette formatée DOS dans le lecteur de disquettes A:, `su` pour devenir root, et tapez: [source,shell] .... # /sbin/mount -t msdos /dev/fd0 /mnt .... pour monter le lecteur de disquettes dans le répertoire [.filename]#/mnt#. Ensuite (plus besoin d'être root, vous pouvez utiliser `exit` pour redevenir l'utilisateur jacques), vous pouvez aller dans le répertoire où vous avez créé le fichier chmod.txt et le recopier sur la disquette avec la commande: [source,shell] .... % cp chmod.txt /mnt .... puis utiliser `ls /mnt` pour lister le contenu du répertoire [.filename]#/mnt#, où devrait figurer le fichier [.filename]#chmod.txt#. En particulier, il vous sera utile de créer un fichier à partir du résultat de la commande [.filename]#/sbin/dmesg# en tapant: [source,shell] .... % /sbin/dmesg > dmesg.txt .... et en copiant [.filename]#dmesg.txt# sur la disquette. `/sbin/dmesg` liste les informations affichées au démarrage du système, qu'il est utile de comprendre, parce qu'elles décrivent la configuration matérielle reconnue par FreeBSD au démarrage. Si vous posez des questions sur mailto:freebsd-questions@FreeBSD.ORG[freebsd-questions@FreeBSD.ORG] ou dans un forum USENET - du type "FreeBSD ne reconnaît pas mon lecteur de bande, que faire ? " - on vous demandera ce qu'indique `dmesg` sur votre système. Vous pouvez maintenant démonter le lecteur de disquette (sous le compte root) pour retirer la disquette avec la commande: [source,shell] .... # /sbin/umount /mnt .... et redémarrer la machine pour passer sous DOS. Copiez ces fichiers dans un répertoire DOS, éditez-les avec DOS EDIT, Windows Notepad, ou un traitement de texte, faites une petite modification pour avoir à les enregistrer et imprimez-les comme d'habitude sous DOS ou Windows. J'espère que cela marche! Les pages de manuel s'impriment mieux avec la commande `print` du DOS. (Copier des fichiers de FreeBSD vers une partition DOS montée est dans certains cas encore un peu risqué). Pour pouvoir imprimer depuis FreeBSD, il faut définir l'imprimante dans le fichier [.filename]#/etc/printcap# et créer le répertoire tampon correspondant dans [.filename]#/var/spool/output#. Si votre imprimante est sur le port `lpt0` (qui s'appelle `LPT1` sous DOS), il suffit d'aller dans le répertoire [.filename]#/var/spool/output# et (sous le compte root) de créer le répertoire [.filename]#lpd#, s'il n'existe pas, en tapant: [source,shell] .... # mkdir lpd .... L'imprimante devrait alors répondre si elle était sous tension au démarrage du système et les commandes lp ou lpr devraient envoyer un fichier à l'imprimante. Que le fichier s'imprime ou non dépend de la configuration de l'imprimante, qui est décrite dans le link:{handbook}[manuel FreeBSD.] == D'autres Commandes Utiles `df`:: liste les systèmes de fichiers montés, leur taille et leur utilisation. `ps aux`:: liste les processus actifs. `ps ax` en est une forme abregée. `rm nom_de_fichier`:: efface le fichier `_nom_de_fichier._` `rm -R répertoire`:: efface le répertoire _répertoire_ et tous ses sous-répertoires - attention! `ls -R`:: liste les fichiers du répertoire courant et de tous ses sous-répertoires; j'en utilisais une variante, `ls -AFR > where.txt`, pour avoir la liste de tous les fichiers du répertoire racine [.filename]#/# et (indépendamment) du répertoire [.filename]#/usr# avant de trouver un meilleur moyen pour rechercher des fichiers. `passwd`:: pour changer le mot de passe d'un utilisateur (ou le mot de passe root). `man hier`:: pages de manuel du système de fichier Unix. Avec le commande `find` vous pouvez localiser le fichier _nom_de_fichier_ dans [.filename]#/usr# ou un de ses sous-répertoires: [source,shell] .... % find /usr -name "nom_de_fichier" .... Vous pouvez employer `\*` comme caractère de substitution dans `"_nom_de_fichier_"` (qui doit être entre guillemets). Si vous demandez à `find` d'effectuer la recherche dans [.filename]#/# au lieu de [.filename]#/usr#, il va parcourir tous les systèmes de fichiers montés, y compris le CDROM et la partition DOS. Voici un excellent livre qui détaille les commandes et les utilitaires du système Unix: Abrahams & Larson, Unix for the Impatient (2nd ed., Addison-Wesley, 1996). Vous trouverez aussi beaucoup d'informations sur Unix sur l'Internet. Essayez l' http://www.eecs.nwu.edu/unix.html[Unix Reference Desk]. == Etapes Suivantes Vous avez maintenant les outils nécessaires à l'exploration du système et à l'édition de fichiers. Il y a énormément d'informations dans le link:{handbook}[manuel FreeBSD] (que vous avez probablement aussi sur votre disque dur) et sur le http://www.freebsd.org/[site Internet de FreeBSD]. Il y a un grand nombre de logiciels sur le CDROM de http://www.cdrom.com/[Walnut Creek] et sur leur site Internet. Le "manuel" vous explique comment les utiliser (installer le logiciel s'il existe, avec `pkg_add /cdrom/packages/All/nom_du_logiciel`, où _nom_du_logiciel_ est le nom du fichier correspondant au logiciel voulu). Le CDROM donne la liste des logiciels pré-compilés ou non footnote:[N.d.T: Les logiciels prévus pour être utilisés avec FreeBSD peuvent être pré-compilés (packages) ou disponibles sous forme de code source (ports) livré avec les procédures nécessaires à sa compilation.] avec une courte description de chacun dans [.filename]#/cdrom/packages/index#, [.filename]#/cdrom/packages/index.txt# et [.filename]#/cdrom/ports/index#. Il y a des descriptifs plus détaillés dans [.filename]#/cdrom/ports/\*/*/pkg/DESCR#, où les *s désignent respectivement les sous-répertoires regroupant les logiciels par catégories et les noms des logiciels. Si vous trouvez le "manuel" trop subtil (avec ses commandes `lndir` et ainsi de suite) en ce qui concerne l'installation des logiciel à compiler, voici une méthode qui fonctionne habituellement: Trouvez le logiciel que vous voulez, par exemple `kermit`. Il y aura un sous-répertoire correspondant sur le CDROM. Copiez ce sous-répertoire dans [.filename]#/usr/local# (là où l'on met généralement les logiciels que l'on installe pour les mettre à la disposition de tous les utilisateurs) avec: [source,shell] .... # cp -R /cdrom/ports/comm/kermit /usr/local .... Ceci crée normalement un sous-répertoire [.filename]#/usr/local/kermit# qui contient tous les fichiers du sous-répertoire `kermit` du CDROM. Recherchez ensuite dans le répertoire [.filename]#/cdrom/ports/distfiles# un fichier dont le nom indique que c'est le logiciel que vous voulez installer. Copiez ce fichier dans [.filename]#/usr/ports/distfiles#; avec les versions récentes, vous pouvez sauter cette étape, FreeBSD s'en chargera. Dans le cas de `kermit`, il n'y a aucun fichier associé dans [.filename]#/cdrom/ports/distfiles#. Puis `cd` dans le sous-répertoire de [.filename]#/usr/local/kermit# qui contient le fichier [.filename]#Makefile#. Tapez: [source,shell] .... # make all install .... Pendant l'installation, le système ira chercher par ftp les fichiers compressés qu'il ne trouve pas dans [.filename]#/usr/ports/distfiles#. Si vous n'êtes pas encore connecté à l'Internet et que le fichier correspondant au logiciel n'existe pas dans [.filename]#/cdrom/ports/distfiles#, vous devrez récupérer ce fichier sur une autre machine et le copier dans [.filename]#/usr/ports/distfiles# depuis une disquette ou votre partition Dos. Lisez [.filename]#Makefile# (Avec `cat`, `more` ou `view`) pour trouver sur quel site (le "master distribution site" - site de distribution d'origine) aller pour récupérer le fichier et pour connaître son nom. Ce nom sera tronqué si vous téléchargez le fichier sous DOS, et vous devrez redonner au fichier son nom d'origine après l'avoir recopié dans [.filename]#/usr/ports/distfiles# (avec la commande `mv`) pour que FreeBSD le trouve. (Utilisez le transfert de fichier en mode binaire!) Revenez ensuite dans [.filename]#/usr/local/kermit#, trouvez le sous-répertoire où est [.filename]#Makefile#, et tapez `make all install`. Il peut aussi arriver quand vous installez des logiciels pré-compilés ou non qu'un autre logiciel soit nécessaire. Si l'installation s'interrompt avec un message du style `can't find unzip`, vous devez d'abord installer le logiciel unzip avant de continuer. Un fois le logiciel installé, tapez `rehash` pour que FreeBSD relise la liste des fichiers dans les chemins d'accès par défaut, de façon à ce qu'il sache ce qui s'y trouve. (Si vous obtenez de nombreux messages d'erreur `path not found` avec les commandes `whereis` ou `which`, ajoutez les répertoires nécessaires à la liste des chemins d'accès par défaut définis dans le fichier [.filename]#.cshrc# de votre répertoire utilisateur. L'instruction path d'Unix fonctionne de la même façon que sous DOS, à ceci près que, pour des raisons de sécurité, le répertoire courant n'y est pas défini (par défaut); si le programme que vous cherchez se trouve dans le répertoire courant, vous devrez faire précéder le nom du programme de [.filename]#./# pour l'exécuter (pas d'espace après le "[.filename]#/#".) Vous voudrez peut-être installer la version la plus récente de Netscape depuis leur link:ftp://ftp.netscape.com[site ftp]. (Netscape a besoin du gestionnaire graphique X Window.) Il vous faut la version "unknown bsd". Appliquez au fichier téléchargé les commandes `gunzip nom_de_fichier` puis `tar xvf nom_de_fichier`, recopiez l'exécutable dans [.filename]#/usr/local/bin# ou dans tout autre répertoire où vous mettez les programmes, `rehash`, et ajoutez les lignes suivantes aux fichiers [.filename]#.cshrc# dans les répertoires de tous les utilisateurs ou (plus simplement) au fichier [.filename]#/etc/csh.cshrc# de démarrage de l'interpréteur de commandes csh applicable à tous les utilisateurs: [.programlisting] .... setenv XKEYSYMDB /usr/X11R6/lib/X11/XKeysymDB setenv XNLSPATH /usr/X11R6/lib/X11/nls .... Ce qui présuppose que les fichiers [.filename]#XKeysymDB# et le répertoire [.filename]#nls# existent dans [.filename]#/usr/X11R6/lib/X11#; s'ils n'y sont pas, trouvez-les et recopiez-les dans ce répertoire. Si vous aviez auparavant installé Netscape depuis le CDROM (ou par ftp), ne remplacez pas [.filename]#/usr/local/bin/netscape# par le nouveau binaire; ce fichier n'est qu'une procédure qui positionne des variables d'environnement. Au lieu de cela, renommez le nouveau fichier binaire en [.filename]#netscape.bin# et installez-le à la place de l'ancien, qui s'appelle [.filename]#/usr/local/lib/netscape/netscape.bin#. == Votre Environnement de Travail Votre interpréteur de commandes est la composante la plus importante de votre environnement de travail. C'est l'équivalent de COMMAND.COM sous DOS. C'est lui qui analyse les commandes que vous tapez au clavier et communique avec le reste du système d'exploitation. Vous pouvez aussi écrire des procédures, qui sont l'équivalent des fichiers .BAT de DOS. Deux interpréteurs de commandes sont pré-installés par FreeBSD : csh et sh. csh est utile pour le travail en ligne de commande, mais vous devriez mieux écrire vos procédures pour sh (ou bash). `echo $SHELL` vous retourne le nom de l'interpréteur que vous utilisez actuellement. L'interpréteur csh est commode, mais tcsh fait tout ce que fait csh et plus encore. Il vous permet de rappeler des commandes avec les touches flèches et de les éditer. Il sait compléter les noms de fichiers avec la touche Tab (csh utilise la touche Echap) et il vous permet de revenir dans le répertoire où vous étiez auparavant avec `cd -`. Il est aussi plus facile de modifier l'invite du système avec tcsh. Il vous rend la vie beaucoup plus facile. Voici les trois étapes pour installer un nouvel interpréteur de commandes: Installez l'interpréteur, pré-compilé ou non, comme vous le feriez pour n'importe quel autre logiciel. Utilisez `rehash` puis `which tcsh` (en supposant que vous installiez tcsh) pour vous assurer qu'il est bien installé. Sous le compte root, éditez le fichier [.filename]#/etc/shells#, ajoutez-y une ligne pour le nouvel interpréteur, dans notre cas /usr/local/bin/tcsh, et enregistrez votre modification. (certaines procédures d'installation font cela pour vous.) Utilisez `chsh` pour changer de façon permanente d'interpréteur de commandes, ou tapez `tcsh` sous l'invite du système pour changer d'interpréteur sans ouvrir de nouvelle session. Note: Il peut être dangereux de changer l'interpréteur de commandes du compte root en autre chose que sh ou csh avec les premières versions de FreeBSD et de nombreuses autres versions d'Unix; vous pourriez ne plus avoir d'interpréteur de commandes quand le système passe en mode mono-utilisateur. La solution est d'utiliser `su -m` pour devenir root et disposer de tcsh, parce que l'interpréteur de commandes est partie intégrante de l'environnement. Vous pouvez rendre ce fonctionnement définitif en ajoutant un alias dans votre fichier [.filename]#.tchsrc#: [source,shell] .... alias su su -m .... Quand tcsh démarre, il lit les fichiers [.filename]#/etc/csh.cshrc# et [.filename]#/etc/csh.login#. Il lit aussi le fichier [.filename]#.login# de votre répertoire utilisateur, ainsi que le fichier [.filename]#.cshrc#, à moins que vous n'ayez un fichier [.filename]#.tchsrc#. Vous pouvez facilement en créer un en copiant simplement [.filename]#.cshrc# dans [.filename]#.tcshrc#. Maintenant que vous avez installé tcsh, vous pouvez modifier l'invite du système. Vous trouverez plus de détails dans les pages de manuel de tcsh, mais voici une ligne que vous pouvez mettre dans votre fichier [.filename]#.tchsrc#, qui vous dira combien de commandes vous avez tapées, quelle heure il est, et dans quel répertoire vous vous trouvez. Un > sera aussi affiché si vous êtes un utilisateur ordinaire et un # si vous êtes root, mais tcsh fait cela de toute façon: [source,shell] .... set prompt = "h t ~ " .... Mettez cette ligne à la place de la ligne "set prompt" s'il y en a déjà une, ou après la ligne "if($?prompt) then" sinon. Mettez l'ancienne ligne en commentaire; vous pourrez toujours y revenir si vous le souhaitez. N'oubliez pas les espaces et les guillemets. Vous pouvez forcer la relecture du fichier [.filename]#.tchsrc# en tapant `source .tcshrc`. Vous pouvez obtenir la liste des autres variables d'environnement qui ont été positionnées avec la commande `env`. Le résultat vous indiquera entre autres quels sont votre éditeur et votre gestionnaire de page affichée par défaut, et quel type de terminal vous utilisez. Une commande utile si vous vous connectez à distance et ne pouvez exécuter un programme parce que le terminal n'est pas adapté est `setenv TERM vt100`. == Autres En tant que root, vous pouvez démonter le CDROM avec `/sbin/umount /cdrom`, le sortir du lecteur, en mettre un autre, et monter ce dernier avec `/sbin/mount_cd9660 /dev/cd0a /cdrom` en supposant que `cd0a` est le nom du périphérique associé à votre lecteur de CDROMs. Le système de fichier actif - le deuxième CDROM de la distribution de FreeBSD - est utile si vous manquez d'espace disque. Vous pouvez essayez d'utiliser `emacs` ou des jeux depuis le cdrom. Vous devrez utiliser `lndir`, qui est installé en même temps que le gestionnaire graphique X Window, pour dire au(x) programme(s) où trouver les fichiers dont il a besoin, parce qu'ils se trouvent dans le système de fichiers [.filename]#/cdrom# et non dans [.filename]#/usr# et ses sous-répertoires, où ils devraient normalement être. Lisez `man lndir`. Vous pouvez supprimer un utilisateur (par example, jacques) en utilisant la commande `vipw` pour éditer le fichier [.filename]#master.passwd# (n'utilisez pas `vi` directement sur le fichier [.filename]#master.passwd#); effacez la ligne pour jacques et sauvez le fichier. Editez ensuite [.filename]#/etc/group# et supprimez toutes les occurrences de jacques. Enfin, allez dans [.filename]#/usr/home# et utilisez `rm -R jacques` (pour effacer les fichiers et sous-répertoires du répertoire utilisateur de jacques). == Vos Commentaires sont la Bienvenue Si vous utilisez ce guide, je suis intéressée de savoir où il ne vous est pas suffisamment clair et ce que vous trouvez qu'il y manque, et aussi s'il vous a été utile. footnote:[N.d.T.: en anglais !] Mes remerciements à Eugene W. Stark, professeur d'informatique à SUNY-Stony Brook, et à John Fieber pour ses commentaires pertinents. Annelise Anderson, mailto:andrsn@hoover.stanford.edu[andrsn@hoover.stanford.edu] diff --git a/documentation/content/fr/articles/pam/_index.adoc b/documentation/content/fr/articles/pam/_index.adoc index ec5fc6d248..8daeac087b 100644 --- a/documentation/content/fr/articles/pam/_index.adoc +++ b/documentation/content/fr/articles/pam/_index.adoc @@ -1,570 +1,600 @@ --- title: Pluggable Authentication Modules authors: - author: Dag-Erling Smørgrav copyright: 2001-2003 Networks Associates Technology, Inc. releaseinfo: "$FreeBSD$" trademarks: ["pam", "freebsd", "linux", "opengroup", "sun", "general"] --- = Pluggable Authentication Modules :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Table des matières :part-signifier: Partie :chapter-signifier: Chapitre :appendix-caption: Annexe :table-caption: Tableau :example-caption: Exemple [.abstract-title] Abstract Cet article décrit les principes sous-jacent et les mécanismes de la bibliothèque PAM, il explique comment configurer PAM, l'intégrer dans les applications, et écrire ses propres modules PAM. Version française de Clément Mathieu ``. ''' toc::[] [[pam-intro]] == Introduction La bibliothèque PAM est une API généralisée pour les services relevant de l'authentification permettant à un administrateur système d'ajouter une nouvelle méthode d'authentification en ajoutant simplement un nouveau module PAM, ainsi que de modifier les règles d'authentification en éditant les fichiers de configuration. PAM a été conçu et développé en 1995 par Vipin Samar et Charlie Lai de Sun Microsystems, et n'a pas beaucoup évolué depuis. En 1997 l'Open Group publie les premières spécifications XSSO qui standardisent l'API PAM et ajoute des extensions pour un simple (ou plutot intégré) "sign-on". Lors de l'écriture de cet article, la spécification n'a toujours pas été adoptée comme standard. Bien que cet article se concentre principalement sur FreeBSD 5.x, qui utilise OpenPAM, il devrait également être applicable à FreeBSD 4.x qui utilise Linux-PAM, ainsi qu'à d'autres systèmes d'exploitations tels que Linux ou Solaris. [[pam-trademarks]] == Marques déposées Sun, Sun Microsystems, SunOS and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. UNIX and The Open Group are trademarks or registered trademarks of The Open Group. All other brand or product names mentioned in this document may be trademarks or registered trademarks of their respective owners. [[pam-terms]] == Termes et conventions [[pam-definitions]] == Définitions La terminologie de PAM est plutôt confuse. Ni la publication originale de Samar et Lai, ni la spécification XSSO n'ont essayé de définir formellement des termes pour les acteurs et les entités intervenant dans PAM, les termes qu'ils utilisent (mais ne définissent pas) sont parfois trompeurs et ambigus. Le premier essai d'établir une terminologie consistante et non ambiguë fut un papier écrit par Andrew G. Morgan (l'auteur de Linux-PAM) en 1999. Bien que les choix de Morgan furent un énorme pas en avant, ils ne sont pas parfait d'après l'auteur de ce document. Ce qui suit, largement inspiré par Morgan, est un essai de définir précisément et sans ambiguïté des termes pour chaque acteur ou entité utilisé dans PAM. [.glosslist] compte:: L'ensemble de permissions que le demandeur demande a l'arbitre. demandeur:: L'utilisateur ou l'entité demandant authentification. arbitre:: L'utilisateur ou l'entité possédant les privilèges nécessaires pour vérifier la requête du demandeur ainsi que l'autorité d'accorder ou de rejeter la requête. chaîne:: Une séquence de modules qui sera invoquée pour répondre à une requête PAM. La chaîne comprend les informations concernant l'ordre dans lequel invoquer les modules, les arguments à leur passer et la façon d'interpréter les résultats. client:: L'application responsable de la requête d'authentification au nom du demandeur et de recueillir l'information d'authentification nécessaire. mécanisme:: Il s'agit de l'un des quatre groupes basiques de fonctionnalités fournit par PAM : authentification, gestion de compte, gestion de session et mise à jour du jeton d'authentification. module:: Une collection d'une ou plusieurs fonctions implémentant un service d'authentification particulier, rassemblées dans un fichier binaire (normalement chargeable dynamiquement) et identifié par un nom unique. règles:: Le jeu complet de configuration des règles décrivant comment traiter les requêtes PAM pour un service particulier. Une règle consiste normalement en quatre chaînes, une pour chaque mécanisme, bien que quelques services n'utilisent pas les quatre mécanismes. serveur:: L'application agissant au nom de l'arbitre pour converser avec le client, récupérer les informations d'authentification, vérifier les droits du demandeur et autoriser ou rejeter la requête. service:: Un ensemble de serveurs fournissant des fonctionnalités similaires ou liées et nécessitant une authentification similaire. Les règles de PAM sont définies sur un le principe de par-service; ainsi tous les serveurs qui demandent le même nom de service seront soumis aux mêmes règles. session:: Le contexte dans lequel le service est délivré au demandeur par le serveur. L'un des quatre mécanismes de PAM, la gestion de session, s'en occupe exclusivement par la mise en place et le relâchement de ce contexte. jeton:: Un morceau d'information associé avec un compte tel qu'un mot de passe ou une passphrase que le demandeur doit fournir pour prouver son identité. transaction:: Une séquence de requêtes depuis le même demandeur vers la même instance du même serveur, commençant avec l'authentification et la mise en place de la session et se terminant avec le démontage de la session. [[pam-usage-examples]] == Exemples d'utilisation Cette section a pour but d'illustrer quelques-uns des termes définis précédemment à l'aide d'exemples basiques. == Client et serveurs ne font qu'un Cet exemple simple montre `alice` utilisant man:su[1] pour devenir `root`. [source,shell] .... % whoami alice % ls -l `which su` -r-sr-xr-x 1 root wheel 10744 Dec 6 19:06 /usr/bin/su % su - Password: xi3kiune # whoami root .... * Le demandeur est `alice`. * Le compte est `root`. * Le processus man:su[1] est à la fois client et serveur. * Le jeton d'authentification est `xi3kiune`. * L'arbitre est `root`, ce qui explique pourquoi man:su[1] est setuid `root`. == Client et serveur sont distincts. L'exemple suivant montre `eve` essayant d'initier une connexion man:ssh[1] vers `login.exemple.com`, en demandant à se logguer en tant que `bob`. La connexion réussit. Bob aurait du choisir un meilleur mot de passe ! [source,shell] .... % whoami eve % ssh bob@login.example.com bob@login.example.com's password: % god Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-STABLE (LOGIN) 4: Tue Nov 27 18:10:34 PST 2001 Welcome to FreeBSD! % .... * Le demandeur est `eve`. * Le client d'`eve` est représenté par les processus man:ssh[1] * Le serveur est le processus man:sshd[8] sur `login.example.com` * Le compte est `bob`. * Le jeton d'identification est `god`. * Bien que cela ne soit pas montré dans cet exemple, l'arbitre est `root`. == Exemple de règles Les lignes qui suivent sont les règles par défaut de `sshd`: [.programlisting] .... sshd auth required pam_nologin.so no_warn sshd auth required pam_unix.so no_warn try_first_pass sshd account required pam_login_access.so sshd account required pam_unix.so sshd session required pam_lastlog.so no_fail sshd password required pam_permit.so .... * Cette politique s'applique au service `sshd` (qui n'est pas nécessairement restreint au serveur man:sshd[8]) * `auth`, `account`, `session` et `password` sont des mécanismes. * [.filename]#pam_nologin.so#, [.filename]#pam_unix.so#, [.filename]#pam_login_access.so#, [.filename]#pam_lastlog.so# et [.filename]#pam_permit.so# sont des modules. Il est clair dans cet exemple que [.filename]#pam_unix.so# fournit au moins deux mécanismes ( authentification et gestion de compte). [[pam-conventions]] == Conventions Cette section n'a pas encore été écrite. [[pam-essentials]] == Les bases de PAM [[pam-facilities-primitives]] == Mécanismes et primitives L'API PAM fournit six primitives d'authentification différentes regroupées dans quatre mécanismes qui seront décrits dans la partie suivante. `auth`:: _Authentification._ Ce mécanisme concerne l'authentification du demandeur et établit les droits du compte. Il fournit deux primitives : ** man:pam_authenticate[3] authentifie le demandeur, généralement en demandant un jeton d'identification et en le comparant a une valeur stockée dans une base de données ou obtenue par le biais d'un serveur d'authentification. ** man:pam_setcred[3] établi les paramètres du compte tel que l'uid, les groupes dont le compte fait parti ou les limites sur l'utilisation des ressources. `account`:: _Gestion de compte._ Ce mécanisme concerne la disponibilité du compte pour des raisons autres que l'authentification. Par exemple les restrictions basées sur l'heure courante ou la charge du serveur. Il fournit une seule primitive: ** man:pam_acct_mgmt[3] vérifie que le compte demandé est disponible. `session`:: _Gestion de session._ Ce mécanisme concerne la mise en place de la session et sa terminaison, par exemple l'enregistrement de la session dans les journaux. Il fournit deux primitives: ** man:pam_open_session[3] accomplie les tâches associées à la mise en place d'une session : ajouter une entrée dans les bases [.filename]#utmp# et [.filename]#wtmp#, démarrer un agent SSH... ** man:pam_close_session[3] accomplie les tâches associées à la terminaison d'une session : ajouter une entrée dans les bases [.filename]#utmp# et [.filename]#wtmp#, arrêter l'agent SSH... `password`:: _Gestion des mots de passe._ Ce mécanisme est utilisé pour modifier le jeton d'authentification associé à un compte, soit parce qu'il a expiré, soit parce que l'utilisateur désire le changer. Il fournit une seule primitive: ** man:pam_chauthtok[3] modifie le jeton d'authentification, et éventuellement vérifie que celui-ci est assez robuste pour ne pas être deviné facilement ou qu'il n'a pas déjà utilisé. [[pam-modules]] === Modules Les modules sont le concept clef de PAM; après tout ils constituent le "M" de PAM. Un module PAM est lui-même un morceau de code qui implémente les primitives d'un ou plusieurs mécanismes pour une forme particulière d'authentification; par exemple, les bases de mots de passe UNIX que sont NIS, LDAP et Radius. [[pam-module-naming]] == Nom des modules FreeBSD implémente chaque mécanismes dans un module distinct nommé `pam_mécanisme.so` (par exemple `pam_unix.so` pour le mécanisme Unix .) Les autres implementations possèdent parfois des modules séparés pour des mécanismes séparés et incluent aussi bien le nom du service que celui du mécanisme dans le nom du module. Un exemple est le module `pam_dial_auth.so.1` de Solaris qui est utilisé pour authentifier les utilisateurs dialup. [[pam-module-versioning]] == Gestion des versions de module L'implémentation originale de PAM par FreeBSD, basée sur Linux-PAM, n'utilisait pas de numéro de version pour les modules PAM. Ceci peut poser des problèmes avec les applications tiers qui peuvent être liées avec d'anciennes bibliothèques systèmes, puisqu'il n'y a pas possibilité de charger la version correspondante du module désiré. Pour sa part, OpenPAM cherche les modules qui ont la même version que la bibliothèque PAM (pour le moment 2) et se rabat sur un module sans version si aucun module avec version n'a put être chargé. Ainsi les anciens modules peuvent être fournis pour les anciennes applications, tout en permettant aux nouvelles applications (ou bien nouvellement compilées) de tirer parti des modules les plus récents. Bien que les modules PAM de Solaris possèdent généralement un numéro de version, ils ne sont pas réellement versionnés car le numéro correspond à une partie du nom du module et doit être inclus dans la configuration. [[pam-chains-policies]] == Chaînes et politiques Lorsqu'un serveur initie une transaction PAM, la bibliothèque PAM essaie de charger une politique pour le service spécifié dans l'appel a man:pam_start[3] . La politique indique comment la requête d'authentification doit être traitée et est définie dans un fichier de configuration. Il s'agit de l'autre concept clef de PAM : la possibilité pour l'administrateur de configurer la politique de sécurité d'un système en éditant simplement une fichier texte. Une politique consiste en quatre chaînes, une pour chacune des quatre mécanismes de PAM. Chaque chaîne est une suite de règles de configuration, chacune spécifiant un module à invoquer, des paramètres, options, à passer au module et un drapeau de contrôle qui décrit comment interpréter le code de retour du module. Comprendre le drapeau de contrôle est essentiel pour comprendre les fichiers de configuration de PAM. Il existe quatre drapeaux de contrôle différents : `binding`:: Si le module réussit et qu'aucun module précédent de la chaîne n'a échoué, la chaîne s'interrompt immédiatement et la requête est autorisée. Si le module échoue le reste de la chaîne est exécuté, mais la requête est rejetée au final. + Ce drapeau de contrôle a été introduit par Sun Solaris dans la version 9 (SunOS 5.9); il est aussi supporté par OpenPAM. `required`:: Si le module réussit, le reste de la chaîne est exécuté, et la requête est autorisée si aucun des autres modules n'échoue. Si le module échoue, le reste de la chaîne est exécuté, mais au final la requête est rejetée. `requisite`:: Si le module réussit le reste de la chaîne est exécuté, et la requête est autorisée sauf si d'autres modules échoués. Si le module échoue la chaîne est immédiatement terminée et la requête est rejetée. `sufficient`:: Si le module réussit et qu'aucun des modules précédent n'a échoué la chaîne est immédiatement terminée et la requête est allouée. Si le module échoue il est ignore et le reste de la chaîne est exécuté. + Puisque la sémantique de ce drapeau peut être un peu confuse, spécialement lorsqu'il s'agit de celui du dernier module de la chaîne, il est recommandé d'utiliser le drapeau `binding` à la place de celui-ci sous la condition que l'implémentation le supporte. `optional`:: Le module est exécuté mais le résultat est ignoré. Si tout les modules de la chaîne sont marqués `optional`, toutes les requêtes seront toujours acceptées. Lorsqu'un serveur invoque l'une des six primitives PAM, PAM récupère la chaîne du mécanisme à laquelle la requête correspond et invoque chaque module de la chaîne dans l'ordre indiqué, jusqu'à ce que la fin soit atteinte ou qu'aucune exécution supplémentaire ne soit nécessaire (soit à cause du succès d'un module en `binding` ou `sufficient`, soit à cause de l'échec d'un module `requisite`). La requête est acceptée si et seulement si au moins un module a été invoqué, et que tout les modules non optionnels ont réussi. Notez qu'il est possible, bien que peu courant, d'avoir le même module listé plusieurs fois dans la même chaîne. Par exemple un module qui détermine le nom utilisateur et le mot de passe à l'aide d'un serveur directory peut être invoqué plusieurs fois avec des paramètres spécifiant différents serveurs a contacter. PAM considère les différentes occurrences d'un même module dans une même chaîne comme des modules différents et non liés. [[pam-transactions]] === Transactions Le cycle de vie d'une transaction PAM typique est décrit ci-dessous. Notez que si l'une de ces étapes échoue, le serveur devrait reporter un message d'erreur au client et arrêter la transaction. . Si nécessaire, le serveur obtient les privilèges de l'arbitre par le biais d'un mécanisme indépendant de PAM - généralement en ayant été démarré par `root` ou en étant setuid `root`. . Le serveur appel man:pam_start[3] afin d'initialiser la bibliothèque PAM et indique le service et le compte cible, et enregistre une fonction de conversation appropriée. . Le serveur obtient diverses informations concernant la transaction (tel que le nom d'utilisateur du demandeur et le nom d'hôte de la machine sur lequel le client tourne) et les soumet à PAM en utilisant la fonction man:pam_set_item[3]. . Le serveur appel man:pam_authenticate[3] pour authentifier le demandeur. . Le serveur appel la fonction man:pam_acct_mgmt[3] qui vérifie que le compte est valide et disponible. Si le mot de passe est correct mais a expiré, man:pam_acct_mgmt[3] retournera `PAM_NEW_AUTHTOK_REQD` à la place de `PAM_SUCCESS`. . Si l'étape précédente a retourné `PAM_NEW_AUTHTOK_REQD`, le serveur appel maintenant man:pam_chauthtok[3] pour obliger l'utilisateur à changer le jeton d'authentification du compte désiré. . Maintenant que le demandeur a été correctement authentifié, le serveur appelle man:pam_setcred[3] pour obtenir les privilèges du compte désiré. Il lui est possible de faire ceci parce qu'il agit au nom de l'arbitre dont il possède les privilèges. . Lorsque les privilèges corrects ont été établi le serveur appelle man:pam_open_session[3] pour mettre en place la session. . Maintenant le serveur effectue les services demandés par le client - par exemple fournir un shell au demandeur. . Lorsque le serveur a fini de servir le client, il appelle man:pam_close_session[3] afin de terminer la session. . Pour finir, le serveur appelle man:pam_end[3] afin signaler à la bibliothèque PAM que la transaction se termine et qu'elle peut libérer les ressources qu'elle a alloué au cours de la transaction. [[pam-config]] == Configuration de PAM [[pam-config-file-locations]] == Emplacement des fichiers de configuration Le fichier de configuration de PAM est traditionnellement [.filename]#/etc/pam.conf#. Ce fichier contient toutes les politiques de PAM pour votre système. Chaque ligne du fichier décrit une étape dans une chaîne, tel que nous allons le voir ci-dessous: [.programlisting] .... login auth required pam_nologin.so no_warn .... Les champs sont respectivement, le service, le nom du mécanisme, le drapeau de contrôle, le nom du module et les arguments du module. Tout champ additionnel est considéré comme argument du module. Une chaîne différente est construite pour chaque couple service/mécanisme; ainsi, alors que l'ordre des lignes est important lorsqu'il s'agit des mêmes services ou mécanismes, l'ordre dans lequel les différents services et mécanismes apparaissent ne l'est pas - excepté l'entrée pour le service `other`, qui sert de référence par défaut et doit être placé à la fin. L'exemple du papier original sur PAM regroupait les lignes de configurations par mécanisme et le fichier [.filename]#pam.conf# de Solaris le fait toujours, mais FreeBSD groupe les lignes de configuration par service. Toutefois il ne s'agit pas de la seule possibilité et les autres possèdent aussi un sens. OpenPAM et Linux-PAM offrent un mécanisme de configuration alternatif où les politiques sont placées dans des fichiers séparés portant le nom du service auquel ils s'appliquent. Ces fichiers sont situés dans [.filename]#/etc/pam.d/# et ne contiennent que quatre champs à la place de cinq - le champ contenant le nom du service est omis. Il s'agit du mode par défaut dans FreeBSD 4.x. Notez que si le fichier [.filename]#/etc/pam.conf# existe et contient des informations de configuration pour des services qui n'ont pas de politique spécifiée dans [.filename]#/etc/pam.d#, ils seront utilisés pour ces services. Le gros avantage de [.filename]#/etc/pam.d/# sur [.filename]#/etc/pam.conf# est qu'il est possible d'utiliser la même politique pour plusieurs services en liant chaque nom de service à un fichier de configuration. Par exemple pour utiliser la même politique pour les services `su` et `sudo`, nous pouvons faire comme ceci : [source,shell] .... # cd /etc/pam.d # ln -s su sudo .... Ceci fonctionne car le nom de service est déterminé a partir du nom de fichier plutôt qu'indiqué à l'intérieur du fichier de configuration, ainsi le même fichier peut être utilisé pour des services nommés différemment. Un autre avantage est qu'un logiciel tiers peu facilement installer les politiques pour ses services sans avoir besoin d'éditer [.filename]#/etc/pam.conf#. Pour continuer la tradition de FreeBSD, OpenPAM regardera dans [.filename]#/usr/local/etc/pam.d# pour trouver les fichiers de configurations; puis si aucun n'est trouvé pour le service demandé, il cherchera dans [.filename]#/etc/pam.d/# ou [.filename]#/etc/pam.conf#. Finalement, quelque soit le mécanisme que vous choisissiez, la politique "magique"`other` est utilisée par défaut pour tous les services qui n'ont pas leur propre politique. [[pam-config-breakdown]] == Breakdown of a configuration line Comme expliqué dans <>, chaque ligne de [.filename]#pam.conf# consiste en quatre champs ou plus: le nom de service, le nom du mécanisme, le drapeau de contrôle, le nom du module et la présence ou non d'arguments pour le module. Le nom du service est généralement, mais pas toujours, le nom de l'application auquelle les règles s'appliquent. Si vous n'êtes pas sûr, référez vous à la documentation de l'application pour déterminer quel nom de service elle utilise. Notez que si vous utilisez [.filename]#/etc/pam.d/# à la place de [.filename]#/etc/pam.conf#, le nom du service est spécifié par le nom du fichier de configuration et n'est pas indiqué dans les lignes de configuration qui, dès lors, commencent par le nom du mécanisme. Le mécanisme est l'un des quatre mots clef décrit dans <>. De même, le drapeau de contrôle est l'un des quatre mots clef décrits dans <> et décrit comment le module doit interpréter le code de retour du module. Linux-PAM supporte une syntaxe alternative qui vous laisse spécifier l'action à associer à chaque code de retour possible; mais ceci devrait être évité puisque ce n'est pas standard et étroitement lié à la façon dont Linux-PAM appelle les services (qui diffère grandement de la façon de Solaris et OpenPAM). C'est sans étonnement que l'on apprend qu'OpenPAM ne supporte pas cette syntaxe. [[pam-policies]] == Politiques Pour configurer PAM correctement, il est essentiel de comprendre comment les politiques sont interprétées. Lorsqu'une application appelle man:pam_start[3] la bibliothèque PAM charge la politique du service spécifié et construit les quatre chaînes de module (une pour chaque mécanisme). Si une ou plusieurs chaînes sont vides, les chaînes de la politique du service `other` sont utilisées. Plus tard, lorsque l'application appelle l'une des six primitives PAM, la bibliothèque PAM récupère la chaîne du mécanisme correspondant et appelle la fonction appropriée avec chaque module listé dans la chaîne. Après chaque appel d'une fonction de service, le type du module et le code d'erreur sont retournés par celle-ci pour déterminer quoi faire. À quelques exceptions près, dont nous parlerons plus tard, la table suivante s'applique: .Résumé de la chaîne d'exécution PAM [cols="1,1,1,1", options="header"] |=== | | PAM_SUCCESS | PAM_IGNORE | other |binding |if (!fail) break; |- |fail = true; |required |- |- |fail = true; |requisite |- |- |fail = true; break; |sufficient |if (!fail) break; |- |- |optional |- |- |- |=== Si `fail` est vrai à la fin de la chaîne, ou lorsqu'un "break" est atteint, le dispatcheur retourne le code d'erreur renvoyé par le premier module qui a échoué. Autrement `PAM_SUCCESS` est retourné. La première exception est que le code d'erreur `PAM_NEW_AUTHOK_REQD` soit considéré comme un succès, sauf si aucun module n'échoue et qu'au moins un module retourne `PAM_NEW_AUTHOK_REQD` le dispatcheur retournera `PAM_NEW_AUTHOK_REQD`. La seconde exception est que man:pam_setcred[3] considère les modules `binding` et `sufficient` comme s'ils étaient `required`. La troisième et dernière exception est que man:pam_chauthtok[3] exécute la totalité de la chaîne deux fois (la première pour des vérifications préliminaires et la deuxième pour mettre le mot de passe) et lors de la première exécution il considère les modules `binding` et `sufficient` comme s'ils étaient `required`. [[pam-freebsd-modules]] == Les modules PAM de FreeBSD [[pam-modules-deny]] === man:pam_deny[8] Le module man:pam_deny[8] est l'un des modules disponibles les plus simples; il répond à n'importe qu'elle requête par `PAM_AUTH_ERR`. Il est utile pour désactiver rapidement un service (ajoutez-le au début de chaque chaîne), ou pour terminer les chaînes de modules `sufficient`. [[pam-modules-echo]] === man:pam_echo[8] Le module man:pam_echo[8] passe simplement ses arguments à la fonction de conversation comme un message `PAM_TEXT_INFO`. Il est principalement utilisé pour le debogage mais il peut aussi servir à afficher un message tel que "Les accès illégaux seront poursuivits" avant de commencer la procédure d'authentification. [[pam-modules-exec]] === man:pam_exec[8] Le module man:pam_exec[8] prend comme premier argument le nom du programme à exécuter, les arguments restant étant utilisés comme arguments pour ce programme. L'une des applications possibles est d'utiliser un programme qui monte le répertoire de l'utilisateur lors du login. [[pam-modules-ftp]] == pam_ftp(8) Le module pam_ftp(8) [[pam-modules-ftpusers]] === man:pam_ftpusers[8] Le module man:pam_ftpusers[8] [[pam-modules-group]] === man:pam_group[8] Le module man:pam_group[8] accepte ou rejette le demandeur à partir de son appartenance à un groupe particulier (généralement `wheel` pour man:su[1]). Il a pour but premier de conserver le comportement traditionnel de man:su[1] mais possède d'autres applications comme par exemple exclure un certain groupe d'utilisateurs d'un service particulier. [[pam-modules-krb5]] === man:pam_krb5[8] Le module man:pam_krb5[8] [[pam-modules-ksu]] === man:pam_ksu[8] Le module man:pam_ksu[8] [[pam-modules-lastlog]] === man:pam_lastlog[8] Le module man:pam_lastlog[8] [[pam-modules-login-access]] === man:pam_login_access[8] Le module man:pam_login_access[8] [[pam-modules-nologin]] === man:pam_nologin[8] Le module man:pam_nologin[8] [[pam-modules-opie]] === man:pam_opie[8] Le module man:pam_opie[8] implémente la méthode d'authentification man:opie[4]. Le système man:opie[4] est un mécanisme de challenge-response où la réponse à chaque challenge est une fonction directe du challenge et une phrase de passe, ainsi la réponse peut facilement être calculée "en temps voulu" par n'importe qui possédant la phrase de passe ce qui élimine le besoin d'une liste de mots de passe. De plus, puisque man:opie[4] ne réutilise jamais un mot de passe qui a reçu une réponse correcte, il n'est pas vulnérable aux attaques basée sur le rejouage. [[pam-modules-opieaccess]] === man:pam_opieaccess[8] Le module man:pam_opieaccess[8] est un compagnon du module man:pam_opie[8]. Son but est de renforcer les restrictions codifiées dans man:opieaccess[5], il régule les conditions sous lesquelles un utilisateur qui normalement devrait s'authentifier par man:opie[4] est amené à utiliser d'autres méthodes. Ceci est généralement utilisé pour interdire l'authentification par mot de passe depuis des hôtes non digne de confiance. Pour être réellement effectif, le module man:pam_opieaccess[8] doit être listé comme `requisite` immédiatement après une entrée `sufficient` pour man:pam_opie[8] et avant tout autre module, dans la chaîne `auth`. [[pam-modules-passwdqc]] === man:pam_passwdqc[8] Le module man:pam_passwdqc[8] [[pam-modules-permit]] === man:pam_permit[8] Le module man:pam_permit[8] est l'un des modules disponibles les plus simples; il répond à n'importe quelle requête par `PAM_SUCCESS`. Il est utile pour les services où une ou plusieurs chaînes auraient autrement été vides. [[pam-modules-radius]] === man:pam_radius[8] Le module man:pam_radius[8] [[pam-modules-rhosts]] === man:pam_rhosts[8] Le module man:pam_rhosts[8] [[pam-modules-rootok]] === man:pam_rootok[8] Le module man:pam_rootok[8] retourne un succès si et seulement si l'identifiant d'utilisateur réel du processus appelant est 0. Ceci est utile pour les services non basés sur le réseau tel que man:su[1] ou man:passwd[1] où l'utilisateur `root` doit avoir un accès automatique. [[pam-modules-securetty]] === man:pam_securetty[8] Le module man:pam_securetty[8] [[pam-modules-self]] === man:pam_self[8] Le module man:pam_self[8] retourne un succès si et seulement si le nom du demandeur correspond au nom du compte désiré. Il est utile pour les services non basés sur le réseau tel que man:su[1] où l'identité du demandeur peut être vérifiée facilement . [[pam-modules-ssh]] === man:pam_ssh[8] Le module man:pam_ssh[8] [[pam-modules-tacplus]] === man:pam_tacplus[8] Le module man:pam_tacplus[8] [[pam-modules-unix]] === man:pam_unix[8] Le module man:pam_unix[8] implémente l'authentification Unix traditionnelle par mot de passe, il utilise man:getpwnam[3] pour obtenir le mot de passe du compte visé et le compare avec celui fournit par le demandeur. Il fournit aussi des services de gestion de compte (désactivation du compte et date d'expiration) ainsi que des services pour le changement de mot de passe. Il s'agit certainement du module le plus utile car la plupart des administrateurs désirent garder le comportement historique pour quelques services. [[pam-appl-prog]] == Programmation d'applications PAM Cette section n'a pas encore été écrite. [[pam-module-prog]] == Programmation de modules PAM Cette section n'a pas été encore écrite. :sectnums!: [appendix] [[pam-sample-appl]] == Exemples d'application PAM Ce qui suit est une implémentation minimale de man:su[1] en utilisant PAM. Notez qu'elle utilise la fonction de conversation man:openpam_ttyconv[3] spécifique à OpenPAM qui est prototypée dans [.filename]#security/openpam.h#. Si vous désirez construire cette application sur un système utilisant une bibliothèque PAM différente vous devrez fournir votre propre fonction de conversation. Une fonction de conversation robuste est étonnamment difficile à implémenter; celle présentée dans <> est un bon point de départ, mais ne devrait pas être utilisée dans des applications réelles. [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/su.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/su.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/su.c[] +endif::[] .... :sectnums!: [appendix] [[pam-sample-module]] == Exemple d'un module PAM Ce qui suit est une implémentation minimale de man:pam_unix[8] offrant uniquement les services d'authentification. Elle devrait compiler et tourner avec la plupart des implémentations PAM, mais tire parti des extensions d'OpenPAM si elles sont disponibles : notez l'utilisation de man:pam_get_authtok[3] qui simplifie énormément l'affichage de l'invite pour demander le mot de passe à l'utilisateur. [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/pam_unix.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/pam_unix.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/pam_unix.c[] +endif::[] .... :sectnums!: [appendix] [[pam-sample-conv]] == Exemple d'une fonction de conversation PAM La fonction de conversation présentée ci-dessous est une version grandement simplifiée de la fonction man:openpam_ttyconv[3] d'OpenPAM. Elle est pleinement fonctionnelle et devrait donner au lecteur une bonne idée de comment doit se comporter une fonction de conversation, mais elle est trop simple pour une utilisation réelle. Même si vous n'utilisez pas OpenPAM, N'hésitez pas à télécharger le code source et d'adapter man:openpam_ttyconv[3] à vos besoins, nous pensons qu'elle est raisonnablement aussi robuste qu'une fonction de conversation orientée tty peut l'être. [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/converse.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/converse.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/converse.c[] +endif::[] .... :sectnums!: [[pam-further]] == Lectures complémentaires === Publications _link:http://www.sun.com/software/solaris/pam/pam.external.pdf[Rendre les services de connexion indépendants des technologies d'authentification]_. Vipin Samar et Charlie Lai. Sun Microsystems. _link:http://www.opengroup.org/pubs/catalog/p702.htm[X/Open Single Sign-on Preliminary Specification]_. The Open Group. 1-85912-144-6. June 1997. _link:http://www.kernel.org/pub/linux/libs/pam/pre/doc/current-draft.txt[Pluggable Authentication Modules]_. Andrew G. Morgan. 1999-10-06. === Guides utilisateur _link:http://www.sun.com/software/solaris/pam/pam.admin.pdf[Administration de PAM]_. Sun Microsystems. === Page internet liées _link:http://openpam.sourceforge.net/[La page d'OpenPAM]_. Dag-Erling Smørgrav. ThinkSec AS. _link:http://www.kernel.org/pub/linux/libs/pam/[La page de Linux-PAM]_. Andrew G. Morgan. _link:http://wwws.sun.com/software/solaris/pam/[La page de Solaris PAM]_. Sun Microsystems.