Herhangi bir dağıtımda çalışan bir yedekleme uygulaması oluşturmak kolay bir iş değildir. Linux için Veeam Agent'ın Red Hat 6 ve Debian 6'dan OpenSUSE 15.1 ve Ubuntu 19.04'e kadar olan dağıtımlarda çalışmasını sağlamak için, özellikle yazılım ürününün bir çekirdek modülü içerdiği göz önüne alındığında, çeşitli sorunları çözmeniz gerekir.
Makale konferansta yapılan bir konuşmadaki materyallere dayanarak oluşturuldu .
Linux yalnızca en popüler işletim sistemlerinden biri değildir. Esasen bu, benzersiz, kendinize ait bir şey yapabileceğiniz bir platformdur. Bu sayede Linux, yazılım bileşenleri kümesinde farklılık gösteren birçok dağıtıma sahiptir. Ve burada bir sorun ortaya çıkıyor: Bir yazılım ürününün herhangi bir dağıtımda çalışabilmesi için her birinin özelliklerini dikkate almanız gerekir.
Paket yöneticileri. .deb ve .rpm
Ürünü farklı dağıtımlara dağıtmanın bariz sorunuyla başlayalım.
Yazılım ürünlerini dağıtmanın en tipik yolu, paketi bir depoya koymaktır, böylece sistemdeki yerleşik paket yöneticisi onu oradan kurabilir.
Ancak iki popüler paket formatımız var: rpm и deb. Bu herkesin destek vermesi gerektiği anlamına geliyor.
Borç paketleri dünyasında uyumluluk düzeyi inanılmazdır. Aynı paket hem Debian 6 hem de Ubuntu 19.04'te eşit derecede iyi kurulur ve çalışır. Eski Debian dağıtımlarında belirtilen paket oluşturma ve onlarla çalışma sürecine ilişkin standartlar, yeni çıkan Linux Mint ve temel işletim sistemi için geçerli olmaya devam ediyor. Bu nedenle Linux için Veeam Agent durumunda her donanım platformu için bir deb paketi yeterlidir.
Ancak rpm paketleri dünyasında farklar büyüktür. Birincisi, uyumluluğun tamamen gereksiz olduğu, tamamen bağımsız iki distribütör olan Red Hat ve SUSE'nin mevcut olması nedeniyle. İkincisi, bu distribütörlerin dağıtım kitleri var. Destek ve deneysel. Aralarında uyumluluk olmasına da gerek yoktur. El6, el7 ve el8'in kendi paketlerinin olduğu ortaya çıktı. Fedora için ayrı paket. SLES11 ve 12 için paketler ve openSUSE için ayrı bir paket. Asıl sorun bağımlılıklar ve paket adlarıdır.
Bağımlılık sorunu
Ne yazık ki aynı paketler sıklıkla farklı dağıtımlarda farklı isimler altında karşımıza çıkıyor. Aşağıda veeam paketi bağımlılıklarının kısmi bir listesi bulunmaktadır.
EL7 için:
SLES 12 için:
- libblkid
- libgcc
- libstdc ++
- ncurses-lib'ler
- sigorta kütüphaneleri
- dosya kütüphaneleri
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc + + 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Sonuç olarak bağımlılıkların listesi dağıtım için benzersizdir.
Daha da kötüsü güncellenmiş bir sürümün eski paket adı altında saklanmaya başlamasıdır.
Örnek:
Paket Fedora 24'te güncellendi ncurses'in sürüm 5'ten sürüm 6'ya. Ürünümüz, eski dağıtımlarla uyumluluğu sağlamak için sürüm 5 ile oluşturulmuştur. Kütüphanenin eski 5. versiyonunu Fedora 24'te kullanmak için paketi kullanmak zorunda kaldım ncurses-uyumlu-lib'ler.
Sonuç olarak Fedora için farklı bağımlılıklara sahip iki paket var.
Daha da ilginç. Bir sonraki dağıtım güncellemesinden sonra paket ncurses-uyumlu-lib'ler kütüphanenin 5. sürümüyle birlikte kullanılamadığı ortaya çıktı. Bir distribütörün eski kitaplıkları dağıtımın yeni bir sürümüne sürüklemesi pahalıdır. Bir süre sonra sorun SUSE dağıtımlarında da tekrarlandı.
Sonuç olarak, bazı dağıtımlar açık bağımlılıklarını bırakmak zorunda kaldı. ncurses-lib'lerve ürünü, kitaplığın herhangi bir sürümüyle çalışacak şekilde düzeltin.
Bu arada Red Hat'in 8. sürümünde artık meta paket yok pitoneski güzellere gönderme yapan python 2.7. Var python2 и piton3.
Paket yöneticilerine alternatif
Bağımlılıklarla ilgili sorun eskidir ve uzun zamandır ortadadır. Bağımlılık cehennemini hatırla.
Çeşitli kitaplıkları ve uygulamaları, hepsinin istikrarlı bir şekilde çalışacak ve çakışmayacak şekilde birleştirmek - aslında bu, herhangi bir Linux dağıtıcısının çözmeye çalıştığı görevdir.
Paket yöneticisi bu sorunu tamamen farklı bir şekilde çözmeye çalışıyor. Çabuk Canonical'dan. Ana fikir: Uygulama, ana sistemden izole edilmiş ve korunan bir sanal alanda çalışır. Bir uygulama kitaplıklar gerektiriyorsa, bunlar uygulamanın kendisiyle birlikte sağlanır.
Flatpak ayrıca Linux Containers'ı kullanarak uygulamaları sanal alanda çalıştırmanıza da olanak tanır. Korumalı alan fikri de kullanılıyor AppImage.
Bu çözümler, herhangi bir dağıtım için tek bir paket oluşturmanıza olanak tanır. durumunda Flatpak uygulamanın kurulumu ve başlatılması yöneticinin bilgisi olmadan bile mümkündür.
Asıl sorun, tüm uygulamaların sanal alanda çalışamamasıdır. Bazı kişilerin platforma doğrudan erişmesi gerekiyor. Kesinlikle çekirdeğe bağımlı olan ve sandbox konseptine uymayan çekirdek modüllerinden bahsetmiyorum bile.
İkinci sorun ise kurumsal ortamda popüler olan Red Hat ve SUSE dağıtımlarının henüz Snappy ve Flatpak desteği içermemesidir.
Bu bağlamda Linux için Veeam Agent mevcut değildir açık değil .
Paket yöneticileriyle ilgili soruyu sonuçlandırmak için, ikili dosyaları ve bunları tek bir pakete kurmak için bir komut dosyasını birleştirerek paket yöneticilerini tamamen terk etme seçeneğinin olduğunu belirtmek isterim.
Böyle bir paket, farklı dağıtımlar ve platformlar için ortak bir paket oluşturmanıza, etkileşimli bir kurulum işlemi gerçekleştirmenize ve gerekli özelleştirmeyi gerçekleştirmenize olanak tanır. Sadece Linux için VMware'in bu tür paketleriyle karşılaştım.
Güncelleme sorunu
Tüm bağımlılık sorunları çözülse bile program aynı dağıtımda farklı şekilde çalışabilir. Bu bir güncelleme meselesi.
3 güncelleme stratejisi vardır:
- En basiti asla güncelleme yapmamaktır. Sunucuyu kurdum ve unuttum. Her şey çalışıyorsa neden güncelleme yapasınız ki? Desteğe ilk başvurduğunuzda sorunlar başlar. Dağıtımı oluşturan kişi yalnızca güncellenmiş sürümü destekler.
- Distribütöre güvenebilir ve otomatik güncellemeleri ayarlayabilirsiniz. Bu durumda, başarısız bir güncellemenin hemen ardından destek çağrısı yapılması muhtemeldir.
- Yalnızca test altyapısında çalıştırdıktan sonra manuel güncelleme seçeneği en güvenilir olanıdır ancak pahalı ve zaman alıcıdır. Herkes bunu karşılayamaz.
Farklı kullanıcılar farklı güncelleme stratejileri kullandığından hem en son sürümü hem de daha önce yayınlanmış tüm sürümleri desteklemek gerekir. Bu, hem geliştirme hem de test sürecini karmaşıklaştırır ve destek ekibine baş ağrısı ekler.
Çeşitli donanım platformları
Farklı donanım platformları büyük ölçüde yerel koda özgü bir sorundur. En azından desteklenen her platform için ikili dosyalar toplamanız gerekir.
Linux için Veeam Agent projesinde hala bu RISC gibi bir şeyi destekleyemiyoruz.
Bu konu üzerinde ayrıntılı olarak durmayacağım. Sadece ana sorunları özetleyeceğim: platforma bağlı türler, örneğin size_t, yapı hizalaması ve bayt sırası.
Statik ve/veya dinamik bağlantı
Ancak soru şu: "Kütüphanelerle dinamik veya statik olarak nasıl bağlantı kurulur?" tartışmaya değer.
Kural olarak, Linux altındaki C/C++ uygulamaları dinamik bağlantı kullanır. Uygulama özel olarak belirli bir dağıtım için oluşturulmuşsa bu harika çalışır.
Görev, çeşitli dağıtımları tek bir ikili dosyayla kapsamaksa, desteklenen en eski dağıtıma odaklanmanız gerekir. Bizim için bu Red Hat 6'dır. C++4.4 standardının bile desteklemediği gcc 11'ü içerir. .
Projemizi C++6.3'ü tam olarak destekleyen gcc 14 kullanarak oluşturuyoruz. Doğal olarak bu durumda Red Hat 6'da libstdc++ ve boost kütüphanelerini yanınızda taşımanız gerekiyor. En kolay yol bunlara statik olarak bağlanmaktır.
Ancak ne yazık ki tüm kütüphaneler statik olarak bağlanamaz.
İlk olarak, sistem kütüphaneleri gibi libfuse, libblkid çekirdek ve modülleriyle uyumluluğunu sağlamak için dinamik olarak bağlanmak gerekir.
İkincisi, lisanslarda bir incelik var.
GPL lisansı temel olarak kitaplıkları yalnızca açık kaynak koduyla bağlamanıza olanak tanır. MIT ve BSD, statik bağlantıya izin verir ve kütüphanelerin bir projeye dahil edilmesine izin verir. Ancak LGPL, statik bağlantıyla çelişmiyor gibi görünüyor, ancak bağlantı için gerekli dosyaların paylaşılmasını gerektiriyor.
Genel olarak dinamik bağlantı kullanmak herhangi bir şey sağlama zorunluluğunuzu ortadan kaldıracaktır.
C/C++ uygulamaları oluşturma
Farklı platformlar ve dağıtımlar için C/C++ uygulamaları oluşturmak için uygun bir gcc sürümü seçmek veya oluşturmak, belirli mimariler için çapraz derleyiciler kullanmak ve tüm kitaplık setini bir araya getirmek yeterlidir. Bu iş oldukça uygulanabilir, ancak oldukça zahmetlidir. Seçilen derleyicinin ve kitaplıkların uygulanabilir bir sürüm sağlayacağının garantisi yoktur.
Açık bir avantaj: Tüm yapım süreci tek bir makinede tamamlanabildiğinden altyapı büyük ölçüde basitleştirilmiştir. Ek olarak, bir mimari için bir dizi ikili dosyayı toplamak yeterlidir ve bunları farklı dağıtımlar için paketler halinde paketleyebilirsiniz. Linux için Veeam Agent için veeam paketleri bu şekilde oluşturulur.
Bu seçeneğin aksine, basitçe bir inşa çiftliği, yani montaj için birkaç makine hazırlayabilirsiniz. Bu tür makinelerin her biri, belirli bir dağıtım ve belirli bir mimari için uygulama derlemesi ve paket derlemesi sağlayacaktır. Bu durumda derleme distribütörün hazırladığı araçlar kullanılarak gerçekleştirilir. Yani derleyicinin hazırlanması ve kütüphanelerin seçilmesi aşaması ortadan kalkmaktadır. Ayrıca yapım süreci kolaylıkla paralelleştirilebilir.
Ancak bu yaklaşımın bir dezavantajı vardır: Aynı mimari içindeki her dağıtım için kendi ikili dosya kümenizi toplamanız gerekecektir. Diğer bir dezavantaj ise bu kadar çok sayıda makinenin bakıma ihtiyaç duyması ve büyük miktarda disk alanı ve RAM tahsis edilmesinin gerekmesidir.
Red Hat dağıtımları için veeamsnap çekirdek modülünün KMOD paketleri bu şekilde derlenir.
Oluşturma Hizmetini Aç
SUSE'deki meslektaşlarımız, uygulamaları derlemek ve paketleri birleştirmek için özel bir hizmet şeklinde bir orta yol uygulamaya çalıştılar - .
Esasen, bir sanal makine oluşturan, gerekli tüm paketleri içine yükleyen, uygulamayı derleyen ve paketi bu yalıtılmış ortamda oluşturan ve ardından sanal makineyi piyasaya süren bir hipervizördür.
OpenBuildService'te uygulanan zamanlayıcı, optimum paket oluşturma hızı için kaç sanal makinenin başlatılabileceğini belirleyecektir. Yerleşik imzalama mekanizması paketleri imzalayacak ve bunları yerleşik depoya yükleyecektir. Yerleşik sürüm kontrol sistemi, değişikliklerin ve yapıların geçmişini kaydedecektir. Geriye sadece kaynaklarınızı bu sisteme eklemek kalıyor. Sunucuyu kendiniz kurmanıza bile gerek yok; açık olanı kullanabilirsiniz.
Ancak bir sorun var: Böyle bir biçerdöverin mevcut altyapıya sığması zordur. Örneğin sürüm kontrolüne gerek yok; kaynak kodlarımız için zaten kendi kodlarımız var. İmza mekanizmamız farklı: özel bir sunucu kullanıyoruz. Bir depoya da ihtiyaç yoktur.
Ek olarak, diğer dağıtımlara (örneğin Red Hat) yönelik destek oldukça zayıf bir şekilde uygulanıyor ve bu da anlaşılabilir bir durum.
Böyle bir hizmetin avantajı SUSE dağıtımının bir sonraki sürümü için hızlı destektir. Sürümün resmi olarak duyurulmasından önce, montaj için gerekli paketler halka açık bir depoda yayınlanıyor. OpenBuildService'deki mevcut dağıtımlar listesinde yeni bir tane belirir. Kutuyu işaretliyoruz ve inşaat planına ekleniyor. Böylece dağıtımın yeni versiyonunun eklenmesi neredeyse tek tıklamayla yapılıyor.
Altyapımızda, OpenBuildService kullanılarak, SUSE dağıtımları için veeamsnap çekirdek modülünün tüm KMP paketleri bir araya getirilir.
Daha sonra çekirdek modüllerine özgü konulara değinmek istiyorum.
çekirdek ABI'sı
Linux çekirdek modülleri tarihsel olarak kaynak biçiminde dağıtılmıştır. Gerçek şu ki, çekirdeğin yaratıcıları, çekirdek modülleri için ve özellikle ikili düzeyde, ayrıca kABI olarak anılacak olan kararlı bir API'yi destekleme endişesiyle kendilerine yük olmuyorlar.
Vanilya çekirdeğine yönelik bir modül oluşturmak için kesinlikle bu çekirdeğin başlıklarına ihtiyacınız var ve bu yalnızca bu çekirdek üzerinde çalışacak.
DKMS, çekirdeği güncellerken modül oluşturma sürecini otomatikleştirmenize olanak tanır. Sonuç olarak, Debian deposunun kullanıcıları (ve onun birçok akrabası), ya dağıtıcının deposundaki ya da DKMS kullanılarak kaynaktan derlenen çekirdek modüllerini kullanır.
Ancak bu durum özellikle Enterprise segmentine pek yakışmıyor. Tescilli kod dağıtıcıları, ürünü derlenmiş ikili dosyalar olarak dağıtmak ister.
Yöneticiler, güvenlik nedeniyle geliştirme araçlarını üretim sunucularında tutmak istemezler. Red Hat ve SUSE gibi kurumsal Linux distribütörleri, kullanıcıları için kararlı kABI'yi destekleyebileceklerine karar verdi. Sonuçta Red Hat için KMOD paketleri ve SUSE için KMP paketleri ortaya çıktı.
Bu çözümün özü oldukça basittir. Dağıtımın belirli bir sürümü için çekirdek API'si dondurulur. Dağıtıcı, örneğin 3.10 çekirdeğini kullandığını ve yalnızca çekirdek arayüzlerini etkilemeyen düzeltmeler ve iyileştirmeler yaptığını ve ilk çekirdek için toplanan modüllerin, sonraki tüm çekirdekler için yeniden derlemeye gerek kalmadan kullanılabileceğini belirtiyor.
Red Hat, dağıtımın tüm yaşam döngüsü boyunca kABI uyumluluğunu iddia ediyor. Yani, rhel 6.0 (Kasım 2010 sürümü) için birleştirilmiş modülün 6.10 sürümü (Haziran 2018 sürümü) üzerinde de çalışması gerekir. Ve bu neredeyse 8 yıl. Doğal olarak bu görev oldukça zordur.
kABI uyumluluk sorunları nedeniyle veeamsnap modülünün çalışmayı durdurduğu birkaç durum kaydettik.
RHEL 7.0 için derlenen veeamsnap modülünün RHEL 7.5 çekirdeğiyle uyumlu olmadığı ortaya çıktıktan, ancak yüklendiğinden ve sunucuyu çökertmesi garantilendiğinden, RHEL 7 için kABI uyumluluğunun kullanımını tamamen bıraktık.
Şu anda RHEL 7 için KMOD paketi, her yayın sürümü için bir derleme ve modülü yükleyen bir komut dosyası içerir.
SUSE, KABI uyumluluğu görevine daha dikkatli yaklaştı. KABI uyumluluğunu yalnızca tek bir hizmet paketinde sağlarlar.
Örneğin, SLES 12'nin piyasaya sürülmesi Eylül 2014'te gerçekleşti. Ve SLES 12 SP1 zaten Aralık 2015'teydi, yani bir yıldan biraz fazla zaman geçti. Her iki sürüm de 3.12 çekirdeği kullansa da kABI uyumlu değildir. Açıkçası, kABI uyumluluğunu yalnızca bir yıl sürdürmek çok daha kolay. Yıllık çekirdek modülü güncelleme döngüsü, modül yaratıcıları için sorun yaratmamalıdır.
Bu SUSE politikasının bir sonucu olarak veeamsnap modülümüzde kABI uyumluluğuyla ilgili tek bir sorun bile kaydetmedik. Doğru, SUSE paketlerinin sayısı neredeyse bir kat daha fazla.
Yamalar ve destek dosyaları
Distribütörler, kABI uyumluluğunu ve çekirdek kararlılığını sağlamaya çalışsalar da, aynı zamanda bu kararlı çekirdeğin performansını artırmaya ve kusurlarını ortadan kaldırmaya da çalışırlar.
Aynı zamanda, kurumsal Linux çekirdeğinin geliştiricileri, kendi "hatalar üzerinde çalışmalarına" ek olarak, vanilya çekirdeğindeki değişiklikleri izler ve bunları "kararlı" çekirdeklerine aktarır.
Bazen bu yenilerine yol açar .
Red Hat 6'nın son sürümünde küçük güncellemelerden birinde hata yapıldı. Bu, anlık görüntü yayınlandığında veeamsnap modülünün sistemi çökertmesinin garantili olmasına yol açtı. Güncelleme öncesi ve sonrası çekirdek kaynaklarını karşılaştırdığımızda sorunun arka bağlantıda olduğunu gördük. Vanilya çekirdeğinin 4.19 sürümünde de benzer bir düzeltme yapıldı. Sadece bu düzeltme vanilya çekirdeğinde iyi çalıştı, ancak onu "kararlı" 2.6.32'ye aktarırken spinlockta bir sorun ortaya çıktı.
Elbette herkesin her zaman hataları vardır, ancak istikrarı riske atarak kodu 4.19'dan 2.6.32'ye sürüklemeye değer miydi?.. Emin değilim...
En kötüsü pazarlamanın “istikrar” ile “modernleşme” arasındaki çekişmeye dahil olmasıdır. Pazarlama departmanının güncellenmiş dağıtımın çekirdeğinin bir yandan istikrarlı olmasına, aynı zamanda performans açısından daha iyi olmasına ve yeni özelliklere sahip olmasına ihtiyacı var. Bu garip uzlaşmalara yol açar.
SLES 4.4 SP12'ün 3 çekirdeği üzerinde bir modül oluşturmaya çalıştığımda, içinde Vanilya 4.8'in işlevselliğini bulduğumda şaşırdım. Bana göre, SLES 4.4 SP12'ün 3 çekirdeğinin blok I/O uygulaması, SLES4.8 SP4.4'nin kararlı 12 çekirdeğinin önceki sürümüne kıyasla 2 çekirdeğe daha çok benziyor. SP4.8 için çekirdek 4.4'den SLES 3'e kodun yüzde kaçının aktarıldığını yargılayamıyorum, ancak çekirdeğe aynı kararlı 4.4 bile diyemiyorum.
Bunun en tatsız yanı, farklı çekirdeklerde eşit derecede iyi çalışacak bir modül yazarken artık çekirdek sürümüne güvenememenizdir. Dağıtımı da hesaba katmalısınız. Bazen yeni işlevlerle birlikte ortaya çıkan bir tanıma dahil olmanız iyi bir şey, ancak bu fırsat her zaman ortaya çıkmıyor.
Sonuç olarak kod, tuhaf koşullu derleme yönergeleriyle büyümüş hale gelir.
Belgelenen çekirdek API'sini değiştiren yamalar da vardır.
Dağıtımla karşılaştım 5.16 ve bu çekirdek sürümündeki Lookup_bdev çağrısının giriş parametreleri listesini değiştirdiğini görmek beni çok şaşırttı.
Bunu bir araya getirmek için makefile dosyasına, Lookup_bdev işlevinin bir maske parametresi olup olmadığını kontrol eden bir komut dosyası eklemem gerekiyordu.
Çekirdek modüllerini imzalama
Ancak paket dağıtımı konusuna dönelim.
Kararlı kABI'nin avantajlarından biri, çekirdek modüllerinin ikili dosya olarak imzalanabilmesidir. Bu durumda geliştirici, modülün kazara hasar görmediğinden veya kasıtlı olarak değiştirilmediğinden emin olabilir. Bunu modinfo komutuyla kontrol edebilirsiniz.
Red Hat ve SUSE dağıtımları, modülün imzasını kontrol etmenize ve yalnızca ilgili sertifikanın sistemde kayıtlı olması durumunda yüklemenize olanak tanır. Sertifika, modülün imzalandığı ortak anahtardır. Ayrı bir paket olarak dağıtıyoruz.
Buradaki sorun, sertifikaların ya çekirdeğe yerleştirilebilmesi (dağıtımcılar bunları kullanır) ya da bir yardımcı program kullanılarak EFI kalıcı belleğine yazılmasının gerekmesidir. mokutil. Yarar mokutil Bir sertifika yüklerken sistemi yeniden başlatmanızı gerektirir ve hatta işletim sistemi çekirdeğini yüklemeden önce yöneticiden yeni bir sertifikanın yüklenmesine izin vermesi istenir.
Bu nedenle, sertifika eklemek sisteme fiziksel yönetici erişimi gerektirir. Makine bulutta bir yerde veya uzak bir sunucu odasında bulunuyorsa ve erişim yalnızca ağ üzerinden (örneğin ssh aracılığıyla) sağlanıyorsa, sertifika eklemek mümkün olmayacaktır.
Sanal makinelerde EFI
EFI'nin neredeyse tüm anakart üreticileri tarafından uzun süredir desteklenmesine rağmen, bir sistem kurarken yönetici EFI ihtiyacını düşünmeyebilir ve devre dışı bırakılabilir.
Tüm hipervizörler EFI'yi desteklemez. VMWare vSphere, sürüm 5'ten itibaren EFI'yi destekler.
Microsoft Hyper-V ayrıca Windows Server 2012R2 için Hyper-V'den başlayarak EFI desteğini de kazandı.
Ancak varsayılan yapılandırmada bu işlevsellik Linux makineleri için devre dışıdır, bu da sertifikanın yüklenemeyeceği anlamına gelir.
vSphere 6.5'te seçeneği ayarlayın Güvenli Başlatma yalnızca web arayüzünün Flash üzerinden çalışan eski sürümünde mümkündür. HTML-5'teki Web kullanıcı arayüzü hala çok geride.
Deneysel dağılımlar
Ve son olarak deneysel dağıtımlar ve resmi destek olmadan yapılan dağıtımlar konusunu ele alalım. Bir yandan bu tür dağıtımların ciddi kuruluşların sunucularında bulunması pek mümkün değildir. Bu tür dağıtımlar için resmi bir destek yoktur. Bu nedenle bunları sağlayın. Ürün böyle bir dağıtımda desteklenemez.
Ancak bu tür dağıtımlar yeni deneysel çözümlerin denenmesi için uygun bir platform haline geliyor. Örneğin, Fedora, OpenSUSE Tumbleweed veya Debian'ın Kararsız sürümleri. Oldukça kararlılar. Her zaman programların yeni sürümleri ve her zaman yeni bir çekirdekleri vardır. Bir yıl içinde bu deneysel işlevsellik güncellenmiş bir RHEL, SLES veya Ubuntu ile sonuçlanabilir.
Yani eğer deneysel bir dağılımda bir şey işe yaramıyorsa, bu, sorunu bulup çözmek için bir nedendir. Bu işlevselliğin yakında kullanıcıların üretim sunucularında görüneceği gerçeğine hazırlıklı olmanız gerekir.
Sürüm 3.0 için resmi olarak desteklenen dağıtımların güncel listesini inceleyebilirsiniz. . Ancak ürünümüzün üzerinde çalışabileceği gerçek dağıtım listesi çok daha geniştir.
Şahsen ben Elbrus OS ile yapılan deneyle ilgileniyordum. Veeam paketini sonlandırdıktan sonra ürünümüz kuruldu ve çalışıyor. Bu deney hakkında Habré'de yazmıştım. .
Yeni dağıtımlara destek devam ediyor. 4.0 versiyonunun çıkmasını bekliyoruz. Beta ortaya çıkmak üzere, bu yüzden dikkat edin !
Kaynak: habr.com