tls.acme names the certificate and jarl: the Jarl server and a token that may only write the challenge record. Steward gets the certificate with DNS-01 (lego), writing the record through Jarl's API into every view that has the zone, renews it with a third of its lifetime left and swaps it in without a restart. A check runs before every order: Jarl, the zone, the token's permission, a test record, the zone's name servers, public resolvers, clean-up; each step says what to fix. Staging by default. With a certificate, each listener serves HTTPS and plain HTTP on one port (redirecting plain HTTP, except from the server itself). steward cert / cert check / cert renew, Server -> Certificate in the web UI, GET /certificate, POST /certificate/check|renew. docs/certificates.md and docs/jarl.md (the Jarl user and the token's grant). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.6 KiB
Configuration file
/etc/steward/steward.yaml says how stewardd runs. The DHCP
configuration (subnets, pools, reservations, options) isn't here; it is
in the database, changed with the CLI or the web UI.
stewardd config --example prints a commented file with the defaults.
Every setting is optional; unknown settings are an error. stewardd reads
the file when it starts.
| Setting | Default | |
|---|---|---|
listen |
["127.0.0.1:8067"] |
addresses of the web UI and API (host:port). Keep them on localhost or a management network |
tls.cert_file, tls.key_file |
none | serve HTTPS with this certificate; stewardd rereads it when the file changes, or on systemctl reload steward |
tls.acme.* |
off | get the certificate from Let's Encrypt, with Jarl publishing the challenge (certificates.md) |
jarl.server, jarl.token_file (or jarl.token), jarl.ca_cert, jarl.insecure |
none | the Jarl server Steward uses for DNS, and its token (jarl.md) |
trusted_proxies |
[] |
addresses or prefixes of reverse proxies whose X-Forwarded-For and X-Forwarded-Proto are believed |
socket |
/run/steward/steward.sock |
the local API socket; "" turns it off |
database |
/var/lib/steward/steward.db |
the SQLite database: configuration, leases, history, users, audit log |
log.level |
info |
debug (every HTTP request), info, warn or error |
log.format |
text |
text or json |
session.lifetime |
12h |
how long a web UI login lasts |
session.idle_timeout |
2h |
logged out after this long without use |
session.cookie_secure |
auto |
auto (secure over HTTPS), always or never |
backup.dir |
/var/backups/steward |
where stewardd backup writes |
backup.retention |
30d |
backups older than this are deleted… |
backup.keep_at_least |
7 |
…keeping at least this many |
Durations are written 15s, 12h or 30d.
HTTPS
Over plain HTTP, passwords and tokens cross the network in the clear; stewardd warns when it listens on a non-loopback address without TLS. Let it get its own certificate through Jarl (certificates.md), or give it one:
listen: ["10.0.10.2:8067"]
tls:
cert_file: /etc/steward/tls/fullchain.pem
key_file: /etc/steward/tls/privkey.pem
Or keep it on 127.0.0.1 behind a reverse proxy that terminates TLS, and
list the proxy in trusted_proxies. With a certificate, the same port
answers HTTPS and redirects plain HTTP to it, except from the server
itself. Ports below 1024 work too: the unit
grants CAP_NET_BIND_SERVICE for DHCP's port 67.