One place for hosting & domains

      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

      Comprendre les bases de données relationnelles


      Introduction

      Les systèmes de gestion des bases de données (SGDB ou DBMS en anglais) sont des programmes informatiques qui permettent aux utilisateurs d’interagir avec une base de données. Un SGDB permet aux utilisateurs de contrôler l’accès à une base de données, d’écrire des données, d’exécuter des requêtes et d’effectuer toute autre tâche liée à la gestion de base de données.

      Pour effectuer l’une de ces tâches, cependant, le SGDB doit avoir une sorte de modèle sous-jacent qui définit la manière dont les données sont organisées. Le modèle relationnel est une approche d’organisation des données qui ont trouvé un large usage dans le logiciel de base de données depuis sa conception initiale à la fin des années 1960, à tel point que, à partir de ce texte, quatre des cinq SGDB les plus populaires sont relationnels.

      Cet article conceptuel décrit l’historique du modèle relationnel, la manière dont les bases de données relationnelles organisent les données, et leur utilisation aujourd’hui.

      Histoire du modèle relationnel

      Les bases de données sont des groupes d’informations ou de données modélisés de manière logique**. Toute collecte de données est une base de données, quel que soit la manière dont elle est stockée ou l’endroit où elle est stockée. Même un classeur de fichiers contenant des informations sur les salaires est une base de données, tout comme une pile de formulaires de patients d’un hôpital ou la collecte d’informations sur les clients d’une entreprise répartis dans plusieurs endroits. Avant que le stockage et la gestion des données à l’aide d’ordinateurs ne soit une pratique courante, les bases de données physiques comme celles-ci étaient les seules dont disposaient les organisations gouvernementales et commerciales qui avaient besoin de stocker des informations.

      Vers le milieu du XXe siècle, les développements en informatique ont conduit à la mise au point de machines plus puissantes, ainsi qu’à une plus grande capacité de stockage local et externe. Ces progrès ont conduit les informaticiens à commencer à reconnaître le potentiel de ces machines pour stocker et gérer des quantités de données toujours plus importantes.

      Cependant, il n’existait pas de théories sur la manière dont les ordinateurs pouvaient organiser les données de manière logique et significative. C’est une chose de stocker des données non triées sur une machine, mais il est beaucoup plus compliqué de concevoir des systèmes qui vous permettent d’ajouter, récupérer, trier et gérer ces données d’une manière cohérente et pratique. La nécessité d’un cadre logique pour stocker et organiser les données a conduit à un certain nombre de propositions d’utilisation des ordinateurs pour la gestion des données.

      L’un des premiers modèles de base de données était le modèle hiérarchique, dans lequel les données sont organisées dans une structure arborescente ressemblant semblables aux systèmes de fichiers modernes. L’exemple suivant montre à quoi pourrait ressembler la disposition d’une partie d’une base de données hiérarchique utilisée pour classer les animaux : :

      Exemple Base de données hiérarchiques : catégorisation des animaux

      Le modèle hiérarchique a été largement appliqué dans les systèmes de gestion de base de données, mais il s’est également avéré peu flexible. Dans ce modèle, même si les enregistrements individuels peuvent avoir plusieurs enregistrements “enfant”, chaque enregistrement ne peut avoir qu’un seul “parent” dans la hiérarchie. Pour cette raison, ces bases de données hiérarchiques antérieures se limitaient à représenter uniquement des relations “”un à un” et “un à plusieurs” Cette absence de relations “de plusieurs à plusieurs”  pourrait entraîner des problèmes lorsque vous travaillez avec des points de données que vous souhaitez associer à plus d’un parent.

      À la fin des années 1960, Edgar F. Codd, un informaticien chez IBM, a mis au point le modèle relationnel de gestion de base de données. Le modèle relationnel de Codd a permis à des enregistrements individuels d’être associés à plus d’une table, permettant ainsi des relations “de plusieurs à plusieurs” entre les points de données en plus des relations “d’un à plusieurs”.  Cela a permis une plus grande flexibilité que d’autres modèles existants en ce qui concerne la conception des structures de base de données, ce qui signifie que les systèmes de gestion de bases de données relationnelles (SGBDR) pouvaient répondre à un éventail beaucoup plus large de besoins commerciaux.

      Codd a proposé un langage pour gérer les données relationnelles, connu sous le nom d’Alpha, qui a influencé le développement de langages de base de données ultérieurs. Deux des collègues de Codd chez IBM, Donald Chamberlin et Raymond Boyce, ont créé un tel langage inspirée d’Alpha. Ils ont appelé leur langue SEQUEL, anagramme de   S tructured  E nglish  Que ry  L anguage, mais en raison d’une marque existante ils ont raccourci le nom de leur langage à SQL (appelé de manière plus formelle Structured Query Language).

      En raison de contraintes matérielles, les premières bases de données relationnelles étaient excessivement lentes, et il a fallu un certain temps avant que la technologie ne se généralise. Mais au milieu des années 1980, le modèle relationnel de Codd a été mis en œuvre dans un certain nombre de produits de gestion de base de données commerciales d’IBM et de ses concurrents. Ces entreprises ont également suivi l’initiative d’IBM en développant et en mettant en œuvre leurs propres dialectes de SQL. En 1987, l’American National Standards Institute et l’International Organization for Standardization avaient tous deux ratifié et publié des normes pour SQL, consolidant ainsi son statut de langage accepté pour la gestion des SGBDR.

      L’utilisation du modèle relationnel dans plusieurs industries a conduit à sa reconnaissance en tant que modèle standard de gestion des données. Même avec l’essor de différentes bases de données NoSQL ces dernières années, les bases de données relationnelles restent les outils dominants pour le stockage et l’organisation des données.

      Maintenant que vous avez une compréhension générale de l’histoire du modèle relationnel, examinons de plus près la manière dont le modèle organise les données.

      Les éléments les plus fondamentaux du modèle relationnel sont les relations que les utilisateurs et les SGBDR modernes reconnaissent comme tableaux. Une relation est un ensemble de tuples, ou de lignes dans une table, avec chaque tuple partageant un ensemble d’attributs, ou colonnes :

      Exemple de diagramme indiquant comment les relations, les tuples et les attributs sont liés les uns aux autres

      Une colonne est la plus petite structure organisationnelle d’une base de données relationnelle, et représente les différentes facettes qui définissent les enregistrements de la table. D’où leur nom plus formel, les attributs. Vous pouvez penser à chaque tuple comme une instance unique de n’importe quel type de personnes, objets, événements ou associations que la table contient. Ces instances peuvent être des éléments comme les employés d’une entreprise, les ventes d’une entreprise en ligne ou les résultats de test en laboratoire. Par exemple, dans une table contenant les enregistrements des enseignants d’une école, les tuples peuvent avoir des attributs comme name, subjects, start_date, etc.

      Lorsque vous créez des colonnes, vous spécifiez un type de données qui dicte le type d’entrées autorisées dans cette colonne. Les SGBDR mettent souvent en œuvre leurs propres types de données uniques, qui peuvent ne pas être directement interchangeables avec des types de données similaires dans d’autres systèmes. Les types de données les plus courants comprennent les dates, les chaînes de caractères, les entiers et les Booléens.

      Dans le modèle relationnel, chaque table contient au moins une colonne qui peut être utilisée pour identifier de manière unique chaque ligne, appelée clé primaire. C’est important, car cela signifie que les utilisateurs n’ont pas à savoir où leurs données sont physiquement stockées sur une machine, au lieu de cela, leur SGBD peut suivre chaque enregistrement et les renvoyer sur une base ad hoc. Cela signifie que les enregistrements n’ont pas d’ordre logique défini, et que les utilisateurs ont la possibilité de renvoyer leurs données dans n’importe quel ordre ou par les filtres qu’ils souhaitent.

      Si vous souhaitez associer deux tables l’une à l’autre, vous pouvez le faire avec une clé étrangère. Une clé étrangère est essentiellement une copie de la clé primaire d’une table (la table “parent”) insérée dans une colonne d’une autre table (l’“enfant”). L’exemple suivant met en évidence la relation entre deux tableaux, l’un utilisé pour enregistrer les informations relatives aux employés d’une entreprise et l’autre utilisée pour suivre les ventes de l’entreprise. Dans cet exemple, la clé principale du tableau EMPLOYEES est utilisée comme clé étrangère du tableau SALES :

      Diagramme illustrant comment la clé principale du tableau de EMPLOYEE agit en tant que clé étrangère du tableau SALES

      Si vous essayez d’ajouter un enregistrement au tableau enfant et que la valeur saisie dans la colonne de clé étrangère n’existe pas dans la clé primaire du tableau parent, l’instruction d’insertion sera invalide. Cela aide à maintenir l’intégrité au niveau des relations, car les lignes des deux tableaux seront toujours correctement reliées.

      Les éléments structurels du modèle relationnel aident à conserver les données stockées de manière organisée, mais la conservation des données n’est utile que si vous pouvez les récupérer. Pour récupérer des informations d’un SGBDR, vous pouvez émettre une query ou une requête structurée d’un ensemble d’informations. Comme mentionné précédemment, la plupart des bases de données relationnelles utilisent SQL pour gérer et interroger les données. SQL vous permet de filtrer et de manipuler les résultats de requête avec une variété de clauses, de prédicats et d’expressions, vous donnant un contrôle précis sur les données qui apparaîtront dans l’ensemble de résultats.

      Avantages et limitations des bases de données relationnelles

      En tenant compte de la structure organisationnelle sous-jacente des bases de données relationnelles, examinons quelques-uns de leurs avantages et de leurs inconvénients.

      Aujourd’hui, tant SQL que les bases de données qui l’implémentent s’écartent du modèle relationnel de Codd de plusieurs façons. Par exemple, le modèle de Codd dicte que chaque ligne d’une table doit être unique tandis que, pour des raisons pratiques, la plupart des bases de données relationnelles modernes permettent de dupliquer les lignes. Certaines personnes ne considèrent pas les bases de données SQL comme de véritables bases de données relationnelles si elles ne respectent pas chacune des spécifications du modèle relationnel de Codd. En termes pratiques, cependant, tout SGBD qui utilise SQL et qui adhère au moins en partie au modèle relationnel est susceptible d’être appelé un système de gestion de base de données relationnelles.

      Bien que les bases de données relationnelles aient rapidement gagné en popularité, certaines des lacunes du modèle relationnel ont commencé à apparaître lorsque les données prenaient de la valeur et que les entreprises ont commencé à en stocker davantage. La scalabilité horizontale, ou scaling out, est la pratique qui consiste à ajouter plus de machines à une pile existante afin de répartir la charge et de permettre un traffic plus important et un traitement plus rapide. Cette opération est souvent opposée à la mise à la scalabilité verticale qui implique la mise à niveau du matériel d’un serveur existant, généralement en ajoutant plus de RAM ou de CPU.

      La raison pour laquelle il est difficile de faire évoluer une base de données relationnelle horizontalement est liée au fait que le modèle relationnel est conçu pour assurer la cohérence, ce qui signifie que les clients qui interrogent la même base de données récupèrent toujours les mêmes données. Si vous devez faire évoluer une base de données relationnelle horizontalement sur plusieurs machines, il devient difficile d’en garantir la cohérence car les clients peuvent parfois écrire des données sur un nœud, sans le faire sur les autres. Il y aurait probablement un délai entre l’écriture initiale et le moment où les autres nœuds sont mis à jour pour refléter les changements, ce qui entraînerait des incohérences entre eux.

      Une autre limitation présentée par les SGDBR est que le modèle relationnel a été conçu pour gérer des données structurées, ou des données qui s’alignent avec un type de données prédéfini ou qui sont au moins organisées d’une manière prédéterminée, ce qui les rend facilement triables et consultables. Toutefois, avec le développement de l’informatique personnelle et l’essor d’Internet au début des années 1990, les données non structurées — telles que les messages électroniques, les photos, les vidéos, etc. — sont devenues plus fréquentes.

      Rien de cela ne veut dire que les bases de données relationnelles ne sont pas utiles. Au contraire, le modèle relationnel est toujours le cadre dominant de la gestion des données après plus de 40 ans. Leur prévalence et leur longévité signifient que les bases de données relationnelles sont une technologie mature, qui est en soi l’un de leurs avantages majeurs. Il existe de nombreuses applications conçues pour fonctionner avec le modèle relationnel, ainsi que de nombreux administrateurs de base de données de carrière qui sont des experts en matière de bases de données relationnelles. Il existe également un large éventail de ressources disponibles sur papier et en ligne pour ceux qui souhaitent se lancer dans les bases de données relationnelles.

      Un autre avantage des bases de données relationnelles est que presque tous les SGBDR prennent en charge les transactions. Une transaction consiste en une ou plusieurs des instructions SQL individuelles exécutées en séquence comme une seule unité de travail. Les transactions présentent une approche de type tout-ou rien, ce qui signifie que chaque instruction SQL de la transaction doit être valide ; sinon, la transaction entière échouera. Ceci est très utile pour garantir l’intégrité des données lors de modifications de plusieurs lignes ou tableaux.

      Enfin, les bases de données relationnelles sont extrêmement flexibles. Elles ont été utilisées pour construire une grande variété d’applications différentes, et continuent de fonctionner efficacement même avec de très grandes quantités de données. SQL est également extrêmement puissant, vous permettant d’ajouter et de modifier des données au vol, ainsi que de modifier la structure des schémas et des tableaux de base de données sans incidence sur les données existantes.

      Conclusion

      Grâce à leur flexibilité et à leur conception pour l’intégrité des données, les bases de données relationnelles sont toujours le principal moyen de gérer et de stocker les données plus de cinquante ans après leur conception. Même avec l’essor de diverses bases de données NoSQL ces dernières années, la compréhension du modèle relationnel et de la manière de travailler avec les SGBDR sont la clé pour tous ceux qui veulent construire des applications qui exploitent la puissance des données.

      Pour en savoir plus sur quelques SGBDR open source populaires, nous vous encourageons à consulter notre comparaison de différentes bases de données SQL relationnelles open-source. Si vous souhaitez en savoir plus sur les bases de données en général, nous vous encourageons à consulter notre bibliothèque complète de contenus liés aux bases de données.



      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.

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

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