controle de versão para / etc em * BSD

Quais soluções turnkey existem para colocar /etcsob controle de versão, sob vários departamentos? Chave na mão não significa necessariamente parte da instalação base, mas os seguintes recursos seriam bons:

• conecta-se a comandos VCS para gerenciar metadados (propriedade, permissões);
• integração com o gerenciador de pacotes (execute automaticamente antes e depois das instalações, manipule as atualizações de maneira inteligente);
• tratar versões de arquivo upstream como uma ramificação;
• uma lista de ignorados pré-preenchida;
• suporte para vários VCS subjacentes (especialmente os distribuídos).

Eu uso o etckeeper no Debian e derivados. Ele possui todos os recursos acima, exceto que não acompanha as versões upstream. Eu gostaria de aprender sobre alternativas, particularmente no * BSD.

No Gentoo, a ferramenta para gerenciar mudanças induzidas por pacotes no / etc (chamada dispatch-conf) suporta rcs para rastrear alterações, mas isso não é realmente poderoso.

Eu tendem a versão meu / etc via git, especialmente porque, usando diferentes ramificações, posso manter meu / etc o mais semelhante possível em diferentes distribuições possíveis, mantendo o máximo de coisas em um só lugar possível (para algumas áreas que obviamente falham, configuração do apache por exemplo, é realmente diferente em diferentes distribuições). Funciona assim:

Eu tenho meu masterrepositório com meus arquivos de configuração padrão. Agora entro em contato com uma nova distribuição e crio uma nova ramificação com base na minha masterramificação com base no nome da distribuição (neste exemplo debian). O Debian mantém algum arquivo de configuração em um local diferente do meu, masterentão eu faço a git mv file new_loc. E está tudo bem. Volto mastere mudo esse arquivo porque adicionei alguma diretiva de configuração específica. Quando mesclo masterem minha debianramificação, o arquivo movido é alterado, para que eu possa alterar apenas a maioria das coisas em minha masterramificação e apenas mesclar alterações em minha "distribuição" branches (normalmente eles tendem a ser mais uma mistura de ramos de distribuição e de propósito, um servidor debian tem algumas diferenças em relação a uma estação de trabalho debian, obviamente, mas os recursos ainda funcionam).

Então, basicamente, eu tenho uma "configuração genérica" mastere (para dizer em termos de programação orientada a objetos) herdo-as em meus ramos (que também podem herdar uns dos outros).

Além disso, gitos mecanismos de "seleção de cereja" confirmados (neste caso, as alterações para / etc /) têm sido bastante úteis para mim em momentos em que eu precisava apenas de partes de uma determinada configuração.

Agora, para algumas de suas idéias:

• Se eu precisasse de mais integração com o gerenciador de pacotes, provavelmente usaria scripts de wrapper para isso (no momento não).
• tratar versões upstream como uma ramificação funcionaria bem git, é apenas outra ramificação que às vezes você mescla (parcialmente)master
• A lista de ignorados no git é o arquivo .gitignore no seu repositório, para que seja coberto.

Eu tenho usado fossilpara isso com algum sucesso. Veja meu post sobre Fossil para mais informações. Também usei uma ferramenta chamada etcupdateque é mais para mover entre atualizações do que rastrear alterações. Eu acredito que ele pretendia ser uma ferramenta complementar freebsd-updateem um ponto. Não tenho certeza de seu status atualmente, mas ele funciona nos meus RELEASE-8.*sistemas.

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

Existe uma ferramenta chamada etckeeper, que eu não tenho ideia de como é boa.

O etckeeper é uma coleção de ferramentas para permitir que o / etc seja armazenado em um repositório git, mercurial, darcs ou bzr. Ele se conecta ao apt (e outros gerenciadores de pacotes, incluindo yum e pacman-g2) para confirmar automaticamente as alterações feitas no / etc durante as atualizações do pacote. Ele rastreia os metadados de arquivo que os sistemas de controle de revisão normalmente não suportam, mas isso é importante para o / etc, como as permissões do / etc / shadow. É bastante modular e configurável, além de ser simples de usar, se você entender o básico de como trabalhar com controle de revisão.

Eu também não sei se ele pode ser feito para funcionar no * BSD Eu suspeito que sim, mas que não será suportado com portas prontas para uso.