Les libristes (selon ma définition), voient plus loin que le logiciel : le logiciel n'est qu'un moyen por eux de participer à ce mouvement (parce que le logiciel est leur spécialité et qu'ils peuvent apporter leur compétence dans ce domaine et laissent à d'autres le soin de combattre sur d'autres fronts).
Sans vouloir rentrer dans une guerre de définitions (qui serait de toute façon stérile), on peut être libriste (à mon avis) sans pour autant sortir du cadre strict du logiciel.
Il y a trois aspects (toujours à mon avis) qui définissent le libriste :
La participation au LL (que ce soit par contribution de toutes sortes, promotions, publicité etc.)
La défense du LL existant (lutte contre les patents-trolls, financement, actions juridiques etc.)
La défense du LL en général (lutte contre les lois, habitudes et régulations qui étranglent et cherchent à faire disparaitre ou à exclure le LL - volontairement ou non)
Le dernier aspect est extrêmement vaste puisqu'il nécessite une surveillance constante de type lobbying. Donc des actions politiques, des débats législatifs, des groupes d'influences et des mobilisations de masse juste pour permettre au logiciel libre de continuer à exister et à couvrir tous les domaines essentiels de l'informatique moderne (de la lecture de blu-ray à la libre concurrence sur le marché des maquettes numériques d'immeubles (BIM))
Donc même en ayant comme seul et unique objectif le logiciel, on se retrouve quand même à participer de façon assez large à la vie publique d'un pays.
Comme on peut être libriste et refuser le délire "ne rien en avoir à foutre des caméras revient exactement à ne rien en avoir à foutre de la vie privée, de l'annonymat, de la non surveillance, de la démocratie, de la connaissance etc" qui est n'importe quoi.
Non on ne peut pas. Tout d'abord parceque ce n'est pas un délire. On parle de droit fondamental non pas au sens moderne "Vachement super important trop bien", mais au sens premier : droit qui sert de fondation. Ne rien en avoir à foutre des fondations c'est ne rien en avoir à foutre de l'édifice qui repose sur ces fondations. Ce jemenfoutisme peut avoir deux causes : soit un réel détachement vis à vis de l'édifice, soit une croyance naive en la survie de l'édifice même si on commence à abbattre des murs porteurs. Mais que ce soit par désintérêt ou par ignorance le résultat est le même : si on attaque le support d'un élément il a tendance à s'effondrer.
Le libre inclut, il n'exclut pas. Pas très libriste que de refuser les gens qui n'ont pas les mêmes opinions sur des sujets différents…
Déjà le libre exclu. Par essence une personne qui ne fait que des logiciels propriétaires, ne partage rien avec la communeauté et n'a de cesse de vérouiller ses clients pour les empêcher de migrer vers des solutions concurrentes est exclu. Il ne s'agit pas d'une démarche active de la communeauté libre qui va chercher à ostraciser celui qu'ils considèrent comme un ennemi, mais d'une pure séparation structurelle. De même qu'une personne qui mange régulièrement de la viande par choix conscient ne peut en aucun cas être considéré comme végétarien. Ce n'est pas une kabale initiée par les membres extremistes de la communeauté, c'est juste la définition de la communeauté : végétarien = pas de viande si on a le choix.
De la même façon, être libriste a un sens. toutes les personnes qui contribuent au libre ne sont pas forcément libristes de même que toutes les personnes qui mangent de la salade ne sont pas végétariens. Il existe des pelletées de devs qui bossent dans des boites qui contribuent au libre, tout en trouvant les concepts du libre complètement cons. Il font celà pour gagner leur croute. On trouve dans le monde libre aussi bien des devs qui débutent en SSLL parceque c'était proche de leur appart que des sociétés qui utilisent le libre comme argument marketing pour se faire mousser sans pour autant penser un seul instant mettre quoi que ce soit de sérieux dans la version "communeautaire" de leur logiciel, que des grands pontes embauchés par Google ou Yahoo pour bosser sur des produits libres et qui n'ont choisi ce poste que parceque la paye était meilleure à l'exclusion de tous les autres facteurs ou presque. Donc libriste ne veut pas dire utilisateur/contributeur du libre.
Après on peut sortir des centaines de définitions de libriste et pinailler pendant des heures sur laquelle est la meilleure, mais techniquement je ne crois pas qu'il soit possible de définir libriste sans apporter les notions suivantes :
le libriste est volontaire, i.e on ne devient pas libriste par accident ou opportunisme
le libriste défend (plus ou moins activement nous sommes d'accord) le logiciel libre. C'est à dire la possibilité d'écrire des logiciels dont le code source est disponible et qui sont librement diffusable, étudiable et modifiable.
le libriste est sincère dans sa démarche, ie il est libriste car il pense que le logiciel libre apporte quelque chose à son entourage (voire au monde entier ca dépend de la qualité des contributions et de la taille des chevilles.)
Le second point nécessite d'être concerné par les caméras et par le respect d'un certain nombre de prérequis (la plupart des dits prérequis étant d'ailleurs dans la déclaration universelle des droits de l'homme).
Je suis libriste, mais les caméras je m'en fous (en fait pire : je trouve ça utile)
Trouver les caméras utiles est très loin d'être pire que de s'en foutre. On peut être libriste et trouver les caméras utiles (c'est à dire avoir réfléchi à la question et avoir de bonne foi estimé que la qualité de vie supplémentaire apportée par les caméras apporte plus de sérénité et de liberté que leur absence - à savoir que l'on est pas encore au moment ou les caméras portent atteinte aux individus). Le problème est vraiment vis à vis de "s'en foutre".
Peut-être qu'un jour les libristes contre les caméras comprendront que tous les libristes ne sont pas contre les caméras (ils s'en foutent comme le reste de la population)
Malheureusement ce n'est pas possible. Vois-tu le socle fondamental d'un certain nombre de choses (au hasard la liberté d'expression et le droit à l'intimité et à la vie privée) reposent justement sur le droit à l'anonymat et à la non immixion dans sa vie privée. Comme c'est sur ces droits là que reposent d'autres choses telles que la démocratie, la liberté d'association, la libre circulation, le droit de prendre part à la vie politique, le droit d'accéder et de diffuser la connaissance et j'en passe, ne rien en avoir à foutre des caméras revient exactement à ne rien en avoir à foutre de la vie privée, de l'annonymat, de la non surveillance, de la démocratie, de la connaissance etc.
Dire "Je suis libriste, mais les caméras je m'en fous" est un contre sens. On peut être utilisateur, et même auteur de logiciel libre et n'en avoir rien à foutre des caméras, mais si on est libriste on est forcément concerné par les caméras.
La présence de caméras, et donc de surveillance et plus encore la possibilité impromptue de cette présence sans déclaration claire entrainne nécessairement une atteinte à un des droits fondamentaux. Une personne qui se sait surveillé, ou qui sait qu'elle peut être surveillée à n'importe quel moment n'aura pas un comportement, une expression ou une pensée aussi libre que si la garantie de non immixition dans la vie privée est certifiée.
En bref toutes les personnes qui sont concernées par les caméras ne sont pas des libristes, loin s'en faut, mais tous les libristes sont nécessairement concernés par la libre expression, la libre pensée et la libre circulations des connaissances et donc par les caméras.
Ensuite, pour le DNS, le DNS étant décentralisé, le domaine de M. Michu (mettons mmichu.fr) ne se trouve pas dans les serveurs racine et ne peut donc pas en être retiré.
Oh non Stephane, pas toi ! Je t'accorde bien volontiers la caricature de mon poste (j'avais pas envie d'écrire un article didactique de 20 pages - surtout que d'autres (toi par exemple) le feraient bien mieux que moi. J'avais juste envie de passer un message sur la main mise américaine sur le sujet).
Donc caricatural d'accord - mais au niveau des erreurs je ne pense pas qu'il y en ait beaucoup.
En ce qui concerne les IP (ou plus précisément le routage des IP) c'est clair que la probabilité pour qu'il y ait une action est faible - En partie parce que les IP sont gérées par plusieurs groupes, en partie parce que ça pousserait les gouvernements non américains à se poser de bonnes questions (et dieu sait qu'il faut éviter ça à tout prix) et en partie surtout parce qu'il y a de gros morceaux du routage internet ou plus personne ne sait trop comment ça marche (ils ont une idée hein, mais ils ont pas envie de la tester en prod là tout de suite là maintenant) et que retirer des blocs IP d'une zone pour les mettre dans une autre ca pourrait avoir des effets de bords assez désagréables.
Ceci étant techniquement rien n'empêche l'IANA de déplacer un bloc IP d'une zone à une autre. (Ils l'ont d'ailleurs fait il y a pas trop longtemps pour que l'Afrique dispose d'autre chose que d'un /24). Bien sur rien n'oblige les ISPs et les transitaires à suivre. Ils peuvent décider d'ignorer les demandes de modifications et continuer à router et à peerer comme avant. Mais déjà tous les tiers 1 américain se mettront au pas, je ne vois pas trop Tata faire de la résistance. Il va rester qui ? Deutsche Telekom et NTTC ?
On est d'accord que politiquement ça ne se produira probablement jamais et que le RIPE NCC en Europe met déjà des mois à réagir au vol ou à l'abuse de plages IP (les listes DROP n'ont pas été crées par hasard) - mais techniquement c'est faisable et légitime.
En ce qui concerne les entrées DNS, ICann et Verisign ont de bons moyens d'action.
Tout d'abord effectivement personne ne connait le domaine de madame Michu "michu.fr", donc personne ne l'a en cache (à part éventuellement le registar de madame michu), donc si on met le domaine de madame michu dans les root DNS avec un pointeur vers une fausse adresse, plus personne n'accède à michu.fr à part peut être les gens qui sont sur le même réseau que sont serveur autoritaire et éventuellement son registrar.
Il ne s'agit pas ici d'enlever le nom des root DNS, mais au contraire de l'y ajouter. Après on fait deux trois déclarations et une contre propagation et en deux heures montre posée sur la table, l'ensemble de l'internet mondial a oublié l'ancien serveur de madame Michu, tout le monde pointe sur le nouveau serveur (vous savez celui qui dit que les gentils agents du FBI vous ont sauvé la démocratie.)
Là aussi il y a peu de chances que cela se produise. Les root serveurs c'est pas fait pour jouer avec, enfin pas trop. Mais contrairement au démapping sauvage de blocs IP, ce procédé a déjà utilisé.
L'ensemble des noms de domaines classiques sont sous controle américain. A moins de rajouter des noms de domaine "fantaisistes" et d'ajouter de nouveaux serveurs dans la liste des ROOT DNS de ta machine, il n'y a aucun moyen de couper à l'hégémonie américaine sur ce point.
Comme tu le dis, si tu veux être protégé par le droit français un peu plus, tu prends un registrar français sur un truc genre .fr, géré par l'AFNIC
Je te rassure tout de suite, l'AFNIC n'a qu'une délégation. Si au nom du droit américain un juge américain veut saisir un nom de domaine en .fr d'une société française basée en France ça reste tout à fait faisable.
Il peut également obtenir le déroutage de ta/tes plages IP et le retrait des entrées te concernant des root DNS (ou une contre propagation depuis les root DNS vers une IP qui n'est pas la tienne.)
En théorie il faut passer par l'ICANN pour faire tout ça, mais en pratique un coup de fil à Verisign et ca va être réglé rapidement.
Après pour te sucrer tes adresses IP elles-même il faut passer par l'ICANN (mais comme l'ICANN a tendance à ne pas faire n'importe quoi n'importe comment, le département du commerce américain a bien limité leurs pouvoirs au maximum.)
J'ignore si cela peut résoudre les problèmes que tu rencontres : des utilisateurs non-root peuvent créer, lancer et stopper des unités systemd.
Oui, mais seulement dans leur session. En d'autres termes l'utilisateur Nagions ne peut pas interragir avec le programme lancé par l'utilisateur Nginx sans être route. Et ce même si l'utilisateur Nagios aexactement les mêmes droits que l'utilisateur Nginx.
Le but du jeu ici est de pouvoir interragir avec des units systèmes, pas des units session.
T'es pas obligé de lancer un signal KILL, non plus.
Peut importe le signal que je lance, il faut que ce soit interprété comme un fail par systemd. (Si je mets le service en restart même sur un status de sortie correct, ca veut dire que je ne peux plus jamais arréter le service à moins d'éteindre la machine.)
A partir de là, a part sigkill, sigterm et sigint j'ai pas grand chose.
Si le process est solitaire, un sigterm peut permettre une sortie en douceur si tout va bien, mais si il y a plusieurs processus ou que sigterm ne suffit pas il faut y aller plus fort. Et là le fait que mon service secondaire ne soit pas l'init que les différentes infos ne soient plus logguées comme avant et qu'elle ne soit pas accessible facilement par un processus non root peut entrainer des problèmes.
Tu as plusieurs politiques dans systemd en jouant avec Restart et SuccessExitStatus tu devrais pourvoir faire en sorte que systemd relance le service quand quand tu le souhaite.
Pas vraiment non. Si c'est le service "moniteur" qui envoie un sigkill, je veux que le service monitoré redémarre. Par contre si c'est moi qui envoit le sigkill je veux que ce soit pris en compte comme un ordre définitif. Généralement je ne fais pas de sigkill, mais quand j'en fais un c'est pas pour que le processus soit relancé immédiatement.
Et l'action de Nagios ça ne peut pas être de simplement tuer les processus à relancer ?
Pour certains services problématiques, c'est déjà le cas aujourd'hui, mais après avoir tenté plusieurs fois une extinction propre via les commandes init.
J'ai l'impression que ce qui te pose problème ça n'est pas l'architecture de systemd, c'est juste que son API dBus ne serait accessible qu'à root (ce qui me surprends).
D'un autre coté, le fait que le bus systeme avec la target qui controle tous les services ne soit acessible que à root n'est pas franchement choquant.
Ce qui est plus embétant c'est que systemd ne possède aucun moyen de lui passer des paramètres dynamiquement que ce soit à l'init ou pendant la vie du service.(j'ai bien dit "des" je sais qu'on peu en passer un via @ à l'init.)
Je ne serai pas aussi négatif si il y avait les fonctions suivantes dans systemd
- Un moyen de lancer plusieurs fois la même unit avec des paramètres différents (ex : /etc/init.d/startvirtualnet --ip=192.168.200.0/24 --with-dhcp=192.168.200.1 --vinterface=vl12)
- un moyen de balancer des messages au service en cours d'éxecution (ex: /etc/init.d/service --rehash --reindex)
- un moyen d'autoriser des services non root à lancer les deux types de commandes ci dessus.
A l'heure actuelle pour chaque service lancé par systemd je suis obligé de chopper le PID au vol et de le stoquer pour pouvoir balancer les commandes directement, d'enregistrer et de détruire des units à tour de bras et le tout en faisant gaffe à ce que systemd ne prenne pas mal ce que je suis en train de faire.
Le reste ça me semble plutôt intéressant de faire gérer les services via un seul point (systemd) qui va gérer ça aussi proprement et de manière aussi centralisée que possible.
La question est limite philosophique, mais je ne considère pas que gérer un service se limite à le lancer, le logguer et à l'arréter. Pas mal de service son des options que l'on peut régler dynamiquement, tant que l'on ne peut pas les gérer depuis systemd, on se trouve à écrire des gestionnaires secondaires pour faire tout ce que systemd ne gère pas.
Tu peux avoir un service qui fait ça. Il vérifie le processus comme tu le souhaite, puis si vraiment il y a un problème il le dézingue et systemd le relancera.
Déjà j'aime pas trop "dézinguer" un service qui tourne, même si avec systemd il y a un relatif ménage derrière qui évite les zombis et les processus fils qui trainent (Mais qui n'évite pas forcément la rémanence de données inutiles dans les applis connectées à ce service, le post-traitement n'est pas appelé etc.)
Autre effet désagréable si on relance le service de cette façon, systemd va compter un "fail". Donc pour que le service soit relancé à chaque fois, il faut configurer systemd pour qu'il relance le service systématiquement. Ce qui n'est pas sans effet de bord quand le service se met vraiment à merder tout seul comme un grand.
Ensuite, c'est bien beau pour un service, mais pour deux cents ca devient pénible. Si on décide de faire des procédures différentes par client, de modifier toute sles procédures de surveillance, de changer temporairement une procédure (par exemple le client prévient qu'il y aura une forte charge et/ou des tests pendant une semaine) etc. Ben tu as deux cents services à mettre à jour. Quand c'est fait depuis Nagios, tu as une règle à changer - tu es sur de ne pas oublier de règle puisque tout est centralisé etc.
Finalement à ce compte là autant avoir un script à l'ancienne qui essaye au moins d'arréter le service proprement, tout en faisant la nique à systemd. Mais ca n'est pas possible avec tous les services (des que l'on touche au réseau en dehors de networkd, il se passe des choses indésirables). Pendant qu'on y est on va même carrément mettre ce script comme cible de l'unit systemd - comme ça systemd lance un script qui à son tour lance le programme voulu. Un émulateur sysV en quelque sorte - mais avec une interface de plus.
L'option Restart des units ne suffit pas pour ça ? Avec la possibilité de conditionner le restart et la possibilité de lancer une commande avant le démarrage du service pour récupérer l'état de la machine lors du restart.
Les watchdogs de systemd sont pas mal pour les cas faciles. Mais c'est assez compliqué d'écrire des règles pour shooter les processus PHP seulement quand il y a une fuite de mémoire ou une boucle infinie. Il y a des raisons tout à fait valable pour que le PHP se mette à bouffer le CPU ou de la mémoire comme un goret sur des périodes de temps plus ou moins longues. Avant d'utiliser le shootgun il faut vérifier que la consommation est constante, que la mémoire ne baisse pas significativement de temps en temps (utilisation en dent de scie) etc.
Donc on polle toutes les cinq/dix minutes, si ca dépasse systématiquement les quotas on polle toute les trente secondes, puis surveillance intensive et enfin shootgun.
Les watchdogs systemd n'ont pas (en tout cas pas encore à ma connaissance) la capacité à passer d'une règle de surveillance à l'autre en fonction des résultats.
C'est pas une question de configuration DBus ça ?
Jusque récemment il était impossible d'envoyer un message au dbus system vers systemd avec autre chose que root non limité. Maintenant il est possible de limiter root pour autoriser seulement certains types de messages sur certaines units de systemd. Mais je ne crois pas qu'il soit possible de passer des messages si l'on n'est pas root.
Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine
Ca fait un petit moment qu'on évalue les différentes beta. Mais je te rassure on a encore rien en prod - et pour l'instant la question est plus "est-ce que" que "quand".
La doc officiel comme ça :
Il s'agit ici de modifier un la configuration d'un CGroup donné. Pas de placer un processus dans un autre cgroup que celui par défaut ou encre de déplacer un processus d'un cgroup à l'autre. (à ma connaissance le kernel ne permet de toute façon pas le déplacement à chaud en ce moment.)
Par exemple si tu veux mettre tous les processus d'un client au sein d'un même cgroups pour pouvoir contrôler les ressources en un seul point central - ben c'est compliqué.
Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.
J'ai bien conscience d'être assez difficile à suivre vu que a) je n'ai pas franchement des problèmes communs (systemd marche très bien 95% du temps) et que b) je ne peux pas franchement donner d'exemples concrets pour cause de contrats à la con. J'avoue que ça n'aide pas.
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Je parle en mode hyperviseur. Bien sur tu testes avant de passer en prod, bien sur tu audites pendant un moment avant d'ajouter la règle en dur (IE tu passes quelques semaines avec setenforce à permissive - c'est ce que je voulais dire par mode "audit only") Mais à un moment ou à un autre il faut bien passer en vraie prod. Et là parfois pour tout un tas de raisons (fin de mois, mise à jour des logiciels du client, changement du sens du vent - que sais-je) le container va faire une action ou avoir besoin d'une ressource que tu n'avais pas prévu. Et là on repart en permissive, on récupère le container client à la pince à épiler (parceque bien entendu c'était pendant une écriture en base de données que le bug a eu lieu - sinon c'est pas drole - et bien entendu la base c'est pas Postgresql - c'est une grosse base de données commerciale qui vit très mal le fait de plus pouvoir écrire sur le disque d'une seconde à l'autre). On fait de plates excuses au client. Une fois, deux fois et puis on arrête SELinux.
Alors ca c'est ennormément amélioré au cours des trois dernières années (et on a appris de nos erreurs aussi) mais ca reste un sujet sensible (chat échaudé toussa.)
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Quelques temps - ca fait moins d'un an. Je crois que l'annonce de Lennart date du 21 juin 2013. On savait déjà que les cgroups allaient être unifiés (et c'est une bonne chose) mais le coup du controleur unique accessible uniquement via DBus ca fait bizarre.
Ca fait bizarre pour deux raisons :
- la première c'est qu'un processus acquiert son cgroup au lancement, et là soit il se retrouve dans le même cgroup que son père, soit on veut le mettre dans un autre cgroup. Mais si on veut le mettre dans un autre cgroup il faut être capable de dire à systemd d'une façon ou d'une autre "attention le prochain processus que je vais lancer doit aller dans le cgroup /bidule/truc" parce que une fois que le processus est lancé c'est rapé (du moins jusqu'à ce qu'on puisse balader un processus d'un cgroup à un autre.)
A partir de là il faut bien s'assurer que la session depuis laquelle on est ne va pas lancer un autre processus avant celui que l'on veut mettre en cgroup. C'est extrèmement facile à faire pour un service qui s'initialise, mais pour une session utilisateur ou encore pour une commande lancée par uns ervice après initialisation c'est tout de suite plus complexe, il faut bien faire attention aux conditions de courses et autres ratage de lancement (par exemple si je prépare un cgroup, mais que mon processus ne se lance pas - on fait quoi ?). Reste la solution de créer une nouvelle session par processus - Mais ca peut devenir assez problématique assez vite.
- la seconde est liée au comportement même des cgroups en mode comptabilité. Si j'utilise les cgroups pour mesurer la consommation de ressources de mes processus (très utile quand un client a l'habitude de faire du while 1 fork; sans le vouloir). A aujourd'hui, mon appli avec son propre temps CPU peut checker la consommation quand elle le veut. Mais demain si tout passe par DBus je me fais un peu de soucis, parceque gérer 3000 processus qui vont venir le questionner à tour de rôle ca peut être lourd à digérer.
Maintenant il s'agit juste de réflexions en me basant sur l'existant et sur ce qui a été dit. Ca me casse les pieds de faire évoluer mes archis pour prendre en compte les nouveaux cgroups, mais ca n'est pas fondammentalement mauvais. J'attend de voir ce qui sort pour donner un avis plus complet sur la question.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Il ne s'agit pas de faire faire du correctif à Nagios (Même si c'est faisable, et même plutôt salvateur sur certaines config, on va pas déranger un admin à chaque fois qu'il faut relancer un php??-?gi, on a pas les moyens d'embaucher assez de monde) - mais plutôt de pouvoir déclencher facilement des sondes supplémentaires quand un comportement anormal est détecté.
Typiquement je surveille le temps d’exécution moyen d'une requête. Et quand il augmente je lance d'autres sondes pour savoir si ca vient de grosses requêtes qui sont lancées, des I/Os qui foirent ou de la mémoire vive qui est pleine. Comme ça je lance un minimum de sondes et je ne passe sur des sondes plus fortes que si le besoin s'en fait sentir et seulement là ou j'en ai besoin.
Pour la majorité des sondes il suffit de chopper les logs et/ou se connecter via un canal spécial à l'appli en mode client. Pour d'autres sondes il faut aller triffouiller plus loin ce qui implique soit un reload de la config du serveur qui pose soucis, soit le chargement de certains modules par l'appli,soit carrément un restart avec une autre config.
Tout ceci se faisait avant très simplement en ligne de commande en balançant des commandes de type
/etc/init.d/monservice -reload -with module2 -activate stacktrace -verbosity 5 Sur l'ensemble des commandes "de l'ancien temps" il n'y a guère que le reload que je sache faire passer aujourd'hui et encore en ayant les droits root (que ce soit via DBus ou via systemctl reload, restart, start, stop, enable et disable nécessitent les droits root sinon => Access Denied).
Ce n'est pas que je n'aime pas la nouvelle méthode - c'est que je ne la connais pas. Et j'ai beau chercher et ouvrir des tickets chez RH je n'ai pas encore eu de réponses satisfaisantes. (parceque très honnêtement modifier les pre,env et les posts d'un fichier unit avant de le réenregistrer et de faire un restart n'est pas une réponse satisfaisante).
Oui, il y a cette solution, mais elle implique une bonne baffe en performance (10 à 15%) lors de mes tests, le 7% annoncé par fedora me parait très optimiste. En plus SELinux c'est quand même pas évident à gérer et très facile à casser (ce qui en langage hypervisuer veut dire plus personne ne peut rien faire tant qu'on a pas rebooter la machine en single user et passé SELinux en audit only). Comme les modifications ne s'appliquent qu'au redémarrage dans la plupart des cas, on a assez fréquemment de mauvaises surprises.
Perso, j'étais plutôt parti sur le quinca qui a pris ses habitudes, n'aime pas qu'on les lui change et surtout se retrouve à égalité technique avec les post-ado qui arrivent et maitrisent mieux les outils modernes, et ça lui fait mal à l'égo (la personne a de l'expérience! faut pas déconner…) alors il va chercher n'importe quelle petite bête pour se justifier.
Tiens un autre quinca qui a du mal à suivre toutes les évolutions Linux et qui rale plutôt que d'apprendre :
Il y en a un paquet qui tombent régulièrement. La nécessité d'être root pour la majorité des opérations + la centralisation des méthodes de sécurité + la compelxité polkit/consolekit + … font qu'il risque de falloir un bon moment avant qu'il n'y ait pas deux ou 3 CVE par jour. (Rien que sur le bugzilla RH il y a eu plus de 5000 CVE systemd/udev don certains CANT et WONTFIX qui ne me donnent pas confiance.)
Hum, systemd est incapable de lancer un processus avec un autre utilisateur que root ? Ou alors je ne comprends pas.
Non le problème c'est qu'un service qui est lancé avec autre chose que le cgroup le plus haut hierarchiquement et des droits root ne peut pas auditer/interragir/démarrer/redémarrer un autre processus. Ca n'est juste pas acceptable. J'ai besoin que Nagios (par exemple) puisse démarrer tout seul comme un grand nombre d'autres services, lesquels services doivent pouvoir interagir avec les services critiques, le tout surtout sans être root. C'est la base de l'admin système : on a des sondes qui tournent en permanence , mais pas beaucoup parceque les ressources sont pas gratuite. Et quand on a un soucis on doit pouvoir lancer d'autres services ou sondes qui vont essayer de diagnostiquer le problème - soitpour le corriger automatiquement (rare) soit au moins pour que l'admin n'ait pas à lancer 200 commandes à la queue leu leu pour se faire un idée de la situation.
Il faut aussi en cas de pépins pouvoir remonter des infos aux utilisateurs/à la production/aux admins services pour qu'il puissent réagir etc.
Tout n'est pas forcément accessible depuis les logs, et je vais pas refiler les droits root aux services qui créé le tableau de bord du client…
Après c'est comme tout quand tu fais tomber un goulot d'étranglement tu en a un autre qui apparaît, mais c'est pas pour ça que ça ne sert à rien de l'avoir supprimé.
Mais il n'y a pas de goulot d'étranglement à ce niveau là. Je ne peux pas faire un diagnostique de mon data-center toute les minutes ce serait ultra consommateur de ressources pour rien - et d'un autre coté dans le cadre d'un cloud elastique je ne peux pas non plus demander au client de patienter une minute à chaque fois qu'il fait une modif ou qu'il passe d'un status iddle à un status plein régime. Donc l'ensemble du problème de consommation électrique ou de densité des data-center repose sur l'anticipation des admins et les optimisations du data-center. Le temps de boot d'une machine - dans la mesure ou il reste très inférieur au temps de mise à jour du status du data center ne rentre pas en compte.
Si je mets 8 minutes à mettre à jour le "load" de mon data center (ce qui sera déjà une performance - ou alors un gaspillage de performance suivant comment c'est fait), je ne vais pas attendre tout ce temps pour me dire "tiens ? On est plein il faudrait peut-être lancer un nouvel hyperviseur/monter des réseau virtuels des fois que la charge augmente". Comparé à ces huit minutes d'anticipation obligatoires (et encore une fois poler un datacenter complet en 8 minutes ca demande un certain doigté) les 4 secondes que va me faire gagner systemd au boot je m'en cogne. Le temps de boot de l'init c'est le 6 ème chiffre après la virgule d'une opération sur trois chiffres significatifs.
Ou alors j'ai mal compris , ou alors tu extrapoles largement, mais c'est pas du tout ce qui est dit.
Déjà de base le texte est de mauvaise foie (je pense que c'est assez évident). Il s'en trouvera toujours pour penser que j'ai 14 ans et que je parle de systemd pour passer ma période pré-ado (bonjour Misc _o/ ), mais dans le fond, même si je n'utiliserais pas systemd avant qu'il y ait eu de gros changements (c'est à dire probablement jamais, parti comme c'est) je n'ai pas de ressentiment particulier vis à vis du logiciel.
Pour être clair je considère que systemd est comme internet explorer 5.0, ca rend service à pleins de gens, en surface c'est facile à mettre en oeuvre et à utiliser et ça juste marche pour 90% à 95% des cas. Maintenant c'est aussi un nid à bugs et à trous de sécu, et les 5% de cas ou systemd ne marchera jamais font qu'il est bon à mettre à la poubelle d'après moi. En tout cas pour l'utilisation que j'ai de l'outil informatique au niveau professionnel, non seulement il ne me sert à rien, mais en plus il est fondamentalement incompatible avec mon métier. (Par exemple il est hors de questions que mes sondes actives ou que mes watchdogs choppent les droits root. Donc soit je ne monitore pas, soit je n'utilise pas systemd - le choix est très vite fait.)
Revenons en à la question qui nous interresse
On a cette phrase là (je prend la traduction pour aller vite)
Pour les configurations dans les nuages avec un nombre important de machines virtuelles ou de conteneurs, le cout d’un démarrage lent est multiplié par le nombre d’instances. Passer plusieurs minutes de temps CPU et d’entrées/sorties sur des démarrages très lents de milliers de machines virtuelles ou de conteneurs réduit la densité de votre système de façon importante, cela vous coute même plus d’énergie. Un démarrage lent peut vous couter beaucoup d’argent, alors qu’un démarrage rapide permet d’implémenter une logique d’activation de conteneurs par socket pour augmenter la densité de votre système dans les nuages.
En substance ce qui est expliqué ici (très lentement, parce que les admins à qui ont confie des datacenters contenant plusieurs milliers de conteneurs sont rarement très malins) c'est le principe de la loi d'Erlang du temps d'attente - à savoir que de façon générale (à adapter en fonction des situations bien sur) un système servant plusieurs clients n'a pas besoin de disposer d'assez de ressources pour servir tous les clients en simultané. Typiquement si vous avez 50 employés et que vous n'êtes pas un call-center, dix canaux téléphoniques c'est suffisant.
Pour les VMs c'est pareil, pour peu que l'on arrive à mettre à disposition une VM assez rapidement, pas besoin de faire tourner toutes les VMs (ou conteneur) tout le temps, il suffit de lancer la VM au moment ou elle est demandé. Donc moins de charge CPU, moins de courant électrique, un datacenter plus dense etc.
Sauf que ça ne marche pas tout à fait comme ça.
Il existe (grosso-modo) trois grand types de VMs/Conteneurs dans le cloud.
- Les VMs pour faire du calcul
- Les VMs pour faire du traitement de données
- Les VMs pour faire du stockage de données
Plus un type hybride des trois : les serveurs dédiés virtuels.
Les VMs pour faire du calcul démarrent généralement en un temps record. Il s'agit le plus souvent d'OS ultra-dépouillés dont le seul rôle est de répondre le plus vite possible à un serveur maitre, donc avec un temps de boot minuscule. C'est généralement mis en place sur des très très grosses machines avec des quantités de ram délirante (le petit octo-déca coeur avec 2TO de mémoire vive est assez populaire). Elles vont être louées par paquets de 200/300 tranches pour plusieurs jours, voire semaines. Généralement la personne qui gère ce type de machine est prévenu plusieurs semaines à l'avance. (Que ce soit l'industrie du cinéma ou celui de la recherche, entre le moment ou le contrat est signé et celui ou l'argent est arrivé et ou les comptes sont ouverts il s'écoule un moment.) De toute les façon que ce soit coté client ou coté exploitant tout le monde se fout royalement de la demi-seconde gagné par une VM à booter sur systemd.
Les VMs pour faire du traitement de données sont principalement orienté de façon à minimiser les I/Os. Généralement ce sont des machines avec une grosse quantité de mémoire (pour pouvoir stoquer les index) et des I/Os disque ultra optimisés. Le but étant bien sur de pouvoir processer un flux d'information assez conséquent à toute allure. Sur ce genre de VM, le temps de boot est très négligeable comparé au temps de rapatriement des données/mise en place du flux et au temps de calcul des index. Donc toujours pas d’intérêt majeur à utiliser systemd (et totu ca sans même parler du temps nécessaire pour faire le sharding des données ou le fencing des machines si l'application le nécessite)
Les VMs pour faire du stockage de données sont généralement en fait des partitions de serveurs de fichier. C'est à dire qu'un service central (Mongo, Hadoop, Riak etc. ) sert plusieurs dizaines voire centaines de client finaux. La question de le démarrer à la demande ne se pose pas vraiment. Et une fois de plus il s'agit de serveurs très simple avec des OS très spécifiques qui vont avoir tendance à avoir des temps de boot très rapide. Ce temps de boot sera systématiquement très inférieur au temps mis par les services pour faire le mapping des données et les rendre accessibles.
Reste les serveurs dédiés virtuels, c'est à dire les produits type EC2, VPS OVH par VMWare, machines Gandi et autre google Cloud. Là éventuellement les principes de l'Erlang peuvent s'appliquer. On est sur une grande diversité de clients, avec des demandes ponctuelles et irrégulières dans le temps. Systemd possède donc un avantage ici, même si il est minime (attribution des ressources + mise en place monitoring/facturation + montages des données + initialisation de la VM et des instances fallback éventuelles >> temps gagné avec systemd). Mais le temps gagné par systemd sera très difficile à exploiter en vrai, tout d'abord parceque le temps de mise en attente toléré est très inférieur au temps de boot, même avec systemd (un serveur qui met plusieurs secondes à répondre sous pretexte qu'il n'y a pas eu de demandes depuis une heure, ca la fout mal) et ensuite parce que le temps d'usage est lui très très supérieur au temps de boot.
Généralement on va avoir un temps de mise en attente toléré de l'ordre de quelques millisecondes (entre 10 et 100), un temps de boot de plusieurs secondes (entre une et 10) et un temps d'utilisation de plusieurs heures (de 12h typiquement pour un service pro principalement utilisé pendant les heures de bureau)
Chercher à grapiller quelque chose là dedans ca va être l'horreur.
Deuxième soucis, le système va gagner quelques secondes au boot - à condition que les ressources soit prêtes. Ca c'est bien entendu le boulot de l'hyperviseur d'avoir des ressources disponibles au cas ou une demande arriverait, mais si les ressources sont disponibles on est déjà en consommation électrique "iddle" sur ces ressources.
Par exemple si mon hyperviseur est configuré pour avoir 15% de ressources préallouées par rapport au volume consommé, il aura exactement la même densité et la même consommation que ce soit en mode systemd ou init classique. Et comme je n'ai pas le temps de faire toute l'allocation à la demande (pour des raisons de temps de réponse du hardware - ouvrir une LUN sur un SAN par exemple ca ne sera jamais instantané, idem pour le temps de création d'un sous réseau virtuel avec les VLANs qui vont bien) - et bien au final ma consommation électrique et ma densité salle blanche ne bougeront pas d'un iota.
Donc dans tous les cas possibles parmis les plus fréquents, du minicloud entre potes au EC2 Amazon systemd n'apporte rien au niveau densité, consommation électrique ou vitesse de mise à disposition. Les facteurs limitants se trouvent systématiquement hors de portée des problèmes qu'un init peut résoudre.
Après l'exemple débile que j'ai donné n'a pas d'autres but que celui d'être humoristique. On se place dans un univers ou presque tout fonctionne comme Lennart Poettering le décrit (c'est à dire que tout ce que "controle" systemd, du temps de boot, au réseau, à la nécessité d'aller le plus vite possible au point que trois secondes sont salvatrices) et on regarde ce qu'il se passe juste après, et paf le SAN.
Bien sur que dans la vraie vie ca va bloquer à pleins d'endroits - le systèmes ne débloquera pas les 250 comptes simultanément, les 250 sous réseaux virtuels ne seront pas créés dans la même milliseconde, l'hyperviseur ne traitera pas toutes les demandes assez vite (si tant est qu'il en ait l'intention au début) etc.
Après tout ce démontage d'idées reçues, il est temps de remonter un peu
systemd est monolithique
Systemd est constitué de pleins, pleins pleins de binaires. Donc il n'est pas monolithique. Le fait que tous ces binaires sont fortement interdépendant n'a aucun rapport avec la choucroute. En plus dans sytemd chaque binaire effectue une tache bien définie, comme par exemple vérifier la config réseau, lancer le DHCP, simuler les connexions en attendant l'initialisation resynchroniser tout ça et balancer les résultats via DBus pour qu'il soit loggués. C'est une tache simple, fine et précise. Pourquoi ? Parceque nous avons le soucis de la sécurité, grâce à l'utilisation de bon nombre de technologies flaguées "experimental" dans le noyau nous arrivons à limiter grandement les droits dont un processus a besoin pour effectuer sa tache. Ainsi il suffit d'être ROOT pour arreter ou relancer un service, il suffit également d'être ROOT et dans la hiérarchie de plus haut niveau dans les CGroups pour pouvoir auditer un autre processus. De même en étant simplement ROOT on peut envoyer des signaux à un autre processus ou encore créer une nouvelle unit.
systemd a été conçu pour la vitesse
Pas du tout, systemd a été conçu principalement pour être propre. Comme il a été conçu et pensé intelligemment, il est en plus rapide - mais c'est juste un effet de bord de notre travail de réflexion. Ce quic ompte c'est que systemd soit super bien conçu, tellement bien conçu même que le des systèmes simples comme les logs ou le monitoring d'initialisation de périphériques n'ont entrainnés qu'une petite dizaines de bugs critiques au démarrage chacun.
La vitesse de systemd ne sert à rien pour les serveurs !
Pas du tout, déjà même sur les gros serveurs dont la partie matérielle du boot matériel peut durer plusieurs minutes, 10secondes de plus ou de moins ca peut changer la vie. Mais sur les VMs qui vont booter en quelques secondes quoi qu'il arrive et avec lesquelles ont peut faire des snapshot à chaud pour les mise à jour de toutes les façons, cette différence de trois secondes est encore plus cruciale. Sur un système qui contient plusieurs centaines de VM et qu'il faut redémarrer en urgence, ces trois secondes gagnées par VM au boot peuvent faire un total de 6 voire 8 secondes. Et puis le SAN est tellement content de voire 250 VM venir lui faire coucou dans un intervalle maximal de 2 secondes.
systemd est incompatible avec les scripts shell
Totalement faux, on peut parfaitement utiliser des scripts shell avec systemd. Du moment que ces scripts sont lancés avec les droits root, ne modifient pas l'environnement, restent cantonnés dans leur CGroup, ne cherchent ni à arréter ni à relancer le processus, et bien entendu ne cherchent pas à remonter une autre info que start, stop, reload aux units - tout ce passe très bien. (Enfin pour le premier script shell, si vous avez besoin que plusieurs scripts shells interragissent avec la même unit ca peut nécessiter l'écriture d'une autre unit, ou d'un wrapper ou les deux.)
systemd est compliqué
Alors là c'est n'importe quoi, en quoi un système qui s'appuie sur les capabilities, les cgroups, DBus, un nouveau système de log, un nouveau système de controle, un petit 500 variables kernel (dont 200+ spécifiques à Linux) le tout derrière une boite noire affreuseument simpliste, serait-il plus compliqué de lancer httpd avec l'utilisateur apache depuis un script shell ?
En plus au cas exceptionnel au systemd viendrait à vous causer des soucis, journald loggue l'ensemble des évènement de façon si claire et si concise que le kernel Linux arive presque à digérer le flux à tous les boot.
systemd n’est pas modulaire
Oui c'est le même sujet que plus haut dans la section "systemd est monolithique" mais j'écris tout d'une traite et ça me fait chier de me relire et de corriger quand je tape du texte aussi.
Donc systemd est modulaire, on peut désactiver pleins de trucs à la compilation ou à l'éxecution. Si vous le fait ca cassera surement le système, mais inutile de nous envoyer un mail pour vous plaindre - au mieux on vous répondra poliment qu'on s'en cogne. Dans systemd vous pouvez désactiver à la compilation les cgroups (mais ca casse le système) les capabilities (mais ca casse le système) passer sur une version plus ancienne de dbus (mais ca casse le système) ou encore activer le mode de compatibilité pour utiliser une libsystemd pas tout à fait synchrone avec la version de l'executable (mais…)
Bref si vous aimez linux 1.xx vous allez adorer systemd.
systemd est seulement pour les ordinateurs de bureau
Pas du tout, quand on a créer systemd on a penser à toute la gamme de produit basés sur Linux. Nous avons déjà vu ce que la vitesse de systemd apportait au serveur. Mais ce n'est rien à coté de ce que DBus+Journald logé en RAM au démarrage+les capabilites+la nécessiter de passer par systemd pour gérer les CGroups peuvent apporter au monde de l'embarqué.
systemd est un résultat du syndrome NIH
Le problème que nous avions avec notre précédent système d'init, Upstart (outre le fait qu'il ne marchait pas non plus) n'est non pas qu'il n'avait pas été inventé par Red Hat, mais qu'il avait été inventé par Canonical. Honnêtement un init inventé par Debian ou même Suse ca ne nous aura pas posé autant de problèmes. Mais là quand même….
systemd est un projet freedesktop.org
Et voilà, sous pretexte que vous êtes hébergés par freedesktop, que votre système se met à gérer toutes les notions d'ACPI, le login et de getty et que son auteur est principalement pour avoir fait deux démons purement orienté utilisateur final non professionnel - vous êtes catalogué tout de suite. Pas du tout si on a fini sur le site freedesktop.org, c'est juste parceque justine, la scrétaire du troisième connait vachement bien le gars qui change les tubes néons dans la salle serveur 4 de chez FreeDesktop. Tout de suite à se faire des idées les gens.
systemd n’est pas UNIX
D'un certains coté c'est vrai que l'on s'est un peu éloigné de la philosophie UNIX. Mais le fondamental de la philosophie UNIX est "avoir un sous système qui fait une seule chose et qui le fait bien", nous un a un macro système qui fait pleins de chose, mais que délègue à plusieurs modules qui eux font … plusieurs choses aussi, d'accord, mais on est quand même proche de la philosophie UNIX. Quand même. En tout cas on s'en inspire. Par contre pour ce qui est de faire bien, je vous déjà dit à quel point on était bien conçu et rapide ?
systemd est complexe
Bonjour, veuillez regarder le bout de ce stylo s'il vous plait
FLASH
Bien sur que systemd est complexe, les ordinateurs aujourd'hui sont complexes - et comme on veut gérer l'ensemble du système de façon monolithique il est normale que ce soit compliqué et difficile à débugguer. Pour éviter les redondance on centralise les trucs avec des effets de bords WTF à la clef. Mais c'est normal !
Hop rebelotte stylo
FLASH
systemd est une usine à gaz
Mais pas du tout, avant pour lancer un service il suffisait d'avoir les droits sur l’exécutable et/ou le script concerné. Du coup n'importe qui pouvait lancer assez facilement des services sous réserve de ressources et de droits. Et bien c'est ca la vrai usine à gaz.
Nous on a un système centralisé ou pour lancer une copie d'un service qui tourne déjà avec d'autres paramètres il faut copier un template, le linker symboliquement, l'enregistrer, et finalement l'initialiser (éventuellement avec des scripts pre et post traitement) via des commandes DBus et/ou systemctl.
Pas la peine de nous remercier on aime rendre service.
systemd seulement pour Linux, pas sympa pour les BSD
systemd est un OS très différent de BSD. BSD utilise encore l'ancien système ou l'init du système sert principalement à initialiser le système puis à foutre la paix à l'admin. De part leur vision archaique ils ne peuvent pas être interressés par mon init, même si celui ci était portable, je suis sur qu'ils continueraient à me regarder avec des yeux et à me parler lentement.
systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian
Dans le monde, ce sont toujours les gens intelligents qui cèdent. Je me fait pas de soucis, ils utiliseront systemd…
(N.B : C'est fait)
systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient
On est tellement flexible, modulaire et léger que les autres systèmes seraient probablement incapables de copier les fonctionnalités simple et ciblées de systemd. Même partiellement. Honnêtement on ne peut pas porter systemd ailleurs.
systemd n’a pas de raison de ne pas être portable
On utilise partout et de façon centralisée pleins de fonctionnalités spécifiques Linux (mais en restant modulaire attention). Donc on est pas portable, centralisé, focalisé sur Linux exclusivement (mais modulairement … Et en s'inspirant de la philosophie UNIX aussi)
systemd utilise des fichiers de configuration binaire
N'importe quoi, systemd utilise des fichiers de configuration texte qui … Ah vous parliez de la configuration du comportement de systemd lui même, pas des units. Ben c'est encore plus n'importe quoi alors parce que le comportement systemd il est carrément codé en dur. Et toc !
systemd est un cauchemar de fonctionnalités
Vous pouvez penser ça aujourd'hui, mais dans 5 ans vous vous retourner et vous verrez qu'en fait il n'y avait pas tant de fonctionnalités que ça dans systemd à l'époque. En plus comme dit plus haut, vous pouvez désactiver pleins de fonctionnalités (mais ca casse votre système)
systemd vous force à faire quelque chose
Pas du tout, on est pas la mafia. Vous êtes libre de laisser votre ordinateur éteint ou de créer votre propre distrib. En plus il y a des promos sur les licences XP en ce moment. Vous êtes libres.
systemd rend impossible l’utilisation de syslog
Encore faux, systemd peut parfaitement renvoyer le contenu de journald sur syslog si vous tenez tant que ça à doubler les I/Os. J'ai dit doubler ? Mettez tripler en fait on a pas mal modifier la verbosité des logs avec notre nouveau systeme et c'est plutôt chiant à régler…
systemd est incompatible
Comme avec les scripts, du moment que vous avez les droits ROOT, que les fichiers sont là ou on vous à dit de les mettre et que vous respectez scrupuleusement les guidelines vous devriez être capables de lancer la plupart des services qui ne sont ni des sondes ni des outils de chiffrement.
Mais bon avec systemd on peut utiliser les unit d'une distribution sur une autre distribution. Je ne vois pas trop à quoi ca peut servir dans le monde professionnel ou la plupart des admins sérieux font des scripts d'init custom. Mais bon c'était très difficile à faire avant, donc on est assez fier.
systemd n’est pas scriptable, à cause de son utilisation de D-Bus
DBus est presque intégralement accessible par script depuis la plupart des clients (enfin des clients locaux) du moment que vous avez une fois de plus les droits ROOT. Donc argument invalide. Hop là, question suivante.
systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement
Ce n'est pas vrai du tout. Vous pouvez éditer les fichiers de configs avec les outils que vous voulez. C'est pour qu'ils soient pris en compte que vous devez utilisez d'obscurs outils de configuration.
systemd est instable et bogué
Totalement faux, la liste bugtracker Fedora nous indique que nous avons assez peu de problèmes avec systemd. Si l'on exclu un certain Linus T qui commence sérieusement à nous casser les pieds avec ces menaces à peine voilées on est plutôt bien.
systemd n’est pas déboguable
En fait on a tellement peu de soucis que la page pour aider à débuguer systemd fait à peine quelques lignes et qu'elle a été mise à jour la semaine dernière (enfin la semaine d'avant ce texte, parceque depuis rien, que dalle, nada. Et ceci même alors que les saturations journald et les conflits udev ont fait crasher pas mal de machines au démarrage.)
systemd fait des changements pour le plaisir de changer
Très très mensonger. On évite les changement incompatibles autant que possible, mais malheureusement parfois l'ancienne solution n'est vraiment pas assez hype pour nos développeurs. En ce qui concerne l'ajout d'un serveur DHCP dans l'init, c'était obligatoires. Parceque des raisons.
systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde
Oh mon dieu, une attaque à mon orgueuil, vite une réponse de trois pages… Les grecs anciens n'avaient pas le concept du zéro ….
systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine
Non, nous on supporte très bien un /usr séparé. C'est Linux qui ne sait pas faire. D'ailleurs toutes les personnes qui fonctionnent avec /usr séparé, par exemple les techniques de doubles montages utilisé en pxeboot ou en /usr commun sur SAN ne marchent pas.
Mais sur systemd avoir un /usr séparé fonctionne très bien (sauf en double montage - mais que personne n'arrive à faire marcher. Je vous jure, si, si)
systemd ne permet pas de remplacer ses composants
Comme déjà vu plusieurs fois, vous pouvez remplacer à peu près n'importe quel composant de systemd, du moment que vous avez les droits ROOT, que vous remplacez avec des composants systemd plus récents et que vous n'avez pas peur de casser votre systeme.
L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque
Ahahaha. DBus utilise les sockets. Du moment que vous avez les droits root, une version custom de DBus avec tracages des paquets et la logique de désérialisation - ca n'est pas plus dur à suivre qu'un socket non DBus.
Promis j'ai commencé un vendredi, donc c'est autorisé.
Mozilla indique que le code est fourni avec une procédure de compilation déterministe pour s'assurer de pouvoir compiler soi-même le bac-à-sable.
Je me suis mal exprimé, le fait que l'on puisse recréer à l'identique l'ensemble du logiciel (tout le binaire firefox) est en effet possible (même si je pense que ce sera complexe), mais je ne pense pas que l'on puisse créer une version fonctionnelle de la sandbox dans un firefox modifié.
Ca permet en effet de voir que Mozilla ne ment pas en disant que le binaire qu'il fournit a été compilé à partir des sources qu'il fournit également, mais ce ne changera pas grand chose au fait que si l'on modifie quoi que ce soit, le plugin adobe refusera de fonctionner.
L'API de la sandbox ne verra pas forcément passer le flux vidéo décodé
Tout le but de la sandbox est justement de ne pas donner les clefs du hardware sous jacent au plugin (sinon la sandbox ne sert à rien, a quoi ca sert de masquer l'historique de navigation si c'est pour filer les droits root au plugin quand il doit afficher une vidéo.)
Faut il encore que cette information soit vraie… Parce que je n'ai pas lu que la sandbox allait être distribué sous forme binaire.
Elle sera probablement sous forme source également, mais je doute fort que l'on puisse compiler une version fonctionnelle. Si c'était le cas il serait extrèmement facile de créer un proxy en sortie du flux audio/vidéo décodé et d'enregistrer le flux.
Donc toute l'étape DRM ne servirait à rien.
A part que tu ne peux pas étudier le logiciel complet (sandbox+plugin) vu que très probablement la partie plugin va se mettre en rideau si tu fais ça, si tu modifies le code il ne sert très probablement plus à rien et si tu arrives à créer une version fonctionnelle (ie qui fonctionne avec le plugin Adobe) et que tu la diffuse, tu tombes sous le coup du Digital Millenium Act aux US et sous le coup de lois comparables au sein de l'UE.
Mais sinon oui, les 4 libertés fondamentales ne sont presque pas touchés.
Une fois de plus je ne suis pas contre les DRM par principe. Et je ne fais pas une croisade contre les DRM ou l'implémentation des DRM par Mozilla.
Je comprend parfaitement que Mozilla soit coincé entre le marteau et l'enclume et décide de collaborer avec l'ennemi pour ne pas se faire détruire.
C'est triste mais c'est comme ça.
Ce à quoi je réagis, c'est lorsque que l'on annonce que l'interface mise en place par Mozilla pour le plugin Adobe est libre.
Un truc dont le seul but est de de faire tourner un truc non libre fermé, tout pourri n'est pas libre. Même si le code source est ouvert. On a pas la liberté de l'analyser ou de le modifier, si on le fait on perd le seul usage du truc.
[^] # Re: Comprendre...
Posté par Kaane . En réponse au journal [RMLL 2014] Surveillance vidéo de la foule à l’insu des visiteurs. Évalué à 5.
Sans vouloir rentrer dans une guerre de définitions (qui serait de toute façon stérile), on peut être libriste (à mon avis) sans pour autant sortir du cadre strict du logiciel.
Il y a trois aspects (toujours à mon avis) qui définissent le libriste :
Le dernier aspect est extrêmement vaste puisqu'il nécessite une surveillance constante de type lobbying. Donc des actions politiques, des débats législatifs, des groupes d'influences et des mobilisations de masse juste pour permettre au logiciel libre de continuer à exister et à couvrir tous les domaines essentiels de l'informatique moderne (de la lecture de blu-ray à la libre concurrence sur le marché des maquettes numériques d'immeubles (BIM))
Donc même en ayant comme seul et unique objectif le logiciel, on se retrouve quand même à participer de façon assez large à la vie publique d'un pays.
[^] # Re: Comprendre...
Posté par Kaane . En réponse au journal [RMLL 2014] Surveillance vidéo de la foule à l’insu des visiteurs. Évalué à 10.
Non on ne peut pas. Tout d'abord parceque ce n'est pas un délire. On parle de droit fondamental non pas au sens moderne "Vachement super important trop bien", mais au sens premier : droit qui sert de fondation. Ne rien en avoir à foutre des fondations c'est ne rien en avoir à foutre de l'édifice qui repose sur ces fondations. Ce jemenfoutisme peut avoir deux causes : soit un réel détachement vis à vis de l'édifice, soit une croyance naive en la survie de l'édifice même si on commence à abbattre des murs porteurs. Mais que ce soit par désintérêt ou par ignorance le résultat est le même : si on attaque le support d'un élément il a tendance à s'effondrer.
Déjà le libre exclu. Par essence une personne qui ne fait que des logiciels propriétaires, ne partage rien avec la communeauté et n'a de cesse de vérouiller ses clients pour les empêcher de migrer vers des solutions concurrentes est exclu. Il ne s'agit pas d'une démarche active de la communeauté libre qui va chercher à ostraciser celui qu'ils considèrent comme un ennemi, mais d'une pure séparation structurelle. De même qu'une personne qui mange régulièrement de la viande par choix conscient ne peut en aucun cas être considéré comme végétarien. Ce n'est pas une kabale initiée par les membres extremistes de la communeauté, c'est juste la définition de la communeauté : végétarien = pas de viande si on a le choix.
De la même façon, être libriste a un sens. toutes les personnes qui contribuent au libre ne sont pas forcément libristes de même que toutes les personnes qui mangent de la salade ne sont pas végétariens. Il existe des pelletées de devs qui bossent dans des boites qui contribuent au libre, tout en trouvant les concepts du libre complètement cons. Il font celà pour gagner leur croute. On trouve dans le monde libre aussi bien des devs qui débutent en SSLL parceque c'était proche de leur appart que des sociétés qui utilisent le libre comme argument marketing pour se faire mousser sans pour autant penser un seul instant mettre quoi que ce soit de sérieux dans la version "communeautaire" de leur logiciel, que des grands pontes embauchés par Google ou Yahoo pour bosser sur des produits libres et qui n'ont choisi ce poste que parceque la paye était meilleure à l'exclusion de tous les autres facteurs ou presque. Donc libriste ne veut pas dire utilisateur/contributeur du libre.
Après on peut sortir des centaines de définitions de libriste et pinailler pendant des heures sur laquelle est la meilleure, mais techniquement je ne crois pas qu'il soit possible de définir libriste sans apporter les notions suivantes :
Le second point nécessite d'être concerné par les caméras et par le respect d'un certain nombre de prérequis (la plupart des dits prérequis étant d'ailleurs dans la déclaration universelle des droits de l'homme).
Trouver les caméras utiles est très loin d'être pire que de s'en foutre. On peut être libriste et trouver les caméras utiles (c'est à dire avoir réfléchi à la question et avoir de bonne foi estimé que la qualité de vie supplémentaire apportée par les caméras apporte plus de sérénité et de liberté que leur absence - à savoir que l'on est pas encore au moment ou les caméras portent atteinte aux individus). Le problème est vraiment vis à vis de "s'en foutre".
[^] # Re: Comprendre...
Posté par Kaane . En réponse au journal [RMLL 2014] Surveillance vidéo de la foule à l’insu des visiteurs. Évalué à 10.
Malheureusement ce n'est pas possible. Vois-tu le socle fondamental d'un certain nombre de choses (au hasard la liberté d'expression et le droit à l'intimité et à la vie privée) reposent justement sur le droit à l'anonymat et à la non immixion dans sa vie privée. Comme c'est sur ces droits là que reposent d'autres choses telles que la démocratie, la liberté d'association, la libre circulation, le droit de prendre part à la vie politique, le droit d'accéder et de diffuser la connaissance et j'en passe, ne rien en avoir à foutre des caméras revient exactement à ne rien en avoir à foutre de la vie privée, de l'annonymat, de la non surveillance, de la démocratie, de la connaissance etc.
Dire "Je suis libriste, mais les caméras je m'en fous" est un contre sens. On peut être utilisateur, et même auteur de logiciel libre et n'en avoir rien à foutre des caméras, mais si on est libriste on est forcément concerné par les caméras.
La présence de caméras, et donc de surveillance et plus encore la possibilité impromptue de cette présence sans déclaration claire entrainne nécessairement une atteinte à un des droits fondamentaux. Une personne qui se sait surveillé, ou qui sait qu'elle peut être surveillée à n'importe quel moment n'aura pas un comportement, une expression ou une pensée aussi libre que si la garantie de non immixition dans la vie privée est certifiée.
En bref toutes les personnes qui sont concernées par les caméras ne sont pas des libristes, loin s'en faut, mais tous les libristes sont nécessairement concernés par la libre expression, la libre pensée et la libre circulations des connaissances et donc par les caméras.
[^] # Re: Vive la démocratie d'Internet !
Posté par Kaane . En réponse au journal Microsoft débranche 22 domaines No-IP. Évalué à 2.
Ensuite, pour le DNS, le DNS étant décentralisé, le domaine de M. Michu (mettons mmichu.fr) ne se trouve pas dans les serveurs racine et ne peut donc pas en être retiré.
Oh non Stephane, pas toi ! Je t'accorde bien volontiers la caricature de mon poste (j'avais pas envie d'écrire un article didactique de 20 pages - surtout que d'autres (toi par exemple) le feraient bien mieux que moi. J'avais juste envie de passer un message sur la main mise américaine sur le sujet).
Donc caricatural d'accord - mais au niveau des erreurs je ne pense pas qu'il y en ait beaucoup.
En ce qui concerne les IP (ou plus précisément le routage des IP) c'est clair que la probabilité pour qu'il y ait une action est faible - En partie parce que les IP sont gérées par plusieurs groupes, en partie parce que ça pousserait les gouvernements non américains à se poser de bonnes questions (et dieu sait qu'il faut éviter ça à tout prix) et en partie surtout parce qu'il y a de gros morceaux du routage internet ou plus personne ne sait trop comment ça marche (ils ont une idée hein, mais ils ont pas envie de la tester en prod là tout de suite là maintenant) et que retirer des blocs IP d'une zone pour les mettre dans une autre ca pourrait avoir des effets de bords assez désagréables.
Ceci étant techniquement rien n'empêche l'IANA de déplacer un bloc IP d'une zone à une autre. (Ils l'ont d'ailleurs fait il y a pas trop longtemps pour que l'Afrique dispose d'autre chose que d'un /24). Bien sur rien n'oblige les ISPs et les transitaires à suivre. Ils peuvent décider d'ignorer les demandes de modifications et continuer à router et à peerer comme avant. Mais déjà tous les tiers 1 américain se mettront au pas, je ne vois pas trop Tata faire de la résistance. Il va rester qui ? Deutsche Telekom et NTTC ?
On est d'accord que politiquement ça ne se produira probablement jamais et que le RIPE NCC en Europe met déjà des mois à réagir au vol ou à l'abuse de plages IP (les listes DROP n'ont pas été crées par hasard) - mais techniquement c'est faisable et légitime.
En ce qui concerne les entrées DNS, ICann et Verisign ont de bons moyens d'action.
Tout d'abord effectivement personne ne connait le domaine de madame Michu "michu.fr", donc personne ne l'a en cache (à part éventuellement le registar de madame michu), donc si on met le domaine de madame michu dans les root DNS avec un pointeur vers une fausse adresse, plus personne n'accède à michu.fr à part peut être les gens qui sont sur le même réseau que sont serveur autoritaire et éventuellement son registrar.
Il ne s'agit pas ici d'enlever le nom des root DNS, mais au contraire de l'y ajouter. Après on fait deux trois déclarations et une contre propagation et en deux heures montre posée sur la table, l'ensemble de l'internet mondial a oublié l'ancien serveur de madame Michu, tout le monde pointe sur le nouveau serveur (vous savez celui qui dit que les gentils agents du FBI vous ont sauvé la démocratie.)
Là aussi il y a peu de chances que cela se produise. Les root serveurs c'est pas fait pour jouer avec, enfin pas trop. Mais contrairement au démapping sauvage de blocs IP, ce procédé a déjà utilisé.
[^] # Re: Vive la démocratie d'Internet !
Posté par Kaane . En réponse au journal Microsoft débranche 22 domaines No-IP. Évalué à 4.
Et il faudrait choisir quoi comme extension?
L'ensemble des noms de domaines classiques sont sous controle américain. A moins de rajouter des noms de domaine "fantaisistes" et d'ajouter de nouveaux serveurs dans la liste des ROOT DNS de ta machine, il n'y a aucun moyen de couper à l'hégémonie américaine sur ce point.
[^] # Re: Vive la démocratie d'Internet !
Posté par Kaane . En réponse au journal Microsoft débranche 22 domaines No-IP. Évalué à 0.
Comme tu le dis, si tu veux être protégé par le droit français un peu plus, tu prends un registrar français sur un truc genre .fr, géré par l'AFNIC
Je te rassure tout de suite, l'AFNIC n'a qu'une délégation. Si au nom du droit américain un juge américain veut saisir un nom de domaine en .fr d'une société française basée en France ça reste tout à fait faisable.
Il peut également obtenir le déroutage de ta/tes plages IP et le retrait des entrées te concernant des root DNS (ou une contre propagation depuis les root DNS vers une IP qui n'est pas la tienne.)
En théorie il faut passer par l'ICANN pour faire tout ça, mais en pratique un coup de fil à Verisign et ca va être réglé rapidement.
Après pour te sucrer tes adresses IP elles-même il faut passer par l'ICANN (mais comme l'ICANN a tendance à ne pas faire n'importe quoi n'importe comment, le département du commerce américain a bien limité leurs pouvoirs au maximum.)
[^] # Re: Les sessions utilisateurs de systemd.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
J'ignore si cela peut résoudre les problèmes que tu rencontres : des utilisateurs non-root peuvent créer, lancer et stopper des unités systemd.
Oui, mais seulement dans leur session. En d'autres termes l'utilisateur Nagions ne peut pas interragir avec le programme lancé par l'utilisateur Nginx sans être route. Et ce même si l'utilisateur Nagios aexactement les mêmes droits que l'utilisateur Nginx.
Le but du jeu ici est de pouvoir interragir avec des units systèmes, pas des units session.
[^] # Re: Suite à un vieux bug qui est enfin cloturé
Posté par Kaane . En réponse au journal Debian revient à la glibc. Évalué à -3.
Parce que j'imagine mal installer une clôture autour d'un bug
Je sais pas, c'est quoi la traduction officielle de "fenced" en Français ?
# Suite à un vieux bug qui est enfin cloturé
Posté par Kaane . En réponse au journal Debian revient à la glibc. Évalué à 10.
https://sourceware.org/bugzilla/show_bug.cgi?id=10134
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
T'es pas obligé de lancer un signal KILL, non plus.
Peut importe le signal que je lance, il faut que ce soit interprété comme un fail par systemd. (Si je mets le service en restart même sur un status de sortie correct, ca veut dire que je ne peux plus jamais arréter le service à moins d'éteindre la machine.)
A partir de là, a part sigkill, sigterm et sigint j'ai pas grand chose.
Si le process est solitaire, un sigterm peut permettre une sortie en douceur si tout va bien, mais si il y a plusieurs processus ou que sigterm ne suffit pas il faut y aller plus fort. Et là le fait que mon service secondaire ne soit pas l'init que les différentes infos ne soient plus logguées comme avant et qu'elle ne soit pas accessible facilement par un processus non root peut entrainer des problèmes.
Tu as plusieurs politiques dans systemd en jouant avec Restart et SuccessExitStatus tu devrais pourvoir faire en sorte que systemd relance le service quand quand tu le souhaite.
Pas vraiment non. Si c'est le service "moniteur" qui envoie un sigkill, je veux que le service monitoré redémarre. Par contre si c'est moi qui envoit le sigkill je veux que ce soit pris en compte comme un ordre définitif. Généralement je ne fais pas de sigkill, mais quand j'en fais un c'est pas pour que le processus soit relancé immédiatement.
Et l'action de Nagios ça ne peut pas être de simplement tuer les processus à relancer ?
Pour certains services problématiques, c'est déjà le cas aujourd'hui, mais après avoir tenté plusieurs fois une extinction propre via les commandes init.
J'ai l'impression que ce qui te pose problème ça n'est pas l'architecture de systemd, c'est juste que son API dBus ne serait accessible qu'à root (ce qui me surprends).
D'un autre coté, le fait que le bus systeme avec la target qui controle tous les services ne soit acessible que à root n'est pas franchement choquant.
Ce qui est plus embétant c'est que systemd ne possède aucun moyen de lui passer des paramètres dynamiquement que ce soit à l'init ou pendant la vie du service.(j'ai bien dit "des" je sais qu'on peu en passer un via @ à l'init.)
Je ne serai pas aussi négatif si il y avait les fonctions suivantes dans systemd
- Un moyen de lancer plusieurs fois la même unit avec des paramètres différents (ex : /etc/init.d/startvirtualnet --ip=192.168.200.0/24 --with-dhcp=192.168.200.1 --vinterface=vl12)
- un moyen de balancer des messages au service en cours d'éxecution (ex: /etc/init.d/service --rehash --reindex)
- un moyen d'autoriser des services non root à lancer les deux types de commandes ci dessus.
A l'heure actuelle pour chaque service lancé par systemd je suis obligé de chopper le PID au vol et de le stoquer pour pouvoir balancer les commandes directement, d'enregistrer et de détruire des units à tour de bras et le tout en faisant gaffe à ce que systemd ne prenne pas mal ce que je suis en train de faire.
Le reste ça me semble plutôt intéressant de faire gérer les services via un seul point (systemd) qui va gérer ça aussi proprement et de manière aussi centralisée que possible.
La question est limite philosophique, mais je ne considère pas que gérer un service se limite à le lancer, le logguer et à l'arréter. Pas mal de service son des options que l'on peut régler dynamiquement, tant que l'on ne peut pas les gérer depuis systemd, on se trouve à écrire des gestionnaires secondaires pour faire tout ce que systemd ne gère pas.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
Tu peux avoir un service qui fait ça. Il vérifie le processus comme tu le souhaite, puis si vraiment il y a un problème il le dézingue et systemd le relancera.
Déjà j'aime pas trop "dézinguer" un service qui tourne, même si avec systemd il y a un relatif ménage derrière qui évite les zombis et les processus fils qui trainent (Mais qui n'évite pas forcément la rémanence de données inutiles dans les applis connectées à ce service, le post-traitement n'est pas appelé etc.)
Autre effet désagréable si on relance le service de cette façon, systemd va compter un "fail". Donc pour que le service soit relancé à chaque fois, il faut configurer systemd pour qu'il relance le service systématiquement. Ce qui n'est pas sans effet de bord quand le service se met vraiment à merder tout seul comme un grand.
Ensuite, c'est bien beau pour un service, mais pour deux cents ca devient pénible. Si on décide de faire des procédures différentes par client, de modifier toute sles procédures de surveillance, de changer temporairement une procédure (par exemple le client prévient qu'il y aura une forte charge et/ou des tests pendant une semaine) etc. Ben tu as deux cents services à mettre à jour. Quand c'est fait depuis Nagios, tu as une règle à changer - tu es sur de ne pas oublier de règle puisque tout est centralisé etc.
Finalement à ce compte là autant avoir un script à l'ancienne qui essaye au moins d'arréter le service proprement, tout en faisant la nique à systemd. Mais ca n'est pas possible avec tous les services (des que l'on touche au réseau en dehors de networkd, il se passe des choses indésirables). Pendant qu'on y est on va même carrément mettre ce script comme cible de l'unit systemd - comme ça systemd lance un script qui à son tour lance le programme voulu. Un émulateur sysV en quelque sorte - mais avec une interface de plus.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
L'option Restart des units ne suffit pas pour ça ? Avec la possibilité de conditionner le restart et la possibilité de lancer une commande avant le démarrage du service pour récupérer l'état de la machine lors du restart.
Les watchdogs de systemd sont pas mal pour les cas faciles. Mais c'est assez compliqué d'écrire des règles pour shooter les processus PHP seulement quand il y a une fuite de mémoire ou une boucle infinie. Il y a des raisons tout à fait valable pour que le PHP se mette à bouffer le CPU ou de la mémoire comme un goret sur des périodes de temps plus ou moins longues. Avant d'utiliser le shootgun il faut vérifier que la consommation est constante, que la mémoire ne baisse pas significativement de temps en temps (utilisation en dent de scie) etc.
Donc on polle toutes les cinq/dix minutes, si ca dépasse systématiquement les quotas on polle toute les trente secondes, puis surveillance intensive et enfin shootgun.
Les watchdogs systemd n'ont pas (en tout cas pas encore à ma connaissance) la capacité à passer d'une règle de surveillance à l'autre en fonction des résultats.
C'est pas une question de configuration DBus ça ?
Jusque récemment il était impossible d'envoyer un message au dbus system vers systemd avec autre chose que root non limité. Maintenant il est possible de limiter root pour autoriser seulement certains types de messages sur certaines units de systemd. Mais je ne crois pas qu'il soit possible de passer des messages si l'on n'est pas root.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine
Ca fait un petit moment qu'on évalue les différentes beta. Mais je te rassure on a encore rien en prod - et pour l'instant la question est plus "est-ce que" que "quand".
La doc officiel comme ça :
Il s'agit ici de modifier un la configuration d'un CGroup donné. Pas de placer un processus dans un autre cgroup que celui par défaut ou encre de déplacer un processus d'un cgroup à l'autre. (à ma connaissance le kernel ne permet de toute façon pas le déplacement à chaud en ce moment.)
Par exemple si tu veux mettre tous les processus d'un client au sein d'un même cgroups pour pouvoir contrôler les ressources en un seul point central - ben c'est compliqué.
Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.
J'ai bien conscience d'être assez difficile à suivre vu que a) je n'ai pas franchement des problèmes communs (systemd marche très bien 95% du temps) et que b) je ne peux pas franchement donner d'exemples concrets pour cause de contrats à la con. J'avoue que ça n'aide pas.
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Je parle en mode hyperviseur. Bien sur tu testes avant de passer en prod, bien sur tu audites pendant un moment avant d'ajouter la règle en dur (IE tu passes quelques semaines avec setenforce à permissive - c'est ce que je voulais dire par mode "audit only") Mais à un moment ou à un autre il faut bien passer en vraie prod. Et là parfois pour tout un tas de raisons (fin de mois, mise à jour des logiciels du client, changement du sens du vent - que sais-je) le container va faire une action ou avoir besoin d'une ressource que tu n'avais pas prévu. Et là on repart en permissive, on récupère le container client à la pince à épiler (parceque bien entendu c'était pendant une écriture en base de données que le bug a eu lieu - sinon c'est pas drole - et bien entendu la base c'est pas Postgresql - c'est une grosse base de données commerciale qui vit très mal le fait de plus pouvoir écrire sur le disque d'une seconde à l'autre). On fait de plates excuses au client. Une fois, deux fois et puis on arrête SELinux.
Alors ca c'est ennormément amélioré au cours des trois dernières années (et on a appris de nos erreurs aussi) mais ca reste un sujet sensible (chat échaudé toussa.)
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7.
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Quelques temps - ca fait moins d'un an. Je crois que l'annonce de Lennart date du 21 juin 2013. On savait déjà que les cgroups allaient être unifiés (et c'est une bonne chose) mais le coup du controleur unique accessible uniquement via DBus ca fait bizarre.
Ca fait bizarre pour deux raisons :
- la première c'est qu'un processus acquiert son cgroup au lancement, et là soit il se retrouve dans le même cgroup que son père, soit on veut le mettre dans un autre cgroup. Mais si on veut le mettre dans un autre cgroup il faut être capable de dire à systemd d'une façon ou d'une autre "attention le prochain processus que je vais lancer doit aller dans le cgroup /bidule/truc" parce que une fois que le processus est lancé c'est rapé (du moins jusqu'à ce qu'on puisse balader un processus d'un cgroup à un autre.)
A partir de là il faut bien s'assurer que la session depuis laquelle on est ne va pas lancer un autre processus avant celui que l'on veut mettre en cgroup. C'est extrèmement facile à faire pour un service qui s'initialise, mais pour une session utilisateur ou encore pour une commande lancée par uns ervice après initialisation c'est tout de suite plus complexe, il faut bien faire attention aux conditions de courses et autres ratage de lancement (par exemple si je prépare un cgroup, mais que mon processus ne se lance pas - on fait quoi ?). Reste la solution de créer une nouvelle session par processus - Mais ca peut devenir assez problématique assez vite.
- la seconde est liée au comportement même des cgroups en mode comptabilité. Si j'utilise les cgroups pour mesurer la consommation de ressources de mes processus (très utile quand un client a l'habitude de faire du while 1 fork; sans le vouloir). A aujourd'hui, mon appli avec son propre temps CPU peut checker la consommation quand elle le veut. Mais demain si tout passe par DBus je me fais un peu de soucis, parceque gérer 3000 processus qui vont venir le questionner à tour de rôle ca peut être lourd à digérer.
Maintenant il s'agit juste de réflexions en me basant sur l'existant et sur ce qui a été dit. Ca me casse les pieds de faire évoluer mes archis pour prendre en compte les nouveaux cgroups, mais ca n'est pas fondammentalement mauvais. J'attend de voir ce qui sort pour donner un avis plus complet sur la question.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Il ne s'agit pas de faire faire du correctif à Nagios (Même si c'est faisable, et même plutôt salvateur sur certaines config, on va pas déranger un admin à chaque fois qu'il faut relancer un php??-?gi, on a pas les moyens d'embaucher assez de monde) - mais plutôt de pouvoir déclencher facilement des sondes supplémentaires quand un comportement anormal est détecté.
Typiquement je surveille le temps d’exécution moyen d'une requête. Et quand il augmente je lance d'autres sondes pour savoir si ca vient de grosses requêtes qui sont lancées, des I/Os qui foirent ou de la mémoire vive qui est pleine. Comme ça je lance un minimum de sondes et je ne passe sur des sondes plus fortes que si le besoin s'en fait sentir et seulement là ou j'en ai besoin.
Pour la majorité des sondes il suffit de chopper les logs et/ou se connecter via un canal spécial à l'appli en mode client. Pour d'autres sondes il faut aller triffouiller plus loin ce qui implique soit un reload de la config du serveur qui pose soucis, soit le chargement de certains modules par l'appli,soit carrément un restart avec une autre config.
Tout ceci se faisait avant très simplement en ligne de commande en balançant des commandes de type
/etc/init.d/monservice -reload -with module2 -activate stacktrace -verbosity 5
Ce n'est pas que je n'aime pas la nouvelle méthode - c'est que je ne la connais pas. Et j'ai beau chercher et ouvrir des tickets chez RH je n'ai pas encore eu de réponses satisfaisantes. (parceque très honnêtement modifier les pre,env et les posts d'un fichier unit avant de le réenregistrer et de faire un restart n'est pas une réponse satisfaisante).
dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl
Oui, il y a cette solution, mais elle implique une bonne baffe en performance (10 à 15%) lors de mes tests, le 7% annoncé par fedora me parait très optimiste. En plus SELinux c'est quand même pas évident à gérer et très facile à casser (ce qui en langage hypervisuer veut dire plus personne ne peut rien faire tant qu'on a pas rebooter la machine en single user et passé SELinux en audit only). Comme les modifications ne s'appliquent qu'au redémarrage dans la plupart des cas, on a assez fréquemment de mauvaises surprises.
Ensuite (mais honnêtement je ne sais pas si c'est encore vrai) SELinux ne fonctionnait avec systemd que dans le cadre d'une descente de privilèges. C'est à dire plus pour empêcher un processus root d'interagir avec des services que pour autoriser un service non root à le faire.
La page de RH ne donne pas non plus d'exemple d'élévation : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/chap-Security-Enhanced_Linux-Systemd_Access_Control.html on y parle que de réduire les droits.
Es-tu sur que l'élévation de droits marche ? (Vraie question)
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
Perso, j'étais plutôt parti sur le quinca qui a pris ses habitudes, n'aime pas qu'on les lui change et surtout se retrouve à égalité technique avec les post-ado qui arrivent et maitrisent mieux les outils modernes, et ça lui fait mal à l'égo (la personne a de l'expérience! faut pas déconner…) alors il va chercher n'importe quelle petite bête pour se justifier.
Tiens un autre quinca qui a du mal à suivre toutes les évolutions Linux et qui rale plutôt que d'apprendre :
https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 0.
Tu as des CVE à montrer ?
Il y en a un paquet qui tombent régulièrement. La nécessité d'être root pour la majorité des opérations + la centralisation des méthodes de sécurité + la compelxité polkit/consolekit + … font qu'il risque de falloir un bon moment avant qu'il n'y ait pas deux ou 3 CVE par jour. (Rien que sur le bugzilla RH il y a eu plus de 5000 CVE systemd/udev don certains CANT et WONTFIX qui ne me donnent pas confiance.)
Rien que pour les bugs confirmés ou plus :
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=CLOSED&component=systemd&component=udev&component=udev-browse&component=udev-extras&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced
Hum, systemd est incapable de lancer un processus avec un autre utilisateur que root ?
Ou alors je ne comprends pas.
Non le problème c'est qu'un service qui est lancé avec autre chose que le cgroup le plus haut hierarchiquement et des droits root ne peut pas auditer/interragir/démarrer/redémarrer un autre processus. Ca n'est juste pas acceptable. J'ai besoin que Nagios (par exemple) puisse démarrer tout seul comme un grand nombre d'autres services, lesquels services doivent pouvoir interagir avec les services critiques, le tout surtout sans être root. C'est la base de l'admin système : on a des sondes qui tournent en permanence , mais pas beaucoup parceque les ressources sont pas gratuite. Et quand on a un soucis on doit pouvoir lancer d'autres services ou sondes qui vont essayer de diagnostiquer le problème - soitpour le corriger automatiquement (rare) soit au moins pour que l'admin n'ait pas à lancer 200 commandes à la queue leu leu pour se faire un idée de la situation.
Il faut aussi en cas de pépins pouvoir remonter des infos aux utilisateurs/à la production/aux admins services pour qu'il puissent réagir etc.
Tout n'est pas forcément accessible depuis les logs, et je vais pas refiler les droits root aux services qui créé le tableau de bord du client…
Après c'est comme tout quand tu fais tomber un goulot d'étranglement tu en a un autre qui apparaît, mais c'est pas pour ça que ça ne sert à rien de l'avoir supprimé.
Mais il n'y a pas de goulot d'étranglement à ce niveau là. Je ne peux pas faire un diagnostique de mon data-center toute les minutes ce serait ultra consommateur de ressources pour rien - et d'un autre coté dans le cadre d'un cloud elastique je ne peux pas non plus demander au client de patienter une minute à chaque fois qu'il fait une modif ou qu'il passe d'un status iddle à un status plein régime. Donc l'ensemble du problème de consommation électrique ou de densité des data-center repose sur l'anticipation des admins et les optimisations du data-center. Le temps de boot d'une machine - dans la mesure ou il reste très inférieur au temps de mise à jour du status du data center ne rentre pas en compte.
Si je mets 8 minutes à mettre à jour le "load" de mon data center (ce qui sera déjà une performance - ou alors un gaspillage de performance suivant comment c'est fait), je ne vais pas attendre tout ce temps pour me dire "tiens ? On est plein il faudrait peut-être lancer un nouvel hyperviseur/monter des réseau virtuels des fois que la charge augmente". Comparé à ces huit minutes d'anticipation obligatoires (et encore une fois poler un datacenter complet en 8 minutes ca demande un certain doigté) les 4 secondes que va me faire gagner systemd au boot je m'en cogne. Le temps de boot de l'init c'est le 6 ème chiffre après la virgule d'une opération sur trois chiffres significatifs.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Ou alors j'ai mal compris , ou alors tu extrapoles largement, mais c'est pas du tout ce qui est dit.
Déjà de base le texte est de mauvaise foie (je pense que c'est assez évident). Il s'en trouvera toujours pour penser que j'ai 14 ans et que je parle de systemd pour passer ma période pré-ado (bonjour Misc _o/ ), mais dans le fond, même si je n'utiliserais pas systemd avant qu'il y ait eu de gros changements (c'est à dire probablement jamais, parti comme c'est) je n'ai pas de ressentiment particulier vis à vis du logiciel.
Pour être clair je considère que systemd est comme internet explorer 5.0, ca rend service à pleins de gens, en surface c'est facile à mettre en oeuvre et à utiliser et ça juste marche pour 90% à 95% des cas. Maintenant c'est aussi un nid à bugs et à trous de sécu, et les 5% de cas ou systemd ne marchera jamais font qu'il est bon à mettre à la poubelle d'après moi. En tout cas pour l'utilisation que j'ai de l'outil informatique au niveau professionnel, non seulement il ne me sert à rien, mais en plus il est fondamentalement incompatible avec mon métier. (Par exemple il est hors de questions que mes sondes actives ou que mes watchdogs choppent les droits root. Donc soit je ne monitore pas, soit je n'utilise pas systemd - le choix est très vite fait.)
Revenons en à la question qui nous interresse
On a cette phrase là (je prend la traduction pour aller vite)
En substance ce qui est expliqué ici (très lentement, parce que les admins à qui ont confie des datacenters contenant plusieurs milliers de conteneurs sont rarement très malins) c'est le principe de la loi d'Erlang du temps d'attente - à savoir que de façon générale (à adapter en fonction des situations bien sur) un système servant plusieurs clients n'a pas besoin de disposer d'assez de ressources pour servir tous les clients en simultané. Typiquement si vous avez 50 employés et que vous n'êtes pas un call-center, dix canaux téléphoniques c'est suffisant.
Pour les VMs c'est pareil, pour peu que l'on arrive à mettre à disposition une VM assez rapidement, pas besoin de faire tourner toutes les VMs (ou conteneur) tout le temps, il suffit de lancer la VM au moment ou elle est demandé. Donc moins de charge CPU, moins de courant électrique, un datacenter plus dense etc.
Sauf que ça ne marche pas tout à fait comme ça.
Il existe (grosso-modo) trois grand types de VMs/Conteneurs dans le cloud.
- Les VMs pour faire du calcul
- Les VMs pour faire du traitement de données
- Les VMs pour faire du stockage de données
Plus un type hybride des trois : les serveurs dédiés virtuels.
Les VMs pour faire du calcul démarrent généralement en un temps record. Il s'agit le plus souvent d'OS ultra-dépouillés dont le seul rôle est de répondre le plus vite possible à un serveur maitre, donc avec un temps de boot minuscule. C'est généralement mis en place sur des très très grosses machines avec des quantités de ram délirante (le petit octo-déca coeur avec 2TO de mémoire vive est assez populaire). Elles vont être louées par paquets de 200/300 tranches pour plusieurs jours, voire semaines. Généralement la personne qui gère ce type de machine est prévenu plusieurs semaines à l'avance. (Que ce soit l'industrie du cinéma ou celui de la recherche, entre le moment ou le contrat est signé et celui ou l'argent est arrivé et ou les comptes sont ouverts il s'écoule un moment.) De toute les façon que ce soit coté client ou coté exploitant tout le monde se fout royalement de la demi-seconde gagné par une VM à booter sur systemd.
Les VMs pour faire du traitement de données sont principalement orienté de façon à minimiser les I/Os. Généralement ce sont des machines avec une grosse quantité de mémoire (pour pouvoir stoquer les index) et des I/Os disque ultra optimisés. Le but étant bien sur de pouvoir processer un flux d'information assez conséquent à toute allure. Sur ce genre de VM, le temps de boot est très négligeable comparé au temps de rapatriement des données/mise en place du flux et au temps de calcul des index. Donc toujours pas d’intérêt majeur à utiliser systemd (et totu ca sans même parler du temps nécessaire pour faire le sharding des données ou le fencing des machines si l'application le nécessite)
Les VMs pour faire du stockage de données sont généralement en fait des partitions de serveurs de fichier. C'est à dire qu'un service central (Mongo, Hadoop, Riak etc. ) sert plusieurs dizaines voire centaines de client finaux. La question de le démarrer à la demande ne se pose pas vraiment. Et une fois de plus il s'agit de serveurs très simple avec des OS très spécifiques qui vont avoir tendance à avoir des temps de boot très rapide. Ce temps de boot sera systématiquement très inférieur au temps mis par les services pour faire le mapping des données et les rendre accessibles.
Reste les serveurs dédiés virtuels, c'est à dire les produits type EC2, VPS OVH par VMWare, machines Gandi et autre google Cloud. Là éventuellement les principes de l'Erlang peuvent s'appliquer. On est sur une grande diversité de clients, avec des demandes ponctuelles et irrégulières dans le temps. Systemd possède donc un avantage ici, même si il est minime (attribution des ressources + mise en place monitoring/facturation + montages des données + initialisation de la VM et des instances fallback éventuelles >> temps gagné avec systemd). Mais le temps gagné par systemd sera très difficile à exploiter en vrai, tout d'abord parceque le temps de mise en attente toléré est très inférieur au temps de boot, même avec systemd (un serveur qui met plusieurs secondes à répondre sous pretexte qu'il n'y a pas eu de demandes depuis une heure, ca la fout mal) et ensuite parce que le temps d'usage est lui très très supérieur au temps de boot.
Généralement on va avoir un temps de mise en attente toléré de l'ordre de quelques millisecondes (entre 10 et 100), un temps de boot de plusieurs secondes (entre une et 10) et un temps d'utilisation de plusieurs heures (de 12h typiquement pour un service pro principalement utilisé pendant les heures de bureau)
Chercher à grapiller quelque chose là dedans ca va être l'horreur.
Deuxième soucis, le système va gagner quelques secondes au boot - à condition que les ressources soit prêtes. Ca c'est bien entendu le boulot de l'hyperviseur d'avoir des ressources disponibles au cas ou une demande arriverait, mais si les ressources sont disponibles on est déjà en consommation électrique "iddle" sur ces ressources.
Par exemple si mon hyperviseur est configuré pour avoir 15% de ressources préallouées par rapport au volume consommé, il aura exactement la même densité et la même consommation que ce soit en mode systemd ou init classique. Et comme je n'ai pas le temps de faire toute l'allocation à la demande (pour des raisons de temps de réponse du hardware - ouvrir une LUN sur un SAN par exemple ca ne sera jamais instantané, idem pour le temps de création d'un sous réseau virtuel avec les VLANs qui vont bien) - et bien au final ma consommation électrique et ma densité salle blanche ne bougeront pas d'un iota.
Donc dans tous les cas possibles parmis les plus fréquents, du minicloud entre potes au EC2 Amazon systemd n'apporte rien au niveau densité, consommation électrique ou vitesse de mise à disposition. Les facteurs limitants se trouvent systématiquement hors de portée des problèmes qu'un init peut résoudre.
Après l'exemple débile que j'ai donné n'a pas d'autres but que celui d'être humoristique. On se place dans un univers ou presque tout fonctionne comme Lennart Poettering le décrit (c'est à dire que tout ce que "controle" systemd, du temps de boot, au réseau, à la nécessité d'aller le plus vite possible au point que trois secondes sont salvatrices) et on regarde ce qu'il se passe juste après, et paf le SAN.
Bien sur que dans la vraie vie ca va bloquer à pleins d'endroits - le systèmes ne débloquera pas les 250 comptes simultanément, les 250 sous réseaux virtuels ne seront pas créés dans la même milliseconde, l'hyperviseur ne traitera pas toutes les demandes assez vite (si tant est qu'il en ait l'intention au début) etc.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
250 Vms qui bootent en même temps , ton problème c'est clairement pas systemd , mais une très mauvaise gestion ( incompétence ? ) de ton hyperviseur…
Ah mais je suis entièrement d'accord. Mais ça n'est pas de moi que vient cet argument.
# Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Sommaire
Après tout ce démontage d'idées reçues, il est temps de remonter un peu
systemd est monolithique
Systemd est constitué de pleins, pleins pleins de binaires. Donc il n'est pas monolithique. Le fait que tous ces binaires sont fortement interdépendant n'a aucun rapport avec la choucroute. En plus dans sytemd chaque binaire effectue une tache bien définie, comme par exemple vérifier la config réseau, lancer le DHCP, simuler les connexions en attendant l'initialisation resynchroniser tout ça et balancer les résultats via DBus pour qu'il soit loggués. C'est une tache simple, fine et précise. Pourquoi ? Parceque nous avons le soucis de la sécurité, grâce à l'utilisation de bon nombre de technologies flaguées "experimental" dans le noyau nous arrivons à limiter grandement les droits dont un processus a besoin pour effectuer sa tache. Ainsi il suffit d'être ROOT pour arreter ou relancer un service, il suffit également d'être ROOT et dans la hiérarchie de plus haut niveau dans les CGroups pour pouvoir auditer un autre processus. De même en étant simplement ROOT on peut envoyer des signaux à un autre processus ou encore créer une nouvelle unit.
systemd a été conçu pour la vitesse
Pas du tout, systemd a été conçu principalement pour être propre. Comme il a été conçu et pensé intelligemment, il est en plus rapide - mais c'est juste un effet de bord de notre travail de réflexion. Ce quic ompte c'est que systemd soit super bien conçu, tellement bien conçu même que le des systèmes simples comme les logs ou le monitoring d'initialisation de périphériques n'ont entrainnés qu'une petite dizaines de bugs critiques au démarrage chacun.
La vitesse de systemd ne sert à rien pour les serveurs !
Pas du tout, déjà même sur les gros serveurs dont la partie matérielle du boot matériel peut durer plusieurs minutes, 10secondes de plus ou de moins ca peut changer la vie. Mais sur les VMs qui vont booter en quelques secondes quoi qu'il arrive et avec lesquelles ont peut faire des snapshot à chaud pour les mise à jour de toutes les façons, cette différence de trois secondes est encore plus cruciale. Sur un système qui contient plusieurs centaines de VM et qu'il faut redémarrer en urgence, ces trois secondes gagnées par VM au boot peuvent faire un total de 6 voire 8 secondes. Et puis le SAN est tellement content de voire 250 VM venir lui faire coucou dans un intervalle maximal de 2 secondes.
systemd est incompatible avec les scripts shell
Totalement faux, on peut parfaitement utiliser des scripts shell avec systemd. Du moment que ces scripts sont lancés avec les droits root, ne modifient pas l'environnement, restent cantonnés dans leur CGroup, ne cherchent ni à arréter ni à relancer le processus, et bien entendu ne cherchent pas à remonter une autre info que start, stop, reload aux units - tout ce passe très bien. (Enfin pour le premier script shell, si vous avez besoin que plusieurs scripts shells interragissent avec la même unit ca peut nécessiter l'écriture d'une autre unit, ou d'un wrapper ou les deux.)
systemd est compliqué
Alors là c'est n'importe quoi, en quoi un système qui s'appuie sur les capabilities, les cgroups, DBus, un nouveau système de log, un nouveau système de controle, un petit 500 variables kernel (dont 200+ spécifiques à Linux) le tout derrière une boite noire affreuseument simpliste, serait-il plus compliqué de lancer httpd avec l'utilisateur apache depuis un script shell ?
En plus au cas exceptionnel au systemd viendrait à vous causer des soucis, journald loggue l'ensemble des évènement de façon si claire et si concise que le kernel Linux arive presque à digérer le flux à tous les boot.
systemd n’est pas modulaire
Oui c'est le même sujet que plus haut dans la section "systemd est monolithique" mais j'écris tout d'une traite et ça me fait chier de me relire et de corriger quand je tape du texte aussi.
Donc systemd est modulaire, on peut désactiver pleins de trucs à la compilation ou à l'éxecution. Si vous le fait ca cassera surement le système, mais inutile de nous envoyer un mail pour vous plaindre - au mieux on vous répondra poliment qu'on s'en cogne. Dans systemd vous pouvez désactiver à la compilation les cgroups (mais ca casse le système) les capabilities (mais ca casse le système) passer sur une version plus ancienne de dbus (mais ca casse le système) ou encore activer le mode de compatibilité pour utiliser une libsystemd pas tout à fait synchrone avec la version de l'executable (mais…)
Bref si vous aimez linux 1.xx vous allez adorer systemd.
systemd est seulement pour les ordinateurs de bureau
Pas du tout, quand on a créer systemd on a penser à toute la gamme de produit basés sur Linux. Nous avons déjà vu ce que la vitesse de systemd apportait au serveur. Mais ce n'est rien à coté de ce que DBus+Journald logé en RAM au démarrage+les capabilites+la nécessiter de passer par systemd pour gérer les CGroups peuvent apporter au monde de l'embarqué.
systemd est un résultat du syndrome NIH
Le problème que nous avions avec notre précédent système d'init, Upstart (outre le fait qu'il ne marchait pas non plus) n'est non pas qu'il n'avait pas été inventé par Red Hat, mais qu'il avait été inventé par Canonical. Honnêtement un init inventé par Debian ou même Suse ca ne nous aura pas posé autant de problèmes. Mais là quand même….
systemd est un projet freedesktop.org
Et voilà, sous pretexte que vous êtes hébergés par freedesktop, que votre système se met à gérer toutes les notions d'ACPI, le login et de getty et que son auteur est principalement pour avoir fait deux démons purement orienté utilisateur final non professionnel - vous êtes catalogué tout de suite. Pas du tout si on a fini sur le site freedesktop.org, c'est juste parceque justine, la scrétaire du troisième connait vachement bien le gars qui change les tubes néons dans la salle serveur 4 de chez FreeDesktop. Tout de suite à se faire des idées les gens.
systemd n’est pas UNIX
D'un certains coté c'est vrai que l'on s'est un peu éloigné de la philosophie UNIX. Mais le fondamental de la philosophie UNIX est "avoir un sous système qui fait une seule chose et qui le fait bien", nous un a un macro système qui fait pleins de chose, mais que délègue à plusieurs modules qui eux font … plusieurs choses aussi, d'accord, mais on est quand même proche de la philosophie UNIX. Quand même. En tout cas on s'en inspire. Par contre pour ce qui est de faire bien, je vous déjà dit à quel point on était bien conçu et rapide ?
systemd est complexe
Bonjour, veuillez regarder le bout de ce stylo s'il vous plait
FLASH
Bien sur que systemd est complexe, les ordinateurs aujourd'hui sont complexes - et comme on veut gérer l'ensemble du système de façon monolithique il est normale que ce soit compliqué et difficile à débugguer. Pour éviter les redondance on centralise les trucs avec des effets de bords WTF à la clef. Mais c'est normal !
Hop rebelotte stylo
FLASH
systemd est une usine à gaz
Mais pas du tout, avant pour lancer un service il suffisait d'avoir les droits sur l’exécutable et/ou le script concerné. Du coup n'importe qui pouvait lancer assez facilement des services sous réserve de ressources et de droits. Et bien c'est ca la vrai usine à gaz.
Nous on a un système centralisé ou pour lancer une copie d'un service qui tourne déjà avec d'autres paramètres il faut copier un template, le linker symboliquement, l'enregistrer, et finalement l'initialiser (éventuellement avec des scripts pre et post traitement) via des commandes DBus et/ou systemctl.
Pas la peine de nous remercier on aime rendre service.
systemd seulement pour Linux, pas sympa pour les BSD
systemd est un OS très différent de BSD. BSD utilise encore l'ancien système ou l'init du système sert principalement à initialiser le système puis à foutre la paix à l'admin. De part leur vision archaique ils ne peuvent pas être interressés par mon init, même si celui ci était portable, je suis sur qu'ils continueraient à me regarder avec des yeux et à me parler lentement.
systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian
Dans le monde, ce sont toujours les gens intelligents qui cèdent. Je me fait pas de soucis, ils utiliseront systemd…
(N.B : C'est fait)
systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient
On est tellement flexible, modulaire et léger que les autres systèmes seraient probablement incapables de copier les fonctionnalités simple et ciblées de systemd. Même partiellement. Honnêtement on ne peut pas porter systemd ailleurs.
systemd n’a pas de raison de ne pas être portable
On utilise partout et de façon centralisée pleins de fonctionnalités spécifiques Linux (mais en restant modulaire attention). Donc on est pas portable, centralisé, focalisé sur Linux exclusivement (mais modulairement … Et en s'inspirant de la philosophie UNIX aussi)
systemd utilise des fichiers de configuration binaire
N'importe quoi, systemd utilise des fichiers de configuration texte qui … Ah vous parliez de la configuration du comportement de systemd lui même, pas des units. Ben c'est encore plus n'importe quoi alors parce que le comportement systemd il est carrément codé en dur. Et toc !
systemd est un cauchemar de fonctionnalités
Vous pouvez penser ça aujourd'hui, mais dans 5 ans vous vous retourner et vous verrez qu'en fait il n'y avait pas tant de fonctionnalités que ça dans systemd à l'époque. En plus comme dit plus haut, vous pouvez désactiver pleins de fonctionnalités (mais ca casse votre système)
systemd vous force à faire quelque chose
Pas du tout, on est pas la mafia. Vous êtes libre de laisser votre ordinateur éteint ou de créer votre propre distrib. En plus il y a des promos sur les licences XP en ce moment. Vous êtes libres.
systemd rend impossible l’utilisation de syslog
Encore faux, systemd peut parfaitement renvoyer le contenu de journald sur syslog si vous tenez tant que ça à doubler les I/Os. J'ai dit doubler ? Mettez tripler en fait on a pas mal modifier la verbosité des logs avec notre nouveau systeme et c'est plutôt chiant à régler…
systemd est incompatible
Comme avec les scripts, du moment que vous avez les droits ROOT, que les fichiers sont là ou on vous à dit de les mettre et que vous respectez scrupuleusement les guidelines vous devriez être capables de lancer la plupart des services qui ne sont ni des sondes ni des outils de chiffrement.
Mais bon avec systemd on peut utiliser les unit d'une distribution sur une autre distribution. Je ne vois pas trop à quoi ca peut servir dans le monde professionnel ou la plupart des admins sérieux font des scripts d'init custom. Mais bon c'était très difficile à faire avant, donc on est assez fier.
systemd n’est pas scriptable, à cause de son utilisation de D-Bus
DBus est presque intégralement accessible par script depuis la plupart des clients (enfin des clients locaux) du moment que vous avez une fois de plus les droits ROOT. Donc argument invalide. Hop là, question suivante.
systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement
Ce n'est pas vrai du tout. Vous pouvez éditer les fichiers de configs avec les outils que vous voulez. C'est pour qu'ils soient pris en compte que vous devez utilisez d'obscurs outils de configuration.
systemd est instable et bogué
Totalement faux, la liste bugtracker Fedora nous indique que nous avons assez peu de problèmes avec systemd. Si l'on exclu un certain Linus T qui commence sérieusement à nous casser les pieds avec ces menaces à peine voilées on est plutôt bien.
systemd n’est pas déboguable
En fait on a tellement peu de soucis que la page pour aider à débuguer systemd fait à peine quelques lignes et qu'elle a été mise à jour la semaine dernière (enfin la semaine d'avant ce texte, parceque depuis rien, que dalle, nada. Et ceci même alors que les saturations journald et les conflits udev ont fait crasher pas mal de machines au démarrage.)
systemd fait des changements pour le plaisir de changer
Très très mensonger. On évite les changement incompatibles autant que possible, mais malheureusement parfois l'ancienne solution n'est vraiment pas assez hype pour nos développeurs. En ce qui concerne l'ajout d'un serveur DHCP dans l'init, c'était obligatoires. Parceque des raisons.
systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde
Oh mon dieu, une attaque à mon orgueuil, vite une réponse de trois pages…
Les grecs anciens n'avaient pas le concept du zéro ….
systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine
Non, nous on supporte très bien un /usr séparé. C'est Linux qui ne sait pas faire. D'ailleurs toutes les personnes qui fonctionnent avec /usr séparé, par exemple les techniques de doubles montages utilisé en pxeboot ou en /usr commun sur SAN ne marchent pas.
Mais sur systemd avoir un /usr séparé fonctionne très bien (sauf en double montage - mais que personne n'arrive à faire marcher. Je vous jure, si, si)
systemd ne permet pas de remplacer ses composants
Comme déjà vu plusieurs fois, vous pouvez remplacer à peu près n'importe quel composant de systemd, du moment que vous avez les droits ROOT, que vous remplacez avec des composants systemd plus récents et que vous n'avez pas peur de casser votre systeme.
L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque
Ahahaha. DBus utilise les sockets. Du moment que vous avez les droits root, une version custom de DBus avec tracages des paquets et la logique de désérialisation - ca n'est pas plus dur à suivre qu'un socket non DBus.
Promis j'ai commencé un vendredi, donc c'est autorisé.
[^] # Re: Droit de réponse
Posté par Kaane . En réponse au journal La SACD sur le Parti Pirate. Évalué à 4.
Tout a fait. En tous cas merci a la SACD de faire une pub pareille au Parti Pirate
Comparé à la pub que LinuxFR est en train de faire à nos amis les presseurs de disques….
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 2.
Mozilla indique que le code est fourni avec une procédure de compilation déterministe pour s'assurer de pouvoir compiler soi-même le bac-à-sable.
Je me suis mal exprimé, le fait que l'on puisse recréer à l'identique l'ensemble du logiciel (tout le binaire firefox) est en effet possible (même si je pense que ce sera complexe), mais je ne pense pas que l'on puisse créer une version fonctionnelle de la sandbox dans un firefox modifié.
Ca permet en effet de voir que Mozilla ne ment pas en disant que le binaire qu'il fournit a été compilé à partir des sources qu'il fournit également, mais ce ne changera pas grand chose au fait que si l'on modifie quoi que ce soit, le plugin adobe refusera de fonctionner.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 3.
L'API de la sandbox ne verra pas forcément passer le flux vidéo décodé
Tout le but de la sandbox est justement de ne pas donner les clefs du hardware sous jacent au plugin (sinon la sandbox ne sert à rien, a quoi ca sert de masquer l'historique de navigation si c'est pour filer les droits root au plugin quand il doit afficher une vidéo.)
Sur le schema qu'ils ont fait ici https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/ (à peu près au millieu de la page) le contenu décodé repasse bien par Firefox avant d'être affiché.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 1.
Faut il encore que cette information soit vraie… Parce que je n'ai pas lu que la sandbox allait être distribué sous forme binaire.
Elle sera probablement sous forme source également, mais je doute fort que l'on puisse compiler une version fonctionnelle. Si c'était le cas il serait extrèmement facile de créer un proxy en sortie du flux audio/vidéo décodé et d'enregistrer le flux.
Donc toute l'étape DRM ne servirait à rien.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 2.
puisque ces points me semblent respectés
A part que tu ne peux pas étudier le logiciel complet (sandbox+plugin) vu que très probablement la partie plugin va se mettre en rideau si tu fais ça, si tu modifies le code il ne sert très probablement plus à rien et si tu arrives à créer une version fonctionnelle (ie qui fonctionne avec le plugin Adobe) et que tu la diffuse, tu tombes sous le coup du Digital Millenium Act aux US et sous le coup de lois comparables au sein de l'UE.
Mais sinon oui, les 4 libertés fondamentales ne sont presque pas touchés.
[^] # Re: Que de mauvaises intentions
Posté par Kaane . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 0.
Une fois de plus je ne suis pas contre les DRM par principe. Et je ne fais pas une croisade contre les DRM ou l'implémentation des DRM par Mozilla.
Je comprend parfaitement que Mozilla soit coincé entre le marteau et l'enclume et décide de collaborer avec l'ennemi pour ne pas se faire détruire.
C'est triste mais c'est comme ça.
Ce à quoi je réagis, c'est lorsque que l'on annonce que l'interface mise en place par Mozilla pour le plugin Adobe est libre.
Un truc dont le seul but est de de faire tourner un truc non libre fermé, tout pourri n'est pas libre. Même si le code source est ouvert. On a pas la liberté de l'analyser ou de le modifier, si on le fait on perd le seul usage du truc.
Donc ce n'est pas un logiciel libre.