systemd 259: Temel Değişiklikler ve Sistem Gereksinimleri

Informatec Digital » Kaynaklar » systemd 259: Temel Değişiklikler ve Sistem Gereksinimleri

Systemd 259'un kararlı sürüm olarak yayınlanması, Linux ekosisteminin en tartışmalı ve temel bileşenlerinden birinde yeni bir dönüm noktası temsil ediyor. Çoğu dağıtımda zaten baskın olan hizmetleri başlatma ve yönetme çerçevesinden bahsediyoruz ve bu sürüm, teknik gereksinimler, güvenlik ve eski teknolojilerin terk edilmesi açısından çıtayı daha da yükseltiyor.

Bu güncelleme, aylarca süren yoğun çalışmanın ardından geldi ve üç ana alana odaklanıyor : yeni C kütüphaneleriyle uyumluluk, gelişmiş güvenlik ve eski kodların (SysV komut dosyaları, TPM 1.2, iptables vb.) temizlenmesi. Ayrıca, run0 ile ayrıcalık yönetimi, systemd-oomd ile bellek yönetimi, günlük depolama ve libsystemd'nin dahili bağımlılık modelinde önemli değişiklikler getiriyor.

systemd 259 ve musl için deneysel destek

Bu sürümün en çok konuşulan özelliklerinden biri, systemd 259'un ilk kez C standart kütüphanesi musl için kısmi destek içermesidir . Bu kütüphane, glibc'ye kıyasla basitlik ve daha düşük kaynak tüketiminin istendiği hafif sistemlerde, minimalist konteynerlerde ve gömülü ortamlarda yaygın olarak kullanılmaktadır.

Meson derleme sisteminin "libc" seçeneğini "musl" olarak ayarlayarak musl desteği etkinleştirilir . Ancak bu entegrasyon henüz tamamlanmamıştır: musl, Name Service Switch (NSS) mekanizmasını uygulamadığı için, bu kütüphaneye karşı derleme yapılırken systemd'nin çeşitli bölümlerinin devre dışı bırakılması zorunlu hale gelir.

Özellikle, musl ile systemd 259'u derlemek, nss-systemd, nss-resolve, systemd-homed, systemd-userdbd ve systemd-nsresourced gibi temel bileşenleri dışlar . DynamicUser seçeneği ve ayrıcalık olmadan systemd-nspawn çalıştırma yeteneği de kullanılamaz; bu durum, bu özelliklere büyük ölçüde bağımlı olan konteyner ortamlarında özellikle önemlidir.

Geliştiriciler, uzun vadeli desteği garanti edemeyeceklerini kendileri de kabul ediyorlar . Desteğin devamı, topluluğun gerçek ilgisine, musl'un eksik olduğu işlevleri sağlayan ek katmanların olgunluğuna ve bu kütüphaneye özgü hata raporlarına bağlı olacaktır. Talep düşükse veya bakım çok karmaşık hale gelirse, bu desteğin gelecekteki sürümlerde gözden geçirilmesi şaşırtıcı olmaz.

Ancak, musl'a bu açılım sembolik bir düzeyde önemlidir: systemd, yıllarca neredeyse tamamen glibc'ye bağımlı olması nedeniyle eleştirilmişti ; bu durum onu ​​alternatif dağıtımlar ve çok minimalist senaryolar için elverişsiz hale getiriyordu. Bu adım her şeyi çözmüyor, ancak diğer C kütüphanelerine tamamen kapalı bir sistem imajını kırıyor.

run0 ve yeni ayrıcalık modeli: sudo'ya bir alternatif

systemd 259'un bir diğer önemli özelliği de yardımcı programıdır. sudo'nun modern ve daha güvenli bir alternatifi olarak önerilen run0Bu araç zaten systemd-run üzerine inşa edilmişti, ancak şimdi önemli bir özellik kazanıyor: seçenek --empower.

Yeni `--empower` argümanı, UID'nizi root olarak değiştirmeden yükseltilmiş ayrıcalıklarla bir oturum başlatmanıza olanak tanır . Geleneksel bir kullanıcı değiştirme yerine, `run0`, ayrıcalıklı eylemleri gerçekleştirmek için gereken izinleri tam olarak vermek üzere çekirdek yeteneklerinden (örneğin `CAP_SYS_ADMIN`) yararlanır ve tamamen root olma riskini azaltır.

Dahası, bu yaklaşımla başlatılan süreçler , Polkit tarafından yönetilen geniş bir eylem kümesine erişime sahip mantıksal bir "yetkilendirme" grubunda gruplandırılır . Buradaki fikir, ayrıcalıklardaki artışın ayrıntılı ve kontrollü olması, erişimin genellikle çok geniş açıldığı geleneksel sudo'ya kıyasla daha sıkı bir ayrım sağlamasıdır.

Bu yaklaşım , mümkün olduğunca root kullanıcısının doğrudan kullanımından kaçınma eğilimiyle uyumludur ve bu da oldukça değerli bir güvenlik ilkesidir. Bununla birlikte, run0'ın gerçek etkinliğinin üretim ortamında gösterilmesi gerekmektedir: Her dağıtımın politikalarıyla nasıl entegre olduğunu, yeteneklerinin pratikte nasıl yapılandırıldığını ve sistem yönetiminin yeni iş akışına ne kadar iyi uyum sağladığını görmemiz gerekecek.

SysV başlatma ve eski dosyaların temizlenmesine yönelik destek sona erdi.

systemd 259, System V tarzı servis komut dosyaları için de kesin sonun başlangıcını işaret ediyor . Bu klasik mekanizmalarla uyumluluk yıllardır "sona ermek üzere" olarak nitelendiriliyordu ve şimdi bunların kaldırılması için net bir zaman çizelgesi belirlendi.

Bu sürüm, bir sonraki büyük sürüme yönelik beklentileri karşılıyor. systemd-sysv-generator, systemd-rc-local-generator ve systemd-sysv-install gibi geçmişe ait bileşenler kaldırılacaktır.Yani, senaryolar /etc/init.d/ Artık systemd tarafından dikkate alınmayacaklar; bu da yaklaşık on yıldır süren bir geçiş sürecini sonlandırıyor.

SysV komut dosyalarına dayalı özel servisleri hala sürdüren yöneticiler için bu, işe koyulmak anlamına gelir: tüm bu komut dosyalarının envanterinin çıkarılması ve yerel systemd birimlerine (.service, .socket, vb.) taşınması gerekir. Büyük dağıtımlar bu geçişin neredeyse tamamını zaten tamamladı, ancak özel ortamlarda veya eski kurulumlarda, bazı "kalıntılar" hala arka planda çalışıyor olabilir.

Bu eski sistem temizleme süreci yalnızca SysV ile sınırlı değil. Systemd'nin son sürümleri, `/forcefsck` ve `/fastboot` gibi klasik yöntemlere olan desteği kaldırarak bunların yerine çekirdek parametrelerini ve daha modern kimlik doğrulama mekanizmalarını getiriyor. 259. sürümde de aynı yönelim söz konusu: daha sürdürülebilir ve tutarlı bir kod tabanı karşılığında daha az geriye dönük uyumluluk.

Minimum systemd gereksinimleri 259: çekirdek, kütüphaneler ve ortam

Eski sistemleri en çok etkileyebilecek değişikliklerden biri, systemd 259'u çalıştırmak için gereken minimum yazılım gereksinimlerindeki artıştır. Bu sürüm artık çok eski donanım veya yığınları önemsemiyor ve açıkça modern platformlara yöneliyor.

systemd 259'da bir araya getirilen temel gereksinimler arasında modern platformlara bağlılık yer almaktadır.

• Linux çekirdeği 5.10 minimum (en az 5.14'e kadar çıkılması tavsiye edilir).
• glibc2.34 GNU standart kütüphanesinin minimal bir sürümü olarak.
• SSL 3.0.0'ı açın Desteklenen şifreleme işlevleri için zorunlu bir temel olarak.
• util-linux 2.37 Sistemin temel işlevleri için bir gereklilik olarak.
• libxcrypt 4.4.0 Parolalarla ilgili kriptografik işlevlerin yönetimi için.
• cryptsetup 2.4.0 ve libseccomp 2.4.0 Ses seviyesi şifreleme ve sistem çağrısı filtreleme için.
• Python 3.9.0 Yardımcı araçlar için minimum bağımlılık olarak.
• Bazı notlarda ayrıca şunlardan da bahsediliyor: elfutils 0.177 Güncellenmiş bağımlılıklar kümesinin bir parçası olarak.

Bu sıkılaştırma, 5.10 öncesi çekirdek dallarına bağlı kalan çok eski sistemlerin veya dağıtımların , temel teknolojilerini güncellemedikleri sürece bu sürüm için destekten otomatik olarak dışlanacağı anlamına gelir . Buna karşılık, daha az özel durum ve uzlaşma çözümüyle daha homojen bir ekosistem elde edilir.

Çoğu genel amaçlı masaüstü ve sunucu dağıtımı için bu gereksinimler sorun teşkil etmemelidir: modern LTS çekirdek dalları zaten 5.10 bariyerini çoktan aşmıştır ve bahsedilen kütüphaneler yaygın olarak mevcuttur. En büyük sorunlar gömülü sistemlerde, cihazlarda veya sık sık güncellenmeyen çok muhafazakar kurulumlarda ortaya çıkabilir.

Gelişmiş güvenlik: TPM 2.0, şifreleme ve cihaz kısıtlamaları.

Güvenlik alanında, systemd 259 birkaç önemli kararla ilerlemesini hızlandırıyor. En belirgin olanı, systemd-boot ve systemd-stub'ın TPM 1.2 desteğini kesin olarak bırakması ve bundan böyle yalnızca TPM 2.0'ın referans standart olarak kabul edilmesidir.

Bu değişiklik , güvenli önyükleme politikalarını veya şifreleme anahtarlarını yönetmek için TPM 1.2'ye güvenen sistemlerin, systemd-boot'un daha yeni sürümleriyle bu özellikleri kullanmaya devam etmek istiyorlarsa donanımlarını yükseltmeleri (örneğin, anakartı değiştirerek) gerekeceği anlamına gelir. Birçok Linux masaüstü kullanıcısı TPM ve Güvenli Önyüklemeyi devre dışı bıraktığı için değişikliği fark etmeyebilirler, ancak kurumsal veya yüksek güvenlikli ortamlarda etkisi olabilir.

systemd 258 gibi önceki sürümlerde bu alanda önemli düzenlemeler yapılmıştı: OpenSSL, systemd-resolved ve systemd-importd tarafından desteklenen tek şifreleme kütüphanesi haline gelmiş , GnuTLS ve libgcrypt gibi alternatifler dışarıda bırakılmıştı. Tüm bunlar, daha küçük ve daha kontrollü bir kriptografik araç seti etrafında bir konsolidasyona işaret ediyor.

Ayrıca 258 numaralı dalda, tty/pts için daha sıkı varsayılan erişim kısıtlamaları getirildi : düğümler 0620 yerine 0600 izinleriyle oluşturuluyor ve bu da diğer kullanıcıların terminallerimize yazmasını engelliyor. Bu, systemd'nin bir süredir düşük seviyeli ayrıntıları nasıl ince ayar yaptığının ve bunların bir araya geldiğinde sistemin genel güvenliğini nasıl güçlendirdiğinin bir başka örneğidir.

libsystemd daha modüler ve dinamik olarak yüklenir.

Daha yüksek verimlilik ve azaltılmış bağımlılık yükü hedefiyle, systemd 259, libsystemd'nin diğer sistem kütüphaneleriyle etkileşim biçiminde önemli değişiklikler getiriyor . Amaç, her şeyin baştan taşınmasını önlemek ve yalnızca ihtiyaç duyulduğunda yüklemektir.

Özellikle, libsystemd artık libacl, libblkid, libseccomp, libselinux ve libmount gibi kütüphaneleri dinamik olarak yüklemek için dlopen() işlevini kullanıyor . Bu, bu bağımlılıkların derleme zamanında katı bir şekilde bağlanmadığı veya her zaman belleğe yüklenmediği anlamına gelir: yalnızca belirli bir işlev onları gerektirdiğinde etkinleştirilirler.

`dlopen()` ile aynı mekanizma, Linux denetim alt sistemi ve PAM ile entegrasyon için de geçerlidir . Bu sayede, tüm bu bileşenlere aynı anda ihtiyaç duyulmayan ortamlarda systemd'nin başlatılması ve normal çalışması daha hafif olabilir.

Öte yandan, daha önce libcap kütüphanesi tarafından sağlanan işlevsellik doğrudan libsystemd'ye entegre edildi . Bu, başka bir harici bağımlılığı ortadan kaldırarak derleme zincirini basitleştiriyor ve olası hata veya uyumsuzluk noktalarını azaltıyor.

Genel olarak, bu yaklaşım, özellikle hızlı önyükleme sürelerinin ve sıkıca paketlenmiş bir hizmet kümesinin istendiği sistemlerde daha iyi modülerlik ve daha küçük bellek ve disk alanı kullanımı sağlar.

Ağ ve konteyner değişiklikleri: iptables'a elveda, nftables'a merhaba.

Ağ ve sanallaştırma alanı da önemli değişikliklere uğruyor. systemd 259'dan itibaren systemd-networkd ve systemd-nspawn, iptables/libiptc kullanarak NAT kuralları oluşturmayı artık desteklemiyor . Desteklenen tek güvenlik duvarı arka ucu nftables oluyor.

Bu durum, iptables üzerinden NAT kullanan systemd-nspawn ile yönetilen konteynerleri ve klasik arka uç ile adres çevrimi kuralları kullanan systemd-networkd'de tanımlanan ağları doğrudan etkiler . Yayın adaylarıyla yapılan testlerde, tüm yapılandırma nftables'a taşınana kadar NAT işlevinde sessiz hatalar gözlemlendi.

Adreslerin tercümesinin ötesinde, systemd-resolved, yerel kancaları kullanma yeteneği kazanıyor. en /run/systemd/resolve.hook/Bu komutlar, yerel ad çözümleme sorgusu her yapıldığında yürütülür. Bu, yöneticinin gelişmiş DNS özelleştirmelerine ve özel mantığa erişimini sağlar.

Görüntü içe aktarma ve yönetimi alanında, systemd-importd, TAR dosyalarıyla çalışmak için yerleşik bir mantık içerir.GNU tar yardımcı programından libarchive'a güvenilerek. Ayrıca, hem systemd-importd hem de systemd-machined artık kullanıcı modunda çalıştırılabiliyor ve yerleştirilen sistem imajlarını yönetebiliyor. ~/.local/state/machines/.

Bu modları kontrol etmek için, importctl yardımcı programı "--user" ve "--system" seçeneklerini ekleyerek , kullanıcı bağlamında mı yoksa sistem düzeyinde mi çalışacağınızı kolayca seçmenize olanak tanır. Bu yaklaşım, makinenin genel yapılandırmasını değiştirmek istemediğiniz geliştirme ve test ortamları için kullanışlıdır.

Varsayılan olarak kalıcı günlük kaydı ve disk alanı yönetimi

Pratik etkileri olan bir diğer değişiklik ise şu hususun değiştirilmesidir: varsayılan günlük depolama modusystemd'nin günlük kaydı alt sistemi olan `std`. Şimdiye kadar, "otomatik" davranış, `std` dizininin varlığına veya yokluğuna bağlıydı. /var/log/journal.

systemd 259 ile birlikte, klasörün daha önce var olup olmamasına bakılmaksızın varsayılan mod "kalıcı " olur. Bu, günlük dosyasının geçici RAM'de depolanmak yerine varsayılan olarak diske kalıcı olarak kaydedileceği anlamına gelir.

Bu kararın artıları ve eksileri var. Bir yandan, sorun gidermeyi büyük ölçüde kolaylaştırıyor , çünkü günlükler yöneticinin özel bir işlem yapmasına gerek kalmadan yeniden başlatmalardan sonra da korunuyor. Öte yandan, gömülü sistemlerde, hafif konteynerlerde veya çok sınırlı depolama alanına sahip ortamlarda, disk kullanımında önemli bir artışa neden olabilir.

Bu senaryolarda, aşırı aşınmayı önlemek istiyorsanız (örneğin, sınırlı yazma döngüsüne sahip flash belleklerde), günlük döndürme ve boyut politikalarını ayarlamak veya hatta farklı bir depolama modunu zorlamak her zamankinden daha önemli olacaktır .

systemd-oomd, bellek yetersizliği izleme ve kaynak kontrolü

Bellek yönetimi ve "Bellek Yetersizliği" senaryoları da önemli ölçüde iyileştirildi. Yetersiz bellek durumlarına yanıt vermekten sorumlu olan systemd-oomd bileşeni, daha fazla görünürlük sağlamak için yeni özellikler içeriyor.

Özellikle, yetersiz bellek nedeniyle çekirdek veya systemd-oomd tarafından sonlandırılan işlem sayısını kaydeden OOMKills ve ManagedOOMKills özellikleri artık hizmetler için kullanılabilir durumdadır . Bu bilgilere systemd araçları kullanılarak doğrudan erişilebilir ve bu da sonraki olay analizini kolaylaştırır.

Bir işlem kontrolden çıktığında ve sistemi tehlikeye atacak kadar RAM tüketmeye başladığında , bu ölçümler hangi birimlerin etkilendiğini, OOM mekanizmasının kaç kez tetiklendiğini ve hangi bileşenlerin en fazla bellek baskısına neden olduğunu bir bakışta görmenizi sağlar.

Yüksek yük altındaki ortamların veya kaynakları çok kısıtlı sistemlerin yöneticileri için, bellek yetersizliği (OOM) durumunu gözlemleme yeteneği özellikle faydalıdır; çünkü daha önce fark edilmeyebilecek yetersiz boyutlandırılmış hizmetleri veya bellek sızıntılarını belirlemeye yardımcı olur.

systemd 259'daki diğer önemli iyileştirmeler

Yukarıda bahsedilen büyük değişikliklere ek olarak, systemd 259, ekosistem genelinde dağılmış çok sayıda iyileştirme ve küçük düzenlemeyle birlikte geliyor . Birçoğu oldukça teknik olsa da, birlikte önemli bir değişikliğe yol açtıkları için gözden geçirmeye değer.

API'nin yeni özelliklerinden bazıları şunlardır: Varlink protokolüne dayalı arayüz genişletiliyor. Hizmet yapılandırmasına erişime izin vermek ve IPC çağrılarını yürütmek gibi işlemler için: Reload() y Reexecute()Ayrıca systemd-repart, systemd-resolved ve systemd-networkd işlevlerini ele almak için özel çağrılar da eklenmiştir.

Yapılandırma ve birimler alanında, bir hizmetin yapılandırması yeniden yüklendikten hemen sonra komutların çalıştırılmasına olanak tanıyan ExecReloadPost seçeneği tanıtıldı . Ayrıca, ".ignore" ile biten yapılandırma dosyaları artık otomatik olarak atılıyor ; bu, dosyaları silmeye veya önemli ölçüde yeniden adlandırmaya gerek kalmadan devre dışı bırakmanın basit bir yoludur.

Geçici birimler mülkiyet kazanır. KökDizinDosyaTanımlayıcısıBu, kök dizine karşılık gelen dosya tanımlayıcısını tanımlar ve yeni bir seçenek eklenir. KullanıcıAdAlanYoluBu özellik, bir sürücüyü bir kullanıcı ad alanına, bir yol belirterek bağlamanıza olanak tanır. /procsystemd-nspawn'da bu yönerge görünür. Bölümdeki NamespacePath Kullanılacak ağ ad alanını belirtmek için .nspawn dosyalarından yararlanılır.

Diğer bileşenler gibi systemd-sysext ve systemd-confext, özel yapılandırma dosyaları içerir. en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confÇevresel değişkenler SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS Kaplamalar için montaj seçeneklerini ayarlamanıza olanak tanırlar.

Udev dünyasında bu seçenek eklendi. OPTIONS=»dump-json» to systemd-udevd Bir olayın mevcut durumunu JSON formatında görüntülemek için şu fonksiyon kullanılır: net_id DeviceTree bulunan sistemlerde kablosuz arayüzler için tahmin edilebilir adlar oluşturur ve sembolik bağlantılar kurar. /dev/gpio/by-id/... GPIO aygıtları için.

Kullanıcı ve hesap bölümü de güçlendiriliyor: Kullanıcı veritabanı bir UUID alanı içerir.userdbctl yardımcı programı, bu tanımlayıcıya göre arama yapmak için "-uuid" seçeneğini destekler ve homectl update Artık mevcut hesaplara kurtarma anahtarları eklemek için "--recovery-key" seçeneği desteklenmektedir.

systemd-homed'de, "--prompt-shell" ve "--prompt-groups" seçenekleri, systemd-homed-firstboot.service kullanılarak ilk önyükleme sırasında dahil edilir ve systemd-firstboot'ta, ilk önyüklemede yerel konsol kullanılırken klavye haritasını sormak için "--prompt-keymap-auto" seçeneği görünür.

El systemd-boot önyükleme yöneticisi, günlük kaydının ayrıntı düzeyini tanımlama özelliğini ekler. parametre ile log-level en loader.conf veya SMBIOS alanı ile io.systemd.boot.loglevelEk olarak, XBOOTLDR gibi bölümler için daha katı gereksinimler birleştiriliyor; bu bölümlerin artık VFAT formatında olması gerekiyor, bu da modern UEFI sistemlerinde ESP için zaten gerekli olan şartlarla uyumlu.

Gelişmiş ağ seviyesinde, systemd-networkd, DHCP sunucusu için EmitDomain ve Domain seçeneklerini ekler ve DNS çözümlemesi kullanarak DHCP aracılığıyla verilen ana bilgisayar adlarını belirleyen bir denetleyici uygular. Bu arada, systemd-modules-load, çekirdek modüllerini paralel olarak yükleyerek , birçok sürücüye sahip sistemlerde önyükleme sürelerini kısaltır.

Son olarak, bütünlük bölümünde, systemd-integrity-setup, HMAC-SHA256, PHMAC-SHA256 ve PHMAC-SHA512 algoritmalarına destek ekleyerek sistem bütünlüğünü korumak için kullanılabilen kriptografik seçeneklerin yelpazesini genişletiyor.

Tüm bu değişikliklerle systemd 259, son derece teknik, zorlu ve açıkça geleceğe yönelik bir sürüm olarak konumunu sağlamlaştırıyor . Kullanıcıları SysV init, iptables ve TPM 1.2 gibi eski teknolojileri terk etmeye zorluyor, güvenliği ve kaynak kontrolünü güçlendiriyor, dahili modülerliği geliştiriyor ve kısmen ve koşullu olarak da olsa musl ile yeni yapılandırmalara kapı açıyor. Noktasal sürüm dağıtımlarını kullanan son kullanıcılar için bu yeni özelliklerin çoğu neredeyse fark edilmeyecek; ancak sürekli olarak en son sürümü kullanan yöneticiler ve projeler için, geçiş yapmadan önce komut dosyalarını, birimleri ve donanım gereksinimlerini dikkatlice gözden geçirme zamanı geldi.