Como verificar o conteúdo do arquivo, não o atime, mtime, ctime no Linux?

Question

Existe alguma maneira de descobrir qual conteúdo de arquivo foi modificado ou adicionado no Linux. Estou ciente do atime, ctime, mtime. Digamos que eu criei um script "myscript.sh" e alguém alterou algum conteúdo dele, por exemplo adicionou algumas linhas de código ou excluiu. Eu quero saber qual conteúdo foi alterado desde que o arquivo foi criado?

Alguma ideia?

    

Answer 1

Com base nos seus comentários à resposta do @ SahibPrime, você deve usar o etckeeper

Na home page:

etckeeper is a collection of tools to let /etc be stored in a git, mercurial, bazaar or darcs repository. This lets you use git to review or revert changes that were made to /etc. Or even push the repository elsewhere for backups or cherry-picking configuration changes.

It hooks into package managers like apt to automatically commit changes made to /etc during package upgrades. It tracks file metadata that git does 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 version control.

Uma coisa que o SahibPrime não mencionou foi que você pode usar git diff para visualizar as alterações feitas entre as versões atuais e / ou anteriores, e quando essas alterações foram feitas. Você também pode facilmente reverter para qualquer versão anterior de qualquer arquivo controlado por revisão.

No Debian, pelo menos, ele é executado diariamente a partir do cron, então você nem precisa lembrar de confirmar as alterações. Quase certamente também é executado a partir do cron em outras distribuições.

Instale e esqueça completamente até que você precise. Não requer manutenção.

Você também pode usar git (ou qualquer outro software similar) para rastrear alterações em / usr / local. Eu costumava usar o RCS por anos em / etc e em diretórios como / usr / local / {s,} bin / e ~ / bin. Mais tarde, mudei para svn . etckeeper e git são melhores.

tldr: gitmeoutofhere

Eu devo ter mudado para o etckeeper em 2012. Eu tenho um histórico de revisão de todas as mudanças (pelo menos diariamente e antes / depois de cada apt de instalação ou atualização) desde então.

# git log | tail -5 
commit 7e3bb0eade7ae9e211bb684be2e3c7d4a3128c24
Author: ...my.email.address.deleted...
Date:   Wed Feb 29 12:53:30 2012 +1100

    Initial commit

# git log | grep '^commit' | wc -l
1378

Eu quase nunca tenho que olhar ou pensar sobre isso ou até mesmo lembrar que está lá, mas quando eu preciso, é inestimável . Eu posso desfazer qualquer coisa estúpida que eu possa fazer e imediatamente recuperar uma versão válida e em bom funcionamento de qualquer arquivo de configuração.

Veja algumas das coisas que posso fazer com todo esse histórico de revisão dos meus arquivos de configuração:

Eu posso ver uma lista de commits para arquivos específicos:

# git log apache2/apache2.conf | sed -ne 's/commit //p'  | head
2d0fabf90f2bc639d30bca925147fafd3fbd5e50
8022c7ca6dbe1661064604a646c52ca0d1f1b3ac
0620c88b8d1fd625f74f42059a4e8f056846df16
8c2fcfef72eca034b251654be44a268e92e39416
02329cf86655a2bb2c09c793b1d195a4de579cf1
5e449105f0ab75f9e903d8c75af5c8db6543c281
d8339212967af2c664b0c1776e9352f6c0e12ff8
7e3bb0eade7ae9e211bb684be2e3c7d4a3128c24

Eu posso ver quando algum desses commits aconteceu:

# git log 8022c7ca6dbe1661064604a646c52ca0d1f1b3ac | head -5
commit 8022c7ca6dbe1661064604a646c52ca0d1f1b3ac
Author: ...
Date:   Tue Aug 20 12:26:53 2013 +1000

    committing changes in /etc after apt run

e eu posso ver o diff:

# git diff 8022c7ca6dbe1661064604a646c52ca0d1f1b3ac apache2/apache2.conf
diff --git a/apache2/apache2.conf b/apache2/apache2.conf
index baf6d8a..617152c 100644
--- a/apache2/apache2.conf
+++ b/apache2/apache2.conf
@@ -71,7 +71,7 @@
 #
 # The accept serialization lock file MUST BE STORED ON A LOCAL DISK.
 #
-Mutex file:${APACHE_LOCK_DIR} default
+#Mutex file:${APACHE_LOCK_DIR} default

 #
 # PidFile: The file in which the server should record its process

E eu posso reverter qualquer coisa e / ou tudo para qualquer versão anterior. O mais útil é a reversão de um arquivo individual:

# git checkout 8022c7ca6dbe1661064604a646c52ca0d1f1b3ac apache2/apache2.conf
# git diff 8022c7ca6dbe1661064604a646c52ca0d1f1b3ac apache2/apache2.conf
#

Eu posso ver uma lista de arquivos que foram alterados desde o último commit:

# git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   apache2/apache2.conf

no changes added to commit (use "git add" and/or "git commit -a")

Se eu quisesse, poderia confirmar isso novamente (com git add e git commit ) ou mudar de idéia e trazer de volta o commit mais recente:

# git checkout 2d0fabf90f2bc639d30bca925147fafd3fbd5e50 apache2/apache2.conf
# git help status
# 

    

Answer 2

Você pode fazer isso de maneira VCS via git .
Primeiro, instale o git (ele deve estar pré-instalado, se não, o gerenciador de pacotes deve tê-lo). Para sistemas Debian: sudo apt-get install git
Em seguida, crie um diretório para manter seu arquivo em ( mkdir myDir )
Vá para o diretório e execute git init . (Isso criará um repositório Git local).
Adicione seu arquivo ao diretório e execute git add -f * .
Agora, você pode executar git commit -m "file before editing" para salvar seu arquivo como está.
Você pode executar git status para ver se o arquivo foi editado ou não. Vai mostrar algo como:

modified: myFile.txt

Se você quiser reverter o arquivo para a última vez em que executou git commit , poderá executar git reset --hard HEAD^ . Isso forçará o repositório local a retornar ao último commit.

Você pode salvar uma nova alteração no arquivo com git commit , assim:

git commit -m "added 4 lines"

Se você quiser ver uma lista de commits (e suas mensagens), você pode executar git log .

O VCS foi projetado para isso, e eu o usei na minha resposta.

    

Answer 3

Normalmente, não há recursos embutidos no Unix (ou melhor, incorporados nos sistemas de arquivos mais comuns do Unix, como está / estava no OpenVMS ), então você não pode esperar recuperar versões anteriores de um arquivo.

A solução mais simples seria manter uma cópia pessoal dos arquivos que você gostaria de "monitorar" e, em seguida, executar periodicamente diff sobre essas e as cópias instaladas no sistema.

O próximo passo é manter os arquivos em algum tipo de sistema de controle de revisão. O mais prontamente disponível no Unix é geralmente RCS , que é muito básico, mas que faz o que diz na lata. / p> O

Git é mais sofisticado, mas pode ser muito trabalhoso se isso envolver apenas um ou um punhado de arquivos (o RCS manipula arquivos individuais e não tem o conceito de "um repositório" de muitos arquivos que estão juntos).

    

Answer 4

Um "diff" não seria suficiente? diff oldfile newfile > mudanças colocariam todas as diferenças no nome do arquivo com os números de linha apropriados.

Alan

    

Answer 5

Você pode estar procurando por um sistema de detecção de intrusão (um IDS). Alguns IDSs examinam periodicamente todos os arquivos em seu sistema e alertam sobre alterações inesperadas. O exemplo clássico é tripwire , mas eu tenho recebido um 403 em tripwire.org pelas últimas oito horas.

Esses sistemas normalmente lembram apenas as somas de verificação dos arquivos, portanto, para saber o que mudou, é necessário comparar com seus backups.

    

Answer 6

Um método último recurso , para aqueles que não usaram o controle de revisão. Aviso: Verifique os pré-requisitos, pode não funcionar em sua situação. Eu só fiz isso duas vezes.

Pré-requisitos:

• O arquivo foi alterado por um editor que substituiu o arquivo: unlink, create; ou crie, desvincule, mova. (não modificando o original)
• O arquivo original ainda está aberto por pelo menos um processo no sistema.
• Você é inteligente, paciente e tem tempo.
• Você tem sorte (lembre-se "quanto mais eu pratico, mais sorte eu recebo").

Método:

1. Encontre o processo que ainda tem o arquivo original aberto. (Dica: lsof )
2. Identifique o PID deste processo.
3. Navegue até /proc/«pid»/fd .
4. Identifique o descritor de arquivo (um número: 0 é stdin, 1 stdout, 2 stderr, outros números para outros arquivos) para o arquivo que você está procurando.
5. Copie o arquivo de /proc/«pid»/fd/«file-descriptor» para uma área de armazenamento persistente (disco rígido).

Atenção: isso é mágico (graças a @wildcard por me lembrar disso).