- Вопрос или проблема
- Ответ или решение
- 1. Использование временных единиц (Transient Units)
- Пример реализации:
- 2. Создание генераторов (Generators)
- Пример создания генератора:
- 3. Перенаправление каталогов wants на изменяемую часть файловой системы
- Процесс настройки:
- 4. Управление через файлы конфигурации
- Заключение
Вопрос или проблема
Я ищу стратегии управления включением и отключением сервисов systemd на файловой системе только для чтения. Это невозможно, так как содержимое директории multi-user.target.wants изменяется.
Сохраняя /etc/systemd/system в качестве места по умолчанию для сервисов, пробовал ли кто-то найти способы управления запуском ‘таблицы’ / multi-user.target.wants так, чтобы приложение или скрипт, выполняющийся на этой цели, могли все равно включать или отключать конкретный сервис (или сервисы), даже если файловая система является RO?
Я подумал о создании символической ссылки на директорию multi-user.target.wants в одном из небольших rw “конфигурационных” разделов и переключении между предустановленными директориями multi-user.target.wants при загрузке/перезагрузке в зависимости от необходимости. В качестве альтернативы, я предполагаю, что скрипт или приложение могли бы напрямую изменять это место с символической ссылкой, добавляя или удаляя записи из него.
Я еще не тестировал это; хотел узнать, есть ли у кого-то опыт с этим, возможные стратегии или знают ли о более стандартизированном подходе к этому? Спасибо.
Это не полный ответ, но слишком много деталей для комментария.
Чтобы внести изменения, вам нужен доступ на запись к этой файловой системе. Я предполагаю, что у вас сейчас есть доступ на запись, но вы хотите заблокировать его в режиме только для чтения, оставаясь при этом в состоянии вносить такие изменения позже.
systemd будет искать пути к юнитам в нескольких местах в /run, которые не будут только для чтения. Возможно, у вас есть возможность загрузить сервис очень рано и создать/отредактировать некоторые юниты в одном из этих путей загрузки:
Ссылка: https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20File%20Load%20Path
| Путь | Описание |
|---|---|
| /etc/systemd/system.control | Постоянная и временная конфигурация, созданная с использованием API dbus |
| /run/systemd/system.control | “ |
| /run/systemd/transient | Динамическая конфигурация для временных юнитов |
| /run/systemd/generator.early | Сгенерированные юниты с высоким приоритетом (см. early-dir в systemd.generator(7)) |
| /etc/systemd/system | Системные юниты, созданные администратором |
| /run/systemd/system | Юниты времени выполнения |
| /run/systemd/generator | Сгенерированные юниты со средним приоритетом (см. normal-dir в systemd.generator(7)) |
| /usr/local/lib/systemd/system | Системные юниты, установленные администратором |
| /usr/lib/systemd/system | Системные юниты, установленные менеджером пакетов дистрибутива |
| /run/systemd/generator.late | Сгенерированные юниты с низким приоритетом (см. late-dir в systemd.generator(7)) |
Возможно, вам удастся написать приложение, которое будет работать очень рано во время загрузки и подключаться к сокету вашего командного центра, получать инструкции для юнитов, а затем использовать API dbus для создания юнитов в /run/systemd/system.control
Другой вариант – написать генератор. Смотрите systemd.generator(7) для подробностей. Генераторы – это программы, которые выполняются systemd рано в процессе загрузки (до загрузки юнит-файлов). Ожидается, что эти генераторы создадут юнит-файлы, файлы “запусков” или символические ссылки в таких местах, как /run/systemd/generator/. Это будет вне вашей файловой системы только для чтения.
Примером генератора является systemd-fstab-generator, который читает /etc/fstab и генерирует нативные системные юниты *.mount.
Ответ или решение
Управление системными службами systemd на файловой системе только для чтения представляет собой серьезный вызов, особенно когда речь идет о необходимости включения и отключения служб при жестком ограничении прав доступа. Рассмотрим несколько стратегий, которые помогут в этой задаче.
1. Использование временных единиц (Transient Units)
Системные единицы могут быть созданы динамически в директории /run/systemd/transient, которая доступна для записи во время выполнения. Для этого можно использовать D-Bus API для создания и управления временными единицами на лету. Программа или скрипт, который запускается на ранних этапах загрузки, могут подключаться к D-Bus и регистрировать нужные службы.
Пример реализации:
dbus-send --system --print-reply --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1/system org.freedesktop.systemd1.Manager.StartUnit string:"имя_единицы.service" string:"replace"2. Создание генераторов (Generators)
Генераторы — это программы, которые выполняются systemd на ранних этапах загрузки и могут генерировать новые единицы или изменять существующие на основе определенных условий. Вы можете создать генератор, который будет проверять условия и создавать символьные ссылки в директории /run/systemd/generator, таким образом определяя, какие службы будут активированы.
Пример создания генератора:
- Создайте скрипт, который будет генерировать необходимую конфигурацию.
- Поместите его в директорию
/etc/systemd/generator, чтобы он выполнялся при загрузке.
3. Перенаправление каталогов wants на изменяемую часть файловой системы
Ваше предложение о создании отдельного "конфигурационного" раздела, который будет доступен для записи, выглядит разумно. Вы можете создать символическую ссылку на /etc/systemd/system/multi-user.target.wants, указывающую на местоположение в вашем RW-разделе. Это позволит изменять содержимое целевых «wants» без изменения RO файловой системы.
Процесс настройки:
- Создайте RW-раздел и подготовьте в нем нужные директивы службы.
- Создайте символическую ссылку:
ln -s /mnt/rw-config/multi-user.target.wants /etc/systemd/system/multi-user.target.wants
4. Управление через файлы конфигурации
Если ваша система подразумевает возможность редактирования конфигураций через SSH или другой доступ, можно реализовать систему управления, которая будет менять конфигурационные файлы, активируя или деактивируя нужные службы. Это может быть сделано с помощью скриптов, которые переписывают файлы конфигурации на монтируемом RW-разделе.
Заключение
Несмотря на сложности, которые может создать файловая система только для чтения, использование D-Bus API, создание генераторов и перенаправление необходимой конфигурации в RW-раздел предоставляет гибкие решения для управления системными службами systemd. Важно помнить о безопасности и целостности системы при реализации этих стратегий, а также тщательно тестировать каждое решение в безопасной среде перед развертыванием на боевом сервере.