tasks: merge imported MoreThenCms task history with admin live agenda

- 7 admin per-task files moved from .tasks-imported/ to .tasks/ (renames) - NEXT-SESSION-PROMPT.md (iis-migration session handoff) kept as sibling - .tasks-imported/STATUS.md removed (content merged into admin STATUS.md) - admin STATUS.md gains 'Imported from MoreThenCms' section with all 7 admin done tasks verbatim. 4 CMS-domain task blocks excluded (stay in MoreThenCms): cms-admin-assets-root-folders-seed, cms-port-leak-fix, traefik-maljarka-502-bug, cms-maljarka-https-mode-bug-fix - morecms-subtree-split marked done (acceptance: 4 split branches exist with per-file history) - admin-subtree-import-and-cleanup marked active (in-progress this session) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-21 13:51:48 +03:00
parent 3cdcdad048
commit c55cb11948
10 changed files with 85 additions and 146 deletions
--- a/.tasks/NEXT-SESSION-PROMPT.md
+++ b/.tasks/NEXT-SESSION-PROMPT.md
@@ -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&amp;_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` — `&` → `&amp;` в conn-string
+- `.tasks/STATUS.md`
+- `.tasks/iis-on-host-migration.md` — Phase 1-9 история
+- Это сообщение
--- a/.tasks/STATUS.md
+++ b/.tasks/STATUS.md
@@ -37,11 +37,12 @@ Do **not** invent migration recipes, file lists, taxonomies, or scope decisions

 ---

-## ⚪ [morecms-subtree-split] — Шаг 2 миграции: в `~/projects/MoreThenCms` создать 4 subtree-split ветки, каждая хранит per-file history своего dir'а. Эти ветки потом импортируются в admin (см. `admin-subtree-import-and-cleanup`).
+## 🟢 [morecms-subtree-split] — Шаг 2 миграции: в `~/projects/MoreThenCms` создать 4 subtree-split ветки, каждая хранит per-file history своего dir'а. Эти ветки потом импортируются в admin (см. `admin-subtree-import-and-cleanup`).

 См. `.wiki/concepts/admin-infra-project.md` §Migration mechanics шаг 2 для полного контекста.

-**Status:** ready
+**Status:** done
+**Closed:** 2026-05-21 — 4 split branches созданы в `~/projects/MoreThenCms` (split-wiki-entities @24661c10, split-wiki-sources @a5e96432, split-wiki-concepts @c727aaa1, split-tasks @cbdc2b39). Acceptance: per-file history preserved (verified via subsequent subtree-add in admin). Не push'ились — служебные.
 **Where I stopped:** (not started)
 **Next action:** ```powershell
 cd ~/projects/MoreThenCms
@@ -59,11 +60,11 @@ Done — пометить 🟢 + переходить к `admin-subtree-import-a

 ---

-## 🔵 [admin-subtree-import-and-cleanup] — Шаги 3-7 миграции: импорт 4 split-веток из MoreThenCms в admin (clean prefixes через `git subtree add`, populated prefixes через `git read-tree --prefix` merge), cleanup CMS-следов из mixed splits, STATUS.md merge, index.md regen, push на Gitea.
+## 🔴 [admin-subtree-import-and-cleanup] — Шаги 3-7 миграции: импорт 4 split-веток из MoreThenCms в admin (clean prefixes через `git subtree add`, populated prefixes — temp-prefix dance с `git subtree add` + `git mv` для history-preservation через merge-commit + rename; read-tree вариант spec'a отвергнут — не сохраняет parent-link к morecms history → `git log --follow` не доходит до morecms-era коммитов), cleanup CMS-следов из mixed splits, STATUS.md merge, index.md regen, push на Gitea.

 Объединено в одну таску потому что: тот же agent, та же session, sequential steps без natural review-point между ними. См. `.wiki/concepts/admin-infra-project.md` §Migration mechanics шаги 3-7.

-**Status:** blocked
+**Status:** active
 **Where I stopped:** (not started)
 **Next action:** **3a. Clean prefixes:**
 ```powershell
@@ -123,8 +124,7 @@ Acceptance:
 - Gitea web shows updated tree

 Done — 🟢; unblock `morecms-cleanup-and-breadcrumb` + `resilience-roadmap-design`.
-**Blocker:** morecms-subtree-split
-**Branch:** n/a
+**Branch:** master
 <!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-05-21T10:23:14.254Z -->

 ---
@@ -385,8 +385,86 @@ Done — 🟢; secret-management dyra closed.
 **Status:** blocked
 **Where I stopped:** (not started)
 **Next action:** Дождаться 🟢 у всех blocker-тасок (включая `admin-infra-project-pointers` — без него pointers в `.wiki/CLAUDE.md` не залиты, и review будет читать stub). Прочитать спецификацию (см. путь в description). Для каждой импл-таски: `git show <commit>`, прогнать acceptance criteria из её next_action, сверить с design-decisions в спецификации. Findings → новые follow-up tasks через `mcp__projects-meta__tasks_create`.
-**Blocker:** migration: morecms-subtree-split, admin-subtree-import-and-cleanup, morecms-cleanup-and-breadcrumb, verify-migration; agenda: resilience-roadmap-design, secrets-out-of-common, secrets-manager-adopt
+**Blocker:** migration: admin-subtree-import-and-cleanup, morecms-cleanup-and-breadcrumb, verify-migration; agenda: resilience-roadmap-design, secrets-out-of-common, secrets-manager-adopt
 **Branch:** n/a
 <!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-05-21T10:25:43.430Z -->

 ---
+
+# Imported from MoreThenCms — 2026-05-21 subtree-split migration
+
+Полное содержимое `.tasks/STATUS.md` из MoreThenCms на момент 2026-05-21, **CMS-domain блоки исключены** (остались в MoreThenCms): `cms-admin-assets-root-folders-seed`, `cms-port-leak-fix`, `traefik-maljarka-502-bug`, `cms-maljarka-https-mode-bug-fix`. История per-file сохранена через subtree-split + temp-prefix merge.
+
+## 🟢 [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` (CMS-domain — остаётся в MoreThenCms).
+**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
+
+---
+
+## 🟢 [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
+
+---
--- a/.tasks/iis-on-host-migration.md
+++ b/.tasks/iis-on-host-migration.md
@@ -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).
--- a/.tasks/iis-traefik-dead-routes-cleanup.md
+++ b/.tasks/iis-traefik-dead-routes-cleanup.md
@@ -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`.
--- a/.tasks/nas-recovery.md
+++ b/.tasks/nas-recovery.md
@@ -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.
--- a/.tasks/vds-backup-rsync-kreknin.md
+++ b/.tasks/vds-backup-rsync-kreknin.md
@@ -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'`
--- a/.tasks/vds-gc-cron.md
+++ b/.tasks/vds-gc-cron.md
@@ -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/...`. Странно но работает.
--- a/.tasks/vds-kzntsv-bootstrap.md
+++ b/.tasks/vds-kzntsv-bootstrap.md
@@ -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 | 2–3G | prune old tarballs до миграции |
+| owncloud | `/volume1/docker/owncloud/` 187M + дубль 195M | — | **отказ**, заменяется seafile |
+| seafile | (новый) | 30–40G | green install на VDS |
+| registry | `/volume1/docker/infrastucture/registry/` 99G | 5–15G | **`registry garbage-collect` ДО миграции** (write op, требует read-only/stopped registry) |
+| hermes | `/volume1/docker/hermes/` 0 (пусто на kreknin) | ~10G (user estimate) | TBD — что это, где state |
+
+Раскладка после cleanup: ~55–75G data + ~5G OS/docker → ~80–100G с 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).
--- a/.tasks/vds-ntfy-push.md
+++ b/.tasks/vds-ntfy-push.md
@@ -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), нет дополнительных шагов.