Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Короткие новости

Это архивная статья

Matthias Clasen сообщил, что разработчики GNOME думают сдвинуть график выхода для синхронизации с графиком Wayland.

В целом никто не против.

Chris Smart, мэйнтейнер Kororaa Linux, опубликовал инструкцию по включению TLS 1.2 в Firefox 26.

Интженер Red Hat и участник fedora-infra, Patrick Uiterwijk, рассказывает о своем опыте работы с RPM-OSTree, анонсированным чуть ранее.

Это еще одна система для создания rootfs, которые можно использовать параллельно загружаемыми.

Marek Goldmann написал заметку о том, как соединять Docker-контейнеры с помощью Open vSwitch.

Jeff Layton рассказывает о проблемах с POSIX locks и том, что было им предложено для исправления.

Из серии "занимательная литература" - Joe Damato рассказывает совершенно удивительную историю семилетнего бага.

Продолжается дискуссия вокруг стандартизации ARM (особенно UEFI и ACPI).

Jonathan Corbet подводит промежуточный итог.

В ответ на получившую некую известность среди русскоязычных коллег-аналитиков статью Rich Felker про мнимые или реальные архитектурные проблемы systemd Chris Siebenmann опубликовал заметку, в которой излагает в общем-то довольно очевидные вещи - почему systemd выиграла войну, а другие альтернативы проиграли.

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

И раз уж заговорили о systemd - Lennart Poettering в своей ленте Google+ расссказывает о том, как он как он добился запуска немодифицированной Fedora в контейнере с включенным audit.

systemd с точки зрения мэйнтейнера upstream-проекта

Это архивная статья

Теперь уже самым закоренелым скептикам должно быть понятно, что systemd, это нынешний стандарт. Для закрепления успеха systemd продвигают в LSB с начала 2012 года.
Однако, несмотря на огромнейшую гору документации по systemd (и даже на русском), спрос на нее все еще заметен.
Инженеh SUSE, Neil Brown написал пару статей (часть 1 и часть 2), где попытался описать свой опыт с systemd, как upstream-мэйнтейнера mdadm и nfs-utils.
Для начала Neil отмечает, что init-скрипты слишком сильно отличаются от дистрибутива к дистрибутиву, чтоб имело смысл их поставлять в составе файлов в upstream. Да и для сложных случаев, таких, как nfs-utils, синхронизация с помощью SysV была недостаточной, и Neil затрудняется вспомнить, есть ли дистрибутив, в котором демоны NFS для сложных конфигураций были бы запущены в нужном порядке. А вот в случае с systemd, это стало возможным - и общая настройка для всех дистров, и точный порядок запуска.
Neil увидел уменьшение объема скриптов systemd по сравнению с SysV (примерно с 800 строк до менее 200 строк), зато ему пришлось включить большее количество описаний сервисов - вместо двух SysV-скриптов, для nfs-utils понадобилось 14 systemd-файлов. К счастью среди этих 14 файлов присутствуют 4 *.target (в терминологии systemd, это некая "точка" на дереве загрузки системы, достигнутая стадия), что упрощает жизнь пользователей.
Дальше Neil заинтересовался, как бы не дать повода пользователю редактировать unit-файлы, одновременно позволив ему изменять ряд параметров (количество потоков демона и т.п.). Тут Neil увидел область, нуждающуюся доработки. Например, если пользователь хочет переназначить порт, то было бы логично просто установить переменную $MOUNTD_PORT где-нибудь в /etc/sysconfig/ или /etc/defaults/. Однако, тогда демону может потребоваться ключ командной строки, который не нужен, если порт не переназначается. Т.е. требуется написать что-то типа
/usr/sbin/rpc.mountd ${MOUNTD_PORT:+-p $MOUNTD_PORT}
(если установлена переменная, то добавить ключ командной строки, иначе не добавлять). В systemd возможности задавать такие условия нет, и пользователю придется пересоздавать unit-файл в /etc/systemd. А это "перезапишет" изменения в unit-файлы из /usr/lib/systemd. Можно, конечно, указывать в файлах конфигурации не $MOUNTD_PORT, а MOUNTD_PORT_ARG="-p 12345", но это как-то не очень красиво получается. Вообще, более правильно было бы использовать include-директивы или "drop-ins" (unit-файлы в директории /etc/systemd/system/*.d).
Neil продолжил вторую часть с обсуждения вопросы активации сервисов. Он отмечает, что в отличие от Upstart, установка unit-файла не означает его автоматическую активацию. Далее он обращает наше внимание на существенную разницу в активации legacy-сервисов из SysV, с помощью insserv, и в systemd. В SysV активация сервиса сопровождается проверкой на завивимости (директива Required-Start), и если сервис не активирован, но insserv выпадает с подробным сообщением, из которого понятно. что нужно сделать. Утилита для обработки SysV-скриптов из systemd действует по-другому - оно учитывает порядок, но не смотрит на наличие. Таким образом можно смело говорить, что работать SysV-скрипты в systemd будут лишь в простейших случаях, и потребуется полный переход на него.
Neil также отмечает, что несмотря на противопоставление event-based системе активации из Upstart и декларативному подходу в systemd, некоторые сервисы активируются таким образом, что сторонний непредвзятый наблюдатель не сможет отличить это от событийной модели активации. Например, mdadm активируется с помощью udev, при появлении дискового массива - это выглядит именно как событие.
Дальше Neil обращает внимание на недоработку - в механизме socket activation отсутствует возможность активации не с предопределенного, а с произвольного номера порта. Это нужно для rpc.statd. Что интересно, в Solaris такой механизм есть.
Возвращаясь к параллелям и отличиям с Upstart, Neil продолжает анализировать активацию сервисов и отмечает, что достижение target в systemd хотя и практически неотличимо от событий Upstart ("starting"), сервисы systemd запускаются не по событиям, а сами создают списки событий ("я запускаюсь, поэтому запусти также то-то и то-то"). Зависимость тут развернутая - сервис Upstart точно знает, что за событие его запустило, в то время, как сервис systemd знает какие "события" (сервисы) оно запускает. Здесь очень интересно появление двух директив в systemd WantedBy и RequiredBy, которые являются антиподами для Wants и Requires соответственно, но в отличие от них могут использоваться лишь в секции [Install]. Эти директивы можно считать аналогом "start on" в Upstart, но интересно, что в секции [Unit] их использовать не получится. Несмотря на то, что каждое указание Wants и Requires в секции [Unit] действительно создает внутреннее представление WantedBy и RequiredBy в зависимых сервисах, явное их использование не допускается.
Neil продолжает с интересной задачей - условный запуск сервиса (запускать лишь в каком-то случае, иначе запускать другой сервис).
Оказалось, что без вмешательства суперпользователя это в общем случае нерешимо. Однако, в ряде случаев, используя директиву Requisite=, удалось привязать сервис к доступности указанного target. Сервис не запускается, если не запущен target, и останавливается сразу при остановке target. Получив уже четыре разных target в составе пакета nfs-utils, Neil отмечает удобство пресетов (presets) для systemd, которые позволяют мэйнтейнерам дистрибутивов самостоятельно решать то, какие target и сервисы будут включены по умолчанию.
Подытоживая вопросы активации, Neil говорит, что systemd предоставляет довольно богатый набор директив для управления сервисами, которые покрывают даже очень сложные случаи. К сожалению, как отмечает Neil, включение и отключение сервисов не принимает во внимание файлы конфигураций из /etc/sysconfig или /etc/defaults. Также интересно, что поведение udev по запуску правил по умолчанию полностью отличается от systemd, хотя присутствует в том же пакете ПО.
Далее Neil, обладая некоторым опытом разработки языков программирования, переключается с практических аспектов, на теоретические. Он недоумевает - директивы systemd разрешены лишь в конкретных секциях, тогда зачем нужны все эти [Unit], [Service], [Install]? Ну, кроме того, чтоб unit-файл выглядет бы как ini-файл.
Neil продолжает с логическими директивами systemd, такими как ConditionPathExists, которые отчасти позволяют логические выражения, такие, как A and B and (C or D or E), но не такие, как (A or B) and (C or D). Он интересуется, почему было бы не использовать традиционные правила, вместо частичного их подмножества. Любое отклонение от общепринятого стандарта лишь усложняет изучение, хотя и понятно, что сложные логические выражения в unit-файлах не будут часто встречаться.
Однако, собственная алгебра логики, это не единственное проблематичное место. Neil отмечает огромное количество директив - Requires, RequiresOverridable, Requisite, RequisiteOverridable, Wants, BindsTo, PartOf, Conflicts, Before, After, OnFailure, PropagateReloadsTo, ReloadPropagateFrom и т.п. Он чувствует, что такое их количество, это явный признак некоей модели, скрытой от пользователя, и которую можно было бы более эффективно представлять с помощью DSL.
На этом Neil останавливается, и подводит итог. Он отмечает. что указанные менее 200 строк он написал с первой попытки, и он впервые чувствует, что его описание nfs-utils в systemd делает именно то, что нужно. Как разработчик, он отмечает, что наконец-то он обладает инструментарием и языков описания, которое позволяет ему выражать именно то, что он хочет, и сравнивая с тем, что дает разработчикам systemd, можно не обращать внимание на в основном косметические минусы.

Scientific Linux присоединяется к нам

Это архивная статья

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

Кстати, в этом году CentOS снова попробует поучаствовать в Google Summer of Code. Если вы студент, то подпишитесь на новости.

Вернулись с FOSDEM

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

Тем, кто вынужден был пропустить мероприятие, мы рекомендуем посмотреть, что постят на G+ и Twitter по хэштэгу #fosdem.

Особенно рекомендуем полистать твиттер Maksim Melnikau.

Впереди DevConf.cz с 7го по 9е февраля.

Встретимся там!

"Cute embedded nonsense hacks"

Среди embedded-разработчиков прямо сейчас набирает популярность новый слоган:

http://peter.fedorapeople.org/stuff/pics/i_do_cute_embedded_nonsense_hacks_shirts-r8152a3c7d6fc436d9527ef4a5eb8bb6e_va6lr_512.jpg

Его появление связано со стандартизацией AArch64/ARM64, и история эта - поучительна и интересна.

Начавшаяся следующая стадия перехода AMD на ARM, это была не единственная новость на неделе. Компания ARM Ltd анонсировала Server Base System Architecture - референсную платформу дня 64-битных ARM-платформ (не микропроцессоров, а сразу целых платформ). Среди основных разработчиков стандарта был наш коллега Jon Masters. Мы уже рассказывали вам о вопиющих архитектурных недостатках 32-битных ARM-платформ, следствием которых является непомерно разбухшая директория arch/arm в исходниках ядра Linux (проверьте сами). Embedded-программистам, создающим нестандартные решения и живущим по принципу "срубить бабла на прототипе и откосить от техподдержки", нравится такая казацкая вольница, т.к. она позволяет быстро лепить готовые нестандартные изделия. Всего-то делов - скопировать одну из папок arch/arm/mach-* и/или arch/arm/plat-*, и готова новая ARM-система. Понятно, что в результате там получилось месиво из более-менее повторно используемого кода. Даже известный любитель положить на стандарты, лишь бы работало у юзера, Linus Torvalds, и тот тоже был очень недоволен, а однажды зло ругался на ARM-разработчиков как раз из-за этого.

Прошло время, но ситуация не изменилась, и Торвальдсу пришлось ругаться снова.

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

Cтандарт на AArch64 создан с оглядкой на опыт Intel и Microsoft, позволивший им создать предсказуемо работающую, легко расширяемую архитектуру (PC), и в нее включено много устоявшихся решений. Больше не нужно компилировать откопанный где-то на FTP-сервере в Тайване тарболл с форкнутым пару лет назад u-boot - теперь все будет работать с UEFI, ACPI, Secure Boot, и в дистрибутив будет достаточно включить единственный образ ядра, который будет работать на любой AArch64-архитектуре. Таков план, о котором нам рассказал Jon Masters, и больше никаких cute embedded nonsense hacks.

Любители форкнуть и скопипастить сильно обиделись.

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

Moscow Virtualization Meetup "FOSDEM After-party"

15 февраля состоится очередной Moscow Virtualization Meetup, под неофициальным кодовым названием "FOSDEM After-party", организованный командой Russian Fedora при поддержке Яндекса. На встрече будут обсуждаться различные аспекты виртуализации. Свои доклады представят эксперты в этой области — представители таких компаний и сообществ, как Parallels, Cloudius Systems, ksys labs, FastVPS, Fedora Project, Red Hat и Mirantis.

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

Программа:

Участие бесплатное, но зарегистрироваться необходимо.

15 февраля, в субботу, с 12:00 ждем участников по адресу: Москва, ул. Льва Толстого 16, офис Яндекса, зал Экстрополис.

Количество мест ограничено. Если вы зарегистрировались, но не сможете прийти, – пожалуйста, сообщите нам об этом заранее.

systemd и смежные вопросы

Это архивная статья

Чем однозначно ценна сложившаяся ситуация с Debian, так это тем, что заинтересованным лицам становится видна неприглядная заполитизированность и отсталость альтернативных решений, вся ложь их пропонентов. Например, пеняя systemd его зависимостью от Linux, часто говорили, что SysV как раз переносимый. При этом совершенно забыли спросить тех, кто переносил его, например, на Hurd, так ли оно на самом деле? А надо было бы.

Justus Winter, который как раз и переносил SysV на Debian/Hurd в рамках GSoC 2013, высказался по теме в своем блоге.

Он с удивлением заметил, что после нескольких месяцев, которые он на глазах у всего OSS-коммьюнити потратил на частичный перенос SysV на GNU Hurd, люди считают SysV переносимым. Дело в том, что многие современные, т.е. написанные после 1995 года, системные приложения используют Linux-специфичные особенности procfs, от которой, например, отказываются в том же FreeBSD. Для использования SysV в Debian/kFreeBSD и Debian/Hurd были задействованы два сторонних компонента - linprocfs и procfs. Так что технически, все ровно наоборот - в Debian портировали (задействовали сторонние компоненты) ядра FreeBSD и Hurd, чтоб запустить непереносимое ПО.

Конечно, уровень доработки, необходимый для запуска systemd, вероятнее всего неподъемный, но технически этот аргумент нужно убирать - SysV и обе альтернативы (systemd и Upstart) непереносимы на устаревшие ядра.

Степень переносимости, еще раз заметим, отличается. Интересно, что в процессе обсуждения ситуации с завязкой системных компонентов на procfs наш коллега, инженер Linaro, Koen Kooi, обратил наше внимание, что даже под Linux procfs нестандартизирована толком, чего уж там ожидать особых откровений от BSD-вариантов.

Одной из проблем, с которой столкнулся Justus при портировании SysV на Hurd было отключение. SysV последовательно убивал процессы, чем препятствовал отмонтированию разделов в системе (в systemd эту проблему решают в помощью cgroups, но этот Linux-компонент еще не перенесли на Hurd). Так что можно говорить, что не только SysV не переносим, так он еще и жестко привязан к ядру Linux.

Так уж совпало, что Lennart Poettering как раз поднял тему выключения системы в своей ленте Google+ прокомментировав баг в Upstart, приводящий к повреждению файловой системы при отключении (его пост уже перевели на OpenNET.ru).

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

В целом, хотя нам и известно, что в Upstart существует ряд архитектурных неустранимых или очень сложно устранимых проблем, обусловленных в т.ч. и императивным, а не декларативным, как в systemd, подходом к описанию сервисов, которые вылазят в неожиданных местах, теоретически его можно доработать. Но тут есть еще одна проблема. Доработка Upstart приводит к бесплатной работе на Canonical, т.к. проект находится под CLA. С упорством, достойным лучшего применения, Canonical отказывается освободить его из под соглашения. CLA Canonical критикует уже даже сам автор Upstart, не говоря уж о наших коллегах - статья Matthew Garrett, шокирующие признаниях Kay Sievers, мнение Greg Kroah-Hartman и мнение Linus Torvalds.

А ведь это серьезно лимитирует количество разработчиков! В поле systemd прекрасное разнотравье из десятков активных участников, представляющих разные компании, а на бетонном плацу Upstart пугающая серая однородность. И это в то время, когда им надо постоянно копипастить, прикручивая изолентой, новые компоненты из systemd.

В тему о новых компонентах из systemd. До нас дошли слухи, что скоро приступят к интеграции Upstart с cgroups, но само собой, заведомо не так, как в systemd, и ряд задач такая интеграция решить так и не сможет. Здесь интересно отметить, что сторонники Upstart критикуют systemd за его-де монструозность, за количество плотно притертых компонентов, а якобы Upstart, это такой standalone init-демон. Вот только теперь ему нужны компоненты из systemd, без которых он не сможет выполнять ряд задач (и дальше таких компонентов будет еще больше), но он все равно якобы "standalone" и юниксвэйный - такова профессиональная честность пропагандистов.

Вернемся к хорошему. GNOME 3.13 планирует перейти на systemd для user sessions, о которых мы уже вам рассказывали.

Долго они собирались.

Docker теперь поддерживает socket activation. Интересно, что один из участников команды Docker заартачился, назвав поддержку systemd - vendor-specific фичей.

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

AMD начало переход на ARM.

Мы уже сообщали вам почти полтора года назад, что AMD собирается переходить на ARM. Работу по проектированию архитектуры системы взялся провести небезызвестный наш коллега Jon Masters, который принимает деятельное участие в составлении списка стандартов, на которых будет базироваться современные ARM-машины.

Наши новости тогда не приняли некоторые коллеги-аналитики, которые, к сожалению, привыкли черпать информацию не из общения с разработчиками на различных ивентах и чтения исходников, списков рассылки и багтрекеров, а из глянцевых рекламных буклетов. Но, наконец-то, в рекламных буклетах стали появляться подтверждения - да, у AMD скоро будет AMD Opteron на базе ARM64/AArch64.

Коллеги-аналитики уже обсуждают новость.

В X.org включают поддержку systemd!

Это архивная статья

Наш коллега, инженер Red Hat, Hans de Goede, продолжил работу по интеграции systemd и X.org. Он приступил к более решительным шагам и предложил патчи для включения в X.org socket activation и дальнейшей интеграции с systemd-logind.

Конечно пока это будет compile-time switch, и никто не требует срочно отказываться от поддержки устаревших Unix-систем в X.org.