Snap vs Deb.

Многие пользователи начинают интересоваться как технически устроена работа программы в snap пакете. По мере своих сил, как снапкрафтер, пытаюсь ответить на вопросы и вот решил вынести всё в одну статью. Буковок много, но для нетерпеливых в конце статьи есть краткая выжимка. Итак, мир deb против мира snap.

Установка программы

В традиционном мире deb пакетов ваша операционная система Linux (далее на примере Debian, Ubuntu,...) обладает списком источников софта, которые называются репозитории (repository). Вы можете поправить эти списки в файлах:

• Официальные репозитории в файле /etc/apt/sources.list
• Самостоятельно добавленные в каталоге /etc/apt/sources.list.d/

Устанавливая софт через GUI или CLI, ваш установщик-обновлятор софта вначале скачивает с репозиториев списки доступного в нём софта. Так как софт, как сложный программный продукт, сопровождающими (мантейнерами) традиционно разбивается на логические части, идущие в различных пакетах, то требуется обработать зависимости с помощью ресурсов вашего ПК и этот процесс называется full dependency resolution.

В мире snap источники софта называются хранилищами (store). Формально говоря, понятия зависимости в мире снап не существует. И один снап пакет с программой не зависит от другого снап пакета. Чуть ниже разжую один сложный момент, но в данном месте, чтобы вас не путать, условимся что в истинном понимании слова зависимость такого процесса как full dependency resolution в мире снап - НЕТ!

Установщик-обновлятор deb пакетов скачивает их с репозитория в каталог типа /var/cache/apt/archives/, распаковывает их содержимое по тем абсолютным путям, что идут в пакете деб. После ваших команд типа apt clean пакеты в /var/cache/apt/archives/ будут удалены, так как они выполнили свою задачу и больше не нужны.

Программа внутри snap сжата со всем необходимым ей с помощью squashfs. Пакет скачивается с хранилища в виде snap package в каталог /var/lib/snapd/snaps/ и НИКУДА и НИКОГДА не распаковывается. Пакет с программой банально монтируют в каталог /snap/ИМЯ-ПРОГРАММЫ/ВЕРСИЯ/

В мире deb специально программу дробят на различные пакеты, традиционно выделяя библиотеки/плагины/фреймворки в отдельные пакеты, чтобы делить их с другими программами. Рассмотрим упрощённый классический пример, когда программа А идёт в пакете a-v1.deb и зависит от пакета openssl-v1.deb и программа B из пакета b-v1.deb, зависящая так же от openssl-v1.deb. Говорят о том, что программа А и В де́лят между собой (share) общую библиотеку openssl-v1, а пакет a-v1.deb и b-v1.deb зависят от одного и того же пакета openssl-v1.deb.

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

Тут многие зададутся вопросом - зачем терять место на диске, таская в каждом снап пакете одно и тоже, отказываясь от классной штуки share?

Когда придумывали формат snap (он эволюционное развитие формата click), хотели прежде всего отказаться от full dependency resolution. Каждый из нас и не раз встречал ситуацию, когда разрешение зависимостей заканчивалось ошибкой. Вам нужно было пробовать столкнуть ситуацию с места командами sudo apt-get install -f или sudo dpkg --configure -a. Можно было попробовать переустановить пакет с установкой дефолтных настроек - sudo apt-get -o DPkg::options::=--force-confmiss --reinstall install ПАКЕТ_ПРОГРАММЫ Это всё попахивает не надёжностью в мире серверов и десктопа, а в мире мобильных устройств, для которых готовили формат snap, - это смерти подобно. Давайте пока дальнейший отказ Canonical от мобильной ветки и от идеи конвергенции тут не будем затрагивать, ибо snap пакет родом из мобильной сферы, но ею не ограничивается. Итак, фейл при установке пакета на телефоне. Как на маломощном устройстве сталкивать ситуацию с мёртвой точки при вероятной проблеме? Тем более full dependency resolution довольно таки затратная операция для ЦПУ. Нужна была надёжность в лице атомарности:
1) скачал snap пакет.
2) не затратно для CPU примонтировал пакет БЕЗ всяких full dependency resolution, ничего никуда не распаковывая.
3) получил новую версию программы.
4) если новая версия программа будет вызывать проблемы, то можно легко откатиться к старой версии, перемонтировав на старую версию пакета.

Занятое место

Давайте вопрос с занятым местом разрешим здесь навсегда.

Должен ли снап пакет, хранящий в себе всё что нужно программе + саму программу, быть жирнее аналогичного комплекса из деб пакетов этой же программы? Ответ - нет! Примеры в лице LibreOffice и Krita показали меньший размер в формате снап.

Будут ли множество программ в snap пакетах занимать больше места, чем они же в деб пакетах. Ответ - да. Без механизма share, когда масса программ могут использовать одни и те же компоненты, общий их размер будет больше.

Открою тайну, подлив масла в огонь хейтерам snap! Для поддержки механизма отката и возможности вернуться к старой работоспособной версии, в системе хранится несколько версий snap пакета программы.

Вот мой личный пример на момент написания статьи
ll /var/lib/snapd/snaps/

drwxr-xr-x 1 root root       334 авг 23 10:14 ./
drwxr-xr-x 1 root root       216 авг 25 13:18 ../
-rw-r--r-- 1 root root  83349504 июл  4 07:40 core_2312.snap
-rw-r--r-- 1 root root  84393984 июл 17 15:21 core_2381.snap
-rw-r--r-- 1 root root  84393984 июл 26 16:47 core_2462.snap
-rw-r--r-- 1 root root 148656128 янв  5  2017 inkscape_1880.snap
-rw-r--r-- 1 root root 149258240 фев 16  2017 inkscape_2527.snap
-rw-r--r-- 1 root root 153026560 авг 10 07:47 inkscape_3080.snap
-rw------- 1 root root 209604608 авг  8 08:58 languagetool_x1.snap
-rw------- 1 root root 108244992 ноя 28  2016 pac-vs_x1.snap
drwxr-xr-x 1 root root         0 ноя 24  2016 partial/
-rw-r--r-- 1 root root  85258240 июн 20 13:19 xnsketch_2.snap
-rw-r--r-- 1 root root 154583040 июн 26 17:12 xnviewmp_1.snap

Мы видим 3 snap пакета core_*.snap, олицетворяющую операционную систему (об этом ниже). 3 пакета inkscape_*.snap программы Inkscape. Если вас напрягает такая ситуация, когда одна и та же библиотека находится внутри различных снап пакетов И снап пакетов одной и то же программы может быть несколько, то может сто́ит занятое место воспринимать как плату за ВЕРСИОННОСТЬ и НАДЁЖНОСТЬ?

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

Все программы внутри snap пакета изолированы от операционной системы и друг от друга профилем мандатного доступа AppArmor. Но и в темнице есть окна для связи со внешним миром. В терминах snap технологии - это интерфейсы (interface). Интерфейс - это когда plug соединён со slot. Хотите из программы звук? Просите при упаковке программы через snapcraft.yaml, чтобы plug pulseaudio соединили с одноимённым slot pulseaudio в системе (пакет ubuntu-core). До этого момента все slot предоставляла операционная система через снап пакет ubuntu-core. То есть ВСЕ программы, стыковались (connect) ТОЛЬКО со слотами системы и получали требуемое. Разработчики реализовали интерфейс content и стало возможно снап А соединить со снап Б.

Разработчики KDE активно щупали технологию Snap, чтобы попробовать представить своё детище в таком формате. Первые пробы упаковки KCalc рожали снап пакеты по 70 мб из-за kde-frameworks-5 внутри, но стоило воспользоваться интерфейсом connect и вынести kde-frameworks-5 в отдельный snap пакет, то KCalc похудел до 300 кб

Художник во мне от слова худо, поэтому попытался вам нарисовать ситуацию ДО и ПОСЛЕ появления content interface.

К сожалению, до сих пор графическая Ubuntu Software не умеет разруливать такие ситуации, когда вы ставите пакет снап А, а он будет просить коннекты к пакету Б. Я видел даже графические наброски разрабов, но пока такое не реализовано и, на примере KCalc вы можете пока только в консоли скомандовать
sudo snap install kcalc
sudo snap install kde-frameworks-5
sudo snap connect kcalc:kde-frameworks-5-plug kde-frameworks-5:kde-frameworks-5-slot


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

Снапкрафтер из проекта КДЕ при упаковке kcalc создавал snapcraft.yaml, который внутри пакета будет лежать у вас в системе по адресу /snap/kcalc/current/meta/snap.yaml

Нужная для понимания часть файла.

apps:
    plugs:
    - kde-frameworks-5-plug
    - home
    - x11
    - opengl
    - network
    - network-bind
    - unity7
    - pulseaudio

plugs:
  kde-frameworks-5-plug:
    content: kde-frameworks-5-all
    default-provider: kde-frameworks-5
    interface: content
    target: kf5

Что мы видим? Plugs с именами home, x11, opengl, network, network-bind, unity7, pulseaudio будут соединены с одноимёнными slots к ubuntu-core, которая олицетворяет систему. kde-frameworks-5-plug использует интерфейс content.

Теперь анализируем /snap/kde-frameworks-5/current/meta/snap.yaml

slots:
  kde-frameworks-5-slot:
    content: kde-frameworks-5-all
    interface: content

Мы видим слот kde-frameworks-5-slot, использующий интерфейс content.

Кто-то скажет, что ушли от понятия зависимости в мире deb, но connect между snap пакетами чем не связь-зависимость? Частично вы правы, но дьявол прячется в мелочах. Сейчас в большинстве дистрибутивов linux вы не можете иметь несколько одновременно установленных в системе библиотек типа gtk/qt или различных версий runtime типа KDE Frameworks. Новые версии библиотек и runtime вынуждают сторонних авторов ПО отслеживать их API/ABI и частенько переписывать свои детища, если они хотят и впредь видеть свою программу в официальных репозиториях. Более подробно лучше прочесть в статье Разработчики GTK хотят разрушить Linux desktop. В мире snap можно в операционной системе обладать несколькими версиями библиотек/runtime и просить коннект к нужной. Это тонкая грань между зависимостями (dependancy) в мире deb и соединениями (connect) в мире snap, но её нужно понять на уровне ДНК.

Работа программы

В данном разделе давайте рассмотрим различия в работе программ, установленных из деб и снап пакетов. Большинство Linux систем - это discretionary access control (DAC). Вы установили программу А и при запуске её бинарника, в памяти он становится понятием - процесс. Запускали программу вы от своего имени и процесс будет обладать теми правами, которыми обладает ваша учётная запись. Если вы можете зайти в папку /share/folder_x/ и прочесть файл secret.txt, то и программа А сможет это сделать. В традиционном мире Linux мы надеемся на порядочность программистов, пишущих софт, и на внимательность сопровождающих пакета, которые пытаются не допустить злоупотреблений. Молимся, чтобы сетевой программой удалённо не кукловодил злоумышленник, отправляя к себе наши файлы, поимев программу через дыры. То есть в мире DAC нам остаётся надеяться, верить и молиться.

Мир snap - это mandatory access control (MAC). Снапкрафтер при упаковке программы в декларативном виде описывал многие вещи в файле snapcraft.yaml, в том числе к каким интерфейсам он желал бы подключить программу. Эти желания будут развёрнуты в правила системы мандатного доступа AppArmor и проанализировать их можно по адресу /var/lib/snapd/apparmor/profiles/

Следует помнить, что мир MAC строже чем DAC. Программа находится в изоляции и может только то что ей разрешено профилем. В мире снап запущенная программа А не сможет зайти в /share/folder_x/ и прочесть файл secret.txt при всём её желании. Отсюда следует вывод, который многие упускают. После установки программы в виде снап пакета, любой её бинарник НЕ сможет что-либо считать, кроме как из пути /snap/ИМЯ-ПАКЕТА/ВЕРСИЯ/

Другими словами и ещё раз. НЕЛЬЗЯ считать и подгрузить из вашей системы бинарники, библиотеки из /usr/, /lib/ . Интерфейс home, если он запрошен, даёт ограниченный и фильтированный доступ к вашей домашней папке ~/.

Зачем и кому нужен snap?

Сторонний программист со своим прикладным софтом

Snap задумывался как упрощение процесса попадания прикладного софта от стороннего программиста в официальные репозитория-хранилища. Из-за того, что в деб пакете есть скрипты post/pre inst/rm, выполняющиеся от root, сопровождающему при любом обновлении софта снова требуется визировать новую версию. Более подробно Контр доводы к словам Кайла Кина.

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

Пользователь

При любых изменениях в операционной системе, можно быть уверенным, что программа "не поломается" из-за изменений в библиотеках/фреймворках. Установил раз - работает всегда.

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

Системный администратор

Технология snap поддерживает версионность и возможность отката. Пакеты ставятся атомарно и нет ситуаций - вы застряли по середине. Программа работает под присмотром системы мандатного доступа и вам гарантируют поведение программы в рамках профиля и фильтрацию системных вызовов по белому списку.

Кратко

Давайте кратко всё резюмирую.

Deb	Snap
Программу с её библиотеками в мире деб красиво представляют в виде множества пакетов, которые зависят друг от друга.	В снап пакете обычно идёт программа со всем необходимым ей. Иногда тяжёлые фреймворки выносят в отдельный snap и делают к нему connect.
Deb пакеты скачивают, распаковывают содержимое, выполняя рихтовочные control скрипты.	Snap пакет скачивают и монтируют в каталог, ничего никуда не распаковывается. Внутри сжатого пакета снап нет каких-либо скриптов, которые вызываются кем бы то нибыло.
Программа из пакета deb ничем не ограничена и получает доступ ко всему к чему у вас есть права.	Программа в snap пакете работает в изоляции. Получает нужное через интерфейсы и не получает какой-либо доступ, даже если у вас есть на это права.
В мире deb сложнее осуществляется версионность. Откат к старой версии может быть технически невозможен, ибо в репозитории может отсутствовать старый пакет к этому времени. Процедура понижения версии (downgrade) непроста и редко используется в практике. Атомарность не гарантируется. Все стараются, чтобы при обновлении всё прошло гладко, но не всегда система может быть переведена из одного рабочего состояния А в другое Б.	Snap пакеты поддерживают атомарность и версионность. Вы можете откатывать софт к версии ранее и пакет или ставится полностью или не ставится совсем, если есть какие-то технические проблемы.

Дата последней правки: 2017-08-26 15:46:41