¿Control de versiones para /etc bajo *bsd?

Qué soluciones llave en mano existen para poner /etc bajo 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 con los comandos de VCS para administrar los metadatos (propiedad, permisos);
• integración con el administrador de paquetes (se ejecuta automáticamente antes y después de las instalaciones, maneja las actualizaciones de manera inteligente);
• tratar las versiones anteriores del archivo como una rama;
• una lista de ignorados precargada;
• soporte para varios VCS subyacentes (especialmente los distribuidos).

Uso etckeeper bajo 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 sobre *BSD.

Respuesta aceptada:

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

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

• Tengo mi master repositorio 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 master rama basada en el nombre de la distribución (en este ejemplo, debian).

• Debian guarda algunos archivos de configuración en una ubicación diferente de mi master así que hago un archivo git mv file new_loc . Y todo está bien.

• Vuelvo a master y cambie ese archivo porque agregué una directiva de configuración específica.

• Cuando fusiono master en mi debian ramifica el archivo movido, por lo que básicamente puedo cambiar la mayoría de las cosas dentro de mi master rama y solo tengo que fusionar los cambios en mis ramas de "distribución" (por lo general, tienden a ser más una combinación de ramas de distribución y propósito, un servidor Debian tiene algunas diferencias con una estación de trabajo Debian, obviamente, pero las funciones aún funcionan).

Básicamente, tengo una "configuración genérica" ​​en master y (para decirlo en términos de programación orientada a objetos) heredar esos en mis sucursales (que también pueden heredar entre sí).

Aparte de eso, git Los mecanismos de "selección selectiva" de confirmaciones (en este caso, cambios a /etc/ ) me ha sido muy útil en momentos en los que solo necesitaba partes de una determinada configuración.

Relacionado:¿Ejecutar el comando Unix con precisión en intervalos muy cortos SIN acumular retrasos con el tiempo?

Ahora algunas de sus ideas:

• Si necesitara más integración con el 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 con git , es solo otra rama que a veces fusionas (parcialmente) en master
• La lista de ignorados en git es el archivo .gitignore en su repositorio para que esté cubierto.