| Scroll Ignore |
|---|
| scroll-viewport | true |
|---|
| scroll-pdf | true |
|---|
| scroll-office | true |
|---|
| scroll-chm | true |
|---|
| scroll-docbook | true |
|---|
| scroll-eclipsehelp | true |
|---|
| scroll-epub | true |
|---|
| scroll-html | false |
|---|
|
|
La base Mongodb utilisé est la version 3.0.15. Elle est livrée avec deux moteurs de données:
MMapv1: utilisé seulement si vous avez une installation initiale de Shinken en V02.06.03 ou antérieur, toutes les installations suivantes utilisent le moteur Wired TigerPour garantir que seules les instances de Shinken puissent accéder aux données de la base, il est possible d'activer l'authentification par mot de passe au niveau de la base de données.
Il sera alors nécessaire de spécifier les identifiants à utiliser par Shinken dans les fichiers de configuration des démons et des modules se connectant à MongoDB.
Ces identifiants devront être fournis lors de l'exécution de toute commande Shinken nécessitant un accès à la base de données.
La procédure décrite permet de minimiser au maximum le temps d'interruption de service. Ce temps d'interruption correspondra uniquement au temps nécessaire pour redémarrer le cluster MongoDB et Shinken.
Les étapes du protocole sont les suivantes :
Créer l'utilisateur dans la base MongoDB.
- Exiger l'authentification par mot de passe dans MongoDB.
Configurer Shinken pour s'authentifier avec l'utilisateur auprès de MongoDB.
Redémarrer MongoDB et Shinken.
- Mettre à jour la supervision ( sup de sup ) des Brokers et du Synchronizer dans Shinken afin de prendre en compte l'activation de l'authentification.
Étape 1 : Créer l'utilisateur d'authentification à la base
On commence par créer l'utilisateur dans MongoDB qui sera utilisé pour s'authentifier.
Se connecter au shell MongoDB :
Depuis le shell MongoDB, exécutez les deux commandes suivantes :
| Code Block |
|---|
|
db.createUser(
{ user : 'YOUR_USER',
pwd : 'YOUR_PASSWORD',
roles : [ { role : 'root', db : 'admin' } ]
}
) |
Adapter le nom d'utilisateur ( YOUR_USER ) et le mot de passe ( YOUR_PASSWORD ) dans la commande.
| Warning |
|---|
Il ne faut pas modifier les champs role et db. Pour que Shinken fonctionne correctement, l'utilisateur doit disposer de privilèges avancés sur l'ensemble des bases de données, ce qui impose la valeur de ces deux paramètres. |
Exemple :
| Code Block |
|---|
|
mongos> db.createUser(
... { user : 'shinken',
... pwd : 'shinken',
... roles : [ { role : 'root', db : 'admin' } ]
... }
... )
Successfully added user: {
"user" : "shinken",
"roles" : [
{
"role" : "root",
"db" : "admin"
}
]
} |
Se connecter à MongoDB avec l'utilisateur crée
Il est désormais possible de s'authentifier lors de la connexion à MongoDB.
Les identifiants peuvent être spécifiés directement dans la commande de lancement du shell MongoDB :
| Code Block |
|---|
|
mongo --username YOUR_USER --password YOUR_PASSWORD --authenticationDatabase admin |
| Tip |
|---|
Si le champ --password est laissé vide, un prompt s'affiche pour demander le mot de passe, évitant ainsi d'exposer celui-ci en clair. |
Il est également possible de fournir les identifiants une fois connecté dans le shell MongoDB :
| Code Block |
|---|
|
use admin
db.auth('YOUR_USER', 'YOUR_PASSWORD') |
| Tip |
|---|
La commande db.auth n'est pas sauvegardée dans l'historique des commandes du shell MongoDB, ce qui évite d'exposer le mot de passe. |
Lorsque l'authentification par mot de passe sera activée dans MongoDB, seules les connexions avec des identifiants valides seront acceptées.
Changer le mot de passe d'un utilisateur
Pour changer le mot de passe de l'utilisateur créé , il faut se connecter au shell MongoDB avec les identifiants actuels , puis exécuter les deux commandes suivantes :
| Code Block |
|---|
|
db.changeUserPassword('YOUR_USER', 'NEW_PASSWORD') |
Étape 2 : Activer l'authentification à la base
Pour activer l'authentification dans MongoDB, il faut ajouter le champ suivant dans le fichier de configuration /etc/mongod.conf
| Code Block |
|---|
| language | js |
|---|
| theme | Confluence |
|---|
|
security:
authorization: enabled |
Exemple de fichier de configuration complet
RHEL / CentOS 7 ou RHEL / Alma / Rocky 8 ou RHEL / Alma / Rocky 9
| Code Block |
|---|
| language | js |
|---|
| theme | Confluence |
|---|
|
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# Where and how to store data.
storage:
dbPath: /var/lib/mongo
journal:
enabled: true
# how the process runs
processManagement:
fork: true # fork and run in background
pidFilePath: /var/run/mongodb/mongod.pid
# network interfaces
# NOTE: when go as a replicat member (cluster), change the 27017 to 27018 according to configuration
# and comment the bindIp parameter
net:
port: 27017
unixDomainSocket:
enabled: false
bindIp: 127.0.0.1 # Listen to local interface only, comment to listen on all interfaces.
storage:
engine: wiredTiger
security:
authorization: enabled |
| Warning |
|---|
Sur une distribution Debian il faut noter que : - la base de données est stockée dans le dossier /var/lib/mongodb.
- Le système de démarrage des démons est géré différemment, il ne doit pas y avoir de section processManagement dans le fichier de configuration.
|
| Code Block |
|---|
| language | js |
|---|
| theme | Confluence |
|---|
|
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# Where and how to store data.
storage:
dbPath: /var/lib/mongodb
journal:
enabled: true
# network interfaces
# NOTE: when go as a replicat member (cluster), change the 27017 to 27018 according to configuration
# and comment the bindIp parameter
net:
port: 27017
unixDomainSocket:
enabled: false
bindIp: 127.0.0.1 # Listen to local interface only, comment to listen on all interfaces.
storage:
engine: wiredTiger
security:
authorization: enabled |
Étape 3 : Déclarer l'utilisateur et le mot de passe dans Shinken
Dans les fichiers de configuration
Il est désormais possible de déclarer l'utilisateur et le mot de passe à utiliser pour que Shinken s'authentifie à la base.
- Tous les composants de Shinken qui se connectent à MongoDB doivent voir leur configuration modifiée sur le serveur de l'Arbiter.
- Voici la liste des éléments qui se connectent à MongoDB et dont la configuration doit être mise à jour :
- Dans le cas de l'utilisation de l'outil tiers Grafana, il faut aussi modifier sur la ou les machines avec un carbon-cache le fichier de configuration /opt/graphite/conf/mongodb.conf ( voir la page Grafana - v8.3.2 ) ;
Une fois que l'authentification par mot de passe est activée, il faut de fournir les identifiants aux commandes Shinken qui se connectent à la base. L'aide des commandes permet de savoir si une commande se connecte à MongoDB.
Les paramètres pour s'identifier sont : --mongo-username et --mongo-password
Avant d'exécuter tout traitement, les commandes Shinken se connectant à MongoDB vérifient d'abord qu'elles disposent des privilèges nécessaires, garantissant ainsi l'intégrité et la cohérence de Shinken
| Tip |
|---|
Si l'option --mongo-password est utilisée, le mot de passe risque d'être visible dans l'historique des commandes ( via la commande history par exemple ). Pour éviter d'exposer le mot de passe, il est possible d'utiliser cette commande uniquement avec l'option --mongo-username. Un prompt interactif apparaîtra alors pour demander le mot de passe. Pour automatiser les commandes dans un script, il est possible de faire un fichier qui contient le mot de passe et d'utiliser ce fichier dans la commande ( en utilisant cat ou les directives de redirections des entrées sorties du shellpar exemple ) : --mongo-password $(<my_file). |
Étape 4 : Redémarrer MongoDB et Shinken
Pour appliquer l'activation de l'authentification, il faut redémarrer mongod et Shinken
Il faut éteindre dans l'ordre :
| Excerpt Include |
|---|
| Démarrage/Arrêt/Statut des démons ( Ligne de commande ) |
|---|
| Démarrage/Arrêt/Statut des démons ( Ligne de commande ) |
|---|
| page | DefaultLink[destination=Optional[PageResourceIdentifier[spaceKey=<null>,title=Démarrage/Arrêt/Statut des démons ( Ligne de commande )]],body=Optional.empty,tooltip=Optional.empty,anchor=Optional.empty,target=Optional.empty] |
|---|
| nopanel | true |
|---|
|
| Code Block |
|---|
|
service mongod stop |
Ensuite, il faut redémarrer dans l'ordre suivant :
| Code Block |
|---|
|
service mongod start |
| Excerpt Include |
|---|
| Manipulation des démons Shinken ( Ligne de commande ) |
|---|
| Manipulation des démons Shinken ( Ligne de commande ) |
|---|
| page | DefaultLink[destination=Optional[PageResourceIdentifier[spaceKey=<null>,title=Manipulation des démons Shinken ( Ligne de commande )]],body=Optional.empty,tooltip=Optional.empty,anchor=Optional.empty,target=Optional.empty] |
|---|
| nopanel | true |
|---|
|
L'authentification est désormais activée. MongoDB autorisera uniquement les connexions de l'utilisateur créé.
Si Grafana est utilisé pour afficher les métriques, il faut aussi redémarrer apache sur les serveurs avec un carbon-cache :
RHEL / CentOS 7 ou RHEL / Alma / Rocky 8 ou RHEL / Alma / Rocky 9
| Code Block |
|---|
|
systemctl restart httpd |
| Code Block |
|---|
|
systemctl restart apache2 |
Étape 5 : Mise à jour de la supdesup de Shinken
L'activation de l'authentification par mot de passe sur MongoDB n'est pas automatiquement prise en compte par la supervision.
- Les checks Broker - DB - Last Flush Time, Broker - DB - Open Connections, Synchronizer - DB - Last Flush Time, Synchronizer - DB - Open Connections seront en erreurs.
- Il est nécessaire de modifier les modèles d'hôtes shinken-synchronizer et shinken-broker pour y renseigner les identifiants. Les données à remplir sont :
- DB_AUTH_DB
- DB_USER_NAME
- DB_USER_PASSWORD
Wired Tiger: moteur récent et performant, utilisé pour toutes les nouvelles installations de serveurs, présent par défaut pour les serveurs Shinken installés en V02.07.00 ou supérieurFragmentation des fichiers de stockage
Pour stocker ses données, MongoDB alloue des pages par défaut de 512 Mo.
- Avec le temps, le stockage de donnée sur disque peut créer de la fragmentation car des données sont supprimés, mais mongoDB ne peut pas forcément utiliser des espaces libérés (si par exemples les entrées à écrire sont plus grandes que celles qui ont été supprimées).
- Il s'agit donc d'un point attention. Nous mettons à disposition :