Просмотр исходного текста страницы Поддержка сторонних пакетов rpm в ОС Альт (OSSDEVCONF-2018)

;{{SpeakerInfo}}:
* {{Speaker|Дмитрий Державин}}
* {{Speaker|Виталий Липатов}}
<blockquote>
Традиционно дистрибутивы операционных систем семейства Альт рассматриваются разработчиками в первую очередь как
реализация программной платформы для совместных программных и программно-аппаратных решений. При этом сами разработчики
ОС рекомендуют технологическим партнёрам оформлять свои программные продукты в виде пакетов rpm, собранных в
соответствии с правилами, принятыми для пакетов ОС Альт, и с помощью нативных инструментов ОС Альт.

К сожалению, не все разработчики с готовностью внедряют соответствующие технологии и соблюдают правила. Иногда в
совместных проектах встречаются пакеты, разрушительно влияющие на другие компоненты и систему в целом. Авторы доклада
предлагают краткий обзор возможных подходов к решению этой проблемы.
</blockquote>

{{VideoSection}}
{{vimeoembed|287829175|800|450}}
{{youtubelink|fghe3lbqlYs}}
{{letscomment}}

{{----}}

== Thesis ==

Основной источник проблемы — умолчальное разрешение на использование произвольных сценариев в пакетах. База данных rpm позволяет отслеживать конфликты между пакетами на уровне файлов. Но, если с точки зрения разработчика стороннего по отношению к системе пакета какой-то файл, предоставленный другим пакетом, просто необходимо заменить — это легко можно сделать на уровне сценариев, входящих в состав пакета и автоматически выполняющихся при его установке. Конфликта при установке пакета не возникнет. При проверке соответствия дерева каталогов записям в базе данных rpm конфликт будет замечен, конечно же, но тогда будет уже поздно — пакет установлен и «всё работает». При этом для такого разработчика не вполне очевидно, что «работает» только его часть, а остальные компоненты совместного решения вполне могут пострадать.

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

Полный запрет выполнения сценариев в пакетах с точки зрения обеспечения целостности системы выглядит многообещающе. Но для реализации этой идеи потребуется как-то формализовать и автоматизировать рутинные операции, для которых установочные сценарии сейчас используются ответственными разработчиками. В этом смысле понятно, что можно сделать, например, с добавлением пользователей и групп — добавить их в виде объектов в базу данных rpm. При этом появится дополнительное преимущество в виде возможности устанавливать соответствующие зависимости. С запуском и остановом служб, предоставляемых пакетом, направления поиска решения тоже понятны — можно попробовать так же интегрировать в базу данных rpm unit-ы системы инициализации systemd. Возможно, трудоёмкость этой задачи окупится преимуществами отказа от выполнения произвольных сценариев и новыми типами зависимостей. Но что делать, например, со сценариями миграции — вопрос более сложный. Действительно, существует ряд плохо формализуемых задач, решение которых в случае отказа от выполнения сценариев потребует отдельной исследовательской работы.

Ещё один важный аспект запрета сценариев — реакция сообщества коммерческих компаний-разработчиков на такое изменение. Здесь важно иметь в виду не столько психологические моменты, связанные с новыми запретами, сколько неожиданные трудозатраты, необходимость которых может быть не очевидной. Поэтому, возможно, имеет смысл одновременно предлагать разработчикам новые для них технологии, позволяющие оптимизировать сборку и упаковку ПО для различных отечественных ОС. Здесь перспективными выглядят технологии, разработанные и успешно применяемые в компании Этерсофт — в частности, Коринф и epm, уже неоднократно обсуждавшиеся на этой конференции. Таким образом, перейдя на единый сборочный сценарий, разработчики смогут сэкономить ресурсы и одновременно сделать свои пакеты более пригодными для использования в составе совместных решений.

Второй из предлагаемых подходов к решению проблемы сценариев — разрешение на их выполнение только при установке доверенных пакетов. Например, подписанных участниками Alt Linux Team. Этот вариант хорош тем, что может стимулировать коммерческих разработчиков вствпать в Team и сопровождать там пакеты типа -preinstall, которые сейчас широко используются в качестве прослойки между дистрибутивными и недистрибутивными пакетами, предоставляя недостающие зависимости. Как свойственно полумерам, это «решение» по сути не решает проблему выполнения произвольных сценариев, а просто переносит её в другую плоскость. Очевидно, введение такого решения в качестве единственного может вызвать очередное «соревнование снаряда и брони» в виде расширения списка разрешений на уровне конкретных внедрений.

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

Авторы не предлагают при рассмотрении проблемы ограничиваться каким-то одним из предложенных подходов к решению. Возможно, имеет смысл применять их частично и комплексно. Также, выступление является приглашением к обсуждению проблемы как на конференции, так и за её рамками.




{{----}}
[[File:{{#setmainimage:Поддержка сторонних пакетов rpm в ОС Альт (OSSDEVCONF-2018)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->




{{vklink|1175}}                                          
{{fblink|2165930266993316}}                                          
<references/>
* В дискуссии упоминается доклад [https://www.youtube.com/watch?v=0cOjf_8MzF4&feature=youtu.be  Flock 2017 - Scriptlet Reform and RPM Independence: building images in the Container Era]



{{stats|disqus_comments=0|refresh_time=2018-10-19T21:08:27.556532|vimeo_plays=6|youtube_plays=0}}

[[Категория:OSSDEVCONF-2018]]
[[Категория:ALT Linux]]
[[Категория:Инструменты майнтейнеров]]