controle de versão para / etc em * BSD

Question

Quais soluções completas existem para colocar /etc sob controle de versão, sob vários unices? Turnkey não significa necessariamente parte da instalação básica, mas os seguintes recursos seriam bons:

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

Eu uso o etckeeper sob o Debian e seus derivados. Ele tem todos os recursos acima, exceto que não mantém o controle das versões upstream. Eu gostaria de aprender sobre alternativas, particularmente no * BSD.

    

Answer 1

Sob o Gentoo, a ferramenta para gerenciar mudanças induzidas por pacotes em / etc (chamado dispatch-conf) suporta o rcs para rastrear mudanças, mas isso não é realmente poderoso.

Eu tenho a tendência de usar my / etc via git , especialmente porque usando diferentes branches eu posso manter meu / etc o mais parecido possível sobre distribuições diferentes quanto possível, mantendo o máximo possível em um lugar (para algumas áreas) que obviamente falha, a configuração do apache, por exemplo, é realmente diferente em diferentes distribuições). Funciona assim:

Eu tenho meu master repo com meus arquivos de configuração padrão. Agora eu entro em contato com uma nova distro, então eu crio uma nova ramificação baseada na minha ramificação master 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 master , então eu faço um git mv file new_loc . E está tudo bem. Volto para master e altero esse arquivo porque adicionei uma diretiva de configuração específica, quando mescla master em minha ramificação debian , o arquivo movido é alterado, então basicamente posso alterar a maioria das coisas dentro de minha master ramificação e apenas tem que mesclar as mudanças em minhas ramificações de "distribuição" (geralmente elas tendem a ser mais de uma combinação de ramificações de distribuição e finalidade, um servidor debian tem algumas diferenças para uma estação de trabalho debian obviamente, mas os recursos ainda funcionam). >

Então, basicamente, eu tenho uma "configuração genérica" em master e (para dizer isso em termos de programação orientada a objeto), herdo-as em minhas ramificações (que também podem herdar umas das outras).

Além disso, os mecanismos de git para "cherry-pick" commits (neste caso, alterações em / etc /) foram bastante úteis para mim, nos momentos em que eu precisei apenas de partes de uma determinada configuração.

Agora, algumas de suas ideias:

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

Answer 2

Eu usei fossil para isso com algum sucesso. Veja meu post sobre Fossil para mais informações. Eu também usei uma ferramenta chamada etcupdate , que é mais para mover entre as atualizações do que as alterações de rastreamento. Acredito que foi planejado para ser uma ferramenta complementar para freebsd-update em um determinado momento. Não tenho certeza do status atual, mas funciona nos meus sistemas RELEASE-8.* .

link link

    

Answer 3

Existe uma ferramenta chamada etckeeper Eu não tenho ideia de como é bom.

etckeeper is a collection of tools to let /etc be stored in a git, mercurial, darcs, or bzr repository. It hooks into apt (and other package managers including yum and pacman-g2) to automatically commit changes made to /etc during package upgrades. It tracks file metadata that revison control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with revision control.

Eu também não sei se pode ser feito para trabalhar em * BSD, eu suspeito que poderia, mas que não será suportado com portas fora da caixa.