La réponse courte à votre question est Oui .
Je n'hésiterais pas à recommander Git (ou tout autre logiciel de contrôle de version) pour garder une trace des fichiers de configuration. Depuis, je suis plus productif (en particulier pour la configuration de nouvelles installations) et j'ai une plus grande confiance dans mes fichiers de configuration. Avec le contrôle de version, j'ai un enregistrement de quoi des modifications ont été apportées et le message de validation fournit la raison pourquoi le changement a été effectué. Si un changement a des effets secondaires imprévus, je peux facilement consulter le journal/l'historique pour voir quel changement a causé les effets.
Personnellement, je me méfierais du suivi de tous les fichiers sous le / répertoire racine. La liste des chemins à ignorer pourrait devenir longue et peu maniable. Je préfère conserver chaque ensemble logique de fichiers dans leur propre référentiel.
J'utilise manuellement Git pour garder une trace de mon personnel fichiers de configuration / de démarrage, par exemple, la configuration de Vim, les fonctions Bash, les alias, etc. - similaire à l'approche répertoriée dans Comment suivre $HOME avec git. Je conserve chaque ensemble de fichiers dans leur propre référentiel et j'utilise des liens symboliques vers le répertoire personnel.
Pour système fichiers de configuration, j'utilise Git avec Etckeeper pour garder une trace des fichiers dans mon /etc répertoire.
Inconvénients
Un problème dont il faut se méfier est si les fichiers suivis incluent des liens physiques . Lorsque Git est utilisé pour extraire des fichiers ou modifier autrement l'arborescence de travail, il dissocie les fichiers, puis les recrée. Voir Git, Dotfiles et Hardlinks pour une explication plus complète.
Etcgardien
Etckeeper peut être utilisé pour conserver un historique complet des modifications apportées à /etc. Il suit les métadonnées des fichiers que les systèmes de contrôle de révision ne prennent normalement pas en charge, mais c'est important pour /etc , comme les autorisations de /etc/shadow .
Il se connecte aux gestionnaires de packages tels que apt et yum et (dans sa configuration par défaut), s'exécute avant et après l'installation afin que toutes les modifications soient apportées à /etc sont suivis.
Si un paquet est installé ou supprimé, toutes les modifications non validées dans /etc seront validées avant l'opération de package afin qu'il y ait deux validations :
- "enregistrer les modifications non validées dans /etc avant l'exécution de yum"
- "commettre les modifications dans /etc après l'exécution de yum"
Je l'ai utilisé avec des distributions basées sur Debian et Red Hat et je sais qu'il prend en charge la gestion des packages Arch. Je ne peux pas dire combien d'automatisation cela ajouterait à un système Gentoo mais un paquet est disponible pour cela.
Il prend également en charge le transfert des fichiers de configuration vers un dépôt distant (qui devrait, bien sûr, être privé).
Configuration
Après avoir installé le package, vous devrez peut-être le configurer (/etc/etckeeper/etckeeper.conf ), par exemple, sur les systèmes Ubuntu, le système de contrôle de version par défaut est modifié de Git à Bazaar. Vous pouvez également désactiver les commits automatiques quotidiens .
Commitations automatiques quotidiennes
Les modifications peuvent être automatiquement validées par une tâche cron quotidienne . Cela peut être ennuyeux car le référentiel peut être encombré de plusieurs messages de validation automatisés.
Je décommente la ligne appropriée dans /etc/etckeeper/etckeeper.conf :
sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf
Ignorer certains fichiers
Modifier /etc/.gitignore pour spécifier les fichiers qui ne doivent pas être suivis.
Première exécution
Après la configuration, exécutez les commandes suivantes :
sudo etckeeper init
sudo etckeeper commit "Initial commit"
Si votre répertoire actuel est etc , vous pouvez exécuter la norme git commandes, par exemple,
sudo git status
sudo git log
J'utilise git pour suivre des zones spécifiques de mon répertoire personnel. Personnellement, je n'emprunterais pas la voie du suivi du répertoire racine, mais je dois dire que j'admire votre ambition. :)
Peut-être que cette collection d'expériences pourrait vous donner une meilleure idée de ce dans quoi vous pourriez vous embarquer :
effets de l'initialisation du référentiel git sur le répertoire racine Linux 3 :)
Toutes mes excuses pour une "réponse", au lieu de simplement lancer le lien dans un commentaire ; cependant, pas assez de représentants, mais souhaitait intervenir.
Modifier
Ouah! Très belle réponse de @AnthonyGeoghegan. Je crois que ce n'est pas aussi difficile que je l'avais imaginé à l'origine.