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.13 :

02.08.01.09

Voici l'historique des installeurs de la version 02.08.01.09 :

02.08.01.08

Voici l'historique des installeurs de la version 02.08.01.08 :

02.08.01.07

Voici l'historique des installeurs de la version 02.08.01.07 :

02.08.01.06

Voici l'historique des installeurs de la version 02.08.01.06 :

02.08.01.05

Voici l'historique des installeurs de la version 02.08.01.05 :

02.08.01.04

Voici l'historique des installeurs de la version 02.08.01.04 :

02.08.01.03

Voici l'historique des installeurs de la version 02.08.01.03 :

02.08.01.02

Voici l'historique des installeurs de la version 02.08.01.02 :

02.08.01.01

Voici 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 :

Mise à jour 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

Avec une installation d'une version antérieure de Shinken déjà effectuée.

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 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 un serveur 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

Concernant les versions de Shinken Entreprise

Extraction du package et mise à jour

Mise à jour :

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 de mise à jour et les dépendances nécessaires à la mise à jour.
  
  

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

./update.sh

Ainsi, la mise à jour :

• Mettra à jour Shinken Entreprise mais n'aura aucune incidence sur le dossier de configuration de /etc/shinken , évitant tout risque d’écrasement d'une configuration que vous auriez définie.
• Au lieu d'écraser votre paramétrage, des fichiers "*.cfg.rpmnew" seront ajoutés. De nouvelles propriétés pourront figurer dans ces fichiers, il est donc conseillé de parcourir ces fichiers et si besoin, récupérer ces nouvelles propriétés pour les intégrer dans votre architecture.
• Avant la mise à jour, une sauvegarde est effectuée et placée dans /root/shinken/versions_and_patch_installations/DATE-HEURE-update-NUMERO_VERSION/backup-pre-update/ .
  Elle est nommée de la manière suivante : " DATE__HEURE__NUMERO_VERSION___backup-preupdate-version-NUMERO_VERSION ".
  
  • Si un Synchronizer est actif sur la machine, alors la configuration est sauvegardée,
  • et/ou si un Broker est actif sur la machine, alors les données utilisateurs sont sauvegardées.

Documentation dans le package

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

• Vous pouvez le retrouver à l'intérieur de 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 ouvert avec un navigateur internet.

Mise à jour ( Mode avancé )

Options disponibles

Mise en place du chiffrement

Vous pouvez mettre en place le Chiffrement des données sensibles de façon automatique au moment de la mise à jour.

Une clé de chiffrement sera alors générée lors du processus de mise à jour et la base de données du Synchronizer sera chiffrée.

Pour cela, lancez la commande suivante :

./update.sh --activate-encryption <nom de clé>

• --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.

Options pour l'automatisation de la mise à jour

Passer les demandes de saisies lors de la mise à jour

Si vous voulez automatiser la mise à jour de Shinken, via un script Ansible par exemple, vous allez avoir besoin de désactiver les demandes de saisies lors de la mise à jour de Shinken.

Nous vous conseillons fortement de faire au moins une installation manuelle afin de lire les informations fournies lors de la mise à jour 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 la mise à jour.

Désactiver le redémarrage des démons à la fin de la mise à jour

Dans le cas où vous voulez automatiser la mise à jour sur plusieurs machines, vous pouvez avoir envie de redémarrer tous les démons de toutes les machines en même temps afin d'éviter que par exemple un Arbiter trop à jour tente de parler avec des démons qui n'ont pas encore été mis à jour.

• --disable-daemons-restart-after-update permet de désactiver le redémarrage des démons à la fin de la mise à jour.

Faire la mise à jour 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 : permets 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 la mise à jour 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 à bien accès aux " repository ". Cette vérification va bloquer la mise à jour alors que le serveur a bien accès à des " repository " locaux. Il faut alors utiliser l'option suivante :

• --skip-redhat-subscription-check : permets 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 ).

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, 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.
  • A 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 et mssql, donc pas les paquets pour oracle par exemple.

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

exclura les dépendances des packs oracle et nagios-checks (seulement en RedHat 8 pour ce dernier)

Exclure l'installation ou la mise à jour de Nagvis

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

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 mettez à jour un autre démon ou si ces addons ne sont pas nécessaires, vous pouvez choisir de ne pas installer ou mettre à jour  Nagvis en utilisant l'option --skip-nagvis.

Migration de certains fichiers de configuration

Lors d'une mise à jour, il peut arriver que certains fichiers de configuration changent de place.

• Le script de mise à jour va gérer ces déplacements de façon transparente.
• Si un de ces déplacements implique d'écraser des fichiers existants, les fichiers originaux seront préservés et copiés avec l'extension .patchsave

Activation du bac à événements ( S'il n'est pas déjà activé )

Lors d'une nouvelle installation, le bac à événements est automatiquement mis en place.

Lors d'une mise à jour depuis une version antérieure, avec une architecture complexe, le script de mise à jour ne peut pas toujours déterminer avec certitude sur quels brokers et quelles Web-UI le bac à événements doit être installé. C'est pourquoi vous devez vous-même effectuer la configuration manuellement.

Il est nécessaire d'ajouter les modules :

• Le module event-manager-writer sur vos brokers ( cela permettra d'enregistrer les données aux nécessaires événements ).
• Le module event-manager-reader sur vos WebUI ( cela permettra aux WebUI d'accéder aux données enregistrées pour les événements ).

Pour le paramétrage spécifique de ces modules, consulter les pages Module event-manager-writer et Module event-manager-reader .

Vérification du bon fonctionnement

Pour vérifier que Shinken Entreprise est bien mis à jour, configuré et fonctionnel, lancez dans un shell la commande :

$ shinken-healthcheck

Elle vous permettra en ligne de commande d'avoir une vision des différents serveurs/éléments qui composent votre architecture Shinken Entreprise.

• Voir la page Shinken-healthcheck - Vérifier le bon fonctionnement de Shinken Entreprise pour plus de détail sur résultat de cette commande.

Mise à jour des checks via la source cfg-file-shinken

Lors de l'installation de Shinken, nous incluons de nombreux checks (via des modèles du Pack Pack shinken : Pack shinken , Pack Linux , Pack windows ,...

Ces éléments de ces packs (checks, modèles, commandes) sont disponibles au travers de la source "cfg-file-shinken" :

Lors d'une update, nous vous fournissons également toutes les mises à jour de ces packs, nous vous conseillons donc d'activer la source et de bien regarder les mises à jour possibles, via les éléments qui apparaîtront en "nouveau" et en "différence".

Mise à jour avec un cluster Mongo

Dans la version V02.07.00, la base Mongodb est mise à jour.

• Lorsque Mongodb a été configuré pour fonctionner en tant que cluster, le comportement du script de mise à jour de Shinken Entreprise a été modifié pour prendre en compte cette configuration particulière.
• Des explications détaillées sont présentes dans la page de documentation dédiée : Si Shinken Inférieur à V02.07.00 - Montée de version en Mongodb 3.0 (réalisée automatiquement sous conditions )

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 à la mise à jour

Les logs de la mise à jour

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-update-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

Erreur lors des actions fait automatiquement lors de la mise à jour

Lors de la mise à jour, il y a un certain nombre d'actions ( sanatize ) qui sont automatiquement réalisées.

Si une de ces actions échoue, il vous faudra créer un ticket au prêt du support avec les fichiers de logs de la mise à jour.

Erreurs concernant MongoDB

Si script de mise à jour ne parvient pas à se connecter à la base Mongo

Lors du démarrage de la mise à jour de Shinken, une vérification est effectuée pour s'assurer que la base de données est accessible. Si MongoDB n'est pas accessible, la mise à jour de Shinken est interrompue, et le message suivant s'affiche :

Il est nécessaire de vérifier que la base de données est bien démarrée et que les paramètres d'accès sont correctement configurés (port, nom du serveur, authentification, tunnel SSH, etc.).

Vérifier que la base de données est opérationnelle

systemctl status mongod

Vérifier les paramètres d'accessibilité de la base dans le fichier de conficuration de votre base : /etc/mongod.conf

La version de MongoDB installée sur votre système n'est pas une version validée par Shinken Solutions.

Le script de mise à jour refuse de s'exécuter avec l'erreur suivante :

ERROR: Mongodb is already installed but your Mongodb version XX.YY.ZZ is not supported for install/update"

Assurez-vous que la version de MongoDB utilisée est la 2.6.9 pour les installations antérieures à Shinken Entreprise 2.6.1 et la 3.0.15 pour les versions de Shinken Entreprise plus récentes.