Skip to Content
Building OsOpstartscripts

Opstartscripts

os.startup_scripts maakt begrensd systemd one-shot-werk voor de resulterende image. Elke entry declareert een shell-commando, vereiste packages, uitvoeringsgebruiker en ordering unit.

Opstartscripts zijn root-capable code tenzij run_as iets anders zegt. Ze moeten dezelfde review krijgen als elk installatiescript.

Canonieke vorm

{
  "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"
      }
    ]
  }
}

De velden zijn description en command, niet het legacy-veld script. run_as en after gebruiken ook snake_case. after is één systemd-unitstring, geen array.

Het schema accepteert hoogstens 32 entries en een begrenste commandogrootte. Validatie wijst lege commando’s en NUL-bytes af, maar maakt shell-inhoud niet veilig of idempotent.

Ontwerp voor retries en gedeeltelijke falen

Een boot kan worden onderbroken nadat er al neveneffecten zijn opgetreden. Schrijf scripts zodat een volgende uitvoering veilig afrondt of eindigt met een duidelijke, inspecteerbare staat.

Goede patronen zijn onder andere:

  • naar een tijdelijk bestand schrijven, controleren, daarna atomisch hernoemen;
  • controleren of gebruikers, mappen of configuratie-items al bestaan;
  • install gebruiken voor expliciete eigenaar en mode;
  • set -Eeuo pipefail toepassen en verwachte nonzero-resultaten bewust afhandelen;
  • begrenste netwerk-timeouts en een eindig aantal retries; en
  • een readiness marker pas schrijven nadat alle vereiste stappen slagen.

Vertrouw niet op sleep als readiness-check. Test de werkelijke afhankelijkheid.

Externe downloads

Vermijd curl ... | sh. Als first boot een artifact moet ophalen:

  1. HTTPS met certificaatverificatie gebruiken;
  2. het verwachte artifact of de bronversie pinnen;
  3. een cryptografische digest of goedgekeurde handtekening verifiëren vóór uitvoering;
  4. connect- en total-timeouts instellen;
  5. fail closed als verificatie faalt; en
  6. credentials of ondertekende URL’s niet loggen.

Voor echt offline of reproduceerbaar gedrag neemt u gereviewde inhoud op in de image of een goedgekeurd package repository in plaats van te downloaden bij first boot.

Geheimen

Sluit nooit plaintext credentials in in het recept, commando, URL of gegenereerde marker. Recept-JSON en buildlogs worden bewaard als bewijs en kunnen zichtbaar zijn voor operators. Gebruik een goedgekeurd enrollment- of secret-delivery-mechanisme op deploymenttijd en scope het resulterende credential tot het doel.

Uitvoeringsidentiteit

Geef de voorkeur aan een unprivileged service account. Als root nodig is, beperk het commando tot de kleinst mogelijke privilegestap en stel expliciete bestandseigendom in. Bevestig dat run_as een account noemt dat vóór start van de unit is aangemaakt.

Verificatie

Test uitkomsten, niet alleen de exitstatus van de unit:

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

Test ook een tweede boot, een niet-beschikbare afhankelijkheid en herstel na een onderbroken eerste run. Inspecteer bij falen systemctl status en het unit journal.

ServicesImage-lokale gebruikers