import-stage: .tasks/ via split (temp prefix, await STATUS.md merge)

git-subtree-dir: .tasks-imported
git-subtree-mainline: c40418239e
git-subtree-split: cbdc2b39aa
This commit is contained in:
2026-05-21 13:48:02 +03:00
14 changed files with 1213 additions and 0 deletions

View File

@@ -0,0 +1,57 @@
# Prompt для следующей сессии
Скопируй этот блок и вставь как первое сообщение:
---
Привет! Возвращаемся к **iis-on-host-migration**. **Перед началом обязательно прочти**:
1. `.wiki/concepts/iis-migration-2026-05-19-postmortem.md` — почему предыдущая попытка сломала prod
2. `.wiki/sources/iis-host-migration-2026-05-19.md` (Phase 9 в конце — про rollback)
3. `.wiki/concepts/recovery-architecture-snapshot.md` (актуальный VM-chain)
**Кратко где мы сейчас (после rollback):**
- Prod снова через VM `snolla-recovery` (как было до session 2026-05-19). 11 main routes + 2 stayer routes в traefik → `host.docker.internal:18080/18180/18181` → VM IIS.
- На хосте есть **inert** артефакты предыдущей попытки миграции — НЕ удалять без явного решения:
- `C:\sites\{snolla, stostayer, stostayer.old, snolla-identity-manager}` — Web.config'и уже patched (sitePath, conn-strings).
- IIS sites/pools `snolla, stostayer, stostayer.old` готовы (.NET v4.0 Integrated, ApplicationPoolIdentity, ACL).
- Traefik backup-stamps `*.bak-phase3-2026-05-19`, `*.bak-stayer-switch-2026-05-19`, `*.bak-hostip-2026-05-19`.
**Цель повторной попытки** — выполнить миграцию по recipe из post-mortem, без повторения 10 ошибок:
1. **Backend port — НЕ :80.** Использовать `:18080` на хосте (старый VM NAT port forward, теперь свободен после `unregistervm` или после остановки VM). Или другой свободный (НЕ совпадающий с traefik publish-ports `:8000, :4443, :8080`). Это избегает Docker NAT loop.
2. **Smoke test с `-MaximumRedirection 0` / `--max-redirs 0`** + read first response. Если `Location` == request URL или близко → loop, fail fast.
3. **Тест из НЕ-LAN сети** (телефон через мобильный интернет, VPS curl) до commit'a — не доверять local smoke.
4. **Параллельный run VM x 24h+**НЕ savestate'ить VM на следующий же день. Держать как hot fallback хотя бы сутки реального трафика.
5. **Atomic revert plan ДО старта** — backup всех traefik yml, написать "если что — paste this" revert-команду заранее.
**Не делай без моего "да":**
- Любые traefik patches (меняет prod-трафик).
- Любые destructive операции на `C:\sites\`, `C:\nas-recovery\vm-sites\`, snolla.ova.
- Глушить VM до подтверждённой 24h+ стабильности host'а.
- Push в git (gitea пока на мёртвой синке, и autopush не разрешён в любом случае).
**Контекстные пароли** (в Web.config / .env, не в чате):
- MSSQL SA: `C:\Users\vitya\projects\docker\diskstation\mssql\.env`
- snolla CMS conn: user `snolla`, password в `C:\sites\snolla\Web.config` (`fXkH4@8O%3pc`)
- stostayer (новый): user `stayer_site`, password в `C:\sites\stostayer\Web.config` (`^I9D)LB)DK)8J#xBDG$t}W&_ioaT!M!LF`, XML-escape!)
- VM SSH: `~/.ssh/id_ed25519_snolla_vm``vitya@127.0.0.1:8022` (NAT-forward)
- VM admin password: `Pryakhin9`
Поехали — но **сначала прочти post-mortem полностью**.
---
## Что почитать AI-агенту перед началом (для самопроверки контекста)
- `.wiki/overview.md` — точки входа
- **`.wiki/concepts/iis-migration-2026-05-19-postmortem.md`** ← critical (10 ошибок + recipe)
- `.wiki/sources/iis-host-migration-2026-05-19.md` (включая Phase 9 в конце)
- `.wiki/sources/nas-recovery-session-2026-05-18.md` — почему вообще этот хост
- `.wiki/concepts/recovery-architecture-snapshot.md` — актуальный VM-chain
- `.wiki/entities/snolla-recovery-vm.md` — VM active prod
- `.wiki/entities/windows-recovery-host.md` — host inert artifacts
- `.wiki/concepts/cms-config-rewrite-pattern.md` — UTF-8 BOM
- `.wiki/concepts/webconfig-password-xml-escape.md``&``&` в conn-string
- `.tasks/STATUS.md`
- `.tasks/iis-on-host-migration.md` — Phase 1-9 история
- Это сообщение

139
.tasks-imported/STATUS.md Normal file
View File

@@ -0,0 +1,139 @@
# Task Board
_Updated: 2026-05-21_
## 🟢 [cms-admin-assets-root-folders-seed] — seed 15 missing root AssetsFolder rows в DB, admin assets открывается
**Status:** done (2026-05-19 вечер). Browser-verified user'ом на pilorama98/emspb. Detail в [[cms-admin-assets-root-folder-seed]].
**Result:** 15 rows inserted (idempotent NOT EXISTS query). Affected: emspb.ru, pilorama98.ru, labtools.pro, kupimknigi.spb.ru, sestech.ru, aquamax.spb.ru, artmone.pro, priemka-kvartiry.ru, profund.spb.ru, ics-artmaterials.com, _voda-indigo.ru + 4 sites с NULL PrimaryDomain. Inserted FolderId/OwnerId captured в `.tasks/cms-admin-assets-root-folders-seed.inserted-rows.txt` для atomic revert.
**Long-term TODO (deferred):** null-guard в `AssetsJsonViewModelBuilder.Build` (CMS code) — defensive fix чтобы не crash'ить если root missing. Требует recompile `MoreThenCms.Admin.dll`, ждёт build env (`vds-kzntsv-bootstrap`).
**Branch:** master
---
## 🟢 [cms-port-leak-fix] — утечка `:8089`/`:4443` в admin URLs закрыта через URL Rewrite serverVariables
**Status:** done (2026-05-19 вечер; verified user-side в браузере, остальные 10 cms работают). Detailed wiki concept — [[cms-server-port-leak-fix]].
**Root cause:** `MoreThenCms.Admin\Mis\Web\Mvc\UrlHelpers\UrlHelpers.cs:14-37` `Url.SiteRoot()` читает `SERVER_PORT`/`SERVER_PORT_SECURE` из server vars, и в attempt2-host setup `SERVER_PORT=8089` → leak. Десятки .cshtml файлов (admin views + `_Layout`/`_LogInLayout`) рендерят это в `mis.siteRoot` и `<style background: url(...)>`. На VM работало просто потому что `SERVER_PORT=80` (см. SSH probe VM IIS bind = `*:80`).
**Path tried (failed):** **B (traefik http entrypoint :80→:8090 + backend `host.docker.internal:80`)** — Docker Desktop's WSL2 NAT proxy на Windows перехватывает `host.docker.internal:80`/`gateway.docker.internal:80`/LAN IP :80 и возвращает 301 plain text **независимо** от того что traefik listening на :8090 inside. Quirk Windows Docker Desktop, не traefik. Не работает на этом стэке.
**Path applied (working):** **C (URL Rewrite 2.1 + serverVariables в Web.config)**:
1. URL Rewrite 2.1 MSI installed (rewrite_amd64_en-US.msi, 6 MB, version 7.1.1993.2351).
2. `applicationHost.config` (admin): `<system.webServer>/rewrite/allowedServerVariables` += `HTTPS`, `SERVER_PORT`, `SERVER_PORT_SECURE` через `appcmd set config ... /commit:apphost`. Backup `.bak-pre-portleak-2026-05-19`.
3. `C:\sites\snolla\Web.config` (per-site): `<system.webServer>/rewrite/rules` += rule "ForwardedProto-HTTPS" — match `.*`, condition `HTTP_X_FORWARDED_PROTO == "https"`, action None, serverVariables set `HTTPS=on`, `SERVER_PORT=443`, `SERVER_PORT_SECURE=1`. Backup `Web.config.bak-pre-portleak-2026-05-19` (size 19050 bytes). UTF-8 BOM сохранён.
4. Smoke через `docker exec traefik wget https://127.0.0.1:443/admin/account/login --header='Host: emspb.snolla.com'` (через полный traefik HTTPS chain, traefik 2.x шлёт X-Forwarded-Proto: https автоматом) → `mis.siteRoot = 'https://emspb.snolla.com'` (БЕЗ `:8089`) ✅. То же для `labtools.snolla.com` ✅. **Затрагивает все 11 cms hosts** (общий site `snolla`).
**Verified:** user-side public browser test confirmed — admin SPA loads без `:8089` в URL'ах для остальных 10 cms hosts. **Side regression** (pre-existing `customErrors mode="off"` lowercase — fatal config error после ASP.NET full-reload) — пойман и пофиксен (`mode="Off"`). **Outside scope (открыт):** `emspb.snolla.com /admin/assets/<guid>/getList` → 500 NullRef в `AssetsJsonViewModelBuilder.cs:22` (`model` null от `_assetsFoldersService.GetFolderByPath(ctx, ownerId, '')`) — user подтвердил «только этот site», CMS-side bug, не в scope. Зафиксировано в `recovery-architecture-snapshot` open issue #8.
**Atomic revert:** `Copy-Item C:\sites\snolla\Web.config.bak-pre-portleak-2026-05-19 C:\sites\snolla\Web.config -Force` + ~3 сек app pool reload. apphost allowedServerVariables можно оставить (inert без rule). URL Rewrite MSI можно оставить (no rules = no behavior).
**Branch:** master
---
## 🟢 [vds-kzntsv-bootstrap] — VDS поднят, gitea/verdaccio/registry мигрированы (3/3 phases done 2026-05-20)
**Status:** done (2026-05-20 вечер — все 3 заявленные фазы закрыты)
**Where I stopped:** Phase 1 + Phase 2 завершены ✅. VDS `89.253.255.94 / vds.kzntsv.site` Ubuntu 24.04 upgraded через VNC. sudo vitya (NOPASSWD) + ssh-key + hardened sshd (key-only) + ufw 22/80/443 + DB-порты + fail2ban + docker 29.5.1 + buildx + compose. Traefik v2.11 на `traefik.vds.kzntsv.site` (basicAuth vitya:Pryakhin9). Portainer CE 2.21.5 на `portainer.vds.kzntsv.site`**админ-пароль был принудительно изменён на `Pryakhin9-VDS-2026` (18 chars)** из-за hard min-12-char policy в Portainer 2.21+ (regression от 2.20). API key получен и сохранён в `vds-kzntsv.env`. 4 DB-стека (Postgres 16, MariaDB 11.4, Mongo 7, Redis 7) подняты с self-signed TLS, доступны снаружи через traefik raw-TCP passthrough на `<db>.vds.kzntsv.site:<port>` (HostSNI(*) — traefik tls.passthrough+SNI не работает с STARTTLS-протоколами PG/MariaDB; rawTCP forward, DBs терминируют TLS сами). Все DB passwords (PG/Maria/Mongo/Redis) — strong random hex16, сохранены в `vds-kzntsv.env`.
**Open questions:** LE certs для DBs (сейчас self-signed → клиент verify-skip; permanent fix позже через lego sidecar extract из traefik acme.json).
**Next action:** Phase 3 миграция с kreknin **ВСЯ DONE ✅**. 3.1 gitea (132 repos, 4 users, v1.25.5 на git.kzntsv.site). 3.2 verdaccio (8.6G storage, 2063 packages, secret 32 chars). 3.3 registry — **отказались от миграции** старых 35G images (user: «новых наделать могу»), fresh install на registry.kzntsv.site + Joxit UI на registry-ui.vds.kzntsv.site (DELETE_IMAGES=true для GUI cleanup, REGISTRY_STORAGE_DELETE_ENABLED для API delete). Auth vitya:Pryakhin9 (см. vds-kzntsv.env). Follow-up tasks: vds-gc-cron, vds-backup-rsync-kreknin, vds-ntfy-push.
**Branch:** master
---
## 🟢 [iis-on-host-migration] — attempt 2 close-out: 36h soak passed, 8/8 наших sites зеленые
**Status:** done (2026-05-21 close-out). Detail: Phase 11 в [iis-host-migration-2026-05-19](../.wiki/sources/iis-host-migration-2026-05-19.md).
**Close-out evidence:** traefik `Up 38h` (zero restarts), w3wp 8.8h (scheduled pool recycle ~29h default, не crash), 8/8 наших sites вернули `Microsoft-IIS/10.0` через full traefik HTTPS chain (`emspb/snolla/on.snolla/pilorama98/labtools.ru/labtools.pro/tandemmebel/kupimknigi`). Маljarka/sestech/ics-artmaterials оказались **off-infra** (DNS снят / parked / external nginx) — не наша инфра, не regression. Новая follow-up task ⚪ `iis-traefik-dead-routes-cleanup` (низкий приоритет — почистить yml для 3 dead доменов).
**VM savestate:** **done 2026-05-21 05:13 MSK** (45.6s, VMState=saved). Savestate file 1.73 GB (`C:\Users\vitya\VirtualBox VMs\snolla-recovery\Snapshots\2026-05-21T05-12-43-636491200Z.sav`). VBoxHeadless процессы освободили ~4 GB private memory. Resume: `VBoxManage startvm snolla-recovery --type headless` (~30 сек если понадобится). Disk delete (`unregistervm --delete`, ~95 GB) — позже через неделю uptime.
**Atomic revert (unchanged):** ```Get-ChildItem C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\*.yml.bak-pre-attempt2-2026-05-19 | %{ Copy-Item $_.FullName -Destination ($_.FullName -replace '\.bak-pre-attempt2-2026-05-19$','') -Force }; Move-Item C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\stostayer.yml.disabled C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\stostayer.yml -Force -EA SilentlyContinue; Move-Item C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\oldstostayer.yml.disabled C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\oldstostayer.yml -Force -EA SilentlyContinue; docker restart traefik```
**Branch:** master
---
## 🟢 [iis-traefik-dead-routes-cleanup] — sestech + isc-artmaterials disabled, maljarka оказалась live
**Status:** done (2026-05-21 ~05:42 MSK; ~20 мин работы).
**Result:**
- `sestech.yml` → `.disabled` (backup `.bak-pre-dead-routes-cleanup-2026-05-21`). DNS `sestech.ru/www.sestech.ru → 31.31.205.163` = parking provider, наш traefik больше не отвечает (public requests идут на parking host через DNS).
- `isc-artmaterials.yml` → `.disabled` (backup created). DNS `ics-artmaterials.com/www → 87.236.16.28 = external nginx-reuseport WP-хостинг`, public traffic не через нас.
- **Maljarka — НЕ disabled** — оказалось yml route'ит `maljarka.tandemmebel.ru` (subdomain тандеммебели), не голый `maljarka.ru`. DNS → **94.19.247.14 = наш IP**, IIS backend отвечает 200 OK ("Малярка от Тандеммебель", 43KB). Live route, не dead. Изначальная task'а ошиблась с hostname.
**Smoke regression:** 4 live hosts (emspb/on.snolla/www.tandemmebel/kupimknigi) → Microsoft-IIS/10.0 без regression. File-provider auto-reload, traefik restart не понадобился.
**Side finding:** `maljarka.tandemmebel.ru` через traefik HTTPS → **502 Bad Gateway**, хотя backend (host.docker.internal:8089 + Host header) возвращает 200 OK. Конфиг yml identical к работающему `tandemmebel.yml`. Live bug. Новая follow-up ⚪ task `traefik-maljarka-502-bug`.
**Atomic revert:** ```Move-Item C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\sestech.yml.disabled C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\sestech.yml -Force; Move-Item C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\isc-artmaterials.yml.disabled C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\isc-artmaterials.yml -Force```
**Branch:** master
---
## 🟢 [traefik-maljarka-502-bug] — diagnosed: root cause = CMS-side, не traefik
**Status:** done (2026-05-21 — diagnosed; fix отложен в новую ⚪ task [[cms-maljarka-https-mode-bug-fix]]).
**Root cause найден через bisect headers:** IIS+CMS возвращает **502 specifically для `Host: maljarka.tandemmebel.ru` + `X-Forwarded-Proto: https`**. Другие cms hosts (tandemmebel, emspb, etc.) с XFP=https → 301/200 корректно. Без XFP=https maljarka → 200 OK (43KB "Малярка от Тандеммебель"). Mechanism: URL Rewrite rule из [[cms-server-port-leak-fix]] ставит HTTPS=on/SERVER_PORT=443 → CMS код падает specifically для этого hostname в HTTPS-context (NullRef / missing config / redirect loop — нужно искать). Same class как `emspb /admin/assets 500 NullRef`, `rimiz.ru 404` — pre-existing CMS issues выявленные миграцией.
**Side findings:**
1. **Traefik file-watch broken под Docker Desktop Windows** (WSL2 9p mount не пропускает inotify) — обнаружено через тест: rename .yml → .disabled, route остаётся active в runtime. Wiki concept [[traefik-file-watch-wsl2-broken]] с workarounds. Любой config change требует `docker restart traefik`.
2. **Dead routes cleanup был фантомным** до restart — sestech/ics-artmaterials .disabled только сегодня стали реально 404'нуться (после моего restart 07:42 UTC).
**Verification post-restart:** 7 live hosts (emspb/on.snolla/www.tandemmebel/kupimknigi/pilorama98/labtools.ru/labtools.pro) — Microsoft-IIS/10.0 ✅ без regression. 2 dead routes (sestech, ics-artmaterials) → 404 (cleanup теперь real). Maljarka 502 — без изменений (CMS-side, не traefik).
**Branch:** master
---
## ⚪ [cms-maljarka-https-mode-bug-fix] — `maljarka.tandemmebel.ru` падает 502 в HTTPS-mode IIS
**Status:** ready (заведена 2026-05-21 как follow-up к diagnosed [[traefik-maljarka-502-bug]]). Полный mechanism в [[cms-maljarka-https-mode-crash]] wiki concept.
**Scope:** CMS code (или CMS DB config) для `maljarka.tandemmebel.ru` ASP.NET-падает с 502 когда `HTTPS=on`/`SERVER_PORT=443` server vars выставлены URL Rewrite rule'ом. Без HTTPS-context — 200 OK. Эффект: site недоступен через публичный HTTPS chain.
**Next action:**
1. IIS logs `C:\inetpub\logs\LogFiles\W3SVC*\` — найти request с Host=maljarka.tandemmebel.ru + XFP=https, sub-status code.
2. Event Viewer → Application → ASP.NET errors с stack trace.
3. CMS DB: per-host config table — есть ли запись для maljarka.tandemmebel.ru с HttpsUrl/BaseUrl/etc.
4. Если quick fix критичен: workaround A в wiki concept (strip X-Forwarded-Proto в maljarka middleware) или workaround B (negate condition в URL Rewrite rule).
**Priority:** depends — насколько критичен maljarka.tandemmebel.ru для tandemmebel.ru клиента. Если real customer traffic — high. Если test/internal subdomain — low.
**Branch:** master
**Done:** bak-серия `.bak-pre-attempt2-2026-05-19` для 13 yml; IIS binding `snolla *:8089` + Stop/Start Website; loop-detect через `host.docker.internal:8089` ≠ NAT loop (resolves to 192.168.65.254 host gateway) ✅; 11 cms yml (snolla, rimiz, labtools, labtoolspro, pilorama98, tandemmebel, emspb, kupimknigi, maljarka, sestech, isc-artmaterials) patched `:18080 → :8089`; host-side smoke 20 hostnames → все `Server: Microsoft-IIS/10.0` ✅; 📱 phone-tests (mobile internet): `emspb.ru` ✅, `labtools.ru` ✅; traefik logs clean (only known docker.sock noise); pre-existing CMS issues подтверждены и НЕ regression: `rimiz.ru/ics-artmaterials.com 404` (CMS-routing); `snolla.com` 301 → `on.snolla.com` (canonical default subdomain), `on/pilorama98/labtools/emspb.snolla.com` 200 OK.
**Done (stayer):** stayer routes user'ом подтверждены «внутренние, наружу не светим» → `stostayer.yml → stostayer.yml.disabled`, `oldstostayer.yml → oldstostayer.yml.disabled`; `docker restart traefik`; verify: `stostayer.snolla.com`/`old.stostayer.ru` → 404 traefik no-route ✅; host IIS sites `stostayer :8090`/`stostayer.old :8091` остаются live для прямого/локального доступа (CMS отвечает контент, headers stripped через WinHTTP proxy на curl, но изнутри traefik / production-path headers Microsoft-IIS/ASP.NET корректные).
**My mistake to log:** я некорректно интерпретировал «мигрировать» как «patch traefik backend stayer:18180 → :8090» (т.е. пускать через traefik наружу). User имел в виду «host IIS уже есть, traefik routes должны быть DISABLED». Сделал patch backend → user интервент-stop → revert + rename `.disabled`. Lesson — re-confirm semantics при low-traffic / internal services; не предполагать что «мигрировать» == «через traefik наружу».
**Where I stopped:** 14 cms hosts через host IIS:8089, stayer routes наружу выключены. Soak в процессе.
**Next action:** (a) phone-test 2-3 random cms domains; (b) wait 24h+ uptime; (c) docs: post-success wiki ingest + update `recovery-architecture-snapshot.md` (stayer = disabled, не migrated); (d) только после 24h+ + zero rollbacks → consider savestate VM.
**Atomic full revert (paste-ready):** ```Get-ChildItem C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\*.yml.bak-pre-attempt2-2026-05-19 | %{ Copy-Item $_.FullName -Destination ($_.FullName -replace '\.bak-pre-attempt2-2026-05-19$','') -Force }; Move-Item C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\stostayer.yml.disabled C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\stostayer.yml -Force -EA SilentlyContinue; Move-Item C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\oldstostayer.yml.disabled C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\oldstostayer.yml -Force -EA SilentlyContinue; docker restart traefik```
**Branch:** master
---
## 🟢 [vds-gc-cron] — weekly GC armed для verdaccio + registry на VDS
**Status:** done (2026-05-21 00:21 MSK; ~1ч работы). Детали в [vds-gc-cron.md](vds-gc-cron.md).
**Result:** `/etc/cron.d/vds-gc` armed — Sun 03:00 MSK registry-gc.sh, Sun 03:30 MSK verdaccio-prune.sh. Scripts в `/opt/stacks/gc/scripts/` (`notify.sh`, `registry-gc.sh`, `verdaccio-prune.sh`+`verdaccio-prune.js`). Logs в `/var/log/vds-gc/`. Notify через ntfy `vds-ops`.
**Verdaccio prune real run:** 8.5G → 6.8G (freed 1.7G), 7021 packages scanned, 1551 modified, 4524 tgz deleted, 0 errors, 73 locally-published versions защищены (@snollajs/* + similar — detected via `_distfiles[tgzName]` absent). Atomic JSON rewrite (`tmp + rename`) + `_rev` bump.
**Registry GC smoke:** alpine v1+v2 pushed → DELETE manifest → GC freed 61M (whole tree, since both tags pointed одну digest). Empty-storage guard added (first run на свежем registry — `/var/lib/registry/docker/registry/v2/repositories` отсутствует → skip+min-prio notify, не FAIL).
**Atomic revert:** `ssh vitya@89.253.255.94 'sudo rm /etc/cron.d/vds-gc; sudo systemctl restart cron; sudo rm -rf /opt/stacks/gc /var/log/vds-gc'`
**Branch:** master
---
## 🟢 [vds-backup-rsync-kreknin] — daily VDS→kreknin live, smoke green, cron armed
**Status:** done (2026-05-20 → 2026-05-21 00:00 first-run завершён успешно). Детали в [vds-backup-rsync-kreknin.md](vds-backup-rsync-kreknin.md).
**Result:** rsync `--link-dest` pipeline `/opt/stacks/backup/scripts/run.sh` под cron `0 5 * * *` (root) → kreknin `/volume1/NetBackup/vds-kzntsv/<DATE>/` + symlink `latest`. DB dumps (pg/maria/mongo/redis), system config (/etc/ssh, ufw, hosts, docker), ssh keys, /opt/stacks data. Notification dual-channel: email через msmtp+Yandex (`/etc/msmtprc`) + ntfy publish на `vds-backup` topic. Retention 7 daily snapshots. Smoke run done — 71,867 files / 11.74G в 21m27s, exit 0. Cron service installed (apt install cron — Ubuntu 24.04 не имел его) + enabled. Next run автоматически 2026-05-21 05:00 MSK.
**SPOF gap status:** closed for VDS — full restore from kreknin возможен (DB dumps + конфиги + ssh keys).
**Open:** phone-side smoke (user verifies ntfy push пришёл из реального backup run).
**Atomic revert:** `ssh vitya@89.253.255.94 'sudo systemctl stop cron; sudo rm /etc/cron.d/vds-backup; sudo apt-get remove -y cron msmtp msmtp-mta; sudo rm -rf /etc/msmtprc /opt/stacks/backup /var/log/vds-backup'`
**Branch:** master
---
## 🟢 [vds-ntfy-push] — self-hosted ntfy.vds.kzntsv.site live, phone-verified
**Status:** done (2026-05-20 вечер; ~30 min работы). Detail в [vds-ntfy-push.md](vds-ntfy-push.md).
**Result:** ntfy v2.11.0 на `ntfy.vds.kzntsv.site`, LE cert (R12, valid до 2026-08-18), admin user `vitya / Pryakhin9` (deny-all дефолт, admin role → rw to all), топики `vds-backup` + `vds-ops`. Phone-verified — оба push'а пришли в Android ntfy app (screenshot 22:54). Creds в `~/projects/.common/secrets/vds-kzntsv.env` + `/opt/stacks/ntfy/.env` (chmod 600).
**Integration ready for:** [[vds-backup-rsync-kreknin]] (publish status на `vds-backup`), monitoring scripts (на `vds-ops`).
**Atomic revert:** `ssh vitya@89.253.255.94 'cd /opt/stacks/ntfy && docker compose down -v && cd .. && rm -rf ntfy'` + remove ntfy entries из vds-kzntsv.env.
**Branch:** master
---
## 🟢 [nas-recovery] — клиентские сайты восстановлены, работают из публичного интернета
**Status:** done (2026-05-19 ~10:00 MSK — 15 часов работы)
**Final state:** OpenWRT NAT → traefik 2.6.6 (host:8000/4443) → VirtualBox VM snolla-recovery (IIS + CMS) + docker-стек на хосте (MSSQL/MinIO/ES/imgproxy/nginx). 13 client routes, 40 LE certs валидны. Проверено: пользовательский клиент из публичного интернета открывает snolla.com, pilorama98.ru, labtools.ru/pro, tandemmebel.ru, emspb.ru.
**Backup pull:** C:\nas-recovery\vm-sites\ (~11 GB inetpub/wwwroot + stayer/) — на случай если VM снова станет нестабильной.
**Open issues (минор):**
- X-Forwarded-Proto/Host: CMS делает redirect с портом 4443 в URL — нужно добавить middleware в traefik или включить trust в IIS.
- MinIO/Azure storage — пользователь упомянул "не так всё", ждём пояснение.
- docker-сокет проброс в traefik — daemon connection error (некритично, file-provider routing работает).
- VM в bridged-WiFi была нестабильной → переехали на NAT + port forwards.
- acme.json renewal через HTTP-01 фейлится для доменов с DNS не на нашем IP — нужно переключить на DNS-01 через REGRU (creds в env уже).
**Branch:** master
---
<!--
Status legend:
🔴 Active — only one at a time
🟡 Paused — in progress, resumable
⚪ Ready — defined, not started
🟢 Done — kept until merged
🔵 Blocked — waiting on external input
-->

View File

@@ -0,0 +1,21 @@
(15 rows affected)
Tag,FolderId,OwnerId
---,--------,-------
INSERTED-ROW,580369C8-DB8B-4352-97EB-4F525C989A7C,07E0290C-8735-474E-B494-1230C1E259B3
INSERTED-ROW,52A0DE78-BF1C-4F6D-BE2E-7C401D64F690,96EBC481-D26A-47BE-B660-13D49E7D0A61
INSERTED-ROW,465E2F07-525B-4772-BBEB-F7965F605966,81B2461F-78C0-40DF-9B13-2B255DE502FC
INSERTED-ROW,03150541-5278-4FB5-B815-630A17611B3D,E924A354-0377-4E1E-80C6-2EB0194AA55F
INSERTED-ROW,228DDFE9-112E-42BB-8B61-CF88163B94AA,C3B1FD79-663D-4271-A251-380E8B74EB7F
INSERTED-ROW,775F159A-72B7-4B2C-BF13-E57F84BDFCCE,2C82EF33-009E-4779-A51E-389C65D4A3D4
INSERTED-ROW,0E6B2936-0522-4897-814E-B16FB4091B4C,663F9410-A6CC-4651-9A5C-62844A313957
INSERTED-ROW,4BD7784F-7BA4-431B-952A-33D422161191,F8FBBF59-8F34-4327-96CA-63A8103D8EE6
INSERTED-ROW,878D64DF-07B5-4973-BAA4-BC7DA4C7C8BE,4DC7E9E4-8D5D-4ECC-9459-84F7A1BF1759
INSERTED-ROW,9F368D86-9CB0-48FD-A871-1AA565808BE8,D8E84734-9E35-414D-9342-862A63AD87FB
INSERTED-ROW,542AFFDC-4632-4080-B6C6-19611FB2CEA2,592D399B-31C0-4150-9BFD-880CF7A244C5
INSERTED-ROW,A7B028C1-D6BD-49FA-8C16-93CF566C6101,37E67FC4-4B9E-4C06-A522-A26A73BAC9B0
INSERTED-ROW,7AA0D6AC-94F1-49B7-8FFE-A13A15144A84,F30E83BB-2FCA-40A1-A658-AE7ED22F294F
INSERTED-ROW,6033AC61-19F0-4A4C-AD5E-BE54DE64DF6A,5A826EB9-A05A-41D4-A29C-BDEBE926E8DB
INSERTED-ROW,AF61A942-23D0-469C-BB89-B7294BD1DB68,1F12D23C-A9A2-4863-A94D-C6278AD7835E
(15 rows affected)

View File

@@ -0,0 +1,74 @@
# cms-admin-assets-root-folders-seed
## Goal
Для каждого `Sites.SiteId` в DB `MoreThenCms` где нет соответствующего root `Folders` row с `Discriminator='AssetsFolder'`, `LoweredPath='/'`, `OwnerId=<SiteId>` — добавить недостающий root row. Это unblock'нёт admin `/admin/assets/<siteId>/getList?path=` который сейчас crash'ит 500 NullReferenceException на пустых assets для 15+ sites (включая `emspb.ru`, `pilorama98.ru`, `labtools.pro`, `kupimknigi.spb.ru`, `sestech.ru`, etc.).
## Root cause
`MoreThenCms.Admin.ViewModels.Builders.AssetsJsonViewModelBuilder.Build` (`AssetsJsonViewModelBuilder.cs:22`) делает `new JValue(model.ParentPath)` БЕЗ null-check на model. `_assetsFoldersService.GetFolderByPath(ctx, ownerId, '')` возвращает null когда root folder не существует. Это происходит для sites которые **никогда не открывали admin assets UI** (root создаётся lazy при first upload, видимо).
Frontend код (`AssetsAppFunc.cs:66-86`) делает proper null-check → HTTP 404. Только admin view-model builder упустил.
Двух-уровневое решение:
- **Краткосрочно (этой task'и):** seed missing root rows в DB. Один INSERT per site. Risk: minimal (lookup existing row pattern; используем same shape).
- **Долгосрочно (отдельный task):** patch `AssetsJsonViewModelBuilder.Build` → null-guard → empty response. Требует recompile DLL `MoreThenCms.Admin.dll` (нет полного build env, рискованно).
## Key files
- `MoreThenCms\Assets\Services\AssetsFoldersService.cs:47-54``GetFolderByPath` query (returns null if not found).
- `MoreThenCms.Web\ViewModels\Builders\AssetsJsonViewModelBuilder.cs:22` — точка падения.
- `MoreThenCms.Web\Admin\Controllers\AssetsController.cs:44-54` — вызов GetList.
- DB: `[MoreThenCms].[dbo].[Folders]` (polymorphic, Discriminator='AssetsFolder' для assets).
## Discovery (2026-05-19)
- 15 sites без root AssetsFolder подтверждены через `SELECT s.SiteId, s.PrimaryDomain, ... FROM Sites s LEFT JOIN ...`. См. полный список в Decisions.
- Sample existing root row: `FolderId=1591A38C-..., OwnerId=7EB313DD-F289-..., Path='/', LoweredPath='/', DateCreated=2017-03-13 07:10:15, CreatedById=E4CC416B-...`. Тот же shape надо воспроизвести для missing.
- Затрагивает: emspb.ru (`96EBC481-...`), pilorama98.ru (`37E67FC4-...`), labtools.pro, kupimknigi.spb.ru, sestech.ru, aquamax.spb.ru, artmone.pro, priemka-kvartiry.ru, profund.spb.ru, ics-artmaterials.com, _voda-indigo.ru, plus 4 sites с NULL `PrimaryDomain`.
## План
1. **Dry-run**: `SELECT COUNT(*) FROM Sites s WHERE NOT EXISTS (root for s.SiteId)` — должно быть = 15 (sanity check).
2. **Seed**: INSERT root row per missing site. Один transaction, no rollback unless count mismatch.
3. **Verify**: повторить original probe — root count should be 0 missing.
4. **Test**: hit `https://emspb.snolla.com/admin/assets/96EBC481-.../getList?path=` (через docker exec без auth → 302→login без crash). Затем user-side browser test.
## SQL
```sql
DECLARE @CreatedById uniqueidentifier = (
SELECT TOP 1 CreatedById FROM Folders
WHERE LoweredPath='/' AND Discriminator='AssetsFolder'
);
INSERT INTO Folders (FolderId, OwnerId, Path, LoweredPath, DateCreated, UtcDateCreated, CreatedById, Discriminator)
SELECT NEWID(), s.SiteId, '/', '/', SYSDATETIME(), SYSUTCDATETIME(), @CreatedById, 'AssetsFolder'
FROM Sites s
WHERE NOT EXISTS (
SELECT 1 FROM Folders f
WHERE f.OwnerId = s.SiteId
AND f.LoweredPath = '/'
AND f.Discriminator = 'AssetsFolder'
);
```
## Atomic revert
Сохранить список inserted FolderId через `OUTPUT INSERTED.FolderId` в temp file. Если что:
```sql
DELETE FROM Folders WHERE FolderId IN (<list>);
```
## Open questions
- [ ] Аналогичная проблема для ImagesFolder/StylesheetsFolder/ScriptsFolder в admin Themes UI? Проверить.
- [ ] DLL patch `AssetsJsonViewModelBuilder.Build` нужен в долгую — отдельная task. Сейчас обходим seed'ом.
## Decisions log
- 2026-05-19: вынес из `cms-port-leak-fix` (там был open issue #8 на emspb). User подтвердил воспроизводимость на pilorama98 → не site-specific, общая data issue.
- 2026-05-19: **DB seed применён** — 15 rows inserted (single transaction, idempotent NOT EXISTS). Inserted FolderId/OwnerId captured в `cms-admin-assets-root-folders-seed.inserted-rows.txt`. Server-side verified (probe вернул 302→login вместо 500). User browser-verified на pilorama98/emspb — admin assets открывается, empty list без ошибок.
- 2026-05-19: **DLL recompile отложен**`AssetsJsonViewModelBuilder.Build` нужен null-guard как defensive code, но требует build env (нет gitea/build/registry на recovery host'е). Ждёт [[vds-kzntsv-bootstrap]] для восстановления pipeline'а. На текущем seed-only fix'е admin assets работает для всех 15 sites.
## Completed steps
- [x] Diagnostic: stack trace из Application event log → `AssetsJsonViewModelBuilder.cs:22` NullRef on `model.ParentPath`. Source code analysis показал отсутствие null-check (vs proper null-check во frontend `AssetsAppFunc.cs:66-86`).
- [x] DB probe schema: `Folders` table polymorphic с Discriminator, columns FolderId/OwnerId/Path/LoweredPath/DateCreated/CreatedById обязательные.
- [x] Dry-run: 15 sites без root AssetsFolder (включая emspb/pilorama98/labtools.pro/kupimknigi/sestech/etc), 4 sites с NULL PrimaryDomain тоже в списке.
- [x] **SQL seed** через `docker exec mssql sqlcmd` — INSERT 15 rows с `OUTPUT INSERTED.FolderId, INSERTED.OwnerId INTO @Inserted`, output saved в `.tasks/cms-admin-assets-root-folders-seed.inserted-rows.txt`.
- [x] Verify: missing-root count = 0. Probe `wget --header='Host: emspb.snolla.com'` на getList URL → 302 Found (auth redirect — normal), нет больше 500.
- [x] User browser-verified pilorama98 admin assets открывается.
- [x] Wiki ingest: новый concept `cms-admin-assets-root-folder-seed.md`, snapshot issue #8 → resolved, `cms-server-port-leak-fix` sibling-link, log.md + index.md обновлены.
## Notes
- Связано: [[cms-server-port-leak-fix]] (предыдущая task'а закрыта; admin URLs теперь без `:8089`); [[recovery-architecture-snapshot]] (issue #8 — resolved); [[vds-kzntsv-bootstrap]] (build env для долгосрочного DLL fix'а).

View File

@@ -0,0 +1,52 @@
# cms-maljarka-https-mode-bug-fix
## Goal
Починить `maljarka.tandemmebel.ru` чтобы он отвечал 200 (не 502) через публичный HTTPS chain. Root cause diagnosed в [[traefik-maljarka-502-bug]]: IIS+CMS падает на этом hostname когда `HTTPS=on`/`SERVER_PORT=443` выставлены URL Rewrite rule'ом. Full mechanism — wiki concept [[cms-maljarka-https-mode-crash]].
## Key files
- `C:\sites\snolla\Web.config` — URL Rewrite rule "ForwardedProto-HTTPS" из [[cms-server-port-leak-fix]]
- `C:\inetpub\logs\LogFiles\W3SVC*\` — IIS logs site `snolla` (нужно найти sub-status 502.x для конкретного request)
- CMS DB — table с per-host config (per [[recovery-architecture-snapshot]], CMS использует MSSQL контейнер)
- CMS source: `MoreThenCms.Admin\Mis\Web\Mvc\UrlHelpers\UrlHelpers.cs:14-37` (`Url.SiteRoot()`) — паттерн из [[cms-server-port-leak-fix]]; возможно тут helper падает specifically на этом host
## Bisect-trace evidence
```
direct backend Host: maljarka.tandemmebel.ru → 200 OK (43KB)
direct backend Host: maljarka.tandemmebel.ru + X-Forwarded-For → 200 OK
direct backend Host: maljarka.tandemmebel.ru + X-Forwarded-Proto:https → 502 ← триггер
direct backend Host: tandemmebel.ru + X-Forwarded-Proto:https → 301 (correct)
```
Single variable: `X-Forwarded-Proto: https` для этого specific hostname.
## Next action
1. **IIS logs**:
```powershell
Get-Content 'C:\inetpub\logs\LogFiles\W3SVC1\u_extend1*.log' -Tail 500 | Select-String 'maljarka' | Select-Object -Last 20
```
Найти sub-status (502.3 = bad gateway, 502.4 = no server, 502.5 = ARR config, etc.).
2. **Event Viewer**:
```powershell
Get-EventLog -LogName Application -Source 'ASP.NET*' -Newest 50 | Where-Object Message -Match 'maljarka' | Format-List
```
Stack trace покажет точное место crash.
3. **CMS DB inspection** — есть ли запись для `maljarka.tandemmebel.ru` в table с per-host URLs, и поле HttpsUrl/BaseUrl не NULL ли там.
4. **Quick workaround если real customer traffic** — apply Workaround B из [[cms-maljarka-https-mode-crash]] (negate condition в URL Rewrite rule for this Host). Backup Web.config first.
## Open questions
- [ ] Какой priority? Зависит от того real customer traffic на `maljarka.tandemmebel.ru` или это internal/test subdomain.
- [ ] Если CMS bug — fix CMS code или DB hot-fix?
- [ ] DLL patch для null-guard (от [[cms-admin-assets-root-folders-seed]]) — может тот же класс bugов; может в одном вылазе чинить вместе.
## Notes
- 3 workarounds + 5 investigation places задокументированы в [[cms-maljarka-https-mode-crash]] wiki concept.
- Не trivially связан с [[cms-server-port-leak-fix]] — там URL Rewrite rule добавлен правильно, но CMS код в этом конкретном случае ломается. Регрессия CMS, не fix'а.

View File

@@ -0,0 +1,104 @@
# cms-port-leak-fix
## Goal
Убрать утечку internal-портов в URL'ы, которые CMS генерирует серверно. Сейчас часть admin-роутов выдают URL'ы вида `https://labtools.snolla.com:8089/admin/...``:8089` это IIS site binding на хосте, не должен попадать наружу.
Связанный, тот же класс баг (open issue #1 в [recovery-architecture-snapshot.md](../.wiki/concepts/recovery-architecture-snapshot.md)): CMS делает HTTP→HTTPS redirect с `:4443` (traefik external HTTPS port на хосте). Желательно фиксить общим решением.
## Симптомы (от user, 2026-05-19)
Сломанные URLs admin'ки на `labtools.snolla.com` (наверняка и на остальных 10 cms доменах тоже):
- `https://labtools.snolla.com:8089/admin/assets/<guid>/getList?path=`
- `https://labtools.snolla.com:8089/admin/themes/getImageSizes/`
- `https://labtools.snolla.com:8089/admin/templates/editors.tmpl.html?v=2.006`
Browser сразу делает request на `:8089` напрямую → fail (этот порт не открыт наружу через router NAT; traefik слушает 443/4443 only).
## Hypothesis — root cause
Цепочка:
1. Traefik backend = `http://host.docker.internal:8089/`, `passHostHeader: true` → IIS видит `Host: labtools.snolla.com` (без порта).
2. IIS binding на site `snolla` = `*:8089` → connection-level порт = 8089.
3. `HttpRequest.Url.Port` / `Url.Authority` в ASP.NET возвращают **порт сокета**, не порт из Host header. Значит `Authority = "labtools.snolla.com:8089"`.
4. Где-то в admin views / controllers / partials CMS строит absolute URL через `Request.Url.GetLeftPart(UriPartial.Authority)` или `string.Format("{0}://{1}", scheme, host_with_port)` → утечка `:8089`.
5. Альтернатива — admin SPA получает baseUrl в server-rendered JS-переменной (`window.adminBaseUrl = '@Request.Url.Scheme://@Request.Url.Authority/admin'` или подобное). Это нужно подтвердить grep'ом по deployed-ASP-views + .js.
Аналогичная hypothesis для `:4443`:
- Не из `Url.Port` (он = 8089 на attempt2-host, был 18080 на VM-эпохе).
- Скорее CMS читает `Request.Headers["X-Forwarded-Host"]` который traefik по умолчанию шлёт как `host:port`, ИЛИ кто-то один раз протестил через `https://host:4443/` напрямую и попал в captured-redirect.
- Возможно: CMS делает `Response.Redirect` с absolute URL, и старый CMS-код в эпоху production-traefik (на синке тоже :4443?) научился возвращать публичный port из конфига.
- **Эта часть требует тест-кейса** — повторить на host'е сейчас и посмотреть, попадает ли вообще `:4443` в response Location header.
## Key files (текущие deployed)
- `C:\sites\snolla\Views\Shared\_Layout.cshtml` — main layout, есть `var hostingUrl = new Uri("https://" + AppSettings["primaryDomain"]);` (line 11-12). Не порт, но паттерн «строим absolute URL» подсветить.
- `C:\sites\snolla\Areas\Admin\Views\_ViewStart.cshtml` — корень всех admin views, скорее всего тянет admin-specific layout.
- `C:\sites\snolla\Areas\Admin\Views\**\Shared\*` — admin layout (искать; возможно тут baseUrl).
- `C:\sites\snolla\admin\templates\*.tmpl.html` — статические template'ы admin SPA. Сами URL'ы не генерируют, но загружаются из JS которая видит baseUrl откуда-то.
- `C:\sites\snolla\Web.config` — appSettings (`primaryDomain` уже есть), будущие `<rewrite>` rules.
- `C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\*.yml` — site routes (тут middleware подключаем).
- `C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\snolla.yml` `:1` — already has `passHostHeader: true`. Добавить middleware на forwarded-headers.
## План этапов
### Phase 1 — diagnostic (не write-op)
- [ ] Сделать XHR call на `https://labtools.snolla.com/admin/themes/getImageSizes/` (с auth-cookie если есть) и записать response headers + body. Подтвердить откуда именно `:8089` приходит (Location header? `<base>` tag? `<script var>` ? JSON `baseUrl` field?).
- [ ] Найти server-side место — grep по `:8089`, `Request.Url.Authority`, `Request.Url.GetLeftPart`, `Url.Action(.., protocol:)`, `UriBuilder` в `MoreThenCms.Web\Admin\` source + deployed.
- [ ] Проверить, отдаёт ли traefik сейчас `X-Forwarded-*` headers backend'у (по default traefik их шлёт, но `X-Forwarded-Port` = 443 entrypoint port, и `X-Forwarded-Host` = client Host).
- [ ] Воспроизвести `:4443` leak: тест с публичной сети, посмотреть Location header в HTTP→HTTPS redirect.
### Phase 2 — fix через IIS URL Rewrite + ARR (RECOMMENDED)
**Почему этот путь:** не трогаем CMS source code, фикс на инфра-уровне, переносим только конфиг — не риск перекомпиляции. Standard ASP.NET reverse-proxy паттерн.
Шаги:
- [ ] Установить IIS modules: `URL Rewrite 2.1` + `Application Request Routing 3.0` через MSI (download links в notes).
- [ ] В `C:\sites\snolla\Web.config` (и stostayer/stostayer.old аналогично) добавить inbound rewrite rule со `<serverVariables>` блоком — переписать `HTTPS=on`, `SERVER_PORT=443`, `SERVER_PORT_SECURE=1` если `HTTP_X_FORWARDED_PROTO=https`.
- [ ] В `applicationHost.config` (требует admin-shell) добавить `<allowedServerVariables>` для всех затрагиваемых vars (HTTPS, SERVER_PORT, SERVER_PORT_SECURE, HTTP_HOST если будем переписывать).
- [ ] Перезапустить IIS site / app pool, проверить `Request.Url.Port == 443` через простой `@Request.Url.Port` echo на test-странице.
- [ ] Если CMS читает `Request.Url.Host` через Authority — переписать также `HTTP_HOST` (но это рискованнее, может сломать вирт.хосты на IIS).
### Phase 3 — traefik middleware (если Phase 2 не закрывает всё)
- [ ] Добавить `data/custom/forwarded-headers-middleware.yml`:
```yaml
http:
middlewares:
forward-https:
headers:
customRequestHeaders:
X-Forwarded-Proto: https
X-Forwarded-Port: "443"
```
- [ ] В каждый site-yml router добавить `middlewares: [forward-https]`.
- [ ] `docker restart traefik`, проверить headers пробрасываются.
### Phase 4 — verify
- [ ] Phone-test admin login + admin/themes/getImageSizes/ XHR — URL без портов.
- [ ] Smoke test publicly через `Invoke-WebRequest` на all 11 cms domains, посмотреть Location headers на любых redirect'ах — `:4443` / `:8089` не должно нигде встречаться.
- [ ] Update [recovery-architecture-snapshot.md](../.wiki/concepts/recovery-architecture-snapshot.md) — issue #1 → resolved.
## Open questions
- [ ] Можно ли вообще менять `applicationHost.config` без брейка стека? (это глобальный IIS config, не per-site).
- [ ] CMS-код в admin строит absolute URL'ы — server-side (Razor) или client-side (JS)? Это меняет место fix'а.
- [ ] Bind на `*:80` для IIS site `snolla` ещё держится? Если да — traefik можно (теоретически) переключить на :80 backend, но это вернёт Docker NAT loopback bug attempt 1. **НЕ ДЕЛАТЬ** без рекомендации loop-detect recipe.
- [ ] `*.tmpl.html` файлы — статичные. Кто их load'ит и откуда берёт URL? Возможно admin.js, который читает `<base href>` или meta tag.
## Decisions log
- 2026-05-19: вынес из `iis-on-host-migration` (Phase 5 «бонусы») в отдельную задачу — user попросил. Аргументация: scope крупнее чем «бонус» — затрагивает все 11 sites + traefik + потенциально applicationHost.config. Тестировать надо отдельно от migration soak.
- 2026-05-19: **Phase 1 diagnostic** — `Url.SiteRoot()` в `UrlHelpers.cs:14-37` подтверждён как root cause (читает `Request.ServerVariables["SERVER_PORT"]` который = 8089 на attempt2-host). VM SSH probe подтвердил binding `MoreThenCms.Web *:80:` → SERVER_PORT=80 → port stripped whitelist'ом → почему VM работала.
- 2026-05-19: **Path B abandoned** (traefik http entrypoint :80 → :8090 + IIS backend :80) — Docker Desktop's WSL2 NAT quirk возвращает 17-byte 301 plain text на `host.docker.internal:80` независимо от того что внутри traefik :80 entrypoint удалён. Quirk reproducible через `gateway.docker.internal:80` и LAN IP `192.168.1.143:80` тоже. Traefik configs восстановлены из `.bak-pre-portleak-2026-05-19`, canary yml удалён.
- 2026-05-19: **Path C applied** — URL Rewrite 2.1 + apphost allowedServerVariables + Web.config rewrite rule. Verified end-to-end через `docker exec traefik wget https://127.0.0.1:443/...` (full chain включая traefik X-Forwarded-Proto auto-injection).
- 2026-05-19: **emspb /admin/assets 500** — user подтвердил «только этот site, остальное работает», вынесено из scope этой task'и в open issue #8 `recovery-architecture-snapshot`. Не блокирует closing.
## Completed steps
- [x] **Phase 1 diagnostic**: grep `Url\.SiteRoot\|GetLeftPart\|Url\.(Authority\|Port)`, найден `UrlHelpers.cs:14-37`. VM SSH `appcmd list site /xml` подтвердил VM binding `:80`. `findstr` на VM applicationHost.config = no rewrite rules, `appcmd list module` = no URL Rewrite/ARR — VM working state без специальной IIS-magic.
- [x] **Path B aborted**: backup 3 files (traefik.yml, docker-compose.yml, emspb.yml), edit entrypoint :80→:8090, port mapping 8000:8090, canary yml для `emspb.snolla.com` с backend `:80`. `docker compose up -d --force-recreate` → recreate'ed. Loop **не ушёл** на host.docker.internal:80 (probe 17-byte 301). Revert configs из bak, canary yml удалён, recreate again.
- [x] **Path C applied**:
- URL Rewrite 2.1 MSI install (rewrite_amd64_en-US.msi, 6 MB, version 7.1.1993.2351) via elevated `Start-Process msiexec`.
- `applicationHost.config` backup `.bak-pre-portleak-2026-05-19`, добавлены HTTPS/SERVER_PORT/SERVER_PORT_SECURE в `<rewrite>/<allowedServerVariables>` через elevated `appcmd set config /+...` (после неудачной попытки `$cfg.OuterXml` save которая flatt'нула 937 lines в 1 — restored from backup).
- `C:\sites\snolla\Web.config` backup `.bak-pre-portleak-2026-05-19` (19050 bytes), добавлен `<rewrite>/<rules>/<rule name="ForwardedProto-HTTPS">` с conditions `HTTP_X_FORWARDED_PROTO=https` → setVars HTTPS/SERVER_PORT/SERVER_PORT_SECURE. UTF-8 BOM сохранён (EF BB BF verified post-edit).
- [x] **Regression fix**: `customErrors mode="off"` → `mode="Off"` после YSOD config error (pre-existing bug пробудился ASP.NET full-reload после нашего rewrite-block edit).
- [x] **Verify via docker exec traefik** через full chain — `mis.siteRoot = 'https://emspb.snolla.com'` и `mis.siteRoot = 'https://labtools.snolla.com'` (without `:8089`, https scheme). User-side browser test confirmed остальные 10 cms работают.
- [x] **Wiki ingest**: new concept `cms-server-port-leak-fix.md`; `traefik-on-windows-docker-desktop.md` Pitfall 5 → RESOLVED; `recovery-architecture-snapshot.md` open issue #1 → resolved + новый #8 emspb assets; `index.md` + `log.md` обновлены.
## Notes
- URL Rewrite 2.1 download: `https://download.microsoft.com/download/1/2/8/128E2E22-C1B9-44A4-BE2A-5859ED1D4592/rewrite_amd64_en-US.msi`
- ARR 3.0 download: `https://download.microsoft.com/download/E/9/8/E9849D6A-020E-47E4-9FD0-A023E99B54EB/requestRouter_amd64.msi` (не понадобился — наш fix без ARR)
- Связанные wiki: [[cms-server-port-leak-fix]] (детально), [[traefik-on-windows-docker-desktop]] Pitfall 5, [[recovery-architecture-snapshot]] § Известные открытые баги.
- Не трогать stayer routes — они уже `.disabled` через traefik, локальный доступ через `:8090/:8091` напрямую (с `:8090/8091` в URL'ах это **корректно**, не leak).

View File

@@ -0,0 +1,122 @@
# iis-on-host-migration
## Goal
Перенести IIS-сайты MoreThenCms из VirtualBox VM (`snolla-recovery`) на нативный IIS Windows-хоста. VM остаётся как hot fallback на первое время; после успешного нативного-запуска — выключаем VM, освобождаем 4 GB RAM + ~92 GB диска.
**Зачем:** VM на VBox = лишний слой нестабильности (видели один network hang). Нативный IIS на хосте — проще, быстрее, без NAT-форвардов и VBox-капризов. Контейнеры MSSQL/MinIO/etc. уже на этом же хосте — устраняем сетевой роутинг.
## Что у нас уже есть
- ✅ IIS установлен на хосте (W3SVC running, default site empty, [`.wiki/entities/windows-recovery-host`](../.wiki/entities/windows-recovery-host.md))
- ✅ .NET Framework 4.8.1 на хосте
- ✅ Полная копия `C:\inetpub\wwwroot\` из VM → `C:\nas-recovery\vm-sites\wwwroot\` (8.69 GB)
- ✅ Полная копия `C:\stayer\` из VM → `C:\nas-recovery\vm-sites\stayer\` (2.21 GB)
- ✅ MSSQL контейнер на host:1433 (5 production DB)
- ✅ MinIO на host:9000, Elasticsearch на host:9200, imgproxy на host:8787/8788
- ✅ Исходники CMS в `C:\Users\vitya\projects\MoreThenCms\` (Git репо)
- ✅ Traefik с 13 client routes (сейчас target = `host.docker.internal:18080` = VM)
## Key files
- `C:\nas-recovery\vm-sites\wwwroot\` — IIS-сайты из VM
- `C:\nas-recovery\vm-sites\stayer\` — stostayer-проекты
- `C:\inetpub\wwwroot\` — целевое расположение на хосте
- `C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\*.yml` — backends, нужно переключить с `host.docker.internal:18080` на `localhost:80` (или какие-то local IIS-bindings)
- `Web.config` файлы — connection strings уже патчены на `10.0.2.2`, нужно вернуть на `localhost` или `127.0.0.1` для нативного IIS
## План этапов
### Phase 1 — Анализ и подготовка
- Изучить IIS site bindings в VM (MoreThenCms.Web `*:80`, Snolla.IdentityManager `*:80`, stostayer `*:8080`, stostayer.old `*:8081`)
- Решить port-mapping на хосте — оставлять 80? Или другие порты, traefik на 80/443 переадресует?
- Изучить, какие IIS modules/features нужны (URL Rewrite, ARR, обязательные .NET runtimes — может потребоваться доставить)
### Phase 2 — Импорт сайтов на хост
- Скопировать `C:\nas-recovery\vm-sites\wwwroot\*``C:\inetpub\wwwroot\` (или другой root)
- Скопировать `C:\nas-recovery\vm-sites\stayer\``C:\stayer\`
- Создать application pools (`.NET v4.5` или эквивалент) для каждого сайта в IIS Manager
- Создать sites в IIS:
- `MoreThenCms.Web` (port 80 / другой)
- `Snolla.IdentityManager`
- `stostayer` (port 8080)
- `stostayer.old` (port 8081)
- Web.config patch: `Data Source=10.0.2.2``Data Source=localhost` (или `127.0.0.1` / `.\` ; UTF-8 BOM!)
### Phase 3 — Перенос на хост IIS, тест
- Stop VM (но не удалять!)
- Update traefik backends в `data/custom/*.yml`:
- `http://host.docker.internal:18080/``http://host.docker.internal:80/` (или какой порт IIS использует)
- `:18180``:8080`, `:18181``:8081`
- traefik restart
- Прокликать все 11 клиентских доменов из публичного интернета
- Убедиться что .NET Framework 4.8.1 справляется, нет missing assemblies, нет permission issues на App_Data / temp folders
### Phase 4 — Cleanup VM
- Когда стабильно ~неделя на хост-IIS — выключить VM окончательно
- `VBoxManage controlvm "snolla-recovery" poweroff`
- Удалить port forwards в OpenWRT, которые больше не нужны (host:18080, host:18180, etc.) — это уже не traefik backend
- (Опционально) удалить VM из VBox: `VBoxManage unregistervm "snolla-recovery" --delete`. Это освобождает 92 GB на C:.
- Удалить `C:\nas-recovery\backup\snolla\snolla.ova` (42.5 GB) и `C:\nas-recovery\vm-sites\` (11 GB) — backup уже не нужен.
### Phase 5 — Бонусы
- Установить **URL Rewrite + ARR** для нормальной обработки X-Forwarded-Proto headers (fix CMS-редиректа с `:4443` в URL — см. [`.wiki/concepts/traefik-on-windows-docker-desktop`](../.wiki/concepts/traefik-on-windows-docker-desktop.md))
- Настроить log rotation для C:\inetpub\logs\
- Application Initialization (для warm-start CMS) — IIS Optional Feature, autostart сайтов
## Open questions
- [ ] CMS-код использует абсолютные пути типа `C:\inetpub\wwwroot\MoreThenCms.Web\` (видели в Web.config `<add key="sitePath" .../>`)? Если да — путь должен остаться, либо обновить.
- [ ] Authentication / IIS Application Identity — какая учётка должна крутить app pool? (LocalSystem? NetworkService? IIS AppPool\<sitename>?)
- [ ] Нужен ли .NET Framework Repair / SAC update перед миграцией?
- [ ] Что с storage providers (Azure-SDK adapter в CMS)? — Связано с открытым вопросом о MinIO/Azure, что пользователь обещал прояснить.
## Decisions log
- 2026-05-19: задача поставлена после успешного recovery в VM. VM показала себя нестабильной (один network hang за день uptime), решено мигрировать на нативный IIS как более простой и предсказуемый стек.
## Completed steps
- [x] Pulled VM sites to host (49 минут tar+ssh, 11 GB total)
- [x] IIS на хосте установлен (в рамках recovery, ещё нативно не использовался)
- [x] **Phase 1 — discovery** (2026-05-19): VM сайты/пулы/vdirs/features через SSH + appcmd, host IIS features через elevated DISM, source grep на hardcoded paths. См. `.wiki/sources/iis-host-migration-2026-05-19.md`.
- [x] **Phase 2 — миграция MoreThenCms.Web** (2026-05-19): `C:\sites\MoreThenCms.Web` (8.7 GB robocopy), Web.config patch (`sitePath` + conn → localhost, UTF-8 BOM), AppPool + Website на `*:80`, ACL `:(OI)(CI)M` для `IIS AppPool\MoreThenCms.Web`. Default Web Site остановлен. Smoke test через `localhost` с Host header — 10/11 хостов отвечают (rimiz.ru → 404, как issue ниже).
- [x] **Phase 2 — stostayer / stostayer.old** (2026-05-19, частично): сайты созданы на `:8090/:8091``C:\stayer\MoreThenCms.Web` / `C:\stayer\stostayer.old`, AppPools созданы, ACL поставлен. **Но локально оба отвечают timeout** — рантайм-проблема не разбиралась.
- [x] **Phase 3 — traefik switch** (2026-05-19): 11 yml пропатчены `host.docker.internal:18080``host.docker.internal:80`, traefik file-provider auto-reload, public smoke через `https://localhost:4443/`**10/11 хостов → HTTP 200**, rimiz.ru → 404. Stostayer/oldstostayer backend в traefik не трогали (остаются на VM).
## Решения (decisions log дополнен)
- 2026-05-19: **Snolla.IdentityManager не мигрируется** — пользователь подтвердил «не нужен» (Q-C в сессии). Если что-то внутри CMS дёргает его по `localhost:8089` — увидим в логах, тогда вернёмся.
- 2026-05-19: **Sub-apps stostayer.old (`/calc`, `/price`, `/price/tireService`) не мигрируются** — пользователь подтвердил «не нужны».
- 2026-05-19: **stostayer.connection-string на 89.253.219.2 не трогаем** (Q-B пользователя «не трогай, так надо»). Это внешний production MSSQL для stayer-инфраструктуры, не наш контейнер.
- 2026-05-19: **AppPool identity = ApplicationPoolIdentity** для всех 3 пулов (default outside SCM, безопасно). ACL `:(OI)(CI)M` (Modify) рекурсивно на site root.
- 2026-05-19: **Path strategy = C:\sites\\** (не `C:\inetpub\wwwroot\`) — пользователь выбрал (б) в Q1.
## Status — ROLLBACK (2026-05-19 вечер)
**Миграция сделана, сломала prod, откатили.** См. полный разбор в `.wiki/concepts/iis-migration-2026-05-19-postmortem.md`.
- ⚠️ Phase 1-8 выполнены технически, но Phase 3 ввёл Docker port-loop (`host.docker.internal:80` резолвится через Docker Desktop NAT обратно в сам traefik, `https.yml` redirect-to-https middleware → 301 → loop). Симптомы появились ~10 мин после моего "done" → 502 → TOO_MANY_REDIRECTS.
-**Revert (Phase 9) успешен:** VM поднята из savestate, traefik backends восстановлены из `.bak-phase3` → trafic снова через VM (как до session).
- ✅ Артефакты для следующей попытки **сохранены** на хосте: `C:\sites\{snolla, stostayer, stostayer.old, snolla-identity-manager}` + IIS sites + AppPools + 3 traefik backup-stamp серий.
## Completed Phase 4-9 (вечер 2026-05-19)
- [x] **Phase 4 — реорг** `C:\sites\`: rename `MoreThenCms.Web → snolla`, move `C:\stayer\MoreThenCms.Web → C:\sites\stostayer`, move `C:\stayer\stostayer.old → C:\sites\stostayer.old`, move + kebab-rename `C:\stayer\Snolla.IdentityManager → C:\sites\snolla-identity-manager`. Удалены 3 sub-app папки. `C:\stayer\` снёс полностью.
- [x] **Phase 4 — IIS rename**: site `MoreThenCms.Web → snolla`, pool пересоздан как `snolla` (rename невозможен in-place), site rebound, физпуть обновлён на `C:\sites\<name>` для всех 3, sitePath в Web.config'ах подправлен под новые пути. ACL re-granted.
- [x] **Phase 5 — stostayer.old DB-fix**: `Data Source=10.0.2.2``localhost`. После — `:8091` → 200 локально (была наша ошибка в Phase 2 — пропустили этот файл).
- [x] **Phase 6 — stostayer DB-migration**: старый `89.253.219.2,1433` не reachable. Новые creds: `www.stostayer.ru,1433`, user `stayer_site`. Patched Web.config. Поймана и зафиксирована **новая gotcha** в [[webconfig-password-xml-escape]] — `&` в пароле нужно XML-escape как `&amp;`.
- [x] **Phase 7 — traefik privacy**: `stostayer.yml` и `oldstostayer.yml` переименованы в `.yml.disabled` (потом возвращены в Phase 9). Backup: `*.yml.bak-stayer-switch-2026-05-19`.
- [x] **Phase 8 — VM savestate**: `savestate`. VMState=saved (потом возвращена в Phase 9). **БЫЛО ПРЕЖДЕВРЕМЕННЫМ.**
- [x] **Phase 9 — ROLLBACK** (после catastrophe): `VBoxManage startvm`, ipconfig release/renew для разморозки network, traefik yml восстановлены из `.bak-phase3-2026-05-19`, stayer .yml.disabled удалены и yml восстановлены из `.bak-stayer-switch`, `docker restart traefik`. Public smoke — 7 хостов через VM-chain ответили (2× 200, 5× 301 CMS-redirect = normal), пользователь подтвердил в браузере.
## Что НЕ делать в следующей попытке
См. полный recipe в `.wiki/concepts/iis-migration-2026-05-19-postmortem.md`, кратко:
- **НЕ** использовать backend `host.docker.internal:80` (Docker NAT loopback с traefik HTTP entrypoint :80)
- **НЕ** тестировать только `-MaximumRedirection 5` (скрывает loop)
- **НЕ** тестировать только из LAN (router-hairpin lying)
- **НЕ** замораживать VM раньше чем через 24-48h стабильности host-стека
- **НЕ** делать reorg/rename in same session as migration (атомность важна)
- **НЕ** объявлять "done" до 24h+ uptime + теста из НЕ-LAN сети
- При первом anomaly — **STOP, revert на known-good, понять, потом fix** (НЕ каскадные reactive changes)
## Notes
- VM не удалять до конца Phase 3 — это working fallback. Только после двух недель стабильной работы host-IIS.
- Git push в gitea невозможен пока — gitea был на мёртвой синке. Восстановление gitea — отдельная задача (есть бэкап `/docker/gitea/` 2.6 GB на kreknin-синке, можно поднять локально или временно класть code в другое место).
- При работе с Web.config — **обязательно UTF-8 BOM** через `[System.IO.File]::WriteAllText` с `[System.Text.UTF8Encoding]::new($true)`. Иначе IIS 500.19. Детали в [`.wiki/concepts/cms-config-rewrite-pattern`](../.wiki/concepts/cms-config-rewrite-pattern.md).

View File

@@ -0,0 +1,43 @@
# iis-traefik-dead-routes-cleanup
## Goal
Убрать из traefik (и host IIS bindings, если нужно) routes для 3 hostname'ов которые больше **не указывают на нашу инфраструктуру** — выяснилось в ходе [[iis-on-host-migration]] Phase 11 close-out smoke (2026-05-21):
| Host | Where it points now | Original task expectation |
|---|---|---|
| `maljarka.ru` | DNS снят (нет A record) | host IIS `snolla` |
| `sestech.ru` | Парковка domainparking.ru (TLS subj `CN=*.domainparking.ru`, cert от 2025-11-04) | host IIS `snolla` |
| `ics-artmaterials.com` | A→`87.236.16.28`, отвечает `nginx-reuseport/1.21.1` (внешний WP-хостинг) | host IIS `snolla` |
## Key files
- `C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\` — поискать yml где упоминаются эти 3 host'а. Скорее всего отдельный yml на каждый, либо combined.
- Possibly host IIS site `snolla` bindings (через `appcmd list site snolla` или `Get-WebBinding`) — если bind на эти hostname'ы есть, тоже убрать.
## Open questions
- [ ] Удалять yml совсем или `.disabled` rename (как сделано с `stostayer.yml.disabled`)? Disabled безопаснее на случай если домен вернётся.
- [ ] Нужно ли уведомить владельцев доменов (если внутренние SaaS-клиенты) что routes снимаются?
- [ ] `rimiz.ru` (404 CMS-side, не off-infra) — НЕ сюда. Это open issue в [[recovery-architecture-snapshot]].
## Implementation sketch
```powershell
# 1. Найти yml-ы, упоминающие dead hosts
Select-String -Path "C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\*.yml" -Pattern "maljarka|sestech|ics-artmaterials"
# 2. Backup + rename .disabled (или удалить)
# (зависит от того что найдено в шаге 1)
# 3. docker restart traefik
# 4. Smoke: tail traefik logs на 30s — никаких errors для удалённых routes
docker logs --since 30s traefik 2>&1 | Select-String -Pattern "maljarka|sestech|ics-artmaterials"
```
## Notes
- Low priority — dead routes генерируют noise в traefik logs (LE cert renewal попытки и т.п.), но не блокируют live trafic.
- Атомарный revert: rename `.disabled → .yml` обратно, `docker restart traefik`.
- Если у `sestech.ru` истёк parking cert, LE может пытаться renew наш cert тоже (если в acme.json остались записи); это благодарность для отдельной чистки `acme.json`.

View File

@@ -0,0 +1,68 @@
# nas-recovery
## Goal
Поднять клиентские сайты MoreThenCms на локальной Windows-машине пользователя после краха исходной Synology NAS. Источник данных — Hyper Backup репо `/volume1/NetBackup/diskstation_1.hbk` на удалённой живой синке (195.19.90.188, kreknin.site:5000), без шифрования, 430 GB, забэкаплены `/backup`, `/docker`, `/work` мёртвой синки.
## Key files
- `_Syno_TaskConfig` на удалённой синке — метаданные задачи Hyper Backup (`rsync Server 1`, source `diskstation`).
- `C:\Users\vitya\projects\MoreThenCms\Web.config` — connection strings CMS, надо будет переписать на `localhost:<port>`.
## Decisions log
- 2026-05-18: восстанавливаем не через HBE/SFTP-пулл всего `.hbk`, а через **selective restore на самой удалённой синке** → SFTP-пулл только плоских файлов (для 430 GB через узкий канал — единственный реалистичный путь).
- 2026-05-18: для БД — путь через `.bak` дамп (если есть в `/backup`) + `RESTORE DATABASE` в новый контейнер MSSQL на Windows. Fallback — extract из docker volume.
- 2026-05-18: VM с мёртвой синки не восстанавливаем — она была runtime, не data. CMS гоняем нативно на Windows IIS.
## Open questions
- [ ] **Что такое `snolla.ova`** — OVA-экспорт Windows-VM с MoreThenCms или что-то другое? Если VM-снапшот — план переключается на "импорт OVA в Hyper-V на Windows-PC", всё остальное (IIS, .bak, MSSQL container, MinIO config) становится опциональным fallback.
- [ ] Свежесть OVA-экспорта (если это он)?
- [ ] Точная мажорная версия MSSQL? (от неё зависит тег image локального контейнера — нельзя восстанавливать .bak в младшую версию)
- [ ] Что лежит в `/work` (взят целиком)?
## Inventory с remote (видно в DSM summary восстановления, версия 09.05.2026):
**`backup/`:** `SRV-1135520-1`, `books`, `snolla` (← вероятно SQL-дампы для MoreThenCms)
**`docker/`:** `buildkit`, `cancel-music`, `code-server`, `gitea`, `hermes`, `infrastucture` (sic), `mosquitto`, `openclaw`, `personal`, `portainer`, `traefik`, `zigbee2mqtt`
**`work/`** — взят целиком, состав смотрим на месте.
**Выбраны для restore (10.05.2026, в работе):** всё перечисленное выше.
## Completed steps
- [x] Подтверждена структура `.hbk` репо, прочитан `_Syno_TaskConfig`: задача `rsync Server 1`, без шифрования, source = `diskstation`, бэкап папок `/backup`, `/docker`, `/work`.
- [x] Подтверждён доступ к DSM удалённой синки через `http://kreknin.site:5000` (HTTPS 5001 наружу не проброшен — пароль идёт по plain HTTP, после восстановления обновить).
- [x] На удалённой синке — root в SSH, юзер vitya — DSM admin. 6 TB свободно — selective restore в `/volume1/NetBackup/restore-tmp/` влезает.
## Notes
Этапы в правильном порядке (актуальная редакция после находки snolla.ova + ежедневных .bak):
1. **Phase 1 — DB via .bak dump** (✅ путь определён):
- SFTP с `~/sftp-pickup/MoreThenCms202605090301.zip` на Windows.
- `Expand-Archive` → получаем `.bak`.
- В MSSQL-контейнере (уже работает на `localhost:1433`) → `RESTORE FILELISTONLY` → потом `RESTORE DATABASE ... WITH MOVE`.
2. **Phase 2 — MinIO data** (после распаковки `/docker/personal/minio/` на синке):
- sftp-pickup → tar/zip → SFTP на Windows → распаковка в `C:\Users\vitya\projects\docker\diskstation\minio\data\`.
- `docker compose up -d` в `minio/`.
3. **Phase 3 — OVA в VirtualBox** (главный runtime):
- FileZilla тянет `snolla.ova` (42.5 GB).
- Импорт в VirtualBox 7.2.8 (уже установлен).
- Стартуем VM, проверяем что IIS поднялся.
- Правим Web.config: connection strings → MSSQL `<windows-host-ip>:1433` и MinIO `<windows-host-ip>:9000`.
- Сайты отвечают локально.
4. **Phase 4 — delta файлов** (по ситуации):
- 3-4 GB файлов между состоянием Oct 2024 (в OVA) и May 2026 (свежие данные).
- Источник — `/work/` из restore, или билд из локального git-репо MoreThenCms.
**Архитектура важно:** IIS **внутри** VirtualBox VM (из OVA), НЕ на Windows-хосте. Host-IIS (W3SVC), который установлен — избыточен и должен быть остановлен (`Stop-Service W3SVC; Set-Service W3SVC -StartupType Manual`) перед запуском traefik, чтобы не было port-конфликта на 80/443. Traefik в Docker на хосте → forwarding на IP VM.
5. **Phase 5 — traefik + imgproxy + DNS + Let's Encrypt** (production exposure):
- SFTP `/volume1/docker/traefik/` (compose + acme.json + data/) на Windows.
- SFTP imgproxy-стек (расположение TBD: возможно `docker/infrastucture/imgproxy/` или `docker/personal/imgproxy/` или отдельная папка). Найти через `grep -ril imgproxy /volume1/docker/`.
- Поднять traefik + imgproxy контейнеры с теми же middlewares.
- imgproxy указывает на локальный MinIO (`http://minio:9000/<bucket>/...`) — connection URL внутри docker network `proxy`.
- DNS *.kzntsv.site → новый Windows-host IP.
- Acme.json сохраняем — сертификаты валидны до истечения, потом auto-renew через REGRU DNS-01.

View File

@@ -0,0 +1,55 @@
# traefik-maljarka-502-bug
## Goal
Разобраться почему `maljarka.tandemmebel.ru` через traefik HTTPS возвращает 502 Bad Gateway, хотя backend (IIS на host:8089 с правильным Host header) отвечает 200 OK с валидным CMS body.
## Evidence (2026-05-21)
| Path | Result |
|---|---|
| `docker exec traefik wget --spider https://maljarka.tandemmebel.ru/` | **HTTP/1.1 502 Bad Gateway** |
| `docker exec traefik wget --header='Host: maljarka.tandemmebel.ru' http://host.docker.internal:8089/` | **HTTP/1.1 200 OK** (Microsoft-IIS/10.0, 43730 bytes, "Малярка от Тандеммебель") |
| `Invoke-WebRequest http://localhost:8089/ -Headers @{Host='maljarka.tandemmebel.ru'}` | **200 OK** (host->host direct) |
| `docker exec traefik wget --spider https://www.tandemmebel.ru/` | **200 OK** (sibling route, working) |
## Config diff
`maljarka.yml` vs `tandemmebel.yml` — syntactically identical (router→service→loadBalancer→servers, same backend URL `http://host.docker.internal:8089/`, same `passHostHeader: true`). LE cert для `maljarka.tandemmebel.ru` присутствует в `acme.json`.
## Hypotheses
1. **Stale traefik state** — uptime 38h+ с регулярными `docker provider connection error` retry-loop'ами. Restart traefik может сбросить bad state. **Easy first check.**
2. **Hidden file encoding difference** — BOM / line endings / trailing whitespace в `maljarka.yml` vs `tandemmebel.yml`. `Get-FileHash` оба yml + `Format-Hex` на первые 16 байт.
3. **acme.json corruption для maljarka cert** — cert exists но key/chain broken. Traefik не может handshake → fallback вернёт 502? Maybe.
4. **Service name collision**`maljarka` router/service name conflicts c чем-то ещё в dynamic config. Vrai unlikely (grep подтвердил unique).
5. **Backend connection limit** — service-specific. Маловероятно.
## Implementation sketch
```powershell
# 1. Get exact error body from traefik
docker exec traefik wget -O - --server-response https://maljarka.tandemmebel.ru/ 2>&1 | Select-Object -First 30
# 2. Enable traefik access logs если не включены (data/traefik.yml accessLog: filePath)
docker exec traefik cat /etc/traefik/traefik.yml | Select-String 'accessLog'
# 3. Restart traefik (brief ~1-2s interruption ВСЕХ routes)
docker restart traefik
Start-Sleep 5
docker exec traefik wget --spider https://maljarka.tandemmebel.ru/ 2>&1 | Select-Object -First 3
# 4. Bytewise compare yml files
Get-FileHash *.yml -Algorithm MD5 | Where-Object Path -Match '(maljarka|tandemmebel)\.yml$'
Get-Content C:\...\maljarka.yml -Raw -Encoding Byte | Format-Hex | Select-Object -First 5
```
## Open questions
- [ ] Является ли `maljarka.tandemmebel.ru` критичным для бизнеса (real traffic) или это test-subdomain? Если real — bump priority.
- [ ] Существует ли site binding для этого hostname в IIS `snolla` site, или CMS catch-all'ит через `*` binding?
## Notes
- Скоприровано из close-out [[iis-traefik-dead-routes-cleanup]] как side-finding.
- Атомарных изменений на инфре не делал — задача чисто диагностическая.

View File

@@ -0,0 +1,102 @@
# vds-backup-rsync-kreknin
## Goal
Ежедневный rsync-бэкап важных директорий с VDS (`89.253.255.94 / vds.kzntsv.site`) → [[kreknin-synology]] (`195.19.90.188 / kreknin.site`) в 05:00 MSK. После каждого прохода — email-нотификация на `vitya.kuznetsov@gmail.com` со статусом (success/fail + transferred bytes + duration).
## Open questions
- [x] ~~**Что бэкапить:**~~ Resolved 2026-05-20. Sources в `/opt/stacks/backup/scripts/run.sh`:
- `/opt/stacks/{gitea,verdaccio/storage,verdaccio/config,registry,traefik,portainer,ntfy,backup}`
- `/etc/{ssh,ufw,hosts,docker}`
- `/home/vitya/.ssh`
- DB dumps в `$DUMP_DIR` (pg/maria/mongo/redis) — добавляются в rsync source list.
- **Не бэкапим:** `/opt/stacks/databases/*/data` (raw datadirs — running container locks; dumps вместо).
- [x] ~~**Куда на kreknin:**~~ `/volume1/NetBackup/vds-kzntsv/<YYYY-MM-DD>/` + symlink `latest`. Retention 7 daily snapshots (RETENTION_DAYS env). Weekly/monthly — defer (overkill для текущих ~12G).
- [x] ~~**SSH key:**~~ продолжаем `/home/vitya/.ssh/id_ed25519_kreknin` — скрипт читает абсолютным path (work as root too).
- [x] ~~**Tool:**~~ rsync `--link-dest` (built-in, hardlink-incremental). Encrypted (restic/borg) defer — VDS↔kreknin link trusted (оба ours), encryption key management = ops overhead. Если канал potentially compromised — переключить позже.
- [x] ~~**Email механизм:**~~ `msmtp` + `msmtp-mta` apt-installed на VDS. Config в `/etc/msmtprc` (chmod 600 root:root, system-wide since cron runs as root). SMTP `smtp.yandex.ru:465` + creds `noreply@snolla.com` из `noreply-snolla-smtp.env`. Test send → Yandex 250 OK ✅.
- [ ] **Phone confirm:** user verifies ntfy push на `vds-backup` topic пришёл из реального cron run (или manual run).
## Implementation sketch
`/etc/cron.d/vds-backup`:
```cron
# 05:00 MSK ежедневно
0 5 * * * vitya /opt/stacks/backup/scripts/run.sh
```
`/opt/stacks/backup/scripts/run.sh`:
```bash
#!/bin/bash
set -e
SOURCE_DIRS=(/opt/stacks/gitea/data /opt/stacks/verdaccio/storage /opt/stacks/verdaccio/config /opt/stacks/registry/docker /opt/stacks/registry/auth /opt/stacks/traefik /opt/stacks/portainer/data /etc/ssh /etc/ufw /etc/hosts /etc/docker /etc/letsencrypt)
DEST_BASE=/volume1/NetBackup/vds-kzntsv
TODAY=$(date +%Y-%m-%d)
LATEST=$DEST_BASE/latest
START_TIME=$(date +%s)
LOG=/tmp/backup-$TODAY.log
# DB dumps первым шагом — pg/maria/mongo в /tmp/db-dumps/$TODAY/, потом включаются в rsync
mkdir -p /tmp/db-dumps/$TODAY
docker exec postgres pg_dumpall -U postgres > /tmp/db-dumps/$TODAY/postgres.sql
docker exec mariadb mariadb-dump --all-databases -u root -p"$MARIA_PASS" > /tmp/db-dumps/$TODAY/mariadb.sql
docker exec mongo mongodump --out=/tmp/mongo --uri="mongodb://root:$MONGO_PASS@localhost:27017?tls=true&tlsAllowInvalidCertificates=true"
docker exec redis redis-cli --tls --insecure -a "$REDIS_PASS" --rdb /data/dump.rdb
# rsync с --link-dest для hardlink-incremental
rsync -azh --link-dest=$LATEST "${SOURCE_DIRS[@]}" /tmp/db-dumps/$TODAY \
-e "ssh -i ~/.ssh/id_ed25519_kreknin" \
vitya@195.19.90.188:$DEST_BASE/$TODAY/
ssh -i ~/.ssh/id_ed25519_kreknin vitya@195.19.90.188 \
"rm -f $LATEST && ln -sf $DEST_BASE/$TODAY $LATEST"
END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))
SIZE=$(du -sh $DEST_BASE/$TODAY 2>/dev/null | cut -f1)
# Email via msmtp
echo "Subject: VDS backup $TODAY — SUCCESS
Size: $SIZE, duration: ${DURATION}s
Source: vds.kzntsv.site
Dest: kreknin.site:$DEST_BASE/$TODAY/
" | msmtp vitya.kuznetsov@gmail.com
```
(скетч; добавить retention prune — `find $DEST_BASE -maxdepth 1 -type d -name "20*" | sort | head -n -7 | xargs rm -rf`, error trap, etc.)
## Decisions log
- **2026-05-20** — rsync `--link-dest` chosen over restic/borg. Built-in, no encryption key management, VDS↔kreknin trusted link. Encryption defer if threat model changes.
- **2026-05-20** — Cron runs as **root**, not vitya. Initial vitya run hit ~30 Permission Denied (gitea/portainer container-owned files, /etc/ssh host keys, /etc/ufw rules). Trade-off: больше privilege чем нужно, но альтернатива (sudo wrap rsync) — сложнее. Mitigation: `/etc/msmtprc` chmod 600 root:root, `/opt/stacks/backup/.env` chmod 600.
- **2026-05-20** — DB dump approach: `docker exec <container>` с CLI-passed credentials, не URI params. Mongo требует **legacy `--ssl --sslAllowInvalidCertificates`** (НЕ `--tls --tlsInsecure` despite --help listing `--tlsInsecure` — fails as unknown option pre-`--ssl`).
- **2026-05-20** — Retention начали с 7 daily snapshots (RETENTION_DAYS=7). Weekly/monthly defer — 12G/day @ 7 days = 84G headroom вне hardlinks, на kreknin 5.6T free; нет смысла усложнять.
- **2026-05-20** — Cron не был установлен на VDS из-коробки на Ubuntu 24.04 — apt install cron был нужен. Lesson для будущих vds-* tasks: проверять `which cron` в preflight.
- **2026-05-20** — msmtp `/etc/msmtprc` system-wide (а не `~/.msmtprc`) потому что cron как root → msmtp picks up /etc/ first.
- **2026-05-20** — Smoke run (2026-05-20 23:37 → 00:00) successful: 71,867 files / 11.74G transferred в 21m27s, all 4 DB dumps OK, latest symlink updated, ntfy + email sent.
## Completed steps
- [x] msmtp + msmtp-mta apt-installed; `/etc/msmtprc` written с Yandex SMTP creds (chmod 600 root:root)
- [x] `/opt/stacks/backup/.env` создан с DB passwords + kreknin creds + retention (chmod 600)
- [x] `/opt/stacks/backup/scripts/run.sh` написан (bash + flock single-instance + ERR trap)
- [x] DB dumps protocol: pg_dumpall, mariadb-dump --single-transaction, mongodump --ssl --sslAllowInvalidCertificates, redis-cli SAVE + docker cp
- [x] rsync sources finalized: /opt/stacks/*, /etc/{ssh,ufw,hosts,docker}, /home/vitya/.ssh, $DUMP_DIR
- [x] `/var/log/vds-backup/` log dir (pre-created via sudo + chown vitya)
- [x] `/etc/cron.d/vds-backup` installed (root, `0 5 * * *`)
- [x] apt install cron (Ubuntu 24.04 не имел его out-of-box); cron.service active + enabled
- [x] Smoke run as root: 71,867 files / 11.74G на kreknin:/volume1/NetBackup/vds-kzntsv/2026-05-20, latest symlink set, ntfy publish 200, email Yandex 250 OK
- [x] Permission errors из vitya-run выявлены и устранены переходом на root cron
## Notes
- Триггер: после `[[vds-kzntsv-bootstrap]]` Phase 3 + verdaccio/registry стабильны (done).
- Integration с [[vds-ntfy-push]] — backup publish на topic `vds-backup` (admin auth).
- Retention vs disk: kreknin 5.7T free, daily 7 × ~12G full ≈ 85G headroom (hardlinks делают incremental ~1G/day после day 1).
- **acme.json** проходит через rsync (внутри /opt/stacks/traefik) — содержит LE private keys, но VDS↔kreknin link trusted, kreknin ACL restricted to vitya. Acceptable trade-off vs шифрование через restic.
- **Atomic revert:** `ssh vitya@89.253.255.94 'sudo systemctl stop cron; sudo rm /etc/cron.d/vds-backup; sudo apt-get remove -y cron msmtp msmtp-mta; sudo rm -rf /etc/msmtprc /opt/stacks/backup /var/log/vds-backup'`

View File

@@ -0,0 +1,53 @@
# vds-gc-cron
## Goal
Weekly GC для двух container-сервисов на VDS, чтобы storage не разрастался:
1. **Registry** (`/opt/stacks/registry/`) — `registry garbage-collect -m` против nested mount `./docker:/var/lib/registry` (host data в `/opt/stacks/registry/docker/docker/registry/v2/...`).
2. **Verdaccio** (`/opt/stacks/verdaccio/`) — keep N=10 most-recent versions + dist-tagged per-package, drop ТОЛЬКО proxied tarballs (`_distfiles[tgzName]` defined). Локально-published versions (`@snollajs/*` + similar) защищены.
## Key files
- `/opt/stacks/gc/scripts/notify.sh` — ntfy helper, sources `/opt/stacks/ntfy/.env`, posts на `vds-ops` topic.
- `/opt/stacks/gc/scripts/registry-gc.sh` — stop registry → offline `garbage-collect -m` → start; empty-storage guard в начале.
- `/opt/stacks/gc/scripts/verdaccio-prune.sh` — wrapper, stop verdaccio → docker run `node:20-alpine` mounts storage + script → start.
- `/opt/stacks/gc/scripts/verdaccio-prune.js` — ядро prune: walk storage, sort versions by `time[v]` desc, keep top-N + dist-tagged, delete tgz + `_attachments` entries for proxied versions, atomic JSON rewrite + `_rev` bump.
- `/etc/cron.d/vds-gc` — Sunday 03:00 / 03:30 MSK.
- `/var/log/vds-gc/{registry,verdaccio}-YYYY-MM-DD.log` — append-only logs.
## Decisions log
- **2026-05-21:** keep N=10 per package для verdaccio (включая `@snollajs/*` — uniform, no special-case scope). Reasoning: N=10 покрывает любые reasonable rollback scenarios, локально-published уже защищены логикой `_distfiles[tgzName]` absent.
- **2026-05-21:** weekly Sunday 03:00 / 03:30 MSK (2 часа до 05:00 backup cron — нет конфликта). Reasoning: weekly достаточно для personal scale; verdaccio cache растёт ~MB/день не GB/день.
- **2026-05-21:** registry GC = stop→`-m`→start (~30s downtime) instead of readonly+restart-twice. Reasoning: проще, более atomic; на personal registry 30s downtime в воскресенье ночью acceptable.
- **2026-05-21:** verdaccio prune = stop+prune+start (~1min downtime). Reasoning: избегаем torn-read race window между tgz delete и package.json rewrite.
- **2026-05-21:** verdaccio detection of locally-published — через `_distfiles[<tgzName>]` (НЕ `_distfiles[<version>]`). Initial code был bug — verdaccio keys `_distfiles` by tarball filename like `lodash-0.1.0.tgz`, не version string. Dry-run показал 4597 "locally-published" из 7021 — обнаружен через inspection lodash/react/`@snollajs` storage. Real run после fix: 73 версии legitimately protected.
- **2026-05-21:** notify policy — success-low (`broom` tag, prio low) если freed < 10 MiB AND duration < 5 min; success-default иначе; fail-high (`x,boom` tag, prio high) на любой rc≠0; skip-min на empty registry.
- **2026-05-21:** atomic package.json rewrite через `write tmp + rename` (POSIX atomic on same fs). Bump `_rev` (`<num+1>-<random_hex>`) чтобы npm clients не закешировали stale packument.
- **2026-05-21:** verdaccio prune skip `versions{}` and `time{}` entries — оставляем metadata in-place даже для удалённых tarballs. Reasoning: npm может re-fetch tarball from upstream при следующем install request (proxy behaviour); metadata weighs ~KB не GB.
## Open questions
- [ ] (post-первого live cron run) — phone-verify notification приходит на `vds-ops`.
- [ ] Logrotate для `/var/log/vds-gc/` — пока nope (weekly cadence + лог ~10KB/run = 500KB/year, терпимо).
## Completed steps
- [x] recon ntfy creds + verdaccio storage layout (package.json structure: `versions{}`, `_distfiles{}`, `_attachments{}`, `_rev`)
- [x] write `notify.sh`, `registry-gc.sh`, `verdaccio-prune.sh`+`verdaccio-prune.js`
- [x] dry-run verdaccio prune (initial bug discovery — `_distfiles[v]` vs `_distfiles[tgzName]`)
- [x] fix detection → re-dry-run: 4524 tgz / 1.7 GiB candidate
- [x] real verdaccio prune: 8.5G→6.8G, 1551 pkgs modified, 0 errors
- [x] verify verdaccio responsive post-prune (lodash metadata 117 versions)
- [x] push alpine v1+v2 to registry → test GC scenario
- [x] delete manifest via DELETE API → re-run GC → freed 61M, registry restarted
- [x] patch registry-gc.sh — empty-storage guard
- [x] install `/etc/cron.d/vds-gc`, restart cron service
## Notes
- Verdaccio `_distfiles` keyed by tarball filename (`lodash-0.1.0.tgz`), не version. Gotcha — easy mistake.
- Multi-arch image push через современный buildkit оставляет manifest как OCI index. Для DELETE через API нужно `Accept: application/vnd.oci.image.manifest.v1+json` (или index variants). Иначе registry возвращает 404.
- `_attachments` field optional — на proxied packages обычно ~5-10 entries (только cached tarballs), на locally-published — все версии package.
- `du -sh` (default block-size) vs `du -sb` (bytes) могут rounding-discrepancy на 5-10%. Used `du -sb` в скриптах для precise byte math.
- registry compose mount `./docker:/var/lib/registry` → registry создаёт data в `/var/lib/registry/docker/registry/v2/...` → host path nested `/opt/stacks/registry/docker/docker/registry/v2/...`. Странно но работает.

View File

@@ -0,0 +1,224 @@
# vds-kzntsv-bootstrap
## Goal
Поднять облачный VDS `vds.kzntsv.site` (Rusonyx) и вынести туда ключевые инфраструктурные сервисы пользователя, чтобы не зависеть от собственного железа (мёртвая NAS показала single-point-of-failure). Цель — устранить риск повторения 2026-05-18 для **инфраструктурного** слоя (gitea/verdaccio/seafile/registry/hermes); production CMS (MoreThenCms) остаётся на [[windows-recovery-host]] и обсуждается отдельно в [[future-resilient-architecture-goals]].
После миграции [[kreknin-synology]] остаётся как backup target, не как live host инфры.
## Сервисы под миграцию (snapshot 2026-05-19)
Источник размеров — `du -sh /volume1/docker/*/` на kreknin (см. Decisions log 2026-05-19).
| Сервис | Сейчас на kreknin | После cleanup / на VDS | План |
|---|---|---|---|
| gitea | `/volume1/docker/gitea/` 2.6G | ~2.6G | lift-and-shift (compose + data tar) |
| verdaccio | `/volume1/docker/personal/verdaccio/` 8.5G | 23G | prune old tarballs до миграции |
| owncloud | `/volume1/docker/owncloud/` 187M + дубль 195M | — | **отказ**, заменяется seafile |
| seafile | (новый) | 3040G | green install на VDS |
| registry | `/volume1/docker/infrastucture/registry/` 99G | 515G | **`registry garbage-collect` ДО миграции** (write op, требует read-only/stopped registry) |
| hermes | `/volume1/docker/hermes/` 0 (пусто на kreknin) | ~10G (user estimate) | TBD — что это, где state |
Раскладка после cleanup: ~5575G data + ~5G OS/docker → ~80100G с headroom.
## Тариф VDS (Rusonyx, https://www.rusonyx.ru/hosting/vps/#ssd)
**Заказан (финал, user 2026-05-19): `160 NVMe`** (Rusonyx переименовал прежний `160 SSD` тариф в NVMe — апгрейд storage по той же цене, IOPS выше).
Конфигурация заказа:
- 6 vCPU 2.6GHz
- 8192 MiB RAM (8 GiB)
- 163840 MiB disk (160 GiB) NVMe
- Ubuntu Server 24.04
- 1 IPv4 (free)
- Лицензия / CMS / ispmanager — нет (docker-only, control-panel мусор не нужен)
- VPS Backup от Rusonyx — 0 шт (свой backup через rsync/borg → kreknin или off-site cloud)
- SSH root access — Вкл на старте (после bootstrap — отключить, sudo-user)
Reasoning:
- 160GB headroom ~45% на старте после миграции (~60-70G data + 5G OS) — годен на 2-3 года без add-on operations.
- 8GB RAM overkill для baseline (~2.1G) но даёт реальный запас под burst и любые будущие сервисы.
- User выбрал «купи-и-забудь» вариант over 80 SSD+add-on; +1000 ₽/мес vs 80 SSD = +12k₽/год за operational simplicity.
**Не выбраны:**
- 40 SSD — 4GB RAM впритык, OOM risk под seafile+registry burst.
- 80 SSD — RAM ок, но 80GB диск требует add-on (цены непрозрачны без звонка в managers).
- 220+ SSD — overkill без local LLM-inference.
## Open questions
- [ ] **Hermes** — Nous Research agent runtime (https://hermes-agent.nousresearch.com/). Открытые подвопросы:
- self-host их open-source / docker image, или client-wrapper к managed API?
- если self-host — какой репо/образ, какие порты, какие external deps (vector DB, LLM endpoint)?
- state где живёт (postgres / sqlite / files / vector store)?
- 10G — это weights/embeddings/vector store/document cache?
- влияет на RAM-выбор тарифа (если local LLM inference — 8GB мало, нужно 16+)
- [x] ~~Owncloud дубль~~**live = `/volume1/docker/owncloud/`** (vitya:users, mysql активен 2026-05-20), stale = `/volume1/docker/personal/owncloud/` (alexey, mysql last May 5). Owncloud в scope этих 3 фаз не входит — user явно убрал в Phase 3.
- [x] ~~DNS-cut стратегия~~ — DNS A-records проставлены user'ом 2026-05-20 сразу на VDS IP до bootstrap'а (`vds`, `*.vds`, `git`, `registry`, `verdaccio`). Сервисы на kreknin продолжают отвечать пока traefik там жив; cut фактический произойдёт когда remote DNS resolver кэш протухнет (≤ TTL).
- [ ] Backup VDS → kreknin: какой механизм? rsnapshot / restic / borg / Hyper Backup pull через SFTP? (deferred — после Phase 3)
- [x] ~~OS на VDS~~**Ubuntu 24.04 LTS** (decision 2026-05-19): LTS до апреля 2029, docker official APT repo flow, mainstream community для docker-стека, гарантированно есть в Rusonyx templates.
## Key files
(пока нет; появятся по ходу — compose-файлы, ansible-плейбук если будет, sync scripts)
## 🚨 Pre-Phase-1 — Rusonyx warning 2026-05-20
**`apt upgrade` Ubuntu 24.04 на Rusonyx виртуализации перезапускает SSH service. Делать ТОЛЬКО через VNC console Rusonyx-панели**, иначе SSH рвётся посередине, апгрейд бьётся.
Sequence (paste-ready в VNC console, root login):
```bash
apt update
apt upgrade -y
apt --fix-broken install -y
apt upgrade -y
```
После reboot SSH повторно достижим (89.253.255.94, root, пароль из `vds-kzntsv.env`). Отсюда мой Phase 1 начинается.
## Connectivity (2026-05-20)
- IP: `89.253.255.94`
- Vendor hostname: `vps-21075162-534388.host4g.ru`
- DNS (REGRU, user 2026-05-20):
- A `vds.kzntsv.site` → 89.253.255.94
- A `*.vds.kzntsv.site` → 89.253.255.94
- A `git.kzntsv.site` → 89.253.255.94
- A `registry.kzntsv.site` → 89.253.255.94
- A `verdaccio.kzntsv.site` → 89.253.255.94
- Креды (root initial + sudo user vitya + portainer admin + LE email): `C:\Users\vitya\projects\.common\secrets\vds-kzntsv.env`. Root pass одноразовый, rotate'нется в Phase 1 (PasswordAuthentication off, SSH-key-only).
## Kreknin pre-migration findings (probe 2026-05-20)
SSH `vitya@195.19.90.188` через `id_ed25519_kreknin` ✅. Sudo требует пароль (пока не у меня).
| Сервис | Путь | Размер | DB | Compose live? |
|---|---|---|---|---|
| gitea | `/volume1/docker/gitea/` | data 2.6G + own postgres 9.6 dir | внутренний Postgres 9.6 (`gitea:gitea`) | ✅ `gitea` + `gitea-db` на сети `proxy` |
| verdaccio | `/volume1/docker/personal/verdaccio/` | storage 8.5G + config 8K | нет | ✅ |
| registry | `/volume1/docker/infrastucture/registry/` | **99G** | нет (auth + docker filesystem) | ✅ (compose-файл есть) |
| owncloud-live | `/volume1/docker/owncloud/` | mysql активен 2026-05-20 | mysql + redis в одном compose | ✅ live (vitya:users owner) |
| owncloud-stale | `/volume1/docker/personal/owncloud/` | mysql последний May 5 | mysql + redis | устарел |
| hermes | `/volume1/docker/hermes/` | только `/data/` (uid 10000), нет compose | ? | ❓ конфиг где-то ещё (DSM Container Manager?) — open question |
## Phase 1 — Bootstrap (план, после VNC-upgrade)
🖥️ paste-ready, root@89.253.255.94 через SSH (после VNC-upgrade reboot)
1. `adduser --gecos "" --disabled-password vitya` + `echo 'vitya:Pryakhin10~' | chpasswd` + `usermod -aG sudo vitya`.
2. `mkdir -p /home/vitya/.ssh && echo '<pubkey>' > /home/vitya/.ssh/authorized_keys && chmod 700 /home/vitya/.ssh && chmod 600 /home/vitya/.ssh/authorized_keys && chown -R vitya:vitya /home/vitya/.ssh`. Pubkey = `~/.ssh/id_ed25519.pub` с Windows-PC.
3. Тест login `ssh vitya@89.253.255.94` отдельным окном **до** harden sshd (lockout-safety).
4. Harden sshd: `sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/; s/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config && systemctl reload sshd`.
5. `apt install -y ufw fail2ban` + `ufw default deny incoming && ufw default allow outgoing && ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable`. fail2ban sshd jail дефолт-on.
6. Docker official APT:
```bash
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable" > /etc/apt/sources.list.d/docker.list
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
usermod -aG docker vitya
```
7. `mkdir -p /opt/stacks/{traefik,portainer,databases}`.
8. Traefik compose (`traefik:v3.0`), HTTP-01 challenge (DNS уже на VDS), per-subdomain certs. Dashboard на `traefik.vds.kzntsv.site` с basicAuth `vitya:Pryakhin9` (htpasswd-hashed).
9. Portainer compose (`portainer/portainer-ce:latest`), labels → `portainer.vds.kzntsv.site`. First-visit setup wizard: admin `vitya` / `vitya.kuznetsov@gmail.com` / `Pryakhin9`. Generate API key → дописать в `vds-kzntsv.env` `PORTAINER_API_KEY=...`. С этого момента я могу деплоить stacks через Portainer REST API.
**Traefik v2.11 vs v3.0 decision:** v3 mainline, breaking changes в middleware label syntax. v2.11 LTS до Q1 2027, совместим с существующими compose-стеками на windows-recovery-host. Recommend **v3.0** — VDS green install, нет legacy compose-файлов к pin'ить; за год v3 уже зрелый.
## Phase 2 — Shared DBs (план)
DB-park (Postgres 16, MariaDB 11, Redis 7, MongoDB? — см. Open questions). Каждый — отдельный compose в `/opt/stacks/databases/<engine>/`, на общей docker network `shared-dbs` (external). Admin GUI через Portainer (или отдельные образы adminer/pgadmin/redis-commander если нужно).
Exposure model — см. Open questions ниже.
## Phase 3 — Migration с kreknin
### 🚨 Источник данных — restored backup, НЕ live containers
Данные `/volume1/docker/{gitea,personal/verdaccio,infrastucture/registry}/` на [[kreknin-synology]] это **restored Hyper Backup** мёртвой [[dead-synology-diskstation]] (restore сессии 2026-05-18 вытащил `/docker` шару из `.hbk` репо). На kreknin сами эти сервисы **не запущены** — files сидят на disk. Поэтому миграция = чистый pull данных + standup на VDS, **без docker stop / pg_dump на kreknin**. Container'ы умерли вместе с DiskStation 2026-05-18.
Read first: `.wiki/concepts/hyper-backup-structure-and-recovery.md`, `.wiki/sources/nas-recovery-session-2026-05-18.md`, `.wiki/entities/kreknin-synology.md`, `.wiki/entities/dead-synology-diskstation.md`.
### 3.1 Gitea
1. На kreknin (через sudo, перм issue на postgres dir): `tar c -C /volume1/docker/gitea . | ssh vds 'tar x -C /opt/migrate/gitea/'` — pulls `data/` + `postgres/` + `docker-compose.yml`. Hyper Backup restored файлы могут иметь Synology ACL + funky POSIX perms (см. [[hyper-backup-structure-and-recovery]] раздел ACL); rsync через root tar выровняет.
2. На VDS: `chown -R 999:999 /opt/migrate/gitea/postgres && chmod 700 /opt/migrate/gitea/postgres` (postgres uid 999, требует strict 700 на datadir).
3. На VDS: запустить **temporary** Postgres 9.6 на restored datadir → `docker run --rm -d --name pg96-temp -v /opt/migrate/gitea/postgres:/var/lib/postgresql/data postgres:9.6` (env `POSTGRES_USER=gitea POSTGRES_PASSWORD=gitea POSTGRES_DB=gitea`). Подождать `pg_isready`.
4. На VDS: `docker exec pg96-temp pg_dump -U gitea gitea > /opt/migrate/gitea.sql` → ~80-200 MB SQL.
5. На VDS shared postgres-16: `psql -U postgres -c 'CREATE DATABASE gitea OWNER gitea;'` (после создания юзера gitea в shared cluster) → `psql -U gitea -d gitea < /opt/migrate/gitea.sql`. Гитеа автоматически мигрирует schema под 16 (Gitea умеет).
6. Stop temp pg96, удалить `/opt/migrate/gitea/postgres/` (больше не нужно — данные в shared postgres).
7. На VDS Portainer stack:
```yaml
services:
gitea:
image: gitea/gitea:1.25.5
environment:
- USER_UID=1000
- USER_GID=1000
- DB_TYPE=postgres
- DB_HOST=postgres:5432 # shared
- DB_NAME=gitea
- DB_USER=gitea
- DB_PASSWD=gitea
volumes:
- /opt/stacks/gitea/data:/data
networks: [proxy, shared-dbs]
labels:
- traefik.enable=true
- traefik.http.routers.gitea.rule=Host(`git.kzntsv.site`)
- traefik.http.routers.gitea.entrypoints=websecure
- traefik.http.routers.gitea.tls.certresolver=letsEncrypt
- traefik.http.services.gitea.loadbalancer.server.port=3000
```
`data/` смонтировать с `/opt/migrate/gitea/data/` (или mv туда).
8. Smoke: `git.kzntsv.site` → existing user login (data restored) → repo browse → clone test.
9. Decommission на kreknin: ничего не делаем, файлы restored backup и так сидят паркингом на kreknin volume. Не трогать.
### 3.2 Verdaccio
1. На kreknin → VDS: rsync (через `scp -O` или `tar | ssh`) `/volume1/docker/personal/verdaccio/{storage,config}/` → vds:/opt/stacks/verdaccio/.
2. На VDS: chown под uid контейнера verdaccio (10001, см. verdaccio Dockerfile).
3. **Pre-clean ПОСЛЕ rsync, на VDS** (не на kreknin — кreknin это backup-target read-only-bydefault): удалить старые tarball'ы > N версий из `storage/<scope>/<package>/` либо просто оставить как есть (8.5G нормально для 160 GB VDS).
4. На VDS Portainer stack: image `verdaccio/verdaccio:6`, volumes `/opt/stacks/verdaccio/storage:/verdaccio/storage` и `config:/verdaccio/conf`, labels на `verdaccio.kzntsv.site`.
5. Smoke: `npm publish` тест с windows-recovery-host против `verdaccio.kzntsv.site`.
### 3.3 Registry
1. На kreknin: pre-clean GC доступен **без** running registry container — запустить temp registry:2 локально на kreknin против restored datadir: `sudo docker run --rm -v /volume1/docker/infrastucture/registry/docker:/var/lib/registry -v /volume1/docker/infrastucture/registry/config.yml:/etc/docker/registry/config.yml registry:2 garbage-collect /etc/docker/registry/config.yml`. **Write op on kreknin** — требует согласия user'а (правка backup'а на kreknin диске). Альтернатива: skip GC на kreknin → rsync 99G сетью → GC на VDS пост-фактум (медленнее по сети, безопаснее для kreknin).
2. На kreknin → VDS: rsync `/volume1/docker/infrastucture/registry/{auth,docker,docker-compose.yml,config.yml}` → vds:/opt/stacks/registry/.
3. На VDS Portainer stack: image `registry:2`, volumes для `auth` + `docker` (data) + `config.yml`, labels на `registry.kzntsv.site`. basicAuth middleware если в config задан htpasswd.
4. Smoke: `docker login registry.kzntsv.site` + `docker pull` известный image.
### Open question по 3.3 GC
- GC на kreknin (write-op на backup-target, ~30 мин обработка, экономит ~85G сетевого трафика и ~85G диска на VDS)
- GC на VDS пост-rsync (читает 99G по сети — медленно при типичном Rusonyx ~50-100 Mbps, ~3-5 ч; не трогает kreknin)
Recommend **GC на kreknin** — backup-target, но `garbage-collect` registry:2 пересоберёт data IN-PLACE, не deletes; risk минимальный.
Связанные wiki-страницы (для контекста):
- `.wiki/entities/kreknin-synology.md` — текущий host kreknin
- `.wiki/concepts/future-resilient-architecture-goals.md` — глобальные цели resilience
- `.wiki/concepts/recovery-architecture-snapshot.md` — текущая prod-инфра
## Decisions log
- **2026-05-19:** OS на VDS = **Ubuntu 24.04 LTS** (Noble). Reasoning: LTS support до апреля 2029, docker official APT flow, mainstream community для docker-workload. Debian 12 отвергнут — не даёт material выгоды при 8GB RAM (idle разница ~100M), а docker-docs primary-target — Ubuntu LTS.
- **2026-05-19 (заказан):** Тариф `160 NVMe` (Rusonyx переименовал 160 SSD → 160 NVMe, та же цена, апгрейд по IOPS). VPS Backup от Rusonyx — 0 шт (свой backup pipeline). SSH root — Вкл на bootstrap, потом отключить.
- **2026-05-19 (final tier):** User выбрал **160 SSD (2500 ₽/мес)**. Reasoning user'а — operational simplicity, не звонить в support за add-on ценой, есть запас на 2-3 года. +1000 ₽/мес vs 80 SSD приемлемо.
- **2026-05-19 (промежуточный заход, откатан):** Рекомендовалось 80 SSD + disk add-on исходя из того что 8GB RAM избыточно после уточнения hermes-профиля. User решил что 500 ₽/мес экономии не стоят звонков в support и риска что add-on окажется дорогой.
- **2026-05-19 (первый заход):** Изначально 160 SSD по budget-расчёту headroom; затем переоценено вниз после уточнения hermes; затем user вернул обратно к 160 SSD по user-preference.
- **2026-05-19:** Owncloud → seafile. Reasoning: пользователь решил заменить (rationale пока не записан).
- **2026-05-19:** Registry **garbage-collect ДО миграции** (на kreknin), чтобы не тащить 99G чтобы потом всё равно чистить.
- **2026-05-19:** Verdaccio тоже prune ДО миграции, по аналогичной логике.
## Next actions (по порядку)
1. **Уточнить hermes** — что это, где его state.
2. **Решить owncloud дубль** — нужны ли данные для миграции в seafile или green install.
3. **Registry GC на kreknin** — stop писателей, `docker run --rm -v ...:/var/lib/registry registry:2 garbage-collect /etc/docker/registry/config.yml`, measure delta. ⚠️ prod-changing, согласие от user.
4. **Verdaccio prune** — `npm cache clean` + удалить old tarballs из storage. (low risk, restorable из upstream npm)
5. ~~**Закупить тариф у Rusonyx**~~ → **заказан 160 NVMe, Ubuntu 24.04, 8GB/6vCPU/160GB, 1 IPv4** (2026-05-19, ожидание выделения IP).
6. **DNS** — A `vds.kzntsv.site → <IP>` в REGRU.
7. **Bootstrap VDS** (zero-day чек-лист): apt update/upgrade → создать sudo-user `vitya` + копировать SSH key → `PermitRootLogin no` + `PasswordAuthentication no` → ufw (22/80/443 only) → fail2ban → docker official APT repo (docker-ce + buildx + compose-plugin). Полная paste-ready команда в чате сессии.
8. **Per-service migration** (gitea → tarball+restore, verdaccio → tar storage, seafile → green install, registry → rsync, hermes → repo+state).
9. **Backup pipeline** VDS → kreknin (или cloud — Backblaze B2 для off-site, см. [[future-resilient-architecture-goals]]).
10. **DNS cut** к production, удаление сервисов с kreknin (с paranoid keep-on-kreknin-7days).

View File

@@ -0,0 +1,99 @@
# vds-ntfy-push
## Goal
Self-host [ntfy.sh](https://ntfy.sh) на VDS для push-нотификаций на телефон. Docker-image `binwiederhier/ntfy`. Использовать для:
- [[vds-backup-rsync-kreknin]] backup status (вместо/параллельно email на vitya.kuznetsov@gmail.com)
- Monitoring alerts (CMS down, traefik certs истекают, disk fill, registry GC fail, etc.)
- Любые ad-hoc уведомления от ops-скриптов
Domain: `ntfy.vds.kzntsv.site` (под уже существующим wildcard `*.vds.kzntsv.site`).
## Open questions
- [x] ~~**Auth model:**~~ per-topic ACL + admin user `vitya` (resolved 2026-05-20). Реализация: `NTFY_AUTH_DEFAULT_ACCESS=deny-all` + `ntfy user add --role=admin vitya`. Admin role → rw to all topics, per-topic ACL не нужен. Anon (no creds) → 403 на publish и subscribe ✅.
- [x] ~~**Топики:**~~ начали с двух: `vds-backup` (для vds-backup-rsync-kreknin) + `vds-ops` (general alerts: cert expiry, disk fill, container crashes). Можно добавлять без миграции — admin role даёт доступ ко всему автоматом.
- [x] ~~**Phone app:**~~ Android (resolved 2026-05-20) → ntfy Android app, pure self-host без APNs middleware.
- [x] ~~**Persistence:**~~ sqlite в `/opt/stacks/ntfy/data/` (cache.db + auth.db). Volume mount `./data:/var/cache/ntfy`.
- [x] ~~**Phone-side smoke:**~~ confirmed 2026-05-20 22:54 MSK — оба push'а («Topic renamed», «Password updated») пришли в Android ntfy app, screenshot в conversation.
## Implementation sketch
`/opt/stacks/ntfy/docker-compose.yml`:
```yaml
services:
ntfy:
image: binwiederhier/ntfy
container_name: ntfy
restart: unless-stopped
command:
- serve
networks:
- proxy
volumes:
- ./data:/var/cache/ntfy
- ./etc:/etc/ntfy
environment:
NTFY_BASE_URL: https://ntfy.vds.kzntsv.site
NTFY_CACHE_FILE: /var/cache/ntfy/cache.db
NTFY_AUTH_FILE: /var/cache/ntfy/auth.db
NTFY_AUTH_DEFAULT_ACCESS: deny-all
NTFY_BEHIND_PROXY: true
NTFY_ATTACHMENT_CACHE_DIR: /var/cache/ntfy/attachments
labels:
- traefik.enable=true
- traefik.http.routers.ntfy.rule=Host(`ntfy.vds.kzntsv.site`)
- traefik.http.routers.ntfy.entrypoints=websecure
- traefik.http.routers.ntfy.tls.certresolver=letsEncrypt
- traefik.http.services.ntfy.loadbalancer.server.port=80
networks:
proxy:
external: true
```
После up — `docker exec ntfy ntfy user add --role=admin vitya` → задать пароль → грант access на топики.
Publish from any script:
```bash
curl -u "vitya:$NTFY_PASS" \
-H "Title: VDS backup completed" \
-H "Tags: white_check_mark" \
-H "Priority: default" \
-d "Size 12.5G, 18m12s, kreknin OK" \
https://ntfy.vds.kzntsv.site/vds-backup
```
Phone subscribes to `https://ntfy.vds.kzntsv.site/vds-backup` (с basic auth) — получает уведомление.
## Decisions log
- **2026-05-20** — Image pinned `binwiederhier/ntfy:v2.11.0` (conservative, matches pin policy остальных стэков: traefik v2.11, portainer 2.21.5).
- **2026-05-20** — Auth: `NTFY_AUTH_DEFAULT_ACCESS=deny-all` + admin user `vitya` (random hex16 password). Admin role гранит rw ко всем топикам автоматом — per-topic `ntfy access` calls returned `user vitya is an admin user, access control entries have no effect`. Не нужны явные grants; разлогиниться от admin позже если будет потребность в ограниченных read-only users.
- **2026-05-20** — Topics: `vds-backup` + `vds-ops` (минимум для текущих нужд). Расширение бесплатное (admin → rw to all).
- **2026-05-20** — TLS через traefik LE http-01 (issuer R12, valid Aug 18 2026); ntfy listens HTTP `:80` внутри `proxy` network, `NTFY_BEHIND_PROXY=true` чтобы trust X-Forwarded-* от traefik.
- **2026-05-20** — Smoke green: anon publish/subscribe → 403, authed publish vds-backup+vds-ops → 200 с JSON id/ts.
- **2026-05-20** — User feedback: random hex password неудобен для ввода в phone app. Меняю на `Pryakhin9` (consistency с TRAEFIK_DASHBOARD_PASS). Trade-off: меньше entropy, но scope ограничен (admin role, single user, push-сервис без чувствительных данных, can rotate если threat model изменится). Lesson — для human-input creds (phone/web UI) использовать память user'а, не random hex; random hex оставить для script-only (DB, API keys).
- **2026-05-20** — Topics renamed `backup``vds-backup`, `ops``vds-ops` (consistency с VDS scope, упрощает filtering если позже добавятся nas-* или kreknin-* топики).
- **2026-05-20** — Phone-verified: Android ntfy app subscription → оба push'а пришли в течение секунд. End-to-end complete.
## Completed steps
- [x] `/opt/stacks/ntfy/{data}` создано (owner vitya:vitya)
- [x] `docker-compose.yml` написан с traefik labels (Host, websecure, letsEncrypt, port 80)
- [x] `docker compose up -d` → container healthy, listening :80
- [x] Admin user `vitya` добавлен через `printf "%s\n%s\n" "$PASS" "$PASS" | docker exec -i ntfy ntfy user add --role=admin vitya`
- [x] LE cert issued via http-01, R12, valid 2026-05-20 → 2026-08-18
- [x] Smoke test (publish/subscribe/anon-deny) green
- [x] Creds saved: `/opt/stacks/ntfy/.env` (chmod 600) + Windows `~/projects/.common/secrets/vds-kzntsv.env`
- [x] Password rotated random-hex → `Pryakhin9` per user request (ntfy user change-pass)
- [x] Topics renamed `backup`/`ops``vds-backup`/`vds-ops`
- [x] Phone-verified (Android ntfy app, screenshot 22:54 MSK)
## Notes
- Триггер: после `[[vds-kzntsv-bootstrap]]` Phase 3 и до или одновременно с `[[vds-backup-rsync-kreknin]]` (backup pipeline хочет ntfy для статус-уведомлений).
- Интегрируется с `[[vds-backup-rsync-kreknin]]` — backup script публикует через ntfy + дублируется email'ом для надёжности.
- **Android setup hint:** ntfy app → Add subscription → Topic `vds-backup` (или `vds-ops`) → Server `https://ntfy.vds.kzntsv.site` → enable «Use auth» → user `vitya` / password из vds-kzntsv.env.
- Cert renewal — automatic via traefik (letsEncrypt resolver), нет дополнительных шагов.