contrôle de version pour / etc sous * BSD

Quelles solutions clé en main existent pour mettre /etcsous contrôle de version, sous différents unices? Clé en main ne signifie pas nécessairement une partie de l'installation de base, mais les fonctionnalités suivantes seraient bien:

• 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'ignorance pré-remplie;
• prise en charge de plusieurs VCS sous-jacents (en particulier ceux distribués).

J'utilise etckeeper sous Debian et ses dérivés. Il possède toutes les fonctionnalités ci-dessus, sauf qu'il ne garde pas la trace des versions en amont. Je voudrais en savoir plus sur les alternatives, notamment sur * BSD.

Sous Gentoo, l'outil de gestion des modifications induites par les packages dans / 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 garder mon / etc aussi similaire que possible sur différentes distributions tout en conservant autant de choses en un seul endroit que possible (pour certaines zones qui échouent évidemment, configuration apache par exemple, est vraiment différent selon les 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 ma masterbranche basée sur le nom de la distribution (dans cet exemple debian). Debian conserve un fichier de configuration dans un emplacement différent du mien, masterdonc je fais un git mv file new_loc. Et tout va bien. Je reviens masteret change ce fichier parce que j'ai ajouté une directive de configuration spécifique, quand je fusionne masterdans ma debianbranche, le fichier déplacé est changé, donc je peux simplement changer la plupart des choses dans ma masterbranche et juste avoir à fusionner les changements dans ma "distribution" des branches (généralement elles ont tendance à être plus un mélange de branches de distribution et d’objectifs, un serveur Debian a des différences avec une station de travail Debian bien sûr mais les fonctionnalités fonctionnent toujours).

Donc, fondamentalement, j'ai une "configuration générique" dans masteret (pour le dire en termes de programmation orientée objet) hériter ceux de mes branches (qui peuvent également hériter les uns des autres).

En dehors de cela, gitles mécanismes de commits "cherry-pick" (dans ce cas, les modifications apportées à / etc /) m'ont été très utiles à certains moments où je n'avais besoin que de parties d'une certaine configuration.

Passons maintenant à certaines de vos idées:

• Si j'avais besoin de plus d'intégration du gestionnaire de paquets, j'utiliserais probablement des scripts wrapper pour cela (pour le moment, je n'en ai pas).
• traiter les versions en amont comme une branche fonctionnerait bien git, c'est juste une autre branche dans laquelle vous fusionnez parfois (partiellement) enmaster
• La liste des ignorés dans git est le fichier .gitignore dans votre référentiel, donc cela est couvert.

Je l'ai utilisé fossilavec succès. Voir mon article sur Fossil pour plus d'informations. J'ai également utilisé un outil appelé etcupdatequi permet davantage de passer d'une mise à niveau à l'autre que de suivre les modifications. Je crois que cela devait être un outil complémentaire freebsd-updateà un moment donné. Je ne suis pas sûr de son statut actuellement mais il fonctionne sur mes RELEASE-8.*systèmes.

http://lists.freebsd.org/pipermail/freebsd-current/2010-June/017927.html http://people.freebsd.org/~jhb/etcupdate/

Il y a un outil appelé etckeeper, je ne sais pas à quel point il est bon.

etckeeper est une collection d'outils pour laisser / etc être stocké dans un dépôt git, mercurial, darcs ou bzr. Il se connecte à apt (et à d'autres gestionnaires de packages, yum et pacman-g2) pour valider automatiquement les modifications apportées à / etc lors des mises à niveau des packages. Il suit les métadonnées des fichiers que les systèmes de contrôle de révision ne prennent généralement pas en charge, mais cela est important pour / etc, comme les autorisations de / etc / shadow. Il est assez modulaire et configurable, tout en étant simple à utiliser si vous comprenez les bases du travail avec le contrôle de révision.

Je ne sais pas non plus s'il peut fonctionner sur * BSD, je le pense, mais qu'il ne sera pas pris en charge avec des ports prêts à l'emploi.