Olyan alkalmazás létrehozása, amely bármely disztribúción működik, nem egyszerű feladat. Ahhoz, hogy a Veeam Agent for Linux működjön a Red Hat 6 és a Debian 6 disztribúciókon, egészen az OpenSUSE 15.1-ig és az Ubuntu 19.04-ig, számos problémát kell megoldani, különösen figyelembe véve, hogy a szoftvercsomag tartalmaz egy kernel modult.
A cikk a konferencián tartott előadás anyagai alapján készült .
A Linux nem csupán az egyik legnépszerűbb operációs rendszer. Valójában ez egy platform, amelyen valami egyedit, valami sajátot hozhatunk létre. Ennek köszönhetően a Linuxnak számos disztribúciója van, amelyek eltérő szoftverkomponens-csoportokkal rendelkeznek. Itt azonban felmerül a probléma: ahhoz, hogy a szoftvertermék bármely disztribúción működjön, figyelembe kell venni a különböző sajátosságokat.
Csomagkezelők. .deb vs .rpm
Kezdjük azzal a nyilvánvaló problémával, hogy a termék terjesztése különböző disztribúciók között.
A legtipikusabb módja a szoftvertermékek terjesztésének az, hogy a csomagot feltöltjük egy tárolóba, hogy a rendszerbe épített csomagkezelő onnan telepíthesse azt.
Azonban két népszerű csomagformátumunk van: rpm és deb. Ezért mindkettőt támogatni kell.
A deb-csomagok világában a kompatibilitás szintje lenyűgöző. Ugyanaz a csomag egyformán jól telepíthető és működik a Debian 6-on és az Ubuntu 19.04-en is. A csomagok létrehozásának és kezelésének folyamata során alkalmazott szabványok, amelyeket a régi Debian disztribúciókban fektettek le, továbbra is érvényesek az új Linux Mint és elementary OS esetében is. Ezért a Veeam Agent for Linux esetében elegendő egy deb-csomag minden hardverplatformhoz.
A rpm-csomagok világában azonban jelentős eltérések vannak. Először is, azért, mert két teljesen független forgalmazó van, a Red Hat és a SUSE, amelyek számára nem szükséges a kompatibilitás. Másodszor, ezeknek a forgalmazóknak vannak támogatott és kísérleti disztribúcióik. Ezek között sem szükséges a kompatibilitás. Ezért a el6, el7 és el8 számára külön csomagok készültek. Külön csomag a Fedora számára. Csomagok a SLES11 és 12 számára, valamint külön az openSUSE-hoz. A fő probléma a függőségekben és a csomagok neveiben rejlik.
A függőségek problémája
Sajnos ugyanezek a csomagok gyakran eltérő neveken szerepelnek különböző disztribúciókban. Az alábbiakban nem teljes lista a veeam csomag függőségeiről.
EL7 esetén:
SLES 12 esetén:
- 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
Ennek eredményeként a függőségek listája egyedivé válik a disztribúció számára.
Rosszabb, amikor a régi csomagnév alatt kezd el bújni egy frissített verzió.
Példa:
A Fedora 24-ben frissült a csomag ncurses 5-ös verzióról 6-os verzióra. A termékünket pontosan az 5-ös verzióval állították össze, hogy kompatibilis legyen a régi disztribúciókkal. Ahhoz, hogy az 5-ös verziójú könyvtárat használhassuk a Fedora 24-en, a ncurses-compat-libs.
ezért a Fedora számára két csomag jelenik meg, különböző függőségekkel.
Tovább izgalmasabb. A disztribúció következő frissítése után a csomag ncurses-compat-libs az 5-ös verziójú könyvtárral nem elérhető. A forgalmazónak költséges a régi könyvtárakat új disztribúcióba hozni. Egy idő után a probléma megismétlődött a SUSE disztribúciókban is.
Ennek eredményeként egyes disztribúciókban el kellett mondani a nyílt függőségről a ncurses-libs, a terméket pedig úgy kellett módosítani, hogy bármely verziójú könyvtárral működjön.
Egyébként a Red Hat 8-as verziójában már nincs meta-csomag python, ami a régi jó python 2.7. Létezik python2 és python3.
Alternatíva a csomagkezelők számára
A függőségekkel kapcsolatos probléma régi és régóta nyilvánvaló. Gondoljunk csak a Dependency hell-re.
A különböző könyvtárakat és alkalmazásokat úgy összehangolni, hogy minde különböző konfliktusok nélkül stabilan működjön – gyakorlatilag ezt a feladatot próbálja megoldani minden Linux forgalmazó.
Teljesen másképp próbálja kezelni ezt a problémát a Snappy a Canonical-tól. Az alapötlet: az alkalmazás egy elszigetelt és a fő rendszertől védett homokozóban működik. Ha az alkalmazásnak könyvtárakra van szüksége, azokat együtt biztosítják magával az alkalmazással.
Flatpak ez lehetővé teszi az alkalmazások futtatását a homokozóban, Linux Containers használatával. A homokozó ötletét használja AppImage.
Ezek a megoldások lehetővé teszik egy csomag létrehozását bármely disztribúció számára. Az esetében a Flatpak a telepítés és az alkalmazás elindítása még az adminisztrátor tudta nélkül is lehetséges.
A fő probléma az, hogy nem minden alkalmazás tud működni a homokozóban. Néhány közvetlen hozzáférést igényel a platformhoz. Már arra sem beszélek a kernel modulokról, amelyek szorosan függenek a kerneltől és sehogy sem illeszkednek a homokozó koncepciójába.
A második probléma – a Red Hat és SUSE enterprise környezetében népszerű disztribúciók még nem támogatják a Snappy-t és a Flatpak-ot.
Ennek megfelelően a Veeam Agent for Linux nem elérhető sem a sem a .
A csomagkezelők témáját lezárva megjegyzem, hogy van lehetőség teljesen lemondani a csomagkezelőkről, és egyetlen csomagba egyesíteni a bináris fájlokat és a telepítő scriptet.
Az ilyen bundle lehetővé teszi, hogy egy közös csomagot hozzunk létre különböző disztribúciókhoz és platformokhoz, interaktív telepítési folyamatot végezve, a szükséges testreszabásokat elvégezve. Eddig csak VMware-től találkoztam ilyen csomagokkal a Linux számára.
A frissítések problémája
Még ha minden függőségi probléma meg is oldódik, a program eltérően működhet ugyanazon disztribúción belül. A probléma a frissítésekkel van.
Három frissítési stratégia létezik:
- A legegyszerűbb - soha nem frissíteni. Beállította a szervert és elfelejtette. Miért lenne szükség frissítésekre, ha minden működik? A problémák az első ügyfélszolgálati híváskor kezdődnek. A disztribúció készítője csak a legfrissebb kiadást támogatja.
- Bízni lehet a disztribúció készítőjében, és automatikus frissítést beállítani. Ilyen esetben a hívás az ügyfélszolgálatra valószínűleg rögtön a hibás frissítés után történik.
- A manuális frissítési lehetőség csak a tesztelési infrastruktúráján való kiértékelés után a legbiztonságosabb, de költséges és időigényes. Messze nem mindenki engedheti meg magának ezt.
Mivel a felhasználók különböző frissítési stratégiákat alkalmaznak, szükséges támogatni a legfrissebb kiadást, és az összes korábban kiadottat is. Ez bonyolítja a fejlesztési és tesztelési folyamatokat, és több fejtörést jelent az ügyfélszolgálatnak.
A hardverplatformok sokfélesége
A különböző hardverplatformok problémát jelentenek, főként a natív kódra vonatkozóan. Legalább annyit biztosan meg kellene csinálni, hogy a támogatott platformokhoz különféle binárisokat kell készíteni.
A Veeam Agent for Linux projektben még mindig nem tudunk támogatni semmit, ami RISC alapú.
Erről a kérdésről részletesebben nem szeretnék beszélni. Csak a főbb problémákat említem: platformfüggő típusok, mint például size_t, struktúrák igazítása és byte order.
Statikus és/vagy dinamikus linkelés
A kérdés, hogy "Hogyan linkeljünk a könyvtárakkal - dinamikusan vagy statikusan?" megér egy diskurzust.
Általában a C/C++ alkalmazások Linux alatt dinamikus linkelést használnak. Ez nagyszerűen működik, ha az alkalmazás kifejezetten egy adott disztribúcióhoz készült.
Ha azonban az a cél, hogy különböző disztribúciókat egyetlen bináris fájl segítségével lefedjünk, akkor a legöregebb támogatott disztribúcióra kell orientálódnunk. Számunkra ez a Red Hat 6. Ez 4.4-es gcc-t tartalmaz, amely még a C++11 szabványt sem támogatja. .
A projektet a gcc 6.3-mal építjük, amely teljes mértékben támogatja a C++14-et. Nyilvánvaló, hogy ilyen esetben a Red Hat 6-os környezethez a libstdc++-t és a boost könyvtárakat magunkkal kell vinnünk. A legegyszerűbb statikusan linkelni ezeket.
Sajnos nem minden könyvtárral lehet statikusan linkelni.
Először is, a rendszer könyvtárakat, mint például. libfuse, libblkid , dinamikusan kell linkelni, hogy biztosak legyünk a kernel kompatibilitásában és annak moduljaival.
Másodszor, licencelési szempontból van egy árnyalat.
A GPL licenc alapvetően csak a nyílt forráskódú kóddal való linkelést engedélyezi. Az MIT és BSD engedélyezik a statikus linkelést, és lehetővé teszik a könyvtárak projektekbe való integrálását. Az LGPL viszont látszólag nem ellenkezik a statikus linkeléssel, de megköveteli, hogy a linkeléshez szükséges fájlokat közzétegyük.
Általánosságban elmondható, hogy a dinamikus linkelés használata megvédi az említett fájlok nyújtásának kötelezettségétől.
C/C++ alkalmazások építése
C/C++ alkalmazások különböző platformokhoz és disztribúciókhoz való építéséhez elegendő egy megfelelő verziójú gcc-t választani vagy összegyűjteni, és speciális architektúrákhoz használni a keresztfordítókat, összeszedve minden szükséges könyvtárat. Ez a munka teljesíthető, de meglehetősen fáradságos. És nincs garancia arra, hogy a kiválasztott fordító és könyvtárak működő verziót biztosítanak.
Nyilvánvaló előnye: nagymértékben leegyszerűsíti az infrastruktúrát, mivel az építési folyamatot egy gépen lehet elvégezni. Ezen kívül elegendő egy architektúrához egy készlet bináris fájlt összegyűjteni, és azokat csomagokba lehet pakolni különböző disztribúciókhoz. Éppen így készülnek a veeam csomagok a Veeam Agent for Linux számára.
Ezzel a megoldással szemben egyszerűen készíthetünk egy build farmot, vagyis több gépet a csomagoláshoz. Minden ilyen gép biztosítja az alkalmazás fordítását és a csomag elkészítését egy adott elosztó és architektúra számára. Ebben az esetben a fordítószerver beállítása és a könyvtárak kiválasztása elhagyható. Ráadásul a build folyamata könnyen párhuzamosítható.
Igaz, hogy van ennek a megközelítésnek egy hátránya is: minden elosztó számára, amely ugyanazon architektúra keretein belül működik, külön kell elkészítenünk a megfelelő bináris fájlokat. A másik hátrány, hogy sok gépet kell üzemeltetni, ami jelentős lemezkapacitást és RAM-ot igényel.
Így készülnek a KMOD csomagok a veeamsnap kernel modulhoz a Red Hat elosztókhoz.
Open Build Service
A SUSE kollégái megpróbálták megvalósítani a kompromisszumnak egy speciális szolgáltatást az alkalmazások fordításához és csomagolásához — .
Lényegében ez egy hypervisor, amely létrehoz egy virtuális gépet, telepíti az összes szükséges csomagot, végrehajtja az alkalmazás fordítását és a csomag elkészítését ebben az elszigetelt környezetben, majd ez a virtuális gép felszabadul.
Az OpenBuildService-ben megvalósított ütemező automatikusan meghatározza, hogy hány virtuális gépet indíthatunk a csomagok optimális sebességű összeállításához. A beépített aláíró mechanizmus automatikusan aláírja a csomagokat, és feltölti őket a beépített tárolóba. A beépített verziókezelő rendszer rögzíti a módosítások és építések történetét. Csak annyit kell tenni, hogy feltöltjük a forrásainkat a rendszerbe. A szerver felállítása sem szükséges, használhatjuk a nyílt forrást.
Itt azonban van egy probléma: ez a kombájn nehezen illeszthető a meglévő infrastruktúrába. Például a verziókezelésre nincs szükség, már van egy sajátunk a forrásokhoz. Az aláírási mechanizmusunk eltérő: egy speciális szerver található. A tárolóra sem lenne szükség.
Továbbá, más elosztók támogatása — például a Red Hat — meglehetősen gyenge, ami teljesen érthető.
Ennek a szolgáltatásnak az előnye a SUSE disztribúció legújabb verziójának gyors támogatása. A hivatalos kiadási bejelentés előtt a szükséges csomagok nyilvános adattárba kerülnek. Az OpenBuildService elérhető disztribúciós listájában új jelenik meg. Kiválasztjuk, és hozzáadódik a build tervhez. Így az új disztribúció verzióját gyakorlatilag egy kattintással hozzáadhatjuk.
Infrastrukturánkban az OpenBuildService segítségével a KMP csomagok széles választéka készül a veeamsnap kernel modulhoz a SUSE disztribúciókhoz.
Ezután szeretnék egy kicsit részletesebben foglalkozni a kernel modulokkal kapcsolatos kérdésekkel.
kernel ABI
A Linux kernel modulok történelmileg forráskód formájában terjedtek. Ennek az az oka, hogy a kernel készítői nem terhelik magukat azzal, hogy stabil API-t biztosítsanak a kernel modulok számára, és különösen nem a bináris szinten, az úgynevezett kABI-nál.
Ahhoz, hogy egy modult építsünk a vanília kernelhez, feltétlenül szükség van éppen ennek a kernelnek a header fájljaira, és csak ezen a kernelen fog működni.
A DKMS lehetővé teszi a modulok építési folyamatának automatizálását a kernel frissítésekor. Ennek következtében a Debian (és annak számos rokon) tároló felhasználói vagy a disztribútor tárolójából származó kernel modulokat, vagy forrásból DKMS segítségével épített modulokat használnak.
Azonban ez a helyzet nem igazán felel meg az Enterprise szegmens igényeinek. A proprietárius kódok terjesztői azt akarják, hogy a terméküket már összegyűjtött binárisok formájában terjesszék.
A rendszergazdák nem akarják megtartani a fejlesztési eszközöket a production szervereken biztonsági okokból. Az Enterprise Linux disztribútorok - mint például a Red Hat és a SUSE - úgy döntöttek, hogy a felhasználóik számára stabil kABI-t tudnak biztosítani. Ennek eredményeként KMOD csomagok alakultak ki a Red Hat számára és KMP csomagok a SUSE számára.
Ez a megoldás lényege meglehetősen egyszerű. Egy adott disztribúció verzióhoz a kernel API fagyasztva van. A disztribútor bejelenti, hogy például a 3.10-es kernelt használja, és csak olyan javításokat és fejlesztéseket végez, amelyek nem érintik a kernel felületeit, míg az első kernelhez épített modulok felhasználhatók minden következő verzióra újraépítés nélkül.
A Red Hat bejelentette a kABI kompatibilitást a disztribúció életciklusa során. Ez azt jelenti, hogy a rhel 6.0-ra (2010 novemberi kiadás) készült modulnak is működnie kell a 6.10-es verzión (2018 júniusi kiadás). Ez majdnem 8 év. Természetesen, ez egy viszonylag bonyolult feladat.
Több esetet rögzítettünk, amikor a kABI kompatibilitási problémák miatt a veeamsnap modul megszűnt működni.
Miután a RHEL 7.0-ra készült veeamsnap modul nem volt kompatibilis a RHEL 7.5-ös kernellel, de egyébként betöltődött, és garantáltan összeomlott a szerver, úgy döntöttünk, hogy teljesen elhagyjuk a kABI kompatibilitást a RHEL 7 esetében.
Jelenleg a KMOD csomag a RHEL 7-hez minden verzióra tartalmaz összeállítást és egy scriptet, amely biztosítja a modul betöltését.
A SUSE óvatosabb megközelítést alkalmazott a kABI kompatibilitás ügyében. Csak egy szolgáltatáscsomagon belül biztosítják a kABI kompatibilitást.
Például a SLES 12 kiadása 2014 szeptemberében történt. A SLES 12 SP1 már 2015 decemberében megjelent, tehát picivel több mint egy év telt el. Annak ellenére, hogy mindkét kiadás a 3.12-es kernelt használja, kABI inkompatibilisek. Nyilvánvaló, hogy a kABI kompatibilitás fenntartása csupán egy év alatt sokkal egyszerűbb. Az éves kernelfrissítési ciklus nem okozhat problémát a modulfejlesztőknek.
A SUSE ilyen politikája következtében nem tapasztaltunk egyetlen kABI kompatibilitási problémát sem a veeamsnap modulunkkal. Igaz, hogy a SUSE csomagok száma közel tízszer nagyobb.
Javítások és visszaállítások
Annak ellenére, hogy a disztribútorok arra törekednek, hogy biztosítsák a kABI kompatibilitást és a kernel stabilitását, még a teljesítményjavításra és a stabil kernel hibáinak kiküszöbölésére is törekednek.
Eközben az enterprise linux kernel fejlesztői a saját "hibajavításaik" mellett figyelemmel kísérik a vanília kernel változásait, és átviszik azokat a "stabil" verziójukba.
Ez néha új .
A legutolsó Red Hat 6-os kiadás egyik kisebb frissítésében egy hiba lépett fel. Ez ahhoz vezetett, hogy a veeamsnap modul garantáltan összeomlott a snapshotok felszabadításakor. Az kernel forráskódjának az frissítés előtti és utáni összehasonlítása során kiderült, hogy a hibát a backport okozta. Hasonló javítást végeztek a 4.19-es vanília kernelnél. Csak éppen a vanília kernel ezt a javítást normálisan kezelte, míg a "stabil" 2.6.32-be történő átvitelkor probléma merült fel a spin-lockkal.
Természetesen mindenkinél, mindenhol előfordulnak hibák, de megérte-e 4.19-es kódot átvinni 2.6.32-be, kockáztatva ezzel a stabilitást?.. Nem vagyok benne biztos…
A legrosszabb, amikor a „stabilitás” és a „modernizáció” közötti húzóversenyhez a marketing is csatlakozik. A marketingosztálynak arra van szüksége, hogy az új disztribúció magja stabil legyen, egyrészt, míg másrészt mégis jobb teljesítménnyel és új funkciókkal rendelkezzen. Ez furcsa kompromisszumokhoz vezet.
Amikor megpróbáltam összeállítani egy modult a SLES 12 SP3 4.4-es kernelén, meglepetten tapasztaltam, hogy abban a vanília 4.8-as verzió funkciói megtalálhatóak. Véleményem szerint a SLES 12 SP3 4.4-es kernelének blokk I/O megvalósítása inkább hasonlít a 4.8-ra, mint a SLES 12 SP2 stabil 4.4-es verziójára. Nem tudom megítélni, hogy a 4.8-ból hány százaléknyi kódot vittek át a SLES-es 4.4-be a SP3 számára, de hogy ezt továbbra is stabil 4.4-ként emlegetni, azt nem tudom.
A legrosszabb az, hogy amikor olyan modulokat írok, amelyek egyaránt jól működnek különböző kernel verziókon, már nem lehet a kernel verzióra támaszkodni. Figyelembe kell venni a disztribúciót is. Jó, hogy néha lehet hivatkozni egy definiálásra, amely az új funkcióval együtt jelenik meg, de erre nem mindig van lehetőség.
Ennek eredményeként a kód furcsa feltételes fordítási direktívákkal gyarapszik.
Találkozni lehet olyan javításokkal is, amelyek megváltoztatják a dokumentált kernel API-t.
Beléptem egy disztribúcióba 5.16 és nagyon meglepődtem, amikor láttam, hogy a lookup_bdev hívása ebben a kernel verzióban megváltoztatta a belépő paraméterek listáját.
Az összeállításhoz hozzá kellett adnom a makefile-hoz egy szkriptet, amely ellenőrzi, hogy a lookup_bdev funkciónak van-e mask paramétere.
Kernel modulok aláírása
De térjünk vissza a csomagok terjesztésének kérdéséhez.
A stabil kABI egyik előnye, hogy a kernel modulokat bináris fájlként alá lehet írni. Ebben az esetben a fejlesztő biztos lehet abban, hogy a modul nem sérült meg véletlenül, vagy nem módosították szándékosan. Ezt a modinfo parancs segítségével lehet ellenőrizni.
A Red Hat és a SUSE disztribúciók lehetővé teszik a modul aláírásának ellenőrzését, és csak akkor töltik be, ha a rendszerben be van jegyezve a megfelelő tanúsítvány. A tanúsítvány egy nyilvános kulcs, amellyel a modult aláírják. Ezt külön csomag formájában terjesztjük.
A probléma az, hogy a tanúsítványok beépíthetők a kernelbe (ezeket az értékesítők használják), vagy az EFI nem volatilis memóriájába kell írni őket egy segédprogram segítségével. mokutil. Segédprogram mokutil a tanúsítvány telepítésekor a rendszer újraindítását kéri, és a művelet előtt, még a működési rendszer betöltődése előtt, lehetőséget ad az adminisztrátornak, hogy engedélyezze az új tanúsítvány betöltését.
Így a tanúsítvány hozzáadása fizikai adminisztrátori hozzáférést igényel a rendszerhez. Ha a gép valahol a felhőben vagy egyszerűen egy távoli szerveren található, és csak hálózaton keresztül elérhető (például ssh-n keresztül), akkor a tanúsítvány hozzáadása lehetetlen.
EFI virtuális gépeken
Bár az EFI már régóta támogatott szinte minden alaplapgyártó által, az adminisztrátor a rendszer telepítésekor nem biztos, hogy figyelembe veszi az EFI szükségességét, és az ki is lehet kapcsolva.
Nem minden hypervisor támogatja az EFI-t. A VMWare vSphere az 5-ös verziótól kezdődően támogatja az EFI-t.
A Microsoft Hyper-V szintén kapott EFI támogatást a Hyper-V for Windows Server 2012R2-től kezdődően.
Azonban az alapértelmezett beállítás szerint ez a funkció a Linux gépek esetében ki van kapcsolva, így a tanúsítvány telepítése nem lehetséges.
A vSphere 6.5-ben az opciót Secure Boot csak a régi Flash-alapú webes felületen keresztül lehet beállítani. A HTML-5 alapú Web UI még mindig jelentősen elmarad.
Kísérleti disztribúciók
Végül nézzünk meg néhány kísérleti disztribúciót és a hivatalos támogatás nélküli disztribúciókat. Egyrészt ezek a disztribúciók valószínűleg nem fordulnak elő komoly szervezetek szerverein. Ezeknek a disztribúcióknak nincs hivatalos támogatásuk. Ezért a termék technikai támogatását ilyen disztribúciókon nem lehet biztosítani.
Azonban ezek a disztribúciók kényelmes platformot nyújtanak új kísérleti megoldások kipróbálására. Például a Fedora, az OpenSUSE Tumbleweed vagy a Debian Unstable verziói. Ezek viszonylag stabilak. Mindig új programverziókat tartalmaznak, és mindig új kernel van bennük. Egy év múlva ez a kísérleti funkció megjelenhet a frissített RHEL, SLES vagy Ubuntu verziókban.
Tehát ha valami nem működik egy kísérleti disztribúción, az arra ösztönöz, hogy vizsgáljuk meg a problémát és oldjuk meg azt. Fel kell készülni arra, hogy ez a funkció hamarosan megjelenik a felhasználók produkciós szerverein.
A jelenlegi, hivatalosan támogatott 3.0 verziójú disztribúciók listáját tanulmányozhatja. De a valós disztribúciók listája, amelyeken a termékünk működik, sokkal szélesebb.
Számomra érdekes kísérlet volt az 'Elbrusz' operációs rendszerrel. A veeam csomag átdolgozása után termékünk települt és működött. Erről a kísérletről írtam a Habr-on. .
A támogatás új disztribúciók számára tovább folytatódik. A 4.0 verzió megjelenésére számítunk. Hamarosan érkezik a béta, figyeljenek a frissítésekre. !
Forrás: habr.com
