Utiliser syslogd pour centraliser les logs de machines distantes n'est pas toujours d'une grande facilité. La documentation n'est pas vraiment limpide et les exemples se font rares. Voici rapidement comment procéder pour centraliser des logs sur une machine sous FreeBSD 7.x.
Sur la machine qui reçoit les logs
Il faut remplir deux conditions : votre machine doit accepter les connexions à destination de syslogd, et ce dernier doit savoir quoi faire des données qu'il reçoit.
Pour dire à syslogd d'accepter les connexions venant du réseau, il suffit de modifier les paramètres de lancement dans le fichier /etc/rc.conf. Éditez ce fichier pour que la ligne syslogd_flags ressemble à ceci :
syslogd_flags="-c4C -a machine_distante"
Je vous renvoie au man syslogd pour la signification des options. Par exemple, si votre réseau est en IPv6, remplacer le 4 par un 6. "machine_distante" est le nom ou l'IP de la machine dont vous souhaitez centraliser les logs. Vous pouvez préciser plusieurs fois le paramètre -a, pour ajouter des machines, des netmasks...
Par défaut, syslogd n'accepte que les données qui proviennent d'une machine listée dans le -a, et dont le port distant est 514. Si vous souhaitez agréger des logs de machines sous Mac OS X Server par exemple, il vous faudra préciser le port "*", car ce système utilise un port non privilégié pour envoyer ses données :
syslogd_flags="-c4C -a machine_distante -a macosx_server:*"
Ensuite, il faut régler le contenu du fichier /etc/syslog.conf pour assigner une destination à chaque flux de log. Et c'est ici que la difficulté se trouve. Si on n'y prend garde, des données sont écrites dans de mauvais fichiers, d'autres ne sont pas écrites du tout.
Si les machines sont assez peu nombreuses, je recommande la simplicité : un bloc de définition = une machine. C'est plus verbeux, mais c'est aussi plus simple à corriger/modifier.
Un bloc consiste en une série d'instructions débutant par une définition de machine ou de programme (ou des deux). L'ordre doit toujours être :
- définition facultative de machine
- définition facultative de programe
- sélecteur et action
- ...
Pour éviter toute interférence entre deux blocs consécutifs, je recommande de placer à la fin de chaque bloc un "reset" pour la définition de machine. Voici un exemple :
1: +machine_distante 2: mail.info /var/log/maillog 3: +* 4: 5: +macosx_server 6: mail.* /var/log/maillog 7: local5.* /var/log/maillog 8: +* 9: 10: +@ 11: *.err;kern.warning;auth.notice;mail.crit /dev/console
Je suis ici tout au début de mon fichier /etc/syslog.conf. Ma première ligne indique que le bloc qui débute concerne les logs en provenance de la machine "machine_distante". Tout ce qui vient de cette machine, et qui appartient au sélecteur mail.info sera enregistré dans le fichier /var/log/maillog.
La troisième ligne fait un "reset" de la machine.
Ligne 5, j'ouvre un bloc qui concerne la machine "macosx_server". Lignes 6 et 7 je défini mes couples sélecteur/action, puis ligne 8 je ferme mon bloc avec un "reset".
Ligne 10, j'utilise le nom de machine @ qui représente la machine locale. Les lignes suivantes sont les couples sélecteur/action pour localhost.
Une fois tout ceci réglé, il vous suffit de relancer syslogd (en root) :
# /etc/rc.d/syslogd restart
Sur les machines qui envoient les logs
Pour finir, il reste à configurer le syslogd des machines distantes pour qu'ils envoient les données voulues vers votre serveur FreeBSD. À nouveau, je vous renvoie vers le man syslogd, qui à ce niveau est assez clair. Voici par exemple ce qu'il faut ajouter au fichier /etc/rc.conf d'un FreeBSD :
syslogd_flags="-cs"
Cela permet à syslogd de parler sur le réseau, sans l'autoriser pour autant à recevoir des connexions venant de l'extérieur.
Puis dans le fichier /etc/syslog.conf, on indique simplement les sélecteurs que l'on souhaite envoyer vers le serveur. Par exemple, ces deux lignes indiquent que je veux écrire les logs de mail.info en local et sur la machine distante "serveur_syslogd" :
mail.info /var/log/maillog mail.info @serveur_syslogd
Relancez le syslogd de la machine dont vous modifier la configuration, assurez vous bien sûr que les firewall laissent passer le trafic qui vous intéresse, et tout devrait fonctionner.
Si ça coince
Si ça ne fonctionne pas, vous avez deux outils pour trouver le point de blocage. Le premier outil est tcpdump. Il vous aidera rapidement à voir ce qui sort d'une machine et ce qui arrive à l'autre. Par exemple, sur le serveur de log :
# tcpdump -A src or dst host machine_distante and port syslog
Cette commande vous permet de vérifier que les paquets venant de machine_distante vous parviennent bien sur le port 514. La commande suivante permet de vérifier, sur "machine_distante" que les paquets à destination de serveur_syslogd tentent bien de sortir :
# tcpdump -A src or dst host serveur_syslogd and port syslog
Si les deux commandes donnent satisfaction, alors la connexion entre les deux machines est bonne, et le problème ne vient pas d'un éventuel firewall.
Le second outil qui dépanne, c'est l'option -d de syslogd : le mode debug. Ajoutez ce paramètre à syslogd_flags dans votre rc.conf (sur la machine qui centralise les logs), et relancez syslogd. Après quelques lignes indigestes, les informations intéressantes arrivent. Voici un exemple :
1: cvthname(192.168.0.20) 2: validate: dgram from IP 192.168.0.20, port 514, name machine_distante; 3: accepted in rule 0. 4: logmsg: pri 26, flags 0, from machine_distante, msg ../.. 5: Logging to FILE /var/log/maillog 6: cvthname(192.168.0.20) 7: validate: dgram from IP 192.168.0.20, port 514, name machine_distante; 8: accepted in rule 0. 9: logmsg: pri 26, flags 0, from machine_distante, msg ../.. 10: Logging to FILE /var/log/maillog 11: cvthname(192.168.0.250) 12: validate: dgram from IP 192.168.0.250, port 50194, name macosx_server; 13: rejected in rule 0 due to port mismatch. 14: rejected in rule 1 due to port mismatch.
Lignes 1 à 10, on a deux exemples de trames correctement acceptées par notre agrégateur de log, et venant du port 514 de "machine_distante".
Lignes 11 à 14, on a un rejet de trame, venant du port 50194 de la machine "macosx_server". Sans doute avons-nous oublié d'indiquer :* comme port autorisé pour la machine "macosx_server" dans les options syslogd_flags.
Ici, le mode debug nous dit clairement où est notre erreur : rejected in rule 0 due to port mismatch.
Si vous avez un gros débit de log, coupez rapidement le mode debug (ctrl-c), supprimez le -d de votre syslogd_flags, et relancer syslogd. Vous aurez tous le temps d'analyser la trace ensuite.