סקריפטים להפעלה

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

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

צורה קנונית


{
  "os": {
    "startup_scripts": [
      {
        "name": "write-build-marker",
        "description": "Create a local readiness marker after networking is available.",
        "command": "set -Eeuo pipefail\ninstall -d -m 0755 /var/lib/example\nprintf '%s\\n' ready > /var/lib/example/build-ready",
        "packages": [],
        "run_as": "root",
        "after": "network-online.target"
      }
    ]
  }
}

השדות הם description וcommand, לא השדה script מדור קודם. run_as וafter משתמשים גם ב-snake_case. after היא מחרוזת יחידה מערכתית אחת, לא מערך.

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

עיצוב עבור ניסיונות חוזרים וכישלון חלקי

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

דפוסים טובים כוללים:

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

אל תסתמך על sleep כבדיקת מוכנות. בדוק את התלות בפועל.

הורדות חיצוניות

הימנע מ-13. אם האתחול הראשון חייב להביא חפץ:

השתמש ב-HTTPS עם אימות אישור;
הצמד את החפץ הצפוי או את גרסת המקור;
לאמת תקציר קריפטוגרפי או חתימה מאושרת לפני הביצוע;
הגדר חיבור ותפוגה כוללת;
כשל סגור אם האימות נכשל; ו
הימנע מרישום אישורים או כתובות URL חתומות.

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

סודות

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

זהות ביצוע

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

אימות

תוצאות הבדיקה במקום רק סטטוס היציאה של היחידה:


{
  "type": "file_contains",
  "description": "The startup unit wrote its readiness marker.",
  "params": {
    "path": "/var/lib/example/build-ready",
    "content": "ready"
  }
}

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