/run or not /run

52
4
avr.
2011
Linux

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 !

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

  • # not /run

    Posté par (page perso) . É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 . Évalué à 4.

      Bon ben, /Run ?
      Si c'est accepté j'veux un achtécé dizayeur.

    • [^] # Re: not /run

      Posté par (page perso) . Évalué à 6.

      Utilise autojump :)

    • [^] # Re: not /run

      Posté par . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 1.

                    Le mot de passe de qui ?

                    • [^] # Re: not /run

                      Posté par . É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 (page perso) . Évalué à 2.

                        Un fois toutes les 20 minutes d'inactivité, ça reste raisonnable non ?

                        • [^] # Re: not /run

                          Posté par . É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 . Évalué à 7.

                            C'est peut-être pour ça qu'il faut verrouiller ta session quand tu quittes ton poste...

                            • [^] # Re: not /run

                              Posté par . É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 . É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 (page perso) . É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 . É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 . Évalué à 2.

                  Quelle est la différence pour la traçabilité que HISTFILE / HISTSIZE ne règlent pas ?

                  • [^] # Re: not /run

                    Posté par . É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 (page perso) . É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 . É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 . Évalué à 0. Dernière modification le 07/04/11 à 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 . É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 . É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 . Évalué à 1.

                        oui ya aussi

                        sudo gnome-terminal &
                        

                        Sedullus dux et princeps Lemovicum occiditur

                      • [^] # Re: not /run

                        Posté par (page perso) . É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 . Évalué à 6.

                        Ou sudo -s tout bêtement.

                  • [^] # Re: not /run

                    Posté par (page perso) . É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 . É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 (page perso) . Évalué à 6.

                Surtout que "sudo cd", ça ne risque pas de fonctionner...

            • [^] # Re: not /run

              Posté par . É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 (page perso) . Évalué à 6.

                De toute facon, sudo cd ne peut pas fonctionner vu que cd est une commande interne à bash...

                • [^] # Re: not /run

                  Posté par (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 3.

                      Donc ca ne peut pas fonctionner avec sudo, merci ;)

                      • [^] # Re: not /run

                        Posté par . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 0.

        D'après Lennart Poettering /run sera un montage de type tmpfs.

      • [^] # Re: boot

        Posté par (page perso) . É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 (page perso) . É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 . Évalué à 10.

      /boot n'a pas du tout besoin d'etre monté au boot alors avoir une dépendance dessus...

      • [^] # Re: boot

        Posté par (page perso) . Évalué à 4.

        Tout à fait, sur mes serveurs, /boot n'est monté que le temps d'installer un nouveau kernel :).

        • [^] # Re: boot

          Posté par . É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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 6.

        Parce que /var n'est pas disponible au boot.

      • [^] # Re: boot

        Posté par (page perso) . É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 . É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 (page perso) . É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 (page perso) . É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 . É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 . Évalué à 4.

    • [^] # Re: La flame war a bien eu lieu

      Posté par . É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 . É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 . É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 . É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 (page perso) . É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 . É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 . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . Évalué à -4.

                Incroyable les conneries qu'on peux lire ici !

                • [^] # Re: La flame war a bien eu lieu

                  Posté par . É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 . Évalué à 9.

            De toute façon les nazis se croient souvent tout permis, à la limite du savoir-vivre.

  • # Ubuntu

    Posté par (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 . É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 . É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 . Évalué à 8.

    Finalement le but est de fusionner dans quelque chose de plus propre et de plus commun l'utilisation massive et <i>pas toujours logique</i> (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é (<i>troll : bientôt presqu'autant que sous un vrai ninix</i>) 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 <i>moi</i> ça me semblerait bien plus cohérent (propre?) d'utiliser une hierarchie sous /sys, mais bon ...

    • [^] # Re: /dev/.*

      Posté par (page perso) . Évalué à 5.

      bon c'est sûr que <i>moi</i> ç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 (page perso) . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.