Je débarque et je me mets ça de côté. Non, je n'ai pas lu la série « systemd for Administrators » ni les pages de manuel : il faut y aller doucement. :D

http://linuxfr.org/news/systemd-pour-les-administrateurs-partie-1-et-2 :
    Partie 1 : vérifier le démarrage des services
-> ok, cool, mais ça n'empêche pas de devoir aller gratter dans les logs ... so ... un grep dans les logs et j'aurais su pour ntpd ... Quelle différence avec status + grep ?

    Partie 2 : quels services possèdent quels processus ?
-> vraie fonctionnalité. services -> cgroups -> processus. cgroup nommé selon service donc pas d'échappatoire


http://linuxfr.org/news/systemd-pour-les-administrateurs-parties-3-4-et-5 :
    « Systemd fournit des éléments de compatibilité avec ces scripts shell mais, en raison des points négatifs invoqués précédemment, il est recommandé d'installer des fichiers de service systemd pour l'ensemble des démons installés. De plus, en contraste avec les scripts d'init SysV qui ont besoin d'être adaptés à la distribution, les fichiers de service systemd sont compatibles avec n'importe quelle distribution exécutant systemd (ce qui arrive de plus en plus fréquemment ces derniers temps…). »

    « Systemd vient à la rescousse: avec systemctl kill, vous pouvez facilement envoyer un signal à tous les processus d'un service. »

   « Masquer un service. Un mécanisme similaire n'existe pas (officiellement) pour les systèmes SysV. Néanmoins, il existe quelques trucs officieux comme éditer le script d'init et en indiquant un exit 0 au début ou bien encore en enlevant le bit exécutable. Néanmoins ces solutions présentent différents inconvénients comme le fait qu'elles interfèrent avec ce que le responsable de paquet a prévu ».
  -> Si un logiciel ne fournit pas un moyen simple de le désactiver comme un fichier dans /etc/default, c'est peut-être qu'il faut râler auprès des dev's/mainteneurs du logiciel/paquet. Pour limiter les interférences (et donc les réactivations surprises), on a aussi dpkg-statoverride.

http://linuxfr.org/news/%C3%A9volutions-techniques-de-systemd
Autofs :
  « Pour accélérer cela, Harald Hoyer a eu l’idée d’utiliser le système autofs en mode direct. De la même façon que pour les sockets, autofs permet de monter un pseudo système de fichiers à la place du système réel, et de ne basculer sur le vrai système qu’au moment où un accès est fait. Comme pour la création de sockets, le montage du pseudo système de fichiers est quasiment instantané.

Si un accès est fait alors que le système de fichiers n’est pas prêt (fsck en cours, par exemple), alors le noyau bloque la requête (et celui qui l’a faite) jusqu’à ce que le système de fichiers soit disponible.

Pour la racine (« / »), cela ne présente pas d’intérêt ; mais pour les grosses volumétries qui peuvent être montées sur « /home », ou pour des partitions de données qui ne sont pas nécessaires au démarrage du système, cela présente un gain important. »

« Démarrer moins de choses
Ce principe permet également de faire du démarrage à la demande. Si personne ne s’adresse à un service, il est inutile de le lancer. À l’instar d’inetd (et de son remplaçant xinetd) ; nous pouvons attendre qu’un service ait reçu une demande de connexion pour le lancer. Pour les postes de travail qui impriment trois pages par semaine, CUPS est un bon candidat. Tant qu’aucune impression n’est lancée, aucune donnée n’arrive et le service CUPS n’a pas de raison d’être démarré. »
  -> Cette démarche est pertinente pour quelques services comme CUPS mais tout service ouvert sur l'extérieur est condamné à subir des scans de ports. Même en IPv6 car utilisation d'IP mémorisables ou qui ont un sens sémantique. Donc les services seront quand même lancés pour rien. L'approche spawn de démons n'est pas forcément idéale non plus en terme d'usage des ressources.

Clarification des initscripts :
« Pour chaque service, il est possible de régler de nombreux paramètres : limites, répertoire racine (chroot), umask, priorité, paramètre « OOM killer » (out of memory), les classes et les priorités d’ordonnancement et d’entrées‐sorties, l’affinité processeur, l’utilisateur, les groupes, les répertoires accessibles et les modes d’accès, les capacités, le répertoire temporaire, le réglage des cgroups…

Les flux stdout et stderr peuvent être redirigés vers le service de journalisation, vers « /dev/kmsg », vers un terminal ou vers un fichier. »
  -> tout ça, plus le fait de dégager start-stop-daemon et autres magouilles, est un vrai plus, c'est indéniable.

Ce qui m'ennuie encore à l'heure actuelle avec systemd, c'est :
  * organiser la transition. Adapter les paquets, adapter (autoformer, on dit) les adminsys, essuyer les plâtres, ... Non parce que si c'est pour avoir systemd en mode de compatibilité avec les scripts sysV uhuhu quoi. Le chemin qui reste à parcourir est long.

  * le périmètre de responsabilités de systemd est trop grand (mais au moins en accord avec son nom :D) : init, config résal, config hostname/locale/time, udev/dbus, ... Si ça c'est pas du SPOF ... On est loin des principes UNIX/KISS quand même. Quel inpact cela aura-t-il sur la fiabilité et la sécurité des systèmes ? C'est encore une grande inconnue.

  * Lennart Poettering c'est PulseAudio (dont je ne pense pas le plus grand mal mais pas le plus grand bien non plus) et Avahi (c'est peut-être plus Zeroconf en lui même sur lequel il faudrait taper plutôt que sur une implé en particulier) ... Ça sonne un peu attaque ad-hominem m'enfin bon ...