Sommaire
plop,
Pour commencer à préparer la progression vers vendredi en douceur, j'ai traduit ce post de Leszek Urbanski sur systemd, qui dissertait en mai 2011 en les problèmes qu'il peut poser sur serveurs. Posté en ces lieux avec l'aimable autorisation de l'auteur (de l'article, par la suite le mot auteur, au sein de la traduction, désignera l'auteur de systemd).
C'est parti :
Le sophisme systemd
(…) So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It’s quite relieving!
– Lennart Poettering @ fosdem.org
systemd est erroné sur tellement de points que je ne sais pas par où commencer. Son erreur de conception la plus importante est peut-être qu’il a été conçu avec un mépris flagrant pour les serveurs. Le manifeste de l’auteur ainsi que la série « systemd pour les admins » fournissent un bon aperçu de ses motivations pour la conception de systemd.
Il s’étend encore et encore sur la façon dont vous pouvez gagner quelques secondes ici et là par le démarrage des services en parallèle et en différé - systemd a d’ailleurs une fonction permettant de mesurer le temps de démarrage du système. La question est : qui s'en soucie ? Les utilisateurs de bureau, oui. Les utilisateurs d’embarqué, peut-être. Les utilisateurs de serveurs ? Non. Il importe peu qu’un serveur démarre en 96,3 secondes au lieu de 33,1. Ce qui compte c’est qu’il reste en fonctionnement et qu’il ne soit pas trop lourd à maintenir.
Alors, comment sont atteints les objectifs de systemd ? Simplement, en jetant les paradigmes bien éprouvés d’Unix par la fenêtre et en le revendiquant clairement. Oui, Unix a été conçu il y a 42 ans. Et non, il n’est pas cassé. Je ne suis pas un traditionaliste pur et dur et je ne suis même pas réticent à adopter de nouvelles solutions, mais Unix reste la conception d’OS pour serveur ayant le plus de succès au monde pour une raison – et est encore utilisé aujourd'hui sous des formes diverses, après ces 42 ans. C'est simple, élégant et ça marche. Le pilier de sa conception, c'est la simplicité et la modularité. Un programme pour une tâche ; une interconnexion facile entre les programmes. Et pourtant il faudrait que nous jetions tout cela pour quelque chose de neuf et qui brille.
Un des objectifs de conception de systemd est de se débarrasser de scripts shell dans le processus de démarrage et … de tout réécrire en C, vu que l'auteur ne semble pas être très friand que grep soit appelé 77 fois et awk 92 lors de son initialisation du système. Mais pourquoi avons-nous des scripts shell dans le processus de démarrage ? Ils sont simples. Ils sont faciles à lire. Tout admin Un*x un tant soit peu compétent connait au moins les bases du scripting shell. Cela permet un contrôle pratiquement total du processus de démarrage complet et n’importe quoi peut être changé en quelques secondes. Bien sûr, on peut affirmer que c'est presque aussi facile de changer le code C de systemd, recompiler et réinstaller. Je vais vous confier un petit secret : quand avez-vous typiquement besoin de changer quelque chose dans le processus de démarrage ? Quand quelque chose fonctionne mal. Peu importe que vous soyez confortablement installé à votre bureau devant 3 écrans 30" ou dans les tranchées au data center après une nuit horrible – vous devez corriger le problème au plus vite. La dernière chose que vous voulez et d’avoir à instrumenter, débugger, et reconstruire du code C au cœur de votre OS.
Le second objectif de conception semble être une complexité intentionnelle incroyable et injustifiée. Le processus le plus important dans l’espace utilisateur est censé être propre, petit et efficace. Jetons un coup d'œil à ce que systemd est censé superviser :
le redémarrage des processus après leur crash. sysvinit ne le fait pas et nous n'avons pas restartd ou mille autres programmes pour cela !
la collecte d'informations sur les plantages des démons. Aujourd'hui la plupart des démons possèdent leurs propres formats de rapport de crash, syslog, stderr, directement dans les fichiers journaux au format texte, des dumps binaires, etc. Bonne chance pour imposer aux auteurs de se conformer à une norme unique. Et bonne chance pour tous les cas aux limites.
garder le contrôle (par l'intermédiaire cgroups) sur les processus détachés de leurs parents. Mais pour cela nous avons déjà, … cgroups ?
démarrage du service à la demande / retardé (NDT : l’inspiration c’est services.msc ?). « Sur la plupart des machines où sshd peut être à l’écoute quelqu’un s’y connecte genre tous les deux mois » déclare l’auteur. Sur un poste de travail – peut-être. Combien de RAM allez-vous économiser en retardant le démarrage de quelques démons ? S’ils sont inutilisés, ils vont être swappés de toute façon. Afin de pourvoir à la demande de démarrage des services réseau, encore une autre fonctionnalité déjà disponible ailleurs a dû être mise en œuvre dans systemd : inetd.
la gestion des dépendances entre services. Pour l'auteur, il y a de la redondance dans la gestion des dépendances entre services. Le problème est que tout processus de démarrage est basé sur des dépendances. Pensez aux services et non aux processus. Vos services dépendent de ce que leurs systèmes de fichiers aient été montés, les systèmes de fichiers dépendent de l’initialisation des périphériques sous-jacents, et ainsi de suite. Nous avions déjà une gestion rudimentaire des dépendances entre services dans System V ! S31fancyd et S31foobar dépendait de S30whatsit. Lors de l’arrêt, seulement lorsque K10foobar et K10fancyd étaient arrêtés le système pouvait procéder à K20whatsit. Contrairement aux ordinateurs de bureau, le temps de démarrage des serveurs se mesure entre le moment ou vous appuyez sur le gros bouton rouge et le moment où le serveur fournit réellement tous ses services. En d’autres termes, lorsque vous attendez, qui se soucie si c’est en parallèle ou en série ? Il importe peu si par exemple ftpd est autorisé à démarrer avant que /home/ftp ne soit monté et que des fichiers puissent être servis. En outre, un administrateur peut choisir de stopper S30whatsit sans stopper S31 fancyd – et il ou elle sait probablement ce qu’ils fabriquent. Il est plus difficile de forcer des actions sur les services avec systemd : on finit toujours par se battre contre ses décisions.
systemd crée des points de montage autofs et démarre des démons avant que leurs systèmes de fichiers ne soient disponibles (évidemment, les opérations de fs vont de bloquer jusque-là). Cela semble horrible, non ? Cela va être un cauchemar d’administration. Il n'y a pas moyen de faire de l’autofs correctement. Si quelque chose va mal avec l’ES sous-jacent ou autofs proprement dit, vous vous retrouvez avec un système inutilisable. Même sous Solaris, qui a sans doute la mise en œuvre la plus robuste d’une implémentation d’automounter. Intégrer autofs dans le PID 1 et le processus de démarrage (et mettre les services en attente là-dessus) garantit des problèmes.
l'écoute de modifications sur le matériel introduit des problèmes potentiels de stabilité et de sécurité – et il y a déjà des choses qui fonctionnent (plus ou moins) avec les événements matériels.
la communication via D-Bus. D-Bus est très orienté bureautique. Il ne s'appelle pas « bus de bureau » (NDT : Desktop Bus) pour rien. Il est conçu pour la portabilité - et non la vitesse, la fiabilité ou la simplicité. Il existe des dizaines de protocole d’IPC et de passage de messages simples et robustes, mais D-Bus est de loin l’un des plus compliqués, peut-être uniquement après CORBA/IIOP. Au lieu de laisser cette abomination mourir, ou du moins la laisser confinée au bureau, D-Bus va être intégré au processus de démarrage. Les développeurs de démons sont incités à l’utiliser. Mettons le dans le noyau tant qu’on y est.
systemd est trop compliqué et farci de fonctionnalités inutiles, presque comme si quelqu'un essayait de mettre en œuvre un second noyau en espace utilisateur. On dirait qu'il a été conçu par quelqu'un qui n'a jamais vu autre chose que son propre poste de travail. C'est un exercice gentil dans les systèmes d’autogestion, avec son approche fourre-tout ça mérite sans doute d’y jeter un œil pour les fournisseurs de bureautique/embarqué en tant qu’alternative à SystemV ou à un système d’initialisation fait maison, mais c’est tout.
Le processus de démarrage de l’espace utilisateur de Linux devrait être passé en revue et nettoyé dans la plupart des distributions importantes, et peut-être même être normalisé (ou non – nous avons actuellement quatre système de démarrage majeurs pour l’espace utilisateur, tous dans des distributions majeures – un peu de diversité est en réalité bienvenue).
Toutefois, systemd n'est pas la voie à suivre. Il nous ferait reculer d’une décennie. Espérons que cela n'accroche pas - tout comme upstart ou la première mise en œuvre de devfs en 2000. Il n'est guère surprenant de voir combien les gens sont près à suivre aveuglement - systemd offre beaucoup de belles promesses. Avec le soutien financier de Red Hat et toute la propagande (je n'ose même pas appeler cela de la Relation Publique), cela va être un combat ardu, mais rappelez-vous: après tout, upstart a intégré Ubuntu; devfs est même entré dans le noyau. Tout espoir n'est pas perdu.
# Ca rassure de voir qu'il y a encore des gens censés sur terre.
Posté par totof2000 . Évalué à -2.
[^] # Re: Ca rassure de voir qu'il y a encore des gens censés sur terre.
Posté par BAud (site web personnel) . Évalué à 10.
censés quoi ?
être sensés ?
# Cloud fail
Posté par inico (site web personnel) . Évalué à 8.
Sauf si tu laisse des serveurs éteind pour faire des économies et que tu ne les allumes que s'il y a une montée en charge.
Les firmwares des différents contrôleurs prennent un temps monstrueux à démarrer donc tu as besoin que ton OS soit disponible le plus rapidement possible.
90s vs 30s, cela fait 1 minutes de ralentissement parce que ton init est en attente séquentielle et cela fait un certain nombre d'utiliseur qui voit ton service ramer.
Même remarque pour les mise à jours ayant besoin d'un reboot.
Conclusion: même sur un serveur, le temps de boot est important.
[^] # Re: Cloud fail
Posté par Larry Cow . Évalué à 10.
Important oui, mais pas forcément à n'importe quel prix. Je pense que c'était ça, le message.
[^] # Re: Cloud fail
Posté par Zenitram (site web personnel) . Évalué à -10.
Je croyais que Linux était libre?
C'est suffisamment important pour les mainteneurs des distros qui l'ont implémenté, si tu n'est pas content pourquoi ne pas monter une autre distro pour prouver que les gens ont besoin d'une distro sans systemd?
Bizarre, on n'arrête pas de me dire que l'avantage de Linux est que les gens peuvent faire ce qu'ils veulent et que l'éco-système sélectionnera tout seul, et quand les gens font ce qu'ils veulent, on leur tombe dessus pour dire que c'est mal.
Assez incohérent.
Ce n'est pas ici qu'il faut débattre de mettre systemd dans telle ou telle distro, mais sur les forums officiels de chaque ditro. C'est un choix des distros.
[^] # Re: Cloud fail
Posté par Jux (site web personnel) . Évalué à 10.
En même temps il y a des gens qui bossent sur des distros qui passent sur Linuxfr donc c'est un endroit valable pour discuter systemd.
Gni ? Donc on a plus le droit de débattre de tel ou tel changement dans une distribution ? L'avantage de l'écosystème libre, c'est qu'on pourra toujours virer systemd si on est pas content. Ca n'empêche pas d'essayer de convaincre les distros qu'on utilise de ne pas l'utiliser. Ca nous évitera de devoir faire un fork sans systemd. (Je suis pas spécialement pour ou contre, mais je trouve le débat intéressant)
[^] # Re: Cloud fail
Posté par B16F4RV4RD1N . Évalué à 9.
si si, justement, ici il y a beaucoup de gens qui utilisent beaucoup de distributions différentes (au fait, c'est quand que tu t'y mets ? Même sans systemd, les distributions Linux sont très agréables à utiliser, on peut faire beaucoup de choses avec, surf internet, graphisme, vidéo, musique…). De ce fait, si le maximum de personnes peut se rendre compte que ce gars est fou à lier, si des distributions ont l'idée saugrenu d'implémenter ses trucs, il pourra y avoir plus de voix contre.
Ou peut-être que Lennart est un agent de microsoft qui a fait un pari avec un collègue sur le thème de « est-ce que les distributions seront assez bêtes pour rajouter ça de base ? » (le collègue, c'est celui qui a réussi à mettre grub2)
Sinon l'article est intéressant, la seule réserve que j'aurais c'est :
non, l'utilisateur de bureau souhaite que son ordinateur, une fois arrêté, retourne sur sa session de travail en cours le plus rapidement possible. Entre 15" de boot avec systemd + 40" pour rouvrir le terminal sur le chemin de travail en cours puis ouvrir l'explorateur de fichiers puis ouvrir le logiciel d'email, je préfère sortir mon ordinateur de veille (5") et revenir sur mon travail en cours.
Systemd est une fausse solution pour un problème qui n'existe pas, et qui a la rigueur posera plus de soucis en cas d'urgence. Évidemment, s'il y a des distributions qui trouvent ça cool et travaillent à ça (ça fait peur quand on voit la liste, fedora, mageia, opensuse), grand bien leur fasse, mais je serais utilisateur, j'aurais un peu peur de voir ça, alors qu'il y a d'autres priorités…
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Cloud fail
Posté par Misc (site web personnel) . Évalué à 10.
Personnellement, je pense que les scripts bash qui servent de fichier init avec des gros morceaux de copier coller sont un problème. Et le manque de maniabilités et de standardisation ( quand on compare à tout ce qu'on peut régler de façon unifié sur systemd ) est aussi un problème. Rien que pour ça, je suis content d'utiliser des distros avec systemd.
Et le simple fait que tout le monde se focalise sur l'histoire de la vitesse de boot prouve bien que les gens ne se posent même pas la question du reste. Oui, les systèmes de boot actuelles font leur job depuis des années, mais c'est en aucun cas une preuve qu'ils sont parfait. Les gens acceptent le status quo et la médiocrité sans chercher à améliorer l'existant. Les équipes de Apple ont vu les problèmes => ils ont mis au point launchd. Les devs de Gentoo ont vu les problèmes, ils ont refait le système d'init .Les ingés d'Ubuntu ont vu les problèmes, ils ont fait upstart. Même debian qui propose des systèmes de boot alternatifs ( comme runit, par exemple ).
Et franchement, on voit bien que tu développes pas une distribution, sinon, tu saurais que les gens sont libres de bosser sur ce qu'ils veulent. Et si tu estimes qu'il y a d'autres priorités, c'est ton droit, mais c'est aussi le droit des autres, ceux qui font le boulot. Donc si tu penses qu'un truc est plus urgent, faut bosser dessus si tu veux que ça arrive.
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 7.
Idem, le fait de virer SysV pour systemd ne me gène pas plus que cela, je ne vois vraiment pas ce que cela va changer…
L'exemple du "je peux modifier mon script shell" est le pire de tous, quand tu as besoin de faire cela, c'est justement parce que ce script shell a été codé avec les pieds, qu'il utilise des trucs qui ne sont pas en rapport avec ton système… Du coup, systemd prend tout son sens…
Après, j'avoue resté amoureux de l'init BSD, just KISS…
[^] # Re: Cloud fail
Posté par Toufou (site web personnel) . Évalué à 5.
Je pense que tout l’intérêt d'un script shell c'est justement que tu peux facilement le modifier pour l'adapter à tes besoins : c'est fait pour ça. Son exemple me semble tout à fait pertinent. Je ne vois pas en quoi adapter un script veut dire qu'il a été codé avec les pieds : c'est juste que le contexte change.
Si tu dois chercher les 36 dépendances de ton script shell pour pourvoir l'adapter à ton besoin, alors là oui ça veut dire que c'est codé avec les pieds. Debian et red hat (les autres je ne connais pas) sont spécialistes des scripts complexes appelant 36 fonctions externes et balançant des lockfiles inutiles de partout.
Quand je vois /etc/sysconfig je peux comprendre pourquoi RH trouve que systemd est une amélioration. Mais quand j'utilise un init BSD, je ne peux qu'être d'accord avec l'auteur de l'article : systemd est écrit par un mec qui ne voit que le desktop et qui a laissé sa culture informatique au placard pour ne pas voir que ce qu'il propose existe déjà en mieux.
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 2.
Mwai, enfin les services dans systemd, j'imagine qu'il sont pas codé en C, tu peux tout aussi bien les adapter à tes besoins…
Genre dans systemd, y'a:
ExecStartPre=
qui te permet de lancer un script avant le lancement du service et donc de faire tout ce que tu veux…
Donc je vois pas ce que ca change…
[^] # Re: Cloud fail
Posté par Toufou (site web personnel) . Évalué à 4. Dernière modification le 07 mars 2012 à 14:11.
Rien.
C'est ce que je dis : le mec réinvente la roue et ce au prix d'ajouter une énieme syntaxe spécifique (celle de la conf de systemd) pour faire ce qui se faisait avant dans une syntaxe unique : sh.
De toutes manières ce n'est pas le propos principal de mon post : ce que je relevais c'est que devoir modifier un script ne veut pas dire que ce script est codé avec les pieds. Si on fait des scripts et pas du compilé c'est justement pour rendre simples les modifs éventuelles pour adapter le programme au contexte.
[^] # Re: Cloud fail
Posté par zebra3 . Évalué à 0.
Sachant que la syntaxe de sh est universelle et tout à fait lisible par n'importe qui.
Ou pas.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Cloud fail
Posté par Toufou (site web personnel) . Évalué à 4.
Beh universelle non puisqu'il y a des dialectes mais tu ne peux nier qu'elle soit très connue car utilisée sur tous les unix de la planète, entre autres systèmes l'utilisant, et que contrairement à la syntaxe d'un fichier conf quel qu'il soit, elle sert à faire plein de choses utiles autres que la conf d'un soft.
Qui parle de lisible par tout le monde ? Parce que tu crois que quand madame Michu ira bidouiller son systemd (et les scrips shell qu'il n'élimine pas) pour faire sa config aux petits oignons elle s'affranchira de potasser les docs sur les syntaxes utilisées ?
Quand à l'admin système du quartier, s'il n'est pas foutu de lire un script shell alors crois moi, systemd n'est pas la solution à ses problèmes.
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 3.
Donc en gros, ce que tu dis, inetd c'est de la grosse merde, il fallait faire ça avec des scripts shell ? Attention, y'en a un paquet de soft dans le genre…
[^] # Re: Cloud fail
Posté par Toufou (site web personnel) . Évalué à 2.
Encore un petit effort et tu arriveras à me faire dire que je demande la réécriture du noyau en shell. Non mais vraiment n'importe quoi.
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 1.
Au lieu de rien dire, répond à la question…
C'est quoi la différence entre ce que fait inetd et ce que fait systemd ? Il utilise tous les deux un fichiers de conf pour lancer un service, et j'ai jamais vu personne geuler…
[^] # Re: Cloud fail
Posté par Toufou (site web personnel) . Évalué à 1.
Décidement tu dois te tromper de post ou j'ai un bug d'affichage : je ne parle pas d'inetd mais de l'utilisation des scripts shell et du fait qu'avoir les modifier n'implique pas qu'ils soient codés avec les pieds (ce que toi tu affirmes).
Le seul rapport avec inetd ou autre service c'est qu'on utilise des script shell pour les démarrer.
Le seul rapport avec systemd c'est quand je dis que systemd n'amène rien qui n'existe déjà qui ne se fasse très bien par scripts.
Désolé je ne vois pas comment tu en arrives à me faire dire qu'inetd et les binaires c'est de la merde. Alors respire un coup et relis au calme.
dans un cas il y a deux choses à connaitre (le shell et la conf du service), dans l'autre il y en a 3 (systemd, le shell et la conf du service) => plutôt que de se baser sur l'existant, on réinvente la roue.
beh j'ai pas gueulé non plus, c'est toi qui démarre au quart de tour
[^] # Re: Cloud fail
Posté par gaaaaaAab . Évalué à 3.
il y a quand même une sacrée grosse différence entre systemd et inetd, c'est la gestion des dépendances. Du coup, autant les services gérés par inetd sont "plats", autant systemd doit gérer un graphe (j'imagine qu'un arbre binaire basique ne suffit pas à systemd mais je ne n'ai pas mis le nez dedans). Conséquence logique, le code d'inetd peut être beaucoup plus simple et robuste que celui de systemd.
Autre différence majeure, inetd est optionnel (on peut très bien démarrer son démon sshd sans passer par lui) et le restera tandis que systemd vise à remplacer définitivement les autres mécanismes de boot avec lesquels il est en concurrence.
ça répond à la question ?
[^] # Re: Cloud fail
Posté par Sufflope (site web personnel) . Évalué à 1.
init=/bin/bash dans grub et c'est bon tu peux te passer de systemd pour utiliser ce que tu veux qui est tellement mieux.
Pour lilo je sais pas, je suis pas archéologue.
[^] # Re: Cloud fail
Posté par gaaaaaAab . Évalué à 1.
certes.
en l'occurrence, je répondais sur les différences entre systemd et inetd.
[^] # Re: Cloud fail
Posté par briaeros007 . Évalué à 2.
Donc tu pense que le code compilé en C ne sera pas codé avec les pieds ?
Si ils sont codé en shell avec des pieds, il n'y a aucune raison qu'en C ils codent beaucoup mieux, ca serait même l'inverse d'ailleurs.
Si ils dépendent d'un fichier qui n'est pas installé sur ton système, systemd ne vas rien changer sur ce point.
Juste que ce sera BEAUCOUP plus compliqué à détecter, comprendre, gérer et modifier.
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 2.
Le code de systemd, il est codé une fois, les scripts de démarrage de soft de MERDE PROPRIO A LA CON QUI MARCHE PAS, j'en ai plein ma tabatière…
Systemd veut forcer la standardisation, donc y'aura pas de fichier pas installé
[^] # Re: Cloud fail
Posté par claudex . Évalué à 3.
De plus, il y a une commande pour voir la liste des dépendances d'un service.
« 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: Cloud fail
Posté par briaeros007 . Évalué à 2.
upstart aussi …
Ca s'apelle "cat"
et en plus on peut la modifier très facilement à la main si on veut que ca s’exécute après un script maison par ex …
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 2.
Comme avec systemd, amis du je blahblahte sans savoir de quoi je parle, bonjour…
[^] # Re: Cloud fail
Posté par briaeros007 . Évalué à 0.
Faudra que tu me montre comment tu modifie très facilement les scripts de démarrages … vu qu'il y en a pas (dixit vos dires) et qu'on arrête justement pas de nous répéter que "ceci est une révolution".
Sinon j'assume totalement ne pas avoir regarder en long en large et en travers la doc d'admin (dont la trad fr n'est même pas hébergé chez eux) car je ne suis tout simplement pas d'accord sur les principes de bases de systemd. Je ne vais donc pas perdre mon temps à utiliser un truc qui complexifie inutilement mes systèmes (ne serait ce que par l'utilisation de dbus).
[^] # Re: Cloud fail
Posté par claudex . Évalué à 3.
Au lieu de faire pointer ExecStart vers le binaire, du le fait pointer vers ton script. Et tu fais ce que tu veux. Tu peux même utiliser ExecStartPre
« 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: Cloud fail
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
De toute façon, le CamelCase, c'est naze ;-)
[^] # Re: Cloud fail
Posté par briaeros007 . Évalué à 1.
Donc systemd saura tout seul comme un grand comment les softs sont censés démarré ou dépendra d'une conf/ajout/… qui sera tout aussi plantogène ?
Tu fais comment pour les softs qui viennent d'autres unix ? Tu demandes aux dvp de travailler pour chaque version d'unix ?
veut n'est pas "vas y arriver".
Ensuite un fichier de conf (tu sais un truc qui sert à configurer un programme/logiciels/… pour des gens qui ont besoin d'avoir plus que juste les options de gnomes) ca peut très bien ne pas être ajouté par le gestionnaire de paquetages, le make/make install ou alors avoir une légère différence entre la syntaxe attendu (v1.3) et celle installé sur le système (v1.0).
tu peux m'expliquer comme systemd va automagiquement gérer ça ?
Parce que là c'est plus un système de démarrage, c'est carrément une distrib complète(fermé vu qu'on ne peut rien modifier et que tout est déjà parfait d'après tes dire)
Enfin, des standardisation il y en a déjà eu pour les scripts de démarrages (lsb toussa). Et visiblement d'après tes dires ce ne fut pas parfait. Qu'est ce que fait que systemd ca va être automagiquement parfait, surtout qu'ils demandent aux gens de faire plus de taff et de refaire un taff qu'ils avaient déjà fait ? Tu crois vraiment qu'ils vont passer du temps à paufiner ce qu'ils avaient déjà fait ?
[^] # Re: Cloud fail
Posté par claudex . Évalué à 4.
Tu lui reproche exactement à systemd, d'être compatible avec l'existant ou d'apporter une nouvelle syntaxe?
« 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: Cloud fail
Posté par briaeros007 . Évalué à 1.
Je reproche à systemd d'être bling bling et de ne pas se préoccuper des vrais problèmes , a savoir un système fiable, robuste, utilisable en cas de grosse merde, et adaptable aussi bien sur des serveurs que sur des desktops ou de l'embarqué. Et compatible avec des conf extérieures (portages etc…).
Il fais plein de promesses (demain on rase gratis), mais plusieurs autres ont déjà fait les mêmes promesses, et on a tous vu qu'aucun a pu les tenir.``
Bref, avant de vouloir tout péter et de tout décider, il faudrait se concentrer sur les intérêts.
Est ce que tu serais intéressé de changer de software (presque)complètement débuggé par le fait que ca fait 15 ans qu'ils tournent, sur des archi complètements différentes et des cas d'utilisations tout aussi disparates, alors qu'il répond tout à fait a tes attentes ?
Moi non.
Et si les gens sont si concernés que ça par le démarrage de leur desktop, qu'ils le mettent en hibernation!
[^] # Re: Cloud fail
Posté par Zenitram (site web personnel) . Évalué à 0.
Je t'en prie, fait-le. En attendant, systemd répond aux vrais problèmes de ceux qui le développent et ceux qui l'acceptent.
C'est ça qui est beau avec un "vrai problème" balancé comme ça.
[^] # Re: Cloud fail
Posté par briaeros007 . Évalué à 1.
mais je l'ai fait.
Mon problème de fiabilité est résolu avec l'init actuel, et de simplicité aussi.
Et si je veux du parallélisme, j'utilise upstart, et ça suffit amplement.
Pas besoin de changer quand quelque chose marche.
[^] # Re: Cloud fail
Posté par claudex . Évalué à 3.
Upstart n'est plus développé il me semble.
« 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: Cloud fail
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Actuellement sous debian insserv (développé par Suse à l'origine) gère les dépendances lors d'une mise à jour et sysv-rc assure le boot parralèle. Par besoin d'Upstart /a priori/ pour cela.
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 2.
Non, systemd propose un fichier de conf qui fonctionne sur toutes les distribs…
Pas un script écrit pour RH qui fonctionne que sous RH… C'est si dure que ça à comprendre ?
Euh, facile, en gardant une syntaxe stable dans le temps, c'est la promesse de systemd… Sinon, c'est sur, si tu enlèves cette partie, il ne sert plus à rien…
Allez, vas y expliques moi cette partie, t'as l'air de vachement t'y connaitres pour lancer de telles affirmations…
[^] # Re: Cloud fail
Posté par Albert_ . Évalué à 1.
Non, systemd propose un fichier de conf qui fonctionne sur toutes les distribs…
Pas un script écrit pour RH qui fonctionne que sous RH…
Tu me permettras d'attendre de voir ca en production dans une distribution stable et non a base de RPM avant de me prenoncer!
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 2.
Toi, t'as jamais installé un soft proprio sous Debian ;)
[^] # Re: Cloud fail
Posté par Albert_ . Évalué à 2.
Euh si, un compilo :)
[^] # Re: Cloud fail
Posté par Sufflope (site web personnel) . Évalué à 2.
Quelle est la durée de maintenance d'une distribution stable selon toi (Debian, j'imagine) comparée aux 10 ans de maintenance d'une RHEL ?
[^] # Re: Cloud fail
Posté par Albert_ . Évalué à 3.
RedHat a deja inclu systemd dans RHEL?
Et mon point c'etait que pour le moment en dehors de systeme RPM based systemd c'etait juste en phase de test. ET vu le merdier que fut PA, NM a mettre sur autre chose je prefere attendre et de voir venir. Le coup des trucs venant de RH qui doivent fonctionner partout et ou c'est pas vraiment le cas c'est un peu un classique tout de meme surtout les trucs de Pottering.
[^] # Re: Cloud fail
Posté par briaeros007 . Évalué à 3.
NM est sur RHEL.
Lors d'une formation RHEL (donné par redhat), première chose qu'on a dis quand on s'occupe du réseau : "On désactive Network Manager. C'est très bien pour une utilisation desktop mais c'est nulle pour un serveur".
Et ils nous refont la même chose avec systemd visiblement /o
[^] # Re: Cloud fail
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je ne suis pas sur que 10 ans soit une bonne idée sauf cas spécifique (satellite…). Une maintenance trop longue peux aussi s'avérer un boulet à terme.
Après, la bonne longueur…
[^] # Re: Cloud fail
Posté par briaeros007 . Évalué à 2.
Et quand il y a des différences entre les distribs qu'il est nécessaire de prendre en compte, tu fais comment ?
C'est surtout que ça fait juste 25 ans qu'il y en a qui nous sortent la même rengaines, et 25 ans de prod qui montrent qu'elles n'a jamais marchée.
"sh" a une syntaxe stable dans le temps, ca devrait donc être suffisant d'après tes dire.
Je me base juste sur vos affirmations (faut prendre la phrase dans son contexte).
Sinon je suis triste que tu ne parles pas des derniers paragraphes de mon commentaires /o
[^] # Re: Cloud fail
Posté par gaaaaaAab . Évalué à 3.
j'ai peur que ça ne reste que des bonnes intentions. Pour mémoire, Microsoft n'a jamais réussi à faire utiliser ses outils de journalisations par les éditeurs tiers (ce qui explique l'inutilité des journaux système de Windows) et pourtant, c'est Microsoft.
[^] # Re: Cloud fail
Posté par claudex . Évalué à 3.
C'est, entre autres, ce qui fait leur force. Il ne font pas chier les développeurs, qui leur permet d'avoir beaucoup d'applications disponibles. (demande à Zenitram si ce n'est pas plus facile pour le développeur de développer pour Windows)
« 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: Cloud fail
Posté par gaaaaaAab . Évalué à 4.
et après, demande moi si c'est pas plus simple de développer pour Linux. Et ensuite ? on a montré quoi ?
[^] # Re: Cloud fail
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Cela fait des années qu'il existe une solution simple à ce porblème, la mutualisation du code. Un coup de "source" dans ton fichier bash et tu mutualises pas mal de ligne entre les scripts qui le peuvent.
Chez debian, il y a par exemple en début de script
[^] # Re: Cloud fail
Posté par Michaël (site web personnel) . Évalué à 3.
Sous FreeBSD le même principe est utilisé, je pense qu'il a été importé depuis NetBSD. Cf. rc.subr(8)
Une autre façon de résoudre le problème consisterait à réaliser correctement tous ces copier-coller, c.-à.-d. à utiliser un préprocesseur, comme m4, pour préparer les scripts de démarrage. Je ne connais cependant aucun système procédant ainsi.
[^] # Re: Cloud fail
Posté par Axone . Évalué à 7.
Pourtant le site officiel de systemd pointe un article sur linuxfr.org :
http://freedesktop.org/wiki/Software/systemd
C'est carrément dans la section "Manual Pages And Documentation for Users and Administrators"
Ca pointe ici :
https://linuxfr.org/news/%C3%A9volutions-techniques-de-systemd
[^] # Re: Cloud fail
Posté par patrick_g (site web personnel) . Évalué à 3.
Ce qui est normal puisque la news LinuxFr, était en grande partie une traduction de la documentation systemd (c'est précisé lors de l'introduction de la dépêche).
[^] # Re: Cloud fail
Posté par Guillaume Knispel . Évalué à 6.
Dans certains cas oui. Néanmoins comme tu le dis certains firmware bootent en 3 plombes, et il vaut mieux s'y attaquer en cas de besoin de démarrage rapide sur un serveur et viser des choses comme coreboot par exemple. De plus systemd n'améliore pas tant que ça le temps entre le démarrage et la disponibilité réelle de tous les services, et s'il y a peu de services c'est facile d'obtenir un résultat encore plus proche en se passant de sa complexité (et en gagnant au passage en modularité et possibilité de combinaison non prévues par les concepteurs). Enfin systemd est fourni avec des chaînes dorées que l'on peut sous un certain angle trouver confortables et certains sont tentés de s'attacher avec (ou font carrément exprès car ils kiffent les effets de bords de ces chaînes qui permettent aussi d'asservir des tiers), ce qui présente un grave risque pour l'écosystème du LL.
[^] # Re: Cloud fail
Posté par inico (site web personnel) . Évalué à -2.
Donc écrire un fichier /linuxrc où la gestion des erreurs dependra de tes compétences ?
J'ai observé ce style d'optimisation sur de l'embarqué et même un init SySV aurait été plus fonctionnel (l'httpd crash et l'init s'arrete, fun, non ?)
C'est drôle tous ces articles sur Systemd, je n'ai pas vu les équivalent pour launchd et smf.
Pourtant, il y a la même volonté de changement derrière.
[^] # Re: Cloud fail
Posté par Guillaume Knispel . Évalué à 5.
Tout le monde se fiche de launchd et smf. (au sens où ça a beaucoup moins d'impact indirect, les gens directement intéressés ne s'en fichent évidemment pas)
Le problème de systemd, c'est que RH compte dominer la planète GNU/Linux grâce à ce truc (et à d'autres bidules du même genre) avec des effets collatéraux relous en passant.
[^] # Re: Cloud fail
Posté par gik . Évalué à 4.
C'est moche ton avis sur Red Hat.
Moi qui avais foi en l'impartialité de ce journal…
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 2.
Et genre, comment RH va dominer la planète GNU/Linux grâce à ce truc ?
Tu comprends pas que si Suse s'oriente vers ce truc, y'a une bonne raison ? C'est qu'il est écrit pour répondre à une demande, celle du monde propriétaire qui s'en bas la race du libre et qui demande juste un moyen de simplifier le fonctionnement de la gestion des services sous Linux.
Mais j'ai pas encore entendu dire que Linus avait prévu de rendre le noyau "systemd compatible only"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cloud fail
Posté par inico (site web personnel) . Évalué à 8.
Tu n'as jamais eu une machine qui dépends d'un service réseau pour booter style NIS ?
Même avec un SSD, l'ypbind prend 1 minute, c'est là où il faut paralleliser.
On peut egalement évoquer les resolutions DNS bloquantes et autre joyeuseries.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cloud fail
Posté par inico (site web personnel) . Évalué à -1.
& va laisser stdin, stdout et stderr connectés à la console.
Cela peut être problématique.
ps: L'IUT R&T sur le campus de Luminy (coucou fredg @DOSICALU) utilisait NIS jusqu'a l'année dernière.
Cette année, c'est enfin du ldap :)
[^] # Re: Cloud fail
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
Sauf si tu fait attention à ce que tu fait, hein. Dans un script de démarrage, tu peux faire sereinement en background deux choses :
/etc/motdavec les fortunes d'un moulodrôme quelconque.Donc, je ne vois pas où est le problême.
[^] # Re: Cloud fail
Posté par Buf (Mastodon) . Évalué à 1.
Ben tu le dis toi-même :
Le problème, c'est tout le reste.
[^] # Re: Cloud fail
Posté par Michaël (site web personnel) . Évalué à 6. Dernière modification le 07 mars 2012 à 13:30.
Dans le shell, il a des opérateurs de redirection. Tu peux lancer ton programme
progcomme ça:sh
( exec prog <&- 1>stdout.log 2>stderr.log )&
et le tour est joué.
[^] # Re: Cloud fail
Posté par gnumdk (site web personnel) . Évalué à 4.
T'as déjà eu une machine comme ca ?
- Avec un init standard BSD: c'est faux
- Avec upstart: c'est plus rapide mais c'est faux
- Avec systemd: c'est plus rapide mais c'est faux
[^] # Re: Cloud fail
Posté par NeoX . Évalué à 3.
sur mes serveurs c'est l'initialisation des peripheriques AVANT de demarrer le noyau linux qui prend du temps (check de la ram, activation de la carte RAID, check des disques etc)
une fois le hardware activé, ca boote comme un desktop, en 15/30sec
sauf peut-etre quand il y a un fsck
[^] # Re: Cloud fail
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je dois dire qu'avec le boot parallèle du vieux système init amélioré, cela va déjà très vite…
On perd du temps ou sur un serveur : Le bios surtout…
Le reste, ca va très vite, l'activation du réseau peux ralentir parfois (synchro ntp…) mais tout cela reste négligeable devant le BIOS.
[^] # Re: Cloud fail
Posté par briaeros007 . Évalué à 7.
Sur… quand ta carte raid prend 15 minutes (montre en main, testé) à voir les lun et a gérer correctement ta conf, que ton serveur soit "UP" en 17 minutes ou en 17,5 minutes va vraiment changer la face du monde … (soit un gain de … 3% sur le démarrage total)
# Ben oui
Posté par Michaël (site web personnel) . Évalué à 3.
Je suis bien d'accord, on avait déjà parlé de systemd ici, pas pour n'en dire que du bien.
https://linuxfr.org/nodes/88259/comments/1293013
Heureusement, je suis sous FreeBSD! :)
# Bureau, serveur et maîtrise
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ce que j'apprécie sous Linux, c'est que je peux utiliser la même machine comme serveur web, fichier, lecteur multimédia, station bureautique, console de jeu, PC de développement… Pour tous ces usages, je veux à la fois un boot rapide, peu gourmand en ressource et un système facile à entretenir.
Ce n'est peut être pas parfait, mais aujourd'hui les machines et les distributions Linux actuelles le permettent. Systemd promet d'améliorer les performances, c'est bien, mais je préfère acheter de la RAM ou un disque SSD que de perdre la maîtrise de mon environnement.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bureau, serveur et maîtrise
Posté par gik . Évalué à 3.
Même sous GNU/Linux, embarqué, bureau et serveur sont segmentés.
Les impératifs sont différents: embarqué: économie de ressources, bureau: simplicité d'utilisation, serveur: adaptabilité.
On peut certes mélanger les genres sur un bureau (parce que de vieilles bécanes s’apparentent plus à de l'embarqué de nos jours) mais certainement pas installer des logiciels de bureau sur de l'embarqué, et il y a peu d’intérêt à utiliser des logiciels pour l'embarqué sur un serveur.
Non seulement tu affirme que Systemd te ferait perdre la maîtrise de ton environnement sans étayer tes propos, mais en plus sache rien n’empêche d'améliorer les performances à la fois coté logiciel (ce qui n'est pas le but de Systemd) et coté matériel (mais je préfère que ce soit logiciel personnellement, afin que cela profite au plus grand nombre).
J'ajouterais qu'il n'y a pas encore eu de Fronde des Sysadmin mais une poignée de réfractaires en Europe (Amho, surtout des trolls franco-français qui dès qu'ils trouvent écho à l'étranger se pressent de l'étaler sur dlfp). Si Systemd ne convient pas, les décideurs pressés changeront de solutions sans trop de difficultés.
[^] # Re: Bureau, serveur et maîtrise
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Dans le monde pro oui, chez les noob michus qui achètent une tablette, un nas et une console aussi, mais pas dans le monde des Personal Computers qui sont des machines à tout faire.
Je ne dis pas ça, je dis juste qu'actuellement les systèmes GNU/Linux fonctionnent pour tous les usages et il est encore possible de comprendre comment ils fonctionnent. Si Systemd n'est pas beaucoup plus performant et beaucoup plus simple que l'existant, je n'en vois pas l'intérêt.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bureau, serveur et maîtrise
Posté par gik . Évalué à 7. Dernière modification le 07 mars 2012 à 13:11.
Linus n'utilise pas Linux From Scratch, il n'y a ni n00b, ni kevin, ni michu, ni 1337. Il y a des utilisateurs dont la grande majorité veulent un système qui fonctionne sans connaissances particulières (je mets volontairement de côté le business model des grosses boites qui utilisent le libre). Une tablette sous GNU/Linux ou PC-BSD à l'aspect soigné (avec KDE ou Gnome osef) se vendrait très bien pour peu qu'elle soit produite par une grosse boite avec la comm' qui va bien. S'il vous faut un système éducatif, il y LFS, Gentoo *BSD ou mieux encore Minix. Quoi qu'il en soit, à partir du moment ou le code est vaguement libre, c'est "hackable".
Pour en revenir au sujet: Je le répète, l'intérêt de Systemd n'est pas dans la performance. Sans animosité aucune, cette remarque n'était pas vraiment personnelle à vrais dire, mais si le code de Systemd est imbitable, j'en conviens, dire que sa configuration est compliquée, ou qu'elle empêche qui que ce soit de maîtriser son système, c'est là qu'est le sophisme. Autre exemple: wpa_supplicant (bien moins critique que le pid 1, certe) est imbitable, mais sa configuration est simple. J'irais pas hurler au scandale parce que wpa_supplicant n'est pas écrit en bash et je n'irais pas raconter que j'ai besoin d'un debugger et de connaissance en C pour pour me coller à mon point d'accès. En poussant le raisonnement à l'extrême (je suis drosophile pour le coup): Linux n'est pas en lua/python/bash/basic et pourtant cela aurait beaucoup plus simple pour sa compréhension. En tout cas pour l'instant Systemd, ça juste marche.
[^] # Re: Bureau, serveur et maîtrise
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Je sais bien que la consommation est en train de "gagner". Mais je veux croire qu'il existe encore des gens qui veulent pouvoir changer une roue sans aller chez le garagiste, remplacer un robinet sans appeler le plombier, cuisiner au lieu d'acheter des plats micro-ondables, faire un jardin au lieu de mettre des plantes en plastique, construire des étagères au lieu d'aller chez ikea, jouer d'un instrument, écrire, ou dessiner plutôt que de rester devant la télé, bref créer plutôt que consommer.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bureau, serveur et maîtrise
Posté par gik . Évalué à 2. Dernière modification le 07 mars 2012 à 13:34.
J'ajouterais que l'usage de ton "Personal Computer", ce que j'appelle bureau, c'est triste à dire mais, il aurait été le même sur un OS proprio (et pourquoi pas des logiciels gratuits si c'est un critère). Là, tu ne pourrais rien maîtriser.
On est loin de comprendre tout se qui se passe sur un GNU/Linux. Faut avoir un groupe d'experts pour cela.
Je suis utilisateur de libre, entre autre, pour la philosophie du libre, probablement comme toi, mais certainement pas pour passer pour un bricoleur.
# Choix
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10. Dernière modification le 06 mars 2012 à 23:36.
Bah, en même temps, pas la peine de s'inquiéter, il y en aura pour tous les goûts : systemd pour ceux qui aiment, SysV init ou BSD init pour les autres. systemd ne signera pas l'arrêt de mort de ses prédécesseurs, qui continueront à être maintenus pour les besoins des BSD et de Debian.
[^] # Re: Choix
Posté par gik . Évalué à 1. Dernière modification le 07 mars 2012 à 03:10.
Tu n'as visiblement pas saisi toute l'essence dramaturgique de ce plaidoyer.
Il dit: "Son erreur de conception la plus importante est peut-être qu'il a été conçu avec un mépris flagrant pour les serveurs".
Impossible que systemd soit utilisé en prod. La preuve en est, il permet le démarrage plus rapide des services, c'est de la merde.
Plus loin, il explique que Systemd n'est pas Unix qui "est encore utilisé aujourd'hui sous des formes diverses, après ces 42 ans" et "dont le"pilier de sa conception, c'est la simplicité et la modularité. Un programme pour une tâche ; une interconnexion facile entre les programmes"
Faut il comprendre que GNU/Linux a 42 ans? En tout cas, Systemd fait plus que démarrer des services, donc c'est de la merde.
J'aime beaucoup cet argument: "La dernière chose que vous voulez et d'avoir à instrumenter, débugger, et reconstruire du code C au coeur de votre OS"
Il faut un debugger et des connaissances en C pour modifier les services, donc nous pouvons affirmer que c'est de la merde.
L'implacable verité:
"Avec le soutien financier de Red Hat et toute la propagande (je n'ose même pas appeler cela de la Relation Publique), cela va être un combat ardu [..] Tout espoir n'est pas perdu."
Red Hat, c'est le système financier. Indignez vous, et lançons Occupy Poettering.
L'auteur aurait préféré l'ironie au cynisme que son argumentaire aurait été bien moins ridicule.
:) Nimage
[^] # Re: Choix
Posté par Misc (site web personnel) . Évalué à -1.
Moi aussi, je trouve qu'avoir du C au coeur du kernel, c'est une horreur. Vivement qu'on puisse revenir à du bash pour avoir un truc vraiment solide.
[^] # Re: Choix
Posté par claudex . Évalué à 3.
Vivement baba, bash en bash.
« 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: Choix
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
En plus, modifier un script init en bash, c'est quand même la recette assurée pour le désastre à la prochaine mise-à-jour de ta distro.
Oh, on me souffle à l'oreille que les vrais admins ne mettent pas à jour…
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Choix
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il n'empêche que j'utilise en frontal pour le mail QPSMTPD écrit en Perl qui tient bien la charge et que j'ai pu modifier ici ou la à ma sauce alors que je n'ai jamais modifié et ne modifierais certainement jamais une ligne de code dans exim ou postfix !
Il faut du C pour aller vite et aussi du script pour la souplesse.
Toute la force d'UNIX pour le moment a été de garder de la souplesse aux bons endroits…
[^] # Re: Choix
Posté par gik . Évalué à -2. Dernière modification le 07 mars 2012 à 23:25.
Boah, c'est un soft assez spécifique, c'est pas comme si tu voulais passer tout un système, scripts d'init compris, à un autre shell par défaut pour des raisons de performance, puis que tu t’aperçoive que ça pourrait foutre le boxon :)
https://wiki.ubuntu.com/DashAsBinSh
http://wiki.debian.org/DashAsBinSh
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481
C'est surtout du second degré (probablement en rapport avec un de mes commentaires plus haut), personne ne nie que les langages de "scripts" (j'aime pas trop ce terme) soit précieux et incontournables même si d'aucun affirme qu'ils ne sont pas toujours utilisés avec sagesse.
[^] # Re: Choix
Posté par Sufflope (site web personnel) . Évalué à 4.
Parce que tu connais Perl et pas le C. Pour un gourou de la programmation fonctionnelle, ça doit être simple de modifier mldonkey, et une horreur de regarder un .sh (sérieux, vous trouvez bash élégant comme langage ???)
[^] # Re: Choix
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je ne connais pas Python que personnellement je n'apprécie guère, cela ne m'a pas empêché de modifier du Python ou du PHP sur des serveurs…
Le problème ne viens pas du C, il viens que c'est du binaire et qu'il faut donc les sources, recompiler… C'est toute cette chaîne qui fait qu'en pratique, quasiment personne je pense ne modifie en serveur écrit en C.
Sinon pour le bash, c'est pas un langage parfait mais cela pourrait être pire. C'est un langage fait pour la ligne de commande donc avec l'espace comme séparateur. Je le trouve surtout faible coté tableau et table de hachage ;-)
[^] # Re: Choix
Posté par briaeros007 . Évalué à 1.
Ceux qui disent "non mais c'est génial le C pour administrer un serveur et rajouter un petit service"
soit n'ont jamais fait de C et ne savent pas de quoi ils parent
soit n'ont jamais administrer (réellement) un serveur et ne savent pas de quoi ils parlent.
[^] # Re: Choix
Posté par Zenitram (site web personnel) . Évalué à 6.
Ceux qui disent "non mais c'est horrible le C pour administrer un serveur et rajouter un petit service"
soit n'ont jamais fait utilisé un fichier de conf et ne savent pas de quoi ils parent
soit n'ont jamais administrer (réellement) un serveur et ne savent pas de quoi ils parlent.
Non, parce que la, corrigez moi si je me trompe, mais les fichiers de conf (service) ne sont pas en C, on édite ce fichier de conf et pas systemd lui-même. Donc : voit pas le rapport avec C.
[^] # Re: Choix
Posté par briaeros007 . Évalué à 0.
Ou alors ils ont déjà utilisé un fichier de conf, et savent les intérêts et les limites de tels fichiers.
Quand tu veux modifier le fonctionnement du script de démarrage, tu modifie un fichier de conf ou tu modifie le script?
[^] # Re: Choix
Posté par Zenitram (site web personnel) . Évalué à 2.
Quelle merde ce serveur Apache, il est codé en C et demande des fichiers de conf, on voit les limites… Ou pas.
Sinon, pour les mecs trop trop pointus dont le fichier de conf ne suffira pas, ben… Pourquoi pas mettre dans le fichier de conf l'appel à ton script? Bref, rien de gênant, à part pour le plaisir de râler contre ce qui a du succès (toutes les distros ou presque regardent)
Ah… quand on veut absolument critiquer pour critiquer…
[^] # Re: Choix
Posté par briaeros007 . Évalué à 1.
Ah bon? Y'a aucun module sous apache ? Tout peut etre fait uniquement avec les fichiers de conf ?
Ou pas…
Non tu as raison, autant avoir un système batard bien crade… Quand on prone la simplicité et la normalisation c'est tellement une bonne méthode de rajouter des scripts non normalisé (start/stop ca a au moins un avantage) au beau milieu rien que pour pouvoir dire 'non mais l'interface de lancement elle est propre' …
Ce qui m'intéresse c'est un système cohérent, pas un patchwork.
[^] # Re: Choix
Posté par Zenitram (site web personnel) . Évalué à 3.
Donc Apache c'est de la merde : il y a un patchwork de fichier de conf (répondant à 90% des besoins) et des modules (les 10%). En fait comme quasiment partout, sauf un truc horrible à coup de scripts uniquement.
Pourquoi critiquer systemd et pas Apache?
Et encore une fois, rien ne t'empèchera de configurer pour lancer ton script "comme avant" sans toucher une ligne de C. C'est du FUD.
[^] # Re: Choix
Posté par briaeros007 . Évalué à 2.
En même temps Apache c'est un service applicatif, on a pas forcément les mêmes demandes qu'avec un système d'init.
Tu as pas du souvent utiliser apache. Les modules de apache couvrent les besoins de base. tu as des fichiers de conf spécifiques pour les modules.
Euh non pas comme "quasiment partout". Certains serveurs applicatifs couvrent leurs besoins sans avoir rajouter modules et plugins dont certains avec des fichiers de conf différents.
Et qu'est ce que ça a d'horrible d'avoir des fichiers de confs et des modules (les scripts) ?
Ah oui, rien. Sauf que c'est cohérent :
Des scripts shell pour le démarrage avec init/upstart.
Des modules compilés spécifique pour apache avec l'API apache pour apache.
Des fichiers de confs spécifiques aux "modules" (pour l'init les scripts, pour apache, les .so) dans les deux cas.
Sauf que poru systemd, ce n'est pas cohérent : on refuse les scripts shell pour le démarrages des services, mais finalement on les veux bien son a besoin de rajouter des commandes à executer avant, etc…
Bref, pas cohérent du tout.
Je vois pas bien en quoi je fait peur à qui que ce soit.
Faut juste pas venir nous expliquer que systemd est super "normalisé" itou, et en même temps avoir besoin de passer soit par de gros hack (non cohérent avec le principe du système), soit de changer tous le systèmes en, excusant du peu, devoir recompiler l'init.
En une ligne comme en cents : le shell script c'est facile a modifier et à gérer, et c'est proche du système. D'où son intérêt dans l'utilisation de l'initialisation.
Et faire un système batard ne sert qu'a complexifier inutilement les choses.
[^] # Re: Choix
Posté par gaaaaaAab . Évalué à 3.
je ne l'ai pas vu mentionner dans le fil alors ici, c'est aussi bien qu'ailleurs.
Sur un serveur de prod, il n'y a pas systématiquement un compilo de disponible. En fait même, c'est plutôt qu'il y a systématiquement pas de compilo installé.
[^] # Re: Choix
Posté par Sufflope (site web personnel) . Évalué à 3.
Ah parce que sur ton serveur de prod' où il est explicitement interdit d'installer un compilo, tu modifies les scripts d'init à la volée ?
Lolilou.
[^] # Re: Choix
Posté par gaaaaaAab . Évalué à 3.
dans le cas nominal, non, évidemment. Je parle de situation de crise ou le service est par terre, les secondaires pareils (parce que par exemple c'est le 29 Février pour tous les serveurs en même temps) et il faut remettre en service le plus vite possible, option tous les coups sont permis. Je t'accorde que dans ce cas là, on pourra installer un compilo mais bon, si on peut directement intervenir en shell, ça peut faire gagner du temps.
[^] # Re: Choix
Posté par claudex . Évalué à 4.
Pourquoi tu veux recompiler systemd dans ce cas ? Il suffit de faire pointer ExecStart vers ton script et le problème est réglé.
« 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: Choix
Posté par Albert_ . Évalué à 3.
parce que par exemple c'est le 29 Février pour tous les serveurs en même temps
Euh on parle de Linux la pas de Microsoft Azure… :)
(ca va j'ai bien marcher dedans?)
[^] # Re: Choix
Posté par gaaaaaAab . Évalué à 2.
tout le monde avait reconnu, mais je n'ai pas voulu stigmatiser particulièrement Microsoft. Des problèmes sérieux (comme par exemple un bug dans génération de clefs suite à une modif d'opennSSH) peuvent arriver chez tous les vendeurs. C'était juste le premier exemple récent qui m'est venu à l'esprit.
[^] # Re: Choix
Posté par gnumdk (site web personnel) . Évalué à 3.
Mais pourquoi tu veux modifier systemd, faut quand même qu'on m'explique… A ce moment là, on peux aussi cracher sur l'init SysV, c'est du C aussi…
Tu vas me dire que ton noyau boot avec init=/bin/bash et des scripts persos? ?
[^] # Re: Choix
Posté par briaeros007 . Évalué à 0.
parce qu'on a peut être des besoins qui ne sont pas standards et qu'on a envie de controler finement le démarrage. Par exemple effectuer un vgchange -a y juste avant la détection le montage des disques parce qu'il y a un bug et qu'il faut l'effectuer comme ça pour que ça fonctionne. (rcS toussa).
Parce que j'ai envie de modifier la façon dont est lancé certains softs et que systemd dans sa version de base n'utilise pas mon truc top moumoute ?
[^] # Re: Choix
Posté par claudex . Évalué à 4.
Dans ce cas, tu modifie les services pour pointer vers ton script de démarrage. Je ne vois pas ce que ça change.
« 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: Choix
Posté par gnumdk (site web personnel) . Évalué à 5.
Il y'a déjà tout ce qu'il faut pour faire des opérations avant le lancement d'un service dans systemd: ExecStartPre=tonscriptbash.sh
[^] # Re: Choix
Posté par briaeros007 . Évalué à -1.
que c'est beau …
Rajouter des scripts différents au beau milieu.
Et ca se dit un système normalisé, cohérent, avec juste des fichiers de confs…
[^] # Re: Choix
Posté par gnumdk (site web personnel) . Évalué à 2.
En fait, t'es un comique ou juste un boulet ?
Pour les cas particuliers, y'a ce qu'il faut pour lancer des scripts shells mais je suis sur que 100% des services fournis par Fedora n'utilise pas ce genre de truc, c'est juste au cas ou…
[^] # Re: Choix
Posté par claudex . Évalué à 4.
Je ne comprend pas où tu vas perdre de la souplesse. Tu peux toujours modifier le fichier de service de systemd pour qu'il démarre ton script bash au lieu de l'exécutable normal.
« 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: Choix
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Ou ai je dis que systemd ne le permettait pas ?
Je pense que parfois, un langage spécialisé est top, pas exemple le fichier /etc/network/interface de debian. Il est encore plus top si, comme celui-ci, on peux aussi y mettre du bash (dash) dedans !
[^] # Re: Choix
Posté par gik . Évalué à 1.
Alors certes ces fichiers de configuration utilisent une syntaxe ésotérique mais de là à qualifier cela de "langage"? Pour sed à la rigueur, je veux bien, mais je suis pas certain que cela soit applicable dans cet exemple, ni dans les déclarations des fichiers de configuration des services de Systemd, il ne faut pas pousser mémé dans les hortensias…
# Le réseau
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 5.
Ça aussi, j'ai vraiment du mal à comprendre ce que ça vient faire dans ce machin. Il y a bien 20 ans que je pratique inetd, peut-être 10 ans que j'ai découvert xinetd, et ces deux trucs font très bien leur travail. Il ne faut pas trop longtemps pour comprendre comment ça marche, comment ça se règle, et c'est quasiment identique sur tous les systèmes sérieux. Les vicieux arrivent même à utiliser les deux simultanéments.
Que des services réseau "accessoires" soient gérés par le contrôleur central du coeur du système, ça me semble un peu étrange. Franchement, qui d'entre vous a trouvé un défaut à inetd/xinetd (c'est une vraie question) ?
Et pour le reste du troll sur
systemd, je n'ai pas grand chose à dire, n'ayant pas encore été confronté à ce genre de chose, à ce que ça peut impacter ma vie de tous les jours. Je vais attendre trolldi pour causer de pulseaudio.[^] # Re: Le réseau
Posté par Guillaume Knispel . Évalué à 8.
On ne peut pas comprendre les raisons des choix techniques de RH sans s'intéresser à sa politique en matière de support.
[^] # Re: Le réseau
Posté par Misc (site web personnel) . Évalué à 4.
Je pense pas que xinetd fasse mal son travail, au contraire. C'est juste que quitte à faire du démarrage à la demande, autant le faire complétement.
Tout comme launchd ou upstart peuvent servir à remplacer at/crond ( à terme au moins pour upstart, si je me souviens bien de la roadmap ) car ils ont pour principe de gérer les événements ( et "il est tel heure" est juste un cas particulier d’événements qu'on peut rajouter à d'autres ), systemd est la pour lancer des logiciels, et xinetd est juste un cas particulier de lanceur ( "je lance quand tel port est ouvert" ) auquel on rajoute "je lance tel logiciel sur une socket unix" et autres.
[^] # Re: Le réseau
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Euh ?
Quand j'écris 50 lignes de code pour jouer un question/réponse par le réseau trois fois par jour, inetd/xinetd fait complètement ce que j'attends de lui. On demande, il le fait.
[^] # Re: Le réseau
Posté par briaeros007 . Évalué à 1.
Donc systemd gère le démarrage de chaque application ?
Quand l'utilisateur lance libreoffice pour ouvrir un .doc, c'est un "démarrage" d'application, mais c'est pas systemd qui le gère (et heureusement).
Le but de systemd c'est de gérer le démarrage de la machine, pas le démarrage de tout ce qui tourne!
[^] # Re: Le réseau
Posté par claudex . Évalué à 3.
Le but de systemd, c'est de démarrer les services surtout.
« 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: Le réseau
Posté par zebra3 . Évalué à 3.
Sinon, on l'aurait appelé applicationd pour gérer les applications…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Le réseau
Posté par briaeros007 . Évalué à 0.
service d'édition de document docx …
oui c'est capillo tracté, mais pas plus qu'expliquer que le remplacement d'inetd par systemd c'est dans le principe de démarrage des services systèmes.
Un init qui ouvre des ports réseaux… Et tout le monde applaudis!
Remarque si vous souhaitez tant que ça avoir les même qualités que windows, cad ouvrir de grands pans de votre machine aux attaquants de tout poil c'est la bonne façon de faire.
Tout centraliser dans un seul soft, comme ça si il est corrompu, au moins pas de problème de gestion des dégats…
[^] # Re: Le réseau
Posté par claudex . Évalué à 4.
Donc l'init actuel le démarre déjà?
C'est quoi la différence avec l'init actuel qui démarre Apache?
« 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: Le réseau
Posté par gnumdk (site web personnel) . Évalué à 3.
Ben, tu peux espérer planter systemd en lui envoyant n'importe quoi … Après, vu que systemd ne fait que passer la main sans lire ce qu'on lui envoie, ca doit être très limité, sauf si il fait mumuse avec identd comme on l'a vu avec xinetd…
[^] # Re: Le réseau
Posté par briaeros007 . Évalué à 1.
[^] # Re: Le réseau
Posté par claudex . Évalué à 3.
Et ça change quoi?
« 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
# Mouais
Posté par Sufflope (site web personnel) . Évalué à 9.
Euh si. On peut citer daemontools par exemple.
Oui enfin le but est que le système d'init le fasse, pas qu'on compte sur chaque auteur de chaque script de démarrage d'utiliser cgroups.
Franchement appeler ça une gestion des dépendances c'est se foutre du monde. Le jour où je dois intercaler un service entre S30 et S31 je fais quoi, un S30,5 ?
Ah d'accord donc quand Lennart utilise un truc standardisé prévu pour la portabilité, c'est un salaud, et quand il refuse de complexifier son système pour prévoir la portabilité, c'est un salaud.
Yet another "Lennart est un salaud" troll, en somme.
[^] # Re: Mouais
Posté par bubar🦥 (site web personnel) . Évalué à 6. Dernière modification le 07 mars 2012 à 10:48.
+1
Et c'est bien un problème concret de Unix en général : en laissant trop de champ au sysadmin, on peut se retrouver avec du bricolage assez rapidement. Ton argument sur Cgroups je le place aussi pour les scripts d'init dans leur ensemble, tout leur ensemble. Quiconque a travaillé dans une maison dont l'histoire avec unix est aussi vieille que unix lui même, avec un parc de machines conséquent et très disparate, verra bien de quoi il s'agit lorsqu'on parle de bricolage. C'est vrai (heu, ça me semble) que systemd enlève du possible, par défaut, aux sysadmin. Et alors ? Vous en avez pas marre, vous, de voir des scripts d'init foireux partout sur plein de machines, avec un historique, et parfois un objectif, inconnu ? Là, le sysadmin il se contentera d'un déclaratif encore plus simple qu'un script, et c'est très bien comme ça.
Alors oui, moi aussi j'aime bien me toucher en faisant moi même des modifications, des ajouts, et même des règles Cgroups personnalisées. Juste pour le fun. Mais IRL, dans une grosse boite, le sysadmin qui fait ça j'ai tendance à vouloir l'enduire de goudron et de plumes. Donc :
Est un problème dans un parc conséquent avec un environnement mouvant. N'est pas un avantage. Et s'il veut "reprendre le contrôle total", ben il "upgrade son skill".
Bon, ceci dit, cet argument en faveur de systemd peut être retourner en compensant ce défaut de sysV par une bonne centralisation des confs, et des "meilleures pratiques" bien respectées. Mouhai, j'ai quant même un doute.
Su ce point là, précis, le sysadmin que je suis vois dans systemd une sacrée belle avancée. (après, pour le reste, sur dbus surtout, je ne sais pas)
[^] # Re: Mouais
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Personnellement, j'ai toujours trouvé que les scripts chez Debian était globalement propre et concis.
[^] # Re: Mouais
Posté par gnumdk (site web personnel) . Évalué à 5.
Regarde ceux d'un BSD/ArchLinux/… et on en reparle ;)
# Outil spécialisé vs générique
Posté par drakmaniso . Évalué à 4.
Tu oublies une chose: lorsqu'un outil cible des utilisations radicalement différentes, il doit se limiter au plus petit dénominateur commun. Si on veux autre chose que le compromis mou inhérent aux outils génériques, il faut différencier, spécialiser.
Oui, systemd est orienté bureau, tant mieux. La plus grande partie des changements apportés par systemd m'intéressent, ils correspondent bien à mes besoins. À l'inverse, certaines contraintes liées aux serveurs peuvent me gêner.
Personne n'a besoin de sacrifier quoique ce soit: à chacun de choisir l'outil adapté. Si les distribs font leur boulot, elles ne se précipiteront pas toute sur systemd, et chacun trouvera son bonheur.
[^] # Re: Outil spécialisé vs générique
Posté par Misc (site web personnel) . Évalué à 10.
Au contraire, je trouve que systemd est plus orienté serveurs. Y a 10 articles sur "systemd pour les admins", et je pense que l'utilisateur de bureau s'en fout de pouvoir limiter les demons dans un chroot ou un container lxc, s'en fout de pouvoir remonter tout ou parti de / en readonly, s'en fout de pouvoir lancer proprement 15 instances d'openvpn sans faire des trucs moches comme copier le script d'init à la main. Alors qu'un admin, je pense que ça l'intéresse ( en tout cas, moi, ça m'intéresse ).
# Don't feed the troll
Posté par Aissen . Évalué à 5.
Bel appeau à troll, tout y est: traduire un article vieux de 10 mois (il y a plus de 15 releases de systemd dans l’intervalle), faire un procès d’intention (Lennart s’en fout des serveurs), classique résistance au changement.
Cela ressemble au chant du cygne d’un admin qui n’a pas envie de tout réapprendre ni monter en compétence pour utiliser un outil plus performant.
Si systemd était si pourri et gênait tant de gens, ils pourraient unir leur ressources et faire leur propre distro "propre" (à la slackware), sans systemd. À moins que ça ne soit plus facile de bloquer son arrivée dans Debian (oups, troll inside).
[^] # Re: Don't feed the troll
Posté par zebra3 . Évalué à 2.
Raté, il est déjà dans testing.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Don't feed the troll
Posté par Aissen . Évalué à 1.
Évidemment ça je le sais. Je parle d’intégration plus profonde, avec des unit/service files pour tous les paquets, et une petite référence aux derniers déba^W trolls sur debian-devel ;-)
[^] # Re: Don't feed the troll
Posté par Guillaume Knispel . Évalué à 5.
Pour référence, je suis pas admin du tout (enfin bon, disons je suis admin à 2% dont 1% des 2% à gérer des trucs de boot) mais ingé travaillant en ce moment dans le logiciel de base + électronique, j'ai simplement trouvé l'opinion intéressante même si assez, hm, disons "forte", et susceptible de générer des débats et des opinions contradictoires venant largement contrebalancer le parti pris initial, ce qui n'a pas manqué de ce produire.
Mon opinion perso est que je trouve que systemd va trop loin en s'écartant du KISS et que D-Bus… sérieusement ?—mais j'avoue que dans certains contexte je pourrais fort bien m'en servir. Honnêtement apprendre à s'en servir doit être plutôt rapide.
Enfin je trouve même que sur certains de ses arguments Leszek Urbanski était, disons, léger.
Concernant le nombre de versions de systemd ayant été publiées entre l'article d'origine, ça n'enlève rien au fond qui traite de l'architecture et de la liste de ce que systemd veut gérer. Concernant la structure de la phrase citée, elle confond implicitement le traducteur et l'auteur d'origine.
Le travail de traduction m'a pris je pense un peu plus d'une heure. (Voire peut-être deux, je sais plus trop.) Si j'avais voulu écrire mon opinion perso sur le sujet, un tel temps m'aurait permis de le faire plus directement. Mais je n'ai pas autant de choses à dire.
En tout cas j'ai trouvé certaines argumentations en commentaire de ce journal assez intéressantes, donc de mon point de vue mon appeau à troll c'est révélé aller au delà de mes espérances sur ses fonctions.
# J'ai pas d'avis
Posté par Axone . Évalué à 7.
Je n'ai pas d'avis sur systemd (pareil que grub2) car il y a tellement d'options et de possibilités qu'il me faut le PDM (putain de manuel), mais je n'ai trouvé que TFM (the fucking manuel).
Je n'ai pas encore touché à systemd, mais il y a quelques semaines, j'ai touché pour la première fois à grub2. Je voulais changer l'os par défaut au démarrage. J'ai mis beaucoup de temps pour ce simple changement. La documentation en format PDF fait 106 pages ! Gloups.
Entre Grub2 et systemd, va falloir être un expert pour le démarrage de sa machine…
[^] # Re: J'ai pas d'avis
Posté par Misc (site web personnel) . Évalué à 3.
En même temps, grub2 fait beaucoup plus de choses. par exemple, il est capable de comprendre directement le lvm et le raid, ou les disques durs chiffrés. Et je pense que la difficulté viens pas tant de grub2 que du script d'auto détection des os qui est mis par défaut par les distros ( script fourni upstream ).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.