systemd 259: การเปลี่ยนแปลงที่สำคัญและข้อกำหนดของระบบ

อินฟอร์เมเทค ดิจิตอล » Recursos » systemd 259: การเปลี่ยนแปลงที่สำคัญและข้อกำหนดของระบบ

การเปิดตัวsystemd 259 ในฐานะเวอร์ชันเสถียรถือเป็นการเปลี่ยนแปลงครั้งสำคัญอีกครั้งหนึ่งในส่วนประกอบที่สำคัญและเป็นที่ถกเถียงกันมากที่สุดของระบบนิเวศ Linux เรากำลังพูดถึงเฟรมเวิร์กสำหรับการเริ่มต้นและจัดการบริการ ซึ่งครอบงำการแจกจ่าย Linux ส่วนใหญ่อยู่แล้ว และการเปิดตัวครั้งนี้ได้เพิ่มความเข้มงวดในแง่ของข้อกำหนดทางเทคนิค ความปลอดภัย และการละทิ้งเทคโนโลยีแบบเก่าๆ

การอัปเดตครั้งนี้เกิดขึ้นหลังจากทำงานอย่างหนักมาหลายเดือน และมุ่งเน้นไปที่สามด้านหลัก ได้แก่ ความเข้ากันได้กับไลบรารี C ใหม่ การรักษาความปลอดภัยที่ได้รับการปรับปรุง และการปรับปรุงโค้ดเก่า (สคริปต์ SysV, TPM 1.2, iptables เป็นต้น) นอกจากนี้ยังมีการเปลี่ยนแปลงที่สำคัญในด้านการจัดการสิทธิ์ด้วย run0 การจัดการหน่วยความจำด้วย systemd-oomd การจัดเก็บบันทึก และโมเดลการพึ่งพาภายในของ libsystemd อีกด้วย

systemd 259 และการสนับสนุนเชิงทดลองสำหรับ musl

หนึ่งในคุณสมบัติที่ถูกพูดถึงมากที่สุดของเวอร์ชันนี้คือsystemd 259 ได้รวมเอาการสนับสนุนบางส่วนสำหรับไลบรารีมาตรฐาน C ที่ชื่อ musl เป็นครั้งแรกไลบรารีนี้มีการใช้งานอย่างแพร่หลายในระบบขนาดเล็ก คอนเทนเนอร์แบบมินิมัลลิสต์ และสภาพแวดล้อมแบบฝังตัว ซึ่งต้องการความเรียบง่ายและการใช้ทรัพยากรที่ลดลงเมื่อเทียบกับ glibc

การรองรับ musl เปิดใช้งานได้โดยการตั้งค่าตัวเลือก "libc" ของระบบสร้าง Meson เป็น "musl"อย่างไรก็ตาม การผสานรวมนี้ยังไม่สมบูรณ์: musl ไม่ได้ใช้งานกลไก Name Service Switch (NSS) ซึ่งบังคับให้ปิดใช้งานส่วนต่างๆ ของ systemd เมื่อคอมไพล์โดยใช้ไลบรารีนี้

โดยเฉพาะอย่างยิ่ง การสร้าง systemd เวอร์ชัน 259 ด้วย musl จะไม่รวมส่วนประกอบสำคัญ เช่น nss-systemd, nss-resolve, systemd-homed, systemd-userdbd และ systemd-nsresourcedนอกจากนี้ ตัวเลือก DynamicUser และความสามารถในการเรียกใช้ systemd-nspawn โดยไม่ต้องใช้สิทธิ์พิเศษก็ไม่สามารถใช้งานได้ ซึ่งมีความสำคัญอย่างยิ่งในสภาพแวดล้อมคอนเทนเนอร์ที่ต้องพึ่งพาความสามารถเหล่านี้เป็นอย่างมาก

ผู้พัฒนาเองก็ยอมรับว่าพวกเขาไม่สามารถรับประกันการสนับสนุนในระยะยาวได้การสนับสนุนจะดำเนินต่อไปหรือไม่นั้นขึ้นอยู่กับความสนใจที่แท้จริงของชุมชน ความสมบูรณ์ของส่วนเสริมที่ให้ฟังก์ชันที่ musl ขาดไป และรายงานข้อบกพร่องเฉพาะของไลบรารีนี้ หากความต้องการต่ำหรือการบำรุงรักษาซับซ้อนเกินไป ก็คงไม่น่าแปลกใจหากการสนับสนุนนี้จะถูกทบทวนในเวอร์ชันต่อๆ ไป

อย่างไรก็ตาม การเปิดรับ musl นี้มีความสำคัญในเชิงสัญลักษณ์: systemd ถูกวิพากษ์วิจารณ์มานานหลายปีแล้วเกี่ยวกับการพึ่งพา glibc เกือบทั้งหมดซึ่งทำให้ไม่เป็นมิตรกับระบบปฏิบัติการทางเลือกและสถานการณ์ที่เรียบง่ายมาก ๆ ขั้นตอนนี้ไม่ได้แก้ปัญหาทุกอย่าง แต่เป็นการทำลายภาพลักษณ์ของระบบที่ปิดกั้นตัวเองจากไลบรารี C อื่น ๆ อย่างสิ้นเชิง

run0 และโมเดลสิทธิ์แบบใหม่: ทางเลือกอื่นนอกเหนือจาก sudo

อีกหนึ่งคุณสมบัติหลักของ systemd 259 คือยูทิลิตี้ run0 ถูกเสนอให้เป็นทางเลือกที่ทันสมัยและปลอดภัยกว่าสำหรับ sudoเครื่องมือนี้สร้างขึ้นบน systemd-run อยู่แล้ว แต่ตอนนี้มันได้รับความสามารถที่สำคัญเพิ่มขึ้นมา นั่นคือ ตัวเลือก --empower.

อาร์กิวเมนต์ใหม่ `--empower` ช่วยให้คุณเริ่มต้นเซสชันด้วยสิทธิ์ระดับสูงโดยไม่ต้องเปลี่ยน UID ของคุณเป็น rootแทนที่จะใช้การสลับผู้ใช้แบบเดิม `run0` ใช้ประโยชน์จากความสามารถของเคอร์เนล (เช่น `CAP_SYS_ADMIN`) เพื่อให้สิทธิ์ที่จำเป็นในการดำเนินการที่มีสิทธิ์พิเศษอย่างแม่นยำ ลดความเสี่ยงในการเป็น root ลงอย่างสิ้นเชิง

นอกจากนี้ กระบวนการที่เริ่มต้นด้วยวิธีการนี้จะถูกจัดกลุ่มไว้ในกลุ่ม "เสริมอำนาจ" เชิงตรรกะ ซึ่งสามารถเข้าถึงการดำเนินการต่างๆ มากมายที่จัดการโดย Polkitแนวคิดก็คือ การเพิ่มสิทธิ์นั้นเป็นไปอย่างละเอียดและควบคุมได้ รักษาการแยกส่วนที่เข้มงวดกว่าที่มักพบใน sudo แบบดั้งเดิม ซึ่งมักเปิดการเข้าถึงกว้างเกินไป

แนวทางนี้สอดคล้องกับแนวโน้มในการหลีกเลี่ยงการใช้ผู้ใช้ root โดยตรงทุกครั้งที่เป็นไปได้ ซึ่งเป็นหลักการด้านความปลอดภัยที่ได้รับการยกย่องอย่างสูง อย่างไรก็ตาม ประสิทธิภาพที่แท้จริงของ run0 ยังคงต้องได้รับการพิสูจน์ในสภาพแวดล้อมการใช้งานจริง เราจะต้องดูว่ามันทำงานร่วมกับนโยบายของแต่ละระบบปฏิบัติการอย่างไร ความสามารถของมันถูกกำหนดค่าในทางปฏิบัติอย่างไร และฝ่ายบริหารระบบจะปรับตัวเข้ากับเวิร์กโฟลว์ใหม่ได้ดีเพียงใด

สิ้นสุดการสนับสนุนสำหรับการเริ่มต้น SysV และการล้างข้อมูลเก่า

systemd เวอร์ชัน 259 ยังถือเป็นการเริ่มต้นของการยุติการใช้งานสคริปต์บริการแบบ System V อย่างถาวร ความเข้ากันได้กับกลไกแบบคลาสสิกเหล่านี้ถูกระบุว่า "กำลังจะหมดไป" มานานหลายปีแล้ว และตอนนี้ก็ได้มีกำหนดการที่ชัดเจนสำหรับการลบออกแล้ว

เวอร์ชันนี้ประกาศว่า เมื่อมองไปข้างหน้าถึงการเปิดตัวเวอร์ชันหลักครั้งต่อไป ส่วนประกอบทางประวัติศาสตร์ เช่น systemd-sysv-generator, systemd-rc-local-generator และ systemd-sysv-install จะถูกลบออกนั่นคือ สคริปต์ใน /etc/init.d/ ระบบ systemd จะไม่นำข้อมูลเหล่านี้มาพิจารณาอีกต่อไป ซึ่งเป็นการสิ้นสุดช่วงเปลี่ยนผ่านที่กินเวลานานเกือบสิบปี

สำหรับผู้ดูแลระบบที่ยังคงดูแลรักษาระบบบริการแบบกำหนดเองโดยใช้สคริปต์ SysV อยู่นั่นหมายความว่าพวกเขาจะต้องลงมือทำงานอย่างจริงจัง: สคริปต์เหล่านั้นทั้งหมดจะต้องถูกตรวจสอบและย้ายไปยังหน่วย systemd ดั้งเดิม (.service, .socket เป็นต้น) ระบบปฏิบัติการขนาดใหญ่ส่วนใหญ่ได้ทำการเปลี่ยนแปลงนี้เสร็จสิ้นไปแล้วเกือบทั้งหมด แต่ในสภาพแวดล้อมแบบกำหนดเองหรือการติดตั้งเวอร์ชันเก่า อาจมี "สิ่งตกค้าง" บางอย่างที่ยังคงทำงานอยู่เบื้องหลัง

กระบวนการล้างข้อมูลที่ล้าสมัยนี้ไม่ได้จำกัดอยู่แค่ SysV เท่านั้น เวอร์ชันล่าสุดของ systemd ได้ลบการสนับสนุนวิธีการแบบเก่า เช่น `/forcefsck` และ `/fastboot`ออกไปแล้ว โดยแทนที่ด้วยพารามิเตอร์เคอร์เนลและกลไกการตรวจสอบสิทธิ์ที่ทันสมัยกว่า สำหรับเวอร์ชัน 259 ทิศทางก็ยังคงเหมือนเดิม คือ ลดความเข้ากันได้กับเวอร์ชันเก่าลงเพื่อแลกกับโค้ดเบสที่ดูแลรักษาง่ายและสม่ำเสมอมากขึ้น

ข้อกำหนดขั้นต่ำของ systemd 259: เคอร์เนล ไลบรารี และสภาพแวดล้อม

หนึ่งในความเปลี่ยนแปลงที่อาจส่งผลกระทบมากที่สุดต่อระบบเก่าคือการเพิ่มข้อกำหนดขั้นต่ำของซอฟต์แวร์ในการใช้งาน systemd 259เวอร์ชันนี้ไม่สนใจฮาร์ดแวร์หรือสแต็กที่เก่ามากอีกต่อไป และมุ่งเน้นไปที่แพลตฟอร์มที่ทันสมัยอย่างชัดเจน

ข้อกำหนดสำคัญที่รวบรวมไว้ใน systemd 259 ได้แก่ความมุ่งมั่นต่อแพลตฟอร์มที่ทันสมัย

• เคอร์เนลลินุกซ์เวอร์ชัน 5.10 ขั้นต่ำ (โดยแนะนำให้เล่นอย่างน้อยถึงระดับ 5.14)
• glibc2.34 ในรูปแบบเวอร์ชันย่อของไลบรารีมาตรฐาน GNU
• เปิด SSL 3.0.0 ถือเป็นพื้นฐานที่จำเป็นสำหรับฟังก์ชันการเข้ารหัสที่รองรับ
• ยูทิลิตี้-ลินุกซ์ 2.37 เป็นสิ่งจำเป็นสำหรับระบบสาธารณูปโภคขั้นพื้นฐาน
• libxcrypt 4.4.0 สำหรับการจัดการฟังก์ชันการเข้ารหัสที่เกี่ยวข้องกับรหัสผ่าน
• cryptsetup 2.4.0 และ libseccomp 2.4.0 สำหรับการเข้ารหัสไดรฟ์และการกรองการเรียกใช้ระบบ
• งูหลาม 3.9.0 เป็นส่วนประกอบขั้นต่ำที่จำเป็นสำหรับเครื่องมือเสริม
• บันทึกบางส่วนยังกล่าวถึงเรื่องนี้ด้วย เอลฟูทิล 0.177 เป็นส่วนหนึ่งของชุดการพึ่งพาที่ได้รับการอัปเดตแล้ว

การปรับปรุงให้เข้มงวดขึ้นนี้หมายความว่าระบบหรือระบบปฏิบัติการรุ่นเก่ามาก ๆ ที่ยังคงใช้เคอร์เนลเวอร์ชันก่อน 5.10 จะไม่ได้รับการสนับสนุนในเวอร์ชันนี้โดยอัตโนมัติ เว้นแต่ว่าจะมีการอัปเดตเทคโนโลยีพื้นฐานของตน ในทางกลับกัน จะทำให้เกิดระบบนิเวศที่เป็นเนื้อเดียวกันมากขึ้น โดยมีกรณีพิเศษและวิธีแก้ปัญหาแบบประนีประนอมน้อยลง

สำหรับระบบปฏิบัติการเดสก์ท็อปและเซิร์ฟเวอร์ทั่วไปส่วนใหญ่ ข้อกำหนดเหล่านี้ไม่น่าจะเป็นปัญหา: เคอร์เนลเวอร์ชัน LTS รุ่นใหม่ๆ นั้นรองรับเวอร์ชัน 5.10 ขึ้นไปแล้วและไลบรารีที่กล่าวถึงก็หาได้ง่าย ปัญหาใหญ่ที่สุดอาจเกิดขึ้นในระบบฝังตัว อุปกรณ์ หรือระบบที่ติดตั้งแบบอนุรักษ์นิยมมาก ๆ ซึ่งไม่ได้มีการอัปเดตบ่อยนัก

ระบบรักษาความปลอดภัยขั้นสูง: TPM 2.0, การเข้ารหัส และการจำกัดการใช้งานอุปกรณ์

ในด้านความปลอดภัย systemd 259 เร่งความก้าวหน้าด้วยการตัดสินใจที่สำคัญหลายประการ ที่เห็นได้ชัดที่สุดคือsystemd-boot และ systemd-stub เลิกสนับสนุน TPM 1.2 อย่างถาวรดังนั้นจากนี้ไป TPM 2.0 เท่านั้นที่จะถือเป็นมาตรฐานอ้างอิง

การเปลี่ยนแปลงนี้หมายความว่าระบบที่ใช้TPM 1.2 ในการจัดการนโยบายการบูตที่ปลอดภัยหรือคีย์การเข้ารหัสจะต้องอัปเกรดฮาร์ดแวร์ (เช่น การเปลี่ยนเมนบอร์ด) หากต้องการใช้งานคุณสมบัติเหล่านี้ต่อไปกับ systemd-boot เวอร์ชันใหม่กว่า ผู้ใช้เดสก์ท็อป Linux จำนวนมากปิดใช้งาน TPM และ Secure Boot ดังนั้นพวกเขาอาจไม่สังเกตเห็นการเปลี่ยนแปลง แต่การเปลี่ยนแปลงนี้อาจส่งผลกระทบในสภาพแวดล้อมขององค์กรหรือสภาพแวดล้อมที่มีความปลอดภัยสูง

ในเวอร์ชันก่อนหน้า เช่น systemd 258 ได้มีการปรับปรุงที่สำคัญในส่วนนี้แล้ว โดยOpenSSL กลายเป็นไลบรารีการเข้ารหัสเพียงตัวเดียวที่ได้รับการสนับสนุนโดย systemd-resolved และ systemd-importdโดยไม่รวมทางเลือกอื่น ๆ เช่น GnuTLS และ libgcrypt ทั้งหมดนี้ชี้ให้เห็นถึงการรวมกลุ่มของเครื่องมือเข้ารหัสลับที่มีขนาดเล็กลงและควบคุมได้มากขึ้น

ในเวอร์ชัน 258 ยังมีการเพิ่มข้อจำกัดการเข้าถึงเริ่มต้นที่เข้มงวดมากขึ้นสำหรับ tty/ptsโดยสร้างโหนดด้วยสิทธิ์ 0600 แทนที่จะเป็น 0620 เพื่อป้องกันไม่ให้ผู้ใช้รายอื่นเขียนไปยังเทอร์มินัลของเรา นี่เป็นอีกตัวอย่างหนึ่งที่แสดงให้เห็นว่า systemd ได้ปรับแต่งรายละเอียดระดับต่ำมาสักระยะหนึ่งแล้ว ซึ่งเมื่อรวมกันแล้วจะช่วยเสริมความปลอดภัยโดยรวมของระบบ

libsystemd มีโครงสร้างแบบโมดูลาร์มากกว่าและสามารถโหลดได้แบบไดนามิก

เพื่อเพิ่มประสิทธิภาพและลดภาระการพึ่งพาไลบรารีอื่นๆ systemd 259 จึงได้นำเสนอการเปลี่ยนแปลงครั้งสำคัญในวิธีการที่ libsystemd ทำงานร่วมกับไลบรารีระบบอื่นๆเป้าหมายคือการป้องกันไม่ให้มีการโหลดทุกอย่างตั้งแต่เริ่มต้น แต่จะโหลดเฉพาะเมื่อจำเป็นเท่านั้น

โดยเฉพาะอย่างยิ่งlibsystemd ในปัจจุบันใช้ dlopen() เพื่อโหลดไลบรารีแบบไดนามิก เช่น libacl, libblkid, libseccomp, libselinux และ libmountซึ่งหมายความว่าไลบรารีเหล่านี้จะไม่ถูกเชื่อมโยงอย่างตายตัวในระหว่างการคอมไพล์ และจะไม่ถูกโหลดเข้าสู่หน่วยความจำเสมอไป แต่จะถูกเรียกใช้งานก็ต่อเมื่อฟังก์ชันเฉพาะต้องการใช้งานเท่านั้น

กลไกเดียวกันนี้ที่ใช้กับ `dlopen()` ยังใช้ได้กับการบูรณาการกับระบบตรวจสอบของ Linux และ PAMด้วยเช่นกัน ด้วยวิธีนี้ การเริ่มต้นและการทำงานปกติของ systemd จะเบาลงในสภาพแวดล้อมที่ไม่ต้องการส่วนประกอบทั้งหมดเหล่านี้พร้อมกัน

ในทางกลับกันฟังก์ชันการทำงานที่เคยมีอยู่ในไลบรารี libcap ได้ถูกรวมเข้ากับ libsystemd โดยตรงแล้วซึ่งช่วยลดการพึ่งพาไลบรารีภายนอกอีกตัวหนึ่ง ทำให้กระบวนการสร้างง่ายขึ้น และลดโอกาสที่จะเกิดความล้มเหลวหรือความไม่เข้ากัน

โดยทั่วไปแล้ว แนวทางนี้ให้ความยืดหยุ่นในการใช้งานที่ดีกว่า และใช้หน่วยความจำและพื้นที่ดิสก์น้อยกว่าโดยเฉพาะในระบบที่ต้องการเวลาบูตเครื่องที่รวดเร็วและชุดบริการที่กระชับ

การเปลี่ยนแปลงด้านเครือข่ายและคอนเทนเนอร์: ลาก่อน iptables สวัสดี nftables

ในส่วนของการเชื่อมต่อเครือข่ายและการจำลองเสมือนก็มีการเปลี่ยนแปลงครั้งสำคัญเช่นกัน เริ่มตั้งแต่ systemd เวอร์ชัน 259 เป็นต้นไปsystemd-networkd และ systemd-nspawn จะไม่รองรับการสร้างกฎ NAT โดยใช้ iptables/libiptc อีกต่อไป ส่วนไฟร์วอลล์ที่รองรับเพียงอย่างเดียวคือ nftables

ปัญหานี้ส่งผลกระทบโดยตรงต่อคอนเทนเนอร์ที่จัดการด้วย systemd-nspawn ซึ่งอาศัย NAT ผ่าน iptablesรวมถึงเครือข่ายที่กำหนดไว้ใน systemd-networkd ซึ่งใช้กฎการแปลงที่อยู่ด้วยแบ็กเอนด์แบบดั้งเดิม ในการทดสอบกับเวอร์ชันทดลองใช้งาน พบความล้มเหลวแบบเงียบๆ ในการทำงานของ NAT จนกระทั่งการกำหนดค่าทั้งหมดถูกย้ายไปยัง nftables

นอกเหนือจากการแปลที่อยู่แล้ว systemd-resolved เพิ่มความสามารถในการใช้ hook ในเครื่อง en /run/systemd/resolve.hook/คำสั่งเหล่านี้จะถูกเรียกใช้ทุกครั้งที่มีการสอบถามการแก้ไขชื่อโดเมนในพื้นที่ ซึ่งเปิดโอกาสให้ผู้ดูแลระบบสามารถปรับแต่ง DNS ขั้นสูงและกำหนดตรรกะเฉพาะได้

ในด้านการนำเข้าและจัดการรูปภาพ systemd-importd ผสานรวมตรรกะดั้งเดิมสำหรับการทำงานกับไฟล์ TARโดยอาศัยไลบรารี libarchive จากยูทิลิตี้ GNU tar นอกจากนี้ ทั้ง systemd-importd และ systemd-machined ยังสามารถทำงานในโหมดผู้ใช้ได้ โดยจัดการอิมเมจระบบที่วางไว้ใน ~/.local/state/machines/.

ในการควบคุมโหมดเหล่านี้ยูทิลิตี้ importctl จะเพิ่มตัวเลือก "--user" และ "--system"ซึ่งช่วยให้คุณเลือกได้อย่างง่ายดายว่าจะทำงานในบริบทของผู้ใช้หรือในระดับระบบ วิธีนี้มีประโยชน์สำหรับสภาพแวดล้อมการพัฒนาและการทดสอบที่คุณไม่ต้องการแก้ไขการกำหนดค่าโดยรวมของเครื่อง

การบันทึกข้อมูลแบบถาวรโดยค่าเริ่มต้นและการจัดการพื้นที่ดิสก์

การเปลี่ยนแปลงอีกประการหนึ่งที่มีผลกระทบในทางปฏิบัติคือการปรับเปลี่ยน โหมดการจัดเก็บบันทึกเริ่มต้นซึ่งเป็นระบบย่อยการบันทึกข้อมูลของ systemd จนถึงปัจจุบัน พฤติกรรม "อัตโนมัติ" ขึ้นอยู่กับการมีอยู่หรือไม่ของไดเร็กทอรีนั้น /var/log/journal.

ใน systemd เวอร์ชัน 259 โหมดเริ่มต้นจะเป็น "ถาวร " โดยไม่คำนึงว่าโฟลเดอร์นั้นเคยมีอยู่ก่อนหรือไม่ ซึ่งหมายความว่าบันทึกจะถูกบันทึกอย่างถาวรลงดิสก์โดยค่าเริ่มต้น แทนที่จะเก็บไว้ในหน่วยความจำ RAM ชั่วคราว

การตัดสินใจนี้มีทั้งข้อดีและข้อเสีย ในด้านหนึ่งมันช่วยลดความซับซ้อนในการแก้ไขปัญหาได้อย่างมากเนื่องจากไฟล์บันทึกยังคงอยู่แม้หลังจากการรีบูตโดยไม่ต้องมีการดำเนินการพิเศษใดๆ จากผู้ดูแลระบบ ในอีกด้านหนึ่ง ในระบบฝังตัว คอนเทนเนอร์ขนาดเล็ก หรือสภาพแวดล้อมที่มีพื้นที่จัดเก็บข้อมูลจำกัดมาก อาจส่งผลให้การใช้งานดิสก์เพิ่มขึ้นอย่างมาก

ในสถานการณ์เหล่านี้ การปรับนโยบายการหมุนเวียนและการกำหนดขนาดของวารสาร หรือแม้กระทั่งการบังคับใช้โหมดการจัดเก็บข้อมูลที่แตกต่างออกไป จะมีความสำคัญมากกว่าที่เคยหากคุณต้องการหลีกเลี่ยงการสึกหรอมากเกินไป (ตัวอย่างเช่น ในหน่วยความจำแฟลชที่มีรอบการเขียนจำกัด)

systemd-oomd, การติดตาม OOM และการควบคุมทรัพยากร

การจัดการหน่วยความจำและสถานการณ์ "หน่วยความจำไม่เพียงพอ" ก็ได้รับการปรับปรุงอย่างมากเช่นกันคอมโพเนนต์ systemd-oomd ซึ่งรับผิดชอบในการตอบสนองต่อสถานการณ์หน่วยความจำไม่เพียงพอ ได้เพิ่มคุณสมบัติใหม่เพื่อให้มองเห็นได้ชัดเจนยิ่งขึ้น

โดยเฉพาะอย่างยิ่งคุณสมบัติ OOMKills และ ManagedOOMKills พร้อมใช้งานแล้วสำหรับบริการต่างๆซึ่งจะบันทึกจำนวนกระบวนการที่ถูกยุติโดยเคอร์เนลหรือโดย systemd-oomd เองเนื่องจากหน่วยความจำไม่เพียงพอ ข้อมูลนี้สามารถเข้าถึงได้โดยตรงโดยใช้เครื่องมือ systemd ซึ่งจะช่วยอำนวยความสะดวกในการวิเคราะห์เหตุการณ์ในภายหลัง

เมื่อกระบวนการทำงานผิดปกติและเริ่ม"แย่งใช้" RAM จนถึงขั้นเป็นอันตรายต่อระบบตัวชี้วัดเหล่านี้จะช่วยให้คุณเห็นได้อย่างรวดเร็วว่าหน่วยใดได้รับผลกระทบ กลไก OOM ถูกเรียกใช้งานกี่ครั้ง และส่วนประกอบใดที่ทำให้เกิดแรงกดดันต่อหน่วยความจำมากที่สุด

สำหรับผู้ดูแลระบบที่มีภาระงานสูงหรือระบบที่มีทรัพยากรจำกัดมากความสามารถในการสังเกต OOM ที่มากขึ้น นี้ มีประโยชน์อย่างยิ่ง เนื่องจากช่วยระบุบริการที่มีขนาดไม่เหมาะสมหรือการรั่วไหลของหน่วยความจำที่อาจไม่เคยถูกสังเกตมาก่อน

การปรับปรุงที่สำคัญอื่นๆ ใน systemd 259

นอกเหนือจากการเปลี่ยนแปลงหลักๆ ที่กล่าวมาข้างต้นแล้ว systemd 259 ยังมาพร้อมกับการปรับปรุงและแก้ไขเล็กๆ น้อยๆ มากมายที่กระจายอยู่ทั่วทั้งระบบนิเวศหลายอย่างค่อนข้างซับซ้อนทางเทคนิค แต่ก็คุ้มค่าที่จะตรวจสอบ เพราะโดยรวมแล้วจะทำให้เกิดการเปลี่ยนแปลงที่สำคัญ

ในบรรดาคุณสมบัติใหม่ของ API นั้น ได้แก่ อินเทอร์เฟซที่ใช้โปรโตคอล Varlink กำลังได้รับการขยาย เพื่ออนุญาตการเข้าถึงการกำหนดค่าบริการและดำเนินการเรียกใช้ IPC เช่น Reload() y Reexecute()นอกจากนี้ ยังมีการเพิ่มคำสั่งเฉพาะเพื่อจัดการฟังก์ชันการทำงานของ systemd-repart, systemd-resolved และ systemd-networkd อีกด้วย

ในส่วนของการตั้งค่าและการกำหนดค่าหน่วย ได้ มีการเพิ่มตัวเลือก ExecReloadPostซึ่งช่วยให้สามารถเรียกใช้คำสั่งได้ทันทีหลังจากที่การตั้งค่าของบริการได้รับการโหลดใหม่ นอกจากนี้ไฟล์การตั้งค่าที่ลงท้ายด้วย ".ignore" จะถูกลบทิ้งโดยอัตโนมัติซึ่งเป็นเทคนิคที่ง่ายสำหรับการปิดใช้งานไฟล์โดยไม่ต้องลบหรือเปลี่ยนชื่อไฟล์อย่างรุนแรง

หน่วยชั่วคราวได้รับกรรมสิทธิ์ ตัวอธิบายไฟล์ไดเร็กทอรีรากซึ่งกำหนดตัวระบุไฟล์ที่สอดคล้องกับไดเร็กทอรีราก และมีการเพิ่มตัวเลือกใหม่ เส้นทางเนมสเปซผู้ใช้ซึ่งช่วยให้คุณเชื่อมโยงไดรฟ์กับเนมสเปซของผู้ใช้โดยการระบุพาธใน /procใน systemd-nspawn คำสั่งดังกล่าวปรากฏขึ้น NamespacePath ในส่วนนั้น ใช้ไฟล์ .nspawn เพื่อระบุเน็ตเวิร์กเนมสเปซที่จะใช้

ส่วนประกอบอื่น ๆ เช่น systemd-sysext และ systemd-confext มีไฟล์การกำหนดค่าเฉพาะ en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confตัวแปรสิ่งแวดล้อม SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS ฟังก์ชันเหล่านี้ช่วยให้คุณสามารถปรับแต่งตัวเลือกการติดตั้งสำหรับโอเวอร์เลย์ได้

ในโลกของ udev ได้มีการเพิ่มตัวเลือกนี้เข้ามา OPTIONS=»dump-json» to systemd-udevd ฟังก์ชันนี้ใช้สำหรับแสดงสถานะปัจจุบันของเหตุการณ์ในรูปแบบ JSON net_id โปรแกรมนี้จะสร้างชื่อที่คาดเดาได้สำหรับอินเทอร์เฟซไร้สายบนระบบที่มี DeviceTree และสร้างลิงก์เชิงสัญลักษณ์ /dev/gpio/by-id/... สำหรับอุปกรณ์ GPIO

ส่วนผู้ใช้และบัญชีผู้ใช้กำลังได้รับการปรับปรุงให้ดียิ่งขึ้น: ฐานข้อมูลผู้ใช้มีฟิลด์ UUID อยู่ด้วยยูทิลิตี้ userdbctl รองรับตัวเลือก "-uuid" เพื่อค้นหาตามตัวระบุนี้ และ homectl update ขณะนี้รองรับการใช้ "--recovery-key" เพื่อเพิ่มรหัสกู้คืนให้กับบัญชีที่มีอยู่แล้ว

ใน systemd-homed ตัวเลือก "--prompt-shell" และ "--prompt-groups"จะถูกรวมเข้าไว้ในระหว่างการบูตครั้งแรกโดยใช้ systemd-homed-firstboot.service และใน systemd-firstboot ตัวเลือก "--prompt-keymap-auto" จะปรากฏขึ้นเพื่อถามหาแผนผังแป้นพิมพ์เมื่อใช้คอนโซลภายในเครื่องในระหว่างการบูตครั้งแรก

El ตัวจัดการการบูต systemd-boot เพิ่มความสามารถในการกำหนดระดับรายละเอียดของบันทึก (log) พร้อมพารามิเตอร์ log-level en loader.conf หรือด้วยฟิลด์ SMBIOS io.systemd.boot.loglevelนอกจากนี้ ยังมีการรวบรวมข้อกำหนดที่เข้มงวดมากขึ้นสำหรับพาร์ติชั่นต่างๆ เช่น XBOOTLDR ซึ่งปัจจุบันต้องอยู่ในรูปแบบ VFAT เพื่อให้สอดคล้องกับข้อกำหนดที่มีอยู่แล้วสำหรับ ESP ในระบบ UEFI รุ่นใหม่ๆ

ในระดับเครือข่ายขั้นสูงsystemd-networkd จะเพิ่มตัวเลือก EmitDomain และ Domain สำหรับเซิร์ฟเวอร์ DHCPและใช้งานตัวควบคุมที่กำหนดชื่อโฮสต์ที่ออกผ่าน DHCP โดยใช้การแก้ไข DNS ในขณะเดียวกัน systemd-modules-load จะโหลดโมดูลเคอร์เนลแบบขนานซึ่งช่วยลดเวลาในการบูตบนระบบที่มีไดรเวอร์จำนวนมาก

สุดท้าย ในส่วนของการตรวจสอบความสมบูรณ์ของระบบ systemd-integrity-setup เพิ่มการรองรับอัลกอริธึม HMAC-SHA256, PHMAC-SHA256 และ PHMAC-SHA512ซึ่งเป็นการขยายขอบเขตของตัวเลือกการเข้ารหัสลับที่มีอยู่เพื่อปกป้องความสมบูรณ์ของระบบ

ด้วยการเปลี่ยนแปลงทั้งหมดนี้ systemd 259 ตอกย้ำตำแหน่งของตนเองในฐานะเวอร์ชันที่มีความซับซ้อนทางเทคนิคสูง มีความต้องการสูง และมุ่งเน้นอนาคตอย่างชัดเจนมันผลักดันให้ผู้ใช้ละทิ้งเทคโนโลยีเก่าๆ เช่น SysV init, iptables และ TPM 1.2 เสริมความแข็งแกร่งด้านความปลอดภัยและการควบคุมทรัพยากร ปรับปรุงความยืดหยุ่นภายใน และเปิดประตูสู่การกำหนดค่าใหม่ๆ ด้วย musl แม้ว่าจะยังจำกัดและมีเงื่อนไขก็ตาม สำหรับผู้ใช้ทั่วไปที่ใช้ระบบปฏิบัติการเวอร์ชันอัปเดตย่อย ฟีเจอร์ใหม่เหล่านี้ส่วนใหญ่แทบจะไม่เป็นที่สังเกต แต่สำหรับผู้ดูแลระบบและโครงการที่ใช้เวอร์ชันล่าสุดอยู่ตลอดเวลา ถึงเวลาแล้วที่จะต้องตรวจสอบสคริปต์ หน่วย และข้อกำหนดของฮาร์ดแวร์อย่างรอบคอบก่อนที่จะเปลี่ยนไปใช้เวอร์ชันใหม่