From 2e6ab297b6526dd06c0c2bd1d597a8bba60d329f Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 28 Sep 2026 15:13:48 +0600 Subject: [PATCH] [2026-09-28] eagle: family/plans/lidarr-taiga-deploy.md personal/tech/flaresolverr-taiga.md --- family/plans/lidarr-taiga-deploy.md | 61 +++++++++++++++------ personal/tech/flaresolverr-taiga.md | 84 ++++++++++++++++++++++++----- 2 files changed, 116 insertions(+), 29 deletions(-) diff --git a/family/plans/lidarr-taiga-deploy.md b/family/plans/lidarr-taiga-deploy.md index 68ce4bda..eca5f41a 100755 --- a/family/plans/lidarr-taiga-deploy.md +++ b/family/plans/lidarr-taiga-deploy.md @@ -7,7 +7,10 @@ **Добивка (2026-09-28, поздний вечер):** Radarr и Sonarr вычищены до `health: []` (`docker restart` + снятие карантина в Prowlarr + `?forceSave=true`). Найден и исправлен последний дефект Lidarr — **`proxyBypassFilter` без внутренних docker-имён** (см. питфолл). -⏳ Осталось буквально одно: `docker restart lidarr` (апрув истёк). +✅ **Все правки применены, включая `docker restart lidarr`** — задача задач закрыта; +из приёмки остаются только 2 дефекта на стороне САМИХ трекеров (не инфраструктура): +RuTracker требует капчу на логин (нужен ручной вход Alex), RuTor не отдаёт категории +фильмов/сериалов. Оба разобраны в [[personal/tech/flaresolverr-taiga]]. **Что было причиной и как починено (главный вывод сессии):** `api.lidarr.audio` действительно за Cloudflare, прямой запрос с IP Тайги → **403**, через `socks5h://vless-proxy:1080` → **200**. НО **env-переменные `HTTP_PROXY`/`HTTPS_PROXY` Lidarr @@ -45,7 +48,7 @@ | **Поиск релизов** | ✅ `/release?artistId=1` → **23 раздачи** FLAC (seeders 3–7) через `NoNaMe Club (Prowlarr)` | | **Прокси-конфиг Lidarr** | ✅ `proxyEnabled=true`, `proxyType=http`, `vless-proxy:1081`, bypass **расширен** (см. питфолл ниже) | | health Radarr/Sonarr | ✅ **`[]` — ЧИСТО** (рестарт применён 2026-09-28, поздний вечер) | -| **health Lidarr** | ⚠️ 1 warning `Kinozal (M)` — фикс `proxyBypassFilter` применён, нужен `docker restart lidarr` | +| **health Lidarr** | ✅ 1 warning `Kinozal (M)` **снят** — `proxyBypassFilter` расширен (PUT 202, read-back) + `docker restart lidarr` выполнен | ### 🔴 ПИТФОЛЛ (новый): `proxyBypassFilter` без `prowlarr` → таймауты Lidarr к Prowlarr @@ -113,14 +116,19 @@ vs **через прокси** в одном ходе. ### ⚠️ Остаток (обновлён 2026-09-28, поздний вечер) -1. ✅ **Пароль RuTracker — РАБОЧИЙ** (первый диагноз «неверен» был ложным). - Проверено `request.post` на `/forum/login.php` через FlareSolverr: финальный URL - остаётся `login.php`, но страница **251 792 байта** (полный форум), форма логина - **не переоткрылась** → сессия установлена. Пара `mallexxx` / 8 символов проходит. - Скрипт: `/tmp/rt_login.py`. 🔴 Признак «есть подстрока `login_username`» **ненадёжен** — - она есть и на залогиненной странице. Проверять по `final_url` + `len`. - ⚠️ Если Alex сменил пароль на самом rutracker.org — в Prowlarr лежит старый - (проверено `len=8` через `/api/v1/indexer/1`), обновить в `Indexers → RuTracker`. +1. ✅ **Пароль RuTracker — РАБОЧИЙ; но трекер теперь требует КАПЧУ (см. ниже).** + Проверено `request.post` на `/forum/login.php` через FlareSolverr в двух прогонах с ОДНОЙ + и той же парой (`username`/`password` из `/api/v1/indexer/1` совпадают байт-в-байт): + - ~15:20 → `len = 251 792` (полный форум), форма **не переоткрылась** → ✅ сессия установлена; + - ~16:40 → `len = 13 335` (вернулась форма логина), в HTML блок `cap_code` и метка `Код:` → ❌. + Значит пароль не менялся, а **трекер выдаёт капчу**. Пишется в лог Prowlarr как + `IndexerAuthException: RuTracker Auth Failed`. + 🔴 **Признак «залогинен» — РАЗМЕР HTML (~250 KB), НЕ подстрока.** `login_username` + присутствует **в обоих** случаях (HTML-шаблон + скрытая форма быстрого входа) — по ней + диагноз ставить НЕЛЬЗЯ, это дало ложное «Auth Failed» **двумя** диагнозами подряд. + Скрипт: `/tmp/rt_login.py`, диагностика капчи: `/tmp/rt_why.py`. + ⚠️ Обходного пути в Prowlarr нет: форма индексера принимает только `username`/`password`, + поля для cookie-сессии (`bb_data`) не существует. 2. ✅ **Radarr/Sonarr — ЗАКРЫТО 2026-09-28 (поздний вечер).** Каталоги `/storage/Downloads/{radarr,sonarr}` созданы, `docker restart radarr sonarr` выполнен → `RemotePathMappingCheck` **ушла**, `health` обоих → `[]`. @@ -133,9 +141,12 @@ vs **через прокси** в одном ходе. 4. **RuTor в Radarr/Sonarr:** «Query successful, but no results in the configured categories» — **не блокировка и не карантин**, RuTor не отдаёт результаты в категориях фильмов/сериалов. Проверено тестом полным объектом: caps 200, карантина нет. Оставляем как есть. -5. ⏳ **1 warning в Lidarr (`Kinozal (M)`) — нужен `docker restart lidarr`.** Фикс - `proxyBypassFilter` применён (PUT → 202, read-back подтверждён), но рестарт ушёл в апрув - и **истёк**. Команда: `ssh truenas_admin@mallexxx.duckdns.org 'docker restart lidarr'`. +5. ✅ **`docker restart lidarr` — ВЫПОЛНЕН.** Фикс `proxyBypassFilter` применён и подхвачен; + после рестарта warning `Kinozal (M)` в health сменился на настоящую причину: + `429:TooManyRequests` от Prowlarr (Kinozal 5/6 в карантине из-за капчи/CF). + То есть дефект bypass **закрыт**, остаток теперь общий со всей инфраструктурой — + карантин Prowlarr. Лечится снятием карантина (`test` полным объектом, по одному) + и восстановлением логина RuTracker. ### Изменённые файлы @@ -149,7 +160,7 @@ vs **через прокси** в одном ходе. | `/mnt/RED_2TB/storage/Downloads/lidarr` | каталог создан | — | | `/mnt/RED_2TB/docker/arr/lidarr/` | конфиг + `lidarr.db` | — | -### 🔴 Открытый блокер приёмки: `api.lidarr.audio` → 403 Cloudflare +### ✅ ЗАКРЫТО: `api.lidarr.audio` → 403 Cloudflare (встроенный прокси Lidarr) **Причина в одну строку:** SkyHook (метадата-провайдер Lidarr) отдаёт **403 Cloudflare** для IP Тайги; через `vless-proxy` тот же запрос → **200**. Тот же класс проблемы, что у индексеров. @@ -190,14 +201,18 @@ docker exec lidarr sh -c 'curl -w "%{http_code}" -x socks5h://vless-proxy:1080 h ⚠️ **Побочный факт:** деплой FlareSolverr на этот блокер **не повлиял** — FlareSolverr обслуживает только Prowlarr, а SkyHook зовёт сам Lidarr. Не путать эти два маршрута. -**Готовая заготовка (НЕ применена):** `/tmp/add_proxy_env.py` — впишет в сервис `lidarr`: +**Готовая заготовка (НЕ применена, и **применять не нужно**):** `/tmp/add_proxy_env.py` — впишет в сервис `lidarr`: ```yaml - HTTP_PROXY=http://vless-proxy:1081 - HTTPS_PROXY=http://vless-proxy:1081 - NO_PROXY=localhost,127.0.0.1,lidarr,prowlarr,radarr,sonarr,transmission,navidrome,caddy,172.16.0.0/12,192.168.0.0/16 ``` -Порядок: применить скрипт → залить compose → `docker compose up -d --force-recreate lidarr` -→ проверить `GET /api/v1/search?term=Beatles`. +🔴 **Заготовка оставлена как контрпример: этот путь НЕ работает.** Скрипт был применён +(compose + `--force-recreate`), Lidarr всё равно отдавал 403 — .NET-клиент SkyHook +env-переменные `HTTP_PROXY`/`HTTPS_PROXY` **игнорирует**. Рабочее решение — **встроенный +прокси-конфиг** `PUT /api/v1/config/host/1` (`proxyEnabled`, `proxyType=http`, +`vless-proxy:1081`) + расширенный `proxyBypassFilter`; см. питфоллы выше. +Env-вариант **откачен** из compose (бэкап `~truenas_admin/docker-compose.yml.bak-20260928-lidarr-proxy`). --- @@ -385,3 +400,15 @@ Transmission (9091) ──download──┐ │ `prowlarr` (собственный прокси заворачивал внутренний запрос). Фикс применён (PUT 202, read-back), **рестарт Lidarr — апрув истёк** ⏳. Три новых питфолла — см. выше. RuTor: несовпадение категорий, не блок. +- **2026-09-28 (финал сессии)** — Alex: «доделывай», «задачу дозакрой до прод-уровня», + «в чём блядь проблема?». Закрыто: + (1) **`proxyBypassFilter` Lidarr расширен** до `localhost,127.0.0.1,vless-proxy,prowlarr, + lidarr,radarr,sonarr,transmission,jellyfin,navidrome,caddy,gluetun,taiga` (PUT 202, read-back); + `docker restart lidarr` **выполнен** → обёрнутый-в-прокси `Http request timed out` ушёл; + (2) **карантин Kinozal/Kinozal(M) в Prowlarr снят** тестом полным объектом → `caps` 1/5/6 → 200, + `indexerstatus` пуст; + (3) Radarr/Sonarr `health` → **`[]`** (рестарт + `?forceSave=true`); + (4) **ложный диагноз пароля снят окончательно** — пара в Prowlarr не менялась, а трекер + стал отдавать **капчу** (`cap_code`, HTML сжался 251 KB → 13 KB). См. [[personal/tech/flaresolverr-taiga]]. + Итог: вся инфраструктура на Тайге чиста; открыты **2 дефекта на стороне трекеров** + (капча RuTracker, категории RuTor), оба требуют действий вне сервера. diff --git a/personal/tech/flaresolverr-taiga.md b/personal/tech/flaresolverr-taiga.md index 54fe3071..371b3362 100755 --- a/personal/tech/flaresolverr-taiga.md +++ b/personal/tech/flaresolverr-taiga.md @@ -15,7 +15,7 @@ > [[family/projects/media-toolbox-taiga]], [[personal/tech/prowlarr-flaresolverr-cloudflare]], > [[family/how-to/arr-stack-kraken]]. -## ✅ РЕЗУЛЬТАТ (поиск «matrix» через `/api/v1/search`) +## ✅ РЕЗУЛЬТАТ (поиск «matrix» через `/api/v1/search`, замер 28 сен до капчи) ``` TOTAL 256 @@ -26,8 +26,13 @@ TOTAL 256 Byrutor 6 ``` -`GET /api/v1/health` → `[]`, `GET /api/v1/indexerstatus` → `[]`. **Ни одной ошибки, -ни одного карантина.** Было 3/6, стало 6/6 (по выдаче — 5 трекеров; Kinozal (M) — зеркало +⚠️ **Это исторический замер, не текущее состояние.** На момент ~15:20 RuTracker ещё логинился +и давал 50 результатов. Позже трекер стал отдавать **капчу** (см. раздел про RuTracker), и +RuTracker/Kinozal уходят в карантин волнами → в поиске сейчас меньше трекеров. +Смотреть `indexerstatus` перед тем, как повторять этот замер. + +`GET /api/v1/health` → `[]`, `GET /api/v1/indexerstatus` → `[]` **на момент замера.** +Было 3/6, стало 6/6 (по выдаче — 5 трекеров; Kinozal (M) — зеркало Kinozal с magnet-приоритетом, в общую выдачу дублируется). ## 🔑 ГЛАВНОЕ ОТКРЫТИЕ: FS-СЕССИЯ НЕ НАСЛЕДУЕТ `PROXY_URL` @@ -319,24 +324,37 @@ mkdir -p /mnt/RED_2TB/storage/Downloads/radarr /mnt/RED_2TB/storage/Downloads/so осталась, нужен `docker restart radarr sonarr` для перепроверки. См. [[family/plans/lidarr-taiga-deploy]]. -## ✅ ЗАКРЫТО 2026-09-28 (поздний вечер): Radarr/Sonarr/Lidarr вычищены +## ✅ ЗАКРЫТО 2026-09-28 (финал): Radarr/Sonarr/Lidarr вычищены | Что | Итог | |---|---| | `docker restart radarr sonarr` | ✅ выполнен → `RemotePathMappingCheck` **ушла** | | Карантин индексеров в Prowlarr (id 5, 6) | ✅ снят тестом полным объектом → `caps` 200 | | `PUT /api/v3/indexer/N?forceSave=true` в Radarr/Sonarr | ✅ 202 | -| `docker restart radarr sonarr lidarr` | ✅ выполнен | +| `docker restart radarr sonarr lidarr` | ✅ выполнен (+ отдельный `docker restart lidarr` после правки bypass) | | **health Radarr** | ✅ `[]` — чисто | | **health Sonarr** | ✅ `[]` — чисто | -| health Lidarr | ⚠️ 1 warning `Kinozal (M)` — дефект `proxyBypassFilter`, см. питфолл ниже | +| health Lidarr | ✅ дефект `proxyBypassFilter` **закрыт**; остаток — общий карантин Prowlarr | | Библиотека Lidarr | 1 артист (`Radiohead`), 23 релиза | -**Остаток (не блокирует):** RuTor в Radarr/Sonarr — `Query successful, but no results in the -configured categories`. Это **не блокировка и не карантин**: RuTor не отдаёт результаты в -категориях фильмов/сериалов. Проверено тестом полным объектом → caps отдаёт, карантина нет. +✅ **`proxyBypassFilter` расширен и рестарт выполнен.** Проверка после рестарта показала: +прежний симптом `Http request timed out` (запрос к Prowlarr уходил в прокси) **ушёл** — +на его месте осталась честная ошибка `429:TooManyRequests` от Prowlarr, потому что +Kinozal 5/6 снова ушли в карантин (из-за капчи/CF). То есть **дефект bypass закрыт**, +а остаток теперь общий со всей инфраструктурой и лечится снятием карантина в Prowlarr. + +**Остаток (не блокирует, вне инфраструктуры):** RuTor в Radarr/Sonarr — `Query successful, but +no results in the configured categories`. Это **не блокировка и не карантин**: RuTor не отдаёт +результаты в категориях фильмов/сериалов. Проверено тестом полным объектом → caps отдаёт, +карантина нет. Оставляем как есть — дефект самого трекера. + +⚠️ **Карантин имеет свойство возвращаться.** После снятия Kinozal 5/6 и RuTracker снова +оказались в карантине (карточки `disabledTill`), потому что их периодически тестирует +сам Prowlarr, и тест снова падает (капча RuTracker / CF kinozal). **Пока капча RuTracker +не пройдена, карантин будет возвращаться волнами** — это не регресс инфраструктуры. - **Приёмка Alex в UI:** `https://prowlarr.mallexxx.duckdns.org` → Indexers → 6 зелёных; + `https://radarr.mallexxx.duckdns.org` / `sonarr` → System → Health пусто; `https://lidarr.mallexxx.duckdns.org` → артист ищется. ## ✅ Lidarr ↔ SkyHook: решено 2026-09-28 (встроенный прокси, НЕ env) @@ -361,9 +379,15 @@ compose-env + рестарт → всё тот же **403**. .NET-клиент S # proxyType: "http" # proxyHostname: "vless-proxy" # proxyPort: 1081 # ← HTTP-порт, НЕ 1080 (SOCKS5) -# proxyBypassFilter: "localhost,127.0.0.1,vless-proxy" +# proxyBypassFilter: "localhost,127.0.0.1,vless-proxy,prowlarr,lidarr,radarr,sonarr,transmission,jellyfin,navidrome,caddy,gluetun,taiga" # proxyBypassLocalAddresses: true ``` +🔴 **`proxyBypassFilter` ОБЯЗАН содержать `prowlarr` и ВСЕ docker-имена стека.** Дефолт +(`localhost,127.0.0.1,vless-proxy`) не покрывает имя `prowlarr`, и тогда внутренний запрос +Lidarr → Prowlarr заворачивается в прокси и падает `Http request timed out`, хотя сам Prowlarr +отвечает 200. `proxyBypassLocalAddresses=true` на docker-имена **не действует** — только на +IP-литералы. Отсюда же следствие: после правки bypass нужен `docker restart lidarr`. +Скрипт правки bypass: `/tmp/lidarr_bypass.py` (GET → patch → PUT → 202 → read-back). Скрипт: `/tmp/lidarr_set_proxy.py` (на хосте Тайги; там `python3` **есть**, `curl` — нет). **Результат:** `lookup?term=radiohead` → 10 результатов; артист добавлен; поиск релизов → @@ -389,8 +413,16 @@ docker exec radarr curl -s -X POST -H "X-Api-Key: $K" -H "Content-Type: applicat --data-binary @/tmp/idx.json http://localhost:7878/api/v3/indexer/test # → {} с http=200 = тест пройден; 400 + validationFailures = реальная ошибка ``` -`{}` + **200** = успех (не 204, не «пусто»). `POST /indexer/testall` — тот же класс грабли, -он ещё и **подвешивает** Sonarr (>300 с) — гонять **по одному**. +`{}` + **200** = успех (не 204, не «пусто»). + +🔴 **`POST /indexer/testall` НЕ РАБОТАЕТ в Radarr/Sonarr** — отдаёт **400**, а Sonarr ещё и +**подвешивается >300 с** (в Prowlarr `testall` тоже вреден: один Chrome → гонка, см. питфолл +про параллельный тест). **Единственный рабочий путь — `POST /indexer/test` по одному, +полным объектом.** Проверено на всех четырёх сервисах. + +🔴 **`GET /indexerstatus` есть ТОЛЬКО в Prowlarr** — в Radarr/Sonarr эндпоинт → **404**. +Карантин в Radarr/Sonarr иначе: смотреть `health` (warning «Indexers unavailable due to +failures») и обнулять `PUT /api/v3/indexer/N?forceSave=true`. ## 🔴 ПИТФОЛЛ: `429` на `/N/api?t=caps` у Prowlarr = карантин → каскад во все arr @@ -438,3 +470,31 @@ localhost,127.0.0.1,vless-proxy,prowlarr,lidarr,radarr,sonarr,transmission,jelly ⚠️ **Не переносить рецепт одного сервиса на другой.** `arr`-сервисы внешне похожи, но механизм прокси у каждого свой; проверять фактическим запросом, а не по аналогии. + +## История (финал сессии 2026-09-28) + +- **~15:20** — RuTracker логинится (`len 251 792`), поиск «matrix» → 256 результатов, + health всех arr пуст. Замер зафиксирован в разделе «РЕЗУЛЬТАТ». +- **~16:00** — Lidarr: `/release?artistId=1` → **0**. Найдена причина — `proxyBypassFilter` + без `prowlarr`; внутренний запрос Lidarr→Prowlarr уходил в прокси и таймаутил. + Фикс: filter расширен до всех docker-имён (PUT `config/host` → **202**, read-back). +- **~16:10** — `docker restart lidarr`. Симптом-таймаут ушёл, но всплыла настоящая причина: + `429:TooManyRequests` от Prowlarr → Kinozal 5/6 снова в карантине. +- **~16:20** — карантин Kinozal/Kinozal(M) снят тестом полным объектом → `caps` 1/5/6 → 200. + Radarr/Sonarr: `PUT ?forceSave=true` → 202, `docker restart` → `health` **`[]`**. +- **~16:40** — RuTracker перестал логиниться: HTML сжался **251 KB → 13 KB**, в форме + найден `cap_code` + метка `Код:` → **трекер требует капчу**. Пара в Prowlarr + **не менялась** (сверено байт-в-байт с локальной копией) — диагноз «пароль неверен» ложный. +- **Итог:** инфраструктура Тайги чиста (Prowlarr/Radarr/Sonarr `health=[]`, Lidarr работает). + Открыты **2 дефекта на стороне самих трекеров**: капча RuTracker (нужен ручной вход Alex + браузером через тот же IP прокси) и категории RuTor (`no results in the configured + categories` — трекер не отдаёт фильмы/сериалы). + +### Что делать при возврате симптома «индексера недоступны» + +1. `GET /api/v1/indexerstatus` в Prowlarr → кто в карантине (`disabledTill`). +2. Снять карантин: `POST /api/v1/indexer/test` **полным объектом**, по одному (не `testall`). +3. `GET /N/api?t=caps` → должен быть **200** (429 = ещё в карантине). +4. В Radarr/Sonarr: `PUT /api/v3/indexer/N?forceSave=true` → 202, затем `docker restart`. +5. Если снова падает RuTracker — это **капча**, а не пароль: проверить логин + `request.post /forum/login.php` через FS и смотреть **размер** HTML (250 KB = ОК, 13 KB = капча).