evolix/wiki
22
0
Fork 0
Code Releases Activity

typo

Browse source
This commit is contained in:
Ludovic Poujol 2017-06-09 15:10:33 +02:00
parent 5b5a3263ad
commit 10b2e63d6b
1 changed files with 3 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
HowtoIcinga.md
View file

@ -153,7 +153,7 @@ Il est possible de lancer des commandes (planifier un check, downtimer une machi
Pour continuer l'installation de l'interface web, il faut aller sur <http://monitoring.example.com/icingaweb2/setup> : un token sera demandé qui peut être créé avec la commande `icingacli setup token create`.
La prochaine étape de l'assistant demande quelles fonctions activer : il faut au moins activer le module **Monitoring** sinon l'interface web perd = son intérêt !
La prochaine étape de l'assistant demande quelles fonctions activer : il faut au moins activer le module **Monitoring** sinon l'interface web perd son intérêt !
L'assistant lance ensuite une série de tests. Il est important de s'assurer que tous les tests sont OK (il est normal que les tests PostgreSQL s'affichent en jaune, car on utilise MySQL).
@ -253,7 +253,7 @@ Et voilà, en théorie le master et le client peuvent se parler ! On peut mainte
<https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-top-down-command-endpoint>
C'est la méthode la plus simple, similaire à NRPE : le nœud master souhaitant effectuer un check, il lance une commande au travers de l'agent local icinga2 installé. Le seul pré-requis est que les objets de type **CheckCommand** définissant les commandes à exécuter doivent être présent localement (i.e. là où la commande est exécutée).
C'est la méthode la plus simple, similaire à NRPE : le nœud master souhaitant effectuer un check, il lance une commande au travers de l'agent local icinga2 installé. Le seul pré-requis est que les objets de type **CheckCommand** définissant les commandes à exécuter doivent être présent sur le master **et** localement (i.e. là où la commande est exécutée).
#### mode bottom up config sync (checks envoyés vers le master)
@ -312,7 +312,7 @@ object Service "ssh" {
Pour que la synchronisation se fasse entre le master et le client, on redémarre Icinga sur le master :
~~~
# systemcrl reload icinga2
# systemctl reload icinga2
~~~
> *Note* : Si, pour une raison ou une autre, la configuration venait à être invalide lors du reload, celui-ci va être avorté. Mais Icinga va continuer de fonctionner avec l'ancienne configuration valide chargée avant. En effet, il contrôle la configuration avant de demander au daemon de s'arréter. Pour controler la syntaxe de la configuration, on peut d'ailleurs utiliser la commande `icinga2 daemon --validate`
@ -563,8 +563,6 @@ Modules avec des fonctions de haute disponibilité :
Pour ajouter un nouveau noeud une *zone* master, il suffit de l'installer normalement comme expliqué plus haut, puis d'ajuster le fichier `zone.conf` pour faire en sorte que les deux noeuds appartiennent bien à la même zone.
## Plomberie
### Gestion de la PKI - Génération manuelle des certificats
Dans certains cas, on peut être amené à générer manuellement le certificat TLS pour l'authentification d'un nouveau noeud.