diff --git a/fr_FR.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/cutting-edge/chapter.sgml index d3a26b7379..9ccbe1da2d 100644 --- a/fr_FR.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,2202 +1,2058 @@ Jim Mock Restructuré, réorganisé, et en partie mis à jour par Jordan Hubbard Travail original de Poul-Henning Kamp John Polstra Nik Clayton Questions avancées &trans.a.fonvieille; Synopsis &os; est en constant développement entre deux versions. Pour ceux désirant toujours être à jour, il existe plusieurs mécanismes simples pour maintenir votre système synchronisé avec les derniers développements. Soyez prévenus—cela ne s'adresse pas à tout le monde! Ce chapitre vous aidera à décider si vous voulez suivre les développements, ou vous en tenir aux versions publiées. Après la lecture de ce chapitre, vous connaîtrez: La différence entre les deux branches de développement: &os.stable; et &os.current;. Comment maintenir votre système à jour avec CVSup, CVS, ou CTM. Comment recompiler et réinstaller l'intégralité du système de base avec la commande make buildworld (etc.). Avant de lire ce chapitre, vous devrez: Correctement configurer votre connexion réseau (). Savoir comment installer des logiciels tiers (). &os.current; contre &os.stable; -CURRENT -STABLE Il existe deux branches de développement de FreeBSD: &os.current; et &os.stable;. Cette section détaillera un peu chacune d'elles et décrira comment garder à jour votre système avec chaque arborescence respective. &os.current; sera tout d'abord traité, suivit de &os.stable;. Se synchroniser avec la version -CURRENT de &os; En lisant ces lignes, gardez à l'esprit que &os.current; représente “les tout derniers” développement de &os;. On attend des utilisateurs de &os.current; un degré élevé de compétences techniques, et devraient être capables de résoudre des problèmes système compliqués par eux-mêmes. Si vous êtes nouveau à &os;, pensez à deux fois avant de l'installer. Qu'est-ce que &os.current;? instantané &os.current; est la toute dernière version des sources de &os; en cours de développement. Cela inclut des évolutions en cours, des modifications expérimentales, et des mécanismes de transition qui feront ou ne feront pas partie de la prochaine version officielle du logiciel. Bien que de nombreux développeurs de &os; compilent les sources de &os.current; quotidiennement, il arrive que celles-ci ne soient pas compilables pendant une certaine période de temps. Ces problèmes sont résolus aussi rapidement que possible, mais que &os.current; soit à l'origine d'un désastre ou de l'apport d'une nouvelle fonctionnalité attendue peut parfois dépendre que du moment auquel vous avez chargé le code source. Qui a besoin de &os.current;? &os.current; est mis à disposition pour 3 types de personnes: Les membres de la communauté &os; qui travaillent activement sur une partie de l'arborescence des sources et pour qui rester constamment à jour est une nécessité absolue. Les membres de la communauté &os; qui participent activement aux tests et sont disposés à passer du temps à résoudre les problèmes pour garantir que &os.current; reste aussi saine que possible. Il y a également ceux qui désirent faire des suggestions dans certains domaines sur les modifications à faire et la direction générale que prend &os;, et soumettent des correctifs pour les implémenter. Ceux qui veulent simplement garder un oeil sur les évolutions, ou utiliser les dernières sources comme référence (e.g. pour les lire, et non pour les utiliser). Ces personnes font parfois des remarques ou contribuent au code. Qu'est-ce que <emphasis>n'est pas</emphasis> &os.current;? Un raccourci pour se procurer des pré-versions parce que vous avez entendu dire qu'il y a de nouvelles fonctionnalités géniales et que vous voulez être le premier du coin à les avoir. Etre le premier à avoir la nouvelle fonctionnalité signifie être le premier à avoir les nouveaux bogues également. Une moyen rapide d'avoir des corrections de bogues. N'importe quelle version de &os.current; apportera probablement de nouveaux bogues comme elle corrigera ceux déjà présents. Nous ne le “supportons officiellement” en aucun cas. Nous faisons du mieux que nous pouvons pour aider les personnes qui font vraiment partie des trois groupes “légitimes” à qui s'adresse &os.current;, mais nous n'avons tout simplement “pas le temps” de fournir un support technique. Ce n'est pas parce que nous sommes des personnes détestables qui n'aiment pas aider les autres (nous ne ferions pas &os; si tel était le cas), nous ne pouvons simplement pas répondre à des centaines de messages par jour et travailler sur FreeBSD! Entre améliorer &os; et répondre à de nombreuses questions sur le code expérimental, les développeurs optent pour le premier choix. Utiliser &os.current; -CURRENT utilisation Inscrivez-vous à la &a.current; et la &a.cvsall;. Ce n'est pas seulement une bonne idée, c'est indispensable. Si vous n'êtes pas sur la liste &a.current.name;, vous ne verrez pas les commentaires qui sont faits sur l'état courant du système et vous vous retrouverez probablement confrontés à de nombreux problèmes que d'autres ont déjà identifiés et résolus. Encore plus grave, vous manqueriez des bulletins importants potentiellement critiques pour la bonne santé de votre système. La liste &a.cvsall.name; vous permettra de voir les courriers de trace des soumissions de toutes les modifications dès qu'elles sont faites et des informations pertinentes sur les éventuels effets de bord. Pour vous inscrire à ces listes, ou à une autre, rendez vous à &a.mailman.lists.link; et cliquez sur la liste à laquelle vous désirez vous inscrire. Des instructions sur le reste de la procédure sont alors données. Récupérez les sources sur un site miroir &os;. Vous pouvez le faire de deux manières: cvsup cron -CURRENT Synchronisation avec CVSup Utilisez le programme cvsup avec le fichier supfile nommé standard-supfile disponible dans le répertoire /usr/share/examples/cvsup. C'est la méthode recommandée, puisqu'elle permet de récupérer la totalité des sources la première fois et par la suite uniquement ce qui a été modifié. De nombreuses personnes exécutent cvsup depuis cron et maintiennent ainsi automatiquement à jour leurs sources. Vous devez personnaliser l'exemple de supfile précédent, et configurer cvsup pour votre environnement. -CURRENT Synchroniser avec CTM Utilisez CTM. Si vous disposez d'une mauvaise connexion (connexions chères ou seulement un accès au courrier électronique) CTM est une bonne solution. Cependant, c'est une source de problèmes et peut donner lieu à des fichiers endommagés. C'est pourquoi cette méthode est rarement utilisée, ce qui augmente les chances que cela ne fonctionne pas pendant d'assez longue périodes. Nous recommandons d'utiliser CVSup à tous ceux disposant d'un modem 9600 bps ou d'une connexion plus rapide. Si vous récupérez les sources pour compiler un système opérationnel, et pas simplement pour les lire, alors récupérez tout &os.current;, et pas uniquement certaines portions. La raison de cela est que diverses parties des sources dépendent de modifications effectuées ailleurs, et si vous essayez de compiler juste une partie des source, il est quasiment certain que vous aurez des problèmes. -CURRENT compilation Avant de compiler &os.current;, lisez attentivement le Makefile dans /usr/src. Vous devriez au moins la première fois installer un nouveau noyau et recompiler le système, comme étape nécessaire à votre processus de mise à jour. La lecture de la &a.current; et du fichier /usr/src/UPDATING vous tiendra au courant des autres procédures de transition qui sont parfois nécessaires lorsque nous préparons la prochaine version. Participez! Si vous utilisez &os.current;, nous aimerions savoir ce que vous en pensez, tout particulièrement si vous avez des améliorations à nous suggérer ou des corrections de bogues à nous soumettre. Les suggestions accompagnées de code sont accueillies avec enthousiasme! Se synchroniser avec la version -STABLE de &os; Qu'est-ce que &os.stable;? -STABLE &os.stable; est notre branche de développement à partir de laquelle sont extraites les versions majeures. Les modifications sur cette branche se font à une allure différente, et en supposant généralement qu'elles ont été tout d'abord testées sur &os.current;. Cela reste cependant toujours une branche de développement, et cela signifie qu'à certains moments, les sources de &os.stable; pourront être ou pas utilisables pour une quelconque raison. C'est tout simplement une autre branche de mise au point, et non pas une ressource pour l'utilisateur final. Qui a besoin de &os.stable;? Si vous désirez suivre ou contribuer au processus de développement de FreeBSD, tout particulièrement si cela a rapport avec la prochaine version de FreeBSD, alors vous devriez penser à suivre &os.stable;. Bien qu'il soit vrai que les correctifs de sécurité vont également dans la branche &os.stable;, vous n'avez pas besoin de suivre &os.stable; pour cela. Chaque rapport de sécurité concernant FreeBSD explique comment corriger le problème sur les versions affectées Ceci n'est pas tout à fait vrai. Nous ne pouvons continuer à supporter les anciennes versions de FreeBSD éternellement, bien que nous les supportions pendant de nombreuses années. Pour une description complète de la politique de sécurité actuelle pour les anciennes versions de FreeBSD, veuillez consulter http://www.FreeBSD.org/security/. , et suivre intégralement une branche de développement juste pour des raisons de sécurité apportera également de nombreux changements non désirés. Bien que nous tentons de nous assurer que la branche &os.stable; soit compilable et constamment stable, cela ne peut être garanti. De plus, alors que le code est développé sous &os.current; avant de l'inclure dans &os.stable;, le nombre de personnes utilisant &os.stable; est plus nombreux que celui utilisant &os.current;, aussi il est inévitable que des bogues et des problèmes pourront parfois apparaître sous &os.stable; alors qu'ils n'existaient pas sous &os.current;. Pour ces raisons, nous ne recommandons pas de suivre aveuglément &os.stable;, et il est tout particulièrement important que vous ne mettiez pas à jour des serveurs de production sous &os.stable; sans avoir tout d'abord testé le code dans votre environnement de travail. Si vous ne disposez pas des ressources pour faire cela alors nous recommandons que vous utilisiez la version de FreeBSD la plus récente, et que vous utilisiez le mécanisme de mise à jour binaire pour passer d'une version à une autre. Utiliser &os.stable; -STABLE utilisation Inscrivez-vous à à la liste &a.stable.name;. Vous serez tenu au courant des dépendances de compilation qui peuvent apparaître dans la branche &os.stable; ou de tout autre problème demandant une attention particulière. Les développeurs publieront également des annonces sur cette liste lorsqu'ils envisagent une correction ou modification controversée, offrant la possibilité aux utilisateurs de répondre s'ils ont des questions à soulever en rapport avec la modification proposée. La liste &a.cvsall.name; vous permettra de voir les courriers de trace des soumissions de toutes les modifications dès qu'elles sont faites et des informations pertinentes sur les éventuels effets de bord. Pour vous inscrire à ces listes, ou à une autre, rendez vous à &a.mailman.lists.link; et cliquez sur la liste à laquelle vous désirez vous inscrire. Des instructions sur le reste de la procédure sont alors données. - Si vous installez un nouveau système et voulez qu'il - soit aussi stable que possible, vous pouvez simplement - récupérer le dernier instantané en date de - la branche à partir de - et l'installer comme toute autre version. Ou vous pouvez + Si vous installez un nouveau système et vous + voulez qu'il utilise le dernier instantané + publié tous les mois à partir de la + branche &os.stable;, consultez la page sur les instantanés + pour plus d'information. D'autre part, vous pouvez installer la version &os.stable; la plus récente à partir des sites miroirs et suivre les instructions ci-dessous pour mettre à jour votre système avec les sources &os;stable; les plus récentes. Si vous faites tourner une version précédente de &os; et que vous désirez mettre à jour via les sources vous pouvez aisément le faire à partir d'un site miroir &os;. Cela peut être fait de deux manières: cvsup cron -STABLE Synchronisation avec CVSup Utilisez le programme cvsup avec le fichier supfile nommé stable-supfile disponible dans le répertoire /usr/share/examples/cvsup. C'est la méthode recommandée, puisqu'elle permet de récupérer la totalité des sources la première fois et par la suite uniquement ce qui a été modifié. De nombreuses personnes exécutent cvsup depuis cron et maintiennent ainsi automatiquement à jour leurs sources. Vous devez personnaliser l'exemple de supfile précédent, et configurer cvsup pour votre environnement. -STABLE Synchroniser avec CTM Utilisez CTM. Si vous ne disposez pas d'une connexion Internet rapide et peu coûteuse, c'est la méthode que vous devriez penser à utiliser. Avant tout, si vous avez besoin d'un accès rapide à la demande aux sources et que la bande passante n'est pas un problème, utilisez cvsup ou ftp. Sinon, utilisez CTM. -STABLE compilation Avant de compiler &os.stable;, lisez attentivement le Makefile dans /usr/src. Vous devriez au moins la première fois installer un nouveau noyau et recompiler le système, comme étape nécessaire à votre processus de mise à jour. La lecture de la &a.stable; et du fichier /usr/src/UPDATING vous tiendra au courant des autres procédures de transition qui sont parfois nécessaires lorsque nous préparons la prochaine version. Synchroniser vos sources Il existe différentes façons d'utiliser une connexion Internet (ou le courrier électronique) pour garder à jour les sources de n'importe quelle partie, ou de l'ensemble, du projet &os;, selon ce qui vous intéresse. Les principaux services que nous fournissons sont le CVS anonyme, CVSup, et CTM. Alors qu'il est possible de mettre à jour seulement certaines parties de l'arbre des sources, la seule procédure de mise à jour supportée est celle consistant à mettre à jour l'intégralité de l'arborescence et de recompiler les sources des applicatifs de base—“userland” (i.e., tous les programmes qui tournent dans l'espace utilisateur, comme ceux des répertoires /bin et /sbin) et du noyau. Ne mettre à jour qu'une partie des sources, uniquement le noyau, ou seul le “userland” mènera souvent à des problèmes. Ces problèmes pourront aller d'erreurs de compilation à des paniques du noyau ou même des corruptions de données. CVS anonyme CVS anonyme et CVSup utilisent une méthode de mise à jour pilotée par le client—pull. Dans le cas de CVSup, l'utilisateur (ou une procédure cron) appelle le programme cvsup, qui interagit avec un serveur cvsupd distant, pour mettre à jour vos fichiers. Les mises à jour que vous recevez sont les plus récentes, et vous ne les recevez seulement lorsque vous le désirez. Vous pouvez aisément restreindre vos mises à jour aux fichiers ou répertoires particuliers qui vous intéressent. Les mises à jour sont générées à la volée par le serveur, en fonction de ce que vous avez déjà et de ce que vous voulez. CVS anonyme est plus simpliste que CVSup, car ce n'est qu'une extension de CVS qui permet de récupérer des modifications directement d'une archive CVS distante. Pour cela, CVSup est bien plus efficace mais CVS anonyme est plus facile à utiliser. CTM CTM, à l'inverse, ne compare pas interactivement les sources dont vous disposez avec celles qui sont sur l'archive de référence. Au lieu de cela, une procédure qui identifie les modifications intervenues depuis qu'elle a été exécutée pour la dernière fois, est lancée plusieurs fois par jour sur la machine CTM de référence (maître), les modifications détectées sont compressées, affectées d'un numéro de séquence et encodées pour pouvoir être envoyées par courrier électronique (en ASCII imprimable uniquement). Une fois reçus, ces “deltas CTM” peuvent être passés à l'utilitaire &man.ctm.rmail.1; qui décodera, contrôlera et appliquera automatiquement les modifications à l'exemplaire des sources de l'utilisateur. Cette méthode est beaucoup plus efficace que CVSup et consomme beaucoup moins de ressources sur notre serveur, parce que c'est un modèle piloté par le serveur—push plutôt que par l'utilisateur—pull. Il y a, bien sûr, quelques contreparties. Si vous effacez par inadvertance des parties de votre archive, CVSup s'en apercevra et vous reconstruira les parties endommagées. CTM ne le fera pas, et si vous effacez des parties de votre l'arborescence des sources (et que vous n'avez pas fait de sauvegarde) alors vous devrez repartir de zéro (à partir du plus récent “delta de base” CVS) et tout reconstituer avec CTM ou CVS anonyme, effacer les parties endommagées et resynchroniser. Recompiler le système recompiler le système Une fois que vous avez synchronisé votre arborescence des sources avec une version donnée de &os; (&os.stable;, &os.current;, et ainsi de suite) vous pouvez alors utiliser cette arborescence des sources pour recompiler le système. Faites une sauvegarde On n'insistera jamais assez sur l'importance de faire une sauvegarde de votre système avant tout autre chose. Bien qu'il soit facile de “refaire le monde” (recompiler FreeBSD), si vous suivez ces instructions, vous ferez inévitablement des erreurs à un moment ou un autre, ou d'autres feront des erreurs au niveau de l'arborescence des sources qui empêcheraient votre système de redémarrer. Assurez-vous que vous avez bien fait une sauvegarde. Ayez une disquette de maintenance, ou un CD démarrable à portée de la main. Vous ne l'utiliserez probablement pas, mais prudence est mère de sûreté! S'abonner à la bonne liste de diffusion liste de diffusion Les branches &os.stable; et &os.current; sont, par nature, en développement. Les personnes qui participent à &os; sont des humains, et des erreurs se produisent occasionnellement. Ces erreurs sont parfois bénignes, provocant simplement l'affichage d'un nouveau message d'avertissement par votre système. Elles peuvent aussi être catastrophiques, et empêcher votre système de redémarrer ou détruire vos systèmes de fichiers (ou pire). Quand de tels problèmes se produisent, un avertissement “heads up” est posté sur la liste de diffusion appropriée, décrivant la nature du problème et quels systèmes sont concernés. Un message “all clear” est posté quand le problème est résolu. Si vous tentez de suivre &os.stable; ou &os.current; et que vous ne lisez pas la &a.stable; ou la &a.current;, vous allez au devant d'ennuis. N'utilisez pas la commande <command>make world</command> De nombreuses anciennes documentations préconisent d'utiliser la commande make world. Cette commande n'effectue pas un certain nombre d'étapes importantes et ne devrait être utilisée que si vous êtes sûr de ce que vous faites. Dans presque tout les cas make world n'est pas une bonne chose à faire, et la procédure décrite dans la suite de ce document devrait être utilisée à la place. La méthode générique de mise à jour du système Pour mettre à jour votre système, vous devriez consulter /usr/src/UPDATING pour toute opération préliminaire nécessaire en fonction de la version de vos sources et ensuite utiliser la procédure suivante: &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; reboot Dans quelques rares cas, il est nécessaire de lancer un mergemaster -p avant l'étape buildworld. Ces cas sont décrits dans le fichier UPDATING. Généralement, vous pouvez omettre cette opération si vous ne mettez pas à jour d'une version majeure de &os; à une autre. Une fois l'opération installkernel terminée avec succès, vous devrez démarrer en mode mono-utilisateur (en utilisant par exemple la commande boot -s à l'invite du chargeur). Exécutez ensuite: &prompt.root; mergemaster -p &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Lisez les explications supplémentaires La séquence décrite ci-dessus n'est qu'un court résumé pour vous aider à démarrer. Vous devriez cependant lire les sections suivantes afin de comprendre clairement chaque étape, tout particulièrement si vous désirez utiliser une configuration du noyau personnalisée. Lire <filename>/usr/src/UPDATING</filename> Avant tout autre chose, lisez /usr/src/UPDATING (ou le fichier équivalent en fonction de l'endroit où se trouve vos sources). Ce fichier devrait contenir les informations importantes au sujet des problèmes que vous pourriez rencontrer, ou indique l'ordre dans lequel vous devriez exécuter certaines commandes. Si le fichier UPDATING contredit quelque chose d'écrit ici, UPDATING prime sur tout le reste. La lecture du fichier UPDATING n'est pas un substitut à l'abonnement à la liste de diffusion correcte, comme décrit précédemment. Ces deux prérequis sont complémentaires, et non pas exclusifs. Contrôler <filename>/etc/make.conf</filename> make.conf Contrôlez les fichiers /usr/share/examples/etc/make.conf - (appelé /etc/defaults/make.conf sous -  4.X) et + et /etc/make.conf. Le premier contient des paramètres par défaut – la plupart étant placés en commentaires. Pour les utiliser quand vous recompilez votre système à partir des sources, rajoutés-les au fichier /etc/make.conf. Gardez à l'esprit que tout ce que vous ajoutez au fichier /etc/make.conf est utilisé chaque fois que vous invoquez la commande make, il est donc bon de s'assurer que les valeurs par défaut sont appropriées à votre système. Un utilisateur typique voudra probablement copier les lignes CFLAGS et - NOPROFILE se trouvant dans - /usr/share/examples/etc/make.conf - (ou dans /etc/defaults/make.conf sous - &os; 4.X) vers + NO_PROFILE se trouvant dans + /usr/share/examples/etc/make.conf vers /etc/make.conf et les décommenter. Examinez les autres définitions (COPTFLAGS, NOPORTDOCS et ainsi de suite) et décidez si elles vous conviennent. Mettre à jour les fichiers dans <filename>/etc</filename> Le répertoire /etc contient la plupart des informations de configuration de votre système, ainsi que les procédures de démarrage. Certaines de ces procédures changent d'une version à l'autre de FreeBSD. Certains fichiers de configuration sont également utilisés en permanence par le système. En particulier /etc/group. Il est arrivé que la phase d'installation make installworld ait besoin que certains utilisateurs et groupes existent. Il y a de fortes chances qu'ils n'aient pas été définis avant la mise à jour. C'est une source de problèmes. Dans certains cas make buildworld contrôlera si ces utilisateurs ou groupes existent. - Un exemple récent de cela fut l'addition de l'utilisateur + Un exemple de cela fut l'addition de l'utilisateur smmsp. Le processus d'installation échouait quand mtree tentait de créer /var/spool/clientmqueue. - La solution est d'examiner le fichier - /usr/src/etc/group et de comparer sa - liste de groupe avec la votre. S'il y a des groupes dans le - nouveau fichier qui sont absents du votre, alors rajoutez-les. - De même vous devriez renommer tous les groupes dans - /etc/group qui ont le même GID mais un nom - différent que ceux présents dans - /usr/src/etc/group. - - Depuis 4.6-RELEASE vous pouvez exécuter + La solution est d'exécuter &man.mergemaster.8; dans le mode pré-“buildworld” en ajoutant l'option . Cela effectuera la comparaison uniquement des fichiers essentiels pour le succès de la procédure buildworld ou installworld. Si votre vieille version de mergemaster ne supporte pas l'option , utilisez la nouvelle version présente dans l'arborescence des sources quand vous l'exécutez pour la première fois: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Si vous êtes particulièrement paranoïaque, vous pouvez contrôler votre système afin de voir quels fichiers appartiennent au groupe que vous renommez ou effacez: &prompt.root; find / -group GID -print affichera les fichiers appartenant au groupe GID (qui peut être soit un nom de groupe ou un identifiant numérique de groupe). Passer en mode mono-utilisateur mode mono-utilisateur Il vaut mieux recompiler le système en mode mono-utilisateur. En dehors du fait que cela sera légèrement plus rapide, la réinstallation va modifier un grand nombre de fichiers systèmes importants, tous les binaires de base du système, les bibliothèques, les fichiers d'include et ainsi de suite. Les modifier sur un système en fonctionnement (en particulier s'il y a des utilisateurs connectés à ce moment là), c'est aller au devant de problèmes. mode multi-utilisateurs Une autre méthode consiste à compiler le système en mode multi-utilisateurs, et passer dans le mode mono-utilisateur pour l'installation. Si vous désirez utiliser cette méthode, conservez les étapes suivantes pour le moment où la compilation sera terminée. Vous pouvez reporter le passage en mode mono-utilisateur jusqu'à l'exécution de installkernel ou installworld. En tant que super-utilisateur, vous pouvez exécuter la commande: &prompt.root; shutdown now sur un système en fonctionnement, pour passer en mode mono-utilisateur. Ou bien, redémarrer le système, et à - l'invite de démarrage, entrez l'indicateur - . Le système démarrera alors + l'invite de démarrage, sélectionnez l'option + single user. Le système démarrera alors en mode mono-utilisateur. A l'invite de l'interpréteur de commandes, exécutez alors: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Cela effectue une vérification des systèmes de fichiers, remonte / en mode lecture/écriture, et monte tous les autres systèmes de fichiers UFS listés dans le fichier /etc/fstab, puis active la pagination. Si votre horloge CMOS est réglée sur l'heure locale et non pas sur le fuseau GMT (cela est vrai si la sortie de la commande date ne donne pas l'heure et le fuseau correct), vous aurez également peut-être besoin d'exécuter la commande suivante: &prompt.root; adjkerntz -i Cela permettra de s'assurer que vos paramètres de fuseaux horaires sont correctement configurés — sans cela, vous risquez de faire face, plus tard, à des problèmes. Effacer <filename>/usr/obj</filename> Au fur et à mesure que les différentes parties du système sont recompilées, elles sont placées dans des répertoires qui (par défaut) sont sous /usr/obj. Les répertoires sont agencés comme sous /usr/src. Vous pouvez accélérer le processus make buildworld, et également vous éviter d'éventuels problèmes de dépendances en effaçant ce répertoire. Certains fichiers dans /usr/obj peuvent avoir l'indicateur immuable positionné (consultez la page de manuel &man.chflags.1; pour plus d'informations) qui doit être retiré en premier. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * - - Recompiler les sources + + Recompiler le système de base Enregistrer la sortie C'est une bonne idée d'enregistrer la sortie de &man.make.1; dans un fichier. Si quelque chose se passe mal, vous aurez une trace des messages d'erreur. Même si cela ne vous aide pas à diagnostiquer ce qui n'a pas fonctionné, cela peut aider les autres si vous postez votre problème sur une des listes de diffusion de &os;. La méthode la plus aisée pour faire cela est d'utiliser la commande &man.script.1;, avec en paramètre le nom du fichier où enregistrer les résultats. Vous devez faire cela immédiatement juste avant de recompiler le système, et taper exit une fois que c'est terminé. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … Si vous le faites, n'enregistrez pas le résultat dans /tmp. Ce répertoire peut être vidé au prochain redémarrage du système. Un meilleur endroit de sauvegarde est /var/tmp (comme dans l'exemple précédent) ou dans le répertoire utilisateur de root. Compiler le nouveau système Vous devez être dans le répertoire /usr/src: &prompt.root; cd /usr/src (à moins, bien sûr, que votre code source ne soit ailleurs, auquel cas vous devrez aller dans le répertoire correspondant). make Pour recompiler le système, on utilise la commande &man.make.1;. Cette commande lit ses instructions dans le fichier Makefile, qui décrit comment devraient être reconstruits les programmes qui constituent &os;, dans quel ordre, et ainsi de suite. Le format général de la ligne de commande que vous taperez sera la suivante: &prompt.root; make -x -DVARIABLE cible Dans cet exemple, est une option que vous passez à &man.make.1;. Reportez-vous à la page de manuel pour un exemple d'options que vous pouvez passer. transmet un variable au fichier Makefile. Le comportement du Makefile est défini par ces variables. Ce sont les mêmes variables que l'on trouve dans /etc/make.conf, et c'est un autre moyen de les positionner. - &prompt.root; make -DNOPROFILE cible + &prompt.root; make -DNO_PROFILE cible est une autre manière de dire qu'il ne faut pas compiler les bibliothèques profilées et correspond à la ligne: - NOPROFILE= true # Avoid compiling profiled libraries + NO_PROFILE= true # Avoid compiling profiled libraries dans /etc/make.conf. cible indique à &man.make.1; ce que vous voulez faire. Chaque Makefile définit un certain nombre de “cibles”, et votre choix de cible détermine ce qui se passe. Certaines cibles listées dans le fichier Makefile, ne doivent pas être employées. Ce sont des étapes intermédiaires utilisées par le processus de recompilation pour décomposer les étapes importantes de la recompilation du système en sous-étapes. La plupart du temps, vous n'aurez pas besoin de passer de paramètres à &man.make.1;, et votre commande ressemblera à ceci: &prompt.root; make cible - A partir de la version 2.2.5 de &os; (en fait, c'est - apparu en premier sur la branche &os.current;, et ensuite - intégré dans la branche &os.stable; entre les - versions 2.2.2 et 2.2.5) la cible world a - été décomposée en deux parties: - buildworld et - installworld. Avec la version 5.3 - de &os; la cible world est - modifiée et ne fonctionnera pas par défaut et - est en fait dangereuse pour la plupart des - utilisateurs. + Où cible sera une des + nombreuses options de compilation. La première cible + devrait toujours être + buildworld. Comme leurs noms l'indiquent, buildworld reconstruit la nouvelle arborescence dans /usr/obj, et - installworld l'installe sur la + installworld, une autre cible, l'installe sur la machine. - Ceci est très utile pour deux raisons. Tout d'abord + Disposer d'options séparées est très utile pour deux raisons. Tout d'abord cela vous permet de recompiler en toute sûreté en sachant qu'aucun composant du système actuel ne sera affecté. La compilation est “autonome”. En raison de cela vous pouvez exécuter buildworld sur une machine en mode multi-utilisateurs sans redouter d'effets fâcheux. Il est néanmoins recommandé de toujours exécuter l'étape installworld en mode mono-utilisateur. En second lieu, cela vous permet d'utiliser des systèmes montés par NFS pour mettre à jour plusieurs machines de votre réseau. Si vous avez trois machines A, B et C que vous voulez mettre à jour, exécutez make buildworld et make installworld sur A. B et C doivent ensuite monter par NFS /usr/src et /usr/obj depuis A, et vous pouvez alors exécuter make installworld pour installer le système recompilé sur B et C. Bien que la cible world existe toujours, vous êtes fortement encouragé à ne pas l'utiliser. Exécutez: &prompt.root; make buildworld - Il est maintenant possible de passer l'option + Il est possible de passer l'option à &man.make.1; ce qui lui permettra d'exécuter plusieurs processus simultanément. C'est particulièrement utile sur une machine avec plusieurs processeurs. Cependant, comme la compilation est plus gourmande en E/S plutôt qu'en CPU, c'est également utile sur des machines mono-processeur. Typiquement sur une machine mono-processeur, vous exécuteriez: &prompt.root; make -j4 buildworld &man.make.1; pourra exécuter jusqu'à 4 processus simultanément. Des constatations empiriques postées sur les listes de diffusion montrent que c'est en général ce qui apporte le plus de gain en performances. Si vous avez une machine multi-processeurs et que vous avez configuré un noyau SMP, essayez des valeurs entre 6 et 19 et voyez quel bénéfice vous en tirez. - - Soyez conscient que c'est toujours quelque peu - expérimental, et que des modifications de l'arborescence - des sources rendent parfois cette possibilité inutilisable. - Si la recompilation échoue avec ce paramètre, essayez - sans avant de signaler votre problème. Durée compilation du système durée De nombreux facteurs influencent la durée de - compilation, mais actuellement un &pentium; III à - 500 MHz avec 128 MO de RAM met environ - 2 heures pour compiler l'arborescence &os.stable;, + compilation, mais les machines récentes devraient + mettrent seulement de une à deux heures + pour compiler l'arborescence &os.stable;, sans modification ni raccourcis durant le processus. Une arborescence &os.current; nécessitera un peu plus de temps. Compiler et installer un nouveau noyau noyau compilation Pour tirer pleinement parti de votre nouveau système, vous devrez recompiler le noyau. C'est pratiquement indispensable, parce que certaines structures mémoires peuvent avoir changées, et des programmes comme &man.ps.1; et &man.top.1; ne fonctionneront pas tant que le système et le noyau n'utilisent pas les mêmes versions de code source. La manière la plus simple et la plus sûre est de compiler et installer un noyau basé sur le noyau GENERIC. Alors que le noyau GENERIC peut ne pas comporter les pilotes de périphériques nécessaires pour votre système, il devrait contenir tout ce qui est nécessaire pour faire démarrer votre système en mode mono-utilisateur. C'est une bonne façon de tester le fonctionnement de votre nouveau système. Après avoir démarré à partir du noyau GENERIC et vérifié que votre système fonctionne vous pouvez alors compiler un nouveau noyau basé sur votre fichier de configuration normal du noyau. - Sur les versions récentes de &os;, il est important + Sur &os;, il est important de recompilé le système avant de compiler un nouveau noyau. Si vous désirez compiler un noyau personnalisé, et que vous avez déjà un fichier de configuration, utilisez juste KERNCONF=MONNOYAU comme suit: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MONNOYAU &prompt.root; make installkernel KERNCONF=MONNOYAU Notez que si vous avez augmenté la variable kern.securelevel à une valeur supérieure à 1 et que vous avez positionné l'indicateur noschg ou similaire sur votre noyau, il sera intéressant de passer en mode mono-utilisateur pour utiliser installkernel. Sinon vous devriez être en mesure d'exécuter ces commandes à partir du mode multi-utilisateur sans problèmes. Voir la page de manuel de &man.init.8; pour plus de détails à propos de kern.securelevel et la page &man.chflags.1; pour des informations sur les différents indicateurs de fichiers. Redémarrer en mode mono-utilisateur mode mono-utilisateur Vous devriez redémarrer en mode mono-utilisateur pour tester le fonctionnement du nouveau noyau. Pour cela suivez les instructions de . - + Installer les nouveaux binaires système Si vous avez compilé une version de &os; assez récente pour avoir utilisé make buildworld alors vous devriez utiliser maintenant installworld pour installer les nouveaux binaires système. Lancez: &prompt.root; cd /usr/src &prompt.root; make installworld Si vous spécifiez des variables sur la ligne de commande de make buildworld, vous devez utiliser les mêmes variables avec la commande make installworld. Cela ne reste pas forcément vrai pour d'autres options; par exemple, ne doit jamais être utilisée avec installworld. Par exemple, si vous exécutez: - &prompt.root; make -DNOPROFILE buildworld + &prompt.root; make -DNO_PROFILE buildworld vous devrez ensuite installer les résultats avec: - &prompt.root; make -DNOPROFILE installworld + &prompt.root; make -DNO_PROFILE installworld sinon il essayera d'installer les bibliothèques profilées qui n'ont pas été recompilées à l'étape make buildworld. Mettre à jour les fichiers non modifiés par <command>make installworld</command> La recompilation du système ne mettra pas à jour certains répertoires (en particulier, /etc, /var et /usr) avec les fichiers nouveaux ou modifiés. La manière la plus simple de mettre à jour ces fichiers est d'utiliser &man.mergemaster.8;, bien qu'il soit possible de le faire manuellement si vous le désirez. Indépendamment de la manière que vous choisissez, assurez-vous de faire une sauvegarde du répertoire /etc au cas où quelque chose se passerait mal. Tom Rhodes Contribution de <command>mergemaster</command> mergemaster L'utilitaire &man.mergemaster.8; est une procédure Bourne qui vous aidera à déterminer les différences entre vos fichiers de configuration dans le répertoire /etc, et les fichiers de configuration dans l'arborescence des sources /usr/src/etc. C'est la solution recommandée pour maintenir à jour les fichiers de configuration du système avec ceux situés dans l'arborescence des sources. Pour commencer, tapez simplement mergemaster à l'invite, et observez-le travailler. mergemaster commencera à constituer une arborescence temporaire, à partir de /, et la remplira avec divers fichiers de configuration. Ces fichiers sont alors comparés avec ceux actuellement installés sur votre système. A ce point, les fichiers qui diffèrent seront affichés dans le format &man.diff.1;, avec le signe représentant les lignes modifiées ou ajoutées, et le représentant les lignes qui seront soit complètement supprimées, soit remplacées avec une nouvelle ligne. Voir la page de manuel &man.diff.1; pour plus d'informations au sujet de la syntaxe &man.diff.1; et comment sont affichées les différences. &man.mergemaster.8; vous affichera ensuite chaque fichier présentant des différences, et vous aurez à ce moment-là le choix de soit supprimer le nouveau fichier (le fichier temporaire), soit d'installer le fichier temporaire non modifié, soit de fusionner le fichier temporaire et le fichier actuellement installé, soit enfin de revoir les résultats de l'opération &man.diff.1;. Choisir de supprimer le fichier temporaire indiquera à &man.mergemaster.8; que nous désirons conserver notre fichier actuel intacte, et effacera la nouvelle version. Cette option n'est pas recommandée, à moins que vous ne voyez aucune raison de modifier le fichier actuel. Vous pouvez obtenir de l'aide à n'importe quel moment en tapant ? à l'invite de &man.mergemaster.8;. Si l'utilisateur choisit de passer un fichier, il sera présenté à nouveau une fois que tous les autres fichiers auront été traités. Choisir d'installer un fichier temporaire intact remplacera le fichier actuel avec le nouveau. Pour la plupart des fichiers non modifiées, c'est la meilleure option. Choisir de fusionner le fichier, vous affichera un éditeur de texte, et le contenu des deux fichiers. Vous pouvez maintenant les fusionner en les visionnant côte à côte sur l'écran, et en sélectionnant des parties des deux fichiers pour créer un fichier final. Quand les fichiers sont comparés côte à côte, la touche l sélectionnera le contenu de gauche et la touche r sélectionnera celui de droite. Le résultat final sera un fichier constitué des deux parties, qui peut alors être installé. Cette option est habituellement utilisée pour les fichiers où les des paramètres ont été modifiés par l'utilisateur. Choisir de revoir les résultats de l'opération &man.diff.1; vous affichera les différences entre fichiers tout comme la fait &man.mergemaster.8; avant de vous demander un choix. Après que &man.mergemaster.8; en ait terminé avec les fichiers système, il vous proposera de nouvelles opérations. &man.mergemaster.8; vous demandera si vous - désirez reconstruire le fichier des mots de passe et/ou - exécuter &man.MAKEDEV.8; si vous utilisez une version de - FreeBSD antérieure à la 5.0, et terminera avec la - possibilité de supprimer les fichiers temporaires + désirez reconstruire le fichier des mots de passe + et terminera en vous proposant + de supprimer les fichiers temporaires restants. Mise à jour manuelle Si vous désirez faire la mise à jour manuellement, vous ne pouvez cependant pas vous contenter de copier les fichiers de /usr/src/etc dans /etc pour que cela fonctionne. Certains de ces fichiers doivent d'abord être “installés”. En effet le répertoire /usr/src/etc “n'est pas” une copie de ce que devrait contenir votre répertoire /etc. De plus, il a des fichiers qui doivent être dans /etc et qui ne sont pas dans /usr/src/etc. Si vous utilisez &man.mergemaster.8; (comme recommandé), - vous pouvez passer directement à la section suivante. + vous pouvez passer cette section et aller directement à + la section + suivante. La façon la plus simple de procéder est d'installer les fichiers dans un nouveau répertoire, puis de passer en revue les différences. Sauvegardez votre répertoire <filename>/etc</filename> actuel Bien qu'en principe rien ne sera modifié automatiquement dans ce répertoire, prudence est mère de sûreté. Copiez donc votre répertoire /etc dans un endroit sûr. Quelque chose du genre: &prompt.root; cp -Rp /etc /etc.old conviendra; l'option fait une copie récursive, préserve la date, les autorisations des fichiers et ainsi de suite. Vous devez créer un ensemble de répertoires provisoires pour y installer les fichiers du répertoire /etc et autres. /var/tmp/root est un bon choix, il y a un certain nombre de sous-répertoires à créer également: &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Cela va créer l'arborescence nécessaire et y installera les fichiers. Un grand nombre des sous-répertoires créés dans /var/tmp/root sont vides et devront être supprimés. La façon la plus simple de le faire est: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Ceci supprimera tous les répertoires vides (la sortie d'erreur standard est redirigée vers /dev/null pour empêcher les avertissements à propos des répertoires non vides). /var/tmp/root contient maintenant tous les fichiers à installer à l'endroit requis sous /. Vous devez maintenant examiner chacun de ces fichiers pour déterminer en quoi ils diffèrent de vos propres fichiers. Notez que certains des fichiers qui seront installés dans /var/tmp/root commencent par un “.”. Au moment où sont écrites ces lignes, les seuls fichiers concernés sont les fichiers d'initialisation des interpréteurs de commandes dans /var/tmp/root/ et /var/tmp/root/root/, mais il pourrait y en avoir d'autres (cela dépend de quand vous lirez ces lignes). Assurez-vous d'utiliser la commande ls -a pour ne pas les oublier. La manière la plus simple de procéder est d'utiliser la commande &man.diff.1; pour comparer les deux fichiers: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Cela vous indiquera les différences entre votre fichier /etc/shells et le nouveau fichier /var/tmp/root//etc/shells. A partir de là, décidez si vous aller reporter les modifications que vous y avez apportée ou si vous allez simplement recopier le nouveau fichier. Donnez au nouveau répertoire racine (<filename>/var/tmp/root</filename>) un nom qui inclue une date, pour pouvoir facilement comparer les différentes versions Si vous recompilez fréquemment votre système, cela signifie que vous devez également souvent mettre à jour le répertoire /etc, ce qui peut rapidement devenir une corvée. Vous pouvez accélérer le processus en conservant une copie du dernier ensemble de fichiers modifiés que vous avez reportés dans /etc. La procédure suivante présente une façon de faire. Recompilez le système comme à l'accoutumé. Au moment de mettre à jour /etc et les autre répertoires, donnez au répertoire cible un nom basé sur la date du jour. Si vous faisiez cela le 14 février 1998, vous pourriez procéder comme suit: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Reporter les modifications depuis ce répertoire comme décrit plus haut. Ne supprimez pas le répertoire /var/tmp/root-19980214 quand vous aurez terminé. Quand vous récupérez la dernière version des sources et la recompilerez, suivez l'étape 1. Vous aurez alors un nouveau répertoire, qui pourrait s'appeler /var/tmp/root-19980221 (si vous faites une mise à jour chaque semaine). Vous pouvez maintenant voir les modifications intervenues d'une semaine à l'autre en utilisant &man.diff.1; pour afficher les différences entre tous les fichiers deux répertoires: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Généralement, il y aura beaucoup moins de différences qu'entre /var/tmp/root-19980221/etc et /etc. Comme il y a beaucoup moins de différences, il est beaucoup plus facile de les reporter dans le répertoire /etc. Vous pouvez maintenant supprimer le plus ancien des deux répertoires /var/tmp/root-*: &prompt.root; rm -rf /var/tmp/root-19980214 Répétez l'opération chaque fois que vous devez reporter des modifications dans /etc. Vous pouvez utiliser &man.date.1; pour automatiser la génération des noms de répertoires: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` - - Mettre à jour <filename>/dev</filename> - - - DEVFS - DEVFS - Si vous utilisez FreeBSD 5.0 ou suivante - vous pouvez sans risque passer cette section. Ces versions - utilisent &man.devfs.5; pour allouer les fichiers spéciaux - de périphériques de façon transparente pour - l'utilisateur. - - - Dans la plupart des cas, l'outil &man.mergemaster.8; - déterminera quand il sera nécessaire de mettre à - jour les fichiers spéciaux de périphériques, - et proposera de le faire automatiquement. Les instructions - suivantes expliquent comment mettre à jour les fichiers - spéciaux de périphériques manuellement. - - Pour des raisons de sécurité, cette mise - à jour se fait en plusieurs étapes. - - - - Copiez /var/tmp/root/dev/MAKEDEV dans - /dev: - - &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev - - MAKEDEV - - - Si vous avez utilisé &man.mergemaster.8; pour - mettre à jour /etc, alors votre - procédure MAKEDEV a dû - déjà être mise à jour, - bien que cela ne peut pas faire de mal de la contrôler - (avec &man.diff.1;) et la copier manuellement si - nécessaire. - - - - Maintenant, prenez une photographie de l'état de - votre répertoire /dev. Cette - photographie doit contenir les droits, propriétaires et - les codes majeur et mineur de fichier spécial de - périphérique, mais pas leur date de - dernière mise à jour. La façon la plus - aisée de procéder est d'utiliser la commande - &man.awk.1; pour éliminer les informations - inutiles: - - &prompt.root; cd /dev -&prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out - - - - Recréez tous les fichiers spéciaux de - périphériques: - - &prompt.root; sh MAKEDEV all - - - - Reprenez une autre photographie du répertoire, cette - fois-ci dans /var/tmp/dev2.out. - Comparez maintenant ces deux fichiers pour voir si - certains fichiers spéciaux de - périphériques manquant n'ont pas - été créés. Cela ne devrait pas - être le cas, mais prudence est mère de - sûreté. - - &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out - - Il manquera peut-être des descripteurs de partitions, - il vous faudra alors exécuter des commandes du - type: - - &prompt.root; sh MAKEDEV sd0s1 - - pour les recréer. Les détails dépendent - de votre installation. - - - - - - Mettre à jour <filename>/stand</filename> - - - Cette étape n'est décrite que pour - être exhaustif. Elle peut être omise sans risque. - Si vous utilisez &os; 5.2 ou suivante, le - répertoire /rescue est automatiquement mis - à jour avec des binaires compilés en statique - lors de l'opération make - installworld, rendant par conséquent - obsolète la mise à jour du répertoire - /stand/ (qui n'existe - pas sous &os; 6.0 et versions suivantes). - - - Pour être exhaustif, vous pouvez également mettre - à jour les fichiers du répertoire - /stand. Ces fichiers sont des liens - physiques vers le binaire - /stand/sysinstall. Cet exécutable - doit être compilé en statique, pour qu'il soit - utilisable sans qu'aucun autre système de fichiers - (et en particulier /usr) ne soit - monté. - - &prompt.root; cd /usr/src/release/sysinstall -&prompt.root; make all install - - - + Redémarrer Vous en avez terminé. Après avoir vérifié que tout semble être en place, vous pouvez alors redémarrez votre système. Un simple &man.shutdown.8; devrait suffire: &prompt.root; shutdown -r now C'est fini Vous devriez maintenant avoir mis à jour avec succès votre système &os;. Félicitations. Si les choses se sont légèrement mal passées, il est facile de recompiler un élément particulier du système. Par exemple, si vous avez accidentellement effacé /etc/magic lors de la mise à jour de /etc, la commande &man.file.1; ne fonctionnerait plus. Dans ce cas, la solution serait d'exécuter: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Questions Dois-je refaire le monde à chaque évolution? Il n'y a pas de réponse toute faite à cette question, tout dépend de la nature des évolutions. Par exemple, si vous venez juste d'exécuter CVSup, et que les fichiers suivants on été mis à jour: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk cela ne vaut probablement pas la peine de recompiler tout le système. Vous pouvez tout simplement aller dans les sous-répertoires appropriés, exécuter make all install, et c'est à peu près tout. Mais s'il y a des évolutions importantes, par exemple sur src/lib/libc/stdlib alors vous devrez soit refaire le monde, ou recompiler au moins toutes les parties du système qui sont liées statiquement (de même que tout ce vous pourriez avoir ajouté qui y serait lié statiquement). C'est à vous de voir. Vous préférerez peut-être recompiler votre système tous les quinze jours, et laisser les modifications s'empiler pendant quinze jours. Ou bien vous préférerez ne recompiler que ce qui a changé et vous faire confiance pour tout ce qui en dépend. Et, bien sûr, cela dépend de la fréquence avec laquelle vous voulez faire vos mises à jour, et de si vous suivez la branche &os.stable; ou &os.current;. Ma compilation échoue avec de nombreuses erreurs “signal 11” (ou tout autre numéro de signal). Que s'est-il passé? signal 11 Cela indique généralement un problème matériel. (Re)compiler le système est un bon moyen de mettre votre matériel sous pression, et mettra souvent en évidence des défaillances de la mémoire vive. Elles se manifestent normalement d'elles-mêmes, la compilation échouant lors de la réception de mystérieux signaux. Un bon indicateur de cet état de fait, est que vous pouvez relancer la compilation et qu'elle échouera en un endroit différent. Dans ce cas, vous ne pouvez guère faire autre chose que d'intervertir les différents composants de votre matériel pour déterminer lequel est en cause. Puis-je effacer /usr/obj après avoir fini? Une réponse courte est oui. /usr/obj contient tous les fichiers objets générés à la compilation. Normalement, une des premières étapes de make buildworld est de supprimer ce répertoire et de repartir à zéro. Dans ce cas, conserver le répertoire /usr/obj après avoir terminé ne sert pas à grand chose, alors que vous économiseriez pas mal d'espace disque (actuellement environ 340 MO). Cependant, si vous savez ce que vous faites, vous pouvez faire en sorte que make buildworld saute cette étape. Cela rendra les compilations ultérieures plus rapides, puisque la plupart des sources n'auront pas besoin d'être recompilées. Le revers de la médaille est que des problèmes subtils de dépendance peuvent se manifester, provoquant l'échec de votre compilation de manière étrange. Cela génère fréquemment du bruit sur les listes de diffusion de &os;, quand quelqu'un se plaint que sa mise à jour a échoué, sans réaliser que c'est parce qu'il a tenté de brûler les étapes. Une recompilation interrompue peut-elle être reprise? Tout dépend de jusqu'où vous êtes aller avant de rencontrer un problème. En général (et ceci n'est pas une règle absolue) make buildworld crée de nouveaux exemplaires des outils indispensables (comme &man.gcc.1; et &man.make.1;) et des bibliothèques système. Ces outils et bibliothèques sont ensuite installés. Puis ils sont utilisés pour se reconstruire eux-mêmes, et installés de nouveau. L'intégralité du système (y compris maintenant les programmes utilisateurs classiques, comme &man.ls.1; ou &man.grep.1;) est alors recompilé avec les nouveaux fichiers système. Si vous êtes à cette dernière étape, et que vous le savez (parce que vous avez consulté les résultats que vous avez enregistrés) alors vous pouvez (sans trop de risque) faire: … fix the problem … &prompt.root; cd /usr/src -&prompt.root; make -DNOCLEAN all +&prompt.root; make -DNO_CLEAN all Cela ne détruira pas les résultats du travail qu'à déjà effectué make buildworld. Si vous voyez le message: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- dans les comptes-rendus de make buildworld alors cette façon de procéder est probablement bonne. Si vous ne voyez pas ce message, ou que vous doutez de vous, alors prudence est mère de sûreté, et il vaut mieux tout reprendre depuis le début. Comment puis-je accélérer la compilation du système? Passez en mode mono-utilisateur. Mettez les répertoires /usr/src et /usr/obj sur des systèmes de fichiers et des disques différents. Si possible, installez ces disques sur des contrôleurs différents. Encore mieux, mettez ces systèmes de fichiers sur plusieurs disques utilisant le système &man.ccd.4; (pilote de disques concaténés). Ne compilez pas les bibliothèques profilées - (mettez “NOPROFILE=true” dans le fichier + (mettez “NO_PROFILE=true” dans le fichier /etc/make.conf). Vous n'en avez certainement pas besoin. Egalement dans /etc/make.conf, positionnez CFLAGS à quelque chose comme . L'optimisation est bien plus lente, et la différence d'optimisation entre et est en général négligeable. demande au compilateur d'utiliser des tuyaux à la place de fichiers temporaires, ce qui économise des accès disque (mais utilise plus de mémoire). Passez l'option à &man.make.1; pour permettre l'exécution de plusieurs processus en parallèle. Cela améliore généralement les choses, que vous ayez une machine mono- ou multi-processeurs. Le système de fichiers qui contient /usr/src peut être monté (ou remonté) avec l'option . Cela empêche l'enregistrement des dates d'accès aux fichiers par le système de fichiers. Vous n'avez de toute façon probablement pas besoin de cette information. &prompt.root; mount -u -o noatime /usr/src Cet exemple suppose que /usr/src constitue à lui seul un système de fichiers. Si ce n'est pas le cas (s'il fait partie de /usr par exemple) vous devez alors indiquer le point de montage de ce système de fichiers, et non /usr/src. Le système de fichiers où se trouve /usr/obj peut être monté (ou remonté) avec l'option . Les écritures sur le disque se feront alors de façon asynchrone. En d'autres termes, le programme reprend immédiatement la main, et l'écriture des données sur le disque se fait quelques secondes plus tard. Cela permet le groupement des écritures sur le disque, et le gain en performance peut être spectaculaire. Gardez à l'esprit que cette option rend votre système de fichiers plus fragile. Avec cette option, les risques ne sont accrus qu'en cas de coupure d'alimentation, le système de fichiers soit irrécupérable quand la machine redémarrera. S'il n'y a que /usr/obj sur ce système de fichiers, ce n'est alors pas un problème. Si vous avez d'autres données importantes sur ce système de fichiers, assurez-vous que vos sauvegardes soient à jour avant d'activer cette option. &prompt.root; mount -u -o async /usr/obj Comme auparavant, si /usr/obj ne constitue pas un système de fichiers en soit, remplacez-le dans l'exemple par le nom du point de montage approprié. Que faire si quelque chose se passe mal? Soyez absolument sûr que votre environnement ne contient pas des restes de compilation précédentes. Cela est plutôt simple: &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir En effet, make cleandir doit vraiment être exécutée deux fois. Ensuite relancez l'ensemble du processus, en commençant avec make buildworld. Si vous avez toujours des problèmes, envoyez l'erreur et le résultat de la commande uname -a à la &a.questions;. Tenez-vous prêt à répondre à d'autres concernant votre configuration! Mike Meyer Contribution de Suivre les mises à jour pour plusieurs machines NFS installation de multiples machines Si vous avez plusieurs machines dont vous voulez maintenir à jour l'arborescence des sources, alors faire télécharger et recompiler à chacune d'entre elles les sources semble un gaspillage de ressources: espace disque, bande passante réseau, et cycles CPU. C'est en effet bien le cas, et la solution est d'avoir une machine qui fait la majeure partie du travail, pendant que le reste des machines montent ce travail par NFS. Cette section décrit une façon de le faire. Préliminaires Premièrement, identifiez un ensemble de machines qui va utiliser le même ensemble de binaires, que nous appellerons un ensemble de compilation. Chaque machine peut avoir un noyau personnalisé, mais elles exécuteront les mêmes binaires utilisateur du système de base. Dans cet ensemble de machine, choisissez une machine qui sera la machine de compilation. Cela sera la machine sur laquelle le monde et le noyau seront compilés. Idéalement, cela devrait être une machine rapide avec un CPU suffisamment disponible pour exécuter la commande make buildworld et make buildkernel. Vous voudrez également utiliser une machine de test, qui testera les mises à jour logicielles avant d'être utilisées en production. Cela doit être une machine que vous pouvez vous permettre d'avoir hors service pour une longue période. Cela peut être la machine de compilation, mais cela n'est pas obligatoire. Toutes les machines de cet ensemble de compilation doivent monter /usr/obj et /usr/src à partir de la même machine, et du même point de montage. Idéalement, ces derniers sont sur deux disques différents sur la machine de compilation, mais peuvent également être montés par NFS sur cette machine. Si vous avez plusieurs ensembles de compilation, /usr/src devrait être sur une machine de compilation, et monté par NFS sur les autres. Finalement assurez-vous que /etc/make.conf sur toutes les machines de l'ensemble de compilation est en accord avec la machine de compilation. Cela signifie que la machine de compilation doit compiler toutes les parties du système de base que toute machine de l'ensemble de compilation va installer. De plus, chaque machine de compilation devra avoir son nom de noyau défini avec KERNCONF dans /etc/make.conf, et la machine de compilation devrait tous les lister dans KERNCONF, en listant son noyau en premier. La machine de compilation doit avoir les fichiers de configuration des noyaux de chaque machine dans /usr/src/sys/arch/conf si elle va compiler leur noyau. Le système de base Maintenant que tout est configuré, vous êtes fin prêt pour tout compiler. Compilez le noyau et le monde sur la machine de compilation comme décrit dans la , mais n'installez rien. La compilation une fois terminée, allez sur la machine de test, et installez le noyau que vous venez juste de compiler. Si la machine monte /usr/src et /usr/obj via NFS, quand vous redémarrez en mode mono-utilisateur vous devrez activer le réseau et monter ces répertoires. La méthode la plus simple est de démarrer en mode multi-utilisateur, puis exécutez shutdown now pour passer en mode mono-utilisateur. Une fois à ce niveau, vous pouvez installer le nouveau noyau et monde puis exécuter mergemaster comme vous le feriez habituellement. Une fois cela effectué, redémarrez pour retourner en mode multi-utilisateur pour cette machine. Après que vous soyez certain que tout fonctionne correctement sur la machine de test, utilisez la même procédure pour installer le nouvel ensemble logiciel sur chacune des autres machines de l'ensemble de compilation. Les logiciels portés La même idée peut être utilisée pour le catalogue des logiciels portés. La première étape critique est de monter /usr/ports depuis la même machine vers toutes les machines de l'ensemble de compilation. Vous pouvez alors configurer correctement /etc/make.conf pour partager les archives. Vous devrez faire pointer DISTDIR sur un répertoire de partage commun dans lequel peut écrire n'importe quel utilisateur utilisé pour correspondance de l'utilisateur root par vos montages NFS. Chaque machine devrait faire pointer WRKDIRPREFIX sur une répertoire de compilation local. Et enfin, si vous projetez de compiler et distribuer des logiciels précompilés, vous devriez fixer PACKAGES sur un répertoire similaire à DISTDIR. diff --git a/fr_FR.ISO8859-1/books/handbook/eresources/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/eresources/chapter.sgml index d0e91ab44f..397bf1ce28 100644 --- a/fr_FR.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,1950 +1,2025 @@ Ressources sur Internet &trans.a.fonvieille; L'évolution rapide de FreeBSD rend peu pratique le suivi des développements via des supports imprimés. Les supports électroniques sont le meilleur, sinon la plupart du temps le seul, moyen de se tenir au courant des dernières avancées. Comme FreeBSD est un effort basé sur le volontariat, la communauté des utilisateurs sert généralement de “service de support technique”, le courrier électronique et les forums de discussion étant le meilleur moyen de contacter cette communauté. Les points de contact les plus importants avec la communauté des utilisateurs de FreeBSD sont listés ci-dessous. Si vous connaissez d'autres ressources qui n'y figurent pas, communiquez-les s'il vous plaît à la &a.doc; de façon à ce qu'elles soient aussi mentionnées. Listes de diffusion Bien qu'un grand de nombre de développeurs de FreeBSD lisent les forums de discussion, nous ne pouvons vous garantir de réponse en temps et en heure à vos questions (ni même de réponse tout court) si vous ne les postez que sur un des forums comp.unix.bsd.freebsd.*. En adressant vos questions sur la liste de diffusion appropriée vous nous contacterez en même temps qu'un auditoire FreeBSD concentré, ce qui vous garantit invariablement une meilleure (ou tout au moins une plus rapide) réponse. Les chartes d'utilisation pour les différentes listes sont données à la fin de ce document. Lisez-les s'il vous plaît avant de vous inscrire ou d'envoyer du courrier à une liste. La plupart des inscrits à nos listes reçoivent maintenant des centaines de messages en rapport à FreeBSD chaque jour, et en définissant des chartes et des règles d'utilisation, nous essayons de garder assez élevé le rapport signal/bruit sur les listes. Ne pas le faire verrait l'échec des listes de diffusion comme moyen efficace de communication pour le projet. En cas de doute sur la liste sur laquelle poser une question, lisez Comment obtenir les meilleurs résultats sur la liste de diffusion FreeBSD-questions. Avant de poster sur une liste de diffusion, veuillez apprendre à utiliser au mieux les listes de diffusion, comme par exemple éviter de relancer des discussions qui reviennent régulièrement, en lisant le document (FAQ) sur les questions fréquemment posées au sujet des listes de diffusion. Des archives de toutes les listes de diffusion sont conservées et on peut effectuer des recherches sur le serveur World Wide Web de FreeBSD. Les archives interrogeables par mots-clés offrent un excellent moyen de trouver des réponses aux questions fréquemment posées et devraient être consultées avant de poster une question. Résumé des listes de diffusion Listes générales: les listes suivantes sont des listes générales auxquelles chacun est libre (et encouragé) de s'inscrire: Liste Objet &a.cvsall.name; Toutes les modifications de l'arborescence des sources &a.advocacy.name; Propagande FreeBSD &a.announce.name; Evénements et étapes importantes du projet &a.arch.name; Discussions sur l'architecture et l'implémentation de FreeBSD &a.bugbusters.name; Discussions concernant la maintenance de la base des données des rapports de bogue de FreeBSD et des outils rattachés &a.bugs.name; Rapports de bogue &a.chat.name; Sujets non-techniques en rapport avec la communauté FreeBSD &a.current.name; Discussions concernant l'utilisation de &os.current; &a.isp.name; Pour les fournisseurs d'accès utilisant FreeBSD &a.jobs.name; Emplois et interventions de consultants en rapport avec FreeBSD &a.policy.name; Décisions de la politique de l'équipe de base de FreeBSD. Volume faible, et accès en lecture uniquement &a.questions.name; Questions des utilisateurs et support technique &a.security-notifications.name; Avis de sécurité &a.stable.name; Discussions concernant l'utilisation de &os.stable; &a.test.name; Où envoyer vos messages de test au lieu que dans une des listes réelles Listes techniques: les listes suivantes sont destinées aux discussions techniques. Vous devriez lire la charte d'utilisation pour chaque liste attentivement avant de s'y inscrire ou d'y envoyer du courrier parce qu'il y a des règles fermes quant à leur utilisation et leur contenu. Liste Objet &a.acpi.name; Développement de l'ACPI et de la gestion d'energie &a.afs.name; Portage d'AFS sous FreeBSD &a.aic7xxx.name; Développement de pilotes pour les contrôleurs AIC 7xxx d'&adaptec; &a.alpha.name; Portage de FreeBSD sur les systèmes Alpha &a.amd64.name; Portage de &os; sur les systèmes AMD64 &a.apache.name; Discussion sur les logiciels portés relatifs à Apache &a.arm.name; Portage de FreeBSD sur les processeurs &arm; &a.atm.name; Utilisation de réseaux ATM avec FreeBSD &a.audit.name; Projet d'audit du code source &a.binup.name; Conception et développement du système de mise à jour binaire &a.bluetooth.name; Utilisation de la technologie &bluetooth; sous &os; &a.cluster.name; Utilisation de FreeBSD dans un environnement en grappe &a.cvsweb.name; Maintenance du système CVSweb &a.database.name; Discussions à propos de l'utilisation de bases de données et de leur développement sous FreeBSD &a.doc.name; Création de documents en rapport avec FreeBSD &a.drivers.name; Ecrire des pilotes de périphériques pour &os; &a.eclipse.name; Pour les utilisateurs &os; de l'EDI Eclipse, les outils, les applications clientes et les logiciels portés. + + &a.embedded.name; + Utilisation de &os; dans les applications + embarquées + + + + &a.eol.name; + Entre-aide sur les logiciels relatifs à + &os; et qui ne sont plus supportés par le projet + &os;. + + &a.emulation.name; Emulation d'autres systèmes comme Linux/&ms-dos;/&windows; &a.firewire.name; Discussion technique au sujet du &firewire; (iLink, IEEE 1394) sous FreeBSD &a.fs.name; Systèmes de fichiers &a.geom.name; Discussions spécifiques à GEOM et à ses implémentations &a.gnome.name; Portage de GNOME et des applications GNOME &a.hackers.name; Discussions techniques générales &a.hardware.name; Discussion générale à propos du matériel fonctionnant sous FreeBSD &a.i18n.name; Internationalisation de FreeBSD &a.ia32.name; &os; sur la plate-forme IA-32 (&intel; x86) &a.ia64.name; Portage de FreeBSD sur les futurs système &intel; IA64 &a.ipfw.name; Discussion technique concernant le développement du nouveau code du coupe-feu &a.isdn.name; Développeurs ISDN &a.java.name; Développeurs &java; et personnes portant et les JDKs sous FreeBSD &a.kde.name; Portage de KDE et des applications pour KDE &a.lfs.name; Portage de LFS sous FreeBSD &a.libh.name; Le système d'installation et de logiciel pré-compilé de seconde génération &a.mips.name; Portage de &os; sur &mips; &a.mobile.name; Discussions à propos des ordinateurs portables &a.mozilla.name; Portage de Mozilla sous FreeBSD &a.multimedia.name; Applications multimédia &a.newbus.name; Discussions techniques au sujet de l'architecture de bus &a.net.name; Discussion au sujet des réseaux et du code source TCP/IP &a.openoffice.name; Portage d'OpenOffice.org et de &staroffice; sous FreeBSD &a.performance.name; Questions relatives à l'optimisation pour les installations à charge/performances élevées. &a.perl.name; Maintenance des logiciels portés relatifs à perl &a.pf.name; Discussions et questions concernant le système de coupe-feu packet filter &a.platforms.name; Portages sur des plateformes à architecture non &intel; &a.ports.name; Discussion sur le catalogue des logiciels portés &a.ports-bugs.name; Discussion sur les bogues/PRs des logiciels portés &a.ppc.name; Portage de FreeBSD pour le &powerpc; &a.proliant.name; Discussion technique sur l'utilisation de &os; sur les serveurs HP ProLiant &a.python.name; Problèmes concernant l'utilisation de Python sous &os; &a.qa.name; Discussion sur la qualité de FreeBSD, généralement entre deux versions &a.rc.name; Discussion relative au système rc.d et à son développement &a.realtime.name; Développement des extensions temps réel de FreeBSD &a.scsi.name; Sous-système SCSI &a.security.name; Questions concernant la sécurité &a.small.name; Utilisation de FreeBSD dans les applications - embarquées + embarquées (obsolète, utilisez + &a.embedded.name; à la place) &a.smp.name; Discussions sur la conception du traitement symétrique multiprocesseurs &a.sparc.name; Portage de FreeBSD sur les systèmes &sparc; &a.standards.name; Conformité de FreeBSD aux normes C99 et &posix; + + &a.sun4v.name; + Portage de &os; sur les systèmes + basés sur &ultrasparc; T1 + + &a.threads.name; Threading sous &os; &a.testing.name; Tests de stabilité et de performance de &os; &a.tokenring.name; Support du Token Ring sous FreeBSD &a.x11.name; Support et maintenance de X11 sous &os; &a.usb.name; Discussion sur le support USB sous &os; &a.vuxml.name; Discussion sur l'infrastructure VuXML &a.x11.name; Maintenance and support of X11 on FreeBSD Liste à accès restreint: les listes suivantes sont pour les assistances plus spécialisées (et exigeantes) et ne sont probablement pas d'intérêt général. C'est aussi une bonne idée d'être d'abord actif sur les listes techniques avant de vous inscrire à une de ces listes limités de sorte que vous compreniez l'étiquette impliquée dans ces communications. Liste Objet &a.hubs.name; Pour ceux qui gèrent des sites miroir (questions d'infrastructure) &a.usergroups.name; Coordination des groupes d'utilisateurs &a.vendors.name; Coordination des fournisseurs des pré-versions &a.www.name; Webmestres de www.FreeBSD.org Résumé de liste: Toutes les listes ci-dessus sont également disponibles sous forme de résumé. Une fois inscrit à une liste, vous pouvez modifier vos options de résumé dans les options de votre compte. Listes CVS lists: Les listes suivantes sont destinées aux personnes intéressées par la lecture des journaux des modifications effectuées sur les différentes partie de l'arborescence des sources. Ce sont des listes à lecture seule et on ne devrait pas y envoyer de messages. Liste Partie de l'arborescence des sources Description de la partie (des sources concernées) &a.cvsall.name; /usr/(CVSROOT|doc|ports|projects|src) Toute modification de l'arborescence (agrégation de l'ensemble des listes CVS) &a.cvs-doc.name; /usr/(doc|www) Toutes les modifications effectuées sur les arborescences doc et www &a.cvs-ports.name; /usr/ports Toutes les modifications effectuées sur l'arborescence des logiciels portés &a.cvs-projects.name; /usr/projects Toutes les modifications effectuées sur l'arborescence des projets &a.cvs-src.name; /usr/src Toutes les modifications effectuées sur l'arborescence des sources Comment s'inscrire Pour s'inscrire à une liste, cliquez sur le nom d'une liste ci-dessus où sur &a.mailman.lists.link; et cliquez ensuite sur la liste qui vous intéresse. La page de la liste devrait contenir toutes les instructions nécessaires à l'inscription. Pour poster réellement sur une liste, envoyez simplement un courrier électronique à l'adresse nom-de-la-liste@FreeBSD.org. Ce courrier sera alors redistribué à l'ensemble des membres de la liste de par le monde. Pour vous désabonner d'une liste, cliquez sur l'URL se trouvant à la fin de chaque message reçu de la liste. Il est également possible d'envoyer un message à nom-de-la-liste-unsubscribe@FreeBSD.org pour vous désabonner. Encore une fois, nous voudrions vous demander de garder aux discussions sur les listes techniques leur caractère technique. Si vous n'êtes intéressés uniquement que par les annonces importantes alors nous vous suggérons de vous inscrire à la liste &a.announce;, dont le trafic n'est qu'occasionnel. Chartes d'utilisation des listes Il y a pour toutes les listes de diffusion FreeBSD des règles de base auxquelles tous leurs utilisateurs doivent se conformer. En cas de non respect de ces règles, et après deux (2) avertissements écrits de la part du “Postmaster” de FreeBSD postmaster@FreeBSD.org, au troisième manquement, le contrevenant sera désabonné de toutes les listes de diffusion de FreeBSD, et ses messages ultérieurs filtrés. Nous regrettons de devoir prendre de telles mesures, mais l'Internet d'aujourd'hui est un milieu relativement hostile, et beaucoup ne se rendent pas compte de la fragilité de certains de ses mécanismes. Règles générales: Le sujet de tout message doit correspondre au sujet traité par la liste à laquelle il est adressé, e.g., si c'est une liste concernant des problèmes techniques alors le contenu de votre message doit être technique. Le bavardage continu et les polémiques ne font que dégrader la qualité de la liste de diffusion pour tous les utilisateurs et ne seront pas tolérés. Pour des discussions libres sans sujet particulier, la &a.chat; est disponible et devrait être utilisée dans ce cas. Aucun message ne doit être adressé à plus de 2 listes de diffusion, et à 2 listes uniquement dans le cas où il y a une nécessité évidente de poster sur les deux listes. Pour la plupart des listes, il y a déjà beaucoup de souscripteurs communs, et mis à part les cas les plus ésotériques (par exemple “-stable & -scsi”), il n'y a pas vraiment de raison de poster sur plus d'une liste à la fois. Si vous recevez un message où apparaissent sur la ligne Cc plusieurs listes de diffusion, vous devez purger cette ligne Cc avant d'y répondre. Vous êtes toujours responsable de vos expéditions croisées, peu importe qui en a été à l'origine. Les attaques personnelles et les insultes (dans le cadre d'une discussion) ne sont pas autorisés, et cela concerne tout autant les utilisateurs que les développeurs. Les manquements grossiers à la “nétiquette”, citer ou reposter des courriers privés quand l'accord n'en a pas été donné et ne le sera pas, par exemple, sont désapprouvés, mais pas particulièrement réprimés. Cependant de tels contenus entrent rarement dans le cadre des règles d'utilisation d'une liste, et entraîneront donc probablement un avertissement (ou une exclusion) pour cette seule raison. La publicité pour des produits ou services sans rapport avec FreeBSD est rigoureusement interdite et entraînera l'exclusion immédiate s'il s'avère que le contrevenant adresse ses publicités par “courrier électronique non sollicité” - spam. Chartes liste par liste: &a.acpi.name; Développement de l'ACPI et de la gestion de l'énergie &a.afs.name; Système de fichiers Andrew - Andrew File System C'est une liste de discussion sur le portage et l'utilisation d'AFS de CMU/Transarc. &a.announce.name; Evénements importants / étapes importantes pour le projet C'est une liste pour les gens intéressés uniquement par les annonces occasionnelles d'évènements FreeBSD importants. Cela inclut les annonces d'instantanés et autres versions. Cela comprend également les annonces de nouvelles fonctionnalités de FreeBSD. Il peut y avoir aussi des appels à volontaires, etc... C'est une liste de faible volume et rigoureusement modérée. &a.arch.name; Discussions concernant l'architecture et l'implémentation C'est une liste pour discuter de l'architecture de FreeBSD. Les messages y seront habituellement de nature technique. Des exemples de sujets qui cadrent avec cette liste sont: Comment revoir le système de compilation pour que plusieurs compilations personnalisées puissent être effectuées en même temps. Que faut-il corriger dans VFS pour que les couches Heidemann fonctionnent. Comment modifier l'interface des pilotes de périphériques pour que la même interface fonctionne proprement sur différents bus et architectures. Comment écrire un pilote réseau. &a.audit.name; Projet d'audit du code source C'est la liste de discussion pour le projet d'audit du code source de FreeBSD. Bien que n'étant à l'origine destinée qu'aux modifications relatives à la sécurité, sa charte a été élargie pour l'examen de toute modification de code. Cette liste est très chargée de correctif, et n'est probablement pas intéressant pour l'utilisateur moyen de FreeBSD. Les discussions sur la sécurité non relatives à une modification particulière du code ont lieu sur freebsd-security. Réciproquement, tous les développeurs sont encouragés à envoyer leur correctifs sur la liste pour examen, tout particulièrement s'ils touchent une partie du système où un bogue peut compromettre l'intégrité du système. &a.binup.name; Projet de mise à jour binaire de FreeBSD Cette liste existe pour discuter du système de mise à jour binaire, ou binup. Problèmes de conception, détails d'implémentation, correctifs, rapports de bogue, rapport d'état, demandes de fonctionnalités, traces des modifications du code, et tout ce qui peut avoir rapport avec binup sont à leur place ici. &a.bluetooth.name; &bluetooth; sous &os; C'est un forum où se rassemble les utilisateurs de la technologie &bluetooth; sous &os;. Problèmes de conception, détails de l'implémentation, rapports de bogues, état du support, demande de fonctionnalités, et tous les sujets en rapport avec &bluetooth; sont les bienvenues. &a.bugbusters.name; Coordination de la gestion des rapports de bogue L'objet de cette liste est de servir de forum de coordination et de discussion entre le “Boguemestre”, ses chasseurs de bogues et toute autre partie intéressée dans la base de données des PRs. Cette liste n'est pas destinée aux discussions sur des bogues spécifiques, correctifs ou PRs. &a.bugs.name; Rapports de bogue C'est la liste pour rapporter les bogues de FreeBSD. Chaque fois que c'est possible, les bogues devraient être soumis en utilisant la commande &man.send-pr.1; ou son interface WEB. &a.chat.name; Sujets non-techniques en rapport avec la communauté FreeBSD Cette liste reçoit le résidu des discussions sur les autres listes: informations sociologiques, et non techniques. Cela va de savoir si Jordan ressemble ou non à un furet de bande dessinée, s'il faut tapez en majuscules, qui boit trop de café, quelle est la meilleure bière, qui brasse de la bière dans sa cave, et ainsi de suite. Les annonces occasionnelles d'événements importants (les prochaines fêtes, mariages, naissances, nouveaux emplois, etc...) peuvent être adressées aux listes techniques, mais doivent ensuite être redirigées sur cette liste. &a.core.name; Equipe de base de FreeBSD C'est une liste interne à l'usage des membres de l'équipe de base. Des messages peuvent y être adressés lorsqu'un sujet en rapport avec FreeBSD demande arbitrage ou examen à haut niveau. &a.current.name; Discussions concernant l'utilisation de &os.current; C'est la liste de diffusion pour les utilisateurs de &os.current;. Elle inclut avertissements au sujet de nouvelles fonctionnalités de -CURRENT qui affecteront les utilisateurs, et les instructions sur ce qu'il faut faire pour rester à jour avec -CURRENT. Tous les utilisateurs de “CURRENT” doivent s'inscrire à cette liste. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.cvsweb.name; Project CVSweb de FreeBSD Discussions techniques au sujet de l'utilisation, du développement et de la maintenance du FreeBSD-CVSweb. &a.doc.name; Project de documentation C'est la liste de discussion sur les questions et projets liés à la rédaction de documentation pour FreeBSD. Les membres de cette liste sont collectivement appelés “Le Projet de Documentation de FreeBSD” - The FreeBSD Documentation Project. C'est une liste ouverte; n'hésitez pas à vous inscrire et à participer! &a.drivers.name; Ecrire des pilotes de périphériques pour &os; C'est une liste pour les discussions techniques au sujet des pilotes de périphériques sous &os;. C'est principalement un lieu où les personnes écrivant les pilotes peuvent poser des questions sur l'écriture de pilotes utilisant les APIs du noyau &os;. &a.eclipse.name; Pour les utilisateurs &os; de l'EDI Eclipse, les outils, les applications clientes et les logiciels portés. L'objectif de cette liste est de fournir un support pour tout que qui concerne le choix, l'installation, l'utilisation, le développement et la maintenance de l'EDI Eclipse, des ses outils, de ses applications clients sous &os; et l'aide au portage de l'EDI Eclipse et de ses greffons sous l'environnement &os;. Le but est également de faciliter les échanges d'information entre les communautés Eclipse et &os; pour un bénéfice mutuel. Bien que cette liste soit principalement destinée à répondre aux demandes des utilisateurs d'Eclipse, elle est également un forum pour ceux qui désirent développer des applications spécifiques à &os; en utilisant le système Eclipse. + + &a.embedded.name; + + + Utilisation de &os; dans les applications + embarquées + + Cette liste aborde les sujets relatifs à + l'utilisation de &os; dans les systèmes + embarqués. C'est une liste de diffusion à + caractère technique pour laquelle on attend un + contenu strictement technique. Dans le cadre de cette + liste, nous définissons le terme de + système embarqué pour les appareils + informatisés qui ne sont pas des stations de + travail et qui sont destinés à une + application bien particulière et limitée + par opposition aux systèmes informatiques + classiques. Des exemples de systèmes + embarqués, parmi tant d'autres, sont les + combinés téléphoniques, les + équipements réseau comme les routeurs, les + commutateurs et les PABXs, les équipements de + mesure à distance, les PDAs, les systèmes + de distributeurs, et ainsi de suite. + + + &a.emulation.name; Emulation d'autres systèmes comme Linux/&ms-dos;/&windows; C'est une liste pour les discussions techniques relativent à l'exécution sous &os; de programmes écris pour d'autres systèmes d'exploitation. + + &a.eol.name; + + + Entre-aide sur les logiciels relatifs + à &os; et qui ne sont plus supportés par le + projet &os;. + + Cette liste est destinée aux personnes + désirant proposer ou recherchant une aide pour + les logiciels relatifs à &os; pour lesquels le + projet &os; ne fournir officiellement plus de support + (par exemple sous la forme d'avis de + sécutité et de correctifs). + + + &a.firewire.name; &firewire; (iLink, IEEE 1394) C'est une liste pour les discussions sur la conception et le développement d'un sous-système &firewire; (IEEE 1394, iLink) sous FreeBSD. Les sujets appropriés incluent spécifiquement les normes, les bus périphériques et leur protocole, l'ensemble d'adaptateurs/cartes/circuits, et l'architecture et l'implémentation de leur propre support. &a.fs.name; Systèmes de fichiers Discussions concernant les systèmes de fichiers FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.geom.name; GEOM Discussions spécifiques à GEOM et aux implémentations relatives. C'est une liste de diffusion technique sur laquelle le contenu doit être strictement technique. &a.gnome.name; GNOME Discussions concernant l'environnement de travail GNOME sous les systèmes FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.ipfw.name; Coupe-feu IP C'est le forum pour les discussions techniques concernant la nouvelle implémentation du code du coupe-feu IP sous FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.ia64.name; Portage de FreeBSD sur IA64 C'est une liste de discussion technique pour les personnes travaillant sur le portage de FreeBSD sur la plate-forme IA-64 d'&intel;, pour soulever les problèmes ou discuter de solutions alternatives. Ceux qui sont intéressés à suivre les discussions techniques sont aussi bienvenus. &a.isdn.name; Communications ISDN C'est la liste pour les personnes discutant du développement du support ISDN de FreeBSD. &a.java.name; Développement &java; C'est la liste pour les personnes discutant du développement d'applications &java; significatives sous FreeBSD et du portage et de la maintenance des &jdk;s. &a.jobs.name; Recherches et offres d'emplois C'est un forum pour poster des offres d'emplois et des curriculum vitae relatifs à &os;, c'est à dire si vous cherchez un emploi concernant &os; ou que vous offrez un emploi impliquant &os;, alors c'est le bon endroit. Ce n'est pas une liste de diffusion pour les problèmes généraux relatifs aux offres et à la recherche d'un emploi puisque des forums adéquats existent déjà par ailleurs. Notez que cette liste, comme les autres listes de diffusion du domaine FreeBSD.org, est diffusée au niveau mondial. Par conséquent, vous devez être précis quant à l'emplacement, les possibilités de travail à distance ou de déplacement. Les messages devraient utiliser uniquement des formats ouverts — de préférence du texte brut, mais le PDF, l'HTML, et quelques autres formats sont acceptables. Les formats propriétaires comme µsoft; Word (.doc) seront rejetés par le serveur de la liste de diffusion. &a.kde.name; KDE Discussions concernant KDE sous les systèmes &os;. C'est une liste de discussion technique sur laquelle le contenu doit rester strictement technique. &a.hackers.name; Discussions techniques C'est le forum pour les discussions techniques au sujet de FreeBSD. C'est la principale liste technique. Elle est destinée à ceux qui travaillent activement à FreeBSD, pour soulever des problèmes et discuter de solutions alternatives. Ceux qui sont intéressés à suivre les discussions techniques sont aussi bienvenus. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.hardware.name; Discussions générales sur le matériel pour FreeBSD Discussions générales sur les types de matériel sur lesquels tourne FreeBSD, les problèmes rencontrés et suggestions sur quoi acheter ou éviter. &a.hubs.name; Sites miroir Annonces et discussions pour les personnes qui font fonctionner les sites miroir FreeBSD. &a.isp.name; Questions concernant les fournisseurs d'accès à Internet C'est la liste pour discuter des sujets qui intéressent les fournisseurs d'accès Internet - Internet Service Providers (ISPs) - qui utilisent FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.openoffice.name; OpenOffice.org Discussions concernant le portage et la maintenance d'OpenOffice.org et &staroffice;. &a.performance.name; Discussions au sujet de l'optimisation et l'accélération de la vitesse d'exécution de &os; Cette liste de diffusion existe pour offrir un endroit aux hackers, administrateurs, et/ou les parties concernées pour discuter de sujets ayant trait aux performances de &os;. Les sujets acceptables comprennent les discussions concernant les installations de &os; qui sont soit sous charge importante, soit présentant des problèmes de performance, ou encore qui repoussent les limites de &os;. Les personnes désirant travailler sur l'amélioration des performances de &os; sont grandement encouragées à s'inscrire à cette liste. C'est une liste hautement technique destinée aux utilisateurs expérimentés de &os;, aux hackers, ou aux administrateurs intéressés par un &os; rapide, robuste, et adaptable. Ce n'est pas une liste de questions-réponses qui remplace la lecture de la documentation, mais c'est un endroit où il est possible d'effectuer des contributions ou de se préoccuper de sujets non-résolus relatifs aux performances. &a.pf.name; Discussions et questions concernant le système de coupe-feu packet filter Discussions concernant le système de coupe-feu packet filter (pf) sous &os;. Les discussions techniques ainsi que les questions des utilisateurs sont les bienvenues. Cette liste est également un endroit où discuter du système de qualité de service ALTQ. &a.platforms.name; Portage sur les plate-formes non &intel; Questions concernant le support d'autres plates-formes, discussions générales et propositions pour les portages sur des plates-formes non &intel;. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.policy.name; Décisions de la politique de l'équipe de base C'est une liste de discussion à faible trafic, et en lecture seule pour les décisions de la politique de l'équipe de base. &a.ports.name; Discussion sur les “logiciels portés” Discussions concernant le ``catalogue des logiciels portés'' de FreeBSD (/usr/ports), propositions de portages, modifications de l'infrastructure du catalogue des logiciels portés et coordination générale. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.proliant.name; Discussion technique sur l'utilisation de &os; sur les serveurs HP ProLiant Cette liste de diffusion doit être utilisée pour les discussions techniques concernant l'utilisation de &os; sur les serveurs HP ProLiant, y compris les discussions sur les pilotes spécifiques à ces machines, les logiciels de gestion, les outils de configuration, et les mises à jour du BIOS. C'est également le premier endroit où discuter des modules hpasmd, hpasmcli, et hpacucli. &a.python.name; Python sous &os; C'est une liste pour les discussions relatives à l'amélioration du support de Python sous &os;. C'est une liste de discussion technique. Elle est destinée aux personnes travaillant sur le portage de Python, de ses modules tiers partie et éléments relatifs à Zope sous &os;. Les personnes intéressées par ces discussions techniques sont également les bienvenues. &a.questions.name; Questions des utilisateurs C'est la liste pour les questions à propos de FreeBSD. Vous ne devriez pas adresser de questions du type “comment faire” aux listes techniques à moins que vous n'estimiez que la question soit vraiment très technique. &a.scsi.name; Sous-système SCSI C'est la liste de diffusion pour ceux qui travaillent sur le sous-système SCSI de FreeBSD. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.security.name; Questions relatives à la sécurité Questions ayant trait à la sécurité des ordinateurs sous FreeBSD (DES, Kerberos, trous de sécurité connus et correctifs, etc...). C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. Notez que ce n'est pas une liste de question-réponse, mais ce type de contribution (la question ET la réponse) à la FAQ est le bienvenue. &a.security-notifications.name; Avis de sécurité Notifications des problèmes de sécurité concernant FreeBSD et correctifs. Ce n'est pas une liste de discussion. La liste de discussion correspondante est FreeBSD-security. &a.small.name; Utilisation de FreeBSD dans les applications embarquées Cette liste discute de sujets relatifs aux installations inhabituellement petites et embarquées de FreeBSD. C'est une liste de discussion technique sur laquelle un contenu strictement technique est attendu. + + + Cette liste est obsolète depuis la + création de &a.embedded.name;. + &a.stable.name; Discussions concernant l'utilisation de &os.stable; C'est la liste de diffusion pour les utilisateurs de &os.stable;. Elle inclut avertissements au sujet de nouvelles fonctionnalités de -STABLE qui affecteront les utilisateurs, et des instructions sur ce qu'il faut faire pour rester à jour avec -STABLE. Tous les utilisateurs de la branche “STABLE” devraient s'inscrire à cette liste. C'est une liste de discussion technique sur laquelle le contenu doit être strictement technique. &a.standards.name; Conformité aux normes C99 & POSIX C'est un forum pour les discussions techniques concernant la conformité de FreeBSD aux normes C99 et POSIX. &a.usb.name; Discussion sur le support USB sous &os; C'est une liste de diffusion pour les discussions techniques relatives au support de l'USB sous &os; &a.usergroups.name; Coordination des groupes d'utilisateurs C'est la liste pour les coordinateurs des différents groupes locaux d'utilisateurs, destinée à leurs discussions entre eux et avec un membre désigné de l'équipe de base. Cette liste doit se limiter aux comptes-rendus de réunions et à la coordination de projets entre plusieurs groupes d'utilisateurs. &a.vendors.name; Fournisseurs Coordination des discussions entre le projet FreeBSD et les fournisseurs de logiciel ou de matériel pour FreeBSD. Filtrages en vigueur sur les listes de diffusion Les listes de diffusion &os; sont filtrées de plusieurs façons en vue d'éviter la distribution de SPAM, de virus, et tout autre message non-sollicité. Les opérations de filtrage décries dans cette section ne comprennent pas toutes celles utilisées pour protéger les listes re diffusion. Seuls certains types de pièces jointes sont autorisés sur les listes de diffusion. Toutes les pièces jointes avec un format MIME qui ne figurent pas parmi la liste ci-dessous seront retirées avant que le message ne soit distribué sur les listes de diffusion. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Certaines listes de diffusion pourront autoriser des pièces jointes sous d'autres formats MIME, mais la liste précédente devrait être applicable pour la plupart des listes de diffusion. Si un message contient une version HTML et une version texte du contenu du message, la version HTML sera retirée. Si le corps d'un message est uniquement sous forme HTML, il sera converti sous forme texte brut. Forums de discussion En plus de deux forums de discussion spécifiques à FreeBSD, il y en a de nombreux autres où il est question de FreeBSD ou qui sont par ailleurs d'intérêt pour les utilisateurs de FreeBSD. Des archives interrogeables par mots-clés sont disponibles pour certains de ces forums, grâce à Warren Toomey wkt@cs.adfa.edu.au. Forums spécifiques à BSD comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (Allemand) fr.comp.os.bsd (Français) it.comp.os.freebsd (Italien) + + + tw.bbs.comp.386bsd (Chinois) + Autres forums &unix; intéressants comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd Système X Window comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine Serveurs World Wide Web &chap.eresources.www.inc; Adresses électroniques Les groupes d'utilisateurs suivants fournissent à leurs membres des adresses électroniques liées à FreeBSD. Les administrateurs cités se réservent le droit de supprimer l'adresse si elle est à l'origine d'abus. Domaine Possibilités offertes Groupe d'utilisateurs Administrateur ukug.uk.FreeBSD.org Transmission de courrier uniquement freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Comptes Les groupes d'utilisateurs suivants fournissent des comptes aux personnes supportant le projet FreeBSD. Les administrateurs cités se réservent le droit de supprimer le compte s'il est à l'origine d'abus. Hôte Accès Possibilités offertes Administrateur dogma.freebsd-uk.eu.org Telnet/FTP/SSH Adresse électronique, espace Web, FTP anonyme Lee Johnston lee@uk.FreeBSD.org