diff --git a/fr_FR.ISO8859-1/books/handbook/mirrors/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/mirrors/chapter.sgml index c2968f98d8..7a3fd7acd9 100644 --- a/fr_FR.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,3628 +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:
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 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 - (Utilisez cvs login et entrez le mot - de passe “anoncvs” quand on vous le - demandera.) - - - Allemagne: - :pserver:anoncvs@anoncvs2.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 8b:c4:6f:9a:7e:65:8a:eb:50:50:29:7c:a1:47:03:bc root@ender.liquidneon.com -SSH2 HostKey: 2048 4d:59:19:7b:ea:9b:76:0b:ca:ee:da:26:e2:3a:83:b8 ssh_host_dsa_key.pub + 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 - (ssh uniquement - pas de mot de passe) + (ssh2 uniquement - pas de mot de passe) - SSH HostKey: 1024 4b:83:b6:c5:70:75:6c:5b:18:8e:3a:7a:88:a0:43:bb root@ender.liquidneon.com -SSH2 HostKey: 1024 80:a7:87:fa:61:d9:25:5c:33:d5:48:51:aa:8f:b6:12 ssh_host_dsa_key.pub + 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. 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.jp.FreeBSD.org:/home/ncvs + &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login -At the prompt, enter the password anoncvs. +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.jp.FreeBSD.org:/home/ncvs + &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login -At the prompt, enter the password anoncvs. +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.jp.FreeBSD.org:/home/ncvs + &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login -At the prompt, enter the password anoncvs. +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.jp.FreeBSD.org:/home/ncvs + &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login -At the prompt, enter the password anoncvs. +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 + 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;. - Toutes questions et rapports de bogues devraient être - adressés à l'auteur du programme à adresse - cvsup-bugs@polstra.com. + 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/network-servers/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/network-servers/chapter.sgml index 157443b6f7..7c0e1bb57b 100644 --- a/fr_FR.ISO8859-1/books/handbook/network-servers/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/network-servers/chapter.sgml @@ -1,5878 +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 souvent référence à + 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 une instance - d'inetd réduit la charge - système globale par rapport à l'exécution + 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 - /etc/rc.conf. L'option + &man.rc.8;. L'option inetd_enable est positionnée à la valeur NO par défaut, - mais est activée par - sysinstall avec le profil de - sécurité modéré. Placer - inetd_enable="YES" ou - inetd_enable="NO" dans - /etc/rc.conf peut activer ou - désactiver le démarrage + 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. + 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 - Synopsis d'inetd: + 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 - - - -d - - - Active le débogage. - - - - - -l - - - Active le journal des connexions - réussies. - - - - - -w - - - Active le “TCP Wrapping” pour les - services externes (actif par défaut). - - - - - -W - - - Active le “TCP Wrapping” pour les - services internes qui font partie - d'inetd (actif par - défaut). - - + 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. - -a - - - Indique l'adresse IP sur laquelle le trafic sera - attendu. Alternativement, un nom de machine peut - être utilisé, dans ce cas l'adresse IPv4 ou - IPv6 correspondant à la machine sera - utilisée. Généralement, un nom de - machine est précisé quand - inetd est exécuté - à l'intérieur d'un environnement - &man.jail.8;, dans quel cas le nom de machine correspond - à l'environnement &man.jail.8;. - - Quand un nom de machine est utilisé et que - l'on doit être à l'écoute sur une - adresse IPv4 et IPv6, une entrée avec le - protocole adapté pour chaque type d'adresse est - nécessaire pour chaque service dans - /etc/inetd.conf. Par exemple, un - service de type TCP nécessitera deux - entrées, une utilisant tcp4 - pour le protocole et une autre utilisant - tcp6. - - - - - -p + -s maximum - Spécifie un fichier différent dans - lequel stocker l'indentifiant du processus. + 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 + . - - Ces options peuvent être passées à - inetd en utilisant l'option - inetd_flags de - /etc/rc.conf. Par défaut, - inetd_flags est positionné à - -wW, ce qui active le “TCP - wrapping” pour les services internes et externes - d'inetd. Pour un utilisateur de - base ces paramètres ne doivent - généralement pas être modifiés ou - même ajoutés au fichier - /etc/rc.conf. - - - Un service externe est un “daemon” - indépendant d'inetd, qui est - invoqué quand une connexion lui étant - destinée est reçue. D'autre part, un service - interne est un service qu'inetd - peut offrir directement. - - + <filename>inetd.conf</filename> La configuration d'inetd se fait par l'intermédiaire du fichier /etc/inetd.conf. Quand le fichier /etc/inetd.conf est modifié, inetd peut être forcé de relire son fichier de configuration - en envoyant un signal “HangUP” au processus - inetd comme suit: + en utilisant la commande: - - Envoyer un signal “HangUP” à - <application>inetd</application> + + Recharger le fichier de configuration + d'<application>inetd</application> - &prompt.root; kill -HUP `cat /var/run/inetd.pid` + &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 du fichier + “#”. 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” - ftpd utilisant l'IPv4: + &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]] + {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 , une - autre option limitant le nombre maximal de connexions + En plus de , deux + autres options limitant le nombre maximal de connexions à partir d'un emplacement vers un - “daemon” particulier peut être - activée. L'option - est - l'option en question. Ici, une valeur de dix limiterait + “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. C'est - utile pour empêcher l'abus intentionnel ou par - inadvertance des ressources et les attaques par - déni de service (“Denial of - Service—DOS”). + 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 - + , + et + sont optionnelles. Un “daemon” utilisant un flux de type multi-threadé sans limites - ou - + , + ou + sera tout simplement affecté de l'option nowait. Le même “daemon” avec une limite maximale de dix “daemon” serait: nowait/10. - De plus, la même configuration avec une limite + La même configuration avec une limite de vingt connexions par adresse IP par minute et une limite maximale de dix “daemon”s enfant serait: nowait/10/20. Ces options sont utilisées comme valeurs par défaut par le “daemon” - fingerd, comme le montre ce + &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 du profil de sécurité choisi - à l'installation, plusieurs “daemon”s + 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”, désactivez-le! Ajoutez un + d'un “daemon”, envisagez de le désactiver. Ajoutez un caractère “#” devant le “daemon” en question dans le fichier - /etc/inetd.conf, et envoyez ensuite un - signal hangup à - inetd. Certains “daemon”s comme + /etc/inetd.conf, et ensuite + rechargez la + configuration + d'inetd. Certains daemons comme fingerd, devraient être - évités parce qu'ils donnent trop d'informations - aux personnes malveillantes. + é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é, ou n'ont pas de - délai limite d'expiration pour les tentatives de + 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 - et + , + ou sur certains - “daemon”s. + 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 - (ident, - identd), et est configurable - à un certain degré. + 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. - Sous &os; 4.X, l'utilitaire - portmap est utilisé - à la place de rpcbind. Aussi - sous &os; 4.X l'utilisateur doit remplacer chaque - instance de rpcbind avec - portmap dans les exemples qui - suivent. - Sur le serveur, les “daemons” suivants doivent tourner: NFS serveur - rpcbind + serveur de fichiers + clients UNIX - portmap + 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 - Vous devez relancer mountd - à chaque fois que vous modifiez - /etc/exports pour que les changements - puissent prendre effet. Cela peut être effectué - en envoyant le signal HUP au processus - mountd: + 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 (sous - &os; 4.X portmap est - utilisé à la place de - rpcbind). + jouer le rôle d'un client NIS. ypbind Fait pointer un client NIS vers son serveur NIS. Il récupérera le nom de domaine NIS auprès du système, et en utilisant les RPC, se connectera au serveur. ypbind est le coeur de la communication client-serveur dans un environnement NIS; si ypbind meurt sur une machine cliente, elle ne sera pas en mesure d'accéder au serveur NIS. ypserv Ne devrait tourner que sur les serveurs NIS, c'est le processus serveur en lui-même. Si &man.ypserv.8; meurt, alors le serveur ne pourra plus répondre aux requêtes NIS (avec un peu de chance, un serveur esclave prendra la relève). Il existe des implémentations de NIS (mais ce n'est pas le cas de celle de &os;), qui n'essayent pas de se reconnecter à un autre serveur si le serveur utilisé précédement meurt. Souvent, la seule solution dans ce cas est de relancer le processus serveur (ou même redémarrer le serveur) ou le processus ypbind sur le client. rpc.yppasswdd Un autre processus qui ne devrait tourner que sur les serveurs maître NIS; c'est un “daemon” qui permettra aux clients de modifier leur mot de passe NIS. Si ce “daemon” ne tourne pas, les utilisateurs devront ouvrir une session sur le serveur maître NIS et y changer à cet endroit leur mot de passe. Comment cela fonctionne-t-il? Dans un environnement NIS il y a trois types de machines: les serveurs maîtres, les serveurs esclaves et les clients. Les serveurs centralisent les informations de configuration des machines. Les serveurs maîtres détiennent l'exemplaire de référence de ces informations, tandis que les serveurs esclaves en ont un double pour assurer la redondance. Les clients attendent des serveurs qu'ils leur fournissent ces informations. Le contenu de nombreux fichiers peut être partagé de cette manière. Les fichiers master.passwd, group, et hosts sont fréquemment partagés par l'intermédiaire de NIS. A chaque fois qu'un processus d'une machine cliente a besoin d'une information qu'il trouverait normalement localement dans un de ces fichiers, il émet une requête au serveur NIS auquel il est rattaché pour obtenir cette information. Type de machine NIS serveur maître Un serveur NIS maître. Ce serveur, analogue à un contrôleur de domaine &windowsnt; primaire, gère les fichiers utilisés par tous les clients NIS. Les fichiers passwd, group, et les autres fichiers utilisés par les clients NIS résident sur le serveur maître. Il est possible pour une machine d'être un serveur NIS maître pour plus qu'un domaine NIS. Cependant, ce cas ne sera pas abordé dans cette introduction, qui suppose un environnement NIS relativement petit. NIS serveur esclave Serveurs NIS esclaves. Similaire aux contrôleurs de domaine &windowsnt; de secours, les serveurs NIS esclaves possèdent une copie des fichiers du serveur NIS maître. Les serveurs NIS esclaves fournissent la redondance nécessaire dans les environnements importants. Ils aident également à à la répartition de la charge du serveur maître: les clients NIS s'attachent toujours au serveur NIS dont ils reçoivent la réponse en premier, y compris si c'est la réponse d'un serveur esclave. NIS client Clients NIS. Les clients NIS, comme la plupart des stations de travail &windowsnt;, s'identifient auprès du serveur NIS (ou le contrôleur de domaine &windowsnt; dans le cas de stations de travail &windowsnt;) pour l'ouverture de sessions. Utiliser NIS/YP Cette section traitera de la configuration d'un exemple d'environnement NIS. - Dans cette section on suppose que vous utilisez - &os; 3.3 ou une version suivante. Les instructions - fournies fonctionneront probablement - avec n'importe quelle version de &os; supérieure - à 3.0, mais il n'y a aucune garantie que cela soit le - cas. - Planification Supposons que vous êtes l'administrateur d'un petit laboratoire universitaire. Ce laboratoire dispose de 15 machines &os;, et ne possède pas actuellement de point central d'administration; chaque machine a ses propres fichiers /etc/passwd et /etc/master.passwd. Ces fichiers sont maintenus à jour entre eux grâce à des interventions manuelles; actuellement quand vous ajoutez un utilisateur pour le laboratoire, vous devez exécuter adduser sur les 15 machines. Cela doit changer, vous avez donc décidé de convertir le laboratoire à l'utilisation de NIS en utilisant deux machines comme serveurs. La configuration du laboratoire ressemble à quelque chose comme: Nom de machine Adresse IP Rôle de la machine ellington 10.0.0.2 Maître NIS coltrane 10.0.0.3 Esclave NIS basie 10.0.0.4 Station de travail bird 10.0.0.5 Machine cliente cli[1-11] 10.0.0.[6-17] Autres machines clientes Si vous mettez en place un système NIS pour la première fois, c'est une bonne idée de penser à ce que vous voulez en faire. Peu importe la taille de votre réseau, il y a quelques décisions à prendre. Choisir un nom de domaine NIS NIS nom de domaine Ce n'est pas le “nom de domaine” dont vous avez l'habitude. Il est plus exactement appelé “nom de domaine NIS”. Quand un client diffuse des requêtes pour obtenir des informations, il y inclut le nom de domaine NIS auquel il appartient. C'est ainsi que plusieurs serveurs d'un même réseau peuvent savoir lequel d'entre eux doit répondre aux différentes requêtes. Pensez au nom de domaine NIS comme le nom d'un groupe de machines qui sont reliées entre elles. Certains 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 tcpwrapper + également l'outil TCP Wrapper de Wietse Venema. Cela permet à l'administrateur d'utiliser les fichiers de configuration de - tcpwrapper pour contrôler les + 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. - tcpwrapper + TCP Wrapper L'utilisation du système - tcpwrapper augmente les temps de + 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. &os; utilise l'implémentation DHCP de - l'ISC (Internet Software Consortium), aussi toutes les - informations spécifiques à - l'implémentation, ici, concernent la version - distribuée par l'ISC. + 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 et côté serveur du + 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, dhclient, est + 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 (pseudo-device - bpf sous &os; 4.X) à votre fichier + 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) - de l'ensemble DHCP. + du serveur DHCP. - La partie serveur n'est pas fournie dans le + Le serveur n'est pas fourni dans le système de base de &os;, et vous devrez installer le logiciel porté net/isc-dhcp3-relay pour + role="package">net/isc-dhcp3-server pour bénéficier de ce service. Lisez le pour plus d'information sur l'utilisation du catalogue des logiciels portés. Installation d'un serveur DHCP DHCP installation Afin de configurer votre système &os; en serveur DHCP, vous devrez vous assurer que le support du périphérique &man.bpf.4; est compilé dans votre noyau. Pour cela ajouter la ligne - device bpf (pseudo-device - bpf sous &os; 4.X) dans votre fichier de + 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 (DNS) + 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é, et d'autres serveurs de noms de plus + 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. - Ce document fait référence à BIND - 8.x, comme c'est la version stable utilsée dand &os;. - BIND 9.x peut être installée à l'aide du - logiciel porté net/bind9. - - Les RFC1034 et RFC1035 régissent le protocole - DNS. - Actuellement, BIND est maintenu par l'Internet Software Consortium . 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 une zone sous la + org. est un domaine de premier niveau + (TLD) sous la zone racine example.org. est une - zone sous la zone org. - - - foo.example.org. - est un sous-domaine, une zone sous la zone example.org. + zone sous le TLD + org. - 1.2.3.in-addr.arpa est une zone faisant + 1.168.192.in-addr.arpa est une zone faisant référence à toutes les adresses IP qui appartiennent l'espace d'adresse 3.2.1.*. + role="ipaddr">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 serveur de noms de secours, appelé esclave, - doit répondre aux requêtes quand le serveur - primaire est tombé ou inaccessible. + 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. - - une réduction du trafic réseau global - est désirée (il a été - mesuré que 5% ou plus du trafic Internet total - concerne le trafic DNS). - Quand on émet des requêtes pour www.FreeBSD.org, le résolveur interroge généralement le serveur de noms du fournisseur d'accès, et récupère la réponse. Avec un serveur DNS cache local, la requête doit être effectuée qu'une seule fois vers le monde extérieur par le serveur DNS cache. Chaque interrogation suivante n'aura pas à être transmise en dehors du réseau local, puisque l'information est désormais disponible localement dans le cache. Comment cela fonctionne-t-il? Sous &os; le “daemon” BIND est appelé named pour des raisons évidentes. Fichier Description - named + &man.named.8; le “daemon” BIND - ndc + &man.rndc.8; le programme de contrôle du - “daemon” + 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” - Les fichiers de zone sont généralement - stockés dans le répertoire /etc/namedb, et contiennent les - informations concernant les zones DNS gérées par - le serveur de noms. + 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é au + named est lancé à chaque démarrage, ajoutez la ligne suivante dans /etc/rc.conf: named_enable="YES" - Pour démarrer le “daemon” manuellement - (après l'avoir configuré): - - &prompt.root; ndc start + 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> - Assurez-vous d'effectuer: - - &prompt.root; cd /etc/namedb -&prompt.root; sh make-localhost - - pour générer correctement le fichier de - zone DNS inverse - /etc/namedb/localhost.rev. + 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$ + // $FreeBSD$ // -// Reportez-vous à la page de manuel named(8) pour plus de -// détails. Si vous devez configurer un serveur primaire -// assurez-vous d'avoir compris les détails épineux du -// fonctionnement du DNS. Même avec de simples erreurs, vous -// pouvez rompre la connexion entre les parties affectées, ou -// causer un important trafic Internet inutile. +// 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.1, BIND utilise - * par défaut un port quelconque non + * version 8, BIND utilise + * par défaut un port pseudo-aléatoire quelconque non * réservé. */ // query-source address * port 53; - - /* - * Si exécution dans un "sandbox", vous pourrez avoir - * à indiquer un emplacement différent pour le - * fichier de sortie de la base de données. - */ - // dump-file "s/named_dump.db"; }; -// Note: ce qui suit sera supporté dans une future version. -/* -host { any; } { - topology { - 127.0.0.0/8; - }; -}; -*/ - -// Configurer des serveurs secondaires est plus simple et le principe -// général est présenté plus bas. -// // Si vous activez un serveur de noms local, n'oubliez pas d'entrer // 127.0.0.1 dans votre fichier /etc/resolv.conf de sorte que ce // serveur soit interrogé le premier. Assurez-vous // également de l'activer dans /etc/rc.conf. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; - file "localhost.rev"; + file "master/localhost.rev"; }; -zone -"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { - type master; - file "localhost.rev"; +// 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 serveur secondaire. -// Il peut être pratique de devenir serveur secondaire pour la +// 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 un -// serveur secondaire est plus simple. +// 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. -// -// NOTE!!! &os; exécute BIND dans un "sandbox" (voir l'option -// named_flags dans rc.conf). Le répertoire contenant les -// zones secondaires doit être accessible à BIND en -// écriture. La séquence suivante est -// suggérée: -// -// mkdir /etc/namedb/s -// chown bind:bind /etc/namedb/s -// chmod 750 /etc/namedb/s - - Pour plus d'informations sur l'exécution de BIND - dans un “sandbox” (bac à sable), - consultez la section Exécution de named - dans un sandbox. - - - /* -zone "example.com" { - type slave; - file "s/example.com.bak"; - masters { - 192.168.1.1; - }; + +/* Un exemple de zone maître +zone "example.net" { + type master; + file "master/example.net"; }; +*/ -zone "0.168.192.in-addr.arpa" { - type slave; - file "s/0.168.192.in-addr.arpa.bak"; - masters { - 192.168.1.1; - }; +/* 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 "example.org"; + 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/example.org comme + /etc/namedb/master/example.org comme précisé par l'option . zone "example.org" { type slave; - file "example.org"; + 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/example.org) suit: - - $TTL 3600 + /etc/namedb/master/example.org) suit: -example.org. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh - 3600 ; Retry - 604800 ; Expire - 86400 ) ; Minimum TTL + $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. + 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 3.2.1.2 -ns2 IN A 3.2.1.3 -mail IN A 3.2.1.10 -@ IN A 3.2.1.30 +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 @ - -; Enregistrement MX -@ IN MX 10 mail.example.org. +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. ( - 5 ; Serial + 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) - 5 + 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. 2001041002 - signifierait dernière modification le 10/04/2001, - le 02 indiquant que c'est la seconde + 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. + IN NS ns1.example.org. C'est une entrée de type NS. Tous les serveurs de noms qui doivent faire autorité pour la zone - devront inclure une de ces entrées. Le - caractère @ aurait pu être - remplacé par example.org.. Le - caractère @ étant - équivalent à l'origine. + devront inclure une de ces entrées. -localhost IN A 127.0.0.1 -ns1 IN A 3.2.1.2 -ns2 IN A 3.2.1.3 -mail IN A 3.2.1.10 -@ IN A 3.2.1.30 +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 - 3.2.1.2. Ici encore, le - symbôle d'origine, @, signifie que - example.org donnera pour résolution - d'adresse l'adresse 3.2.1.30. + 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 - correspondant à l'origine, ou encore example.org (3.2.1.30). Les enregistrements CNAME + 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. + IN MX 10 mail.example.org. L'enregistrement MX indique quels serveurs de messagerie sont responsables de la gestion du courrier entrant pour la zone. mail.example.org est le nom de machine du serveur de messagerie, et 10 étant la priorité du serveur de messagerie. On peut avoir plusieurs serveurs de messagerie, avec des - priorités de 3, 2, 1. Un serveur de messagerie + 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é, puis celui venant + 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.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial +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. + IN NS ns1.example.org. + IN NS ns2.example.org. -2 IN PTR ns1.example.org. -3 IN PTR ns2.example.org. -10 IN PTR mail.example.org. -30 IN PTR example.org. +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. - - Exécution <application>named</application> dans un - “sandbox” - - BIND - exécution dans un sandbox - - - - chroot - - Pour plus de sécurité, il peut être - préférable d'exécuter &man.named.8; sous un - utilisateur sans privilèges, et le configurer pour - modifier l'emplacement de la racine du système de - fichiers (&man.chroot.8;) vers le répertoire du - “sandbox” (bac à sable). Ceci rend - inaccessible au “daemon” - named tout ce qui est situé en - dehors de l'environnement “sandbox”. Si - named est compromis, cela - réduira l'impact des dommages. Par défaut, &os; - dispose d'un utilisateur et d'un groupe appelé - bind, destiné à cet - usage. - - - De nombreuses personnes recommanderont qu'à la - place de configurer named à - “chrooter”, vous devriez exécuter - named dans un environnement - &man.jail.8;. Cette section ne traitera pas ce cas de - figure. - - - Puisque named ne sera pas en - mesure d'avoir accès à des - éléments extérieur au - “sandbox” (comme aux bibliothèques - partagées, aux “sockets” pour - l'enregistrement des journaux, etc.), il y a un certain - nombre d'étapes à suivre afin de permettre - à named un fonctionnement - correct. Dans la liste d'opérations qui suit, on - suppose que l'emplacement du “sandbox” est - /etc/namedb et que vous - n'avez pas précédemment modifié le - contenu de ce répertoire. Effectuez les étapes - suivantes en tant que root: - - - - Créer tous les répertoires que - named s'attend à - trouver: - - &prompt.root; cd /etc/namedb -&prompt.root; mkdir -p bin dev etc var/tmp var/run master slave -&prompt.root; chown bind:bind slave var/* - - - - named n'a besoin - uniquement que d'un accès en écriture - à ces répertoires, c'est tout ce que nous - lui donnerons. - - - - - - Réarranger les fichiers de configuration et - créer la zone: - - &prompt.root; cp /etc/localtime etc -&prompt.root; mv named.conf etc && ln -sf etc/named.conf -&prompt.root; mv named.root master - -&prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master -&prompt.root; cat > master/named.localhost -$ORIGIN localhost. -$TTL 6h -@ IN SOA localhost. postmaster.localhost. ( - 1 ; serial - 3600 ; refresh - 1800 ; retry - 604800 ; expiration - 3600 ) ; minimum - IN NS localhost. - IN A 127.0.0.1 -^D - - - - Ceci permet à named - d'utiliser des dates correctes lors de l'envoie des - journaux à &man.syslogd.8;. - - - - - syslog - journaux - DNS - - - Si vous utilisez une version de &os; antérieure - à 4.9-RELEASE, compilez une version liée en - statique de named-xfer, et - copiez-la dans le “sandbox”: - - &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir && make cleandir && make depend && make all -&prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir && make cleandir && make depend && make all -&prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all -&prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer - - Après avoir installé votre version - statique de named-xfer, un peu de - nettoyage est nécessaire pour éviter de - conserver des copies inutiles de bibliotèques ou de - programmes dans votre arborescence des sources: - - &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir -&prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir -&prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir - - - - Il a été signalé que cette - étape peut parfois échouer. Si cela vous - arrive, tapez alors la commande: - - &prompt.root; cd /usr/src && make cleandir && make cleandir - - et effacez votre arborescence - /usr/obj: - - &prompt.root; rm -fr /usr/obj && mkdir /usr/obj - - Cela devrait supprimer les éventuels - “scories” de votre arborescence des - sources, puis en réessayant les - opérations ci-dessus cela devrait enfin - fonctionner. - - - - Si vous utilisez &os; 4.9-RELEASE ou une version - suivante, alors la version de - named-xfer se trouvant dans le - répertoire /usr/libexec est liée - en statique par défaut, et vous pouvez tout - simplement utiliser la commande &man.cp.1; pour la copier - dans l'environnement “sandbox”. - - - - Créer un fichier spécial de - périphérique dev/null - dans lequel named peut lire et - écrire: - - &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 -&prompt.root; chmod 666 null - - - - Créer un lien symbolique de - /var/run/ndc vers - /etc/namedb/var/run/ndc: - - &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc - - - Ceci évite tout simplement d'avoir à - spécifier l'option à - &man.ndc.8; à chaque fois que vous - l'exécutez. Comme le contenu du répertoire - /var/run est - effacé au démarrage, il peut être - utile d'ajouter cette commande dans le fichier - &man.crontab.5; de l'utilisateur - root en utilisant l'option - . - - - - syslog - journaux - named - - - Configurer &man.syslogd.8; pour qu'il - créé une “socket” - supplémentaire log sur - laquelle named dispose d'un - accès en écriture. Pour cela, ajoutez - -l /etc/namedb/dev/log à la - variable syslogd_flags du fichier - /etc/rc.conf. - - - chroot - - - S'arranger à ce que - named démarre et se - “chroot” lui-même dans - l'environnement “sandbox” en ajoutant ce qui - suit au fichier /etc/rc.conf: - - named_enable="YES" -named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" - - - Notez que l'emplacement du fichier de configuration - /etc/named.conf est - référencé par rapport un chemin - complet relatif au - “sandbox”, i.e. dans la ligne - au-dessus, le fichier auquel on fait - référence est en fait - /etc/namedb/etc/named.conf. - - - - - L'étape suivante est d'éditer le fichier - /etc/namedb/etc/named.conf pour que - named puisse savoir quelles zones - charger et où les trouver sur le disque. Un exemple - commenté suit (tout ce qui n'est pas - spécifiquement commenté ici n'est pas - différent de la configuration d'un serveur DNS ne - tournant pas dans un “sandbox”): - - options { - directory "/"; - named-xfer "/bin/named-xfer"; - version ""; // Ne pas révéler la version de BIND - query-source address * port 53; -}; -// socket de contrôle ndc -controls { - unix "/var/run/ndc" perm 0600 owner 0 group 0; -}; -// Les zones: -zone "localhost" IN { - type master; - file "master/named.localhost"; - allow-transfer { localhost; }; - notify no; -}; -zone "0.0.127.in-addr.arpa" IN { - type master; - file "master/localhost.rev"; - allow-transfer { localhost; }; - notify no; -}; -zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { - type master; - file "master/localhost-v6.rev"; - allow-transfer { localhost; }; - notify no; -}; -zone "." IN { - type hint; - file "master/named.root"; -}; -zone "private.example.net" in { - type master; - file "master/private.example.net.db"; - allow-transfer { 192.168.10.0/24; }; -}; -zone "10.168.192.in-addr.arpa" in { - type slave; - masters { 192.168.10.2; }; - file "slave/192.168.10.db"; -}; - - - - L'option directory est - définie par /, - puisque tous les fichiers dont - named a besoin sont dans ce - répertoire (ceci est équivalent au fichier - /etc/namedb d'un utilisateur - “normal”). - - - - Indique le chemin d'accès complet du binaire - named-xfer (à partir de - l'arborescence utilisée pour - named). Ceci est - nécessaire puisque named - est compilé pour chercher - named-xfer par défaut dans le - répertoire /usr/libexec. - - - Indique le nom de fichier (relatif à la valeur - de directory plus haut) où - named le fichier de zone pour - cette zone. - - - Indique le nom de fichier (relatif à la valeur - de directory plus haut) où - named devrait trouver une copie - du fichier de zone pour cette zone après l'avoir - transféré avec succès à partir - du serveur maître. C'est pourquoi nous avons eu - besoin de changer le propriétaire du - répertoire slave pour - bind dans les étapes de - configuration précédentes. - - - - Après avoir complétées les - étapes précédentes, redémarrez - votre serveur ou relancez &man.syslogd.8; et démarrez - &man.named.8;, en s'assurant de bien utiliser les nouvelles - options spécifiées dans les variables - syslogd_flags et - named_flags. Vous devriez disposez - maintenant d'une version de named - tournant dans un environnement “sandbox”! - - Sécurité Bien que BIND soit l'implémentation la plus courante du DNS, le problème de la sécurité subsiste toujours. De possibles problèmes de sécurité exploitables sont parfois découvert. + 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.ndc.8; + 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 4ème Edition de chez O'Reilly + DNS + et BIND 5ème Edition de chez O'Reilly RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification - - - - - Tom - Rhodes - Ecrit par - - - - <acronym>BIND</acronym>9 et &os; - - - - bind9 - configuration - - L'arrivée de &os; 5.3 a apporté le - serveur DNS BIND9 dans la - distribution. De nouvelles fonctionnalités concernant la - sécurité, une nouvelle organisation des fichiers, - une configuration &man.chroot.8; automatisée, font partie - des nouveautés. Cette section est divisée en deux - parties, la première abordera les nouvelles - fonctionnalités et leur configuration, la seconde - traitera des mises à jours en vue d'aider la migration - vers &os; 5.3. A partir de cet instant, il sera fait - référence au serveur à l'aide du nom - &man.named.8; à la place de BIND. - Cette section fait l'impasse sur la terminologie - présentée dans la section précédente - tout comme sur une partie de la théorie, par - conséquent il est recommandé de consulter la - section précédente avant d'aller plus loin. - - Les fichiers de configuration pour - named se trouvent dans le - répertoire /var/named/etc/namedb/ et devront - être adaptés avant toute utilisation. C'est - là où la majeure partie de la configuration se - fera. - - - Configuration d'une zone maître - - Pour configurer une zone maître, il faut se rendre - dans le répertoire /var/named/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 répertoire master. Le nom du fichier - devrait ê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, une - configuration pour son utilisation sera déjà - présente dans le fichier - named.conf. - - - - Configuration d'une zone esclave - - La configuration de domaines supplémentaires ou de - sous-domaines peut être faite sous la forme d'une zone - esclave. Dans la plupart des cas, le fichier - master/localhost.rev peut être - directement copié dans le répertoire slave et y être - modifié. Une fois complétés, les - fichiers doivent être ajoutés dans le fichier - named.conf comme dans la configuration - suivante pour example.com: - - zone "example.com" { - type slave; - file "slave/example.com"; - masters { - 10.0.0.1; - }; -}; - -zone "0.168.192.in-addr.arpa" { - type slave; - file "slave/0.168.192.in-addr.arpa"; - masters { - 10.0.0.1; - }; -}; - - Notez que dans cet exemple, l'adresse - IP du maître est celle du serveur - primaire du domaine à partir duquel les zones sont - transférées; il ne joue pas - nécessairement le rôle de serveur - DNS en tant que tel. - - - - Configuration de l'initialisation du - système - - Afin de lancer le daemon - named au démarrage du - système, l'option suivante doit être - présente dans le fichier - rc.conf: - - named_enable="YES" - - Alors que d'autres options existent, cela - représente le minimum nécessaire. Consultez la - page de manuel de &man.rc.conf.5; pour une liste des autres - options disponibles. Si rien n'est présent dans le - fichier rc.conf alors - named peut être - exécuté à partir de la ligne de commande - en invoquant: - - &prompt.root; /etc/rc.d/named start - - - - La sécurité et - <acronym>BIND</acronym>9 - - Bien que &os; enferme automatique - named dans un environnement - &man.chroot.8;, il existe plusieurs autres mécanismes de - sécurité présents qui pourraient aider - à se prémunir contre de possibles attaques - DNS. - - - Listes de contrôle d'accès des - requêtes - - Une liste de contrôle d'accès des - requêtes peut être employée pour - restreindre les requêtes sur certaines zones. La - configuration de cette liste fonctionne en - définissant le réseau concerné à - l'intérieur d'une directive acl - puis en listant les adresses IP dans la - configuration de zone. Pour autoriser des domaines à - envoyer des requêtes à la machine - utilisée en exemple, effectuez la définition - suivante: - - acl "example.com" { - 192.168.0.0/24; -}; - -zone "example.com" { - type slave; - file "slave/example.com"; - masters { - 10.0.0.1; - }; - allow-query { example.com; }; -}; - -zone "0.168.192.in-addr.arpa" { - type slave; - file "slave/0.168.192.in-addr.arpa"; - masters { - 10.0.0.1; - }; - allow-query { example.com; }; -}; - - - - Restreindre l'accès au numéro de - version - - Autoriser les requêtes sur le numéro de - version du serveur DNS peut ouvrir les - portes à un agresseur. Un utilisateur malveillant - peut utiliser cette information pour rechercher les exploits - connus ou les bogues à utiliser contre la machine. - Une fausse chaîne de caractères de version peut - être placée dans la section - options du fichier - named.conf: - - options { - directory "/etc/namedb"; - pid-file "/var/run/named/pid"; - dump-file "/var/dump/named_dump.db"; - statistics-file "/var/stats/named.stats"; - version "None of your business"; - - - - - Murray Stokely Contribution de Serveur HTTP Apache - serveur web + 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/apache2. + role="package">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 + 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 + 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> <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 + url="http://httpd.apache.org/docs/vhosts/">. 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 - serveur web + 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 + Apache 2.X avec le logiciel porté www/apache2, où il est + role="package">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 - 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. - Si vous n'avez pas encore installé - Apache, une version - d'Apache comprenant le module - mod_perl peut être - installée avec le logiciel porté www/apache13-modperl. - + 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. + - - PHP - - PHP - - PHP, qui signifie “PHP: Hypertext - Preprocessor” est un langage de script “Open - Source” très utilisé qui est tout - particulièrement adapté au - développement Web et peut être - intégré à du HTML. Sa syntaxe est - dérivée du C, du &java; et du Perl, et est - facile à apprendre. L'objectif principal de ce - langage est de permettre aux développeurs Web - d'écrire rapidement des pages au contenu - généré dynamiquement, mais vous pouvez - faire bien plus avec PHP. - - PHP peut être installé à partir du - logiciel porté + + + + 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) - serveur 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 , un signal - “HangUP” doit être envoyé à - inetd après que son fichier + linkend="network-inetd-reread">, 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 - journaux + 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 stream tcp nowait/400 root /usr/local/sbin/swat swat Comme expliqué dans la , un signal - “HangUP” doit être envoyé à - inetd après modification - de son fichier de configuration. + linkend="network-inetd-reread">, 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 à tous vos + Si vous désirez donner accès à vos comptes utilisateur &unix; à partir de clients &windows;, utilisez la commande suivante: - &prompt.root; grep -v "^#" /etc/passwd | make_smbpasswd > /usr/local/private/smbpasswd -&prompt.root; chmod 600 /usr/local/private/smbpasswd + &prompt.root; smbpasswd -a username - Veuillez consulter la documentation de - Samba pour des informations + 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> - Pour activer Samba au - démarrage du système, ajoutez la ligne suivante - au fichier /etc/rc.conf: + 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" - Vous pouvez alors démarrer - Samba en tapant: + 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.sh start + &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.sh. Si vous avez + 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.sh stop + &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 - - - Sous &os; 4.X, vous devez remplacer chaque - ntpd par xntpd dans les - options ci-dessus. Utiliser ntpd avec une connexion Internet temporaire Le programme &man.ntpd.8; n'a pas besoin d'une connexion permanente à l'Internet pour fonctionner correctement. Cependant, si vous disposez d'une 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.