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

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


Анонимные аналитики негативно оценивают грядущие улучшения в 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 Foundation начал разворачивать узлы Tor! Статус узлов можно посмотреть на странице статистики Tor Foundation.

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

Наши коллеги по 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 Team просят заполнить простую форму, где указать какие плагины вы используете, каких плагинов не хватает и написать комментарий в свободной форме.

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++. Это значительная работа. Пока решение не принято, и наши коллеги все еще ругаются друг на друга конструктивно обсуждают предложенное изменение.

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

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

Christian Schaller в своем блоге объявил о массовом наборе (6-7 человек) на работу по улучшению десктопного линукса.

Вместо формального списка требований, Christian опубликовал список пожеланий к будущим сотрудникам. Чем больше пунктов подходит, тем лучше для кандидата. Список довольно обширен:



  • Able to program in C
  • Able to program in Ruby
  • Able to program in Javascript
  • Able to program in Assembly
  • Able to program in Python
  • Experience with Linux Kernel development
  • Experience with GTK+
  • Experience with Wayland
  • Experience with x.org
  • Experience with developing for PPC architecture
  • Experience with compiler optimisations
  • Experience with llvm-pipe
  • Experience with SPICE
  • Experience with developing software like Virtualbox, VNC, RDP or similar
  • Experience with building web services
  • Experience with OpenGL development
  • Experience with release engineering
  • Experience with Project Atomic
  • Experience with graphics driver enablement
  • Experience with other PC hardware enablement
  • Experience with enterprise software management tools like Satellite or ManageIQ
  • Experience with accessibility software
  • Experience with RPM packaging
  • Experience with Fedora
  • Experience with Red Hat Enterprise Linux
  • Experience with GNOME


Чтобы лучше понимать, какие задачи предстоит решать, Christian предлагает ознакомиться с десктопными фичами, которые запланированы на Fedora 22. Если вы хотите поработать над этими или схожими задачами, то напишите ему по почте cschalle(at)redhat(dot)com.

В systemd появилась очень полезная фича - возможность и запускать загрузочные образы системы с помощью systemd-nspawn. Поддержка пока ограниченная, но теперь не надо распаковывать вручную скачанные образы для виртуалки / облачной системы. Можно использовать их в systemd как есть. К сожалению, systemd не умеет пока запускать контейнер из раздела, т.е. systemd-nspawn -i /dev/sdb3 пока не работает.

Спустя пару дней были расширены и возможности systemd-import, утилиты, созданной недавно, чтобы импортировать контейнеры D*ck*r. Была добавлена возможность импортировать образы в формате qcow и сжатые с помощью XZ образы. Теперь их можно не распаковывать самостоятельно - systemd все сделает.

Кажется, что совсем недавно, в октябре 2014, был представлен первый вариант патчсета для kdbus, породивший серьезные обсуждения, и вот Greg KH предлагает третий вариант. Коллеги-аналитики уже обсуждают изменение на OpenNET.ru.

Lennart не только пишет код, но и раздает многочисленные интервью. Недавно издание Linux Voice опубликовало еще одно пространное интервью с ним. А недавно наши коллеги собрали и перевели его ответы на вопросы в рамках недавней IAmA-сессии Lennart Poettering на Reddit.

И напоследок забавное. Помните, года три назад известный хулиган и матершинник Linus Torvalds изругал разработчиков udev за то, что те решили работать синхронно и не загружать firmware до полной инициализации модуля ядра, потребовав асинхронности в загрузке firmware от разработчиков ядра? Ну, был скандал, гентушники не особо вникая в ситуацию попытались форкнуть udev, а разработчики ядра и разработчики udev требовали асинхронной работы друг от друга. Тогда дело закончилось тем, что ядро начало само загружать firmware. Так вот, та ситуация с асинхронной инициализацией модулей ядра получила развитие! Несмотря на проклятия Линуса, асинхронная загрузка драйверов оказалась интересной идеей, позволившей еще больше сократить время запуска системы, и неудивительно, что Google реализовал ее для Chrome OS. Эти патчи были недавно представлены на включение в ядро Дмитрием Тороховым. Посмотрим, чем закончится.

Наши участники делают еще один шаг в направлении общесистемных крипто-политик, работа по реализации которых начата в Fedora 21. Nikos Mavrogiannopoulos, основной разработчик криптобиблиотеки GnuTLS, создал спецификацию на работу с библиотеками OpenSSL и GnuTLS, которой должны следовать все приложения, использующие их. Расширение спецификации на nss планируется, но пока не реализовано. Остальные криптобиблиотеки, с нашей точки зрения, лучше не использовать. Если же разработчики их используют, то им стоит рассмотреть переход на одну из этих трех. В будущем останется лишь одна, но которая из них, пока непонятно.

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

Возвращаясь к трем основным библиотекам, мы бы рады сказать, что надо прямо сейчас переходить на %криптобиблиотека%, но это невозможно. Все три обладают несовпадающим набором функционала, к их upstream-командам есть серьезные вопросы по процессу разработки, все три обладают различными лицензиями, что не позволяет переносить функционал друг из друга. В быту проблемы вызывают все библиотеки. Но проблема еще и в том, что логика работы криптобиблиотек не всегда понятна. Криптография, это и без того непростая область, так еще и конкретные реализации усложняют процесс. Например, наш коллега, Adam Williamson, решил разобраться в деталях того, как происходит подключение дополнительные сертификатов в основных крипто-библиотеках. Сначала оказалось, что хранилище сертификатов по умолчанию в разных дистрибутивах находится в разных местах, да еще и по формату отличается (внимание, очень длинный пост), затем оказалось, что понятие "trusted" в OpenSSL гораздо сложнее, чем кажется, и не все мэйнтейнеры понимают его правильно. Последнее далось Адаму особенно тяжело.

Уже довольно давно начат прием фич на Fedora 22, и комитет FESCo уже одобрил часть из них. На настоящий момент в Fedora 22 запланированы следующие изменения:

  • Обновление BIND до версии 9.10. В этой версии произведен окончательный переход на новый формат конфигурационных файлов, что автоматически делает это изменение деструктивным.
  • Начиная с Fedora 22 в системе будет включен локальный DNS-резолвер по умолчанию. Это очередной шаг к архитектурно правильной системе работы с DNS.

    Если кто не в курсе, то юниксвэйный способ работы с DNS, это текстовичок, пригодный для чтения глазами, в котором хранится список адресов DNS-серверов и еще немного информации. За деталями обращайтесь к man resolv.conf. В общем это бы и работало, если бы не ряд проблем. Например, тот печальный факт, что при получении адресов по DHCP, установке VPN, присоединении к Wi-Fi, содержимое этого файла изменялось различными командами (и различными хуками, в самых разнообразных bash-портянках), что приводит к самым удивительным эффектам. Пытаясь обойти конкретно эту проблему, не нарушая священный юниксвэй, был предложен полурабочий вариант - resolvconf. Это еще один shell-скрипт, который подчищает изменения /etc/resolv.conf, то ли откатывая их, то ли объединяя. Разумеется, как и многие другие портянки на bash, он не работает в чуть более сложных случаях, чем думали авторы, и несчастные пользователи тратят свою жизнь в бессмысленной борьбе с этим еще одним тяжким наследием юниксвэя.

    Исправить эту и другие проблемы с текущей архитектурой реализации DNS на рабочих станциях (таймауты, если один из серверов отвалился, DNSSEC и т.п.), было предложено радикально - в /etc/resolv.conf будет содержаться единственная запись локального DNS-резолвера, который будет собирать DNS-записи, полученные по dhcp/vpn/wifi, и поддерживать DNSSEC.
  • Включение Elasticsearch, открытой поисковой системы (системы индексирования и анализа данных).
  • Традиционное обновление Boost до версии 1.58 (или 1.57). Обновление Boost, это очень деструктивное изменение, затрагивающее огромное количество пакетов, и мы обновляем его лишь с новыми версиями Fedora.
  • Обновление GHC до версии 7.8, и пересборка всего стека Haskell-приложений и библиотек новым компилятором.
  • Переход в X.org на libinput для работы с устройствами ввода. Сейчас мы используем evdev/synaptics, а они очень плохо работают с современными тачпадами на ноутбуках.
  • Замена индийских фонтов Lohit Odia и Lohit Telugu на их новую версию Lohit2.
  • Очень спорное изменение - новый консольный фонт. Несмотря на заявленную совместимость, в нем нет поддержки арабских, еврейских и кириллических символов, так что нам лучше остаться на текущем latarcyrheb-sun16. Зато в новом фонте есть полная поддержка европейских языков, греческого, и есть все смайлики.
  • Perl обновляют до версии 5.20.
  • Preupgrade Assistant, утилита, позвояющая переносить изменения конфигураций при апгрейде.
  • Перенесенная с Fedora 21 фича - Python 3 по умолчанию. Идея в том, что в дефолтной конфигурации не должно быть Python 2. Сам он, конечно, будет доступен из репозиториев.
  • Yum заменяют на DNF. Некоторые наши коллеги уже пользуются DNF, и даже вносят в него улучшения. Пока особых проблем найдено не было, хотя архитектурные отличия между ними есть.
  • Обновление Ruby до версии 2.2.
  • Вместе с Ruby будет обновлен Ruby on Rails до версии 4.2.
  • UEFI SecureBoot будет поддерживать черные списки приложений и сертификатов. Приложение, подписанное ключом, находящимся в черном списке не будет запущено, если SecureBoot будет включен.
  • Библиотека wxPython будет обновлена до последней версии 3.0.


На подходе еще пачка фич!

Страницы