Rechercher

16.7. Utilisation des rôles du système logging avec RELP

download PDF

Reliable Event Logging Protocol (RELP) est un protocole de réseau pour l'enregistrement de données et de messages sur le réseau TCP. Il garantit une livraison fiable des messages d'événements et vous pouvez l'utiliser dans des environnements qui ne tolèrent aucune perte de message.

L'émetteur de RELP transfère les entrées de journal sous forme de commandes et le récepteur les accuse réception une fois qu'elles ont été traitées. Pour garantir la cohérence, le RELP enregistre le numéro de transaction de chaque commande transférée afin de permettre la récupération de tout type de message.

Vous pouvez envisager un système de journalisation à distance entre le client RELP et le serveur RELP. Le client RELP transfère les journaux vers le système de journalisation distant et le serveur RELP reçoit tous les journaux envoyés par le système de journalisation distant.

Les administrateurs peuvent utiliser le rôle de système logging pour configurer le système de journalisation afin qu'il envoie et reçoive des entrées de journal de manière fiable.

16.7.1. Configuration de la journalisation des clients avec RELP

Vous pouvez utiliser le rôle de système logging pour configurer la journalisation dans les systèmes RHEL qui sont journalisés sur une machine locale et peuvent transférer les journaux vers le système de journalisation distant avec RELP en exécutant un livre de jeu Ansible.

Cette procédure configure RELP sur tous les hôtes du groupe clients dans l'inventaire Ansible. La configuration de RELP utilise Transport Layer Security (TLS) pour crypter la transmission des messages afin de sécuriser le transfert des journaux sur le réseau.

Conditions préalables

  • Vous avez le droit d'exécuter des playbooks sur les nœuds gérés sur lesquels vous souhaitez configurer RELP.
  • Les nœuds gérés sont répertoriés dans le fichier d'inventaire du nœud de contrôle.
  • Les paquets ansible et rhel-system-roles sont installés sur le nœud de contrôle.

Procédure

  1. Créer un fichier playbook.yml avec le contenu suivant :

    ---
    - name: Deploying basic input and relp output
      hosts: clients
      roles:
        - rhel-system-roles.logging
      vars:
        logging_inputs:
          - name: basic_input
            type: basics
        logging_outputs:
          - name: relp_client
            type: relp
            target: _logging.server.com_
            port: 20514
            tls: true
            ca_cert: _/etc/pki/tls/certs/ca.pem_
            cert: _/etc/pki/tls/certs/client-cert.pem_
            private_key: _/etc/pki/tls/private/client-key.pem_
            pki_authmode: name
            permitted_servers:
              - '*.server.example.com'
        logging_flows:
          - name: _example_flow_
            inputs: [basic_input]
            outputs: [relp_client]

    Les playbooks utilisent les paramètres suivants :

    • target: Il s'agit d'un paramètre obligatoire qui spécifie le nom de l'hôte où le système d'enregistrement à distance est exécuté.
    • port: Numéro de port que le système d'enregistrement à distance écoute.
    • tls: Assure un transfert sécurisé des journaux sur le réseau. Si vous ne voulez pas d'enveloppe sécurisée, vous pouvez fixer la variable tls à false. Par défaut, le paramètre tls est fixé à true lorsque vous travaillez avec RELP et nécessite des clés/certificats et des triplets {ca_cert, cert, private_key} et/ou {ca_cert_src, cert_src, private_key_src}.

      • Si le triplet {ca_cert_src, cert_src, private_key_src} est défini, les emplacements par défaut /etc/pki/tls/certs et /etc/pki/tls/private sont utilisés comme destination sur le nœud géré pour transférer des fichiers depuis le nœud de contrôle. Dans ce cas, les noms de fichiers sont identiques aux noms originaux dans le triplet
      • Si le triplet {ca_cert, cert, private_key} est défini, les fichiers sont censés se trouver sur le chemin par défaut avant la configuration de l'enregistrement.
      • Si les deux triplets sont activés, les fichiers sont transférés du chemin local du nœud de contrôle au chemin spécifique du nœud géré.
    • ca_cert: Représente le chemin d'accès au certificat de l'autorité de certification. Le chemin par défaut est /etc/pki/tls/certs/ca.pem et le nom du fichier est défini par l'utilisateur.
    • cert: Représente le chemin d'accès au certificat. Le chemin par défaut est /etc/pki/tls/certs/server-cert.pem et le nom du fichier est défini par l'utilisateur.
    • private_key: Représente le chemin d'accès à la clé privée. Le chemin par défaut est /etc/pki/tls/private/server-key.pem et le nom du fichier est défini par l'utilisateur.
    • ca_cert_src: Représente le chemin d'accès au fichier CA cert local qui est copié sur l'hôte cible. Si ca_cert est spécifié, il est copié à cet emplacement.
    • cert_src: Représente le chemin d'accès au fichier local cert qui est copié sur l'hôte cible. Si cert est spécifié, il est copié à l'emplacement.
    • private_key_src: Représente le chemin d'accès au fichier de la clé locale qui est copié sur l'hôte cible. Si la clé privée est spécifiée, elle est copiée à cet emplacement.
    • pki_authmode: Accepte le mode d'authentification name ou fingerprint.
    • permitted_servers: Liste des serveurs qui seront autorisés par le client de journalisation à se connecter et à envoyer des journaux via TLS.
    • inputs: Liste des dictionnaires d'entrée de la journalisation.
    • outputs: Liste des dictionnaires de sortie de la journalisation.
  2. Facultatif : Vérifier la syntaxe du playbook.

    # ansible-playbook --syntax-check playbook.yml
  3. Exécutez le manuel de jeu :

    # ansible-playbook -i inventory_file playbook.yml

16.7.2. Configuration de la journalisation du serveur avec RELP

Vous pouvez utiliser le rôle de système logging pour configurer la journalisation dans les systèmes RHEL en tant que serveur et recevoir les journaux du système de journalisation distant avec RELP en exécutant un livre de jeu Ansible.

Cette procédure configure RELP sur tous les hôtes du groupe server dans l'inventaire Ansible. La configuration de RELP utilise TLS pour chiffrer la transmission des messages afin de sécuriser le transfert des journaux sur le réseau.

Conditions préalables

  • Vous avez le droit d'exécuter des playbooks sur les nœuds gérés sur lesquels vous souhaitez configurer RELP.
  • Les nœuds gérés sont répertoriés dans le fichier d'inventaire du nœud de contrôle.
  • Les paquets ansible et rhel-system-roles sont installés sur le nœud de contrôle.

Procédure

  1. Créer un fichier playbook.yml avec le contenu suivant :

    ---
    - name: Deploying remote input and remote_files output
      hosts: server
      roles:
        - rhel-system-roles.logging
      vars:
        logging_inputs:
          - name: relp_server
            type: relp
            port: 20514
            tls: true
            ca_cert: _/etc/pki/tls/certs/ca.pem_
            cert: _/etc/pki/tls/certs/server-cert.pem_
            private_key: _/etc/pki/tls/private/server-key.pem_
            pki_authmode: name
            permitted_clients:
              - '_*example.client.com_'
        logging_outputs:
          - name: _remote_files_output_
            type: _remote_files_
        logging_flows:
          - name: _example_flow_
            inputs: _relp_server_
            outputs: _remote_files_output_

    Les playbooks utilisent les paramètres suivants :

    • port: Numéro de port que le système d'enregistrement à distance écoute.
    • tls: Assure un transfert sécurisé des journaux sur le réseau. Si vous ne voulez pas d'enveloppe sécurisée, vous pouvez fixer la variable tls à false. Par défaut, le paramètre tls est fixé à true lorsque vous travaillez avec RELP et nécessite des clés/certificats et des triplets {ca_cert, cert, private_key} et/ou {ca_cert_src, cert_src, private_key_src}.

      • Si le triplet {ca_cert_src, cert_src, private_key_src} est défini, les emplacements par défaut /etc/pki/tls/certs et /etc/pki/tls/private sont utilisés comme destination sur le nœud géré pour transférer des fichiers depuis le nœud de contrôle. Dans ce cas, les noms de fichiers sont identiques aux noms originaux dans le triplet
      • Si le triplet {ca_cert, cert, private_key} est défini, les fichiers sont censés se trouver sur le chemin par défaut avant la configuration de l'enregistrement.
      • Si les deux triplets sont activés, les fichiers sont transférés du chemin local du nœud de contrôle au chemin spécifique du nœud géré.
    • ca_cert: Représente le chemin d'accès au certificat de l'autorité de certification. Le chemin par défaut est /etc/pki/tls/certs/ca.pem et le nom du fichier est défini par l'utilisateur.
    • cert: Représente le chemin d'accès au certificat. Le chemin par défaut est /etc/pki/tls/certs/server-cert.pem et le nom du fichier est défini par l'utilisateur.
    • private_key: Représente le chemin d'accès à la clé privée. Le chemin par défaut est /etc/pki/tls/private/server-key.pem et le nom du fichier est défini par l'utilisateur.
    • ca_cert_src: Représente le chemin d'accès au fichier CA cert local qui est copié sur l'hôte cible. Si ca_cert est spécifié, il est copié à cet emplacement.
    • cert_src: Représente le chemin d'accès au fichier local cert qui est copié sur l'hôte cible. Si cert est spécifié, il est copié à l'emplacement.
    • private_key_src: Représente le chemin d'accès au fichier de la clé locale qui est copié sur l'hôte cible. Si la clé privée est spécifiée, elle est copiée à cet emplacement.
    • pki_authmode: Accepte le mode d'authentification name ou fingerprint.
    • permitted_clients: Liste des clients qui seront autorisés par le serveur de journalisation à se connecter et à envoyer des journaux via TLS.
    • inputs: Liste des dictionnaires d'entrée de la journalisation.
    • outputs: Liste des dictionnaires de sortie de la journalisation.
  2. Facultatif : Vérifier la syntaxe du playbook.

    # ansible-playbook --syntax-check playbook.yml
  3. Exécutez le manuel de jeu :

    # ansible-playbook -i inventory_file playbook.yml
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.