У меня есть большое количество систем (100), которыми управляет небольшая группа людей, которые со временем менялись. Каждая система устанавливается с использованием базового образа (у которого есть своя собственная версия, которая различается в зависимости от возраста установки), который затем со временем настраивается (разветвляется) различными способами в соответствии с потребностями клиента.
У меня есть копия каждой версии установочного образа. Более 90% установочного образа в разных версиях одинаковы. Настройки обычно составляют менее 3%.
Мне нужно выяснить, какие версии установлены и какие настройки были внесены после установки.
Из-за ограничений пропускной способности я не могу создать сеть diff или rsync --dry-run по сети *.
Однако я предполагаю иметь возможность запускать сценарий для каждого установочного образа и отправлять его как базу данных в каждую систему для сравнения с ее собственной файловой системой и отчета - как «отпечаток пальца», если хотите.
«Отпечаток пальца» (дерево файловой системы + контрольная сумма для каждого файла и папки) будет ограничен набором файлов, который можно изменить (а не /proc, /sys, /tmp, трубы, розетки и т. д.).
«Отпечаток пальца» не может быть MD5 файловой системы, потому что одно изменение приведет к другому «отпечатку пальца», и мы не можем быть уверены, какие файлы могли быть настроены.
Я ищу утилиту, которая сообщит 2 вещи:
Кроме того, было бы хорошо, если бы я мог создавать новые базы данных из существующих, чтобы я мог брать информацию из настроек для создания новых версий (например, Версия 2.0.3-withmodX).
Я рассмотрел:
Я мог бы, возможно, использовать git каким-то образом создать базу данных '.git' файловой системы, а затем отправить несколько баз данных .git для сравнения, затем:
git status lines = version.git status вывод против версии = настройки.Есть ли такая утилита "отпечатка пальца" для файловых систем или есть какая-нибудь утилита, которая упростит ее сборку?
* хотя мне интересно, если rsync может выводить базу данных метаинформации, которую можно легко использовать для создания такого инструмента.
Вы хотите описать происхождение сотен образов дисков, выявить произвольные нечеткие изменения и ограничена ли пропускная способность? Сложно.
Ранее при сбое сервера сравнение образов дисков поднял cmp и rsync. Я добавлю virt-diff, и VCS (вероятно, git). Ни один из них вам не понравится.
Контрольная сумма образа диска (sha256sum, md5sum) вы сбрасываете со счетов, поскольку хотите узнать разницу в файлах. По-прежнему будет полезным идентификатором изображения, если вы определите, какое именно изображение вам нужно.
UUID и любая метка в файловой системе видны с lsblk --fs. Полезно для определения происхождения, но не для каких-либо изменений. Однако я готов поспорить, что ни один из них не был изменен при установке системы.
cmp в образах дисков происходит побайтовое сравнение файловой системы. Вы не увидите различий на уровне файлов. Такие незначительные изменения, как отток в / tmp, сделают каждое изображение другим.
rsync в смонтированных файловых системах будут отображаться измененные файлы. Он также будет выполнять глупое количество операций ввода-вывода, типичная корневая файловая система Linux будет иметь сотни тысяч inode. У вас нет IOPS, чтобы найти дельту с сотнями других файловых систем, а не с используемыми системами.
virt-diff найдет различия в файлах в образах дисков. Вы могли бы сослаться на неиспользуемый образ диска или моментальный снимок, например полную резервную копию на вторичном сервере. Это резервное копирование ограничено пропускной способностью, а не IOPS. Однако вы сказали, что ваша пропускная способность ограничена.
VCs нравится git не предназначены для сохранения произвольных системных файлов, включая разрешения и специальные файлы. у etckeeper есть хаки для этого. VCS также менее полезны, когда происхождение неизвестно, их структуры данных соответствуют тому, как пользователь разветвился.
Вы можете создать отчет о дедупликации для произвольных объектов в репозиториях git с помощью глядя на файлы пакетов. Проблемы здесь - инструменты и масштаб. verify-pack - это команда сантехники низкого уровня, которую нелегко использовать для этой цели. Выполнение этого на уровне файла будет анализировать миллионы больших двоичных объектов, не масштабируемых. Даже если посмотреть, как упаковываются образы дисков в виде больших двоичных объектов, это замедлит работу.
Я предлагаю забыть автоматический сценарий и попросить человека сделать это.
Определите полезные изображения из базовых и настроенных. Примеры использования, которые стоит оставить в качестве базовых изображений.
Установите и задокументируйте на них уникальные идентификаторы UUID и метки. Контрольная сумма и архив изображений для будущего использования.
Не связаны напрямую, но в будущем попробуйте разделить состояние системного пакета и пользовательские данные.
Рассмотрим корень, доступный только для чтения, с конфигурацией и данными из разных файловых систем или наложений. Возможно / home на NFS или / tmp на tmpfs. Базовое изображение легко идентифицировать, так как оно остается нетронутым. Внесение изменений в образ может быть определенным процессом: монтирование r / w, внесение изменений, снимок.