En fait, le souci a été rapporté plus tôt qu'il y a 4j. Le bug https://bugzilla.redhat.com/show_bug.cgi?id=1141597 date du 14 septembre. Sachant que l'équipe réponds en général sous 24h avec un CVE, je pense que la faille date de ce jour, ce qui a laissé le temps de coordonner , de corriger et de tester le correctif. Ensuite, en effet, la 2eme faille a été bien plus rapide à être corrigé, et je sais que l'équipe a bossé comme des fous sur le sujet.
Il est aussi à noter que l'article dit que CVE-2014-7187 et CVE-2014-7186 sont non publiques, mais il y a une description sur le bugzilla de RH :
Il me semble aussi que postfix n'est pas un vecteur connu ( au contraire de qmail et exim ), car il nettoie les variables comme il faut. Mais je ne trouve rien sur le sujet.
Ça part aussi du principe que l'admin change jamais de boulot, et qu'il n'a jamais personne qui le remplace, et qu'il a jamais une personne pour l'aider qui a son propre jeu de scripts avec des workarounds différents, etc :)
En effet, entres autres. Et je travaille avec du code qui à pas
loin de 10 ans, installé sur des machines dont l'âge varie de 6
ans à dans quelques jours (install et param en cours).
Bien que je préfère ça aussi, je suis parfois hélas obliger de faire face à un monde différent du tien, ou les choses bougent plus vite. Exemple, ruby, ou python. Donc oui, c'est chiant d'avoir des écosystèmes qui bougent, mais c'est le prix à payer pour avoir des améliorations. Et si le libre n'évolue pas, je pense qu'il risque de tomber en désuétude, même sur des domaines ou il est dominant. Exemple, les webmails, les forges, qui ont globalement pris une grande claque via gmail et github ( même si github a aussi bénéficier d'un effet réseau mais pas uniquement ). Je sais que des gens préfèrent jira à bugzilla pour les bugs trackers ( ou confluence à mediawiki, pour les wikis ).
Ensuite, on est pas à l'abri d'une évolution ( genre apache qui a changé son format, chose que j'aurais pas cru possible, surtout si c'est pas pour corriger les fautes de grammaires ).
Enfin, j'ai envie de citer le seul autre outil de journalisation
binaire que j'aie vu, celui de windows. Franchement, pas quelque
chose que j'ai envie de voir arriver sur Linux, vue la galère
que c'est (ou du moins, que c'était à l'époque d'XP) que
d'essayer d'y tirer la moindre information utile
Il y en a d'autres. Par exemple, splunk. Le souci des logs windows, c'est quand même que le contenu ne veut rien dire sauf pour le développeur. Ou alors, c'est l'UI qui est pourri ? Franchement, je t'invite à choper une centos 7 et à jouer avec. mets un serveur ftp, regarde journalctl, etc. Pour ma part, je me demande comment j'ai fait pour me passer de l'option -u.
Je pense que soit tu estimes les logs sont transients, et tu t'en fout de les perdre.
Soit tu estimes qu'ils sont importants, et tu traites ça comme tel ( cad, des backups, ou tu logues en double sur 2 machines, etc ). Et à ce niveau la, journald permet de tirer les logs, ou de les pousser de façon native. On va me dire que les logs non binaire le font aussi, mais c'est un peu moins simple en pratique. En fait, pour la partie "pousser", c'est kifkif.
Tout d'abord pour tirer les logs, car il faut mettre rsync en place pour tirer les logs de façon sécurisé. C'est pas dur, mais c'est un peu chiant si on le fait par ssh ( je passe à chaque fois 5 minutes sur la syntaxe de forcecommand et les options exactes à mettre, donc 4 minutes à retrouver le truc pour les voir ). Ca se fait bien via rsync tout court ( via xinetd par exemple ), mais ç'est en clair, et je suis pas sur que tout le monde soit ok avec ça. On peut monter ça via nfs, ftp, http, etc, mais c'est moins efficace sur des gros fichiers que rsync AMHA.
L'autre souci, c'est la configuration par défaut des distributions et de logrotate. Par défaut sur certaines distribs ( Debian based, Mandriva ), logrotate va renommer les fichiers en utilisant un incrément, ce qui fait qu'un fichier nommé logrotate.2.gz un jour sera logrotate.3.gz plus tard, ce qui est pas terrible pour faire des backups. Il semble que RHEL 7 utilise l'option dateext dans logrotate.conf pour éviter ça, donc on peut éviter ( il semble aussi que ça date de 2007, donc je me prends un peu la honte sur ma demonstration ).
Journald utilise un timestamp ( encodé en hexa , le 3eme champ du nom de fichier cf http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n273 ) ce qui fait que c'est facile de trier et de retirer les plus anciens. Je regrette ceci dit que le timestamp ne soit pas lisible à l'oeil nu. Mais il a le bon gout d'avoir une taille fixe, ce qui evite des corners cases avec le tri en shell ( genre, oublier de faire un tric sur une valeur numérique au lieu d'une valeur lexicographique, ce qui fait que toto-400 est vu comme avant toto-50, car on compare caractères par caractères ).
Donc rien d'insurmontable bien sur, rien de novateur, mais la force de systemd, c'est aussi d'offrir ça par défaut, ce qui permet de construire par dessus des choses haut niveau réutilisable, et ce qui démocratise la bonne pratique.
Un truc bien fait avec journald, c'est que le logiciel va gérer nativement le faire d'avoir des fichiers de log venant de n'importe ou, car le nommage le permet, et le logiciel en tire parti. On peut tout mettre tel quel dans /var/log/journal, et journal va faire "the right thing". On peut donc suivre les logs sur plusieurs machines, etc, etc. Le nommage des logs classiques implique un post traitement plus complexe, ce qui est faisable encore une fois. Par exemple, splunk, elastic search sont des solutions pour ça qui vont bien au delà de journald. mais qui requiert une infra plus conséquente, la ou journald va juste tirer parti du nommage des fichiers et d'un design simple.
C'est donc vraiment dans l'approche d'offrir un truc parce que c'est facile à faire, une solution intermédiaire entre rien et le truc plus complet et plus compliqué ( un peu comme le protocole de notification de systemd ). Ça règle pas tout les soucis de tout le monde, mais ça peut aider.
Bien sur qu'il vaut mieux plusieurs implémentations, mais l'équipe systemd en a écrit une, il manque plus que les autres pour le faire.
Ensuite, il y a aussi le fait que faire plusieurs implémentations, c'est aussi dupliquer le code, donc c'est pas exactement gratuit en terme de ressources. Si l'unique motivation est d'avoir plusieurs implémentations, ça suffit généralement pas, il y a souvent d'autres raisons ( license, architecture différente, choix d'implémentation, etc ). Sous Linux, on a attendu longtemps d'avoir autre chose que la libjpeg, et je suis pas sur d'avoir vu autre chose que la libpng.
C'est donc arriver par la suite, dans les années 80. Et si je me souviens bien des headers de copyright, les scripts qu'on retrouve au moins sur les distros rpms datent de milieu/fin 90 sur Linux, donc pas très unix à la base.
Ensuite, Apple l'a remplacé du jour au lendemain ( lors de la release 10.4 ). Gentoo l'a remplacé du jour au lendemain ( genre dés le début ). Ubuntu l'a remplacé du jour au lendemain ( même si ils ont eu des journées longues ). Sun l'a remplacé du jour au lendemain ( sur solaris 10 ). Les BSD, qui sont bien plus Unix que Linux par définition n'ont pas sysvinit, sauf erreur de ma part.
Enfin, du jour au lendemain, tu veux sans doute dire "en 2 ou 3 ans".
Et autant que je sache, Solaris a encore le droit de s'appeler Unix, ce que la majorité des distributions Linux n'ont jamais eu le droit. Donc si Solaris et Apple sont assez "Unix" pour l'open group ( que OS X 10.7 avait la certification, et je doute pas que Solaris aussi ), je pense qu'il faut pas être plus royaliste que le roi.
Dans ce cas, tu doit faire que du C ou du perl. Parce que le python, le ruby et le php d'il y a 10 ans, y a des chances que ça marche plus.
je suis d'accord qu'il faut de la stabilité, mais je pense que c'est à la distribution d'assurer ça. Le reste, c'est juste une conséquence de la R&D distribué qu'est le mouvement du logiciel libre. Il y a les outils ou personne n'innove,
Systemd a une page qui liste les interfaces et la promesse de pas les changer, ce qui est largement mieux que la majorité des projets que je connais, même si certains s'en sortent aussi bien voir mieux.
Mais maintenant, je pense qu'on peut pas soutenir les devs kernels qui soutiennent que les interfaces internes du kernel peuvent bouger, alors qu'il y a de la demande pour la stabilité (pour les drivers), que d'autres arrivent à le faire (solaris, windows ), et en même temps réclamer que rien ne change sur les autres projets.
Ça me semblerait juste hypocrite, et je doute qu'une séparation arbitraire il y a un bout de temps entre kernel space et user space soit une raison suffisante pour dire "c'est normal d'être emmerdé pour les drivers, bout de code compilé qui tourne sur ton pc, mais pour les softs en user space, autre truc compilé qui tourne sur ton pc, c'est différent".
Et je pense que le but n'est pas de remplacer init, mais de remplacer les initscripts ( au sens paquet du même nom ). Et en effet, par la suite, d'offrir une API pour gerer la machine tant qu'à faire.
Les initscripts, les trucs qui montent le LVM, lance le réseau, lance les softs, etc. Tout des trucs qui étaient déjà fait à gauche et à droite de façon différente par chaque distro.
Tu donnes l'exemple de la journalisation, mais il faut bien voir que le journal est une conséquence du design et de la position de systemd. Tu voudrais mettre ça en dehors de systemd, mais comment est ce qu'un programme en dehors de systemd accède à stdin et stdout ? Donc une fois que tu te dit "ça serait une idée de choper ça", tu te retrouves à avoir un cache. Et tu te dit "je peux rajouter plus de données". Et ensuite, "je peux sans doute faire des recherches dans ce cache", et le mettre sur le disque et voila, journald dans sa forme actuelle, cad un programme qui va en effet faire le même travail que les fichiers syslog, mais dans une base de données indexé lisible.
Si tu as selinux, alors dhclient va juste avoir le droit de faire ce que la policy dit de faire, ce qui a des chances de grandement limiter les dégats. j'ai pas regardé en détail, mais de ce que je vois aprés 5 minutes d'analyses, c'est quand même limité.
va lister les domaines vers lesquelles dhcp_t peut faire une transition.
sesearch --allow -s dhcpc_t | grep execute
va lister les types que dhclient a le droit d'executer, la majorité sans avoir des droits différents de dhclient lui même ( vu qu'ils sont pas dans la première liste ).
Un rapide examen montre que dhcpc va écrire des fichiers d'un certain type, mais n'a le droit d'execution sur aucun de ceux qu'il va écrire. Donc ça bloque déjà les exploits à base de wget basique. Tu peux sans doute faire un truc avec wget + un interpreteur de commande ceci dit, mais tu sera toujours limité à ce que dhclient peut faire.
A vue de nez, le truc le plus prometteur serait insmod_t, mais je pense que insmod_t ne va pas charger n'importe quel fichier, et surtout pas un fichier que dhclient va écrire, pour cause de mauvais label.
Ensuite, je voit qu'un script pourrait couper le firewall, ce qui est un souci. Le reste, c'est de la manipulation de réseau, ce qui est chiant, mais dans la mesure ou ça implique un dhcp rogue, je pense qu'on peux supposer que le réseau n'a pas besoin d'une faille pour être modifier de façon créative.
Donc voila, je pense que selinux va bloquer assez efficacement la majorité des soucis, même si j'exclue pas qu'un truc passe à travers, ou qu'on puisse enchainer.
Quand à ssh, ça va marcher si le serveur ssh est openssh ou similaire, ie, un serveur ssh avec un shell. Je sais pas ce que ça donnerais sur les implémentations customs d'un serveur pour des besoins spécifiques ( genre github a son propre serveur git en ruby, si je me souviens bien, et ils semblent dire que leur service n'est pas vulnérable https://github.com/blog/1893-security-vulnerability-in-bash-addressed donc je suppose que c'est pareil pour ssh ). Mais je suppose aussi que ce genre d'infrastructure est l'exception plus que la norme.
Ne pas avoir prévu la gestion de la mise en veille/hibernation
pour les points de montage, ça fait fausse note.
En fait, c'est pas la mise en veille le souci, c'est le changement et ou la perte de la connectivité. La mise en veille est juste un déclencheur. Je peux par exemple avoir un point de montage non réseau qui continue de marcher ou qui va dépendre du fait que je retire un cable pendant que le pc est en veille. Ou mettre en veille et revenir dans le même réseau de façon transparente.
Intuitivement, je me dit que ça devrait être fait au niveau du filesystem, mais peut être que les sémantiques et que le code ne permet pas de faire ça de façon optimum.
Perso, j'ai pas de cgi, j'ai mon dhclient qui tourne avec un domaine selinux confiné. Et j'ai pas de serveur git avec forcecommand ( j'ai des rsync par contre, mais ça implique d'avoir la clé à priori ). Donc je vais pas stopper tout pour la mise à jour, je vais finir ma pizza ( au contraire de Linuxfr, qui lui est important )
maintenant, si vous avez gitolite, et que vous êtes dans un hotel chelou rempli de linuxien, ça me parait plus critique que pour moi :)
Pour le moment, le mec a surtout retiré du code, et appliquer des patchs refusés upstream pour musl. L'argument des devs de systemd étant "il faut rajouter le code dans musl", et les devs de musl "il faut rajouter le code partout ailleurs" ( mais bon, y en a qu'un des 2 qui se fait traiter de fachiste pour refuser du code ).
Donc oui, c'est sur qu'en ne faisant que retirer du code d'une vielle version, ça va pas exploser. Bien sur, c'est intenable sur le long terme sauf à ce que rien d'autre ne bouge à coté.
Je suis pas d'accord. Je suis packageur depuis un numbre d'année à 2 chiffres, et j'ai vu les soucis que pose les scripts en bash, à savoir que tout le monde ne maitrise pas le bash, ce qui justement donne des soucis super compliqués.
J'ai donné les exemples de bind, sur debian sur openbsd etc lors des nombreuses discussions sur systemd, mais juste pour montrer les trucs récents sur ansible lié à des fichiers d'init foireux :
Et pourquoi ? parce que les gens qui font les scripts se préoccupent pas des détails comme la synchronisation entre le script et le soft qui est geré, ou des détails comme filer les codes de retour.
Donc je pense que la séparation "j'ai vu comment ça marche, c'est moche", c'est faux. Les conséquences d'avoir du bash à tout les étages sont simple à piger, tu as des scripts dupliqués ( car personne n'envoie les scripts upstream et il y a pas d'unité dans ce que tu fais ), parfois de qualité inégale, du au fait que personne ne peux penser à tout à chaque fois, surtout quand ça requiert des compétences que tout le monde n'a pas ( genre, se préoccuper de l'automatisation, ça te viens pas à l'esprit quand tu es un packageur débutant ). Et tu le voit assez vite quand tu fait du mentoring auprès des nouveaux arrivants.
Ensuite, l'intégration de systemd est plus complexe que celle de sysvinit, mais c'est surtout parce que systemd bouge la ou sysvinit ne bouge pas. mais l'intégration de sysvinit n'etait pas non plus une partie de plaisir y a 6/7 ans quand les gens étaient encore en trian de le faire bouger, et que par exemple, mandriva devait refaire les patchs en bash sur le soft venant de Fedora/RH.
Il faut espérer que systemd va finir par se stabiliser un peu plus et innover moins, pour réduire ta charge de travail.
Sur RHEL 7/Centos 7 et fedora je sais pas combien, les plugins firefox sont restreint via SELinux. Donc si jamais quelqu'un arrive à trouver une faille dans flash et la distribue via un réseau de pub, comme ça arrive souvent, ta clé ssh se fera pas faucher, sauf à contourner SElinux.
( tu peux aussi remplacer "clé ssh" par "fichier de mot de passe firefox" ).
Il me semble aussi qu'il y a eu des choses sur les outils qui font des vignettes, au cas ou tu trouves une clé usb avec un fichier vérolé qui fait planter l'outil de vignette.
Je pense aussi que SElinux permet de s'assurer que le compte guest ( paquet xguest ) est vraiment limité, ce qui sert sur un kiosque.
Il permet également de limiter docker, qui est un outil assez à la mode en ce moment pour les devs ( donc sur un pc personnel ), et je suppose que selinux serviras aussi pour limiter les applications tierces pour ce que Gnome veut faire avec les histoires de sandbox.
L'ipod avant quand même une capacité en disque bien plus grande que les autres sur le marché, en grande partie par la pénurie orchestré par Tim Cook qui a fait une razzia sur le stock mondiale, pour s'assurer d'avoir de l'avance ( ce que des gens qualifient de "génie logistique", d'autres d'" abus de position dominante" mais bon, ça ne s'applique que si l'histoire est vrai )
Ou le fait de devoir aller à la boutique Apple pour prendre rendez vous pour faire reparer ton pc portable. Mais si tu commences à dire "le service client ne me satisfait pas", tu passes devant tout le monde.
De toutes façons payer le prix fort pour se retrouver enfermé,
très peu pour moi.
En fait, tu payes pas pour le produit, mais pour l'image que ça te donne. Il suffit de voir l'image qu'Apple associe à coup de publicité à ses produits, et le fait que tu bénéficies de la même aura inconsciemment.
Exemple, il suffit de voir les pubs à la télé ( pas celle de bouygues, celle pur Apple ), tu vois pas vraiment le produit. Tu vois quelqu'un qui voyage dans des paysages superbes, qui va à la découverte du monde ( Asie notamment ) en faisant de la danse, en discuttant avec quelqu'un dans un souk. C'est indéniablement un style de vie qui fait rêver, mais qui est couteux.
Ou tu prends la pub avec un compositeur solennelle dans sa voiture, en train de reflechir, etc et on termine en te disant "et vous, quel est votre rime", sous entendu "et toi, tu va aussi être un artiste ?". Et quand on parle d'artiste, on montre pas n'importe quoi, on parle de compositeur de musique classique, qui est ( à tort ) associé à une forme de bourgeoisie.
Bien sur, c'est hautement fabriqué et filtré comme vision, ça joue à fond sur les préjugés, voir ça les renforcent, mais ça marche.
Le fait de mettre un prix plus haut fait que forcément, tu te dit que c'est pour les riches. Donc si tu l'achètes, c'est que tu es riche. Et ça renforce l'envie. ( et le fait d'avoir des prix plus hauts donnent des marges qui compensent le fait d'avoir moins de vente dans un temps ).
Et tout est dans ce sens. les gens dans l'Apple store ne te présentent pas les fonctionnalités du téléphone, mais cherche à te faire parler, pour ensuite te dire comment le téléphone va s'intégrer dans ta vie à des moments clés via l'émotion ( l'exemple qu'on m'a donné, c'est qu'on va pas te dire "y a 2 camera X mega pixels avec tel feature", mais on va te dire que grace à la camera, tu peux faire une vidéo conférence après la naissance de ton fils avec ta famille.
C'est pas pour rien que Apple a débauché des gens du secteur de la mode comme VP. C'est parce qu'ils ont besoin de gens qui sont bien imprégné et qui maitrise le paraitre.
Et les exemples sont à l'infini, et si tu as le sens de l'observation et un peu de sens critique, tu peux difficilement l'éviter ( et plus ça va, plus tu en vois ). Greenpeace fait un rapport qui égratigne l'image d'Apple sur l’environnement, 2 ans après, ils ont tout changer pour dire "on est écolo" ( tant que c'était pas publique, ils s'en foutaient grave ). Et Tim cook en remets une couche face à un investisseur.
Si tu prends un appareil Apple, c'est marqué "designed in California" avec made in china tout petit, histoire de propager l'image de coolitude californienne ( silicon valley, etc ).
Ou la page web de la marque. On te dit pas "revoir la keynote", mais "revivre la keynote". Parce que revoir, c'est passif. Revivre, on te place directement la position d'un moment d'émotion.
Enfin voila, toi, tu va pas l'acheter parce que tu mets plus de valeurs à ta liberté, mais l'utilisateur moyen visé par Apple ne déborde pas de compétences informatiques ( être globalement super neu neu proof est quand même un des points de Os X tant que tu restes dans les clous, ce qui arrivent quand même pas en pratique ), donc ne va pas vraiment voir la problématique de la liberté sous le même angle que toi.
Je sais pas si systemd y réponds, et si un outil d'orchestration plus classique, voir juste un makefile ferait pas l'affaire par contre.
Un script maitre marcherais, mais je pense que l'idée est aussi d’intelligemment reprendre si ça s'arrête à un moment, ce qui est pas une chose qu'une simple exécution à la suite ferait. Ensuite, peut être que c'est overkill, et qu'il faudrait donc un outil plus spécialisé.
C'est pas tant systemd en tant que tel que le fait que logind gére la session ( cad s'assure que les accés sont revoqués quand il y en a plus besoin, etc ). Ensuite la question est pourquoi logind a besoin de systemd, et pourquoi personne n'a fait ça avant.
Logind a besoin d'un système qui va gérer les sessions de manière fiable ( cad sans fuite de process hors de la session ), et il se trouve que c'est l'un des points fort de systemd, cad via les cgroups. À son tour, la gestion des cgroups, pour être propre, requiert d'avoir un seul process qui gére ça ( histoire que l'état ne change pas sous nez et avec des races conditions ). A son tour, la gestion des process requiert d'avoir un PID1 qui est au courant du fait qu'il y a des cgroups pour les process. Soit il gére ça lui même ( ce que fait systemd ), soit il fait faire ça par un autre process ( ce que upstart aurait fait ).
Les devs de systemd est que pour éviter les races conditions et la fiabilité, c'est plus simple de faire ça dans un seul processus que dans 2 ( vu qu'il y a des délais, potentiellement des communications asynchrones, du code pour communiquer entre les 2 processus, et du code dans le premier pour relancer le 2eme, avec le code du 2eme pour relancer ce qu'il lance lui même, etc ). Donc c'est comme ça qu'on se retrouve avec logind qui a besoin de systemd, et systemd qui se retrouve avec le pid 1.
Je suis sur qu'on aurait pu le faire avant, mais si les premiers trucs au sujet de X sans root date de 2008 ( https://airlied.livejournal.com/59521.html ) et qu'il a fallu 6 ans pour faire les derniers pas, peut être que c'était pas si simple à faire de manière propre.
# Quelque details
Posté par Misc (site web personnel) . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 10.
En fait, le souci a été rapporté plus tôt qu'il y a 4j. Le bug https://bugzilla.redhat.com/show_bug.cgi?id=1141597 date du 14 septembre. Sachant que l'équipe réponds en général sous 24h avec un CVE, je pense que la faille date de ce jour, ce qui a laissé le temps de coordonner , de corriger et de tester le correctif. Ensuite, en effet, la 2eme faille a été bien plus rapide à être corrigé, et je sais que l'équipe a bossé comme des fous sur le sujet.
Il est aussi à noter que l'article dit que CVE-2014-7187 et CVE-2014-7186 sont non publiques, mais il y a une description sur le bugzilla de RH :
https://bugzilla.redhat.com/show_bug.cgi?id=1146791
https://bugzilla.redhat.com/show_bug.cgi?id=1146804
Il me semble aussi que postfix n'est pas un vecteur connu ( au contraire de qmail et exim ), car il nettoie les variables comme il faut. Mais je ne trouve rien sur le sujet.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 3.
Ça part aussi du principe que l'admin change jamais de boulot, et qu'il n'a jamais personne qui le remplace, et qu'il a jamais une personne pour l'aider qui a son propre jeu de scripts avec des workarounds différents, etc :)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
Bien que je préfère ça aussi, je suis parfois hélas obliger de faire face à un monde différent du tien, ou les choses bougent plus vite. Exemple, ruby, ou python. Donc oui, c'est chiant d'avoir des écosystèmes qui bougent, mais c'est le prix à payer pour avoir des améliorations. Et si le libre n'évolue pas, je pense qu'il risque de tomber en désuétude, même sur des domaines ou il est dominant. Exemple, les webmails, les forges, qui ont globalement pris une grande claque via gmail et github ( même si github a aussi bénéficier d'un effet réseau mais pas uniquement ). Je sais que des gens préfèrent jira à bugzilla pour les bugs trackers ( ou confluence à mediawiki, pour les wikis ).
Ensuite, on est pas à l'abri d'une évolution ( genre apache qui a changé son format, chose que j'aurais pas cru possible, surtout si c'est pas pour corriger les fautes de grammaires ).
Il y en a d'autres. Par exemple, splunk. Le souci des logs windows, c'est quand même que le contenu ne veut rien dire sauf pour le développeur. Ou alors, c'est l'UI qui est pourri ? Franchement, je t'invite à choper une centos 7 et à jouer avec. mets un serveur ftp, regarde journalctl, etc. Pour ma part, je me demande comment j'ai fait pour me passer de l'option -u.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 8.
Je pense que soit tu estimes les logs sont transients, et tu t'en fout de les perdre.
Soit tu estimes qu'ils sont importants, et tu traites ça comme tel ( cad, des backups, ou tu logues en double sur 2 machines, etc ). Et à ce niveau la, journald permet de tirer les logs, ou de les pousser de façon native. On va me dire que les logs non binaire le font aussi, mais c'est un peu moins simple en pratique. En fait, pour la partie "pousser", c'est kifkif.
Tout d'abord pour tirer les logs, car il faut mettre rsync en place pour tirer les logs de façon sécurisé. C'est pas dur, mais c'est un peu chiant si on le fait par ssh ( je passe à chaque fois 5 minutes sur la syntaxe de forcecommand et les options exactes à mettre, donc 4 minutes à retrouver le truc pour les voir ). Ca se fait bien via rsync tout court ( via xinetd par exemple ), mais ç'est en clair, et je suis pas sur que tout le monde soit ok avec ça. On peut monter ça via nfs, ftp, http, etc, mais c'est moins efficace sur des gros fichiers que rsync AMHA.
L'autre souci, c'est la configuration par défaut des distributions et de logrotate. Par défaut sur certaines distribs ( Debian based, Mandriva ), logrotate va renommer les fichiers en utilisant un incrément, ce qui fait qu'un fichier nommé logrotate.2.gz un jour sera logrotate.3.gz plus tard, ce qui est pas terrible pour faire des backups. Il semble que RHEL 7 utilise l'option dateext dans logrotate.conf pour éviter ça, donc on peut éviter ( il semble aussi que ça date de 2007, donc je me prends un peu la honte sur ma demonstration ).
Journald utilise un timestamp ( encodé en hexa , le 3eme champ du nom de fichier cf http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n273 ) ce qui fait que c'est facile de trier et de retirer les plus anciens. Je regrette ceci dit que le timestamp ne soit pas lisible à l'oeil nu. Mais il a le bon gout d'avoir une taille fixe, ce qui evite des corners cases avec le tri en shell ( genre, oublier de faire un tric sur une valeur numérique au lieu d'une valeur lexicographique, ce qui fait que toto-400 est vu comme avant toto-50, car on compare caractères par caractères ).
Donc rien d'insurmontable bien sur, rien de novateur, mais la force de systemd, c'est aussi d'offrir ça par défaut, ce qui permet de construire par dessus des choses haut niveau réutilisable, et ce qui démocratise la bonne pratique.
Un truc bien fait avec journald, c'est que le logiciel va gérer nativement le faire d'avoir des fichiers de log venant de n'importe ou, car le nommage le permet, et le logiciel en tire parti. On peut tout mettre tel quel dans /var/log/journal, et journal va faire "the right thing". On peut donc suivre les logs sur plusieurs machines, etc, etc. Le nommage des logs classiques implique un post traitement plus complexe, ce qui est faisable encore une fois. Par exemple, splunk, elastic search sont des solutions pour ça qui vont bien au delà de journald. mais qui requiert une infra plus conséquente, la ou journald va juste tirer parti du nommage des fichiers et d'un design simple.
C'est donc vraiment dans l'approche d'offrir un truc parce que c'est facile à faire, une solution intermédiaire entre rien et le truc plus complet et plus compliqué ( un peu comme le protocole de notification de systemd ). Ça règle pas tout les soucis de tout le monde, mais ça peut aider.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 4.
Bien sur qu'il vaut mieux plusieurs implémentations, mais l'équipe systemd en a écrit une, il manque plus que les autres pour le faire.
Ensuite, il y a aussi le fait que faire plusieurs implémentations, c'est aussi dupliquer le code, donc c'est pas exactement gratuit en terme de ressources. Si l'unique motivation est d'avoir plusieurs implémentations, ça suffit généralement pas, il y a souvent d'autres raisons ( license, architecture différente, choix d'implémentation, etc ). Sous Linux, on a attendu longtemps d'avoir autre chose que la libjpeg, et je suis pas sur d'avoir vu autre chose que la libpng.
[^] # Re: Je vais paraître inculte, mais...
Posté par Misc (site web personnel) . En réponse au journal Mettez du Debian et du ArchBSD dans votre FreeBSD : mkjl.sh. Évalué à 6.
C'est quoi le souci de gentoo BSD, en dehors du fait que ça fait pas tourner systemd ( je dit ça juste pour remplir le quota de 80% )
[^] # Re: Surprenant, non ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 9.
L'unix de base ( celui des 70s ) n'avait pas l'air d'avoir un système de script d'init, si je regarde le code sur google code
https://code.google.com/p/unix-jun72/source/browse/#svn%2Ftrunk%2Ffs%2Froot%2Fetc
C'est donc arriver par la suite, dans les années 80. Et si je me souviens bien des headers de copyright, les scripts qu'on retrouve au moins sur les distros rpms datent de milieu/fin 90 sur Linux, donc pas très unix à la base.
Ensuite, Apple l'a remplacé du jour au lendemain ( lors de la release 10.4 ). Gentoo l'a remplacé du jour au lendemain ( genre dés le début ). Ubuntu l'a remplacé du jour au lendemain ( même si ils ont eu des journées longues ). Sun l'a remplacé du jour au lendemain ( sur solaris 10 ). Les BSD, qui sont bien plus Unix que Linux par définition n'ont pas sysvinit, sauf erreur de ma part.
Enfin, du jour au lendemain, tu veux sans doute dire "en 2 ou 3 ans".
Et autant que je sache, Solaris a encore le droit de s'appeler Unix, ce que la majorité des distributions Linux n'ont jamais eu le droit. Donc si Solaris et Apple sont assez "Unix" pour l'open group ( que OS X 10.7 avait la certification, et je doute pas que Solaris aussi ), je pense qu'il faut pas être plus royaliste que le roi.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 7.
Dans ce cas, tu doit faire que du C ou du perl. Parce que le python, le ruby et le php d'il y a 10 ans, y a des chances que ça marche plus.
je suis d'accord qu'il faut de la stabilité, mais je pense que c'est à la distribution d'assurer ça. Le reste, c'est juste une conséquence de la R&D distribué qu'est le mouvement du logiciel libre. Il y a les outils ou personne n'innove,
Systemd a une page qui liste les interfaces et la promesse de pas les changer, ce qui est largement mieux que la majorité des projets que je connais, même si certains s'en sortent aussi bien voir mieux.
Mais maintenant, je pense qu'on peut pas soutenir les devs kernels qui soutiennent que les interfaces internes du kernel peuvent bouger, alors qu'il y a de la demande pour la stabilité (pour les drivers), que d'autres arrivent à le faire (solaris, windows ), et en même temps réclamer que rien ne change sur les autres projets.
Ça me semblerait juste hypocrite, et je doute qu'une séparation arbitraire il y a un bout de temps entre kernel space et user space soit une raison suffisante pour dire "c'est normal d'être emmerdé pour les drivers, bout de code compilé qui tourne sur ton pc, mais pour les softs en user space, autre truc compilé qui tourne sur ton pc, c'est différent".
Et je pense que le but n'est pas de remplacer init, mais de remplacer les initscripts ( au sens paquet du même nom ). Et en effet, par la suite, d'offrir une API pour gerer la machine tant qu'à faire.
Les initscripts, les trucs qui montent le LVM, lance le réseau, lance les softs, etc. Tout des trucs qui étaient déjà fait à gauche et à droite de façon différente par chaque distro.
Tu donnes l'exemple de la journalisation, mais il faut bien voir que le journal est une conséquence du design et de la position de systemd. Tu voudrais mettre ça en dehors de systemd, mais comment est ce qu'un programme en dehors de systemd accède à stdin et stdout ? Donc une fois que tu te dit "ça serait une idée de choper ça", tu te retrouves à avoir un cache. Et tu te dit "je peux rajouter plus de données". Et ensuite, "je peux sans doute faire des recherches dans ce cache", et le mettre sur le disque et voila, journald dans sa forme actuelle, cad un programme qui va en effet faire le même travail que les fichiers syslog, mais dans une base de données indexé lisible.
[^] # Re: Il est urgent de mettre à jour
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 10.
Si tu as selinux, alors dhclient va juste avoir le droit de faire ce que la policy dit de faire, ce qui a des chances de grandement limiter les dégats. j'ai pas regardé en détail, mais de ce que je vois aprés 5 minutes d'analyses, c'est quand même limité.
sesearch -T --allow -s dhcpc_t | grep type_transition | grep process
va lister les domaines vers lesquelles dhcp_t peut faire une transition.
sesearch --allow -s dhcpc_t | grep execute
va lister les types que dhclient a le droit d'executer, la majorité sans avoir des droits différents de dhclient lui même ( vu qu'ils sont pas dans la première liste ).
Un rapide examen montre que dhcpc va écrire des fichiers d'un certain type, mais n'a le droit d'execution sur aucun de ceux qu'il va écrire. Donc ça bloque déjà les exploits à base de wget basique. Tu peux sans doute faire un truc avec wget + un interpreteur de commande ceci dit, mais tu sera toujours limité à ce que dhclient peut faire.
A vue de nez, le truc le plus prometteur serait insmod_t, mais je pense que insmod_t ne va pas charger n'importe quel fichier, et surtout pas un fichier que dhclient va écrire, pour cause de mauvais label.
Ensuite, je voit qu'un script pourrait couper le firewall, ce qui est un souci. Le reste, c'est de la manipulation de réseau, ce qui est chiant, mais dans la mesure ou ça implique un dhcp rogue, je pense qu'on peux supposer que le réseau n'a pas besoin d'une faille pour être modifier de façon créative.
Donc voila, je pense que selinux va bloquer assez efficacement la majorité des soucis, même si j'exclue pas qu'un truc passe à travers, ou qu'on puisse enchainer.
Quand à ssh, ça va marcher si le serveur ssh est openssh ou similaire, ie, un serveur ssh avec un shell. Je sais pas ce que ça donnerais sur les implémentations customs d'un serveur pour des besoins spécifiques ( genre github a son propre serveur git en ruby, si je me souviens bien, et ils semblent dire que leur service n'est pas vulnérable
https://github.com/blog/1893-security-vulnerability-in-bash-addressed donc je suppose que c'est pareil pour ssh ). Mais je suppose aussi que ce genre d'infrastructure est l'exception plus que la norme.
[^] # Re: Conflicts=sleep.target
Posté par Misc (site web personnel) . En réponse au journal Où systemd résout des problèmes de cifs. Évalué à 8.
En fait, c'est pas la mise en veille le souci, c'est le changement et ou la perte de la connectivité. La mise en veille est juste un déclencheur. Je peux par exemple avoir un point de montage non réseau qui continue de marcher ou qui va dépendre du fait que je retire un cable pendant que le pc est en veille. Ou mettre en veille et revenir dans le même réseau de façon transparente.
Intuitivement, je me dit que ça devrait être fait au niveau du filesystem, mais peut être que les sémantiques et que le code ne permet pas de faire ça de façon optimum.
# pas si validé que ça
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 7.
https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23
Il semblerais que ça ne soit pas fini. Bon, ben j'ai bien fait d'automatiser avec ansible mes upgrades d serveur.
[^] # Re: Whaou
Posté par Misc (site web personnel) . En réponse au journal Où systemd résout des problèmes de cifs. Évalué à 10.
A vue de nez, l'intégration. Cad que je mets mon pc en veille en fermant le capot, ça le fera tout seul.
Bien sur, si systemd l'a fait, alors tu peux le faire aussi en refaisant ce qu'il fait, cad en écoutant les événements en lançant ton truc suite à ça.
[^] # Re: Alternatives
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 7.
Sauf à faire pointer sh vers zsh, je pense que ça va pas changer grand chose. J'ai pas testé ce que ça donne avec dash par contre.
# Quitte à citer
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 10.
Quitte à pointer vers une ressource du grand satan pousseur de systemd avec un chapeau rouge, autant pointer vers le blog qui explique les détails :
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
Et vers le thread sur oss-sec :
http://www.openwall.com/lists/oss-security/2014/09/24/10
Notamment
http://www.openwall.com/lists/oss-security/2014/09/24/12
Perso, j'ai pas de cgi, j'ai mon dhclient qui tourne avec un domaine selinux confiné. Et j'ai pas de serveur git avec forcecommand ( j'ai des rsync par contre, mais ça implique d'avoir la clé à priori ). Donc je vais pas stopper tout pour la mise à jour, je vais finir ma pizza ( au contraire de Linuxfr, qui lui est important )
maintenant, si vous avez gitolite, et que vous êtes dans un hotel chelou rempli de linuxien, ça me parait plus critique que pour moi :)
[^] # Re: Ah ah
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 6.
Marrant, moi, j'ai un service de base qui va lancer /etc/rc.d/rc.local start. Donc j'aurais tendance à dire que ça marche de base.
( l'unité, c'est /usr/lib/systemd/system/rc-local.service )
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 8.
Pour le moment, le mec a surtout retiré du code, et appliquer des patchs refusés upstream pour musl. L'argument des devs de systemd étant "il faut rajouter le code dans musl", et les devs de musl "il faut rajouter le code partout ailleurs" ( mais bon, y en a qu'un des 2 qui se fait traiter de fachiste pour refuser du code ).
Donc oui, c'est sur qu'en ne faisant que retirer du code d'une vielle version, ça va pas exploser. Bien sur, c'est intenable sur le long terme sauf à ce que rien d'autre ne bouge à coté.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 10.
Je suis pas d'accord. Je suis packageur depuis un numbre d'année à 2 chiffres, et j'ai vu les soucis que pose les scripts en bash, à savoir que tout le monde ne maitrise pas le bash, ce qui justement donne des soucis super compliqués.
J'ai donné les exemples de bind, sur debian sur openbsd etc lors des nombreuses discussions sur systemd, mais juste pour montrer les trucs récents sur ansible lié à des fichiers d'init foireux :
Le fichier de nginx sur ubuntu :
https://github.com/ansible/ansible/issues/9108
le fichier de proftpd
https://github.com/ansible/ansible/issues/9069
https://github.com/ansible/ansible/issues/7918
https://github.com/ansible/ansible/issues/6286
Postgresql :
https://github.com/ansible/ansible/issues/8183
https://github.com/ansible/ansible/issues/7695
Et pourquoi ? parce que les gens qui font les scripts se préoccupent pas des détails comme la synchronisation entre le script et le soft qui est geré, ou des détails comme filer les codes de retour.
Donc je pense que la séparation "j'ai vu comment ça marche, c'est moche", c'est faux. Les conséquences d'avoir du bash à tout les étages sont simple à piger, tu as des scripts dupliqués ( car personne n'envoie les scripts upstream et il y a pas d'unité dans ce que tu fais ), parfois de qualité inégale, du au fait que personne ne peux penser à tout à chaque fois, surtout quand ça requiert des compétences que tout le monde n'a pas ( genre, se préoccuper de l'automatisation, ça te viens pas à l'esprit quand tu es un packageur débutant ). Et tu le voit assez vite quand tu fait du mentoring auprès des nouveaux arrivants.
Ensuite, l'intégration de systemd est plus complexe que celle de sysvinit, mais c'est surtout parce que systemd bouge la ou sysvinit ne bouge pas. mais l'intégration de sysvinit n'etait pas non plus une partie de plaisir y a 6/7 ans quand les gens étaient encore en trian de le faire bouger, et que par exemple, mandriva devait refaire les patchs en bash sur le soft venant de Fedora/RH.
Il faut espérer que systemd va finir par se stabiliser un peu plus et innover moins, pour réduire ta charge de travail.
[^] # Re: Aucun, et, à quoi ça sert
Posté par Misc (site web personnel) . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 10.
Sur RHEL 7/Centos 7 et fedora je sais pas combien, les plugins firefox sont restreint via SELinux. Donc si jamais quelqu'un arrive à trouver une faille dans flash et la distribue via un réseau de pub, comme ça arrive souvent, ta clé ssh se fera pas faucher, sauf à contourner SElinux.
( tu peux aussi remplacer "clé ssh" par "fichier de mot de passe firefox" ).
Il me semble aussi qu'il y a eu des choses sur les outils qui font des vignettes, au cas ou tu trouves une clé usb avec un fichier vérolé qui fait planter l'outil de vignette.
Cf https://danwalsh.livejournal.com/54092.html
Je pense aussi que SElinux permet de s'assurer que le compte guest ( paquet xguest ) est vraiment limité, ce qui sert sur un kiosque.
Il permet également de limiter docker, qui est un outil assez à la mode en ce moment pour les devs ( donc sur un pc personnel ), et je suppose que selinux serviras aussi pour limiter les applications tierces pour ce que Gnome veut faire avec les histoires de sandbox.
[^] # Re: Browser wars
Posté par Misc (site web personnel) . En réponse au journal publicité mensongère de Google contre le libre. Évalué à 8.
et ça change tout au niveau de l'indépendance financière ?
[^] # Re: End of an era
Posté par Misc (site web personnel) . En réponse au journal Et comme prévu, ça a fait... pffffuit. Évalué à 2.
L'ipod avant quand même une capacité en disque bien plus grande que les autres sur le marché, en grande partie par la pénurie orchestré par Tim Cook qui a fait une razzia sur le stock mondiale, pour s'assurer d'avoir de l'avance ( ce que des gens qualifient de "génie logistique", d'autres d'" abus de position dominante" mais bon, ça ne s'applique que si l'histoire est vrai )
[^] # Re: Bien emballé
Posté par Misc (site web personnel) . En réponse au journal Et comme prévu, ça a fait... pffffuit. Évalué à 3.
Ou le fait de devoir aller à la boutique Apple pour prendre rendez vous pour faire reparer ton pc portable. Mais si tu commences à dire "le service client ne me satisfait pas", tu passes devant tout le monde.
[^] # Re: A l'heure du tout tactile,
Posté par Misc (site web personnel) . En réponse au journal Et comme prévu, ça a fait... pffffuit. Évalué à 10.
En fait, tu payes pas pour le produit, mais pour l'image que ça te donne. Il suffit de voir l'image qu'Apple associe à coup de publicité à ses produits, et le fait que tu bénéficies de la même aura inconsciemment.
Exemple, il suffit de voir les pubs à la télé ( pas celle de bouygues, celle pur Apple ), tu vois pas vraiment le produit. Tu vois quelqu'un qui voyage dans des paysages superbes, qui va à la découverte du monde ( Asie notamment ) en faisant de la danse, en discuttant avec quelqu'un dans un souk. C'est indéniablement un style de vie qui fait rêver, mais qui est couteux.
Ou tu prends la pub avec un compositeur solennelle dans sa voiture, en train de reflechir, etc et on termine en te disant "et vous, quel est votre rime", sous entendu "et toi, tu va aussi être un artiste ?". Et quand on parle d'artiste, on montre pas n'importe quoi, on parle de compositeur de musique classique, qui est ( à tort ) associé à une forme de bourgeoisie.
Bien sur, c'est hautement fabriqué et filtré comme vision, ça joue à fond sur les préjugés, voir ça les renforcent, mais ça marche.
Le fait de mettre un prix plus haut fait que forcément, tu te dit que c'est pour les riches. Donc si tu l'achètes, c'est que tu es riche. Et ça renforce l'envie. ( et le fait d'avoir des prix plus hauts donnent des marges qui compensent le fait d'avoir moins de vente dans un temps ).
Et tout est dans ce sens. les gens dans l'Apple store ne te présentent pas les fonctionnalités du téléphone, mais cherche à te faire parler, pour ensuite te dire comment le téléphone va s'intégrer dans ta vie à des moments clés via l'émotion ( l'exemple qu'on m'a donné, c'est qu'on va pas te dire "y a 2 camera X mega pixels avec tel feature", mais on va te dire que grace à la camera, tu peux faire une vidéo conférence après la naissance de ton fils avec ta famille.
C'est pas pour rien que Apple a débauché des gens du secteur de la mode comme VP. C'est parce qu'ils ont besoin de gens qui sont bien imprégné et qui maitrise le paraitre.
Et les exemples sont à l'infini, et si tu as le sens de l'observation et un peu de sens critique, tu peux difficilement l'éviter ( et plus ça va, plus tu en vois ). Greenpeace fait un rapport qui égratigne l'image d'Apple sur l’environnement, 2 ans après, ils ont tout changer pour dire "on est écolo" ( tant que c'était pas publique, ils s'en foutaient grave ). Et Tim cook en remets une couche face à un investisseur.
Si tu prends un appareil Apple, c'est marqué "designed in California" avec made in china tout petit, histoire de propager l'image de coolitude californienne ( silicon valley, etc ).
Ou la page web de la marque. On te dit pas "revoir la keynote", mais "revivre la keynote". Parce que revoir, c'est passif. Revivre, on te place directement la position d'un moment d'émotion.
Enfin voila, toi, tu va pas l'acheter parce que tu mets plus de valeurs à ta liberté, mais l'utilisateur moyen visé par Apple ne déborde pas de compétences informatiques ( être globalement super neu neu proof est quand même un des points de Os X tant que tu restes dans les clous, ce qui arrivent quand même pas en pratique ), donc ne va pas vraiment voir la problématique de la liberté sous le même angle que toi.
[^] # Re: en fait DEUX raccourcis clavier
Posté par Misc (site web personnel) . En réponse au sondage Pour éteindre/redémarrer mon ordinateur, j'utilise.... Évalué à 3.
Non, tu peux aussi utiliser H + alt, ça arrête le pc :p
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 3.
Je vois l'usage.
Je sais pas si systemd y réponds, et si un outil d'orchestration plus classique, voir juste un makefile ferait pas l'affaire par contre.
Un script maitre marcherais, mais je pense que l'idée est aussi d’intelligemment reprendre si ça s'arrête à un moment, ce qui est pas une chose qu'une simple exécution à la suite ferait. Ensuite, peut être que c'est overkill, et qu'il faudrait donc un outil plus spécialisé.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 10.
La réponse est sur https://hansdegoede.livejournal.com/14268.html
C'est pas tant systemd en tant que tel que le fait que logind gére la session ( cad s'assure que les accés sont revoqués quand il y en a plus besoin, etc ). Ensuite la question est pourquoi logind a besoin de systemd, et pourquoi personne n'a fait ça avant.
Logind a besoin d'un système qui va gérer les sessions de manière fiable ( cad sans fuite de process hors de la session ), et il se trouve que c'est l'un des points fort de systemd, cad via les cgroups. À son tour, la gestion des cgroups, pour être propre, requiert d'avoir un seul process qui gére ça ( histoire que l'état ne change pas sous nez et avec des races conditions ). A son tour, la gestion des process requiert d'avoir un PID1 qui est au courant du fait qu'il y a des cgroups pour les process. Soit il gére ça lui même ( ce que fait systemd ), soit il fait faire ça par un autre process ( ce que upstart aurait fait ).
Les devs de systemd est que pour éviter les races conditions et la fiabilité, c'est plus simple de faire ça dans un seul processus que dans 2 ( vu qu'il y a des délais, potentiellement des communications asynchrones, du code pour communiquer entre les 2 processus, et du code dans le premier pour relancer le 2eme, avec le code du 2eme pour relancer ce qu'il lance lui même, etc ). Donc c'est comme ça qu'on se retrouve avec logind qui a besoin de systemd, et systemd qui se retrouve avec le pid 1.
Je suis sur qu'on aurait pu le faire avant, mais si les premiers trucs au sujet de X sans root date de 2008 ( https://airlied.livejournal.com/59521.html ) et qu'il a fallu 6 ans pour faire les derniers pas, peut être que c'était pas si simple à faire de manière propre.