Linux е многолик: как да работим на всеки дистрибутив

Създаването на приложение за архивиране, работещо на всяко дистрибутив, е сложна задача. За да се осигури работата на Veeam Agent for Linux на дистрибутиви от Red Hat 6 и Debian 6 до OpenSUSE 15.1 и Ubuntu 19.04, е необходимо да се решат редица проблеми, особено като се има предвид, че в състава на софтуерния продукт влиза модул на ядрото.

Статията е написана на база на материалите от изказването на конференцията LinuxPiter 2019.

Linux не е просто една от най-популярните операционни системи. По същество, това е платформа, на която може да се изработи нещо уникално, нещо свое. Заради това, Linux разполага с множество дистрибутиви, които се различават по набор от софтуерни компоненти. И тук възниква проблемът: за да функционира софтуерният продукт на който и да е дистрибутив, е необходимо да се вземат предвид особеностите на всеки.

Мениджъри на пакети. .deb срещу .rpm

Нека започнем с очевидния проблем с разпространението на продукта за различни дистрибутиви.
Най-типичният начин за разпространение на софтуерни продукти е да се постави пакет в хранилище, за да може вграденият в системата мениджър на пакети да го инсталира оттам.
Но популярните формати на пакети са два: 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. Основният проблем — в зависимостите и имената на пакетите.

Проблема с зависимостите

За съжаление, същите пакети често се срещат под различни наименования в различни дистрибутиви. По-долу е непълен списък на зависимостите на пакета veeam.

За EL7:
За SLES 12:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• fuse-libs
• file-libs
• veeamsnap = 3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veeamsnap-kmp = 3.0.2.1185

В резултат списъкът на зависимостите се оказва уникален за дистрибуцията.

По-лошо е, когато под старото име на пакета започне да се крие обновена версия.

Пример:

В Fedora 24 бе обновен пакет ncurses от версия 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 инсталацията и стартирането на приложението е възможно дори без знанието на администратора.

Основният проблем е, че не всички приложения могат да работят в пясъчника. Някои изискват директен достъп до платформата. Да не споменавам модулите на ядрото, които са силно зависими от ядрото и по никакъв начин не се вписват в концепцията на пясъчника.

Вторият проблем е, че популярните в enterprise-средата дистрибуции от Red Hat и SUSE все още не съдържат поддръжка за Snappy и Flatpak.

В тази връзка Veeam Agent for Linux няма нито на snapcraft.io никъде flathub.org.

В завършване на въпроса относно пакетните мениджъри, ще спомена, че има вариант да се откажем напълно от пакетните мениджъри, комбинирайки бинарните файлове и скрипта за тяхната инсталация в един пакет.

Такъв пакет позволява да се създаде един общ пакет за различни дистрибуции и платформи, да се извърши интерактивен процес на инсталация, осигурявайки необходимата персонализация. Аз съм срещал такива пакети за Linux само от VMware.

Проблемът с актуализациите

Дори ако всички проблеми с зависимостите са разрешени, програмата може да работи по различен начин на една и съща дистрибуция. Става дума за актуализациите.

Има 3 стратегии за актуализиране:

• Най-простата е никога да не актуализирате. Настроили сте сървъра и забравили. Защо да актуализирате, ако всичко работи? Проблемите започват при първото обаждане в обслужването на клиенти. Създателят на дистрибуцията поддържа само актуализирания релийз.
• Може да се доверите на дистрибутора и да настроите автоматично актуализиране. В този случай обаждането в обслужването на клиенти е вероятно веднага след неуспешна актуализация.
• Вариантът за ръчно актуализиране само след тестове на тестовата инфраструктура е най-сигурният, но и най-скъпият и трудоемък. Далеч не всеки може да си го позволи.

Тъй като различните потребители прилагат различни стратегии за актуализиране, е необходимо да се поддържат както най-новите релийзи, така и всички предишни. Това усложнява както процеса на разработка, така и процеса на тестване, добавяйки главоболия на обслужването на клиенти.

Разнообразие от хардуерни платформи

Различните хардуерни платформи са проблем, който в значителна степен е специфичен именно за нативния код. Най-малкото, трябва да се създават бинарни файлове за всяка поддържана платформа.

В проекта Veeam Agent for Linux все никак не можем да поддържаме нещо такова RISC-обрано.

Няма да задълбавам подробно в този въпрос. Ще посоча само основните проблеми: платформен зависящи типове, като size_t, подравняване на структури и ред на байтовете.

Статично и/или динамично свързване

А въпросът "Как да се свързваме с библиотеките — динамично или статично?" заслужава да се обсъди.

Обикновено приложенията на C/C++ за Linux използват динамично свързване. Това работи отлично, ако приложението е компилирано специално за конкретна дистрибуция.

Ако целта е да се обхванат различни дистрибуции с един бинарен файл, трябва да се ориентираме към най-старата поддържана дистрибуция. За нас това е Red Hat 6. Той съдържа gcc 4.4, който не поддържа дори стандарт C++11. напълно.

Ние съставяме нашия проект с помощта на gcc 6.3, който напълно поддържа C++14. Разбира се, в този случай на Red Hat 6 библиотеките libstdc++ и boost трябва да се носят със себе си. Най-лесно е да се линковат статично с тях.

Но за съжаление, не со всички библиотеки може да се линковат статично.

На първо място, системните библиотеки, като libfuse, libblkid трябва да се линковат динамично, за да сме сигурни в съвместимостта им с ядрото и неговите модули.

На второ място, има особености с лицензите.

Лицензията GPL в принцип не разрешава линковането на библиотеки само с opensource код. MIT и BSD разрешават статична линковка и позволяват включването на библиотеки в проекта. А LGPL, изглежда, не противоречи на статичната линковка, но изисква предоставянето на общ достъп до файлове, необходими за свързването.

В общия случай, използването на динамична линковка ще ни предпази от необходимостта да предоставяме нещо.

Събиране на C/C++ приложения

За събиране на C/C++ приложения за различни платформи и дистрибуции, достатъчно е да подберем или съберем 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 на ядрото се замразява. Дистрибuteur заявява, че използва именно ядрото, например 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 гарантирано сриваше системата при освобождаването на снапшота. Сравнявайки изходните кодове на ядрото преди и след обновлението, установихме, че вината е в бекпорта. Подобен фикс е бил направен във ваниловото ядро версия 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 ядро от SLES 12 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 за Windows Server 2012R2.

Обаче в дефолтната конфигурация тази функционалност за Linux машини е изключена, което означава, че сертификатът не може да бъде инсталиран.

В vSphere 6.5 опцията Secure Boot може да бъде активирана само в старата версия на уеб интерфейса, който работи чрез Flash. Web UI на HTML-5 все още значително изостава.

Експериментални дистрибуции

И накрая, нека разгледаме въпроса за експерименталните дистрибуции и дистрибуции без официална поддръжка. От една страна, такива дистрибуции едва ли ще срещнете на сървърите на сериозни организации. Официална поддръжка за такива дистрибуции няма. Следователно, осигуряването на тех. поддръжка за продукта на такава дистрибуция не е възможно.

Въпреки това, такива дистрибуции стават удобна платформа за проба на нови експериментални решения. Например, Fedora, OpenSUSE Tumbleweed или нестабилни версии на Debian. Те са доста стабилни. В тях винаги има нови версии на софтуера и винаги ново ядро. След година тази експериментална функционалност може да се окаже в обновен RHEL, SLES или Ubuntu.

Така че, ако нещо не работи на експериментална дистрибуция — това е повод да се запознаете с проблема и да го решите. Трябва да сте готови, че тази функционалност скоро ще се появи на production-сървърите на потребителите.

Списъкът на официално поддържаните дистрибуции за версия 3.0 е наличен за преглед. тук.Но реалният списък на дистрибуциите, на които нашият продукт може да работи, е много по-широк.

Лично мен ме интересуваше експериментът с ОС "Елбрус". След доработка на пакета Veeam, нашият продукт беше инсталиран и заработи. За този експеримент писах на Хабра в статии.

Поддръжката на нови дистрибуции продължава. Очакваме появата на версия 4.0. Скоро трябва да се появи бета версия, така че следете за whats-new!

Източник: habr.com