From ae51be4872e8d39012ae20b3af3350cce4b8dadd Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Fri, 4 Sep 2026 14:16:45 +0600 Subject: [PATCH] [2026-09-04] eagle: family/how-to/arr-stack-kraken.md family/how-to/hermes-kraken-api.md family/how-to/kraken-access.md family/how-to/kraken-network.md family/how-to/kraken-portainer-access.md family/how-to/openmediavault-rpi5.md family/how-to/router-bishkek-asus.md family/projects/watchlist-automation.md personal/tech/cloudflare-tunnel-ssh-published-route.md --- family/how-to/arr-stack-kraken.md | 48 +++++++++++++- family/how-to/hermes-kraken-api.md | 7 +- family/how-to/kraken-access.md | 66 ++++++++++++++++++- family/how-to/kraken-network.md | 40 +++++++++-- family/how-to/kraken-portainer-access.md | 2 +- family/how-to/openmediavault-rpi5.md | 20 +++++- family/how-to/router-bishkek-asus.md | 2 + family/projects/watchlist-automation.md | 15 ++++- .../cloudflare-tunnel-ssh-published-route.md | 62 +++++++++++++++++ 9 files changed, 244 insertions(+), 18 deletions(-) create mode 100644 personal/tech/cloudflare-tunnel-ssh-published-route.md diff --git a/family/how-to/arr-stack-kraken.md b/family/how-to/arr-stack-kraken.md index 2fa383cd..5349264c 100644 --- a/family/how-to/arr-stack-kraken.md +++ b/family/how-to/arr-stack-kraken.md @@ -1,7 +1,7 @@ --- title: Arr Stack — Kraken created: '2026-05-23' -updated: '2026-05-27' +updated: '2026-09-04' type: tech namespace: family tags: [arr, radarr, sonarr, prowlarr, transmission, jellyfin, infra, kraken] @@ -128,6 +128,52 @@ All services accessible at `kraken:`: - **17 фильмов в Radarr `hasFile=False`** — ждут подходящего релиза в Prowlarr. Scream (1996) в процессе загрузки. - **Prowlarr** — если долго не находит релизы, проверить статус индексеров (`/api/v1/health`). +- **🔴 2026-09-04: 4K UHD Remux при Direct Play подтормаживает на ТВ (webOS).** Симптом у `Неистовый (Unhinged 2020)` — 60.9GB `...Remux.2160p.mkv` avg ~99 Мбит/с. После фикса eth0 Kraken → 1G (был 100M, см. [[kraken-network]]) торможение **сохранилось**. Подтверждено по логу Jellyfin `log_20260904.log`: сессия 10:18→10:28 «Jellyfin for WebOS 1.2.2», Stop at 400916ms (~6:40), **ни одной строки transcode → это Direct Play**, не CPU-рендер субтитров. +- **🔴🔴 2026-09-04 (уточнение, важно): тормозит Direct Play даже лёгкого 4K → причина в клиенте webOS, НЕ в сети/диске.** Вживую при воспроизведении `Project Hail Mary (2026)` (`...2160p.iT.WEB-DL...mkv`, HEVC Main10 4K HDR10+, avg ~24.5-25.7 Мбит/с, 30.2GB, Direct Play) подёргивание **сохранилось**, хотя: транскода нет (0 ffmpeg, CPU Kraken load 0.1), сервер отдаёт всего ~21 Мбит/с, Wi-Fi ТВ чист (0 CRC / 0 retries за стрим, -53 dBm), все линки с запасом ×10+. **Значит низкоуровневая причина — программный декодер/буфер «Jellyfin for WebOS 1.2.2» при Direct Play 4K HEVC 10-bit HDR, не инфраструктура.** Вывод для стратегии качества: даже лёгкий 4K Direct Play не гарантирует плавности на этом ТВ-клиенте — вопрос не столько в remux, сколько в клиенте. Кандидаты фикса: настройки буфера/декодера клиента, DirectStream (ремукс), тянуть через HTPC/Kodi на HDMI, либо транскод аудио. **Решение НЕ принято — продолжить в след. сессии.** + +## Radarr Quality Profiles на Kraken (проверено 2026-09-04) + +Via `http://kraken:7878/radarr/api/v3/qualityprofile` (X-Api-Key из config.xml; **UrlBase=`/radarr`**). Radarr v6.1.1.10360, Linuxserver image, net `docker_default`. + +| id | Профиль | Разрешённые качества | Cutoff | +|----|---------|----------------------|--------| +| 1 | **Any** | весь диапазон CAM..BR-DISK, вкл. все 2160p | Remux-1080p | +| 2 | SD | до Bluray-576p | — | +| 3 | HD-720p | до Bluray-720p | — | +| 4 | HD-1080p | HDTV/Bluray/Remux-1080p | Bluray-1080p | +| 5 | **Ultra-HD** | HDTV/Bluray/**Remux-2160p** (BR-DISK не allowed) | **Remux-2160p** | +| 6 | HD-720p/1080p | 1080p и ниже | — | + +- **Корень «почему новые качаются в любой жир»:** `watchlist-sync` (который добавляет фильмы/сериалы из watchlist в Radarr/Sonarr) жёстко прописывает `"qualityProfileId": 1` (= профиль `Any`) в `arr.py`: + - Реальный путь репо: `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f/watchlist-sync` (НЕ `~/Developer/watchlist-sync`, хотя симлинк `~/Developer/watchlist-sync` → `.../49e8.../watchlist-sync` есть; 49e8 — симлинк на 6194). + - `watchlist_sync/arr.py` → `radarr_add()` (~стр 77) и `sonarr_add()` (~стр 112), обе `"qualityProfileId": 1`. Radarr POST `/api/v3/movie` c `addOptions.searchForMovie:true`; Sonarr POST `/api/v3/series`. +- **Как изменить «качество для новых фильмов» глобально:** сменить зашитый `qualityProfileId` в `arr.py` на другой профиль (напр. id=5 Ultra-HD), ИЛИ создать профиль «2160p без Remux» и указать его. Это правка кода репо watchlist-sync на Кракене + профили в Radarr API. ⚠️ Алекс ещё НЕ утвердил направление (4K лёгкий vs 1080p, и нужно ли для сериалов). НЕ менять без явного ok. +- ⚠️ **Решение по стратегии качества (пользователь прошлые строки уточнял) НЕ принято — продолжить в след. сессии.** Приоритет — разобраться, что делает webOS-клиент на Direct Play лёгкого 4K (см. «Известные проблемы»), т.к. если клиент виноват, смена профиля Radarr не решит подёргивание. + +### Реальный состав жирного remux (пример Unhinged, ffprobe 2026-09-04) + +Важно для понимания «что даёт remux» перед выбором профиля. Файл `Неистовый.2020.UHD.Blu-Ray.Remux.2160p.mkv` = **60.9GB, 1:31:05, контейнер 89.17 Мбит/с средний**. + +FFprobe потоки: +| idx | тип | кодек | каналы | язык / роль | +|----|-----|-------|--------|------| +| 0 | video | **HEVC Main10, 3840×2160, 24fps** | — | HDR10 (BT.2020, PQ smpte2084) | +| 1 | audio | AC3 | 5.1(side) 384k | rus «Dub, iTunes» | +| 2 | audio | **DTS-HD MA** | 7.1 | rus «Д. Есарев» | +| 3 | audio | **TrueHD** | 7.1 | eng | +| 4 | audio | AC3 | 5.1 640k | eng | +| 5 | audio | DTS | stereo 320k | eng Commentary (реж. Деррик Борте) | +| 6-8 | sub | SRT/SPU | — | rus / eng full / eng SDH | + +Вывод: размер 60GB раздувает НЕ видео (HDR10 HEVC-часть типичная), а **множество звуковых дорожек (lossless DTS-HD MA + TrueHD) + аудиокомментарий**. «Что даёт remux» на бытовом ТВ: видео-выигрыш против аккуратного 4K-рипа почти незаметен с дивана; бонус реализуется только при lossless-прокачке звука (AVR/eARC). Если ТВ играет через собственные динамики/стерео или делает audio-transcode — плюс remux теряется, а вес/сеть/лаг остаются. Это аргумент за профиль «2160p без Remux» для бытового просмотра на webOS-TB. + +### Бенчмарк WEB-4K (замерено по библиотеке Kraken, 2026-09-04) + +«Поддерживаемое качество» для сравнения с жирным remux — это кодированные 2160p. Замер файлов с `WEB`+`2160` в имени в `/media`: +- Полнометражки (2ч): `Project Hail Mary` 28.1GB, `The Drama` 19.2GB, `The Crow` 17.4GB, `They Will Kill You` 17.2GB, `Кот в сапогах` 19.9GB → **range 17–28GB, медиана ~19GB**. +- 45-50 мин эпизоды док-сериалов (`prehistoric.planet` s01): ~7.2–7.7GB каждый. +- Статсводка по всем 10 файлам: min 7.2 / median 12.5 / mean 13.9 / max 28.1 GB. Средний битрейт ~20–40 Мбит/с. +- **Практичный floor benchmark: «нормальная» копия 4K для этого ТВ ≈ 17–28GB/фильм** (в 2.5–3× меньше remux). ⚠️ Однако см. «Известные проблемы»: даже такой лёгкий 4K Direct Play у webOS-клиента может подёргиваться — дело в клиенте, а не в размере файла. ## Notes diff --git a/family/how-to/hermes-kraken-api.md b/family/how-to/hermes-kraken-api.md index b04d8efe..b73769aa 100644 --- a/family/how-to/hermes-kraken-api.md +++ b/family/how-to/hermes-kraken-api.md @@ -1,7 +1,7 @@ --- title: Hermes Kraken — OpenAI-Compatible API Server created: '2026-05-29' -updated: '2026-05-29' +updated: '2026-09-04' type: tech namespace: personal tags: [hermes, kraken, infra, agent, how-to] @@ -24,7 +24,7 @@ assistant. ``` Android (Aide) - └── HTTPS → hermes.kraken.qentra.top/v1/chat/completions + └── HTTPS → kraken.qentra.top/v1/chat/completions ↓ Cloudflare Tunnel cloudflared (Kraken, host network) ↓ localhost:8642 @@ -67,8 +67,7 @@ Tunnel name: `kraken`. Public hostname (CF Zero Trust dashboard): - **Type:** HTTP (not SSH) - **URL:** `localhost:8642` -SSH to Kraken still works via VPS reverse tunnel (port 2223) — the CF -hostname change does not affect SSH access. +`kraken.qentra.top` — HTTP-маршрут на Hermes API (8642). SSH через Cloudflare Tunnel идёт **отдельным** hostname **`ssh-kraken.qentra.top` → `ssh://localhost:22`** (рабочий с 2026-09-04; вход `ssh kraken@ssh-kraken.qentra.top`, разовый `cloudflared access login ssh-kraken.qentra.top`, см. [[kraken-access]]). Альтернативный SSH-путь — VPS reverse tunnel `91.207.28.205:2223`. ⚠️ Двухуровневый `ssh.kraken.qentra.top` НЕ работает (нет edge-TLS на 2-уровневом subdomain) — подробности/питфол в [[kraken-access]]. ## Aide Android Client Config diff --git a/family/how-to/kraken-access.md b/family/how-to/kraken-access.md index ec1c26a3..1db6e3af 100644 --- a/family/how-to/kraken-access.md +++ b/family/how-to/kraken-access.md @@ -1,6 +1,6 @@ # Kraken — Внешний доступ -> Обновлено: 2026-09-01 +> Обновлено: 2026-09-04 > Updated: 2026-09-01 23:00 — диск/докер кракена восстановились после перезагрузки. @@ -40,8 +40,67 @@ EP=3 # endpoint ID на Кракене = 3, не 1! | Имя | Заметки | |-----|---------| -| xray-reverse-bridge | развёрнут 2026-09-01 (единственный активный) | -| flaresolverr / hermes-kraken / homeassistant / jellyfin / portainer / prowlarr / radarr / rclone / sonarr / transmission / cloudflared / watchtower | образы есть, контейнеры потеряны — пересоздать при необходимости | +| xray-reverse-bridge | развёрнут 2026-09-01 | +| cloudflared | ✅ UP (2026-09-04), remote-managed по TUNNEL_TOKEN — пересоздан после сбоя | +| flaresolverr / hermes-kraken / homeassistant / jellyfin / portainer / prowlarr / radarr / rclone / sonarr / transmission / watchtower | образы есть, контейнеры потеряны — пересоздать при необходимости | + +## Cloudflared туннель — публичные маршруты (состояние на 2026-09-04) + +Туннель `kraken` в Zero Trust, remote-managed по `TUNNEL_TOKEN`, `network_mode: host`, образ `cloudflare/cloudflared:latest`. Актуальный ingress конфиг (виден в логах cloudflared на Kraken, `INF Updated to new configuration`): +``` +{"ingress":[ + {"hostname":"kraken.qentra.top", "originRequest":{"httpHostHeader":"kraken.qentra.top"},"service":"http://localhost:8642"}, ← Hermes API + {"hostname":"ssh-kraken.qentra.top", "service":"ssh://localhost:22"}, ← SSH (published application route) + {"service":"http_status:404"} ← default catch-all +]} +``` + +⚠️ **Важно (путаница была!):** `kraken.qentra.top` — это **HTTP-маршрут на `localhost:8642` (Hermes API)**, НЕ SSH. Поэтому SSH к `kraken.qentra.top:22` и не шёл. Под SSH создан отдельный hostname **`ssh-kraken.qentra.top`**. + +### ✅ SSH-доступ работает через `ssh-kraken.qentra.top` (РАБОЧИЙ, 2026-09-04) + +**Вход (проверено, работает):** +```bash +ssh kraken@ssh-kraken.qentra.top +``` + +`~/.ssh/config` блок: +``` +Host ssh-kraken.qentra.top + HostName ssh-kraken.qentra.top + User kraken + ProxyCommand cloudflared access ssh --hostname %h +``` + +Первый раз — авторизация cloudflared в Access-приложение: +```bash +cloudflared access login ssh-kraken.qentra.top +``` + +Маршрут на Kraken (UP, контейнер) подхвачен ingress `ssh-kraken.qentra.top → ssh://localhost:22`; sshd на Kraken — `0.0.0.0:22`. DNS проксировано CF (104.21.x / 172.67.x). + +### ⚠️ Питфол: почему `ssh.kraken.qentra.top` (двухуровневый) НЕ сработал + +Изначально под SSH добавлялся hostname `ssh.kraken.qentra.top` (`ssh.kraken` + `qentra.top`) → `ssh://localhost:22`, + Access Application (type SSH) + Service Token. Вход НЕ заработал. Решающий факт — на edge Cloudflare у этого hostname **НЕТ SSL/TLS-терминации**, в отличие от одиночных subdomain: +``` +openssl s_client -connect ssh.kraken.qentra.top:443 → SSL alert 40 (handshake failure), no peer certificate +curl https://ssh.kraken.qentra.top → ssl=1 handshake failure +``` +Любой `cloudflared access login/ssh` и Service Token к чистому двухуровневому SSH-hostname не помогают — клиент не доходит даже до авторизации из-за отсутствия edge-TLS. + +**Решение, которое сработало:** использовать **одиночный subdomain через дефис** — `ssh-kraken.qentra.top` (покрывается Universal SSL `*.qentra.top`). На нём размещены тот же `published application route` SSH → `ssh://localhost:22` + Access Application. Вошло сразу. + +> Почему так: Universal SSL зоны покрывает `*.qentra.top` (1 уровень) и `qentra.top`, но НЕ `*.kraken.qentra.top` (2 уровня). Для 2-уровневого нужен Advanced Certificate — проще взять одиночный subdomain. + +### Диагноз IPv4/IPv6 «жив, но шумит» (актуально для обоих hostname) + +- В логах cloudflared — часть `Registered tunnel connection ... protocol=quic`, но постоянные `ERR ... write udp [::]->198.41.x.x:7844: sendmsg: network is unreachable`. +- **Причина: на Kraken НЕТ глобального IPv6** (только `::1` и link-local `fe80::`; роутер `192.168.1.1` IPv6 не выдаёт → `ping6 2606:4700::1111` = `Network is unreachable`). cloudflared пробует QUIC и по IPv6 → каналы падают; туннель выживает по IPv4-QUIC. +- **Возможный фикс:** заставить cloudflared QUIC только по IPv4, чтобы убрать IPv6-шум. + +### SSH через VPS reverse (независимо от cloudflared) + +Остаётся рабочим внешним путём: reverse SSH туннель через VPS `91.207.28.205:2223` (см. ниже), НЕ cloudflared. ## Связанные заметки @@ -49,4 +108,5 @@ EP=3 # endpoint ID на Кракене = 3, не 1! - [[wireguard-vpn]] — полное описание WG (⚠️ VPS-звено мёртво на 2026-09-01) - [[kraken-portainer-access]] - [[openmediavault-rpi5]] +- [[tech/cloudflare-tunnel-ssh-published-route]] — генерализуемое руководство: SSH через Cloudflare Tunnel (1-уровневый subdomain + Universal SSL), питфолы diff --git a/family/how-to/kraken-network.md b/family/how-to/kraken-network.md index ab993626..9c2567bc 100644 --- a/family/how-to/kraken-network.md +++ b/family/how-to/kraken-network.md @@ -1,12 +1,17 @@ --- title: Kraken Network & Infra created: '2026-05-23' -updated: '2026-09-02' +updated: '2026-09-04' type: tech namespace: personal -tags: [infra, kraken, ssh, wireguard, network] +tags: + - infra + - kraken + - ssh + - wireguard + - network related: - - "[[tech/arr-stack-kraken]]" + - '[[tech/arr-stack-kraken]]' --- # Kraken Network & Infra @@ -29,10 +34,37 @@ SSH alias `kraken` resolves via `~/.ssh/config`. | **wlan0** (WiFi) | `192.168.1.15/24` (DHCP) | `2c:cf:67:64:03:f4` | fallback — metric 600 | - Ethernet link на boot: **1000 Mbit/s full duplex** (как и ожидалось для Gigabit-порта RPi5), carrier up. -- ⚠️ **2026-09-02 ~16:30: eth0 ПЕРЕСОГЛАСОВАЛСЯ ВНИЗ до 100 Mbit/s full** (dmesg: `Link is Down → Link is Up - 100Mbps/Full`), с тех пор стабильно висит на 100M (на момент ~19:00 всё ещё 100). Счётчики eth0 чистые (rx_errors=1 суммарно, свежих CRC нет) — не электрический шум, а downshift линка (обычно кабель/коннектор/порт роутера). **Симптом:** 4K UHD Blu-ray Remux (~99 Mbit/s) при Direct Play дёргается — 99M видео по 100M линку = ~100% занятие канала без запаса. Ожидается boot-link 1G (перепроверить / возможно требует переподключить патч). +- ⚠️ **2026-09-02 ~16:30: eth0 ПЕРЕСОГЛАСОВАЛСЯ ВНИЗ до 100 Mbit/s full** (dmesg: `Link is Down → Link is Up - 100Mbps/Full`) и стабильно висел на 100M (проверялось 2026-09-04 по SSH: speed=100). Счётчики eth0 чистые (rx_errors=1 суммарно, свежих CRC нет) — не электрический шум, а downshift линка (кабель/коннектор/порт роутера). **Симптом:** 4K UHD Blu-ray Remux (~99 Mbit/s) при Direct Play дёргался — 99M видео по 100M линку ≈ 100% занятие канала без запаса. +- ✅ **РЕШЕНО 2026-09-04: замена патч-корда вернула eth0 на 1000 Mbit/s full duplex** (проверено по SSH: speed=1000, duplex=full, carrier=up). Причина — неисправный/некачественный кабель, а не порт роутера или настройки. Carrier_changes = 5 на момент проверки. 4K Remux больше не должен дёргаться. - Router/gateway: `192.168.1.1` (`f0:79:59:77:9b:70`). eth0 MAC соответствует static lease в доке [[family/how-to/openmediavault-rpi5|openmediavault-rpi5]]. - ⚠️ Ранее эта заметка утверждала «wlan0 = .15 primary» — устарело (см. таблицу выше). +## Хранилище Kraken — USB (проверено 2026-09-04) + +Единственный диск `sda` (Toshiba **MQ01UBB200**, 1.8TB) подключён **напрямую в порт USB3/SS RPi5, НЕ через хаб** — Sysfs путь `/.../xhci-hcd.0/usb2/2-1`, speed **5000 Mbps**. lsusb -t: Dev 2 на Bus 02 (5000M). Линк USB3 настоящий (не USB2). + +**Скорость чтения диска ~95 МБ/с** (dd direct + buffered, по remux-файлу): это не USB-узкое место, а **физический предел 5400rpm 2.5" ноутбучного HDD** (максимум ~100–110 МБ/с на внешних дорожках). Для сравнения потолок USB2 ≈ 35–40 МБ/с. USB3.0 линк подтверждён (5000M). Вывод: для скорости >200 МБ/с нужен SSD/7200rpm, текущий механик упрется в ~95–110 МБ/с. + +Хабы (Super Top `1-1.2`, Huasheng «USB2.0 HUB» `1-1`) висят на **Bus 01 (USB2, 480M)** и **пустые** — к ним ничто не подключено. + +Монтирование: `/dev/sda1` (ext4, UUID `6194539b-03e0-4f33-986b-4da09834e82f`) → `/srv/dev-disk-by-uuid-6194539b-...`; старый путь `49e8f586...` — **symlink** на него. + +## Клиент — LG webOS TV (192.168.1.75 WiFi / 192.168.1.70 Ethernet) (проверено 2026-09-04) + +По SSH `root@192.168.1.75` или `root@192.168.1.70` (`~/.ssh/config` .75, id_rsa; выводит post-quantum warning — ок). Host LGwebOSTV, ядро 4.4.84 armv7 (webOS). ТВ имеет **два MAC**: WiFi `54:77:87:ce:fb:b3`, Ethernet `ac:5a:f0:25:11:c6` (этот = static lease в роутере `.75`). + +**Состояние на конец сессии 2026-09-04:** ТВ переведён на **провод** (пользователь воткнул патч-корд в роутер) → WiFi `wlan0 DOWN`, `eth0 UP`. После этого IP сменился: проводной интерфейс получил **`192.168.1.70`** (старый `.75` больше не отвечает, ping 100% loss). ⚠️ **eth0 ТВ линк = 100 Mbit/s full duplex** (carrier up, speed=100) — то есть **тот же downshift на 100M**, какой был у Kraken (см. ниже). Провод 100M **медленнее**, чем WiFi (867 PHY ≈ 400+ реальных Мбит/с) → переключение на полуживой кабель — регресс., если не поменять патч-корд ТВ↔роутер на рабочий гигабитный. + +**Сводка по линкам ТВ (до переключения на провод, WiFi .75):** +- Wi-Fi клиент был: SSID **ASUS5**, BSSID `f0:79:59:77:9b:74`, **канал 153 / 5765MHz / width 80MHz (5 GHz, 802.11ac)**, **signal -53 dBm** (отличный), **TX link rate 867.0 MBit/s PHY** (2-поток 80MHz AC — потолок карты), txpower 15 dBm. +- Реальный TCP-пропуск ≈ 50–60% PHY ≈ **400–500 Мбит/с** при таком сигнале — это в разы больше 99 Мбит/с remux'а, так что **WiFi ТВ не узкое место**. Торможение 4K сохранялось и на WiFi, и позже подтверждено на сотне-проводе. + +**Forensics торможения (проведено вживую при воспроизведении Project Hail Mary, Direct Play):** +- Транскода НЕТ: 0 ffmpeg-процессов, `/config/transcodes` пуст, CPU Kraken load ~0.1 — сервер простаивает. +- Сервер отдаёт всего ~21 Мбит/с (eth0 tx) при файле ~27 Мбит/с — сеть и диск с запасом ×10+. +- Wi-Fi ТВ-интерфейс за время стрима: **rx_crc_errors=0, tx_retries delta=0**, signal постоянно -53 dBm — радио чистое, не деградирует. +- **Вывод: все сетевые/дисковые/радио-счётчики чисты, линки имеют запас, а Direct Play НИЗКОбитрейтного (24-27 Мбит/с) 4K всё равно подёргивается** → причина в **программном декодере/буфере клиента «Jellyfin for WebOS 1.2.2»**, а не в инфраструктуре. См. [[arr-stack-kraken]] «Известные проблемы». Плюс если смотреть через провод — линк ТВ сейчас 100M (тоже слабое место для remux). + ## WireGuard Topology Split-tunnel: Eagle ↔ VPS ↔ Kraken. Full details: [[tech/wireguard-vpn]]. diff --git a/family/how-to/kraken-portainer-access.md b/family/how-to/kraken-portainer-access.md index 97f8cc96..cd480c46 100644 --- a/family/how-to/kraken-portainer-access.md +++ b/family/how-to/kraken-portainer-access.md @@ -61,7 +61,7 @@ curl -s -X DELETE -H "X-API-Key: $KEY" \ ## Cloudflared — деплой (выполняет Кракен) -CF Tunnel уже создан Alex'ом (`kraken` в Zero Trust), hostname настроен: `kraken.qentra.top → SSH → localhost:22`. +CF Tunnel уже создан Alex'ом (`kraken` в Zero Trust), ingress настроен. ⚠️ Актуальные маршруты (2026-09-04): **`kraken.qentra.top` → HTTP `localhost:8642`** (Hermes API, НЕ SSH) и отдельный **`ssh-kraken.qentra.top` → `ssh://localhost:22`** (published SSH application route; вход `ssh kraken@ssh-kraken.qentra.top`, работает с 2026-09-04). Полная картина и статус — [[kraken-access]]. **CF Tunnel Token:** ``` diff --git a/family/how-to/openmediavault-rpi5.md b/family/how-to/openmediavault-rpi5.md index d0aaa077..78cb144b 100644 --- a/family/how-to/openmediavault-rpi5.md +++ b/family/how-to/openmediavault-rpi5.md @@ -5,7 +5,7 @@ tags: - openmediavault - how-to created: '2026-05-11' -updated: '2026-07-03' +updated: '2026-09-04' status: hermes-pending ip: 192.168.1.15 --- @@ -160,7 +160,7 @@ sudo update-initramfs -u -k all < /dev/null ## Шаг 6 — USB HDD 1. Подключить HDD к синему (USB 3.0) порту Pi -2. Проверить скорость: `sudo apt install hdparm && sudo hdparm -t --direct /dev/sda` → должно быть ~200-250 MB/s +2. Проверить скорость: `sudo apt install hdparm && sudo hdparm -t --direct /dev/sda` → ориентир ~200-250 MB/s **только для быстрых дисков** (SSD / 7200rpm). См. ⚠️ ниже про 5400rpm. 3. Разметить: `sudo parted -s /dev/sda mklabel gpt mkpart primary 0% 100%` 4. Форматировать (агент не может — только вручную или через скрипт): ```bash @@ -171,6 +171,22 @@ sudo update-initramfs -u -k all < /dev/null > ⚠️ Не монтировать вручную через fstab — OMV должен управлять монтированием сам +### ⚠️ Скорость диска Toshiba 1.8TB (проверено 2026-09-04) + +**Не путать медленный HDD с USB2-линком.** Реальный замер чтения на Kraken (по SSH, смонтированная ФС, `dd` из remux-файла, 1GB × прогоны): +- direct (обход page cache): **95.3 / 95.7 MB/s** +- buffered: 92.7 MB/s +- **Итог: ~95 MB/s стабильно.** + +Диагностика «а диск не на USB2 ли?» (2026-09-04) завершилась **отрицательно**: +- USB2-потолок ≈ **35-40 MB/s** (480 Мбит/с минус накладные). 95 MB/s в 2.5× выше → линк **точно USB3**. +- sysfs топология sda: `/…/xhci-hcd.0/usb2/2-1 → sda`, `speed=5000 Mbps`, подключён **напрямую** в синий (USB3) порт Pi, **не через хаб**. +- Оба хаба на Kraken (Huasheng USB2.0 HUB + Super Top) висят на Bus 01 (**USB 2.0, 480M**) и на момент проверки **пустые** (к ним ничего не подключено) — к диску отношения не имеют. +- 95 MB/s — это **физический предел** Toshiba **MQ01UBB200: 5400 rpm 2.5"** HDD (~100-110 MB/s внешние дорожки). Упирается в механику, а не в USB. +- `hdparm` и прямой доступ к `/dev/sda` под `kraken` недоступны (sudo требует пароль, hdparm не установлен, user не в группе disk) — тест чтения шёл через смонтированную ФС. + +Для скорости >200 MB/s нужен SSD или 7200rpm; текущий 5400rpm не быстрее. Тест записи на боевом диске без явного разрешения не проводился. + ### CLI-альтернатива: регистрация диска в OMV через config.xml Если Web UI недоступен, можно зарегистрировать диск через прямой редактор config.xml и deploy: diff --git a/family/how-to/router-bishkek-asus.md b/family/how-to/router-bishkek-asus.md index 080e248a..8ec50f09 100644 --- a/family/how-to/router-bishkek-asus.md +++ b/family/how-to/router-bishkek-asus.md @@ -48,6 +48,8 @@ address=/tv/192.168.1.75 |-----|----|-----|------------| | htpc | 192.168.1.86 | — | Bazzite, статический IP, RX 570 | | tv / LGwebOSTV | 192.168.1.75 | ac:5a:f0:25:11:c6 | LG TV | + +> ⚠️ **2026-09-04:** LG TV подключён по **проводу** (вместо WiFi). Проводная часть использует Ethernet-MAC `ac:5a:f0:25:11:c6` и на конец сессии получал **`192.168.1.70`** (DHCP), а статический lease `.75` перестал отвечать по этому MAC (на .75 когда-то был WiFi-MAC `54:77:87:ce:fb:b3`). Если `.75` вдруг «пропал» из сети — телевизор просто переключился на провод и его теперь надо искать по .70 или заново в DHCP-lease. Линк eth0 ТВ на 2026-09-04 = **100 Mbit/s** (downshift, кабель не тянет 1G). | Mac | 192.168.1.57 | 5a:fe:e7:bb:b3:d1 | | | MacBookPro | 192.168.1.43 | 76:88:0d:b9:6a:cd | | | zhimi-airpurifier (1) | 192.168.1.58 | b4:04:29:38:6a:63 | Xiaomi очиститель воздуха | diff --git a/family/projects/watchlist-automation.md b/family/projects/watchlist-automation.md index b3ac4813..f7986282 100644 --- a/family/projects/watchlist-automation.md +++ b/family/projects/watchlist-automation.md @@ -1,6 +1,6 @@ --- created: '2026-05-20' -updated: '2026-05-27' +updated: '2026-09-04' status: active tags: - kraken @@ -77,7 +77,7 @@ Jellyfin (8096) → rescan → виден контент **Пути на Кракене (HDD UUID 49e8f586-3839-4c5d-a1e1-58bfc3579ade):** - `/home/kraken/obsidian` → symlink на `/srv/dev-disk-by-uuid-.../obsidian` -- watchlist-sync: `/srv/dev-disk-by-uuid-.../Developer/watchlist-sync` +- `~/Developer/watchlist-sync` → symlink. **Реальный корень репо** (проверено 2026-09-04): `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f/watchlist-sync` — находится **в корне диска, НЕ под `Developer/`** (в доке ранее путь был ошибочный). Внутри: `watchlist_sync/` (cli.py, arr.py, sync_down.py, sync_up.py, resolver.py, parser.py, discover.py, jellyfin.py), `.venv` (py3.11+httpx+click), `.resolve_cache.json`, pyproject.toml. ## Discover — Фильтрация @@ -136,8 +136,17 @@ Jellyfin library mapping: Movies → `movies`, Cartoons → `mixed` (movies + ep ### KP API Endpoint `api.kinopoisk.dev` редиректит на `api.poiskkino.dev/v1.4/movie`. Использовать destination redirect напрямую. -## Open Tasks (2026-05-20) +### 🔴 Жёстко зашитый `qualityProfileId: 1` в arr.py (корень жирных remux) +Найдено 2026-09-04. В `watchlist_sync/arr.py` **`qualityProfileId: 1` захардкожен** и для Radarr, и для Sonarr: +```python +# radarr_add (~стр. 77) / sonarr_add (~стр. 112) +"qualityProfileId": 1, +``` +Профиль 1 (Radarr) = **'Any'** — разрешает ВСЁ вплоть до Remux-2160p и BR-DISK. Поэтому **каждый новый фильм/сериал, добавляемый watchlist-sync, попадает в «Any»** и Radarr скачивает самый жирный доступный релиз (60GB remux'ы). Готового профиля «2160p, но без Remux» на Kraken нет (нужно создавать). Решение по стратегии — открыто (см. ниже). Чтобы новые шли в поддерживаемое качество: либо создать профиль «2160p без Remux/BR-DISK» и поменять `qualityProfileId` в `arr.py` (Radarr+Sonarr), либо сузить сам профиль 1, либо зашить `4` (HD-1080p). +## Open Tasks + +- 🔴 **[2026-09-04] Решить стратегию качества загрузки новых фильмов** (см. профили в [[arr-stack-kraken]]). Корень — захардкоженный `qualityProfileId: 1` (`Any`) в `watchlist_sync/arr.py`. Пока НЕ менялось (НИЧЕГО не правилось, ждём решение Alex). Вопрос юзеру: сохранить 4K (→ создать профиль «2160p без Remux/BR-DISK» и сменить id в arr.py) или опустить до 1080p (id 4); и менять ли и для Sonarr (сериалы) тоже. - 🟡 Передавать Transmission locations через router script при каждом импорте (сейчас вручную) - 🔴 rsync невыполненных фильмов с HTPC на Кракен (`Фильмы не перенесенные с htpc на кракен.md`) - 🟡 Watchlist sync-up: добавить перенесённые фильмы в нужные разделы diff --git a/personal/tech/cloudflare-tunnel-ssh-published-route.md b/personal/tech/cloudflare-tunnel-ssh-published-route.md new file mode 100644 index 00000000..3aa2a827 --- /dev/null +++ b/personal/tech/cloudflare-tunnel-ssh-published-route.md @@ -0,0 +1,62 @@ +# Cloudflare Tunnel: SSH через Published Application Route + +> Обновлено: 2026-09-04 (итог отладки захода на Kraken) +> Рабочий case с полными командами: `family/how-to/kraken-access.md` + +Генерализуемые выводы про то, как сделать **SSH через Cloudflare Tunnel** (`published application route`), чтобы вход работал `ssh user@host — через cloudflared на клиенте`. + +## Ключевое правило: hostname должен быть 1-уровневым subdomain (БЕЗ точки до домена) + +**Симптом:** двухуровневый subdomain вида `ssh.kraken.qentra.top` (`ssh.kraken` + точка + `qentra.top`) НЕ работает как SSH/TLS через Cloudflare. + +Проверка (решающий факт) — на edge НЕТ TLS-терминации для 2-уровневого hostname: +```bash +openssl s_client -connect ssh.kraken.qentra.top:443 -servername ssh.kraken.qentra.top +# → SSL alert number 40 (handshake failure), "no peer certificate available" +curl -s https://ssh.kraken.qentra.top # ssl=1 handshake failure +``` +В отличие от 1-уровневого hostname (`kraken.qentra.top`), который отвечает: +```bash +openssl s_client -connect kraken.qentra.top:443 ... # CN=qentra.top, verify ok +``` + +**Почему:** Universal SSL Cloudflare-зоны покрывает только `*.domain` (1 уровень wildcard) и сам `domain`. Он НЕ покрывает `*.sub.domain` (2 уровень). Для 2-уровневых нужен Advanced Certificate (SAN на полный двухуровневый wildcard) — обычно проще взять **одиночный subdomain**. + +> ⚠️ ПИТФОЛ: Cloudflare-точка в hostname (`a.b.domain`) = 2 уровня по SSL, точка НЕ безобидна. Рабочая замена — один уровень с дефисом: `ssh-kraken.qentra.top` (покрывается `*.qentra.top`). + +## Правильная схема SSH через Tunnel (по доке Cloudflare) + +**На сервере/туннеле (Zero Trust):** +- Tunnels → туннель → **Routes → Add route → Published application** +- Service: **SSH** → `localhost:22` (или `:22`) +- hostname использовать **одиночный** subdomain (`ssh-kraken.qentra.top`, не `ssh.kraken...`) + +**В Zero Trust Access:** +- Access → **Applications → Add self-hosted** (тип SSH, browser rendering off) на тот же hostname, с политикой (Allow / Service Token). +- SSH-route без Access Application не даёт клиенту пройти даже до авторизации: `cloudflared access login ` → `failed to get app info: ... tls: handshake failure`. + +**На клиенте** (cloudflared установлен): +`~/.ssh/config`: +``` +Host ssh-kraken.qentra.top + HostName ssh-kraken.qentra.top + User kraken + ProxyCommand cloudflared access ssh --hostname %h +``` +Первый раз — авторизация: `cloudflared access login ssh-kraken.qentra.top` (откроет SSO/браузер). Дальше `ssh kraken@ssh-kraken.qentra.top`. + +## Client-side подводные камни + +- `cloudflared access login ` нельзя проверить по `HEAD https://` — SSH-kind hostname НЕ терминирует HTTP/TLS, поэтому `failed to get app info: tls: handshake failure` — ожидаемо, если на маршруте нет Access App. +- `~/.cloudflared/*-org-token` = `not-available` означает, что cloudflared НЕ авторизован в Access org — разовый `cloudflared access login` обязателен. +- Сам ssh к hostname:22 напрямую (без cloudflared в ProxyCommand) к проксированному DNS не работает — hostname за Cloudflare-Anycast, в туннель трафик попадает только через cloudflared-клиент. +- `network_mode: host` (container cloudflared) — сервис напрямую видит локальные порты (sshd на `0.0.0.0:22`). + +## Общий паттерн «жив, но шумит» cloudflared на origin без IPv6 + +Если у origin нет глобального IPv6 (роутер не выдаёт), cloudflared пытается поднять QUIC и по IPv6 → в логах постоянные `ERR ... write udp [::]->198.41.x.x:7844: sendmsg: network is unreachable`, соединения падают/retry. Туннель продолжает работать по IPv4-QUIC. Возможный фикс — заставить cloudflared использовать только IPv4. + +## Связанные заметки + +- `family/how-to/kraken-access.md` — рабочий живой пример (hostname `ssh-kraken.qentra.top`, ingress, команды) +- `family/how-to/kraken-portainer-access.md` — деплой cloudflared-контейнера и логи туннеля