Contexte

Ce guide a pour finalité de permettre l'installation de Shinken Entreprise sur un serveur Linux ( RHEL / Alma / Rocky / Debian ).

• Une fois le guide d'installation suivi, les interfaces de Configuration et de Visualisation de Shinken seront rapidement accessibles dans une architecture par défaut, c'est-à-dire un seul serveur sur lequel tous les démons sont activés.
• Si le serveur fait partie d'une architecture distribuée, il faudra modifier les fichiers de configurations des démons ( noms et IP des serveurs, royaume, spare, tag de Pollers, rétention, ... ).
  
  

Remarque : Concernant la procédure de mise à jour, se référer à la page Mise à jour.

Historique de l'installeur

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

02.08.02

Voici l'historique des installeurs de cette version :

Installation de Shinken Entreprise

Prérequis

Concernant l'OS

Environnement requis : 

• RHEL : 7.2 => 7.9, 8.5 => 8.10
  • Centos : 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9
• Alma : 8.5 => 8.10
• Rocky : 8.9 => 8.10
• Debian : 13

Shinken Entreprise a choisi les 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 les 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.
    
• Alma et Rocky sont deux successeurs de CentOS, la version CentOS 8 ayant été arrêtée.
• Debian est la distribution communautaire de référence dans l'écosystème Linux, elle sert également de base à d'autres distributions. 

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 distributions Linux

RHEL

Les sous-versions impaires ( Exemple : 8.3, 8.5, 8.7, 8.9 ) ont un support de 6 mois seulement.

• Nous conseillons donc de n'utiliser que les sous-versions paires, c'est-à-dire par exemple 8.4, 8.6, 8.8, 8.10 ( voir la page https://access.redhat.com/support/policy/updates/errata ).
  
  

Alma / Rocky

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

Debian

Toutes les versions de la distribution Debian disposent d'un support d'au moins 5 ans.

• Un support commercial est également disponible pour encore allonger ce délai ( voir https://www.debian.org/releases/, https://wiki.debian.org/LTS et https://wiki.debian.org/LTS/Extended ).
  
  

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

Redhat a changé sa politique concernant Centos, qui devient maintenant une version Béta de RHEL.
Là où précédemment, elle était une recompilation à l'identique de 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 RHEL.
• Elle récupère ainsi le rôle qu'avait Fedora avant elle.
• Elle ne nous semble donc pas viable pour une utilisation professionnelle en production.

Depuis la version V02.08.02-RC012 Shinken prend en charge l'installation sur les distributions Alma et depuis la version V02.08.02-RC015 Shinken prend en charge l'installation sur les distributions Rocky.

• Ce sont deux remplaçantes possibles de CentOS.

Transformer une CentOS en RHEL

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

Toutefois, pour réaliser cette opération, des informations sont disponibles sur la page : ( PROCEDURE ) Passer de Centos 7.9 à RedHat 7.9.

Concernant RHEL

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 de Visualisation
  • 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 avec les options d'installation par défaut

Prérequis a l'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

Extraction de l'installeur

Il existe plusieurs installeurs qui dépendent de l'OS sur lequel shinken va être installé :

• Un pour les distributions RHEL 7 et CentOS 7 ;
• Un pour les distributions RHEL 8, Alma 8 et Rocky 8 ;
• Un pour la distribution Debian 13 ;

Chaque binaire est nommé suivant un nom précis :

shinken-enterprise_V02.08.XX-RC0XX.XX_ALL-LANG_Linux-LISTE_DES_DISTRIBUTIONS_FULL_AAAA-MM-JJ.tar.gz

« Décompresser » le package  :

tar zxvf shinken-enterprise_V02.08.XX-RC0XX.XX_ALL-LANG_Linux-LISTE_DES_DISTRIBUTIONS_FULL_AAAA-MM-JJ.tar.gz

Cela créera un répertoire shinken-entreprise contenant le script et les dépendances nécessaires à l’installation.

Se placer à la base du répertoire shinken-entreprise  

cd shinken-enterprise_V02.08.XX-RC0XX.XX_ALL-LANG_Linux-LISTE_DES_DISTRIBUTIONS_FULL_AAAA-MM-JJ

Choix de la langue d'installation

Au moment de lancer l'installation, il est possible de spécifier la langue souhaitée pour les interfaces ( fr ou en ).

Pour ce faire, il existe deux moyens :

• Renseigner la langue souhaitée avec l'argument --lang au moment de lancer l'installation.
• Si l'argument n'est pas renseigné à l'installation, l'installeur demandera la langue souhaitée au début de l'installation.

Lancer l'installation

Exécuter le script :

./install.sh

OU 

./install.sh --lang XX

Il installera Shinken Entreprise et ses composants automatiquement.

VMWare

• Le SDK VMWare nécessaire aux checks est maintenant installé automatiquement (  il 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 :

RHEL / CentOS 7 ou RHEL / Alma / Rocky 8

Debian 13

Vérification du bon fonctionnement

Vérification : 

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

shinken-healthcheck

Pour la mise en place de la licence Shinken Enterprise, voir la section Clé de licence Shinken Enterprise  plus bas sur cette page.

Accès aux interfaces web

Interface Utilisateur ( UI ) de Configuration

Une fois Shinken Entreprise installée, pour accéder à l'UI de configuration, il suffit de saisir l'adresse affichée durant l'installation dans un navigateur Web.

• Par défaut, l'interface de configuration est accessible sur le port 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, il suffit de saisir l'adresse affichée durant l'installation dans un navigateur Web.

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

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

La documentation liée à la version installée

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

• Elle est disponible dans l'archive shinken-enterprise_V02.08.XX-LANGUAGE.tar.gz dans le répertoire tools/documentation/
• La première page de la documentation est index.html qui peut être ouverte avec un navigateur internet.

La documentation de Shinken est aussi accessible sur chaque serveur Shinken via l'URL http(s)://HOTE DE SHINKEN:PORT D'APACHE/shinken-documentation

• Les pages de documentation sont déposées par l'installeur dans /opt/shinken/documentation/.
• Elles sont consultables via un alias du serveur Apache ( shinken-documentation ).

Installation du script dump_performance.sh 

Ce script permet de stocker les informations systèmes du serveur Linux en local.

• Ce sont des informations utiles en cas de debug avec le support Shinken.
• Ce script doit être mis en place par vos soins.
  • Suivez la procédure décrite dans la page  ( voir la page dump_performance.sh ( top / ps / cpu / kernel / healthcheck )). 

Installation ( Mode avancé )

Options disponibles

Choix de la langue

Cette option permet de choisir la langue initiale qui sera utilisée dans les fichiers de configurations des interfaces utilisateurs.

Deux valeurs sont possibles :

• fr : les interfaces seront en français ;
• en : les interfaces seront en anglais ;

Passer les demandes de saisies lors de l'installation

Pour automatiser l'installation de Shinken, via un script Ansible par exemple, il est possible de désactiver les demandes de saisies lors de l'installation de Shinken.

Il est toutefois fortement conseillé de faire au moins une installation sans l'option --disable-important-notices-user-input, afin de lire les informations fournies lors de l'installation, avant de l'automatiser.

Choisir les démons à activer 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 :

tar zxvf shinken-enterprise_V02.08.XX-RC0XX.XX_ALL-LANG_Linux-LISTE_DES_DISTRIBUTIONS_FULL_AAAA-MM-JJ.tar.gz

Cela créera un répertoire shinken-entreprise contenant le script et les dépendances nécessaires à l’installation.

Se placer à la base du répertoire shinken-entreprise  

cd shinken-enterprise_V02.08.XX-RC0XX.XX_ALL-LANG_Linux-LISTE_DES_DISTRIBUTIONS_FULL_AAAA-MM-JJ

et lancer la commande d'installation avec en paramètre les options indiquant les démons à activer :

• --arbiternode : active le démon Arbiter ( distribution de la configuration ),
• --brokernode : active le démon Broker ( export des données ).
• --pollernode : active le démon Poller ( lancement des checks ),
• --reactionnernode : active le démon Reactionner ( lancement des notifications et des gestionnaires d'événements ),
• --receivernode : active le démon Receiver ( réception des checks passifs ),
• --schedulernode : active le démon Scheduler ( planification des checks ),
• --synchronizernode : active le démon Synchronizer ( gestion la configuration ),

./install.sh --schedulernode --pollernode

Pour vérifier que les démons sélectionnés de Shinken Entreprise sont bien installés, configurés et fonctionnels, lancer 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, pour activer/désactiver des démons, utiliser la commande d'activation détaillée ( voir la page Lister/Activer/Désactiver des démons ).
• Lors d'une mise à jour, le script update.sh prendra en compte les démons qui sont activés ou non.
  

Les différents add-ons sont automatiquement activés lors de l'installation :

• nagvis-shinken-architecture : Activé lors d'une installation avec un Arbiter ( voir la page Configuration de la Visualisation de l'architecture )
• nagvis: Activé lors d'une installation avec un Broker ( voir la page NagVis ( Addon ) )

Mise en place du chiffrement

Le chiffrement peut être mis en place automatiquement 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, lancer la commande suivante :

./install.sh --activate-encryption "nom de clé"

La commande shinken-healthcheck permettra de vérifier la bonne configuration des démons et du chiffrement.

Serveur de synchronisation du temps par le réseau

L'installeur va vérifier la présence d'un démon assurant la synchronisation de l'horloge du système avec un ou des référents sur le réseau.

• Si aucun n'est fonctionnel, Chrony est installé.
• Si la synchronisation de l'horloge du système est assurée par un autre moyen, il est possible de désactiver l'installation de Chrony avec l'option --disable-time-server-setup-if-missing.

Mise en place d'un serveur sans connexion internet

Debian 13

L'option --disable-add-public-epel est sans effet sur cette distribution Linux.

• L'installeur va créer automatiquement un dépôt de paquets local pour apt.
  • Ce dernier contiendra toutes les dépendances nécessaires.
  • Il n'y a rien à faire, l'installation peut se dérouler sans aucun autre dépôt apt activé.
  • Ce dépôt de paquets sera supprimé automatiquement à la fin de l'installation. 

RHEL / CentOS 7 ou RHEL / Alma / Rocky 8

EPEL ( Extra Packages for Enterprise Linux ) est un dépôt de paquets public fourni par Redhat, donc sans connexion internet, ce packet est inutile.

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 dépôt epel sur le serveur.

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

Debian 13

L'option --package-update-only-on-conflict est sans effet sur cette distribution Linux.

• L'installeur va créer automatiquement un dépôt de paquets local pour apt.
  • Ce dernier contiendra toutes les dépendances nécessaires.
  • Il n'y a rien à faire, l'installation peut se dérouler sans aucun autre dépôt apt activé.
  • Ce dépôt de paquets sera supprimé automatiquement à la fin de l'installation.

RHEL / CentOS 7 ou RHEL / Alma / Rocky 8

Par défaut, le script d'installation cherche à mettre à jour tous les paquets ( .rpm ) du système pour lesquels il possède une version plus récente.

Dans le cas d'un serveur qui n'a accès qu'à des dépôts de paquets ( "repository" ) internes qui ne sont pas forcément synchronisés sur les dernières versions des dépôts CentOS / RHEL / Alma / Rocky officiels, ceci peut entrainer des problèmes si l'installeur fournit des paquets trop récents par rapport à ce qu'il y a de disponible dans ces dépôts.
Dans ce cas, il faut utiliser l'option qui demande à ne pas mettre à jour les paquets s'ils sont déjà installés :

• --package-update-only-on-conflict : ne pas chercher à mettre à jour les paquets déjà installés. Cela permet d'éviter d'installer des paquets trop récents par rapport à un dépôt interne qui ne serait pas à jour.

Faire l'installation sur un serveur RHEL non enregistré sur les dépôts RedHat

Debian 13 ou CentOS 7 ou Alma / Rocky 8

L'option --skip-redhat-subscription-check est sans effet sur ces distributions Linux.

• En effet, il n'y a pas d'enregistrement à faire chez RedHat pour ces distributions Linux.

RHEL 7 ou RHEL 8

Si un serveur avec la distribution RHEL a un accès uniquement à des dépôts de paquets ( "repository" ) locaux, il ne sera pas enregistré directement chez RedHat.

• Sur les distributions RHEL, l'installeur se base sur la vérification de cet enregistrement afin de déterminer si le serveur a bien accès aux dépôts de paquets.
• Ici cette vérification va bloquer l'installation alors que le serveur a bien accès à des dépôts 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 ( mais il faut avoir tout de même accès à des dépôts locaux ).

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

Debian 13

L'installeur va créer automatiquement un dépôt de paquets local pour apt.

• Ce dernier contiendra toutes les dépendances nécessaires.
• Il n'y a rien à faire, l'installation peut se dérouler sans aucun autre dépôt apt activé.
• Ce dépôt de paquets sera supprimé automatiquement à la fin de l'installation. 

RHEL / CentOS 7 ou RHEL / Alma / Rocky 8

Dans des cas bien précis, un serveur Shinken peut ne pas avoir accès à des dépôts RHEL/centos/epel.

• Il est important de noter qu'une connexion internet n'est pas nécessaire, juste l'accès à des dépôts locaux est totalement suffisant.
• Si même l'accès à des dépôts 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 de 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.

Quand l'installation s'arrête sur une erreur, un message s'affiche avec 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 ce 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 dépôts ( publics ou internes ).
  • ce serveur ne doit pas avoir déjà installé les paquets recherchés :
  • idéalement un serveur avec une installation minimale de la distribution, sans Shinken, 
• installer une extension à yum qui va permettre de télécharger les dépendances :
  
  

yum install yum-plugin-downloadonly

Puis télécharger :

• les deux paquets recherchés ;
• 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 ce 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 dépôt et les installer manuellement :

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)

Debian 13

L'installeur va créer automatiquement un dépôt de paquets local pour apt.

• Ce dernier contiendra toutes les dépendances nécessaires.
• Il n'y a rien à faire, l'installation peut se dérouler sans aucun autre dépôt apt activé.
• Ce dépôt de paquets sera supprimé automatiquement à la fin de l'installation. 

RHEL / CentOS 7 ou RHEL / Alma / Rocky 8

Dans le cas d'un serveur qui est totalement isolé du moindre dépôt de paquets ( "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 dans une mauvaise version, depuis le message d'erreur de l'installeur,
• depuis un serveur qui lui a accès à un dépôt, 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.

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

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, avant de 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 ensuite 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 choisir de ne pas déployer 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 / SQL Server.
• 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.
  • A exclure en cas d'utilisation d'une version de bacula issue du site www.bacula.org, car ce dernier fournit des dépendances incompatibles.

L'administrateur peut choisir d'utiliser l'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 permet de ne pas installer Nagvis.

Nagvis est installé par défaut avec Shinken. Il est nécessaire au fonctionnement de deux add-ons 

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

Ces deux add-ons sont utilisés par le Broker et l'Arbiter.

Pour l'installation d'un autre démon ou si ces add-ons ne sont pas nécessaires, il est possible de choisir de ne pas installer Nagvis avec l'option --skip-nagvis.

Clé de licence Shinken Enterprise

Le service Commercial de Shinken Enterprise délivre des licences nominatives permettant d'utiliser pleinement le produit.

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

Pour l'installer, 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émarrer Shinken Enterprise via la commande :

• 

Enfin, relancer la commande shinken-healthcheck. Le message d'erreur de licence doit avoir disparu. Voici un exemple d'information de licence valide :

En l'absence de clé de licence ou si 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, un dossier est créé dans ~/shinken /versions_and_patch_installations/, nommé de la manière suivante :

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

Ce dossier contient les données suivantes :

• Affichage du script d'installation : shinken.enterprise.install.log
• Détails d'installation des paquets : shinken.enterprise.install.detail.log
• Nettoyage de la configuration : sanatize.update.log
• Log de l'installation des packages via yum: rpm_tmp_install.log