Systemd 260: TPM2, แซนด์บ็อกซ์ และความสามารถใหม่ใน Linux

คู่มือฮาร์ดแวร์ » คู่มือการซื้อ » Systemd 260: TPM2, แซนด์บ็อกซ์ และความสามารถใหม่ใน Linux

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

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

กล่าวคำอำลาครั้งสุดท้ายแก่ System V และการพึ่งพาไดรฟ์ดั้งเดิมโดยสิ้นเชิง

หนึ่งในความเปลี่ยนแปลงที่โดดเด่นที่สุดใน systemd 260 คือการลบการสนับสนุนสคริปต์ System Vออกอย่างสิ้นเชิง กระบวนการบูตแบบคลาสสิกที่ใช้ /etc/init.d นั้นถูกยกเลิกไปนานแล้ว แต่ตอนนี้มันหายไปจากโค้ด systemd อย่างแท้จริง

หมายความว่าส่วนประกอบที่ทำหน้าที่เชื่อมต่อระหว่างสคริปต์ SysV และหน่วยพื้นฐานได้ถูกลบออกไปแล้ว ได้แก่systemd-rc-local-generator, rc-local.service, systemd-sysv-generator และ systemd-sysv-install ซึ่งไม่มีอยู่อีกต่อไปแล้ว ส่งผลให้บริการใดๆ ที่ยังคงพึ่งพากลไกเดิมเหล่านี้จะไม่สามารถเริ่มต้นทำงานได้บนระบบที่ใช้ systemd 260

ในระหว่างกระบวนการปรับปรุงระบบ ตัวเลือกการสร้าง Meson หลายตัวถูกทำเครื่องหมายว่าล้าสมัยหรือถูกลบออกไปแล้ว แฟล็ก-Drc-local=, -Dsysvinit-path= และ -Dsysvrcnd-path=ถูกย้ายไปเก็บในคลังข้อมูล ในขณะที่แฟล็กอื่นๆ เช่น-Dintegration-tests= และ -Dcryptolib=ถูกลบออกไปทั้งหมด นี่เป็นการส่งสัญญาณที่ชัดเจนว่า ทุกอย่างจะต้องได้รับการจัดการโดยหน่วยพื้นฐานและโครงสร้างพื้นฐาน systemd ที่ทันสมัยแล้ว

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

ความต้องการเคอร์เนลที่สูงขึ้นและการมุ่งเน้นไปที่สภาพแวดล้อมปัจจุบัน

เวอร์ชันใหม่นี้ยกระดับมาตรฐานของเคอร์เนลขึ้นไปอีกขั้น: จากนี้ไปเวอร์ชัน Linux ขั้นต่ำที่รองรับคือ 5.10ซึ่งทิ้งเวอร์ชันเก่าๆ อย่าง 5.4 ไว้เบื้องหลัง นอกจากนี้ โครงการยังระบุว่า ผู้ใช้ควรใช้งานเคอร์เนลเวอร์ชัน 5.14 หรือสูงกว่าและโดยเฉพาะอย่างยิ่งแนะนำซีรีส์ 6.6เพื่อใช้ประโยชน์จากคุณสมบัติที่มีอยู่ทั้งหมดได้อย่างเต็มที่

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

ในทางตรงกันข้าม ระบบปฏิบัติการแบบ Rolling Release เช่น Arch Linux หรือ openSUSE Tumbleweed ซึ่งได้รับความนิยมอย่างมากในหมู่ผู้ที่ต้องการคุณสมบัติล่าสุด มักจะรวมเอาเคอร์เนลใหม่และสาขาใหม่ของ systemd เข้ามาอย่างรวดเร็ว ในขณะที่ระบบปฏิบัติการอื่นๆ เช่น Fedora รักษาความเสถียรของเวอร์ชันหลักของ systemd ตลอดวงจรชีวิตของแต่ละรุ่น ซึ่งช่วยให้มีเวลามากขึ้นในการวางแผนการย้ายระบบ

TPM2, ความสมบูรณ์ของการบูต และการรองรับ SRK ขั้นสูง

หนึ่งในด้านที่ systemd พัฒนามากที่สุดคือการบูรณาการกับTPM2 (Trusted Platform Module 2.0)ชิปนี้ซึ่งพบได้ทั่วไปมากขึ้นในเมนบอร์ด UEFI รุ่นใหม่ๆ และฮาร์ดแวร์ระดับกลางและระดับสูง ช่วยให้สามารถผูกข้อมูลลับเข้ากับสถานะของระบบ วัดขั้นตอนการบูต และปลดล็อกไดรฟ์ที่เข้ารหัสโดยอัตโนมัติ เมื่อสภาพแวดล้อมเป็นไปตามที่คาดไว้

Systemd 260 เพิ่มประสิทธิภาพการทำงานร่วมกันนี้ให้ดียิ่งขึ้นไปอีก โดยเพิ่มเครื่องมือและบริการที่ครอบคลุมขั้นตอนต่างๆ ของกระบวนการบูต ส่วนประกอบสำคัญคือsystemd-tpm2-setupซึ่งมีหน้าที่เตรียมโครงสร้างพื้นฐานรอบๆStorage Root Key (SRK) ของ TPM คีย์หลักนี้ทำหน้าที่เป็นรากฐานทางด้านการเข้ารหัสเพื่อรักษาความปลอดภัยในการสื่อสารกับชิป และเพื่อจัดเก็บความลับอื่นๆ อย่างปลอดภัย

ระหว่างการบูต ระบบจะแบ่งออกเป็นสองขั้นตอน คือ ขั้นตอนแรกใน initrd และขั้นตอนที่สองเมื่อระบบรูทเข้าสู่ระบบแล้ว ในขั้นตอนแรก บริการที่เรียกว่า "Early TPM SRK Setup" จะตรวจสอบว่า TPM มี SRK ที่จัดเก็บไว้แล้วหรือไม่ และหากไม่มีอยู่ ก็จะสร้างขึ้นและทำให้สามารถใช้งานได้ชั่วคราวที่/run/systemd/tpm2-srk-public-key.*ต่อมา เมื่อระบบไฟล์จริงถูกเมานต์แล้ว บริการนี้จะรวม SRK และตรวจสอบว่าคีย์ที่จัดเก็บไว้ใน/var/lib/systemd/tpm2-srk-public-key.pemตรงกับคีย์ใน TPM หรือไม่

ในสถานการณ์ที่มีการตั้งค่าอย่างถูกต้อง ระบบจะแสดงข้อความในบันทึก เช่น"SRK ถูกจัดเก็บไว้ใน TPM แล้ว"และข้อความที่ระบุว่ารูปแบบ SRK ตรงกับที่คาดไว้ อย่างไรก็ตาม หากสภาพแวดล้อมไม่ได้ตั้งค่าอย่างถูกต้อง (ตัวอย่างเช่น ในการตั้งค่าที่ใช้ Yocto หรือบนบอร์ดอย่าง Raspberry Pi ที่มี TPM แบบ SPI และวิธีการบูตแบบกำหนดเอง เช่น U-Boot และการบูตแบบวัดค่า) อาจเกิดสถานการณ์ที่ systemd ไม่สามารถสร้างไฟล์เหล่านี้ภายใต้ /var/lib/systemd ได้ ทำให้เกิดข้อสงสัยว่า SRK ได้รับการตั้งค่าอย่างถูกต้องหรือไม่

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

นอกเหนือจาก SRK แล้ว การปรับปรุงที่ใช้งานได้จริงอีกอย่างหนึ่งคือการเพิ่มยูทิลิตี้ภายในที่เรียกว่าtpm2_id ใน udev เครื่องมือแบบบูรณาการนี้จะทำงานเมื่อระบบตรวจพบอุปกรณ์ TPM2 และจะดึงข้อมูลผู้ผลิตและรหัสรุ่นโดยอัตโนมัติซึ่งจะช่วยลดความซับซ้อนของรายการฮาร์ดแวร์ด้านความปลอดภัย ซึ่งมีประโยชน์อย่างมากในหน่วยงานภาครัฐ บริษัทที่อยู่ภายใต้การกำกับดูแล หรือโครงสร้างพื้นฐานที่สำคัญ ซึ่งจำเป็นต้องทราบอย่างแม่นยำว่ามีการใช้งานโมดูล TPM ใดบ้าง

การบูรณาการกับโครงสร้างพื้นฐานการวัดการบูตได้รับการเสริมความแข็งแกร่งยิ่งขึ้นด้วยหน่วยเฉพาะ เช่นsystemd-pcrextendซึ่งบันทึกเหตุการณ์ต่างๆ เช่น "enter-initrd", "leave-initrd", "sysinit" และ "ready" ใน PCR ต่างๆ (เช่น PCR 11) ลำดับของส่วนขยายเหล่านี้ช่วยให้ TPM สามารถสะสมบันทึกที่ตรวจสอบได้ทางคริปโตกราฟีของกระบวนการบูต ซึ่งสามารถนำไปใช้กับนโยบาย Trusted Boot หรือUKI (Unified Kernel Images)เพื่อตรวจสอบสถานะของเครื่องก่อนที่จะปล่อยคีย์ได้

มาตรการรักษาความปลอดภัยและการแยกบริการออกจากสภาพแวดล้อมด้วย systemd

Systemd ไม่เพียงแต่เริ่มต้นกระบวนการทำงานเท่านั้น แต่ยังนำเสนอชุดคำสั่งแซนด์บ็อกซ์ที่ ครอบคลุม เพื่อแยกบริการและจำกัดความเสียหายในกรณีที่มีการบุกรุก แนวทางการป้องกันเชิงลึกนี้อาศัย cgroups, namespaces, ความสามารถของเคอร์เนล และตัวกรองการเรียกใช้ระบบ (seccomp)

เพื่อประเมินความปลอดภัยของบริการเฉพาะ ระบบ systemd มี เครื่องมือ วิเคราะห์ความปลอดภัย systemd-analyzeการเรียกใช้เครื่องมือนี้จะสร้างรายงานที่มีคะแนนความเสี่ยงในระดับ 0 ถึง 10 โดยคะแนนที่ต่ำกว่าจะดีกว่า รายงานจะแสดงรายละเอียดว่าการป้องกันใดบ้างที่เปิดใช้งานหรือปิดใช้งาน (การแยกเครือข่าย การเข้าถึงระบบไฟล์ การเข้าถึงอุปกรณ์ ฯลฯ) ทำให้ง่ายต่อการระบุการตั้งค่าที่ขาดหายไปและตรวจสอบว่าการเปลี่ยนแปลงช่วยปรับปรุงคะแนนได้จริงหรือไม่

แทนที่จะแก้ไขหน่วยต้นฉบับ ซึ่งจะหายไปในการอัปเดตแพ็กเกจในอนาคต ขอแนะนำให้สร้างหน่วยใหม่ แทนที่ en /etc/systemd/system/mi-servicio.service.d/ ตัวอย่างเช่น ด้วยไฟล์ sandbox.confหลังจากแก้ไขเสร็จแล้ว ก็เพียงแค่โหลดการตั้งค่าใหม่ด้วย systemcat-daemon-reload และเริ่มให้บริการอีกครั้งเพื่อให้ข้อจำกัดใหม่มีผลบังคับใช้

ในระดับระบบไฟล์ หนึ่งในตัวเลือกที่สำคัญที่สุดคือ ปกป้องระบบ =ค่าต่างๆ เช่น strict, full o true พวกเขาติดตั้งส่วนต่างๆ ของโครงสร้างต้นไม้ในโหมดอ่านอย่างเดียว โดยปกติแล้ว หากเป็นไปได้ จะใช้ ProtectSystem=strictการตั้งค่านี้จะทำให้ /usr, /boot, /efi และ /etc เป็นแบบอ่านอย่างเดียวสำหรับบริการ หากแอปพลิเคชันใดต้องการเขียนข้อมูลลงในไดเร็กทอรีเฉพาะ ก็สามารถทำได้โดยใช้การตั้งค่านี้ เส้นทางการอ่านและเขียน = /path เป็นน้ำหนึ่งใจเดียวกัน

เพื่อเพิ่มความเป็นส่วนตัวให้มากยิ่งขึ้น ขอแนะนำให้จำกัดการเข้าถึงไดเร็กทอรีของผู้ใช้โดยใช้`ProtectHome=true`ซึ่งจะป้องกันไม่ให้บริการอ่าน `/home`, `/root` หรือ `/run/user` นอกจากนี้`PrivateTmp=true`จะสร้างพื้นที่ `/tmp` และ `/var/tmp` ที่แยกต่างหาก ป้องกันการมองเห็นไฟล์ชั่วคราวระหว่างกระบวนการต่างๆ

ในอุปกรณ์ต่างๆ`PrivateDevices=true`จะซ่อนโครงสร้าง `/dev` จริงๆ และแทนที่ด้วยชุดอุปกรณ์เสมือนที่ปลอดภัยขั้นต่ำ (null, zero, random เป็นต้น) หากไดรฟ์ต้องการอุปกรณ์เฉพาะ (เช่น พอร์ตอนุกรมหรือบล็อกดิสก์) สามารถให้สิทธิ์ได้โดยใช้`DeviceAllow=/dev/xxx rw`หรือในโหมดอ่านอย่างเดียว

เครือข่ายก็เป็นปัจจัยสำคัญเช่นกัน ด้วย เครือข่ายส่วนตัว=จริง มีการสร้างเน็ตเวิร์กเนมสเปซแบบแยกเดี่ยว โดยเหลือไว้เพียงลูปแบ็กเท่านั้น บริการจะไม่เห็นอินเทอร์เฟซทางกายภาพและจะไม่สามารถสื่อสารกับโลกภายนอกได้ หรืออีกทางเลือกหนึ่ง คุณสามารถจำกัดตระกูลแอดเดรสที่สามารถใช้งานได้โดย จำกัดที่อยู่ครอบครัว=อนุญาตเฉพาะ AF_INET และ AF_INET6 สำหรับ IPv4/IPv6, AF_UNIX สำหรับซ็อกเก็ตภายใน หรือแม้แต่ none เพื่อนำความสามารถของเครือข่ายแบบญี่ปุ่นมาใช้ให้เต็มรูปแบบ

ในส่วนของสิทธิ์ การเข้าถึง คำสั่ง `NoNewPrivileges=true`เป็นหนึ่งในคำสั่งที่มีประสิทธิภาพมากที่สุด: มันป้องกันไม่ให้กระบวนการได้รับสิทธิ์ใหม่ผ่านไบนารี setuid หรือการเปลี่ยนแปลงความสามารถ กล่าวโดยสรุป แม้ว่าบริการจะเรียกใช้โค้ดที่มีช่องโหว่ มันก็ไม่ควรจะสามารถยกระดับสิทธิ์ไปถึงระดับ root ผ่านกลไกแบบดั้งเดิมได้ เมื่อรวมกับ`CapabilityBoundingSet=`ซึ่งกำหนดรายการความสามารถที่อนุญาตอย่างแม่นยำ (ตัวอย่างเช่น เฉพาะ `CAP_NET_BIND_SERVICE` เท่านั้นที่จะรับฟังพอร์ตต่ำ) พื้นที่การโจมตีก็จะลดลงเหลือน้อยที่สุด

ยิ่งไปกว่านั้น systemd ยังอนุญาตให้กรองการเรียกใช้ระบบได้ด้วย ตัวกรองการโทรของระบบ=แทนที่จะจัดทำรายการ syscall ด้วยตนเอง จะใช้กลุ่มที่กำหนดไว้ล่วงหน้า เช่น @system-service, @network-io, @basic-io หรือปฏิเสธกลุ่มต่างๆ เช่น ~@privileged. กับ systemd-analyze syscall-filter สามารถตรวจสอบได้ว่าการเรียกใช้งานใดบ้างที่เป็นของแต่ละกลุ่ม ซึ่งช่วยให้สามารถสร้างโปรไฟล์การดำเนินการที่จำกัดมาก คล้ายกับสิ่งที่แซนด์บ็อกซ์เฉพาะทางนำเสนอ

การตั้งค่าอื่นๆ ที่เกี่ยวข้อง ได้แก่`ProtectKernelTunables=true`ซึ่งจะบล็อกการแก้ไขพารามิเตอร์เคอร์เนลใน `/proc/sys` และ `/sys`; `ProtectKernelModules=true`ซึ่งจะป้องกันการโหลดหรือยกเลิกการโหลดโมดูล; `ProtectKernelLogs=true`ซึ่งจะป้องกันการอ่านบันทึกเคอร์เนล; และ`ProtectControlGroups=true`ซึ่งจะบล็อกการเขียนไปยังลำดับชั้น cgroups ทั้งหมดนี้ทำงานได้อย่างราบรื่นกับความสามารถในการแยกผู้ใช้แบบใหม่ เช่น ` PrivateUsers=full`ซึ่งในเวอร์ชัน 260 ได้รับการอัปเดตให้แมปช่วงรหัสผู้ใช้ทั้งหมด ทำให้ไม่จำเป็นต้องใช้วิธีแก้ปัญหาแบบเดิมสำหรับสภาพแวดล้อม systemd ที่ซ้อนกันอีกต่อไป

ผู้ใช้ส่วนตัว, xaccess และการควบคุมการเข้าถึงอุปกรณ์ใหม่

กลไกPrivateUsersซึ่งออกแบบมาเพื่อให้บริการต่างๆ สามารถทำงานในพื้นที่รหัสผู้ใช้ที่แยกต่างหาก ได้ถูกรวมเข้าไว้ใน systemd เวอร์ชัน 260 แล้ว ตัวเลือก PrivateUsers=fullตอนนี้จะแมปตัวระบุทั้งหมด ทำให้สิ่งต่างๆ ง่ายขึ้นในคอนเทนเนอร์และบนระบบที่มีอินสแตนซ์ systemd แบบซ้อนกันซึ่งใช้เวอร์ชันเก่ากว่า (ก่อนเวอร์ชัน 257) การปรับปรุงนี้ได้กำจัดวิธีการแก้ไขปัญหาเฉพาะหน้าที่เคยใช้ในการตรวจจับอินสแตนซ์เก่าเหล่านี้

ในขณะเดียวกัน ส่วนประกอบต่างๆ เช่นsystemd-logind และ systemd-udevdได้นำแนวคิดของxaccess มาใช้ กลไกนี้เสริมตรรกะแบบดั้งเดิมของuaccessซึ่งให้สิทธิ์การเข้าถึงอุปกรณ์บางอย่าง (เช่น เสียงหรือวิดีโอ) แก่ผู้ใช้ที่มีเซสชันกราฟิกที่ทำงานอยู่เบื้องหน้าบนเครื่องโลคัล ด้วย xaccess สิทธิ์สามารถมอบหมายให้กับผู้ใช้ระยะไกลที่มีเซสชันที่ทำเครื่องหมายไว้เป็นพิเศษได้ตัวอย่างเช่น ผู้ใช้ที่เชื่อมต่อผ่านเดสก์ท็อประยะไกลสามารถเข้าถึงอุปกรณ์เรนเดอร์ GPU ในเครื่องได้โดยไม่ต้องให้สิทธิ์อย่างกว้างขวางแก่ทั้งระบบ

การกำหนดค่าเซสชันเหล่านี้เกี่ยวข้องกับตัวแปรสภาพแวดล้อมที่เปิดเผยผ่าน PAM โดยเฉพาะอย่างยิ่งPAMXDG_SESSION_EXTRA_DEVICE_ACCESS=ซึ่งช่วยให้สามารถกำหนดได้ว่าอุปกรณ์ใดบ้างที่จะรวมอยู่ในตรรกะนี้ แนวทางนี้สอดคล้องอย่างยิ่งกับข้อกำหนดด้านการปฏิบัติตามกฎระเบียบและการคุ้มครองข้อมูลของสหภาพยุโรป ซึ่งต้องการความละเอียดและความสามารถในการตรวจสอบย้อนกลับสำหรับการเข้าถึงฮาร์ดแวร์ที่ละเอียดอ่อน

mstack, systemd-mstack และเครื่องมือคอนเทนเนอร์ใหม่ๆ

ในด้านการใช้งานคอนเทนเนอร์นั้น systemd 260 ได้นำเสนอฟังก์ชันการทำงานใหม่ เอ็มสแต็ก และคำสั่งที่เกี่ยวข้อง ซิสเต็มดี-เอ็มสแต็กแนวคิดเบื้องหลัง mstack คือการอนุญาตให้กำหนด โอเวอร์เลย์FS โดยอิงตามโครงสร้างของไดเร็กทอรีพิเศษที่เรียกว่า .mstack/ซึ่งเป็นไปตามข้อกำหนดเฉพาะสำหรับการจัดระเบียบเลเยอร์ต่างๆ

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

เครือข่าย: การผสานรวมกับ ModemManager และตัวเลือกประสิทธิภาพใหม่

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

เพื่อรองรับการทำงานนี้ จึงมีการเพิ่มส่วนใหม่เข้าไป ไปยังไฟล์การกำหนดค่า พร้อมพารามิเตอร์ต่างๆ เช่น APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=สิ่งนี้ช่วยอำนวยความสะดวกในการใช้งานใน พื้นที่ชนบทหรือสภาพแวดล้อมที่มีการเชื่อมต่อผ่านเครือข่ายโทรศัพท์มือถือพบเห็นได้ทั่วไปในบางพื้นที่ของยุโรปที่ไม่ได้มีโครงข่ายใยแก้วนำแสงหรือสายโทรศัพท์พื้นฐานที่มีคุณภาพเสมอไป

ในแง่ของประสิทธิภาพ ไฟล์ . link ของ systemd-networkd มีตัวเลือกใหม่สำหรับอุปกรณ์อีเธอร์เน็ตโดยเฉพาะ ซึ่งได้แก่ ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList และ GenericReceiveOffloadUDPForwardingตัวเลือกเหล่านี้ช่วยให้สามารถปรับแต่งการถ่ายโอนงานไปยังฮาร์ดแวร์และไดรเวอร์ได้อย่างละเอียด ซึ่งมีความสำคัญอย่างยิ่งในเครือข่ายองค์กร ศูนย์ข้อมูล และผู้ให้บริการที่ต้องการลดความหน่วงแฝงให้น้อยที่สุดในทุกมิลลิวินาที

นอกจากนี้ อินเทอร์เฟซVarlink และ JSON ของ systemd-networkd ยังสามารถรายงานที่อยู่ IP ใน รูปแบบ ที่อ่านง่าย (สตริง) ในขณะที่ยังคงรักษาการแสดงผลในรูปแบบอาร์เรย์จำนวนเต็ม ซึ่งช่วยลดความซับซ้อนในการผสานรวมกับแดชบอร์ดการตรวจสอบ สคริปต์การจัดการ หรือเครื่องมือของบุคคลที่สามที่ไม่ต้องการจัดการกับรูปแบบตัวเลขที่เข้าใจยาก

การพกพาบริการ เครื่องเสมือนชั่วคราว และบริการที่ไม่ต้องใช้สิทธิ์พิเศษ

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

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

ในทางกลับกันsystemd-vmspawnซึ่งเป็นเครื่องมือที่ออกแบบมาเพื่อสร้างเครื่องเสมือนในลักษณะที่ผสานรวมกับ systemd ได้ขยายขีดความสามารถในการลงทะเบียนกับsystemd-machined ภายในเซสชันของผู้ใช้ นอกจากนี้ยังแนะนำ ตัวเลือก`-ephemeral`เพื่อสร้างเครื่องเสมือนชั่วคราวที่จะถูกทำลายเมื่อใช้งานเสร็จสิ้น ซึ่งเหมาะอย่างยิ่งสำหรับไปป์ไลน์ CI/CD ห้องเรียนเสมือนจริง หรือแพลตฟอร์มการศึกษาของยุโรปที่ต้องการการสร้างและการทำลายเครื่องเสมือนอย่างรวดเร็วและควบคุมได้

การควบคุม CPU หน่วยความจำ และการจัดตารางเวลาอย่างละเอียดด้วย SCHED_EXT และ THP

Systemd 260 ยังเจาะลึกไปถึงการควบคุมประสิทธิภาพด้วยนโยบายใหม่ๆ ตัวเลือกบริการ นโยบายการจัดตารางเวลา CPU = ตอนนี้ยอมรับค่าแล้ว extซึ่งจะเปิดใช้งานตัวกำหนดตารางเวลา กำหนดไว้_EXTนักวางแผนทางเลือกนี้เปิดประตูสู่ การทดลองกับนโยบายการวางแผนที่แตกต่างกัน ตามมาตรฐานของเคอร์เนล ซึ่งอาจเป็นสิ่งที่น่าสนใจในห้องปฏิบัติการวิจัยและพัฒนา หรือในการใช้งานเฉพาะทางขั้นสูง

ในส่วนของหน่วยความจำ คุณจะพบ`MemoryTHP=`ซึ่งช่วยให้คุณจัดการการใช้งานTransparent Huge Pages (THP)ในแต่ละบริการได้ แทนที่จะตั้งค่าแบบทั่วทั้งระบบ คุณสามารถตัดสินใจได้ว่าหน่วยเฉพาะนั้นควรใช้ THP หรือไม่ ปิดใช้งาน หรือใช้โหมดกลาง สำหรับแอปพลิเคชันที่สำคัญในด้านการธนาคาร การประกันภัย หรือภาครัฐ การควบคุมแบบละเอียดนี้สามารถสร้างความแตกต่างอย่างมากในด้านความหน่วง การใช้หน่วยความจำ และประสิทธิภาพ

คำสั่งใหม่ใน systemctl และการใช้งาน Varlink ที่ขยายเพิ่มเติม

คำสั่งsystemctl ที่คุ้นเคยได้ เพิ่มคำสั่งใหม่เข้ามา: enqueue-markedการกระทำนี้จะเรียกใช้เมธอดEnqueueMarkedJobs() ของ D-Bus ภายใน และอนุญาตให้ทำงานกับคิวของงานและบริการที่ถูกทำเครื่องหมายไว้ล่วงหน้า แม้ว่าอาจดูเหมือนเป็นรายละเอียดเล็กน้อย แต่สำหรับทีมปฏิบัติการที่จัดการฟาร์มเซิร์ฟเวอร์ขนาดใหญ่มันเป็นอีกเครื่องมือหนึ่งในการปรับปรุงเวิร์กโฟลว์การปรับใช้และการทำงานอัตโนมัติให้ดียิ่งขึ้น

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

ช่องระบุระบบและประสบการณ์ผู้ใช้

คุณสมบัติใหม่ที่น่าสนใจแต่มีประโยชน์สำหรับบางการแจกแจงคือการแนะนำฟิลด์ ชื่อแฟนซี = ในที่เก็บถาวร /etc/os-releaseช่องนี้มีลักษณะคล้ายกับ PRETTY_NAME แต่สามารถอนุญาตให้ใช้งานได้ ลำดับ ANSI และอักขระ Unicode ที่ซับซ้อนยิ่งขึ้นด้วยเหตุนี้ การจัดจำหน่ายและฉบับพิมพ์เฉพาะจึงสามารถนำเสนอด้วยชื่อที่ดึงดูดสายตาหรือโดดเด่นยิ่งขึ้นได้

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

เอกสารเฉพาะสำหรับตัวแทน AI และขั้นตอนการทำงานการตรวจสอบโดยความช่วยเหลือ

หนึ่งในสัญญาณที่น่าสนใจที่สุดเกี่ยวกับทิศทางการพัฒนาของ systemd คือการปรากฏตัวของเอกสารที่มุ่งเน้นไปที่เอเจนต์ปัญญาประดิษฐ์ โดยเฉพาะ ในคลังเก็บโค้ดมี ไฟล์ AGENTS.mdซึ่งออกแบบมาเพื่อช่วยให้เครื่องมือวิเคราะห์โค้ดและผู้ช่วยการเขียนโปรแกรม รวมถึงคู่มือทางเทคโนโลยี บางส่วน เข้าใจสถาปัตยกรรม รูปแบบ กระบวนการพัฒนา และแนวทางการมีส่วนร่วมของโครงการได้ดียิ่งขึ้น

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

นอกจากไฟล์ AGENTS.md แล้ว ยังมีไฟล์ชื่อCLAUDE.mdซึ่งอ้างอิงถึงไฟล์ก่อนหน้าอย่างชัดเจน และออกแบบมาเพื่อเป็นแนวทางให้กับเครื่องมือ Claude Code ซึ่งเป็นหนึ่งในผู้ช่วยพัฒนาซอฟต์แวร์ที่ใช้ AI อย่างแพร่หลายที่สุด ด้วยวิธีนี้ โครงการจึงได้ผนวกรวม AI เข้าสู่กระบวนการพัฒนาอย่างชัดเจน

นอกจากนี้ ยังมีไฟล์การตั้งค่ารวมอยู่ด้วย คลอเด-รีวิว.ymlโดยกำหนดวิธีการตรวจสอบกระบวนการวิเคราะห์คำขอเปลี่ยนแปลง (pull request) โดยใช้ Claude Code เป็นตัวช่วย ในบริบทนี้ ผลงานที่ใช้ AI จำเป็นต้องบูรณาการ AI เข้าไปด้วย ฉลากการเปิดเผยข้อมูล ในขณะที่ Co-developed-by ในส่วนที่เป็นแพทช์นั้น ทิ้งหลักฐานไว้ว่าเครื่องมืออัตโนมัติได้มีส่วนร่วมในการสร้างโค้ด

ด้วยการเปลี่ยนแปลงที่ครอบคลุมเหล่านี้—การปรับปรุงการสนับสนุนระบบเก่า การปรับปรุงแซนด์บ็อกซ์ การพัฒนา TPM2 และ SRK การบูรณาการเครือข่ายขั้นสูง ความสามารถในการพกพาแบบใหม่ และเอกสารประกอบที่ออกแบบมาสำหรับเอเจนต์อัจฉริยะ—systemd 260ตอกย้ำบทบาทสำคัญในระบบนิเวศ Linux สมัยใหม่ สำหรับผู้ดูแลระบบและนักพัฒนาในสเปนและยุโรป ความท้าทายเร่งด่วนคือการตรวจสอบเคอร์เนล การปรับแต่งการกำหนดค่าการบูตและบริการ และการใช้ประโยชน์จากคุณสมบัติเหล่านี้เพื่อสร้างโครงสร้างพื้นฐานที่ปลอดภัยและอัตโนมัติมากขึ้น ซึ่งสอดคล้องกับการใช้งานระบบในปัจจุบัน