One place for hosting & domains

      Journald

      Zentralisieren von Protokollen mit Journald unter Ubuntu 20.04


      Der Autor wählte den Free and Open Source Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Systemprotokolle sind ein äußerst wichtiger Bestandteil für die Verwaltung von Linux-Systemen. Sie bieten einen unschätzbaren Einblick in die Funktionsweise und Verwendung der Systeme, da sie neben Fehlern auch Betriebsinformationen wie Sicherheitsereignisse aufzeichnen. Die Standardkonfiguration für Linux-Systeme besteht darin, ihre Protokolle lokal auf demselben System zu speichern, auf dem sie aufgetreten sind. Dies funktioniert für eigenständige Systeme, wird jedoch mit zunehmender Anzahl von Systemen schnell zu einem Problem. Die Lösung für die Verwaltung all dieser Protokolle besteht darin, einen zentralen Protokollierungsserver zu erstellen, auf dem jeder Linux-Host seine Protokolle in Echtzeit an einen dedizierten Protokollverwaltungsserver sendet.

      Eine zentralisierte Protokollierungslösung bietet im Vergleich zum Speichern von Protokollen auf jedem Host mehrere Vorteile:

      • Reduziert den Speicherplatz, der auf jedem Host zum Speichern von Protokolldateien benötigt wird.
      • Protokolle können länger aufbewahrt werden, da der dedizierte Protokollserver mit mehr Speicherkapazität konfiguriert werden kann.
      • Es kann eine erweiterte Protokollanalyse durchgeführt werden, die Protokolle von mehreren Systemen und mehr Rechenressourcen erfordert, als auf den Hosts verfügbar sind.
      • Systemadministratoren können auf die Protokolle aller ihrer Systeme zugreifen, bei denen sie sich aus Sicherheitsgründen möglicherweise nicht direkt anmelden können.

      In diesem Leitfaden konfigurieren Sie eine Komponente der Tool-Suite systemd, um Protokollnachrichten von Client-Systemen an einen zentralen Protokollsammlungsserver weiterzuleiten. Sie konfigurieren den Server und den Client so, dass TLS-Zertifikate verwendet werden, um die Protokollnachrichten zu verschlüsseln, wenn sie über unsichere Netzwerke wie das Internet übertragen werden, und um sich gegenseitig zu authentifizieren.

      Voraussetzungen

      Bevor Sie diese Anleitung beginnen, benötigen Sie Folgendes:

      • Zwei Ubuntu 20.04-Server.
      • Einen Nicht-root-Benutzer mit Sudo-Berechtigungen auf beiden Servern. Anweisungen dazu finden Sie im Leitfaden zur Ersteinrichtung des Servers mit Ubuntu 20.04. Sie sollten auch die UFW-Firewall auf beiden Servern konfigurieren, wie im Leitfaden erläutert.
      • Zwei Hostnamen, die auf Ihre Server verweisen. Ein Hostname für das Client-System, das die Protokolle generiert, und ein anderer für den Protokollsammlungsserver. In der Domains- und DNS-Dokumentation erfahren Sie, wie Sie Hostnamen auf DigitalOcean Droplets verweisen.

      In diesem Leitfaden werden die folgenden zwei Beispiel-Hostnamen verwendet:

      • client.your_domain: Das Client-System, das die Protokolle generiert.
      • server.your_domain: Der Protokollsammlungsserver.

      Melden Sie sich sowohl beim Client als auch beim Server in separaten Terminals über SSH als Nicht-root-sudo-Benutzer an, um dieses Tutorial zu starten.

      Hinweis: Während des gesamten Tutorials werden Befehlsblöcke mit dem Namen des Servers (Client oder Server) gekennzeichnet, auf dem der Befehl ausgeführt werden soll.

      Schritt 1 — Installieren von systemd-journal-remote

      In diesem Schritt installieren Sie das Paket systemd-journal-remote auf dem Client und dem Server. Dieses Paket enthält die Komponenten, die der Client und der Server zum Weiterleiten von Protokollnachrichten verwenden.

      Führen Sie zunächst sowohl auf dem Client als auch auf dem Server ein Systemupdate aus, um sicherzustellen, dass die Paketdatenbank und das System aktuell sind:

      Client and Server

      • sudo apt update

      • sudo apt upgrade

      Installieren Sie das Paket systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      Aktivieren und starten Sie auf dem Server die beiden systemd-Komponenten, die zum Empfangen von Protokollnachrichten benötigt werden, mit dem folgenden Befehl:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket

      • sudo systemctl enable systemd-journal-remote.service

      Die Option --now im ersten Befehl startet die Dienste sofort. Sie haben es im zweiten Befehl nicht verwendet, da dieser Dienst erst gestartet wird, wenn er über TLS-Zertifikate verfügt, die Sie im nächsten Schritt erstellen.

      Aktivieren Sie auf dem Client die Komponente, mit der systemd die Protokollnachrichten an den Server sendet:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Öffnen Sie anschließend auf dem Server die Ports 19532 und 80 in der UFW-Firewall. Dadurch kann der Server die Protokollnachrichten vom Client empfangen. Port 80 ist der Port, über den Certbot das TLS-Zertifikat generiert. Die folgenden Befehle öffnen diese Ports:

      Server

      • sudo ufw allow in 19532/tcp

      • sudo ufw allow in 80/tcp

      Auf dem Client müssen Sie Port 80 nur mit diesem Befehl öffnen:

      Client

      Sie haben jetzt die erforderlichen Komponenten installiert und die Basissystemkonfiguration auf dem Client und dem Server abgeschlossen. Bevor Sie diese Komponenten so konfigurieren können, dass sie mit der Weiterleitung von Protokollnachrichten beginnen, registrieren Sie die Let’s Encrypt TLS-Zertifikate für den Client und den Server mithilfe des Dienstprogramms certbot.

      Schritt 2 – Installieren von Certbot und Registrieren von Zertifikaten

      Let’s Encrypt ist eine Zertifizierungsstelle, die kostenlose TLS-Zertifikate ausstellt. Mit diesen Zertifikaten können Computer sowohl die zwischen ihnen gesendeten Daten verschlüsseln als auch die Identität des anderen überprüfen. Mit diesen Zertifikaten können Sie Ihr Surfen im Internet mit HTTPS sichern. Dieselben Zertifikate können von jeder anderen Anwendung verwendet werden, die dieselbe Sicherheitsstufe wünscht. Der Prozess der Registrierung des Zertifikats ist der gleiche, unabhängig davon, wofür Sie es verwenden.

      In diesem Schritt installieren Sie das Dienstprogramm certbot und registrieren damit die Zertifikate. Außerdem wird es automatisch darum kümmern, die Zertifikate zu erneuern, wenn sie ablaufen. Der Registrierungsvorgang ist hier der gleiche auf dem Client und dem Server. Sie müssen nur den Hostnamen ändern, um ihn an den Host anzupassen, auf dem Sie den Registrierungsbefehl ausführen.

      Aktivieren Sie zunächst das universe-Repository von Ubuntu, da sich das Dienstprogramm certbot im universe-Repository befindet. Wenn Sie das universe-Repository bereits aktiviert haben, wird eine Ausführung dieser Befehle in Ihrem System nichts verändern und ist somit sicher:

      Client and Server

      • sudo apt install software-properties-common

      • sudo add-apt-repository universe

      • sudo apt update

      Als Nächstes installieren Sie certbot auf beiden Hosts:

      Client and Server

      Nachdem Sie certbot installiert haben, führen Sie den folgenden Befehl aus, um die Zertifikate auf dem Client und Server zu registrieren:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Die Optionen in diesem Befehl bedeuten Folgendes:

      • certonly: Registrieren Sie das Zertifikat und führen Sie keine anderen Änderungen am System vor.
      • --standalone: Verwenden Sie den integrierten Webserver von certbot zur Verifizierung der Zertifikatsanforderung.
      • –-agree-tos: Stimmen Sie automatisch den Nutzungsbedingungen von Let’s Encrypt zu.
      • --email your_email: Dies ist die E-Mail-Adresse, mit der Let’s Encrypt Sie über den Ablauf des Zertifikats und andere wichtige Informationen benachrichtigt.
      • -d your_domain: Der Hostname, für den das Zertifikat registriert wird. Dies muss dem System entsprechen, in dem Sie es ausführen.

      Wenn Sie diesen Befehl ausführen, werden Sie gefragt, ob Sie die E-Mail-Adresse mit Let’s Encrypt teilen möchten, damit diese Ihnen Nachrichten und andere Informationen zu ihrer Arbeit per E-Mail senden können. Dies ist optional. Wenn Sie Ihre E-Mail-Adresse nicht teilen, wird die Zertifikatsregistrierung weiterhin normal abgeschlossen.

      Wenn der Zertifikatregistrierungsprozess abgeschlossen ist, werden die Zertifikat- und Schlüsseldateien in /etc/letsencrypt/live/your_domain/ abgelegt, wobei your_domain der Hostname ist, für den Sie das Zertifikat registriert haben.

      Schließlich müssen Sie eine Kopie der Let’s Encrypt-Zertifizierungsstelle und der Zwischenzertifikate herunterladen und in dieselbe Datei einfügen. journald verwendet diese Datei, um die Authentizität der Zertifikate auf dem Client und dem Server zu überprüfen, wenn diese miteinander kommunizieren.

      Mit dem folgenden Befehl werden die beiden Zertifikate von der Let’s Encrypt-Website heruntergeladen und in einer einzigen Datei mit dem Namen letsencrypt-combined-certs.pem im Home-Verzeichnis Ihres Benutzers abgelegt.

      Führen Sie diesen Befehl auf dem Client und dem Server aus, um die Zertifikate herunterzuladen und die kombinierte Datei zu erstellen:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Verschieben Sie als Nächstes diese Datei in das Verzeichnis Let’s Encrypt, das die Zertifikate und Schlüssel enthält:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Sie haben nun die Zertifikate und Schlüssel registriert. Im nächsten Schritt konfigurieren Sie den Protokollsammlungsserver so, dass er Protokollnachrichten vom Client abhört und speichert.

      Schritt 3 – Konfigurieren des Servers

      In diesem Schritt konfigurieren Sie den Server so, dass er die im letzten Schritt generierten Zertifikat- und Schlüsseldateien verwendet, damit er Protokollnachrichten vom Client akzeptieren kann.

      systemd-journal-remote ist die Komponente, die auf Protokollnachrichten wartet. Öffnen Sie ihre Konfigurationsdatei unter /etc/systemd/journal-remote.conf mit einem Texteditor, um die Konfiguration auf dem Server zu starten:

      • sudo nano /etc/systemd/journal-remote.conf

      Entfernen Sie anschließend die Kommentare in allen Zeilen im Abschnitt [Remote] und legen Sie die Pfade so fest, dass sie auf die soeben erstellten TLS-Dateien verweisen:

      /etc/systemd/journal-remote.conf

      [Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

      Hier sind die Optionen, die Sie hier verwendet haben:

      • Seal=false: Melden Sie die Protokolldaten im Journal an. Aktivieren Sie diese Option, wenn Sie maximale Sicherheit benötigen; andernfalls können Sie es als false belassen.
      • SplitMode=host: Die Protokolle der Remoteclients werden nach Host in /var/log/journal/remote geteilt. Wenn Sie möchten, dass alle Protokolle einer einzelnen Datei hinzugefügt werden, setzen Sie dies auf SplitMode=false.
      • ServerKeyFile: Die private Schlüsseldatei des Servers.
      • ServerCertificateFile: Die Zertifikatdatei des Servers.
      • TrustedCertificateFile: Die Datei mit den Let’s Encrypt CA-Zertifikaten.

      Jetzt müssen Sie die Berechtigungen für die Let’s Encrypt-Verzeichnisse ändern, die die Zertifikate und den Schlüssel enthalten, damit die systemd-journal-remote sie lesen und verwenden kann.

      Ändern Sie zunächst die Berechtigungen so, dass das Zertifikat und der private Schlüssel lesbar sind:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ändern Sie als Nächstes das Gruppeneigentum des privaten Schlüssels in die Gruppe von systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Jetzt können Sie systemd-journal-remote starten:

      • sudo systemctl start systemd-journal-remote.service

      Ihr Protokollsammlungs server wird jetzt ausgeführt und ist bereit, Protokollnachrichten von einem Client zu akzeptieren. Im nächsten Schritt konfigurieren Sie den Client so, dass die Protokolle an Ihren Sammlungs server weitergeleitet werden.

      Schritt 4 – Konfigurieren des Clients

      In diesem Schritt konfigurieren Sie die Komponente, die die Protokollnachrichten an den Protokollsammlungsserver weiterleitet. Diese Komponente wird systemd-journal-upload genannt.

      Die Standardkonfiguration für systemd-journal-upload ist, dass ein temporärer Benutzer verwendet wird, der nur vorhanden ist, während der Prozess ausgeführt wird. Dies erschwert das Lesen der TLS-Zertifikate und -Schlüssel durch systemd-journal-upload. Um dies zu beheben, erstellen Sie einen neuen Systembenutzer mit demselben Namen wie der temporäre Benutzer, der an seiner Stelle verwendet wird.

      Erstellen Sie zunächst den neuen Benutzer mit dem Namen systemd-journal-upload auf dem Client mit dem folgenden adduser-Befehl:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Diese Optionen für den Befehl lauten:

      • --system: Erstellen Sie den neuen Benutzer als Systembenutzer. Dadurch wird dem Benutzer eine UID-Nummer (Benutzerkennung) unter 1000 gegeben. UIDs über 1000 werden normalerweise an Benutzerkonten vergeben, mit denen sich ein Mensch anmeldet.
      • --home/run/systemd: Legen Sie /run/systemd als Home-Verzeichnis für diesen Benutzer fest.
      • --no-create-home: Erstellen Sie das Home-Verzeichnis nicht, da es bereits vorhanden ist.
      • --disabled-login: Der Benutzer kann sich beispielsweise nicht über SSH beim Server anmelden.
      • --group: Erstellen Sie eine Gruppe mit demselben Namen wie der Benutzer.

      Legen Sie als Nächstes die Berechtigungen und den Besitz der Let’s Encrypt-Zertifikatdateien fest:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem

      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Bearbeiten Sie nun die Konfiguration für systemd-journal-upload unter /etc/systemd/journal-upload.conf. Öffnen Sie diese Datei mit einem Texteditor:

      • sudo nano /etc/systemd/journal-upload.conf

      Bearbeiten Sie diese Datei, damit sie wie folgt aussieht:

      /etc/systemd/journal-upload.conf

      [Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem

      Starten Sie abschließend den systemd-journal-upload-Dienst neu, damit er die neue Konfiguration verwendet:

      • sudo systemctl restart systemd-journal-upload.service

      Ihr Client ist jetzt eingerichtet und wird ausgeführt und sendet seine Protokollnachrichten an den Protokollsammlungsserver. Im nächsten Schritt überprüfen Sie, ob die Protokolle korrekt gesendet und aufgezeichnet werden.

      Schritt 5 – Testen des Clients und des Servers

      In diesem Schritt testen Sie, ob der Client Protokollnachrichten an den Server weiterleitet und ob der Server sie korrekt speichert.

      Der Protokollsammlungsserver speichert die Protokolle von den Clients in einem Verzeichnis unter /var/log/journal/remote/. Wenn Sie den Client am Ende des letzten Schritts neu gestartet haben, wurden Protokollnachrichten gesendet, sodass sich jetzt eine Protokolldatei in /var/log/journal/remote/ befindet. Die Datei wird nach dem Hostnamen, den Sie für das TLS-Zertifikat verwenden, benannt.

      Verwenden Sie den Befehl Is, um zu überprüfen, ob die Protokolldatei des Clients auf dem Server vorhanden ist:

      Server

      • sudo ls -la /var/log/journal/remote/

      Dadurch wird der Verzeichnisinhalt mit der Protokolldatei gedruckt:

      Output
      total 16620
drwxr-xr-x  2 systemd-journal-remote systemd-journal-remote     4096 Jun 30 16:17  .
drwxr-sr-x+ 4 root                   systemd-journal            4096 Jun 30 15:55  ..
-rw-r-----  1 systemd-journal-remote systemd-journal-remote 8388608 Jul  1 10:46 'remote-CN=client.your_domain'

      Schreiben Sie als Nächstes eine Protokollnachricht auf den Client, um zu überprüfen, ob der Server die Nachrichten des Clients wie erwartet empfängt. Mit dem Dienstprogramm logger erstellen Sie eine benutzerdefinierte Protokollnachricht auf dem Client. Wenn alles funktioniert, leitet systemd-journal-upload diese Nachricht an den Server weiter.

      Führen Sie auf dem Client den folgenden logger-Befehl aus:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      -p syslog.debug in diesem Befehl legt Funktion und Schweregrad der Nachricht fest. Wenn man dies auf syslog.debug setzt, wird deutlich, dass es sich um eine Testnachricht handelt. Dieser Befehl zeichnet die Nachricht ### TEST MESSAGE from client.your_domain ### im Journal des Clients auf, das dann vom systemd-journal-upload an den** Server** weitergeleitet wird.

      Lesen Sie als Nächstes die Journaldatei des Clients auf dem Server, um zu überprüfen, ob die Protokollnachrichten vom Client eingehen. Diese Datei ist eine binäre Protokolldatei, sodass Sie sie mit Tools wie less nicht lesen können. Lesen Sie die Datei stattdessen mit journalctl mit der Option --file =, mit der Sie eine benutzerdefinierte Journaldatei angeben können:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      Die Protokollnachricht wird wie folgt angezeigt:

      Test log message
      . . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Ihr Protokollzentralisierungsserver sammelt jetzt erfolgreich Protokolle von Ihrem Client-System.

      Zusammenfassung

      In diesem Artikel haben Sie einen zentralen Protokollsammlungsserver eingerichtet und einen Client so konfiguriert, dass eine Kopie seiner Systemprotokolle an den Server weitergeleitet wird. Mit den hier verwendeten Client-Konfigurationsschritten können Sie so viele Clients konfigurieren, wie Sie zum Weiterleiten von Nachrichten an den Protokollsammlungsserver benötigen.



      Source link

      Cómo centralizar los registros con Journald en Ubuntu 20.04


      El autor seleccionó la Free and Open Source Fund para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Los registros de sistemas son un componente extremadamente importante para administrar sistemas Linux. Proporcionan una visión valiosa sobre cómo funcionan los sistemas y cómo se utilizan porque, además de errores, registran información operativa como eventos de seguridad. La configuración estándar para sistemas Linux es almacenar sus registros localmente en el mismo sistema donde se produjeron. Esto funciona para sistemas independientes, pero rápidamente se convierte en un problema, ya que aumenta el número de sistemas. La solución para administrar todos estos registros es crear un servidor de registro centralizado donde cada host Linux envía sus registros en tiempo real a un servidor de administración de registros específico.

      Una solución de registro centralizada ofrece varias ventajas en comparación con el almacenamiento de registros en cada host:

      • Reduce la cantidad de espacio de disco necesaria en cada host para almacenar archivos de registro.
      • Los registros pueden mantenerse más tiempo, ya que el servidor de registro específico puede configurarse con más capacidad de almacenamiento.
      • Pueden realizarse análisis de registro avanzados que requieren registros de varios sistemas y también más recursos informáticos de los que puede estar disponible en los hosts.
      • Los administradores de sistemas pueden acceder a los registros para todos sus sistemas a los que, quizá, no puedan acceder directamente por razones de seguridad.

      En esta guía, configurará un componente de la serie de herramientas systemd para transmitir mensajes de registro desde los sistemas de cliente a un servidor de recopilación de registros centralizado. Configurará el servidor y el cliente para que utilicen certificados TLS para cifrar los mensajes de registro, ya que se transmiten a través de redes inseguras como Internet y también para autenticarse.

      Requisitos previos

      Para completar esta guía, necesitará lo siguiente:

      • Dos servidores Ubuntu 20.04.
      • Un usuario no root con privilegios sudo en ambos servidores. Siga la guía de configuración inicial de servidor con Ubuntu 20.04 para obtener instrucciones sobre cómo hacerlo. También debería configurar el firewall UFW en ambos servidores como se explica en la guía.
      • Dos nombres de host que apuntan a sus servidores. Un nombre de host para el sistema cliente que genera los registros y otro para el servidor de compilación de registros. Descubra cómo apuntar nombres de host a DigitalOcean Droplets consultando la documentación sobre dominios y DNS.

      Esta guía utilizará los dos nombres de host siguientes:

      • client.your_domain: el sistema de cliente que genera los registros.
      • server.your_domain: el servidor de compilación de registro.

      Inicie sesión en el cliente y en el servidor en terminales independientes a través de SSH como en el usuario sudo no root para empezar este tutorial.

      Nota: A lo largo del tutorial, se etiquetan los bloques de comandos con el nombre de servidor (cliente o servidor) en el que debería ejecutarse el comando.

      Paso 1: Instalar systemd-journal-remote

      En este paso, instalará el paquete systemd-journal-remote en el cliente y en el servidor. Este paquete contiene los componentes que utilizan el cliente y el servidor para transmitir los mensajes de registro.

      Primero, en el cliente y en el servidor, ejecute una actualización de sistema para garantizar que la base de datos de paquetes y el sistema estén actualizados:

      Client and Server

      • sudo apt update

      • sudo apt upgrade

      A continuación, instale el paquete systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      En el servidor, habilite e inicie los dos componentes systemd que necesita para recibir mensajes de registro con el siguiente comando:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket

      • sudo systemctl enable systemd-journal-remote.service

      La opción --now en el primer comando inicia los servicios de inmediato. No lo utilizó en el segundo comando, ya que este servicio no se iniciará hasta que tenga certificados TLS, lo que creará en el siguiente paso.

      En el cliente, habilite el componente que systemd utiliza para enviar los mensajes de registro al servidor:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      A continuación, en el servidor, abra los puertos 19532 y 80 en el firewall UFW. Esto permitirá al servidor recibir los mensajes de registro del cliente. El puerto 80 es el puerto que certbot utilizará para generar el certificado TLS. Los siguientes comandos abrirán estos puertos:

      Server

      • sudo ufw allow in 19532/tcp

      • sudo ufw allow in 80/tcp

      En el cliente, solo deberá abrir el puerto 80 con este comando:

      Client

      Ahora ha instalado los componentes necesarios y ha completado la configuración del sistema base en el cliente y en el servidor. Antes de que pueda configurar estos componentes para que empiecen a retransmitir los mensajes de registro, registrará los certificados TLS Let’s Encrypt para el cliente y el servidor usando la utilidad certbot.

      Paso 2: Instalar certificados de registro y Certbot

      Let’s Encrypt es una autoridad de certificación que emite certificados TLS gratuitos. Estos certificados permiten a los ordenadores cifrar los datos que envían entre ellos y también verificar la identidad de cada uno. Estos certificados le permiten proteger su navegación en Internet con HTTPS. Cualquier otra aplicación que quiera el mismo nivel de seguridad, puede usar los mismos certificados. El proceso de registro del certificado es el mismo sin importar para lo que los use.

      En este paso, instalará la utilidad certbot y la usará para registrar los certificados. También automáticamente se ocupará de renovar los certificados cuando expiren. El proceso de registro aquí es el mismo en el cliente y en el servidor. Solo deberá cambiar el nombre de host para que coincida con el host donde está ejecutando el comando de registro.

      Primero, habilite el repositorio universe de Ubuntu, ya que la utilidad certbot reside en el repositorio universe. Si ya tiene el repositorio universe habilitado, la ejecución de estos comandos es segura y no le hará a su sistema:

      Client and Server

      • sudo apt install software-properties-common

      • sudo add-apt-repository universe

      • sudo apt update

      A continuación, instale certbot en ambos hosts:

      Client and Server

      Ahora que ha instalado certbot, ejecute el siguiente comando para registrar los certificados en el cliente y en el servidor:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Las opciones de este comando significan lo siguiente:

      • certonly: registra el certificado y no realiza otros cambios en el sistema.
      • --standalone: utiliza el servidor web integrado de certbot para verificar la solicitud de certificado.
      • --agree-tos: acepta de forma automática los Términos de uso de Let’s Encrypt.
      • --email your-email: esta es la dirección de correo electrónico que Let’s Encrypt usará para notificarle sobre la expiración del certificado y otra información importante.
      • -d your_domain: el nombre de host para el que se registrará el certificado. Debe coincidir con el sistema donde lo ejecuta.

      Cuando ejecute este comando, se le solicitará si quiere compartir la dirección de correo electrónico con Let’s Encrypt para que puedan enviarle por correo electrónico noticias y otra información sobre su trabajo. Hacerlo es opcional, si no comparte su dirección de correo electrónico, el registro de certificados se completará de forma normal.

      Cuando se complete el proceso de registro de certificado, colocará el certificado y los archivos de clave en /etc/letsencrypt/live/your_domain/ donde your_domain es el nombre de host para el que registró el certificado.

      Por último, deberá descargar una copia de los certificados intermedios y de la autoridad de certificación Let’s Encrypt y ponerlos en el mismo archivo. journald usará este archivo para verificar la autenticidad de los certificados en el cliente y en el servidor cuando se comuniquen entre ellos.

      El siguiente comando descargará los dos certificados desde el sitio web Let’s Encrypt y los pondrá en un solo archivo llamado letsencrypt-combined-certs.pem en el directorio de inicio de su usuario.

      Ejecute este comando en el cliente y en el servidor para descargar los certificados y crear un archivo combinado:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      A continuación, mueva este archivo al directorio Let’s Encrypt que contiene los certificados y las claves:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Ahora ha registrado los certificados y las claves. En el siguiente paso, configurará el servidor de compilación de registro para que empiece a escuchar y almacenar los mensajes de registro del cliente.

      Paso 3: Configuración del servidor

      En este paso, configurará el servidor para que utilice el certificado y los archivos de clave que generó en el último paso, de forma que pueda comenzar a aceptar los mensajes de registro del cliente.

      systemd-journal-remote es el componente que escucha los mensajes de registro. Abra su archivo de configuración en /etc/systemd/journal-remote.conf con un editor de texto para empezar a configurarlo en el servidor:

      • sudo nano /etc/systemd/journal-remote.conf

      A continuación, elimine todas las líneas de la sección [remoto] y establezca las rutas para que apunten a los archivos TLS que acaba de crear:

      /etc/systemd/journal-remote.conf

      [Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

      Aquí están las opciones que ha utilizado:

      • Seal=false: firma los datos de registro en el diario. Habilítelo si necesita una máxima seguridad; de lo contrario, puede dejarlo como false.
      • SplitMode=host: los registros de los clientes remotos se dividen host en /var/log/journal/remote. Si prefiere que se añadan todos los registros a un solo archivo configúrelo a SplitMode=false.
      • ServerKeyFile: el archivo de clave privada del servidor.
      • ServerCertificateFile: el archivo de certificado del servidor.
      • TrustedCertificateFile: el archivo que contiene los certificados de la autoridad de certificación Let’s Encrypt.

      Ahora, deberá cambiar los permisos en los directorios Let’s Encrypt que contienen los certificados y la clave para que systemd-journal-remote los pueda leer y usar.

      Primero, cambie los permisos para que el certificado y la clave privada se puedan leer:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      A continuación, cambie la propiedad de grupo de la clave privada al grupo systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ahora puede iniciar systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Ahora se está ejecutando su servidor de compilación de registro y está listo para comenzar a aceptar mensajes de registro de un cliente. En el siguiente paso, configurará el cliente para que envíe los registros a su servidor de compilación.

      Paso 4: Configurar el cliente

      En este paso, configurará el componente que transmite los mensajes de registro al servidor de compilación de registro. Este componente se llama systemd-journal-upload.

      La configuración predeterminada para systemd-journal-upload es la que utiliza un usuario temporal que solo existe mientras se está ejecutando. Esto permite que systemd-journal-upload lea los certificados TLS y las claves más complicadas. Para resolverlo, creará un nuevo usuario de sistema con el mismo nombre que el usuario temporal que se utilizará en su lugar.

      Primero, cree el nuevo usuario llamado systemd-journal-upload en el cliente con el siguiente comando adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Estas opciones al comando son:

      • --system: crea el nuevo usuario como un usuario de sistema. Le da al usuario un número UID (Identificador de usuario) inferior a 1000. Normalmente, los UID superiores a 1000 se dan a las cuentas de usuario con las que un humano iniciará sesión.
      • --home /run/systemd: establece /run/systemd como el directorio de inicio de este usuario.
      • --no-create-home: no crea el conjunto de directorio de inicio, puesto que ya existe.
      • --disabled-login: el usuario no puede iniciar sesión en el servidor a través de SSH, por ejemplo.
      • --group: crea un grupo con el mismo nombre que el usuario.

      A continuación, establezca los permisos y la propiedad de los archivos del certificado Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem

      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Ahora, edite la configuración para systemd-journal-upload, que está en /etc/systemd/journal-upload.conf. Abra este archivo con un editor de texto:

      • sudo nano /etc/systemd/journal-upload.conf

      Edite este archivo de forma que se parezca a lo siguiente:

      /etc/systemd/journal-upload.conf

      [Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem

      Por último, reinicie el servicio systemd-journal-upload para que utilice la nueva configuración:

      • sudo systemctl restart systemd-journal-upload.service

      Ahora su cliente está configurado y ejecutándose, y envía sus mensajes de registro al servidor de compilación de registro. En el siguiente paso, comprobará que se están enviando los registros de forma correcta.

      Paso 5: Probar el cliente y el servidor

      En este paso, probará que el cliente está enviando mensajes de registro al servidor y que el servidor los almacena correctamente.

      El servidor de compilación de registro almacena los registros de los clientes en un directorio en /var/log/journal/remote/. Cuando reinició el cliente al final del último paso, comenzó a enviar mensajes de registro, de forma que ahora hay un archivo de registro en /var/log/journal/remote/. El archivo será llamará como el nombre de host que utilizó para el certificado TLS.

      Utilice el comando ls para comprobar que el archivo de registro del cliente está presente en el servidor:

      Server

      • sudo ls -la /var/log/journal/remote/

      Esto imprimirá el contenido del directorio que muestra el archivo de registro:

      Output
      total 16620
drwxr-xr-x  2 systemd-journal-remote systemd-journal-remote     4096 Jun 30 16:17  .
drwxr-sr-x+ 4 root                   systemd-journal            4096 Jun 30 15:55  ..
-rw-r-----  1 systemd-journal-remote systemd-journal-remote 8388608 Jul  1 10:46 'remote-CN=client.your_domain'

      A continuación, escriba un mensaje de registro en el cliente para comprobar que el servidor está recibiendo los mensajes del cliente como se espera. Usará la utilidad logger para crear un mensaje de registro personalizado en el cliente. Si todo está funcionando, systemd-journal-upload transmitirá este mensaje al servidor.

      En el cliente ejecute el siguiente comando logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      El -p syslog.debug en este comando establece la instalación y la gravedad del mensaje. Configurar esto a syslog.debug aclarará que es un mensaje de prueba. Este comando grabará el mensaje ### TEST MESSAGE from client.your_domain ### al diario del cliente, que systemd-journal-upload transmitirá al servidor.

      A continuación, lea el archivo de diario del cliente en el servidor para comprobar que los mensajes de registro están llegando desde el cliente. Este archivo es un archivo de registro binario, de forma que no podrá leerlo con herramientas como less. En su lugar, lea el archivo usando journalctl con la opción --file= que le permite especificar un archivo de diario personalizado:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      El mensaje de registro aparecerá como se muestra:

      Test log message
      . . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Ahora su servidor de centralización de registro está recopilando correctamente los registros de su sistema de cliente.

      Conclusión

      En este artículo, configuró un servidor de compilación central de registro y configuró un cliente para que transmitiera una copia de sus registros de sistema al servidor. Puede configurar tantos clientes como necesite para transmitir los mensajes al servidor de compilación de registro usando los pasos de configuración del cliente que utilizó aquí.



      Source link

      Comment centraliser les journaux avec Journald sur Ubuntu 20.04


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Les journaux système sont un élément extrêmement important de la gestion des systèmes Linux. Ils fournissent un aperçu inestimable du fonctionnement des systèmes et de leur utilisation car, en plus des erreurs, ils enregistrent des informations opérationnelles telles que les événements de sécurité. La configuration standard des systèmes Linux consiste à stocker leurs journaux localement sur le même système que celui où ils ont été créés. Cela fonctionne pour les systèmes autonomes, mais devient rapidement un problème lorsque le nombre de systèmes augmente. La solution pour gérer tous ces journaux est de créer un serveur de journalisation centralisé où chaque hôte Linux envoie ses journaux, en temps réel, à un serveur de gestion de journaux dédié.

      Une solution de journalisation centralisée offre plusieurs avantages par rapport au stockage des journaux sur chaque hôte :

      • Cela réduit la quantité d’espace disque nécessaire sur chaque hôte pour stocker les fichiers journaux.
      • Les journaux peuvent être conservés plus longtemps, car le serveur de journaux dédié peut être configuré avec une plus grande capacité de stockage.
      • Il est possible d’effectuer une analyse avancée des journaux qui nécessite des journaux provenant de plusieurs systèmes et également plus de ressources de calcul que celles qui peuvent être disponibles sur les hôtes.
      • Les administrateurs de systèmes peuvent accéder aux journaux de tous leurs systèmes auxquels ils ne peuvent pas se connecter directement pour des raisons de sécurité.

      Dans ce guide, vous allez configurer un composant de la suite d’outils systemd pour relayer les messages de journal des systèmes clients vers un serveur de collecte de journaux centralisé. Vous allez configurer le serveur et le client pour qu’ils utilisent des certificats TLS afin de crypter les messages du journal lorsqu’ils sont transmis sur des réseaux non sécurisés tels qu’Internet, et également pour qu’ils s’authentifient mutuellement.

      Conditions préalables

      Avant de commencer ce guide, vous aurez besoin des éléments suivants :

      • Deux serveurs Ubuntu 20.04.
      • Un utilisateur non root avec des privilèges sudo sur les deux serveurs.  Suivez le guide Configuration initiale du serveur avec Ubuntu 20.04 pour savoir comment procéder. Vous devez également configurer le pare-feu UFW sur les deux serveurs comme expliqué dans le guide.
      • Deux noms d’hôtes qui pointent vers vos serveurs. Un nom d’hôte pour le système client qui génère les journaux et un autre pour le serveur de collecte des journaux. Apprenez comment faire pointer les noms d’hôtes vers DigitalOcean Droplets en consultant la documentation Domaines et DNS.

      Ce guide utilisera les deux exemples de noms d’hôtes suivants :

      • client.your_domain : Le système client qui génère les journaux.
      • server.your_domain : Le serveur de collecte des journaux.

      Connectez-vous au client et au serveur dans des terminaux séparés via SSH en tant qu’utilisateur non root sudo pour commencer ce tutoriel.

      Note : tout au long du tutoriel, les blocs de commande sont étiquetés avec le nom du serveur (client ou server) sur lequel la commande doit être exécutée.

      Étape 1 — Installation de systemd-journal-remote

      Au cours de cette étape, vous installerez le paquet systemd-journal-remote sur le client et le serveur. Ce paquet contient les composants que le client et le serveur utilisent pour relayer les messages du journal.

      Tout d’abord, sur le client et le serveur, lancez une mise à jour du système pour vous assurer que la base de données de paquets et le système sont à jour :

      Client and Server

      • sudo apt update

      • sudo apt upgrade

      Ensuite, installez le paquet systemd-journal-remote :

      Client and Server

      • sudo apt install systemd-journal-remote

      Sur le serveur, activez et lancez les deux composants systemd dont il a besoin pour recevoir les messages de journal avec la commande suivante :

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket

      • sudo systemctl enable systemd-journal-remote.service

      L’option --now de la première commande permet de démarrer les services immédiatement. Vous ne l’avez pas utilisé dans la deuxième commande, car ce service ne démarrera pas tant qu’il ne disposera pas de certificats TLS, que vous créerez à l’étape suivante.

      Sur le client, activez le composant que systemd utilise pour envoyer les messages de journal au serveur :

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Ensuite, sur le serveur, ouvrez les ports 19532 et 80 dans le pare-feu UFW. Cela permettra au serveur de recevoir les messages de journal du client. Le port 80 est le port que certbot utilisera pour générer le certificat TLS. Les commandes suivantes permettent d’ouvrir ces ports :

      Server

      • sudo ufw allow in 19532/tcp

      • sudo ufw allow in 80/tcp

      Sur le client, il suffit d’ouvrir le port 80 avec cette commande :

      Client

      Vous avez maintenant installé les composants nécessaires et terminé la configuration du système de base sur le client et le serveur. Avant de pouvoir configurer ces composants pour commencer à relayer les messages du journal, vous devez enregistrer les certificats Let’s Encrypt TLS pour le client et le serveur à l’aide de l’utilitaire certbot.

      Étape 2 — Installation de Certbot et enregistrement de certificats

      Let’s Encrypt est une autorité de certification qui délivre des certificats TLS gratuits. Ces certificats permettent aux ordinateurs à la fois de crypter les données qu’ils s’envoient entre eux et de vérifier l’identité de chacun. Ce sont ces certificats qui vous permettent de sécuriser votre navigation sur Internet avec HTTPS. Les mêmes certificats peuvent être utilisés par toute autre application qui souhaite le même niveau de sécurité. La procédure d’enregistrement du certificat est la même, quelle que soit l’utilisation que vous en ferez.

      Au cours de cette étape, vous installerez l’utilitaire certbot et l’utiliserez pour enregistrer les certificats. Il se chargera également de renouveler automatiquement les certificats lorsqu’ils arriveront à expiration. La procédure d’enregistrement est ici la même sur le client et sur le serveur. Il vous suffit de changer le nom d’hôte pour qu’il corresponde à celui de l’hôte sur lequel vous exécutez la commande d’enregistrement.

      Tout d’abord, activez le référentiel universe d’Ubuntu car l’utilitaire certbot réside dans le référentiel universe. Si vous avez déjà activé le dépôt universe, l’exécution de ces commandes ne fera rien à votre système et vous pourrez les exécuter en toute sécurité :

      Client and Server

      • sudo apt install software-properties-common

      • sudo add-apt-repository universe

      • sudo apt update

      Ensuite, installez certbot sur les deux hôtes :

      Client and Server

      Maintenant que vous avez installé certbot, exécutez la commande suivante pour enregistrer les certificats sur le client et le serveur :

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Les options de cette commande signifient ce qui suit :

      • certonly : enregistrer le certificat et ne faire aucune autre modification dans le système.
      • –--standalone : utiliser le serveur web intégré de certbot pour vérifier la demande de certificat.
      • --agree-tos : accepter automatiquement les conditions d’utilisation du service Let’s Encrypt.
      • --email your_email : il s’agit de l’adresse électronique que Let’s Encrypt utilisera pour vous informer de l’expiration du certificat et d’autres informations importantes.
      • -d your_domain : le nom d’hôte pour lequel le certificat sera enregistré. Il doit correspondre au système dans lequel vous l’exécutez.

      Lorsque vous exécutez cette commande, il vous sera demandé si vous souhaitez partager l’adresse électronique avec Let’s Encrypt afin qu’ils puissent vous envoyer des bulletins d’actualités et d’autres informations sur leur travail. Cette opération est facultative. Si vous ne communiquez pas votre adresse électronique, l’enregistrement du certificat se déroulera quand même normalement.

      Lorsque le processus d’enregistrement du certificat sera terminé, il placera le certificat et les fichiers clés dans /etc/letsencrypt/live/your_domain/ où your_domain est le nom d’hôte pour lequel vous avez enregistré le certificat.

      Enfin, vous devez télécharger une copie de l’AC de Let’s Encrypt et des certificats intermédiaires, puis les placer dans le même fichier. journald utilisera ce fichier pour vérifier l’authenticité des certificats sur le client et le serveur lorsqu’ils communiquent entre eux.

      La commande suivante permet de télécharger les deux certificats sur le site web Let’s Encrypt et de les placer dans un seul fichier appelé letsencrypt-combined-certs.pem dans le répertoire personnel de votre utilisateur.

      Exécutez cette commande sur le client et le serveur pour télécharger les certificats et créer le fichier combiné :

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Ensuite, déplacez ce fichier dans le répertoire Let’s Encrypt contenant les certificats et les clés :

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Vous avez maintenant enregistré les certificats et les clés. Dans l’étape suivante, vous configurerez le serveur de collecte de journaux pour qu’il commence à écouter et à stocker les messages des journaux du client.

      Étape 3 — Configuration du serveur

      Au cours de cette étape, vous configurerez le serveur pour qu’il utilise les fichiers de certificats et de clés que vous avez générés à la dernière étape afin qu’il puisse commencer à accepter les messages de journal du client.

      systemd-journal-remote est le composant qui écoute les messages de journal. Ouvrez son fichier de configuration à l’adresse /etc/systemd/journal-remote.conf avec un éditeur de texte pour commencer à le configurer sur le serveur :

      • sudo nano /etc/systemd/journal-remote.conf

      Ensuite, décommentez toutes les lignes sous la section [Remote] et définissez les chemins d’accès aux fichiers TLS que vous venez de créer :

      /etc/systemd/journal-remote.conf

      [Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

      Voici les options que vous avez utilisées ici :

      • Seal=false : signer les données du journal dans le journal. Activez cette option si vous avez besoin d’une sécurité maximale ; sinon, vous pouvez la laisser comme false.
      • SplitMode=host : les journaux des clients distants seront répartis par hôte dans /var/log/journal/remote. Si vous préférez que tous les journaux soient ajoutés dans un seul fichier, réglez celui-ci sur SplitMode=false.
      • ServerKeyFile : le fichier de clé privée du serveur.
      • ServerCertificateFile: le fichier de certificat du serveur.
      • TrustedCertificateFile: le fichier contenant les certificats AC Let’s Encrypt.

      Maintenant, vous devez modifier les autorisations sur les répertoires de Let’s Encrypt qui contiennent les certificats et la clé afin que le systemd-journal-remote puisse les lire et les utiliser.

      Tout d’abord, modifiez les autorisations afin que le certificat et la clé privée soient lisibles :

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ensuite, changez la propriété du groupe de la clé privée pour celle du groupe de systemd-journal-remote :

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Vous pouvez maintenant lancer systemd-journal-remote :

      • sudo systemctl start systemd-journal-remote.service

      Votre serveur de collecte de journaux est maintenant en cours d’exécution et prêt à commencer à accepter les messages de journaux d’un client. Dans l’étape suivante, vous configurerez le client pour qu’il transmette les journaux à votre serveur de collecte.

      Étape 4 — Configuration du client

      Au cours de cette étape, vous configurerez le composant qui relaie les messages du journal au serveur de collecte des journaux. Ce composant s’appelle systemd-journal-upload.

      La configuration par défaut de systemd-journal-upload fait qu’il a recours à un utilisateur temporaire qui n’existe que pendant le déroulement du processus. Il est donc plus compliqué d’autoriser systemd-journal-upload à lire les certificats et les clés TLS. Pour résoudre ce problème, vous créerez un nouvel utilisateur système portant le même nom que l’utilisateur temporaire qui sera utilisé à sa place.

      Tout d’abord, créez le nouvel utilisateur appelé systemd-journal-upload sur le client avec la commande adduser suivante :

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Ces options de commande sont :

      • --system : créer le nouvel utilisateur en tant qu’utilisateur système. Elle donne à l’utilisateur un numéro UID (User Identifier) inférieur à 1000. Les UID de plus de 1 000 sont généralement attribués à des comptes utilisateurs avec lesquels un humain se connectera.
      • --home /run/systemd : définir /run/systemd comme le répertoire d’origine de cet utilisateur.
      • --no-create-home : ne pas créer le répertoire d’origine, car il existe déjà.
      • --disabled-login : l’utilisateur ne peut pas se connecter au serveur (via SSH, par exemple).
      • --group : créer un groupe portant le même nom que l’utilisateur.

      Ensuite, définissez les autorisations et la propriété des fichiers de certificat Let’s Encrypt :

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem

      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Maintenant, modifiez la configuration pour systemd-journal-upload, qui se trouve dans /etc/systemd/journal-upload.conf. Ouvrez ce fichier avec un éditeur de texte :

      • sudo nano /etc/systemd/journal-upload.conf

      Modifiez ce fichier de manière à ce qu’il ressemble à ce qui suit :

      /etc/systemd/journal-upload.conf

      [Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem

      Enfin, redémarrez le service systemd-journal-upload afin qu’il utilise la nouvelle configuration :

      • sudo systemctl restart systemd-journal-upload.service

      Votre client est maintenant configuré, en cours d’exécution et envoie ses messages au serveur de collecte de journaux. Dans l’étape suivante, vous vérifierez que les journaux sont correctement envoyés et enregistrés.

      Étape 5 — Test du client et du serveur

      Au cours de cette étape, vous vérifierez que le client relaie les messages de journaux au serveur et que le serveur les stocke correctement.

      Le serveur de collecte des journaux stocke les journaux des clients dans le répertoire /var/log/journal/remote/. Lorsque vous avez redémarré le client à la fin de la dernière étape, il a commencé à envoyer des messages de journaux ; il y a donc maintenant un fichier journal dans /var/log/journal/remote/. Le fichier sera nommé d’après le nom d’hôte que vous avez utilisé pour le certificat TLS.

      Utilisez la commande ls pour vérifier que le fichier journal du client est présent sur le serveur :

      Server

      • sudo ls -la /var/log/journal/remote/

      Cela permet d’imprimer le contenu du répertoire contenant le fichier journal :

      Output
      total 16620
drwxr-xr-x  2 systemd-journal-remote systemd-journal-remote     4096 Jun 30 16:17  .
drwxr-sr-x+ 4 root                   systemd-journal            4096 Jun 30 15:55  ..
-rw-r-----  1 systemd-journal-remote systemd-journal-remote 8388608 Jul  1 10:46 'remote-CN=client.your_domain'

      Ensuite, écrivez un message de journal sur le client pour vérifier que le serveur reçoit les messages du client comme prévu. Vous utiliserez l’utilitaire logger pour créer un message de journal personnalisé sur le client. Si tout fonctionne correctement, systemd-journal-upload transmettra ce message au serveur.

      Sur le client, exécutez la commande logger suivante :

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      Le -p syslog.debug de cette commande définit la facilité et la gravité du message. Si vous réglez ce paramètre sur syslog.debug, vous verrez qu’il s’agit d’un message de test. Cette commande enregistre le message ### TEST MESSAGE from client.your_domain ### dans le journal du client, que systemd-journal-upload transfère au serveur.

      Ensuite, lisez le fichier journal du client sur le serveur pour vérifier que les messages du journaux arrivent bien en provenance du client. Ce fichier est un fichier journal binaire, vous ne pourrez donc pas le lire avec des outils comme less. Lisez plutôt le fichier en utilisant journalctl avec l’option --file= qui vous permet de spécifier un fichier journal personnalisé :

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      Le message du journal apparaîtra comme suit :

      Test log message
      . . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Votre serveur de centralisation des journaux recueille maintenant avec succès les journaux de votre système client.

      Conclusion

      Dans cet article, vous avez mis en place un serveur central de collecte de journaux et configuré un client pour qu’il transmette une copie de ses journaux système au serveur. Vous pouvez configurer autant de clients que nécessaire pour relayer les messages au serveur de collecte de journaux en exécutant les étapes de configuration des clients que vous avez réalisées ici.



      Source link

      Forgot Your Password ?