האם קובץ ה-.deb הישן של openfortivpn מתאים ל-Raspberry Pi שלכם?

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

מה שם הקובץ נועל בשקט

קראו שם כמו openfortivpn_1.17.0-1_armhf.deb מימין לשמאל. הסיומת היא הארכיטקטורה שעבורה הודר הבינארי, השדה האמצעי הוא גרסת ה-upstream והאריזה, והשדה הרביעי המשתמע הוא מערך הספריות של ההפצה שבה הוא נבנה.

בהתקנה של 64 סיביות של Raspberry Pi OS ארכיטקטורת המערכת היא arm64, ולכן dpkg -i דוחה חבילת armhf בגלל אי-התאמה בארכיטקטורה. גם במקום שבו multiarch מאפשר התקנה, הבינארי מצפה לגרסאות ספרייה מהמהדורה שכנגדה נבנה, ומערכת בסיס חדשה יותר אולי כבר לא מספקת אותן. התוצאה היא חבילה מותקנת שבה קובץ ההרצה אינו עולה, וזו התקלה שאנשים בדרך כלל מפרשים לא נכון כאילו הלקוח עצמו שבור.

היות שהלוח הוא התקן ARM לא הופך חבילת ARM למתאימה. ארכיטקטורה היא ציר אחד; מהדורה ו-ABI הם השניים האחרים, והם נכשלים באופן בלתי תלוי.

שאלו את ההפצה לפני שתבקשו קישור הורדה

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

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

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

אם רענון המטא-נתונים נכשל, הפרידו את הכשל הזה משאלת החבילה. פתרון שמות, תעבורת מאגרים, חתימת Release חסרה ומהדורה שפג תוקפה — כולם שוברים את apt update לפני שהלקוח בכלל מעורב. תיקון מקורות הוא משימה אחרת מבחירת לקוח VPN, וערבוב השניים הוא הדרך שבה אנשים מפנים מערכת עדכנית למהדורה מיושנת.

מה apt מאמת, ומה קובץ שהורד לא מקבל

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

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

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

התקינו את הלקוח, ואז נפתרו את החיבור בנפרד

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

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

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

התוכנית שאמורה להחליף את שם הקובץ הישן

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

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

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