Tjenester

En recipe-tjeneste har kun tre kanoniske felter: name, enabled og et åbent config-objekt. Formen valideres strukturelt, men en konfigurationsnøgle virker kun, når den valgte build worker eller feature hook implementerer den. Validering er ikke bevis for, at en daemon blev installeret eller konfigureret.

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

SSH-konfiguration

Den generelle Linux-buildsti genkender disse SSH-indstillinger:

Worker-specifikke stier kan understøtte et mindre sæt. Især hardware-, Proxmox- og Raspberry Pi-builders har egne adaptrer. Gennemgå det normaliserede recipe og buildadvarsler for det valgte mål.

Hvis adgangskodegodkendelse er slået fra, medtag mindst én gyldig offentlig nøgle og test den separat, før du deployer til hardware. Læg ikke private nøgler eller adgangskoder i recipe-tjenestens konfiguration.

Andre tjenester

Navne som nginx, wireguard, DNS, DHCP eller firewall-komponenter er ikke et universelt konfigurations-API. Deres pakker og konfiguration kommer fra tilsvarende feature, hook, pakkeliste eller startup script for den valgte base. Et vilkårligt objekt som config.sites kan accepteres af skemaet og alligevel ignoreres.

Brug denne rækkefølge:

1. Vælg et base image, og aktiver den konkrete feature eller pakker.
2. Tilføj kun konfigurationsnøgler, der er implementeret for den capability.
3. Gennemgå det normaliserede recipe og genererede advarsler.
4. Tilføj assertions for pakke tilstedeværelse, tjenesteaktivering, listener-porte, konfigurationsfiler og svar på applikationsniveau.
5. Boot og test artefakten, før hardware eller produktion.

Se Features, Startup scripts og Assertion types.