Структура Snappy пакета.
Canonical представила свой формат пакета snap, который является эволюцией пакета click и рано или поздно придёт на замену пакету deb. Давайте рассмотрим структуру пакета snap.
Прежде чем начать, хотелось бы вам и себе в очередной раз разжевать, а чем не угодил deb и зачем нужен snap?
Во-первых, deb пакет хорош, но он создан людьми Дебиан, которые сплош создатели операционной системы, а не прикладные программисты. То есть deb пропитан духом - прикладной софт сторонних программистов не отличим от системы. Но стороннему софту попасть в основные репозитории и там актуально обновляться очень сложно. В deb пакете кроме бинарников есть Maintainer Scripts - команды, вызываемые при событиях удаления (post/pre rm), установки (post/pre inst). Всё это нужно проверять! Как? Canonical хочет автоматизировать сей процесс и ускорить одобрение.
Во-вторых, deb полагается на полное разрешение зависимостей между пакетами (full dependency resolution), а snappy - всё своё ношу с собой.
В-третьих, файлы из deb пакета располагаются по Filesystem Hierarchy Standard (FHS), а он пока не предполагает версионность. Snappy пакеты при обновлении будут иметь возможность отката при проблемах.
В-четвёртых, Дебиан и, следовательно, Убунту - это не rolling дистрибутивы. Есть релизы и временные рамки, в котором живёт сам релиз и софт в нём. Хотите свежую версию софта из репозитория? Добавляйте ещё один репозиторий типа PPA, где выкладывается более актуальная версия. Canonical хочет, чтобы сторонний софт безопасно появлялся у вас так быстро, как это возможно и через официальные репозитории. Со Snappy - PPA будут не нужны.
Анатомия snappy пакета.
Snappy пакет невероятно прост. Весь код пакета разместят в /apps/<программа>/current/, единственное место обитания ваших файлов вашего пакета. В сущности, ваш пакет snappy - тарбол данного каталога. Из-за работы механизма откатов при проблемах, при обновлении вашего пакета snappy будут создаваться версионные папки в /apps/<программа>/<версия>/, а /apps/<программа>/current/ указывает на текущую, активную версию. Нет жёстких ограничений на структуру пакета. Можете разместить любые файлы в любом месте. Можете статически слинковать бинарники или носить с собой свои библиотеки. Создать любое дерево каталогов и файлов. Единственное условие, что должен существовать файл метаданных meta/package.yaml. Все метаданные обитают в meta/package.yaml. Их список будет ниже, а кратенько для знакомства укажем пример:
name: pkgname version: version-string binaries: - name: binary exec: path/to/binary - name: another-binary exec: path/to/another-binary
В примере, у нас есть пакет с именем pkgname, версией version-string и 2 бинарника. Бинарники, как вы поняли, нужно декларировать. Сервисы, если вы их предоставляете, так же нужно объявлять.
Данные нужно писать в каталог, зависящий от данного приложения. Предоставляются 2 места, доступные для записи. "Системный" каталог
/var/lib/apps/<pkgname>/current/
и пользовательский каталог в домашней папке
/home/$USER/apps/<pkgname>/current/
Вы не сможете писать куда-либо ещё.
Опции метаданных package.yaml.
Обязательные поля:
- name: имя пакета (разрешено [a-z0-9][a-z0-9+.-]).
- version: версия (разрешено [a-zA-Z0-9.+~-]).
- vendor: имя, емайл или URL разработчика.
Опциональные поля:
- icon: путь к иконке SVG, которая будет отображена в Ubuntu Store.
- explicit-license-agreement: Если Y, то пользователь должен принять лицензию из meta/license.txt ДО установки пакета.
- license-version: строка, которая если меняется и explicit-license-agreement = Y, то вызывается запрос на принятие лицензии снова.
- type: тип пакета snappy:
- app - подразумевается по дефолту если type не указан.
- oem - специальный snap от OEM, который обслуживает их оборудование.
- framework - специальный snap, который расширяет возможности системы.
- architectures: Список в формате YAML поддерживаемых архитектур. Если пустой, то подразумевается ["all"].
- frameworks: список фреймворков, нужные для работы. Например frameworks: docker, foo, bar
- services: сервисы (демоны), предоставляемые пакетом.
- name: обязательное имя сервиса ([a-zA-Z0-9+.-]).
- description: обязательное описание сервиса.
- start: обязательная команда старта сервиса.
- stop: обязательная команда остановки сервиса.
- stop-timeout: опциональное указание в секундах таймаута для ожидания остановки. По дефолту 60 секунд.
- poststop: команда, выполняемая после остановки сервиса.
- Пример:
services: - name: service-name description: "line of text" start: "relative/path/to/binary --with --cmdline --parms" stop: "path/to/command --with --parms" stop-timeout: 45 - name: service-name-2 description: "another line of text" start: "relative/path/to/binary-2 --with --cmdline-2 --parms"
- caps: caps = capabilities. Список в человекочитаемом формате (для примера network-client) дополнительных политик безопасности. Данный список будет транслирован в политики AppArmor и seccomp. Если caps и security-template не указаны, программе разрешены сетевые возможности. Caps не совместим с security-override и security-policy.
- security-template: опциональный и альтернативный шаблон безопасности вместо дефолтного. Если указать опцию без caps, то подразумевается пустой caps. Не совместимо с security-override или security-policy.
- security-override: опциональное перекрытие настроек безопасности, когда не хватает security-template и caps. Несовместимо с caps, security-template или security-policy. Использование данного поля обязательно вызовет запрос на ручную проверку пакета специалистом перед попаданием в Ubuntu Store.
- apparmor: path/to/security.override
- seccomp: path/to/filter.override
- security-policy: опциональное указание вручную созданную политику безопасности. Несовместимо с caps, security-template или security-override. Использование данного поля обязательно вызовет запрос на ручную проверку пакета специалистом перед попаданием в Ubuntu Store.
- apparmor: path/to/profile
- seccomp: path/to/filter
- ports: опциональное указание портов, с которыми сервис будет работать
- internal. Порт для внутренней коммуникации.
- TagName в свободной форме
- port: номер-порта/протокол, типа 80/tcp
- negotiable: опционально. Если указано Y, то приложение может использовать другой порт, если нужный занят.
- external. Порт будет открыт для обмена с миром.
- TagName в свободной форме
- port: номер-порта/протокол, типа 80/tcp
- negotiable: опционально. Если указано Y, то приложение может использовать другой порт, если нужный занят.
Пример,
ports: internal: localcomm1: port: 3306/tcp,3307/tcp,3308/udp negotiable: yes external: ui: port: 80/tcp negotiable: no - internal. Порт для внутренней коммуникации.
- bus-name: опциональное сообщение по шине об имени сервиса. Можно применять только если type : framework.
- binaries: Список бинарников. Бинарники вызываться будут $pkgname.$binary. К примеру есть пакет hello-world и в нём hello, то результирующая команда hello-world.hello
- name: требуемое имя бинарника ([a-zA-Z0-9+.-])
- exec: программа, которая будет вызвана.
- source: URL где можно работать совместно с разработчиком программы.
readme.md
Файл meta/readme.md содержит описание пакета в формате README. Инструментарий snappy автоматически извлекает заголовок как краткую аннотацию пакета и первый параграф как описание в Ubuntu Store.
Что у нас в сухом раскладе? Автор программы компилирует своё детище - статически или с библиотеками. В папке проекта создаёт подпапку meta и там 2 файла: package.yaml и readme.md. Если работа программы не требует сверх исключений из вопросов безопасности, то одобрение в Ubuntu Store будет автоматическим и моментально софт станет доступным конечным пользователям. Если программа заявила себе определённый шаблон безопасности, а вздумает работать злонамеренно, то AppArmor просто не даст сделать что-либо. Пользователь может откатывать изменения, если они привели к проблемам. Откатится как софт, так и настройки.
Пока мне не ясен один момент. Если разные версии программы есть в системе, то можно их вызывать для работы по номеру версии? В целом мне нравится мир, который рисует Snappy. А вам?
Связь пакетов:
Будущее Убунту со Snappy.
Модель транзакционного обновления Snappy.
