Record VPS migration findings and DNS guidance
This commit is contained in:
axiomlogicnexus
parent
19c8a78f92
commit
5b381dc33e
1 changed files with 223 additions and 3 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue