Bien sur, mais la centralisation me parait quand même assez inévitable. Il y a un avantage économique à se regrouper pour les acteurs donc soit ils le font, soit ils perdent l'avantage économique face à ceux qui le font. La mutualisation est donc naturel. Même dans le libre, quand on regarde bien.
Ensuite, le souci n'est pas la mutualisation/centralisation en soit, mais l'hyper centralisation. Et le souci n'est pas tant la centralisation que le cout pour un nouvelle entrant qui pourrait changer ça. La centralisation ne serait pas un si gros souci si quelqu'un pouvait venir et sans un effort trop couteux, combattre ça. IE, dans le cas du cloud, si tu peux concurrencer un peu les acteurs existants avec une fraction de leur moyen. Je ne sais pas à quel point c'est possible.
Depuis plusieurs mois, je lit les articles sur hacker news, qui sont assez souvent "silicon valley centric", et le destin d'une startup, c'est de se faire absorber par les gros ou de crever, ç'est assez flippant. IE, l'état "petite boite" est transitoire et personne ne le cache.
Pas le même protocole, même si ça réponds au même besoin haut niveau.
Mais on peut aussi rajouter "fait le dispatch vers des fichiers textes pour garder la compatibilité avec l'existant", chose que journald fait faire par syslog.
Sauf que la gestion n'est pas propre, "socket activation" en est
la preuve. Si la gestion était propre, un service réseau ne
démarrerait qu'après le réseau. Là, on fait croire au service
que le réseau est là alors qu'on a juste systemd et son socket
en carton …
Alors d'abord, ça veut rien dire "démarrer le réseau". Tu veux dire quoi, avoir une ip routable, un accès potable au net, juste avoir 'lo', avoir une ip interne, de l'ipv6 ou v4, avoir tout les interfaces lancés ?
Ensuite, les sockets, c'est aussi des sockets unix. Ça marche sans le réseau que je sache.
Enfin, l'activation par socket permet l'activation à la demande. exemple, ton serveur ssh qui sert une fois de temps en temps, pour pas que ça occupe de la ram ( oui, tu t'en fous sans doute avec 1 serveur ssh et 40G de ram, mais y a des gens avec moins de ram, ou avec plus qu'un serveur ssh, cf containeurs ).
L'activation permet aussi le démarrage dans un ordre non garanti, et permet de relancer en cas de crash.
Et puis bon, c'est juste ce que inetd fait, tu serait pas en train de dire qu'un truc d'unix serait pas propre ?
Alors tu serais surpris de voir qu'il y a quand même beaucoup de différences sur les distribution. Exemple, le cycle de release ( 2 ans, 6 mois, 8 mois, 9 mois , 2 ans glissant ), la gouvernance du projet, les méthodes de constructions, les choix techniques comme les installeurs, les outils de bases ( zypper, yum, etc ), et que chaque différence permet d'expérimenter.
D'ailleurs si on enlève le côté rapide de systemd, il ne reste
plus rien de bénéfique
De ton point de vue. De la part d'autres personnes, le coté "je suis capable de suivre les processus", c'est un bénéfice. Pour d'autres ( moi le premier ), la partie "environment propre" est un bénéfice appréciable. Le fait d'avoir des fichiers de configs lisibles et surchargeable sans magouille est un plus aussi.
Y a des gens qui sont content d'avoir une api dbus pour faire des outils plus haut niveau. Des gens content d'avoir un système de template générique, et pas des solutions ad-hoc qui se dupliquent les unes et les autres.
vu qu'il se plaignait d'autofs qui était une grosse loutre d'avant le passage à systemd, j'ai quand même des doutes. Je ne doute pas que ça soit deux soucis séparés, mais si systemd fait segfaulter autofs, j'aurais tendance à dire qu'autofs a un bug. Mais il est possible aussi que ça soit 2 soucis séparés entre le sien et le tien.
Les versions récentes de systemd intègrent un contournement
spécifique (peut-être était-il déjà dans les versions
précédentes sauf qu’il plantait).
C'est intéressant, tu as un commit que je comprenne un peu plus le détail, car la, une recherche ans le code ne montre rien de probant, et je pige pas ton histoire de cgroups. Les cgroups s'occupent des processus pour systemd et rien de plus, sauf si tu mets des limitations ( mais tu en parles pas, donc je vais pas supposer des trucs ).
IE, les cgroups servent pas d'isolation magique qui empêche quoi que ce soit.
Ce gadget ne joue pas dans la même cour qu’autofs : il ne
permet pas d’utiliser une table d’automontage située sur un
serveur (LDAP ou NIS).
Il n'a pas vocation à remplacer autofs non plus. Même si un générateur ferait l'affaire pour des cas simples, je pense pas que ça soit le but.
C’est le souci avec les services qui gravitent autour de
systemd : ils se multiplient mais ne font qu’une partie du
boulot des services qu’ils sont sensés remplacer (à
l’exception peut-être de journald).
C'est pas forcément remplacer, c'est souvent "offrir une fonction de base en laissant à d'autres le choix de faire plus".
Journald fait des trucs que syslog fait pas, les timers font des trucs que cron font pas, et vice versa. Exemple, syslog fait la partie "envoie vers un autre serveur syslog". cron envoie des mails avec la sortie des commandes, etc.
Bien sur, mais on peut remplacer openssh par toute les monocultures du libres. Bind, par exemple. Ou dhcpd pour rester dans ce que fait l'isc. Ou les libs qu'on trouve partout, genre libpng, libjpeg. Ou peut être des libs de crypto comme openssl, pour rester dans l'actualité.
Le problème avec systemd, c'est que cela t'impose un gros
changement, sur un composant plutôt immuable (l'init) alors
que tu ne t'es jamais vraiment posé de question à ce sujet.
Tout ça est joyeusement hackable car après tout ce n'est que
du shell, tu peux paralléliser comme bon te semble, genre:
"appel à script & " etc
alors, la parallélisation, ça requiert plus que de juste lancer les choses avec '&' et hop ça marche. Il y a besoin d'avoir un minimum de synchronisation, sauf si tu as des taches indépendantes. Il y a aussi besoin de passer proprement en background, etc, mais bon, c'est la base, et je ne doute pas que tu soit au courant des soucis que ça peut poser ( comme "ne pas pouvoir démonter un filesystéme", etc, etc )
Il y avait un post de Lennart qui expliquait les raisons de
tout changer. Ce post, que j'ai lu, ne m'a jamais vraiment
convaincu. Donc, pourquoi tout changer?
Parce qu'il a convaincu les gens qui décident, et les gens qui décident, c'est les gens qui contribuent. Le fait que tu n'es pas été convaincu change pas grand chose dans l'arrangement. Il faut quand même bien voir que les commandes services marchent encore, que les scripts d'init marchent encore. Que la majorité des commandes ( reboot, halt) marchent encore.
Maintenant, je me réjouis de voir que plus de gens vont sur les systémes BSD. Bien sur, j’espère que ça va être plus que de la simple utilisation, et que ces systèmes vont enfin avoir l'afflux de contributions pour les faire briller. Mais curieusement, j'ai des doutes.
Oui, mais ça reste avec la même version, ce n'est pas tout à
fait la même chose que recharger une nouvelle version.
Je suis pas sur que grand monde le fasse en pratique, le rechargement à chaud.
Ceci dit, c'est facile à tester, tu prends une vm fedora 19, tu fait un yum upgrade, tu recharges systemd et voila.
Le coeur du code est dans
./src/core/manager.c , fonction manager_deserialize et manager_serialize.
je pense qu'on peut considérer que manager_serialize va pas avoir de bug énorme, étant donné que c'est juste des printfs.
Du coté de manager_deserialize , soit c'est un reload, soit c'est un nouveau daemon. Si c'est un nouveau daemon et que la deserialization ne marche pas, systemd continue à tourner ( et donc à se lancer ), bien qu'il est possible que des process soient non gérés ou ce genre de choses ( vu que l'état n'a pas été transmis ). Bien que ça ne soit pas parfait, je pense que "systemd est encore mais le systéme est dans un état dégradé" est plus robuste que "le systéme est planté".
Par contre, l'impact potentiel d'une faille est-il plus élevé si > elle touche le cœur de systemd, vue l'ampleur de ses
prérogatives?
D'un point de vue purement surface d'attaque, je pense qu'il faut déjà définir de quoi on parle. Je pense que quand les gens disent "systemd", c'est le binaire principal ( /usr/lib/systemd/systemd ).
Donc si on doit évaluer les risques, il peut écouter sur le reseau, ce qui est mal, mais il ne fait aucun traitement , ce qui diminue fortement les risques ( le plus gros souci d'un service "network facing", c'est le traitement des données externes ). Le code critique est vraiment court, et à ce niveau, il fait la même chose qu'openssh ( qui tourne aussi en root ), il recoit le socket, et il forke.
le pid 1 tourne en root, ce qui est aussi en sa défaveur, mais pas pire que iodine ou d'autres serveurs qui tourne en root. Le fait d'être pid 1 donne pas de droit spéciaux à ce niveau la dans un systéme unix, mais ça lui donne le droit de faire des transitions selinux. Ce qui est requis de part sa nature, et inévitable. Ensuite, comme beaucoup de gens ne l'utilisent pas, je pense que ça change pas grand chose à ce niveau.
Et toujours pour comparer avec openssh, openssh a aussi le droit de faire des transitions selinux un peu libre, vu qu'on peut se connecter avec sur n'importe quel uid.
Ensuite, on peut dire qu'il y a du traitement fait par systemd, mais en local. C'est vrai, ça réponds à des requêtes dbus et ce genre de choses, et je ne sais pas exactement par ou passe les données pour les logs. Donc je pense que ça reste limité en terme de traitement (parsing), ce qui diminue les risques d'autant, de part l'utilisation de choses plus haut niveau.
Donc au final, le risque est le même que celui d'une faille dans un serveur ssh, modulo le fait que systemd ne fait pas un traitement d'un protocole.
Le plus gros facteur de risque lié à openssh, c'est pas sa nature, c'est que son omniprésence, et c'est pareil dans le cas de systemd. Les années ont montrés que la monoculture ne semble pas déranger grand monde pour les serveurs ssh ( car franchement, qui tourne avec dropbear en dehors de l'embarqué, qui a entendu parler de lsh, qui s'est dit "pourquoi j'utiliserais pas mina sur mon serveur de prod" ), et qu'au final, tout le monde est d'accord pour dire "oui, faudrait faire un truc" mais n'applique pas en pratique. Et je pense que ça va être pareil pour systemd.
C'est vrai. En même temps, contrairement aux headers sous Linux
qui me font devenir chèvre à faire des milliards d'#include
partout pour trouver la définition d'un type ou la déclaration
d'une fonction, les BSD ont une hiérarchie des headers simple
qui fait qu'on trouve facilement ce qu'on cherche (enfin en tout
cas c'est mon expérience).
L'un comme les autres ont des pages de man pour les fonctions. Car bon, les headers, c'est bien joli, mais ça donne pas les infos potables.
même s'il y a un outil qui permet de recharger systemd, s'il
crache, on n'est bon pour un reboot matériel, ce qui n'est pas
toujours simple sur un serveur à distance.
Donc la machine ne fait pas de kernel panic, sauf si tu configure pour autre chose ( faire un coredump, ou lancer un shell ), et tourne encore. Donc tu peux encore faire un ssh, et relancer la machine quand tu veux.
Et bien sur, la partie sur "recharger systemd peut crasher", il faut savoir que systemd se recharge à chaque boot quand il passe de l'initrd au systéme normal :
$ ps fax | grep deseria | head -n 1
1 ? Ss 0:18 /usr/lib/systemd/systemd --system --deserialize 18
Donc je pense que le jour ou ça explose, ça se verras assez vite.
Nan mais ça viole l'esprit unix, tu piges pas. Au contraire de l'option -u de sort, qui duplique pas du tout ce que fait uniq. Au contraire de sed et awk qui font qu'une chose à la fois, au contraire de bash qui a l'option ( non active sur Debian ) d'ouvrir des sockets tcp (dupliquant nc/socat).
Au contraire des ACLs et de SELinux, qui viole l'esprit des permissions unix. Au contraire d'iptables qui viole le principe de "tout est fichier", tout comme les milliers d'ioctl.
Y en a une ou deux personnes qui le font, en essayant de garder upstart en état de marche, enfin en continuant l'intégration dans Debian, y a des gens qui bossent sur openrc. Mais en effet, la majorité a visiblement pas les compétences pour faire grand chose de plus que des articles de blog.
J'ai pas beaucoup plus d'expérience que vous en la matière, mais
je me demande surtout quel est l'avis d'un mainteneur de
sysvinit et de ses nombreux fichiers de script.
Alors je ne rentre pas exactement dans la catégorie que tu cherches ( j'ai maintenu plein de choses, mais pas sysvinit ), mais dans la mesure ou Arch, Mageia et Opensuse ont adoptés systemd ( et je dirais Fedora aussi ), je pense que les mainteneurs ont fait leur choix sans avoir le moindre soupçon de pression.
On m'a dit que altq n'est plus dans le kernel depuis 3j. Et il y a des gens qui ont portés pf sur netbsd. Donc bon, c'est faisable.
Tout comme des gens ont fait des portages de l'API doors de solaris, ou des gens qui ont fait tourner zfs sur freebsd et linux via fuse. C'est juste un boulot énorme.
Quand à carp, oui, c'est réimplementable, tout comme des gens ont refait une implémentations de certains API de systemd, suffit de suivre le protocole.
Mais c'est vrai que je trouve difficilement des choses aussi étroitement lié à un kernel, en dehors du kernel et utilisant beaucoup d'api spécifique du kernel.
Le travail est pas non plus exactement le même, porter une lib C est un daemon qui dépend de fonctions non présente dans les autres kernels, c'est pas exactement la même chose. J'attends de voir une équipe qui va porter openbgpd qui sont bien plus dépendant du kernel d'openbsd qu'openssh ou libressl puisse l'être. Ou le portage de pf/altq sur linux.
À la différence que "vous avez le droit de forker" est faciliter par l'usage de git de base. Et pas du bla bla sur "si on laisse les gens forker, plus personne ne va tourner sur la version HEAD donc on va garder CVS" comme le dit Theo.
docker + selinux pour la sécurité + ostree pour les updates atomics + cockpit pour l'interface web et systemd pour la gestion des limites et la centralisation des logs. Le tout sur une base de distro qu'on connait ( fedora/centos pour le moment, mais rien n'empeche de prendre de la debian si quelqu'un code la partie qui fait un arbre ostree à partir d'un .deb, l'auteur serait très heureux d'ajouter ça )
Rajoute aussi geard, pour orchestrer les containers et les déployer, et source-to-image, qui va prendre un depot git et le combiner avec une image docker pour le deployer directement dans atomic ( https://github.com/openshift/docker-source-to-images ).
Quoi, ce groupe mené par un leader "éclairé" écrit encore du code propre à une platforme pour laisser les autres dans la panade en forçant l'usage d'API qui sont en dehors de la norme POSIX et d'UNIX, c'est quoi ce bordel, combien de temps est ce qu'on va tolérer les débordements de sys…. Ah, on me signale dans l'oreillette que c'est pas Lennart, donc c'est parfaitement acceptable de faire ça, pardon pour l'intervention.
( pour clarifier, je ne critique pas le fait que openbsd le fasse, c'est leur droit, mais je note juste le double standard à ce sujet, et en fait, juste pour lancer le débat qu'autre chose )
[^] # Re: Toujours le même problème: centralisation
Posté par Misc (site web personnel) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 3.
Bien sur, mais la centralisation me parait quand même assez inévitable. Il y a un avantage économique à se regrouper pour les acteurs donc soit ils le font, soit ils perdent l'avantage économique face à ceux qui le font. La mutualisation est donc naturel. Même dans le libre, quand on regarde bien.
Ensuite, le souci n'est pas la mutualisation/centralisation en soit, mais l'hyper centralisation. Et le souci n'est pas tant la centralisation que le cout pour un nouvelle entrant qui pourrait changer ça. La centralisation ne serait pas un si gros souci si quelqu'un pouvait venir et sans un effort trop couteux, combattre ça. IE, dans le cas du cloud, si tu peux concurrencer un peu les acteurs existants avec une fraction de leur moyen. Je ne sais pas à quel point c'est possible.
Depuis plusieurs mois, je lit les articles sur hacker news, qui sont assez souvent "silicon valley centric", et le destin d'une startup, c'est de se faire absorber par les gros ou de crever, ç'est assez flippant. IE, l'état "petite boite" est transitoire et personne ne le cache.
[^] # Re: Lennux Is Not UniX
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 2.
Pas le même protocole, même si ça réponds au même besoin haut niveau.
Mais on peut aussi rajouter "fait le dispatch vers des fichiers textes pour garder la compatibilité avec l'existant", chose que journald fait faire par syslog.
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
Alors d'abord, ça veut rien dire "démarrer le réseau". Tu veux dire quoi, avoir une ip routable, un accès potable au net, juste avoir 'lo', avoir une ip interne, de l'ipv6 ou v4, avoir tout les interfaces lancés ?
Ensuite, les sockets, c'est aussi des sockets unix. Ça marche sans le réseau que je sache.
Enfin, l'activation par socket permet l'activation à la demande. exemple, ton serveur ssh qui sert une fois de temps en temps, pour pas que ça occupe de la ram ( oui, tu t'en fous sans doute avec 1 serveur ssh et 40G de ram, mais y a des gens avec moins de ram, ou avec plus qu'un serveur ssh, cf containeurs ).
L'activation permet aussi le démarrage dans un ordre non garanti, et permet de relancer en cas de crash.
Et puis bon, c'est juste ce que inetd fait, tu serait pas en train de dire qu'un truc d'unix serait pas propre ?
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 6.
Alors tu serais surpris de voir qu'il y a quand même beaucoup de différences sur les distribution. Exemple, le cycle de release ( 2 ans, 6 mois, 8 mois, 9 mois , 2 ans glissant ), la gouvernance du projet, les méthodes de constructions, les choix techniques comme les installeurs, les outils de bases ( zypper, yum, etc ), et que chaque différence permet d'expérimenter.
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 6.
De ton point de vue. De la part d'autres personnes, le coté "je suis capable de suivre les processus", c'est un bénéfice. Pour d'autres ( moi le premier ), la partie "environment propre" est un bénéfice appréciable. Le fait d'avoir des fichiers de configs lisibles et surchargeable sans magouille est un plus aussi.
Y a des gens qui sont content d'avoir une api dbus pour faire des outils plus haut niveau. Des gens content d'avoir un système de template générique, et pas des solutions ad-hoc qui se dupliquent les unes et les autres.
[^] # Re: Lennux Is Not UniX
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 3.
vu qu'il se plaignait d'autofs qui était une grosse loutre d'avant le passage à systemd, j'ai quand même des doutes. Je ne doute pas que ça soit deux soucis séparés, mais si systemd fait segfaulter autofs, j'aurais tendance à dire qu'autofs a un bug. Mais il est possible aussi que ça soit 2 soucis séparés entre le sien et le tien.
C'est intéressant, tu as un commit que je comprenne un peu plus le détail, car la, une recherche ans le code ne montre rien de probant, et je pige pas ton histoire de cgroups. Les cgroups s'occupent des processus pour systemd et rien de plus, sauf si tu mets des limitations ( mais tu en parles pas, donc je vais pas supposer des trucs ).
IE, les cgroups servent pas d'isolation magique qui empêche quoi que ce soit.
Il n'a pas vocation à remplacer autofs non plus. Même si un générateur ferait l'affaire pour des cas simples, je pense pas que ça soit le but.
C'est pas forcément remplacer, c'est souvent "offrir une fonction de base en laissant à d'autres le choix de faire plus".
Journald fait des trucs que syslog fait pas, les timers font des trucs que cron font pas, et vice versa. Exemple, syslog fait la partie "envoie vers un autre serveur syslog". cron envoie des mails avec la sortie des commandes, etc.
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 2.
Bien sur, mais on peut remplacer openssh par toute les monocultures du libres. Bind, par exemple. Ou dhcpd pour rester dans ce que fait l'isc. Ou les libs qu'on trouve partout, genre libpng, libjpeg. Ou peut être des libs de crypto comme openssl, pour rester dans l'actualité.
Ou pour parler de risques juridiques, le kernel lui même avec SCO, ou le fait que la glibc avait du code sans une license correct ( https://blogs.oracle.com/webmink/entry/old_code_and_old_licenses )
J'ai pris l'exemple d'openssh pour le programme en lui même. Mais des trucs sur la monocultures, j'en ai à la pelle.
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
Je veux bien te croire, mais le fait est que des gens se posent des questions à ce sujet. Sun, Apple, Gentoo, Canonical. Ils se sont tous posés des questions, et ils ont donnés une réponse. Les *BSDs aussi, http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-156/rcNG-l-anti-systemd
alors, la parallélisation, ça requiert plus que de juste lancer les choses avec '&' et hop ça marche. Il y a besoin d'avoir un minimum de synchronisation, sauf si tu as des taches indépendantes. Il y a aussi besoin de passer proprement en background, etc, mais bon, c'est la base, et je ne doute pas que tu soit au courant des soucis que ça peut poser ( comme "ne pas pouvoir démonter un filesystéme", etc, etc )
Et encore une fois, au risque de radoter :
https://bugs.gentoo.org/show_bug.cgi?id=391945
Parce qu'il a convaincu les gens qui décident, et les gens qui décident, c'est les gens qui contribuent. Le fait que tu n'es pas été convaincu change pas grand chose dans l'arrangement. Il faut quand même bien voir que les commandes services marchent encore, que les scripts d'init marchent encore. Que la majorité des commandes ( reboot, halt) marchent encore.
Maintenant, je me réjouis de voir que plus de gens vont sur les systémes BSD. Bien sur, j’espère que ça va être plus que de la simple utilisation, et que ces systèmes vont enfin avoir l'afflux de contributions pour les faire briller. Mais curieusement, j'ai des doutes.
[^] # Re: Systemd et crash
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 6.
Je suis pas sur que grand monde le fasse en pratique, le rechargement à chaud.
Ceci dit, c'est facile à tester, tu prends une vm fedora 19, tu fait un yum upgrade, tu recharges systemd et voila.
Le coeur du code est dans
./src/core/manager.c , fonction manager_deserialize et manager_serialize.
je pense qu'on peut considérer que manager_serialize va pas avoir de bug énorme, étant donné que c'est juste des printfs.
Du coté de manager_deserialize , soit c'est un reload, soit c'est un nouveau daemon. Si c'est un nouveau daemon et que la deserialization ne marche pas, systemd continue à tourner ( et donc à se lancer ), bien qu'il est possible que des process soient non gérés ou ce genre de choses ( vu que l'état n'a pas été transmis ). Bien que ça ne soit pas parfait, je pense que "systemd est encore mais le systéme est dans un état dégradé" est plus robuste que "le systéme est planté".
Le code
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/manager.c#n959
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c#n1663
On note qu'une erreur est affiché, mais que ça continue.
Si c'est un reload, ça se passe ici :
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/manager.c#n2335
Et si c'est un reload, et que ça plante, le manager continue.
Donc je veux bien croire que des bugs arrivent, mais les précautions pour ne pas se vautrer trop lamentablement sont la.
[^] # Re: Tout s'éclaire
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 9.
Tu oublies aussi "debian et le support étendu, pour éviter systemd ?".
Et "openbsd forke openssl, Theo De Raddt refuse de communiquer sur l'implication de systemd dans sa décision"
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
D'un point de vue purement surface d'attaque, je pense qu'il faut déjà définir de quoi on parle. Je pense que quand les gens disent "systemd", c'est le binaire principal ( /usr/lib/systemd/systemd ).
Donc si on doit évaluer les risques, il peut écouter sur le reseau, ce qui est mal, mais il ne fait aucun traitement , ce qui diminue fortement les risques ( le plus gros souci d'un service "network facing", c'est le traitement des données externes ). Le code critique est vraiment court, et à ce niveau, il fait la même chose qu'openssh ( qui tourne aussi en root ), il recoit le socket, et il forke.
le pid 1 tourne en root, ce qui est aussi en sa défaveur, mais pas pire que iodine ou d'autres serveurs qui tourne en root. Le fait d'être pid 1 donne pas de droit spéciaux à ce niveau la dans un systéme unix, mais ça lui donne le droit de faire des transitions selinux. Ce qui est requis de part sa nature, et inévitable. Ensuite, comme beaucoup de gens ne l'utilisent pas, je pense que ça change pas grand chose à ce niveau.
Et toujours pour comparer avec openssh, openssh a aussi le droit de faire des transitions selinux un peu libre, vu qu'on peut se connecter avec sur n'importe quel uid.
Ensuite, on peut dire qu'il y a du traitement fait par systemd, mais en local. C'est vrai, ça réponds à des requêtes dbus et ce genre de choses, et je ne sais pas exactement par ou passe les données pour les logs. Donc je pense que ça reste limité en terme de traitement (parsing), ce qui diminue les risques d'autant, de part l'utilisation de choses plus haut niveau.
Donc au final, le risque est le même que celui d'une faille dans un serveur ssh, modulo le fait que systemd ne fait pas un traitement d'un protocole.
Le plus gros facteur de risque lié à openssh, c'est pas sa nature, c'est que son omniprésence, et c'est pareil dans le cas de systemd. Les années ont montrés que la monoculture ne semble pas déranger grand monde pour les serveurs ssh ( car franchement, qui tourne avec dropbear en dehors de l'embarqué, qui a entendu parler de lsh, qui s'est dit "pourquoi j'utiliserais pas mina sur mon serveur de prod" ), et qu'au final, tout le monde est d'accord pour dire "oui, faudrait faire un truc" mais n'applique pas en pratique. Et je pense que ça va être pareil pour systemd.
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 3.
L'un comme les autres ont des pages de man pour les fonctions. Car bon, les headers, c'est bien joli, mais ça donne pas les infos potables.
(ensuite, c'est en effet chiant pour les types)
# Systemd et crash
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
Non.
Quand systemd crashe, il se passe ça :
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c#n120
La mise en place du signal handler est la :
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c#n212
Et il va dans la fonction 'freeze', ou il tourne dans une boucle passive.
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n3459
Donc la machine ne fait pas de kernel panic, sauf si tu configure pour autre chose ( faire un coredump, ou lancer un shell ), et tourne encore. Donc tu peux encore faire un ssh, et relancer la machine quand tu veux.
Et bien sur, la partie sur "recharger systemd peut crasher", il faut savoir que systemd se recharge à chaque boot quand il passe de l'initrd au systéme normal :
$ ps fax | grep deseria | head -n 1
1 ? Ss 0:18 /usr/lib/systemd/systemd --system --deserialize 18
Donc je pense que le jour ou ça explose, ça se verras assez vite.
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
Nan mais ça viole l'esprit unix, tu piges pas. Au contraire de l'option -u de sort, qui duplique pas du tout ce que fait uniq. Au contraire de sed et awk qui font qu'une chose à la fois, au contraire de bash qui a l'option ( non active sur Debian ) d'ouvrir des sockets tcp (dupliquant nc/socat).
Au contraire des ACLs et de SELinux, qui viole l'esprit des permissions unix. Au contraire d'iptables qui viole le principe de "tout est fichier", tout comme les milliers d'ioctl.
[^] # Re: But du site ?
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
Tu veux dire, faire du vrai travail ?
Y en a une ou deux personnes qui le font, en essayant de garder upstart en état de marche, enfin en continuant l'intégration dans Debian, y a des gens qui bossent sur openrc. Mais en effet, la majorité a visiblement pas les compétences pour faire grand chose de plus que des articles de blog.
[^] # Re: Lennux Is Not UniX
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 4.
ça marche aussi correctement sur le serveur en mageia de mon coloc, sur mon serveur en EL 7, et sur mon serveur en Fedora.
Ceci dit, mon coloc semble aussi se plaindre d'autofs qui segfault et se vautre.
Donc j'aurais tendance plus à dire que c'est un souci spécifique à autofs. Tu as utilisé l'implémentation dans systemd ?
http://www.freedesktop.org/software/systemd/man/systemd.automount.html
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 9.
Alors je ne rentre pas exactement dans la catégorie que tu cherches ( j'ai maintenu plein de choses, mais pas sysvinit ), mais dans la mesure ou Arch, Mageia et Opensuse ont adoptés systemd ( et je dirais Fedora aussi ), je pense que les mainteneurs ont fait leur choix sans avoir le moindre soupçon de pression.
Sinon:
http://www.piware.de/2014/04/booting-ubuntu-with-systemd-test-packages-available/
visiblement, même su ubuntu, ça marche quasiment sans modif.
[^] # Re: "on retrouve certains points plus valides"
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 5.
Et pour être précis, c'est optionnel.
http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n664
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 2.
On m'a dit que altq n'est plus dans le kernel depuis 3j. Et il y a des gens qui ont portés pf sur netbsd. Donc bon, c'est faisable.
Tout comme des gens ont fait des portages de l'API doors de solaris, ou des gens qui ont fait tourner zfs sur freebsd et linux via fuse. C'est juste un boulot énorme.
Quand à carp, oui, c'est réimplementable, tout comme des gens ont refait une implémentations de certains API de systemd, suffit de suivre le protocole.
Mais c'est vrai que je trouve difficilement des choses aussi étroitement lié à un kernel, en dehors du kernel et utilisant beaucoup d'api spécifique du kernel.
[^] # Re: ...
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 7.
C'est pas parce qu'il est audité qu'on trouve 100% des failles. Les erreurs, ça arrive à tout le monde.
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 3.
Le travail est pas non plus exactement le même, porter une lib C est un daemon qui dépend de fonctions non présente dans les autres kernels, c'est pas exactement la même chose. J'attends de voir une équipe qui va porter openbgpd qui sont bien plus dépendant du kernel d'openbsd qu'openssh ou libressl puisse l'être. Ou le portage de pf/altq sur linux.
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 7.
À la différence que "vous avez le droit de forker" est faciliter par l'usage de git de base. Et pas du bla bla sur "si on laisse les gens forker, plus personne ne va tourner sur la version HEAD donc on va garder CVS" comme le dit Theo.
# Et project atomic ?
Posté par Misc (site web personnel) . En réponse à la dépêche Logiciels pour survivre avec Docker. Évalué à 8.
Sinon, y a ça qui a été annoncé la semaine dernière :
http://www.projectatomic.io/
docker + selinux pour la sécurité + ostree pour les updates atomics + cockpit pour l'interface web et systemd pour la gestion des limites et la centralisation des logs. Le tout sur une base de distro qu'on connait ( fedora/centos pour le moment, mais rien n'empeche de prendre de la debian si quelqu'un code la partie qui fait un arbre ostree à partir d'un .deb, l'auteur serait très heureux d'ajouter ça )
Rajoute aussi geard, pour orchestrer les containers et les déployer, et source-to-image, qui va prendre un depot git et le combiner avec une image docker pour le deployer directement dans atomic ( https://github.com/openshift/docker-source-to-images ).
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 10.
Quoi, ce groupe mené par un leader "éclairé" écrit encore du code propre à une platforme pour laisser les autres dans la panade en forçant l'usage d'API qui sont en dehors de la norme POSIX et d'UNIX, c'est quoi ce bordel, combien de temps est ce qu'on va tolérer les débordements de sys…. Ah, on me signale dans l'oreillette que c'est pas Lennart, donc c'est parfaitement acceptable de faire ça, pardon pour l'intervention.
( pour clarifier, je ne critique pas le fait que openbsd le fasse, c'est leur droit, mais je note juste le double standard à ce sujet, et en fait, juste pour lancer le débat qu'autre chose )
[^] # Re: Et les algorithmes GOST ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 9.
Donc il faut se concentrer sur les algos apatrides ?
Ça va être chaud, non ?