Russian Fedora

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

Будущие фичи Fedora 21

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

График выхода Fedora 21 пока только утряхивается, а фичи будущего релиза уже начали появляться. Неопределенность с графиком привела к тому, что большое количество фич до сих пор не было анонсировано, и в списке находились лишь известные с октября и ноября 2013 года базовая поддержка OpenCL в Fedora 21, Python3 по умолчанию и обновление Python3 до версии 3.4. Но определенность позволила начать планировать свои возможности, и наши коллеги сразу предложили ряд фич:

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

Есть ли будущее у OLPC?

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

Над проектом OLPC сгущаются тучи. В блоге независимого коммьюнити вокруг OLPC появилась заметка, в которой предвещается скорая кончина проекта. Среди признаков надвигающейся гибели проекта выделяют окончание гарантийного срока, сложности с поиском запчастей, отсутствие поддержки со стороны производителя, отсутствие программистов, продолжающих развивать ПО для проекта, уход Nicholas Negroponte, что приводит к падению энтузиазма у участников коммьюнити (что, в свою очередь, можно считать еще одним показателем скорой гибели проекта).

Заметка быстро стала довольно обсуждаемой, и к вышеуказанным признакам прибавили недавнюю продажу имущества головной компании, после которого осталось несколько миллионов долларов долгов.

Появились и несогласные с утверждением о скорой гибели. Giulia D'Amico, Vice President of Business Development, не согласилась с тем, что проект вот-вот загнется.

Новая модель XO-4, которая работает под управлением Android, уже поступает потребителям - 50 тысяч устройств прямо сейчас поставляются в Уругвай. Другие комментаторы считают, что проект необходимо мерять не сухим языком бухгалтерии, а его культурным и социальным воздействием. OLPC предвосхитил ряд концепций, и многие ныне реализованные идеи возможно даже и не обдумывались бы всерьез без примера OLPC перед глазами. Высказались и люди, которые до сих пор поддерживают проекты, построенные на базе оборудования OLPC. Так что не все так однозначно.

Для нас OLPC навсегда будет примером того, что можно сделать с помощью нашего коммьюнити. Операционная система первоначальных релизов базировалась на Fedora, благодаря чему статистически наш дистрибутив одно время стал самым популярным предустановленным Linux-дистрибутивом на ноутбуках, позднее уступившим пальму первенства ChromeOS. Другие проекты предустановки Linux на ноутбуках так и не вышли за пределы пилотных партий и фотосессий в магазинах второго эшелона в странах третьего мира. Проект послужил одним из катализаторов разработки GNOME 3, заложил ряд новых концепций в интерфейсе пользователя (Sugar), и впервые реализовал на практике казавшуюся уже несбыточной мечту о полностью свободном ноутбуке.

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

BLKDISCARD, BLKZEROOUT, BLKDISCARDZEROES, BLKSECDISCARD

Rich WM Jones обращает наше внимание на ряд новых ioctl - BLKDISCARD, BLKZEROOUT, BLKDISCARDZEROES, BLKSECDISCARD. Ну, новые они относительно - в ядре с 2010 года, а поддержка в userspace-программах начала появляться недавно (например, в util-linux добавили примерно год назад), т.е., например, в Debian они будут доступны года с 2017.

Rich заметил, что данные ioctl никак не документированы, хотя наши коллеги уже упоминают их в своих докладах (например, Paolo Bonzini на прошедшем недавно DevConf) и решил исправить положение, перечислив их функциональность и ограничения (если есть):

  • BLKDISCARD - требует от блочного устройства удалить все блоки, попадающие в указанный диапазон. Есть ограничение - блочное устройство может игнорировать этот ioctl. Что будет прочитано после выполнения этой функции никак не стандартизируется, и может заполнить указанный диапазон нулями, случайными числами, или просто проигнорировать запрос целиком, оставив все, как есть.
  • BLKZEROOUT - то же, что и BLKDISCARD, но требует заполнить указанный диапазон нулями. Ядро вынуждено реализовать этот функционал само, и устройство тут никак не помогает.
  • BLKDISCARDZEROES - запрашивает у устройства, будет ли оно обнулять секторы, удаленные при помощи вызова BLKDISCARD. Если ответ положительный, то BLKZEROOUT не требуется.
  • BLKSECDISCARD - то же, что и BLKDISCARD, но без какой-либо возможности восстановления. Обязано вернуть EOPNOTSUPP, если устройство не в состоянии этого сделать.

В RHEL 6.5 и выше, утилита blkdiscard уже доступна в составе пакета util-linux-ng.

SELinux больше не будет пугать пользователей, запускающих Windows-программы в Wine

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

SELinux обычно вызывает проблемы лишь с откровенно глючным ПО, и чаще всего люди жалуются, что он блокирует Skype, Flash и Windows-программы в Wine. Из этого перечня видно, что SELinux работает правильно! К сожалению, среди глючных Windows-программ, запускаемых в Wine, попадаются и игры. Некоторые пользователи довольно разумно говорят, что глючную игру можно раз в пару часов и перезапустить - чай не Emacs, и не хотелось бы чтоб SELinux ее блокировал. Dan Walsh прислушался к таким пользователям.

Dan объявил, что DAC-проверки для случая mmap_zero будут выполняться перед проверками MAC (патч был предложен инженером Red Hat, Paul Moore). Раньше программа под Wine зачастую пыталась mmap-ить память начиная с адреса меньшего, чем разрешенное пороговое значение в /proc/sys/vm/mmap_min_addr , что у нее, разумеется, не получалось. Для программы это было некритично - она просто повторяла попытку с увеличенным адресом. Проблема в том, что проводилась и MAC, и DAC проверки, в результате чего логи засыпались сообщениями вида *SELinux is preventing /usr/bin/wine-preloader from 'mmap_zero' accesses on the memprotect*, пугавшими пользователя.

Теперь будет проводиться сначала DAС-проверка, и только если она успешно прошла, будет проверка MAC (самого SELinux). Таким образом MAC-проверки для пользовательских приложений вообще не потребуется, т.к. DAC вернет ошибочное значение EPERM. Проверка MAC будет проводиться только для тех приложений, что запущены от суперпользователя (прошедшие DAC).

Заодно Dan рассказал про интересную историю, которая произошла недавно.

У одного из заказчиков Red Hat не запускались Web-приложения для OpenShift со смонтированной с nosuid партиции, и Dan описывает как он решал эту проблему. Обратите внимание, какой уровень поддержки оказала компания, раз проблема была поднята непосредственно для разработчика подсистемы ядра. Так-то!

NetworkManager обрастает Enterprise-grade функционалом

Основной аудиторией NetworkManager становятся не наши коллеги с ноутбуками, подключающиеся к Wi-Fi, а пользователи серверных / облачных систем. У них одним из требований к приложению обычно является "ничего лишнего", и Dan Williams пошел им навстречу. Недавно он анонсировал отделение от NetworkManager ряда функциональных компонентов. В отдельные плугины были выделен функционал по управлению соединениями ATM, Bluetooth, и WWAN. В дальнейшем Dan планирует выделить управление WLAN в отдельный плагин, т.к. оно зачастую не нужно в виртуалках.

Но не только перераспределением кода внутри NM заняты наши коллеги. Недавно участник проектов Fedora и GNOME, инженер Red Hat, Dan Winship, уже известный вам по работе над новым CLI для NetworkManager, основанным на curses и по удалению кода из Glib, за два коммита включил в NM поддержку VxLAN (см. статью в википедии). Работа заняла у него более полугода, и проводилась в рамках разработки RHEL 7.

А вы, кстати, в вашем облаке используете SDN или bridge?

Серьезно перетряхнуло Basho

Интересные новости от Basho, компании-разработчика NoSQL-базы, Riak, и организатора серии мероприятий, посвященных распределенным системам, RICON. Сначала их Chief Architect, Andy Gross, объявил, что переходит на работу в Twitter, а затем почти сразу их CTO, Justin Sheeny, объявил, что переходит в VMware.

Мы, в отличие от некоторых новостных изданий, не очень беспокоимся за будущее Basho, т.к. там очень хорошая команда разработчиков, и даже если ее уполовинить, то компетенции там хватит на много компаний. Мы просто пожелаем нашим коллегам (как по коммьюнити, так и по прошлым местам работы) доброго пути!

Поддержка протокола kdbus для Wireshark

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

Разработчик Linux, systemd, PulseAudio и ряда других проектов, Daniel Mack, в своей ленте Google+ анонсировал диссектор протокола kdbus для Wireshark (см. также "пишем плагин-диссектор для Wireshark"). Пока диссектор еще не предложен в апстрим для включения, но очень возможно, что вскоре он будет добавлен. Наша практика показывает, что появление диссектора протокола в Wireshark резко упрощает дальнейшую разработку ПО, работающего с этим протоколом, и вот именно поэтому мы, когда разрабатываем новые протоколы, стараемся побыстрее добавить их поддержку в WIreshark. Поэтому мы не сомневаемся, что не станет исключением и kdbus, хотя прямо сейчас он выглядит не очень готовым к использованию.

Появление поддержки D-Bus в Wireshark было непростым делом. От так и не материализовавшейся идеи до ее реализации совершенно другими людьми прошло почти полтора года. Еще год ушел на добавление поддержки захвата сообщений D-Bus в libpcap (что интересно, dbus-dump, сторонняя утилита для создания таких pcap-файлов была написана участником коммьюнити openSUSE, Martin Vidner, ранее 2010 года). Хотелось бы верить, что с kdbus дела пойдут побыстрее, т.к. таскать с пару дюжин out-of-tree патчей и бэкпортить их туда-сюда, это не самое приятное времяпровождение.

Преобразование Fedora в RFRemix

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

Вопросы о том, как магическим образом превратить Fedora в RFRemix задавались довольно часто. И раньше тут было не мало проблем. По сути одного подключения репозиториев RPM Fusion и Russian Fedora было недостаточно, так как простое обновление системы разве что подправит обновлённые и исправленные пакеты из репозитория russianfedora-fixes, а кодеки и прочую "красоту" приходилось устанавливать вручную.

Однако теперь последние версии yum научились при обновлении системы обрабатывать группы (которые берут из comps-файла репозитория) и устанавливать пакеты (которых нет в системе), помеченные для обязательной установки. Так что теперь просто подключаете пять репозиториев (или по выбору): rpmfusion-free, rpmfusion-nonfree, russianfedora-free, russianfedora-nonfree, russianfedora-fixes и отдаёте команду yum update. Далее пример для Fedora 20. После подключения пакетов с настройками репозиториев Russian Fedora получаем следующее:

$ sudo yum update
Загружены модули: langpacks, refresh-packagekit
Разрешение зависимостей
...
Зависимости определены

==================================================================================================================================================================================
 Package                                           Архитектура             Версия                                              Репозиторий                                  Размер
==================================================================================================================================================================================
Installing for group upgrade "GNOME":
 NetworkManager-openswan                           x86_64                  0.9.8.0-1.fc20                                      fedora                                        93 k
 NetworkManager-ssh-gnome                          x86_64                  0.9.1-0.5.20130706git6bf4649.fc20                   fedora                                        37 k
 clipit                                            x86_64                  1.4.2-5.fc20                                        fedora                                        73 k
 dconf-editor                                      x86_64                  0.18.0-2.fc20                                       fedora                                       127 k
 gconf-editor                                      x86_64                  3.0.1-6.fc20                                        fedora                                       1.2 M
 gnome-tweak-tool                                  noarch                  3.10.1-2.fc20                                       fedora                                       201 k
 gstreamer-ffmpeg                                  x86_64                  0.10.13-10.fc20                                     rpmfusion-free                               2.9 M
 gstreamer-plugins-ugly                            x86_64                  0.10.19-14.fc20                                     rpmfusion-free                               316 k
 gstreamer1-libav                                  x86_64                  1.2.1-1.fc20                                        rpmfusion-free                               2.8 M
 gstreamer1-plugins-bad-freeworld                  x86_64                  1.2.1-2.fc20                                        rpmfusion-free-updates                       157 k
 gstreamer1-plugins-ugly                           x86_64                  1.2.1-1.fc20                                        rpmfusion-free                               245 k
 mailnag                                           noarch                  0.5.2-4.fc20                                        fedora                                       135 k
Installing for group upgrade "base-x":
 mesa-libGLU                                       x86_64                  9.0.0-4.fc20                                        updates                                      196 k
Installing for group upgrade "Аудио и видео":
 paman                                             x86_64                  0.9.4-11.fc20                                       fedora                                        85 k
 paprefs                                           x86_64                  0.9.10-5.fc20                                       fedora                                        68 k
 pavucontrol                                       x86_64                  2.0-4.fc20                                          fedora                                       139 k
 pavumeter                                         x86_64                  0.9.3-11.fc20                                       fedora                                        34 k
Installing for group upgrade "Веб-браузер Firefox":
 flash-plugin                                      x86_64                  7:11.2.202.310-1.R                                  russianfedora-nonfree                        5.5 M
Installing for group upgrade "Основные":
 workaround-cyrillic-console                       noarch                  1.0-5.fc20.R                                        russianfedora-free                           4.1 k
Installing for group upgrade "Стандартные":
 gpm                                               x86_64                  1.20.7-3.fc20                                       fedora                                       183 k
 mc                                                x86_64                  1:4.8.11-1.fc20                                     updates                                      1.8 M
 p7zip                                             x86_64                  9.20.1-6.fc20                                       fedora                                       616 k
Installing for group upgrade "Шрифты":
 ubuntu-font-family                                noarch                  5:0.69-2.R                                          russianfedora-free                           526 k
 ucs-miscfixed-fonts                               noarch                  0.3-11.fc20                                         fedora                                       466 k
Установка:
 aspell-ru                                         x86_64                  50:0.99f7-12.fc20                                   fedora                                       2.0 M
 rfremix-logos                                     x86_64                  21.0.1-1.fc20.R                                     russianfedora-fixes                          9.6 M
     замена  fedora-logos.x86_64 21.0.1-1.fc20
 rfremix-release                                   noarch                  2:20-1.R                                            russianfedora-fixes                           37 k
     замена  fedora-release.noarch 20-1
Обновление:
 anaconda                                          x86_64                  20.25.16-1.fc20.R                                   russianfedora-fixes-updates                  2.1 M
 anaconda-widgets                                  x86_64                  20.25.16-1.fc20.R                                   russianfedora-fixes-updates                  701 k
...
 xdotool                                           x86_64                  1:2.20110530.1-7.fc20                               fedora                                        46 k

Итого за операцию
==================================================================================================================================================================================
Установить  27 пакетов (+63 зависимых)
Обновить    24 пакета

Объем загрузки: 61 M
Is this ok [y/d/N]:

Как видно на примере yum, обновляя группу, хочет доставить некоторые новые пакеты в систему. "Возмущённые читатели" даже прислали по этому поводу баг. В принципе тут нужно подумать, как лучше избегать установку кому-то не нужных компонентов, но с другой стороны RFRemix для этого и придумывался.

Благодаря этой удачной особенности yum у нас появилось несколько путей развития RFRemix'а. Но о них в следующей статье.

Discoverable partitions в systemd

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

Lennart Poettering и его команда включили в systemd поддержку разработанного ими же расширения спецификации GPT, стандартизирующего уникальные GUID для характерных разделов Linux.

Идея в том, чтоб systemd распознавал GUID для таких разделов, как /, /home, /srv, swap и некоторых других, и монтировал их автоматически, без использования /etc/fstab. Использование fstab уже давно не требуется в системах с systemd, хотя порой прикладное ПО очень удивляется, если этого файла не существует, или он нулевого размера (мы периодически отсылаем патчи, когда обнаруживаем такие случаи). У нас уже работают системы, в которых /etc/fstab пуст (хотя еще и существует), так что это действительно работает. Пока /etc/fstab все еще обрабатывается, но рекомендуется постепенно переходить на systemd-юниты для разделов, если случай сложен, или на GPT, если простой.

Прекратите отключать selinux (и не принимайте советов от Valve)

Мы не раз предупреждали, что SELinux не "глючит", а блокирует реальные проблемы в приложениях, и отключать его не нужно. Если уж очень приспичило, то лучше переводить в режим permissive, но не отключать. Конечно, из-за ошибок в библиотеках бывает, что приложение при SELinux в режиме permissive ведет себя иначе, чем при полностью выключенном SELinux, но эти случаи нечасты, и наши коллеги их быстро поправят, если пользователи сообщат о подобной ситуации. Наш коллега, Elad Alfassa, обратил наше внимание на характерный багрепорт.

Пользователь сообщает в багтрекере Valve, что недавно выпущенная под Linux игра Portal 2 не работает, вываливаясь с ошибкой. Оказалось, что mp3-декодер в игре требует execheap (о вредности execheap в свое время писали вице-президент Goldman Sachs, бывший инженер Red Hat, Ulrich Drepper, и нынешний мэйнтейнер SELinux, Dan Walsh). Однако, вместо изучения ошибки, какой-то из инженеров Valve просто закрыл тикет, порекомендовав отключить SELinux. Выяснилось, что ситуация типична для Valve! Видимо изначальная ориентация на дистрибутив для начинающих, с искусственно заниженными стандартами (в т.ч. и по безопасности), привела к тому, что инженеры Valve порой просто не понимают, о чем речь!

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

Обратите внимание, в некоторых комментариях четко видно, что ряд инженеров Valve и помогавших им на начальных этапах, до перехода SteamOS на Debian, инженеров Canonical всерьез утверждали, что это "баг с SELinux", что характерно для начинающих пользователей Linux. И только недавно начало сквозить понимание, что это виноват не SELinux, а приложения (mp3-библиотека), которые просто дырявы (а SELinux просто это сообщает в простой и понятной манере).

Случай получился очень показательный. Тут и проприетарный быдлокод, для хоть какой-то работы которого надо отключать SELinux, и дремучее неприятие и недопонимание ситуации со стороны начинающих пользователей Linux и тех, кто в повседневной жизни пользуется дистрибутивами без SELinux (с искусственно заниженными требованиями безопасности). Но надо отметить и прозрачность и гласность процесса, что позволило быстро привлечь внимание к ситуации. Это, конечно, может стать очень сильной стороной Valve. Практика показывает, что широкое вовлечение участников коммьюнити поможет исправить и гораздо более тяжелые ситуации - вот почему мы, в отличие от других проектов, всячески рекомендуем и стимулируем наших коллег и товарищей принимать деятельное участие в жизни и нашего коммьюнити, и upstream-проектов.

Присоединяйтесь к нам и вы!

Upd. Завязалось интересное обсуждение ситуации с Valve и SELinux на Reddit.