systemd

[Радость]

Lennart Poettering, сотрудник компании Red Hat, представил концепцию принципиально нового механизма управления инициализацией системы -- systemd (system daemon), которая вобрала в себя достоинства классического System V init и более современных launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), но при этом лишена многих их недостатков. В разработке этого проекта ему помогали сотрудники Red Hat, Novell, IBM, Intel и Nokia.

systemd опирается на современные linux-технологии: cgroups, AutoFS, D-Bus, и при этом совместим с исторически устоявшимися механизмами: init-скриптами, стандартными командами shutdown, poweroff и т.п. Предоставляемый systemd функционал позволяет заменить не только систему инициализации, но и ряд других подсистем, в частности, cron, (x)inetd, xdm/kdm/gdm/..., частично даже SELinux.

Основные идеи, использованные при создании systemd:

[indent]

• Контроль над сокетами. Многие демоны, запускаемые при инициализации, взаимодействуют с другими демонами через unix domain и сетевые сокеты, и большинство существующих системы инициализации запускают демона-клиента только после того, как демон-сервер запустится и создаст сокет. Вместо этого, systemd создает сокеты, а затем запускает демонов, передавая им эти сокеты. Даже если демон-клиент запустится быстрее и начнет использовать сокет раньше сервера, ничего страшного не произойдет: его запрос будет буферизован и передан серверу, как только тот сможет его обработать. Такой подход уже используется в Mac OS X (launchd), позволяя этой ОС достигать впечатляющей скорости загрузки.Аналогичный принцип используется systemd и при запуске служб, использующих шину D-Bus.
  
  Кроме того, возможен автоматический запуск служб при обращении к заданным сокетам (см. ниже).

• Фоновое монтирование. Такие операции, как монтирование, проверка и активация квот файловых систем, занимают весьма значительную долю загрузочного времени. В большинстве современных систем они выполняются последовательно, до запуска всех демонов. systemd же предлагает монтировать не-жизненно-важные ФС только тогда, когда они кому-то понадобятся. Для этого используется механизм AutoFS. Например, многие служебные демоны вовсе не обязаны ждать, пока смонтируется огромный и к тому же зашифрованный /home. Разумеется, этот подход неприменим к /, /proc, /sys и т.п.

• Минимизация числа вспомогательных процессов. В настоящее время значительная часть работ по инициализации производится шелл-скриптами, что приводит к колоссальным времязатратам. В частности, Леннарт пишет:

On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74,

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

В качестве альтернативы Леннарт предлагает предлагает переписать критичные участки на C, а также вынести часть функционала в самих демонов и в systemd. Сейчас для systemd уже готовы написанные на C подсистемы монтирования и установки имени хоста. До полной победы, отмечает Леннарт, работа предстоит огромная, но результат того стоит.

• Отслеживание процессов. В ныне используемых системах инициализации в принципе возможна такая ситуация, когда при неправильном форке процесс может «потеряться». Например, так может произойти с некорректно написанным CGI-приложением, и процесс останется работать даже после остановки веб-сервера.Для предотвращения таких ситуаций systemd использует интегрированный в ядро Linux механизм контрольных групп (cgroups). Если приложение не имеет доступа к псевдо-ФС, управляющей работой cgroups, то оно не может самостоятельно покинуть свою группу и «потеряться».
  
  Также к этой группе задач относится и автоматический перезапуск демонов, перенаправление их stdout/stderr на выбранные TTY или в системный журнал, регистрация всех запусков и остановок служб, и многое другое.

• Ограничение процессов. systemd предоставляет множество возможностей ограничить или расширить полномочия процессов, контролируя такие параметры, как uid, gid, umask, рабочий и корневой каталоги, класс и приоритет CPU и I/O, наличие доступа на чтение и запись к смонтированным файловым системам и отдельным каталогам и т.п. Также можно использовать возможности по ограничению ресурсов, предоставляемые cgroups.

Базовым элементом systemd являются модули (units), которые связаны между собой и имеют определенный тип. Каждый модуль может требовать для своей работы другие модули, конфликтовать с модулями, запускаться только после или до определенного модуля (директивы конфигурации Requires, Conflicts, Before, After, Wants). Из типов модулей определены:

• service -- обычный демон, поддерживающий операции start, stop, restart, reload. Может быть представлен родным (native) файлом конфигурации systemd или System V init-скриптом.
• socket. При обращении к сокету генерируется событие, для которого можно настроить обработчик. Например, автоматически запускать определенные службы при обращении к заданному сокету. В этом отношении systemd похож на давно известный (x)inetd, однако при этом поддерживает unix domain сокеты и FIFO.
• device. Отметив нужные устройства в конфигурации udev, впоследствии можно использовать такие события, как появление и удаление устройства, в качестве событий systemd, назначив на них обработчики. Например, при появлении устройства bluetooth будет запущена соответствующая служба.
• mount. systemd контролирует все точки монтирования файловых систем. В целях обратной совместимости поддерживается сбор информации о точках монтирования из /etc/fstab.
• automount. Для помеченных таким образом точек монтирования, монтирование выполняется только при обращении к ним.
• target. Более гибкий аналог уровней исполнения (runlevels), используемых в System V init. Представляет собой группу служб, объединенных по функциональному назначению. Например, multi-user.target идентичен runlevel 5, а bluetooth.target приводит к инициализации подсистемы bluetooth.
• snapshot -- во многом похож на target. Позволяет «запомнить» существующую конфигурацию units (запущенных служб, открытых сокетов, смонтированных ФС) с тем, чтобы в дальнейшем восстановить это состояние. Позволяет, например, перейти в emergency shell (сейчас это init 1), а затем полностью восстановить набор запущенных служб. Другой пример -- выход системы из состояния suspend.

Надо заметить, что systemd отличается от SMF, во-первых, тем, что позволяет оперировать не только зависимостями между службами, но и событиями, например, «готовность устройства» или «обращение к сокету». Во-вторых, systemd использует более простой формат файлов конфигурации (.desktop aka .INI против XML в SMF).

От upstart же systemd отличается более высокой степенью параллелизации, и как следствие, более высокой скоростью загрузки. Например, если демон A требует для работы сокет, открытый демоном B, то upstart сначала запустит демона B, а затем демона A, в то время как systemd создаст сокет сам и запустит обоих демонов одновременно, что занимает примерно в два раза меньше времени. Используемый в upstart принцип, когда ключевыми событиями является лишь запуск и остановка демона, Леннарт и его коллеги считают изначально неэффективным.


[/indent]# Источник

[Rubik]

[size="3"][color="#3399ff"]30.04.2010 23:47[/color][/size][size="3"] systemd - новая система инициализации от разработчиков Red Hat и Novell [/size]

Леннарт Поттеринг (Lennart Poettering), создатель звукового сервера PulseAudio, работающий в компании Red Hat, при участии разработчиков из компаний Novell, IBM, Intel и Nokia, подготовил прототип принципиальной новой системы инициализации для Linux - systemd, нацеленной на более интенсивную параллелизацию выполнения сервисов на этапе загрузки.

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

После построения плана выбирается наиболее оптимальный вариант параллельного запуска сервисов и сокращается повторный вызов программ (например, awk в процессе инициализации запускается около 92 раза, grep - 77 раз) и повторное обращения к типовым ресурсам (например, чтение значения таймера или получение параметров сетевого интерфейса). Процессы вызываются только при необходимости, т.е. например, CUPS не будет запущен до того, как локально или удаленно не будет обращения к сервису печати. Кроме обслуживания процесса загрузки, systemd выполняет также такие функции как управление процессами в системе и обеспечение корректной работы системы с новым динамически подключаемыми устройствами.

Базовым элементом systemd являются "юниты", которые связаны между собой и имеют определенный тип. Каждый юнит может требовать для своей работы другие юниты, конфликтовать с юнитами, определять возможность запуска только после или до определенного юнита (директивы конфигурации Requires, Conflicts, Before, After, Wants). Например, устройство может зависеть от сервиса, который должен быть запущен сразу после доступности устройства. Из типов юнитов определены:

• Сервисы: стандартные демоны, которые могут быть запущены и остановлены. В роли сервисов также могут выступать классические SysV-скрипты инициализации.
• Сокеты: точки привязки к сетевым или файловым сокетам, позволяющие построить ассоциацию с определенным сервисом. Например, в через сокет-юнит может быть задан сетевой порт, при обращении к которому автоматически должен быть вызвать определенный сервис (аналог inetd).
• Устройства: элементы дерева устройств, которые могут обрабатываться с помощью udev.
• Точки монтирования: задают используемые файловые системы, которые встречаются в /etc/fstab;
• Точки автоматического монтирования (automount): определяет какую ФС смонтировать при обращении к заданной директории.
• Цели: логические юниты для логической группировки юнитов. Например, multi-user.target идентичен run-level 5, bluetooth.target приводит к инициализации подсистемы bluetooth.
• Снапшоты: логические юниты для запоминания и восстановления определенного состояния системы.

opennet.ru

[size="3"][color="#3399ff"]07.07.2010 12:07[/color][/size][size="3"] Вышла первая версия системы инициализации systemd [/size]

Леннарт Поттеринг (Lennart Poettering), сотрудник компании Red Hat, создавший в свое время звуковой сервер PulseAudio, официально представил первый релиз системного менеджера systemd. systemd является альтернативной системой инициализации Linux, вобравшей в себя достоинства классического System V init и более современных launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), но при этом лишенной многих их недостатков.

systemd (system daemon) реализует принципиально новый подход к инициализации и контролю работы системы. Одним из ключевых новшеств этого подхода является высокая степень параллелизации запуска служб при инициализации системы, за счет активного использования возможностей сокетов, что в перспективе позволяет добиться гораздо более высокой скорости, чем традиционный подход с последовательным запуском взаимозависимых служб, используемый, например, в upstart. Другим важным моментом является контроль над точками монтирования (не-жизненно-важные файловые системы можно монтировать только при первом обращении к ним, не тратя на это время при инициализации системы) и устройствами (можно запускать и останавливать определенные службы и при появлении или удалении заданных устройств). Для отслеживания групп процессов используется механизм cgroups, который также может быть использован для ограничения потребляемых ими системных ресурсов.

С момента прошлого анонса Леннарт и его коллеги проделали огромную работу, и выход первого официального релиза является важной вехой в развитии проекта -- теперь systemd готов к эксплуатации. Пакеты с systemd v1 уже включены в Fedora Rawhide и openSUSE Factory. Также подготовлены сборочные скрипты для дистрибутивов Arch и Gentoo. Проект Debian, как всегда, нетороплив -- на данный момент в experimental находится git-снапшот месячной давности. Все эти дистрибутивы полностью поддерживаются systemd. Что касается Ubuntu, то разработчики этого дистрибутива не проявили никакой заинтересованности в проекте, и поэтому поддержка инфраструктуры и готовые пакеты для данного дистрибутива отсутствуют.

opennet.ru

[Rubik]

[size="3"][color="#3399ff"]23.08.2010 23:31[/color][/size][size="3"] Отчет о развитии systemd [/size]

Леннарт Поттеринг, ведущий разработчик перспективной системы инициализации systemd, рассказал о ключевых достижениях в разработке данного программного продукта:

• В настоящее время systemd уже принят в состав выпуска Fedora 14 и отлично зарекомендовал себя в предварительном тестировании, поэтому скорее всего именно он будет использоваться в Fedora 14 в качестве системы инициализации по умолчанию.
• Добавлены новые конфигурационные единицы (юниты): timer-юниты для активации событий по таймеру (в стиле cron), swap-юниты, позволяющие централизованно управлять swap-разделами и swap-файлами, и path-юниты, обеспечивающие реагирование на события inotify (например, изменение заданного файла или появление файлов в определенном каталоге).
• Реализована поддержка SELinux: создаваемым объектам (каталогам, сокетам, FIFO) автоматически присваиваются корректные метки безопасности.
• Выполнена интеграция со стандартной аудит-подсистемой ядра Linux: systemd отчитывается обо всех операциях запуска/остановки служб.
• Добавлена поддержка TCP-оберток (wrappers) для обслуживаемых сокетов.
• Обеспечена поддержка PAM при запуске служб под отдельными пользователями (при открытии и завершении сеанса выполняются соответствующие хуки PAM).
• Реализована поддержка D-Bus: все D-Bus службы могут контролироваться systemd точно так же, как и обычные SysV-службы. За счет использования буферизующих возможностей шины и сокетов, обеспечивается эффективное распараллеливание запуска серверов и клиентов (перед запуском клиента уже необязательно дожидаться окончания запуска сервера -- их можно запустить одновременно, и если запрос клиента придет раньше, чем сервер сможет его обработать, то этот запрос просто задержится в буфере до нужного момента).
• Обеспечен парсинг специфичных для Debian и openSUSE расширений формата SysV-скриптов (для Fedora такая поддержка была изначально).
• Завершена доработка управляющего D-Bus-интерфейса к systemd, обеспечивающего полный доступ к текущей конфигурации. Используя такие утилиты, как gdbus или d-feet, администратор может просматривать всю интересующую его информацию и при необходимости отдавать команды.
• Добавлен PAM-модуль, который обеспечивает полный контроль над завершением всех пользовательских процессов по окончании сеанса (для отслеживания процессов используется механизм cgroups).
• Добавлена утилита systemd-cgls, выполняющая рекурсивный вывод иерархии контрольных групп (cgroups).
• Реализована сама иерархия контрольных групп (в настоящий момент управляющая псевдо-ФС, отражающая эту иерархию, монтируется в /cgroup/systemd, однако перед выпуском Fedora 14 ее планируется перенести в недра /sys/fs/).
• Поддерживается запуск getty для serial-консолей.
• Значительно улучшена основная управляющая утилита systemctl (например, поддерживается вывод графа зависимостей в формате Graphviz). Также улучшены средства, эмулирующие работу классических утилит SysV (halt, shutdown, runlevel, telinit) -- теперь соответствующие программы из комплекта systemd могут работать не только под systemd, но также под Upstart и SysV, что должно упростить процесс миграции. Кроме того, обеспечена отправка уведомлений в том случае, если файлы конфигурации systemd были изменены, а команды перечитать их не поступало.
• Подготовлен пример реализации демона, эффективно использующего возможности, предоставляемые systemd.
• Также подготовлен комплект документации по основным компонентам systemd, включая рекомендации по разработке демонов с учетом специфики systemd.
• Некоторые программные продукты уже включает в комплект поставки конфигурационные файлы для systemd, что обеспечивает корректную работу таких программ в любом дистрибутиве, поддерживающем systemd. В планы Леннарта и его коллег входит унификация процесса загрузки и управления службами во всех этих дистрибутивах, и определенные результаты уже достигнуты. Кроме того, в ряд проектов уже приняты присланные разработчиками systemd патчи, обеспечивающие эффективное использование возможностей socket-based активации (в стиле inetd).
• Добавлено множество опций, определяющих среду исполнения процессов и сокетов (лимиты на системные ресурсы, ограничения безопасности и т.п.).
• Леннарт Поттеринг приступил к публикации цикла статей «systemd for Administrators».
• Функциональность практически всех скриптов, обеспечивающих запуск и остановку Fedora, реализована «с нуля» в отдельных быстрых, простых и компактных C-программах, и частично в самом systemd. И хотя многие из этих наработок, к сожалению, не будут задействованы в выпуске Fedora 14, все они включены в состав systemd, и их полная активация обеспечивает быструю, эффективно распараллеленную загрузку, причем PID первого пользовательского терминала должен быть уже меньше пятисот. К выпуску Fedora 15 Леннарт и коллеги планируют подготовить полностью бескостыльный (shell-less) процесс загрузки.
• В systemd реализован уникальный механизм обеспечения работы регистратора /dev/log, в перспективе позволяющий сохранить все лог-записи, начиная от первого запуска systemd на раннем этапе загрузки и заканчивая моментом halt'а системы. Вкратце, идея состоит в следующем: в те периоды времени, когда syslog-демон недоступен (до его запуска в начале загрузки, после его остановки при завершении работы, во время его перезапуска и т.п.) регистрация событий производится средствами ядерного лог-буфера (kmsg). Если syslog-демон по какой-то причине становится неработоспособен, все системные события можно узнать из вывода dmesg. В дальнейшем, если syslog-демон все-таки поднимется, эта информация будет распределена по заданным в его конфигурации приемникам (лог-файлам, удаленным серверам логгирования и т.п.). В том случае, если подъем syslog-демона больше не ожидается (например, при остановке системы), содержимое ядерного лог-буфера может быть выведено на терминал (или serial console, или netconsole, и т.п.). Особый интерес эта возможность представляет для встраиваемых систем, в которых теперь можно обходиться вообще без демона системного лога (преимущества: меньше нагрузка на процессор, отсутствие дискового ввода-вывода, возможность доступа к логу через последовательную или сетевую консоль).
• Подготовлены конфигурационные файлы для монтирования средствами autofs ряда виртуальных файловых систем ядра (binfmt_misc, hugetlbfs и т.п.). Теперь эти файловые системы монтируются автоматически при первом обращении к ним, и программам, использующим данные ФС, больше не требуется самостоятельно подгружать соответствующие модули ядра перед началом работы. Во многих случаях это означает, что таким программам больше не нужны root-привилегии даже на этапе инициализации, что делает их более безопасными, и упрощает процесс их запуска.
• Огромное количество мелких исправлений и улучшений.

opennet.ru
 

[Rubik]

[size="3"][color="#3399ff"]20.11.2010 11:00[/color][/size][size="3"] Второй отчет о развитии системного менеджера systemd [/size]

Леннарт Поттеринг, возглавляющий разработку перспективной системы инициализации systemd, представил очередной отчет о развитии проекта, приуроченный к его 13-му релизу.

Ключевые моменты:

• Уже сейчас, в составе Fedora 15/Rawhide, systemd 13 способен обеспечить полноценную загрузку системы без использования shell-скриптов. Однако, все еще существуют отдельные ситуации, когда без скриптов обойтись невозможно, в частности:
  • Включен autoswapping (Леннарт отмечает, что это в любом случае не лучшая идея);
  • Требуется полная переустановка меток SELinux;
  • Выполняется первая загрузка после установки системы;
  • Производится загрузка модулей ядра, сконфигурированная без использования соответствующего штатного механизма systemd;
  • Производится загрузка с доступной только на чтение NFS;
  • Задействованы LVM/RAID/Multipath.
  Во всех остальных случаях, используя Fedora 15/Rawhide, вы уже сейчас можете полностью избавиться от скрипт-костылей и насладиться невероятно быстрой загрузкой. Что касается перечисленных ситуаций, то Леннарт и его коллеги интенсивно работают над расширением возможностей systemd, так что, вероятно, к выходу Fedora 15 список таких неудобных ситуаций будет сильно сокращен.
• Подготовлен написанный на C инструмент, обеспечивающий корректную остановку системы, включая остановку всех процессов, отмонтирование всех файловых систем, отключение всех loopback-устройств и томов Device Mapper (LVM, Multipath, etc.). Все эти операции производятся по тщательно продуманному алгоритму, обеспечивающему их корректное выполнение практически в любой ситуации. Например, большинство современных скрипт-костылей оставляют смонтированной файловую систему, если на ней находится файл, подключенный к loopback-устройству, что приводит к необходимости запуска fsck для данной ФС при следующей загрузке. systemd в такой ситуации, выполнив отключение loopback-устройств, повторно попытается отмонтировать еще смонтированные ФС. Отметим, что данный модуль может быть использован как после полной остановки всех служб (обычное выключение/перезагрузка), так и без нее -- в последнем случае он предоставляет корректную и безопасную замену действиям halt -f/reboot -f.
• В systemd добавлена базовая реализация упреждающего чтения (read ahead) с HDD и SSD-накопителей, использующая новейшие возможности ядра Linux, такие, как fanotify(), fadvise() и mincore(). Леннарт отмечает, что полученное в результате ускорение процесса загрузки должно проявляться на любых компьютерах, однако оно будет особенно заметно на старых и медленных машинах.
• Подготовлен, написанный на C модуль, выполняющий запуск fsck и активацию квот файловых систем с обеспечением максимально возможной степени параллелизации операций.
• Каждая служба, каждый пользователь и каждый пользовательский сеанс выделяются в собственную контрольную группу по CPU-ресурсу, что позволит «из коробки» получить ту самую «killer feature» (высокую отзывчивость сильно нагруженной системы) без наложения дополнительных патчей на ядро или использования небезопасных и не вполне универсальных решений.
• systemd предоставляет интерфейс протоколирования /dev/log, действующий с ранней стадии загрузки до момента полной остановки системы. В том случае, если демон системного лога не запущен, запись ведется в буфер ядра (kmsg). После запуска этого демона, накопленные лог-записи обрабатываются им согласно соответствующим настройкам. Таким образом, systemd позволяет обеспечить регистрацию событий в системе практически на все время ее функционирования. Подробнее о концепции этого механизма и его достоинствах можно почитать в прошлом отчете.
• Добавлена команда «systemctl kill», обеспечивающая отправку заданного сигнала всем процессам определенной службы, таким образом, обеспечив ее корректную остановку. Этим systemd отличается от классических механизмов вроде «kill `cat /var/run/daemon.pid`», которые в некоторых случаях допускают возможность продолжения работы порожденных службой процессов (например, некорректно форкнувшегося и потерявшего связь с родителем CGI-процесса при остановке web-сервера). Подробнее об этих вопросах можно почитать в четвертой статье из цикла «systemd for Administrators».
• В systemd реализована возможность загрузки правил SELinux. Таким образом, один и тот же бинарник systemd может использоваться при загрузке как с initrd, так и без него. К удивлению самих авторов, systemd оказался первой (и пока последней) системой инициализации Linux, поддерживающей такую возможность.
• systemd обеспечивает настройку системной локали (соответствующих переменных окружения), которая автоматически наследуется всеми процессами в системе (и, разумеется, может быть перекрыта при необходимости).
• Добавлена штатная поддержка работы с шифрованными LUKS/dm-crypt томами, включая чтение настроек из /etc/crypttab. Особенно интересна модульная структура реализации запроса пароля, работающая с самыми различными агентами. Например, при загрузке пароль может быть запрошен через Plymouth или непосредственно в консоли, а при горячем подключении -- через графическую утилиту в составе GNOME или механизм wall. Также, при ручной активации юнита через команду «systemctl start», пароль может быть запрошен из той же консоли. Интерфейс взаимодействия агента запроса пароля с systemd очень прост, отмечает Леннарт, и предлагает разработчикам KDE лично убедиться в этом, создав собственную реализацию агента. С другой стороны, данная инфраструктура может использоваться для работы не только с шифрованными томами, но и вообще с любыми программными и аппаратными компонентами, запрашивающими некие пароли (например, шифровальными токенами).

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

• Механизм плагинов также используется в системе генераторов -- специальных программ, динамически формирующих файлы конфигурации юнитов (units) systemd. Таким образом можно, например, упростить развертывание большого количества виртуальных окружений на базе LXC или KVM, с сохранением полного централизованного контроля над ними.
• systemd берет на себя автоматическую очистку и формирование внутренней структуры «динамических» каталогов, таких, как /tmp, /var/run и /var/lock, что позволяет выносить их в tmpfs без дополнительных усилий.
• Реализовано измерение и регистрация длительности всех операций, происходящих при загрузке, что упрощает процесс выявления «узких мест».
• Обеспечивается корректное завершение сеансов пользователя. Раньше при остановке Linux отнюдь не редко встречалась ситуация, когда некоторые пользовательские процессы завершались позже всех демонов, просто потому, что они отделились от основного сеанса и не были завершены вместе с ним. С systemd такое исключено.
• Добавлена поддержка маскирования -- специального механизма, позволяющего полностью заблокировать запуск какой-либо службы. Обычный метод «systemctl disable», запрещая автоматический запуск службы, оставляет возможность для ручного запуска через «systemctl start». Маскирование, состоящее в создании в /etc/systemd/system символьной ссылки с именем соответствующей службы, указывающей на /dev/null, полностью блокирует как автоматический, так и ручной запуск службы.
• В файлах описания юнитов теперь можно использовать проверку некоторых условий, в частности, существования заданных файлов или наличия каких-либо файлов в заданном каталоге (проверка на непустой каталог), присутствие определенных параметров в командной строке ядра.
• В дополнение к классическим механизмам halt, reboot и poweroff, добавлена реализация перезагрузки через использование kexec, позволяющей избежать затрат времени на инициализацию BIOS, что особенно актуально для серверного оборудования, в котором этот период бывает достаточно длительным.
• Реализовано «умное» (в стиле zsh) дополнение опций systemctl для bash (требуется версия bash >=4.0).
• Andrew Edmunds добавил в systemd поддержку дистрибутива Ubuntu. Однако, пока что фирма Canonical не стремится интегрировать systemd в свой дистрибутив, предпочитая собственную разработку -- upstart, которая, к сожалению, использует не столь эффективные методы параллелизации и значительно уступает systemd по возможностям.
• Тем временем, разработчики Debian -- Michael Biebl и Tollef Fog Heen -- работают над полной интеграцией systemd в Debian, с возможностью загрузки системы без установленного пакета initscripts. Подробнее см. эту страницу в Debian Wiki. [Прим. перев.: заметим, что интеграцией systemd в Fedora и openSUSE занимаются его непосредственные разработчики -- Леннарт Поттеринг, сотрудник Red Hat, и Кай Сиверс (Kay Sievers), сотрудник Novell.]

opennet.ru
 

[Zhek@Ch]

[size="3"]Сравнение систем инициализации systemd, upstart и SysVinit [/size]

Приблизительно год назад Леннарт Поттеринг (Lennart Poettering), сотрудник компании Red Hat, создавший в свое время звуковой сервер PulseAudio, начал разработку новой системы инициализации и управления сервисами под названием systemd. На создание замены SysVinit, существующей уже несколько десятков лет со времён первых Unix систем, Леннарта сподвигли недостатки традиционной системы и её несоответствие реалиям нашего времени - появлению SSD-накопителей, обладающих практически нулевым временем поиска нужных данных и огромной скоростью, посему способных обеспечить параллельную загрузку информации. Другой проблемой SysVinit является её зависимость от множества достаточно тяжёлых и не очень быстрых приложений - bash, awk, sed и других, которые не отличаются скорой работы на встраиваемых системах. Учитывая, что Linux стал использоваться на серверах, где требуется повышенная отказоустойчивость, от SysVinit потребовалась возможность слежения и перезапуска сервисов в случае их краха, которую она не обеспечивала.

Первым дистрибутивом, где systemd будет использоваться по умолчанию станет Fedora 15, готовящаяся к выпуску в конце мая этого года. Разработчики OpenSUSE собираются использовать systemd в следующем стабильном релизе 12.1. Arch, Debian, Gentoo включают поддержку systemd в экспериментальном режиме. Разработчики Mandriva также планируют использовать systemd. Следует учитывать, что при использовании ядра с собственной конфигурацией, systemd требует включения некоторых параметров ядра.

Леннарт Поттеринг опубликовал развёрнутое сравнение systemd, upstart и SysVinit, которое не оставляет никаких сомнений в том, что systemd станет стандартом де-факто в мире Linux.



[indent][color="#555555"]^[1] Реализация упреждающего чтения в Upstart доступна в виде отдельного пакета ureadahead и требует наложения патча на ядро
^[2] Активация через сокеты в upstart является экспериментальной возможностью, а также не поддерживает сериализацию, поэтому вообще не подходит для этого.
^[3] Активация через шину для upstart доступна пока только в виде патча, который в основную ветку разработки ещё не принят.
^[4] реализация в upstart не является практичной.
^[5] Данная возможность для upstart существует в виде отдельного пакета и работает только для монтирования во время загрузки, плохо поддерживая зависимости.
^[6] Некоторые дистрибутивы реализуют эту возможность с помощью shell скриптов.
^[7] Скрипты инициализации LSB поддерживают это, в случае если они используются. [/color][/indent] Также systemd предлагает огромные возможности по установке параметров запускаемых сервисов:

• параметры OOM;
• рабочая директория;
• root-директория (аналог chroot);
• переменные среды;
• переменные среды из внешнего файла;
• ограничения по ресурсам;
• umask;
• user/group ID;
• приоритет и класс ввода/вывода;
• Настройки CPU (привязка к ядрам, приоритет, значение nice, сброс параметров для форка процессов);
• и многое другое.

# opennet.ru

[Zhek@Ch]

[size="3"]Systemd 29[/size]
 
16 июня, тихо и незаметно вышла 29-ая версия новой системы инициализации для Linux. Среди её возможностей основными являются:

• событийно-ориентированная система параллельного запуска сервисов;
• управление через dbus;
• упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C для управления консолью, установки локали, запуска fsck, монтирования файловых систем и др.;
• возможность запуска сервисов по появлению данных в сокете, запуску или остановке других сервисов, наличию подключённых устройств или смонтированных файловых систем;
• встроенное упреждающее чтение с диска;
• интеграция с cgroups;
• совместимость со старыми скриптами, предназначенных для использования с SysVinit.

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

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

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

Будем надеяться, что в следующей 30 версии мы увидим эти новые фичи.

>>> Исходники

>>> О systemd и ссылки

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

# linux.org.ru

[Zhek@Ch]

[size="3"]Разработчики systemd представили Journal, замену системе syslog [/size]

Леннарт Поттеринг (Lennart Poettering) представил в своём блоге Journal, дополнение к системному менеджеру systemd, призванное заменить собой службу syslog и другие сопутствующие сервисы журналирования событий. Разработка пока находится на начальной стадии, прототип с реализацией базовой функциональности можно найти в Git-репозитории systemd. Первую экспериментальную реализацию Journal планируется интегрировать в дистрибутив Fedora 17.

Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов. Как правило, первым делом после взлома злоумышленники пытаются замести следы и вычистить из системных логов записи, выдающие их активность. Используемые в настоящее время реализации службы syslog беспомощны перед такими действиями. В Journal для решения данной задачи планируется задействовать средства обеспечения целостности, похожие на те, что используются в Git. Каждой записи в журнале будет сопоставлен хэш, который по цепочке будет охватывать хэши предыдущих записей. Используя отдельно сохранённый эталонный начальный хэш, который недоступен атакующему (без этого хэша нет возможности воссоздать всю цепочку подтверждений), можно легко проверить неизменность всего лога.

Journal будет частью systemd и не сможет использоваться обособленно. Все логи будут проиндексированы и храниться в бинарных файлах, к которым к сожалению будут неприменимы стандартные утилиты обработки текстовых данных, например, grep. Тем не менее, Journal не исключает параллельное использование традиционных syslog-служб, таких как rsyslog и syslog-ng. Каждая запись в БД Journal содержит набор параметров в формате "переменная=значение". С целью обеспечения структурирования информации, переменные могут создаваться произвольно. Кроме текстовых данных допускается прикрепление бинарных дополнений, которые могут содержать такие данные, как core-дампы, данные мониторинга SMART и диагностические дампы SCSI.

По своему формату БД Journal является комбинацией классических линейных логов и идей, используемых в репозитории Git. Как в случае с обычными логами, данные добавляются в конец БД с небольшим изменением служебных заголовков в начале файла. Данные хранятся в сжатом виде. Каждое поле в блоке данных сохраняется как независимый объект, что позволяет минимизировать потребление дискового пространства при наличии типовых значений (например, при сохранеии поля с именем хоста, если такое имя уже было в логе, вместо дублирования информации будет помещена ссылка). Сообщения от непривилегированных пользователей размещаются в отдельных файлах БД, привязанных к логину пользователя. Подобный подход позволяет ограничить доступ к логам только для их владельцев (для доступа к системным логам пользователь должен входить в специальную группу).

Для отправки подлежащих журналированию сообщений может быть использован стандартный API syslog(3), поэтому совместимость с приложениями будет сохранена. В будущем планируется реализовать ряд расширений, которые позволят из специализированных программ отправлять в лог не только строковые сообщения, но привязанные к ним метаданные и бинарные приложения. Каждая запись в логе имеет свой уникальный 128-разрядный идентификатор.

Для управления журналами будет подготовлен набор инструментов, которые позволят выполнять такие операции, как ротация, копирование, объединение и создание произвольных выборок. Ротация БД с журналом будет производиться автоматически, после превышения заданного лимита. С целью предотвращения утери логов дополнительно будет учитываться наличие свободного пространства на диске. Для защиты от атак, направленных на переполнение диска из-за разрастания лога, будут задействованы средства контроля за интенсивностью отправки сообщений (rate limit), при этом лимит будет автоматически корректироваться в зависимости от размера доступного места на диске. Выборку данных можно будет производить как по дате, так и по отдельным полям. Утилита для выборки данных автоматически будет охватывать и подвергнутые ротации файлы, т.е. весь архив логов будет виден как единое целое.

Кроме выполнения функций syslog, новая система сможет взять на себя ведение и других типов логов, таких как журнал входа в систему (wtmp), журнал начальной загрузки и логи системы аудита. Источником поступления сообщений может быть как стандартный интерфейс syslog(3), так и вызов printk() из ядра, а также различные специализированные API. В будущем рассматривается возможность перехвата сообщений от прошивок (логи UEFI) и задействование расширенных механизмов журналирования в ядре Linux. Начальная реализация Journal будет включать в себя только минимальную поддержку передачи логов по сети, которая будет ограничена простым копированием файлов БД на центральный хост при помощи scp, rsync или NFS. В будущем появятся более серьёзные средства для непрерывного приёма и отправки новых записей по сети.

Особенности Journal:

• Упрощение: небольшой размер кода с минимальным числом зависимостей;
• Автоматизация работы без необходимости ручного обслуживания: ведение журнала критически важная функциональность для отладки и мониторинга систем, поэтому работа должна вестись с оглядкой на возникновение внештатных ситуаций. Например, следует контролировать расходование свободного места в разделе /var и применять соответствующие методики ротации логов и ограничения интенсивности записи в лог;
• Устойчивость: файлы с логами должны быть непосредственно доступны для администраторов и пригодны для простого копирования по сети с использованием штатных средств, таких как scp, без нарушения целостности, даже если лог скопирован не полностью. Возможность анализа лога должна быть доступна без необходимости запуска демона журналирования, обслуживающего БД с логами;
• Переносимость: файлы с логами не должны зависеть от типа системы и CPU. Например, БД с логом, созданная на встраиваемом устройстве на базе архитектуры ARM, должна быть просмотрена и на компьютере с другим порядком следования байт;
• Производительность: все операции по добавлению данных в лог и просмотру лога должны выполняться с максимальной скоростью;
• Интеграция: Новая система ведения логов должна плотно интегрироваться с другими системными компонентами;
• Минимальное потребление ресурсов: файлы с журналами должны занимать минимальное место на диске, даже с учетом того, что объем генерируемых данных может быть существенно больше, чем при использовании классических журналов;
• Хранилище информации о событиях общего назначения: должно поддерживаться помещение в журнал разных типов записей, независимо от их формата и размера;
• Унификация: различные виды технологий журналирования должны быть унифицированы, все события должны храниться в едином типе хранилища и должны быть доступны для связанного анализа. Например, часто запись от прошивки следует за записью от ядра Linux и связана с какими-то действиями на уровне пользователя - важно, чтобы связь между этими тремя событиями можно было отследить;
• Поддержка высокоуровневых инструментов: должен присутствовать удобный API, который можно использовать в программах мониторинга, восстановления после сбоев, генераторах отчетов о причинах краха и различных утилитах для просмотра логов;
• Масштабируемость: система должна одинаково хорошо работать на обычных компьютерах, на больших кластерах и на встраиваемых системах с ограниченными ресурсами, справляясь с любыми размерами журналов и интенсивностью потока событий;
• Универсальность: возможность расширения для поддержки специфичных требований отдельных приложений (формат должен быть расширяем);
• Поддержка кластеризации и сетевых функций: обеспечение единой службы журналирования для больших инфраструктур, состоящих из множества хостов;
• Безопасность: файлы с логами должны быть аутентифицированными для гарантии отсутствия изменения уже сохранённых данных.

Среди основных проблем syslog, которые попытались решить разработчики Journal, отмечаются:

• Данные сообщений не аутентифицированы. Например, любой локальный процесс может указать что он Apache с PID 4321, а syslog поверит этому и сохранит сведения в лог;
• Данные помещаются в лог в свободной и неструктурированной форме, что требует написания специальных парсеров для автоматизированного разбора логов, учитывающих множество возможных форм представления данных;
• Время записи сохраняется без учета часового пояса;
• На одной машине разными службами одновременно ведётся несколько разных журналов, таких как utmp/wtmp, lastlog, audit, логи ядра, логи прошивок, логи отдельных приложений. Подобная организация существенно затрудняет выявление связей между элементами разных логов;
• Чтение лога является очень простым, но в то же время крайне неэффективным процессом. Так как отсутствует индексация, всегда требуется полный перебор лога;
• Сетевой протокол syslog очень ограничен, например, не гарантирует доставку и не учитывает потерю пакетов;
• Атакующие могут легко отредактировать лог для сокрытия своих действий;
• Отсутствуют гибкие средства контроля доступа к логам;
• Ограничены возможности по сохранению в логе дополнительных метаданных;
• При ротации логов не учитывается свободное место и нет эффективной защиты от проведения DoS-атак через наводнение логов;
• Сжатие логов производится только после ротации, активный лог находится в несжатом виде, а архивный сжат целиком, а не на уровне отдельных записей;
• Классический Syslog непригоден для журналирования событий на раннем этапе загрузки системы;
• В лог не могут помещаться бинарные данные.

# opennet.ru