Russian Fedora

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

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

Праздник к ним приходит!

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

Веселье в коммьюнити Debian продолжается. Предсказуемо, но Ian Jackson опять потребовал, чтоб мэйнтейнеры не смели забрасывать поддержку альтернативных недоработанных init-систем.

Коллеги-аналитики уже обсуждают новость на OpenNET.ru.

image0 Прекращаем работу и начинаем конструктивно обсуждать systemd! Только мы порадовались, что на недавно прошедшем systemd-хакфесте мэйнтейнеры Debian и Ubuntu наконец-то синхронизировали кодовую базу с апстримом, и нате вам. Ну будем надеяться, что здравомыслие восторжествует, и коммьюнити остановит злого клоуна вовремя.

2 года работы над AArch64

Присоединившийся чуть больше года назад к Red Hat embedded-разработчик Marcin Juszkiewicz, недавно отмечавший эту дату, отмечает годовщину следующего события - два года его работы над AArch64.

Поздравляем! В последнее время, после пренебрежительного отзыва Jon Masters о cute embedded nonsense hacks и вовлечения наших коллег в разработку стандартной (SBSA) платформы для AArch64, в коммьюнити появились панические настроения, мол Fedora не будет поддерживать не-SBSA системы. Участник Fedora ARM SIG, Peter Robinson, официально объявил, что Fedora будет поддерживать Cute Embedded Nonsence Hacks на AArch64.

Бояться нечего - U-Boot и DeviceTree будут работать.

Process Identifier Preservation Society и Libvirt

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

Всем известно, что PID в системе крайне мало (см. cat /proc/sys/kernel/pid_max), и их надо беречь. Первый человек, который открыто стал заботиться о PID, был Lennart Poettering, в его первом анонсе systemd (см. "Keeping the First User PID Small"), и к его призыву присоединились и другие, в начале 2014 года организовав Process Identifier Preservation Society с рекомендациями для программистов о пидосбережении.
Пока кто-то посмеивался, привычно наматывая портянки из bash-скриптов, пришел shellshock, и народ, наконец-то, проняло. Конечно надо учесть, что конкретно у Bash проблемы в ДНК, и его разработка в одиночку ведется человеком, застрявшим даже не в 1990х, а в самом дремучем юниксвэе 1980х, даже без системы контроля версий, но тем не менее - рекомендации PID Preservation Society наполнились смыслом, до тех пор непонимаемым некоторыми коллегами-аналитиками.
К сожалению, когда вспоминают о том, как правильно запускать другие процессы из приложений, то в антипримеры первым делом всплывали пара известных программ. Ну, во-1, это Anaconda, и с ней все и так понятно.

А вот во-2, что для нас всегда было грустно слышать, это Libvirt.

Например, обратите еще раз внимание на седьмую страницу из уже приводимой в пример довольно радикальной презентации с Linux Plumber Conference 2012 нашего коллеги Andy Grover.

Инженер Red Hat, Daniel P. Berrangé, расстроившись из-за того, что Libvirt одним махом записали в субоптимальный код, решил рассказать про историю того, как с процессами управляется Libvirt, и почему было сделано именно так, а не по-другому.

История API запуска процессов в Libvirt без использования shell
Если говорить о запуске дочерних процессов, то у Libvirt очень интересная история - давнее игнорирование стандартных методов и вызовов библиотечных функций ANSI C system / popen и использование fork / exec с помощью неких высокоуровневых самописных врапперов. Для этого было несколько причин, некоторые очевидные, некоторые нет:
  1. Отказ от использования shell. Командная строка, передаваемая в запускаемые программы, часто содержит данные, введенные пользователем. Правильно обработать ее, чтобы заблокировать вредоносный shell-код, это нетривиальная задача. Отказ от использования shell избавляет от целого класса таких атак, и был высокоприоритетной задачей.
  2. Потокобезопасная работа в файловыми дескрипторами. Обычно, это ошибка, когда дочерним процессам позволяется наследовать файловые дескрипторы. Из-за ошибки при дизайне Unix специфицирует, что файловые дескрипторы наследуются по умолчанию при exec, из-за чего требуется выставлять флаг O_CLOEXEC чтобы предотвратить наследование. Если не использовать нестандартные расширения Glibc, то установка O_CLOEXEC может вызвать race condition в многопоточных программах, использующих system / popen. Единственные переносимый вариант гарантировать на 100%, что не будет утечек файловых дескрипторов в дочерние процессы, это выполнить массовое закрытие всех файловых дескрипторов до fork / exec.
  3. Безопасная обработка сигналов. Команды system / popen не сбрасывают обработчики сигналов после fork(). Таким образом есть риск, что обработчики сигналов, зарегистрированные программой, будут вызваны между fork / exec, при выполнении внешних команд. В зависимости от того, что эти обработчики сигналов делают, это может быть серьезной проблемой.
  4. Предоставление лучшего API. Команды system / popen просто использовать в простых случаях, но они не помогут в более сложных сценариях. Например, сборка списка аргументов командной строки часто требует большого количества операций со строками и массивами.

Насчет shellshock
В свете проблемы с shellshok в bash мы довольно счастливы, что Libvirt в основном не использует system / popen. Есть лишь два места, где, как я помню, Libvirt использует shell.
Во-1, когда используется транспорт SSH для API удаленного доступа, то клиент Libvirt логинится на удаленном хосте, чтоб создать туннель до демона Libvirt, и это приводит к использованию shell.
Это может лишь быть использовано для shellshock, если администратор попытался ограничить права пользователя с помощью опции в конфиге SSH ForceCommand. Для аккаунтов Libvirt это довольно непопулярное решение, т.к. предоставление доступа к демону Libvirt подразумевает привилегии, эквивалентные суперпользователю, и таким образом мало чего можно добиться ограничениями в SSH.
Во-2, служба libvirt-guests, которая запускается init-системой, чтобы приостановить гостевые системы при выключении, написана на shell-скриптах, и таким образом потенциально уязвима для shellshock. Риск может возникнуть, если непривилигированный пользователь будет иметь возможность менять имя гостя. Например, гость с названием “() { :;}; echo vulnerable”. К счастью тестирование до сих пор показывало, что невозможно использовать эксплойт в контексте выполнения libvirt-guests, даже при злонамеренно измененном имени гостевой системы, т.к. большинство операций использует UUID.
Всего несколько месяцев назад код в Libvirt, ответственный за network filtering, использовал автоматически сгенерированные огромные скрипты на shell чтобы запускать iptables. Мы не анализировали этот устаревший код, чтоб проверить уязвим ли он, но считается, что это маловероятно, т.к. единственные строки, вводимые пользователем, были имена цепочек iptables, а Libvirt их строго проверяет. В любом случае из актуальных версий Libvirt этот код уже удален, и вместо этого он общается с firewalld через DBus API.
Конечно, вполне возможно, что другие внешние программы, с которыми общается Libvirt, в свою очередь используют shell и могут быть уязвимы. Но как минимум, области, за которые ответственнен Libvirt, можно считать безопасными по отношению к shellshock.
График изменений API запуска процессов
После исключения system / popen, оставшиеся варианты запуска внешних программ, это fork / exec или, возможно, posix_spawn. API posix_spawn, на самом деле, довольно современно в смысле предоставляемой гибкости, но все еще обладает высокой ценой использования с точки зрения требуемых им аргументов функции. Таким образом за эти годы в Libvirt появился высокоуровневый API вокруг fork / exec, который сейчас используется везде в его кодовой базе. Нижеследующая история проливает свет на то, как API развился в его текущую форму и текущий функционал.
  • 2007.02 – qemudStartVMDaemon(). Когда драйвер QEMU был впервые добавлен в Libvirt, была добавлена и функция qemudStartVMDaemon(), чтобы упростить запуск QEMU с помощью fork / exec. Заметными действиями этого враппера были подключения stdio дочернего процесса к пайпам, и затем закрытие всех прочих дескрипторов. Это предотвращало опасное использование shell и утечку файловых дескрипторов.

    Реализация функции не допускала повторное использование, т.к. в ней был код для преобразования конфига QEMU в массив argv.

  • 2007.02 – qemudExec(). Когда в драйвер QEMU была добавлена возможность запуска dnsmasq, то qemudStartVMDaemon() была переписана в функцию qemudExec(). Это был первый в Libvirt повторно используемый враппер вокруг fork / exec. Получая массив параметров командной строки он запускал дочерний процесс, с присоединенным stdin к /dev/null и возвращал пару пайпов для чтения stdout и stderr. Это было наравне с popen() по удобству пользования, но гораздо более безопасней в использовании из-за исключения shell и более безопасного использования файловых дескрипторов. В будущем функция получила гораздо больше фич.

  • 2007.07 – _virExec(). С появлением драйвера OpenVZ, функция qemudExec() была перемещена из драйвера QEMU в модуль общих функций. Это был первый шаг в сторону совместного использования большого количества кода между различными драйверами виртуализации в Libvirt. Функционал остался тем же, что и в qemudExec().

  • 2008.08 – _virExec(). Было обнаружено race condition, возникающее при обработке сигналов, упомянутое выше. Обработчик сигналов зарегистрированный в родителе был настроен на запись в пайп, когда приходил сигнал, но _virExec закрывал дескриптор пайпа, и его номер порой был писпользован повторно, когда настраивался пайп для использования с stdio дочернего процесса.

    Исправление было в блокировке всех сигналов перед тем. как запускать fork(), и разблокировке их после fork(). Однако, перед разблокировкой дочерний процесс сбрасывал все обработчики сигналов в дефолт.

  • 2008.01 – virRun(). API _virExec() API был преднаначен для запуска долгоживущих дочерних процессов, так что он возвращал PID дочернего процесса и ожидал, что родитель будет вызывать функцию waitpid. Чтобы упросить запуск короткоживущих программ был представлен API virRun(), который просто запускал _virExec() и затем вызывал waitpid, передавая потом статус выхода дочернего приложения в родительское. Это было аналогично system() по простоте использования, но безопаснее из-за исключения shell и более безопасного использования файловых дескрипторов.

  • 2008.08 – _virExec(). API _virExec() изначально создавал пару пайпов, чтобы потом передавать данные stdout/stderr в родительское приложение. Позже было обнаружено, что более удобно передавать дескриптор уже открытого файла вместо создания нового пайпа. Поэтому API _virExec() был расширен.

  • 2008.08 – _virExec(). Изначально все запускаемые программы наследовали все переменные окружения, установленные в демоне Libvirtd. API _virExec() был расширен, чтобы позволить передачу произвольных переменных, и чтобы заменять установленные переменные. Если запрашивалась модификация переменныт, то вызывалась функция execve(), иначе использовалась execvp(). В этом же изменение также предлагался новый флаг для демонизации дочерней программы. В случае выставления этого флага дочернее приложение вновь вызывало fork(), и первый дочерний процесс выходил. Дочернему процессу дочернего процесса также выставлялась домашняя директория в “/”, и он становился session leader.

  • 2008.08 – _virExec(). Как было упомянуто выше, все файловые дескрипторы в дочернем процессе закрывались, и совершенно новый набор дескрипторов присоединялся к stdin/out/err. Для лучшего контроля API _virExec() был расширен чтобы позволить родителю передавать дополнительный набор файловых дескрипторов.

  • 2009.02 – _virExec(). С появлением поддержки sVirt / SELinux в драйвере QEMU возникла необходимость производить некоторые действия между вызовами fork() и exec(). Чтоб не хардкодить эти действия для каждого места, где вызывается _virExec(), была добавлена возможность добавить callback для этого.

    Этот callback запускался сразу перед exec() и использовался для установки меток SELinux для процесса QEMU.

  • 2009.05 – _virExec(). Многие дочерние процессы имеют возможность записать pid-файл, что полезно, когда они запускаются как демоны, т.к. нет надежного способа снаружи получить PID дочернего процесса после второго форка. Тут есть опасность race condition для родительского процесса, потому-что нет гарантий, что pid-файл уже существует в момент, когда _virExec() возвращает управление родителю. Поэтому пришлось расширить функционал _virExec(), чтобы позволить ему создавать pid-файлы при демонизации команд.

    Таким образом родителю гарантируется, что pid-файл уже существует когда _virExec() возвращает управление.

  • 2009.06 – _virExec(). Когда запускается привилегированный процесс, то он обычно наследует все capabilities родителя. Если известно. что программа не требует каких-то из них, то лучше удалить их. В virExec() API была добавлена поддержка libcap-ng, чтобы удалять capabilities дочерних процессов.

  • 2010.02 – _virExec(). Синхронизация с внутренним мьютексом журналирования. Если поток находился в процессе вызова сообщения для журнала, а другой поток вызывает virExec(), то мьютекс журналирования будет захвачет первым потоком. Любая попытка журналирования в дочернем процессе застрянет в дедлоке. Чтобы поправить это нужно захватить мьютекс журналирования перед форком нового процесса, и отпустить его сразу после форка.

    Такие веселые пляски приходится делать везде, где есть глобальный мьютекс, который нужно захватить во время работы пары fork / exec.

  • 2010.02 – virFork(). Есть пара случаев, когда Libvirt нуждается в возможности вызвать fork без последующего exec. Так что код для работы с fork() и сброса обработчиков сигналов был отделен отvirExec(), чтобы его можно было использовать независимо.

  • 2010.05 – virCommand. Список параметров для virExec() вырос больше, чем хотелось бы, так что пришлось создать новый объект - virCommand.

    Идея в том, чтобы заполнить этот объект, а уж потом передать его в функцию, которая и выполнит команду, собранную из него. Если вызывать virExec, то вызывающий сам должен собрать char **argv, а если использовать virCommand, то есть удобные функции-хелперы, которые упрощают процесс создания argv и делают его более надежным.

  • 2010.11 – virCommand. Обычно, кактолько запускается дочерний процесс, то он работает асинхронно от родительского. Однако, бывают случаи, когда им обоим нужно шагать в ногу друг с другом.

    Например, блокировке дисков в Libvirt нужно захватить хранилище перед тем, как запустится бинарник QEMU, но ему нужно знать PID запущенного процесса и, к сожалению, код захвата ресурса не может быть запущен в дочернем процессе (который-то уж PID знает наверняка). API virCommand был расширен функционалом взаимного подтверждения (handshake).

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

  • 2012.01 – virCommand. API команды virCommand API позволяло дочернему процессу наследовать все capabilities, либо все их блокировать. Но есть случаи, когда необходим более тонкий контроль, например запуск LXC-контейнеров с ограниченными привилегиями. Пришлось расширить API virCommand чтобы добавлять указанные capabilities в дочерний процесс.

  • 2013.01 – virCommand. Ситуация, когда хочется изменить UID/GID запущенного процесса - не такая уж и редкость, особенно если нельзя доверять процессу делать это самому, ну или когда он уже не может изменить их из-за удаленных capabilities (удаленный флаг CAP_SETUID). API virCommand API был расширен, чтобы позволить изменять UID+GID запускаемому процессу.

    Это изменение вносится между fork / exec одновременно с изменением capabilities у процесса.

  • 2013.05 – virCommand. При запуске QEMU очень важно отрегулировать некоторые системные ограничения, например, поднять максимальное количество одновременно открытых файлов, причем независимо от ограничений, наложенных на сам демон Libvirt (libvirtd). Опять, API virCommand пришлось расширить, чтобы можно было устанавливать системные ограничения между fork / exec.

  • 2014.03 – virCommand. Во время unit-тестирования желательно предотвратить взаимодействие с системой, так что это непросто протестировать код, которые запускает внешние команды. Однако в API virCommand было легко включить тестовый режим, в котором команде можно предоставить callback-функцию вместо реальной команды. Эта функция возвращает необходимые данные в stdout/stderr, которые требуются для тестирования кода.

  • 2014.09 – virCommand. В UNIX, по умолчанию дочерний процесс наследует umask родительского процесса process, что не всегда желательно. Например, хотя Libvirtd может иметь umask 0077, желательно, чтобы QEMU получил umask 0007, чтобы можно было настроить разделяемые ресурсы группы. API virCommand получил новую опцию для указания umask, устанавливаемой между *fork* / *exec*.


Вышеприведенная хронология показывает, что собственный API Libvirt для запуска дочерних процессов получил довольно большой функционал за семь лет разработки. Он быстро превзошел system / popen по безопасности по отношению к разным серьезным проблемам, в тоже время сохраняя простоту использования. Это было достигнуто без необходимости выставлять весь низкоуровневый API наружу.
Низкоуровевые детали изолированы в одном месте, и остальной код использует высокоуровневый API. В следующем блог-посте я приведу реальные примеры использования API virCommand.
В целом мы не услышали почти ничего нового, о чем бы многократно не говорил Lennart Poettering, но тем не менее, заметка получилась очень показательной. Мы надеемся, что те, кто думают, что запуск процессов супервизором, это легкотня, запросто реализуемая на bash-портянках, начнут в этом сомневаться.

Из каких элементов состоит подсистема Linux Storage

К проходящему LinuxCon Europe Werner Fischer выложил обновленную схему компонентов подсистемы хранения Linux.

Наши коллеги Andy Grover и Ric Wheeler уже изучили схему и высоко ее оценили, одобрив работу автора.

http://www.thomas-krenn.com/de/wikiDE/images/e/ee/Linux-storage-stack-diagram_v3.17.svg

Кликните для полноразмерной картинки

Ceylon 1.1.0 и Rust 0.12

Gavin King объявил о выходе Ceylon 1.1.0. Анонс уже обсуждают коллеги-аналитики на OpenNET.ru. В целом нам кажется интересной идея языка, одинаково хорошо работающего и в JVM, и в виртуальной машине JS, например в Node.js. Похоже, что у Red Hat есть планы на мобильные приложения - не с этим ли связана покупка Red Hat компании FeedHenry? Печально, но пока язык Ceylon даже не включен в репозитории Fedora, и чтоб попробовать его, нужно собирать самому.

Другой интересный язык, новая версия которого была недавно анонсирована и уже тоже обсуждается коллегами-аналитиками на OpenNET.ru, это Rust. Его не то, что нет в репозиториях, но раньше он даже не собирался в Fedora 20 и старше, настолько он инновационен. Зато начиная с Fedora 21, и с его версии 0.12 он хоть собирается. Язык довольно интересен. Например, его сборщик мусора умеет самостоятельно закрывать сокеты, файлы и освобождать прочие системные ресурсы.

Стоит попробовать, хотя будьте готовы к тому, что в отличие от Golang его синтаксис плывет от версии к версии.

Польза тестирования

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

В других коммьюнити вокруг открытых проектов потихоньку меняют свои взгляды на тестирование. Например, не так давно тесты появились даже в ядре Linux, которое до этого никто не тестировал вообще (даже после появления тестов никто особо его не тестирует). Но вот в рамках дистрибутивов пока очагов тестирования немного. Навскидку вспоминается инженер Canonical и разработчик systemd, Martin Pitt, который проводит какую-то нечеловеческого объема работу по созданию тестов уровня пользователя, уже упомянутые наши тестовые дни, и еще есть секретная лаборатория в подвалах дата-центров Red Hat. В этих подвалах наши коллеги ведут тестирование прикладного ПО, в т.ч. и на уровне GUI, о чем был интересный доклад на прошедшем FOSDEM 2014, который некоторые наши участники посетили лично. А в вашем дистрибутиве есть тестирование?

Огромный объем тестирования, проводимый в Red Hat, предсказуемо приводит к недавно анонсированному результату - 17% уязвимостей в безопасности выявляются самими инженерами Red Hat, а почти 27% они узнают по знакомству, что примерно тоже самое. Уязвимость, выявленная "по знакомству", это порой та же уязвимость, найденная лично, просто после обнаружения ошибки дополнительно приходится консультироваться с upstream, чтоб разобраться в причине. Все это это и приводит к более большому уровню надежности RHEL по сравнению с конкурентами, которые получают информацию об уязвимостях лишь после анонсирования их в интернете (вот зачем нужно брать на работу разработчиков, а не только дизайнеров, переносящих кнопки справа налево и обратно).

Но, конечно, коллеги-аналитики верно подметили, что нашими и делается ошибок тоже навалом. Например, в grep обычно происходит так - вносится улучшение, которое только все портит, а в следующей версии уже исправляется внесенное улучшение (см. grep 2.18 и grep 2.20). Бывает, чего уж. Сперва добейся, а потом критикуй!

Само собой, не только у нас заботятся о безопасности - половину других уязвимостей ведь кто-то находит. В дружественной нам компании Collabora тоже занимаются безопасностью системных компонентов, например устраняют ошибки в D-Bus. Их инженер, Alban Crequy, в своем блоге подводит итог последних месяцев работы по улучшению безопасности D-Bus. Как вы знаете, наши друзья и коллеги планируют перенести его функционал в ядро Linux, поэтому эта работа довольно интересна для нас.

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

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

Наша инфраструктура и сопутствующие проекты продолжают развиваться.

В строй окончательно введена и запущена в работу наша реализация release tracker - Anitya. Это подключенный к шине fedmsg сервис, собирающий информацию с нескольких популярных хостинговых платформ, (GitHub, GNOME, пока еще незакрытого Google Code, CPAN, GNU, и еще нескольких), и создающий заявки в Fedora Bugzilla. Введение такого сервиса позволит отказаться и от запускаемого по cron cnucnu и ряда других архитектурно устаревших сервисов. Интересно, что благодаря подключению к fedmsg можно мониторить ситуацию с пакетами не только в Fedora, но и в других дистрибутивах. Пока планируется подключение CentOS, и уже начато подключение к Debian, что, разумеется, еще больше усилит наше позитивное влияние на этот проект. Как вы помните, Debian давно подключился к fedmsg, хотя полного объединения инфраструктур пока не произведено.

Отвлекшись от новости, нужно отметить, что разработка современных сервисов, подобных Anitya и fedmsg, была бы трудозатратной без появления удобных API на хостинговых платформах. Например, GitHub API, SourceForge API, Hackage API. Без них пришлось бы как в 2000е по крону выкачивать html-странички по ftp, а затем парсить перлом их содержимое. Индустрия, под влиянием революции социальных сетей, сдвинулась в сторону распределенных и автоматизированных систем, состоящих из изолированных узлов, управляющих друг другом с помощью сообщений через Web API. То, что DevOps называют microservices.

Некоторые коллеги-аналитики замечают, что архитектура микросервисов очень хорошо соответствует идеям Unix-way, и всерьез противопоставляют архитектуру микросервисов архитектуре shared libraries. Конечно, в наше время идея shared libraries по ряду причин не выглядит столь привлекательно, как это было лет 20-30 назад, да и мы постепенно продвигаем идею платформы systemd/Linux, в которой ядро платформы будет сформировано из сильно связанных общей шиной, но работающих в независимых ячейках (например, в контейнерах) сервисов, обменивающихся сообщениями, но мы предостерегаем некоторых DevOps от чрезмерного увлечения идеями почти полностью статических приложений. Проблемы у shared libs в основном обусловлены отсутствием средств мониторинга изменений API. Изменение API зачастую фатально сказывается на работоспособности системы c shared libs, но хоть эта проблема и не очень видна в случае архитектуры, основанной на передаче сообщений, там она тоже есть. Это мы вам, как бывалые разработчики на языках с передачей сообщений между потоками, говорим.

Верьте нам, мы инженеры!

Возвращаясь к теме о Anitya. Нам очень жаль, что в сервисе пока никак не используется результаты работы наших соотечественников над проектом Upstream Tracker. Без проверки API решение не будет законченным. Ну т.е. оно не будет законченным и с проверкой API, но с ним оно более законченней. Мы периодически обсуждаем функциональность Upstream Tracker, но пока выглядит все так, что дальше обсуждения ничего не продвинулось. Плохо, конечно, но пока вот так.

Введен в строй еще один новый узел - Taskotron. Это современная замена старому AutoQA, который, по большому счету, ничего особо не умел, кроме тривиального статического анализа собранных RPM-пакетов. Теперь же, в рамках Taskotron будет возможность добавлять функциональные тесты уровня пользователя, и мы опять надеемся, что коммьюнити популярных дистрибутивов, как и в случае с fedmsg, тоже будут им пользоваться.

Презентация Taskotron на прошедшем Flock 2014 (`слайды презентации <https://tflink.fedorapeople.org/presentations/flock2014_taskotronAndMe/>`__)

Перед тем, чтобы что-то тестировать, его надо бы собрать в пакет. Для этого мы используем утилиту mock. Работала она не очень шустро, с помощью chroot, и порой создавала интересные ситуации, когда запускалось в параллель сразу несколько сборок одного и того же пакета. Недавно наш коллега, участник GSoC 2014, Michael Šimáček добавил поддержку LVM (напомним, в LVM есть возможности создавать снапшоты, и "форкаться" от них, что теоретически может ускорить создание rootfs для сборки, т.к. у них будет значительная общая часть), а Miroslav Suchý добавил поддержку контейнеров systemd-nspawn вместо chroot. Пришлось изменить внутренний API, поэтому была выпущена новая тестовая версия mock. В стабильные версии Fedora (включая уже и 21ю), она, к сожалению не попадет, но будет доступна в Copr-репозитории.

Ну и напоследок новость об инфраструктуре GNOME. Они переехали на FreeIPA.

Готов к [STRIKEOUT:десктопу] продакшену!

Началась конференция LinuxCon + CloudOpen + Embedded Linux Conference Europe

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

Сегодня в Дюссельдорфе началась конференция LinuxCon Europe (на самом деле сразу несколько). Расписание довольно интересное, с кучей выступлений представителей дружественных нам компаний. Основная тематика, в общем, предсказуемая - то, что актуально сейчас (распределенные системы, облака, контейнеры, виртуализация, платформа systemd/Linux, ARM). Завтра там же параллельно откроется KVM Forum с более специализированной программой, так что будем следить за появлением записей выступлений.

image0 Наш стенд разместили рядом с Oracle