1

Tutoriel d’installation : SHINKEN Sommaire

Avant-propos : ..................................................................................................................................... 1

1. Installation de Shinken .................................................................................................................... 1

2. Installation de Webui ...................................................................................................................... 2

3. Connexion à l'interface web ............................................................................................................ 3

4. Ajout de l’onglet « /wall » ............................................................................................................... 4

5. Problème lié aux hôtes .................................................................................................................... 5

6. Ajout du pack linux-ssh .................................................................................................................... 5

7. Ajout d’hôte(s) ................................................................................................................................. 6

8. Ajout des plugins snmp, nagios, ntp................................................................................................ 6

9. Correction de l’erreur « Log_file_Health » ...................................................................................... 8

10. Installation de PNP4Nagios ......................................................................................................... 9

11. Envoi des mails d’alertes ........................................................................................................... 13

Avant-propos : Le tutoriel suivant est réalisé avec une machine virtuelle Debian Wheezy ayant une adresse IP fixe

dans le cadre de l’épreuve E4 du BTS SIO : le laboratoire Galaxy Swiss Bourdin (cas GSB).

Shinken est un logiciel libre permettant la surveillance système et réseau, il est très proche de Nagios

dans son utilisation, mais il apporte une supervision distribuée et hautement disponible facile à

mettre en place. Je vous partage ma procédure d’installation pour une mise en place très simple et

rapide.

Le tutoriel suivant explique comment installer la version 2.2 du logiciel Shinken.

1. Installation de Shinken L’installation du logiciel Shinken se fait en deux temps : d’abord il faut créer un utilisateur Shinken et

installer les dépendances nécessaires, puis nous pourrons passer à l’installation du logiciel.

a) Création d’un utilisateur :

adduser shinken kbkjbkbhbhjbjhvjhvjhvjvhjvjhvjh

b) Installation des dépendances nécessaires :

aptitude install python-pycurl python-setuptools python-pip sysstat curl python-cherrypy3

python-crypto -y

Une fois l'utilisateur créé et les dépendances installées, nous pouvons passer à l'installation de

Shinken.

Pour ce faire, nous allons utiliser Pip :

pip install shinken

2

Une fois l’installation terminée, on s’identifie avec l’utilisateur préalablement créé :

su shinken

2. Installation de Webui Shinken propose son propre gestionnaire de greffons avec le programme shinken. La CLI de Shinken a

besoin d'être initialisée afin de générer le fichier Ini contenant les chemins vers les différents

répertoires de configuration de l'outil. Pour ce faire :

shinken -- init

On peut dorénavant installer le module Webui :

shinken install webui

On installe aussi un module d’identification, je choisis identification par fichier de configuration :

shinken install auth-cfg-password

Il faut installer également un module pour stocker les données des utilisateurs dans une base de

données. Si vous oubliez cette étape, vous aurez l’erreur “Warning: You didn’t define a WebUI

module for saving user preferences like the MongoDB one. You won’t be able to use this page!” lors

de la connexion à l’interface web. Je choisis le module sqlitedb :

shinken install sqlitedb

Il faut maintenant modifier les fichiers de configuration pour que les différents modules

fonctionnent.

Modifier le fichier /etc/shinken/brokers/broker-master.cfg pour activer le module webUI (ligne 40

pour moi) :

Modifier maintenant le fichier /etc/shinken/modules/webui.cfg pour activer les modules

d’authentification et de la base de données SQLite pour l’interface utilisateur (ligne 25 pour moi) :

3

Vous pouvez maintenant changer le mot de passe admin par défaut. Pour ce faire, il faut modifier le

fichier /etc/shinken/contacts/admin.cfg

On vérifie que les fichiers de configuration ont correctement été modifiés (en utilisateur root) :

service shinken check

On démarre maintenant les services pour prendre en compte la nouvelle configuration :

service shinken start ou /etc/init.d/shinken start

3. Connexion à l'interface web Vous pouvez maintenant accéder à l'interface web de votre serveur à partir de l'adresse suivante :

http://IPSERVEUR:: 7767Les identifiants par défaut sont admin / admin.

Voici les différentes erreurs possibles :

Les identifiants ne correspondent pas à ceux renseigner dans le fichier

/etc/shinken/contacts/admin.cfg :

Les données des utilisateurs ne sont pas accessibles dues à l'oubli d'installation de la base de

données ou à la mauvaise installation de celle-ci :

4

4. Ajout de l’onglet « /wall » En naviguant dans les différents onglets de Shinken, vous pouvez remarquer que l’onglet Wall n’est

pas accessible :

Nous allons maintenant corriger ce problème. Dans un premier temps, nous devons télécharger le

bon fichier de configuration, pour ce faire :

wget https://raw.githubusercontent.com/shinken-monitoring/mod-

webui/master/module/plugins/wall/wall.py

Ensuite, nous allons enregistrer le fichier original afin de le restaurer en cas de besoin :

cp /var/lib/shinken/modules/webui/plugins/wall/wall.py

/var/lib/shinken/modules/webui/plugins/wall/originalwall

Une fois le fichier original sauvegardé, nous allons injecter le nouveau :

mv wall.py /var/lib/shinken/modules/webui/plugins/wall/

On vérifie que les fichiers de configuration ont correctement été modifiés (en utilisateur root) :

service shinken check

On redémarre maintenant les services pour prendre en compte la nouvelle configuration :

service shinken restart ou /etc/init.d/shinken restart

Recharger votre page web, l’erreur 404 à disparue :

Nous avons maintenant une interface web fonctionnant de manière optimale.

5

5. Problème lié aux hôtes

Pour corriger cette erreur, il faut installer les différents packs permettant de remonter l'information.

6. Ajout du pack linux-ssh Nous allons installer des packs qui vont permettre la remontée d’information des hôtes distants vers

le serveur Shinken.

Un hôte est un élément réseau (serveurs, postes de travail, éléments d'interconnexions) dont les

services (disque, mémoire, cpu...) vont être supervisés par le serveur Shinken.

Dans un premier temps, on va choisir le pack linux-ssh qui est un mode agent : le script ouvre une

connexion ssh pour exécuter une commande sur l’hôte distant et récupérer l’information. Il faut

savoir que ce mode n'est pas le plus recommandé, car il consomme plus de ressources qu'une

requête SNMP classique.

Pour installer le pack linux-ssh, il suffit de faire (en utilisateur shinken) :

shinken install linux-ssh

Ces plugins ont besoin d’une librairie nommée python-paramiko. On repasse en root pour effectuer

cette installation :

aptitude install python-paramiko

Ces plugins lancent une connexion ssh sur l’hôte distant (dans notre cas le serveur local). On va donc

générer une paire de clés ssh et donner la clé publique à l’utilisateur shinken :

ssh-keygen

Ne pas saisir de passphrase sinon le script attendrait une intervention humaine pour saisir cette

dernière à chaque exécution.

On déploie la clé publique :

ssh-copy-id -i ~/.ssh/id_rsa shinken@localhost

On va tester un plugin pour voir que tout fonctionne parfaitement :

/var/lib/shinken/libexec/check_load_average_by_ssh.py -H localhost

Ce qui doit donner :

Ok: load average is good 0.59,0.27,0.15 | load1=0.59;1.00;2.00;; load5=0.27;1.00;2.00;;

load15=0.15;1.00;2.00;;

On va donc ajouter le tag linux-ssh à la définition de notre hôte. Nous allons dans un premier temps

copier les fichiers originaux :

cp /etc/shinken/hosts/localhost.cfg /etc/shinken/hosts/originallocalhost

6

On peut maintenant ajouter le tag linux-ssh. Pour cela, on édite le fichier

/etc/shinken/hosts/localhost. cfg :

On vérifie que les fichiers de configuration ont correctement été modifiés (en utilisateur root) :

service shinken check

On redémarre maintenant les services pour prendre en compte la nouvelle configuration :

service shinken restart ou /etc/init.d/shinken restart

7. Ajout d’hôte(s) Maintenant, nous pouvons ajouter des hôtes : pour ajouter un hôte, il suffit de créer un fichier ‘. cfg’

dans le dossier /etc/shinken/hosts/

Il est donc recommandé de créer un fichier ‘.Cfg' par hôte.

Un fichier de configuration se présente de la manière suivante :

8. Ajout des plugins snmp, nagios, ntp Comme dis plus haut, le pack linux-ssh consomme plus de ressources qu'une requête SNMP classique

c'est pourquoi nous allons maintenant installer le pack linux-snmp. Pour ce faire :

shinken install linux-snmp

Les manipulations suivantes seront à effectuer sur tous les hôtes à monitorer.

Il faut installer différents paquets (en utilisateur root) : snmpd permet de rendre accessible une

machine A dont on souhaite récupérer les informations de fonctionnement pour les exploiter sur une

autre machine B, ntp est un protocole qui permet de synchroniser via un réseau informatique

l'horloge locale d'ordinateurs sur une référence d'heure et enfin nagios-plugins sont les plugins de

Nagios qui vont permettre la remonter d’information (les plugins sont compatibles avec Shinken).

aptitude install snmpd nagios-plugins ntp

Il faut modifier le fichier de configuration suivant pour autoriser snmp à être écouté à distance

/etc/snmp/snmpd.conf : il faut commenter la première ligne enlever le commentaire de la deuxième.

7

Prenez exemple sur le fichier suivant.

Maintenant, commenter la ligne comme il suit et ajouter la seconde à votre fichier.

Pour terminer on redémarre le service :

service snmpd restart

On retourne désormais sur notre serveur de monitoring : Shinken

Deux soucis de l'installation sous Debian sont à corriger :

Il faut changer les droits du répertoire /usr/lib/nagios/plugins/check_icmp (afin de mettre les droit

setuid) :

chmod u+s /usr/lib/nagios/plugins/check_icmp

Le module PERL utils.pm est mal référencé par les greffons Nagios ; on le fait pointer sur celui de

notre installation de PERL dans /usr/share/perl5 : dans un premier temps déplacez-vous dans le

répertoire /usr/share/perl5 puis créer un lien symbolique.

cd /usr/share/perl5/

ln -s /usr/lib/nagios/plugins/utils.pm

Les deux soucis étant à présent corrigés, on peut maintenant modifier le fichier de configuration de

notre hôte afin de préciser que celui-ci doit utiliser le pack linux-snmp et non plus le pack linux-ssh :

On peut maintenant démarrer le démon ntp :

service ntp start

On télécharge aussi les plugins de shinken, pour ce faire il suffit de télécharger l’archive à l’adresse

suivante :

8

wget --no-check-certificate https://www.monitoring-plugins.org/download/monitoring-plugins-

2.1.1.tar.gz

À l'aide de la commande : tar -xvzf monitoring-plugins-2.1.1.tar.gz, nous allons décompresser

l’archive. Déplacez-vous ensuite dans le dossier et installer les plugins à l’aide de la commande :

./configure --with-nagios-user=shinken --with-nagios-group=shinken --enable-libtap --enable-extra-

opts --enable-perl-modules --libexecdir=/usr/lib/nagios/plugins

Il faut maintenant terminer l’installation à l’aide de la commande :

make install

Une fois les plugins installés, on vérifie que les fichiers de configuration ont correctement été

modifiés :

service shinken check

Et on redémarre les services pour prendre en compte la nouvelle configuration :

service shinken restart ou /etc/init.d/shinken restart

Retourner sur votre navigateur à l’adresse du serveur, vos informations ont remonté vers le serveur :

9. Correction de l’erreur « Log_file_Health » L’utilisateur shinken ne possédant pas de droit d’écriture sur le répertoire /var/log/syslog il ne peut

donc pas écrire de log dans le journal.

Pour contourner le problème, il suffit de créer un fichier dans le répertoire et de rediriger les logs

dans celui-ci.

On commence par créer le fichier (en root) :

mkdir /var/log/logshinken.log

On donne tous les droits à tout le monde :

chmod +x /var/log/logshinken.log

On copie le fichier original pour le restaurer en cas de besoin :

cp /var/lib/shinken/libexec/logFiles_linux.conf /var/lib/shinken/libexec/originallogFiles_linux

9

On modifie le fichier afin de changer le chemin d’accès au log :

vim /var/lib/shinken/libexec/logFiles_linux.conf

On vérifie que les fichiers de configuration ont correctement été modifiés :

service shinken check

Et on redémarre les services pour prendre en compte la nouvelle configuration :

service shinken restart ou /etc/init.d/shinken restart

On vérifie maintenant :

L’erreur n’est plus référencée.

10. Installation de PNP4Nagios Il nous faut intégrer à notre environnement de supervision, un outil de monitoring. PNP4Nagios

permet de récupérer les valeurs de performance des plugins et de les injecter dans des bases rrdtool

puis de créer des graphiques via une interface en PHP.

Cette installation nous permettra donc d’avoir les graphiques de performances de nos différents

plugins directement dans l’interface de Shinken.

L’installation de PNP4Nagios se fait en deux temps : il nous faut avant tout installer les prérequis car

depuis sa version 2, Shinken utilise son propre moteur d’interface web, apache et php ne sont donc

pas encore installé, puis nous compilerons l’outil PNP4Nagios.

1. Installation des prérequis :

aptitude install apache2 php5 libapache2-mod-php5 rrdtool librrds-perl php5-gd

2. Compiler PNP4Nagios :

On va se procurer les sources à partir de l’adresse suivante :

http://downloads.sourceforge.net/project/pnp4nagios/PNP-c.6/ prenez la dernière version

de l’outil (pnp4nagios-0.6.25.tar.gz). Pour ce faire :

wget http://downloads.sourceforge.net/project/pnp4nagios/PNP-0.6/pnp4nagios-0.6.25.tar.gz

Décompresser l’archive :

tar -xzf pnp4nagios-0.6.25.tar.gz

10

Déplacez-vous maintenant dans le dossier.

Lors de l’étape de configuration de la compilation, on indique que l’on veut que PNP

s’authentifie avec l’utilisateur Shinken :

./configure --with-nagios-user=shinken --with-nagios-group=shinken

Vérifier le résultat de la commande à la fin :

Il ne reste plus qu’à compiler et à installer. d'abord, la compilation des binaires :

make all

Puis l’installation de tous ce qu’il faut :

make fullinstall

Nous allons maintenant passer à la configuration de l’interface Web

Le fichier de configuration d’Apache fournit par défaut utilise l’authentification de Nagios. L’UI de

Shinken n’utilise pas Apache, ces directives doivent donc être adaptées en conséquence. Pour

simplement supprimer l’authentification, commenter les lignes suivantes dans le fichier de

configuration d’Apache /etc/apache2/conf.d/pnp4nagios.conf :

On active également le mode rewrite d’Apache qui est utilisé par PNP et on redémarre le service

Apache :

a2enmod rewrite

service apache2 restart

11

On peut maintenant vérifier que tout est correctement installé en se rendant sur l’interface, on ne

doit avoir que du vert : http://LESERVEUR/pnp4nagios :

Il faut maintenant supprimer ou renommer le fichier install.php :

mv /usr/local/pnp4nagios/share/install.php /usr/local/pnp4nagios/share/install.php.old

Si on retourne maintenant sur l’interface de PNP, on a le message d’erreur suivant : “perfdata

directory “/usr/local/pnp4nagios/var/perfdata/” is empty”. C’est normal, il faut maintenant installer

le module Shinken qui va transmettre les données à PNP.

Installation des modules Shinken :

On s’authentifie avec notre utilisateur Shinken puis on installe les modules requis :

su shinken

shinken install npcdmod

shinken install ui-pnp

On active le module npcmod dans le fichier de configuration du broker /etc/shinken/brokers/broker-

master.cfg :

12

On ajoute la prise en charge du module ui-pnp dans le fichier de configuration de l’interface de

Shiken /etc/shinken/modules/webui.cfg :

On vérifie que les fichiers de configuration ont correctement été modifiés :

service shinken check

Et on redémarre les services pour prendre en compte la nouvelle configuration :

service shinken restart ou /etc/init.d/shinken restart

service npcd restart

Vérifications :

On retourne sur l’interface web de PNP4Nagios et on vérifie que le service fonctionne correctement

(http://LESEdRVEUR/pnp4nagios). Si vous avez un message d’erreur comme quoi le répertoire

perfdata est vide, attendez quelques minutes, s’il n’y a pas de changement, vérifier la configuration

de votre Shinken et le bon fonctionnement des cheks.

Interface web de PNP4Nagios

13

On peut maintenant vérifier que l’intégration à Shinken fonctionne correctement :

Si cela ne fonctionne pas, il se peut que le problème vient d’une mauvaise résolution du nom de

machine. Vous pouvez modifier le fichier /etc/shinken/modules/ui-pnp.cfg et changer l’URL en

remplaçant le nom de machine par l’IP.

11. Envoi des mails d’alertes Nous devons maintenant installer les paquets suivants :

aptitude install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

Les paquets : postfix c’est postfix, mailutils permet la gestion des courriels par la console, libsasl2-2

est l’implémentation de l’interface de programmation de Cyrus SASL, ca-certificates contient des

fichiers PEM de certificats CA, et pour finir libsasl2-modules contient des modules pour le paquet

libsasl2-2.

Nous allons maintenant nous occuper de la configuration. On ouvre le fichier de configuration de

Postfix :

vim /etc/postfix/main.cf

On modifie la ligne :

Par :

Cela sert à indiquer que nous utiliserons le SMTP de Gmail. Ensuite, en dessous, on ajoute les lignes

suivantes :

14

Cela sert à activer l’authentification, à indiquer où se trouve le fichier sasl_passwd que nous créerons

plus tard, à interdire le mode anonyme, à indiquer où se trouve le certificat, et pour finir à utiliser le

tls. On enregistre et on quitte.

On va maintenant préciser l’adresse Gmail d’où nous voulons que les mails partent. Pour cela, il faut

créer le fichier suivant :

vim /etc/postfix/sasl_passwd

Dans ce fichier vide, on ajoute la ligne suivante :

[smtp.gmail.com]:587 USERNAME@gmail.com:PASSWORD

Comme vous l’aurez compris, on remplace USERNAME par notre nom d’utilisateur gmail.com et

PASSWORD par notre mot de passe. Au début, on laisse le smtp de Gmail. On enregistre et on quitte.

On attribue maintenant les droits pour pouvoir utiliser ce fichier :

chmod 400 /etc/postfix/sasl_passwd

On exécute un postmap, cela permettra de créer une sorte de base de données.

postmap /etc/postfix/sasl_passwd

On redirige le certificat vers /etc/postfix/cacert.pem :

cat /etc/ssl/certs/Thawte_Premium_Server_CA.pem | tee -a /etc/postfix/cacert.pem

On relance postfix pour que tous nos changements soient pris en compte.

/etc/init.d/postfix reload

Pour tester, nous pouvons exécuter la commande suivante :

echo "Test mail from postfix" | mail -s "Test Postfix" adresse@mail.com

Remplacez adresse@mail.com par l’adresse mail de la personne qui recevra le mail. Dans les

messages envoyés dans votre adresse gmail.com, vous devriez voir que vous avez envoyé un mail

dont l’objet est “Test Postfix”, le contenu du mail est “test mail from postfix”, le destinataire est

adresse@mail.com. Le destinataire doit normalement avoir reçu votre mail.