/run or not /run

Posté par Frédéric Massot (site web personnel) le 04 avril 2011 à 10:07. Modéré par Xavier Teyssier. Licence CC By‑SA.

Étiquettes :

avr.

2011

Ces dernières semaines les personnes clés des principales distributions se sont réunies pour discuter des problèmes liés aux données d'exécution (runtime data) utilisées lors de la phase de démarrage et surtout de leurs emplacements.

Lors du démarrage d'un système GNU/Linux différents programmes (initscripts, dracut, mdadm, etc) ont besoin de stocker leurs données d'exécution dans l'arborescence et cela avant les éventuels montages annexes (/home, /usr ou /var). Ces données sont aussi utilisées par les programmes et daemons lors du fonctionnement du système.

Actuellement, les distributions utilisent différents subterfuges pour stocker ce type de données dans des dossiers cachés : /dev/.mdadm, /dev/.mount, /dev/.systemd, /dev/.udev, etc. Elles utilisent pour la plupart le répertoire /dev pour stocker les premières données, ce dossier est de type tmpfs et est disponible dès les premiers instants du démarrage.

À la suite des derniers montages (/home, /usr ou /var) les daemons sont lancés, ils utilisent principalement le dossier /var/run pour leurs données et cherchent les données liées au démarrage dans les différents dossiers /dev/.xxx ou autres selon les distributions.

Pour en finir avec cette cacophonie, les principales distributions ont décidé d'ajouter le dossier "run" à la racine. Ce dossier fera partie de l'arborescence initiale des prochaines versions, il contiendra les données contenues auparavant dans les dossiers /dev/.xxx, /var/run, /var/lock, /lib/init/rw, etc.

Cette décision est techniquement simple et simplifie la liaison entre les données liées au démarrage et les programmes, elle a souvent été envisagée mais repoussée pour des raisons politiques, des craintes d'intense flameware et la rupture avec la LSB/FHS.

Les développeurs de dracut, udev et systemd ont déjà mis à jour ces logiciels. Les distributions utiliseront le répertoire /run de façon progressive avec, dans un premier temps, des montages de type bind des anciens répertoires vers /run.

Lennart Poettering (Pulseaudio, avahi, systemd) a rédigé un mail pour faire le point sur cette réunion, annoncer le changement et les phases de mise en place.

Alors, LSB/FHS outragée, LSB/FHS brisée, LSB/FHS martyrisée… crouch, touch, pause, engage !

N. D. M. : Les principales distributions impliquées sont Debian, SuSE, Ubuntu et Fedora.

Aller plus loin

Mail de Lennart Poettering (249 clics)
Demande d'ajout de /run dans la FHS (262 clics)
LSB : Linux Standard Base (214 clics)
Filesystem Hierarchy Standard (167 clics)

# not /run

Posté par Xavier Teyssier (site web personnel) le 04 avril 2011 à 10:09. Évalué à 10.

Et j'ai une excellente raison d'être contre la création de ce répertoire : pour aller dans /root, aujourd'hui, /r<completion> suffit. Demain, avec /run, il faudra une touche de plus. Groumph.
- [^] # Re: not /run
 
 Posté par Anonyme le 04 avril 2011 à 10:32. Évalué à 4.
 
 Bon ben, /Run ?
 Si c'est accepté j'veux un achtécé dizayeur.
- [^] # Re: not /run
 
 Posté par JoeltheLion (site web personnel) le 04 avril 2011 à 10:35. Évalué à 6.
 
 Utilise autojump :)
- [^] # Re: not /run
 
 Posté par zebra3 le 04 avril 2011 à 10:51. Évalué à 10.
 
 Je n'ai jamais tapé « # cd /root ».
 Un simple « # cd » suffit.
 
 Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
 - [^] # Re: not /run
 
 Posté par Anonyme le 04 avril 2011 à 13:19. Évalué à 7.
 
 Nouveau sondage en perspective o/
- [^] # Re: not /run
 
 Posté par Victor STINNER (site web personnel) le 04 avril 2011 à 10:53. Évalué à 4.
 
 Bah si tu te logues en root, "cd<entrée>" suffit ! (3 touches), plus rapide que "/r<tab><entrée>" (4 touches) :-)
- [^] # Re: not /run
 
 Posté par sam80 le 04 avril 2011 à 12:11. Évalué à 6.
 
 Moi c'est le répertoire /media qui m'embête à mort. A chaque mise à jour de autofs je dois faire attention à ne pas remplacer mes fichiers de config. J'ai toutes mes données dans /mnt/data et fait donc un usage abusif du cd /m<complete>/d<complete>.
 
 Si Xavier a vraiment l'habitude d'utiliser cd /r<complete>, je comprends qu'il soit effrayé par le /run. Malgré mes efforts je n'arrive jamais à taper: less file, mais je tape toujours: cat file | less. Et nous avons tous certains automatismes comme celui - ci.
 
 Avec les /config, /run, /media, ..., la racine devient une véritable jungle.
 - [^] # Re: not /run
 
 Posté par Xavier Teyssier (site web personnel) le 04 avril 2011 à 13:48. Évalué à 2.
 
 "effrayé" est un bien grand mot, mais oui, l'arrivé de /run risque de me faire râler un peu.
 
 Et non, un simple cd ne suffit pas : généralement, j'évite de me logguer directement en root.
 
 Et effectivement, j'ai eu le même problème avec /mnt/data lorsque /media est arrivé. Depuis, ledit répertoire s'appelle directement /data. Moins propre, mais /da<complete> est quand même plus rapide que /m<complete>/d<complete>...
 - [^] # Re: not /run
 
 Posté par zebra3 le 04 avril 2011 à 14:02. Évalué à 6.
 
 Et non, un simple cd ne suffit pas : généralement, j'évite de me logguer directement en root.
 
 Sur Debian et Red Hat, /root n'est lisible que par root par défaut. J'imagine que c'est le cas pour toutes les distributions, et qu'il y a une raison pour ça : la sécurité.
 
 J'ai donc l'impression que tu es dans un cas à part…
 
 Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
 - [^] # Re: not /run
 
 Posté par Xavier Teyssier (site web personnel) le 04 avril 2011 à 14:25. Évalué à 4.
 
 J'utilise principalement Debian chez moi et Red-Hat au boulot. Et oui, sur ces distributions, /root n'est pas lisible pour un utilisateur quelconque. En revanche, il est tout à fait utilisable pour un utilisateur sudoers ayant les bons droits...
 
 [^] # Re: not /run
 
 Posté par JGO le 04 avril 2011 à 14:39. Évalué à 3.
 
 Et ça te/vous dérange pas de devoir taper sudo devant chaque commande ? chaque fois "sudo cd" vers un répertoire pas lisible par user, chaque fois "sudo vi" pour un fichier de conf, chaque fois "sudo make modules_install" pour le noyau, "sudo mount /boot"... 5 caractères à chaque ligne où on a besoin des permissions root !
 
 [^] # Re: not /run
 
 Posté par Hobgoblins Master (Mastodon) le 04 avril 2011 à 15:19. Évalué à 2.
 
 Sur une machine sans importance, tu peux te permettre sudo -i, sudo su ou autre joyeuseté, mais sur un serveur de prod, sudo à chaque commande aide beaucoup à la traçabilité… Et avec un alias type _=sudo, ça fait plus 5 caractères, mais 2 ;)
 
 [^] # Re: not /run
 
 Posté par zebra3 le 04 avril 2011 à 15:21. Évalué à 1.
 
 Et le mot de passe ?
 
 Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
 
 [^] # Re: not /run
 
 Posté par Hobgoblins Master (Mastodon) le 04 avril 2011 à 15:28. Évalué à 1.
 
 Le mot de passe de qui ?
 
 [^] # Re: not /run
 
 Posté par zebra3 le 04 avril 2011 à 15:39. Évalué à 1.
 
 Ben de l'utilisateur qui lance sudo, tiens
 
 Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
 
 [^] # Re: not /run
 
 Posté par Hobgoblins Master (Mastodon) le 04 avril 2011 à 15:54. Évalué à 2.
 
 Un fois toutes les 20 minutes d'inactivité, ça reste raisonnable non ?
 
 [^] # Re: not /run
 
 Posté par JGO le 04 avril 2011 à 18:40. Évalué à 6.
 
 Avec un shell en user, mes copains peuvent avoir les droits root pendant 20 minutes en passant derrière moi juste en tapant sudo. J'ai plein de xterm sur tous bureaux virtuels (ils ont des positions et dimensions qui dépendent de l'activité qui leur est assignée), je ne me rappelle pas desquels j'ai utilisés pour taper juste un petite commande en root. Alors que mon xterm en root a un code couleur dans le PS1 que je ne peux pas manquer de voir, et j'en sors dès que j'ai fini.
 
 [^] # Re: not /run
 
 Posté par Édouard Siha le 05 avril 2011 à 13:37. Évalué à 7.
 
 C'est peut-être pour ça qu'il faut verrouiller ta session quand tu quittes ton poste...
 
 [^] # Re: not /run
 
 Posté par JGO le 05 avril 2011 à 15:01. Évalué à 1.
 
 Un jour quand ubuntu aura conquis la planète, il y aura des vers qui se propageront en prenant le contrôle des consoles ouvertes avec un sudo lancé récemment, avec mot le de passe déjà entré.
 
 [^] # Re: not /run
 
 Posté par Anonyme le 05 avril 2011 à 18:38. Évalué à 4.
 
 while :; do sudo rm -rf /*; done;
 
 Tu prends n'importe quel kévin sur une Ubuntu de base, il est fait…
 
 [^] # Re: not /run
 
 Posté par LupusMic (site web personnel, Mastodon) le 06 avril 2011 à 03:56. Évalué à 1.
 
 J'ai le réflexe de taper <ctrl>+<alt>+<L> quand je quitte mon ordinateur, et l'autolock configuré à 30 secondes.
 
 Non, je ne suis pas paranoïaque, je suis responsable :)
 
 [^] # Re: not /run
 
 Posté par J Avd le 04 avril 2011 à 20:13. Évalué à 2.
 
 %sudo ALL=(ALL) NOPASSWD: ALL
 
 Et des fois ça fait mal :) du coup ça incite à mettre en place un backup
 
 "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
 
 [^] # Re: not /run
 
 Posté par JGO le 04 avril 2011 à 15:31. Évalué à 2.
 
 Quelle est la différence pour la traçabilité que HISTFILE / HISTSIZE ne règlent pas ?
 
 [^] # Re: not /run
 
 Posté par BFG le 04 avril 2011 à 15:44. Évalué à 2.
 
 La différence (je suppose que vous parlez de changer le HISTFILE/HISTSIZE de root) est que cela n'indique pas quel utilisateur a exécuté la commande. Alors que "sudo <commande>" est bien enregistré par sudo dans un fichier journal.
 
 [^] # Re: not /run
 
 Posté par Hobgoblins Master (Mastodon) le 04 avril 2011 à 15:45. Évalué à 5.
 
 Il y a HISTSIZE…
 
 C'est rarement configuré pour avoir plusieurs shells ouverts en parallèle – le dernier fermé écrase l'historique des autres
 
 C'est rarement horodaté – où alors c'est pénible à lire
 
 On ne sais jamais qui à lancé la commande
 
 Sudo trace dans syslog, et syslog est expédié en temps réel sur le réseau
 
 Du coup, ce n'est vraiment pas pratique quand on travaille à plusieurs…
 
 [^] # Re: not /run
 
 Posté par zebra3 le 04 avril 2011 à 16:13. Évalué à 2.
 
 C'est rarement configuré pour avoir plusieurs shells ouverts en parallèle – le dernier fermé écrase l'historique des autres
 
 Ben faut le configurer alors. C'est pas le rôle de l'administrateur ?
 
 Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
 
 [^] # Re: not /run
 
 Posté par Frédéric Perrin (site web personnel) le 05 avril 2011 à 14:52. Évalué à 4.
 
 Ce qui 1) n'est pas forcément possible 2) ne règle qu'un point sur les autres avantages.
 
 [^] # Re: not /run
 
 Posté par stopspam le 05 avril 2011 à 23:09. Évalué à 0. Dernière modification le 07 avril 2011 à 10:49.
 
 Sur une machine sans importance, tu peux te permettre sudo -i, sudo su ou autre joyeuseté, mais sur un serveur de prod, sudo à chaque commande aide beaucoup à la traçabilité… Et avec un alias type _=sudo, ça fait plus 5 caractères, mais 2 ;)
 
 J'ai franchement jamais compris l'utilité de sudo à part laisser la possibilité à n'importe quel user de passer root facilement (cf: http://www.courtesan.com/sudo/security.html). Pour le problème de traçabilité je vois pas. Chez moi la config est ainsi :
 
 ben .bash_history ça existe avec root hein ;)
 
 seuls les users membre du groupe wheel peuvent passer root
 
 connexion directe sur ssh avec root désactivé
 
 Je suis root sur mon serveur de prod et j'en suis fier !
 
 [^] # Re: not /run
 
 Posté par stopspam le 05 avril 2011 à 23:11. Évalué à 1.
 
 mouarf c'est quoi ce truc foireux avec l'éditeur : mes listes n'apparaissent plus en tant que liste (puce+saut de ligne) une fois le commentaire posté !!!
 
 PS : sympa l'image affichée quand on répond à son propre commentaire ^^
 
 [^] # Re: not /run
 
 Posté par JGO le 05 avril 2011 à 23:30. Évalué à 2.
 
 Tiens, on peut faire sudo bash !
 
 (Ou comment je vais pouvoir arrêter de piquer une crise de nerfs pour le support technique des Ubuntu des copains...)
 
 [^] # Re: not /run
 
 Posté par houra le 06 avril 2011 à 01:23. Évalué à 1.
 
 oui ya aussi
 
 sudo gnome-terminal &
 
 Sedullus dux et princeps Lemovicum occiditur
 
 [^] # Re: not /run
 
 Posté par Enoch (site web personnel) le 06 avril 2011 à 11:35. Évalué à 1.
 
 Sinon avec un sudo passwd tu peux mettre un mot de passe à root ce qui permet de faire un su classique ou de se connecter en root comme sur n'importe quel autre distrib.
 
 [^] # Re: not /run
 
 Posté par Antoine le 07 avril 2011 à 00:12. Évalué à 6.
 
 Ou sudo -s tout bêtement.
 
 [^] # Re: not /run
 
 Posté par claudex le 06 avril 2011 à 08:34. Évalué à 6.
 
 J'ai franchement jamais compris l'utilité de sudo à part laisser la possibilité à n'importe quel user de passer root facilement
 
 Tu peux ne laisser qu'une liste réduite de commandes accessible via sudo.
 
 Pour le problème de traçabilité je vois pas. Chez moi la config est ainsi : - ben .bash_history ça existe avec root hein ;) - seuls les users membre du groupe wheel peuvent passer root - connexion directe sur ssh avec root désactivé
 
 Je ne comprends toujours pas comment tu sais quel utilisateur a exécuté telle commande en root quand deux sont connectés en même temps.
 
 « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
 
 [^] # Re: not /run
 
 Posté par stopspam le 07 avril 2011 à 18:27. Évalué à 1.
 
 Je ne comprends toujours pas comment tu sais quel utilisateur a exécuté telle commande en root quand deux sont connectés en même temps.
 
 Je prend le problème à l'envers : toute commande qui a besoin d'être root pour être exécutée n'est exécutée que par root (sans sudo). Le compte root n'est utilisé que par les ADMINISTRATEURS dont c'est le métier sinon il a pas à être root.
 
 Expliques-moi à quoi te serts la traçabilité de celui qui tape les commandes root ?
 
 Tu fliques pour savoir à qui la faute si un serveur est planté ? Au travail nous sommes plusieurs à nous occuper des serveurs. On sait qui s'occupe de quoi et éventuellement quels sont ceux qui ont merdé (de toute façon on se sert les coudes). Jamais j'ai eu la problématique de savoir qui avait exécuté telle commande à la con.
 
 [^] # Re: not /run
 
 Posté par MrLapinot (site web personnel) le 05 avril 2011 à 14:15. Évalué à 6.
 
 Surtout que "sudo cd", ça ne risque pas de fonctionner...
 
 [^] # Re: not /run
 
 Posté par zebra3 le 04 avril 2011 à 15:17. Évalué à 1.
 
 Comme JGO, je n'arrive pas à imaginer faire un sudo toutes les trentes secondes. D'ailleurs le gain en sécurité me paraît assez faible si tous ces utilisateurs peuvent lancer des commandes telles que cd en root.
 
 Et puis lancer « sudo cd » ne te permet pas de rester dans le répertoire /root, puisque sudo créé un environnement qu'il ferme à la fin de la commande, il me semble ?
 Enfin, faut que j'essaie car ça me paraît assez bizarre.
 
 Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
 
 [^] # Re: not /run
 
 Posté par gnumdk (site web personnel) le 04 avril 2011 à 15:27. Évalué à 6.
 
 De toute facon, sudo cd ne peut pas fonctionner vu que cd est une commande interne à bash...
 
 [^] # Re: not /run
 
 Posté par Kerro le 04 avril 2011 à 23:06. Évalué à -1.
 
 Lorsque sudo est invoqué, il execute 'cd' qui est un programme tout à fait valide et accessible via PATH. Ce n'est certes pas le même que celui intégré à Bash, mais en principe le comportement est le même.
 
 echo est aussi une commande intégrée à Bash:
 
 $sudo echo toto toto
 
 [^] # Re: not /run
 
 Posté par Frédéric Perrin (site web personnel) le 04 avril 2011 à 23:52. Évalué à 1.
 
 Lorsque sudo est invoqué, il execute 'cd' qui est un programme tout à fait valide et accessible via PATH.
 
 Quel est ce programme ? Et comment un programme invoqué par sudo pourrait-il changer le $PWD du shell courant ?
 
 girafe:~% for p in ${path}; do ls -l ${p}/cd; done /bin/ls: impossible d'accéder à /usr/local/bin/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /usr/bin/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /bin/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /usr/local/sbin/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /usr/sbin/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /sbin/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /usr/bin/vendor_perl/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /usr/lib/perl5/vendor_perl/bin/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /usr/bin/core_perl/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /opt/qt/bin/cd: Aucun fichier ou dossier de ce type /bin/ls: impossible d'accéder à /home/fred/bin/cd: Aucun fichier ou dossier de ce type
 
 [^] # Re: not /run
 
 Posté par boq le 05 avril 2011 à 00:46. Évalué à 7.
 
 girafe:~% for p in ${path}; do ls -l ${p}/cd; done
 
 $ which cd no cd in (blah blah ...)
 
 [^] # Re: not /run
 
 Posté par gnumdk (site web personnel) le 05 avril 2011 à 08:55. Évalué à 4.
 
 "cd" est une commande interne, je sais pas quelle distrib tu utilises qui l'aurait en commande externe (comme echo sous Linux mais pas sous Unix).
 
 [^] # Re: not /run
 
 Posté par zebra3 le 05 avril 2011 à 09:00. Évalué à 4.
 
 $ which cd ~ cd: shell built-in command
 
 Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
 
 [^] # Re: not /run
 
 Posté par gnumdk (site web personnel) le 05 avril 2011 à 09:39. Évalué à 3.
 
 Donc ca ne peut pas fonctionner avec sudo, merci ;)
 
 [^] # Re: not /run
 
 Posté par shbrol le 05 avril 2011 à 10:16. Évalué à 2.
 
 D'un autre coté, si cd etait un binaire et pas une commande intégrée au shell, quel serait le résultat attendu de 'sudo cd' ?
 
 [^] # Re: not /run
 
 Posté par gnumdk (site web personnel) le 05 avril 2011 à 12:46. Évalué à 2.
 
 Aucun mais là l'idée était que déjà, il est impossible de faire executer un cd à sudo sauf en appelant sh explicitement...
 
 [^] # Re: not /run
 
 Posté par shbrol le 05 avril 2011 à 13:55. Évalué à 1.
 
 Alors je reformule la question : qu'est ce qu'on peut bien attendre comme résultat de :
 
 sudo sh -c 'cd /toto'
 
 ca me semble pas franchement utile...
 
 [^] # Re: not /run
 
 Posté par shbrol le 05 avril 2011 à 13:56. Évalué à 2.
 
 Mea culpa, j'avais pas vu que Guillaume avait déja répondu a la question plus haut...
 
 (et puis je voulais aussi voir si la BD était encore la...)
 - [^] # Re: not /run
 
 Posté par Michaël (site web personnel) le 08 avril 2011 à 02:06. Évalué à 0.
 
 Malgré mes efforts je n'arrive jamais à taper: less file, mais je tape toujours: cat file | less.
 
 Pour que ala période de transition soit moins dure, tu passer par `less < file' qui semble un bon compromis :)
# Et les autres?

Posté par claudex le 04 avril 2011 à 10:18. Évalué à 10.

Qu'en est-il des autres Unix comme les *BSD? Ne sont-ils pas concerné par des problème similaire (même si ce n'est pas udev ou systemd qui doivent leur poser problème)? Ils préfère rester compatible avec la FHS?

Sinon, est-ce que cela résoudrait le bug de systemd qui ne gère pas /usr sur une autre partition que / ?(http://cgit.freedesktop.org/systemd/commit/?id=80758717a6359cbe6048f43a17c)

« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Et les autres?
 
 Posté par mickabouille le 04 avril 2011 à 11:56. Évalué à 3.
 
 Sinon, est-ce que cela résoudrait le bug de systemd qui ne gère pas /usr sur une autre partition que /
 
 Ça marche. Non, disons que ça peut marcher. Mais ce n'est pas supporté. Ce n'est pas tout à fait la même chose. C'est un choix, il a été décidé que /usr à part ne serait plus supporté, c'est à dire qu'il n'y aurait plus d'effort de fait pour que ça marche, mais que si ça marche, c'est à dire, si l'utilisateur fait tout ce qu'il faut pour que ça marche, ben tant mieux.
 - [^] # Re: Et les autres?
 
 Posté par rewind (Mastodon) le 04 avril 2011 à 12:11. Évalué à 8.
 
 Ouais enfin, c'est quand un peu con de ne pas gérer un /usr sur une partition différente. Cette configuration est quand même la norme sur des serveurs, donc la gérer me semble être le minimum pour ne pas se foutre de la gueule des gens.
 
 D'ailleurs, on constate aussi qu'il ne gère pas un /etc/mtab qui n'est pas un lien sur /proc/self/mounts. Or sur ma Debian, ce n'est pas un lien...
 
 Il fait un logiciel pour qui ce gars ? Lui tout-seul ?
 - [^] # Re: Et les autres?
 
 Posté par Anthony Bourguignon (site web personnel) le 04 avril 2011 à 12:22. Évalué à 4.
 
 Attention à ne pas confondre. Systemd gère très bien quand /usr n'est pas chargé au boot. Il en a pas besoin. Par contre, il averti que certains processus risquent de ne pas être contents et de ne pas fonctionner (et se vautrer silencieusement). Typiquement, on a udev qui est dans ce cas (certaines règles ne seront pas exécutées correctement si /usr n'est pas chargé).
 
 Pour /etc/mtab, pareil, c'est un avertissement. Et avec les noyaux supérieurs à 2.6.26, /etc/mtab devrait de toute façon être un lien symbolique.
 
 Donc non, il ne fait pas un logiciel pour lui tout seul mais un logiciel qui permet de mettre en place des bonnes pratiques.
 - [^] # Re: Et les autres?
 
 Posté par Pierre Carrier le 04 avril 2011 à 12:24. Évalué à 2.
 
 /etc/mtab n'est pas encore un lien sur /proc/self/mounts.
 
 Tu vois un seul intérêt à les garder séparés ? Juste parce que ça n'est pas le cas sur ta Debian (ni sur la plupart des systèmes) ne veut pas dire que ça ait un sens (autre que compatibilité avec des très vieux noyaux que personne n'utilisera avec systemd étant donné qu'il utilise des systemcalls apparus récemment comme timerfd/signalfd, ou vieux systèmes de boot que personne n'utilisera avec systemd parce que... je laisse le soin au lecteur de deviner).
 
 Un des buts est de permettre d'avoir un /etc en lecture seule.
 - [^] # Re: Et les autres?
 
 Posté par rewind (Mastodon) le 04 avril 2011 à 13:58. Évalué à 2.
 
 Ma Debian serait une petite distribution sans envergure, je ne dis pas. Mais on parle là d'une des distributions les plus utilisées au niveau serveur. Alors je veux que ça ait un sens, mais je ne suis pas sûr que sa méthode pour y parvenir soit très bonne.
 
 [^] # Re: Et les autres?
 
 Posté par claudex le 04 avril 2011 à 15:12. Évalué à 3.
 
 http://wiki.debian.org/systemd#Known_Issues_and_Workarounds pourtant, c'est la méthode conseillée.
 
 « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
 
 [^] # Re: Et les autres?
 
 Posté par Pierre Carrier le 08 avril 2011 à 16:57. Évalué à 2.
 
 Que ce soit le cas actuellement ou pas sur ta distro n'a aucune importance. Ce n'est pas le cas dans Fedora non plus.
 
 Tu sais pourquoi ? Parce que ta distro n'utilise pas systemd. Quand ta distro voudra passer à systemd, elle aura beaucoup plus de boulot que simplement transformer /etc/mtab en symlink vers /proc/self/mounts. Et tu ne t'en apercevras même pas.
- [^] # Re: Et les autres?
 
 Posté par Joris Dedieu (site web personnel) le 04 avril 2011 à 12:54. Évalué à 9.
 
 Qu'en est-il des autres Unix comme les *BSD?
 
 Ils ont échappés a /sys voir même à /proc (pour les meilleurs d'entre eux :) ils échapperons bien à /run. Les autres Unix libres ne sont pas concernés parce qu'ils montent leurs fs avant de lancer des services ce qui semble être l'ordre naturel des choses.
 - [^] # Re: Et les autres?
 
 Posté par Quzqo le 04 avril 2011 à 14:27. Évalué à 5.
 
 Ne serait-ce donc pas cette démarche qu'il faudrait privilégier du côté de Linux plutôt que l'apparition d'un /run ?
 D'autant que ce qui était dans /dev/.<xxx>, soit sur un montage tmpfs, donc en mémoire, va se retrouver désormais écrit dans le système de fichiers racine avec tous les risques inhérents à ce genre de pratique (des données volatiles dans /).
 
 Tout cela ne me parait pas franchement fiable/logique, genre pansement sur une jambe de bois, et tout cela pour quoi ? gagner quelques millièmes de secondes au boot ? Rester permissif dans la gestion des dépendances des rc.d ?
 Histoire de fusionner trois FS (/dev/.<xxx>, /etc, /lib/rw) en un, on rend plus vulnérable /. Je ne vois pas où est l'intérêt.
 
 Mais quand on voit que certains que certains écrivent déjà dans /etc ou /lib/rw (données volatiles dans la configuration statique ou sous la racine), un /run en plus ne doit pas faire peur... :/
 - [^] # Re: Et les autres?
 
 Posté par Quzqo le 04 avril 2011 à 14:34. Évalué à 1.
 
 D'autant que ce qui était dans /dev/.<xxx>, soit sur un montage tmpfs, donc en mémoire, va se retrouver désormais écrit dans le système de fichiers racine avec tous les risques inhérents à ce genre de pratique (des données volatiles dans /).
 
 Il reste effectivement la possibilité, comme souligner par certains, de monter /run en mémoire (tmpfs) mais ça reste redondant avec /var/run (si on laisse de côté le problème au boot, avant montage de /var)...
 - [^] # Re: Et les autres?
 
 Posté par Frédéric Perrin (site web personnel) le 04 avril 2011 à 14:38. Évalué à 4.
 
 ça reste redondant avec /var/run
 
 C'est justement pour ça quand dans son mail, Poettering explique que /var/run sera un symlink vers /run.
 - [^] # Re: Et les autres?
 
 Posté par bubar🦥 (Mastodon) le 04 avril 2011 à 18:28. Évalué à 3.
 
 +1 à tout.
 pour /run en ramfs, encore faut il que cela soit possible... combien de programme ne sont pas contents lorsqu'il trouve un /var/run vide, alors qu'ils attendent leur arborescence dessous et ne la créeait pas si elle n'existe pas.
 Bref, avant d'utiliser /run en ram il y a quelques ajustements à faire (que j'imagine toute personne ayant un laptop fait de lui même) Et justement parmis ces programmes à problème, il y a avahi-daemon.
 - [^] # Re: Et les autres?
 
 Posté par Frédéric Perrin (site web personnel) le 04 avril 2011 à 14:53. Évalué à 8.
 
 D'autant que ce qui était dans /dev/.<xxx>, soit sur un montage tmpfs, donc en mémoire, va se retrouver désormais écrit dans le système de fichiers racine avec tous les risques inhérents à ce genre de pratique (des données volatiles dans /).
 
 C'est pour ça que dans son mail, Poettering explique que /run est un tmpfs.
 
 gagner quelques millièmes de secondes au boot ? Rester permissif dans la gestion des dépendances des rc.d ?
 
 Ni l'un ni l'autre, mais se débarrasser de dossiers /cachés/ dans /dev.
 
 Histoire de fusionner trois FS (/dev/.<xxx>, /etc, /lib/rw) en un, on rend plus vulnérable /. Je ne vois pas où est l'intérêt.
 
 Je ne vois de /lib/rw ni sous Arch, ni sous Debian que j'ai sous la main, ni dans le mail de Poettering. Je ne sais donc pas exactement à quoi tu fais référence. /run a effectivement pour but de remplacer tous les /dev/.xxx, le /lib/init/rw qui est une Debiannerie qui a le même but que le /run proposé, et les choses crades qui écrivent dans /etc (d'ailleurs, je n'ai pas d'exemple en tête de scripts au démarrage qui font ceci... tu as un coupable en tête ?).
 
 En quoi /run rend / vulnérable ?
 - [^] # Re: Et les autres?
 
 Posté par geb le 05 avril 2011 à 01:09. Évalué à 5.
 
 et les choses crades qui écrivent dans /etc (d'ailleurs, je n'ai pas d'exemple en tête de scripts au démarrage qui font ceci... tu as un coupable en tête ?).
 
 n'importe quel client dhcp: il modifiera le /etc/resolv.conf voir nsswitch (debian ne fait rien pour ça)
 
 resolvconf (idem)
 
 (liste non exhaustive)
 - [^] # Re: Et les autres?
 
 Posté par claudex le 04 avril 2011 à 15:16. Évalué à 2.
 
 gagner quelques millièmes de secondes au boot ?
 
 Tu gagnes bien plus que ça si tu as des système de fichiers sur le réseau.
 
 « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
 - [^] # Re: Et les autres?
 
 Posté par Joris Dedieu (site web personnel) le 04 avril 2011 à 16:05. Évalué à 3.
 
 Tu gagnes bien plus que ça si tu as des système de fichiers sur le réseau.
 
 Si ton système de fichier réseau contient ta racine, tu l'attendra de toute façon. S'il contient des données, il ne sert a rien de l'attendre et dans ce cas une modification du script d'init est sans doute moins intrusive.
# boot

Posté par Sytoka Modon (site web personnel) le 04 avril 2011 à 10:19. Évalué à 5.

Puisque cela concerne principalement le démarrage, on aurait pu faire un

/boot/run

Sachant que /boot est très rapidement monté...

Ensuite, /var/run et /boot/run aurait été identique.

Bref, juste une idée qui me passe par la tête pour éviter la prolifération dans /.
- [^] # Re: boot
  
  Posté par claudex le 04 avril 2011 à 10:29. Évalué à 10.
  
  Je pense que le problème, c'est qu'actuellement /boot ne nécessite aucune écriture, ce qui permet de le placer sur des périphériques spéciaux qui ne supporte pas beaucoup d'écriture. De plus, on peut monter /run en tmpfs et donc gagner du temps au démarrage (et/ou à l'extinction), et je me vois mal mettre /boot en tmpfs (mais ça pourrait être amusant).
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: boot
    
    Posté par Frédéric Massot (site web personnel) le 04 avril 2011 à 10:43. Évalué à 0.
    
    D'après Lennart Poettering /run sera un montage de type tmpfs.
  - [^] # Re: boot
    
    Posté par Sytoka Modon (site web personnel) le 04 avril 2011 à 11:15. Évalué à 2.
    
    Tu peux monter run sous /boot en tmpfs...
    
    Par contre, comme il est dis ci-dessous, on peux avoir un système sans /boot et c'est effectivement le cas de mes machines virtuelles sous Xen, il n'y a pas de /boot car pas de noyau dessus !
    - [^] # Re: boot
      
      Posté par claudex le 04 avril 2011 à 11:22. Évalué à 5.
      
      Tu peux monter run sous /boot en tmpfs...
      
      Cela risque d'être comme la situation d'Ubuntu actuellement qui monte /var/run avant /var, ce qui est loin d'être propre.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: boot
  
  Posté par HardShooter le 04 avril 2011 à 10:33. Évalué à 10.
  
  /boot n'a pas du tout besoin d'etre monté au boot alors avoir une dépendance dessus...
  - [^] # Re: boot
    
    Posté par Corentin Chary (site web personnel) le 04 avril 2011 à 10:40. Évalué à 4.
    
    Tout à fait, sur mes serveurs, /boot n'est monté que le temps d'installer un nouveau kernel :).
    - [^] # Re: boot
      
      Posté par zebra3 le 04 avril 2011 à 10:53. Évalué à 2.
      
      Tiens, c'est pas bête comme idée, faudra que je regarde pour faire de même.
      
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: boot
      
      Posté par bubar🦥 (Mastodon) le 04 avril 2011 à 18:35. Évalué à 1.
      
      Et tu colles /lib/modules dans /boot, aussi :-)
      sur ma distro courante, cela ne fonctionne pas par défaut car il y a quelques accès en écriture dans lib/modules, qu'il faut modifier.
      okok je ->
      :p
      - [^] # Re: boot
        
        Posté par Corentin Chary (site web personnel) le 04 avril 2011 à 19:18. Évalué à 3.
        
        D'une part, je ne met que rarement les drivers nécessaire au boot en module, d'autre part, je n'active que rarement les modules sur mes serveurs.
- [^] # Re: boot
  
  Posté par FRLinux (site web personnel) le 04 avril 2011 à 14:55. Évalué à -2.
  
  /var/run c'est très bien à mon avis. Pourquoi toujours vouloir rajouter des couches. Ca fait longtemps que les systèmes unix ont été faits tel quels. Je pense que /var rempli bien son rôle mais bon... Faut vivre avec son temps :)
  - [^] # Re: boot
    
    Posté par Frédéric Perrin (site web personnel) le 04 avril 2011 à 14:59. Évalué à 6.
    
    Parce que /var n'est pas disponible au boot.
  - [^] # Re: boot
    
    Posté par claudex le 04 avril 2011 à 15:29. Évalué à 5.
    
    C'est un hack immonde, c'est ce que fait ubuntu mais ils monte /var/run avant /var, ce qui veut dire que /var n'est pas utilisable alors que /var/run l'est. Ça n'a pas beaucoup de sens.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: boot
      
      Posté par nicolas le 04 avril 2011 à 16:48. Évalué à 1.
      
      Pourquoi ? Ça ne sera pas la première fois qu’on peut traverser un répertoire sans y avoir accès. Ça peut même être assez courant en fonction des droits d’accès qu’on a bien voulu nous donner.
      - [^] # Re: boot
        
        Posté par claudex le 04 avril 2011 à 19:26. Évalué à 2.
        
        Sauf qu'on parle du noyau, ça doit pas être courant.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Vraiment cassé?

Posté par Zenitram (site web personnel) le 04 avril 2011 à 10:53. Évalué à 10.

Alors, LSB/FHS outragée, LSB/FHS brisée, LSB/FHS martyrisée… crouch, touch, pause, engage !

D'après le lien vers la demande d'ajout dans FHS:
"Note that by the current standard, new top-level directories are forbidden to applications but only discouraged for distributions. So this usage does not violate the FHS."

Donc même pas de troll possible... Tout s'en va.
# La flame war a bien eu lieu

Posté par Ronan BARZIC le 04 avril 2011 à 11:28. Évalué à 2.

Cette décision est techniquement simple et simplifie la liaison entre les données liées > au démarrage et les programmes, elle a souvent été envisagée mais repoussée pour des > > raisons politiques, des craintes d'intense flameware et la rupture avec la LSB/FHS.

La flameware a bien eu lieu - La première réponse a été par un certain Ralf Corsepius qui a commencé a faire un caca nerveux :

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976

Tout ca pour se faire exploser en vol par l'auteur du mail original qui l'accuse de ne pas avoir lu le premier mail (et il a raison...):

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976

J'ai été ahuri de voir la raideur d'esprit du mec - Comme quoi, faire du libre n'est pas une garantie contre la connerie
- [^] # Re: La flame war a bien eu lieu
  
  Posté par Ronan BARZIC le 04 avril 2011 à 11:40. Évalué à 4.
  
  Correction - le second lien c'est :
  http://article.gmane.org/gmane.linux.redhat.fedora.devel/147072
- [^] # Re: La flame war a bien eu lieu
  
  Posté par bubar🦥 (Mastodon) le 04 avril 2011 à 19:32. Évalué à 5.
  
  En tout cas le fil est ... surprenant. Entre les touches d'humour, sympathique, et ceux qui répondent pas des quasi attaques ad-hominem à cet humour, et ceux qui nourrissent un truc totalement hs dans le fil, c'est ... surprenant. (et rassurant : à priori suis pas le seul à ne pas me relire ou tourner 5 fois ses doigts autour du clavier avant de cliquer sur 'envoyer' :p)
  
  Toutes ces mini discussions à l'intérieur de ce fil, et le fil lui même, font ressortir encore une fois la difficulté de prendre en compte tout les usages pour une petite modification. Or cela pourrait être en fonction de l'usage que le système fait des ajustements. Lorsqu'on install un "portable à usage personnel" on pourrait avoir des divergences automatiques plus importantes qu'actuellement lorsqu'on installe "un serveur". Et ça, bien que ces options soient proposées par l'installeur de certaines distributions, ce n'est pas fait : on a tout juste un choix de paquetages et quelques configs pam par défaut. Mais rien concernant des points pourtant importants, que j'imagine toute personne ajuste ensuite (plus de tmpfs, pour rester dans le sujet). Le "système universel" est vraiment quelque chose de difficile, et soit il reste des ajustements derrières, soit la distro les fait selon le contexte d'usage déclaré.
  - [^] # Re: La flame war a bien eu lieu
    
    Posté par Ronan BARZIC le 04 avril 2011 à 20:10. Évalué à 10.
    
    et ce qui m'a faire bien rigoler, c'est que ce soit un mec de Fedora qui vienne reprocher à un mec de RedHat d'introduire un truc nouveau - Dès fois, il faut vraimment se pincer pour être sur de ne pas réver...
  - [^] # Re: La flame war a bien eu lieu
    
    Posté par Maclag le 05 avril 2011 à 08:08. Évalué à 5.
    Ce que moi j'ai trouvé surprenant dans le fil, c'est l'impression de légèreté qui émane de l'assurance-qualité dans Fedora.
    
    OK, c'est une distro pour faire des choses expérimentales quitte à tout casser. Mais là, on soulève un problème, on insiste sur le fait que la doc paraît confuse et la réponse c'est en substance:
    "On a déjà fait des trucs dans le genre sans regarder si ça violait les procédures ou si on avait toute la doc pour le contrôle qualité, alors je vois pas pourquoi on s'embêterait ce coup-ci"
    
    Le problèmes est (ici):
    - Les consignes de Fedora sont vagues: suivre la FHS
    - la FHS stipule que les distros peuvent faire un peu ce qu'elles veulent dans / tant que c'est bien pensé
    Comme précisé, la FHS définit un minimum pour les distributions. Et Fedora n'a donc aucune spécification propre, aucun maximum défini, aucune procédure de contrôlé appliquée?
    
    Du coup, il y a un grand flou artistique sur qui peut ajouter quoi et comment dans la racine.
    
    La bonne réponse, ce serait de définir cette procédure, incluant la doc et la transition, et vérifier si les précédentes modifs "passent" les contrôles.
    
    La mauvaise réponse est "on s'en foutait avant alors on va continuer de s'en foutre".
    
    Et je suis effaré de voir autant de monde dans la liste plutôt enclins à choisir la deuxième réponse pourvu que ça aille plus vite (et vas-y que je te qualifie tout ça de "bureaucratique").
    
    On n'a pas l'impression en lisant le fil, que beaucoup de monde soit sensible au principes de contrôles qualité!
    - [^] # Re: La flame war a bien eu lieu
      
      Posté par GeneralZod le 05 avril 2011 à 08:24. Évalué à 8.
      
      Il y a bien un process QA bien bien nazi limite debiannesque dans Fedora, par contre t'as un petit groupe qu'on appelerait par exemple Redhat Desktop & friends qui se croit tout permis.
      - [^] # Re: La flame war a bien eu lieu
        
        Posté par Sytoka Modon (site web personnel) le 06 avril 2011 à 20:24. Évalué à -7.
        
        Que viens faire ce mot "nazi" ici à par pour en détourné le sens pour faire de l'humour assez nul à vrai dire.
        
        Petit rappel du nazisme ici : http://fr.wikipedia.org/wiki/Nazisme
        
        Moque toi de debian, c'est de bonne guerre mais évite de participer à l'usage de ce mot pour des choses qui n'ont rien à voir avec le nazisme.
        
        Je sais, de l'autre coté de l'atlantique, ils y en a qui se permettent... Ils sont de l'autre coté et pas en Europe et ont parfois perdus le sens de l'histoire.
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par bubar🦥 (Mastodon) le 07 avril 2011 à 01:26. Évalué à 3.
        
        on pourrait remplacer cela, en europe, par le terme "militaire" puisque la signification sous-entendu c'est "très carré + va chier si pas d'accord".
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par GeneralZod le 07 avril 2011 à 10:04. Évalué à 4.
        
        mais évite de participer à l'usage de ce mot pour des choses qui n'ont rien à voir avec le nazisme.
        
        Merci pour la leçon de morale, je sais très bien ce qu'est le nazisme.
        
        Je sais, de l'autre coté de l'atlantique, ils y en a qui se permettent... Ils sont de l'autre coté et pas en Europe et ont parfois perdus le sens de l'histoire.
        
        ou pas, la meilleure façon d'exorciser un traumatisme c'est d'en rire et d'aller de l'avant et pas de le refouler. Plus tu le refouleras, plus il reviendra en force (l'UMP le prouve brillamment depuis une dizaine d'années !).
        Je respecte tout autant que toi la mémoire des victimes, mais je ne me priverais pas du droit de tourner en ridicule les bourreaux ! On ne terrasse pas un dragon en scellant sa grotte avec du papier mâché ...
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par PachaFonk le 07 avril 2011 à 16:09. Évalué à 1.
        
        Tant qu'on reste en dehors du champ politique, faire des comparaisons avec les nazis reste "bon enfant" et anodin.
        
        Es tu vraiment en train de comparer le régime nazi et la la France en 2011 ?
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par Sytoka Modon (site web personnel) le 07 avril 2011 à 20:09. Évalué à -2.
        
        Merci pour la leçon de morale, je sais très bien ce qu'est le nazisme.
        
        Désolé, j'avais pas l'impression ;-)
        
        ou pas, la meilleure façon d'exorciser un traumatisme c'est d'en rire et d'aller de l'avant et pas de le refouler.
        
        Je sais en rire et je ne refoule pas. Ta phrase n'est pas vraiment drôle et au final, cela rend l'utilisation de ce mot banal pour tout un tas de blague nulle... On a le droit d'en rire, certes, mais pour pour moi, autant éviter la banalité et l'usage complètement HS ;-)
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par Maclag le 08 avril 2011 à 06:47. Évalué à 6.
        
        Euh, si je comprends bien, tu es d'accord pour voir des blagues utilisant le mot "nazi", à condition qu'elles soient "bonnes"?
        
        Pareil pour le commentaire plus bas. C'est une blague, c'est à prendre au second degré. Personne ici ne demande qu'on donne une deuxième chance aux nazis.
        
        Je dirais que encore une fois, on peut rire de tout, mais pas avec tout le monde...
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par Sytoka Modon (site web personnel) le 08 avril 2011 à 07:23. Évalué à -3.
        
        Il y a certain film qui sont drôle comme la grande vadrouille par exemple.
        
        Quand au second degré à n'importe quel moment et sur n'importe quoi, c'est à mon sens possible si cela ne devient pas un réflexe, une habitude et utiliser trop souvent -> banalité.
        
        Il ne faut pas non plus faire le jeu du FN. Il ne faut pas oublier les propos du père Le Pen. Il ne faut pas oublié qu'il y a un certain de personne aux FN qui ne sont pas du tout clean sur le sujet et qui ne sont pas dans le second degré (cf le candidat FN sur Grenoble aux dernières élections).
        
        Bref, le monde n'est pas tout beau tout gentils ;-)
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par claudex le 08 avril 2011 à 08:46. Évalué à 6.
        
        Il y a certain film qui sont drôle comme la grande vadrouille par exemple.
        
        La prochaine fois que je regarde un film, je t'envois un message pour savoir si je peux rire ou pas.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par Sytoka Modon (site web personnel) le 08 avril 2011 à 10:21. Évalué à -1.
        
        Très bien, je vois que tu deviens enfin raisonnable ;-)
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par zebra3 le 07 avril 2011 à 10:13. Évalué à 6.
        
        Bla bla bla... C'est marrant que c'est toujours les nazis qui ont toujours le mauvais rôle...
        
        Nous sommes en ~~1955~~ 2011, Herr ~~Bramard~~ Modon ! On peut avoir une deuxième chance ?! Merci...
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par Sytoka Modon (site web personnel) le 07 avril 2011 à 20:06. Évalué à -4.
        
        Incroyable les conneries qu'on peux lire ici !
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par zebra3 le 08 avril 2011 à 10:26. Évalué à 5.
        
        Désolé, c'était du second degré, je ne voulais pas te froisser.
        
        C'est une citation d'OSS-117, un film justement très appuyé sur le second degré, et j'ai trouvé que ça s'accordait assez bien avec le sujet.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: La flame war a bien eu lieu
        
        Posté par Sytoka Modon (site web personnel) le 08 avril 2011 à 15:35. Évalué à 1.
        
        Je trouve moi aussi les films OSS-117 très bien fait et amusant. j'avais pas fait le rapprochement. Bien joué !
      - [^] # Re: La flame war a bien eu lieu
        
        Posté par Antoine le 07 avril 2011 à 00:14. Évalué à 9.
        
        De toute façon les nazis se croient souvent tout permis, à la limite du savoir-vivre.
# Ubuntu

Posté par Amine "nh2" Brikci-Nigassa (site web personnel) le 04 avril 2011 à 11:54. Évalué à 2.

NdM : Les principales distributions impliquées sont Debian, SuSE, Ubuntu et Fedora.

Si Debian prend une telle décision, Ubuntu a-t-elle vraiment le choix ?

GNU's Not Unix / LINUX Is Not Unix Xernel
- [^] # Re: Ubuntu
  
  Posté par Spyhawk le 04 avril 2011 à 13:13. Évalué à 5.
  
  Et pourquoi pas? Aujourd'hui, Ubuntu diverge passablement de Debian, à tel point que la solution adoptée actuellement est différente de Debian (/var/run monté avant /var par un hack assez crade, alors que Debian utilise la solution du /dev/.xyz aussi "peu sexy").
  
  Un dev de chez Canonical soutient l'idée, parce qu'elle "a du sens" et qu'elle est très "unix".
  
  http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976
- [^] # Re: Ubuntu
  
  Posté par J Avd le 04 avril 2011 à 20:18. Évalué à 6.
  
  Et le systemV il met le upstart dans le papier d'alu...
  
  "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
# for i in [...] mount [...] chroot

Posté par Thomas Debesse (site web personnel) le 04 avril 2011 à 15:37. Évalué à 5.

est-ce que ce sera un répertoire de plus à monter avant de faire un chroot ?
on a déjà /proc /sys /dev /dev/pts ...

ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: for i in [...] mount [...] chroot
  
  Posté par zebra3 le 04 avril 2011 à 15:40. Évalué à 2.
  
  Plus simple : utiliser LXC.
  
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: for i in [...] mount [...] chroot
    
    Posté par Thomas Debesse (site web personnel) le 04 avril 2011 à 17:31. Évalué à 3.
    
    Chez moi le chroot c'est en général synonyme de situation de crise ou bidouille. ^ Quand on fait du LXC, le chroot est prévu et est un fonctionnement normal. Dans ce cas là la complexité est bien moins gênante que lorsqu'il s'agit de jouer les médecins et qu'on n'a pas forcément avec soi la suite d'outils kivabien.
    
    ce commentaire est sous licence cc by 4 et précédentes
  - [^] # Re: for i in [...] mount [...] chroot
    
    Posté par geb le 05 avril 2011 à 01:28. Évalué à 2.
    Plus simple : utiliser LXC.
```
chroot=truc; for x in /proc /sys /run; do mount -o bind $x $chroot/$x; done ; chroot $chroot
```
    Tu es vraiment sûr que c'est plus simple ? Et si jamais tu veux faire un conteneur leger avec juste un deamon c'est toujours plus simple ? (lxc le permet mais ne fournit aucun script-kikoolol-qui-fait-tout-pour-toi-et-te-donne-l-impression-que-c-est-simple dans ce cas).
    - [^] # Re: for i in [...] mount [...] chroot
      
      Posté par zebra3 le 05 avril 2011 à 09:15. Évalué à 1.
      
      Tu es vraiment sûr que c'est plus simple ?
      
      Dans le cas d'une crise ou de bidouille comme le décrit Thomas, ça ne me paraît pas tellement plus compliqué, non. Faut juste écrire le fichier de description du conteneur, on le fait une fois et c'est marre.
      
      Après pour le rescue, il suffit de se faire un Live CD Debian avec les outils de base dont LXC, ce qui est redoutablement simple avec Live Helper.
      
      Évidemment, tout ça se prépare, mais une fois fait en amont, il n'y a pas de boulot en plus ni d'inconvénients.
      
      Et si jamais tu veux faire un conteneur leger avec juste un deamon c'est toujours plus simple ?
      
      C'est vrai, j'ai pas trouvé comment faire. Mais la méthode actuelle (un système minimal pour faire tourner le démon) n'est en fait pas très complexe. Et ça ne demande pas de bidouille à la OpenVZ ou Vserver (pas de patch noyau, etc).
      
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: for i in [...] mount [...] chroot
        
        Posté par geb le 05 avril 2011 à 13:14. Évalué à 4.
        
        Dans le cas d'une crise ou de bidouille comme le décrit Thomas, ça ne me paraît pas tellement plus compliqué, non. Faut juste écrire le fichier de description du conteneur, on le fait une fois et c'est marre.
        
        Et configurer un bridge/nat, et et et et et...
        
        C'est vrai, j'ai pas trouvé comment faire. Mais la méthode actuelle (un système minimal pour faire tourner le démon) n'est en fait pas très complexe.
        
        C'est simple, il faut s'abstraire des outils tout fait qui masquent la complexité de la chose. Un LXC c'est juste une arborescence + quelques fichiers de conf. Si tu génère tout automatiquement ça donne l'impression d'être simple, pourtant ça l'est pas vraiment.. la preuve tu n'as pas pensé à contourner ces outils ou à regarder comment ils marchaient/ce qu'ils faisaient...
        
        Et ça ne demande pas de bidouille à la OpenVZ ou Vserver (pas de patch noyau, etc).
        
        Huhu. en l'occurrence aucun de ces 2 là ne va crasher l'hôte à cause d'un while (1) malloc(beaucoup). Tu me prêtes un shell et on essai sur tes LXC ? :)
# /dev/.*

Posté par bubar🦥 (Mastodon) le 04 avril 2011 à 18:42. Évalué à 8.

Finalement le but est de fusionner dans quelque chose de plus propre et de plus commun l'utilisation massive et pas toujours logique (selon le point de vue) de montage et/ou répertoires cachés dans des endroits pas très orthodoxes pour cela.

Bref, c'est une très bonne chose. Non ? On a plus de propreté (troll : bientôt presqu'autant que sous un vrai ninix) et plus de convergence sur des usages.

Que ça soit dans /run bah finalement on s'en fout un peu, non ? bon c'est sûr que moi ça me semblerait bien plus cohérent (propre?) d'utiliser une hierarchie sous /sys, mais bon ...
- [^] # Re: /dev/.*
 
 Posté par claudex le 04 avril 2011 à 19:28. Évalué à 5.
 
 bon c'est sûr que moi ça me semblerait bien plus cohérent (propre?) d'utiliser une hierarchie sous /sys, mais bon ...
 
 Il me semble que /sys est réservé au noyau, contrairement à /run accessible à n'importe qu'elle application.
 
 « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
 - [^] # Re: /dev/.*
 
 Posté par claudex le 04 avril 2011 à 19:28. Évalué à 3.
 
 s/qu'elle/quelle/
 
 « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
 - [^] # Re: /dev/.*
 
 Posté par bubar🦥 (Mastodon) le 04 avril 2011 à 19:40. Évalué à 2.
 
 vi, je sais. mais /proc n'est il pas en voie de dépréciation depuis longtemps ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.