Russian Fedora

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

Новости с DevConf.cz

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

На фото, бывший (?) американский кгбшник, инженер NSA, Dan Walsh, [STRIKEOUT:зомбирует активистов] заставляет аудиторию стоя и хором повторять за ним правила обращения с SELinux.

System Message: ERROR/3 (<string>, line 8)

Error in "image" directive: "center" is not a valid value for the "align" option within a substitution definition. Valid values for "align" are: "top", "middle", "bottom".

image:: https://lh4.googleusercontent.com/-YurXqhXpKLE/VNSR1G-iI-I/AAAAAAAAZ90/Q4ZTCEBUqnc/IMG_3558_web.JPG
   :align: center
   :target: https://plus.google.com/+MarkusFeilner/posts/cjKUGQ9TSY5

System Message: WARNING/2 (<string>, line 8)

Substitution definition "image0" empty or invalid.

.. |image0| image:: https://lh4.googleusercontent.com/-YurXqhXpKLE/VNSR1G-iI-I/AAAAAAAAZ90/Q4ZTCEBUqnc/IMG_3558_web.JPG
   :align: center
   :target: https://plus.google.com/+MarkusFeilner/posts/cjKUGQ9TSY5

Наверняка в превосходстве systemd представителей других дистрибутивов убеждали такими же сектантско-пропагандисткими методами. То ли еще будет!

Golang и bundled libs

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

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

Это привело нас к интересному вопросу - а как быть с bundled libs? Строго говоря, библиотек там нет. Вместо этого используется термин "пакет". В терминологии Golang, это кучка исходников, которые не загружаются во время работы, а подключаются при сборке. Получается, что он и попадает под определение "bundled lib"? Не так быстро! Мы растаскиваем приложения на библиотеки перед сборкой, чтоб в будущем обновив одну из них, мы не обязательно были бы вынуждены обновлять все зависящие от нее приложения и библиотеки. А тут то так не получится! Пересобирать Go-приложение все равно придется. Да, теоретически, выделяя Go-пакеты в отдельные RPM-пакеты, можно упростить исправление ошибки - исправил один Golang-пакет и пересобрал его в RPM-пакет, и начинай пересобирать все зависящие от него RPM-пакеты. На деле это не даст значительного ускорения, зато увеличит работу по unbundling. Осознав это, мы решили пойти на компромиссный вариант - пока прекратить требовать выделения всех пакетов Go в отдельные RPM-пакеты, но если такие RPM-пакеты уже есть, то использовать при сборке именно их. Мы попросили Fedora Packaging Committee одобрить это решение, и в целом народ понял проблему, но предложили нам вместо решения лишь этого вопроса заняться более общей задачей - написать Golang Packaging Guidelines, где отразить эту особенность. Участники Golang SIG так и порешили.

Одно уже понятно - бездумный перенос работавших в других местах подходов не всегда продуктивен.

Типичная система под управлением Fedora

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

На фото один из узлов Square Kilometre Array, разрабатываемого самого большого радиотелескопа в мире, который будет состоять из сети узлов, расположенных в Южном Полушарии: image0 Каждый день радиотелескоп будет собирать миллион терабайт данных, которые будут обрабатываться кластером PowerPC-машинок от IBM, и на которых сейчас работает Fedora. Каждая машинка имеет 12-ядерный процессор на 1.8 гигагерца, 10Gb и 1Gb сетевые карты, 4 PCIe контроллера.

Короткие новости о контейнерах

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

Сейчас использование контейнеров активно расширяется на все возможные области задач, тестируя тем самым реалистичные границы применения. Например, проект GNOME предлагает запускать в контейнерах графические приложения. Это потребует полного перехода на Wayland, systemd и kdbus, но это совсем другая история. Коллеги-аналитики уже обсуждают на OpenNET.ru.

https://hsto.org/getpro/habr/comment_images/ae7/a02/a05/ae7a02a059319a7a85cddf73b67a593c.jpg

Анонимные аналитики негативно оценивают грядущие улучшения в systemd/Linux платформе

В облачных системах есть две важные темы среди всех прочих - связность систем (виртуализация сети с помощью SDN, распределенные хранилища данных и шины данных), и репликация (как систем, так и данных). Эти темы связаны настолько, что решение различных задач в этой предметной области часто производится одним и тем же инструментарием. Например, для виртуализации сети сейчас можно использовать т.н. сетевые контроллеры, например flannel, о котором мы вскользь упоминали или Weave, о котором мы тоже упоминали. В ходу, конечно, и более сложные решения SDN. Из этих двух, проекту flannel пока везет больше, и он уже включен в Fedora - можете пробовать, если не боитесь ряда детских болезней. Если же не боитесь, то наш коллега, Scott Collier, написал короткую хаутушку, как быстро развернуть сетку для Docker на базе flannel на нескольких машинках. К сожалению, дефолтная конфигурация flannel пока неоптимальная даже для Docker-систем, не говоря уж о нестандартных решениях, и для реальных решений вам придется ее поменять. Мы работаем над более общим и менее завязанным на какие-то специфические случаи решением, и просим вас сообщать про ошибки и пожелания в нашу багзиллу. Устоявшихся сценариев использования пока мало, и даже инженеры CoreOS и Red Hat пока не владеют достаточным объемом информации про возможные варианты использования.

Вышеупомянутый flannel использует etcd для хранения и репликации настроек, который готовится к выходу версии 2.0. Мы планируем обновить его до последней альфа-версии, и это возможно вызовет регрессии, т.к. в этой версии изменены некоторые умолчальные параметры и изменено то, как бутстрапится кластер etcd. Опять же, тема очень новая, и просто нет достаточного количества "use case", чтоб все проверить - без вас тут никак.

Возможности etcd гораздо выше, чем репликация настроек. Будучи просто системой хранения структурированных данных он годится в т.ч. и для задачи service discovery. Тут напомним про часто отключаемый неосведомленными пользователями Avahi, который можно также использовать в облаках, если уметь его готовить. Мы уже обращали ваше внимание на далеко не полный список облачных средств для service discovery, но вариантов решения с тех пор еще прибавилось. Например, недавно появился еще один проект от Mesosphere, известных вам по участию в проекте Kubernetes, вместе с Google, Red Hat, CoreOS и т.п. Они предложили облачный сервис DNS - mesos-dns, само собой написанный на Golang. Предлагается запустить его как основной DNS-сервер, который предоставит доменную зону .mesos (можно настроить). В этой зоне появятся доменные имена, соответствующие запущенным в кластере сервисам. Решение довольно интересное, т.к. он прячет от приложений изнанку системы, и позволяет обходиться без работы с API систем service discovery. API для DNS, это базовый функционал любого языка программирования, и это сильно упростит вещи (ценой усложнения настройки самой системы в целом, конечно).

Если по service discovery вариантов полно, то по шинам данных, которые и обеспечивают управление системой, пока довольно скучное однообразие. Либо строятся облачные системы без общей шины данных, как это делается в проекте CoreOS, либо, как в случае OpenStack, используется вариант AMQP. Конечно, сейчас в рамках очередного уровня абстракций OpenStack Oslo производится работа по реализации ZeroMQ-бэкенда, но по умолчанию используется RabbitMQ, написанный на Erlang нашими друзьями из одноименной компании. James Page, техлид Canonical, сообщил результаты тестирования бэкенда RabbitMQ против ZeroMQ - результаты пока не в пользу ZeroMQ. Тут, кстати, у Red Hat серьезный просчет. Дело в том, что у них был свой AMQP-вариант - Qpid, и они планировали использовать именно его, а не RabbitMQ. Хоть Qpid и быстрее на ряде синтетических тестов, но коммьюнити выбрало RabbitMQ, и им приходится нагонять. У них в штате нет специалистов по нему, а мультиинструменталист Rich WM Jones занят другими делами. К счастью в Red Hat был принят ряд решений, и тут ситуация, по агентурным данным, скоро переменится - новости скоро будут!

Сложность облачных систем в целом продолжает повышаться. Разработчики громоздят все большие уровни абстракций, виртуализируя все больше и больше подсистем. Это не только упрощает создание сервисов, но и, к сожалению, повышает хрупкость и понижает "поддерживаемость" облачных систем в целом. Первоначальный энтузиазм, вызванный продолжающимся упрощением развертывания и управления облаков благодаря появлению проектов типа Fuel от Mirantis и Juju от Canonical, сменился осознанием того, что сложность в основном просто перетекла с уровня отдельного изолированного сервиса на уровень всей облачной системы. Скорость разработки приводит к тому, что бэкенды к разным уровням абстракций сильно расползаются по уровню качества - это, разумеется, не проблема, если под рукой есть коллектив разработчиков Red Hat, HP или Mirantis. А вот маленькие коллективы начали чувствовать свою беспомощность перед нависающей тучей подсистем в OpenStack, и отказываться от OpenStack в пользу нестандартных решений, например на базе инструментария CoreOS. Вероятно, мы услышим еще о подобных историях в ближайшее время.

Одним из таких инструментов от проекта CoreOS является fleet, супервизор задач для кластера, разработанный на базе etcd и systemd. Вы уже могли о нем слышать. К сожалению, пока его в репозитории Fedora нет, но мы работаем над этим. Написан fleet, разумеется, на Golang.

Вообще, Golang, при всех его недостатках, становится стандартом. Просто те альтернативы, которые ему есть, не очень удобны. Не, ну а как? Rust, как оказалось, даже и собрать сложно, не то, что писать на нем (там вообще есть хоть какая то система CI?). Haskell настолько непрост, что до сих пор на нем написали лишь компилятор Нaskell и утилиты для разработки компилятора Haskell. На судьбе Ocaml трагическим образом сказалась чудовищная близорукость основного архитектора системы, который всерьез считал, что многопроцессорные системы не будут популярны. Ну а про остальные варианты даже упоминать не стоит. Поэтому, чтоб произвести впечатление на первокурсниц, изучайте Haskell. Чтоб попасть в Mozilla Foundation, попробуйте собрать Rust и начать на нем писать (и переписывать каждую неделю). Чтоб поговорить по душам с Rich WM Jones начните писать на Ocaml. А чтоб упросить себе жизнь DevOps, то ваш выбор - Golang. Для московских пользователей этого языка у нас есть две новости - хорошая и не очень. Хорошая это то, что в ближайшее время выйдет анонс очередного Moscow Golang User Meetup. Плохая - это будет мемориальной встречей, посвященной эвакуации офиса разработки Google из России.

Несмотря на грустные новости, жизнь продолжается. Нам хочется поздравить наших коллег из Parallels со знаменательным событием - их проект, CRIU, перевалил за 5000 коммитов! Поздравляем!

Mozilla начала развертывание Tor-узлов!

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

В целях повышения устойчивости интернета к цензуре и обрывам связи, проект Mozilla Foundation начал разворачивать узлы Tor! Статус узлов можно посмотреть на странице статистики Tor Foundation.

Запретить биткойны, GitHub или Wikipedia коррумпированным режимам теперь стало заметно сложнее. Напомним, что наши ресурсы доступны в сети Tor. Кроме нас, нативным Tor-адресом обладают Facebook и Flibusta.

Стандартизация загрузки на UEFI-системах

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

Наши коллеги по Fedora Project успешно продолжают стандартизацию Linux-систем.

Разработчик udev и systemd, Kay Sievers, добавил парсер PE-формата в gummiboot, что позволило провернуть интересный трюк.

Теперь gummiboot парсит PE-файлы в /EFI/Linux/*.efi, и если находит там специальным образом подготовленные, содержащие секцию .osrel, то добавляет в меню загрузки новый пункт, исходя из содержимого найденных файлов. Специально подготовленные, это второе предложение от Kay - новый вариант упаковки Linux-системы, в один большой PE-файл. Он подготовил первый вариант описания бинарного формата. Ядро Linux, образ initrd и аргументы командной строки предлагается упаковывать в один большой PE-файл, содержащий уже упомянутую выше секцию .osrel и дополнительные секции .linux, .inird и .cmdline соответственно. А уж gummiboot будет искать такие файлы, разбирать их и загружать систему.

Отзывы к DNF Plugins

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

Наши коллеги из DNF Team просят заполнить простую форму, где указать какие плагины вы используете, каких плагинов не хватает и написать комментарий в свободной форме.

Loading...

Pepperflash для Firefox

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

Eсли вы пользователь Firefox и вас не устраивает древний (версия 11) неразвиваемый flash-plugin от Adobe, то рекомендуем попробовать chromium-pepper-flash - флеш (версия 16) от Chrome. Для этого надо установить сам chromium-pepper-flash и freshplayerplugin из репозиториев russianfedora. О проблемах можно писать в наш багтрекер.

Новости нашей инфраструктуры

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

Поступило интересное и неоднозначное предложение - исключить gcc, gcc-c++ и make из пакетов, устанавливаемых по умолчанию при сборке в Koji.

Рациональное зерно есть - языки C и C++ медленно сдают современным молодежным языкам программирования, и приложения, написанные на этих моднейших языках, не требуют установки этих пакетов для сборки. Отказ от установки необязательных пакетов сэкономит пока еще неизмеренное время при сборках. Но есть и недостаток. Хоть они и не требуют, но и не против установки этих пакетов. А вот пакеты, написанные на C и C++ именно, что требуют присутствия этих пакетов, и для сборки пришлось бы явно указывать зависимость от gcc и gcc-c++. Это значительная работа. Пока решение не принято, и наши коллеги все еще [STRIKEOUT:ругаются друг на друга] конструктивно обсуждают предложенное изменение.

Интересно, что это изменение сделало бы наши spec-файлы более близкими к стандартам openSUSE. Участники обеих проектов часто отмечают, что между нашими проектами слишком мало взаимодействия, и мы зачастую совершаем двойную работу. Отсутствие координации вредит обеим проектам, но, к сожалению, до значительных сдвигов в этом направлении еще далеко. Тем приятнее видеть инициативы снизу по движению в верном направлении.

Например, не так давно участник openSUSE Richard Brown, в рамках работы по продвижению системы автоматического тестирования дистрибутивов, openQA, показал, что вполне возможно протестировать установку Fedora в автоматическом режиме. Автоматических тестов никогда не бывает мало, поэтому интересно, чем закончится эта инициатива.

И наконец, хорошие новости от дружественного нам проекта GDB. Инженер Red Hat и участник Fedora, Sérgio Durigan Júnior, объявил, что он настроил BuildBot для GDB. Пока крутится на его личном домене, но понятно, что как только отполируют, то перенесут куда-нибудь на официальный домен.