Contexte

Ce guide vous permettra de mettre à jour Shinken Entreprise sur un serveur Linux.

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

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 l'installeur à utiliser, il faut prendre le dernier en date.

02.08.01

Voici l'historique des installeurs de la version 02.08.01:

02.08.01.01

Voici l'historique des installeurs de la version 02.08.01.01:

Mise à jour de Shinken Entreprise

Prérequis

Concernant l'OS

Environnement requis : 

• Centos : 6.10, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9
• RHEL : 8.5, 8.6, 8.7 [ 64bits ]

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

Shinken Entreprise a choisi les distributions produites par Red Hat : RHEL ( Red Hat Enterprise Linux  ) et CentOS  ( Community  enterprise  Operating  System ). Ces distributions Linux, principalement destinées aux serveurs, sont stables, performantes et compatibles avec une très grande majorité des environnements professionnels.

• Red Hat Enterprise Linux ( RHEL ) est la distribution référente dans l'écosystème professionnel Linux
• CentOS est une distribution dont tous ses paquets, à l'exception du logo, sont des paquets compilés à partir des sources de la distribution Red Hat Enterprise Linux ( RHEL )
  • Elle est donc quasiment identique à celle-ci et se veut 100 % compatible d'un point de vue binaire
    

Concernant le support de ces distributions:

Concernant la transformation de la Centos en Centos Stream ( Béta de la Redhat )

Redhat a changé sa politique concernant la Centos, qui devient maintenant une version Béta à la RHEL.
Là ou 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.

Il y a donc 2 axes possibles :

• Vous restez sur Centos 7, le temps qu'un remplaçant se démarque.
  • Le support de la Centos 7 va jusqu'en Juin 2024, ce que laisse une marge conséquente.
  • Dés qu'un remplaçant sera suffisamment stable, nous intégrerons cette OS dans nos mécanismes d'installation / mise à jour / patch
• Passer vos Centos en Redhat.

Notre recherche du remplaçant de Centos

Pour le remplacement de Centos 7, pour l'instant nous attendons qu'une distribution fasse consensus sur le marché afin de partir sur une distribution pérenne, pour les prochaines années. Actuellement, nous suivons de prêt l'évolution de deux distributions, clones de Centos:

• Rockylinux ( par le créateur initial de Centos )
• Almalinux ( par la société CloudLinux )

Transformer une Centos en Redhat

RedHat a mis à disposition un outil de conversion CentOS 7.9 vers RedHat 7.9 qui est convert2rhel.

• Il vous faudra posséder un compte et une licences valide pour procéder à cette conversion.

Suite à nos tests, la conversion d'un serveur avec Shinken déjà installé est fonctionnelle et n'a aucun impact sur notre outil.

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é-tarez » 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 de la configuration et des données utilisateur est effectuée et placée dans /tmp. Ces sauvegardes sont nommées de la manière suivante: "backup-preupdate-version-NUMERO_VERSION".

Mise à jour ( Mode avancé )

Options disponibles

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, notaement le paquet sqlplus founis par Oracle
• mssql: les dépendances pour les sondes Mssql/Sqlserver
• nagios-checks: (seulement disponible pour l'installation sur RedHat8) les dépendances pour les sondes Nagios

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

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

installera uniquement les dépendances des packs nagios et mssql, donc pas les paquets pour oracle

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

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

Erreurs courants lors d'une mise à jour

Les erreurs les plus courantes sont les suivantes :

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

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 ( Si 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 Packs Shinken, Linux, 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".

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

Lors de l'installation des dépendances, si une machine n'est pas connectée à internet ou connectée à un repository privé, il arrive que les scripts d'installation ou de mise à jour échouent.

Dans ce cas, des fichiers sont créés dans le "home" de l'utilisateur avec lequel est effectuée l'installation/mise à jour. Ces fichiers contiennent plus de détails sur les erreurs rencontrées et peuvent être envoyés à votre contact de support Shinken Entreprise pour la correction du problème.

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

• Pour une installation:

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

• Pour une mise à jour:

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

Ces dossiers contiennent 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)

En cas de soucis avec les installations de packages via yum, les erreurs seront présentes dans les fichiers:

• /tmp/install.txt
• /tmp/install_bogus.txt

Cas spécifique de la mise à jour d'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: Inférieur à V02.07.00 - Montée de version en Mongodb 3.0 (réalisée automatiquement sous conditions )