Mencipta aplikasi sandaran yang berfungsi pada mana-mana pengedaran bukanlah tugas yang mudah. Untuk memastikan Veeam Agent for Linux berfungsi pada pengedaran daripada Red Hat 6 dan Debian 6, kepada OpenSUSE 15.1 dan Ubuntu 19.04, anda perlu menyelesaikan pelbagai masalah, terutamanya memandangkan produk perisian tersebut termasuk modul kernel.
Artikel itu dibuat berdasarkan bahan daripada ucapan di persidangan itu .
Linux bukan hanya salah satu sistem pengendalian yang paling popular. Pada asasnya, ini adalah platform di mana anda boleh membuat sesuatu yang unik, sesuatu yang anda sendiri. Terima kasih kepada ini, Linux mempunyai banyak pengedaran yang berbeza dalam set komponen perisian mereka. Dan di sini masalah timbul: agar produk perisian berfungsi pada mana-mana pengedaran, anda perlu mengambil kira ciri masing-masing.
Pengurus pakej. .deb lwn .rpm
Mari kita mulakan dengan masalah yang jelas untuk mengedarkan produk merentasi pengedaran yang berbeza.
Cara paling biasa untuk mengedarkan produk perisian ialah meletakkan pakej pada repositori supaya pengurus pakej yang terbina dalam sistem boleh memasangnya dari sana.
Walau bagaimanapun, kami mempunyai dua format pakej yang popular: rpm ΠΈ deb. Ini bermakna semua orang perlu menyokong.
Dalam dunia pakej deb, tahap keserasian adalah menakjubkan. Pakej yang sama dipasang dan berfungsi dengan baik pada kedua-dua Debian 6 dan Ubuntu 19.04. Piawaian untuk proses membina pakej dan bekerja dengannya, yang ditetapkan dalam pengedaran Debian lama, kekal relevan dalam Linux Mint dan OS asas. Oleh itu, dalam kes Veeam Agent untuk Linux, satu pakej deb untuk setiap platform perkakasan adalah mencukupi.
Tetapi dalam dunia pakej rpm, perbezaannya sangat besar. Pertama, disebabkan oleh fakta bahawa terdapat dua pengedar bebas sepenuhnya, Red Hat dan SUSE, yang mana keserasian sama sekali tidak diperlukan. Kedua, pengedar ini mempunyai kit pengedaran daripada mereka. sokongan dan eksperimen. Tidak perlu ada keserasian antara mereka juga. Ternyata el6, el7 dan el8 mempunyai pakej mereka sendiri. Pakej berasingan untuk Fedora. Pakej untuk SLES11 dan 12 dan yang berasingan untuk openSUSE. Masalah utama ialah kebergantungan dan nama pakej.
Masalah kebergantungan
Malangnya, pakej yang sama sering berakhir di bawah nama yang berbeza dalam pengedaran yang berbeza. Di bawah ialah senarai separa kebergantungan pakej veeam.
Untuk EL7:
Untuk SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fius-libs
- file-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc ++ 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Akibatnya, senarai tanggungan adalah unik untuk pengedaran.
Apa yang menjadi lebih teruk ialah apabila versi yang dikemas kini mula bersembunyi di bawah nama pakej lama.
Contoh:
Pakej telah dikemas kini dalam Fedora 24 ncurses dari versi 5 hingga versi 6. Produk kami dibina dengan versi 5 untuk memastikan keserasian dengan pengedaran yang lebih lama. Untuk menggunakan versi 5 perpustakaan lama pada Fedora 24, saya terpaksa menggunakan pakej tersebut ncurses-compat-libs.
Akibatnya, terdapat dua pakej untuk Fedora, dengan kebergantungan yang berbeza.
Lebih menarik lagi. Selepas kemas kini pengedaran seterusnya, pakej ncurses-compat-libs dengan versi 5 perpustakaan ternyata tidak tersedia. Adalah mahal bagi pengedar untuk menyeret perpustakaan lama ke versi pengedaran baharu. Selepas beberapa lama, masalah itu berulang dalam pengedaran SUSE.
Akibatnya, sesetengah pengedaran terpaksa menggugurkan pergantungan eksplisit mereka pada ncurses-libs, dan betulkan produk supaya ia boleh berfungsi dengan mana-mana versi pustaka.
By the way, dalam versi 8 Red Hat tiada lagi pakej meta ular sawa, yang merujuk kepada lama yang baik ular sawa 2.7... terdapat python2 ΠΈ ular sawa3.
Alternatif kepada pengurus pakej
Masalah dengan kebergantungan sudah lama dan telah lama jelas. Ingat sahaja Ketergantungan neraka.
Untuk menggabungkan pelbagai perpustakaan dan aplikasi supaya semuanya berfungsi dengan stabil dan tidak bercanggah - sebenarnya, ini adalah tugas yang cuba diselesaikan oleh mana-mana pengedar Linux.
Pengurus pakej cuba menyelesaikan masalah ini dengan cara yang sama sekali berbeza. Snappy daripada Canonical. Idea utama: aplikasi berjalan dalam kotak pasir terpencil dan dilindungi daripada sistem utama. Jika aplikasi memerlukan perpustakaan, ia dibekalkan dengan aplikasi itu sendiri.
Flatpak juga membolehkan anda menjalankan aplikasi dalam kotak pasir menggunakan Bekas Linux. Idea kotak pasir juga digunakan AppImage.
Penyelesaian ini membolehkan anda membuat satu pakej untuk sebarang pengedaran. Dalam kes Flatpak pemasangan dan pelancaran aplikasi boleh dilakukan walaupun tanpa pengetahuan pentadbir.
Masalah utama ialah tidak semua aplikasi boleh dijalankan dalam kotak pasir. Sesetengah orang memerlukan akses terus ke platform. Saya tidak bercakap tentang modul kernel, yang bergantung sepenuhnya pada kernel dan tidak sesuai dengan konsep kotak pasir.
Masalah kedua ialah pengedaran yang popular dalam persekitaran perusahaan daripada Red Hat dan SUSE belum lagi mengandungi sokongan untuk Snappy dan Flatpak.
Dalam hal ini, Ejen Veeam untuk Linux tidak tersedia tidak sama sekali .
Untuk menyimpulkan soalan tentang pengurus pakej, saya ingin ambil perhatian bahawa terdapat pilihan untuk meninggalkan pengurus pakej sama sekali dengan menggabungkan fail binari dan skrip untuk memasangnya ke dalam satu pakej.
Himpunan sedemikian membolehkan anda membuat satu pakej biasa untuk pengedaran dan platform yang berbeza, menjalankan proses pemasangan interaktif, menjalankan penyesuaian yang diperlukan. Saya hanya menemui pakej sedemikian untuk Linux daripada VMware.
Masalah kemas kini
Walaupun semua isu pergantungan diselesaikan, program mungkin berjalan secara berbeza pada pengedaran yang sama. Ini soal kemas kini.
Terdapat 3 strategi kemas kini:
- Yang paling mudah ialah jangan sekali-kali mengemas kini. Saya menyediakan pelayan dan melupakannya. Mengapa mengemas kini jika semuanya berfungsi? Masalah bermula pada kali pertama anda menghubungi sokongan. Pencipta pengedaran hanya menyokong keluaran yang dikemas kini.
- Anda boleh mempercayai pengedar dan menyediakan kemas kini automatik. Dalam kes ini, panggilan untuk menyokong berkemungkinan serta-merta selepas kemas kini yang tidak berjaya.
- Pilihan untuk mengemas kini manual hanya selepas menjalankannya pada infrastruktur ujian adalah yang paling boleh dipercayai, tetapi mahal dan memakan masa. Bukan semua orang mampu.
Memandangkan pengguna yang berbeza menggunakan strategi kemas kini yang berbeza, adalah perlu untuk menyokong kedua-dua keluaran terbaharu dan semua keluaran yang dikeluarkan sebelum ini. Ini merumitkan kedua-dua proses pembangunan dan ujian serta menambah sakit kepala kepada pasukan sokongan.
Pelbagai platform perkakasan
Platform perkakasan yang berbeza adalah masalah yang sebahagian besarnya khusus untuk kod asli. Sekurang-kurangnya, anda perlu mengumpul binari untuk setiap platform yang disokong.
Dalam projek Ejen Veeam untuk Linux, kami masih tidak dapat menyokong apa-apa seperti RISC ini.
Saya tidak akan membincangkan isu ini secara terperinci. Saya hanya akan menggariskan masalah utama: jenis bergantung pada platform, seperti size_t, penjajaran struktur dan susunan bait.
Pautan statik dan/atau dinamik
Tetapi persoalannya ialah "Bagaimana untuk memaut dengan perpustakaan - secara dinamik atau statik?" patut dibincangkan.
Sebagai peraturan, aplikasi C/C++ di bawah Linux menggunakan pemautan dinamik. Ini berfungsi dengan baik jika aplikasi dibina khusus untuk pengedaran tertentu.
Jika tugasnya adalah untuk menampung pelbagai pengedaran dengan satu fail binari, maka anda perlu memberi tumpuan kepada pengedaran yang paling lama disokong. Bagi kami, ini ialah Red Hat 6. Ia mengandungi gcc 4.4, yang walaupun standard C++11 tidak menyokong .
Kami membina projek kami menggunakan gcc 6.3, yang menyokong sepenuhnya C++14. Sememangnya, dalam kes ini, pada Red Hat 6 anda perlu membawa libstdc++ dan meningkatkan perpustakaan dengan anda. Cara paling mudah ialah memautkannya secara statik.
Tetapi sayangnya, tidak semua perpustakaan boleh dipautkan secara statik.
Pertama, perpustakaan sistem seperti libfuse, libblkid adalah perlu untuk menghubungkan secara dinamik untuk memastikan keserasiannya dengan kernel dan modulnya.
Kedua, terdapat kehalusan dengan lesen.
Lesen GPL pada asasnya membolehkan anda memautkan perpustakaan hanya dengan kod sumber terbuka. MIT dan BSD membenarkan pemautan statik dan membenarkan perpustakaan dimasukkan ke dalam projek. Tetapi LGPL nampaknya tidak bercanggah dengan pemautan statik, tetapi memerlukan fail yang diperlukan untuk pemautan dikongsi.
Secara umum, menggunakan pautan dinamik akan menghalang anda daripada perlu menyediakan apa-apa.
Membina aplikasi C/C++
Untuk membina aplikasi C/C++ untuk platform dan pengedaran yang berbeza, sudah cukup untuk memilih atau membina versi gcc yang sesuai dan menggunakan pengkompil silang untuk seni bina tertentu dan memasang keseluruhan set perpustakaan. Kerja ini agak boleh dilaksanakan, tetapi agak menyusahkan. Dan tidak ada jaminan bahawa pengkompil dan perpustakaan yang dipilih akan menyediakan versi yang boleh dilaksanakan.
Kelebihan yang jelas: infrastruktur sangat dipermudahkan, kerana keseluruhan proses binaan boleh diselesaikan pada satu mesin. Di samping itu, cukup untuk mengumpul satu set binari untuk satu seni bina dan anda boleh membungkusnya ke dalam pakej untuk pengedaran yang berbeza. Beginilah cara pakej veeam dibina untuk Ejen Veeam untuk Linux.
Bertentangan dengan pilihan ini, anda hanya boleh menyediakan ladang binaan, iaitu beberapa mesin untuk pemasangan. Setiap mesin tersebut akan menyediakan kompilasi aplikasi dan pemasangan pakej untuk pengedaran tertentu dan seni bina tertentu. Dalam kes ini, kompilasi dijalankan menggunakan cara yang disediakan oleh pengedar. Iaitu, peringkat menyediakan pengkompil dan memilih perpustakaan dihapuskan. Di samping itu, proses binaan boleh diselaraskan dengan mudah.
Walau bagaimanapun, terdapat kelemahan pada pendekatan ini: untuk setiap pengedaran dalam seni bina yang sama, anda perlu mengumpul set fail binari anda sendiri. Satu lagi kelemahan ialah bilangan mesin yang begitu besar perlu diselenggara dan sejumlah besar ruang cakera dan RAM mesti diperuntukkan.
Beginilah cara pakej KMOD modul kernel veeamsnap disusun untuk pengedaran Red Hat.
Perkhidmatan Binaan Terbuka
Rakan sekerja dari SUSE cuba melaksanakan beberapa jalan tengah dalam bentuk perkhidmatan khas untuk menyusun aplikasi dan memasang pakej - .
Pada asasnya, ia adalah hypervisor yang mencipta mesin maya, memasang semua pakej yang diperlukan di dalamnya, menyusun aplikasi dan membina pakej dalam persekitaran terpencil ini, selepas itu mesin maya dikeluarkan.
Penjadual yang dilaksanakan dalam OpenBuildService akan menentukan bilangan mesin maya yang boleh dilancarkan untuk kelajuan pembinaan pakej yang optimum. Mekanisme tandatangan terbina dalam akan menandatangani pakej dan memuat naiknya ke repositori terbina dalam. Sistem kawalan versi terbina dalam akan menyimpan sejarah perubahan dan binaan. Yang tinggal hanyalah menambah sumber anda pada sistem ini. Anda tidak perlu menyediakan pelayan sendiri; anda boleh menggunakan pelayan terbuka.
Walau bagaimanapun, terdapat masalah: penuai seperti itu sukar untuk dimuatkan ke dalam infrastruktur sedia ada. Sebagai contoh, kawalan versi tidak diperlukan; kami sudah mempunyai kod sumber kami sendiri. Mekanisme tandatangan kami berbeza: kami menggunakan pelayan khas. Repositori juga tidak diperlukan.
Di samping itu, sokongan untuk pengedaran lain - sebagai contoh, Red Hat - dilaksanakan agak teruk, yang boleh difahami.
Kelebihan perkhidmatan sedemikian ialah sokongan pantas untuk versi pengedaran SUSE yang seterusnya. Sebelum pengumuman rasmi keluaran, pakej yang diperlukan untuk pemasangan disiarkan pada repositori awam. Yang baharu muncul dalam senarai pengedaran yang tersedia di OpenBuildService. Kami menandakan kotak dan ia ditambahkan pada pelan binaan. Oleh itu, menambah versi baharu pengedaran dilakukan dalam hampir satu klik.
Dalam infrastruktur kami, menggunakan OpenBuildService, keseluruhan pelbagai pakej KMP modul kernel veeamsnap untuk pengedaran SUSE dipasang.
Seterusnya, saya ingin membincangkan isu khusus untuk modul kernel.
kernel ABI
Modul kernel Linux secara sejarah telah diedarkan dalam bentuk sumber. Hakikatnya ialah pencipta kernel tidak membebankan diri mereka dengan keprihatinan menyokong API yang stabil untuk modul kernel, dan terutamanya pada peringkat binari, selanjutnya dirujuk sebagai kABI.
Untuk membina modul untuk kernel vanila, anda pasti memerlukan pengepala kernel khusus ini, dan ia hanya akan berfungsi pada kernel ini.
DKMS membolehkan anda mengautomasikan proses membina modul apabila mengemas kini kernel. Akibatnya, pengguna repositori Debian (dan banyak saudaranya) menggunakan modul kernel sama ada dari repositori pengedar atau disusun daripada sumber menggunakan DKMS.
Walau bagaimanapun, keadaan ini tidak sesuai dengan segmen Perusahaan. Pengedar kod proprietari ingin mengedarkan produk sebagai binari yang disusun.
Pentadbir tidak mahu menyimpan alat pembangunan pada pelayan pengeluaran atas sebab keselamatan. Pengedar Enterprise Linux seperti Red Hat dan SUSE memutuskan bahawa mereka boleh menyokong kABI yang stabil untuk pengguna mereka. Hasilnya ialah pakej KMOD untuk Red Hat dan pakej KMP untuk SUSE.
Intipati penyelesaian ini agak mudah. Untuk versi pengedaran tertentu, API kernel dibekukan. Pengedar menyatakan bahawa dia menggunakan kernel, contohnya, 3.10, dan hanya membuat pembetulan dan penambahbaikan yang tidak menjejaskan antara muka kernel, dan modul yang dikumpul untuk kernel pertama boleh digunakan untuk semua yang berikutnya tanpa penyusunan semula.
Red Hat mendakwa keserasian kABI untuk pengedaran sepanjang keseluruhan kitaran hayatnya. Iaitu, modul yang dipasang untuk rhel 6.0 (keluaran November 2010) juga harus berfungsi pada versi 6.10 (keluaran Jun 2018). Dan ini hampir 8 tahun. Sememangnya, tugas ini agak sukar.
Kami telah merekodkan beberapa kes di mana modul veeamsnap berhenti berfungsi kerana isu keserasian kABI.
Selepas modul veeamsnap, yang disusun untuk RHEL 7.0, ternyata tidak serasi dengan kernel daripada RHEL 7.5, tetapi ia dimuatkan dan dijamin akan ranap pelayan, kami meninggalkan penggunaan keserasian kABI untuk RHEL 7 sama sekali.
Pada masa ini, pakej KMOD untuk RHEL 7 mengandungi pemasangan untuk setiap versi keluaran dan skrip yang memuatkan modul.
SUSE mendekati tugas keserasian kABI dengan lebih berhati-hati. Mereka menyediakan keserasian kABI hanya dalam satu pek perkhidmatan.
Sebagai contoh, keluaran SLES 12 berlaku pada September 2014. Dan SLES 12 SP1 sudah pun pada Disember 2015, iaitu lebih sedikit daripada setahun telah berlalu. Walaupun kedua-dua keluaran menggunakan kernel 3.12, ia adalah kABI tidak serasi. Jelas sekali, mengekalkan keserasian kABI untuk hanya setahun adalah lebih mudah. Kitaran kemas kini modul kernel tahunan seharusnya tidak menyebabkan masalah kepada pencipta modul.
Hasil daripada dasar SUSE ini, kami tidak merekodkan satu masalah pun dengan keserasian kABI dalam modul veeamsnap kami. Benar, bilangan pakej untuk SUSE hampir satu susunan magnitud yang lebih besar.
Tampalan dan backports
Walaupun pengedar cuba memastikan keserasian kABI dan kestabilan kernel, mereka juga cuba meningkatkan prestasi dan menghapuskan kecacatan kernel stabil ini.
Pada masa yang sama, sebagai tambahan kepada "kerja pada ralat" mereka sendiri, pembangun kernel Linux perusahaan memantau perubahan dalam kernel vanila dan memindahkannya ke kernel "stabil" mereka.
Kadang-kadang ini membawa kepada yang baru .
Dalam keluaran terbaru Red Hat 6, kesilapan telah dilakukan dalam salah satu kemas kini kecil. Ia membawa kepada fakta bahawa modul veeamsnap telah dijamin untuk ranap sistem apabila syot kilat dikeluarkan. Setelah membandingkan sumber kernel sebelum dan selepas kemas kini, kami mendapati bahawa backport harus dipersalahkan. Pembaikan serupa telah dibuat dalam kernel vanila versi 4.19. Cuma pembetulan ini berfungsi dengan baik dalam inti vanila, tetapi apabila memindahkannya ke "stabil" 2.6.32, masalah timbul dengan kunci spin.
Sudah tentu, setiap orang sentiasa mempunyai ralat, tetapi adakah ia berbaloi untuk menyeret kod dari 4.19 ke 2.6.32, mempertaruhkan kestabilan?.. Saya tidak pasti...
Perkara yang paling teruk ialah apabila pemasaran terlibat dalam tarik tali antara "kestabilan" dan "pemodenan". Jabatan pemasaran memerlukan teras pengedaran yang dikemas kini supaya stabil, dalam satu pihak, dan pada masa yang sama menjadi lebih baik dalam prestasi dan mempunyai ciri baharu. Ini membawa kepada kompromi yang aneh.
Apabila saya cuba membina modul pada kernel 4.4 daripada SLES 12 SP3, saya terkejut apabila mendapati fungsi daripada vanilla 4.8 di dalamnya. Pada pendapat saya, pelaksanaan blok I/O bagi kernel 4.4 daripada SLES 12 SP3 adalah lebih serupa dengan kernel 4.8 daripada keluaran sebelumnya bagi kernel 4.4 yang stabil daripada SLES12 SP2. Saya tidak dapat menilai berapa peratusan kod yang dipindahkan daripada kernel 4.8 kepada SLES 4.4 untuk SP3, tetapi saya tidak boleh memanggil kernel sama stabil 4.4.
Perkara yang paling tidak menyenangkan tentang ini ialah apabila menulis modul yang akan berfungsi dengan baik pada kernel yang berbeza, anda tidak boleh lagi bergantung pada versi kernel. Anda juga perlu mengambil kira pengedaran. Adalah baik bahawa kadangkala anda boleh terlibat dalam definisi yang muncul bersama-sama dengan fungsi baharu, tetapi peluang ini tidak selalu muncul.
Akibatnya, kod itu menjadi ditumbuhi dengan arahan penyusunan bersyarat yang pelik.
Terdapat juga patch yang mengubah API kernel yang didokumenkan.
Saya terjumpa pengedaran 5.16 dan sangat terkejut melihat bahawa panggilan lookup_bdev dalam versi kernel ini menukar senarai parameter input.
Untuk mengumpulkannya, saya terpaksa menambah skrip pada makefile yang menyemak sama ada fungsi lookup_bdev mempunyai parameter topeng.
Menandatangani modul kernel
Tetapi mari kita kembali kepada isu pengedaran pakej.
Salah satu kelebihan kABI yang stabil ialah modul kernel boleh ditandatangani sebagai fail binari. Dalam kes ini, pembangun boleh memastikan bahawa modul itu tidak rosak secara tidak sengaja atau diubah suai dengan sengaja. Anda boleh menyemak ini dengan arahan modinfo.
Pengagihan Red Hat dan SUSE membolehkan anda menyemak tandatangan modul dan memuatkannya hanya jika sijil yang sepadan didaftarkan pada sistem. Sijil ialah kunci awam yang dengannya modul ditandatangani. Kami mengedarkannya sebagai pakej berasingan.
Masalahnya di sini ialah sijil sama ada boleh dibina ke dalam kernel (pengedar menggunakannya) atau mesti ditulis ke memori tidak meruap EFI menggunakan utiliti mokutil. Utiliti mokutil Apabila memasang sijil, ia memerlukan anda but semula sistem dan, walaupun sebelum memuatkan kernel sistem pengendalian, menggesa pentadbir membenarkan pemuatan sijil baharu.
Oleh itu, menambah sijil memerlukan akses pentadbir fizikal kepada sistem. Jika mesin terletak di suatu tempat di awan atau hanya di dalam bilik pelayan jauh dan akses hanya melalui rangkaian (contohnya, melalui ssh), maka adalah mustahil untuk menambah sijil.
EFI pada mesin maya
Walaupun fakta bahawa EFI telah lama disokong oleh hampir semua pengeluar papan induk, apabila memasang sistem, pentadbir mungkin tidak memikirkan keperluan untuk EFI, dan ia mungkin dilumpuhkan.
Tidak semua hypervisor menyokong EFI. VMWare vSphere menyokong EFI bermula dari versi 5.
Microsoft Hyper-V juga mendapat sokongan EFI bermula dengan Hyper-V untuk Windows Server 2012R2.
Walau bagaimanapun, dalam konfigurasi lalai fungsi ini dilumpuhkan untuk mesin Linux, yang bermaksud sijil tidak boleh dipasang.
Dalam vSphere 6.5, tetapkan pilihan Boot selamat hanya mungkin dalam versi lama antara muka web, yang berjalan melalui Flash. UI Web pada HTML-5 masih jauh ketinggalan.
Pengagihan eksperimen
Dan akhirnya, mari kita pertimbangkan isu pengedaran dan pengedaran percubaan tanpa sokongan rasmi. Di satu pihak, pengedaran sedemikian tidak mungkin ditemui pada pelayan organisasi yang serius. Tiada sokongan rasmi untuk pengedaran sedemikian. Oleh itu, sediakan mereka. Produk tidak boleh disokong pada pengedaran sedemikian.
Walau bagaimanapun, pengedaran sedemikian menjadi platform yang mudah untuk mencuba penyelesaian percubaan baharu. Contohnya, Fedora, OpenSUSE Tumbleweed atau versi Unstable Debian. Mereka agak stabil. Mereka sentiasa mempunyai versi program baharu dan sentiasa kernel baharu. Dalam setahun, fungsi percubaan ini mungkin berakhir dalam RHEL, SLES atau Ubuntu yang dikemas kini.
Jadi jika sesuatu tidak berfungsi pada pengedaran percubaan, ini adalah sebab untuk memikirkan masalah dan menyelesaikannya. Anda perlu bersedia untuk fakta bahawa fungsi ini akan muncul pada pelayan pengeluaran pengguna tidak lama lagi.
Anda boleh mengkaji senarai semasa pengedaran yang disokong secara rasmi untuk versi 3.0 . Tetapi senarai sebenar pengedaran yang produk kami boleh berfungsi adalah lebih luas.
Secara peribadi, saya berminat dengan eksperimen dengan OS Elbrus. Selepas memuktamadkan pakej veeam, produk kami telah dipasang dan berfungsi. Saya menulis tentang eksperimen ini pada HabrΓ© dalam .
Nah, sokongan untuk pengedaran baharu diteruskan. Kami sedang menunggu versi 4.0 dikeluarkan. Beta akan muncul, jadi awasi !
Sumber: www.habr.com