Nem könnyű feladat olyan biztonsági mentési alkalmazás létrehozása, amely bármilyen disztribúción működik. Ahhoz, hogy a Veeam Agent for Linux működjön a Red Hat 6-tól és Debian 6-tól az OpenSUSE 15.1-ig és az Ubuntu 19.04-ig terjedő disztribúciókon, számos problémát kell megoldania, különös tekintettel arra, hogy a szoftvertermék tartalmaz egy kernelmodult.
A cikk a konferencián elhangzott beszéd anyagai alapján készült .
A Linux nem csak az egyik legnépszerűbb operációs rendszer. Lényegében ez egy olyan platform, amely alapján valami egyedit, sajátot készíthet. Ennek köszönhetően a Linuxnak számos disztribúciója van, amelyek szoftverösszetevőiben különböznek egymástól. És itt egy probléma merül fel: ahhoz, hogy egy szoftvertermék bármilyen disztribúción működjön, figyelembe kell vennie mindegyik jellemzőit.
Csomagkezelők. .deb vs .rpm
Kezdjük azzal a nyilvánvaló problémával, hogy a terméket különböző disztribúciók között kell elosztani.
A szoftvertermékek terjesztésének legjellemzőbb módja, hogy a csomagot egy tárhelyre helyezzük, hogy onnan a rendszerbe épített csomagkezelő telepíthesse.
Van azonban két népszerű csomagformátumunk: fordulat и első bálozó. Ez azt jelenti, hogy mindenkinek támogatnia kell.
A deb csomagok világában a kompatibilitás szintje elképesztő. Ugyanaz a csomag telepíthető és egyformán jól működik mind a Debian 6, mind az Ubuntu 19.04 rendszeren. A régi Debian disztribúciókban lefektetett szabványok a csomagok felépítésére és a velük való munkavégzés folyamatára továbbra is érvényesek az újkeletű Linux Mintben és az elemi operációs rendszerben. Ezért a Veeam Agent for Linux esetében minden hardverplatformhoz elegendő egy deb csomag.
De az rpm csomagok világában nagyok a különbségek. Először is, amiatt, hogy van két teljesen független forgalmazó, a Red Hat és a SUSE, amelyek számára a kompatibilitás teljesen szükségtelen. Másodszor, ezek a forgalmazók rendelkeznek azokból származó elosztókészletekkel. támogató és kísérleti. Nincs szükség kompatibilitásra sem közöttük. Kiderült, hogy az el6, el7 és el8 saját csomaggal rendelkezik. Külön csomag a Fedorához. Csomagok az SLES11-hez és 12-höz, valamint egy külön az openSUSE-hoz. A fő probléma a függőségek és a csomagnevek.
Függőségi probléma
Sajnos ugyanazok a csomagok gyakran más-más néven kerülnek a különböző disztribúciókban. Az alábbiakban a veeam csomagfüggőségek részleges listája található.
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 egyedi a terjesztéshez.
Ami még rosszabb, ha egy frissített verzió a régi csomagnév alatt bujkál.
Példa:
A csomag frissült a Fedora 24-ben ápolja Az 5-ös verziótól a 6-os verzióig. Termékünk az 5-ös verzióval készült, hogy biztosítsa a kompatibilitást a régebbi disztribúciókkal. A Fedora 5-en a könyvtár régi 24. verziójának használatához a csomagot kellett használnom ncurses-compat-libs.
Ennek eredményeként két csomag létezik a Fedora számára, eltérő függőséggel.
Tovább érdekesebb. A következő terjesztési frissítés után a csomag ncurses-compat-libs a könyvtár 5-ös verziójával kiderül, hogy nem elérhető. Egy terjesztőnek drága áthúzni a régi könyvtárakat a disztribúció új verziójába. Egy idő után a probléma megismétlődött a SUSE disztribúciókban.
Ennek eredményeként néhány disztribúciónak fel kellett hagynia az explicit függőséggel ncurses-libs, és javítsa ki a terméket, hogy a könyvtár bármely verziójával működjön.
A Red Hat 8-as verziójában egyébként már nincs metacsomag piton, amely a jó öregre utalt Python 2.7. Van python2 и piton3.
A csomagkezelők alternatívája
A függőségekkel kapcsolatos probléma régi, és már régóta nyilvánvaló. Emlékezzen csak a függőségi pokolra.
Különféle könyvtárak és alkalmazások kombinálása úgy, hogy azok stabilan működjenek és ne ütközzenek egymással – valójában ezt a feladatot minden Linux-terjesztő megpróbálja megoldani.
A csomagkezelő egészen más módon próbálja megoldani ezt a problémát. Lendületes a Canonicaltól. A fő ötlet: az alkalmazás a fő rendszertől elkülönített és védett homokozóban fut. Ha egy alkalmazáshoz könyvtárak szükségesek, akkor azokat magával az alkalmazással látják el.
Flatpak lehetővé teszi az alkalmazások homokozóban való futtatását is a Linux Containers használatával. A homokozó ötletet is használják AppImage.
Ezek a megoldások lehetővé teszik egy csomag létrehozását bármely disztribúcióhoz. Esetében Flatpak az alkalmazás telepítése és elindítása a rendszergazda tudta nélkül is lehetséges.
A fő probléma az, hogy nem minden alkalmazás futhat homokozóban. Néhány embernek közvetlen hozzáférésre van szüksége a platformhoz. Nem is beszélek a kernel modulokról, amelyek szigorúan a kerneltől függenek, és nem illeszkednek a sandbox koncepcióba.
A második probléma az, hogy a Red Hat és a SUSE vállalati környezetben népszerű disztribúciói még nem tartalmazzák a Snappy és a Flatpak támogatását.
Ebben a tekintetben a Veeam Agent for Linux nem érhető el nincs bekapcsolva .
A csomagkezelőkkel kapcsolatos kérdés befejezéseként szeretném megjegyezni, hogy lehetőség van a csomagkezelők teljes elhagyására a bináris fájlok és a telepítésükhöz szükséges szkript egy csomagba történő kombinálásával.
Egy ilyen csomag lehetővé teszi, hogy egyetlen közös csomagot hozzon létre a különböző disztribúciókhoz és platformokhoz, interaktív telepítési folyamatot hajtson végre, és elvégezze a szükséges testreszabást. Csak a VMware-től találkoztam ilyen Linux-csomagokkal.
Frissítési probléma
Még ha minden függőségi probléma megoldódott is, a program eltérően futhat ugyanazon a disztribúción. Ez frissítés kérdése.
Három frissítési stratégia létezik:
- A legegyszerűbb az, hogy soha ne frissítsd. Beállítottam a szervert és elfelejtettem. Minek frissíteni, ha minden működik? A problémák az első alkalommal jelentkeznek az ügyfélszolgálattal. A disztribúció készítője csak a frissített kiadást támogatja.
- Megbízhat a forgalmazóban, és beállíthatja az automatikus frissítéseket. Ebben az esetben a sikertelen frissítés után azonnal fel kell hívni a támogatást.
- A legmegbízhatóbb, de költséges és időigényes az a lehetőség, hogy a manuális frissítést csak tesztinfrastruktúrán történő futtatás után lehet elvégezni. Nem mindenki engedheti meg magának.
Mivel a különböző felhasználók eltérő frissítési stratégiákat használnak, támogatni kell mind a legújabb kiadást, mind az összes korábban megjelentet. Ez bonyolítja mind a fejlesztési, mind a tesztelési folyamatot, és fejfájást okoz a támogató csapatnak.
Különféle hardverplatformok
A különböző hardverplatformok olyan problémát jelentenek, amely nagyrészt a natív kódra jellemző. Legalább bináris fájlokat kell gyűjtenie minden támogatott platformhoz.
A Veeam Agent for Linux projektben továbbra sem tudunk támogatni ehhez hasonló RISC-t.
Nem fogok részletesen foglalkozni ezzel a kérdéssel. Csak a főbb problémákat vázolom fel: platformfüggő típusok, mint pl size_t, struktúra igazítás és bájtsorrend.
Statikus és/vagy dinamikus linkelés
De a kérdés az: „Hogyan kapcsolódjunk össze a könyvtárakkal – dinamikusan vagy statikusan?” érdemes megvitatni.
A Linux alatti C/C++ alkalmazások általában 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 a feladat különböző disztribúciók lefedése egy bináris fájllal, akkor a legrégebbi támogatott disztribúcióra kell összpontosítania. Nálunk ez a Red Hat 6. Gcc 4.4 van benne, amit még a C++11 szabvány sem támogat .
Projektünket a gcc 6.3 használatával építjük, amely teljes mértékben támogatja a C++14-et. Természetesen ebben az esetben a Red Hat 6-on magával kell vinnie a libstdc++ és a boost könyvtárakat. A legegyszerűbb, ha statikusan linkeljük őket.
De sajnos nem minden könyvtár csatlakoztatható statikusan.
Először is a rendszerkönyvtárak, mint pl libfuse, libblkid A rendszermaggal és moduljaival való kompatibilitásuk biztosítása érdekében dinamikusan kell összekapcsolni.
Másodszor, van egy finomság az engedélyekkel kapcsolatban.
A GPL licenc alapvetően lehetővé teszi, hogy csak nyílt forráskóddal kapcsoljon össze könyvtárakat. Az MIT és a BSD lehetővé teszi a statikus összekapcsolást, és lehetővé teszi könyvtárak bevonását egy projektbe. De úgy tűnik, hogy az LGPL nem mond ellent a statikus linkelésnek, hanem megköveteli a csatoláshoz szükséges fájlok megosztását.
Általánosságban elmondható, hogy a dinamikus linkelés használata megakadályozza, hogy bármit is meg kelljen adnia.
C/C++ alkalmazások készítése
Különböző platformokhoz és disztribúciókhoz való C/C++ alkalmazások készítéséhez elegendő kiválasztani vagy elkészíteni a gcc megfelelő verzióját, és keresztfordítókat használni az adott architektúrákhoz, és összeállítani a teljes könyvtárkészletet. Ez a munka meglehetősen kivitelezhető, de meglehetősen fáradságos. És nincs garancia arra, hogy a kiválasztott fordító és a könyvtárak működőképes verziót biztosítanak.
Nyilvánvaló előny: az infrastruktúra nagymértékben leegyszerűsödik, mivel a teljes építési folyamat egy gépen elvégezhető. Ezen kívül elegendő egyetlen bináris készletet összegyűjteni egy architektúrához, és ezeket csomagokba csomagolhatja különböző disztribúciókhoz. Így készülnek a veeam csomagok a Veeam Agent for Linux számára.
Ezzel a lehetőséggel szemben egyszerűen előkészíthet egy farmot, azaz több gépet összeszerelésre. Minden ilyen gép egy adott disztribúcióhoz és egy adott architektúrához biztosít alkalmazás-összeállítást és csomag-összeállítást. Ebben az esetben az összeállítás a forgalmazó által készített eszközökkel történik. Azaz megszűnik a fordító előkészítésének és a könyvtárak kiválasztásának szakasza. Ezenkívül az építési folyamat könnyen párhuzamosítható.
Ennek a megközelítésnek azonban van egy árnyoldala is: az azonos architektúrán belüli minden disztribúcióhoz össze kell gyűjtenie a saját bináris fájlkészletét. További hátrány, hogy ekkora számú gépet kell karbantartani, és nagy lemezterületet és RAM-ot kell lefoglalni.
Így fordítják le a veeamsnap kernelmodul KMOD-csomagjait a Red Hat disztribúciókhoz.
Nyissa meg a Build szolgáltatást
A SUSE kollégái megpróbáltak valami középutat megvalósítani egy speciális szolgáltatás formájában az alkalmazások összeállításához és a csomagok összeállításához - .
Lényegében egy hipervizorról van szó, amely létrehoz egy virtuális gépet, telepíti benne az összes szükséges csomagot, lefordítja az alkalmazást és összeállítja a csomagot ebben az izolált környezetben, ami után a virtuális gép kiadásra kerül.
Az OpenBuildService-ben megvalósított ütemező meghatározza, hogy hány virtuális gépet tud elindítani az optimális csomagkészítési sebesség érdekében. A beépített aláírási mechanizmus aláírja a csomagokat, és feltölti a beépített tárolóba. A beépített verziókezelő rendszer elmenti a változtatások és buildek előzményeit. Nincs más hátra, mint a források hozzáadása ehhez a rendszerhez. Még a szervert sem kell beállítania, használhat nyitott szervert.
Van azonban egy probléma: egy ilyen betakarítógépet nehéz beilleszteni a meglévő infrastruktúrába. Például nincs szükség verziókezelésre, már van saját forráskódunk. Az aláírási mechanizmusunk más: speciális szervert használunk. Nincs szükség tárolóra sem.
Ezenkívül az egyéb disztribúciók támogatása - például a Red Hat - meglehetősen rosszul van megvalósítva, ami érthető.
Egy ilyen szolgáltatás előnye a SUSE disztribúció következő verziójának gyors támogatása. A megjelenés hivatalos bejelentése előtt az összeállításhoz szükséges csomagok nyilvános tárhelyen kerülnek felhelyezésre. Egy új jelenik meg az OpenBuildService elérhető disztribúcióinak listájában. Bejelöljük a négyzetet, és hozzáadjuk az építési tervhez. Így a disztribúció új verziójának hozzáadása szinte egy kattintással megtörténik.
Infrastruktúránkban, az OpenBuildService használatával, a veeamsnap kernelmodul KMP-csomagjainak teljes választéka össze van állítva a SUSE disztribúciókhoz.
Ezután a kernelmodulokkal kapcsolatos problémákkal szeretnék foglalkozni.
kernel ABI
A Linux kernel modulokat a történelem során forrás formában terjesztették. A tény az, hogy a kernel készítői nem terhelik magukat azzal, hogy támogassanak egy stabil API-t a kernelmodulokhoz, különösen a bináris szinten, amelyet kABI-nak neveznek.
Ahhoz, hogy egy vanília kernelhez modult építsünk, feltétlenül szükségünk van ennek a kernelnek a fejlécére, és ez csak ezen a kernelen fog működni.
A DKMS lehetővé teszi a modulok felépítésének automatizálását a kernel frissítésekor. Ennek eredményeként a Debian lerakat felhasználói (és sok rokona) vagy a terjesztő tárolójából, vagy a DKMS segítségével a forrásból lefordított kernelmodulokat használnak.
Ez a helyzet azonban nem igazán illik az Enterprise szegmenshez. A védett kód terjesztői a terméket lefordított binárisokként szeretnék terjeszteni.
Az adminisztrátorok biztonsági okokból nem akarják a fejlesztői eszközöket az éles szervereken tartani. Az Enterprise Linux disztribútorok, például a Red Hat és a SUSE úgy döntöttek, hogy támogatni tudják a stabil kABI-t a felhasználók számára. Az eredmény KMOD-csomagok a Red Hathez és KMP-csomagok a SUSE-hoz.
Ennek a megoldásnak a lényege meglehetősen egyszerű. A disztribúció egy adott verziója esetén a kernel API le van fagyva. A disztribútor kijelenti, hogy a kernelt például 3.10-et használja, és csak olyan javításokat, fejlesztéseket végez, amelyek nem érintik a kernel interfészeit, a legelső kernelhez összegyűjtött modulok pedig újrafordítás nélkül használhatók az összes következőhöz.
A Red Hat azt állítja, hogy a disztribúció teljes életciklusa során kABI-kompatibilis. Vagyis a rhel 6.0-hoz (2010. novemberi kiadás) összeállított modulnak működnie kell a 6.10-es verzión is (2018. júniusi kiadás). És ez majdnem 8 év. Természetesen ez a feladat meglehetősen nehéz.
Számos olyan esetet rögzítettünk, amikor a veeamsnap modul kABI kompatibilitási problémák miatt leállt.
Miután az RHEL 7.0-ra fordított veeamsnap modulról kiderült, hogy nem kompatibilis az RHEL 7.5 rendszermagjával, de betöltődött, és garantáltan összeomlott a szerver, teljesen felhagytunk a kABI-kompatibilitás használatával az RHEL 7-hez.
Jelenleg az RHEL 7 KMOD-csomagja minden kiadási verzióhoz tartalmaz egy-egy összeállítást és egy szkriptet, amely betölti a modult.
A SUSE alaposabban közelítette meg a kABI-kompatibilitás feladatát. Csak egy szervizcsomagon belül biztosítanak kABI-kompatibilitást.
Például az SLES 12 megjelenése 2014 szeptemberében történt. Az SLES 12 SP1 pedig már 2015 decemberében volt, vagyis kicsivel több mint egy év telt el. Annak ellenére, hogy mindkét kiadás a 3.12-es kernelt használja, nem kompatibilis a kABI-val. Nyilvánvalóan sokkal könnyebb fenntartani a kABI-kompatibilitást mindössze egy évig. A kernelmodul éves frissítési ciklusa nem okozhat problémát a modulkészítőknek.
Ennek a SUSE-szabályzatnak az eredményeként egyetlen kABI-kompatibilitási problémát sem rögzítettünk veeamsnap modulunkban. Igaz, a SUSE csomagjainak száma szinte egy nagyságrenddel több.
Patchek és háttérportok
Bár a terjesztők igyekeznek biztosítani a kABI-kompatibilitást és a kernelstabilitást, igyekeznek javítani a stabil kernel teljesítményét és kiküszöbölni a hibáit.
Ugyanakkor a vállalati Linux kernel fejlesztői saját „hibamunkájukon” túl figyelik a vanília kernel változásait, és átviszik azokat a „stabil” kernelbe.
Néha ez újhoz vezet .
A Red Hat 6 legújabb kiadásában az egyik kisebb frissítésben hiba történt. Ez oda vezetett, hogy a veeamsnap modul garantáltan összeomlik a rendszerben, amikor a pillanatfelvétel megjelent. A frissítés előtti és utáni kernelforrások összehasonlítása után rájöttünk, hogy a backport volt a hibás. Hasonló javítás történt a vanília kernel 4.19-es verziójában is. Csupán arról van szó, hogy ez a javítás jól működött a vanília kernelben, de amikor átvittük a „stabil” 2.6.32-re, probléma lépett fel a spinlockkal.
Persze mindig mindenkinek vannak hibái, de megérte a stabilitást kockáztatva 4.19-ről 2.6.32-re húzni a kódot?.. Nem tudom...
A legrosszabb az, amikor a marketing belekeveredik a „stabilitás” és a „modernizáció” közötti huzavonaba. A marketing osztálynak szüksége van arra, hogy a frissített disztribúció magja egyrészt stabil legyen, ugyanakkor jobb legyen a teljesítménye és új funkciókkal rendelkezzen. Ez furcsa kompromisszumokhoz vezet.
Amikor megpróbáltam modult építeni az SLES 4.4 SP12 3-es kernelére, meglepődtem, hogy a vanilla 4.8-as funkcionalitást találtam benne. Véleményem szerint az SLES 4.4 SP12 3-es kernelének blokk I/O-megvalósítása jobban hasonlít a 4.8-as kernelhez, mint az SLES4.4 SP12-ből származó stabil 2-es kernel előző kiadásához. Nem tudom megítélni, hogy a kód hány százaléka került át a 4.8-as kernelről az SLES 4.4-re az SP3-hoz, de még csak nem is hívhatom ugyanazt a stabil 4.4-es kernelt.
A legkellemetlenebb ebben az, hogy amikor olyan modult írunk, amely egyformán jól működne a különböző kerneleken, már nem támaszkodhatunk a kernel verziójára. Az elosztást is figyelembe kell venni. Jó, ha néha bele lehet keveredni egy-egy definícióba, amely új funkcionalitás mellett jelenik meg, de ez a lehetőség nem mindig jelenik meg.
Ennek eredményeként a kód benőtt furcsa feltételes fordítási direktívákkal.
Vannak olyan javítások is, amelyek megváltoztatják a dokumentált kernel API-t.
Találkoztam az elosztással 5.16, és nagyon meglepődve láttam, hogy a lookup_bdev hívás ebben a kernelverzióban megváltoztatta a bemeneti paraméterek listáját.
Az összeállításhoz hozzá kellett adnom egy szkriptet a makefile-hoz, amely ellenőrzi, hogy a lookup_bdev függvénynek van-e maszk paramétere.
Kernelmodulok aláírása
De térjünk vissza a csomagterjesztés kérdéséhez.
A stabil kABI egyik előnye, hogy a kernelmodulok bináris fájlként is aláírhatók. Ebben az esetben a fejlesztő biztos lehet benne, hogy a modul nem sérült meg véletlenül vagy nem módosították szándékosan. Ezt a modinfo paranccsal ellenőrizheti.
A Red Hat és a SUSE disztribúciók csak akkor teszik lehetővé a modul aláírásának ellenőrzését és betöltését, ha a megfelelő tanúsítvány regisztrálva van a rendszeren. A tanúsítvány az a nyilvános kulcs, amellyel a modul alá van írva. Külön csomagban forgalmazzuk.
A probléma itt az, hogy a tanúsítványok beépíthetők a kernelbe (a forgalmazók használják őket), vagy az EFI nem felejtő memóriájába kell írni egy segédprogram segítségével mokutil. Hasznosság mokutil Tanúsítvány telepítésekor újra kell indítani a rendszert, és még az operációs rendszer kernelének betöltése előtt felkéri a rendszergazdát, hogy engedélyezze az új tanúsítvány betöltését.
Így a tanúsítvány hozzáadásához fizikai rendszergazdai hozzáférés szükséges a rendszerhez. Ha a gép valahol a felhőben vagy egyszerűen egy távoli szerverszobában található, és a hozzáférés csak a hálózaton keresztül történik (például ssh-n keresztül), akkor lehetetlen lesz tanúsítványt hozzáadni.
EFI virtuális gépeken
Annak ellenére, hogy az EFI-t már régóta támogatja szinte minden alaplapgyártó, a rendszer telepítésekor előfordulhat, hogy a rendszergazda nem gondol az EFI szükségességére, és le is tiltható.
Nem minden hipervizor támogatja az EFI-t. A VMWare vSphere az 5-ös verziótól kezdve támogatja az EFI-t.
A Microsoft Hyper-V EFI-támogatást is kapott a Hyper-V-től kezdve a Windows Server 2012R2 rendszerhez.
Az alapértelmezett konfigurációban azonban ez a funkció le van tiltva a Linux gépeken, ami azt jelenti, hogy a tanúsítvány nem telepíthető.
A vSphere 6.5-ben állítsa be a beállítást biztonságos rendszerindítás csak a webes felület régi verziójában lehetséges, amely Flash-en keresztül fut. A HTML-5 webes felhasználói felülete még messze elmarad.
Kísérleti eloszlások
És végül nézzük meg a kísérleti és hivatalos támogatás nélküli disztribúciók kérdését. Egyrészt komoly szervezetek szerverein nem valószínű, hogy ilyen disztribúciók találhatók. Az ilyen terjesztésekhez nincs hivatalos támogatás. Ezért biztosítsa azokat. A termék nem támogatható ilyen disztribúción.
Az ilyen disztribúciók azonban kényelmes platformot jelentenek az új kísérleti megoldások kipróbálásához. Például a Fedora, az OpenSUSE Tumbleweed vagy a Debian instabil verziói. Elég stabilak. Mindig van új programverziójuk és mindig új kernellel. Egy éven belül ez a kísérleti funkció egy frissített RHEL-ben, SLES-ben vagy Ubuntuban végezhet.
Tehát ha valami nem működik egy kísérleti eloszláson, ez ok arra, hogy kitaláljuk a problémát és megoldjuk. Fel kell készülnie arra, hogy ez a funkció hamarosan megjelenik a felhasználók éles szerverein.
Megtekintheti a 3.0-s verzió hivatalosan támogatott disztribúcióinak aktuális listáját . De a disztribúciók valódi listája, amelyeken termékünk működhet, sokkal szélesebb.
Személy szerint engem érdekelt az Elbrus operációs rendszerrel végzett kísérlet. A veeam csomag véglegesítése után termékünk telepítésre került és működött. Erről a kísérletről Habrén írtam ben .
Nos, az új disztribúciók támogatása folytatódik. Várjuk a 4.0-s verzió megjelenését. Hamarosan megjelenik a béta, ezért figyeljen oda !
Forrás: will.com