Nagios est un logiciel de supervision qui possède de nombreux plugins, parmi ces plugins, il y en a certains qui permettent d’envoyer des commandes de vérifications locales sur une machine distante.
Nagios communique donc avec un agent qui va faire des vérifications localement sur la machine cliente. Au début, NRPE (agent Linux) et winNrpe (agent Windows), semblaient être les agents parfait pour Nagios, mais les évolutions de Nagios ont fait qu’à moment donné, il y a eu des incohérences winnrpe et nsclient++ (désactivation de la couche SSL/TLS).
Finalement, après quelques recherches, il semblerait que Nagios suggère un agent : NCPA (Nagios Cross Platform Agent ou, en français agent Nagios multiplateforme).
Sommaire
Historique de NCPA (selon le site de Nagios)
Les origines de la NCPA remontent à la conférence mondiale Nagios de 2012, où un administrateur réseau a déclaré :
Je n’ai aucune idée de la raison pour laquelle les agents sont si difficiles. Après avoir réfléchi à cette déclaration, nous n’avions pas de réponse. L’idée de faire de NCPA un agent de surveillance unique, sécurisé, simple et facile à gérer a été formée.
En 2014, la première version de NCPA a été publiée avec les fonctionnalités de base qui sont au cœur du projet, comme l’API multiplateforme.
Aujourd’hui, NCPA a parcouru un long chemin depuis l’idée initiale de 2014. Il comprend d’innombrables fonctionnalités supplémentaires, avec beaucoup d’autres en cours de développement.
À propos des agents
Les agents peuvent fonctionner sous deux modes :
-
Active Checks : c’est Nagios qui, via
check_ncpa
, demande l’exécution d’une vérification (sujet traité dans cette publication). - Passive Checks (NRDP) : l’agent exécute des vérifications définies dans son fichier de configuration et envoie le résultat à un serveur de supervision doté du module NRDP. Ce module NRDP est inclus dans Nagios XI. Pour plus d’information sur les passive checks, la documentation « getting started » explique comment configurer l’agent et Nagios pour réalise ce type de supervision.
Note : si on veut comparer NCPA par rapport à NRPE, NCPA ne contient pas de ligne de configuration de check
prêt à être utilisé.
Autre point, dans NRPE, il y avait un module ou fonction qui permettait d’avoir le loadavg
du système, ce n’est plus possible avec NCPA, il faut utiliser les fonctions liées au CPU.
Check_ncpa
C’est le plugin qui doit être installé sur le serveur Nagios. Il s’agit d’un script python.
Attention, sous CentOS 8, il y a un problème de version de python.
En effet, l’exécutable s’appelle python2
sur CentOS 8 et non python
donc, il faut adapter le script python check_ncpa
pour qu’il appelle python2
.
#!/usr/bin/env python
SYNOPSIS
vers
#!/usr/bin/env python2
SYNOPSIS
NdM : la documentation du script stipulant qu'il est compatible python2 et 3, il semblerait que cet avertissement ne soit plus d'actualité.
Sinon, pour la partie serveur, le check_ncpa est installé, il ne reste plus qu’à l’appeler ou plutôt l’utiliser.
Mais avant de l’appeler, il faut installer les agents sur les serveurs à superviser.
Installation de l’agent
Pour l’installation de l’agent sur le serveur, il y a un exécutable 32-bits pour Windows et un RPM 64-bits sous Linux ainsi qu’une version pour MacOS.
Durant l’installation sous Windows, un community_string est demandé, ce n’est pas le cas sous Linux. Ce community_string est très important, car c’est la clé d’authentification entre l’agent et check_ncpa (Nagios).
L’installation de l’agent va soit créer un service sous Windows, soit un daemon sous Linux. Ainsi, sous Linux, pour activer, démarrer, arrêter ncpa, on utilisera systemctl
avec comme nom de process : ncpa_listener
. Et, sous Windows, il suffit d’aller dans services.msc
.
Comme pour les autres types d’agent, il y a un fichier de configuration, fichier où est stocké notamment le community_string. Il s’agit du fichier ncpa.cfg
.
Le fichier est localisé :
- sous Linux :
/usr/local/ncpa/etc/ncpa.cfg
. - sous Windows :
c:\program files (x86)\Nagios\ncpa\etc\ncpa.cfg
.
Étrangement, il n’est pas actif par défaut. Par sécurité, je recommanderais donc d’activer la ligne admin_auth_only = 1
.
En mettant admin_auth_only = 1
, on active la demande d’un mot de passe sur l’interface GUI. Et il y a bien sur dans ce fichier ncpa.cfg, le paramètre community_string = xxxxxxxxxxxx
.
Si on veut changer le token (community_string) après installation, il faut redémarrer les services ou process installé sur le serveur.
Pour les exemples, je vais partir du principe que Nagios est installé dans /usr/local/nagios.
Pour tester que l’agent fonctionne bien, on peut aller sur le serveur Nagios et exécuter la commande suivante :
/usr/local/nagios/libexec/check_ncpa.py -H <host> -t '<token>' -P 5693 -M system/agent_version
Exemples de check
Voici un exemple d’appel décrit dans les fichiers de Nagios. Il faut préalablement décrire le plugin dans le fichier command.cfg de Nagios :
define command {
command_name check_ncpa
command_line $USER1$/check_ncpa.py -H $HOSTADDRESS$ $ARG1$
}
Check CPU :
check_ncpa!-t '<token>' -M 'cpu/percent' -q aggregate=avg -w 90 -c 99
Check DISK :
Les \ et / doivent être représentés par un | (barre verticale).
Windows :
check_ncpa !-t '<token>' -P 5693 -M 'disk/logical/C:|/used_percent' --warning 90 --critical 95
Linux :
check_ncpa !-t '<token>' -P 5693 -M 'disk/logical/|/used_percent' --warning 90 --critical 95
Check Memory :
check_ncpa !-t '<token>' -P 5693 -M 'memory/virtual' --warning 90 --critical 95
Check Services (Windows):
check_ncpa ! -t '<token>' -P 5693 -M 'services' -q 'service=<nom du service>,check=1'
Check Process (Linux):
check_ncpa !-t '<token>' -P 5693 -M 'processes' -q 'name=<nom du process>'
OU
check_ncpa -t '<token>' -P 5693 -M 'processes' -q 'cmd=<nom du process>, match=search' -c 1:1
Attention, il faut faire quelques tests, et de plus, avec un Windows en Français, il y a un risque de message d’erreurs (en tout cas sur le fait d’avoir la liste complète des process). C’est un problème constaté et signalé.
L’interface web de l’agent permet de voir les essais ou checks effectués.
Pour les tests, il est toujours possible de faire des essais via la ligne de commande.
Ex :
/opt/nagios/libexec/check_ncpa.py -H <host> -t '<token>' -P 5693 -M 'processes' -q 'cmd=robotProm.jar,match=search' -c 1:1
Plugins
Il est possible de faire des plugins, des scripts Windows ou Linux à mettre dans le répertoire plugins de l’agent ncpa.
Exemple :
#!/bin/bash
nbProcess=`ps aux | grep java | grep tomcat | wc -l`
echo $nbProcess
if [ $nbProcess -eq 1 ]; then
ret=0
comment="Tomcat process is running"
else
ret=2
comment="No tomcat process"
fi;
if [[ -z $ret ]]; then
echo "No exit code was supplied, aborting!"
exit
fi
if [[ -z $comment ]]; then
echo "No dummy message was supplied, aborting!"
exit
fi
echo $comment
exit $ret
Si, lors des premiers checks, il y a le message : CRITICAL: Incorrect credentials given →
, il faudra vérifier l’orthographe du token.
Conclusion
Cet article ne couvre pas tout NCPA, mais permet de présenter le produit et les usages les plus communs.
Il faut constater qu’il y a presque autant de type d’agent (NRPE, NCPA, nsclient++…) qu’il y a de serveur de supervision (Nagios, Centreon, Shinken…) mais, si on suit Nagios, NCPA est l’agent recommandé.
Aller plus loin
- NCPA - getting started (125 clics)
- Télécharger check_ncpa (54 clics)
- Télécharger agent (46 clics)
- Aide sur NCPA (47 clics)
# Utilisation des Custom Object Variables recommandée
Posté par Cédric Temple (site web personnel, Mastodon) . Évalué à 6.
Merci, c'est super !
À noter, depuis la version 3 de Nagios, il est recommandé d'utiliser les Custom Object Variables plutôt que les $ARGn. C'est très triste que la documentation officielle de NCPA (et de Nagios) ne mette pas en avant cela mais les avantages sont importants :
Grâce aux Custom Object Variables, il est beaucoup plus simple de définir une stratégie de configuration efficace et surtout, maintenable dans le temps. Lorsqu'on a quelques dizaines de serveurs à superviser, on peut s'en passer (et encore), mais lorsqu'on dépasse la centaine, elles deviennent vite indispensables.
# Attention à la licence
Posté par DiscoM . Évalué à 7.
La licence de NCPA est très loin d’être une licence libre.
Extrait : «The Software may not be Forked. "Forking" and "to Fork" means to create or distribute a product or a derivative work of the object or source code of the Software under a new or different brand.»
Source : https://github.com/NagiosEnterprises/ncpa/blob/master/LICENSE.rst
Un changement de licence à été promis, mais jamais réalisé :
https://github.com/NagiosEnterprises/ncpa/issues/642
# Et la sécurité ?
Posté par Samuel (site web personnel) . Évalué à 3.
Merci pour cette présentation !
J'ai quelques questions qui me restent, notamment au regard des dégâts qu'ont pu avoir la faille solarwinds où un logiciel de supervision compromis permettait à l'intrus de prendre le contrôle de la totalité du parc :
[^] # Re: Et la sécurité ?
Posté par Startrek1701 . Évalué à 3.
Très bonne questions…
NCPA propose deux types de commandes
Il y a les commandes disponibles par défaut: CPU, mémoire, espace disques.
Et il y a les plugins qui sont sur la machine cliente et écris par un admin ou quelqu'un d'autres.
Donc, oui, si le plugin est détérioré ou compromis, oui, il y a un problème de sécurité.
Par défaut, sous Windows, c'est : "local system" et sous Linux: c'est nagios
Le community-string étant défini sur l'agent, on peut gérer autant de community-string que l'on veut. C'est dans la supersivion que l'on doit alors faire correspondre le community-string au bon serveur
La communication est cryptée avec comme version SSl par défaut: ssl_version = TLSv1_2
[^] # Re: Et la sécurité ?
Posté par Samuel (site web personnel) . Évalué à 1.
Du coup le serveur ne peut pas reconfigurer l'agent ou lui faire exécuter une commande arbitraire, exact ? (sauf plugin mal écrit…)
Merci de la précision ! Mais du coup, ça nécessite d'avoir une autorité de certification interne (ou d'en créer une pour cet usage), exact ?
[^] # Re: Et la sécurité ?
Posté par Startrek1701 . Évalué à 3.
Je ne sais pas comment est géré la couche SSL entre l'agent et le serveur Nagios, mais je suppose qu'il utilise un certificat self-signed. Concernant, le premier point, le serveur ne peut pas reconfigurer l'agent ou lui faire exécuter une commande arbitraire (sauf plugin mal écrit…).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.