LINUX.ORG.RU

Релиз systemd 230

 


4

8

Представлен выпуск системного менеджера systemd 230. Из новшеств можно отметить включение по умолчанию DNSSEС и режима чистки процессов пользователя после завершения сеанса, поддержку унифицированной иерархии cgroup, возможность настройки прокси ARP для сетевого интерфейса, новые типы юнитов generated и transient, новую команду systemctl revert и возможность создания виртуальных прямых сетевых ссылок между контейнерами.

Основные изменения:

  • В DNS-резолвере systemd-resolved по умолчанию включен DNSSEC. DNSSEC доступен в режиме allow-downgrade (автоматический откат на режим без DNSSEC) и может быть отключен через настройку DNSSEC в resolved.conf или на этапе сборки при указании опции configure --with-default-dnssec=no. Дистрибутивам пока не рекомендуется включать DNSSEC по умолчанию, пока не будут выявлены все возможные несовместимости режима DNSSEC с DNS-серверами.
  • В systemd-resolve добавлена возможность резолвинга DNS-записей DANE (DNS-based Authentication of Named Entities) при указании опции --tlsa и OPENPGPKEY при указании опции --openpgp, а также создания дампа raw-данных записей DNS при указании опции --raw=дамп.
  • В systemd-logind по умолчанию обеспечено принудительное завершение процессов, запущенных в составе пользовательского сеанса, после выхода пользователя из системы. Управлять принудительным завершением можно через опцию KillUserProcesses в logind.conf, которая теперь выставлена в значение yes по умолчанию, что требует отдельных настроек, если необходимо сохранить работу длительно выполняемых пользовательских процессов (для работы screen и tmux требуется специальная настройка сервисов, например, включение т.н. lingering через loginctl). Для восстановления старого поведения на этапе сборки можно указать опцию --without-kill-user-processes.
  • В systemd-logind добавлены новые настройки SessionsMax и InhibitorsMax, которые по умолчанию установлены в значение 8192.
  • В systemd-logind добавлена поддержка обновления конфигурации по сигналу SIGHUP.
  • Добавлена поддержка унифицированной иерархии cgroup (в ядре с 4.5), для задействования которой в systemd при загрузке требуется указать опцию командной строки ядра systemd.unified_cgroup_hierarchy=1. Для унифицированной иерархии также добавлен контроллер cgroup io, который дополнил контроллеры memory и pids.
  • Поддержка протокола LLDP (Link Layer Discovery Protocol) расширена возможностями использования пассивного (только приём) и активного (отправка) режимов. Пассивный режим включен по умолчанию в systemd-networkd, а активный режим включен по умолчанию в изолированных контейнерах с адресацией внутренней сети. Для просмотра статистики можно использовать команду networkctl lldp.
  • Добавлена возможность настройки уникальных идентификаторов IAID и DUID, отправляемых в запросах DHCP. Идентификаторы могут быть определены как для всей системы, так и для отдельных файлов .network при помощи опций DUIDType, DUIDRawData и IAID.
  • В systemd-networkd добавлена возможность настройки прокси ARP для отдельных сетевых интерфейсов, используя опцию ProxyArp в файлах .network. Кроме того, в файлы .netdev добавлены опции MulticastQuerier и MulticastSnooping, позволяющие включить режим отправки запросов и прослушивания IGMP-трафика.
  • В файлах .network представлена новая опция PreferredLifetime, позволяющая определить время жизни IP-адреса.
  • В DHCP-сервере, встроенном в systemd-networkd, активирована по умолчанию опция EmitRouter, включающая поле DHCP Option 3 (Router).
  • Тестовая утилита systemd-activate переименована в systemd-socket-activate и перемещена в /usr/bin.
  • В systemd-journald задействован отдельный поток для сброса прокэшированных данных на диск при закрытии файлов с журналом, что решило проблемы с задержками записи в лог на медленных дисках.
  • В journalctl добавлен новый метод вывода -o short-unix, при котором к записями в логе добавляется префикс с эпохальным (UNIX) временем (число секунд с 1970 года). Также добавлена опция --no-hostname для исключения столбца с именем хоста.
  • Устройства фреймбуфера, сканеры и 3D-принтеры теперь подключаются в режиме uaccess и доступны для вошедших в систему пользователей.
  • В опции DeviceAllow теперь можно указывать спецификаторы (начинаются с символа %).
  • В systemctl show добавлена опция --value, позволяющая вывести только содержимое заданного свойства юнита без указания его имени.
  • Для автоматически сгенерированных и созданных в процессе работы через обращения к API файлов добавлены новые типы юнитов generated и transient.
  • Добавлена новая команда systemctl revert для отката к предоставляемой поставщиком версии файла юнита в случае внесения в файл юнита локальных изменений.
  • В machinectl clean добавлена возможность автоматического удаления всех или только скрытых образов контейнеров.
  • В systemd-tmpfiles добавлен новый тип записи «e», позволяющий организовать очистку директорий, если они уже существуют.
  • В systemd-nspawn добавлена поддержка автоматического исправления UID/GID и ACL для всех файлов и директорий в контейнере для их соответствия диапазону UID/GID, выбранному при запуске контейнера.
  • В systemd-nspawn добавлена новая опция --network-zone для создания виртуальных прямых линков между контейнерами.
  • Для socket-юнитов добавлены опции TriggerLimitIntervalSec и TriggerLimitBurst для настройки лимитов на возможное число активаций в заданный промежуток времени.
  • Компонент systemd-bootchart вынесен в отдельный репозиторий.
  • Из состава удалён systemd-bus-proxyd, так как kdbus вряд ли будет принят в ядро в своём текущем виде.
  • Удалены библиотеки libsystemd-daemon.so, libsystemd-journal.so, libsystemd-id128.so и libsystemd-login.so, которые ранее были объявлены устаревшими.
  • Удалена опция Capabilities, вместо которой следует использовать AmbientCapabilities и CapabilityBoundingSet.

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

★★★★

Проверено: Falcon-peregrinus ()
Последнее исправление: Klymedy (всего исправлений: 5)

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

Какое 4.2? По вашему разработчики devuan не являлись разработчиками debian? Точное количество тех, кто не стал мирится с systemd мне не известно, но когда было голосование о включении systemd в дистр голоса разделились примерно поровну.

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

придумал и передёрнул тут именно ты

Как у нас говорят, - «передёрнул - стреляй!» //поправляя черный берет//

Таких как ты я предпочитаю не видеть, а если и видеть - то очень недолго, и исключительно в увеличительное стёклышко 30х, нацепленное на СВД.

Разработчики не debian, а devuan

Devuan - это проект. А разработчики у него - фонд спо dyne.org, безграмотный форк не всех своих родителей.

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

Если говорить о хомякомашинах (у меня есть такие) остались крыса, корица, и с горем пополам - юнити.

Я к тому, что дистры общего назначения предоставляют выбор. Им сложно отказаться от сборок гнома/кде. Отсюда и вся эта бессмысленная борьба/уговоры/труд.

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

Зачем их форкать?

Чтоб предоставить широкий выбор программного обеспечения и взаимозаменяемость компонент системы.

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

А ведь там было не 1.5 анонимуса, около половины разработчиков было против введения systemd в дистрибутив.

Опять ведь 4.2. По-первых не разработчики, а тех. коммитет, во вторых не половина была «против», а голоса разделились между systemd и upstart. В итоге тех. коммитет решил дефолт сделать systemd из-за сомнительного contributor's agreement апстарта и полную завязанность на Canonical и любовь последнего спихивать работу на апстрим и деньги собирать за added value.

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

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

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

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

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

Что-то ты погнал. Ну не полтора, чуть больше. И какую роль они играли в Debian я не знаю, просвети.

https://devuan.org/os/team/

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

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

Та же самая история с ядром линукса, но это ведь тебя не смущает?

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

Примечательно и то, что «они» не пилили себе поддержку системд для дебиана в сторонке. И даже не форкнули дебиан. А просто послали 30% разработчиков с их мнением. Когда к ним с патчами подкатили - тож послали.

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

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

А на счёт devaun, я тоже был скептически настроен, особенно учитыва на отсутствие изменений на главном сайте в течение долгого времени, но вот и бета случилась, думаю разработчики и дальше будут продолжать, пока это будет им по силам. Ведь действительно непросто сделать совместимый дистр, при этом выдрав оттуда такого монстра как systemd.

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

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

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

Я сам не знаю, ибо не пробовал пока. Но я давал ссылку на человека, который испытал большое количество способов заработка на СПО. В своём резюме он написал, что таки с GPL и подобными лицензиями «Вася» имеет возможность заработать, а вот в случае с лицензиями типа BSD шансов нет, пройдите по ссылке, почитайте, там интересно.

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

А ведь там было не 1.5 анонимуса

За Devuan стоят именно полтора анона.

около половины разработчиков было против введения systemd в дистрибутив

DM, DD или членов технического комитета, юный специалист по дебиану? :)

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

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

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

пройдите по ссылке, почитайте, там интересно.

нет уж, увольте. хотите, цитируйте здесь.

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

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

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

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

Главная фишка Linux была в UNIXWay. Если мы говорим, что эта концепция устарела, то резон обратиться к уже готовой системе, коей является windows.

UNIXWay... Хех...
1) Ядро линукса не юниксвейно.
2) XOrg не юниксвей.
3) firefox/chrome не юниксвей.
4) Gnome/KDE не юниксвей.

А вот системд - вполне катит за юниксвей. Ибо каждый бинарник из состава системд делает свое дело и старается его делать хорошо. Другое дело, связанны они не пайпами. Это да.

kir2yar
()

ыныеуьв как вижуал студио. монстроузный проект в котором типа «все есть».

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

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

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

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

Главная фишка Linux была в UNIXWay.

Нет, главная фишка Linux - это свобода ПО.

А тенденции таковы, что Microsoft в среднесрочной перспективе ожидает серьёзное падение спроса, думаю в течении десяти лет они просядут до 30-40% присутствия на десктопах.

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

испытал большое количество способов заработка на СПО.

Есть разные способы, и не все - очевидные. У сабжа этого треда - всё очевидно. Мне интересно - когда RH начнет требовать роялти? Как только сабж будет избавлен от массы текущих проблем, я полагаю, и начнет хотя бы стабильно работать...

Не хотел я это писать... Типичный и банальный пример - с год назад на одной из используемых эмбеддед-железяк с 8-ядерным mips64 одна из новых версий одного известного дистрибутива внезапно встала в позу рака. Причиной оказался systemd, внезапно появившийся в системе при очередном централизованном обновлении. Он тупо наглухо вис при попытке развернуть udev. На этом всё заканчивалось, аппаратный ватчдог отправлял железку на ребут через заданный таймаут, и всё повторялось снова. Отключил ватчдог, ждал два часа - система всё также висела на этапе populating udev... Пришлось снимать белый воротничок, закатывать рукава и лезть в потроха этой железяки, - решилось же всё откатом системы на версию без systemd, но с кастомным ядром. При этом, та же система, на таких же железках - работала нормально, раком встал только один (весьма недешевый) девайс. Время простоя обошлось примерно в 20к гринов. Саппорт-тим того дистрибутива запросил с нас порядка 50*10^3 вечнозеленых, неделю на разборки и железку для исследований. Да «на бал» такие решения... После этого централизованный апдейт железок был принудительно выключен, и на всех железяках теперь царит init. Ни одного зависона больше не было. Уже пару лет клиент доволен как слон, и ему пофигу - что там крутится в его железяках.

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

Чтоб предоставить широкий выбор программного обеспечения

Выбор и так настолько широк, что отсутствие гномокед как DE его совершенно не затрагивает.

компонент

Компонентов, а не компонент. Ты в единственном числе «компонента» говоришь, что ли?

взаимозаменяемость

DM и WM, не привязанных к системе инициализации, предостаточно. Система инициализации тоже не одна. Что тебе не так?

border-radius
()
Ответ на: комментарий от Olegarch

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

эмбеддед

внезапно появившийся в системе при очередном централизованном обновлении

Ты это... Ври, но не завирайся.

Или у седовласых спецов-мудрецов эмбеддед получает мажорные обновления из неподконтрольного источника без тестовых развёртываний?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от AS

В десктопной части - да. В серверной - нет. systemd же тащит это и на сервера.

То есть апач юинксвей? Asterisc юниксвей? Dovecot юниксвей? Или OpenSSH (с фтп-сервером, пробросом портов и кучей прочего полезного хлама) юинксвей?

Правда постфикс более-менее юинксвей. Правда пока вкуришь его main.cf...

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

Нет, главная фишка Linux - это свобода ПО.

Это не так. Большая часть «свободного» ПО кроссплатформенно. Другое дело, в винде, зачастую, оно не конкурентоспособно по сравнению с ПО частных и коллективных собственников. Однако, никто не мешает использовать тебе там это «свободное» ПО,

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

А это тоже ноунеймы, как и твой воид.

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

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

эмбеддед обновляется из неподконтрольного источника без тестовых развёртываний

Ты тоже...? А так вроде и не скажешь... :)

Повторяю для не умеющих читать - проблема возникла только на ОДНОЙ железке, и причиной стал systemd. Он тупо вис на этапе polulating udev. Меня не колышат сейчас причины такой избирательности (я подозреваю - где он споткнулся), - мне надо, чтобы оно работало. Оно не работало. После принудительного отката на версию БЕЗ сабжа - заработало, также, как за год до этого, когда железка была поставлена. Итого - два года без этого овна - полет нормальный.

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

То есть апач юинксвей?

Да. Его задача - http. Даже ftp не поддерживает. :-)

Asterisc юниксвей?

Он предназначен для чего-то, кроме телефонии ?

Dovecot юниксвей?

А нет ? Это mail storage, обеспцивающий только те функции, которые необходимы для mail storage.

Или OpenSSH

Он делает ровно то, для чего предназначен. А ftp там разве есть ? Впрочем, если есть, то это - мелочь.

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

и причиной стал systemd. Он тупо вис на этапе polulating udev.

Причём, в общем-то, это udev, а не systemd. Только вот группа нехороших людей их собрала в кучу, лишив людей возможности раздельного обновления...

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

Он делает ровно то, для чего предназначен.

Пробрасывает иксы, произвольные порты, и обслуживает локальные каталоги по SFTP? НЕКОМБАЙН.

А ftp там разве есть ? Впрочем, если есть, то это - мелочь.

s/мелочь/двойные стандарты/

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

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

 ~ % apt depends udev
udev
  PreDepends: dpkg (>= 1.17.14)
    dpkg:i386
  Depends: libacl1 (>= 2.2.51-8)
  Depends: libblkid1 (>= 2.19.1)
  Depends: libc6 (>= 2.17)
  Depends: libkmod2 (>= 5~)
  Depends: libselinux1 (>= 2.0.65)
  Depends: adduser
  Depends: libudev1 (= 229-6)
  Depends: lsb-base (>= 3.0-6)
  Depends: util-linux (>= 2.27.1)
    util-linux:i386
  Depends: procps
    procps:i386
  Breaks: bash-completion (<< 1:2.1)
  Breaks: consolekit (<< 0.4.6-1)
  Breaks: ifupdown (<< 0.8.5~)
  Breaks: kmod (<< 14)
  Breaks: plymouth (<< 0.9.0-7)
  Breaks: systemd (<< 224-2)
  Replaces: bash-completion (<< 1:2.1)
  Replaces: systemd (<< 224-2)

???

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

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

Так основной посыл ненависти к systemd это якобы повышение вероятности «нарваться на новые ошибки»? Как-то знаете ли неубедительно звучит. Переход на systemd состоялся и никаких серьёзных проблем не было.

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

Это всё очень напоминает искусственную травлю, я вот только всё никак не пойму на чей хвост так больно наступил systemd, но учитывая методы травли - нелепые надуманные предлоги, похоже на то что сказать прямым текстом «systemd наступил на хвост вот этим людям» нельзя т.к. сообщество Linux видимо не посчитает «хвост вот этих людей» достойным своей защиты.

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

Пробрасывает иксы, произвольные порты,

Именно. Обеспечивает шифрованный канал передачи для чего угодно. Или ты думал, что это замена telnet ?

и обслуживает локальные каталоги по SFTP?

SFTP - это клиент вообще-то. На стороне сервера он не нужен.

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

Обеспечивает шифрованный канал передачи для чего угодно.

Если бы sshd представлял собой этакий netcat с диффи-хеллманом и асимметричной аутентификацией — тогда я был бы с тобой согласен. Но это не так.

Так что вот мой ответ: «systemd делает ровно то, для чего предназначен: обеспечивает полнофункциональную и контролируемую среду для выполнения прикладных программ».

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

Да. Его задача - http. Даже ftp не поддерживает. :-)

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

Он предназначен для чего-то, кроме телефонии ?

Так и про системд можно сказать «он предназначен для чего-то, кроме менеджмента системы?»
В том-же астериске куча всего, к примеру есть http сервер, клиенты к разным базам данных, интерпретатор своего языка, интерпретатор lua и прочая фигня...

Dovecot юниксвей?

Тут сложнее, я, если честно, только начал с ним детально разбираться. С ходу скажу что там есть сортировщик писем, imap/pop3, авторизация и куча всего.

Я часто пишу авторизация, потому-что юниксвей авторизация - дергать /bin/login, при желании заворачивая трафик в что-то вроде openssl, разумеется пайпом. )


Он делает ровно то, для чего предназначен. А ftp там разве есть ? Впрочем, если есть, то это - мелочь.

Ну так и про системд можно сказать.

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

Так основной посыл ненависти к systemd это якобы повышение
вероятности «нарваться на новые ошибки»?

Дошло, что ли ? Только слово «якобы» тут лишнее.

Переход на systemd состоялся и никаких серьёзных проблем не было.

Были. На одну серьёзную я уже в начале этой темы указывал, со ссылкой на проблему на моём буке в январе. А были и ещё.

То же ядро можно новое поставить рядом со старым, сказать lilo -R new_label, после чего вернуться банальным reset (в Grub тоже что-то такое родили), а что сделать с комбайном, который уложит систему при обновлении ?

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

Или ты думал, что это замена telnet ?

Ты точно не виртуал этого укуренного «ветерана»? Это замена rsh. Слово «shell» в названии ни о чём не говорит?

SFTP - это клиент вообще-то. На стороне сервера он не нужен.

/usr/lib/sftp-server

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

«The mod_ftp module» - какое слово перевести ?

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

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

???

В репозитарий новые udev, systemd и прочая братия попадают _одновременно_. Нельзя собирать systemd со старым udev. Точнее, наверное, можно иногда, но это куча головной боли и неподдерживаемое теперь апстримом решение. А полный список подпакетов на полтора-два десятка. Включая journal, login и прочее.

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

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

У systemd совершенно другая реализация к подходу разработки. Ты не обязан обновлять плагины Апача при каждом обновлении самого сервера. Часто достаточно пересобрать старый с новой версией.

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

В репозитарий новые udev, systemd и прочая братия попадают _одновременно_.

«Репозиторий». Ну так не обновляй одновременно. Или у тебя RHEL, в котором так нельзя?

А полный список подпакетов на полтора-два десятка. Включая journal, login и прочее.

Где???

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

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

Апач банально старый проект. Там уже внутренний API стабилизировался.

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

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

А полный список подпакетов на полтора-два десятка.
Включая journal, login и прочее.

Где???

Что ? Где-то, вообще, в одном пакете ? :-)

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

Думаю плагины systemd, которые используют стабильный
набор функций тоже не нужно пересобирать после обновления.

Зачем тогда это в рамках одного цельного дерева исходников всё распространяется, а не раздельно ?

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

строго-говоря двоичные «палагины» это не крутой юникс-вей.
хороший юникс-вей это открытые протоколы через стандартный ввод-вывод. например, i3wm в нормальном дистре идет отдельно от i3status поскольку оконный менеджер со статус панелью общается по оговоренному протоколу. таким образом я могу установить враппер на пидоне (py3status ) который поддерживает клики мышью (например) и тд.

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

Ну ладно, уговорил. Но, всё равно, тут всё около одного направления.

Смех, смехом, но и весь системд около одного направления - нормальная системная прослойка.
Зачем? Ну хотя-бы затем, что бы мне не приходилось костылить свою реализацию мультисита на баш-лапше.
Или можно было управлять терминальным сервером на уровне сессий.
Тот-же loginctl позволяет столько старых костылей выбросить, что аж дух захватывает.

$ loginctl list-sessions 
   SESSION        UID USER             SEAT            
        c4       1001 ksu              seat0           
        c3       1000 yar              seat1
$ loginctl session-status c4
c4 - ksu (1001)
           Since: Ср 2016-05-18 18:37:48 YEKT; 6 days ago
          Leader: 24990 (lightdm)
            Seat: seat0; vc7
         Display: :1
         Service: lightdm; type x11; class user
         Desktop: xubuntu
           State: active
            Unit: session-c4.scope
***список процессов

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

Для сравнения выхлоп who, старого способа узнать кто залогинен:

$ who
yar                   2016-05-18 18:14 (:0)
yar      pts/4        2016-05-18 18:14 (:0.0)
yar      pts/10       2016-05-18 18:15 (:0.0)
yar      pts/12       2016-05-18 18:26 (:0.0)
yar      pts/16       2016-05-18 18:27 (:0.0)
yar      pts/19       2016-05-18 18:36 (:0.0)
ksu      tty7         2016-05-18 18:37 (:1)
yar      pts/1        2016-05-18 20:53 (:0.0)
ksu      pts/3        2016-05-18 22:47 (:1.0)
yar      pts/9        2016-05-19 12:28 (:0.0)
yar      pts/17       2016-05-20 01:14 (:0.0)
yar      pts/20       2016-05-20 02:00 (:0.0)
yar      pts/23       2016-05-20 15:20 (:0.0)
yar      pts/24       2016-05-20 17:46 (:0.0)
yar      pts/25       2016-05-20 21:51 (:0.0)
yar      pts/26       2016-05-21 22:06 (:0.0)
yar      pts/28       2016-05-23 18:38 (:0.0)
yar      pts/27       2016-05-21 22:06 (:0.0)
yar      pts/29       2016-05-21 22:09 (:0.0)
yar      pts/32       2016-05-24 01:10 (:0.0)
yar      pts/33       2016-05-24 01:24 (:0.0)
yar      pts/34       2016-05-24 13:59 (:0.0)
yar      pts/35       2016-05-24 18:52 (:0.0)

kir2yar
()
Последнее исправление: kir2yar (всего исправлений: 1)
Ответ на: комментарий от AS

Причём, в общем-то, это udev, а не systemd.

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

В предыдущей версии дистра был udev, но не было systemd. Проблем не было. Появился systemd - появилась проблема. Я думаю (не знаю - предполагаю), что у udev'а случилась какая-то беда то-ли с доступом к RTC, то ли с выдачей прав на этот RTC, то ли просто интерфейс RTC не ответил в заданный таймаут... Я хрен его знает, что там случилось - логов же нет, детализации загрузки нет, - ничего нет, на JTAG/UART тишина - висит на populating udev, и амба. И что делать с железякой, которая только что была живее всех живых, и померла сразу после апдейта*? ...откатывать. Откатил - sysvinit сразу показал лог загрузки, детальный, по каждому модулю, который подгрузил - вывел в UART данные об успехе/неуспехе... Притормозил чуть дольше на модуле rtc, проглотил его и пошел дальше... Выводы? Кто неустойку платить будет за один багнутый девайс, который в силу реакцию болотного газа со светом Луны в районе Йелоустона не захотел грузиться прямо сейчас? Блин. За девайс отвечают админы. Админам платит наниматель. Он вправе требовать бесперебойной работы, и выставлять счета за простой. Как представитель компании-исполнителя я не могу гарантировать заказчику бесперебойную работу при использовании сабжевого продукта.

Ровно то же самое относится к другому нашему заказчику - я не рекомендовал им отказываться от использования 6-й версии одного известного дистрибутива и обновлять её до 7-й версии, по причине перехода этого дистрибутива на ыныеуьв. Да и их админы просто кровью плакали перед руководством, чтобы не было этого перехода. Всё настроено, контейнеры тянутся из NoDB, разворачиваются, запускаются-гасятся, всё работает - им не нужен этот геморрой и непредсказуемость. Штрафовать за простои будут их, а не поттеринга...

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