Cher journal,
Tu te dis que ça fait longtemps qu'on n'a plus entendu parlé des antisystemd (en fait, si mais ça casse mon intro si je le dis). Et bien, ils formanttaient un coup qui va mettre fin à l'adoption à coup sûr, ils proposent de boycotter systemd et de ne plus utiliser que Slackware, seule distribution résistant encore à l'envahisseur1. Dans les arguments, on retrouve certains points plus valides (une mise à jour de systemd demande un reboot, et ça arrive plus souvent qu'une mise à jour de l'init traditionnel2, systemd embarque une bibliothèque de QR code) que d'autres (la conf par défaut n'est pas terrible pour certains cas spécifiques, pour éviter de prendre le plus petit dénominateur commun, il faut utiliser les fonctions qui sont le plus petit dénominateur commun…).
Et pour ceux qui aiment systemd, une petite nimage.
PS : Je sais qu'il est encore un peu tôt mais moi le vendredi, je bosse.
-
on remarquera qu'il doit y avoir un recoupement entre les anti systemd et la FSF vu que dès qu'on propose systemd, on est une mauvaise distribution, Debian et Gentoo sont donc exclues des alternatives. ↩
-
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. ↩
# USE="-systemd"
Posté par Parleur . Évalué à 10.
Justement, avec l'avancement de systemd dans Debian, je suis en train de repasser à Gentoo, avec USE="-systemd" dans les variables globales.
J'suis pas vraiment compétent comme admin sys, mais j'avoue que quand vient le temps de faire joujou avec ma machine, je comprends bien mieux comment fonctionne OpenRC que systemd.
Je n'ai pas les moyens de juger ce qui est « mieux » ou pas, techniquement parlant, mais j'avoue que je prends plus de plaisir quqad je comprends plus facilement ce qui se passe sous le capot, et c'est important aussi. Je crois. Pour moi, en tout cas.
[^] # Re: USE="-systemd"
Posté par Okki (site web personnel, Mastodon) . Évalué à 9.
C'est aussi, et je pense qu'on est nombreux dans ce cas, qu'on fait face à de nouveaux outils, une nouvelle façon de faire, qu'il faut tout réapprendre, et qu'en attendant, on se sent comme un débutant. Et le fait de se dire "merde, j'ai appris tout ça pour rien, faut tout refaire", ça n'aide pas non plus.
[^] # Re: USE="-systemd"
Posté par Pi3R1k . Évalué à 10.
En tant qu'admin sys je peux vous assurer que systemd me change déjà la vie et j'attend avec impatience que toutes les distributions y passent.
Imaginez un monde ou le script d'init change en fonction de la distribution. Où par conséquences il faut tout réapprendre en changeant de distribution, voir simplement en changeant de version. C'est le monde proposé par les script d'init "classiques".
Mettez le nez 2 secondes dans un script d'init sysVinit et comparez le avec un fichier d'init systemd. Vous me direz lequel est le plus lisible, maintenable.
Un petit exemple avec des scripts d'init d'apache2 :
systemd : http://pastebin.com/zCLVFr0r
sysVinit sous debian : http://pastebin.com/4etchSUX
upstart sous centos 6 : http://pastebin.com/p7FzsJm1
[^] # Re: USE="-systemd"
Posté par Altor . Évalué à 3.
Et sous slack :
C'est pas beaucoup plus long/compliqué que sous systemD.
[^] # Re: USE="-systemd"
Posté par claudex . Évalué à 5.
Non, mais c'est beaucoup plus boggué, comme expliqué plus bas par Misc.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: USE="-systemd"
Posté par Misc (site web personnel) . É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: USE="-systemd"
Posté par Altor . Évalué à -5.
Le but ici était de montrer que l'on peut faire des scripts bash aussi court que systemD.
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 ?
Docker ne faisant pas parti de slackware (ni de debian) donc ça ne me choque pas plus que ça.
Après oui, les cgroups c'est bien.
[^] # Re: USE="-systemd"
Posté par claudex . Évalué à 6.
systemd fait très bien le restart/stop, pour le restart, il fait un stop + start, pour le stop, c'est écrit dans la définition du service. Si le stop échoue et que tu veux tuer les process du service, il y a la commande
systemctl killqui tue les process du cgroup.Docker, ce n'est qu'une utilisation des conteneurs, tu peux très bien aussi les utiliser à la main. Et si tu le fait sous slackware, tu dois écrire ton script d'init à la main et il deviendra complexe.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: USE="-systemd"
Posté par claudex . Évalué à 5.
Et par exemple, le script d'init sysv de Debian stable ne tue pas des process dont il n'est pas sûr qu'ils n'ont pas été démarré par le script d'init. Tu te retrouve avec des process qui reste mais c'est mieux que se retrouver avec un service tué alors qu'il n'avait rien demandé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: USE="-systemd"
Posté par Misc (site web personnel) . É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: USE="-systemd"
Posté par Moonz . Évalué à 5.
Et sous systemd tu fais comment pour implémenter la différence entre
stopetgraceful-stop?[^] # Re: USE="-systemd"
Posté par Chris K. . Évalué à 10. Dernière modification le 24 avril 2014 à 23:37.
C'est comme avec dacode => templeet => rails. Ça gueule au début et mais une fois que ça sera bien intégré au final plus personne ne voudra revenir en arrière ^_^
[^] # Re: USE="-systemd"
Posté par jean-michel.bertrou.eu . Évalué à 9.
Le mieux techniquement parlant ce n'est pas le système parfait qui aurait épuisé les récriminations des anti-systemd
Confère Méthode hypercritique.
Le mieux techniquement, c'est qu'il y ait un système unifié à peu près bien qui soit prépondérant, les autres innovant sagement dans leur coin jusqu'à ce qu'ils apportent comme systemd l'a apporté (cf le nombre de distros convaincues) la preuve qu'ils apportent un mieux substentiel pour justifier l'inconvénient d'avoir à migrer.
C'est nettement préférable à 42 système tous aussi excellents les uns que les autres (à l'instar de http://distrowatch.com/dwres.php?resource=major ), chose qui tourne nécessairement au désastre.
# Bientôt dans le kernel
Posté par Patrick Nicolas . Évalué à 10.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Hum hum
Posté par ianux (site web personnel, Mastodon) . Évalué à 10.
Ça t'a pas choqué plus que ça que les dictionnaires de DLFP et/ou Firefox (Chromium ?) fassent seppuku au milieu de ton salon ?
[^] # Re: Hum hum
Posté par El Titi . Évalué à 10. Dernière modification le 24 avril 2014 à 21:21.
Seuls les vrais menteurs fomentent. Les faux fermentent dans le fort mol en promettant fortmellement des méres vieilles.
[^] # Re: Hum hum
Posté par zebra3 . Évalué à 8.
Mais rassurez-vous, votre maire veille !
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Hum hum
Posté par El Titi . Évalué à 5.
Une erreur passée à la trappe de mon correcteur est passée.
Tous mes plussoiements d une semaine à celui qui la trouve.
[^] # Re: Hum hum
Posté par Yves Bourguignon . Évalué à 5.
Ta mère te pardonnera-t-elle cette faute amère ?
[^] # Re: Hum hum
Posté par El Titi . Évalué à 6.
Fermement, je l'affirme haut et fort et je déments en mon for intérieur:
Cépafo
[^] # Re: Hum hum
Posté par El Titi . Évalué à 5.
C'est dément !
DLFP, ce diamant, n'amende pas la grammaire.
Ô drame amer !
[^] # Re: Hum hum
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Je n'ai pas compris pourquoi ils formatent, alors que la mise à jour de systemd demande un reboot. Sûrement parce que les formes hantent ou en T.
[^] # Re: Hum hum
Posté par claudex . Évalué à 4.
En fait, entre les systemd, Debian, Gentoo en rouge, ça en faisait tellement que ça ne m'a pas choqué /o\. Après, j'aurais pu me relire aussi, mais il ne faut pas trop pousser.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Hum hum
Posté par Croconux . Évalué à 4.
Si même les faux mentent, alors on ne peut plus se fier à personne.
# "on retrouve certains points plus valides"
Posté par oinkoink_daotter . Évalué à 10.
Une phrase honnête aurait été : journald a une fonctionnalité de passerelle HTTP/JSON proposant de générer des QR Codes. Cette fonctionnalité existe depuis au moins octobre 2012
(as per https://lists.fedoraproject.org/pipermail/devel/2012-October/172163.html)
[^] # Re: "on retrouve certains points plus valides"
Posté par Misc (site web personnel) . Évalué à 5.
Et pour être précis, c'est optionnel.
http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n664
# L'avis d'un mainteneur.
Posté par karchnu . Évalué à 8.
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. Après tout, de ce que j'ai pu comprendre un gros avantage serait une configuration simplifiée (et donc plus lisible), ainsi qu'un boot parallélisé (ce qui semble logique aux vues des avancées en matière de hardware) et une certaine gestion de chaque démon qui se lance.
Si on se fixe cet objectif, on peut comprendre facilement les différents choix qui ont été fait dans systemd ; et on peut comprendre que cela attire les mainteneurs. Peut-être cependant qu'il y en a (et il y en a) qui sont contre l'adoption de systemd et ce serait intéressant d'avoir leur avis sur la question.
Ce qui me pose le plus de problème (toujours vu de loin), c'est la gestion du journal avec ses fichiers binaires… mais l'alternative est proposée, on peut faire tourner du syslog, donc où est le problème concrètement ? Autre soucis, ce serait de devoir redémarrer la machine à chaque changement de systemd, mais le cœur de l'application devra-t-il réellement changer régulièrement ou ce sont plutôt ses composants annexes (et donc qui ne nécessitent pas de redémarrage) qui seront plus enclin à être mis à jour ?
Il semble normal de se dire cependant que systemd est un peu chargé. Toujours aux vues des ambitions, cela semble pourtant assez normal. On reproche aussi à systemd de ne plus respecter la devise une application = une tâche, je n'ai pas assez creusé pour savoir en quoi.
Dernière chose, je vois qu'on reproche de ne pas pouvoir redémarrer la machine s'il y a un soucis, mais sur un serveur il y a des outils pour redémarrer matériellement. D'accord, c'est un peu pénible de devoir faire ça, mais d'un autre côté c'est pas comme si on prévoyait de planter tous les jours le système.
[^] # Re: L'avis d'un mainteneur.
Posté par claudex . Évalué à 9.
Si tu prend l'exemple de Debian, les discussions de l'équipe technique ont été mouvementées (cf. le journal sur le sujet).
Le cœur de systemd fait plus de chose que le cœur d'un init traditionnel, donc statistiquement, il y aura plus de faille de sécurité qu'il faudra corriger.
C'est possible, mais c'est toujours sur cette machine qu'on a oublié de le configurer, qu'on l'a mal configuré, que ce n'est pas disponible… (loi de Murphy oblige). Il vaut mieux diminuer la probabilité qu'un problème survienne plutôt que d'avoir des solutions post-mortem.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: L'avis d'un mainteneur.
Posté par Maclag . Évalué à 10.
De ce que j'en comprends, systemd n'apporte finalement pas grand chose de plus, il remplace beaucoup en consolidant du code et permettant une meilleure intégration de l'ensemble.
Du coup, pour comparer le risque qu'une faille soit trouvée, il faut comparer systemd contre init+panoplie d'outils remplacés par systemd.
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?
Pour départager ces risques, j'ajouterais que systemd est très activement maintenu et plutôt sous les yeux des projecteurs. Nos vieux outils l'étaient sûrement beaucoup moins. Serait-on prêt à les garantir sans faille au vu de leur ancienneté?
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . É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: L'avis d'un mainteneur.
Posté par pikapika . Évalué à 4.
La différence d'openssh, c'est qu'il ne correspond qu'à un seul outil, alors que systemd va en remplacer une foultitude.
Si jamais, pour une raison ou une autre, il faut sortir d'openssh, il y a potentiellement des alternatives rapides à mettre en place.
Alors que si jamais il faut passer de systemd à autre chose, c'est tout un "écosystème" qu'il faut refaire, et ça sera loin d'être trivial.
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . É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: L'avis d'un mainteneur.
Posté par cedric . Évalué à 8.
Mouah ah ah ah ! Proxy, forward de port, transfert de fichiers, shell distant, … C'est un couteau suisse ton outil ! Reecrire un client/serveur SSH, c'est du gros boulot tout de meme ! La difference, c'est que tu as l'habitude de OpenSSH, alors que systemd est nouveau pour toi.
[^] # Re: L'avis d'un mainteneur.
Posté par Batchyx . Évalué à 2.
SSH est un protocole assez simple si tu le regarde. Le serveur doit certes supporter plusieurs canals de différent types, comme des flux, des pty, des forward dynamique de ports et du transfert de fichier, mais au final, le couteau suisse, c'est le client OpenSSH. Par exemple le proxy SOCKS est entièrement fait coté client.
De toute façon, il y a déjà plusieurs implémentations d'SSH alternatives: dropbear et celle de twisted, donc la question se pose pas.
[^] # Re: L'avis d'un mainteneur.
Posté par zebra3 . Évalué à 2.
Comme OpenSSL. Oh wait…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: L'avis d'un mainteneur.
Posté par claudex . Évalué à 5.
Franchement, tu dirais que OpenSSL est activement maintenu ? Et sous les yeux des projecteurs (avant l'annonce de la faille) ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: L'avis d'un mainteneur.
Posté par zebra3 . Évalué à 3.
Ben il semblerait, puisque dans le journal sur LibreSSL on me dit que le code est régulièrement audité.
Et sur la page d'OpenSSL il est écrit « The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit ». Naïvement, je suppose qu'un outil de sécurité qui cherche à être « robust », « commercial-grade » et « full-featured » il faut un minimum de suivi.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: L'avis d'un mainteneur.
Posté par karchnu . Évalué à 3.
Ou alors tu te dis comme n'importe-quel admin/sys que ces mots sont purement commerciaux et que donc tu as (peut-être) de quoi t'inquiéter.
[^] # Re: L'avis d'un mainteneur.
Posté par claudex . Évalué à 5.
Ce n'est pas ce que j'appelle "être sous les projecteurs"
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: L'avis d'un mainteneur.
Posté par ZeroHeure . Évalué à 3.
Relis, personne ne t'a répondu ça.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: L'avis d'un mainteneur.
Posté par zebra3 . Évalué à 3.
Alors je ne sais pas lire :
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: L'avis d'un mainteneur.
Posté par Anonyme . Évalué à 3.
Parler d'audit de code comme d'un truc binaire c'est completement stupide. Des projets qui acceptent des patchs sans les lire (donc sans les auditer un minimum), j'en connais pas. Je pense qu'on peut dire que environ 100% des projets sont audités. Ca veut pas dire qu'ils le sont tous de la meme facon.
Et puis la complexité de OpenSSL a pas grand chose à voir avec celle de systemd.
[^] # Re: L'avis d'un mainteneur.
Posté par zebra3 . Évalué à 10.
À ce compte-là on peut jeter beaucoup de choses. Konqueror permet d'aller sur le web et de naviguer dans les fichiers, est-il pour cela un mauvais logiciel ? Emacs peut tout faire (sauf peut-être éditer des fichiers), faut-il le jeter pour ça ?
On va me dire que Konqueror n'est qu'une GUI autour des Kio ou Emacs se sert de plugins, mais :
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: L'avis d'un mainteneur.
Posté par claudex . Évalué à 10.
Et ça en devient une autre critique : il y a trop de binaires (c'est un peu la magie des anti).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . É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: L'avis d'un mainteneur.
Posté par oinkoink_daotter . Évalué à 5.
Et les interfaces réseau. Elles ne sont pas fichier les interfaces réseau.
[^] # Re: L'avis d'un mainteneur.
Posté par oinkoink_daotter . Évalué à 6.
Ici, visiblement, pas grand chose à part un hello world. /o\
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . É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.
# Lennux Is Not UniX
Posté par Arthur Accroc . Évalué à 10.
J’ai la joie d’administrer des postes en réseau avec des Fedora (donc systemd) en poste client (j’ai des utilisateurs qui veulent des versions récentes d’un certain nombre de trucs) et des services Unix classiques : NFS, autofs…
Bon, j’ai dû laisser tomber pour la Fedora 17, la version de systemd qui était dessus plantait complètement autofs. Et là, je n’en étais pas à résoudre le problème moi-même comme à l’époque des scripts bash, alors que les développeurs de Fedora eux-mêmes n’ont pas réussi avant la sortie de la 18 (en rétroportant une correction ; mêmes eux n’ont pas les compétences pour le corriger eux-mêmes).
La Fedora 19 marchait correctement au début (peut-être après ajout d’une dépendance sur un des services systemd, mais ça restait raisonnable).
J’ai fait une mise à jour (à la suite de la faille sur OpenSSL) et là, c’est le drame, l’arrêt qui se remet à merder complètement s’il est lancé directement depuis une session utilisateur : blocages de l’ordre du quart d’heure ou plus, dus en particulier aux partages NFS qui sont démontés après l’arrêt du réseau et systemd qui les attend… longtemps.
Alors, j’ai configuré logind pour qu’il tue les processus de l’utilisateur à la fermeture de session (sinon, il traînait des processus qui bloquaient le montage, en particulier un de Gnome et un de… systemd).
J’ai ajouté un pseudo-service intermédiaire démontant (lors de l’arrêt) les partitions NFS et définissant surtout des dépendances avec autofs d’un côté et le réseau de l’autre pour s’assurer de l’ordre.
J’ai aussi ajouté une temporisation de quelques secondes à l’arrêt du service autofs.
Alors, ça marche moyennement (entre 30 s à 1 minute pour l’arrêt, pas mieux que le démarrage), mais ça remerde bien plus si je retire n’importe laquelle de mes modifs.
À voir les traces, systemd essaye de faire un arrêt très rapide… en lançant les arrêts des services dans l’ordre des dépendances, mais pour certains (notamment autofs et les démontages NFS) en parallèle, sans attendre que l’arrêt du service soit fini pour commencer l’arrêt de celui dont il dépend. C’est quand même génial !
Sur un système client typique avec répertoires sur NFS, c’est la catastrophe.
Même Slackware avec son arrêt sauvage type BSD à l’ancienne s’en sortirait mieux.
Pour l’arrêt, il envoie un Ctrl-C aux processus, puis les tue salement après quelques secondes s’ils ne se sont pas terminés, mais avant tout cela… il démonte les partitions NFS !
Le seul argument que j’aie à la décharge de systemd, c’est qu’après avoir configuré une Ubuntu 12.04 de la même manière, je sais qu’Upstart en est à un stade encore pire : il lance autofs avant le réseau, donc même le démarrage rate (l’intérêt d’autofs, c’est d’aller chercher la table de montage sur le serveur avec LDAP ou NIS). Pour que ça marche, il faut rajouter les dépendances soi-même, sauf que c’est moins pratique à configurer qu’avec systemd et mal documenté…
Alors évidemment, systemd, ça marche sur un ordinateur portable, donc autonome. Des systèmes grand public (dans le mauvais sens du terme) comme Ubuntu et Windows aussi.
Et pour démarrer aussi vite que systemd sur un portable, pas besoin de quelque chose d’aussi compliqué. Sur une Arch avant systemd, je lançais dbus et un autre service puis quasiment tous les autres en parallèle sans aucun problème et le démarrage était aussi rapide.
Partant d’un a priori positif sur systemd du point de vue de la conception avant que Fedora ne l’utilise vraiment, mon avis devient de plus en plus négatif (ça se voit au fil des posts).
Mais le temps que je perds dessus se cumule et son fonctionnement ne s’améliore pas réellement (par rapport à la Fedora 17, si, mais la version qui était dessus était bien pire que les précédentes).
En tant qu’administrateur système, Systemd est la plus grosse plaie que j’aie eu récemment.
Et que fait un système avec systemd qui me manquerait sans ? Rien !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Lennux Is Not UniX
Posté par claudex . Évalué à 10.
C'est un sale point pour systemd. Mais c'est quand même une drôle d'idée d'utiliser Fedora si on ne veut pas beaucoup bidouiller.
Si je comprends bien la doc, il faut mettre NFS dans After et dans Require pour qu'il attende complètement qu'il soit démarré/arrêté.
Si j'ai bien compris ta situation, sans systemd, tu te traînerais des processus qui ne se terminent pas à la fermeture de la session.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Lennux Is Not UniX
Posté par Arthur Accroc . Évalué à 4.
Quelle distribution suggères-tu ?
J’ai des utilisateurs qui veulent des versions récentes d’un tas de trucs, ça élimine CentOS et Debian stable.
Par rapport à des distributions plus confidentielles, Fedora et Ubuntu ont l’avantage que beaucoup de choses sont déjà empaquetées pour elles. Ça fait gagner pas mal de temps.
D’autres utilisateurs (ou quelquefois les mêmes) veulent continuer à utiliser des logiciels commerciaux dont on n’a que de vieilles versions (faute d’avoir payé la maintenance), du coup le fait que Fedora fournisse un certain nombre de bibliothèques de compatibilité (contrairement à Ubuntu) est un avantage.
Jusqu’à la version 14, Fedora était bien adaptée à un fonctionnement en machine cliente, contrairement à Ubuntu (depuis qu’elle n’a plus le même système d’init que Debian).
Avant systemd, contourner les éventuels bugs de la Fedora était moins lourd que de transformer Ubuntu en système client fonctionnel.
Alors maintenant, je changerais bien, mais comme toutes les distributions qui disposent d’un large choix de paquets sont déjà dans le Borg ou sur la voie de l’assimilation…
Ça, c’est la théorie. Dans la pratique, j’ai pour l’arrêt des traces comme quoi le démontage des partitions NFS est bien lancé avant l’arrêt du réseau, sauf qu’il n’est pas fini quand l’arrêt du réseau est lancé.
L’un fait partie de systemd. L’autre de Gnome, mais si on lui laissait un poil de temps avant de tout remballer, il se terminerait probablement normalement. D’ailleurs si je ferme la session sans lancer l’arrêt, il disparaît.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Lennux Is Not UniX
Posté par claudex . Évalué à 5.
Même avec les backports ?
Ça vaut peut-être un rapport de bug ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Lennux Is Not UniX
Posté par oinkoink_daotter . Évalué à 3.
C'était quoi le problème, à part "c'est pas comme ailleurs" (unity et upstart) ? Parce que bon, le desktop, c'est un peu le cœur de marché d'Ubuntu, donc ce que tu dis mérite un peu d'explications …
[^] # Il y a desktop et desktop.
Posté par Arthur Accroc . Évalué à 2.
J’ai un plutôt l’impression qu’actuellement, Ubuntu et Fedora visent surtout les portables. Je ne dis pas que c’est aberrant, après tout, ça se vend plus que les machines de bureau.
Par ailleurs, il y a desktop et desktop. La configuration n’est pas la même sur une machine du boulot avec tout centralisé sur le serveur que sur une machine perso autonome.
Imagine une Fedora d’avant la 18 (neuneuïsation de l’installeur).
L’installeur te donnait la possibilité de configurer directement la base d’utilisateurs sur LDAP ou NIS (avec éventuellement authentification sur Kerberos) avec pour LDAP récupération du certificat et d’un point de vue général tout bien configuré : pam, nsswitch.conf, ldap.conf ou yp.conf… et autofs qui marche directement.
Des trucs que j’avais passé pas mal de temps à configurer correctement lors du passage à LDAP en 2002 (il faut dire qu’à l’époque, les distributions ne prévoyaient pas encore trop ça, et les docs n’indiquaient pas les bons attributs LDAP, il avait fallu que je trace les accès au serveur pour savoir quoi y mettre), que même mon collègue incompétent (actuellement en reconversion professionnelle après un éclair de lucidité) pouvait ainsi configurer correctement en peu de temps.
Avec Ubuntu, il n’y a pas ça (avec les versions récentes de Fedora non plus…). Je ne peux pas être sûr que je n’aie pas raté un outil génial pour le faire après l’installation, mais autofs n’est même pas prévu pour démarrer après le réseau. Je t’invites à vérifier toi-même /etc/init/autofs.conf.
Compare par exemple avec /etc/init/ypbind.conf (paquet nis), qui lui est bien prévu pour démarrer après le réseau (enfin ce n’est pas clair que ça marche si le réseau est configuré avec NetworkManager ou en DHCP, cela dit).
Tu pourras au passage constater que démarrer un service après le réseau est moins trivial qu’avec une init System V ou systemd…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Il y a desktop et desktop.
Posté par Misc (site web personnel) . É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
[^] # Fedora
Posté par Arthur Accroc . Évalué à 2.
Je n’aime pas trop miser sur des outils spécifiques : je peux être amené à changer de distribution et par ailleurs, on n’est jamais sûr qu’ils ne disparaissent pas brusquement.
Je me suis dit « Hein ??? QUELLE seconde partie ??? ». Je sais bien qu’il y en avait une, mais quand j’ai testé une Fedora 20, je n’en ai pas eu.
J’ai refait le test (sur une machine virtuelle) ; pas mieux.
J’ai vérifié les dépôts, il n’y a plus de paquet firstboot sur la Fedora 20 (il existait encore sur la 19).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Fedora
Posté par claudex . Évalué à 3.
Quelle différence par rapport à utiliser l'installateur ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fedora
Posté par Arthur Accroc . Évalué à 2.
Il ne demande pas d’investir du temps pour le maîtriser.
Je ne l’utilise même pas une fois par version de la distribution : je mets à jour mon système type.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Fedora
Posté par Misc (site web personnel) . Évalué à 2.
alors utilise l'outil spécifique pour lancer un truc comme ansible
au contraire d'un outil non spécifique ? les choses partent pas "brutalement", c'est plus les gens qui découvrent brutalement qu'il fallait suivre les changements. Je dit pas que c'est simple ceci dit, vu comme le monde du libre bouge. Mais par exemple, puppet, non spécifique, a des soucis de versions en fonction du client puppet, qui lui même depend de la version de ruby et des gems. De même, ils ont retiré les manifests en ruby dans la version 3.0, et y a des gens qui s'en servaient.
En effet, j'ai pas installé de Fedora 20, j'ai juste fait un yum search firstboot et j'ai pas vu qu'il était installé, pas dispo. Et donc en effet : https://admin.fedoraproject.org/pkgdb/acls/name/firstboot
Cela a été remplacé par gnome-initial-setup ( https://fedoraproject.org/wiki/Features/NewFirstboot ), qui en effet ne propose pas un réglage aussi fin que tu voudrais de ldap, ceci étant reservé à la commande authconfig
Il est présent dans EL7 ceci dit.
[^] # Re: Lennux Is Not UniX
Posté par Misc (site web personnel) . É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: Lennux Is Not UniX
Posté par Arthur Accroc . Évalué à 7.
Du coup, ça ne marche pas trop…
Oui, mais lié à systemd.
Avec systemd, autofs se retrouve dans un CGroup spécifique alors qu’il est sensé monter des répertoires pour des utilisateurs qui sont dans un autre ; c’est ça qui fait foirer. 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).
Si ton colloc passe à une version de systemd (donc à la verstion de Mageia qui la contient, vu que changer de version de systemd n’est pas forcément trivial) égale ou supérieure à 195, le problème devrait disparaître (… sauf s’il a un autre problème).
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).
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).
À court ou moyen terme, on devrait avoir un stockage centralisé (suffisant) pour tous nos utilisateurs, donc je devrais pouvoir me passer de la table d’automontage et utiliser pam_mount. Pas sûr que le démontage et donc l’arrêt du système fonctionneront mieux pour autant…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Lennux Is Not UniX
Posté par Misc (site web personnel) . É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: Lennux Is Not UniX
Posté par claudex . Évalué à 5.
http://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.service.html ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Lennux Is Not UniX
Posté par Misc (site web personnel) . É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.
# But du site ?
Posté par xouillet . Évalué à 10.
J'avoue ne pas saisir la substantifique moelle de ce site.
Je veux dire, débiter des arguments plus ou moins pertinents sur systemd, soit, si ça les amuse, mais leur conclusion c'est quoi ? Boycotter, changer de distro, passer à Plan9…puissant.
Ça n'aurait pas été mieux au contraire de faire passer un message pour aider les développeurs Debian par exemple pour faire des paquets non "infectés" par systemd pour Jessie, afin de garder la liberté du choix qui a plus ou moins été décidé. Ou encore encourager les personnes convaincus par la liste de faire des patchs dans GNOME ou autres pour éviter de dépendre trop de systemd.
Bref, déjà les arguments m'ont pas convaincu (mais bon j'aime bien systemd :p), mais alors leur conclusion…déplorable
[^] # Re: But du site ?
Posté par Misc (site web personnel) . É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.
# Systemd et crash
Posté par Misc (site web personnel) . É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: Systemd et crash
Posté par claudex . Évalué à 4.
Oui, mais ça reste avec la même version, ce n'est pas tout à fait la même chose que recharger une nouvelle version.
Oui, en théorie ça marche, mais la probabilité est plus grande qu'un truc se passe mal.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Systemd et crash
Posté par Misc (site web personnel) . É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.
# slack
Posté par theblatte . Évalué à 4.
Alors déjà je m'insurge parce que Slackware saibien.
Ensuite je ne suis pas sûr de comprendre le sens de cette note de bas de page, mais au cas où elle insinue que la FSF serait de mèche avec Slackware : Slackware du point de vue de la FSF, sapusaipalibre ! Pat a toujours inclus des trucs pas libres sans vergogne (tels que… firefox sous son vrai nom ! Bon avant il y avait des exemples plus frappants comme flash).
[^] # Re: slack
Posté par Renault (site web personnel) . Évalué à 10.
La remarque se voulait, je pense, ironique en mentionnant que les anti-systemd sont aussi rigides dans leurs recommandations de distributions sans systemd que la FSF pour les distributions libres.
# Tout s'éclaire
Posté par antistress (site web personnel) . Évalué à 6. Dernière modification le 25 avril 2014 à 01:41.
D'autant que PC-BSD lance un nouvel environnement graphique, Lumina, sans doute à cause de l'imbrication prévisible de systemd avec GNOME..? et prochainement de KDE etc. Je dis ça, hein…
[^] # Re: Tout s'éclaire
Posté par Maclag . Évalué à 10.
Tant il est vrai qu'on avait un gros besoin d'alternative à Gnome et KDE. C'est pas comme si on avait déjà des Xfce, Razor-Qt/LXDE, des Mate, des Cinnamon ou encore des E17.
Nan, je plaisante, ici les objectifs sont clairement différents de toutes ces alternatives: un bureau complet mais léger et rapide! Pas comme les autres au-dessus, qui cherchent à développer des bureaux pas fonctionnels, lourds et lents.
Enfin, j'ai peut-être raté un truc très très très important qui fait toute la différence et qu'on ne pouvait absolument pas ajouter aux autres.
[^] # Re: Tout s'éclaire
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 25 avril 2014 à 15:44.
J'ai cru comprendre que celui-là était pour BSD parce que tous les autres, conçus pour Linux à la base, auraient tendance à déconner sous BSD.
(et t'as oublié Unity et Pantheon et Hawaii et le truc de Chrome OS)
[^] # Re: Tout s'éclaire
Posté par Le Gab . Évalué à -3.
Ah bon? c'est vraiment la volonté affichée ou juste une conséquence de leurs choix et compétences?
Parce que vas-y pour féderer des devs bénévoles avec:
"Bon les gars, je lance un projet de serveur graphique lourd et monolitique écrit en Java avec fichierS de config en XML"
[^] # Re: Tout s'éclaire
Posté par Misc (site web personnel) . É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: Tout s'éclaire
Posté par Seazor . Évalué à 2.
Pour gnome, peut-être… J'en sais rien.
Pour KDE, j'ai un gros doute.
Avec leur habitude de faire des couches d'abstraction pour tout ce qui vient de l'extérieur (phonon, solid et autres), il y aura surement un backend systemd pour pas mal de choses dans KDE5.
Mais ca m'étonnerait que d'autres backends ne soient pas faisable pour les mêmes fonctionnalités pour les autres OS/configs…
[^] # Re: Tout s'éclaire
Posté par antistress (site web personnel) . Évalué à 2.
Ce type en parle http://www.phoronix.com/forums/showthread.php?99351-PC-BSD-Is-Developing-Its-Own-Desktop-Environment&p=413398#post413398 mais sans sourcer son propos
# If it works, don't fix it.
Posté par octane . Évalué à 7.
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.
L'init, c'est simple, ça marche, ça a un fichier de conf (inittab) et pleins de petits rc. Sous slackware, la lecture (et la compréhension) de l'init complet du système prend moins d'une heure et c'est très bien. (bon, sous redhat/debian c'est quelque fois un peu spaghetti, mais on s'en sort).
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.. et tu peux gruiker/coder/modifier tout ce que tu veux, comme par exemple détecter via bluetooth ton smartphone pour t'autologger lorsque tu est devant la machine :)
On se fait plaisir, on utilise des outils classiques comme vi/grep/sed/awk pour administrer la machine et c'est joyeux.
Puis viens systemd qui dit que l'init c'est tout pourri, genre: il est impossible de lire les lignes 110 à 138 du fichier de log facilement, et il n'y a pas de parrallélisation etc, etc, etc.. On va donc tout changer, mettre 80 binaires qui font tout et ça sera mieux. Vous n'êtes pas d'accord? Vous n'êtes que des rétrogrades rétifs au changement qui ne méritez que de mourir et de toute façon pour ces résidus du passé j'ai mis des passerelles vers les vieux systèmes obsolètes. Bon. Ok. Pourquoi pas. Lorsqu'un linuxien saute sur un windowsien en lui disant que son système c'est de la merde et que linux saytrogénial vazy change, le windowsien a toujours un mouvement de recul. Je crois que c'est la même chose avec systemd.
D'un système qui se hackait au script shell, on passe à un système tout intégré beaucoup plus statique. Je lisais l'histoire d'un gars qui voulait modifier la manière dont on entrait le mot de passe de la partition chiffrée au démarrage. Solution: patche le bon morceau de systemd et fait accepter ton patch. Avant, il suffisait de trois lignes en shell. Aujourd'hui, bah tu laisses tomber (pas le temps de le faire, de tout recompiler basta).
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? Sauf qu'aujourd'hui, le passage à systemd se fait à marche forcée et l'obligation commence à m'ennuyer. Je crois que je vais créer un commpte sur http://bsdfr.org :)
[^] # Re: If it works, don't fix it.
Posté par Reihar . Évalué à -2.
Juste comme ça, si on ne réparait pas les trucs qui marchaient on aurait pas d'innovation.
Ah et, tu es sûr que tu veux un compte sur http://chambrenoire.fousdereflex.com:5080 ?
[^] # Re: If it works, don't fix it.
Posté par octane . Évalué à 10.
Et voilà. On ose critiquer systemd et on se fait traiter de rétrograde :)
[^] # Re: If it works, don't fix it.
Posté par Reihar . Évalué à 8.
Ah mais ma remarque n'était pas du tout liée à systemd. Je disais juste que "If it works, don't fix it" est un principe de merde qui sert juste à ralentir l'humanité.
[^] # Re: If it works, don't fix it.
Posté par apkwa . Évalué à 1.
Je suis tout à fait d'accord avec tout ce que tu dis (et oui, je suis rétrograde/archaïque).
Personnellement, je n'ai jamais regardé à quoi ressemblait l'init dans le détail. Je fais juste des init scripts de temps en temps, et j'aime bien parce que c'est super simple. Ceci dit, je ne suis pas sûr que de ce côté systemd soit plus compliqué.
Par contre, je suis d'accord sur le côté "forcé" du truc, surtout sur qqchose d'aussi important et qui évolue encore si rapidement. On pourrait peut-être lui laisser le temps de se tasser avant de l'imposer à quasiment tous les Linuxiens et surtout leurs serveurs: Gagner 3 secondes pour démarrer ne devrait pas être plus important que de perdre 3h à parser un dmesg…
Et puis bon, init c'est init quoi… c'est quand même une des fondations des *nix, le PID 1, tout ca…
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 7.
Du coup, c'est un rapport de bug à ta distrib qu'il faut faire.$
Le but de systemd n'a pas été un démarrage rapide, mais son architecture conçue pour gérer les dépendance de service fait que ça accélère le démarrage.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
Bon faut arrêter ces conneries, le but originel de systemd c'est, en premier lieu, un démarrage rapide. Le message d'annonce de systemd commence comme suit (emphase de moi) :
D'ailleurs si on enlève le côté rapide de systemd, il ne reste plus rien de bénéfique. D'ailleurs ça faisait des années que je n'avais plus eu un ordinateur qui se vautrait au démarrage, systemd m'a ramené à cette bonne vieille période parce que mon fstab contenait une entrée plus valide mais sans grande importance.
Et maintenant quant à chaque fois que je lance "top" je vois systemd dans le top 3 sur un core i7, je me dis qu'on va se la prendre sévère dans la gueule.
Enfin, centralisation et monoculture, c'est la base d'un fiasco et c'est les fondamentaux de systemd …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Renault (site web personnel) . Évalué à 6.
Mince une gestion propre et simple des dépendances entre services c'est rien en effet. Une factorisation de code entre distributions et entre services c'est inutile aussi.
Ouais enfin parfois dans me top 3 de top j'ai des processus qui utilisent 0.1% de processeur tu vois… Ça n'a pas grand sens.
[^] # Re: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 8.
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 … Ce truc existe juste pour la vitesse (on lance tout d'un coups et on gérera ensuite), une gestion propre des dépendances c'est : "si un service à besoin du réseau, il démarre quand le réseau est disponible". Comme pour le système autofs, si un service à besoin du système de fichier, il doit partir après que le système de fichier soit monté.
Faut arrêter ! systemd est conçu pour aller vite et c'est tout. Il suffit de relire l'annonce de systemd, tout tourne autour de fast !
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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 Etienne Bagnoud (site web personnel) . Évalué à 3.
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 ?
Et "démarrer le réseau" dépend du service qui va tourner dessus. systemd supporte-t-il l'activation pour les services utilisant les "raw socket" (vrai question) ?
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.
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.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . Évalué à -6.
C'est un peu ce que je dis, c'est utile à moitié. Donc inutile. Soit tu es sur un système de bureau et, finalement, tu n'as que très peu, voir pas du tout, de service en écoute sur le réseau, soit tu es sur un serveur et là tu vas mettre en place les tests complets de tes services et donc systemd ne fait qu'un truc inutile, un test sans intérêt vu qu'il y a des tests plus complets mis en place. En fait le seul cas utile de cette surveillance c'est pour les ordinateurs de bureau des "power user", mi-serveur, mi-"ordi de bureau". Et cette situation est normal, vu que systemd a été développé pour la vitesse de démarrage. D'ailleurs à l'annonce de systemd, l'explication de l'activation des sockets donne (emphase de moi):
Ah oui, ben en fait ils ont fait ça pour avoir le « fantastic boot-up times » de MacOS … Et en plus ça permet de ne plus gérer les dépendances … Oh ! Mince ! En fait systemd ne fait pas de gestion des dépendances !
Enfin on en revient à mon premier message, systemd a été conçu uniquement pour la vitesse ; dans le cadre historique et dans l'annonce de sa sortie, tout concorde.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Anthony Jaguenaud . Évalué à 1.
Pour moi, un service est démarré quand le processus rend la main. Un démon, va forké, faire son changement de session, s'initialiser, et à ca moment prévenir le père que c'est bon. Alors, le père meurt, et le script, lanceur de démon (openrc, systemd…) peut supposer que le service est opérationnel.
[^] # Re: If it works, don't fix it.
Posté par xcomcmdr . Évalué à 2.
C'est super propre et efficace et pas compliqué du tout.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: If it works, don't fix it.
Posté par Batchyx . Évalué à 3.
J'ai voulu tester systemd justement sur un système avec peu de RAM qui lancait des services pas souvent utilisés.
Alors oui, systemd n'a pas lancé ces services, mais au final, l'occupation en RAM du PID1 était similaire à celle des services qu'il n'a pas lancés. Et si j'accédais à ces services, mon swap se remplissait …
[^] # Re: If it works, don't fix it.
Posté par Le Gab . Évalué à -5.
Franchement, je voudrais plutôt que ces distributions aient réellement une plus value, un peu à la *BSD où ont sait que fait quoi et ont leurs outils spécifiques!
Car un bête réempaquetage, un logo différent, des noms de services différents : pour l'une smb, pour l'autre samba, ssh soit openssh-server, l'une misant sur XFCE l'autre sur KDE… franchement ça gonnnfle!
Fedora veut faire une déclinaison "workstation", supeeeer! déjà que c'est une distro expérimentale à la base, je ne comprends pas que des osent encore la suggérer à des utilisateurs lambda.
Enfin, moi je suis incroyablement satisfait de Debian et je dis qu'elle devrait enterrer les toutes sauf Gentoo! :p
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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 Ignatz Ledebur . Évalué à 2.
La gestion des dépendances entre services, ça reste quand même un problème essentiellement dans le cadre d'un démarrage parallèlisé, type de démarrage qui sert à aller vite (en séquentiel, tu t'en moques à peu près, le premier service ayant besoin de "totod" le démarrant pour tous les suivants).
Perso, je me suis toujours demandé ce que les gens pouvaient bien faire des 30 secondes (je suis généreux) qu'ils gagnaient au démarrage. C'est certes énorme en temps machine, mais en temps humain, c'est même pas assez pour aller pisser.
[^] # Re: If it works, don't fix it.
Posté par Renault (site web personnel) . Évalué à 2.
Pourquoi aller plus lentement quand aller plus vite est possible sans contre partie négative ?
J'ai un ordinateur portable, parfois je veux avoir une information rapidement en étant à l'extérieur, perdre 30 secondes pour ça peut être énorme. En tout cas c'est très frustrant.
De toute façon quand ton ordinateur s'est lancé tu as rarement besoin de tous les services lancés. Typiquement Windows 8 ne démarre le réseau qu'après t'avoir montré l'écran de connexion comme ça le temps de taper ton mot de passe tu as le réseau de lancé. Est-ce que tu as réellement besoin du réseau avant ça ? Et de tous les services (impression, Bluetooth, serveur Web, serveurs divers, SSH, etc.) ? Rien ne peut attendre ?
Non seulement ça va vite mais ça optimise au maximum ton temps et celui de la machine et c'est bien ce que l'on attend d'un ordinateur.
[^] # Re: If it works, don't fix it.
Posté par Maclag . Évalué à -2.
Il faut arrêter effectivement ces conneries.
Lennart a déjà clarifié plusieurs fois: il n'a rien fait de particulier pour améliorer la vitesse de démarrage (au moins aux débuts, aujourd'hui je ne sais pas).
Le but de systemd n'était pas un démarrage plus rapide!!
Sa phrase reste totalement correcte: un bon système d'init travaille vite. C'est un effet de bord quand on est capable de gérer les lancements parallèles et d'autres trucs.
Dire que systemd est conçu pour démarrer plus vite, c'est aussi pertinent que dire que les voitures électriques ont été conçues dans le but de réduire le bruit.
Ce n'est pas le but, mais ça vient avec et c'est très appréciable.
[^] # Re: If it works, don't fix it.
Posté par dinomasque . Évalué à 10.
L'annonce de systemd pointée par Etienne va pourtant très clairement dans le sens systemd = boot rapide).
Quels éléments autres disent que la vitesse n'était pas l'objectif premier ?
ps: de toute façon, le boot rapide, BeOS le faisait y'a 15 ans et en joli en plus ;)
BeOS le faisait il y a 20 ans !
[^] # Re: If it works, don't fix it.
Posté par manawy (site web personnel) . Évalué à 2.
je pense que l'idée principale est que les devs de systemd assument que si on fait les choses correctement alors le système est rapide.
Et donc la rapidité de systemd est juste une preuve que toutes les features sont implémentées correctement.
Après est-ce que cette hypothèse est vrai ou pas… de plus "rapidité" c'est tellement large.
C'est sans doute vrai dans la mesure où, si l'on est rapide, on a utiliser au mieux les ressources du système.
Et tout dépend de la définition de "faire les choses correctement" (par exemple comment définit-on le compromis robustesse-sécurité-rapidité-…)
[^] # Re: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
Une année avant la sortie (avril 2009) de systemd, Intel annonçait l'objectif du démarrage en 2 secondes pour son système Moblin (basé sur Linux). À ce moment là, la première version d'Android venait de sortir sur smartphone (octobre 2008) et Moblin était bien perçu pour entrer sur le marché mobile. Une année après l'annonce du démarrage en 2 secondes d'Intel, sortait le code de systemd avec un message expliquant qu'il était rapide. De mon point de vu, une année pour décider, designer, coder et sortir un système de démarrage tel que systemd me semble assez juste.
Donc du fait que systemd soit apparu durant une période où Linux faisait la course au démarrage et que le message de sortie de systemd ne parlait que d'un système de démarrage rapide, je suis convaincu que l'idée principale des devs de systemd était fast.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par manawy (site web personnel) . Évalué à 2. Dernière modification le 25 avril 2014 à 19:40.
j'ai jamais dis le contraire, j'ai juste dis que j'ai l'impression que pour les devs de systemd, être rapide c'est un gage de qualité.
C'est un esprit qu'on retrouve dans beaucoup d'écrits des devs de systemd pour le justifier :
1) il n'y a aucun mal a être rapide
2) c'est la preuve que le code s'adapte au-mieux à son environnement (d'où les features linux-only) et au hardware
3) c'est aussi la preuve que les features sont implémentés correctement, on perd pas son temps à faire des choses inutiles…
ça c'est leurs point de vue… c'est justifié sous certain aspect, un peu moins sous d'autre (quid de la sécurité)
Et si la rapidité était l'unique avantage de systemd alors oui, ils ne serait pas utilisé. Le fait est qu'il a beaucoup d'autre avantages (je ne ferais pas une n-ieme list ici).
(Pour info je n'utilise pas sytemd, je suis sous gentoo et perso je n'ai pas vraiment de préférence openrc/systemd, juste que le démarrage est effectivement lent sous openrc…)
[^] # Re: If it works, don't fix it.
Posté par Arthur Accroc . Évalué à 8.
Vu comme ça, quand je me prends un blocage d’un quart d’heure ou plus à l’arrêt de la machine (montages NFS avec autofs, unités systemd non modifiées), ça doit bien prouver qu’il y a des trucs pas correctement implémentés…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 5.
Tu veux dire que ce n'est pas une implémentation parfaite sans bug ? C'est vraiment étonnant…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par Anonyme . Évalué à 6.
Je crois que l'objectif premier supposé de lennart quand il a crée systemd, on s'en fou. Le résultat c'est que systemd a plein d'avantages autres que la vitesse de boot. Donc résumer systemd à un boot plus rapide c'est ne pas avoir compris grand chose à ce qu'est systemd.
[^] # Re: If it works, don't fix it.
Posté par Maclag . Évalué à 3.
http://0pointer.de/blog/projects/the-biggest-myths.html
Je me demande combien de fois on verra ce lien sur ce site…
(PS: 20secs sur Google hein!)
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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: If it works, don't fix it.
Posté par Misc (site web personnel) . É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: If it works, don't fix it.
Posté par Ignatz Ledebur . Évalué à 9.
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. Quand tu es mainteneur et que tu vois le maintien d'un truc comme ça t'arriver sur les bras à moyen terme, ça incite quand même pas mal à donner toute sa chance à la nouvelle solution.
On pourrait aussi parler de l'effet moutonnier présidant à certaines décisions qui devraient être purement techniques. Souvenons-nous par exemple de KDE 4.0, sur lequel presque tout le monde s'est précipité pour ne pas passer pour un ringard à côté des autres…
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.
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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: If it works, don't fix it.
Posté par Ignatz Ledebur . Évalué à 2.
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).
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 2.
Et donc, il est revenu sur quel partie du message ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par Ignatz Ledebur . Évalué à 5.
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
Quatre mois à peine, pour apprendre que finalement on allait jeter le support d'un udev indépendant le plus vite possible.
De fait, après avoir longtemps maintenu un build alternatif, ils ont fini par lâcher l'affaire chez LFS :
« The extraction I was doing was a PITA because of upstream's mixing in non-udev stuff which kept making the task more and more difficult. »
Et dans la mesure où maintenant LFS se décline avec une version systemd, je doute qu'on puisse les accuser de faire de l'anti-systemd primaire.
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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: If it works, don't fix it.
Posté par Ignatz Ledebur . Évalué à 2.
En relisant bien ce qui t'arrange peut-être (je graisse) :
Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball and package only what is necessary of the resulting build.
Je sais qu'il n'y a pas de foi sans mauvaise foi, mais quand même…
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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 jyes . Évalué à 6.
Les problèmes avec autofs, ou le boot sur partition chiffrée, etc me font penser que systemd n’est pas non plus un stradivarius. Personnellement, je pense que systemd est une piste intéressante, et sûrement le futur, mais il arrive beaucoup trop vite dans les distributions et est présenté par ses auteurs et défenseurs comme une solution qui surpasse toutes les précédentes, alors qu’il ne tient pas encore toutes ses promesses.
[^] # Re: If it works, don't fix it.
Posté par xcomcmdr . Évalué à 4.
En gros, faut qu'il soit parfait avant de sortir.
Balivernes.
Et c'est Lennart le mainteneur des distributions ? non !
Release early, release often. Et là, tu finiras pas avoir un vrai logiciel.
Linus n'a pas attendu, lui.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: If it works, don't fix it.
Posté par gnx . Évalué à 5.
Un peu dans le genre, tu as aussi ce qui s'est passé sur Arch :
Avril 2012 :
Août 2012 :
Novembre 2012 :
Messages de Tom Gundersen, développeur Arch. Accessoirement employé de RedHat et développeur principal de systemd.
Non, franchement, que des gars en lesquels on doit avoir confiance…
[^] # Re: If it works, don't fix it.
Posté par Sylvain Blandel . Évalué à 5. Dernière modification le 25 avril 2014 à 15:03.
Tu démontres que, sous SysVinit, les utilisateurs sont contraints d'apprendre le shell pour administrer leurs machines. Qu'ils sont forcés d'apprendre le fonctionnement des outils vi/grep/sed/awk/cat/less. S'ils veulent personnaliser finement leurs machines, on leur impose de savoir écrire des scripts.
Sous systemd, les utilisateurs sont contraints d'apprendre le fonctionnement de systemd pour administrer leurs machines. Ils sont forcés d'apprendre le fonctionnement de la commande
systemctl. Si les utilisateurs veulent personnaliser finement leurs machines, on leur impose de savoir écrire des fichiers.service.Tu as fait l'effort d'apprendre le shell. Après avoir passé des heures à suivre des tutoriels et à lire des pages de manuel, tu maîtrises cet outil. Tu écrits des scripts facilement et rapidement. Cela te convient très bien, tu es l'aise avec le shell.
Nos successeurs apprendront systemd. Et, une fois la période d'apprentissage passée, ils seront à l'aise avec cet outil.
[^] # Re: If it works, don't fix it.
Posté par zul (site web personnel) . Évalué à 7.
Le shell, ça permet de faire un peu plus de chose que systemd, genre c'est un outil de base pour administrer / jouer avec un unix, pas juste l'init. Enfin, je suis sûr qu'on finira par avoir un lennartsh avec sa syntaxe propre, plus "moderne".
[^] # Re: If it works, don't fix it.
Posté par Frank-N-Furter . Évalué à 1.
On parle de scripting shell
Depending on the time of day, the French go either way.
[^] # Re: If it works, don't fix it.
Posté par Sylvain Blandel . Évalué à 2.
Ça tombe bien, systemd est bien plus qu'un système d'initialisation. Systemd permet d'arrêter/redémarrer/mettre en veille la machine, de lancer/suivre/arrêter les services, de lister les services défaillants, de créer et gérer des fichiers temporaires, de démarrer des services selon des contraintes temporelles, de gérer les logs du système. Et il y a également d'autres fonctionnalités.
Peut-être que dans 15 ans, « être un(e) excellent(e) administrateur(trice) de système linux » signifiera « maitriser parfaitement systemd », et qu'une connaissance poussée du shell sera devenue facultative ?
[^] # Re: If it works, don't fix it.
Posté par anaseto . Évalué à 1. Dernière modification le 26 avril 2014 à 12:50.
Dans 15 ans les administrateurs utiliseront tous bashd.
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . Évalué à 3.
Ou rubyd, à un moment, faudrait évoluer.
[^] # Re: If it works, don't fix it.
Posté par zebra3 . Évalué à 5.
Le shell, c'est surtout un truc pour faire des scripts à l'arrache, rapidement illisibles et impossibles à maintenir dès que tu veux un truc un peu compliqué.
Et pas besoin d'un nouveau langage, tu en as déjà plein qui suffisent largement (Perl même si je n'aime pas, ou bien Python et Ruby).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: If it works, don't fix it.
Posté par gnumdk (site web personnel) . Évalué à 6.
Et rajouter un service à systemd pour lancer un gros script shell et faire sa tambouille, ca prend 1 minute…
[^] # Re: If it works, don't fix it.
Posté par barmic . Évalué à 6.
Faudrait pas abuser non plus les shells sont imbattables pour manipuler des fichiers et pour certaines formes de parallélisme.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 3.
Ou pour lancer des commandes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par flagos . Évalué à 6.
Mince, tu veux dire que systemd va également remplacer nos shell ?
[^] # Re: If it works, don't fix it.
Posté par Reihar . Évalué à 4.
Je tiens à rappeller au passage que les .service sont simples à écrire et LISIBLES contrairement aux scripts sysv.
[^] # Re: If it works, don't fix it.
Posté par dinomasque . Évalué à 4.
Ben shell, vi, grep, sed, awk, cat, less et compagnie c'est un peu la base d'UNIX.
Bien sur que pour jouer avec un composant système d'un UNIX-like il faut avoir appris les fondamentaux d'UNIX ;)
Comment le reprocher à SysVinit ?
Par opposition, Systemd demande à un administrateur d'apprendre UNIX + Systemd, ça fait beaucoup plus.
BeOS le faisait il y a 20 ans !
[^] # Re: If it works, don't fix it.
Posté par manawy (site web personnel) . Évalué à 5.
En même temps, sysinit fait deux choses à la fois dans les scripts init; c'est à la fois des scripts de configuration et des exécutables.
Systemd respecte mieux "l'esprit unix" parce que les fichiers de configuration sont juste des fichiers de configuration.
Cela accroît la sécurité, la lisibilité, la robustesse de l'ensemble, …
[^] # Re: If it works, don't fix it.
Posté par ZeDuke . Évalué à 2.
Euh dans un script sysvinit fait consciencieusement et dans les règles de l'art, un sourcing des fichiers de conf (/etc et/ou /etc/default whatelse?) est fait au début du script : la configuration est séparée du script et c'est heureux.
Après je dois avoir passé trop de temps à faire du shell au lieu de tripoter du systemd, mais je trouve vraiment rien de sorcier à lire/écrire du script shell. Surtout que dans la majorité des cas ça revient à faire toujours à peu près la même chose au détail près du démon lancé qui change : un chargement des fichiers de conf, un parsing des arguments, un gros switch case pour les traiter. La complexité reste dans le code du démon lancé heureusement !
Bon à un peu plus de 30 piges et 15 ans de GNU/Linux et autres Unices, je sens déjà plus le vieux croûton que la miche qui sort du four… Monde cruel !
Sur ce, m'en vais retourner à mon havane … ça suit des lois d'évolution beaucoup plus lente (même si il y aurait à redire mais ce serait complètement HS).
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 10.
Tu trouve plus lisible
que
Et bien pas moi, si je dois audité un minimum pour éviter d'introduire un truc potentiellement dangereux, je préfère de loin une unité systemd, il y a beaucoup moins de ligne et encore moins de ligne qui peuvent poser problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par gouttegd . Évalué à 5.
Les scripts d’init System V comme ceux-là sont imbitables, c’est clair, mais il ne faudrait pas oublier qu’il existe d’autres façons de faire qui n’impliquent pas de remplacer le système init tout entier…
Chez moi, un script d’init, ça ressemble plutôt à ça :
[^] # Re: If it works, don't fix it.
Posté par Ignatz Ledebur . Évalué à 4.
Ouais, enfin, très honnêtement je ne vois pas quelles difficultés pose ce script. C'est impressionnant a priori, mais dès que tu te plonges un peu dans le contenu, c'est assez simple, même sans connaître le contenu des libs sourcées au début.
Le truc, c'est qu'un script est une séquence de commandes, quant un fichier de config est une simple série de variables. Nécessairement le premier nécessite plus d'effort à la lecture, la contre-partie étant que c'est assez simple à déboguer (tu peux tester séquence par séquence dans ton shell, pas besoin de mettre le nez dans du C ni d'attendre les corrections upstream à la moindre couille).
[^] # Re: If it works, don't fix it.
Posté par Thomas Douillard . Évalué à 10.
Si c'est pour debugger encore et toujours les mêmes bugs, ou laisser des problèmes de fond traîner sous prétexte que c'est simple à debugger, ça ne vaut pas le coût. Autant mutualiser le tout proprement, debugger et laisser une trace de l'expérience dans le code mutualisé.
[^] # Re: If it works, don't fix it.
Posté par Ignatz Ledebur . Évalué à 1.
Je ne vois pas en quoi le shell ferait que tu débogues toujours les mêmes choses. Les scripts ne s'auto-réécrivent pas magiquement, et POSIX n'est pas fait pour les chiens pour ce qui est de la solidité des solutions. Mais quand bien même, le point central demeure qu'avec du shell tu es beaucoup plus autonome, et que c'est donc finalement une histoire classique de curseur entre liberté/facilité.
Pour ce qui est de la trace, je doute que les gens se tapent n années de logs avant d'introduire un mauvais changement. Ça ne servira que s'il reste dans le projet des personnes se souvenant d'avoir eu une couille du même type avec « attends que je me souvienne… »
[^] # Re: If it works, don't fix it.
Posté par Thomas Douillard . Évalué à 6.
Il n'y a rien qui ressemble plus à un script d'init qu'un autre script d'init. C'est peut être ''facile'' à debugger, mais c'est encore plus facile de ne pas avoir à l'écrire. Sur la trace, elle est inscrite dans le code, on peut laisser un commentaire, il y a des tests de non régression … Tu veux comparer ça avec un nième problème d'écriture d'init script pour un nouveau service qui a finalement exactement les mêmes problèmes que les autres, ou alors pas les mêmes problèmes que les autres et pour leuquel on va copier/coller un script standard qui marche pas (ou qui a l'air de marcher …) ?
[^] # Re: If it works, don't fix it.
Posté par ZeDuke . Évalué à 5.
Oui mais rien n'empêche de mutualiser du code shell comme c'est déjà le cas avec LSB. Ensuite pour que la comparaison de Xavier Claude soit valable, il faut qu'il compare le code C de systemd lié au lancement/séquencement + la configuration du service avec le script init shell.
Après l'avantage d'un code shell mutualisé shell, c'est que tu peux choisir de l'utiliser … ou pas ! Une simple ligne de commentaire et hop ! C'est l'avantage d'être une library plutôt que le coeur de ton system. Alors que dans la cas de systemd si tu veux modifier légèrement le comportement d'un lancement, pour un seul démon, parce que t'es dans un cas particulier ou que tu veux tester quelquchose … bah tu peux pas. Tu dois te plier au plus petit dénominateur commun, qui je l'accorde va fonctionner dans 95% des cas, mais qui ne va pas te permettre de gérer à ta sauce même de manière temporaire.
Pour finir, le seul avantage que je voyais à sytemd c'est la gestion fine de l'ordonnancement des démons/tâches grâce à une synchro DBus. Mais malheureusement si même ça c'est pas encore au point à la vue de ce qui et décrit plus haut sur autofs … alors pour l'instant en temps qu'adminsys je sens que je vais être plus embêter qu'autre chose par cette migration forcée.
[^] # Re: If it works, don't fix it.
Posté par Thomas Douillard . Évalué à 6.
Systemd peut lancer un script, non ?
[^] # Re: If it works, don't fix it.
Posté par zebra3 . Évalué à 7.
Je ne vois pas le rapport.
Ou alors pour réellement être honnête il faut aussi compter les lignes en C du shell et des outils de bases appelés par le script (echo, rm, etc).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 3.
Et le code noyau utilisé pour les appels systèmes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par ZeDuke . Évalué à 1.
Xavier Claude parlait je cite
Je suis désolé mais s'il n'audite que les .service il ne va pas auditer grand chose. Ce ne sont que des fichiers purement descriptifs. La seule chose à auditer s'il veut auditer quelquechose c'est systemd en lui même.
Par contre je suis d'accord qu'une fois audité, ça le sera pour tous les services l'utilisant, tout comme ce serait le cas si la LSB était plus riche, et son utilisation plus systématique. Par exemple la quasi totalité des fonctions en préambule du script init cité, en particulier celle vérifiant que le programme ayant le PID stocké dans le PIDFile soit bien le bon programme (le reproche fait par Misc plus bas) est tout à fait générique et aurait sa place dans une library.
Ce que je veux dire, c'est que dans ce cas, ton audit se dirigera uniquement sur les scripts n'utilisant pas délibérément la "library", mais pour que ce soit viable sa non-utilisation devra être limitée et justifiée par les mainteneurs. Tu conserveras la flexibilité de pouvoir en tant que non mainteneur modifier à volonté un script en particulier si ça te chante, tout ayant une base commune riche, stable et "auditée".
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 4.
Sauf que systemd, il vient de ma distribution, le script d'init/.service, il vient potentiellement d'ailleurs (quand le logiciel/la version n'est pas dans les dépôts).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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) . É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 claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par gouttegd . Évalué à -2.
Il est rudimentaire, c’est certain. C’est pour ça que je l’apprécie. Il fait le job 99.9% du temps, je n’en demande pas plus.
Je précise que ce n’est pas à l’unité systemd qu’il faut comparer ce script (ça n’aurait aucun sens), mais bien au script System V, qui est beaucoup trop long pour le peu de services qu’il rend.
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. Si je voulais vraiment gérer ces cas tordus (personnellement je m’en moque, mais je comprends ceux qui le veulent), je préférerais encore utiliser systemd.
H.S. :
J’aurais aimé mettre
stunnel.piddans/var/runavec les autres, mais en l’occurence, avec stunnel c’est un peu plus délicat, il est chrooté dans/var/lib/stunnel/et le fichier de pid ne peut se trouver que dans le chroot. J’imagine que le script d’init pourrait se charger de récupérer le PID et l’écrire lui-même à la bonne place, mais on rentre précisément dans le genre de complications inutiles que je ne veux pas voir dans mes scripts d’init.D’ailleurs, que propose systemd dans ce cas de figure ?
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 4.
Tu peux aussi faire
mount --bind /run/stunnel /var/lib/stunnel/run. Mais si le but est de faire au plus simple, ce n'est pas très pertinent.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . É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 zebra3 . Évalué à 7. Dernière modification le 26 avril 2014 à 16:33.
C'est là tout le problème : le développeur de script doit être consciencieux et faire dans les règles de l'art. Mais c'est pas la majorité.
Alors que pour systemd, le format est concis et permet d'avoir un truc propre sans effort supplémentaire.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: If it works, don't fix it.
Posté par claudex . Évalué à 6.
C'est la même problématique qu'entre faire du C et utiliser un langage de haut niveau qui évite de gérer des éléments problématique. Ou entre le fait de refaire son implémentation ou d'utiliser une bibliothèque existante.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: If it works, don't fix it.
Posté par zebra3 . Évalué à 8. Dernière modification le 25 avril 2014 à 22:38.
Justement non, vu que tu peux remplacer tous tes scripts par des unités, pas besoin d'apprendre UNIX.
En plus « connaître UNIX » ne veut rien dire, tu as tellement de différences entre une Red Hat et une Debian qu'un habitué de l'une sera perdu avec l'autre.
Et je ne parle même pas des UNIX non-Linux. J'ai touché un peu à du HP-UX et du Solaris, les fondamentaux c'est sympa pour les trucs de base mais pour administrer c'est franchement léger : amuse-toi à chercher comment configurer la couche réseau quand tu « connais » UNIX.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Slackware risque de passer à systemd
Posté par Tsomi . Évalué à 5.
Pas par amour, mais parce que ça va devenir impossible de faire autrement :
http://www.linuxquestions.org/questions/slackware-14/i%27m-back-after-a-break-from-slackware-sharing-thoughts-and-seeing-whats-new-4175482641/#post5054861
L'avantage c'est que dans quelques années on choisira sa distribution juste pour son wallpaper. On aura enfin ce Mac OS X gratuit que tous les utilisateurs veulent et on vivra dans le meilleur des mondes : Linux enfin prêt pour le desktop.
a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
[^] # Re: Slackware risque de passer à systemd
Posté par Sylvain Blandel . Évalué à 2.
Le message que tu pointes date d'octobre 2013, c'était il y a 6 mois. À l'époque, le comité technique Debian n'avait pas encore rendu sa décision. Et Ubuntu n'avait pas annoncé sa migration vers systemd.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.