Linuxでプログラムによって行われたファイルシステムの変更を追跡、保存、および元に戻す


9

インストーラーなどのプログラムが実行されたときに、ファイルシステムに加えられた変更のリストを追跡して、後で元に戻すことができるようにしたいと思います。

編集:これはパッケージ化されていないプログラムに関係します。できる限りapt-getを使用しています。

理想的には、次のようなことができるようになりたいです。

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

その後:

(sudo) revert-modifs fsmodifs.patch

それを行う便利な方法はありますか?

回答:


1

おそらくこれを行う最も簡単な(?)方法は、「永続的なデータパーティション」を持つLiveUSBから起動することです。(または、効果を自分で再現するには、chroot刑務所で、roレイヤーの上にrwレイヤーをマウントします。)rwファイルシステムのスナップショットを取得します-これは、新規ブート後に非常にスリムになるはずです。その後、インストーラーを実行します。それが変更または作成するすべてのファイルは、rwの「永続データ」オーバーレイパーティションにあります。削除されたファイルも「マジックドットファイル」として表示されます。


これは複雑に見えます...新しいパーティションを作成し、古いパーティションをROにマウントして、RWに新しいパーティションをマウントすることはできませんか?
Ywen

はい、シングルユーザーモードからも可能です。見てくださいunionfs—基本的に、RWファイルシステムはすべての書き込みを受け入れますが、ROファイルシステムはまだその下に表示されています。ファイルが変更されると、RW fsに「移行」します。削除された場合、実際には、RW fsに「マスク」するための「マジックドットファイル」があります。セットアップunionfsは少し面倒かもしれませんが、私がLiveUSBを提案したのはそのためです(この部分はあなたのために行われ、「クリーン」なシステムイメージが最初から始まります)
BRPocock

2

たぶんtripwireを見てみませんか?Tripwireはアクティブな例よりもパッシブですが、それでも機能する場合があります。

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

Tripwireは侵入検知システム(IDS)であり、クラッカーによって(または誤って)破壊または変更された場合に、重要なシステムファイルとレポートを常に自動的に管理します。これにより、システム管理者は何が危険にさらされたかを即座に把握して修正できます。


1

「CheckInstall」ですか?makefileがない場合でも機能しますか?私の場合(Eclim)、インストールはjarインストーラーを介して行われました。

いいえ、CheckInstallの一部であるInstallwatchを意味します。
qerub

「Installwatchは、動的にリンクされたすべてのELFプログラムで機能し、ファイルシステムの変更を引き起こすシステムコールをオーバーライドします。そのようなシステムコールの一部は、open(2)およびunlink(2)です。」JVMで正常に動作するはずです。
qerub

はい、しかしどうやらInstallwatch だけでは長い間メンテナンスされていません。さらに、InstallWatchログを元に戻すには、CheckInstallが必要です。私はまだ見る必要があります。ありがとう。

1

ライブラリー関数LD_PRELOADをインターセプトしopenてパス名を変更するライブラリーをロードするために使用します/出力をログに記録します/ファイルを開く前にバックアップを作成します

のソースコードをご覧くださいstrace


はい、しかし誰かが言ったように、プログラムが静的にリンクされている場合はどうなりますか?
Ywen、2011

0

インストーラーがパッケージ機能(.debDebian / Ubuntu / ...の.rpmパッケージ、RedHat / CentOS / ...のパッケージなど)を使用している場合、パッケージインストーラーはインストール時と削除時の処理を知っている必要があります。また、独自のパッケージングシステムを発明するのではなく、既存のパッケージングシステム使用する必要があると思います。(通常、LinuxにはWindowsのようなインストーラーはありません)。

何らかのプロセスで行われたファイルの変更を本当に追跡したい場合は、を使用straceしたりltrace、システムコールをキャッチしたりできます。また、関連施設をinotifyすることもできます。

しかし、私はあなたが望むようなcatch-modifs&を知りrevert-modifsません。

私はあなたのアプリケーションのためのインストーラをしないことをお勧めしますが、提供するため、パッケージマネージャを使用する.deb(および/または.rpmアプリケーションのパッケージ)。依存関係の問題は、独自のインストーラーよりも適切に処理されます。


はい、常にapt-getを使用しています。私は自分のアプリケーションではなく、パッケージ化されていないアプリケーションについて話していました。常に.debが手元にあるとは限りません。

言及するパッケージ化されていないアプリケーションは、それらが使用するファイルとそれらのインストール方法を文書化する必要があります。

^^そうでない場合はどうなりますか?自分でパッケージできることは知っていましたが、簡単ではありません。さらに、このようなコマンドは、作成したシステムスクリプトをより安全な方法でテストするのに役立ちます。

....私はあなたの願いが面白いであることに同意、それが簡単に実現可能であるならば、私はわからない

0

希望するものを簡単に実現する方法:「信頼できない」アプリケーションを新しい仮想マシンインスタンス(VMWareワークステーション、Oracle VirtualBoxなど)にインストールします。

アプリケーションが不要になった場合は、仮想マシンを削除します。

他の代替手段-ファイルアクセスシステムコールのキャッチ-は、エラーが発生しやすく、不完全になる可能性があります。機能するために動的リンクを必要とするソリューションには特に注意してください(Installwatchのように見える)。インストーラは、直接システムコールを合法的に実行したり、静的にリンクしたりできます。


うわー、仮想マシンは間違いなくやりすぎです...いくつかの構成ファイルを便利な方法で保存してバックアップするだけです。
Ywen
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.