Есть чем развернуть копию ванильного дистрибутива линукс?

Опять мухоморов переели?

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

они там что, образы просто предлагают, которые надо своевременно самому обновлять? универсального решения устанавливать свежую систему «на лету» не придумали?

Есть чем развернуть копию ванильного дистрибутива линукс?

развернуть ванильную копию свежеустановленной системы в условное chroot окружение

LXC/LXD

Существует ли в природе инструмент, чтобы в любом дистрибутиве развернуть ванильную копию свежеустановленной системы в условное chroot окружение?

docker, podman

А может есть универсальный враппер над всеми этими pacstrap, debootstrap, dnf –installroot, и что там ещё в природе есть… При чём, инструмент повторюсь, должен быть универсальным и работать на любом дистрибутиве.

ansible пытается быть

Хочу одной командой разворачивать копию свежей системы, настраивать, и одной командой заворачивать в загрузочный iso, initrd и т.д… С последней частью проблем нет. Думаю над решением первого пунктика.

Реши неуниверсально, а еще лучше остановись и спроси себя «накой».

Разверните мысль про ванильную систему. Что вы подразумеваете под этим термином?

ванильный софт == софт поставляемый «как есть», без малейших изменений.

зачастую это невозможно т.к. не патченный софт просто не будет работать, ведь в каждом дистрибутиве своя экосистема, где-то файлики лежат в /usr/lib, где-то в /lib, а в программе там пути захардкодены, и это ещё лайтовый вариант развития событий, изменить пути распополжения файлов в системе под конкретный софт.

в контексте дистрибутива, я говорю о системе, которая была только что установлена. и ничего, возможно даже пароль root не установлен. так.

я занимаюсь сборкой серверов hp/dell и мне надо наклепать дистрибутивов под разные задачи, стресс-тестирование и прожарка процессоров, памяти, дисков.

всего за месяц я уже навидался, когда процессор успешно проходит тест linpack'ом, но делаешь kill -9 $(pgrep runme_xeon64) и сервер уходит в ребут.

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

когда засираешь всю память /dev/urandom, думаешь всё ОК, сервер уходит клиенту, а клиент говорит — одна планка дефектная, плохо зделоли, поменяйте. и я такой fuuuu.

каждое утро уже начинается с матюков, когда в твоих руках сервак просто душка, но уходит к клиенту и начинааается.

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

я занимаюсь сборкой серверов hp/dell и мне надо наклепать дистрибутивов под разные задачи, стресс-тестирование и прожарка процессоров, памяти, дисков.

Ты занимаешься натягиванием совы на любимый глобус в рабочее время.

Берешь 10 готовых isoшек разных дистров с cloud-init, который поставит и запустит прожариватель. Все.

hp/dell

Там есть ilo/idrac, которые пишут причину зависания/перезагрузки.

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

stress + memtester работают на всех дистрибутивах одинаково.

пишут причину зависания/перезагрузки

они пишут только о явно неисправных комлпектующих, что тоже прекрасно, но повторюсь, все остальные случаи неисправности простое информирование в System Health не охватывает никак.

тесты делать надо.

stress + memtester

гляну спасибо

нагружать сервер реальными рабочими задачами, далёкими от синтетических тестов

Лимиты батюшка, лимиты. Если руки развязаны любую систему положить можно.

cloud-init это такой аналог curl http://.../rootkit.sh | bash?

запускаешь исошник с дистрибутивом на котором установлен cloud-init, и оно с какого-то местечкового ресурса выполняет init-скрипт, который задаёт настройки всей системе?

и в этом cloud-init уже централизовано хранятся все настройки, выполняется т.н. «оркестрация» загружаемых систем?

ладно, молодцы, нормально сделали, посмотрим.

но с тем же успехом я мог бы и сам уже готовые исошники собрать с необходимым содержимым, без надобности подсасываться куда-то в cloud-init.

Ну ХЗ, я в своё время из тарбола разворачивал, полёт нормальный. Но возможно задачи сильно отличались.

Может чего то не понимаю?

Берешь диск 500GB. На нем 1001 дистрибутив установлен. Запускаешь первую операционную систему. Она уже настроена для тестов. Запускаешь сценарий, который тоже настроен. Оно отрабатывает. Смотришь, все в порядке. Перезагружаешь сервер в операционную систему номер два. Она на этом же диске 500GB, и тоже настроена для тестов. Запустил сценарий. Отработало. И так прогоняются все операционные системы со всеми сценариями.

Если надо одновременно тестировать 10 серверов, значит и дисков таких 10 штук. Бери и тестируй одновременно 10 серверов.

Исошки собрать невелика проблема, проблема

естственно всё это обновлять и поддерживать в актуальном состоянии.

cloud-init спасает то этого, но сдается мне, это то, что тебе интересно как раз это, а остальное лишь повод. Не виню, сам местами грешен.

мог бы и сам уже готовые исошники собрать с необходимым содержимым, без надобности подсасываться куда-то в cloud-init.

этот файл необязательно через http грузить, можно, ЕМНИП, внешним носителем дать или в исошку вшить.

На нем 1001 дистрибутив установлен.

И не обновлен. А можно проще, не обновляя и не устанавливая.