ללינוקס יש פנים רבות: איך לעבוד על כל הפצה

יצירת אפליקציית גיבוי שעובדת על כל הפצה היא משימה לא פשוטה. כדי להבטיח ש-Veeam Agent עבור לינוקס עובד על הפצות מ-Red Hat 6 ו-Debian 6, ל-OpenSUSE 15.1 ו-Ubuntu 19.04, עליך לפתור מגוון בעיות, במיוחד בהתחשב בעובדה שמוצר התוכנה כולל מודול ליבה.

המאמר נוצר על סמך חומרים מנאום בכנס לינוקס פיטר 2019.

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

מנהלי חבילות. .deb לעומת .rpm

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

בעולם חבילות ה-deb רמת התאימות מדהימה. אותה חבילה מתקינה ועובדת באותה מידה גם בדביאן 6 וגם באובונטו 19.04. הסטנדרטים לתהליך בניית החבילות והעבודה איתן, שנקבעו בהפצות ישנות של דביאן, נותרו רלוונטיים ב-Linux Mint החדשנית ובמערכת ההפעלה היסודית. לכן, במקרה של Veeam Agent עבור Linux, מספיקה חבילת deb אחת לכל פלטפורמת חומרה.

אבל בעולם חבילות הסל"ד, ההבדלים גדולים. ראשית, בשל העובדה שיש שני מפיצים עצמאיים לחלוטין, Red Hat ו-SUSE, שעבורם התאימות מיותרת לחלוטין. שנית, למפיצים אלה יש ערכות הפצה מאלה. תמיכה וניסיונית. גם אין צורך בהתאמה ביניהם. התברר שלel6, el7 ו-el8 יש חבילות משלהם. חבילה נפרדת לפדורה. חבילות עבור SLES11 ו-12 וחבילה נפרדת עבור openSUSE. הבעיה העיקרית היא תלות ושמות חבילות.

בעיית תלות

לרוע המזל, אותן חבילות מגיעות לעיתים קרובות תחת שמות שונים בהפצות שונות. להלן רשימה חלקית של התלות בחבילות veeam.

עבור EL7:
עבור SLES 12:

• libblkid
• libgcc
• libstdc ++
• ncurses-libs
• פיוז-libs
• file-libs
• veeamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc ++ 6
• libmagic1
• libfuse2
• veeamsnap-kmp=3.0.2.1185

כתוצאה מכך, רשימת התלות היא ייחודית להפצה.

מה שמחמיר הוא כאשר גרסה מעודכנת מתחילה להסתתר תחת שם החבילה הישן.

לדוגמה:

החבילה עודכנה בפדורה 24 קללות מגרסה 5 לגרסה 6. המוצר שלנו נבנה עם גרסה 5 כדי להבטיח תאימות עם הפצות ישנות יותר. כדי להשתמש בגרסה החמישית הישנה של הספרייה בפדורה 5, הייתי צריך להשתמש בחבילה ncurses-compat-libs.

כתוצאה מכך, ישנן שתי חבילות עבור Fedora, עם תלות שונות.

עוד יותר מעניין. לאחר עדכון ההפצה הבא, החבילה ncurses-compat-libs עם גרסה 5 של הספרייה מסתבר שהיא לא זמינה. זה יקר למפיץ לגרור ספריות ישנות לגרסה חדשה של ההפצה. לאחר זמן מה, הבעיה חזרה על עצמה בהפצות SUSE.

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

אגב, בגרסה 8 של Red Hat כבר אין חבילת מטא פִּיתוֹן, שהתייחס לישן והטוב פיתון 2.7. יש פיתון 2 и פִּיתוֹן3.

אלטרנטיבה למנהלי חבילות

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

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

פלאטפק מאפשר לך גם להפעיל יישומים בארגז חול באמצעות Linux Containers. נעשה שימוש גם ברעיון ארגז החול AppImage.

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

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

הבעיה השנייה היא שהפצות פופולריות בסביבת הארגון מ-Red Hat ו-SUSE עדיין לא מכילות תמיכה ב-Snappy ו-Flatpak.

בהקשר זה, Veeam Agent עבור Linux אינו זמין snapcraft.io לא על flathub.org.

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

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

בעיית עדכון

גם אם כל בעיות התלות נפתרות, התוכנית עשויה לפעול אחרת באותה הפצה. זה לגבי עדכונים.

ישנן 3 אסטרטגיות עדכון:

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

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

מגוון פלטפורמות חומרה

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

בפרויקט Veeam Agent for Linux, אנחנו עדיין לא יכולים לתמוך במשהו כמו RISC זה.

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

קישור סטטי ו/או דינמי

אבל השאלה היא "כיצד לקשר עם ספריות - דינמית או סטטית?" שווה דיון.

ככלל, יישומי C/C++ תחת לינוקס משתמשות בקישור דינמי. זה עובד מצוין אם האפליקציה נבנתה במיוחד עבור הפצה ספציפית.

אם המשימה היא לכסות הפצות שונות בקובץ בינארי אחד, אז אתה צריך להתמקד בהפצה הנתמכת הוותיקה ביותר. עבורנו, זה Red Hat 6. הוא מכיל gcc 4.4, שאפילו תקן C++11 אינו תומך בו באופן מלא.

אנו בונים את הפרויקט שלנו באמצעות gcc 6.3, שתומך באופן מלא ב-C++14. באופן טבעי, במקרה זה, ב-Red Hat 6 אתה צריך לשאת את ה-libstdc++ ולהגביר איתך את הספריות. הדרך הקלה ביותר היא לקשר אליהם באופן סטטי.

אבל למרבה הצער, לא כל הספריות ניתנות לקישור סטטי.

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

שנית, יש עדינות עם רישיונות.

רישיון GPL בעצם מאפשר לך לקשר ספריות רק עם קוד פתוח. MIT ו-BSD מאפשרים קישור סטטי ומאפשרים לכלול ספריות בפרויקט. אבל נראה שה-LGPL אינו סותר קישור סטטי, אלא דורש שיתוף של הקבצים הדרושים לקישור.

באופן כללי, שימוש בקישור דינמי ימנע ממך את הצורך לספק משהו.

בניית יישומי C/C++

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

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

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

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

כך מורכבות חבילות KMOD של מודול ליבת veeamsnap עבור הפצות של Red Hat.

פתח את שירות Build

עמיתים מ-SUSE ניסו ליישם איזו דרך ביניים בצורה של שירות מיוחד להידור יישומים והרכבת חבילות - Openbuildservice.

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

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

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

בנוסף, תמיכה בהפצות אחרות - למשל, Red Hat - מיושמת בצורה גרועה למדי, וזה מובן.

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

בתשתית שלנו, באמצעות OpenBuildService, מורכב כל מגוון חבילות ה-KMP של מודול ליבת veeamsnap עבור הפצות SUSE.

לאחר מכן, ברצוני להתעכב על בעיות ספציפיות למודולי ליבה.

ליבת ABI

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

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

DKMS מאפשר לך להפוך את תהליך בניית המודולים לאוטומטי בעת עדכון הקרנל. כתוצאה מכך, משתמשים במאגר דביאן (וקרוביו הרבים) משתמשים במודולי ליבה מהמאגר של המפיץ או הידור ממקור באמצעות DKMS.

עם זאת, מצב זה אינו מתאים במיוחד לפלח ה-Enterprise. מפיצי קוד קנייניים רוצים להפיץ את המוצר כקבצים בינאריים מהודרים.

מנהלי מערכת אינם רוצים לשמור כלי פיתוח בשרתי ייצור מסיבות אבטחה. מפיצי לינוקס ארגוניים כמו Red Hat ו-SUSE החליטו שהם יכולים לתמוך ב-kABI יציב עבור המשתמשים שלהם. התוצאה הייתה חבילות KMOD עבור Red Hat וחבילות KMP עבור SUSE.

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

Red Hat טוענת לתאימות kABI להפצה לאורך כל מחזור החיים שלה. כלומר, המודול המורכב עבור rhel 6.0 (מהדורה בנובמבר 2010) אמור לעבוד גם בגרסה 6.10 (הוצאה יוני 2018). וזה כמעט 8 שנים. מטבע הדברים, משימה זו היא די קשה.
רשמנו מספר מקרים שבהם מודול veeamsnap הפסיק לעבוד עקב בעיות תאימות kABI.

לאחר שמודול veeamsnap, שהורכב עבור RHEL 7.0, התברר כלא תואם עם הליבה מ-RHEL 7.5, אך הוא נטען והובטח לקרוס את השרת, נטשנו לחלוטין את השימוש בתאימות kABI עבור RHEL 7.

נכון לעכשיו, חבילת KMOD עבור RHEL 7 מכילה assembly עבור כל גרסת מהדורה וסקריפט הטוען את המודול.

SUSE ניגש למשימה של תאימות kABI בזהירות רבה יותר. הם מספקים תאימות kABI רק בתוך Service Pack אחד.

לדוגמה, השחרור של SLES 12 התרחש בספטמבר 2014. ו-SLES 12 SP1 כבר היה בדצמבר 2015, כלומר עברה קצת יותר משנה. למרות ששתי המהדורות משתמשות בקרנל 3.12, הן אינן תואמות kABI. ברור ששמירה על תאימות kABI למשך שנה היא הרבה יותר קלה. מחזור עדכון מודול הקרנל השנתי לא אמור לגרום לבעיות עבור יוצרי המודולים.

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

תיקונים ויציאות אחוריות

למרות שמפיצים מנסים להבטיח תאימות kABI ויציבות ליבה, הם גם מנסים לשפר את הביצועים ולחסל פגמים של ליבה יציבה זו.

במקביל, בנוסף ל"עבודה על שגיאות" משלהם, מפתחי ליבת לינוקס הארגונית עוקבים אחר שינויים בליבת הווניל ומעבירים אותם ל"יציב" שלהם.

לפעמים זה מוביל לחדשים טעויות.

במהדורה האחרונה של Red Hat 6, נפלה טעות באחד העדכונים הקטנים. זה הוביל לעובדה שמודול veeamsnap היה מובטח לקרוס את המערכת כאשר תמונת המצב שוחררה. לאחר השוואה בין מקורות הליבה לפני ואחרי העדכון, גילינו שה-backport הוא אשם. תיקון דומה נעשה בגרסת הוניל גרסת 4.19. רק שהתיקון הזה עבד מצוין בגרעין הווניל, אבל כשהעבירו אותו ל-"יציב" 2.6.32, נוצרה בעיה עם הספינלוק.

כמובן שלכולם תמיד יש שגיאות, אבל האם היה שווה לגרור את הקוד מ-4.19 ל-2.6.32, להסתכן ביציבות?.. אני לא בטוח...

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

כשניסיתי לבנות מודול על ליבה 4.4 מ-SLES 12 SP3, הופתעתי למצוא בו פונקציונליות מ-vanilla 4.8. לדעתי, יישום הבלוק I/O של ליבת 4.4 מ-SLES 12 SP3 דומה יותר לליבה 4.8 מאשר המהדורה הקודמת של ליבת 4.4 היציבה מ-SLES12 SP2. אני לא יכול לשפוט איזה אחוז מהקוד הועבר מגרעין 4.8 ל-SLES 4.4 עבור SP3, אבל אני אפילו לא יכול לקרוא לקרנל אותו 4.4 יציב.

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

כתוצאה מכך, הקוד גדל עם הנחיות הידור מותנה מוזרות.

ישנם גם תיקונים שמשנים את ה-API של הליבה המתועד.
נתקלתי בהפצה ניאון KDE 5.16 והופתע מאוד לראות שהקריאה lookup_bdev בגרסת הקרנל הזו שינתה את רשימת פרמטרי הקלט.

כדי להרכיב את זה, הייתי צריך להוסיף סקריפט ל-makefile שבודק אם לפונקציה lookup_bdev יש פרמטר mask.

חתימה על מודולי ליבה

אבל נחזור לסוגיית הפצת החבילות.

אחד היתרונות של kABI יציב הוא שניתן לחתום על מודולי ליבה כקובץ בינארי. במקרה זה, המפתח יכול להיות בטוח שהמודול לא ניזוק בטעות או שונה בכוונה. אתה יכול לבדוק זאת עם הפקודה modinfo.

הפצות Red Hat ו-SUSE מאפשרות לך לבדוק את חתימת המודול ולטעון אותו רק אם התעודה המתאימה רשומה במערכת. האישור הוא המפתח הציבורי איתו חתום המודול. אנו מפיצים אותו כחבילה נפרדת.

הבעיה כאן היא שאישורים יכולים להיות מובנים בתוך הליבה (מפיצים משתמשים בהם) או שיש לכתוב אותם לזיכרון לא נדיף של EFI באמצעות כלי עזר מוקוטיל. תוֹעֶלֶת מוקוטיל בעת התקנת אישור, זה מחייב אותך לאתחל את המערכת, ועוד לפני טעינת ליבת מערכת ההפעלה, מבקש מהמנהל לאפשר טעינה של אישור חדש.

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

EFI על מכונות וירטואליות

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

לא כל היפרוויזרים תומכים ב-EFI. VMWare vSphere תומך ב-EFI החל מגרסה 5.
Microsoft Hyper-V זכתה גם לתמיכה ב-EFI החל מ-Hyper-V עבור Windows Server 2012R2.

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

ב-vSphere 6.5, הגדר את האפשרות אתחול מאובטח אפשרי רק בגרסה הישנה של ממשק האינטרנט, שפועל באמצעות פלאש. ממשק המשתמש באינטרנט ב-HTML-5 עדיין נמצא הרחק מאחור.

הפצות ניסוי

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

עם זאת, הפצות כאלה הופכות לפלטפורמה נוחה להתנסות בפתרונות ניסיוניים חדשים. לדוגמה, גרסאות Fedora, OpenSUSE Tumbleweed או Unstable של דביאן. הם די יציבים. תמיד יש להם גרסאות חדשות של תוכניות ותמיד ליבה חדשה. בעוד שנה, הפונקציונליות הניסיונית הזו עשויה להסתיים ב-RHEL, SLES או אובונטו מעודכנים.

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

אתה יכול ללמוד את הרשימה הנוכחית של ההפצות הנתמכות רשמית עבור גרסה 3.0 כאן. אבל הרשימה האמיתית של ההפצות שעליהן המוצר שלנו יכול לעבוד היא הרבה יותר רחבה.

באופן אישי, התעניינתי בניסוי עם מערכת ההפעלה Elbrus. לאחר סיום חבילת veeam, המוצר שלנו הותקן ופעל. כתבתי על הניסוי הזה על Habré ב статье.

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

מקור: www.habr.com