migration: install verified on the new box; correct two wrong claims and list the ports still shut

Measured from the agent host: setup page live on both IPs, 80/443 open on v4 (rules gap fixed), cert is a valid Let's Encrypt IP certificate (not self-signed) so no ACME exposure for the domain, no cloudron CLI on a server, and 25/465/587/993/995/4190 still closed there.
This commit is contained in:
inference-bot committed 2026-10-30 23:22:40 +00:00
1 parent 717c72c9bb
commit 6dce468bf3
1 file changed
+20 -13
+20 -13
View File
@@ -69,21 +69,28 @@ needed to restore are inside the thing being restored.
(`/api/v1/cloudron/status` → `10.1.5`; backup manifests read `box_v10.1.5`). The
earlier note of "9.0.4" was the *CLI* version, not the platform — a restore cannot go
backwards.
- [ ] **Install now, stop before the wizard.** Run `cloudron-setup` with **no `--domain`**, and leave
the browser wizard for cutover day. On current Cloudron the setup page is served on the
server's **IP with a self-signed certificate**, so the install needs no DNS — and because the
domain is not entered yet it makes **no certificate attempts at all**. The Let's Encrypt
rate-limit risk noted earlier only materialises if you enter `my.inference.coop` while DNS still
points at Hostinger; leaving it unset means the box sits idle and retries nothing, so it needs
no powering off. This de-risks the one step that can hard-fail (kernel, Docker, OS support)
while there is still time to act on it.
**Check immediately after installing:** `cloudron --version` ≥ **10.1.5** (a restore cannot go
backwards — 10.1.5 is the platform version this box runs; the earlier note of "9.0.4" was the
*CLI* version), `cloudron status` healthy, Docker running, and **no apps installed** (a pristine
platform is what a restore expects).
- [x] **Installed 2026-10-30 — banner shown, setup page live on the IPs.** Run `cloudron-setup`
with **no `--domain`**, and leave the browser wizard for cutover day. Verified from the agent
host: the box serves the setup page on **both** `https://179.237.86.116` and
`https://[2001:1600:18:206::89]` (HTTP 200), and **80/443 are open on v4** (the earlier
v4-rules gap is fixed).
**The certificate is NOT self-signed.** Cloudron obtained a **valid Let's Encrypt certificate
for the bare IP** — SAN `IP Address:179.237.86.116`, expires 2026-11-06, and `curl` verifies it
with no `-k`. That is LE's new short-lived IP-certificate feature. Consequence: **nothing is
attempted against `my.inference.coop` yet, so there is no ACME rate-limit exposure at all** —
the "watch Let's Encrypt limits" caveat in earlier drafts of this section is moot. Over IPv6 the
IP cert does not validate (the SAN covers the v4 address only), which is harmless: after
cutover the hostname certificates cover both families.
**There is no `cloudron` CLI on the server** — that is a separate npm tool for managing a remote
Cloudron, not part of the platform. For server-side diagnostics use the documented tool,
`sudo cloudron-support --troubleshoot`. The version needs no guessing: a fresh install pulls the
current release, which is 10.1.5 or newer, and anything ≥ 10.1.5 restores this backup.
**Ports still to open on the new box (checked 2026-10-30): 25, 465, 587, 993, 995, 4190.** Only
22, 80 and 443 answer today. Mail will not work on the new box until these are added, and
outbound 25 is the separate Infomaniak ticket.
**Leave for cutover day:** the domain, the plan/subscription (completing the wizard early can
move the subscription off the live server — the one step worth reading twice), and the
restore-from-backup itself.
restore-from-backup itself. Looking at the setup page is harmless; submitting it is not.
- [ ] Take an Infomaniak **snapshot of the VPS right after the install** (snapshots: 0 of 1 used), so a
botched wizard on cutover day can roll back to a known-good installed platform.
- [ ] Confirm the Cloudron subscription can be moved to a new server (do it at cutover,