[2026-09-28] eagle: personal/plans/flaresolverr-taiga-deploy.md personal/tech/flaresolverr-taiga.md

2026-09-28 17:56:49 +06:00
1 parent 8f85b41bb1
commit 14f8f6f24e
@@ -9,6 +9,11 @@
 > **Корень: нет куки `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).
 > Полный разбор, все питфоллы и команды — [[personal/tech/flaresolverr-taiga]].
 > Связано: [[personal/plans/lidarr-taiga-and-indexer-unblock]],
 > [[family/projects/media-toolbox-taiga]], [[family/how-to/arr-stack-kraken]],
@@ -346,3 +351,41 @@ for I in 1 5 6; do curl -s -o /dev/null -w "idx$I=%{http_code}\n" \
   **Обе площадки красные по одной и той же причине.** Не строить план на посылке
   «на Кра́кене работает». Детали — [[personal/tech/flaresolverr-taiga]] §«СВЕРКА С КРА́КЕНОМ»,
   [[family/how-to/arr-stack-kraken]].
+
+## 🔴 СЕССИЯ 2026-09-29 (вечер): разбор идеи Alex + свой образ `flaresolverr-vnc`
+
+**Задача Alex:** «ароматизировать процесс насколько возможно — уведомление в ТГ от hermes-taiga,
+соединение моего браузера через 3x-ui через тот же туннель, выдача и установка куки обратно».
+
+**Результат — три из четырёх идей отвергнуты фактами:**
+
+| Идея | Вердикт | Причина |
+|---|---|---|
+| Свой браузер через 3x-ui по тому же туннелю | ❌ | `vless-proxy` — **клиент** xray, не сервер. `cf_clearance` привязан к **IP + UA + TLS-fingerprint** |
+| Впихнуть куки обратно в Prowlarr | ❌ | Индексер RuTracker принимает только `username`/`password` — поля для cookie нет |
+| Капча-солвер FS (`CAPTCHA_SOLVER`) | ❌ | **Официально non-functional** (DeepWiki FS; issue #1452 закрыт без решения) |
+| Ручной вход **в Chrome внутри FS** + persistent профиль | ✅ | Единственный рабочий путь |
+
+**Сделано (шаг 1 из 3) ✅:**
+- Собран образ **`flaresolverr-vnc:latest`** — база FS + `Xvfb` + `fluxbox` + `x11vnc` + `novnc`
+  + `supervisor`, 5 процессов. Файлы: `/mnt/RED_2TB/docker/arr/fs-vnc/{Dockerfile,supervisord.conf,entrypoint-vnc.sh}`.
+- Compose: образ подменён, добавлены порт **`6080:6080`** (noVNC) и volume
+  `/mnt/RED_2TB/docker/arr/flaresolverr-config:/config` (persistent профиль Chromium).
+- Профиль вынесен через `XDG_CONFIG_HOME=/config/chromium-profile`, FS запущен с `HEADLESS=false`.
+- Проверено: `docker compose config -q` OK, сборка ~215 с, контейнер `Up`,
+  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 входит в `http://mallexxx.duckdns.org:6080/vnc.html` → рутрекер → логин+капча →
+   проверить, что cookies (`bb_data`) легли в `/config/chromium-profile` и **переживают
+   `docker restart flaresolverr`**.
+3. ⏳ `hermes-taiga`: уведомление в ТГ при `Empty cookies returned` со ссылкой на noVNC.
+4. ⏳ Приёмка: `GET /api/v1/search?query=X` с `group_by(.indexer)` — CF-индексеры в выдаче.
+
+⚠️ **Открытый вопрос:** проброшен ли порт `6080` наружу (duckdns + NAT). Проверяется только
+браузером Alex; если закрыт — нужен ssh-туннель или маршрут через Caddy.
+
+⚠️ **Уточнение методики:** Alex работает по схеме **коммит → правка → заливка → проверка Alex**.
+Промежуточный шаг «проверить, что cookies переживают рестарт» **требует его ручного входа** —
+до этого приёмка не может быть закрыта. Не отчитываться «готово» до его проверки.
@@ -12,6 +12,11 @@
 > капча-солвер на Кра́кене — **его там НЕТ**, только FlareSolverr. Карантин на Кра́кене
 > **идентичен Тайге**: RuTracker/Kinozal/Kinozal(M) `EscalationLevel=9`, `DisabledTill=2026-09-27`.
 > Обе площадки имеют один и тот же незакрытый дефект. См. раздел «СВЕРКА С КРА́КЕНОМ».
+> 🔴🔴 **РЕШЕНИЕ НАЙДЕНО (2026-09-29): свой образ `flaresolverr-vnc` + noVNC.**
+> Капча-солвер невозможен (`CAPTCHA_SOLVER` официально non-functional), cookie в Prowlarr
+> не вписать → единственный путь: **ручной вход в Chrome внутри FS**. Собран образ
+> `flaresolverr-vnc:latest` (Xvfb+fluxbox+x11vnc+noVNC), профиль Chromium на persistent
+> volume, порт `6080` для noVNC. **Развёрнуто и работает.** См. раздел «РЕШЕНИЕ».
 > **Radarr/Sonarr/Lidarr** — health чистый; warning-и про индексе́ры живут в БД **Prowlarr**, не у них.
 > **Lidarr** — SkyHook работает, `musicCategory=lidarr` применён, поиск релизов отдаёт **43** FLAC.
 > ⚠️ Открыто: **RuTracker** — автоматический логин невозможен (нужен Alex, см. ниже);
@@ -354,6 +359,138 @@ Prefetch `GET login.php` в той же сессии → POST → тоже фо

 ---

+## 🔴🔴 РЕШЕНИЕ (2026-09-29): свой образ `flaresolverr-vnc` + noVNC для ручной капчи
+
+Alex поставил задачу: **«ароматизировать процесс насколько возможно»** — уведомление в ТГ,
+вход браузером через тот же туннель, установка куки обратно. Разбор по фактам:
+
+**Что из исходной идеи не работает (проверено):**
+
+| Идея | Вердикт | Причина |
+|---|---|---|
+| Мой браузер через 3x-ui по тому же туннелю | ❌ | `vless-proxy` — **клиент**, не сервер. И `cf_clearance` привязан к **IP + User-Agent + TLS-fingerprint** — кука моего Chrome не подойдёт чужому Chrome |
+| Установка куки обратно в Prowlarr | ❌ | Индексер RuTracker принимает только `username`/`password`. Поля для cookie нет |
+| Капча-солвер (`CAPTCHA_SOLVER`) | ❌ | **Официально non-functional.** DeepWiki FS: «Currently non-functional». Issue #1452 закрыт без решения — адаптеры удалены из образа |
+| Ручной вход **внутри Chrome FS** + persistent профиль | ✅ | Единственный рабочий путь. Капчу решает человек, дальше автомат |
+
+> 🔴 **Капчу решает человек физически.** Это защита RuTracker, а не дефект конфига.
+> Задача инженерии — сжать участие Alex до **одного клика за жизнь cookie**.
+
+**Проверка 3x-ui / xray (факты):**
+```
+vless-proxy (xray-клиент):  socks :1080 + http :1081
+                            outbound VLESS → vpn.mallexxx.duckdns.org:443 (ws/tls, path /vless)
+xray-admin (3x-ui):         панель :54321, внутри слушает 2053, сеть caddy_default (172.16.1.9)
+hermes-taiga:               есть, сеть hermes_taiga_net
+```
+
+### Свой образ `flaresolverr-vnc` — собран и развёрнут ✅
+
+Compose-сервис заменён с `ghcr.io/flaresolverr/flaresolverr:latest` на локальный образ:
+
+```yaml
+  flaresolverr:
+    image: flaresolverr-vnc:latest          # ← свой образ
+    container_name: flaresolverr
+    restart: unless-stopped
+    environment:
+      - LOG_LEVEL=warning
+      - BROWSER_TIMEOUT=60000
+      - TZ=Asia/Novosibirsk
+      - PROXY_URL=socks5://vless-proxy:1080
+    ports:
+      - "8191:8191"                          # API FS
+      - "6080:6080"                          # ← noVNC
+    volumes:
+      - /mnt/RED_2TB/docker/arr/flaresolverr-config:/config   # ← persistent профиль
+    networks:
+      - media_net
+    shm_size: 1gb
+    sysctls:
+      - net.ipv6.conf.all.disable_ipv6=1
+```
+
+**Файлы образа — `/mnt/RED_2TB/docker/arr/fs-vnc/`** (собирать оттуда):
+
+| Файл | Что |
+|---|---|
+| `Dockerfile` | база `ghcr.io/flaresolverr/flaresolverr:latest` + `x11vnc novnc websockify fluxbox supervisor` |
+| `supervisord.conf` | 5 процессов: `xvfb`(:99, 1920x1080x24) → `fluxbox` → `x11vnc`(:5900) → `novnc`(:6080) → `flaresolverr` |
+| `entrypoint-vnc.sh` | `XDG_CONFIG_HOME=/config/chromium-profile`, `DISPLAY=:99`, запуск supervisord |
+
+**Сборка:** `cd /mnt/RED_2TB/docker/arr/fs-vnc && docker build -t flaresolverr-vnc:latest .` (~215 с).
+
+### 🔴 ПИТФОЛЛ: FS в headed-режиме (`HEADLESS=false`) — порт 8191 первый запрос рвёт
+
+`supervisord.conf` запускает FS с `HEADLESS=false` — иначе в noVNC нечего смотреть.
+Следствие: сразу после старта контейнера первый `curl` к `:8191` получает
+**`Connection reset by peer`**. Через ~5–10 с всё работает:
+
+```
+$ curl -s -X POST http://localhost:8191/v1 -d '{"cmd":"sessions.list"}'
+curl: (56) Recv failure: Connection reset by peer     ← сразу после старта
+# sleep 5
+{"status":"ok","sessions":[],"version":"3.5.2"}       ← ✅
+```
+Порт слушается (`netstat -tlnp` → `0.0.0.0:8191`), но Chrome в headed-режиме доводится дольше.
+**Проверять живость FS — с ретраем/паузой, не с первого запроса.**
+
+### 🔴 ПИТФОЛЛ: `sessions.destroy` несуществующей сессии → HTTP 500
+
+`{"cmd":"sessions.destroy","session":"whale-clean-test"}` на несуществующей сессии отдаёт
+**HTTP 500 InternalServerError**, а не «ok/not found». Скрипт проверки должен **не падать**
+на этом (обернуть в try) и использовать уникальное имя сессии (`whale<timestamp>`),
+иначе повторный прогон ломается на `destroy` несуществующей.
+
+### ✅ Сервис работает
+
+```
+flaresolverr Up  0.0.0.0:6080->6080/tcp, 0.0.0.0:8191->8191/tcp
+API FS:    {"status":"ok","version":"3.5.2"}
+noVNC:     http://localhost:6080/vnc.html  → 200
+профиль:   /mnt/RED_2TB/docker/arr/flaresolverr-config/chromium-profile  ← создан
+```
+
+⚠️ **Порт `8191` с Mac НЕ проброшен наружу** — `Connection refused`. Все скрипты проверки
+запускать **на хосте Тайги** (`scp` → `ssh ... python3`), не локально.
+
+### Как пользоваться (процедура «ручная капча»)
+
+1. Alex открывает `http://mallexxx.duckdns.org:6080/vnc.html` (или через ssh-туннель,
+   если порт не проброшен наружу через NAT — **не проверено**).
+2. Внутри видит рабочий стол fluxbox и Chrome.
+3. Заходит на `rutracker.org`, вводит логин/пароль, решает капчу.
+4. Cookies ложатся в `/config/chromium-profile` → **переживают рестарт контейнера**.
+5. FS переиспользует профиль при следующих сессиях → автологин проходит без капчи.
+
+### План (оставшиеся шаги)
+
+| # | Шаг | Статус |
+|---|---|---|
+| 1 | Образ `flaresolverr-vnc` + noVNC + persistent профиль | ✅ **выполнено** |
+| 2 | Проверить, что cookies переживают рестарт контейнера | ⏳ ждёт ручного входа Alex |
+| 3 | `hermes-taiga`: уведомление в ТГ при `Empty cookies returned` | ⏳ не начато |
+| 4 | Подтвердить со стороны Prowlarr: поиск отдаёт CF-индексеры | ⏳ после п.2 |
+
+**Шаг 3 (дизайн).** hermes-taiga поллит `GET /api/v1/indexerstatus` (или грепает лог Prowlarr
+на `Empty cookies returned`/`429`) → при появлении карантина шлёт в ТГ:
+«RuTracker просит капчу → открой `http://<тайга>:6080/vnc.html`». Логика простая, ничего
+в стеке не ломает.
+
+**Бэкапы этой сессии:**
+| Файл | Путь |
+|---|---|
+| compose (до правки образа) | `/mnt/RED_2TB/docker/arr/docker-compose.yml.bak-20260928-profvol` (2723 B) |
+| ПДФ предыдущих правок | `docker-compose.yml.bak-20260928-flaresolverr`, `.bak-20260928-lidarr-proxy` |
+
+> ⚠️ **Опровергнута прошлая версия про `/config`.** Ранее в этом доке записано «на Тайге
+> `/config` НЕТ» — **неверно**: volume был (анонимный, от образа), но профиль Chromium жил
+> в `~/.config/chromium` **внутри** контейнера и умирал при пересоздании. Теперь профиль
+> явно смонтирован в `/config/chromium-profile` через `XDG_CONFIG_HOME`. Не путать:
+> наличие `/config` ≠ persistent профиль.
+
+---
+
 ## 🔴🔴 СВЕРКА С КРА́КЕНОМ (2026-09-29): «как на Кра́кене» = ТОЖЕ СЛОМАНО

 Alex спросил «на кракене вроде был капча солвер для этого?». Проверено на живом Кра́кене —
@@ -890,3 +1027,35 @@ localhost,127.0.0.1,vless-proxy,prowlarr,lidarr,radarr,sonarr,transmission,jelly
   # нет bb_data → логин не прошёл → нужно вмешательство Alex (капча), инфраструктура ни при чём
   ```
 5. Если снова падает RuTracker — **не требовать пароль**, пока не проверены `bb_data` и капча.
+
+## История (продолжение, 2026-09-29 — сессия «ручная капча»)
+
+- **Постановка Alex:** «ароматизировать насколько возможно — уведомление в ТГ от hermes-taiga,
+  соединение моего браузера через 3x-ui через тот же туннель, выдача и установка куки обратно».
+- **Разбор идей — три из четырёх отвергнуты фактами** (см. таблицу в разделе «РЕШЕНИЕ»):
+  свой браузер через 3x-ui → `vless-proxy` это **клиент**, плюс `cf_clearance` привязан
+  к UA/fingerprint; установка куки в Prowlarr → полей нет; капча-солвер → **официально
+  non-functional** (DeepWiki FS + issue #1452).
+- **Исследован Кра́кен** (Alex: «на кракене вроде был капча солвер?»). Проверено на живом:
+  солвера **нет** (только FS, `requestTimeout: 60`), карантин **идентичен Тайге**
+  (`EscalationLevel=9`, `DisabledTill=2026-09-27`). Миф про «рабочий Кра́кен» развеян.
+- **Проверена инфраструктура 3x-ui/xray:** `vless-proxy` = xray-клиент (socks :1080 + http :1081,
+  VLESS → `vpn.mallexxx.duckdns.org:443` ws/tls path `/vless`); `xray-admin` = 3x-ui, панель `:54321`.
+- **Собран и развёрнут свой образ `flaresolverr-vnc:latest`** — база FS + Xvfb + fluxbox +
+  x11vnc + noVNC, под `supervisor`, 5 процессов. Профиль Chromium вынесен на persistent
+  volume через `XDG_CONFIG_HOME=/config/chromium-profile`, FS запущен с `HEADLESS=false`.
+  Файлы: `/mnt/RED_2TB/docker/arr/fs-vnc/{Dockerfile,supervisord.conf,entrypoint-vnc.sh}`.
+  Compose: образ подменён, добавлены `6080:6080` и volume
+  `/mnt/RED_2TB/docker/arr/flaresolverr-config:/config`. Бэкап
+  `docker-compose.yml.bak-20260928-profvol`.
+- **Проверено:** `docker compose config -q` → OK; сборка ~215 с; контейнер `Up`;
+  API `{"status":"ok","version":"3.5.2"}`; `http://localhost:6080/vnc.html` → **200**;
+  каталог профиля создан.
+- **Новые питфоллы:** headed-Chrome → **первый запрос к `:8191` рвёт соединение**
+  (`Connection reset by peer`), нужна пауза ~5–10 с; `sessions.destroy` несуществующей
+  сессии → **HTTP 500**.
+- **Открытый вопрос:** проброшен ли порт `6080` наружу (duckdns + NAT) — проверяется только
+  браузером Alex.
+- **Остаток:** ручной вход Alex в Chrome через noVNC → проверить, что cookies (`bb_data`)
+  легли в профиль и переживают рестарт → шаг 3 (уведомление в ТГ).
+