opsi-nagios-connector

Transcription

1 opsi-nagios-connector Revision: OpenSides sprl Rue des Palais 44, bte Brussels Tel.: opsi@opensides.be

2 opsi-nagios-connector i Table des matières 1 Connecteur-opsi-Nagios Introduction Conditions préalables Conditions préalables au niveau du serveur et des clients OPSI Conditions préalables au niveau du serveur Nagios Concept extension opsi web service extension opsi-client-agent opsi-checks Quelques renseignements généraux sur l endroit où exécuter les contrôles opsi-check-plugin Contrôle: opsi web service Contrôle: opsi web service pnp4nagios template Contrôle: opsi-check-diskusage Contrôle: opsi-client-status Contrôle: opsi-check-productstatus Contrôle: opsi-check-depotsync Contrôle: contrôle nagios client plugin via opsiclientd configuration de la surveillance d opsi utilisateur de la surveillance d opsi Répertoire de configuration du connecteur opsi-nagios modèle Nagios: opsitemplates.cfg opsi hostgroup: opsihostgroups.cfg opsi server: <nom complet du serveur>.cfg opsi Clients: clients/<nom complet du client>.cfg configuration commande opsi: opsicommands.cfg Contacts: opsicontacts.cfg Services: opsiservices.cfg

3 opsi-nagios-connector 1 / 20 1 Connecteur-opsi-Nagios 1.1 Introduction Outre la gestion des clients, la surveillance est l une des fonctions centrales dans une gestion des services informatiques modernes. Avec OPSI vous avez un outil de gestion clients. Pour les tâches de surveillance il y a d autres bien connus solutions open source. Alors nous construisons pour les tâches de surveillance dans OPSI non pas un outil de surveillance propre mais une interface aux solutions existantes. Avec cette extension OPSI nous fournissons un connecteur à Nagios. Dans les chapitres suivants est expliquée la conception et la configuration du connecteur opsi Nagios. Le connecteur opsi Nagios n est pas strictement liée à Nagios. Il est développé pour l utilisation avec Nagios et Icinga. Il devrait également fonctionner avec des dérivés de Nagios mais cela n est pas testé ni pris en charge. La portée de ce manuel est la conception et la configuration du connecteur opsi-nagios. Il n est pas un manuel Nagios. Vous aurez besoin d une installation de Nagios et de savoir comment faire fonctionner Nagios. 1.2 Conditions préalables Conditions préalables au niveau du serveur et des clients OPSI Ce module est développé en tant que projet en co-financement. Cela signifie qu il n est disponibles que pour les clients qui paient une contribution aux coûts de développement ou à des fins d évaluation. Dès que le développement du projet sera refinancé, le composant fera partie de la distribution opsi et pourra être utilisé gratuitement. voir aussi Donc, comme condition sine qua non pour utiliser cette extension, vous avez besoin d abord d un fichier d activation. À des fins d évaluation vous obtiendrez un fichier d activation temporaire si vous le demandez dans un mail à opsi@opensides.be. Les conditions préalables techniques sont opsi avec le suivant paquets et versions de produits: Table 1: Versions des produits et des paquets nécessaires opsi package Version opsi-client-agent >= opsiconfd >= python-opsi >= Conditions préalables au niveau du serveur Nagios Comme condition préalable, vous avez besoin d une installation de Nagios dans la version 3.x ou d une installation Icinga dans la version 1.6 ou supérieur. Pour une sortie graphique de données sur le rendement, l installation de pnp4nagios est nécessaire. Vous trouverez de plus amples informations à:

4 opsi-nagios-connector 2 / Concept Le Connecteur opsi-nagios contient deux composantes fondamentales. Dans un premier temps nous allons discuter du coeur du système extension opsi web service Le coeur du connecteur opsi-nagios sont des fonctions étendues du service Web OPSI. Ces extension de service Web permettent d exécuter des vérifications via le web service sur le serveur opsi. Donc le serveur Nagios appelle des contrôles via le web service qui sont exécutés sur le serveur opsi et les résultats reviennent au serveur Nagios via le web service opsi. L avantage de cette solution c est qu il n y a presque rien à faire sur le serveur opsi surveillé. L objectif de l extension de service Web OPSI se trouve sur des contrôles OPSI spécifiques comme par exemple le suivi de déploiement. Pour la surveillance normal du serveur, vous devriez utiliser toujours des méthodes de contrôle standards extension opsi-client-agent Une autre partie du Connecteur opsi-nagios est l extension de opsi-client-agent. Dans un environnement OPSI sur chaque client géré s exécute opsi-client-agent. Avec cette extension, vous pouvez utiliser opsi-client-agent comme agent de Nagios ainsi. Mais en fait toutes les fonctions d un agent standard Nagios ne sont pas mis en œuvre dans opsi-client-agent comme NSClient++. Vous pouvez utiliser opsi-client-agent pour exécuter des programmes en ligne de commande et renvoyer la sortie. Si vous n utilisez pas toutes les fonctions comme NSCA mais plutôt certains contrôles standard par plugin sur le client ou un ensemble de plugins à vous sur les clients vous pouvez utiliser opsi-client-agent. Si vous avez besoin de plus de fonctionnalités pour le suivi des clients vous devriez déploiement, par l intermédiaire opsi, un agent standard comme NSClient++. L avantage d utiliser opsi-client-agent comme agent de Nagios est que vous n avez pas besoin d un agent supplémentaire sur le client et que vous n avez pas besoin de données d accès pour les clients au niveau du serveur de surveillance. Ces données ne sont pas nécessaires parce que tout vérification sont exécuté via le serveur OPSI. Cela rend la configuration beaucoup plus facile. 1.4 opsi-checks Le chapitre suivant explique les objectifs et les configurations des contrôles OPSI Quelques renseignements généraux sur l endroit où exécuter les contrôles Les administrateurs de surveillance connaissent la différence entre les contrôles actifs et passifs. Avec le Connecteur opsi-nagios on obtient une nouvelle différence: directe et indirecte. directe: Le contrôle qui recueille des informations sur un client s exécute sur ce client, il reçoit l information directement auprès du client et renvoie l information. indirecte: Le contrôle qui recueille des informations sur un client s exécute sur le serveur opsi et il reçoit l information à partir des données de configuration d opsi qui sont stockées dans le backend d opsi. Donc, cette information peut être différente de la situation réelle du client. Un bon exemple pour un contrôle indirect est le check-opsi-client-status. Cette vérification vous donne, pour un client donné, les informations sur les demandes d action en attente et les défaillances signalées du déploiement de logiciel d opsi. Donc, ce sont des informations sur le client à partir du point de vue du serveur opsi. Par conséquent, cette vérification s exécute sur le serveur OPSI et c est un contrôle indirecte. Une vérification qui s exécute sur le client est un contrôle direct.

5 opsi-nagios-connector 3 / 20 Pour une correcte distribution et configuration des contrôles vous devez analyser votre installation OPSI. En fonction de la flexibilité de OPSI de nombres configurations différentes d opsi sont possibles. Donc, ici nous ne pouvons qu expliquer certaines situations typiques. Bien sûr, nous allons vous aider pour des situations particulières avec notre support commercial. un seul serveur opsi: Une installation autonome d opsi est la situation que vous trouverez dans la plupart des environnements OPSI. Dans ce type d installation le serveur opsi ainsi que le serveur de depot opsi (un seul) sont sur la même machine. Cela signifie pour vous, que vous pouvez ignorer si un contrôle doit être exécuté sur le serveur de configuration ou le serveur de dépôt. Figure 1 Schéma d un serveur autonome OPSI OPSI avec serveurs de dépôts multiples: Si vous avez un gestion centralisée d un environnement OPSI de plusieurs emplacements (un serveur de config, plusieurs serveurs de dépôt) la situation est plus compliquée. Donc, vous devez comprendre la situation:

6 opsi-nagios-connector 4 / 20 Figure 2 Schéma d un environnement OPSI avec multiples dépôt Comme le souligne la figure il n existe qu un seul serveur qui contient les données de configuration - le backend. Il s agit du serveur de configuration opsi. Le serveur de dépôt OPSI, il ne dispose pas de son propre stockage de données, mais d une redirection vers le backend. Cela signifie que si vous demandez à un serveur de dépôt pour les données de configuration, cette question sera redirigé vers le serveur de configuration. Et cela conduit à la conséquence que chaque contrôle qui va à l encontre du backend sera au moins exécuter sur le serveur de configuration. Vous devez donc répondre à des contrôles qui s exécutent à l encontre du backend toujours sur le serveur de configuration. Même dans la situation de collecte d informations sur les clients qui sont affectés à un dépôt qui est différente du serveur de configuration et le contrôle est logiquement partie de la vérification de ce serveur de dépôt. Si vous exécutez les contrôles directs vous avez l habitude aussi d aborder la configuration du serveur opsi. Vous pouvez régler le serveur de dépôt si les clients ne peuvent pas être atteint par le serveur de configuration OPSI via le port Dans ce cas, c est une bonne idée de s adresser au serveur de dépôt.

7 opsi-nagios-connector 5 / 20 Figure 3 Contrôles distribués opsi-check-plugin Au niveau du serveur nagios il n existe qu un seul opsi-check-plugin qui fournit un large éventail de différents contrôles. En fonction du nombre de fonctionnalités il y a aussi un grand nombre d options de ligne de commande. Lister toutes ces options ne vous aidera pas trop. Au lieu de cela, l option sera expliqué dans le contexte de la documentation des possibles contrôles. Toutefois, pour obtenir une liste de toutes les options vous pouvez utiliser check_opsi avec les paramètres --help ou -h. Les options générales suivantes sont nécessaires pour chaque contrôle: Table 2: General Options Option Description Exemple -H,--host serveur opsi qui devrait exécuter le configserver.domain.local contrôle -P,--port opsi webservice port 4447 (Default) -u,--rname opsi monitoring r monitoring -p,--password opsi monitoring password monitoring123 -t,--task opsi check method (case sensitive) Le chapitre suivant décrit comment appeler opsi-check-plugin en ligne de commande. Comment vous devez configurer ces appels à votre serveur Nagios est décrit au chapitre configuration. Afin d installer opsi-check-plugin sur votre serveur Nagios vous devez ajouter le dépôt OPSI sur votre serveur et installer le paquet opsi-nagios-plugins. Par exemple, dans Debian ou Ubuntu avec les commandes suivantes:

8 opsi-nagios-connector 6 / 20 apt-get install opsi-nagios-plugins Sur RedHat/CentOS serveurs s il vous plaît utilisez la commande suivante: yum install opsi-nagios-plugins Et enfin pour des installations opensuse/sles: zypper install opsi-nagios-plugins Le plugin en lui-même est écrit en python et devrait fonctionner sur n importe quelle distribution. Le paquet se base sur les paquets nagios-plugins-basic et nagios-plugins et il installe le plugin dans /usr/lib/nagios/ plugins. Selon la flexibilité de check_plugin il n y a pas de configuration automatique. Contrôle: opsi web service Cette vérification surveille le processus opsi web service (opsiconfd). Cette vérification renvoie également les données de performance. Vous devez exécuter cette vérification sur chaque serveur OPSI parce que chaque serveur OPSI dispose d un processus opsiconfd. check_opsi.py -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsiwebservice Cette vérification renvoi normalement OK. Vous obtiendrez d autres valeurs de retour dans les situations suivantes: Critical: Si opsiconfd a des problèmes et ne peut pas répondre correctement. Si opsiconfd consomme plus de 80% de la cpu. Si vous avez un taux d erreurs RPC de plus de 20%. Warning: Si opsiconfd consomme plus de 60% (mais moins de 80%) de la cpu. Si vous avez un taux d erreurs RPC de plus de 10% mais moins de 20% Unknown: Le service web OPSI n a pas pu être atteint. NOTICE: La valeur en pourcentage de la consommation cpu appartient toujours à une cpu parce que opsiconfd peut seulement utiliser une cpu. (Cela pourrait changer avec l extension de multitraitement d opsi) Contrôle: opsi web service pnp4nagios template Pour l affichage des données de performance il y a un modèle pour pnp4nagios qui affiche les données d une manière combinée. Ici, n est pas décrit comment installer pnp4nagios. Nous supposons que pnp4nagios est installé et configuré correctement. La façon dont vous avez à utiliser pour configurer notre modèle peut différer de la façon ci-dessous décrite en fonction de votre installation pnp4nagios (qui peut utiliser un chemin différent). Les modèles standard affichent pour toutes les données de performance un diagramme propre. Pour créer un affichage combiné vous devez passer aux étapes suivantes: Étape 1: créez dans /etc/pnp4nagios/s un fichier nommé check_opsiwebservice.cfg et insérez le contenu suivant:

9 opsi-nagios-connector 7 / 20 CUSTOM_TEMPLATE = 0 DATATYPE = ABSOLUTE,ABSOLUTE,ABSOLUTE,ABSOLUTE,DERIVE,GAUGE,GAUGE,GAUGE Étape 2: accédez au répertoire /usr/share/pnp4nagios/html/templates et placez dedans le fichier check_opsiwebservice. php que vous pouvez consulter à partir de svn.opsi.org: cd /usr/share/pnp4nagios/html/templates svn co S il vous plaît vérifiez que votre fichier php est nommé exactement comme le command_name qui est défini dans / etc/nagios3/conf.d/opsi/opsicommands.cfg. Si les noms ne correspondent pas, un modèle standard sera utilisé à la place de notre modèle combiné. Après l installation de ce modèle vous devez supprimer la bases de données RRD qui appartiennent à ce contrôle (s il y a une existante). Vous trouverez ces bases de données dans /var/pnp4nagios/perfdata/<host>/ où vous devriez (seulement) supprimer les fichiers opsi-webservice.rrd et opsi-webservice.xml. Si vous avez tout configuré correctement vous devriez maintenant pouvoir voir les diagrammes comme dans la capture d écran ci-dessous.

10 opsi-nagios-connector 8 / 20 Contrôle: opsi-check-diskusage Ce contrôle surveille l utilisation des ressources (répertoires) qui sont utilisées par OPSI. Le tableau suivant montre les noms des ressources et les répertoires correspondants: Table 3: ressources opsi Resource name Path / /usr/share/opsiconfd/static configed /usr/lib/configed depot /opt/pcbin/install repository /var/lib/opsi/repository S il vous plaît notez que ce contrôle surveille uniquement les données pertinentes d opsi et remplace une vérification général de l usage du disque pour le serveur. La commande suivante extrait toutes les ressources en même temps: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidiskusage En plus de cette variante standard vous pouvez restreindre la vérification à la ressource depot: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidiskusage -r depot La valeur par défaut du résultat de cette vérification est OK et l espace libre des ressources. L espace libre est donnée en Gigabyte. Les valeurs par défaut pour les résultats de Warning et Critical sont: WARNING: Si au moins une ressource as 5GB ou moins d espace libre. CRITICAL: Si au moins une ressource as 1GB ou moins d espace libre. Ce sont les seuils par défaut. Elles peuvent changer en donnant d autres valeurs pour Warning avec les options -W ou --warning et pour Critical avec les options -C ou --critical. Avec ces options, vous pouvez indiquer les seuils en Gigabyte (G) et en pourcentage (%) ainsi. La sortie produite utilise la même unité qui est utilisé pour définir les seuils. Enfin un exemple: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidiskusage -r depot --warning\ 10% --critical 5% Contrôle: opsi-client-status L un des objectifs du connecteur OPSI Nagios est la surveillance du déploiement de logiciel par l écoute des clients individuels. C est l un des contrôles, qui est conçu pour cet emploi. Plus exactement: les situations déploiement du logiciel et vu la dernière fois d un certain client sont vérifiées. Le résultat des contrôles suivants est déterminée par deux états différents: L état de déploiement d un ou plusieurs logiciels: Le résultat de l état du déploiement de logiciels peut être: OK si le logiciel est installé dans le même produit et version du paquet qui est disponible au niveau du serveur et aucune demande d action est définie. Warning si le logiciel est installé dans une version qui est différente de la version serveurs ou si une demande d action est définie. Critical s il y a un échec rapporté par la dernière action. Le temps écoulé depuis vu la dernière fois: Le résultat du temps écoulé depuis vu la dernière fois peut être: OK si le client a été vu moins ou égale à 30 jours avant.

11 opsi-nagios-connector 9 / 20 Warning si le client a été vu plus de 30 jours avant. Ce contrôle peut être utilisé avec différentes variantes, ici la plus simple, qui comprend tous les logiciels: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkclientstatus -c opsiclient.\ domain.local Comme variante, il est possible d exclure des produits de la vérification. par exemple: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkclientstatus -c opsiclient.\ domain.local -x firefox Dans l exemple ci-dessus le produit firefox a été exclu de la vérification. Donc, cette vérification ne passera pas à critique parce que la dernière action sur firefox a signalé une défaillance. Contrôle: opsi-check-productstatus Un autre objectif du connecteur OPSI Nagios est la surveillance du déploiement de logiciel par l écoute de produit unique ou de groupe de produits. Le résultat de ces contrôles est déterminé par les états suivants: Le résultat de l état du déploiement de logiciels peut être: * OK si le logiciel est installé dans le même produit et version du paquet qui est disponible au niveau du serveur et aucune demande d action est définie. * Warning si le logiciel est installé dans une version qui est différente de la version serveurs ou si une demande d action est définie. * Critical s il y a un échec rapporté par la dernière action. Ces contrôles ont de nombres variantes et sont donc très souples. La meilleur façon d expliquer ces variantes c est avec des exemples. La variante simple verifie un produit sur tous les clients. Il faut specifier le produit par son opsi productid. check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkproductstatus -e firefox Dans un environnement avec un seul serveur opsi, ce contrôle est tout ce dont vous avez besoin pour verifier l état du produit firefox sur tous les clients. Vous sauriez combien de clients sont dans l état Warning et Critical. Pour savoir quel client a effectivement des problémes, vous devez l appeler en modalité verbe: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkproductstatus -e firefox -v Une autre variante vous permet d exclure un client de la verification. //// produkt muss angegebn werden?! //// check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkproductstatus -e firefox -x \ client.domain.local Dans un environnement opsi avec plusieurs serveurs de depot vous devez utiliser des options supplémentaires pour vérifier aussi les clients que ne sont pas assigné au depot du serveur de configuration. Si vous avez les dépôts multiple, vous pouvez passer le nom des dépôts comme parametres: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkproductstatus -e firefox -d \ depotserver.domain.local La raison est que la version du paquet peut être différente entre vos depots. Donc la version de chaque client devra être vérifié à partir du depot qui lui est assignè. Un avantage est qu il pourra placer l affichage des résultats sur le serveur de depot. Vous pouvez donner au lieu du nom du serveur de depot le mot clef all ce qui signifie tous les serveurs de depot connus. Mais cela normalement a seulement sens si vous avez un ou deux serveurs de depot. Vous pouvez aussi donner une liste de serveurs de depot sépare par une virgule. Une autre façon de definir le contrôle est de donner le nom d un ou plusieurs groups opsi. Ainsi vous pouvez verifier l état du déploiement de logiciels pour tous les produits dans un group de produits opsi donné. Si vous avez par exemple un group de produits accounting vous pouvez utiliser l appel suivant:

12 opsi-nagios-connector 10 / 20 check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkproductstatus -g accounting Maintenant vous pouvez vérifier tous les produits qui sont membre du group de produits opsi accounting avec ce simple contrôle. L important est de voir, que la résolution du groupe OPSI se fait au moment du contrôle au niveau du serveur OPSI. De cette façon vous pouvez changer le group opsi dans l interface web the gestion d opsi et changer le produits à tester sans apporter de modification sur le serveur Nagios. Note Sub groups (groups in groups) will not be resolved. De la même façon sera possible de définir les clients que vous voulez verifier en donnent le nom d un groupe de clients opsi. Un exemple pour un group de clients productiveclients: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkproductstatus -g accounting -G \ productiveclients Ceci vérifiera tous les produits du groupe de produits accounting sur tous les clients du groupe de clients productiveclients. Note Sub groups (groups in groups) will not be resolved. Note Vous pouvez aussi donner une liste de groupes opsi separè par virgule. Contrôle: opsi-check-depotsync Si vous utilisez des dépôts multiple est importante de surveiller aussi la synchronicité. Même si vos dépôts ne son pas, pour des bonnes raison, complètement synchronisé ils devraient, autant que possible, l être pour pallier au problèmes de déplacement d un client depuis un depot vers un autre. Ce contrôle surveille si vos depots sont synchronisé en fonction de l ids des produits, des versions du produits et des versions du paquet. Ce contrôle renvoi: OK Si tout est sincronisè. Warning S il y a des difference. Vous devez exécuter ce contrôle toujours sur un serveur de config parce que tous les données viennent du backend du serveur de config. Ici quelques exemples. La variante de base: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidepotsyncstatus Cette variante de base est équivalente à l appel suivant: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidepotsyncstatus -d all

13 opsi-nagios-connector 11 / 20 Donc si vous ne donnez pas le depot à verifier, tous les depots connus seront vérifiés. Si vous avez beaucoup de depots, l interprétation des résultats sera compliqué, donc ce sera une bonne idée de définir un ensemble de contrôles simples où les dépôts sont donnés comme liste séparé par virgule: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidepotsyncstatus -d \ configserver.domain.local,depotserver.domain.local Avec ce contrôle vous comparez tous les produits qui sont installés sur les deux depots. Tous les produits installès seulement dans un depot seront ignoré et n affectera pas le résultat. Si vous voulez inclure des produits which qui ne sont pas installés dans tous les depots vérifiés, vous devez utiliser le commutateur strictmode: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidepotsyncstatus -d \ configserver.domain.local,depotserver.domain.local --strictmode Maintenant aussi les différences sur les produits manquants seront affichèes. Si vous voulez exclure un produit de la verification (peut-être parce que ce produit doit être dans des versions différentes sur différents dépôts) vous devez utiliser l option -x. Vous pouvez aussi utiliser une liste separè par virgule: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidepotsyncstatus -d \ configserver.domain.local,depotserver.domain.local --strictmode -x firefox,thunderbird Ce contrôle ne vous averti pas si les produits firefox ou thunderbird ne sont pas synchronisé. Au lieu d exclure des produits vous pouvez donner une liste explicite de produits à vérifier: check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidepotsyncstatus -d \ configserver.domain.local,depotserver.domain.local --strictmode -e firefox,thunderbird Dans ce cas seulement firefox et thunderbird seront vérifié. Nous vous recommandons d utiliser cette variante stric tmode du contrôle pour voir si l un des produits est manquante../check_opsi.py -H configserver.domain.local -P u monitoring -p monitoring123 -t checkopsidepotsync Contrôle: contrôle nagios client plugin via opsiclientd Cette vérification vous donne un moyen facile pour intégrer les contrôles qui collectent les données directement sur le client avec un minimum de travail de configuration. Donc, ce contrôle demande à opsiclientd qui est en cours d exécution au niveau du client opsi d exécuter une commande, récupérer la sortie et de la renvoyer. Cette extension n est pas destiné à être un remplacement complet d un agent Windows Nagios avec toutes ces fonctionnalité. C est seulement une alternative légère. Les plugins que opsiclientd peut appeler doivent être compatibles avec la Nagios plug-in development guidelines. (More details at: ). Afin d exécuter un tel plugin sur le client, il doit être installé sur le client. La solution du problème est de le déployer comme un paquet opsi. Le chemin dans lequel le plugin est installé chez le client n a pas d importance parce que vous devez donner le chemin complet à la définition du contrôle. Nous recommandons d installer tous les plugins dans un répertoire pour faciliter l entretien des plugins sur le client. Pour des raisons de sécurité, vous devriez faire en sorte que les utilisateurs non privilégiés n ont pas accès en écriture à des plugins, parce qu ils seront exécutés à partir de opsiclientd avec des privilèges système. Il ya beaucoup de plugins prêts à l emploi sur Internet. Une adresse à regarder est: Dans ce qui suit, nous supposons que vos plugins sont installés dans C:\opsi.org\nagiosplugins\ et nous y trouverons le plugin check_win_disk.exe sorti de son paquet nagioscol depuis

14 opsi-nagios-connector 12 / 20 check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkpluginonclient --plugin "C:\\\ opsi.org\\nagiosplugincol\\check_win_disk.exe C:" -c client.domain.local Cet appel contrôle le client client.domain.local. Au niveau du client le plugin check_win_disk.exe est appelé avec le paramètre C:. Cela signifie que le disque dur avec la lettre C doit être vérifiée. La sortie et la valeur du résultat du plugin seront récupérées par opsiclientd et seront donnée au serveur Nagios (via le serveur OPSI) dans un format correct pour Nagios. Une autre caractéristique spéciale est de garder les résultats de la dernière vérification, même si le client n est pas joignable. Cette fonctionnalité a été mis en œuvre selon le fait que les clients ne sont pas toujours en cours d exécution comme les serveurs, mais le plus de temps dans leur vie sont généralement éteint. Normalement Nagios montrera pour les clients éteints le résultat Inconnu. En fait le plus de problèmes sur les clients surveillés ne vont pas disparaître simplement en les éteignant et en les allumant à nouveau. Ainsi, les informations que le client avait un problème avant qu il ne soit éteints peuvent être des informations essentielles pour l administrateur système. (Vous pouvez essayer de résoudre ce problème en utilisant Timeperiods à la configuration de Nagios, mais nous pensons que ce n est pas assez souple et conduit à un travail de configuration permanente). Donc, cette extension OPSI vous donne la possibilité de renvoier les derniers résultats de contrôle réels, si le client n est pas joignable en ce moment. Pour utiliser cette fonctionnalité, vous devez utiliser les macros Nagios $SERVICESTATEID$ et $SERVICEOUTPUT$. $SERVICESTATEID$ donne le dernier résultat et devrait être passé à l option -s. $SERVICEOUTPUT$ donne la dernière ligne de sortie et devrait être passé à l option -o. Ainsi le contrôle peut donner ces dernières valeurs au lieu de Inconnu si le client n est pas joignable. check_opsi -H configserver.domain.local -P u monitoring -p monitoring123 -t checkpluginonclient --plugin "C:\\\ opsi.org\\nagiosplugincol\\check_win_disk.exe C:" -c client.domain.local -s $SERVICESTATEID$ -o $SERVICEOUTPUT$ 1.5 configuration de la surveillance d opsi Ce chapitre se concentre sur la configuration qui a été réalisés pour une interface operationnel entre les serveur opsi et Nagios. Il suffit de voir cela comme une recommandation, il y aura beaucoup d autres façons de faire le travail. Cette description utilise un serveur Nagios en tant que serveur de surveillance. Sur un serveur Icinga il devrait fonctionner similairement mais vous devez changer certaines entrées de chemin. Il devrait également fonctionner sur les produits dérivés de Nagios, mais ce n est pas testé. ASTUCE Les fichiers de configuration de ce chapitre sont dans opsi-nagios-connector-utils svn-repository. Pour obtenir ces fichiers de configuration vous pouvez vous connecter avec un navigateur web à l url: ou vous pouvez faire une extraction directe à partir du dépôt svn avec la commande suivante: svn co utilisateur de la surveillance d opsi Dans les environnements de surveillance vous trouverez souvent que l accès est seulement limité par l adresse IP. En raison de l absence de sécurité de cette solution nous avons décidé de travailler avec un véritable utilisateur / mot de passe de sécurité dans cette extension opsi. En utilisant le groupe standard OPSI opsiadmin on donnerait à Nagios plus de droits que nécessaire. Donc, vous devez créer un utilisateur OPSI propre pour le Connecteur opsi-nagios. Dans l exemple suivant, un utilisateur nommé monitoring avec le mot de passe monitoring123 est créé pour opsi:

15 opsi-nagios-connector 13 / 20 opsi-admin -d method r_setcredentials monitoring monitoring123 L utilisateur créé monitoring sera stockée avec le mot de passe crypté dans /etc/opsi/passwd et n est pas un utilisateur qui peut être utilisé pour connecter au shell. En fait, il n est pas un utilisateur réel Unix. Vous devez créer cet utilisateur uniquement sur votre serveur de configuration, même si vous avez des dépôts multiples. Sur votre serveur Nagios vous devriez masquer l utilisateur et le mot de passe en faisant une entrée dans /etc/ nagios3/resource.cfg. Cela devrait être par exemple comme ceci: $USER2$=monitoring $USER3$=monitoring123 Le nombre derrière $USER peut varier. Si cette configuration n a pas été utilisé avant, il devrait y avoir seulement $ USER1 $ utilisable. Selon ce que vous utilisez ici, vous pourriez avoir à modifier les autres exemples dans ce manuel Répertoire de configuration du connecteur opsi-nagios Pour rendre la maintenance de la configuration de Nagios plus facile, nous vous recommandons de mettre tous les fichiers de configuration associés au connecteur opsi nagios dans un endroit séparé. Il suffit donc de créer dans /etc/nagios3/conf.d un nouveau répertoire nommé opsi pour ces configurations. Les fichiers de configuration que nous allons placer dans ce répertoire sont: Nagios Template: opsitemplates.cfg Hostgroups: opsihostgroups.cfg Server Hosts: <full name of the server>.cfg Commands: opsicommands.cfg Contacts: opsicontacts.cfg Services: opsiservices.cfg Nous vous recommandons de mettre tous les fichiers de configuration du client dans des sous-répertoires. Par conséquent, vous créez dans /etc/nagios3/conf.d/opsi un autre répertoire nommé clients modèle Nagios: opsitemplates.cfg L tilisation des modèles est une fonctionnalité standard de Nagios qui ne sera pas expliqué ici. Le principal avantage est que cela rend les fichiers de configuration petitset plus faciles à lire (et écrire). A l intérieur des modèles nous utilisons certaines variables personnalisées Nagios pour les valeurs souvent utilisés. Selon le fait que le plus grand nombre de contrôle doivent s exécuter sur le serveur de configuration opsi, nous allons définir le nom et le port du serveur de configuration en tant que variable personnalisée: _configserver configserver.domain.local _configserverurl 4447 Vous trouverez ce ci-dessous dans les définitions de modèles. Ces variables personnalisées peuvent plus tard être référencé par les macros Nagios: $_HOSTCONFIGSERVER$ et $_HO STCONFIGSERVERPORT$. (Ces macros ont HOST dans leur nom, parce qu ils sont définis à l intérieur d une définition d hôte). Pour plus de détails sur les variables et les macros regardez à la documentation de Nagios. Maintenant, le premier fichier que nous créons dans /etc/nagios3/conf.d/opsi est le fichier de définition de modèle opsitemplates.cfg. Ce fichier peut contenir différents modèles. Chaque modèle est créé selon la base suivante (qui contient des commentaires pour mieux comprendre):

16 opsi-nagios-connector 14 / 20 define host{ name opsihost-tmp ; The name of this host template notifications_enabled 1 ; Host notifications are enabled event_handler_enabled 1 ; Host event handler is enabled flap_detection_enabled 1 ; Flap detection is enabled failure_prediction_enabled 1 ; Failure prediction is enabled process_perf_data 0 ; Process performance data retain_status_information 1 ; Retain status information across program restarts retain_nonstatus_information 1 ; Retain non-status information across program restarts max_check_attempts 10 notification_interval 0 notification_period 24x7 notification_options d,u,r contact_groups admins register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE! icon_image opsi/opsi-client.png NOTE: * L option facultative icon_image peut être mise dans une image avec un chemin relatif dans: /usr/share/ nagios3/htdocs/images/logos/. * En option vous pouvez donner un propre contact_group, qui doivent être définis en tant qu objet de contact, par exemple dans le fichier opsicontacts.cfg. Maintenant, nous recommandons de créer des modèles pour les objets suivants opsi server opsi client opsi service et 2 modèles pour pnp4nagios (host-pnp / srv-pnp) Commençons par l exemple du modèle du serveur opsi (opsi server): define host{ name opsi-server-tmpl notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 failure_prediction_enabled 1 process_perf_data 1 retain_status_information 1 retain_nonstatus_information 1 check-host-alive max_check_attempts 10 notification_interval 0 notification_period 24x7 notification_options d,u,r contact_groups admins,opsiadmins _configserver configserver.domain.local _configserverport 4447 register 0 icon_image opsi/opsi-client.png Vous avez juste à changer configserver.domain.local avec le nom de votre serveur de configuration. Aussi, vous pouvez changer le contact_groups selon vos besoins. La prochaine partie du fichier opsitemplates.cfg est le modèle pour les clients: define host{ name opsi-client-tmpl notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 failure_prediction_enabled 1 process_perf_data 1 retain_status_information 1 retain_nonstatus_information 1

17 opsi-nagios-connector 15 / 20 max_check_attempts 10 notification_interval 0 notification_period 24x7 notification_options d,u,r contact_groups admins,opsiadmins _configserver configserver.domain.local _configserverport 4447 register 0 icon_image opsi/opsi-client.png L option "check command check-host-alive" ne devrait être pas définie ici parce que les clients ne sont pas toujours en cours d exécution. En effet les clients seront affichées comme pending au lieu de offline. Vous avez juste à changer configserver.domain.local avec le nom de votre serveur de configuration. Aussi, vous pouvez changer le contact_groups selon vos besoins. La prochaine partie du fichier opsitemplates.cfg est le modèle pour les opsi-services: name opsi-service-tmpl active_checks_enabled 1 passive_checks_enabled 1 parallelize_check 1 obsess_over_service 1 check_freshness 0 notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 failure_prediction_enabled 1 process_perf_data 1 retain_status_information 1 retain_nonstatus_information 1 notification_interval 0 is_volatile 0 check_period 24x7 normal_check_interval 5 retry_check_interval 1 max_check_attempts 4 notification_period 24x7 notification_options w,u,c,r contact_groups admins,opsiadmins register 0 Si vous utilisez pnp4nagios pour la représentation graphique des données de performance vous aurez besoin de deux autres modèles dans le fichier opsitemplates.cfg: define host { name host-pnp action_url /pnp4nagios/index.php/graph?host=$hostname$&srv=_host_ register 0 define service { name srv-pnp action_url /pnp4nagios/index.php/graph?host=$hostname$&srv=$servicedesc$ register opsi hostgroup: opsihostgroups.cfg La prochaine étape consiste à définir les hostgroups. Cela contribue à structurer l affichage des résultats ainsi que les définitions de services. Créez donc un fichier nommé opsihostgroups.cfg avec le contenu suivant:

18 opsi-nagios-connector 16 / 20 define hostgroup { hostgroup_name alias define hostgroup { hostgroup_name alias members opsi-clients OPSI-Clients opsi-server OPSI-Server configserver.domain.local, depotserver.domain.local Ne pas oublier de modifier la ligne member opsi server: <nom complet du serveur>.cfg L étape suivante consiste à créer pour chaque serveur opsi en cours d exécution un fichier de configuration propre. Ce fichier doit être nommé sur la base du modèle <nom complet du serveur>.cfg. Par exemple configserver.domain. local.cfg. (Vous pouvez également créer un fichier (ex. opsihost.cfg avec toutes les définitions de serveur). Le contenu devrait ressembler à ceci: define host{ host_name hostgroups alias address define host{ host_name hostgroups alias address opsi-server-tmpl configserver.domain.local opsi-server opsi Configserver configserver.domain.local opsi-server-tmpl depotserver.domain.local opsi-server opsi Depotserver depotserver.domain.local Explication des entrées: * références au modèle utilisée. * hostgroups nous dit quel hostgroup appartient à ce serveur opsi Clients: clients/<nom complet du client>.cfg Les configurations des clients OPSI doivent être placés dans un répertoire propre. Elles doivent être définies comme ceci: define host{ host_name hostgroups alias address _depotid opsi-client-tmpl client.domain.local opsi-clients opsi client client.domain.local depotserver.domain.local Cette configuration du client utilise à nouveau une variable personnalisée: _depotid. Cette variable personnalisée peut être référencée par la macro $_HOSTDEPOTID$. L utilisation est facultative. Si un client n est pas connecté directement au serveur de configuration opsi, vous devez écrir ici à partir de quel serveur de dépôt le client peut être contacté. Pour faciliter la création des fichiers de configuration pour votre nombreux clients OPSI, vous pouvez exécuter le script suivant sur votre serveur de configuration OPSI:

19 opsi-nagios-connector 17 / 20 #!/usr/bin/env python from OPSI.Backend.BackendManager import * template = define host { host_name hostgroups alias address opsi-client-tmpl %hostid% opsi-clients %hostid% %hostid% backend = BackendManager( dispatchconfigfile = u /etc/opsi/backendmanager/dispatch.conf, backendconfigdir = u /etc/opsi/backends, extensionconfigdir = u /etc/opsi/backendmanager/extend.d, ) hosts = backend.host_getobjects(type="opsiclient") for host in hosts: filename = "%s.cfg" % host.id entry = template.replace("%hostid%",host.id) f = open(filename, w ) f.write(entry) f.close() configuration commande opsi: opsicommands.cfg Maintenant, nous devons définir quels sont les commandes de contrôle, qui sont décrites avant, que nous voulons utiliser. Vous devez le faire dans un fichier nommé opsicommands.cfg. Ceci est juste un exemple que vous pouvez modifier à vos besoins: D abord nous expliquons la structure des entrées: define command{ command_name check_opsi_clientstatus command_line $USER1$/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$ -p \ $USER3$ -t checkclientstatus -c $HOSTADDRESS$ command_name sera utilisé par d autres fichiers de configuration. L option command_line définit la commande et tous les arguments utilisés. Basé sur ce modèle, nous créons maintenant le fichier opsicommands.cfg: command_name check_opsiwebservice command_line /usr/lib/nagios/plugins/check_opsi -H $HOSTADDRESS$ -P u $USER2$ -p $USER3$ -t \ checkopsiwebservice command_name check_opsidiskusage command_line /usr/lib/nagios/plugins/check_opsi -H $HOSTADDRESS$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$ -p \ $USER3$ -t checkopsidiskusage command_name check_opsiclientstatus command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkclientstatus -c $HOSTADDRESS$

20 opsi-nagios-connector 18 / 20 command_name check_opsiproductstatus command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkproductstatus -e $ARG1$ -d $HOSTADDRESS$ -v command_name check_opsiproductstatus_withgroups command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkproductstatus -g $ARG1$ -G $ARG2$ -d "all" command_name check_opsiproductstatus_withgroups_long command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkproductstatus -g $ARG1$ -G $ARG2$ -v -d "all" command_name check_opsidepotsync command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkdepotsyncstatus -d $ARG1$ command_name check_opsidepotsync_long command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkdepotsyncstatus -d $ARG1$ -v command_name check_opsidepotsync_strict command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkdepotsyncstatus -d $ARG1$ --strict command_name check_opsidepotsync_strict_long command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkdepotsyncstatus -d $ARG1$ --strict -v command_name check_opsipluginon_client command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkpluginonclient -c $HOSTADDRESS$ --plugin $ARG1$ command_name check_opsipluginon_client_with_states command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\ -p $USER3$ -t checkpluginonclient -c $HOSTADDRESS$ --plugin $ARG1$ -s $SERVICESTATEID$ -o "$SERVICEOUTPUT$" command_name check_opsipluginon_client_from_depot command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTDEPOTID$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$ -p \ $USER3$ -t checkpluginonclient -c $HOSTADDRESS$ --plugin $ARG1$ Contacts: opsicontacts.cfg Ceci définit les contacts qui obtiendront les notifications. define contact{ contact_name alias service_notification_period host_notification_period service_notification_options host_notification_options service_notification_commands host_notification_commands define contactgroup{ adminr Opsi 24x7 24x7 w,u,c,r d,r notify-service-by- notify-host-by- root@localhost