systemd 259: שינויים עיקריים ודרישות מערכת

אינפורמטק דיגיטל » Recursos » systemd 259: שינויים עיקריים ודרישות מערכת

שחרור systemd 259 כגרסה יציבה מייצג תפנית נוספת באחד המרכיבים השנויים ביותר במחלוקת והחיוניים של מערכת האקולוגית של לינוקס. אנו מדברים על המסגרת להפעלה וניהול שירותים שכבר שולטת ברוב ההפצות, ומהדורה זו מהדקת עוד יותר את הברגים מבחינת דרישות טכניות, אבטחה ונטישה של טכנולוגיות מדור קודם.

עדכון זה מגיע לאחר מספר חודשי עבודה אינטנסיביים ומתמקד בשלושה תחומים עיקריים: תאימות עם ספריות C חדשות, אבטחה משופרת וניקוי קוד מדור קודם (סקריפטים של SysV, TPM 1.2, iptables וכו'). הוא מציג גם שינויים משמעותיים בניהול הרשאות עם run0, טיפול בזיכרון עם systemd-oomd, אחסון יומני רישום ומודל התלות הפנימי של libsystemd.

systemd 259 ותמיכה ניסיונית עבור musl

אחת התכונות המדוברות ביותר של גרסה זו היא ש- systemd 259 משלבת, לראשונה, תמיכה חלקית בספריית musl, ספרייה סטנדרטית של C. ספרייה זו נמצאת בשימוש נרחב במערכות קלות משקל, קונטיינרים מינימליסטיים וסביבות משובצות, בהן רצויות פשטות וצריכת משאבים מופחתת בהשוואה ל-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 חשובה ברמה הסמלית: systemd ספגה ביקורת במשך שנים על תלותה הכמעט בלעדית ב-glibc , מה שהפך אותה ללא ידידותית להפצות חלופיות ותרחישים מינימליסטיים מאוד. צעד זה אינו פותר הכל, אך הוא שובר את הדימוי של מערכת סגורה לחלוטין מספריות C אחרות.

run0 ומודל ההרשאות החדש: אלטרנטיבה ל-sudo

מאפיין מרכזי נוסף של systemd 259 הוא התועלת run0, מוצע כתחליף מודרני ובטוח יותר ל-sudoכלי זה כבר נבנה על systemd-run, אך כעת הוא מקבל יכולת מפתח: האפשרות --empower.

הארגומנט החדש `--empower` מאפשר לך להתחיל הפעלה עם הרשאות מוגברות מבלי לשנות את ה-UID שלך ל-root . במקום החלפת משתמש מסורתית, `run0` ממנף יכולות ליבה (כגון `CAP_SYS_ADMIN`) כדי להעניק בדיוק את ההרשאות הדרושות לביצוע פעולות בעלות זכויות, ובכך להפחית את החשיפה של הפיכה ל-root לחלוטין.

יתר על כן, תהליכים שמתחילים בגישה זו מקובצים לקבוצת "העצמה" לוגית עם גישה למגוון רחב של פעולות המנוהלות על ידי Polkit . הרעיון הוא שהגדלת ההרשאות היא מפורטת ומבוקרת, תוך שמירה על הפרדה מחמירה יותר מזו שמציעה בדרך כלל sudo מסורתי, שבו הגישה פתוחה לעתים קרובות לרווחה מדי.

גישה זו מתיישבת עם המגמה של הימנעות משימוש ישיר במשתמש הבסיס ככל האפשר , עיקרון אבטחה מוערך מאוד. עם זאת, עדיין יש להדגים את היעילות האמיתית של run0 בסביבת הייצור: נצטרך לראות כיצד הוא משתלב עם המדיניות של כל הפצה, כיצד יכולותיו מוגדרות בפועל, וכיצד ניהול המערכת מסתגל לזרימת העבודה החדשה.

סיום התמיכה בניקוי SysV init ו-Legacy

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, הכיוון זהה: פחות תאימות לאחור בתמורה לבסיס קוד עקבי ובר-תחזוקה יותר.

דרישות מערכת מינימליות 259: ליבה, ספריות וסביבה

אחד השינויים שיכולים להשפיע בצורה הגדולה ביותר על מערכות ישנות יותר הוא העלייה בדרישות התוכנה המינימליות להפעלת systemd 259. גרסה זו כבר לא מתחשבת בחומרה או במחסניות ישנות מאוד, ודוחפת בבירור לכיוון פלטפורמות מודרניות.

בין הדרישות המרכזיות שאוחדו ב-systemd 259 נמצאות: מחויבות לפלטפורמות מודרניות

• גרסת לינוקס 5.10 לפחות (עם המלצה ללכת לפחות ל-5.14).
• glibc 2.34 כגרסה מינימלית של ספריית הסטנדרט של GNU.
• פתח את SSL 3.0.0 כבסיס חובה לפונקציות ההצפנה הנתמכות.
• util-linux 2.37 כדרישה לתועלת הבסיסית של המערכת.
• libxcrypt 4.4.0 לניהול פונקציות קריפטוגרפיות הקשורות לסיסמאות.
• cryptsetup 2.4.0 ו-libseccomp 2.4.0 עבור הצפנת אמצעי אחסון וסינון שיחות מערכת.
• פייתון 3.9.0 כתלות מינימלית בכלי עזר.
• חלק מההערות מזכירות גם elfutils 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. משתמשי לינוקס רבים מושבתים את TPM ואתחול מאובטח, כך שייתכן שהם אפילו לא ישימו לב לשינוי, אך ייתכן שתהיה לכך השפעה בסביבות ארגוניות או בסביבות אבטחה גבוהות.

בגרסאות קודמות, כמו 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()` חל גם על אינטגרציה עם תת-מערכת הביקורת של לינוקס ו-PAM . בדרך זו, אתחול systemd ותפעול רגיל יכולים להיות קלים יותר בסביבות שאינן דורשות את כל הרכיבים הללו בו זמנית.

מצד שני, הפונקציונליות שסופקה בעבר על ידי ספריית libcap שולבה ישירות ב-libsystemd . זה מבטל תלות חיצונית נוספת, מפשט את שרשרת הבנייה ומפחית נקודות פוטנציאליות של כשל או חוסר תאימות.

באופן כללי, גישה זו מספקת מודולריות טובה יותר וטביעת רגל קטנה יותר של זיכרון ודיסק , במיוחד במערכות בהן רצויים זמני אתחול מהירים ומערך שירותים צפוף.

שינויים ברשת ובקונטיינרים: להתראות iptables, שלום nftables

גם תחום הרשתות והווירטואליזציה עובר שינויים משמעותיים. החל מ-systemd 259, systemd-networkd ו-systemd-nspawn אינם תומכים עוד ביצירת כללי NAT ​​באמצעות iptables/libiptc . חומת האש האחורית הנתמכת היחידה היא nftables.

זה משפיע ישירות על קונטיינרים המנוהלים באמצעות systemd-nspawn שהסתמכו על NAT דרך iptables , כמו גם על רשתות שהוגדרו ב-systemd-networkd שהשתמשו בכללי תרגום כתובות עם ה-backend הקלאסי. בבדיקות עם תוכניות גירסה נצפו כשלים שקטים בפונקציונליות NAT עד שכל התצורה הועברה ל-nftables.

מעבר לתרגום כתובות, systemd-resolved מקבל את היכולת להשתמש ב-hooks מקומיים en /run/systemd/resolve.hook/פקודות אלו מבוצעות בכל פעם שמבוצעת שאילתת זיהוי שמות מקומית. זה פותח את הדלת להתאמות אישיות DNS מתקדמות ולוגיקה ספציפית על ידי מנהל המערכת.

בתחום ייבוא ​​וניהול תמונות, systemd-importd משלב לוגיקה מקורית לעבודה עם קבצי TAR, בהסתמך על libarchive מכלי השירות tar של GNU. יתר על כן, ניתן כעת להריץ גם systemd-importd וגם systemd-machined במצב משתמש, תוך ניהול תמונות מערכת הממוקמות ב ~/.local/state/machines/.

כדי לשלוט במצבים אלה, כלי השירות importctl מוסיף את האפשרויות "--user" ו-"--system" , מה שמאפשר לך לבחור בקלות האם לפעול בהקשר המשתמש או ברמת המערכת. גישה זו שימושית לסביבות פיתוח ובדיקה שבהן אינך רוצה לשנות את התצורה הגלובלית של המכונה.

רישום מתמיד כברירת מחדל וניהול שטח דיסק

שינוי נוסף בעל השפעה מעשית הוא שינוי ה- מצב אחסון יומן ברירת מחדל, תת-מערכת הרישום של systemd. עד כה, ההתנהגות ה"אוטומטית" הייתה תלויה בקיומה או אי קיומה של הספרייה /var/log/journal.

עם systemd 259, מצב ברירת המחדל הופך ל"persistent ", ללא קשר לשאלה האם התיקייה הייתה קיימת בעבר. משמעות הדבר היא שהיומן יישמר לצמיתות בדיסק כברירת מחדל, במקום להיות מאוחסן בזיכרון 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, ההנחיה מופיעה נתיב מרחב השמות במקטע מקבצי ה-.nspawn כדי לציין את מרחב השמות של הרשת שיש להשתמש בו.

רכיבים אחרים כגון systemd-sysext ו- systemd-confex משלבים קבצי תצורה ייעודיים en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confמשתני סביבה SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS הם מאפשרים לך להתאים את אפשרויות ההרכבה עבור שכבות-על.

בעולם ה-udev, האפשרות מתווספת אפשרויות = »dump-json» ל- systemd-udevd כדי להציג את המצב הנוכחי של אירוע בפורמט JSON, הפונקציה net_id הוא מייצר שמות צפויים עבור ממשקים אלחוטיים במערכות עם DeviceTree ויוצר קישורים סמליים. /dev/gpio/by-id/... עבור התקני GPIO.

גם מדור המשתמש והחשבון מתחזק: מסד הנתונים של המשתמשים כולל שדה UUIDכלי השירות usertdbctl תומך באפשרות "-uuid" לחיפוש לפי מזהה זה, ו- homectl update כעת הוא תומך ב-"--recovery-key" כדי להוסיף מפתחות שחזור לחשבונות קיימים.

ב-systemd-homed, האפשרויות "--prompt-shell" ו-"--prompt-groups" משולבות במהלך האתחול הראשון באמצעות systemd-homed-firstboot.service, וב-systemd-firstboot, נראה כי "--prompt-keymap-auto" מבקש את מפת המקלדת בעת שימוש בקונסולה המקומית באתחול הראשון.

El מנהל האתחול systemd-boot מוסיף את היכולת להגדיר את רמת הפירוט של היומן עם פרמטר 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, אם כי באופן חלקי ובתנאי. עבור משתמשי קצה בהפצות נקודתיות, רבות מהתכונות החדשות הללו כמעט ולא יזוהו; עבור מנהלים ופרויקטים המשתמשים כל הזמן בגרסה העדכנית ביותר, הגיע הזמן לבחון בקפידה סקריפטים, יחידות ודרישות חומרה לפני ביצוע המעבר.