sysklogd − Utilitaires de journalisation du système Linux.

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

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.

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

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.

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

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.

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

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

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.

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.

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

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.

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

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

Laurent Hugé

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.