Авторские статьи об OpenSource

Структура 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
    
  • 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.

    Twitter   


Разделы

Главная
Новости
Ворох бумаг
Видео Linux
Игры в Linux
Безопасность
Статьи о FreeBSD
Статьи об Ubuntu
Статьи о Snappy
Статьи об Ubuntu Phone
Статьи о Kubuntu
Статьи о Xubuntu
Статьи о Lubuntu
Статьи об Open Source
Карта сайта

Лучшее на сайте:

1С под Linux.   Ускорение Ubuntu.   21 пример iptables.   Цикл статей о Ceph.   Убунту в дикой среде.   Ubuntu Linux на SSD.   Ubuntu для блондинок.   Поддержка железа в Linux.   BTSync на службе у админа.   Андроид программы в Ubuntu.   Прокидывание портов для p2p.   Анти СПАМ в Postfix.  



Круги Гугл Ада.


Группа поддержки