tasks(minio+iis): close 🟢 — CMS image pipeline стоп-на-windows-host

Finding: MoreThenCms.Modules.Imgproxy.dll (closed-source) содержит
hardcoded https://imgproxy.kzntsv.site URL (strings analysis из binary).
Архитектура: browser → traefik → IIS snolla → ImgproxyHandler →
server-side GET imgproxy.kzntsv.site → windows-host traefik → imgproxy-nginx
→ imgproxy → MinIO localhost:9000.

Sample URL decode: https://www.pilorama98.ru/imgproxy/<sig>/.../
czM6Ly9waWxvcmFtYTk4L3Byb2R1Y3RzL2wv... → base64 =
s3://pilorama98/products/l/<uuid>.jpg

DLL closed-source, исходника в репо нет. 4 options рассмотрены
(hosts+cert trick / nginx-relay / keep-as-is / decompile+recompile).
User decision: Option C — оставить как есть. Windows-host imgproxy/nginx
/MinIO живут indefinitely, VDS stack = standby.

minio-imgproxy-vds-migration 🟢 — VDS stack ready as standby
iis-cutover-to-vds-services 🟢 — MSSQL leg done, image pipeline stays
Decommission window-host MSSQL осtaется (48ч soak до 2026-05-24);
MinIO/imgproxy/nginx на windows — НЕ decommission.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-22 10:47:29 +03:00
parent 8a30696a45
commit adcd8bda1f
2 changed files with 47 additions and 19 deletions

View File

@@ -1,5 +1,5 @@
# Admin Task Board
_Updated: 2026-05-22 (MSSQL+MinIO миграция за одну сессию: MSSQL Express 2022 live на `mssql.kzntsv.site:1433` с 5 restored DBs, IIS snolla site cutover ✓ — 8 prod hosts 200 OK; MinIO stack live на VDS, 3 GiB / 19324 obj mirrored с upgrade 2020→2025 ✓; VDS imgproxy постоянно на `imgproxy.vds.kzntsv.site``imgproxy.kzntsv.site` занят другим сервисом на другом сервере, не наш scope. CMS audit показал 0 refs на imgproxy/kzntsv/minio в snolla source/templates/DLL/DB — wiring CMS→VDS imgproxy = отдельная задача после идентификации actual consumer. 3 wiki concepts ingested. 48ч soak до decommission source MSSQL 2026-05-24.)_
_Updated: 2026-05-22 (Сессия завершена. MSSQL Express 2022 live на `mssql.kzntsv.site:1433` с 5 restored DBs, IIS snolla site cutover ✓ — 8 prod hosts 200 OK. MinIO/imgproxy: VDS stack live as standby (3 GiB / 19324 obj mirrored, upgrade 2020→2025), но CMS image pipeline остаётся на windows-host — closed-source `MoreThenCms.Modules.Imgproxy.dll` hardcoded `https://imgproxy.kzntsv.site` URL. User decision Option C. 3 wiki concepts ingested. Decommission window-host MSSQL после 48ч soak 2026-05-24; MinIO/imgproxy/nginx на windows остаются indefinitely.)_
<!--
Status legend:
@@ -559,7 +559,7 @@ Original umbrella `.tasks/mssql-minio-migration-to-vds.md` сохранён дл
---
## 🟡 [minio-imgproxy-vds-migration] — Data layer DONE 2026-05-22 (3 GiB / 19324 obj mirrored, upgrade 2020→2025 ✓). **VDS stack permanently on `imgproxy.vds.kzntsv.site`** — `imgproxy.kzntsv.site` занят другим сервисом на другом сервере, не наш scope. Wiring CMS↔VDS imgproxy pending audit (CMS не нашли refs в текущем коде/DB).
## 🟢 [minio-imgproxy-vds-migration] — Closed 2026-05-22 — VDS stack live as standby; CMS image pipeline остаётся на windows-host из-за hardcoded URL в closed-source DLL.
**Where I stopped:** Stack live на VDS (`minio.vds.kzntsv.site` + `minio-console.vds.kzntsv.site` + `imgproxy.vds.kzntsv.site` traefik routes ✓). Все buckets mirrored с format compat 2020→2025 verified (mc mirror through S3 API, не сырое filesystem). CMS image URLs пока рендерятся через windows-host imgproxy (DNS `imgproxy.kzntsv.site` всё ещё на windows IP).
@@ -575,11 +575,14 @@ Original umbrella `.tasks/mssql-minio-migration-to-vds.md` сохранён дл
**Findings закреплены в** [`minio-imgproxy-on-vds`](../.wiki/concepts/minio-imgproxy-on-vds.md) §Gotchas: (1) MinIO upgrade 5y gap works via mc mirror (S3 API), не bind-swap (xl.meta format), (2) mc 2025 НЕ auto-creates buckets, (3) silent skip non-ASCII filename + slow uplink → verify по count, (4) IMGPROXY_KEY/SALT preserve обязательно (HMAC signed URLs), (5) MINIO_ROOT_USER/PASSWORD replace deprecated MINIO_ACCESS_KEY/SECRET — reuse same values.
**Next action для completion:**
1. **Audit CMS image pipeline (NEW finding 2026-05-22):** грепы snolla source / Admin / DLL / DB SiteSettings + ModuleProperties не нашли НИ ОДНОЙ ссылки на `imgproxy.*` / `kzntsv` / `minio` / `localhost:9000`. Public HTML рендерится через relative `/images/` + `/themes/` (locally served IIS). `MoreThenCms.Modules.Imgproxy.dll` deployed но не wired в active flow — либо vestigial либо invoked dynamically через `Azure storage` connection string `AccountName=snolla;AccountKey=...` (Azure-style SDK против MinIO). **Кто реально читает source MinIO/imgproxy — не идентифицировано.** Перед decommission'ом source containers — нужно подтвердить через monitoring (logs windows-host MinIO в течение 24-48ч) что нет live тенанта.
2. Если есть live consumer (Azure SDK pattern): найти где `AccountName=snolla` connection string'и реально потребляются, переписать endpoint на VDS MinIO (`https://minio.vds.kzntsv.site`).
3. Backup pipeline integration в `/opt/stacks/backup/scripts/run.sh` (`minio_mirror` daily — rsync `/opt/stacks/storage/minio-imgproxy/data` → kreknin).
4. 48ч soak → decommission windows-host containers (см. iis-cutover decommission section).
**Resolution 2026-05-22:** `MoreThenCms.Modules.Imgproxy.dll` (closed-source, исходника в репо нет) содержит **hardcoded** `https://imgproxy.kzntsv.site` (decoded из DLL strings: `/imgproxy;https://imgproxy.kzntsv.site/-ImgproxyHandler_Invoke`). Архитектура: browser → traefik → IIS snolla → ImgproxyHandler → server-side GET к `imgproxy.kzntsv.site` → traefik windows-host → imgproxy-nginx → imgproxy → MinIO localhost:9000.
Sample URL (decoded): `https://www.pilorama98.ru/imgproxy/<sig>/.../czM6Ly9waWxvcmFtYTk4L3Byb2R1Y3RzL2wv...` → base64 = `s3://pilorama98/products/l/9d428089-...jpg` (MinIO bucket `pilorama98`).
Опции рассмотрены: A) hosts+cert trick + LE DNS-01 / B) local nginx-relay с self-signed + CallTrust unknown / C) keep as-is / D) decompile+recompile DLL. **User decision: Option C — оставить как есть.** Windows-host imgproxy/nginx/MinIO живут indefinitely; VDS stack — standby/backup target. Backup pipeline integration (rsync VDS MinIO → kreknin) — отдельная chore-task если понадобится.
**Windows-host MinIO/imgproxy/imgproxy-nginx остаются running** (не decommission). Decommission ALLOW только для windows-host MSSQL (см. iis-cutover-to-vds-services).
**Branch:** master
**Backup pipeline TODO:** `minio_mirror` daily в `/opt/stacks/backup/scripts/run.sh` — rsync `/opt/stacks/storage/minio-imgproxy/data` → kreknin.
@@ -588,7 +591,7 @@ Original umbrella `.tasks/mssql-minio-migration-to-vds.md` сохранён дл
---
## 🟡 [iis-cutover-to-vds-services] — MSSQL cutover DONE 2026-05-22 (8 hosts 200 OK ✓). MinIO image-pipeline — нет обнаруженных CMS refs (см. audit в `minio-imgproxy-vds-migration` Next action); VDS imgproxy постоянный home = `imgproxy.vds.kzntsv.site`.
## 🟢 [iis-cutover-to-vds-services] — Closed 2026-05-22 — MSSQL cutover live (8 hosts 200 OK ✓); MinIO image-pipeline остаётся на windows-host (user decision Option C — hardcoded URL в closed-source DLL).
**MSSQL phase complete:**
- Audit: `C:\sites\snolla\Web.config` обслуживает 11 CMS hosts (snolla catch-all `*:8089`). Только 1 conn-string на MoreThenCms DB, login `snolla` (не sa).
@@ -599,12 +602,12 @@ Original umbrella `.tasks/mssql-minio-migration-to-vds.md` сохранён дл
- IIS auto-recycle на web.config touch (без iisreset).
- Smoke 8 priority hosts: emspb/snolla.com→on.snolla/pilorama98/labtools.ru/labtools.pro/www.tandemmebel/kupimknigi — **все 200 OK**, latency 0.3-3.1s (tandemmebel самый медленный — большая страница).
**MinIO image-pipeline phase (audit revealed нет обнаруженных refs):**
- В `web.config`'ах **нет** refs `localhost:9000` / `localhost:8788` / `imgproxy` / `kzntsv` / `minio`.
- В snolla source / Admin templates / DLL strings / DB SiteSettings + ModuleProperties — тоже 0 refs.
- Public HTML рендерится через relative `/images/` + `/themes/` (locally served IIS).
- **Возможный invocation path**: Azure storage SDK через `AccountName=snolla;AccountKey=...` connection string в snolla/Web.config — Azure-compat доступ к MinIO. Endpoint неизвестен (нужен grep кода Azure storage usage).
- **Decision:** VDS imgproxy остаётся постоянно на `imgproxy.vds.kzntsv.site` (`imgproxy.kzntsv.site` занят другим сервисом на другом сервере). При необходимости wiring CMS → VDS imgproxy будет отдельной задачей после идентификации actual consumer.
**MinIO image-pipeline phase: NOT migrated (user decision Option C):**
- `MoreThenCms.Modules.Imgproxy.dll` hardcoded `https://imgproxy.kzntsv.site` (strings analysis 2026-05-22).
- DLL closed-source, исходника в репо нет; decompile+recompile = ad-hoc-fragile.
- **CMS image pipeline остаётся целиком на windows-host** (imgproxy/nginx/MinIO + traefik route `imgproxy.kzntsv.site` → imgproxy-nginx:80).
- VDS MinIO+imgproxy stack — standby / future use only. Backup target rsync — optional chore.
- Decommission windows-host: **TOLLY MSSQL container** (после 48ч soak). MinIO/imgproxy/imgproxy-nginx — остаются.
**48ч soak:** monitor через ntfy `vds-ops` + manual smoke 24h/48h marks. Source windows-host MSSQL container оставить running до 2026-05-24 для rollback.

View File

@@ -1,6 +1,6 @@
---
title: MinIO + imgproxy stack on vds-kzntsv
status: live (data-layer); VDS imgproxy postoянно на imgproxy.vds.kzntsv.site (imgproxy.kzntsv.site занят другим сервисом, не наш scope)
status: live as standby — CMS image pipeline остаётся на windows-host (closed-source DLL hardcoded URL)
tags: [vds, minio, imgproxy, migration, ops]
related: [[vds-kzntsv]], [[recovery-architecture-snapshot]], [[mssql-on-vds]]
---
@@ -78,13 +78,38 @@ done
4. **IMGPROXY_KEY + IMGPROXY_SALT preserve обязательно** — это HMAC signing для URLs. Если поменять, все pre-existing CMS image URLs (signed ссылки в шаблонах + кешированные в admin) ломаются. Reuse same values из source.
5. **MinIO root creds vs AWS-style**: source использует MINIO_ACCESS_KEY/MINIO_SECRET_KEY (deprecated env vars), новый MinIO — MINIO_ROOT_USER/MINIO_ROOT_PASSWORD. Reuse same values (no rotation в этой миграции) → CMS+imgproxy credentials не меняются. Rotation — отдельная hardening-таска.
## Domain decision
## CMS image pipeline — DLL hardcoded constraint (2026-05-22 finding)
`imgproxy.kzntsv.site`**занят другим сервисом на другом сервере** (не наш scope, user confirmed 2026-05-22). VDS imgproxy постоянный home = `imgproxy.vds.kzntsv.site`.
Browser-side URL pattern: `https://www.<site>/imgproxy/<sig>/fill/W/H/no/1/<base64(s3://<bucket>/<path>)>.<ext>`. Sample (working URL provided by user):
```
https://www.pilorama98.ru/imgproxy/3rGOrTLEtTSjsrwvbs2fe75A1jDHFGPbaSe9ea7vtPQ/fill/800/800/no/1/czM6Ly9waWxvcmFtYTk4L3Byb2R1Y3RzL2wvOWQ0MjgwODktMGFjYi00ZGM2LWE3YjAtMGQxYzIxN2E1ZTFjLmpwZw.webp
```
Base64 source decode: `s3://pilorama98/products/l/9d428089-0acb-4dc6-a7b0-0d1c217a5e1c.jpg`. HMAC signature `3rGOr...` computed from `IMGPROXY_KEY + SALT` (preserved в нашей миграции).
CMS audit 2026-05-22 показал: snolla source / Admin templates / DLL strings / DB SiteSettings + ModuleProperties — НИ ОДНОЙ ссылки на imgproxy/kzntsv/minio/localhost:9000. Public HTML — relative `/images/` + `/themes/` (locally served IIS). `MoreThenCms.Modules.Imgproxy.dll` deployed but не wired в active flow (vestigial), либо invoked dynamically через Azure storage SDK (`AccountName=snolla;AccountKey=...` в snolla/Web.config — Azure-compat доступ).
**Server-side architecture:**
```
Browser → https://www.<site>/imgproxy/<sig>/...
→ traefik (windows-host) → IIS snolla site :8089
→ ImgproxyHandler (MoreThenCms.Modules.Imgproxy.dll, closed-source)
→ HTTP GET https://imgproxy.kzntsv.site/<sig>/... (HARDCODED in DLL)
→ traefik (windows-host) imgproxy.yml route
→ imgproxy-nginx:80 → imgproxy → MinIO localhost:9000
```
Если в будущем CMS будет wired к VDS imgproxy — endpoint = `https://imgproxy.vds.kzntsv.site` (плюс update `IMGPROXY_S3_ENDPOINT` если нужно, но он уже internal через docker DNS = `http://minio:9000`).
Decoded DLL strings (`cat MoreThenCms.Modules.Imgproxy.dll | tr -cd '[:print:]\n' | grep -oE ...`):
```
/imgproxy;https://imgproxy.kzntsv.site/-ImgproxyHandler_Invoke
```
`MoreThenCms.Modules.Imgproxy.dll` closed-source (исходника нет в `~/projects/MoreThenCms`; ни одного `*.cs` файла с `imgproxy` literal). Options для cutover:
- A) Hosts file + DNS-01 cert trick — средняя сложность
- B) Local nginx-relay на windows + self-signed cert + CallTrust поведение DLL unknown — средне-высокая
- C) Keep as-is — windows-host imgproxy/nginx/MinIO живут indefinitely, VDS stack = standby
- D) Decompile + recompile DLL — высокая, fragile (binding+strong-name)
**User decision 2026-05-22: Option C.** Image pipeline остаётся на windows-host; VDS stack — standby/future use. Decommission windows-host MinIO/imgproxy/imgproxy-nginx НЕ выполняется.
Если в будущем понадобится cutover — рассматривать Option A (DNS-01 challenge через REGRU API) как наиболее clean путь, при условии что `imgproxy.kzntsv.site` снова станет нашим (сейчас занят другим сервисом на другом сервере).
## Rollback