Dans le genre système d'init pour server j'eviterai drastiquement système en effet : -openRC pour le tout venant - l'init de busybox pour le compromis efficacité/simplicité - carrément sinit quand on est sur du micro service - voir pas d'init du tout, avec le service final qui est codé pour faire office d'init - voir carrément le service final qui est Codé pour être aussi le bootloader, à la bare_metal sur vm x86 (j'aime les Unikernel, chacun ses vices)
Mais sinon se passer de systemd semble résoudre pas mal de problème. En revanche pour Barberousse mon précédent je dirait quand même que mettre l'usine a gaz "j'abuse des système convergents" "j'ai découvert l'idempotence et j'en ai fait une drogue" à.k.a chef quand on Parle à cote d'éviter systemd, c'est plutôt rigolo comme namedropping (et inconsistant). "Chef, y'en à qu'on essayé, ils ont eu des problème." Du moins on connait pas mal de boîte qui jouent beaucoup de transparence sur leur propres erreurs et qui n'ont pas manque de bien expliciter pourquoi aujourd'hui ils se mordent les doigt d'avoir parié sur chef. Envoyé par TypeApp Le 9 déc. 2016 11:53, à 11:53, Alexandre Legrix <a...@bragonux.net> a écrit: >Hello > >Pour résumer c'etait mieux avant concernant, le système d'init ! >Par contre je ne vois pas l’intérêt d'installer automatiquement un Lamp >avec un script Bash maintenant que tout peut être fait très proprement >avec >Ansible / puppet / chef ! > >Un fidèle utilisateur qui n'a pas du tout aimé systemd et qui utilise >openRC tous les jours, et qui n'aime pas du tout pulseaudio .... > >Amicalement >Alexandre > >Le 9 décembre 2016 à 10:50, Benjamin Boudoir ><benjamin+fr...@boudoir.name> >a écrit : > >> Le 08/12/2016 19:21, Mrjk a écrit : >> >>> Salut, >>> >>> Loin de moi de vouloir relancer un troll qui devient vieux comme le >>> monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est >le >>> point de vue de l'admin qui fait de la prod qui m’intéresse (je ne >>> sais pas si tu es dans ce cas). >>> >>> En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté >>> un grand confort, surtout quand on utilise des outils du type >>> Ansible/Puppet sur différentes plateforme. Une interface pour tous >les >>> masteriser. J'ai encore du mal à comprendre ce que l'on peut >reprocher >>> a systemd. >>> >> >> Je suis sysadmin, j'utilise ansible et je n'ai encore jamais rien vu >que >> systemd améliorait avec cet outil. J'ai un playbook qui réinstalle >sysv au >> lieu de systemd sur toutes les machines que l'on gère. >> >> Les raisons de mon désamour de systemd sont très nombreuses et je >vais la >> résumer en quelques points : >> - systemd est incapable de faire démarrer une machine dans toutes les >> conditions (notamment l'utilisation de FS en réseau / tmpfs / RO) >> - systemd peut avoir des problèmes pour éteindre certaines machines >(je >> l'ai déjà retrouver à ne pas réussir à démonter des points montés en >réseau >> avec un timeout de... 5 minutes. Par point de montage. 2h de down >pour une >> upgrade de kernel ça fait super mal quand même, ça va que c'était que >pour >> de l'interne) >> - systemd est peut-être plus modulaire que beaucoup d'anti le disent, >dans >> les faits il l'est beaucoup moins que Lennart Poettring veut bien le >faire >> croire et beaucoup de distribs se retrouvent presques forcées >d'intégrer >> des extensions à systemd qui sont au mieux inutiles, au pire >dangereuses >> (genre systemd-resolvd) >> - systemd casse des features du kernel (chroot, LXC, terminaux >virtuels, >> ...) et ses développeurs refusent de corriger leur code >> - systemd rend plus complexe l'écriture de scripts (start / stop / >restart >> / status ne retournent pas d'état, les commandes retournent leur >résultats >> dans un pager par défaut, etc.) >> - BEAUCOUP de surprises sur des binaires usuels qui changent de >> comportement (genre halt qui n'éteint plus électriquement une >machine)... >> Même si, j'avoue que c'est juste chiant parce que ça casse les >habitudes, >> en vrai une fois que tu le sais ça va vite a prendre en compte. Et >faut >> vérifier tes scripts au cas où. >> >> Je serais moins virtulent avec systemd, si ce n'était qu'un système >> d'init. Le problème c'est que ses développeurs veulent le faire >grossir en >> fonctionnalités avant même de savoir faire booter un système Linux >> correctement. C'est fâcheux, vraiment. C'est avant tout une question >de >> confiance dans le produit fini et en l'état, je suis incapable de >prédire >> que ma prod tournera correctement (ni même démarrera) avec systemd. >> Accessoirement, je préfère les scripts d'init que je peux facilement >> débugger alors qu'avec systemd si quelque chose ne démarre pas, je >peux me >> brosser pour avoir les détails qui m'intéressent. >> >> Après, je dis pas que y'a des choses pratiques dans systemd, >notamement : >> - Les scripts d'init faciles à faire >> - L'utilisation de cgroups pour chaque daemon lancé >> - La gestion de daemons utilisateurs >> >> Cependant, c'est rien qui n'ait pas déjà été fait ailleurs de façon >plus >> propre. Partant de là, j'ai du mal à comprendre que systemd ait été >autant >> poussé en avant alors qu'il casse plus de choses qu'il n'en corrige >tout en >> retirant aux admins la possibilité de contourner les problèmes. >> >> Note; C'est le point de vue qui m’intéresse, je cherche pas à >>> démontrer que systemd est le meilleur. >>> >> >> Pour le coup, je tiens à dire que j'ai vraiment tenté d'utiliser >systemd. >> Malgré le fait que je le trouvais dégeulasse par design, je me suis >quand >> même dit que ça pouvait pas être si mal que ça si Debian l'intégrait >par >> défaut : >> - Sur mes postes persos, 4 machines sur 5 ne démarraient plus, la >dernière >> mettait plus de temps à démarrer. >> - En prod, le playbook ansible est assez récent (4 mois d'après git), >il >> fait suite aux multiples problèmes qu'on a pu rencontrer au fur et à >mesure >> (et quand je dis "multiple", c'est en grande partie parce qu'on a >rarement >> eu le même plusieurs fois, rien qu'écrire de la doc sur ce que >cassait >> systemd à nécessité un boulot de dingue, vraiment). Au début on >repassait >> sous sysv uniquement les machines où systemd nous posait de gros >problèmes. >> Puis on s'est rendu compte que c'était plus de la moitié de nos >setups et >> on a préféré jouer la carte de la sécurité. >> >> -- >>> MrJK >>> GPG: https://jeznet.org/jez.asc >>> >> >> -- >> Benjamin Boudoir >> >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ >> > > > >-- >Alexandre > > >------------------------------------------------------------------------ > >_______________________________________________ >Liste de diffusion du FRsAG >http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
