One place for hosting & domains


      How To Install Cockpit on Debian 10

      The author selected the Free and Open Source Fund to receive a donation as part of the Write for DOnations program.


      Cockpit is a server administration dashboard that allows you to view the status of your server in real time. It provides information on CPU load, filesystem statistics, processes, and further information. One of Cockpit’s benefits is that it will not consume any server resources when you’re not logged in to the control panel—the service only starts when you browse to the control panel.

      You can perform server administration tasks with Cockpit, such as managing users and troubleshooting network issues. You can also access a terminal from a browser on your computer or phone. Cockpit uses your system’s users for login and system management using sudo for privilege escalation. In this way Cockpit doesn’t introduce an additional layer of security considerations to your server by creating a second set of Cockpit-only users.

      In this tutorial, you will deploy a secured Cockpit server administration dashboard on a Debian 10 server.


      Before you begin this guide, you’ll need the following:

      • One Debian 10 server configured using the Initial Server Setup with Debian 10 guide. You should configure and enable the UFW firewall as described in the guide.
      • A domain name that points to your server that you will use to access Cockpit. If you need information on pointing domain names please refer to the Domains and DNS guide. We will use the example domain name cockpit.your_domain in this tutorial. Your domain must point to your server before you start.

      Log in to your server as the sudo-enabled non-root server to begin.

      Step 1 — Installing Cockpit

      In this step, you will install Cockpit and open the port that Cockpit uses in your firewall.

      First, perform a system update using apt. This will ensure that your server has the latest packages and will avoid any errors during the Cockpit installation:

      • sudo apt update
      • sudo apt upgrade

      Next, install Cockpit:

      Now, create a directory using the mkdir command:

      • sudo mkdir -p /usr/lib/x86_64-linux-gnu/udisks2/modules

      You use the -p option so that mkdir will create several levels of directory with one invocation.

      You created this directory to stop a harmless, but distracting warning, from displaying in your Cockpit instance. This warning appears because the udisks2 utility is unable to find the /usr/lib/x86_64-linux-gnu/udisks2/modules directory, which is not created by default unless additional udisks2 are installed.

      Finally, open Cockpit’s access port 9090 and port 80 that you will use to obtain the SSL certificate in the next step:

      • sudo ufw allow 9090
      • sudo ufw allow 80

      You have now installed Cockpit and opened the ports ready to use a signed SSL certificate for your domain. You will get this certificate in the next step.

      Step 2 — Obtaining an SSL Certificate

      In this step, you will get an SSL certificate issued by Let’s Encrypt using the Certbot utility. Certbot will register and download the certificate and will also automatically renew the certificate when it expires.

      Certbot is distributed as an Ubuntu snap package. The snap utility is not installed by default on Debian 10, so you must install it as a part of the snapd package:

      Next, run the following two commands to ensure that you are running the latest version of snap:

      • sudo snap install core
      • sudo snap refresh core

      Now, install Certbot snap with the following command:

      • sudo snap install --classic certbot

      The --classic option here installs the Certbot snap in classic mode—this reduces confinement and allows access to more of your system’s resources, which is necessary for Certbot to function correctly.

      Next, create a symbolic link from /usr/bin/certbot to point to the snap-installed Certbot binary at /snap/bin/certbot with the ln utility:

      • sudo ln -s /snap/bin/certbot /usr/bin/certbot

      You need to create this symbolic link because not all utilities on Linux are aware that they should look in /snap/bin/ for program files; whereas /usr/bin/ is a standard location for user-installed programs.

      Note: A symbolic link works on Linux the same way that a shortcut works on Windows—it is a pointer from a location to the file.

      Now that you’ve installed the Certbot utility, you’ll use it to register and download the SSL certificate with the following command:

      • sudo certbot certonly --standalone --agree-tos --email your_email -d cockpit.your_domain

      You’ve used the following options:

      • certonly: Registers and downloads the SSL certificate without making other changes to the system.
      • --standalone: Uses Certbot’s built-in web server to register the certificate.
      • --agree-tos: Automatically agrees to the Terms of Service (ToS).
      • --email your_email: Takes your email address to register the certificate. (This will only be used for expiry notices and security information.)
      • -d cockpit.your_domain: Specifies the domain name that you want to use for your Cockpit instance.

      When you run this command Certbot will ask you if you want to share your email address with the Electronic Frontier Foundation (the developers of the Certbot utility) for non-essential emails. You do not have to agree to this to register the SSL certificate, so enter Y for “yes” or N “no” to continue and register the certificate.

      When the Certbot utility completes the registration, it will save your certificate files in /etc/letsencrypt/live/cockpit.your_domain.

      Cockpit has a couple of requirements for using an SSL certificate:

      1. The certificate file must contain the certificate and the private key in the same file.
      2. This certificate and key file must be located in the /etc/cockpit/ws-certs.d directory and end in .cert.

      As a result, you will need to create the certificate and key file with the SSL certificate you registered so you can use it with Cockpit. You will also need to configure Certbot to re-create this file when your certificate is renewed.

      First, create the combined certificate and key file with the following command:

      • sudo bash -c "cat /etc/letsencrypt/live/cockpit.your_domain/fullchain.pem /etc/letsencrypt/live/cockpit.your_domain/privkey.pem >/etc/cockpit/ws-certs.d/cockpit.your_domain.cert"

      You use sudo bash -c here because without it the command will fail. This is because the redirection > takes place in a different shell than the one that has the sudo permissions.

      The cat command prints the contents of the certificate and key files to standard output, so this content is then redirected with > into a new file.

      Next, you’ll create the post-renewal script that Certbot will run. This script will re-create the certificate and key file with the renewed certificate and restart the Cockpit service so it starts using it.

      Open the script at /etc/cockpit/ with a text editor:

      • sudo nano /etc/cockpit/

      Add the following code into this file:

      #!/usr/bin/env bash
      echo "Recreating Cockpit SSL Certificate"
      cat /etc/letsencrypt/live/cockpit.your_domain/fullchain.pem /etc/letsencrypt/live/cockpit.your_domain/privkey.pem > /etc/cockpit/ws-certs.d/cockpit.your_domain.cert
      echo "Restarting Cockpit"
      systemctl restart cockpit.socket

      You’ve specified the following:

      • #!/usr/bin/env bash: This is the shebang and tells Linux what program to use to execute the script. In this case, you stipulate the GNU Bash shell.
      • echo: This command prints the message that follows. You will receive this when you test the certificate renewal.
      • cat: This is the same command you ran to create the certified and key file earlier in the tutorial.
      • systemctl restart cockpit.socket: This restarts Cockpit so that it uses the new certificate.

      Make this certificate executable by changing its permissions with chmod:

      • sudo chmod 755 /etc/cockpit/

      If you are unsure about Linux file permissions refer to An Introduction to Linux Permissions for more information.

      Next you’ll configure Certbot to run this script when it renews the SSL certificate by adding a line to /etc/letsencrypt/renewal/cockpit.your_domain.conf.

      Open this file with a text editor:

      • sudo nano /etc/letsencrypt/renewal/cockpit.your_domain.conf

      Add the following line at the end of the [renewalparams] section:


      post_hook = /etc/cockpit/

      Next, test that the new configuration is working with the following command:

      • sudo certbot renew --dry-run

      The --dry-run options tells Certbot to perform a certificate renewal, but without making any changes to your certificates. You will receive the following lines at the bottom of the output:


      Running post-hook command: /etc/cockpit/ Output from post-hook command Recreating Cockpit SSL Certificate Restarting Cockpit

      This tells you that the renewal script process is working correctly for when the SSL certificate renewal happens.

      Finally, restart Cockpit to load the SSL certificate:

      • sudo systemctl restart cockpit.socket

      You’ve now fully configured your Cockpit instance and you’re ready to log in.

      Step 3 — Accessing Cockpit

      You’ve configure the Cockpit interface to listen on port 9090, so you will need to specify this port at the end of the URL that you type into your browser. Here is the URL for your Cockpit instance:

      Cockpit Login URL


      Cockpit does not keep a separate list of users, but instead uses the system’s users. These are the users that you create with the adduser command.

      You can log in with the user that you created in the initial set up guide or create a new one following the same procedure.

      The login form has a checkbox labeled Reuse my password for privileged tasks.

      Image showing the Cockpit log in fields

      If you check this option you will be able to run commands that require sudo inside Cockpit as long as the user has sudo access rights.

      The Cockpit interface has three main areas. The first is the real-time system information page. Browse to this page by locating the left-hand navigation panel and clicking on the meter icon.

      Image showing the meter icon in the left-hand navigation panel

      Clicking on this will take you to real-time graphs showing you your server’s CPU, memory, network, and disk I/O.

      The next section is the Detailed Information and Administration section. Navigate to this section by clicking on the server icon in the left-hand navigation panel.

      Image highlighting the detailed administration icon

      This section of Cockpit provides detailed information about many aspects of your system, such as the logs and system files. You can also administer some parts of your server, like adding and removing users and managing the system’s storage. You will find the browser bash terminal in this section.

      To edit your user’s Cockpit settings, click on your user icon at the top of the interface and select Account Settings. Here you can change the interface language, password, and email address.

      Image showing the account setting panel

      You’ve now accessed your Cockpit instance from your browser.


      In this tutorial, you installed Cockpit and secured your connection with an SSL certificate for your domain. You can now use your browser to view real-time resource use, administer, and access your server from a command prompt.

      You can read more about extending your Cockpit instance with the help of the official documentation.

      Source link

      Cómo centralizar los registros con Journald en Debian 10

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


      Los registros de sistemas son un componente extremadamente importante para administrar sistemas Linux. Proporcionan una visión valiosa sobre cómo funcionan los sistemas, así como sobre 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íe 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 pueden estar disponible en los hosts.
      • Los administradores de sistemas pueden acceder a los registros para todos sus sistemas a los que quizás no acceden 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 Debian 10.
      • Un usuario no root con privilegios sudo en ambos servidores. Siga la guía de configuración inicial de servidor con Debian 10 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 tanto en el cliente como 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 de la 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, tanto en el cliente como 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:


      • 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:


      • 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:


      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

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


      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 certificados 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, instale certbot y la utilidad curl en ambos hosts:

      Client and Server

      • sudo apt install certbot curl

      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 se realizan otros cambios en el sistema.
      • --standalone: se utilizar el servidor web integrado de certbot para verificar la solicitud de certificado.
      • --agree-tos: se aceptan 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. Esto debe coincidir con el sistema donde lo ejecuta.

      Cuando ejecute este comando, se le preguntará 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 CA Let’s Encrypt y de nivel intermedio 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 unos con otros.

      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{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:



      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 Let’s Encrypt CA.

      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. Esto 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 de 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 tenga el siguiente aspecto:



      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 ejecutado, y envía sus mensajes de registro al servidor de compilación de registro. En el siguiente paso, comprobará que los registros se están enviando 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 e 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 se 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:


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

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


      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:


      • 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:


      • 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.


      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 Debian 10

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


      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 Debian 10.
      • Un utilisateur non root avec des privilèges sudo sur les deux serveurs.  Suivez le guide Configuration initiale du serveur avec Debian 10 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 serveur) 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 :


      • 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 :


      • 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 :


      • 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 :


      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, installez certbot et l’utilitaire curl sur les deux hôtes :

      Client and Server

      • sudo apt install certbot curl

      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/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 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{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 :



      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 :



      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 :


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

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


      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 :


      • 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é :


      • 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.


      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