Usando o etckeeper - proteção e outras questões

Question

Seguindo a sugestão feita Colocando o / etc sob controle de fonte eu instalei o ETCKEEPER.

Parece muito bom, mas tenho algumas perguntas.

• É de qualquer maneira colocar o comando que você faz na mensagem de mudança. Então, se eu rodar o apt-get install widget , eu gostaria que a primeira linha da mensagem de commit fosse algo como install widget ao invés de menos commiting changes in / etc após executar o apt

• Eu quero poder fazer perguntas sobre o repositório bzr de um usuário comum. Mas eu sou impedido pela proteção no diretório .bzr . Existem algumas dicas para mudar isso para a + r

  drwx ------ 6 raiz raiz 4096 30 de agosto 13:00 .bzr

• Existe alguma armadilha na remoção de arquivos (como / etc / shadow / do controle etckeeper

Answer 1

Se você olhar o log completo do bzr em vez do shortlog, verá que confirmando mudanças em / etc depois do apt run é seguido por uma lista dos pacotes que foram alterados. Pelo menos, esse é o comportamento no meu laptop e servidor Ubuntu. Para a grande maioria dos casos, eu suspeito que seja mais útil do que uma mensagem de commit "sudo apt-get upgrade".

O motivo pelo qual você é impedido de acessar o log bzr como um usuário comum é que o repositório bzr tem acesso total ao repositório shadow. Provavelmente, o maior obstáculo para parar isso é que, se você remover um arquivo do repositório bzr, ele ainda estará disponível em revisões antigas. Provavelmente há algum voodoo que você pode usar nas linhas de svndumpfilter | svnadmin --import mas para bzr, mas eu não tentei.

Uma alternativa que você pode tentar é sudo su . Ou talvez você possa criar um novo usuário e grupo, colocar o usuário nesse grupo, dar ao grupo acesso a .bzr e su a esse usuário para operações de interesse bzr.

    

Answer 2

Is the any way off putting the command you do into the change message.

Entender como o etckeeper funciona significa que você precisa entender como os sistemas de controle de versão funcionam. Com sistemas VCS você tem o conceito de seu repositório, basicamente um banco de dados de todas as mudanças, o diretório de trabalho onde você está mudando as coisas no momento.

Etckeeper pode realmente usar um dos vários back-ends do DVCS, ele pode suportar bzr, git e hg. Seja qual for o back-end que você usa, tudo funciona da mesma maneira. Eu uso o git como back-end, já que estou muito mais familiarizado com o git.

Com o Etckeeper, seu diretório de trabalho é quase sempre /etc , embora você possa usá-lo para outros diretórios. Quando tudo sobre o estado atual do seu diretório de trabalho for confirmado, seu diretório de trabalho será considerado limpo . Se você fizer uma alteração em algum arquivo e quiser que sua mudança seja confirmada no repositório, execute o comando etckeeper commit "Your log message here" . Você pode verificar se o repositório está em um estado limpo, executando um comando como etckeeper unclean && echo $ .

Com o fundo fora do caminho, posso entrar em como o etckeeper se conecta para ajudá-lo a acompanhar o que o apt faz. Quando o etckeeper é instalado, um arquivo de configuração é adicionado à configuração do apt em /etc/apt/apt.conf.d/05etckeeper . Isso configura alguns ganchos, então quando o apt for solicitado a instalar um pacote (s), ele executará o comando antes que a instalação seja iniciada e executará um comando após a conclusão da instalação. Para ver exatamente o que os comandos pre e post install analisam os scripts nos diretórios /etc/etckeeper/pre-install.d e /etc/etckeeper/post-install.d .

Basicamente, o comando pre-install fará um commit se o seu diretório de trabalho não estiver limpo. Se você não gostar disso, você pode simplesmente lembrar de executar manualmente uma confirmação depois de alterar qualquer coisa. Se você se opuser strongmente ao auto-commit, poderá ajustar o arquivo /etc/etckeeper/etckeeper.conf e descomentar a linha AVOID_COMMIT_BEFORE_INSTALL=1 . Fazer essa alteração significará que você será forçado a confirmar manualmente antes de poder executar o apt. Se você realmente não gosta do auto-commit, você também pode querer desabilitar o auto-commit diário, presente em versões mais novas.

I want to be able to do enquiries on the bzr repository from an ordinary user.

Essa é uma ideia extremamente ruim na minha opinião. Existem muitos arquivos em / etc que não devem ser legíveis para um usuário final. Se você quiser facilitar a sua vida, você pode configurar o sudo para não solicitar uma senha quando usar o bzr ou o etckeeper.

Are there any gotchas in removing files (such as /etc/shadow/ from etckeeper control

O jeito certo de fazer isso é usar o recurso de ignorar para o backend do DVCS que você escolheu. Se você usando o git você adicionaria o arquivo ao seu /etc/.gitignore , eu acredito que existe um /etc/.bzrignore que deveria fazer a mesma coisa, mas você pode precisar do bzr expert para confirmar isso para você. Pessoalmente, acho que gosto de acompanhar o arquivo /etc/shadow , pois ele permite que eu saiba se alguém mal conseguiu modificar uma conta de serviço que deveria ter uma senha desativada, para ter uma senha que permita que ela seja usada para logins.