Tieni traccia, salva e ripristina le modifiche del file system apportate da un programma su Linux

9

Mi piacerebbe poter, quando viene eseguito un programma come un programma di installazione, tenere traccia dell'elenco delle modifiche apportate al mio filesystem in modo da poterle ripristinare in seguito.

EDIT: riguarda un programma non impacchettato . Uso apt-get per quanto posso.

Idealmente mi piacerebbe poter fare qualcosa del tipo:

(sudo) catch-modifs some-installer.bin > fsmodifs.patch

E poi:

(sudo) revert-modifs fsmodifs.patch

C'è un modo conveniente per farlo?

— Ywen
fonte

1

Forse il modo più semplice (?) Per farlo è quello di avviare un LiveUSB con una "partizione dati persistente". (Oppure, per replicare l'effetto tu stesso, in una prigione chroot: monta un livello rw su un livello ro.) Scatta un'istantanea del filesystem rw - che dovrebbe essere molto sottile dopo un nuovo avvio - quindi esegui il tuo programma di installazione. Ogni file che altera o crea sarà sulla partizione overlay "dati persistenti" rw. Anche i file rimossi appariranno come "dotfile magici".

— BRPocock
fonte

Sembra complicato ... Non è possibile solo creare una nuova partizione, montare la vecchia RO e montarla su quella nuova in RW?

— Ywen,

Sì, puoi farlo anche tu, dalla modalità utente singolo, forse. Dai un'occhiata al unionfs- sostanzialmente, il filesystem RW accetta tutte le scritture, ma il filesystem RO è ancora visibile sotto di esso. Se un file viene modificato, "migra" su RW fs; se viene eliminato, in realtà c'è un "dotfile magico" sull'RW fs per "mascherarlo". L'impostazione unionfspuò essere un po 'permalosa, è per questo che ho suggerito LiveUSB (fa quella parte per te, e hai un'immagine di sistema "pulita" da cui iniziare)

— BRPocock,

2

Forse dai un'occhiata a tripwire? Tripwire è più passivo del tuo esempio attivo, ma può ancora funzionare per te.

http://www.linuxjournal.com/article/8758

Tripwire è un sistema di rilevamento delle intrusioni (IDS) che, costantemente e automaticamente, tiene sotto controllo i file e i rapporti del sistema critico se sono stati distrutti o modificati da un cracker (o per errore). Consente all'amministratore di sistema di sapere immediatamente cosa è stato compromesso e risolverlo.

— Corith Malin
fonte

1

Dai un'occhiata a Installwatch:

http://en.wikipedia.org/wiki/Installwatch#Functionality

http://asic-linux.com.mx/~izto/checkinstall/installwatch.html

— qerub
fonte

Intendi "CheckInstall"? Funziona quando non ho makefile? Nel mio caso (Eclim) l'installazione è stata effettuata tramite un installer jar.

No, intendo Installwatch che fa parte di CheckInstall.

— qerub,

"Installwatch funziona con tutti i programmi ELF collegati dinamicamente, sovrascrivendo le chiamate di sistema che causano alterazioni del file system. Alcune di queste chiamate di sistema sono aperte (2) e scollegate (2)." Dovrebbe funzionare bene con una JVM.

— qerub,

Sì, ma a quanto pare Installwatch da solo non è più stato mantenuto per molto tempo. Inoltre è necessario CheckInstall per poter ripristinare i registri di InstallWatch. Dovrei ancora dare un'occhiata. Grazie.

1

Utilizzare LD_PRELOADper caricare una libreria che intercetta la openfunzione della libreria e modifica il percorso / registra l'output / esegue un backup prima di aprire il file.

Dai un'occhiata al codice sorgente di strace.

— Ben Voigt
fonte

Sì, ma come qualcuno ha detto, cosa succede se il programma è staticamente collegato?

— Ywen,

0

Se il programma di installazione utilizza una funzione di impacchettamento (vale a dire per i .debpacchetti per Debian / Ubuntu / ..., i .rpmpacchetti per RedHat / CentOS / ... ecc.), Il programma di installazione dei pacchetti dovrebbe sapere cosa fare all'installazione e alla rimozione. E credo che dovresti usare i sistemi di imballaggio esistenti , non inventarne uno tuo. (Linux convenzionalmente non ha programmi di installazione come Windows).

Se desideri davvero seguire le modifiche ai file apportate da un processo, puoi utilizzare straceo ltraceintercettare le chiamate di sistema. È inoltre possibile inotificare e strutture correlate.

Ma non so di un catch-modifs& revert-modifscome vuoi tu.

Suggerisco di non creare un programma di installazione per l'applicazione, ma di utilizzare il gestore pacchetti, quindi di fornire .deb(e / o .rpm) pacchetti per l'applicazione. Gestiranno i problemi di dipendenza meglio del proprio programma di installazione.

— Basile Starynkevitch
fonte

Sì, utilizzo apt-get sempre. Non stavo parlando delle mie applicazioni, ma di quelle non imballate. Non ho sempre un .deb a portata di mano.

Le applicazioni non pacchettizzate che menzioni dovrebbero documentare quali file usano e come dovrebbero essere installati.

^^ E se non lo facessero? Sapevo di poterli impacchettare da solo, ma non è semplice . Inoltre, tali comandi potrebbero essere utili per testare in modo più sicuro alcuni script di sistema creati.

Concordo sul fatto che il tuo desiderio sia interessante, ma non sono sicuro che sia facilmente realizzabile ....

0

Il modo più semplice per ottenere ciò che desideri: installa l'applicazione "non attendibile" in una nuovissima istanza di macchina virtuale (workstation VMWare, Oracle VirtualBox, ecc.).

Quando si decide che non si desidera più l'applicazione, eliminare la macchina virtuale.

Le altre alternative, ovvero la rilevazione dei syscall di accesso ai file, saranno probabilmente soggette a errori e incomplete. Prestare particolare attenzione a qualsiasi soluzione che richiede un collegamento dinamico per funzionare (come sembra che Installwatch faccia). Un installatore può legittimamente esercitare chiamate di sistema dirette o essere staticamente collegato.

Caspita, la macchina virtuale è decisamente eccessiva ... Devo solo salvare e fare il backup di alcuni file di configurazione in modo conveniente.

— Ywen,