Journal Réflexion sur les fichiers de conf.

Posté par  (site web personnel) .
Étiquettes : aucune
0
1
fév.
2006
Je viens de mettre à jour mon kde en version 3.5.1 sous debian, et lors de la mise à jour, on me demande si je veux ecraser/garder ma version du fichier kdmrc.
Je trouve ça pas terrible, je vais devoir tout reconfigurer, faut de temps pour pouvoir analyser les (nombreuses) différences.

J'imaginais une solution basée sur deux fichiers de conf.
Dans mon exemple pour kdm, nous aurions un fichier (par exemple)
/etc/kde3/kdm/kdmrc.default, qui ne serait pas modifié par l'utilisateur (enfin root dans ce cas), et mis à jour à chaque fois que nécessaire
et
/etc/kde3/kdm/kdmrc qui lui ne contiendrait que les différences apportées par l'utilisateur

Le principe pour l'appli serait de lire les cles du kdmrc.default, puis ensuite le kdmrc "utilisateur" et ecraser les cles du premier par celles qu'il y trouve.

Exemple :
[kdmrc.default] : AutoLoginEnable=false
[kdmrc] : AutoLoginEnable=true

Mon idée est-elle farfelue, est-ce que je réinvente la roue, est-ce que j'ai raté le truc gros comme une maison qui fait déjà tout ça ?
Ou alors est-ce une bonne idée et on me sort le "propose un patch"... (si c du C ou un dérivé, oubliez....)

  • # Idée

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

    Ce que je fais quand debian me demande de choisir entre les deux versions d'un fichier de config: avant de répondre je fais une copie de fichier actuel et je choisi de garder la version du mainteneur. Ainsi, j'ai ensuite les deux fichiers et je peux faire un diff plus tard et choisir d'éditer à la main ou de vraiment n'en garder qu'un.

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: Idée

      Posté par  . Évalué à 3.

      Tu peux aussi choisir de faire un diff au prompt debconf (avec D il me semble).

    • [^] # De la galère des mises à jour...

      Posté par  . Évalué à 3.

      C'est plutôt bien que Debian demande quoi faire en cas d'écrasement de fichier de conf lors d'une mise à jour... Mais reconnaissons-le, ce serait encore mieux si la mise à jour pouvait effectuer toute seule le diff et (au moins) proposer de merger l'ancien fichier de configuration personnalisé par l'utilisateur avec le nouveau contenant de nouvelles instructions.

      Parceque pour un utilisateur relativement avancé, pas de problème : On va faire une manipulation telle que celle que tu proposes pour avoir exactement le comportement que l'on souhaite malgré le fait que la mise à jour ne la propose pas. Mais quid de l'utilisateur lambda qui a déjà du mal avec l'utilisation de base du système ? Il a le choix entre garder son ancien fichier, ce qui peut entrainer des bugs gênants, ou l'écraser avec le nouveau et perdre sa configuration. Ce n'est quand même pas réjouissant comme choix...

      En tout cas merci à Twidi pour son retour. C'est justement un des points qui me faisait hésiter à mettre à jour pour l'instant (Je supposais un écrasement plus ou moins brutal de tout ou partie de la config dans la manoeuvre).

      Ce serait si dur que ca de faire des diffs sur les fichiers de config et les appliquer lors de la mise à jour ? Qu'en pensez-vous ?

      • [^] # Re: De la galère des mises à jour...

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

        Debian propose déjà cela lors de la mise à jour, mais le gros problèmes avec (par exemple) le fichier kdmrc, c'est qu'il peut-être écrit par le "Centre de configuration Kde", et tu risques donc de te retrouver avec un fichier ayant les même valeurs, mais à des endroits totalement différents. Dans ce cas, ton diff ne te servira quasiment à rien. Cela explique aussi en partie pourquoi il n'est pas forcément possible de couper le fichier en deux, comme le suggère le journal.

        Si vous voulez troller sur l'utilité de la configuration graphique qui pète les fichiers de conf, c'est maintenant ;-).

        • [^] # Re: De la galère des mises à jour...

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

          Ma solution impliquerait bien évidement de la rigueur dans la modification du fichier de conf par les applications.

          Elles ne devraient écrire dans le fichier "utilisateur" que les valeurs différentes de celles du fichier ".default".

          Le mieux pour éviter que différentes applis gèrent les choses n'importe comment, seraient de faire un mini-programme pour écrire dans la conf (mais qui ne serait pas obligatoire pour l'utilisateur désirant modifier son script à la main).

          Du style kdm-conf --set "AutoLoginEnabled=true", le programme se chargeant du travail...

          • [^] # Re: De la galère des mises à jour...

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

            Ca existe déjà ce petit programme. Autant pour KDE que pour Gnome. Je suis pas chez moi donc je sais plus les noms.

            L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

            • [^] # Re: De la galère des mises à jour...

              Posté par  . Évalué à 2.

              gconftool-2 pour gnome, si je ne m'abuse. C'est vrai que des trucs comme gconf permettent une gestion "atomique" des paramètres (que j'évoque dans un post plus bas), au lien d'une gestion atomique des fichiers de conf.

            • [^] # Re: De la galère des mises à jour...

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

              Ce serait pas ccp ?

              J'ai découvers ça dans la cooker mandriva, ce programme a l'air de faire de diff des fichiers de configuration pour gérer les problèmes de migration que vous avez évoqué.

              Bon,sinon j'ai tendance a laisse ma mandriva renommer l'ancien fichier en .rpmsave et si je vois des changements notables je vais regarder ce qu'un diff me donne dessus ;)

              Dans tous les cas, lors du changement de version majeure, mieux vaut refaire un nouveau profile, ça évite les bugs stupides dûs a ces changements...

      • [^] # Re: De la galère des mises à jour...

        Posté par  . Évalué à 4.

        Mais reconnaissons-le, ce serait encore mieux si la mise à jour pouvait effectuer toute seule le diff et (au moins) proposer de merger l'ancien fichier de configuration personnalisé par l'utilisateur avec le nouveau contenant de nouvelles instructions.

        Ca n'est pas évident du tout à réaliser. Certaines valeurs d'options qui étaient valables sur l'ancienne version ne sont peut être plus valides sur la nouvelle et riquent de faire planter le logiciel. Ca m'est déjà arrivé avec Kdm justement (du coup plus moyen de se loguer dans Kde). Et ça Dpkg ne peut pas le deviner. J'ai l'impression que le seul programme à pouvoir mettre à jour un fichier de conf... c'est tout simplement celui qui l'utilise. Dans un monde parfait, chaque programme devrait migrer lui même ses fichiers de conf. On ne peut pas attendre d'un gestionnaire de package qu'il comprenne les whatmille format de fichiers de conf (conf Xorg, Apache, fichier xml) et merge tout ça tout seul.

    • [^] # Re: Idée

      Posté par  . Évalué à 5.

      C'est pas que j'aie l'impression que tu te fatigues pour rien, mais il me semble que dpkg fait tout seul un backup du fichier qui ne sera pas utilisé.
      Du coup on se retrouve avec un fichier_de_conf.dpkg-old si on a choisi d'installer la version du mainteneur, ou un fichier_de_conf.dpkg-new si on a gardé sa version modifiée.

      • [^] # Re: Idée

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Oui, moi aussi je croyais à ça. Et un jour, sur une upgrade, pffut!, pas de backup! Alors depuis, je le fais moi.

        La gelée de coings est une chose à ne pas avaler de travers.

  • # Glop

    Posté par  . Évalué à 3.

    Ce problème est exactement le même problème que la spécification d'une API.

    Aussi bien pensée soit-elle, une API est toujours amenée à évoluer.

    Dans ton cas, imagine que quelqu'un chez kde décide que XML, c'est la voie et que tous les fichiers de configuration doivent migrer vers du XML. Comment tu gères la transition ? Faut-il garder l'ancien analyseur syntaxique pour supporter les fichiers de configuration de kde 0.00001 pre alpha ?

    On peut essayer de faire des scripts qui aident mais on ne pourra jamais avoir quelque chose de parfait.

    • [^] # Re: Glop

      Posté par  . Évalué à 5.

      Il y a au moins un truc à faire à mon avis : pouvoir gérer de manière atomique une option.

      Je m'explique : Debian, par exemple, propose : de garder l'ancien fichier / d'écraser l'ancien fichier / de regarder le diff et de se démerder par soi même.

      Garder l'ancien fichier, surtout si on connait pas bien l'appli, on se dit "merde, et si dans le nouveau je rate un truc super ?"

      L'écraser : on perd ses config mitonnées avec amour, et temps

      Merger à la mimine : pas forcément le temps, autre chose à faire, devoir tout réapprendre si on connait pas bien le fichier, si on l'a fait il y a longtemps, ...

      Ce que j'aimerai : un truc qui garde automatiquement les options que j'ai modifié, qui met à jour tout seul les "deprecated", qui vire les options que j'ai modifié, qui suggère une meilleure option, qui met un truc par défaut pour les nouvelles options ... (là je met l'idéal, remplir les premiers trucs serait pas un mal déja)

      En gros, un système qui garde l'historique de ce qui a été fait, non pas sur le fichier en entier (actuellement c'est juste "le fichier a été modifié, ou pas"). En gros, passer d'une gestion de fichiers de configuration à une gestion plus fine de la configuration/ des options elles mêmes.

      Alors ok, certains fichiers ne s'y prêtent pas, on à besoin d'un véritable système de gestion de configuration/d'options, En plus, ça donne du boulot au mainteneur du paquet/aux développeurs de l'appli, mais ça me simplifierait la vie, dans l'idéal ou le système fonctionne bien.

      • [^] # Re: Glop

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

        Et si il pouvait faire le café, ça serai parfait :). Le problème d'un système tout automatique, c'est, je pense, qu'il se planterait régulièrement(c'est quasi-inévitable je pense). Il faudrai de toute façon repasser derrière pour corriger. Je pense qu'il faudrait alors faire une croix sur la possibilité de mettre son édition à jour une fois tout les 10 ans(par exemple à chaque fois qu'une debian stable sort), car les différences seraient trop importantes. D'autant plus si les fichiers de confs changent radicalement de têtes(passage au xml, fichier éclaté en plusieurs fichiers, ...). Pour le kidam de base, il me semble qu'a chaque version de mandriva, il est recommandé de refaire une installation toute propre. Sinon, ils doivent aussi mettre les mains dans le cambouis apparemment. Les raisons que j'avais compris sont autres, mais ça montre que l'update tout automatique reste assez utopique. Même de l'autre coté de la frontière, ceux qui font tout mieux que tout le monde, et qui arrive à vendre plus chère tout en coûtant moins chère que les autres(tm), les mises à jours effectuées d'une version vers une version supérieur sont assez bancales, et en général les gens reformat. Bon, me direz-vous, ils sont pas à un formatage prêt :d.

    • [^] # Re: Glop

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

      Imaginons des clés spéciales dans le .default qui serviraient justement à ça.
      Par exemple une clé pour lister les clés obsolètes, une pour indiquer si le fichier ne peut être gardé tel quel et doit être réécrit (ce serait le cas le "pire" qui reviendrait à la situation actuelle).
      Tu vois toi le cas extrème où il faudrait faire ce qu'on doit faire aujourd'hui à chaque fois. Je pense qu'avec cette idée (que quelqu'un d'autre a certainement eu avant moi) cela pourrait rendre les choses plus faciles.

      Le cas de l'utilisateur "de base" est un bon exemple dans le cas de kdm.. imaginons qu'il est tout personnalisé via l'interface graphique (comme je l'ai fait), et paf, lors de la mise à jour (automatique par exemple), il perd toute sa config kdm... de quoi dérouter voire énerver.

      Quant au diff automatique c'est relativement dangereux. Comment il gère le cas où toi tu as mis "AutoLoginEnabled=true" et que dans le fichier il y a "AutoLoginEnabled=false" ?
      Bon admettons qu'il ignore la ligne et ne l'écrase pas, je pense qu'il ne s'en sort pas si par exemple toi tu as viré tous les commentaires et que la conf par défaut veut les remettre, voire même si tu as simplement changé l'ordre des entrées.

  • # Troll

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

    C'est mieux géré sous Gentoo :

    http://gentoo-wiki.com/HOWTO_etc-update
    http://gentoo-wiki.com/TIP_dispatch-conf
    http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml?part=(...)

    Il me semble aussi avoir lu quelque part, mais google ne veux pas me dire où, qu'il est possible d'utiliser CVS pour gérer ses fichiers de configuration.

    • [^] # Re: Troll

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

      Oui gentoo dispose de deux outils très pratiques pour "merger" (fusionner en français), des fichiers de configuration.
      Celà permet donc aisément de passer d'une configuration à une autre sans devoir complètement reconfigurer une application.
      etc-update l'outils par défaut, et dispatch-conf qui permet en plus de garder des copies des anciennes versions à la méthode CVS, dans une base de donnée.

      Mais je reste persuadé que celà peut encore être amélioré :-)

      • [^] # Re: Troll

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

        C'est très bien géré sous FreeBSD et NetBSD, tout ce qui est fusion de fichiers de conf, mise à jour...

        C'est pas la mort.

        Et le coup du fichier.conf et du fichier.conf.defaut, c'est aussi réinventer la roue (devinez vers quels OS je lorgne)

  • # il y a mieux

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

    Il existe ccp (Common Configuration Parser) qui lit les fichiers de configuration et fait la mise à jour. Je crois savoir que ccp sera utilisé dans la prochaine Mandriva lors de la mise à jour des paquets. Pour plus de détails :
    http://ccp.nongnu.org/

    ça doit fonctionner pour les fichiers de conf de n'importe quel application, KDE, Gnome, Apache, SSH...

    • [^] # Re: il y a mieux

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

      Arf, je vient de faire un doublon sans le savoir :'(

      Enfin, content de pas m'être trompé, ccp a l'air intéressant

      Y a plus qu'a tester maintenant...

      J'ai pas eu de pb lors de la migration, reste plus qu'a espérer que toutes les distributions suivent cette initiative.

      Avec un peu de chance, ça passera sûrement dans la prochaine LSB et tous les projets en profiterons...

  • # rpmdrake

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

    rpmdrake au moins il fait un diff entre les 2 fichiers et nous demande si on veut fusionner / écraser ou conserver.

    Et au pire, des fichiers .rpmsave ou .rpmnews sont créés si on passe par par rpmdrake mais par urpmi (ou rpm direct)

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: rpmdrake

      Posté par  . Évalué à 1.

      J'ai déjà eu ce viiieux doute devant la console... aïe! on sait jamais quoi répondre, et puis on a pas envie de tout décortiquer... et la viens ma question (je sais pas si vous vous êtes aussi posé la question) "ppfff est-ce vraiment gênant...?".

      Pour moi le vrai problème, c'est est-ce que mon ancien fichier ne va faire planter la nouvelle version! Pour les nouvelles fonctionnalités, ou elles m'interressent vraiment, et la je vais bien vite m'en rendre compte, ou elles ne sont pas vitale et puis tant pis! on a fait sans après tout!

      Donc l'automatisation j'suis pas pour, mais la balise " aucune garantie avec version x.x.x et précédente" ou " incompatible avec ..." serait plus raisonnable.
      Après c'est du boulot de plus pour les mainteneurs/ testeurs de paquets j'imagine... :/

      Rien de tel qu'une mise à jour qui foire pour me mettre en pétard :D béta testeur c pas ma tasse de thé! :)

  • # Une idée

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

    Une idée qui vaut ce qu'elle vaut:
    conserver le fichier de conf original de la version n (kdm.conf-3.5 par exemple), et à l'installation de la version n+1, faire un diff entre le nouveau et l'ancien.

    La plupart du temps, lors d'une mise à jour, le fichier de conf change très peu, donc:
    - s'il n'y a pas de différence entre kdm.conf-3.5 et kdm.conf-3.5.1, on conserve l'ancien fichier (éventuellement modifié par l'utilisateur) sans poser de question.
    - si les différences sont communes avec kdm.conf et kdm.conf-3.5, merger sans poser de question (si diff kdm.conf-3.5.1 kdm.conf et diff kdm.conf-3.5.1 kdm.conf-3.5 donnent la même chose).

    Dans les autres cas, ça devient un peu plus compliqué, mais je pense qu'il est possible de s'en tirer avec diff3.

    Mais ça suppose que les mainteneurs soient assez rigoureux quand ils changent les fichiers de conf (j'ai déjà vu des diff longs comme les bras entre l'ancien et le nouveau, alors que seules 2 valeurs avaient changé... mais l'ordre avait été complètement modifié).

    Voilivoilou

    • [^] # Re: Une idée

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

      j'ai déjà vu des diff longs comme les bras entre l'ancien et le nouveau, alors que seules 2 valeurs avaient changé... mais l'ordre avait été complètement modifié


      c'était le cas justement pour ce kdmrc

  • # Troll

    Posté par  . Évalué à 0.

    Sous GNOME avec GConf ça existe déjà

    • [^] # Re: Troll

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

      Pour les applis gnome (que j'ai quitté pour kde il y a peu après de longues années). et pour les autres ? (oui je marche dedans, je sais)

      donc bon, mon "idée" (qui ne semble pas intéresser grand monde à mon grand désespoir) n'est pas liée à un soft, ou un desktop en particulier, mais à n'importe quel soft avec un fichier de conf...

  • # .tail / .local

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

    J'imaginais une solution basée sur deux fichiers de conf.
    Nous aurions un fichier qui ne serait pas modifié par l'utilisateur et mis à jour à chaque fois que nécessaire et [un autre] qui lui ne contiendrait que les différences apportées par l'utilisateur

    Le principe pour l'appli serait de lire les cles du kdmrc.default, puis ensuite le kdmrc "utilisateur" et ecraser les cles du premier par celles qu'il y trouve.

    Mon idée est-elle farfelue, est-ce que je réinvente la roue, est-ce que j'ai raté le truc gros comme une maison qui fait déjà tout ça ?


    En fait ça existe déjà chez OpenBSD.

    Il y a les fichier rc / rc.conf et rc.local / rc.conf.local. Les premiers sont livrés avec la distribs et ne devraient pas être édités, les seconds écrasent les valeurs des premiers.

    Pareil il y a les resolv.conf.tail et motd.tail qui sont virtuellement des fins de fichiers pour resolv.conf et motd (qui eux sont écrasés). Le resolv.conf je crois que c'est pour le DHCP et le motd ça doit être parce que bon, faut vraiment utiliser sendbug pour envoyer un bug...

    • [^] # Re: .tail / .local

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

      En même temps, chez OpenBSD, la mise à jour, c'est aussi "voici l'archive avec le nouveau /etc, décompressez là dans /tmp et démerdez-vous pour le merge"... Au moins ça force à voir ce qui a changé ;-)

Suivre le flux des commentaires

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