Потихоньку идет процесс перевода операционок от Google на современные компоненты. Несмотря на то, что Chrome OS и Android не будут сливаться в одну систему (т.е. будут, но путем переноса фич туда-сюда, а обои будут разные), и та, и эта системы пока технологически отстают от дистрибутивов линукса. Например, SELinux в Android включили лишь в 2012 году, что гораздо позже Fedora / RHEL (ну, кстати, в Ubuntu его до сих пор нет, что сильно подрывает и без того плохую ситуацию с безопасностью этого дистрибутива). PulseAudio и Wayland были доступны на Android в качестве очень очень экспериментальной сборки от стороннего разработчика. Но самая плохая ситуация была с системой инициализации. В Chrome OS до сих пор используется Upstart, а в Android самописная система инициализации - init. К счастью, благодаря тому, что Chrome OS основана на Gentoo, сменить init-систему на systemd не так и сложно, что продемонстрировали разработчики CoreOS, заменившие Upstart на systemd. Тем не менее, пока Chrome OS официально использовал лишь устаревший и малофункциональный Upstart.

Неожиданно выяснилось, что инженеры Intel уже несколько месяцев работают над возможностью использовать стандартное дерево Chrome OS с systemd. Пока непонятно, насколько полно поддерживается systemd в Chrome OS, но новость позитивная.

Участник коммьюнити Debian, Philipp Emanuel Weidmann, решил разобраться, как обстоит дело с безопасностью при скачивании популярных дистрибутивов? Он выделил несколько ключевых моментов:

  • Страница со ссылками на скачивание должна быть доступна по HTTPS
  • Еще лучше, чтобы она была доступна только по HTTPS и желательно с HSTS
  • Файлы (пакеты, ISO-образы, и т.п.) должны скачиваться по HTTPS
  • На странице со ссылками должна присутствовать контрольная сумма скачиваемых образов
  • На странице со ссылками должна присутствовать GPG-подпись проекта
  • Должна присутствовать инструкция по проверке скачанного


Результаты кого-то сильно удивят, но, конечно, не нас. Мы-то знаем, что в плане обеспечения безопасности пользователя Fedora всегда последовательно реализует лучшие из имеющихся схемы - как и внутри системы (контрольные суммы у пакетов, SELinux, SecureBoot/RestrictedBoot), так и снаружи. Приведем таблицу, которую составил Philipp на 17 июля 2016 года:

Distro HTTPS supported HTTPS forced HTTPS download Checksum Signature Instructions
Mint Yes Yes No1 Externally hosted Yes Difficult2
Debian Yes Yes No Hard to find3 Hard to find3 Difficult3
Ubuntu No No No HTTP only Yes Very clear
openSUSE Yes Yes No HTTP only No None
Manjaro Yes No No Yes (SHA-1) Yes Clear
Fedora Yes Yes Yes Yes Yes Clear4
Zorin No No No5 HTTP only No None
CentOS Yes Yes No Hard to find6 No Hard to find6
elementary Yes No Yes Yes No Clear
Arch Yes Yes No Yes (SHA-1) Yes None


1 Some download mirrors support HTTPS, but are linked to via HTTP only.
2 The (externally hosted) signature and checksum files are not linked to directly. The user has to navigate through multiple subdirectories to find them.
3 "Official releases of Debian CDs come with signed checksum files; look for them alongside the images in the iso-cd, jigdo-dvd, iso-hybrid etc. directories." No directory or direct links are provided. Verification instructions are not linked to from the download page.
4 Not linked to directly from the download page.
5 Additionally, Zorin OS downloads are funneled through intransparent "bit.ly" links.
6 No instructions on the download page. A web search brings up a page with obscure references to a "md5sum.txt" that "can be found in the same directory as the iso image".



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

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

Шесть лет OpenStack

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

Сейчас проект OpenStack объединяет более 25 тысяч специалистов из 165 стран и поддерживается более, чем 500 компаниями. На нашем первом OpenStack саммите в 2010 году было всего 75 человек, а уже в ноябре 2014 – более 4700!

Каждый год в июле все локальные OpenStack сообщества по всему миру собираются вместе для того, чтобы подвести итоги предыдущего года, пообщаться друг с другом и главное - поздравить OpenStack с днем рождения. Для нашей страны прошедший год был знаковым, так как к нашему сообществу присоединились не только новые разработчики, но и российские компании, которые работают с данной технологией.

Мы приглашаем Вас разделить с нами радость этого дня и принять участие в мероприятии! В программе: конференция, поздравления и подарки от OpenStack Foundation и спонсоров, празднование для рождения и фуршет.

Посмотреть подробности и зарегистрироваться можно на сайте мероприятия.

Kristian Høgsberg, участник Fedora и уже бывший инженер Intel, всем известный, как основной архитектор Wayland, с июля 2016 перешел в Google. Главное теперь, чтобы гугли не решили с его помощью спроектировать что-нибудь еще более новое и несовместимое, а начали бы долгожданный переход на Wayland!

Поздравляем, Kristian!

Наш коллега из Parallels, Сергей Бронников, поделился опытом тестирования проекта CRIU. К сожалению, его статья опубликована на запрещенном в РФ сайте dou.ua, и может быть недоступна с устройств, где госцензуру РФ обходить непросто, т.е. телефоны, планшеты, смарт-ТВ. Поэтому, пока вы не настроили себе способ обхода госцензуры, вы можете прочитать эту статью у нас.

Контроль качества в Open Source: опыт проекта CRIU

CRIU (Checkpoint and Restore In Userspace) — это проект по разработке инструментария для ОС Linux, который позволяет сохранить состояние процесса или группы процессов в файлы на диске и позднее восстановить его, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Один из основных сценариев использования CRIU — это живая миграция контейнеров между серверами, но им применение проекта не ограничивается.

В 2012 году, когда Эндрю Мортон принял первую серию патчей для ядра Linux с целью поддержки C/R (Checkpoint/Restore) в пространстве пользователя, идея реализовать такую функциональность все ещё выглядела сумасшедшей. А спустя четыре года проект CRIU получил признание и всё больше вызывает интерес к себе. До этого попытки реализовать C/R в Linux уже неоднократно предпринимались (DMTCP, BLCR, OpenVZ, CKPT и т.д.), но все они, к сожалению, не увенчались успехом. В то время как CRIU стал жизнеспособным проектом.

Я разрабатывал поддержку вывода в формате TestAnythingProtocol в систему запуска тестов CRIU и пока делал патч разобрался в том, как устроено тестирование CRIU. Своими знаниями хочу поделиться с читателями DOU.

Потребность в тестировании

На старте проекта всё было просто: трое разработчиков и небольшой набор функциональности. Но в ходе разработки количество разработчиков росло, появлялась новая функциональность, и перед нами встали следующие проблемы:
— Сделать запуск тестов простым и доступным любому разработчику, чтобы каждый при желании мог протестировать свои изменения;
— Количество комбинаций функциональности и поддерживаемых конфигураций стало расти экспоненциально, поэтому ручной запуск тестов стал отнимать много времени, и требовалась автоматизация задач;
— Время пользователей и разработчиков CRIU дорого, поэтому хотелось максимально покрывать функциональность тестами и исключить появление регрессий в новых версиях;
— Процесс тестирования новых изменений и результаты запуска тестов был закрытыми, хотелось сделать процесс прозрачным и открытым для сообщества;
— Процесс ревью перестал был достаточным критерием для принятия новых изменений, хотелось получать больше информации о качестве патчей до вливания в репозиторий.

Процесс разработки CRIU мало чем отличается от разработки ядра Linux. Все новые патчи проходят через список рассылки criu@openvz.org, где все новые изменения ревьюят разработчики из сообщества CRIU. Ревью позволяет выявить ошибки на самой ранней стадии, и поначалу ревью было единственным критерием для принятия новых изменений. В какой-то момент этого стало недостаточно, и теперь параллельно с ревью выполняется множество других проверок для новых изменений, которые влияют на решение, будут ли они приняты или нет: проверка компиляции, автоматический запуск тестов, измерение покрытия кода тестами, статический анализ кода. Для всего этого используются общедоступные инструменты, которые делают процесс проверки прозрачным и открытым для сообщества.

Все новые патчи из рассылки попадают в Patchwork, который автоматически запускает сборку проекта на всех поддерживаемых аппаратных платформах (x86_64, ARM, AArch64, PPC64le), чтобы убедиться, что новые изменения ее не сломали. Для этих целей мы используем сервис Travis CI. Вообще этот сервис ограничен использованием только одной архитектуры — x86_64, поэтому для остальных архитектур мы используем qemu-user-static внутри Docker контейнера.

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

Как устроен процесс тестирования

Для функционального регрессионного тестирования мы используем тесты из набора ZDTM (Zero DownTime Migration), которыми до этого успешно тестировали in-kernel реализацию C/R в OpenVZ. Каждый тест из этого набора запускается отдельно и проходит 3 стадии: подготовка окружения, «демонизация» и ожидание сигнала (который сигнализирует тесту о том, что пора проверять своё состояние), проверка результата.

Тесты условно разделены для две группы. Первая группа — это статические тесты, которые подготавливают некое постоянное окружение или состояние и «засыпают» в ожидании сигнала. Вторая группа — динамические тесты, которые постоянно меняют своё состояние и/или окружение (к примеру, пересылают данные через TCP соединение). Если в 2012 году набор тестов CRIU включал порядка 70 отдельных тестовых программ, то на сегодняшний день их количество увеличилось до 200. Функциональные тесты мы запускаем на публичном Jenkins CI по расписанию и для каждого нового изменения, добавленного в репозиторий CRIU. Польза запуска тестов для новых изменений несомненна — по нашей статистике, примерно каждое 10-е изменение ломает тесты.

Учет конфигураций. Вообще для тестирования достаточно собрать проект с помощью make и запустить make test, так что протестировать CRIU может каждый. Но количество комбинаций функциональности и конфигураций CRIU слишком велико, чтобы делать это вручную, или в противном случае это не будет полноценным тестированием CRIU. Да и, как известно, разработчики очень ленивы для регулярного прогона тестов, и даже если прогон тестов будет занимать 1 минуту, то они все равно не будут их запускать :)

Основная конфигурация для тестирования — запуск всего набора тестов на хосте, при котором каждая тестовая программа садится в определённую позу, процесс теста сохраняют и восстанавливают, а потом просят проверить, в той же позе он остался или нет.

Следующей по важности конфигурацией является проверка, что C/R не только работает, но и после checkpoint основной процесс не cломался. Поэтому каждый тест нужно прогнать ещё и в варианте, когда выполнена только первая часть (без восстановления) и проверить, что поза соблюдена. Это безресторный тест.

Восстановленный процесс может оказаться в той же позе, но не пригоден к повторному C/R. Так появляется ещё одна конфигурация — повторный C/R. Потом появляются конфигурации со снапшотами, C/R в окружении пространств имён, C/R с правами обычного пользователя, C/R с проверкой обратной совместимости, проверка успешного восстановления на BTRFS и NFS (потому что эти ФС имеют свои «особенности»). Но помимо C/R для отдельных процессов, можно делать групповые C/R — сохранение группы процессов, когда все процессы находятся в одной позе и когда каждый процесс находится в своей позе.

Тестирование ядер. CRIU поддерживает несколько аппаратных архитектур, сейчас это x86_64, ARM, AArch64, PPC64le и на подходе i386. Суровая реальность заставляет нас тестировать еще и несколько версий ядер: последний официальный релиз ванильного ядра, ядро RHEL7 (которое базируется на 3.10) и ветку linux-next. Длительность тестов небольшая (2-10 мин), но если учесть количество комбинаций существующих сценариев и возможных конфигураций, то получается внушительная цифра.

Ядра из ветки linux-next мы тестируем, чтобы заранее находить и сообщать об изменениях, которые ломают наш проект. За время существования CRIU мы нашли порядка 20 багов, связанных с linux-next. Для тестирования linux-next нужно каждый раз использовать чистое тестовое окружение и для создания таких окружений очень удобно использовать облака для создания окружения по запросу. В нашем случае мы используем API одного из облачных провайдеров для создания ВМки, устанавливаем в нее ядро и запускаем тесты. Мы уверены, что не получим никаких «наводок» от предыдущих запусков.

Fuzz тестирование. Функциональное тестирование гарантирует, что то, что работало раньше, будет работать и впредь, но оно не способно найти новых багов. Поэтому мы им не ограничиваемся и дополнительно используем fuzz тестирование. Не так активно как хотелось бы, но тем не менее. Например, тест maps007 создает random mappings и «трогает» эти участки памяти.

Error пути. Одними из плохо покрываемых участков кода являются error пути. Наиболее критические такие участки мы тестируем с помощью техники fault injection. Это метод тестирования, при котором предполагается искусственное внесение разного рода неисправностей для тестирования отказоустойчивости и, в частности, обработки исключений. Для такого вида тестирования ни одно существующее решение нам не подошло, и мы написали свой движок прямо в коде CRIU. Часть тестов CRIU регулярно запускаем в режиме fault injection.

Статические анализаторы кода. В какой-то момент мы решили попробовать статические анализаторы кода. Начали с clang-analyzer и потом перешли на использование сервиса Coverity, который бесплатен для использования в открытых проектах. До использования статических анализаторов мы переживали, что отчёты будут содержать много false positive багов, но на деле оказалось все наоборот — анализаторы находят баги, которые не выявляются тестами. Теперь ни один релиз не обходится без проверки кода в Coverity.

Покрытия кода. В маленьких проектах никто не меряет покрытие кода регулярно, потому что оно и так известен мейнтейнеру проекта и со временем меняется незначительно. В основном покрытие измеряют, чтобы выявить участки кода, которые никогда не затрагиваются тестами, и понять, как их можно покрыть тестами или понять причины, почему существующие тесты не покрывают их. Разбирая результаты покрытия кода, мы не раз находили куски кода, которые не были покрыты тестами, хотя тесты на них были. Ужасно это понимать, когда сталкиваешься с этим. Для измерения покрытия мы используем стандартные утилиты gcov и lcov и вдобавок загружаем результаты в сервис Coveralls, чтобы проанализировать, какие именно строки в коде затрагиваются тестами.

К чему стремиться

В ходе решения стоявших перед нами проблем мы составили список того, какими должны быть тесты:
— К написанию тестов нужно подходить ответственно, потому что нет ничего хуже, чем искать баг в коде проекта, а найти его в коде теста;
— Код тестов должен быть таким же качественным, как и качество основного кода;
— Хорошие тесты получаются, когда вы их пишите до начала разработки фичи;
— Ценность тестов для разработчика увеличивается, если он их пишет и использует сам;
— Тесты нужно прогонять до того, как код попал в репозиторий, так как в этом случае понятно, кто должен исправлять выявленные проблемы;
— Плохие тесты хуже, чем их полное отсутствие. Потому что они дают ложное чувство того, что код работает.
— Много тестов не бывает, в проекте CRIU соотношение полезного кода к тестовому примерно 1.6 (48 KLOC vs 30 KLOC), и есть куда расти.

Microsoft опубликовала спецификацию протокола Language Server Protocol (LSP) в своей организации на GitHub. Это протокол для создания веб-ориентированных IDE для одиночной и коллективной разработки (и возможно в них программировать будет удобнее, чем в Vim). Наши коллеги из Red Hat и Eclipse Foundation добавляют поддержку в свои продукты - Red Hat объявил о разработке Javа-сервера LSP, а Eclipse Foundation (стратегический партнер Red Hat) объявил о поддержке LSP в Eclipse Che. Новость уже обсуждается коллегами-аналитиками на OpenNET.ru.

Наш коллега, Roland Wolters, написал хаутушку о том, что делать если среди всех многочисленных модулей Ansible еще нет поддержки некоего REST API сервиса. Оказалось, что ничего сложного.


Нет модуля Ansible? Напиши сам, ты же программист!


Кстати, месяц назад Red Hat анонсировала выход Ansible 2.1, с поддержкой Windows и Docker.

Наш коллега, Remy DeCausemaker, объявил, что вынужден оставить пост "Fedora Community Action and Impact Lead" (что бы это ни значило) ради присоединения к команде Хиллари Клинтон. К сожалению, это потребует от него полной отдачи, и он не сможет совмещать. Многие наши коллеги участвуют в политике, как на профессиональном уровне, так и на любительском, поддерживая других политиков и политические организации, и мы всячески приветствуем решение Remy и желаем ему удачи!


Ralph Bean (в кепке) и Remy DeCausemaker

Гентушник и бывший инженер Collabora, Arun Raghavan, объявил о выходе PulseAudio 9.0. Среди заметных новинок - улучшение эхоподавления, о чем Arun уже подробно рассказывал в своем блоге, улучшение в маршрутизации звуковых потоков, и поддержка memfd вместо POSIX shared memory, о котором вы могли слышать. Все идет согласно плану, который Arun продемонстрировал публике еще в 2014 году. Новость уже обсуждают коллеги-аналитики на OpenNET.ru.

Доступен для загрузки RFRemix 24. На этот раз с небольшим запозданием, так как RPM Fusion всё-таки решили выложить свои пакеты для 24-й версии в updates-testing. Из-за этого пришлось в спешном порядке переделывать образы. Но будьте внимательны, пакеты в RPM Fusion Free Updates Testing не подписаны. Такая воль kwizard'а. Вообще для Fedora 24 сейчас есть testing репозиторий Free, а в качестве NonFree можно использовать репозиторий от Fedora 23.


gnome
Что у нас нового и старого
  • Для загрузки доступны две большие редакции RFRemix Server и Workstation (включая сетевые установки), а также Live-образы с различными рабочими столами;
  • Для поддержки мультимедии используется всё ещё RPM Fusion, у которого зашевелилась инфраструктура. Вообще вероятность что он будет жить намного выше, чем у проекта unitedrpms.github.io;
  • Для RPM Fusion используются немного измененные release-пакеты с подключением nonfree от Fedora 23 (для 24-й этого репозитория просто нет). Они должны обновиться на оригинальные автоматически, когда RPM Fusion будет полностью готов (что как раз и произошло в Fedora 23);
  • Многие пакеты из репозиториев Russian Fedora доступны из приложения GNOME Software (Программы);
  • Так же у нас пересобран freetype с subpixel rendering и subpixel hinting;
  • Fontconfig содержит патчи Ubuntu для LCD мониторов (в общем сломали шрифты как всегда);
  • Пакет fontconfig-infinality был выпилен по просьбам;
  • В образы Workstation (GNOME 3.20) по умолчанию для GNOME Shell (не для GTK) используется тема Korora из одноименного проекта. Также опционально добавлены темы Adapta и EvoPop для GTK и иконки EvoPop. Все отключается и в ключается в gnome-tweak-tool;
  • В репозитории содержится почти всевозможный набор мессенджеров: skype, viber, telegram-desktop. Также есть Chromium с pepper-flash, полный набор Opera и обычный flash-plugin.
Образы

Для загрузки доступны Live образы Workstation, KDE (Plasma 5), LXDE, XFCE, MATE и Cinnamon. DVD и netinstall образ RFRemix Server и netinstall образ RFRemix Workstation.

Куда сходить спросить, пожаловаться Обновление

В принципе обновление с RFRemix 23 не должно составить проблем. Сперва полностью обновите текущую систему, а затем отдайте команду:

dnf --releasever=24 distro-sync --nogpgcheck

Планы на RFRemix 25

Так как RPM Fusion пока не оправдывает никаких надежд, у нас появилось огромное желание собрать всё нужно у себя. Одним словом сделать свой собственный велосипед. Эта идея не нова, но по крайней мере мы будем иметь всё что нужно и не зависеть от внешних репозиториев. Так что ждите RFRemix 25 осенью этого года.

Страницы