Вопрос или проблема
Я создаю встроенную систему с использованием Buildroot. В настоящее время моя конфигурация Buildroot обеспечивает монтирование rootfs как доступного для чтения и записи во время запуска. Однако я хотел бы убрать эту функцию и оставить rootfs только для чтения.
У меня есть несколько вопросов по этому поводу:
Как изменить пароль пользователя? Это потребует изменения /etc/passwd и /etc/shadow.
Как изменить часовой пояс? Это потребует изменения /etc/localtime.
Как создать ssh-ключи для sshd? ssh-keygen создает ключи в /etc/ssh/.
Согласно Стандарту иерархии файловой системы, система Linux должна работать с каталогом /etc/ только для чтения, но, похоже, я сталкиваюсь с явной потерей функциональности, как описано выше.
Во-вторых, после того как я указал, что rootfs должен оставаться только для чтения в моей конфигурации Buildroot, он выбирает монтировать /var/ как tmpfs (в оперативной памяти, поэтому он доступен для записи).
Но это временно, как я могу гарантировать, что файлы во время выполнения (которые мне нужно сохранить) не будут потеряны при перезагрузке или неожиданной потере питания?
Я использую UBIFS в своей встроенной системе. Обязан ли я создавать том UBI для чтения и записи, который использую в качестве постоянного хранилища? Это стандарт для встроенных систем?
И наконец, стоит ли мне вообще переосмыслить свою идею использования rootfs только для чтения? Учитывая, что я использую UBI, и так как выравнивание износа реализовано для всех томов UBI (которые, конечно, находятся на одном устройстве), получу ли я какую-либо выгоду от того, чтобы сделать rootfs только для чтения?
Поддержание файловой системы в режиме только для чтения обеспечивает то, что ничего не изменяется неожиданным образом.
Для выполнения определенных операций необходимо работать с конкретными разделами файловой системы:
– Системный раздел: только для чтения
– Пользовательский раздел: доступен для записи
Потеря пользовательского раздела может лишь вернуть встроенное устройство к исходному состоянию, но не приведет к постоянной недоступности устройства.
Для выполнения определенных операций, например, изменения паролей, необходимо создать символические ссылки на конкретные файлы в пользовательском разделе.
– /etc/passwd -> /mnt/user/passwd
– /etc/ssh -> /mnt/user/ssh
– /etc/localtime -> /mnt/user/localtime
Чтобы сделать доступ к паролям более надежным, может быть хорошей идеей перенаправить passwd на tmpfs и затем получать пароль из пользовательского раздела во время запуска.
Такой подход может привести к проблемам с часовым поясом. Возможно, потребуется патчить tzdata, чтобы напрямую использовать /mnt/user/localtime, если двойная ссылка приводит к ошибке:
/etc/localtime -> /mnt/user/localtime -> /usr/share/zoneinfo …
Ответ или решение
Создание встроенной системы с использованием Buildroot и настройкой файловой системы как только для чтения — это разумный выбор для повышения устойчивости и безопасности вашей системы. Однако это также требует определенных архитектурных изменений для обеспечения необходимой функциональности. Давайте рассмотрим каждый из ваших вопросов по порядку.
1. Изменение пароля пользователя
Для изменения пароля пользователя, учитывая, что файловая система должна оставаться только для чтения, вам следует использовать пространственный подход. Вы можете настроить отдельный раздел для пользователя, который будет монтироваться в режиме записи. Например:
- Создайте раздел пользователя, который будет монтироваться в /mnt/user.
- Создайте символьные ссылки в вашей файловой системе, указав на файлы в разделе пользователя:
ln -s /mnt/user/passwd /etc/passwd ln -s /mnt/user/shadow /etc/shadow
При этом вы сможете изменять файлы, находящиеся в /mnt/user/passwd и /mnt/user/shadow, которые остаются доступными в режиме записи.
2. Изменение часового пояса
Подобно предыдущему пункту, чтобы изменить часовой пояс, создайте символьную ссылку на файл /etc/localtime, который находится на разделе пользователя:
ln -s /mnt/user/localtime /etc/localtimeЭто позволит вам обновлять часовой пояс без необходимости изменения файловой системы, монтируемой в режиме записи.
3. Создание SSH-ключей для sshd
Для генерации SSH-ключей можно использовать тот же подход. Создайте директорию для SSH-ключей на разделе пользователя:
/mnt/user/sshЗатем перенаправьте SSH-сервер на использование этой директории через символьные ссылки:
ln -s /mnt/user/ssh /etc/sshПри этом ключи, сгенерированные с помощью ssh-keygen, могут быть сохранены на разделе пользователя, что позволяет вам управлять ими без изменения корневой файловой системы.
4. Работа с временными файлами
Вы правы в том, что монтирование /var как tmpfs делает его временным. Чтобы обеспечить сохранность важных данных при перезагрузке или сбоях, рекомендуется создать дополнительный читаемый и записываемый UBI том. Этот том может использоваться для хранения важных файлов и данных.
Стандартный подход для встроенных систем включает в себя:
- Раздел для системы (только для чтения)
- Раздел для пользователя (только для записи)
- Место для хранения непостоянных данных на UBI-томе (перезапись происходит в пределах этой области)
5. Переоценка идеи использования read-only rootfs
Использование файловой системы только для чтения имеет свои преимущества, такие как увеличение безопасности и защита от неконтролируемых изменений. Если вы используете UBI с алгоритмами выравнивания износа, преимущества от использования только для чтения файловой системы могут быть менее выраженными. Однако это все еще зависит от специфики вашего применения.
Таким образом, решение: оставить файловую систему только для чтения – разумный выбор, если ваша архитектура позволяет избежать упомянутых выше недостатков. Обязательно подумайте о необходимости хранения переменных данных в читаемом и записываемом пространстве, чтобы ваша система оставалась функциональной и устойчивой.