- systemd 259 memperkenalkan dukungan parsial untuk musl, modularitas yang lebih besar di libsystemd, dan model hak akses yang diberlakukan dengan run0 --empower.
- Standar persyaratan ditingkatkan: kernel Linux 5.10, glibc 2.34, OpenSSL 3.0.0, dan pustaka modern lainnya menjadi persyaratan minimum yang wajib dipenuhi.
- Penghentian penggunaan sistem lama semakin cepat: selamat tinggal skrip SysV, berakhirnya dukungan TPM 1.2, pengabaian iptables, dan adopsi penuh nftables.
- Mereka meningkatkan kemampuan pengamatan dan keamanan dengan jurnal persisten secara default, metrik OOMKills baru, dan berbagai penyesuaian di seluruh jaringan, kontainer, dan homed.
Rilis systemd 259 sebagai versi stabil menghadirkan perubahan lain dalam salah satu komponen paling kontroversial dan penting dari ekosistem Linux. Kita berbicara tentang kerangka kerja untuk memulai dan mengelola layanan yang sudah mendominasi sebagian besar distribusi, dan rilis ini semakin memperketat persyaratan teknis, keamanan, dan pengabaian teknologi lama.
Pembaruan ini hadir setelah beberapa bulan kerja intensif dan berfokus pada tiga area utama: kompatibilitas dengan pustaka C baru, peningkatan keamanan, dan pembersihan kode lama (skrip SysV, TPM 1.2, iptables, dll.). Pembaruan ini juga memperkenalkan perubahan signifikan pada manajemen hak akses dengan run0, penanganan memori dengan systemd-oomd, penyimpanan log, dan model ketergantungan internal libsystemd.
systemd 259 dan dukungan eksperimental untuk musl
Salah satu fitur yang paling banyak dibicarakan dalam versi ini adalah bahwa systemd 259 untuk pertama kalinya menyertakan dukungan parsial untuk pustaka standar C musl . Pustaka ini banyak digunakan dalam sistem ringan, kontainer minimalis, dan lingkungan tertanam, di mana kesederhanaan dan pengurangan konsumsi sumber daya dibandingkan dengan glibc sangat diinginkan.
Dukungan untuk musl diaktifkan dengan mengatur opsi "libc" pada sistem build Meson menjadi "musl" . Namun, integrasi ini masih jauh dari lengkap: musl tidak mengimplementasikan mekanisme Name Service Switch (NSS), yang memaksa penonaktifan beberapa bagian systemd saat mengkompilasi terhadap pustaka ini.
Secara spesifik, membangun systemd 259 dengan musl mengecualikan komponen-komponen kunci seperti nss-systemd, nss-resolve, systemd-homed, systemd-userdbd, dan systemd-nsresourced . Opsi DynamicUser dan kemampuan untuk menjalankan systemd-nspawn tanpa hak istimewa juga tidak tersedia, yang sangat relevan di lingkungan kontainer yang sangat bergantung pada kemampuan ini.
Para pengembang sendiri mengakui bahwa mereka tidak dapat menjamin dukungan jangka panjang . Keberlanjutannya akan bergantung pada minat aktual komunitas, kematangan lapisan tambahan yang menyediakan fungsi yang kurang dimiliki musl, dan laporan bug khusus untuk pustaka ini. Jika permintaan rendah atau pemeliharaan terbukti terlalu kompleks, tidak akan mengejutkan jika dukungan ini ditinjau ulang dalam versi mendatang.
Namun, pembukaan akses ke musl ini penting pada tingkat simbolis: systemd telah dikritik selama bertahun-tahun karena ketergantungannya yang hampir eksklusif pada glibc , yang membuatnya tidak ramah terhadap distribusi alternatif dan skenario yang sangat minimalis. Langkah ini tidak menyelesaikan semuanya, tetapi mematahkan citra sistem yang sepenuhnya tertutup terhadap pustaka C lainnya.
run0 dan model hak akses baru: alternatif untuk sudo
Fitur utama lain dari systemd 259 adalah utilitasnya. run0, diusulkan sebagai pengganti sudo yang modern dan lebih aman.Alat ini sudah dibangun di atas systemd-run, tetapi sekarang ia memperoleh kemampuan kunci: opsi --empower.
Argumen `--empower` yang baru memungkinkan Anda memulai sesi dengan hak akses yang lebih tinggi tanpa mengubah UID Anda menjadi root . Alih-alih pergantian pengguna tradisional, `run0` memanfaatkan kemampuan kernel (seperti `CAP_SYS_ADMIN`) untuk memberikan izin yang tepat yang dibutuhkan untuk melakukan tindakan istimewa, mengurangi risiko menjadi root sepenuhnya.
Selain itu, proses yang dimulai dengan pendekatan ini dikelompokkan ke dalam kelompok "pemberdayaan" logis dengan akses ke serangkaian tindakan luas yang dikelola oleh Polkit . Idenya adalah bahwa peningkatan hak akses bersifat terperinci dan terkontrol, menjaga pemisahan yang lebih ketat daripada yang biasanya ditawarkan oleh sudo tradisional, di mana akses seringkali dibuka terlalu luas.
Pendekatan ini sejalan dengan tren menghindari penggunaan langsung pengguna root sebisa mungkin , sebuah prinsip keamanan yang sangat dihargai. Namun, efektivitas sebenarnya dari run0 masih perlu dibuktikan di lingkungan produksi: kita harus melihat bagaimana integrasinya dengan kebijakan setiap distribusi, bagaimana kemampuannya dikonfigurasi dalam praktiknya, dan seberapa baik administrasi sistem beradaptasi dengan alur kerja baru.
Penghentian dukungan untuk init SysV dan pembersihan sistem lama.
systemd 259 juga menandai awal dari akhir definitif untuk skrip layanan bergaya System V. Kompatibilitas dengan mekanisme klasik ini telah ditandai sebagai "akan segera berakhir" selama bertahun-tahun, dan sekarang jadwal yang jelas untuk penghapusannya telah ditetapkan.
Versi ini mengumumkan bahwa, menjelang rilis utama berikutnya, Komponen-komponen lama seperti systemd-sysv-generator, systemd-rc-local-generator, dan systemd-sysv-install akan dihapus.Artinya, naskah-naskah dalam /etc/init.d/ Data tersebut tidak akan lagi diperhitungkan oleh systemd, yang mengakhiri transisi yang telah berlangsung selama hampir satu dekade.
Bagi administrator yang masih memelihara layanan kustom berbasis skrip SysV , ini berarti harus segera bekerja: semua skrip tersebut perlu diinventarisasi dan dimigrasikan ke unit systemd asli (.service, .socket, dll.). Distribusi besar telah menyelesaikan hampir seluruh transisi ini, tetapi di lingkungan kustom atau instalasi lama, beberapa "peninggalan" mungkin masih berjalan di latar belakang.
Proses pembersihan warisan ini tidak terbatas pada SysV. Versi systemd terbaru telah menghapus dukungan untuk metode klasik seperti `/forcefsck` dan `/fastboot` , menggantinya dengan parameter kernel dan mekanisme kredensial yang lebih modern. Dengan versi 259, arahnya sama: kompatibilitas mundur yang lebih rendah sebagai imbalan untuk basis kode yang lebih mudah dipelihara dan konsisten.
Persyaratan minimum systemd 259: kernel, pustaka, dan lingkungan
Salah satu perubahan yang dapat memberikan dampak terbesar pada sistem lama adalah peningkatan persyaratan perangkat lunak minimum untuk menjalankan systemd 259. Versi ini tidak lagi mempermasalahkan perangkat keras atau tumpukan teknologi yang sangat lama, dan jelas mendorong ke arah platform modern.
Di antara persyaratan utama yang dikonsolidasikan dalam systemd 259 adalah: komitmen terhadap platform modern.
- Kernel Linux versi minimal 5.10 (dengan rekomendasi untuk setidaknya sampai versi 5.14).
- glibc 2.34 sebagai versi minimal dari pustaka standar GNU.
- Buka SSL 3.0.0 sebagai dasar wajib untuk fungsi enkripsi yang didukung.
- util-linux 2.37 sebagai persyaratan untuk utilitas dasar sistem.
- libxcrypt 4.4.0 untuk pengelolaan fungsi kriptografi yang terkait dengan kata sandi.
- cryptsetup 2.4.0 dan libseccomp 2.4.0 untuk enkripsi volume dan pemfilteran panggilan sistem.
- Python 3.9.0 sebagai ketergantungan minimum untuk alat bantu.
- Beberapa catatan juga menyebutkan elfutil 0.177 sebagai bagian dari rangkaian dependensi yang diperbarui.
Pengetatan ini berarti bahwa sistem atau distribusi yang sangat lama yang masih menggunakan cabang kernel sebelum versi 5.10 secara otomatis dikecualikan dari dukungan untuk versi ini kecuali jika mereka memperbarui teknologi dasarnya. Sebagai imbalannya, tercipta ekosistem yang lebih homogen, dengan lebih sedikit kasus khusus dan solusi kompromi.
Untuk sebagian besar distribusi desktop dan server tujuan umum, persyaratan ini seharusnya tidak menjadi masalah: cabang kernel LTS modern sudah jauh melampaui batasan 5.10 , dan pustaka yang disebutkan tersedia secara luas. Masalah terbesar dapat muncul pada sistem tertanam, perangkat keras, atau instalasi yang sangat konservatif yang tidak sering diperbarui.
Keamanan yang ditingkatkan: TPM 2.0, enkripsi, dan pembatasan perangkat.
Di bidang keamanan, systemd 259 mempercepat kemajuannya dengan beberapa keputusan penting. Yang paling terlihat adalah bahwa systemd-boot dan systemd-stub secara definitif menghentikan dukungan untuk TPM 1.2 , sehingga mulai sekarang hanya TPM 2.0 yang dianggap sebagai standar referensi.
Perubahan ini berarti bahwa sistem yang mengandalkan TPM 1.2 untuk mengelola kebijakan boot aman atau kunci enkripsi perlu melakukan peningkatan perangkat keras (misalnya, dengan mengganti motherboard) jika ingin terus menggunakan fitur-fitur ini dengan versi systemd-boot yang lebih baru. Banyak pengguna desktop Linux menonaktifkan TPM dan Secure Boot, sehingga mereka mungkin bahkan tidak menyadari perubahan tersebut, tetapi hal ini dapat berdampak pada lingkungan perusahaan atau lingkungan dengan keamanan tinggi.
Pada rilis sebelumnya, seperti systemd 258, penyesuaian signifikan telah dilakukan di area ini: OpenSSL menjadi satu-satunya pustaka enkripsi yang didukung oleh systemd-resolved dan systemd-importd , mengesampingkan alternatif seperti GnuTLS dan libgcrypt. Semua ini menunjukkan konsolidasi di sekitar seperangkat alat kriptografi yang lebih kecil dan lebih terkontrol.
Pada branch 258, pembatasan akses default yang lebih ketat diperkenalkan untuk tty/pts : node dibuat dengan izin 0600, bukan 0620, sehingga mencegah pengguna lain untuk menulis ke terminal kita. Ini adalah contoh lain bagaimana systemd telah menyempurnakan detail tingkat rendah selama beberapa waktu, yang, jika digabungkan, memperkuat keamanan sistem secara keseluruhan.
libsystemd lebih modular dan dimuat secara dinamis.
Dalam upaya mencapai efisiensi yang lebih besar dan mengurangi beban ketergantungan, systemd 259 memperkenalkan perubahan mendasar pada cara libsystemd berinteraksi dengan pustaka sistem lainnya . Tujuannya adalah untuk mencegah semua hal dibawa dari awal, melainkan hanya dimuat saat dibutuhkan.
Secara spesifik, libsystemd sekarang menggunakan dlopen() untuk memuat pustaka secara dinamis seperti libacl, libblkid, libseccomp, libselinux, dan libmount . Ini berarti bahwa dependensi ini tidak dihubungkan secara kaku pada waktu kompilasi dan tidak selalu dimuat ke dalam memori: dependensi tersebut hanya diaktifkan ketika fungsi tertentu membutuhkannya.
Mekanisme yang sama dengan `dlopen()` juga berlaku untuk integrasi dengan subsistem audit Linux dan PAM . Dengan cara ini, proses startup dan operasi normal systemd dapat lebih ringan di lingkungan yang tidak memerlukan semua komponen ini secara bersamaan.
Di sisi lain, fungsionalitas yang sebelumnya disediakan oleh pustaka libcap telah diintegrasikan langsung ke dalam libsystemd . Hal ini menghilangkan ketergantungan eksternal lainnya, menyederhanakan rantai pembangunan dan mengurangi potensi titik kegagalan atau ketidakcocokan.
Secara umum, pendekatan ini memberikan modularitas yang lebih baik dan jejak memori serta disk yang lebih kecil , terutama pada sistem yang menginginkan waktu booting yang cepat dan serangkaian layanan yang padat.
Perubahan jaringan dan kontainer: selamat tinggal iptables, selamat datang nftables
Area jaringan dan virtualisasi juga mengalami perubahan signifikan. Mulai dari systemd 259, systemd-networkd dan systemd-nspawn tidak lagi mendukung pembuatan aturan NAT menggunakan iptables/libiptc . Satu-satunya backend firewall yang didukung adalah nftables.
Hal ini secara langsung memengaruhi kontainer yang dikelola dengan systemd-nspawn yang mengandalkan NAT melalui iptables , serta jaringan yang didefinisikan dalam systemd-networkd yang menggunakan aturan terjemahan alamat dengan backend klasik. Dalam pengujian dengan kandidat rilis, kegagalan tanpa pemberitahuan pada fungsi NAT diamati hingga seluruh konfigurasi dimigrasikan ke nftables.
Selain penerjemahan alamat, systemd-resolved memperoleh kemampuan untuk menggunakan hook lokal. en /run/systemd/resolve.hook/Perintah-perintah ini dieksekusi setiap kali kueri resolusi nama lokal dilakukan. Hal ini membuka peluang untuk kustomisasi DNS tingkat lanjut dan logika khusus oleh administrator.
Di bidang impor dan manajemen gambar, systemd-importd menggabungkan logika bawaan untuk bekerja dengan file TAR., dengan mengandalkan libarchive dari utilitas GNU tar. Selain itu, baik systemd-importd maupun systemd-machined sekarang dapat dijalankan dalam mode pengguna, mengelola citra sistem yang ditempatkan di ~/.local/state/machines/.
Untuk mengontrol mode-mode ini, utilitas importctl menambahkan opsi "--user" dan "--system" , yang memungkinkan Anda untuk dengan mudah memilih apakah akan beroperasi dalam konteks pengguna atau pada tingkat sistem. Pendekatan ini berguna untuk lingkungan pengembangan dan pengujian di mana Anda tidak ingin memodifikasi konfigurasi global mesin.
Pencatatan jurnal persisten secara default dan manajemen ruang disk.
Perubahan lain yang memiliki dampak praktis adalah modifikasi dari mode penyimpanan jurnal default, subsistem pencatatan (logging) dari systemd. Hingga saat ini, perilaku "otomatis" bergantung pada keberadaan atau tidaknya direktori tersebut. /var/log/journal.
Dengan systemd 259, mode default menjadi "persistent ", terlepas dari apakah folder tersebut sudah ada sebelumnya. Ini berarti jurnal akan disimpan secara permanen ke disk secara default, alih-alih disimpan di RAM yang mudah berubah.
Keputusan ini memiliki pro dan kontra. Di satu sisi, hal ini sangat menyederhanakan pemecahan masalah , karena log tetap ada setelah reboot tanpa memerlukan tindakan khusus dari administrator. Di sisi lain, pada sistem tertanam, kontainer ringan, atau lingkungan dengan penyimpanan yang sangat terbatas, hal ini dapat mengakibatkan peningkatan penggunaan disk yang signifikan.
Dalam skenario ini, akan lebih penting dari sebelumnya untuk menyesuaikan kebijakan rotasi dan ukuran jurnal , atau bahkan memaksakan mode penyimpanan yang berbeda jika Anda ingin menghindari keausan yang berlebihan (misalnya, pada memori flash dengan siklus penulisan terbatas).
systemd-ooMD, pelacakan OOM dan kontrol sumber daya
Manajemen memori dan skenario "Kehabisan Memori" juga menerima peningkatan yang signifikan. Komponen systemd-oomd, yang bertanggung jawab untuk menanggapi situasi memori yang tidak mencukupi , menggabungkan properti baru untuk memberikan visibilitas yang lebih besar.
Secara spesifik, properti OOMKills dan ManagedOOMKills kini tersedia untuk layanan , yang mencatat jumlah proses yang dihentikan oleh kernel atau oleh systemd-oomd itu sendiri karena memori yang tidak mencukupi. Informasi ini dapat diakses langsung menggunakan alat systemd, sehingga memudahkan analisis insiden selanjutnya.
Ketika suatu proses menjadi tidak terkendali dan mulai "memakan" RAM hingga membahayakan sistem , metrik ini memungkinkan Anda untuk melihat sekilas unit mana yang terpengaruh, berapa kali mekanisme OOM (Out of Memory) telah dipicu, dan komponen mana yang menyebabkan tekanan memori paling besar.
Bagi administrator lingkungan dengan beban tinggi atau sistem dengan sumber daya yang sangat terbatas, kemampuan yang lebih besar untuk mengamati OOM (Out of Memory) ini sangat berguna, karena membantu mengidentifikasi layanan dengan ukuran yang tidak tepat atau kebocoran memori yang mungkin sebelumnya tidak terdeteksi.
Peningkatan penting lainnya pada systemd 259
Selain perubahan besar yang disebutkan di atas, systemd 259 hadir dengan banyak peningkatan dan penyesuaian kecil yang tersebar di seluruh ekosistem . Banyak di antaranya cukup teknis, tetapi ada baiknya untuk meninjaunya karena secara keseluruhan perubahan tersebut menghasilkan perubahan yang signifikan.
Di antara fitur-fitur baru API tersebut, Antarmuka berbasis protokol Varlink sedang diperluas. untuk memungkinkan akses ke konfigurasi layanan dan mengeksekusi panggilan IPC seperti Reload() y Reexecute()Panggilan khusus juga ditambahkan untuk menangani fungsi systemd-repart, systemd-resolved, dan systemd-networkd.
Di area konfigurasi dan unit, opsi ExecReloadPost telah diperkenalkan , yang memungkinkan perintah diluncurkan segera setelah konfigurasi layanan dimuat ulang. Selain itu, file konfigurasi yang berakhiran ".ignore" sekarang secara otomatis dibuang , sebuah trik sederhana untuk menonaktifkan file tanpa harus menghapus atau mengubah namanya secara drastis.
Unit sementara memperoleh kepemilikan Deskriptor Berkas Direktori Akar, yang mendefinisikan deskriptor file yang sesuai dengan direktori root, dan opsi baru ditambahkan. JalurRuangNamaPengguna, yang memungkinkan Anda untuk menautkan drive ke namespace pengguna dengan menentukan jalur di /procDi systemd-nspawn, arahan tersebut muncul NamespacePath di bagian tersebut dari file .nspawn untuk menunjukkan namespace jaringan yang akan digunakan.
Komponen lainnya seperti systemd-sysext dan systemd-context menyertakan file konfigurasi khusus. en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confVariabel lingkungan SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS Fitur ini memungkinkan Anda untuk menyesuaikan opsi pemasangan untuk Overlay.
Dalam dunia udev, opsi ini ditambahkan. OPTIONS=»dump-json» ke systemd-udevd Untuk menampilkan status terkini suatu peristiwa dalam format JSON, fungsi tersebut net_id Fitur ini menghasilkan nama yang mudah diprediksi untuk antarmuka nirkabel pada sistem dengan DeviceTree dan membuat tautan simbolik. /dev/gpio/by-id/... untuk perangkat GPIO.
Bagian pengguna dan akun juga sedang diperkuat: Basis data pengguna mencakup kolom UUID.Utilitas userdbctl mendukung opsi "-uuid" untuk mencari berdasarkan pengidentifikasi ini, dan homectl update Sekarang fitur ini mendukung "--recovery-key" untuk menambahkan kunci pemulihan ke akun yang sudah ada.
Di systemd-homed, opsi "--prompt-shell" dan "--prompt-groups" diintegrasikan selama boot pertama menggunakan systemd-homed-firstboot.service, dan di systemd-firstboot, "--prompt-keymap-auto" tampaknya meminta pemetaan keyboard saat menggunakan konsol lokal pada boot pertama.
El Manajer boot systemd-boot menambahkan kemampuan untuk menentukan tingkat detail log. dengan parameter log-level en loader.conf atau dengan kolom SMBIOS io.systemd.boot.loglevelSelain itu, persyaratan yang lebih ketat sedang dikonsolidasikan untuk partisi seperti XBOOTLDR, yang sekarang harus dalam format VFAT, sejalan dengan apa yang sudah dipersyaratkan untuk ESP dalam sistem UEFI modern.
Pada tingkat jaringan tingkat lanjut, systemd-networkd menambahkan opsi EmitDomain dan Domain untuk server DHCP dan mengimplementasikan pengontrol yang menentukan nama host yang dikeluarkan melalui DHCP menggunakan resolusi DNS. Sementara itu, systemd-modules-load memuat modul kernel secara paralel , mengurangi waktu booting pada sistem dengan banyak driver.
Terakhir, pada bagian integritas, systemd-integrity-setup menambahkan dukungan untuk algoritma HMAC-SHA256, PHMAC-SHA256, dan PHMAC-SHA512 , memperluas jangkauan opsi kriptografi yang tersedia untuk melindungi integritas sistem.
Dengan semua perubahan ini, systemd 259 memperkuat posisinya sebagai versi yang sangat teknis, menuntut, dan jelas berorientasi ke masa depan . Versi ini mendorong pengguna untuk meninggalkan teknologi lama seperti SysV init, iptables, dan TPM 1.2, memperkuat keamanan dan kontrol sumber daya, meningkatkan modularitas internal, dan membuka pintu untuk konfigurasi baru dengan musl, meskipun sebagian dan bersyarat. Bagi pengguna akhir pada distribusi rilis titik, banyak fitur baru ini hampir tidak akan terasa; bagi administrator dan proyek yang terus-menerus menggunakan versi terbaru, inilah saatnya untuk meninjau dengan cermat skrip, unit, dan persyaratan perangkat keras sebelum melakukan peralihan.
