eblume/hephaestus
1
0
Fork 0
generated from eblume/project-template
Code Issues Pull requests Projects Releases 10 Packages Wiki Activity Actions

C2(hephd-self-update): close service-env-forge-access

Browse source 
Public repo => anonymous HTTPS clone, no credentials (the SSH/canonical
premise was wrong: that was the access-restricted cargo registry, not git
clone). Install URL points at the canonical public host (verified end to
end); the service template bakes cargo onto PATH. Card rewritten to
reflect what actually happened.
This commit is contained in:
Erich Blume 2026-06-04 14:47:05 -07:00
commit 240c8a9f68
1 changed files with 31 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

50
docs/how-to/self-update/service-env-forge-access.md
View file

@ -3,35 +3,39 @@ title: Service env forge access
modified: 2026-06-04
tags:
- how-to
status: active
requires: []
---
# Service env forge access
The known blocker. `cargo install --git ssh://forgejo@forge.ops.eblu.me:2222/…`
works from an interactive shell (it has an SSH agent/key and cargo on PATH) —
but the daemon runs under launchd/systemd, whose environment likely has
**neither**. Self-update via cargo can't work until the service context can
reach the forge and run cargo.
The runtime-environment prerequisite for the apply path: a `hephd` started by
launchd/systemd runs with a minimal environment, so it must be able to find
cargo and fetch the repo when it runs `cargo install`.
## What to establish
## Resolved (and how the original premise was wrong)
- **cargo + toolchain on the service PATH.** launchd/systemd start with a
minimal env; `~/.cargo/bin` and rustup's toolchain must be discoverable.
Likely bake `PATH`/`EnvironmentFile` into the generated plist/unit
(`crates/heph/src/service.rs`).
- **Forge SSH auth without an interactive agent.** Options to evaluate: a
dedicated read-only deploy key referenced via `GIT_SSH_COMMAND`/an SSH config
entry, or `SSH_AUTH_SOCK` exported to the service. Must work headless.
- **The canonical-host caveat.** Owner note: cargo rejects `forge.ops.eblu.me`
over HTTPS because the forge advertises `forge.eblu.me` as canonical; the
**SSH** URL on port 2222 sidesteps this and is the proven path (used by the
install how-to and the v1.0.3 redeploy). Pin self-update to the SSH URL;
capture any `insteadOf`/known_hosts setup needed headlessly.
This card was first written assuming self-update needed **forge SSH
credentials** for a headless service — because the install how-to uses
`ssh://forgejo@forge.ops.eblu.me:2222/…`. That premise was wrong:
## Done when
- **hephaestus is a public repo**, and `cargo install --git` is a plain
anonymous git clone — *not* the Forgejo cargo **registry** (the registry is
access-restricted and is the thing that required `forge.ops.eblu.me`; it is
unrelated to git clone). So **no credentials, no SSH, no deploy key**.
- Verified end-to-end: `cargo install --git https://forge.eblu.me/eblume/hephaestus.git --tag v1.0.3 hephd`
builds a working binary anonymously. Self-update uses that canonical public
HTTPS URL (`INSTALL_GIT_URL`), and the release poll uses the same host.
A hephd running as the installed service can, in its own environment, complete
`cargo install --locked --git ssh://… --tag <known-good> hephd` non-interactively.
Unblocks [[cargo-install-from-tag]]. Part of [[hephd-self-update]].
So the only real requirement was the **environment**, handled in
`crates/heph/src/service.rs`: `heph daemon start --self-update` generates a
launchd/systemd service that passes `--self-update` and bakes a `PATH`
(including `~/.cargo/bin`) + `HOME` so the minimal service env can find cargo
and the toolchain. `restart` preserves the setting. Default services are
unchanged.
## Remaining (owner)
The Rust toolchain must be installed for the service user (cargo builds from
source), and a real on-device run — enable `--self-update`, then confirm a
live upgrade when the next release lands — is the final end-to-end check. See
[[hephd-self-update]].