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

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

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

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

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

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

В света на deb пакетите нивото на съвместимост е невероятно. Същият пакет се инсталира и работи еднакво добре както на Debian 6, така и на Ubuntu 19.04. Стандартите за процеса на изграждане на пакети и работа с тях, заложени в старите дистрибуции на Debian, остават актуални в новомодния Linux Mint и елементарната ОС. Следователно в случая на Veeam Agent за Linux е достатъчен един deb пакет за всяка хардуерна платформа.

Но в света на rpm пакетите разликите са големи. Първо, поради факта, че има два напълно независими дистрибутора, Red Hat и SUSE, за които съвместимостта е напълно ненужна. Второ, тези дистрибутори имат комплекти за разпространение от тях. поддържащи и експериментални. Няма нужда и от съвместимост между тях. Оказа се, че el6, el7 и el8 имат собствени пакети. Отделен пакет за Fedora. Пакети за SLES11 и 12 и отделен за openSUSE. Основният проблем са зависимостите и имената на пакетите.

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

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

За EL7:
За SLES 12:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• fuse-libs
• файл-библиотеки
• veeamsnap=3.0.2.1185

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

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

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

Пример:

Пакетът е актуализиран във Fedora 24 псувни от версия 5 на версия 6. Нашият продукт е създаден с версия 5, за да осигури съвместимост с по-стари дистрибуции. За да използвам старата 5-та версия на библиотеката във Fedora 24, трябваше да използвам пакета ncurses-compat-libs.

В резултат на това има два пакета за Fedora с различни зависимости.

Още по-интересно. След следващата актуализация на разпространението пакетът ncurses-compat-libs с версия 5 на библиотеката се оказва недостъпна. За дистрибутора е скъпо да премести стари библиотеки в нова версия на дистрибуцията. След известно време проблемът се повтори в дистрибуциите на SUSE.

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

Между другото, във версия 8 на Red Hat вече няма мета пакет питон, което се отнасяше до доброто старо python 2.7, Има python2 и питон3.

Алтернатива на мениджърите на пакети

Проблемът със зависимостите е стар и отдавна е ясен. Просто си спомнете ада на зависимостта.
Комбинирайте различни библиотеки и приложения, така че всички те да работят стабилно и да не са в конфликт - всъщност това е задачата, която всеки дистрибутор на Linux се опитва да реши.

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

Flatpak също така ви позволява да стартирате приложения в пясъчна среда, използвайки Linux контейнери. Използва се и идеята за пясък AppImage.

Тези решения ви позволяват да създадете един пакет за всяко разпространение. В случай на Flatpak инсталирането и стартирането на приложението е възможно дори без знанието на администратора.

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

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

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

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

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

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

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

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

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

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

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

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

В проекта Veeam Agent за 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 лицензът ви позволява да свързвате библиотеки само с отворен код. MIT и BSD позволяват статично свързване и позволяват библиотеки да бъдат включени в проект. Но LGPL не изглежда да противоречи на статичното свързване, но изисква файловете, необходими за свързване, да бъдат споделяни.

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

Изграждане на C/C++ приложения

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

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

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

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

Ето как се компилират KMOD пакетите на модула на ядрото veeamsnap за дистрибуции на Red Hat.

Отворете услугата за изграждане

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

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

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

Има обаче проблем: такъв комбайн трудно се вписва в съществуващата инфраструктура. Например не е необходим контрол на версиите; ние вече имаме собствени за изходните кодове. Нашият механизъм за подписване е различен: използваме специален сървър. Хранилище също не е необходимо.

В допълнение, поддръжката на други дистрибуции - например Red Hat - се прилага доста слабо, което е разбираемо.

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

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

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

ABI на ядрото

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

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

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

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

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

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

Red Hat твърди, че е съвместим с kABI за разпространението през целия му жизнен цикъл. Тоест сглобеният модул за rhel 6.0 (издание ноември 2010 г.) трябва да работи и на версия 6.10 (издание юни 2018 г.). И това са почти 8 години. Естествено, тази задача е доста трудна.
Записахме няколко случая, при които модулът veeamsnap спря да работи поради проблеми със съвместимостта на kABI.

След като модулът veeamsnap, компилиран за RHEL 7.0, се оказа несъвместим с ядрото от RHEL 7.5, но се зареди и гарантирано ще срине сървъра, ние се отказахме изцяло от използването на kABI съвместимост за RHEL 7.

Понастоящем пакетът KMOD за RHEL 7 съдържа сборка за всяка версия на изданието и скрипт, който зарежда модула.

SUSE подходи по-внимателно към задачата за kABI съвместимост. Те осигуряват kABI съвместимост само в рамките на един сервизен пакет.

Например, пускането на SLES 12 се състоя през септември 2014 г. А SLES 12 SP1 беше вече през декември 2015 г., т.е. измина малко повече от година. Въпреки че и двете версии използват ядрото 3.12, те са несъвместими с kABI. Очевидно поддържането на kABI съвместимост само за една година е много по-лесно. Годишният цикъл на актуализиране на модула на ядрото не трябва да създава проблеми на създателите на модули.

В резултат на тази политика на SUSE не сме записали нито един проблем с kABI съвместимостта в нашия модул veeamsnap. Вярно е, че броят на пакетите за SUSE е почти с порядък по-голям.

Пачове и бекпортове

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

В същото време, в допълнение към собствената си „работа по грешките“, разработчиците на корпоративното ядро ​​на Linux наблюдават промените във ваниловото ядро ​​и ги прехвърлят в своето „стабилно“.

Понякога това води до нови грешки.

В последната версия на Red Hat 6 беше допусната грешка в една от малките актуализации. Това доведе до факта, че модулът veeamsnap гарантирано ще срине системата, когато снимката бъде пусната. След като сравнихме изходните кодове на ядрото преди и след актуализацията, открихме, че вината е backport. Подобна корекция беше направена във версия на vanilla ядрото 4.19. Просто тази корекция работи добре във ваниловото ядро, но при прехвърлянето му към „стабилната“ 2.6.32 възникна проблем със спинлок.

Разбира се, всеки винаги има грешки, но струваше ли си да влача кода от 4.19 до 2.6.32, рискувайки стабилност?.. Не съм сигурен...

Най-лошото е, когато маркетингът се намеси в дърпането на въже между „стабилност“ и „модернизация“. Маркетинговият отдел се нуждае от ядрото на актуализираната дистрибуция, за да бъде стабилно, от една страна, и в същото време да бъде по-добро в производителността и да има нови функции. Това води до странни компромиси.

Когато се опитах да създам модул на ядро ​​4.4 от SLES 12 SP3, бях изненадан да намеря функционалност от vanilla 4.8 в него. По мое мнение внедряването на блок I/O на ядрото 4.4 от SLES 12 SP3 е по-подобно на ядрото 4.8, отколкото предишната версия на стабилното ядро ​​4.4 от SLES12 SP2. Не мога да преценя какъв процент код е прехвърлен от ядрото 4.8 към SLES 4.4 за SP3, но дори не мога да нарека ядрото същото стабилно 4.4.

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

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

Има също пачове, които променят документирания API на ядрото.
Попаднах на разпределението KDE неон 5.16 и беше много изненадан да види, че извикването lookup_bdev в тази версия на ядрото промени списъка с входни параметри.

За да го събера, трябваше да добавя скрипт към make-файла, който проверява дали функцията lookup_bdev има параметър маска.

Подписване на модули на ядрото

Но да се върнем на въпроса за разпространението на пакети.

Едно от предимствата на стабилния kABI е, че модулите на ядрото могат да бъдат подписвани като двоичен файл. В този случай разработчикът може да бъде сигурен, че модулът не е бил случайно повреден или умишлено модифициран. Можете да проверите това с командата modinfo.

Дистрибуциите на Red Hat и SUSE ви позволяват да проверите подписа на модула и да го заредите само ако съответният сертификат е регистриран в системата. Сертификатът е публичният ключ, с който се подписва модулът. Ние го разпространяваме като отделен пакет.

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

Следователно добавянето на сертификат изисква физически администраторски достъп до системата. Ако машината се намира някъде в облака или просто в отдалечена сървърна стая и достъпът е само през мрежата (например чрез 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 тук. Но реалният списък от дистрибуции, върху които нашият продукт може да работи, е много по-широк.

Лично аз се интересувах от експеримента с Elbrus OS. След финализиране на пакета veeam, нашият продукт беше инсталиран и работи. Писах за този експеримент на Хабре в Статия.

Е, поддръжката за нови дистрибуции продължава. Очакваме да излезе версия 4.0. Бета е на път да се появи, така че следете какво ново!

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