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

Прављење резервне апликације која ради на било којој дистрибуцији није лак задатак. Да бисте осигурали да Вееам Агент за Линук ради на дистрибуцијама од Ред Хат 6 и Дебиан 6, до ОпенСУСЕ 15.1 и Убунту 19.04, морате да решите низ проблема, посебно имајући у виду да софтверски производ укључује модул кернела.

Чланак је настао на основу материјала из говора на конференцији Линук Петер 2019.

Линук није само један од најпопуларнијих оперативних система. У суштини, ово је платформа на основу које можете направити нешто јединствено, нешто своје. Захваљујући томе, Линук има много дистрибуција које се разликују по свом скупу софтверских компоненти. И овде настаје проблем: да би софтверски производ функционисао на било којој дистрибуцији, морате узети у обзир карактеристике сваке од њих.

Менаџери пакета. .деб вс .рпм

Почнимо са очигледним проблемом дистрибуције производа у различитим дистрибуцијама.
Најтипичнији начин за дистрибуцију софтверских производа је стављање пакета у спремиште тако да менаџер пакета уграђен у систем може да га инсталира одатле.
Међутим, имамо два популарна формата пакета: рпм и Деб. То значи да ће сви морати да подрже.

У свету деб пакета, ниво компатибилности је невероватан. Исти пакет се инсталира и ради подједнако добро и на Дебиан 6 и на Убунту 19.04. Стандарди за процес прављења пакета и рада са њима, постављени у старим Дебиан дистрибуцијама, остају релевантни у новонасталом Линук Минту и основном ОС-у. Стога, у случају Вееам Агент-а за Линук, довољан је један деб пакет за сваку хардверску платформу.

Али у свету рпм пакета, разлике су велике. Прво, због чињенице да постоје два потпуно независна дистрибутера, Ред Хат и СУСЕ, за које је компатибилност потпуно непотребна. Друго, ови дистрибутери имају дистрибутивне комплете од њих. подршка и експериментални. Нема потребе за компатибилношћу између њих. Испоставило се да ел6, ел7 и ел8 имају своје пакете. Одвојени пакет за Федору. Пакети за СЛЕС11 и 12 и посебан за опенСУСЕ. Главни проблем су зависности и називи пакета.

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

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

За ЕЛ7:
За СЛЕС 12:

• либблкид
• либгцц
• либстдц++
• нцурсес-либс
• фусе-либс
• филе-либс
• вееамснап=3.0.2.1185

• либблкид1
• либгцц_с1
• либстдц ++ КСНУМКС
• либмагиц1
• либфусе2
• вееамснап-кмп=3.0.2.1185

Као резултат тога, листа зависности је јединствена за дистрибуцију.

Оно што постаје горе је када ажурирана верзија почне да се крије под старим именом пакета.

Пример:

Пакет је ажуриран у Федора 24 нцурсес од верзије 5 до верзије 6. Наш производ је направљен са верзијом 5 да би се обезбедила компатибилност са старијим дистрибуцијама. Да бих користио стару 5. верзију библиотеке на Федора 24, морао сам да користим пакет нцурсес-цомпат-либс.

Као резултат, постоје два пакета за Федора, са различитим зависностима.

Даље занимљивије. Након следећег ажурирања дистрибуције, пакет нцурсес-цомпат-либс са верзијом 5 библиотеке испоставило се да је недоступна. За дистрибутера је скупо да превуче старе библиотеке у нову верзију дистрибуције. Након неког времена, проблем се поновио у СУСЕ дистрибуцијама.

Као резултат тога, неке дистрибуције су морале да одбаце своју експлицитну зависност од нцурсес-либс, и поправите производ тако да може да ради са било којом верзијом библиотеке.

Иначе, у верзији 8 Ред Хата више нема мета пакета питон, који се односио на старо добро питхон 2.7... постоји питхон2 и питон3.

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

Проблем са зависностима је стар и одавно је очигледан. Сетите се само пакла зависности.
Комбиновати различите библиотеке и апликације тако да све раде стабилно и да се не сукобљавају - у ствари, то је задатак који сваки дистрибутер Линука покушава да реши.

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

Флатпак такође вам омогућава да покренете апликације у сандбок-у користећи Линук контејнере. Користи се и идеја сандбок-а АппИмаге.

Ова решења вам омогућавају да креирате један пакет за било коју дистрибуцију. У случају Флатпак инсталација и покретање апликације могуће је и без знања администратора.

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

Други проблем је што дистрибуције које су популарне у пословном окружењу од Ред Хат-а и СУСЕ-а још увек не садрже подршку за Снаппи и Флатпак.

У том смислу, Вееам Агент за Линук није доступан снапцрафт.ио није на флатхуб.орг.

Да закључим питање о менаџерима пакета, желео бих да напоменем да постоји опција да се менаџери пакета потпуно напусте комбиновањем бинарних датотека и скрипте за њихово инсталирање у један пакет.

Такав пакет вам омогућава да креирате један заједнички пакет за различите дистрибуције и платформе, спроведете интерактивни процес инсталације, извршите неопходну прилагодбу. Такве пакете за Линук сам срео само од ВМваре-а.

Проблем са ажурирањем

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

Постоје 3 стратегије ажурирања:

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

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

Разноврсне хардверске платформе

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

У пројекту Вееам Агент за Линук још увек не можемо да подржимо ништа попут овог РИСЦ-а.

Нећу се детаљније задржавати на овом питању. Навешћу само главне проблеме: типове зависне од платформе, као нпр size_t, поравнање структуре и редослед бајтова.

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

Али питање је "Како се повезати са библиотекама - динамички или статички?" вреди дискутовати.

По правилу, Ц/Ц++ апликације под Линуком користе динамичко повезивање. Ово одлично функционише ако је апликација направљена посебно за одређену дистрибуцију.

Ако је задатак да покријете различите дистрибуције једном бинарном датотеком, онда се морате фокусирати на најстарију подржану дистрибуцију. За нас је ово Ред Хат 6. Садржи гцц 4.4, који чак ни стандард Ц++11 не подржава потпуно.

Наш пројекат градимо користећи гцц 6.3, који у потпуности подржава Ц++14. Наравно, у овом случају, на Ред Хат 6 морате носити либстдц++ и појачати библиотеке са собом. Најлакши начин је да се статички повежете са њима.

Али, нажалост, не могу све библиотеке бити статички повезане.

Прво, системске библиотеке као нпр либфусе, либблкид потребно је динамички повезати да би се обезбедила њихова компатибилност са језгром и његовим модулима.

Друго, постоји суптилност са лиценцама.

ГПЛ лиценца вам у основи омогућава да повежете библиотеке само са отвореним кодом. МИТ и БСД дозвољавају статичко повезивање и омогућавају да се библиотеке укључе у пројекат. Али изгледа да ЛГПЛ није у супротности са статичким повезивањем, већ захтева да се датотеке неопходне за повезивање деле.

Уопштено говорећи, коришћење динамичког повезивања ће вас спречити да морате било шта да пружите.

Израда Ц/Ц++ апликација

Да бисте направили Ц/Ц++ апликације за различите платформе и дистрибуције, довољно је одабрати или изградити одговарајућу верзију гцц-а и користити унакрсне компајлере за одређене архитектуре и саставити цео скуп библиотека. Овај посао је прилично изводљив, али прилично проблематичан. И не постоји гаранција да ће изабрани компајлер и библиотеке обезбедити функционалну верзију.

Очигледна предност: инфраструктура је знатно поједностављена, пошто се цео процес изградње може завршити на једној машини. Поред тога, довољно је прикупити један сет бинарних датотека за једну архитектуру и можете их спаковати у пакете за различите дистрибуције. Овако су направљени вееам пакети за Вееам Агент за Линук.

За разлику од ове опције, можете једноставно припремити фарму за изградњу, односно неколико машина за монтажу. Свака таква машина ће обезбедити компилацију апликације и састављање пакета за одређену дистрибуцију и специфичну архитектуру. У овом случају, компилација се врши помоћу средстава које је припремио дистрибутер. То јест, фаза припреме компајлера и одабира библиотека је елиминисана. Поред тога, процес изградње се може лако паралелизирати.

Постоји, међутим, лоша страна овог приступа: за сваку дистрибуцију унутар исте архитектуре, мораћете да прикупите сопствени скуп бинарних датотека. Још један недостатак је што је потребно одржавати тако велики број машина и доделити велику количину простора на диску и РАМ-а.

Овако се компајлирају КМОД пакети модула вееамснап кернел за Ред Хат дистрибуције.

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

Колеге из СУСЕ-а су покушале да имплементирају неку средину у виду посебног сервиса за компајлирање апликација и склапање пакета - опенбуилдсервице.

У суштини, то је хипервизор који креира виртуелну машину, инсталира све потребне пакете у њу, компајлира апликацију и гради пакет у овом изолованом окружењу, након чега се виртуелна машина пушта.

Планер имплементиран у ОпенБуилдСервице ће одредити колико виртуелних машина може да покрене за оптималну брзину прављења пакета. Уграђени механизам потписивања ће потписати пакете и отпремити их у уграђено спремиште. Уграђени систем контроле верзија ће сачувати историју измена и израда. Све што остаје је да једноставно додате своје изворе овом систему. Не морате чак ни сами да подешавате сервер; можете користити отворени.

Постоји, међутим, проблем: такав комбајн се тешко уклапа у постојећу инфраструктуру. На пример, контрола верзија није потребна; већ имамо сопствене изворне кодове. Наш механизам потписа је другачији: користимо посебан сервер. Репозиторијум такође није потребан.

Поред тога, подршка за друге дистрибуције - на пример, Ред Хат - имплементирана је прилично лоше, што је разумљиво.

Предност оваквог сервиса је брза подршка за следећу верзију СУСЕ дистрибуције. Пре званичног објављивања, пакети неопходни за склапање се постављају на јавно складиште. Нова се појављује на листи доступних дистрибуција на ОпенБуилдСервице-у. Означавамо поље и додаје се у план изградње. Тако се додавање нове верзије дистрибуције врши скоро једним кликом.

У нашој инфраструктури, користећи ОпенБуилдСервице, саставља се читав низ КМП пакета вееамснап кернел модула за СУСЕ дистрибуције.

Затим бих желео да се задржим на питањима специфичним за модуле кернела.

кернел АБИ

Модули Линук кернела су историјски дистрибуирани у изворном облику. Чињеница је да се креатори кернела не оптерећују бригом о подршци стабилном АПИ-ју за модуле кернела, а посебно на бинарном нивоу, који се даље назива кАБИ.

Да бисте направили модул за ванилла кернел, дефинитивно су вам потребна заглавља овог конкретног кернела, и он ће радити само на овом кернелу.

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

Међутим, ова ситуација не одговара посебно сегменту предузећа. Дистрибутери власничког кода желе да дистрибуирају производ као компајлиране бинарне датотеке.

Администратори не желе да задрже развојне алате на производним серверима из безбедносних разлога. Ентерприсе Линук дистрибутери као што су Ред Хат и СУСЕ одлучили су да могу да подрже стабилан кАБИ за своје кориснике. Резултат су били КМОД пакети за Ред Хат и КМП пакети за СУСЕ.

Суштина овог решења је прилично једноставна. За одређену верзију дистрибуције, АПИ језгра је замрзнут. Дистрибутер наводи да користи језгро, на пример, 3.10, и прави само исправке и побољшања која не утичу на интерфејсе кернела, а модули прикупљени за први кернел могу се користити за све наредне без рекомпилације.

Ред Хат тврди да је кАБИ компатибилност за дистрибуцију током читавог животног циклуса. То јест, састављени модул за рхел 6.0 (издање новембар 2010.) такође треба да ради на верзији 6.10 (издање јуна 2018.). А ово је скоро 8 година. Наравно, овај задатак је прилично тежак.
Снимили смо неколико случајева где је вееамснап модул престао да ради због проблема са кАБИ компатибилношћу.

Након што се показало да је вееамснап модул, компајлиран за РХЕЛ 7.0, некомпатибилан са језгром из РХЕЛ 7.5, али се учитао и гарантовано да ће срушити сервер, у потпуности смо напустили употребу кАБИ компатибилности за РХЕЛ 7.

Тренутно, КМОД пакет за РХЕЛ 7 садржи склоп за сваку верзију издања и скрипту која учитава модул.

СУСЕ је пажљивије приступио задатку кАБИ компатибилности. Они пружају кАБИ компатибилност само у оквиру једног сервисног пакета.

На пример, издање СЛЕС 12 се догодило у септембру 2014. А СЛЕС 12 СП1 је већ био у децембру 2015. године, односно прошло је нешто више од годину дана. Иако оба издања користе језгро 3.12, они су кАБИ некомпатибилни. Очигледно, одржавање кАБИ компатибилности само годину дана је много лакше. Годишњи циклус ажурирања модула кернела не би требало да ствара проблеме креаторима модула.

Као резултат ове СУСЕ политике, нисмо забележили ниједан проблем са кАБИ компатибилношћу у нашем вееамснап модулу. Истина, број пакета за СУСЕ је скоро за ред величине већи.

Закрпе и бацкпортови

Иако дистрибутери покушавају да обезбеде кАБИ компатибилност и стабилност кернела, они такође покушавају да побољшају перформансе и елиминишу недостатке овог стабилног кернела.

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

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

У најновијем издању Ред Хат 6, направљена је грешка у једном од мањих ажурирања. То је довело до чињенице да је модул вееамснап гарантовано срушио систем када је снимак објављен. Упоредивши изворе кернела пре и после ажурирања, открили смо да је за то крив бацкпорт. Слична исправка је направљена у верзији језгра ваниле 4.19. Само што је ова исправка добро функционисала у ванилла кернелу, али када је пренета на „стабилну“ 2.6.32, појавио се проблем са спинлоцком.

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

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

Када сам покушао да направим модул на кернелу 4.4 из СЛЕС 12 СП3, био сам изненађен што сам у њему пронашао функционалност ваниле 4.8. По мом мишљењу, блок И/О имплементација 4.4 кернела из СЛЕС 12 СП3 је сличнија кернелу 4.8 од претходног издања стабилног 4.4 кернела из СЛЕС12 СП2. Не могу да проценим колики је проценат кода пренет са кернела 4.8 на СЛЕС 4.4 за СП3, али не могу ни да назовем кернел истим стабилним 4.4.

Најнепријатнија ствар у вези са овим је да када пишете модул који би подједнако добро функционисао на различитим кернелима, више се не можете ослонити на верзију кернела. Такође морате узети у обзир дистрибуцију. Добро је што се понекад можете укључити у дефиницију која се појављује заједно са новом функционалношћу, али ова прилика се не појављује увек.

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

Постоје и закрпе које мењају документовани АПИ кернела.
Наишао сам на дистрибуцију КДЕ неон 5.16 и био сам веома изненађен када је видео да је позив лоокуп_бдев у овој верзији кернела променио листу улазних параметара.

Да бих то сакупио, морао сам да додам скрипту макефилеу која проверава да ли функција лоокуп_бдев има параметар маске.

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

Али вратимо се питању дистрибуције пакета.

Једна од предности стабилног кАБИ-ја је то што модули кернела могу бити потписани као бинарни фајл. У овом случају, програмер може бити сигуран да модул није случајно оштећен или намерно измењен. Ово можете проверити командом модинфо.

Ред Хат и СУСЕ дистрибуције вам омогућавају да проверите потпис модула и учитате га само ако је одговарајући сертификат регистрован у систему. Сертификат је јавни кључ којим је модул потписан. Дистрибуирамо га као посебан пакет.

Проблем је у томе што сертификати могу бити уграђени у кернел (дистрибутери их користе) или морају бити уписани у ЕФИ непроменљиву меморију помоћу услужног програма мокутил. Корисност мокутил Када инсталирате сертификат, он захтева да поново покренете систем и, чак и пре учитавања кернела оперативног система, тражи од администратора да дозволи учитавање новог сертификата.

Дакле, додавање сертификата захтева физички приступ администратора систему. Ако се машина налази негде у облаку или једноставно у удаљеној серверској соби и приступ је само преко мреже (на пример, преко ссх), онда ће бити немогуће додати сертификат.

ЕФИ на виртуелним машинама

Упркос чињеници да ЕФИ већ дуго подржавају скоро сви произвођачи матичних плоча, приликом инсталирања система администратор можда неће размишљати о потреби за ЕФИ и може бити онемогућен.

Не подржавају сви хипервизори ЕФИ. ВМВаре вСпхере подржава ЕФИ почевши од верзије 5.
Мицрософт Хипер-В је такође добио ЕФИ подршку почевши од Хипер-В за Виндовс Сервер 2012Р2.

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

У вСпхере 6.5, подесите опцију сецуре боот могуће само у старој верзији веб интерфејса, који ради преко Фласх-а. Веб кориснички интерфејс на ХТМЛ-5 је још увек далеко иза.

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

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

Међутим, такве дистрибуције постају погодна платформа за испробавање нових експерименталних решења. На пример, Федора, ОпенСУСЕ Тумблевеед или Нестабилне верзије Дебиан-а. Они су прилично стабилни. Увек имају нове верзије програма и увек ново језгро. За годину дана, ова експериментална функционалност може завршити у ажурираном РХЕЛ-у, СЛЕС-у или Убунту-у.

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

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

Лично, био сам заинтересован за експеримент са Елбрус ОС-ом. Након финализације вееам пакета, наш производ је инсталиран и ради. Писао сам о овом експерименту на Хабре у Чланак.

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

Извор: ввв.хабр.цом