Services

Ein Rezept-Service hat nur drei kanonische Felder: name, enabled und ein offenes config-Objekt. Die Form validiert strukturell, aber ein Config-Key wirkt nur, wenn der gewählte Build-Worker oder Feature-Hook ihn implementiert. Validierung beweist nicht, dass ein Daemon installiert oder konfiguriert wurde.


{
  "services": [
    {
      "name": "ssh",
      "enabled": true,
      "config": {
        "port": 2222,
        "allow_root": false,
        "disable_password_auth": true,
        "authorized_keys": ["ssh-ed25519 AAAA... operator@example"]
      }
    }
  ]
}

SSH-Konfiguration

Der allgemeine Linux-Build-Pfad erkennt diese SSH-Einstellungen:

Rezept-Key	Wirkung
`port` oder `listen_port`	OpenSSH-Port, 1–65.535
`allow_root`	Mappt auf `PermitRootLogin`
`disable_password_auth`	Invertiert in `PasswordAuthentication`
`password_authentication`	Direkter OpenSSH-Token-Wert
`pubkey_authentication`	Direkter OpenSSH-Token-Wert
`client_alive_interval`	Begrenztes `ClientAliveInterval`
`client_alive_attempts`	Begrenztes `ClientAliveCountMax`
`authentication_retries`	Begrenztes `MaxAuthTries`
`timeout`	Begrenzte Login-Grace-Time
`x11_forwarding`, `allow_agent_forwarding`, `allow_tcp_forwarding`	Direkte OpenSSH-Token-Werte
`authorized_keys`	Installiert die gelieferten Public Keys, wo unterstützt

Worker-spezifische Pfade können eine kleinere Menge unterstützen. Insbesondere Hardware-, Proxmox- und Raspberry-Pi-Builder haben eigene Adapter. Normalisiertes Rezept und Build-Warnungen für das gewählte Ziel prüfen.

Ist Passwort-Authentifizierung deaktiviert, mindestens einen gültigen Public Key einbeziehen und unabhängig testen, bevor auf Hardware deployed wird. Keine privaten Keys oder Passwörter in Rezept-Service-Konfiguration.

Weitere Services

Namen wie nginx, wireguard, DNS, DHCP oder Firewall-Komponenten sind keine universelle Konfigurations-API. Pakete und Konfiguration kommen vom passenden Feature, Hook, Paketliste oder Startup-Skript für die gewählte Base. Ein beliebiges Objekt wie config.sites kann vom Schema akzeptiert und trotzdem ignoriert werden.

Diese Reihenfolge nutzen:

Base Image wählen und konkretes Feature oder Pakete aktivieren.
Nur Config-Keys hinzufügen, die für diese Capability implementiert sind.
Normalisiertes Rezept und generierte Warnungen prüfen.
Assertions für Paketpräsenz, Service-Enablement, Listener-Ports, Config-Dateien und Application-Level-Antwort hinzufügen.
Artefakt booten und testen vor Hardware- oder Produktions-Promotion.

Siehe Features, Startup scripts und Assertion types.