Nyieun aplikasi cadangan anu tiasa dianggo dina distribusi naon waé mangrupikeun tugas anu nangtang. Pikeun mastikeun operasi Veeam Agent pikeun Linux dina distribusi ti Red Hat 6 sareng Debian 6, dugi ka OpenSUSE 15.1 sareng Ubuntu 19.04 ngagaduhan sababaraha masalah anu kedah diatasi, khususna upami ningali produk perangkat lunak éta kalebet modul kernel.
Tulisan ieu didamel dumasar kana bahan tina pidato dina konperénsi éta .
Linux — ieu sanés ngan ukur salah sahiji sistem operasi anu paling populér. Ieu dasarna mangrupikeun platform dimana anjeun tiasa nyiptakeun hal anu unik, hal anjeun nyalira. Hatur nuhun kana ieu, Linux Aya seueur distribusi, masing-masing gaduh sakumpulan komponén parangkat lunak anu béda. Sareng di dieu masalahna timbul: supados produk parangkat lunak tiasa fungsina dina distribusi naon waé, fitur khusus masing-masing kedah diperhatoskeun.
Pangatur pakét. .deb vs .rpm
Hayu urang mimitian ku masalah atra ngadistribusikaeun produk di sakuliah distribusi béda.
Cara anu paling umum pikeun ngadistribusikaeun produk parangkat lunak nyaéta nempatkeun pakét dina gudang supados manajer pakét anu diwangun kana sistem tiasa dipasang ti dinya.
Nanging, kami gaduh dua format pakét anu populér: rpm и deb. Ieu hartosna sadayana kedah ngadukung.
Dina dunya pakét deb, tingkat kompatibilitasna luar biasa. Pakét anu sami dipasang sareng jalanna sami saéna dina duanana. Debian 6, sareng salajengna Ubuntu 19.04. Standar pikeun prosés ngawangun pakét sareng damel sareng éta, ditetepkeun dina anu lami Debian distribusi, tetep relevan dina model anyar Linux Mint sareng OS dasar. Ku kituna, dina kasus Veeam Agent kanggo Linux Hiji pakét deb cekap pikeun unggal platform hardware.
Tapi dina dunya bungkusan rpm, bédana hébat. Firstly, alatan kanyataan yén aya dua distributor lengkep bebas, Red Hat jeung SUSE, nu kasaluyuan sagemblengna teu perlu. Kadua, distributor ieu ngagaduhan kit distribusi ti éta. rojongan tur eksperimen. Henteu aya kabutuhan pikeun kasaluyuan antara aranjeunna ogé. Tétéla yén el6, el7 jeung el8 boga bungkusan sorangan. pakét misah pikeun Fedora. Paket pikeun SLES11 sareng 12 sareng anu misah pikeun openSUSE. Masalah utama nyaéta dependensi sareng nami pakét.
Masalah kagumantungan
Hanjakalna, bungkusan anu sami sering ditungtungan ku nami anu béda dina distribusi anu béda. Di handap ieu daptar parsial tina kagumantungan paket veeam.
Pikeun EL7:
Pikeun SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- sekering-libs
- file-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++ 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Hasilna, daptar kagumantungan unik pikeun distribusina.
Anu parah nyaéta nalika versi anu diropéa mimiti nyumput dina nami pakét anu lami.
contona:
Paket parantos diropéa dina Fedora 24 ncurses ti versi 5 mun versi 6. Produk kami diwangun ku versi 5 pikeun mastikeun kasaluyuan jeung sebaran heubeul. Pikeun nganggo versi 5 perpustakaan heubeul dina Fedora 24, kuring kedah nganggo pakét ncurses-compat-libs.
Hasilna, aya dua bungkusan pikeun Fedora, sareng katergantungan anu béda.
Salajengna langkung narik. Saatos update distribusi salajengna, pakét ncurses-compat-libs kalawan versi 5 perpustakaan tétéla teu sadia. Éta mahal pikeun distributor a nyered perpustakaan heubeul kana versi anyar distribusi. Saatos sababaraha waktos, masalahna ngulang deui dina distribusi SUSE.
Hasilna, sababaraha sebaran kapaksa leupaskeun kagumantungan eksplisit maranéhanana ncurses-libs, sarta ngalereskeun produk supados tiasa dianggo kalayan sagala versi perpustakaan.
Ku jalan kitu, dina versi 8 Red Hat teu aya deui pakét meta python, nu disebut heubeul alus python 2.7. aya python2 и python3.
Alternatif pikeun manajer pakét
Masalah sareng katergantungan parantos lami sareng parantos atra. Ngan inget Dependency naraka.
Ngahijikeun rupa-rupa perpustakaan sareng aplikasi supados sadayana tiasa dianggo sacara stabil sareng henteu konflik, kanyataanna, mangrupikeun tugas anu dicobian direngsekeun ku unggal distributor. Linux.
Manajer pakét nyobian ngabéréskeun masalah ieu ku cara anu béda. Snappy ti Canonical. Gagasan utama: aplikasi dijalankeun dina kotak pasir anu terasing sareng ditangtayungan tina sistem utama. Lamun hiji aplikasi merlukeun perpustakaan, aranjeunna disadiakeun kalawan aplikasi sorangan.
Flatpak Éta ogé ngamungkinkeun anjeun pikeun ngajalankeun aplikasi dina sandbox nganggo Linux Wadah. Ideu sandbox ogé dianggo ku AppImage.
Solusi ieu ngamungkinkeun anjeun nyiptakeun hiji pakét pikeun distribusi naon waé. Dina hal Flatpak pamasangan sareng peluncuran aplikasi tiasa dilaksanakeun sanaos tanpa sepengetahuan administrator.
Masalah utama nyaéta henteu sadayana aplikasi tiasa dijalankeun dina kotak pasir. Sababaraha urang peryogi aksés langsung kana platform. Kuring malah teu ngawangkong ngeunaan modul kernel, nu mastikeun gumantung kana kernel jeung teu cocog kana konsép sandbox.
Masalah kadua nyaéta distribusi anu populer di lingkungan perusahaan ti Red Hat sareng SUSE henteu acan ngandung dukungan pikeun Snappy sareng Flatpak.
Dina hal ieu, Agen Veeam kanggo Linux teu aya hiji ogé teu asup .
Pikeun nyimpulkeun patarosan ngeunaan manajer pakét, kuring hoyong dicatet yén aya pilihan pikeun ngantunkeun manajer pakét sadayana ku ngagabungkeun file binér sareng skrip pikeun masangana kana hiji pakét.
Bundel ieu ngamungkinkeun anjeun pikeun nyieun hiji pakét umum pikeun distribusi sareng platform anu béda, ngalaksanakeun prosés pamasangan interaktif, sareng ngalaksanakeun kustomisasi anu diperyogikeun. Kuring parantos mendakan pakét sapertos kitu pikeun Linux ngan ukur ti VMware.
Masalah update
Sanaos sadaya masalah katergantungan direngsekeun, program tiasa jalanna béda dina distribusi anu sami. Ieu ngeunaan apdet.
Aya 3 strategi update:
- Anu pangbasajanna nyaéta henteu kantos ngapdet. Kuring nyetél server jeung poho ngeunaan eta. Naha ngamutahirkeun upami sadayana jalan? Masalah dimimitian nalika pertama kali anjeun ngahubungi dukungan. Panyipta distribusi ngan ukur ngadukung sékrési anu diropéa.
- Anjeun tiasa percanten ka distributor sareng nyetél apdet otomatis. Dina hal ieu, panggero pikeun ngarojong kamungkinan langsung saatos apdet gagal.
- Pilihan pikeun ngamutahirkeun manual ngan saatos ngajalankeun éta dina infrastruktur tés nyaéta anu paling dipercaya, tapi mahal sareng nyéépkeun waktos. Henteu sadayana tiasa nanggung.
Kusabab pamaké béda ngagunakeun strategi update béda, perlu pikeun ngarojong duanana release panganyarna na sagala release saméméhna. Ieu complicates duanana ngembangkeun sarta prosés nguji sarta nambahan headaches ka tim rojongan.
Rupa-rupa platform hardware
Platform hardware anu béda mangrupikeun masalah anu umumna khusus pikeun kode asli. Sahenteuna, anjeun kedah ngumpulkeun binér pikeun tiap platform anu dirojong.
Dina Agen Veeam pikeun proyék Linux Urang tetep teu bisa ngadukung nanaon nu sarupa jeung RISC.
Kuring moal Huni on masalah ieu di jéntré. Kuring ngan baris outline masalah utama: jenis gumantung platform, kayaning size_t, alignment struktur jeung urutan bait.
Statis jeung / atawa linking dinamis
Tapi patarosanna nyaéta "Kumaha ngaitkeun perpustakaan - sacara dinamis atanapi statis?" patut ngabahas.
Sacara umum, aplikasi C/C++ nyaéta Linux Anggo tautan dinamis. Ieu tiasa dianggo kalayan saé upami aplikasi diwangun khusus pikeun distribusi anu khusus.
Upami tugasna nyaéta nutupan rupa-rupa distribusi sareng hiji file binér, maka anjeun kedah fokus kana distribusi anu didukung pangkolotna. Pikeun urang, ieu Red Hat 6. Ieu ngandung gcc 4.4, nu sanajan standar C ++ 11 teu ngarojong. .
Urang ngawangun proyék urang ngagunakeun gcc 6.3, nu pinuh ngarojong C++ 14. Alami, dina hal ieu, dina Red Hat 6 anjeun kedah nyandak libstdc ++ sareng ningkatkeun perpustakaan sareng anjeun. Cara panggampangna nyaéta ngahubungkeun aranjeunna sacara statik.
Tapi sayangna, henteu sadayana perpustakaan tiasa dihubungkeun sacara statis.
Anu mimiti, perpustakaan sistem sapertos libfuse, libblkid perlu link dinamis pikeun mastikeun kasaluyuan maranéhanana jeung kernel jeung modul na.
Bréh, aya subtlety jeung lisensi.
Lisensi GPL dasarna ngamungkinkeun anjeun pikeun ngaitkeun perpustakaan ngan sareng kode opensource. MIT sareng BSD ngawenangkeun tautan statik sareng ngamungkinkeun perpustakaan kalebet dina proyék. Tapi LGPL teu sigana contradict linking statik, tapi merlukeun yén file dipikabutuh pikeun linking dibagikeun.
Sacara umum, ngagunakeun linking dinamis bakal nyegah anjeun ti ngabogaan nyadiakeun nanaon.
Ngawangun aplikasi C/C++
Pikeun ngawangun aplikasi C / C ++ pikeun platform sareng distribusi anu béda, cukup pikeun milih atanapi ngawangun versi gcc anu cocog sareng nganggo kompiler silang pikeun arsitéktur khusus sareng ngumpul sadayana perpustakaan. Karya ieu cukup meujeuhna, tapi rada nyusahkeun. Sareng teu aya jaminan yén kompiler sareng perpustakaan anu dipilih bakal nyayogikeun versi anu tiasa dianggo.
Kauntungan anu jelas: infrastrukturna disederhanakeun pisan, kumargi sadaya prosés ngawangun tiasa dilakukeun dina hiji mesin. Salajengna, cekap pikeun ngawangun hiji sét binér pikeun hiji arsitéktur, sareng éta tiasa dipak pikeun distribusi anu béda. Kieu persis kumaha Veeam ngapaksa pikeun Veeam Agent for Linux.
Sabalikna tina pilihan ieu, anjeun ngan saukur tiasa nyiapkeun tegalan ngawangun, nyaéta, sababaraha mesin pikeun assembly. Unggal mesin sapertos bakal nyayogikeun kompilasi aplikasi sareng rakitan pakét pikeun distribusi khusus sareng arsitéktur khusus. Dina hal ieu, kompilasi dilaksanakeun nganggo cara anu disiapkeun ku distributor. Nyaéta, tahap nyiapkeun kompiler sareng milih perpustakaan dileungitkeun. Sajaba ti éta, prosés ngawangun bisa gampang parallelized.
Sanajan kitu, aya hiji downside kana pendekatan ieu: pikeun tiap distribusi dina arsitektur sarua, Anjeun kudu ngumpulkeun set sorangan tina file binér. Karugian sanésna nyaéta yén sajumlah ageung mesin kedah dijaga sareng sajumlah ageung rohangan disk sareng RAM kedah dialokasikeun.
Ieu kumaha bungkusan KMOD tina modul kernel veeamsnap disusun pikeun distribusi Red Hat.
Buka Service Ngawangun
Kolega ti SUSE nyobian ngalaksanakeun sababaraha jalan tengah dina bentuk layanan khusus pikeun nyusun aplikasi sareng assembling bungkusan - .
Intina, éta mangrupikeun hypervisor anu nyiptakeun mesin virtual, masang sadaya pakét anu diperyogikeun di jerona, nyusun aplikasi sareng ngawangun pakét di lingkungan terasing ieu, saatos mesin virtual dileupaskeun.
Penjadwal anu dilaksanakeun dina OpenBuildService bakal nangtukeun sabaraha mesin virtual anu tiasa diluncurkeun pikeun laju ngawangun pakét anu optimal. Mékanisme penandatanganan anu diwangun bakal ngadaptarkeun bungkusan sareng unggah kana gudang anu diwangun. Sistem kontrol versi anu diwangun bakal ngahémat sajarah parobihan sareng ngawangun. Sadaya anu tetep nyaéta ngan ukur nambihan sumber anjeun kana sistem ieu. Anjeun malah henteu kedah nyetél server sorangan; anjeun tiasa nganggo anu kabuka.
Aya, kumaha oge, masalah: harvester misalna hiji hese pas kana infrastruktur aya. Contona, kontrol versi teu diperlukeun; urang geus boga sorangan pikeun kode sumber. Mékanisme tanda tangan kami béda: kami nganggo server khusus. Repository ogé henteu diperyogikeun.
Salaku tambahan, dukungan pikeun distribusi anu sanés - contona, Red Hat - dilaksanakeun rada kirang, anu kaharti.
Kauntungannana jasa sapertos nyaéta dukungan gancang pikeun versi salajengna tina distribusi SUSE. Sateuacan pengumuman resmi ngeunaan sékrési, bungkusan anu dipikabutuh pikeun rakitan dipasang dina gudang umum. Anu anyar muncul dina daptar distribusi anu sayogi dina OpenBuildService. Urang pariksa kotak sarta ditambahkeun kana rencana ngawangun. Ku kituna, nambahkeun versi anyar tina distribusi dipigawé dina ampir hiji klik.
Dina infrastruktur urang, ngagunakeun OpenBuildService, sakabeh rupa bungkusan KMP tina modul kernel veeamsnap pikeun sebaran SUSE dirakit.
Salajengna, abdi hoyong ngabahas masalah khusus pikeun modul kernel.
kernel ABI
Modul kernel Linux Sacara historis, éta disebarkeun dina bentuk kode sumber. Masalahna nyaéta para panyipta kernel henteu repot-repot ngajaga API anu stabil pikeun modul kernel, langkung-langkung dina tingkat binér (salajengna disebut kABI).
Pikeun ngawangun modul pikeun kernel vanili, anjeun pasti peryogi headers tina kernel husus ieu, sarta eta ngan bakal dianggo dina kernel ieu.
DKMS ngamungkinkeun otomatisasi pangwangunan modul salami apdet kernel. Hasilna, pangguna repositori Debian (sareng seueur dulurna) nganggo modul kernel boh tina gudang distributor atanapi dikompilasi tina sumber nganggo DKMS.
Nanging, kaayaan ieu henteu cocog sareng bagean Enterprise. Distributor kode proprietary hoyong ngadistribusikaeun produk salaku binér anu disusun.
Administrator teu hoyong nyimpen alat pamekaran dina server produksi kusabab alesan kaamanan. Distributor Perusahaan Linux — sapertos Red Hat sareng SUSE — mutuskeun yén aranjeunna tiasa ngadukung kABI anu stabil pikeun pangguna na. Hasilna, pakét KMOD pikeun Red Hat sareng pakét KMP pikeun SUSE didamel.
Hakekat solusi ieu cukup basajan. Pikeun versi husus tina distribusi, API kernel beku. Distributor nyatakeun yén anjeunna nganggo kernel, contona, 3.10, sareng ngan ukur koréksi sareng perbaikan anu henteu mangaruhan antarmuka kernel, sareng modul anu dikumpulkeun pikeun kernel anu munggaran tiasa dianggo pikeun sadayana anu salajengna tanpa kompilasi.
Red Hat ngaklaim kasaluyuan kABI pikeun distribusi sapanjang sakabéh siklus hirupna. Hartina, modul dirakit pikeun rhel 6.0 (ngaleupaskeun Nopémber 2010) ogé kedah dianggo dina versi 6.10 (ngaleupaskeun Juni 2018). Sareng ieu ampir 8 taun. Alami, tugas ieu rada hese.
Kami parantos ngarékam sababaraha kasus dimana modul veeamsnap lirén damel kusabab masalah kasaluyuan kABI.
Saatos modul veeamsnap, disusun pikeun RHEL 7.0, tétéla sauyunan sareng kernel ti RHEL 7.5, tapi dimuat sareng dijamin ngadat server, urang ngantunkeun panggunaan kABI kasaluyuan pikeun RHEL 7 sadayana.
Ayeuna, pakét KMOD pikeun RHEL 7 ngandung rakitan pikeun tiap versi pelepasan sareng naskah anu ngamuat modul.
SUSE ngadeukeutan tugas kasaluyuan kABI leuwih taliti. Aranjeunna nyadiakeun kasaluyuan kABI ngan dina hiji pak jasa.
Salaku conto, sékrési SLES 12 lumangsung dina Séptémber 2014. Sareng SLES 12 SP1 parantos aya dina bulan Désémber 2015, nyaéta, sakedik langkung ti sataun ka pengker. Sanaos duanana rilis nganggo kernel 3.12, aranjeunna kABI teu cocog. Jelas, ngajaga kasaluyuan kABI ngan ukur sataun langkung gampang. Siklus apdet modul kernel taunan teu matak ngabalukarkeun masalah pikeun panyipta modul.
Salaku hasil tina kawijakan SUSE ieu, kami henteu acan ngarékam masalah tunggal sareng kasaluyuan kABI dina modul veeamsnap kami. Leres, jumlah pakét kanggo SUSE ampir langkung ageung.
Patches na backports
Sanajan distributor nyoba pikeun mastikeun kasaluyuan kABI jeung stabilitas kernel, maranéhanana ogé nyoba ngaronjatkeun kinerja jeung ngaleungitkeun defects of kernel stabil ieu.
Dina waktos anu sami, salian ti "karya dina kasalahan" sorangan, pamekar perusahaan Linux kernel ngawas parobahan dina kernel vanili sareng nransferkeunana ka "stabil" na.
Kadang-kadang ieu ngakibatkeun nu anyar .
Dina sékrési panganyarna tina Red Hat 6, kasalahan dilakukeun dina salah sahiji pembaruan minor. Éta nyababkeun kanyataan yén modul veeamsnap dijamin ngadat sistem nalika snapshot dileupaskeun. Saatos ngabandingkeun sumber kernel sateuacan sareng saatos pembaruan, kami mendakan yén backport kedah disalahkeun. Perbaikan anu sami dilakukeun dina versi kernel vanili 4.19. Ieu ngan éta fix ieu digawé rupa dina kernel vanili, tapi lamun mindahkeun ka "stabil" 2.6.32, timbul masalah jeung spinlock nu.
Tangtu, dulur salawasna boga kasalahan, tapi éta patut nyered kodeu ti 4.19 ka 2.6.32, risking stabilitas? .. Kaula teu yakin ...
Hal awon nyaeta nalika pamasaran meunang aub dina tug-of-perang antara "stabilitas" jeung "modernisasi". Jurusan pamasaran peryogi inti distribusi anu diropéa janten stabil, di hiji sisi, sareng dina waktos anu sami langkung saé dina pagelaran sareng gaduh fitur anyar. Ieu ngakibatkeun compromises aneh.
Nalika kuring diusahakeun ngawangun modul on kernel 4.4 ti SLES 12 SP3, Kuring kaget manggihan fungsionalitas ti vanili 4.8 di dinya. Dina pamanggih kuring, palaksanaan blok I / O tina 4.4 kernel ti SLES 12 SP3 leuwih sarupa jeung 4.8 kernel ti release saméméhna tina stabil 4.4 kernel ti SLES12 SP2. Abdi teu tiasa nangtoskeun naon perséntase kode ditransferkeun ti kernel 4.8 mun SLES 4.4 pikeun SP3, tapi malah teu bisa nelepon kernel sarua stabil 4.4.
Hal anu paling pikaresepeun ngeunaan ieu nyaéta nalika nyerat modul anu bakal dianggo ogé dina kernel anu béda, anjeun moal tiasa deui ngandelkeun versi kernel. Anjeun oge kudu tumut kana akun distribusi. Ieu alus nu kadang anjeun bisa aub dina harti nu mucunghul babarengan jeung fungsionalitas anyar, tapi kasempetan ieu teu salawasna muncul.
Hasilna, kode jadi overgrown kalawan diréktif kompilasi kondisional aneh.
Aya ogé patch anu ngarobih API kernel anu didokumentasikeun.
Kuring datang di sakuliah distribusi 5.16 sareng reuwas pisan ningali yén panggero lookup_bdev dina versi kernel ieu ngarobih daptar parameter input.
Pikeun ngumpulkeun éta, kuring kedah nambihan naskah kana makefile anu mariksa naha fungsi lookup_bdev ngagaduhan parameter masker.
Signing modul kernel
Tapi hayu urang balik deui ka masalah distribusi pakét.
Salah sahiji kaunggulan kABI stabil nyaéta modul kernel tiasa ditandatanganan salaku file binér. Dina hal ieu, pamekar bisa mastikeun yén modul teu kahaja ruksak atawa ngahaja dirobah. Anjeun tiasa pariksa ieu ku paréntah modinfo.
Sebaran Red Hat sareng SUSE ngamungkinkeun anjeun mariksa tandatangan modul sareng ngamuat ngan upami sertipikat anu saluyu didaptarkeun dina sistem. Sertipikat mangrupikeun konci umum dimana modul ditandatanganan. Urang ngadistribusikaeun salaku pakét misah.
Masalahna di dieu nyaéta yén sertipikat tiasa diwangun kana kernel (distributor ngagunakeunana) atanapi kedah diserat kana mémori non-volatile EFI nganggo utiliti. mokutil. Utiliti mokutil Nalika masang sertipikat, éta meryogikeun anjeun reboot sistem sareng, bahkan sateuacan ngamuat kernel sistem operasi, naroskeun administrator pikeun ngijinkeun loading sertipikat énggal.
Ku kituna, nambahkeun sertipikat merlukeun aksés administrator fisik kana sistem. Upami mesinna aya di mana waé dina awan atanapi ngan ukur di kamar server jauh sareng aksés ngan ukur ngalangkungan jaringan (contona, via ssh), maka moal mungkin pikeun nambihan sertipikat.
EFI dina mesin virtual
Sanaos kanyataan yén EFI parantos lami dirojong ku ampir sadaya produsén motherboard, nalika masang sistem, pangurus panginten henteu mikirkeun kabutuhan EFI, sareng éta tiasa ditumpurkeun.
Henteu sakabéh hypervisors ngarojong EFI. VMWare vSphere ngadukung EFI mimitian ti versi 5.
Microsoft Hyper-V ogé nampi dukungan EFI, dimimitian ku Hyper-V pikeun Windows Server 2012R2.
Nanging, dina konfigurasi standar, fungsi ieu kanggo Linux Mesinna pareum, anu hartosna sertipikatna teu tiasa dipasang.
Dina vSphere 6.5, setel pilihan boot aman ngan mungkin dina versi heubeul tina panganteur web, nu dijalankeun via Flash. UI wéb dina HTML-5 masih jauh.
Distribusi ékspérimén
Tungtungna, hayu urang nganggap masalah distribusi sareng distribusi ékspérimén tanpa dukungan resmi. Di hiji sisi, panyebaran sapertos kitu sigana moal aya dina server organisasi serius. Henteu aya dukungan resmi pikeun distribusi sapertos kitu. Ku alatan éta, nyadiakeun pamadegan. Produk teu tiasa dirojong dina distribusi sapertos kitu.
Nanging, distribusi sapertos kitu janten platform anu merenah pikeun nyobian solusi ékspériméntal énggal. Salaku conto, Fedora, OpenSUSE Tumbleweed, atanapi vérsi Unstable. DebianAranjeunna lumayan stabil. Aranjeunna salawasna gaduh vérsi parangkat lunak énggal sareng kernel énggal. Dina sataun, fungsi ékspériméntal ieu tiasa waé réngsé dina RHEL, SLES, atanapi anu diénggalan. Ubuntu.
Janten upami aya anu henteu tiasa dianggo dina distribusi ékspérimén, ieu mangrupikeun alesan pikeun terang masalahna sareng ngabéréskeunana. Anjeun kedah siap pikeun kanyataan yén fungsionalitas ieu bakal muncul dina server produksi pangguna.
Anjeun tiasa ngulik daptar ayeuna distribusi anu dirojong sacara resmi pikeun versi 3.0 . Tapi daptar nyata distribusi dimana produk urang tiasa dianggo langkung lega.
Pribadi, kuring resep kana ékspérimén sareng Elbrus OS. Saatos ngabéréskeun pakét veeam, produk urang dipasang sareng jalan. Kuring nulis ngeunaan percobaan ieu dina Habré di .
Nya, dukungan pikeun distribusi énggal diteruskeun. Kami ngantosan versi 4.0 dileupaskeun. Béta badé muncul, janten jaga !
sumber: www.habr.com
