У меня есть большое количество систем (100), которыми управляет небольшая группа людей, которые со временем менялись. Каждая система установлена используя базовый образ (у которого есть своя собственная версия, которая различается в зависимости от возраста установки), который затем со временем настраивается (разветвляется) различными способами в соответствии с потребностями клиента.
У меня есть копия каждого версия установочного образа. Более 90% установочного образа одинаковы между версиями. Настройки обычно составляют менее 3%.
Мне нужно выяснить, какие версии установлены и какие настройки были сделаны с момента установки.
Из-за ограничений полосы пропускания я не могу выполнить сеть diff
или rsync --dry-run
по сети *.
Однако я предполагаю, что смогу запустить сценарий для каждого установочного образа и отправить его как базу данных в каждую систему для сравнения с ее собственными файлами. tem и доложите - как «отпечаток пальца», если хотите.
«Отпечаток пальца» (дерево файловой системы + контрольная сумма для каждого файла и папки) будет ограничен набором файлов, который можно изменить (а не / proc
, / sys
, / tmp
, каналы, сокеты и т. Д.).
«Отпечаток пальца» не может быть MD5 файловой системы, потому что одно изменение приведет к получению другого отпечатка пальца, и мы не можем быть уверены, какие файлы могли быть настроены.
Я ищу утилиту, которая сообщит о двух вещах:
Кроме того, это было бы хорошо, если бы я мог создавать новые базы данных из существующих, чтобы я мог брать информацию из настроек для создания новых версий (например, Версия 2.0.3-withmodX).
Я рассмотрел:
Я мог бы, возможно, использовать git
каким-то образом, чтобы создать базу данных '.git' файловой системы, а затем отправить несколько баз данных .git для сравнения, затем:
git status
строк = версия. git status
вывод против version = customisations. Существует ли такая утилита для создания отпечатков пальцев для файловых систем или какая-то утилита, которая упростит ее сборку?
* хотя мне интересно, rsync
может выводить базу данных метаинформации, которую можно легко использовать для создания такого инструмента.
Вы хотите описать происхождение сотен образов дисков, идентифицировать произвольные нечеткие изменения и ограничена ли полоса пропускания? Сложно.
Ранее при сбое сервера при сравнении образов дисков вызывались 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, вносить изменения, снимок.