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

This commit is contained in:
Alexey Martemyanov committed 2026-09-28 19:48:25 +06:00
1 parent a2732b9fb3
commit fe5dc880a2
2 files changed
+110 -18

No files matched your search

+21 -10
View File
@@ -14,11 +14,17 @@
> **ручной вход в Chrome внутри FS**. Собран образ (Xvfb+fluxbox+x11vnc+noVNC), профиль
> Chromium на persistent volume, noVNC на порту **6080**. Осталось: вход Alex → проверка
> выживания cookies → уведомление в ТГ (Остаток п.2–4).
> 🔴 **ДОСТУП К noVNC (2026-09-29): порт 6080 наружу НЕ проброшен** (роутер недоступен).
> Два пути: **SSH-туннель** `ssh -L 6080:truenas_admin@mallexxx.duckdns.org:6080 -N truenas_admin@mallexxx.duckdns.org`
> → `http://localhost:6080/vnc.html`, либо **Caddy-роут** `vnc.mallexxx.duckdns.org`
> (блок добавлен в Caddyfile, `basic_auth`, нужен `docker network connect media_net caddy`).
> Бэкап Caddyfile: `~truenas_admin/Caddyfile.bak-20260928-novnc`. Детали — [[personal/tech/flaresolverr-taiga]].
> 🔴 **ДОСТУП К 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]].
> Связано: [[personal/plans/lidarr-taiga-and-indexer-unblock]],
> [[family/projects/media-toolbox-taiga]], [[family/how-to/arr-stack-kraken]],
@@ -382,14 +388,19 @@ for I in 1 5 6; do curl -s -o /dev/null -w "idx$I=%{http_code}\n" \
- Бэкап: `/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`**.
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-индексеры в выдаче.
⚠️ **Открытый вопрос:** проброшен ли порт `6080` наружу (duckdns + NAT). Проверяется только
браузером Alex; если закрыт — нужен ssh-туннель или маршрут через Caddy.
✅ **Доступ к 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 "<пароль>"`.
⚠️ **Уточнение методики:** Alex работает по схеме **коммит → правка → заливка → проверка Alex**.
Промежуточный шаг «проверить, что cookies переживают рестарт» **требует его ручного входа** —
+89 -8
View File
@@ -16,7 +16,12 @@
> Капча-солвер невозможен (`CAPTCHA_SOLVER` официально non-functional), cookie в Prowlarr
> не вписать → единственный путь: **ручной вход в Chrome внутри FS**. Собран образ
> `flaresolverr-vnc:latest` (Xvfb+fluxbox+x11vnc+noVNC), профиль Chromium на persistent
> volume, порт `6080` для noVNC. **Развёрнуто и работает.** См. раздел «РЕШЕНИЕ».
> volume, порт `6080` для noVNC. **Развёрнуто и работает.**
> 🔴 **ДОСТУП ОТКРЫТ (2026-09-29): `https://vnc.mallexxx.duckdns.org/vnc.html`**,
> логин `admin` / пароль `vnc-taiga`, роут в Caddy (TLS выпущен, **проверен → 200**).
> Порт `6080` наружу НЕ проброшен — доступ через Caddy, роутер не нужен.
> **Alex вошёл и видит Chrome** (проверено). Осталась его часть: логин + капча RuTracker,
> затем проверка выживания cookies. См. раздел «РЕШЕНИЕ».
> **Radarr/Sonarr/Lidarr** — health чистый; warning-и про индексе́ры живут в БД **Prowlarr**, не у них.
> **Lidarr** — SkyHook работает, `musicCategory=lidarr` применён, поиск релизов отдаёт **43** FLAC.
> ⚠️ Открыто: **RuTracker** — автоматический логин невозможен (нужен Alex, см. ниже);
@@ -456,13 +461,58 @@ noVNC: http://localhost:6080/vnc.html → 200
### Как пользоваться (процедура «ручная капча»)
1. Alex открывает `http://mallexxx.duckdns.org:6080/vnc.html` (или через ssh-туннель,
если порт не проброшен наружу через NAT — **не проверено**).
2. Внутри видит рабочий стол fluxbox и Chrome.
3. Заходит на `rutracker.org`, вводит логин/пароль, решает капчу.
4. Cookies ложатся в `/config/chromium-profile` → **переживают рестарт контейнера**.
1. Открыть `https://vnc.mallexxx.duckdns.org/vnc.html` → логин `admin`, пароль `vnc-taiga`
(роут в Caddy, **проверен 200**). Альтернатива — ssh-туннель на `6080`.
2. Внутри — рабочий стол fluxbox с Chrome (⚠️ Chrome надо **запустить**, см. питфолл ниже).
3. Зайти на `rutracker.org`, ввести логин/пароль, решить капчу.
4. Cookies лягут в `/config/chromium-profile` → **переживают рестарт контейнера**.
5. FS переиспользует профиль при следующих сессиях → автологин проходит без капчи.
### 🔴 ПИТФОЛЛ: «cannot set background» + чёрный экран в noVNC
Симптомы, увиденные Alex: подключение проходит, fluxbox ругается `cannot set background`,
меню есть, **окна нет — чёрный экран**.
**Причина.** fluxbox/Xvfb **работают штатно** — это безвредный шум (`Failed to read:
session.screen0.*`, `Missing charsets in String to FontSet conversion`). Реальная причина
пустого экрана: **FS запускает Chrome только на время запроса и убивает его.**
Между запросами в `:99` **нет ни одного окна** — смотреть нечего.
**Проверка (на хосте Тайги):**
```bash
# X-сервер жив?
docker exec flaresolverr sh -c 'ls -la /tmp/.X11-unix/'
# → srwxrwxrwx X99 ✅
# Chrome запущен?
docker exec flaresolverr sh -c 'ps aux | grep chromium | grep -v grep | wc -l'
# → 0 ← вот причина чёрного экрана
```
**Фикс — запустить Chrome вручную в том же display и оставить жить** (`-d` = detached,
иначе убьётся вместе с exec):
```bash
docker exec -d -e DISPLAY=:99 flaresolverr sh -c \
"chromium --no-sandbox --disable-gpu --disable-dev-shm-usage \
--user-data-dir=/config/chromium-profile/chromium \
--window-size=1280,900 --start-maximized rutracker.org > /tmp/chrome-manual.log 2>&1"
sleep 12
docker exec flaresolverr sh -c 'ps aux | grep chromium | grep -v grep | wc -l' # → 12
```
После этого в noVNC видно окно Chromium. **Alex подтвердил:** «ок, вижу хром».
⚠️ `--user-data-dir` указывать **точно как у FS** (`/config/chromium-profile/chromium`) —
иначе профиль раздвоится и куки осядут в другом месте.
**Сопутствующий шум (НЕ ошибки):**
```
ERROR:dbus/object_proxy.cc Failed to call method: org.freedesktop.DBus.NameHasOwner
ERROR:dbus/bus.cc Failed to connect to the bus: /run/dbus/system_bus_socket
WARNING:zygote_communication_linux.cc Failed to send GetTerminationStatus message
```
dbus/zygote ругань есть в любом контейнере без dbus — на работу Chrome в Xvfb не влияет.
Отличить «Chrome упал» от «Chrome жив» по `EXIT=124` от `timeout`: **124 = жив** (таймаут сработал).
### План (оставшиеся шаги)
| # | Шаг | Статус |
@@ -1092,19 +1142,50 @@ ssh truenas_admin@mallexxx.duckdns.org 'docker network connect media_net caddy'
```
vnc.mallexxx.duckdns.org {
basic_auth {
admin $2a$14$.1IkoISmRXHCFi1KZld2ROa7E93cVZFNO3vomCVZYruLhO1l0hB1i
admin $2a$14$tcfG4J1HSonHGX1rb3rsPeTkDWPmo7rpSbg/TAHhV3sRbWztWmqVa
}
reverse_proxy flaresolverr:6080
}
```
> 🔴 `basic_auth` **обязателен**: noVNC без пароля = открытый рабочий стол с залогиненным
> RuTracker в интернете. Хэш тот же, что у `books`/`library` (`books-admin` → логин `admin`).
> RuTracker в интернете.
>
> 🔴 **ПИТФОЛЛ: не переиспользовать чужой bcrypt-хэш.** В первой версии блока был скопирован
> хэш от `books-admin` — тот же, что у `books`/`library`. Это дало **401 даже с паролем**,
> потому что логин в паре с этим хэшем — `books-admin`, а не `admin`: `basic_auth` сверяет
> **пару (логин, пароль)**, а не хэш отдельно. Лечится генерацией своего:
> ```bash
> docker exec caddy caddy hash-password --plaintext "vnc-taiga"
> # → $2a$14$tcfG4J1HSonHGX1rb3rsPeTkDWPmo7rpSbg/TAHhV3sRbWztWmqVa
> ```
> Правильные креды: логин **`admin`**, пароль **`vnc-taiga`**.
> ⚠️ Пароль хэшируется **до** заливки Caddyfile; в `caddy reload` ошибок не будет — просто 401.
**Бэкап:** `~truenas_admin/Caddyfile.bak-20260928-novnc` (2124 B).
⚠️ `cp Caddyfile.bak-...` рядом с оригиналом → **Permission denied** (каталог root).
Копировать в `~`.
### ✅ РЕЗУЛЬТАТ: роут проверен, работает
Порядок, который дал рабочий результат:
1. `docker network connect media_net caddy` — **до** reload, иначе DNS не резолвится.
2. `scp` нового Caddyfile → `docker exec caddy caddy validate --config /etc/caddy/Caddyfile`
→ `Valid configuration`.
3. `docker exec caddy caddy reload --config /etc/caddy/Caddyfile`.
Проверка (с Mac, снаружи):
```bash
curl -s -o /dev/null -w "%{http_code}\n" --max-time 25 \
-u admin:vnc-taiga https://vnc.mallexxx.duckdns.org/vnc.html
# → 200
```
⚠️ **Первый curl может вернуть `000` (exit 35, TLS-ошибка)** — это не провал:
Caddy в этот момент ещё выпускает сертификат. Сертификат **выпустился успешно**
(`grep -i acme` → `authorization finalized`, `authz_status: valid`, `tls-alpn-01`),
`000` был из-за гонки с выпуском. **Повторить curl через 10–20 с.**
### Два способа доступа (оба без правок роутера)
| Способ | Команда / адрес | Когда |