В этом посте мы рассмотрим архитектуру Solus, рассмотрим некоторые ключевые отличия, отделяющие его от других проектов. Обратите внимание, что это техническая статья, и не охватывает каждую область Solus, ради краткости.
Одной из главных целей Solus является: обеспечение стабильного выпуска дистрибутива Linux, с акцентом на домашние системы. На первый взгляд, это может показаться тривиальным, но как это будет с течением времени? В двух словах, наши инструменты и цели являются продолжением нашей философии, и позволяют нам постоянно нам поддерживать дистрибутив.
Важно помнить, что первая версия Solus выглядел абсолютно не так, как мы описываем её ниже. Фактически, Solus 1.0 должен был быть статически версионным, классическим дистрибутивом, который со временем значительно эволюционировал в полноценный, общедоступный дистрибутив. Эта статья поможет вам понять, как именно мы дошли до этого момента, и показать закулисье, которые делают Solus тем, чем он является. И наконец, мы не претендуем на совершенство! Есть и другие области для активных действий, и мы продолжаем развиваться, и надеемся, что наш подход к решению этих вопросов может быть полезен для сторонних проектов, за пределами Solus, будь то код или просто философия.
Репозиторий
Любой пакет в Solus начинает жизнь с репозитория git, размещенном на портале разработки. Как только Разработчик доволен изменениями, номер версии изменяется, и они запускают make publish, чтобы отправить сборку на наш контроллер сборок. Удаленный сервер сборок будет клонировать тот же репозиторий, из неизменяемого тега git, и если сборка завершится успешно, она будет загружена экземпляром в наш ferryd, для дальнейшей обработки.
В течение 15 секунд после того, как набор пакетов достигнет ferry, они будут включены в нестабильный репозиторий. Эти пакеты проверяются в манифесте transit, для проверки полезной нагрузки (payload,), и в случае успеха они будут доступны в нашем репозитории. В то же время, ferryd будет планировать обновления delta в фоновом режиме, так что важность обновления будет сведена к минимуму, для будущих пользователей, одновременно сохраняя разблокировку основной очереди обработки. Это позволяет нам поддерживать высокую каденцию, а также обеспечивать удобство для ограниченной пропускной способности.
Пользователю
Однако, нестабильный репозиторий имеет тенденцию соответствовать своему названию! За одну неделю, мы видим сотни изменений и множество критических преобразований, и исправлений. Таким образом, разработчики предпочтут неустойчивую сборку, позволяющее оптимизировать это окно обновления, в то время как подавляющее большинство пользователей будет находиться на стабильной сборке (известный как Shannon). Каждую неделю мы проходим через этот итеративный процесс разработки, и стабилизируем хранилище вовремя, для еженедельной синхронизации. На этом этапе, мы выполняем все оставшееся тестирования, с реальным оборудованием, и производим тестовые ISOs, для проверки наших изменений. Когда все будет хорошо, мы будем выполнять еженедельную (обычно в пятницу) синхронизацию в stable. Как правило, эта операция занимает 15-20 секунд и извлекает все новые/отсутствующие пакеты из текущих версий, опубликованных в unstable, в shannon. Это делает процесс синхронизации невероятно быстрым, и мы можем снова, немедленно начать hacking на нестабильной версии.
Кроме того, ferryd будет порождать Дельта-операции, для создания любых отсутствующих пакетов delta, для ShПользователюannon в фоновом режиме, что позволит после синхронизации свести к минимуму, потребления пропускной способности, для пользователей на Shannon. За кулисами, мы используем различные методы дедупликации, включая подсчет ссылок на все идентификаторы активов в пуле и жесткую привязку этих пакетов между unstable и shannon через пул, чтобы минимизировать общее использование диска репозитория. Это позволяет нам сохранять несколько backversions пакетов и расширенной графики для пакетов "Дельта", снизив Размер скачиваемых обновление для пользователей. Все это происходит "бесплатно" с нашей архитектурой, что позволяет нам поддерживать высокую скорость без каких-либо жертв.
Rolling Snapshot
Если говорить начистоту, то unstable технически является "реальным" отображением дистрибутива, а Shannon - это прокатанная, проверенная версия unstable. Наши действия таковы, что каждая еженедельная обновление представляет собой новую версию Solus Shannon, в то время как Unstable непрерывно проверяется. Это дает пользователю защитное одеяло, и разработчики имеют больше свободы вносить необходимые изменения. Таким образом, мы можем вносить радикальные архитектурные изменения или даже выполнять большие обновления стеков, такие как последние обновления MATE 1.20 или Plasma 5.12. В качестве дополнительного слоя, разработчики могут использовать функциональность локального репозитория soilbuild, для создания массивных локальных изменений / дополнений перед их размещением, для включения в нестабильную среду.
Формат Пакетов
Однажды Solus использовал наследие actions.py / pspec.xml, унаследованный от PiSi. Однако, мы очень быстро поняли, что мы просто перекопировали все, и потратили много времени на ручное написание одних и тех же правил, снова и снова. За первые дни мы заменили устаревший формат, нашим собственным пакетом .yml в ypkg. Это структурированный, декларативный формат сборки, который используется с 2015 года. В отличие от других вариантов сборок собственного пакета, мы использовали автоматизированный подход к политике, и правилам. По сути, пакет .yml - файл содержит некоторые инструкции по сборке, которые являются просто встроенными скриптами bash со специальной разметкой (например, %configure) и автоматическим учетом размещения файлов и зависимостей между пакетами.
Это позволяет постоянно производить пакеты, используя правила дистрибутива (например, наши флаги, расположение файлов, директорий) и наслаждайтесь автоматическим подпакетом (например, -devel, -docs, -dbginfo). По сравнению с началом, появился огромный функционал поддерживающий широкий диапазон характеристик, включая:
Улучшенные макросы для многих систем сборки
Автоматическая Оптимизация профиля на профиль шаг
Автоматическое управление флагами с помощью optimize keyset, для включения целевых оптимизаций компилятора
Расширенный fnmatch пользовательские шаблоны стиля, для автоматического создания определенных разработчиками подпакетов
Поддержка источников git sources
Полная поддержка -m32 сборки пакета (emul32: да произведет -32бит пакеты, и соответствующие -32bit-devel, -32bit-dbginfo, etc)
Следует отметить, что в качестве раннего дизайнерского решения, мы решили не включать поддержку триггеров в наш формат, чтобы сохранить его простым.
Сборки всех пакетов выполняются в специальных контейнерах через solbuild, который использует overlayfs, чтобы обеспечить нормальную среду сборки, для облегчения сборки пакетов Solus на любой системе, которая поддерживает современные overlayfs. Это создаёт многие детали реализации для нас, такие как источники git, или экспорт git changelogs, непосредственно в результирующие пакеты, чтобы позволить пользователям знать, что мы изменили в наших пакетах, просто посмотрев на данные обновления, в центре программного обеспечения. Кроме того, мы используем это, чтобы выполнить некоторые незначительные песочницы, такие как отключение привилегированных операций в контейнере, а также отключение сети по умолчанию (loopback localhost разрешен, однако.)
Активатор пакетов
В традиционных пакетных дистрибутивах используется понятие триггеров (скриптов постинсталляции). На самом простом уровне они будут запускать некоторые сценарии / операции после установки/удаления/обновления пакета в системе, такие как обновление кэша значков, добавление пользователей и т. д. Как уже объяснялось ранее, наш формат пакета намеренно не поддерживает триггеры, и мы также недавно полностью отменили устаревшую систему конфигурации. Итак, как мы выполняем необходимые дополнительные изменения после изменения пакета? Мы используем usysconf.
usysconf очень умный, будучи очень глупым, в том, что он не знает пакетов или событий. Вместо этого usysconf будет отслеживать время изменения интересных путей, и когда изменение наблюдается на одном или нескольких из этих путей, соответствующие действия будут выполнены. Однако, обратите внимание, что usysconf один статический бинарник, который не имеет абсолютно никаких конфигурационных файлов. Вместо этого он постепенно применяет интеллектуальные действия, основанные исключительно на этих изменениях, или, более технически, аннулирование системных путей.
Другое ключевое различие между usysconf и традиционными постинсталлами заключается в том, что они запускаются только после завершения транзакции, а не для каждого пакета. Это решает многие условия скорости взаимозависимая между пакетами, гарантируя, что файловая система находится в согласованном, перед применением действий.
Восстановление
Самым основным триггером будет ldconfig, который просто перезапускает ldconfig, когда пути к системной библиотеке становятся недействительными. Однако, это хорошо определенные триггеры в статически связанном, отказоустойчивом двоичном файле. В отличие от традиционных триггеров пакетов, эти действия не скрываются за сценариями или диспетчером пакетов. Вместо этого пользователь может напрямую вызывать двоичный файл для выполнения восстановления системы. Можно вызвать sysconf run-f в chroot для выполнения всех известных триггеров, независимо от состояния недействительности, чтобы вернуть установку к полной работоспособности. Кроме того, sysconf знает, работает ли он в chroot или в реальной среде, поэтому он будет условно выполнять некоторые триггеры. Это означает, usysconf могут быть использованы в нашей установщика, chroot для восстановления сред soilbuild, производства, ICO, и т. д.
Управление загрузкой
Мы считаем недопустимым отправлять любые файлы в / boot в любом пакете Solus. Вместо этого наши ядра живут в /usr / lib / kernel и управляются CLR-boot-manager для продвижения / понижения ядра из загрузочного раздела / directory / ESP. Это позволяет уровень гранулярности не возможно раньше, такие как управление командной строки на ядро, а также всегда имея "старый" ядро к откату, если есть проблемы с недавно обновленным ядром. Это дает нам почти пуленепробиваемую загрузку, когда дело доходит до управления ядром. usysconf автоматически вызвать в CLR-Boot-менеджера во время любой сделки, которая меняет пути ядра, такие как /usr/lib в/ядра или /usr/доли/ядра/командной строки.d. Во время ранней концепции CLR-boot-manager было решено, что инструмент должен быть агностическим и обеспечивать разумный подход к управлению загрузкой, а также некоторый уровень стандартизации двойной загрузки на системном разделе EFI. Таким образом, во избежание конфликтов все загрузочные ресурсы имеют полное пространство имен.
Еще одно заметное различие здесь заключается в том, как мы обрабатываем initramfs (начальная файловая система RAM). В большинстве дистрибутивов Linux это происходит в системе конечных пользователей во время некоторых операций/транзакций после установки, которые могут быть подвержены локальным сбоям (например, недопустимым локальным конфигурациям, нарушающим целевой образ). И наоборот, мы создаем образ initramfs во время компиляции ядра, отправляя эти готовые образы непосредственно пользователям вместе с пакетом ядра. Именно тогда задача clr-boot-managerto продвигать их вместе с ядром в загрузочный раздел / ESP. Это изменение само по себе решило целый ряд проблем для нас, и позволило уровень воспроизводимости и тестирования ранее невозможно с целевыми конкретных изображений.
Управление Драйверами
Другой триггер, который usysconf будет запускать, - это linux-driver-management, когда пути графических драйверов становятся недействительными. В наши дни работа LDM в качестве триггера значительно упрощена, так как мы недавно выкатили обновления для переключения графической архитектуры Souls на использование GLVND. Этот триггер теперь отвечает за управление ранней инициализацией сеанса X11 для устройств Optimus и управление конфигурацией X11 для проприетарных драйверов. По сути, достаточно просто установить правильные драйверы NVIDIA, чтобы автоматически вызывать триггеры и создавать правильные конфигурации. Как и все наши обновления, цель состоит в том, что он работает полностью автоматически. Пользователь просто перезагружается после установки пакетов, и они будут использовать правильную конфигурацию / драйверы без необходимости прикасаться к чему-либо. Кроме того, IBM теперь предоставляет возможности обнаружения оборудования, которые мы будем расширять в Soils 4, чтобы обеспечить поддержку hotplug для предложения драйверов устройств пользователю.
Ahead-of-Time Triggers
usysconf также упаковывает некоторые общие триггеры стиля перед временем, такие как перестроение кэшей шрифтов + значков, когда они недействительны. Совсем недавно мы добавили новый триггер для борьбы с регрессией во время загрузки с AppArmor через наш проект aa-lsm-hook. Это обеспечивает общий, агностический механизм для sanely оборачивать apparmor_parser. В результате мы теперь компилируем кэш AppArmor во время транзакций пакетов и загружаем только двоичный кэш при загрузке. Для дополнительной безопасности мы гарантируем, что a-lsm-hook попытается выполнить перекомпиляцию при загрузке в случае сбоя ранней загрузки. Это было недавно включено в здание нашего ISOs и преобразовало массивную регрессию времени загрузки (1.3 s+) в область 8ms.
System Migrations
Давнишнее преимущество статически версионных релизов заключается в том, что на самом деле базовая ОС не сильно меняется. Это позволяет запускать сценарии миграции во время обновления стиля” dist-upgrade " между основными обновлениями. Прокатные релизы, такие как Solus, традиционно были в невыгодном положении в этой области, так как goalposts может и будет двигаться со временем. Для борьбы с этой проблемой мы создали проект qol-assist, чтобы обеспечить качество жизни для постоянных установок прокатного выпуска. Во время транзакции пакета usysconf может вызвать qol-assist для регистрации триггера миграции, если qol-assist был обновлен. Это эффективно создает файл триггера на диске, чтобы сообщить systemd, что модуль QoL должен быть запущен во время ранней загрузки (sysinit.цель.) При запуске этого модуля он определит состояние миграции (целочисленная версия) системы и применит все отложенные миграции, прежде чем, наконец, сохранить новую версию миграции системы. Это гарантирует, что нам не нужно снова запускать старые триггеры, однако все триггеры сначала проверят, нужны ли они.
Используя эту версионную систему триггера миграции, мы прозрачно исправили проблемы в существующих установках Solus просто через процедуру update + reboot. Примеры некоторых миграций, которые возникли с течением времени:
Автоматический перенос динамических пользователей, выделенных systemd, в фиксированный gid 100 (также теперь параметр systemd configure time)
Автоматически поместил всех активных пользователей admin в систему в новую группу сканеров для исправления регрессии sane-backends.
Последний пример довольно интересен с архитектурной точки зрения; группа сканеров не существовала в Solus, когда мы выпустили Solus 3, поэтому у пользователей не было абсолютно никаких шансов автоматически стать частью этой группы. Вместо этого мы исправили эту проблему, проталкивая группу сканеров к системам через фрагмент systemd sysusers (автоматически выполняемый usysconf) и предоставил триггер qol-assist для размещения пользователей в эту группу, если они еще не были членами, а также считались “администратором” и “активными”. Это мощный инструмент для любого прокатного выпуска дистрибутива, что позволяет нам исправлять проблемы, которые, как правило, требуют ручного вмешательства или нового выпуска.
Немного противоречивые решения
Для того, чтобы помочь упорядочить некоторые элементы Solus, мы приняли некоторые решения, которые могут считаться спорными в других областях.
No DKMS
Solus не поддерживает и не будет поддерживать DKMS. Вместо этого мы отправляем две ветви ядра, linux-current и linux-lts, со всеми нашими пакетами модулей ядра, построенными в тандеме с нашими ядрами. Это гарантирует, что модули ядра (построенные из дерева) всегда будут работать с нашими ядрами, и нет никакого риска, связанного с локальной перекомпиляцией с использованием DKMS. Например, если пользователь устанавливает nvidia-glx-driver-current, это предоставляет модули только для linux-current. Они встроены в нестабильный linux-current и будут выпущены в виде обновления вместе с ядром.
Дополнительно с нашей интеграцией clr-boot-manager, эти нажаты в такое же дерево модуля на диске, обеспечивающ старое .ko файлы по-прежнему присутствуют для резервных ядер между обновлениями, что позволяет пользователям откат к старой рабочей ядра, если проблема возникает с более новым ядром. Они автоматически очищаются с течением времени. Каждое обновление ядра Solus уникально вплоть до номера выпуска, что позволяет пользователям загружать последнюю сборку ядра.
Avoiding “three-way-merge” Config Hell
По умолчанию многие части Souls постепенно переходят в конфигурацию без отслеживания состояния. На самом базовом уровне мы разделяем домены конфигурации на OS, Data, Admin. Основная предпосылка заключается в том, что материал, который на самом деле не требует настройки для запуска, не должен иметь их, и все программное обеспечение должно функционировать в отсутствие пользовательской конфигурации. Во многих местах мы используем конфигурацию по умолчанию, которая” принадлежит " ОС, но может быть переопределена пользователями/администрациями. Это гарантирует, что их конфигурация отделена от ОС, позволяя откаты и сброс, а также избежать страшных интерактивных слияний конфигурации при обновлении. Или " кто действительно владеет /etc?". Это еще не идеально в Souls, и мы стремимся улучшить это с течением времени с введением инструментов управления конфигурацией, а также краткой документации/политик.
Избежать конфликтов
В качестве проектного решения мы активно избегаем пакетов, которые конфликтуют друг с другом. Это означает, что в Solus Вы не найдете систем стилей с альтернативными обновлениями, и только один пакет может владеть каждым путем. В результате не существует конкретной ситуации, когда пакет может зависеть от одного или нескольких поставщиков данной библиотеки или интерфейса, все они должны быть удовлетворены исключительно. Мы разрешаем пакеты, которые sanely сосуществуют, но мы не допускаем дублирования данного поставщика soname или pkgconfig между пакетами. Таким образом, ПНГ, один JPEG и т. д.
Единственные заметные исключения из этого правила прямо сейчас:
Проприетарные драйверы NVIDIA (как дизайнерское решение для обеспечения активного использования одного драйвера NVIDIA)
Дисплейные менеджеры (LightDM / SDDM / GDM). Со временем мы позволим им сосуществовать с переключателем для изменения предпочтительного DM со встроенными весами.
Можно утверждать, что кульминация этих правил может показаться чрезмерно враждебной свободному движению, однако реальный результат заключается в том, что он заставляет разработчиков рассматривать, как их пакеты будут работать с самого начала и как они будут вести себя при обновлении. Для пользователей они получают согласованный опыт установки и обновления, не сталкиваясь с интерактивными диалогами настройки / страшного удаления, и все “просто работает”.
Управление пакетами "Доставка”
Мы просто используем управление пакетами для доставки программного обеспечения и обновлений, и некоторые области системы находятся вне управления менеджера пакетов, и действительно, пользователя. Примером этого является Управление /boot с помощью CLR-boot-manager. Обновления доставляются в /usr / lib / kernel, и /boot управляется исключительно CLR-boot-manager. Таким образом, различные области Solus подпадают под различные области, и управление пакетами само по себе не может рассматриваться как единственное решение или функция продажи хорошо интегрированной операционной системы - вместо этого он образует один элемент в конвейере доставки.
Fixing the “stupid”
Следует отметить, что мы не тратим каждую минуту на размышления о том, как переработать нашу архитектуру, как правило, она развивается из реальных проблем. Однако, давняя тема заключалась в том, чтобы ”исправить глупость", т. е. атаковать низко висящие фрукты и отбросить наследие cruft из системы. С учетом сказанного, было бы неразумно слепо запускать эти проекты, поэтому мы используем этот подход только в сочетании с очень важной частью философией Solus: Давай исправим это в последний раз.
Следовательно, большинство наших проектов в настоящее время написаны агностическим образом, которые ищут решение проблемы в последний раз, в то время как атакуют корневую проблему в реальном мире развертывания Solus (“глупый”). Некоторые незначительные примеры могли бы быть нашим недавним преобразованием нашего управления CPU по требованию от дорогих сценариев bash к C или даже введением usysconf для замены традиционных триггеров. В любом случае конечный результат тот же, система постоянно совершенствуется для конечного пользователя, становится более надежным с течением времени, и сосредоточиться на вопросах, которые на самом деле имеют значение.
Подытоживая статью
Эта статья кратко коснулась некоторых невидимых компонентов архитектуры Souls и, надеюсь, должна выделить некоторые из основных различий между Solus и” традиционным " распределением. Важно помнить некоторые очень важные идеи в философии души :
ОС должна знать, как ухаживать за собой.
Агностик код водит к главным дизайну и качеству.
ОС должна держаться подальше от пользователя
ОС должна облегчать, а не затруднять работу пользователя.
Целью ОС является безопасное, надежное и прозрачное включение рабочих нагрузок для пользователя.
Инструменты имеют значение. Если процесс сосет, то tooling нужно быть улучшенным.
Никакая часть Solus не священна. Если области в душах найдены желающими, они могут и будут изменены/заменены. (соль…)
Все должно “просто работать”
Обращение переводчика и основателя русскоязычного сообщества Solus
На перевод данной статьи ушло не мало времени, и под конец я уже сдался, по этому в 40% текста кривой перевод. Оригинал содержит свыше 20.000 символов и 5.000 слов. Прошу вас обратить внимание на эту проблему, и если вам не сложно, то помочь её решить. Пишите мне в телеграмм, и по возможности я буду давать небольшие тексты. Само собой, вы будете указаны как переводчик.
Личный контакт для связи — t.me/plagness
Русскоязычное сообщество по SolusOS
Официальная группа: vk.com/solusosru
Новостной канал: t.me/solusosru
Разговорный чат, где можно задавать вопросы: t.me/solusosru_chat
Stereolubov и Alexniakris, не удаляйте пожалуйста. Данная статься находится в категории рандома и довольно полезная к ознакомлению. Теперь на форум я буду заливать только полноценные статьи.
