Rola Ansible: Rsyslog

Instaluje i konfiguruje rsyslog na serwerach Debian/Ubuntu.

Ta rola instaluje i konfiguruje najnowszą wersję rsyslog z oficjalnego repozytorium APT (na Debianie) lub oficjalnego PPA (na Ubuntu). Domyślnie nadpisuje zawartość plików /etc/rsyslog.conf i /etc/rsyslog.d/50-default.conf.

Wymagania

Brak.

Zmienne roli

Oto dostępne zmienne z ich wartościami domyślnymi (jak w defaults/main.yml):

rsyslog_rules: []

Tablica reguł dla rsyslog. Każdy wpis utworzy oddzielny plik konfiguracyjny o nazwie $priority-$rule_name.conf. Upewnij się, że sprawdzisz defaults/main.yml po skomentowane przykłady ze wszystkimi dostępnymi opcjami.

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"

Oto przykład w pełni wypełnionego wpisu rsyslog_rules. Zauważ, że | jest używane do deklaracji bloku dla ruleset. Od tego momentu staje się to czystą składnią konfiguracyjną rsyslog.

Alternatywną metodą definiowania rsyslog_rules w sposób reguła po regule jest użycie rsyslog_extra_conf_options. Umożliwia to rozszerzenie głównego pliku konfiguracyjnego /etc/rsyslog.conf o dodatkowe opcje zamiast tworzenia nowych plików w /etc/rsyslog.d.

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

Tutaj również | jest używane do deklaracji bloku, a sama składnia to czysta składnia konfiguracyjna rsyslog. Może być również połączona z rsyslog_remove_default_rules: true, co zapewni, że /etc/rsyslog.d/ będzie puste.

Dodatkowo obecnie istnieją trzy wstępnie skonfigurowane reguły rsyslog. Wszystkie mają specjalne, dedykowane szablony (templates/*.conf.j2). Tylko jedna z nich jest domyślnie włączona i nazywa się po prostu default. Przejmuje ona definicję pliku /etc/rsyslog.d/50-default.conf. Może być łatwo wyłączona przez określenie state: "absent".

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

Drugą jest docker, która obsługuje logi dla kontenerów Docker działających na danym hoście. Definiowana jest w pliku /etc/rsyslog.d/20-docker.conf.

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

Utworzy to /var/log/docker i umieści w nim pliki logów z nazwami w schemacie $CONTAINER_NAME.log. Oczekuje się, że $syslogtag będzie zawierać docker/ w nazwie (sprawdź przykład poniżej), w przeciwnym razie wszystkie logi zostaną przekierowane do /var/log/docker/no_tag.log. Dodatkowo istnieje rsyslog_rule_docker_tag_all, który można włączyć, gdy na danym hoście działa więcej niż jeden kontener i pozwala na pojedynczy plik z logami agregowanymi ze wszystkich kontenerów w /var/log/docker/all.log (Uwaga: to podwoi potrzebną przestrzeń dla logów kontenerów). Możesz sprawdzić moją rolę hadret.containers jako przykład definicji kontenera z włączonym wsparciem dla syslog.

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

journald w dzisiejszych czasach automatycznie jest obsługiwany przez rsyslog.

Ostatnią, ale nie mniej ważną, jest obsługa remote. Chciałem stworzyć gotowe rozwiązanie do obsługi zarówno części klienta, jak i serwera. Zdalne logowanie jest obecnie bardzo surowe i podstawowe, ale działa od razu po minimalnej konfiguracji.

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

Co najmniej jeden zdalny protokół (relp/tcp/udp) musi być określony (Uwaga: nie ma domyślnej opcji, a samo określenie rsyslog_rule_remote zakończy się niepowodzeniem). Sposób obsługi po stronie serwera wymaga zdefiniowania ruleset_name, ponieważ to ruleset wykonuje rzeczywistą akcję zapisywania logów (za pomocą omfile) oraz stosuje wcześniej zdefiniowane szablony. Wstępnie skonfigurowano następujące wyniki: auth.log, syslog.log, rsyslog.log, kern.log i mail.log.

rsyslog_rule_remote_relp:
  port: 514

Obecnie tylko relp obsługuje konfigurację 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"

Zarówno tcp, jak i udp obecnie pozwalają tylko na określenie address (opcjonalne w trybie serwera), target (wymagane w trybie klienta) i port (wymagane w obu trybach).

rsyslog_rule_remote_tcp:
  address: 0.0.0.0
  port: 514

rsyslog_rule_remote_udp:
  address: 0.0.0.0
  port: 514

Uwaga: możesz zdefiniować wszystkie trzy, z różnymi adresami i portami (ale każda z nich tylko raz). Cała konfiguraacja domyślnie trafi do /etc/rsyslog.d/99-remote.conf (zarówno serwera, jak i klienta). Obecnie niemożliwe jest, aby jedna maszyna działała jako zarówno serwer, jak i klient tylko przy użyciu rsyslog_rule_remote_relp, ale możliwe jest określenie dodatkowej reguły przy użyciu rsyslog_extra_conf_options lub 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")

Uwaga: wszystkie trzy dodatkowe wstępnie skonfigurowane reguły rsyslog są słownikami, a nie tablicami. Tylko rsyslog_rules pozwala na wiele definicji reguł.

Rozszerzanie i zastępowanie szablonów

Zdaję sobie sprawę, że nie wszystko jest objęte zmiennymi i istnieje wiele różnych możliwych opcji konfiguracyjnych. Dlatego używam szablonów dla wszystkich reguł, co umożliwia łatwe rozszerzanie, blokowe zastępowanie (za pomocą dziedziczenia szablonów Jinja2) lub pełną wymianę szablonów, aby dostosować się do potrzeb, o których nie pomyślałem.

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

Można to również zmienić na poziomie reguły.

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"

Przykład: rozszerzanie bloku modułów w głównym pliku konfiguracyjnym

rsyslog_conf_template musi zostać ustawione na wskazanie nowego pliku w katalogu playbooka.

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

Plik szablonu dostosowanego musi zostać umieszczony w relacji do twojego 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 %}

Powyższy przykład zastępuje/rozszerza blok modules w głównym pliku konfiguracyjnym rsyslog.

Zależności

Brak.

Przykładowy playbook

hosts: all
  roles:
    - hadret.rsyslog

Licencja

MIT.

Autorzy

Ta rola została częściowo złożona w 2019 roku przez Filipa Chabika.