Poller on Zwindler's Reflection

Impossible de faire disparaitre les hôtes après suppression d’un poller Centreon

Tue, 22 Aug 2017 11:45:21 +0000

Des hôtes qui n’existent plus sont toujours visible dans l’interface de Centreon

Je plante le décor : Vous avez une infrastructure supervisée avec Centreon. Cool :). Vous aviez des collecteurs distants (aka poller) et vous avez décidé de les supprimer finalement (je sais pas, imaginons que finalement le client décide d’annuler le projet par exemple, même si ça n’arrive jamais).

Et là, surprise. Vous n’aviez pas remarqué avant d’avoir définitivement supprimé la machine poller et toute sa configuration, mais les hôtes précédemment supervisés sont toujours visibles dans l’interface de Centreon, avec leur état en date de la dernière fois qu’un check a eu lieu, indéfiniment.

Ici, une capture d’écran du 17, avec des serveurs qui ont répondu la dernière fois le 16 !

Pourtant, ils n’existent plus dans votre configuration !! Tout est désactivé (ou supprimé). Vous ne voyez pas ce que vous pouvez faire de plus !

Back in time

Il faut déjà se rappeler comment marche Centreon, dans un premier temps.

Historiquement, Centreon se basait sur Nagios. Et Nagios est un programme des années 2000, monolithique, codé en C, et qui ne dispose pas, par conception, de stockage pour historiser les états des serveurs surveillés.

Ça peut paraître fou aujourd’hui, mais Nagios n’a pas de base de données ! L’ensemble des états à un moment donné des serveurs était (est) stocké dans un fichier plat, tout le temps réécrit et que vous pouvez trouver dans un sous répertoire de nagios (var/status.log).

Les premières lignes du status.log

Cette méthode de fonctionnement « simple » (l’interface HTTP en CGI a juste à lire le fichier plat pour afficher les états des serveurs) est catastrophique pour les performances. J’ai vu des contextes où ce fichier était stocké en RAM via un ramdisk pour essayer de supporter un peu mieux la charge…

Conscients du manque qu’occasionne l’absence de base de données pour historiser l’état des serveurs au delà de leur état instantané, les gens de chez Nagios ont créé un connecteur externe (le « broker » ndo2db) qui permet de transmettre une copie des résultats à une base de données (MySQL le plus souvent mais je me demande si il n’y a pas aussi Oracle ?). Le modèle de la base NDO est accessible sur le site de Nagios.

Où je veux en venir avec tout ça ?

Ce broker externe a été un peu détourné de son but initial par plusieurs projets, dont Centreon, qui l’a utilisé en tant que source principale pour afficher les status des serveurs. Utiliser la base NDO comme source principale a un 2ème avantage : il est possible d’agréger plusieurs serveur Nagios dans une même base de données. On a donc la possibilité de gérer plusieurs serveur depuis une même interface => c’est le principe utilisé par les collecteurs de Centreon.

Le collecteur par défaut (Central) est composé du cœur de Centreon lui même gérant l’interface et la configuration de tous les pollers ainsi que de la base NDO et du connecteur NDO2DB. Les pollers eux ne sont que des moteurs Nagios, leur configuration « Nagios » est générée par le Central, et les données sont collectées via ndomod (le connecteur qui envoie les données sur le ndo2db).
[Avant de me prendre la remarque, ce que je dis ici n’est plus tout à fait vrai car Centreon et réécrit depuis longtemps tous ces composants, notamment centreon-broker pour ndo2db, centreon-engine pour le moteur Nagios. Mais le principe reste le même]

Comme la base contenant la configuration des pollers est distincte de la base NDO, il est « normal » que l’inactivation d’un poller n’ait pas d’impact sur le contenu de la base NDO. NDO ne stocke des données venant des serveurs Nagios, au fil de l’eau, et n’a aucune connaissance de la configuration dans Centreon…

La vraie méthode

Si vous n’avez pas encore tout pété comme je le décris dans le premier paragraphe, vous serez content d’apprendre qu’il existe une meilleure méthode. La « vraie » méthode (à moins qu’il y en ait encore une autre que je ne connais pas) est décrite dans ce post que j’ai retrouvé sur le forum Monitoring-fr (lien mort, pas sauvegardé par Internet Archive).

David GUENAULT (un des piliers de Monitoring-fr et qui a contribué sur plusieurs projets) nous donne la solution :

bah en fait c’est tout simple
tu réaffecte tes hôtes sur le poller principal :

configuration->hosts puis filtre sur le poller que tu veux enlever

selection des hôtes

dans la combo => massive change

dans la combo monitored from => tu selectionne ton central et validation

tu supprimes ensuite le poller dans l’interface de centreon :

tu supprime ta config ndo relative au poller que tu veux enlever : configuration -> centreon -> ndomod

tu supprime le poller dans : configuration->centreon->pollers

tu pousses ta configuration : configuration -> nagios -> generate

Bon et si c’est trop tard ?

Mais si vous êtes sur cet article c’est peut être que c’est déjà trop tard et que vous n’avez plus moyen de réaliser la procédure ci-dessus ?

Et bien là, pas le choix. Il va falloir aller bidouiller la base de données NDO !

Le plus simple est de se connecter directement via le shell mysql depuis votre serveur Central. Dans la base de données NDO, on peut donc chercher les instances existantes :

select * from nagios_instances;
+-------------+---------------+----------------------+
| instance_id | instance_name | instance_description |
+-------------+---------------+----------------------+
| 1 | Central | |
| 3 | Poller1 | |
| 4 | Poller2 | |
| 5 | Poller3 | |
+-------------+---------------+----------------------+

Dans mon cas, c’est Poller1 que j’ai supprimé. Pour essayer de ne pas trop faire n’importe quoi, je préfère toujours regarde un peu ce que je compte modifier avant de le faire ;-)

Je liste tous les objets de Nagios, puis je compare avec ceux de mon instance 3.

SELECT count(*) FROM nagios_objects;
+----------+
| count(*) |
+----------+
| 11820 |
+----------+
1 row in set (0.00 sec)
SELECT count(*) FROM nagios_objects where instance_id = 3;
+----------+
| count(*) |
+----------+
| 815 |
+----------+
1 row in set (0.00 sec)

Connaissant mon infra, cela parait cohérent. Le Poller1 est un petit poller peu chargé. Je peux donc utiliser ma baguette magique : on a de la chance, NDO prévoit un « flag » is_active qui permet d’activer ou non un objet. Et il se trouve que Centreon gère correctement ce flag. Pour cacher nos hôtes fantômes dans Centreon, il suffit juste de les désactiver avec la commande suivante :

UPDATE nagios_objects SET is_active=0 WHERE instance_id = 3;

Normalement c’est quasi-instantané. Tous les hôtes précédemment liés au Poller1 doivent disparaître de l’interface.

Et la même en un peu plus chirurgical :

select object_id,instance_id,name1,is_active from nagios_objects where name1 like &quot;VIEUX_SERVEUR_OUBLIE_HS&quot;;
+-----------+-------------+-------------------------+-----------+
| object_id | instance_id | name1 | is_active |
+-----------+-------------+-------------------------+-----------+
| 6462 | 4 | VIEUX_SERVEUR_OUBLIE_HS | 1 |
| 6472 | 4 | VIEUX_SERVEUR_OUBLIE_HS | 1 |
+-----------+-------------+-------------------------+-----------+
UPDATE nagios_objects SET is_active=0 where name1 like &quot;VIEUX_SERVEUR_OUBLIE_HS&quot;;
Query OK, 2 rows affected (0.01 sec)
Rows matched: 2 Changed: 2 Warnings: 0

« J’aime beaucoup les zèbres, les rayures sont bien parallèles. »

J’ai eu le plaisir récemment de ré-écouter le sketch de Pierre Desproges : « Le maniaque ». Voilà la toute première phrase du sketch :

« Je ne suis pas à proprement parler ce qu’on appelle un maniaque. Simplement j’aime que tout brille et que tout soit bien rangé. »

Si vous non plus, vous ne pouvez pas vous résoudre à laisser trainer dans NDO des milliers d’objets, certes inactivés, mais toujours bien présents, cachés sous le tapis, la suite de cet article est pour vous (ou si vous êtes simplement curieux).

Pour descendre un peu plus dans les arcanes de NDO, je vous propose de regarder un peu ce qu’on peut trouver avec les requêtes suivantes :

select host_id,instance_id,display_name
from nagios_hosts
where instance_id != 1 limit 10;
+---------+-------------+--------------------+
| host_id | instance_id | display_name |
+---------+-------------+--------------------+
| 32149 | 2 | AAAAAA-HHHHHH01 |
| 32157 | 2 | AAAAAA-DADADADAD02 |
| 32150 | 2 | AAAAAA-DAD02 |
| 32146 | 2 | AAAAAA-GGGG |
| 32151 | 2 | AAAAAA-DDDDDA |
| 32152 | 2 | AAAAAA-DDDDDB |
| 32153 | 2 | AAAAAA-EEEE02 |
| 32154 | 2 | AAAAAA-FFFFFFF02 |
| 32155 | 2 | AAAAAA-FFFFFF02 |
| 32156 | 2 | AAAAAA-UUUUUUUUU01 |
+---------+-------------+--------------------+
10 rows in set (0.00 sec)
select object_id,instance_id,name1,name2,is_active from nagios_objects where instance_id != 1 limit 10;
+-----------+-------------+------------------+-------+-----------+
| object_id | instance_id | name1 | name2 | is_active |
+-----------+-------------+------------------+-------+-----------+
| 3307 | 0 | XXXXXXXXXX_ILO | ping | 0 |
| 5365 | 3 | check_icmp | NULL | 0 |
| 5366 | 3 | AAAAAA-CCC01 | NULL | 0 |
| 5367 | 3 | 24x7 | NULL | 0 |
| 5368 | 3 | AAAAAA-BBBBBA | NULL | 0 |
| 5369 | 3 | AAAAAA-BBBBBB | NULL | 0 |
| 5370 | 3 | AAAAAA-AAA | NULL | 0 |
| 5371 | 3 | AAAAAA-SAVE | NULL | 0 |
| 5372 | 3 | AAAAAA-SGBD01 | NULL | 0 |
| 5373 | 3 | AAAAAA-VMOTION01 | NULL | 0 |
+-----------+-------------+------------------+-------+-----------+
10 rows in set (0.01 sec)
select service_id,host_object_id,instance_id,display_name
from nagios_services
where instance_id != 1 limit 10;
+------------+----------------+-------------+------------------+
| service_id | host_object_id | instance_id | display_name |
+------------+----------------+-------------+------------------+
| 213526 | 4686 | 2 | BasculeClusterHA |
| 213527 | 4686 | 2 | ping |
| 213528 | 4687 | 2 | BasculeClusterHA |
| 213529 | 4687 | 2 | ping |
| 213530 | 4688 | 2 | ping |
| 213678 | 4669 | 2 | /appli |
| 213531 | 4689 | 2 | ping |
| 213532 | 4700 | 2 | ping |
| 213533 | 4703 | 2 | ping |
| 213534 | 4704 | 2 | ping |
+------------+----------------+-------------+------------------+
10 rows in set (0.00 sec)
select nagios_hosts.display_name,nagios_services.display_name,nagios_services.instance_id
from nagios_hosts,nagios_objects,nagios_services
where nagios_hosts.host_object_id = nagios_objects.object_id
and nagios_services.host_object_id = nagios_objects.object_id
and nagios_services.host_object_id in
(select host_object_id from nagios_hosts where instance_id = 3) limit 10;
+-----------------+-------------------------------+-------------+
| display_name | display_name | instance_id |
+-----------------+-------------------------------+-------------+
| SRV | BasculeClusterHA | 3 |
| SRV | check_http_aaaa | 3 |
| SRV | check_mountpoint_cifs_log | 3 |
| SRV | check_mountpoint_cifs_spl | 3 |
| SRV | ping_lan | 3 |
| SRV2 | BasculeClusterHA | 3 |
| SRV2 | ping_lan | 3 |
| SRV3 | BasculeClusterHA | 3 |
| SRV3 | ping_lan | 3 |
| ILO | ping_lan | 3 |
+-----------------+-------------------------------+-------------+
10 rows in set (0.01 sec)

[Aparté]Je pense qu’il faut que je trouve un module WordPress pour pseudonymiser les données automatiquement, je me fatiguerais moins à changer le nom des serveurs…[/Aparté]

Comme vous pouvez le constater, il y en a partout : c’est terrible !

DELETE FROM nagios_hosts WHERE instance_id =3;
DELETE FROM nagios_services WHERE instance_id =3;
DELETE FROM nagios_hostgroups WHERE instance_id =3;
DELETE FROM nagios_servicegroups WHERE instance_id =3;
DELETE FROM nagios_objects WHERE instance_id =3;

[Tutoriel] Shinken 2.4 sur CentOS/RHEL 7 – partie 3

Tue, 22 Sep 2015 16:32:00 +0000

Cet article fait parti d’une série d’articles (au moins 3) que je vais publier sur le sujet et que j’ai séparé pour les rendre un peu plus digestes. Je vous conseille quand même de ne pas en sauter pour bien comprendre de quoi on parle ;-) :

Les modules

L’ensemble des modules et en particulier le broker n’a donc aucun module d’activé. Or les interfaces graphiques sont gérées par des modules du broker pour ne citer qu’eux.

Les modules et shinken.io

Par convention (ce n’était pas forcément le cas dans les précédentes versions), la configuration des modules est définie dans des fichiers de configurations individuels qui seront stockés dans le sous dossier modules de /etc/shinken/.

On peut trouver les fichiers liés aux modules dans le répertoire /var/lib/shinken/modules/ (par défaut, mais vous pouvez le modifier dans le fichier shinken.cfg ou dans les « .ini » des démons).

cat /etc/shinken/modules/sample.cfg
# Here is a sample module that will do nothing :)
#define module{
# module_name module-sample
# module_type module-sample
# key1 value1
# key2 value2
ll /var/lib/shinken/modules
total 24
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_arbiter
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_broker
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_broker_external
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_poller
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_scheduler
-rw-r--r-- 1 shinkn shinkn 919 17 sept. 14:34 __init__.py

Autant dire que pour l’instant on ne peut pas faire grand chose !

C’est un choix technique qui a été fait à partir de la version 2 (si je ne m’abuse) et qui permet de n’avoir que ce dont on a vraiment besoin, ce qui est une très bonne pratique.

Pour autant, pour éviter de trop alourdir le processus d’installation de multiples modules, l’équipe a mis au point un catalogue d’extensions qui permet d’installer les modules manquants à l’aide d’une simple ligne de commande, ce qui est très pratique.

La première fois, il faut commencer par « initialise » notre Shinken 2.4, avec la commande suivante :

shinken --init

Le site shinken.io référence à date pas moins de 138 packages dont les fameux modules qui nous manquent.

Premier module : les logs comme nagios.log

Pour installer le module de log plat à la mode « Nagios », il faut installer simple-log.

shinken install simple-log
Grabbing : simple-log
OK simple-log

Pas mal hein?

Si vous avez l’erreur suivante qui apparaît, c’est que vous n’avez pas fait la commande shinken init à l’étape précédente.

shinken install simple-log
[1442761511] ERROR: [Shnken] Cannot load cli commands, missing paths or cli entry in the config
[1442761511] ERROR: [Shnken] CLI loading not done: missing configuration data. Please run --init
shinken --init
Creating ini section paths
Creating ini section shinken.io
Saving the new configuration file /root/.shnken.ini

Installer la WebUI, l’interface graphique officielle du projet

Pour installer l’interface graphique « officielle » (aka la WebUI), il faut se rendre sur la page suivante (et la documentation qui détaille sont installation sont disponibles ici).

Toutes les dépendances python peuvent être installées via pip et le fichier requirements.txt. Pour mongodb, je vous l’ai déjà fait installer un peu plus tôt donc ça devrait déjà être fait (enfin… si vous avez suivi… sinon :-p retournez à l’article précédent).

pip install -r https://raw.githubusercontent.com/shinken-monitoring/mod-webui/develop/requirements.txt
shinken install webui2
Grabbing : webui2
OK webui2

Par défaut, le fichier de configuration webui2.cfg est créé dans le dossier /etc/shinken/modules/ et les fichiers du modules ont été déposés dans /var/lib/shinken/modules/.

Pour que notre authentification par fichier htpasswd soit prise en compte, il faut dé-commenter la ligne contenant le paramètre htpasswd_file.

[Deprecated]Vous devriez aussi changer tout de suite le paramètre auth_secret dans le fichier de configuration webui2.cfg. Remplacez CHANGEME par la valeur que vous voulez.

Historiquement il fallait changer soit même le paramètre auth_secret dans le fichier de configuration mais cette option a été remplacée par un fichier autogénéré. Cette méthode est plus sécurisante car elle évite d’oublier de le faire ;-).

htpasswd_file /etc/shinken/htpasswd.users
[...]
# Authentication secret for session cookie
#auth_secret BOBLEPONGE
# ; CHANGE THIS or someone could forge cookies
auth_secret_file /var/lib/shinken/auth_secret
[...]

Pour l’instant, seule l’authentification par Apache htpasswd est activé (vu qu’on vient de le décommenter). On pourra en rajouter d’autres par la suite mais pour faire simple, on va juste y ajouter un compte pour commencer.

htpasswd -c /etc/shinken/htpasswd.users admin

Ensuite on démarre la base mongodb

systemctl enable mongod
systemctl start mongod

Câbler le tout

On a installé deux modules, mais aucun des deux n’ont été reliés au broker : ils ne seront pas utilisés au démarrage. On modifie donc la configuration du broker en conséquence.

vi /etc/shinken/brokers/broker-master.cfg
modules simple-log,webui2

Pour plus de détails sur la configuration du broker, je vous renvoie vers la page broker de la documentation officielle.

Redémarrez l’outil pour prendre en compte la modification de configuration et connectez vous à l’URL http://@IP_shinken:7767

systemctl restart shinken

Yata !

Le dashboard. Mais pour l’instant il n’y a pas grand chose !

En cas de problèmes

Par défaut, les logs sont stockés dans le répertoire /var/log/shinken/, avec un fichier par démon.

Ils sont généralement assez détaillés et on peut moduler le niveau de détails dans les fichiers de configuration des démons que j’ai présenté un peu plus tôt.

Dans le cas où la configuration (shinken.cfg et tous les autres .cfg qui en découlent) contiendrait une erreur, l’arbiter plantera au démarrage et les informations sur son plantage seront contenues dans le fichier /tmp/bad_start_for_arbiter. Ça peut être utile.

Aller plus loin

Ça y est. Votre nouvel outil de supervision fonctionne et vous disposez d’une interface graphique pour voir ce qu’il s’y passe.

Voici quelques pistes pour réellement terminer le travail que vous venez de commencer :

D’abord vous pourriez commencer par ajouter des plugins et quelques serveurs à votre configuration pour voir comment Shinken réagit quand on lui donne un peu de travail. Et pourquoi ne pas vous économiser du travail de configuration en utilisant les packs, dans ce but ultime d’automatiser toujours plus (pour travailler moins) ?
Ensuite, vous pourriez ajouter des modules à la WebUI, comme par exemple ui-graphite ou ui-pnp pour ajouter la gestion des graphes dans votre WebUI.
Enfin, vous pourriez vous pencher sur les aspects de haute disponibilité, de répartition de charge et de gestion des royaumes, histoire de répondre à des problématiques plus complexe ?

[Tutoriel] Shinken 2.4 sur CentOS/RHEL 7 – partie 2

Tue, 22 Sep 2015 16:31:03 +0000

Tutoriel pas à pas pour installer Shinken 2.4 - partie 2

Cet article fait parti d’une série d’articles (au moins 3) que je vais publier sur Shinken 2.4 et que j’ai séparé pour les rendre un peu plus digestes. Je vous conseille quand même de ne pas en sauter pour bien comprendre de quoi on parle ;-) :

Installation

Vous savez maintenant c’est conçu, on peut se lancer dans le bain !

En réalité, c’est un peu plus compliqué que cela ;-). D’autant plus que le logiciel a subit plusieurs modifications de philosophie et de fonctionnement au fil du temps et que la page de documentation 10 Minutes Shinken Installation Guide n’est malheureusement plus à jour et parfois même incomplète.

Prérequis et installation via pip

D’abord, il va falloir installer quelques prérequis si vous voulez pouvoir installer Shinken sur un serveur CentOS 7 « Desktop ». On les retrouve dans le 10 minutes Shinken installation Guide cité plus haut.

La méthode la plus simple consiste à utiliser pip qui récupère les sources directement depuis pypi.python.org et les installe tout seul c’est donc celle là que je vais présenter. Pour CentOS 7, pip est contenu dans le package python-pip, lui même disponible via le dépôt EPEL Release.

[New]Si comme moi vous en avez marre d’installer des Desktop pou rien ca rvous n’utilisez pas la partie graphique, il faut ajouter le package redhat-lsb en Minimal, prérequis aux scripts de démarrage de Shinken

yum install epel-release
#ou rpm -iUvh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
yum update
yum install python-pip
yum install redhat-lsb

A partir de là, on peut reprendre les commandes citées sur la page principale du site.

adduser shinken
pip install shinken

Auquel on nous conseille (sans trop nous le dire) d’ajouter

pip install cherrypy
yum install nagios-plugins

Et enfin quelques derniers prérequis pas du tout cités et qui seront utiles pour la suite :

yum install python-crypto #necessaire pour installer les modules via "shinken install"
yum install mongodb mongodb-server #necessaire pour plusieurs modules dont la WebUI
yum install httpd-tools #utile pour une authentification simple et rapide de la WebUI

Si vous êtes derrière un proxy (moi j’ai besoin de ntlmaps ou cntlm pour sortir sur Internet), n’oubliez pas de le positionner dans la variable https_proxy (notez le S de https).

export https_proxy=http://localhost:8080/

pip devrait maintenant se charger de tout récupérer sur Internet pour vous.

Collecting shinken
Downloading Shinken-2.4.tar.gz (26.7MB)
65% |##################### | 17.5MB 106kB/s eta 0:01:27

Votre machine dispose maintenant du cœur de Shinken installé. C’était rapide, mais ne criez pas victoire trop vite.

Il faut maintenant configurer les démons et ajouter les modules.

Configuration de base

Le cœur de la configuration se situe dans le fichier /etc/shinken/shinken.cfg.

C’est dans ce fichier que vous allez définir les paramètres globaux et les fichiers de configuration complémentaires à parcourir de la même façon que vous l’auriez fait avec nagios.cfg.

Les démons

J’en parlais dans les articles précédents, l’architecture de Shinken diffère de celle de Nagios du fait que Shinken fonctionne avec des démons, chaque démons ayant un rôle particulier.

L’installation de base créé un fichier de configuration pour chaque type de démon dans son propre répertoire :

ll /etc/shinken/arbiters/
total 4
-rw-r--r--. 1 shinken shinken 2744 19 sept. 19:54 arbiter-master.cfg

A ne pas confondre : vous pourriez être surpris par la présence de fichiers [demon]d.ini dans le répertoire daemons/. Ces fichiers servent plutôt à la modification des paramètres « systèmes » des démons, comme le user+group, mais pas à l’ajout de modules ou à la définition de paramètres interne à Shinken, comme le fait que le démon soit un spare ou pas, affecté à un realm, etc.

ll /etc/shinken/daemons
-rw-r--r-- 1 shnkn shnkn 1231 17 sept. 14:34 brokerd.ini
-rw-r--r-- 1 shnkn shnkn 1223 17 sept. 14:34 pollerd.ini
-rw-r--r-- 1 shnkn shnkn 862 17 sept. 14:34 reactionnerd.ini
-rw-r--r-- 1 shnkn shnkn 856 17 sept. 14:34 receiverd.ini
-rw-r--r-- 1 shnkn shnkn 983 17 sept. 14:34 schedulerd.ini

Démarrage automatique

On s’arrange pour qu’ils démarrent tous au démarrage. La documentation propose la boucle suivante pour ajouter tous les démons dans le démarrage pour un OS qui utilise systemd et plus System V (Debian/Ubuntu/RHEL/CentOS dans leurs dernières versions pour ne citer qu’eux).

for i in arbiter poller reactionner scheduler broker receiver; do
systemctl enable shinken-$i.service;
done

Cela étant dit, j’ai plutôt utilisé le service shinken qui « chapeaute » le tout et qui suffit dans le cas d’une architecture standard (sans haute disponibilité et répartition de charge) comme celle que nous sommes en train d’installer. A votre convenance.

systemctl enable shinken

Quelque soit la méthode, un CentOS/RHEL 7 devrait vous renvoyer l’erreur suivante :

shinken.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig shinken on
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).

Il est probable que le script n’ait pas encore totalement été modifié pour fonctionner avec systemd (pour des raisons de compatibilité peut être ?). Ça mériterait un petit ticket sur github pour voir avec les core devs…

A ce stade, c’est « fonctionnel » dans le sens ou on peut lancer le démon principal et qu’on se rendra compte que tout « fonctionne ».

systemctl start shinken
systemctl status shinken
shinken.service - LSB: Shinken monitoring daemon
Loaded: loaded (/etc/rc.d/init.d/shinken)
Active: active (running) since dim. 2015-09-20 16:34:12 CEST; 7s ago
[...]

Pour autant, je ne suis pas certain que cela vous soit très utile car :

vous n’avez pas encore ajouté vos serveurs à superviser
vous n’avez pas encore d’interface graphique.

Direction l’article suivant pour régler ça !