[devel] systemd-215

[devel] systemd-215

[Alexey Shabalin]

> Думаю его можно передвинуть на попозже. Делая эти
> сервисы(altlinux-*.service),  я пытался повторить логику rc.sysinit.
> Скорее всего надо пересмотреть эту логику на текущий момент. У меня
> глаз уже замылился, а свежым взглядом может быть все виднее.

День добрый.
Собираю systemd-215, и пытаюсь переварить нововведения сделанные в нем
для ALTLinux. Прошу помощи зала. Вопрос такой.
в 215 добавлены новые функции для Factory Reset, Stateless Systems ...
http://0pointer.de/blog/projects/stateless.html
появились новые ConditionNeedsUpdate=, утилита systemd-sysusers, юнит
systemd-update-done.service(и к нему в нагрузку
systemd-sysusers.service,systemd-udev-hwdb-update.service,
systemd-journal-catalog-update.service, ldconfig.service)
Эти сервисы используются для первой загрузки после reset, или внутри
нового контейнера, по аналогии с нашим /etc/rc.d/scripts/first_time
В принципе, после обновления до systemd-215 эти сервисы отработают
один раз и при следующей перегрузке запускаться не должны. Но у меня
все равно возникают сомнения в необходимости запуска ldconfig.service
даже этот один раз (при чем у нас /usr еще может быть на отдельном
разделе).
Вопрос что делать?
- сразу выставить флаг, что б не запускать эти сервисы
- вообще вырезать эти нововведения
- вырезать это в отдельный пакет
- оставить как есть, пусть запустятся один раз

PS: может и /etc/rc.d/scripts/first_time перевести на эту новую
функциональность?

-- 
Alexey Shabalin

Re: [devel] systemd-215

[Michael Shigorin]

On Mon, Aug 04, 2014 at 07:50:31PM +0400, Alexey Shabalin wrote:
> Эти сервисы используются для первой загрузки после reset, или внутри
> нового контейнера, по аналогии с нашим /etc/rc.d/scripts/first_time

Т.е. смысл именно в отрабатывании на свежесгенерированной системе
(или аналогично в чруте)?

> В принципе, после обновления до systemd-215 эти сервисы отработают
> один раз и при следующей перегрузке запускаться не должны.

А должны ли они вообще отрабатывать после _обновления_?

> Вопрос что делать?
> - сразу выставить флаг, чтоб не запускать эти сервисы
> - вообще вырезать эти нововведения
> - вырезать это в отдельный пакет
> - оставить как есть, пусть запустятся один раз

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

> PS: может и /etc/rc.d/scripts/first_time перевести на эту новую
> функциональность?

Только если не сломается под sysvinit, пожалуйста.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] systemd-215

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]

On Mon, Aug 04, 2014 at 07:50:31PM +0400, Alexey Shabalin wrote:

> День добрый.
> Собираю systemd-215, и пытаюсь переварить нововведения сделанные в нем
> для ALTLinux. Прошу помощи зала. Вопрос такой.
> в 215 добавлены новые функции для Factory Reset, Stateless Systems ...
> http://0pointer.de/blog/projects/stateless.html
> появились новые ConditionNeedsUpdate=, утилита systemd-sysusers, юнит
> systemd-update-done.service(и к нему в нагрузку
> systemd-sysusers.service,systemd-udev-hwdb-update.service,
> systemd-journal-catalog-update.service, ldconfig.service)
> Эти сервисы используются для первой загрузки после reset, или внутри
> нового контейнера, по аналогии с нашим /etc/rc.d/scripts/first_time


ldconfig.service нужен только в случае отсутствия ld.so.cache. Во всех
иных случаях у нас этим занимаются filetrigger'ы. Так что ему вместо
ConfigtionNeedsUpdate нужно проверять отсутствие /etc/ld.so.cache.

systemd-sysusers требует отдельного разбирательства -- для  практического
использования в дистрибутивах потребуется отпилить её в отдельный пакет,
дабы от нее был прок и для SYSV-based дистрибутивов. И потребуется участие
мантейнеров пакетов для её использования. И, кстати, она работоспособна с
tcb?

Что делают остальные сервисы?

> - сразу выставить флаг, что б не запускать эти сервисы

Надо для начала разобраться с саими сервисами.

> - вообще вырезать эти нововведения

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

> - вырезать это в отдельный пакет

systemd-sysusers однозначно стоит -- ибо его активное использование
в пакетах потребует его ставить и запускать и в sysv-based системах.

> - оставить как есть, пусть запустятся один раз

Ни в коем случае. Оно не должно лезть в /etc пока не попросят, особенно
создавать каких-либо пользователей, к примеру.

> PS: может и /etc/rc.d/scripts/first_time перевести на эту новую
> функциональность?

А как это будет выглядеть? first_time ведь не должен запускаться при любом
изменении /usr.

P.S. Кстати о. Работа этих фич требует еще чтобы наш rpm делал touch на
/usr после любых изменений. 

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] systemd-215

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 3291 bytes --]

On Tue, Aug 05, 2014 at 01:19:04AM +0400, Alexey Shabalin wrote:

>> ldconfig.service нужен только в случае отсутствия ld.so.cache. Во всех
>> иных случаях у нас этим занимаются filetrigger'ы. Так что ему вместо
>> ConfigtionNeedsUpdate нужно проверять отсутствие /etc/ld.so.cache.
> Этот сервис тоже предназначен только для первого запуска системы.

Если бы это было так, там было бы вместо:

ConditionNeedsUpdate=/etc

написано:

ConditionPathExists=!/etc/ld.so.cache

Собственно это изменение я и предлагаю сделать.

ConfigtionNeedsUpdate работает сравнением mtime у /usr и /etc/.updated.

Эта фича у нас работать не будет вообще, если только rpm не далет touch на
/usr после любого обновления. И суть её именно в том, чтобы модифицировать
/etc после обновления содержимого /usr.

Для ситуации с пустым /etc вполне достаточно пачки сервисов с
CondigtionPathExists.

>> systemd-sysusers требует отдельного разбирательства -- для  практического
>> использования в дистрибутивах потребуется отпилить её в отдельный пакет,
>> дабы от нее был прок и для SYSV-based дистрибутивов. И потребуется участие
>> мантейнеров пакетов для её использования. И, кстати, она работоспособна с
>> tcb?
> shadow никак не затрагиваются, для свеже сгенерированой  системы нужны
> только passwd и groups.

Надо уточнить у ldv@ так ли это. Ибо для системных пользователей я таки
вижу соответствующие каталоги в /etc/tcb.

>> Что делают остальные сервисы?
> Все эти сервисы, грубо говоря, нужны при пустом /etc.

Однако работают они отнюдь не только при пустом /etc ;)

>> Если мешают -- вырезать, если как минимум не мешают -- оставлять.
> Не-не, сначала почитайте по ссылке, для чего все это задумано.
> Такие советы я и сам могу дать :)
> Я же хочу услышать более конкретные мысли, как мы это можем использовать у
> себя.

Я прочитал по ссылке. И, очевидно, это может быть полезно для контейнеров,
а также для выполнения части той работы, что сейчас выполняется
хуками инсталлера.

>>> - вырезать это в отдельный пакет
>> systemd-sysusers однозначно стоит -- ибо его активное использование
>> в пакетах потребует его ставить и запускать и в sysv-based системах.
> Пока склоняюсь к мысли все (ldconfig.service, systemd-users и остальное)
> вырезать в отдельный пакет. Имя какое придумать? systemd-stateless?

1. Не просто вырезать, а все же модифицировать под наши реалии. Потому как
ldconfig с ConditionNeedsUpdate у нас (где есть файлтриггеры
соответствющие) попросту нафиг не нужен. Он нужен _только_ при пустом
/etc, а значит нужно использовать ConditionPathExists.

2. systemd-sysusers либо отпилить нафиг в systemd-stateless и забить (но
тогда он будет абсолютно бесполезен -- ибо некому для него будет создавать
конфиги). Либо поместить его в systemd-utils, ибо этот инструмент не
зависит от используемой системы инициализации.

Соответственно можно будет обсудить использование его, точно также как и в
Fedora, вместо adduser/addgroup в спеках.

>> P.S. Кстати о. Работа этих фич требует еще чтобы наш rpm делал touch на
>> /usr после любых изменений.
> Это если оригинальные конфиги будут хранится в /usr ? И переноситься в /etc
> ?

А вся концепция подразумевает именно это.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]