Izrada aplikacije za sigurnosnu kopiju koja radi na bilo kojoj distribuciji je složen zadatak. Da bi Veeam Agent for Linux radio na distribucijama od Red Hat 6 do Debian 6, pa sve do OpenSUSE 15.1 i Ubuntu 19.04, potrebno je riješiti niz problema, osobito uzimajući u obzir da softverski proizvod uključuje modul jezgre.
Članak je napravljen na temelju materijala sa konferencije .
Linux nije samo jedan od najpopularnijih operativnih sustava. U suštini, to je platforma na kojoj se može izraditi nešto jedinstveno, nešto svoje. Zbog toga postoji mnogo distribucija Linuxa, koje se razlikuju po skupu softverskih komponenti. I tu se javlja problem: kako bi softverski proizvod funkcionirao na bilo kojoj distribuciji, potrebno je uzeti u obzir osobitosti svake.
Upravitelji paketa: .deb vs .rpm
Započnimo s očiglednim problemom distribucije proizvoda za različite distribucije.
Najtipičniji način distribucije softverskih proizvoda je postaviti paket na repozitorij kako bi ga ugrađeni upravitelj paketa u sustavu mogao instalirati s njega.
Međutim, imamo dva popularna formata paketa: rpm i deb. To znači da ćemo morati podržavati svaki.
U svijetu deb paketa razina kompatibilnosti je zapanjujuća. Isti paket jednako dobro radi i na Debian 6 i na Ubuntu 19.04. Standardi procesa izrade paketa i rada s njima, postavljeni u starim Debian distribucijama, ostaju relevantni i u modernim Linux Mint i elementary OS. Stoga je za Veeam Agent for Linux dovoljan jedan deb paket za svaku hardversku platformu.
Međutim, u svijetu rpm paketa razlike su velike. Prvo, zbog toga što postoje dva potpuno neovisna distributera, Red Hat i SUSE, koji ne trebaju kompatibilnost. Drugo, ovi distributeri imaju distribucije s tehničkom podrškom i eksperimentalne. Između njih kompatibilnost također nije potrebna. Tako da imamo svoje pakete za el6, el7 i el8. Odvojeno paket za Fedora. Paketi za SLES11 i 12 i odvojen za openSUSE. Glavni problem leži u zavisnostima i imenima paketa.
Problem zavisnosti
Nažalost, isti paketi često se pojavljuju pod različitim imenima u različitim distribucijama. Ispod je nepotpun popis zavisnosti paketa veeam.
Za EL7:
Za 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
Kao rezultat, popis ovisnosti postaje jedinstven za distribuciju.
Gore je kada se pod starim imenom paketa počne skrivati nova verzija.
Primjer:
U Fedora 24 ažuriran paket ncurses s verzije 5 na verziju 6. Naš proizvod je izgrađen s 5. verzijom, kako bi se osigurala kompatibilnost sa starim distribucijama. Da bismo koristili staru 5. verziju biblioteke na Fedora 24, morali smo koristiti paket ncurses-compat-libs.
Kao rezultat, za Fedoru se pojavljuju dva paketa, s različitim ovisnostima.
Dalje postaje zanimljivije. Nakon još jednog ažuriranja distribucije, paket ncurses-compat-libs s 5. verzijom biblioteke postaje nedostupan. Distributeru je skupo zadržavati stare biblioteke u novoj verziji distribucije. Nakon nekog vremena, problem se ponovio i u distribucijama SUSE.
Kao rezultat, za neke distribucije je bilo potrebno odustati od eksplicitne ovisnosti o ncurses-libs, a proizvod prilagoditi tako da može raditi s bilo kojom verzijom biblioteke.
Usput, u 8. verziji Red Hat više nema meta-paketa python, koji se odnosio na stari dobri python 2.7. Postoji python2 i python3.
Alternativa paketnim menadžerima
Problemi s ovisnostima su stari i dobro poznati. Sjetite se samo Dependency hell.
Ujediniti raznolike biblioteke i aplikacije tako da svi stabilno rade i ne sukobljavaju se — to je zadatak koji svaki Linux distributer pokušava riješiti.
Posve drugačije ovaj problem pokušava riješiti paketni menadžer Snappy od Canonical. Osnovna ideja: aplikacija se izvršava u izoliranoj i zaštićenoj od glavnog sistema sandboxu. Ako aplikaciji trebaju biblioteke, one se isporučuju zajedno s aplikacijom.
Flatpak također omogućava pokretanje aplikacija u sandboxu koristeći Linux Containers. Ideju sandboxa koristi i AppImage.
Ova rješenja omogućavaju stvaranje jednog paketa za sve distribucije. U slučaju s Flatpak instalacija i pokretanje aplikacije moguća su čak i bez znanja administratora.
Osnovni problem je u tome što ne mogu sve aplikacije raditi u sandboxu. Nekima je potrebno izravno obraćanje platformi. O ne govorim o kernel modulima koji su strogo ovisni o kernelu i nikako se ne uklapaju u koncept sandboxa.
Drugi problem je taj što popularni distribucije od Red Hata i SUSE u enterprise okruženju još uvijek nemaju podršku za Snappy i Flatpak.
U vezi s tim, Veeam Agent za Linux nije ni na ni na .
Na kraju, kada je riječ o paket-menadžerima, postoji mogućnost da se potpuno odrekne paketa, kombinirajući binarne datoteke i skriptu za njihovu instalaciju.
Takav bundle omogućuje stvaranje jednog zajedničkog paketa za različite distribucije i platforme, kao i interaktivni proces instalacije uz potrebnu prilagodbu. Takve pakete za Linux sam viđao samo od VMware-a.
Problem ažuriranja
Čak i ako su svi problemi s zavisnostima riješeni, program može raditi različito na istoj distribuciji. Riječ je o ažuriranjima.
Postoje 3 strategije ažuriranja:
- Najjednostavnija je nikada ne ažurirati. Podesite server i zaboravite. Zašto ažurirati ako sve radi? Problemi počinju pri prvom pozivu u službu podrške. Stvoritelj distribucije podržava samo ažuriranu verziju.
- Može se vjerovati distributeru i postaviti automatsko ažuriranje. U tom slučaju je poziv u službu podrške vjerojatan odmah nakon neuspješnog ažuriranja.
- Opcija ručnog ažuriranja tek nakon testiranja u testnoj infrastrukturi je najpouzdanija, ali skupa i zahtijeva mnogo rada. Nisu svi u mogućnosti to priuštiti.
Budući da različiti korisnici primjenjuju različite strategije ažuriranja, potrebno je održavati i najnoviju verziju te sve ranije objavljene. To komplicira i proces razvoja i testiranja, dodaje glavobolju službi podrške.
Raznolikost hardverskih platformi
Različite hardverske platforme predstavljaju problem, koji je uglavnom specifičan za native kod. Bar je potrebno sastaviti binarne datoteke za svaku podržanu platformu.
U projektu Veeam Agent za Linux još uvijek ne možemo podržati ništa što je RISC-ovine.
O ovom pitanju neću se detaljno zadržavati. Samo ću označiti glavne probleme: platformi zavisni tipovi, kao što su size_t, poravnanje struktura i redoslijed bajtova.
Statička i/ili dinamička povezivanje
A pitanje 'Kako se povezivati s bibliotekama - dinamički ili statički?' vrijedi raspraviti.
U pravilu, C/C++ aplikacije na Linuxu koriste dinamičko vezivanje. To dobro funkcionira ako je aplikacija sastavljena posebno za određenu distribuciju.
Ako postoji potreba za obuhvaćanjem raznih distribucija jednim binarnim datotekom, potrebno je orijentirati se na najstariju podržavanu distribuciju. Za nas je to Red Hat 6. Sadrži gcc 4.4, koji čak ne podržava standard C++11. .
Naš projekt sastavljamo pomoću gcc 6.3, koji potpuno podržava C++14. Naravno, u tom slučaju na Red Hat 6 moramo sa sobom ponijeti libstdc++ i boost knjižnice. Najjednostavnije je povezati se s njima statički.
Ali nažalost, ne možemo se sa svim knjižnicama povezivati statički.
Prvo, sistemske knjižnice kao što su libfuse, libblkid moraju se povezivati dinamički kako bismo bili sigurni u njihovu kompatibilnost s kernelom i njegovim modulima.
Drugo, postoji nijansa s licencama.
GPL licenca u načelu dopušta povezivanje knjižnica samo s opensource kodom. MIT i BSD dopuštaju statičko vezivanje i omogućuju uključivanje knjižnica u projekt. A LGPL, čini se, ne proturječi statičkom vezivanju, ali zahtijeva da se javno dostupni datoteke potrebne za vezivanje.
U općem smislu, korištenje dinamičkog vezivanja osigurava da ne bude potrebe nešto pružati.
Sastavljanje C/C++ aplikacija
Za sastavljanje C/C++ aplikacija za različite platforme i distribucije dovoljno je odabrati ili sastaviti gcc odgovarajuće verzije i koristiti križne kompajlere za specifične arhitekture, te prikupiti cijeli set knjižnica. Ovaj rad je sasvim ostvariv, ali prilično zamoran. I ne postoje nikakve garancije da će odabrani kompajler i knjižnice osigurati funkcionalnu verziju.
Očita prednost: infrastruktura se značajno pojednostavljuje, jer se cijeli proces sastavljanja može izvršiti na jednoj mašini. Osim toga, dovoljno je prikupiti jedan skup binarnih datoteka za jednu arhitekturu i moguće ih je pakirati u pakete za različite distribucije. Tako se zapravo sastavljaju paketi za Veeam Agent for Linux.
Umjesto ovog pristupa, možete jednostavno pripremiti build farmu, što uključuje nekoliko računala za kompilaciju. Svako od tih računala će osigurati kompilaciju aplikacije i izradu paketa za određeni distribucijski sustav i specifičnu arhitekturu. U tom slučaju, kompilacija se vrši alatima koje je pripremio distributer. Dakle, faza pripreme kompajlera i odabir biblioteka otpada. Osim toga, proces izrade može se lako paralelizirati.
Međutim, postoji i nedostatak ovog pristupa: za svaki distribucijski sustav unutar jedne arhitekture morat će se izraditi vlastiti set binarnih datoteka. Također, nedostatak je što je potrebno održavati mnoge uređaje, dodijeliti veliku količinu prostora na disku i radne memorije.
Na taj se način sastavljaju KMOD paketi modula jezgre veeamsnap za distribucije Red Hat.
Open Build Service
Kolege iz SUSE-a pokušali su realizirati neku zlatnu sredinu u obliku posebne usluge za kompiliranje aplikacija i izradu paketa — .
U suštini, to je hipervizor koji stvara virtualnu mašinu, instalira sve potrebne pakete u nju, izvodi kompilaciju aplikacije i izradu paketa u ovom izoliranom okruženju, nakon čega se ta virtualna mašina oslobađa.
Planer implementiran u OpenBuildService sam će odrediti koliko virtualnih mašina može pokrenuti za optimalnu brzinu izrade paketa. Ugrađeni mehanizam potpisivanja automatski će potpisati pakete i staviti ih u ugrađeni repozitorij. Ugrađeni sustav upravljanja verzijama će sačuvati povijest promjena i izrada. Ostaje samo dodati svoje izvore u ovaj sustav. Nema potrebe ni podizati vlastiti server, već se može iskoristiti otvoreni.
Ipak, postoji problem: takav stroj teško se uklapa u postojeću infrastrukturu. Na primjer, upravljanje verzijama nije potrebno jer već imamo svoj za izvore. Mehanizam potpisivanja se razlikuje kod nas: koristi se poseban server. Također, repozitorij nije potreban.
Osim toga, podrška za druge distribucije — primjerice, Red Hat — implementirana je prilično oskudno, što je sasvim razumljivo.
Prednost ove usluge je brza podrška za novu verziju SUSE distribucije. Prije službene objave o puštanju, potrebni paketi za izgradnju objavljuju se u javnom repozitoriju. Na popisu dostupnih distribucija u OpenBuildServiceu pojavljuje se novi. Označimo ga, i dodaje se u plan izgradnje. Tako se dodavanje nove verzije distribucije provodi praktički jednim klikom.
U našoj infrastrukturi, koristeći OpenBuildService, sastavlja se raznolikost KMP paketa modula jezgre veeamsnap za SUSE distribucije.
Nakon toga, želio bih se osvrnuti na pitanja koja su specifična za module jezgre.
kernel ABI
Linux moduli jezgre su povijesno distribuirani u obliku izvornog koda. Naime, kreatori jezgre ne opterećuju se brigom o podršci stabilnom API-ju za module jezgre, a pogotovo na binarnoj razini, kasnije kABI.
Da bi se modul sastavio za vanilija jezgru, trebaju se točno ti headeri, i radit će samo na toj jezgru.
DKMS omogućava automatizaciju procesa izgradnje modula pri ažuriranju jezgre. Kao rezultat, korisnici Debian repozitorija (i njegovih brojnih rođaka) koriste module jezgre ili iz repozitorija distributera ili ih sastavljaju iz izvornog koda pomoću DKMS-a.
Međutim, takva situacija ne odgovara posebno Enterprise segmentu. Distributeri proprietarnog koda žele distribuirati proizvod u obliku sastavljenih binarnih datoteka.
Administratori ne žele imati sredstva za razvoj na produkcijskim serverima iz sigurnosnih razloga. Distributeri Enterprise Linuxa — poput Red Hat-a i SUSE-a — odlučili su da će za svoje korisnike podržati stabilno kABI. Kao rezultat, pojavili su se KMOD paketi za Red Hat i KMP paketi za SUSE.
Bit takvog rješenja je prilično jednostavan. Za određenu verziju distribucije, API jezgre se zamrzava. Distributer izjavljuje da koristi točno jezgru, primjerice, 3.10, i unosi samo ispravke i poboljšanja koja se na bilo koji način ne dotiču sučelja jezgre, a moduli sastavljeni za najprvu jezgru mogu se koristiti za sve kasnije bez ponovne kompilacije.
Red Hat tvrdi kako osigurava kABI kompatibilnost za distribuciju tijekom cijelog životnog ciklusa. To znači da sastavljeni modul za rhel 6.0 (izdanje iz studenog 2010.) treba raditi i na verziji 6.10 (izdanje iz lipnja 2018.). To je gotovo 8 godina. Naravno, zadatak je prilično složen.
Primijetili smo nekoliko slučajeva kada je zbog problema s kABI kompatibilnošću modul veeamsnap prestao raditi.
Nakon što je modul veeamsnap, sastavljen za RHEL 7.0, postao nekompatibilan s kernelom iz RHEL 7.5, ali se pritom učitavao i jamčio rušenje poslužitelja, odustali smo od korištenja kABI kompatibilnosti za RHEL 7 u potpunosti.
Trenutno KMOD paket za RHEL 7 sadrži izdanje za svaku verziju i skriptu koja osigurava učitavanje modula.
SUSE je pristupio zadatku kABI kompatibilnosti opreznije. Oni osiguravaju kABI kompatibilnost samo unutar jednog service packa.
Na primjer, izdanje SLES 12 je objavljeno u rujnu 2014. A SLES 12 SP1 već u prosincu 2015., što znači da je prošlo nešto više od godine. Unatoč tome što oba izdanja koriste kernel 3.12, oni nisu kABI kompatibilni. Očito je da je održavanje kABI kompatibilnosti tijekom samo jedne godine znatno lakše. Godišnji ciklus ažuriranja modula kernela ne bi trebao predstavljati probleme za proizvođače modula.
Kao rezultat te politike, SUSE nije zabilježio nijedan problem s kABI kompatibilnošću našeg modula veeamsnap. Istina, broj paketa za SUSE je gotovo redom veći.
Zaključci i backportovi
Unatoč tome što distributeri nastoje osigurati kABI kompatibilnost i stabilnost kernela, također pokušavaju poboljšati performanse i otkloniti nedostatke ovog stabilnog kernela.
Pri tom, osim vlastitog 'rada na greškama', programeri enterprise linux kernela prate promjene u vanilijom kernelu i prenose ih u svoje 'stabilno'.
Ponekad to dovodi do novih .
U posljednjem izdanju Red Hat 6 u jednom od manjih ažuriranja došlo je do greške. Ona je uzrokovala da modul veeamsnap jamči rušenje sustava prilikom oslobađanja snimke. Usporedivši izvore kernela prije i nakon ažuriranja, saznali smo da je razlog bio backport. Sličan popravak je napravljen u vanilijom kernelu verzije 4.19. No, u vanilijom kernelu ovaj popravak je radio normalno, a prilikom prenošenja u 'stabilno' 2.6.32 pojavila se problem sa spin-lockingom.
Naravno, greške se događaju svima i uvijek, ali je li bilo potrebno prenijeti kod s 4.19 na 2.6.32, riskirajući stabilnost?.. Nisam siguran...
Najgore je kada se marketing uključi u povlačenje užeta između "stabilnosti" i "modernizacije". Marketinškom odjelu treba stabilno jezgro ažurirane distribucije s jedne strane, a s druge strane bolje performanse i nove funkcije. To dovodi do čudnih kompromisa.
Kada sam pokušao sastaviti modul na jezgru 4.4 iz SLES 12 SP3, s iznenađenjem sam otkrio funkcionalnosti iz vanilnog 4.8. Po mom mišljenju, implementacija blokiranog ulaza/izlaza jezgra 4.4 iz SLES 12 SP3 više liči na jezgro 4.8 nego na prethodno stabilno izdanje 4.4 jezgra iz SLES12 SP2. Kakav je bio postotak prenesenog koda iz jezgra 4.8 u SLES-ovo 4.4 za SP3, ne bih se usudio suditi, međutim, ne mogu reći da je jezgro i dalje stabilno 4.4.
Najneugodnije u svemu je to što se prilikom pisanja modula koji bi jednako dobro radio na različitim jezgrama više ne može oslanjati na verziju jezgra. Također se mora uzeti u obzir i distribucija. Dobro je što se ponekad može vezati na definiranu konstantu koja dolazi s novom funkcionalnošću, međutim, ta se mogućnost ne pojavljuje uvijek.
Kao rezultat, kod postaje prepun čudnih direktiva uvjetne kompilacije.
Ima i zakrpa koje mijenjaju dokumentirano API jezgra.
Naišao sam na distribuciju 5.16 i bio sam vrlo iznenađen kada sam vidio da je poziv lookup_bdev u ovoj verziji jezgra promijenio popis ulaznih parametara.
Kako bih se sastavio, morao sam dodati skriptu u makefile koja provjerava postoji li parametar mask za funkciju lookup_bdev.
Potpis modula jezgra
Ali se vratimo pitanju distribucije paketa.
Jedna od prednosti stabilnog kABI-a je ta da se moduli jezgra u obliku binarnih datoteka mogu potpisati. U tom slučaju, programer može biti siguran da modul nije slučajno oštećen ili namjerno izmijenjen. To se može provjeriti naredbom modinfo.
Distribucije Red Hat i SUSE omogućuju provjeru potpisa modula i učitavanje samo ako je u sustavu registriran odgovarajući certifikat. Certifikat predstavlja javni ključ kojim se potpisuje modul. Mi ga distribuiramo u obliku zasebnog paketa.
Problem je u tome što certifikati mogu biti ili ugrađeni u jezgru (koriste ih distributeri), ili moraju biti pohranjeni u nevolatilnu memoriju EFI pomoću alata mokutil. Alat mokutil pri instalaciji certifikata zahtijeva ponovno pokretanje sustava i još prije učitavanja jezgre operativnog sustava nudi administratoru da odobri učitavanje novog certifikata.
Dakle, dodavanje certifikata zahtijeva fizički pristup administratora sustavu. Ako se stroj nalazi negdje u oblaku ili jednostavno na udaljenom poslužitelju, a pristup je moguć samo putem mreže (na primjer, putem ssh), onda dodavanje certifikata nije moguće.
EFI na virtualnim strojevima
Unatoč tome što gotovo svi proizvođači matičnih ploča podržavaju EFI već dugo, administrator možda neće razmisliti o potrebnosti EFI prilikom instalacije sustava, i mogao bi biti isključen.
Ne podržavaju svi hipervizori EFI. VMWare vSphere podržava EFI počevši od verzije 5.
Microsoft Hyper-V također je dobio podršku za EFI, počevši od Hyper-V za Windows Server 2012R2.
Međutim, u zadnjoj konfiguraciji ta funkcionalnost za Linux strojeve je isključena, što znači da certifikat ne može biti instaliran.
U vSphere 6.5, opcija Secure Boot može se postaviti samo u staroj verziji web sučelja, koja radi preko Flash-a. Web UI na HTML-5 još uvijek znatno zaostaje.
Eksperimentalne distribucije
Na kraju, razmotrimo pitanje eksperimentalnih distribucija i distribucija bez službene podrške. S jedne strane, takve distribucije vjerojatno se neće naći na serverima ozbiljnih organizacija. Takve distribucije nemaju službenu podršku. Stoga se ne može osigurati tehnička podrška za proizvod na takvoj distribuciji.
Međutim, takve distribucije postaju zgodna platforma za isprobavanje novih eksperimentalnih rešenja. Na primjer, Fedora, OpenSUSE Tumbleweed ili Unstable verzije Debian. To su prilično stabilne distribucije. U njima su uvijek nove verzije programa i uvijek novo jezgro. Kroz godinu dana ova eksperimentalna funkcionalnost može se naći u ažuriranom RHEL, SLES ili Ubuntu.
Dakle, ako nešto ne radi na eksperimentalnoj distribuciji — to je prilika da se prouči problem i riješi ga. Treba biti spreman na to da će se ta funkcionalnost uskoro pojaviti na proizvodnim poslužiteljima korisnika.
Trenutni popis službeno podržanih distribucija za verziju 3.0 možete proučiti . No, stvarni popis distribucija na kojima naš proizvod može raditi je znatno širi.
Mene je osobno zanimalo eksperimentirati s operativnim sustavom „Elbrus“. Nakon dorade paketa veeam, naš proizvod se instalirao i počeo raditi. O tom eksperimentu pisao sam na Habr-u u .
Podrška za nove distribucije se nastavlja. Očekujemo dolazak verzije 4.0. Beta bi trebala uskoro biti dostupna, pa pratite !
Izvor: habr.com
