En même temps, y a pas de raison de dire du mal de Fedora, vu que ça n'a pas été fait sans regarder, il suffit de voir le thread sur le sujet ou il est dit que le profile hfp doit être codé ailleurs que dans bluez :
Si tu veux laisser le langage gérer ta RAM utilise java ;
En l'occurrence, non, ça gère que les cas les plus triviaux. Genre fermeture du fichier quand la variable sort du scope, etc, etc.
Enfin je pense que c'est pas dur de voir qu'il y a une des tonnes de possibilités entre "tout faire gérer" et "rien gérer du tout", donc je suis pas sur que la dichotomie soit un argument valable.
Utiliser des extension d'un compilateur empêche d'utiliser les
autres… pas très libre dans l'esprit
Tu peux rajouter qu'avec une unité, on a un feedback si la syntaxe est invalide. Alors qu'il y a pas vraiment de vérificateur de base avec bash (que je sache).
C'est en effet court, mais buggué. Si jamais tu utilises un truc genre containers, ou chroot, et que les processus sont visibles depuis l'extérieur, le processus à l'intérieur va se faire tuer aussi ( cf http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?rev=1.70;content-type=text%2Fplain ).
Mais bon, openbsd a juste chroot comme solution de container, et la virtualisation du réseau, donc c'est pas non plus l'os de choix pour ça.
De plus, sous Linux, ce script aurait un souci assez évident. Je précise sous Linux parce qu'il est possible que ça ne marche pas sous OpenBSD, donc je vais pas m'avancer avant de dire "y a peut etre un souci". Donc sous Linux, on peut changer le nom d'un process en modifiant argv[0]. Donc un utilisateur sans privilége peut faire un DoS en créant un processus, puis en le renommant en "named: [priv]" et en le faisant intercepter SIGTERM ( ou en forkant lorsqu'il reçoit le SIGTERM ) pour ne pas mourir.
Sauf erreur de ma part, le script va envoyer SIGTERM sur tout les process qui matche la regexp, puis attendre 30 secondes pour conclure "ok, j'ai bien fait mon boulot" à grand coup de pgrep. Comme il n'arrive pas à tuer tout les processus, alors il va s'arreter la. Si c'est "/etc/init.d/named start", ça se lanceras pas. Si c'est /etc/init.d/named restart", ça se relanceras pas.
Bien sur, un admin peut intervenir et corriger. Car c'est bien connu, ils ont en général que ça à faire.
Mais sinon, à part ces soucis qui dérange personne à part moi ( vu que comme tu dit, personne n'a cru bon de corriger ça depuis 2 ans ), c'est pas mal, c'est en effet bien plus clair que la majorité des scripts d'init que j'ai pu lire.
Chaque script d'init s'occupe d'une seule chose et s'exécute
dans un ordre bien précis.
Ce qui est bien, c'est que comme tu restes dans le vague, on peut pas te contredire. Donc je vais arbitrairement prendre Debian comme exemple en partant du principe qu'il y a que Debian ou Ubuntu avec /etc/default, et parce tout mes autres serveurs sont en systemd ( en fait, la Debian aussi, mais y a pas d'unité sauf les miennes ). et te montrer que non, si ta distrib est Debian, alors les scripts font plus que "juste une chose" et qu'en fait, ils font des tas de trucs pour "juste une chose" qui est "lancer un programme".
On va prendre par exemple bind9. Dans le script de bind9, le script fait :
- l'ajout de localhost dans /etc/resolv.conf de façon conditionnel
- le chargement d'un module ( capabilities )
- la creation de /var/run/named
- vérifie que le réseau est configuré avant de lancer bind
Une chose et une seule ? Le chargement du module, c'est le script kmod qui doit le faire, pas lui. La creation d'un repertoire, c'est l'ordre du paquet. Et la vérification du réseau, c'est pas pour ça qu'on a les dependances LSB et que "tout se lance dans l'ordre" ?
On peut voir dbus. Il fait :
- création du repertoire pour le pid
- vérification si /proc est monté
- génere un fichier /etc/machine-id si absent
On retrouve le même pattern, vérification que tout est en place ( le reseau, /proc ) pour palier à des dépendances qu'on peut pas exprimer avec la LSB ( genre le fait d'avoir /proc ). Et la création des fichiers, chose qui devrait être fait par le paquet ou en postinst.
Ok, un autre script au hasard, celui de saslauthd. 400 lignes.
Une grande partie de la complexité vient du fait que ce script gère le fait de lancer plusieurs instances du serveur ( stop_instance, start_instance ), qu'il duplique la logique de création de répertoire avec les autres scripts, fonction createdir ( en prenant en compte selinux, contrairement aux 2 autres, ce qui fait qu'il y a soit du code en trop dans le dernier, soit des bugs dans mes 2 autres exemples ).
Il refait aussi son propre oneliner pour parser la ligne de commande de saslauthd, qui est fourni par la configuration en bash:
Code copier coller entre le start et le stop, au passage.
Donc ça fait un chouia plus que "juste lancer le daemon". Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.
Un autre exemple pour la route ?
Le script de postfix fait une vérification de la config de postfix pour voir si tu n'a pas mis "ubuntu.com ou debian.org" ( le commentaire dit "c'est pas bon, et ça fait chier les admins des domaines" ).
Il gère aussi la création du chroot pour postfix. La création du chroot implique d'analyser le fichier de config pour savoir ce qu'il faut copier, mais il y a postconf pour ça. Il y a aussi besoin de savoir si il faut un chroot ou pas, via ce morceau si claire d'awk ( car bon, faire ça en bash tu peux pas, faut faire appel à un outil externe ) :
Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.
Ton exemple est le moins cryptique qu'on puisse trouver. Un truc comme :
*/5 10 * * 2 /usr/local/bin/yourjob
Est cryptique.
Bien sur, il est cryptique car il a pas beaucoup de sens ( le job est lancé tout les mardis, à 10h par intervalles de 5 minutes, c'est assez peu courant et compliqué à souhait ).
A comparer avec :
0 */2 */3 * * /usr/local/bin/yourjob
Lancer tout les 3 jours, et avec un intervalle de 2 heures entre chaque job.
Pour les trucs simples, c'est assez simple ( une fois que tu penses à mettre 0 et pas * pour lancer une fois par heure, et quand tu penses que c'est rangé par ordre de durée ( minute -> heure -> jour -> mois ), modulo une exception pour le jour de la semaine ). Pour les trucs compliqués, c'est vachement plus compliqués.
Une autre conséquence de cette évolution rapide est que ce
logiciel est tous sauf stable et bien testé. Il s'agit au mieux
d'un soft de qualité béta.
La version 208 est listé comme LTS, et elle est intégré dans RHEL 7. Que je sache, il y a une équipe QA dédié pour justement s'assurer que les logiciels soit pas dans l'état "pas stable" pour la version finale. De ce que je vois sur ma machine de test, c'est une version 208 qui est fourni, version 208 aussi listé comme "LTS" par l'upstream de systemd, avec une branche git dédié.
On peut rajouter que pour un truc que tu qualifies de béta, y a plein de distro qui l'utilise ( Mageia, Arch, Fedora, Opensuse ), qu'il y a des hébergeurs qui l'utilisent en prod ( Pantheon system, qui parle de 500 000 unités lancés https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units , Flow Pilots ( http://savanne.be/articles/deploying-node-js-with-systemd/ ). Il y a des boites qui l'utilisent comme CoreOS qui fait un OS dédié à avoir systemd, docker et des outils de gestions, ou Axis ( vu les patchs qui passent sur la ml ).
Le problème pour comprendre systemd est que ce logiciel évolue
à toute vitesse et que pour le comprendre et suivre cette
évolution, il faut être un développeur payé à plein temps pour
ça.
Ma foi, je vais devoir demander à mon employeur de me payer un deuxiéme salaire, car j'arrive à suivre sans bosser à plein temps dessus. En fait, sans être payé pour regarder systemd, juste par curiosité.
C'est clairement plus complexe. Et je pense que l'article "remplacer cron par systemd" est trompeur, les 2 ne font pas les mêmes choses ( exemple, systemd envoie pas de mail que je sache quand un tache est lancé ). L'idée est plus de complémenter que de remplacer.
Systemd propose des choses que cron propose pas. La gestion fines des ressources intégré dans l'unité est AMHA important pour un usage dans un adre de serveur. Par exemple, la gestion des backups et des taches nocturnes ( genre la tache de backup qui prends pas tout les i/o sur le serveur ).
La précision des timers de systemd est aussi plus fine.
OnActiveSec fait la même chose que at, OnBootSec permet de delayer le lancement d'une tache aprés le boot ( cron ne supporte que @boot je crois ). OnUnitActiveSec permet de dire "toutes les 17 minutes et 5 secondes", chose qu'on peut pas vraiment faire proprement avec cron ( non pas que ça me manque en pratique, les gens sont content d'arrondir à "toutes les 10 minutes", ou à faire une magouille à base de script et d'estimation par pgcd ).
Les timers ont aussi une résolution inférieur à la minute, ce qui est un plus dans certains cas ( je pense par exemple pour de l'embarqué ).
Et la syntaxe est aussi AMHA plus simple à comprendre, car bon, sans la doc ajouté par un patch externe à cron ( come le fait Debian et Mageia ) quand on fait crontab -e ( qui rajoute "# m h dom mon dow command" en guise de doc ), la syntaxe de "* * 5 * * /bin/foo" est pas super intuitive par rapport à celle de systemd, dont acte :
OnCalendar=08:05
vs
5 8 * * * /bin/foo
Donc non, on remplace pas cron par systemd, mais systemd peut apporter des choses à certains.
Non, vraiment, le code a l'air bon et bien compartimenté.
Le code est aussi plus moderne et agréable que ce que j'ai pu lire ailleurs. Par exemple, ça utilise largement des fonctionnalités de gcc pour nettoyer les variables automatiquement ( via l'attribut cleanup ) pour éviter les fuites de mémoires. Il y a un coding style assez détaillé et qui est suivi. Il y a une suite de tests, assez de commentaires pour piger ce qui se passe dans les cas compliqués. Et y a pas des tonnes de #ifdef en fonction de la plateforme.
Pour avoir lu en détail celui de upstart et de systemd ( mon but était de rajouter le support du protocole d'activation à upstart ), celui de systemd m'a paru bien plus facile à comprendre et à modifier.
pourquoi ils n’ont pas choisi un de ces projets il y a des
années ? parce que le bash de 2009 était maintenable mais le
bash de 2014 ne l’est plus ?
Ubuntu est passé sur upstart, Fedora aussi, et Opensuse/Mandrake allait le faire. Gentoo utilise autre chose que sysv init.
Solaris et Os X ont refait un init. Le hurd a revu les concepts de runlevels depuis le début car non adaptés.
Donc je pense que les distributeurs ou assimilés ont tentés de faire des choses, oui.
Ensuite, la question est en fonction de chaque OS. Launchd n'était pas portable, je suppose SMF non plus. Il reste donc upstart, qui a un certain nombre de souci de design ( utilisation de ptrace pour suivre les processus, syntaxe de la conf pas super intuitive ) en plus d'avoir un CLA qui a limité les contributions externes (selon moi).
pourquoi slackware, maintenu par une seule personne donc en
première ligne pour les questions de difficulté de
maintenance, veut retarder le plus possible son adoption ?
Faut lui demander. Mais il me semble plus évident que ne pas migrer coute moins cher que migrer, sauf que du coup, tu restes sur les vieux soucis, sans avoir les nouvelles fonctions. On peut retourner la question de slackware sur le fait d'avoir son propre format de paquet.
pourquoi les BSD n’abandonnent pas les initscripts si c’est
une telle charge de travail à maintenir ?
Et les devs BSD ont déjà des choses plus urgentes à faire. Comme essayer de suivre linux pour les pilotes graphiques ( ex kms ). Le souci, c'est pas que le code en bash soit si difficile à maintenir si tu connais le bash. C'est comme écrire ton site web en C, ça se fait. Le souci, c'est d'écrire ça comme il faut la première fois. C'est une barrière à la contribution inutile pour les packageurs.
En fait, JBoss est le nom commercial d'une famille de projets mais il y a eu renommage du projet de base ( ie, le serveur d'application ) en Wildfly ( il y a eu séparation du nom pour réduire la confusion entre version communautaire et version entreprise, et ça a déjà fait couler beaucoup d'encre virtuel, je vais pas en rajouter ).
Et c'est donc dans le cadre de wildfly/Jboss qu'on retrouve notamment des projets libres à coté ( parfois aussi nommé jboss ) qui sont en concurrence direct des produits d'Oracle, comme par exemple Jboss EAP qui va en frontal face à Oracle Weblogic. Sauf qu'un est libre, l'autre non.
On trouve des libs pour distribuer le contenu, pour mettre un systéme de messaging ( genre amqp, etc ), des trucs pour faire tourner du ruby sur jboss, pour manager des instances, etc, etc.
J'ai pas les détails, je suis pas à fond dans java, loin de la, je me contente juste de suivre les discussions de mes collègues. Et je vois que je suis vachement perdu aujourd'hui :)
Coreos supporte uniquement amd64 car il faut bien se rendre compte que si ton but est d'avoir un consommation de courant minimal ( cas typique d'avoir une board arm à la place d'un pc complet pour chez toi ), tu va pas commencer à faire un cluster de machine.
De plus, docker n'a pas l'air d'avoir eu un port ARM pendant longtemps ( https://github.com/dotcloud/docker/issues/636 ), et il faut bien voir que l'avantage de docker, c'est d'avoir aussi une liste d'image dans leur index, et que les images sont mono-arch pour le moment. Et que tout refaire, ça revient à refaire tout le travail d'une distribution, ce que visiblement, les gens veulent pas ( sinon, ils feraient une distro, soyons honnêtes )
Systemd est intégré, oui. Et bash est présent ( via le module bash de dracut ), mais pas awk ni rien d'autre. Bash est présent uniquement pour le shell de secours, et visiblement parce que dracut est écrit en shell. Savoir si c'est remplaçable par dash/ash/sh est un exercise pour le lecteur.
La portabilité, c'est trés surfait. par exemple, awesome est minimaliste, mais est ce qu'il est portable ? Par exemple, je peux faire tourner ça sur ios, android ou windows ?
Ou est ce que la portabilité est une notion faiblement défini par "portable sur ce qui me parait important et fuck off les chiffres et les stats qui montrent que ça reste 1% du parc" ?
Sauf que si tu regardes un peu autour de toi, tu va voir que le monde n'est pas composé uniquement de machines de bureau surdimensionnés.
D'une part, quand tu produit des appareils à des millions d'exemplaire, ton histoire de la barrette de ram devient "pourquoi ne pas avoir acheté des millions de barrettes de ram" ce qui reviens d'un coup à "pourquoi ne pas avoir dépenser beaucoup plus de pognon en achat, en logistique et en test". D'ailleurs, il suffit de voir qui teste networkd sur la list, et tu va voir des emails @intel.com, @axis.com .
Ou simplement que malgré le fait qu'on trouve des Giga de ram, on trouve pas encore des giga sur les contrôleurs embarqués et sur toutes les pièces d'un appareil.
Et d'autre part, la tendance est à faire des conteneurs pour augmenter la densité du nombre de service par machine. Donc quand tu tapes dans les 2/3, ça va, ça fait pas grand choses. Quand tu tapes dans les centaines, tout d'un coup, ça commence à faire un multiplicateur qui rends la chose un chouia moins futile que tu sembles le croire, aussi bien en temps de démarrage qu'en occupation mémoire.
Donc oui, je pense que Moonz a raison de pointer l'overhead de systemd lui même par rapport à /bin/init du bon vieux temps, et que même si ça semble futile, ça reste un point à regarder. Mais comme j'ai dit plus loin, j'ai changé juste un paramètre à la fois pour comparer.
Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.
Sinon, je pourrait aussi dire "bah je flash coreboot et je boote direct sur un kernel qui lance un shell en 2 secondes" comme sur la demo ici ( https://www.youtube.com/watch?v=IKBtQYNrsBU ) et conclure "tout est bloated, il suffit juste que tout le monde tourne sur exactement mon pc et mon setup".
Il y a bien sur sans doute toujours moyen de faire plus spécialisé et qui prends le moins possible de place ( genre coder en dur les ip partout, voir pousser directement ça sur la stack du kernel ), mais l'exercise me parait futile.
Ensuite, je reconnait que le script network fait beaucoup plus que networkd. Par exemple, il gére l'isdn [~1.4M pour le rpm), le ppp (380k pour le soft), le dhcpv6, le bonding via teamd ( 250k ) ou ipx. Donc c'est pas vraiment à feature égal.
Mais sachant que je doute que l'isdn, le ppp ou ipx dans l'initrd soit vraiment présent dans la majorité des cas, je vois pas l’intérêt de prendre ça en compte. Et malgré le fait que ça soit fait de manière ad-hoc, comprendre "à l'arrache", en ne copiant pas ce qui ne doit pas être copié sans avoir vraiment de vision haut niveau de ce qui est requis, le script network marche sans la majorité des dépendances. Alors que bash et awk sont requis.
J'ai non plus pas compté les 400k de iputils, car je part du principe que même si c'est pas requis pour que networkd fonctionne, dans le cas d'une machine de rescue, on peut en avoir besoin. mais si le but est juste de comparer la taille sans prendre en compte le rescue (ce qui me semble tricher un peu, car je pense qu'on a besoin des outils), on peut retirer ça et mettre networkd, et voila.
Et en compilant systemd sans selinux, on retire les 400k de la libpcre, et les 140k de la libselinux, et j'imagine qu'avec kdbus, on peut sans doute retirer les 430k de dbus-daemon.
Je suis pas sur pour la libdbus car systemd a sa propre lib pour le support de dbus et de kdbus, et je suis pas assez courageux pour faire un make install sur ma bécane de prod, ni assez motivé pour faire une vm pour vérifier l'hypothèse.
Donc oui, dans le cas d'un initrd avec systemd/udev/etc, mettre networkd à la place du script network permet d'avoir un solution plus économe à mon sens. Mais tu peux sans doute faire mieux en sacrifiant des features qui te paraisse superflu (sans discuter du fait qu'elles le soit ou pas pour d'autres, et je reconnais bien volontiers que pas grand monde n'a besoin des vlans dans l'initrd par exemple)
C'est comme démarrer directement erlang depuis xen directement. C'est custom made, c'est rapide, ça permet d'avoir des choses qu'on arrive pas à avoir autrement mais voila, la majorité des gens vont pas utiliser ça.
Rajoute "et parce que toute les machines ne sont pas équipés en IMPI ou carte d'admin couteuses, ce qui permet d'adresser le marché des hobbyistes ayant leur serveur sous forme d'un shuttle dans le salon".
Et comme je peux pas me fatiguer à répondre à la même question sur le réseau, avoir un rescue sur le systéme qui a le réseau ça permet par exemple de télécharger le fichier de la glibc qu'on a écrasé par erreur depuis le rescue.
Bien sur, on arrive à se débrouiller autrement quand on a pas le réseau, mais je peux imaginer que ça peut faciliter la vie.
Et ça prends aussi moins de place dans l'initrd, au moins sur Fedora.
systemd-networkd fait 343k après passage de strip, bash + /etc/init.d/network + divers scripts dans /etc/sysconfig/network-scripts/ , ça fait 960k + ~100k de scripts.
Et si on me dit "mais networkd- tire la libpcre, ça fait 410k de plus", je dirais que les scripts d'init tire gawk, qui fait 570k.
Nan mais commence pas à ruiner tout l'argumentaire avec des vrais features et des use cases qui sont pas tirés par les cheveux, tu te rends compte que Linuxfr vit grace aux contributions, et que systemd a augmenté les contributions sur les commentaires :)
Les arguments à l'époque était sur les appels de fonctions dbus. La, on parle de fonctions en C et la différence entre avant et maintenant, c'est ce sur quoi tu lies ton binaire.
Networkmanager fait beaucoup plus de choses, genre le wifi, le bluetooth, le ppp. Il gère les proxys dns ( via dnsmasq) et le partage de connexion.
La, je pense que l'idée est surtout de remplacer /etc/init.d/network ( sur fedora ), et l'idée n'est pas non plus de Lennart, mais de Tom Gundersen, packageur Arch.
En même temps, faut pas se voiler la face. AppArmor a failli disparaitre sans Canonical qui voulait avoir une alternative à SELinux, car Novell avait finalement décidé de lacher l'affaire. At AppArmor est en retard niveau intégration partout ailleurs, car Canonical n'a pas vraiment les ressources.
Pr exemple, dbus a d'abord supporté SELinux, puis AppArmor. Postgresql supporte la séparation par SELinux, pas par AppArmor. Des distros comme Gentoo, Debian ou Fedora ont supportés SELinux bien en premier, puis vaguement Apparmor. Les seuls à avoir AppArmor de base sont celles ou le sponsor a décidé d'en haut de pousser la techno, ie Ubuntu et Opensuse. IE, la communauté poussant AppArmor est pas très grande.
Et je peux détailler en long, en large et en travers pourquoi à mon sens AppArmor est plus primitif et moins extensible que SELinux.
Par exemple, AppArmor utilise des chemins pour les permissions et les accès la ou SELinux rajoute une couche d'indirection, ce qui le rends impropre a un usage comme "ce document est noté top secret, personne doit le lire". Apparmor ne supporte pas trop le concept de MLS ( mais sur la TODO list http://wiki.apparmor.net/index.php/AppArmorMLS ). Et c'est pas un exemple purement théorique non utilisé en pratique, car tout openshift dépend de ça pour l'isolation des gens.
Autre example, changer le repertoire racine d'un serveur web. Sous SELinux, tu changes le label du répertoire via semanage fcontext, et voila. Sous AppArmor avec le système de profile, tu doit modifier tout les profiles pour copier les permissions. Mais donc du coup, pour palier à ce cas, ils ont rajouté le concept d'alias. Donc tu va dire que /var/www/ est un alias vers /home/www et donc que les accès de l'un correspondent aux accès de l'autre. Donc la ou une solution élégante est en place, on rajoute un truc de plus.
Je pourrais dire comment les politiques de sécurité SELinux sont configurable via des booleans, etc, etc. Et comment la config de apparmor, c'est juste des variables prédéfinis. En théorie, on peut faire la même chose avec AppArmor, sauf qu'en pratique, c'est quasiment du tout ou rien.
Je pourrait rajouter comment le fait de rajouter un nouveau type d'objet ( genre les sockets réseau ) implique de rajouter une option au parser, des nouveaux types d'objet dans la lib et de tout recompiler, la ou SELinux fait ça de façon indépendante du code dans le kernel et le reste, tout dans sa policy ( et avec du code pour l'arbitrage dans le programme qui va se servir de la policy, bien sur ). Comprendre comment faire ça, c'est globalement un workshop de 2h pour quelqu'un qui sait écrire une policy.
Alors ouais, SELinux semble s'avancer pour devenir quasiment un choix "normaliser" ( mais ça reste plus que relatif, car le défaut pour la majorité des distros, ça va surtout être "rien" ). Mais c'est surtout que ç'est plus extensible, ce qui permet de faire plus de choses, ce qui fait qu'il y a un marché pour ça, et donc des investissements.
[^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 2.
En même temps, y a pas de raison de dire du mal de Fedora, vu que ça n'a pas été fait sans regarder, il suffit de voir le thread sur le sujet ou il est dit que le profile hfp doit être codé ailleurs que dans bluez :
https://lists.fedoraproject.org/pipermail/devel/2014-January/194512.html
Et notamment la partie sur "bluez 4 n'était plus maintenu depuis 1 an"
https://lists.fedoraproject.org/pipermail/devel/2014-January/194757.html
Et que la QA de Fedora a vu la regression, mais n'a pas jugé ça suffisamment important pour bloquer la release :
https://lists.fedoraproject.org/pipermail/devel/2014-January/194375.html
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 5.
En l'occurrence, non, ça gère que les cas les plus triviaux. Genre fermeture du fichier quand la variable sort du scope, etc, etc.
Enfin je pense que c'est pas dur de voir qu'il y a une des tonnes de possibilités entre "tout faire gérer" et "rien gérer du tout", donc je suis pas sur que la dichotomie soit un argument valable.
Sauf si l'extension est compatible.
En l'occurrence, on parle de ça :
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/macro.h#n47
Utilisé pour ça :
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/path-lookup.c#n93
Et la doc pour GCC est la :
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
Et c'est compatible avec llvm, cf ce morceau du code de llvm :
https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/Attr.td#L482
Il y a des gens qui compilent systemd avec clang, des patchs qui remontent donc c'est pas par hasard non plus.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 7.
Tu peux rajouter qu'avec une unité, on a un feedback si la syntaxe est invalide. Alors qu'il y a pas vraiment de vérificateur de base avec bash (que je sache).
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.
C'est en effet court, mais buggué. Si jamais tu utilises un truc genre containers, ou chroot, et que les processus sont visibles depuis l'extérieur, le processus à l'intérieur va se faire tuer aussi ( cf http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?rev=1.70;content-type=text%2Fplain ).
Mais bon, openbsd a juste chroot comme solution de container, et la virtualisation du réseau, donc c'est pas non plus l'os de choix pour ça.
De plus, sous Linux, ce script aurait un souci assez évident. Je précise sous Linux parce qu'il est possible que ça ne marche pas sous OpenBSD, donc je vais pas m'avancer avant de dire "y a peut etre un souci". Donc sous Linux, on peut changer le nom d'un process en modifiant argv[0]. Donc un utilisateur sans privilége peut faire un DoS en créant un processus, puis en le renommant en "named: [priv]" et en le faisant intercepter SIGTERM ( ou en forkant lorsqu'il reçoit le SIGTERM ) pour ne pas mourir.
Sauf erreur de ma part, le script va envoyer SIGTERM sur tout les process qui matche la regexp, puis attendre 30 secondes pour conclure "ok, j'ai bien fait mon boulot" à grand coup de pgrep. Comme il n'arrive pas à tuer tout les processus, alors il va s'arreter la. Si c'est "/etc/init.d/named start", ça se lanceras pas. Si c'est /etc/init.d/named restart", ça se relanceras pas.
Bien sur, un admin peut intervenir et corriger. Car c'est bien connu, ils ont en général que ça à faire.
Mais sinon, à part ces soucis qui dérange personne à part moi ( vu que comme tu dit, personne n'a cru bon de corriger ça depuis 2 ans ), c'est pas mal, c'est en effet bien plus clair que la majorité des scripts d'init que j'ai pu lire.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.
Ce qui est bien, c'est que comme tu restes dans le vague, on peut pas te contredire. Donc je vais arbitrairement prendre Debian comme exemple en partant du principe qu'il y a que Debian ou Ubuntu avec /etc/default, et parce tout mes autres serveurs sont en systemd ( en fait, la Debian aussi, mais y a pas d'unité sauf les miennes ). et te montrer que non, si ta distrib est Debian, alors les scripts font plus que "juste une chose" et qu'en fait, ils font des tas de trucs pour "juste une chose" qui est "lancer un programme".
On va prendre par exemple bind9. Dans le script de bind9, le script fait :
- l'ajout de localhost dans /etc/resolv.conf de façon conditionnel
- le chargement d'un module ( capabilities )
- la creation de /var/run/named
- vérifie que le réseau est configuré avant de lancer bind
Une chose et une seule ? Le chargement du module, c'est le script kmod qui doit le faire, pas lui. La creation d'un repertoire, c'est l'ordre du paquet. Et la vérification du réseau, c'est pas pour ça qu'on a les dependances LSB et que "tout se lance dans l'ordre" ?
On peut voir dbus. Il fait :
- création du repertoire pour le pid
- vérification si /proc est monté
- génere un fichier /etc/machine-id si absent
On retrouve le même pattern, vérification que tout est en place ( le reseau, /proc ) pour palier à des dépendances qu'on peut pas exprimer avec la LSB ( genre le fait d'avoir /proc ). Et la création des fichiers, chose qui devrait être fait par le paquet ou en postinst.
Ok, un autre script au hasard, celui de saslauthd. 400 lignes.
Une grande partie de la complexité vient du fait que ce script gère le fait de lancer plusieurs instances du serveur ( stop_instance, start_instance ), qu'il duplique la logique de création de répertoire avec les autres scripts, fonction createdir ( en prenant en compte selinux, contrairement aux 2 autres, ce qui fait qu'il y a soit du code en trop dans le dernier, soit des bugs dans mes 2 autres exemples ).
Il refait aussi son propre oneliner pour parser la ligne de commande de saslauthd, qui est fourni par la configuration en bash:
Code copier coller entre le start et le stop, au passage.
Donc ça fait un chouia plus que "juste lancer le daemon". Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.
Un autre exemple pour la route ?
Le script de postfix fait une vérification de la config de postfix pour voir si tu n'a pas mis "ubuntu.com ou debian.org" ( le commentaire dit "c'est pas bon, et ça fait chier les admins des domaines" ).
Il gère aussi la création du chroot pour postfix. La création du chroot implique d'analyser le fichier de config pour savoir ce qu'il faut copier, mais il y a postconf pour ça. Il y a aussi besoin de savoir si il faut un chroot ou pas, via ce morceau si claire d'awk ( car bon, faire ça en bash tu peux pas, faut faire appel à un outil externe ) :
Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.
[^] # Re: À corriger
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 2.
dans le même genre, le nom du portable, c'est "lenovo yoga", pas yago.
[^] # Re: Timers
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 6.
Ton exemple est le moins cryptique qu'on puisse trouver. Un truc comme :
Est cryptique.
Bien sur, il est cryptique car il a pas beaucoup de sens ( le job est lancé tout les mardis, à 10h par intervalles de 5 minutes, c'est assez peu courant et compliqué à souhait ).
A comparer avec :
Lancer tout les 3 jours, et avec un intervalle de 2 heures entre chaque job.
Pour les trucs simples, c'est assez simple ( une fois que tu penses à mettre 0 et pas * pour lancer une fois par heure, et quand tu penses que c'est rangé par ordre de durée ( minute -> heure -> jour -> mois ), modulo une exception pour le jour de la semaine ). Pour les trucs compliqués, c'est vachement plus compliqués.
[^] # Re: Merci Lennart (and sinma)
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 4.
Virer les macs est aussi une solution…
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 5.
La version 208 est listé comme LTS, et elle est intégré dans RHEL 7. Que je sache, il y a une équipe QA dédié pour justement s'assurer que les logiciels soit pas dans l'état "pas stable" pour la version finale. De ce que je vois sur ma machine de test, c'est une version 208 qui est fourni, version 208 aussi listé comme "LTS" par l'upstream de systemd, avec une branche git dédié.
On peut rajouter que pour un truc que tu qualifies de béta, y a plein de distro qui l'utilise ( Mageia, Arch, Fedora, Opensuse ), qu'il y a des hébergeurs qui l'utilisent en prod ( Pantheon system, qui parle de 500 000 unités lancés https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units , Flow Pilots ( http://savanne.be/articles/deploying-node-js-with-systemd/ ). Il y a des boites qui l'utilisent comme CoreOS qui fait un OS dédié à avoir systemd, docker et des outils de gestions, ou Axis ( vu les patchs qui passent sur la ml ).
Ma foi, je vais devoir demander à mon employeur de me payer un deuxiéme salaire, car j'arrive à suivre sans bosser à plein temps dessus. En fait, sans être payé pour regarder systemd, juste par curiosité.
[^] # Re: Timers
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 9.
C'est clairement plus complexe. Et je pense que l'article "remplacer cron par systemd" est trompeur, les 2 ne font pas les mêmes choses ( exemple, systemd envoie pas de mail que je sache quand un tache est lancé ). L'idée est plus de complémenter que de remplacer.
Systemd propose des choses que cron propose pas. La gestion fines des ressources intégré dans l'unité est AMHA important pour un usage dans un adre de serveur. Par exemple, la gestion des backups et des taches nocturnes ( genre la tache de backup qui prends pas tout les i/o sur le serveur ).
La précision des timers de systemd est aussi plus fine.
OnActiveSec fait la même chose que at, OnBootSec permet de delayer le lancement d'une tache aprés le boot ( cron ne supporte que @boot je crois ). OnUnitActiveSec permet de dire "toutes les 17 minutes et 5 secondes", chose qu'on peut pas vraiment faire proprement avec cron ( non pas que ça me manque en pratique, les gens sont content d'arrondir à "toutes les 10 minutes", ou à faire une magouille à base de script et d'estimation par pgcd ).
Les timers ont aussi une résolution inférieur à la minute, ce qui est un plus dans certains cas ( je pense par exemple pour de l'embarqué ).
Et la syntaxe est aussi AMHA plus simple à comprendre, car bon, sans la doc ajouté par un patch externe à cron ( come le fait Debian et Mageia ) quand on fait crontab -e ( qui rajoute "# m h dom mon dow command" en guise de doc ), la syntaxe de "* * 5 * * /bin/foo" est pas super intuitive par rapport à celle de systemd, dont acte :
vs
Donc non, on remplace pas cron par systemd, mais systemd peut apporter des choses à certains.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.
Le code est aussi plus moderne et agréable que ce que j'ai pu lire ailleurs. Par exemple, ça utilise largement des fonctionnalités de gcc pour nettoyer les variables automatiquement ( via l'attribut cleanup ) pour éviter les fuites de mémoires. Il y a un coding style assez détaillé et qui est suivi. Il y a une suite de tests, assez de commentaires pour piger ce qui se passe dans les cas compliqués. Et y a pas des tonnes de #ifdef en fonction de la plateforme.
Pour avoir lu en détail celui de upstart et de systemd ( mon but était de rajouter le support du protocole d'activation à upstart ), celui de systemd m'a paru bien plus facile à comprendre et à modifier.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.
Ubuntu est passé sur upstart, Fedora aussi, et Opensuse/Mandrake allait le faire. Gentoo utilise autre chose que sysv init.
Solaris et Os X ont refait un init. Le hurd a revu les concepts de runlevels depuis le début car non adaptés.
Donc je pense que les distributeurs ou assimilés ont tentés de faire des choses, oui.
Ensuite, la question est en fonction de chaque OS. Launchd n'était pas portable, je suppose SMF non plus. Il reste donc upstart, qui a un certain nombre de souci de design ( utilisation de ptrace pour suivre les processus, syntaxe de la conf pas super intuitive ) en plus d'avoir un CLA qui a limité les contributions externes (selon moi).
Faut lui demander. Mais il me semble plus évident que ne pas migrer coute moins cher que migrer, sauf que du coup, tu restes sur les vieux soucis, sans avoir les nouvelles fonctions. On peut retourner la question de slackware sur le fait d'avoir son propre format de paquet.
http://wiki.netbsd.org/projects/project/launchd-port/
http://www.phoronix.com/forums/showthread.php?91776-Apple-s-OS-X-Launchd-Being-Ported-To-FreeBSD
Et les devs BSD ont déjà des choses plus urgentes à faire. Comme essayer de suivre linux pour les pilotes graphiques ( ex kms ). Le souci, c'est pas que le code en bash soit si difficile à maintenir si tu connais le bash. C'est comme écrire ton site web en C, ça se fait. Le souci, c'est d'écrire ça comme il faut la première fois. C'est une barrière à la contribution inutile pour les packageurs.
[^] # Re: 1997. 2x plus cher. A-t-il évolué?
Posté par Misc (site web personnel) . En réponse au journal Le jeu Earth 2140 arrive enfin sous Linux !. Évalué à 10.
Non, mais ce qui est notable, c'est que l'auteur du journal ne parle pas de Suse.
# JBoss est plus qu'un projet
Posté par Misc (site web personnel) . En réponse au journal Red Hat réécrit un logiciel sous GPLv2 de peur de violer des brevets Oracle. Évalué à 7.
En fait, JBoss est le nom commercial d'une famille de projets mais il y a eu renommage du projet de base ( ie, le serveur d'application ) en Wildfly ( il y a eu séparation du nom pour réduire la confusion entre version communautaire et version entreprise, et ça a déjà fait couler beaucoup d'encre virtuel, je vais pas en rajouter ).
Et c'est donc dans le cadre de wildfly/Jboss qu'on retrouve notamment des projets libres à coté ( parfois aussi nommé jboss ) qui sont en concurrence direct des produits d'Oracle, comme par exemple Jboss EAP qui va en frontal face à Oracle Weblogic. Sauf qu'un est libre, l'autre non.
voir http://wildfly.org/ et https://www.jboss.org/projects
On trouve des libs pour distribuer le contenu, pour mettre un systéme de messaging ( genre amqp, etc ), des trucs pour faire tourner du ruby sur jboss, pour manager des instances, etc, etc.
J'ai pas les détails, je suis pas à fond dans java, loin de la, je me contente juste de suivre les discussions de mes collègues. Et je vois que je suis vachement perdu aujourd'hui :)
[^] # Re: Quid du support d'ARMv7 & ARMv8 ?
Posté par Misc (site web personnel) . En réponse au journal Systemd, Docker, NetworkD, EtcD, FleetCTL | CoreOS : Le Cloud n'est pas un Fog .. Évalué à 3.
Coreos supporte uniquement amd64 car il faut bien se rendre compte que si ton but est d'avoir un consommation de courant minimal ( cas typique d'avoir une board arm à la place d'un pc complet pour chez toi ), tu va pas commencer à faire un cluster de machine.
De plus, docker n'a pas l'air d'avoir eu un port ARM pendant longtemps ( https://github.com/dotcloud/docker/issues/636 ), et il faut bien voir que l'avantage de docker, c'est d'avoir aussi une liste d'image dans leur index, et que les images sont mono-arch pour le moment. Et que tout refaire, ça revient à refaire tout le travail d'une distribution, ce que visiblement, les gens veulent pas ( sinon, ils feraient une distro, soyons honnêtes )
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 2.
Systemd est intégré, oui. Et bash est présent ( via le module bash de dracut ), mais pas awk ni rien d'autre. Bash est présent uniquement pour le shell de secours, et visiblement parce que dracut est écrit en shell. Savoir si c'est remplaçable par dash/ash/sh est un exercise pour le lecteur.
[^] # Re: Et si on lisait un peu plus loin ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 4.
C'est chose faite :
http://cgit.freedesktop.org/systemd/systemd/commit/?id=03e37dd767e52908f30783d9b4c09fb6a4e865c7
Et une release est prévu sous peu.
[^] # Re: Le nid à trolls
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 3.
La portabilité, c'est trés surfait. par exemple, awesome est minimaliste, mais est ce qu'il est portable ? Par exemple, je peux faire tourner ça sur ios, android ou windows ?
Ou est ce que la portabilité est une notion faiblement défini par "portable sur ce qui me parait important et fuck off les chiffres et les stats qui montrent que ça reste 1% du parc" ?
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 8.
Sauf que si tu regardes un peu autour de toi, tu va voir que le monde n'est pas composé uniquement de machines de bureau surdimensionnés.
D'une part, quand tu produit des appareils à des millions d'exemplaire, ton histoire de la barrette de ram devient "pourquoi ne pas avoir acheté des millions de barrettes de ram" ce qui reviens d'un coup à "pourquoi ne pas avoir dépenser beaucoup plus de pognon en achat, en logistique et en test". D'ailleurs, il suffit de voir qui teste networkd sur la list, et tu va voir des emails @intel.com, @axis.com .
Ou simplement que malgré le fait qu'on trouve des Giga de ram, on trouve pas encore des giga sur les contrôleurs embarqués et sur toutes les pièces d'un appareil.
Et d'autre part, la tendance est à faire des conteneurs pour augmenter la densité du nombre de service par machine. Donc quand tu tapes dans les 2/3, ça va, ça fait pas grand choses. Quand tu tapes dans les centaines, tout d'un coup, ça commence à faire un multiplicateur qui rends la chose un chouia moins futile que tu sembles le croire, aussi bien en temps de démarrage qu'en occupation mémoire.
Donc oui, je pense que Moonz a raison de pointer l'overhead de systemd lui même par rapport à /bin/init du bon vieux temps, et que même si ça semble futile, ça reste un point à regarder. Mais comme j'ai dit plus loin, j'ai changé juste un paramètre à la fois pour comparer.
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 4.
Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.
Sinon, je pourrait aussi dire "bah je flash coreboot et je boote direct sur un kernel qui lance un shell en 2 secondes" comme sur la demo ici ( https://www.youtube.com/watch?v=IKBtQYNrsBU ) et conclure "tout est bloated, il suffit juste que tout le monde tourne sur exactement mon pc et mon setup".
Il y a bien sur sans doute toujours moyen de faire plus spécialisé et qui prends le moins possible de place ( genre coder en dur les ip partout, voir pousser directement ça sur la stack du kernel ), mais l'exercise me parait futile.
Ensuite, je reconnait que le script network fait beaucoup plus que networkd. Par exemple, il gére l'isdn [~1.4M pour le rpm), le ppp (380k pour le soft), le dhcpv6, le bonding via teamd ( 250k ) ou ipx. Donc c'est pas vraiment à feature égal.
Mais sachant que je doute que l'isdn, le ppp ou ipx dans l'initrd soit vraiment présent dans la majorité des cas, je vois pas l’intérêt de prendre ça en compte. Et malgré le fait que ça soit fait de manière ad-hoc, comprendre "à l'arrache", en ne copiant pas ce qui ne doit pas être copié sans avoir vraiment de vision haut niveau de ce qui est requis, le script network marche sans la majorité des dépendances. Alors que bash et awk sont requis.
J'ai non plus pas compté les 400k de iputils, car je part du principe que même si c'est pas requis pour que networkd fonctionne, dans le cas d'une machine de rescue, on peut en avoir besoin. mais si le but est juste de comparer la taille sans prendre en compte le rescue (ce qui me semble tricher un peu, car je pense qu'on a besoin des outils), on peut retirer ça et mettre networkd, et voila.
Et en compilant systemd sans selinux, on retire les 400k de la libpcre, et les 140k de la libselinux, et j'imagine qu'avec kdbus, on peut sans doute retirer les 430k de dbus-daemon.
Je suis pas sur pour la libdbus car systemd a sa propre lib pour le support de dbus et de kdbus, et je suis pas assez courageux pour faire un make install sur ma bécane de prod, ni assez motivé pour faire une vm pour vérifier l'hypothèse.
Donc oui, dans le cas d'un initrd avec systemd/udev/etc, mettre networkd à la place du script network permet d'avoir un solution plus économe à mon sens. Mais tu peux sans doute faire mieux en sacrifiant des features qui te paraisse superflu (sans discuter du fait qu'elles le soit ou pas pour d'autres, et je reconnais bien volontiers que pas grand monde n'a besoin des vlans dans l'initrd par exemple)
C'est comme démarrer directement erlang depuis xen directement. C'est custom made, c'est rapide, ça permet d'avoir des choses qu'on arrive pas à avoir autrement mais voila, la majorité des gens vont pas utiliser ça.
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 10.
Rajoute "et parce que toute les machines ne sont pas équipés en IMPI ou carte d'admin couteuses, ce qui permet d'adresser le marché des hobbyistes ayant leur serveur sous forme d'un shuttle dans le salon".
Et comme je peux pas me fatiguer à répondre à la même question sur le réseau, avoir un rescue sur le systéme qui a le réseau ça permet par exemple de télécharger le fichier de la glibc qu'on a écrasé par erreur depuis le rescue.
Bien sur, on arrive à se débrouiller autrement quand on a pas le réseau, mais je peux imaginer que ça peut faciliter la vie.
Et ça prends aussi moins de place dans l'initrd, au moins sur Fedora.
systemd-networkd fait 343k après passage de strip, bash + /etc/init.d/network + divers scripts dans /etc/sysconfig/network-scripts/ , ça fait 960k + ~100k de scripts.
Et si on me dit "mais networkd- tire la libpcre, ça fait 410k de plus", je dirais que les scripts d'init tire gawk, qui fait 570k.
Et que le fait de tirer pcre est listé comme bug dans la TODO list de systemd :
https://github.com/systemd/systemd/blob/master/TODO#L152
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 8.
Nan mais commence pas à ruiner tout l'argumentaire avec des vrais features et des use cases qui sont pas tirés par les cheveux, tu te rends compte que Linuxfr vit grace aux contributions, et que systemd a augmenté les contributions sur les commentaires :)
[^] # Re: Le nid à trolls
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 7.
Les arguments à l'époque était sur les appels de fonctions dbus. La, on parle de fonctions en C et la différence entre avant et maintenant, c'est ce sur quoi tu lies ton binaire.
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 10.
Networkmanager fait beaucoup plus de choses, genre le wifi, le bluetooth, le ppp. Il gère les proxys dns ( via dnsmasq) et le partage de connexion.
La, je pense que l'idée est surtout de remplacer /etc/init.d/network ( sur fedora ), et l'idée n'est pas non plus de Lennart, mais de Tom Gundersen, packageur Arch.
[^] # Re: Politique
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 8.
En même temps, faut pas se voiler la face. AppArmor a failli disparaitre sans Canonical qui voulait avoir une alternative à SELinux, car Novell avait finalement décidé de lacher l'affaire. At AppArmor est en retard niveau intégration partout ailleurs, car Canonical n'a pas vraiment les ressources.
Pr exemple, dbus a d'abord supporté SELinux, puis AppArmor. Postgresql supporte la séparation par SELinux, pas par AppArmor. Des distros comme Gentoo, Debian ou Fedora ont supportés SELinux bien en premier, puis vaguement Apparmor. Les seuls à avoir AppArmor de base sont celles ou le sponsor a décidé d'en haut de pousser la techno, ie Ubuntu et Opensuse. IE, la communauté poussant AppArmor est pas très grande.
Et je peux détailler en long, en large et en travers pourquoi à mon sens AppArmor est plus primitif et moins extensible que SELinux.
Par exemple, AppArmor utilise des chemins pour les permissions et les accès la ou SELinux rajoute une couche d'indirection, ce qui le rends impropre a un usage comme "ce document est noté top secret, personne doit le lire". Apparmor ne supporte pas trop le concept de MLS ( mais sur la TODO list http://wiki.apparmor.net/index.php/AppArmorMLS ). Et c'est pas un exemple purement théorique non utilisé en pratique, car tout openshift dépend de ça pour l'isolation des gens.
Autre example, changer le repertoire racine d'un serveur web. Sous SELinux, tu changes le label du répertoire via semanage fcontext, et voila. Sous AppArmor avec le système de profile, tu doit modifier tout les profiles pour copier les permissions. Mais donc du coup, pour palier à ce cas, ils ont rajouté le concept d'alias. Donc tu va dire que /var/www/ est un alias vers /home/www et donc que les accès de l'un correspondent aux accès de l'autre. Donc la ou une solution élégante est en place, on rajoute un truc de plus.
Je pourrais dire comment les politiques de sécurité SELinux sont configurable via des booleans, etc, etc. Et comment la config de apparmor, c'est juste des variables prédéfinis. En théorie, on peut faire la même chose avec AppArmor, sauf qu'en pratique, c'est quasiment du tout ou rien.
Je pourrait rajouter comment le fait de rajouter un nouveau type d'objet ( genre les sockets réseau ) implique de rajouter une option au parser, des nouveaux types d'objet dans la lib et de tout recompiler, la ou SELinux fait ça de façon indépendante du code dans le kernel et le reste, tout dans sa policy ( et avec du code pour l'arbitrage dans le programme qui va se servir de la policy, bien sur ). Comprendre comment faire ça, c'est globalement un workshop de 2h pour quelqu'un qui sait écrire une policy.
Alors ouais, SELinux semble s'avancer pour devenir quasiment un choix "normaliser" ( mais ça reste plus que relatif, car le défaut pour la majorité des distros, ça va surtout être "rien" ). Mais c'est surtout que ç'est plus extensible, ce qui permet de faire plus de choses, ce qui fait qu'il y a un marché pour ça, et donc des investissements.