| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
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 ).
| Warning | ||
|---|---|---|
| ||
L'installation de Shinken Entreprise met en place deux bases de donnée :
Pour ne pas créer de dysfonctionnement, nous vous demandons de ne pas mettre à jour MongoDB / Graphite.
|
Afin de prévenir tout risque, les démons Shinken Entreprise refuseront de démarrer si la version installée de MongoDB n'est pas celle préconisée.| Warning | ||
|---|---|---|
| ||
Dans le cadre de l'utilisation d'un antivirus sur les serveurs Shinken, veuillez vous référer à la page Restrictions à appliquer aux antivirus pour mettre en place les exclusions indispensables au bon fonctionnement des services. |
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 :
| Nom de la version | Date de parution | Nom de l'installeur | Modification par rapport à la version précédente | ||||
|---|---|---|---|---|---|---|---|
RC019.0813 ... RC019 | 22 Avril 2026 ...MODIFIER LES VERSION POUR LA RC19.05 17 Nov. 2025 | RC019.13
| Modification de l'installateur installeur : 1 - Désormais, l'installateur installeur de Shinken n'est plus séparé par langue, mais par la distribution linux ciblée :
Liste des autres modifications : Voir la release note 2 - Désormais, l'installation de Shinken est compatible avec les distributions RHEL 9, Alma 9 et Rocky 9. 3 - Chaque installeur ( en fonction de la distribution ) fournit tous les packs de langue. 4 - Mise à jour du Python 3.11 ( version 3.11.14 ) utilisé par Shinken avec les correctifs de sécurité de Python. 5 - Mise à jour des paquets système ( .rpm ou .deb ) fournis par l'installeur. 6 - Les dépendances système ( .rpm ou .deb ) nécessaires à Shinken sont désormais disponibles via un dépôt local temporaire mis en place par l'installeur ( il sera supprimé à la fin de la mise à jour ) Liste des autres modifications : Voir la release note | ||||
RC018.05 ... RC018 | 24 Oct. 2025 | shinken-enterprise_V02.08.02-RC018.05_FR_Linux_FULL_2025-10-24.tar.gz | Modification de l'installeur : 1 - Le script de mise à jour de Shinken permet de renseigner | RC018.05 ... RC018 | 24 Oct. 2025 | shinken-enterprise_V02.08.02-RC018.05_FR_Linux_FULL_2025-10-24.tar.gz | Modification de l'installateur : 1 - Le script de mise à jour de Shinken permet de renseigner les identifiants de connexion à MongoDB lorsque l’authentification par mot de passe est activée dans la base. 2 - Le script d'installation vérifie la présence d'un serveur de synchronisation de temps par le réseau ( NTP ) et installe Chrony s'il n'y en a pas. 3 - Ajout de l'option --disable-time-server-setup-if-missing pour désactiver l'installation de Chrony. 4 - Désormais, l'installation de Shinken est compatible avec la distribution Debian 13. Liste des autres modifications : Voir la release note |
RC017.02 ... RC017 | 19 juin 2025 ... 20 mai 2025 | shinken-enterprise_V02.08.02-RC017.02_FR_Linux_FULL_2025-06-16.tar.gz | Modification de l'installateur installeur : 1 - Mise à jour du Python 3.11 ( version 3.11.11 ) utilisé par Shinken avec les correctifs de sécurité de Python. Liste des autres modifications : Voir la release note | ||||
RC016.06 ... RC016 | 19 mai 2025 ... 27 février 2025 | shinken-enterprise_V02.08.02-RC016.06_FR_Linux_FULL_2025-05-15.tar.gz | Liste des autres modifications : Voir la release note | ||||
RC015.19 ... RC015 | 23 juin 2025 ... 12 Aout 2024 | shinken-enterprise_V02.08.02-RC015.12_FR_Linux_FULL_2025-01-16.tar.gz | Modification de l'installateur installeur : 1 - Tous les démons fonctionnent avec Python 3.11.8. 2 - Désormais, l'installation de Shinken est compatible avec les versions RHEL/Alma 8.10. 3 - L'installation de Shinken est désormais possible sur les distributions Rocky 8.9 et 8.10. Liste des autres modifications : Voir la release note | ||||
RC014.05 RC014.04 RC014.03 RC014.02 RC014.01 RC014 | 11 avril 2024 | shinken-enterprise_V02.08.02-RC014.05_FR_Linux_FULL_2024-04-05.tar.gz | Modification de l'installateur installeur : 1 - Désormais, l'installation de Shinken est compatible avec les versions RHEL/Alma 8.9. 2 - Les démons Poller et Reactionner fonctionnent avec Python 3.11.8. 3 - Mise à jour du Python 2.7 ( version 2.7.18-15 ) utilisé par les autres démons de Shinken avec les correctifs de sécurité de RedHat. 4 - Ajout de l'option --skip-nagvis. 5 - Suppression du support de RHEL / CentOS 6. Liste des autres modifications : Voir la release note | ||||
| RC013 | 04 octobre 2023 | shinken-enterprise_V02.08.02-RC013_US/FR_Linux_FULL_2023-10-03.tar.gz | Voir la release note | ||||
| RC012.01 RC012.02 RC012.03 | 13 septembre 2023 | shinken-enterprise_V02.08.02-RC012.01_US/FR_Linux_FULL_2023-07-13.tar.gz | Modification de l'installateur installeur : 1 - L'exclusion des "nagios-checks" et de leurs dépendances par les paramètres --packs-to-install / --packs-to-exclude est désormais fonctionnelle en RHEL7 / Centos7 ( elle était réservée à la RHEL8 / Alma8 auparavant ). Liste des autres modifications : Voir la release note | ||||
| RC012 | 06 juillet 2023 | shinken-enterprise_V02.08.02-RC012_US/FR_Linux_FULL_2023-07-05.tar.gz | Modification de l'installateur installeur : 1 - Les dossiers /var/lib/shinken-nagvis et /opt/nagvis/ dans lesquels NagVis va s'installer, peuvent maintenant être des points de montage. 2 - Depuis la mise à jour de RHEL/Alma en 8.8 ( fait le 18/05/2023 ), l'installation des versions précédentes de Shinken échouait. Désormais l'installation est compatible sur les RHEL/Alma 8.5 à 8.8 incluses. Liste des autres modifications : Voir la release note | ||||
| RC011 | 07 Avril 2023 | shinken-enterprise_V02.08.02-RC011_US/FR_Linux_FULL_2023-04-04.tar.gz | Modification de l'installateur installeur : 1 - Désormais l'installation est possible sur les systèmes Alma 8. Liste des autres modifications : Voir la release note | ||||
| RC010 | 07 Mars 2023 | shinken-enterprise_V02.08.02-RC010_US/FR_Linux_FULL_2023-03-07.tar.gz | Voir la release note | ||||
| RC009 | 01 décembre 2022 | shinken-enterprise_V02.08.02-RC009_US/FR_Linux_FULL_2022-11-17.tar.gz | Modification de l'installateur installeur : 1 - Désormais l'installation est possible sur les systèmes RHEL 8.5 & 8.6 2 - Rajout de l'option "--packs-to-install" : permet de ne sélectionner que les dépendances listées. 3 - Rajout de l'option "--packs-to-exclude" : permet de ne pas installer les dépendances listées. Liste des autres modifications : Voir la release note | ||||
| RC008 | 15 novembre 2022 | shinken-enterprise_V02.08.02-RC008_US/FR_Linux_FULL_2022-11-07.tar.gz | Voir la release note | ||||
| RC007.03 | 23 septembre 2022 | shinken-enterprise_V02.08.02-RC007.03_US/FR_Linux_FULL_2022-09-23.tar.gz | Voir la release note | ||||
| RC007.02 | 19 septembre 2022 | shinken-enterprise_V02.08.02-RC007.02_US/FR_Linux_FULL_2022-09-19.tar.gz | Voir la release note | ||||
| RC007.01 | 30 Août 2022 | shinken-enterprise_V02.08.02-RC007.01_US/FR_Linux_FULL_2022-08-30.tar.gz | Voir la release note | ||||
| RC007 | 29 Mai 2022 | shinken-enterprise_V02.08.02-RC007_US/FR_Linux_FULL_2022-06-22.tar.gz | Modification de l'installateur installeur : 1 - Ajout du paramètre "--ignore-pre-setup-non-blocking-errors" dans l'installation de patchs et de mise à jour pour passer outre les erreurs non importantes pour le bon fonctionnement de Shinken. Pour l’instant, seul le backup pré-installation est impacté. Liste des autres modifications : Voir la release note | ||||
| RC006.02 | 23 Mai 2022 | shinken-enterprise_V02.08.02-RC006.02_US/FR_Linux_FULL_2022-04-14.tar.gz | Version d'origine ( non finale pour l'instant ). |
Mise à jour de Shinken Entreprise
Prérequis
Concernant l'OS
Environnement requis :
| Distribution RHEL |
|---|
- Centos : 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9
| 7 | 8 | 9 | |
|---|---|---|---|
| Red Hat | 7.2 => 7.9 | 8.5 => 8.10 | 9.7 |
| Alma | 7.2 => 7.9 | 8.5 => 8.10 | 9.7 |
| Rocky | 7.2 => 7.9 | 8.5 => 8.10 | 9.7 |
| CentOS | 7.2 => 7.9 |
Environnement requis :
| Distribution Debian | 13 |
|---|---|
| Debian |
| 13 |
Shinken Entreprise a choisiles distributions suivantes :
- RHEL ( Red Hat Enterprise Linux Red Hat Enterprise Linux ) est la distribution référente dans l'écosystème professionnel Linux
- CentOS ( Community ommunity enterprise erprise Operating perating System ) est une distribution dont tous ses 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
- 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. 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 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 :
| Distribution | Version distribution | Date support éditeur distribution | Gérée actuellement par Shinken | Sera gérée dans les prochaines versions de Shinken | Recommandations Shinken | |||
|---|---|---|---|---|---|---|---|---|
RHEL | 6.10 | plus supportée | Non | Non | Cette version de la distribution n'est plus supportée depuis la version 02V02.08.02-RC014 de Shinken. | |||
| 7.2 → 7.9 | juin 2024 | Oui | Oui | Mettre Faire une mise à jour en RHEL 7.9 si possible. | ||||
| 8.5 → 8.10 | mai 2029 | Oui | Oui | Gérée depuis la V02.08.02-RC009. | Alma | 8 | mai 2029 | |
| 9.7 | Février 2026 | Oui | Oui Successeur de CentOS, similaire à la RHEL 8. | Gérée depuis la V02.08.02-RC012RC019.10. | ||||
| Alma | Rocky8.5 → 8.10 | mai 2029 | Oui | Oui | Successeur de CentOS, similaire à la RHEL 8. Gérée depuis la V02.08.02- RC015 | CentOS | 6.10 | plus|
RC012. | ||||||||
| 9.7 | Février 2026 | Oui | Oui | Gérée depuis la V02.08.02-RC019.10. | ||||
| Rocky | 8.9 → 8.10 | mai 2029 | Oui | Oui | Successeur de CentOS, similaire à la RHEL 8. Gérée depuis la V02.08.02-RC015. | |||
| 9.7 | Février 2026 | Oui | Oui | Gérée depuis la V02.08.02-RC019.10. | ||||
| CentOS | 6.10 | plus supportée | Non | Non | Cette version de la distribution n'est plus supportée depuis la version 02.08.02-RC014 de Shinken. | |||
| 7.2 → 7.9 | juin 2024 | Oui | Oui | |||||
Faire une mise à jour en Centos 7.9 si possible. Nous conseillons de déplacer cette installation vers une Alma 8. | ||||||||
| 8 | plus supportée | Non | Non | La version 8 a été annoncée comme arrêtée fin 2021 et ne sera donc pas gérée. | ||||
| DebianDebian | 13 | Juin 2030 | Oui | Oui | Gérée depuis la V02.08.02-RC018.05. |
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 ).
| Panel | ||
|---|---|---|
| ||
|
| Panel | ||
|---|---|---|
| ||
|
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 ).
| Panel | ||
|---|---|---|
| ||
|
Concernant la transformation de la CentOS en CentOS Stream ( Beta de la RHEL )
Redhat a changé sa politique concernant CentosCentOS, qui devient maintenant une version Béta 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
| Info | ||
|---|---|---|
| ||
Lors d'une installation de distribution Redhat Enterprise Linux ( commerciale ), il faut associer la souscription Redhat au système. Voici les commandes à utiliser depuis le serveur: 1/ subscription-manager register et il faut également l'attacher à l'OS en cours: 2/ subscription-manager attach Yum pourra alors être utilisé correctement car l'abonnement sera valide ( et donc Shinken pourra être installé ) |
Prérequis navigateur web
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Concernant les versions de Shinken Entreprise
| Note | ||
|---|---|---|
| ||
Pour mettre à jour Shinken depuis une version majeure qui dispose d'un patch qui n'a pas été installé ( exemple : V02.08.01, avec le cumulativePatch-25 ) vers une nouvelle version majeure ( exemple : V02.08.02 RC015 ) :
IMPORTANT : Il n'est pas possible de rétrograder la version de Shinken.
|
Extraction du package et mise à jour
Prérequis a la mise a jour
Il faut être loggué en tant que root.
| Code Block | ||||
|---|---|---|---|---|
| ||||
$id uid=0(root) gid=0(root) |
Et que le umask du compte root soit à 0022.
| Code Block | ||||
|---|---|---|---|---|
| ||||
$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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
shinken-enterprise_V02.08.XX-RC0XX.XX_ALL-LANG_Linux-LISTE_DES_DISTRIBUTIONS_FULL_AAAA-MM-JJ.tar.gz |
« Décompresser » le package :
| Code Block | ||||
|---|---|---|---|---|
| ||||
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
| Code Block | ||||
|---|---|---|---|---|
| ||||
cd shinken-enterprise_V02.08.XX-RC0XX.XX_ALL-LANG_Linux-LISTE_DES_DISTRIBUTIONS_FULL_AAAA-MM-JJ |
Exécuter le script :
| Code Block | ||||
|---|---|---|---|---|
| ||||
./update.sh |
| Tip |
|---|
Ce qui aura pour effet :
|
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
| Scroll Title | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Options de connexion à la base MongoDB
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
Passer les demandes de saisies lors de la mise à jour
| Scroll Title | |||||
|---|---|---|---|---|---|
| |||||
|
| Warning |
|---|
| Il est cependant fortement conseillé de lire les informations fournies lors de la mise à jour. |
| Info |
|---|
| Cette option peut être combinée avec les autres options de l'installeur. |
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.
| Anchor | ||||
|---|---|---|---|---|
|
Mise en place du chiffrement
| Scroll Title | |||||
|---|---|---|---|---|---|
| |||||
|
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 ).
| Tip |
|---|
Si vous n'avez jamais activé le chiffrement des données sensibles, nous vous conseillons de procéder à la mise à jour sans activer le chiffrement et de découvrir la fonctionnalité par la lecture de 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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
./update.sh --activate-encryption <nom de clé> |
| Warning |
|---|
La mise en place automatique du chiffrement nécessite dans tous les cas d'effectuer l'export et la sauvegarde de la clé générée ( voir la page shinken-protected-fields-keyfile-export ). |
La commande shinken-healthcheck permettra de vérifier la bonne configuration des démons et du chiffrement.
| Anchor | ||||
|---|---|---|---|---|
|
Serveur de synchronisation du temps par le réseau
| Scroll Title | |||||
|---|---|---|---|---|---|
| |||||
|
| Warning |
|---|
Du fait de son architecture distribuée, pour éviter toutes incohérences des données, il est primordial que tous les serveurs de Shinken soient à l'heure ( voir la page Les serveurs de supervision doivent impérativement être à l'heure via ntp ou chrony ). |
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.
Anchor Désactiver le redémarrage des démons à la fin de la mise à jour Désactiver le redémarrage des démons à la fin de la mise à jour
Désactiver le redémarrage des démons à la fin de la mise à jour
| Scroll Title | |||||
|---|---|---|---|---|---|
| |||||
|
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.
Anchor Faire la mise à jour sur un serveur avec des repository internes ( non publics ) fixés sur une version précise Faire la mise à jour sur un serveur avec des repository internes ( non publics ) fixés sur une version précise Anchor Faire la mise à jour sur un serveur
RedHat non enregistré sur les repository RedHat Faire la mise à jour sur un serveur RedHat non enregistré sur les repository RedHat
Faire la mise à jour sur un serveur RHEL non enregistré sur les dépôts RedHat
| Scroll Title | |||||
|---|---|---|---|---|---|
| Scroll Title | |||||
| |||||
|
Debian 13 ou CentOS 7 ou Alma / Rocky 8 et 9
Debian 13L'option --packageskip-updateredhat-only-on-conflict subscription-check 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 En effet, 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 :
- 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 ).
| Anchor | ||||
|---|---|---|---|---|
|
Permettre d'exclure l'installation ou la mise à jour de certaines dépendances de sondes
--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.
| Warning | ||
|---|---|---|
| ||
Il est à noter que le serveur doit tout de même avoir accès à un dépôt de paquets valide. Des conflits peuvent survenir dans le cas de l'installation de nouveaux paquets. Dans ce cas, seul yum pourra les résoudre ( cela arrive quand les paquets fournis par le script de mise à jour sont trop récents par rapport à ce qui est disponible dans le dépôt ). |
Faire la mise à jour sur un serveur RHEL non enregistré sur les dépôts RedHat
| Scroll Title | |||||
|---|---|---|---|---|---|
| |||||
|
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 ).
|
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.
| Warning |
|---|
Il est important de noter qu'à l'heure actuelle seules les dépendances des sondes ne sont pas installées.
|
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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
--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
| Code Block | ||||
|---|---|---|---|---|
|
Permettre d'exclure l'installation ou la mise à jour de certaines dépendances de sondes
| Scroll Title | ||||
|---|---|---|---|---|
| ||||
| --- | N'installer que les dépendances listées. | ||
--packs-to-exclude ARG | --- | Ne pas installer les dépendances listées. |
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.
| Warning |
|---|
Il est important de noter qu'à l'heure actuelle seules les dépendances des sondes ne sont pas installées.
|
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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
--packs-to-install : nagios-checks,mssql |
| Code Block | ||||
|---|---|---|---|---|
| ||||
--packs-to-exclude: oracle,nagios-checks |
| Warning |
|---|
Pour les futures mises à jour de Shinken, il faudra utiliser ces options à chaque fois pour préciser la liste des dépendances à inclure ou à exclure. |
Exclure l'installation ou la mise à jour de Nagvis
| anchor | parameter_command |
|---|---|
| title | |
| Panel |
|---|
--skip-nagvis |
---
Ne pas installer Nagvis sur le serveur.
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 ) )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.
| Warning |
|---|
Pour les futures mises à jour de Shinken, il faudra utiliser cette option à chaque fois pour ignorer l'installation de Nagvis. |
| Warning |
|---|
Après une installation sans Nagvis, pour pouvoir activer les addons, il faudra effectuer une mise à jour de Shinken sans l'option pour ne pas installer 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 )
- 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-weathersur 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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ 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 :
| Panel |
|---|
|
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".
| Info |
|---|
Si des personnalisations ont déjà été faites sur les éléments de ces packs, il faudra faire preuve de vigilance avant d'appliquer les différences. Cependant, il est au moins conseillé de mettre à jour les éléments relatifs au Pack shinken ( éléments 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
Sur le serveur de l'Arbiter, s'il n'y a pas de licence valide, la commande shinken-healthcheck affichera un message d'erreur :
- La licence par défaut installée est une licence d'essai.
- Seul un très faible nombre d'hôtes pourra être mis en supervision.
| Panel |
|---|
|
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 :
: oracle,nagios-checks |
exclura les dépendances des dépendances (fichiers rpm )des packs oracle et nagios-checks
| Warning |
|---|
Pour les futures mises à jour de Shinken, il faudra utiliser ces options à chaque fois pour préciser la liste des dépendances à inclure ou à exclure. |
Exclure l'installation ou la mise à jour de Nagvis
| Scroll Title | |||||
|---|---|---|---|---|---|
| |||||
|
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.
| Warning |
|---|
Pour les futures mises à jour de Shinken, il faudra utiliser cette option à chaque fois pour ignorer l'installation de Nagvis. |
| Warning |
|---|
Après une installation sans Nagvis, pour pouvoir activer les addons, il faudra effectuer une mise à jour de Shinken sans l'option pour ne pas installer 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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ 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 :
| Panel |
|---|
|
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".
| Info |
|---|
Si des personnalisations ont déjà été faites sur les éléments de ces packs, il faudra faire preuve de vigilance avant d'appliquer les différences. Cependant, il est au moins conseillé de mettre à jour les éléments relatifs au Pack shinken ( éléments 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 )
| Anchor | ||||
|---|---|---|---|---|
|
Clé de licence Shinken Enterprise
Sur le serveur de l'Arbiter, s'il n'y a pas de licence valide, la commande shinken-healthcheck affichera un message d'erreur :
- La licence par défaut installée est une licence d'essai.
- Seul un très faible nombre d'hôtes pourra être mis en supervision.
| Panel |
|---|
|
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 :
| Panel |
|---|
|
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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
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.
| Panel | ||
|---|---|---|
| ||
|
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 :
| Panel |
|---|
|
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
Enfin, relancer la commande shinken-healthcheck. Le message d'erreur de licence doit avoir disparu. Voici un exemple d'information de licence valide :
| Panel |
|---|
|
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 :| Code Block | ||||
|---|---|---|---|---|
| ||||
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.
| Panel | ||
|---|---|---|
| ||
|
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 :
| No Format |
|---|
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é :
| Code Block | ||||
|---|---|---|---|---|
| ||||
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 |
| Info | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Sous Debian la ligne :
est remplacée par :
|
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.
| Anchor | ||||
|---|---|---|---|---|
|
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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
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
| Code Block | ||||
|---|---|---|---|---|
| ||||
# Se placer dans cet environnement :
chroot /root/stable-chroot/
# Supprimer les paquets précédemment téléchargés
apt clean
# Télécharger les paquets problématiques
apt --download-only --reinstall -y -o "APT::Install-Recommends=1" install some-dependency other-dependency
# Quitter l'environnement minimal
exit |
Étape 3 : Récupérer les paquets téléchargés
| Code Block | ||||
|---|---|---|---|---|
| ||||
# 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
RHEL
| Code Block | ||||
|---|---|---|---|---|
| ||||
subscription-manager repos --enable="rhel-7-server-optional-rpms"
rpm --import https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7
yum -y install https://dl.fedoraproject.org/pub/archive/epel/7/x86_64/Packages/e/epel-release-7-14.noarch.rpm |
CentOS
| Code Block | ||||
|---|---|---|---|---|
| ||||
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 :
| Code Block | ||||
|---|---|---|---|---|
| ||||
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
| Code Block | ||||
|---|---|---|---|---|
| ||||
yum install yum-utils |
Étape 3 : Télécharger les paquets manquants
| Code Block | ||||
|---|---|---|---|---|
| ||||
rm -fr /root/shinken-missing-rpms
repotrack --arch=x86_64 --download_path=/root/shinken-missing-rpms some-dependency other-dependency
# repotrack télécharge toutes les variantes ( architectures ) d'un paquet, inutile de garder les versions 32 bits
rm -f /root/shinken-missing-rpms/*.i686.rpm |
Étape 4 : Récupérer les paquets téléchargés
| Code Block | ||||
|---|---|---|---|---|
| ||||
# ==> 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
RHEL 8
| Code Block | ||||
|---|---|---|---|---|
| ||||
subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms
rpm --import http://download.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-8
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm |
RHEL 9
| Code Block | ||||
|---|---|---|---|---|
| ||||
subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
rpm --import http://download.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-9
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm |
Alma 8
| Code Block | ||||
|---|---|---|---|---|
| ||||
dnf config-manager --set-enabled powertools
dnf install -y epel-release |
Alma 9
| Code Block | ||||
|---|---|---|---|---|
| ||||
dnf install -y epel-release
dnf config-manager --set-enabled crb |
Rocky 8
| Code Block | ||||
|---|---|---|---|---|
| ||||
dnf config-manager --set-enabled powertools
dnf install -y epel-release |
Rocky 9
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 :
| Panel |
|---|
|
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| Code Block | ||||
|---|---|---|---|---|
| ||||
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 :
| No Format |
|---|
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.
...
dnf config-manager --set-enabled crb
dnf install -y epel-release |
Étape 2 : Télécharger les paquets manquants
| Code Block | ||||
|---|---|---|---|---|
| ||||
rm -fr /root/shinken-missing-rpms
dnf download --arch x86_64,noarch --resolve --alldeps --downloaddir=/root/shinken-missing-rpms |
Étape 3 : Récupérer les paquets téléchargés
| Code Block | ||||
|---|---|---|---|---|
| ||||
# ==> 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.