Énième remous de l’affaire systemd/debian : un « groupe de développeurs Debian » menace de forker la distrib si on ne laisse pas à l’utilisateur la possibilité de ne pas utiliser systemd.
La guerre de tranchée fait toujours rage :
http://www.debianuserforums.org/viewtopic.php?f=12&t=3031
http://soylentnews.org/article.pl?sid=14/09/27/2211225
Le problème est double, certains rejettent systemd en tant que solution technique, et certains sont choqués par la manière dont la décision a été prise.
Moi ce qui m’inquiète un peu, en dehors de ce gaspillage d’énergie, c’est que la seule mention à udev sur la page debianfork.org vient d’un email d’un utilisateur, copié sur la page d’accueil. Alors que c’est la première question qui me vient à l’esprit : si ça forke, qui va maintenir udev et compagnie, tout ce qui repose désormais sur systemd dans la plupart des autres distros ?
# Beaucoup de bruit
Posté par claudex . Évalué à 10.
Vu qu'il n'y a déjà pas assez de monde pour maintenir Debian/kFreebsd alors que ce noyau est en place depuis longtemps et a plus de ressource (comme il est déjà utilisé dans Freebsd et par conséquent a tout l'infrastructure pour les remplaçant d'udev qui existe déjà). Je doute qu'ils trouvent assez de monde ayant un peu d'énergie pour bosser vraiment et maintenir toute la distrib.
« 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: Beaucoup de bruit
Posté par Almin (site web personnel) . Évalué à 7.
À propos de BSD, on voit de plus en plus de monde qui pense migrer si systemd devient incontournable sous Linux.
[^] # Re: Beaucoup de bruit
Posté par claudex . Évalué à 10.
Comme le disais Misc, c'est une bonne chose, ça leur ferra plus de main d'œuvre et donc la concurrence dans le libre va s'améliorer ce qui ne peut être que bénéfique.
« 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: Beaucoup de bruit
Posté par eingousef . Évalué à 3.
Wow, si tu passais pas ton temps à dire exactement le contraire sur la tribune, j'aurais presque envie de te plusser.
*splash!*
[^] # Re: Beaucoup de bruit
Posté par Misc (site web personnel) . Évalué à 7.
Bah, je pense qu'il a le droit d'avoir un avis différent du mien :)
Je pense qu'en effet, un apport de gens motivés pour les BSD serait une bonne chose. Je suis par contre pas forcement sur que les gens qui ralent sur systemd dans debian soient dans leur grande majorité ce genre de gens. Il y en a sans doute, et il y a des gens qui ont des critiques valables, et qui tombent sur des bugs et des régressions ( keyscript et luks, par exemple ). Ensuite, ça serait pas la première regression dans debian ( le fait de retirer haproxy dans la dernière stable par exemple ), c'est des choses qui arrivent à tous.
Et bon, ce genre d'article :
http://www.vitavonni.de/blog/201410/2014101801-beware-of-trolls---do-not-feed.html
ça me rappelle quand même south park ( l'épisode sur le drapeau ).
[^] # Re: Beaucoup de bruit
Posté par claudex . Évalué à 2.
Ah ben non, je suis d'accord avec toi sur ce point. D'ailleurs, je ne sais pas vraiment d'où il sort le fait que je dise le contraire.
« 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: Beaucoup de bruit
Posté par eingousef . Évalué à 5.
Bonjour, je cherche un type qui s'appelle claudex<, qui vient régulièrement sur la tribune, et lorsqu'on y parle de systemd dit que les utilisateurs de sysvinit sont des réactionnaires, qu'ils passeront à systemd de toute façon, que toute résistance est futile et que les distros qui utilisent encore autre chose que systemd doivent toutes passer à systemd ou disparaître. Tu ne l'aurais pas vu par hasard ?
*splash!*
[^] # Re: Beaucoup de bruit
Posté par Vincent Bernat (site web personnel) . Évalué à 3.
Le retrait de HAProxy est un souhait de l'upstream qui n'a pas aimé la façon dont HAProxy a été traité dans les précédentes releases. Debian a toujours traditionnellement suivi les choix de l'upstream. HAProxy a été immédiatement mis à jour dans les backports pour combler ce manque et sera présent dans Jessie.
[^] # Re: Beaucoup de bruit
Posté par Misc (site web personnel) . Évalué à 2.
Je ne doute pas le moins du monde que la raison derrière ce souci soit valable et rationnel. Même si tu m'avais dit "on a retiré haproxy car on avait personne pour s'en occuper", j'aurais trouvé ça acceptable, ça fait parti du jeu des distros communautaires ( voir même commercial, avoir un peu plus de ressources implique pas d'en avoir une infinité )
Je fait confiance aux gens du libre pour faire des choix avec une bonne raison, même si parfois je peux ne pas être d'accord.
Mon point est juste que l'argument de jamais avoir de changement ou de régression est une vison idéalisée. Un autre exemple est selinux, et je pourrais raler sur le fait de pas avoir eu de réponse sur mes rapports de bugs sur la stable ( avec 2 patchs ), mais si y a personne pour faire le taf sur la stable, bah tant pis pour moi :)
[^] # Re: Beaucoup de bruit
Posté par flan (site web personnel) . Évalué à 10.
Moui, il y a de la marge entre le dire et le faire.
Si tu vas sur les forums Mac (Macbidouille, par exemple), il y en a beaucoup qui disent qu'ils vont passer à Linux ou au Hackintosh depuis des années, et qui finalement restent sur OS X.
[^] # Re: Beaucoup de bruit
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 19 octobre 2014 à 20:06.
chiche, tu veux qu'on ouvre la paris entre ceux qui font et ceux qui disent qu'ils vont faire? Allez, je pari moins de 1% de la masse de râleurs va effectivement le faire, et je prend de la marge (et j'en profite pour parier que tous les forks Linux qui ont pour idée de juste virer systemd vivront entre 0 et 1 version, les personnes derrière ces idées de fork ne tolerant pas la démocratie ni n'ayant une idée réelle de ce qu'ils veulent hormis "c'était mieux avant", ça va être dur de trouver assez de monde motivé par la tonne de boulot à faire, et par un système qui sera de moins en moins performant en comparaison de système moderne, dans le temps)
# Autant qu'ils forkent
Posté par JoeltheLion (site web personnel) . Évalué à 10.
Mieux vaut à mon sens un bon fork pour voir qui est vraiment prêt à mettre les mains dans le cambouis plutôt que de continuer les flamewars sur les listes de diffusion.
[^] # Re: Autant qu'ils forkent
Posté par Misc (site web personnel) . Évalué à 10.
Idéalement, voir même installer un forum sur leur site, histoire que les gens puissent se concerter et proposer une communication construite.
Je serait le premier à lister des soucis de systemd si on me demande ( la dépendance aux cgroups était par exemple un souci sur mes VPS sans le support dans le kernel, bien que ça soit corrigé via un patch upstream ), mais j'ai relu tout les threads de debian-user, c'est extrêmement peu précis. Il y a des bugs, il y a une features bien spécifiques sur la crypto qui semblent ne pas marcher, mais le reste c'est des gens veulent pas parce qu'ils veulent pas. Y a un mec qui poste pour dire que c'est plus compliqué à réparer pour lui. C'est sans doute vrai, il faut d'autres connaissances que le shell, mais je ne voit personne faire ce genre d'argument vis à vis de tout le reste des choses en C ( à part le projet olpc, qui a tout fait en python pour laisser les gens lire le code ).
une bonne part semble agiter le spectre de "ça ressemble à windows" et "Red hat va contrôler le monde du libre avec ça". Mon favori reste quand même le mec qui postule que systemd est la pour rendre les choses plus compliqués afin de vendre plus de services et de consulting via des techniciens "forcement" certifiés par RH.
Donc je pense que faire un groupe de discussion avec quelqu'un pour répondre point à point et garder les remontés valables ( par exemple, améliorer les messages d'erreur pour rendre les fichiers d'unités plus facile à debugger en essayant de voir ce qui fait que les gens trouvent ça difficile à debugger ) serait positif.
Actuellement, ça part plus dans l'outrage personnel à base de reprendre le concept de "linux is about choice".
[^] # Re: Autant qu'ils forkent
Posté par Zenitram (site web personnel) . Évalué à 4.
Depuis le temps qu'on entend parler de fork, rien de concret (et lit le site mis en lien, personne ne dit qu'il va tenter un fork, au contraire ils disent qu'ils ne vont pas le faire). Ca ne te donne pas un petit indice sur le nombre de personnes prêtes à mettre les mains dans le cambouis?
[^] # Re: Autant qu'ils forkent
Posté par barmic . Évalué à 10.
Non c'est des blaireaux. Ça ne va rien donner parce que les immatures qui ne comprennent pas de quoi ils parlent ne produisent jamais rien ou du moins rien de très intéressant.
Forker Debian pour pouvoir proposer aux utilisateurs de continuer à utiliser sysvinit, c'est à peu près aussi malin que de s'agenouiller dans la rue et de se taper la tête contre le goudron.
Une solution intéressante serait de créer un tasksel qui va bien et d'éditer un installer qui le propose par défaut. Ça demande très peu de boulot (une personne seule peu le faire) et ça demande presque pas d'infrastructure (l'infra de Debian peut très bien la plupart des choses). Le seul travail que ça demande c'est de maintenir sysvinit et par exemple de porposer aux paquets des scripts de démarrage de sysv chose qu'ils vont devoir faire de toute manière.
Mais c'est vrai que :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autant qu'ils forkent
Posté par Misc (site web personnel) . Évalué à 10.
Je pense que garder sysvinit n'est en effet pas le plus gros souci. Le souci, ça va être de convaincre les packageurs de garder les scripts d'init dans leur paquets, et de corriger les potentiels bugs. Et bien sur de garder et corriger les trucs de démarrage en shell ( ie, tout /etc/rcS.d/* ) si besoin. Et sur le point des bugs, je suis rassuré de voir que je suis pas le seul à citer le script de bind comme exemple de script buggué par design ( genre, y a un mec qui cite ça sur lwn ).
Et donc je pense que comme systemd élimine quand même une bonne classe de comportement problématique grace au démarrage dans un env clean, il est attractif pourles packageurs de convertir les paquets.
Par exemple, j'ai parlé avec un des devs de fusion inventory , qui m'a dit que le passage à systemd a permis de liquider 1/3 des bugs sur launchpad, cad tout les bugs à la con avec le fait qu'un des processus meurt et pas un autre, etc.
Donc sur la base de ce genre de besoin, je pense que le chemin qui marcherait serait de pousser openrc ( car portable, et encore en cours de dev ), et le rendre capable de lire les fichiers de systemd, et/ou trouver comment faire des scripts d'init depuis les fichiers de systemd ( cf projet gsoc ).
Du coup, les gens qui veulent pas systemd auront une alternative. Les gens qui veulent des scripts auront leur truc en shell, avec sans doute moins de variations. Et la charge de travail pour les packageurs resteras raisonnable.
Bien sur, ça ne régle le souci que pour la partie "init". Il resteras encore le souci pour logind et la subsistance de systemd-shim sur le long terme.
Tout ça, je pense que ça aurais pu se faire durant les mois depuis le premier vote et maintenant par quelqu'un d'assez motivé et compétent, avec assez de temps. Je ne me prononcerais pas sur le fait que ça ne soit pas arrivé pour le moment, malgré tout ces gens qui sont prêt à protester.
Sinon, c'est aussi une bonne nouvelle pour debian lts, car je suis sur que tout ces gens vont mettre la main à la poche pour financer la survie de la stable courante pour éviter le piége systemd, bien sur.
[^] # Re: Autant qu'ils forkent
Posté par barmic . Évalué à 2.
Tout le monde a oublié l'existence de metainit. Les quelques fois où j'en ai parlé ça n'a pas eu l'air d'intéresser grand monde. C'est bien dommage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autant qu'ils forkent
Posté par Misc (site web personnel) . Évalué à 4.
Alors, tu es sur du nom ? Parce que la, je tombe sur un truc d'oracle dans Google.
Et sinon, oui, le souci des discussions constantes sur le sujet est que le niveau technique et les propositions sont au raz des pâquerettes. Ayant lu debian-user@, ça vole pas haut et les gens comprennent pas pourquoi ils veulent pas certaines choses, mais ils sont sur de pas le vouloir.
Il y a sans doute plein de possibilités, mais comme une bonne part des gens semblent fatigués par le sujet qui polarisent une part des utilisateurs, les gens capables de discuter se résignent.
Bien sur, toute tentative de ramener le calme est vu comme "les pro systemd veulent nous faire taire" ( ce qui est vrai, quand quelqu'un a dit 15 fois que c'est une conspiration, la 16eme est du bruit inutile ) et ça repart de plus belle.
[^] # Re: Autant qu'ils forkent
Posté par barmic . Évalué à 2.
Oui : metainit
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autant qu'ils forkent
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 20 octobre 2014 à 08:01.
Si je comprend bien, c'est systemd 0.0.1pre-alpha1: une seule des fonctions de systemd (celle des units à la place de scripts) est ici faites par un programme externe qui va transformer les units en script pour que les scripts soient lancés à l'ancienne, et ces scripts tu ne dois pas les modifier car ils seront écrasé à la prochaine itération, ça fait des scripts statiques (limités aux fonctionnalité du programme qui gère les units). De plus, aucune mise à jour depuis 2008, ça a l'air très vivant comme logiciel.
Euh… Autant mettre systemd non? Ou déjà faire un programme qui lise des units systemd plutôt que "metainit files"? (ho, tiens, c'est ce que dit Misc…)
(Ce programme aurait sans doute été interessant si il avait fait le boulot de systemd, comme par exemple faire un fichier "metainit" universel avec le programme qui adapte suivant les distros, mais vu que le mainteneur Debian et l''auteur du programme sont une personne, que le "site web" du projet est le repo Debian, j'ai un doute que ça pense à autre chose que Debian)
Je comprend, ça a l'air d'être aussi vivant que les forks Debian à cause de systemd.
[^] # Re: Autant qu'ils forkent
Posté par barmic . Évalué à 10.
La seule chose que je dis c'est qu'il y a déjà eu une tentative de faire quelque chose dans ce sens (détend-toi sérieusement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autant qu'ils forkent
Posté par barmic . Évalué à 3.
L'approche d'avoir un fichier générique (que ce soit un unit systemd ou autre n'est pas très important/intéressant) et un générateur ne permet pas simplement de changer l'init facilement (ce qui est une lubbie), mais simplifie largement le travail pour intégrer des paquets dans Debian/kFreeBSD. C'est une approche qui m'a l'air intéressante, mais le seul projet qui allais dans ce sens est mort il y a longtemps dans l'indifférence générale et il semble qu'aujourd'hui encore personne (même les anti-systemd) n'est très intéressé par ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Oubli ?
Posté par cosmocat . Évalué à 5.
Tu as oublié de parler de personnes qui essaient de relancer le vote pour le système d'init de debian: http://lwn.net/Articles/616571/rss
[^] # Re: Oubli ?
Posté par arnaudus . Évalué à 5.
L'acharnement devient réellement ridicule. Le principe d'une gouvernance, même quand elle est collective, c'est de se mettre d'accord sur un système de prise de décision, et de s'y soumettre. J'imagine que ces personnes sont sincères et qu'elles pensent réellement agir pour le bien de Debian, mais il est évident qu'elles se trompent. Mieux vaut tous aller dans la même direction, même si elle n'est pas forcément la meilleure, plutôt que de risquer de déchirer une communauté.
Sur le fond, on sent quand même la rage du conservatisme. Ça doit faire peur de devoir apprendre quelque chose de nouveau à un stade avancé de sa carrière ; les jeunes pigent plus vite, et seront plus efficaces. On perd son expertise et son expérience. Mais c'est quand même moche de réagir de manière aussi violente, et finalement, aussi puérile.
[^] # Re: Oubli ?
Posté par freem . Évalué à 10.
Raté, ce vote n'a pas pour ambition de changer la décision concernant l'init par défaut, mais de s'assurer que Debian ne se fasse pas enfermer par systemd en garantissant le fait qu'un programme doive avoir l'obligation de pouvoir fonctionner, ne serait-ce qu'en mode dégradé, avec un init différent.
Cette obligation ne concernerait évidemment pas les programmes qui ont pour unique rôle celui de gérer le système d'init.
Ce vote ne remets en cause aucune décision, il souhaite simplement préciser de manière claire que Debian supportera les autres systèmes d'init, dans le temps.
Tu vois, dans ton post, je vois plutôt la rage du modernisme…
[^] # Re: Oubli ?
Posté par barmic . Évalué à 6.
Pourquoi personne ne s'est posé la question pour
upstart,openrcourc.d?Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubli ?
Posté par freem . Évalué à 4.
J'imagine que ces systèmes sont nettement plus interchangeables, et nettement moins invasifs, que systemd.
[^] # Re: Oubli ?
Posté par Misc (site web personnel) . Évalué à 10.
Upstart est invasif. Il supporte pas inittab ( comme systemd ), et il a un format spécial ( comme systemd ), et il y a un plan d el'utiliser comme gestionnaire de session ( au moins unity fait ça ).
Et depuis le début, il propose de remplacer atd/crond ( je sais pas si c'est codé ceci dit ).
Ensuite, le fait aussi que personne s'intéresse à upstart, ce qui est triste.
[^] # Upstart blafard ?
Posté par Sylvain Blandel . Évalué à 1.
Sur la liste de discussions upstart-devel, il n'y a eu qu'un seul mail posté entre le 18 septembre 2014 et aujourd'hui (20 octobre 2014). Un seul mail en un mois …
Canonical a décidé de s'appuyer sur systemd pour les prochaines versions d'Ubuntu. Pendant combien de temps cette entreprise investira-t-elle des moyens dans le développement d'Upstart ?
[^] # Re: Oubli ?
Posté par xcomcmdr . Évalué à 1.
systemd propose, les développeurs d'applications / mainteneurs disposent. Je vois pas en quoi c'est invasif.
Quant à systemd-logind et consorts, il est utilisé par GNOME parce que ConsoleKit est mort et enterré.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# J'ai bien ri
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 19 octobre 2014 à 20:19.
Sur le site
Justement, c'est bien le soucis : veteran != bon.
On peux juste être expérimenté sur savoir comment mieux faire tourner la manivelle d'un voiture pour la démarrer, et ne pas aimer apprendre à tourner une clé de contact (zut, comment on va vendre nos cours pour mieux faire tourner la manivelle? Ho, problème sur notre business!)
Ca s'appelle un argument d'autorité, et généralement ça annon qu'on a pas d'autre argument.
Oui, mais bien sûr, après l'argument d'autorité, voila qu'on prend les gens pour de cons incapables de regarder les besoins.
Ca va convaincre.
J'aurai inversé la rôles plutôt, mais bon quand on veut pas ouvrir les yeux.
on a envie de se lacher vite fait sur un pauvre site web en gros caractères, mais on affiche la couleur direct : on a envie que les autres se fassent chier pour nous, mais nous on a acuune envie de se faire chier.
Résumons donc : argument d'autorité, les autres sont des cons, et on ne veut pas se bouger. Crédible qu'il y aura un fork?
J'adore toujours autant les anti-systemd : ils sont la pour râler qu'on leur modifie leurs petites habitudes de vieux, mais à part ça quand il s'agit de faire autre chose que troller… C'est beau, merci pour le moment sourire.
[^] # Re: J'ai bien ri
Posté par kursus_hc . Évalué à 2.
Et tu as oublié le titre, qui résume plutôt bien la chose :
# Le post de forum
Posté par Misc (site web personnel) . Évalué à 10.
Depuis que j'ai lu qu'une des personnes derrière le mouvement antisystemd est MikeUSA, un mec connu pour avoir harceler pendant longtemps plein de gens, je commence à regarder d'un autre œil les posts.
Et la, ça commence fort niveau allégation. Dire que debian a été fait pour l'utilisateur est faux. Il est dit que la priorité sont les utilisateurs, mais ça ne veut pas dire que l'utilisateur sait ce qu'il veut. Ni qu'il est maitre à bord, loin de la.
Ensuite, la partie sur "le comité est rempli d'anciens de Red Hat er de Canonical" est fausse. Il y a 2 personnes de Canonical et 1 ancien, et c'est tout. Et en relisant les débats, c'est eux qui étaient contre systemd.
Ensuite, l'argument visant à faire croire qu'il s'agit d'une prise de pouvoir militaire comme en égypte est ridicule, car le pouvoir en question a toujours été la. Comparer le fait de bannir les gens avec le fait de se faire tirer dessus est aussi risible.
Mais ce qui me fait le plus tiquer, c'est de faire remarquer que tout est parti en sucette il y a 8 ans quand ils ont virer les gens qui disent du mal des femmes, donc ils sont contre la liberté d'expression ( vous savez, la liberté d'expression qui consiste à harceler les gens sur internet par exemple ).
Sachant que le mec a juste ouvert un compte pour poster ses théories fumeuses, dire qu'il s'agit d'un faux compte est un pas que je franchirais allégrement.
Tout colle, l'obsession a redire encore et toujours les mêmes trucs faux sans la moindre preuve, le fait de se positionner en martyr sur la base de choses non vérifiables, les insultes ( "these people are bastards" suite à son banissement ).
Et bien sur, les bonnes vielles habitudes :
http://www.debianuserforums.org/viewtopic.php?f=63&t=3055&p=29240&sid=55b6af469344f5ee822a9b3ba8404de4#p29237 et http://www.debianuserforums.org/viewtopic.php?f=12&t=3064 )
Mais il y a plein de perles, comme quand le mec tente quand même de dire que c'est pas important de mettre à jour, car y a grsec et pax, et apparmor. Bien sur, personne ne va lui dire qu'une technique de contournement de pax a été publié ( http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf ).
# Et le créateur est ...
Posté par Misc (site web personnel) . Évalué à 10.
Alors, comme je suis un mec curieux, je me suis demandé qui est derriére le fork.
Donc j'ai cherché debianfork ( aprés un coup de whois et co, qui pointe vers dyne.org, une variante Debian pour le multimedia ). Et je suis tombé sur le brouillon du site sur lab.dyne.org :
https://webcache.googleusercontent.com/search?q=cache:ig5xnArsuqwJ:https://lab.dyne.org/DebianFork+&cd=9&hl=fr&ct=clnk&gl=ca&client=firefox-a
qui pointe vers Jaromil comme éditeur. Le même Jaromil qui a un article wikipedia à son nom. Et qui a posté sur twitter au sujet du fork :
https://twitter.com/jaromil
ainsi que divers appels à refuser systemd.
En cherchant un peu, on voit qu'il a une page dédié à purifier les distributions linux :
https://lab.dyne.org/GnuLinuxPurification
Et qu'il a écrit un soft de crypto en shell :
https://www.dyne.org/software/tomb/
https://github.com/dyne/Tomb/blob/master/tomb
Script qui bien sur a un souci avec la gestion de /tmp dans certaines conditions, car il vérifie pas le code de retour de tmp_create, qui pourrait échouer si un autre utilisateur rempli /dev/shm. Y a des chances que ça fasse de la perte de données, et de la merde sans aucun doute.
Et comme il vérifie pas que le fichier existe déjà, comme /dev/shm est en écriture pour tous et comme le script tourne en root, je peux faire un fichier avec le nom prévisible ( vu que c'est pid + random ), et mettre les acl qui vont bien pour le lire, et le script va faire son touch, son chown et tout ça, et je vaix pouvoir choper la clé ( cf https://github.com/dyne/Tomb/blob/master/tomb#L833 ).
Alors on va me dire "faut être vachement rapide pour faire ça", je vais dire que c'est pour ça qu'on a incron. Et surtout si les PID ne sont pas randomisés, je peux juste faire une attaque qui peut statistiquement fonctionner.
Sinon, le script utilise /etc/password pour lister les users, il ne marche donc pas avec ldap ou nis. Il execute aussi directement ce que le fichier tomb lui dit d'executer, ce qui est quand même super comme fonction ( tiens, un fichier chiffré avec les données secrètes, tu peux l'ouvrir, et "oups, ma clé ssh s'est rajouté dans ton trousseau" ). Je suis sur qu'en cherchant aussi de manière créative, on peut injecter des commandes avec dans le script avec un nom de fichier qui prends des metacaractéres.
J'ose croire qu'il y a d'autres VAU avec lui pour faire ce fork, car la, ça me fait quand même doucement rire.
[^] # Re: Et le créateur est ...
Posté par loloemr . Évalué à 1.
Ho la vache, la page GNU Linux purification est juste hallucinante :)
[^] # Re: Et le créateur est ...
Posté par BAud (site web personnel) . Évalué à 2.
moui, le seul truc cohérent est qu'il ait choisi comme licence la WTFPL ;-) (mici \o_ sam< :p)
# Forkons Fedora !
Posté par patrick_g (site web personnel) . Évalué à 10.
Énorme la satire : http://forkfedora.org/
[^] # Re: Forkons Fedora !
Posté par apkwa . Évalué à 7. Dernière modification le 20 octobre 2014 à 19:39.
Marrant :)
Mais je pense cependant que ca illustre parfaitement les 2 points de vue:
La modernisation/simplification, ca me fait penser à (MS|Open|Libre) Office, qui me fait des guillemets français, des apostrophes typographiques (ou je ne sais pas comment ca s'appelle), des espaces insécables, des majuscules, même quand je n'en ai pas besoin ou que simplement je n'en veux pas. Ca m'énerve assez souvent et de temps en temps je lâche un "%$£#& mais je peux écrire ce que je veux ou pas???".
Ca peut se désactiver, mais ca me fait râler quand même (c'est dans ma nature: je suis français).
[^] # Re: Forkons Fedora !
Posté par Zenitram (site web personnel) . Évalué à -2.
Perso, je ne sais pas, autant pour systemd que pour SysV.
Tu démontres le problème principal des "vétérans" : ils ne veulent pas faire l'éffort d'apprendre ce qu'ils ont déjà appris, parce qu'ils savent faire avec le vieux bousin, grâce à l'expérience, et qui trouvent chiant de se retrouver avec un nouveau système où il faut apprendre alors qu'on veut même pas essayer de voir les avantages qu'il va ensuite procurer une fois les premiers pas passés.
Pas de chance, les nouveaux arrivent, et font plus simple, donc celui qui doit apprendre aujourd'hui va apprendre la version la plus simple (non, pas SysV, j'en suis 100% sûr même si je ne connais ce cas précis) et les vétérans experts en vieillerie iront pointer au chômage (ce qui est normal, quand on ne veut pas apprendre la nouvelle syntaxe parce qu'on connait l'ancienne).
Dur dur d'apprendre de nouveau et de se retrouver non plus avec son argument d'autorité (je suis vétéran, je sait un peu plus car j'ai appris par coeur les commandes du vieux bousin à force) mais à se battre contre les jeunes avec ses compétences plutôt ;-).
[^] # Re: Forkons Fedora !
Posté par gnujsa . Évalué à 1.
C'est pas uniquement une syntaxe contre une autre, c'est un langage de programmation (très simple) contre un bête fichier de conf. Après toute la rhétorique ancien vs moderne, c'est … juste de la rhétorique. On s'en fout pas mal d'être ancien ou moderne, tant qu'on ne perd pas en fonctionnalité et/ou qu'on en gagne. Pour cet exemple, on gagne certainement en clarté de configuration, mais on perd la possibilité modifier facilement le fonctionnement.
[^] # Re: Forkons Fedora !
Posté par Misc (site web personnel) . Évalué à 10.
C'est en effet un souci d'industrialisation. C'est à dire que systemd va mutualiser et industrialiser le processus métier.
Mine de rien, c'est comme passer de sendmail et son language de macro m4 ( on m'a parlé de faire une calculatrice avec ) à postfix, qui est purement déclaratif.
Au début, dans une phase d'innovation, on sait pas exactement ce qu'on veut, ça part dans tout les sens. Et puis avec le temps, on a une idée plus précise, et on repart de la.
Tu regardes l'histoire des outils de gestions de configuration ( cfengine, puppet, etc ), ça commence par des scripts shells. Puis on a passe à des outils de configurations à base de declaration ( puppet, cfengine ), il y a des gens qui veulent revenir à des scripts ( chef, le ruby DSL de puppet, ), mais les nouveaux partent par défaut vers du déclaratif avant tout ( salt, ansible ), avec le scripting en possibilité mais pas vraiment par défaut.
Et systemd se place à ce niveau. Tu peux faire des scripts shells si tu veux, mais le défaut va vers l'industrialisation.
[^] # Re: Forkons Fedora !
Posté par Zenitram (site web personnel) . Évalué à -2.
Tout à fait.
J'ai l'impression que le clash arrive car d'un côté des gens veulent travailler (être productif) avec Linux, et de l'autre des gens veulent être payés pour jouer avec Linux, et pour ces derniers la fête est finie (les entreprises n'avaient pas le choix avant, elles devaient payer ceux qui voulaient jouer car c'était les seuls) mais maintenant elle a le choix et donc elle choisit l'industrialisation du processus métier.
Comme à chaque fois, on voit surtout le mécanisme de rente : ceux qui ont la rente (ici, leur connaissance des bizaretés du shell pour un init) ne veulent pas la perdre, alors que les nouveaux souhaitent avancer.
[^] # Re: Forkons Fedora !
Posté par Michaël (site web personnel) . Évalué à 4.
Un peu comme sous FreeBSD, quoi: les scripts d'init sont essentiellement déclaratifs, mais cela reste des scripts shells, qui sont donc facile à aménager comme on veut.
[^] # Re: Forkons Fedora !
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 21 octobre 2014 à 08:12.
Je vais te révéler un secret : avec systemd, tu peux lancer un… Script shell, qui sont donc facile à aménager comme on veut.
(ça ne doit pas être la première fois que tu lis cette information, surtout que la personne à laquelle tu réponds te l'a déjà dit mais pas assez directement il faut croire, qu'en conclure sur la personne qui ressort une n-ième fois cet "inconvénient" de systemd?)
[^] # Re: Forkons Fedora !
Posté par Michaël (site web personnel) . Évalué à 4.
Sympa. Qu'est-ce qui est faux dans ma déclaration factuelle? Tu semble répondre à une déclaration “systemd c'est caca” que je n'ai pas écrite.
[^] # Re: Forkons Fedora !
Posté par Zenitram (site web personnel) . Évalué à -6. Dernière modification le 21 octobre 2014 à 08:32.
Oui, factuellement c'est trop propre, le but n'est pas de faire déduire que systemd est moins bien, non, pas du tout, "qui sont donc facile à aménager comme on veut" est écrit gratuitement, sans sous-entendre "l'autre c'est moins bien", pas du tout.
Mais bien sûr…
mais cela reste des scripts shells, qui sont donc écrit par des humains. Voila, j'ai mis une autre phrase, aussi peu utile. On peut remplir avec plein de trucs inutile, ou ne pas mettre, si il n'y a aucun sous-entendu.
Dit-moi donc pourquoi tu as écrit "qui sont donc facile à aménager comme on veut".
PS : pour info, je trouve "facile à aménager comme on veut" comme un inconvénient, car ce n'est pas à cet endroit que le processus metier devrait permettre des hacks. Il faut cloisonner pour pouvoir industrialiser, gérer proprement. Merci pour l'aide à flinguer ce principe.
[^] # Re: Forkons Fedora !
Posté par Michaël (site web personnel) . Évalué à 3.
C'est écrit factuellement, pas gratuitement.
Ben oui.
Parceque c'est vrai et que la personne qui écrit présente un élément comme un avantage systemd sur sysv qui n'en est pas un, les avantages sont ailleurs.
[^] # Re: Forkons Fedora !
Posté par barmic . Évalué à 10.
T'y va fort sur les procès d'intention. Donc à chaque fois que tu dis que systemd c'est bien tu es d'accord pour que toute la communauté BSD te tombe sur le coin de la gueule parce que si tu dis que systemd c'est bien c'est que tout le reste c'est de la merde ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Forkons Fedora !
Posté par Michaël (site web personnel) . Évalué à 3.
Un peu oui! Pour détendre l'atmosphère, souvenons-nous de ce sketch des Monthy Pythons!.
[^] # Re: Forkons Fedora !
Posté par Misc (site web personnel) . Évalué à 6.
Alors, j'ai pris un script au hasard :
https://svnweb.freebsd.org/ports/head/irc/ircd-hybrid/files/ircd-hybrid.in?revision=340872&view=markup
C'est en effet un chouia plus déclaratif, mais ça reste du shell. C'est un pas en avant par rapport à ce qu'on trouve sur linux, sans aucun doute, mais pld le faisait aussi.
Mais ça n'est pas du 100% déclaratif, ce qui fait qu'il manque 2 points importants :
- la possibilité de faire de l'analyse statique. Ce que je veux dire par la, c'est d'automatiser la lecture du fichier, et son analyse vis à vis d'un jeu de regle. C'est un mécanisme de QA, et je pense que ça aide aussi pour des audits de configurations. Je reconnais que c'est un souci purement de distributeur.
Et dans le cas de systemd, le fait d'avoir un language purement déclaratif permet de rajouter par dessus du templating. Chose qui serait faisable en bash aussi à priori, modulo le fait que bash fait deja ça, et que ça serait à mon sens moins élégant.
mais tu n'as pas les avantages d'un format qu'on peut parser. Et a reste du shell, ce qui fait que tu peux pas faire proprement le trick
[^] # Re: Forkons Fedora !
Posté par Michaël (site web personnel) . Évalué à 2.
Ça montre en effet assez bien qu'on peut utiliser le shell pour l'init sans manger des tartines comme celles que montre http://forkfedora.org/.
Ben oui, forcément! ☺
C'est peut-être plus facile de faire ce genre d'analyse avec le fichiers de systemd mais a priori rien n'empêche de faire ce genre d'analyse. Cela demande d'imposer des conditions de forme sur les scripts d'inits, mais si c'est un objectif du projet rien n'interdit de l'implémenter. Un exemple de cette approche est la commande
portlint(1)qui analyse les Makefile des ports pour faire de la QA — probablement très élémentaire.Effectivement. L'approche typique serait probablement de dupliquer et éditer le fichier.
[^] # Re: Forkons Fedora !
Posté par Misc (site web personnel) . Évalué à 10.
Je pense que j'ai pas besoin d'expliquer en quoi la syntaxe de bash est complexe, ni en quoi le fait de faire un parser parfait est quasiment impossible, vu que personne ou presque ne connait les centaines de subtilités.
Donc le souci, si tu rajoutes un DSL en shell, c'est plus du shell. Et ça va bloquer les gens qui vont confondre les 2 syntaxes.
Mais comme j'avais pas envie de faire un paté sans fin, j'ai pas tout mis, et le véritable souci d'utiliser le shell, c'est que tu peux pas avoir le même niveau de fonctionnalité que systemd en matiére de configuration.
Et je dit pas ça parce qu'il y a pas des outils en CLI pour faire ça, car je suis sur globalement que ça peut s'écrire. Tu peux faire un chroot, un su, un changement de group, etc.
Je dit ça parce qu'il y a des endroits ou c'est juste impossible par design du shell lui même, et j'ai pigé ça y a moins de 2 semaines.
Exemple personnel. Pour rajouter ma pierre à l'édifice de la discussion du TC Debian il y a un an, j'ai codé le support de AppArmor dans systemd ( l'idée étant de réduire la différence entre systemd et upstart, mais y a que systemd ou j'ai réussi à produire du code upstreamable ).
La fonctionnalité est de pouvoir dire "tel service est lancé avec tel profile". Je teste sur une opensuse, ça marche, j'envoie, c'est mergé debut janvier. Il se trouve que je croise les gens de Tails en avril, qui sont en effet intéressé par la feature, et qui après l'intégration de systemd, testent et trouvent que ça ne marche pas en octobre ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760526 ).
Il se trouve que par hasard à la recherche de bug à corriger, je passe sur le BTS de Debian, et déjà, je vois que j'ai un premier bug sur le message d'erreur de mon code que je corrige ( envoie, merge, dans la journée ). À partir de la, j'arrive à piger que j'ai un 2eme bug.
Le bug est que pour changer de profile apparmor, tu dois écrire dans /proc/self/attr ( http://wiki.apparmor.net/index.php/Kernel_interfaces ). Tu peux changer le profile du processus courant, ou du prochain processus exécuté. Le déclencheur du bug est que le service tor du projet tails est blindé, et notamment, l'accés à /proc est restreint pour tor via systemd. Et si tu fait disparaitre /proc avant de tenter de changer de profile, ça ne marche pas, ce qui est le cas dans mon code. D'abord, systemd restreint les namespaces, ensuite, il fait la demande de changement de profil pour le prochain processus ( exec_child dans src/core/execute.c ).
Donc la solution est d'écrire dans /proc en demandant de changer le profil du prochain process , puis de faire des montages spéciaux avec les namespaces. Changer le processus courant bloque les changements avec les namespaces, et faire les changements avec les namespaces bloque le changement de contexte apparmor.
Systemd est en en C, et ça marche parce que systemd ne fait pas de fork sauf pour lancer le service.
En shell, ça ne peux pas marcher dans l'état, car tout est un fork.
Si je commence par faire le echo kivabien dans /proc pour apparmor, ça va s'appliquer au prochain processus, qui va être le processus nsenter qui va changer les namespaces, et qui va sans doute être bloqué en fonction de la politique apparmor.
Et si je rentre dans un namespace d'abord, puis que je fait l'écriture vers /proc, je peux pas car mon namespace peut supprimer /proc.
Conclusion, ça ne marche pas, et c'est à mon sens impossible de faire marcher ça, sauf à changer apparmor pour avoir un autre mécanisme de communication qui marche sans /proc.
Et même la, le mécanisme devra marcher dans un environnement très restrictif ( genre avec des syscalls désactivés, etc ).
Le fait de dire "fait le changement pour le prochain executable" est très élégant car tu peux empiler les restrictions sans que ça se marche sur les pieds, ça ne s’appliquera qu'à ton fils, le processus à lancer.
Mais en shell, tu n'as pas de séparation logique donc tu ne peux pas avoir ça.
Alors mon exemple est ultra particulier. J'ai relu le reste du code et globalement, y a rien qui ne me saute aux yeux pour dire "y a pas que apparmor" ( enfin y a le choix du contexte selinux, mais le souci est une variation de apparmor, qui souffre du même bug comme je viens de le voir, et qui a été aussi écrit par moi (j'ai un peu honte)).
Le coeur du souci est en effet d'appliquer des restrictions capables de se bloquer les unes et les autres, et les appliquer dans un ordre convenable. Sauf que comme il y a une boucle, le seul moyen est de briser la boucle en séparant l'application de la restriction de sa déclaration en appliquant à un événement dans le futur. Le fait d'appliquer "on exec" est exactement ça.
Alors une solution serait de modifier le protocole de communication pour prendre un argument en plus, le chemin de l’exécutable à confiner en plus du profile/domaine/etc.
Mais il y a des corners cases et des choses non intuitives ( genre si je veut restreindre python et qu'un des programmes pour restreindre est écrit aussi en python, ou justement, si je veux restreindre un script en python, il faut que je dise que c'est python que je veux restreindre car c'est ce que le kernel va voir, etc ).
Donc parce que des APIs et le kernel est pas vraiment toujours shell friendly, un systéme d'init qui se base sur le shell autant que possible ne va pas avoir le même niveau de fonctionnalités.
Bien sur, une solution alternative serait sans doute d'avoir juste un gros binaire comme start-stop-daemon qui prends des tas d'options, voir des variables d'environement. On en reviens du coup à la critique "je ne peux pas comprendre ce qui se passe dans le script", vu que ça devient juste "je déclare des vars et je lance un binaire magique qui fait tout". Je ne doute pas qu'on râle au manque d'esprit unix de la chose :)
[^] # Re: Forkons Fedora !
Posté par barmic . Évalué à 3.
C'est ce que je remarque de plus en plus. Pour tous ce qui est passé tôt au déclaratif est entrain non pas de revenir mais de s'assouplir (ant -> maven -> gradle).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Forkons Fedora !
Posté par Almin (site web personnel) . Évalué à 2.
Analogie bien trouvée, et comme je suis fan de postfix tu viens de me convaincre de passer à systemd quand jessie sortira. Bon ceci dit, au début j’étais aussi convaincu par pulseaudio, mais j’avais déchanté à l’usage ;)
[^] # Re: Forkons Fedora !
Posté par barmic . Évalué à 7.
Il gérait pas bien ton micro ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Forkons Fedora !
Posté par xcomcmdr . Évalué à 4.
J'en doute :
- systemd a de nouvelles options de config pour les Unit files assez souvent au fil des versions… Le "smart reload" m'a l'air d'être un besoin assez banale…
- tu peux toujours utiliser les scripts…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Forkons Fedora !
Posté par xcomcmdr . Évalué à 7.
HA !
Je trouve le C plus simple que le shell. Au moins je m'embête pas quand je veux faire des comparaisons entre des variables numériques. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Forkons Fedora !
Posté par Antoine . Évalué à 8.
Par contre tu t'embêtes quand tu veux faire des comparaisons entre des chaînes de caractères :-)
[^] # Re: Forkons Fedora !
Posté par freem . Évalué à 2.
Ma foi, j'aurai plutôt parlé de regex à ta place. Pour comparer des chaînes de caractères c'est assez simple dans tous les langages (bon, certes, il faut appeler explicitement une fonction quand les langages sont pas objets). La ou shell dépote, c'est pour appeler des programmes et filtrer le texte.
[^] # Re: Forkons Fedora !
Posté par Padishah . Évalué à 3.
Donc ton avis n'est pas des plus pertinent, car dans tous les cas tu ne perds/gagnes rien.
Dans l'exemple Sendmail, l'unité Systemd va lancer 3 commandes :
/etc/mail/make
/etc/mail/make aliases
/usr/sbin/sendmail -bd $SENDMAIL_OPTS $SENDMAIL_OPTARG
C'est quoi le code dans les 2 make ?
[^] # Re: Forkons Fedora !
Posté par claudex . Évalué à 8.
Soit tu as la science infuse, soit tu pars du principe que tu connais bien l'init de Fedora. Mais alors, c'est complètement biaisé. Parce que des lignes comme
Ça me semble loin d'être clair de deviner ce qu'elle fait.
« 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: Forkons Fedora !
Posté par gnujsa . Évalué à -3.
Oui, mais les 2 mis côte à côte ne sont pas rigoureusement équivalent. Le premier comporte, la logique, du moins en partie, alors que le second ne comporte que des définitions. Il aurait fallut mettre le code C qui s'occupe du second à côté. Et pas sûr que systemd reste toujours aussi simple à lire/modifier.
J'ai bidouillé des tonnes de fois des scripts d'init, mais n'étant pas développeur, c'est juste quelque chose qui va m'échapper maintenant avec systemd.
[^] # Re: Forkons Fedora !
Posté par Anonyme . Évalué à 4.
Il n'y a aucune raison d'aller lire/modifier le code de systemd dans le cas d'une utilisation normale, pas plus que tu vas aller lire/modifier le code C de ton shell pour faire fonctionner un script d'init.
[^] # Re: Forkons Fedora !
Posté par freem . Évalué à 3.
Dans son cas, j'ai l'impression qu'il ne parle pas du source de l'init, mais des modules que l'init utilise. Dans le cas de systemd, ces modules sont écrits en C, donc compilés, donc pas directement modifiables.
Dans le cas de sysV, ils sont écrits en… euhh… ça dépend de la configuration j'imagine (c'est vrai d'abord, je me demande si, quelqu'un d'original ne pourrait pas utiliser un autre langage au final?), mais traditionnellement en shell, qui n'est pas compilé (jusqu'à preuve du contraire), et donc dont le source est accessible.
De là à qualifier le shell de plus lisible que du C, je ne m'aventurerai pas, mais je suis biaisé.
[^] # Re: Forkons Fedora !
Posté par Anonyme . Évalué à 1.
Peu importe de quelle partie de l'init il parle, il n'y a pas besoin d'aller lire ou modifier le code de systemd pour une utilisation normale.
L'equivalent de ce qui est fait dans les scripts d'init est ecrit en C, mais on s'en fou, il n'y a pas besoin d'aller le lire / modifier.
Donc aucune raison de l'inclure dans la comparaison.
[^] # Re: Forkons Fedora !
Posté par xcomcmdr . Évalué à 3.
Bientôt partout : linux et SysV en shell script.
Ça va dépoter !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Forkons Fedora !
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Ben non justement, l’avantage de systemd sur sysv c’est qu’avec systemd on n’a pas besoin de programmer, il suffit de déclarer, et dans sysv on ne peut rien déclarer sans programmer.
La comparaison ne porte pas sur le nombre de ligne de code que pond le développeur, mais le nombre de ligne de code que pond l’administrateur.
Et même si systemd ne faisait pas que du déclaratif, ton argument reviendrait à répondre à quelqu’un qui code en Python et qui déclare qu’il apprécie ne pas se prendre la tête avec des pointeurs : « mais pas du tout, ton interpréteur python il fait plein de pointeurs, tu dois systématiquement lire le code de CPython à chaque fois que tu écris une ligne en Python, sinon t’es pas un vrai homme qui en a ».
Bref, j’aime bien le shell, je ne suis pas très fan de cette mode qui déplace le savoir faire de chez l’utilisateur vers le développeur, mais il ne faut pas se tromper d’argument.
Les vrais hommes assemblent eux-même leur code de tête, sauf quand ils sont payés uniquement pour déclarer.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Forkons Fedora !
Posté par gnujsa . Évalué à 1.
Et bien ça n'est pas très clair que la comparaison ne concerne que les admins sys. Et dans le cadre de cette dépêche, un fork de Debian, un système qui se veut universel, il y a pas mal d'utilisateurs qui modifient leurs scripts d'init, ou en rajoutent d'autres sans même parfois tout bien comprendre. (c'est un des intérêts du shell que de pouvoir pratiquer rapidement en ne connaissant qu'un sous-ensemble du langage). Alors quand on a le code sous les yeux, la logique même du script, c'est un gros avantage. Il n'est bien sûr a ce niveau pas question de forker systemd. Alors dans ces cas là, on utilisera des programmes tout prêt, ou on ne fera pas (il y a apparemment moyen de faire fonctionner des script shell sous systemd ce qui amoindrit pas mal ce problème).
Ce que je voulais dire, c'est qu'il est normal et logique d'avoir plus de lignes lorsque l'on a le programme ET sa configuration réunis, que lorsque l'on a uniquement le fichier de configuration. Si maintenant il s'agit de montrer que la config est plus simple, alors ce n'est pas tout à fait honnête, car on peut faire la même chose en shell (sourcer un fichier de config, c'est en partie le cas, mais là on nous montre aussi les entrailles du script).
Je prend juste un exemple:
script shell:
if [ -f /etc/sysconfig/sendmail ] ; then
. /etc/sysconfig/sendmail
else
DAEMON=no
QUEUE=1h
fi
unit systemd:
[Service]
EnvironmentFile=-/etc/sysconfig/sendmail
Maintenant, rien n’empêche (et assez facilement) d'avoir :
script shell:
# Source global config "unit-like"
if [ -f ./etc/rc.d/init.d/conf/sendmail.unit ] ; then
. /etc/rc.d/init.d/conf/sendmail.unit
fi
…
et dans /etc/rc.d/init.d/conf/sendmail.unit, quelque chose de similaire au fichier de config de systemd, c'est à dire, une dizaine de variable. Et dans ce cas pour le sysadmin, ça ne changera pas grand chose.
Donc l'argument de la clarté, je le trouve un peu léger, et pas très fairplay. Tant qu'a montrer la logique, l’algorithmie, du script shell, autant montrer aussi celle équivalente dans systemd pour voir si elle est aussi compréhensible et facile à modifier (et oui, Debian n'est pas fait que pour les sysadmin allergiques aux scripts shell, et sans même être un gros bidouilleur, on peut vouloir modifier quelques trucs et comprendre).
[^] # Re: Forkons Fedora !
Posté par barmic . Évalué à 7.
Je ne connais pas de sysadmin (unix/linux) allergiques aux script shell.
Mais il n'y a pas à gérer la logique de démarrage des services ! C'est pas un truc que l'on modifie, c'est quelque chose que l'on configure ! Chercher à refaire 15 milliards de fois cette même logique (bancale) n'a pas le moindre intérêt pour personne. L'utilisateur Debian (qu'il soit "admin", "développeur" ou agriculteur), il copiait le fichier
/etc/init.d/skeletonet il modifiait le minimum possible et lançait une incantation vaudou (du genre un bon gros copier-coller deupdate-rc.d nom_script start 14 S . stop 12 0 6 .).Il faut bien comprendre une chose : modifier la manière de démarrer un deamon c'est mal. C'était mal avant systemd, c'est mal sur les OS non linux, ce seras mal quand on utilisera plus systemd. C'est la porte ouverte aux bugs les plus tordus, à la maintenance complexe, etc.
C'est toujours possible mais c'est très vivement déconseillé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Forkons Fedora !
Posté par Anonyme . Évalué à 6.
Si tous les services étaient fait comme ca, en utilisant tous les memes variables documentées, oui. Mais c'est pas le cas, chaque script d'init est implémenté de facon differente.
Non par ce que les 2 n'ont rien à voir.
Le code de systemd est generique et permet de gérer tous les cas de démarrage d'un service. Il n'y a aucune raison d'aller modifier ce code ou le lire, à moins d'etre developeur de systemd. Et si on veut savoir ce que fait une option, il y a de la doc pour ca.
Dans le cas des scripts init, ce n'est pas du code generique mais spécifique au service, que l'on est obligé de lire si l'on veut savoir comment est démarré le service.
[^] # Re: Forkons Fedora !
Posté par Psychofox (Mastodon) . Évalué à 10.
Par lire la doc peut-être ?
Il n'y avait pas un acronyme souvent utilisé par les "vétérans" unix/linux…ça ne me revient plus.
[^] # Re: Forkons Fedora !
Posté par apkwa . Évalué à 3.
Bah, je ne suis pas un vétéran et je n'ai jamais aimé ces "RTFM" (c'est bien sympa, mais quand on ne sait même pas que la commande existe, ca nous avance bien…).
Ce n'était pas une vraie question, mais puisque tu en parles, je crois justement que ce n'est pas possible de faire ca. Pour certains cas, on peut jouer avec le "@" et le "%i" qui permet d'une certaine façon le passage d'un paramètre lors de l'appel du script, mais ce n'est pas possible de faire autre chose que les start/stop/reload/… prévus.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.