Russian Fedora

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

Content (59 страница со старыми записями)

X.org без привилегий суперпользователя

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

Прошли годы, и благодаря systemd, наш коллега, инженер Red Hat, Hans de Goede, добился работы X без дополнительных привилегий, и без одновременного доступа к /dev/ttyXX.

Первая серия патчей уже отправлена им в список рассылки.

Идея запускать такой сложный кусок системы, как X, не под суперпользователем (и без suid-бита) не нова. С ней экспериментировал Intel в рамках уже давно забытого проекта moblin, потом Canonical попыталась реализовать, но столкнулась с рядом проблем, и отложила планы.

Участники Fedora немного чувствуют вину за неудачу Canonical, т.к. мы дали им неверные подсказки, например использовать ConsoleKit, в то время, как вкладывались в systemd, переводя ConsoleKit в разряд неподдерживаемого ПО. Тем не менее, даже без ConsoleKit, оставались бы нерешенными проблемы, связанные с отсутствием системного вызова revoke, доступного, например, в OpenBSD.

Разумеется, в частных случаях отдельные энтузиасты добивались работы X на самосборных системах, когда не требовалось обеспечивать безопасность единственного пользователя (см. "админ локалхоста").

И вот, наконец-то, благодаря systemd, и высокой интеграции его компонентов, мы можем в общем случае запускать X не от суперпользователя. Одна из внезапно возникших проблем, это логи X.org, которые он ведет самостоятельно, не используя даже syslog. Недавно пришедший к нам Tom Gundersen предлагает использовать syslog или Journald для ведения логов. В обсуждении в ленте Google+ участника ArchLinux, David Herrmann, инженер Linaro, Koen Kooi, предлагает использовать Journal, т.к. это сильно упростит жизнь embedded-разработчиков, которые переходят на systemd, а Aaron Seigo высказывается за общесистемное решение, т.е. за syslog или Journald.

OpenCL в Fedora

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

С октября 2013 года ситуация с OpenCL в Fedora еще немного улучшилась, хотя "из коробки" пока не работает.

Участник нашего коммьюнити, Igor Gnatenko, присоединился к инициативе инженера Red Hat и разработчика oVirt, Fabian Deutsch, и предложил ряд изменений для Mesa, которые корректно включают поддержку OpenCL в библиотеке. Как минимум, можно будет запустить стандартные утилиты и получить параметры доступных OpenCL-драйверов.

К сожалению, работа еще не завершена, и необходимо замерджить эти изменения в Mesa в репозиторий Fedora, и добавить еще несколько библиотек и приложений (сейчас идет работа по включению beignet).

Статистика ядра Linux версии 3.13

На LWN опубликовали статистику по ядру Linux версии 3.13. Ситуация пока не меняется, и Red Hat по количеству коммитов продолжает болтаться сразу под тройкой лидеров, как в ядре 3.12, хотя и вышел на первое место по общему количеству измененных строк кода.

Дифченки обогнали Google, NVidia, Oracle и ARM по количеству патчей, а вот по количеству измененных строк не смогли войти в TOP-20. Ничего, дифченки еще нам покажут! Но самым заметным результатом остается влияние коммьюнити - коллективный участник, скрывающийся в категориях (None), (Unknown), (Consultant), написал почти пятую часть всех патчей, что равняется примерно такой же части фактически измененных строк. Его роль крайне мала при раздаче signoffs, процессе, необходимом для включения патча в ядро, что показывает, что все ключевые разработчики уже трудоустроены. Что характерно, лидером по Signed-off-by остается Red Hat, и примерно пятая часть всех изменений была одобрена инженерами Red Hat, что позволяет компании контролировать процесс разработки ядра. Кроме Red Hat, лидерами про Signed-off-by является Intel и Linux Foundaton, после которых идут "железячники" Linaro и Samsung с Texas Instruments, после которых уже идут Google, Novell и IBM.

Почему приложения, при SELinux в режиме Permissive, порой работают неправильно?

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

Как известно, SELinux работает в трех режимах - Disabled, Permissive, Enforcing (рекомендованный). Режим Permissive должен быть идентичен Enforcing за тем исключением, что все запрещенные действия разрешаются. Это позволяет отладить политики SELinux для непростых случаев, чтоб потом переключиться в Enforcing уже с правильными параметрами. Приложение, когда SELinux включен в режиме Permissive, должно работать как будто SELinux выключен. К сожалению, это порой не так, и это очень странно.
Dan разъясняет. Дело в том, что модуль ядра работает хорошо, но есть еще проверки SELinux в userspace. Dan выделяет следующие сценарии:
  • Может ли приложение соединиться с указанным D-Bus демоном?
  • Позволено ли приложению запускать один из демонов systemd?
  • Может ли процесс, запущенный от суперпользователя, менять пароли?
  • Разрешать ли sshd логиниться dwalsh как unconfined_t?

Эти проверки происходят в userspace, и ядерный модуль их не увидит. Их можно определить по типу сообщения "USER_AVC" в логах. И вот если эти тесты написаны неправильно, то можно увидеть запреты, даже при включенном в Permissive режиме SELinux. Такие проверки включены в самые разные части системы - D-Bus, systemd, X Server, sshd, passwd, и, к сожалению, в ряде случаев в upstream проектов, люди не хотят включать дополнительную проверку на Permissive (или еще не реализовали). Если вы столкнулись с такой проблемой, то открывайте заявку в Bugzilla.redhat.com, и Dan вам поможет.
В логах эта ситуация видна очень хорошо. Если вы переключили SELinux в Permissive режиме, и видите флаг success=yes в записи типа USER_AVC или AVC, то это нормально - сработало правило SELinux, но приложение получило доступ к запрашиваемому ресурсу. А вот если вы видите флаг success=no, то самое время сообщить в багзиллу.

Карта зависимостей в Fedora

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

Одной из интересных задач, стоящих перед нашим коммьюнити, это разработка публично доступного механизма для бутстрапа системы. Во-1 периодически находятся энтузиасты, что переносят дистрибутив на новые платформы, а во-2 это интересно многим вендорам - полная пересборка RHEL. Важно отладить процесс до полностью автоматического режима, т.к. делать это вручную или самописными скриптами, это Dorogo & Glupo.

Для бутстрапа надо собрать не только дерево пакетов, но и инструменты для сборки дерева. А лучше потом собранными инструментами собрать инструменты еще раз. Эта работа тесно связана с еще одной задачей - ядро системы (Fedora Core) должно содержать как можно меньше пакетов, чтобы кросс-компиляция занимала меньше времени. Важно, что время уйдет в т.ч. на построение дерева зависимостей, и последующее распутывание получившегося постоянными пересборками. Смело скажем, не скрывая горькой правды, что Fedora тут сильно отстает от некоторых других дистрибутивов.

Как говорят те, кто пробовал, пересобрать с нуля тот-же Debian или SUSE получится гораздо легче, чем пересобрать Fedora или RHEL. Но работа по исправлению этой ситуации ведется.

Наши коллеги, Harald Hoyer и Phil Knirsch решили построить граф зависимостей между пакетами ядра системы, и вот что у них получилось: Self-Hosting kernel build requirements Можно сказать, что это политическая карта пакетов Fedora.

Различия между kdbus и Binder

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

Известный гентушник и дистрохоппер Greg Kroah-Hartman попробовал объяснить, почему Binder, использующийся в Android вероятно никогда не будет заменен kdbus. В статье, написанной им с помощью Kay Sievers и Lennart Poettering, он упрощает различия до двух - D-Bus требует память, а Binder целиком полагается на CPU. Грубо говоря, Binder, это синхронная система распределенных блокирующих вызовов и посылок сообщений, не хранящая их, а сразу доставляющая адресату наподобие той, что должна присутствовать в любом микроядре (аналог gen_server:call/2 в Erlang). А вот D-Bus, как раз наоборот, асинхронная неблокирующая шина данных, накапливающая сообщения в памяти (очень приблизительный аналог gen_server:cast/2 в Erlang).

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

Заметку уже обсуждают в ленте G+ автора.

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

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

Участник проектов Fedora и LibreOffice, Caolán McNamara, благодаря уже известному вам переходу с устаревшего класса строк в LibreOffice на новый, наконец-то исхитрился пофиксить десятилетний баг в LibreOffice / OpenOffice.org. Конечно, в Apache OpenOffice его уже никто не будет фиксить, и он там так и останется навсегда, но кто же будет тревожить ПО с кладбища проектов, когда есть хороший LibreOffice? Это не все новости от McNamara. Он с гордостью объявляет, что перевел уже 70% диалогов LibreOffice в новый формат GtkBuilder.

Недавно вышедший Rust 0.9 доступен в дополнительном репозитории Fedora, созданном благодаря Copr.

Инженер Red Hat, Andreas Schneider анонсировал выход libssh версии 0.6.0.

Среди прочего, был добавлен серверный API для работы с открытыми ключами (в виде callback), алгоритмы ECDSA и ECDH и поддержка Kerberos.

Наконец-то появились "официальные" образы Fedora для Docker.

В кавычках, потому что их собрала не RelEng группа, а наш коллега Lokesh Mandvekar.

Выпущена Fedora 20 для System z.

И забавная новогодняя новость, если кто упустил - Eric S Raymonds предложил перевести Emacs c Bazaar на Git.

Bazaar, это еще один проект, поддерживаемый Canonical, кстати.

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

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

Вышла новая версия Copr, новой сборочной системы, о которой вы уже слышали. В новой версии добавлена возможность сборки для EPEL 7, которую как раз недавно анонсировали.

[STRIKEOUT:Дикий срач] Конструктивный диалог вокруг dnf, перспективной замены yum, не был безрезультатным. После недавно вышедшей версии 0.4.10, в которой была добавлена возможность плагинам добавлять команды, быстро вышла версия 0.4.11, начиная с которой возможности для плагинов были расширены еще больше (например, для создания плагина, который бы возвращал поведение, аналогичное Yum, при удалении kernel).

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

Первая новость после присоединения к нам команды CentOS (всех трех человек). Открыт доступ к git-репозиториям CentOSзеркало на GitHub). Там пока ничего особо нету, но будет вся сборочная инфраструктура (конфиги, kickstart-файлы, и т.п.).

Ralph Bean продолжает работать над централизацией нашей инфраструктуры. Он анонсировал замену старого узла Bugz.fedoraproject.org в пользу интегрированного с Pkgdb2 решения.

И напоследок, интересная новость. Наш товарищ, Max Lapshin, написал наверное первую рабочую библиотеку по работе с RPM, не использующую librpm. С непритворным ужасом и изумлением он ознакомился с форматом пакета, о чем и пишет в своем посте. Несмотря на то, что библиотека еще не оформлена, как библиотека, и написана на Erlang, мы уверены, что проведенная им работа будет полезна в т.ч. и другим разработчикам, например, при реализации бинарного формата на любом другом языке. Напомним, что разработчикам RPM проблемы стандарта известны, и уже сформулированы планы на инфраструктуру вокруг RPM на ближайшую пятилетку. В планы, кстати, входит и dnf.

Firefox медленно переходит на GTK3

Сразу после новости о сборке Firefox с gstreamer, пришла еще одна - выложили первую версию Firefox с поддержкой GTK3.

Состояние пока очень плохое. Не только не работают плагины, но и возникают совершенно необычные глюки на ровном месте, особенно с нетипичными DE, такими как MATE. Но в целом странички уже открывает. За прогрессом можно следить в тикете №627699.