Control de versiones para / etc bajo * BSD

¿Qué soluciones llave en mano existen para poner /etcbajo control de versiones, bajo varios unices? Llave en mano no necesariamente significa parte de la instalación base, pero las siguientes características serían buenas:

• se conecta a los comandos VCS para administrar metadatos (propiedad, permisos);
• integración con el administrador de paquetes (se ejecuta automáticamente antes y después de las instalaciones, gestiona las actualizaciones de forma inteligente);
• tratar las versiones de archivos ascendentes como una rama;
• una lista de ignorados precargada;
• soporte para varios VCS subyacentes (especialmente los distribuidos).

Yo uso etckeeper en Debian y derivados. Tiene todas las características anteriores, excepto que no realiza un seguimiento de las versiones anteriores. Me gustaría aprender sobre alternativas, particularmente en * BSD.

Bajo Gentoo, la herramienta para administrar cambios inducidos por paquetes a / etc (llamada dispatch-conf) admite rcs para rastrear cambios, pero eso no es realmente poderoso.

Tiendo a versionar mi / etc a través git, especialmente porque al usar diferentes ramas puedo mantener mi / etc lo más similar posible en diferentes distribuciones como sea posible mientras mantengo la mayor cantidad de cosas en un lugar posible (para algunas áreas que obviamente fallan, configuración de apache por ejemplo, es realmente diferente en diferentes distribuciones). Funciona así:

Tengo mi masterrepositorio con mis archivos de configuración predeterminados. Ahora entro en contacto con una nueva distribución, así que creo una nueva rama basada en mi masterrama basada en el nombre de la distribución (en este ejemplo, debian). Debian mantiene algún archivo de configuración en una ubicación diferente a la mía, masterasí que hago un git mv file new_loc. Y todo está bien. Vuelvo mastery cambio ese archivo porque agregué una directiva de configuración específica, cuando me fusiono masteren mi debianrama, el archivo movido cambia, por lo que básicamente puedo cambiar la mayoría de las cosas dentro de mi masterrama y solo tengo que fusionar los cambios en mi "distribución" ramas (por lo general, tienden a ser más una mezcla de distribución y ramas de propósito, un servidor Debian tiene algunas diferencias con una estación de trabajo Debian, obviamente, pero las características aún funcionan).

Así que, básicamente, tengo una "configuración genérica" mastery (por decirlo en términos de programación orientada a objetos) las heredo en mis ramas (que también pueden heredarse entre sí).

Aparte de eso, gitlos mecanismos para "confirmar" los compromisos (en este caso, los cambios a / etc /) me han sido muy útiles en momentos en los que solo necesitaba partes de una determinada configuración.

Ahora a algunas de sus ideas:

• Si necesitara más integración del administrador de paquetes, probablemente usaría scripts de envoltura para esto (en este momento no lo hago).
• tratar las versiones anteriores como una rama funcionaría bien git, es solo otra rama en la que a veces se fusiona (parcialmente)master
• La lista de ignorados en git es el archivo .gitignore en su repositorio para que esté cubierto.

He usado fossilesto con cierto éxito. Vea mi publicación sobre Fossil para más información. También he usado una herramienta llamada etcupdateque es más para moverse entre actualizaciones que para rastrear cambios. Creo que en un momento fue una herramienta complementaria freebsd-update. No estoy seguro de su estado actualmente, pero funciona en mis RELEASE-8.*sistemas.

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

Hay una herramienta llamada etckeeper. No tengo idea de lo buena que es.

etckeeper es una colección de herramientas para permitir que / etc se almacene en un repositorio git, mercurial, darcs o bzr. Se conecta a apt (y a otros gestores de paquetes, incluidos yum y pacman-g2) para confirmar automáticamente los cambios realizados en / etc durante las actualizaciones de paquetes. Realiza un seguimiento de los metadatos de archivos que los sistemas de control de revisión normalmente no son compatibles, pero eso es importante para / etc, como los permisos de / etc / shadow. Es bastante modular y configurable, a la vez que es fácil de usar si comprende los conceptos básicos de trabajar con el control de revisión.

Tampoco sé si se puede hacer que funcione en * BSD, sospecho que podría, pero que no será compatible con los puertos listos para usar.