Как отпечаток (евклидово расстояние) файловой системы на linux?

У меня есть большое количество систем (100), которыми управляет небольшая группа людей, которые со временем менялись. Каждая система установлена используя базовый образ (у которого есть своя собственная версия, которая различается в зависимости от возраста установки), который затем со временем настраивается (разветвляется) различными способами в соответствии с потребностями клиента.

У меня есть копия каждого версия установочного образа. Более 90% установочного образа одинаковы между версиями. Настройки обычно составляют менее 3%.

Мне нужно выяснить, какие версии установлены и какие настройки были сделаны с момента установки.

Из-за ограничений полосы пропускания я не могу выполнить сеть diff или rsync --dry-run по сети *.

Однако я предполагаю, что смогу запустить сценарий для каждого установочного образа и отправить его как базу данных в каждую систему для сравнения с ее собственными файлами. tem и доложите - как «отпечаток пальца», если хотите.

«Отпечаток пальца» (дерево файловой системы + контрольная сумма для каждого файла и папки) будет ограничен набором файлов, который можно изменить (а не / proc , / sys , / tmp , каналы, сокеты и т. Д.).

«Отпечаток пальца» не может быть MD5 файловой системы, потому что одно изменение приведет к получению другого отпечатка пальца, и мы не можем быть уверены, какие файлы могли быть настроены.

Я ищу утилиту, которая сообщит о двух вещах:

  1. Предложить, какая версия лучше всего соответствует файловой системе в ее нынешнем виде. база данных «отпечатков пальцев» файловой системы (метаданные древовидной структуры + контрольная сумма файлов и папок) и
  2. Список файлов / папок, которые были изменены (настроены) по сравнению с этой версией, включая новые файлы и удаленные файлы.

Кроме того, это было бы хорошо, если бы я мог создавать новые базы данных из существующих, чтобы я мог брать информацию из настроек для создания новых версий (например, Версия 2.0.3-withmodX).

Я рассмотрел:

  • Утилиты резервного копирования - они предполагают, что версии имеют линейную прогрессию 1: 1 для каждого клиента
  • Системы управления изображениями - обычно предполагают, что изображения отправляются на сервер- > клиент только с известной настройкой (например, новые файлы, определенные папки конфигурации), где нам нужна информация, где клиент (база данных ссылок) -> сервер.

Я мог бы, возможно, использовать git каким-то образом, чтобы создать базу данных '.git' файловой системы, а затем отправить несколько баз данных .git для сравнения, затем:

  1. Наименьшее количество git status строк = версия.
  2. git status вывод против version = customisations.

Существует ли такая утилита для создания отпечатков пальцев для файловых систем или какая-то утилита, которая упростит ее сборку?

* хотя мне интересно, rsync может выводить базу данных метаинформации, которую можно легко использовать для создания такого инструмента.

1
задан 16 October 2019 в 03:27
1 ответ

Вы хотите описать происхождение сотен образов дисков, идентифицировать произвольные нечеткие изменения и ограничена ли полоса пропускания? Сложно.

Ранее при сбое сервера при сравнении образов дисков вызывались cmp и rsync . Я добавлю virt-diff и VCS (возможно, git). Ни один из них вам не понравится.

Контрольная сумма образа диска ( sha256sum , md5sum ) вы сбрасываете со счетов, поскольку хотите узнать разницу в файлах. По-прежнему будет полезным идентификатором изображения, если вы определите, какое именно изображение вам нужно.

UUID и любая метка в файловой системе видны с помощью lsblk --fs . Полезно для определения происхождения, но не для каких-либо изменений. Тем не менее, я готов поспорить, что ни один из них не был изменен при установке системы.

cmp в образах дисков представляет собой сравнение файловой системы в байтах. Вы не увидите различий на уровне файлов. Такие незначительные изменения, как добавление / tmp, сделают каждый образ другим.

rsync в смонтированных файловых системах покажет измененные файлы. Он также будет выполнять глупое количество операций ввода-вывода, типичная корневая файловая система Linux будет иметь сотни тысяч inodes. У вас нет количества операций ввода-вывода в секунду, чтобы найти дельту с сотнями других файловых систем, а не с используемыми системами.

virt-diff найдет различия в файлах в образах дисков. Вы бы сослались на образ диска или снимок, который не используется,например, полная резервная копия на вторичном сервере. Это резервное копирование ограничено пропускной способностью, а не IOPS. Однако вы сказали, что ваша пропускная способность ограничена.

VCS, такие как git , не предназначены для сохранения произвольных системных файлов, включая разрешения и специальные файлы. etckeeper имеет для этого хаки . VCS также менее полезны, когда происхождение неизвестно, их структуры данных следуют за тем, как пользователь разветвился.

Вы можете составить отчет о дедупликации для произвольных объектов в репозиториях git, просмотрев файлы пакетов . Проблемы здесь - инструменты и масштаб. verify-pack - это команда нижнего уровня, которую нелегко использовать для этой цели. Выполнение этого на уровне файла будет анализировать миллионы больших двоичных объектов, без возможности масштабирования. Даже глядя на то, как образы дисков упаковываются как капли, замедлится.


Я предлагаю забыть автоматический сценарий и попросить человека сделать это.

Определите полезные образы из базовых и настроенных. Примеры использования, которые стоит оставить в качестве базовых изображений.

Установите и задокументируйте для них уникальные UUID и метки. Контрольная сумма и архив изображений для использования в будущем.


Не имеет прямого отношения, но в будущем попробуйте разделить состояние системного пакета и пользовательские данные.

Рассмотрим корень, доступный только для чтения, с конфигурацией и данными из разных файловых систем или наложений. Возможно, / home на NFS или / tmp на tmpfs. Базовое изображение легко идентифицировать, так как оно остается нетронутым. Внесение изменений в образ может быть определенным процессом: монтировать r / w, вносить изменения, снимок.

2
ответ дан 3 December 2019 в 20:05

Теги

Похожие вопросы