git_admin/obsidian-vault
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Alexey Martemyanov committed 2026-09-28 16:35:39 +06:00
1 parent addd5ba445
commit f1964019f3
3 files changed
+187 -14
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

family/plans/lidarr-taiga-deploy.md
+7 -2
View File
@@ -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**, через
personal/plans/flaresolverr-taiga-deploy.md
+93 -12
View File
@@ -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).
personal/tech/flaresolverr-taiga.md
+87
View File
@@ -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 пара