Stvaranje sigurnosne aplikacije koja radi na bilo kojoj distribuciji nije lak zadatak. Kako biste osigurali da Veeam Agent za Linux radi na distribucijama od Red Hat 6 i Debian 6, do OpenSUSE 15.1 i Ubuntu 19.04, morate riješiti niz problema, posebno imajući u vidu da softverski proizvod uključuje kernel modul.
Članak je nastao na temelju materijala iz govora na konferenciji .
Linux nije samo jedan od najpopularnijih operativnih sustava. U biti, ovo je platforma na temelju koje možete napraviti nešto unikatno, nešto svoje. Zahvaljujući tome, Linux ima mnogo distribucija koje se razlikuju po skupu softverskih komponenti. I tu se javlja problem: kako bi softverski proizvod funkcionirao na bilo kojoj distribuciji, morate uzeti u obzir značajke svake.
Upravitelji paketa. .deb u odnosu na .rpm
Počnimo s očitim problemom distribucije proizvoda u različitim distribucijama.
Najtipičniji način distribucije softverskih proizvoda je stavljanje paketa u repozitorij tako da ga upravitelj paketa ugrađen u sustav može od tamo instalirati.
Međutim, imamo dva popularna formata paketa: min и debitant. To znači da će svi morati podržati.
U svijetu deb paketa, razina kompatibilnosti je nevjerojatna. Isti paket instalira se i jednako dobro radi i na Debianu 6 i na Ubuntuu 19.04. Standardi za proces izgradnje paketa i rad s njima, postavljeni u starim distribucijama Debiana, ostaju relevantni u novopostavljenom Linux Mintu i osnovnom OS-u. Stoga je u slučaju Veeam Agenta za Linux dovoljan jedan deb paket za svaku hardversku platformu.
Ali u svijetu rpm paketa, razlike su velike. Prvo, zbog činjenice da postoje dva potpuno neovisna distributera, Red Hat i SUSE, kojima je kompatibilnost potpuno nepotrebna. Drugo, ovi distributeri imaju distribucijske komplete od onih. podrška i eksperimentalni. Nema potrebe ni za kompatibilnošću među njima. Ispostavilo se da el6, el7 i el8 imaju svoje pakete. Zaseban paket za Fedoru. Paketi za SLES11 i 12 i poseban za openSUSE. Glavni problem su ovisnosti i imena paketa.
Problem ovisnosti
Nažalost, isti paketi često završe pod različitim imenima u različitim distribucijama. Ispod je djelomičan popis ovisnosti paketa veeam.
Za EL7:
Za SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fuse-libs
- datoteka-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc ++ 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Kao rezultat toga, popis ovisnosti je jedinstven za distribuciju.
Ono što postaje još gore je kada se ažurirana verzija počne skrivati pod starim nazivom paketa.
Primjer:
Paket je ažuriran u Fedori 24 npsovke s verzije 5 na verziju 6. Naš je proizvod izgrađen s verzijom 5 kako bi se osigurala kompatibilnost sa starijim distribucijama. Da bih koristio staru 5. verziju biblioteke na Fedori 24, morao sam koristiti paket ncurses-compat-libs.
Kao rezultat toga, postoje dva paketa za Fedoru, s različitim ovisnostima.
Dalje zanimljivije. Nakon sljedećeg ažuriranja distribucije, paket ncurses-compat-libs s verzijom 5 knjižnice ispada da nije dostupna. Za distributera je skupo prevući stare biblioteke u novu verziju distribucije. Nakon nekog vremena problem se ponovio u SUSE distribucijama.
Kao rezultat toga, neke su distribucije morale odustati od svoje eksplicitne ovisnosti o ncurses-libsi popraviti proizvod tako da može raditi s bilo kojom verzijom biblioteke.
Usput, u verziji 8 Red Hata više nema meta paketa piton, koji se odnosio na staru dobru piton 2.7, Postoji python2 и piton3.
Alternativa upraviteljima paketa
Problem s ovisnostima je star i odavno je očit. Samo se sjetite pakla zavisnosti.
Kombinirati različite biblioteke i aplikacije tako da sve rade stabilno i da se ne sukobljavaju - zapravo, to je zadatak koji svaki distributer Linuxa pokušava riješiti.
Upravitelj paketa pokušava riješiti ovaj problem na potpuno drugačiji način. Lijep od Canonical. Glavna ideja: aplikacija radi u sandboxu izoliranom i zaštićenom od glavnog sustava. Ako aplikacija zahtijeva biblioteke, one se isporučuju sa samom aplikacijom.
Flatpak također vam omogućuje pokretanje aplikacija u sandboxu koristeći Linux kontejnere. Također se koristi ideja pješčanika AppImage.
Ova rješenja vam omogućuju stvaranje jednog paketa za bilo koju distribuciju. U slučaju Flatpak instalacija i pokretanje aplikacije moguće je i bez znanja administratora.
Glavni problem je što se sve aplikacije ne mogu izvoditi u sandboxu. Neki ljudi trebaju izravan pristup platformi. Da čak i ne govorim o modulima kernela, koji su strogo ovisni o kernelu i ne uklapaju se u koncept sandboxa.
Drugi problem je taj što distribucije Red Hata i SUSE-a popularne u poslovnom okruženju još ne sadrže podršku za Snappy i Flatpak.
U tom pogledu Veeam Agent za Linux nije dostupan ne na .
Da zaključim pitanje o upraviteljima paketima, želio bih napomenuti da postoji opcija potpunog napuštanja upravitelja paketa kombiniranjem binarnih datoteka i skripte za njihovo instaliranje u jedan paket.
Takav paket omogućuje vam stvaranje jednog zajedničkog paketa za različite distribucije i platforme, provođenje interaktivnog postupka instalacije, provođenje potrebne prilagodbe. Takve pakete za Linux susreo sam samo od VMware-a.
Problem ažuriranja
Čak i ako su svi problemi ovisnosti riješeni, program može raditi drugačije na istoj distribuciji. To je stvar ažuriranja.
Postoje 3 strategije ažuriranja:
- Najjednostavnije je nikad ne ažurirati. Postavio sam server i zaboravio na njega. Zašto ažurirati ako sve radi? Problemi počinju kada prvi put kontaktirate podršku. Tvorac distribucije podržava samo ažurirano izdanje.
- Možete vjerovati distributeru i postaviti automatska ažuriranja. U tom slučaju, poziv podršci je vjerojatno odmah nakon neuspješnog ažuriranja.
- Opcija ručnog ažuriranja tek nakon pokretanja na testnoj infrastrukturi je najpouzdanija, ali skupa i dugotrajna. Ne može si to svatko priuštiti.
Budući da različiti korisnici koriste različite strategije ažuriranja, potrebno je podržati i najnovije izdanje i sva prethodno izdana. To komplicira proces razvoja i testiranja i stvara glavobolje timu za podršku.
Raznolikost hardverskih platformi
Različite hardverske platforme su problem koji je u velikoj mjeri specifičan za nativni kod. Najmanje morate prikupiti binarne datoteke za svaku podržanu platformu.
U projektu Veeam Agent za Linux još uvijek ne možemo podržati ništa poput ovog RISC-a.
Neću se detaljnije zadržavati na ovom pitanju. Navest ću samo glavne probleme: vrste ovisne o platformi, kao što su size_t, poravnanje strukture i poredak bajtova.
Statičko i/ili dinamičko povezivanje
Ali pitanje je "Kako se povezati s bibliotekama - dinamički ili statički?" vrijedno rasprave.
U pravilu, C/C++ aplikacije pod Linuxom koriste dinamičko povezivanje. Ovo izvrsno funkcionira ako je aplikacija izrađena posebno za određenu distribuciju.
Ako je zadatak pokriti različite distribucije s jednom binarnom datotekom, tada se morate usredotočiti na najstariju podržanu distribuciju. Za nas je ovo Red Hat 6. Sadrži gcc 4.4 koji čak ni C++11 standard ne podržava .
Naš projekt gradimo koristeći gcc 6.3, koji u potpunosti podržava C++14. Naravno, u ovom slučaju, na Red Hat 6 morate sa sobom nositi libstdc++ i knjižnice za povećanje. Najlakši način je statički se povezati s njima.
Ali nažalost, ne mogu se sve biblioteke statički povezati.
Prvo, sistemske biblioteke kao što su libfuza, libblkid potrebno je dinamički povezati kako bi se osigurala njihova kompatibilnost s jezgrom i njegovim modulima.
Drugo, postoji suptilnost s licencama.
GPL licenca vam u osnovi omogućuje povezivanje knjižnica samo s otvorenim kodom. MIT i BSD dopuštaju statičko povezivanje i dopuštaju uključivanje knjižnica u projekt. Ali čini se da LGPL nije u suprotnosti sa statičkim povezivanjem, ali zahtijeva da se datoteke potrebne za povezivanje dijele.
Općenito, korištenje dinamičkog povezivanja spriječit će vas da morate bilo što pružati.
Izrada C/C++ aplikacija
Za izradu C/C++ aplikacija za različite platforme i distribucije dovoljno je odabrati ili izgraditi odgovarajuću verziju gcc-a i koristiti unakrsne kompajlere za određene arhitekture i sastaviti cijeli skup biblioteka. Ovaj posao je prilično izvediv, ali prilično problematičan. I nema jamstva da će odabrani kompilator i biblioteke pružiti funkcionalnu verziju.
Očita prednost: infrastruktura je znatno pojednostavljena, budući da se cijeli proces izgradnje može dovršiti na jednom stroju. Osim toga, dovoljno je prikupiti jedan set binarnih datoteka za jednu arhitekturu i možete ih pakirati u pakete za različite distribucije. Ovako se grade veeam paketi za Veeam Agent za Linux.
Za razliku od ove opcije, možete jednostavno pripremiti građevinsku farmu, odnosno nekoliko strojeva za montažu. Svaki takav stroj će osigurati kompilaciju aplikacije i sastavljanje paketa za određenu distribuciju i određenu arhitekturu. U tom slučaju, kompilacija se provodi pomoću sredstava koje je pripremio distributer. To jest, eliminirana je faza pripreme prevodioca i odabira biblioteka. Osim toga, proces izgradnje može se jednostavno paralelizirati.
Postoji, međutim, loša strana ovog pristupa: za svaku distribuciju unutar iste arhitekture, morat ćete prikupiti vlastiti skup binarnih datoteka. Još jedan nedostatak je to što je potrebno održavati tako velik broj strojeva i alocirati veliku količinu prostora na disku i RAM-a.
Ovako se kompajliraju KMOD paketi veeamsnap kernel modula za Red Hat distribucije.
Otvorite uslugu izgradnje
Kolege iz SUSE-a pokušale su implementirati neku sredinu u vidu posebnog servisa za sastavljanje aplikacija i sastavljanje paketa - .
U biti, radi se o hipervizoru koji kreira virtualni stroj, u njega instalira sve potrebne pakete, kompajlira aplikaciju i gradi paket u tom izoliranom okruženju, nakon čega se virtualni stroj oslobađa.
Planer implementiran u OpenBuildService će odrediti koliko virtualnih strojeva može pokrenuti za optimalnu brzinu izgradnje paketa. Ugrađeni mehanizam potpisivanja potpisat će pakete i učitati ih u ugrađeno spremište. Ugrađeni sustav kontrole verzija će spremiti povijest promjena i nadogradnji. Sve što preostaje je jednostavno dodati svoje izvore u ovaj sustav. Ne morate čak ni sami postaviti poslužitelj; možete koristiti otvoreni.
Postoji, međutim, problem: takav kombajn teško je uklopiti u postojeću infrastrukturu. Na primjer, kontrola verzija nije potrebna; već imamo vlastite izvorne kodove. Naš mehanizam potpisa je drugačiji: koristimo poseban poslužitelj. Repozitorij također nije potreban.
Osim toga, podrška za druge distribucije - na primjer, Red Hat - implementirana je prilično loše, što je razumljivo.
Prednost takve usluge je brza podrška za sljedeću verziju SUSE distribucije. Prije službene najave izdavanja, paketi potrebni za montažu objavljuju se na javnom repozitoriju. Nova se pojavljuje na popisu dostupnih distribucija na OpenBuildService. Označimo okvir i on se dodaje u plan izgradnje. Tako se dodavanje nove verzije distribucije vrši gotovo jednim klikom.
U našoj infrastrukturi, koristeći OpenBuildService, sastavljen je čitav niz KMP paketa veeamsnap kernel modula za SUSE distribucije.
Zatim bih se želio zadržati na pitanjima specifičnim za module kernela.
kernel ABI
Moduli jezgre Linuxa kroz povijest su se distribuirali u izvornom obliku. Činjenica je da se tvorci kernela ne opterećuju brigom o podršci stabilnog API-ja za module kernela, a posebno na binarnoj razini, dalje nazvanoj kABI.
Za izgradnju modula za vanilla kernel, definitivno su vam potrebna zaglavlja ove jezgre, a radit će samo na ovoj jezgri.
DKMS vam omogućuje automatizaciju procesa izgradnje modula prilikom ažuriranja kernela. Kao rezultat toga, korisnici Debianovog repozitorija (i njegovih brojnih srodnika) koriste module kernela ili iz distributerovog repozitorija ili kompajlirane iz izvora koristeći DKMS.
No, takvo stanje ne odgovara posebno segmentu Enterprise. Distributeri vlasničkog koda žele distribuirati proizvod kao kompilirane binarne datoteke.
Administratori ne žele držati razvojne alate na proizvodnim poslužiteljima iz sigurnosnih razloga. Enterprise Linux distributeri kao što su Red Hat i SUSE odlučili su da mogu podržati stabilni kABI za svoje korisnike. Rezultat su bili KMOD paketi za Red Hat i KMP paketi za SUSE.
Suština ovog rješenja je vrlo jednostavna. Za određenu verziju distribucije, kernel API je zamrznut. Distributer navodi da koristi kernel, na primjer, 3.10, i vrši samo ispravke i poboljšanja koja ne utječu na sučelja kernela, a moduli prikupljeni za prvi kernel mogu se koristiti za sve sljedeće bez ponovnog kompiliranja.
Red Hat tvrdi da je kABI kompatibilan za distribuciju tijekom cijelog životnog ciklusa. Odnosno, sklopljeni modul za rhel 6.0 (izdanje studeni 2010.) također bi trebao raditi na verziji 6.10 (izdanje lipanj 2018.). A ovo je skoro 8 godina. Naravno, ovaj zadatak je prilično težak.
Zabilježili smo nekoliko slučajeva u kojima je veeamsnap modul prestao raditi zbog problema s kABI kompatibilnošću.
Nakon što se modul veeamsnap, kompiliran za RHEL 7.0, pokazao nekompatibilnim s jezgrom iz RHEL 7.5, ali se učitao i zajamčeno je srušio poslužitelj, u potpunosti smo odustali od upotrebe kABI kompatibilnosti za RHEL 7.
Trenutno KMOD paket za RHEL 7 sadrži sklop za svaku verziju izdanja i skriptu koja učitava modul.
SUSE je pažljivije pristupio zadatku kABI kompatibilnosti. Omogućuju kABI kompatibilnost samo unutar jednog servisnog paketa.
Na primjer, izdanje SLES 12 održano je u rujnu 2014. A SLES 12 SP1 već je bilo u prosincu 2015., odnosno prošlo je nešto više od godinu dana. Iako oba izdanja koriste 3.12 kernel, nisu kompatibilna s kABI. Očito je mnogo lakše održavati kABI kompatibilnost samo godinu dana. Godišnji ciklus ažuriranja modula jezgre ne bi trebao stvarati probleme kreatorima modula.
Kao rezultat ove SUSE politike, nismo zabilježili niti jedan problem s kABI kompatibilnošću u našem veeamsnap modulu. Istina, broj paketa za SUSE je gotovo red veličine veći.
Zakrpe i backportovi
Iako distributeri pokušavaju osigurati kABI kompatibilnost i stabilnost kernela, oni također pokušavaju poboljšati performanse i eliminirati nedostatke ovog stabilnog kernela.
Istodobno, osim vlastitog "rada na pogreškama", programeri Enterprise Linux kernela prate promjene u vanilla kernelu i prenose ih u svoj "stabilni".
Ponekad to dovodi do novih .
U posljednjem izdanju Red Hat 6 napravljena je pogreška u jednom od manjih ažuriranja. To je dovelo do činjenice da će modul veeamsnap zajamčeno srušiti sustav kada se objavi snimka. Usporedivši izvore kernela prije i poslije ažuriranja, otkrili smo da je za to kriv backport. Sličan popravak napravljen je u vanilla verziji kernela 4.19. Samo što je ovaj popravak dobro funkcionirao u vanilla kernelu, ali prilikom prebacivanja u "stabilnu" 2.6.32 pojavio se problem sa spinlockom.
Naravno, svi uvijek imaju greške, ali je li se isplatilo povlačiti kod s 4.19 na 2.6.32, riskirajući stabilnost?.. Nisam siguran...
Najgore je kad se marketing uključi u natezanje konopa između “stabilnosti” i “modernizacije”. Odjel marketinga treba da jezgra ažurirane distribucije bude stabilna, s jedne strane, a da u isto vrijeme ima bolje performanse i nove značajke. To dovodi do čudnih kompromisa.
Kad sam pokušao izgraditi modul na kernelu 4.4 iz SLES 12 SP3, iznenadio sam se kad sam u njemu pronašao funkcionalnost vanilla 4.8. Po mom mišljenju, implementacija blok I/O jezgre 4.4 iz SLES 12 SP3 sličnija je jezgri 4.8 od prethodnog izdanja stabilnog kernela 4.4 iz SLES12 SP2. Ne mogu procijeniti koliki je postotak koda prebačen s kernela 4.8 na SLES 4.4 za SP3, ali ne mogu ni nazvati kernel istim stabilnim 4.4.
Ono što je najneugodnije kod ovoga je to što se pri pisanju modula koji bi podjednako dobro radio na različitim kernelima više ne možete osloniti na verziju kernela. Također morate uzeti u obzir distribuciju. Dobro je što se ponekad možete uključiti u definiciju koja se pojavljuje zajedno s novom funkcionalnošću, ali ta se prilika ne pojavljuje uvijek.
Kao rezultat toga, kod postaje pretrpan čudnim direktivama uvjetne kompilacije.
Postoje i zakrpe koje mijenjaju dokumentirani kernel API.
Naišao sam na distribuciju 5.16 i bio je vrlo iznenađen kad je vidio da je poziv lookup_bdev u ovoj verziji kernela promijenio popis ulaznih parametara.
Da bih to spojio, morao sam dodati skriptu u makefile koja provjerava ima li funkcija lookup_bdev parametar maske.
Potpisivanje kernel modula
No, vratimo se pitanju paketne distribucije.
Jedna od prednosti stabilnog kABI-ja je da moduli kernela mogu biti potpisani kao binarna datoteka. U tom slučaju programer može biti siguran da modul nije slučajno oštećen ili namjerno modificiran. To možete provjeriti naredbom modinfo.
Red Hat i SUSE distribucije omogućuju provjeru potpisa modula i njegovo učitavanje samo ako je odgovarajući certifikat registriran na sustavu. Certifikat je javni ključ kojim je modul potpisan. Distribuiramo ga kao zaseban paket.
Problem je u tome što se certifikati mogu ugraditi u kernel (distributeri ih koriste) ili se moraju zapisati u EFI trajnu memoriju pomoću uslužnog programa mokutil. Korisnost mokutil Prilikom instaliranja certifikata, od vas se traži ponovno pokretanje sustava i, čak i prije učitavanja jezgre operativnog sustava, traži od administratora da dopusti učitavanje novog certifikata.
Dakle, dodavanje certifikata zahtijeva fizički administratorski pristup sustavu. Ako se stroj nalazi negdje u oblaku ili jednostavno u udaljenoj serverskoj sobi i pristup je samo putem mreže (na primjer, putem ssh-a), tada će biti nemoguće dodati certifikat.
EFI na virtualnim strojevima
Unatoč činjenici da EFI već dugo podržavaju gotovo svi proizvođači matičnih ploča, prilikom instaliranja sustava administrator možda neće razmišljati o potrebi za EFI-jem i može biti onemoguć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 EFI podršku počevši s Hyper-V za Windows Server 2012R2.
Međutim, u zadanoj konfiguraciji ova je funkcija onemogućena za Linux strojeve, što znači da se certifikat ne može instalirati.
U vSphere 6.5 postavite opciju Sigurna Boot moguće samo u staroj verziji web sučelja, koja radi preko Flasha. Web sučelje na HTML-5 je još uvijek daleko.
Eksperimentalne distribucije
I na kraju, razmotrimo pitanje eksperimentalnih distribucija i distribucija bez službene podrške. S jedne strane, takve se distribucije vjerojatno neće naći na poslužiteljima ozbiljnih organizacija. Ne postoji službena podrška za takve distribucije. Stoga, osigurajte ih. Proizvod ne može biti podržan na takvoj distribuciji.
Međutim, takve distribucije postaju zgodna platforma za isprobavanje novih eksperimentalnih rješenja. Na primjer, Fedora, OpenSUSE Tumbleweed ili Unstable verzije Debiana. Prilično su postojani. Uvijek imaju nove verzije programa i uvijek novi kernel. Za godinu dana ova bi eksperimentalna funkcionalnost mogla završiti u ažuriranom RHEL-u, SLES-u ili Ubuntuu.
Dakle, ako nešto ne radi na eksperimentalnoj distribuciji, to je razlog da otkrijete problem i riješite ga. Morate biti spremni na činjenicu da će se ova funkcionalnost uskoro pojaviti na produkcijskim poslužiteljima korisnika.
Možete proučiti trenutni popis službeno podržanih distribucija za verziju 3.0 . Ali pravi popis distribucija na kojima naš proizvod može raditi mnogo je širi.
Osobno me zanimao eksperiment s Elbrus OS-om. Nakon finalizacije veeam paketa, naš proizvod je instaliran i radi. Pisao sam o ovom eksperimentu na Habréu u .
Pa, podrška za nove distribucije se nastavlja. Čekamo izlazak verzije 4.0. Beta će se uskoro pojaviti, pa pripazite !
Izvor: www.habr.com