Content-type: text/html
Manpage of SYSKLOGD
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 omettre 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.
Index
- NOM
-
- SYNOPSIS
-
- DESCRIPTION
-
- OPTIONS
-
- SIGNAUX
-
- DIFFÉRENCES DE SYNTAXE DU FICHIER DE CONFIGURATION
-
- SUPPORT DE LA JOURNALISATION DISTANTE
-
- ÉCRITURE DANS LES TUBES NOMMÉS (FIFOs)
-
- PROBLÈMES D'INSTALLATION
-
- MENACES DE SÉCURITÉ
-
- DÉBUGAGE
-
- FICHIERS
-
- BUGS
-
- VOIR AUSSI
-
- COLLABORATEURS
-
- TRADUCTION
-
- AVERTISSEMENT SUR LA TRADUCTION
-
This document was created by
man2html,
using the manual pages.
Time: 20:26:58 GMT, July 10, 2005