pastilhasandClaude Opus 5
aac8af5e1f
The first watcher had an unbounded retry in it. A release whose deploy failed left no .done file, so the next poll two minutes later spawned a fresh headless agent, and the one after that, all night, each one costing money. The loop was careful and its logging was honest; the defect was structural. It is structural because the loop is written FRESH by an agent every time one arms. A rule that lives only in the prompt gets re-implemented from scratch each time, and the wrong implementation is the one that looks right: test the .done file. That file only exists on success, so testing it is exactly the retry storm. So scripts/deploy-claim.sh owns it. `claim <version>` exits 0 once and 1 for ever after, whatever became of the attempt that held it — a failed release is not retried, it is looked at. Handing the claim back is `rm -rf` by a person, on purpose; a loop cannot undo its own claim, which is what makes the storm impossible rather than unlikely. Three choices in it worth keeping: - `mkdir` is the claim. One atomic syscall that both tests and takes, with no window between checking and acting — two pollers a second apart is not hypothetical when a watcher gets restarted. - Bash, not bun. The thing that stops a retry storm must not need a healthy checkout; a deploy that dies on `bun install` is precisely when it has to work. - A version is digits and dots or it is refused. It arrives off a git tag and is concatenated into a path. A pre-existing .done with no claim beside it still counts as deployed, so deploy/2026.08.21.01 — rolled out by hand before any of this existed — is not re-attempted. docs/servers.md corrected from the commander's own report, which was right and specific: on macbookpro APPEND /opt/homebrew/bin for bun rather than replacing the PATH (this file said "do not help the PATH", which is right for pm2 and is what made plugins:update fail there), `ls` is aliased to an eza that is not installed, plugins:update bounces every sidecar before the plan's own restart step, and fofos cannot publish affordances for what is probably the same ownership problem as its capabilities sync. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
123 lines
7.2 KiB
Markdown
123 lines
7.2 KiB
Markdown
# Servers — the running list
|
|
|
|
Every machine the owner runs, how to reach it, and what of Officer is on it. Kept here so an
|
|
orchestrator ("pull and update every platform", "restart officer everywhere", "which host is behind")
|
|
has one place to read rather than a fact re-derived per session.
|
|
|
|
**Verified 2026-08-21** from `officer-dev` by SSH and `pm2 jlist`, except where marked assumed.
|
|
|
|
## How access works
|
|
|
|
All of it is over the tailnet, key-based, no `~/.ssh/config`, no passwords, no jump hosts, no ports.
|
|
|
|
**The login user is NOT always `pastilhas`.** It is per host and it is in the table below. `deadpool` runs
|
|
as `br` and always will — the owner's key is authorised for that account. An orchestrator that hard-codes
|
|
a username fails on that host and will fail on the next one like it.
|
|
|
|
```bash
|
|
ssh alpha # pastilhas, implied
|
|
ssh br@deadpool-rezio-bridge # not implied
|
|
```
|
|
|
|
## Officer platforms
|
|
|
|
Seven, all running.
|
|
|
|
| Host | Tailnet IP | Login | Checkout | Domain |
|
|
| ---------------------------- | ----------- | ----------- | ----------------------------------- | --------------------------------- |
|
|
| `officer-dev` | 100.64.0.13 | `pastilhas` | `~/officer-dev/platform` | `platform.officer.dev` |
|
|
| `alpha` | 100.64.0.1 | `pastilhas` | `~/officerdev/platform` | `officer.pastilhas.dev` |
|
|
| `fofos` | 100.64.0.17 | `pastilhas` | `~/officerdev/platform` | `officer.fofosfluffybastards.com` |
|
|
| `macbookpro` | 100.64.0.9 | `pastilhas` | `~/projects/officer-suite/platform` | `macbookpro.pastilhas.dev` |
|
|
| `edge-pertento-bridge` | 100.64.0.15 | `pastilhas` | `~/officerdev/platform` | `edge.pertento.ai` |
|
|
| `production-pertento-bridge` | 100.64.0.12 | `pastilhas` | `~/officerdev/platform` | `officer.pertento.ai` |
|
|
| `deadpool-rezio-bridge` | 100.64.0.21 | **`br`** | `/home/br/officerdev/platform` | `officer.rezio.dev` `[pending]` |
|
|
|
|
Only `platform.officer.dev` is public (77.42.39.155). The rest resolve to tailnet addresses and are
|
|
reachable from inside only.
|
|
|
|
### Names that disagree with themselves
|
|
|
|
Three hosts answer to more than one name, and `tailscale status` is not always the one in use:
|
|
|
|
| In `tailscale status` | Also | The machine's own hostname |
|
|
| ----------------------- | ---------------------------- | -------------------------- |
|
|
| `edge-bridge` | `edge-pertento-bridge` | `edge-pertento` |
|
|
| `gitea-bridge` | `production-pertento-bridge` | `PPROD` |
|
|
| `deadpool-rezio-bridge` | — | `deadpool` |
|
|
|
|
The middle column is what to use. `edge-bridge` and `gitea-bridge` are the old names and are being
|
|
retired; anything reading `tailscale status` will still see them.
|
|
|
|
### Things that will catch out an orchestrator
|
|
|
|
All verified, none cosmetic.
|
|
|
|
- **The checkout path differs per host** — four distinct shapes across seven machines. Take it from PM2:
|
|
the `officer` process's `pm_cwd`. `alpha` carries a SECOND, stale checkout at
|
|
`~/dockers/officer.dev/platform`, and pulling that one succeeds while changing nothing.
|
|
- **`pm2` is not on a non-interactive PATH.** It lives under nvm, and nvm's setup is in `.zshrc`, which a
|
|
_login_ shell does not read. Use `ssh <host> '$SHELL -ic "pm2 jlist"'`. `-lc` is **not** enough — it
|
|
reports "command not found" on machines where pm2 is plainly running, which cost two wrong conclusions
|
|
on 2026-08-21.
|
|
- **On `macbookpro`, APPEND to the PATH for `bun`. Never replace it.** This said "do not help the PATH"
|
|
until 2026-08-21, and that was half right in a way that cost a deploy step: `pm2` is only on the
|
|
interactive shell's PATH, so replacing it breaks `pm2` — but `bun` is at `/opt/homebrew/bin/bun` and
|
|
`.zshrc` does not put that directory on the interactive PATH either, so `bun run plugins:update` fails
|
|
`command not found` before it runs a line. `export PATH=$PATH:/opt/homebrew/bin` for that one command
|
|
shadows nothing: `pm2` stays at `~/.local/bin/pm2` and `node` at `node@22`. Run `pm2` as a separate
|
|
command.
|
|
- **`$SHELL -ic` on `macbookpro` aliases `ls` to `eza`, which is not installed.** A probe using `ls`
|
|
reports a missing file that is plainly there. Use `command ls`, or a non-interactive shell for file tests.
|
|
- **The git remotes differ.** `fofos` pulls over HTTPS; the others over SSH. Never assume a URL — pull in
|
|
place.
|
|
- **A "dirty tree" means TRACKED changes.** `git status --porcelain` counts untracked files, and a stray
|
|
script a fast-forward could never touch is not a reason to skip a host. Use `--untracked-files=no`.
|
|
- **`macbookpro` is a laptop.** It may be asleep. Unreachable is a skip with a note, not a failed deploy.
|
|
- **`bun run plugins:update` restarts sidecars itself**, printing `sidecar: started` per plugin — on
|
|
`alpha` that is twelve processes bouncing during the plugins step, before any restart the plan asked for.
|
|
Not a fault, but a deploy report that lists only `officer` under "restarted" is understating what moved.
|
|
- **`fofos` cannot sync its capabilities**, and could not publish gitea affordances on 2026-08-21:
|
|
`dubious ownership` from git and `EACCES … mkdir '…/capabilities/affordances/officerdev'`. Both point at
|
|
that capabilities checkout being owned by somebody other than `pastilhas`. Deliberately not papered over
|
|
with a `safe.directory` entry until somebody has run one `stat` on it. **Unexplained.**
|
|
|
|
## Not platforms — ignore for now
|
|
|
|
A checkout may be present; no `officer` process runs on any of these. Whether they are retired, staging
|
|
or half-installed is **not established** — ask before treating them as targets.
|
|
|
|
| Host | Tailnet IP |
|
|
| ----------- | ---------- |
|
|
| `headscale` | 100.64.0.2 |
|
|
| `omega` | 100.64.0.3 |
|
|
| `gateway` | 100.64.0.4 |
|
|
|
|
## Other machines on the tailnet
|
|
|
|
- **Not SSH-reachable** (port 22 refused): `edge-dns` (100.64.0.8), `officer-bridge` (100.64.0.5).
|
|
Assumed service-only containers — not confirmed. `edge-bridge` was listed here until 2026-08-21 and was
|
|
wrong: its SSH was simply down at the time of checking.
|
|
- **Client devices, not servers:** `iphone16`, `andres-ipad`, `pixel9a`, plus other people's devices in
|
|
the tailnet (`diogos-ipad`, `iphone-diogo`, `iphone-bruno`, `fedras-iphone`,
|
|
`guilhermes-macbook-pro`, `macbook-pro-de-joo`).
|
|
|
|
## Known wrong, waiting on someone else
|
|
|
|
- **`officer.rezio.dev` resolves to 100.64.0.4** — that is `gateway`, not `deadpool` (100.64.0.21). Not
|
|
merely unavailable: pointed at a different machine, so it will serve the wrong box the moment gateway
|
|
answers on 443. Ports 80 and 443 are closed on `deadpool`, so nothing fronts it yet. Waiting on the
|
|
domain owner.
|
|
|
|
## Keeping this list true
|
|
|
|
It rots when a server is added, a checkout moves, a platform is retired, a remote changes or a login
|
|
differs. Re-verify with the four commands it was built from:
|
|
|
|
```bash
|
|
tailscale status
|
|
ssh <login>@<host> '$SHELL -ic "pm2 jlist"' # the officer entry's pm_cwd
|
|
ssh <login>@<host> 'git -C <cwd> remote get-url origin'
|
|
getent hosts <domain>
|
|
```
|