Gostaria de acompanhar as alterações em / etc /
Basicamente eu gostaria de saber se um arquivo foi alterado, por yum update ou por um usuário e retroceder se não gostar do chage.
Pensei em usar um VCS como git, LVM ou btrfs snapshots ou um programa de backup para isso.
O que você recomendaria?
Parece que você quer etckeeper do Joey Hess do Debian, que gerencia arquivos sob /etc usando o controle de versão. Suporta git, mercurial, darcs e bazar.
git is the VCS best supported by etckeeper and the VCS users are most likely to know. It's possible that your distribution has chosen to modify etckeeper so its default VCS is not git. You should only be using etckeeper with a VCS other than git if you're in love with the other VCS.
Não posso dar uma recomendação final, mas posso compartilhar algumas reflexões sobre o assunto. Dado que o / etc é geralmente pequeno, você pode optar por uma simples solução de tar-ball compactada. Se você não precisa passar pelo histórico, pode ser a solução mais fácil de configurar.
Para mim, seria tedioso gerenciar os volumes lógicos apenas para acompanhar / etc e especialmente porque eu não acho que os snapshots do LVM foram projetados para serem criados regularmente como meio de backup de uma quantidade relativamente pequena de dados. .
O btrfs parece ser muito melhor para isso, mas ainda não é tão estável quanto, por exemplo, ext {2,3,4} e a ferramenta fsck também não está pronta ainda. Mas continuamente melhora.
Pessoalmente, eu realmente uso o git para rastrear / etc, mas você deve ter em mente que o git não armazena metainformation de arquivo como posse ou permissão! E também verifique se o diretório .git tem a permissão correta. Existem algumas ferramentas que ajudam com esses problemas. Você pode querer dar uma olhada em etc-keeper , que foi desenvolvido exatamente para acompanhar / etc ou use pelo menos algo como gitperms ou metastore para rastrear a metainformação.
Para acompanhar as alterações "indesejadas", usamos um HIDS - no nosso caso samhain outros são tripwire ou aide . Todos esses sistemas avisam quando algo indesejado aconteceu.
Um yum update não deve alterar nada sem deixar um .rpmnew ou .rpmold, se o arquivo de configuração estiver sinalizado como tal no rpm correspondente.
Myselv Achei uma boa prática fazer uma cópia de segurança do arquivo que vou modificar com cp -p origfile origfileYYYY-MM-DD com a data do dia anterior.
Se tudo mais falhar - eu chamo os caras de backups e peço uma restauração do último backup "bom" conhecido.
Eu acho que você pode fazer um instantâneo de arquivos / diretórios em /etc .
Primeiro faça uma lista de arquivos / etc / diretório:
# ls -lha /etc >> /snapshotofetc
E se você criar um arquivo no /etc
# touch testfile
e se você retomar um instantâneo de /etc como o que fizemos antes
# ls -lhs /etc /lastsnapshotofetc
e então você pode comparar as diferenças entre os 2 arquivos como este:
# diff /snapshotofetc /lastsnapshotofetc
Há sempre radmind . Você pode reverter essa mudança se não gostar.
Você está procurando gerenciamento de configuração ou rastreamento / monitoramento das alterações no sistema de arquivos?
Se for mais cedo, eu verificaria puppet ou chef . CFEngine existe para fins comerciais. puppet é uma fera popular nos dias de hoje.
Se for o último, é difícil monitorar as alterações no sistema de arquivos, mas existem exemplos de programas como inotify e auditoria do sistema de arquivos auditctl ou fam do SGI, mas novamente, é um monitoramento e pode ser caro implementação (o desempenho do sistema de arquivos pode se deteriorar).
Você pode verificar rsnapshot , que mantém instantâneos de hora em hora dos diretórios que você quiser ... você pode configurar 24 horas, depois X diários, depois X semanais, etc. Tanto quanto você deseja para espaço em disco . É inteligente o suficiente para linkar quando os arquivos não foram alterados (usa rsync nos bastidores.
Você pode considerar o uso de git . Você pode É eficiente no rastreamento de alterações e muito fácil de usar para algo parecido com isto.
git status # Show changed files
git diff # Show file differences (paged automatically)
git commit -a # Commit all changes.
Eu acredito que a configuração inicial seja assim. Eu não fiz isso por um tempo.
cd /etc
git init
git add *
git commit -a -m "Created repository"
Essa abordagem funciona melhor para um único servidor, mas pode ser colocada em camadas com outras ferramentas que alteram o repositório. Isso pode ser útil em seu site (s) canário (s) para garantir que as mudanças esperadas estão ocorrendo.
Você pode usar a clonagem para lidar com arquivos comuns a vários servidores.
Eu tenho um script que é executado todos os dias e faz o backup de arquivos que foram alterados desde o backup anterior:
#!bin/bash
ext=$(date +"%Y%m%d")_ChangeS
mkdir -p "$1/$ext" && \
ionice -c3 rsync -ah --numeric-ids --inplace --backup \
--backup-dir="$1/$ext" \
--include="/etc" / "$1" && \
rmdir --ignore-fail-on-non-empty "$1/$ext"
Você passa o caminho onde os backups seriam criados e esse diretório terá uma listagem semelhante a esta (depois de algumas execuções):
20120106_ChangeS etc
$ls 20120106_ChangeS/etc/
cron.d
Você pode modificá-lo um pouco para registrar as alterações com mais frequência ou usar o inotify para acionar uma versão modificada do script quando ocorrem alterações em /etc .