LINUX.ORG.RU

Февральские тезисы о планах развития systemd

 ,


2

4

На прошедшей конференции FOSDEM Леннарт Поттеринг огласил некоторые перспективы развития systemd:

  • Интеграция в systemd загрузчика gummiboot, поддерживающего технологию UEFI Secure Boot.
  • machined — менеджер регистрации виртуальных машин, спроектированный под впечатлением от Solaris Zones.
  • В подсистеме nspawn и смежных с ней ожидается больше возможностей для управления контейнерами, например, journald сможет собирать логи не только с хоста, но и с контейнеров.
  • Уже в следующей версии ожидается улучшенная поддержка Btrfs (подразделы и снапшоты Btrfs планируется использовать для изоляции отдельных приложений).
  • Поддержка HiDPI и Юникода в consoled.
  • Сервис-ориентированный фаерволл: можно будет задавать правила в привязке не к номерам портов, а к именам процессов.
  • Отпадёт нужда указывать путь к юниту для systemctl-cat; systemctl-edit позволит редактировать юниты и после сохранения изменений автоматически перезапускать соответствующие сервисы.
  • nss-getmyhostname — функция для получения имени хоста на stateless-системах.
  • Утилита ping gateway позволит автоматически определить все доступные сетевые интерфейсы и проверить их статус командой ping.
  • Развитие networkd и собственной библиотеки для работы с DHCP (совместимой с dhcpv4 и dhcpv6).
  • Комбинирование nspawn и networkd позволит легко конфигурировать сеть для контейнеров.
  • Создание средств для широкого системного аудита, интегрированных в journald. Например, станет возможным логировать все системные вызовы к файлу /etc/passwd.
  • Движение в сторону stateless-систем, у которых только /usr доступен на чтение и запись, а /etc и /var будут автоматически заполняться systemd.
  • journald-remoting — удалённая работа логгера через HTTP. Поддержка в journald моделей pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST.
  • Возможность определения для сервисов минимальных пространств имён и sandbox-изоляции: доступ к некоторым разделам и каталогам только на чтение, сокрытие устройств в /dev, приватный /tmp для каждого сервиса, и др.
  • timesyncd в качестве замены ntpd.
  • Автоматическое определение разделов GPT, не нуждающееся в указании их в fstab.
  • Поддержка перезапуска демонов без потери их состояния (посредством сохранения оного на диск).

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: ymn (всего исправлений: 1)

Ответ на: комментарий от kir2yar

Хорошо. Молодец. А теперь дай мне цепочку, в результате которой исполняется код из /etc/X11/xsession. От запуска инита, до запуска xsession. Все промежуточные скрипты, с учетом соурсящихся.

Ты ж чушь несёшь.

Система инициализации идёт по списку и запускает демоны. То, что программа запуска сорсит какие-то шелл-скрипты — дело вообще десятое. Это логически ИНАЯ сущность. Точно так же может их сорсить то, что у тебя прописано в Exec в юнит-файле.

А какая разница? Если там есть rm -rf, он выполнится. Т.е. разницы никакой.

Deleted
()
Ответ на: комментарий от anonymous

в данном случае у нас разные представления о профессиональном софте, т.к. grep и diff выполняют свою работу на 5

cawa
()
Ответ на: комментарий от kir2yar

Оке, а какие еще скрипты исполняются и где лежат? Только честно, с учетом того, что тянется через source.


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

echo $PATH

smith
()
Ответ на: комментарий от cawa

Если скрипт bash плохо читаем - это проблема bash, и именно здесь её надо решать. Если sysvinit долбанута - это проблема sysvinit, и.т.д. Почему частные проблемы должны отменять общий принцип? Кроме того я сильно сомневаюсь, что в итоге взаимодействие компонентов systemd будет менее долбанутым, чем sysvinit.

Проблемам bash и sysvinit уже больше лет, чем части тут комментирующих. Просто эти конюшни никто не хочет разгребать, в результате было решено создать новые. В надежде, что там сранья будет меньше.



А вообще - есть клевая копипаста в тему:
Лошадь сдохла — слезь!

Лошадь сдохла — слезь!В жизни есть огромное количество ситуаций, вещей, или людей, которые нас не устраивают и уже давно. Например:
— Отношения, которые давно в тягость.
— Работа, которая давно надоела.
— Бизнес, который приносит одни убытки.

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

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

Но если его нет, тогда уясни древнюю индейскую пословицу:
Лошадь сдохла – слезь!
Казалось бы все ясно, но……
Мы уговариваем себя, что есть еще надежда.
Мы бьем лошадь сильнее.
Мы говорим «Мы всегда так скакали».
Мы организовываем мероприятие по оживлению дохлых лошадей.
Мы объясняем что наша дохлая лошадь гораздо «лучше, быстрее и дешевле».
Мы организовываем сравнение различных дохлых лошадей.
Мы сидим возле лошади и уговариваем ее не быть дохлой.
Мы покупаем средства, которые помогают скакать быстрее на дохлых лошадях.
Мы изменяем критерии опознавания дохлых лошадей.
Мы посещаем другие места чтобы посмотреть, как там скачут на дохлых лошадях.
Мы собираем коллег, чтобы дохлую лошадь проанализировать.
Мы стаскиваем дохлых лошадей ,в надежде, что вместе они будут скакать быстрее.
Мы нанимаем специалистов по дохлым лошадям.

Если лошадь сдохла – слезь.

kir2yar
()
Ответ на: комментарий от intelfx

Он обеспечивает мультисит

опять враки!

ни одной серьезной проблемы мультисита на практике (в теории, завтра - не интересно) систед пока не решил

anonymous
()
Ответ на: комментарий от kir2yar

Но сейчас вполне живую лошадь, может местами и хромающую, пытаются заменить на лошадь мёртворождённую. Фанатики, что с них взять. Свидетели секты мёртвой лошади.

anonymous
()
Ответ на: комментарий от kir2yar

Проблемам bash и sysvinit уже больше лет, чем части тут комментирующих. Просто эти конюшни никто не хочет разгребать, в результате было решено создать новые. В надежде, что там сранья будет меньше.

Эт хорошо, что вы понимаете суть. Вместо того, чтобы убрать и впредь не срать, было решено срать в другом месте. Теперь у нас две кучи говна.

Deleted
()
Ответ на: комментарий от cawa

«в данном случае у нас разные представления о профессиональном софте, т.к. grep и diff выполняют свою работу на 5»

Нет, в данном случае у нас разные представления об оценке работы на 5.

anonymous
()
Ответ на: комментарий от anonymous

Но сейчас вполне живую лошадь, может местами и хромающую, пытаются заменить на лошадь мёртворождённую. Фанатики, что с них взять. Свидетели секты мёртвой лошади.

Это sysvinit - живая лошадь?! Да не смеши мои тапки!

Единственная задача, за которую берется sysvinit - запуск сервисов, так?
Умеет-ли он это делать? Чертс два! Для запуска любого демона приходится писать отдельную программу-запускалку в /etc/init.d. На тьюринг-полном языке. С извращенским синтаксисом. И зачастую с достаточно одинаковой логикой.

Единственное, что sysvinit умеет - запускать запускалку запускалок сервисов. Это живая система инициализации чтоль?

kir2yar
()
Ответ на: комментарий от Deleted

Эт хорошо, что вы понимаете суть. Вместо того, чтобы убрать и впредь не срать, было решено срать в другом месте. Теперь у нас две кучи говна.

Только все ждут, что за них будут убирать дерьмо. Потому и строится конюшня с теликом, дерьмосливом, душевой кабинкой и кондиционером.
Конечно, человек умеющий держать отвертку в руках - может убрать все излишества, оставив только самое необходимое. Но большинству дистроклепателей такая конюшня пришлась по нраву.

kir2yar
()
Ответ на: комментарий от kir2yar

«Это sysvinit - живая лошадь?! Да не смеши мои тапки!»

Некрофилы еще надеются своем нытьем воскресить sysvinit. Однако она была мертворожденной еще при создании.

anonymous
()
Ответ на: комментарий от kir2yar

Единственная задача, за которую берется sysvinit - запуск сервисов, так?

Умеет-ли он это делать? Чертс два! Для запуска любого демона приходится писать отдельную программу-запускалку в /etc/init.d. На тьюринг-полном языке. С извращенским синтаксисом. И зачастую с достаточно одинаковой логикой.

Т.е. поскольку sysvinit не умеет запускать сервисы, надо написать systemd, который содержит полсотни бинарников, начиная от генератора QR-кодов и заканчивая ntp-клиентом.

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

sysvinit-style давно пора было выкинуть. Но не такой же ценой.

Deleted
()
Ответ на: комментарий от kir2yar

Единственная задача, за которую берется sysvinit - запуск сервисов, так?

Сразу неправильно. Sysvinit - система инициализации.

Единственное, что sysvinit умеет - запускать запускалку запускалок сервисов. Это живая система инициализации чтоль?

Надо же, мозг у тебя не до конца атрофировался, догадался для чего нужен sysvinit. И sysvinit справляется с этим на 100%, а что там за запускалка сервисов - скрипты или openrc или ещё что-либо - неважно для sysvinit. Но адептам тесной анальной интеграции с systemd такое сложно понять и принять. Это же выбирать надо из систем запуска сервисов (или можно даже свою сделать), эти дауны не могут справиться с такой непосильной задачей.

P.S. капча «obedience» подходит к фанатикам SystemDick'а.

anonymous
()
Ответ на: комментарий от cawa

Если скрипт bash плохо читаем - это проблема bash, и именно здесь её надо решать.

Проблема в том, что баш это клей системы и пока нет более чего-то продвинутого. Именно решение этой проблемы, имеет шансы избавится от таких велосипедов как systemd и им подобных.

Сейчас цели systemd достигаются дешёвыми методами, за ним ничего нет кроме тех-же велосипедов и костылей. Это хорошо заметно по обилию юнит-тестов для проверки непротиворечивости.

«В ванной есть пар? (c)» точнее в ядре юнит-тесты? Все это исходит от неуверенности в правильных действиях и ошибочной архитектуре. В итоге всё скрыто в бинарщине и система управляется наборами детских, непонятных windows-конфигов с чуждыми *nix системе идеологиями.

Кстати уже были попытки внедрения реестров. Не удивлюсь что реестры ещё вернутся...

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

Ведь эта дурь развивается не сама по себе, а за счет паразитирования на хорошо зарекомендовавших себя системах.

anonymous
()
Ответ на: комментарий от kir2yar

Но большинству дистроклепателей такая конюшня пришлась по нраву.

Да нет никакого «большинства дистроклепателей». Есть RH, и есть те, кто тащит из неё код.

Deleted
()
Ответ на: комментарий от anonymous

Некрофилы еще надеются своем нытьем воскресить sysvinit. Однако она была мертворожденной еще при создании.

Ну-ка, расскажи поподробнее про проблемы sysvinit, ну или признайся, что обосрался прилюдно.

anonymous
()
Ответ на: комментарий от kir2yar

Для запуска любо демона уже есть init-скрипт из коробки. Поправить его под свои нужды , или написать для своего демона не составляет абсолютно никаких проблем.
Я не апологет sysvinit, я просто пытаюсь понять зачем менять существующие и рабочие вещи.
Что может быть более нативным, чем bash и util-linux. Разговор именно про систему инициализации, не про крон, логирование или tty-сессии. Давайте про инициализацию, как конкретный пример.

smith
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Deleted

Т.е. поскольку sysvinit не умеет запускать сервисы, надо написать systemd, который содержит полсотни бинарников, начиная от генератора QR-кодов и заканчивая ntp-клиентом.

Зато сервисы он умеет запускать.

sysvinit-style давно пора было выкинуть. Но не такой же ценой.

Цену назначает тот, кто пишет код.

kir2yar
()
Ответ на: комментарий от anonymous

Надо же, мозг у тебя не до конца атрофировался, догадался для чего нужен sysvinit. И sysvinit справляется с этим на 100%, а что там за запускалка сервисов - скрипты или openrc или ещё что-либо - неважно для sysvinit. Но адептам тесной анальной интеграции с systemd такое сложно понять и принять. Это же выбирать надо из систем запуска сервисов (или можно даже свою сделать), эти дауны не могут справиться с такой непосильной задачей.

А нахрен-же он тогда вообще нужен, такой красивый? Передать управление следующему пиду?
Почему-бы тогда не выбросить его из цепочки kernel -> sysvinit -> systend? Если один фиг, единственное, что он делает - запускает следующую запускалку?

kir2yar
()
Ответ на: комментарий от kir2yar

Зато сервисы он умеет запускать.

В Emacs уже появился текстовый редактор? (c)

Deleted
()
Ответ на: комментарий от anonymous

Пользуйся только тем, что тебе нужно...

дельные советы

Ещё такой: «Нужно не забывать иногда себе говорить, когда цели не достигнуты - это не работает или не сработало»

Не будь жертвой.

Точнее так: жертва это частный случай игр типа «Жертва\Палач» Не играйте в эти игры.

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

anonymous
()
Ответ на: комментарий от smith

Разговор именно про систему инициализации, не про крон, логирование или tty-сессии. Давайте про инициализацию, как конкретный пример.

Ну, начать с почти тотальной невозможности отладки. Заканчивая демоническими двойными форками, что бы от консоли отцепиться. Вообще, у sysvinit достаточно много накопилось проблем. Если бы оно реально работало - никто бы не пилил альтернативу в лице openrc/upstart/systemd/launchd.

Что такое инициализированный компьютер? Это компьютер, готовый выполнять свою задачу.
Это:
1) все устройства определены/инициализированы.
2) локальные и сетевые ресурсы смонтированы.
3) сеть настроена.
4) запущенны все сервисы необходимые для основной задачи.
N) запущенна основная задача (те, ради которой компьютер и включили) * количество задач.

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

kir2yar
()
Ответ на: комментарий от kir2yar

А нахрен-же он тогда вообще нужен, такой красивый? Передать управление следующему пиду?

А нужен он затем, что когда твоя любимая куча говна вместо запускалки сервисов умрёт (например, SystemDick), система не сдохнет вместе с ней. Pid 1 должен выжить всегда, а bloatware systemdick имеет слишком много точек отказа и багов. Я не вкурсе, давно не пользовался этим говном, но умеет ли systemdick обновлять свою программу, работающую в pid1 без перезагрузки системы и без потери состояния? sysvinit с этим легко справляется через перезапуск себя через exec.

Почему-бы тогда не выбросить его из цепочки kernel -> sysvinit -> systend? Если один фиг, единственное, что он делает - запускает следующую запускалку?

По этой же логике можно выкинуть systemdick, и мы вернёмся к решению по запуску скриптами.

anonymous
()
Ответ на: комментарий от intelfx

Спасибо за просвещение, по ходу следующий setup у меня будет с systemd.

Shadow ★★★★★
()
Ответ на: комментарий от anonymous

Да, да теплые старые ламповые скрипты вроде: http://pastebin.com/F81LFvPw

намного удобнее, чем-то что предлагает systemd

[Unit]
Description=Berkeley Internet Name Domain (DNS)
Wants=nss-lookup.target
Wants=named-setup-rndc.service
Wants=network-online.target
Before=nss-lookup.target
After=named-setup-rndc.service
After=network-online.target

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/named
Environment=KRB5_KTNAME=/etc/named.keytab
PIDFile=/run/named/named.pid

ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf
ExecStart=/usr/sbin/named -u named $OPTIONS

ExecReload=/bin/sh -c '/usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP $MAINPID'

ExecStop=/bin/sh -c '/usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID'

PrivateTmp=true
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
ProtechHome=true
ProtectSystem=true

[Install]
WantedBy=multi-user.target

anonymous
()
Ответ на: комментарий от anonymous

Я не вкурсе, давно не пользовался этим говном, но умеет ли systemdick обновлять свою программу, работающую в pid1 без перезагрузки системы и без потери состояния?

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

kir2yar
()
Ответ на: комментарий от kir2yar

В этом плане, sysvinit не является системой инициализации. Он запускалка, причем довольно тупая и примитивная, сервисов, которые решают перечисленные задачи.

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

Причем даже сами сервисы он не может запустить без отдельной программы.

Это огромный плюс, который можно охарактеризовать как гибкость. Есть стандартные утилиты, есть shell интерпретатор. В зависимости от требуемых действий , мы запускаем те или иные уилиты, которые нам дают возможность сделать необходимое.

smith
()
Ответ на: комментарий от kir2yar

Он запускалка, причем довольно тупая и примитивная

это отлично. компоненты системы должны быть простыми и понятными, тогда с ними проще и надёжнее работать.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от kir2yar

Для запуска любого демона приходится писать отдельную программу-запускалку в /etc/init.d. На тьюринг-полном языке. С извращенским синтаксисом. И зачастую с достаточно одинаковой логикой.

Эта «программа» пишется методом копипаста и замены названия запускаемого бинарника в большинстве случаев. Ужас-ужас, как сложно

Harald ★★★★★
()
Ответ на: комментарий от kir2yar

Т.е. systemdick такого не умеет? И я ничего не говорил про боевые серваки, это твоя бАнальная фантазия.

anonymous
()
Ответ на: комментарий от anonymous

Так и запишем: Хипстер, по совместительству админ локалхоста, не умеет в bash.

afterlanding ★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

[Unit]
Description=Berkeley Internet Name Domain (DNS)

... пипец

Это просто жесть - windows-подобный конфиг. ini-конфиг это-же полнейшая дурь. Про прелести этого формата распичканы тома... Да и формат такой неспроста.

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

anonymous
()
Ответ на: комментарий от anonymous

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

Тут либо шашечки, либо ехать. Либо работает правильно, либо как в systemdick. Понятно зачем в systemdick'е автоматическая перезапускалка сервисов встроена с такой кривотой при портировании скриптов в юниты.

anonymous
()
Ответ на: комментарий от smith

Есть стандартные утилиты, есть shell интерпретатор. В зависимости от требуемых действий , мы запускаем те или иные уилиты, которые нам дают возможность сделать необходимое.

Ога, пока очередной кодер не поставит лишний пробел в rm -rf /tmp/*
История nvidia и bumblebee тому яркое подтверждение.
Сравни с
PrivateTmp=true
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
ProtechHome=true
ProtectSystem=true

kir2yar
()
Ответ на: комментарий от anonymous

нифига не наглядные

вопрос культуры ментейнера. В *BSD они обычно весьма наглядные, например.

Shadow ★★★★★
()
Ответ на: комментарий от kir2yar

А в чём отличие от такого же теоретического случая, когда лишний пробел поставят в systemdick'е? Ну, кроме того, что тогда оно проявится у ВСЕХ пользователей этого поделия, а не только у тех, кто использовал bumblebee.

anonymous
()
Ответ на: комментарий от kir2yar

Хорошо, а как дела с проверками на условие ?
Как реализован функционал [ -x bla-bla-bla ] например ?
Как сделать так, чтобы демон запускался с помощью конкретной программы?
Простой пример: мне надо ограничить исходящую скорость бекапа с сервера. Соответственно в запускающем скрипте bacula-fd я ставлю trickle -s -u в строчке запуска bacula-fd.

smith
()
Ответ на: :) от chemistmail

Когда(если) ты подрастешь и увидишь логи > 2 гигов, у тебя возникнут вопросы как с ними работать.

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

Еще раз: журнал нужен для логов конкретной машины. И если вы, вместо аггрегации на сислог сервер, используете его для объемных логов - это проблема архитектуры, а не технологии.

Alsvartr ★★★★★
()
Ответ на: комментарий от Alsvartr

логов конкретной машины

с логами конкретной машины проблем не было никогда и вообще.

что-то не помню плачей десктопюзеров или гневных выступлений админов мини серверов...

может ссылочкой на проблемы логов «маленьких» машин ты богат? Дак поделись... ;)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.