Sysklogd fournit deux utilitaires système qui prennent en charge la journalisation du système et le recouvrement des messages du noyau. La prise en charge des sockets de domaine Internet et unix permet à cet utilitaire de prendre en charge la journalisation locale et distante.
La journalisation système est fournie par une version desyslogd(8) provenant des sources BSD du stock. La prise en charge de la journalisation du noyau est fournie par leKlogd(8) Utilitaire qui permet de consigner le noyau de manière autonome ou en tant que client de syslogd.
Syslogd fournit une sorte de journalisation utilisée par de nombreux programmes modernes. Chaque message enregistré contient au moins une heure et un champ de nom d’hôte, généralement un champ de nom de programme, mais cela dépend de la fiabilité du programme de journalisation.
Tandis que lesyslogd les sources ont été fortement modifiées quelques notes sont en ordre. Tout d'abord, il y a eu une tentative systématique de s'assurer que syslogd respecte son comportement BSD standard par défaut. Le deuxième concept important à noter est que cette version de syslogd interagit de manière transparente avec la version de syslog présente dans les bibliothèques standard. Si un fichier binaire lié aux bibliothèques partagées standard ne fonctionne pas correctement, nous voudrions un exemple du comportement anormal.
Le fichier de configuration principal /etc/syslog.conf ou un fichier alternatif, donné avec le-F option, est lu au démarrage. Toutes les lignes commençant par le signe dièse (`` # '') et les lignes vides sont ignorées. Si une erreur survient lors de l'analyse, toute la ligne est ignorée.
Synopsis
syslogd -une prise -ré -F fichier de configuration -h -l liste d'hôtes -m intervalle -n -p prise -r -s domainlist -v -X
Les options
-une prise
En utilisant cet argument, vous pouvez spécifier des sockets supplémentaires à partir de celui-ci.syslogd doit écouter. Cela est nécessaire si vous laissez un démon s'exécuter dans un environnement chroot (). Vous pouvez utiliser jusqu'à 19 prises supplémentaires. Si votre environnement a encore besoin de plus, vous devez augmenter le symboleMAXFUNIX dans le fichier source syslogd.c. Un exemple de démon chroot () est décrit par les utilisateurs d’OpenBSD à l’adresse http://www.psionic.com/papers/dns.html.
-ré
Active le mode débogage. En utilisant cela, le démon ne procédera pas àfourchette(2) pour se placer en arrière-plan, mais en face de cela, restez au premier plan et écrivez beaucoup d’informations de débogage sur le terminal en cours. Voir la section DÉBOGAGE pour plus d'informations.
-F fichier de configuration
Spécifiez un fichier de configuration alternatif au lieu de /etc/syslog.conf , qui est la valeur par défaut.
-h
Par défaut, syslogd ne transfère pas les messages qu'il reçoit des hôtes distants. Si vous spécifiez ce commutateur sur la ligne de commande, le démon de journal transfère tous les messages distants qu'il reçoit aux hôtes de transfert définis.
-l liste d'hôtes
Spécifiez un nom d'hôte à consigner uniquement avec son nom d'hôte simple et non pas le nom de domaine complet. Plusieurs hôtes peuvent être spécifiés à l'aide du séparateur de deux points (`:: '').
-m intervalle
lesyslogd enregistre un horodatage de la marque régulièrement. Le défaut intervalle entre deux -- MARQUE -- lignes est de 20 minutes. Cela peut être changé avec cette option. Réglage du intervalle à zéro l'éteint complètement.
-n
Évitez les arrière-plans automatiques. Cela est nécessaire surtout si lesyslogd est démarré et contrôlé parinit(8).
-p prise
Vous pouvez spécifier un autre socket de domaine Unix au lieu de / dev / log .
-r
Cette option permettra à l'installation de recevoir un message du réseau à l'aide d'un socket de domaine Internet avec le service syslog (voir (5)). La valeur par défaut est de ne recevoir aucun message du réseau.
Cette option est introduite dans la version 1.3 du paquet sysklogd. Veuillez noter que le comportement par défaut est le contraire de la façon dont les anciennes versions se comportent, vous devrez donc peut-être l'activer.
-s domainlist
Spécifiez un nom de domaine à supprimer avant la journalisation. Plusieurs domaines peuvent être spécifiés à l'aide du séparateur de deux points («::»). Veuillez noter qu'aucun sous-domaine ne peut être spécifié, mais uniquement des domaines entiers. Par exemple si-s north.de est spécifié et la journalisation de l'hôte résout satu.infodrom.north.de, aucun domaine ne serait coupé, vous devrez spécifier deux domaines comme:-s north.de:infodrom.north.de.
-v
Imprimer la version et quitter.
-X
Désactiver les recherches de noms lors de la réception de messages distants. Cela évite les blocages lorsque le serveur de noms est exécuté sur le même ordinateur que le démon syslog.
Des signaux
Syslogd réagit à un ensemble de signaux. Vous pouvez facilement envoyer un signal àsyslogd en utilisant ce qui suit:
kill -SIGNAL `cat / var / run / syslogd.pid`
Soupir
Cela permetsyslogd effectuer une réinitialisation. Tous les fichiers ouverts sont fermés, le fichier de configuration (par défaut /etc/syslog.conf ) sera relue et lesyslog(3) l'installation est redémarrée.
SIGTERM
lesyslogd mourront.
SIGINT, SIGQUIT
Si le débogage est activé, ceux-ci sont ignorés, sinonsyslogd mourront.
SIGUSR1
Activer / désactiver le débogage. Cette option ne peut être utilisée que sisyslogd est commencé avec le-ré option de débogage.
SIGCHLD
Attendez que des enfants soient nés, à cause de messages cachés.
Différences de syntaxe du fichier de configuration
Syslogd utilise une syntaxe légèrement différente pour son fichier de configuration par rapport aux sources BSD d'origine. À l'origine, tous les messages de priorité spécifique et supérieure étaient transférés au fichier journal.
Par exemple, la ligne suivante entraînait TOUTES les sorties des démons utilisant les fonctions du démon (debug étant la priorité la plus basse, donc toutes les commandes les plus hautes correspondent) / usr / adm / daemons :
# Exemple syslog.conf daemon.debug / usr / adm / daemons
Sous le nouveau schéma, ce comportement reste le même. La différence réside dans l’ajout de quatre nouveaux spécificateurs, l’astérisque (*) joker, le signe d’équation (=), le point d'exclamation (!) et le signe moins (-).
le* spécifie que tous les messages de l'installation spécifiée doivent être dirigés vers la destination. Notez que ce comportement est dégénéré avec la spécification d'un niveau de priorité de débogage. Les utilisateurs ont indiqué que la notation astérisque est plus intuitive.
le= Le caractère générique est utilisé pour limiter la journalisation à la classe de priorité spécifiée. Cela permet, par exemple, d'acheminer uniquement les messages de débogage vers une source de journalisation particulière.
Par exemple, la ligne suivante dans syslog.conf dirigerait les messages de débogage de toutes les sources vers le / usr / adm / debug fichier.
# Exemple de syslog.conf *. = Debug / usr / adm / debug
le! est utilisé pour exclure la journalisation des priorités spécifiées. Ceci affecte toutes les possibilités (!) De spécifier les priorités.
Par exemple, les lignes suivantes consigneraient tous les messages du courrier de la fonction, à l’exception de ceux avec les informations de priorité vers le destinataire. / usr / adm / mail fichier. Et tous les messages de news.info (y compris) à news.crit (à l'exclusion) seraient connectés à la / usr / adm / news fichier.
# Exemple de courrier syslog.conf. *; Mail.! = Info / usr / adm / mail news.info; news.! Crit / usr / adm / news
Vous pouvez l'utiliser intuitivement comme spécificateur d'exception. L'interprétation mentionnée ci-dessus est simplement inversée. Faire que vous pouvez utiliser
mail.none
ou
courrier.!*
ou
mail.! debug
pour ignorer tous les messages fournis avec une installation de messagerie. Il y a beaucoup de place pour jouer avec. :-)
le- ne peut être utilisé que pour préfixer un nom de fichier si vous souhaitez omettre la synchronisation du fichier après chaque écriture.
Cela peut prendre un peu d’acclimatation aux personnes habituées au comportement BSD pur, mais les testeurs ont indiqué que cette syntaxe est un peu plus souple que le comportement BSD. Notez que ces modifications ne devraient pas affecter la normesyslog.conf(5) fichiers. Vous devez spécifiquement modifier les fichiers de configuration pour obtenir le comportement amélioré.
Prise en charge de la journalisation à distance
Ces modifications fournissent un support réseau à la fonction syslogd. La prise en charge réseau signifie que les messages peuvent être transférés d’un nœud exécutant syslogd vers un autre nœud exécutant syslogd, où ils seront réellement consignés dans un fichier de disque.
Pour l'activer, vous devez spécifier le-r option sur la ligne de commande. Le comportement par défaut est quesyslogd n'écoute pas le réseau.
La stratégie consiste à ce que syslogd écoute sur un socket de domaine unix les messages de journal générés localement. Ce comportement permettra à syslogd d’interagir avec le syslog trouvé dans la bibliothèque C standard. Simultanément, syslogd écoute sur le port standard syslog les messages transférés depuis d'autres hôtes. Pour que cela fonctionne correctement leprestations de service(5) fichiers (généralement présents dans /etc ) doit avoir l'entrée suivante:
syslog 514 / udp
Si cette entrée est manquantesyslogd ni ne peuvent recevoir ni envoyer de messages distants, car le port UDP ne peut pas être ouvert. Au lieu, syslogd va mourir immédiatement, soufflant un message d'erreur.
Pour que les messages soient transférés à un autre hôte, remplacez la ligne de fichier normale dans le répertoire. syslog.conf fichier avec le nom de l'hôte auquel les messages doivent être envoyés, précédé d'un @.
Par exemple, pour transférerTOUT messages à un hôte distant en utilisant ce qui suit syslog.conf entrée:
# Exemple de fichier de configuration syslogd dans # messages à un hôte distant pour tout transférer. *. * @hostname
Tout transférernoyau messages à un hôte distant, le fichier de configuration serait le suivant:
# Exemple de fichier de configuration pour transférer tous # les messages du noyau à un hôte distant. kern. * @hostname
Si le nom d'hôte distant ne peut pas être résolu au démarrage, car il est possible que le serveur de noms ne soit pas accessible (il peut être démarré après syslogd), vous n'avez pas à vous inquiéter.Syslogd essaiera de résoudre le nom dix fois, puis se plaindra. Une autre possibilité pour éviter cela consiste à placer le nom d’hôte dans / etc / hosts .
À la normalesyslogds vous obtiendrez des boucles syslog si vous envoyez des messages d’un hôte distant au même hôte (ou plus compliqué à un troisième hôte qui le renvoie au premier, etc.). Dans mon domaine (Infodrom Oldenburg), nous en avons accidentellement un et nos disques se sont remplis du même message. :-(
Pour éviter cela ultérieurement, aucun message reçu d'un hôte distant n'est plus envoyé à un autre (ou au même) hôte distant. S'il y a des scénarios où cela n'a pas de sens, envoyez-moi une ligne (Joey).
Si l'hôte distant est situé dans le même domaine que l'hôte,syslogd est en cours d'exécution, seul le nom d'hôte simple sera consigné à la place de l'intégralité du nom de domaine complet.
Sur un réseau local, vous pouvez fournir un serveur de journalisation central pour conserver toutes les informations importantes sur un seul ordinateur. Si le réseau est constitué de différents domaines, vous n'avez pas à vous plaindre de la consignation de noms qualifiés complets au lieu de noms d'hôtes simples. Vous voudrez peut-être utiliser la fonctionnalité strip-domain-s de ce serveur. Vous pouvez dire lesyslogd supprimer plusieurs domaines autres que celui du serveur et consigner uniquement les noms d'hôte simples.
En utilisant le-l En option, il est également possible de définir des hôtes uniques en tant que machines locales. Cela entraîne également la consignation de leurs noms d’hôte simples, et non des noms de fichiers.
Le socket UDP utilisé pour transférer des messages vers des hôtes distants ou pour recevoir des messages de ceux-ci est ouvert uniquement lorsque cela est nécessaire. Dans les versions antérieures à la version 1.3-23, il était ouvert à chaque fois mais n'était pas ouvert pour la lecture ou le transfert, respectivement.
Sortie vers des canaux nommés (FIFO)
Cette version de syslogd prend en charge la journalisation de la sortie vers des canaux nommés (fifos). Un fifo ou un canal nommé peut être utilisé comme destination pour les messages de journal en ajoutant un symbole de pipy (`` | '') au nom du fichier. C'est pratique pour le débogage. Notez que le fifo doit être créé avec la commande mkfifo avant que syslogd ne soit démarré.
Le fichier de configuration suivant achemine les messages de débogage du noyau vers un fifo:
# Exemple de configuration pour acheminer les messages de débogage du noyau # UNIQUEMENT à / usr / adm / debug, qui est un canal # nommé. kern. = debug | / usr / adm / debug
Problèmes d'installation
Il y a probablement une considération importante lors de l'installation de cette version de syslogd. Cette version de syslogd dépend du formatage correct des messages par la fonction syslog. Le fonctionnement de la fonction syslog dans les bibliothèques partagées a changé quelque part dans la région de libc.so.4. 2-4 .n. Le changement spécifique consistait à mettre fin au message à zéro avant de le transmettre au / dev / log prise. Le bon fonctionnement de cette version de syslogd dépend de la terminaison nulle du message.
Ce problème se manifeste généralement si d'anciens fichiers binaires liés de manière statique sont utilisés sur le système. Les fichiers binaires utilisant les anciennes versions de la fonction syslog entraînent la journalisation des lignes vides suivies du message avec le premier caractère du message supprimé. Relier ces fichiers binaires à des versions plus récentes des bibliothèques partagées corrigera ce problème.
Les deuxsyslogd(8) et leKlogd(8) peut être exécuté à partir de init (8) ou démarré dans le cadre de la séquence rc. *. S'il est lancé depuis init l'option -n doit être défini, sinon, vous aurez des tonnes de démons syslog lancés. Ceci est dû au faitinit(8) dépend de l'ID de processus.
Menaces à la sécurité
Il est possible que le démon syslogd soit utilisé comme conduit pour une attaque par déni de service. Merci à John Morrison ([email protected]) de m'avoir averti de ce potentiel. Un programme non fiable (mer) pourrait très facilement submerger le démon syslogd avec des messages syslog, ce qui entraînerait une utilisation par les fichiers journaux de tout l'espace restant sur le système de fichiers. L'activation de la journalisation sur les sockets de domaine inet exposera naturellement un système à des risques extérieurs aux programmes ou aux utilisateurs de la machine locale.
Il existe plusieurs méthodes pour protéger une machine:
- Implémentez le pare-feu du noyau pour limiter les hôtes ou les réseaux ayant accès au socket 514 / UDP.
- La journalisation peut être dirigée vers un système de fichiers isolé ou non-racine qui, s'il est rempli, n'affectera pas la machine.
- Le système de fichiers ext2 peut être utilisé et peut être configuré pour limiter un certain pourcentage d'un système de fichiers à une utilisation par la racine uniquement.REMARQUE cela nécessitera que syslogd soit exécuté en tant que processus non root. NOTE AUSSI cela empêchera l'utilisation de la journalisation à distance car syslogd ne pourra pas se lier au socket 514 / UDP.
- La désactivation des sockets de domaine inet limitera les risques pour la machine locale.
- Utilisez l’étape 4 et si le problème persiste et qu’il n’est pas secondaire par rapport à un programme / démon non fiable, obtenez une tige de ventouse * d'environ 3,5 pieds (environ 1 mètre) et discutez avec l'utilisateur en question. Sucker rod déf. --- 3/4, 7/8 ou 1 pouce tige en acier trempé, filetée à chaque extrémité. Utilisation principale dans l'industrie pétrolière dans l'ouest du Dakota du Nord et dans d'autres endroits pour pomper le pétrole "aspiré" des puits de pétrole. Les utilisations secondaires concernent la construction de parcs d'engraissement pour le bétail et le traitement occasionnel d'un individu récalcitrant ou belligérant.
Débogage
Lorsque le débogage est activé en utilisant-ré option alorssyslogd sera très verbeux en écrivant une grande partie de ce qu’il fait sur stdout. Chaque fois que le fichier de configuration est relu et analysé, un tableau apparaît, correspondant à la structure de données interne. Ce tableau se compose de quatre champs:
nombre
Ce champ contient un numéro de série commençant par zéro. Ce nombre représente la position dans la structure de données interne (c'est-à-dire le tableau). Si un numéro est omis, il se peut qu'une erreur se produise dans la ligne correspondante. /etc/syslog.conf .
modèle
Ce champ est délicat et représente exactement la structure interne. Chaque colonne représente une installation (se référer àsyslog(3)). Comme vous pouvez le constater, il reste encore des installations laissées libres pour une utilisation antérieure, seules les installations les plus à gauche sont utilisées. Chaque champ d’une colonne représente les priorités (reportez-vous àsyslog(3)).
action
Ce champ décrit l'action particulière qui se produit chaque fois qu'un message correspondant au modèle est reçu. Se référer ausyslog.conf(5) page de manuel pour toutes les actions possibles.
arguments
Ce champ affiche des arguments supplémentaires pour les actions du dernier champ. Pour la journalisation de fichier, il s'agit du nom de fichier du fichier journal. pour la journalisation des utilisateurs, il s'agit d'une liste d'utilisateurs; pour la journalisation à distance, il s'agit du nom d'hôte de la machine à laquelle se connecter; pour la consignation de la console, c'est la console utilisée; pour l'enregistrement de tty, il s'agit du tty spécifié; mur n'a pas d'arguments supplémentaires.
Voir également
enregistreur(1), syslog(2), (5)
Collaborateurs
Syslogd provient de sources BSD, Greg Wettstein ([email protected]) a effectué le portage vers Linux, Martin Schulze ([email protected]) a corrigé quelques bugs et ajouté plusieurs nouvelles fonctionnalités.Klogda été écrit à l’origine par Steve Lord ([email protected]), Greg Wettstein a apporté d’importantes améliorations.
Dr. Greg WettsteinDéveloppement de Systèmes Enjelliques Division de la recherche en oncologie Installation de calculCentre de cancérologie Roger MarisFargo, ND[email protected] Stephen TweedieDépartement d'informatiqueUniversité d'Édimbourg, Ecosse[email protected] Juha Virtanen[email protected] Shane Alderton[email protected] Martin SchulzeInfodrom Oldenburg[email protected] Important: Utilisez le homme commande ( % homme ) pour voir comment une commande est utilisée sur votre ordinateur. Articles Liés
