Доступен для загрузки RFRemix 25, ремикс основанный на репозиториях Fedora, RPM Fusion и Russian Fedora. На этот раз RPM Fusion оправился от всех своих болячек и сделал все свои репозитории в срок. Fedora/RFRemix 25 - это первый релиз, в котором рабочий стол GNOME по-умолчанию использует Wayland. Одни говорят, что это хорошо, у других не всё так гладно, но начало положено.

%d0%b2%d1%8b%d0%b4%d0%b5%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5_024
Что у нас нового и старого
  • Для загрузки доступны две большие редакции RFRemix Server и Workstation (включая сетевые установки), а также Live-образы с различными рабочими столами;
  • Различные мультимедиа-кодеки, которых нет в оригинальной Fedora, а также Flash доступны из коробки;
  • Многие пакеты из репозиториев Russian Fedora доступны из приложения GNOME Software (Программы);
  • Так же у нас пересобран freetype с subpixel rendering;
  • Fontconfig содержит патчи Ubuntu для LCD мониторов (в общем сломали шрифты как всегда) и навсегда выкинули infinality, который не работал;
  • В образы Workstation (GNOME 3.22) по умолчанию для GNOME Shell (не для GTK) используется тема Korora из одноименного проекта. Также опционально добавлены темы Adapta и EvoPop для GTK и иконки EvoPop. Все отключается и включается в gnome-tweak-tool;
  • В репозитории содержится почти всевозможный набор мессенджеров: skype, viber, telegram-desktop. Также есть Chromium с pepper-flash, полный набор Opera и обычный flash-plugin.
  • Хромиум пересобран с поддержкой GTK3 и правильных кодеков;
  • Также мы обновили систему сборки. Теперь Live-образы максимально схожи с апстримовскими.

Как было сказано по умолчанию GNOME использует Wayland. Если вам такое поведение не подходит, то можно переключиться на Xorg в меню выбора сеанса.

Образы

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

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

Для обновления с предыдущих версий желательно сперва обновить текущую систему, а затем отдайте команду:

dnf --releasever=25 distro-sync --refresh --nogpgcheck

С сегодняшнего дня разрешено включение ПО для декодирования MP3. Про кодирование в MP3 ничего сказано еще не было.

Для загрузки доступен RFRemix 25 Beta. Всё как обычно, как и раньше. Для загрузки доступны Live-образы KDE, LXDE, XFCE, MATE, Cinnamon, а также Workstation версия с GNOME 3.22. Доступна Серверная редакция, образы сетевой установки и установочный DVD образ Workstation (не известно зачем, но в Fedora решили тоже его собирать).


25

RFRemix основан на репозиториях Fedora, RPM Fusion, который за полгода стал живее всех живых, вот что делает с проектами нормальная инфраструктура, и на репозиториях Russian Fedora. Fedora с каждым релизом становится всё лучше и лучше и всё меньше изменений требуется вносить в образы.

Основные отличия
  • Freetype пересобран с subpixel rendering.
  • Fontconfig содержит патчи Ubuntu для LCD мониторов (в общем сломали шрифты как всегда).
  • В образы Workstation по умолчанию для GNOME Shell (не для GTK) используется тема Korora из одноименного проекта. Также опционально добавлены темы Adapta и EvoPop для GTK и иконки EvoPop. Все отключается и включается в gnome-tweak-tool.
  • В репозитории содержится почти всевозможный набор мессенджеров: skype, viber, telegram-desktop. Также есть Chromium с pepper-flash, полный набор Opera и обычный flash-plugin.
  • Мы продолжаем провайдить Chromium, так как тот что в репозитории Fedora очень плохо работает с видео.
  • Telegram теперь собирается из исходников.
Куда сходить спросить, пожаловаться Обновление

Для обновления с предыдущих версий RFRemix нужно сперва полностью обновить текущую систему, а затем отдайте команду:

dnf --releasever=25 distro-sync --nogpgcheck

Релиз RFRemix 25 намечен на 15 ноября одновременно с релизом Fedora.

Вышел Qemu 2.7.0. Официальный список изменений поражает еще меньше, чем в версии 2.6.0, но можно отметить ускорения в блочной и сетевой подсистеме.


Доска почета - корпоративные разработчики этой версии

Вслед за выходом "ванильного" OpenStack Mitaka, тринадцатой версии OpenStack, начали выходить и дистрибутивы от вендоров. Сначала вышел Mirantis OpenStack 9.0, а через пару месяцев вышел и Red Hat OpenStack 9.0. Изменений много, но ошеломляющие найти непросто, что и неудивительно от ПО, чья цель, это просто запускать процессы на кластере прозрачно для оператора. Основная масса изменений в версиях ПО, используемого в составе дистрибутива.

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

Большие изменения еще грядут. Пока OpenStack все еще использует виртуалки, а что-то подсказывает, что будет переход на контейнеры. Это чувствуют и в Docker Inc, которые видимо сразу после Red Hat Summit поехали на VMworld 2016. Там ни с кем не ссорились.

Появилась статья, объясняющая почему dnf, это самостоятельное ПО, не являющееся форком Yum. На самом деле, конечно, являющееся, но когда это было?

Главное отличие, это то, как dnf вычисляет зависимости. Разработчики не стали сами лезть в математику, а взяли готовый солвер, обкатанный нашими коллегами из openSUSE. Как результат, получилось лучше и гораздо быстрее. Обратная сторона, это то, что полностью поведение Yum повторить не получится - тот высчитывал зависимости иначе. Высчитывал медленно, криво и косо, так что даже пытаться воспроизвести его поведение, это просто глупо. Ну и про полную поддержку Python 3 в dnf тоже стоит упомянуть. К сожалению, полной поддержки Python 3 в утилитах для мэйнтейнера (сборка RPM, добавление в репозитории Fedora и т.п.) пока нет - ждем.

Интересно, что в последнее время вокруг RPM и сопутствующих инструментов и утилит возникло оживление. Для начала Mageia объявили, что будут поставлять dnf в параллель с их самобытным urpmi. А недавно мы узнали, что оказывается AltLinux уже с лета переходит на RPM из rpm.org вместо использования своего форка. Это все, разумеется, очень правильно - больше стандартизации, это хорошо для инженеров. Искренне рекомендуем ребятам обдумать переход на DNF!

Инициативе по переносу Wayland на Android уже несколько лет, но похоже, что результаты можно ожидать уже совсем скоро.

На приближающейся конференции X.Org Developer's Conference 2016, которая состоится 21-23 сентября в Хельсинки, запланирован любопытный доклад инженера Google, David Reveman - ARC++ (ARC, это сокращение от "Android Runtime for Chrome"). В докладе будет рассказано о том, как функционирует подсистема ARC для запуска ПО из Google Play Store на ChromeOS. Оказывается, для этого используется протокол Wayland. Напомним, инженеры Intel уже экспериментируют с systemd на ChromeOS. Похоже, что в 2017-2018 году нас ждут интересные новости.

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

Justin Azoff, безопасник из National Center for Supercomputing Applications, также решил рассказать киборгам-любителям читать логи глазами про объективные недостатки syslog.

Я ненавижу syslog.

Протокол ужасен.
Формат сообщений ужасен.
API ужасен.

Протокол

Документ с RFC по syslog был обновлен в 2009 году. Несмотря на то, что этот документ - недавний, это лишь формализация текущих реализаций syslog и содержит много лишнего из 1980х. Есть альтернативы, но ничего стандартизированного. Большинство встраиваемых устройств или готовых систем поддерживают лишь минимум функционала.

"Facilities"

Заголовок сообщения syslog содержит несколько байто зарезервированных для обозначения источника сообщения. До сих пор ююкаете? В протоколе syslog оно поддерживается! Используете что-нибудь посовременнее 1985 года? Отказать!

Жестко определены следующие "facilities":

Код    "Facility"
   0    kernel messages
   1    user-level messages
   2    mail system
   3    system daemons
   4    security/authorization messages
   5    messages generated internally by syslogd
   6    line printer subsystem
   7    network news subsystem
   8    UUCP subsystem
   9    clock daemon
  10    security/authorization messages
  11    FTP daemon
  12    NTP subsystem
  13    log audit
  14    log alert
  15    clock daemon (note 2)
  16    local use 0  (local0)
  17    local use 1  (local1)
  18    local use 2  (local2)
  19    local use 3  (local3)
  20    local use 4  (local4)
  21    local use 5  (local5)
  22    local use 6  (local6)
  23    local use 7  (local7)

Значения "facility" ДОЛЖНЫ быть из диапазона от 0 до 23 включительно.

У большинства из 24 значений "facilitiy" также есть короткое слово, ассоциированное со значением: kern, user, mail, auth, news, ftp, и так далее. Вместо того, чтобы просто использовать 4 байта, чтобы обозначить почту, как ‘mail’, его впихивают вместе со значением приоритета сообщения ("priority") в 2 байта. А после того, как сэкономили пару байтов, эти два байта записывают в кавычки - <>.

Вместо кодирования сообщения от NTP с приоритетом 7 пятью байтами ("7 ntp"), его кодируют в 5 байт, как "<103>".

Почему это число заключено в скобки, а все остальное нет?

Brackets

Получается так, что поле "facility" полностью бесполезно в современных системах. Скорее всего, если вы получаете syslog-сообщения от приложения, то их всех пошлют, как local0.

(не)Надежная доставка

У большинства реализаций syslog есть пара опций доставки:

Ни один из этих вариантов не отвечает за потерянные сообщения:

Протокол syslog не предоставляет подтверждения от доставке сообщений. Хотя некоторые транспортные протоколы могут предоставлять результат доставки, концептуально, syslog, это чисто симплексный протокол коммуникации.

Как то раз я мониторил около тысячи свитчей. Одна из наиболее разъярявших меня проблем с syslog была такой - если порт аплинка мигнул, вы не получите никакого сообщения об этом событии. В большинстве случаев однокилобайтного буфера хватило бы для гарантированной доставки всех сообщений.

Некоторые реализации syslog предоставляют надежную доставку, включая буферизацию сообщений, когда сервер недоступен.

(не)Структурированные данные

RFC5424 добавляет поддержку структурированных данных используя формат key="value" обрамленный скобками. Выглядит примерно так:

... [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

Это довольно хорошая спецификация, хотя в ней не указано, как журналировать типизованные данные (int, bool), и нет поддержки иерархических структур, таких, как списки.

Возьмем гипотетическое сообщение от SMTP:

{from:"a@example.com", bytes:12345, to:["b@example.com", "c@example.com"], spam: false, status:"queued"}

Довольно легко его представить, как JSON, а в RFC5424 эквивалента нет.

К сожалению, это неважно, что в syslog поддержка структурированных данных ограничена, так как подавляющее большинство ПО все равно не поддерживает журналирование в таком формате.

ПО продолжает использовать неструктурированное ‘printf’-подобное журналирование. Это явление я называю ‘lossy serialization’.

Мой любимый пример ‘lossy serialization’, это sshd. sshd делает так, когда записывает результат аутентификации:

authlog("%s %s%s%s for %s%.100s from %.200s port %d ssh2%s%s",
    authmsg,
    method,
    submethod != NULL ? "/" : "", submethod == NULL ? "" : submethod,
    authctxt->valid ? "" : "invalid user ",
    authctxt->user,
    ssh_remote_ipaddr(ssh),
    ssh_remote_port(ssh),
    authctxt->info != NULL ? ": " : "",
    authctxt->info != NULL ? authctxt->info : "");

authlog это обертка, которая вызывает syslog().

Этот кусок кода генерирует примерно такие сообщения:

Failed password for root from 192.168.50.65 port 34780 ssh2

Много человеко-лет было потрачено в попытках распарсить такие сообщения. Зачастую, эти попытки оканчивались ошибками и проблемами с безопасностью.

Обратите внимание, что вызов authlog ничего не экранирует или кодирует. Попробуйте авторизоваться с таким именем пользователя - root from 8.8.8.8:

$ ssh 'root from 8.8.8.8'@localhost

А теперь проверьте syslog:

Sep  3 15:25:49 box sshd[23076]: Failed password for invalid user root from 8.8.8.8 from 127.0.0.1 port 54460 ssh2

Если вы распарсите это сообщение неверно, то окажется, что кто-то с адреса 8.8.8.8 попытался залогиниться рутом:

Failed password for invalid user root from 8.8.8.8

Внутри sshd, переменная ssh_remote_ipaddr(ssh), содержит изолированное значение адреса удаленного хоста, но как только его запишут в текстовый журнал, оно теряется внутри сообщения. Если бы sshd (и любой другой демон, которому нужно журналировать структурированные данные) использовал бы API, аналогичный указанному ниже, можно было бы однозначно десериализовать данные обратно, вместо той одностронней сериализации, что у нас сейчас есть.

authlog("msg", authmsg,
        "method", method,
        "submethod", submethod,
        "valid", authctxt->valid,
        "user", authctxt->user,
        "remote_ip", ssh_remote_ipaddr(ssh),
        "remote_port", ssh_remote_port(ssh),
        "protocol", "ssh2",
        "info", authctxt->info)

И это можно было бы записать в журнал следующим образом:

[msg="failed" method="password" valid="t", user="root" remote_ip="192.168.50.65" remote_port="34780" protocol="ssh2" info=""]

А сообщение с адресом внутри имени пользователя выглядело бы так::

[msg="failed" method="password" valid="f", user="root from 8.8.8.8" remote_ip="127.0.0.1" remote_port="54460" protocol="ssh2" info=""]

API ужасен.

API syslog очень прост:

void syslog(int priority, const char *format, ...);

Как журналировать структурированные данные, и правильно их экранировать? Думайте сами, удачи! Может быть этот функционал стоит включить в libc? НИКОГДА!.

TL;DR

  • У вас скорее всего не получится надежно журналировать на удаленный сервер.
  • Если вы не уверены, что произойдет, если ваш syslog-сервер упадет, СРОЧНО проверьте.
  • А в полученных сообщениях у вас будут проблемы с их обработкой (получением данных, нужных для бизнес-процесса).

Насчет бинарных логов

Популярно мнение, что бинарные логи, это зло, и единственный способ вести системный журнал, это текстовые файлы.

Мне лично все равно - текстовые или бинарные логи. Однако, если вы пытаетесь убедить окружающих не использовать бинарные логи, потому что они "не читаются глазами" и могут быть легко повреждены, то вам следует обратить внимание на то, как устроена ротация логов на вашей машине. Ну просто, если после ротации ваши логи сжимаются чем-то вроде gzip, то у вас уже нет текстовичков.



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

Похоже, что история GCJ (GNU Compiler for Java) подходит к завершению. Наш коллега, инженер Red Hat, Andrew Haley, предложил окончательно удалить GCJ из GCC. Им уже считай никто не пользуется, он застрял на уровне Java 1.5, его теоретически можно использовать для бутстрапа OpenJDK, но уже давно никто это не пробовал проверить.

Вообще, с одной стороны жалко что юниксвэйное количество Java-компиляторов и VM сокращается дo OpenJDK, в котором сейчас все и происходит, и на который перелезает даже Android с ранее выбранного по юридическим причинам Apache Harmony (напомним, что Apache, это кладбище проектов, где они медленно умирают, и продолжать разработку и как-то использовать проекты Apache, это кощунство сродни осквернению могил). С другой, мы, как инженеры, всячески приветствуем стандартизацию:

«...Нет в мно­го­вла­с­тии бла­га; да будет еди­ный вла­с­ти­тель,
Царь нам да будет еди­ный, кото­ро­му Зевс про­зор­ли­вый
Скиптр даро­вал и зако­ны: да цар­с­тву­ет он над дру­ги­ми».


Насчет Apache Harmony и Android. Вы наверное слышали про "веганов" от опенсорса, людей, которые всерьез считают BSD по-настоящему свободной ОС, в отличие от несвободного линукса под GPL? Они-то сами лично используют на десктопе проприетарные Windows или Mac OS X, т.к. BSD на десктопе просто нельзя пользоваться, а Linux с их точки зрения недостаточно свободен, не юниксвэй (в отличие от проприетарных Windows и Mac OS X). Но главное это то, что они регулярно утверждали, что невирусные разрешительные лицензии (MIT, BSD, Apache) для пользователя и производителя лучше. Так вот, теперь можно посылать их в Google, которые смачно огребли от Oracle именно из-за того, что выбрали не OpenJDK, проект под GPL, а Apache Harmony, проект под лицензией Apache, которая никому ничего не обещает и не гарантирует. Если же говорить серьезно, то очевидно, что причиной проблем Google был не неправильный выбор лицензии, а осквернение старого индейского кладбища Apache Software Foundation, с которого они выкопали Apache Harmony и потащили в продакшен. Это не могло окончиться хорошо.

На фото наш товарищ, Glauber Costa (Lord Glauber of Sealand), на Scylla Summit 2016:

Страницы