Պահուստային հավելվածի ստեղծումը, որն աշխատում է ցանկացած բաշխման վրա, հեշտ գործ չէ: Ապահովելու համար, որ Veeam Agent-ը Linux-ի համար աշխատում է Red Hat 6-ից և Debian 6-ից մինչև OpenSUSE 15.1 և Ubuntu 19.04 բաշխումների վրա, դուք պետք է լուծեք մի շարք խնդիրներ, հատկապես հաշվի առնելով, որ ծրագրային արտադրանքը ներառում է միջուկի մոդուլ:
Հոդվածը ստեղծվել է գիտաժողովի ելույթի նյութերի հիման վրա .
Linux-ը միայն ամենահայտնի օպերացիոն համակարգերից չէ: Ըստ էության, սա հարթակ է, որի հիման վրա դուք կարող եք ինչ-որ եզակի, ձեր սեփականը ստեղծել: Դրա շնորհիվ Linux-ն ունի բազմաթիվ բաշխումներ, որոնք տարբերվում են իրենց ծրագրային բաղադրիչների հավաքածուով: Եվ այստեղ խնդիր է առաջանում. որպեսզի ծրագրային արտադրանքը գործի ցանկացած բաշխման վրա, պետք է հաշվի առնել յուրաքանչյուրի առանձնահատկությունները:
Փաթեթի կառավարիչներ. .deb vs .rpm
Սկսենք ապրանքը տարբեր բաշխումներով բաշխելու ակնհայտ խնդրից:
Ծրագրային արտադրանքի բաշխման ամենատիպիկ եղանակը փաթեթը պահեստի վրա դնելն է, որպեսզի համակարգում ներկառուցված փաթեթի կառավարիչը կարողանա այն տեղադրել այնտեղից:
Այնուամենայնիվ, մենք ունենք փաթեթի երկու հայտնի ձևաչափ. 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
- ապահովիչ-լիբերակներ
- ֆայլ-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Արդյունքում, կախվածությունների ցանկը եզակի է բաշխման համար:
Ավելի վատն այն է, երբ թարմացված տարբերակը սկսում է թաքնվել հին փաթեթի անվան տակ:
Example:
Փաթեթը թարմացվել է Fedora 24-ում նզովքներ 5-րդ տարբերակից մինչև 6-րդ տարբերակ: Մեր արտադրանքը կառուցվել է 5 տարբերակով, որպեսզի ապահովի համատեղելիությունը հին բաշխումների հետ: Fedora 5-ի գրադարանի հին 24-րդ տարբերակը օգտագործելու համար ես ստիպված էի օգտագործել փաթեթը ncurses-compat-libs.
Արդյունքում, Fedora-ի համար կա երկու փաթեթ՝ տարբեր կախվածություններով։
Ավելի հետաքրքիր. Բաշխման հաջորդ թարմացումից հետո փաթեթը ncurses-compat-libs գրադարանի 5 տարբերակով պարզվում է անհասանելի է։ Բաշխողի համար թանկ է հին գրադարանները բաշխման նոր տարբերակի մեջ քաշելը: Որոշ ժամանակ անց խնդիրը կրկնվեց SUSE բաշխումների մեջ:
Արդյունքում որոշ բաշխումներ ստիպված եղան հրաժարվել իրենց բացահայտ կախվածությունից ncurses-libsև ամրացրեք արտադրանքը, որպեսզի այն կարողանա աշխատել գրադարանի ցանկացած տարբերակի հետ:
Ի դեպ, Red Hat-ի 8-րդ տարբերակում այլեւս մետա փաթեթ չկա Python, որը վերաբերում էր բարի հինին python 2.7. կա python2 и Python3.
Փաթեթների կառավարիչների այլընտրանք
Կախվածության խնդիրը հին է և վաղուց ակնհայտ է: Պարզապես հիշեք կախվածության դժոխքը:
Համատեղել տարբեր գրադարաններ և հավելվածներ, որպեսզի նրանք բոլորն աշխատեն կայուն և չհակասեն, իրականում սա այն խնդիրն է, որը փորձում է լուծել Linux-ի ցանկացած դիստրիբյուտոր:
Փաթեթի կառավարիչը փորձում է այս խնդիրը լուծել բոլորովին այլ կերպ։ Շատ պարզ Canonical-ից։ Հիմնական գաղափարը. հավելվածն աշխատում է հիմնական համակարգից մեկուսացված և պաշտպանված ավազատուփում: Եթե հավելվածը պահանջում է գրադարաններ, դրանք տրամադրվում են հենց հավելվածով:
Flatpak նաև թույլ է տալիս հավելվածներ գործարկել ավազարկղում՝ օգտագործելով Linux Containers: Օգտագործվում է նաև ավազատուփի գաղափարը AppImage- ը.
Այս լուծումները թույլ են տալիս ստեղծել մեկ փաթեթ ցանկացած բաշխման համար: Դեպքում Flatpak հավելվածի տեղադրումն ու գործարկումը հնարավոր է նույնիսկ առանց ադմինիստրատորի իմացության:
Հիմնական խնդիրն այն է, որ ոչ բոլոր հավելվածները կարող են աշխատել ավազարկղում: Որոշ մարդկանց անհրաժեշտ է ուղղակի մուտք դեպի հարթակ: Էլ չեմ խոսում միջուկի մոդուլների մասին, որոնք խիստ կախված են միջուկից և չեն տեղավորվում sandbox հասկացության մեջ։
Երկրորդ խնդիրն այն է, որ Red Hat-ից և SUSE-ից ձեռնարկությունների միջավայրում տարածված բաշխումները դեռ չեն պարունակում Snappy-ի և Flatpak-ի աջակցություն:
Այս առումով, Veeam Agent-ը Linux-ի համար հասանելի չէ ընդհանրապես .
Փաթեթների կառավարիչների մասին հարցը եզրափակելու համար ես կցանկանայի նշել, որ կա փաթեթի կառավարիչներից ընդհանրապես հրաժարվելու տարբերակ՝ երկուական ֆայլերը և դրանք մեկ փաթեթում տեղադրելու սցենարը համատեղելով:
Նման փաթեթը թույլ է տալիս ստեղծել մեկ ընդհանուր փաթեթ տարբեր բաշխումների և հարթակների համար, իրականացնել ինտերակտիվ տեղադրման գործընթաց՝ իրականացնելով անհրաժեշտ հարմարեցում։ Նման փաթեթների եմ հանդիպել միայն 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 լիցենզիան հիմնականում թույլ է տալիս կապել գրադարանները միայն բաց կոդով: MIT-ը և BSD-ն թույլ են տալիս ստատիկ կապակցել և թույլ են տալիս գրադարաններին ներառել նախագծում: Բայց LGPL-ը կարծես թե չի հակասում ստատիկ կապին, այլ պահանջում է, որ կապելու համար անհրաժեշտ ֆայլերը համօգտագործվեն:
Ընդհանուր առմամբ, դինամիկ կապի օգտագործումը ձեզ կխանգարի որևէ բան տրամադրել:
C/C++ հավելվածների ստեղծում
Տարբեր հարթակների և բաշխումների համար C/C++ հավելվածներ ստեղծելու համար բավական է ընտրել կամ կառուցել gcc-ի համապատասխան տարբերակը և օգտագործել խաչաձև կոմպիլյատորներ հատուկ ճարտարապետությունների համար և հավաքել գրադարանների ամբողջ հավաքածուն: Այս աշխատանքը բավականին իրագործելի է, բայց բավականին անհանգիստ։ Եվ երաշխիք չկա, որ ընտրված կոմպիլյատորը և գրադարանները կապահովեն գործունակ տարբերակ:
Ակնհայտ առավելություն. ենթակառուցվածքը մեծապես պարզեցված է, քանի որ կառուցման ամբողջ գործընթացը կարող է ավարտվել մեկ մեքենայի վրա: Բացի այդ, բավական է հավաքել երկուականների մեկ հավաքածու մեկ ճարտարապետության համար և կարող եք դրանք փաթեթավորել տարբեր բաշխումների համար նախատեսված փաթեթներում: Ահա թե ինչպես են կառուցվում veeam փաթեթները Veeam Agent-ի համար Linux-ի համար:
Ի տարբերություն այս տարբերակի, դուք կարող եք պարզապես պատրաստել ֆերմա, այսինքն, մի քանի մեքենաներ հավաքման համար: Յուրաքանչյուր նման մեքենա կտրամադրի հավելվածների հավաքում և փաթեթների հավաքում կոնկրետ բաշխման և որոշակի ճարտարապետության համար: Այս դեպքում կոմպիլյացիան իրականացվում է դիստրիբյուտորի պատրաստած միջոցներով։ Այսինքն՝ վերացված է կոմպիլյատորի պատրաստման եւ գրադարանների ընտրության փուլը։ Բացի այդ, կառուցման գործընթացը կարելի է հեշտությամբ զուգահեռացնել:
Այնուամենայնիվ, այս մոտեցման մի թերություն կա. նույն ճարտարապետության մեջ յուրաքանչյուր բաշխման համար դուք պետք է հավաքեք ձեր սեփական երկուական ֆայլերը: Մյուս թերությունն այն է, որ նման մեծ թվով մեքենաներ պետք է պահպանվեն և մեծ քանակությամբ սկավառակի տարածություն և օպերատիվ հիշողություն պետք է հատկացվի:
Այսպես են կազմվում veeamsnap միջուկի մոդուլի KMOD փաթեթները Red Hat բաշխումների համար։
Բացեք Build Service
SUSE-ի գործընկերները փորձեցին իրականացնել որոշակի միջին հիմք հավելվածների կազմման և փաթեթներ հավաքելու հատուկ ծառայության տեսքով. .
Ըստ էության, դա հիպերվիզոր է, որը ստեղծում է վիրտուալ մեքենա, տեղադրում է դրա մեջ բոլոր անհրաժեշտ փաթեթները, կազմում է հավելվածը և կառուցում փաթեթը այս մեկուսացված միջավայրում, որից հետո վիրտուալ մեքենան ազատվում է։
OpenBuildService-ում ներդրված ժամանակացույցը կորոշի, թե քանի վիրտուալ մեքենաներ այն կարող է գործարկել փաթեթի կառուցման օպտիմալ արագության համար: Ներկառուցված ստորագրման մեխանիզմը կստորագրի փաթեթները և կվերբեռնի դրանք ներկառուցված պահոց: Ներկառուցված տարբերակի կառավարման համակարգը կփրկի փոփոխությունների և կառուցումների պատմությունը: Մնում է պարզապես ավելացնել ձեր աղբյուրները այս համակարգին: Դուք նույնիսկ ստիպված չեք լինի ինքնուրույն կարգավորել սերվերը, կարող եք օգտագործել բացը:
Սակայն խնդիր կա. նման կոմբայնը դժվար է տեղավորվում առկա ենթակառուցվածքի մեջ։ Օրինակ, տարբերակի վերահսկումը անհրաժեշտ չէ, մենք արդեն ունենք մեր սեփականը աղբյուրի կոդերի համար: Մեր ստորագրության մեխանիզմը տարբեր է՝ մենք օգտագործում ենք հատուկ սերվեր։ Պահեստը նույնպես անհրաժեշտ չէ:
Բացի այդ, այլ բաշխումների աջակցությունը, օրինակ՝ Red Hat-ը, բավականին վատ է իրականացվում, ինչը հասկանալի է:
Նման ծառայության առավելությունը SUSE բաշխման հաջորդ տարբերակի արագ աջակցությունն է: Մինչ թողարկման պաշտոնական հայտարարությունը, հավաքման համար անհրաժեշտ փաթեթները տեղադրվում են հանրային պահեստում: Նորը հայտնվում է OpenBuildService-ի հասանելի բաշխումների ցանկում: Մենք ստուգում ենք վանդակը և այն ավելացվում է կառուցման պլանին: Այսպիսով, բաշխման նոր տարբերակի ավելացումը կատարվում է գրեթե մեկ սեղմումով։
Մեր ենթակառուցվածքում, օգտագործելով OpenBuildService-ը, հավաքվում են SUSE բաշխումների համար veeamsnap միջուկի մոդուլի KMP փաթեթների ողջ բազմազանությունը:
Հաջորդը, ես կցանկանայի անդրադառնալ միջուկի մոդուլներին հատուկ խնդիրների վրա:
միջուկ 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-ի համատեղելիության խնդիրների պատճառով:
Այն բանից հետո, երբ RHEL 7.0-ի համար կազմված veeamsnap մոդուլը անհամատեղելի էր RHEL 7.5-ի միջուկի հետ, բայց այն բեռնվեց և երաշխավորված էր, որ կխափանվեր սերվերը, մենք ընդհանրապես հրաժարվեցինք RHEL 7-ի համար kABI համատեղելիության օգտագործումից:
Ներկայումս RHEL 7-ի համար KMOD փաթեթը պարունակում է հավաքում յուրաքանչյուր թողարկման տարբերակի համար և մոդուլը բեռնող սցենար:
SUSE-ն ավելի ուշադիր մոտեցավ kABI-ի համատեղելիության խնդրին: Նրանք ապահովում են kABI-ի համատեղելիությունը միայն մեկ սպասարկման փաթեթի շրջանակներում:
Օրինակ, SLES 12-ի թողարկումը տեղի ունեցավ 2014 թվականի սեպտեմբերին, իսկ SLES 12 SP1-ն արդեն 2015 թվականի դեկտեմբերին էր, այսինքն՝ անցել է մեկ տարուց մի փոքր ավելի: Չնայած երկու թողարկումներն էլ օգտագործում են 3.12 միջուկը, դրանք kABI անհամատեղելի են: Ակնհայտ է, որ kABI-ի համատեղելիությունը պահպանելը ընդամենը մեկ տարի շատ ավելի հեշտ է: Տարեկան միջուկի մոդուլի թարմացման ցիկլը չպետք է խնդիրներ առաջացնի մոդուլ ստեղծողների համար:
Այս SUSE քաղաքականության արդյունքում մենք մեր veeamsnap մոդուլում kABI համատեղելիության հետ կապված ոչ մի խնդիր չենք գրանցել: Ճիշտ է, SUSE-ի համար փաթեթների թիվը գրեթե մի կարգով ավելի մեծ է:
Կարկատաններ և հետնամասեր
Չնայած դիստրիբյուտորները փորձում են ապահովել kABI-ի համատեղելիությունը և միջուկի կայունությունը, նրանք նաև փորձում են բարելավել կատարողականը և վերացնել այս կայուն միջուկի թերությունները:
Միևնույն ժամանակ, բացի սեփական «սխալների վրա աշխատանքից», ձեռնարկության Linux միջուկի մշակողները վերահսկում են վանիլային միջուկի փոփոխությունները և դրանք փոխանցում իրենց «կայուն» միջուկին:
Երբեմն դա հանգեցնում է նորերի .
Red Hat 6-ի վերջին թողարկումում սխալ է թույլ տրվել փոքր թարմացումներից մեկում: Դա հանգեցրեց այն փաստին, որ veeamsnap մոդուլը երաշխավորված էր խափանել համակարգը, երբ հրապարակվեց snapshot-ը: Համեմատելով միջուկի աղբյուրները թարմացումից առաջ և հետո՝ մենք պարզեցինք, որ դրա մեղավորը backport-ն էր։ Նմանատիպ շտկում արվել է վանիլի միջուկի 4.19 տարբերակում: Պարզապես այս շտկումը լավ էր աշխատում վանիլային միջուկում, բայց այն «կայուն» 2.6.32-ին փոխանցելիս խնդիր առաջացավ սպինբլոկի հետ։
Իհարկե, բոլորի մոտ միշտ էլ սխալներ են լինում, բայց արժե՞ր արդյոք կոդը 4.19-ից քաշել 2.6.32՝ վտանգելով կայունությունը։ Վստահ չեմ...
Ամենավատն այն է, երբ մարքեթինգը ներգրավվում է «կայունության» և «արդիականացման» միջև պայքարի մեջ: Մարքեթինգի բաժնին անհրաժեշտ է, որ թարմացված բաշխման միջուկը մի կողմից լինի կայուն, և միևնույն ժամանակ կատարողականով ավելի լավ լինի և ունենա նոր հնարավորություններ: Սա հանգեցնում է տարօրինակ փոխզիջումների։
Երբ ես փորձեցի SLES 4.4 SP12-ից 3 միջուկի վրա մոդուլ կառուցել, ես զարմացա, որ դրա մեջ ֆունկցիոնալություն գտա վանիլային 4.8-ից: Իմ կարծիքով, SLES 4.4 SP12-ից 3 միջուկի բլոկ I/O իրականացումը ավելի նման է 4.8 միջուկին, քան SLES4.4 SP12-ից կայուն 2 միջուկի նախորդ թողարկումը: Ես չեմ կարող դատել, թե կոդի քանի տոկոսն է փոխանցվել միջուկից 4.8-ից SLES 4.4 SP3-ի համար, բայց ես նույնիսկ չեմ կարող միջուկն անվանել նույն կայուն 4.4:
Սրա մեջ ամենատհաճն այն է, որ մոդուլ գրելիս, որը հավասարապես լավ կաշխատի տարբեր միջուկների վրա, այլևս չի կարելի հիմնվել միջուկի տարբերակի վրա։ Պետք է հաշվի առնել նաև բաշխումը։ Լավ է, որ երբեմն կարող ես ներգրավվել մի սահմանման մեջ, որը հայտնվում է նոր ֆունկցիոնալության հետ մեկտեղ, բայց միշտ չէ, որ այդ հնարավորությունը հայտնվում է:
Արդյունքում, կոդը դառնում է գերաճած տարօրինակ պայմանական կոմպիլյացիայի հրահանգներով:
Կան նաև patches, որոնք փոխում են փաստաթղթավորված միջուկի API-ն:
Ես հանդիպեցի բաշխմանը 5.16 և շատ զարմացա՝ տեսնելով, որ այս միջուկի տարբերակում lookup_bdev զանգը փոխեց մուտքագրման պարամետրերի ցանկը:
Այն հավաքելու համար ես պետք է սկրիպտ ավելացնեմ makefile-ում, որը ստուգում է, թե արդյոք 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-ում սահմանեք տարբերակը Անվտանգ Boot հնարավոր է միայն վեբ ինտերֆեյսի հին տարբերակում, որն աշխատում է Flash-ի միջոցով: HTML-5-ի վեբ միջերեսը դեռ շատ հետ է մնում:
Փորձարարական բաշխումներ
Եվ վերջապես, եկեք դիտարկենք առանց պաշտոնական աջակցության փորձարարական բաշխումների և բաշխումների հարցը: Մի կողմից, նման բաշխումներ դժվար թե գտնվեն լուրջ կազմակերպությունների սերվերներում։ Նման բաշխումների պաշտոնական աջակցություն չկա: Հետեւաբար, տրամադրեք դրանք: Արտադրանքը չի կարող աջակցվել նման բաշխման վրա:
Այնուամենայնիվ, նման բաշխումները դառնում են հարմար հարթակ նոր փորձնական լուծումներ փորձելու համար։ Օրինակ՝ Fedora, OpenSUSE Tumbleweed կամ Debian-ի անկայուն տարբերակները։ Նրանք բավականին կայուն են։ Նրանք միշտ ունեն ծրագրերի նոր տարբերակներ և միշտ նոր միջուկ: Մեկ տարուց այս փորձնական գործառույթը կարող է հայտնվել թարմացված RHEL, SLES կամ Ubuntu-ում:
Այսպիսով, եթե ինչ-որ բան չի աշխատում փորձարարական բաշխման վրա, սա խնդիր է պարզելու և այն լուծելու պատճառ: Դուք պետք է պատրաստ լինեք այն փաստին, որ այս գործառույթը շուտով կհայտնվի օգտատերերի արտադրական սերվերներում:
Դուք կարող եք ուսումնասիրել 3.0 տարբերակի համար պաշտոնապես աջակցվող բաշխումների ընթացիկ ցանկը . Բայց բաշխումների իրական ցանկը, որոնց վրա մեր արտադրանքը կարող է աշխատել, շատ ավելի լայն է:
Անձամբ ինձ հետաքրքրում էր Elbrus OS-ի փորձը: Veeam փաթեթը վերջնական տեսքի բերելուց հետո մեր արտադրանքը տեղադրվեց և աշխատեց: Ես գրել եմ այս փորձի մասին Habré-ում .
Դե, նոր բաշխումների աջակցությունը շարունակվում է: Մենք սպասում ենք 4.0 տարբերակի թողարկմանը։ Բետա-ն շուտով կհայտնվի, այնպես որ ուշադիր եղեք !
Source: www.habr.com