Place-file & reload
The place-file activator is how a delivery profile actually lands a config on a device. A small agent runs on each device and does the work: it verifies the signed descriptor, writes the file atomically at the declared path, runs an optional reload, then checks health and reverts if anything is wrong. The platform is not agentless — this on-device step is where verification, atomic swap, and rollback live.
The device decides what is allowed
A signed descriptor can request a destination and a reload, but it can never grant itself permission. Each device is configured with an allowlist that bounds what placement may do:
- which absolute path prefixes a file may be written under,
- which systemd units may be reloaded,
- which binaries may be executed as a reload.
The allowlist starts empty, which means deny-everything: a device accepts file placement only after an operator has explicitly enabled it. A descriptor that asks for a destination or reload outside the allowlist is refused on the device, even though it was signed. The signed payload may only choose within the allowlist; it can never widen it.
How a placement runs
- The agent fetches and verifies the descriptor, then re-validates its shape and checks the requested destination and reload against the device allowlist.
- It confirms the file's contents match the declared SHA-256 digest.
- If a file already exists at the destination, it is backed up so the change can be undone.
- The new file is written to a temporary path and moved into place with an atomic rename, so readers never see a half-written file.
- The reload runs, if one was declared.
- A health probe checks that the device is actually healthy with the new config.
Reloads have no shell
A reload is one of two fixed shapes. A systemd reload reloads-or-restarts a named unit. An exec reload runs a fixed argument list whose first element is an absolute binary path. Neither is interpreted by a shell, and both must be on the device allowlist. There is no way to express a free-form command, by design.
Rollback on a failed probe
Placement is only as safe as the probe that follows it. If the health probe fails after the file is placed, the agent restores the previous state on its own — putting the backed-up file back (or removing the file if there was none before) — and re-runs the reload so the service returns to its prior configuration. A bad config update leaves the device on the config it had before, without an operator having to intervene.
config — acme-tuning@1.4.0 → /etc/acme/config.yaml
descriptor verified TUF · digest match
destination in allowlist /etc/acme/*
backup taken · file placed atomic rename
reload acme.service systemd
health probe failed rolling back
previous config restored · reloaded recovered