RedHat, que tu sembles tant aimer, supporte encore un kernel
2.6.18 en 2014. Je ne crois pas que ce soit encore upstream.
Donc cela ne semble pas infaisable.
Je pense aussi que c'est faisable, mais je pense aussi que Canonical n'a pas les moyens qu'a Red Hat en terme de dev à temps plein, donc je peux dans une certaine mesure comprendre les doutes des gens.
Tout le monde demande du MySQL, de plus :
- Tu peux installer MariaDB à partir des repo
- Très peu de distributions utilisent MariaDB par défaut, donc
il ne faut pas pointer du doigt Ubuntu comme si c'était une
exception.
Je pense que la raison, c'est plus le coté totalement faux jeton de Mark Shuttleworth vis à vis d'Oracle. Tout comme Mark a fait un volte face sur le bug #1, il fait de la com pour faire plaisir à Oracle, car les devs Oracles sont venus tout d'un coup faire du taf avec les distros le jour ou les gens ont dit "tiens, et si on prenait Mariadb à la place, car Oracle ferme trop Mysql". Et pour moi, c'est clairement parce que RHEL part sur du Mariadb par défaut dans la 7 que Canonical tente de se distinguer car sinon, ça part pour être libreoffice vs openoffice à nouveau.
Pour le reste, c'est pas parce qu'ils n'ont aucune compéténce en
lutherie que le violoniste ou le simple mélomane ne sont pas
habilités à juger de la qualité d'un instrument (les luthiers ne
fabriquent pas les violons pour d'autres luthiers).
Ils ne jugent pas l'instrument, mais le son qu'on arrive à en tirer, et autant la prestation de la personne que l'instrument.
Ici, on a clairement des gens qui vont pas voir les résultats. Et je doute aussi que de nombreux mélomanes viennent sortir des arguments comme "mais ce violon contredit les principes de Stradivari" ( à prendre pour l'argument des principes Unix ) ou "mais non, regarde, c'est aussi facile de jouer avec les cordes mises comme ça, mais ça joue pas toute les notes, mais je m'en fout, j'ai pas besoin du Do mineur, et j'ai jamais eu le cas ou je devais me servir de plus d'une corde à la fois" ( à prendre pour les nombreux exemples de scripts d'init du thread ).
Je pense qu'il y a une incompréhension. Le premier message, il dit "on va permettre de le compiler pour un usage ou systemd n'est pas lancer".
"After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially."
Jamais il ne dit ou promer comment il faut le compiler, il parle juste d'usage après build.
Le second message dit la même chose, d'une autre façon. Je comprends que ça soit pas ce que tout le monde veuille et un peu plus de clarté aurait sans doute grandement éviter les incompréhensions, mais en relisant bien, c'était marqué noir sur blanc.
Le but ici était de montrer que l'on peut faire des scripts
bash aussi court que systemd.
Parfait, et mon but est de montrer que faire des scripts bash, ça donne en général des scripts incorrects dans des cas d'usages qui sont pas totalement farfelus.
Docker ne faisant pas parti de slackware (ni de debian) donc
ça ne me choque pas plus que ça.
Les outils lxc vont avoir les mêmes soucis, et ils sont disponibles sur Slackware de ce qu'on me dit. Docker fait parti de Debian, cf https://packages.debian.org/fr/sid/docker.io .
Mais y a pas que docker/lxc/vserver/openvz/etc, y a aussi les bons vieux chroots. Même si c'est mal de part l'isolation inexistante entre le chroot et dehors, le souci est le même, et des gens qui ont des systèmes dans des chroots, y en a.
Critiquer des options (restart/stop…) que ne fait pas systemd
c'est plutôt marrant quand même. Par curiosité, tu fais
comment l'équivalent sous systemd ?
L'équivalent de quoi, de stop, start ? C'est déjà de base. Y a stop, start, reload, restart, try-restart, reload-or-restart, reload-or-try-restart. Et c'est fait sans avoir à copier coller que restart, c'est stop + start X fois, etc.
Bémol quand même, il ne faut pas oublier l'épisode udev. Le fait
d'intégrer (en revenant sur sa parole) pareille pièce à systemd
ça s'appelle quand même forcer la main.
Qui est revenu sur sa parole ?
Que je sache, le mainteneur du code d'udev l'a fait de manière consciente et volontaire upstream.
Et bon, faut pas oublier que personne ne force la mise à jour d'un soft, que udev a été forké par des devs Gentoo ( fork que pas grand monde semble utiliser à vue de nez ), donc le mainteneur downstream avait largement les moyens d'éviter qu'on force quoi que ce soit. Donc ta vision me semble ne pas coller avec la réalité documenté.
Car c'est bien connu, dès que tu installes un BSD, en sus des
orgasmes portés à 180 minutes tu deviens développeur système.
Au vue du nombre de gens qui s'estiment compétent en design de système unix qui postent régulièrement sur les news et journaux en rapport avec systemd, oui. Ou alors, c'est la premise "compétent en design de système" qui est fausse, car "avoir le temps pour contribuer" est déjà réglé. Si tu as le temps de poster sur linuxfr, tu as le temps de coder.
Ce script la à un bug en plus. Si tu utilises docker, alors les processus dans le container sont visibles de l'extérieur.
Exemple:
$ docker run -i -t ubuntu /bin/bash
# vi
et sur un autre terminal:
$ ps fax | grep -A 2 /bin/docker
13583 ? Ssl 0:00 /usr/bin/docker -d
14007 pts/3 Ss 0:00 \_ /bin/bash
14054 pts/3 S+ 0:00 \_ vi
Donc "killall vi" en root lancé en dehors du docker va tuer le processus vi dans le container docker ( ie, du lxc tout con ).
Si tu remplaces vi par httpd, tu as un bug, sauf à vouloir que ton script httpd externe tue le processus qu'il lance et celui lancé ailleurs.
Et je passe sur le fait que httpd peut aussi lancer des processus qui s'appelle pas "httpd", au hasard, tout les processus wsgi lancé par mod_wsgi, et qu'ils vont totalement être oublié en cas de problème par le "killall httpd". IE, le nettoyage est incomplet.
Ensuite, dans l'action restart, le signal envoyé par le script est SIGTERM. Ce qui veut dire qu'un processus peut l'ignorer et/ou ne pas le traiter à temps, et donc que apache peut continuer de tourner, ce qui fait que le démarrage va échouer. Bien sur, jamais apache n'est surchargé et jamais il ne va mettre trop longtemps à mourir. Et jamais personne ne va injecter du code dans un processus apache via un interpréteur embarqué php. Car bon, tout le monde a retiré mod_php, qui tourne dans le même espace mémoire qu'apache par design, non ?
(et je parle pas d'attaque sr le code de php, je parle d'une personne qui va utiliser pcntl_signal en php dans une page pour dire à apache d'ignorer SIGTERM ou ce genre de trucs crades. J'ai pas testé, mais je serais pas étonné que ça marche).
Mais bon, j'imagine que "utiliser des containeurs" et "avoir des processus apache qui partent modérément en sucette" arrive pas si souvent, c'est juste la faute à pas de chance, et qu'on peut continuer à garder des scripts rempli de boilerplates et de bugs parce que c'est mieux (tm) ?
Non ! C’est justement en voulant à tout prix essayer de gérer
les 0.1% (et encore) de cas tordus directement dans le script
qu’on en est venu à des scripts d’init de deux cents lignes
Je suis pas sur que les coupures de courant et l'usage de puppet/ansible/etc rentre dans les 0.1%. Surtout les coupures de courant. Parce que bon, si tu veux faire un script buggué pour toi en te disant "ça a pas besoin d'être robuste", pas de souci, mais tu comprends bien que les gens qui font des softs pour les autres (exemple, les distributions) veulent des solutions plus solide que ton script, et donc que pour eux, il faut soit avoir des scripts qui font des trucs que tu trouves inutiles, soit se prendre des bugs et la réputation de faire du taf de merde ( réputation à juste titre ).
D’ailleurs, que propose systemd dans ce cas de figure ?
De lancer le soft en premier plan, donc il peut connaitre le pid sans souci. Ou de faire comme d'hab, utiliser les cgroups. Le fichier de pid sert juste à signaler "je suis prêt" et à donner le nom du PID, mais sinon, je pense que l'option "GuessMainPID" doit marcher si tu insistes sur "passer en arrière plan".
En fait, en cherchant un peu, j'ai trouvé d'autres soucis.
4) ton script s'appuie sur le pid, donc si on perds le fichier, on perds une partie de l'etat. Pire encore, si on reboote la machine brutalement ( coupure de courant ), le fichier pid reste la, et bloque le démarrage de stunnel. Ou, si stunnel écrase le fichier existant, alors on peut imaginer l'inverse, on lance 2 fois le script ( cf point 6 ), et le 2eme fait qu'on perds le pid du premier, sauf si stunnel n'écrit pas le pid car le premier est lancé.
Et je parle pas d'avoir /var/lib en readonly ( livecd, etc ). Mais bon, c'est un détail, on peut supposer trivialement que ça se trouve dans /var/run, un truc poussé par systemd au passage.
C'est un tmpfs donc ça régle le souci.
5) il n'y a aucun nettoyage de l’environnement. Si ma locale est en français, alors stunnel sera en français, avec ce que ça implique ( message de log, format des dates, etc ). Parfois, ça change rien. Et parfois, ça change. Et comme c'est un script, tu peux toujours avoir quelqu'un qui le lance en dehors de service ou équivalent. Un souci que systemd n'a pas en forçant le passage par systemctl.
6) ton script ne renvoie pas de code de retour différents pour status. Donc un outil comme puppet va pas réussir à voir si le logiciel est lancé ou pas. Et les codes de retour sont spécifiés dans la LSB. Encore une fois, systemd unifie ça et évite de refaire le code à chaque fois.
7) Il se passe quoi si stunnel mets plus d'une seconde à s’arrêter, et que tu fais un restart ( genre ta machine est bien surchargé avec plein de load ). Réponse, il se relance pas, parce que le stop ne garanti pas que le process est coupé. C'est aussi un souci que systemd gère correctement ( en étant sur que les processus sont morts, dans le cgroup ).
Tout ça, ça se corrige dans ton script. Mais c'est surtout pour montrer que c'est pas aussi simple que ça de faire un truc robuste ( car bon, en dehors des commentaires de Linuxfr, les machines ont des coupures de courants, les machines ont du load, les gens utilisent puppet/ansible, les processus se plantent, les gens font des erreurs de config ).
je vois un certain nombre de souci avec ton script.
1) il se passe quoi si la config de stunnel fait que le pid est ailleurs ? Faut changer le script. mais du coup, comme le script est sous le controle du gestionnaire de paquet, y a un conflit si le packageur mets à jour le script.
2) tu part du principe que le PID dans $PIDFILE est celui de stunnel. C'est une supposition dangereuse à faire. Par exemple, stunnel crash ( un bon segfault des familles ), le pid est repris par un autre process. Tu fait un status, il va te dire que stunnel tourne, alors que non. Du coup, tu fait un stop. Et le process qui a repris le PID se fait tuer.
3) il se passe quoi si quelqu'un configure stunnel par erreur pour ne pas passer en background ? Le script bloque. En fonction du systéme d'init, ça peut bloquer le boot.
Alors bien sur, systemd va pas forcément résoudre le point 1. mais systemd va te dire "le fichier PID n'est pas la, j'ai un souci" si tu utilises PIDFile et que rien n'apparait. Systemd va pas avoir le souci du 2. Et pour le 3, c'est pareil, systemd va voir qu'il y a un souci, et comme il fforke avant de lancer, il va pas bloquer quoi que ce soit.
C'est exactement ce que fait inetd. Et comme stunnel est à TLS
ce que inetd est à IP, pourquoi systemd ne prend pas en charge
l'initialisation des sockets TLS, dans leur logique ça devrait
être le cas ?
Si c'est pas le cas, alors ta vision de la logique des developpeurs est fausse.
Il me semblait qu'une gestion des dépendances permettaient de
lancer les services dans un ordre correct et non pas dans
n'importe quel ordre.
Si tu arrives à déterminer quand un service est effectivement démarré. C'est tout le noeud du problème. sysinit et d'autres s'en préoccuppent pas vraiment. Ça marche la plupart du temps, mais tu es obligé de faire ça en série, en partant du principe que ça démarre assez vite. parfois, tu rajoutes des sleep par ci par la, mais bon. On a vu le cas chez mandriva avec les cartes réseaux qui mettent 10 secondes à avoir leur ip, et les services notés "aprés le réseau" ne pas réussir à écouter comme il faut. Et puis parfois, tu as pas le souci, et tu sais pas ce qui est différent.
Upstart s'y prends différement. Il va suivre les process avec ptrace et voir le nombre de fork fait et à partir de la, dire "ok, il est lancé". C'est buggué, je vais pas revenir la dessus, j'ai collé les liens à chaque discussion sur systemd.
Donc la vrai solution, c'est que le service dise "je suis prêt".
D'ou la discussion sur le BTS Debian sur le sujet, avec l'idée d'utiliser sigstop (comme upstart ), refuser car posant divers souci. Systemd propose un protocole qui consiste à envoyer un message sur une socket donné par systemd lors du lancement, mais faut patcher le code des programmes, et ça se fait pas tout seul ( bien que de mon expérience, c'est pas le code le plus problématique, c'est les autotools ). Donc en attendant, il y a des heuristiques. On considére que le service est pret quand il a forké, quand il fait un fichier de pid, ou on utilise l'activation par socket, pour les cas ou "programme pret == programme qui écoute". Comme les sockets sont ouvertes avant de lancer toutes les unités, alors les dépendances ne sont plus importantes si la dépendance exprime juste "j'ai besoin de me connecter à tel service gére par la socket activation". Ça supporte dbus, les fifo, les messages netlink, etc, donc ç'est large. Ensuite, oui, si ton service depend d'un truc plus compliqué, alors la bonne façon, c'est de rajouter le protocole de notification, ou de faire comme avant, se dire que ça va marcher sans synchronisation.
systemd supporte-t-il l'activation pour les services utilisant
les "raw socket" (vrai question) ?
Non, pas que je sache. Je pense pas que ça soit super complexe à rajouter, et je suppose qu'un truc comme snort pourrait s'en servir, mais j'ai quand même du mal à voir des cas d'utilisation. Ceci dit, je garde l'idée le jour ou je m'ennuie et j'ai envie de faire du C.
Quand à la gestion des crash, c'est indépendant de
l'activation des socket de systemd et, pour faire juste, il
faudrait communiquer avec le service afin de contrôler son
fonctionnement. Le service peut sembler fonctionnel alors
qu'en fait il est planter, donc on est obliger de prévoir une
solution supplémentaire capable de parler le protocole du
service afin de s'assurer qu'il fonctionne correctement.
la réalité est plus compliqué que ça. Tu as plusieurs façons de planter, et c'est pas parce qu'un outil ne couvre pas tout les cas imaginables que couvrir 50% est inutile, loin de la. Déjà, tu peux faire de l'activation comme inetd avec 1 process par client. La, je pense que j'ai pas besoin de dire pourquoi ça marche quand le process se plante. Mais même avec 1 process pour tout les clients, il est relancé si jamais ça se gauffre, vu que c'est un retour l'état de début.
Quand à avoir un process qui ne marche pas mais qui tourne encore, il y a aussi un système de watchdog ou le process signal "je tourne encore" à intervalle régulier. Bien que ça ne règle pas le cas "je tourne mais je dit de la merd", ça donne un truc de plus entre le simple "le pid est la donc c'est bon" et le plus lourd "je lance une analyse compléte de la réaction du serveur" que ferait un nagios.
Il faut bien voir que plus un test est léger, plus on peut le lancer souvent. Exemple, voir qu'un process est planté pour systemd, c'est 3 fois rien. Mais plus il est leger, moins il couvre de choses. Dans le cas extrême d'un site, voir que 15 urls renvoient pas "error 500" en suivant un scénario web précis , c'est un chouia plus lourd, tu va pas le lancer tout les 10 secondes. Dans le cas d'un watchdog dans systemd, c'est un bete timer, et je pense que faire ça chaque 30 secondes ( ie, une écriture dans un socket ), c'est pas la mort.
Encore une fois, l'idée est pas de remplacer, mais de profiter de la poistion du gestionnaire d'init pour proposer des features en plus, à un autre endroit sur une échelle "precision/lourdeur" de test.
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.
[^] # Re: Pitoyable
Posté par Misc (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 4.
Je pense aussi que c'est faisable, mais je pense aussi que Canonical n'a pas les moyens qu'a Red Hat en terme de dev à temps plein, donc je peux dans une certaine mesure comprendre les doutes des gens.
Je pense que la raison, c'est plus le coté totalement faux jeton de Mark Shuttleworth vis à vis d'Oracle. Tout comme Mark a fait un volte face sur le bug #1, il fait de la com pour faire plaisir à Oracle, car les devs Oracles sont venus tout d'un coup faire du taf avec les distros le jour ou les gens ont dit "tiens, et si on prenait Mariadb à la place, car Oracle ferme trop Mysql". Et pour moi, c'est clairement parce que RHEL part sur du Mariadb par défaut dans la 7 que Canonical tente de se distinguer car sinon, ça part pour être libreoffice vs openoffice à nouveau.
[^] # 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é à 2.
Ils ne jugent pas l'instrument, mais le son qu'on arrive à en tirer, et autant la prestation de la personne que l'instrument.
Ici, on a clairement des gens qui vont pas voir les résultats. Et je doute aussi que de nombreux mélomanes viennent sortir des arguments comme "mais ce violon contredit les principes de Stradivari" ( à prendre pour l'argument des principes Unix ) ou "mais non, regarde, c'est aussi facile de jouer avec les cordes mises comme ça, mais ça joue pas toute les notes, mais je m'en fout, j'ai pas besoin du Do mineur, et j'ai jamais eu le cas ou je devais me servir de plus d'une corde à la fois" ( à prendre pour les nombreux exemples de scripts d'init du thread ).
[^] # 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é à 1.
Je pense qu'il y a une incompréhension. Le premier message, il dit "on va permettre de le compiler pour un usage ou systemd n'est pas lancer".
"After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially."
Jamais il ne dit ou promer comment il faut le compiler, il parle juste d'usage après build.
Le second message dit la même chose, d'une autre façon. Je comprends que ça soit pas ce que tout le monde veuille et un peu plus de clarté aurait sans doute grandement éviter les incompréhensions, mais en relisant bien, c'était marqué noir sur blanc.
[^] # Re: Il y a desktop et desktop.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 4.
Si tu fait des trucs comme "installer des tas de machines", il y Kickstart, tout comme dans la doc de RHEL.
On configure nos postes clients linux en ldap + kerberos via sssd grâce à ça. ( avec authentification offline possible ).
Y aussi l'intégration autofs :
https://fedoraproject.org/wiki/Features/SSSDAutoFSSupport
Sinon, y a comme depuis toujours authconfig qui fait exactement ça, en gtk et en mode texte.
Et puis, le dialogue que tu cherches existe encore, il est passé à firstboot, la 2nd partie de l'installeur :
https://fedoraproject.org/wiki/QA:Testcase_SSSD_LDAP_Identity_and_LDAP_Authentication
[^] # Re: USE="-systemd"
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 7.
Parfait, et mon but est de montrer que faire des scripts bash, ça donne en général des scripts incorrects dans des cas d'usages qui sont pas totalement farfelus.
Les outils lxc vont avoir les mêmes soucis, et ils sont disponibles sur Slackware de ce qu'on me dit. Docker fait parti de Debian, cf https://packages.debian.org/fr/sid/docker.io .
Mais y a pas que docker/lxc/vserver/openvz/etc, y a aussi les bons vieux chroots. Même si c'est mal de part l'isolation inexistante entre le chroot et dehors, le souci est le même, et des gens qui ont des systèmes dans des chroots, y en a.
L'équivalent de quoi, de stop, start ? C'est déjà de base. Y a stop, start, reload, restart, try-restart, reload-or-restart, reload-or-try-restart. Et c'est fait sans avoir à copier coller que restart, c'est stop + start X fois, etc.
[^] # 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é à 3.
Qui est revenu sur sa parole ?
Que je sache, le mainteneur du code d'udev l'a fait de manière consciente et volontaire upstream.
Et bon, faut pas oublier que personne ne force la mise à jour d'un soft, que udev a été forké par des devs Gentoo ( fork que pas grand monde semble utiliser à vue de nez ), donc le mainteneur downstream avait largement les moyens d'éviter qu'on force quoi que ce soit. Donc ta vision me semble ne pas coller avec la réalité documenté.
Au vue du nombre de gens qui s'estiment compétent en design de système unix qui postent régulièrement sur les news et journaux en rapport avec systemd, oui. Ou alors, c'est la premise "compétent en design de système" qui est fausse, car "avoir le temps pour contribuer" est déjà réglé. Si tu as le temps de poster sur linuxfr, tu as le temps de coder.
[^] # Re: USE="-systemd"
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 7.
En effet, voir ce thread :
https://linuxfr.org/users/claudex/journaux/chronique-des-dinosaures-retrogrades#comment-1534946
Ce script la à un bug en plus. Si tu utilises docker, alors les processus dans le container sont visibles de l'extérieur.
Exemple:
et sur un autre terminal:
Donc "killall vi" en root lancé en dehors du docker va tuer le processus vi dans le container docker ( ie, du lxc tout con ).
Si tu remplaces vi par httpd, tu as un bug, sauf à vouloir que ton script httpd externe tue le processus qu'il lance et celui lancé ailleurs.
Et je passe sur le fait que httpd peut aussi lancer des processus qui s'appelle pas "httpd", au hasard, tout les processus wsgi lancé par mod_wsgi, et qu'ils vont totalement être oublié en cas de problème par le "killall httpd". IE, le nettoyage est incomplet.
Ensuite, dans l'action restart, le signal envoyé par le script est SIGTERM. Ce qui veut dire qu'un processus peut l'ignorer et/ou ne pas le traiter à temps, et donc que apache peut continuer de tourner, ce qui fait que le démarrage va échouer. Bien sur, jamais apache n'est surchargé et jamais il ne va mettre trop longtemps à mourir. Et jamais personne ne va injecter du code dans un processus apache via un interpréteur embarqué php. Car bon, tout le monde a retiré mod_php, qui tourne dans le même espace mémoire qu'apache par design, non ?
(et je parle pas d'attaque sr le code de php, je parle d'une personne qui va utiliser pcntl_signal en php dans une page pour dire à apache d'ignorer SIGTERM ou ce genre de trucs crades. J'ai pas testé, mais je serais pas étonné que ça marche).
Mais bon, j'imagine que "utiliser des containeurs" et "avoir des processus apache qui partent modérément en sucette" arrive pas si souvent, c'est juste la faute à pas de chance, et qu'on peut continuer à garder des scripts rempli de boilerplates et de bugs parce que c'est mieux (tm) ?
[^] # 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.
Je suis pas sur que les coupures de courant et l'usage de puppet/ansible/etc rentre dans les 0.1%. Surtout les coupures de courant. Parce que bon, si tu veux faire un script buggué pour toi en te disant "ça a pas besoin d'être robuste", pas de souci, mais tu comprends bien que les gens qui font des softs pour les autres (exemple, les distributions) veulent des solutions plus solide que ton script, et donc que pour eux, il faut soit avoir des scripts qui font des trucs que tu trouves inutiles, soit se prendre des bugs et la réputation de faire du taf de merde ( réputation à juste titre ).
De lancer le soft en premier plan, donc il peut connaitre le pid sans souci. Ou de faire comme d'hab, utiliser les cgroups. Le fichier de pid sert juste à signaler "je suis prêt" et à donner le nom du PID, mais sinon, je pense que l'option "GuessMainPID" doit marcher si tu insistes sur "passer en arrière plan".
[^] # 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é à 8.
En fait, en cherchant un peu, j'ai trouvé d'autres soucis.
4) ton script s'appuie sur le pid, donc si on perds le fichier, on perds une partie de l'etat. Pire encore, si on reboote la machine brutalement ( coupure de courant ), le fichier pid reste la, et bloque le démarrage de stunnel. Ou, si stunnel écrase le fichier existant, alors on peut imaginer l'inverse, on lance 2 fois le script ( cf point 6 ), et le 2eme fait qu'on perds le pid du premier, sauf si stunnel n'écrit pas le pid car le premier est lancé.
Et je parle pas d'avoir /var/lib en readonly ( livecd, etc ). Mais bon, c'est un détail, on peut supposer trivialement que ça se trouve dans /var/run, un truc poussé par systemd au passage.
C'est un tmpfs donc ça régle le souci.
5) il n'y a aucun nettoyage de l’environnement. Si ma locale est en français, alors stunnel sera en français, avec ce que ça implique ( message de log, format des dates, etc ). Parfois, ça change rien. Et parfois, ça change. Et comme c'est un script, tu peux toujours avoir quelqu'un qui le lance en dehors de service ou équivalent. Un souci que systemd n'a pas en forçant le passage par systemctl.
6) ton script ne renvoie pas de code de retour différents pour status. Donc un outil comme puppet va pas réussir à voir si le logiciel est lancé ou pas. Et les codes de retour sont spécifiés dans la LSB. Encore une fois, systemd unifie ça et évite de refaire le code à chaque fois.
7) Il se passe quoi si stunnel mets plus d'une seconde à s’arrêter, et que tu fais un restart ( genre ta machine est bien surchargé avec plein de load ). Réponse, il se relance pas, parce que le stop ne garanti pas que le process est coupé. C'est aussi un souci que systemd gère correctement ( en étant sur que les processus sont morts, dans le cgroup ).
Tout ça, ça se corrige dans ton script. Mais c'est surtout pour montrer que c'est pas aussi simple que ça de faire un truc robuste ( car bon, en dehors des commentaires de Linuxfr, les machines ont des coupures de courants, les machines ont du load, les gens utilisent puppet/ansible, les processus se plantent, les gens font des erreurs de config ).
[^] # 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é à 8.
je vois un certain nombre de souci avec ton script.
1) il se passe quoi si la config de stunnel fait que le pid est ailleurs ? Faut changer le script. mais du coup, comme le script est sous le controle du gestionnaire de paquet, y a un conflit si le packageur mets à jour le script.
2) tu part du principe que le PID dans $PIDFILE est celui de stunnel. C'est une supposition dangereuse à faire. Par exemple, stunnel crash ( un bon segfault des familles ), le pid est repris par un autre process. Tu fait un status, il va te dire que stunnel tourne, alors que non. Du coup, tu fait un stop. Et le process qui a repris le PID se fait tuer.
3) il se passe quoi si quelqu'un configure stunnel par erreur pour ne pas passer en background ? Le script bloque. En fonction du systéme d'init, ça peut bloquer le boot.
Alors bien sur, systemd va pas forcément résoudre le point 1. mais systemd va te dire "le fichier PID n'est pas la, j'ai un souci" si tu utilises PIDFile et que rien n'apparait. Systemd va pas avoir le souci du 2. Et pour le 3, c'est pareil, systemd va voir qu'il y a un souci, et comme il fforke avant de lancer, il va pas bloquer quoi que ce soit.
[^] # 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é à 3.
Ou rubyd, à un moment, faudrait évoluer.
[^] # 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é à 7.
Si c'est pas le cas, alors ta vision de la logique des developpeurs est fausse.
Si tu arrives à déterminer quand un service est effectivement démarré. C'est tout le noeud du problème. sysinit et d'autres s'en préoccuppent pas vraiment. Ça marche la plupart du temps, mais tu es obligé de faire ça en série, en partant du principe que ça démarre assez vite. parfois, tu rajoutes des sleep par ci par la, mais bon. On a vu le cas chez mandriva avec les cartes réseaux qui mettent 10 secondes à avoir leur ip, et les services notés "aprés le réseau" ne pas réussir à écouter comme il faut. Et puis parfois, tu as pas le souci, et tu sais pas ce qui est différent.
Upstart s'y prends différement. Il va suivre les process avec ptrace et voir le nombre de fork fait et à partir de la, dire "ok, il est lancé". C'est buggué, je vais pas revenir la dessus, j'ai collé les liens à chaque discussion sur systemd.
Donc la vrai solution, c'est que le service dise "je suis prêt".
D'ou la discussion sur le BTS Debian sur le sujet, avec l'idée d'utiliser sigstop (comme upstart ), refuser car posant divers souci. Systemd propose un protocole qui consiste à envoyer un message sur une socket donné par systemd lors du lancement, mais faut patcher le code des programmes, et ça se fait pas tout seul ( bien que de mon expérience, c'est pas le code le plus problématique, c'est les autotools ). Donc en attendant, il y a des heuristiques. On considére que le service est pret quand il a forké, quand il fait un fichier de pid, ou on utilise l'activation par socket, pour les cas ou "programme pret == programme qui écoute". Comme les sockets sont ouvertes avant de lancer toutes les unités, alors les dépendances ne sont plus importantes si la dépendance exprime juste "j'ai besoin de me connecter à tel service gére par la socket activation". Ça supporte dbus, les fifo, les messages netlink, etc, donc ç'est large. Ensuite, oui, si ton service depend d'un truc plus compliqué, alors la bonne façon, c'est de rajouter le protocole de notification, ou de faire comme avant, se dire que ça va marcher sans synchronisation.
Non, pas que je sache. Je pense pas que ça soit super complexe à rajouter, et je suppose qu'un truc comme snort pourrait s'en servir, mais j'ai quand même du mal à voir des cas d'utilisation. Ceci dit, je garde l'idée le jour ou je m'ennuie et j'ai envie de faire du C.
la réalité est plus compliqué que ça. Tu as plusieurs façons de planter, et c'est pas parce qu'un outil ne couvre pas tout les cas imaginables que couvrir 50% est inutile, loin de la. Déjà, tu peux faire de l'activation comme inetd avec 1 process par client. La, je pense que j'ai pas besoin de dire pourquoi ça marche quand le process se plante. Mais même avec 1 process pour tout les clients, il est relancé si jamais ça se gauffre, vu que c'est un retour l'état de début.
Quand à avoir un process qui ne marche pas mais qui tourne encore, il y a aussi un système de watchdog ou le process signal "je tourne encore" à intervalle régulier. Bien que ça ne règle pas le cas "je tourne mais je dit de la merd", ça donne un truc de plus entre le simple "le pid est la donc c'est bon" et le plus lourd "je lance une analyse compléte de la réaction du serveur" que ferait un nagios.
Il faut bien voir que plus un test est léger, plus on peut le lancer souvent. Exemple, voir qu'un process est planté pour systemd, c'est 3 fois rien. Mais plus il est leger, moins il couvre de choses. Dans le cas extrême d'un site, voir que 15 urls renvoient pas "error 500" en suivant un scénario web précis , c'est un chouia plus lourd, tu va pas le lancer tout les 10 secondes. Dans le cas d'un watchdog dans systemd, c'est un bete timer, et je pense que faire ça chaque 30 secondes ( ie, une écriture dans un socket ), c'est pas la mort.
Encore une fois, l'idée est pas de remplacer, mais de profiter de la poistion du gestionnaire d'init pour proposer des features en plus, à un autre endroit sur une échelle "precision/lourdeur" de test.
[^] # 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.