Archives pour la catégorie Memo

Memorandum: note des choses dont on veut se souvenir, carnet contenant ces notes.

Les pages MAN de sysklogd

MAN SYSKLOGD
Section : Administration du système Linux (8)
Updated : Jeudi 25 décembre 2003
Index Return to Main Contents

NOM

sysklogd – Utilitaires de journalisation du système Linux.

SYNOPSIS

syslogd [ -a socket ] [ -d ] [ -f fichier_config ] [ -h ] [ -l liste_hôte ] [ -m intervalle ] [ -n ] [ -p socket ] [ -r ] [ -s liste_domaine ] [ -v ]

DESCRIPTION

Sysklogd 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 syslogd(8) dérivée du stock de sources BSD. La gestion de la journalisation du noyau est fournie par l’utilitaire klogd(8) qui permet à celle-ci d’être conduite soit en mode autonome, soit comme client de syslogd.

Syslogd 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 syslogd 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 /etc/syslog.conf, ou un autre fichier donné par l’option -f , 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.

OPTIONS

-a socket
En utilisant cet argument vous pouvez précisez des sockets supplémentaires à partir desquelles syslogd 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 MAXFUNIX 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.

-d
Passe en mode débugage. En utilisant ceci, le démon ne procédera pas à un fork(2) 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.

-f fichier_config
Précise un autre fichier de configuration que /etc/syslog.conf, qui est la valeur par défaut.

-h
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.

-l liste_hôte
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 (« : »).

-m intervalle
Syslogd journalise une marque de temps régulièrement. L’ intervalle par défaut entre deux lignes — MARK — est 20 minutes. Ceci peut être changé avec cette option. Positionner intervalle à zéro le coupe complètement.

-n
Évite la mise en arrière-plan automatique. Ceci est nécessaire particulièrement si syslogd est lancé et contrôlé par init(8).

-p socket
Vous pouvez préciser une autre socket de domaine Unix que /dev/log.

-r
Cette option permettra de recevoir des messages depuis le réseau en utilisant la socket de domaine internet du service syslog (voir services(5)). 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.

-s liste_domaine _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 -s north.de 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 : -s north.de:infodrom.north.de.

-v
Affiche la version et se termine.

SIGNAUX

Syslogd réagit à une liste de signaux. Vous pouvez facilement envoyer un signal à syslogd en utilisant ce qui suit :

kill -SIGNAL `cat /var/run/syslogd.pid`

SIGHUP
Ceci réinitialise syslogd. Tous les fichiers ouverts sont fermés, le fichier de configuration ( /etc/syslog.conf par défaut) sera relu et syslog(3) sera lancé à nouveau.

SIGTERM
Syslogd se termine.

SIGINT, SIGQUIT
Si le débugage est actif, ils sont ignorés, sinon syslogd se termine.

SIGUSR1
Bascule le débugage en marche/arrêt. Cette option ne peut être utilisée que si syslogd est lancé avec l’option de débugage -d.

SIGCHLD
Attend ses enfants s’ils existent, en raison de messages condamnés.

DIFFÉRENCES DE SYNTAXE DU FICHIER DE CONFIGURATION

Syslogd 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.

Par exemple les lignes suivantes envoyant TOUTES les sorties des démons utilisant les capacité du démon syslog (debug est la priorité la plus faible, aussi toutes les priorités correspondront aussi) vers /usr/adm/daemons :


# Exemple de syslog.conf
daemon.debug /usr/adm/daemons

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 (*), le signe égal (=), le point d’exclamation ( !), et le signe moins (-).

= 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 = 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.

Par exemple la ligne suivante dans syslog.conf dirigera les messages de débugage de toutes les sources vers le fichier /usr/adm/debug.


# Exemple de syslog.conf
*.=debug /usr/adm/debug

! est utilisé pour exclure la journalisation de la priorité précisée. Ceci affecte toutes ( !) les possibilité de précision de priorité.

Par exemple, les lignes suivantes journaliseraient tous les messages de la facility mail en dehors de celle de priorité info vers le fichier /usr/adm/mail. Et tous les messages de news.info (inclus) à news.crit (exclus) seraient journalisés vers le fichier /usr/adm/news.


# Exemple de syslog.conf
mail.*;mail.!=info /usr/adm/mail
news.info;news.!crit /usr/adm/news

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


mail.none

or

mail.!*

or

mail.!debug

pour ommettre chaque message arrivant avec la facility mail. Et il y a encore beaucoup de jeux à essayer avec ceci. 🙂

/ 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 syslog.conf(5) standard. Vous devez modifier spécifiquement ce fichier de configuration pour obtenir le comportement amélioré.

SUPPORT DE LA JOURNALISATION DISTANTE

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 -r sur la ligne de commande. Le comportement par défaut est que syslogd 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 services(5) (typiquement dans /etc) doit avoir l’entrée suivante :


syslog 514/udp

Si cette entrée manque syslogd ne peut ni recevoir de messages distincts, ni en émettre, parce que le port UDP ne peut être ouvert. Au lieu de cela syslogd 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 syslog.conf par le nom de l’hôte vers lequel les messages doivent être envoyés, préposé avec @.

Par exemple, pour retransmettre TOUS les messages vers un hôte distant utilisez l’entrée suivante dans syslog.conf :


# Exemple de fichier de configuration de syslogd
# pour retransmettre tous les messages vers un
# hôte distant
*.* @nom_hôte

Pour retransmettre tous les messages noyau vers un hôte distant, le fichier de configuration devrait être comme suit :


# Exemple de fichier de configuration de syslogd
# pour retransmettre tous les messages noyau vers
# un hôte distant
kern.* @nom_hôte

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. Syslogd 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 /etc/hosts.

Avec un syslogd 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 syslogd, 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 -s sur ce serveur. Vous pouvez dire à syslogd 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 -l 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.

ÉCRITURE DANS LES TUBES NOMMÉS (FIFOs)

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é.

Le fichier de configuration suivant route les messages de débugage du noyau vers un fifo :


# 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

PROBLÈMES D’INSTALLATION

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 /dev/log. 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 syslogd(8) et klogd(8) peuvent être exécutés par init(8) ou lancés à partir d’une séquence rc.*. S’il est lancé à partir d’initi, l’option -n doit être active, sinon vous lancerez des tonnes de démons syslog. Ceci est du au fait qu’ init(8) dépend de l’identifiant du processus [NdT : PID].

MENACES DE SÉCURITÉ

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. Implémenter le pare-feu du noyau pour limiter les hôtes ou les réseaux ayant accès à la socket 514/UDP.
  2. 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.
  3. 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. REMARQUEZ que cela obligera à lancer syslogd comme processus non root. REMARQUEZ AUSSI que cela empêchera l’utilisation de la journalisation distante, puisque syslog sera incapable de lier la socket 514/UDP.
  4. Désactiver la socket de domaine internet limitera les risques sur la machine locale.
  5. 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 » — 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.

DÉBUGAGE

Quand le débugage est activé en utilisant l’option -d alors syslogd 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 :

numéro
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 /etc/syslog.conf correspondante.

modèle
Ce champ est complexe et représente exactement la structure interne. Chaque colonne représente une capacité (référez-vous à syslog(3)). 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 à syslog(3)).

action
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 syslog.conf(5) pour toutes les actions possibles.

arguments
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.

FICHIERS

/etc/syslog.conf Fichier de configuration pour syslogd. Voir syslog.conf(5) pour des informations exactes. /dev/log La socket de domaine Unix depuis ou vers laquelle les messages syslog sont lus. /var/run/syslogd.pid Le fichier contenant l’identifiant du processus syslogd.

BUGS

Si une erreur apparaît sur une ligne la ligne entière est ignorée.

Syslogd 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 savelog(8) qui est empaqueté dans la distribution smail 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.

VOIR AUSSI

syslog.conf(5), klogd(8), logger(1), syslog(2), syslog(3), services(5), savelog(8)

COLLABORATEURS

Syslogd 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. Klogd a originellement été écrit par Steve Lord (lord@cray.com), Greg Wettstein y a apporté des améliorations majeures.

Dr. Greg Wettstein Enjellic Systems Development Oncology Research Division Computing Facility Roger Maris Cancer Center Fargo, ND greg@wind.enjellic.com

Stephen Tweedie Department of Computer Science Edinburgh University, Scotland sct@dcs.ed.ac.uk

Juha Virtanen jiivee@hut.fi

Shane Alderton shane@ion.apana.org.au

Martin Schulze Infodrom Oldenburg joey@linux.de

TRADUCTION

Laurent Hugé

AVERTISSEMENT SUR LA TRADUCTION

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.

Les pages MAN de syslog.conf

MAN SYSLOG.CONF
Section : Administration du système Linux
Updated : Mardi 10 Février 2004
Index Return to Main Contents

NOM

syslog.conf – fichier de configuration de syslogd(8)

DESCRIPTION

Le fichier syslog.conf est le fichier principal de configuration de syslogd(8) qui journalise les messages des systèmes *nix. Ce fichier précise les règles de journalisation. Pour des possibilités spécifiques, lisez la page de manuel de sysklogd(8).

Chaque règle consiste en deux champs, un champ sélecteur et un champ action. Ces deux champs sont séparés par un ou plusieurs espaces ou tabulations. Le champ sélecteur précise un modèle de facility et priorité correspondant à l’action précisée.

Les lignes commençant par un dièse (« # ») et les lignes vides sont ignorées.

Cette version de syslogd est capable de comprendre une syntaxe étendue. Une règle peut être divisée en plusieurs lignes si la ligne de départ se termine par un anti-slash (« \ »).

SÉLECTEURS

Le champ sélecteur est lui-même encore divisé en deux parties, une facility et une priorité, séparés par un point (« . »). Chaque partie est insensible à la casse et peut aussi être décrite avec des nombres décimaux, mais ne le faites pas, vous aurez été prévenu. Facility et priorité sont toutes deux décrites dans syslog(3). Les noms mentionnés ci-dessous correspondent à leurs valeurs LOG_ similaires dans /usr/include/syslog.h.

La facility est l’un des mots-clés suivants : auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security (identique à auth), syslog, user, uucp et de local0 à local7. Le mot-clé security ne devrait plus être utilisé et mark est seulement destiné à un usage interne et ne devrait par conséquent pas être utilisé dans les applications. Cependant, vous pouvez avoir envie de préciser la redirection de ces messages ici. La facility identifie le sous-système qui produit le message, c’est-à-dire que tous les programmes de courriel journalisent avec la facility mail (LOG_MAIL) s’ils journalisent via syslog.

La priorité est l’un des mots-clés suivants, dans l’ordre croissant : debug, info, notice, warning, warn (identique à warning), err, error (identique à err), crit, alert, emerg, panic (identique à emerg). Les mots-clés error, warn et panic sont désapprouvés et ne devraient plus être utilisés. La priorité définit la sévérité du message.

Le comportement du syslogd original BSD est que tous les messages de la priorité précisée et au-dessus sont journalisés conformément à l’action donnée. Ce syslogd(8) se comporte de même, mais possède quelques extensions.

En plus des noms mentionnés ci-dessus, syslogd(8) comprend les extensions suivantes : un astérisque (« * ») remplace toutes les facility et toutes les priorités, en fonction de l’endroit où il est utilisé (avant ou après le point). Le mot-clé none signifie aucune priorité de la facility donnée.

Vous pouvez préciser de multiples facility avec le même modèle de priorité dans une seule déclaration en utilisant l’opérateur virgule (« , »). Vous pouvez préciser autant de facility que vous le souhaitez. Rappelez-vous que seule la partie facility d’une telle déclaration sera considérée, toute partie priorité sera omise [NdT : en dehors du modèle de priorité en fin de sélecteur].

De multiples sélecteurs peuvent être précisés pour une unique action en utilisant le séparateur point-virgule (« ; »). Rappelez-vous que chaque sélecteur dans le champ selector est capable d’outrepasser les précédents. En utilisant cette méthode vous pouvez exclure des priorités du modèle.

Ce syslogd(8) dispose d’une extension de syntaxe par rapport au source original BSD, qui rend son utilisation plus intuitive. Vous pouvez précéder chaque priorité avec le signe égal (« = ») pour préciser cette priorité unique et non celles au-dessus. Vous pouvez aussi (les deux sont valides aussi) précéder la priorité avec un point d’exclamation (« ! ») pour ignorer cette priorité, soit exactement celle-ci, soit celle-ci et celles au-dessus. Si vous utilisez les deux extensions, le point d’exclamation doit apparaître avant le signe égal, de façon intuitive.

ACTIONS

Le champ action d’une règle concrétise le nom abstrait de « journal ». Un « journal » ne nécessite pas en fait d’être un véritable fichier. Syslogd(8) permet les actions suivantes.

Fichier Régulier Typiquement les messages sont journalisés dans de véritables fichiers. Le fichier doit être précisé par son chemin absolu, commençant par un slash « / ».

Vous pouvez précéder chaque entrée avec le signe moins « – » pour ne pas synchroniser le fichier après chaque journalisation. Remarquez que vous pouvez alors perdre des informations si le système se crashe juste après une tentative d’écriture. Cependant vous pouvez gagner en retour quelques performances, spécialement si vous exécutez des programmes qui utilisent la journalisation de manière très verbeuse.

Tubes Nommés Cette version de syslogd(8) 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(1) avant que syslogd(8) ne soit lancé.

Terminal et Console Si le fichier que vous précisez est un terminal [NdT : tty], une manipulation spéciale du terminal est effectuée, de la même façon pour /dev/console.

Machine Distante Ce syslogd(8) fournit une journalisation distante complète, c’est-à-dire qu’il est capable d’envoyer les messages à un hôte distant exécutant syslogd(8) et de recevoir les messages d’hôtes distants. L’hôte distant ne retransmettra plus le message, et ne pourra que le journaliser localement. Pour retransmettre les messages vers un autre hôtes, préfixez le nom d’hôte par le signe arobase (« @ »).

En utilisant cette possibilité vous serez à même de contrôler tous les messages syslog sur un hôte, si toutes les autres machines journalisent vers lui. Ceci dissipe tous les besoins d’administration.

Liste d’Utilisateurs Généralement les messages critiques sont aussi redirigés vers « root » sur une machine. Vous pouvez préciser une liste d’utilisateurs qui recevront les messages en écrivant simplement leur login. Vous pouvez préciser plus d’un utilisateur en les séparant par des virgules (« , »). S’ils sont connectés ils recevront le message. Ne croyez pas qu’un courriel sera envoyé, cela pourrait être trop tard.

Tous les Utilisateurs Connectés Les messages d’urgence sont souvent envoyés à tous les utilisateurs connectés pour les prévenir que quelque chose d’étrange se produit sur le système. Pour préciser cette capacité wall(1) utilisez un astérisque (« * »).

EXEMPLES

Voici quelques exemples, en partie tirés d’un site et d’une configuration existants. Par chance ils répondent à toutes les questions de configuration, si certaines demeurent, touchez-en un mot à Joey.


# Stocke tout ce qui est critique dans critical
#
*.=crit;kern.none /var/adm/critical

Ceci stockera tous les messages de priorité crit dans le fichier /var/adm/critical, sauf pour les messages noyau.


# Les messages noyau sont tout d'abord stockés dans
# le fichier kernel, les messages critiques et au-dessus
# sont retransmis vers un autre hôte et vers
# la console
#
kern.* /var/adm/kernel
kern.crit @finlandia
kern.crit /dev/console
kern.info;kern.!err /var/adm/kernel-info

- La première règle dirige tous les messages de facility kernel vers le fichier /var/adm/kernel.
- La seconde déclaration dirige tous les messages noyau de priorité crit et au-dessus vers l’hôte distant finlandia. Ceci est utile, car si l’hôte se crashe et que le disque subit des erreurs irréparables vous pourriez ne plus arriver à lire les messages stockés. S’ils sont aussi sur un hôte distant, vous pouvez encore essayer de trouver les raisons du crash.
- La troisième règle dirige ces même messages vers la console courante, aussi l’utilisateur qui travaille sur la machine les recevra, aussi.
- La quatrième ligne indique à syslogd de sauvegarder tous les messages noyau arrivant avec un priorité de info à warning dans le fichier /var/adm/kernel-info. Tout de err et au-dessus est exclu.


# Tcp wrapper journalise selon mail.info, nous affichons
# toute la connexion sur tty12
#
mail.=info /dev/tty12

Ceci dirige tous les messages utilisant mail.info (dans les sources LOG_MAIL | LOG_INFO) vers /dev/tty12, la 12ème console. Par exemple le tcp wrapper tcpd(8) utilise ceci par défaut.


# Stocke tout ce qui concerne le courriel dans
# le fichier mail
#
mail.*;mail.!=info /var/adm/mail

Ce modèle correspond à tous les messages arrivant avec la facility mail, sauf ceux de priorité info. Ils seront stockés dans le fichier /var/adm/mail.


# Journalise tout message mail.info ou news.info dans info
#
mail,news.=info /var/adm/info

Ceci extraira tous les messages arrivant avec soit mail.info soit news.info et les stockera dans le fichier /var/adm/info.


# Journalise les messages info et notice dans
# le fichier messages
#
*.=info;*.=notice;\
mail.none /var/log/messages

Ceci laissera syslogd journaliser tous les messages qui arrivent avec la priorité soit info soit notice dans le fichier /var/log/messages, sauf les messages qui utilisent la facility mail.


# Journalise les messages info dans le fichier messages
#
*.=info;\
mail,news.none /var/log/messages

Cette déclaration fait journaliser syslogd tous les messages arrivant avec la priorité info dans le fichier /var/log/messages. Mais tout message arrivant avec la facility soit mail soit news ne sera pas stocké.


# Les messages d'urgence seront affiché avec wall
#
*.=emerg *

Cette règle indique à syslogd d’envoyer tous les messages d’urgence à tous les utilisateurs connectés. C’est l’action de wall.


# Les messages de priorité alert seront dirigés
# vers les opérateurs
#
*.alert root,joey

Cette règle dirige tous les messages de priorité alert ou au-dessus vers les terminaux des opérateurs, c’est-à-dire des utilisateurs « root » et « joey » s’ils sont connectés.


*.* @finlandia

Cette règle redirigerait tous les messages vers un hôte distant nommé finlandia. Ceci est utile spécialement dans un cluster de machines où tous les messages syslog seront stockés sur une machine unique.

DIFFÉRENCES DE SYNTAXE DU FICHIER DE CONFIGURATION

Syslogd utilise pour son fichier de configuration une syntaxe légèrement différente des sources originales BSD. Originellement tous les messages d’une priorité précisée et au-dessus étaient envoyés vers le journal. Les modificateurs « = », « ! » et « – » ont été ajoutés pour rendre syslogd plus flexible et pour l’utiliser de manière plus intuitive.

Le syslogd BSD original ne comprenait pas les espaces comme des séparateurs entre les champs sélecteur et action.

FICHIERS

/etc/syslog.conf Fichier de configuration de syslogd

BUGS

Les effets de sélecteurs multiples ne sont pas toujours intuitifs. Par exemple « mail.crit,*.err » sélectionnera les messages de facility « mail » de priorité « err » et au-dessus, et non de priorité « crit » et au-dessus.

VOIR AUSSI

sysklogd(8), klogd(8), logger(1), syslog(2), syslog(3)

AUTEURS

Syslogd 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.

TRADUCTION

Laurent Hugé

AVERTISSEMENT SUR LA TRADUCTION

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.

http://www.delafond.org/traducmanfr/man/man8/sysklogd.8.html

Memo X serveur et Gnome

J’ai pas de tête, pas envie de m’encombrer la mémoire, mon site web est la pour cela ! Voici donc mon memo rapide d’installation de X server et de gnome pour une Debian woody.

J’ai installé une woody dans sa version minimum (sans utiliser taskselect et dselect) et je souhaite maintenant installer un serveur X et gnome facilement, rapidement [1] et toujours avec un minimum de pollution reportant à demain la configuration fine et performante.

Voici la recette :

Installation des paquages

  1. apt-get update
  2. apt-get upgrade
  3. apt-get install x-window-system-core gnome-session nautilus gnome-control center gnome-applets sawfish-gnome

Configuration des paquages

Vous allez maintenant configurer le serveur X avec debconf : il va vous poser une série de questions puis générer le fichier de configuration de XFree /etc/X11/XF86Config-4 :

La carte

  1. Divers : prendre VESA [2]
  2. Identifiant de la carte : la marque sa carte graphique.
  3. Entrez l’identifiant du bus de la carte vidéo : laisser le champs vide.
  4. Entrez la quantité de mémoire que va utiliser votre carte vidéo : laisser le champs vide.
  5. Utiliser l’interface framebuffer du noyau ? : Non.

Le clavier

  1. Choisir l’ensemble XKB à utiliser : saisir xfree86.
  2. Veuillez choisir votre type de clavier : pc105 (clavier standard avec les trois touches Windows en plus).
  3. Choisir la disposition de votre clavier : saisir fr
  4. Sélectionner la variante de votre clavier : laissez le champ vide.
  5. Sélectionner les options de votre clavier : laissez le champ vide.

La souris

  1. Indiquez le port de branchement de votre souris :

    • /dev/psaux pour une souris sur le port PS/2
    • /dev/input/mice pour une souris sur port USB.
  2. Sélectionner le protocole de la souris. Choisissez :

    • PS/2 si vous avez une souris de base,
    • ImPS/2 si vous avez une souris avec roulette.
  3. Emuler une souris 3 boutons ?

    • Si vous avez une souris 2 boutons, répondez Oui
    • si vous avez une souris avec 3 boutons ou plus, répondez Non.
  4. Activer le défilement avec la roulette ?
    • Si vous avez une souris avec roulette, répondez Oui.
    • Si non répondez Non.

L’écran

  1. Saisir un identifiant pour votre moniteur.
  2. Votre moniteur est-il de type LCD ? oui / non c’est facile.
  3. Ensuite viennnent les questions sur les réglages de l’écran. Si vous ne connaissez pas les spécifications techniques de votre écran, choisissez le mode Simple.
  4. Choisissez les modes vidéo que vous désirez utiliser pour le serveur X : cochez toutes les résolutions supportées par votre écran.
  5. Choisissez la profondeur de couleur par défaut : sélectionnez 24 bits.

Les modules

  1. Sélectionnez les modules du serveur XFree86 chargés par défaut : ne modifiez pas la liste.
  2. Mettre une section « Files » de référence dans la configuration ? : Oui.
  3. Mettre une section « DRI » de référence dans la configuration ? : répondez non (marche pas avec le driver vesa).

Le choix de Gnome

Configurer votre environnement pour utiliser Gnome. En temps que simple utilisateur, créez dans votre répertoire home un fichier .xsession contenant la commande gnome-session :
echo "gnome-session" > /home/votre_id/.xsession

Lancer X

  1. startx

Marche pas ? Recommencer !

Relancer la configuration avec la commande :

  1. dpkg-reconfigure xserver-xfree86

Documentation

Formation Alexis de Lattre
Guide Andesi
Manuel debian pour sarge
Reference debian fr


[1] Pour une réelle explication et une configuration performance voir la documentation car ceci n’est qu’un memo

[2] Pour une configuration performance avec le driver spécifique à votre voir la documentation ceci n’est qu’un memo(bis)