Contexte

Ce guide vous permettra de mettre 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 ).

Si vous mettez en place une architecture distribuée, après avoir terminé l'installation de Shinken sur vos différents serveurs, il vous faudra passer à la phase de configuration de vos démons (noms et IP des serveurs, royaume, spare, Tag des Pollers, rétention..).

En ce qui concerne la procédure de mise à jour, le script "d'update" vous permettra de mettre à jour votre serveur Shinken de manière complète, même si quelques démons sont seulement activés. La configuration de votre serveur Shinken ne sera pas modifiée.

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

Mise à jour de Shinken Entreprise

Prérequis

Concernant l'OS

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 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, les versions de CentOS supérieures à la 7 étant maintenant construites à partir de Fedora, elles ont d'avantage une vocation de distributions bêta-test et elles sont moins adaptées à des serveurs de production.
• 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 Beta 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 navigateur web

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 les distributions RHEL 9, Alma 9 et Rocky 9 ;
• 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

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 RHEL non enregistré sur les dépôts RedHat

Debian 13 ou CentOS 7 ou Alma / Rocky 8 et 9

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, RHEL 8 ou RHEL 9

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 :
  

  Excerpt Include
  Les 7 Démons et 1 script Les 7 Démons et 1 script nopanel true

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/update_logs/

Ce dossier contient les données suivantes :

• Détails d'installation des paquets : update__shinken_enterprise_detail.log
• Nettoyage de la configuration : update__sanitize.log
• Affichage du script de mise à jour : update__shinken_enterprise.log
• Sauvegarde de la configuration et données utilisateur : ../backup-pre-update/
• Log de l'installation des packages via yum: update__last_rpm_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.

Résoudre un problème d'installation de paquets système ( .rpm ou .deb )

Si l'installeur ne parvient pas à installer certaines dépendances système, un message de ce style sera affiché :

Aborting as package installation failed. Output is available in SHINKEN_INSTALLATION_LOG_FILE file.
Please report this issue to your dedicated support.
You can try to solve this issue by running
 yum install some-dependency other-dependency
and run this script again

 yum install some-dependency other-dependency

 apt install some-dependency other-dependency

Rejouer la commande yum ou apt avec ses paramètres, telle qu'elle est affichée dans le message de l'installeur, pour obtenir la nature de l'erreur.

Si certains paquets ne peuvent être installés ou mis à jour, activer les dépôts indiqués dans la section suivante ( Télécharger des paquets manquants depuis un autre système ) sur le système.

Sinon, pour un système déconnecté, ou ne disposant pas d'un accès aux dépôts de la distribution, il faut passer par un serveur connecté avec un accès à ces dépôts, afin de télécharger ces paquets.

Télécharger des paquets manquants depuis un autre système

Debian 13

Étape 1 : Créer un environnement minimal

Sur un système disposant d'un accès aux dépôts de la distribution :

apt update
apt -y install debootstrap
rm -fr /root/stable-chroot/ 
debootstrap stable /root/stable-chroot/

Étape 2 : Télécharger des paquets manquants dans l'environnement minimal

Étape 3 : Récupérer les paquets téléchargés

# sur le système connecté :

rm -fr /root/shinken-missing-debs
mkdir /root/shinken-missing-debs
cp -nv /root/stable-chroot/var/cache/apt/archives/*.deb /root/shinken-missing-debs/

# ==> Transférer le dossier /root/shinken-missing-debs sur le système déconnecté

# sur le système déconnecté :
apt install ./shinken-missing-debs/*.deb

Relancer l'installation de Shinken, si d'autres paquets manquent, reprendre à l'étape 2 avec ces nouveaux paquets.

RHEL / CentOS 7

Étape 1 : Configurer les dépôts nécessaires

yum install -y epel-release

Les dépôts ayant été archivés ( suite à la fin de vie de la distribution ), il peut être nécessaire d'utiliser les miroirs vault :

sed -i.orig s/mirror.centos.org/vault.centos.org/g /etc/yum.repos.d/*.repo
sed -i.orig s/^#.*baseurl=http/baseurl=http/g /etc/yum.repos.d/*.repo
sed -i.orig s/^mirrorlist=http/#mirrorlist=http/g /etc/yum.repos.d/*.repo
yum clean all

Étape 2 : Installer l'utilitaire permettant de récupérer les paquets

Étape 3 : Télécharger les paquets manquants

Étape 4 : Récupérer les paquets téléchargés 

# ==> Transférer le dossier /root/shinken-missing-rpms sur le système à installer

# Sur le système déconnecté
yum install /root/shinken-missing-rpms/*.rpm 

Relancer l'installation de Shinken, si d'autres paquets manquent, reprendre à l'étape 3 avec ces nouveaux paquets.

RHEL / Alma / Rocky 8 et 9

Étape 1 : Configurer les dépôts nécessaires

Étape 2 : Télécharger les paquets manquants

Étape 3 : Récupérer les paquets téléchargés 

# ==> Transférer le dossier /root/shinken-missing-rpms sur le système à installer

# Sur le système déconnecté
yum install /root/shinken-missing-rpms/*.rpm 

Relancer l'installation de Shinken, si d'autres paquets manquent, reprendre à l'étape 2 avec ces nouveaux paquets.