The commercial editions can update their agents on Linux, Windows and Solaris automatically.
This feature enables easy updating of the agents in the case of new Checkmk versions, and even a changed configuration of the agents can be applied automatically.
In this way you can take advantage of the Agent Bakery to apply individual configurations to hosts.
 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
Les éditions commerciales peuvent mettre à jour automatiquement leurs agents sous Linux, Windows et Solaris.
Cette fonctionnalité permet de mettre à jour facilement les agents en cas de nouvelles versions de Checkmk, et même une configuration modifiée des agents peut être appliquée automatiquement.
Vous pouvez ainsi tirer parti de la boulangerie d’agents pour appliquer des configurations individuelles aux ordinateurs hôtes.
1. Configuration des mises à jour automatiques
Pour mettre en place les mises à jour, procédez comme suit : Ouvrez d'abord Setup > Agents > Windows, Linux, Solaris, AIX et sélectionnez « Agents > Automatic updates » :
Consultez Prerequisites pour obtenir la liste des conditions préalables à remplir afin que les mises à jour automatiques fonctionnent correctement.
Il vous suffit de les cocher dans l'ordre.
N'oubliez pas que vous pouvez obtenir plus d'informations sur chacun de ces éléments via Help > Show inline help.
En cliquant sur 
, vous accéderez directement au paramètre que vous devez configurer.
Plus précisément, les paramètres décrits dans les cinq sections suivantes doivent être définis, puis activés via l'Master switch.
1.1. Création d'une clé de signature
Le système est conçu de manière à ce que les agents puissent télécharger des mises à jour via HTTP ou HTTPS depuis leur serveur de supervision central. Les agents contenant du code exécutable, il est particulièrement important de se prémunir contre la possibilité que des agents falsifiés proviennent d’un attaquant. Les clés de signature sont utilisées à cette fin. Ces clés se composent d’une paire de clés publique et privée (méthode à clé publique).
Vous pouvez créer autant de clés de signature que vous le souhaitez. Chacune d'entre elles est sécurisée par une phrase de passe, que vous devrez ensuite saisir à chaque fois que vous signerez. Cela empêche, par exemple, un attaquant ayant accédé à une sauvegarde du serveur de supervision de signer des agents.
Créez ici une clé de signature et notez la phrase de passe.
|
Cette clé de signature ne pourra plus être modifiée ni restaurée ultérieurement. En cas de perte de la clé, cela peut signifier que tous les agents devront être mis à jour manuellement une nouvelle fois. |
1.2. Configuration du plugin de mise à jour
La mise à jour proprement dite est effectuée par un plugin d’agent nommé « cmk-update-agent ».
Celui-ci est appelé par l’agent selon un cycle définissable (par exemple, une fois par heure).
À ce moment-là, il demande au serveur de déploiement (votre système de surveillance central) s’il existe un nouveau paquet disponible pour cet ordinateur hôte, et si tel est le cas, il effectuera alors la mise à jour.
Le plugin doit bien sûr être présent et correctement configuré dans l’agent. Pour ce faire, ajoutez ce plugin aux agents à l’aide du jeu de règles « Agent updater (Linux, Windows, Solaris) ». Vous trouverez ce jeu de règles en cliquant sur l’entrée « Configuration of update plug-in » sur la page « Automatic agent updates ».
Notez que le jeu de règles présenté ici suit le principe « La première règle par paramètre prévaut ». Cela vous permet de définir des paramètres de base de manière générale afin de ne pas avoir à les redéfinir à chaque fois dans les règles plus spécifiques. De plus, l'aide en ligne fournit davantage d'informations sur chaque élément dès que vous l'activez.
Vous trouverez ci-dessous quelques explications sur les différents points.
Activation
Ce paramètre doit être activé (Deploy plugin …) pour permettre l’ajout du plugin à l’agent. Ici, par exemple, l’héritage des règles peut être utilisé pour définir une valeur par défaut dans un dossier de niveau supérieur et la remplacer pour des ordinateurs hôtes/dossiers individuels si nécessaire.
Mise à jour des informations sur le serveur
Vous pouvez saisir ici des données de configuration facultatives pour la connexion du programme de mise à jour de l’agent au serveur Checkmk. Si cette entrée n'est pas configurée, les informations devront être saisies ultérieurement lors de l'enregistrement du programme de mise à jour de l’agent.
Charge de travail
Dans le cas d’une supervision distribuée avec configuration centrale, le programme de mise à jour de l’agent reçoit par défaut son serveur de mise à jour correspondant de l’instance Checkmk à laquelle il se connecte. Cette option permet de configurer l’utilisation permanente du serveur de mise à jour saisi ici et d’ignorer le serveur de mise à jour automatique.
Nom DNS ou adresse IP du serveur de mise à jour
Vous saisissez ici — à quelques exceptions près — le nom du serveur sur lequel vous configurez actuellement cette règle. Vous pouvez donc copier l'URL depuis la fenêtre de votre navigateur actuel.
Une exception à cette approche serait le cas où les ordinateurs hôtes concernés devraient être « déplacés » vers un autre serveur Checkmk. Dans ce cas, saisissez ici un serveur différent, une seule fois. Voir également ci-dessous sous Scénarios d’application. Saisissez le nom DNS sous lequel le serveur Checkmk est accessible. Il est important ici que l’ordinateur hôte puisse résoudre ce nom DNS et qu’il ait été configuré en tant qu’hôte dans Checkmk. Lorsque vous utilisez HTTPS, assurez-vous que le nom du certificat correspond au nom du serveur Checkmk connu de l’ordinateur hôte.
Nom de l'instance Checkmk du serveur de mise à jour
Vous saisissez ici — à quelques exceptions près — le nom de l’instance sur laquelle vous configurez actuellement cette règle. Une exception à cette approche serait le cas où les ordinateurs hôtes concernés devraient être « déplacés » vers une autre instance Checkmk. Dans ce cas, saisissez ici une autre instance, une seule fois. Voir également ci-dessous sous Scénarios d'application. Dans le cadre d’une supervision distribuée avec configuration centrale, l’instance sur laquelle vous souhaitez vous enregistrer peut également être différente de l’instance centrale où cette règle est configurée.
Protocole à utiliser pour récupérer les mises à jour
Si, comme nous le recommandons, vous utilisez HTTPS, vous devez vous assurer que le programme de mise à jour de l’agent dispose également d’un certificat CA (CA = Autorité de certification) pour vérifier la connexion.
|
Selon la configuration du serveur, l'utilisation de HTTPS (y compris la redirection de HTTP vers HTTPS) peut être imposée. Dans ce cas, la configuration de cette règle sur HTTP n'a aucun effet. |
Certificats pour la vérification HTTPS
Les certificats CA ou auto-signés configurés ici sont mis à la disposition du programme de mise à jour de l’agent pour la vérification des connexions HTTPS. Par ailleurs, dans le cas d’une supervision distribuée avec configuration centrale, les certificats peuvent également être mis à la disposition du programme de mise à jour de l’agent depuis l’instance Checkmk, ou être importés directement lors de la connexion via des paramètres de ligne de commande.
|
Si la chaîne de certificats du serveur est signée par une autorité de certification publique, la connexion peut normalement être vérifiée sans certificats importés. Toutefois, dès que des certificats importés provenant de l’une des sources mentionnées sont mis à la disposition du programme de mise à jour de l’agent, toutes les autres autorités de certification sont ignorées ! En cas de problèmes avec la configuration du protocole HTTPS, veuillez consulter la FAQ ci-dessous. |
Intervalle de check des mises à jour
Vous spécifiez ici l'intervalle auquel le programme de mise à jour de l'agent interroge le serveur de surveillance configuré pour savoir si des mises à jour sont disponibles. Tant que l'intervalle spécifié n'est pas écoulé, un appel mis en cache est renvoyé, afin de réduire au maximum la charge réseau. Il est généralement judicieux d'utiliser un intervalle d'au moins 10 minutes, sinon le risque est très grand que votre réseau soit fortement sollicité si vous disposez d'un grand nombre d'agents Checkmk. Si vous ne définissez pas de valeur ici, une valeur par défaut de 1 heure s'appliquera.
Paramètres de proxy
Ce paramètre est également facultatif. Le programme de mise à jour de l’agent part initialement du principe qu'il existe une connexion directe au serveur Checkmk sur l'ordinateur hôte, même si des paramètres de proxy sont configurés, et ignore tous les paramètres de proxy locaux. Si tel est le comportement souhaité, ce paramètre peut donc être omis. Sinon, saisissez manuellement les paramètres de proxy ou utilisez les variables d'environnement existantes de l'ordinateur hôte.
Format de l'exécutable (Linux)
Vous pouvez, si vous le souhaitez, spécifier la manière dont le plugin est ajouté au paquet d'installation de l'agent. Le comportement par défaut de la règle dépend du système cible :
Linux (deb, rpm, tgz) : Vous n'avez rien à modifier manuellement pour ces systèmes ; la mise à jour de l’agent est fournie sous forme de binaire 64 bits. Vous pouvez également, si vous le souhaitez, sélectionner un binaire 32 bits pour les systèmes hérités, ou l'ancien script Python. Remarque : pour le binaire, vous aurez besoin du paquet glibc (version 2.5 au minimum). Les distributions Linux répondent généralement à ces exigences depuis 2006.
Windows : Pour les ordinateurs hôtes Windows, Checkmk déploiera toujours un exécutable 32 bits. Cette règle est donc ignorée par défaut. Remarque : si vous trouvez un binaire 64 bits de la mise à jour de l’agent sur l’un de vos ordinateurs hôtes Windows, cette version date d'une ancienne version de Checkmk et n'est pas à jour.
Solaris : Vous n'avez rien à modifier ici non plus. Checkmk utilisera le script Python même si vous conservez la valeur par défaut sur le binaire 64 bits.
Autres architectures : Si vous disposez de paquets pour d'autres architectures telles que arm ou ppc, définissez cette option manuellement sur Python , car Checkmk ne la détecte pas automatiquement et aucun binaire n'est proposé pour ces plateformes.
Si vous devez encore utiliser l'ancien script Python, les exigences suivantes s'appliquent au système :
Python 3, version 3.4 ou plus récente
Les modules Python requests, PySocks et pyOpenSSL
Clés de signature que l'agent acceptera
Sélectionnez au moins une clé de signature dont la signature doit être acceptée par le programme de mise à jour de l’agent. Vous pouvez également, si vous le souhaitez, spécifier plusieurs clés. Cela peut être le cas si, par exemple, vous souhaitez désactiver une ancienne clé. À cette fin, le programme de mise à jour de l’agent de l’ordinateur hôte doit, dans l’intervalle, accepter les deux clés.
Une fois ce dernier paramètre défini, votre règle pourrait ressembler à la capture d'écran suivante :
Enregistrez toutes vos entrées en cliquant sur « 
» (Enregistrer les modifications) Save.
1.3. Compilation et signature des agents
Vous pouvez ensuite immédiatement compiler et signer les agents ainsi configurés en une seule opération. En effet, les règles nouvellement créées et personnalisées ne figureront pas dans les paquets d'installation tant que vous ne les aurez pas recréées/compilées.
Pour ce faire, cliquez sur l'entrée « Baked agents » sur la page « Automatic agent updates », puis cliquez sur « Bake and sign agents ». Vous devez maintenant saisir la phrase de passe de la clé de signature. Après avoir cliqué sur « Bake and sign », le processus de compilation démarrera en arrière-plan. Une fois ce processus terminé, vous en serez informé :
Tous les agents signés de cette manière se verront attribuer un symbole 
correspondant.
Si vous avez créé plusieurs clés, signez séparément avec ces clés supplémentaires.
Il suffit que le programme de mise à jour de l’agent sur l’ordinateur hôte vérifie si le nouveau paquet a été signé avec l’une des clés connues du programme de mise à jour.
1.4. Enregistrement du programme de mise à jour de l’agent
À l'étape suivante, enregistrez les ordinateurs hôtes à surveiller sur le serveur Checkmk. Étant donné qu'un nouvel ordinateur hôte n'est pas encore considéré comme fiable par le serveur Checkmk et que ce dernier ne sait pas encore que l'ordinateur hôte doit être mis à jour automatiquement, l'agent doit être installé manuellement — une seule fois — sur l'ordinateur hôte.
Pour ce faire, rendez-vous d’abord sur Setup > Agents > Windows, Linux, Solaris, AIX et téléchargez le paquet approprié pour l’ordinateur hôte depuis la boulangerie d’agents. Assurez-vous que le paquet contient bien le plugin de mise à jour de l’agent.
Sélection d'un utilisateur pour l'enregistrement
L'enregistrement doit être effectué par un utilisateur Checkmk disposant des autorisations nécessaires.
 |
Notez que l'utilisateur de l'automatisation |
Vous pouvez effectuer l'enregistrement en tant qu'administrateur, c'est-à-dire avec un utilisateur auquel le rôle d'administrateur a été attribué, car un administrateur dispose de toutes les autorisations. Toutefois, si, pour des raisons de sécurité, vous devez utiliser un utilisateur qui n'est autorisé qu'à enregistrer une mise à jour de l’agent, vous pouvez également le faire. Vous devez créer manuellement un tel utilisateur, car Checkmk ne le crée pas automatiquement pour le moment. Pour ce faire, procédez comme suit :
Commencez par créer un nouveau rôle sur la page Setup > Users > Roles & permissions en clonant le rôle existant no_permissions.
Modifiez le nouveau rôle en lui attribuant des noms descriptifs dans les champs Internal ID et Alias et en lui attribuant uniquement les autorisations suivantes.
Le moyen le plus rapide de les trouver est de les rechercher à l'aide de Find on this page dans la longue liste de la page des autorisations :
Register host & download monitoring agents of your hosts.
Register all hosts & download all monitoring agents.
Use the GUI at all
Ensuite, sur la page Setup > Users > Users, créez un nouvel utilisateur avec un nom descriptif Username (par exemple, agent_updater_registration) et attribuez uniquement le rôle nouvellement créé à cet utilisateur.
Cliquez sur Automation secret for machine accounts pour créer le nouvel utilisateur en tant qu’utilisateur de l’automatisation.
Le mot de passe d’automatisation correspondant vous sera demandé lors de l’enregistrement.
Les sections suivantes présentent la procédure d'enregistrement avec un utilisateur de l'automatisation agent_updater_registration créé de cette manière.
Finalisation de l'enregistrement
- Linux
Copiez maintenant le paquet de l'agent sur l'ordinateur hôte et installez-le à l'aide de
rpmoudpkg(installation du paquet Linux).Une fois l'installation terminée, vous trouverez le plugin de mise à jour de l’agent dans le répertoire
/usr/lib/check_mk_agent/plugins/3600/cmk-update-agent. La valeur du sous-répertoire3600indique l'intervalle de vérification des mises à jour en secondes (ici, la valeur par défaut est d'une heure). Un script du même nom est également stocké sous/usr/bin/, de sorte que l'instructioncmk-update-agentest également disponible.Appelez maintenant le programme de mise à jour de l’agent avec l’argument
register. Saisissez les informations requises dans l’ordre.À l'aide de l'instruction suivante, vous enregistrez maintenant la mise à jour de l’agent à partir d’un ordinateur hôte Linux :
Vous pouvez également effectuer l'enregistrement en mode non interactif en saisissant les données requises via les instructions de ligne de commande. Un appel à l'
cmk-update-agent register --help. affiche ici les options configurables.- Windows
Copiez maintenant le package de l'agent sur l'ordinateur hôte et installez-le à l'aide de l'
msiexec(installation du package Windows).Après l'installation, la mise à jour de l’agent est intégrée à l’
C:\Program Files (x86)\checkmk\service\check_mk_agent.exede l’agent Windows. La mise à jour elle-même peut être contrôlée à l’aide de l’instructioncheck_mk_agent.exe updater.Appelez maintenant la mise à jour de l’agent avec l’argument
register. Sous Windows, cette opération doit être effectuée dans une invite de commande avec des droits d'administrateur. Saisissez les informations requises dans l'ordre.Comme la mise à jour de l’agent pour les ordinateurs hôtes Windows est intégrée à l’agent lui-même, l’instruction permettant de l’enregistrer se présente comme suit :
Vous pouvez également effectuer l'enregistrement en mode non interactif en saisissant les données requises via les instructions de ligne de commande. L'instruction complète pour l'enregistrement se présente comme suit :
L'option
-Spermet de transmettre le mot de passe d'utilisateur de l'automatisation.
Informations générales sur l'enregistrement
Lors de l'enregistrement, le plugin a également besoin du nom de domaine tel qu'il est connu dans la supervision. Ce nom n'est pas nécessairement identique au nom de domaine de l'ordinateur hôte. Le nom de domaine est ensuite stocké localement avec la clé.
Pour utiliser HTTPS, HTTPS doit également être configuré sur votre serveur de supervision. HTTP est beaucoup plus simple dans ce cas, mais ne permet pas de crypter la transmission. Étant donné que l'agent peut théoriquement contenir des mots de passe, HTTPS est la méthode recommandée. L'authenticité de l'agent est toutefois garantie indépendamment par la signature.
L'enregistrement n'est requis qu'une seule fois. Lors de l'enregistrement, l'agent et le serveur conviennent d'une clé secrète (secret d'ordinateur hôte) connue uniquement de cet ordinateur hôte. Le mot de passe que vous saisissez n'est enregistré nulle part.
Alors que le mode interactif interroge uniquement les champs qui ne figurent encore dans aucun fichier de configuration, le mode non interactif permet de définir tous les champs affichés dans l’aide et bénéficie de la priorité la plus élevée pour cet appel. Les options enregistrées uniquement dans
cmk-update-agent.stateseront écrasées — ce qui n’est toutefois pas le cas des options provenant decmk-update-agent.cfg. Vous trouverez plus de détails à ce sujet ci-dessous, à la section « Affichage de la configuration locale ».
Une fois l'enregistrement effectué, le secret de l'ordinateur hôte est stocké sur l'agent dans le fichier /etc/cmk-update-agent.state.
Sur le serveur, il se trouve dans ~/var/check_mk/agent_deployment/myhost.
Désormais, le secret de l'ordinateur hôte permet à ce dernier de télécharger son propre agent depuis le serveur sans avoir besoin d'un mot de passe.
Il n'est pas possible de télécharger des agents provenant d'autres ordinateurs hôtes, car ceux-ci pourraient contenir des données confidentielles.
1.5. Commutateur master
Le déploiement automatique des agents est désactivé par défaut au niveau global.
Enfin, activez-le en cliquant sur Master switch.
Cela modifie le paramètre global Activation of automatic agent updates sous Setup > General > Global Settings > Automatic Agent Updates.
Toutes les conditions devraient désormais être remplies. Le tableau « Prerequisites » devrait désormais se présenter comme suit :
Désormais, l’agent enverra un rapport à la fin de chaque intervalle de mise à jour configuré et recherchera une nouvelle version de l’agent. Si une nouvelle version est disponible — et signée —, elle sera téléchargée et installée automatiquement.
Par ailleurs, la table Master switch permet également de désactiver le processus de mise à jour de manière globale.
Un guide étape par étape est également fourni par la vidéo issue de la Checkmk Conference #3 (2017), accessible via le lien suivant. Il ne s'agit pas de la dernière version — mais la procédure de base n'a pas changé : Les nouvelles mises à jour automatiques de l'agent
1.6. Désactivation des mises à jour automatiques pour un ordinateur hôte
Si un ordinateur hôte doit être exclu des mises à jour automatiques, utilisez le jeu de règles de l’Agent updater (Linux, Windows, Solaris) pour ajuster son paramétrage de manière à ce que le plugin de mise à jour y soit désactivé. Lors de la prochaine mise à jour régulière, l’agent supprimera son propre programme de mise à jour !
Il va sans dire que la mise à jour ne pourra ensuite être réactivée qu’en installant manuellement un nouveau package d’agent. Toutefois, l’enregistrement reste intact et n’a pas besoin d’être réalisé un renouvellement.
2. Limiter les mises à jour à certains ordinateurs hôtes
Avant de déployer un nouvel agent sur un grand nombre d'ordinateurs hôtes, vous souhaiterez certainement le tester au préalable sur un nombre plus restreint d'ordinateurs hôtes. Cette étape importante permet d'éviter une erreur potentielle aux conséquences graves.
Pour cette fonction, utilisez la case centrale de la page « Automatic agent updates » :
Une conjonction logique (ET) s'applique aux conditions : seuls les ordinateurs hôtes qui répondent à tous les critères sélectionnés recevront la mise à jour. Après avoir défini ici les conditions de sélection des ordinateurs hôtes, vous pouvez utiliser le champ « Test hostname before activation » pour saisir des noms de domaine individuels et vérifier si les mises à jour pour ces ordinateurs hôtes ont été activées ou non.
Important : sur les ordinateurs hôtes qui ne doivent pas encore recevoir de mises à jour automatiques, le paquet installé ne doit pas contenir le plugin de mise à jour de l’agent — sinon, le plugin vous avertira régulièrement que l'ordinateur hôte n'a pas encore été enregistré.
3. Diagnostic
Il existe de nombreuses sources d'informations permettant de vérifier si toutes les mises à jour fonctionnent comme prévu.
3.1. Statistiques du déploiement des agents
Cet aperçu montre le comportement des différents ordinateurs hôtes dans la mise à jour de l’agent.
L’aide en ligne fournit des explications supplémentaires.
En cliquant sur « 
», vous obtenez une liste détaillée des différents ordinateurs hôtes.
Vous pouvez également accéder à la liste complète de tous les ordinateurs hôtes enregistrés via la vue de la table « Monitor > System > Agent update status ».
Vous pouvez alors y rechercher des ordinateurs hôtes individuels.
Dans cette liste, vous trouverez également des informations sur la manière dont le hachage d’un agent démarre, quel agent est destiné à un ordinateur hôte (Target Agent), quel agent a été téléchargé le plus récemment depuis l’ordinateur hôte (Downloaded Agent), et quel agent est actuellement installé sur l’ordinateur hôte (Installed Agent). De cette manière, vous pouvez toujours voir si les spécifications ont été respectées ou où en est actuellement le processus. Il convient de noter ici que les informations d’état s’affichent à gauche directement dans la communication entre la boulangerie d’agents et l’agent de mise à jour, tandis que les champs Update Check et Update Check Output proviennent du plugin de mise à jour de l’agent lors de l’interrogation de l’agent de l’ordinateur hôte, et qu’en raison de la mise en cache (définie par l’intervalle de temps), celles-ci peuvent être mises à jour à un moment différent.
3.2. Le service «Check_MK Agent »
Si vous avez installé le plugin de mise à jour de l’agent sur un agent, celui-ci transmettra régulièrement l’état actuel de la mise à jour sous forme de données de surveillance. La reconnaissance du service génère un nouveau service nommé Check_MK Agent sur l’ordinateur hôte. Celui-ci reflète à son tour l’état actuel de la mise à jour. Vous pouvez ainsi être averti de tout problème lié aux mises à jour.
L'état du service indique notamment comment la clé de signature est évaluée. Les états suivants sont possibles :
WARN : le certificat de la clé de signature est corrompu, non valide ou le deviendra dans les 90 prochains jours.
CRIT : il n'existe aucun certificat valide pour la clé de signature ou le certificat perdra sa validité dans les 30 prochains jours.
3.3. Affichage de la configuration locale
Le comportement du programme de mise à jour de l’agent est régi par les deux fichiers cmk-update-agent.cfg et cmk-update-agent.state.
Les valeurs définies dans le fichier .cfg prévalent toujours sur celles du fichier .state.
Si le programme de mise à jour de l’agent présente un comportement inattendu, il est parfois utile de vérifier la configuration.
Il existe également une fonctionnalité pratique si vous appelez le programme de mise à jour de l’agent directement depuis la ligne de commande :
3.4. Messages du journal
En cas de problème, vous trouverez également des données de journalisation concernant les mises à jour sur l'ordinateur hôte sous supervision.
Sous Linux, l'cmk-update-agente les informations importantes dans syslog, telles que les avertissements et les erreurs :
Jul 02 13:59:23 myhost [cmk-update-agent] WARNING: Missing config file at ./cmk-update-agent.cfg. Configuration may be incomplete.
Jul 02 13:59:23 myhost [cmk-update-agent] ERROR: Not yet registered at deployment server. Please run 'cmk-update-agent register' first.Un fichier journal plus détaillé cmk-update-agent.log, comprenant des informations de débogage et des traces d’appels éventuelles, est disponible sous Linux et sous Windows :
2026-01-16 07:49:23,295 [288229] DEBUG: Starting Checkmk Agent Updater v2.4.0p19
2026-01-16 07:49:23,295 [288229] DEBUG: Updating the certificate store "/var/lib/check_mk_agent/cmk-update-agent/cas/all_certs.pem"...
2026-01-16 07:49:23,297 [288229] INFO: Updated the certificate store "/var/lib/check_mk_agent/cmk-update-agent/cas/all_certs.pem" with 1 certificate(s)
...
2026-01-16 07:49:23,326 [288229] DEBUG: Successfully read /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,326 [288229] DEBUG: Successfully read /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,327 [288229] DEBUG: Saved deployment status to /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,327 [288229] INFO: Target state (from deployment server):
2026-01-16 07:49:23,327 [288229] INFO: Agent available: True
2026-01-16 07:49:23,327 [288229] INFO: Signatures: 1
2026-01-16 07:49:23,327 [288229] INFO: Target hash: 37221b87f5cb46a2
2026-01-16 07:49:23,327 [288229] INFO: Agent 37221b87f5cb46a2 already installed.
2026-01-16 07:49:23,340 [288229] DEBUG: Caught Exception:
Traceback (most recent call last):
File "cmk_update_agent.py", line 1733, in main
File "cmk_update_agent.py", line 714, in run
File "cmk_update_agent.py", line 1372, in _run_mode
File "cmk_update_agent.py", line 1071, in _do_update_as_command
File "cmk_update_agent.py", line 1150, in _do_update_agent
File "cmk_update_agent.py", line 1221, in _check_signatures
Exception: No valid signature found.Sous ces deux systèmes, vous pouvez également utiliser l'option de ligne de commande --logfile LOGFILE pour spécifier un autre chemin d'accès pour le fichier journal.
4. Cas d'utilisation
4.1. Désactivation des mises à jour automatiques des ordinateurs hôtes
Si un ordinateur hôte doit être exclu des mises à jour automatiques, modifiez son paramétrage à l'aide du jeu de règles «Agent updater (Linux, Windows, Solaris)» afin que le plugin de mise à jour y soit désactivé. Lors de la prochaine mise à jour régulière, l'agent supprimera alors lui-même son propre programme de mise à jour !
Il va sans dire que la mise à jour ne pourra alors être réactivée qu’en installant manuellement un nouveau package d’agent ! L’enregistrement est conservé et n’a pas besoin de subir un renouvellement.
4.2. Migration vers une nouvelle instance de supervision
Si vous souhaitez migrer vers une nouvelle instance Checkmk dans une configuration à site unique sans perdre les ordinateurs hôtes enregistrés sur le serveur, il convient de noter que, pour que le processus de mise à jour de l'agent aboutisse, les informations suivantes concernant le serveur et l'hôte doivent correspondre :
Pour ce faire, procédez comme suit :
Ajoutez d'abord à la supervision tous les ordinateurs hôtes dont les informations d'enregistrement doivent être migrées vers la nouvelle instance. Assurez-vous que les ordinateurs hôtes de la nouvelle instance sont supervisés sous le même nom. Copiez ensuite le dossier
~/var/check_mk/agent_deploymentde l'ancienne instance de supervision vers la nouvelle.Exportez la ou les clés de signature acceptées par les agents installés sur les ordinateurs hôtes. Les clés de signature peuvent être exportées et importées à l'aide d'Setup > Agents > Windows, Linux, Solaris, AIX > Agents > Signature keys.
Importez ces clés de signature de l'étape 2 sur la nouvelle instance de supervision.
Configurez la règle de mise à jour de l’agent sur la nouvelle instance de supervision conformément aux instructions, puis signez les agents générés à l’aide de la ou des clés de signature importées.
Enfin, dans la règle de mise à jour de l’agent sur l’ancien site, configurez les champs relatifs au serveur de mise à jour et au nom du site Checkmk conformément à votre nouveau site de supervision, puis générez à nouveau les agents. Remarque : veuillez vérifier à ce stade que vous avez tout spécifié correctement avant de régénérer les agents.
Dès que les prochaines mises à jour automatiques auront été effectuées sur les ordinateurs hôtes, l'ancien site de supervision sera désactivé. À partir de ce moment, les ordinateurs hôtes à surveiller ne répondront plus qu'au nouveau serveur Checkmk. À la suite de la deuxième mise à jour automatique, l'agent sera installé par le nouveau serveur Checkmk en conséquence.
4.3. La mise à jour de l’agent en tant qu’installateur automatique
|
Il ne s'agit pas d'une fonctionnalité officielle de la mise à jour de l’agent. Ces instructions s'adressent donc principalement aux utilisateurs plus expérimentés. La méthode officielle pour installer un agent Checkmk sur un ordinateur hôte consiste à télécharger et à exécuter le paquet d'agent adapté au système. Il est toutefois également possible de permettre l'installation initiale de l'agent Checkmk par la mise à jour de l’agent, car celle-ci fonctionne également comme un programme autonome. |
Procédez comme suit :
Copiez le binaire cmk-update-agent ou le script
cmk_update_agent.pysur l'ordinateur hôte à surveiller (les deux sont disponibles à l'adresse~/share/check_mk/agents/pluginssur le serveur Checkmk).Enregistrez l'ordinateur hôte sur le serveur Checkmk en exécutant
cmk-update-agent register. Il est judicieux ici de transmettre les informations d'enregistrement requises directement via la ligne de commande – en particulier si vous souhaitez utiliser un script d'installation. Les options correspondantes peuvent être affichées en exécutantcmk-update-agent register --help.Ensuite, à l'aide d'un dernier appel au plugin de mise à jour de l’agent, installez l'agent avec tous les détails de configuration pour l'ordinateur hôte surveillé. Cependant, comme il n'y a pas de configuration locale (la mise à jour de l’agent affiche également un avertissement correspondant) et donc pas de signature pour le paquet d'agent à télécharger, appelez à nouveau le programme de mise à jour avec
cmk-update-agent --skip-signaturesafin de faire explicitement confiance au paquet téléchargé. La condition préalable à l'installation par la mise à jour de l’agent est, bien sûr, que la boulangerie d’agents dispose d’un paquet d’agent adapté et prêt pour l’ordinateur hôte cible sur le serveur Checkmk.
5. Mises à jour des agents dans le cadre d'une supervision distribuée
Depuis la version Checkmk2.0.0 , il est également possible de déployer des agents préconfigurés via des instances distantes. Cela nécessite une supervision distribuée avec une configuration centrale et une connexion permettant aux instances distantes d'accéder à l'instance centrale via HTTP/HTTPS.
Une telle supervision distribuée peut — notamment de manière temporaire — également fonctionner avec différentes versions de Checkmk. Cela permet de faire passer progressivement des systèmes plus importants à une nouvelle version de Checkmk. Dans ce cas, veillez toutefois à respecter les remarques concernant les environnements de supervision à versions mixtes dans la supervision distribuée.
5.1. Fonctionnalité
Techniquement, la fonctionnalité est implémentée de telle sorte que les demandes de mise à jour sur les instances distantes sont transmises à l’instance centrale — de sorte que l’ensemble de la configuration ainsi que la mise à jour des agents s’effectuent exclusivement sur l’instance centrale. Les paquets d’agents déjà demandés sur une instance distante sont mis en cache sur l’instance distante (tant qu’ils sont valides), afin d’éviter de devoir les télécharger à nouveau depuis l’instance centrale. De plus, la cohérence des données demandées est checkée sur l’instance distante, ce qui permet d’éviter des connexions inutiles à l’instance centrale.
Contrairement à une configuration à site unique, le serveur de mise à jour approprié pour les ordinateurs hôtes ne provient pas exclusivement de l’ensemble de règles de la mise à jour de l’agent, mais est communiqué à l’agent de mise à jour demandeur par le site Checkmk contacté. Dans ce processus, un ordinateur hôte se voit attribuer son serveur par le site à partir duquel il est supervisé. La spécification d’un serveur Checkmk n’est donc nécessaire que pour l’enregistrement unique, qui peut théoriquement avoir lieu sur n’importe quelle instance — accessible depuis l’ordinateur hôte — de l’ensemble de la supervision distribuée. Si la connexion au serveur déterminé automatiquement échoue, le serveur précédemment enregistré (issu de la configuration des règles ou saisi manuellement lors de l’enregistrement) est utilisé comme solution de secours.
5.2. Configuration
La distribution des paquets d’agents via les instances distantes n’a pas besoin d’être activée séparément — l’instance distante concernée reconnaît automatiquement la situation et communique en conséquence avec l’instance centrale ainsi qu’avec le programme de mise à jour de l’agent qui en fait la demande. Si les agents doivent effectuer un rapport explicitement uniquement à l’instance centrale pour les mises à jour, cela peut être effectué via un serveur de mise à jour fixe défini dans le jeu de règles du programme de mise à jour de l’agent.
Toutefois, pour que les mises à jour des agents de supervision fonctionnent effectivement dans une supervision distribuée, certains paramètres doivent être définis sur l’instance centrale,
tous disponibles à l’adresse Setup > General > Global Settings > Automatic Agent Updates.
Si les paramètres diffèrent pour chaque instance distante, ils peuvent également être modifiés séparément.
Pour ce faire, rendez-vous sur Setup > General > Distributed monitoring et sélectionnez l’icône en forme d’engrenage 
dans la ligne de l’instance souhaitée pour accéder aux paramètres de cette instance Site specific global settings.
Connexion à la boulangerie d’agents centrale
À ce stade, l’URL permettant d’accéder à l’instance centrale depuis l’instance distante doit être spécifiée, y compris son protocole et la chaîne de caractères /check_mk/, par exemple https://myserver.org/mysite/check_mk/.
Bien que l’instance Checkmk tente d’identifier lui-même tous les autres paramètres manquants, la spécification de cette URL n’est pas facultative, car sinon, cette direction de connexion ne sera pas établie dans le cas d’une configuration centrale.
Si le protocole est HTTPS, l’instance distante utilise automatiquement les certificats CA ou auto-signés disponibles dans la configuration pour la vérification de la connexion Setup > General > Global Settings > Site management > Trusted certificate authorities for SSL.
Connexion à la boulangerie d’agents distants
Étant donné que les instances distantes ne sont pas nécessairement accessibles depuis les ordinateurs hôtes respectifs via la même URL que depuis l’instance centrale, une URL peut être configurée ici à cette fin. Cette URL est alors automatiquement communiquée à l’ordinateur hôte (ou à l’agent de mise à jour de l’agent) lorsqu’une connexion est établie avec une instance Checkmk. La configuration sous la forme Site specific global settings est particulièrement pertinente ici. Si aucune URL n’est spécifiée, on suppose que les instances distantes sont accessibles à la fois depuis l’instance centrale et depuis les ordinateurs hôtes sous une URL identique. S’il s’agit d’une connexion HTTPS, le certificat approprié peut également être automatiquement mis à la disposition de l’ordinateur hôte. Étant donné que le magasin CA central ne peut pas être utilisé à cette fin, les certificats appropriés peuvent être spécifiés à ce stade. Les certificats peuvent également être spécifiés dans les règles de mise à jour de l’agent.
6. Utilisation du protocole HTTPS
À plusieurs reprises dans cet article, il est fait référence à la sécurisation des connexions via HTTPS. Nous allons ici vous présenter une nouvelle fois un aperçu général des mesures à prendre pour sécuriser pleinement les connexions via HTTPS. Tant la connexion entre une instance distante et son instance centrale que celle entre un ordinateur hôte et un site Checkmk peuvent et doivent être sécurisées via TLS, c'est-à-dire en utilisant HTTPS. Cela vaut aussi bien pour une configuration à site unique que pour une supervision distribuée.
6.1. Configuration de HTTPS
Pour pouvoir se connecter à une instance Checkmk via HTTPS, il faut d’abord configurer le serveur de supervision pour HTTPS. Cela peut se faire, par exemple, via une configuration appropriée du système Apache, ou plus simplement via les paramètres HTTPS de l’appliance Checkmk.
Le fait qu’un serveur Checkmk soit alors accessible via HTTP ou HTTPS est déterminé par l’URL configurée dans chaque cas.
Si celle-ci commence par https://, le serveur est accessible via le protocole HTTPS en utilisant le port 443.
Cela s’applique également au protocole que vous avez configuré avec le paramètre Update server information.
En principe, vous pouvez forcer la redirection de HTTP vers HTTPS côté Apache et (dans un premier temps) exclure certains chemins d’accès de cette redirection.
Pour plus de détails sur la configuration, consultez la documentation Apache relative aux modules mod_rewrite et mod_redirect.
6.2. Fourniture de certificats
Pour qu’une connexion HTTPS puisse être établie, il doit être possible de vérifier la chaîne de certificats du serveur contacté ou le certificat auto-signé (selon la configuration du serveur). La mise à disposition de certificats CA ou auto-signés appropriés permet d’y parvenir et peut être réalisée de différentes manières.
Connexions d’un ordinateur hôte vers un serveur Checkmk
Le programme de mise à jour de l’agent tente toujours de vérifier les connexions HTTPS et les interrompt si la vérification s’avère impossible. Les certificats destinés à la vérification sont mis à la disposition du programme de mise à jour de l’agent à partir des sources suivantes :
L’agent de mise à jour de l’agent : Par défaut, l’agent de mise à jour de l’agent est fourni avec un environnement d’exécution Python comprenant tous les modules requis. Le lot de certificats du module Certifi est également inclus ; celui-ci s’appuie quant à lui sur la collection de certificats du projet Mozilla. Cela garantit que les autorités de certification publiques sont portées à la connaissance de l’agent de mise à jour de l’agent en temps opportun, même lorsque des mises à jour du système d’exploitation sont en attente.
Certificats via la boulangerie d’agents : Les certificats contenus dans le module Certifi sont ignorés dès qu’un ou plusieurs certificats ont été importés via l’un des mécanismes suivants. Les certificats provenant des sources suivantes sont stockés localement sur l’ordinateur hôte et utilisés uniquement par le programme de mise à jour de l’agent :
Grâce au paramètre Certificates for HTTPS verification, les certificats peuvent être intégrés dans un paquet d’agent et seront disponibles pour la mise à jour de l’agent dès l’installation (ou une mise à jour).
Lors de la configuration de la connexion à l’instance distante via Setup > General > Global settings > Automatic agent updates > Connection to remote agent bakery, vous pouvez spécifier les certificats pouvant être utilisés pour vérifier la connexion HTTPS vers l’instance distante concernée. Ceci est particulièrement utile s’il n’est pas encore clair, au moment de la configuration, quel ordinateur hôte sera attribué à quelle instance distante. Cette option d’importation peut également être utilisée pour réduire le nombre d’agents à intégrer, car les certificats appropriés pour les serveurs de mise à jour respectifs n’ont pas besoin d’être configurés spécifiquement pour chaque ordinateur hôte.
Magasin de certificats :
le programme de mise à jour de l’agent ne peut utiliser le magasin de certificats du système d'exploitation que s'il a été configuré pour utiliser le Python système (System-Python) à la place de l'environnement d'exécution Python fourni, et qu'aucun module Certifi n'est configuré dans le Python système.
Étant donné que de nombreux facteurs, tels que les paramètres d'installation ou la variable d'environnement _PIP_STANDALONE_CERT, entrent ici en jeu, nous ne prenons pas officiellement en charge une telle configuration.
Certificat via la ligne de commande - Importer un certificat :
Vous pouvez également appeler le programme de mise à jour de l’agent avec l’argument de ligne de commande --trust-cert.
Cela permet de récupérer et d'importer le certificat du serveur.
Cette opération s'effectue sans tenir compte du type de certificat :
le certificat est considéré comme fiable sans vérification supplémentaire d'une éventuelle chaîne, qu'il s'agisse d'un certificat auto-signé, d'un certificat situé à la fin d'une chaîne de certificats publique ou d'un certificat signé par une autorité de certification interne.
|
|
Certificat via la ligne de commande – Ignorer le certificat :
Si aucun certificat valide n’est disponible pour le programme de mise à jour de l’agent, la validation du certificat peut être contournée en utilisant l’argument de ligne de commande --insecure lors d’un appel.
Cela peut s’avérer utile si le certificat valide est déjà en attente d’être récupéré depuis le serveur lors de la prochaine connexion,
mais que le programme de mise à jour de l’agent serait « bloqué » par l’absence de ce certificat.
|
Cela désactive en fait complètement le check du certificat pour cet appel. La communication s'effectue toujours sous forme cryptée, l'utilisation de cet argument est donc « mieux que rien ». |
Connexion d’une instance distante vers une instance centrale
La distribution des certificats est plus simple lors d’une connexion d’une instance distante vers l’instance centrale, car la procédure de configuration n’est pas du tout exécutée. L’instance distante peut utiliser le magasin de certificats Checkmk accessible à l’adresse Global settings > Site management > Trusted certificate authorities for SSL. Il suffit donc d’importer le ou les certificats via l’instance centrale, si nécessaire également via Site specific global settings lorsque l’instance centrale est accessible sous plusieurs URL.
Procédure de remplacement d’un certificat
Si vous utilisez votre propre infrastructure de certification, vous utilisez idéalement un certificat racine valable pendant très longtemps et dont la clé associée est régulièrement utilisée pour créer des certificats intermédiaires. Ceux-ci sont ensuite utilisés à leur tour pour signer les certificats de serveur. Dans ce cas, vous déployez les certificats intermédiaires sous forme de chaîne de certificats sur le serveur Checkmk. Les ordinateurs hôtes qui reçoivent des mises à jour automatiques de l'agent n'ont désormais plus qu'à être informés de l'existence du certificat racine.
Si vous ne savez pas si un nouveau certificat de serveur nécessite un nouveau certificat racine, utilisez l'instruction suivante. Utilisez-la pour déterminer l'identifiant de la clé racine utilisée pour signer un certificat de serveur :
Si l'identifiant affiché est identique pour l'ancien et le nouveau certificat, aucune autre action n'est requise. Les ordinateurs hôtes qui font confiance à ce certificat racine peuvent continuer à obtenir des mises à jour même si la chaîne de certificats change — à condition que la chaîne ait été correctement stockée dans le système Apache.
Si un certificat auto-signé ou un certificat racine à durée de vie limitée provenant d’une autorité de certification interne a été utilisé jusqu’à présent, ou si la clé racine précédente de l’une de vos autorités de certification internes a été compromise, procédez comme suit pour remplacer le certificat :
Ajoutez le nouveau certificat à l'aide du paramètre `Certificates for HTTPS verification` (dans la règle `Agent updater (Linux, Windows, Solaris)`).
Recompilez les paquets de l'agent et mettez à jour tous les ordinateurs hôtes dans la supervision. Assurez-vous que cette mise à jour a bien été effectuée pour tous les ordinateurs hôtes avant de continuer.
Remplacez maintenant le certificat du serveur.
Effectuez un test sur quelques ordinateurs hôtes sur lesquels il est facile de réinstaller manuellement l'agent en cas d'échec, afin de vérifier s'il est possible de procéder à une nouvelle mise à jour à l'aide du nouveau certificat.
Si l'étape précédente (4) a pu être effectuée avec succès — vous pouvez (le certificat va expirer) ou devez (la clé a été compromise) — supprimer l'ancien certificat et effectuer une nouvelle mise à jour de l'agent.
7. Dépannage
Ce chapitre traite tout d'abord des erreurs courantes et générales ainsi que de leurs causes :
La mise à jour de l’agent ne s’exécute en réalité qu’une seule fois au cours de l’intervalle de mise à jour, de sorte qu’une erreur s’affichera en continu jusqu’à ce que vous lanciez le plugin manuellement ou que le prochain intervalle soit imminent.
Le programme de mise à jour de l’agent crée son propre fichier d’état cmk-update-agent.state de manière indépendante (sous Linux/Unix dans le répertoire /etc, et sous Windows dans le dossier config).
Ce fichier reste sur l’ordinateur hôte après la désinstallation, afin que les informations du registre ne soient pas perdues.
Une nouvelle installation trouvera ce fichier et continuera à l’utiliser.
Si cette situation n’est pas souhaitable, il suffit de supprimer manuellement le fichier cmk-update-agent.state après une désinstallation.
La page Monitor > System > Agent Update Status affiche tous les ordinateurs hôtes qui sont sous supervision et pour lesquels un fichier d’état existe sur le serveur Checkmk.
Peu importe que l’ordinateur hôte se connecte effectivement au serveur Checkmk pour les mises à jour automatiques.
Si un ordinateur hôte inattendu s’affiche ici, il vaut la peine de jeter un œil dans le dossier /omd/sites/mysite/var/check_mk/agent_deployment — la cause sera probablement un registre ancien ou créé par inadvertance.
L'agent de mise à jour de l’agent est conçu pour ne faire explicitement confiance qu'aux certificats qui sont généralement spécifiés sous Agent updater (Linux, Windows, Solaris) dans la configuration HTTPS. Les certificats installés localement, en particulier, sont ignorés. Il peut également arriver que le serveur Checkmk soit accessible via le navigateur, tandis que l'agent de mise à jour de l’agent ne parvient pas à établir une connexion en raison d'une configuration incorrecte.
Dans la configuration HTTPS de la règle de mise à jour de l’agent, il faut spécifier un certificat racine permettant de vérifier la connexion au serveur Checkmk. En d’autres termes : la chaîne de certificats incluse dans le certificat de serveur du serveur Checkmk doit pouvoir être vérifiée à l’aide du certificat indiqué ici. Souvent, c’est le certificat de serveur qui est spécifié à cet endroit — cela ne convient toutefois pas à cet usage.
Vérifiez la chaîne de certificats du serveur Checkmk à l'aide de l'outil OpenSSL.
En raison de la longueur de la chaîne, seule une partie pertinente est affichée ici pour plus de clarté, et les sections omises sont signalées par [...] :
Pour la dernière entrée — dans notre cas subject=/CN=mymonitoring.example.net —, vous avez besoin d’un certificat racine valide.
Celui-ci ne doit pas nécessairement être — comme dans cet exemple — l’émetteur du certificat.
Il s’agit généralement d’une chaîne d’émetteurs.
Examinez ensuite le certificat utilisé. Ici aussi, en raison de sa longueur, il sera raccourci comme dans l'exemple ci-dessus :
Le certificat de niveau supérieur — visible dans l'extrait ci-dessus — n'est pas autorisé à dépendre d'un autre certificat.
Vous pouvez constater que les chaînes Issuer et Subject sont identiques et que l'option CA:TRUE est incluse.
De plus, la chaîne d'émetteurs qui authentifie un objet doit être cohérente jusqu'à l'entrée finale.
Vous avez donc également besoin de tous les certificats intermédiaires si l'émetteur du dernier certificat n'est pas une autorité de certification (CA).
Il est arrivé à l’occasion — en particulier sur les systèmes Red Hat/CentOS — que l’appel à rpm déclenché par la mise à jour automatique échoue à plusieurs reprises,
alors qu’un appel manuel à cmk-update-agent aboutit.
Dans ces cas, la cause était une directive SELinux qui empêchait un appel sans erreur si rpm était appelé par un processus enfant de xinetd.
Vous pouvez résoudre le problème, c'est-à-dire en déterminer la cause, en analysant les journaux SELinux et en ajustant la directive en conséquence à l'aide de l'outil audit2allow.
La section suivante traite des problèmes signalés par des messages d'erreur spécifiques :
Sur certains systèmes Linux, le programme Prelink est installé et une tâche cron est activée
qui examine régulièrement tous les fichiers binaires du système et les adapte si nécessaire afin d’accélérer les programmes.
Cependant, le plugin de mise à jour de l’agent est packagé avec le programme PyInstaller, qui n’est pas compatible avec de telles actions, et est donc endommagé.
Checkmk dispose donc d’une entrée de liste noire pour les paquets deb/rpm, stockée sous /etc/prelink.conf.d,
et — si prelink existe — définit une entrée dans le fichier /etc/prelink.conf existant.
Ce problème étant difficile à gérer, il peut arriver que ces mesures ne prennent pas effet — en particulier en cas de configuration ultérieure de prelink.
Par conséquent, si vous installez prelink ultérieurement, définissez l'entrée vous-même et ajoutez la ligne suivante au fichier à l'aide de l'instruction suivante :
Ce message d'erreur apparaît lorsque le répertoire /tmp a été monté dans le système avec l'indicateur « noexec ».
Pour résoudre ce problème, vous pouvez soit supprimer l'indicateur, soit — si vous avez délibérément défini et avez besoin de cet indicateur — créer une règle sur le serveur Checkmk dans Setup sous Agents > Windows, Linux, Solaris, AIX > Agents > Agent rules > Installation paths for agent files (Linux, Unix).
Vous pouvez y définir vous-même le répertoire tmp dans l’option Directory for storage of temporary data (set TMPDIR environment variable).
Le plugin de mise à jour de l’agent écrira alors à l’avenir les fichiers temporaires dans le répertoire défini.
Cela fonctionne même si vous appelez le plugin manuellement à l’aide du script d’aide disponible à l’adresse /usr/bin/cmk-update-agent.
Si le service Check_MK Agent affiche l'avertissement « No valid signature found », cela signifie que le package d'agent destiné à l'ordinateur hôte dans la boulangerie d’agents n'a pas été signé avec l'une des clés acceptées.
Dans le cas le plus simple, il vous suffit de signer vos agents à l'aide de la fonction « Sign agents » dans la boulangerie d’agents avec l’une des clés affichées sous Signature keys the agent will accept.
Dès que la mise à jour de l’agent enverra son prochain rapport depuis l'ordinateur hôte concerné vers le serveur Checkmk, et que l'intervalle de mise en cache du service aura expiré, l'avertissement disparaîtra.
Toutefois, si l'ordinateur hôte ne dispose pas (ou ne dispose plus) d'une seule clé de signature située sur le serveur Checkmk, vous devez répéter la création et la signature à l'aide d'une clé affichée sous Signature keys the agent will accept, puis copier l'agent créé sur l'ordinateur hôte concerné et le réinstaller à cet endroit.
Sur un ordinateur hôte concerné, vous pouvez exécuter cmk-update-agent -v ou check_mk_agent.exe updater -v pour obtenir plus de détails sur cette erreur.
Le message d'erreur détaillé répertorie explicitement les signatures du fichier de configuration du plugin de mise à jour de l’agent qui n'ont pas de contrepartie acceptée (c'est-à-dire configurée) sur votre serveur Checkmk.
Ignoring signature #1 for certificate: certificate is unknown.
No valid signature found.8. Fichiers et répertoires
8.1. Chemins d'accès aux fichiers sur le serveur Checkmk
| Chemin d'accès | Description |
|---|---|
|
Contient les agents précompilés, classés d'abord dans des sous-répertoires par système d'exploitation (par exemple |
|
Contient des fichiers portant les noms des ordinateurs hôtes enregistrés. L'un de ces fichiers contient l'heure du dernier enregistrement et la clé secrète de l'ordinateur hôte. |
8.2. Chemins d'accès aux fichiers sur l'ordinateur hôte sous supervision
- Linux
Chemin d'accès au fichier Description /usr/lib/check_mk_agent/plugins/3600/cmk-update-agentLe plugin de mise à jour de l’agent sous forme de fichier binaire ou de script, selon la configuration, au format exécutable. Le sous-répertoire «
3600» correspond à l'intervalle de vérification des mises à jour en secondes (ici, la valeur par défaut est d'une heure)./usr/bin/cmk-update-agentScript permettant d'appeler le plugin de mise à jour de l’agent et d'enregistrer l'agent à l'aide de l'instruction
cmk-update-agent register./etc/check_mk/cmk-update-agent.cfgFichier de configuration du plugin de mise à jour de l’agent, qui contient les paramètres de la règle Agent updater (Linux, Windows, Solaris). Ne modifiez pas ce fichier, car il est écrit lors des installations et des mises à jour.
/etc/cmk-update-agent.stateFichier contenant les informations du registre, y compris le secret de l'ordinateur hôte.
/var/lib/check_mk_agent/cmk-update-agent.logFichier journal complet contenant les messages de débogage.
- Windows
Chemin d'accès au fichier Description C:\ProgramData\checkmk\agent\plugins\cmk_update_agent.checkmk.pyLe plugin de mise à jour de l’agent sous forme de fichier Python.
C:\Program Files (x86)\checkmk\service\check_mk_agent.exeProgramme de l'agent permettant d'enregistrer l'agent à l'aide de l'instruction «
check_mk_agent.exe updater register».C:\ProgramData\checkmk\agent\config\cmk-update-agent.cfgFichier de configuration du plugin de mise à jour de l’agent, qui contient les paramètres de la règle d'Agent updater (Linux, Windows, Solaris). Ne modifiez pas ce fichier, car il est écrit lors des installations et des mises à jour.
C:\ProgramData\checkmk\agent\config\cmk-update-agent.stateFichier contenant les informations du registre, y compris le secret de l'ordinateur hôte.
C:\ProgramData\checkmk\agent\log\cmk-update-agent.logFichier journal complet contenant des messages de débogage.
C:\ProgramData\checkmk\agent\bakery\check_mk.bakery.ymlFichier de configuration créé par la boulangerie d’agents, qui définit notamment l'intervalle de vérification des mises à jour.