From f1964019f3f8c5a4ddf9580409d07abf319e0572 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 28 Sep 2026 16:35:39 +0600 Subject: [PATCH] [2026-09-28] eagle: family/plans/lidarr-taiga-deploy.md personal/plans/flaresolverr-taiga-deploy.md personal/tech/flaresolverr-taiga.md --- family/plans/lidarr-taiga-deploy.md | 9 +- personal/plans/flaresolverr-taiga-deploy.md | 105 +++++++++++++++++--- personal/tech/flaresolverr-taiga.md | 87 ++++++++++++++++ 3 files changed, 187 insertions(+), 14 deletions(-) diff --git a/family/plans/lidarr-taiga-deploy.md b/family/plans/lidarr-taiga-deploy.md index 5303eac4..c116a536 100755 --- a/family/plans/lidarr-taiga-deploy.md +++ b/family/plans/lidarr-taiga-deploy.md @@ -19,8 +19,13 @@ поиск релизов → **43** FLAC-раздачи. ⚠️ **Открыт 1 дефект, на стороне САМОГО трекера (не инфраструктура):** RuTor — `no results in the configured categories` (не отдаёт фильмы/сериалы). Не блокировка, не карантин. -⚠️ **Остаток-механика:** `docker restart radarr sonarr lidarr` — сбросить **кэш health** -со старым RuTracker (команда ждала апрува Alex, в сессии не выполнена). +⚠️ **Остаток-механика (ОБНОВЛЕНО в конце сессии):** `docker restart radarr sonarr lidarr` +**выполнен** — кэш health сбросился, Radarr/Sonarr `health` → `[]` (чисто). Но warning +про индексе́ры **вернулся** — причина не в кэше, а в таблице **`IndexerStatus`** в `prowlarr.db` +(RuTracker `EscalationLevel=9`, `DisabledTill` +24 ч). Снимается **только SQL**, и +`POST /indexer/test` карантин не снимает, а **продлевает**. План снятия (бэкап → `docker stop +prowlarr` → `DELETE FROM IndexerStatus` → `start`) — в [[personal/plans/flaresolverr-taiga-deploy]] +§«НАЙДЕНА ИСТИННАЯ ПРИЧИНА ЗАЛИПА». Разобрано в [[personal/tech/flaresolverr-taiga]]. **Что было причиной и как починено (главный вывод сессии):** `api.lidarr.audio` действительно за Cloudflare, прямой запрос с IP Тайги → **403**, через diff --git a/personal/plans/flaresolverr-taiga-deploy.md b/personal/plans/flaresolverr-taiga-deploy.md index dbbfc640..15a0803e 100755 --- a/personal/plans/flaresolverr-taiga-deploy.md +++ b/personal/plans/flaresolverr-taiga-deploy.md @@ -1,8 +1,11 @@ # FlareSolverr на Тайге + обход блокировок индексеров — план/отчёт -> **Статус: ✅ ВЫПОЛНЕНО 2026-09-28. Итог 6/6 индексеров, `health` → `[]` (пусто).** -> Поиск «matrix» → **256 результатов** (RuTor 100, RuTracker 50, NoNaMe 50, Kinozal 50, Byrutor 6). -> **RuTracker впервые `valid` за всё время стека (с 2026-05-20).** +> **Статус 2026-09-28 (конец дня): инфраструктура готова, 1 пункт открыт.** +> FlareSolverr развёрнут, все 6 индексеров настроены, поиск «matrix» → **256 результатов** +> (RuTor 100, RuTracker 50, NoNaMe 50, Kinozal 50, Byrutor 6). **RuTracker впервые `valid` +> за всё время стека (с 2026-05-20).** +> 🔴 **Открыто:** `IndexerStatus` в `prowlarr.db` — RuTracker `EscalationLevel=9` до +24 ч. +> Снимается **только SQL** (план ниже), карантин даёт warning каскадом во все четыре сервиса. > Полный разбор, все питфоллы и команды — [[personal/tech/flaresolverr-taiga]]. > Связано: [[personal/plans/lidarr-taiga-and-indexer-unblock]], > [[family/projects/media-toolbox-taiga]], [[family/how-to/arr-stack-kraken]], @@ -12,6 +15,8 @@ > навсегда остаётся без прокси → `ERR_NAME_NOT_RESOLVED` → Prowlarr пишет ложное > «blocked by CloudFlare» (симптом маскируется под таймаут CF). Лечится > `sessions.destroy` + `session:"prowlarr"`; пересоздаётся сама. +> 🔴 **Второй питфолл:** `POST /indexer/test` карантин **НЕ снимает, а продлевает** — +> каждая «попытка починить тестом» удлиняла `DisabledTill`. Карантин живёт в `IndexerStatus`. ## ФАКТИЧЕСКОЕ СОСТОЯНИЕ (2026-09-28, после деплоя) @@ -234,14 +239,90 @@ GET https://rutracker.org/forum/login.php через socks5h://vless-proxy:1080 `Downloads/{radarr,sonarr}` (Radarr/Sonarr их ждали), выявлен **неверный пароль RuTracker**. Детали — [[family/plans/lidarr-taiga-deploy]], [[personal/tech/flaresolverr-taiga]]. +## 🔴 2026-09-28 (ночь): НАЙДЕНА ИСТИННАЯ ПРИЧИНА ЗАЛИПА — таблица `IndexerStatus` + +Итог долгой петли: «снять карантин тестом → warning возвращается → тест падает заново». +Петля не сходилась, потому что **причина лежит в БД Prowlarr, а не в прокси/FlareSolverr**. + +**Пруф — прямой дамп таблицы (хост Тайги, `sqlite3` в контейнере НЕТ, на хосте ЕСТЬ):** +```bash +DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db +sqlite3 "file:$DB?mode=ro" \ + "SELECT Id, ProviderId, InitialFailure, MostRecentFailure, EscalationLevel, DisabledTill FROM IndexerStatus;" +``` + +``` +Id ProviderId InitialFailure EscalationLevel DisabledTill +1 5 Kinozal 2026-09-28 09:43:24 2 2026-09-28 10:08 +2 6 Kinozal M 2026-09-28 09:32:45 2 — +3 4 NoNaMe 2026-09-28 07:57:42 0 — +4 2 RuTor 2026-05-20 05:45:18 0 — +5 1 RuTracker 2026-09-28 09:04:28 9 2026-09-29 09:46 ← СУТКИ +6 3 Byrutor — 0 — +``` + +🔴 **RuTracker: `EscalationLevel = 9` (максимум), `DisabledTill` = +24 ч.** Prowlarr сам +выключил индексер на сутки. Пока запись держится, `caps` отдаёт **429**, Prowlarr не делает +новых попыток, фоновый health-чек Radarr/Sonarr/Lidarr бьёт по 429 → **warning каскадом во все +четыре сервиса**. Отсюда «Radarr health чист, а warning живёт» — он живёт не у Radarr. + +⚠️ **Тест индексера карантин НЕ снимает, а ПРОДЛЕВАЕТ.** Наблюдалось вживую: `DisabledTill` +`15:44` → `21:45` после одного `POST /indexer/test`. То есть каждая попытка «починить тестом» +удлиняла блокировку. **Это и была петля.** + +### ✅ РАБОЧИЙ ПЛАН СНЯТИЯ (согласован, 2 команды + бэкап) + +На Кра́кене применялся тот же приём — см. [[family/how-to/arr-stack-kraken]] +§«(3) Блокировки индексера в БД — рестарт их НЕ сбрасывает». + +**1. Бэкап через `.backup`, НЕ `cp`** (БД в WAL-режиме): +```bash +DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db +TS=$(date +%Y%m%d-%H%M%S) +sqlite3 "file:$DB?mode=ro" ".backup /home/truenas_admin/prowlarr.db.bak-$TS" +shasum -a 256 "$DB" "$OUT" # сверить, что копия снята +``` +✅ **Сделано:** `~/prowlarr.db.bak-20260928-032611` — 581 632 байт, +sha256 исходника `d792777c3545969dba57339d1b956f11aef40da91596b266839068a1a1af7845`. + +**2. Стоп → очистка → старт** (⚠️ `docker stop` требует апрува Alex — истёк дважды): +```bash +docker stop prowlarr +sqlite3 "$DB" "DELETE FROM IndexerStatus WHERE ProviderId IN (1,5,6);" +docker start prowlarr +``` + +**3. Проверка:** +```bash +PK=$(cat /home/truenas_admin/pk.txt) +curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexerstatus # → пусто +for I in 1 5 6; do curl -s -o /dev/null -w "idx$I=%{http_code}\n" \ + "http://localhost:9696/$I/api?t=caps&apikey=$PK"; done # → 200 +``` + +**Таблицы в `prowlarr.db` (для справки):** `Indexers`, `IndexerStatus`, `IndexerProxies`, +`ApplicationIndexerMapping`, `IndexerDefinitionVersions`. + +> ⚠️ **Урок:** health-эндпоинты arr-сервисов **не являются источником истины** о блокировках. +> На Кра́кене это записано отдельно: «`GET /api/v1/health` и `/api/v1/indexerstatus` НЕ показывают +> причины блокировки» — авторитет за `prowlarr.debug.txt` и таблицей `IndexerStatus`. +> На Тайге `indexerstatus` причины показывал, но **снятие через API не срабатывало** — только SQL. + ## Остаток после сессии 2026-09-28 (не блокирует Prowlarr/FlareSolverr) -1. 🔴 **Пароль RuTracker неверен** — POST-логин через FS возвращает форму логина + «неверные - данные» + капча. Нужен верный пароль от Alex. Даёт `Auth Failed` в `testall` Prowlarr. -2. **Radarr/Sonarr:** каталоги `Downloads/{radarr,sonarr}` созданы, но `RemotePathMappingCheck` - в health держится — нужен `docker restart radarr sonarr` (кэш проверки). ⏳ не выполнен. -3. Indexer-warnings в Radarr/Sonarr снимаются `POST /api/v3/indexer/testall` - (отдаёт **400** с телом-массивом по индексеру — парсить тело, не код). -4. Приёмка Alex в UI: `https://prowlarr.mallexxx.duckdns.org` → 6 зелёных; - `https://lidarr.mallexxx.duckdns.org` → поиск артиста работает. - Открытый вопрос по swap закрыт Alex (не нужен — RAM 21 GB). +1. ⏳ **Снять `IndexerStatus` через SQL** — план выше, шаг 2 ждёт апрува на `docker stop prowlarr`. + Единственный незакрытый пункт, дающий warning каскадом во все четыре сервиса. +2. ✅ **Пароль RuTracker — вопрос закрыт: пароль ВЕРНЫЙ.** Проверено `request.post` через FS: + `len=251 792`, форма логина не вернулась. Первый диагноз «пароль неверен» был ложным — + признак «форма вернулась» проверять по **`final_url` + длине HTML**, а не по подстроке + `login_username` (она есть и на залогиненной странице). Подтверждено и через сессию + `prowlarr`: логин `254 410`, поиск `254 745`, `Auth Failed` в HTML отсутствует. + `Auth Failed` в Prowlarr при живом логине = **следствие `IndexerStatus`**, а не пароля. +3. ✅ **Radarr/Sonarr:** `docker restart radarr sonarr lidarr` выполнен → `RemotePathMappingCheck` + ушла, health **пуст** у обоих. +4. ⚠️ **RuTor:** `no results in the configured categories` — не блокировка. На Кра́кене тот же + дефект, лечение известно: RuTor не фильтрует по категориям, ему нужна **`8000(Other)`**, + не `5000`. На Тайге не применено. +5. **Приёмка Alex в UI:** `https://prowlarr.mallexxx.duckdns.org` → 6 зелёных; + `https://lidarr.mallexxx.duckdns.org` → поиск артиста работает. Alex подтвердил: + **«все зеленое, логин починен»**. Открытый вопрос по swap закрыт Alex (не нужен — RAM 21 GB). diff --git a/personal/tech/flaresolverr-taiga.md b/personal/tech/flaresolverr-taiga.md index 6b6b4c32..e16b6a4a 100755 --- a/personal/tech/flaresolverr-taiga.md +++ b/personal/tech/flaresolverr-taiga.md @@ -330,6 +330,93 @@ docker exec prowlarr curl -s -o /dev/null -w "%{http_code}" "http://localhost:96 ``` Проверено: `{}` + **200** → `indexerstatus` пуст, `caps` → **200**. +## 🔴🔴 ГЛАВНЫЙ ПИТФОЛЛ ФИНАЛА: `IndexerStatus` в `prowlarr.db` — снимается ТОЛЬКО SQL + +Самая долгая петля сессии. Симптом: «снимаю карантин тестом → warning возвращается → +тест падает заново». Круг не сходился, потому что **причина не в прокси, не в FlareSolverr +и не в пароле — она в БД Prowlarr.** + +**Пруф — дамп таблицы** (`sqlite3` на хосте Тайги ЕСТЬ, в контейнере НЕТ): +```bash +DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db +sqlite3 "file:$DB?mode=ro" \ + "SELECT Id, ProviderId, InitialFailure, MostRecentFailure, EscalationLevel, DisabledTill FROM IndexerStatus;" +``` +``` +ProviderId Индексер EscalationLevel DisabledTill +5 Kinozal 2 2026-09-28 10:08 +6 Kinozal M 2 — +4 NoNaMe 0 — +2 RuTor 0 — +1 RuTracker 9 2026-09-29 09:46 ← СУТКИ +3 Byrutor 0 — +``` + +`EscalationLevel` = степень эскалации (0–9), `9` — максимум, `DisabledTill` = **+24 ч**. +Пока запись есть: `caps` отдаёт **429** → Prowlarr не пробует снова → фоновый health-чек +Radarr/Sonarr/Lidarr бьёт в 429 → **warning каскадом во все четыре сервиса**. Отсюда парадокс +«health Radarr пуст, а warning про индексе́ры живёт» — он живёт не у Radarr, а в БД Prowlarr. + +🔴 **`POST /indexer/test` карантин НЕ снимает, а ПРОДЛЕВАЕТ.** Наблюдалось вживую: +`DisabledTill` `15:44` → `21:45` после одного теста. Каждая «попытка починить тестом» +удлиняла блокировку — это и была петля. Записи эскалируют, а не сбрасываются. + +### Рабочий путь снятия (как на Кра́кене) + +```bash +# 1. БЭКАП через .backup, НЕ cp (БД в WAL-режиме) +DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db +sqlite3 "file:$DB?mode=ro" ".backup /home/truenas_admin/prowlarr.db.bak-$(date +%Y%m%d-%H%M%S)" +# 2. стоп → удалить строки карантина → старт +docker stop prowlarr +sqlite3 "$DB" "DELETE FROM IndexerStatus WHERE ProviderId IN (1,5,6);" +docker start prowlarr +# 3. проверка +curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexerstatus # → пусто +for I in 1 5 6; do curl -s -o /dev/null -w "idx$I=%{http_code}\n" \ + "http://localhost:9696/$I/api?t=caps&apikey=$PK"; done # → 200 +``` + +Таблицы: `Indexers`, `IndexerStatus`, `IndexerProxies`, `ApplicationIndexerMapping`, +`IndexerDefinitionVersions`. + +> ⚠️ **Урок об источниках истины.** health-эндпоинты arr-сервисов **не авторитет** о блокировках. +> На Кра́кене это записано прямо: «`GET /api/v1/health` и `/api/v1/indexerstatus` НЕ показывают +> причины блокировки» — смотреть `prowlarr.debug.txt` и таблицу `IndexerStatus`. На Тайге +> `indexerstatus` причину показывал, но **снятие через API не срабатывало — только SQL.** + +## 🔴 ПИТФОЛЛ: `Auth Failed` = следствие `IndexerStatus`, а НЕ неверный пароль + +Диагноз ставился трижды и дважды был неверным — фиксирую окончательно. + +Проверка логина через FS (сессия `prowlarr`): +``` +login → len=254 410 ✅ +search → len=254 745 ✅ auth_failed_in_html=False login_form=False +``` +То есть **логин живой**, а Prowlarr в это же время отдаёт `RuTracker Auth Failed`. + +**Правильный признак «залогинен или нет» — РАЗМЕР HTML, не подстрока:** + +| `len` HTML | Что это | +|---|---| +| **~250 KB** | залогиненный форум ✅ | +| **~13 KB** | форма логина вернулась ❌ | + +Подстрока `login_username` присутствует **в обоих** случаях (HTML-шаблон + скрытая форма +быстрого входа) — по ней диагноз ставить НЕЛЬЗЯ. Именно это дало ложное «пароль неверен». + +⚠️ **И капча тут ни при чём.** Наблюдалось: «холодная» (свежесозданная) FS-сессия получает +форму с `cap_code` (`len=13 338`), а уже прогретая сессия `prowlarr` — залогиненный форум +(`len=251 792`). То есть капча отдаётся **не по признаку пароля**, а свежим сессиям. +Пароль всё время был верный — Alex подтвердил отдельно. + +> ⚠️ **Порядок диагностики при `Auth Failed` (не переставлять):** +> 1. Проверить логин `request.post` на `/forum/login.php` через FS → судить по `len` (~250 KB = ок). +> 2. Посмотреть `IndexerStatus` в `prowlarr.db` — если есть строка, **это и есть причина**. +> 3. Только если п.1 показал ~13 KB — вопрос к паролю. +> **Не требовать у Alex новый пароль, не пройдя п.2.** + ## ✅ ЗАКРЫТО: пароль RuTracker — рабочий (первый диагноз был НЕВЕРЕН) **Итог 2026-09-28 (позже в тот же вечер):** сохранённая в Prowlarr пара