Journal Lennart Poettering et les fichiers de configuration

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
49
21
avr.
2011

Après pulseaudio, après avahi, après systemd, après le répertoire /run voilà que Lennart Poettering frappe à nouveau et propose de chambouler l'organisation de nos systèmes GNU/Linux.

Dans un post sur son blog Lennart vient d'annoncer une refonte des fichiers de configuration. Selon lui la transition vers un système d'init moderne comme systemd est l'occasion d'en finir avec la fragmentation (aka le bordel) qui règne entre les différentes distributions.

Voici son résumé de la situation actuelle des fichiers de configuration et des saletés qu'il a été obligé d'inclure dans le code de systemd pour pouvoir supporter les choix divergents des distributions:

Certains d'entre eux sont bien standardisés entre les distributions et donc le fait de les supporter dans notre implémentation en C a été facile et évident. Par exemple on peut citer /etc/fstab, /etc/crypttab ou encore /etc/sysctl.conf.

Cependant, pour d'autres fichiers de configuration, il n'existe aucune standardisation ce qui nous a forcé à introduire une orgie de #ifdef dans notre source afin de pouvoir interagir avec les différents emplacements utilisés par les distributions.
Pour améliorer la situation et pour bénéficier de force unificatrice qu'est systemd nous avons donc décidé que le support différencié des fichiers de configuration serait uniquement une solution de secours et que, par défaut, nous introduirions de nouveaux fichiers de configuration chaque fois que ce sera la meilleure solution.

Lennart cite ensuite plusieurs exemples de fichiers de configuration qui sont stockés de façon différente sur les multiples distros et il indique quelle est la solution retenue par les développeurs de systemd.

Par exemple le fichier host name est stocké sous /etc/sysconfig/network dans Fedora et sous /etc/HOSTNAME pour OpenSUSE. Il a été décidé de standardiser tout ça en s'alignant sur le système Debian en utilisant /etc/hostname.

La locale utilisée par le système sera dans /etc/locale.conf tandis que l'identification du système d'exploitation est standardisé dans /etc/os-release (plus besoin de /etc/fedora-release ou de /etc/debian_version…regardez sur cette page la pagaille qui règne actuellement !).

Bien entendu Lennart annonce que ces emplacements standardisés ne lui ont pas été dictés par l'archange Gabriel et que tout ceci été discuté entre les différents responsables des distros (all of these files were discussed in one way or another with various folks from the various distributions).

Encore plus important, il dit clairement dans son post que la solution de fallback pour lire les anciens emplacements de fichiers a vocation a disparaitre:

De façon a pousser gentiment tout le monde a standardiser autour de ces fichiers nous voulons rendre clair que, tôt ou tard, nous allons supprimer le support des vieux fichiers de configuration dans systemd. Cela signifie que l'adoption de cette nouvelle organisation peut se faire lentement, petit à petit, mais que le but final de n'avoir qu'un seul schéma de configuration doit être clair.

Etant donné que systemd semble bien parti pour remplacer sysvinit sur nos systèmes il y a des chances pour que cet effort de standardisation proposé par Lennart et ses acolytes soit lui aussi bien accueilli. Certes la transition sera longue et il y aura sans nul doute des récalcitrants mais personne ne peut nier que cette unification représente un progrès.

Lennart nous demande donc a tous de l'aider à faire avancer cette transition:

help us standardizing Linux! Use the new configuration files! Adopt them upstream, adopt them downstream, adopt them all across the distributions!

On pense ce qu'on voudra de Lennart Poettering, de son code et de ses provocations, mais il ne fait aucun doute qu'il aura eu une influence énorme sur la façon dont nous utilisons tous nos systèmes GNU/Linux.

  • # Fichiers de configuration du système

    Posté par  (site web personnel) . Évalué à 10.

    J'ai eu une belle frayeur en listant le début de cet article, qui donne l'impression qu'il veut tout casser dans ''/etc''. Il n'en est rien, il s'agit des fichiers de configuration liés à l'utilisation du système de base, pas de ceux des logiciels qu'on fait tourner dessus.

    Donc, nom d'hôte, paramètres de comportement du noyau (sysctl) et langue. Mais certainement pas configuration de Postfix et compagnie, ça ne le regarde pas.

  • # et LFS?

    Posté par  . Évalué à 2.

    Et LFS ? c'est pas son rôle de gérer ce merdier et d'imposer des normes ?

    En tout cas, c'est une bonne nouvelle.

    • [^] # Re: et LFS?

      Posté par  . Évalué à 2.

      FHS pas LFS, désolé de la miss take

      • [^] # Re: et LFS?

        Posté par  (site web personnel) . Évalué à 4.

        Il en parle à propos du choix de /etc/os-release :

        The LSB tried to standardize something like this with the lsb_release tool, but quite frankly the idea of employing a shell script in this is not the best choice the LSB folks ever made. To rectify this we just decided to generalize this, so that everybody can use the same file here.

    • [^] # Re: et LFS?

      Posté par  (site web personnel) . Évalué à 7.

      LSB : Linux standard base. À ne pas confondre avec LFS, Linux from scratch, et LSD, Lysergesäurediethylamid.

      • [^] # Re: et LFS?

        Posté par  . Évalué à 2.

        Heu... LSD, c'est pas Lucy in the Sky with Diamond ? On m'aurais menti?

    • [^] # Re: et LFS?

      Posté par  (Mastodon) . Évalué à 5.

      C'est ce qui est (me semble) intéressant ici, très justement :
      La démarche propose une spec, une direction, qui a déjà été discutée par des développeurs, et qui a été crée de manière concertée. Ensuite ils demandent aux autres de bien vouloir se pencher sur la question.

      Bref au lieu qu'il s'agisse d'une haute instance (LSB) ou d'un dictateuràvie (MS) qui impose une vision, là, on un process décidé et validé par les premiers concernés : les développeurs.

      • [^] # Re: et LFS?

        Posté par  (site web personnel) . Évalué à 10.

        "les premiers concernés : les développeurs."

        Les premiers en ordre chronologique... parce qu'en nombre de personne, on doit avoir bien plus d'administrateurs systèmes.

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # Pour légèrement digresser

    Posté par  . Évalué à 5.

    Dans le même ordre d'idée, ça serait peut-être bien d'avoir quelque chose comme un répertoire "/home/utilisateur_untel/etc". Je trouve que les fichiers de configurations personnels sont vraiment dispersés en bordel, je les aimerais bien regroupés. D'autant plus que ce sont bien en pratique des fichiers de type "editable text configuration".
    Mes 0,2€ ...

  • # DANGER!

    Posté par  . Évalué à 3.

    Encore de la standardisation?

    Mais que fait Riguidel?!?

    • [^] # Re: DANGER!

      Posté par  . Évalué à 3.

      Il va bosser sur l'optimalité avec Militello.

  • # miguel de icaza sort de ce corps

    Posté par  (site web personnel) . Évalué à 5.

    Cependant, pour d'autres fichiers de configuration, il n'existe aucune standardisation ce qui nous a forcé à introduire une orgie de #ifdef dans notre source afin de pouvoir interagir avec les différents emplacements utilisés par les distributions.

    Faire un fichier de configuration n'était pas envisageable ?

    Je n'ai rien contre l'évolution et la standardisation attention. Mais ici le prétexte est clairement fallacieux.

    Mes deux cents
    Joris

  • # il pourrait d'abord finir un truc

    Posté par  . Évalué à 10.

    Visiblement il aime bien lancer des trolls et tous casser mais personnellement j'aimerai bien qu'il finisse un projet quelconque avant de se lancer dans la destruction d'une autre partie de linux.

    • pulseaudio pas fini, dernier truc en date chez moi, le microphone soit disant qui fonctionne mais dont aucun logiciel n'arrive a prendre le control. Alors je vais etre honnete c'est pratique pour connecter avec le receveur bluetooth de ma chaine. Mais bon avoir un truc aussi complique pour faire seulement cela cela me laisse dubitatif. J'ai un peu l'impression que l'on utiliser une bombe atomique lorsque un marteau aurait suffit.
    • avahi ca marche mais il faut mettre les mains dans le cambouis (fichier de configuration a la mano). Et j'ai un peu l'impression que sous mac zeroconf a plus de services disponible.
    • systemd c'est tout nouveau donc bon attendons de voir ce que cela donne.
    • /run c'est encore un tout nouveau projet

    • [^] # Re: il pourrait d'abord finir un truc

      Posté par  (Mastodon) . Évalué à 5.

      PulseAduoi, ça fait bien longtemps que je m'en suis débarrassé. Terminé, rouasse. Au début râlante de voir un truc nouveau débarqué, en moins bien que l'existant. Ensuite, ferme de gueule parceque faut voir l'évolution vu que tout le monde ça ne peut pas être mauvais. Patience. Aujourd'hui ? à part me poser des soucis, je n'en vois pas l'intérêt. (quant des besoins de jongler avec des cables audio virtuels sont présents : jack) Sinon c'est : ALSA only, et tout fonctionne très bien comme cela.

    • [^] # Re: il pourrait d'abord finir un truc

      Posté par  . Évalué à 1.

      Je n'ai pas de problèmes avec PulseAudio ni avec Avahi (au fait tu as des problèmes ou c'est juste que tu penses que tu as moins de services que sous MasOSX ?).

      Pas de problèmes avec systemd depuis 3 semaines que je l'utilise.

      Bref, ton attaque envers Lennart, c'est juste pour te calmer ? Comme d'habitude quoi...

      • [^] # Re: il pourrait d'abord finir un truc

        Posté par  . Évalué à 1.

        PA j'ai des problemes avec comme decrit au dessus avc plusieurs distribs differentes. Ca fait des annees que l'on se coltine se truc et si c'est si difficile a installer que meme 2 ou 3 distributions (toutes sauf RH/fedora quoi) n'arrive pas a faire en sorte que le branchement d'un microphone fonctionne c'est que l'outil est mal foutu/trop complexe/fait n'importe comment.

        Avahi ca fonctionne pour les deux trucs que j'ai cite mais d'apres ce que me dise les collegues utilisant MacOSX, ils s'en servent aussi pour connecter deux ordis ensemble et en particulier servir de bornes wifi (en gros cela manage aussi les reseaux ad-hoc simplement et ca j'attend encore de voir cela sous linux). Et comme je l'ai dit pour le configurer il faut copier a la mano des fichiers dans /etc/avahi/services et ca c'est tout sauf user friendly (debian et ubuntu au minimum).

        • [^] # Re: il pourrait d'abord finir un truc

          Posté par  (site web personnel) . Évalué à 5.

          Sur mandriva (on rigole pas.), j'ai rien de pariculier à faire:
          % ls /etc/avahi/services
          openssh.service proftpd.service sftp-ssh.service udisks.service
          %
          Enfin ça parait logique, il suffit que le package du serveur en question crée un fichier là..

Suivre le flux des commentaires

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