From 5b381dc33eaa2d29701db7f6d47b63d79361bc0f Mon Sep 17 00:00:00 2001 From: axiomlogicnexus Date: Fri, 29 May 2026 18:28:55 +0200 Subject: [PATCH] Record VPS migration findings and DNS guidance --- ...JO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md | 226 +++++++++++++++++- 1 file changed, 223 insertions(+), 3 deletions(-) diff --git a/docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md b/docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md index 3e85cc5..a3f1bfc 100644 --- a/docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md +++ b/docs/ops/HYPERTWIST_VPS_12_24_720_FORGEJO_WOODPECKER_MIGRATION_PLAN_2026-05-29.md @@ -36,6 +36,50 @@ Current live control-plane shape documented there: - backup scripts and cron jobs - ops guards and journald retention policy +## Live discovery findings from 2026-05-29 + +### New VPS `212.227.13.220` + +Confirmed directly over SSH: + +- host reachable over SSH as `root` +- Ubuntu `24.04.4 LTS` is installed +- no active Plesk services found +- no installed Plesk packages found +- no Apache or NGINX listener active yet +- only SSH is listening publicly at the moment +- current global IPv4: `212.227.13.220` +- no global IPv6 address was visible during inspection +- root filesystem is effectively empty and healthy with ample free space + +Operational consequence: + +- no reinstall is required just to remove Plesk +- proceed with direct bootstrap on the existing new host +- do not publish `AAAA` records for the new host until a real global IPv6 is + present and configured + +### Old production/control-plane VPS `212.227.22.66` + +Confirmed directly over SSH: + +- still the live Forgejo/Woodpecker control-plane host +- stack is still under `/srv/scriptorium-stack` +- containers healthy: + - `forgejo` + - `forgejo-postgres` + - `woodpecker-server` + - `woodpecker-agent` +- current live static roots: + - `/var/www/scriptoriumai` + - `/var/www/verticaltension` + +Important nuance: + +- the old host still has a `*.plesk.page` hostname label +- that does **not** mean active Plesk is still running +- treat it as leftover hostname labeling only + ## Recommended migration method Preferred method: @@ -87,11 +131,12 @@ Recreate on the new host rather than copying blindly: Need: -- new VPS public IPv4 +- new VPS public IPv4: `212.227.13.220` - new VPS public IPv6, if any - root SSH access method -- confirmation that Ubuntu `24.04` is installed -- confirmation whether the IONOS image includes Plesk or any other panel +- confirmation that Ubuntu `24.04` is installed: yes +- confirmation whether the IONOS image includes Plesk or any other panel: + checked directly, no active Plesk present ### DNS and nameserver information @@ -109,6 +154,13 @@ Need: remain untouched - approved TTL-lowering window before cutover +Already clarified: + +- `scriptoriumai.io`, `verticaltension.com`, and `www.verticaltension.com` are + already in production on the old VPS +- `hypertwist.app` is not yet configured for production on the new VPS +- `vectorshell.com` is not yet configured for production on the new VPS + ### Cutover scope Need: @@ -223,6 +275,68 @@ Require all of the following before deleting the old VPS: - Rider remote development connects - Visual Studio remote Linux development connects +## Current source-versus-production parity finding + +This is the key result for migration safety. + +### Source-control parity + +Confirmed: + +- local `HyperTwist` app repo `HEAD` and remote `origin/main` match at: + - `19c8a78f92f6c5d84558cbb57d682288edb302b2` +- local `ScriptoriumAI` repo `HEAD` and remote `origin/main` match at: + - `118a85c0fee3fff34c071dd78d7cfe3eacc8ba95` +- local `VerticalTension` repo `HEAD` and remote `origin/main` match at: + - `91bee21a7101ef08d3e91db9040f8a3ec8d3dd27` + +### Working-tree cleanliness nuance + +Observed locally: + +- `ScriptoriumAI` working tree is dirty +- `VerticalTension` working tree is effectively clean except for an untracked + workspace file + +Operational consequence: + +- if rebuilding from local source, use a clean clone or a clean detached export, + not the current dirty `ScriptoriumAI` working tree + +### Production artifact parity + +The live production web roots on the old VPS are **not** provably identical to +the current local built outputs. + +Observed: + +- production `scriptoriumai.io` `index.html` serves: + - `/assets/index-DKzZ39HF.js` +- current local `C:\ScriptoriumAI\scriptoriumai-ui\dist\index.html` references: + - `/assets/index-B2KwrMUv.js` +- production `verticaltension.com` `index.html` serves: + - `/assets/index-CgVsNXoc.js` + - `/assets/index-ismjD07_.css` +- current local `C:\VerticalTension\dist\index.html` references: + - `/assets/index-ChYBuzHU.js` + - `/assets/index-Ck8vgTXb.css` + +Meaning: + +- source-control heads are safe +- current production artifacts are not byte-for-byte the same as the currently + visible local build outputs +- therefore, if the goal is exact production continuity, migrate the currently + deployed web/app content from the old VPS instead of rebuilding from local + source during cutover + +Recommended safety rule: + +- for zero-surprise cutover, copy the live deployed content from the old VPS +- only do a fresh rebuild/deploy after the new VPS replacement is stable and + only when you intentionally want to refresh production to the current source + state + ## Rider remote-development setup Official source basis: @@ -286,3 +400,109 @@ Next action is to fill the pending-input section above with: Once those are supplied, the live execution pass can begin from the new-host bootstrap phase. + +## DNS record recommendations based on current findings + +### `hypertwist.app` + +Current observed public DNS: + +- `A @ -> 217.160.0.30` +- `AAAA @ -> 2001:8d8:100f:f000::200` + +Recommended production cutover records for the new VPS: + +- change `A @` to `212.227.13.220` +- remove the current `AAAA @` record for now +- add `CNAME www -> hypertwist.app` + +Reason: + +- the new VPS currently has no confirmed global IPv6 +- keeping the placeholder IONOS `AAAA` would continue sending IPv6-capable + clients to the wrong host + +### `vectorshell.com` + +Current observed public DNS: + +- `A @ -> 217.160.0.41` +- `AAAA @ -> 2001:8d8:100f:f000::200` + +Recommended production cutover records for the new VPS: + +- change `A @` to `212.227.13.220` +- remove the current `AAAA @` record for now +- add `CNAME www -> vectorshell.com` + +Keep unchanged: + +- current mail records +- `_domainconnect` +- `_dmarc` +- DKIM-related CNAMEs +- `autodiscover` + +### `scriptoriumai.io` + +Current observed public DNS already points to the old production VPS: + +- `A @ -> 212.227.22.66` +- `A api -> 212.227.22.66` +- `A app -> 212.227.22.66` +- `A ci -> 212.227.22.66` +- `A git -> 212.227.22.66` +- `CNAME www -> scriptoriumai.io` + +Do not change these yet unless the ScriptoriumAI production surfaces are part of +the same cutover window. + +### `verticaltension.com` + +Current observed public DNS already points to the old production VPS: + +- `A @ -> 212.227.22.66` +- `A www -> 212.227.22.66` +- `A api -> 212.227.22.66` +- `A app -> 212.227.22.66` +- `A ci -> 212.227.22.66` +- `A git -> 212.227.22.66` + +Do not change these yet unless VerticalTension is included in the same cutover +window. + +## `www` guidance + +Short answer: + +- `www` is not technically required +- `www` can still be useful +- Google does not need `www` specifically +- the real rule is to choose one canonical host and redirect the other + +Practical recommendation: + +- for new public sites such as `hypertwist.app` and `vectorshell.com`, add + `www` and redirect it to the primary canonical host +- keep apex as canonical if you want consistency with the current + `scriptoriumai.io` setup + +Why `www` can be useful: + +- easier aliasing through `CNAME` +- cleaner future CDN or proxy routing options +- people still type it out of habit + +Why it is not mandatory: + +- search engines treat apex and `www` equally if canonicalization is correct +- there is no inherent SEO advantage just from having `www` + +SSL clarification: + +- the old idea that one certificate class is only for `www` and another is only + for apex is not the general rule here +- with modern certificates, including Let's Encrypt, one certificate can cover + both apex and `www` as SAN entries if you request both names +- the real limitation is DNS and validation wiring, not a universal + `www`-versus-apex certificate class rule