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
[^] # 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