Quelles solutions clés en main existent pour mettre /etc sous contrôle de version, sous divers unices ? Clé en main ne signifie pas nécessairement une partie de l'installation de base, mais les fonctionnalités suivantes seraient intéressantes :
- se connecte aux commandes VCS pour gérer les métadonnées (propriété, autorisations) ;
- intégration avec le gestionnaire de packages (s'exécute automatiquement avant et après les installations, gère intelligemment les mises à niveau) ;
- traiter les versions de fichiers en amont comme une branche ;
- une liste d'ignorés pré-remplie ;
- prise en charge de plusieurs VCS sous-jacents (en particulier ceux distribués).
J'utilise etckeeper sous Debian et dérivés. Il possède toutes les fonctionnalités ci-dessus, sauf qu'il ne garde pas la trace des versions en amont. J'aimerais en savoir plus sur les alternatives, en particulier sur *BSD.
Réponse acceptée :
Sous Gentoo, l'outil pour gérer les modifications induites par les packages sur /etc (appelé dispatch-conf ) prend en charge rcs pour suivre les modifications, mais ce n'est pas vraiment puissant.
J'ai tendance à versionner mon /etc via git , d'autant plus qu'en utilisant différentes branches je peux conserver mon /etc aussi similaire que possible sur différentes distributions que possible tout en gardant autant de choses au même endroit que possible (pour certains domaines qui échouent évidemment, la configuration d'Apache, par exemple, est vraiment différente entre différentes distributions). Cela fonctionne comme ceci :
-
J'ai mon
masterdépôt avec mes fichiers de configuration par défaut. -
Maintenant j'entre en contact avec une nouvelle distribution donc je crée une nouvelle branche basée sur mon
masterbranche basée sur le nom de la distribution (dans cet exemple debian). -
Debian conserve certains fichiers de configuration dans un emplacement différent de mon
masterdonc je fais un fichiergit mv file new_loc. Et tout va bien. -
Je repasse en
masteret modifiez ce fichier car j'ai ajouté une directive de configuration spécifique. -
Quand je fusionne
masterdans mondebianbranche le fichier déplacé est modifié, donc je peux simplement changer la plupart des choses dans monmasterbranche et j'ai juste à fusionner les changements dans mes branches de "distribution" (généralement, elles ont tendance à être plus un mélange de branches de distribution et d'objectif, un serveur Debian a évidemment quelques différences avec un poste de travail Debian mais les fonctionnalités fonctionnent toujours).
Donc, en gros, j'ai une "configuration générique" dans master et (pour le dire en termes de programmation orientée objet) en héritent dans mes branches (qui peuvent également hériter les unes des autres).
En dehors de cela, git mécanismes de "cherry-pick" commits (dans ce cas, les changements à /etc/ ) m'a été très utile lorsque je n'avais besoin que de certaines parties d'une certaine configuration.
Passons maintenant à certaines de vos idées :
- Si j'avais besoin d'une plus grande intégration du gestionnaire de packages, j'utiliserais probablement des scripts wrapper pour cela (pour le moment, ce n'est pas le cas).
- traiter les versions amont comme une branche fonctionnerait bien avec
git, c'est juste une autre branche que vous fusionnez parfois (partiellement) dansmaster - La liste des ignorés dans git est le fichier
.gitignoredans votre dépôt afin que cela soit couvert.