En migrant de mon portable de travail vers un vieux fixe chez moi, j'ai réalisé à quel point le /etc est un gros foutoir difficilement gérable proprement!
Je 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?
Journal /etc, c'est le foutoir...
23
mar.
2006
# C'est peut être le bordel, mais un bordel organisé
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 10.
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 .....
Posté par totof2000 . Évalué à 2.
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 ....
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Proposition
Posté par jimee (site web personnel) . Évalué à 10.
/etc/HKEY_LOCAL_MACHINE/Software/GNU/sysvinit/Currentversion/Runlevels/0/S99halt
[^] # Re: Proposition
Posté par totof2000 . Évalué à 10.
[^] # Re: Proposition
Posté par Prosper . Évalué à 10.
C'est pas sympa pour gconf...
# etc
Posté par naibed . Évalué à 3.
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
Posté par neriki (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 1.
[^] # Re: Repenser l'arborescence de Linux
Posté par Fabien Engels . Évalué à 2.
# plutôt que chercher un truc compliqué
Posté par Anonyme . Évalué à 2.
/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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: plutôt que chercher un truc compliqué
Posté par Gniarf . Évalué à 4.
[^] # Re: plutôt que chercher un truc compliqué
Posté par Sharpshooter . Évalué à 7.
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 . Évalué à 2.
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 fusible . Évalué à 2.
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 Maclag . Évalué à 2.
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 . Évalué à 2.
# Information
Posté par Ph Husson (site web personnel) . Évalué à 4.
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
Posté par JaguarWan . Évalué à 4.
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 . Évalué à 2.
- 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 ...
Posté par Fabien Engels . Évalué à 4.
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 . Évalué à 2.
[^] # Re: Perso ...
Posté par med . Évalué à 3.
[^] # Re: Perso ...
Posté par Narishma Jahar . Évalué à 2.
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 . Évalué à 1.
# La main et le cerveau.
Posté par Sylvain Sauvage . Évalué à 3.
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).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.