From 9b459b79dd5d15880bc666c427dd8e90fa8ab96e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Sat, 22 Aug 2026 15:27:20 +0000 Subject: [PATCH] =?UTF-8?q?poll=20gitea=20locally=20=E2=80=94=20the=20publ?= =?UTF-8?q?ic=20door=20is=20rate-limited=20and=20gitea=20is=20on=20this=20?= =?UTF-8?q?machine?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The deploy watcher kept logging `Connection closed by 77.42.39.155 port 22` followed by "make sure you have the correct access rights", which reads as a credentials problem and is not one. `origin` pointed at gitea.officer.dev, which resolves to the public address and arrives through Nginx Proxy Manager — where every connection appears to come from one container IP, internet bots get that IP penalised by srclimit_penalise, and SSH is refused for long stretches. Gitea is a plugin ON THIS MACHINE, listening on 100.64.0.13:10023. The watcher was leaving the box and coming back in through a proxy to read a repository sitting on its own disk. origin now points at the local address; the public URL is kept as `gitea-public` so nothing is lost. No file was edited to do it, which matters — the watcher is a running bash script and editing one in place is how a loop starts executing half of two versions. Changing the remote's URL takes effect on the next tick with nothing restarted. Loopback would be better still and is not used: 127.0.0.1 fails host key verification because it has no known_hosts entry, while the tailnet address is already trusted. The cost of not knowing this, recorded in the prompt: a tag pushed at 21:47 on 2026-08-21 went unnoticed until 23:07. Eighty minutes, forty-odd ticks, every one of them correctly logged and retried. The loop was never at fault — it was asking through a door that is sometimes shut. Co-Authored-By: Claude Opus 5 --- prompts/deploy-commander.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/prompts/deploy-commander.md b/prompts/deploy-commander.md index 410df00e..dbb43ef0 100644 --- a/prompts/deploy-commander.md +++ b/prompts/deploy-commander.md @@ -18,6 +18,21 @@ there is a release to deploy that has not been deployed. git ls-remote --tags origin 'refs/tags/deploy/*' ``` +**Poll a LOCAL remote, never the public hostname.** On `officer-dev`, gitea is a plugin on the same machine +— it listens on `100.64.0.13:10023` and on loopback — so `origin` points there. `gitea.officer.dev` resolves +to the public address and arrives through Nginx Proxy Manager, where every connection appears to come from +one container IP: internet bots get that IP penalised by `srclimit_penalise`, and SSH is then refused for +long stretches. + +That is not hypothetical and it is not subtle when it happens. On 2026-08-21 a tag pushed at 21:47 was not +noticed until 23:07 — eighty minutes of `ls-remote` being closed on, forty-odd ticks, all correctly logged +and retried. On 2026-08-22 it refused at 08:35 and again at 12:58. The loop is not at fault in any of those: +it logs the exit code, sleeps, and carries on. It is simply asking through a door that is sometimes shut. + +If `ls-remote` fails with `Connection closed by port 22`, that is this, and the remote is wrong +rather than the credentials. Loopback needs a `known_hosts` entry that may not exist; the tailnet address is +already trusted. + A release is **a tag**, named `deploy/` — `deploy/2026.08.21.01`. Nothing else triggers you: not a commit message, not a branch, not a push.