• [^] # Re: Intérêt sur un serveur ?

    Posté par . En réponse à la dépêche systemd pour les administrateurs, parties 3, 4 et 5. Évalué à 8.

    J'utilise systemd sur mon routeur, un Bubba 3 avec une archlinux arm customisée. Systemd y était par défaut.

    Ce qui m'a plu jusqu'ici, et qui me ferait choisir systemd pour un futur serveur:
    - Lancer un service en chroot est facile (fait avec Nginx)
    - Fichiers de service relativement* simple à écrire (*: passée la phase d'apprentissage)
    - Monitoring de l'état du système, avec un listing des services actifs plus propre que ps
    - Possibilité de préparer le système pour restreindre les accès d'un service (ex: /tmp privée, restriction d'accès aux répertoires, préparation d'un espace dans /run, ...)
    - Meilleure récupération des logs et du stdout/stderr notamment lors du démarrage (bien que je ne sois vraiment pas copain avec journalctl, je suis encore paumé dans les options)

    Au final, je trouve systemd plus simple et plus complet.

    -- Blabla supplémentaire --

    Le Bubba 3 est livré d'origine avec une Debian un peu trafiquée qui utilisait des scripts d'init "habituels" (je n'ose pas parler de SysV init car je ne suis pas sûr). À l'époque de la Debian, j'avais voulu ajouter un service de terminal par web (anyterm). Et entre la configuration d'Apache et l'architecture pas claire des scripts d'inits (peut être à cause de la différence avec Arch) j'avais préféré lancer le service à la main quand je redémarrais le serveur au risque de l'oublier. Face à ça, lancer Nginx en chroot en quelques lignes de config, on se dit "cool".

    Pareil pour le lancement d'un service Flask avec Gunicorn. J'ai mis un peu de temps à avoir une config stable à cause du fichier de PID qui n'avait pas les droits d'accès au dossier jusqu'à ce que je tombe sur l'option RuntimeDirectory (très mal documentée). Il y avait aussi le problème qu'en forkant, Gunicorn n'héritait pas du contexte pour stdout/stderr et je perdais des logs (corrigé par une option dans Gunicorn).

    Au moment de Shellshock, j'ai trouvé pratique de pouvoir avoir un œil sur tous les services en cours, y compris les programmes lancés par l'(les) utilisateur(s) (admin en l'occurence).

    Sur mon routeur, il y a une petite LED. Avec un petit script Python et DBus, ça me permet de changer la couleur de la LED selon que le système est sain ou qu'un service est mort. Pratique.

    Dans les moins, il y a la configuration à la main qui est quasi-impossible si systemd n'est pas accessible, par exemple pour configurer une carte SD qui doit avoir une configuration réseau particulière dès le démarrage et sans autre accès console (cf. RaspberryPi et autre Cubietrucks), et la configuration explosée dans plein de fichiers avec des syntaxes différentes (hostname.conf, vconsole.conf, ...)

    Et aussi ce qui m'a fait détester systemd pendant longtemps : je suis pas du tout fan des commandes systemctl et journalctl qui sont AMHA trop longues à taper et trop confuses (pourquoi systemctl help ça ne marche pas alors qu'on doit taper systemctl status et pourquoi journalctl sans option commence au début du journal, genre il y a deux ans, et pas aux entrées les plus récentes ?)