LINUX.ORG.RU
решено ФорумAdmin

Cоздать образ с ПО и временно подключить его к rootfs другой системы?

 , ,


0

1

Добрый вечер. Возникла такая задача, буду рад получить совет хоть как к ней подступиться, так как идеи мои что-то кончились. Есть работающая серверная система, в нее вносить изменения нельзя (она может быть либо повреждена, либо смонтирована в «только чтение» либо другие вводные, которые не позволяют что-то в систему внести/исправить). Известно только то, что это будет Линукс х64, ну и если нужно - с поддержкой overlayfs, если необходимо. Нужно провести анализ такой системы, тестирование и прочее. Для этого соответствующее ПО нужно принести с собой, на внешнем носителе или еще как-то и подключить к rootfs исходной системы, не затрагивая ее состояние (то есть не меняя файлы, ничего не копируя и пр. При этом некоторые утилиты я контролирую (то есть могу собрать их так, чтобы они настройки хранили рядом, были статически собраны и пр.), а некоторые - проприентарные, то есть не могу про них ничего сказать заранее, нужно обеспечить им расположение данных в нужных каталогах и конфиги в дереве исходной системы (то есть той, в которой будет запуск). В этом и проблема: они ломятся по только им известным путям, что не позволяет их как-то заранее перенаправить.

То есть проблема вырисовывается такая: нужно смонтировать внешний носитель с ремонтными программами так, чтобы он «внедрился» в rootfs целевой системы (правильнее сказать объединился как в случае uninfs/overlayfs), утилиты заработали и можно было бы выполнить нужные действия, а в конце работ - без следов и главное - без изменения исходной системы (кроме того, что было выполнено утилитами - но это ладно, главное чтобы образ с ними ничего не убил) можно было бы извлечь и продолжить работать. Конечно, все легально и пароль от root/sudo есть, вопрос только в том, чтобы не предвнести в систему ничего лишнего/стороннего. Вплоть до того, чтобы за собой подчистить /tmp, но думаю это не проблема.

Посоветуйте, пожалуйста, в каком направлении копать. Что можно тут придумать для реализации подобного? Спасибо.


Ответ на: комментарий от firkax

При физическом доступе к консоли вопросы легальности уже можно не рассматривать.) Но да, тут как раз-таки все ок. Система просто на чипе и не даст rw доступа к себе, только в ОЗУ сформировать если диск и там что-то через tmpfs замутить. Это один вид систем. Другая - может быть сертифицированная система, где каждый файл имеет контрольную сумму и учтен во внешней системе. Третий тип систем - нужно собрать post-mortem инфу о том, что было. Достаточно случаев?) Не только же пароли красть)

AKENDO
() автор топика
Ответ на: комментарий от AKENDO

без изменения исходной системы (кроме того, что было выполнено утилитами

Как ты собрался что-то менять утилитами если там ro?

И почему чистку tmp упомянул?

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Разные системы и разные случаи. Все под нашим обслуживанием, во всех нужно что-то порой поправить, для этого собрали весь набор инструментов в кучу. Объединяет их только то, что вносить изменения на систему нельзя.

AKENDO
() автор топика

Можно было бы собрать комплект софта в PREFIX и подобрать чтобы софт был portable, но это надолго, и с проприетарными утилитами так пересобрать не выйдет.

Shushundr ★★★
()

Тут ничего не нужно придумывать, overlayfs как раз делает то что тебе нужно. Разве что тебе наверное нужно будет два исходных слоя и один rw слой. Но можно в принципе и одним обойтись. Просто поверх корня монтируешь через overlay свой каталог со всеми утилитами и всё что будет писаться после этого будет писаться на твой внешний носитель с утилитами.

Xenius ★★★★★
()
Ответ на: комментарий от firkax

Он не понимает. Нам остаётся только гадать, чего он не понимает.

«Persistent» - это теория. Ему нужно изучить эту теорию и знания применить в своей практике. В общих чертах, «persistent» - это «оверлей на всю систему». А при его знаниях, он скорее систему так угробит, что и перезагрузка не поможет.

andytux ★★★★★
()