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

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

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

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

Пакетни управители. .deb vs .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 инсталирането и стартирането на приложението е възможно дори без знанието на администратора.

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

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

Във връзка с това Veeam Agent for Linux не е наличен нито на snapcraft.io нито на flathub.org.

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

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

Проблемът с обновленията

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

Съществуват 3 стратегии за обновление:

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

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

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

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

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

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

Статична и/или динамична линковане

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

Обикновено приложенията на С/С++ под 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 изглежда, че не противоречи на статичното свързване, но изисква предоставяне на файлове, нужни за свързването.

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

Създаване на С/С++ приложения

За създаване на С/С++ приложения за различни платформи и дистрибуции е достатъчно да се подбере или събере gcc с подходяща версия и да се използват крос-компилатори за специфични архитектури, да се събере целият набор от библиотеки. Тази работа е напълно реализируема, но доста трудоемка. И няма гаранции, че избраният компилатор и библиотеките ще осигурят работеща версия.

Очевиден плюс: инфраструктурата значително се опростява, тъй като целият процес на компилация може да се извърши на една машина. Освен това е достатъчно да се събере един набор от бинарни файлове за една архитектура и те могат да се опаковат в пакети за различни дистрибуции. Така се създават пакетите veeam за Veeam Agent for Linux.

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

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

По този начин се събират KMOD пакети на модула ядро veeamsnap за дистрибутивите Red Hat.

Open Build Service

Колегите от SUSE опитаха да реализират някаква златна среда под формата на специална услуга за компилация на приложения и изграждане на пакети — openbuildservice.

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

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

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

Освен това, поддръжката на други дистрибутиви — например, Red Hat — е реализирана доста оскъдно, което е напълно обяснимо.

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

В нашата инфраструктура с използване на OpenBuildService се компилира всякакво разнообразие от KMP пакети на модула на ядрото veeamsnap за дистрибуции SUSE.

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

kernel ABI

Модулите на ядрото на Linux исторически се разпространяват под формата на изходен код. Факт е, че създателите на ядрото не се обременяват с поддържането на стабилен API за модулите на ядрото, а още по-малко на бинарно ниво, известно като kABI.

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

DKMS позволява автоматизиране на процеса на компилиране на модулите при актуализиране на ядрото. В резултат на това потребителите на репозитория Debian (и неговите многобройни роднини) използват модулите на ядрото или от репозитория на дистрибуторите, или компилирани от изходен код с помощта на DKMS.

Все пак, такава ситуация не е особено задоволителна за сектора Enterprise. Разпространителите на проприетарен код искат да предлагат продукта под формата на компилирани бинарни файлове.

Администраторите не искат да държат средства за разработка на production сървъри по съображения за сигурност. Дистрибуторите на Enterprise Linux — като Red Hat и SUSE — решиха, че за своите потребители ще могат да поддържат стабилно kABI. В резултат на това се появиха KMOD пакети за Red Hat и KMP пакети за SUSE.

Същността на това решение е доста проста. За конкретна версия на дистрибуцията API на ядрото се „замразява“. Дистрибуторът заявява, че използва именно ядро, например 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 ядро от 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. Уеб интерфейсът на HTML-5 все още е значително по-бавен.

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

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

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

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

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

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

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

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