Для некоторых наших участников до сих пор остается загадкой непреодолимое желание некоторых наших пользователей добавить в систему ряд известных Windoz-шрифтов. Ведь многие из нас живут без них, и ничего!

А вот наш коллега, Caolán McNamara, начал совсем уж необычный эксперимент. Он устанавливает в Linux-систему шрифты из Mac OS X, и пытается их использовать в LibreOffice. Сразу скажем, что мы не уверены в законности этого действия, если у вас нет легально купленной копии Mac OS X, но Caolán рискнул. В результате он получил необычный результат. Шрифты в fontconfig есть, а LibreOffice их не видит. Как обычно, для наших коллег, Caolán не побежал жаловаться в чатик или форум, а сел разбираться. Выяснилось, что в LibreOffice не поддерживалась версия "2" ttс-фонтов, нужно было добавить поддержку кодировки имени фонтов, используемую в Mac OS X, перевести Apple Language ID во внутреннее представление LibreOffice, и необходимо было внести ряд других мелких изменений.

Работа еще не закончена, но уже кое что работает. Теперь вы можете нас удивлять не только странным желанием использовать Windoz-шрифты, но и желанием использовать Mac OS X-шрифты.

Инженер Red Hat и участник Fedora и Debian David Airlie рассказал о текущем состоянии Virgil 3D (статья за paywall) на прошедшем LinuxCon North America. Мы уже вкратце упоминали про Virgil 3D, и возможно пришла пора рассказать о нем, и проблеме, которую он решает, поподробнее.

Очень хочется предоставлять виртуальным машинам возможности 3D-ускорения, имеющиеся на хостовой системе. Сейчас есть лишь проприетарные решения. Virgil 3D, это как раз открытый вариант. Сейчас он использует Mesa, но в будущем планируется добавить и DirectX и Direct3D драйверы.

Исходная задача

Airlie сказал, что решение VMware "лучший вариант из существующих" для виртуального GPU. Однако, он основан на DirectX 9, так что у него ограниченные возможности, и он проприетарный, кроме куска, который работает в гостевой системе Linux. У VirtualBox тоже есть решение, но оно основано на OpenGL, который является "худшим вариантом", т.к. его сложно сделать безопасным. У OpenGL есть слишком много точек входа, и для приложения в userspace очень легко добиться переполнения буфера или создать иные проблемы. Также есть драйвер vGallium, но это лишь исследовательский проект, до сих пор не достигший уровня пригодности для широкого использования.

Virgil 3D основан на virtio, на стандарте для виртуализированного ввода/вывода (I/O), созданном Rusty Russell. Основная идея virtio, это набор очередей для взаимодействия с драйвером, наряду с конфигурационным пространством, которое может выглядеть как PCI.

С графической части Mesa реализует OpenGL, а ее часть Gallium3D упрощает разработку 3D-драйверов. Под Mesa есть еще EGL API, который сидит между OpenGL и оборудованием. EGL был изначально спроектирован для встраиваемых устройств, но он теперь "все чаще и чаще используетсядля всего подряд", сказал David, и однажды "захватит всё". Еще одна часть мозаики, это SPICE, протокол для "удаленного десктопа" — он предоставляет удаленный доступ к аудио, видео, устройствам ввода-вывода и т.п.

На реальном графическом оборудовании обязательно есть что-то типа ring buffer, куда ядро отправляет команды. Графические драйверы из userspace создают потоки таких команд (которые манипулируют текстурами, surface, шейдерами и т.п.), чтобы передать их в ядро. Эти userspace-команды должны рассматриваться, как небезопасные. Они копируются в ядро, затем проверяются, чтобы превратить их в "безопасные" команды. А уже эти команды затем помещаются в ring buffer, за которыми располагается защитная операция (fence). Т.к. GPU асинхронное, то ядро может узнать, что набор команд был выполнен, лишь по порядковому номеру, присвоенному уже выполненной защитной операции (fence).

Поддержка 2D

Первая задача для Virgil 3D, задолго до перехода к "3D части, в которой я был заинтересован", была, это запустить базовый virtio GPU драйвер, сказал Airlie. Он поддерживал несколько мониторов, хардверные курсоры, и базовый набор 2D команд. Драйвер предоставлял memory-mapped I/O, PCI, или VGA устройства, и должен был работать на любой архитектуре, что поддерживала virtio. "Базовым компонентом был командный ring buffer", хотя оригинально было задумано два кольцевых буфера, и один для защитных операций (fence). Разработчик QEMU переписал его для использования лишь одного командного ring buffer — кольцевой буфер для защитных операций (fence) может быть добавлен попозже, если его отсутствия станет проблемой.

Базовый объект в драйвере, это ресурс, сказал Airlie, и каждый ресурс обладает уникальным идентификатором. Для 2D, каждый ресурс обладает шириной, высотой, битовой глубиной, привязанных к нему. Для 3D, есть еще "целый букет" атрибутов, и это "гораздо сложнее". Гость просто ссылается на ресурс по его идентификатору, а хост выделяет память и создает собственно ресурс. Драйвер получает страницы памяти гостевой системы, чтобы присоединить их к ресурсу.

Ресурсы отображаются в объекты OpenGL. Для 2D, драйвер просто копирует данные из гостевых страниц памяти, присоединенных к ресурсу, в объект OpenGL. Передавать данные 3D в хостовую систему гораздо сложнее, сказал Airlie. Для 2D хост просто передает данные, а для 3D можеть быть необходимость в вычитывании данных из оборудования назад, в гостевую систему.

Этот простейший драйвер предоставляет "ресурсы и способ наполнить их данными", сказал David; следующий шаг, это превратить ресурс в "передний объект", чтобы "люди могли его увидеть". Это сделано с помощью set_scanout(), что примерно тоже самое, что и выбор режима работы на обычном графическом устройстве. Также нужно вызвать flush_resource(), чтобы вызвать перерисовку OpenGL. Все это "основа простейшего GPU", большая часть которого уже включается в QEMU.

3D

Для 3D, поток небезопасных команд создается из Mesa в гостевой машине, и отправляется в драйвер с помощью команды SUBMIT_3D. Создаются 3D-контексты для каждой user-space программы из гостевой системы, и к ним присоединяются ресурсы. Это означает, что гостевая программа не обладает доступом к ресурсу, который она не создала, т.к. он просто не будет присоединен к 3D-контексту.

У потока 3D-команд есть несколько типов действий. Есть действия над состоянием объекта (создать, привязать, уничтожить), над различными типами шейдеров (включая вертексы, фрагменты и геометрию), по управлению поверхностями (surface) и текстурными объектами и т.п. Кроме того, есть также операции рендеринга, например draw, clear, и blit. Также есть набор команд, которые завершают набор 3D-команд. Всем этим нужно управлять в Virgil 3D.

Необходимо пять несвязанных компонентов, чтобы это все заработало в Linux, сказал Airlie. Два куска работают на хостовой машине: virtio GPU драйвер в QEMU и в библиотеке рендеринга. Причем, последний, это довольно большая работа. Гостевое ядро должно обладать DRM/KMS (direct rendering manager/kernel mode setting) драйвером, который поддерживает virtio GPU. В user-space ему нужен Gallium3D-драйвер для Mesa, чтобы общаться с ядром, и может понадобиться device-dependent X (DDX) драйвер для X-сервера.

Когда Airlie начал работу над проектом Virgil 3D, QEMU поддерживал лишь Simple DirectMedia Layer (SDL) 1.2 для графики, и там не было поддержки нескольких мониторов. Это значило, что QEMU нужно было портировать на SDL 2.0. Эта работа уже включена в апстрим QEMU. А код virtio GPU находится "в чьем-то дереве исходников", и пока направляется на включение в QEMU.

Библиотека для рендеринга, это то, "где вся веселуха", сказал он. Она получает поток команд, и превращает их в вызовы OpenGL API. Она также преобразовывает шейдеры в GLSL (язык для шейдеров, использующийся в OpenGL).

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

Чтобы этого добиться, код использует dma_buf фичу ядра и передает файловые дескрипторы из QEMU в клиент удаленного десктопа и обратно. Однако SPICE использует TCP, а дескрипторы могут передаваться лишь по Unix-сокетам. Так что пока David подкрутил кое-какие права доступа у Unix-сокетов, временно назначив им права 777, чтобы хоть как то все это запустить.

Есть некоторые проблемы с OpenGL, которые надо поправить, включая то, как работать с фичами GL 3.1, которые используются редко, и которые непросто реализовать. Если на хостовой машине что-то использует GL 3.1, то Virgil 3D будет нужно как-то это обрабатывать, но GL 3.1 сейчас не реализован для Linux (и для Apple, кому интересно). Много функциональности из 3.1 может быть реализовано с помощью других фич и команд OpenGL, так что их теоретически возможно эмулировать.

TODO-лист для Virgil 3D довольно короткий, сказал Airlie, но все пункты в нем "огромны". В список входят корректная обработка возможностей OpenGL, использование текстового представления шейдеров в формате TGSI (Tungsten Graphics Shader Infrastructure) вместо бинарного, используемого сейчас (что будет "проблематично"), уже упомянутая проблема с GL 3.1, многопоточность в GL-части QEMU, и, наконец, включение всего в апстрим.

Airlie завершил свое выступление демонстрашкой 3D-игры Xonotic, запущенной в виртуалке на его ноутбуке. Получилось, как он сказал, 60 fps, "по крайней мере". Он ответил на вопросы из зада, отметив, что использование протокола удаленного доступа по сети приведет к использованию видеосжатия на хостовой машине, и передаче результатов в программу-просмотрщик, а не прямую передачу 3D-объектов и команд. Он был бы рад ошибаться в этом, но в любом случае он попробует сделать передачу 3D-объектов по сети своим следующим проектом.

[Jake Edge, автор оригинальной статьи, хотел бы поблагодарить Linux Foundation за помощь в поездке в Chicago на LinuxCon North America.]

Richard Hughes анонсировал PackageKit 1.0.0. В этом релизе отказались от плагинов - от них лишь проблемы. Вся функциональность, которая хоть кем-то затребована, была перенесена в дерево проекта. Были удалены бэкенды для conary, opkg, smart, yum - их никто не поддерживал уже очень давно. Richard недавно собрал список проблем в имеющихся бэкендах, и его услышали - бэкенды для alpm, aptcc, hif, zypp были обновлены.

Alexandre Oliva написал статью о многопоточности и потокобезопасности в Glibc.

К сожалению, Glibc не полностью соответствует стандарту POSIX в терминах потокобезопасности. И, к еще большему сожалению, проблемы есть не только в расширениях Glibc, но и в реализации POSIX-стандартных функций. В Red Hat озаботились проблемой, и с прошлого года вели аудит функций Glibc на предмет соответствия стандарту. Сейчас работа завершена, в общем никаких открытий не сделано, но удалось составить список различий между POSIX и Glibc. Дальнейшие шаги пока определяются - порой POSIX не требует потокобезопасности, а в Glibc она реализована, но порой бывает и наоборот. В последнем случае, перед исправлением надо учесть API/ABI-совместимость.

В статье, Alexandre рассказывает о том, почему функции бывают потоконебезопасными, что сделать в программе, чтобы она использовала эти функции, и работала, как ожидается, и что еще почитать по теме.

Внимательные пользователи Fedora 21 и RHEL 7 уже заметили появление нового типа в SELinux - unconfined_service_t. Dan Walsh решил объяснить, что это за штука такая.

Каждый, кто хоть раз использовал SELinux, знает, что домен unconfined_t, это метка процесса, который не ограничивается (unconfined) [SELinux]. Но это не единственный неограничиваемый (unconfined) домен в SELinux. На самом деле, это домен по умолчанию пользователя, который залогинился в системе. Во многих случаях, нам стоит использовать тип unconfined_user_t, а не unconfined_t.

По умолчанию, существует довольно много неограниченных (unconfined) доменов в системе с SELinux Targeted. Мы их завели, чтобы пользователи могли запускать ПО/сервисы без вмешательства SELinux, если SELinux не знает о них. Вы можете просмотреть список всех неограниченных (unconfined) доменов в вашей системе с помощью этой команды:

seinfo -aunconfined_domain_type -x


В RHEL6 и старых версиях Fedora, мы запускали сервисы с типом initrc_t по умолчанию. Ну, конечно, если кто-нибудь не написал для них специальное правило. Тип initrc_t, это по умолчанию неограниченный (unconfined) домен, пока вы не отключаете unconfined.pp модуль. Запуск неизвестных сервисов, как initrc_t, позволяет администраторам запускать приложение даже если для него не было написано правила.

В RHEL6 есть такие правила:

init_t @initrc_exec_t -> initrc_t
init_t @bin_t -> initrc_t


Если администратор добавляет исполняемый файл в /usr/sbin или /usr/bin, то init-система может запустить этот сервис с типом initrc_t.

Однако, мы обнаружили проблему.

Проблема в том, что есть слишком много правил перехода из домена initrc_t в другой домен. Например, если программа, о которой мы ничего не знаем, запущена в домене initrc_t, и она запускает, например, rsync чтобы скопировать данные между серверами, то SELinux переведет программу в домен rsync_t, и всё поломается наглухо. SELinux ошибочно посчитает, что rsync был настроен в серверном режиме, не в клиентском. Другие правила перехода также приведут к поломкам.

Мы решили, что нам нужен новый неограниченный (unconfined) домен для запуска сервисов, и в котором не будет никаких правил перехода в другие домены. Поэтому мы создали домен unconfined_service_t. Теперь у нас есть такое правило:

init_t @bin_t -> unconfined_service_t


Процессу, запущенному как unconfined_service_t, разрешено запускать другие ограниченные программы, но он сам остается в домене unconfined_service_t. SELinux не будет блокировать доступ. Это значит, что если вы установили сервис, для которого не написано никаких правил, то он будет работать без препятствий со стороны SELinux.

Иногда приложения устанавливаются в нестандартные директории внутри /usr или /opt (или в случае Oracle даже в /u01), что заканчивается маркировкой приложения как usr_t, поэтому мы добавили следующие правила перевода из домена в домен:

# sesearch -T -s init_t  | grep unconfined_service_t
type_transition init_t bin_t : process unconfined_service_t;
type_transition init_t usr_t : process unconfined_service_t;


Вы можете их найти уже в Fedora 21.

Подводя итог

Будем надеяться, что unconfined_service_t упростит работу с неотключенным SELinux на системах, на которых приходится запускать сервисы от сторонних разработчиков, и позволит защищать прочие сервисы, запущенные на ваших системах.

Примечание:
Автор благодарен Simon Sekidde и Miroslav Grepl за помощь в создании этой заметки.

Вы будете удивлены, но облачных средств для service discovery снова прибыло. , один из разработчиков Flynn, еще одной платформы PaaS, написанной уже традиционно на Golang, предложил еще один вариант service discovery - Registrator, написанный, разумеется, тоже на Golang.

Оказалось, что HP не просто так отказалась от покупки Rackspace. Просто они уже присмотрели другой вариант, о котором и объявили только что - HP покупает Eucaliptus. Поздравляем наших друзей с этим достижением! "Что делать будем? Завидовать будем!"

Пока одни бессмысленно борются с systemd и мечтают о мифических линукс-телефонах, другие решают задачи, интересные бизнесу, за что и щедро вознаграждаемы.

В OpenStack теперь будет Царь. На самом деле будет система царей, которые будут в их зоне ответственности помогать Program Technical Lead (PTL).



В инкубатор OpenStack добавили Manila. Это аналог Cinder, но уровнем выше. Если Cinder, это vendor-agnostic сервис блочных устройсв для OpenStack, то Manila, это vendor-agnostic сервис файлов. Он будет предоставлять управление и уровень абстракции над традиционными сетевыми файловыми системами, такими, как NFS, Samba и т.п.

Вышел Qemu 2.1.1, а проект oVirt Node выбирает направление дальнейшего движения, рассматривая идеи из Project Atomic и systemd.

Компании Infinera и KEMP Technologies присоединились к проекту OpenDaylight, в рамках которого разрабатывается открытая SDN. Мы еще раз повторимся, что тема SDN вскоре будет очень горячей. Если уже не стала.

Intel, в рамках своих разработок SDN, поддержал протокол Generic Network Virtualization Encapsulation (Geneve). Этот протокол уже реализован в Open vSwitch, еще одном проекте по разработке SDN.

Кстати, ознакомьтесь, что нового в OpenStack Neutron в релизе Juno. Например, ожидается более полная поддержка IPv6 (т.е. полной не будет, ок, поняли).

Cisco выбрала Red Hat OpenShift, как платформу для создания систем Internet of Things. Теперь Red Hat и systemd будет не только в вашем автомобиле, но и в вашей электрической лампочке. А в автомобиле будет не только systemd, но и OpenStack!

Mirantis опубликовал отличные результаты первой половины 2014 года, и похвастался сильными позициями в секторе размером 3.5 МИЛЛИАРДА биткойнов (1.6 ТРИЛЛИОНА долларов в устаревших денежных единицах). Это телеком-индустрия, очень осторожный и консервативный рынок, и влезть туда непросто. Зато и вылезти тоже не получится!

Сильные позиции Mirantis среди потребителей позволяют нарисовать довольно радужные перспективы, немного омрачаемые лишь торопливыми анонсами VMware относительно еще их не вышедшего продукта. Вообще, за неделю после анонса от VMware мы услышали интересные мнения, например, что OpenStack от VMware не такой уж и open (честно говоря, в этом мы не сомневаемся). Негативные отношения мешают делу, и Борис Ренский посчитал нужным выступить с примиряющих позиций насчет продукта VMware. Не всех из нас это интервью убедило, и некоторые продолжают быть уверены, что градус дискуссии будет лишь нарастать, но народ вроде бы успокоился.

Mike Werner, директор Red Hat, выступил на OpenStack Trove Day с докладом на тему того, как создавать экосистему вокруг проекта:

Welcome To OpenStack Trove Day 2014 from Tesora on Vimeo.



К выходу SystemTap 2.6 мы снова задумались о тестировании. Вот, например, как выглядит рабочий процесс тестирования изменения в OpenStack, который уже начали проклинать обычные разработчики:



Народная примета: если редхатовцы чем-то недовольны, то это скоро заменят. И действительно, предлагается переосмыслить весь процесс разработки OpenStack. Посмотрим, что будет в итоге.

Какие-то плохие новости идут про Rackspace, и там тоже много наших друзей, поэтому мы очень встревожены. В отличие от Mirantis компания сильно рискует в последнее время, особенно после анонса VMware. Недавно были слухи, что их покупает HP, но Hewlett-Packard официально опровергли их. Дошло до того, что всерьез поднимался вопрос, что будет с OpenStack, если Rackspace, компания-основатель, выйдет из бизнеса? Сошлись на том, что ничего страшного не произойдет - Red Hat, HP, IBM и Mirantis осилят разработку проекта и без них. Что бы с ними не произошло, будем надеяться, что на самом ценном ресурсе любой техническом компании, т.е. на разработчиках, это не скажется негативно.

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

А если вам еще мало ссылок, то вот, что за последнюю неделю происходило в коммьюнити и проекте OpenStack.

DevConf.cz начинает прием заявок от желающих выступить в 2015 году. По датам, это будет с 6 по 8 февраля включительно, сразу после FOSDEM 2015. Рабочий язык - английский, но можно и на чешском или словацком, хоть и нежелательно.

Страницы