бета для linux deb x64 что это
Яндекс.Браузер для Linux
Яндекс браузер — активно развивающийся сервис, который пользуется большой популярностью. Поддерживается большинством операционных систем. И если на windows вопросов по установке не возникает, то в случае с системами linux могут возникнуть трудности. Как установить yandex браузер для линукс?
Отличия версии для linux и windows
Обновления для linux-версии браузера появляются после windows-версии, поэтому возможны незначительные отличия. Однако базовый функционал присутствует:
Обычно версия для линукс имеет пометку “Бета”. В этом нет ничего страшного. Учитывая то, что пользователей линукс-версии гораздо меньше, выявить ошибки в работе приложения сложнее. Отмечая продукт пометкой “Бета”, компания показывает, что над продуктом активно ведутся работы по выявлению и устранению ошибок.
Дистрибутивы linux
Linux – это не операционная система, как многие ошибочно считают, это целое семейство Unix-подобных систем, которые могут сильно отличаться. К самым популярным дистрибутивам относятся:
Linux-системы уникальны тем, что загружать установочные файлы можно двумя способами — классическим и через консоль. В большинстве случаев это пакеты с форматом deb или rpm. По способу установки они почти не отличаются.
Установка пакетов с форматом deb
Приложения с форматом deb предназначены для linux-систем, основанных на Debian. Например, чтобы установить яндекс браузер на Ubuntu, нужно просто скачать deb версию приложения, и провести стандартные действия. Ubuntu поддерживает графическую версию установщика, поэтому проблем возникнуть не должно.
Приложение можно скачать и установить через консоль, введя следующие команды:
Если в консоли не будет ошибок, значит браузер установлен.
В случае, если инсталляция не была проведена успешно, нужно ввести в командную строку следующее:
Команда проводит установку новейших версий всех пакетов, которые есть в системе на данный момент. После обновления можно повторить попытку.
Скачивание и установка пакетов формата rpm
Файл с форматом rpm предназначен для систем Red Hat, Fedora и тд. Чтобы установить яндекс браузер на линукс системы с поддержкой пакетов rpm, нужно скачать приложение и ввести в консоль команду:
Запустить приложение можно через основное меню или в командной строке:
Помимо этого способа, можно кликнуть правой кнопкой мыши по установочному пакету и выбрать “Открыть с помощью другого приложения”, после выбрать менеджер установки пакетов и провести инсталляцию. Однако этот способ может не работать и выдавать ошибку.
Популярная ошибка при установке
У некоторых пользователей во время инсталляции появляется ошибка “appindicator1”. Для ее устранения нужно самостоятельно скачать библиотеку python-appindicator. Сделать это можно, введя команду в консоли:
После корректной установки библиотеки проблема исчезнет и можно повторить попытку.
Выводы
Yandex легко устанавливается на linux-системы, даже с учетом того, что необходимых пакетов нет в репозитории. Сложности могут возникнуть при использовании малоизвестных дистрибутивов, на даже в таких ситуациях в интернете можно найти решение проблемы.
В чём разница между Debian и Ubuntu? Что лучше выбрать?
Поговорим о Debian и Ubuntu. И там, и там можно использовать команды apt-get для управления приложениями. Оба дистрибутива поддерживают установку DEB-пакетов. Часто, читая статьи про Linux, можно видеть, что для Debian и Ubuntu подходят одни и те же инструкции по установке каких-то программ.
Чем же, при такой близости друг к другу, различаются эти дистрибутивы?
«Дистрибутив Ubuntu основан на Debian», — что это значит?
Хотя и существуют сотни дистрибутивов Linux, лишь немногие из них являются независимыми, то есть, созданными с чистого листа. Среди крупнейших независимых дистрибутивов можно отметить Debian, Arch Linux, Red Hat.
Дистрибутив Ubuntu основан на Debian. Это значит, что Ubuntu использует тот же механизм работы с пакетами (APT), что и Debian, и то, что в Ubuntu применяется очень много пакетов и библиотек из репозиториев Debian. В качестве базы для Ubuntu используется инфраструктура Debian.
Базой для Ubuntu является Debian
Именно так выглядят взаимоотношения большинства Linux-дистрибутивов с теми дистрибутивами, на которых они основаны. Они используют ту же систему управления пакетами и те же пакеты, что и базовый дистрибутив. Но они, кроме того, добавляют к существующим пакетам свои пакеты. Именно в этом и кроется отличие Ubuntu от Debian, несмотря на то, что ОС Ubuntu основана на Debian.
Различия между Ubuntu и Debian
Итак, ОС Ubuntu построена на базе архитектуры и инфраструктуры Debian, она использует те же DEB-пакеты, что и Debian.
Значит ли это, что пользоваться Ubuntu — это то же самое, что и пользоваться Debian? Не совсем. Существует множество дополнительных факторов, которые отличают один дистрибутив от другого.
Обсудим эти факторы и, таким образом, сравним Ubuntu и Debian. Прежде чем мы начнём — прошу помнить о том, что некоторые сравнения применимы к настольному варианту ОС, а некоторые — к серверному.
▍1. Цикл выпуска
Существует два вида выпусков Ubuntu — LTS ( Long Term Support, «поддержка в течение длительного периода») и обычные. LTS-выпуски выходят каждые два года, они поддерживаются в течение 5 лет. При обновлении системы у пользователя есть возможность обновиться до следующего доступного LTS-выпуска. Такие выпуски считаются более стабильными, чем обычные.
Каждые шесть месяцев выходят обычные выпуски Ubuntu, не относящиеся к категории LTS. Их поддержка осуществляется лишь в течение девяти месяцев, но в них имеются более новые, в сравнении с последним LTS-выпуском, версии ПО и возможности. Когда заканчивается жизненный цикл используемого обычного выпуска — нужно обновиться до следующей версии Ubuntu.
В результате у того, кто пользуется Ubuntu, учитывая особенности выхода её выпусков, есть возможность выбирать между стабильностью и новыми возможностями.
А вот у Debian имеется три вида выпусков: стабильные (Stable), тестируемые (Testing) и нестабильные (Unstable). Нестабильные выпуски предназначены для «полевых» испытаний, для реальной работы ими лучше не пользоваться.
А тестируемые выпуски не так уж и нестабильны. Соответствующая ветка используется для подготовки следующего стабильного выпуска. Некоторые пользователи Debian выбирают именно Testing-выпуски для того чтобы быстрее других получить доступ к новым возможностям.
И наконец — скажем пару слов о стабильных выпусках Debian. Это — основные выпуски Debian. Они могут не отличаться наличием в них самого нового ПО или самых новых возможностей, но, если говорить о стабильности, то можно сказать, что они исключительно стабильны.
Новый стабильный выпуск выходит раз в два года. Такие выпуски поддерживаются в течение трёх лет. После этого нужно обновляться до нового стабильного выпуска.
▍2. Свежесть программного обеспечения
Команда apt-cache policy
Ориентированность ОС Debian на стабильность означает то, что разработчики системы не всегда стремятся к тому, чтобы включать в неё самые свежие версии программного обеспечения. Например, в самой свежей Debian 11 используется GNOME 3.38, а не последняя GNOME 3.40.
То же самое касается и другого ПО — вроде GIMP, LibreOffice и так далее. Это — тот компромисс, на который вынужден идти тот, кто выбирает Debian. Именно поэтому в сообществе Linux популярна шутка «Debian stable = Debian stale», намекающая на то, что стабильная Debian — это Debian не первой свежести.
Выпуски Ubuntu LTS тоже нацелены на стабильность. Но в них обычно используются более актуальные, чем в Debian, версии популярного ПО.
Стоит обратить внимание на то, что то же самое справедливо и для некоторых программ, устанавливаемых из репозиториев, поддерживаемых разработчиками ОС. В результате, например, если вам нужна самая последняя версия Docker — можно добавить репозиторий Docker и в Debian, и в Ubuntu.
В целом же можно отметить, что в стабильных выпусках Debian обычно используются более старые версии ПО, чем в сравнимых выпусках Ubuntu.
▍3. Доступность программного обеспечения
И Debian, и Ubuntu имеют огромные репозитории программного обеспечения. Но у Ubuntu есть ещё и PPA (Personal Package Archive). Благодаря PPA процедура установки более новых программ или свежих версий уже имеющихся программ немного облегчается.
Использование команды add-apt-repository
Использовать PPA можно и в Debian, но это не так удобно, как в Ubuntu. В Debian это обычно сопряжено с некоторыми проблемами.
▍4. Поддерживаемые платформы
Доступны варианты дистрибутива Ubuntu для 64-битных платформ x86 и ARM. В рамках проекта больше не выпускаются 32-битные образы ОС.
А Debian, с другой стороны, поддерживает и 32-битные и 64-битные архитектуры. Кроме того, Debian поддерживает ещё и 64-битную архитектуру ARM (arm64), и ARM EABI (armel), и ARMv7 (EABI hard-float ABI, armhf), и 32-битную архитектуру MIPS с обратным порядком байтов (mipsel), и 64-битную архитектуру MIPS с обратным порядком байтов (mips64el), и 64-битную архитектуру PowerPC с обратным порядком байтов (ppc64el), и IBM System z (s390x).
В результате — неудивительно то, что Debian называют «универсальной операционной системой».
▍5. Установка
Установка Ubuntu гораздо проще, чем установка Debian. И я, говоря это, не шучу. Установка Debian может вызвать сложности даже у пользователей Linux среднего уровня подготовки.
После загрузки дистрибутива Debian в распоряжении пользователя, по умолчанию, оказывается минимальный ISO. В состав этого образа не входят прошивки, не являющиеся опенсорсными. В результате пользователю надо самому установить соответствующие прошивки, и учитывать то, что система не распознает автоматически его сетевые адаптеры и другое аппаратное обеспечение.
Есть и особые ISO, содержащие код подобных прошивок, но для того чтобы их найти — надо знать где искать. В результате тот, кто этого не знает, может столкнуться с неприятным сюрпризом.
Не самая дружелюбная процедура самостоятельной загрузки прошивки в Debian
Команда разработчиков Ubuntu гораздо снисходительнее относится к включению в состав стандартного дистрибутива драйверов и прошивок с закрытым исходным кодом.
Кроме того, установщик Debian выглядит устаревшим, чего не скажешь об установщике Ubuntu. Установщик Ubuntu, кроме того, распознаёт другие ОС, установленные на диске, и предлагает пользователю возможность установки Ubuntu совместно с уже установленными системами (с возможностью сформировать конфигурацию двойной загрузки). А вот исследуя установку Debian я ничего такого не заметил.
Установка Ubuntu проходит гораздо приятнее, чем установка Debian
▍6. Встроенная поддержка различного аппаратного обеспечения
ОС Debian, как уже было сказано, ориентирована, преимущественно на FOSS (Free and Open Source Software, свободное и открытое программное обеспечение). Это означает, что ядро, предоставляемое Debian, не содержит драйверов и прошивок с закрытым кодом.
Это не значит, что такие драйверы и прошивки нельзя заставить работать в Debian. Всё дело в том, что пользователю придётся самостоятельно добавлять или включать соответствующие репозитории и вручную устанавливать то, что ему нужно. Это может, особенно у новичков, отбить желание пользоваться Debian.
Нельзя сказать, что Ubuntu — это совершенная ОС, но, в деле встроенной поддержки различных аппаратных устройств, она гораздо лучше Debian. Это означает, что Ubuntu легче привести в рабочее состояние, и то, что пользователю будет, с самого начала, удобнее работать с этой ОС, чем с Debian.
▍7. Выбор окружения рабочего стола
В Ubuntu, по умолчанию, используется специально настроенное окружение рабочего стола GNOME. Поверх него можно установить другое окружение, или выбрать какой-то вариант Ubuntu с другим окружением рабочего стола — вроде Kubuntu (там используется KDE) или Xubuntu (Xfce).
В Debian тоже, по умолчанию, устанавливается GNOME. Но установщик даёт пользователю возможность самому выбрать окружение рабочего стола.
Выбор окружения рабочего стола при установке Debian
С сайта Debian можно скачать образы, рассчитанные на установку определённого окружения рабочего стола.
▍8. Игры
В последнее время ситуация с играми в Linux, в целом, улучшилась, что произошло благодаря Steam и Proton. Но возможность запуска игр, конечно, сильно зависит и от аппаратного обеспечения.
Если говорить о совместимости ОС с аппаратным обеспечением, то Ubuntu лучше Debian справляется с поддержкой проприетарных драйверов.
Нельзя сказать, что того же, что способна дать Ubuntu, нельзя достичь в Debian, но на это потребуется потратить некоторое время и некоторые силы.
▍9. Производительность
Если говорить о производительности, то чёткого ответа на вопрос о том, что быстрее — Ubuntu или Debian — нет. Причём, это справедливо и для настольных систем, и для серверов. И та и другая операционные системы популярны как на настольном, так и на серверном фронтах.
Производительность компьютера зависит от его аппаратных возможностей и от набора установленного на нём программного обеспечения. Настраивать параметры системы, оптимизируя её производительность, можно и в Ubuntu, и в Debian.
▍10. Сообщество и поддержка
Debian — это истинный продукт трудов сообщества разработчиков. Всё, что касается управления этим проектом, находится в ведении членов сообщества.
За Ubuntu стоит компания Canonical. Но это — не тот проект, который поддерживает исключительно некая корпорация. Вокруг Ubuntu тоже сформировалось сообщество разработчиков. Но окончательные решения по любым вопросам, касающимся Ubuntu, принимает именно Canonical.
Если же говорить о поддержке, то существуют специализированные форумы, на которых можно получить помощь и по Ubuntu, и по Debian.
Canonical, кроме того, предлагает профессиональную поддержку своим корпоративным клиентам. Разработчики Debian такой поддержки не предлагают.
Итоги
И Debian, и Ubuntu — это отличный выбор как для настольного компьютера, так и для сервера. Эти ОС используют менеджер пакетов apt и DEB-пакеты, и, в результате, дают своим пользователям очень похожие возможности.
Но для эффективного использования Debian нужен некоторый опыт. Особенно — если речь идёт о настольном варианте ОС. Если вы только начинаете осваивать мир Linux — то вам лучше будет остановить свой выбор на Ubuntu. Я полагаю, что новичкам, прежде чем перейти к Debian, нужно наработать некоторый опыт и познакомиться с Linux в целом.
Нельзя сказать, что знакомство с Linux нельзя начать с Debian, но такое начало, вероятнее всего, станет для новичка серьёзным испытанием.
Как вы выбираете дистрибутивы Linux для настольных компьютеров и для серверов?
Linux многоликий: как работать на любом дистрибутиве
Создать приложение для резервного копирования, работающее на любом дистрибутиве — задачка непростая. Чтобы обеспечить работу Veeam Agent for Linux на дистрибутивах от RHEL 6 и Debian 6, до openSUSE Leap 15.1 и Ubuntu 19.04 приходится решать спектр проблем, особенно если учесть, что в состав программного продукта входит модуль ядра.
Статья создана по материалам выступления на конференции LinuxPiter 2019.
Linux — это не просто одна из самых популярных ОС. По сути, это платформа, на базе которой можно сделать что-то уникальное, что-то своё. Благодаря этому у Linux множество дистрибутивов, которые отличаются набором программных компонентов. И тут возникает проблема: чтобы программный продукт функционировал на любом дистрибутиве, приходится учитывать особенности каждого.
Начнём с очевидной проблемы распространения продукта для разных дистрибутивов.
Самый типичный способ распространения программных продуктов — это выложить пакет на репозиторий, чтобы встроенный в систему пакетный менеджер смог его оттуда установить.
Однако популярных форматов пакетов у нас два: rpm и deb. Значит, придётся поддержать каждый.
В мире deb-пакетов уровень совместимости поразителен. Один и тот же пакет одинаково хорошо ставится и работает как на Debian 6, так и на Ubuntu 19.04. Стандарты процесса построения пакетов и работы с ними, заложенные в старых Debian дистрибутивах, остаются актуальными и в новомодных Linux Mint и elementary OS. Поэтому в случае Veeam Agent for Linux достаточно одного deb-пакета для каждой аппаратной платформы.
А вот в мире rpm-пакетов различия велики. Во-первых, из-за того, что есть два совершенно независимых дистрибьютера Red Hat и SUSE, для которых совершенно не нужна совместимость. Во-вторых, у этих дистрибьютеров есть дистрибутивы с тех. поддержкой и экспериментальные. Между ними совместимость тоже не нужна. У нас получилось, что для el6, el7 и el8 свои пакеты. Отдельно пакет для Fedora. Пакеты для SLES11 и 12 и отдельный для openSUSE. Основная проблема — в зависимостях и именах пакетов.
Проблема зависимостей
В результате список зависимостей оказывается уникальным для дистрибутива.
Хуже бывает, когда под старым именем пакета начинает прятаться обновлённая версия.
В Fedora 24 обновился пакет ncurses c версии 5 до версии 6. Наш продукт собирался именно с 5-той версией, для обеспечения совместимости со старыми дистрибутивами. Чтобы воспользоваться старой 5-той версией библиотеки на Fedora 24, пришлось использовать пакет ncurses-compat-libs.
В результате для Fedora появляется два пакета, с разными зависимостями.
Дальше интереснее. После очередного обновления дистрибутива пакет ncurses-compat-libs с 5-той версией библиотеки оказывается недоступным. Для дистрибьютера накладно тянуть старые библиотеки в новую версию дистрибутива. Спустя некоторое время проблема повторилась и в дистрибутивах SUSE.
В результате для некоторых дистрибутивов пришлось отказаться от явной зависимости от ncurses-libs, а продукт поправить так, чтобы он мог работать с любой версией библиотеки.
Кстати, в 8-й версии Red Hat больше нет мета-пакета python, который ссылался на старый добрый python 2.7. Есть python2 и python3.
Альтернатива пакетным менеджерам
Проблема с зависимостями стара и давно очевидна. Вспомнить хотя бы Dependency hell.
Объединить разнообразные библиотеки и приложения так, чтобы все они стабильно работали и не конфликтовали — собственно, эту задачу и пытается решать любой дистрибьютор Linux.
Совсем иначе пытается решать эту проблему пакетный менеджер Snappy от Canonical. Основная идея: приложение выполняется в изолированной и защищённой от основной системы песочнице. Если приложению нужны библиотеки, то они поставляются вместе с самим приложением.
Flatpak также позволяет запускать приложения в песочнице, используя Linux Containers. Есть ещё AppImage, который позволяет создавать портативные образы программ.
Эти решения позволяют создавать один пакет для любых дистрибутивов. В случае с Flatpak и AppImage установка и запуск приложения возможна даже без ведома администратора.
Основная проблема в том, что не все приложения могут работать в песочнице и без root привилегий. Некоторым нужно прямое обращение к платформе. Я уж не говорю про модули ядра, которые жёстко зависят от ядра и никак не вписываются в концепцию песочницы.
Вторая проблема – популярные в enterprise-среде дистрибутивы от Red Hat и SUSE ещё не содержат поддержку Snappy и Flatpak.
В связи с этим Veeam Agent for Linux нет ни на snapcraft.io ни на flathub.org.
В завершение вопроса о пакетных менеджерах замечу, что есть вариант отказаться вовсе от пакетных менеджеров, объединив в один пакет бинарные файлы и скрипт для их установки.
Такой bundle позволяет создать один общий пакет для разных дистрибутивов и платформ, производить интерактивный процесс установки, осуществляя необходимую кастомизацию. Я сталкивался с такими пакетами для Linux только от VMware.
Проблема обновлений
Даже если все проблемы с зависимостями решены, программа может работать по-разному на одном и том же дистрибутиве. Дело в обновлениях.
Есть 3 стратегии обновления:
Разнообразие аппаратных платформ
Различные аппаратные платформы – это проблема, в значительной степени специфичная именно для native-кода. Как минимум, приходится собирать бинарники для каждой поддерживаемой платформы.
В проекте Veeam Agent for Linux мы всё никак не можем поддержать хоть что-нибудь такое RISC-овое.
Статическая и/или динамическая линковка
А вот вопрос «Как линковаться с библиотеками — динамически или статически?» стоит обсудить.
Как правило, С/С++ приложения под Linux используют динамическую линковку. Это отлично работает в том случае, если приложение собрано специально под конкретный дистрибутив.
Если же стоит задача охватить разнообразные дистрибутивы одним бинарным файлом, то приходится ориентироваться на самый старый поддерживаемый дистрибутив. Для нас это Red Hat 6. Он содержит gcc 4.4, который даже стандарт С++11 поддерживает не полностью.
Мы собираем наш проект с помощью gcc 6.3, который полностью поддерживает C++14. Естественно, в таком случае на Red Hat 6 библиотеку libstdc++ и boost приходится тащить с собой. Проще всего линковаться с ними статически.
Но увы, не со всеми библиотеками можно линковаться статически.
Во-первых, системные библиотеки, такие как libfuse, libblkid необходимо линковать динамически, чтобы быть уверенным в совместимости их с ядром и его модулями.
Во-вторых, есть тонкость с лицензиями.
Линцензия GPL в принципе разрешает линковать библиотеки только с opensource кодом. MIT и BSD разрешают статическую линковку и позволяют включать библиотеки в проект. А вот LGPL вроде как не противоречит статической линковке, но требует предоставить в общий доступ файлы, необходимые для связывания.
В общем случае использование динамической линковки обезопасит от необходимости что-то предоставлять.
Сборка С/С++ приложений
Для сборки С/С++ приложений для разных платформ и дистрибутивов достаточно подобрать или собрать gcc подходящей версии и воспользоваться кросс-компиляторами для специфичных архитектур, собрать весь набор библиотек. Работа эта вполне реализуемая, но довольно хлопотная. И нет никаких гарантий, что выбранный компилятор и библиотеки обеспечат работоспособный вариант.
Очевидный плюс: сильно упрощается инфраструктура, так как весь процесс сборки можно выполнить на одной машине. Кроме того, достаточно собрать один набор бинарных файлов для одной архитектуры и можно паковать их в пакеты для разных дистрибутивов. Именно так собираются пакеты veeam для Veeam Agent for Linux.
В противовес этому варианту можно просто подготовить build ферму, то есть несколько машин для сборки. Каждая такая машина будет обеспечивать компиляцию приложения и сборку пакета для конкретного дистрибутива и определённой архитектуры. В таком случае компиляция производится теми средствами, которые подготовил дистрибьютер. То есть этап подготовки компилятора и подбор библиотек отпадает. Кроме того, процесс сборки может быть легко распараллелен.
Есть, правда, и минус у такого подхода: для каждого дистрибутива в рамках одной архитектуры придётся собирать свой набор бинарных файлов. Также минусом является то, что такое множество машин нужно обслуживать, выделять большое количество дискового пространства и оперативной памяти.
Таким образом собираются KMOD пакеты модуля ядра veeamsnap под дистрибутивы Red Hat.
Open Build Service
Коллеги из SUSE попробовали реализовать некоторую золотую середину в виде специального сервиса для компиляции приложений и сборки пакетов — openbuildservice.
По сути, это гипервизор, который создаёт виртуальную машину, устанавливает в ней все необходимые пакеты, выполняет компиляцию приложения и сборку пакета в этой изолированной среде, после чего такая виртуальная машина освобождается.
Реализованный в OpenBuildService планировщик сам определит, сколько виртуальных машин он может запустить для оптимальной скорости сборки пакетов. Встроенный механизм подписи сам подпишет пакеты и выложит их на встроенный репозиторий. Встроенная система версионного контроля сохранит историю изменений и сборок. Остаётся просто добавить в эту систему свои исходники. Даже сервер самому поднимать не обязательно, а можно воспользоваться открытым.
Тут, правда, есть проблема: такой комбайн трудно вписывается в существующую инфраструктуру. Например, версионный контроль не нужен, у нас уже есть свой для исходников. Механизм подписи у нас отличается: используется специальный сервер. Репозиторий тоже не нужен.
Кроме того, поддержка других дистрибутивов — к примеру, Red Hat — реализована довольно скудно, что вполне объяснимо.
Достоинством такого сервиса является быстрая поддержка очередной версии дистрибутива SUSE. До официального объявления о релизе необходимые для сборки пакеты выкладываются на публичный репозиторий. В списке доступных дистрибутивов на OpenBuildService появляется новый. Выставляем галочку, и он добавляется в план сборки. Таким образом, добавление новой версии дистрибутива выполняется практически в один клик.
В нашей инфраструктуре с использованием OpenBuildService собирается всё многообразие KMP пакетов модуля ядра veeamsnap для дистрибутивов SUSE.
Далее я хотел бы остановиться на вопросах, специфичных именно для модулей ядра.
kernel ABI
Модули ядра Linux исторически распространялись в виде исходных текстов. Дело в том, что создатели ядра не обременяют себя заботой о поддержке стабильного API для модулей ядра, а тем более на бинарном уровне, далее kABI.
Чтобы собрать модуль для ванильного ядра, обязательно нужны header-ы именно этого ядра, и работать он будет только на этом ядре.
DKMS позволяет автоматизировать процесс сборки модулей при обновлении ядра. В результате пользователи репозитория Debian (и его многочисленных родственников) используют модули ядра либо из репозитория дистрибьютера, либо собираемые из исходников с помощью DKMS.
Однако такая ситуация не особо устраивает Enterprise-сегмент. Распространители проприетарного кода хотят распространять продукт в виде собранных бинарников.
Администраторы не хотят держать средства разработки на production-серверах из соображений безопасности. Дистрибьютеры Enterprise Linux — такие, как Red Hat и SUSE — решили, что для своих пользователей стабильное kABI они смогут поддержать. В результате появились KMOD пакеты для Red Hat и KMP пакеты для SUSE.
Суть такого решения довольно проста. Для конкретной версии дистрибутива API ядра freeze-ится. Дистрибьютор заявляет, что он использует именно ядро, например, 3.10, и вносит только исправления и улучшения, которые никак не затрагивают интерфейсы ядра, а собранные для самого первого ядра модули могут быть использованы для всех последующих без перекомпиляции.
Red Hat заявляют о kABI совместимости для дистрибутива на протяжении всего жизненного цикла. То есть собранный модуль для rhel 6.0 (релиз ноября 2010) должен также работать и на версии 6.10 (релиз июня 2018). А это почти 8 лет. Естественно, задача это довольно сложная.
Мы зафиксировали несколько случаев, когда из-за проблем с kABI совместимостью модуль veeamsnap переставал работать.
После того, как модуль veeamsnap, собранный для RHEL 7.0, оказался несовместим с ядром из RHEL 7.5, но при этом загружался и гарантированно ронял сервер, мы отказались от использования kABI совместимости для RHEL 7 вообще.
В настоящий момент KMOD пакет для RHEL 7 содержит сборку для каждой версии релиза и скрипт, который обеспечивает загрузку модуля.
SUSE к задаче kABI совместимости подошли более осторожно. Они обеспечивают kABI совместимость только в рамках одного service pack.
Например, релиз SLES 12 состоялся в сентябре 2014. А SLES 12 SP1 уже в декабре 2015, то есть прошло чуть больше года. Несмотря на то, что оба релиза используют ядро 3.12, они kABI несовместимы. Очевидно, что поддерживать kABI совместимость в течение всего лишь года значительно проще. Годовой цикл обновления модуля ядра не должен вызывать проблем у создателей модулей.
В результате такой политики SUSE мы не зафиксировали ни одной проблемы с kABI совместимостью у нашего модуля veeamsnap. Правда, и число пакетов для SUSE почти на порядок больше.
Патчи и бэкпорты
Несмотря на то, что дистрибьютеры стараются обеспечить kABI совместимость и стабильность ядра, они ещё и стараются улучшить производительность и устранить дефекты этого стабильного ядра.
При этом кроме собственной «работы над ошибками» разработчики ядра enterprise linux отслеживают изменения в ванильном ядре и переносят их в своё «стабильное».
Иногда это приводит к новым ошибкам.
В последнем релизе Red Hat 6 в одном из минорных обновлений была допущена ошибка. Она приводила к тому, что модуль veeamsnap гарантированно валил систему при освобождении снапшота. Сравнив исходники ядра до и после обновления, мы выяснили, что виной всему был backport. Аналогичный фикс был произведён в ванильном ядре версии 4.19. Вот только в ванильном ядре этот фикс работал нормально, а при переносе его в «стабильное» 2.6.32 возникла проблема со спин-блокировкой.
Конечно, ошибки встречаются у всех и всегда, но стоило ли тащить код из 4.19 в 2.6.32, рискуя стабильностью. Я не уверен…
Хуже всего, когда к перетягиванию каната «стабильность» «модернизация» подключается маркетинг. Отделу маркетинга нужно, чтобы ядро обновлённого дистрибутива был стабильным, с одной стороны, и в тоже время было лучше по производительности и имело новые функции. Это приводит к странным компромиссам.
Когда я попробовал собрать модуль на ядре 4.4 от SLES 12 SP3, я с удивлением обнаружил в нём функционал из ванильного 4.8. На мой взгляд, реализация блочного ввода/вывода ядра 4.4 от SLES 12 SP3 больше походит на ядро 4.8, чем на предыдущий релиз стабильного 4.4 ядра от SLES12 SP2. Каков был процент перенесённого кода из ядра 4.8 в SLES-овский 4.4 для SP3 я судить не берусь, однако назвать ядро всё тем же стабильным 4.4 у меня язык не поворачивается.
Самое неприятное в этом то, что при написании модуля, который бы одинаково хорошо работал на разных ядрах, более нельзя опираться на версию ядра. Приходится ещё и учитывать дистрибутив. Хорошо, что иногда можно завязаться на дефайн, который появляется вместе с новым функционалом, однако такая возможность появляется не всегда.
В результате код обрастает причудливыми директивами условной компиляции.
Встречаются ещё и патчи, которые меняют задокументированное API ядра.
Наткнулся на дистрибутив KDE neon 5.16 и был очень удивлён, увидев что вызов lookup_bdev в этой версии ядра изменил перечень входных параметров.
Чтобы собраться, пришлось в makefile добавлять скрипт, который проверяет, есть ли параметр mask у функции lookup_bdev.
Подпись модулей ядра
Но вернёмся к вопросу распространения пакетов.
Одно из достоинств стабильного kABI в том, что модули ядра в виде бинарного файла можно подписать. В этом случае разработчик может быть уверен, что модуль не был случайно повреждён или намеренно изменён. Проверить это можно командой modinfo.
Дистрибутивы Red Hat и SUSE позволяют проверять подпись модуля и загружать его, только если в системе зарегистрирован соответствующий сертификат. Сертификат представляет собой публичный ключ, которым подписывается модуль. Мы распространяем его в виде отдельного пакета.
Проблема тут в том, что сертификаты могут быть либо встроенные в ядро (их используют дистрибьютеры), либо должны быть записаны в энергонезависимую память EFI с помощью утилиты mokutil. Утилита mokutil при установке сертификата требует перезагрузить систему и ещё до загрузки ядра операционной системы предлагает администратору разрешить загрузку нового сертификата.
Таким образом, добавление сертификата требует физического доступа администратора к системе. Если машина располагается где-то в облаке либо просто в удалённой серверной и доступ есть только по сети (например, по ssh), то добавить сертификат будет невозможно.
EFI на виртуальных машинах
Несмотря на то, что уже давно EFI поддерживается практически всеми создателями материнских плат, при установке системы администратор может не задуматься о необходимости EFI, и он может быть отключён.
Не все гипервизоры поддерживают EFI. VMWare vSphere поддерживает EFI, начиная с версии 5.
Microsoft Hyper-V также получил поддержку EFI, начиная с Hyper-V for Windows Server 2012R2.
Однако в дефолтной конфигурации этот функционал для Linux машин выключен, а значит, сертификат установить нельзя.
В vSphere 6.5 выставить опцию Secure Boot можно только в старой версии веб-интерфейса, который работает через Flash. Web UI на HTML-5 пока сильно отстаёт.
Экспериментальные дистрибутивы
Ну и напоследок рассмотрим вопрос экспериментальных дистрибутивов и дистрибутивов без официальной поддержки. С одной стороны, такие дистрибутивы навряд ли встретишь на серверах серьёзных организаций. Официальной поддержки у таких дистрибутивов нет. Поэтому и обеспечивать тех. поддержку продукта на таком дистрибутиве нельзя.
Однако такие дистрибутивы становятся удобной площадкой для пробы новых экспериментальных решений. Например, Fedora, OpenSUSE Tumbleweed или Unstable версии Debian. Они довольно стабильны. В них всегда новые версии программ и всегда новое ядро. Через год этот экспериментальный функционал может оказаться в обновлённом RHEL, SLES или Ubuntu.
Так что если что-то не работает на экспериментальном дистрибутиве — это повод разобраться в проблеме и решить её. Нужно быть готовым к тому, что этот функционал скоро появится на production-серверах пользователей.
Существующий на текущий момент список официально поддерживаемых дистрибутивов для версии 3.0 вы можете изучить здесь. Но реальный список дистрибутивов, на которых наш продукт способен работать, намного шире.
Лично мне был интересен эксперимент с ОС «Эльбрус». После доработки пакета veeam наш продукт установился и заработал. Про этот эксперимент я писал на Хабре в статье.
Ну а поддержка новых дистрибутивов продолжается. Ожидаем появления на свет версии 4.0. Вот-вот должна появиться бэта, так что следите за whats-new!