« LINUX:Systemd-Paramétrage personnalisé » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (3 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 20 : | Ligne 20 : | ||
=Exemples= | |||
J'ai été forcé de passer à cette étape dans le cadre de la suite Wazuh". Il faut dire que ma machine est vielle et poussive. J'ai mis les services suivants sur la même machine: | |||
* wazuh-manager.service | |||
* filebeat.service | |||
* wazuh-indexer.service | |||
* wazuh-dashboard | |||
Les plus gros problèmes surviennent au démarrage de la machine, d'autre de nuit. | |||
Cette machine héberge de nombreux services dont certains très gourmand en ressources et en temps de démarrage. Comme ils veulent tous démarrer en même temps, certains dépassent le temps imparti ("timeout"). | |||
==FILEBEAT - redémarrage automatique== | |||
Ce service est programmé pour redémarrer automatiquement en cas d'arrêt intempestif mais si ces essais de démarrages infructueux sont trop nombreux et trop rapprochés, ce système se bloque et le service ne démarre plus sauf par quelques opérations manuelles. | |||
Pour résoudre ce problème, il existe une option qui permet d'allonger la durée entre deux essais de démarrage. On crée un fichier dans le répertoire "/etc/systemd/system/filebeat.service.d" nouvellement créé, que l'on nomme "restart.conf". Voici son contenu: | |||
---- | |||
[Service] | |||
RestartSec=5s | |||
---- | |||
Nous l'avons mis à 5 secondes, à ajuster à l'avenir. | |||
==FILEBEAT - temps de démarrage== | |||
Le second problème est le temps de démarrage en liaison avec les autres modules la suite de Wazuh ("timeout"). | |||
Pour résoudre ce problème mineur dans ce cas, nous avons augmenté le temps limite de démarrage en créant dans ce même répertoire, le fichier que l'on a nommé "startup-timeout.conf". Voici son contenu: | |||
---- | |||
[Service] | |||
TimeoutStartSec=600 | |||
---- | |||
Nous l'avons mis à 10 minutes, à ajuster à l'avenir. | |||
Remarquons que les contenus de ces deux fichiers peuvent être réunis en un seul. | |||
==WAZUH-INDEXER - temps de démarrage== | |||
Ce service est très long à se mettre en route et demande beaucoup de ressources; quand il est lancé, la machine se calme. On a donc un problème de "timeout"; le service ne démarre pas. On le résout comme ci-dessus. | |||
On crée un fichier dans le répertoire "/etc/systemd/system/wazuh-indexer.service.d" nouvellement créé, que l'on nomme "startup-timeout.conf". Voici son contenu: | |||
---- | |||
[Service] | |||
TimeoutStartSec=600 | |||
---- | |||
Nous l'avons mis à 10 minutes, à ajuster à l'avenir. | |||
==WAZUH-MANAGER - temps de démarrage== | |||
Ce service a les mêmes inconvénients que "Wazuh-indexer" mais en plus dès qu'il est lancé, il commence par faire une vérification d"intégrité du système. Ce processus demande beaucoup de ressources d'accès disque et met à mal tout autre service qui veut démarrer; dans notre cas, il rentre en conflit avec "Wazuh-indexer". | |||
Le premier problème sera résolu comme ci-dessus en créant un fichier dans le répertoire "/etc/systemd/system/wazuh-manager.service.d" nouvellement créé, que l'on nomme "startup-timeout.conf". Voici son contenu: | |||
---- | |||
[Service] | |||
TimeoutStartSec=600 | |||
---- | |||
Nous l'avons mis à 10 minutes, à ajuster à l'avenir. | |||
==WAZUH-MANAGER - ordre de démarrage== | |||
Pour le second problème, on va privilégier le démarrage de "Wazuh-indexer" avant le lancement de "Wazuh-manager". On crée dans le même répertoire, le fichier que l'on nomme "after.conf". Voici son contenu: | |||
---- | |||
[Unit] | |||
After=network.target network-online.target '''wazuh-indexer.service''' | |||
---- | |||
Dans la configuration de base de ce service, cette option avait déjà deux valeurs. Nous avons repris celles-ci auquel on a ajouté le service "wazuh-indexer.service" que l'on veut qu'il démarre avant. | |||
==WAZUH-MANAGER - limiter la mémoire virtuelle== | |||
Un autre problème est apparu; le service "systemd-oomd.service" s'est mis en route. Régulièrement il passe en revue les différents processus et, dans mon cas, si la mémoire virtuelle dépasse 1G, le processus est tué. | |||
Pour éviter ce problème sur le service "wazuh-manager.service", j'ai ajouté le paramètre "LimitAS" qui limite la mémoire virtuelle à 1G. | |||
On crée dans le même répertoire, le fichier que l'on nomme "limitemv.conf". Voici son contenu: | |||
---- | |||
[Service] | |||
LimitAS=1000000000 | |||
---- | |||
Remarquons qu'ici aussi les contenus de ces trois fichiers peuvent être réunis en un seul. | |||