Дмитрий Левин

Дмитрий Левин, Заместитель генерального директора, главный архитектор ООО «Базальт СПО».
Закончил мехмат МГУ по специальности математика. Один из инициаторов проекта Sisyphus и сообщества ALT Linux Team (2000 год), разработчик инфраструктурного ПО Sisyphus. Основатель (2001 год) и главный архитектор ООО «Альт Линукс». Основатель (2015) ООО «Базальт СПО». Мейнтейнер strace и многолетний контрибьютор множества международных проектов разработки СПО.

---

Инфраструктура разработки Sisyphus

---

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

---

hasher: инструмент безопасной сборки пакетов

Первая задача, которую предстояло решить – создание инструмента безопасной воспроизводи-мой сборки пакетов репозитория из исходного кода. Традиционный в то время инструментарий сборки пакетов в хост-системе был ненадёжным и небезопасным. Новый инструментарий дол-жен был соответствовать следующим требованиям:

не снижать уровень безопасности хост-системы; обеспечивать собственную безопасность от атак со стороны пакетов;

обеспечивать безопасность сборки пакетов от атак со стороны других пакетов; гарантировать надёжность (воспроизводимость) результатов сборки; обеспечивать приемлемый уровень производительности.

• 2003 году такой инструмент был создан [1]. hasher базируется на принципе создания новой сборочной среды для каждой сборки.
• основе архитектуры hasher’а лежит трёхпользовательская модель: вызывающий неприви-легированный пользователь и два непривилегированных вспомогательных псевдопользователя; первый играет роль root в порождаемой сборочной среде, второй – обычного пользователя, со-бирающего программы.

Переключение между вызывающим и вспомогательными пользователями осуществляется

• помощью специальной привилегированной программы, написанной с применением парано-идальных мер защиты от непривилегированных пользователей. Кроме того, с помощью этой программы удаляются процессы, запущенные вспомогательными псевдопользователями и не завершившиеся в срок, а также создаются устройства. Наконец, эта программа предоставляет возможность контролировать ресурсы, выделяемые процессам непривилегированных пользова-телей, для защиты от DoS-атак.

gear: инструмент хранения исходного кода пакетов

С появлением git совместная разработка перешла на новый уровень, и понадобился инструмент для хранения исходного кода пакетов в git-репозиториях. Идея созданного в 2006 году gear [2] заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки

которых достаточно sed и git) можно было бы безопасно и воспроизводимо собирать srpm-пакеты из произвольно устроенного git-репозитория, по аналогии с hasher, который был задуман как средство собирать пакеты репозитория из произвольных srpm-пакетов.

gitery: безопасный хостинг репозиториев исходного кода

Одновременно с внедрением инструмента хранения исходных пакетов в git-репозиториях был создан хостинг git-репозиториев. Для каждого пользователя такого хостинга создаётся непри-вилегированный аккаунт, что позволяет использовать обычные средства разграничения досту-па в linux. Удалённый доступ осуществляется с помощью ssh, в качестве шелла используется специальная программа, которая реализует git fetch, git push, и ещё несколько операций об-служивания git-репозиториев. Реализована система почтовых уведомлений об изменениях в git-репозиториях.

girar: сборочная система

Внедрённая в 2009 система сборки [3] поддерживает целостность репозитория за счёт тран-закционных переходов, при которых полностью вычисляются характеристики репозитория. По умолчанию разрешены только переходы, которые не ухудшают характеристик. Система ориентирована на асинхронное продвижение транзакций, а окончательная сериализация и учёт взаимного влияния между транзакциями осуществляется при помощи rebase.

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

Каждое сборочное задание состоит из одного или нескольких gear-репозиториев (и их меток) или srpm-пакетов, отправленных на сборку. Сборочная система сначала осуществляет первич-ную сборку пакетов. Если при первичной сборке пакетов возникли грубые ошибки, то задание автоматически отменяется. В противном случае, если все пакеты в задании успешно собрались, то генерируется временный репозиторий, в котором выполняется ряд проверок (вычисляют-ся характеристики нового репозитория). По умолчанию переход в новое состояние разрешён, только если характеристики репозитория не ухудшились. Если же собранные пакеты ухудша-ют характеристики репозитория, то составляется список нарушений, и задание переводится в отложенный режим.

Задания, переведённые в отложенный режим, можно дорабатывать и возобновлять. Если все нарушения были сняты, то выполняется транзакционный переход репозитория в новое со-стояние.