Модель транзакционного обновления Snappy.
После того как публике была представлена новая система транзакционного обновления Snappy у многих назрело множество вопросов. И это не удивительно. Snappy и Apt-get - это два полярных решения управления обновлением системы. Apt-get оперирует пакетами и в его мире система не отделена от софта. Для Snappy система и софт раздельные понятия и он оперирует состоянием, к которому приводит базовую систему или откатывает назад. Apt-get неразрывно связан с понятием "репозиторий", из которого скачиваются списки новых программ и сами программы при обновлении. Snappy в будущем будет устанавливать софт из Ubuntu AppStore.
В данной статье речь пойдёт о Snappy, который отлично вписался в мобильном секторе проекта Ubuntu Phone (Touch). Но новый механизм обновления НЕ ограничивается мобильными системами.
Философские разговоры про разделение Системы от Приложений Canonical начала относительно давно, после начала работы над Ubuntu Phone. А это уже пару лет, как минимум! Системный софт в пакетах deb не отличим от софта сторонних приложений и даже тесно переплетён между собой в репозитории - вот такой он мир Debian и Ubuntu, как его потомок, всё это унаследовал и использовал до сих пор. Но мир изменился! Хотелось бы пустить сторонних разработчиков в новый мир, но оставить систему под жёстким контролем. Более подробно о данном процессе в статье Процесс загрузки приложения в репозиторий Ubuntu.
Уже сейчас Ubuntu Phone на мобильных системах обладает несколькими целями, которые реализует через Snappy:
- Системные обновления.
- Заменить модель "репозиторий с архивами" на модель "магазин приложений" для систем, использующих Snappy.
- Быстрое появление софта от сторонних разработчиков.
- Надёжный жизненный цикл приложения.
- Система должна оставаться простой и понятной.
- Система должна быть безопасной.
- Доверительная модель приложений, в которой пользователь легко и понятно контролирует их.
Snappy так же позволяет реализовать:
- Пуленепробиваемая система с транзакционными обновления и с поддержкой откатов.
- Система должна быть простой в использовании и понимании для сторонних интеграторов.
- Система должна быть простой в использовании и понимании для администраторов.
А теперь поподробнее ...
Системные обновления.
- Системные обновления.
- Пуленепробиваемая система с транзакционными обновления и с поддержкой откатов.
Любой разработчик операционной системы желал бы быстрое, надёжное обновление своего детища для всех использующих её людей. Кроме того, если во время обновления что-то идёт не так, то нужен механизм отката системы на предыдущее рабочее состояние. Чтобы достичь этого, Приложения должны работать отдельно от Системы и не вносить в неё непредсказуемые изменения.
Разработанный Snappy FHS (Filesystem Hierarchy Standard - стандарт иерархии файловой системы) и политики безопасности AppArmor гарантируют, что злонамеренный или неправильно работающий софт не поламает систему.
Snappy ФС.
| Метка раздела | Устройство | Дефолтный размер (Гб) | Запись? | Описание |
|---|---|---|---|---|
| system-a | /dev/sda1 | 2 | Нет | Primary root filesystem |
| system-b | /dev/sda2 | 2 | Нет | Secondary root filesystem |
| writable | /dev/sda3 | 20-(2+2) = ~16 | Да | Все данные пользователя |
Системы с Snappy имеют 2 раздела, доступных на чтение всем остальным. Эти два раздела System-a/b и позволяют механизм отката (rollback). В свежей системе раздел system-a будет занят системой, а system-b будет пустым, ибо отформатирован. Администратору не стоит забивать голову какой именно раздел является текущим и с которого производится загрузка, хотя команда snappy versions -a всё покажет и расскажет. После обновления системы через snappy update оба раздела system-a/b будут содержать образ системы, только разных версий. "Snappy update" не только производит обновление системы в другой раздел, но и "переключается" между ними, делая текущим то один, то другой.
Раздел Writable служит для сохранения ВСЕХ данных в системе:
- Изменения в системе, типа логов.
- Изменения пользователя, типа домашней папки.
- Временное хранение скаченных образов системы.
Так как оба раздела system-a/b постоянно доступны только для чтения, то необходимо указать некоторые части корневой файловой системы доступными для записи. Это делается через конфигурационный файл /etc/system-image/writable-paths, подобный fstab. А сам /etc/fstab генерируется динамически из файла writable-paths и его теперь не стоит править ручками, ибо потеряете свои изменения.
Каждый snappy пакет ставится в свой каталог. Snappy пакеты никогда не перезаписывают файлы других пакетов или старые файлы своего же пакета ранней версии. Snappy пакет может лишь читать свой каталог и писать в специальное место, доступное для записи. За этим следит AppArmor через свои профиля в обязательном режиме enforce.
Приложения ставятся в /apps/
| Каталог | Запись? | Описание |
|---|---|---|
| /apps/<программа>/<версия>/ | Нет | Файлы только-для-чтения, библиотеки, файлы ресурсов и другие бинарные файлы, шедшие с приложением. |
| /var/lib/apps/<программа>/<версия>/ | Да | Доступно для записи, конфигурации или данные, не специфичные для любого пользователя. |
| /var/lib/apps/<программа>/<старая-версия> | Нет | Только-для-чтения для приложения, резервная копия. |
| /home/user/apps/<программа>/<версия>/ | Да | Доступно для записи, конфигурационные или другие данные для конкретного пользователя. |
| /home/user/apps/<программа>/<старая-версия>/ | Нет | Только-для-чтения, конфигурации или других данных конкретного пользователя, резервное копирование. |
AppStore.
- Заменить модель "репозиторий с архивами" на модель "магазин приложений" для систем, использующих Snappy.
- Быстрое появление софта от сторонних разработчиков.
Ubuntu - замечательный дистрибутив linux с богатейшим репозиторием софта, который постоянно обновляется. Но традиционная модель deb-пакеты-в-репозитории имеет ряд недостатков, и, возможно, самый главный среди них - прикладные программисты должны преодолеть серьёзный барьер, чтобы их программа появилась на компьютерах пользователей через механизм репозиториев. Мощным софтварным компаниям лучше пойти через создание своего репозитория, хранящим новые версии программного продукта данной компании. А как быть небольшим студиям или программистам-одиночкам?
Модель AppStore с призвана упростить появление новых версий программ на компьютерах пользователей. Чтобы устранить человеческий обзор тысяч программ в deb пакетах с помощью людей из Application Review Board (ARB), была создана система автоматического одобрения программ, если они удовлетворяют определённым критериям. Пакеты Click, в которых нет скриптов, песочница и профиля AppArmor собственно и позволяют автоматизировать approve приложений и гарантировать его корректное поведение в системе у пользователя, пока разработчик данного приложения следует правилам Ubuntu store policy.
При всём этом, Ubuntu остаётся гибкой системой, в которой вы можете устанавливать какой угодно софт и развивать комплекс "система + софт" в любом направлении.
Надёжный жизненный цикл приложения.
В мобильном мире всё работает под двумя дамокловыми мечами: энергия батареи и замедление системы при большом количестве запущенных программ. Все понимают, что компьютерная мощь смартфона от батареи не чета десктопу под постоянным питанием. Другими словами, программы в смартфоне не могут так же вольготно работать в фоне как на десктопе. Разработчики призрачно изменили конечный автомат состояний процессов и Ubuntu умеет даже переключаться между разными политиками, в зависимости от того на какой платформе она работает И/ИЛИ какое питание - постоянное или от батареи. Подробнее в статье Новая модель работы приложений в Ubuntu.
А причём тут Snappy? Snappy в отличие от полного разрешения зависимостей в apt-get, что существенно потребляет такты CPU, просто скачивает дельты новой системы и применяет их, что благотворительно сказывается на экономии батареи.
Безопасность.
- Система должна быть безопасной.
- Доверительная модель приложений, в которой пользователь легко и понятно контролирует их.
Все хотят, чтобы его система была создана безопасной by design, а не пристяжными костылями в последствии. Для Snappy были добавлены дополнительные функции, связанные с безопасностью (seccomp, управляемый абстрактный сокет связи, межсетевой экран).
В Ubuntu системный, сетевой софт обладает профилями AppArmor, а в мобильном секторе программа обязана заявлять о нужных ей правах, которые ей будут даны через шаблоны и группы политики AppArmor для работы её в ограниченной песочнице. Всё это вместе называется Моделью Доверия (Trust Model). Заметьте, что это не требует от вас ручного одобрения прав доступа, хотя если программа затребует сверх того, что ей дано системой, то пользователю будет выведен запрос во время использования данной программы и возможность запомнить на будущее ваш выбор.
Простота.
- Система должна оставаться простой и понятной.
- Система должна быть простой в использовании и понимании для сторонних интеграторов.
- Система должна быть простой в использовании и понимании для администраторов.
На Ubuntu Phone проекте разработали и обкатали вышеописанную систему, основанную на простой декларативной модели разрешений для приложений. Её решено продвигать и для всех Snappy систем, которые будут использовать установку софта из AppStore.
Система гибка и поддерживает:
- Приложение заявляет и работает строго в рамках политики безопасности.
- Приложение объявляет исключения из политик безопасности.
- Приложение объявляет об использовании политик безопасности из списка restricted.
- Приложение объявляет о работе в неограниченном режиме (unconfined).
- Приложение объявляет о работе под политикой безопасности, созданной ей самой.
Ubuntu AppStore будет автоматически принимать программы от прикладных разработчиков только из пункта 1 и вызывать запрос на ручной обзор программы человеком для всех остальных пунктов.
Будущее.
Всё описанное про механизм Snappy отлично работает для Ubuntu Phone, но для расширения влияния Snappy на другие аппаратные платформы типа серверов и облаков требуется дополнительная работа по элегантному решения вопроса доступа приложений к аппаратному обеспечению.
Сотрудники Canonical не хотят расслабляться в вопросах безопасности, которая до сих пор делала систему пуленепробиваемой. И некоторые решения, которые лезут в голову, типа временных политик безопасности для определённого доступа к устройству являются, мягко говоря, не гибкими. С другой стороны никто не желает видеть приложения, которые сами могут автоматически добавить нужную политику безопасности, что прямиком ведёт к привилегированному доступу, чего лишён пользователь Snappy Ubuntu.
Ответ на вопрос как быть? прост и лежит на поверхности. Пользователи Snappy Ubuntu - это админы, разработчики и интеграторы. Они смогут сами сделать доверительное разрешение для доступа приложению к оборудованию. Решено в ближайшем будущем реализовать возможность пользователю указать, что данной программе к данному оборудованию доступ РАЗРЕШЁН. Такая возможность НЕ идёт в разрез с Trust Model, даст гибкость и мобильность, учитывая использование традиционных Linux API.
Snappy не просто конкурент Apt-get, а новая идеология обновления системы и установки софта. Если работу apt-get мы видим каждый день, то новому snappy нужно, как минимум, дать время. И только потом решить для себя - годно или нет!
Материалы:
Партнёрство Canonical и Microsoft.
