Por que e como rastrear / var / log / dmesg com o controle de versão

Question

Em este wiki eles recomendam o rastreamento de /var/log/dmesg usando o Mercurial. Eu queria configurar um cron job no CentOS 6.4 como em esta página para me lembrar para fazer mensagens de commit para tal repo. No entanto, a saída de hg diff on /var/log/dmesg é bastante longa e eu realmente não entendo o que estou procurando.

Se você mesmo acompanhar esse arquivo, por quê? Com que problemas você fica atento? Com que frequência o seu muda?

    

Answer 1

Nos links que você postou sobre o rastreamento de /var/log/dmesg , ele é discutido apenas no primeiro, mas não acho que esse seja realmente o foco principal desses artigos. Eles estão discutindo principalmente como você rastrearia as alterações feitas no seu diretório /etc , que é algo que você definitivamente gostaria de fazer, e é bem fácil de fazer.

No entanto, se você estiver interessado em acompanhar as alterações de /etc , eu usaria uma ferramenta de wrapper, como etckeeper , em vez de fazê-lo com vanilla git / mercurial (existem várias razões para isso, o principal é que git e mercurial não acompanham as permissões que se tornam importantes em /etc ). Obviamente, para /etc , todas as suas informações de configuração são mantidas lá, por isso é valioso acompanhar as alterações nesses arquivos ao longo do tempo.

Sobre se você deve acompanhar as alterações feitas em /var/log/dmesg ? Eu não vejo nenhum valor nisso e acredito que seria um desperdício de tempo e recursos para fazê-lo.

    

Answer 2

O rastreamento de arquivos de configuração, como quase tudo em /etc , é uma boa ideia. Em vez de cometer apenas alguns arquivos, basta confirmar tudo. Gerenciar /etc pode ser um pouco complicado (você precisa restaurar permissões e propriedade de arquivos, o que o software de controle de versão normalmente não faz), e é realmente útil ter gerenciadores de pacotes realizando commits automaticamente, então eu não faço isso. Não recomendamos o uso de software de controle de versão diretamente. Em vez disso, use o etckeeper , que cuida do gerenciamento da permissão e propriedade, e tem ganchos para o yum. Ao contrário do Debian e do Ubuntu, o CentOS não envia o etckeeper pronto para uso, mas o pode ser instalado .

O rastreamento de /usr/local/bin e /usr/local/sbin pode ser uma boa ideia, embora dependa do que você coloca lá. Se você escrever scripts para o seu sistema e colocá-los lá, esses diretórios devem estar sob controle de versão. Se você instalar software de terceiros, esses diretórios provavelmente não devem estar sob controle de versão. O que eu faço é escrever meus scripts locais em /etc/local/bin e /etc/local/sbin (que estão na área gerenciada pelo etckeeper) e adicionar esses diretórios ao PATH padrão do sistema ou criar links simbólicos em /usr/local .

Colocar arquivos de log como /var/log/dmesg e /var/log/rpmpkgs sob controle de versão é inútil. Os arquivos de log crescem sempre sob operação normal. Eles podem ser girados, o que reduz o arquivo de log, mas não remove nenhum dado de log: ele é movido para um novo nome de arquivo. Como o registro só cresce, não faz sentido reverter para uma versão anterior. O log não será ramificado. O registro só é modificado automaticamente, não manualmente. Assim, nenhum dos benefícios do controle de versão entra em ação.

Pior, pode haver um requisito legal para limpar logs antigos de privacidade. Colocar os logs sob controle de versão dificulta muito a limpeza de versões antigas. Os registros devem ser arquivados separadamente.