RMM (Remote Management and Monitoring)

Le nom RMM provient de l'acronyme Remote Monitoring and Management.

Il s'agit d'un système centralisé permettant de créer et de planifier des tâches depuis la Console Web de Pandora FMS, qui seront ensuite exécutées localement par les agents, et de signaler au serveur les informations relatives aux exécutions effectuées et à leur état. Il est implémenté à partir de la version 778 de Pandora FMS et est distribué avec le serveur et les agents, ainsi que les composants nécessaires à son fonctionnement.

Il comprend trois composants:

• Agent RMM :

Responsable de se connecter au serveur RMM pour rechercher de nouvelles exécutions, de les effectuer si elles sont disponibles et d'envoyer deux types de fichiers : keepalive et data. Ces fichiers, au format JSON, contiennent des informations telles que le nom de l'agent, la date d'envoi du fichier, l'intervalle suivi par l'agent, l'état de l'exécution, etc.

• Serveur RMM :

Il héberge les scripts et les exécutions programmées et en file d'attente qui seront exécutées par les agents RMM.

• Service Tentacle RMM :

Il permet la connexion entre le client et le serveur RMM. Dans sa configuration, les paramètres tels que le mot de passe, les certificats utilisés pour le chiffrement de la connexion, le type de fichiers lus, et la configuration des répertoires (uniquement en lecture ou uniquement en écriture) sont définis. Par défaut, les répertoires rmm, res et queue sont uniquement en téléchargement, tandis que data et keepalive sont uniquement en écriture. Le bon fonctionnement des trois composants est essentiel pour assurer le fonctionnement du système RMM.

Comme mentionné, RMM est implémenté dans la version 778 de Pandora FMS et inclut les composants nécessaires à son fonctionnement avec le serveur et l'EndPoint.

L'installation de Pandora FMS Server inclut également la partie Tentacle, de sorte qu'une installation standard en 778 ou une mise à jour vers cette version est suffisante pour répondre aux conditions d'utilisation. Cela inclut les certificats pour le chiffrement de la connexion via Tentacle entre l'agent et le serveur RMM, bien qu'il soit possible d'utiliser ses propres certificats SSL et de changer le mot de passe de connexion.

En ce qui concerne la configuration, il s'agit d'un processus en deux étapes :

• Première étape : Activer le serveur RMM du PFMS Server.

Pour ce faire, le fichier de configuration du serveur doit être modifié. Si la configuration à distance est activée, cela doit être fait depuis la Console Web ; sinon, cela doit être fait depuis le terminal.
Il est nécessaire de modifier la ligne #rmmserver 1 dans le pandora_server.conf et de la décommenter.

Il existe également deux paramètres supplémentaires pour RMM :

• rmmserver_threads : Permet de choisir le nombre de threads dédiés à l'exécution du serveur RMM.
• rmmdir : Permet d'indiquer le répertoire local de la machine qui sera utilisé par tentacle_rmm pour gérer l'échange de données avec les agents RMM.

Lors de l'enregistrement des modifications, vous pouvez attendre leur application automatique ou redémarrer manuellement le serveur PFMS. Depuis la vue de la console Web, dans la liste des serveurs, vous pourrez vérifier visuellement si le RMM server est actif :

Vous pouvez également vérifier depuis le terminal si le processus Tentacle pour RMM est actif. Ce processus devrait être créé automatiquement après l'activation du RMM server.

• Deuxième étape : Activer l'agent RMM.

Pour activer l'agent RMM, le fichier de configuration de chaque agent doit également être modifié. Il convient de noter qu'il fonctionne aussi bien pour les agents Linux® que MS Windows®. La valeur de la ligne rmm_enabled doit être modifiée en 1.

Autres paramètres :

• rmm_interval : Détermine la fréquence à laquelle l'agent RMM vérifie s'il y a des exécutions en file d'attente pour lui-même et les exécute. Par défaut, il est réglé sur 30 secondes. Il indique également la fréquence d'envoi des fichiers .keepalive pour signaler son état de connexion.
  
• rmm_server : Indique l'adresse IP ou le nom DNS du serveur RMM. Par défaut, cette ligne est commentée et utilise la même adresse ou le même nom DNS que celui indiqué dans le paramètre server_ip pour l'EndPoint. Une adresse ou un nom différent peut être indiqué ici si le RMM server se trouve sur une machine différente de celle du PFMS server de l'EndPoint.
  
• rmm_port : Indique le port qui sera utilisé pour les connexions Tentacle, et il doit être le même que celui utilisé par le serveur PFMS. Par défaut, c'est le 41123.
  
• rmm_temp : Indique le répertoire local pour les fichiers temporaires liés aux exécutions RMM. Par défaut, il indiquera /tmp sur les agents Linux® et C:\Program Files\pandora_agent\temp sur les agents MS Windows®.
  
• rmm_extra_opts : Ce paramètre indique les options de connexion supplémentaires au service tentacle_rmm, incluant notamment le mot de passe ou la clé nécessaire pour établir la connexion via Tentacle pour les exécutions RMM. Il est configuré par défaut ; en cas de besoin, il se trouve dans le fichier /etc/tentacle/tentacle_rmm.conf du serveur, dans le paramètre password.
  
• rmm_debug : Indique le fichier local où seront stockées les entrées de logs ou de debug, si ce mode est activé. Sur les agents Linux®, c'est /var/log/pandora/pandora_rmm.debug et sur les agents MS Windows®, c'est C:\Program Files\pandora_agent\pandora_rmm.debug par défaut.
  

Une fois les modifications enregistrées, vous pouvez attendre l'intervalle suivant de l'agent ou le redémarrer manuellement. Une fois les changements effectifs, vous pouvez observer le processus pandora_rmm_agent sur l'appareil :

Comme nous l'avons mentionné, c'est l'agent qui se connecte au serveur RMM pour rechercher les exécutions à effectuer et signaler l'état de la situation. Tout cela se fait par l'intermédiaire de Tentacle à travers une connexion cryptée grâce aux certificats qui sont inclus dans l'installation du serveur Pandora FMS. Les fichiers que l'agent RMM envoie sont les fichiers .data et .keepalive.

Les fichiers .data sont envoyés au serveur uniquement lorsque des exécutions de scripts ont été effectuées dans l'intervalle de temps précédent. Ils contiennent, comme les fichiers .keepalive, le nom de l'agent (agent_name), la date de contact, l'intervalle de temps de l'agent RMM, la différence résidant dans la présence de données relatives à l'exécution effectuée. L'ID de l'exécution, l'étape où l'exécution s'est terminée, l'état au format numérique, le message de sortie (STDOUT) et le message d'erreur (STDERR) doivent être indiqués :

{
  "agent_name": "4a6d4f8f8d599d57ba3b5b7c1c0bf4450306e720c5c46d9de2ef31daf3984dca",
  "last_contact": "1731402567",
  "rmm_interval": "30",
  "script": [
    {
      "queue_id": "60",
      "step": "post",
      "status": 0,
      "output": "Execution completed successfully\n",
      "error": ""
    }
  ]
}

Les fichiers .keepalive sont envoyés à chaque intervalle de l'agent RMM et indiquent au serveur que l'agent RMM est disponible/connecté. Le contenu de ces fichiers comprend le nom de l'agent (agent_name) pour faciliter la liaison avec l'agent correspondant précédemment enregistré dans la console, un horodatage indiquant la date exacte d'envoi de ce fichier pour servir de date de dernier contact, et l'intervalle de temps qu'il suit :

{
  "agent_name": "4a6d4f8f8d599d57ba3b5b7c1c0bf4450306e720c5c46d9de2ef31daf3984dca",
  "last_contact": "1731402285",
  "rmm_interval": "30"
}

À ce stade, la communication entre l'agent et le serveur RMM doit fonctionner correctement. Vous pouvez le vérifier en accédant à la liste des agents RMM ou à la vue Heatmap dans la section Management → RMM du menu latéral gauche de la console Web.

En cas de connexion réussie entre les agents et le serveur RMM, une case différente sera affichée pour chaque agent RMM dans la vue Heatmap, représentée par une couleur ou un schéma de couleurs et une légende permettant d'interpréter l'état de l'agent RMM sur la base de ces couleurs.

La vue de la liste des agents offre le même système de couleurs pour les états des agents RMM, ainsi que des données supplémentaires telles que le nom de l'agent, son adresse IP, son système d'exploitation et sa version, ainsi que sa description (le cas échéant).

Cette vue présente tous les scripts enregistrés dans l'environnement, ainsi que des informations à leur sujet et la possibilité de créer de nouveaux scripts, de modifier ou copier les scripts existants ou de les supprimer.

Pour créer des scripts, vous disposez du même formulaire que pour les modifier. Si vous cliquez sur New script ou sur le nom d'un des scripts existants, ils seront ouverts pour la création ou l'édition.

Chaque script peut recevoir un nom, une description, indiquer le système d'exploitation dans lequel il sera utilisé ou compatible, ainsi que la version de ce système d'exploitation. Cette partie n'est qu'organisationnelle, car il n'y a pas de limitations en ce qui concerne l'attribution des exécutions aux agents RMM.

Vous devez également indiquer un groupe auquel le script appartiendra et, à côté, vous verrez une option appelée Notify before executing (Notifier avant l'exécution). Si cette option est activée, l'agent qui va exécuter ce script signalera un état de réussite avant l'exécution effective (success) du script. Cette option est utile dans les cas où le processus de l'agent RMM serait arrêté et où il serait impossible de signaler correctement les données d'exécution après l'exécution, par exemple lors du redémarrage de l'équipement. Cet état correct sera représenté dans la liste d'attente, mais d'une manière différente de l'état correct d'une exécution réellement terminée, afin qu'il puisse être facilement identifié. La colonne d'état affichera une boîte verte avec des bandes ou des lignes blanches.

La section suivante Inputs vous permettra par la suite de personnaliser un peu plus le script lors de la création des exécutions. En cliquant sur Add input, vous pouvez donner un nom, choisir un type entre chaîne (string) et ressource (resource), indiquer un conseil ou une aide sur l'input, et la valeur macro que l'input aura, qui est automatiquement remplie.

La différence entre les types string et resource réside dans le fait qu'avec une entrée chaîne, lors de la création d'une exécution, la valeur de cette entrée peut être indiquée à la main et, comme son nom l'indique, il s'agira d'un texte ou d'une chaîne de caractères.

Si un script qui redémarre un service utilise une entrée de type chaîne, ce script peut être utilisé pour une multitude de services, simplement en indiquant un service différent pour chaque exécution. Avec les entrées de ressources, vous pouvez choisir la ressource à utiliser par le script à chaque exécution. Pour ce faire, il est nécessaire de télécharger les ressources au préalable, comme nous le verrons après.

Une fois les entrées configurées, l'étape suivante consiste à configurer le script lui-même. Il existe trois types de scripts :

• Precondition script.
• Script.
• Post script.

De ces trois types, seule la configuration du script, située au milieu, est obligatoire :

La structure de configuration est la même pour les trois types de scripts. Vous pouvez indiquer les paramètres que chaque script utilisera dans le champ Parameters en indiquant le nom de la macro vu dans la section Inputs. Dans la section Interpreter, indiquez l'interpréteur de commande qui sera utilisé pour exécuter le script. Vous pouvez utiliser des interpréteurs tels que Bash, Python, Perl… en tenant toujours compte du fait qu'ils doivent être installés et disponibles dans l'environnement de l'agent.

Dans la partie File extension, l'extension du fichier de script sera indiquée, et enfin la partie Code, où le code du script lui-même sera introduit. L'extension du fichier est particulièrement importante dans les systèmes MS Windows®, car si l'extension appropriée n'est pas indiquée, les scripts ne seront pas exécutés correctement.

Une fois le script configuré, il vous suffit de cliquer sur Update configuration la configuration pour l'actualiser si vous l'avez modifié ou sur Save configuration si vous en avez créé un nouveau.

Cette vue contient les ressources téléchargées qui peuvent être utilisées ultérieurement dans les exécutions. Par défaut, cette vue n'affiche rien. Pour ce faire, vous devez télécharger vos propres ressources.

Le fichier doit être sélectionné dans l'explorateur, en cliquant sur Select a file et en indiquant un nom court (short name) qui servira d'identifiant unique pour la ressource. Lorsque vous téléchargez une ressource utilisant un short name qui existe déjà, il vous sera demandé si vous souhaitez mettre à jour la ressource précédente.

Ces ressources seront stockées, ainsi que les dossiers keepalive et data, dans le répertoire RMM indiqué dans le fichier de configuration du serveur sous le nom res.

Dans la console Web, il sera affiché comme suit :

Il est également possible de supprimer ces ressources individuellement ou en bloc. Ces ressources peuvent être utilisées comme entrées dans les scripts si le type d'entrée est défini sur Resource.

Pour pouvoir visualiser correctement les vues des Queues et des Schedules, il est nécessaire d'ajouter des exécutions dans certains agents, faute de quoi aucun contenu ne pourra être visualisé.

Pour ce faire, à partir de la Agent list ou de la Heatmap, vous pouvez accéder à la vue détaillée de l'agent que vous avez choisi en cliquant sur son nom. Vue par défaut sans aucune exécution créée :

Pour ajouter des exécutions à l'agent, il suffit de cliquer sur New execution et le formulaire de création d'exécution s'ouvre.

Le premier menu déroulant vous permet de filtrer en fonction du système d'exploitation que vous utilisez (données organisationnelles). Ensuite, avec le menu déroulant Scripts, vous pouvez choisir le script que l'exécution que vous créez utilisera.

Ensuite, vous pouvez indiquer le nom que portera l'exécution et son type de programmation :

• Only once : L'exécution sera ajoutée directement dans la file d'attente, elle sera donc exécutée immédiatement après sa création et dès que l'agent RMM lira l'exécution dans le serveur. Elles sont visibles dans la vue Queues.
• Schedule : Il s'agit d'une liste déroulante permettant de sélectionner, au format cron, le moment où cette exécution sera exécutée. Jusqu'à ce que l'heure indiquée soit atteinte, ce type d'exécutions n'apparaîtra pas dans la vue Queues, mais elles seront toujours visibles et avec l'option d'édition de la vue Schedules.

En fonction du script choisi, ses entrées, le cas échéant, apparaîtront. Le type de string vous permettra de compléter le texte selon vos besoins et le type de ressource proposera la liste des ressources RMM téléchargées dans l'environnement.

En outre, si le champ Tip est rempli en configurant les inputs, le message d'aide s'affichera :

Après avoir terminé la configuration de l'exécution, cliquez sur Confirm pour sauvegarder. Elle sera répertoriée dans la vue Agent details :

Les exécutions seront automatiquement regroupées par nom de tâche et par script, de sorte que s'il y a des exécutions à des moments différents qui partagent le même nom et le même script, leurs historiques d'exécution seront fusionnés et seront visibles en cliquant sur le bouton Execution history dans la colonne Actions du tableau.

Quant aux exécutions programmées, elles apparaîtront dans le tableau inférieur et leurs exécutions collées n'apparaîtront que lorsque le temps indiqué dans la section Cron se sera écoulé.

Dans cette vue se trouvent toutes les exécutions en file d'attente de l'environnement ainsi qu'une série de données qui permettent de les identifier.

Un certain nombre de filtres permettent de limiter les données affichées, comme la Free search (recherche dans les colonnes Task name, agent, script, step, output, error) et les filtres par scripts, status, last queue, step.

Le tableau contient également des actions permettant d'ouvrir le détail de l'exécution ou de le supprimer de la file d'attente. Si le script n'a pas encore été exécuté, cela empêchera son exécution future. S'il a été exécuté, il sera simplement supprimé de la liste des exécutions de l'agent RMM et de la vue de la file d'attente.

Pour afficher les exécutions programmées :

Des filtres peuvent être utilisés pour effectuer des recherches par agent, par script ou par heures cron spécifiées. Il est également possible de modifier les tâches ou de les supprimer.

Retour à l'index de la documentation de Pandora FMS