Mettant à jour l'ancienne description, voici la nouvelle
spécification du protocole syslog, protocole de
transmission d'informations sur les événements observés par un
système.
syslog est un très ancien protocole, qui,
comme souvent sur l'Internet,
n'avait pas été normalisé pendant longtemps. Seul l'examen des sources
du programme syslogd ou bien l'étude des paquets
passant sur le réseau, permettaient de décrire le protocole. Le
premier RFC à formaliser syslog était le , qui vient d'être remplacé par notre RFC. Au contraire de
son prédécesseur, qui décrivait l'existant, ce nouvel RFC et ses
compagnons normalisent un nouveau
protocole, en étendant l'ancien syslog, le BSD
syslog (l'annexe A.1 discute des différences entre les deux protocoles). Parmi les changements du nouveau protocole, notons une description
modulaire, qui sépare le format utilisé (qui fait l'objet de notre
RFC) du protocole utilisé pour le transport des données (voir par
exemple le ).
syslog sert à transmettre des rapports sur des événements survenus
dans un système. Le programme client (originator) qui signale les événements
transmet à un serveur syslog (collector), situé sur la même machine ou bien
ailleurs sur le réseau. Le serveur syslog, typiquement configuré sur
Unix via le fichier
/etc/syslog.conf va ensuite enregistrer ces
événements, par exemple dans un fichier comme
/var/log/mail.log. Ces fichiers, véritables
journaux de bord du système, permettent à
l'ingénieur de suivre tout ce qui se passe. On y trouvera des informations
telles que la date, le nom de la machine où à été noté l'événement, un
court texte décrivant celui-ci, etc. Par exemple :
Nov 29 21:18:11 ludwigVI dhcpd: DHCPREQUEST for 172.19.1.25 from 00:1c:23:00:6b:7f via eth0
où le serveur DHCP a signalé une requête pour
une adresse IP,
ou bien :
Nov 29 21:06:17 foobar named[2418]: lame server resolving 'oasc08a.247realmedia.com' (in 'oasc08a.247realmedia.com'?): 64.191.219.251#53
où le serveur de noms BIND note un problème
avec un domaine.
syslog est un immense succès. Non seulement tous les
démons Unix l'utilisent pour signaler les
événements qu'ils observent (tournant en permanence, sans console,
sans utilisateur qui les suit, ils n'ont que ce canal pour
communiquer) mais tout routeur, tout
commutateur réseau a aussi un client syslog,
qu'on peut configurer pour envoyer les messages à un serveur, souvent
Unix, qui écoute sur le réseau et note tout. (Avec
IOS, par exemple, cela se fait avec les commandes logging facility local3 - ou un autre service que local3 - et
logging 192.0.2.84 pour indiquer l'adresse IP du serveur syslog.)
On peut aussi utiliser syslog pour noter manuellement des événements qu'on détecte.
L'architecture complète peut être plus complexe qu'un simple
client/serveur, la section 4.1 donnant plusieurs exemples.
Rien ne garantit la bonne délivrance des messages, syslog est
typiquement unidirectionnel (les sections 5.1 et 8.5 discutent plus en
détail cette question).
La section 6 discute en détail du format des messages syslog,
format conçu pour rester compatible avec le précédent, tout en
permettant davantage de structuration (l'ancien format avait très peu
de structure et il était donc difficile d'en extraire automatiquement
des informations, par exemple pour le filtrage des événements avec un
programme comme Swatch). Le premier champ d'un
en-tête syslog, nommé PRI est écrit entre < et
> et code le service
(facility) et la gravité
(severity) du message. Le service indique quelle
partie du système a noté l'événements (2, le sous-système de courrier, 4,
la sécurité, etc). Notons que ce système est très rigide et ne permet
pas une grande finesse dans le classement. La gravité permet, elle, de distinguer les messages de
débogage (gravité 7), de simple information (gravité 6) et ainsi de
suite jusqu'aux
extrêmes urgences (gravité 0). Service et gravité sont encodés dans un
seul nombre en multipliant le premier par 8, donc, si j'émets un
message du service 16 (« usage local 0 ») avec une gravité de 3
(erreur), ici avec la commande logger :
% logger -p local0.error "Test syslog"
Le message sur le réseau commencerait par <131>
(16 * 8 + 3).
L'en-tête permet ensuite d'indiquer le numéro de version de syslog,
la date, le nom de la machine émettrice, le nom de l'application
(logger, cité plus haut, met par défaut le nom de
l'utilisateur), un numéro qui peut identifier une instance de
l'application (sur Unix, c'est typiquement le numéro de processus mais
le RFC note à juste titre que ce champ ne peut pas avoir de
signification standard)...
Une nouveauté de ce RFC est la présence de données structurées,
après l'en-tête et avant le message. Ces données sont formatées de
telle façon qu'un serveur syslog de l'ancien protocol peut toujours
les traiter comme du texte. Elles s'écrivent sous forme de doublets
attribut-valeur placés entre crochets. Les noms d'attributs possibles
sont décrits dans la section 7 et font l'objet d'un registre IANA (section 9.2). Un exemple est [meta
language="fr"] pour indiquer que le texte est en français
ou bien [timeQuality tzKnown="1" isSynced="1"]
pour indiquer que la machine qui a émis le message connait son fuseau
horaire et que son horloge est synchronisée, par exemple par
NTP.
Enfin, le message se termine par du texte libre, encodé en
UTF-8. Le RFC cite ainsi comme exemple un
message complet avec son en-tête :
1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8
]]>
syslog étant un protocole assez primitif, fonctionnant souvent sur
le simple UDP, il n'est pas étonnant qu'il aie
connu quelques problèmes de sécurité et que la section 8, consacrée à
ce sujet, soit très détaillée. Parmi les nombreuses questions
discutées, on peut citer par exemple le rejeu (section 8.4), contre
lequel syslog n'a pas de protection, l'absence de garantie de
délivrance des messages (section 8.5, qui note qu'on peut avoir de
bonnes raisons de ne pas vouloir cette garantie), l'absence de
contrôle de congestion, qui rend possible une noyade d'une machine
sous les messages syslog (section 8.6), etc.
Une mise en œuvre comme rsyslog gère les principales
nouveautés de ce RFC (comme le transport sur TCP, avec ou sans TLS).