Мне нужно узнать обо всех изменениях файловой системы, внесенных установщиком. Скорее всего, установленный пакет - это rpm или deb, но приложение, конечно, можно просто скопировать или скомпилировать и установить с помощью способа configure; make; make install. Несмотря на то, что в rpm и deb есть списки файлов, их сценарии после установки могут вносить дополнительные изменения в файловую систему.
Сначала я искал приложение, которое могло бы отслеживать другое приложение, чтобы найти все изменения файловой системы, сделанные другим приложением. Я не нашел.
Затем я изучил многоуровневые файловые системы, думая, что перед тем, как начать установку приложения, я бы поместил многоуровневую файловую систему, а затем установил приложение в многоуровневой файловой системе, а затем выяснил все модификации, которые произошли на уровне. Лучшее, что я мог найти, было mini_fo но, похоже, он не поддерживается с 2006 года. Также не похоже, что его можно просто наложить на / (это скрывает некоторые вещи от слоя).
Затем я изучил решения на основе inotify, но, похоже, это непрактично для мониторинга всего, что начинается с /. Например, inotifywatch (linux.die.net/man/1/inotifywatch) по умолчанию упоминает ограничение на количество часов всего 8 КБ. Также требуется некоторое время для установки наблюдателей. Также появляются ошибки, при которых вновь созданные каталоги не отслеживаются немедленно, поэтому изменения в них можно пропустить.
Есть ли другой способ добиться того, что я хочу делать, помимо создания снимков файловой системы до и после установки и сравнения?
На этот вопрос уже был дан ответ, но я все равно добавлю то, что делаю. Если все, что вам нужно, это посмотреть, были ли файлы созданы, удалены или изменены, вы можете сделать это:
find / -xdev -printf '%p\t%c\n' |sort >/tmp/before
rpm/dpkg/apt-get/yum/whatever
find / -xdev -printf '%p\t%c\n' |sort >/tmp/after
diff -u /tmp/before /tmp/after |less
Вот и все. Он явно не скажет вам, как файл был изменен, но, по крайней мере, вы будете знать, что он каким-то образом изменился.
У меня возникнет соблазн попробовать запустить вашу установку через Strace. Это будет немного шумно, но вы, помимо всего прочего, регистрируете, вы должны видеть все, что написано.
Вот команда, которая, кажется, почти без лишнего шума показывает все обращения к файлам во время установки.
sudo strace -o /tmp/install.log -f -e trace=file apt-get install package
Что касается RPM, вы можете получить список файлов, установленных пакетом, выполнив следующую команду:
rpm -ql <package_name>
Если тебе нужно знать перед их установкой, вы можете использовать следующие однострочники, в которых будет перечислено содержимое пакетов.
Для Об / мин (требуется rpm2cpio & cpio команды):
rpm2cpio <package>.rpm | cpio -vt
Для DEB (требуется ar & tar команды):
ar p <package>.deb data.tar.gz | tar zt
Вся приведенная выше информация была взята из http://www.g-loaded.eu/2008/01/28/how-to-extract-rpm-or-deb-packages/ В обоих случаях вы получите список файлов, которые будут установлены. Дополнительные файлы могут быть созданы с помощью сценариев до и после установки, которые включают эти пакеты. Перечислить эти файлы невозможно.
Вы можете проверить installwatch: http://www.asic-linux.com.mx/~izto/checkinstall/installwatch.html и проверьте установку: http://asic-linux.com.mx/~izto/checkinstall/ . Обе очень простые утилиты для определения того, что на самом деле затрагивает процесс установки.
При этом находка Джеффа | Команда sort - хорошая идея, но может быть немного "громоздкой", поскольку она просто вручную дважды проверяет все файлы на машине.
Вопрос старый, и ответы на него нужно обновить.
Решение 1: Используйте контейнер или виртуальную машину и сделайте разницу с базовым образом.
Решение 2: Используйте auditd
Решение 3: Использование systemtap и контролировать все файлы, открытые для записи. Видеть: https://sourceware.org/systemtap/examples/lwtools/opensnoop-nd.stp
stap -e 'probe begin{ printf("%6s %6s %16s %4s %s\n", "UID", "PID", "COMM", "FD", "PATH");} probe nd_syscall.open.return{ printf("%6d %6d %16s %4d %s\n", uid(), pid(), execname(),returnval(), user_string(@entry(pointer_arg(1))));}'
Решение 4: Использование strace или ltrace как упоминал @Zoredache.