CHG-0042: The Home Pi Becomes a Deevnet Pi, and the Devices Hold Both Sites

Summary

The home Pi runs EdS on a card whose certificate is signed by that card’s own CA, for names entered by hand in the home DNS. The devices dial its address and trust that CA, and hold one site’s settings.

After: a new card, whose certificate is Deevnet’s, from the Tenant Service CA, for the tenant’s site-less names (mqtt.eds.deevnet.net and its siblings) and for each of them at home and mobile. Everything on it trusts the Deevnet Root. The devices dial mqtt.eds.deevnet.net, trust the Root, and hold both sites: home in use, mobile beside it, for the switching firmware to come (ADR-0049).

Goal

• sudo deevnet-kit status on the Pi names mqtt.eds.deevnet.net, and the certificate’s issuer is the Tenant Service CA.
• make status says ok for every check.
• /etc/eds/lightd.env on the Pi has MQTT_HOST=mqtt.eds.deevnet.net.
• Each device’s presence is green on the console, from this Pi’s broker.
• A record on the turntable lights the stand.

Scope

In scope: the new card, its certificate, the home DNS names, and the four devices’ creds partitions. Out of scope: the switching firmware (ADR-0049), the devices’ firmware, the tenant’s workload and the relay Pi.

Risk and impact

Procedure

Step 1: Build the image

Run: make -C deploy/backend image fetch

Verify: the build’s check of the base passes: its deevnet-kit has cert install (0.15.0).

Step 2: The card

Flash eds-pi-backend.img.xz with no customization, then:

Run: make -C deploy/backend card PI_HOSTNAME=dv01rpi001p01

Step 3: Swap and first boot

Power off the Pi, keep the old card, put in the new one, and power on. Allow a few minutes for both boots.

Verify: ssh eds@dv01rpi001p01.local sudo deevnet-kit status answers.

Step 4: The certificate

Run, on the Pi: sudo deevnet-kit cert request. Then a deevnet_certificate in the tenant’s Terraform with that request, name mqtt, names logs, grafana and console, and sites home and mobile; terraform apply. Copy the full chain and the Deevnet Root to the Pi:

sudo deevnet-kit cert install fullchain.pem deevnet-root-ca.pem
sudo systemctl restart eds-backend-setup

Verify: sudo deevnet-kit status names the Deevnet names, and /etc/eds/lightd.env has MQTT_HOST=mqtt.eds.deevnet.net.

Step 5: Drivers and checks

Run: make pair, make spotify, make turntable DEVICE=plughw:CODEC, make drivers DRIVERS=itunes,spotify,turntable, make status

Verify: every check ok.

Step 6: Home DNS

mqtt, logs, grafana and console, under eds.deevnet.net and eds.home.deevnet.net, answer 192.168.2.40 on the home network.

Verify: from a computer at home, https://console.eds.deevnet.net/ loads with no warning where the Deevnet Root is trusted.

Step 7: The devices

Copy deploy/backend/devices.json and deevnet-kit-ca.pem aside: they are the old card’s. Then make devices, and on each device, the beacon first, in its firmware directory:

python3 tools/provision_tenant.py -p <port> \
    --outputs-json ../../deploy/backend/devices.json \
    --ca ../../deploy/backend/deevnet-kit-ca.pem \
    --site home --also mobile=terraform

Verify: before each write, the two sites printed are home (DVNT-CORE, mqtt.eds.deevnet.net) in use and mobile beside it; after it, the device’s presence is green on the console. Only after the beacon is, the others.

Verification

Every check under Goal.

Undo

Before step 7: power off, put the old card back. Nothing else has changed but a certificate issued, which is left to expire.

After a device is moved: the old card back in, and that device provisioned from the copies kept in step 7 (provision_tenant.py with them, and no --site).

Outcome

Completed after the change has run.

Departures from the plan

• The tenant’s provider pin went from ~> 0.7 to ~> 0.8: a certificate’s sites first came in 0.8.0.
• The same day’s applies also created grafana_dashboard.covers, waiting since ADR-0050 was merged without one.
• Before the certificate, the Pi warned that its card certificate did not name its IPv6 address. A Deevnet certificate names no address.
• The card is named eds-backend, not dv01rpi001p01: it was written with make card’s default PI_HOSTNAME.
• cert install restarted the services but not deevnet-kit-dashboards, so Grafana’s log data sources kept the card’s localhost until that was restarted by hand.
• The beacon was provisioned without --site home --also mobile=terraform: the tenant’s state is reachable only from dvntm. Its tenant settings were read from its creds partition first, to write back as the undo.
• respeaker-01 was not moved. The plan named it, but the backend Pi runs palette, lightd, nowplayd and the console, and not voiced or scribe, so its requests would reach a broker with nothing listening for them.
• The Pi has two addresses on the home network, 192.168.2.40 (wired) and 192.168.2.228.

Follow-ups

• Deevnet: deevnet-kit cert install should rerun the dashboards step (deevnet-provisioning-api#41), so Grafana’s data sources dial the new names.
• Deevnet (deevnet-provisioning-api#42): on a Deevnet Pi, status and selftest warn that the certificate names none of the Pi’s addresses and suggest regen-certs, which then refuses. A Deevnet certificate names no address by design; the check should not run in that mode.
• Find out why the cover screen’s first start after provisioning sent no presses while showing covers. Test each device’s controls straight after it is written, before anything restarts it. Not seen again on 2026-10-31: unplugged since the move, the screen was powered again with nothing on its serial port, came online by itself, and four presses in a row reached iTunes, each in a fraction of a second. If it happens again, it is right after a provisioning write, and the screen’s serial log is the place to look.
• The resolver named Journey’s Wheel In the Sky, heard on Infinity, as from Alive in America, a live album, and lit the stand from its cover (named_by=original, ADR-0038). The record is not in the Discogs collection, so nothing named it first. The original album step should not choose a live album or a reissue over a studio original.
• The reSpeaker, once this Pi runs voiced and scribe: until then it stays on the tenant. Its account is already in accounts.conf.
• --also mobile=terraform for the beacon, the screen and the stand, on a day on dvntm: each holds this Pi’s site alone.
• The switching firmware (ADR-0049), over the air to the stand, the screen and the beacon; by cable to the reSpeaker.
• The certificate named for the host, not a service. Its CN is mqtt.eds.deevnet.net, from name = "mqtt". Wanted: name = "backend" and names = ["mqtt", "logs", "grafana", "console", "dv01rpi001p01"], sites home and mobile, for a CN of backend.eds.deevnet.net. The tenant’s CA signs only in its own zone, so the Deevnet host name appears as dv01rpi001p01.eds.deevnet.net, never dv01rpi001p01.home.deevnet.net. Changing name replaces the certificate, and the old one is left to expire. The round trip is this change’s: cert request at home, terraform apply on dvntm, cert install at home. Home DNS gains backend and dv01rpi001p01 under eds.deevnet.net and eds.home.deevnet.net, at 192.168.2.40; the .home one is the host’s own name, for SSH. At the next reflash, perhaps the card named to match (it is eds-backend).
• nginx on the Pi’s 80 and 443: plain HTTP sent to HTTPS, and a name beginning grafana. reaching Grafana, so it needs no :3000, with Grafana on loopback behind it. From an earlier draft that this change superseded, kept as the branch archive/backend-names-nginx; its names were interim until the site-less ones this change put in place.
• .local or the A record for SSH and make (PI ?= $(PI_HOSTNAME).local). Talked through on 2026-10-29: .local stays for now. It came with the take-home kit, which assumed no DNS at all; iTunes needs Bonjour only to pair, and never the Pi’s own name. Its one remaining merit is working when the router’s DNS does not, which is when SSH is wanted most. Revisit with the certificate’s rename: give the host a site-qualified A record, backend.eds.home.deevnet.net (a site-less name follows the tenant between sites, and a host does not move), use it with PI=backend.eds.home.deevnet.net, and decide then whether it becomes the default.
• Deevnet (deevnet-provisioning-api#43): deevnet-kit cert install installs only for a pending request, and deletes its key once used, so a renewal Terraform issues for the same key cannot be installed. Every renewal is a new cert request. To note beside ADR-0053’s renewal job.