Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de Maclag :
- [19/09@09:20] réflexion sur le protocole Jabber
- [15/08@13:51] voipbuster
Journal : /etc, c'est le foutoir...
Posté par Matthieu Lagouge (Jabber id, page perso, ) le 23 mars 2006Je repense à ça d'autant plus que je viens de lire l'astuce pour réinstaller sa debian, qui en fait ne garde qu'une liste de paquets.
Admettons! Si on change le matériel, quid du /etc?
On y va un fichier/répertoire à la fois, pour pas faire de bêtise?
C'est très long! Trop même pour être sûr!
D'où le principe de mon idée:
pourquoi ne pas revoir l'organisation de /etc en sections, plus "modulaires"?
- Un sous-répertoire pour ce qui concerne les choses purement - matérielles
- Un autre pour les réglages logiciels
- Pourquoi pas même distinguer les logiciels relatifs à l'administration et aux utilisateurs? (config apache séparée de celle de firefox, par exemple) voire aux interfaces réseau, etc.
Le but serait de savoir ce qu'on fait facilement quand on manipule ça:
- changement de machine pur: on vire le matériel, on garde le reste, déplacement de machine: on vire le réseau, on garde le reste, etc.
En plus, ça permettrait d'envisager des "sous-administrateurs" qui auraient accès à une partie du /etc et pas une autre, et de faciliter les backups des trucs considérés essentiels
Evidemment, ça va pas être simple (ex: xorg.conf, qui mélange allègrement la conf des polices, des drivers, etc.), mais est-ce que ça vaudrait pas le coup de se poser la question?
> Lire le journal (27 commentaires, moyenne: 4,2).
C'est peut être le bordel, mais un bordel organisé
Concrètement, qu'est-ce qui est difficilement gérable ?
La configuration "machine" (par opposition à la configuration de chaque utilisateur) se trouve rangée dans /etc, et uniquement là. Alors, à part modifier un fichier précis pour configurer quelque chose de précis ou faire une sauvegarde/un transfert de tout /etc, que faut-il faire de plus qui ne soit possible aujourd'hui ?
Pour le matériel, sauf si j'ai manqué quelque chose, en dehors de la fstab, je n'ai jamais eu de problème (changement de carte mère, de carte graphique, de carte réseau, ça fonctionne toujours).
Et pour ce qui serait d'une structuration du /etc, le problème de réinventer la roue, indépendamment du fait que ça soit justifié c'est :
- qu'il existe plusieurs bonnes solutions
- il en existe une par personne motivée pour changer les choses
- il faut faire un choix entre ces solutions
Sinon, pour faire ce que tu veux, il est tout à fait envisageable de créer une autre hiérarchie construite avec des liens hard.
Bon courage ! ;)
en meme temps .....
c'est pas parce que le système installe par défaut tous les fichers de conf dans /etc qu'il t'oblige forcément à le faire .... ou alors, mauvais système, changer de système.
De plus quand tu migre d'une machine vers une autre, il est rarement judicieux de tout copier d'une machine à une autre sans se poser de questions. Il faut savoir ce que l'on reporte d'une machine à une autre et de là tous les fichiers de conf associés.
Exemple: migration des "services" apache+php+mysql: se poser les bonnes questions sur ces services , ou sont les fichiers de conf pour les reporter, etc ....
Proposition
> Un sous-répertoire pour ce qui concerne les choses purement - matérielles
Style /etc/HKEY_LOCAL_MACHINE ey /etc/HKEY_CURRENT_CONFIG ?
> - Un autre pour les réglages logiciels
Style /etc/HKEY_LOCAL_MACHINE/Software et /etc/HKEY_CLASSES_ROOT ?
> - Pourquoi pas même distinguer les logiciels relatifs à l'administration et aux utilisateurs?
Style /etc/HKEY_USERS où chaque utilisateur aurait ses propres paramètres de configuration ?
Je crois qu'un autre système a déjà tenté cela, mais il paraît que c'est encore plus le bordel ...
-
[^]Re: Proposition
Posté par jimee (page perso, ) le 23/03/2006 à 14:23. (lien). Évalué à 10.Nan, faut arrêter...
/etc/HKEY_LOCAL_MACHINE/Software/GNU/sysvinit/Currentversion/Runlevels/0/S99halt
-
[^]Re: Proposition
-
[^]Re: Proposition
Posté par PasChauve PasOunet () le 23/03/2006 à 15:41. (lien). Évalué à 10.Je crois qu'un autre système a déjà tenté cela, mais il paraît que c'est encore plus le bordel ...
C'est pas sympa pour gconf...
etc
Tu n'es certainement pas le seul à penser qu'il est possible de mieu organiser le repertoire etc.
Pour ma part je pencherai pour une séparation de ce qui est système, serveur, applicatons.
Mais comme tu l'as indiqué il n'est pas toujours facile de classer un fichier un peu à cheval entre plusieurs catégories.
Un commentaires plus haut nous dit qu'on peut le faire, mais cela reviens à patcher systématiquement tout ce qu'on met à jour.
Pour qu'une nouvelle structure puisse être acceptée il faudrait qu'une grosse distribution engage le mouvement mais c'est une décision difficile à prendre car cela casse la compatibilité.
Repenser l'arborescence de Linux
Ce n'est pas le premier journal à remettre en cause l'arborescence traditionnelle d'Unix (utilisée sous Linux), j'avais lu il n'y a pas longtemps un journal qui se plaignait que c'était le foutoir dans /usr/bin.
Je vous rappelle donc qu'il y a des distributions qui essayent autre chose, par exemple GoboLinux:
http://www.gobolinux.org/
-
[^]Re: Repenser l'arborescence de Linux
Posté par Lawrence P. Waterhouse (page perso, ) le 24/03/2006 à 16:35. (lien). Évalué à 1.Sans parler du foutoir de /proc, mais si l'informatique était simple je serai obligé de faire boulanger et j'aime pas me lever tôt.
-
[^]Re: Repenser l'arborescence de Linux
Posté par Fabien Engels (page perso, ) le 24/03/2006 à 19:04. (lien). Évalué à 2.D'un autre coé /proc c'est obsolete, et /sys est bien mieux organisé (enfin a mon gout :p ).
-
plutôt que chercher un truc compliqué
Plutôt que chercher un truc compliqué, pourquoi ne pas avoir un dossier dans /etc/ par paquet ayant des fichiers de conf, avec à la rigueur une grosse séparation de départ, genre :
/etc/kernel
/etc/base-system
/etc/daemons
/etc/network
/etc/x-desktop
Bon, facile à dire, long à réorganiser, sans intérêt si ce n'est pas fait par une distro directement.
-
[^]Re: plutôt que chercher un truc compliqué
Posté par L () le 23/03/2006 à 16:31. (lien). Évalué à 4.Mieux : à l'heure actuelle où on vante la facilité de Linux ici et là et où tous les bureaux tente de faire abstraction du système de fichier, quel pourrait être l'intérêt de tout réorganiser un standards qui a traversé des décennies au risque de tout chambouler ?
Après tout, sous Windows, depuis son origine, les dossier WINDOWS, "Program Files" et WINDOWS/SYSTEM* sont des gros bordels et ça n'a pas l'air de déranger l'utilisateur tant qu'il peut installer/désinstaller ses applications facilement.-
[^]Re: plutôt que chercher un truc compliqué
-
-
[^]Re: plutôt que chercher un truc compliqué
Posté par Sharpshooter () le 23/03/2006 à 20:15. (lien). Évalué à 7.Moi je suis trés favorable à une arborescence comme celle-ci. Ca permettrait de s'y retrouver un peu plus facilement parce que c'est vrai que /etc au bout d'un moment c'est le bordel.
Et puis il y a bien eu une évolution de /dev alors pourquoi pas faire évoluer /etc ?
Je voterais aussi pour la création d'un répertoire ~/.etc qui permettrait de stocker tous les repértoires de config.
Chez moi :
lo@lo:~$ ls|wc -l
7
lo@lo:~$ ls -a|wc -l
101
Si on enlève les 7 répertoires, . et .. ça fait quand même 92 répertoires et fichiers cachés !-
[^]Re: plutôt que chercher un truc compliqué
Posté par pshunter () le 24/03/2006 à 09:40. (lien). Évalué à 2.Il existe déjà ~/.local qui (il me semble) est standard selon freedesktop.org (personellement j'avais pris l'habitude de me créer un répertoire ~/... donc maintenant mon ~/.local est un lien vers ...).
Ce répertoire est censé reprendre l'organisation de / (j'avais un ~/.local/share), j'y ai crée un ~/.local/bin, des points de montage pour mes systèmes de fichier FUSE ~/local/{1,2,3}mnt.
Je pense qu'il y existe aussi un ~/local/etc, sinon rien n'interdit de le créer. En tout cas je trouve ça pratique, pour installer des programmes dans son /home il suffit de faire ./configure --prefix=~/... (ou ~/.local)-
[^]Re: plutôt que chercher un truc compliqué
Posté par arno (Jabber id, ) le 24/03/2006 à 11:17. (lien). Évalué à 2.C'est la variable XDG_CONFIG_HOME qui définie l'emplacement du répertoire de conf défini par freedesktop. Il me semble qu'il est défini par défaut sur ~/.config mais rien n'empèche de le modifier.
Voir http://standards.freedesktop.org/basedir-spec/latest/ pour plus d'informations.
Malheuresement peu de logiciels utilisent encore ces variables et quand ils le font ce n'est pas forcément génial. ex ROX-Filer qui avant plaçait ses fichiers dans ~/ROX (ou un truc du genre) et qui utilise maintenant XDG_CONFIG_HOME. Résultat ses fichiers vont dans $XDG_CONFIG_HOME/rox.sourceforge.net ... Mouais :/ Et pour les autres applies que j'utilise avec Rox c'est $XDG_CONFIG_HOME/kerofin.demon.co.uk et $XDG_CONFIG_HOME/hayber.us ...
Mais oui, bien sur, c'est vachement parlant ça une addresse internet! /o\
-
-
-
[^]Re: plutôt que chercher un truc compliqué
Posté par Matthieu Lagouge (Jabber id, page perso, ) le 24/03/2006 à 01:22. (lien). Évalué à 2.Euh, en fait, c'était mon idée, désolé si je l'ai mal exprimée.
L'idée est effectivement d'avoir des sous-répertoires dans /etc suivant la catégorie de l'outil que l'on configure.
Evidemment, oui, ce serait long à faire, et je n'ai nullement les compétences nécessaires à ça.
Mon idée n'est pas d'avoir un équivalent aux bases de registres (dont je n'aime pas non plus le principe, en ce qui me concerne, c'est pire!). Mais je continue de dire que migrer la configuration d'une distribution linux peut être non trivial!
Tout le monde ne migre pas simplement le matériel ou le réseau. En ce qui me concerne, c'est le matériel (portable wifi+ethernet pour le bureau passerelle au travail différente chez moi vers un fixe avec un accès ethernet pur, avec un firewall dans la freebox). Apache ça change, la détection du réseau, ça change (vers du plus simple, mais ça change ;) ). Le matériel auto-détecté par udev, ça change, etc.
Alors oui, comme dit plus haut, il suffit de bien réfléchir, mais bien réfléchir, des fois, ça implique bien réfléchir quasiment pour chaque fichier de configuration!!
Je ne suis pas administrateur professionnel! Je dois parcourir chaque fichier et/ou répertoire pour être sûr de ne rien avoir oublié!
Comme cité, ça a été fait pour /dev, pourquoi ne pas l'envisager pour /etc? (et tant qu'on y est, effectivement un peu de standardisation des fichiers de config, et des ~/.* , ça ferait pas de mal non plus!)
Ceci n'était qu'une suggestion, je n'ai pas les moyens ni les compétences de m'attaquer à ça, et je ne veux pas critiquer mon système préféré!! Je propose ce qui me semble être une amélioration, ça s'arrête là.-
[^]Re: plutôt que chercher un truc compliqué
Posté par totof2000 () le 24/03/2006 à 08:59. (lien). Évalué à 2.Ben dans ce cas, pour te simplifier la vie coté matériel, pourquoi n'as tu pas dans ce cas fait une install de ta distrib coté matériel, poyur ensuite récupérer tes données et fichiers de conf applicatifs ? Ca t'aurait évité certains soucis non?
-
Information
99% des paquets qui utilisent autmake/autoconf, ont un repertoire de configuration dans /etc réglable, c'est donc relativement facile àfaire (oui relativement je sais....)
Pour le probleme d'un Xorg un coup de m4 (par exemple) et ca roule, enfin bon si on veut le faire c'est largement faisable, mais faut le vouloir
PS:Je cite automake/autoconf parce que c'est le plus courant, mais j'espere que ceux qui se proclament alternatives gerent aussi ca ....
Boah
L'autre jour quand mon alim' a explosé j'ai transféré mon installation Slackare de mon P4 i865 + nvidia 5700 sur un vieux Dell PowerEdge 1300 que j'avais sous la main (bi p3 550 + ATI Rage IIc) et honnêtement, j'ai juste eu à faire un gros cp -a de mes disques durs puis modifier le xorg.conf et le fstab.
Ah, et recompiler un noyau aussi (normal).
Donc à part xorg.conf, fstab et éventuellement le /etc/modules.conf, je ne vois pas trop ce qui peut être si pénible avec /etc lors d'un changement de machine ?
Je trouve qu'il est comparativement bien plus simple de changer une installation de machine avec GNU/Linux que Windows par exemple (ghoster une machine et restaurer l'image sur une autre ça le perturbe pas mal).
En une heure et demie, le temps de partitionner le raid, copier toutes les données, recompiler un noyau, et éditer la conf de base c'était prêt. Et j'avais une copie carbone de mon système d'origine, complètement opérationnelle (sauf la Rage IIc qui voulait pas passer en 1280x1024 ;) )
J'ai d'ailleurs été assez impressionné par la réactivité du système, quasi identique à celle que j'avais sur mon P4 alors que je n'ai absolument pas tweaké la configuration (cp -a power). Chapeau à Slackware et KDE.
-
[^]Re: Boah
Posté par _alex () le 23/03/2006 à 21:53. (lien). Évalué à 2.Annecdote :
- Il y a quelques années, ma BP6 (bi celeron) avait lachée.
- J'ai acheté une KT133A avec un Duron 750Mhz (oui je sais, je n'aurais pas du)
Windows 2000 redemarre : détection à tout bout de champs de nouveaux matériels, au bout 10 minutes, nouveau reboot, ca deux ou trois fois, et tout remarchait. J'ai utilise cette config pendant plusieurs mois, pas de problème.
Mais c'est vrai, qu'avec une autre config, ca eu moins de succès, tant qu'avec linux, de mes expériences, ca passe comme une lettre à la poste. (mandrake, debian).
Perso ...
Ce qui me gênes le plus, c'est les différentes syntaxes entre les fichiers de conf :
param=value
param = value (sans espace ça marche pas)
param value
ceux sous format INI
[section]
....
Entre les différents types de commentaires
#
;
ça facilites pas vraiment la vie. un projet viser à unifier tout ça, en propose des outils pour pouvoir acceder/modifier facilement les valeurs via des outils en ligne de commande : "Registry"
http://linuxfr.org/2004/08/30/17120.html
Mais je sais pas ou ça en est, et si ça sera un jour adopter.
-
[^]Re: Perso ...
Posté par Fabien Engels (page perso, ) le 23/03/2006 à 23:33. (lien). Évalué à 2.Le projet se nomme Elektra maintenant, le site : http://www.libelektra.org/Main_Page
-
[^]Re: Perso ...
Posté par med (page perso, ) le 24/03/2006 à 08:52. (lien). Évalué à 3.Il me semble d'ailleurs que KDE 4 supportera n'importe quel backend (on dit comment en français ?) pour la gestion des fichiers de configuration, tout ça se fera à coup de modules et l'administrateur aura le choix du mode de stockage, que ce soit en local ou sur le réseau. D'ailleurs le module elektra a déjà été écrit il me semble.
-
[^]Re: Perso ...
Posté par Narishma Jahar () le 25/03/2006 à 16:22. (lien). Évalué à 2.Le seul module (je suppose que tu parle de backend pour kconfig) qui a été écrit c'est celui qui utiliser les fichiers .ini standard.
Pour kde 4 les développeurs sont en train d'étendre l'API de kconfig pour qu'il puisse supporter plus de backends. Au minimum ini et ldap seront supportés, d'autres éventuellement s'il y a des codeurs pour le faire. Ils ne sont pas très chaud pour elektra par contre, je ne me rappelle plus des raisons...-
[^]Re: Perso ...
Posté par Thomas Douillard () le 26/03/2006 à 14:47. (lien). Évalué à 1.J'imagine pas les trolls si on leur propose un backend gconf ;)
-
-
-
La main et le cerveau.
Comme dit plus haut, très peu de fichiers sont modifiés par l'admin.
Sinon, je propose qu'à chaque fois que l'on modifie un fichier de conf., on conserve la trace de cette modification :
- soit maintenir une simple liste des fichiers modifiés ;
- soit bien marquer les passages modifiés dans les fichiers eux-mêmes ;
- soit garger une copie des fichiers originaux et modifiés dans /root/... ;
- soit faire du versioning (cvs, svn...) : ça permet de garder une trace des modifications et donc de récupérer des diffs très facilement.
Le but est de pouvoir repartir d'une version « distribution » de tous les fichiers de conf : seule la dizaine de fichiers modifiés est à vérifier pour l'intégration ou non dans le nouveau PC (parce que, de toute façon, les choix faits à un moment sont sûrement à refaire et qu'ils ne sont pas automatiques).
(Personnellement, je fais un peu tout ça. Reste plus qu'à trouver quelque chose de propre pour gérer les choix faits via debconf...)
Bon, évidemment, il faut y penser avant, ce n'est pas automatique (quoique : dpkg¹ se rend très bien compte lorsque l'on a modifié un fichier de conf).
¹ : je parle de ce que je connais, les autres distributions ont sûrement des outils similaires).
Cette page a été générée par Templeet en 0.1271s (dont 0.0197 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.