diff --git a/fr_FR.ISO8859-1/books/handbook/eresources/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/eresources/chapter.sgml index 626d11f5b1..5fbc221ff8 100644 --- a/fr_FR.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,2031 +1,2039 @@ Ressources sur Internet &trans.a.fonvieille; L'évolution rapide de FreeBSD rend peu pratique le suivi des développements via des supports imprimés. Les supports électroniques sont le meilleur, sinon la plupart du temps le seul, moyen de se tenir au courant des dernières avancées. Comme FreeBSD est un effort basé sur le volontariat, la communauté des utilisateurs sert généralement de “service de support technique”, le courrier électronique et les forums de discussion étant le meilleur moyen de contacter cette communauté. Les points de contact les plus importants avec la communauté des utilisateurs de FreeBSD sont listés ci-dessous. Si vous connaissez d'autres ressources qui n'y figurent pas, communiquez-les s'il vous plaît à la &a.doc; de façon à ce qu'elles soient aussi mentionnées. Listes de diffusion Bien qu'un grand de nombre de développeurs de FreeBSD lisent les forums de discussion, nous ne pouvons vous garantir de réponse en temps et en heure à vos questions (ni même de réponse tout court) si vous ne les postez que sur un des forums comp.unix.bsd.freebsd.*. En adressant vos questions sur la liste de diffusion appropriée vous nous contacterez en même temps qu'un auditoire FreeBSD concentré, ce qui vous garantit invariablement une meilleure (ou tout au moins une plus rapide) réponse. Les chartes d'utilisation pour les différentes listes sont données à la fin de ce document. Lisez-les s'il vous plaît avant de vous inscrire ou d'envoyer du courrier à une liste. La plupart des inscrits à nos listes reçoivent maintenant des centaines de messages en rapport à FreeBSD chaque jour, et en définissant des chartes et des règles d'utilisation, nous essayons de garder assez élevé le rapport signal/bruit sur les listes. Ne pas le faire verrait l'échec des listes de diffusion comme moyen efficace de communication pour le projet. + + Si vous désirez tester votre + capacité à envoyer du courrier aux listes &os;, + envoyez un message de test à la liste + &a.test.name;. Veuillez ne pas envoyer de messages + de test vers une autre liste. + + En cas de doute sur la liste sur laquelle poser une question, lisez Comment obtenir les meilleurs résultats sur la liste de diffusion FreeBSD-questions. Avant de poster sur une liste de diffusion, veuillez apprendre à utiliser au mieux les listes de diffusion, comme par exemple éviter de relancer des discussions qui reviennent régulièrement, en lisant le document (FAQ) sur les questions fréquemment posées au sujet des listes de diffusion. Des archives de toutes les listes de diffusion sont conservées et on peut effectuer des recherches sur le serveur World Wide Web de FreeBSD. Les archives interrogeables par mots-clés offrent un excellent moyen de trouver des réponses aux questions fréquemment posées et devraient être consultées avant de poster une question. Résumé des listes de diffusion Listes générales: les listes suivantes sont des listes générales auxquelles chacun est libre (et encouragé) de s'inscrire: Liste Objet &a.cvsall.name; Toutes les modifications de l'arborescence des sources &a.advocacy.name; Propagande FreeBSD &a.announce.name; Evénements et étapes importantes du projet &a.arch.name; Discussions sur l'architecture et l'implémentation de FreeBSD &a.bugbusters.name; Discussions concernant la maintenance de la base des données des rapports de bogue de FreeBSD et des outils rattachés &a.bugs.name; Rapports de bogue &a.chat.name; Sujets non-techniques en rapport avec la communauté FreeBSD &a.current.name; Discussions concernant l'utilisation de &os.current; &a.isp.name; Pour les fournisseurs d'accès utilisant FreeBSD &a.jobs.name; Emplois et interventions de consultants en rapport avec FreeBSD &a.policy.name; Décisions de la politique de l'équipe de base de FreeBSD. Volume faible, et accès en lecture uniquement &a.questions.name; Questions des utilisateurs et support technique &a.security-notifications.name; Avis de sécurité &a.stable.name; Discussions concernant l'utilisation de &os.stable; &a.test.name; Où envoyer vos messages de test au lieu que dans une des listes réelles Listes techniques: les listes suivantes sont destinées aux discussions techniques. Vous devriez lire la charte d'utilisation pour chaque liste attentivement avant de s'y inscrire ou d'y envoyer du courrier parce qu'il y a des règles fermes quant à leur utilisation et leur contenu. Liste Objet &a.acpi.name; Développement de l'ACPI et de la gestion d'energie &a.afs.name; Portage d'AFS sous FreeBSD &a.aic7xxx.name; Développement de pilotes pour les contrôleurs AIC 7xxx d'&adaptec; &a.alpha.name; Portage de FreeBSD sur les systèmes Alpha &a.amd64.name; Portage de &os; sur les systèmes AMD64 &a.apache.name; Discussion sur les logiciels portés relatifs à Apache &a.arm.name; Portage de FreeBSD sur les processeurs &arm; &a.atm.name; Utilisation de réseaux ATM avec FreeBSD &a.audit.name; Projet d'audit du code source &a.binup.name; Conception et développement du système de mise à jour binaire &a.bluetooth.name; Utilisation de la technologie &bluetooth; sous &os; &a.cluster.name; Utilisation de FreeBSD dans un environnement en grappe &a.cvsweb.name; Maintenance du système CVSweb &a.database.name; Discussions à propos de l'utilisation de bases de données et de leur développement sous FreeBSD &a.doc.name; Création de documents en rapport avec FreeBSD &a.drivers.name; Ecrire des pilotes de périphériques pour &os; &a.eclipse.name; Pour les utilisateurs &os; de l'EDI Eclipse, les outils, les applications clientes et les logiciels portés. &a.embedded.name; Utilisation de &os; dans les applications embarquées &a.eol.name; Entre-aide sur les logiciels relatifs à &os; et qui ne sont plus supportés par le projet &os;. &a.emulation.name; Emulation d'autres systèmes comme Linux/&ms-dos;/&windows; &a.firewire.name; Discussion technique au sujet du &firewire; (iLink, IEEE 1394) sous FreeBSD &a.fs.name; Systèmes de fichiers &a.geom.name; Discussions spécifiques à GEOM et à ses implémentations &a.gnome.name; Portage de GNOME et des applications GNOME &a.hackers.name; Discussions techniques générales &a.hardware.name; Discussion générale à propos du matériel fonctionnant sous FreeBSD &a.i18n.name; Internationalisation de FreeBSD &a.ia32.name; &os; sur la plate-forme IA-32 (&intel; x86) &a.ia64.name; Portage de FreeBSD sur les futurs système &intel; IA64 &a.ipfw.name; Discussion technique concernant le développement du nouveau code du coupe-feu &a.isdn.name; Développeurs ISDN &a.jail.name; Discussion au sujet des environnements &man.jail.8; &a.java.name; Développeurs &java; et personnes portant et les JDKs sous FreeBSD &a.kde.name; Portage de KDE et des applications pour KDE &a.lfs.name; Portage de LFS sous FreeBSD &a.libh.name; Le système d'installation et de logiciel pré-compilé de seconde génération &a.mips.name; Portage de &os; sur &mips; &a.mobile.name; Discussions à propos des ordinateurs portables &a.mozilla.name; Portage de Mozilla sous FreeBSD &a.multimedia.name; Applications multimédia &a.newbus.name; Discussions techniques au sujet de l'architecture de bus &a.net.name; Discussion au sujet des réseaux et du code source TCP/IP &a.openoffice.name; Portage d'OpenOffice.org et de &staroffice; sous FreeBSD &a.performance.name; Questions relatives à l'optimisation pour les installations à charge/performances élevées. &a.perl.name; Maintenance des logiciels portés relatifs à perl &a.pf.name; Discussions et questions concernant le système de coupe-feu packet filter &a.platforms.name; Portages sur des plateformes à architecture non &intel; &a.ports.name; Discussion sur le catalogue des logiciels portés &a.ports-bugs.name; Discussion sur les bogues/PRs des logiciels portés &a.ppc.name; Portage de FreeBSD pour le &powerpc; &a.proliant.name; Discussion technique sur l'utilisation de &os; sur les serveurs HP ProLiant &a.python.name; Problèmes concernant l'utilisation de Python sous &os; &a.qa.name; Discussion sur la qualité de FreeBSD, généralement entre deux versions &a.rc.name; Discussion relative au système rc.d et à son développement &a.realtime.name; Développement des extensions temps réel de FreeBSD &a.scsi.name; Sous-système SCSI &a.security.name; Questions concernant la sécurité &a.small.name; Utilisation de FreeBSD dans les applications embarquées (obsolète, utilisez &a.embedded.name; à la place) &a.smp.name; Discussions sur la conception du traitement symétrique multiprocesseurs &a.sparc.name; Portage de FreeBSD sur les systèmes &sparc; &a.standards.name; Conformité de FreeBSD aux normes C99 et &posix; &a.sun4v.name; Portage de &os; sur les systèmes basés sur &ultrasparc; T1 &a.threads.name; Threading sous &os; &a.testing.name; Tests de stabilité et de performance de &os; &a.tokenring.name; Support du Token Ring sous FreeBSD &a.x11.name; Support et maintenance de X11 sous &os; &a.usb.name; Discussion sur le support USB sous &os; &a.vuxml.name; Discussion sur l'infrastructure VuXML &a.x11.name; Maintenance and support of X11 on FreeBSD Liste à accès restreint: les listes suivantes sont pour les assistances plus spécialisées (et exigeantes) et ne sont probablement pas d'intérêt général. C'est aussi une bonne idée d'être d'abord actif sur les listes techniques avant de vous inscrire à une de ces listes limités de sorte que vous compreniez l'étiquette impliquée dans ces communications. Liste Objet &a.hubs.name; Pour ceux qui gèrent des sites miroir (questions d'infrastructure) &a.usergroups.name; Coordination des groupes d'utilisateurs &a.vendors.name; Coordination des fournisseurs des pré-versions &a.www.name; Webmestres de www.FreeBSD.org Résumé de liste: Toutes les listes ci-dessus sont également disponibles sous forme de résumé. Une fois inscrit à une liste, vous pouvez modifier vos options de résumé dans les options de votre compte. Listes CVS lists: Les listes suivantes sont destinées aux personnes intéressées par la lecture des journaux des modifications effectuées sur les différentes partie de l'arborescence des sources. Ce sont des listes à lecture seule et on ne devrait pas y envoyer de messages. Liste Partie de l'arborescence des sources Description de la partie (des sources concernées) &a.cvsall.name; /usr/(CVSROOT|doc|ports|projects|src) Toute modification de l'arborescence (agrégation de l'ensemble des listes CVS) &a.cvs-doc.name; /usr/(doc|www) Toutes les modifications effectuées sur les arborescences doc et www &a.cvs-ports.name; /usr/ports Toutes les modifications effectuées sur l'arborescence des logiciels portés &a.cvs-projects.name; /usr/projects Toutes les modifications effectuées sur l'arborescence des projets &a.cvs-src.name; /usr/src Toutes les modifications effectuées sur l'arborescence des sources Comment s'inscrire Pour s'inscrire à une liste, cliquez sur le nom d'une liste ci-dessus où sur &a.mailman.lists.link; et cliquez ensuite sur la liste qui vous intéresse. La page de la liste devrait contenir toutes les instructions nécessaires à l'inscription. Pour poster réellement sur une liste, envoyez simplement un courrier électronique à l'adresse nom-de-la-liste@FreeBSD.org. Ce courrier sera alors redistribué à l'ensemble des membres de la liste de par le monde. Pour vous désabonner d'une liste, cliquez sur l'URL se trouvant à la fin de chaque message reçu de la liste. Il est également possible d'envoyer un message à nom-de-la-liste-unsubscribe@FreeBSD.org pour vous désabonner. Encore une fois, nous voudrions vous demander de garder aux discussions sur les listes techniques leur caractère technique. Si vous n'êtes intéressés uniquement que par les annonces importantes alors nous vous suggérons de vous inscrire à la liste &a.announce;, dont le trafic n'est qu'occasionnel. Chartes d'utilisation des listes Il y a pour toutes les listes de diffusion FreeBSD des règles de base auxquelles tous leurs utilisateurs doivent se conformer. En cas de non respect de ces règles, et après deux (2) avertissements écrits de la part du “Postmaster” de FreeBSD postmaster@FreeBSD.org, au troisième manquement, le contrevenant sera désabonné de toutes les listes de diffusion de FreeBSD, et ses messages ultérieurs filtrés. Nous regrettons de devoir prendre de telles mesures, mais l'Internet d'aujourd'hui est un milieu relativement hostile, et beaucoup ne se rendent pas compte de la fragilité de certains de ses mécanismes. Règles générales: Le sujet de tout message doit correspondre au sujet traité par la liste à laquelle il est adressé, e.g., si c'est une liste concernant des problèmes techniques alors le contenu de votre message doit être technique. Le bavardage continu et les polémiques ne font que dégrader la qualité de la liste de diffusion pour tous les utilisateurs et ne seront pas tolérés. Pour des discussions libres sans sujet particulier, la &a.chat; est disponible et devrait être utilisée dans ce cas. Aucun message ne doit être adressé à plus de 2 listes de diffusion, et à 2 listes uniquement dans le cas où il y a une nécessité évidente de poster sur les deux listes. Pour la plupart des listes, il y a déjà beaucoup de souscripteurs communs, et mis à part les cas les plus ésotériques (par exemple “-stable & -scsi”), il n'y a pas vraiment de raison de poster sur plus d'une liste à la fois. Si vous recevez un message où apparaissent sur la ligne Cc plusieurs listes de diffusion, vous devez purger cette ligne Cc avant d'y répondre. Vous êtes toujours responsable de vos expéditions croisées, peu importe qui en a été à l'origine. Les attaques personnelles et les insultes (dans le cadre d'une discussion) ne sont pas autorisés, et cela concerne tout autant les utilisateurs que les développeurs. Les manquements grossiers à la “nétiquette”, citer ou reposter des courriers privés quand l'accord n'en a pas été donné et ne le sera pas, par exemple, sont désapprouvés, mais pas particulièrement réprimés. Cependant de tels contenus entrent rarement dans le cadre des règles d'utilisation d'une liste, et entraîneront donc probablement un avertissement (ou une exclusion) pour cette seule raison. La publicité pour des produits ou services sans rapport avec FreeBSD est rigoureusement interdite et entraînera l'exclusion immédiate s'il s'avère que le contrevenant adresse ses publicités par “courrier électronique non sollicité” - spam. Chartes liste par liste: &a.acpi.name; Développement de l'ACPI et de la gestion de l'énergie &a.afs.name; Système de fichiers Andrew - Andrew File System C'est une liste de discussion sur le portage et l'utilisation d'AFS de CMU/Transarc. &a.announce.name; Evénements importants / étapes importantes pour le projet C'est une liste pour les gens intéressés uniquement par les annonces occasionnelles d'évènements FreeBSD importants. Cela inclut les annonces d'instantanés et autres versions. Cela comprend également les annonces de nouvelles fonctionnalités de FreeBSD. Il peut y avoir aussi des appels à volontaires, etc... C'est une liste de faible volume et rigoureusement modérée. &a.arch.name; Discussions concernant l'architecture et l'implémentation C'est une liste pour discuter de l'architecture de FreeBSD. Les messages y seront habituellement de nature technique. Des exemples de sujets qui cadrent avec cette liste sont: Comment revoir le système de compilation pour que plusieurs compilations personnalisées puissent être effectuées en même temps. Que faut-il corriger dans VFS pour que les couches Heidemann fonctionnent. Comment modifier l'interface des pilotes de périphériques pour que la même interface fonctionne proprement sur différents bus et architectures. Comment écrire un pilote réseau. &a.audit.name; Projet d'audit du code source C'est la liste de discussion pour le projet d'audit du code source de FreeBSD. Bien que n'étant à l'origine destinée qu'aux modifications relatives à la sécurité, sa charte a été élargie pour l'examen de toute modification de code. Cette liste est très chargée de correctif, et n'est probablement pas intéressant pour l'utilisateur moyen de FreeBSD. Les discussions sur la sécurité non relatives à une modification particulière du code ont lieu sur freebsd-security. Réciproquement, tous les développeurs sont encouragés à envoyer leur correctifs sur la liste pour examen, tout particulièrement s'ils touchent une partie du système où un bogue peut compromettre l'intégrité du système. &a.binup.name; Projet de mise à jour binaire de FreeBSD Cette liste existe pour discuter du système de mise à jour binaire, ou binup. Problèmes de conception, détails d'implémentation, correctifs, rapports de bogue, rapport d'état, demandes de fonctionnalités, traces des modifications du code, et tout ce qui peut avoir rapport avec binup sont à leur place ici. &a.bluetooth.name; &bluetooth; sous &os; C'est un forum où se rassemble les utilisateurs de la technologie &bluetooth; sous &os;. Problèmes de conception, détails de l'implémentation, rapports de bogues, état du support, demande de fonctionnalités, et tous les sujets en rapport avec &bluetooth; sont les bienvenues. &a.bugbusters.name; Coordination de la gestion des rapports de bogue L'objet de cette liste est de servir de forum de coordination et de discussion entre le “Boguemestre”, ses chasseurs de bogues et toute autre partie intéressée dans la base de données des PRs. Cette liste n'est pas destinée aux discussions sur des bogues spécifiques, correctifs ou PRs. &a.bugs.name; Rapports de bogue C'est la liste pour rapporter les bogues de FreeBSD. Chaque fois que c'est possible, les bogues devraient être soumis en utilisant la commande &man.send-pr.1; ou son interface WEB. &a.chat.name; Sujets non-techniques en rapport avec la communauté FreeBSD Cette liste reçoit le résidu des discussions sur les autres listes: informations sociologiques, et non techniques. Cela va de savoir si Jordan ressemble ou non à un furet de bande dessinée, s'il faut tapez en majuscules, qui boit trop de café, quelle est la meilleure bière, qui brasse de la bière dans sa cave, et ainsi de suite. Les annonces occasionnelles d'événements importants (les prochaines fêtes, mariages, naissances, nouveaux emplois, etc...) peuvent être adressées aux listes techniques, mais doivent ensuite être redirigées sur cette liste. &a.core.name; Equipe de base de FreeBSD C'est une liste interne à l'usage des membres de l'équipe de base. Des messages peuvent y être adressés lorsqu'un sujet en rapport avec FreeBSD demande arbitrage ou examen à haut niveau. &a.current.name; Discussions concernant l'utilisation de &os.current; C'est la liste de diffusion pour les utilisateurs de &os.current;. Elle inclut avertissements au sujet de nouvelles fonctionnalités de -CURRENT qui affecteront les utilisateurs, et les instructions sur ce qu'il faut faire pour rester à jour avec -CURRENT. Tous les utilisateurs de “CURRENT” doivent s'inscrire à cette liste. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.cvsweb.name; Project CVSweb de FreeBSD Discussions techniques au sujet de l'utilisation, du développement et de la maintenance du FreeBSD-CVSweb. &a.doc.name; Project de documentation C'est la liste de discussion sur les questions et projets liés à la rédaction de documentation pour FreeBSD. Les membres de cette liste sont collectivement appelés “Le Projet de Documentation de FreeBSD” - The FreeBSD Documentation Project. C'est une liste ouverte; n'hésitez pas à vous inscrire et à participer! &a.drivers.name; Ecrire des pilotes de périphériques pour &os; C'est une liste pour les discussions techniques au sujet des pilotes de périphériques sous &os;. C'est principalement un lieu où les personnes écrivant les pilotes peuvent poser des questions sur l'écriture de pilotes utilisant les APIs du noyau &os;. &a.eclipse.name; Pour les utilisateurs &os; de l'EDI Eclipse, les outils, les applications clientes et les logiciels portés. L'objectif de cette liste est de fournir un support pour tout que qui concerne le choix, l'installation, l'utilisation, le développement et la maintenance de l'EDI Eclipse, des ses outils, de ses applications clients sous &os; et l'aide au portage de l'EDI Eclipse et de ses greffons sous l'environnement &os;. Le but est également de faciliter les échanges d'information entre les communautés Eclipse et &os; pour un bénéfice mutuel. Bien que cette liste soit principalement destinée à répondre aux demandes des utilisateurs d'Eclipse, elle est également un forum pour ceux qui désirent développer des applications spécifiques à &os; en utilisant le système Eclipse. &a.embedded.name; Utilisation de &os; dans les applications embarquées Cette liste aborde les sujets relatifs à l'utilisation de &os; dans les systèmes embarqués. C'est une liste de diffusion à caractère technique pour laquelle on attend un contenu strictement technique. Dans le cadre de cette liste, nous définissons le terme de système embarqué pour les appareils informatisés qui ne sont pas des stations de travail et qui sont destinés à une application bien particulière et limitée par opposition aux systèmes informatiques classiques. Des exemples de systèmes embarqués, parmi tant d'autres, sont les combinés téléphoniques, les équipements réseau comme les routeurs, les commutateurs et les PABXs, les équipements de mesure à distance, les PDAs, les systèmes de distributeurs, et ainsi de suite. &a.emulation.name; Emulation d'autres systèmes comme Linux/&ms-dos;/&windows; C'est une liste pour les discussions techniques relativent à l'exécution sous &os; de programmes écris pour d'autres systèmes d'exploitation. &a.eol.name; Entre-aide sur les logiciels relatifs à &os; et qui ne sont plus supportés par le projet &os;. Cette liste est destinée aux personnes désirant proposer ou recherchant une aide pour les logiciels relatifs à &os; pour lesquels le projet &os; ne fournir officiellement plus de support (par exemple sous la forme d'avis de sécutité et de correctifs). &a.firewire.name; &firewire; (iLink, IEEE 1394) C'est une liste pour les discussions sur la conception et le développement d'un sous-système &firewire; (IEEE 1394, iLink) sous FreeBSD. Les sujets appropriés incluent spécifiquement les normes, les bus périphériques et leur protocole, l'ensemble d'adaptateurs/cartes/circuits, et l'architecture et l'implémentation de leur propre support. &a.fs.name; Systèmes de fichiers Discussions concernant les systèmes de fichiers FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.geom.name; GEOM Discussions spécifiques à GEOM et aux implémentations relatives. C'est une liste de diffusion technique sur laquelle le contenu doit être strictement technique. &a.gnome.name; GNOME Discussions concernant l'environnement de travail GNOME sous les systèmes FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.ipfw.name; Coupe-feu IP C'est le forum pour les discussions techniques concernant la nouvelle implémentation du code du coupe-feu IP sous FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.ia64.name; Portage de FreeBSD sur IA64 C'est une liste de discussion technique pour les personnes travaillant sur le portage de FreeBSD sur la plate-forme IA-64 d'&intel;, pour soulever les problèmes ou discuter de solutions alternatives. Ceux qui sont intéressés à suivre les discussions techniques sont aussi bienvenus. &a.isdn.name; Communications ISDN C'est la liste pour les personnes discutant du développement du support ISDN de FreeBSD. &a.java.name; Développement &java; C'est la liste pour les personnes discutant du développement d'applications &java; significatives sous FreeBSD et du portage et de la maintenance des &jdk;s. &a.jobs.name; Recherches et offres d'emplois C'est un forum pour poster des offres d'emplois et des curriculum vitae relatifs à &os;, c'est à dire si vous cherchez un emploi concernant &os; ou que vous offrez un emploi impliquant &os;, alors c'est le bon endroit. Ce n'est pas une liste de diffusion pour les problèmes généraux relatifs aux offres et à la recherche d'un emploi puisque des forums adéquats existent déjà par ailleurs. Notez que cette liste, comme les autres listes de diffusion du domaine FreeBSD.org, est diffusée au niveau mondial. Par conséquent, vous devez être précis quant à l'emplacement, les possibilités de travail à distance ou de déplacement. Les messages devraient utiliser uniquement des formats ouverts — de préférence du texte brut, mais le PDF, l'HTML, et quelques autres formats sont acceptables. Les formats propriétaires comme µsoft; Word (.doc) seront rejetés par le serveur de la liste de diffusion. &a.kde.name; KDE Discussions concernant KDE sous les systèmes &os;. C'est une liste de discussion technique sur laquelle le contenu doit rester strictement technique. &a.hackers.name; Discussions techniques C'est le forum pour les discussions techniques au sujet de FreeBSD. C'est la principale liste technique. Elle est destinée à ceux qui travaillent activement à FreeBSD, pour soulever des problèmes et discuter de solutions alternatives. Ceux qui sont intéressés à suivre les discussions techniques sont aussi bienvenus. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.hardware.name; Discussions générales sur le matériel pour FreeBSD Discussions générales sur les types de matériel sur lesquels tourne FreeBSD, les problèmes rencontrés et suggestions sur quoi acheter ou éviter. &a.hubs.name; Sites miroir Annonces et discussions pour les personnes qui font fonctionner les sites miroir FreeBSD. &a.isp.name; Questions concernant les fournisseurs d'accès à Internet C'est la liste pour discuter des sujets qui intéressent les fournisseurs d'accès Internet - Internet Service Providers (ISPs) - qui utilisent FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.openoffice.name; OpenOffice.org Discussions concernant le portage et la maintenance d'OpenOffice.org et &staroffice;. &a.performance.name; Discussions au sujet de l'optimisation et l'accélération de la vitesse d'exécution de &os; Cette liste de diffusion existe pour offrir un endroit aux hackers, administrateurs, et/ou les parties concernées pour discuter de sujets ayant trait aux performances de &os;. Les sujets acceptables comprennent les discussions concernant les installations de &os; qui sont soit sous charge importante, soit présentant des problèmes de performance, ou encore qui repoussent les limites de &os;. Les personnes désirant travailler sur l'amélioration des performances de &os; sont grandement encouragées à s'inscrire à cette liste. C'est une liste hautement technique destinée aux utilisateurs expérimentés de &os;, aux hackers, ou aux administrateurs intéressés par un &os; rapide, robuste, et adaptable. Ce n'est pas une liste de questions-réponses qui remplace la lecture de la documentation, mais c'est un endroit où il est possible d'effectuer des contributions ou de se préoccuper de sujets non-résolus relatifs aux performances. &a.pf.name; Discussions et questions concernant le système de coupe-feu packet filter Discussions concernant le système de coupe-feu packet filter (pf) sous &os;. Les discussions techniques ainsi que les questions des utilisateurs sont les bienvenues. Cette liste est également un endroit où discuter du système de qualité de service ALTQ. &a.platforms.name; Portage sur les plate-formes non &intel; Questions concernant le support d'autres plates-formes, discussions générales et propositions pour les portages sur des plates-formes non &intel;. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.policy.name; Décisions de la politique de l'équipe de base C'est une liste de discussion à faible trafic, et en lecture seule pour les décisions de la politique de l'équipe de base. &a.ports.name; Discussion sur les “logiciels portés” Discussions concernant le ``catalogue des logiciels portés'' de FreeBSD (/usr/ports), propositions de portages, modifications de l'infrastructure du catalogue des logiciels portés et coordination générale. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.proliant.name; Discussion technique sur l'utilisation de &os; sur les serveurs HP ProLiant Cette liste de diffusion doit être utilisée pour les discussions techniques concernant l'utilisation de &os; sur les serveurs HP ProLiant, y compris les discussions sur les pilotes spécifiques à ces machines, les logiciels de gestion, les outils de configuration, et les mises à jour du BIOS. C'est également le premier endroit où discuter des modules hpasmd, hpasmcli, et hpacucli. &a.python.name; Python sous &os; C'est une liste pour les discussions relatives à l'amélioration du support de Python sous &os;. C'est une liste de discussion technique. Elle est destinée aux personnes travaillant sur le portage de Python, de ses modules tiers partie et éléments relatifs à Zope sous &os;. Les personnes intéressées par ces discussions techniques sont également les bienvenues. &a.questions.name; Questions des utilisateurs C'est la liste pour les questions à propos de FreeBSD. Vous ne devriez pas adresser de questions du type “comment faire” aux listes techniques à moins que vous n'estimiez que la question soit vraiment très technique. &a.scsi.name; Sous-système SCSI C'est la liste de diffusion pour ceux qui travaillent sur le sous-système SCSI de FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.security.name; Questions relatives à la sécurité Questions ayant trait à la sécurité des ordinateurs sous FreeBSD (DES, Kerberos, trous de sécurité connus et correctifs, etc...). C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. Notez que ce n'est pas une liste de question-réponse, mais ce type de contribution (la question ET la réponse) à la FAQ est le bienvenue. &a.security-notifications.name; Avis de sécurité Notifications des problèmes de sécurité concernant FreeBSD et correctifs. Ce n'est pas une liste de discussion. La liste de discussion correspondante est FreeBSD-security. &a.small.name; Utilisation de FreeBSD dans les applications embarquées Cette liste discute de sujets relatifs aux installations inhabituellement petites et embarquées de FreeBSD. C'est une liste de discussion technique sur laquelle un contenu strictement technique est attendu. Cette liste est obsolète depuis la création de &a.embedded.name;. &a.stable.name; Discussions concernant l'utilisation de &os.stable; C'est la liste de diffusion pour les utilisateurs de &os.stable;. Elle inclut avertissements au sujet de nouvelles fonctionnalités de -STABLE qui affecteront les utilisateurs, et des instructions sur ce qu'il faut faire pour rester à jour avec -STABLE. Tous les utilisateurs de la branche “STABLE” devraient s'inscrire à cette liste. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.standards.name; Conformité aux normes C99 & POSIX C'est un forum pour les discussions techniques concernant la conformité de FreeBSD aux normes C99 et POSIX. &a.usb.name; Discussion sur le support USB sous &os; C'est une liste de diffusion pour les discussions techniques relatives au support de l'USB sous &os; &a.usergroups.name; Coordination des groupes d'utilisateurs C'est la liste pour les coordinateurs des différents groupes locaux d'utilisateurs, destinée à leurs discussions entre eux et avec un membre désigné de l'équipe de base. Cette liste doit se limiter aux comptes-rendus de réunions et à la coordination de projets entre plusieurs groupes d'utilisateurs. &a.vendors.name; Fournisseurs Coordination des discussions entre le projet FreeBSD et les fournisseurs de logiciel ou de matériel pour FreeBSD. Filtrages en vigueur sur les listes de diffusion Les listes de diffusion &os; sont filtrées de plusieurs façons en vue d'éviter la distribution de SPAM, de virus, et tout autre message non-sollicité. Les opérations de filtrage décries dans cette section ne comprennent pas toutes celles utilisées pour protéger les listes re diffusion. Seuls certains types de pièces jointes sont autorisés sur les listes de diffusion. Toutes les pièces jointes avec un format MIME qui ne figurent pas parmi la liste ci-dessous seront retirées avant que le message ne soit distribué sur les listes de diffusion. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Certaines listes de diffusion pourront autoriser des pièces jointes sous d'autres formats MIME, mais la liste précédente devrait être applicable pour la plupart des listes de diffusion. Si un message contient une version HTML et une version texte du contenu du message, la version HTML sera retirée. Si le corps d'un message est uniquement sous forme HTML, il sera converti sous forme texte brut. Forums de discussion En plus de deux forums de discussion spécifiques à FreeBSD, il y en a de nombreux autres où il est question de FreeBSD ou qui sont par ailleurs d'intérêt pour les utilisateurs de FreeBSD. Des archives interrogeables par mots-clés sont disponibles pour certains de ces forums, grâce à Warren Toomey wkt@cs.adfa.edu.au. Forums spécifiques à BSD comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (Allemand) fr.comp.os.bsd (Français) it.comp.os.freebsd (Italien) tw.bbs.comp.386bsd (Chinois) Autres forums &unix; intéressants comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd Système X Window comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine Serveurs World Wide Web &chap.eresources.www.inc; Adresses électroniques Les groupes d'utilisateurs suivants fournissent à leurs membres des adresses électroniques liées à FreeBSD. Les administrateurs cités se réservent le droit de supprimer l'adresse si elle est à l'origine d'abus. Domaine Possibilités offertes Groupe d'utilisateurs Administrateur ukug.uk.FreeBSD.org Transmission de courrier uniquement freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Comptes Les groupes d'utilisateurs suivants fournissent des comptes aux personnes supportant le projet FreeBSD. Les administrateurs cités se réservent le droit de supprimer le compte s'il est à l'origine d'abus. Hôte Accès Possibilités offertes Administrateur dogma.freebsd-uk.eu.org Telnet/FTP/SSH Adresse électronique, espace Web, FTP anonyme Lee Johnston lee@uk.FreeBSD.org diff --git a/fr_FR.ISO8859-1/books/handbook/introduction/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/introduction/chapter.sgml index f82c0630ef..5faeb72446 100644 --- a/fr_FR.ISO8859-1/books/handbook/introduction/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/introduction/chapter.sgml @@ -1,1054 +1,1058 @@ Jim Mock Restructuré, réorganisé, et parties réécrites par Introduction &trans.a.fonvieille; Synopsis Merci de votre intérêt pour FreeBSD! Le chapitre suivant traite de divers aspects concernant le projet FreeBSD, comme son histoire, ses objectifs, son mode de développement, et d'autres. Après la lecture de ce chapitre, vous connaîtrez: Comment FreeBSD est lié aux autres systèmes d'exploitation. L'histoire du Projet FreeBSD. Les objectifs du Projet FreeBSD. Les bases du mode de développement open-source de FreeBSD. Et bien sûr: l'origine du nom “FreeBSD”. Bienvenue à FreeBSD! 4.4BSD-Lite FreeBSD est une système d'exploitation basé sur 4.4BSD-Lite2 pour les ordinateurs à base d'architecture Intel (x86 et &itanium;), AMD64, les ordinateurs DEC Alpha, et Sun &ultrasparc;. Le portage pour d'autres architectures est également en cours. Pour connaître l'histoire du projet, lisez Un court historique de FreeBSD. Pour avoir une description de la version la plus récente, allez à la section A propos de cette version. Si vous voulez contribuer d'une façon ou d'une autre au projet FreeBSD (code, matériel, - chèques en blanc), voyez s'il vous plaît à la + dons), voyez s'il vous plaît à la section Contribuer à FreeBSD. Que peut faire FreeBSD? FreeBSD dispose de nombreuses caractéristiques remarquables. Parmi lesquelles: multi-tâche préemptif Multi-tâche préemptif avec ajustement dynamique des priorités pour garantir un partage équilibré et fluide de l'ordinateur entre les applications et les utilisateurs et cela même sous les charges les plus importantes. accès multi-utilisateurs Accès multi-utilisateurs qui permet à de nombreuses personnes d'utiliser en même temps un système FreeBSD à des fins très différentes. Cela signifie, par exemple, que des périphériques tels que les imprimantes ou les lecteurs de bandes peuvent être partagés entre tous les utilisateurs sur le système ou sur le réseau et que des limitations d'utilisation des ressources peuvent être appliquées à des utilisateurs ou groupes d'utilisateurs, protégeant ainsi les ressources systèmes critiques d'une sur-utilisation. Réseau TCP/IP Réseau TCP/IP complet dont le support de standards industriels comme SCTP, DHCP, NFS, - NIS, PPP et SLIP. Cela signifie que votre machine FreeBSD peut + NIS, PPP, SLIP, IPsec, et IPv6. Cela signifie que votre machine FreeBSD peut coopérer facilement avec d'autres systèmes ou être utilisée comme serveur d'entreprise, fournissant des fonctions essentielles comme NFS (accès aux fichiers en réseau) et le service de courrier électronique, ou encore l'accès de votre entreprise à l'Internet grâce aux services WWW, FTP, et aux fonctionnalités de routage et de coupe-feu (sécurité). protection de la mémoire La protection de la mémoire garantit que les applications (ou les utilisateurs) ne peuvent interférer entre eux. Une application qui plante n'affectera en rien les autres. FreeBSD est un système d'exploitation 32-bits (64-bits sur l'architecture Alpha, &itanium;, AMD64, et &ultrasparc;) et a été conçu comme tel dès le début. système X Window XFree86 - Le Système X Window (X11R6), + Le Système X Window (X11R7), standard industriel, fournit une interface graphique à l'utilisateur (Graphical User Interface - GUI), moyennant l'achat d'une carte VGA ordinaire et d'un moniteur, et est livré avec l'intégralité de son code source. Compatibilité binaire Linux Compatibilité binaire SCO Compatibilité binaire SVR4 Compatibilité binaire BSD/OS Compatibilité binaire NetBSD Compatibilité binaire avec de nombreux programmes compilés pour Linux, SCO, SVR4, BSDI et NetBSD. Des milliers d'applications prêtes à l'emploi sont disponibles grâce au catalogue des logiciels portés (ports) et au catalogue des logiciels pré-compilés (packages). Pourquoi chercher sur l'Internet alors que tout est là?. Des milliers d'applications faciles à porter sont disponibles sur l'Internet. FreeBSD est compatible au niveau du code source avec les systèmes &unix; commerciaux les plus répandus et donc la plupart des applications exigent peu, sinon aucune modification, pour les compiler. mémoire virtuelle Mémoire virtuelle à la demande et “cache unifié pour les disques et la mémoire virtuelle” cela permet de répondre aux besoins des applications gourmandes en mémoire tout en garantissant le temps de réponse aux autres utilisateurs. Traitement symétrique multiprocesseurs (SMP) Support du traitement symétrique multiprocesseurs (SMP). compilateurs C compilateurs C++ compilateurs Fortran Des outils complets de développement C, C++, et Fortran. De nombreux autres langages pour la recherche de pointe et le développement sont aussi disponibles dans les catalogues des logiciels portés et pré-compilés. code source La disponibilité Code source de l'intégralité du système vous donne un contrôle total sur votre environnement. Pourquoi être prisonnier d'une solution propriétaire et dépendant de votre fournisseur alors que vous pouvez avoir un véritable système ouvert? Une documentation en ligne très complète. Et beaucoup d'autres choses encore! 4.4BSD-Lite Computer Systems Research Group (CSRG) U.C. Berkeley FreeBSD est basé sur la version 4.4BSD-Lite2 du “Computer Systems Research Group” (CSRG) de l'Université de Californie à Berkeley et continue la tradition de développement renommée des systèmes BSD. En plus de l'excellent travail fourni par le CSRG, le Projet FreeBSD a investi des milliers d'heures de travail pour optimiser le système pour arriver aux meilleures performances et au maximum de fiabilité sous la charge d'un environnement de production. Alors que la plupart des géants dans le domaine des systèmes d'exploitation pour PC s'acharnent encore à obtenir de telles possibilités, performances et fiabilité, FreeBSD peut les offrir dès maintenant! La seule limite aux domaines d'application auxquels FreeBSD peut satisfaire est votre propre imagination. Du développement de logiciels à la production robotisée, de la gestion de stocks à la correction d'azimut pour les antennes satellites; si un &unix; commercial peut le faire, il y a de très fortes chances que FreeBSD le puisse aussi! FreeBSD bénéficie aussi de centaines d'applications de haute qualité développées par les centres de recherche et les universités du monde entier, souvent disponibles gratuitement ou presque. Il existe aussi des applications commerciales et leur nombre croît de jour en jour. Comme le code source de FreeBSD lui-même est globalement disponible, le système peut aussi être adapté sur mesure à un point pratiquement jamais atteint pour des applications ou des projets particuliers, d'une façon qui serait habituellement impossible avec les systèmes d'exploitation commerciaux de la plupart des principaux fournisseurs. Voici juste quelques exemples d'applications pour lesquelles FreeBSD est utilisé: Services Internet: les fonctionnalités réseau TCP/IP robustes qu'inclut FreeBSD en font la plate-forme idéale pour un éventail de services Internet, tels que: serveurs FTP Serveurs FTP serveurs web Serveurs World Wide Web (standard ou sécurisé [SSL]) + + Routage IPv4 et IPv6 + + coupe-feu IP masquerading NAT Coupe-feux et passerelles de traduction d'adresses (“IP masquerading”) email Serveurs de courrier électronique USENET Serveurs de News USENET (forums de discussion) ou Bulletin Board Systems (BBS) Et plus... Avec FreeBSD, vous pouvez facilement commencer petit avec un PC 386 à bas prix et évoluer jusqu'à un quadri-processeurs Xeon avec stockage RAID au fur et à mesure que votre entreprise s'agrandit. Education: Etes-vous étudiant en informatique ou dans un domaine d'ingénierie apparenté? Il n'y a pas de meilleur moyen pour étudier les systèmes d'exploitation, l'architecture des ordinateurs et les réseaux que l'expérience directe et de “derrière la coulisse” que FreeBSD peut vous apporter. Il y a aussi un grand nombre d'outils mathématiques, graphiques et de Conception Assistée par Ordinateur qui en font un outil très utile pour ceux qui s'intéressent aux ordinateurs essentiellement pour faire un autre travail! Recherche: Avec le code source de la totalité du système disponible, FreeBSD est un excellent outil de recherche sur les systèmes d'exploitation tout autant que pour d'autres branches de l'informatique. Le fait que FreeBSD soit librement disponible rend aussi possible l'échange d'idées et le développement partagé entre groupes éloignés sans avoir à se préoccuper de problèmes de licence particulières ou de restrictions à ce qui pourrait être discuté sur des forums ouverts. routeur serveur DNS Réseau: Il vous faut un nouveau routeur? Un serveur de domaine (DNS)? Un coupe-feu pour tenir les gens à l'écart de votre réseau interne? FreeBSD peut facilement faire de votre vieux 386 ou 486 inutilisé qui traîne dans un coin un routeur évolué avec des fonctionnalités sophistiquées de filtrage de paquets. système X Window XFree86 système X Window Accelerated-X Station de travail X Window: FreeBSD est un excellent choix pour faire un terminal X peu coûteux,i en utilisant le serveur X11 librement disponible. Au contraire d'un terminal X, FreeBSD permet d'exécuter localement, si désiré, un grand nombre d'applications, déchargeant ainsi le serveur central. FreeBSD peut même démarrer “sans disque”, ce qui permet de concevoir des postes de travail individuels moins chers et plus faciles à administrer. Compilateur GNU Développement de logiciel: Le système FreeBSD de base inclut un environnement de développement complet dont les compilateur et débogueur GNU C/C++ réputés. FreeBSD est disponible sous forme de code source ou binaire sur CDROM, DVD ou par ftp anonyme, Voyez pour plus de détails. Qui utilise FreeBSD? utilisateurs les sites importants utilisant FreeBSD FreeBSD est utilisé par certains des plus importants sites sur l'Internet, parmi lesquels: Yahoo! Yahoo! Apache Apache Blue Mountain Arts Blue Mountain Arts Pair Networks Pair Networks Sony Japan Sony Japan Netcraft Netcraft Weathernews Weathernews Supervalu Supervalu TELEHOUSE America TELEHOUSE America Sophos Anti-Virus Sophos Anti-Virus JMA Wired JMA Wired et de nombreux autres. A propos du Projet FreeBSD La section suivante fournit des informations générales sur le projet, dont un court historique, les objectifs du projet, et le mode de développement du projet. Jordan Hubbard Contribution de Un court historique de FreeBSD 386BSD Patchkit Hubbard, Jordan Williams, Nate Grimes, Rod Projet FreeBSD historique Le projet FreeBSD a vu le jour au début de 1993, en partie comme extension du “Kit de mise à jour non officiel de 386BSD” des trois derniers coordinateurs du kit de mise à jour : Nate Williams, Rod Grimes et moi-même. 386BSD Notre objectif de départ était de fournir une distribution intermédiaire de 386BSD pour corriger un certain nombre de problèmes que le mécanisme du kit de mise à jour ne permettait pas de résoudre. Certains d'entre vous se rappellent peut-être que l'intitulé de travail d'origine du projet était “386 BSD 0.5” ou “386BSD Interim” en référence à ce problème. Jolitz, Bill 386BSD était le système d'exploitation de Bill Jolitz, qui souffrait assez sévèrement à ce moment-là d'avoir été négligé pendant presque un an. Comme le kit de mise à jour enflait de plus en plus inconfortablement au fil des jours, nous avons décidé à l'unanimité qu'il fallait faire quelque chose et aider Bill en fournissant cette distribution provisoire de “remise à plat”. Ces projets se sont brutalement interrompus lorsque Bill a décidé de retirer son aval au projet sans dire clairement ce qui serait fait à la place. Greenman, David Walnut Creek CDROM Il ne nous a pas fallu longtemps pour décider que l'objectif restait valable, même sans l'adhésion de Bill, et nous avons donc adopté le nom “FreeBSD”, une proposition de David Greenman. Nos objectifs de départ ont été définis après avoir consulté les utilisateurs du moment du système et, dès qu'il est devenu clair que le projet était parti pour devenir un jour éventuellement réalité, nous avons contacté Walnut Creek CDROM dans l'optique d'améliorer la distribution de FreeBSD pour le grand nombre de ceux qui n'avaient pas la chance de pouvoir accéder facilement à l'Internet. Non seulement Walnut Creek CDROM a adopté l'idée de distribuer FreeBSD sur CDROM, mais a été jusqu'à fournir au projet une machine pour travailler et une connexion rapide à l'Internet. Sans le degré pratiquement sans précédent de confiance de Walnut Creek CDROM en ce qui n'était alors qu'un projet totalement inconnu, il y a peu de chance que FreeBSD ait été aussi loin, aussi vite, que là où il en est aujourd'hui. 4.3BSD-Lite Net/2 U.C. Berkeley 386BSD Free Software Foundation La première version sur CDROM (et sur l'ensemble du Net) fut FreeBSD 1.0, parue en Décembre 1993. Elle reposait sur la bande 4.3BSD-Lite (“Net/2”) de l'Université de Californie à Berkeley, avec de nombreux composants venant aussi de 386BSD et de la “Free Software Foundation”. Ce fut un succès honnête pour une version initiale, qui fut suivi par le franc succès de la version 1.1 de FreeBSD, publiée en Mai 1994. Novell U.C. Berkeley Net/2 AT&T A peu près à cette époque, des nuages menaçants et inattendus apparurent lorsque commença la bataille juridique entre Novell et l'U.C. Berkeley autour du statut légal de la bande Net/2 de Berkeley. Dans les termes de l'accord, l'U.C. Berkeley concédait qu'une grande partie de Net/2 était du code “protégé” et propriété de Novell, qui l'avait à son tour racheté à AT&T quelque temps auparavant. Berkeley obtint en retour la “bénédiction” de Novell que 4.4BSD-Lite soit, lorsqu'il vit finalement le jour, déclaré non protégé et que tous les utilisateurs de Net/2 soit fortement incités à migrer. Cela incluait FreeBSD, et l'on donna au projet jusqu'à Juillet 1994 pour mettre un terme à son propre produit basé sur Net/2. Selon les termes de cet accord, une dernière livraison était autorisée avant le délai final; ce fut FreeBSD 1.1.5.1. FreeBSD s'attela alors à la tâche difficile de littéralement se réinventer à partir de fragments totalement nouveaux et assez incomplets de 4.4BSD-Lite. Les versions “Lite” étaient légères (“light”) en partie parce que le CSRG avait retiré de gros morceaux du code nécessaires pour que l'on puisse effectivement en faire un système qui démarre (pour différentes raisons légales) et parce que le portage pour Intel de la version 4.4 était très partiel. Il fallu au projet jusqu'à Novembre 1994 pour terminer cette étape de transition et que FreeBSD 2.0 paraisse sur l'Internet et sur CDROM (fin Décembre). Bien qu'elle fut encore assez rugueuse aux angles, cette livraison obtint un succès significatif et fut suivie par la version 2.0.5 de FreeBSD, plus fiable et facile à installer, en Juin 1995. Nous avons publié FreeBSD 2.1.5 en Août 1996, et il s'avéra suffisamment populaire chez les fournisseurs d'accès et les utilisateurs professionnels pour qu'une nouvelle version sur la branche 2.1-STABLE soit justifiée. Ce fut la version FreeBSD 2.1.7.1, parue en Février 1997 et qui marque la fin de 2.1-STABLE comme branche principale de développement. Dès lors, il n'y aurait plus que des améliorations quant à la sécurité et autres corrections de bogues critiques sur cette branche, (RELENG_2_1_0), passée en phase de maintenance. La branche FreeBSD 2.2 fut créée à partir de la branche principale de développement (“-CURRENT”) en Novembre 1996 en tant que branche RELENG_2_2, et la première version complète (2.2.1) parut en Avril 1997. Il y eut d'autres versions sur la branche 2.2 à l'été et à l'automne 97, la dernière (2.2.8) parut en Novembre 1998. La première version officielle 3.0 sortira en Octobre 1998 et annoncera le début de la fin pour la branche 2.2. Il y eut la création de nouvelles branches le 20 Janvier 1999, donnant une branche 4.0-CURRENT et une branche 3.X-STABLE. De cette dernière il y eut la version 3.1 livrée le 15 Février 1999, la version 3.2 livrée le 15 Mai 1999, la 3.3 le 16 Septembre 1999, la 3.4 le 20 Décembre 1999 et la 3.5 le 24 Juin 2000, qui fut suivit quelques jours plus tard par une mise à jour mineure 3.5.1 pour rajouter quelques correctifs de sécurité de dernière minute sur Kerberos. Cela sera la dernière version de la la branche 3.X à paraître. Le 13 Mars 2000 a vu l'apparition d'une nouvelle branche: la branche 4.X-STABLE. Il y a eu plusieurs versions jusqu'ici: la 4.0-RELEASE est sortie en Mars 2000, et la dernière version, la 4.11-RELEASE est sortie en Janvier 2005. La tant attendue 5.0-RELEASE a été annoncée le 19 Janvier 2003. Etant le point culminant de près de trois ans de travail, cette version a engagé &os; sur la voie d'un support avancé des systèmes multiprocesseurs et des “threads”, et a introduit le support des plateformes &ultrasparc; et ia64. Cette version fut suivie de la 5.1 en Juin 2003. La dernier version 5.X issue de la branche -CURRENT fut la 5.2.1-RELEASE présentée en Février 2004. La branche RELENG_5 créée en Août 2004, suivie par la 5.3-RELEASE, marque le début de la branche 5-STABLE. La version la plus récente, la &rel2.current;-RELEASE, est sortie en &rel2.current.date;. Il n'est pas prévu de publier d'autres versions de la branche RELENG_5. La branche RELENG_6 a été créée en Juillet 2005. La version 6.0-RELEASE, la première version issue de la branche 6.X a été rendue publique en Novembre 2005. La version la plus récente, la &rel.current;-RELEASE, est sortie en &rel.current.date;. De nouvelles versions sont prévues pour la branche RELENG_6. Pour le moment, les projets de développement à long terme continuent à se faire dans la branche (tronc) 7.X-CURRENT, et des “instantanées” de la 7.X sur CDROM (et, bien sûr, sur le net) sont continuellement mises à disposition sur le serveur d'instantané pendant l'avancement des travaux. Jordan Hubbard Contribution de Les objectifs du projet FreeBSD Projet FreeBSD objectifs L'objectif du projet FreeBSD est de fournir du logiciel qui puisse être utilisé à n'importe quelle fin et sans aucune restriction. Nombre d'entre nous sont impliqués de façon significative dans le code (et dans le projet) et ne refuseraient certainement pas une petite compensation financière de temps à autre, mais ce n'est certainement pas dans nos intentions d'insister là dessus. Nous croyons que notre première et principale “mission” est de fournir du code à tout le monde, pour n'importe quel projet, de façon à ce qu'il soit utilisé le plus possible et avec le maximum d'avantages. C'est, nous le pensons, l'un des objectifs les plus fondamentaux du Logiciel Libre et l'un de ceux que nous soutenons avec enthousiasme. GNU General Public License (GPL) GNU Lesser General Public License (LGPL) BSD Copyright Le code de l'arborescence des sources, qui est régi par la Licence Publique GNU (“GNU Public License” - GPL) ou la Licence Publique GNU pour les Bibliothèques (“GNU Library Public License” - GLPL) impose légèrement plus de contraintes, bien que plutôt liées à une disponibilité plus grande qu'au contraire, comme c'est généralement le cas. En raison des complications supplémentaires qui peuvent résulter de l'utilisation commerciale de logiciels GPL, nous essayons, cependant de remplacer ces derniers par des logiciels soumis à la licence BSD qui est plus souple, chaque fois que c'est possible. Satoshi Asami Contribution de Le mode de développement de FreeBSD Projet FreeBSD mode de développement Le développement de FreeBSD est un processus très ouvert et très souple, c'est littéralement le résultat de contributions de centaines de personnes dans le monde entier, ce que reflète notre liste des participants. L'infrastructure de développement de &os; permet à ces centaines de développeurs de collaborer via l'Internet. Nous sommes toujours à l'affût de nouveaux développeurs et de nouvelles idées, et ceux que s'impliquer de plus près intéresse n'ont besoin que de contacter la &a.hackers;. La &a.announce; est aussi disponible pour ceux qui veulent faire connaître aux autres utilisateurs de FreeBSD les principaux domaines de développement en cours. Quelques points utiles à connaître à propos du projet FreeBSD et de son processus de développement, que vous travailliez indépendamment ou en collaboration étroite: Les archives CVS CVS archives Concurrent Versions System CVS L'arborescence centrale des sources de FreeBSD est gérée sous CVS (Concurrent Version System), un système librement disponible de gestion de version des sources qui est livré avec FreeBSD. Les archives CVS principales sont sur une machine à Santa Clara CA, USA, d'où elles sont répliquées sur de nombreuses machines miroir à travers le monde. L'arborescence CVS qui contient les branches -CURRENT et -STABLE peut facilement être dupliquée sur votre propre machine. Reportez-vous à la section Synchroniser votre arborescence des sources pour plus d'informations sur la façon de procéder. La liste des personnes autorisées, les “committers” personnes autorisées, “committers” Les personnes autorisées (committers) sont celles qui ont les droits en écriture sur l'arborescence CVS, et sont autorisées à faire des modifications dans les sources de FreeBSD (le terme “committer” vient de la commande &man.cvs.1; commit, que l'on utilise pour reporter des modifications dans les archives CVS). La meilleure façon de proposer des modifications pour qu'elles soient validées par les “committers” est d'utiliser la commande &man.send-pr.1;. S'il semble y avoir un problème dans ce système, vous pouvez aussi les joindre en envoyant un courrier électronique à &a.committers;. L'équipe de base de FreeBSD équipe de base de FreeBSD L'équipe de base de FreeBSD serait l'équivalent du comité de direction si le Projet FreeBSD était une entreprise. La responsabilité principale de l'équipe de base est de s'assurer que le projet, dans son ensemble, fonctionne correctement et va dans la bonne direction. Proposer à des développeurs impliqués et responsables de rejoindre notre groupe de personnes autorisées est une des fonctions de l'équipe de base, ainsi que le recrutement de nouveaux membres de l'équipe de base quand d'autres s'en vont. L'actuelle équipe de base a été élu à partir d'un ensemble de “committers” candidats en Juillet 2006. Des élections ont lieu tous les 2 ans. Certains membres de l'équipe de base ont aussi leur propre domaine de responsabilité, ce qui signifie qu'il leur est dévolu de veiller à ce qu'une partie significative du système satisfasse aux fonctionnalités annoncées. Pour une liste complète des développeurs FreeBSD et de leurs domaines de responsabilité, veuillez consulter la liste des participants au projet. La plupart des membres de l'équipe de base sont volontaires en ce qui concerne le développement de FreeBSD et ne retirent aucun profit financier du projet, donc “implication” ne doit pas être compris “support garanti”. La comparaison précédente avec un comité directeur n'est pas tout à fait exacte, et il serait plus juste de dire que ce sont des gens qui ont sacrifié leur vie à FreeBSD contre toute raison! Contributions extérieures contributions Enfin, mais certainement pas des moindres, le groupe le plus important de développeurs est constitué par les utilisateurs eux-mêmes qui nous fournissent de façon quasi régulière leur retour d'expérience et leurs corrections de bogues. Le principal moyen d'entrer en contact avec le développement plus décentralisé de FreeBSD est de s'inscrire sur la &a.hackers; où ces questions sont abordées. Voyez pour plus d'informations concernant les diverses listes de discussion &os;. La liste de ceux qui ont contribué au projet est longue et en augmentation, pourquoi donc ne pas vous y joindre et contribuer à quelque chose en retour dès aujourd'hui? Fournir du code n'est pas la seule manière de contribuer au projet; pour avoir une liste plus complète de ce qu'il y a à faire, voyez s'il vous plaît le site du projet FreeBSD. En résumé, notre modèle de développement est organisé comme un ensemble relâché de cercles concentriques. Ce modèle centralisé est en place pour la commodité des utilisateurs de FreeBSD, qui disposent ainsi d'un moyen facile de suivre l'évolution d'une base de code centrale, et non pour tenir à l'écart d'éventuels participants! Nous souhaitons fournir un système d'exploitation stable avec un nombre conséquent de programmes d'application cohérents que les utilisateurs puissent facilement installer et employer — c'est un modèle qui fonctionne très bien pour cela. Tout ce que nous attendons de ceux qui se joindraient à nous pour développer FreeBSD est un peu de la même implication que les développeurs actuels ont vis-à-vis de sa réussite continue! A propos de cette version NetBSD OpenBSD 386BSD Free Software Foundation U.C. Berkeley Computer Systems Research Group (CSRG) FreeBSD est une version librement disponible et incluant tout le code source basé sur 4.4BSD-Lite2 pour les ordinateurs à architectures Intel &i386;, &i486;, &pentium;, &pentium; Pro, &celeron;, &pentium; II, &pentium; III, &pentium; 4 (ou compatible), &xeon;, DEC Alpha et systèmes basés sur &ultrasparc; de Sun. Il est basé essentiellement sur du logiciel du groupe CSRG de l'Université de Californie à Berkeley, avec des additions venant de NetBSD, OpenBSD, 386BSD, et de la “Free Software Foundation”. Depuis la publication de FreeBSD 2.0 fin 1994, les performances, fonctionnalités et la stabilité de FreeBSD ont été améliorées de façon spectaculaire. La plus grosse modification est un gestionnaire de mémoire virtuelle totalement revu qui comprend un cache commun au disque et à la mémoire virtuelle, qui n'améliore pas seulement les performances, mais diminue aussi l'occupation de la mémoire, de telle sorte qu'une configuration avec 5 MO devienne un minimum acceptable. D'autres ajouts concernent le support intégral des clients et serveurs NIS, le support des transactions TCP, les connexions PPP à la demande, le support intégré DHCP, un sous-système SCSI amélioré, support ISDN, support pour l'ATM, FDDI, les cartes “Fast et Gigabit Ethernet” (1000 Mbit), un meilleur support des derniers contrôleurs Adaptec et des milliers de corrections de bogues. En plus du système lui-même, FreeBSD offre un nouveau catalogue de logiciels portés (“ports”) qui inclut des milliers de programmes habituellement demandés. A l'heure où sont écrites ces lignes il y avait plus de &os.numports; logiciels portés! La liste va des serveurs HTTP (WWW) aux jeux, langages, éditeurs et presque tout ce qui existe entre. Le catalogue complet des logiciels demande près de &ports.size; d'espace disque, les portages se présentant sous forme de “delta” avec les sources d'origine. Cela rend leur mise à jour bien plus facile, et diminue de façon sensible l'espace nécessaire par rapport à l'ancien catalogue 1.0. Pour compiler un logiciel porté, il vous suffit d'aller dans le répertoire du programme que vous désirez installer, de taper make install, et de laisser le système faire le reste. La distribution originale complète de chaque logiciel est chargée dynamiquement depuis le CDROM ou un site FTP proche, il vous suffit de disposer de suffisamment d'espace disque pour compiler le logiciel que vous voulez. Presque tous les logiciels sont aussi fournis sous forme pré-compilée (“package”—paquetage) qui peut être installé avec une seule commande (pkg_add), si vous ne voulez pas les compiler à partir des sources. Plus d'information sur les paquetages et les logiciels portés peut être trouvée dans le . Il y a un certain nombre d'autres documents qui vous serons peut-être très utiles à l'installation et à l'utilisation de FreeBSD, que vous pouvez maintenant trouver dans le répertoire /usr/share/doc de n'importe quelle machine sous une version récente de &os;. Vous pouvez consulter les manuels localement disponibles avec n'importe quel navigateur HTML aux URLs suivantes: Le Manuel FreeBSD /usr/share/doc/handbook/index.html La FAQ de FreeBSD /usr/share/doc/faq/index.html Vous pouvez aussi consulter les exemplaires originaux (et les plus souvent mis à jour) sur http://www.FreeBSD.org. diff --git a/fr_FR.ISO8859-1/books/handbook/mirrors/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/mirrors/chapter.sgml index 7a3fd7acd9..db49f9c3f6 100644 --- a/fr_FR.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,3679 +1,3679 @@ Se procurer &os; &trans.a.fonvieille; Editeurs de CD-ROMs et DVDs Produits vendus en boîte Des versions en boîte de &os; sont disponibles (CDs de &os;, logiciels supplémentaires, et documentation papier) auprès de plusieurs revendeurs:
CompUSA WWW:
Frys Electronics WWW:
CDs et DVDs Les CDs et DVDs de &os; sont disponibles auprès de nombreux revendeurs en ligne:
BSD Mall by Daemon News PO Box 161 Nauvoo, IL 62354 USA Phone: +1 866 273-6255 Fax: +1 217 453-9956 Email: sales@bsdmall.com WWW: + url="http://www.bsdmall.com/">
BSD-Systems Email: info@bsd-systems.co.uk WWW:
FreeBSD Mall, Inc. 3623 Sanford Street Concord, CA 94520-1405 USA - Phone: +1 925 674-0783 + Phone: +1 925 240-6652 Fax: +1 925 674-0821 Email: info@freebsdmall.com WWW:
Dr. Hinner EDV St. Augustinus-Str. 10 D-81825 München Allemagne Phone: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre France WWW:
JMC Software Ireland Phone: 353 1 6291282 WWW:
Linux CD Mall Private Bag MBE N348 Auckland 1030 New Zealand Phone: +64 21 866529 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA Royaume-Uni Phone: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux+ DVD Magazine Lewartowskiego 6 Warsaw 00-190 Poland Phone: +48 22 860 18 18 Email: editors@lpmagazine.org WWW:
Linux System Labs Australie 21 Ray Drive Balwyn North VIC - 3104 Australie Phone: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Russia Phone: +7-812-3125208 Email: info@linuxcenter.ru WWW:
Distributeurs Si vous êtes un revendeur et désirez vendre des CDROMS de &os;, veuillez contacter un distributeur:
Cylogistics 809B Cuesta Dr., #2149 Mountain View, CA 94040 USA Phone: +1 650 694-4949 Fax: +1 650 694-4953 Email: sales@cylogistics.com WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 USA Phone: 1 (800) 456-8000 WWW:
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 USA Phone: +1 952 947-0822 Fax: +1 952 947-0876 Email: sales@kudzuenterprises.com
Navarre Corp 7400 49th Ave South New Hope, MN 55428 USA Phone: +1 763 535-8333 Fax: +1 763 535-0341 WWW:
Sites FTP >Les sources officielles de &os; sont disponibles via FTP anonyme à partir d'un ensemble de sites miroir. Le site dispose d'une bonne connectivité et autorise un grand nombre de connexions, mais vous avez intérêt à trouver plutôt un site miroir “plus proche” (tout particulièrement si vous décidez de mettre en place une sorte de miroir à votre tour). La base de données des sites miroir &os; est plus à jour que la liste de ce Manuel, parce qu'elle tire ses informations du DNS plutôt que se reposer sur une liste statique de machines. De plus, &os; est disponible via FTP anonyme à partir des sites miroir ci-dessous. Si vous décidez de vous procurer &os; via FTP anonyme, essayez si possible d'utiliser un site proche de vous. Les sites miroir listés en tant que “sites miroir primaires“ disposent généralement de l'intégralité de l'archive &os; (toutes les versions actuellement disponibles pour chacune des architectures) mais vous obtiendrez les temps de téléchargements les plus courts à partir d'un site situé dans votre pays ou votre région. Les sites régionaux proposent les versions les plus récentes des architectures les plus populaires mais pourraient ne pas proposer l'intégralité de l'archive de &os;. Tous les sites proposent un accès FTP anonyme mais certains sites fournissent également un accès suivant d'autres méthodes. Les méthodes d'accès disponibles pour chaque site sont données entre parenthèses après le nom de la machine. &chap.mirrors.ftp.inc; CVS anonyme <anchor id="anoncvs-intro">Introduction CVS anonyme CVS anonyme (ou comme on l'appelle également, anoncvs) est une de fonctionnalité des utilitaires CVS livrés avec &os; qui permet la synchronisation avec un référentiel CVS sur une machine distante. Elle permet, entre autres, aux utilisateurs de &os;, de lire, sans autorisation particulière, les archives disponibles sur l'un des serveurs anoncvs officiels du projet &os;. Pour l'utiliser, il suffit simplement de définir la variable d'environnement CVSROOT pour qu'elle pointe sur le serveur anoncvs approprié, fournir le fameux mot de passe “anoncvs” avec la commande cvs login, puis ensuite utiliser la commande &man.cvs.1; pour y accéder de la même manière qu'à un référentiel local. La commande cvs login, stocke les mots de passe utilisés pour authentification sur le serveur CVS dans un fichier appelé .cvspass dans votre répertoire HOME. Si ce fichier n'existe pas, vous pourrez obtenir une erreur quand vous essaierez d'utiliser cvs login pour la première fois. Créez juste un fichier .cvspass vide, et relancez la commande. Bien que l'on puisse aussi dire que CVSup et anoncvs assurent globalement la même fonction, il y a diverses nuances qui peuvent influencer l'utilisateur dans son choix d'une méthode de synchronisation. En résumé, CVSup utilise plus efficacement les ressources réseau et est de loin la méthode la plus sophistiquée des deux, mais cela a un prix. Pour employer CVSup, il faut d'abord installer et configurer un programme client spécialisé avant de pouvoir récupérer quoi que ce soit, et il faut ensuite travailler par sous-ensemble relativement importants, que CVSup appelle catalogues. anoncvs, au contraire, peut être utilisé pour examiner n'importe quoi, d'un seul fichier à un programme particulier (tel que ls ou grep) en faisant référence au nom du module CVS. Bien sûr, anoncvs n'est bon qu'à lire un référentiel CVS, si vous avez donc l'intention de développer localement sur un référentiel partagé avec le projet &os;, alors vous n'avez d'autre choix que d'utiliser CVSup. <anchor id="anoncvs-usage">Utiliser CVS anonyme Configurer &man.cvs.1; pour utiliser un référentiel CVS anonyme consiste simplement à définir la variable d'environnement CVSROOT pour qu'elle pointe sur l'un des serveurs anoncvs du projet &os;. A la date de rédaction de ce document, les serveurs suivants sont disponibles: Autriche: :pserver:anoncvs@anoncvs.at.FreeBSD.org:/home/ncvs (Utilisez cvs login et entrez le mot de passe “anoncvs” quand on vous le demandera.) France: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs (pserver (mot de passe “anoncvs”), ssh (aucun mot de passe)) Allemagne: :pserver:anoncvs@anoncvs.de.FreeBSD.org:/home/ncvs (rsh, pserver, ssh, ssh/2022) Japon: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (Utilisez cvs login et entrez le mot de passe “anoncvs” quand on vous le demandera.) Taiwan: :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs (pserver (utilisez cvs login and entrez n'importe quel mot de passe quand on vous le demandera), ssh (pas de mot de passe)) SSH2 HostKey: 1024 e8:3b:29:7b:ca:9f:ac:e9:45:cb:c8:17:ae:9b:eb:55 /etc/ssh/ssh_host_dsa_key.pub USA: freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs (ssh uniquement - pas de mot de passe) SSH HostKey: 1024 a1:e7:46:de:fb:56:ef:05:bc:73:aa:91:09:da:f7:f4 root@sanmateo.ecn.purdue.edu SSH2 HostKey: 1024 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65 ssh_host_dsa_key.pub USA: anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (ssh2 uniquement - pas de mot de passe) SSH2 HostKey: 2048 53:1f:15:a3:72:5c:43:f6:44:0e:6a:e9:bb:f8:01:62 /etc/ssh/ssh_host_dsa_key.pub Comme CVS vous permet de récupérer (“check out”) pratiquement n'importe quelle version des sources de &os; ayant existé (ou, dans certains cas, à venir), vous devez maîtriser l'indicateur de révision () de &man.cvs.1; et connaître les valeurs qu'il peut prendre dans le référentiel du projet &os;. Il y a deux sortes d'étiquettes, les étiquettes de révision et les étiquettes de branches. Les étiquettes de révision s'appliquent à une révision particulière. Leur signification ne varie pas d'un jour à l'autre. Les étiquettes de branche, à l'inverse, se rapportent à la dernière révision sur une branche particulière à un moment donné. Comme les étiquettes de branche ne se rapportent pas à une révision particulière, elles peuvent désigner demain quelque chose de différent de ce qu'elles référencent aujourd'hui. présente les étiquettes de révision qui peuvent intéresser l'utilisateur. Encore une fois, aucune ne s'applique au catalogue des logiciels portés puisque ce dernier ne présente pas - de multiple révisions. + de multiples branches de développement. Quand vous précisez une étiquette de branche, vous obtenez normalement la dernière version des fichiers de cette branche de développement. Si vous voulez une version antérieure, vous pouvez l'obtenir en précisant une date avec l'indicateur . Reportez-vous aux pages de manuel &man.cvs.1; pour plus de détails. Exemples Bien qu'il soit vraiment recommandé de lire attentivement les pages de manuel de &man.cvs.1; avant de faire quoi que ce soit, voici quelques exemples rapides qui vous montrent essentiellement comment utiliser CVS anonyme: Récupérer quelque chose de -CURRENT (&man.ls.1;): &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter any word for password. &prompt.user; cvs co ls Utiliser SSH pour récupérer l'arborescence <filename>src/</filename>: &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. Récupérer la version 6-STABLE de &man.ls.1;: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter any word for password. &prompt.user; cvs co -rRELENG_6 ls Générer la liste des différences concernant &man.ls.1; (sous forme de “diffs unifiés”) entre différentes versions de &os; &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter any word for password. &prompt.user; cvs rdiff -u -rRELENG_5_3_0_RELEASE -rRELENG_5_4_0_RELEASE ls Savoir quels autres noms de modules peuvent être utilisés: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter any word for password. &prompt.user; cvs co modules &prompt.user; more modules/modules Autres ressources Les ressources supplémentaires suivantes peuvent être utiles pour apprendre à se servir de CVS: Guide CVS de Cal Poly. CVS Home, la communauté de développement et de support de CVS. CVSweb est l'interface Web pour CVS du projet &os;. Utiliser CTM CTM CTM est une méthode pour synchroniser une arborescence de répertoires distants avec une arborescence centrale. Elle a été développée pour être utilisée avec l'arborescence des sources de &os;, bien que d'autres puissent avec le temps la trouver utile pour d'autres besoins. Il existe actuellement très peu, sinon aucune, documentation sur la façon de créer les deltas, contactez-donc la liste de diffusion &a.ctm-users.name; pour obtenir plus d'informations et si vous souhaitez utiliser CTM pour autre chose. Pourquoi utiliser <application>CTM</application>? CTM vous procurera un exemplaire local de l'arborescence des sources de &os;. Il y a plusieurs “moutures” de l'arborescence disponibles. Que vous désiriez suivre toute l'arborescence CVS ou seulement une de ses branches, CTM peut vous fournir ce dont vous avez besoin. Si vous développez activement sous &os;, mais ne disposez que d'une connectivité TCP/IP peu fiable ou n'en avez pas du tout, ou voulez tout simplement que les modifications vous soient automatiquement envoyées, CTM est ce qu'il vous faut. Il vous faudra jusqu'à trois deltas par jour sur les branches les plus actives. Cependant, vous devriez envisager de vous les faire envoyer automatiquement par courrier électronique. La taille des mises à jour est toujours aussi petite que possible. Typiquement moins de 5KO, occasionnellement (une fois sur 10), entre 10 et 50KO, et de temps à autre, une grosse modification de 100KO ou plus. Vous devrez aussi vous tenir au courant des différentes contre-parties liées au fait de travailler directement avec les sources en cours de développement plutôt qu'avec les versions publiées. C'est particulièrement vrai si vous choisissez les sources de la branche “-CURRENT”. Il est recommandé de lire Se synchroniser avec la version -CURRENT de FreeBSD. Que vous faut-il pour utiliser <application>CTM</application>? Vous aurez besoin de deux choses: le programme CTM, et les deltas initiaux à lui fournir (pour mettre à jour avec la version “courante”). Le programme CTM fait partie de &os; depuis la publication de la version 2.0, et se trouve dans /usr/src/usr.sbin/ctm si vous avez un exemplaire des sources en ligne. Vous pouvez obtenir les “deltas” à fournir à CTM de deux façons, par FTP ou par courrier électronique. Si vous avez un accès FTP à l'Internet, les sites suivants supportent l'accès à CTM: ou reportez-vous à la section Sites miroirs. Allez dans le répertoire vous concernant et commencez par télécharger le fichier README. Si vous souhaitez récupérer vos deltas par courrier électronique: Abonnez-vous à l'une des listes de distribution CTM. &a.ctm-cvs-cur.name; comprend toute l'arborescence -CURRENT. &a.ctm-src-4.name; concerne la branche 4.X, etc... (Si vous ne savez pas comment vous abonner à une liste, cliquez sur le nom de la liste ci-dessus ou sur &a.mailman.lists.link; puis cliquez sur la liste à laquelle vous désirez vous abonner. La page devrait contenir toutes les instructions nécessaires à l'abonnement.) Dès que vous commencez à recevoir vos mises à jour CTM par courrier électronique, vous pouvez utiliser le programme ctm_rmail pour les décompacter et les appliquer. Vous pouvez en fait utiliser directement le programme ctm_rmail à partir d'une entrée dans /etc/aliases si vous voulez automatiser complètement le processus. Consultez les pages de manuel de ctm_rmail pour plus de détails. Quelle que soit la méthode que vous utilisez pour récupérer les deltas CTM, vous devriez vous abonner à la liste de diffusion &a.ctm-announce.name;. Ce sera, dans l'avenir, le seul endroit où les annonces concernant le fonctionnement du système CTM seront faites. Cliquez sur le nom de la liste et suivez les instructions pour s'inscrire à la liste. Utiliser <application>CTM</application> pour la première fois Avant de pouvoir utiliser les deltas CTM, il vous faut un point de départ pour appliquer les deltas générés à partir de là. Tout d'abord vous devez déterminer ce que vous avez déjà. Tout le monde peut partir d'un répertoire “vide”. Vous devez utiliser un delta “Empty” (vide) au départ pour débuter votre arborescence supportée par CTM. Il fut question que l'un de ces deltas de départ soit distribué sur le CD, cependant ce n'est actuellement pas le cas. Puisque les arborescences représentent plusieurs dizaines de mégaoctets, vous préférerez commencer avec ce que vous avez déjà sous la main. Si vous disposez d'une version de &os; sur CD, vous pouvez copier ou extraire les sources initiales qui s'y trouvent. Cela évitera un transfert de données conséquent. Vous pouvez reconnaître ces deltas de transition au X qui suit leur numéro de séquence (src-cur.3210XEmpty.gz par exemple). La dénomination après le X correspond à l'origine de votre “racine” initiale. Empty est un répertoire vide. La règle est qu'une transition de base à partir de Empty est générée tous les 100 deltas. Au passage, elles sont volumineuses! De 70 à 80 mégaoctets de données compressées avec gzip est une taille habituelle pour les deltas XEmpty. Une fois que vous avez sélectionné un delta initial à partir duquel commencer, il vous faudra également tous les deltas de numéro supérieur qui le suivent. Utiliser <application>CTM</application> au quotidien Pour appliquer les deltas, tapez simplement: &prompt.root; cd /où/vous/voulez/mettre/les/fichiers &prompt.root; ctm -v -v /où/vous/mettez/vos/deltas/src-xxx.* CTM reconnaît les deltas qui ont été compressés avec gzip, vous n'avez donc pas besoin de les décompresser avant, ce qui économise de l'espace disque. A moins d'être absolument sûr du résultat, CTM ne touchera pas à votre arborescence. Pour contrôler la validité d'un delta, vous pouvez également utiliser l'indicateur et CTM ne modifiera alors pas votre arborescence; il vérifiera simplement l'intégrité du delta et regardera s'il peut s'appliquer proprement à votre arborescence en l'état. Il y a aussi d'autres option pour CTM, voyez les pages de manuel ou lisez les sources pour plus d'informations. C'est à peu près tout. Chaque fois que vous recevez un delta, passez-le à CTM pour tenir à jour votre arborescence des sources. N'effacez pas les deltas s'il vous est difficile de les télécharger de nouveau. Vous pouvez en avoir besoin si quelque chose mauvais se produit. Même si vous n'avez que des disquettes, envisagez d'utiliser &man.fdwrite.1; pour en faire une copie. Conserver vos modifications locales Si vous êtes développeur vous voudrez expérimenter et modifier des fichiers de l'arborescence des sources. CTM supporte de façon limitée les modifications locales: avant de contrôler l'existence d'un fichier foo, il regarde tout d'abord s'il y a un fichier foo.ctm. Si ce fichier existe, CTM l'utilisera au lieu de foo. Ce comportement vous permet de conserver de façon simple des modifications locales: copiez simplement les fichiers que vous envisagez de modifier dans des fichiers de même nom, mais avec le suffixe .ctm. Vous pouvez ensuite bidouiller tranquillement le code, pendant que CTM maintient à jour le fichier .ctm. D'autres options intéressantes de <application>CTM</application> Savoir avec précision ce que va modifier une mise à jour Vous pouvez connaître la liste des modifications que CTM appliquera à votre archive des sources en utilisant CTM avec l'option . C'est utile si vous voulez conserver la trace des modifications, pré- ou post- modifier les fichiers concernés, ou vous vous sentez un tantinet paranoïaque. Faire des sauvegardes avant la mise à jour Parfois vous voudrez sauvegarder tous les fichiers qui seraient toucher par une mise à jour CTM. Avec l'option , CTM sauvegarde tous les fichiers que seraient modifiés par delta CTM donné dans fichier_de_sauvegarde. Restreindre la liste des fichiers touchés par une mise à jour Parfois vous voudrez restreindre le champ d'application d'une mise à jour CTM, ou serez intéressé à n'extraire que quelques fichiers d'une séquence de deltas. Vous pouvez contrôler la liste de fichiers sur laquelle travaillera CTM en donnant comme filtre une expression régulière avec les options et . Par exemple, pour extraire une version à jour de lib/libc/Makefile de la série de deltas CTM que vous avez sauvegardé, lancez les commandes: &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* Pour chaque fichier d'un delta CTM, les options et sont appliquées dans l'ordre donné sur la ligne de commande. Le fichier est traité par CTM uniquement s'il est sélectionné après application des options et . Perspectives pour <application>CTM</application> Il y en a des tonnes: Utiliser une méthode d'authentification au système CTM pour détecter la substitution de mises à jour. Faire le ménage dans les options de CTM, elles commencent à engendrer de la confusion et à contredire l'intuition. Divers Il existe aussi une séquence de deltas pour le catalogue des logiciels portés, mais elle n'a pas reçue beaucoup d'écho jusqu'ici. Miroirs <application>CTM</application> CTM/FreeBSD est disponible via FTP anonyme sur les miroirs suivants. Si vous faites le choix de vous procurer CTM via FTP anonyme, utilisez s'il vous plaît un site proche de vous. En cas de problème, contactez la liste de diffusion &a.ctm-users.name;. Californie, Bay Area, source officielle Afrique du Sud, serveur de sauvegarde pour les anciens deltas Taïwan/R.O.C. Si vous n'avez pas trouvé de miroir proche de vous, où si le miroir est incomplet, essayez d'utiliser un moteur de recherche comme alltheweb. Utiliser CVSup Introduction CVSup est un ensemble de logiciels pour la distribution et la mise à jour d'arborescences de sources à partir d'un référentiel CVS principal sur une machine serveur distante. Les sources de &os; sont archivées sous un référentiel CVS sur une machine centrale de développement en Californie. Grâce à CVSup, les utilisateurs de &os; peuvent facilement tenir à jour leur propre arborescence de sources. CVSup utilise le modèle pull de mise à jour. Dans ce schéma, chaque client réclame les mises à jour au serveur, si et quand il le souhaite. Le serveur attend passivement les demandes de mises à jour de ses clients. Toutes les mises à jour sont donc faites à la demande du client. Le serveur n'envoie jamais de mise à jour non sollicitée. Les utilisateurs doivent soit exécuter le client CVSup à la main pour obtenir une mise à jour, soit mettre en oeuvre une tâche cron pour l'exécuter automatiquement et à intervalles réguliers. Le terme CVSup, avec les majuscules, désigne l'ensemble du logiciel. Ses principales composantes sont le client cvsup qui s'exécute sur les machines de chaque utilisateur, et le serveur cvsupd, qui tourne sur tous les sites miroir de &os;. En lisant la documentation et les listes de diffusion de &os;, vous trouverez des références à sup. sup était le prédécesseur de CVSup, et remplissait la même fonction. CVSup est utilisé de la même façon que sup et, emploie de fait des fichiers de configuration qui sont compatibles avec ceux de sup. sup n'est plus utilisé pour le projet &os;, parce que CVSup est à la fois plus rapide et plus souple. L'utilitaire csup est une réécriture en C du logiciel CVSup. Son plus grand avantage est d'être plus rapide et de ne pas dépendre du langage Modula-3, vous n'avez donc pas besoin de l'installer. De plus si vous utilisez &os; 6.2 ou une version suivante, vous pouvez directement utiliser cet utilitaire puisqu'il fait partie du système de base. Les anciennes versions de &os; ne disposent pas de &man.csup.1; dans leur système de base, mais vous pouvez facilement installer le logiciel porté net/csup, ou le paquetage pré-compilé correspondant. L'utilitaire csup ne supporte pas, cependant, le mode CVS. Si vous désirez dupliquer l'intégralité de dépôts, vous aurez toujours besoin de CVSup. Si vous avez décidé d'utiliser csup, passez les étapes concernant l'installation de CVSup et remplacez les références à CVSup par csup dans le reste de cette section. Installation La méthode la plus simple pour installer CVSup est d'utiliser la version pré-compilée net/cvsup du catalogue des logiciels portés de &os;. Si vous préférez compiler CVSup à partir des sources, vous pouvez directement utiliser le logiciel porté net/cvsup. Cependant soyez averti: le logiciel porté net/cvsup est écrit en Modula-3, qui demande un temps et un espace disque non négligeables pour le télécharger et le compiler. Si vous avez l'intention d'utiliser CVSup sur une machine qui ne disposera pas de &xfree86; ou &xorg;, comme un serveur, assurez-vous que le logiciel porté de n'incluera pas l'interface graphique (“GUI”) de CVSup, net/cvsup-without-gui. Si vous voulez installer csup sous &os; 6.1 et version précédentes, vous pouvez utiliser le paquetage pré-compilé net/csup du catalogue des logiciels portés. Si vous préférez compiler csup à partir des sources, vous pouvez directement utiliser le logiciel porté net/csup. Configuration de <application>CVSup</application> Le fonctionnement de CVSup est contrôlé par un fichier de configuration appelé supfile. Il y a des exemples de fichiers supfile dans le répertoire /usr/share/examples/cvsup/. Les informations du fichier supfile répondent pour CVSup aux question suivantes: Quels fichiers voulez-vous télécharger? Quelles versions de ces fichiers voulez-vous? D'où voulez-vous les télécharger? Où voulez-vous les mettre sur votre machine? Où voulez-vous mettre les fichiers d'état de votre machine? Dans les sections suivantes, nous allons renseigner un fichier supfile typique en répondant une à une à chacune de ces questions. Commençons par décrire la structure d'ensemble d'un fichier supfile. Un fichier supfile est un fichier texte. Les commentaires débutent par un # et se prolongent jusqu'à la fin de la ligne. Les lignes vides ou qui ne contiennent que des commentaires sont ignorées. Les autres lignes décrivent les ensembles de fichiers que l'utilisateur souhaite recevoir. Ces lignes commencent par le nom d'un “catalogue” - collection, un regroupement logique de fichiers défini par le serveur. Le nom du catalogue dit au serveur quels fichiers vous voulez. Ce nom est éventuellement suivi d'un ou plusieurs champs, séparés par un espace. Ces champs répondent aux questions listées ci-dessus. Il y deux types de champs: des indicateurs et des valeurs. Un indicateur est un mot-clé autonome, e.g., delete ou compress. Une valeur commence aussi par un mot-clé, mais il est impérativement suivi sans espace par un = et un deuxième mot. Par exemple, release=cvs est un champ définissant une valeur. Un fichier supfile spécifie en général plus d'un catalogue à télécharger. Une façon de construire un fichier supfile consiste à préciser explicitement tous les champs nécessaires pour chaque catalogue. Cependant, cela tend à donner des fichiers supfile avec des lignes assez longues, et ce n'est pas très pratique parce que la plupart des champs sont les mêmes pour tous les catalogues du fichier supfile. CVSup fournit un mécanisme pour s'affranchir de ce problème. Les lignes qui commencent par le nom du pseudo-catalogue spécial *default servent à définir les indicateurs et les valeurs qui seront pris par défaut pour les catalogues listés ensuite dans le fichier supfile. Une valeur par défaut peut-être surchargée pour un catalogue particulier, en associant au catalogue lui-même une valeur différente. Les valeurs par défaut peuvent également être redéfinies, ou bien on peut en définir de nouvelles, en cours de fichier supfile, par de nouvelles lignes *default. Sachant cela, nous allons maintenant mettre au point un fichier supfile pour télécharger et mettre à jour l'arborescence principale de FreeBSD-CURRENT. Quels fichiers voulez-vous télécharger? Les fichiers disponibles via CVSup sont regroupés par “catalogues” - collections. Les catalogues disponibles sont décrits dans la section suivante. Dans notre exemple, nous souhaitons recevoir toute l'arborescence principale du système &os;. Il existe un unique gros catalogue src-all qui correspond à tout cela. Pour commencer à renseigner notre fichier supfile, nous listons simplement les catalogues, un par ligne (dans notre cas, une seule ligne): src-all Quelle(s) version(s) voulez-vous télécharger? Avec CVSup, vous pouvez obtenir pratiquement n'importe quelle version qui ait existé des sources. C'est possible parce que le serveur cvsupd travaille directement à partir du référentiel CVS, qui contient toutes les versions. Vous indiquez quelle version vous voulez en utilisant les valeurs tag= et . Faites très attention à définir correctement la valeur tag=. Certaines étiquettes ne s'appliquent qu'à certains catalogues. Si l'étiquette que vous donnez n'est pas valable ou mal orthographiée, CVSup effacera des fichiers que vous ne vouliez probablement pas supprimer. En particulier, n'utilisez que tag=. pour les catalogues ports-*. Les valeurs données avec tag= sont des étiquettes symboliques définies dans le référentiel. Il y a deux sortes d'étiquettes, les étiquettes de révision et les étiquettes de branches. Les étiquettes de révision s'appliquent à une révision particulière. Leur signification ne varie pas d'un jour à l'autre. Les étiquettes de branches, à l'inverse, se rapportent à la dernière révision sur une branche particulière à un moment donné. Comme les étiquettes de branches ne se rapportent pas à une révision particulière, elles peuvent désigner demain quelque chose de différent de ce qu'elles référencent aujourd'hui. contient les étiquettes de branches qui peuvent intéresser les utilisateurs. Quand on spécifie une étiquette dans le fichier de configuration de CVSup, elle doit être précédée du champ tag= (RELENG_4 deviendra tag=RELENG_4). Gardez à l'esprit que seule l'étiquette tag=. n'a de signification pour le catalogue des logiciels portés. Faites très attention à mentionner précisément l'étiquette exacte. CVSup ne sait différencier une étiquette valide d'une étiquette qui ne l'est pas. Si vous orthographiez mal l'étiquette, CVSup se comportera comme si vous aviez donné une étiquette valide qui ne se réfère à aucun fichier. Dans ce cas il supprimera toutes les sources que vous avez déjà. Lorsque vous indiquez une étiquette de branche, vous recevez normalement les dernières versions des fichiers sur cette branche de développement. Si vous voulez récupérer des version antérieures, vous pouvez le faire en donnant une date avec le champ . La page de manuel de &man.cvsup.1; vous expliquent comment le faire. Dans notre exemple, nous désirons obtenir &os.current;. Nous ajoutons alors la ligne suivante au début de notre fichier supfile: *default tag=. Il existe un cas particulier important qui se produit lorsque que l'on ne spécifie ni le champ tag= ni le champ date=. Dans ce cas, vous obtenez alors les fichiers RCS directement du référentiel CVS du serveur, plutôt que de recevoir une version donnée. Les développeurs préfèrent généralement cette façon de travailler. En maintenant une version du référentiel lui-même sur leur système, ils ont la possibilité de consulter l'historique des révisions et d'accéder aux versions antérieures des fichiers. Cet avantage ne s'obtient cependant qu'au prix d'une consommation importante d'espace disque. D'où voulez-vous les télécharger? Nous employons le champ host= pour dire à cvsup où récupérer ses mises à jour. N'importe quel des sites miroir CVSup fera l'affaire, bien que vous devriez essayer de choisir un site proche de vous. Dans cet exemple, nous utiliserons un site fictif de distribution de &os; cvsup99.FreeBSD.org: *default host=cvsup99.FreeBSD.org Vous devrez changer le site pour un qui existe réellement avant d'exécuter CVSup. Lors de l'exécution de cvsup, vous pouvez surcharger cette définition sur la ligne de commande avec l'option . Où voulez-vous les mettre sur votre machine? Le champ prefix= dit à cvsup où mettre les fichiers qu'il obtient. Dans l'exemple, nous mettrons les fichiers source directement dans notre arborescence des sources, /usr/src. Le répertoire src est déjà implicitement défini dans les catalogues que nous avons choisis de télécharger, voici donc la définition correcte: *default prefix=/usr Où cvsup doit-il mettre les fichiers d'état? Le client CVSup tient à jour des fichiers d'état dans ce qui est appelé le répertoire de “base”. Ces fichiers permettent à CVSup de travailler plus efficacement en gardant la trace des modifications que vous avez déjà reçues. Nous utiliserons le répertoire de base standard, /var/db: *default base=/var/db Si votre répertoire de base n'existe pas encore, c'est le moment de le créer. Le client cvsup refusera de s'exécuter si le répertoire de base n'existe pas. Diverses autres options de configuration dans le fichier supfile: Il y a une autre ligne d'instruction qui doit normalement figurer dans le fichier supfile: *default release=cvs delete use-rel-suffix compress release=cvs dit au serveur d'obtenir les informations du référentiel principal de &os;. C'est quasiment toujours le cas, mais il existe d'autres possibilités qui sortent du cadre du présent document. delete donne à CVSup l'autorisation de supprimer des fichiers. Vous devriez toujours utiliser cette possibilité, de sorte que CVSup puisse vraiment maintenir à jour votre arborescence des sources. CVSup veille à ne supprimer que les fichiers qu'il maintient. Les fichiers supplémentaires que vous pourriez avoir ne seront pas touchés. use-rel-suffix est... ésotérique. Si vous voulez vraiment savoir de quoi il retourne, lisez la page de manuel de &man.cvsup.1;. Sinon, mettez cet indicateur et ne vous en souciez pas plus. compress permet d'utiliser un algorithme de compression de type &man.gzip.1; sur la ligne de communication. Si votre connexion a la vitesse d'une ligne T1 ou plus, vous ne devriez probablement pas utiliser la compression. Sinon, cela facilite substantiellement les choses. Assembler les morceaux: Voici le fichier supfile de notre exemple en entier: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all Le fichier <filename>refuse</filename> Comme mentionné ci-dessus, CVSup utilise une méthode de type pull. Fondamentalement, cela signifie que vous vous connectez au serveur CVSup, ce dernier dit, “Voici ce que vous pouvez télécharger...”, puis votre client répond “Ok, je prendrai ceci, ceci, ceci et cela”. Dans la configuration par défaut, le client CVSup téléchargera chaque fichier associé avec le catalogue et l'étiquette que vous avez choisi dans le fichier de configuration. Cependant cela ne correspond pas toujours à ce que vous désirez, tout particulièrement si vous mettez à jour les arborescences doc, ports, ou www — la plupart des personnes sont incapables de lire quatre ou cinq langues différentes, et donc elles n'ont pas besoin de télécharger les fichiers spécifiques à certaines langues. Si vous mettez à jour le catalogue des logiciels portés, vous pouvez remédier à cela en spécifiant chaque catalogue individuellement (e.g., ports-astrology, ports-biology, etc au lieu de spécifier simplement ports-all). Cependant puisque les arborescences doc et www ne disposent pas de catalogues spécifiques à chaque langue, vous devez utiliser une des nombreuses fonctions de CVSup: le fichier refuse. Le fichier refuse indique essentiellement à CVSup qu'il ne doit pas télécharger chaque fichier d'un catalogue; en d'autre termes, il dit au client de refuser certains fichiers du serveur. Le fichier refuse peut être trouvé (ou, si vous n'en disposez pas encore d'un, doit être placé) dans base/sup/. base est défini dans votre supfile; notre répertoire base est défini en tant que /var/db ce qui signifie que le fichier refuse est par défaut /var/db/sup/refuse. Le fichier refuse a un format très simple; il contient tout simplement les noms des fichiers ou des répertoires que vous ne désirez pas rapatrier. Par exemple, si vous ne pouvez parler d'autres langues que l'anglais ou un peu d'allemand, et vous ne ressentez pas le besoin de lire la traduction en allemand de la documentation, vous pouvez mettre ce qui suit dans le fichier refuse: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/it_* doc/ja_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* et ainsi de suite pour les autres langues (vous pouvez en trouver une liste complète en parcourant le référentiel CVS de &os;). Avec cette fonction très utile, les utilisateurs disposant d'une connexion lente ou payant le temps de connexion à la minute seront en mesure d'économiser de précieuses minutes comme ils n'auront plus du tout besoin de télécharger des fichiers qu'ils n'utiliseront jamais. Pour plus d'information sur les fichiers refuse et d'autres caractéristiques intéressantes de CVSup, consultez sa page de manuel. Exécuter <application>CVSup</application> Vous êtes maintenant prêt à essayer de faire une mise à jour. La ligne de commande à utiliser est très simple: &prompt.root; cvsup supfile où supfile est bien sûr le nom du fichier supfile que vous venez de créer. Si vous êtes sous X11, cvsup affichera une interface graphique avec des boutons pour les opérations courantes. Appuyez sur le bouton go et suivez le déroulement des opérations. Comme, dans cet l'exemple, vous mettez directement à jour votre arborescence /usr/src, vous devrez exécuter le programme en tant que root de façon à ce que cvsup ait le droit de mettre à jour vos fichiers. Comme vous venez juste de créer votre fichier de configuration et n'avez encore jamais utilisé le programme, il est compréhensible que cela vous rende nerveux. Il est facile de faire un essai sans toucher à vos précieux fichiers. Créez juste un nouveau répertoire quelque part et donnez-le en argument supplémentaire sur la ligne de commande: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest Le répertoire indiqué sera pris comme destination pour tous les fichiers modifiés. CVSup examinera les fichiers habituels dans /usr/src, mais ne les modifiera pas et n'en supprimera aucun. Les modifications atterriront dans /var/tmp/dest/usr/src. CVSup ne touchera pas non plus à ses fichiers d'état dans le répertoire de base, lorsqu'il est invoqué de cette manière. Les nouvelles versions de ces fichiers iront dans le répertoire indiqué. A partir du moment où vous avez les les droits en lecture sur /usr/src, vous n'avez pas besoin d'être root pour faire ce genre d'essai. Si vous n'êtes pas sous X11, ou si vous n'aimez tout simplement pas les interfaces graphiques, vous devrez ajouter quelques options supplémentaires sur la ligne de commande de cvsup: &prompt.root; cvsup -g -L 2 supfile L'option dit à CVSup de ne pas utiliser son interface graphique. C'est automatique si vous n'êtes pas sous X11, sinon vous devez le préciser. L'option dit à CVSup d'afficher le détail de ce qu'il est en train de faire. Il y a trois niveaux de trace, de à . La valeur par défaut est de 0, ce qui équivaut à n'émettre que les messages d'erreur. Il y a de nombreuses autres option disponibles. Pour en obtenir un résumé, tapez cvsup -H. Pour une description plus détaillée, reportez-vous aux pages de manuel. Une fois que vous êtes satisfait de la façon dont se passent les mises à jour, vous pouvez mettre en place une exécution de CVSup à intervalles réguliers en utilisant &man.cron.8;. Bien évidemment, vous ne devez pas laisser CVSup utiliser don interface graphique quand vous le lancez depuis &man.cron.8;. Catalogue de fichiers <application>CVSup</application> Les catalogues de fichiers disponibles via CVSup sont organisés hiérarchiquement. Il y a quelques gros catalogues, qui sont divisés en plus petits sous-catalogues. Recevoir un gros catalogue équivaut à recevoir chacun de ces sous-catalogues. Les relations hiérarchiques entre les sous-catalogues sont décrites par les indentations dans la liste ci-dessous. Les catalogues habituellement les plus employés sont src-all, et ports-all. Les autres catalogues ne sont utilisés que par de petits groupes de personnes pour des besoins particuliers, et certains sites miroir ne les mettent pas à disposition. cvs-all release=cvs Le référentiel CVS principal de &os;, incluant les logiciels de chiffrement. distrib release=cvs Les fichiers ayant trait à la distribution et à la mise en place de sites miroir &os;. doc-all release=cvs Les sources du manuel &os; et d'autres documentations. Cela de comprend pas les fichiers pour le site Web de &os;. ports-all release=cvs Le catalogue des logiciels portés de &os;. Si vous ne voulez pas mettre à jour l'intégralité du catalogue ports-all (l'intégralité du catalogue des logiciels portés), mais utiliser un des sous-catalogues listés ci-dessous, assurez-vous de toujours mettre à jour le sous-catalogue ports-base! Dès qu'il y a un changement dans l'infrastructure de compilation des logiciels portés représentée par ports-base, il est certain que ces changements seront utilisés par un logiciel porté très rapidement. Donc, si vous ne mettez à jour que les logiciels portés en tant que tel et qu'ils utilisent certains des changements, il y a de grandes chances pour que leur compilation échoue avec de mystérieux messages d'erreur. La première chose à faire dans ce cas est de vérifier que votre sous-catalogue ports-base est à jour. Si vous voulez construire votre propre version locale du fichier ports/INDEX, vous devez accepter le catalogue ports-all (l'intégralité du catalogue des logiciels portés). La construction de ports/INDEX avec une arborescence partielle n'est pas supportée. Consultez la FAQ. ports-accessibility release=cvs Logiciels pour utilisateurs handicapées. ports-arabic release=cvs Support pour l'arabe. ports-archivers release=cvs Outils d'archivage. ports-astro release=cvs Logiciels d'astronomie. ports-audio release=cvs Support du son. ports-base release=cvs L'infrastructure de compilation du catalogue des logiciels portés — divers fichiers situés dans les répertoires Mk/ et Tools/ sous-répertoires de la hiérarchie /usr/ports. Lisez l'important avertissement ci-dessus: vous devriez toujours mettre à jour ce sous-catalogue, dès que vous mettez à jour une partie du catalogue des logiciels portés de &os;! ports-benchmarks release=cvs Evaluation de performances. ports-biology release=cvs Biologie. ports-cad release=cvs Outils de conception assistée par ordinateur. ports-chinese release=cvs Support pour le chinois. ports-comms release=cvs Logiciels de communication. ports-converters release=cvs Conversion entre codages de caratères. ports-databases release=cvs Bases de données. ports-deskutils release=cvs Les choses que l'on trouvait sur un bureau avant l'invention des ordinateurs. ports-devel release=cvs Outils de développement. ports-dns release=cvs Logiciels relatifs au DNS. ports-editors release=cvs Editeurs. ports-emulators release=cvs Emulateurs d'autres systèmes d'exploitation. ports-finance release=cvs Applications concernant les finances et l'argent. ports-ftp release=cvs Clients et serveurs FTP. ports-games release=cvs Jeux. ports-german release=cvs Support pour l'allemand. ports-graphics release=cvs Outils graphiques. ports-hebrew release=cvs Support de l'hébreu. ports-hungarian release=cvs Support du hongrois. ports-irc release=cvs Outils pour l'IRC. ports-japanese release=cvs Support pour le japonais. ports-java release=cvs Outils &java;. ports-korean release=cvs Support pour le coréen. ports-lang release=cvs Langages de programmation. ports-mail release=cvs Logiciels de courrier électronique. ports-math release=cvs Logiciels de calcul numérique. ports-mbone release=cvs Applications MBone. ports-misc release=cvs Utilitaires divers. ports-multimedia release=cvs Logiciels pour le multimedia. ports-net release=cvs Logiciels réseau. ports-net-im release=cvs Logiciels de messagerie instantanée. ports-net-mgmt release=cvs Logiciels de gestion des réseaux. ports-net-p2p release=cvs Logiciels pour le peer to peer. ports-news release=cvs Logiciels pour les forums de discussion USENET. ports-palm release=cvs Logiciels de support des machines Palm. ports-polish release=cvs Support pour le polonais. ports-ports-mgmt release=cvs Utilitaires pour la gestion des logiciels portés et des paquetages. ports-portuguese release=cvs Support pour le portugais. ports-print release=cvs Logiciels d'impression. ports-russian release=cvs Support pour le russe. ports-science release=cvs Science. ports-security release=cvs Outils de sécurité. ports-shells release=cvs Interpréteurs de commandes. ports-sysutils release=cvs Utilitaires système. ports-textproc release=cvs Outils de traitement de texte (sauf les logiciels de publication assistée par ordinateur). ports-ukrainian release=cvs Support de l'ukrainien. ports-vietnamese release=cvs Support du vietnamien. ports-www release=cvs Logiciels concernant le World Wide Web. ports-x11 release=cvs Logiciel pour le système X window. ports-x11-clocks release=cvs Horloges pour X11. ports-x11-drivers release=cvs pilotes de périphérique X11. ports-x11-fm release=cvs Gestionnaires de fichiers pour X11. ports-x11-fonts release=cvs Polices de caractères et outils associés pour X11. ports-x11-toolkits release=cvs “Toolkits” X11. ports-x11-servers release=cvs Serveurs X11. ports-x11-themes release=cvs Thèmes X11. ports-x11-wm release=cvs Gestionnaires de fenêtres pour X11. projects-all release=cvs Les sources présentes dans le dépots des projets &os;. src-all release=cvs Les sources du système &os;, comprenant les logiciels de chiffrement. src-base release=cvs Divers fichiers en haut de la hiérarchie /usr/src. src-bin release=cvs Programmes utilisateurs qui peuvent être utiles en mode mono-utilisateur (/usr/src/bin). src-cddl release=cvs Utilitaires et bibliothèques sous licence CDDL (/usr/src/cddl). src-contrib release=cvs Utilitaires et bibliothèques d'origine indépendante du projet &os;, employés à peu près tels quels (/usr/src/contrib). src-crypto release=cvs Utilitaires et bibliothèques pour le chiffrement d'origine indépendante du projet &os;, employés à peu près tels quels (/usr/src/crypto). src-eBones release=cvs Kerberos et DES (/usr/src/eBones). Non utilisés dans les versions de &os; actuellement publiées. src-etc release=cvs Fichiers de configuration du système (/usr/src/etc). src-games release=cvs Jeux (/usr/src/games). src-gnu release=cvs Utilitaires soumis à la licence publique GNU (/usr/src/gnu). src-include release=cvs Fichiers d'entête (/usr/src/include). src-kerberos5 release=cvs Logiciel de sécurité Kerberos5 (/usr/src/kerberos5). src-kerberosIV release=cvs Logiciel de sécurité KerberosIV (/usr/src/kerberosIV). src-lib release=cvs Bibliothèques (/usr/src/lib). src-libexec release=cvs Programmes système normalement exécutés par d'autres programmes (/usr/src/libexec). src-release release=cvs Fichiers nécessaires à la génération d'une version publiable de &os; (/usr/src/release). src-rescue release=cvs Programmes liés en statique pour les dépannages d'urgence; consultez la page de manuel &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs Utilitaires système pour le mode mono-utilisateur (/usr/src/sbin). src-secure release=cvs Commandes et bibliothèques pour le chiffrage (/usr/src/secure). src-share release=cvs Fichiers qui peuvent être partagés par plusieurs systèmes (/usr/src/share). src-sys release=cvs Le noyau (/usr/src/sys). src-sys-crypto release=cvs Code du noyau destiné au chiffrement (/usr/src/sys/crypto). src-tools release=cvs Divers outils pour la maintenance de &os; (/usr/src/tools). src-usrbin release=cvs Outils utilisateur (/usr/src/usr.bin). src-usrsbin release=cvs Utilitaires système (/usr/src/usr.sbin). www release=cvs Les sources du site WWW de &os;. distrib release=self Fichiers de configuration du serveur CVSup. Utilisés par les sites miroir CVSup. gnats release=current Base de données GNATS d'historique des bogues. mail-archive release=current Archives des listes de diffusion &os;. www release=current Les fichiers/données WWW publiés (pas les fichiers source). Utilisés par les sites miroir WWW. Pour plus d'informations Pour la FAQ de CVSup et d'autres informations concernant CVSup, consultez la page Web de CVSup. La plupart des discussions relatives à l'utilisation de CVSup sous &os; ont lieu sur la &a.hackers;. Les nouvelles versions du logiciel y sont annoncés ainsi que sur la &a.announce;. Pour toutes les questions et rapports de bogues concernant CVSup, consultez la FAQ CVSup. Sites CVSup Des serveurs CVSup pour &os; fonctionnent aux sites suivants: &chap.mirrors.cvsup.inc; Utiliser Portsnap Introduction Portsnap est un système de distribution sécurisée du catalogue des logiciels portés de &os;. Approximativement chaque heure, un instantané du catalogue des logiciels portés est généré, rassemblé et signé de manière chiffrée. Les fichiers résultants sont alors distribués par l'intermédiaire du protocole HTTP. Tout comme CVSup, Portsnap utilise un modèle de mise à jour de type pull: le catalogue des logiciels portés packagé et signé est placé sur un serveur Web qui attend les requêtes des clients. Les utilisateurs doivent soit exécuter manuellement &man.portsnap.8; pour télécharger les mises à jour, soit configurer &man.cron.8; pour un téléchargement régulier et automatique des mises à jour. Pour des raisons techniques, Portsnap ne met pas à jour le catalogue des logiciels portés directement dans le répertoire /usr/ports; le logiciel travaille plutôt par défaut sur une version compressée de l'arborescence des logiciels portés dans le répertoire /var/db/portsnap. Cette copie compressée est ensuite utilisée pour mettre à jour le catalogue des logiciels portés. Si Portsnap est installé à partir du catalogue des logiciels portés de &os;, alors l'emplacement par défaut pour son instantané compressé sera /usr/local/portsnap au lieu de /var/db/portsnap. Installation Sous &os; 6.0 et les versions plus récentes, Portsnap fait partie du système de base de &os;. Sous des versions plus anciennes de &os;, il peut être installé à partir du logiciel porté ports-mgmt/portsnap. Configuration de Portsnap L'exécution de Portsnap est contrôlée par le fichier de configuration /etc/portsnap.conf. Pour la plupart des utilisateurs, le fichier de configuration par défaut sera suffisant; pour plus de détails, consultez la page de manuel &man.portsnap.conf.5;. Si Portsnap est installé à partir du catalogue des logiciels portés, il utilisera /usr/local/etc/portsnap.conf comme fichier de configuration au lieu de /etc/portsnap.conf. Ce fichier n'est pas créé lors de l'installation du logiciel, mais un fichier d'exemple est fourni; pour le copier à son emplacement correct, utilisez la commande suivante: &prompt.root; cd /usr/local/etc && cp portsnap.conf.sample portsnap.conf Exécuter <application>Portsnap</application> pour la première fois Au premier lancement de la commande &man.portsnap.8;, il sera nécessaire de télécharger un instantané compressé de l'intégralité de l'arborescence des logiciels portés dans /var/db/portsnap (ou /usr/local/portsnap si Portsnap a été installé à partir du catalogue des logiciels portés). Au début de l'année 2006, cela représentait un téléchargement d'environ 41 Mo. &prompt.root; portsnap fetch Une fois que l'instantané compressé a été récupéré, une copie utilisable de l'arborescence des logiciels portés peut être extraite dans le répertoire /usr/ports. Cela est nécessaire même si une arborescence a déjà été créée dans ce répertoire (par exemple en utilisant CVSup), puisque cela met en place une version de référence à partir de laquelle portsnap peut déterminer plus tard quelles parties du catalogue des logiciels portés a besoin d'une mise à jour. &prompt.root; portsnap extract Dans l'installation par défaut de &os; /usr/ports n'est pas créé. Si vous utilisez &os; 6.0-RELEASE, ce répertoire doit être créé avant d'utiliser la commande portsnap. Sur les versions de &os; plus récentes ou de Portsnap, cette création est effectuée automatiquement à la premiere utilisation de la commande portsnap. Mettre à jour l'arborescence des logiciels portés Après qu'un instantané initial du catalogue des logiciels portés ait été récupéré puis décompressé dans le répertoire /usr/ports, la mise à jour du catalogue se divise en deux étapes: la récupération (fetch) des mises à jour de l'instantané, et leur utilisation pour mettre à jour (update) le catalogue des logiciels portés en tant que tel. Ces deux étapes peuvent être effectuées par l'intermédiaire d'une seule commande portsnap: &prompt.root; portsnap fetch update Des versions anciennes de portsnap ne supporte pas cette syntaxe; en cas d'échec, utilisez à la place ceci: &prompt.root; portsnap fetch &prompt.root; portsnap update Exécuter Portsnap à partir de cron Afin d'éviter tout problème d'embouteillage lors de l'accès aux serveurs Portsnap, portsnap fetch ne fonctionnera pas à partir d'une tâche &man.cron.8;. Il existe, à la place, une commande portsnap cron spécifique, qui patiente durant un délai aléatoire pouvant aller jusqu'à 3600 secondes avant de récupérer les mises à jour. De plus, il est fortement recommandé de ne pas exécuter portsnap update à partir d'une tâche cron, puisque cela peut être à l'origine de graves problèmes si la commande a lieu au même moment qu'un logiciel porté est en train d'être compilé ou installé. Cependant, les fichiers INDEX peuvent être mis à jour sans risque, et cela peut être fait en passant l'indicateur à la commande portsnap (bien entendu si portsnap -I update est exécuté à par cron, il sera alors nécessaire de lancer portsnap update sans l'option ultérieurement pour mettre à jour le reste de l'arborescence). L'ajout de la ligne suivante dans le fichier /etc/crontab demandera à portsnap de mettre à jour son instantané compressé et les fichiers INDEX du répertoire /usr/ports, et enverra un courrier électronique si un logiciel porté installé n'est pas à jour: 0 3 * * * root portsnap -I cron update && pkg_version -vIL= Si l'horloge système n'est pas positionnée sur le fuseau horaire local, remplacez 3 par une valeur quelconque comprise entre 0 et 23, afin de répartir de manière plus équilibrée la charge sur les serveurs Portsnap. Des versions anciennes de portsnap ne supportent pas l'utilisation de commandes multiples (par exemple cron update) lors de la même invocation de portsnap. Si la ligne précédente échoue, essayez de remplacer portsnap -I cron update par portsnap cron && portsnap -I update. Etiquettes CVS Quand on récupère ou l'on met à jour les sources en utilisant cvs ou CVSup, une étiquette de révision doit être spécifiée. Une étiquette de révision fait référence soit à une branche particulière de développement de &os;, soit à un moment particulier dans le temps. Le premier type d'étiquette est nommé “étiquette de branche”, le second type “étiquette de publication” — release tags. Etiquettes de branche Toutes ces étiquettes, à l'exception de l'étiquette HEAD (qui est une étiquette toujours valide), ne s'appliquent qu'à l'arborescence src/. Il n'y a pas de branche pour les arborescences ports/, doc/, et www/. HEAD Nom symbolique pour la branche principale de développement, ou FreeBSD-CURRENT. C'est aussi la valeur par défaut lorsque la révision n'est pas précisée. Sous CVSup, cette étiquette est représentée par un . (ce n'est pas une ponctuation, mais bien le caractère .). Sous CVS, c'est la valeur par défaut quand aucune étiquette de révision n'est précisée. Ce n'est généralement pas une bonne idée de récupérer ou mettre à jour vers les sources CURRENT sur une machine STABLE, à moins que cela ne soit vraiment votre intention. RELENG_6 Branche de développement pour &os;-6.X, également connue sous le nom de &os; 6-STABLE. RELENG_6_2 Branche de publication de la version &os;-6.2, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_6_1 Branche de publication de la version &os;-6.1, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_6_0 Branche de publication de la version &os;-6.0, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_5 Branche de développement pour &os;-5.X, également connue sous le nom de &os; 5-STABLE. RELENG_5_5 Branche de publication de la version &os;-5.5, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_5_4 Branche de publication de la version &os;-5.4, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_5_3 Branche de publication de la version &os;-5.3, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_5_2 Branche de publication des versions &os;-5.2 et &os;-5.2.1, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_5_1 Branche de publication de la version FreeBSD-5.1, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_5_0 Branche de publication de la version FreeBSD-5.0, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4 Branche de développement de FreeBSD-4.X, aussi connue sous le nom de &os; 4-STABLE. RELENG_4_11 Branche de publication de la version &os;-4.11, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4_10 Branche de publication de la version &os;-4.10, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4_9 Branche de publication de la version &os;-4.9, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4_8 Branche de publication de la version FreeBSD-4.8, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4_7 Branche de publication de la version FreeBSD-4.7, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4_6 Branche de publication des versions FreeBSD-4.6 et FreeBSD-4.6.2, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4_5 Branche de publication de la version FreeBSD-4.5, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4_4 Branche de publication de la version FreeBSD-4.4, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_4_3 Branche de publication de la version FreeBSD-4.3, utilisée uniquement pour les avis de sécurité et autres correctifs de problèmes critiques. RELENG_3 Branche de développement de FreeBSD-3.X, aussi connue sous le nom de 3.X-STABLE. RELENG_2_2 Branche de développement de FreeBSD-2.2.X, aussi connue sous le nom de 2.2-STABLE. Cette branche est en grande partie obsolète. Etiquettes de publication Ces étiquettes font référence à un moment bien précis dans le temps quand une version particulière de &os; a été publiée. Le processus d'ingénierie des publications est documenté en détails dans les documents Information sur la publication des versions et Processus de publication. L'arborescence src utilise des étiquettes commençant par RELENG_. Les arborescences ports et doc utilisent des étiquettes dont les noms commencent par RELEASE. Enfin, l'arborescence www ne bénéficie pas d'étiquette particulière pour les publications. RELENG_6_2_0_RELEASE FreeBSD 6.2 RELENG_6_1_0_RELEASE FreeBSD 6.1 RELENG_6_0_0_RELEASE FreeBSD 6.0 RELENG_5_5_0_RELEASE FreeBSD 5.5 RELENG_5_4_0_RELEASE FreeBSD 5.4 RELENG_4_11_0_RELEASE FreeBSD 4.11 RELENG_5_3_0_RELEASE FreeBSD 5.3 RELENG_4_10_0_RELEASE FreeBSD 4.10 RELENG_5_2_1_RELEASE FreeBSD 5.2.1 RELENG_5_2_0_RELEASE FreeBSD 5.2 RELENG_4_9_0_RELEASE FreeBSD 4.9 RELENG_5_1_0_RELEASE FreeBSD 5.1 RELENG_4_8_0_RELEASE FreeBSD 4.8 RELENG_5_0_0_RELEASE FreeBSD 5.0 RELENG_4_7_0_RELEASE FreeBSD 4.7 RELENG_4_6_2_RELEASE FreeBSD 4.6.2 RELENG_4_6_1_RELEASE FreeBSD 4.6.1 RELENG_4_6_0_RELEASE FreeBSD 4.6 RELENG_4_5_0_RELEASE FreeBSD 4.5 RELENG_4_4_0_RELEASE FreeBSD 4.4 RELENG_4_3_0_RELEASE FreeBSD 4.3 RELENG_4_2_0_RELEASE FreeBSD 4.2 RELENG_4_1_1_RELEASE FreeBSD 4.1.1 RELENG_4_1_0_RELEASE FreeBSD 4.1 RELENG_4_0_0_RELEASE FreeBSD 4.0 RELENG_3_5_0_RELEASE FreeBSD-3.5 RELENG_3_4_0_RELEASE FreeBSD-3.4 RELENG_3_3_0_RELEASE FreeBSD-3.3 RELENG_3_2_0_RELEASE FreeBSD-3.2 RELENG_3_1_0_RELEASE FreeBSD-3.1 RELENG_3_0_0_RELEASE FreeBSD-3.0 RELENG_2_2_8_RELEASE FreeBSD-2.2.8 RELENG_2_2_7_RELEASE FreeBSD-2.2.7 RELENG_2_2_6_RELEASE FreeBSD-2.2.6 RELENG_2_2_5_RELEASE FreeBSD-2.2.5 RELENG_2_2_2_RELEASE FreeBSD-2.2.2 RELENG_2_2_1_RELEASE FreeBSD-2.2.1 RELENG_2_2_0_RELEASE FreeBSD-2.2.0 Sites AFS Il y a des serveurs AFS pour &os; sur les sites suivants: Suède Le chemin d'accès au fichiers est /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Suède 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Responsable ftp@stacken.kth.se Sites rsync Les sites suivants fournissent &os; en utilisant le protocole rsync. L'utilitaire rsync fonctionne globalement de la même manière que la commande &man.rcp.1;, mais il dispose de plus d'options et utilise le protocole de mise à jour à distance rsync qui ne transfert que les différences entre deux ensembles de fichiers, ce qui accélère énormément la synchronisation par le réseau. C'est surtout utile si vous disposez d'un miroir du serveur FTP de &os;, ou du référentiel CVS. La suite rsync est disponible sur de nombreux systèmes d'exploitation, et sous &os;, voir le logiciel porté net/rsync ou utilisez la version pré-compilée. République Tchèque rsync://ftp.cz.FreeBSD.org/ Collections disponibles: ftp: un miroir partiel du serveur FTP &os;. FreeBSD: un miroir complet du serveur FTP &os;. Allemagne rsync://grappa.unix-ag.uni-kl.de/ Collections disponibles: freebsd-cvs: référentiel CVS &os; complet. Cette machine est également miroir des référentiels CVS des projets NetBSD et OpenBSD, parmi d'autres. Hollande rsync://ftp.nl.FreeBSD.org/ Collections disponibles: vol/4/freebsd-core: un miroir complet du serveur FTP &os;. Thailande rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Collections disponibles: &os;: Un miroir complet du serveur FTP &os;. Royaume-Uni rsync://rsync.mirror.ac.uk/ Collections disponibles: ftp.freebsd.org: Un miroir complet du serveur FTP &os;. Etats Unis d'Amérique rsync://ftp-master.FreeBSD.org/ Ce serveur ne pourra être utilisé que par les sites miroirs primaires &os;. Collections disponibles: FreeBSD: l'archive principale du serveur FTP &os;. acl: la liste principale ACL de &os;. rsync://ftp13.FreeBSD.org/ Collections disponibles: FreeBSD: Un miroir complet du serveur FTP &os;. diff --git a/fr_FR.ISO8859-1/books/handbook/multimedia/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/multimedia/chapter.sgml index ac27fcc06d..ea58b0d4ab 100644 --- a/fr_FR.ISO8859-1/books/handbook/multimedia/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/multimedia/chapter.sgml @@ -1,2037 +1,2036 @@ Ross Lippert Mise en forme par Multimédia &trans.a.fonvieille; Synopsis FreeBSD supporte une grande variété de cartes son, vous permettant d'obtenir un son haute fidélité à partir de votre ordinateur. Ceci inclut la possibilité d'enregistrer et de jouer les formats “MPEG Audio Layer 3” (MP3), WAV et Ogg Vorbis aussi bien que de nombreux autres formats. Le catalogue de logiciels portés de FreeBSD contient également des applications vous permettant d'éditer vos enregistrements, rajouter des effets sonores, et contrôler des périphériques MIDI. - Avec un peu de volonté et d'expérimentation, - FreeBSD peut lire des fichiers vidéo et des DVDs. Le + Avec un peu d'expérimentation, + FreeBSD pourra lire des fichiers vidéo et des DVDs. Le nombre d'applications pour encoder, convertir, et lire divers supports vidéo est plus limité que le nombre d'applications équivalentes dans le domaine du son. Par exemple au moment de l'écriture de ces lignes, il n'existe pas de bonne application d'encodage dans le catalogue des logiciels portés de FreeBSD, qui pourra être utilisée pour convertir d'un format à un autre, comme peut le faire pour le son le programme audio/sox. Cependant, le paysage logiciel dans ce domaine évolue rapidement. Ce chapitre décrira les étapes nécessaires pour configurer votre carte son. La configuration et l'installation d'X11 () ont déjà pris soin des problèmes matériel de votre carte vidéo, bien qu'il puisse y avoir quelques réglages à ajuster pour obtenir une meilleure lecture des vidéos. Après la lecture de ce chapitre, vous connaîtrez: Comment configurer votre système afin que votre carte son soit reconnue. - Les méthodes pour tester si votre carte fonctionne en - utilisant certaines applications. + Les méthodes pour tester le fonctionnement de votre + carte. Comment faire face aux problèmes de configuration de votre carte son. Comment jouer et encoder des MP3s. Comment la vidéo est supportée par X11. Quelques logiciels portés qui donnent de bon résultats pour lire/encoder de la vidéo. Comment lire des DVDs, des fichiers .mpg et .avi. Comment extraire l'information présente sur des CDs et des DVDs. Comment configurer une carte TV. Comment configurer un scanner. Avant de lire ce chapitre, vous devrez: Savoir comment configurer et installer un nouveau noyau (). Essayer de monter des CDs audio avec la commande &man.mount.8; aura pour résultat une erreur, au moins, et une panique du noyau, au pire. Ces supports ont des codages spécifiques qui diffèrent du système de fichiers ISO classique. Moses Moore Contribution de Marc Fonvieille Augmentée pour &os; 5.X par Configurer une carte son Configuration du système PCI ISA cartes son Avant que vous commenciez, vous devriez connaître le modèle de carte son que vous avez, la puce qu'elle utilise, et si c'est une carte PCI ou ISA. FreeBSD supporte une grande variété de cartes PCI et ISA. Consultez la liste des périphériques audio supportés des notes de compatibilité matériel pour voir si - votre carte est supportée. Ce document indiquera + votre carte est supportée. Ces notes indiqueront également quel pilote supporte votre carte. noyau configuration Pour utiliser votre carte son, vous devrez charger le pilote de périphérique approprié. Cela peut être fait de deux façons. La plus simple est de charger le module pour votre carte son avec &man.kldload.8;, ce qui peut être soit fait à partir de la ligne de commande: &prompt.root; kldload snd_emu10k1 soit en ajoutant la ligne appropriée dans le fichier /boot/loader.conf comme cela: snd_emu10k1_load="YES" Ces exemples concernent la carte Creative &soundblaster; Live!. Les autres modules son chargeables sont listés dans /boot/defaults/loader.conf. Si vous n'êtes pas sûr du pilote à utiliser, vous pouvez tenter de charger le pilote snd_driver: &prompt.root; kldload snd_driver C'est un méta-pilote chargeant directement les pilotes les plus courants. Cela accélère la recherche du pilote adapté. Il est également possible de charger l'intégralité des pilotes de cartes son en utilisant le système /boot/loader.conf. Si vous voulez connaître le pilote sélectionné lors du chargement du méta-pilote snd_driver, vous pouvez consulter le fichier /dev/sndstat à cet effet, et cela à l'aide de la commande cat /dev/sndstat. Une seconde méthode est de compiler le support pour votre carte son en statique dans votre noyau. La section ci-dessous fournit les informations nécessaires pour ajouter le support de votre matériel de cette manière. Pour plus d'informations au sujet de la recompilation de votre noyau, veuillez consulter le . Configurer un noyau sur mesure avec support du son La première chose à effectuer est d'ajouter au noyau le pilote de périphérique audio - générique &man.sound.4;, pour cela vous devrez + générique &man.sound.4;; pour cela vous devrez ajouter la ligne suivante au fichier de configuration du noyau: device sound - Ensuite nous devons ajouter le support pour votre carte - son. Par conséquent, nous devons savoir quel pilote + Ensuite, vous devez ajouter le support pour votre carte + son. Par conséquent, vous devez savoir quel pilote supporte la carte. Consultez la liste des périphériques audio supportés des notes de compatibilité matériel pour déterminer le pilote correct pour votre carte son. Par exemple, une carte son Creative &soundblaster; Live! est supportée par le pilote &man.snd.emu10k1.4;. Pour ajouter le support pour cette carte, utilisez ce qui suit: device snd_emu10k1 Assurez-vous de lire la page de manuel du pilote pour la - syntaxe à utiliser. Des informations concernant la - syntaxe des pilotes de cartes son dans la configuration du - noyau peuvent être également trouvées dans + syntaxe à utiliser. La syntaxe de la configuration + du noyau pour chaque pilote de carte son supportée + peut être également trouvée dans le fichier /usr/src/sys/conf/NOTES. - Les cartes ISA non-PnP pourront nécessiter de + Les cartes son ISA non-PnP pourront nécessiter de fournir au noyau des informations sur le paramétrage de - la carte son (IRQ, port d'E/S, etc.). Cela s'effectue par + la carte (IRQ, port d'E/S, etc.), comme c'est en général le + cas pour toutes les cartes ISA non-PnP. Cela s'effectue par l'intermédiaire du fichier /boot/device.hints. Au démarrage du système, le chargeur (&man.loader.8;) lira ce fichier et passera les paramètres au noyau. Par exemple, une vieille carte ISA non-PnP Creative &soundblaster; - 16 utilisera le pilote &man.snd.sbc.4; de paire avec snd_sb16(4), on ajoutera alors la ligne suivante + 16 utilisera le pilote &man.snd.sbc.4; de paire avec snd_sb16, on ajoutera alors la ligne suivante au fichier de configuration du noyau: device snd_sbc device snd_sb16 - avec également ce qui suit dans le fichier + avec également ceci dans le fichier /boot/device.hints: hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x15" Dans ce cas, la carte utilise le port d'E/S 0x220 et l'IRQ 5. La syntaxe utilisée dans le fichier /boot/device.hints est abordée - dans la page de manuel du pilote de la carte son. + dans la page de manuel du pilote &man.sound.4; ainsi que celle + du pilote spécifique à la carte son. Les paramètres donnés ci-dessus sont ceux par défaut. Dans certains cas, vous pouvez avoir besoin de modifier l'IRQ ou tout autre paramètre en fonction de votre carte son. Consultez la page de manuel - &man.snd.sbc.4; pour plus d'informations. + &man.snd.sbc.4; pour plus d'informations au sujet de cette + carte. Tester la carte son Après avoir redémarré avec le noyau modifié, ou après avoir chargé le module nécessaire, la carte son devrait apparaître dans le tampon des messages du système (&man.dmesg.8;) d'un manière proche de la suivante: pcm0: <Intel ICH3 (82801CA)> port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: <Cirrus Logic CS4205 AC97 Codec> L'état de la carte son peut être contrôlée par l'intermédiaire du fichier /dev/sndstat: &prompt.root; cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: <Intel ICH3 (82801CA)> at io 0xd800, 0xdc80 irq 5 bufsz 16384 kld snd_ich (1p/2r/0v channels duplex default) Le résultat pourra être différent sur votre système. Si aucun périphérique pcm n'apparaît, retournez en arrière et revoyez ce qui a été fait précédemment. Contrôlez à nouveau votre fichier de configuration du noyau et vérifiez que vous avez choisi le périphérique correct. Les problèmes courants sont listés dans la . Si tout va bien, vous devriez avoir maintenant une carte son - qui fonctionne. Si votre lecteur de CD-ROM ou de DVD-ROM est - correctement relié à votre carte son, vous pouvez + qui fonctionne. Si la sortie audio de votre lecteur de CD-ROM ou de DVD-ROM est + correctement reliée à votre carte son, vous pouvez introduire un CD dans le lecteur et le jouer avec &man.cdcontrol.1;: &prompt.user; cdcontrol -f /dev/acd0 play 1 Diverses applications, comme audio/workman offrent une meilleure interface. Vous pouvez vouloir installer une application comme audio/mpg123 pour - écouter des fichiers audio MP3. Une méthode + écouter des fichiers audio MP3. + + Une autre méthode rapide pour tester la carte est d'envoyer des données au /dev/dsp, de la manière suivante: &prompt.user; cat filename > /dev/dsp où filename peut être n'importe quel fichier. Cette ligne de commande devrait produire des sons, confirmant le bon fonctionnement de la carte son. Les niveaux du mixer de la carte son peuvent être modifiés par la commande &man.mixer.8;. Plus de détails peuvent être trouvés dans la page de manuel &man.mixer.8;. Problèmes courants fichiers spéciaux de périphérique port d'E/S IRQ DSP Erreur Solution - - unsupported subdevice XX - Un ou plusieurs fichiers spéciaux de - périphérique n'ont pas été - créés correctement. Répétez les - étapes précédentes. - - sb_dspwr(XX) timed out Le port d'E/S n'est pas configuré correctement. bad irq XX L'IRQ sélectionnée est incorrecte. Vérifiez que l'IRQ choisie et l'IRQ de la carte son sont les mêmes. xxx: gus pcm not attached, out of memory Il n'y a pas suffisamment de mémoire disponible pour utiliser ce périphérique. xxx: can't open /dev/dsp! Vérifiez avec la commande fstat | grep dsp si une autre application maintient le périphérique ouvert. Souvent à l'origine de ce type de problème on trouve esound et le support son de KDE. Munish Chopra Contribution de Utiliser des sources sonores multiples Il est souvent intéressant de pouvoir jouer simultanément du son à partir de multiples sources, comme lorsque esound ou artsd ne supportent pas le partage du périphérique son avec certaines applications. FreeBSD vous permet de le faire par l'intermédiaire de Canaux Sonores Virtuels, qui peuvent - être configurés avec la fonction &man.sysctl.8;. Les canaux - virtuels vous permettent de multiplexer les canaux de sortie de + être activés avec la fonction &man.sysctl.8;. Les canaux + virtuels vous permettent de multiplexer la sortie de votre carte son en mixant le son au niveau du noyau. Pour configurer le nombre de canaux virtuels, il existe deux paramètres de sysctl qui, si vous avez les privilèges de l'utilisateur root, peuvent être configurés comme ceci: &prompt.root; sysctl hw.snd.pcm0.vchans=4 &prompt.root; sysctl hw.snd.maxautovchans=4 L'exemple ci-dessus alloue quatre canaux virtuels, ce qui est un nombre suffisant pour une utilisation classique. hw.snd.pcm0.vchans est le nombre de canaux virtuels que possède pcm0, et est configurable une fois que le périphérique a été attaché au système. hw.snd.maxautovchans est le nombre de canaux virtuels alloués à un nouveau périphérique audio quand il est attaché à l'aide de &man.kldload.8;. Comme le module pcm peut être chargé indépendamment des pilotes de périphériques, hw.snd.maxautovchans peut stocker combien de canaux virtuels seront alloués à chaque périphérique attaché par la suite. Vous ne pouvez pas modifier le nombre de canaux virtuels pour un périphérique en cours d'utilisation. Quittez avant tout autre chose les programmes utilisant le périphérique en question, comme les lecteurs de fichiers sonores ou les daemons audios. Si vous n'utilisez pas &man.devfs.5;, vous devrez faire pointer vos applications sur /dev/dsp0.x, où x est 0 à 3 si hw.snd.pcm.0.vchans est fixé à 4. Sur un système utilisant &man.devfs.5;, ce qui précède sera automatiquement effectué - de façon transparente pour l'utilisateur. + de façon transparente pour le programme qui + réclame le périphérique + /dev/dsp0. Josef El-Rayes Contribution de Définir les valeurs par défaut du mixeur des différents canaux Les valeurs par défaut du mixeur des différents canaux sont fixées en dur dans le - code source du pilote &man.pcm.4;. Il existe de nombreuses + code source du pilote &man.pcm.4;. Il existe plusieurs applications et “daemons” qui vous permettent de - fixer les valeurs du mixeur, les mémorisent et les - refixent à chaque fois qu'ils sont lancés, mais - ce n'est pas une solution idéale, nous désirons + fixer les valeurs du mixeur qui seront mémorisées entre + chaque invocation, mais + ce n'est pas une solution idéale. Il est possible régler les valeurs par défaut au niveau du - pilote. Ceci se fait en définissant les valeurs + pilote — ceci se fait en définissant les valeurs adéquates dans le fichier /boot/device.hints. Par exemple: - hint.pcm.0.vol="100" + hint.pcm.0.vol="50" Cela fixera le volume du canal à une valeur par - défaut de 100; dès que le module &man.pcm.4; est + défaut de 50; dès que le module &man.pcm.4; est chargé. Chern Lee Contribution de Fichiers MP3 Les fichiers MP3 (MPEG Layer 3 Audio) donnent un son proche de la qualité d'un CD audio, il n'y a aucune raison pour que votre station de travail FreeBSD ne puisse pas en profiter. Lecteurs de MP3s De loin, le plus populaire des lecteurs MP3 pour X11 est XMMS (X Multimedia System). Les thèmes (skins) de Winamp peuvent être utilisés avec XMMS dès lors que l'interface est quasiment identique à celle du Winamp de Nullsoft. XMMS dispose aussi d'un support natif pour modules externes (plug-in). XMMS peut être installé à partir du catalogue de logiciels portés multimedia/xmms ou de la version pré-compilée. L'interface d'XMMS est intuitive, avec une liste de lecture, un égaliseur graphique, et plus. Ceux qui sont familiers avec Winamp trouveront XMMS simple d'utilisation. Le logiciel porté audio/mpg123 est une alternative, un lecteur de MP3 en ligne de commande. mpg123 peut être utilisé en spécifiant le périphérique sonore et le fichier MP3 sur la ligne de commande, comme montré ci-dessous: &prompt.root; mpg123 -a /dev/dsp1.0 Foobar-GreatestHits.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Playing MPEG stream from Foobar-GreastestHits.mp3 ... MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo /dev/dsp1.0 devrait être remplacé par le périphérique dsp correspondant sur votre système. Extraire les pistes de CDs Audio Avant d'encoder la totalité d'un CD ou une piste en MP3, les données audio doivent être extraites et transférées sur le disque dur. Cela se fait en copiant les données brutes CDDA (CD Digital Audio) en fichiers WAV. L'utilitaire cdda2wav, qui fait partie de la suite sysutils/cdrtools, est utilisé pour extraire les données audio de CDs et les informations rattachées. Avec le CD audio dans le lecteur, la commande suivante peut être utilisée (en tant que root) pour convertir l'intégralité d'un CD en fichiers WAV (un par piste): &prompt.root; cdda2wav -D 0,1,0 -B cdda2wav supportera également les lecteurs de CDROM ATAPI (IDE). Pour faire l'extraction à partir d'un lecteur IDE, précisez le nom du périphérique à la place de l'unité SCSI. Par exemple, pour extraite la piste 7 à partir d'un lecteur IDE: &prompt.root; cdda2wav -D /dev/acd0 -t 7 Le spécifie le périphérique SCSI 0,1,0, qui correspond à ce qui est donné par la commande cdrecord -scanbus. Pour extraire des pistes individuelles, utilisez l'option comme ceci: &prompt.root; cdda2wav -D 0,1,0 -t 7 Cet exemple extrait la septième piste du CD audio. Pour extraire un ensemble de pistes, par exemple, de la piste 1 à 7, précisez un intervalle: &prompt.root; cdda2wav -D 0,1,0 -t 1+7 L'utilitaire &man.dd.1; peut également être utilisé pour extraire des pistes audios à partir de lecteurs ATAPI, consultez la pour plus d'informations sur cette possibilité. Encoder des MP3s De nos jours, l'encodeur mp3 à utiliser est lame. Lame peut être trouvé dans le catalogue de logiciels portés: audio/lame. En utilisant les fichiers WAV extraits, la commande suivante convertira le fichier audio01.wav en audio01.mp3: &prompt.root; lame -h -b 128 \ --tt "La chanson XY" \ --ta "Artiste XY" \ --tl "Album XY" \ --ty "2001" \ --tc "Extrait et encodé par XY" \ --tg "Genre" \ audio01.wav audio01.mp3 128 kbits semble être le taux standard actuel du débit audio utilisé pour les MP3s. Nombreux sont ceux qui préfèrent des taux de haute qualité: 160 ou 192. Plus le débit audio est élevé plus l'espace disque utilisé par le fichier MP3 sera grand mais la qualité sera meilleure. L'option active le mode “haute qualité, mais un peu plus lent”. Les options commençant par indiquent des balises ID3, qui généralement contiennent les informations sur le morceau, devant être intégrées au fichier MP3. D'autres informations sur l'encodage peuvent être trouvées en consultant la page de manuel de Lame. Décoder des MP3s Afin de pouvoir graver un CD audio à partir de fichiers MP3, ces derniers doivent être convertis dans le format WAV non compressé. XMMS et mpg123 supportent tous les deux la sortie de fichiers MP3 en format de fichier non compressé. Ecriture sur le disque avec XMMS: Lancez XMMS. Clic-droit sur la fenêtre pour faire apparaître le menu d'XMMS. Sélectionner Preference sous Options. Changez l'option “Output Plugin” pour “Disk Writer Plugin”. Appuyez sur Configure. Entrez (ou choisissez browse) un répertoire où va être écrit le fichier décompressé. Chargez le fichier MP3 dans XMMS comme à l'accoutumé, avec le volume à 100% et l'égaliseur (EQ settings) désactivé. Appuyez sur Play — XMMS devrait se comporter comme s'il jouait le MP3, mais aucun son ne sera audible. Il est en fait en train de “jouer” le MP3 dans un fichier. Vérifiez que vous avez rétabli l'option “Output Plugin” à sa valeur de départ afin de pouvoir écouter à nouveau des MP3s. Ecriture sur le disque avec mpg123: Lancez mpg123 -s audio01.mp3 > audio01.pcm XMMS crée un fichier au format WAV, tandis que mpg123 convertit le fichier MP3 en données audio PCM brutes. Ces deux formats peuvent être utilisés avec cdrecord pour créer des CDs audio. Vous devez utiliser des fichiers PCM bruts avec &man.burncd.8;. Si vous utilisez des fichiers WAV, vous noterez un petit parasite au début de chaque piste, ce son est l'entête du fichier WAV. Vous pouvez simplement retirer l'entête d'un fichier WAV avec l'utilitaire SoX (il peut être installé à partir du logiciel porté audio/sox ou de la version pré-compilée): &prompt.user; sox -t wav -r 44100 -s -w -c 2 track.wav track.raw Lisez la pour plus d'informations sur l'utilisation d'un graveur de CD sous FreeBSD. Ross Lippert Contribution de Lecture des Vidéos Les applications pour lire des vidéos sont assez récentes et se développent très rapidement. Soyez patient. Tout ne va pas fonctionner aussi bien que cela pu être le cas avec le son. Avant que vous ne commenciez, vous devrez connaître le modèle de carte vidéo dont vous disposez ainsi que le circuit intégré qu'elle utilise. Alors qu'&xorg; et &xfree86; supportent une large variété de cartes vidéo, seul un petit nombre d'entre elles donne de bonnes performances en lecture de vidéos. Pour obtenir la liste des extensions supportées par le serveur X utilisant votre carte employez la commande &man.xdpyinfo.1; durant le fonctionnement d'X11. C'est une bonne idée d'avoir un court fichier MPEG qui pourra être utilisé comme fichier test pour évaluer divers lecteurs et leurs options. Comme certains programmes de lecture de DVD chercheront un support DVD sur /dev/dvd par défaut, ou ont ce périphérique fixé définitivement dans leur code, vous pourrez trouver utile de créer des liens symboliques vers les périphériques corrects: &prompt.root; ln -sf /dev/acd0 /dev/dvd &prompt.root; ln -sf /dev/acd0 /dev/rdvd Notez qu'en raison de la nature du système &man.devfs.5;, les liens créés à la main comme les précédents ne seront pas conservés si vous redémarrez le système. Afin de créer automatiquement les liens symboliques dès que vous redémarrez votre système, ajoutez les lignes suivantes au fichier /etc/devfs.conf: link acd0 dvd link acd0 rdvd De plus, le décodage de DVD, qui nécessite de faire appel à des fonctions spéciales du lecteur de DVD, demande d'avoir la permission d'écrire sur les périphériques DVD. Pour augmenter la mémoire partagée pour l'interface X11, il est recommandé que les valeurs de certaines variables &man.sysctl.8; soient augmentées: kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 Déterminer les capacités vidéo XVideo SDL DGA Il y a plusieurs manières possibles pour afficher de la vidéo sous X11. Ce qui fonctionnera vraiment est énormément dépendant du matériel. Chaque méthode décrite ci-dessous donnera différents résultats en fonction du matériel. De plus, le rendu de la vidéo sous X11 est un sujet recevant beaucoup d'attention dernièrement, et avec chaque nouvelle version d'&xorg;, ou d'&xfree86;, il pourra y avoir des améliorations significatives. Une liste des interfaces vidéo communes: X11: sortie X11 classique utilisant de la mémoire partagée. XVideo: une extension de l'interface X11 qui supporte la vidéo sur n'importe quelle partie de l'écran contrôlé par X11. SDL: “Simple Directmedia Layer” - couche simple d'accès directe au média. DGA: “Direct Graphics Access” - accès direct au graphique. SVGAlib: couche graphique bas niveau pour la console. XVideo &xorg; et &xfree86; 4.X disposent d'une extension appelée XVideo (également connue sous les termes Xvideo, Xv, ou xv) qui permet d'afficher directement de la vidéo à travers une accélération spécifique. Cette extension fournit une très bonne qualité de rendu même sur les machines bas de gamme. Pour vérifier si l'extension fonctionne utilisez xvinfo: &prompt.user; xvinfo XVideo est supporté pour votre carte si le résultat de la commande ressemble à: X-Video Extension version 2.2 screen #0 Adaptor #0: "Savage Streams Engine" number of ports: 1 port base: 43 operations supported: PutImage supported visuals: depth 16, visualID 0x22 depth 16, visualID 0x23 number of attributes: 5 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_SATURATION" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_HUE" (range -180 to 180) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 1024 x 1024 Number of image formats: 7 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x36315652 (RV16) guid: 52563135-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x3e0, 0x7c00 id: 0x35315652 (RV15) guid: 52563136-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x7e0, 0xf800 id: 0x31313259 (Y211) guid: 59323131-0000-0010-8000-00aa00389b71 bits per pixel: 6 number of planes: 3 type: YUV (packed) id: 0x0 guid: 00000000-0000-0000-0000-000000000000 bits per pixel: 0 number of planes: 0 type: RGB (packed) depth: 1 red, green, blue masks: 0x0, 0x0, 0x0 Notez également que les formats listés (YUV2, YUV12, etc...) ne sont pas présents dans chaque implémentation d'XVideo et leur absence pourra gêner certains programmes. Si le résultat ressemble à: X-Video Extension version 2.2 screen #0 no adaptors present Alors XVideo n'est probablement pas supporté pour votre carte. Si XVideo n'est pas supporté pour votre carte, cela signifie seulement qu'il sera plus difficile pour votre système d'affichage de répondre aux demandes du rendu vidéo en termes de puissance de calcul. En fonction de votre carte vidéo et de votre processeur, vous pourriez encore obtenir de bons résultats. Vous devriez probablement vous documenter sur les méthodes pour améliorer les performances en lisant la . “Simple Directmedia Layer” - couche simple d'accès directe au média La couche simple d'accès directe au média, SDL, a été prévue pour être une couche de portage entre µsoft.windows;, BeOS, et &unix;, permettant à des applications “cross-platform” qui font un usage efficace du son et du graphique d'être développées. La couche SDL fournit une abstraction de bas niveau vers le matériel qui peut parfois être plus efficace que l'interface X11. La bibliothèque SDL peut être trouvée dans devel/sdl12. “Direct Graphics Access” - accès direct au graphique L'accès direct au graphique est une extension X11 qui permet à un programme de bypasser le serveur X et d'accéder directement au matériel. Comme il repose sur une copie bas niveau de la mémoire, les programmes l'utilisant doivent être exécutés avec les privilèges de l'utilisateur root. L'extension DGA et ses performances peuvent être testées avec &man.dga.1;. Quand dga est exécuté, il changera les couleurs de l'affichage à chaque appui sur une touche. Pour quitter, utilisez la touche q. Logiciels portés et pré-compilés relatifs à la vidéo logiciels portés vidéo logiciels pré-compilés vidéo Cette section traite des logiciels disponibles dans le catalogue des logiciels portés de FreeBSD qui peuvent être utilisés pour lire de la vidéo. Les applications vidéos sont un domaine de développement très actif, et les capacités de diverses applications seront sujettes à des divergences avec la description donnée ici. Premièrement, il est important de savoir que plusieurs des applications vidéos fonctionnant sous FreeBSD ont été développées comme des applications pour Linux. Plusieurs de ces applications sont encore considérées comme étant de qualité bêta. Parmi les problèmes que l'on peut rencontrer avec les applications vidéos sous &os;, nous trouvons: Une application ne peut pas lire un fichier produit par une autre application. Une application ne peut pas lire un fichier quelle a produit. La même application sur deux machines différentes, recompilée sur chaque machine pour la machine elle-même, jouera le fichier différemment. Un filtre apparemment insignifiant comme un changement d'échelle de l'image donne de très mauvais résultats en raison d'une routine de changement d'échelle boguée. Une application qui plante régulièrement. La documentation n'est pas installée avec le logiciel porté et peut être trouvée sur Internet ou dans le répertoire work du logiciel porté. Parmin ces applications, nombreuses sont celles qui peuvent présenter des “Linuxismes”. Aussi, il y peut y avoir des problèmes résultants de la façon dont certaines bibliothèques standards sont implémentées dans les distributions Linux, ou certaines caractéristiques du noyau Linux qui ont été employées par les auteurs des applications. Ces problèmes ne sont pas toujours remarqués et contournés par les responsables du portage du logiciel ce qui peut mener vers quelques ennuis comme ceux-ci: L'utilisation de /proc/cpuinfo pour détecter les caractéristiques du processeur. Une mauvaise utilisation des “threads” qui provoque le blocage de programme au lieu de se terminer complètement. Des logiciels habituellement utilisés en conjonction avec l'application ne sont pas encore dans le catalogue des logiciels portés. Jusqu'ici, les développeurs de ces applications ont été coopératifs avec les responsables des logiciels portés pour minimiser les modifications nécessaires au portage. MPlayer MPlayer est une application pour lire des vidéos récemment et rapidement développée. Les objectifs de l'équipe de MPlayer sont la rapidité et la flexibilité sur Linux et autre &unix;. Le projet fut démarré quand le fondateur de l'équipe en eu assez des mauvaises performances en lecture des autres lecteurs disponibles. Certains diront que l'interface graphique a été sacrifiée pour une conception rationalisée. Cependant, une fois que vous avez les options en ligne de commande et les combinaisons de touches en main, cela fonctionne très bien. Compiler MPlayer mplayer compilation MPlayer réside dans multimedia/mplayer. MPlayer effectue un certain nombre de contrôle du matériel durant le processus de compilation, il en résulte un binaire qui ne sera pas portable d'un système à l'autre. Ainsi il est important d'utiliser le logiciel porté et de ne pas utiliser un logiciel pré-compilé. En plus, un certain nombre d'options peuvent être spécifiées dans la ligne de commande make, comme décrit dans le fichier Makefile et au départ de la compilation: &prompt.root; cd /usr/ports/multimedia/mplayer &prompt.root; make N - O - T - E Take a careful look into the Makefile in order to learn how to tune mplayer towards you personal preferences! For example, make WITH_GTK1 builds MPlayer with GTK1-GUI support. If you want to use the GUI, you can either install /usr/ports/multimedia/mplayer-skins or download official skin collections from http://www.mplayerhq.hu/homepage/dload.html Les options par défaut du logiciel porté devraient être suffisantes pour la plupart des utilisateurs. Cependant si vous avez besoin du codec XviD, vous devez spécifier l'option WITH_XVID dans la ligne de commande. Le périphérique DVD par défaut peut également être défini avec l'option WITH_DVD_DEVICE, par défaut /dev/acd0 sera utilisé. Au moment de l'écriture de ces lignes, le logiciel porté de MPlayer compilera sa documentation HTML et deux exécutables, mplayer et mencoder, qui est un outil pour ré-encoder de la vidéo. La documentation HTML de MPlayer est très complète. Si le lecteur trouve l'information sur le matériel vidéo et les interfaces manquante dans ce chapitre, la documentation de MPlayer est une alternative très complète. Vous devriez certainement prendre le temps de lire la documentation de MPlayer, si vous êtes à la recherche d'informations sur le support vidéo sous &unix;. Utiliser MPlayer MPlayer utiliser Chaque utilisateur de MPlayer doit créer un sous-répertoire .mplayer dans son répertoire d'utilisateur. Pour créer ce sous-répertoire nécessaire, vous pouvez taper ce qui suit: &prompt.user; cd /usr/ports/multimedia/mplayer &prompt.user; make install-user Les options de commande de mplayer sont données dans la page de manuel. Pour plus de détails il y a la documentation HTML. Dans cette section, nous décrirons que quelques unes des utilisations les plus courantes. Pour lire à un fichier, comme testfile.avi en utilisant une des diverses interfaces vidéo utilisez l'option : &prompt.user; mplayer -vo xv testfile.avi &prompt.user; mplayer -vo sdl testfile.avi &prompt.user; mplayer -vo x11 testfile.avi &prompt.root; mplayer -vo dga testfile.avi &prompt.root; mplayer -vo 'sdl:dga' testfile.avi Cela vaut la peine d'essayer toutes ces options, comme leur performance relative dépend de nombreux facteurs et variera de façon significative avec le matériel. Pour lire un DVD, remplacez testfile.avi par où N est le numéro du titre à jouer et DEVICE est le fichier spécial de périphérique correspondant au lecteur de DVD. Par exemple, pour jouer le titre 3 depuis /dev/dvd: &prompt.root; mplayer -vo xv dvd://3 -dvd-device /dev/dvd Le périphérique DVD par défaut peut être défini lors de la compilation du logiciel porté MPlayer par l'intermédiaire de l'option WITH_DVD_DEVICE. Par défaut, ce périphérique est /dev/acd0. Plus de détails peuvent être trouvés dans le Makefile du logiciel porté. Pour arrêter, avancer, etc..., consultez les combinaisons de touches, qui sont données en exécutant mplayer -h ou lisez la page de manuel. D'autres options importantes pour la lecture sont: qui active le mode plein écran et qui aide au niveau des performances. Pour que la ligne de commande à taper ne devienne pas trop longue, l'utilisateur peut créer un fichier .mplayer/config et y fixer les options par défaut: vo=xv fs=yes zoom=yes Enfin, mplayer peut être utilisé pour extraire une piste du DVD dans un fichier .vob. Pour récupérer la seconde piste vidéo d'un DVD, tapez ceci: &prompt.root; mplayer -dumpstream -dumpfile out.vob dvd://2 -dvd-device /dev/dvd Le fichier de sortie, out.vob, sera du MPEG et peut être manipulé par les autres logiciels décrits dans cette section. mencoder mencoder Avant d'utiliser mencoder c'est une bonne idée de vous familiariser avec les options données par la documentation HTML. Il existe une page de manuel, mais elle n'est pas très utile sans la documentation en HTML. Il y a d'innombrables façons d'améliorer la qualité, diminuer le débit binaire, et modifier les formats, et certaines de ces options peuvent faire la différence entre de bonnes et mauvaises performances. Voici quelques exemples pour y arriver. Tout d'abord une simple copie: &prompt.user; mencoder input.avi -oac copy -ovc copy -o output.avi De mauvaises combinaisons d'options peuvent conduire à des fichiers illisibles même par mplayer. Aussi, si vous voulez juste extraire un fichier, restez sur l'option de mplayer. Pour convertir input.avi au format MPEG4 avec un codage audio MPEG3 (audio/lame est nécessaire): &prompt.user; mencoder input.avi -oac mp3lame -lameopts br=192 \ -ovc lavc -lavcopts vcodec=mpeg4:vhq -o output.avi Ceci a produit un fichier lisible par mplayer et xine. input.avi peut être remplacé par et exécuté en tant que root pour ré-encoder directement un titre DVD. Puisque vous êtes susceptible de ne pas être satisfait du résultat la première fois, il est recommandé d'extraire le titre vers un fichier et de travailler sur le fichier. Le lecteur xine Le lecteur xine est un projet de grande envergure visant non seulement à être une solution vidéo tout-en-un, mais également de produire une bibliothèque de base réutilisable et un exécutable modulaire qui peut être étendu grâce à des greffons. Il est fourni sous forme pré-compilée et de logiciel porté, multimedia/xine. Le lecteur xine est encore un peu brut, mais c'est clairement un bon début. Dans la pratique, xine demande soit un processeur rapide avec une carte vidéo rapide, soit l'extension XVideo. L'interface graphique est utilisable, mais peu pratique. Au moment de l'écriture de ces lignes, il n'y a pas de module d'entrée fourni avec xine qui lira les DVDs codés en CSS. Il existe des versions tiers qui ont des modules à cet effet intégrés, mais aucune de ces dernières ne se trouve dans le catalogue des logiciels portés de FreeBSD. Comparé à MPlayer, xine fait plus pour l'utilisateur, mais au même moment, rend inaccessible à l'utilisateur certains contrôles bien précis. Le lecteur xine se comporte le mieux sur les interfaces XVideo. Par défaut, le lecteur xine lancera une interface graphique. Les menus peuvent alors être utilisés pour ouvrir un fichier précis: &prompt.user; xine Alternativement, le lecteur peut être invoqué pour jouer directement un fichier sans l'interface graphique avec la commande: &prompt.user; xine -g -p mymovie.avi Les utilitaires transcode Le logiciel transcode n'est pas un lecteur, mais une suite d'outils pour ré-encoder les fichiers audio et vidéo. Avec transcode, on a la capacité de fusionner des fichiers vidéos, réparer les fichiers endommagés, en utilisant les outils en ligne de commande avec des interfaces de flots stdin/stdout. Un grand nombre d'options peut être précisé lors de la compilation du logiciel porté multimedia/transcode, nous recommandons d'utiliser la ligne de commande suivante pour compiler transcode: &prompt.root; make WITH_OPTIMIZED_CFLAGS=yes WITH_LIBA52=yes WITH_LAME=yes WITH_OGG=yes \ WITH_MJPEG=yes -DWITH_XVID=yes Le paramétrage proposé devrait convenir à la plupart des utilisateurs. Pour illustrer les capacités de transcode, voici un exemple montrant comment convertir un fichier DivX en fichier MPEG-1 en standard PAL (VCD PAL): &prompt.user; transcode -i input.avi -V --export_prof vcd-pal -o output_vcd &prompt.user; mplex -f 1 -o output_vcd.mpg output_vcd.m1v output_vcd.mpa Le fichier MPEG résultant, output_vcd.mpg, peut être directement lu avec MPlayer. Vous pourrez même le graver sur un CD pour créer ainsi un Vidéo CD; dans ce cas vous devrez installer et utiliser les programmes multimedia/vcdimager et sysutils/cdrdao. Il existe une page de manuel pour transcode, mais il est conseillé de consulter également le wiki de transcode pour plus d'information et des exemples. Lectures supplémentaires Les différents logiciels vidéo pour &os; se développent rapidement. Il est fort possible que dans un futur proche plusieurs des problèmes abordés ici seront résolus. Entre temps ceux qui veulent tirer partie des possibilités audio/vidéo de FreeBSD devront se débrouiller avec des connaissances extraites de plusieurs FAQs et guides et utiliser différentes applications. Cette section existe pour fournir au lecteur des références sur ces documentations additionnelles. La documentation de MPlayer est techniquement très instructive. Ces documents devraient probablement être consultés par quiconque désirant obtenir un niveau élevé d'expertise sur la vidéo et &unix;. La liste de diffusion de MPlayer est hostile à toute personne qui n'a pas pris la peine de lire la documentation, aussi si vous projetez de leur envoyer des rapports de bogue, lisez la documentation! Le HOWTO de xine contient un chapitre sur l'amélioration des performances qui est général à tous les lecteurs de vidéo. Et enfin, il y a quelques autres applications prometteuses que le lecteur devrait essayer: Avifile qui est également un logiciel porté multimedia/avifile. Ogle qui est également un logiciel porté multimedia/ogle. Xtheater multimedia/dvdauthor, un logiciel libre pour la création de DVDs. Josef El-Rayes Contibution originale de Marc Fonvieille Augmentée et adaptée par Configuration des cartes TV cartes TV Introduction Les cartes TV vous permettent de regarder sur votre ordinateur la télévision par voie hertzienne ou par câble. La plupart d'entre elles acceptent de la vidéo composite par l'intermédiaire de connecteurs RCA ou S-video et certaines de ces cartes disposent d'un tuner radio FM. &os; founit le support pour les cartes TV PCI utilisant un circuit de capture video Brooktree Bt848/849/878/879 ou Conexant CN-878/Fusion 878a à l'aide du pilote &man.bktr.4;. Vous devez également vous assurer que la carte dispose d'un tuner supporté, consultez la page de manuel &man.bktr.4; pour une liste des tuners supportés. Ajout du pilote de périphérique Pour utiliser votre carte, vous devrez charger le pilote &man.bktr.4;, cela peut être effectué en ajoutant la ligne suivante au fichier /boot/loader.conf: bktr_load="YES" Alternativement, vous pouvez compiler en statique dans le noyau le support pour la carte TV, dans ce cas ajouter les lignes suivantes dans votre fichier de configuration du noyau: device bktr device iicbus device iicbb device smbus Ces pilotes de périphériques supplémentaires sont nécessaires étant donné que les composants de la carte sont interconnectés via un bus I2C. Compilez et installez, ensuite, un nouveau noyau. Une fois que le support a été ajouté au système, vous devez redémarrer votre machine. Durant le processus de démarrage, votre carte TV devrait apparaître de cette manière: bktr0: <BrookTree 848A> mem 0xd7000000-0xd7000fff irq 10 at device 10.0 on pci0 iicbb0: <I2C bit-banging driver> on bti2c0 iicbus0: <Philips I2C bus> on iicbb0 master-only iicbus1: <Philips I2C bus> on iicbb0 master-only smbus0: <System Management Bus> on bti2c0 bktr0: Pinnacle/Miro TV, Philips SECAM tuner. Bien évidemment ces messages peuvent varier en fonction de votre matériel. Cependant assurez-vous que le tuner est correctement détecté; il est possible de forcer certains des paramètres détecté à l'aide du système &man.sysctl.8; et d'options de configuration du noyau. Par exemple, si vous désirez forcer le tuner pour un tuner Philips SECAM, vous devrez ajouter la ligne suivante au fichier de configuration du noyau: options OVERRIDE_TUNER=6 ou vous pouvez directement utiliser &man.sysctl.8;: &prompt.root; sysctl hw.bt848.tuner=6 Consultez la page de manuel &man.bktr.4; et le fichier /usr/src/sys/conf/NOTES pour plus de détails sur les options disponibles. Applications utiles Pour utiliser votre carte TV, vous devrez installer une des applications suivantes: multimedia/fxtv qui permet de regarder la télévision et d'enregistrer des images, du son et de la vidéo. multimedia/xawtv est également une application pour regarder la télévision avec les mêmes fonctionnalités que fxtv. misc/alevt décode et affiche les informations Vidéotexte/Télétexte. audio/xmradio, un programme pour utiliser le tuner FM fourni avec certaines cartes TV. audio/wmtune, une application intégrable dans votre environnement de travail pour gérer les tuners radio. Plus d'applications sont disponibles dans le catalogue des logiciels portés de &os;. En cas de problème Si vous rencontrez un quelconque problème avec votre carte TV, vous devriez contrôler tout d'abord que le circuit de capture video et le tuner sont vraiment supportés par le pilote &man.bktr.4; et si vous avez utilisé les bonnes options de configuration. Pour plus de support et pour les diverses questions que vous pouvez vous poser à propos de votre carte TV, vous pouvez contacter et utiliser les archives de la liste de diffusion &a.multimedia.name;. Marc Fonvieille Ecrit par Scanners scanners Introduction Sous &os;, l'accès aux scanners est possible grâce à l'API SANE (Scanner Access Now Easy) disponible dans le catalogue des logiciels portés. SANE utilisera également certains pilotes de périphériques &os; pour accéder à la partie matérielle du scanner. &os; supporte les scanners SCSI et USB. Assurez-vous que votre scanner est supporté par SANE avant d'effectuer une quelconque configuration. SANE dispose d'une liste des périphériques supportés qui peut vous informer sur le support et son statut pour un scanner particulier. La page de manuel &man.uscanner.4; donne également une liste des scanners USB supportés. Configuration du noyau Comme mentionné plus haut les interfaces SCSI et USB sont supportées. En fonction de l'interface de votre scanner, différents pilotes de périphérique sont nécessaires. Interface USB Le noyau GENERIC inclu par défaut les pilotes nécessaires au support des scanners USB. Si vous décidez d'utiliser un noyau personnalisé, assurez-vous que les lignes suivantes sont présentes dans votre fichier de configuration du noyau: device usb device uhci device ohci device uscanner En fonction du contrôleur USB présent sur votre carte mère, vous n'avez besoin que d'une des deux lignes device uhci et device ohci, cependant avoir ces deux lignes simultanément dans la configuration du noyau est sans risque. Si vous ne désirez pas recompiler votre noyau et que votre noyau n'est pas le GENERIC, vous pouvez directement charger le module du pilote &man.uscanner.4; à l'aide de la commande &man.kldload.8;: &prompt.root; kldload uscanner Pour charger ce module à chaque démarrage du système, ajoutez la ligne suivante au fichier /boot/loader.conf: uscanner_load="YES" Après avoir redémarré avec le bon noyau, ou après avoir chargé le module nécessaire, branchez votre scanner USB. Une ligne montrant la détection de votre scanner devrait apparaître dans le tampon des messages du système (&man.dmesg.8;): uscanner0: EPSON EPSON Scanner, rev 1.10/3.02, addr 2 Ceci nous indique que notre scanner utilise le fichier spécial de périphérique /dev/uscanner0. Interface SCSI Si votre scanner dispose d'une interface SCSI, il est important de connaître quelle carte contrôleur SCSI vous utiliserez. En fonction du contrôleur sur la carte, vous devrez adapter votre configuration du noyau. Le noyau GENERIC supporte les contrôleurs SCSI les plus courants. Assurez-vous d'avoir lu le fichier NOTES et ajoutez la ligne adéquate dans votre fichier de configuration du noyau. En plus du pilote de votre carte SCSI, vous avez besoin des lignes suivantes dans votre fichier de configuration du noyau: device scbus device pass Une fois que votre noyau a été correctement compilé et installé, vous devriez être en mesure de voir les périphériques au démarrage: pass2 at aic0 bus 0 target 2 lun 0 pass2: <AGFA SNAPSCAN 600 1.10> Fixed Scanner SCSI-2 device pass2: 3.300MB/s transfers Si votre scanner n'était pas alimenté au démarrage du système, il est encore possible de forcer sa détection, en en sondant le bus SCSI avec la commande &man.camcontrol.8;: &prompt.root; camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful Ensuite le scanner apparaîtra dans la liste des périphériques SCSI: &prompt.root; camcontrol devlist <IBM DDRS-34560 S97B> at scbus0 target 5 lun 0 (pass0,da0) <IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1) <AGFA SNAPSCAN 600 1.10> at scbus1 target 2 lun 0 (pass3) <PHILIPS CDD3610 CD-R/RW 1.00> at scbus2 target 0 lun 0 (pass2,cd0) Plus de détails sur les périphériques SCSI sont disponibles dans les pages de manuel &man.scsi.4; et &man.camcontrol.8;. Configuration de SANE Le système SANE est divisé en deux parties: les backends (graphics/sane-backends) et les frontends (graphics/sane-frontends). Les backends fournissent l'accès au scanner. La liste des périphériques supportés par SANE indique quel backend supportera votre scanner. Il est indispensable de déterminer correctement le backend relatif à votre scanner si vous voulez être en mesure d'utiliser votre périphérique. La partie frontends fournie l'interface graphique de numérisation (xscanimage). La première étape est d'installer le logiciel porté graphics/sane-backends ou sa version pré-compilée. Ensuite, utilisez la commande sane-find-scanner pour contrôler la détection du scanner par l'ensemble SANE: &prompt.root; sane-find-scanner -q found SCSI scanner "AGFA SNAPSCAN 600 1.10" at /dev/pass3 Le résultat de la commande affichera le type d'interface utilisée par le scanner et le fichier spécial de périphérique utilisé pour attacher le scanner au système. Le fabricant et le modèle peuvent ne pas apparaître, cela n'est pas important. Certains scanners USB requièrent le chargement préalable d'un firmware, cela est expliqué dans la page de manuel du backend utilisé. Vous devriez également consulter les pages de manuel de &man.sane-find-scanner.1; et &man.sane.7;. Nous devons maintenant vérifier si le scanner sera identifié par un frontend de numérisation. Par défaut, les backends SANE sont fournies avec un outil en ligne de commande appelé &man.scanimage.1;. Cette commande vous permet de lister les périphériques et d'effectuer une acquisition d'image à partir de la ligne de commande. L'option est employée pour afficher les scanners présents sur le système: &prompt.root; scanimage -L device `snapscan:/dev/pass3' is a AGFA SNAPSCAN 600 flatbed scanner Aucun résultat, ou un message disant qu'aucun scanner n'a été identifié indiquent que &man.scanimage.1; est incapable d'identifier le scanner. Si cela se produit, vous devrez éditer le fichier de configuration du backend du scanner et définir le type de scanner utilisé. Le répertoire /usr/local/etc/sane.d/ contient tous les fichiers de configurations des backends. Ce problème d'identification apparaît essentiellement avec certains scanners USB. Par exemple, avec le scanner USB utilisé dans la , sane-find-scanner nous donne l'information suivante: &prompt.root; sane-find-scanner -q found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 Le scanner est correctement détecté, il utilise l'interface USB et est attaché au fichier spécial de périphérique /dev/uscanner0. Nous pouvons maintenant vérifier si le scanner est correctement identifié: &prompt.root; scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Comme le scanner n'est pas identifié, nous devons éditer le fichier /usr/local/etc/sane.d/epson.conf. Le scanner utilisé était un &epson.perfection; 1650, nous en déduisons donc que ce scanner utilisera le backend epson. Assurez-vous de bien lire les commentaires d'aide présents dans les fichiers de configuration des backends. Les modifications à faire sont relativement simples: commentez toutes les lignes concernant une interface différente de celle utilisée par votre scanner (dans notre cas, nous commenterons toutes les lignes débutant par le mot scsi étant donné que notre scanner utilise une interface USB), ajoutez ensuite à la fin du fichier une ligne indiquant l'interface et le fichier spécial de périphérique utilisé. Dans ce cas, nous ajoutons la ligne suivante: usb /dev/uscanner0 Veuillez vous assurer de bien lire les commentaires fournis dans les fichiers de configurations des backends ainsi que les pages de manuel correspondantes pour plus de détails concernant la syntaxe correcte à utiliser. Nous pouvons maintenant vérifier si le scanner est identifié: &prompt.root; scanimage -L device `epson:/dev/uscanner0' is a Epson GT-8200 flatbed scanner Notre scanner a été identifié. Ce n'est pas important si la marque et le modèle ne correspondent pas au scanner. L'important est le champ `epson:/dev/uscanner0', qui nous donne le backend et le fichier spécial de périphérique corrects. Une fois que la commande scanimage -L est en mesure d'identifier le scanner, la configuration est terminée. Le périphérique est prêt à effectuer sa première numérisation. Bien que &man.scanimage.1; permette d'effectuer une numérisation à partir de la ligne de commande, il est préférable d'utiliser une interface graphique. SANE offre une interface graphique simple mais efficace: xscanimage (graphics/sane-frontends). Xsane (graphics/xsane) est une autre interface graphique de numérisation assez populaire. Ce programme offre des fonctions avancées comme différents mode de numérisation (photocopie, fax, etc.), la correction des couleurs, la numérisation par lots, etc. Ces deux applications sont utilisables comme greffon pour GIMP. Donner l'accès au scanner aux autres utilisateurs Toutes les opérations précédentes ont été effectuées avec les privilèges root. Vous pourrez, cependant, avoir besoin que d'autres utilisateurs puissent accéder au scanner. L'utilisateur devra avoir les permissions de lecture et d'écriture sur le fichier spécial de périphérique /dev/uscanner0 dont le propriétaire est le groupe operator. L'ajout de l'utilisateur joe au groupe operator lui autorisera l'accès au scanner: &prompt.root; pw groupmod operator -m joe Pour plus de détails, consultez la page de manuel de &man.pw.8;. Vous devez également fixer les permissions d'écriture correctes (0660 or 0664) sur le fichier spécial de périphérique /dev/uscanner0, par défaut le groupe operator n'a qu'un accès en lecture. Cela se fait en ajoutant les lignes suivantes au fichier /etc/devfs.rules: [system=5] add path uscanner0 mode 660 Ajoutez ensuite ce qui suit au fichier /etc/rc.conf et redémarrez la machine: devfs_system_ruleset="system" Plus d'information concernant ces lignes peut être trouvée dans la page de manuel &man.devfs.8;. Bien sûr, pour des raisons de sécurité, vous devriez réfléchir à deux fois avant d'ajouter un utilisateur à n'importe quel groupe, tout particulièrement au groupe operator. diff --git a/fr_FR.ISO8859-1/books/handbook/network-servers/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/network-servers/chapter.sgml index 7c0e1bb57b..02189d6f17 100644 --- a/fr_FR.ISO8859-1/books/handbook/network-servers/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/network-servers/chapter.sgml @@ -1,5566 +1,5566 @@ Murray Stokely Réorganisé par Serveurs réseau &trans.a.fonvieille; Synopsis Ce chapitre abordera certains des services réseaux les plus fréquemment utilisés sur les systèmes &unix;. Nous verrons comment installer, configurer, tester et maintenir plusieurs types différents de services réseaux. De plus, des exemples de fichier de configuration ont été inclus tout au long de ce chapitre pour que vous puissiez en bénéficier. Après la lecture de ce chapitre, vous connaîtrez: Comment gérer le “daemon” inetd. Comment configurer un système de fichiers réseau. Comment mettre en place un serveur d'information sur le réseau pour partager les comptes utilisateurs. Comment configurer le paramétrage réseau automatique en utilisant DHCP. Comment configurer un serveur de noms de domaine. Comment configurer le serveur HTTP Apache. Comment configurer un serveur de transfert de fichier (FTP). Comment configurer un serveur de fichiers et d'impression pour des clients &windows; en utilisant Samba. Comment synchroniser l'heure et la date, et mettre en place en serveur de temps, avec le protocole NTP. Avant de lire ce chapitre, vous devrez: Comprendre les bases des procédures /etc/rc. Etre familier avec la terminologie réseau de base. Savoir comment installer des applications tierce-partie (). Chern Lee Contribution de Mise à jour pour &os; 6.1-RELEASE par le projet de documentation de &os; Le “super-serveur” <application>inetd</application> Généralités On fait parfois référence à &man.inetd.8; comme étant le “super-serveur Internet” parce qu'il gère les connexions pour plusieurs services. Quand une connexion est reçue par inetd, ce dernier détermine à quel programme la connexion est destinée, invoque le processus en question et lui délègue la “socket” (le programme est invoqué avec la “socket” service comme entrée standard, sortie et descripteurs d'erreur). Exécuter inetd pour les serveurs qui ne sont pas utilisés intensément peut réduire la charge système globale quand on compare avec l'exécution de chaque “daemon” individuellement en mode autonome. inetd est utilisé pour invoquer d'autres “daemon”s, mais plusieurs protocoles triviaux sont gérés directement, comme chargen, auth, et daytime. Cette section abordera la configuration de base d'inetd à travers ses options en ligne de commande et son fichier de configuration /etc/inetd.conf. Configuration inetd est initialisé par l'intermédiaire du système &man.rc.8;. L'option inetd_enable est positionnée à la valeur NO par défaut, mais peut être activée par sysinstall lors de l'installation en fonction de la configuration choisie par l'utilisateur. Placer inetd_enable="YES" ou inetd_enable="NO" dans /etc/rc.conf activera ou désactivera le lancement d'inetd à la mise en route du système. La commande: &prompt.root; /etc/rc.d/inetd rcvar peut être lancée pour afficher le paramétrage en vigueur. De plus, différentes options de ligne de commande peuvent être passées à inetd par l'intermédiaire de l'option inetd_flags. Options en ligne de commande Comme la plupart des daemons, inetd possède de nombreuses options que l'on peut passer à son lancement afin de modifier son comportement. La liste complète des options se présente sous la forme: inetd Les options peuvent être passées à inetd en utilisant le paramètre inetd_flags dans /etc/rc.conf. Par défaut, inetd_flags contient -wW -C 60, qui active le TCP wrapping pour les services inetd, et empêche l'invocation d'un service plus de 60 fois par minute à partir d'une unique adresse IP. Les novices seront heureux d'apprendre que ce paramétrage n'a en général pas besoin d'être modifié, cependant nous présentons ci-dessous les options de limitation du taux d'invocation étant donné que cela peut être utile si vous recevez une quantité excessive de connexions. Une liste complète d'options peut être trouvée dans la page de manuel de &man.inetd.8;. -c maximum Spécifie le nombre maximal par défaut d'invocations simultanées pour chaque service; il n'y a pas de limite par défaut. Cette option peut être surchargée pour chaque service à l'aide du paramètre . -C taux Précise le nombre maximal de fois qu'un service peut être invoqué à partir d'une unique adresse IP et cela sur une minute. Ce paramètre peut être configuré différemment pour chaque service avec le paramètre . -R taux Précise le nombre maximal de fois qu'un service peut être invoqué par minute; la valeur par défaut est 256. Un taux de 0 autorise un nombre illimité d'invocations. -s maximum Précise le nombre maximal de fois qu'un service peut être invoqué simultanément à partir d'une adresse IP unique; il n'y a pas de limite par défaut. Cette option peut-être surchargée pour chaque service individuellement avec le paramètre . <filename>inetd.conf</filename> La configuration d'inetd se fait par l'intermédiaire du fichier /etc/inetd.conf. Quand le fichier /etc/inetd.conf est modifié, inetd peut être forcé de relire son fichier de configuration en utilisant la commande: Recharger le fichier de configuration d'<application>inetd</application> &prompt.root; /etc/rc.d/inetd reload Chaque ligne du fichier de configuration ne mentionne qu'un seul “daemon”. Les commentaires dans le fichier sont précédés par un “#”. Le format de chaque entrée du fichier /etc/inetd.conf est le suivant: nom-du-service type-de-socket protocole {wait|nowait}[/nb-max-enfants[/nb-connexions-max-par-minute]] {wait|nowait}[/nb-max-enfants[/nb-connexions-max-par-minute[/nb-max-enfants-par-ip]]] utilisateur[:groupe][/classe-session] programme-serveur arguments-du-programme-serveur Un exemple d'entrée pour le “daemon” &man.ftpd.8; utilisant l'IPv4 ressemblerait: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l nom-du-service C'est le nom de service du “daemon” en question. Il doit correspondre à un des services listés dans le fichier /etc/services. Cela détermine quel port inetd doit écouter. Si un nouveau service est créé, il doit être ajouté en premier lieu dans /etc/services. type-de-socket Soit stream, soit dgram, soit raw, ou seqpacket. stream doit être utilisé pour les “daemon”s TCP, alors que dgram est utilisé pour les “daemon”s utilisant le protocole UDP. protocole Un des suivants: Protocole Explication tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 et v6 udp46 UDP IPv4 et v6 {wait|nowait}[/nb-max-enfants[/nb-max-connexions-par-ip-par-minute[/nb-max-enfants-par-ip]]] indique si le “daemon” invoqué par inetd est capable ou non de gérer sa propre “socket”. Les “socket”s de type doivent utiliser l'option , alors que les “daemons à socket stream”, qui sont généralement multi-threadés, devraient utiliser . L'option a généralement pour conséquence de fournir plusieurs “socket”s à un “daemon”, tandis que l'option invoquera un “daemon” enfant pour chaque nouvelle “socket”. Le nombre maximal de “daemon”s qu'inetd peut invoquer peut être fixé en utilisant l'option . Si une limite de dix instances pour un “daemon” est nécessaire, /10 devra être placé après . Spécifier /0 autorise un nombre illimité d'enfant. En plus de , deux autres options limitant le nombre maximal de connexions à partir d'un emplacement vers un “daemon” particulier peuvent être activéees. L'option limite le nombre de connexions par minutes à partir d'une adresse IP donnée, par exemple, une valeur de dix limiterait à dix le nombre de tentatives de connexions par minute pour une adresse IP particulière. L'option limite le nombre d'enfants qui peuvent être lancés pour une adresse IP unique à un instant donné. Ces options sont utiles pour empêcher l'abus excessif intentionnel ou par inadvertance des ressources d'une machine et les attaques par déni de service (Denial of Service—DOS). Dans ce champ, ou est obligatoire. , et sont optionnelles. Un “daemon” utilisant un flux de type multi-threadé sans limites , ou sera tout simplement affecté de l'option nowait. Le même “daemon” avec une limite maximale de dix “daemon” serait: nowait/10. La même configuration avec une limite de vingt connexions par adresse IP par minute et une limite maximale de dix “daemon”s enfant serait: nowait/10/20. Ces options sont utilisées comme valeurs par défaut par le “daemon” &man.fingerd.8;, comme le montre ce qui suit: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Et enfin, un exemple de champ avec un maximum de 100 enfants en tout, avec un maximum de 5 adresses IP distinctes serait: nowait/100/0/5. utilisateur C'est l'utilisateur sous lequel le “daemon” en question est exécuté. En général les “daemon”s tournent sous l'utilisateur root. Pour des questions de sécurité, il est courant de rencontrer des serveurs tournant sous l'utilisateur daemon, ou sous l'utilisateur avec le moins de privilèges: nobody. programme-serveur Le chemin complet du “daemon” qui doit être exécuté quand une requête est reçue. Si le “daemon” est un service fourni en interne par inetd, alors l'option devrait être utilisée. arguments-programme-serveur Cette option va de pair avec en précisant les arguments, en commençant avec argv[0], passés au “daemon” lors de son invocation. Si mydaemon -d est la ligne de commande, mydaemon -d sera la valeur de l'option . Ici également, si le “daemon” est un service interne, utilisez . Sécurité En fonction des choix effectués à l'installation, plusieurs services peuvent être activés par défaut. S'il n'y a pas de raison particulière à l'utilisation d'un “daemon”, envisagez de le désactiver. Ajoutez un caractère “#” devant le “daemon” en question dans le fichier /etc/inetd.conf, et ensuite rechargez la configuration d'inetd. Certains daemons comme fingerd, devraient être évités parce qu'ils peuvent fournir des informations utiles aux personnes malveillantes. Certains “daemon”s n'ont aucune conscience des problèmes de sécurité, et ont un long délai limite, ou pas du tout, d'expiration pour les tentatives de connexions. Cela permet à une personne malveillante d'envoyer régulièrement et de manière espacée des demandes de connexions à un “daemon” particulier, avec pour conséquence de saturer les ressources disponibles. Cela peut être une bonne idée de placer des limitations , ou sur certains daemons si vous trouvez que vous avez trop de connexions. Par défaut, le “TCP wrapping” est activé. Consultez la page de manuel &man.hosts.access.5; pour plus d'information sur le placement de restrictions TCP pour divers “daemon”s invoqués par inetd. Divers daytime, time, echo, discard, chargen, et auth sont des services fournis en interne par inetd. Le service auth fournit les services réseau d'identification, et est configurable à un certain degré, alors que les autres services ne peuvent être que stoppés ou en fonctionnement. Consultez la page de manuel de &man.inetd.8; pour plus d'informations. Tom Rhodes Réorganisé et augmenté par Bill Swingle Ecrit par Système de fichiers réseau (NFS) NFS Parmi les différents systèmes de fichiers que &os; supporte se trouve le système de fichiers réseau, connu sous le nom de NFS. NFS permet à un système de partager des répertoires et des fichiers avec d'autres systèmes par l'intermédiaire d'un réseau. En utilisant NFS, les utilisateurs et les programmes peuvent accéder aux fichiers sur des systèmes distants comme s'ils étaient des fichiers locaux. Certains des avantages les plus remarquables offerts par NFS sont: Les stations de travail utilisent moins d'espace disque en local parce que les données utilisées en commun peuvent être stockées sur une seule machine tout en restant accessibles aux autres machines sur le réseau. Les utilisateurs n'ont pas besoin d'avoir un répertoire personnel sur chaque machine du réseau. Les répertoires personnels pourront se trouver sur le serveur NFS et seront disponibles par l'intermédiaire du réseau. Les périphériques de stockage comme les lecteurs de disquettes, de CDROM, de disquettes &iomegazip; peuvent être utilisés par d'autres machines sur le réseau. Cela pourra réduire le nombre de lecteurs de medias amovibles sur le réseau. Comment <acronym>NFS</acronym> fonctionne NFS consiste en deux éléments principaux: un serveur et un ou plusieurs clients. Le client accède à distance aux données stockées sur la machine serveur. Afin que tout cela fonctionne correctement quelques processus doivent être configurés et en fonctionnement. Sur le serveur, les “daemons” suivants doivent tourner: NFS serveur serveur de fichiers clients UNIX rpcbind mountd nfsd Daemon Description nfsd Le “daemon” NFS qui répond aux requêtes des clients NFS. mountd Le “daemon” de montage NFS qui traite les requêtes que lui passe &man.nfsd.8;. rpcbind Ce daemon permet aux clients NFS de trouver le port que le serveur NFS utilise. Le client peut également faire tourner un “daemon” connu sous le nom de nfsiod. Le “daemon” nfsiod traite les requêtes en provenance du serveur NFS. Ceci est optionnel, et améliore les performances, mais n'est pas indispensable pour une utilisation normale et correcte. Consultez la page de manuel &man.nfsiod.8; pour plus d'informations. Configurer <acronym>NFS</acronym> NFS configuration La configuration de NFS est une opération relativement directe. Les processus qui doivent tourner peuvent tous être lancés au démarrage en modifiant légèrement votre fichier /etc/rc.conf. Sur le serveur NFS, assurez-vous que les options suivantes sont configurées dans le fichier /etc/rc.conf: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd est automatiquement exécuté dès que le serveur NFS est activé. Sur le client, assurez-vous que cette option est présente dans le fichier /etc/rc.conf: nfs_client_enable="YES" Le fichier /etc/exports indique quels systèmes de fichiers NFS devraient être exportés (parfois on utilise le terme de “partagés”). Chaque ligne dans /etc/exports précise un système de fichiers à exporter et quelles machines auront accès à ce système de fichiers. En plus des machines qui auront accès, des options d'accès peuvent également être présentes. Ces options sont nombreuses mais seules quelques unes seront abordées ici. Vous pouvez aisément découvrir d'autres options en lisant la page de manuel &man.exports.5;. Voici quelques exemples d'entrées du fichier /etc/exports: NFS exemples d'exportation Les exemples suivants donnent une idée de comment exporter des systèmes de fichiers bien que certains paramètres peuvent être différents en fonction de votre environnement et votre configuration réseau. Par exemple, pour exporter le répertoire /cdrom pour les trois machines d'exemple qui appartiennent au même domaine que le serveur (d'où l'absence du nom de domaine pour chacune d'entre elles) ou qui ont une entrée dans votre fichier /etc/hosts. Le paramètre limite l'accès en lecture seule au système de fichiers exporté. Avec ce paramètre, le système distant ne pourra pas écrire sur le système de fichiers exporté. /cdrom -ro host1 host2 host3 La ligne suivante exporte /home pour les trois machines en utilisant les adresses IP. C'est une configuration utile si vous disposez d'un réseau privé sans serveur DNS configuré. Le fichier /etc/hosts pourrait éventuellement être configuré pour les noms de machines internes, consultez la page de manuel &man.hosts.5; pour plus d'information. Le paramètre autorise l'utilisation des sous-répertoires en tant que point de montage. En d'autres termes, il ne montera pas les sous-répertoires mais autorisera le client à ne monter que les répertoires qui sont nécessaires ou désirés. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 La ligne suivante exporte /a pour que deux clients d'un domaine différent puissent y accéder. Le paramètre autorise l'utilisateur root du système distant à écrire des données sur le système de fichiers exporté en tant que root. Si le paramètre -maproot=root n'est pas précisé, même si un utilisateur dispose d'un accès root sur le système distant, il ne pourra pas modifier de fichiers sur le système de fichiers exporté. /a -maproot=root host.example.com box.example.org Afin de pouvoir accéder à un système de fichiers exporté, le client doit avoir les permissions de le faire. Assurez-vous que le client est mentionné dans votre fichier /etc/exports. Dans /etc/exports, chaque ligne représente l'information d'exportation d'un système de fichiers vers une machine. Une machine distante ne peut être spécifiée qu'une fois par système de fichiers, et ne devrait avoir qu'une seule entrée par défaut. Par exemple, supposons que /usr soit un seul système de fichiers. Le fichier /etc/exports suivant serait invalide: # Invalide quand /usr est un système de fichiers /usr/src client /usr/ports client Un système de fichiers, /usr, a deux lignes précisant des exportations vers la même machine, client. Le format correct pour une telle situation est: /usr/src /usr/ports client Les propriétés d'un système de fichiers exporté vers une machine donnée devraient apparaître sur une ligne. Les lignes sans client sont traitées comme destinée à une seule machine. Cela limite la manière dont vous pouvez exporter les systèmes de fichiers, mais pour la plupart des gens cela n'est pas un problème. Ce qui suit est un exemple de liste d'exportation valide, où les répertoires /usr et /exports sont des systèmes de fichiers locaux: # Exporte src et ports vers client01 et client02, mais seul # client01 dispose des privilèges root dessus /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # Les machines clientes ont les privilèges root et peuvent monter tout # de /exports. N'importe qui peut monter en lecture seule # /exports/obj /exports -alldirs -maproot=root client01 client02 /exports/obj -ro Le daemon mountd doit être forcé de relire le fichier /etc/exports à chacune de ses modifications, afin que les changements puissent prendre effet. Cela peut être effectué soit en envoyant un signal HUP au daemon: &prompt.root; kill -HUP `cat /var/run/mountd.pid` soit en invoquant la procédure &man.rc.8; de mountd avec le paramètre approprié: &prompt.root; /etc/rc.d/mountd onereload Veuillez consulter la pour plus d'information sur l'utilisation des procédures rc. De plus, un redémarrage permettra à &os; de tout configurer proprement. Un redémarrage n'est cependant pas nécéssaire. Exécuter les commandes suivantes en tant que root devrait mettre en place ce qui est nécessaire. Sur le serveur NFS: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Sur le client NFS: &prompt.root; nfsiod -n 4 Maintenant il devrait être possible de monter un système de fichiers distant. Dans nos exemples le nom du serveur sera serveur et le nom du client client. Si vous voulez monter temporairement un système de fichiers distant ou vous voulez simplement tester la configuration, exécutez juste une commande comme celle-ci en tant que root sur le client: NFS montage &prompt.root; mount serveur:/home /mnt Cela montera le répertoire /home situé sur le serveur au point /mnt sur le client. Si tout est correctement configuré vous devriez être en mesure d'entrer dans le répertoire /mnt sur le client et de voir tous les fichiers qui sont sur le serveur. Si vous désirez monter automatiquement un système de fichiers distant à chaque démarrage de l'ordinateur, ajoutez le système de fichiers au fichier /etc/fstab. Voici un exemple: server:/home /mnt nfs rw 0 0 La page de manuel &man.fstab.5; liste toutes les options disponibles. Verrouillage Certaines applications (par exemple mutt) ont besoin du verrouillage des fichiers pour fonctionner correctement. Dans le cas du NFS, rpc.lockd peut être utilisé pour assurer le verrouillage des fichiers. Pour l'activer, ajouter ce qui suit au fichier /etc/rc.conf sur les machines clientes et serveur (on suppose que les clients et le serveur NFS sont déjà configurés): rpc_lockd_enable="YES" rpc_statd_enable="YES" Lancez l'application en utilisant: &prompt.root; /etc/rc.d/nfslocking start Si un verrouillage réel n'est pas nécessaire entre les clients et le serveur NFS, il est possible de laisser le client NFS effectuer le verrouillage localement en passant l'option à &man.mount.nfs.8;. Veuillez vous référer à la page de manuel &man.mount.nfs.8; pour de plus amples détails. Exemples pratiques d'utilisation Il existe de nombreuses applications pratiques de NFS. Les plus communes sont présentés ci-dessous: NFS utilisations Configurer plusieurs machines pour partager un CDROM ou un autre médium. C'est moins cher et souvent une méthode plus pratique pour installer des logiciels sur de multiples machines. Sur les réseaux importants, il peut être plus pratique de configurer un serveur NFS central sur lequel tous les répertoires utilisateurs sont stockés. Ces répertoires utilisateurs peuvent alors être exportés vers le réseau, les utilisateurs devraient alors toujours avoir le même répertoire utilisateur indépendamment de la station de travail sur laquelle ils ouvrent une session. Plusieurs machines pourront avoir un répertoire /usr/ports/distfiles commun. De cette manière, quand vous avez besoin d'installer un logiciel porté sur plusieurs machines, vous pouvez accéder rapidement aux sources sans les télécharger sur chaque machine. Wylie Stilwell Contribution de Chern Lee Réécrit par Montages automatiques avec <application>amd</application> amd daemon de montage automatique &man.amd.8; (“automatic mounter daemon”—“daemon” de montage automatique) monte automatiquement un système de fichiers distant dès que l'on accède à un fichier ou un répertoire contenu par ce système de fichiers. Les systèmes de fichiers qui sont inactifs pendant une certaine période seront automatiquement démontés par amd. L'utilisation d'amd offre une alternative simple aux montages permanents qui sont généralement listés dans /etc/fstab. amd opère en s'attachant comme un serveur NFS aux répertoires /host et /net. Quand on accède à un fichier à l'intérieur de ces répertoires, amd recherche le montage distant correspondant et le monte automatiquement. /net est utilisé pour monter un système de fichiers exporté à partir d'une adresse IP, alors que /host est utilisé pour monter un système de fichiers exporté à partir d'un nom de machine distant. Un accès à un fichier dans /host/foobar/usr demandera à amd de tenter de monter l'export /usr sur la machine foobar. Monter un systèmes de fichiers exporté avec <application>amd</application> Vous pouvez voir les systèmes de fichiers exportés par une machine distante avec la commande showmount. Par exemple, pour voir les répertoires exportés par une machine appelée foobar, vous pouvez utiliser: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr Comme on le voit dans l'exemple, showmount liste /usr comme une exportation. Quand on change de répertoire pour /host/foobar/usr, amd tente de résoudre le nom de machine foobar et de monter automatiquement le système exporté désiré. amd peut être lancé par les procédures de démarrage en ajoutant les lignes suivantes dans le fichier /etc/rc.conf: amd_enable="YES" De plus, des paramètres peuvent être passés à amd à l'aide de l'option amd_flags. Par défaut, l'option amd_flags est possitionnée à: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" Le fichier /etc/amd.map définit les options par défaut avec lesquelles les systèmes exportés sont montés. Le fichier /etc/amd.map définit certaines des fonctionnalités les plus avancées de amd. Consultez les pages de manuel de &man.amd.8; et &man.amd.conf.5; pour plus d'informations. John Lind Contribution de Problèmes d'intégration avec d'autres systèmes Certaines cartes Ethernet ISA présentent des limitations qui peuvent poser de sérieux problèmes sur un réseau, en particulier avec NFS. Ce n'est pas une particularité de &os;, mais &os; en est également affecté. Ce problème se produit pratiquement à chaque fois que des systèmes (&os;) PC sont sur le même réseau que des stations de travail très performantes, comme celles de Silicon Graphics, Inc. et Sun Microsystems, Inc. Les montages NFS se feront sans difficulté, et certaines opérations pourront réussir, puis soudain le serveur semblera ne plus répondre au client, bien que les requêtes vers ou en provenance d'autres systèmes continueront à être traitées normalement. Cela se manifeste sur la machine cliente, que ce soit le système &os; ou la station de travail. Sur de nombreux systèmes, il n'est pas possible d'arrêter le client proprement une fois que ce problème apparaît. La seule solution est souvent de réinitialiser le client parce que le problème NFS ne peut être résolu. Bien que la solution “correcte” est d'installer une carte Ethernet plus performante et de plus grande capacité sur le système &os;, il existe une solution simple qui donnera satisfaction. Si le système &os; est le serveur, ajoutez l'option lors du montage sur le client. Si le système &os; est le client, alors montez le système de fichiers NFS avec l'option . Ces options peuvent être spécifiées dans le quatrième champ de l'entrée fstab sur le client pour les montages automatiques, ou en utilisant le paramètre de la commande &man.mount.8; pour les montages manuels. Il faut noter qu'il existe un problème différent, que l'on confond parfois avec le précédent, qui peut se produire lorsque les serveurs et les clients NFS sont sur des réseaux différents. Si c'est le cas, assurez-vous que vos routeurs transmettent bien les informations UDP nécessaires, ou vous n'irez nulle part, quoi que vous fassiez par ailleurs. Dans les exemples suivants, fastws est le nom de la station de travail (interface) performante, et freebox celui d'une machine (interface) &os; avec une carte Ethernet moins performante. /sharedfs est le système de fichiers NFS qui sera exporté (consulter la page de manuel &man.exports.5;), et /project sera le point de montage sur le client pour le système de fichiers exporté. Dans tous les cas, des options supplémentaires, telles que et seront peut-être nécessaires pour vos applications. Exemple d'extrait du fichier /etc/fstab sur freebox quand le système &os; (freebox) est le client: fastws:/sharedfs /project nfs rw,-r=1024 0 0 Commande de montage manuelle sur freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Exemple d'extrait du fichier /etc/fstab sur fastws quand le système &os; est le serveur: freebox:/sharedfs /project nfs rw,-w=1024 0 0 Commande de montage manuelle sur fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Presque n'importe quelle carte Ethernet 16 bits permettra d'opérer sans l'utilisation des paramètres restrictifs précédents sur les tailles des tampons de lecture et d'écriture. Pour ceux que cela intéresse, voici ce qui se passe quand le problème survient, ce qui explique également pourquoi ce n'est pas récupérable. NFS travaille généralement avec une taille de “bloc” de 8 k (bien qu'il arrive qu'il les fragmente en de plus petits morceaux). Comme la taille maximale d'un paquet Ethernet est de 1500 octets, le “bloc” NFS est divisé en plusieurs paquets Ethernet, bien qu'il soit toujours vu comme quelque chose d'unitaire par les couches supérieures du code, et doit être réceptionné, assemblé, et acquitté comme tel. Les stations de travail performantes peuvent traiter les paquets qui composent le bloc NFS les uns après les autres, pratiquement aussi rapidement que le standard le permet. Sur les cartes les plus petites, de moindre capacité, les derniers paquets d'un même bloc écrasent les paquets précédents avant qu'ils aient pu être transmis à la machine et le bloc ne peut être réassemblé ou acquitté. Avec pour conséquence, le dépassement du délai d'attente sur la station de travail qui recommence alors la transmission, mais en renvoyant l'intégralité des 8 K, et ce processus se répète à l'infini. En définissant la taille de bloc inférieure à la taille d'un paquet Ethernet, nous nous assurons que chaque paquet Ethernet complet sera acquitté individuellement, évitant ainsi la situation de blocage. Des écrasements peuvent toujours survenir quand des stations de travail performantes surchargent un système PC de données, mais avec de meilleures cartes, de tels écrasements ne sont pas systématiques pour les “blocs” NFS. Quand un écrasement apparaît, les blocs affectés sont retransmis, et ils y a de fortes chances pour qu'ils soient reçus, assemblés et acquittés. Bill Swingle Ecrit par Eric Ogren Augmenté par Udo Erdelhoff Services d'information réseau (NIS/YP) Qu'est-ce que c'est? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS, qui signifie “Network Information Services” (services d'information réseau), fut développé par Sun Microsystems pour centraliser l'administration de systèmes &unix; (à l'origine &sunos;). C'est devenu aujourd'hui un standard industriel; tous les systèmes importants de type &unix; (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os;, etc.) supportent NIS. yellow pagesNIS NIS était appelé au départ “Yellow Pages” (page jaunes), mais étant donné que c'était marque déposée, Sun changea le nom. L'ancienne appelation (et yp) est toujours rencontrée et utilisée. NIS domaines C'est un système client/serveur basé sur les RPCs qui permet à un groupe de machines d'un domaine NIS de partager un ensemble de fichiers de configuration communs. Cela permet à un administrateur système de mettre en place des clients NIS avec un minimum de configuration et d'ajouter, modifier ou supprimer les informations de configuration à partir d'un unique emplacement. Windows NT C'est similaire au système de domaine &windowsnt;; bien que l'implémentation interne des deux n'est pas du tout identique, les fonctionnalités de base sont comparables. Termes/processus à connaître Il existe plusieurs termes et processus utilisateurs que vous rencontrerez lors de la configuration de NIS sous &os;, que vous vouliez mettre en place un serveur NIS ou un client NIS: rpcbind portmap Terme Description Nom de domaine NIS Un serveur maître NIS et tous ses clients (y compris ses serveurs esclaves) ont un domaine NIS. Similaire au nom de domaine &windowsnt;, le nom de domaine NIS n'a rien à voir avec le système DNS. rpcbind Doit tourner afin d'activer les RPC (Remote Procedure Call, appel de procédures distantes, un protocole réseau utilisé par NIS). Si rpcbind ne tourne pas, il sera impossible de faire fonctionner un serveur NIS, ou jouer le rôle d'un client NIS. ypbind Fait pointer un client NIS vers son serveur NIS. Il récupérera le nom de domaine NIS auprès du système, et en utilisant les RPC, se connectera au serveur. ypbind est le coeur de la communication client-serveur dans un environnement NIS; si ypbind meurt sur une machine cliente, elle ne sera pas en mesure d'accéder au serveur NIS. ypserv Ne devrait tourner que sur les serveurs NIS, c'est le processus serveur en lui-même. Si &man.ypserv.8; meurt, alors le serveur ne pourra plus répondre aux requêtes NIS (avec un peu de chance, un serveur esclave prendra la relève). Il existe des implémentations de NIS (mais ce n'est pas le cas de celle de &os;), qui n'essayent pas de se reconnecter à un autre serveur si le serveur utilisé précédement meurt. Souvent, la seule solution dans ce cas est de relancer le processus serveur (ou même redémarrer le serveur) ou le processus ypbind sur le client. rpc.yppasswdd Un autre processus qui ne devrait tourner que sur les serveurs maître NIS; c'est un “daemon” qui permettra aux clients de modifier leur mot de passe NIS. Si ce “daemon” ne tourne pas, les utilisateurs devront ouvrir une session sur le serveur maître NIS et y changer à cet endroit leur mot de passe. Comment cela fonctionne-t-il? Dans un environnement NIS il y a trois types de machines: les serveurs maîtres, les serveurs esclaves et les clients. Les serveurs centralisent les informations de configuration des machines. Les serveurs maîtres détiennent l'exemplaire de référence de ces informations, tandis que les serveurs esclaves en ont un double pour assurer la redondance. Les clients attendent des serveurs qu'ils leur fournissent ces informations. Le contenu de nombreux fichiers peut être partagé de cette manière. Les fichiers master.passwd, group, et hosts sont fréquemment partagés par l'intermédiaire de NIS. A chaque fois qu'un processus d'une machine cliente a besoin d'une information qu'il trouverait normalement localement dans un de ces fichiers, il émet une requête au serveur NIS auquel il est rattaché pour obtenir cette information. Type de machine NIS serveur maître Un serveur NIS maître. Ce serveur, analogue à un contrôleur de domaine &windowsnt; primaire, gère les fichiers utilisés par tous les clients NIS. Les fichiers passwd, group, et les autres fichiers utilisés par les clients NIS résident sur le serveur maître. Il est possible pour une machine d'être un serveur NIS maître pour plus qu'un domaine NIS. Cependant, ce cas ne sera pas abordé dans cette introduction, qui suppose un environnement NIS relativement petit. NIS serveur esclave Serveurs NIS esclaves. Similaire aux contrôleurs de domaine &windowsnt; de secours, les serveurs NIS esclaves possèdent une copie des fichiers du serveur NIS maître. Les serveurs NIS esclaves fournissent la redondance nécessaire dans les environnements importants. Ils aident également à à la répartition de la charge du serveur maître: les clients NIS s'attachent toujours au serveur NIS dont ils reçoivent la réponse en premier, y compris si c'est la réponse d'un serveur esclave. NIS client Clients NIS. Les clients NIS, comme la plupart des stations de travail &windowsnt;, s'identifient auprès du serveur NIS (ou le contrôleur de domaine &windowsnt; dans le cas de stations de travail &windowsnt;) pour l'ouverture de sessions. Utiliser NIS/YP Cette section traitera de la configuration d'un exemple d'environnement NIS. Planification Supposons que vous êtes l'administrateur d'un petit laboratoire universitaire. Ce laboratoire dispose de 15 machines &os;, et ne possède pas actuellement de point central d'administration; chaque machine a ses propres fichiers /etc/passwd et /etc/master.passwd. Ces fichiers sont maintenus à jour entre eux grâce à des interventions manuelles; actuellement quand vous ajoutez un utilisateur pour le laboratoire, vous devez exécuter adduser sur les 15 machines. Cela doit changer, vous avez donc décidé de convertir le laboratoire à l'utilisation de NIS en utilisant deux machines comme serveurs. La configuration du laboratoire ressemble à quelque chose comme: Nom de machine Adresse IP Rôle de la machine ellington 10.0.0.2 Maître NIS coltrane 10.0.0.3 Esclave NIS basie 10.0.0.4 Station de travail bird 10.0.0.5 Machine cliente cli[1-11] 10.0.0.[6-17] Autres machines clientes Si vous mettez en place un système NIS pour la première fois, c'est une bonne idée de penser à ce que vous voulez en faire. Peu importe la taille de votre réseau, il y a quelques décisions à prendre. Choisir un nom de domaine NIS NIS nom de domaine Ce n'est pas le “nom de domaine” dont vous avez l'habitude. Il est plus exactement appelé “nom de domaine NIS”. Quand un client diffuse des requêtes pour obtenir des informations, il y inclut le nom de domaine NIS auquel il appartient. C'est ainsi que plusieurs serveurs d'un même réseau peuvent savoir lequel d'entre eux doit répondre aux différentes requêtes. Pensez au nom de domaine NIS comme le nom d'un groupe de machines qui sont reliées entre elles. Certains choisissent d'utiliser leur nom de domaine Internet pour nom de domaine NIS. Ce n'est pas conseillé parce que c'est une source de confusion quand il faut résoudre un problème réseau. Le nom de domaine NIS devrait être unique sur votre réseau et est utile s'il décrit le groupe de machines qu'il représente. Par exemple, le département artistique de Acme Inc. pourrait avoir “acme-art” comme nom de domaine NIS. Pour notre exemple, nous supposerons que vous avez choisi le nom test-domain. SunOS Cependant, certains systèmes d'exploitation (notamment &sunos;) utilisent leur nom de domaine NIS pour nom de domaine Internet. Si une ou plusieurs machines sur votre réseau présentent cette restriction, vous devez utiliser votre nom de domaine Internet pour nom de domaine NIS. Contraintes au niveau du serveur Il y a plusieurs choses à garder à l'esprit quand on choisit une machine destinée à être un serveur NIS. Un des problèmes du NIS est le degré de dépendance des clients vis à vis du serveur. Si un client ne peut contacter le serveur de son domaine NIS, la plupart du temps la machine n'est plus utilisable. L'absence d'information sur les utilisateurs et les groupes bloque la plupart des systèmes. Vous devez donc vous assurer de choisir une machine qui ne sera pas redémarré fréquemment, ni utilisée pour du développement. Idéalement, le serveur NIS devrait être une machine dont l'unique utilisation serait d'être un serveur NIS. Si vous avez un réseau qui n'est pas très chargé, il peut être envisagé de mettre le serveur NIS sur une machine fournissant d'autres services, gardez juste à l'esprit que si le serveur NIS n'est pas disponible à un instant donné, cela affectera tous vos clients NIS. Serveurs NIS La copie de référence de toutes les informations NIS est stockée sur une seule machine appelée serveur NIS maître. Les bases de données utilisées pour le stockage de ces informations sont appelées tables NIS (“NIS maps”). Sous &os; ces tables se trouvent dans /var/yp/[domainname] où [domainname] est le nom du domaine NIS concerné. Un seul serveur NIS peut gérer plusieurs domaines à la fois, il peut donc y avoir plusieurs de ces répertoires, un pour chaque domaine. Chaque domaine aura son propre jeu de tables. Les serveurs NIS maîtres et esclaves traitent toutes les requêtes NIS à l'aide du “daemon” ypserv. ypserv reçoit les requêtes des clients NIS, traduit le nom de domaine et le nom de table demandés en chemin d'accès à la base de données correspondante et transmet l'information de la base de données au client. Configurer un serveur NIS maître NIS configuration du serveur Selon vos besoins, la configuration d'un serveur NIS maître peut être relativement simple. &os; offre par défaut un support direct du NIS. Tout ce dont vous avez besoin est d'ajouter les lignes qui suivent au fichier /etc/rc.conf, et &os; s'occupera du reste pour vous. nisdomainname="test-domain" Cette ligne définie le nom de domaine NIS, test-domain, à la configuration du réseau (e.g. au démarrage). nis_server_enable="YES" Demandera à &os; de lancer les processus du serveur NIS dès que le réseau est en fonctionnement. nis_yppasswdd_enable="YES" Ceci activera le “daemon” rpc.yppasswdd, qui, comme mentionné précedement, permettra aux utilisateurs de modifier leur mot de passe à partir d'une machine cliente. Selon votre configuration NIS, vous aurez peut-être à ajouter des entrées supplémentaires. Consultez la section sur les serveurs NIS qui sont également des clients NIS, plus bas, pour plus de détails. Maintenant, tout ce que vous devez faire est d'exécuter la commande /etc/netstart en tant que super-utilisateur. Elle configurera tout en utilisant les valeurs que vous avez définies dans /etc/rc.conf. Initialisation des tables NIS NIS tables Les tables NIS sont des fichiers de base de données, qui sont conservés dans le répertoire /var/yp. Elles sont générées à partir des fichiers de configuration du répertoire /etc du serveur NIS maître, avec une exception: le fichier /etc/master.passwd. Et cela pour une bonne raison, vous ne voulez pas divulguer les mots de passe pour l'utilisateur root et autres comptes d'administration aux autres serveurs du domaine NIS. Par conséquent, avant d'initialiser les tables NIS, vous devrez faire: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Vous devrez effacer toutes les entrées concernant les comptes système (bin, tty, kmem, games, etc.), tout comme les comptes que vous ne désirez pas propager aux clients NIS (par exemple root et tout autre compte avec un UID 0 (super-utilisateur)). Assurez-vous que le fichier /var/yp/master.passwd n'est pas lisible par son groupe ou le reste du monde (mode 600)! Utilisez la commande chmod si nécessaire. Tru64 UNIX Cela achevé, il est temps d'initialiser les tables NIS! &os; dispose d'une procédure appelée ypinit pour le faire à votre place (consultez sa page de manuel pour plus d'informations). Notez que cette procédure est disponible sur la plupart des systèmes d'exploitation du type &unix;, mais pas tous. Sur Digital UNIX/Compaq Tru64 UNIX, elle est appelée ypsetup. Comme nous voulons générer les tables pour un maître NIS, nous passons l'option à ypinit. Pour générer les tables NIS, en supposant que vous avez effectué les étapes précédentes, lancez: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit devrait avoir créé /var/yp/Makefile à partir de /var/yp/Makefile.dist. Une fois créé, ce fichier suppose que vous être dans un environnement composé uniquement de machines &os; et avec un seul serveur. Comme test-domain dispose également d'un serveur esclave, vous devez éditer /var/yp/Makefile: ellington&prompt.root; vi /var/yp/Makefile Vous devez commenter la ligne NOPUSH = "True" (si elle n'est pas déjà commentée). Configurer un serveur NIS esclave NIS serveur esclave Configurer un serveur NIS esclave est encore plus simple que de configurer un serveur maître. Ouvrez une session sur le serveur esclave et éditez le fichier /etc/rc.conf comme précédemment. La seule différence est que nous devons maintenant utiliser l'option avec ypinit. L'option a besoin du nom du serveur NIS maître, donc notre ligne de commande ressemblera à: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Vous devriez avoir un répertoire appelé /var/yp/test-domain. Des copies des tables du serveur NIS maître devraient se trouver dans ce répertoire. Vous devrez vous assurer que ces tables restent à jour. Les entrées suivantes dans /etc/crontab sur vos serveurs esclaves s'en chargeront: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Ces deux lignes obligent le serveur esclave à synchroniser ses tables avec celles du serveur maître. Bien que ces entrées ne soient pas indispensables puisque le serveur maître essaye de s'assurer que toute modification de ses tables NIS soit répercutée à ses serveurs esclaves et comme l'information sur les mots de passe est vitale pour les systèmes qui dépendent du serveur, il est bon de forcer les mises à jour. C'est d'autant plus important sur les réseaux chargés où il n'est pas certain que les mises à jour soient intégrales. Maintenant, exécutez la commande /etc/netstart sur le serveur esclave, ce qui lancera le serveur NIS. Clients NIS Un client NIS établit une connexion avec un serveur NIS donné par l'intermédiaire du “daemon” ypbind. ypbind consulte le nom de domaine par défaut du système (défini par la commande domainname), et commence à diffuser des requêtes RPC sur le réseau local. Ces requêtes précisent le nom de domaine auquel ypbind essaye de se rattacher. Si un serveur configuré pour ce domaine reçoit une des requêtes diffusées, il répond à ypbind, qui enregistrera l'adresse du serveur. S'il y a plusieurs serveurs disponibles (un maître et plusieurs esclaves par example), ypbind utilisera l'adresse du premier à répondre. Dès lors, le système client dirigera toutes ses requêtes NIS vers ce serveur. ypbind enverra de temps en temps des requêtes “ping” au serveur pour s'assurer qu'il fonctionne toujours. S'il ne reçoit pas de réponse dans un laps de temps raisonnable, ypbind considérera ne plus être attaché au domaine et recommencera à diffuser des requêtes dans l'espoir de trouver un autre seveur. Configurer un client NIS NIS configuration du client Configurer une machine &os; en client NIS est assez simple. Editez le fichier /etc/rc.conf et ajoutez les lignes suivantes afin de définir le nom de domaine NIS et lancez ypbind au démarrage du réseau: nisdomainname="test-domain" nis_client_enable="YES" Pour importer tous les mots de passe disponibles du serveur NIS, effacez tous les comptes utilisateur de votre fichier /etc/master.passwd et utilisez vipw pour ajouter la ligne suivante à la fin du fichier: +::::::::: Cette ligne permet à chaque utilisateur ayant un compte valide dans les tables de mots de passe du serveur d'avoir un compte sur le client. Il y a plusieurs façons de configurer votre client NIS en modifiant cette ligne. Consultez la section groupes réseau plus bas pour plus d'informations. Pour en savoir plus, reportez-vous à l'ouvrage Managing NFS and NIS de chez O'Reilly. Vous devriez conservez au moins un compte local (i.e. non-importé via NIS) dans votre fichier /etc/master.passwd et ce compte devrait également être membre du groupe wheel. Si quelque chose se passe mal avec NIS, ce compte peut être utilisé pour ouvrir une session à distance, devenir root, et effectuer les corrections nécessaires. Pour importer tous les groupes disponibles du serveur NIS, ajoutez cette ligne à votre fichier /etc/group: +:*:: Une fois que c'est fait, vous devriez être en mesure d'exécuter ypcat passwd et voir la table des mots de passe du serveur NIS. Sécurité du NIS De façon générale, n'importe quel utilisateur distant peut émettre une requête RPC à destination de &man.ypserv.8; et récupérer le contenu de vos tables NIS, en supposant que l'utilisateur distant connaisse votre nom de domaine. Pour éviter ces transactions non autorisées, &man.ypserv.8; dispose d'une fonctionnalité appelée “securenets” qui peut être utilisée pour restreindre l'accès à un ensemble donné de machines. Au démarrage, &man.ypserv.8; tentera de charger les informations sur les “securenets” à partir d'un fichier nommé /var/yp/securenets. Ce chemin d'accès peut varier en fonction du chemin d'accès défini par l'option . Ce fichier contient des entrées sous la forme de définitions de réseau et d'un masque de sous-réseau séparé par une espace. Les lignes commençant par un “#” sont considérées comme des commentaires. Un exemple de fichier securenets peut ressembler à ceci: # autorise les connexions depuis la machine locale -- obligatoire 127.0.0.1 255.255.255.255 # autorise les connexions de n'importe quelle machine # du réseau 192.168.128.0 192.168.128.0 255.255.255.0 # autorise les connexions de n'importe quelle machine # entre 10.0.0.0 et 10.0.15.255 # y compris les machines du laboratoire de test 10.0.0.0 255.255.240.0 Si &man.ypserv.8; reçoit une requête d'une adresse qui satisfait à ces règles, il la traite normalement. Si une adresse ne correspond pas aux règles, la requête sera ignorée et un message d'avertissement sera enregistré. Si le fichier /var/yp/securenets n'existe pas, ypserv autorisera les connexions à partir de n'importe quelle machine. Le programme ypserv supporte également l'outil TCP Wrapper de Wietse Venema. Cela permet à l'administrateur d'utiliser les fichiers de configuration de TCP Wrapper pour contrôler les accès à la place de /var/yp/securenets. Bien que ces deux mécanismes de contrôle d'accès offrent une certaine sécurité, il sont, de même que le test du port privilégié, vulnérables aux attaques par “usurpation” d'adresses. Tout le trafic relatif à NIS devrait être bloqué par votre coupe-feu. Les serveurs utilisant /var/yp/securenets pourront échouer à traiter les requêtes de clients NIS légitimes avec des implémentation TCP/IP archaïques. Certaines de ces implémentations positionnent à zéro les bits de la partie machine de l'adresse IP lors de diffusions et/ou sont incapables respecter le masque de sous-réseau lors du calcul de l'adresse de diffusion. Alors que certains de ces problèmes peuvent être corrigés en modifiant la configuration du client, d'autres problèmes peuvent forcer le retrait des systèmes clients fautifs ou l'abandon de /var/yp/securenets. Utiliser /var/yp/securenets sur un serveur avec une implémentation TCP/IP archaïque est une mauvaise idée et sera à l'origine de pertes de la fonctionnalité NIS pour une grande partie de votre réseau. TCP Wrapper L'utilisation du système TCP Wrapper augmente les temps de latence de votre serveur NIS. Le délai supplémentaire peut être suffisament long pour dépasser le délai d'attente des programmes clients, tout particulièrement sur des réseaux chargés ou avec des serveurs NIS lents. Si un ou plusieurs de vos systèmes clients souffrent de ces symptômes, vous devrez convertir les systèmes clients en question en serveurs esclaves NIS et les forcer à se rattacher à eux-mêmes. Interdire l'accès à certains utilisateurs Dans notre laboratoire, il y a une machine basie qui est supposée être une station de travail de la faculté. Nous ne voulons pas retirer cette machine du domaine NIS, le fichier passwd sur le serveur maître NIS contient les comptes pour la faculté et les étudiants. Que pouvons-nous faire? Il existe une méthode pour interdire à certains utilisateurs d'ouvrir une session sur une machine, même s'ils sont présents dans la base de données NIS. Pour cela, tout ce dont vous avez besoin de faire est d'ajouter -nom_utilisateur à la fin du fichier /etc/master.passwd sur la machine cliente, où nom_utilisateur est le nom de l'utilisateur auquel vous désirez refuser l'accès. Ceci doit être fait de préférence avec vipw, puisque vipw contrôlera vos changements au fichier /etc/master.passwd, et régénérera automatiquement la base de données à la fin de l'édition. Par exemple, si nous voulions interdire l'ouverture de session à l'utilisateur bill sur la machine basie nous ferions: basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Contribution de Utiliser les groupes réseau (“netgroups”) groupes réseau La méthode présentée dans la section précédente fonctionne relativement bien si vous avez besoin de règles spécifiques pour un petit nombre d'utilisateurs et/ou de machines. Sur les réseaux plus important, vous oublierez d'interdire l'accès aux machines sensibles à certains utilisateurs, ou vous devrez même modifier chaque machine séparément, perdant par là même les avantages du NIS: l'administration centralisée. La solution des développeurs du NIS pour ce problème est appelé groupes réseau (“netgroups”). Leur objet et définition peuvent être comparés aux groupes utilisés par les systèmes &unix;. La principale différence étant l'absence d'identifiants (ID) numériques et la capacité de définir un groupe réseau à l'aide de comptes utilisateur et d'autres groupes réseau. Les groupes réseau furent développés pour gérer des réseaux importants et complexes avec des centaines de machines et d'utilisateurs. C'est une bonne option si vous êtes forcés de faire avec une telle situation. Cependant leur complexité rend impossible une explication avec des exemples simples. L'exemple utilisé dans le reste de cette section met en évidence ce problème. Supposons que l'introduction avec succès de NIS dans votre laboratoire a retenu l'attention de vos supérieurs. Votre mission suivante est d'étendre la couverture de votre domaine NIS à d'autres machines sur le campus. Les deux tables contiennent les noms des nouveaux utilisateurs et des nouvelles machines ainsi qu'une courte description de chacuns. Nom(s) d'utilisateurs Description alpha, beta Les employés du département IT (“Information Technology“) charlie, delta Les nouveaux apprentis du département IT echo, foxtrott, golf, ... Les employés ordinaires able, baker, ... Les internes actuels Nom(s) de machines Description war, death, famine, pollution Vos serveurs les plus importants. Seuls les employés du département IT sont autorisés à ouvrir des sessions sur ces machines. pride, greed, envy, wrath, lust, sloth Serveurs moins importants. Tous les membres du laboratoire IT sont autorisés à ouvrir des sessions sur ces machines. one, two, three, four, ... Stations de travail ordinaires. Seuls les employés réels sont autorisés à utiliser ces machines. trashcan Une très vielle machine sans données sensibles. Même les internes peuvent utiliser cette machine. Si vous avez essayé d'implémenter ces restrictions en bloquant séparément chaque utilisateur, vous avez dû ajouter une ligne -utilisateur à chaque fichier passwd de chaque système pour chaque utilisateur non-autorisé à ouvrir une session sur le système. Si vous omettez ne serait-ce qu'une entrée, vous aurez des problèmes. Il doit être possible de faire cela lors de la configuration initiale, cependant vous finirez par oublier d'ajouter les lignes pour de nouveaux utilisateurs lors d'opérations quotidiennes. Après tout, Murphy était quelqu'un d'optimiste. Traiter cette situation avec les groupes réseau présente plusieurs avantages. Chaque utilisateur n'a pas besoin d'être traité séparément; vous assignez un utilisateur à un ou plusieurs groupes réseau et autorisez ou refusez l'ouverture de session à tous les membres du groupe réseau. Si vous ajoutez une nouvelle machine, vous n'aurez à définir les restrictions d'ouverture de session que pour les groupes réseau. Ces modifications sont indépendantes les unes des autres, plus de “pour chaque combinaison d'utilisateur et de machine faire...” Si votre configuration NIS est réfléchie, vous n'aurez à modifier qu'une configuration centrale pour autoriser ou refuser l'accès aux machines. La première étape est l'initialisation de la table NIS du groupe réseau. La version &os; d'&man.ypinit.8; ne crée pas de table par défaut, mais son implémentation NIS la supportera une fois créée. Pour créer une table vide, tapez simplement ellington&prompt.root; vi /var/yp/netgroup et commencez à ajouter du contenu. Pour notre exemple, nous avons besoin de quatre groupes réseau: les employées du département IT, les apprentis du département IT, les employés normaux et les internes. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP etc. sont les noms des groupes réseau. Chaque groupement entre parenthèses ajoute un ou plusieurs comptes utilisateurs aux groupes. Les trois champs dans un groupement sont: Le nom de la/les machine(s) où les éléments suivants sont valides. Si vous ne précisez pas un nom de machine, l'entrée est valide sur toutes les machines. Si vous précisez un nom de machine, vous pénétrerez dans un royaume obscure, d'horreur et de confusion totale. Le nom du compte qui appartient au groupe réseau. Le domaine NIS pour le compte. Vous pouvez importer les comptes d'autres domaines NIS dans votre groupe réseau si vous êtes une de ces personnes malchanceuses avec plus d'un domaine NIS. Chacun de ces champs peut contenir des jokers. Consultez la page de manuel &man.netgroup.5; pour plus de détails. groupes réseau Les noms de groupes réseau plus long que 8 caractères ne devraient pas être utilisés, tout particulièrement si vous avez des machines utilisant d'autres systèmes d'exploitation dans votre domaine NIS. Les noms sont sensibles à la casse des caractères; utiliser des majuscules pour vos noms de groupes réseau est une méthode simple pour distinguer les utilisateurs, les machines et les noms de groupes réseau. Certains clients NIS (autres que &os;) ne peuvent gérer les groupes réseau avec un grand nombre d'entrées. Par exemple, certaines anciennes versions de &sunos; commencent à causer des problèmes si un groupe réseau contient plus de 15 entrées. Vous pouvez contourner cette limite en créant plusieurs sous-groupes réseau avec 15 utilisateurs ou moins et un véritable groupe réseau constitué des sous-groupes réseau: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Vous pouvez répéter ce processus si vous avez besoin de plus de 255 utilisateurs dans un seul groupe réseau. Activer et propager votre nouvelle table NIS est simple: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Ceci générera les trois tables NIS netgroup, netgroup.byhost et netgroup.byuser. Utilisez &man.ypcat.1; pour contrôler si vos nouvelles tables NIs sont disponibles: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser La sortie devrait être semblable au contenu de /var/yp/netgroup. La deuxième commande ne produira pas de sortie si vous n'avez pas précisé les groupes réseau spécifiques à une machine. La troisième commande peut être utilisée pour obtenir les listes des groupes réseau pour un utilisateur. La configuration du client est plutôt simple. Pour configurer le serveur war, vous devez lancer &man.vipw.8; et remplacer la ligne +::::::::: par +@IT_EMP::::::::: Maintenant, seules les données pour les utilisateurs définis dans le groupe réseau IT_EMP sont importées dans la base de données de mots de passe de war et seuls ces utilisateurs sont autorisés à ouvrir une session. Malheureusement, cette limitation s'applique également à la fonction ~ de l'interpréteur de commandes et toutes les routines de conversion entre nom d'utilisateur et identifiant numérique d'utilisateur. En d'autres termes, cd ~utilisateur ne fonctionnera pas, et ls -l affichera l'ID numérique à la place du nom d'utilisateur et find . -user joe -print échouera avec le message d'erreur No such user. Pour corriger cela, vous devrez importer toutes les entrées d'utilisateurs sans leur autoriser l'ouverture de session sur vos serveurs. Cela peut être fait en ajoutant une autre ligne au fichier /etc/master.passwd. Cette ligne devrait contenir: +:::::::::/sbin/nologin, signifiant “Importer toutes les entrées mais remplacer l'interpréteur de commandes avec /sbin/nologin dans les entrées importées”. Vous pouvez remplacer n'importe quel champ dans l'entrée passwd en plaçant une valeur par défaut dans votre fichier /etc/master.passwd. Assurez-vous que +:::::::::/sbin/nologin est placée après +@IT_EMP:::::::::. Sinon, tous les comptes utilisateur importés du NIS auront /sbin/nologin comme interpréteur de commandes. Après cette modification, vous ne devrez uniquement que modifier une des tables NIS si un nouvel employé rejoint le département IT. Vous pourrez utiliser une approche similaire pour les serveurs moins importants en remplaçant l'ancienne ligne +::::::::: dans leur version locale de /etc/master.passwd avec quelque chose de semblable à ceci: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Les lignes correspondantes pour les stations de travail normales seraient: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin Tout était parfait jusqu'au changement de politique quelques semaines plus tard: le département IT commença à engager des internes. Les internes du département IT sont autorisés à utiliser les stations de travail normales et les serveurs les moins importants; les apprentis du département IT sont autorisés à ouvrir des sessions sur les serveurs principaux. Vous ajoutez alors un nouveau groupe réseau IT_INTERN, ajoutez les nouveaux internes IT à ce groupe réseau et commencez à modifier la configuration sur chaque machine... Comme disait l'ancien: “Erreurs dans la planification centralisée mènent à un désordre général”. La capacité de NIS à créer des groupes réseau à partir d'autres groupes réseau peut être utilisée pour éviter de telles situations. Une possibilité est la création de groupes réseau basés sur le rôle du groupe. Par exemple vous pourriez créer un groupe réseau appelé BIGSRV pour définir les restrictions d'ouverture de session pour les serveurs importants, un autre groupe réseau appelé SMALLSRV pour les serveurs moins importants et un troisième groupe réseau nommé USERBOX pour les stations de travail normales. Chacun de ces groupes réseau contient les groupes réseau autorisés à ouvrir des sessions sur ces machines. Les nouvelles entrées pour la table NIS de groupes réseau devrait ressembler à ceci: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS Cette méthode qui consiste à définir des restrictions d'ouverture de session fonctionne relativement bien si vous pouvez définir des groupes de machines avec des restrictions identiques. Malheureusement, ceci est une exception et pas une généralité. La plupart du temps, vous aurez besoin de définir des restrictions d'ouverture de session par machine. La définition de groupes réseau spécifiques aux machines est une autre possibilité pour traiter la modification de politique soulignée précédement. Dans ce scénario, le fichier /etc/master.passwd de chaque machine contient deux lignes débutant par “+”. La première ajoute un groupe réseau avec les comptes autorisés à ouvrir une session sur cette machine, la seconde ajoute tous les comptes avec l'interpréteur de commandes /sbin/nologin. C'est une bonne idée d'utiliser des majuscules pour le nom de la machine ainsi que celui du groupe réseau. Dans d'autres termes, les lignes en question devraient être semblables à: +@NOMMACHINE::::::::: +:::::::::/sbin/nologin Une fois cette tâche achevée pour toutes vos machines, vous n'aurez plus jamais à modifier les versions locales du fichier /etc/master.passwd. Tous les changements futurs peuvent être gérés en modifiant la table NIS. Voici un exemple d'une table de groupes réseau possible pour ce scénario avec quelques petits plus: # Définir tout d'abord les groupes d'utilisateurs IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Définir, maintenant, des groupes basés sur les rôles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # Et un groupe pour les tâches spéciales # Permettre à echo et golf d'accéder à notre machine anti-virus SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # les groupes réseau basés sur un ensemble de machines # Nos principaux serveurs WAR BIGSRV FAMINE BIGSRV # L'utilisateur india a besoin d'un accès à ce serveur POLLUTION BIGSRV (,india,test-domain) # # Celle-ci est très importante et nécessite plus de restrictions d'accès DEATH IT_EMP # # La machine anti-virus mentionnée précédemment ONE SECURITY # # Restreindre l'accès à une machine à un seul utilisateur TWO (,hotel,test-domain) # [...d'autres groupes suivent] Si vous utilisez une sorte de base de données pour gérer vos comptes utilisateur, vous devriez pouvoir créer la première partie de la table avec les outils de votre base de données. De cette façon, les nouveaux utilisateurs auront automatiquement accès aux machines. Dernier avertissement: il n'est pas toujours conseillé d'utiliser des groupes réseau basés sur les machines. Si vous déployez quelques douzaines ou même centaines de machines identiques pour des laboratoires pour étudiants, vous devriez utiliser des groupes basés sur les types d'utilisateurs plutôt que sur les machines pour conserver la taille de la table NIS dans des limites raisonables. Les choses importantes à ne pas oublier Il y a un certain nombre de choses que vous devrez effectuer différement maintenant que vous êtes dans un environnement NIS. A chaque fois que vous désirez ajouter un utilisateur au laboratoire, vous devez l'ajouter uniquement sur le serveur NIS et vous devez ne pas oublier de reconstruire les tables NIS. Si vous oubliez de le faire, le nouvel utilisateur ne pourra pas ouvrir de session en dehors du serveur maître NIS. Par exemple, si nous devons ajouter au laboratoire un nouvel utilisateur jsmith, nous ferions: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Vous pouvez lancer adduser jsmith à la place de pw useradd jsmith. Conservez les comptes d'administration en dehors des tables NIS. Vous ne voulez pas propager les comptes et mots de passe d'administration sur les machines qui auront des utilisateurs qui ne devraient pas avoir accès à ces comptes. Sécurisez les serveurs maître et esclave NIS, et réduisez leur temps d'arrêt. Si quelqu'un tente soit d'attaquer soit de simplement arrêter ces machines, de nombreuses personnes ne pourront plus ouvrir de session dans le laboratoire. C'est la principale faiblesse d'un système d'administration centralisée. Si vous ne protégez pas vos serveurs NIS, vous aurez à faire face à de nombreux utilisateurs mécontents! Compatibilité NIS version 1 ypserv sous &os; offre un support des clients NIS version 1. L'implémentation NIS de &os; utilise uniquement le protocole NIS version 2, cependant d'autres implémentations disposent du support pour le protocole version 1 pour des raisons de compatibilité avec d'anciens systèmes. Les “daemons” ypbind fournis avec ces systèmes tenteront de s'attacher à un serveur NIS version 1 même s'ils n'en ont pas besoin (et ils pourront continuer à diffuser des requêtes pour en trouver un même après avoir reçu une réponse d'un serveur NIS version 2). Notez que bien que les requêtes des clients normaux soient supportées, cette version d'ypserv ne supporte pas les requêtes de transfert de tables version 1; par conséquent il n'est pas possible de l'utiliser comme serveur maître ou esclave avec des serveurs NIS plus anciens qui ne supportent que la version 1 du protocole. Heureusement, il n'y a, aujourd'hui, presque plus de serveurs de ce type actifs. Serveurs NIS qui sont aussi des clients NIS Il faut faire attention quand on utilise ypserv dans un domaine avec plusieurs serveurs NIS qui sont également des clients NIS. Il est en général préférable de forcer les serveurs de se rattacher à eux-mêmes plutôt que de les laisser diffuser des requêtes de rattachement et éventuellement se rattacher réciproquement les uns aux autres. Il peut en résulter de curieux problèmes si l'un des serveurs tombe et que d'autres en dépendent. Tous les clients finiront par dépasser leur délai d'attente et se tenteront de se rattacher à d'autres serveurs, mais ce délai peut être considérable et le problème persistera puisque les serveurs peuvent à nouveau se rattacher les uns aux autres. Vous pouvez obliger une machine à se rattacher à un serveur particulier en exécutant ypbind avec l'option . Si vous ne désirez pas faire cela à la main à chaque fois que vous redémarrez votre serveur NIS, vous pouvez ajouter les lignes suivantes à votre fichier /etc/rc.conf: nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" Voir la page de manuel de &man.ypbind.8; pour plus d'informations. Formats des mots de passe NIS formats des mots de passe Un des problèmes les plus courants que l'on rencontre en mettant en oeuvre NIS est celui de la compatibilité des formats de mots de passe. Si votre serveur NIS utilise des mots de passe chiffrés avec l'algorithme DES, il ne supportera que les clients utilisant également DES. Par exemple, si vous avez des client NIS &solaris; sur votre réseau, alors vous aurez presque certainement besoin d'utiliser des mots de passe chiffrés avec le système DES. Pour déterminer quel format vos serveurs et clients utilisent, consultez le fichier /etc/login.conf. Si la machine est configurée pour utiliser des mots de passe chiffrés avec DES, alors la classe default contiendra une entrée comme celle-ci: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Entrées suivantes omises] D'autres valeurs possibles pour la capacité passwd_format sont blf et md5 (respectivement pour les chiffrages de mots de passe Blowfish et MD5). Si vous avez modifié le fichier /etc/login.conf, vous devrez également regénérer la base de données des capacités de classes de session, ce qui est accompli en exécutant la commande suivante en tant que root: &prompt.root; cap_mkdb /etc/login.conf Le format des mots de passe utilisés dans /etc/master.passwd ne sera pas mis à jour avant qu'un utilisateur ne change son mot de passe pour la première fois après la régénération de la base de données des capacités de classes de session. Ensuite, afin de s'assurer que les mots de passe sont chiffrés avec le format que vous avez choisi, vous devez vérifier que l'entrée crypt_default dans le fichier /etc/auth.conf donne la priorité au format de mots de passe choisi. Par exemple, quand les mots de passe DES sont utilisés, l'entrée serait: crypt_default = des blf md5 En suivant les points précédents sur chaque serveur et client NIS sous &os;, vous pouvez être sûr qu'ils seront tous d'accord sur le format de mot de passe utilisé dans le réseau. Si vous avez des problèmes d'authentification sur un client NIS, c'est probablement la première chose à vérifier. Rappelez-vous: si vous désirez mettre en place un serveur NIS pour un réseau hétérogène, vous devrez probablement utiliser DES sur tous les systèmes car c'est le standard le plus courant. Greg Sutter Ecrit par Configuration réseau automatique (DHCP) Qu'est-ce que DHCP? Dynamic Host Configuration Protocol DHCP Internet Software Consortium (ISC) DHCP, le protocole d'attribution dynamique des adresses (“Dynamic Host Configuration Protocol”), décrit les moyens par lesquels un système peut se connecter à un réseau et obtenir les informations nécessaires pour dialoguer sur ce réseau. Les versions de &os; antérieures à la version 6.0 utilisent l'implémentation du client DHCP (&man.dhclient.8;) de l'ISC (Internet Software Consortium). Les versions suivantes utilisent le programme dhclient d'OpenBSD issu d'OpenBSD 3.7. Toutes les informations données ici au sujet de dhclient sont valables aussi bien pour le client DHCP d'ISC que pour celui d'OpenBSD. Le serveur DHCP est celui distribué par le consortium ISC. Ce que traite cette section Cette section décrit les composants côté client des clients DHCP d'ISC et d' OpenBSD et côté serveur du système DHCP ISC. Le programme client, dhclient, est intégré à &os;, la partie serveur est disponible à partir du logiciel porté net/isc-dhcp3-server. Les pages de manuel &man.dhclient.8;, &man.dhcp-options.5;, et &man.dhclient.conf.5;, en plus des références données plus bas, sont des ressources utiles. Comment cela fonctionne-t-il? UDP Quand dhclient, le client DHCP, est exécuté sur la machine cliente, il commence à diffuser des requêtes de demandes d'information de configuration. Par défaut, ces requêtes sont effectuées sur le port UDP 68. Le serveur répond sur le port UDP 67, fournissant au client une adresse IP et d'autres informations réseau importantes comme le masque de sous-réseau, les routeurs, et les serveurs DNS. Toutes ces informations viennent sous la forme d'un “bail” DHCP qui est uniquement valide pendant un certain temps (configuré par l'administrateur du serveur DHCP). De cette façon, les adresses IP expirées pour les clients qui ne sont plus connectés peuvent être automatiquement récupérées. Les clients DHCP peuvent obtenir une grande quantité d'informations à partir du serveur. Une liste exhaustive est donnée dans la page de manuel &man.dhcp-options.5;. Intégration dans &os; Le client DHCP ISC ou OpenBSD (en fonction de la version de &os; que vous utilisez), dhclient, est complètement intégré à &os;. Le support du client DHCP est fourni avec l'installeur et le système de base, rendant évident le besoin d'une connaissance détaillée des configurations réseaux pour n'importe quel réseau utilisant un serveur DHCP. dhclient fait partie de toutes les versions de &os; depuis la version 3.2. sysinstall DHCP est supporté par sysinstall. Quand on configure une interface réseau sous sysinstall, la deuxième question posée est: “Voulez-vous tenter la configuration DHCP de l'interface?”. Répondre par l'affirmative à cette question lancera dhclient, et en cas de succès, complétera automatiquement les informations de configuration réseau. Vous devez faire deux choses pour que votre système utilise DHCP au démarrage: DHCP prérequis Assurez-vous que le périphérique bpf est compilé dans votre noyau. Pour cela, vous devez ajouter la ligne device bpf à votre fichier de configuration du noyau, et recompiler le noyau. Pour plus d'informations sur la compilation de noyaux, consultez le . Le périphérique bpf est déjà présent dans le noyau GENERIC qui est fourni avec &os;, vous ne devez donc pas créer de noyau spécifique pour faire fonctionner DHCP. Ceux qui sont particulièrement conscients de l'aspect sécurité devraient noter que bpf est également le périphérique qui permet le fonctionnement de “renifleurs” de paquets (de tels programmes doivent être lancés sous l'utilisateur root). bpf est nécessaire pour utiliser DHCP, mais si vous êtes très sensible à la sécurité, vous ne devriez probablement pas ajouter bpf à votre noyau parce que vous projetez d'utiliser DHCP dans le futur. Editez votre fichier /etc/rc.conf pour y ajouter ce qui suit: ifconfig_fxp0="DHCP" Assurez-vous de bien remplacer fxp0 par l'interface que vous voulez configurer de façon dynamique comme décrit dans la . Si vous utilisez un emplacement différent pour dhclient, ou si vous désirez passer des arguments supplémentaires à dhclient, ajoutez ce qui suit (en effectuant des modifications si nécessaire): dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP serveur Le serveur DHCP, dhcpd, fait partie du logiciel porté net/isc-dhcp3-server disponible dans le catalogue des logiciels portés. Ce logiciel porté contient le serveur DHCP ISC et sa documentation. Fichiers DHCP fichiers de configuration /etc/dhclient.conf dhclient nécessite un fichier de configuration, /etc/dhclient.conf. Généralement le fichier ne contient que des commentaires, les valeurs par défaut étant suffisantes. Ce fichier de configuration est décrit par la page de manuel &man.dhclient.conf.5;. /sbin/dhclient dhclient est lié statiquement et réside dans le répertoire /sbin. La page de manuel &man.dhclient.8; donne beaucoup plus d'informations au sujet de dhclient. /sbin/dhclient-script dhclient-script est la procédure de configuration du client DHCP spécifique à &os;. Elle est décrite dans la page de manuel &man.dhclient-script.8;, mais ne devrait pas demander de modification de la part de l'utilisateur pour fonctionner correctement. /var/db/dhclient.leases Le client DHCP conserve une base de données des baux valides, qui est écrite comme un fichier journal. La page de manuel &man.dhclient.leases.5; en donne une description légèrement plus longue. Lecture supplémentaire Le protocole DHCP est intégralement décrit dans la RFC 2131. Des informations sont également disponibles à l'adresse . Installer et configurer un serveur DHCP Ce que traite cette section Cette section fournit les informations nécessaires à la configuration d'un système &os; comme serveur DHCP en utilisant l'implémentation ISC (Internet Software Consortium) du serveur DHCP. Le serveur n'est pas fourni dans le système de base de &os;, et vous devrez installer le logiciel porté net/isc-dhcp3-server pour bénéficier de ce service. Lisez le pour plus d'information sur l'utilisation du catalogue des logiciels portés. Installation d'un serveur DHCP DHCP installation Afin de configurer votre système &os; en serveur DHCP, vous devrez vous assurer que le support du périphérique &man.bpf.4; est compilé dans votre noyau. Pour cela ajouter la ligne device bpf dans votre fichier de configuration du noyau. Pour plus d'information sur la compilation de noyaux, consultez le . Le périphérique bpf est déjà présent dans le noyau GENERIC qui est fourni avec &os;, vous ne devez donc pas créer de noyau spécifique pour faire fonctionner DHCP. Ceux qui sont particulièrement conscients de l'aspect sécurité devraient noter que bpf est également le périphérique qui permet le fonctionnement de “renifleurs” de paquets (de tels programmes nécessitent également un accès avec privilèges). bpf est nécessaire pour utiliser DHCP, mais si vous êtes très sensible à la sécurité, vous ne devriez probablement pas ajouter bpf à votre noyau parce que vous projetez d'utiliser DHCP dans le futur. Il vous reste ensuite à éditer le fichier dhcpd.conf d'exemple qui a été installé par le logiciel porté net/isc-dhcp3-server. Par défaut, cela sera /usr/local/etc/dhcpd.conf.sample, et vous devriez le copier vers /usr/local/etc/dhcpd.conf avant de commencer vos modifications. Configuration du serveur DHCP DHCP dhcpd.conf dhcpd.conf est composé de déclarations concernant les masques de sous-réseaux et les machines, il est peut-être plus facile à expliquer à l'aide d'un exemple: option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } Cette option spécifie le domaine qui sera donné aux clients comme domaine par défaut. Consultez la page de manuel de &man.resolv.conf.5; pour plus d'information sur sa signification. Cette option donne une liste, séparée par des virgules, de serveurs DNS que le client devrait utiliser. Le masque de sous-réseau qui sera fourni aux clients. Un client peut demander un bail d'une durée bien précise. Sinon par défaut le serveur alloue un bail avec cette durée avant expiration (en secondes). C'est la durée maximale d'allocation autorisée par le serveur. Si un client demande un bail plus long, le bail sera accordé mais il ne sera valide que durant max-lease-time secondes. Cette option indique si le serveur DHCP doit tenter de mettre à jour le DNS quand un bail est accepté ou révoqué. Dans l'implémentation ISC, cette option est obligatoire. Ceci indique quelles adresses IP devraient être utilisées dans l'ensemble des adresses réservées aux clients. Les adresses comprises dans l'intervalle spécifiée sont allouées aux clients. Définit la passerelle par défaut fournie aux clients. L'adresse matérielle MAC d'une machine (de manière à ce que le serveur DHCP puisse reconnaître une machine quand elle envoie une requête). Indique que la machine devrait se voir attribuer toujours la même adresse IP. Notez que l'utilisation d'un nom de machine ici est correct, puisque le serveur DHCP effectuera une résolution de nom sur le nom de la machine avant de renvoyer l'information sur le bail. Une fois l'écriture de votre fichier dhcpd.conf terminée, vous devez activer le serveur DHCP dans le fichier /etc/rc.conf, en ajoutant: dhcpd_enable="YES" dhcpd_ifaces="dc0" Remplacez le nom de l'interface dc0 avec celui de l'interface (ou des interfaces, séparées par un espace) sur laquelle votre serveur DHCP attendra les requêtes des clients DHCP. Ensuite, vous pouvez lancer le serveur en tapant la commande suivante: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start Si vous devez, dans le futur, effectuer des changements dans la configuration de votre serveur, il est important de savoir que l'envoi d'un signal SIGHUP à dhcpd ne provoque pas le rechargement de la configuration, contrairement à la plupart des “daemons”. Vous devrez envoyer un signal SIGTERM pour arrêter le processus, puis le relancer en utilisant la commande ci-dessus. Fichiers DHCP fichier de configuration /usr/local/sbin/dhcpd dhcpd est lié statiquement et réside dans le répertoire /usr/local/sbin. La page de manuel &man.dhcpd.8; installée avec le logiciel porté donne beaucoup plus d'informations au sujet de dhcpd. /usr/local/etc/dhcpd.conf dhcpd nécessite un fichier de configuration, /usr/local/etc/dhcpd.conf avant de pouvoir commencer à offrir ses services aux client. Ce fichier doit contenir toutes les informations à fournir aux clients qui seront traités, en plus des informations concernant le fonctionnement du serveur. Ce fichier de configuration est décrit par la page de manuel &man.dhcpd.conf.5; installée par le logiciel porté. /var/db/dhcpd.leases Le serveur DHCP conserve une base de données des baux qu'il a délivré, qui est écrite comme un fichier journal. La page de manuel &man.dhcpd.leases.5; installée par le logiciel porté en donne une description légèrement plus longue. /usr/local/sbin/dhcrelay dhcrelay est utilisé dans les environnements avancés où un serveur DHCP fait suivre la requête d'un client vers un autre serveur DHCP sur un réseau séparé. Si vous avez besoin de cette fonctionnalité, installez alors le logiciel porté net/isc-dhcp3-server. La page de manuel &man.dhcrelay.8; fournie avec le logiciel porté contient plus de détails. Chern Lee Contribution de Tom Rhodes Daniel Gerzo Serveurs de noms (<acronym>DNS</acronym>) Généralités BIND &os; utilise, par défaut, BIND (Berkeley Internet Name Domain), qui est l'implémentation la plus courante du protocole DNS. Le DNS est le protocole qui effectue la correspondance entre noms et adresses IP, et inversement. Par exemple une requête pour www.FreeBSD.org aura pour réponse l'adresse IP du serveur Web du projet &os;, et une requête pour ftp.FreeBSD.org renverra l'adresse IP de la machine FTP correspondante. De même, l'opposé est possible. Une requête pour une adresse IP retourne son nom de machine. Il n'est pas nécessaire de faire tourner un serveur DNS pour effectuer des requêtes DNS sur un système. &os; est actuellement fourni par défaut avec le serveur DNS BIND9. Notre installation est dotée de fonctionnalités étendues au niveau de la sécurité, d'une nouvelle organisation du système de fichiers et d'une configuration en environnement &man.chroot.8; automatisée. DNS Le DNS est coordonné sur l'Internet à travers un système complexe de serveurs de noms racines faisant autorité, de domaines de premier niveau (Top Level Domain, TLD), et d'autres serveurs de noms de plus petites tailles qui hébergent, directement ou font office de “cache”, l'information pour des domaines individuels. Actuellement, BIND est maintenu par l'Internet Software Consortium . Terminologie Pour comprendre ce document, certains termes relatifs au DNS doivent être maîtrisés. résolveur DNS inverse zone racine Terme Definition “Forward“ DNS Correspondance noms de machine vers adresses IP. Origine Fait référence au domaine couvert par un fichier de zone particulier. named, BIND, serveur de noms Noms courants pour le serveur de noms BIND de &os; Resolveur Un processus système par l'intermédiaire duquel une machine contacte un serveur de noms pour obtenir des informations sur une zone. DNS inverse C'est l'inverse du DNS “classique” (“Forward“ DNS). C'est la correspondance adresses IP vers noms de machine. Zone racine Début de la hiérarchie de la zone Internet. Toutes les zones sont rattachées à la zone racine, de la même manière qu'un système de fichier est rattaché au répertoire racine. Zone Un domaine individuel, un sous-domaine, ou une partie des noms administrés par un même serveur faisant autorité. zones exemples Exemples de zones: . est la zone racine org. est un domaine de premier niveau (TLD) sous la zone racine example.org. est une zone sous le TLD org. 1.168.192.in-addr.arpa est une zone faisant référence à toutes les adresses IP qui appartiennent l'espace d'adresse 192.168.1.*. Comme on peut le remarquer, la partie la plus significative d'un nom de machine est à sa gauche. Par exemple, example.org. est plus spécifique que org., comme org. est à son tour plus spécifique que la zone racine. La constitution de chaque partie d'un nom de machine est proche de celle d'un système de fichiers: le répertoire /dev se trouve sous la racine, et ainsi de suite. Les raisons de faire tourner un serveur de noms Les serveurs de noms se présentent généralement sous deux formes: un serveur de noms faisant autorité, et un serveur de noms cache. Un serveur de noms faisant autorité est nécessaire quand: on désire fournir des informations DNS au reste du monde, être le serveur faisant autorité lors des réponses aux requêtes. un domaine, comme par exemple example.org, est enregistré et des adresses IP doivent être assignées à des noms de machine appartenant à ce domaine. un bloc d'adresses IP nécessite des entrées DNS inverses (IP vers nom de machine). un second serveur de noms ou de secours, appelé esclave, qui répondra aux requêtes. Un serveur de noms cache est nécessaire quand: un serveur de noms local peut faire office de cache et répondre plus rapidement que l'interrogation d'un serveur de noms extérieur. Quand on émet des requêtes pour www.FreeBSD.org, le résolveur interroge généralement le serveur de noms du fournisseur d'accès, et récupère la réponse. Avec un serveur DNS cache local, la requête doit être effectuée qu'une seule fois vers le monde extérieur par le serveur DNS cache. Chaque interrogation suivante n'aura pas à être transmise en dehors du réseau local, puisque l'information est désormais disponible localement dans le cache. Comment cela fonctionne-t-il? Sous &os; le “daemon” BIND est appelé named pour des raisons évidentes. Fichier Description &man.named.8; le “daemon” BIND &man.rndc.8; le programme de contrôle du serveur de noms /etc/namedb répertoire où se trouvent les informations sur les zones de BIND /etc/namedb/named.conf le fichier de configuration du “daemon” En fonction de la manière dont est configurée sur le serveur une zone donnée, les fichiers relatifs à cette zone pourront être trouvés dans les sous-répertoires master, slave, ou dynamic du répertoire /etc/namedb. Ces fichiers contiennent les informations DNS qui seront données par le serveur de noms en réponse aux requêtes. Lancer BIND BIND lancement Puisque BIND est installé par défaut, sa configuration est relativement simple. La configuration par défaut de named est un serveur de noms résolveur basique, tournant dans un environnement &man.chroot.8;. Pour lancer le serveur avec cette configuration, utilisez la commande suivante: &prompt.root; /etc/rc.d/named forcestart Pour s'assurer que le “daemon” named est lancé à chaque démarrage, ajoutez la ligne suivante dans /etc/rc.conf: named_enable="YES" Il existe, bien évidemment, de nombreuses options de configuration pour /etc/namedb/named.conf qui dépassent le cadre de ce document. Si vous êtes intéressé par les options de démarrage de named sous &os;, jetez un oeil aux paramètres named_* dans /etc/defaults/rc.conf et consultez la page de manuel &man.rc.conf.5;. La section constitue également une bonne lecture. Fichiers de configuration BIND fichiers de configuration Les fichiers de configuration pour named se trouvent dans le répertoire /etc/namedb et devront être adaptés avant toute utilisation, à moins que l'on ait besoin que d'un simple résolveur. C'est dans ce répertoire où la majeure partie de la configuration se fera. Utilisation de <command>make-localhost</command> Pour configurer une zone maître, il faut se rendre dans le répertoire /etc/namedb/ et exécuter la commande suivante: &prompt.root; sh make-localhost Si tout s'est bien passé, un nouveau fichier devrait apparaître dans le sous-répertoire master. Les noms de fichiers devraient être localhost.rev pour le nom de domaine local et localhost-v6.rev pour les configurations IPv6. Tout comme le fichier de configuration par défaut, les informations nécessaires seront présentes dans le fichier named.conf. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Reportez-vous aux pages de manuel named.conf(5) et named(8), et à // la documentation se trouvant dans /usr/share/doc/bind9 pour plus de // détails. // // Si vous devez configurer un serveur primaire, assurez-vous d'avoir // compris les détails épineux du fonctionnement du DNS. Même avec de // simples erreurs, vous pouvez rompre la connexion entre les parties // affectées, ou causer un important et inutile trafic Internet. options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // Si named est utilisé uniquement en tant que résolveur local, ceci // est un bon réglage par défaut. Pour un named qui doit être // accessible à l'ensemble du réseau, commentez cette option, précisez // l'adresse IP correcte, ou supprimez cette option. listen-on { 127.0.0.1; }; // Si l'IPv6 est activé sur le système, décommentez cette option pour // une utilisation en résolveur local. Pour donner l'accès au réseau, // précisez une adresse IPv6, ou le mot-clé "any". // listen-on-v6 { ::1; }; // En plus de la clause "forwarders", vous pouvez forcer votre serveur // de noms à ne jamais être à l'origine de // requêtes, mais plutôt faire suivre les demandes en // activant la ligne suivante: // // forward only; // Si vous avez accès à un serveur de noms au niveau de // votre fournisseur d'accès, ajoutez ici son adresse IP, et // activez la ligne ci-dessous. Cela vous permettra de // bénéficier de son cache, réduisant ainsi le // trafic Internet. /* forwarders { 127.0.0.1; }; */ Comme les commentaires le précisent, pour bénéficier d'un cache en amont de votre connexion, le paramètre forwarders peut être activé. Dans des circonstances normales, un serveur de noms interrogera de façon récursive certains serveurs de noms jusqu'à obtenir la réponse à sa requête. Avec ce paramètre activé, votre serveur interrogera le serveur de noms en amont (ou le serveur de noms fourni) en premier, en bénéficiant alors de son cache. Si le serveur en question gère beaucoup de trafic, et est un serveur rapide, activer cette option peut en valoir la peine. 127.0.0.1 ne fonctionnera pas ici. Remplacez cette adresse IP par un serveur de noms en amont de votre connexion. /* * S'il y a un coupe-feu entre vous et les serveurs de noms * avec lesquels vous voulez communiquer, vous aurez * peut-être besoin de décommenter la directive * query-source ci-dessous. Les versions * précédentes de BIND lançaient des * requêtes à partir du port 53, mais depuis la * version 8, BIND utilise * par défaut un port pseudo-aléatoire quelconque non * réservé. */ // query-source address * port 53; }; // Si vous activez un serveur de noms local, n'oubliez pas d'entrer // 127.0.0.1 dans votre fichier /etc/resolv.conf de sorte que ce // serveur soit interrogé le premier. Assurez-vous // également de l'activer dans /etc/rc.conf. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "master/localhost.rev"; }; // RFC 3152 zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" { type master; file "master/localhost-v6.rev"; }; // NB: N'utilisez pas les adresses IP ci-dessous, elles sont factices, // et ne servent que pour des besoins de // démonstration/documentation! // // Exemple d'entrées de configuration de zone esclave. // Il peut être pratique de devenir serveur esclave pour la // zone à laquelle appartient votre domaine. Demandez à // votre administrateur réseau l'adresse IP du serveur primaire // responsable de la zone. // // N'oubliez jamais d'inclure la résolution de la zone inverse // (IN-ADDR.ARPA)! // (Ce sont les premiers octets de l'adresse IP, en ordre inverse, // auxquels ont a ajouté ".IN-ADDR.ARPA".) // // Avant de commencer à configurer une zone primaire, il faut // être sûr que vous avez parfaitement compris comment le // DNS et BIND fonctionnent. Il apparaît parfois des pièges // peu évidents à saisir. En comparaison, configurer une // zone esclave est plus simple. // // NB: N'activez pas aveuglément les exemples ci-dessous. :-) // Utilisez des noms et des adresses réelles. /* Un exemple de zone maître zone "example.net" { type master; file "master/example.net"; }; */ /* Un exemple de zone dynamique key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "dynamic/example.org"; }; */ /* Exemple de zones esclaves directes et inverses zone "example.com" { type slave; file "slave/example.com"; masters { 192.168.1.1; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ Dans named.conf, ce sont des exemples d'entrées d'un serveur esclave. Pour chaque nouvelle zone gérée, une nouvelle entrée de zone doit être ajoutée au fichier named.conf. Par exemple, l'entrée de zone la plus simple possible pour example.org serait: zone "example.org" { type master; file "master/example.org"; }; Ce sera un serveur maître pour la zone, comme indiqué par l'option , concervant ses informations de zone dans le fichier /etc/namedb/master/example.org comme précisé par l'option . zone "example.org" { type slave; file "slave/example.org"; }; Dans le cas d'un esclave, les informations concernant la zone seront transférées à partir du serveur maître pour la zone en question, et sauvegardées dans le fichier indiqué. Si ou lorsque le serveur maître tombe ou est inaccessible, le serveur esclave disposera des informations de la zone transférée et sera capable de les diffuser. Fichiers de zone BIND fichiers de zone Un exemple de fichier de zone maître pour example.org (défini dans /etc/namedb/master/example.org) suit: $TTL 3600 ; 1 hour example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ; Minimum TTL ) ; Serveurs DNS IN NS ns1.example.org. IN NS ns2.example.org. ; Enregistrements MX IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Noms de machine localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 ; Alias www IN CNAME @ Notez que chaque nom de machine se terminant par un “.” est un nom de machine complet, alors que tout ce qui se termine pas par un “.” est référencé par rapport à une origine. Par exemple, www sera traduit en www.origine. Dans notre fichier de zone fictif, notre origine est example.org., donc www sera traduit en www.example.org. Le format d'un fichier de zone est le suivant: nom-enregistrement IN type-enregistrement valeur DNS enregistrements Les enregistrements DNS les plus couramment utilisés: SOA début des données de zone NS serveur de noms faisant autorité A adresse d'une machine CNAME alias d'un nom de machine MX serveur de messagerie recevant le courrier pour le domaine PTR un pointeur sur un nom de domaine (utilisé dans le DNS inverse) example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day example.org. le nom de domaine, également l'origine pour ce fichier de zone. ns1.example.org. le serveur de noms primaire/faisant autorité pour cette zone. admin.example.org. la personne responsable pour cette zone avec le caractère “@” remplacé. (admin@example.org devient admin.example.org) 2006051501 le numéro de série de ce fichier. Celui-ci doit être incrémenté à chaque modification du fichier de zone. De nos jours, de nombreux administrateurs préfèrent un format du type aaaammjjrr pour le numéro de série. 2006051501 signifierait dernière modification le 15/05/2006, le 01 indiquant que c'est la seconde fois que ce fichier a été révisé ce jour. Le numéro de série est important puisqu'il indique aux serveurs de noms esclaves pour la zone une modification de celle-ci. IN NS ns1.example.org. C'est une entrée de type NS. Tous les serveurs de noms qui doivent faire autorité pour la zone devront inclure une de ces entrées. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 Un enregistrement de type A indique des noms de machine. Comme présenté ci-dessus ns1.example.org sera résolu en 192.168.1.2. IN A 192.168.1.1 Cette ligne assigne l'adresse IP 192.168.1.1 à l'origine, dans cet exemple example.org. www IN CNAME @ L'enregistrement de type CNAME est généralement utilisé pour créer des alias à une machine. Dans l'exemple, www est un alias de la machine connue sous le nom localhost.example.org (127.0.0.1). Les enregistrements CNAME peuvent être utilisés pour fournir des alias à des noms de machines, ou permettre la rotation (“round robin”) d'un nom de machine entre plusieurs machines. MX record IN MX 10 mail.example.org. L'enregistrement MX indique quels serveurs de messagerie sont responsables de la gestion du courrier entrant pour la zone. mail.example.org est le nom de machine du serveur de messagerie, et 10 étant la priorité du serveur de messagerie. On peut avoir plusieurs serveurs de messagerie, avec des priorités de 10, 20, etc. Un serveur de messagerie tentant de transmettre du courrier au domaine example.org essaiera en premier le MX avec la plus haute priorité (l'enregistrement avec le numéro de priorité le plus bas), puis celui venant en second, etc, jusqu'à ce que le courrier puisse être correctement délivré. Pour les fichiers de zone in-addr.arpa (DNS inverse), le même format est utilisé, à l'exception du fait que des entrées PTR seront utilisées en place de A ou CNAME. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org. Ce fichier donne la correspondance entre adresses IP et noms de machines de notre domaine fictif. Serveur de noms cache BIND serveur de noms cache Un serveur de noms cache est un serveur de noms qui ne fait autorité pour aucune zone. Il émet simplement des requêtes, et se souvient du résultat pour une utilisation ultérieure. Pour mettre en place un tel serveur, configurez le serveur de noms comme à l'accoutumé, en prenant bien soin de n'inclure aucune zone. Sécurité Bien que BIND soit l'implémentation la plus courante du DNS, le problème de la sécurité subsiste toujours. De possibles problèmes de sécurité exploitables sont parfois découvert. Bien que &os; enferme automatiquement named dans un environnement &man.chroot.8;, il existe plusieurs autres mécanismes de sécurité qui pourraient aider à se prémunir contre de possibles attaques DNS. C'est une bonne idée de lire les avis de sécurité du CERT et de s'inscrire à la &a.security-notifications; pour se maintenir au courant des problèmes de sécurité actuels de l'Internet et de &os;. Si un problème surgit, conserver les sources à jour et disposer d'une version compilée de named récente ne seront pas de trop. Lectures supplémentaires Les pages de manuel de BIND/named: &man.rndc.8; &man.named.8; &man.named.conf.5;. Page officielle ISC concernant BIND Forum officiel ISC concernant BIND FAQ BIND DNS et BIND 5ème Edition de chez O'Reilly RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification Murray Stokely Contribution de Serveur HTTP Apache serveurs web configuration Apache Généralités &os; est utilisé pour faire tourner certains des sites les plus chargés au monde. La majorité des serveurs web sur l'Internet utilisent le serveur HTTP Apache. Les versions pré-compilées d'Apache devraient se trouver sur le support d'installation de &os; que vous avez utilisé. Si vous n'avez pas installé Apache à l'installation de &os;, alors vous pouvez installer le serveur à partir du logiciel porté www/apache13 ou www/apache20. Une fois qu'Apache a été installé avec succès, il doit être configuré. Cette section traite de la version 1.3.X du serveur HTTP Apache étant donné que c'est la version la plus largement utilisée sous &os;. Apache 2.X introduit de nombreuses nouvelles technologies mais elles ne sont pas abordées ici. Pour plus d'informations concernant Apache 2.X veuillez consulter . Configuration Apache fichier de configuration Le fichier principal de configuration du serveur HTTP Apache est, sous &os;, le fichier /usr/local/etc/apache/httpd.conf. Ce fichier est un fichier texte de configuration &unix; typique avec des lignes de commentaires débutant par un caractère #. Une description complète de toutes les options de configuration possibles dépasse le cadre de cet ouvrage, aussi seules les directives les plus fréquemment modifiées seront décrites ici. ServerRoot "/usr/local" Indique le répertoire d'installation par défaut pour l'arborescence Apache. Les binaires sont stockés dans les sous-répertoires bin et sbin de la racine du serveur, et les fichiers de configuration dans etc/apache. ServerAdmin you@your.address L'adresse électronique à laquelle tous les problèmes concernant le serveur doivent être rapportés. Cette adresse apparaît sur certaines pages générées par le serveur, comme des pages d'erreur. ServerName www.example.com La directive ServerName vous permet de fixer un nom de machine qui est renvoyé aux clients de votre serveur si le nom est différent de celui de la machine (i.e, utilisez www à la place du véritable nom de la machine). DocumentRoot "/usr/local/www/data" DocumentRoot est le répertoire où se trouvent les documents que votre serveur diffusera. Par défaut, toutes les requêtes sont prises en compte par rapport à ce répertoire, mais des liens symboliques et des alias peuvent être utilisés pour pointer vers d'autres emplacements. C'est toujours une bonne idée de faire des copies de sauvegarde de votre fichier de configuration d'Apache avant de faire des modifications. Une fois que vous êtes satisfait avec votre configuration, vous êtes prêt à lancer Apache. Exécuter <application>Apache</application> Apache démarrage ou arrêt Apache n'est pas lancé à partir du “super-serveur” inetd comme pour beaucoup d'autres serveurs réseau. Il est configuré pour tourner de façon autonome pour de meilleures performances à la réception des requêtes HTTP des navigateurs web. Une procédure est fournie pour rendre le démarrage, l'arrêt, et le redémarrage du serveur aussi simple que possible. Pour démarrer Apache pour la première fois, exécutez: &prompt.root; /usr/local/sbin/apachectl start Vous pouvez arrêter le serveur à tout moment en tapant: &prompt.root; /usr/local/sbin/apachectl stop Après avoir effectué des modifications dans le fichier de configuration, vous devez redémarrer le serveur: &prompt.root; /usr/local/sbin/apachectl restart Pour redémarrer Apache sans faire échouer les connexions en cours, exécutez: &prompt.root; /usr/local/sbin/apachectl graceful Des informations supplémentaires sont disponibles dans la page de manuel d'&man.apachectl.8;. Pour lancer Apache au démarrage du système, ajoutez la ligne suivante au fichier /etc/rc.conf: apache_enable="YES" Si vous désirez passer des options en ligne de commande supplémentaires au programme httpd d'Apache lancé au démarrage du système, vous pouvez les spécifier à l'aide d'une ligne dans rc.conf: apache_flags="" Maintenant que le serveur web tourne, vous pouvez voir votre site web en pointant votre navigateur sur http://localhost/. La page web affichée par défaut est /usr/local/www/data/index.html. Serveurs virtuels Apache supporte deux types différents de serveurs virtuels. Le premier type est celui des serveurs virtuels basés sur les noms. Ce type de serveurs virtuels utilise les entêtes HTTP/1.1 pour déterminer le nom de la machine. Cela autorise le partage de la même adresse IP entre plusieurs domaines différents. Pour configurer Apache à l'utilisation de serveurs virtuels basés sur les noms, ajoutez une entrée comme la suivante à votre fichier httpd.conf: NameVirtualHost * Si votre serveur web est appelé www.domain.tld et que vous voulez mettre en place un domain virtuel pour www.someotherdomain.tld alors vous ajouterez les entrées suivantes au fichier httpd.conf: <VirtualHost *> ServerName www.domain.tld DocumentRoot /www/domain.tld </VirtualHost> <VirtualHost *> ServerName www.someotherdomain.tld DocumentRoot /www/someotherdomain.tld </VirtualHost> Remplacez les addresses avec celles que vous désirez utiliser et le chemin d'accès des documents avec celui que vous utilisez. Pour plus d'informations sur la mise en place de serveurs virtuels, veuillez consulter la documentation officielle d'Apache à l'adresse . Modules Apache Apache modules Il existe de nombreux modules Apache disponibles en vue d'ajouter des fonctionnalités au serveur de base. Le catalogue des logiciels portés offre une méthode simple d'installation d'Apache avec certains des modules les plus populaires. mod_ssl serveurs web sécurisé SSL chiffrement Le module mod_ssl utilise la bibliothèque OpenSSL pour offrir un chiffrement solide à l'aide des protocoles “Secure Sockets Layer” (SSL v2/v3) et “Transport Layer Security”. Ce module fourni tout ce qui est nécessaire à la demande de certificats signés auprès d'une autorité de certification connue de façon à pouvoir faire tourner un serveur web sécurisé sous &os;. Si vous n'avez pas déjà installé Apache, alors une version d'Apache 1.3.X comprenant mod_ssl peut être installée à l'aide du logiciel porté www/apache13-modssl. Le support SSL est également disponible pour Apache 2.X avec le logiciel porté www/apache20, où il est activé par défaut. Sites Web dynamiques avec Perl & PHP Ces dernières années, de plus en plus d'entreprises se sont tournées vers l'Internet pour augmenter leurs revenus et renforcer leur exposition. Cela a eu pour conséquence d'accroître le besoin de contenus Web interactifs. Quand certaines entreprises, comme µsoft;, ont introduit dans leurs produits propriétaires des solutions à ces besoins, la communauté des logiciels libres a également répondu à l'appel. Deux options pour obtenir du contenu Web dynamique sont mod_perl et mod_php. mod_perl mod_perl Perl Le projet d'intégration Apache/Perl réuni la puissance du langage de programmation Perl et le serveur HTTP Apache. Avec le module mod_perl il est alors possible d'écrire des modules Apache entièrement en Perl. De plus, la présence d'un interpréteur intégré au serveur évite la surcharge due au lancement d'un interpréteur externe et le délai pénalisant du démarrage de Perl. Le module mod_perl est peut être obtenu de diverses manières. Pour l'utilisation du module mod_perl souvenez-vous que mod_perl 1.0 ne fonctionne qu'avec Apache 1.3 et mod_perl 2.0 ne fonctionne qu'avec Apache 2. Le module mod_perl 1.0 est disponible sous www/mod_perl et une version compilée en statique sous www/apache13-modperl. Le module mod_perl 2.0 est disponible sous www/mod_perl2. Tom Rhodes Ecrit par mod_php mod_php PHP PHP, aussi connu sous le nom de PHP: Hypertext Preprocessor est un langage de script tout particulièrement adapté au développement Web. Pouvant être intégré à du HTML, sa syntaxe est dérivée du C, &java;, et du Perl avec pour objectif de permettre aux développeurs Web d'écrire rapidement des pages Web au contenu généré dynamiquement. Pour ajouter le support de PHP5 au serveur Web Apache, commencez par installer le logiciel porté lang/php5. Si c'est la première installation du logiciel lang/php5, les OPTIONS disponibles seront affichées automatiquement. Si aucun menu n'est affiché, parce que le logiciel porté lang/php5 a été installé par le passé, il est toujours possible de forcer l'affichage du menu des options de compilation en utilisant la commande: &prompt.root; make config dans le répertoire du logiciel porté. Dans le menu des options de compilation, sélectionnez l'option APACHE pour compiler mod_php5 sous forme de module chargeable pour le serveur Web Apache. De nombreux sites utilisent toujours PHP4 pour diverses raisons (des problèmes de compatibilité ou des applications Web déjà déployées). Si mod_php4 est requis à la place de mod_php5, utilisez alors le logiciel porté lang/php4. Le logiciel porté lang/php4 supporte plusieurs des options de configuration et de compilation du logiciel porté lang/php5. Cela installera et configurera les modules requis au support des applications dynamiques PHP. Assurez-vous que les sections suivantes ont été ajoutées au fichier /usr/local/etc/apache/httpd.conf: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Ensuite, un simple appel à la commande apachectl pour un redémarrage élégant est requis pour charger le module PHP: &prompt.root; apachectl graceful Lors des futures mises à jour de PHP, la commande make config ne sera pas nécessaire; les OPTIONS précédemment sélectionnées sont automatiquement sauvegardées par le système des logiciels portés de &os;. Le support de PHP sous &os; est extrêmement modulaire ce qui donne lieu à une installation de base limitée. Il est très simple d'ajouter une fonctionnalité en utilisant le logiciel porté lang/php5-extensions. Ce logiciel porté fournit un menu pour l'installation des extensions PHP. Alternativement, il est possible d'installer les extensions individuellement en utilisant les logiciels portés correspondants. Par exemple, pour ajouter à PHP5 le support pour le serveur de bases de données MySQL, installez simplement le logiciel porté databases/php5-mysql. Après l'installation d'une extension, le serveur Apache doit être redémarré pour prendre en compte les changements de configuration: &prompt.root; apachectl graceful Murray Stokely Contribution de Protocole de transfert de fichiers (FTP) serveurs FTP Généralités Le protocol de transfert de fichiers (FTP) offre aux utilisateurs une méthode simple pour transférer des fichiers vers ou à partir d'un serveur FTP. &os; comprend un serveur FTP, ftpd, dans le système de base. Cela rend la configuration et l'administration d'un serveur FTP sous &os; très simple. Configuration L'étape de configuration la plus important est de décider quels comptes seront autorisés à accéder au serveur FTP. Un système &os; classique possède de nombreux comptes système utilisés par divers “daemon”s, mais les utilisateurs inconnus ne devraient pas être autorisés à ouvrir de session sous ces comptes. Le fichier /etc/ftpusers est une liste d'utilisateurs interdits d'accès au serveur FTP. Par défaut, il inclut les comptes systèmes précédemment mentionnés, mais il est possible d'ajouter des utilisateurs précis qui ne devraient pas avoir accès au serveur FTP. Vous pouvez vouloir restreindre l'accès à certains utilisateurs sans leur refuser complètement l'utilisation du serveur FTP. Cela peut être réalisé à l'aide du fichier /etc/ftpchroot. Ce fichier liste les utilisateurs et les groupes sujet à des restrcitions d'accès FTP. La page de manuel &man.ftpchroot.5; fournit tous les détails, cela ne sera donc pas décrit ici. FTP anonyme Si vous désirez activer l'accès FTP anonyme sur votre serveur, vous devez alors créer un utilisateur appelé ftp sur votre serveur &os;. Les utilisateurs seront donc en mesure d'ouvrir une session FTP sur votre serveur sous le nom d'utilisateur ftp ou anonymous et sans aucun mot de passe (par convention l'adresse électronique de l'utilisateur devrait être utilisée comme mot de passe). Le serveur FTP appellera &man.chroot.2; quand un utilisateur anonyme ouvrira une session, pour restreindre l'accès juste au répertoire personnel de l'utilisateur ftp. Il existe deux fichiers texte qui spécifient les messages de bienvenue à afficher aux clients FTP. Le contenu du fichier /etc/ftpwelcome sera affiché aux utilisateurs avant qu'ils atteignent l'invite de session. Après une ouverture de session, le contenu du fichier /etc/ftpmotd sera affiché. Notez que le chemin d'accès à ce fichier est relatif à l'environnement de la session, aussi le fichier ~ftp/etc/ftpmotd sera affiché aux utilisateurs anonymes. Une fois que le serveur FTP a été configuré correctement, il doit être activé dans le fichier /etc/inetd.conf. Ici il faut juste retirer le symbole de commentaire “#” en face de la ligne ftpd: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Comme expliqué dans la , la configuration d'inetd doit être rechargée après que le fichier de configuration ait été modifié. Vous pouvez maintenant ouvrir une session FTP sur votre serveur en tapant: &prompt.user; ftp localhost Maintenance syslog fichiers journaux FTP Le “daemon” ftpd utilise &man.syslog.3; pour l'enregistement des messages. Par défaut, le “daemon” de gestion des journaux du système enverra les messages relatifs au FTP dans le fichier /var/log/xferlog. L'emplacement des journaux FTP peut être modifié en changeant la ligne suivante dans le fichier /etc/syslog.conf: ftp.info /var/log/xferlog FTP anonyme Soyez conscient des éventuels problèmes impliqués par l'utilisation d'un serveur FTP acceptant les connexions anonymes. Vous devriez, tout particulièrement, penser à deux fois avant d'autoriser les utilisateurs anonyme à déposer des fichiers sur le serveur. Votre site FTP pourrait devenir un forum d'échange de logiciels commerciaux sans les licences ou pire. Si vous devez autoriser le dépôt de fichiers de façon anonyme sur le serveur FTP, alors vous devriez fixer les permissions sur ces fichiers de telle sorte qu'ils ne puissent être lus par d'autres utilisateurs anonymes avant qu'ils n'aient pu être contrôlés. Murray Stokely Contribution de Serveur de fichiers et d'impression pour clients µsoft.windows; (Samba) serveur Samba Microsoft Windows serveur de fichiers clients Windows serveur d'impression clients Windows Généralités Samba est un logiciel libre très populaire qui offre des services de partage de fichiers et d'imprimantes pour les clients µsoft.windows;. De tels clients peuvent se connecter et utiliser l'espace de fichiers d'une machine &os; comme si c'était un disque local, ou utiliser des imprimantes &os; comme si elles étaient des imprimantes locales. Samba devrait se trouver sur votre support d'installation. Si vous n'avez pas installé Samba à l'installation de &os;, vous pouvez alors l'installer à partir de la version pré-compilée ou portée net/samba3. Configuration Le fichier de configuration par défaut de Samba est installé sous le nom /usr/local/etc/smb.conf.default. Ce fichier doit être copié vers /usr/local/etc/smb.conf et personnalisé avant que Samba ne puisse être utilisé. Le fichier smb.conf contient la configuration nécessaire à l'exécution de Samba, comme la définition des imprimantes et des “systèmes de fichiers partagés” que vous désirez partager avec les clients &windows;. Le logiciel Samba comprend une interface Web appelé swat qui offre une méthode simple de configuration du fichier smb.conf. Utilisation de l'interface web d'administration de Samba (SWAT) L'interface web d'administration de Samba (SWAT) est exécutée sous la forme d'un “daemon” à partir d'inetd. Par conséquent, la ligne suivante dans le fichier /etc/inetd.conf doit être décommentée avant que swat ne puisse être utilisé pour configurer Samba: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Comme expliqué dans la , la configuration d'inetd doit être rechargée après modification de ce fichier de configuration. Une fois que swat a été activé dans inetd.conf, vous pouvez utiliser un navigateur pour vous connecter à l'adresse . Vous devez ouvrir tout d'abord une session sous le compte système root. Une fois que vous avez ouvert une session sur la page principale de configuration de Samba, vous pouvez naviguer dans la documentation du système, ou commencer par cliquer sur l'onglet Globals. Le menu Globals correspond aux variables situées dans la section [global] du fichier /usr/local/etc/smb.conf. Paramétrages généraux Que vous utilisiez swat ou éditiez directement le fichier /usr/local/etc/smb.conf, les premières directives que vous allez sûrement rencontrer en configurant Samba seront: workgroup Le nom de domaine NT ou le groupe de travail pour les ordinateurs qui accéderont à ce serveur. netbios name NetBIOS Fixe le nom NetBIOS sous lequel est connu le serveur Samba. Par défaut c'est le même que la première composante du nom de la machine pour le DNS. server string Cette directive définie la chaîne de caractères qui sera affichée lors de l'utilisation de la commande net view et par d'autres outils réseau recherchant à afficher une description du serveur. Paramètres de sécurité Deux des plus importants paramétrages de /usr/local/etc/smb.conf sont le mode de sécurité choisi, et le format de mot de passe pour les utilisateurs. Les directives suivantes contrôlent ces options: security Les deux options les plus courantes sont security = share et security = user. Si vos clients utilisent des noms d'utilisateur identiques à ceux sur votre machine &os;, alors vous voudrez utiliser un niveau de sécurité utilisateur. C'est le mode de sécurité par défaut et qui demande aux clients de d'ouvrir une session avant de pouvoir accéder aux ressources partagées. Dans le niveau de sécurité partage (“share”), le client n'a pas besoin d'ouvrir de session avant de pouvoir se connecter à une ressource partagée. C'était le mode de sécurité par défaut d'anciennes versions de Samba. passdb backend NIS+ LDAP base de données SQL Samba possède plusieurs modèles de support d'authentification. Vous pouvez authentifier des clients avec LDAP, NIS+, une base de données SQL ou un fichier de mot de passe modifié. La méthode d'authentification par défaut est appelée smbpasswd, et c'est celle qui sera présentée ici. En supposant que le modèle smbpasswd par défaut est utilisé, le fichier /usr/local/private/smbpasswd doit être créé pour permettre à Samba d'identifier les clients. Si vous désirez donner accès à vos comptes utilisateur &unix; à partir de clients &windows;, utilisez la commande suivante: &prompt.root; smbpasswd -a username Veuillez consulter le tutorial officiel de Samba pour des informations supplémentaires sur les options de configuration. Avec les bases présentées ici, vous devriez disposer de tous les éléments nécessaires au démarrage de Samba. Démarrage de <application>Samba</application> Le logiciel porté net/samba3 amène une nouvelle procédure de démarrage qui peut être employée pour contrôler Samba. Pour activer cette procédure de manière à ce qu'elle soit utilisée pour par exemple lancer, arrêter ou relancer Samba, ajoutez la ligne suivante au fichier /etc/rc.conf: samba_enable="YES" Ou, pour un contrôle plus fin: nmbd_enable="YES" smbd_enable="YES" Avec cela, Samba sera automatiquement lancé au démarrage. Il est alors possible de démarrer Samba à n'importe quel moment en tapant: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Veuillez consulter la pour plus d'information sur les procédures rc. Samba consiste essentiellement en trois “daemon”s séparés. Vous devriez vous rendre compte que les “daemon”s nmbd et smbd sont lancés par la procédure samba. Si vous avez activé la résolution de noms winbind dans le fichier smb.conf, alors le “daemon” winbindd sera également lancé. Vous pouvez arrêter Samba à tout moment en tapant: &prompt.root; /usr/local/etc/rc.d/samba stop Samba est une suite logiciels complexes avec des fonctionnalités permettant une large intégration avec les réseaux µsoft.windows;. Pour plus d'information sur les fonctionnalités non-abordées dans ce document, veuillez consulter . Tom Hukins Contribution de Synchronisation de l'horloge avec NTP NTP Généralités Avec le temps, l'horloge d'un ordinateur tend à dériver. Le protocole NTP (“Network Time Protocol”) est une des manières pour s'assurer que votre horloge reste précise. De nombreux services Internet ont besoin, ou tirent partie, de la précision des horloges des ordinateurs. Par exemple, un serveur web, peut recevoir des requêtes pour n'envoyer un fichier que s'il a été modifié depuis un certain temps. Sur un réseau local, il est essentiel que les ordinateurs partageant des fichiers à partir du même serveur de fichiers aient des horloges synchronisées de manière à ce que les dates de création ou de dernière modification d'un fichier (“timestamp”) soient cohérentes. Des services comme &man.cron.8; reposent sur une horloge système précise pour exécuter des commandes à des moments précis. NTP ntpd &os; est fourni avec le serveur NTP &man.ntpd.8; qui peut être utilisé pour contacter d'autres serveurs NTP pour régler l'horloge de votre machine ou pour jouer le rôle de serveur de temps pour d'autres. Choisir les serveurs NTP appropriés NTP choisir les serveurs Afin de synchroniser votre horloge, vous devrez trouver un ou plusieurs serveurs NTP. Votre administrateur réseau ou votre FAI peuvent avoir mis en place un serveur NTP dans cet objectif—consultez leur documentation pour voir si c'est le cas. Il existe une liste en ligne de serveurs NTP accessibles par le public que vous pouvez utiliser pour trouver un serveur NTP proche de vous. Assurez-vous d'avoir pris connaissance de la politique d'utilisation des serveurs que vous choisissez, et demandez la permission si nécessaire. Choisir plusieurs serveurs NTP non-connectés entre eux est une bonne idée au cas où un des serveurs que vous utilisez devient inaccessible ou que son horloge n'est plus fiable. &man.ntpd.8; utilise intelligemment les réponses qu'il reçoit d'autres serveurs—il favorisera les plus fiables par rapport aux moins fiables. Configuration de votre machine NTP configuration Configuration de base ntpdate Si vous désirez synchroniser votre horloge uniquement lors du démarrage de la machine, vous pouvez alors employer &man.ntpdate.8;. Cela peut être approprié pour certaines machines de bureau qui sont fréquemment rédémarrées et qui ne nécessites qu'une synchronisation épisodique, cependant la plupart des machines devraient utiliser &man.ntpd.8;. Utiliser &man.ntpdate.8; au moment du démarrage est également une bonne idée pour les machines qui exécutent &man.ntpd.8;. Le programme &man.ntpd.8; modifie l'horloge graduellement, alors que &man.ntpdate.8; change directement l'horloge, peu importe la différence entre l'heure actuelle de la machine et l'heure correcte. Pour activer &man.ntpdate.8; au démarrage, ajoutez la ligne ntpdate_enable="YES" au fichier /etc/rc.conf. Vous devrez également préciser tous les serveurs avec lesquels vous désirez vous synchroniser et tous les indicateurs devant être passés à &man.ntpdate.8; avec ntpdate_flags. NTP ntp.conf Configuration générale NTP est configuré par l'intermédiaire du fichier /etc/ntp.conf suivant le format décrit dans la page de manuel &man.ntp.conf.5;. Voici un exemple simple: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift L'option server précise quels serveurs doivent être utilisés, avec un serveur listé par ligne. Si un serveur est spécifié avec l'argument prefer, comme c'est le cas pour ntplocal.example.com, ce serveur est préféré par rapport aux autres serveurs. Une réponse en provenance d'un serveur préféré sera ignorée si elle diffère de façon significative des réponses des autres serveurs, sinon elle sera utilisée sans considérer les autres réponses. L'argument prefer est normalement employé pour les serveurs NTP qui sont connus pour leur grande précision, comme ceux avec des systèmes spéciaux de contrôle du matériel. L'option driftfile précise quel fichier est utilisé pour stocker le décalage de fréquence de l'horloge. Le programme &man.ntpd.8; l'utilise pour compenser automatiquement la dérive naturelle de l'horloge, permettant de maintenir un réglage raisonnablement correct même s'il est coupé d'autres sources extérieures de temps pendant une certaine période. L'option driftfile précise également quel fichier est utilisé pour stocker l'information concernant les réponses précédentes des serveurs NTP que vous utilisez. Il ne devrait pas être modifié par un autre processus. Contrôler l'accès à votre serveur Par défaut, votre serveur NTP sera accessible par toutes les machines sur l'Internet. L'option restrict du fichier /etc/ntp.conf vous permet de contrôler quelles machines peuvent accéder à votre serveur. Si vous voulez refuser à tout le monde l'accès à votre serveur NTP, ajoutez la ligne suivante au fichier /etc/ntp.conf: restrict default ignore Cela empêchera également à votre serveur d'accéder à tout serveur listé dans votre configuration locale. Si vous avez besoin de synchroniser votre serveur NTP avec un serveur NTP externe, vous devez alors autoriser le serveur en question. Consultez la page de manuel de &man.ntp.conf.5; pour plus d'information. Si vous désirez autoriser uniquement l'accès aux machines de votre réseau pour qu'elles puissent synchroniser leur horloge, tout en vous assurant qu'elles ne peuvent configurer le serveur ou être utilisées comme point de de synchronisation, ajoutez: restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap à la place, où 192.168.1.0 est une adresse IP de votre réseau et 255.255.255.0 est votre masque de sous-réseau. Le fichier /etc/ntp.conf peut contenir plusieurs options restrict. Pour plus de détails, lisez la section Access Control Support de la page de manuel &man.ntp.conf.5;. Exécuter le serveur NTP Pour s'assurer que le serveur NTP est lancé au démarrage, ajoutez la ligne ntpd_enable="YES" dans le fichier /etc/rc.conf. Si vous désirez passer des indicateurs supplémentaires à &man.ntpd.8;, éditez les paramètres de l'option ntpd_flags dans /etc/rc.conf. Pour lancer le serveur sans redémarrer votre machine, exécutez ntpd en étant sûr de préciser tout paramètre supplémentaire de ntpd_flags dans /etc/rc.conf. Par exemple: &prompt.root; ntpd -p /var/run/ntpd.pid Utiliser ntpd avec une connexion Internet temporaire Le programme &man.ntpd.8; n'a pas besoin d'une connexion permanente à l'Internet pour fonctionner correctement. Cependant, si vous disposez d'une connexion temporaire qui est configurée de telle sorte qu'il y ait établissement de la connexion à la demande, c'est une bonne idée d'empêcher le trafic NTP de déclencher la numérotation ou de maintenir constamment établie la connexion. Si vous utilisez PPP en mode utilisateur, vous pouvez employer les directives filter dans le fichier /etc/ppp/ppp.conf. Par exemple: set filter dial 0 deny udp src eq 123 # Empêche le trafic NTP de lancer une connexion set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Empêche le trafic NTP entrant de garder la connexion établie set filter alive 1 deny udp dst eq 123 # Empêche le trafic NTP sortant de garder la connexion établie set filter alive 2 permit 0/0 0/0 Pour plus de détails lisez la section PACKET FILTERING de la page de manuel &man.ppp.8; et les exemples du répertoire /usr/share/examples/ppp/. Certains fournisseurs d'accès Internet bloquent les ports dont le numéro est faible, empêchant NTP de fonctionner puisque les réponses n'atteingnent jamais votre machine. Information supplémentaire La documentation pour le serveur NTP peut être trouvée dans le répertoire /usr/share/doc/ntp/ sous le format HTML.