Outline על ARM: איזו בנייה, ומי מתחזק אותה?
תווית ARM64 עונה על שאלה אחת. החליטו מי בנה את לקוח Outline, איזה מקור הוא מייצג ומי יספק עדכונים לאחר החיבור הראשון.
תווית ARM64 פותרת שאלת תאימות אחת ומשאירה שלוש שאלות קשות יותר פתוחות. היא אינה אומרת מי הפיק את הקובץ ההרצה, מאיזו גרסת מקור הוא בא או מי יספק את תיקון האבטחה הבא. כשתשובת פורום ישנה מצביעה על בנייה קהילתית, השאלות האלה קובעות אם ההתקנה ניתנת להגנה. הפרידו ביניהן לפני שתורידו משהו.
מנהל או לקוח: בחרו תחילה את הארטיפקט הנכון
Outline מספק מנהל לניהול שרתים ולקוח לחיבור מכשירים, ואלה יישומים נפרדים. מאגר המקור מבחין בין שני התפקידים ומקשר לערוצי ההתקנה שלהם. התקנת מנהל על Raspberry Pi אינה נותנת לכם לקוח לאותו Pi. שני הערוצים גם מתעדכנים לפי לוחות זמנים שונים. שני התפקידים קיימים, ולכן השאלה היא איזה תפקיד המכשיר אמור למלא.
בדקו את ערוץ הלקוח הנוכחי עבור מערכת ההפעלה שאתם מריצים. רשומת Linux כללית אינה מטריצת ארכיטקטורות ואינה הבטחה לגבי כל לוח. קראו את עמוד ההורדה כרשימה של מה שקיים, לא כרשימה של מה שאמור להיות.
גיליון היסטורי שמבקש תמיכה ב-ARM אינו אומר דבר על מה שמפורסם היום. התייחסו אליו כתיעוד של פער מהעבר, לא כהצהרה על ההווה. הערוץ שממנו אתם יכולים להוריד הוא הראיה היחידה שנחשבת.
איזו ארכיטקטורה המערכת המותקנת מריצה באמת?
תעדו את המהדורה ואת הארטיפקט הנבדק, לא רק את שם הלוח. התאימו את הקובץ ההרצה ואת רכיביו הנייטיביים ליעד, כי ליבה של 64 סיביות יכולה להריץ מרחב משתמש של 32 סיביות והתווית על הקופסה לא תגיד לכם איזו.
קוד המקור של הלקוח מכיל קוד ממשק משותף ורכיבים ייחודיים לפלטפורמה. בנייה מחדש של הממשק בלבד אינה פורט פלטפורמה, עד כמה שהיא מתקמפלת נקי. החלקים הנייטיביים הם המקום שבו הארכיטקטורה באמת מופיעה. בנייה מחדש שנוגעת רק בממשק תרוץ ובכל זאת תיכשל בצד הנייטיבי.
uname -m וארכיטקטורת החבילה של המערכת המותקנת הם שתי העובדות שחשובות כאן. קראו אותן במכשיר, לא במכונה שממנה אתם בונים. אי-התאמה בשלב הזה פוסלת כל השוואה מאוחרת.
בנייה קהילתית מוסיפה בעל מהדורה
אם לערוץ הרשמי אין ארטיפקט נתמך ליעד שלכם, בנייה קהילתית הופכת להחלטת פריסה ולא להתקנה. זהו את המפרסם, את גרסת המקור, את השינויים לעומת המקור ואת הוראות הבנייה.
לאחר מכן שאלו איך תיקונים עתידיים מגיעים להתקנה. עדכונים עשויים לבוא מהמקור, מהענף או מבנייה ידנית שמישהו צריך לזכור להריץ. האפשרות השלישית היא זו שמפסיקה בשקט לקרות.
מאגר שנראה עדכני אינו אומר דבר על איזו גרסה הפיקה קובץ בינארי שכבר יש לכם. השוו את הוראות הבנייה למה שהארטיפקט מדווח על עצמו. אם השניים חלוקים, הארטיפקט הוא זה שאסור לבטוח בו.
מה סכום ביקורת מוכיח ומה לא
סכום ביקורת מזהה בתים מסוימים. סכום ביקורת שמפרסם אותו בונה לא רשמי אינו הופך את הבונה לפרויקט המקור, ואינו אומר לכם מה מכילים הבתים האלה. הוא עונה אם ההורדה הגיעה שלמה, וזו שאלה שימושית אך צרה. זו תכונה של הקובץ, לא של האדם שפרסם אותו.
צילום מסך של השקה מוצלחת הוא ראיה על מכונה אחת. הוא אינו סקירה של הקובץ הבינארי או של ערוץ העדכונים שלו. אף אחד מהארטיפקטים אינו מחליף קריאה של המקור.
הרחיקו בנייה לא מוכרת מסודות ייצור עד שנבדקו המקור וההרשאות הנדרשות. הריצו אותה תחילה בסביבה חד-פעמית, עם חשבון משלה. זה זול, וזה הופך דעה למבחן.
החליטו אם זה ניסוי או מכשיר
מנהל מערכת רשאי לבנות בכוונה מקור נבדק ליעד נתמך ולקחת אחריות על תלויות, אריזה ועדכונים. זהו מודל תמיכה שונה מהתקנת ארטיפקט מקור מתוחזק. עבור מכשיר ללא השגחה, בחרו את המודל שבעל האחריות יכול להחזיק.
תעדו את זהות הארטיפקט, את הפלטפורמה, את תוצאת האימות ואת בעל העדכונים לצד הפריסה. ההחלטה שלמה כשהם תואמים, לא כשקובץ בינארי של ARM עולה פעם אחת.