Taille: 6381
Commentaire: Ajout des mises à jour du 9 décembre (4.0->4.1->4.2)
|
Taille: 13313
Commentaire: s/ragnarok/(thot|synonymes)/
|
Texte supprimé. | Texte ajouté. |
Ligne 1: | Ligne 1: |
= Description = Il s'agit d'un SUN XFIRE 2100, un serveur 1U avec un opteron 64bits et d'un disque SATA de 80 Go Ragnarok fonctionne sur [http://www.openbsd.org/ OpenBSD]. = Les services = * le wifi (à ne pas confondre avec le wiki) ; quelques infos supplémentaires sur WifiTechnique/OpenBsd. * devrait stocker les sauvegardes de pegase (à rediscuter de qui le gère) |
## page was renamed from CransTechnique/PanthéonServeurs/ServeurRagnarok <<TableOfContents>> Dans le but de rationaliser le stockage et l'accès aux logs, on souhaite mettre en place une structure centralisée de logs. Pour cela, on utilise un serveur maître (feu {{{ragnarok}}}, {{{vo}}} et le domU {{{log}}} pour les tests, et désormais {{{thot}}}). Celui-ci stockera à terme la grande majorité des logs fournis par les divers serveurs (ainsi que les bornes et switchs), via rsyslog en les stockant dans une base de données relationnelle. == Configuration basique du serveur maître == Les services installés dessus sont dédiés aux messages de logs des serveurs: * Rsyslog * Serveur PostgreSQL === Gestion des logs === Le serveur maître utilise rsyslog en tant que démon syslog. Le choix de rsyslog se justifie principalement par les fonctionnalités suivantes: * Mise en file d'attente lorsque l'archivage est impossible * Archivage direct dans une base PostgreSQL (via le paquet {{{rsyslog-pgsql}}}) * Support du protocole RELP d'envoi de log (paquet {{{rsyslog-relp}}}) qui apporte une réelle fiabilité par rapport au protocole syslog initial (autant en UDP qu'en TCP, voir [[http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html|les faiblesses du Syslog TCP]]) Afin de profiter de cette robustesse, il faut, lorsque c'est possible, migrer les autres serveurs sous Rsyslog afin de profiter de l'envoi des log vers le serveur centrale à l'aide du protocole RELP, mais aussi permettre la mise en file d'attente, pour un envoi ultérieur, lorsque le serveur est indisponible. Lorsque ceci est impossible, on se contente d'un envoi classique en UDP ou TCP (voir le cas des switchs et bornes wifi plus bas) ce qui peut occasionner des pertes. ==== Base PostgreSQL ==== On installe donc une base de données PostgreSQL "Syslog" sur le serveur maître avec un compte possédant les droits en écriture (pour {{{rsyslog}}}) et un compte limité pour la lecture. ## Quid de la création de la table ? Par défaut, la base possédait un encodage UTF-8. Des requêtes d'insertions contenant des chaînes dans un encodage différent provoquaient alors des crash inexpliqués du serveur et donc l'arrêt des enregistrements. Comme ce genre de messages ne peut être évité de manière sûre, il vaut mieux choisir un encodage passe-partout comme {{{SQL_ASCII}}}. Voici la marche à suivre pour convertir une base déjà créée: {{{ sudo -u postgres pg_dump -E SQL_ASCII Syslog > /tmp/Syslog.dump sudo -u postgres dropdb Syslog sudo -u postgres createdb -O rsyslog -T template0 -E SQL_ASCII Syslog sudo -u postgres psql -d Syslog -f Syslog.dump }}} Une fois la base créée, on crée le répertoire {{{/etc/rsyslog.d/}}} s'il n'existe pas (a priori, {{{rsyslog-psql}}} et {{{postfix}}} y ont déjà rajouté leurs fichiers de configuration). Ce dossier contient les fichiers de configurations qui sont automatiquement inclus par {{{rsyslog}}}. On préfixera nos fichiers de configurations par des nombres, afin de pouvoir jouer sur l'ordre d'inclusion et donc l'ordre dans lequel les messages sont filtrés. On y crée ainsi le fichier {{{52-listen_relp.conf}}}, que l'on va remplir ainsi : {{{ $ModLoad imrelp $InputRELPServerRun 20514 }}} La première ligne sert à charger le module de réception {{{RELP}}}, la seconde place le serveur central en écoute sur le port 20514 pour ce protocole, en attente de logs. On copie également {{{/usr/share/rsyslog-pgsql/rsyslog-pgsql.conf.template}}} vers {{{/etc/rsyslog.d/51-pgsql.conf}}} en renseignant les informations sur notre base de données. Cela fait, on relance rsyslog via la commande {{{sudo /etc/init.d/rsyslog restart}}}. === (Re)Configuration des serveurs === Parlons de la (re)configuration des serveurs clients, par exemple, whatsupdoc. On s'assure d'abord que le paquet gérant les logs est bien {{{rsyslog}}}. Par ailleurs, il faut installer {{{rsyslog-relp}}}, pour l'envoi des messages. Dans {{{/etc/rsyslog.d}}}, nous allons créer le fichier {{{50-send_relp.conf}}}, contenant les informations suivantes : {{{ $ModLoad omrelp *.* :omrelp:10.231.136.11:20514;RSYSLOG_ForwardFormat }}} La première ligne charge le module d'envoi des données en {{{RELP}}}, la seconde spécifie que tous les logs doivent être envoyés à {{{thot}}} (10.231.136.38), sur le port 20514, via le module {{{omrelp}}}, dans un format prédéfini ({{{RSYSLOG_ForwardFormat}}}). Il ne reste qu'à relancer rsyslog. === Pour les switchs === Les logs des switchs sont envoyés grâce au protocole syslog (en UDP), via la directive de configuration: {{{ logging 10.231.136.11 }}} Le serveur central doit donc également autoriser l'envoi de log via UDP, ce qui se réalise à l'aide d'un fichier supplémentaire ( ./rsyslog.d/53-listen_switches.conf ): {{{ $ModLoad imudp $UDPServerRun 514 $AllowedSender UDP, 127.0.0.1, *.adm.crans.org, 10.231.136.0/24 }}} On a quelques problèmes ouverts sur le champ fromhost enregistré dans la base pgsql: les ip des switchs sont utilisés au lieu de leur nom d'hôte. En désactivant, certaines directives de rsyslog, on arrive à enregistrer le nom d'hôte mais c'est alors les autres serveurs qui sont enregistrés par leur adresse IP ! NB: On utilise ici le protocole UDP, car c'est le seul disponible sur les switchs (probablement par soucis de légèreté). == Généralisation de la configuration via bcfg2 == On supposera ici que les modifications de bcfg2 se font via darcs, on notera donc / comme étant la racine du répertoire darcs bcfg2. L'idée est de généraliser proprement à l'ensemble du réseau ce qu'on a vu au dessus. Cela va donc impliquer aussi plus de lignes de configuration, pour avoir un système fiable (en cas de crash du serveur maître, du réseau, ou de postgres). Dans /Cfg/etc/rsyslog.d, créer le répertoire 50-send_relp.conf/, 51-pgsql.conf/, 52-listen_relp.conf/ et 53-listen_switches.conf/. Dans 50-send_relp.conf/, créer le fichier 50-send_relp.conf, et y mettre les lignes suivantes : {{{ # Fichier géré par BCFG2. Ne pas modifier localement $ModLoad omrelp # Module d'envoi des logs via le réseau, plus fiable que omtcp $WorkDirectory /var/log/spool # Dossier de travail par défaut, pour les clients rsyslog # En cas de plantage de la destination (ici thot), on met en RAM (puis dans des fichiers # temporaires, si la RAM est sollicitée au delà d'une limite "inconnue", placés dans le # répertoire de travail /var/log/spool) pour un envoi ultérieur $ActionQueueType LinkedList # Mode de travail asynchrone pour la mise en attente $ActionQueueFileName syslogfwd # Définit le nom des fichiers temporaires créés en cas de problème $ActionResumeRetryCount -1 # Si l'envoi vers le destinataire standard foire, on réessaye un peu plus tard, indéfiniment. $ActionQueueSaveOnShutdown on # Balance le contenu de la RAM dans un fichier en cas d'arrêt de rsyslog. *.* :omrelp:thot.adm.crans.org:20514;RSYSLOG_ForwardFormat # On envoie le log au serveur maître }}} Dans 51-pgsql.conf/, créer le fichier 51-pgsql.conf, et y mettre : {{{ # Fichier géré par BCFG2. Ne pas modifier localement # On log tout dans la base pgsql, sauf si on plante, auquel cas on fait de la magie, comme proposé sur # http://www.rsyslog.com/doc/rsyslog_reliable_forwarding.html $ModLoad ompgsql # Module d'envoi des logs à la base de donnée postgresql $WorkDirectory /var/spool/rsyslog/ # Dossier de travail pour le serveur. # En cas de plantage de postgres, ou d'arrêt de rsyslog, on met en RAM (puis dans des fichiers # temporaires, si la RAM est sollicitée au delà d'une limite "inconnue", placés dans le # répertoire de travail /var/spool/rsyslog) ce qui doit être envoyé à postgres quand il sera # joignable à nouveau $ActionQueueType LinkedList # Mode de travail asynchrone pour la mise en attente $ActionQueueFileName syslogfwd # Définit le nom des fichiers temporaires créés en cas de problème $ActionResumeRetryCount -1 # Si l'envoi vers le destinataire standard foire, on réessaye un peu plus tard, indéfiniment. $ActionQueueSaveOnShutdown on # Balance le contenu de la RAM dans un fichier en cas d'arrêt de rsyslog. *.* :ompgsql:localhost,Syslog,rsyslog,mot_de_passe_secret; # Balance la sauce dans postgres #On ne loggue plus dans les fichiers ce qui ne concerne pas le serveur local (ici {{{thot}}}). :fromhost, !isequal, "thot" ~ }}} Dans 52-listen_relp.conf/ créer le fichier 52-listen_relp.conf, et y mettre les lignes suivantes : {{{ # Fichier géré par BCFG2. Ne pas modifier localement $ModLoad imrelp # Module de réception RELP $InputRELPServerRun 20514 # Port d'écoute }}} Dans 53-listen_switches.conf/, créer le fichier 53-listen_switches.conf, et y mettre : {{{ # Fichier géré par BCFG2. Ne pas modifier localement # Réception en udp: pour les switchs seulement $ModLoad imudp # Module de réception UDP $UDPServerRun 514 # Port d'écoute $AllowedSender UDP, 127.0.0.1, *.adm.crans.org, 10.231.136.0/24 # On fait la liste des domaines et ip autorisés à envoyer des logs. }}} Dans /Bundler/, créer le fichier rsyslog.xml, et le remplir comme suit : {{{ <Bundle name="rsyslog" version="2.0"> <Service name="rsyslog"/> <Group name="rsyslog-server"> <ConfigFile name="/etc/rsyslog.d/52-listen_relp.conf"/> <ConfigFile name="/etc/rsyslog.d/53-listen_switches.conf"/> <ConfigFile name="/etc/rsyslog.d/51-pgsql.conf"/> <Package name="rsyslog-pgsql"/> <Directory name="/var/spool/rsyslog"/> </Group> <Group name="rsyslog-client"> <Group name="rsyslog-server" negate="true"> <ConfigFile name="/etc/rsyslog.d/50-send_relp.conf"/> <Action name="rsyslog-clean-sendrelp" /> <Directory name="/var/log/spool"/> </Group> </Group> <Package name="rsyslog-relp"/> </Bundle> }}} Dans /Metadata/, modifier le fichier groups.xml, on va modifier le groupe "thot" pour commencer, chercher dans le fichier l'occurence 'Group name="thot"', et y ajouter la ligne : {{{ <Group name="rsyslog-server"/> }}} Maintenant, on modifie le groupe "crans-common", chercher l'occurrence 'Group name="crans-common"', et y ajouter la ligne (là où il faut, histoire que le fichier reste lisible...) : {{{ <Group name="rsyslog-client"/> }}} Dans la portion services du fichier, dans la catégorie divers, rajouter deux nouveaux groupes : {{{ <Group name="rsyslog-server" comment="Serveur de centralisation des logs"> <Bundle name="rsyslog"/> </Group> <Group name="rsyslog-client" comment="Serveurs qui ne centralisent pas les logs (cpt Obvious inside)"> <Bundle name="rsyslog"/> </Group> }}} Enfin, dans /Rules/rules.xml, on rajoute ce qui suit : {{{ <Group name="rsyslog-server"> <Directory name="/var/spool/rsyslog" owner="root" group="adm" perms="0750"/> </Group> <Group name="rsyslog-client"> <Group name="rsyslog-server" negate="true"> <Directory name="/var/log/spool" owner="root" group="adm" perms="750"/> </Group> </Group> }}} À partir de là normalement, on peut enregistrer la configuration, et c'est terminé ! Terminé c'est-à-dire qu'il ne reste plus qu'à exécuter {{{bcfg2}}} sur les serveurs. == Pour les bornes WiFi == Les bornes wifi envoient leurs logs à {{{thot.crans.org}}} (les paquets UDP doivent donc être routés depuis le vlan WiFi) On peut tester l'envoi en redémarrant {{{syslogd}}} sur les bornes via la commande: {{{ killall syslogd; syslogd -R 138.231.148.1 -C16 }}} Pour une configuration plus pérenne, on modifie/rajoute les directives suivantes dans {{{/etc/config/system}}} (catégorie {{{config}}} du fichier) {{{ option log_ip 138.231.136.38 option log_type file option log_file /dev/null }}} Le serveur doit de plus être configuré pour recevoir ces logs UDP via un nouveau fichier dans {{{/etc/rsyslog.d}}}: {{{ $ModLoad imudp $UDPServerRun 514 $AllowedSender UDP, 127.0.0.1, 138.231.148.0/24 }}} Il est possible de transmettre les logs au routeur, qui fera alors office de relai (via rsyslog), ce qui était fait avant (les bornes envoyaient leurs messages à {{{gordon}}} qui les envoyait à son tour à {{{thot}}}). Cependant, le routage fonctionne tout aussi bien, et présente l'avantage d'être configuré dynamiquement. == Exploitation des données == === Les index === === Purge périodique de la base === === données utiles === |
Ligne 12: | Ligne 235: |
= Les mises à jour = Openbsd sort une mise à jour bi-annuelle, une en novembre, l'autre en mai. Chaque mise à jour se fait de version en version (3.8->3.9, 3.9->4.0). == 3.8 -> 3.9 == * Il y a eu des modifications locales (qui ont été reportés dans les nouveaux fichiers) dans les fichiers suivants : * {{{/etc/rc}}} (lancement de {{{named}}}, {{{isakmpd}}} et {{{httpd}}} avec {{{systrace}}}) * {{{/mtree/special}}} ({{{pf.conf}}} en 0644) * {{{/etc/rc.conf}}} (activation de {{{named}}}, {{{ntpd}}}, {{{isakmpd}}}, {{{dhcpd}}}, {{{httpd}}}, {{{nfs_server}}}, {{{amd}}}, {{{pf}}}, {{{portmap}}}, {{{syslogd}}} et paramètre {{{amd_dir}}}) * {{{/etc/ssh/sshd_config}}} (root peut se loguer) * {{{/etc/sysctl.conf}}} (forwarding... le chiffrement de la swap était activé, il ne l'est plus) * Par contre, il semblerait qu'aucune mise à jour de paquet n'ai pu se faire : il y a eu un tas d'erreurs du style : {{{ --- bzip2-1.0.3 ------------------- Couldn't delete /usr/local/lib/libbz2.so.10.3 (bad md5) Couldn't delete /usr/local/bin/bzip2 (bad md5) Couldn't delete /usr/local/bin/bzip2recover (bad md5) Couldn't delete /usr/local/lib/libbz2.a (bad md5) Files kept as partial-bzip2-1.0.3 package }}} Supprimer les paquets {{{partial-*}}}, et relancer la mise à jour résoud le problème : {{{ for u in $(pkg_info 2>/dev/null|awk '/^partial/{print $1}'); do pkg_delete $u; done pkg_add -ui -F update -F updatedepends }}} == 3.9 -> 4.0 == * Modifications locales : comme ci-dessus, plus : * {{{/etc/mail/aliases}}} (alias de {{{root}}} vers {{{root@crans.org}}}) * {{{/etc/rc.local}}} (on conserve le fichier déjà en production) * Problèmes particuliers rencontrés lors de la mise à jour 3.8 -> 4.0 : * La sortie de la commande {{{netstat -r -f encap}}}, utilisée pour obtenir la liste des clients authentifiés en ipsec, a changé de format. Cela cassait le script whos pour les bornes. * La mise à jour de rsync vers la version 2.6.8, où les options {{{-D}}} et {{{--devices}}} ne sont plus équivalentes. La sauvegarde par backuppc ne fonctionnait plus : * Erreur côté pegase (backuppc) : {{{ Connected to 138.231.144.11:873, remote version 29 Connected to module slash Sending args: --server --sender --numeric-ids --perms --owner --group --devices --links --times --block-size=2048 --recursive --checksum-seed=32761 --one-file-system --exclude=lost+found --exclude=etc/wifi/wifi-update/*/retry --ignore-times . . Checksum caching enabled (checksumSeed = 32761) fileListReceive() failed Done: 0 files, 0 bytes Got fatal error during xfer (fileListReceive failed) Backup aborted (fileListReceive failed) }}} * Erreur côté ragnarok (rsyncd) : {{{ 2006/11/29 00:32:01 [11328] connect from pegase.adm.crans.org (138.231.144.18) 2006/11/29 00:32:02 [11328] rsync on . from backupcrans@pegase.adm.crans.org (138.231.144.18) 2006/11/29 00:32:02 [11328] rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32) 2006/11/29 00:32:02 [11328] rsync error: error in rsync protocol data stream (code 12) at /usr/obj/ports/rsync-2.6.8/rsync-2.6.8/io.c(1119) [sender=2.6.8] }}} Correction : remplacer {{{--devices}}} par {{{-D}}} dans la config de backuppc. == 4.0 -> 4.1 == * Modifications locales: * /etc/rc.conf: toutes les modifications locales sont à reporter dans un fichier /etc/rc.conf.local, car à partir de cette release le fichier rc.conf devient "immuable" et les changements doivent apportés dans le fichier /etc/rc.conf.local (déjà possible auparavant, maintenant considéré comme obligatoire par la procédure de mise à jour); les changements apportés à la configuration de base apparaissent ainsi plus facilement. * Après vérification, c'était déjà fait, il faut donc que ça dure. * /etc/rc: les changements à apporter à ce fichier sont triviaux à appliquer. * fait sans souci * /etc/mail/aliases: seul point à vérifier, le retrait définitif de /etc/aliases pour utiliser /etc/mail/aliases dans la configuration de base. * la vérification a été effectuée * La config de PF doit être checkée par rapport à la nouvelle config par défaut des règles stateful (en particulier en ce qui concerne IPsec). Le fichier pf.conf ne nécessitera pas beaucoup de changements (voir [http://openbsd.org/faq/upgrade41.html#apps]) * après vérification, le pf.conf n'a pas subi de modifications (l'IPsec fonctionne avec les règles stateful) * les autres modifications (droits 644 de /etc/pf.conf, les modif de rc.local, sysctl.conf et sshd_config) sont à reporter comme pour les versions précédentes. * fait * Mise à jour des paquets. * Problèmes : aucun. == 4.1 -> 4.2 == * Rien de spécial quant aux modifications locales des fichiers, les changements ont été apportés sans accrocs. * Mise à jour des paquets : * Suite à [http://www.openbsd.org/faq/upgrade42.html#libexpat une erreur d'évaluation des développeurs OpenBSD], la bibliothèque expat (parser XML, une des dépendances de python entre autres) est passée (pour cette release uniquement, en effet expat fera partie de base43.tgz) dans l'archive xbase42.tgz. Cette archive a donc été installée en plus des classiques autres, et le paquet expat-2.0.0 supprimé. Apparemment la transition s'est faite sans accroc. * Comme précédemment, aucun autre changement de format n'est annoncé pour les divers logs que nous utilisons, mais vigilance. == 4.2 -> 4.3 (futur) == On va peut-être attendre qu'elle sorte... :) = Histoire = Il s'agit du premier serveur SUN acheté par le CRANS. C'est aussi le premier serveur qui peut être stocké dans une armoire de switchs. Il est assez surprenant de par sa conception et aussi très étonnant quant à son silence de fonctionnement. ---- * CatégorieCrans/PageNonTerminée : Faire le point sur les différents éléments |
CatégoriePagePublique |
Sommaire
Dans le but de rationaliser le stockage et l'accès aux logs, on souhaite mettre en place une structure centralisée de logs. Pour cela, on utilise un serveur maître (feu ragnarok, vo et le domU log pour les tests, et désormais thot). Celui-ci stockera à terme la grande majorité des logs fournis par les divers serveurs (ainsi que les bornes et switchs), via rsyslog en les stockant dans une base de données relationnelle.
Configuration basique du serveur maître
Les services installés dessus sont dédiés aux messages de logs des serveurs:
- Rsyslog
- Serveur PostgreSQL
Gestion des logs
Le serveur maître utilise rsyslog en tant que démon syslog. Le choix de rsyslog se justifie principalement par les fonctionnalités suivantes:
- Mise en file d'attente lorsque l'archivage est impossible
Archivage direct dans une base PostgreSQL (via le paquet rsyslog-pgsql)
Support du protocole RELP d'envoi de log (paquet rsyslog-relp) qui apporte une réelle fiabilité par rapport au protocole syslog initial (autant en UDP qu'en TCP, voir les faiblesses du Syslog TCP)
Afin de profiter de cette robustesse, il faut, lorsque c'est possible, migrer les autres serveurs sous Rsyslog afin de profiter de l'envoi des log vers le serveur centrale à l'aide du protocole RELP, mais aussi permettre la mise en file d'attente, pour un envoi ultérieur, lorsque le serveur est indisponible.
Lorsque ceci est impossible, on se contente d'un envoi classique en UDP ou TCP (voir le cas des switchs et bornes wifi plus bas) ce qui peut occasionner des pertes.
Base PostgreSQL
On installe donc une base de données PostgreSQL "Syslog" sur le serveur maître avec un compte possédant les droits en écriture (pour rsyslog) et un compte limité pour la lecture.
Par défaut, la base possédait un encodage UTF-8. Des requêtes d'insertions contenant des chaînes dans un encodage différent provoquaient alors des crash inexpliqués du serveur et donc l'arrêt des enregistrements. Comme ce genre de messages ne peut être évité de manière sûre, il vaut mieux choisir un encodage passe-partout comme SQL_ASCII. Voici la marche à suivre pour convertir une base déjà créée:
sudo -u postgres pg_dump -E SQL_ASCII Syslog > /tmp/Syslog.dump sudo -u postgres dropdb Syslog sudo -u postgres createdb -O rsyslog -T template0 -E SQL_ASCII Syslog sudo -u postgres psql -d Syslog -f Syslog.dump
Une fois la base créée, on crée le répertoire /etc/rsyslog.d/ s'il n'existe pas (a priori, rsyslog-psql et postfix y ont déjà rajouté leurs fichiers de configuration). Ce dossier contient les fichiers de configurations qui sont automatiquement inclus par rsyslog. On préfixera nos fichiers de configurations par des nombres, afin de pouvoir jouer sur l'ordre d'inclusion et donc l'ordre dans lequel les messages sont filtrés. On y crée ainsi le fichier 52-listen_relp.conf, que l'on va remplir ainsi :
$ModLoad imrelp $InputRELPServerRun 20514
La première ligne sert à charger le module de réception RELP, la seconde place le serveur central en écoute sur le port 20514 pour ce protocole, en attente de logs. On copie également /usr/share/rsyslog-pgsql/rsyslog-pgsql.conf.template vers /etc/rsyslog.d/51-pgsql.conf en renseignant les informations sur notre base de données. Cela fait, on relance rsyslog via la commande sudo /etc/init.d/rsyslog restart.
(Re)Configuration des serveurs
Parlons de la (re)configuration des serveurs clients, par exemple, whatsupdoc. On s'assure d'abord que le paquet gérant les logs est bien rsyslog. Par ailleurs, il faut installer rsyslog-relp, pour l'envoi des messages. Dans /etc/rsyslog.d, nous allons créer le fichier 50-send_relp.conf, contenant les informations suivantes :
$ModLoad omrelp *.* :omrelp:10.231.136.11:20514;RSYSLOG_ForwardFormat
La première ligne charge le module d'envoi des données en RELP, la seconde spécifie que tous les logs doivent être envoyés à thot (10.231.136.38), sur le port 20514, via le module omrelp, dans un format prédéfini (RSYSLOG_ForwardFormat). Il ne reste qu'à relancer rsyslog.
Pour les switchs
Les logs des switchs sont envoyés grâce au protocole syslog (en UDP), via la directive de configuration:
logging 10.231.136.11
Le serveur central doit donc également autoriser l'envoi de log via UDP, ce qui se réalise à l'aide d'un fichier supplémentaire ( ./rsyslog.d/53-listen_switches.conf ):
$ModLoad imudp $UDPServerRun 514 $AllowedSender UDP, 127.0.0.1, *.adm.crans.org, 10.231.136.0/24
On a quelques problèmes ouverts sur le champ fromhost enregistré dans la base pgsql: les ip des switchs sont utilisés au lieu de leur nom d'hôte. En désactivant, certaines directives de rsyslog, on arrive à enregistrer le nom d'hôte mais c'est alors les autres serveurs qui sont enregistrés par leur adresse IP !
NB: On utilise ici le protocole UDP, car c'est le seul disponible sur les switchs (probablement par soucis de légèreté).
Généralisation de la configuration via bcfg2
On supposera ici que les modifications de bcfg2 se font via darcs, on notera donc / comme étant la racine du répertoire darcs bcfg2. L'idée est de généraliser proprement à l'ensemble du réseau ce qu'on a vu au dessus. Cela va donc impliquer aussi plus de lignes de configuration, pour avoir un système fiable (en cas de crash du serveur maître, du réseau, ou de postgres).
Dans /Cfg/etc/rsyslog.d, créer le répertoire 50-send_relp.conf/, 51-pgsql.conf/, 52-listen_relp.conf/ et 53-listen_switches.conf/. Dans 50-send_relp.conf/, créer le fichier 50-send_relp.conf, et y mettre les lignes suivantes :
# Fichier géré par BCFG2. Ne pas modifier localement $ModLoad omrelp # Module d'envoi des logs via le réseau, plus fiable que omtcp $WorkDirectory /var/log/spool # Dossier de travail par défaut, pour les clients rsyslog # En cas de plantage de la destination (ici thot), on met en RAM (puis dans des fichiers # temporaires, si la RAM est sollicitée au delà d'une limite "inconnue", placés dans le # répertoire de travail /var/log/spool) pour un envoi ultérieur $ActionQueueType LinkedList # Mode de travail asynchrone pour la mise en attente $ActionQueueFileName syslogfwd # Définit le nom des fichiers temporaires créés en cas de problème $ActionResumeRetryCount -1 # Si l'envoi vers le destinataire standard foire, on réessaye un peu plus tard, indéfiniment. $ActionQueueSaveOnShutdown on # Balance le contenu de la RAM dans un fichier en cas d'arrêt de rsyslog. *.* :omrelp:thot.adm.crans.org:20514;RSYSLOG_ForwardFormat # On envoie le log au serveur maître
Dans 51-pgsql.conf/, créer le fichier 51-pgsql.conf, et y mettre :
# Fichier géré par BCFG2. Ne pas modifier localement # On log tout dans la base pgsql, sauf si on plante, auquel cas on fait de la magie, comme proposé sur # http://www.rsyslog.com/doc/rsyslog_reliable_forwarding.html $ModLoad ompgsql # Module d'envoi des logs à la base de donnée postgresql $WorkDirectory /var/spool/rsyslog/ # Dossier de travail pour le serveur. # En cas de plantage de postgres, ou d'arrêt de rsyslog, on met en RAM (puis dans des fichiers # temporaires, si la RAM est sollicitée au delà d'une limite "inconnue", placés dans le # répertoire de travail /var/spool/rsyslog) ce qui doit être envoyé à postgres quand il sera # joignable à nouveau $ActionQueueType LinkedList # Mode de travail asynchrone pour la mise en attente $ActionQueueFileName syslogfwd # Définit le nom des fichiers temporaires créés en cas de problème $ActionResumeRetryCount -1 # Si l'envoi vers le destinataire standard foire, on réessaye un peu plus tard, indéfiniment. $ActionQueueSaveOnShutdown on # Balance le contenu de la RAM dans un fichier en cas d'arrêt de rsyslog. *.* :ompgsql:localhost,Syslog,rsyslog,mot_de_passe_secret; # Balance la sauce dans postgres #On ne loggue plus dans les fichiers ce qui ne concerne pas le serveur local (ici {{{thot
).:fromhost, !isequal, "thot" ~ }}}
Dans 52-listen_relp.conf/ créer le fichier 52-listen_relp.conf, et y mettre les lignes suivantes :
# Fichier géré par BCFG2. Ne pas modifier localement $ModLoad imrelp # Module de réception RELP $InputRELPServerRun 20514 # Port d'écoute
Dans 53-listen_switches.conf/, créer le fichier 53-listen_switches.conf, et y mettre :
# Fichier géré par BCFG2. Ne pas modifier localement # Réception en udp: pour les switchs seulement $ModLoad imudp # Module de réception UDP $UDPServerRun 514 # Port d'écoute $AllowedSender UDP, 127.0.0.1, *.adm.crans.org, 10.231.136.0/24 # On fait la liste des domaines et ip autorisés à envoyer des logs.
Dans /Bundler/, créer le fichier rsyslog.xml, et le remplir comme suit :
<Bundle name="rsyslog" version="2.0"> <Service name="rsyslog"/> <Group name="rsyslog-server"> <ConfigFile name="/etc/rsyslog.d/52-listen_relp.conf"/> <ConfigFile name="/etc/rsyslog.d/53-listen_switches.conf"/> <ConfigFile name="/etc/rsyslog.d/51-pgsql.conf"/> <Package name="rsyslog-pgsql"/> <Directory name="/var/spool/rsyslog"/> </Group> <Group name="rsyslog-client"> <Group name="rsyslog-server" negate="true"> <ConfigFile name="/etc/rsyslog.d/50-send_relp.conf"/> <Action name="rsyslog-clean-sendrelp" /> <Directory name="/var/log/spool"/> </Group> </Group> <Package name="rsyslog-relp"/> </Bundle>
Dans /Metadata/, modifier le fichier groups.xml, on va modifier le groupe "thot" pour commencer, chercher dans le fichier l'occurence 'Group name="thot"', et y ajouter la ligne :
<Group name="rsyslog-server"/>
Maintenant, on modifie le groupe "crans-common", chercher l'occurrence 'Group name="crans-common"', et y ajouter la ligne (là où il faut, histoire que le fichier reste lisible...) :
<Group name="rsyslog-client"/>
Dans la portion services du fichier, dans la catégorie divers, rajouter deux nouveaux groupes :
<Group name="rsyslog-server" comment="Serveur de centralisation des logs"> <Bundle name="rsyslog"/> </Group> <Group name="rsyslog-client" comment="Serveurs qui ne centralisent pas les logs (cpt Obvious inside)"> <Bundle name="rsyslog"/> </Group>
Enfin, dans /Rules/rules.xml, on rajoute ce qui suit :
<Group name="rsyslog-server"> <Directory name="/var/spool/rsyslog" owner="root" group="adm" perms="0750"/> </Group> <Group name="rsyslog-client"> <Group name="rsyslog-server" negate="true"> <Directory name="/var/log/spool" owner="root" group="adm" perms="750"/> </Group> </Group>
À partir de là normalement, on peut enregistrer la configuration, et c'est terminé ! Terminé c'est-à-dire qu'il ne reste plus qu'à exécuter bcfg2 sur les serveurs.
Pour les bornes WiFi
Les bornes wifi envoient leurs logs à thot.crans.org (les paquets UDP doivent donc être routés depuis le vlan WiFi) On peut tester l'envoi en redémarrant syslogd sur les bornes via la commande:
killall syslogd; syslogd -R 138.231.148.1 -C16
Pour une configuration plus pérenne, on modifie/rajoute les directives suivantes dans /etc/config/system (catégorie config du fichier)
option log_ip 138.231.136.38 option log_type file option log_file /dev/null
Le serveur doit de plus être configuré pour recevoir ces logs UDP via un nouveau fichier dans /etc/rsyslog.d:
$ModLoad imudp $UDPServerRun 514 $AllowedSender UDP, 127.0.0.1, 138.231.148.0/24
Il est possible de transmettre les logs au routeur, qui fera alors office de relai (via rsyslog), ce qui était fait avant (les bornes envoyaient leurs messages à gordon qui les envoyait à son tour à thot). Cependant, le routage fonctionne tout aussi bien, et présente l'avantage d'être configuré dynamiquement.
Exploitation des données
Les index
Purge périodique de la base