Rôle Ansible : Rsyslog

Installe et configure rsyslog sur les serveurs Debian/Ubuntu.

Ce rôle installe et configure la dernière version de rsyslog à partir du dépôt APT officiel (sur Debian) ou de PPA officiel (sur Ubuntu). Par défaut, il prendra le contrôle du contenu des fichiers /etc/rsyslog.conf et /etc/rsyslog.d/50-default.conf.

Exigences

Aucune.

Variables du rôle

Voici les variables disponibles avec leurs valeurs par défaut (comme dans defaults/main.yml) :

rsyslog_rules: []

Un tableau de règles pour rsyslog. Chaque entrée créera un fichier de configuration séparé nommé $priority-$rule_name.conf. Assurez-vous de vérifier defaults/main.yml pour des exemples commentés avec toutes les options disponibles.

rsyslog_rules:
  - rule_name: "remote-udp"
    priority: 99
    ruleset: |
      module(load="omfwd")
      action(type="omfwd" target="central.server.local" port="514" protocol="udp")
    state: "present"

Voici un exemple d'une entrée rsyslog_rules complètement remplie. Notez le | pour la déclaration du bloc pour le ruleset. À partir de là, cela devient une syntaxe de configuration rsyslog basique.

Une autre possibilité pour définir les rsyslog_rules de manière individuelle est d'utiliser rsyslog_extra_conf_options. Cela étend le fichier de configuration principal /etc/rsyslog.conf avec des options supplémentaires au lieu de créer de nouveaux fichiers dans /etc/rsyslog.d.

rsyslog_extra_conf_options: |
  module(load="imudp")
  input(type="imudp" port="514")

Ici encore, | est utilisé pour la déclaration du bloc et le code lui-même est une syntaxe de configuration rsyslog basique. Cela peut également être combiné avec rsyslog_remove_default_rules: true pour s'assurer que /etc/rsyslog.d/ est vide.

De plus, il y a actuellement trois règles rsyslog préconfigurées. Toutes ont des modèles spéciaux dédiés (templates/*.conf.j2). Une d'entre elles est activée par défaut et s'appelle, eh bien, default. Elle prend le contrôle de la définition du fichier /etc/rsyslog.d/50-default.conf. Elle peut être facilement désactivée en spécifiant state: "absent".

rsyslog_rule_default:
  rule_name: "default"
  priority: 50
  template: "default.conf.j2"

La deuxième est docker, qui gère les logs des conteneurs Docker en cours d'exécution sur l'hôte donné. Elle est définie dans le fichier /etc/rsyslog.d/20-docker.conf.

rsyslog_rule_docker:
  rule_name: "docker"
  priority: 20
  template: "docker.conf.j2"
rsyslog_rule_docker_tag_all: true

Cela créera /var/log/docker et y mettra des fichiers log avec le schéma de nommage $CONTAINER_NAME.log. Il s'attend à ce que le $syslogtag contienne docker/ dans le nom (voir l'exemple ci-dessous), sinon il poussera tous les logs dans /var/log/docker/no_tag.log. De plus, il y a un rsyslog_rule_docker_tag_all qui peut être activé s'il y a plus d'un conteneur en cours d'exécution sur l'hôte donné et permet de créer un fichier unique avec les logs agrégés de tous les conteneurs dans /var/log/docker/all.log (Note : cela va doubler l'espace nécessaire pour les logs des conteneurs). Vous pouvez consulter mon rôle hadret.containers pour un exemple de définition du conteneur avec le support syslog activé.

containers:
  - name: cadvisor
    image: "google/cadvisor:latest"
    state: started
    log_driver: journald
    log_options:
      tag: docker/cadvisor

journald est de nos jours automatiquement pris en charge par rsyslog.

Enfin, il y a la gestion remote. Je voulais créer une solution clé en main pour gérer les parties client et serveur. La journalisation distante est actuellement très basique, mais fonctionne dès la configuration minimale.

rsyslog_rule_remote:
  rule_name: "remote"
  role: server
  priority: 99
  template: "remote.conf.j2"
  ruleset_name: "remote"

Au moins un protocole distant (relp/tcp/udp) doit être spécifié (Note : il n'y a pas de valeur par défaut et indiquer uniquement rsyslog_rule_remote échouera). La manière dont le côté serveur est géré exige de définir ruleset_name car c'est ce ruleset qui exécute l'action réelle d'écriture des logs (via omfile) et applique des modèles prédéfinis. Ceux-ci sont configurés pour être aussi similaires que possible aux règles "ordinaires", avec les sorties prédéfinies : auth.log, syslog.log, rsyslog.log, kern.log et mail.log.

rsyslog_rule_remote_relp:
  port: 514

Actuellement, seul relp prend en charge la configuration TLS.

rsyslog_rule_remote_relp:
  address: 0.0.0.0
  port: 514
  tls: true
  tls_cacert: "/tls-certs/ca.pem"
  tls_mycert: "/tls-certs/cert.pem"
  tls_myprivkey: "/tls-certs/key.pem"
  tls_authmode: "fingerprint"

Les protocoles tcp et udp n'autorisent actuellement que la spécification de address (optionnel en mode serveur), target (requis en mode client) et port (requis dans les deux modes).

rsyslog_rule_remote_tcp:
  address: 0.0.0.0
  port: 514

rsyslog_rule_remote_udp:
  address: 0.0.0.0
  port: 514

Veuillez noter que vous pouvez définir les trois, avec des adresses et ports différents (mais chacun d'eux seulement une fois). Toute la configuration sera par défaut dans /etc/rsyslog.d/99-remote.conf (serveur et client). Il est actuellement impossible d'avoir une seule machine agissant à la fois comme serveur et client en utilisant uniquement rsyslog_rule_remote_relp, mais il est possible de spécifier une règle supplémentaire avec soit rsyslog_extra_conf_options ou rsyslog_rules.

rsyslog_rule_remote:
  rule_name: "server"
  role: server
  priority: 99
  template: "remote.conf.j2"
  ruleset_name: "server"

rsyslog_rule_remote_udp:
  port: 514

rsyslog_rules:
  - rule_name: "client"
    priority: 99
    ruleset: |
      module(load="omfwd")
      action(type="omfwd" target="central.server.local" port="514" protocol="tcp")

Note : ces trois règles rsyslog préconfigurées sont des dictionnaires, pas des tableaux. Seuls les rsyslog_rules permettent plusieurs définitions de règles.

Extension et remplacement des modèles

Je réalise que tout n'est pas couvert par des variables et qu'il existe de nombreuses options de configuration différentes. C'est pourquoi j'utilise des modèles pour toutes les règles, ce qui permet d'étendre facilement, de remplacer des blocs (via l'héritage de modèles Jinja2) ou d'échanger complètement des modèles pour s'adapter à des besoins auxquels je n'ai pas pensé.

rsyslog_conf_template: "rsyslog.conf.j2"
rsyslog_rules_template: "rules.conf.j2"

Cela peut également être modifié au niveau de chaque règle.

rsyslog_rule_default:
  rule_name: "default"
  priority: 50
  template: "{{ playbook_dir }}/templates/custom-default.conf.j2"

rsyslog_rule_docker:
  rule_name: "docker"
  priority: 20
  template: "{{ playbook_dir }}/templates/custom-docker.conf.j2"

rsyslog_rules:
  - rule_name: "remote-udp"
    priority: 90
    template: "{{ playbook_dir }}/templates/custom-udp.conf.j2"
  - rule_name: "remote-tcp"
    priority: 91
    template: "{{ playbook_dir }}/templates/custom-tcp.conf.j2"

Exemple : étendre le bloc des modules dans le fichier de configuration principal

rsyslog_conf_template doit être défini pour pointer vers le nouveau fichier dans votre répertoire de playbook.

rsyslog_conf_template: "{{ playbook_dir }}/templates/custom-rsyslog.conf.j2"

Le fichier de modèle personnalisé doit être placé par rapport à votre playbook.yml.

{% extends 'roles/external/hadret.rsyslog/templates/rsyslog.conf.j2' %}

{% block modules %}
$ModLoad imuxsock
$ModLoad imklog
$ModLoad immark

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514
{% endblock %}

L'exemple ci-dessus remplace/étend le bloc modules dans le fichier de configuration principal de rsyslog.

Dépendances

Aucune.

Exemple de playbook

hosts: all
  roles:
    - hadret.rsyslog

Licence

MIT.

Auteurs

Ce rôle a été en partie assemblé en 2019 par Filip Chabik.