Contexte

Ce guide vous permettra d'installer Shinken Entreprise sur un serveur Linux.

Une fois le guide d'installation suivi, vous aurez rapidement accès aux interfaces de Configuration et de Visualisation de Shinken dans une architecture par défaut, c'est-à-dire un seul serveur sur lequel tous les démons seront activés.

Si votre serveur fait partie d'une architecture distribuée, il faudra configurer vos démons ( noms et IP des serveurs, royaume, spare, tag de Pollers, rétention... ).

En ce qui concerne la procédure de mise à jour, le script "update.sh" vous permettra de mettre à jour votre installation de Shinken de manière complète, même si tous les démons ne sont pas activés.

La configuration de votre installation Shinken ne sera pas modifiée sur une mise à jour.

Historique de l'installeur

Concernant l'installeur à utiliser, il faut prendre le dernier en date.

02.08.01.

13

Voici l'historique des installeurs de la version 02.08.01.12 13 :

02.08.01.

09

Voici l'historique des installeurs de la version 02.08.01.11 09 :

02.08.01.10

Voici l'historique des installeurs de la version 02.08.01.10 :

02.08.01.

08

Voici l'historique des installeurs de la version 02.08.01.09 08 :

02.08.01.

07

Voici l'historique des installeurs de la version 02.08.01.08 07 :

02.08.01.

06

Voici l'historique des installeurs de la version 02.08.01.07 06 :

02.08.01.

05

Voici l'historique des installeurs de la version 02.08.01.06 05 : 

02.08.01.

04

Voici l'historique des installeurs de la version 02.08.01.05 04 : 

02.08.01.

03

Voici l'historique des installeurs de la version 02.08.01.04 03 :

02.08.01.

02

Voici l'historique des installeurs de la version 02.08.01.03 02 :

02.08.01.

01

Voici l'historique des installeurs de la version 02.08.01.02 01 :

02.08.01.01

02.08.01

Voici l'historique des installeurs de la version 02.08Voici l'historique des installeurs de la version 02.08.01.01 :

02.08.01

Voici l'historique des installeurs de la version 02.08.01 :

Installation de Shinken Entreprise

Prérequis

Concernant l'OS

Environnement requis : 

• Centos : 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9
• RHEL   : 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8.5, 8.6, 8.7, 8.8, 8.9, 8.10
• AlmaLinux : 8.5, 8.6, 8.7, 8.8, 8.9, 8.10

Shinken Entreprise a choisiles distributions suivantes : 

• RHEL ( Red Hat Enterprise Linux  ) est la distribution référente dans l'écosystème professionnel Linux
• CentOS ( Community  enterprise  Operating  System ) est une distribution dont tous ses paquets, à l'exception du logo, sont des paquets compilés à partir des sources de la distribution RHEL ( Red Hat Enterprise Linux  )
  • Elle est donc quasiment identique à celle-ci et se veut 100 % compatible d'un point de vue binaire
    
• AlmaLinux et RockyLinux  sont deux successeurs de CentOS, la version CentOS 8 ayant été arrêtée.

Ces distributions Linux, principalement destinées aux serveurs, sont stables, performantes et compatibles avec une très grande majorité des environnements professionnels.

Concernant le support de ces distributions :

Information sur le cycle de vie des versions RedHat / Alma / Rocky

Pour RedHat

Les sous-versions impaire ( Exemple : 8.3, 8.5, 8.7, 8.9 ) ont un support que de 6 mois. Nous conseillons donc d'utilisé que les sous-version paire ( Exemple : 8.4, 8.6, 8.8, 8.10 ) ( voir la page https://access.redhat.com/support/policy/updates/errata ).

Pour AlmaLinux / RockyLinux

La sortie d'une nouvelle sous-version met fin au support de la sous-version précédente ( voir pour AlmaLinux https://wiki.almalinux.org/release-notes/ et pour RockyLinux https://wiki.rockylinux.org/rocky/version/ )

Concernant la transformation de la CentOS en CentOS Stream ( Beta de la Redhat )

Redhat a changé sa politique concernant la Centos, qui devient maintenant une version Béta à la RHEL.
Là où précédemment, elle était une recompilation à l'identique d'une RHEL, elle est désormais une distribution sans version fixe ( dite "rolling release" ) en amont de RHEL :

• qui sert à RedHat afin de tester des nouvelles versions de paquets, avant leur sélection si les tests sont fonctionnels dans la RHEL.
• Elle récupère ainsi le rôle qu'avait la Fedora avant elle.
• Elle ne nous semble donc pas viable pour une utilisation professionnelle en production.

Depuis la version V02.08.01.02 Shinken prend en charge l'installation sur les distributions AlmaLinux.
Depuis la version V02.08.02-RC015 Shinken prend en charge l'installation sur les distributions RockyLinux.
Ce sont deux remplaçants possibles de CentOS.

Transformer une CentOS en Redhat

Nous ne recommandons pas de convertir une CentOS en RedHat, mais de procéder à l'installation d'un nouveau serveur et migrer les données entre les deux serveurs Shinken.  

Si vous désirez quand même réaliser cette opération, vous pouvez consulter la page : ( PROCEDURE ) Passer de Centos 7.9 à RedHat 7.9.

Concernant la Redhat

Prérequis CPU

Chaque démon utilise un ou plusieurs processus  ( multithreading ) :

• Synchronizer
  • 1 Pour l'interface de Configuration
  • 1 Pour le démon
• Broker
  • 1 Par l'interface deVisualisation
  • 1 Pour le démon
• Arbiter ( 1 Pour le démon )
• Receiver ( 1 Pour le démon )
• Reactionner( 1 Pour le démon )
• Scheduler ( 1 Pour le démon )
• Poller ( 1 Pour le démon )

Extraction du package et installation

Installation automatique :

Il faut être loggué en tant que root,

$id
uid=0(root) gid=0(root)

Et que le umask du compte root soit à 0022

$umask 0022

« Décompresser » le package qui vous a été transmis :

• tar zxvf shinken-enterprise_V02.08.XX-LANGUAGE.tar.gz
• Cela vous créera un répertoire shinken-entreprise contenant le script d’installation et les dépendances nécessaires à l’installation.
  
  

Déplacez-vous à la base du répertoire shinken-entreprise  ( cd shinken-enterprise_V02.08.XX-LANGUAGE )  et exécutez le script :

./install.sh

Il installera Shinken Entreprise et ses composants automatiquement.

• Le SDK VMWare nécessaire aux checks est maintenant installé automatiquement (  nécessitait une installation manuelle dans les versions précédentes ) .
• Pour obtenir plus d'informations sur la consommation des démons et améliorer le fonctionnement de Shinken lorsqu'il est installé sur une machine virtuelle VMWare, le paquet "open-vm-tools" doit être installé manuellement :
  
  

yum install open-vm-tools

Vérification du bon fonctionnement

Vérification : 

Pour vérifier que Shinken Entreprise est bien installé, configuré et fonctionnel, lancez la commande :

shinken-healthcheck

Votre licence Shinken Enterprise n'est pas installée, c'est normal, dirigez-vous dans la section Clé de licence plus bas sur cette page afin d'installer votre clé.

Accès aux interfaces web

Interface Utilisateur ( UI ) de configuration 

Une fois Shinken Enterprise installé, pour accéder à l'UI de configuration, vous devez pointer votre navigateur Web vers l'adresse affichée durant l'installation.

• Par défaut, l'interface de configuration est accessible sur le port dédié 7766 ( via le protocole HTTP ). Par exemple : http://192.168.0.1:7766
  
  

( voir la page Paramétrage de l'interface de Configuration )

Interface Utilisateur ( UI ) de visualisation

Une fois Shinken Enterprise installé, pour accéder à l'UI de visualisation, vous devez pointer votre navigateur Web vers l'adresse affichée durant l'installation.

• Par défaut, l'interface de configuration est accessible sur le port dédié 7767 ( via le protocole HTTP ). Par exemple : http://192.168.0.1:7767
  
  

( voir la page Paramétrage de l'interface de Visualisation )

Documentation dans le package

La documentation ( en français ) est maintenant intégré au package d'installation.

1. Vous pouvez le retrouver à l'intérieur de shinken-enterprise_V02.08.XX-LANGUAGE.tar.gz dans le répertoire /tools/documentation/
2. La première page de la documentation est index.html qui peut être ouvert avec un navigateur internet.

Installation du script dump_performance.sh 

Ce script permet de stocker les informations systèmes de votre serveur Linux en local. Ceux sont des informations très utiles en cas de debug avec le support Shinken.

• Sa mise en place est décrite dans la page dump_performance.sh ( top / ps / cpu / kernel / healthcheck )

Installation ( Mode avancé )

Options disponibles

Installation ( Mode avancé )

Options disponibles

Choisir les démons activés pendant le processus d'installation

Il faut être logué en tant que root,

$id
uid=0(root) gid=0(root)

Et que le umask du compte root soit à 0022

$umask 0022

« Décompresser » le package qui vous a été transmis :

• tar zxvf shinken-enterprise_V02.08.XX-LANGUAGE.tar.gz
• Cela vous créera un répertoire shinken-entreprise contenant le script d’installation et les dépendances nécessaires à l’installation.
  
  

Déplacez-vous dans le répertoire  (cd shinken-enterprise_V02.08.XX- LANGUAGE)  et lancez la commande ./ install.sh  mais avec des options basées sur les démons que vous souhaitez activer :

• --pollernode : active le démon Poller ( dédié au lancement des checks ),
• --reactionnernode : active le démon Reactionner ( dédié au lancement des notifications ),
• --schedulernode : active le démon Scheduler ( planificateur des checks ),
• --arbiternode : active le démon Arbiter ( rôle de distribution centrale ),
• --receivernode : active le démon Receiver ( reçois les checks passifs ),
• --synchronizernode : active le démon Synchronizer ( gère la configuration ),
• --brokernode : active le démon Broker ( export des données ).

./install.sh --schedulernode --pollernode

Pour vérifier que les démons sélectionnés de Shinken Entreprise sont bien mis à jour, configurés et fonctionnels, lancez la commande :

shinken-healthcheck

Shinken-healthcheck vérifiera alors que Shinken Entreprise est bien configuré et en cours d'exécution ( seulement pour les démons installés )

• Après l'installation initiale, si vous souhaitez activer/désactiver des démons, utilisez la commande d'activation détaillée dans le chapitre Lister/Activer/Désactiver des démons .
• Lors d'une mise à jour, le script update.sh prend en compte les démons qui sont activés ou non.
  

Les différents addons sont automatiquement activés lors de l'installation :

• nagvis-shinken-architecture: Activé lors d'une installation d'un Arbiter ( plus de détails dans la page de documentation dédiée :  Configuration de la Visualisation de l'architecture )
• nagvis: Activé lors d'une installation d'un Broker ( plus de détails dans la page de documentation dédiée :  NagVis ( Addon ) )

Mise en place du chiffrement

Vous pouvez mettre en place le chiffrement de façon automatique au moment de l'installation ( voir la page Protection des données sensibles de l'UI de Configuration ).

Une clé de chiffrement sera alors générée lors du processus d'installation et la base de données du Synchronizer sera chiffrée.

Pour cela, lancez la commande suivante :

./install.sh --activate-encryption <nom de clé>  --disable-important-notices-user-input

• --activate-encryption permet d'activer le chiffrement. Le nom de la clé est optionnel toutefois il vous sera demandé lors de l'exécution du programme d'installation si vous ne le précisez pas.

Shinken-healthcheck vous permettra de vérifier la bonne configuration des démons et du chiffrement.

Passer les demandes de saisies lors de l'installation

Si vous voulez automatiser l'installation de Shinken, via un script Ansible par exemple, vous allez avoir besoin de désactiver les demandes de saisies lors de l'installation de Shinken.

Nous vous conseillons fortement de faire au moins une installation manuelle afin de lire les informations fournies lors de l'installation avant d'automatiser l'installation. 

• --disable-important-notices-user-input permet de désactiver les prompts vous demandant confirmation avant de continuer le processus.
   Il vous est cependant fortement conseillé de lire les informations fournies lors de l'installation.

Mise en place d'un serveur sans connexion internet

Dans le cas d'un serveur qui n'a pas de connexion internet, il faut lancer l'installeur avec le paramètre suivant :

• --disable-add-public-epel : permet de ne pas installer le repository epel sur le serveur

•  --disable-epel ( DEPRECATED ): ancien nom du paramètre, sera supprimé dans le futur

Faire l'installation sur un serveur avec des repository internes ( non publics ) fixés sur une version précise

Dans le cas d'un serveur qui n'a accès qu'à des "repository" internes qui ne sont pas forcément synchronisés sur les dernières versions des "repository" centos/redhat officiel, le comportement de base de l'installeur et le script d'update sont de mettre à jour tous les packages si une mise à jour est possible. Ceci peut entrainer des problèmes si l'installeur a une mise à jour à faire trop récente par rapport à ce qu'il a de disponible dans ses "repository".
Dans ce cas, il faut lancer avec l'option qui demande à ne pas mettre à jour les paquets s'ils sont déjà installés :

• --package-update-only-on-conflict : permet de ne pas chercher à mettre à jour les paquets déjà installés et ainsi tente d'éviter d'installer des paquets trop à jour par rapport au "repository" interne qui n'est pas à jour.

Faire l'installation sur un serveur RedHat non enregistré sur les repository RedHat

Si un serveur RedHat a un accès uniquement à des "repository" locaux, il ne sera pas enregistré directement chez RedHat. La vérification de l'installeur et du script d'update sur les RedHat se base sur la vérification de cette connexion afin de déterminer si le serveur a bien accès aux "repository". Ici cette vérification va bloquer l'installation alors que le serveur a bien accès à des "repository" locaux. Il faut alors utiliser l'option suivante :

• --skip-redhat-subscription-check: permet de ne pas lancer la vérification de la souscription du serveur auprès de RedHat ( qui doit avoir tout de même accès à des repository locaux ).

Faire l'installation sur une machine n'ayant même pas accès à des repository redhat/centos/epel

Dans des cas bien précis, un serveur Shinken peut ne pas avoir accès à des repository redhat/centos/epel. Il est important de noter qu'une connexion internet n'est pas nécessaire, juste l'accès à des repository locaux est totalement suffisant.

Si même l'accès à des repository locaux n'est pas possible, l'installation peut échouer même avec l'usage des options --disable-add-public-epel et --package-update-only-on-conflict, car il peut avoir besoin d'installer des nouveaux paquets dont les dépendances ne seront pas disponibles.

Il est cependant possible de contourner le problème en installant manuellement ces dépendances.

Une fois une installation bloquée sur le serveur, vous allez avoir la liste des paquets manquants, par exemple :

-> Running transaction check
--> Package at.x86_64 0:3.1.13-20.el7 will be installed
--> Package audit-libs-python.x86_64 0:2.4.1-5.el7 will be installed
-> Processing Dependency: audit-libs = 2.4.1-5.el7 for package: audit-libs-python-2.4.1-5.el7.x86_64

Dans notre cas, il manque les dépendances at et audit-libs-python pour le paquet installé audit-libs. Il faut donc récupérer leurs rpm, ainsi que ceux de leurs dépendances :

• Depuis un serveur ayant un accès aux repository ( publiques ou internes ).
• Il ne faut pas que ce serveur ait déjà d'installé les paquets recherchés :
  • idéalement, un serveur minimal sans Shinken d'installé dessus donc, sur ce serveur, il faut installer une extension à yum qui va permettre de juste télécharger les dépendances :
    
    

yum install yum-plugin-downloadonly

Puis nous demandons :

• les deux paquets que nous recherchons
• plus le paquet déjà installé ( audit-libs ), au cas où une mise à jour serait disponible.
  
  

Ils seront téléchargés localement :

yum install -y --downloadonly --downloaddir=.  at audit-libs-python audit-libs

Dans notre cas, ceci télécharge deux paquets ( ils n'avaient pas de dépendances et le paquet audit-libs était déjà à jour ), at-3.1.13-24.el7.x86_64.rpm et audit-libs-python-2.8.5-4.el7.x86_64.rpm.

Il faut alors les envoyer sur le serveur qui n'a pas de repository et les installer localement :

rpm -Uvh at-3.1.13-24.el7.x86_64.rpm audit-libs-python-2.8.5-4.el7.x86_64.rpm

Il faut ensuite relancer l'installation, et recommencer l'opération si de nouveaux paquets manquants sont détectés.

Faire l'installation sur un serveur qui n'a accès à aucun repository (ni interne, ni public)

Dans le cas d'un serveur qui est totalement isolé du moindre "repository", il faudra passer par plusieurs tentatives d'installations afin d'avoir à chaque fois les erreurs "yum" qui donnent la liste des paquets manquants.

Le principe général sera :

• récupérer la liste des paquets manquants ou pas dans la bonne version depuis l'erreur de l'installeur
• depuis un serveur qui lui a accès à un repository, récupérer les paquets rpm manquants
• transférer les paquets rpm sur le serveur Shinken à installer
• installer les paquets rpm
• relancer l'installation, et en cas de problèmes de nouveaux paquets manquants, recommencer la procédure jusqu'à ce que l'installation finisse correctement

Dans le cas où l'installeur sorte l'erreur :

error: Failed dependencies:
  audit-libs = 2.4.1-5.el7 is needed by audit-libs-python-2.4.1-5.el7.x86_64
  libavahi-client.so.3()(64bit) is needed by cups-client-1:1.6.3-22.el7.x86_64

Alors il faut lancer sur un serveur ayant accès aux repository ( centos/redhat et epel ):

yum install yum-plugin-downloadonly
yum install -y --downloadonly --downloaddir=.  audit-libs-python  cups-client

Ceci va télécharger localement plusieurs fichiers rpm qu'il faut transférer sur le futur serveur Shinken et lancer une simulation de l'installation des paquets:

rpm -Uvh --test *rpm

Si la commande ne retourne pas d'erreur, lancer l'installation des paquets rpm:

rpm -Uvh *rpm

Il faut alors relancer l'installation de Shinken qui devrait arriver à une étape suivante, et recommencer si certains paquets manquent encore.

Permettre d'exclure l'installation ou la mise à jour de certaines dépendances de sondes

L'installeur permet de refuser l'installation ou la mise à jour de certaines dépendances de sondes que l'administrateur ne souhaite pas installer, comme par exemple les paquets sqlplus d'Oracle.

Les options disponibles sont :

• --packs-to-install : permet de ne sélectionner que les dépendances listées.
• --packs-to-exclude : permet de ne pas installer les dépendances listées.

Les "packs" disponibles pour ces options sont :

• oracle : les dépendances des sondes oracle, notamment le paquet sqlplus fournis par Oracle.
• mssql : les dépendances pour les sondes Mssql/Sqlserver.
• nagios-checks : les sondes Nagios et leurs dépendances.
• bacula : le check de vérification de l'outil de backup Bacula, avec ses dépendances systèmes.
  • À exclure si vous utilisez une version de bacula issue du site www.bacula.org, car ce dernier fourni des dépendances incompatibles.

L'administrateur peut choisir d'utiliser une ou l'autre des options :

--packs-to-install : nagios-checks,mssql

installera uniquement les dépendances ( fichiers rpm ) des packs nagios-checks et mssql, donc pas les paquets pour oracle par exemple

--packs-to-exclude: oracle,nagios-checks

exclura les dépendances ( fichiers rpm ) des packs oracle et nagios-checks

Exclure l'installation de Nagvis

L'installeur vous offre la possibilité de refuser l'installation ou la mise à jour de Nagvis.

Nagvis est installé par défaut avec Shinken et est nécessaire au fonctionnement de deux addons 

• nagvis ( voir la page NagVis ( Addon ) )
• nagvis-shinken-architecture  ( voir la page Configuration de la Visualisation de l'architecture )

Ces deux addons sont utilisés exclusivement par le Broker et l'Arbiter.

Si vous installez un autre démon ou si ces addons ne sont pas nécessaires, vous pouvez choisir de ne pas installer Nagvis en utilisant l'option --skip-nagvis.

Clé de licence Shinken Enterprise

Le service Commercial de Shinken Enterprise a dû vous envoyer une licence nominative vous permettant d'utiliser pleinement le produit.

La licence est un fichier qui a le nom suivant : user.key et cette licence est nominative et limitée dans le temps.

Pour l'installer, rien de plus simple, il suffit de :

• Placer ce fichier sur le serveur hébergeant l'Arbiter et sur les serveurs hébergeant le ou les UIs de Visualisation , dans le chemin suivant : /etc/shinken/user.key
• Redémarrez alors Shinken Enterprise via la commande : service shinken restart

Relancez alors la commande shinken-healthcheck le message d'erreur de licence doit avoir disparu et voici un exemple d'information de licence valide :

Si vous n'avez pas de clé de licence ou que celle-ci a expiré, contactez-nous : contact@shinken-solutions.com

Résolution des problèmes liés à l'installation

Les logs de l'installation

Pour chaque installation/mise à jour, un dossier est créé dans ~/shinken/versions_and_patch_installations/  et nommé de la manière suivante :

• Pour les mises à jour :

YYYY-MM-DD-HHhMMmSS-install-VXX.XX.XX

Ce dossier contient les données suivantes :

• Affichage du script d'installation ( installation seulement ): shinken.enterprise.install.log
• Détails d'installation des paquets : shinken.enterprise.install.detail.log
• Nettoyage de la configuration : sanatize.update.log
• Affichage du script de mise à jour ( mise à jour seulement ) : shinken.enterprise.update.log
• Backup de la configuration et données utilisateur ( mise à jour seulement )
• Log de l'installation des packages via yum: rpm_tmp_install.log