Ensuite, on rentre aussi dans la sémantique. par exemple, dire que tout ce qui n'est pas interdit est autorisé. Et c'est pas interdit d'avoir d'autres repertoire haut niveau, et que les liens permettent de garder la compatibilité. Dire que si tu trouves ton soft dans /bin/ alors les executables pour booter y sont.
Enfin, je pense que personne ne suit à la lettre la FHS. Exemple gentoo à /usr/portage ( alors que ça devrait être dans /var ), Debian a du /usr/games, avec des régles en plus, Fedora/RHEL ont longtemps eu /selinux, et ont toujours /usr/libexec ( suivant les gnu coding standards http://www.gnu.org/prep/standards/html_node/Directory-Variables.html ).
Donc au final, c'est aussi pour ça que je trouve l'auteur du blog comme se focalisant sur les détails "visibles", alors qu'il y avait déjà plein de problème. Le fait d'avoir un /usr/libexec pose des soucis pour les outils qui codent en dur les chemins tout comme /usr/games. ( et c'est juste les détails que j'ai en tête un dimanche matin avant le fosdem ).
Le point de blocage 718, dont dépend celui que que tu pointes et qui traite précisément de la question est toujours
ouvert.
sauf erreur de ma part, le blocage est de savoir si les admins peuvent ou pas mettre /run sur autre chose qu'un tmpfs.
Et le reste est commité dans le draft.
Et je pense que tu as visiblement une idée bien précise sur la façon dont le standard doit évoluer, à savoir d'abord discuter et ensuite coder. Ça, ça s'appelle du design by comitee. Parfois ça marche. Parfois ça marche pas.
Si la FHS fonctionne autrement et se décide à juste documenter le consensus, ça marche aussi. Donc au final, si les distributions y trouvent leur comptes, qui va être emmerdé ?
nulle-part il est question de placer des points de montages dans ce répertoire, qui est le second reproche de
l'auteur du blog.
l'auteur du blog reproche surtout "oula, faut que je tape des noms longs", et le fait d'avoir changé le chemin. Sauf erreur de ma part, le montage est fait par udisk2. Une recherche donne ce commit : http://cgit.freedesktop.org/udisks/commit/?id=aa02e5fc53efdeaf66047d2ad437ed543178965b
Malheureusement, le commit ne donne pas des masses de détails.
De ce que je vois, le changement a 2 composantes : passage sur un tmpfs ( donc /run, supposement tmpfs par défaut ) et passage dans un dossier utilisateur ( /run/media/$USER/$DISQUE ).
Mettre /media en tmpfs aurait sans doute été un problème pour les mises à jours ( ie, changement de comportement ).
Donc tu doit prendre /run ou un autre chemin.
Mettre /run/ entier, c'est niet. Donc un sous repertoire. /run/$USER ou /run/$DISQUE, y a des risques de conflits ( surtout /run/$DISQUE ). Donc ajout de /media, nom fixe.
/run/media/$USER, ça permet de monter 1 disque à la fois, ce qui est niet.
/run/media/$DISQUE, ça marche dans les cas simples, mais pas dans le cas d'une station ou plus d'une personne peut se connecter ( le fameux multiseat qu'on a tous deja utilisé via ssh ). On retrouve çavia du thin client, etc. En effet, si tu fait ça, quelqu'un peut mettre une clé du même nom, et toi, au mieux, tu te demandes laquelle c'est, au pire, tu écrit sur la mauvaise. De surcroit, avec des clés en fat32 ( ou en udf, comme Tanguy le propose sur son blog ) en lecture pour tous, il y a une fuite de données évidentes ( ie, tout le monde peut lire ma clé avec mes documents via ssh ). Une solution alternative serait de faire le montage en forcant l'umask et les droits, mais tout les fs ne le supportent pas; et il y a peut être un souci caché que j'ai pas trouvé dans cette façon de faire ( ne serais que parce que sauf erreur de ma part, aucune distro ne le fait ).
donc /run/media/$USER//$DISQUE, avec $USER ayant des acls.
Bien que je n'ai pas pu tester, je pense qu'une solution au problème d'avoir à taper des chemins plus long serait pour l'utilisateur expert de rajouter son device directement dans /etc/fstab. Udisks respecte les réglages et devrait du coup monter la clé la ou c'est demandé.
À l'inverse, le "standard" continue à spécifier une séparation claire entre /bin et /usr/bin,
ce qui fonde le premier reproche fait (qui est que ça enfreint le FHS).
Le souci, c'est que la FHS dit juste "faut mettre les commandes pour monter les autres fs", en ne spécifiant rien.
Du coup, tu te retrouves à mettre tout ce qui pourrait servir à un moment à monter un disque dans /. Donc par exemple, sur debian, une des rares distros à se donner la peine de le faire proprement ( vu que les autres s'en foutent un peu, dans le sens ou personne ne teste vraiment, et surtout, personne n'ouvre de bug ), tu as tout les fs réseau et toutes les dépendances dans /lib, /bin, et /sbin/. Et j'ai eu du mal à trouver un contre exemple, mais j'ai fini par en trouver 1 ( aprés 4/5 essais ). Si tu veux avoir ton /usr en iscsi, tu peux pas : http://packages.debian.org/sid/alpha/open-iscsi/filelist car les commandes sont dans /usr/
( et le iscsi est vachement plus courant que l'exemple capilotracté de sshfs que j'aurais pou sortir, ou celui d'avoir ton /usr en afs via kerberos ( http://packages.debian.org/sid/armel/openafs-client/filelist ))
En pratique, le fait d'avoir tout dans /usr, ça permet de faire des containers plus facilement ( ou justement, de monter totalement /usr via le réseau comme avant sans avoir à garder le /bin local en synchro avec le /usr distant ), ça permet de faire des rollbacks plus facilement ( même si personne ne le fait, je pense que snapper devrait réussir à en tirer parti sous peu ). Je comprends que ça dérange, car la migration entraine un risque, parce qu'on a le sentiment de bousculer l'ordre établi ( un comme avoir quelqu'un qui range ton bureau, ça te fait toujours chier ).
Mais en pratique, c'était à la bonne franquette pour savoir quoi était ou, et c'était pas terrible la façon dont les distros l'ont mis en place.
Ensuite, tout le monde n'a pas suivi, et pour l'avoir fait, je doit reconnaitre que si on m'avais pas dit, j'aurais sans doute rien remarqué tellement c'était sans douleur. Il ne reste plus qu'à attendre que quelqu'un en tire parti.
c'est sur un tmpfs pour pouvoir nettoyer tout seul le truc. C'est pas déconnant. Et pour des questions de sécurité, de simplification
Pour les menus freedesktop, j'ai un peu de mal à comprendre pourquoi il a été choisi par rapport à JSON/XML, on pourrait pré-supposer qu'un menu est une hiérarchie d'entrées.
Parce que le json, c'est pas si vieux que ça ( dans le principe et dans l'usage en temps que tel, car sinon on aurait pu l'avoir plus tôt ).
Et parce qu'on veut avoir 1 fichier par entrée du menu, pour avoir 1 fichier par paquet installé. Ça rends le packaging trivial. ( donc pas besoin de hiérarchie d'objets )
Et parce qu'il y a pas que des menus chez freedesktop.
Enfin, les archives des discussions sont sur le web, tu doit réussir à trouver ça ( et les devs sont encore la, y a leur nom sur les documents )
Mais bon, des choses comme nodejs utilise le json pour les metadatas, donc c'est pas non plus un mauvais choix.
lxc de base utilise le même kernel que le système hote, donc on est pas à l'abri d'un souci. C'est pour ça aussi que des gens ont mis au point des choses comme des containers confinés par selinux. En fait, je devrait même pas avoir à expliquer à quelqu'un qui a fait une formation en sécurité, comme toi.
Et vous allez me faire croire qu'un admin ne sait pas gérer çà simplement ?
si tu étais admin, tu travaillerais sans doute avec des admins, et tu comprendrais que non, tout le monde ne le fait pas. Il suffit de voir le nombre de gens qui ne passent pas par la commande service pour ce genre de chose.
En gros, pour vous les Gentooistes sont incapables d'avoir une bonne méthode pour connaître les problèmes de sécurité
d'un soft sans la MAJ. Par exemple, si le OpenSSL nouveau débarque, ils ne sauraient pas ? Vous plaisantez là ?
Je dit que le projet gentoo n'a pas réussi à trouver de volontaire pour avoir les alertes sécurités par email pendant un temps. Ensuite, ouais, les gens peuvent lire à la main les listes des autres distributions sans problème.
Dans un monde de bisounours ton environnement est clean
ben, systemd le fait pour moi, donc oui. Je parle d'environnement au sens variable d'environnement.
Dites vous croyez qu'ils sont stupides chez Nginx, ou dans le kernel.org pour préferer un JSON like ?
Je crois pas que le kernel utilise un json like. Mais genre, nulle part.
En fait, nginx non plus. Un json-like, ça implique de se faire charger par un eval ( vu que le json, c'est juste du javascript ) et la config de nginx ne le fait pas. Mais la configuration de nginx a choisi d'exprimer des choses que le .ini ne supporte pas ( genre avoir une hiérarchie de réglage ), donc le .ini n'était pas bon pour eux.
En fait, je crois pas que le fait de faire d'autre choix implique la stupidité en général. Les contraintes sont différentes.
Ca prouve qu'il ne sait pas de quoi il parle. J'arrive à faire chauffer mon processeur, donc il doit bien être capable de faire fonctionner ras la gueule un serveur.
Peut être qu'il veut pas faire planter son serveur en prod. Ou peut être qu'il a mieux à faire que de faire des comparatifs. Mais son email est sur le site, tu devrais directement lui dire de lancer google chrome avec des tas d'onglets sur son serveur, histoire qu'il puisse compléter l'article.
J'ai bien ri: on vous dira sûrement: il suffit d'écrire un script pour régler vos problèmes.
Donc pourquoi personne chez debian n'a écrit de script pour ça ? ( sauf à nier la race condition que j'ai évoqué, et à me dire ce qui ne va pas dans le raisonnement )
2/ Si le gars a trop peur pour son système, il pourra toujours faire du git et/ou du svn avec son répertoire /var/* et/ou /etc/*
Avec un peu d'entraînement il va y arriver. Lorsqu'il maîtrise le processus, il automatisera la tâche…
ah, la bonne vielle idée de mettre /etc dans git ou svn. J'ai déjà tenté, comme tout le monde. Et comme tout le monde, j'ai vu que c'était une idée à la con.
Déjà, tout ne rentre pas dans git/svn. /etc/localtime, un superbe fichier binaire, n'a rien à faire la. /etc/password, qui va changer aprés chaque installation de demon, c'est pareil. Tout les fichiers avec des mots de passes, c'est pas terrible. Et puis, ça gére pas forcément bien les owner des fichiers. Ou le stockage des liens, ça coince ( ou du moins, c’était pas bon à l'époque ). Ensuite, bah, /etc/ c'est pas tout ce qui sert à ton systéme, vu qu'il manque les paquets, etc. On va me dire "mais y a aussi /var/ dans sa proposition". Oui, parce que c'est bien connu, on peut prendre la base des paquets rpms ou deb et pouf, ç'est bon, ça se mets dans un vcs sans prendre une tonne de place, sans poser des soucis avec les diffs parce que c'est du binaire. Et surtout, ça bouge pas à chaque upgrade.
Et au final, on a quoi ? Ben rien, parce que ton dépôt, tu peux pas l'appliquer à une autre bécane sauf à vouloir un clone imparfait. Tu peux tout juste revenir en arriére d'un coup.
Mais en fait, quand on fait les choses bien, on utilise un outil comme puppet, chef, cfengine, etc. Comme le font toute les grosses distros comme dit à une table ronde au fosdem l'année dernière.
Systemd est refusé par deux distributions majeures et à peine acceptée par d'autres.
En effet, ils savent très bien que linux est tiré par RedHat, parce que RedHat a des sous, les autres moins.
Alors, à peine accepté, c'est ni l'avis des gens de Mageia, ni l'avis des gens d'Opensuse. Ni des devs d'archs.
Et Suse a des sous, ils sont numéro 2 sur le marché, ( voir 1 sur certains marché ssi j'en croit leur plaquette ). Si ils voulaient refuser, ils pourraient. Par exemple, ils ont ni anaconda, ni yum.
Quand à Canonical, ils ont aussi assez de sous pour faire unity ( donc refuser gnome 3 ou kde ), pour faire tourner une boite de 400 ou 500 personnes, pour avoir son propre truc de gestion de cloud ( juju, maas ), voir même pour faire son propre systéme d'init. Donc j'ose supposer à partir de la 2 choses :
- si une boite qui gagne pas assez pour être à l'équilibre ( aka canonical ) a les moyens de pas suivre RH, d'autres ont les moyens. L'argument des sous est donc faux.
- si les distrib totalement communautaire veulent prendre openrc, upstart, init-ng ou juste garder sysvinit ( ce code shell si facile à maintenir, je pige pas que personne n'ai encore fait de fork à la MATE ), elles peuvent aussi. Y a rien qui les force.
Tu semble n'avoir aucune idée de la façon dont une distribution marche ou de la façon dont les décisions sont prises, donc tu te raccroche à un modèle erroné ou l'argent règne.
un bug ou le reporter n'a plus rien posté depuis 10 jours, ce qui nous laisse un peu sur notre faim sur son origine ou le problème réel. A plus forte raison si personne n'arrive à reproduire.
Pourquoi ne pas l'avoir contruit avec un JSON like bon sang de bonsoir ?
Parce que c'est pourri ?
Soit c'est du json, et c'est pourri pour de la configuration ( exemple, comment on fait un commentaire en json ).
Soit c'est du truc qui ressemble à du json ( cad, dans le cas que tu cites, nginx, un vague format avec des {} ) et c'est chiant à parser ( vu que c'est plus du json, tu oublies les outils classiques), et ça revient à faire ton propre DSL. Ce qui revient à augmenter encore la courbe d'apprentissage pour rien ( car ton histoire de json-like, en d'un péremptoire "c'est pas pro", ça apporte quoi ? ). Et c'est pourri.
Où il m'a mis la patée ?
Un peu dans tout les commentaires. Dans celui la aussi.
Je dirais pour terminer que je souhaiterais que linux ne dépende pas trop de RedHat [freedesktop, xorg, pusleaudio, nouvel init (systemd), etc.].
Mais en effet, moi, j'aimerais bien aussi que l’origine des contributions soit plus varié.
Et pour ça, y a pas de secret, faut se bouger. Je suis sur qu'un spécialiste du sujet devrait sans souci apporter son expertise à un projet.
Sinon, bah, juste soutenir opensuse ( ah non, la communauté choisit plutôt de ressortir des trucs sans rapport datant d'il y a 5 ans ce qui démotive les rares gens motivés ), soutenir nokia ( ah non trop tard ), filer du pognon à Canonical ( ah non, personne paye ) ou à Mandriva ( ah non, comme Nokia ), enfin bref, injecter de l'argent dans les boites qui contribuent autre que RH.
Tiens je suis déjà à -3 alors que je viens juste de poster…
D’après https://linuxfr.org/wiki/karma , tu peux aller jusqu'à -10 par défaut.
Donc, si tu es à -3, ça veut dire que tu as un karma entre -20 et -10, ce qui veut dire que tu as perdu non seulement les 20 points de base, mais aussi ce que tu as pu avoir au fil du temps. Et je pense qu'à ce rythme, tu va juste être à -10 par défaut d'ici 2 semaines au mieux.
Par exemple, il est pas formellement spécifié. Si j'ai :
[foo]
Toto=tata
Toto=coin
Je suis pas sur que tout les parsers le lisent ( et me donne que toto a 2 valeurs, ou l'ordre ).
Genre python a 3 classe de parsers pour le .ini .
Il permet pas de faire de tableau, et de trucs à plusieurs niveaux imbriqués, n'a pas de schema ( même si ça pourrait se rajouter )
contrairement à du yaml, du xml, ou du json.
Ensuite, la syntaxe est comprise par tout le monde de façon quasiment intuitive, il y a des parsers pour tout
( même si ça peut coincer dans les détails ). C'est pas le format qui va résoudre tout les soucis du monde, mais je doute qu'il existe, et dans le cas de systemd, ça fait l'affaire. On s'en sert déjà pour le reste des projets freedesktop ( genre les menus, etc ), donc il est en plus "standard".
Sinon, le blog que tu as pointé manque de perspective, par exemple, sur l'histoire du /usr merge, il ne pige pas que le role de / est passé à l'initrd, et que dont celui du /usr partagé est passé à tout /usr par le dit merge, ie, que c'est en faisant un système minimaliste à façon qu'on règle le problème du bloat de /.
Il dit que le passage à /run a été d'ignorer le FHS, mais justement, le changement vers /run fait parti du FHS 3.0 justement parce que les distributions se sont mis d'accord ( https://bugs.linuxfoundation.org/show_bug.cgi?id=758 ), et que le passage vers un sous dossier de /run est pour des questions de robustesses ( ie, pour une ressources non partagés sur un système qui lui est partagé , pour éviter les conflits de nom ).
Les divers changements sont pas la pour faire joli, en général, ça vise à tenter de corriger des vrais soucis. Personne ne se rajoute du boulot pour rien, y a déjà assez à faire sur les distributions classiques
Le fait est que les gestionnaires de paquets pourraient faire le merge automatiquement. Sauf qu'ils font pas pour la plupart ( et je dit pour la plupart, car de ce que j'ai vu, au mieux, c'est un hook avec etc-update configuré à la mano par l'admin, mais je doute pas que quelqu'un a du faire un truc plus chiadé un jour ).
Par exemple, quelqu'un avait tenté d'intégrer ça dans mandriva : http://blog.zerodogg.org/2005/09/29/common-configuration-parser-ccp/
Quand au fait d'être incompatible, bien sur. Si la solution miracle aux upgrades existait, je pense bien qu'on l'utiliserais depuis le temps ( exemple le ccp proposé plus haut ).
Maintenant, si tu prends l'exemple d'apache qui fourni un répertoire ou tu mets ta config en plus du fichier de base de la distro, le seul risque, c'est le jour ou apache change radicalement ( passage en 2.4 ), genre une fois tout les 4/5 ans. Pas une fois à chaque upgrade de version de la distro, ou une fois de temps en temps lors d'un souci de sécurité qui va modifier la config pour bloquer l'action TRACE ou changer je ne sais pas quel config par défaut incorrect.
systemd existe depuis 7 ans et n'est toujours pas implémenté dans toutes les distributions !!! )
Le premier commit sur le git de systemd, c'est pas en 2006.
Par contre, tu confond sans doute avec udev, qui a été fusionné dans systemd, et lui, il est utilisé presque partout.
Les rares articles que j'ai lu sur systemd faisaient souvent des critiques sur lui.
Et la réalité des faits sur la mailling list montre le contraire. Faut pas croire tout ce qu'on dit sur le web, à commencer les attaques personnels. Personne ne va dire que Linus Torvalds a tendance à s'enerver, alors que ça serait sans doute intolérable par n'importe ui d'autre. Personne ne dit "faut pas utiliser openbsd car theo de raadt est un colérique", alors qu'il a plus d'une fois poussé une gueulante. Et personne n'a dit "ne pas utiliser la glibc,Ulrich Drepper est un asocial".
Vous n'allez pas me faire croire que vous qui vous vantez d'être un utilisateur très averti de linux
ne mélangez pas des paquets.
Non, je pousse mes paquets directement dans la distro. Ou je reprends le paquet et le recompile. Je mélange pas les paquets binaires le moins du monde, c'est moche.
sous entendu, il n'est pas EXACTEMENT le même. C'est bien ce que je pense.
Les packageurs backportent les correctifs. C'est facile à vérifier, vu que tout est publié.
Je ne vous permets pas de dire que Mageia est petite
J'ai été admin du projet Mageia pendant 2 ans, secretaire de l'association, membre du board, donc je connais la taille de la communauté, je sais combien y a de compte dans le ldap ( que j'ai aidé à mettre en place, que j'ai tenu à jour ), donc je pense être parfaitement capable de déterminer si c'est petit ou pas. Donc le droit de le dire, je le prends avec ou sans la permission d'un inconnu.
Oui, mais ce qu'on ne vous dira jamais c'est que tout cela est propriétaire.
Launchpad est libre, sous AGPL depuis 2009. Y compris Soyuz, la partie responsable du build system.
Sinon, l'OBS est libre aussi et supporte debian directement.
Ensuite que launchpad soit difficile à installer est bien connu. En fait, qu'un système de build soit compliqué à déployer est aussi connu. Et que les systémes de build soit spécifique est aussi hélas bien connu, mais sans doute parce que personne ne bosse pour les rendre compatible ( à part suse ).
J'aurais pu être admin si je le voulais. J'ai même suivi une formation en sécurité informatique.
Impressionnant. J'ai bossé dans une boite spécialisé en sécurité informatique après avoir eu un DESS en sécurité, on peut donc continuer à jouer celui qui a la plus grosse, mais je pense que c'est pas productif.
Et avoir suivi une formation est une chose, mais ça dépend de la durée, du contenu. Et la sécurité, c'est vague, ça va du très théorique ( genre la séparation de domaine et l'analyse haut niveau comme le ferait un analyste ) au plus pratique ( genre, savoir coder de manière sécurisé, mettre en place un firewall, faire un audit ). J'ai fait des cours de compta à la fac, je vais pas dire à un comptable comment il doit faire son métier.
Stallman vous contredirait: vous avez la liberté de copier, cloner, tout ou partie, etc.
La liberté de faire un truc implique pas de ne pas être ridicule. Exemple, tu as la liberté de poster des trucs ridicules, tu t'en sert, ça veut pas dire que ça reste pas ridicule.
En raid logiciel pur, ie sans /boot séparé hors des partoches en raid ?
Dans mon souvenir, le souci est que grub ne comprenant par le raid, il faut charger le kernel et l'initrd depuis une partoche /boot en dehors du raid, et faire la synchro plus ou moins à la main.
Oui, et visiblement, il y a encore d'autres endroits dans le cookbook d'upstart ( que j'ai commencé à relire ) ou ils reprennent le même système de modifier des fichiers qui sont pas de la configuration.
Mais c'est un problème compliqué, car parfois, un fichier de configuration n'arrive pas à exprimer toutes les subtilités de ce que tu veux exprimé, et parfois, faut juste essayer de rentrer dans les clous.
dpkg-divert, c'est un moyen de hacker sans trop de dégât immédiat ton système, mais c'est pas tenable. Et tu peux pas rendre tout configurable non plus.
Ouai je comprends. Ça me paraît être un mauvais usage de l'initsysv.
Je viens de regarder dans ma distrib' (debian stable) ssh ne souffre pas de ce problème mais exim si.
Bah, voila, une troisième méthode que je connaissait pas, et non, je parle en effet d'une autre façon de faire.
Mon coloc s'était plaint de devoir mettre "UsePAM yes" dans sa config, et j'avais fini par trouver un truc en lançant ssh à la demande via les sockets, ce qui fait 1 cgroup par connexion.
Par exemple, sur ma machine ( ou je fait ça pour économiser 3mo de ram afin de pouvoir continuer à lancer des gros trucs java pour remplir les 8G qui reste ), en lançant 2 connexion ssh, j'ai 2 entrées dans la sortie de systemctl :
~ $ sudo systemctl | grep ssh
sshd@2-:...:1:51441.service loaded active running SSH Per-Connection Server
sshd@3-:...:1:51442.service loaded active running SSH Per-Connection Server
sshd.socket loaded active listening SSH Socket for Per-Connection Servers
~ $ systemctl status sshd@3-::1:22-::1:51442.service
sshd@3-::1:22-::1:51442.service - SSH Per-Connection Server
Loaded: loaded (/etc/systemd/system/sshd@.service; static)
Active: active (running) since lun. 2013-01-28 16:16:56 CET; 39s ago
Main PID: 4148 (sshd)
CGroup: name=systemd:/system/sshd@.service/3
Et chacune est dans son propre cgroup, ce qui fait qu'un restart du service ne tue rien.
Mais c'est pour moi un effet de bord du fonctionnement par socket plus qu'autre chose, donc je trouve ma méthode tiré par les cheveux.
Je n'ai pas bien compris ça. Tu peux en dire plus, s'il te plaît ?
en gros, tu prends un job upstart au pif, genre ssh sur mon n9 :
$ head /etc/init/ssh.conf
description "SSH"
# started by group-mce.conf
stop on stopped dbus
console output
respawn
respawn limit 3 300
normal exit 0
oom -17
script
test -x /usr/sbin/sshd || exit 0
if test -f /etc/default/ssh; then
. /etc/default/ssh
fi
root_permitted="-o PermitRootLogin=no"
if test -x /usr/sbin/rdc_cert_verify && \
$(/usr/sbin/rdc_cert_verify &> /dev/null)
then
root_permitted="-o PermitRootLogin=yes"
fi
# Create the PrivSep empty dir if necessary
if [ ! -d /var/run/sshd ]; then
mkdir -p /var/run/sshd
chmod 0755 /var/run/sshd
fi
exec /usr/sbin/sshd $root_permitted $SSHD_OPTS
end script
Il y a 2 parties :
* la partie script ( entre script / end script )
* la partie pas script, à savoir le reste
La, si je veux par exemple que ssh ne s’arrête pas quand dbus se coupe ( c'est mon tel, je fais ce que je veux ). Ou imaginons que je veuille changer la directive oom, changer la valeur de nice, etc. Faut que je modifie le fichier.
Sauf que si je modifie le fichier, il se passe quoi à la prochaine mise à jour qui va faire pareil ( exemple, une modif qui change le chmod 0755 en 0700 pour cause d'un souci de sécurité ( exemple inventé )) ?
3 choix :
- le système de paquets écrase ma modification. Donc je doit repasser pour la remettre, si je m'en souvient.
- le système de paquets n'écrase pas la modification. Mais je doit passer pour rajouter sa modif dans mon fichier modifié.
- le système de paquets me demande, donc je doit passer pour fusionner les changements.
Dans tout les cas, ça requiert d'être la pour s'occuper de l'upgrade et tout ça parce qu'il y a des informations du domaine de la distribution (à savoir la partie 'script' ) mélangés avec des choses du domaine de l'admin ( à savoir les dépendances, le choix de l'oom ou pas, du nice, etc ). Et ça, c'est un job simple, il y a pas mal d'option en plus dans upstart.
Systemd gére ça de façon élégante en prenant les informations de 3 fichiers, et en appliquant la config dans un ordre précis. Si j'ai toto.service dans /lib et dans /etc:, les informations en plus de /etc ( genre une valeur de nice ) se rajoute à celle de /lib. Donc quand la distro modifie le fichier dans /lib, j'ai rien à faire de spécial. Il y a même un outil spécifique ( http://www.freedesktop.org/software/systemd/man/systemd-delta.html ) pour trouver ce qui a été modifié dans /etc par rapport à /lib
Je trouve ça bizarre pourquoi ne pas faire
Les daemons font en général un double fork. Donc ton wait va attendre sur le premier, pas sur le second. Et tu ne peux faire de wait que sur un process fils, sauf erreur de ma part. Donc à partir du moment ou ton script d'init t'a rendu la main, tu peux plus faire de wait sur le pid de bind, donc inapplicable dans le cas exposé, à savoir d'un reboot. D'ou l'usage de ptrace par upstart pour choper le pid ( http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ ).
Oui c'est proposé par Lennard, mais rien de très spécifique à systemd là dedans.
oui, et sauf erreur de ma part, Ubuntu ( entre autre ) l'a fait avant que Lennart ne pousse ça dans systemd, vu que je me souvient distinctement avoir entendu raler le dev debian qui servait de sysadmin dans mon ancien job contre les devs Ubuntu d'avoir mis /var/run en tmpfs. Il avait du rajouter 2/3 lignes pour le script d'init pour refaire /var/run/nufw/ ou ce genre de choses avant de lancer le démon de notre produit.
D’après ce que je lit ici et la, grub-ieee127 ne serait pas ce que tu veux ? ( la dernière sparc que j'ai vu, c'était à la poubelle y a 1 an, donc je suis plus très au courant de ce qu'il faut faire en dehors de "magouiller avec l'open firmware" ).
Mais si tu arrives à le faire marcher, je suis sur qu'un peu de doc pourrait aider.
Mais Pat est le fondateur de Slackware donc je ne prends pas à la légère ce qu'il dit.
Alors d'une part, il y a d'autre fondateurs de distros qui postent parfois ici et la, et tu sembles prendre ça plus à la légère ce qu'ils disent ( enfin pareil, c'est un avis personnel, pas une parole divine ).
Et d'autre part, Patrick a un vision orienté vers son but, à savoir la maintenabilité par lui même de la distribution, et la simplicité extréme que ça requiert, quitte à ce que ça ne réponde pas au besoin de tout le monde.
Son refus de pam est un exemple, et pas grand monde ne va le suivre sur ce point, car même si pam a eu des débuts difficiles, ça reste relativement pratique dés que tu veux avoir un serveur ( comptes en ldap, kerberos ) ou si tu veux essayer de rivaliser avec du windows sur le poste client ( pareil, ldap, etc ). Ou de la sécurité ( authentification à 2 facteurs, lecteur d'empreinte digital ).
D'ailleurs, la gestion des processus par cgroups de systemd ( pour en revenir au sujet ) implique de dire à sshd de se "détacher" des processus utilisateurs pour éviter de les tuer lors d'un restart, et d'avoir son propre cgroups par utilisateur ( ce qui permet d'appliquer des quotas cpu/ram/etc par utilisateur via les cgroups, justement ). Et pour ça, le moyen le plus propre est de passer par pam, qui va voir au login qu'il y a un utilisateur et qui va le changer de cgroups.
Sans ça, tout les utilisateurs sont dans le cgroup de sshd, et se font donc tuer sans pitié en cas de restart du demon. ( il y a une méthode pour faire autrement, mais c'était tirer par les cheveux et j'ai oublié ).
Donc un passage à systemd serait sans doute aller à l'encontre de son objectif de garder pam hors de slackware ( sauf si ce n'est plus d'actualité, bien sur ).
Pour Ubuntu, qui était à l'origine de upstart (non?), je pourrais tout aussi bien les accuser de refuser systemd pour
cause de syndrôme NIH. (c'est tellement facile de dire que "les autres n'en veulent pas parce que c'est pas bien").
Et moi, j'avais le sentiment que upstart a commencé comme projet à part ( au vue du vieux nom de domaine en .at ) avant de passer sous l'aile de Canonical. Mais vu que dans mon souvenir, il y a le fameux CLA, je doit sans doute avoir tout faux.
Tel que je vois la ou Canonical veux aller, c'est l'embarqué ( smartphone, tv ), et le cloud avec des bécanes jetables ( ie, les guests ). Et je pense que le concept de gestion d'événement s’intègre bien aussi avec le premier ( besoin de mobilité et d'une gestion dynamique ) qu'avec le second ( rajouter un file system en réseau via ceph, etc ).
Upstart a été utilisé pour chromeos ( donc un pc portable mobile ), pour le nokia n9 ( donc aussi un appareil mobile ), et sans doute dans Ubuntu Tv et le reste.
Ensuite, pour la partie cloud, ils sont partie sur juju plutôt que de l'intégrer ça directement dans l'OS via upstart, c'est un peu dommage ( et qu'on me dise pas "ça rends juju portable" car ça continue à utiliser des ppa à tout va ). La transparence réseau de upstart, ça aurait pu faire une sacré killer feature pour le système.
Si, le projet est à l'abandon. Mais j’étais pas au courant du port pour netbsd, ni du fait que ça dépend fortement de mach ( ceci dit, j'aurais du m'en douter, mais j'aurais penser qu'un soft non portable aurait fait raler tout le monde ). Je suppose que le fait de dépendre des plists ( un format basé sur xml d'os x, qui peut aussi être compilé en binaire ) risque de faire grincer des dents.
Il explique par exemple que le fait de lancer plusieurs choses en même temps permet de tirer parti des machines multi cores, il montre pas mal d'idées qui se sont retrouvés dans systemd ( le lancement activé par un chemin, par socket et dans le désordre ), et il montre aussi le genre de choses qu'on peut faire avec l'activation par socket dans la session user. Son exemple, lancer X ( qui plante quand il teste ) ou ssh-agent à la demande, ce qui permet de décharger la session des trucs qu'on utilise pas vraiment ( avec comme avantage de consommer un peu moins de ressources, d'avoir un session qui démarre un peu plus vite et surtout d'être plus robuste ).
Quelle est la valeur d'une paire de soucis? Peanuts
Ce que l'auteur pense importe peu. Vous avez peur de dire ce que vous en pensez ?
Vous êtes proFedora donc vous manquez d'objectivité car vous défendrez forcément systemd
upstart c'est de l'ubuntu donc forcément vous ne l'aimerez pas…
Donc récapitulons. J'ai une opinion donc je manque d'objectivité ( c'est grosso modo la définition, mais bon, passons ). Je donne donc pour éviter de tomber dans ce travers un lien de quelqu'un que je connais pas, mais d'un coup j'aurais peur de dire ce que j'ai déjà dit 15 fois sur linuxfr.
Certes. Et au final, quoi que je dise, je suis pro fedora, donc forcement, je vomis ce que fait Ubuntu. Parce que c'est bien connu, quand on utilise une distribution, ça retire tout sens critique, donc pas besoin de donner d'argument.
Au lieu de m'éterniser sur des arguments stériles et des attaques ad hominem, regardons de plus prêt ce que l'auteur de l'article dit :
il donne également l'exemple de la modification de la config d'un systéme, ou pareil, le fait de modifier le fichier fait qu'il risque de passer à coté d'une modification, car c'est plus proche d'un script. Pareil, il mets la correction de ce souci comme avantage de systemd. Lien : http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartDependencyProblem
Donc voila 4 problèmes liés à l'architecture d'upstart ( ie, le fait d'avoir un fichier de config qui est en fait un script, et le fait d'utiliser ptrace pour suivre les processus ), corrigé par le design de systemd, à savoir avoir des fichiers au format .ini, ce qui permet de mettre des priorités sur les directives qui découlent d'un ordre de lecture prétabli, et l'usage des cgroups, pour gérer les groupes de processus. Cgroups déjà à la base de lxc, donc relativement étanche.
Exemple typique de manque d'objectivité:
Le soucis est subtile , donc pas vraiment identifié…
Une affirmation pertinente serait de préciser LE soucis
Quand je dit subtile, je veux dire par la difficilement identifiable. Par exemple, se connecter en ssh, et relancer un serveur web et voir plus tard que tout d'un coup, ton cgi qui appelle la commande 'sort' merdouille parce que la variable LANG n'a pas été nettoyé ( ie, LANG=FR_fr est passé au script, puis à apache, puis à ton cgi, puis à 'sort' qui va trier les caractères diacritiques d'une façon différente en fonction de la locale ). Ou voir qu'en fonction de comment est lancé ton soft, tu as un autre format de date dans les logs, car il reprends LC_ALL et LC_TIME. Bien sur, si on était sur d'avoir toujours le même environnement clean, ça n'arriverais pas ( khofhttp://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRestartEnvironmentkhof )
Gentoo est connu comme très solide et très sérieux.
ah ah ah
Pardon.
J'ai rien contre Gentoo, j'ai un serveur sous Gentoo chez OVh, et je dirais même que je connais des gentooistes ( bien la preuve que je suis pas raciste ). Mais sérieux et solide n'est pas forcément ce qui me vient à l'esprit. J'aurais plutôt dit flexible et adaptatif.
Sérieux, pour moi, ça implique par exemple un suivi des soucis de sécurité et pendant un bon bout de temps, il n'y plus eu d'alertes de sécurité (cf http://www.gentoo.org/security/en/glsa/index.xml entre janvier 2010 et mai 2010 ).
Solide, je dirais que c'est plus la personne qui décide de pas abuser de l'adaptabilité. Il faut bien voir qu'en pratique et en fonction des choix de l'admin, chacun a un système différent. L'utilisateur est le premier, dernier et seul personne à faire la QA de son système. ( bon, pas exactement, mais j'ai toujours voulu caser la formule ). Les paquets passent de masked a unmasked sur la base des retours des gens, ce qui garantit des tests minimums, mais les retours sont se font dans des environnements différents. Et c'est une approche différente d'une debian ou d'une autre distro binaire, ou tout le monde a les mêmes binaires ce qui fait que si ça marche chez X personnes, alors il y a moins de raison que ça foire ailleurs. Alors que gentoo, avec les use flags, etc…
Et comme il y a pas de mises à jours de sécu au sens "mise à jour minimal" avec la QA qui va avec, la solidité n'est pas une chose que j'estime acquise, bien que je n'ai pas eu à me plaindre personnellement si souvent et que c'est suffisant pour ce que j'en fait.
Openrc, qui a quand même eu 10 ans pour se faire adopter, semble faire un revival. Bien sur, personne ne va dire que openrc, il supporte le boot en parallèle avec des bugs compliqué à reproduire ( https://bugs.gentoo.org/show_bug.cgi?id=391945 ).
it apparently does per-user fair share scheduling by default (but I haven't had a chance to run systemd in a
situation where I could really see this in action)
En gros donc, vous nous vantez les mérites de systemd comme étant une révolution, mais même ce monsieur n'arrive
pas à réaliser une telle opération qui est théoriquement facile puisque systemd est une révolution.
Je n'ai pas dit "révolution", j'ai laissé mon pull noir à col roulé au placard. Et j'ai du mal à saisir. L'auteur de l'article n'a pas eu de situation ou le "fair share scheduling", traduisons par "partage équitable de l'ordonnanceur" a pu s'appliquer, donc ça rends systemd compliqué ? Si ses serveurs ne sont pas chargé ras la gueule au point d'en avoir besoin, ou est le souci ?
Pour info, ce dont il parle est détaillé la : http://lwn.net/Articles/415740/ , avec la réponse de lennart la : http://lwn.net/Articles/415756/. Si les gens passent pas leur temps à mettre leur bécane sur les genoux à grand coup de compile kernel pour constater si systemd fait un truc, c'est la faute de systemd ?
is mostly written in C […] XML [15% du code]
Pour info, ce que l'auteur a voulu dire, c'est que contrairement à smf, l'init de solaris, systemd n'utilise pas de xml pour sa config donc l'admin n'a pas à interagir avec. Ensuite, la doc est en docbook ( un format de publication en xml ), et en effet, 15% du contenu du tarball, c'est de la doc en xml.
Mais c'était bien tenté.
Tout le monde est d'avis que le système [init] fonctionne correctement depuis 40 ans.
Pas moi. Ni les gens de chez Sun, vu qu'ils ont refait le système avec SMF. Ni les gens d'Ubuntu ou de Chrome OS, vu qu'ils ont upstart ( ou RHEL 6, ou Maemo ). D'ailleurs pas les gens de Gentoo, vu qu'ils ont fait openrc. En fait, Apple aussi a refait son système d'init il y a 3/4 versions. Donc oui, si on retire tout ça, tout le monde pense que ça marche.
Enfin pas ceux qui ont fait runit ou initng non plus. Ni les gens de FreeBSD qui ont proposé un portage de launchd dans un Google Summer of Code.
Enfin donc, à part tout les gens qui sont tellement d'avis que ça fonctionne correctement qu'ils se sont dit qu'il faut le remplacer, ouais, tout les autres pensent que ça marche.
Enfin si on retire tout ceux qui ont choisi systemd, comme arch, opensuse, mandriva, fedora mageia, ou des boites comme intel ou rackspace ( vu que intel bosse dessus, rackspace bosse sur journald ), oui, tout les autres pensent sans doute que ça marche comme il faut.
Mais bon, je suppose que juste donner des noms, ça ne va convaincre personne, donc je vais détailler. Déjà, quand tu dit "le systeme d'init marche depuis 40 ans", tu veux sans doute parler de sysvinit, et donc depuis 30 ans. Bon, pas grave, 10 ans, c'est presque rien. Le système des premiers unix était sans doute un chouia plus frustre, et je me demande si à l'époque, les gens ont ralés devant la complexité d'avoir gasp, une couche d'indirection de plus.
Alors déjà, si ça marche bien, pourquoi toutes les distros ont rajouté le support des tags LSB pour l'ordre des scripts si le format de base est si bien ? Non, pas la peine de répondre, c'est parce que c'est moisi de devoir choisir à la main l'ordre. Et parce qu'il y a pas vraiment de format, juste des conventions, comme le fait de faire un printf, le fait d'avoir X ordres. Je vais pas parler des codes de retour des initscripts, je risquerais de devenir grossier.
Ensuite, non ça me marche pas bien. Par exemple, bind est le premier exemple que je donne à chaque fois. Bind utilise la commande rdnc pour signaler au processus principal qu'il doit s’arrêter. Sauf que comme c'est une communication unidirectionnel, en fonction de la charge de la machine, tu ne sais pas si bind est coupé ou pas au moment ou la commande rends la main. On pourrait croire naïvement que ça n'a pas d'importance, sauf que si tu fais un stop et un start ( ce qui est quand même la façon la plus universelle de faire restart ), et ben parfois, bind ne se relance pas, car l'autre n'est pas mort. Bien sur, ça dépend de la machine et de sa charge. Et se dire qu'on est passé d'un coup en fonctionnement asynchrone sans le savoir, ça montre bien qu'il y a des soucis.
Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.
Mandriva fait ça avec un sleep 5, ce qui tout aussi un hack.
Systemd, il gère ça en suivant tout les process du groupe. Ie, quand ils sont morts, il le sait.
Le deuxième exemple, c'est mon ami Sympa. Sympa, c'est vachement bien, plus souple de mailman sauf qu'il y a un léger souci. Quand tu le connectes à postgresql ( ce que l'équipe de sysadmin de Mageia a fait ), si la base de données n'est pas disponible, il attends. Il attends pas en tache de fond. Il attends et le script d'init ( une horreur qui lance 5 services d'un coup ) se bloque. Donc si ta base se lance après par la magie des scripts, ton serveur se bloque au boot. En fait, c'est aussi amusant si postgresql mets du temps à mettre son socket à disposition pour une raison X ou Y, car même en étant lancé avant, sympa bloque le boot. Alors bien sur, une fois que tu as pigé le souci, ç'est facile à corriger. D'ailleurs, ça a été corrigé upstream d’après le packageur debian avec qui j'ai eu le temps d'échanger sur le sujet.
Systemd, il gère ça en lançant tout en même temps, et en s'en foutant d'un process qui bloque.
Alors le 3eme exemple, c'est Apache. Apache, c'est un soft cool, ça gère les processus pour toi. Sauf que voila, parfois, y a des processus qui partent en vrille ( ce qui arrive quand on embarque des saletés dedans comme php, ou des cgis ), et parfois, pareil que bind, ça mets du temps à mourir. Comme le process principal tot ou tard meurt, il reste parfois des orphelins. Et c'est coriace ce genre de bestiole, car faut que l'admin vienne à la main faire le ménage. Bien sur, pareil que bind, ça arrive pas toujours, même rarement. Il faut bien tomber sur des circonstances aggravantes pour que ça se produise.
Mais bon, c'est pareil, c'est entièrement du à sysV. Parce qu'avec les cgroups, tu peux faire du kill(9) à tout va après un temps.
Ensuite, des gens vont te dire que la pauvreté de sysV implique de dupliquer le code pour passer un soft en daemon dans chaque soft, que statistiquement tout le monde ne le fait pas tout ce qu'il faut comme il faut ( à savoir se rattacher à un groupe de process, faire un chdir('/'), fermer tout les descripteurs de fichiers, faire un double fork, et sans doute des trucs que j'oublie ) et que du coup, ça cause des soucis
Avec sans doute une petite biére, ils vont continuer pour expliquer qu'il y a des problématiques à la con entre setuid, setgid ( l'ordre par exemple, ou le fait de fait un initgroup avec setgid ), et que même les meilleurs oublient, ou te parler de cas ou un init script s'est vautré sur un fichier de pid non effacé du à un reboot intempestif de la machine.
D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".
Mais bon, je suppose que tout ces gens, tu va sans doute dire que leur objectivité est impossible, qu'ils ont tort parce que toi, tu as eu aucun problème donc ça prouve bien que ça n'existe pas ?
L'auteur détaille une paire de souci avec upstart tout au long de l'article, et explique aussi tout au long des liens le genre de souci subtile qu'il y a avec l'usage de scripts de démarrage ( genre l'environnement pas clean )
Le souci du raid logiciel, c'est qu'il est logiciel. IE, avant d'avoir grub2, je pense qu'il fallait magouiller pour booter directement sur un raid logiciel sans avoir un /boot séparé. Il y a aussi l’intégration avec la carte de management distante souvent vendu avec les serveurs, ce qui permet d'agir même quand le serveur est dans le pâté complet
L'avantage aussi du raid hardware, c'est que c'est grosso modo "techos pas cher"-friendly. Tu as ton alerte, tu as le disque qui clignote, tu dit au mec de remettre le disque en réserve, et voila. ( et je sais pas si le disque qui clignote est une feature standard des serveurs avec du raid soft ).
Enfin perso, moi, j'étais dans le camp des gens en faveur du raid soft quand on a eu la discussion à mon taf, mais j'irais pas qualifier les gens qui font du raid hard de mauvais admins. Si les cartes raids se vendent, c'est bien parce qu'il y a des gens qui achètent et qu'ils y trouvent leur compte
Perso, un mec qui a une kalach en état de marche et qui s'en sert, je suis pas sur que j'aurais vraiment de le contrarier en remettant en cause ses capacités. Je dit ça, je dit rien.
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Ensuite, on rentre aussi dans la sémantique. par exemple, dire que tout ce qui n'est pas interdit est autorisé. Et c'est pas interdit d'avoir d'autres repertoire haut niveau, et que les liens permettent de garder la compatibilité. Dire que si tu trouves ton soft dans /bin/ alors les executables pour booter y sont.
Enfin, je pense que personne ne suit à la lettre la FHS. Exemple gentoo à /usr/portage ( alors que ça devrait être dans /var ), Debian a du /usr/games, avec des régles en plus, Fedora/RHEL ont longtemps eu /selinux, et ont toujours /usr/libexec ( suivant les gnu coding standards http://www.gnu.org/prep/standards/html_node/Directory-Variables.html ).
Donc au final, c'est aussi pour ça que je trouve l'auteur du blog comme se focalisant sur les détails "visibles", alors qu'il y avait déjà plein de problème. Le fait d'avoir un /usr/libexec pose des soucis pour les outils qui codent en dur les chemins tout comme /usr/games. ( et c'est juste les détails que j'ai en tête un dimanche matin avant le fosdem ).
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
sauf erreur de ma part, le blocage est de savoir si les admins peuvent ou pas mettre /run sur autre chose qu'un tmpfs.
Et le reste est commité dans le draft.
https://bugs.linuxfoundation.org/show_bug.cgi?id=718#c13
Et je pense que tu as visiblement une idée bien précise sur la façon dont le standard doit évoluer, à savoir d'abord discuter et ensuite coder. Ça, ça s'appelle du design by comitee. Parfois ça marche. Parfois ça marche pas.
Si la FHS fonctionne autrement et se décide à juste documenter le consensus, ça marche aussi. Donc au final, si les distributions y trouvent leur comptes, qui va être emmerdé ?
Malheureusement, le commit ne donne pas des masses de détails.
De ce que je vois, le changement a 2 composantes : passage sur un tmpfs ( donc /run, supposement tmpfs par défaut ) et passage dans un dossier utilisateur ( /run/media/$USER/$DISQUE ).
Mettre /media en tmpfs aurait sans doute été un problème pour les mises à jours ( ie, changement de comportement ).
Donc tu doit prendre /run ou un autre chemin.
Mettre /run/ entier, c'est niet. Donc un sous repertoire. /run/$USER ou /run/$DISQUE, y a des risques de conflits ( surtout /run/$DISQUE ). Donc ajout de /media, nom fixe.
/run/media/$USER, ça permet de monter 1 disque à la fois, ce qui est niet.
/run/media/$DISQUE, ça marche dans les cas simples, mais pas dans le cas d'une station ou plus d'une personne peut se connecter ( le fameux multiseat qu'on a tous deja utilisé via ssh ). On retrouve çavia du thin client, etc. En effet, si tu fait ça, quelqu'un peut mettre une clé du même nom, et toi, au mieux, tu te demandes laquelle c'est, au pire, tu écrit sur la mauvaise. De surcroit, avec des clés en fat32 ( ou en udf, comme Tanguy le propose sur son blog ) en lecture pour tous, il y a une fuite de données évidentes ( ie, tout le monde peut lire ma clé avec mes documents via ssh ). Une solution alternative serait de faire le montage en forcant l'umask et les droits, mais tout les fs ne le supportent pas; et il y a peut être un souci caché que j'ai pas trouvé dans cette façon de faire ( ne serais que parce que sauf erreur de ma part, aucune distro ne le fait ).
donc /run/media/$USER//$DISQUE, avec $USER ayant des acls.
Bien que je n'ai pas pu tester, je pense qu'une solution au problème d'avoir à taper des chemins plus long serait pour l'utilisateur expert de rajouter son device directement dans /etc/fstab. Udisks respecte les réglages et devrait du coup monter la clé la ou c'est demandé.
Le souci, c'est que la FHS dit juste "faut mettre les commandes pour monter les autres fs", en ne spécifiant rien.
Du coup, tu te retrouves à mettre tout ce qui pourrait servir à un moment à monter un disque dans /. Donc par exemple, sur debian, une des rares distros à se donner la peine de le faire proprement ( vu que les autres s'en foutent un peu, dans le sens ou personne ne teste vraiment, et surtout, personne n'ouvre de bug ), tu as tout les fs réseau et toutes les dépendances dans /lib, /bin, et /sbin/. Et j'ai eu du mal à trouver un contre exemple, mais j'ai fini par en trouver 1 ( aprés 4/5 essais ). Si tu veux avoir ton /usr en iscsi, tu peux pas :
http://packages.debian.org/sid/alpha/open-iscsi/filelist car les commandes sont dans /usr/
( et le iscsi est vachement plus courant que l'exemple capilotracté de sshfs que j'aurais pou sortir, ou celui d'avoir ton /usr en afs via kerberos ( http://packages.debian.org/sid/armel/openafs-client/filelist ))
En pratique, le fait d'avoir tout dans /usr, ça permet de faire des containers plus facilement ( ou justement, de monter totalement /usr via le réseau comme avant sans avoir à garder le /bin local en synchro avec le /usr distant ), ça permet de faire des rollbacks plus facilement ( même si personne ne le fait, je pense que snapper devrait réussir à en tirer parti sous peu ). Je comprends que ça dérange, car la migration entraine un risque, parce qu'on a le sentiment de bousculer l'ordre établi ( un comme avoir quelqu'un qui range ton bureau, ça te fait toujours chier ).
Mais en pratique, c'était à la bonne franquette pour savoir quoi était ou, et c'était pas terrible la façon dont les distros l'ont mis en place.
Ensuite, tout le monde n'a pas suivi, et pour l'avoir fait, je doit reconnaitre que si on m'avais pas dit, j'aurais sans doute rien remarqué tellement c'était sans douleur. Il ne reste plus qu'à attendre que quelqu'un en tire parti.
c'est sur un tmpfs pour pouvoir nettoyer tout seul le truc. C'est pas déconnant. Et pour des questions de sécurité, de simplification
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Parce que le json, c'est pas si vieux que ça ( dans le principe et dans l'usage en temps que tel, car sinon on aurait pu l'avoir plus tôt ).
Et parce qu'on veut avoir 1 fichier par entrée du menu, pour avoir 1 fichier par paquet installé. Ça rends le packaging trivial. ( donc pas besoin de hiérarchie d'objets )
Et parce qu'il y a pas que des menus chez freedesktop.
Enfin, les archives des discussions sont sur le web, tu doit réussir à trouver ça ( et les devs sont encore la, y a leur nom sur les documents )
Mais bon, des choses comme nodejs utilise le json pour les metadatas, donc c'est pas non plus un mauvais choix.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 6.
lxc de base utilise le même kernel que le système hote, donc on est pas à l'abri d'un souci. C'est pour ça aussi que des gens ont mis au point des choses comme des containers confinés par selinux. En fait, je devrait même pas avoir à expliquer à quelqu'un qui a fait une formation en sécurité, comme toi.
si tu étais admin, tu travaillerais sans doute avec des admins, et tu comprendrais que non, tout le monde ne le fait pas. Il suffit de voir le nombre de gens qui ne passent pas par la commande service pour ce genre de chose.
Je dit que le projet gentoo n'a pas réussi à trouver de volontaire pour avoir les alertes sécurités par email pendant un temps. Ensuite, ouais, les gens peuvent lire à la main les listes des autres distributions sans problème.
ben, systemd le fait pour moi, donc oui. Je parle d'environnement au sens variable d'environnement.
Je crois pas que le kernel utilise un json like. Mais genre, nulle part.
En fait, nginx non plus. Un json-like, ça implique de se faire charger par un eval ( vu que le json, c'est juste du javascript ) et la config de nginx ne le fait pas. Mais la configuration de nginx a choisi d'exprimer des choses que le .ini ne supporte pas ( genre avoir une hiérarchie de réglage ), donc le .ini n'était pas bon pour eux.
En fait, je crois pas que le fait de faire d'autre choix implique la stupidité en général. Les contraintes sont différentes.
Peut être qu'il veut pas faire planter son serveur en prod. Ou peut être qu'il a mieux à faire que de faire des comparatifs. Mais son email est sur le site, tu devrais directement lui dire de lancer google chrome avec des tas d'onglets sur son serveur, histoire qu'il puisse compléter l'article.
Donc pourquoi personne chez debian n'a écrit de script pour ça ? ( sauf à nier la race condition que j'ai évoqué, et à me dire ce qui ne va pas dans le raisonnement )
ah, la bonne vielle idée de mettre /etc dans git ou svn. J'ai déjà tenté, comme tout le monde. Et comme tout le monde, j'ai vu que c'était une idée à la con.
Déjà, tout ne rentre pas dans git/svn. /etc/localtime, un superbe fichier binaire, n'a rien à faire la. /etc/password, qui va changer aprés chaque installation de demon, c'est pareil. Tout les fichiers avec des mots de passes, c'est pas terrible. Et puis, ça gére pas forcément bien les owner des fichiers. Ou le stockage des liens, ça coince ( ou du moins, c’était pas bon à l'époque ). Ensuite, bah, /etc/ c'est pas tout ce qui sert à ton systéme, vu qu'il manque les paquets, etc. On va me dire "mais y a aussi /var/ dans sa proposition". Oui, parce que c'est bien connu, on peut prendre la base des paquets rpms ou deb et pouf, ç'est bon, ça se mets dans un vcs sans prendre une tonne de place, sans poser des soucis avec les diffs parce que c'est du binaire. Et surtout, ça bouge pas à chaque upgrade.
Et au final, on a quoi ? Ben rien, parce que ton dépôt, tu peux pas l'appliquer à une autre bécane sauf à vouloir un clone imparfait. Tu peux tout juste revenir en arriére d'un coup.
Mais en fait, quand on fait les choses bien, on utilise un outil comme puppet, chef, cfengine, etc. Comme le font toute les grosses distros comme dit à une table ronde au fosdem l'année dernière.
Alors, à peine accepté, c'est ni l'avis des gens de Mageia, ni l'avis des gens d'Opensuse. Ni des devs d'archs.
Et Suse a des sous, ils sont numéro 2 sur le marché, ( voir 1 sur certains marché ssi j'en croit leur plaquette ). Si ils voulaient refuser, ils pourraient. Par exemple, ils ont ni anaconda, ni yum.
Quand à Canonical, ils ont aussi assez de sous pour faire unity ( donc refuser gnome 3 ou kde ), pour faire tourner une boite de 400 ou 500 personnes, pour avoir son propre truc de gestion de cloud ( juju, maas ), voir même pour faire son propre systéme d'init. Donc j'ose supposer à partir de la 2 choses :
- si une boite qui gagne pas assez pour être à l'équilibre ( aka canonical ) a les moyens de pas suivre RH, d'autres ont les moyens. L'argument des sous est donc faux.
- si les distrib totalement communautaire veulent prendre openrc, upstart, init-ng ou juste garder sysvinit ( ce code shell si facile à maintenir, je pige pas que personne n'ai encore fait de fork à la MATE ), elles peuvent aussi. Y a rien qui les force.
Tu semble n'avoir aucune idée de la façon dont une distribution marche ou de la façon dont les décisions sont prises, donc tu te raccroche à un modèle erroné ou l'argent règne.
un bug ou le reporter n'a plus rien posté depuis 10 jours, ce qui nous laisse un peu sur notre faim sur son origine ou le problème réel. A plus forte raison si personne n'arrive à reproduire.
Parce que c'est pourri ?
Soit c'est du json, et c'est pourri pour de la configuration ( exemple, comment on fait un commentaire en json ).
Soit c'est du truc qui ressemble à du json ( cad, dans le cas que tu cites, nginx, un vague format avec des {} ) et c'est chiant à parser ( vu que c'est plus du json, tu oublies les outils classiques), et ça revient à faire ton propre DSL. Ce qui revient à augmenter encore la courbe d'apprentissage pour rien ( car ton histoire de json-like, en d'un péremptoire "c'est pas pro", ça apporte quoi ? ). Et c'est pourri.
Un peu dans tout les commentaires. Dans celui la aussi.
ça va être dur :
http://community.redhat.com/contributions/
Mais en effet, moi, j'aimerais bien aussi que l’origine des contributions soit plus varié.
Et pour ça, y a pas de secret, faut se bouger. Je suis sur qu'un spécialiste du sujet devrait sans souci apporter son expertise à un projet.
Sinon, bah, juste soutenir opensuse ( ah non, la communauté choisit plutôt de ressortir des trucs sans rapport datant d'il y a 5 ans ce qui démotive les rares gens motivés ), soutenir nokia ( ah non trop tard ), filer du pognon à Canonical ( ah non, personne paye ) ou à Mandriva ( ah non, comme Nokia ), enfin bref, injecter de l'argent dans les boites qui contribuent autre que RH.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
D’après https://linuxfr.org/wiki/karma , tu peux aller jusqu'à -10 par défaut.
Donc, si tu es à -3, ça veut dire que tu as un karma entre -20 et -10, ce qui veut dire que tu as perdu non seulement les 20 points de base, mais aussi ce que tu as pu avoir au fil du temps. Et je pense qu'à ce rythme, tu va juste être à -10 par défaut d'ici 2 semaines au mieux.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Bah, le .ini, c'est pas transcendant non plus.
Par exemple, il est pas formellement spécifié. Si j'ai :
Je suis pas sur que tout les parsers le lisent ( et me donne que toto a 2 valeurs, ou l'ordre ).
Genre python a 3 classe de parsers pour le .ini .
Il permet pas de faire de tableau, et de trucs à plusieurs niveaux imbriqués, n'a pas de schema ( même si ça pourrait se rajouter )
contrairement à du yaml, du xml, ou du json.
Ensuite, la syntaxe est comprise par tout le monde de façon quasiment intuitive, il y a des parsers pour tout
( même si ça peut coincer dans les détails ). C'est pas le format qui va résoudre tout les soucis du monde, mais je doute qu'il existe, et dans le cas de systemd, ça fait l'affaire. On s'en sert déjà pour le reste des projets freedesktop ( genre les menus, etc ), donc il est en plus "standard".
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 5.
Oui lxc marche avec les cgroups et systemd ( même en dehors du framework libvirt-sandbox http://fedoraproject.org/wiki/Features/Securecontainers )
Lennart explique sur un des nombreux blogs posts ce que systemd fait avec les cgroups :
http://0pointer.de/blog/projects/cgroups-vs-cgroups.html
Et il y a une documentation sur comment ne pas se marcher sur les pieds si tu veux utiliser les cgroups aussi :
http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups
Sinon, le blog que tu as pointé manque de perspective, par exemple, sur l'histoire du /usr merge, il ne pige pas que le role de / est passé à l'initrd, et que dont celui du /usr partagé est passé à tout /usr par le dit merge, ie, que c'est en faisant un système minimaliste à façon qu'on règle le problème du bloat de /.
Il dit que le passage à /run a été d'ignorer le FHS, mais justement, le changement vers /run fait parti du FHS 3.0 justement parce que les distributions se sont mis d'accord ( https://bugs.linuxfoundation.org/show_bug.cgi?id=758 ), et que le passage vers un sous dossier de /run est pour des questions de robustesses ( ie, pour une ressources non partagés sur un système qui lui est partagé , pour éviter les conflits de nom ).
Les divers changements sont pas la pour faire joli, en général, ça vise à tenter de corriger des vrais soucis. Personne ne se rajoute du boulot pour rien, y a déjà assez à faire sur les distributions classiques
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Le fait est que les gestionnaires de paquets pourraient faire le merge automatiquement. Sauf qu'ils font pas pour la plupart ( et je dit pour la plupart, car de ce que j'ai vu, au mieux, c'est un hook avec etc-update configuré à la mano par l'admin, mais je doute pas que quelqu'un a du faire un truc plus chiadé un jour ).
Par exemple, quelqu'un avait tenté d'intégrer ça dans mandriva :
http://blog.zerodogg.org/2005/09/29/common-configuration-parser-ccp/
Quand au fait d'être incompatible, bien sur. Si la solution miracle aux upgrades existait, je pense bien qu'on l'utiliserais depuis le temps ( exemple le ccp proposé plus haut ).
Maintenant, si tu prends l'exemple d'apache qui fourni un répertoire ou tu mets ta config en plus du fichier de base de la distro, le seul risque, c'est le jour ou apache change radicalement ( passage en 2.4 ), genre une fois tout les 4/5 ans. Pas une fois à chaque upgrade de version de la distro, ou une fois de temps en temps lors d'un souci de sécurité qui va modifier la config pour bloquer l'action TRACE ou changer je ne sais pas quel config par défaut incorrect.
[^] # Re: Fedora : Le lièvre et la tortue
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 2.
Non, je pousse mes paquets directement dans la distro. Ou je reprends le paquet et le recompile. Je mélange pas les paquets binaires le moins du monde, c'est moche.
J'ai été admin du projet Mageia pendant 2 ans, secretaire de l'association, membre du board, donc je connais la taille de la communauté, je sais combien y a de compte dans le ldap ( que j'ai aidé à mettre en place, que j'ai tenu à jour ), donc je pense être parfaitement capable de déterminer si c'est petit ou pas. Donc le droit de le dire, je le prends avec ou sans la permission d'un inconnu.
Ensuite que launchpad soit difficile à installer est bien connu. En fait, qu'un système de build soit compliqué à déployer est aussi connu. Et que les systémes de build soit spécifique est aussi hélas bien connu, mais sans doute parce que personne ne bosse pour les rendre compatible ( à part suse ).
Impressionnant. J'ai bossé dans une boite spécialisé en sécurité informatique après avoir eu un DESS en sécurité, on peut donc continuer à jouer celui qui a la plus grosse, mais je pense que c'est pas productif.
Et avoir suivi une formation est une chose, mais ça dépend de la durée, du contenu. Et la sécurité, c'est vague, ça va du très théorique ( genre la séparation de domaine et l'analyse haut niveau comme le ferait un analyste ) au plus pratique ( genre, savoir coder de manière sécurisé, mettre en place un firewall, faire un audit ). J'ai fait des cours de compta à la fac, je vais pas dire à un comptable comment il doit faire son métier.
La liberté de faire un truc implique pas de ne pas être ridicule. Exemple, tu as la liberté de poster des trucs ridicules, tu t'en sert, ça veut pas dire que ça reste pas ridicule.
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
En raid logiciel pur, ie sans /boot séparé hors des partoches en raid ?
Dans mon souvenir, le souci est que grub ne comprenant par le raid, il faut charger le kernel et l'initrd depuis une partoche /boot en dehors du raid, et faire la synchro plus ou moins à la main.
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Oui, et visiblement, il y a encore d'autres endroits dans le cookbook d'upstart ( que j'ai commencé à relire ) ou ils reprennent le même système de modifier des fichiers qui sont pas de la configuration.
http://upstart.ubuntu.com/cookbook/#list-all-jobs-with-no-stop-on-condition
Mais c'est un problème compliqué, car parfois, un fichier de configuration n'arrive pas à exprimer toutes les subtilités de ce que tu veux exprimé, et parfois, faut juste essayer de rentrer dans les clous.
dpkg-divert, c'est un moyen de hacker sans trop de dégât immédiat ton système, mais c'est pas tenable. Et tu peux pas rendre tout configurable non plus.
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Alors en lisant la discussion sur lwn, quelqu'un a pointé
et notamment http://upstart.ubuntu.com/cookbook/#override-files
Donc ça peut se faire proprement depuis upstart 1.3 ( soit depuis bientôt 2 ans ).
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Bah, voila, une troisième méthode que je connaissait pas, et non, je parle en effet d'une autre façon de faire.
Mon coloc s'était plaint de devoir mettre "UsePAM yes" dans sa config, et j'avais fini par trouver un truc en lançant ssh à la demande via les sockets, ce qui fait 1 cgroup par connexion.
Par exemple, sur ma machine ( ou je fait ça pour économiser 3mo de ram afin de pouvoir continuer à lancer des gros trucs java pour remplir les 8G qui reste ), en lançant 2 connexion ssh, j'ai 2 entrées dans la sortie de systemctl :
Et chacune est dans son propre cgroup, ce qui fait qu'un restart du service ne tue rien.
Mais c'est pour moi un effet de bord du fonctionnement par socket plus qu'autre chose, donc je trouve ma méthode tiré par les cheveux.
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 5.
en gros, tu prends un job upstart au pif, genre ssh sur mon n9 :
Il y a 2 parties :
* la partie script ( entre script / end script )
* la partie pas script, à savoir le reste
La, si je veux par exemple que ssh ne s’arrête pas quand dbus se coupe ( c'est mon tel, je fais ce que je veux ). Ou imaginons que je veuille changer la directive oom, changer la valeur de nice, etc. Faut que je modifie le fichier.
Sauf que si je modifie le fichier, il se passe quoi à la prochaine mise à jour qui va faire pareil ( exemple, une modif qui change le chmod 0755 en 0700 pour cause d'un souci de sécurité ( exemple inventé )) ?
3 choix :
- le système de paquets écrase ma modification. Donc je doit repasser pour la remettre, si je m'en souvient.
- le système de paquets n'écrase pas la modification. Mais je doit passer pour rajouter sa modif dans mon fichier modifié.
- le système de paquets me demande, donc je doit passer pour fusionner les changements.
Dans tout les cas, ça requiert d'être la pour s'occuper de l'upgrade et tout ça parce qu'il y a des informations du domaine de la distribution (à savoir la partie 'script' ) mélangés avec des choses du domaine de l'admin ( à savoir les dépendances, le choix de l'oom ou pas, du nice, etc ). Et ça, c'est un job simple, il y a pas mal d'option en plus dans upstart.
Systemd gére ça de façon élégante en prenant les informations de 3 fichiers, et en appliquant la config dans un ordre précis. Si j'ai toto.service dans /lib et dans /etc:, les informations en plus de /etc ( genre une valeur de nice ) se rajoute à celle de /lib. Donc quand la distro modifie le fichier dans /lib, j'ai rien à faire de spécial. Il y a même un outil spécifique ( http://www.freedesktop.org/software/systemd/man/systemd-delta.html ) pour trouver ce qui a été modifié dans /etc par rapport à /lib
Les daemons font en général un double fork. Donc ton wait va attendre sur le premier, pas sur le second. Et tu ne peux faire de wait que sur un process fils, sauf erreur de ma part. Donc à partir du moment ou ton script d'init t'a rendu la main, tu peux plus faire de wait sur le pid de bind, donc inapplicable dans le cas exposé, à savoir d'un reboot. D'ou l'usage de ptrace par upstart pour choper le pid ( http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ ).
oui, et sauf erreur de ma part, Ubuntu ( entre autre ) l'a fait avant que Lennart ne pousse ça dans systemd, vu que je me souvient distinctement avoir entendu raler le dev debian qui servait de sysadmin dans mon ancien job contre les devs Ubuntu d'avoir mis /var/run en tmpfs. Il avait du rajouter 2/3 lignes pour le script d'init pour refaire /var/run/nufw/ ou ce genre de choses avant de lancer le démon de notre produit.
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 1.
D’après ce que je lit ici et la, grub-ieee127 ne serait pas ce que tu veux ? ( la dernière sparc que j'ai vu, c'était à la poubelle y a 1 an, donc je suis plus très au courant de ce qu'il faut faire en dehors de "magouiller avec l'open firmware" ).
Mais si tu arrives à le faire marcher, je suis sur qu'un peu de doc pourrait aider.
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Alors d'une part, il y a d'autre fondateurs de distros qui postent parfois ici et la, et tu sembles prendre ça plus à la légère ce qu'ils disent ( enfin pareil, c'est un avis personnel, pas une parole divine ).
Et d'autre part, Patrick a un vision orienté vers son but, à savoir la maintenabilité par lui même de la distribution, et la simplicité extréme que ça requiert, quitte à ce que ça ne réponde pas au besoin de tout le monde.
Son refus de pam est un exemple, et pas grand monde ne va le suivre sur ce point, car même si pam a eu des débuts difficiles, ça reste relativement pratique dés que tu veux avoir un serveur ( comptes en ldap, kerberos ) ou si tu veux essayer de rivaliser avec du windows sur le poste client ( pareil, ldap, etc ). Ou de la sécurité ( authentification à 2 facteurs, lecteur d'empreinte digital ).
D'ailleurs, la gestion des processus par cgroups de systemd ( pour en revenir au sujet ) implique de dire à sshd de se "détacher" des processus utilisateurs pour éviter de les tuer lors d'un restart, et d'avoir son propre cgroups par utilisateur ( ce qui permet d'appliquer des quotas cpu/ram/etc par utilisateur via les cgroups, justement ). Et pour ça, le moyen le plus propre est de passer par pam, qui va voir au login qu'il y a un utilisateur et qui va le changer de cgroups.
Sans ça, tout les utilisateurs sont dans le cgroup de sshd, et se font donc tuer sans pitié en cas de restart du demon. ( il y a une méthode pour faire autrement, mais c'était tirer par les cheveux et j'ai oublié ).
Donc un passage à systemd serait sans doute aller à l'encontre de son objectif de garder pam hors de slackware ( sauf si ce n'est plus d'actualité, bien sur ).
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Scott explique pourquoi il a pas pris initng, launchd etc dans ce post :
http://netsplit.com/2006/08/26/upstart-in-universe/
Et moi, j'avais le sentiment que upstart a commencé comme projet à part ( au vue du vieux nom de domaine en .at ) avant de passer sous l'aile de Canonical. Mais vu que dans mon souvenir, il y a le fameux CLA, je doit sans doute avoir tout faux.
Il y a aussi eu des discussions pour l'intégration de systemd, voir une page de wiki ( https://wiki.ubuntu.com/systemd ), mais Canonical a choisi de garder Upstart ( http://www.iloveubuntu.net/ubuntu-1210-quantal-quetzal-continue-upstart-systemds-rumors-cleared ). La raison évoqué est les tests ( upstart possède une batterie de 12000 lignes de tests en C ), et le fait que upstart réponde plus à leurs besoins.
Tel que je vois la ou Canonical veux aller, c'est l'embarqué ( smartphone, tv ), et le cloud avec des bécanes jetables ( ie, les guests ). Et je pense que le concept de gestion d'événement s’intègre bien aussi avec le premier ( besoin de mobilité et d'une gestion dynamique ) qu'avec le second ( rajouter un file system en réseau via ceph, etc ).
Upstart a été utilisé pour chromeos ( donc un pc portable mobile ), pour le nokia n9 ( donc aussi un appareil mobile ), et sans doute dans Ubuntu Tv et le reste.
Ensuite, pour la partie cloud, ils sont partie sur juju plutôt que de l'intégrer ça directement dans l'OS via upstart, c'est un peu dommage ( et qu'on me dise pas "ça rends juju portable" car ça continue à utiliser des ppa à tout va ). La transparence réseau de upstart, ça aurait pu faire une sacré killer feature pour le système.
( sinon, upstart dépend de libNIH /o\ )
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 1.
Si, le projet est à l'abandon. Mais j’étais pas au courant du port pour netbsd, ni du fait que ça dépend fortement de mach ( ceci dit, j'aurais du m'en douter, mais j'aurais penser qu'un soft non portable aurait fait raler tout le monde ). Je suppose que le fait de dépendre des plists ( un format basé sur xml d'os x, qui peut aussi être compilé en binaire ) risque de faire grincer des dents.
D'ailleurs, si des gens ont du temps à perdre, y a la présentation du dev de launchd chez Google en 2007 :
http://www.youtube.com/watch?v=SjrtySM9Dns
Il explique par exemple que le fait de lancer plusieurs choses en même temps permet de tirer parti des machines multi cores, il montre pas mal d'idées qui se sont retrouvés dans systemd ( le lancement activé par un chemin, par socket et dans le désordre ), et il montre aussi le genre de choses qu'on peut faire avec l'activation par socket dans la session user. Son exemple, lancer X ( qui plante quand il teste ) ou ssh-agent à la demande, ce qui permet de décharger la session des trucs qu'on utilise pas vraiment ( avec comme avantage de consommer un peu moins de ressources, d'avoir un session qui démarre un peu plus vite et surtout d'être plus robuste ).
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Visiblement, c'est dispo :
http://robertmh.wordpress.com/2009/07/18/grub-on-sparc/
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Ou Ceph, ou glusterfs.
Je suis pas sur que zfs fasse la transparence réseau. ( mais comme tout les ex produits Sun, ça fait sans doute tout y compris le café )
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Il dit qu'il a plus de genoux
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 10.
Donc récapitulons. J'ai une opinion donc je manque d'objectivité ( c'est grosso modo la définition, mais bon, passons ). Je donne donc pour éviter de tomber dans ce travers un lien de quelqu'un que je connais pas, mais d'un coup j'aurais peur de dire ce que j'ai déjà dit 15 fois sur linuxfr.
Certes. Et au final, quoi que je dise, je suis pro fedora, donc forcement, je vomis ce que fait Ubuntu. Parce que c'est bien connu, quand on utilise une distribution, ça retire tout sens critique, donc pas besoin de donner d'argument.
Au lieu de m'éterniser sur des arguments stériles et des attaques ad hominem, regardons de plus prêt ce que l'auteur de l'article dit :
Rajoutons donc ce que je sais à savoir que upstart utilise la commande ptrace pour suivre les process, et que curieusement, ça passe pas tout le temps. Comme je ne veux pas donner dans le FUD, il y a 2 liens :
https://bugs.launchpad.net/upstart/+bug/406397
https://bugs.launchpad.net/upstart/+bug/703800
Donc voila 4 problèmes liés à l'architecture d'upstart ( ie, le fait d'avoir un fichier de config qui est en fait un script, et le fait d'utiliser ptrace pour suivre les processus ), corrigé par le design de systemd, à savoir avoir des fichiers au format .ini, ce qui permet de mettre des priorités sur les directives qui découlent d'un ordre de lecture prétabli, et l'usage des cgroups, pour gérer les groupes de processus. Cgroups déjà à la base de lxc, donc relativement étanche.
Quand je dit subtile, je veux dire par la difficilement identifiable. Par exemple, se connecter en ssh, et relancer un serveur web et voir plus tard que tout d'un coup, ton cgi qui appelle la commande 'sort' merdouille parce que la variable LANG n'a pas été nettoyé ( ie, LANG=FR_fr est passé au script, puis à apache, puis à ton cgi, puis à 'sort' qui va trier les caractères diacritiques d'une façon différente en fonction de la locale ). Ou voir qu'en fonction de comment est lancé ton soft, tu as un autre format de date dans les logs, car il reprends LC_ALL et LC_TIME. Bien sur, si on était sur d'avoir toujours le même environnement clean, ça n'arriverais pas ( khof http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRestartEnvironment khof )
J'ai rien contre Gentoo, j'ai un serveur sous Gentoo chez OVh, et je dirais même que je connais des gentooistes ( bien la preuve que je suis pas raciste ). Mais sérieux et solide n'est pas forcément ce qui me vient à l'esprit. J'aurais plutôt dit flexible et adaptatif.
Sérieux, pour moi, ça implique par exemple un suivi des soucis de sécurité et pendant un bon bout de temps, il n'y plus eu d'alertes de sécurité (cf http://www.gentoo.org/security/en/glsa/index.xml entre janvier 2010 et mai 2010 ).
Solide, je dirais que c'est plus la personne qui décide de pas abuser de l'adaptabilité. Il faut bien voir qu'en pratique et en fonction des choix de l'admin, chacun a un système différent. L'utilisateur est le premier, dernier et seul personne à faire la QA de son système. ( bon, pas exactement, mais j'ai toujours voulu caser la formule ). Les paquets passent de masked a unmasked sur la base des retours des gens, ce qui garantit des tests minimums, mais les retours sont se font dans des environnements différents. Et c'est une approche différente d'une debian ou d'une autre distro binaire, ou tout le monde a les mêmes binaires ce qui fait que si ça marche chez X personnes, alors il y a moins de raison que ça foire ailleurs. Alors que gentoo, avec les use flags, etc…
Et comme il y a pas de mises à jours de sécu au sens "mise à jour minimal" avec la QA qui va avec, la solidité n'est pas une chose que j'estime acquise, bien que je n'ai pas eu à me plaindre personnellement si souvent et que c'est suffisant pour ce que j'en fait.
Openrc, qui a quand même eu 10 ans pour se faire adopter, semble faire un revival. Bien sur, personne ne va dire que openrc, il supporte le boot en parallèle avec des bugs compliqué à reproduire ( https://bugs.gentoo.org/show_bug.cgi?id=391945 ).
Je n'ai pas dit "révolution", j'ai laissé mon pull noir à col roulé au placard. Et j'ai du mal à saisir. L'auteur de l'article n'a pas eu de situation ou le "fair share scheduling", traduisons par "partage équitable de l'ordonnanceur" a pu s'appliquer, donc ça rends systemd compliqué ? Si ses serveurs ne sont pas chargé ras la gueule au point d'en avoir besoin, ou est le souci ?
Pour info, ce dont il parle est détaillé la : http://lwn.net/Articles/415740/ , avec la réponse de lennart la : http://lwn.net/Articles/415756/. Si les gens passent pas leur temps à mettre leur bécane sur les genoux à grand coup de compile kernel pour constater si systemd fait un truc, c'est la faute de systemd ?
Pour info, ce que l'auteur a voulu dire, c'est que contrairement à smf, l'init de solaris, systemd n'utilise pas de xml pour sa config donc l'admin n'a pas à interagir avec. Ensuite, la doc est en docbook ( un format de publication en xml ), et en effet, 15% du contenu du tarball, c'est de la doc en xml.
Mais c'était bien tenté.
Pas moi. Ni les gens de chez Sun, vu qu'ils ont refait le système avec SMF. Ni les gens d'Ubuntu ou de Chrome OS, vu qu'ils ont upstart ( ou RHEL 6, ou Maemo ). D'ailleurs pas les gens de Gentoo, vu qu'ils ont fait openrc. En fait, Apple aussi a refait son système d'init il y a 3/4 versions. Donc oui, si on retire tout ça, tout le monde pense que ça marche.
Enfin pas ceux qui ont fait runit ou initng non plus. Ni les gens de FreeBSD qui ont proposé un portage de launchd dans un Google Summer of Code.
Enfin donc, à part tout les gens qui sont tellement d'avis que ça fonctionne correctement qu'ils se sont dit qu'il faut le remplacer, ouais, tout les autres pensent que ça marche.
Enfin si on retire tout ceux qui ont choisi systemd, comme arch, opensuse, mandriva, fedora mageia, ou des boites comme intel ou rackspace ( vu que intel bosse dessus, rackspace bosse sur journald ), oui, tout les autres pensent sans doute que ça marche comme il faut.
Mais bon, je suppose que juste donner des noms, ça ne va convaincre personne, donc je vais détailler. Déjà, quand tu dit "le systeme d'init marche depuis 40 ans", tu veux sans doute parler de sysvinit, et donc depuis 30 ans. Bon, pas grave, 10 ans, c'est presque rien. Le système des premiers unix était sans doute un chouia plus frustre, et je me demande si à l'époque, les gens ont ralés devant la complexité d'avoir gasp, une couche d'indirection de plus.
Alors déjà, si ça marche bien, pourquoi toutes les distros ont rajouté le support des tags LSB pour l'ordre des scripts si le format de base est si bien ? Non, pas la peine de répondre, c'est parce que c'est moisi de devoir choisir à la main l'ordre. Et parce qu'il y a pas vraiment de format, juste des conventions, comme le fait de faire un printf, le fait d'avoir X ordres. Je vais pas parler des codes de retour des initscripts, je risquerais de devenir grossier.
Ensuite, non ça me marche pas bien. Par exemple, bind est le premier exemple que je donne à chaque fois. Bind utilise la commande rdnc pour signaler au processus principal qu'il doit s’arrêter. Sauf que comme c'est une communication unidirectionnel, en fonction de la charge de la machine, tu ne sais pas si bind est coupé ou pas au moment ou la commande rends la main. On pourrait croire naïvement que ça n'a pas d'importance, sauf que si tu fais un stop et un start ( ce qui est quand même la façon la plus universelle de faire restart ), et ben parfois, bind ne se relance pas, car l'autre n'est pas mort. Bien sur, ça dépend de la machine et de sa charge. Et se dire qu'on est passé d'un coup en fonctionnement asynchrone sans le savoir, ça montre bien qu'il y a des soucis.
Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.
Mandriva fait ça avec un sleep 5, ce qui tout aussi un hack.
Systemd, il gère ça en suivant tout les process du groupe. Ie, quand ils sont morts, il le sait.
Le deuxième exemple, c'est mon ami Sympa. Sympa, c'est vachement bien, plus souple de mailman sauf qu'il y a un léger souci. Quand tu le connectes à postgresql ( ce que l'équipe de sysadmin de Mageia a fait ), si la base de données n'est pas disponible, il attends. Il attends pas en tache de fond. Il attends et le script d'init ( une horreur qui lance 5 services d'un coup ) se bloque. Donc si ta base se lance après par la magie des scripts, ton serveur se bloque au boot. En fait, c'est aussi amusant si postgresql mets du temps à mettre son socket à disposition pour une raison X ou Y, car même en étant lancé avant, sympa bloque le boot. Alors bien sur, une fois que tu as pigé le souci, ç'est facile à corriger. D'ailleurs, ça a été corrigé upstream d’après le packageur debian avec qui j'ai eu le temps d'échanger sur le sujet.
Systemd, il gère ça en lançant tout en même temps, et en s'en foutant d'un process qui bloque.
Alors le 3eme exemple, c'est Apache. Apache, c'est un soft cool, ça gère les processus pour toi. Sauf que voila, parfois, y a des processus qui partent en vrille ( ce qui arrive quand on embarque des saletés dedans comme php, ou des cgis ), et parfois, pareil que bind, ça mets du temps à mourir. Comme le process principal tot ou tard meurt, il reste parfois des orphelins. Et c'est coriace ce genre de bestiole, car faut que l'admin vienne à la main faire le ménage. Bien sur, pareil que bind, ça arrive pas toujours, même rarement. Il faut bien tomber sur des circonstances aggravantes pour que ça se produise.
Mais bon, c'est pareil, c'est entièrement du à sysV. Parce qu'avec les cgroups, tu peux faire du kill(9) à tout va après un temps.
Ensuite, des gens vont te dire que la pauvreté de sysV implique de dupliquer le code pour passer un soft en daemon dans chaque soft, que statistiquement tout le monde ne le fait pas tout ce qu'il faut comme il faut ( à savoir se rattacher à un groupe de process, faire un chdir('/'), fermer tout les descripteurs de fichiers, faire un double fork, et sans doute des trucs que j'oublie ) et que du coup, ça cause des soucis
Avec sans doute une petite biére, ils vont continuer pour expliquer qu'il y a des problématiques à la con entre setuid, setgid ( l'ordre par exemple, ou le fait de fait un initgroup avec setgid ), et que même les meilleurs oublient, ou te parler de cas ou un init script s'est vautré sur un fichier de pid non effacé du à un reboot intempestif de la machine.
D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".
Mais bon, je suppose que tout ces gens, tu va sans doute dire que leur objectivité est impossible, qu'ils ont tort parce que toi, tu as eu aucun problème donc ça prouve bien que ça n'existe pas ?
# Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
On m'a filé ça :
http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight
L'auteur détaille une paire de souci avec upstart tout au long de l'article, et explique aussi tout au long des liens le genre de souci subtile qu'il y a avec l'usage de scripts de démarrage ( genre l'environnement pas clean )
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 6.
Le souci du raid logiciel, c'est qu'il est logiciel. IE, avant d'avoir grub2, je pense qu'il fallait magouiller pour booter directement sur un raid logiciel sans avoir un /boot séparé. Il y a aussi l’intégration avec la carte de management distante souvent vendu avec les serveurs, ce qui permet d'agir même quand le serveur est dans le pâté complet
L'avantage aussi du raid hardware, c'est que c'est grosso modo "techos pas cher"-friendly. Tu as ton alerte, tu as le disque qui clignote, tu dit au mec de remettre le disque en réserve, et voila. ( et je sais pas si le disque qui clignote est une feature standard des serveurs avec du raid soft ).
Enfin perso, moi, j'étais dans le camp des gens en faveur du raid soft quand on a eu la discussion à mon taf, mais j'irais pas qualifier les gens qui font du raid hard de mauvais admins. Si les cartes raids se vendent, c'est bien parce qu'il y a des gens qui achètent et qu'ils y trouvent leur compte
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 10.
Perso, un mec qui a une kalach en état de marche et qui s'en sert, je suis pas sur que j'aurais vraiment de le contrarier en remettant en cause ses capacités. Je dit ça, je dit rien.