Contexte

Ce guide a pour finalité de permettre la mise à jour de Shinken Entreprise sur un serveur Linux ( RHEL / Alma / Rocky / Debian ).

• Une fois le guide de mise à jour suivi, les interfaces de Configuration et de Visualisation de Shinken seront de nouveaux accessibles, si elles étaient actives.
• La configuration de l'installation Shinken ne sera pas modifiée suite à la mise à jour ( les données dans les fichiers de configuration ne sont pas modifiées ).

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 :

Mise à jour de Shinken Entreprise

Prérequis

Concernant l'OS

Environnement requis : 

• 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
  • Centos : 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9
• Alma : 8.5, 8.6, 8.7, 8.8, 8.9, 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 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
    
• 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 que de 6 mois.

• Nous conseillons donc de n'utiliser que les sous-versions paires ( 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 la CentOS en CentOS Stream ( Beta de la 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

Concernant les versions de Shinken Entreprise

Extraction du package et mise à jour

Prérequis a la mise a 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

Extraction de l'installeur

Il existe plusieurs installeurs qui dépendent de la distribution Linux sur laquelle 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

Exécuter le script :

./update.sh

La documentation liée à la version installée

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

• Elle est disponible dans l'archive shinken-enterprise_V02.08.XX-XXXX.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 ).

Mise à jour ( Mode avancé )

Options disponibles

Options de connexion à la base MongoDB

Passer les demandes de saisies lors de la mise à jour

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

Il est toutefois fortement conseillé de faire au moins une mise à jour sans passer les demandes de saisies, afin de lire les informations fournies lors de la mise à jour, avant de l'automatiser. 

Mise en place du chiffrement

Le chiffrement peut être mis en place automatiquement au moment de la mise à jour ( 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 de mise à jour et la base de données du Synchronizer sera chiffrée.

Pour cela, lancer la commande suivante :

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

Le script de mise à jour 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.

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

Pour automatiser une mise à jour sur plusieurs machines, et synchroniser le démarrage de tous les démons ( afin d'éviter par exemple qu'un Arbiter mis à jour tente de parler avec des démons qui ne le sont pas ), il suffit d'utiliser l'option --disable-daemons-restart-after-update.

Le redémarrage des démons pourra être géré de façon indépendante après la mise à jour. 

Faire la mise à jour 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 de mise à jour 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 le script de mise à jour 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 la mise à jour 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 cette distribution 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, le script de mise à jour 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 : permets 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 ). 

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

Le script de mise à jour permet de choisir de ne pas déployer 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 / 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.
  • À 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 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 dépendances ( fichiers rpm ) des packs oracle et nagios-checks

Exclure l'installation ou la mise à jour de Nagvis

Le script de mise à jour 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.

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

Les modules à activer manuellement ( car les précédentes versions ne les activaient pas par défaut )

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, quel module peut être installé / activé automatiquement.

• Il est alors possible des les activer manuellement

Activer le Bac à événements

Il est nécessaire d'ajouter les modules :

• Le module event-manager-writer sur les brokers ( cela permettra d'enregistrer les données nécessaires au bac à événements ).
  ( voir la page  Module event-manager-writer )
• Le module event-manager-reader sur les modules WebUI ( cela permettra aux WebUI d'accéder aux données enregistrées dans le bac à événements ).
  ( voir la page  Module event-manager-reader )

Activer la Météo des services

Il est nécessaire d'ajouter le module :

• Le module webui-module-service-weather sur les modules WebUI.
  ( voir la page  Module webui-module-service-weather )

Vérification du bon fonctionnement

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

$ shinken-healthcheck

Elle permettra d'avoir une vision des différents serveurs/éléments qui composent l'architecture Shinken Entreprise.

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

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

Lors de la mise à jour de Shinken, de nombreux checks peuvent être ajoutés ou mis à jour ( via des modèles du Pack shinken, du Pack Linux, et du Pack windows ).

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

Il est vivement conseillé d'activer la source afin de 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 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 à 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 :

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

Erreur lors des actions automatiques

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

• Si une de ces actions échoue, il faudra créer un ticket auprès du support avec les fichiers de logs de la mise à jour.

Erreurs concernant MongoDB

Si le 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 configuration de la base : /etc/mongod.conf

La version de MongoDB installée sur le 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"

S'assurer 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.