Investigate a floating/VIP address for swarm-published SSH ports (git-backup workaround today) #54

New issue

Open

opened 2026-08-21 15:25:02 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-08-21 15:25:02 +00:00

Collaborator

Context

Setting up os-git-backup on blaze (OPNsense) to push config.xml history to the new ccnet-blaze-config-backup Forgejo repo, hit the documented gap from ccnet-forgejo-swarm/'s README / CLAUDE.md: Forgejo's SSH/git port (2223) isn't reachable via code.coppercore.net, because that hostname resolves to 10.10.20.1 (blaze's own Caddy plugin) and Caddy only reverse-proxies HTTP(S) — it doesn't pass through raw TCP/SSH.

Worked around it today by pointing the git-backup remote directly at a swarm manager IP instead of the hostname:

ssh://10.10.10.211:2223/copper/ccnet-blaze-config-backup.git

This works (routing mesh means any of the 5 node IPs would answer on 2223), but it's brittle — it hardcodes one specific node's IP into blaze's config. If 10.10.10.211 is ever decommissioned, re-IP'd, or removed from the swarm, this backup silently breaks with no DNS indirection to fall back on.

Ask

Look into whether a floating/VIP address in front of the swarm nodes (keepalived, a dedicated internal DNS record with multiple A records / round-robin across manager IPs, or similar) would be worth setting up for cases like this — anywhere something needs to reach a swarm-published port directly (bypassing Caddy) without depending on one specific node staying alive/named the same forever. Same underlying gap as the existing "SSH clone access from outside the LAN" item in ccnet-forgejo-swarm/README.md, just hit from a different angle (a LAN-local, non-HTTP consumer this time).

Low priority / quality-of-life — the manager-IP workaround is fine for now.

## Context Setting up `os-git-backup` on blaze (OPNsense) to push config.xml history to the new `ccnet-blaze-config-backup` Forgejo repo, hit the documented gap from `ccnet-forgejo-swarm/`'s README / `CLAUDE.md`: Forgejo's SSH/git port (2223) isn't reachable via `code.coppercore.net`, because that hostname resolves to `10.10.20.1` (blaze's own Caddy plugin) and Caddy only reverse-proxies HTTP(S) — it doesn't pass through raw TCP/SSH. Worked around it today by pointing the git-backup remote directly at a swarm manager IP instead of the hostname: ``` ssh://10.10.10.211:2223/copper/ccnet-blaze-config-backup.git ``` This works (routing mesh means any of the 5 node IPs would answer on 2223), but it's brittle — it hardcodes one specific node's IP into blaze's config. If `10.10.10.211` is ever decommissioned, re-IP'd, or removed from the swarm, this backup silently breaks with no DNS indirection to fall back on. ## Ask Look into whether a floating/VIP address in front of the swarm nodes (keepalived, a dedicated internal DNS record with multiple A records / round-robin across manager IPs, or similar) would be worth setting up for cases like this — anywhere something needs to reach a swarm-published port directly (bypassing Caddy) without depending on one specific node staying alive/named the same forever. Same underlying gap as the existing "SSH clone access from outside the LAN" item in `ccnet-forgejo-swarm/README.md`, just hit from a different angle (a LAN-local, non-HTTP consumer this time). Low priority / quality-of-life — the manager-IP workaround is fine for now.

claude-bot added the

infra

p:low

labels

2026-08-21 15:25:11 +00:00