Je trouve que le nouveau systeme est plutot pas mal. Ce qui fait chier, c'est de changer. C'est pas inintéressant mais c'est juste que l'admin sys a en général beuacoup d'autres chats à fouetter. Réapprendre les fonctions de base du système, c'est du temps en moins pour les autres projets. my 2 cent.... On 14/12/2016 15:15, Thomas Constans wrote:

Franchement, journald et journalctl, avec la possibilité de filtrer par priorité, par service, de récupérer les événements sur une période de temps donnée, c'est plutôt pas mal.

my 1.3¢

Le 13/12/2016 à 17:35, frsag@jack.fr.eu.org a écrit :

...

Ouais ou Debian hein, c'est bien aussi ..

On 13/12/2016 17:11, remy.dernat wrote:

...

Il te reste BSD et son init ;) https://www.textplain.net/blog/2015/problems-with-systemd-and-why-i-like-bsd...

-------- Message d'origine -------- De : Sébastien FOUTREL <sfoutrel@gmail.com> Date : 13/12/2016 13:54 (GMT+01:00) À : Jonathan Leroy <jonathan@unsigned.inikup.com> Cc : French SysAdmin Group <frsag@frsag.org> Objet : Re: [FRsAG] systemd vs les adminsys

Aahhaha. Et la gestion des logs, et la gestion des montages et surement d'autres choses :DRegarde aussi ce qui se passe quand tu veux demarrer un service et que systemd ouvre une socket reseau avant meme que le demon soit lancé :D Essaye de faire un swapoff -a et regarde ce qu'il se passe au bout de quelques secondes ou minutes en fonction de ce que va trapper systemd.Malheureusement comme dit plus tot, systemd c'est parti d'un bon sentiment mais si on avait voulu bosser sur macosX on aurait fait ce choix. Dorenavant on a plus vraiment le choix... Le 9 décembre 2016 à 15:27, Jonathan Leroy <jonathan@unsigned.inikup.com> a écrit : Le 9 décembre 2016 à 14:59, Dominique Rousseau <d.rousseau@nnx.com> a écrit :

...

C'est ça le vrai probleme de systemd sur des serveurs, c'est que ça a un coté bulldozer, qui remplace les outils de configuration reseau, le collecteur de logs, etc. Systemd arrive avec tout un ecosysteme qui fait qu'on a plus "un Unix" (un peu comme MacosX), avec des fichiers plats editables et lisibles par un humain adminsys, des fichiers logs qu'on peut grep/awk/..., des noms d'interface reseau deterministes, etc.

Mais la plupart de ces fonctionnalités sont désactivables, voire

désactivées par défaut.

C'est le cas par défaut sous Debian, qui n'utilise que la partie

"init" de Systemd.

--

Jonathan Leroy.

_______________________________________________

Liste de diffusion du FRsAG

http://www.frsag.org/

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

Mais avant, tu devais faire cet apprentissage pour chacune des grandes famille de distro. Maintenant, tu l'apprends une fois, et tu passe sur toutes les distro! Je trouve ça beau.

Et petit à petit, on t'enlève le choix. À ce rythme là on pourra bienôt plus parler de distribution, justement. -- Kevin Lemonnier PGP Fingerprint : 89A5 2283 04A0 E6E9 0111

Le 14/12/2016 17:39, Alexis Lameire a écrit :

Bonjour, Je ne suis pas un fan boy de systemd, je reste néanmoins plutôt satisfait du projet et comme cité plus haut : - journalctl qui est un délice à utiliser Le 14/12/2016 15:15, Thomas Constans a écrit :

...

Franchement, journald et journalctl, avec la possibilité de filtrer par priorité, par service, de récupérer les événements sur une période de temps donnée, c'est plutôt pas mal.

C'est vrai, avant on avait un outil performant, robuste et léger qui s'appelait grep pour faire ça. Ensuite, pour ce qui est du délice... On parle bien du soft qui croit bon juger d'adapter sa sortie à la taille de ton écran en découpant tes lignes façon crado au milieu du message ?

- les logs binaire et le check des logs qui permettent d'améliorer la protection contre les tentatives d'éffacement des traces

Ils sont chiffrés tes logs ? Parce que modifier des binaires ça se fait pas trop difficilement hein.... C'est plus compliqué qu'avec un sed, certes, mais ça se fait.

- l'écriture de service facilité dans bien des cas

Ça, je suis d'accord. Le problème c'est que dès que tu n'es pas dans un cas "courant", c'est impossible et on a des setups ou ton applicatif peut marcher dans un cas et pas dans l'autre. Exemple : le fait de lancer une appli en debug avec l'option "Restart=on-failure" qui fait bander les admins trop flemmards pour installer monit et les devs trop peu compétents pour faire des softs stables en prod. J'ai un peu la flemme de rechercher le ticket, mais en gros : pour systemd, une "failure" de ton service, c'est quand il écrit sur stderr. Ce qui peut correspondre à du warning ou du debug, comme communément admit par tous les devs / sysadmins depuis des dizaines d'années. Dans mes souvenirs, le ticket a été clos en "wontfix" (et plus bas tu parles de discuter avec ces personnes...)

mais aussi : - le fait de pouvoir écrire des services générique (genre openvpn) et d'en lancer plusieurs instance - une vrai gestion des dépendances entre service, ce qui n'était pas toujours évidant.

Après, il faut reconaitre que le suivis des anomalies par le projet et la politique de tests ne sont pas bon. Mais pour ces points il y a des solutions, les mêmes qui ont toujours fait vivre les projets libre : - faire entendre vos voix de façon constructive, en proposent des patch - si ca ne marche pas, forker (surtout qu'avec git c'est facile merde) et monter sa communauté plus à l'écoute des demanes - développer son propre système d'init

Le truc, c'est que ça existe. Depuis des années. Tiens, un peu de lecture : http://blog.darknedgy.net/technology/2015/09/05/0/

De plus, la plupart des distribution fonctionnent de manière à écouté la communauté, si vous ne souhaitez pas que systemd soit utilisé par défaut ou qu'un autre système d'init le soit à sa place, je vous enjoint donc à communiquer de façon constructive vos doléance aux représentant de votre distribution préféré

Ça a été fait côté Debian. La killer feature qui a été retenue pour systemd comparé à d'autres systèmes d'init proposant les mêmes fonctionnalités (du moins, pour la gestion du démarrage), c'est le support de Gnome. Le même Gnome dont il est discuté l'abandon (au moins en tant que desktop par défaut) à chaque nouvelle version de Debian depuis au moins Lenny. Et ça, niveau discussion avec ta communauté, c'est plutôt moche. Surtout compte tenu du fait que systemd était une "technology preview" dans Wheezy et est passé "default" juste après dans Jessie. Et si la discussion avait été possible, on aurait pas eu un départ massif de développeurs pour forker le projet (Devuan). -- Benjamin Boudoir

Le 15/12/2016 09:43, Jonathan Tremesaygues a écrit :

On 12/14/2016 06:44 PM, Benjamin Boudoir wrote:

...

Ça, je suis d'accord. Le problème c'est que dès que tu n'es pas dans un cas "courant", c'est impossible et on a des setups ou ton applicatif peut marcher dans un cas et pas dans l'autre. Exemple : le fait de lancer une appli en debug avec l'option "Restart=on-failure" qui fait bander les admins trop flemmards pour installer monit et les devs trop peu compétents pour faire des softs stables en prod. J'ai un peu la flemme de rechercher le ticket, mais en gros : pour systemd, une "failure" de ton service, c'est quand il écrit sur stderr. Ce qui peut correspondre à du warning ou du debug, comme communément admit par tous les devs / sysadmins depuis des dizaines d'années. Dans mes souvenirs, le ticket a été clos en "wontfix" (et plus bas tu parles de discuter avec ces personnes...) Tu as un lien vers le ticket ou c'est juste du FUD ? Parce que la doc est assez claire sur ce qui provoque un restart on failure, est il n'est fait aucune mention de stderr : «If set to on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementioned four signals), when an operation (such as service reload) times out, and when the configured watchdog timeout is triggered.» (https://www.freedesktop.org/software/systemd/man/systemd.service.html [1])

Normalement c'est pas du FUD : si je me le suis noté, c'est que je l'ai vu en prod. Cependant, effectivement, je trouve pas de trace de ça et j'ai pas réussi à le reproduire sur une Jessie à jour alors je vais revenir dessus. Pour le ticket, je confond peut-être avec un autre (j'étais déjà pas sûr hier, d'où le "dans mes souvenirs") ou peut-être que j'ai juste croisé une réponse acerbe sur une ML de la part d'un dev. En revanche, des cas de setup ou le boot marche pas comme il faut, j'en ai déjà donné une bonne pelletée dans un mail précédent. -- Benjamin Boudoir

On ven., déc. 16, 2016 at 11:01 , Lunar <lunar@anargeek.net> wrote:

Benjamin Boudoir:

...

Et si la discussion avait été possible, on aurait pas eu un départ massif de développeurs pour forker le projet (Devuan).

Tu as des chiffres là-dessus ?

Je vous propose un point godwin special frsag : systemd ! et on passe à autre chose ?

- journalctl qui est un délice à utiliser - les logs binaire et le check des logs qui permettent d'améliorer la protection contre les tentatives d'éffacement des traces

Je comprend le point de vue, mais je ne suis pas d'accord, je trouve ça assez désagréable à utiliser comparé à ce qu'on avait avant. Peut-être un manque d'habitude ..

- l'écriture de service facilité dans bien des cas

mais aussi : - le fait de pouvoir écrire des services générique (genre openvpn) et d'en lancer plusieurs instance - une vrai gestion des dépendances entre service, ce qui n'était pas toujours évidant.

Certes, venant de debian ça se comprend. En perso je suis un utilisateur de Gentoo, et c'est des choses qu'OpenRC fait très bien depuis très longtemps, donc là encore l'interêt de systemd m'échappe.

Après, il faut reconaitre que le suivis des anomalies par le projet et la politique de tests ne sont pas bon. Mais pour ces points il y a des solutions, les mêmes qui ont toujours fait vivre les projets libre : - faire entendre vos voix de façon constructive, en proposent des patch - si ca ne marche pas, forker (surtout qu'avec git c'est facile merde) et monter sa communauté plus à l'écoute des demanes - développer son propre système d'init

Ben, justement, c'est bien ce qu'on reproche à ce qu'il se passe en ce moment, si tu n'utilises pas systemd ça devient difficile de faire tourner plein de choses. Moi je ne vais pas pleurer sur le manque de compat avec gnome ou KDE, pour prendre un exemple parlant, mais il y a des gens qui les utilisent. Si c'était si simple d'utiliser autre chose le fait que le défaut sois systemd me génèrais beaucoup moins :)

De plus, la plupart des distribution fonctionnent de manière à écouté la communauté, si vous ne souhaitez pas que systemd soit utilisé par défaut ou qu'un autre système d'init le soit à sa place, je vous enjoint donc à communiquer de façon constructive vos doléance aux représentant de votre distribution préféré

Comme mentionné, je n'ai pas ce problème sur la mienne, mais tout à fait. Je ne pense pas que ça manque cela dit, que les gens soient pour ou contre on les entend bien je trouve. -- Kevin Lemonnier PGP Fingerprint : 89A5 2283 04A0 E6E9 0111

Le 14/12/2016 17:42, Mrjk a écrit :

Sur ce point ci, je vais mettre en avant l'idée de convergence plutôt que de parler de l'implémentation technique de systemd en tant que tel.

Ma réponse: Oui, et non. Je ne sais pas si le parallèle est juste, mais essayons: Mettons que tu remettes en cause les GNU Coreutils, as-tu une alternative viable équivalente sur ta distro préférée? (je ne compte pas les busybox, et dérivés ...) Je ne pense pas, et je ne crois pas que personne s'en plaigne. Les GNU Coreutils sont maintenant en standard sur la plupart des distro, et personne ne remet en cause ce fait là; mais ça n'a pas empêché chacune de ces distro de vivre dans son coin, avec sa propre philosophie, et ses propres manières de faire.

TRÈS mauvaise analogie : 1/ Il y a des alternatives et tu en cites toi-même (mais tu refuses de les prendre en compte parce que... ?) 2/ Les shells le réimplémentent en grande partie en builtins (man bash, man zshbuiltins, etc.) 3/ Chaque binaire est indépendant, contrairement à systemd. Il y a plusieurs voix qui se sont élévées pour indiquer que l'intégration de Debian/Ubuntu qui n'utilisent que la partie "init" de systemd est mauvaise parce que ça a des effets de bords contrairement à Arch/Fedora pour qui l'intégration à 100% mène à un système plus stable. On notera que les développeurs de systemd crient pourtant à qui veut l'entendre que leur init est très modulaire. Les coreutils sont clairement moins essentiels que tu l'indiques au fonctionnement du système (à plus forte raison si tu utilises systemd) et finalement, les produits qui reposent dessus sont plutôt peu nombreux (genre... les autres systèmes d'init). Et si tout le monde utilise les GNU coreutils c'est parce que : 1/ La licence est correcte (les BSD coreutils sont.... sous licence BSD quoi) 2/ Ils ont prouvé leur fiabilité Les distributions utilisant GNU coreutils ou la GNU libc ne le font pas parce que "c'est standard" mais parce que c'est celui qui convient le mieux, sinon il y a d'autres distribs qui en utilisent d'autres parce qu'elles visent des besoins spécifiques. systemd n'est que l'init qui convient le mieux aux distributions qui veulent packager Gnome comme environnement par défaut. Et c'est dommage que plus de distributions ne fassent pas plutôt le choix de se débarasser de cette UI plutôt que de forcer systemd qui ne convient pas à de nombreux usages.

Bien que systemd mange toute la différenciation sur les couches basses et essentielles du système, je l'imagine un peu comme les coreutils, qui sera considéré à terme comme outils intrinsèquement lié à Linux. La différenciation des distros se fera sur autre chose que des scripts d'init fait maison (et tout ce que Systemd peut englober). C'est une histoire de timing tout ça, mais bon GNU/Linux ne s'est pas fait en un jour non plus, et les standards peuvent mettre du temps à s'installer.

Le problème est que systemd englobe trop de choses, justement, et profite de la mainmise de Red Hat sur de nombreux projets pour ne pas laisser le choix aux autres distributions. Le mail de Lennart Poettring parlant du merge de udev dans systemd est symptomatique de ça[1]. Et comme les devs de Busybox le disent si bien[2] : "systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them." [1] https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html [2] https://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5... -- Benjamin Boudoir