Стварыць прыкладанне для рэзервовага капіявання, якое працуе на любым дыстрыбутыве – задача няпростая. Каб забяспечыць працу Veeam Agent for Linux на дыстрыбутывах ад Red Hat 6 і Debian 6, да OpenSUSE 15.1 і Ubuntu 19.04 даводзіцца вырашаць спектр праблем, асабліва калі ўлічыць, што ў склад праграмнага прадукта ўваходзіць модуль ядра.
Артыкул створаны па матэрыялах выступлення на канферэнцыі .
Linux - гэта не проста адна з самых папулярных АС. Па сутнасці, гэта платформа, на базе якой можна зрабіць нешта ўнікальнае, нешта сваё. Дзякуючы гэтаму ў Linux мноства дыстрыбутываў, якія адрозніваюцца наборам праграмных кампанентаў. І тут узнікае праблема: каб праграмны прадукт функцыянаваў на любым дыстрыбутыве, даводзіцца ўлічваць асаблівасці кожнага.
Пакетныя менеджэры. .deb vs .rpm
Пачнём з відавочнай праблемы распаўсюджвання прадукта для розных дыстрыбутываў.
Самы тыповы спосаб распаўсюджвання праграмных прадуктаў - гэта выкласці пакет на рэпазітар, каб убудаваны ў сістэму пакетны мэнэджар змог яго адтуль усталяваць.
Аднак папулярных фарматаў пакетаў у нас два: абаротаў у хвіліну и дэбютантка. Значыць, давядзецца падтрымаць кожны.
У свеце 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 абнавіўся пакет праклёны з версіі 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.
Альтэрнатыва пакетным мэнэджэрам
Праблема з залежнасцямі старая і даўно відавочная. Успомніць хаця б Dependency hell.
Аб'яднаць разнастайныя бібліятэкі і прыкладанні так, каб усе яны стабільна працавалі і не канфліктавалі – уласна, гэтую задачу і спрабуе вырашаць любы дыстрыб'ютар Linux.
Зусім інакш спрабуе вырашаць гэтую праблему пакетны мэнэджар Энергічны ад Canonical. Асноўная ідэя: дадатак выконваецца ў ізаляванай і абароненай ад асноўнай сістэмы пясочніцы. Калі з дадаткам патрэбны бібліятэкі, то яны пастаўляюцца разам з самім дадаткам.
Flatpak таксама дазваляе запускаць прыкладанні ў пясочніцы, выкарыстоўваючы Linux Containers. Ідэю пясочніцы выкарыстоўвае і AppImage.
Гэтыя рашэнні дазваляюць ствараць адзін пакет для любых дыстрыбутываў. У выпадку з Flatpak усталёўка і запуск прыкладання магчымая нават без вядзёнай адміністратара.
Асноўная праблема ў тым, што не ўсе прыкладанні могуць працаваць у пясочніцы. Некаторым патрэбны прамы зварот да платформы. Я ўжо не кажу пра модулі ядра, якія цвёрда залежаць ад ядра і ніяк не ўпісваюцца ў канцэпцыю пясочніцы.
Другая праблема - папулярныя ў enterprise-асяроддзі дыстрыбутывы ад Red Hat і SUSE яшчэ не ўтрымліваюць падтрымку Snappy і Flatpak.
У сувязі з гэтым Veeam Agent for Linux няма ні на ні на .
У завяршэнне пытання аб пакетных мэнэджарах заўважу, што ёсць варыянт адмовіцца зусім ад пакетных мэнэджараў, аб'яднаўшы ў адзін пакет бінарныя файлы і скрыпт для іх усталёўкі.
Такі bundle дазваляе стварыць адзін агульны пакет для розных дыстрыбутываў і платформаў, вырабляць інтэрактыўны працэс усталёўкі, ажыццяўляючы неабходную кастамізацыю. Я сутыкаўся з такімі пакетамі для Linux толькі ад VMware.
Праблема абнаўленняў
Нават калі ўсе праблемы з залежнасцямі вырашаны, праграма можа працаваць па-рознаму на адным і тым жа дыстрыбутыве. Справа ў абнаўленнях.
Ёсць 3 стратэгіі абнаўлення:
- Самая простая - не абнаўляць ніколі. Наладзіў сервер і забыўся. Навошта абнаўленні, калі ўсё працуе? Праблемы пачынаюцца пры першым жа звароце ў службу падтрымкі. Стваральнік дыстрыбутыва падтрымлівае толькі абноўлены рэліз.
- Можна даверыцца дыстрыбутару і наладзіць аўтаматычнае абнаўленне. У гэтым выпадку званок у службу падтрымкі верагодны адразу пасля няўдалага абнаўлення.
- Варыянт ручнога абнаўлення толькі пасля яго абкаткі на тэставай інфраструктуры - самы дакладны, але дарагі і працаёмкі. Далёка не ўсе здольныя яго сабе дазволіць.
Бо розныя карыстачы ўжываюць розныя стратэгіі абнаўлення, то і падтрымліваць трэба і самы свежы рэліз, і ўсё раней выпушчаныя. Гэта ўскладняе і працэс распрацоўкі, і працэс тэсціравання, дадае галаўнога болю службе падтрымкі.
Разнастайнасць апаратных платформ
Розныя апаратныя платформы - гэта праблема, у значнай ступені спецыфічная менавіта для native-кода. Як мінімум, даводзіцца збіраць бінарнікі для кожнай падтрымліваемай платформы.
У праекце Veeam Agent for Linux мы ўсё ніяк не можам падтрымаць хоць што-небудзь такое RISC-авае.
Падрабязна спыняцца на гэтым пытанні не буду. Абазначу толькі асноўныя праблемы: платформазалежныя тыпы, такія як size_t, выраўноўванне структур і byte order.
Статычная і/або дынамічная лінкоўка
А вось пытанне "Як лінкавацца з бібліятэкамі - дынамічна ці статычна?" варта абмеркаваць.
Як правіла, З/З++ прыкладанні пад Linux выкарыстаюць дынамічную лінкоўку. Гэта выдатна працуе ў тым выпадку, калі праграма сабрана спецыяльна пад канкрэтны дыстрыбутыў.
Калі ж стаіць задача ахапіць разнастайныя дыстрыбутывы адным бінарным файлам, тое даводзіцца арыентавацца на самы стары які падтрымліваецца дыстрыбутыў. Для нас гэта Red Hat 6. Ён утрымоўвае gcc 4.4, які нават стандарт З++11 падтрымлівае не .
Мы збіраем наш праект з дапамогай gcc 6.3, які поўнасцю падтрымлівае C++14. Натуральна, у такім выпадку на Red Hat 6 бібліятэку libstdc++ і boost даводзіцца цягнуць з сабой. Прасцей за ўсё лінкавацца з імі статычна.
Але нажаль, не са ўсімі бібліятэкамі можна лінкавацца статычна.
Па-першае, сістэмныя бібліятэкі, такія як libfuse, libblkid неабходна лінкаваць дынамічна, каб быць упэўненым у сумяшчальнасці іх з ядром і яго модулямі.
Па-другое, ёсць тонкасць з ліцэнзіямі.
Лінцэнзія GPL у прынцыпе дазваляе лінкаваць бібліятэкі толькі з opensource кодам. MIT і BSD дазваляюць статычную лінкоўку і дазваляюць уключаць бібліятэкі ў праект. А вось LGPL накшталт як не супярэчыць статычнай лінкоўцы, але патрабуе падаць у агульны доступ файлы, неабходныя для звязвання.
У агульным выпадку выкарыстанне дынамічнай лінкоўкі засцеражэ ад неабходнасці нешта падаваць.
Зборка З/З++ прыкладанняў
Для зборкі З/З++ прыкладанняў для розных платформаў і дыстрыбутываў досыць падабраць ці сабраць gcc падыходнай версіі і скарыстацца крос-кампілятарамі для спецыфічных архітэктур, сабраць увесь набор бібліятэк. Праца гэта цалкам рэалізуемая, але даволі клапотная. І няма ніякіх гарантый, што абраны кампілятар і бібліятэкі забяспечаць працаздольны варыянт.
Відавочны плюс: моцна спрашчаецца інфраструктура, бо ўвесь працэс зборкі можна выканаць на адной машыне. Акрамя таго, дастаткова сабраць адзін набор бінарных файлаў для адной архітэктуры і можна пакаваць іх у пакеты для розных дыстрыбутываў. Менавіта так збіраюцца пакеты veeam для Veeam Agent for Linux.
У процівагу гэтаму варыянту можна проста падрыхтаваць build ферму, гэта значыць некалькі машын для зборкі. Кожная такая машына будзе забяспечваць кампіляцыю дадатку і зборку пакета для канкрэтнага дыстрыбутыва і пэўнай архітэктуры. У такім выпадку кампіляцыя робіцца тымі сродкамі, якія падрыхтаваў дыстрыбутар. Гэта значыць, этап падрыхтоўкі кампілятара і падбор бібліятэк адпадае. Акрамя таго, працэс зборкі можа быць лёгка распаралельны.
Ёсць, праўда, і мінус у такога падыходу: для кожнага дыстрыбутыва ў рамках адной архітэктуры давядзецца збіраць свой набор бінарных файлаў. Таксама мінусам з'яўляецца тое, што такое мноства машын трэба абслугоўваць, вылучаць вялікую колькасць дыскавай прасторы і аператыўнай памяці.
Такім чынам збіраюцца KMOD пакеты модуля ядра veeamsnap пад дыстрыбутывы Red Hat.
Open Build Service
Калегі з SUSE паспрабавалі рэалізаваць некаторую залатую сярэдзіну ў выглядзе спецыяльнага сэрвісу для кампіляцыі прыкладанняў і зборкі пакетаў. .
Па сутнасці, гэта гіпервізор, які стварае віртуальную машыну, усталёўвае ў ёй усе неабходныя пакеты, выконвае кампіляцыю прыкладання і зборку пакета ў гэтым ізаляваным асяроддзі, пасля чаго такая віртуальная машына вызваляецца.
Рэалізаваны ў OpenBuildService планавальнік сам вызначыць, колькі віртуальных машын ён можа запусціць для аптымальнай хуткасці зборкі пакетаў. Убудаваны механізм подпісу сам падпіша пакеты і выкладзе іх на ўбудаваны рэпазітар. Убудаваная сістэма версійнага кантролю захавае гісторыю змен і зборак. Застаецца проста дадаць у гэтую сістэму свае зыходнікі. Нават сервер самому паднімаць не абавязкова, а можна скарыстацца адчыненым.
Тут, праўда, ёсць праблема: такі камбайн цяжка ўпісваецца ў існуючую інфраструктуру. Напрыклад, версійны кантроль не патрэбен, у нас ужо ёсць свой для зыходнікаў. Механізм подпісу ў нас адрозніваецца: выкарыстоўваецца спецыяльны сервер. Рэпазітар таксама не патрэбен.
Акрамя таго, падтрымка іншых дыстрыбутываў – да прыкладу, Red Hat – рэалізаваная даволі бедна, што цалкам вытлумачальна.
Вартасцю такога сэрвісу з'яўляецца хуткая падтрымка чарговай версіі дыстрыбутыва SUSE. Да афіцыйнай аб'явы аб рэлізе неабходныя для зборкі пакеты выкладваюцца на публічны рэпазітар. У спісе даступных дыстрыбутываў на OpenBuildService з'яўляецца новы. Выстаўляем галачку, і ён дадаецца ў план зборкі. Такім чынам, даданне новай версіі дыстрыбутыва выконваецца практычна ў адзін клік.
У нашай інфраструктуры з выкарыстаннем OpenBuildService збіраецца ўся разнастайнасць KMP пакетаў модуля ядра veeamsnap для дыстрыбутываў SUSE.
Далей я хацеў бы спыніцца на пытаннях, спецыфічных менавіта для модуляў ядра.
kernel ABI
Модулі ядра Linux гістарычна распаўсюджваліся ў выглядзе зыходных тэкстаў. Справа ў тым, што стваральнікі ядра не абцяжарваюць сябе клопатам аб падтрымцы стабільнага API для модуляў ядра, а тым больш на бінарным узроўні, далей kABI.
Каб сабраць модуль для ванільнага ядра, абавязкова патрэбныя header-ы менавіта гэтага ядра, і працаваць ён будзе толькі на гэтым ядры.
DKMS дазваляе аўтаматызаваць працэс зборкі модуляў пры абнаўленні ядра. У выніку карыстачы рэпазітара Debian (і яго шматлікіх сваякоў) выкарыстаюць модулі ядра або з рэпазітара дыстрыбутара, або збіраныя з зыходнікаў з дапамогай DKMS.
Аднак такая сітуацыя не асоба задавальняе Enterprise-сегмент. Распаўсюджвальнікі прапрыетарнага кода жадаюць распаўсюджваць прадукт у выглядзе сабраных бінарнікаў.
Адміністратары не жадаюць трымаць сродкі распрацоўкі на production-серверах з меркаванняў бяспекі. Дыстрыбутары Enterprise Linux – такія, як Red Hat і SUSE – вырашылі, што для сваіх карыстачоў стабільнае kABI яны змогуць падтрымаць. У выніку з'явіліся пакеты KMOD для Red Hat і пакеты KMP для SUSE.
Сутнасць такога рашэння даволі простая. Для канкрэтнай версіі дыстрыбутыва API ядра freeze-іцца. Дыстрыбутар заяўляе, што ён выкарыстоўвае менавіта ядро, напрыклад, 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 сумяшчальнасць толькі ў рамках аднаго сэрвіснага пакета.
Напрыклад, рэліз 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 ядра ад SLES12 SP2. Які быў адсотак перанесенага кода з ядра 4.8 у SLES-аўскі 4.4 для SP3 я судзіць не бяруся, аднак назваць ядро ўсё тым жа стабільным 4.4 у мяне мова не паварочваецца.
Самае непрыемнае ў гэтым тое, што пры напісанні модуля, які б аднолькава добра працаваў на розных ядрах, больш нельга абапірацца на версію ядра. Даводзіцца яшчэ і ўлічваць дыстрыбутыў. Добра, што часам можна завязацца на дэфайн, які з'яўляецца разам з новым функцыяналам, аднак такая магчымасць з'яўляецца не заўсёды.
У выніку код абрастае мудрагелістымі дырэктывамі ўмоўнай кампіляцыі.
Сустракаюцца яшчэ і патчы, якія мяняюць задакументаванае API ядра.
Натыкнуўся на дыстрыбутыў 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 for Windows Server 2012R2.
Аднак у дэфолтнай канфігурацыі гэты функцыянал для Linux машын выключаны, а значыць, сертыфікат усталяваць нельга.
У vSphere 6.5 выставіць опцыю бяспечная загрузка можна толькі ў старой версіі вэб-інтэрфейсу, які працуе праз Flash. Web UI на HTML-5 пакуль моцна адстае.
Эксперыментальныя дыстрыбутывы
Ну і напрыканцы разгледзім пытанне эксперыментальных дыстрыбутываў і дыстрыбутываў без афіцыйнай падтрымкі. З аднаго боку, такія дыстрыбутывы ці наўрад сустрэнеш на серверах сур'ёзных арганізацый. Афіцыйнай падтрымкі ў такіх дыстрыбутываў няма. Таму і забяспечваць тых. падтрымку прадукта на такім дыстрыбутыве нельга.
Аднак такія дыстрыбутывы становяцца зручнай пляцоўкай для спробы новых эксперыментальных рашэнняў. Напрыклад, Fedora, OpenSUSE Tumbleweed ці Unstable версіі Debian. Яны дастаткова стабільныя. У іх заўжды новыя версіі праграм і заўсёды новае ядро. Праз год гэты эксперыментальны функцыянал можа апынуцца ў абноўленым RHEL, SLES ці Ubuntu.
Так што калі нешта не працуе на эксперыментальным дыстрыбутыве - гэта нагода разабрацца ў праблеме і вырашыць яе. Трэба быць гатовым да таго, што гэты функцыянал хутка з'явіцца на production-серверах карыстальнікаў.
Існуючы на бягучы момант спіс афіцыйна падтрымліваемых дыстрыбутываў для версіі 3.0 вы можаце вывучыць . Але рэальны спіс дыстрыбутываў, на якіх наш прадукт здольны працаваць, нашмат шырэй.
Асабіста мне быў цікавы эксперымент з АС "Эльбрус". Пасля дапрацоўкі пакета veeam наш прадукт устанавіўся і зарабіў. Пра гэты эксперымент я пісаў на Хабры ў .
Ну а падтрымка новых дыстрыбутываў працягваецца. Чакаем з'яўленні на свет версіі 4.0. Вось-вось павінна з'явіцца бэта, так што сочыце за !
Крыніца: habr.com