Nyiptakeun aplikasi cadangan anu tiasa dianggo dina distribusi naon waé sanés tugas anu gampang. Pikeun mastikeun Veeam Agent for Linux berpungsi dina distribusi tina Red Hat 6 sareng Debian 6, ka OpenSUSE 15.1 sareng Ubuntu 19.04, anjeun kedah ngabéréskeun sajumlah masalah, khususna mertimbangkeun yén produk parangkat lunak kalebet modul kernel.
Tulisan ieu didamel dumasar kana bahan tina pidato dina konperénsi éta .
Linux sanés ngan ukur salah sahiji sistem operasi anu pang populerna. Intina, ieu mangrupikeun platform anu anjeun tiasa ngadamel anu unik, anu anjeun sorangan. Hatur nuhun kana ieu, Linux ngagaduhan seueur distribusi anu béda dina sét komponén parangkat lunak. Sareng di dieu timbul masalah: supados produk parangkat lunak tiasa dianggo dina distribusi naon waé, anjeun kedah tumut kana fitur masing-masing.
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.
Di dunya bungkusan deb, tingkat kasaluyuan luar biasa. Paket anu sami dipasang sareng jalanna sami-sami dina Debian 6 sareng Ubuntu 19.04. Standar pikeun prosés ngawangun bungkusan sareng damel sareng aranjeunna, ditetepkeun dina distribusi Debian lami, tetep relevan dina Linux Mint sareng OS dasar. Ku alatan éta, dina kasus Veeam Agent pikeun Linux, hiji pakét deb pikeun tiap platform hardware cukup.
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.
Pikeun ngagabungkeun rupa-rupa perpustakaan sareng aplikasi supados aranjeunna sadayana tiasa dianggo sacara stabil sareng henteu konflik - kanyataanna, ieu mangrupikeun tugas anu badé direngsekeun ku 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 ogé ngamungkinkeun anjeun pikeun ngajalankeun aplikasi dina kotak pasir nganggo Wadah Linux. Gagasan sandbox ogé dianggo 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, Veeam Agent pikeun Linux henteu sayogi 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.
Bungkusan sapertos kitu ngamungkinkeun anjeun nyiptakeun pakét umum pikeun distribusi sareng platform anu béda, ngalaksanakeun prosés pamasangan interaktif, ngalaksanakeun kustomisasi anu diperyogikeun. Kuring ngan ukur mendakan bungkusan sapertos Linux 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 proyék Veeam Agent for Linux, urang masih teu tiasa ngadukung nanaon sapertos RISC ieu.
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.
Sakumaha aturan, aplikasi C/C++ dina Linux Ubuntu make linking dinamis. Ieu jalan hébat lamun aplikasi ieu diwangun husus pikeun sebaran husus.
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.
Hiji kaunggulan atra: infrastruktur ieu greatly disederhanakeun, saprak sakabéh prosés ngawangun bisa réngsé dina hiji mesin. Salaku tambahan, cukup pikeun ngumpulkeun hiji set binari pikeun hiji arsitéktur sareng anjeun tiasa ngarangkep kana bungkusan pikeun distribusi anu béda. Ieu kumaha bungkusan veeam diwangun pikeun Veeam Agent pikeun 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 Ubuntu sajarahna geus disebarkeun dina formulir sumber. Kanyataan yén panyipta kernel henteu ngabeungbeuratan diri kalayan perhatian pikeun ngadukung API anu stabil pikeun modul kernel, sareng khususna dina tingkat binér, anu 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 anjeun pikeun ngajadikeun otomatis prosés ngawangun modul nalika ngamutahirkeun kernel. Hasilna, pamaké Repository Debian (sareng seueur barayana) nganggo modul kernel boh tina gudang distributor atanapi disusun tina sumber nganggo DKMS.
Nanging, kaayaan ieu henteu cocog sareng bagean Enterprise. Distributor kode proprietary hoyong ngadistribusikaeun produk salaku binér anu disusun.
Administrator henteu hoyong ngajaga alat pangembangan dina server produksi kusabab alesan kaamanan. Distributor perusahaan Linux sapertos Red Hat sareng SUSE mutuskeun yén aranjeunna tiasa ngadukung kABI anu stabil pikeun panggunana. Hasilna nyaéta bungkusan KMOD pikeun Red Hat sareng bungkusan KMP pikeun SUSE.
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é meunang rojongan EFI dimimitian ku Hyper-V pikeun Windows Server 2012R2.
Nanging, dina konfigurasi standar fungsi ieu ditumpurkeun pikeun mesin Linux, anu hartosna sertipikat henteu 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 cocog pikeun nyobian solusi ékspérimén énggal. Contona, Fedora, OpenSUSE Tumbleweed atanapi versi Unstable of Debian. Aranjeunna rada stabil. Aranjeunna salawasna gaduh versi anyar program sarta salawasna kernel anyar. Dina sataun, fungsionalitas ékspérimén ieu tiasa mungkas dina RHEL, SLES atanapi Ubuntu anu diropéa.
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