[2026-09-28] eagle: family/how-to/truenas-infrastructure.md family/plans/lidarr-taiga-deploy.md personal/plans/flaresolverr-taiga-deploy.md personal/tech/flaresolverr-taiga.md

family/how-to/truenas-infrastructure.md

@@ -602,7 +602,7 @@ docker run --rm -v <db-dir>:/database filebrowser/filebrowser:latest config set
 | ~~cam.mallexxx.duckdns.org~~ | **❌ УБРАН из Caddyfile (2026-09-14).** Исторический upstream: `192.168.2.197:8090` — отдельный HTTP-MJPEG-сервис (`ustreamer`), контейнер утрачен при пересоздании пула. **Камера теперь на t610:** аддон **`a889bffc_go2rtc-hardware`** → RTSP H.264 `rtsp://192.168.2.176:8554/usb_camera_h264` → `camera.192_168_2_176` (зона Котельная, **WebRTC работает**, поворот `#rotate=90`). Домен не нужен. Подробно [[family/how-to/home-automation]] §5-кватер-И-6 |
 | **vpn-panel.mallexxx.duckdns.org** | **3x-ui панель :2053** (добавлен 2026-09-01) |
 | **vpn.mallexxx.duckdns.org** | **Xray VLESS-WS (путь /vless) → xray-admin:10095** (добавлен 2026-09-01) |
-| **vnc.mallexxx.duckdns.org** | **noVNC FlareSolverr :6080** 🔒 basic_auth (user: admin) — ручное решение капчи RuTracker (2026-09-29). Caddy должен быть в сети `media_net` (`docker network connect media_net caddy`), иначе `flaresolverr:6080` не резолвится. Подробно [[personal/tech/flaresolverr-taiga]] |
+| ~~vnc.mallexxx.duckdns.org~~ | **❌ УБРАН из Caddyfile (2026-09-29).** Был noVNC-роут на `flaresolverr:6080` для ручного решения капчи RuTracker. Гипотеза оказалась **ложной** (капча = симптом неверного пароля, Prowlarr логинится сам) → образ `flaresolverr-vnc`, порт 6080, volume и роут снесены. Caddy отключён от `media_net`. Подробно [[personal/tech/flaresolverr-taiga]] §Откат |
 
 > ### ✅ SUBSCRIPTION-КАНАЛ (auto-обновление клиентов) — работает, проверено 2026-09-15
 >

family/plans/lidarr-taiga-deploy.md

@@ -8,9 +8,14 @@
 (`docker restart` + снятие карантина в Prowlarr + `?forceSave=true`). Найден и исправлен
 последний дефект Lidarr — **`proxyBypassFilter` без внутренних docker-имён** (см. питфолл).
 ✅ **Все правки применены, включая `docker restart lidarr`** — задача закрыта.
-**Финал сессии:** RuTracker **починен Alex'ом** (логин жив; капча отдаётся только «холодным»
-сессиям — `session=prowlarr` её обходит, см. [[personal/tech/flaresolverr-taiga]]),
-карантин снят тестом полным объектом → Prowlarr `indexerstatus` → `[]`, `caps` → **200**.
+**Финал сессии:** RuTracker **работает штатно** — Prowlarr логинится **автоматически**.
+🔴 **Уточнение 2026-09-29:** ранняя версия «капча отдаётся только холодным сессиям,
+`session=prowlarr` её обходит» — **ложный след**. Настоящая причина «Auth Failed» была в том,
+что диагностика шла **другим аккаунтом** (`keropjan_88`) вместо хранящегося в Prowlarr
+(`mallexxx`). Капча — симптом неверного пароля. С верной парой логин проходит без капчи,
+кука авторизации — **`bb_session`** (не `bb_data`). Приёмка 2026-09-29: поиск → **50 результатов**.
+См. [[personal/tech/flaresolverr-taiga]].
+Карантин снимается **только SQL** (`DELETE FROM IndexerStatus`), тест его **продлевает**.
 **Найден и закрыт дефект пути загрузки:** `musicCategory` была **пустая** → Transmission
 положил бы файл без категории, и **импорт в библиотеку упал бы**. Исправлено на
 `musicCategory=lidarr` (дефолт Lidarr, НЕ `music`; каталог `/mnt/storage/Downloads/lidarr`

personal/plans/flaresolverr-taiga-deploy.md

@@ -1,41 +1,28 @@
 # FlareSolverr на Тайге + обход блокировок индексеров — план/отчёт
 
-> **Статус 2026-09-29: инфраструктура готова, поиск через CF-индексеры НЕ работает.**
-> FlareSolverr развёрнут, все 6 индексеров настроены. `IndexerStatus` снят через SQL
-> (2026-09-29) → все 6 `caps` → **200**, `health` `[]`, `indexerstatus` `[]`.
-> 🔴 **Но реальный поиск:** `total=79`, отдали только **NoNaMe (47) + RuTor (32)**
-> (раньше был замер 256 — см. историю). RuTracker/Kinozal/Kinozal(M) возвращаются
-> в карантин через минуты, лог: `Empty cookies returned by FlareSolverr`.
-> **Корень: нет куки `bb_data` → логин RuTracker не выполняется.** Нужен Alex (см. Остаток п.6).
-> 🔴 **«Как на Кра́кене» — НЕ рецепт:** на живом Кра́кене капча-солвера **нет**, карантин
-> **идентичен** (`EscalationLevel=9`, 2026-09-27). Обе площадки красные одинаково (Остаток п.7).
-> 🔴🔴 **РЕШЕНИЕ (2026-09-29): свой образ `flaresolverr-vnc` + noVNC — развёрнут и работает.**
-> Капча-солвер официально non-functional, cookie в Prowlarr не вписать → единственный путь:
-> **ручной вход в Chrome внутри FS**. Собран образ (Xvfb+fluxbox+x11vnc+noVNC), профиль
-> Chromium на persistent volume, noVNC на порту **6080**. Осталось: вход Alex → проверка
-> выживания cookies → уведомление в ТГ (Остаток п.2–4).
-> 🔴 **ДОСТУП К noVNC РЕШЁН (2026-09-29): роут в Caddy работает.**
-> `https://vnc.mallexxx.duckdns.org/vnc.html` → логин **`admin`**, пароль **`vnc-taiga`**.
-> TLS выпущен (Let's Encrypt), роут **проверен → 200**. Порт `6080` наружу НЕ проброшен
-> и не нужен — идём через Caddy (`docker network connect media_net caddy`).
-> Альтернатива: SSH-туннель `ssh -L 6080:truenas_admin@mallexxx.duckdns.org:6080 -N truenas_admin@mallexxx.duckdns.org`
-> → `http://localhost:6080/vnc.html`.
-> 🔴 Питфолл: не копировать чужой bcrypt-хэш в `basic_auth` (даёт 401) — генерировать
-> `caddy hash-password`. Питфолл: Chrome в `:99` **не запущен** между запросами FS →
-> чёрный экран в noVNC, запускать вручную через `docker exec -d`.
-> Бэкап Caddyfile: `~truenas_admin/Caddyfile.bak-20260928-novnc`.
-> Детали — [[personal/tech/flaresolverr-taiga]].
-> Полный разбор, все питфоллы и команды — [[personal/tech/flaresolverr-taiga]].
+> ✅ **СТАТУС 2026-09-29: ЗАДАЧА ЗАКРЫТА.** Prowlarr логинится на RuTracker автоматически,
+> поиск отдаёт CF-индексеры. Приёмка: `search?query=radiohead&indexerIds=1` → **50 результатов**.
+> `IndexerStatus` → `[]`, `health` → `[]`, 6/6 индексеров enabled.
+> 🔴 **Истинная причина «не логинится»:** в Prowlarr хранится пара `mallexxx` /
+> `m@n*w$uperP@$$w0rD`, а все диагностические тесты шли **другим аккаунтом** (`keropjan_88`).
+> Капча RuTracker — **симптом неверного пароля**, а не блокер: с верной парой логин проходит
+> автоматически и без капчи. Кука авторизации — **`bb_session`** (не `bb_data`).
+> 🔴 **Откат:** эксперимент с образом `flaresolverr-vnc` + noVNC (порт 6080, роут
+> `vnc.mallexxx.duckdns.org`, Caddy в `media_net`) **снесён как ненужный** — гипотеза
+> «капчу решает человек» оказалась ложной. FS вернулся на штатный образ.
+> ⚠️ Открыто: **RuTor** — нет результатов в категориях фильмов/сериалов (дефект трекера, не блок).
+> Полный разбор, питфоллы и команды — [[personal/tech/flaresolverr-taiga]].
 > Связано: [[personal/plans/lidarr-taiga-and-indexer-unblock]],
 > [[family/projects/media-toolbox-taiga]], [[family/how-to/arr-stack-kraken]],
-> [[personal/tech/prowlarr-flaresolverr-cloudflare]].
+> [[personal/tech/prowlarr-flaresolverr-cloudflare]], [[family/plans/lidarr-taiga-deploy]].
 >
 > 🔴 **Главный питфолл:** FS-сессия `prowlarr`, созданная ДО появления `PROXY_URL`,
 > навсегда остаётся без прокси → `ERR_NAME_NOT_RESOLVED` → Prowlarr пишет ложное
-> «blocked by CloudFlare» (симптом маскируется под таймаут CF). Лечится
-> `sessions.destroy` + `session:"prowlarr"`; пересоздаётся сама.
-> 🔴 **Второй питфолл:** `POST /indexer/test` карантин **НЕ снимает, а продлевает** —
-> каждая «попытка починить тестом» удлиняла `DisabledTill`. Карантин живёт в `IndexerStatus`.
+> «blocked by CloudFlare». Лечится `sessions.destroy` сессии `prowlarr` — пересоздаётся сама.
+> 🔴 **Второй питфолл:** `POST /indexer/test` карантин **НЕ снимает, а продлевает**.
+> Карантин живёт в таблице `IndexerStatus` и снимается **только SQL** (`DELETE FROM IndexerStatus`).
+> 🔴 **Порядок диагностики «Auth Failed»:** сначала сверить пару логин/пароль из
+> `prowlarr.db` (`SELECT Settings FROM Indexers WHERE Id=1`), и только потом всё остальное.
 
 ## ФАКТИЧЕСКОЕ СОСТОЯНИЕ (2026-09-28, после деплоя)
 
@@ -387,21 +374,33 @@ for I in 1 5 6; do curl -s -o /dev/null -w "idx$I=%{http_code}\n" \
   API → `{"status":"ok","version":"3.5.2"}`, `http://localhost:6080/vnc.html` → **200**.
 - Бэкап: `/mnt/RED_2TB/docker/arr/docker-compose.yml.bak-20260928-profvol` (2723 B).
 
-**Осталось:**
-2. ⏳ **Alex вошёл в noVNC и видит Chrome** ✅ (2026-09-29). Дальше: логин `rutracker.org` +
-   капча → проверить, что cookies (`bb_data`) легли в `/config/chromium-profile/chromium`
-   и **переживают `docker restart flaresolverr`**.
-3. ⏳ `hermes-taiga`: уведомление в ТГ при `Empty cookies returned` со ссылкой на noVNC.
-4. ⏳ Приёмка: `GET /api/v1/search?query=X` с `group_by(.indexer)` — CF-индексеры в выдаче.
+## 🔴 ОТКАТ: эксперимент `flaresolverr-vnc` снесён (2026-09-29)
 
-✅ **Доступ к noVNC решён:** `https://vnc.mallexxx.duckdns.org/vnc.html` (`admin` / `vnc-taiga`),
-роут Caddy + TLS, проверено → **200**. Порт `6080` наружу не нужен.
-🔴 **Питфолл (чёрный экран):** FS убивает Chrome между запросами → в `:99` пусто.
-Запускать вручную: `docker exec -d -e DISPLAY=:99 flaresolverr sh -c "chromium --no-sandbox
---disable-gpu --user-data-dir=/config/chromium-profile/chromium rutracker.org"`.
-🔴 **Питфолл (401):** не копировать чужой bcrypt-хэш в `basic_auth` — генерировать
-`docker exec caddy caddy hash-password --plaintext "<пароль>"`.
+Раздел ниже — **история неудачного эксперимента**, оставлен чтобы не повторять.
+Итог: **гипотеза «капчу решает человек» была ложной** → всё построенное снесено.
+
+**Что было построено и что с ним стало:**
+
+| Артефакт | Статус |
+|---|---|
+| Образ `flaresolverr-vnc:latest` (Xvfb+fluxbox+x11vnc+noVNC) | ❌ снесён, FS вернулся на `ghcr.io/flaresolverr/flaresolverr:latest` |
+| Порт `6080:6080` в compose | ❌ убран |
+| Volume `/mnt/RED_2TB/docker/arr/flaresolverr-config:/config` | ❌ убран |
+| Каталог сборки `/mnt/RED_2TB/docker/arr/fs-vnc/` | ❌ удалён |
+| Роут `vnc.mallexxx.duckdns.org` в Caddyfile | ❌ убран, config валиден, reload сделан |
+| `docker network connect media_net caddy` | ❌ откачен (`network disconnect`), Caddy снова в `caddy_default` + `transmission_default` |
+
+**Почему это было лишним:** Prowlarr логинится на RuTracker **сам**, без VNC и без человека.
+Капча в ответе трекера была **реакцией на неверный пароль** (тесты шли аккаунтом `keropjan_88`
+вместо хранящегося в Prowlarr `mallexxx`), а не требованием трекера к живому человеку.
+
+⚠️ **Правильный порядок при «Auth Failed» — начинать с данных, а не со сборки инфраструктуры:**
+```bash
+DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db
+sqlite3 "file:$DB?mode=ro" "SELECT Settings FROM Indexers WHERE Id=1;"
+# сверить username/password с тем, чем тестируешь — ЭТО ПЕРВЫЙ ШАГ
+```
 
 ⚠️ **Уточнение методики:** Alex работает по схеме **коммит → правка → заливка → проверка Alex**.
-Промежуточный шаг «проверить, что cookies переживают рестарт» **требует его ручного входа** —
-до этого приёмка не может быть закрыта. Не отчитываться «готово» до его проверки.
+Но это не значит, что под каждую гипотезу нужно строить инфраструктуру: сначала проверять
+исходные данные (пара логин/пароль в БД), и только потом — строить.