Давай мне на баше, я переведу.

Тот скрипт делает не то, что было написано выше:

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

Потому что если флешки нет, то он просто выйдет. Вот 2 юнита, которые делают то, что было заявлено раньше:

[Unit]
Description=cryptmount
ConditionPathExists=/dev/disk/by-uuid/12345678-abcd-9876-f00d-fedcba987654

[Service]
Type=oneshot
ExecStartPre=/bin/bash -c 'dd if=/dev/disk/by-uuid/12345678-abcd-9876-f00d-fedcba987654 bs=16 count=1 skip=12 | cryptsetup ...'
ExecStart=/bin/mount /dev/mapper/something /mnt/extra
ExecStop=/bin/umount /mnt/extra
RemainAfterExit=yes

[Unit]
Description=nocryptmount
ConditionPathExists=!/dev/disk/by-uuid/12345678-abcd-9876-f00d-fedcba987654

[Service]
Type=oneshot
ExecStart=/bin/mount /dev/sda10 /mnt/extra
ExecStop=/bin/umount /mnt/extra
RemainAfterExit=yes

Если очень надо, то могу и тот скрипт перевести.

>А как работают udisks и usb_modeswitch?

usb_modeswitch

ЩИТО? Мне надо какую-то срань поставить, чтобы смонтировать /?

udisks

Он немного для съёмных устройств. systemd монтирует то, что в fstab. Разница есть. И я написал же:

монтирует разделы жёсткого диска

Вообще, по-хорошему, это делается через [Mount], а не [Service], но там, к сожалению, нет ExecStartPre. Вот вариант второго юнита на [Mount]:

[Unit]
Description=nocryptmount
ConditionPathExists=!/dev/disk/by-uuid/12345678-abcd-9876-f00d-fedcba987654

[Mount]
What=/dev/sda10
Where=/mnt/extra
Type=auto
Options=defaults

> Беда в том, что как systemd, так и upstart зависят от dbus

От dbus зависит много чего, но не upstart.

так что собрать систему без dbus, которая шустро запускается, оказывается проблематично.

dbus не имеет отношения к скорости запуска. Он - просто лишняя зависимость для init-демона, лишний источник проблем, еще одно потенциальное узкое место. init - это основа системы, он должен быть маленьким, и не должен зависеть ни от чего, а любой его компонент должен быть легко заменяем. sysvinit удовлетворял этому условию, upstart удовлетворяет этому условию, systemd - нет.

Кстати, собрать систему без dbus-а можно на базе icewm, например.

>От dbus зависит много чего, но не upstart.

4.2. upstart не создаёт /dev/initctl и управляется через dbus.

В упор не вижу MARK - проверку на наличие ключа на этом устройстве.

Зато вижу... запуск баша:

ExecStartPre=/bin/bash -c 'dd if=/dev/disk/by-uuid/12345678-abcd-9876-f00d-fedcba987654 bs=16 count=1 skip=12 | cryptsetup ...'

То есть из systemd даже при неполном решении задачи приходится запускать баш? Так зачем нам тогда нужен systemd?

> 4.2. upstart не создаёт /dev/initctl и управляется через dbus.

Он управляется через юникс-сокет. Поддержка управления через dbus появилась начиная с версии 0.6 и она не обязательна (man initctl параметр --system).

Так никто ведь не заставляет юзать пайпы. Вполне можно воспользоваться, скажем, временным файлом.

>при неполном решении задачи

А ты сам не осилил вставить в строку баша нужный код?

Зато вижу... запуск баша:

Я же говорил:

Вообще, по-хорошему, это делается через [Mount], а не [Service], но там, к сожалению, нет ExecStartPre.

Если запилят, можно будет без баша.

Так зачем нам тогда нужен systemd?

Систему запускать, очевидно же.

>Вполне можно воспользоваться, скажем, временным файлом.

Можно FIFO сделать. Это лучше, чем просто файл. Но чтобы сделать '>' туда, то, наверное, sh понадобится. Или systemd умеет перенаправлять?

Кстати, собрать систему без dbus-а можно на базе icewm, например

Кстати да, оказывается много лет жил без dbus. И не замечал. И только недавно, когда захотел на wicd поглядеть (что же его так хвалят), обнаружил, что в /etc/rc.conf опечатался. dbas там было прописано. На ледяных окошках всю сознательную жизнь, с дебиан сарж. А вот хал выкинуть из демьяна было непросто, велосипеды городил. Что и сподвигло на арч перейти.

>в /etc/rc.conf опечатался. dbas там было прописано.

И что, при загрузке не было ошибок? Арч такой арч.

> Для запуска сервисов достаточно простого дерева зависимостей, которое можно обработать хоть на sh, хоть на Tcl, хоть на чем угодно.

Согласен. Заслуга Lennart'а заключается в том, что он понял, что большая часть этих зависимостей на самом деле не нужна.

Я буду очень рад, когда ему выдадут медаль «за понимание собственной ущербности»

Интересно, может не обращал внимания, поскольку всё работало. А значит и копать не надо было. Надо взад всё вернуть, посмотреть. А вообще, я же не против комбайнов. Пусть будут. Но печальный пример бунты и федоры показывает что linux из удобного конструктора превращается в монстра с тесно интерированными зависимыми структурами. Почему-то Форд вспомнился с его изречением: Не ломается только та деталь, которой нет.

Ну так демьян на dash перешёл, если не ошибаюсь.

>Ну так демьян на dash перешёл, если не ошибаюсь.

Там просто симлинк /bin/sh по дефолту не на bash указывает, а на dash. Уже давно, кстати.

ЗЫЖ а за автоматический перезапуск упавших сервисов надо сразу расстреливать. Даже в венде до такого не додумались, кажется.

Додумались с 1999 года. Вы опоздали на 12 лет.

Изменений кот наплакал http://lists.freedesktop.org/archives/systemd-devel/2011-June/002642.html

Стоило ли ради этого новость писать?

> Да не запускает systemd систему быстро - он просто размазывает время старта, и быстрее выводит систему к login prompt.

ВЫ его пробовали или просто о-ла-ла?

> ВЫ его пробовали или просто о-ла-ла?

Я просто читал всю документацию о нем, которую смог достать.

А пробуют его пускай люди, у которых слишком много свободного времни (федора, арча). И по вестям с полей, не готово это чудо для эксплуатации.

>Как же ж нельзя? upstart рулит обычными sysv-скриптам

Ну вот так нельзя. Нативные юниты апстарта (которые *.conf) в свое время можно было только физически удалить с диска(ну или переименовать), а отключить, чтобы не грузился — нет. В 11.04 они таки догадались дать такую возможность, не прошло и пяти лет. В systemd это хотя бы изначально возможно было...

>В венде это приводило только к тому, что некоторое время после логина работать было невозможно.

Могу сказать, что когда я ещё пользовался systemd, такого не наблюдалось.

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

> Так вот я им доволен

Рад за тебя. Но позволь спросить, сколько раз в неделю ты включаешь и выключаешь комп?

но это не значит, что его заочно нужно критиковать, даже не попробовав.

А вот это - серьезная ошибка класса «спердобейся». Критиковать можно и нужно, исходя из спеков.

Я, в общем, не против systemd. Юниты в нем проще, чем в SysV, интеграция с cgroups тоже может быть полезной, так что пусть себе кропают. Другое дело, что никаких критически важных проблем он не решает, и, по-моему, у него kitchen sink synrome.

>не готово это чудо для эксплуатации.

Да ну? Вовсю использую на нетбуке, глюков не наблюдал, кроме подвисаний при выключении на арче из-за тамошнего кривого сислога.

слишком много свободного времни (федора, арча)

Генту же забыл =)

>> не готово это чудо для эксплуатации.

Да ну?

Ога. То, что ты его поставил и настроил, не означает, что оно того стоило.

слишком много свободного времни (федора, арча)

Генту же забыл =)

Каюсь, искуплю.

нет я про стиль хранения конфигов..

Ну, у него традиционный sysv-инит как во всех старых дистрибутивах. А что там в конфигах — детали реализации скриптов, которые ITT обсирают (кстати, с systemd можно изменить конфиги настолько, не трогая бинарник?).

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

>кстати, с systemd можно изменить конфиги настолько, не трогая бинарник?

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

Значит, нет. Ок.

> Ну вот так нельзя. Нативные юниты апстарта в свое время можно было только физически удалить с диска, а отключить, чтобы не грузился — нет.

Вообще-то, можно - переключением ранлевела. Но кому нужны были эти нативные юниты? В нативных - только getty. А все остальное лежит в «обычных» sysv-скриптах, в которых в начале написано что-то вроде:

# Provides: httpd
# Required-Start: $local_fs $remote_fs $network $named
# Required-Stop: $local_fs $remote_fs $network

Раньше можно было посмотреть информацию о том, что загружалось на каждом ранлевеле одной командой `chkconfig --list`. Это работало для sysvinit, это работало для upstart. А что нужно выполнить в systemd, чтобы увидеть то же самое?

>Вообще-то, можно - переключением ранлевела.

И все остальные юниты, которые должны были запускаться на старом ранлевеле, тоже отключатся?

> И все остальные юниты, которые должны были запускаться на старом ранлевеле, тоже отключатся?

Остальных нет, в юнитах - только getty. Таким методом в redhat-based дистрибутивах выключали иксы - в runlevel 5 иксы включены, а в runlevel 3 - нет. А «остальные» - лежали в sysv-скриптах и управлялись классическими, проверенными годами методами.

>А «остальные» - лежали в sysv-скриптах и управлялись классическими, проверенными годами методами.

И никакого профита upstart не давал. Это, кстати, уже не так. Так сделано в Дебиане, и время загрузки с upstart не отличалось от времени с SysVinit (проверял лично). Если же написать нативные юниты для upstart, то был профит в несколько секунд (так сделано в бубунте, но и там до сих пор остались старые скрипты).

Раньше можно было посмотреть информацию о том, что загружалось на каждом ранлевеле одной командой `chkconfig --list`. Это работало для sysvinit, это работало для upstart. А что нужно выполнить в systemd, чтобы увидеть то же самое?

С systemd как таковых ранлевелов нет. Есть таргеты. Посмотреть можно с помощью systemctl (systemctl --help в помощь) или 'ls -1 /{etc,lib}/systemd/system/*.target.wants'

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

Суровые арчеводы ЛОРа…

> +1, лютая жесть. «I wrote most of Avahi and PulseAudio, among other stuff. Right now I am focusing > on systemd which I created»

Черт! Он еще и avahi написал! Самое прискорбное, что это все почему-то намертво внедряют. Привилегии программера в RedHat что ли? Будем надеяться, что к моменту, когда он начнет свой 10ый проект, то уже натренируется на предыдущих.

>Черт! Он еще и avahi написал!

Особенность его проектов в том, что они, вроде, что-то полезное делают, но вполне можно жить без них. Но с ними интереснее.

Во всём виноват RedHat и потому он не нужен.</fat>

Крутейшая штука. Запуск / ждущий режим / выключение радуют.

Avahi нужна, пульса тоже прерасна.

ждём ебилдов?

а как же bolgenos? загрузка 5 секунд(!) новые обои(!) антивирус Попова(!)

А тут 10 секунд почему-то... отстаём, товарищи.

запилят поддержку в systemd

А если не запилят?

>I wrote most of Avahi and PulseAudio

OMG, опять этот велосипедист ///_-

> Наконец-то хоть кто-то осуществил этот шаг.

Такое уже было в initng... но он по ходу загнулся :(

>А тут 10 секунд почему-то... отстаём, товарищи.

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

> Чем примечательна 29-я версия? Их выпускают довольно часто.

Сказано же: «В новой версии были незначительно изменены Makefile-ы, и было добавлено 2 пункта в TODO».

>А если не запилят?

Если всё пойдёт хорошо, то systemd будет во всех ведущих дистрибутивах наравне с udev. Тогда если появится более новая альтернатива udev, которая будет хороша, но всё ещё малоиспользуемая, то разработчики systemd должны обратить на неё внимание, если она будет продвигаться как замена udev (как сейчас systemd заменяет SysVinit).

>ждём ебилдов?

Оверлей systemd, похоже, забросили. Там всё давно протухло (в основном udev). systemd 28 появился недавно в дереве.