update how to icinga2
This commit is contained in:
parent
9a73e5c154
commit
41ed0fabeb
195
HowtoIcinga2.md
195
HowtoIcinga2.md
|
|
@ -4,17 +4,20 @@
|
|||
|
||||
## Introduction
|
||||
|
||||
Icinga2 est un logiciel de surveillance réseau qui vise à surveiller des services en place sur des serveurs.
|
||||
Icinga2 est un logiciel de monitoring réseau qui vise à surveiller des services en place sur des serveurs.
|
||||
|
||||
Icinga2 se veut un remplacement pour Icinga, un fork bien établit de Nagios. Contrairement à Icinga, qui reprenait une partie du code de Nagios et qui avait un système de configuration compatible, Icinga2 a été complètement réécrit et n'est pas compatible avec Nagios.
|
||||
|
||||
## Structure
|
||||
|
||||
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Il est important avant de commencer la mise en place d'Icinga2 de bien réfléchir à la manière dont on souhaite monter notre système. Trois architectures différentes sont possibles:
|
||||
Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Il est important avant de commencer la mise en place d'Icinga2 de bien réfléchir à la manière dont on souhaite monter notre système. Trois architectures différentes sont possibles, toutes les trois s'appuyant sur l'agent icinga2 qui sera présent sur le serveur de surveillance (master) que sur les machines surveillées (clients).
|
||||
|
||||
### Configuration locale
|
||||
A noter qu'il est aussi possible de controller des services sans la présence de l'agent icinga2. Pour cela on pourra s'appuier SNMP, SSH, NRPE...
|
||||
|
||||
Dans cette configuration, les machines locales sont configurées pour se surveiller elles-même et envoyer au serveur central les résultats ponctuellement. La configuration réside sur les machines locales et est synchronisée avec le serveur central.
|
||||
### Configuration locale (Déprécié)
|
||||
|
||||
**Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6**
|
||||
Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-même et envoyer au serveur central les résultats ponctuellement. La configuration réside sur les machines locales et est synchronisée avec le serveur central.
|
||||
|
||||
L'avantage de cette méthode est que les clients locaux peuvent écrire leurs configurations directement sans à avoir à passer par une gestion centralisée des tests et des configurations.
|
||||
|
||||
|
|
@ -30,37 +33,33 @@ Plus ["d'infos ici"](https://github.com/Icinga/icinga2/blob/master/doc/6-distrib
|
|||
|
||||
### Pont d'exécution de commandes
|
||||
|
||||
Avec la méthode du pont d'exécution de commandes, l'ensemble des configurations sont sur le serveur central et y restent. Il n'y a pas de synchronisation de configuration avec les machines locales. Quand le serveur central souhaite effectuer une test sur une machine locale, il la lance directement sur cette dernière.
|
||||
Avec la méthode du pont d'exécution de commandes, l'ensemble des configurations sont sur le serveur central et y restent. Il n'y a pas de synchronisation de configuration avec les machines locales. Quand le serveur central souhaite effectuer une test sur une machine locale, il la lance directement sur cette dernière au travers de l'agent local icinga2. Le seul pré-requis est que les objets de type `CheckCommand` définissant les commandes à exécuter doivent être présent localemement.
|
||||
|
||||
L'avantage de cette méthode est que les machines locales n'ont pas besoin d'avoir un daemon qui roule constamment pour effectuer les tests. Cela implique cependant que les machines locales doivent accepter des commandes directement du serveur central, ce qui est peut-être un peu moins sécuritaire.
|
||||
Cela implique cependant que les machines locales doivent accepter des commandes directement du serveur central
|
||||
|
||||
Plus ["d'infos ici"](https://github.com/Icinga/icinga2/blob/master/doc/6-distributed-monitoring.md#-top-down-command-endpoint).
|
||||
|
||||
|
||||
## Installation du master
|
||||
|
||||
### Core
|
||||
### Icinga2
|
||||
|
||||
L'installation du core d'`icinga2` sur le master est relativement simple. Cependant, la documentation disponible en ligne prends pour acquis que la version utilisée est celle disponible dans `jessie-backports`. Il faut donc s'assurer d'avoir la version 2.4 ou supérieure.
|
||||
L'installation du core d'`icinga2` sur le master est relativement simple. Cependant, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs.
|
||||
|
||||
~~~
|
||||
# apt -t jessie-backports install icinga2 icinga2-ido-mysql
|
||||
# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
|
||||
# echo 'deb http://packages.icinga.com/debian icinga-jessie main' >/etc/apt/sources.list.d/icinga.list
|
||||
# apt update
|
||||
# apt install icinga2
|
||||
~~~
|
||||
|
||||
Le package `icinga2-ido-mysql` fournit un assistant d'installation pour configurer une base de donnée MySQL automatiquement. Si on le souhaite, il est également possible de le faire manuellement.
|
||||
|
||||
Une fois l'installation terminée, il est nécessaire d'activer `ido-mysql`:
|
||||
|
||||
~~~
|
||||
# icinga2 feature enable ido-mysql
|
||||
~~~
|
||||
|
||||
Pour finaliser l'installation d'`icinga2` en master, nous allons créer un CA et activer l'API. La commande qui suit lance un assistant d'installation. Mis à part la première option où il faut répondre `n`, les autres peuvent être laissées vides:
|
||||
Pour finaliser l'installation d'`icinga2` en master, il faut se servir de son assistant de configuration. Il se chargera de créer une CA et activer l'API. La commande qui suit lance un assistant d'installation. Mis à part la première option où il faut répondre `n`, les autres peuvent être laissées vides pour conserver les valeurs par défaut:
|
||||
|
||||
~~~
|
||||
# icinga2 node wizard
|
||||
~~~
|
||||
|
||||
On s'assure finalement que l'ensemble des options voulues sont bien activées en redémarrant le daemon:
|
||||
On termine par un redémarrage complet du daemon pour activer les changements de la configuration
|
||||
|
||||
~~~
|
||||
# service icinga2 restart
|
||||
|
|
@ -68,32 +67,27 @@ On s'assure finalement que l'ensemble des options voulues sont bien activées en
|
|||
|
||||
### WebUI
|
||||
|
||||
Pour fonctionner, le WebUI a besoin d'un serveur web et d'un serveur de base de donnée. Dans les exemples qui suivent, nous utiliseront [/HowtoLAMP/Apache Apache] et [/HowtoLAMP/MySQL MySQL].
|
||||
Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de base de donnée. Dans les exemples qui suivent, nous utiliseront [/HowtoLAMP/Apache Apache] et [/HowtoLAMP/MySQL MySQL].
|
||||
|
||||
Malheureusement, la version 2 du WebUI d'`icinga2` n'est pas dans Debian jessie à l'heure actuelle. Il est donc nécessaire soit d'utiliser les packages fournis par Icinga, ou alors d'utiliser la version dans Stretch.
|
||||
|
||||
Pour Stretch, il suffit de modifier `/etc/apt/sources.list` et de s'assurer d'avoir un fichier `/etc/apt/preferences` qui ressemble au suivant:
|
||||
|
||||
~~~
|
||||
Explanation: Debian jessie
|
||||
Package: *
|
||||
Pin: release o=Debian,n=jessie
|
||||
Pin-Priority: 990
|
||||
|
||||
Explanation: Debian stretch
|
||||
Package: *
|
||||
Pin: release o=Debian,n=stretch
|
||||
Pin-Priority: 2
|
||||
~~~
|
||||
|
||||
Une fois que cela est fait, on met à jour ses sources et on installe les packages nécessaires:
|
||||
Ici, MySQL va servir à 2 choses :
|
||||
* Sauvegarder les utilisateurs & groupes de l'interface Web
|
||||
* Contenir les informations de configuration d'`icinga2`, au status des hôtes et des services... qui sont mis à jour par le module `ido-mysql` d'icinga2
|
||||
|
||||
~~~
|
||||
# apt update
|
||||
# apt install icingaweb2
|
||||
# apt install icingaweb2 icinga2-ido-mysql
|
||||
~~~
|
||||
|
||||
Il est possible de rouler des commande à partir du WebUI directement. Pour cela, il faut ajouter le user qui roule le WebUI dans Apache au groupe `nagios`. Avec `apache2-mpm-itk`, cette étape devrait être superflue car le WebUI devrait déjà rouler sous le user `nagios`:
|
||||
*Note* : Le paquetage `icinga2-ido-mysql` fournit un assistant d'installation pour configurer une base de donnée et un utilisateur MySQL automatiquement. Si on le souhaite, il est également possible de le faire manuellement. Les paramètres sont alors à écrire dans `/etc/icinga2/features-available/ido-mysql.conf`
|
||||
|
||||
Une fois l'installation terminée, il est nécessaire d'activer le module `ido-mysql` d'icinga2:
|
||||
|
||||
~~~
|
||||
# icinga2 feature enable ido-mysql
|
||||
# service icinga2 restart
|
||||
~~~
|
||||
|
||||
Il est possible de lancer des commandes (planifier un check, downtimer une machine...) à partir du WebUI directement. Pour cela, il faut ajouter à l'utilisateur du serveur web au groupe `nagios`.
|
||||
|
||||
~~~
|
||||
# addgroup --system www-data nagios
|
||||
|
|
@ -101,52 +95,7 @@ Il est possible de rouler des commande à partir du WebUI directement. Pour cela
|
|||
# service icinga2 restart
|
||||
~~~
|
||||
|
||||
On ajoute maintenant un VHost apache dans `/etc/apache2/sites-available/icinga2.conf`:
|
||||
|
||||
~~~
|
||||
<VirtualHost *:80>
|
||||
|
||||
ServerName fqdn.org
|
||||
DocumentRoot /usr/share/icingaweb2/public
|
||||
|
||||
<Directory "/usr/share/icingaweb2/public">
|
||||
Options SymLinksIfOwnerMatch
|
||||
AllowOverride None
|
||||
|
||||
<IfModule mod_authz_core.c>
|
||||
Require all granted
|
||||
</IfModule>
|
||||
|
||||
SetEnv ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
|
||||
|
||||
EnableSendfile Off
|
||||
|
||||
<IfModule mod_rewrite.c>
|
||||
RewriteEngine on
|
||||
RewriteBase /
|
||||
RewriteCond %{REQUEST_FILENAME} -s [OR]
|
||||
RewriteCond %{REQUEST_FILENAME} -l [OR]
|
||||
RewriteCond %{REQUEST_FILENAME} -d
|
||||
RewriteRule ^.*$ - [NC,L]
|
||||
RewriteRule ^.*$ index.php [NC,L]
|
||||
</IfModule>
|
||||
|
||||
<IfModule !mod_rewrite.c>
|
||||
DirectoryIndex error_norewrite.html
|
||||
ErrorDocument 404 /error_norewrite.html
|
||||
</IfModule>
|
||||
</Directory>
|
||||
</VirtualHost>
|
||||
~~~
|
||||
|
||||
On active ensuite le VHost et on redémarre apache:
|
||||
|
||||
~~~
|
||||
# a2ensite icinga2.conf
|
||||
# service apache2 reload
|
||||
~~~
|
||||
|
||||
Pour continuer l'installation du WebUI, on visite le <http://fqdn.org/setup.> L'installeur va nous demander un token. On peut créer ce token avec la commande suivante:
|
||||
Pour continuer l'installation du WebUI, on visite le <http://example.org/icingaweb2/setup.> L'installeur va nous demander un token. On peut créer ce token avec la commande suivante:
|
||||
|
||||
~~~
|
||||
# icingacli setup token create
|
||||
|
|
@ -156,13 +105,13 @@ La prochaine étape de l'assistant vous demande quelles fonctions activer. Il es
|
|||
|
||||
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.
|
||||
|
||||
Icingaweb2 offre plusieurs backends d'authentification. Pour une grande organisation, il est préférable d'utiliser le backend LDAP. Pour quelques comptes, il est cependant plus simple d'utiliser le backend basé sur une base de donnée.
|
||||
`Icingaweb2` offre plusieurs backends d'authentification. Pour une grande organisation, il est préférable d'utiliser le backend LDAP. Pour quelques comptes, il est cependant plus simple d'utiliser le backend basé sur une base de donnée.
|
||||
|
||||
Si l'on choisi un backend base de donnée, il suffit de renter les informations d'authentification que l'on souhaite avoir. Le WebUI va ensuite nous aviser que la base de donnée n'existe pas encore et nous demander le mot de passe root pour en créer une pour nous. Encore une fois, il est possible de faire cela directement en ligne de commande avec MySQL.
|
||||
Si l'on choisi un backend base de données, il suffit de renter les informations d'authentification que l'on souhaite avoir. La WebUI va ensuite nous informer que la base de donnée n'existe pas encore et nous demander le mot de passe root pour en créer une pour nous. Encore une fois, il est possible de faire cela directement en ligne de commande avec MySQL.
|
||||
|
||||
Après avoir finalisé les informations pour l'authentification, il vous faudra donner au WebUI l'accès à la base de donnée créée précédemment pour icinga2. Les informations d'authentification se trouvent dans `/etc/icinga2/features-available/ido-mysql.conf`.
|
||||
Après avoir finalisé les informations pour l'authentification, il vous faudra donner au WebUI l'accès à la base de donnée créée précédemment pour icinga2. Si vous avez utilisé l'assitant de configuration du paquetage `icinga2-ido-mysql`, vous pourrez retrouver directement les informations d'authentification à MySQL utilisé par `icinga2` dans `/etc/icinga2/features-available/ido-mysql.conf`.
|
||||
|
||||
Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au <http://fqdn.org.>
|
||||
Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2.>
|
||||
|
||||
## Installation du client
|
||||
|
||||
|
|
@ -170,17 +119,20 @@ Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous conne
|
|||
|
||||
Par défaut, quand on installe `icinga2` sur une machine, le daemon est lancé et `icinga2` se met à surveiller le `localhost`. Pour cette documentation, nous allons monter une architecture de surveillance de type [#Configurationencluster "configuration en cluster"]. Cela va nous permettre de pouvoir centraliser la configuration à un seul endroit et de la gérer à travers Git.
|
||||
|
||||
Attention! La seule commande `icinga2 node <paramètre>` que l'on devrait rouler avec ce type de configuration est `icinga2 node wizard` au tout début du processus d'installation.
|
||||
Attention! La seule commande `icinga2 node <paramètre>` que l'on devrait exécuter avec ce type de configuration est `icinga2 node wizard` au tout début du processus d'installation.
|
||||
|
||||
Malgré les apparences, `icinga2 node update-config` ou encore `icinga2 node add` s'appliquent à une configuration de type locale. Il ne faut donc pas les utiliser en cluster!
|
||||
Malgré les apparences, `icinga2 node update-config` ou encore `icinga2 node add` s'appliquent à une configuration de type locale. De plus, ces commandes sont aussi dépréciées.
|
||||
|
||||
On commence donc par installer `icinga2`:
|
||||
|
||||
~~~
|
||||
# apt -t jessie-backports install icinga2 icinga2-ido-mysql
|
||||
# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
|
||||
# echo 'deb http://packages.icinga.com/debian icinga-jessie main' >/etc/apt/sources.list.d/icinga.list
|
||||
# apt update
|
||||
# apt install icinga2
|
||||
~~~
|
||||
|
||||
Une fois que cela est fait, on roule l'assistant de configuration:
|
||||
Une fois que cela est fait, on lance l'assistant de configuration:
|
||||
|
||||
~~~
|
||||
# icinga2 node wizard
|
||||
|
|
@ -191,21 +143,19 @@ L'assistant nous pose plusieurs questions. On y répond de la manière suivante:
|
|||
~~~
|
||||
Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: y
|
||||
Starting the Node setup routine...
|
||||
Please specifiy the common name (CN) [icinga2-slave1]:
|
||||
Please specifiy the common name (CN) [icinga2-client1]:
|
||||
Please specify the master endpoint(s) this node should connect to:
|
||||
Master Common Name (CN from your master setup): icinga2-master
|
||||
Do you want to establish a connection to the master from this node? [Y/n]: y
|
||||
Please fill out the master connection information:
|
||||
Master endpoint host (Your master's IP address or FQDN): 192.168.4.229
|
||||
Master endpoint port [5665]:
|
||||
Master endpoint port [5665]:
|
||||
Add more master endpoints? [y/N]: n
|
||||
Please specify the master connection for CSR auto-signing (defaults to master endpoint host):
|
||||
Host [192.168.4.229]:
|
||||
Port [5665]:
|
||||
warning/cli: Backup file '/etc/icinga2/pki/icinga2-slave1.key.orig' already exists. Skipping backup.
|
||||
warning/cli: Backup file '/etc/icinga2/pki/icinga2-slave1.crt.orig' already exists. Skipping backup.
|
||||
information/base: Writing private key to '/etc/icinga2/pki/icinga2-slave1.key'.
|
||||
information/base: Writing X509 certificate to '/etc/icinga2/pki/icinga2-slave1.crt'.
|
||||
Host [192.168.4.229]:
|
||||
Port [5665]:
|
||||
information/base: Writing private key to '/etc/icinga2/pki/icinga2-client1.key'.
|
||||
information/base: Writing X509 certificate to '/etc/icinga2/pki/icinga2-client1.crt'.
|
||||
information/cli: Fetching public certificate from master (192.168.4.229, 5665):
|
||||
|
||||
Certificate information:
|
||||
|
|
@ -214,26 +164,25 @@ Certificate information:
|
|||
Issuer: CN = Icinga CA
|
||||
Valid From: Aug 15 21:03:54 2016 GMT
|
||||
Valid Until: Aug 12 21:03:54 2031 GMT
|
||||
Fingerprint: D6 6F 56 55 3B 73 16 45 D5 08 F6 FB CE A6 2A 14 F5 24 05 11
|
||||
Fingerprint: D6 6F 56 55 3B 73 16 45 D5 08 F6 FB CE A6 2A 14 F5 24 05 11
|
||||
|
||||
Is this information correct? [y/N]: y
|
||||
information/cli: Received trusted master certificate.
|
||||
|
||||
Please specify the request ticket generated on your Icinga 2 master.
|
||||
(Hint: # icinga2 pki ticket --cn 'icinga2-slave1'): 4891c5c4c132908f2794d0ed347c9fbf204491aa
|
||||
(Hint: # icinga2 pki ticket --cn 'icinga2-sclient1'): 4891c5c4c132908f2794d0ed347c9fbf204491aa
|
||||
information/cli: Requesting certificate with ticket '4891c5c4c132908f2794d0ed347c9fbf204491aa'.
|
||||
|
||||
warning/cli: Backup file '/etc/icinga2/pki/icinga2-slave1.crt.orig' already exists. Skipping backup.
|
||||
information/cli: Writing signed certificate to file '/etc/icinga2/pki/icinga2-slave1.crt'.
|
||||
information/cli: Writing signed certificate to file '/etc/icinga2/pki/icinga2-client1.crt'.
|
||||
information/cli: Writing CA certificate to file '/etc/icinga2/pki/ca.crt'.
|
||||
Please specify the API bind host/port (optional):
|
||||
Bind Host []:
|
||||
Bind Port []:
|
||||
Bind Host []:
|
||||
Bind Port []:
|
||||
Accept config from master? [y/N]: y
|
||||
Accept commands from master? [y/N]: n
|
||||
~~~
|
||||
|
||||
À noter qu'à l'étape où l'assistant demande le ticket généré sur le master, il faut rouler la commande suivante sur le master et copier l'output dans l'assistant:
|
||||
À noter qu'à l'étape où l'assistant demande le ticket généré sur le master, il faut exécuter la commande suivante sur le master et copier l'output dans l'assistant:
|
||||
|
||||
~~~
|
||||
icinga2 pki ticket --cn '<nom du client>'
|
||||
|
|
@ -244,13 +193,13 @@ Si client reconnaît maintenant le master, il est nécessaire de configurer le m
|
|||
~~~
|
||||
[...]
|
||||
|
||||
object Endpoint "icinga2-slave1" {
|
||||
object Endpoint "icinga2-client1" {
|
||||
host = "<adresse ip du client>"
|
||||
}
|
||||
|
||||
object Zone "icinga2-slave1" {
|
||||
endpoints = [ "icinga2-slave1" ]
|
||||
parent = "master"
|
||||
object Zone "icinga2-client1" {
|
||||
endpoints = [ "icinga2-sclient1" ]
|
||||
parent = "master"
|
||||
}
|
||||
~~~
|
||||
|
||||
|
|
@ -263,13 +212,13 @@ Avec le type de configuration que l'on a choisi, les fichiers de configuration s
|
|||
Nous allons donc ajouter nos tests sur le master dans `zones.d`, le dossier prévu à cet effet. On commence par y créer un nouveau dossier du nom du client que l'on souhaite configurer:
|
||||
|
||||
~~~
|
||||
# mkdir /etc/icinga2/zones.d/icinga2-slave1
|
||||
# mkdir /etc/icinga2/zones.d/icinga2-client1
|
||||
~~~
|
||||
|
||||
Dans ce dossier, on crée un fichier nommé `hosts.conf` qui va nous servir à définir un nouvel objet de type `Host`. Cet objet va nous permettre par la suite de lier d'autres types d'objets à notre nouveau client:
|
||||
|
||||
~~~
|
||||
object Host "icinga2-slave1" {
|
||||
object Host "icinga2-client1" {
|
||||
check_command = "hostalive"
|
||||
address = "<adresse ip du client>"
|
||||
zone = "master"
|
||||
|
|
@ -280,13 +229,13 @@ On peut maintenant ajouter de nouveaux tests dans `services.conf`, des objets de
|
|||
|
||||
~~~
|
||||
object Service "disk" {
|
||||
host_name = "icinga2-slave1"
|
||||
host_name = "icinga2-sclient1"
|
||||
|
||||
check_command = "disk"
|
||||
}
|
||||
|
||||
object Service "ssh" {
|
||||
host_name = "icinga2-slave1"
|
||||
host_name = "icinga2-sclient1"
|
||||
|
||||
check_command = "ssh"
|
||||
}
|
||||
|
|
@ -310,12 +259,15 @@ Les fichiers de configuration se trouvent dans `/etc/icinga2`. Tous les fichiers
|
|||
|
||||
La configuration d'icinga2 se base principalement sur des objets de types différents. Par exemple, l'objet `Service` sert à définir un service à vérifier sur une machine, alors que l'objet `Host` définit un nouveau client. On peut retrouver une description détaillée de tous les objets [ici](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
|
||||
|
||||
En général, l'emplacement des objets n'est pas réellement important. Dans l'exemple plus haut, on aurait ainsi pu ajouter l'objet `Host` dans le fichier `/etc/icinga2/zones.d/icinga2-slave1/mega_foobar.conf` au lieu de `/etc/icinga2/zones.d/icinga2-slave1/hosts.conf`. C'est cependant un bonne pratique de séparer clairement ses différents objets en fichiers nommés de manière claire.
|
||||
En général, l'emplacement des objets n'est pas réellement important. Dans l'exemple plus haut, on aurait ainsi pu ajouter l'objet `Host` dans le fichier `/etc/icinga2/zones.d/icinga2-client1/foo_bar.conf` au lieu de `/etc/icinga2/zones.d/icinga2-client1/hosts.conf`. C'est cependant un bonne pratique de séparer clairement ses différents objets en fichiers nommés de manière claire.
|
||||
|
||||
|
||||
### init.conf
|
||||
|
||||
Le premier fichier à être lu au démarrage du daemon. Il sert à définir sous quel groupe et quel user le daemon est lancé.
|
||||
|
||||
*Note* : Sous Debian, icinga2 fonctionne sous l'utilisateur et le groupe `nagios`
|
||||
|
||||
### icinga2.conf
|
||||
|
||||
Le fichier de configuration principal. Il sert surtout à définir les fichiers de configuration qui seront lus, comme `/features-enabled/*` par exemple. Ce fichier est le second à être lu au démarrage du daemon.
|
||||
|
|
@ -353,4 +305,11 @@ Ce dossier regroupe les configurations de services sur le master et les configur
|
|||
|
||||
### repository.d et zones.d
|
||||
|
||||
`repository.d` regroupe les configurations des clients lors d'une synchronisation de type locale. À l'inverse, pour une configuration de type cluster, les fichiers se retrouveraient plutôt dans le dossier `zones.d`.
|
||||
`repository.d` regroupe les configurations des clients lors d'une synchronisation de type locale. À l'inverse, pour une configuration de type cluster, les fichiers se retrouveraient plutôt dans le dossier `zones.d`.
|
||||
|
||||
## Plomberie
|
||||
|
||||
### Dossiers par défaut d'icinga2
|
||||
`/etc/icinga2` Dossier des fichiers de configuration
|
||||
`/usr/share/icinga2/include` Dossier des templates & commandes par défaut
|
||||
`/var/lib/icinga2` Dossier de "travail" d'`icinga2`, contient la CA, les logs cluster, la configuration chargée, un fichier dump de l'état du cluster
|
||||
|
|
|
|||
Loading…
Reference in a new issue