חבילת מאגר או חבילת לקוח VPN: מה קודם?

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

מה כל חבילה באמת משנה

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

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

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

שלושה תנאים שקובעים את הסדר

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

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

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

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

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

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

dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/

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

התאימו את נתיב מחזיק המפתחות לשדה signed-by= בשורת המקור. מפתח בתיקייה הלא נכונה מייצר שגיאת מקור לא מאומת, שהיא תקלה שונה מחבילה שאינה זמינה.

התייחסו לכשל תלות כשלב נפרד

התקנת .deb שהורד עם dpkg -i אינה פותרת דבר: היא בודקת תלויות, מדווחת מה חסר ומשאירה את החבילה מוגדרת למחצה. זו התנהגות צפויה, לא הורדה פגומה.

לאחר מכן apt --fix-broken install מבקש מ-APT מצב עקבי מהמקורות שיש לכם. APT לא יודע איזה VPN רציתם, והתוכנית שלו עשויה להסיר חבילות כדי לספק את האילוץ שמצא. קראו את העסקה המוצעת לפני שעונים כן, ועצרו אם ההסרות נוגעות במשהו שנחוץ לכם. חזרה על התיקון בלי לקרוא את התוכנית היא הדרך שבה פער תלות קטן הופך לשולחן עבודה שלא עולה יותר.

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

אמתו את היישומון, לא את המאגר

ודאו שהלקוח הגיע למצב מותקן, ואז ודאו שהתוכנית עולה. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop אמור לדווח על install ok installed עם גרסה, וכשל הפעלה לאחר מכן הוא בעיית יישומון ולא בעיית אריזה.

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