Pour le coup je parlais de machines perso en dehors du cadre professionnel.
Le 9 déc. 2016 12:57, "Colin Brigato" <co...@brigato.fr> a écrit : > 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 <http://www.typeapp.com/r> > Le 9 déc. 2016, à 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/ >>> >> >> >> > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
