Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] sysklogd - Utilitaires de journalisation du système Linux. [size=18] [b]Résumé[/b] [/size] [b]syslogd[/b] [b][ -a [/b] [i]socket[/i] ] [b][ -d ][/b] [b][ -f [/b] [i]fichier_config[/i] ] [b][ -h ] [/b] [b][ -l [/b] [i]liste_hôte[/i] ] [b][ -m [/b] [i]intervalle[/i] ] [b][ -n ][/b] [b][ -p[/b] [b][i]socket [/i][/b] ] [b][ -r ][/b] [b][ -s [/b] [i]liste_domaine[/i] ] [b][ -v ][/b]     [size=18] [b]Description[/b] [/size] [b]Sysklogd[/b] fournit deux utilitaires système permettant la journalisation système et le piégeage des messages noyau. La gestion des sockets de domaines Internet et Unix permet à ce paquetage d'utilitaires de supporter à la fois les journalisations locale et distante. La journalisation système est fournie par une version de [b]syslogd (8)[/b] dérivée du stock de sources BSD. La gestion de la journalisation du noyau est fournie par l'utilitaire [b]klogd (8)[/b] qui permet à celle-ci d'être conduite soit en mode autonome, soit comme client de syslogd. [b]Syslogd[/b] fournit un type de journalisation qu'utilisent de nombreux programmes modernes. Chaque message journalisé contient au moins une heure et un champ nom d'hôte, normalement aussi un champ nom de programme, mais cela dépend quelle confiance on accorde au programme les émettant. Bien que les sources de [b]syslogd[/b] aient été lourdement modifiées, quelques notes restent d'actualité. Tout d'abord l'effort a systématiquement été fait pour assurer que syslogd suive par défaut le comportement standard de la version BSD. Le deuxième concept important à noter est que syslogd interagit de façon transparente avec la version de syslog existante dans les bibliothèques standard. Si un exécutable lié à la bibliothèque standard partagée n'exerce pas correctement sa fonction, les auteurs aimeraient recevoir un exemple de ce comportement anormal. Le fichier principal de configuration [i]/etc/syslog.conf,[/i] ou un autre fichier donné par l'option [b]-f[/b] , est lu au démarrage. Chaque ligne commençant par un dièse (« # ») et les lignes vides sont ignorées. Si une erreur se produit durant l'interprétation, la ligne entière est ignorée.     [size=18] [b]Options[/b] [/size] [b][i]-a socket[/i][/b] [table][row][col]    [/col][col]En utilisant cet argument vous pouvez précisez des sockets supplémentaires à partir desquelles [b]syslogd[/b] doit écouter. Ceci est nécessaire si vous voulez laisser un démon lancé dans un environnement chroot(). Vous pouvez utiliser jusqu'à 19 sockets supplémentaires. Si votre environnement en a besoin d'encore plus, vous devez augmenter le symbole [b]MAXFUNIX[/b] dans le fichier source syslogd.c. Un exemple de démon chroot() est donné par les membres d'OpenBSD dans http://www.psionic.com/papers/dns.html.[/col][/row][/table] [b]-d[/b] [table][row][col]    [/col][col]Passe en mode débugage. En utilisant ceci, le démon ne procédera pas à un [b]fork (2)[/b] pour se mettre en arrière-plan, mais à l'opposé va rester en avant-plan et affichera de nombreuses informations de débugage sur le terminal [NdT : tty] courant. Voir la section DEBUGAGE pour plus d'informations.[/col][/row][/table] [b][i]-f fichier_config[/i][/b] [table][row][col]    [/col][col]Précise un autre fichier de configuration que [b]/etc/syslog.conf ,[/b] qui est la valeur par défaut.[/col][/row][/table] [b][i]-h [/i][/b] [table][row][col]    [/col][col]Par défaut, syslogd ne retransmet pas les messages qu'il reçoit d'hôtes distants. Préciser cette bascule en ligne de commande forcera le démon de journalisation à transmettre tous les messages distants qu'il reçoit vers les hôtes qui auront été définis.[/col][/row][/table] [b][i]-l liste_hôte[/i][/b] [table][row][col]    [/col][col]Précise un hôte qui sera journalisé uniquement avec son simple nom d'hôte et non le nom complet de domaine. Des hôtes multiples peuvent être précisés en utilisant le séparateur deux-points (« : »).[/col][/row][/table] [b][i]-m intervalle[/i][/b] [b]Syslogd[/b] [table][row][col]    [/col][col]journalise une marque de temps régulièrement. L' [i]intervalle[/i] par défaut entre deux lignes [i]--[/i] MARK -- est 20 minutes. Ceci peut être changé avec cette option. Positionner [i]intervalle[/i] à zéro le coupe complètement.[/col][/row][/table] [b]-n[/b] [table][row][col]    [/col][col]Évite la mise en arrière-plan automatique. Ceci est nécessaire particulièrement si [b]syslogd[/b] est lancé et contrôlé par [b]init (8).[/b][/col][/row][/table] [b][i]-p socket[/i][/b] [table][row][col]    [/col][col]Vous pouvez préciser une autre socket de domaine Unix que [b]/dev/log .[/b][/col][/row][/table] [b]-r[/b] [table][row][col]    [/col][col]Cette option permettra de recevoir des messages depuis le réseau en utilisant la socket de domaine internet du service syslog (voir [b]services (5)).[/b] La valeur par défaut est de ne pas recevoir de messages du réseau. Cette option a été introduite dans la version 1.3 du paquetage syslogd. Notez que le comportement par défaut est à l'opposé de celui des anciennes versions, aussi vous devriez la remettre en fonction.[/col][/row][/table] [b][i]-s liste_domaine[/i][/b] [table][row][col]    [/col][col]Précise un nom de domaine qui sera rogné avant journalisation. Des domaines multiples peuvent être précisés en utilisant le séparateur deux-points (« : »). Soyez averti qu'aucun sous-domaine ne peut être précisé mais seulement des noms de domaine complets. Par exemple si [b]-s north.de[/b] est précisé et que l'hôte journalisant résout satu.infodrom.north.de, aucun nom de domaine ne sera coupé ; vous devrez préciser deux domaines comme : [b]-s north.de:infodrom.north.de .[/b][/col][/row][/table] [b]-v[/b] [table][row][col]    [/col][col]Affiche la version et se termine.[/col][/row][/table]     [size=18] [b]Signaux[/b] [/size] [b]Syslogd[/b] réagit à une liste de signaux. Vous pouvez facilement envoyer un signal à [b]syslogd[/b] en utilisant ce qui suit : [table][row][col]    [/col][col].nf kill -SIGNAL `cat /var/run/syslogd.pid` .fi[/col][/row][/table] [b]SIGHUP[/b] [table][row][col]    [/col][col]Ceci réinitialise [b]syslogd.[/b] Tous les fichiers ouverts sont fermés, le fichier de configuration ( [b]/etc/syslog.conf[/b] par défaut) sera relu et [b]syslog (3)[/b] sera lancé à nouveau.[/col][/row][/table] [b]SIGTERM[/b] [b]Syslogd[/b] [table][row][col]    [/col][col]se termine.[/col][/row][/table] [b]SIGINT , SIGQUIT[/b] [table][row][col]    [/col][col]Si le débugage est actif, ils sont ignorés, sinon [b]syslogd[/b] se termine.[/col][/row][/table] [b]SIGUSR1[/b] [table][row][col]    [/col][col]Bascule le débugage en marche/arrêt. Cette option ne peut être utilisée que si [b]syslogd[/b] est lancé avec l'option de débugage [b]-d.[/b][/col][/row][/table] [b]SIGCHLD[/b] [table][row][col]    [/col][col]Attend ses enfants s'ils existent, en raison de messages condamnés.[/col][/row][/table]     [size=18] [b]DiffÉrences de syntaxe du fichier de configuration[/b] [/size] [b]Syslogd[/b] utilise une syntaxe légèrement différente pour son fichier de configuration que celle des sources originales BSD. Originellement tous les messages d'une priorité précisée et au-dessus étaient transmis au journal. [table][row][col]    [/col][col]Par exemple les lignes suivantes envoyant TOUTES les sorties des démons utilisant les capacité du démon [b]syslog[/b] (debug est la priorité la plus faible, aussi toutes les priorités correspondront aussi) vers [b]/usr/adm/daemons :[/b][/col][/row][/table] [table][row][col]    [/col][col].nf # Exemple de syslog.conf daemon.debug /usr/adm/daemons .fi[/col][/row][/table] Avec le nouveau schéma, ce comportement reste le même. La différence est l'ajout de quatre nouveaux spécificateurs, le caractère de remplacement astérisque ([b][/b]), le signe égal ([b]=[/b]), le point d'exclamation ([b]![/b]), et le signe moins ([b]-[/b]). [b]=[/b] précise que tous les messages de la facility précisée doivent être dirigés vers la destination. Remarquez que ce comportement est le même qu'en précisant un niveau de priorité debug. Les utilisateurs ont indiqué que la notation astérisque est plus intuitive. Le signe [b]=[/b] est utilisé pour restreindre la journalisation au niveau de priorité précisé. Ceci permet, par exemple, de router uniquement les messages de débugage vers un journal particulier. [table][row][col]    [/col][col]Par exemple la ligne suivante dans [i]syslog.conf[/i] dirigera les messages de débugage de toutes les sources vers le fichier [i]/usr/adm/debug.[/i][/col][/row][/table] [table][row][col]    [/col][col].nf # Exemple de syslog.conf .=debug /usr/adm/debug .fi[/col][/row][/table] [b]![/b] est utilisé pour exclure la journalisation de la priorité précisée. Ceci affecte toutes (!) les possibilité de précision de priorité. [table][row][col]    [/col][col]Par exemple, les lignes suivantes journaliseraient tous les messages de la facility mail en dehors de celle de priorité info vers le fichier [i]/usr/adm/mail.[/i] Et tous les messages de news.info (inclus) à news.crit (exclus) seraient journalisés vers le fichier [i]/usr/adm/news.[/i][/col][/row][/table] [table][row][col]    [/col][col].nf # Exemple de syslog.conf mail.;mail.!=info /usr/adm/mail news.info;news.!crit /usr/adm/news .fi[/col][/row][/table] Vous pouvez l'utiliser intuitivement comme une déclaration d'exception. L'interprétation mentionnée ci-dessus est simplement intervertie. Ce faisant, vous pouvez utiliser .nf mail.none .fi or .nf mail.! .fi or .nf mail.!debug .fi pour omettre chaque message arrivant avec la facility mail. Et il y a encore beaucoup de jeux à essayer avec ceci. :-) [b]-[/b] devrait seulement être utilisé comme préfixe d'un nom de fichier si vous ne voulez pas effectuer de synchronisation après chaque écriture dans ce fichier. Cela nécessite une accoutumance pour ceux habitués au pur comportement BSD, mais les testeurs ont indiqué que cette syntaxe est quelque peu plus flexible que ce comportement. Remarquez que ce changement ne devrait pas affecter un fichier [b]syslog.conf (5)[/b] standard. Vous devez modifier spécifiquement ce fichier de configuration pour obtenir le comportement amélioré.     [size=18] [b]Support de la journalisation distante[/b] [/size] Ces modifications fournissent une capacité réseau à syslogd. Cela signifie que les messages peuvent être retransmis d'un n½ud exécutant syslogd à un autre exécutant syslogd où ils seront réellement journalisés sur un disque. Pour permettre ceci vous devez préciser l'option [b]-r[/b] sur la ligne de commande. Le comportement par défaut est que [b]syslogd[/b] n'écoutera pas le réseau. La stratégie est de faire écouter par syslogd une socket de domaine Unix pour les messages de journalisation générés localement. Ce comportement permettra à syslogd d'inter-opérer avec le syslog de la bibliothèque C standard. Au même moment syslogd écoute sur le port standard de syslog pour les messages retransmis depuis d'autres hôtes. Pour que ceci fonctionne correctement, le fichier [b]services (5)[/b] (typiquement dans [b]/etc )[/b] doit avoir l'entrée suivante : [table][row][col]    [/col][col].nf syslog 514/udp .fi[/col][/row][/table] Si cette entrée manque [b]syslogd[/b] ne peut ni recevoir de messages distincts, ni en émettre, parce que le port UDP ne peut être ouvert. Au lieu de cela [b]syslogd[/b] se terminera immédiatement, en émettant un message d'erreur. Pour que les messages soient retransmis vers des hôtes distants, remplacez une ligne normale dans le fichier [i]syslog.conf[/i] par le nom de l'hôte vers lequel les messages doivent être envoyés, préposé avec @. [table][row][col]    [/col][col]Par exemple, pour retransmettre [b]TOUS[/b] les messages vers un hôte distant utilisez l'entrée suivante dans [i]syslog.conf :[/i][/col][/row][/table] [table][row][col]    [/col][col].nf # Exemple de fichier de configuration de syslogd # pour retransmettre tous les messages vers un # hôte distant . @nom_hôte .fi Pour retransmettre tous les messages [b]noyau[/b] vers un hôte distant, le fichier de configuration devrait être comme suit :[/col][/row][/table] [table][row][col]    [/col][col].nf # Exemple de fichier de configuration de syslogd # pour retransmettre tous les messages noyau vers # un hôte distant kern.* @nom_hôte .fi[/col][/row][/table] Si le nom d'hôte distant ne peut être résolu au lancement parce que le serveur de nom était inaccessible (il pourrait être lancé après syslogd), vous ne devez pas vous inquiéter. [b]Syslogd[/b] essayera de résoudre le nom dix fois avant de se plaindre. Une autre possibilité pour éviter ceci est de placer le nom d'hôte dans [b]/etc/hosts .[/b] Avec un [b]syslogd[/b] normal vous aurez une boucle syslog si vous envoyez les messages reçus d'un hôte distant vers ce même hôte (ou plus compliqué vers un troisième hôte qui les retransmet vers le premier, et ainsi de suite). Dans le domaine de l'auteur (Infodrom Oldenburg) ceci a été accidentellement obtenu et les disques se sont remplis avec le même message simple. :-( Pour éviter ceci dans le futur, aucun message reçu d'un hôte distant n'est plus envoyé vers un autre (ou le même) hôte distant. S'il existe des scénarios où cela n'a pas de sens, merci d'en toucher un mot à Joey. Si l'hôte distant est localisé sur le même domaine que l'hôte exécutant [b]syslogd,[/b] le simple nom d'hôte sera journalisé au lieu du nom complet de domaine. Dans un réseau local vous pouvez établir un serveur central de journaux qui détient toutes les informations importantes. Si le réseau est composé de différents domaines vous n'avez pas de raison de vous plaindre de journaliser des noms de domaines complets au lieu de simples nom d'hôtes. Vous pouvez en effet utiliser la capacité de rognage de nom de domaines [b]-s[/b] sur ce serveur. Vous pouvez dire à [b]syslogd[/b] de rogner plusieurs domaines autres que celui sur lequel le serveur est localisé et de journaliser de simples nom d'hôtes. En utilisant l'option [b]-l[/b] il y aussi possibilité de définir des hôtes comme machines locales. Ceci, aussi, conduit à journaliser seulement leur simple nom d'hôte plutôt que leur noms complets de domaine. La socket UDP utilisée pour retransmettre les messages vers des hôtes distants ou pour en recevoir d'eux est seulement ouverte quand c'est nécessaire. Dans les versions précédant 1.3-23, elle était ouverte à chaque fois, mais pas en uniquement lecture ou en écriture. [size=18] [b]Nom[/b] [/size] Cette version de syslogd supporte la journalisation à travers des tubes nommés (fifos). Un fifo ou tube nommé peut être utilisé comme destination des messages en préfixant du symbole pipe (« \| ») le nom du fichier. Ceci est pratique pour le débugage. Remarquez que le fifo doit être créé avec la commande mkfifo avant que syslog ne soit lancé. [table][row][col]    [/col][col]Le fichier de configuration suivant route les messages de débugage du noyau vers un fifo :[/col][/row][/table] [table][row][col]    [/col][col].nf # Exemple de fichier de configuration pour ne # router QUE les messages debug vers /usr/adm/debug # qui est un tube nommé kern.=debug \|/usr/adm/debug .fi[/col][/row][/table]     [size=18] [b]ProblÈmes dinstallation[/b] [/size] Il y a sûrement une considération importante à prendre en compte lors de l'installation de cette version de syslogd. Cette version de syslogd dépend du formatage des messages par la fonction syslog. Le fonctionnement de la fonction syslog des bibliothèques partagées a changé quelque part autour de libc.so.4.[2-4].n. Le changement spécifique fut de terminer le message par un caractère nul avant de le transmettre à la socket [i]/dev/log.[/i] Le fonctionnement de cette version de syslogd dépend de cette terminaison du message par un caractère nul. Ce problème se manifeste typiquement si de vieux exécutables liés statiquement sont utilisés sur le système. Les exécutables utilisant d'anciennes version de la fonction syslog conduiront à la journalisation de lignes vides suivies par le message privé de son premier caractère. Relier ces exécutables à de nouvelles versions des bibliothèques partagées corrigera le problème. À la fois [b]syslogd (8) et klogd (8)[/b] peuvent être exécutés par [b]init (8)[/b] ou lancés à partir d'une séquence rc.. S'il est lancé à partir d'initi, l'option [i][/i]-n doit être active, sinon vous lancerez des tonnes de démons syslog. Ceci est du au fait qu' [b]init (8)[/b] dépend de l'identifiant du processus [NdT : PID].     [size=18] [b]Menaces de sÉcuritÉ[/b] [/size] Il y une possibilité que le démon syslogd soit utilisé comme passage pour une attaque de déni de service. Merci à John Morrison (jmorriso@rflab.ee.ubc.ca) d'avoir prévenu de cette possibilité. Un programme(ur) voyou pourrait très simplement noyer le démon syslogd avec des messages, ce qui conduirait les journaux à remplir toute la place restante du système de fichiers. Activer la journalisation à travers la socket de domaine internet exposera le système à des risques extérieurs vis-à-vis des programmes ou des utilisateurs de la machine locale. Il y a de nombreuses méthodes pour protéger cette machine : 1. [table][row][col]    [/col][col]Implémenter le pare-feu du noyau pour limiter les hôtes ou les réseaux ayant accès à la socket 514/UDP.[/col][/row][/table] 2. [table][row][col]    [/col][col]La journalisation peut être dirigée vers un système de fichiers isolé ou non-racine qui, s'il est plein, n'impactera pas la machine.[/col][/row][/table] 3. [table][row][col]    [/col][col]Le système de fichiers ext2 peut être utilisé en le configurant pour limiter un certain pourcentage du système de fichier pour une utilisation par root seulement. [b]REMARQUEZ[/b] que cela obligera à lancer syslogd comme processus non root. [b]REMARQUEZ[/b] AUSSI que cela empêchera l'utilisation de la journalisation distante, puisque syslog sera incapable de lier la socket 514/UDP.[/col][/row][/table] 4. [table][row][col]    [/col][col]Désactiver la socket de domaine internet limitera les risques sur la machine locale.[/col][/row][/table] 5. [table][row][col]    [/col][col]Essayez la méthode 4 et si le problème persiste et n'est pas la conséquence d'un programme/démon voyou, prenez un « sucker rod » et ayez une discussion avec l'utilisateur en question. « Sucker rod » (em baguette en acier durci de 1.9, 2.2 ou 2.5 cm, filetée à chaque bout. Utilisé originellement dans l'industrie du pétrole dans le Dakota du nord et d'autres endroits pour pomper [NdT : suck] le pétrole depuis les puits de pétrole. Les autres utilisations sont la construction de parcelles pour nourrir le bétail, et les relations avec des individus occasionnels récalcitrants ou belliqueux.[/col][/row][/table]     [size=18] [b]DÉbugage[/b] [/size] Quand le débugage est activé en utilisant l'option [b]-d[/b] alors [b]syslogd[/b] sera très verbeux en affichant sur la sortie standard la plupart des choses qu'il fait. Chaque fois que le fichier de configuration est relu ou re-analysé vous verrez une tabulation, correspondant à la structure de données interne. Cette tabulation consiste en quatre champs : [i]numéro[/i] [table][row][col]    [/col][col]Ce champ contient un numéro de série commençant par zéro. Ce numéro représente la position dans la structure de données interne (c'est-à-dire dans le tableau). Si un nombre est laissé de côté alors il est probable qu'il y ait une erreur dans la ligne de [b]/etc/syslog.conf[/b] correspondante.[/col][/row][/table] [i]modèle[/i] [table][row][col]    [/col][col]Ce champ est complexe et représente exactement la structure interne. Chaque colonne représente une capacité (référez-vous à [b]syslog (3)).[/b] Comme vous pouvez le voir, il y encore quelques facility laissées libres pour une utilisation future, seulement les plus à gauche sont utilisées. Chaque champ dans une colonne représente une priorité (référez-vous à [b]syslog (3)).[/b][/col][/row][/table] [i]action[/i] [table][row][col]    [/col][col]Ce champ décrit l'action particulière qui est effectuée à chaque fois qu'un message correspondant au modèle est reçu. Référez-vous à la page de manuel de [b]syslog.conf (5)[/b] pour toutes les actions possibles.[/col][/row][/table] [i]arguments[/i] [table][row][col]    [/col][col]Ce champ montre les arguments supplémentaires pour les actions du dernier champ. Pour la journalisation fichiers c'est le nom du journal ; pour la journalisation utilisateurs c'est une liste d'utilisateurs ; pour la journalisation distante c'est le nom d'hôte de la machine sur laquelle journaliser ; pour la journalisation sur console c'est la console utilisée ; pour la journalisation sur terminal c'est le terminal précisé ; wall n'a pas d'arguments supplémentaires.[/col][/row][/table] [size=18] [b]Fichiers[/b] [/size] [i]/etc/syslog.conf[/i] [table][row][col]    [/col][col]Fichier de configuration pour [b]syslogd .[/b] Voir [b]syslog.conf (5)[/b] pour des informations exactes.[/col][/row][/table] [i]/dev/log[/i] [table][row][col]    [/col][col]La socket de domaine Unix depuis ou vers laquelle les messages syslog sont lus.[/col][/row][/table] [i]/var/run/syslogd.pid[/i] [table][row][col]    [/col][col]Le fichier contenant l'identifiant du processus [b]syslogd .[/b][/col][/row][/table] [size=18] [b]Bogues[/b] [/size] Si une erreur apparaît sur une ligne la ligne entière est ignorée. [b]Syslogd[/b] ne change pas les permissions des journaux ouverts à aucun état du programme. Si un fichier est créé, il est lisible par tous. Si vous voulez éviter ceci, vous devez le créer manuellement et changer ses permissions. Ceci peut être fait en combinaison avec la permutation des journaux en utilisant le programme [b]savelog (8)[/b] qui est empaqueté dans la distribution [b]smail[/b] 3.x. Gardez à l'esprit que laisser tout le monde lire auth. peut être un trou de sécurité dans la mesure où il peut contenir des mots de passes.     [size=18] [b]Voir aussi[/b] [/size] [b]syslog.conf (5),[/b] [b]klogd (8),[/b] [b]logger (1),[/b] [b]syslog (2),[/b] [b]syslog (3),[/b] [b]services (5),[/b] [b]savelog (8)[/b]     [size=18] [b]Collaborateurs[/b] [/size] [b]Syslogd[/b] est tiré des sources BSD, Greg Wettstein (greg@wind.enjellic.com) en a effectué le portage sous Linux, Martin Schulze (joey@linux.de) a corrigé certains bugs et ajouté de nombreuses possibilités. [b]Klogd[/b] a originellement été écrit par Steve Lord (lord@cray.com), Greg Wettstein y a apporté des améliorations majeures. [table][row][col]    [/col][col]Dr. Greg Wettstein[/col][/row][/table] [table][row][col]    [/col][col]Enjellic Systems Development[/col][/row][/table] [table][row][col]    [/col][col]Oncology Research Division Computing Facility[/col][/row][/table] [table][row][col]    [/col][col]Roger Maris Cancer Center[/col][/row][/table] [table][row][col]    [/col][col]Fargo, ND[/col][/row][/table] [table][row][col]    [/col][col]greg@wind.enjellic.com [/col][/row][/table] [table][row][col]    [/col][col]Stephen Tweedie[/col][/row][/table] [table][row][col]    [/col][col]Department of Computer Science[/col][/row][/table] [table][row][col]    [/col][col]Edinburgh University, Scotland[/col][/row][/table] [table][row][col]    [/col][col]sct@dcs.ed.ac.uk [/col][/row][/table] [table][row][col]    [/col][col]Juha Virtanen[/col][/row][/table] [table][row][col]    [/col][col]jiivee@hut.fi [/col][/row][/table] [table][row][col]    [/col][col]Shane Alderton[/col][/row][/table] [table][row][col]    [/col][col]shane@ion.apana.org.au [/col][/row][/table] [table][row][col]    [/col][col]Martin Schulze[/col][/row][/table] [table][row][col]    [/col][col]Infodrom Oldenburg[/col][/row][/table] [table][row][col]    [/col][col]joey@linux.de[/col][/row][/table]     [size=18] [b]Traduction[/b] [/size] Laurent Hugé [size=18] [b]Traduction[/b] [/size] Il est possible que cette traduction soit imparfaite ou périmée. En cas de doute, veuillez vous reporter au document original en langue anglaise fourni avec le programme.
Fichier