Опубликовано 27.10.2014 17:17 пользователем Peter Lemenkov
HP неспроста повысило свой уровень участия в OpenStack. Они, вслед за другими ведущими игроками облачных технологий, предложили свой вариант для развертывания облака - HP Helion OpenStack. Пока доступна лишь Community Edition, но вскоре можно ожидать и платный вариант. Мы уже рассказывали про HP Helion ранее, но теперь, после доходящих до нас слухов о том, что Debian Community негласно управляется из HP, становится понятно, почему Debian стремительно переходит на systemd невзирая на стоны любителей юниксвэя.

Бразильский мачо и инженер Red Hat, Lucas Meneghel Rodrigues, разрабатывавший систему тестирования виртуализированных систем Autotest (напомню, мы никогда не недооценивали важность тестирования), начал разработку нового поколения системы тестирования - Avocado. Ознакомьтесь со слайдами с презентации этого проекта. И, конечно, и autotest, и avocado уже доступны в Copr-репозитории на попробовать.

Вышло новое интервью с Julien Danjou, разработчиком Awesome и OpenStack.

Matthew Garrett прокомментировал доклад Jérôme Petazzoni о безопасности в контейнерах (внимание, Garrett ведет свой блог на частично запрещенном в РФ хостинге, так что используйте варианты обхода государственной цензуры в РФ, чтобы ознакомиться с его постами). Напомним, Dan Walsh тоже выступал с докладом о безопасности в контейнерах. Также напомним, что Jérôme Petazzoni выступает 29 октября в Москве на митапе про Docker и контейнерную виртуализацию.

Iron.io рассказывает о своем опыте запуска 300.000.000 Docker-контейнеров. Из результатов особо отметим, что они видят большой потенциал в связке CoreOS + Docker.

Brandon Phillips, основатель CoreOS, недавно выступал на LinuxCon Europe 2014 с докладом о etcd и fleet. Про etcd он уже рассказывал, и интересно посмотреть, чего с тех пор появилось нового.

И последняя печальная новость, не совсем про облака - представитель компании ownCloud потребовал от Canonical удалить устаревшую и глючную версию одноименного пакета из их репозитория. Мы всегда говорили, что меряться надо не размерами репозиториев, а какой-то иной метрикой, например количеством активных мэйнтейнеров или количеством изменений в единицу времени. Большое количество пакетов, и небольшое количество активных мэйнтейнеров, это означает лишь то, что значительную массу этих пакетов составляет глючное и устаревшее ПО, в т.ч. с дырами безопасности. У нас порядка тысячи-полутора мэйнтейнеров, сопровождающих около 10-15 тысяч пакетов, и это очень малое количество рабочих рук. Не вдаваясь в подробности скажем, что если один мэйнтейнер приходится на несколько сотен или даже тысяч пакетов, и утверждается, что качество пакетной базы дистрибутива высокое, то это заведомый (само)обман.

Опубликовано 27.10.2014 16:03 пользователем Peter Lemenkov
Радостная новость для наших коллег, работающих в Kolab Systems - их флагманский коммерческий продукт, Kolab Enterprise стал официально доступен в Red Hat Enterprise Product Directory. У компании уже есть ряд крупных инсталляций, например, городские службы Мюнхена и школы Базеля, но с официальной сертификацией от Red Hat их будет еще больше, и это, разумеется, увеличит доходы компании.

Kolab сейчас, после известных всем скандалов с незаконным доступом американских спецслужб к вашей личной информации, на слуху. Они удачно расположены в стране с прямой демократией, что сформировало серьезное отношение к правам личности, и это позволяет местным компаниям предлагать более защищенные от несанкционированного доступа варианты хостинга. На недавно прошедшем LinuxCon Europe 2014 с докладом выступил CEO Kolab Systems, Georg Greve.



К сожалению, пока нет видеозаписи его выступления, а выложенные слайды неособо проливают свет на содержимое доклада. Тем не менее, на LWN.net уже обсуждают его выступление, и из обсуждения можно понять, что Georg указал на три потенциальных источника проблем - госструктуры, коммерческие компании (промышленный шпионаж), и "обычные" злоумышленники-одиночки. Все обладают возможностями, превышающими пользовательские, и вопросы хранения данных (и исполнения/интерпретации) становятся порой жизненно важными. Georg предлагает свою страну, Швейцарию, как юрисдикцию, наилучшим образом защищающую простых пользователей. Он рекомендует сервис MyKolab, как пример облачного groupware, находящегося в Швейцарии, и тем самым находящегося под защитой законов.

Но что, если спецслужбы третьих стран вынудят владельца или одного из инженеров Kolab выдать им доступ, когда те будут за границей Швейцарии? Для того, чтоб избежать таких проблем, сообщает Georg, его пароли отключаются при его визитах в другие страны, например в Великобританию, где законодательно могут потребовать пароль.

Опубликовано 24.10.2014 17:54 пользователем Peter Lemenkov
Наконец-то, после 25й (!) итерации, OverlayFS включили в дерево vfs.git. Еще пара-тройка шагов, и его включат в официальный Git-репозиторий Торвальдса.

OverlayFS, это результат более чем четырехлетней разработки Miklos Szeredi, разработчика FUSE. Целью проекта является создание "многослойной" файловой системы, объединяющей другие файловые системы в одну, и предоставляющей возможность "форка" полученной системы. Одним из приложений этой функциональности были LiveCD, которые таким образом планировали предоставлять возможность прозрачного доступа к системе на чтение-запись. Еще вариантом использования была функциональность "factory reset" в embedded-системах (телефоны, роутеры, медиаплейеры), когда основная система никогда не изменялась, а настройки велись в union-fs. С развитием облачных технологий появилось еще одно применение - большая часть облачных систем идентична, и хочется эту общую часть разделять между сотнями и тысячами контейнеров в хостовой системе одновременно позволяя всем контейнеризированным приложениям ее изменять, если нужно.

Существовало несколько реализаций Union-FS в разных системах (хороший обзор был сделан Valerie Aurora на LWN.net - первая часть и вторая часть), но в Linux ни одна из реализаций не добралась до ванильного ядра. Причин тому много - архитектурная усложненность, низкое качество кода, высокий уровень ненависти в рассылке ядра социально-личностные проблемы. Ближе всех к ядру подобралась было AuFS, и ее даже поспешно включили в ряд Debian-based дистрибутивов. Но быстро выяснилось, что это было ошибкой, т.к. система оказалась чрезвычайно сложной, хрупкой, и бесперспективной для включения в ядро. Но ущерб поспешными действиями мэйнтейнеров был нанесен - разработчики Docker, по наивности полагаясь на возможности, присутствовавшие в самом популярном Linux-дистрибутиве, решили базироваться на aufs. Непонятно, почему они не проконсультировались с нашими коллегами, которые бы наверняка подсказали более рациональное решение. Так или иначе, когда у Red Hat появился интерес к Docker, то наши коллеги протянули руку помощи зашедшему в архитектурный тупик проекту, переведя его на Device Mapper.

История OverlayFS началась давно, и по сравнению с другими вариантами, система выглядела очень простой. Мэйнтейнеры ядра, придерживаясь их неповторимого стиля общения в списке рассылки ядра, отозвались о патчсете окрыляюще для начинающих - Andrew Morton сказал, что ему проще не принимать его, а на последовавшее предложение перенести функционал в FUSE-модуль в userspace, Linus Torvalds, в присутствии разработчика userspace-файловых систем, высказался, что люди, разрабатывающие файловые системы в userspace просто заблуждаются. Получив свою дозу мотиваторов, Miklos за три года совершил еще две дюжины попыток, и наконец-то пробился!

Одним из первых пользователей OverlayFS были разработчики OpenWRT, и недаром - factory reset и откат при аварии обновления для них является обязательной фичей. Как вы знаете, атомарное, консистентное, изолированное и надежное обновление системы в рамках старой Linux-архитектуры сейчас в общем случае невозможно. Особенно сложно добиться хотя бы частичного удовлетворения ACID, если использовать не RPM, а один из нестандартных самодельных пакетных менеджеров (некоторые из них довольно популярны, и их примитивность и малофункциональность порой видится их наивными пользователями как преимущество перед сложным RPM). Наши коллеги работают над надежными апдейтами довольно давно - offline-апдейты, перенос всего в /usr, использование btrfs, контейнеризация и изоляция приложений, инициатива Fedora Atomic, и многое другое. До чего-то работающего еще пока, к сожалению, довольно далеко.

Опубликовано 24.10.2014 10:56 пользователем Peter Lemenkov
После визита в гости к известному хулигану и матершиннику, давнишнему пользователю Fedora, Linus Torvalds, и после посиделок у другого нашего коллеги, Jes Sorensen, Linux Foundation навестили еще одного нашего коллегу. Встречайте, Linux Foundation в гостях у John Linville!



Опубликовано 23.10.2014 12:59 пользователем Peter Lemenkov
Мы уже рассказывали о печальной судьбе патчсета -RT. Вкратце повторим - его тянет на себе единственный доброволец, Thomas Gleixner. Несмотря на то, что на его труде строятся коммерческие продукты ряда компаний, от них ему ничего не перепадало. Из компаний его спонсировала в основном Red Hat, которая и так оплачивает разработку почти всего опенсорса, но та больше не спонсирует, т.к. проект непрофильный. Профильной его работа является для компаний, разрабатывающих embedded-продукты, но они вообще ему никак не помогали. Вообще, если Томас надеялся на чувство справедливости у любителей придержать исходники до публичного скандала, а потом кинуть в толпу форкнутый U-Boot трехлетней давности и пропатченное ядро Linux 2.6.14 без истории изменений, в одном большом ZIP-файле с бинарными модулями без исходников, которые и собрать-то не всегда получается, то он жестоко просчитался.

Его печальная история продолжается, плавно перерастая в трагикомедию. Даем слово Томасу:

...[Томас] получил письма от примерно двух дюжин компаний, которые спрашивали его о расписании выхода Linux 3.16-rt, потому что это требуется для планирования выхода их коммерческих продуктов. Он отвечал им, что у него нет бюджета, чтобы планировать, и спрашивал их не могут ли они помочь? Некоторые компании не ответили вообще, что Томас назвал "честным подходом". Другие ответили, что денег нет. Создавать продукт на основе технологии, и не иметь бюджета, чтоб работать над ней, это "безумие", по словам Томаса. А вот третьи сказали, что раз так, то они будут разрабатывать продукт на основе ядра 3.12-rt.
Удивительно, но денег на проект не оказалось даже у US Navy. Ну если и натовская военщина не хочет помочь, то Томас сказал, что раз так, то разрабатывать RTLinux на постоянной основе он прекращает, и будет относиться к нему, как к хобби.


Thomas Gleixner после общения с M***a V***a и натовцами

Опубликовано 23.10.2014 10:24 пользователем Peter Lemenkov
Выложили видеозаписи всех выступлений с ежегодного мероприятия Gstreamer Conference, которое проводится с 2010 года. Enjoy!

Опубликовано 22.10.2014 23:45 пользователем Peter Lemenkov
Приближается еще одно мероприятие - OpenStack Summit November 2014 Paris. Оно состоится в Париже, с 3го по 5е ноября (2го начинается регистрация, а 6го и 7го тусовочные дни). Расписание очень плотное, и наших коллег там будет прилично. Ожидается заезд наших соотечественников из компании Mirantis, от которой будет представительная программа, как и положено одному из лидеров разработки OpenStack.

Присоединяйтесь!

Опубликовано 21.10.2014 17:58 пользователем Peter Lemenkov
Только что анонсировали очередной митап DevOps Moscow коммьюнити:

После летнего перерыва возвращаемся к DevOps митапам. В этот раз эксперимент - будем проводить митап в будний день. К нам приедет Jérôme Petazzoni из компании Docker и расскажет нам о Docker из первых рук. Программа мероприятия будет позже. Ждите обновлений.


Мероприятие состоится 29 октября, с 18.00 по 22.00 в офисе Badoo, БЦ "Легенды Цветного", сразу напротив метро Трубная. Цветной бульвар, 2, стр. 1 Зарегистрируйтесь, чтобы получать обновления.

Опубликовано 21.10.2014 14:12 пользователем Peter Lemenkov
Вслед за списком пожеланий от разработчиков systemd, у разработчиков GNOME появился свой GNOME Kernel Wishlist.

Опубликовано 20.10.2014 15:29 пользователем Peter Lemenkov
Появилось дополнение к новости о выходе версии 1.2 утилиты для сборки RPM, mock. Michael Šimáček решил поподробнее рассказать о нововведениях в этой версии. которых больше, чем было анонсировано. И действительно, список новинок довольно значителен:

  • Уже упомянутый плугин для LVM. Это изменения для больших билд-ферм, которое будет использовать фичи LVM по созданию снапшотов. Общая пакетная база, из которой собираются rootfs для сборки, как правило, довольно значительна. Поэтому LVM должен сильно экономить время на перегенерацию roots при его использовании. Раньше мы использовали тарболы, которые распаковывались в chroot.
  • Улучшение производительности с помощью nosync при перегенерации Yum DB при сборке rootfs. В случае создания rootfs особая надежность на случай аварии не нужна, поэтому нет нужды вызывать большое количество раз fsync (man 2 fsync), что ускорит сборку пакетов.
  • Поддержка dnf. Мы уже используем dnf в быту - работает надежно, хотя порой иначе, чем yum, что замечали и наши коллеги. Пока фича считается экпериментальной.
  • Улучшенный режим журналирования. Теперь mock печатает в консоли и вывод Yum/DNF и rpmbuild.
  • Меньшее количество блокирующих операций. Некоторые операции над rootfs теперь поддерживают множественный доступ, например shell-доступ к ней, прямо в процессе сборки.
  • Теперь mock может выполнять дополнительные команды Yum/DNF, например mock --pm-cmd clean metadata-expire.
  • В процессе сборки rootfs можно выполнять команды --enablerepo и --disablerepo пакетного менеджера.
  • Долгожданная команда short-circuit, позволяющая проходить заново обвалившиеся стадии без запуска с самого начала.
  • Возможность передачи дополнительных аргументов в rpmbuild. Например для выбора алгоритма сжатия в финальном пакете.
  • Теперь можно задавать свои пути к утилитам rpm, rpmbuild, yum, yum-builddep, dnf. Таким образом можно легко подменять их своими версиями, без необходимости изменять system-wide копии.
  • Автоматическая инициализация и улучшенная очистка после завершения.
  • Поддержка Python 3.
  • Малоизвестная фича --unique-ext. Она позволяет запускать в параллель несколько сборок одного и того же пакета, с тем же названием. Напрямую это сделать нельзя, т.к. сборки будут использовать одну и ту же директорию для chroot, а благодаря этому ключу к названию добавится указанный суффикс, и конфликта не будет.


Конечно, пока наша инфраструктура неидеальна, но судя по таким новостям, мы потихоньку движемся в верном направлении!

Страницы

Get Fedora! Скачать RFRemix 21!
Slax Linux

Обменная кнопка проекта:

Хостинг для проекта предоставлен компанией FastVPS

Сайт поддерживается российским сообществом Fedora, Red Hat не несет ответственности за его содержимое.
Обратная связь |Благодарности |Правовые положения Fedora | Торговые марки Fedora