Известный гентушник и дистрохоппер Greg KH с первого декабря устраивает IAmA-сессию на Reddit. Можно будет спросить почему он до сих пор не перешел на Fedora.


На фото Greg KH с друзьями планируют какой следующий дистрибутив нужно перевести на systemd

Оказалось, что видеозапись выступления Lennart Poettering на NLUUG Najaarsconferentie 2014 существует! Как подметил Alexander Patrakov, довольно пугающе то, что выступающий не знает записывают ли его или нет.



УПД голландцы не осилили выложить правильно видеозапись - вот прямая ссылка.

Ситуация с корневыми сертификатами для HTTPS настолько плоха, что даже непонятно, с чего начинать. Ну, например, посмотрите этот кусок из выступления Poul-Henning Kamp на FOSDEM 2014:



Наши коллеги присутствовали на этом выступлении, и мы хорошо помним, как зал умолк, когда народ понял главный посыл этого фрагмента выступления phk.

В каждой системе, в каждом браузере по умолчанию присутствует список сертификатов, которыми подписываются другие сертификаты. Кем и когда создавался этот список неизвестно, и это не шутка! Среди корневых удостоверяющих сертификатов действительно есть выпущенные неизвестно кем, и добавленные неизвестно как (привет тем проектам, что не перешли на Git). Еще там есть сертификаты, выпущенные государственными организациями стран, известных гонениями на инакомыслящих (мы не имеем в виду США - после Сноудэна с ними все и так понятно). Можете посмотреть сами - наберите в адресной строке браузера about:preferences#advanced, и там выберите вкладку Certificates -> View Certificates -> Authorities и поизучайте содержимое. Что это за сертификаты, почему они тут, зачем нам им доверять - никто не скажет. Однако ими подписываются сертификаты популярных веб-сервисов, и это, типа, очень безопасно, а вот самоподписанные сертификаты, это, мол, наоборот страшная угроза безопасности.

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

Недавно Mozilla начала удаление из своего набора корневых сертификатов, содержащих слабые ключи. Шаг очень правильный, тут никто не спорит. Но наши коллеги из Red Hat немного потестировали, и выяснили, что несмотря на совместимость с NSS, новый набор сертификатов вызывает проблемы у OpenSSL и некоторых версий GnuTLS. Сказалась изоляция разработчиков разных криптобиблиотек друг от друга. Поэтому мэйнтейнеру пакета ca-certificates пришлось пойти на неоднозначное решение - откатить изменения Mozilla, чтобы работали OpenSSL и GnuTLS, и добавить в пакет специальную утилиту для включения/отключения сертификатов со слабыми ключами. Понятно, что это серьезно влияет на безопасность соединений, но иначе OpenSSL вообще не будет работать со цепочками сертификатов, затронутых удалением. Он завел специальную страницу в Wiki, где будут описаны тонкости пакета с сертификатами - посматривайте туда.

Но есть и хорошие новости - в условиях совершенного бардака с криптобиблиотеками, всегда есть возможность разработчику проявить себя, в т.ч. и с пользой для бюджета. Мы поздавляем Paul Bakker с покупкой ARM Ltd. его проекта, PolarSSL!

Jim Meyering выпустил grep версии 2.21. Обращаем внимание, что хотя Jim говорит, что это релиз, ускоряющий работу, версия у него нечетная. Это значит, что завтра Jim запросто может выпустить экстренный багфикс-релиз.

Хотя многие наши коллеги имеют более десятка-полутора-двух лет опыта работы с Linux и Open Source, еще полно моментов, которые мы понимаем неполностью. Этого мы никогда не стеснялись, не стесняемся и не будем стесняться - учиться никогда не поздно, и всегда приятно и полезно. Вот тут приключилась интересная история, разборки с которой пролили свет на еще один темный уголок Unix-архитектуры. Мы, как и некоторые другие люди, не понимали, почему если процесс запущен не от суперпользователя, то он не может сбросить себе некоторые привилегии - например, группы. Понятно, почему нельзя назначить себе группы, но отказаться-то почему нельзя? Сходу понять это не получается. Josh Triplett решил, что это ошибка, и прислал патч, исправляющий это поведение. В обсуждении оказалось, что Josh, как и мы, просто был не в курсе типичного use case, популярного среди матерых Unix-админов, который проще показать, чем объяснять. Можно создать группу restricted_group_name и добавить туда пользователей. А затем выставить на каталог права доступа 705, а затем сменить владельца вот так - chmod root:restricted_group_name /path/to/restricted_dir. И теперь каталог /path/to/restricted_dir будет доступен всем, кроме тех, кто находится в группе restricted_group_name. А если они смогут сбрасывать группы, то смогут достучаться до содержимого каталога. Вот так.

Кстати, у Josh есть и другие интересные патчи - например, позволяющий процессу иметь несколько UID.

Сдвинулось с мертвой точки портирование Go на неподдерживаемые Google платформы. Во-первых в GCC включают поддержку Go на s390x. Во-вторых представили первый вариант фронтэнда Go для LLVM. Вообще Google очень разумно ограничил язык лишь рядом процессорных архитектур и рядом операционных систем, радикально сократив матрицу тестирования. Тем, кому надо, они предлагают самим реализовывать функционал, и догонять уезжающий поезд, причем строго отдельно, чтоб не мешать лететь. А вот в Opensource-коммьюнити до сих пор местами крикливые меньшинства сдерживают движение вперед большинства.

Дмитрий Монахов, попавший в КПЗ из-за своей политической позиции, откинулся и теперь авторитетный программист в Parallels благополучно вернулся к работе. Мы уже видим его в деле, например, в обсуждении интересного патчсета от Theodore Tso - lazytime, замена relatime. Немного истории - в Unix есть три типа таймстемпов у файлов и директорий, ctime (время изменения файла или его метаданных), mtime (время изменения файла) и самый бесполезный в быту, но самый ресурсоемкий - atime (время последнего доступа к файлу, например его чтения без изменения содержания). Если нам бывает часто интересно, когда последний раз изменено содержимое файла или его права доступа, то когда последний раз производилось чтение - не так важно (хотя многие почтовые клиенты всерьез работали именно так, учитывая atime). Некоторые с незапамятных времен добавляют в опции монтирования noatime, хотя, как говорят, сейчас достаточно добавить relatime, чтоб почти всегда это работало хорошо. Однако, Theodore поразмыслил, и решил, что можно улучшить еще, не нарушая замшелый стандарт POSIX, который требует работы именно atime, не noatime, relatime или чего еще. Он предложил накапливать изменения atime в памяти, и сбрасывать на диск лишь когда кончается память, либо когда происходят какие-либо иные события, требующие обновления atime. Звучит неплохо, и говорят, что примерно так было уже давным давно реализовано в Solaris. К сожалению, Theodore реализовал функционал лишь для ext4. Наш коллега, инженер Red Hat, Dave Chinner, справедливо посчитал, что это не лучший архитектурный вариант, и предложил реализовать ее на уровне выше, на VFS, что автоматически (ну или почти автоматически) добавит эту функциональность во все файловые системы. Посмотрим, что из этого получится.

В интервью с кандидатами в Fedora Council им задавался вопрос - "в чем состоит успешность нашего проекта и как ее измерить?" Некоторые отметили, что не в количестве пользователей или участников, а в способности убеждать других в правоте выбранных нами архитектурных решений. Ну раз так, то у нас еще две победы. Во-1 инженер Google, Russell Hancox, разработал santa - с нашей точки зрения, это выглядит, как SELinux для Mac OS X, хотя почитав реализацию мы бы порекомендовали автору не мучаться, а портировать SELinux, как есть. Конечно, лицензия не та, но что же остается делать остающим? А во-2 отстающие наконец-то сообразили, что отстают, и это очень здорово! В течении следующих десяти лет FreeBSD собирается переходить на launchd. Для нас это не новость, разумеется. Срок, конечно, удивительный, но по-другому не получится - ни у одного из всех пяти разработчиков FreeBSD нет свободного времени. Им бы, конечно, не мучаться, а взять systemd, но верующие в BSD считают GPL несвободной, и поэтому копировать решение будут из проприетарной Mac OS X - таково понимание свободы у любителей Windows и Putty. В ленте Google+ у Lennart Poettering уже с удовольствием обсуждают новость.

Ну и напоследок грустная новость, никак не связанная с Fedora - в Google полностью отказываются от OpenID. Еще один открытый стандарт медленно бредет на свалку истории.

С 18го по 26 ноября будут проведены выборы в Fedora Council, и мы призываем всех участников проекта Fedora прийти и проголосовать. На два места претендуют пять человек, и их уже проинтервьюировали:



Все на выборы!

Когда речь идет про low level API, то как правило говорят про Glibc. Но на самом деле библиотека просто отдает наверх то, что выдается ей ядром системы. Есть такой механизм, syscalls, и Glibc оборачивает функции ядра просто вызовом syscall, например, чтобы реализовать функцию ssize_t read(int fd, void* buf, size_t len) это делается примерно вот так:

nread = syscall(SYS_read, fd, buf, len);



Вместо использования оберток Glibc можно дергать эти функции самому напрямую из ядра с помощью syscall, хотя почти всегда это нецелесообразно - ведь Glibc не просто оборачивает их, но и выполняет много других проверок (корректность аргументов, 32/64-битность и прочее). Но порой приходится, т.к. обертки в Glibc просто нет. Ядро Linux предоставляет огромное количество функций, и далеко не все из них имеют аналоги в API Glibc. Возникает вопрос, а почему какие-то функции экспортированы, а какие-то нет?

Раньше, когда Glibc управлял Ulrich "Stop Reopening" Drepper, он и решал - эту функцию включаем, а эту нет. После его ухода из Red Hat на заработки к финансовым спекулянтам в Goldman Sachs, когда процесс разработки Glibc упорядочился и оздоровился, народ начал обсуждать, а каковы могут быть формальные критерии для создания обертки для функции из ядра?

Одной из проблем является мало кому нужная кроссплатформенность Glibc. Дело в том, что несмотря на то, что в несовместимых между собой операционных системах семейства BSD, проприетарных Unix-системах, и т.п. используется свой аналог Libc, разработчики Glibc с непонятным упорством пытаются обеспечить кроссплатформенность библиотеки - спроса на это практически никакого, но работа ведется. Практика показывает, что кроссплатформенный аналог всегда проигрывает нативному, т.к. вынужден опираться на общее подмножество функционала всех систем, на которых он работает. Поэтому в коде будет полно кусков, облепленных ifdef, в которых по каждой ветке будут неисправленные ошибки, уже давно отсутствующие в других ветках. Хочется добавлять интересный Linux-функционал, но это сразу будет уводить Glibc от его сборок для альтернативных ядер. И даже когда функционал добавляется, его не используют в userspace, т.к. люди боятся обидеть шумных представителей меньшинств с нетрадиционными системами, которые запросто могут начать собирать на киллера. Поэтому Linux-специфичный API повисает мертвым грузом с одним или двумя пользователями, потому что любители юниксвэя закричат любую попытку его использования в популярных приложениях. Однако и здесь в обществе уже начало брезжить понимание, например Debian начал робко отказываться от комбинаций userspace и ядер, которые сдерживают его развитие, хотя до полного отказа от поддержки альтернативных игрушечных систем еще очень далеко.

Обсуждая невостребованную кроссплатформенность Glibc и аналоги в несовместимых между собой вариантах BSD нельзя не упомянуть религиозную суть вопроса. Мы ее не будем раскрывать, т.к. боимся ненависти со стороны фанатиков, и просто предложим подумать, о том, насколько может быть конструктивна техническая дискуссия с людьми, приписывающими везде GNU к названию ядра дистрибутива и ходящими босиком, или с людьми, переписывающими утилиты ls и cp, т.к. им показалось, что лицензия недостаточно открытая.

Так или иначе, но несмотря на все проблемы, интересный Linux-специфичный функционал в Glibc продолжал появляться все время, и обсуждение того, как бы формализовать его появление тоже шло. Все сдвинулось с мертвой точки в конце 2012 - начале 2013 года, когда гентушник Mike Frysinger выписал доводы за и против включения дополнительного API ядра в Glibc. Тогда результата не получилось, т.к. вопрос серьезный и всплыло много нюансов - дополнительная библиотека liblinux, как поступать на "стабильных" и "сертифицированных" (т.е. замороженных, старых и глючных) дистрибутивах, как поддерживать альтернативные архитектуры (а почему бы и никак не поддерживать и их?) и много чего еще.

Недавнее включение (обновление) поддержки futex в Glibc вновь плавно привело к идее формального описания критериев для добавления Linux-специфичного API . На этот раз дело дошло до документации. В целом народ согласен с документом - пора бы начать добавлять API из Linux без оглядки на совместимость с каким-нибудь TruOpenUnixWorks. Из забавного, появление и обсуждение этого RFC затормозило включение в Glibc функционала для поддержки kdbus.


Наш товарищ, убунтовод Carlo Piana, спешит в Европарламент обсуждать открытые стандарты

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

Очередной чиновник из правительства грозится запретить GitHub в России, если те не выполнят его требования. Новость уже обсуждают коллеги-аналитики. Причин цивилизованным людям из GitHub выполнять хотелки бесноватого дикаря, недавно слезшего с нефтяной вышки, сходу не видно - не идут же они на поводу религиозных фундаменталистов из ряда стран третьего мира (но надо отметить, что на поводу у своих фундаменталистов они идут). А значит, рано или поздно российский чиновник, неважно какой, запретит GitHub, да и, наверняка, не только его. Поэтому надо готовиться.

Мы не будем касаться вопросов восстановления доступа к веб-интерфейсу GitHub. Для этого в интернете есть полно решений разной степени сложности. Например, некоторые наши коллеги, для обхода цензуры Единой России, используют комбинацию HTTP-прокси и Firefox с плагином FoxyProxy. Это же решение хорошо подходит и для работы в сети Tor. А вот каких хаутушек в интернете мало, так это как использовать Git через третий узел, находящийся под вашим контролем.

Если у вас есть IPv6, то вы уже можете воспользоваться работающим Git-SSH-прокси по адресу ikvjwd.com. Просто вместо GitHub.com используйте его домен, например:

git clone git@ikvjwd.com:RussianFedora/russianfedora-free-release.git



Необходимо отметить, что т.к. у вас лично нет причин доверять владельцам ikvjwd, то обязательно проверяйте SSH-отпечаток. Таким образом вы сумеете восстановить уничтоженный Единой Россией доступ к нужному нам всем сайту, и очень дешево. Если по каким-то причинам вам готовое решение не подходит, то разверните свой прокси на компьютере, находящемся за пределами РФ. Кстати, за основу можете взять вариант от ikvjwd, владельцы которого выложили конфиг к haproxy, которым вы можете воспользоваться. Сам haproxy доступен в репозиториях Fedora. Но, конечно, можно настроить и туннель, используя SSH. Для чего сначала нужно запустить туннель через ваш ProxyServer.example.com, на котором у вас есть SSH-аккаунт, и который находится в одной из более цивилизованных стран, например страны ЕС, Белоруссия или Украина:

ssh ProxyServer.example.com -L 3333:github.com:22 -N



Это запустит переадресацию вашего локального порта 3333 через ProxyServer.example.com на github.com:22. Затем, в другой консоли, клонируйте ваш репозиторий (или поменяйте адрес в .git/config, если уже клонировали):

git clone ssh://git@localhost:3333/RussianFedora/russianfedora-free-release.git



Если вы клонируете репозиторий по Git-протоколу, то вместо порта 22 нужно пробросить порт 9418. Строка для клонирования будет выглядеть вот так:

git clone git://localhost:3333/RussianFedora/russianfedora-free-release.git



GitHub, это один из наших основных рабочих инструментов, и когда Единая Россия его запретит, то мы обязательно поднимем на своих мощностях Git-прокси на него - таким или каким-либо иным способом. Вообще, очень печально, что такой сайт для современной модной молодежи, как GitHub, ни по IPv6 недоступен, ни в Tor не виден. А вот тот же Facebook доступен и в Tor, и по IPv6 (см. host -t aaaa facebook.com). Напоминаем, что мы-то доступны в сети Tor. Его закрыть у Единой России получится лишь физически изолировав рунет от интернета, что им будет реализовать непросто, хотя и возможно.

Но есть и хорошие новости - решили не вводить налог на программистов в пользу патриотов.

Lennart Poettering выложил слайды со своего выступления на NLUUG Najaarsconferentie 2014, где он рассказывал о фичах безопасности в systemd. Видеозапись выступления никто не сделал.

К сожалению, в RHEL 7 и пересборки включен относительно старый systemd версии 208. В нем нет ни пользовательских сессий, ни управления сетью, и много чего еще. Для тех, кто хочет воспользоваться всем этим, наш коллега Lukáš Nykrýn подготовил экспериментальную сборку самого свежего systemd, прямо из Fedora Rawhide. Конечно, никаких гарантий не предоставляется, но мы уже пробуем.

Продолжается процесс включения kdbus в ядро. Greg KH представил второй вариант патчсета. Из заметного, помимо попытки исправить недостатки, замеченные ранее, отметим появление специализированной файловой системы kdbusfs, которая будет монтироваться в /sys/fs/kdbus.

Наш коллега, Miroslav Lichvar , работает над интересным проектом - timedatex. Это сервис управления системными часами, управляемый через D-Bus, и, что самое интересное, являющийся аналогом systemd-timedated, но не требующий никаких библиотек systemd.

Flannel (ранее Rudder), еще один вариант управления сетью, использующий etcd и systemd (systemd-notify для надежного управления сервисом), наконец-то включают в Fedora. Похоже, что SDN, это уже не будущая, а нынешняя горячая тема.

Сегодня, больше 150 мэйнтейнеров Fedora получили уведомление об открытой заявке в Bugzilla. В ней описывалась дыра в безопасности в одной из популярных JavaScript-библиотек, jQuery. Из-за этой дыры, и из-за того, что jQuery приложена в виде bundled lib во множестве приложений, всем этим мэйнтейнерам придется заняться пересборкой пакетов с исправлением.

Когда говорят о bundled libs, и проблемах, которые они вызывают, то обычно имеют в виду вкомпилированные прямо в приложения исходники библиотек. Среди известных нарушителей можно назвать кросс-платформенные приложения, порой вынужденные ради простоты сборки на проприетарных платформах учитывать бедность их репозитариев. Но на самом деле, именно с этими приложениями мы в целом вопрос решили, и остаются считанные десятки случаев, а теперь у нас основные проблемы с bundled libs вызывают массово копируемые JS-исходники.

Неряшливый подход некоторых frontend-программистов переносится ими на системный уровень. Когда им надо использовать JS-библиотеку, то они ее бросают в исходники, и либо забывают навсегда (отчего в ней заводятся баги), либо безоглядно форкают (отчего она далеко уплывает от оригинала, патчить ее становится сложно, и в ней тоже заводятся баги). Мы попробовали было начать выносить хотя бы jQuery из пакетов, требуя использовать system-wide копию, и даже запланировали было это фичей Fedora 21, но обстоятельства оказались сильнее нас, и фичу перенесли на Fedora 22.

А так ли и надо выносить JS-модули в system-wide пакеты? Конечно, можно и не выносить, но тогда, как сейчас, вместо того, чтобы патчить один пакет силами одного мэйнтейнера, придется патчить целую кучу пакетов силами 156 мэйнтейнеров. К счастью, в апстриме уже начали исправлять проблему, например в CouchDB уже поправили.

Страницы