Существует два основных подхода.

Компиляция -конфигурации времени

Этот подход используют многие упаковщики программного обеспечения.

Используются макросы. Во время создания пакета некоторая форма препроцессора макросов запускается над файлом сервисной единицы, состоящим из макроса -, с параметрами, которые представляют конфигурацию. Результат, который затем помещается в пакет, представляет собой адаптированный файл сервисного модуля.

Пример есть в самом systemd. Файлkmod-static-nodes.service.inсодержит макросы:

ExecStart=@KMOD@ static-nodes --format=tmpfiles --output=/run/tmpfiles.d/static-nodes.conf

Большая коллекция Python-скриптов для сборки systemd (под названием «Meson» )содержит среди прочего препроцессор макросов на основе регулярных -выражений -. Этот препроцессор запускается на kmod-static-nodes.service.in, заменяя макрос KMODдля создания kmod-static-nodes.service, который входит в пакет. Замена представляет собой строку, которая представляет собой путь к файлу образа исполняемой программы kmod, который ищется во время компиляции сценариями Python. (Я не буду вдаваться в подробности большой системы скриптов Python, так как это выходит за рамки данного ответа.)

Недостаток этой схемы заключается в том, что необходимо создавать пакет на машине, которая организована таким же образом и содержит те же программы, что и целевая машина, на которой установлен пакет. Пакеты каждой операционной системы могут отличаться (даже от версии к версии ).

Установить -конфигурацию времени

падение -дюймы

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

Например, :В файле статического сервисного модуля /usr/lib/systemd/system/wibble.serviceможет быть указано

ExecStart=/usr/bin/wibble $OPTIONS

Сценарий обслуживания пакета для действия install , затем создает файл /usr/lib/systemd/system/wibble.service.d/20-options.confна fly во время установки, содержащий настроенные параметры, рассчитанные на текущей машине во время установки, а не на другой машине во время создания пакета:

Environment=OPTIONS=wobble --jelly -o plate

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

предварительная обработка

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

Если вы вообще не создаете пакет, а просто отправляете все в архиве ustar, чтобы системные администраторы могли установить его вручную, это более удобно, чем сгенерированные дроп -ins.

Недостатком этого является то, что системы предварительной обработки макросов, подобные той, что используется в Meson, тесно связаны с коллекцией скриптов Python и недоступны как отдельные инструменты. Для автономных инструментов предварительной обработки есть подобные m4, cppи другие, ни один из которых не подходит для предварительной -обработки файлов.INI и принятия решений (, например. «Определить, какие параметры программа wibbleпринимает на этом компьютере». "Где kmodна этой машине?" ), которые обычно вовлечены.

Очевидно, здесь есть ниша для инструмента, который никто -не замечал — о котором я, во всяком случае, слышал.

Можно отсортировать -или обойтись с помощьюcommand -vдля поиска пути иexдля замены в сценарии оболочки;но это не -тривиально для (, и большинство людей )не защищают это от таких вещей, как пробелы и метасимволы в именах путей, или допускают механизм экранирования для предотвращения раскрытия макроса там, где это нежелательно.

Perl обеспечивает несколько более безопасную обработку строк, чем сценарий оболочки, но не каждая операционная система имеет встроенный Perl (c.f. " Существует ли unix-подобная -система, которая не поставляется с Perl? " ), что требует указания системным администраторам убедиться, что сначала установлен Perl. Python, очевидно, может это сделать, учитывая большую систему сборки Python-скриптов systemd. Но тогда есть проблема системных администраторов, которые меняют версию Python на вас и выбивают почву из-под вас (c.f. «apt -get update больше не работает после восстановления поврежденной переменной PATH », и все вопросы Ask Ubuntu связаны гиперссылками -на ). Другие возможности включают TCL.

На хватающей руке…

Иногда такая конфигурируемость вообще не нужна. Макрос @KMOD@в systemd на самом деле не нужен. Это (в наше время )сработало бы:

ExecStart=kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/static-nodes.conf

Превращение какой-то таблицы базы данных ()в служебные единицы? Отправьте генератор.

Задать состояние включения/отключения по умолчанию? Отправка пресетов.