Distribution EOLE

h1. Gestion des journaux

Les objectifs fondamentaux de la journalisation sont les suivants :

* conserver l'information en vue d'établir des diagnostics de panne,

* conserver l'information en vue de statistiques d'utilisation,

* conserver l'information par contrainte légale.

Les écueils à éviter sont les suivants :

* saturation de la partition stockant les journaux,

* compromission des informations des journaux par application de droits d'accès inadaptés.

Ces objectifs et écueils guident la politique de journalisation à mettre en place. Les contraintes les plus fortes sont l'obligation légale de conserver l'information et le risque de saturation du support de stockage. Les journaux, ou partie de journaux, concernés par l'obligation légale doivent être traités prioritairement. Les autres doivent s'accomoder de la contrainte d'espace de stockage.

h2. Contextes de journalisation

La gestion des journaux d'une distribution EOLE est guidée par différents contextes d'utilisation. Un contexte d'utilisation est une topologie réseau particulière de machines, virtuelles ou physiques, à laquelle s'applique une politique de journalisation commune. Les rôles possibles dans un réseau sont :

* une machine émettrice : transmission des journaux à une machine réceptrice ;

* une machine réceptrice : conservation des journaux locaux, réception des journaux de machines émettrices.

Les machines émettrices se déclinent en matériel réseau, machines physiques et conteneurs lxc. Cette distinction introduit une distinction entre les machines réceptrices qui ne gèrent que les conteneurs qu'elles hébergent et celles qui centralisent les journaux de matériels physiques distants. Certains modules de la distribution EOLE se prêtent plus à l'exécution d'un rôle particulier. ZéphirLog, notamment a été créé pour assumer le rôle de machine réceptrice vis-à-vis des autres modules. Cependant, la modularité permet à un autre module de jouer ce rôle. L'utilisation du mode conteneur ou non est plus contraignant sur les rôles par contre.

h3. Solution EOLE en mode non conteneur

Une machine en mode non conteneur est le cas le plus simple :

* un seul environnement d'exécution ;

* la machine peut jouer les rôles de machine émettrice et transmettre ses journaux et de machine réceptrice et recevoir des journaux.

h3. Solution EOLE en mode conteneur

Une machine en mode conteneur amène un autre niveau :

* une hiérarchie d'environnement d'exécution à deux niveaux :

** un maître ;

** des conteneurs ;

* les conteneurs jouent le rôle de machines émettrices et transmettent leurs journaux ;

* les maîtres jouent forcément le rôle de machines réceptrices, au moins vis-à-vis des conteneurs, et peuvent jouer le rôle de machines émettrices et transmettre leurs journaux.

h3. Autre

Le reste du matériel participant au réseau (équipement réseau, machines clientes hors solutions EOLE, etc.) jouent le rôle de machines émettrices dans la structure envisagée.

h2. La problématique de la transmission réseau

Une machine réceptrice peut potentiellement recevoir de plusieurs sources : 

* des conteneurs ;

* des machines distantes pouvant utiliser le protocole RELP ;

* des machines distantes pouvant utiliser le protocole TCP ;

* des machines distantes pouvant utiliser le protocole UDP.

La transmission devant être fiable, le protocole RELP est à privilégier, ainsi que l'usage des queues, essentiellement pour les journaux à valeur légale. Le protocole TCP est encore incontournable pour l'utilisation d'une liaison sécurisée avec GnuTLS. Le protocole UDP est à réserver pour les équipements ne pouvant utiliser le protocole TCP ou RELP.

Il doit être possible de trier les journaux par zone émettrice. Différentes granularités sont envisageables pour définir les zones émettrices. La granularité la plus grossière distingue la zone interne (les conteneurs) de la zone externe.

h2. Les services

Les services prioritaires sont ceux dont les journaux ont une valeur légale et une durée de rétention prévue par la loi.

h2. La configuration de rsyslog dans EOLE

Le service rsyslog est démarré par défaut sur tous les modules EOLE, maître et conteneurs.

La configuration minimale est composée d'une partie commune et de fichiers de configuration rattachés aux différents services.

La stratégie d'aggrégation des journaux est décidée à l'instanciation.

h3. La configuration minimale

Sur le maître, sur un EOLE en mode non conteneur, un ensemble de règles pour dispatcher les journaux locaux.

Éventuellement, sur le maître, un ensemble de règles pour dispatcher les journaux des conteneurs (sinon mélangés aux journaux locaux).

Sur les conteneurs, des règles avec mise en place de queues pour les journaux sensibles et une règle globale pour le reste.

h3. L'aggrégation

L'aggrégation des journaux des conteneurs sur le maître est imposée.

Le choix du mode d'aggrégation porte sur :

* l'activation de l'envoi : spécification de l'adresse de destination, protocole imposé (RELP), port imposé (20515 ?) ;

* l'activation de la réception :

** réception de clients utilisant RELP : schéma de répartition, liste des adresses des clients, port imposé (20515 ?) ;

** réception de clients utilisant TCP : schéma de répartition, liste des adresses des clients, port imposé (10514 ?) ;

** réception de clients utilisant UDP : schéma de répartition, liste des adresses des clients, port imposé (514) ;

* utilisation du chiffrement : emplacement du certificat.

h3. L'organisation de la configuration

La lecture séquentielle de la configuration de rsyslog impose une organisation particulière :

* les modules (entrée, sortie) doivent être chargés avant d'être utilisés ;

* les ensembles de règles doivent être spécifiés avant d'être associés aux entrées ;

* les modèles doivent être spécifiés avant d'être utilisés ;

* les messages ne doivent pas être sortis de la chaîne de traitement prématurément.

h4. rsyslog.conf

<pre><code>

</code></pre>

h4. rsyslog.d/

00-aggregation.conf

<pre><code>

$ModLoad omrelp

$WorkDirectory /var/log/rsyslog/

$ActionQueueType LinkedList

%if %%is_defined('activate_squid_realtime') and %%activate_squid_realtime == "non"

$ActionQueueDequeueTimeBegin %%squid_heure_debut

$ActionQueueDequeueTimeEnd %%squid_heure_fin

%endif

$ActionQueueFileName relpact

$ActionQueueSaveOnShutdown on

:programname, isequal, 'squid' :omrelp:%%adresse_ip_br0:20514

& ~

*.*  :omrelp:%%adresse_ip_serveur_logs:20514

</code></pre>

00-conteneur.conf

<pre><code>

$ModLoad omrelp

$WorkDirectory /var/log/rsyslog/

$ActionQueueType LinkedList

%if %%is_defined('activate_squid_realtime') and %%activate_squid_realtime == "non"

$ActionQueueDequeueTimeBegin %%squid_heure_debut

$ActionQueueDequeueTimeEnd %%squid_heure_fin

%endif

$ActionQueueFileName relpact

$ActionQueueSaveOnShutdown on

:programname, isequal, 'squid' :omrelp:%%adresse_ip_br0:20514

& ~

*.*  :omrelp:%%adresse_ip_br0:20514

& ~

</code></pre>

10-erreurs.conf

<pre><code>

*.err  /var/log/syslog

</code></pre>

20-80….conf : les règles pour filter les services individuellement sur le modèle

<pre><code>

$template DynProgramme, "/var/log/rsyslog/%hostname%/%programname%/%programname%.%syslogseverity-text%.log"

:programname, isequal, "Programme"  ?DynProgramme

& ~

</code></pre>

Actuellement, les services qui disposent de règles spécifiques sont squid, charon, iptables, ufw, smbd, nmbd, named, exim4. Une règle générale peut être ajoutée pour traiter les autres cas. Ces règles personnalisées ne sont pas essentielles sauf dans le cas de fork (exemple de rsyslog qui ajoute le numéro de PID au nom de programme de ses différentes instances). Dans ce cas, il faut une règle avec une expression régulière ou startswith (ou utiliser la facility si elle est univoque).

<pre><code>

$template DynRsyslog, "/var/log/rsyslog/%hostname%/rsyslog/rsyslog.%syslogseverity-text%.log"

:programname, startswith, "rsyslog"  ?DynRsyslog

& ~

</code></pre>

99-general-dispatch.conf

$template DynProgramme, "/var/log/rsyslog/%hostname%/%programname%/%programname%.%syslogseverity-text%.log"

*.*  ?DynProgramme

h3. Utilisation des ensembles de règles

Les règles peuvent être regroupées et les groupes exécutées en fonction de la provenance des messages. La dissociation des ports pour les différentes sources permet d'exécuter des jeux de règles différents pour les messages originaires des conteneurs, de machines distantes ou les messages locaux.

Le protocole RELP ne bénéficie pas de la possibilité d'utiliser les ensembles de règles (la directive pour associer un ensemble donné à une connection RELP n'apparaît que dans la version 6.3.6 : la version prévue pour precise est la 5.8.6).

h2. L'arborescence typique

<pre>

/var/log/syslog

├── local

│   ├── exim

│   │   ├── exim.alert

│   │   ├── exim.info

│   │   └── exim.notice

│   └── smbd

│       ├── smbd.debug

│       └── smbd.info

└── remote

    ├── 10.11.12.13

    │   ├── aaa

    │   │   └── aaa.info

    │   └── ipsec

    │       └── ipsec.error

    ├── 15.16.17.18

    │   ├── apache2

    │   │   └── apache2.error

    │   └── kerberos

    │       └── kerberos.info

    └── sw12-4

        └── aaa

            └── aaa.info

</pre>

h2. Rotation des journaux

h3. Principes de logrotate

* options globales : des options peuvent être définies en début de fichier ;

* -overriding : les fichiers sont lus séquentiellement, celui qui parle en dernier à raison- ;

* gobbling : les règles spécifques peuvent utiliser le wildcard * (problème des redondances de règles cependant.

h3. Mise en œuvre de logrotate

Pour composer avec les contraintes de logrotate, on ajoute .log à la fin de chaque fihier. Cela permet d'utiliser le globbing sur un dossier en excluant les journaux archivés.