opsi-nagios-connector

(1)

Revision: 30.05.2012

OpenSides sprl

Rue des Palais 44, bte 33 1030 Brussels

Tel.:+32 2 880 97 40 www.opensides.be opsi@opensides.be

(2)

Table des matières

1 Connecteur-opsi-Nagios 1

1.1 Introduction. . . 1

1.2 Conditions préalables. . . 1

1.2.1 Conditions préalables au niveau du serveur et des clients OPSI . . . 1

1.2.2 Conditions préalables au niveau du serveur Nagios . . . 1

1.3 Concept . . . 2

1.3.1 extension opsi web service . . . 2

1.3.2 extension opsi-client-agent . . . 2

1.4 opsi-checks . . . 2

1.4.1 Quelques renseignements généraux sur l’endroit où exécuter les contrôles. . . 2

1.4.2 opsi-check-plugin . . . 5

Contrôle: opsi web service . . . 6

Contrôle: opsi web service pnp4nagios template . . . 6

Contrôle: opsi-check-diskusage . . . 8

Contrôle: opsi-client-status . . . 8

Contrôle: opsi-check-ProductStatus. . . 9

Contrôle: opsi-check-depotsync . . . 10

Contrôle: contrôle nagios client plugin via opsiclientd. . . 11

1.5 configuration de la surveillance d’opsi . . . 12

1.5.1 utilisateur de la surveillance d’opsi . . . 12

1.5.2 Répertoire de configuration du connecteur opsi-Nagios . . . 13

1.5.3 modèle Nagios:opsitemplates.cfg . . . 13

1.5.4 opsi hostgroup:opsihostgroups.cfg . . . 15

1.5.5 opsi server:<nom complet du serveur>.cfg . . . 16

1.5.6 opsi Clients:clients/<nom complet du client>.cfg. . . 16

1.5.7 configuration commande opsi:opsicommands.cfg . . . 17

1.5.8 Contacts:opsicontacts.cfg . . . 18

1.5.9 Services:opsiservices.cfg . . . 19

(3)

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

1.2.1 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

http://www.opsi.org/fr/projets-de-co-financement http://www.opsi.org/fr/statistics

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 4.0.2 avec le suivant paquets et versions de produits:

Table 1: Versions des produits et des paquets nécessaires

opsi package Version

opsi-client-agent >=4.0.2-1

opsiconfd >=4.0.2.1-1

python-opsi >=4.0.2.1-1

1.2.2 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 à:

www.nagios.org www.icinga.org www.pnp4nagios.org

(4)

1.3 Concept

Le Connecteur opsi-Nagios contient deux composantes fondamentales. Dans un premier temps nous allons discuter du coeur du système.

1.3.1 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 surveillancenormal du serveur, vous devriez utiliser toujours des méthodes de contrôle standards.

1.3.2 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 commeNSClient++. 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 commeNSClient++.

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.

1.4.1 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)

Pour une correcte distribution et configuration des contrôles vous devez analyser votre installation OPSI.

En fonction de la flexibilité de OPSI de nombreuses 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.

Figure1 – 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)

Figure2 – 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 4441. Dans ce cas, c’est une bonne idée de s’adresser au serveur de dépôt.

(7)

Figure3 – Contrôles distribués

1.4.2 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 utilisercheck_opsiavec les paramètres--helpou -h.

Les options générales suivantes sont nécessaires pour chaque contrôle:

Table2: General Options

Option Description Exemple

-H,--host serveur opsi qui devrait exécuter le

contrôle

configserver.domain.local

-P,--port opsi webservice port 4447 (Default)

-u,--username opsi monitoring user 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 chapitreconfiguration.

Afin d’installer opsi-check-plugin sur votre serveur Nagios vous devez ajouter le dépôt OPSI sur votre serveur et installer le paquetopsi-nagios-plugins.

Par exemple, dans Debian ou Ubuntu avec les commandes suivantes:

(8)

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 paquetsnagios-plugins-basicetnagios-pluginset 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 4447 -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/check_commands un fichier nommé check_opsiwebservice.cfg et insérez le contenu suivant:

(9)

CUSTOM_TEMPLATE = 0

DATATYPE = ABSOLUTE,ABSOLUTE,ABSOLUTE,ABSOLUTE,DERIVE,GAUGE,GAUGE,GAUGE

Étape 2:

accédez au répertoire/usr/share/pnp4nagios/html/templateset placez dedans le fichiercheck_opsiwebservice.

phpque vous pouvez consulter à partir de svn.opsi.org:

cd /usr/share/pnp4nagios/html/templates

svn co https://svn.opsi.org/opsi-pnp4nagios-template/trunk/check_opsiwebservice.php

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 fichiersopsi-webservice.rrdetopsi-webservice.xml.

Si vous avez tout configuré correctement vous devriez maintenant pouvoir voir les diagrammes comme dans la capture d’écran ci-dessous.

(10)

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:

Table3: 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 4447 -u monitoring -p monitoring123 -t checkOpsiDiskUsage

En plus de cette variante standard vous pouvez restreindre la vérification à la ressourcedepot:

check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDiskUsage -r depot

La valeur par défaut du résultat de cette vérification estOK et l’espace libre des ressources. L’espace libre est donnée en Gigabyte. Les valeurs par défaut pour les résultats deWarning etCritical 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 4447 -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 etvu 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échecrapporté par la dernière action.

– Le temps écoulé depuisvu la dernière fois:

Le résultat du temps écoulé depuisvu la dernière fois peut être:

– OK si le client a été vu moins ou égale à 30 jours avant.

(11)

– 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 4447 -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 4447 -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 surfirefox 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échecrapporté par la dernière action.

Ces contrôles ont de nombreuses 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 opsiproductId.

check_opsi -H configserver.domain.local -P 4447 -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 produitfirefox sur tous les clients.

Vous sauriez combien de clients sont dans l’étatWarning etCritical.

Pour savoir quel client a effectivement des problémes, vous devez l’appeler en modalitéverbeuse:

check_opsi -H configserver.domain.local -P 4447 -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 4447 -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 4447 -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 clefallce 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 produitsaccounting vous pouvez utiliser l’appel suivant:

(12)

check_opsi -H configserver.domain.local -P 4447 -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 clientsproductiveclients:

check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -g accounting -G \ productiveclients

Ceci vérifiera tous les produits du groupe de produitsaccounting sur tous les clients du groupe de clientsproductive- clients.

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 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus

Cette variante de base est équivalente à l’appel suivant:

check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d all

(13)

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 4447 -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 commutateurstrictmode:

check_opsi -H configserver.domain.local -P 4447 -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 4447 -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 produitsfirefox outhunderbird 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 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \ configserver.domain.local,depotserver.domain.local --strictmode -e firefox,thunderbird

Dans ce casseulementfirefox etthunderbird seront vérifié. Nous vous recommandons d’utiliser cette variantestric tmodedu contrôle pour voir si l’un des produits est manquante.

./check_opsi.py -H configserver.domain.local -P 4447 -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 fonc- tionnalité . C’est seulement une alternative légère.

Les plugins que opsiclientd peut appeler doivent être compatibles avec laNagios plug-in development guidelines.

(More details at:http://nagiosplug.sourceforge.net/developer-guidelines.html).

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ègessystème.

Il ya beaucoup de plugins prêts à l’emploi sur Internet. Une adresse à regarder est:

http://exchange.nagios.org/

Dans ce qui suit, nous supposons que vos plugins sont installés dans C:\opsi.org\nagiosplugins\et nous y trou- verons le plugincheck_win_disk.exesorti de son paquet nagioscol depuis

http://sourceforge.net/projects/nagiosplugincol/

(14)

check_opsi -H configserver.domain.local -P 4447 -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 clientclient.domain.local. Au niveau du client le plugincheck_win_disk.exeest appelé avec le paramètre C:. Cela signifie que le disque dur avec la lettreC 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ésultatInconnu. 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 deInconnu si le client n’est pas joignable.

check_opsi -H configserver.domain.local -P 4447 -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:

https://svn.opsi.org/listing.php?repname=opsi-nagios-connector-utils

ou vous pouvez faire une extraction directe à partir du dépôt svn avec la commande suivante:

svn co https://svn.opsi.org/opsi-nagios-connector-utils

1.5.1 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 passemonitoring123 est créé pour opsi:

(15)

opsi-admin -d method user_setCredentials monitoring monitoring123

L’utilisateur créémonitoringsera stockée avec le mot de passe crypté dans/etc/opsi/passwdet 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$USERpeut 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.

1.5.2 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 auconnecteur opsi nagiosdans un endroit séparé.

Il suffit donc de créer dans/etc/nagios3/conf.dun nouveau répertoire nommé opsipour 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 con- séquent, vous créez dans/etc/nagios3/conf.d/opsiun autre répertoire nomméclients.

1.5.3 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 quevariable 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 ontHOST 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/opsiest 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 commen- taires pour mieux comprendre):

(16)

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 proprecontact_group, qui doivent être définis en tant qu’objet de contact, par exemple dans le fichieropsicontacts.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_command check-host-alive

notification_interval 0 notification_period 24x7 notification_options d,u,r

contact_groups admins,opsiadmins _configserver configserver.domain.local

_configserverport 4447

register 0

}

Vous avez juste à changerconfigserver.domain.local avec le nom de votre serveur de configuration. Aussi, vous pouvez changer lecontact_groupsselon vos besoins.

La prochaine partie du fichieropsitemplates.cfg est le modèle pour les clients:

define host{

name opsi-client-tmpl

process_perf_data 1

(17)

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

}

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 commepending au lieu deoffline.

Vous avez juste à changerconfigserver.domain.local avec le nom de votre serveur de configuration. Aussi, vous pouvez changer lecontact_groupsselon vos besoins.

La prochaine partie du fichieropsitemplates.cfg est le modèle pour les opsi-services:

define service{

name opsi-service-tmpl

active_checks_enabled 1 passive_checks_enabled 1

parallelize_check 1

obsess_over_service 1

check_freshness 0

process_perf_data 1

notification_interval 0

is_volatile 0

check_period 24x7

normal_check_interval 5 retry_check_interval 1

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 fichieropsitemplates.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 0 }

1.5.4 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.cfgavec le contenu suivant:

(18)

define hostgroup {

hostgroup_name opsi-clients

alias OPSI-Clients

}

define hostgroup {

hostgroup_name opsi-server

alias OPSI-Server

members configserver.domain.local, depotserver.domain.local }

Ne pas oublier de modifier la lignemember.

1.5.5 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 exempleconfigserver.domain.

local.cfg.

(Vous pouvez également créer un fichier (ex.opsihost.cfgavec toutes les définitions de serveur).

Le contenu devrait ressembler à ceci:

define host{

use opsi-server-tmpl

host_name configserver.domain.local

hostgroups opsi-server

alias opsi Configserver

address configserver.domain.local }

define host{

use opsi-server-tmpl

host_name depotserver.domain.local

hostgroups opsi-server

alias opsi Depotserver

address depotserver.domain.local }

Explication des entrées: * use références au modèle utilisée. * hostgroups nous dit quel hostgroup appartient à ce serveur.

1.5.6 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{

use opsi-client-tmpl

host_name client.domain.local

hostgroups opsi-clients

alias opsi client

address client.domain.local

_depotid depotserver.domain.local

}

Cette configuration du client utilise à nouveau unevariable personnalisée:_depotid. Cettevariable personnaliséepeut ê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)

#!/usr/bin/env python

from OPSI.Backend.BackendManager import * template = ’’’

define host {

use opsi-client-tmpl

host_name %hostId%

hostgroups opsi-clients

alias %hostId%

address %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()

1.5.7 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_namesera utilisé par d’autres fichiers de configuration. L’optioncommand_line définit la commande et tous les arguments utilisés.

Basé sur ce modèle, nous créons maintenant le fichieropsicommands.cfg:

define command {

command_name check_opsiwebservice

command_line /usr/lib/nagios/plugins/check_opsi -H $HOSTADDRESS$ -P 4447 -u $USER2$ -p $USER3$ -t \ checkOpsiWebservice

}

define command {

command_name check_opsidiskusage

command_line /usr/lib/nagios/plugins/check_opsi -H $HOSTADDRESS$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$ -p \

$USER3$ -t checkOpsiDiskUsage }

define command {

command_name check_opsiclientstatus

command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\

-p $USER3$ -t checkClientStatus -c $HOSTADDRESS$

}

define command {

(20)

command_name check_opsiproductstatus

-p $USER3$ -t checkProductStatus -e $ARG1$ -d $HOSTADDRESS$ -v }

define command {

command_name check_opsiproductStatus_withGroups

-p $USER3$ -t checkProductStatus -g $ARG1$ -G $ARG2$ -d "all"

}

define command {

command_name check_opsiproductStatus_withGroups_long

-p $USER3$ -t checkProductStatus -g $ARG1$ -G $ARG2$ -v -d "all"

}

define command {

command_name check_opsidepotsync

-p $USER3$ -t checkDepotSyncStatus -d $ARG1$

}

define command {

command_name check_opsidepotsync_long

-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ -v }

define command {

command_name check_opsidepotsync_strict

-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ --strict }

define command {

command_name check_opsidepotsync_strict_long

-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ --strict -v }

define command {

command_name check_opsipluginon_client

-p $USER3$ -t checkPluginOnClient -c $HOSTADDRESS$ --plugin $ARG1$

}

define command {

command_name check_opsipluginon_client_with_states

-p $USER3$ -t checkPluginOnClient -c $HOSTADDRESS$ --plugin $ARG1$ -s $SERVICESTATEID$ -o "$SERVICEOUTPUT$"

}

define command {

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$

}

1.5.8 Contacts: opsicontacts.cfg

Ceci définit les contacts qui obtiendront les notifications.

define contact{

contact_name adminuser

alias Opsi

service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,r

service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email

email root@localhost

}

define contactgroup{

(21)

contactgroup_name opsiadmins

alias Opsi Administrators

members adminuser

}

Vous devez remplaceradminuser par un ou plusieurs utilisateurs réels.

1.5.9 Services: opsiservices.cfg

Enfin, nous définissons avec services ce que les serveur Nagios doivent surveiller et afficher. Cette définition utilise comme modèles, commandes et hostgroups ou hosts la définition de l’autre fichier de configuration susmentionné.

Comme première partie nous définissons les services qui nous donnent des informations sur les serveurs. L’un d’eux est le contrôle de la synchronisation des dépôts, qui est ici-bas en opposition avectousles dépôts connus.

#OPSI-Services define service{

use opsi-service-tmpl,srv-pnp

service_description opsi-webservice check_command check_opsiwebservice

check_interval 1

} define service{

use opsi-service-tmpl

service_description opsi-diskusage

check_command check_opsidiskusage

check_interval 1

} define service{

service_description opsi-depotsyncstatus-longoutput check_command check_opsidepotsync_long!all

check_interval 10

} define service{

service_description opsi-depotsyncstatus-strict-longoutput check_command check_opsidepotsync_strict_long!all

check_interval 10

}

La prochaine partie est le suivi du déploiement de logiciels. Dans un contrôle un produit concret opsiopsi-client-agent est mentionné. Dans deux autres contrôles sont référencés un groupe de produits opsiopsiessentials et un groupe de client opsiproductiveclients.

define service{

hostgroup_name opsi-clients

service_description opsi-clientstatus check_command check_opsiclientstatus

check_interval 10

} define service{

service_description opsi-productstatus-opsiclientagent check_command check_opsiproductstatus!opsi-client-agent

check_interval 10

} define service{

(22)

service_description opsi-productstatus-opsiessentials-group

check_command check_opsiproductStatus_withGroups!opsiessentials!productiveclients

check_interval 10

} define service{

service_description opsi-productstatus-opsiessentials-group-longoutput

check_command check_opsiproductStatus_withGroups_long!opsiessentials!productiveclients

check_interval 10

}

Dans la troisième et dernière partie du fichier sont définis les contrôles qui doivent s’exécuter directement sur les clients (direct checks).

Ces contrôles ne sont pas (par exemple) affecté à des hostgroups mais à un seul host ou à des listes d’hosts (client.domain.local,depotclient.domain.local).

Certains descriptif:

– opsi-direct-checkpluginonclient

exécute des contrôlesdirect sur le client et renvoieunknown si le client est déconnecté.

Lors de cette vérification le serveur de configuration essaie d’atteindre le client directement.

– opsi-direct-checkpluginonclient-with-servicestate

est égal àopsi-direct-checkpluginonclient, mais il renvoie le dernier résultat valide si le client est déconnecté (au lieu deunknown)

– opsi-direct-checkpluginonclient-from-depot

est égal àopsi-direct-checkpluginonclient, mais le client sera contacté par le serveur qui est donnée dans la configu- ration de l’hôte comme_depotid.

define service{

host_name client.domain.local,depotclient.domain.local service_description opsi-direct-checkpluginonclient

check_command check_opsipluginon_client!"C:\\opsi.org\\nagiosplugins\\check_memory.exe"

check_interval 10

} define service{

host_name client.domain.local

service_description opsi-direct-checkpluginonclient-with-servicestate

check_command check_opsipluginon_client_with_states!"C:\\opsi.org\\nagiosplugins\\\

check_memory.exe"

check_interval 10

} define service{

host_name depotclient.domain.local

service_description opsi-direct-checkpluginonclient-from-depot

check_command check_opsipluginon_client_from_depot!"C:\\opsi.org\\nagiosplugins\\check_memory\

.exe"

check_interval 10

}