LINUX.ORG.RU

Systemd 235

 , ,


0

1

После трех месяцев разработки вышел релиз Systemd 235. Основные изменения:

  • Поддержка automake прекращена. В качестве сборщика используется Meson, использующий инструментарий ninja.
  • Для unit-файлов представлены опции RuntimeDirectory и RuntimeDirectoryPreserve, позволяющие определить путь к runtime-каталогу (в иерархии /run или $XDG_RUNTIME_DIR) и поведение в отношении сохранения его содержимого после остановки unit-а. Например, указание RuntimeDirectory=foobar приведёт к размещению данных в каталоге /run/foobar и удалению после завершения работы сервиса, если для него не установлена опция RuntimeDirectoryPreserve;
  • По аналогии с RuntimeDirectory для unit-ов представлены опции StateDirectory, CacheDirectory, LogsDirectory и ConfigurationDirectory, позволяющие вынести данные состояния, кэша, логов и настроек в отдельные подкаталоги в иерархиях /var/lib/, /var/cache/, /var/log/ и /etc, содержимое которых сохранится между запусками сервиса. Дополнительно добавлены вспомогательные пары опций, определяющие режим доступа к каталога - StateDirectoryMode, CacheDirectoryMode, LogsDirectoryMode, ConfigurationDirectoryMode.
  • В Systemd-Jornald реализована более агрессивное кеширование из /proc/ , а также запись в /proc/, что позволило увеличить производительность записи логов при большой нагрузке. Так как метаданные читаются в асинхронном режиме, их состояние может немного запаздывать относительно выводимых в лог записей. Владельцам SSD с TLC-памятью рекомендуется быть поосторожнее.
  • В unit-ы добавлена опция IPAccounting, при включении которой для сервиса добавляются счётчики с данными о трафике и числе пакетов. Данные о трафике можно посмотреть через «systemctl status» или «systemd-run --wait»;
  • Обеспечено сохранение в логе сведений о потреблении ресурсов CPU и трафике. Запись создаётся при каждой остановке юнита, если включены опции CPUAccounting или IPAccounting;
  • В unit-ах реализован Firewall, основанный на опциях IPAddressAllow и IPAddressDeny. Ограничения можно наложить как на входящий, так и на исходящий трафик.
  • В systemd-networkd представлена серия новых настроек, задаваемых через файлы .network: Scope (область достижимости) в секции [Address], ConfigureWithoutCarrier (игнорировать статус линка при настройке) в секции [Network], Anonymize (включение опций анонимного профиля RFC 7844) в секции [DHCP], Type (определение спецмаршрутов для направления трафика в blackhole/unreachable/prohibit) в секции [Route]. Добавлена новая секция [RoutingPolicyRule] для задания правил маршрутизации;
  • В файлы .netdev добавлены опции: Table в секции [VRF] для выбора используемой таблицы маршрутизации, Independent в секции [Tunnel] для настройки туннеля независимо от связанного с ним сетевого интерфейса, GroupForwardMask в секции [Bridge] для настройки распространение локальных сетевых кадров между портами сетевого моста;
  • В файлах .link добавлены новые режимы работы опции WakeOnLan, добавлена настройка TCP6SegmentationOffload для включения аппаратного ускорения обработки сегментов TCP/IPv6;
  • В реализацию сервера для анонса маршрутов IPv6 (Router Advertisment) добавлена поддержка отправки записей RDNSS и RDNSSL для передачи настроек DNS;
  • В systemd-nspawn добавлен флаг "--system-call-filter" для добавления и удаления элементов из применяемого по умолчанию фильтра системных вызовов. Реализована возможность определения белых списков системных вызовов с запретом всех остальных (ранее предлагались черные списки);
  • Добавлены новые фильтры групп системных вызовов: @aio, @sync, @chown, @setuid, @memlock, @signal и @timer, которые можно указывать через опцию SystemCallFilter или флаг "--system-call-filter";
  • В опцию ExecStart для unit-файлов добавлены два новых модификатора: При указании префикса "!" команда запускается без смены идентификатора пользователя/группы (без вызова setuid/setgid/setgroups). Второй модификатор "!!" идентичен "!" за исключением того, что его действие игнорируется на системах с поддержкой наследования расширенных прав (capabilities PR_CAP_AMBIENT, появились в ядре 4.3);
  • В systemd-run добавлен флаг "--pipe", при котором в вызываемый сервис systemd передаются файловые дескрипторы на STDIN/STDOUT/STDERR, что позволяет использовать его в цепочке с другими утилитами в shell с передачей данных через неименованные каналы;
  • Для каждого сервиса обеспечено поддержание счётчика перезапусков, который можно посмотреть командой «systemctl show -p NRestarts сервис».
  • Для unit-файлов реализована новая опция LockPersonality, позволяющая на лету привязать сервис к выбранному домену выполнения;
  • В поставку добавлен файл для modprobe.d, обеспечивающий переопределение параметров модуля bonding для корректного управления интерфейсом bond0 из systemd-networkd;
  • В journald.conf добавлена включенная по умолчанию настройка ReadKMsg, управляющая чтением лога ядра в systemd-journald, а также опция LineMax для задания максимального размера строки при выводе логов через STDOUT/STDERR;
  • В nss-myhostname/systemd-resolved по умолчанию обеспечена генерация DNS-записей A/AAAA для хоста «_gateway» вместо ранее применяемого имени «gateway», так как оно используется для внутренних нужд некоторых дистрибутивов (старое поведение можно вернуть во время сборки);
  • Добавлен новый целевой юнит для пользовательских сеансов: «getty-pre.target», который выполняется до консольного входа в систему;
  • Для увеличения качества энтропии в генераторе псевдослучайных числе systemd теперь при запуске каждого виртуального окружения пытается загрузить модуль ядра virtio-rng.ko;
  • В /etc/crypttab обеспечена возможность применения опции _netdev, по аналогии с /etc/fstab, для организации настройки шифрованных устройств после запуска сети; Для подключения внешних обработчиков в cryptsetup.target добавлено два целевых юнита remote-cryptsetup-pre.target и remote-cryptsetup.target, решающих те же задачи, что remote-fs.target и remote-fs-pre.target в local-fs.target;
  • В сервисы добавлена опция UnsetEnvironment, позволяющая убрать любую переменную окружения, которая в обычных условиях будет передана сервису;
  • Команды «systemctl poweroff», «systemctl reboot», «systemctl halt», «systemctl kexec» и «systemctl exit» теперь всегда выполняются в асинхронном режиме, т.е. сразу возвращают управление, не дожидаясь фактического завершения операции;
  • В systemd-resolve добавлен флаг "--reset-server-features", при указании которого очищаются и перезапрашиваются ранее полученные сведения о возможностях вышестоящих DNS-серверов. Отправка данных в лог теперь включает сведения о всех используемых DNS-серверах.

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

★★

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

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

синтаксис ipfw

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

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

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

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

а любителю смысла в systemd ковыряться нет

Я не любитель. Мне с системами работать. Офисная работа с документами - это не моё (потому и вопросов столько). Вынужденная мера, так сказать. А вообще, мне нужно набираться знаний как системщику, админу.

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

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

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

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

любителю смысла в systemd ковыряться нет

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

h578b1bde ★☆
()

Гном, привязавшись к системГ, уже скатился. Дай Бог, чтобы разработчики КДЕ не связались с этим говнищем. Я же не против, хотите жрать говно, жрите, но зачем насильно заставлять всех пользователей GNU/Linux это делать? Из systemd-free дистрибутивов остались только gentoo, slackware, devuan, lfs.

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

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

Как попробовавший и то и другое могу сказать что ipfw-подобный синтаксис более вменяемый человекочитаемый, в то время как синтаксис правил iptables выглядит как привет с Марса.

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

Ждать хрен знает сколько времени для выключения компьютера — это ли удобно?

Странно, но оно у меня на ноуте больше не тупит при выключении. То ли дебиановцы что-то подкрутили, то ли Леня сходил к ортопеду.

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

Скажем дружно!

Системд НЕНУЖНО!

Раз в списке организаторов и участников хора такие хорошие люди - значит это хороший, годный хор. Не проходим мимо, не стесняемся, присоединяемся! :)

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

Ждать хрен знает сколько времени для выключения компьютера — это ли удобно?

Ввод в гугл запроса «Windows долго выключается» подсказывает, что Леня в этом совсем не новатор.

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

Внимание вопрос «осилятору» iptables: догадайся с одного раза, какой процесс начинает жрать 100% CPU

Это означает только одно: ты не освоил ipset. Иначе бы ты обошёлся как-то так:

iptables <bla-bla> -m set --match-set bad_guys src -j DROP

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

Ввод в гугл запроса «Windows долго выключается»

Зачем мне искать в гугле проблему которой у меня нет?

Леня в этом совсем не новатор

Хреновая отмазка — тоже отмазка, да.

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

Windows
Леня

Мне вот интересно, у системдолбанутых это так проявляется комплекс неполноценности или что? Пока иного объяснения притягиванию совершенно другой операционной системы в тред о системгэ я не вижу.

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

Зачем мне искать в гугле проблему которой у меня нет?

Так и у меня с выключением в systemd проблем нет.

Хреновая отмазка — тоже отмазка, да.

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

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

Так и у меня с выключением в systemd проблем нет.

Команды «systemctl poweroff», «systemctl reboot», «systemctl halt», «systemctl kexec» и «systemctl exit» теперь всегда выполняются в асинхронном режиме, т.е. сразу возвращают управление, не дожидаясь фактического завершения операции

Хвала Лёньке! Уже обновился, да?

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

Как попробовавший и то и другое могу сказать что ipfw-подобный синтаксис более вменяемый человекочитаемый, в то время как синтаксис правил iptables выглядит как привет с Марса.

Всё же вопрос привычки. Кстати, в ALT, если использовать etcnet для настройки netfilter, можно синтаксис ipfw использовать.

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

Ты это местному sd-positive расскажи

Ой прелесть какая :-) Отдельно доставляет явное преобладание категории sd-hater над всеми остальными.

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

Когда нет аргументов в споре

Ввод в гугл запроса


демагог сразу переходит на личности

в твоей любимой Виндоуз

Ну ты понял.

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

Отдельно доставляет явное преобладание категории
sd-hater над всеми остальными.

Сразу понятно, где, на самом деле, адекватные. :-)

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

Так и у меня с выключением в systemd проблем нет.

А у меня на трёх машинах проблемы есть.

И в твоей любимой Виндоуз она присутствует точно так же уже много-много лет.

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

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

Я осилил. Отсутствие в iptables транзакционности сразу делает его непригодным для применений вне ЛОРовских локалхостов с LA0. К счастью, nftables уже почти можно пользоваться. Мучаться осталось недолго.

anonymous
()

Когда я уже прочту «умер Поттеринг и его закопали вместе с systemd»?

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

К ipset бы ещё portset и ruleset… Но это nftables получится.

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

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

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

Отсутствие в iptables транзакционности сразу делает его непригодным

Только эта транзакционность никуда не сплющилась в большинстве случаев применения. А там, где она, всё же, нужна, можно обойтись ipset swap.

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

… закопать НЕНУЖНО!

... предварительно закопав ненужного леннарта.

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

Только эта транзакционность никуда не сплющилась на моём локалхосте

FTFY. То, что ты ещё не сталкивался с такой необходимостью, не значит, что её нет у других. ipset swap обойтись нельзя так как нужно атомарно менять не только связку IP:PORT, но и набор правил, не теряя при этом пакетов.

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

FTFY. То, что ты ещё не сталкивался с такой необходимостью, не значит, что её нет у других. ipset swap обойтись нельзя так как нужно атомарно менять не только связку IP:PORT, но и набор правил, не теряя при этом пакетов.

Приведи пример, когда это а) действительно надо и б) действительно не теряя. И в) невозможно сначала всё разрешить, потом снова воссоздать цепочки.

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

остались только gentoo, slackware, devuan, lfs

void, pc linux os, alt linux starterkit xfce (sysv)

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

а) действительно надо

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

б) действительно не теряя

nftables это делает не теряя пакеты. Такие дела.

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

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

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

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

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

nftables это делает не теряя пакеты. Такие дела.

Это хорошо, волшебно, приятно. Но я не готов это считать киллер фичей в подавляющем большинстве случаев. Гораздо полезнее, на мой взгляд, что там *tables объединили.

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

Ну раз не представляешь, то и ладно. Топик всё равно не об этом.

Ещё не очень представляю проблему потери пакета

А я совсем не представляю себе зачем делать говно, когда говно можно не делать. Agree to disagree?

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

А я совсем не представляю себе зачем делать говно,
когда говно можно не делать.

Наличие более одного DNS в конфигурации локального резолвера, прикинь, правило, а не исключение. А так-то да, можно трястись над единственным. И, всё же, как часто ты дёргаешь iptables на DNS-сервере ? И зачем. Прямо интересно, хотя и не по теме.

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

Да ладно, правда что ли?

Но ты не ответил на вопрос, как часто дёргаешь. Да, наверное nftables, а не iptables, но не суть.

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

И firewalld, таки, лучше ущербного iptables.

http://www.firewalld.org/documentation/concepts.html Вот и выросло поколение линуксоидов, котрые, повозив мышкой в кутяшном интерфейсе с д-басом к ... (нужное вписать), с серьезным видом говорят - вот это - хорошо, а ... (нужное вписать) - ущербный отстой.

И да, Linux никогда не вылезет из 1-2-3% на десктопе.

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

как часто ты дёргаешь iptables на DNS-сервере ?

Я ничего не дёргаю, автомат дёргает. iptables раз в сутки либо по сложному триггеру, у которого документация с разъяснениями его логики занимает две страницы, а nftables без сложностей, просто раз в пять минут±splay time.

И зачем

Затем же, зачем программисты тесты пишут — для доказательства корректности кода. В нашем случае — для доказательства корректности заданной конфигурации, и фаерволл это не единственное, за чем следит автомат. В идеальном мире вся система имела бы детерменированное состояние (кроме rng :). Но мир неидеален, поэтому детерменированы только основные компоненты — версии софта, содержимое конфигурационных файлов, UID/GID важных пользователей и т.п.

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

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

На боевом сервере эксперименты !?

и фаерволл это не единственное, за чем следит автомат.

Конфигурацию рабочую менять зачем, да ещё раз в пять минут. Вот что поясни.

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

На боевом сервере эксперименты !?

В мире единорогов и программистов всё можно посмотреть и потрогать на stage-сервере. В реальности многое можно увидеть только в проде на реальных сетевых соединениях с настоящими пользователями. Мир жесток. Приходится ходить в шлеме.

Конфигурацию рабочую менять зачем,

Затем же, зачем пишут новые версии софта. Для соответствия меняющимся требованиям времени.

да ещё раз в пять минут.

На самом деле есть одна задача: гарантировать сходимость конфигураций за приемлимое время. Мы тут немного угорели по добровольной кооперации независимых акторов, поэтому вместо того, чтобы логиниться на все 100500 хостов вручнуюансиблом по SSH, автомат на сервере сам решает исходя из текущей нагрузки, может ли он применить полиси и каким образом (системы могут по каким-то причинам отличаться от эталона в какой-то момент времени). Так как код для определения наличия изменений всегда слишком сложный, чтобы работать без сбоев и человека, автомат идемпотентно и декларативно приводит конфигурацию к эталонному виду. Пятиминутный интервал, выбранный разработчиками, является приемлимым в нашем случае. Я бы предпочёл моментальную реакцию, например завязанную на изменения inode, но Джеймс ещё не дописал mgmt до уровня, годящегося в прод.

Вот что поясни.

Хоть бы раз «пожалуйста» сказал.

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