Линукс има многу лица: како да се работи на која било дистрибуција

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

Статијата е создадена врз основа на материјали од говор на конференцијата Linux Peter 2019 година.

Linux не е само еден од најпопуларните оперативни системи. Во суштина, ова е платформа врз основа на која можете да направите нешто уникатно, нешто свое. Благодарение на ова, Linux има многу дистрибуции кои се разликуваат во нивниот сет на софтверски компоненти. И тука се појавува проблем: за да може софтверски производ да функционира на која било дистрибуција, треба да ги земете предвид карактеристиките на секоја од нив.

Менаџери на пакети. .deb vs .rpm

Да почнеме со очигледниот проблем на дистрибуција на производот низ различни дистрибуции.
Најтипичен начин за дистрибуција на софтверски производи е да го ставите пакетот во складиште, така што менаџерот на пакети вграден во системот може да го инсталира од таму.
Сепак, имаме два популарни формати на пакети: вртежи во минута и deb. Ова значи дека сите ќе мора да поддржат.

Во светот на deb пакетите, нивото на компатибилност е неверојатно. Истиот пакет се инсталира и работи подеднакво добро и на Debian 6 и на Ubuntu 19.04. Стандардите за процесот на градење пакети и работа со нив, утврдени во старите дистрибуции на Debian, остануваат релевантни во новоформираниот Linux Mint и основниот оперативен систем. Затоа, во случајот на Veeam Agent за Linux, доволен е еден deb пакет за секоја хардверска платформа.

Но, во светот на пакетите со вртежи во минута, разликите се големи. Прво, поради фактот што постојат два целосно независни дистрибутери, Red Hat и SUSE, за кои компатибилноста е целосно непотребна. Второ, овие дистрибутери имаат комплети за дистрибуција од тие. поддршка и експериментални. Нема потреба ниту од компатибилност меѓу нив. Се испостави дека el6, el7 и el8 имаат свои пакети. Посебен пакет за Fedora. Пакети за SLES11 и 12 и посебен за openSUSE. Главниот проблем се зависностите и имињата на пакетите.

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

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

За EL7:
За SLES 12:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• осигурувачи-либови
• датотека-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 и python3.

Алтернатива на менаџерите на пакети

Проблемот со зависностите е стар и одамна е очигледен. Само запомнете го пеколот на Dependency.
Да се ​​комбинираат различни библиотеки и апликации за сите тие да работат стабилно и да не се во конфликт - всушност, ова е задачата што секој дистрибутер на Linux се обидува да ја реши.

Менаџерот на пакети се обидува да го реши овој проблем на сосема поинаков начин. Снешко од Canonical. Главната идеја: апликацијата работи во песок, изолирана и заштитена од главниот систем. Ако за апликацијата се потребни библиотеки, тие се испорачуваат со самата апликација.

Flatpak исто така ви овозможува да извршувате апликации во песок со помош на контејнери на Linux. Се користи и идејата за песок AppImage.

Овие решенија ви дозволуваат да креирате еден пакет за која било дистрибуција. Во случај на Flatpak инсталацијата и стартувањето на апликацијата е можно дури и без знаење на администраторот.

Главниот проблем е што не сите апликации можат да работат во песок. На некои луѓе им треба директен пристап до платформата. Јас дури и не зборувам за кернел модули, кои се строго зависни од кернелот и не се вклопуваат во концептот на песок.

Вториот проблем е што дистрибуциите популарни во претпријатието опкружување од Red Hat и SUSE сè уште не содржат поддршка за Snappy и Flatpak.

Во овој поглед, Veeam Agent за 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++ и да ги зајакнете библиотеките со вас. Најлесен начин е статички да се поврзете со нив.

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

Прво, системските библиотеки како што се 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

Модулите на кернелот на Линукс се историски дистрибуирани во изворна форма. Факт е дека креаторите на кернелот не се оптоваруваат со грижата за поддршка на стабилен API за модули на јадрото, а особено на бинарно ниво, понатаму наречено kABI.

За да изградите модул за кернелот од ванила, дефинитивно ви се потребни заглавијата на овој конкретен кернел, и тој ќе работи само на ова јадро.

DKMS ви овозможува да го автоматизирате процесот на градење модули при ажурирање на кернелот. Како резултат на тоа, корисниците на складиштето Debian (и неговите многубројни роднини) користат кернел модули или од складиштето на дистрибутерот или компајлирани од извор користејќи DKMS.

Сепак, оваа ситуација особено не одговара на сегментот Enterprise. Дистрибутерите на комерцијален код сакаат да го дистрибуираат производот како компајлирани бинарни датотеки.

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

Во исто време, покрај сопствената „работа на грешки“, програмерите на претпријатието Линукс кернелот ги следат промените во кернелот од ванила и ги пренесуваат на нивното „стабилно“.

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

Во најновото издание на Red Hat 6, беше направена грешка во едно од помалите ажурирања. Тоа доведе до фактот дека модулот veeamsnap беше загарантиран да го урне системот кога беше објавена снимката. Откако ги споредивме изворите на кернелот пред и по ажурирањето, откривме дека виновен е backport. Слична поправка беше направена во верзијата 4.19 на кернелот од ванила. Само што оваа поправка функционираше добро во јадрото од ванила, но кога се префрли на „стабилната“ 2.6.32, се појави проблем со заклучувањето.

Се разбира, секој секогаш има грешки, но дали вредеше да се повлече кодот од 4.19 на 2.6.32, ризикувајќи ја стабилноста?.. Не сум сигурен...

Најлошото е кога маркетингот се вклучува во борбата помеѓу „стабилноста“ и „модернизацијата“. На одделот за маркетинг му треба јадрото на ажурираната дистрибуција да биде стабилно, од една страна, а во исто време да биде подобро во перформансите и да има нови функции. Ова води до чудни компромиси.

Кога се обидов да изградам модул на кернелот 4.4 од SLES 12 SP3, бев изненаден кога најдов функционалност од ванила 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 во оваа верзија на кернелот ја смени листата на влезни параметри.

За да го соберам, морав да додадам скрипта во мејкфајлот што проверува дали функцијата 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, поставете ја опцијата Безбедна говорница можно само во старата верзија на веб-интерфејсот, кој работи преку Flash. Web UI на HTML-5 е сè уште далеку зад себе.

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

И, конечно, да го разгледаме прашањето за експериментални дистрибуции и дистрибуции без официјална поддршка. Од една страна, таквите дистрибуции веројатно нема да се најдат на серверите на сериозни организации. Нема официјална поддршка за такви дистрибуции. Затоа, обезбедете ги. Производот не може да се поддржи на таква дистрибуција.

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

Значи, ако нешто не работи на експериментална дистрибуција, ова е причина да го откриеме проблемот и да го решиме. Треба да бидете подготвени за фактот дека оваа функционалност наскоро ќе се појави на серверите за производство на корисниците.

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

Лично, ме интересираше експериментот со оперативниот систем Elbrus. По финализирањето на пакетот veeam, нашиот производ беше инсталиран и работеше. Пишував за овој експеримент на Хабре во Член.

Па, поддршката за нови дистрибуции продолжува. Чекаме да излезе верзијата 4.0. Бета е на пат да се појави, затоа внимавајте што има ново!

Извор: www.habr.com