1. установка програми
2. Зайняте місце
3. Робота програми
4. Навіщо і кому потрібен snap?
5. коротко

Багато користувачів починають цікавитися як технічно влаштована робота програми в snap пакеті. У міру своїх сил, як снапкрафтер, намагаюся відповісти на питання і ось вирішив винести все в одну статтю. Літер багато, але для нетерплячих в кінці статті є коротка витримка. Отже, світ deb проти світу snap.

установка програми

У традиційному світі deb пакетів ваша операційна система Linux (далі на прикладі Debian, Ubuntu, ...) володіє списком джерел софта, які називаються репозиторії (Repository). Ви можете поправити ці списки в файлах:

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

Встановлюючи софт через GUI або CLI, ваш установник-обновлятор софта спочатку викачує з репозиторіїв списки доступного в ньому софта. Так як софт, як складний програмний продукт, що супроводжують (мантейнерамі) традиційно розбивається на логічні частини, що йдуть в різних пакетах, то потрібно обробити залежності за допомогою ресурсів вашого ПК і цей процес називається 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 /

Ми бачимо 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

Потрібна для розуміння частина файлу.

Що ми бачимо? 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

Ми бачимо слот 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 систем - це d iscretionary a ccess c ontrol (DAC). Ви встановили програму А і при запуску її бінарники, в пам'яті він стає поняттям - процес. Запускали програму ви від свого імені і процес буде мати ті правами, якими володіє ваш обліковий запис. Якщо ви можете зайти в папку / share / folder_x / і прочитати файл secret.txt, то і програма А зможе це зробити. У традиційному світі Linux ми сподіваємося на порядність програмістів, які пишуть софт, і на уважність супроводжуючих пакета, які намагаються не допустити зловживань. Молимося, щоб мережевий програмою віддалено НЕ ляльководи зловмисник, відправляючи до себе наші файли, поїмо програму через діри. Тобто в світі DAC нам залишається сподіватися, вірити і молитися.

Світ snap - це m andatory a ccess c ontrol (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 підтримує версійність і можливість відкоту. Пакети ставляться атомарному і немає ситуацій - ви застрягли по середині. Програма працює під наглядом системи мандатної доступу і вам гарантують поведінку програми в рамках профілю і фільтрацію системних викликів по білому списку.

коротко

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