Pour chaque règle, vous devez définir un nouveau module et l'ajouter dans la configuration ip-tags .
Vous pouvez copier l'exemple /etc/shinken/modules/ip-tag-dmz.cfg et le modifier
define module{
module_name ip-tag-dc1
module_type sync_ip_tag
ip_range 192.168.0.0/24
method append
property use
value dc1
} |
Les propriétés sont :
value sera mis dans la propriété visée, c.a.d. property.value à la fin dans la propriété visée, c.a.d. property.value au début de la propriété visée, c.a.d. property.value dans la propriété visée, c.a.d. property.Vous devez ensuite éditer la définition du tagger pour la lier au nouveau module dans le fichier /etc/shinken/taggers/ip-tags.cfg:
define tagger {
tagger_name ip-tags
order 1
modules ip-tag-dmz,ip-tag-dc1
description This tagger will tag hosts based on their ip range
}
|
La propriété tagger_name ne doit pas contenir les caractères suivants:
|
Une fois votre fichier sauvegardé, vous devez l'ajouter dans la liste des taggers du Synchronizer concerné ( par exemple /etc/shinken/synchronizers/synchronizer-master.cfg )
define synchronizer {
[ ... ]
# Taggers:
# ip-tags
# regexp-tags
taggers ip-tags, regexp-tags, my-new-tagger
[ ... ]
} |
Pour que les modifications soient prises en compte, vous devez ensuite redémarrer le Synchronizer.
Si votre configuration est correcte, vous devriez retrouver votre tagger en bas de page de l'interface de configuration :
|
Le tagger est fait pour comparer des IP et des range d'IP.
Si le champ address d'un hôte est rempli avec un nom DNS, alors le tagger va tenter de le résoudre via une résolution DNS système classique, et prendra comme valeur l'IP ainsi récupérée.
Si nous savons que les serveurs dans le range IP 192.168.0.1/24 sont à Bordeaux, il est intéressant de le assigner automatiquement au royaume Bordeaux, ce qui permettra de les superviser au plus proche possible (et donc avoir les bonnes règles de firewall par exemple pour lancer les sondes vers les serveurs).
Nous pouvons donc définir le module suivant que nous accrochons au tagger (comme indiqué précédemment).
Il va fonctionner ainsi:
define module{
module_name ip-tag-bordeaux
module_type sync_ip_tag
# La range IP de l'hote (champ address)
ip_range 192.168.0.0/24
# on va appliquer la regexp sur le nom de l'hote/cluster
matched_prop host_name
# On va alors ecraser la propriete realm avec la valeur Bordeaux
property realm
method set
value Bordeaux
} |
Si la méthode 1 fonctionne, elle n'est pas optimale: en effet, changer le royaume par Bordeaux est utile, mais dans le futur la localisation à Bordeaux va peu être demander à ce qu'une équipe locale ait les droits d'accès et de notifications sur la machine par exemple.
Il faudrait alors faire un second module, ce n'est pas l'idéal.
Il est donc fortement recommandé de ne pas modifier les propriétés directement, mais plutôt de passer par des modèles d'hôtes/cluster.
Il sera ainsi facile de faire des changements en masse sur toutes les machines Bordeaux, en modifiant juste le modèle Bordeaux.
Nous pouvons donc définir le module suivant que nous accrochons au tagger (comme indiqué au dessus).
Il va:
define module{
module_name ip-tag-bordeaux
module_type sync_ip_tag
# La range IP de l'hote (champ address)
ip_range 192.168.0.0/24
# on va appliquer la regexp sur le nom de l'hote/cluster
matched_prop host_name
# On va alors rajouter le template bordeaux au debut de use (prioritaire)
property use
method prepend
value bordeaux
} |
Vous pouvez consulter la configuration des différents taggers sur nom d'hôtes présent sur le Synchronizer sur la page d'accueil en cliquant sur regexp-tags.
