sommaire - lamdaouarmohamed.files.wordpress.com · rtr(config)#access-list 1 permit 172.16.69.254...

SommaireI-Introduction........................................................................................................................................2Dans le TP............................................................................................................................................2II-SUPERVISION D'UN SERVEUR WINDOWS..............................................................................3

-Mise en place de sondes de supervision sous un serveur Windows...............................................3-Ajout d'un utilisateur......................................................................................................................5-Intégration de l'utilisateur à un groupe pour obtenir des informations utile a la supervision........7-Permettre a l'utilisateur de renvoyer des informations WMI a l'aide de CIMV2...........................8-Autorisation d’accès à DCOM pour notre utilisateur wmiagent..................................................10-Configuration du pare-feu pour laisser passer les informations DCOM et WMI........................12-Configuration du serveur Shinken................................................................................................13

III-Supervision matériels....................................................................................................................18-Supervision d'une Imprimante(XEROX).....................................................................................18-Supervision d'un Routeur(CISCO)...............................................................................................19-Supervision d'un Commutateur(CISCO)......................................................................................22-Test manuel de la sonde sur le commutateur................................................................................24

V-Notifications des alertes..................................................................................................................26-Mise en place de la messagerie....................................................................................................26-Test de la messagerie....................................................................................................................28-Configuration des notifications Shinken......................................................................................29-Test des notifications d'alertes......................................................................................................32

VI-Conclusion....................................................................................................................................34

2/37

I-Introduction.

3/37

II-SUPERVISION D'UN SERVEUR WINDOWS.

-Mise en place de sondes de supervision sous un serveur Windows.

Pour que notre serveur Windows sache qu'il sera la cible de supervision de la part d'un serveur shinken, il faut lui ajouter un rôle qui va lui permettre d'utiliser le protocole SNMP(protocole de supervision) mais sous Windows il existe un module WMI qui permet l'accès à certaines ressources et détails de la machine. Pour ajouter ce rôle il faut se rendre dans le dashboard(tableau de bord) et cliquer sur l'option 2(ajouter des rôles et des fonctionnalités) qui se trouve sur la première page.

Après avoir cliqué sur les quatre premières étapes suivant on atterrie sur cette page qui va permettre de choisir et d'ajouter des fonctionnalités à notre serveur. Dans notre cas on veut ajouter le Service SNMPService SNMP et la fonctionnalité Fournisseur WMI SNMP.Fournisseur WMI SNMP.

4/37

Après avoir ajouté les fonctionnalités , on nous demande s'il après avoir installé toutes les fonctionnalités on peut redémarrer l'ordinateur.

On voit la progression d'installation du service. Puis on remarque que les services qu'on sélectionné sont présent. Une fois l'installation achevé l'ordinateur redémarra automatiquement.

Une fois que l’installation du rôle et des fonctionnalités est achevé on peut passer au côté configuration.

5/37

-Ajout d'un utilisateur.On va crée un utilisateur qui sera spécifique à la supervision sous Windows on va associer cette utilisateur à WMI. Pour ce faire on se rend dans le menu outils et on sélectionne Gestion de l'ordinateur.

On ce place dans le dossier utilisateurs pour crée un nouveau utilisateur.

6/37

Dans le menu on sélectionne Nouvel utilisateur.

On arrive sur la fiche du l'utilisateur a crée la fiche détail les points suivant.

-Nom d'utilisateur

-Nom complet

-Mot de passe

Dans notre cas l’utilisateur se nommera wmiagent et aura comme mot de passe sio2PASS.

Bien sûr pour valider le tout on doit cliquer sur créer.

8/37

-Intégration de l'utilisateur à un groupe pour obtenir des informations utile a la supervision.

Il faut qu'on intégré notre utilisateur dans un groupe qui va nous permettre de rapatrier des informations sur le serveur. On clique sur wmiagentOn clique sur wmiagent on nous ouvre une fenêtre propriétés de wmiagentpropriétés de wmiagent . On se rend dans l'onglet membre demembre de , à l'aide d'ajouterd'ajouter on met notre utilisateur dans le groupe Utilisateurs de l'Analyseur de performancesUtilisateurs de l'Analyseur de performances.

On peut vérifier que notre utilisateur est bien dans le bon groupe on regardant en bas de sa fiche . On peut remarquer qu'il est bien intégré dans le groupe voulut.

9/37

-Permettre a l'utilisateur de renvoyer des informations WMI a l'aide de CIMV2.

On clique droit sur le contrôle WMI , puis on se rend dans propriétés .

Dans l'onglet sécurié on choisit CIMV2 puis on clique sur la case sécurité en bas a droite. Cela va nous permettre d'autoriser un utilisateur a renvoyer des informations WMI via l’espace Commun CIMV2.

10/37

Dans l'onglet Sélectionnez des utilisateurs et des groupes, on saisit wmiagent puis on vérifie si le nom est valide .

Lorsqu'on revient sur l'onglet Sécurité pour ROOT/CIMV2 on clique sur notre utilisateur wmiagent. On lui ajoute comme autorisations :

-Activer le compte.

-Appel à distance autorisé.

12/37

-Autorisation d’accès à DCOM pour notre utilisateur wmiagent.On se rend dans l'onglet PowerShell on tape la syntaxe DCOMCnfg.exe DCOMCnfg.exe cette syntaxe permet de sécurisé la distribution « com »

Dans Services des composants on effectue un clique droit sur Poste de travail on choisit l'onglet propriétés.

Une fois qu'on se trouve dans propriétés on se rend dans l'onglet sécurité OGM clique sur le modifier les limites dans la partie Autorisations d’exécution et d'activation.

13/37

On saisit wmiagent dans les noms puis on vérifie si le nom est valide .

On clique sur wmiagent puis on coche les cases suivante :

-Exécution locale.

-Exécution à distance.

-Activation à distance.

14/37

Une fois que tous cela à été effectué , notre utilisateur a les droits nécessaires pour transmettre toutes les informations au serveur de supervision. Cependant un problème ce pose celui du pare-feu.

-Configuration du pare-feu pour laisser passer les informations DCOM et WMI.

Par défaut le serveur Windows est très renfermé sur lui même(pour la sécurité). Donc il ne pas divulguer des informations de performance(WMI) et des informations système(DCOM). Pour que notre serveur Windows puisse envoyer des informations sensible au serveur de supervision shinken on doit activer les deux règles de filtrages trafic au niveau du pare-feu pour autoriser les flux WMI et DCOM.

15/37

-Configuration du serveur Shinken.Une fois après avoir configuré tout les réglages nécessaire sur le Serveur Windows , on doitconfigurer le serveur Shinken pour qu'il puisse récolter les informations nécessaire. La premiére chose a faire sous Shinken est de configuré le fichier active-directory.cfg pour ce faire on s'aide de la commande shell gedit puis on tape le chemin suivant /etc/shinken/resource.d/active-directory.cfg.

Attention les manipulations suivante seront effectuées a l'aide du super-utliisateur.

On ajoute les informations sur notre utilisateur et notre serveur windows :

$DOMAIN$=WORKGROUP(Car notre serveur n'est dans un domaine défini donc il est dansle domaine par défaut de Windows).

$DOMAINUSERSHORT$=wmiagent(Car notre utilisateur sur le serveur Windows s'appelle wmiagent) ;

$DOMAINPASSWORD$=sio2PASS(c'est le mot de passe qu'on indiqué pour l'utilisateur wmiagent).

16/37

Il faut mettre ces informations car c'est grâce a ces informations que le serveur Shinken peut recevoir des informations de la part du serveur Windows.

Après avoir touché à un fichier on doit absolument redémarrer le service Arbiter de Shinken pour qu'il puisse prendre en compte les changements .

On se place dans le répertoire /var/lib/shinken/libexec , une fois au bon emplacements on supprime wmic a l'aide de la commande Shell rm. Après on se rend dans le répertoire de téléchargements .

Dans un premier temps on dé-zippe le fichier wmi-1.3.14.tar qui a était téléchargé au préalable. Pour dé-zipper on utilise la commande Shell bunzip2. Puis dans un second on extrait l'archive wmi-1.3.14.tar a l'aide de la commande Shell tar xf.

À l'aide des trois syntaxe suivante on va compiler et configurer wmic.

-./autogen.sh

-./configure

-make proto bin/wmic

17/37

On copie wmic dans le répertoire Shinken à l'aide de la commande Shell Cp (suivit du fichier a déplacer) (de l'endroit ou le déplacer).

On place dans le répertoire Shinken a l'aide de la commande Shell cd (suivit du chemin ou se trouve la cible).

On attribue la propriété de wmic a l’utilisateur Shinken.

On se connecte avec l'utilisateur Shinken et en se rend dans le répertoire Shinken avec la commande Shell cd.

Pour qu'on puisse voir ce que la fonctionnalité WMIC, nous renvoie on doit taper la commande Shell suivante : ./wmic -U (nom utilisateur crée sous le serveur Windows)%(motde passe de cet utilisateur) -W (nom de domaine du serveur par défaut WORKGROUP) //(adresse IP du serveur Windows) ''select * from Win32_ComputerSystem''

Les parties en orange sont les partie qui ne bouge pas, les autres couleurs signifient qu'elles sont propre à chaque contexte.

18/37

On obtient toutes les informations que WMIC peut nous remonter.

Quelques exemple :

-NumberOfProcessors: nombre de processeur.

-HypervisirPresent : l'hyperviseur(dans notre cas EXSi) présent.

On se rend dans le fichier SRV2-Windows.cfg, on rajoute le modèle a superviser(windows).

Pour que shinken prenne en compte les modifications on doit redémarrer le service arbiter.

Pour ce faire il suffit de taper service shinken-(suivis du service a redémarrer) restart.

Dans l'interface graphique de shinken on obtient ceci lorsqu'on décide d'afficher selon le serveur Windows.(on voit tous les éléments du serveur Windows soit en vert, rouge ou en unknown )

19/37

On a aussi une vue qui s’appelle minemap qui permet de voir tous les états des services cette vue est intéressante.

20/37

III-Supervision matériels.

-Supervision d'une Imprimante(XEROX).On crée un fichier Xerox-Phaser6600.cfg (fichier de configuration de l'imprimante) dans le répertoire /etc/shinken/hosts/ . Dans ce fichier on indique que c'est une imprimante (printer) , son nom(xerox-phaser6600) et son adresse IP(172.16.1.25) . Toutes les informations vous permettre au serveur de supervision de mieux connaître la machine a superviser.



Lorsqu'on retourne sur l'interface graphique de Shinken on remarque que notre imprimante est bien passée à l'état UP . Donc cela veut dire que notre serveur shinken la supervise.

21/37

-Supervision d'un Routeur(CISCO).On se place dans le répertoire Téléchargements à l'aide de la commande Shell cd.

On extrait le fichier à l'aide de la commande Shell tar-zxvf (suivis du fichier à extraire).

On se rend dans le fichier(check_nwc-health-4.6.1) qu'on vient d'extraire à l'aide de la commande Shell cd.

On va configure et compiler à l'aide des commandes Shell suivante :

On copie le fichier check_nwc_health dans le repertoire /var/lib/shinken/libexec à l'aide de la commande Shell cp. Cp check_new_heatlh /var/lib/shinken/libexec .

Dans le répertoire /var/lib/shinken/libexec , on accorde la propriété de check_new_health ashinken à l'aide de la commande chown utilisateur:groupe (nom du fichier).

Si on test pour voir si les droit sont bien appliqué on fait un ls du répertoire . Voici le résultat:

On remarque bien que le fichier appartient a shinken et qu'il est aussi propriété du groupe shinken.

22/37

On crée un fichier RTR.cfg dans le repertoire /etc/shinken/hosts/ . Ce fichier va contenir toutes les informations suivante : le type de machine ( routeur , de marque cisco) , son nom (RTR) et son adresse IP (172.16.69.254).

Sur le routeur on crée une acces-list qui va permettre au serveur supervision une connexion.

RTR(config)#access-list 1 permit 172.16.69.254 On active le service SNMP en mode lecture seule(RO) sur la communauté public .

RTR(config)#snmp-server community public ro 1 Pour que shinken prenne en compte les modifications on doit redémarrer le service arbiter.


Dans l'interface graphique de Shinken on voit que notre routeur est bien présent et en mode UP. Cependant on un mode CRITICAL qui est du au fait que les carte ne sont toutes activées.

23/37

On se connecte avec l'utilisateur shinken et on se rend le répertoire /var/lib/shinken/libexec .

On vérifie l'usage mémoire du routeur à l'aide de la commande suivante :

./check_nwc_health --mode (informations tester) --hostname (adresse IP du matériel) --community public.

24/37

-Supervision d'un Commutateur(CISCO).Pour qu'on puisse superviser un matériel réseau il faut toujours le déclarer dans le fichier du serveur de supervision(dans notre cas on déclare les fichier de configuration dans le dossier /etc/hosts/shinken/ . Le fichier va s'appeler COMM1.cfg , il faut ajouter le type du matériel(dans notre cas commutateur) , le nom du matériel(COMM1) et l'adresse IP du matériel(172.16.69.253).

Sur le commutateur on crée une acces-list qui va permettre au serveur supervision une connexion.

COMM1(config)#access-list 1 permit 172.16.69.253 On active le service SNMP en mode lecture seule(RO) sur la communauté public .

COMM1(config)#snmp-server community public ro 1 Pour que shinken prenne en compte les modifications on doit redémarrer le service arbiter.


On voit sur l'interface graphique de shinken que notre commutateur est en mode UP est que la plupart de ses composantes sont au vert donc notre commutateur est fonctionnel.

25/37

L'interface status est critical car la majorité des interfaces sont en mode down.

26/37

-Test manuel de la sonde sur le commutateur.Dans cette partie on va essayer de superviser un port du switch car on peut remarquer quedans le cas précédent , le serveur de supervision recevait une erreur car tous les port n'étaitpas UP.

Pour ce faire on se rend dans le répertoire /var/lib/shinken/libexec . Tout en étant connecté avec l’utilisateur shinken .

On va tester notre sonde de façon manuelle . On tape ./check_nwc_health –hostname (adresse IP du matériel) –-timeout (le délai d’expiration en cas de non connexion) –-community public –-mode interface-status –-name (nom de l'interface a superviser).

Dans notre cas l'interface à superviser est la Fast Ethernet 0/1.

On se reconnecte en root , puis on se rend dans le fichier /etc/shinken/packs/switch pour rajouter une indication . On lui indique que le port a superviser est le port Fast Ethernet 0/1

Dans le fichier /etc/shinken/packs/switch/services on rajoute le chiffre 1 pour qu'il puisse prendre en compte le fait de superviser que le port spécifique.

27/37



Pour voir si nos réglages on bien été enregistré , on se rend dans l'interface graphique de

shinken. On remarque que l'interface status qui était en critique auparavant est devenu OK car on ne supervise que le port Fast Ethernet 0/1(et qu'il est branché et UP)

Le seul bémol des sonde et qu'il ne peuvent s'appliquer qu'un seul port du switch on peut pas mettre plusieurs ports(dans le cas ou on aura juste 5 port allumé). Mais les sondes manuelle reste très intéressante dans la supervision.

28/37

V-Notifications des alertes.

Dans notre une société le serveur shinken supervise cependant il ce peut que certaine fois on ne soit pas présent et derrière notre pc. Donc l'envoie d'alertes sur notre boite mail ou sur notre téléphone permet d'éviter certaines mésaventures.

-Mise en place de la messagerie.On doit installer des pré-requis pour notre messagerie fonctionne . Pour ce faire on installer un paquets html qui va permettre d'envoyer des messages lorsque shinken envoieses scripts .

On va installer le service de messagerie sous Linux qui est Postfix. À l'aide de la commande Shell apt-get install postfix on peut installe le service Postfix. Une fois installer on va le paramétrer . On nous propose de type de serveur de messagerie , on choisit site internet .

On nomme le nom du courrier serveur shinken cela n'a pas trop d'importance car l'importance c'est qu'on puisse générer des messages.

29/37

On configure notre serveur de messagerie , en rajoutant la ligne suivante

smtp_host_lookup = native dans le fichier /etc/postfix/main.cf

Pour que le service Postfixe prenne en compte le changements il faut redémarrer le service postfix. À l'aide de la commande Shell service postfix restart .

30/37

-Test de la messagerie On crée un utlisateur adminshinken à l'aide de la commande adduser (suivit du nom de l-'utlisateur a créer)

On va faire un test de notre messagerie, pour ce faire on va envoyer un mail à adminshinken@serveurshinken . Il suffit de taper mail -s ''objet du message'' adresse mail du destinataire et le contenu . Pour quitter le message ctrl+d et pour l'envoyer ctrl+d .

Dans nos mail on voit bien qu'on reçu notre mail .

31/37

mailto:adminshinken@serveurshinken

-Configuration des notifications Shinken.Dans le fichier /etc/shinekn/notificationways/email.cfg , on trouve des

Les courriels sont envoyés 7 jours sur 7 et 24 heures sur 24.

Les notifications sont envoyées pour les états c, w, r des hôtes et d, u,r,f des services.

les état c, w, r des hôtes ont pour significations:

w = lorsque le service est en danger.

u = Lorsque le service est inconnu

c = lorsque le service est critique.

r = Lorsque on retrouve un service.(reprise).

les état d, u,r,f des services ont pour significations:

d = service éteint (arrêté)u = service introuvable.r = service retrouvé

Dans le fichier /etc/shinken/timeperiods/24x7.cfg on peut voir que notre configuration fait qu'on reçoit des alertes tout le temps.

32/37

On va crée un nouveau fichier pour l'adminshinken pour ce faire on va dans le répertoire /etc/shinken/contacts/.

Voici la configuration à faire dans le fichier adminshinken.cfg .Dans le fichier on déclare :

use : on déclare quel type d'utilisateur.

Contact name : on déclare le nom de l’utilisateur.

Email : on déclare l'adresse mail de l’utilisateur.

Dans le fichier /etc/shinken/hosts/localhost.cfg . On remarque que il y a un groupe qui s'appelle admins.

Donc on doit rajouter notre utilisateur adminshinken dans le fichier /etc/shinken/contactgroups qui contient les membres du groupe admins .

Dans on doit rajouter notre utilisateur adminshinken dans la dernière ligne qui est faites pour recevoir les membres du groupe .

Donc notre utilisateur adminshinken a une boite mail en liaison avec le serveur shinken.

33/37

Dans le fichier /etc/shinken/packs/linux-snmp/services/disks.cfg on peut remaarmquer la fréquence à laquel il envoie des notification. Dans notre cas on voit qu'il envoie des notification tout les heures .

Dans le fichier /etc/shinken/templates/time_templates.cfg on peut voir les fréquences d 'envoie des notifications . Le modèle qui nous intéresse est la fréquence 5 minutes .

Voic les parametres qui nous intéresse :max_check_attemps: Nombre de checks renvoyant une erreur avant l’envoi d’une notification.

notificationnormal_check_interval: Temps entre deux check renvoyant une erreur.

retry_interval: temps entre deux checks ne renvoyant pas d’erreur.

Dans le fichier où on ùet la fréquence des notifications on met la fréquence à 5 minutes.

34/37

-Test des notifications d'alertes.Pour tester le fonctionnement des alertes on va provoquer un problème pour que notre serveur shinken nous envoie une alertes . Le problème sera provoquer sur note serveur Linux en lui injectera un cd dans le lecteur de CD-ROM.

Sous ESXi, on branche un lecteur CD-rom au démarrage avec un ISO.

On a directement un critical qui remonte sur l'interface graphique de shinken.

35/37

On remarque qu'on a un message qui fait remonter l'erreur .

Avec le temps on remarque que les messages arrive ils décrivent les problèmes engendré par cette surcharge du disque dur.

36/37

VI-Conclusion.

37/37

sommaire - lamdaouarmohamed.files.wordpress.com · rtr(config)#access-list 1 permit 172.16.69.254...

Documents