| Age | Commit message (Collapse) | Author |
|---|
|
The NodePort is LAN-only, so the advertised clone URL
(ssh://git@r0.lan.buetow.org:30222/...) did not work from outside. Add a plain
TCP relay on the gateways forwarding 2022 to NodePort 30222, and have Forgejo
advertise code.f3s.buetow.org:2022.
Port 2022 rather than 22: the gateways run their own sshd on port 2, so 22 was
in fact free, but leaving the forge off the default port keeps it clear of the
mass scanning that port attracts. That is noise reduction and not security --
the real protection is that Forgejo's SSH does key-only auth for git operations
and offers no shell. 2222 would have been the conventional choice but dserver
(DTail) already holds it on the gateways; verified 2022 free on both.
The relay carries no "protocol" line, so relayd forwards the stream untouched.
TLS must not be involved: SSH secures its own transport and the client verifies
Forgejo's host key at the far end. A dedicated <forgejo_ssh> table keeps the
health check on the SSH port, since the web UI can be up while SSH is not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
Review of the initial chart turned up one blocker and several correctness gaps:
- `just create-admin` could never work. `admin user create` does not prompt; it
exits with "must set either password or random-password flag". With the
installer locked and registration disabled that recipe was the only way into
the instance, so first login was impossible. Use --random-password, which
prints the generated password once, rather than passing one on the command
line where it would reach shell history and ps.
- SSH_DOMAIN advertised code.f3s.buetow.org, but that name resolves to the
OpenBSD gateways (443 only) and *.f3s.lan points at the CARP storage VIP, not
a k3s node. Every clone URL Forgejo rendered would have been unreachable.
Advertise r0.lan.buetow.org, which actually answers on the NodePort.
- No REVERSE_PROXY_TRUSTED_PROXIES, so behind relayd -> Traefik every request
was attributed to the Traefik pod IP: real client IPs absent from the audit
trail and per-IP rate limiting defeated, on an internet-facing instance.
- Pin both PVCs with volumeName. The 1Gi config claim also matched the 20Gi
data PV, leaving the choice to the binder's smallest-sufficient heuristic.
README: add the gogios task to the frontends deploy (the new host otherwise
gets no TLS/HTTP checks); drop the false claim that pushing alone deploys the
Application, since nothing watches f3s/argocd-apps/; keep .nfs-sentinel at 0644
instead of sweeping it into a recursive 0750; note that the real certificate is
only issued on the gateway holding the DNS master IP.
Still not activated. Re-verified: helm template renders, and all 9 objects pass
kubectl apply --dry-run=server.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
Deliberately independent of the cgit git-server: separate namespace (services),
separate NFS volumes, separate SSH NodePort (30222 vs 30022), and no shared
storage. cgit keeps serving the existing 80 bare repos at c-git.f3s.buetow.org
and is not touched. Forgejo starts empty; repos get migrated by hand later.
ArgoCD deliberately keeps reading conf.git from the existing git-server, so
Forgejo has no consumers and cannot take cluster deploys down with it.
SQLite rather than a PostgreSQL pod: single writer (replicas 1 + Recreate) and
NFSv4.2 does real byte-range locking, so the usual SQLite-on-NFS failure mode
does not apply. Uses the -rootless image so the pod runs wholly as UID 1000
with all capabilities dropped, and both volumes carry the .nfs-sentinel guard.
The installer is locked and registration disabled because the instance is
reachable from the internet; the admin account is created via the CLI.
code.f3s.buetow.org added to @f3s_hosts, which drives the DNS zone, the relayd
route, the ACME cert and the gogios checks.
Not yet activated: the ArgoCD Application still needs applying, the NFS
directories creating, and the frontends deploying. See f3s/forgejo/README.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
