LINUX:Systemd-Paramétrage personnalisé
But
Chaque service géré par Systemd nécessite un paramétrage spécifique fourni par la distribution. Dans certains cas, on est amené à en modifier ou ajouter certains.
Méthode
Il est toujours déconseillé de modifier directement un fichier de la configuration d'un service fourni avec la distribution car en cas de mise-à-jour de ce fichier par la distribution, soit vos modifications sont perdues, soit la mise-à-jour, souvent nécessaire, n'est pas effectuée.
Nous concentrerons sur les services lancés au niveau global (system). Leurs définitions se trouvent dans le répertoire "/usr/lib/systemd/system" et un service activé consiste, dans la très grande majorité des cas, à effectuer un lien symbolique vers le fichier se trouvant dans le répertoire de référence "/usr/lib/systemd/system". Ce lien se retrouve sous le répertoire "/etc/systemd/system".
Il existe une façon de contourner ce problème. Elle nécessite quelques étapes:
- En premier lieu, on crée un répertoire du nom du service auquel on ajoute l'extension ".d" sous le répertoire "/etc/systemd/system". Par exemple, pour le service "wazuh-manager.service" on crée le sous-répertoire ""/etc/systemd/system/wazuh-manager.service.d".
- En second lieu, on crée un fichier au nom évocateur de votre cru mais dont l'extension est ".conf" dans ce répertoire créé ci-dessus.
- Dans ce fichier, on ajoute la section concernée par l'option à adapter; elle est reconnaissable par un mot mis entre crochets ("[...]"). Dans cette section, on ajoute la ou les options à adapter suivie, après le signe égal ("="), sa valeur.
- Enfin il faut activer cette modification dans "Systemd" avec la commande déjà vue:
systemctl daemon-reload
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.