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:
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):
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{
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{
max_check_attempts 10
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{
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 {
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:
define hostgroup {
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{
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:
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:
#!/usr/bin/env python
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 {
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 }
define command {
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"
}
define command {
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"
}
define command {
command_name check_opsidepotsync
command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$
}
define command {
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 }
define command {
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 }
define command {
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 }
define command {
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$
}
define command {
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$"
}
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{
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
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.
hostgroup_name opsi-server
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{