One place for hosting & domains

      Comment développer un site web Drupal 9 sur votre machine locale en utilisant Docker et DDEV


      L’auteur a choisi le Diversity in Tech Fund​​​​​ pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      DDEV est un outil open-source qui utilise Docker dans le but de construire des environnements de développement locaux pour de nombreux cadres PHP différents. Grâce à la puissance de la conteneurisation, DDEV peut grandement simplifier la façon dont vous travaillez sur des projets multiples qui utilisent plusieurs piles technologiques et plusieurs serveurs cloud. DDEV comprend des modèles pour WordPress, Laravel, Magento, TYPO3, Drupal, et plus encore.

      Drupal 9 a été publié le 3 juin 2020 pour le CMS Drupal. Connu pour sa facilité d’utilisation et sa vaste bibliothèque de modules et de thèmes, Drupal est un cadre PHP populaire pour la création et la maintenance de divers sites web et applications de toutes tailles.

      Dans ce tutoriel, vous allez commencer à développer un site web Drupal 9 sur votre machine locale en utilisant DDEV. Cela vous permettra de construire votre site web dans un premier temps, puis, lorsque vous serez prêt, de déployer votre projet sur un serveur de production.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      Note : Il est possible de développer Drupal 9 en utilisant DDEV sur un serveur à distance, mais vous aurez besoin d’une solution pour accéder à localhost dans un navigateur web. La commande de DDEV ddev share fonctionne avec ngrok , qui crée un tunnel sécurisé vers votre serveur pour que vous et d’autres parties prenantes puissiez voir votre site de développement. Pour un usage personnel, vous pouvez également installer une interface graphique sur votre serveur à distance et accéder à votre site de développement via un navigateur web à l’intérieur de cette interface. Pour ce faire, vous pouvez suivre notre guide Comment installer et configurer VNC sur Ubuntu 20.04. Pour une solution GUI encore plus rapide, vous pouvez suivre notre guide sur la façon de configurer un bureau à distance avec X2Go sur Ubuntu 20.04.

      Étape 1 — Installer DDEV

      Au cours de cette étape, vous installerez DDEV sur votre machine locale. L’option 1 comprend des instructions pour macOS, tandis que l’option 2 fournit des instructions pour Linux. Ce tutoriel a été testé sur la version 1.15.0 de DDEV.

      Option 1 — Installation de DDEV sur macOS

      DDEV conseille aux utilisateurs de macOS d’installer leur outil en utilisant le gestionnaire de paquets Homebrew . Utilisez la commande brew suivante pour installer la dernière version stable :

      • brew tap drud/ddev && brew install drud/ddev/ddev

      Si vous préférez la version la plus récente, vous pouvez utiliser brew pour installer ddev-edge :

      • brew tap drud/ddev-edge && brew install drud/ddev-edge/ddev

      Si vous avez déjà une version de DDEV installée, ou si vous souhaitez mettre à jour votre version, arrêtez DDEV et utilisez brew pour mettre à jour votre installation :

      • ddev poweroff
      • brew upgrade ddev

      Une fois que vous avez installé ou mis à jour DDEV, exécutez  ddev version pour vérifier votre logiciel :

      Vous verrez un résultat similaire à ce qui suit :

      Output

      DDEV-Local version v1.15.0 commit v1.15.0 db drud/ddev-dbserver-mariadb-10.2:v1.15.0 dba phpmyadmin/phpmyadmin:5 ddev-ssh-agent drud/ddev-ssh-agent:v1.15.0 docker 19.03.8 docker-compose 1.25.5 os darwin router drud/ddev-router:v1.15.0 web drud/ddev-webserver:v1.15.0

      DDEV comprend un puissant CLI, ou interface de ligne de commande. Lancez ddev pour en savoir plus sur certaines commandes courantes :

      Vous verrez le résultat suivant :

      Output

      Create and maintain a local web development environment. Docs: https://ddev.readthedocs.io Support: https://ddev.readthedocs.io/en/stable/#support Usage: ddev [command] Available Commands: auth A collection of authentication commands composer Executes a composer command within the web container config Create or modify a ddev project configuration in the current directory debug A collection of debugging commands delete Remove all project information (including database) for an existing project describe Get a detailed description of a running ddev project. exec Execute a shell command in the container for a service. Uses the web service by default. export-db Dump a database to a file or to stdout help Help about any command hostname Manage your hostfile entries. import-db Import a sql file into the project. import-files Pull the uploaded files directory of an existing project to the default public upload directory of your project. list List projects logs Get the logs from your running services. pause uses 'docker stop' to pause/stop the containers belonging to a project. poweroff Completely stop all projects and containers pull Pull files and database using a configured provider plugin. restart Restart a project or several projects. restore-snapshot Restore a project's database to the provided snapshot version. sequelpro This command is not available since sequel pro.app is not installed share Share project on the internet via ngrok. snapshot Create a database snapshot for one or more projects. ssh Starts a shell session in the container for a service. Uses web service by default. start Start a ddev project. stop Stop and remove the containers of a project. Does not lose or harm anything unless you add --remove-data. version print ddev version and component versions Flags: -h, --help help for ddev -j, --json-output If true, user-oriented output will be in JSON format. -v, --version version for ddev Use "ddev [command] --help" for more information about a command.

      Pour plus d’informations sur l’utilisation de la CLI de DDEV, consultez la documentation officielle de DDEV.

      DDEV étant installée sur votre machine locale, vous êtes maintenant prêt(e) a installer Drupal 9 et à commencer à développer un site web.

      Option 2 — Installer DDEV sur Linux

      Sur un système d’exploitation Linux, vous pouvez installer DDEV en utilisant Homebrew pour Linux ou en utilisant le script d’installation officiel. Sur Ubuntu, commencez par mettre à jour votre liste de paquets dans le gestionnaire de paquets apt (vous pouvez utiliser apt dans Debian, sinon utilisez le gestionnaire de paquets équivalent associé à votre distribution Linux) :

      Installez maintenant quelques paquets pré-requis du dépôt officiel d’Ubuntu :

      • sudo apt install build-essential apt-transport-https ca-certificates software-properties-common curl

      Ces paquets vous permettront de télécharger le script d’installation de DDEV à partir de leur dépôt officiel GitHub.

      Maintenant, téléchargez le script :

      • curl -O https://raw.githubusercontent.com/drud/ddev/master/scripts/install_ddev.sh

      Avant d’exécuter le script, ouvrez-le dans nano ou votre éditeur de texte préféré et inspectez son contenu :

      nano install_ddev.sh
      

      Une fois que vous avez examiné le contenu du script et que vous êtes satisfait(e), enregistrez et fermez le fichier. Vous êtes maintenant prêt à exécuter le script d’installation.

      Utilisez la commande chmod pour rendre le script exécutable :

      Maintenant, lancez le script :

      Le processus d’installation peut vous demander de confirmer certains paramètres ou d’entrer votre mot de passe sudo. Une fois l’installation terminée, DDEV sera disponible sur votre système d’exploitation Linux.

      Exécutez la version ddev pour vérifier votre logiciel :

      Vous verrez un résultat similaire à ce qui suit :

      Output

      DDEV-Local version v1.15.0 commit v1.15.0 db drud/ddev-dbserver-mariadb-10.2:v1.15.0 dba phpmyadmin/phpmyadmin:5 ddev-ssh-agent drud/ddev-ssh-agent:v1.15.0 docker 19.03.8 docker-compose 1.25.5 os linux router drud/ddev-router:v1.15.0 web drud/ddev-webserver:v1.15.0

      DDEV est un puissant CLI, ou interface de ligne de commande. Exécutez ddev sans rien d’autre pour apprendre quelques commandes courantes :

      Vous verrez le résultat suivant :

      Output

      Create and maintain a local web development environment. Docs: https://ddev.readthedocs.io Support: https://ddev.readthedocs.io/en/stable/#support Usage: ddev [command] Available Commands: auth A collection of authentication commands composer Executes a composer command within the web container config Create or modify a ddev project configuration in the current directory debug A collection of debugging commands delete Remove all project information (including database) for an existing project describe Get a detailed description of a running ddev project. exec Execute a shell command in the container for a service. Uses the web service by default. export-db Dump a database to a file or to stdout help Help about any command hostname Manage your hostfile entries. import-db Import a sql file into the project. import-files Pull the uploaded files directory of an existing project to the default public upload directory of your project. list List projects logs Get the logs from your running services. pause uses 'docker stop' to pause/stop the containers belonging to a project. poweroff Completely stop all projects and containers pull Pull files and database using a configured provider plugin. restart Restart a project or several projects. restore-snapshot Restore a project's database to the provided snapshot version. sequelpro This command is not available since sequel pro.app is not installed share Share project on the internet via ngrok. snapshot Create a database snapshot for one or more projects. ssh Starts a shell session in the container for a service. Uses web service by default. start Start a ddev project. stop Stop and remove the containers of a project. Does not lose or harm anything unless you add --remove-data. version print ddev version and component versions Flags: -h, --help help for ddev -j, --json-output If true, user-oriented output will be in JSON format. -v, --version version for ddev Use "ddev [command] --help" for more information about a command.

      Pour plus d’informations sur l’utilisation du CLI de DDEV, vous pouvez consulter la documentation officielle de DDEV.

      DDEV étant installé sur votre machine locale, vous êtes maintenant prêt à déployer Drupal 9 et à commencer à développer un site web.

      Étape 2 — Déployer un nouveau site Drupal 9 en utilisant DDEV

      Avec l’exécution de DDEV, vous allez maintenant l’utiliser pour créer un système de fichiers spécifique à Drupal, installer Drupal 9, et ensuite lancer un projet de site web standard.

      Tout d’abord, vous allez créer un répertoire root du projet et ensuite vous déplacer à l’intérieur de celui-ci. Vous exécuterez toutes les commandes restantes à partir de cet emplacement. Ce tutoriel utilisera d9test , mais vous êtes libre de donner un autre nom à votre répertoire. Notez cependant que DDEV ne gère pas bien les noms avec trait d’union. Il est considéré comme une bonne pratique d’éviter les noms de répertoire comme my-project ou drupal-site-1.

      Créez le répertoire root de votre projet et naviguez à l’intérieur :

      DDEV excelle dans la création d’arborescences de répertoires qui correspondent à des plateformes CMS spécifiques. Utilisez la commande ddev config pour créer une structure de répertoire spécifique à Drupal 9 :

      • ddev config --project-type=drupal9 --docroot=web --create-docroot

      Vous verrez un résultat similaire à ce qui suit :

      Output

      Creating a new ddev project config in the current directory (/Users/sammy/d9test) Once completed, your configuration will be written to /Users/sammy/d9test/.ddev/config.yaml Created docroot at /Users/sammy/d9test/web You have specified a project type of drupal9 but no project of that type is found in /Users/sammy/d9test/web Ensuring write permissions for d9new No settings.php file exists, creating one Existing settings.php file includes settings.ddev.php Configuration complete. You may now run 'ddev start'.

      Parce que vous avez passé --project-type=drupal9 à votre commande ddev config, DDEV a créé plusieurs sous-répertoires et fichiers qui représentent l’organisation par défaut pour un site Drupal. L’arborescence de votre répertoire de projets ressemblera désormais à ceci :

      A Drupal 9 directory tree

      .
      ├── .ddev
      │   ├── .gitignore
      │   ├── config.yaml
      │   ├── db-build
      │   │   └── Dockerfile.example
      │   └── web-build
      │       └── Dockerfile.example
      └── web
          └── sites
              └── default
                  ├── .gitignore
                  ├── settings.ddev.php
                  └── settings.php
      
      6 directories, 7 files
      

      ddev/ sera le dossier principal pour la configuration de ddev. web/ sera le root documentaire de votre nouveau projet ; il contiendra plusieurs fichiers settings. spécifiques. Vous disposez maintenant de la structure initiale pour votre nouveau projet Drupal.

      Votrte prochaine étape consiste à initialiser votre plate-forme, qui permettra de construire les conteneurs et les configurations de réseau nécessaires.  DDEV se lie aux ports 80 et 443, donc si vous utilisez un serveur web comme Apache sur votre machine, ou tout autre chose qui utilise ces ports, arrêtez ces services avant de continuer.

      Utilisez la commande ddev start pour initialiser votre plate-forme :

      Cela permettra de construire tous les conteneurs basés sur Docker pour votre projet, qui comprennent un conteneur web, un conteneur de base de données et phpmyadmin. Une fois l’initialisation terminée, vous verrez un résultat comme celui-ci (votre numéro de port peut être différent) :

      Output

      ... Successfully started d9test Project can be reached at http://d9test.ddev.site http://127.0.0.1:32773

      Note : N’oubliez pas que DDEV démarre les conteneurs Docker en arrière-plan ici. Si vous voulez voir ces conteneurs ou vérifier qu’ils fonctionnent, vous pouvez toujours utiliser la commande docker ps :

      En plus des autres conteneurs que vous utilisez actuellement, vous trouverez quatre nouveaux conteneurs, chacun avec une image différente : php-myadmin, ddev-webserver, ddev-router, et ddev-dbserver-mariadb.

      ddev start a réussi à construire vos conteneurs et vous a donné une sortie avec deux URL. Bien que cette sortie indique que votre projet « can be reached at http://d9test.ddev.site and http://127.0.0.1:32773 », le fait de visiter ces URL maintenant entraînera une erreur. À partir de Drupal 8, le noyau de Drupal et les modules contrib fonctionnent comme des dépendances. Par conséquent, vous devez d’abord terminer l’installation de Drupal à l’aide de Composer, le gestionnaire de paquets pour les projets PHP, avant que tout ne se charge dans votre navigateur web.

      L’une des caractéristiques les plus utiles et les plus élégantes de DDEV est que vous pouvez passer les commandes de Composer par le CLI de DDEV et dans votre environnement conteneurisé. Cela signifie que vous pouvez séparer la configuration spécifique de votre machine de votre environnement de développement. Vous n’avez plus à gérer les différents problèmes de chemin de fichier, de dépendance et de version qui accompagnent généralement le développement local de PHP. De plus, vous pouvez rapidement changer de contexte entre plusieurs projets utilisant différents cadres et piles techniques avec un minimum d’effort.

      Utilisez la commande ddev composer pour télécharger drupal/recommended-project. Cela permettra de télécharger le noyau de Drupal, ses bibliothèques et d’autres ressources connexes, puis de créer un projet par défaut :

      • ddev composer create "drupal/recommended-project"

      Téléchargez maintenant un dernier composant appelé Drush, ou Drupal Shell. Ce tutoriel n’utilisera qu’une seule commande drush, et ce tutoriel fournit une alternative, mais drush est un CLI puissant pour le développement de Drupal qui peut améliorer votre efficacité.

      Utilisez ddev composer pour installer drush :

      • ddev composer require "drush/drush"

      Vous avez maintenant construit un projet Drupal 9 par défaut et installé drush. Vous allez maintenant visualiser votre projet dans un navigateur et configurer les paramètres de votre site web.

      Étape 3 — Configuration de votre projet Drupal 9

      Maintenant que vous avez installé Drupal 9, vous pouvez visiter votre nouveau projet dans votre navigateur. Pour ce faire, vous pouvez relancer ddev start et copier l’une des deux URL qu’il produit, ou vous pouvez utiliser la commande suivante, qui lancera automatiquement votre site dans une nouvelle fenêtre de navigateur :

      Vous y trouverez l’assistant d’installation standard de Drupal.

      Installateur Drupal 9 à partir du navigateur

      Vous avez ici deux possibilités. Vous pouvez utiliser cette interface utilisateur et suivre l’assistant tout au long de l’installation, ou vous pouvez retourner à votre terminal et passer une commande drush via ddev. Cette dernière option automatisera le processus d’installation et définira admin comme votre nom d’utilisateur et votre mot de passe.

      Option 1 — Utiliser l’assistant

      Retournez à l’assistant dans votre navigateur. Sous Choose language, sélectionnez une langue dans le menu déroulant et cliquez sur Save and continue. Sélectionnez maintenant un profil d’installation. Vous pouvez choisir entre Standard , Minimal , et Demo. Faites votre choix, puis cliquez sur Save and continue.  Drupal vérifiera automatiquement vos besoins, mettra en place une base de données et installera votre site. La dernière étape consiste à personnaliser quelques configurations. Ajoutez un nom de site et une adresse électronique de site qui se termine par votre domaine. Choisissez ensuite un nom d’utilisateur et un mot de passe. Choisissez un mot de passe fort et conservez vos informations d’identification dans un endroit sûr. Enfin, ajoutez une adresse électronique privée que vous vérifiez régulièrement, remplissez les paramètres régionaux, puis appuyez sur Save and continue.

      Message de bienvenue de Drupal 9 avec un avertissement sur les autorisations

      Votre nouveau site sera chargé avec un message de bienvenue.

      Option 2 — Utilisation de la ligne de commande

      Depuis le répertoire root de votre projet, lancez la commande ddev exec pour installer un site Drupal par défaut en utilisant drush :

      • ddev exec drush site:install --account-name=admin --account-pass=admin

      Votre site sera créé de la même manière que l’assistant, mais avec quelques configurations standard. Votre nom d’utilisateur et votre mot de passe seront admin.

      Lancez maintenant le site pour le visualiser dans votre navigateur :

      Vous êtes maintenant prêt à commencer à construire votre site web, mais il est considéré comme une bonne pratique de vérifier que vos autorisations sont correctes pour le répertoire /sites/web/default. Lorsque vous travaillez localement, ce n’est pas une préoccupation importante, mais si vous transférez ces autorisations à un serveur de production, elles poseront un risque de sécurité.

      Étape 4 — Vérifier vos autorisations

      Pendant l’installation de l’assistant, ou lors du premier chargement de votre page d’accueil, vous pouvez voir un avertissement concernant les paramètres des permissions dans votre répertoire /sites/web/default et un fichier à l’intérieur de ce répertoire : settings.php.

      Après l’exécution du script d’installation, Drupal essaiera de définir les permissions read et execute pour le répertoire web/sites/default, pour tous les groupes : il s’agit d’un paramètre de permissions 555. read only, ou 444. Si vous rencontrez cet avertissement, exécutez ces deux commandes `chmod` du répertoire root de votre projet. Tout manquement à cette obligation constitue un risque pour la sécurité :

      • chmod 555 web/sites/default
      • chmod 444 web/sites/default/settings.php

      Pour vérifier que vous avez les bonnes autorisations, exécutez la commande ls avec les boutons a , l , h et d :

      • ls -alhd web/sites/default web/sites/default/settings.php

      Vérifiez que vos autorisations correspondent à la sortie suivante :

      Output

      dr-xr-xr-x 8 sammy staff 256 Jul 21 12:56 web/sites/default -r--r--r-- 1 sammy staff 249 Jul 21 12:12 web/sites/default/settings.php

      Vous êtes maintenant prêt(e) à développer un site web Drupal 9 sur votre machine locale.

      Étape 5 — Créer votre premier article dans Drupal

      Pour tester certaines des fonctionnalités de Drupal, vous allez maintenant créer un message en utilisant l’interface utilisateur du web.

      Depuis la page initiale de votre site, cliquez sur le bouton Content dans le menu supérieur à gauche. Cliquez maintenant sur le bouton bleu add content. Une nouvelle page apparaîtra. Cliquez sur Article, et une autre page apparaîtra.

      Drupal 9 Créer une invite d'article  

      Ajoutez le titre et le contenu que vous souhaitez. Vous pouvez également ajouter une image, comme l’un des fonds d’écran de DigitalOcean . Lorsque vous êtes prêt, cliquez sur le bouton bleu save.

      Votre premier article apparaîtra sur votre site web.

      Création d'article par Drupal 9  

      Vous développez maintenant un site web Drupal 9 sur votre machine locale sans jamais interagir avec un serveur grâce à Docker et DDEV. Dans l’étape suivante, vous gérerez le conteneur DDEV afin d’adapter votre flux de travail.

      Étape 6 — Gérer le conteneur DDEV

      Lorsque vous avez terminé le développement de votre projet, ou lorsque vous souhaitez faire une pause, vous pouvez arrêter votre conteneur DDEV sans vous soucier de la perte de données. DDEV peut gérer un changement rapide de contexte parmi de nombreux projets ; c’est l’une de ses caractéristiques les plus utiles. Votre code et vos données sont toujours conservés dans le répertoire de votre projet, même après que vous ayez arrêté ou supprimé le conteneur DDEV.

      Pour libérer des ressources, vous pouvez arrêter DDEV à tout moment. Depuis le répertoire root de votre projet, exécutez la commande suivante :

      DDEV est disponible dans le monde entier, vous pouvez donc exécuter des commandes ddev depuis n’importe quel endroit, à condition de spécifier le projet DDEV :

      Vous pouvez également consulter tous vos projets en même temps en utilisant ddev list :

      DDEV comprend de nombreuses autres commandes utiles.

      Vous pouvez à tout moment relancer DDEV et continuer à vous développer localement.

      Conclusion

      Dans ce tutoriel, vous avez utilisé Docker et la puissance de la conteneurisation pour développer un site Drupal localement, avec l’aide de DDEV. DDEV s’intègre également bien avec de nombreux EDI et fournit un débogage PHP intégré pour Atom, PHPStorm et Visual Studio Code (vscode). Vous pouvez également en apprendre davantage sur la création d’environnements de développement pour Drupal avec DDEV ou sur le développement d’autres cadres PHP comme WordPress .



      Source link

      Comment installer et configurer Postfix en tant que serveur SMTP à envoi uniquement sur Ubuntu 18.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

      Postfix est un agent de transfert de courriel (MTA), une application utilisée pour envoyer et recevoir des courriels. Elle peut être configurée de manière à ce qu’elle puisse être utilisée pour envoyer des courriels par application locale uniquement. Cela est utile dans les situations où vous devez régulièrement envoyer des notifications par courrier électronique à partir de vos applications, ou simplement en cas de trafic sortant important qu’un fournisseur de services de courrier électronique tiers n’autoriserait pas. C’est également une alternative plus légère à l’exploitation d’un serveur SMTP complet, tout en conservant les fonctionnalités requises.

      Dans ce tutoriel, vous allez installer et configurer Postfix en tant que serveur SMTP pour l’envoi uniquement. Vous allez également demander des certificats TLS gratuits à Let’s Encrypt pour votre domaine et crypter les courriels sortants à l’aide de ces certificats.

      Conditions préalables

      • Un serveur Ubuntu 20.04 configuré avec la Configuration initiale du serveur avec Ubuntu 20.04 y compris la création d’un sudo non root user.
      • Un nom de domaine entièrement enregistré. Ce tutoriel utilisera your_domain. Vous pouvez acheter un nom de domaine sur Namecheap, en obtenir un gratuitement sur Freenom, ou utiliser le bureau d’enregistrement de domaine de votre choix.
      • Un enregistrement DNS A avec your_domain pointant sur l’adresse IP publique de votre serveur. Vous pouvez suivre cette introduction à DigitalOcean DNS pour savoir comment les ajouter.

      Note : Le nom d’hôte de votre serveur et le nom de votre Droplet doivent correspondre à your_domain car DigitalOcean établit automatiquement des enregistrements PTR pour l’adresse IP de la Droplet en fonction de son nom. 

      Vous pouvez vérifier le nom d’hôte du serveur en tapant hostname à l’invite de commande. La sortie doit correspondre au nom que vous avez donné à la Droplet lors de sa création.

      Étape 1 — Installer Postfix

      Dans cette étape, vous allez installer Postfix. Le moyen le plus rapide est d’installer le paquet mailutils qui regroupe Postfix avec quelques programmes supplémentaires que vous utiliserez pour tester l’envoi de courrier électronique. 

      Tout d’abord, mettez à jour la base de données des paquets :

      Ensuite, installez Postfix en exécutant la commande suivante :

      • sudo apt install mailutils

      Vers la fin du processus d’installation, la fenêtre de configuration de Postfix vous sera présentée :

      Sélectionnez Internet Site dans le menu, puis appuyez sur la touche TAB pour sélectionner<Ok>puis ENTRÉE 

      L’option par défaut est Site Internet. C’est l’option recommandée pour votre cas d’utilisation, donc appuyez sur TAB, puis ENTRÉE. Si vous ne voyez que le texte de la description, appuyez sur TAB pour sélectionner OK, puis sur ENTER. 

      S’il ne s’affiche pas automatiquement, exécutez la commande suivante pour le démarrer :

      • sudo dpkg-reconfigure postfix

      Après cela, vous obtiendrez une autre invite de configuration concernant le nom de messagerie du système :

      Entrez votre nom de domaine, puis appuyez sur TAB pour sélectionner<Ok>ENTRÉE

      Le nom de messagerie du système doit être le même que celui que vous avez attribué à votre serveur lors de sa création. Lorsque vous avez terminé, appuyez sur TAB, puis sur ENTRÉE.

      Vous avez maintenant installé Postfix et vous êtes prêt à commencer à le configurer.

      Étape 2 — Configurer Postfix

      Au cours de cette étape, vous configurerez Postfix pour envoyer et recevoir des courriels uniquement à partir du serveur sur lequel il fonctionne, c’est-à-dire à partir de localhost.

      Pour que cela arrive, Postfix doit être configuré pour écouter uniquement sur l’interface de bouclage, l’interface de réseau virtuel que le serveur utilise pour communiquer en interne. Pour effectuer les changements, vous devrez modifier le fichier de configuration principal de Postfix appelé main.cf, stocké sous etc/postfix. 

      Ouvrez-le pour l’éditer à l’aide de votre éditeur de texte préféré :

      • sudo nano /etc/postfix/main.cf

      Trouvez les lignes suivantes :

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = all
      . . .
      

      Définissez la valeur du paramètre inet_interfaces à loopback-only :

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = loopback-only
      . . .
      

      Une autre directive que vous devrez modifier est la directive mydestination qui spécifie la liste des domaines qui sont distribués via le transport de courrier local_transport. Par défaut, les valeurs sont similaires à celles-ci :

      /etc/postfix/main.cf

      . . .
      mydestination = $myhostname, your_domain, localhost.com, , localhost
      . . .
      

      Changez la ligne pour qu’elle ressemble à ceci :

      /etc/postfix/main.cf

      . . .
      mydestination = localhost.$mydomain, localhost, $myhostname
      . . .
      

      Si votre domaine est en fait un sous-domaine, et que vous souhaitez que les courriels aient l’air d’avoir été envoyés depuis le domaine principal, vous pouvez ajouter la ligne suivante à la fin de main.cf:

      /etc/postfix/main.cf

      ...
      masquerade_domains = your_main_domain
      

      Le paramètre facultatif masquerade_domains spécifie pour quels domaines la partie de sous-domaine sera supprimée dans l’adresse e-mail.

      Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Note : Si vous hébergez plusieurs domaines sur un seul serveur, les autres domaines peuvent également être transmis à Postfix en utilisant la directive mydestination.

      Ensuite, redémarrez Postfix en exécutant la commande suivante :

      • sudo systemctl restart postfix

      Vous avez configuré Postfix pour n’envoyer des courriels qu’à partir de votre serveur. Vous allez maintenant le tester en envoyant un exemple de message à une adresse électronique.

      Étape 3 — Tester le serveur SMTP

      Au cours de cette étape, vous allez tester si Postfix peut envoyer des courriels à un compte de messagerie externe en utilisant la commande mail qui fait partie du paquet mailutils que vous avez installé lors de la première étape.

      Pour envoyer un courriel de test, exécutez la commande suivante :

      • echo "This is the body of the email" | mail -s "This is the subject line" your_email_address

      Vous pouvez changer le corps et l’objet du courriel à votre convenance. N’oubliez pas de remplacer your_email_address avec une adresse électronique valide à laquelle vous pouvez accéder. 

      Maintenant, vérifiez l’adresse électronique à laquelle vous avez envoyé ce message. Vous devriez voir le message dans votre boîte de réception. S’il n’y est pas, vérifiez votre dossier de courrier indésirable. À ce stade, tous les courriers électroniques que vous envoyez ne sont pas cryptés, ce qui fait penser aux fournisseurs de services qu’il s’agit probablement de spam. Vous mettrez en place le cryptage plus tard, à l’étape 5.

      Si vous recevez une erreur de la part de la commande mail ou que vous n’avez pas reçu de message après une période prolongée, vérifiez que la configuration de Postfix que vous avez modifiée est valide et que le nom de votre serveur et le nom d’hôte sont définis pour votre domaine.

      Notez qu’avec cette configuration, l’adresse dans le champ de départ pour les courriels de test que vous envoyez sera sous la forme your_user_name@your_domain, où your_user_name est le nom d’utilisateur de l’utilisateur du serveur sous lequel vous avez exécuté la commande. 

      Vous avez maintenant envoyé un courriel à partir de votre serveur et vérifié qu’il a bien été reçu. Dans l’étape suivante, vous mettrez en place une redirection de courrier électronique pour root. 

      Étape 4 — Transférer le courrier système

      Au cours de cette étape, vous configurerez le transfert de courrier électronique pour l’utilisateur root afin que les messages générés par le système qui lui sont envoyés sur votre serveur soient transférés à une adresse électronique externe.

      Le fichier /etc/aliases contient une liste de noms alternatifs pour les destinataires du courrier électronique. Ouvrez-le pour le modifier :

      Dans son état par défaut, il ressemble à ceci :

      /etc/aliases

      # See man 5 aliases for format
      postmaster:    root
      

      La seule directive présente précise que les courriels générés par le système sont envoyés à root.

      Ajoutez la ligne suivante à la fin du fichier :

      /etc/aliases

      ...
      root:          your_email_address
      

      Avec cette ligne, vous précisez que les courriels envoyés à root finissent par être transférés à une adresse électronique. N’oubliez pas de remplacer your_email_address avec votre adresse électronique personnelle. Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Pour que le changement prenne effet, exécutez la commande suivante :

      L’exécution de newaliases permet de constituer une base de données des alias utilisés par la commande mail, qui sont extraits du fichier de configuration que vous venez d’éditer.

      Testez que l’envoi de courriels vers root fonctionne, en exécutant :

      • echo "This is the body of the email" | mail -s "This is the subject line" root

      Vous devriez recevoir le courriel à votre adresse électronique. S’il n’y est pas, vérifiez votre dossier spam.

      Dans cette étape, vous avez mis en place le transfert des messages générés par le système vers votre adresse électronique. Vous allez maintenant activer le cryptage des messages de sorte que tous les courriers électroniques envoyés par votre serveur sont à l’abri de toute altération pendant leur transit et seront considérés comme plus légitimes.

      Étape 5 — Activation du cryptage SMTP

      Vous allez maintenant activer le cryptage SMTP en demandant un certificat TLS gratuit à Let’s Encrypt pour votre domaine (en utilisant Certbot) et en configurant Postfix pour l’utiliser lors de l’envoi de messages.

      Ubuntu inclut Certbot dans ses référentiels de paquets par défaut ; vous pouvez donc l’installer en exécutant la commande suivante :

      Lorsqu’on vous demande une confirmation, tapez Y et appuyez sur ENTER .

      Lors de la configuration initiale du serveur dans les conditions préalables, vous avez installé ufw, le pare-feu non compliqué. Vous devrez le configurer pour autoriser le port HTTP 80 afin que la vérification du domaine puisse être effectuée. Exécutez la commande suivante pour l’activer :

      La sortie finale ressemblera à ceci :

      Output

      Rule added Rule added (v6)

      Maintenant que le port est ouvert, lancez Certbot pour obtenir un certificat :

      • sudo certbot certonly --standalone --rsa-key-size 4096 --agree-tos --preferred-challenges http -d your_domain

      Cette commande ordonne à Certbot d’émettre des certificats avec une clé RSA de 4096 bits pour faire fonctionner un serveur Web autonome temporaire (--standalone) pour la vérification, et pour vérifier via le port 80 (--preferred-challenges http). N’oubliez pas de remplacer your_domain par votre domaine avant d’exécuter la commande, et entrez votre adresse électronique lorsque vous y êtes invité. 

      Le résultat sera similaire à celui-ci :

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for `your_domain` Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2020-07-11. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      Comme indiqué dans les notes, votre certificat et votre fichier de clé privée ont été enregistrés sous /etc/letsencrypt/live/your_domain. 

      Maintenant que vous avez votre certificat, ouvrez main.cf pour l’éditer :

      • sudo nano /etc/postfix/main.cf

      Trouvez la section suivante :

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
      smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Modifiez-le pour qu’il ressemble à ceci, en remplaçant your_domain par votre domaine, si nécessaire. Cela permettra de mettre à jour vos paramètres TLS pour Postfix :

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/letsencrypt/live/your_domain/fullchain.pem
      smtpd_tls_key_file=/etc/letsencrypt/live/your_domain/privkey.pem
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Une fois que vous avez terminé, enregistrez et fermez le fichier.

      Pour appliquer les changements, redémarrez Postfix :

      • sudo systemctl restart postfix

      Maintenant, essayez d’envoyer à nouveau un courriel :

      • echo "This is the body of an encrypted email" | mail -s "This is the subject line" your_email_address

      Ensuite, vérifiez l’adresse électronique que vous avez fournie. Il est possible que vous voyiez le message dans votre boîte de réception immédiatement car les fournisseurs de messagerie électronique sont beaucoup plus susceptibles de marquer les messages non cryptés comme étant du spam.

      Vous pouvez vérifier les informations techniques concernant le message électronique dans votre client pour voir si le message est effectivement crypté.

      Conclusion

      Vous disposez maintenant d’un serveur de courrier électronique à envoi unique, alimenté par Postfix. Le cryptage de tous les messages sortants est un premier pas efficace pour que les fournisseurs de services de messagerie électronique ne marquent pas purement et simplement vos messages comme du spam. Si vous faites cela dans un scénario de développement, alors cette mesure devrait suffire.

      Cependant, si votre cas d’utilisation est l’envoi de courriels aux utilisateurs potentiels du site (comme des courriels de confirmation pour l’inscription à un forum), vous devriez envisager de créer des registres SPF afin que les courriels de votre serveur soient encore plus susceptibles d’être considérés comme légitimes.



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