В прошлых статьях я переносил домой музыку и фотографии. Эта статья про другое: сделан свой трекер задач и пустил туда работать ИИ. Задачи живут в обычных Markdown-файлах, по одному файлу на задачу. Синхронизируются они между телефоном, ноутбуком и Linux-боксом. Читают и пишут их Android-приложение TaskForge, Obsidian, CLI, MCP-серверы и два вида ИИ-ассистентов: «Admin» (Grok Bot) на боксе и проектные сессии Claude на ноутбуке. Ниже рассказываю, как это устроено, какие правила пришлось ввести и где я наступил на грабли.

С чего всё началось

Всё началось с Google Таблиц. У каждого проекта была своя таблица-трекер: строки задач, вкладка с решениями, вкладка с вопросами. Рядом в репозиториях лежали PLAN.md, PROGRESS.md, DECISIONS.md и QUESTIONS.md. Пока агент был единственным, кто их вёл, это кое-как работало.

Потом работу проектов стали делать ИИ. Claude гонял замеры и писал код, Grok Bot следил за процессами и собирал отчёты. Обоим нужно было где-то записывать, что сделано, что решено и что ждёт меня. Результаты начали расползаться: часть оставалась в чате, часть в PROGRESS.md, часть в таблице, а часть только в контексте сессии, которая потом закрывалась и забывала всё. Я поймал себя на том, что по утрам выясняю у одного ИИ, о чём вчера договорился с другим, а склероз которым тотально страдают нейронки вообще приводил к непрерывным открытиям, что в плане двухнедельной давности половина не сделана.

Мне был нужен трекер, который одинаково удобен трём участникам. Мне на телефоне, причём с телефона я в основном и управляю. ИИ через нормальный программный интерфейс, а не через скриншоты веб-формы. И ему самому, чтобы трекер пережил любой из своих клиентов. Обычные Markdown-файлы под это подходят. TaskForge оказался приложением, которое умеет работать с такими файлами на телефоне и при этом даёт CLI и MCP-сервер для ИИ.

Трекер, в который пишут несколько ИИ, — это добровольное назначение себя администратором распределённой системы. Синхронизация файлов между тремя устройствами, на которых одновременно что-то правят, поломается обязательно. Поэтому половина статьи не про «как поставить приложение», а про правила, валидацию и сторожей, без которых всё это разваливается за пару дней.

Чего мы хотим

Мне не нужна Jira и не нужна командная работа в привычном смысле: команда здесь — это я и несколько ИИ. Нужен личный трекер, где ИИ ведут проекты, а решения остаются за мной. Отсюда цели:

1. Одна задача — один файл. Формат TaskNotes: Markdown с YAML-шапкой, название задачи = имя файла. Никакой базы данных, никакого облака. Файлы читаются глазами, grep’ом и Obsidian’ом и переживут любое приложение.
2. Телефон как главный пульт. Android-приложение TaskForge: посмотреть, поменять статус, ответить на вопрос, принять решение. Компьютер для этого не нужен.
3. ИИ работают через API, а не руками. Каждый ассистент пишет в трекер только через MCP-сервер или CLI. Самодеятельности в YAML нет: формат знает инструмент, а не память модели. Тут нужно отметить, что я взял TaskForge CLI+MCP но у obsidian и TaskNotes есть свои, разницы для меня по сути нет.
4. Трекер — единственный источник правды. Результаты замеров, решения, вопросы, логи и документы лежат в трекере или привязаны к задаче. Потому нередко можно просто отправить агента в трекер и он найдет немало новых задач, о которых забыл.
5. Задача может разбудить ассистента. Ставлю задаче тег и время — в это время ИИ просыпается и выполняет то, что написано в её теле. Будильник, отложенная проверка или регулярная рутина задаются без отдельного планировщика.
6. Защита от дурака, в том числе от умного дурака. Правила, которые нельзя забыть: валидация на каждой записи, ночные проверки, удаление только через карантин. ИИ иногда очень уверенно делает глупости, поэтому система должна это ловить, а не надеяться на внимательность.
7. Выживание после ребута. Бокс перезагрузился (это у Grok Bot) — синхронизация, циклы и сторожа поднялись сами, а я узнал об этом одной строкой.

Архитектура

Вся установка выросла из одной мысли:

Трекер — это папка с Markdown-файлами. Всё остальное — клиенты, которые по-разному в эту папку пишут, плюс Syncthing, который пытается договориться о том, какая версия файла правильная.

        ТЕЛЕФОН (Android)                     НОУТБУК
   TaskForge-app + Obsidian           Claude Code: сессии mon-g0, tq-g1, ...
   один vault, 5 папок проектов       taskforge CLI/MCP (обёртка bwrap)
            │                          interconnect (почта ассистентов, tmux)
            │                                   │
            └────────── Syncthing ──────────────┤
                (send-receive, .stversions)      │
                            │                    │
   ═════════════════ Linux-бокс (всегда онлайн) ══════════════════
   /workspace/taskforge-vaults/{admin,turboquant,monitor,liberec,proxy}
      └─ Projects/<Name>/  (реальная папка Syncthing: задачи, Archive/, attachments/)
            ▲
            │ stdio
   taskforge-mcp-proxy (--validate, 8 правил)  ──►  taskforge mcp --stdio
            ▲
   Admin (Grok Bot)  ◄──  tt-loop (раз в минуту: теги agent, напоминания, precheck)
            ▲             selftest 23:50 · validate_vault 03:17 · сторож Syncthing
            └── рутина раз в 10 минут: письма Claude + сработавшие задачи

На схеме важны две вещи. Во-первых, у файлов нет главного: телефон, ноутбук и бокс равноправны, и Syncthing по очереди тащит изменения от каждого. Это удобно, пока все правят разное, и превращается в отдельный жанр, когда двое правят одно и то же (см. «Грабли»). Во-вторых, ИИ пишут в трекер только через инструменты. Admin на боксе работает через MCP, обёрнутый в валидирующий прокси. Claude на ноутбуке работает через свой CLI/MCP. Ни один ИИ не сочиняет YAML руками.

Проектов пять, и у каждого свой vault, свой MCP-сервер и своя папка Syncthing:

Свой MCP потому, что мне нужно было внутри одного Obsidian vault на телефоне расшарить на другие устройства подпапки через syncthing и каждому проекту назначить свою папку на боксе (grok bot и ноутбук с Claude), а taskforge MCP такое не может сам по себе, так что пришлось обойти.

• admin — задачи самого Admin по управлению проектами: запуск сессий, сверки, рутины, правила;
• turboquant — эксперименты с квантованием KV-кэша для локальных LLM (замеры, порт, сборки);
• monitor — проект сервиса мониторинга;
• liberec — бытовой личный проект, его ведёт отдельный ассистент;
• proxy — подпроект прокси памяти для Claude Code.

По данным ночной проверки сейчас в них чуть больше двух тысяч задач вместе с архивом. Тысяча с лишним приходится на один Monitor, и это хорошо показывает, сколько мелких шагов набирается, когда каждый шаг ИИ становится задачей. При этом ИИ забывает обычно 95% на долгом проекте.

Шаг 0. Формат: одна задача — один файл

TaskNotes — это простой формат. Задача = файл .md, метаданные в YAML-шапке, тело — свободный Markdown. Название задачи хранится в имени файла, ключа title нет. Вот как выглядит типичная задача:

---
status: open
priority: normal
due: 2026-10-10
scheduled: 2026-10-09
dateCreated: 2026-10-08T20:44:57.215+02:00
tags:
  - task
contexts:
  - pc
projects:
  - "[[TurboQuant]]"
timeEstimate: 15
onCompletion: archive
taskSourceType: taskNotes
dateModified: 2026-10-08T20:44:57.215+02:00
id: muzvyzun
---

Короткое описание, что сделать, и критерий готовности.

Материалы: [[attachments/Название отчёта]]

Несколько деталей, о которых стоит знать заранее:

• Файл считается задачей, только если в tags есть task. Без этого тега файл — просто заметка.
• id — это base36 от времени создания. Он не меняется никогда, даже при переименовании, и машинные ссылки (depends_on) идут по нему.
• projects со ссылкой на другую задачу означает «подзадача». blockedBy — это список зависимостей «нельзя начать, пока не закончено то».
• Закрытая задача с onCompletion: archive переезжает в Archive/. Переносит её TaskForge на телефоне или инструмент, но никогда не ИИ руками.
• Из имени файла вырезаются / \ : * ? " < > | # [ ] ^, а кириллица и пробелы остаются. Заголовок «Решение: да/нет?» превратится в имя файла, по которому потом не найдёшь ни одну вики-ссылку.

Структура vault’а одинаковая у всех пяти проектов:

Тут нужно понимать, что это структура на компе Grok Bot в облаке, на моем телефоне где работает TaskForge это один vault, а это сделано как раз потому, что taskforge cli не поддерживает указание отдельных пространств (термин TaskForge) с задачами по разным папкам. Мне нужно было что бы агенты копаясь в своих задачах чужие не трогали.

/workspace/taskforge-vaults/<проект>/
├── Projects/<Name>/          ← реальная папка Syncthing
│   ├── *.md                  ← активные задачи
│   ├── Archive/              ← закрытые
│   └── attachments/          ← документы: docs/, history/, research/, runs/<run-id>/
├── TaskNotes/Archive  →  symlink в Projects/<Name>/Archive
└── TaskForge/Settings →  symlink на общие настройки (dialect.json, spaces.json)

Папка проекта должна быть настоящей, а не симлинком: TaskForge CLI не индексирует задачи, до которых добирается только через симлинк. На ноутбуке у Claude по той же причине стоит маленькая обёртка taskforge-project. Она через bwrap монтирует реальную папку Syncthing внутрь vault-обёртки в приватном пространстве имён и подкладывает свою копию dialect.json, где папка новых задач указывает в проект, а не в несинхронизируемый TaskNotes/Tasks:

# taskforge-project <turboquant|monitor|proxy> <аргументы taskforge>
exec bwrap --bind / / --dev-bind /dev /dev \
  --bind "$R" "$V/Projects/$N" \
  --ro-bind "$O" "$(readlink -f "$DL")" \
  --die-with-parent "$HOME/.local/bin/taskforge" "$@"

Без sudo, ничего не перемещается, общий файл настроек телефона не меняется. Но это просто “как агент придумал”, я не критиковал его, работает и ладно.

Ещё одно правило, которое я ввёл не сразу: всё содержимое трекера пишется по-русски. Это касается названий, тел, логов и решений, кто бы их ни писал. Между собой ассистенты переписываются по-английски, но всё, что читаю я, должно быть по-русски. В трекере я читаю всё, поэтому он русский. Но то, что агенты обязаны говорить между собой ао английски экономит токены.

Шаг 1. MCP: ИИ пишет только через инструмент

Главное правило установки звучит так: формат задач знает инструмент, а не ИИ. Модель уверенно напишет YAML «по аналогии», перепутает in_progress с in-progress. Каждая такая мелочь ломает приложение на телефоне. Поэтому любые правки задач идут только через MCP-сервер проекта, а если его нет — через CLI. Руками файл не редактирует никто.

На боксе работают пять MCP-серверов, по одному на vault: taskforge-admin, taskforge-turboquant, taskforge-monitor, taskforge-liberec, taskforge-proxy. Все они запускаются одинаково, через прокси:

command: python3
args:    /workspace/agent-tools/taskforge-mcp-proxy/proxy.py \
           --vault /workspace/taskforge-vaults/<имя> --default-space <имя> --validate
env:     TASKFORGE_VAULT=/workspace/taskforge-vaults/<имя>

Важная мелочь: taskforge mcp игнорирует --vault и берёт путь только из переменной окружения TASKFORGE_VAULT. Прокси выставляет её сам и без хранилища не стартует.

Как ИИ работает с задачей:

1. Перед первой записью в сессии вызывает get_dialect. Это машинное описание настроек vault’а, которое приложение генерирует само: какие статусы есть, как они пишутся в файл, где архив. Например, MCP-токен todo пишется в файл как open, а medium — как normal.
2. Находит задачи через query_tasks (status:in_progress path:^Projects/Turboquant/ text:"...").
3. Меняет задачу через update_task, и меняет точечно: статус отдельно (set_status), зависимость отдельно (add_depends_on), лог отдельно (append_note). MCP не переписывает файл целиком, а меняет конкретное поле, сохраняя всё остальное, включая ключи, которых он не знает.
4. Передаёт в каждую правку if_hash из последнего get_task. Если хэш не совпал, значит, файл успел поменяться, обычно потому, что я в этот момент правил задачу на телефоне. Тогда ИИ перечитывает задачу, пробует ещё раз и, если снова не вышло, останавливается и сообщает мне.

Последний пункт оказался важнее, чем выглядит. Без if_hash ИИ спокойно затирает правку, которую я сделал на телефоне минуту назад.

Шаг 2. Валидирующий прокси: восемь правил, которые нельзя забыть

Правила в инструкциях ИИ работают примерно как правила в офисной вики: все читали, никто не соблюдает. Поэтому через несколько дней правила переехали из текста в код. Между ассистентом и MCP-сервером стоит taskforge-mcp-proxy — stdio-прокси на Python, который перехватывает каждый вызов записи и до сервера проверяет его по правилам из rules.json.

Режимов два. error — вызов не уходит, ИИ получает «Нарушено правило N (имя): … Исправь: …», исправляет и повторяет. fix — прокси исправляет сам и пишет в ответ «прокси исправил: …». Режима warn нет сознательно: предупреждения ИИ читают так же, как я читаю лицензионные соглашения.

1. Связи обязательны. Задача без связей запрещена: нужна родительская задача, вики-ссылка в теле или зависимость. Исключение — тег root и пометка «корневая задача проекта». Задача, ни с чем не связанная, — это потерянная задача.
2. Без опасных символов в заголовке. Никаких / \ : * ? " < > | # ^ [ ], иначе ломаются имена файлов и вики-ссылки.
3. Задача с тегом agent должна иметь время в scheduled и тело не короче 80 символов. Тело — это инструкция, которую ассистент выполнит, когда проснётся, и «сделать» за инструкцию не считается.
4. У задачи со временем есть напоминание (fix). add_task не умеет писать напоминания, поэтому прокси дописывает их отдельным вызовом после записи.
5. При закрытии onCompletion: archive (fix). В TurboQuant задача-замер не закроется без заполненных result, measured_at и run_dir.
6. blocked и deferred требуют причины и связи. Нужна строка Причина: … или Ждёт: … и ссылка на то, чего задача ждёт. Если она ждёт меня, то ссылка ведёт на задачу «Решение Романа — …».
7. Удаление под замком. Удалять можно только тестовые задачи или задачи с тегом delete-ok, пачками не больше 25.
8. Только своё пространство. Создавать задачи в чужом проекте или в несинхронизируемой папке нельзя.

Кусочек rules.json, чтобы было понятно, насколько это просто устроено:

"blocked_needs_reason": {
  "enabled": true,
  "mode": "error",
  "statuses": ["blocked", "deferred"],
  "reason_regex": "(?im)^[\\s>*_-]*(Причина|Ждёт|Ждет)[*_]*\\s*:[*_\\s]*\\S",
  "require_blocker": true,
  "cross_space_prop": "blocked_by_ref"
}

Файл перечитывается по mtime, перезапуск не нужен. Если файл битый, остаётся прежний рабочий конфиг, а ошибка уходит в журнал. Если сломалась сама проверка, вызов уходит как есть, чтобы прокси никогда не стал причиной, по которой трекер не работает. Все решения прокси пишутся в validation.log: дата, vault, инструмент, правило, block или fix. К прокси есть тесты на свежей копии Admin-vault’а, боевое хранилище они не трогают.

Прокси ловит только записи через MCP. Телефон, Obsidian и Claude на ноутбуке (у него свой MCP без прокси) пишут мимо него. Поэтому раз в сутки ночью validate_vault.py проходит по файлам всех хранилищ с теми же правилами и присылает Grok Bot отчёт. В первый же прогон он нашёл больше сотни нарушений в старых задачах; их разобрали за день. Сейчас в типичном отчёте несколько строк.

Шаг 3. Syncthing: телефон, ноутбук, бокс

Синхронизацию делает Syncthing. Это шесть папок: пять проектов и общие настройки TaskForge (dialect.json, spaces.json), без которых MCP не понимает, где у проекта папки. Режимы такие:

• бокс и телефон — send-receive для всех папок;
• ноутбук — send-receive для проектов, где работает Claude, и receive-only для admin: в задачи Admin сессии Claude не пишут;
• версии старых файлов складываются в .stversions/.

Бокс — это общая машина, на которой живут ассистенты Grok Bot. Он иногда перезагружается и обновляется, и при этом теряет часть домашней папки. Поэтому всё, что должно пережить ребут, лежит в /workspace, а поднимает это идемпотентный скрипт:

#!/bin/bash
# box-ensure.sh — восстанавливает то, что бокс теряет при сбросе, и перезапускает фоновые службы.
# 1) taskforge CLI: восстановить из копии, если npm-установка пропала
if [ ! -x ~/.local/lib/node_modules/taskforge-md/bin/taskforge.js ]; then
  cp -a /workspace/agent-tools/taskforge-md-copy/. ~/.local/lib/node_modules/taskforge-md/
  echo "restored taskforge-md"
fi
# 2) Syncthing: состояние в /workspace/syncthing-state (--home), ключи зеркалируются в бэкап
/workspace/agent-tools/syncthing/syncthing-ensure
# 3) цикл триггеров задач
bash /workspace/agent-tools/task-trigger/tt-start.sh

Ключи и конфиг Syncthing (key.pem, cert.pem, config.xml) syncthing-ensure зеркалирует в бэкап и возвращает обратно, если каталог состояния пропал. Это правило написано кровью ИИ агентов :)

Сверху работает рутина «Сторож Syncthing и цикла задач». Сначала она запускалась каждый час, сейчас реже, раз в четыре часа: токены не бесплатные. Сторож запускает box-ensure.sh (если в выводе есть restored или started, значит, бокс перезагружался, и я получаю одну строку). Через REST проверяет, что папок ровно столько, сколько должно быть, что все они idle с need=0 и что телефон и ноутбук подключены. Ищет новые *.sync-conflict-* и проверяет, что цикл триггеров жив. Если всё в порядке, сторож молчит. Пишет мне только при настоящей проблеме.

Шаг 4. Задачи, которые будят ассистента

Задача с тегом agent и временем в scheduled — это будильник для ИИ. В её теле лежит инструкция. Когда наступает время, ассистент просыпается и выполняет её.

Работает это так. На боксе крутится один цикл tt-loop.py, который раз в минуту через taskforge CLI опрашивает все хранилища из vaults.txt. Событий три:

Последний тип события — страховка от меня. Если я поставил задачу «к 15:00», но забыл тег или напоминание, ассистент заметит это за полтора часа, а не после того, как дедлайн прошёл.

Изначально цикл слал вебхуки, и ассистент просыпался мгновенно. Потом от вебхуков отказались (кто то ддосит Grok Bot), и теперь доставка выглядит так:

{
  "delivery": "log",
  "default": "admin",
  "rules": [
    {"vault": "liberec", "recipient": "admin"},
    {"tag": "agent-lberec", "recipient": "admin"}
  ],
  "vault_options": {"liberec": {"reminders_any_tag": true}}
}

Цикл пишет строки [EVENT] в свой журнал, а Admin раз в 10 минут запускает одну рутину «Проверка писем Claude и задач TaskForge». Сначала идёт дешёвая предпроверка: маленький скрипт на боксе смотрит события, а такой же скрипт на ноутбуке смотрит почту. Если ответ NONE, рутина сразу заканчивается и почти не тратит токенов. Если что-то есть, Admin обрабатывает своё, а чужое пересылает адресату: например, события бытового проекта уходят его ассистенту. Остальные боты собственных опросов не держат. Опрашивает один, и платим за один.

Выполнив разовую задачу, ассистент закрывает её. Если работа длинная, он оставляет задачу в in_progress, пишет в тело, что запущено и где лог, и ставит себе новую задачу-будильник «проверить в 06:45». Так у меня в трекере появились задачи вида «Admin — будильник 14.10 06:45, проверка приёмки шага 2».

Ночной самотест. Каждый день в 23:50 selftest.py создаёт в Admin-vault’е задачу admin-selftest-<дата> с тегом agent и временем «через две минуты». Он ждёт, пока цикл её заметит, отправит событие и переведёт задачу в работу, а потом закрывает её. Любой сбой дописывается в selftest-fail.txt. Нет файла — нет проблем; есть файл — Grok Bot узнает. Самотест честно доказывает только то, что цикл жив и события уходят. То, что ассистент проснулся и что-то сделал, проверяют уже по результатам в трекере.

Шаг 5. Сессии Claude: сначала задача, потом код

Проектную работу делает Claude Code на ноутбуке. Одна длинная сессия на весь проект быстро переполняет контекст, начинает забывать начало и дорого стоит. Поэтому работа нарезана на группы задач, и каждая группа получает свою свежую сессию: mon-g0, tq-g1 и так далее. Открывает и закрывает их Admin через interconnect:

# открыть сессию под группу, связав её с задачей-хабом группы
python3 interconnect.py open tq-g5 ~/projects/turboquant --task turboquant:<id-хаба>

# кто чем занят: состояние, время в нём, непрочитанные письма, связанная задача
python3 interconnect.py sessions
python3 interconnect.py watch --idle-min 60     # сторож: печатает только проблемы

# письмо в ящик сессии, затем «толчок» в терминал, если она ждёт ввода
python3 interconnect.py send --from admin --to tq-g5 "Start: hub task <id>, rules in the start letter"
python3 interconnect.py nudge tq-g5

interconnect — это файловые почтовые ящики с flock плюс управление tmux-сессиями. Скрипт сам ничего не решает и ничего не нажимает. Он сообщает состояние (РАБОТАЕТ, ЖДЁТ ВВОДА, ЖДЁТ ПОДТВЕРЖДЕНИЯ, ЛИМИТ, УПАЛА), а решает Grok Bot Admin. Каждые 15 минут сторож запускает watch. Пустой вывод значит, что всё хорошо. «ЖДЁТ ВВОДА + непрочитанные» значит nudge. Меню и подтверждения разбираются по правилам, а всё, что касается удаления или публикации, решаю я.

Правила для сессий родились из конкретных неприятностей, и каждое теперь вписывается в стартовое письмо каждой сессии:

• Сначала задача, потом реализация. Перед тем как делать шаг, сессия заводит на него задачу в трекере через MCP. Потом делает шаг и записывает результат в эту задачу. Так в трекере остаётся полный путь разработки, а не только итог. Отсюда и тысяча задач в одном проекте.
• Вопросы только письмом. Сессия, которая молча ждёт ответа в терминале, считается ошибкой. Любой вопрос, решение или блокировку, включая запросы подтверждения от самого Claude Code, сессия отправляет письмом в ящик admin и продолжает другую работу.
• Результаты перепроверяет тот, кто их получил. Если замер выглядит подозрительно, Admin сам в логи не лезет, а поручает проверку сессии и обсуждает с ней вывод до согласия. Ко мне приходят только вопросы, которые остались неясными, по одному, с вариантами и рекомендацией.
• Знания попадают в трекер до закрытия. Перед закрытием сессия сдаёт handoff — документ во вложениях проекта: что сделано, что прервано, как продолжить, что предлагается дальше. Каждая новая идея, находка, проблема и новая работа в handoff должна иметь id задачи в трекере. Admin сверяет handoff с трекером построчно, по таблице «пункт → id». Пункт без id возвращается сессии.
• Закрыть без сверки нельзя технически. close без флага --reconciled откажет, а пока сессия работает, тоже откажет:

$ python3 interconnect.py close cs-test
close: сверка не отмечена (задача: admin:...). Сначала handoff + задачи/хабы через MCP
       + сверка Admin + «сверка ок», затем повторить с --reconciled

Порядок всегда одинаковый: handoff → сверка трекера (задачи, хабы, дубли) → письмо «сверка ок» → close --reconciled → снимок экрана в logs/closed/, путь к нему записывается в задачу. Логи сессий не удаляются никогда.

Мне нравится, как это смотрится с телефона. Я открываю TaskForge и вижу хаб группы, его подзадачи с результатами и handoff со ссылками. Если хочется, через remote control Claude подглядываю в саму сессию. Решения, которые ждут меня, лежат отдельными задачами «Решение пользователя — …», и от них по depends_on зависят задачи, которые без меня не двинутся.

Шаг 6. Правила, без которых всё это не живёт

Часть правил стоит в прокси, а часть — это договорённости, которые записаны в навыках ассистентов и проверяются ночью:

• Любое удаление — через карантин. Ничего не удаляется напрямую. Сначала объекты переносятся в quarantine/<дата>-<задача>/ с манифестом (путь, размер, sha256). Git-ветки сначала упаковываются в git bundle, бандл проверяется git bundle verify, его sha256 записывается в задачу. Затем проверяется, что ничего нужного не ушло. Окончательное удаление идёт отдельным шагом, только после моего «ок», и записывается в задачу. Это касается даже чисток, которые я сам одобрил.
• Дубли не удаляются, а отменяются со ссылкой. Дубль получает строку «Дубль: [[основная задача]]» и статус cancelled. История остаётся, ссылки на дубль продолжают работать, а при следующей миграции понятно, откуда что взялось.
• Заблокированная задача ссылается на то, чего ждёт. «Ждёт: ответа» без ссылки не считается. Если задача ждёт меня, то её блокирует задача-решение, и я вижу полный список ожидающих.
• Документы переносятся в трекер, а не копируются. Отчёт, лог, план или выгрузку кладут в attachments/ проекта и ссылаются на них из задачи. После проверки sha256 и ссылки оригинал удаляется (тоже через карантин). Документ без задачи значит потерянную задачу. Модели, бинарники, секреты и файлы больше ~50 МБ в трекер не попадают, в задаче записывается только путь к ним.
• Задачи читаем раньше документов. Чтобы экономить токены, ассистент сначала читает задачи (там лежат свойства и выжимки), идёт по ссылкам на другие задачи и только при нехватке данных открывает вложения. Тяжёлое чтение он поручает исполнителю и просит прислать только выводы.

Грабли

Места, где ИИ потратил время (а пару раз чуть не потерял данные), чтобы вы не потратили.

1. Syncthing разрешает конфликты молча. Если две стороны поправили один файл, Syncthing оставит под нормальным именем более новую по mtime версию, а старую положит рядом как <задача>.sync-conflict-<ДАТА>-<ВРЕМЯ>-<УСТРОЙСТВО>.md. Уведомлений не.
2. Бокс потерял ключи Syncthing. Однажды при обновлении (комп облачный Grok Bot) каталог состояния Syncthing на боксе пересоздался.
3. Телефон завис на 95% из-за длины имени файла. Конфликтная копия задачи с длинным русским названием получила имя в 251 байт.
4. Ребут воскресил двести закрытых задач. После перезагрузки бокса около двухсот уже закрытых задач во всех пяти проектах вернулись в активные папки как старые копии, а их актуальные закрытые версии остались в Archive/. Syncthing сделит за версиями, боты разобрали все сами.
5. ИИ сочиняет формат по памяти. До MCP-only ассистент однажды «аккуратно поправил» несколько задач руками, по аналогии с соседними. Приложение на телефоне потом показывало их без статуса.
6. Новые задачи уезжали в несинхронизируемую папку. По умолчанию TaskForge кладёт новые задачи в TaskNotes/Tasks, а эта папка не синхронизируется. Задачи создавались и исчезали для всех, кроме того, кто их создал. На боксе это лечит прокси (подставляет пространство и запрещает TaskNotes/Tasks правилом 8), на ноутбуке — обёртка с подменой dialect.json. Перенести задачу оттуда на ноутбуке нельзя: move_task падает с EXDEV через bind mount. Поэтому о таких задачах ИИ сообщает, а не чинит их сам.
7. Сессия Claude молча ждёт. Claude Code любит спросить «Do you want to proceed?» и ждать часами. Сессия при этом выглядит живой, а работа стоит. Отсюда правило «вопросы только письмом», сторож watch и проверка, что nudge действительно нажал Enter (до трёх нажатий, затем «Enter НЕ принят» и разбор по экрану). После сброса лимита Claude сам работу не продолжает, его нужно толкнуть этим занимается Grok Bot.
8. Знания умирают вместе с сессией. Первые сессии закрывались с хорошим handoff, но половина находок в нём не превратилась в задачи и через день была забыта. Теперь действует гейт: каждый пункт handoff сопоставлен с id в трекере, иначе close --reconciled не выполняется.
9. Вебхуки оказались лишними. Мгновенное пробуждение по вебхуку выглядело красиво, пока вебхук не начал отвечать HTTP 400 на каждое письмо так как Grok ддосят.

Что в итоге

• Трекер — это папка с файлами. Пять проектов, одна задача = один Markdown-файл. Читается глазами, Obsidian’ом, grep’ом и переживёт любое приложение. Ни одного облака по дороге.
• Телефон — главный пульт. Я вижу всё, что делают ИИ: каждый шаг, каждый результат, каждое решение, которое ждёт меня, с зависимостями и ссылками на документы.
• ИИ работают через инструменты, а не руками. MCP с валидирующим прокси на боксе, CLI/MCP на ноутбуке, восемь правил на каждой записи и ночная проверка всех файлов.
• Задачи будят ассистента. Тег agent и время превращают задачу в будильник или рутину. Precheck страхует от забытых напоминаний, ночной самотест подтверждает, что цикл жив.
• Сессии Claude не уносят знания с собой. Задача на каждый шаг до реализации, handoff со сверкой по id, закрытие только после «сверка ок».
• Ничего не удаляется сразу. Карантин с манифестом, дубли отменяются со ссылкой, конфликты Syncthing разбираются вручную, а не «новее значит правильнее».
• Всё поднимается после ребута само, а я узнаю об этом одной строкой. Ребут 14.10 правда показал, что «поднялось» и «осталось как было» — разные вещи, и разбор воскресших задач ещё впереди.

Рутину — скрипты, прокси, валидацию, сторожей, разбор конфликтов, сверку handoff, даже большую часть этих правил в виде текста — делали ИИ. Решения «что удаляем, что считаем дублем, когда закрываем сессию, какое правило становится жёстким» оставались за мной. Каждое такое решение лежит в трекере отдельной задачей с датой. Забавно, что половина правил выше появилась как реакция на то, что ИИ сделал что-то очень уверенно и очень не так. Трекер, в котором работают ИИ, в итоге оказался не про задачи, а про то, как сделать ошибку дешёвой и заметной.

P.S. Самым полезным правилом оказалось не самое умное, а самое занудное: «сначала заведи задачу на шаг, потом делай». Сессии пишут тысячу задач, но теперь на вопрос «а почему мы так решили неделю назад» есть ответ в трекере, а не в закрытой сессии.

В прошлой статье я писал как перенести свою музыку себе домой, а это руководство для того, кто решил забрать свой фотоархив домой. От пустого LXC-контейнера до работающего Immich: свой «Google Photos» с умным поиском и лицами на встроенном GPU, доступ с телефона из любой точки мира — и перенос семнадцати тысяч фотографий из Google без потери единого кадра и с восстановлением геолокации.

С чего всё началось

В прошлый раз я собирал себе музыкальный стек вместо YouTube Music — и обещал «другую историю» про фотографии. Вот она.

Мотивация тут даже проще, чем с музыкой. Фотоархив — весь мой архив жил у Google: подписка за хранилище, «умные» функции, которые то появляются, то переезжают в платный тариф, и полная непрозрачность того, что с моими снимками происходит. Плюс у меня накопился второй архив в MEGA — старый телефонный хлам, свадьба друга, сканы документов — который вообще нигде не был разобран.

Захотелось простого: все фотографии в одном месте, на моём диске, с поиском «фото с котом на снегу» без отправки котов в чужое облако. И чтобы телефон продолжал работать как раньше — открыл приложение, а там всё.

Сразу честно: самохостинг фотографий — это добровольное назначение себя бэкап-инженером. Google хотя бы ничего не терял; теперь если потеряю — сам. Поэтому половина этой статьи не про «как поставить Immich», а про сверки, страховки и порядок действий, при котором потерять нельзя. Причем выкачанные архивы я так и не удалю.

Чего мы хотим

Мне не нужен фотохостинг для публики и не нужна «социальность» — нужен личный архив, который переживёт любое облако и чужие продуктовые решения. Максимум это расшарить по ссылке кому то фоточки. Отсюда цели:

1. Весь архив на своём диске. Ядро — самохостовый Immich: лента, альбомы, карта, умный поиск, лица. Файлы у меня, в RAID, с бэкапами. RAID это просто коробка куда воткнуты два HDD,подключенная к миниПК по usb 3.2 gen2, я в прошлый статьях о ней писал.

2. ML локально, не в облаке. Поиск по содержимому (не пробовал) и распознавание лиц (пробовал) — на интегрированной видеокарте домашнего сервера. Фотографии не покидают дом ради «умных» функций.

3. Телефон как раньше. Родное приложение Immich снаружи, из любой сети — но не «порт наружу», а mTLS: без клиентского сертификата сервер для интернета не существует.

4. Перенос без потерь. Google Photos + MEGA-архив → Immich, со сверками на каждом шаге. Из Google не удаляется ничего, пока целостность не доказана счётчиками. При этом архив выгрузки я естественно вообще удалять не буду никогда.

5. Вернуть геолокацию. Google прячет координаты при экспорте где может, половина архива вообще снята без GPS. Хочу восстановить географию — честно, с пометкой «откуда взято», не выдавая реконструкцию за правду камеры. Они до 2024 года следили за всеми пользователями постоянно (если кто не знал), но потом говорят, что удалили, но может просто спрятали полную геолокацию, так что тут был пробел и пришлось немного думать.

6. Выжить после ребута. Сервер перезагрузился — всё поднялось само. Ноутбук админа в этом не участвует.

Архитектура

Одна мысль, из которой растёт вся установка:

Immich — это четыре контейнера и одна папка. Всё, что делает установку «своей», живёт вокруг: проброс iGPU в unprivileged LXC, mTLS на входе и дисциплина наполнения, при которой источник не удаляется, пока копия не доказана.

  ТЕЛЕФОН (Immich-app)              БРАУЗЕР (ноут)
       │ api.imm.example.com            │ imm.example.com
       │      mTLS :443                 │    mTLS :443
       ▼                                ▼
  edge-VPS (белый IP) ── WireGuard ── Caddy на роутере (OPNsense)
       tls { client_auth CA }   ← без серта отлуп на TLS-хендшейке
       api.:  только /api*, /share*, /.well-known/*  (админки нет)
       imm.:  полный веб-интерфейс + админка
                                        │ plain http, внутренний VLAN
  ══════ Proxmox ── LXC «immich» (unprivileged, Docker) ══════
                                        ▼
   immich_server :2283 ── valkey ── postgres (VectorChord)
        │  /data = ./library  (139 ГБ, btrfs RAID1)
   immich_machine_learning (-openvino) ◄── /dev/dri (Intel Iris Xe)
        CLIP smart-search + лица, всё локально

Со схемы важно прочитать две вещи. Первое: наружу торчит только :443 с обязательным клиентским сертификатом — для сканеров интернета сервера просто нет, и это снимает главный страх «фотографии всей жизни на самодельном сервере». Второе: вся установка — одна папка ~/immich-app (compose, фото, база, кэш моделей), и это осознанное решение: один снапшот-бэкап LXC забирает установку целиком, восстановление — одна операция. Причем весь ML стек это просто встроенная GPU, я как то писал уже статью про это и там говорил, что потом расскажу зачем возня, вот за этим, надо было разобраться.

Железо скромное: мини-ПК на i5-1240P с интегрированной Iris Xe, диски — 2×8 ТБ USB в btrfs RAID1. Никакой дискретной видеокарты для ML не нужно — и это, пожалуй, главная приятная новость всей затеи.

Установка

Шаг 0. LXC — то, что делается только с хоста

Immich живёт в отдельном unprivileged-LXC (Ubuntu 24.04, docker внутри). Единственное специальное — проброс render-ноды iGPU для ML:

# на хосте Proxmox, под root (116 — номер вашего CT)
pct set 116 --dev1 /dev/dri/renderD128,gid=993,uid=1000
pct set 116 --features nesting=1
pct set 116 --onboot 1

gid=993 — группа render хоста, uid=1000 — обычный пользователь внутри CT: нода приезжает в контейнер уже с правильным владельцем, и дальше всё работает без единого послабления безопасности. Два популярных совета из старых гайдов не понадобились, и это стоит проговорить: apparmor: unconfined не нужен на актуальном Proxmox (баг runc, из-за которого совет появился, в свежих пакетах lxc исправлен), а keyctl=1 Docker в этой конфигурации не требует — проверено запуском: seccomp отдаёт keyctl() как «не реализовано», и никто не жалуется. Чем меньше дырок в изоляции — тем спокойнее спится.

Внутри CT — обычный docker + compose, и дальше всё под обычным пользователем (uid 1000). Root — только для systemd-юнита автозапуска. Управление — sudo docker compose, пользователя в docker-группу не добавляем (членство в ней — это root-эквивалент, sudo хотя бы просит пароль и пишет лог).

Шаг 1. Официальные файлы + четыре правки

Immich ставится из официальных файлов релиза — меньше самодеятельности, легче обновляться, но тут по вкусу:

mkdir -p ~/immich-app && cd ~/immich-app
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O hwaccel.ml.yml     https://github.com/immich-app/immich/releases/latest/download/hwaccel.ml.yml
wget -O .env               https://github.com/immich-app/immich/releases/latest/download/example.env

В .env правим четыре значения:

UPLOAD_LOCATION=./library      # фото — рядом с compose, в rootfs CT
DB_DATA_LOCATION=./postgres    # база — там же
TZ=Europe/Amsterdam
IMMICH_VERSION=v3              # мажорный канал, НЕ release (см. грабли); параноикам — пин v3.0.2
DB_PASSWORD=<только A-Za-z0-9, без спецсимволов>

Относительные пути: вся установка (ОС, docker, фото, база, кэш моделей) лежит в одном rootfs контейнера, и еженедельный vzdump в режиме снапшота забирает её целиком, crash-consistent — Postgres при восстановлении доиграет WAL сам. Один бэкап = цельная установка.

В docker-compose.yml — две правки под OpenVINO и одна под HDD:

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}-openvino
    extends:
      file: hwaccel.ml.yml
      service: openvino          # /dev/dri уезжает в контейнер отсюда
    user: "1000:1000"
    group_add: ["993"]           # render-группа: доступ к renderD128 под non-root
    environment:
      HOME: /cache               # у uid1000 нет HOME → кэши моделей падают без этого
    volumes:
      - ./model-cache:/cache     # bind вместо named-тома: владелец — вы, не root
    env_file: [.env]
    restart: always

  database:
    environment:
      DB_STORAGE_TYPE: 'HDD'     # у нас btrfs на USB-дисках, не NVMe

Остальным сервисам добавляем только user: "1000:1000" — весь стек работает под обычным пользователем, включая Postgres (его данные принадлежат uid 1000, он и бежит от uid 1000). Драйверы Intel внутрь CT ставить не нужно: образ -openvino несёт весь рантайм в себе, от хоста требуется только kernel-драйвер i915 и проброшенная нода.

Шаг 2. Запуск и проверка, что ML реально на видеокарте

cd ~/immich-app && sudo docker compose up -d

Четыре контейнера должны стать healthy, веб отвечает на :2283 — создаём администратора. Дальше проверка, ради которой всё затевалось:

sudo docker logs immich_machine_learning 2>&1 | grep -i provider
#  → Setting execution providers to ['OpenVINOExecutionProvider', ...]
intel_gpu_top   # на хосте, во время джоба Smart Search: движки iGPU должны шевелиться

Если в логе только CPUExecutionProvider — ML работает, но на процессоре, и первичная индексация двадцати тысяч фото будет есть CPU, а GPU будет простаивать (проверять это надо до заливки семнадцати тысяч фото, а не после). Первый прогон разово скачает модели (CLIP + детектор лиц) в model-cache — около 7 ГБ.

Шаг 3. Автозапуск

# /etc/systemd/system/immich.service (в CT, под root)
[Unit]
Requires=docker.service
After=docker.service network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/home/<user>/immich-app
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
[Install]
WantedBy=multi-user.target

systemctl enable immich.service — и вместе с restart: always у контейнеров и onboot=1 у самого LXC получаем три уровня «поднимись сам»: за «сервер перезагрузился, фотографий нет» просыпаться не любит никто. Ребут-тест обязателен: перезагрузить CT и убедиться, что всё встало без рук — до того, как сервер станет единственным местом с фотографиями.

Шаг 4. Доступ снаружи: mTLS и два хоста

Сначала — почему так строго. У Immich нет ни 2FA, ни защиты от брутфорса. То есть форма логина, торчащая в интернет голым портом, защищена одним паролем — для архива всей жизни этого мало. Значит, вся безопасность живёт на входе.

Наружу Immich выходит через reverse-proxy (у меня Caddy на роутере; до него — VPS с белым IP, который не терминирует TLS, а гонит сырой :443 через WireGuard домой — но это детали конкретной сети, важна сама схема). Ключевое решение — два разных хоста с разной шириной доступа, оба за mTLS:

# Браузер: полный Immich, включая админку
imm.example.com {
    tls { client_auth { trust_pool file ca.pem } }
    handle { reverse_proxy immich.vlan:2283 }
}

# Телефон: ТОЛЬКО пути, нужные приложению. Корня нет → админки снаружи нет
api.imm.example.com {
    tls { client_auth { trust_pool file ca.pem } }   # тот же серт, что в Android
    handle /api/*               { reverse_proxy immich.vlan:2283 }
    handle /.well-known/immich* { reverse_proxy immich.vlan:2283 }
    handle /share/*             { reverse_proxy immich.vlan:2283 }
    handle /_app/*              { reverse_proxy immich.vlan:2283 }
    handle /custom.css          { reverse_proxy immich.vlan:2283 }
    handle /favicon*            { reverse_proxy immich.vlan:2283 }
}

В целом можно и одним обойтись и не заниматься выделением эндпоинтов, я два сделал потому, что поначалу mTLS не выходило в immich добавить так как там UI не очевидный, ниже напишу. ca.pem — собственный CA (создаётся в пару кликов в любом роутере/PKI; у меня — в OPNsense System→Trust), из него же выписываются клиентские сертификаты: .p12 для ноутбука и телефона. Серверный сертификат при этом обычный Let’s Encrypt, так что в доверенные корни телефона ничего добавлять не нужно — ставится только клиентский. Без сертификата соединение умирает на TLS-хендшейке — до HTTP, до какого-либо «login», до самого Immich дело даже не доходит. Сканеры интернета видят закрытую дверь.

Родное приложение Immich клиентские сертификаты поддерживает (Settings → Advanced → «SSL client certificate» import, помечено experimental — но работает, включая фоновый бэкап). С двумя засадами — они в граблях (№6).

Наполнение: Google Photos → Immich без потерь

Теперь главное. Перенос фотоархива — это не «скачал и залил»: из Google ничего не удаляется, пока каждая партия не доказана счётчиками. Весь порядок ниже — в этой логике.

Takeout и его проверка

Экспорт — Google Takeout, только Google Photos, zip по 50 ГБ (максимальный размер части: чем меньше частей, тем реже фото и его JSON-метаданные разъезжаются по разным архивам). Скачивать все части резюмируемым способом, не голой вкладкой браузера — она молча бьёт большие файлы. И первая проверка ещё до всякого Immich:

ls takeout-*.zip | wc -l    # число частей = числу, которое назвал Google
for f in takeout-*.zip; do unzip -t "$f" >/dev/null && echo "OK $f" || echo "CORRUPT $f"; done

Битую часть — перекачать, пока ссылки живы (~7 дней). Пропущенная средняя часть молча теряет тысячи фото. Архивы не распаковывать: инструмент импорта читает zip напрямую и матчит фото↔JSON↔альбом по путям через все части сразу.

immich-go: импорт, которому нельзя верить на слово

Заливает архив immich-go — специализированный инструмент именно для Takeout. Он берёт дату съёмки, GPS и альбомы из JSON-сайдкаров Google (родной immich upload этого не умеет — читает только EXIF и теряет всё, что Google хранил отдельно):

# сначала dry-run — прочитать сводку: uploaded / duplicate / unmatched / errors
immich-go upload from-google-photos --server="$IMMICH_SERVER" --api-key="$KEY" \
  --dry-run takeout-*.zip

# реальный импорт; идемпотентный — при обрыве просто повторить
immich-go upload from-google-photos --server="$IMMICH_SERVER" --api-key="$KEY" \
  --session-tag --on-errors=continue --pause-immich-jobs=true \
  --concurrent-tasks=8 --client-timeout=60m takeout-*.zip

# добрать файлы, чей JSON Google переименовал (по умолчанию они МОЛЧА пропускаются!)
immich-go upload from-google-photos --include-unmatched --session-tag \
  --server="$IMMICH_SERVER" --api-key="$KEY" takeout-*.zip

Логу immich-go верить нельзя («uploaded successfully» при недоехавших ассетах). Единственное доказательство полноты — счётчик самого Immich плюс идемпотентный повтор. У меня это выглядело так: первый прогон — 17 165 ассетов, второй добрал 51, третий — ноль новых. Ноль на повторе и есть определение «всё доехало». Итог: 17 212 ассетов (16 651 фото + 561 видео), все альбомы на месте. Сами прогоны, сверки счётчиков и повторы гонял Клод прямо на сервере — я читал отчёты; флаги в командах выше выстраданы именно так.

Отдельно — то, чего в Takeout нет вообще, и что при удалении из Google пропало бы навсегда: Locked Folder и фотографии, которые другие люди добавляли в общие альбомы. Их надо спасать руками до любой очистки (сохранить к себе → залить from-folder). У меня Locked Folder оказался пуст, а чужие фото я решил не тянуть — но проверить это надо явно, а не обнаружить постфактум.

MEGA-архив: дедуп до заливки, а не после

Второй источник — 49 ГБ неразобранного личного архива из MEGA: выгрузки со старых телефонов, свадьба друга с зеркалки, скриншоты, арт, сканы документов. Лить такое в ленту как есть — испортить её навсегда, поэтому порядок другой:

1. Перцептивный дедуп до заливки. Не по байтам — по картинке: pHash с порогом Hamming ≤ 6 ловит один и тот же кадр в разных пережатиях. 938 дублей отсеялось ещё на ноутбуке. Техническая деталь, без которой ничего не работает: перед хэшированием обязателен exif_transpose — иначе портретное фото, у которого поворот записан в EXIF, даёт расстояние 26 вместо 0 к собственной копии.

2. Сортировка по судьбе. Живые фото и видео — в ленту. Скриншоты (771), картинки/арт (240), сканы и документы (99) — в альбомы с visibility: archive: они есть, ищутся, но ленту воспоминаний не засоряют.

3. Заливка и серверный дедуп. Immich сам отбрасывает байт-идентичное (часть архива пересекалась с Takeout). Из 6 639 файлов staging новыми легли 4 875.

Итог наполнения: 22 087 ассетов, 30 альбомов, 139 ГБ. И только теперь можно говорить об очистке Google. При этом конечно все это делал ИИ, скрипты накидал, тут описан только принцип.

Очистка Google — после трёх сверок

Перед удалением — три независимые проверки, каждая ловит свой класс потерь:

• Импорт полон: повторный прогон immich-go по Takeout = 0 новых; staging MEGA = 0 новых. Всё, что есть в источниках, есть на сервере.

• Метаданные забраны: ~1,9 тыс. фото с GPS в JSON-сайдкарах ≈ столько же с GPS в Immich. Выборочно по всем годам: дата съёмки — не дата импорта, Live Photos играют, альбомы на месте.

• Корзина не больше копии: после удаления в корзине Google оказалось 17 080 объектов при 17 212 в Immich. Удалённого не может быть больше, чем сохранённого; разница объяснена (Live Photo у Google — один объект, у Immich — кадр + видео, два ассета).

Само удаление из веб-интерфейса Google Photos — отдельная песня: «выбрать всё» для большой библиотеки там не существует или я не нашел, а массовый Shift-клик в их SPA не работает — интерфейс виртуализирован и мертвеет на массовых операциях. Я поручил это Клоду — он написал скрипт-демона, который через DevTools-протокол управляет моим же залогиненным браузером и делает то же, что делал бы я: выделяет фото, жмёт «В корзину», подтверждает диалоги. Партиями по паре десятков, с человеческими паузами и джиттером, с автостопом при любом намёке на капчу и сторожем-вотчдогом сверху. Семнадцать тысяч фотографий ИИ выкликивал два дня — фоном, пока я занимался своими делами и изредка поглядывал на счётчик корзины. Кстати, о счётчике: своему демону он тоже не верил не зря — счётчик скрипта в итоге наврал, полноту очистки подтвердила только пустая библиотека плюс число объектов в корзине. Ключевое: удалённое падает в корзину Google и лежит там 60 дней — это последняя страховка, и её не трогаем до конца окна. Takeout-архивы (88 ГБ) и MEGA-исходники (27 ГБ) остаются холодной копией на своём диске навсегда — они больше не скачаются. Мне кажется Google специально сделал удаление таким сложным что бы человек забил, ИИ ~1200 раз прогонял цикл, падал и пробовал снова и цикл это много кликов.

Геолокация: вернуть то, что камера не записала

Та самая «другая история». После импорта GPS был примерно у 2 тысяч фото из 22 — остальное снято до эпохи геотегов или телефонами с выключенным GPS. А хотелось карту жизни (в immich прям можно посмотреть карту). К сожалению данные старой слежки Google удалил, я бы по времени мог геотегировать. Сначала начали без спроса следить, а потом так же без спроса удалили собранное, это одна из причин почему я решил все перевести в личное облако.

Восстанавливал слоями, от точного к грубому, и с железным правилом: фото с настоящими координатами не трогаются вообще, а каждый восстановленный геотег несёт в описании пометку об источнике и точности — «геотег по альбому», «интерполяция по времени ≤6ч», «по событию календаря». Через год я смогу отличить правду камеры от моей реконструкции одним взглядом (и скриптом — по регулярке).

• По альбомам-местам: альбомы, названные городом или страной («Город N: путешествие»), сами говорят, где сняты — фото без GPS внутри получают координаты этого места, с точностью «город» или «регион». ~1 300 фото. Такие альбомы вел Google Photo сам.

• Интерполяция по времени ≤ 6 часов: фото без GPS берёт координаты ближайшего по времени фото с настоящим GPS. Порог именно 6 часов, не сутки — перелёты: утром одна страна, вечером другая. И якорями служат только настоящие координаты плюс альбомные — интерполяция от интерполяции запрещена, иначе ошибка едет цепочкой.

• Хронология из Takeout-активности: самый неожиданный источник. «Мои действия» Google помнят каждый построенный маршрут и каждый просмотр карты с координатами прямо в URL — из этого, календаря и реальных EXIF собралась хронология в 15,6 тыс. временных якорей. По сути я восстановил где и чем занимался начиная с 2009 года, даже с учетом того, что Google слежку удалил. Для маршрутов это «в момент T я был здесь», для просмотров карт честнее «смотрел сюда» — и в пометке точности так и написано: «смотрел» ≠ «был». Прогон по хронологии дал ещё 10,8 тыс. геотегов: ~2,7 тыс. по якорям ≤ 6 ч и ~8,1 тыс. по периодам проживания — «в эти годы я жил в этом городе», city-level, с соответствующей пометкой. Перед применением — обязательная проверка: пересечение со множеством фото, у которых координаты уже есть, равно нулю (скрипт останавливается, если не так).

• Вшивание в файлы: координаты в базе Immich — это хорошо, но файл должен быть самодостаточным (следующая миграция скажет спасибо). Утилита immich-exif пишет восстановленный GPS прямо в EXIF и перезаливает файл; оригиналы уезжают в корзину Immich на 30 дней. Вшиты пока ранние слои — альбомные и интерполяция; свежий хронологический живёт в базе, его вшивание тем же механизмом у меня в списке.

Итог: GPS-покрытие с ~2 до 19,5 тыс. ассетов из 22. Карта в Immich из пары городов превратилась в маршрут жизни: переезды, командировки, отпуска. А совсем размытые слои — самые ранние годы, где даже город под вопросом, — я сознательно не применял: лучше честное «неизвестно», чем красивое враньё.

Всю эту археологию — разбор активности, сверки, скрипты с undo-списками — делал Клод по принципу «сначала отчёт, что и сколько затронет, потом моё подтверждение, потом правка».

Форк ради одной буквы: как не потерять фото при вшивании

Со вшиванием не обошлось без форка. immich-exif гоняет под капотом exiftool, и первый же прогон засыпал лог отказами — 475 штук, все на кадрах с зеркалки:

Warning: Truncated NikonScanIFD directory. IFD dropped.
Error: [minor] Bad NikonScanIFD offset for Nikon_Scan_0x002a
0 image files updated    1 files weren't updated due to errors

Разбор показал: в maker notes этих JPEG лежит фирменный под-каталог NikonScanIFD с битым смещением — наследие какого-то софта, который когда-то в жизни этих файлов неаккуратно переписал EXIF. Сам exiftool честно помечает ошибку как [minor]: данные не читаются, но они и не нужны — это метаданные древней никоновской программы, не изображение. Однако по умолчанию он отказывается записывать файл, в котором видит хоть какую-то ошибку, даже минорную. Безопасный дефолт, уважаю — но для меня он означал «сотни кадров остаются без геотега в файле навсегда», причём именно тех, ради которых всё затевалось.

У exiftool на этот случай есть штатный флаг -m (ignore minor errors): пиши, что просят, а битый мусорный под-каталог выброси. Проблема — immich-exif не умеет пробрасывать произвольные аргументы в exiftool. Пришлось форкнуть и добавить одну букву в оба вызова в src/exif/tool.go:

// чтение тегов:
cmdArgs := append([]string{"-m"}, exifArgs...)
// запись:
cmdArgs = append(cmdArgs, "-m", "-overwrite_original", "--", filePath)

Пересобрал образ — и весь класс ошибки исчез: 475 никоновских отказов превратились в ноль, финальный прогон закончился строкой Done: 451 succeeded, 0 failed. Честности ради: нашлась ещё пара файлов с другой, уже настоящей поломкой (битая ссылка на встроенное превью в IFD1) — их не спас даже -m, и я оставил их в покое: геотег у них есть в базе, а чинить чужую битую структуру EXIF ради вшивания — уже перебор. Почему это не страшно: пиксели exiftool не трогает вообще, «теряется» только под-каталог, который и так был нечитаемым мусором. Плюс механизм сам по себе страхующий: сначала dry-run с планом правок, а запись идёт через re-upload — старый файл уезжает в корзину Immich на 30 дней, так что даже неудачная запись физически не может ничего уничтожить. И да: перед тем как дать стороннему инструменту API-ключ от всего архива и право перезаливать файлы, я попросил ИИ прочитать его исходники целиком — образ у меня так и называется, immich-exif:audited. Это, кстати, новое в век ИИ, я теперь все утилитки, а так же малоизвестные контейнеры прошу ИИ по исходникам анализировать и проводить аудит на предмет утечек и безопасности, скомандовать не сложно, а безопасность внутренней инфраструктуры подтягивается выше чем не читать вовсе.

Грабли

Места, где ИИ потратил время (а однажды — чуть не потерял данные), чтобы вы не потратили.

1. Геотег до окончания metadataExtraction затирает настоящий GPS. Главная грабля, единственная, где реально пострадали данные. Залил свадьбу (зеркалка с GPS-модулем), сразу проставил альбому координаты центра города — а Immich ещё не успел дочитать EXIF. Ручной геотег победил: настоящие покадровые координаты 1041 фото затёрлись в базе. Хуже того — refresh-metadata вручную проставленное не перезаписывает: файл говорит одно, база другое, и штатного пути назад нет. Лечение — delete + повторная заливка с ожиданием, пока metadataExtraction станет idle, матчинг файлов к ассетам по checksum. Порядок навсегда: залить → дождаться метаданных → только потом геотегать.

2. Логам инструментов миграции не верить. Полнота доказывается только счётчиком принимающей стороны и идемпотентным повтором до нуля новых. Это спасло от «успешно залито» при реально недоехавших файлах.

3. pHash без exif_transpose — мусор. Портретные фото хранят поворот в EXIF; без нормализации ориентации перцептивный хэш не совпадает у файла с самим собой.

4. Live Photos считаются дважды. У Google это один объект, у Immich — кадр + видео. Пока не знаешь — счётчики «не сходятся» и полчаса паники при сверке целостности.

5. ML под non-root молча деградирует. У uid 1000 в контейнере нет HOME → кэши моделей пытаются писаться в / → нужно HOME=/cache. Named-том кэша принадлежит root → uid 1000 туда не пишет → bind-mount в свою папку. И group_add: ["993"] для render-ноды. Все три — из серии «контейнер зелёный, фичи нет».

6. Android + mTLS: две мины подряд. Первая: кнопка выбора сертификата в приложении Immich ничего не делает, пока .p12 не импортирован в системное хранилище Android (Настройки → Безопасность → Учётные данные); кнопка импорта в самом приложении выглядит рабочей, но мертва. Вторая: .p12 должен быть в legacy-формате (PBE-SHA1-3DES) — OpenSSL 3 по умолчанию пакует его в AES-256, который Android импортирует молча-неуспешно, но тут я не уверен, кажется работало и с новыми форматами, но для информации.

7. API-нюансы Immich v3, о которые бьются скрипты: поисковый search/metadata возвращает exifInfo: null (GPS брать из map/markers, полный ассет — из GET /assets/{id}); описание живёт в exifInfo.description, не на верхнем уровне; массовый PUT /api/assets помечен deprecated, но он единственный рабочий способ bulk-правок — поэтому версия в .env держится на мажорном канале v3 (не release), а обновление — осознанный шаг с дампом БД, а не автопул.

8. Тяжёлые операции — на сервере, не через туннель с ноутбука. Заливка десятков гигабайт через хрупкий туннель (сон ноутбука, обрыв Wi-Fi) виснет и рвётся. Всё тяжёлое гонится на самом CT против localhost. И рабочие файлы скриптов — не в /tmp: это tmpfs, ребут стирает (проверено на себе).

Что в итоге

• Свой Google Photos. Immich с лентой, альбомами, картой, поиском «закат на море» (не проверял) и лицами (проверял) — на домашнем сервере, ML на интегрированной видеокарте мини-ПК. Переживает ребут без рук.

• 22 087 ассетов из двух источников — Google Photos и многолетний MEGA-хлам — слиты, дедуплицированы и разобраны: живое в ленте, скриншоты и сканы в архивных альбомах.

• Ни одного потерянного кадра, и это доказано, а не «вроде всё скопировалось»: идемпотентные прогоны до нуля новых, сверка метаданных, корзина ≤ копии. Google очищен только после всех трёх проверок, страховки (корзина 60 дней, Takeout, MEGA-исходники, дампы БД, RAID, снапшоты) живут до сих пор.

• География восстановлена честно: GPS-покрытие с 2 до 19,5 тысяч фото, каждый восстановленный геотег помечен источником и точностью, настоящие координаты не тронуты, ранние слои уже вшиты в сами файлы.

• Снаружи сервера не существует. Только :443 с обязательным клиентским сертификатом; у телефона — узкий API-хост без админки. Внутри всё под обычным пользователем в unprivileged-контейнере.

Рутину — скрипты дедупа, разбор Takeout-активности, сверки, массовое удаление из Google — делал ИИ; решения «что удаляем, что геотегаем, где порог» оставались за мной, и перед каждой правкой я получал отчёт, что именно она затронет. Для музыки такой режим был удобством — для фотографий он обязателен: это единственные данные, которые не скачаешь заново, хотя сам архив я конечно все равно сохранил в исходном виде навсегда.

P.S. В итоге я перенес музыку домой и фото из хранилища гугла домой, а после этого получил письмо от гугла, что по новым правилам все данные бэкапов и прочего теперь будут занимать место в хранилище. Они этим должны были спровоцировать меня подписку дороже купить, но у меня в хранилище теперь занято на самой мелкой подписке меньше трети и я обдумываю, а не выкинуть ли мне подписку вовсе. Особо обидно, что они за мной следили годами, а когда надо стало мне оказалось, что все удалили без спроса.

Это руководство для того, кто решил поднять всё сам. От пустого LXC-контейнера до работающего стека: свой стриминг, поиск и скачивание музыки с телефона, приватность через VPN и рекомендации «по звуку». Разбираем каждый из двенадцати сервисов — что ставим, зачем и как настроить.

С чего всё началось

YouTube Music я использую довольно давно и с подпиской, полез чистить «Понравившееся» — а часть треков оттуда просто исчезла: где-то удалили клип, где-то канал в бане, где-то правообладатель передумал. Плейлист, который я собирал годами, тихо усыхал, и меня не спросили. Причем у меня есть подписка. Ну и обойдусь.

Заменить стриминг «включил — играет любой трек мира» самохостинг не может, каталог из десятков миллионов треков дома не поднять. Задача другая — забрать под контроль то, что реально ценно: свою коллекцию, свою курацию и механику «услышал → добавил → получил похожее» в пару кликов. Ну и, конечно, мы не пираты.

Чего мы хотим

Я не слежу за артистами и не качаю дискографии — мне нужно, чтобы играла моя коллекция, чтобы услышанный трек добавлялся одной кнопкой, и чтобы система подсовывала похожее. Отсюда цели:

1. Своя коллекция на своём диске. Ядро — самохостовый аудио-сервер (Navidrome, протокол OpenSubsonic): стриминг, плейлисты, рейтинги. Файлы у меня и не исчезают от чужих решений.

2. Поиск и добавление трека с телефона. Услышал — за пару тапов в коллекции, теггировано и разложено. Без «подойди к ноутбуку, запусти Х».

3. Приватность, домашний IP не светится. Всё внешнее приобретение — через VPN с fail-closed killswitch. Soulseek (P2P-раздача — главный DMCA-вектор) живёт целиком внутри сетевого namespace VPN.

4. Перенос курации. Годы лайков, рейтингов, плейлистов и «мёртвые» треки (те, что Google уже удалил) — не потерять, а перенести в нативные механизмы Navidrome.

5. Sonic-рекомендации. Локальный анализ звука («дай похожее на этот трек») плюс weekly-рекомендации по вкусу для открытия нового.

6. В сумме — замена YTM. На телефоне один клиент (Symfonium под Android), в нём моя музыка, лайки, поиск-добавление и радио. Zero-subscription — ни одной активной подписки.

Архитектура

Одна мысль, из которой растёт весь стек:

Navidrome читает каталог /music и строит библиотеку по тегам внутри файлов. SoulSync — это то, что /music наполняет. Остальное — обвязка вокруг этих двух ролей.

Держа это в голове, двенадцать контейнеров складываются в понятную трубу источники → SoulSync → /music → Navidrome → телефон. Ядро — ровно два сервиса; прочие десять — либо приватность, либо «умные» фичи, либо клей.

      ТЕЛЕФОН — Symfonium + клиентский серт .p12
                     │ HTTPS :443, mTLS-гейт (нет серта → connection refused)
                     ▼
   edge-Caddy:  tls { client_auth trust music-CA }   nvd.example.com
                     │ reverse_proxy → внутренний caddy (Host сохраняется)
   ══════ LXC «music» (unprivileged, Docker) ══════
                     ▼
   caddy (внутренний ingress :80) — Host-роутинг локальных UI
                     ▼
   navidrome :4533  ◄── плагин audiomuseai.ndp (sonicSimilarity)
   ЧИТАЕТ /music ПО ТЕГАМ           ▲ анализ звука
        ▲                    audiomuse ×4 (flask+worker+postgres+redis)
        │ читает /music (ro)
        │ ПИШЕТ (file_organization=ON)
   SoulSync :8008 (+ PWA на телефон)
        │ всё внешнее — через VPN
        ▼
   gluetun (WireGuard-VPN, killswitch fail-closed)
     ├─ HTTP-прокси :8888 ← YouTube/Deezer
     └─ netns: slskd (Soulseek P2P), prowlarr+qbit (торренты, opt-in)
     egress = VPN. Домашний/VPS IP наружу не светится.

   explo — раз в неделю пишет плейлист-рекомендацию в Navidrome

Со схемы важно прочитать две вещи. Первое: телефон ходит только К Navidrome, «сверху вниз» — у VPN нет входящего, приватность телефонного трафика держит mTLS на edge, а VPN закрывает исходящий трафик качалок. Второе: /music — одна физическая папка (bind-mount), в которую SoulSync пишет, а Navidrome читает; никакого копирования, никакого промежуточного каталога. Про mTLS важно отметить, что это Caddy reverse proxy и в моих прошлых статьях описано, что это самый край домашней инфры, торчащий в интернет, второй Caddy из текста ниже, это внутри LXC просто для удобства. Внешний Caddy заставить просить mTLS мне нужно было потому, что дырявым музыкальным веб-серверам я не доверяю, а проигрыватель Symfonium как раз поддерживает аутентификацию по сертификату и делает это более надежный Caddy. Не забудьте только в телефон сертификат установить, на андроиде, в настройках. Расписывать как сгенерировать сертификат и установить я не буду, разберетесь. Тогда какие бы дырявые ни были музыкальные сервисы, защищает их внешний reverse proxy.

Установка

Шаг 0. LXC — то, что делается только с хоста

Стек живёт в отдельном unprivileged-LXC. Gluetun нужен туннельный интерфейс, который LXC по умолчанию не отдаёт:

# на хосте Proxmox, под root (117 — номер вашего CT)
pct set 117 --dev0 /dev/net/tun

Дальше всё внутри контейнера и под обычным пользователем (у меня user, uid 1000) — root понадобится только для установки docker и systemd-юнита автозапуска. Это осознанное решение: чем меньше крутится под root, тем меньше поверхность, если один из образов окажется недобросовестным.

Шаг 1. Каталоги — одно дерево, один владелец

# внутри CT, под обычным пользователем
mkdir -p ~/music-app/{navidrome/plugins,soulsync/{config,logs},slskd,prowlarr,qbit,caddy}
mkdir -p ~/music-app/audiomuse/{pgdata,redis-data,temp-flask,temp-worker,plugins-flask,plugins-worker}
mkdir -p ~/music-app/explo/config
mkdir -p ~/music-app/data/{media/music,soulseek/downloads,torrents}
cd ~/music-app

data/media/music — это и есть тот самый /music, единственная папка с музыкой. Всё дерево принадлежит uid 1000; за этим стоит следить (см. грабли про root-owned каталоги).

Шаг 2. Секреты — .env с chmod 600

Пароли и ключи генерируем на месте и держим только в .env, не в compose и не в образах:

{
  echo "TZ=Europe/Amsterdam"
  echo "PUID=1000"; echo "PGID=1000"; echo "UMASK=002"
  echo "AM_DB_PASSWORD=$(openssl rand -hex 24)"          # Postgres AudioMuse
  echo "ND_PASSWORDENCRYPTIONKEY=$(openssl rand -hex 24)" # шифрование паролей Navidrome
  echo "SLSK_USER=music-$(openssl rand -hex 4)"           # Soulseek-аккаунт заводится первым логином
  echo "SLSK_PASS=$(openssl rand -hex 16)"
  echo "EXPLO_UI_PASSWORD=$(openssl rand -hex 8)"
} >> .env
chmod 600 .env

Отдельно — приватный ключ WireGuard от вашего VPN-провайдера. Его вставляем через невидимый ввод, чтобы он не попал ни на экран, ни в history:

read -rs WGKEY
printf 'WG_PRIVATE_KEY=%s\n' "$WGKEY" >> .env

Шаг 3. docker-compose.yml — весь стек

Здесь есть одна сетевая ловушка, на которой легко потерять полдня. Контейнеры за network_mode: service:gluetun наследуют DNS gluetun и перестают резолвить docker-имена — SoulSync теряет связь с navidrome и slskd. Поэтому в туннель VPN мы сажаем только качалки (slskd, prowlarr, qbit), а SoulSync живёт в обычной сети (docker-DNS работает) и гонит наружу через HTTP-прокси gluetun. Ниже это уже учтено.

name: music

networks:
  default:
    name: music
    ipam:
      config:
        - subnet: 172.28.0.0/24   # фиксируем подсеть, чтобы не пересечься с диапазоном VPN

x-env: &common-env
  TZ: ${TZ}
  PUID: ${PUID}
  PGID: ${PGID}
  UMASK: ${UMASK}

services:
  # ── музыкальный сервер (наружу через edge-Caddy с mTLS) ──
  navidrome:
    image: deluan/navidrome:0.63.2
    container_name: navidrome
    user: "1000:1000"
    environment:
      ND_SCANSCHEDULE: 1h
      ND_PLUGINS_ENABLED: "true"           # нужно для плагина AudioMuse
      ND_PLUGINS_AUTORELOAD: "true"
      ND_AGENTS: "audiomuseai,deezer"      # audiomuseai первым — sonic-похожесть
      ND_DEVARTISTINFOTIMETOLIVE: "1s"     # не отдавать similar/radio из кэша
      ND_PASSWORDENCRYPTIONKEY: ${ND_PASSWORDENCRYPTIONKEY}
      TZ: ${TZ}
    volumes:
      - ./navidrome:/data
      - ./data/media/music:/music:ro       # библиотека — только на чтение
    restart: unless-stopped

  # ── AudioMuse-AI: sonic-анализ (flask + worker + postgres + redis) ──
  audiomuse:
    image: ghcr.io/neptunehub/audiomuse-ai:2.6.2
    container_name: audiomuse-ai-flask-app
    user: "1000:1000"
    environment: &am-env
      SERVICE_TYPE: "flask"
      POSTGRES_HOST: audiomuse-db
      POSTGRES_USER: audiomuse
      POSTGRES_PASSWORD: ${AM_DB_PASSWORD}
      POSTGRES_DB: audiomusedb
      REDIS_URL: redis://audiomuse-redis:6379/0
      TEMP_DIR: /app/temp_audio
      TZ: ${TZ}
    volumes:
      - ./audiomuse/temp-flask:/app/temp_audio
      - ./audiomuse/plugins-flask:/app/plugin/installed
    depends_on: [audiomuse-db, audiomuse-redis]
    restart: unless-stopped

  audiomuse-worker:
    image: ghcr.io/neptunehub/audiomuse-ai:2.6.2
    container_name: audiomuse-ai-worker
    user: "1000:1000"
    environment:
      <<: *am-env
      SERVICE_TYPE: "worker"
    volumes:
      - ./audiomuse/temp-worker:/app/temp_audio
      - ./audiomuse/plugins-worker:/app/plugin/installed
      - ./data/media/music:/music:ro       # воркер читает аудио для анализа
    depends_on: [audiomuse-db, audiomuse-redis]
    cpus: "4.0"                             # анализ тяжёлый — ограничиваем, чтобы не душить соседей на хосте
    mem_limit: 4g
    restart: unless-stopped

  audiomuse-redis:
    image: redis:7-alpine
    container_name: audiomuse-redis
    user: "1000:1000"
    volumes: [./audiomuse/redis-data:/data]
    restart: unless-stopped

  audiomuse-db:
    image: postgres:15-alpine
    container_name: audiomuse-db
    user: "1000:1000"
    command: ["postgres", "-c", "unix_socket_directories=/tmp"]
    environment:
      POSTGRES_USER: audiomuse
      POSTGRES_PASSWORD: ${AM_DB_PASSWORD}
      POSTGRES_DB: audiomusedb
    volumes: [./audiomuse/pgdata:/var/lib/postgresql/data]
    restart: unless-stopped

  # ── VPN-шлюз: WireGuard + killswitch ──
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add: [NET_ADMIN]
    devices: ["/dev/net/tun:/dev/net/tun"]
    ports:
      - "5030:5030"   # slskd Web UI
      - "8080:8080"   # qBittorrent (профиль torrents)
      - "9696:9696"   # Prowlarr    (профиль torrents)
    environment:
      VPN_SERVICE_PROVIDER: nordvpn        # ваш провайдер
      VPN_TYPE: wireguard
      WIREGUARD_PRIVATE_KEY: ${WG_PRIVATE_KEY}
      SERVER_COUNTRIES: Switzerland        # DMCA-safe юрисдикция
      SERVER_CATEGORIES: P2P
      FIREWALL: "on"                       # killswitch fail-closed: туннель упал → трафик дропается
      HTTPPROXY: "on"                      # :8888 для HTTP-качалок (SoulSync)
      TZ: ${TZ}
    restart: unless-stopped

  # ── Soulseek-демон (целиком в туннеле VPN) ──
  slskd:
    image: slskd/slskd:latest
    container_name: slskd
    user: "1000:1000"
    network_mode: "service:gluetun"
    depends_on:
      gluetun: { condition: service_healthy }
    environment:
      SLSKD_SLSK_USERNAME: ${SLSK_USER}
      SLSKD_SLSK_PASSWORD: ${SLSK_PASS}
      SLSKD_SLSK_LISTEN_PORT: "50300"      # входящий порт для раздачи (иначе uploads=0)
      TZ: ${TZ}
    volumes:
      - ./slskd:/app
      - ./data:/data
    restart: unless-stopped

  # ── SoulSync: поиск+скачивание (наружу через edge-Caddy) ──
  soulsync:
    image: boulderbadgedad/soulsync:3.0.1  # конкретный тег, НЕ latest (проект очень активен — см. грабли)
    container_name: soulsync-webui
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=022
      - TZ=${TZ}
      - HTTP_PROXY=http://gluetun:8888     # внешнее (YouTube/Deezer) → VPN
      - HTTPS_PROXY=http://gluetun:8888
      - NO_PROXY=localhost,127.0.0.1,navidrome,gluetun,slskd.music,caddy,172.28.0.0/16,.music # внутреннее → напрямую; gluetun обязателен — иначе запросы к Prowlarr/qBit уйдут в прокси
    volumes:
      - ./soulsync/config:/app/config
      - ./soulsync/logs:/app/logs
      - ./data/soulseek/downloads:/app/downloads
      - ./data/media/music:/app/Transfer   # SoulSync пишет ПРЯМО в /music
      - ./data/torrents:/data/torrents
      - soulsync_database:/app/data
    depends_on: [slskd]
    restart: unless-stopped

  # ── Торренты (опционально, профиль torrents; в туннеле VPN) ──
  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    profiles: ["torrents"]
    network_mode: "service:gluetun"
    depends_on: { gluetun: { condition: service_healthy } }
    environment: *common-env
    volumes: [./prowlarr:/config]
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    profiles: ["torrents"]
    network_mode: "service:gluetun"
    depends_on: { gluetun: { condition: service_healthy } }
    environment:
      <<: *common-env
      WEBUI_PORT: "8080"
    volumes:
      - ./qbit:/config
      - ./data:/data
    restart: unless-stopped

  # ── Explo: weekly-рекомендации ListenBrainz → плейлист ──
  explo:
    image: ghcr.io/lumepart/explo:latest
    container_name: explo
    user: "1000:1000"
    environment:
      TZ: ${TZ}
      WEB_UI: "true"
      UI_USERNAME: admin
      UI_PASSWORD: ${EXPLO_UI_PASSWORD}
      HTTP_PROXY: http://gluetun:8888
      HTTPS_PROXY: http://gluetun:8888
      NO_PROXY: localhost,127.0.0.1,navidrome,gluetun,slskd.music,caddy,172.28.0.0/16,.music
    volumes:
      - ./explo/config:/opt/explo/config
      - ./data/media/music/Explo:/data/
      - ./data/soulseek/downloads:/slskd/
    depends_on:
      gluetun: { condition: service_healthy }
      navidrome: { condition: service_started }
    restart: unless-stopped

  # ── внутренний reverse-proxy (Host-роутинг локальных UI) ──
  caddy:
    image: caddy:2-alpine
    container_name: caddy
    user: "1000:1000"
    cap_add: [NET_BIND_SERVICE]
    ports: ["80:80"]
    volumes: [./caddy/Caddyfile:/etc/caddy/Caddyfile:ro]
    depends_on: { gluetun: { condition: service_healthy } }
    restart: unless-stopped
    networks:
      default:
        aliases: [nvd.music, ss.music, slskd.music, audiomuse.music]

volumes:
  soulsync_database:

Шаг 4. Внутренний Caddy — маршрутизация локальных UI

Внутренний caddy отдаёт веб-морды сервисов по внутренним именам (снаружи их закрывает edge-Caddy с mTLS). Минимальный caddy/Caddyfile:

nvd.example.com       { reverse_proxy navidrome:4533 }
ss.example.com        { reverse_proxy soulsync-webui:8008 }
audiomuse.example.com { reverse_proxy audiomuse-ai-flask-app:8000 }
slskd.example.com     { reverse_proxy gluetun:5030 }

Наружу эти хосты проксирует ваша edge-нода, добавляя mTLS (клиентский сертификат). Как устроен edge-слой с mTLS — тема отдельная; здесь важно, что телефон ходит на nvd.example.com за сертификатом, а всё остальное недоступно снаружи вовсе.

Шаг 5. Запуск и проверка, что VPN держит

docker compose up -d                      # ядро
docker compose --profile torrents up -d   # плюс торренты, если нужны

Прежде чем что-то качать — убедимся, что качалки реально ходят через VPN, а не мимо. Спрашиваем публичный IP изнутри туннеля (из контейнера, который в netns gluetun):

docker exec qbittorrent sh -c 'wget -qO- https://ipinfo.io/ip'
# → адрес вашего VPN-сервера. С реальным IP хоста совпасть НЕ должен.

Это принципиально: спросив IP с хоста, вы увидите egress хоста и ничего не поймёте. Проверять надо именно из namespace VPN. Убьёте туннель (docker stop gluetun) — у slskd/qbit пропадёт сеть целиком: killswitch fail-closed, утечь нечему.

Шаг 6. Автозапуск после ребута

Чтобы стек поднимался сам, вешаем на хост CT systemd-юнит:

# /etc/systemd/system/music-app.service  (под root)
[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/home/<user>/music-app
ExecStart=/usr/bin/docker compose --profile torrents up -d
User=<user>
[Install]
WantedBy=multi-user.target

systemctl enable --now music-app. Вместе с restart: unless-stopped на контейнерах и onboot=1 на самом LXC — три уровня «поднимись сам», потому что за «после ребута ничего не играет» никто не любит просыпаться.

Настройка сервисов

Compose поднял контейнеры — теперь пройдёмся по веб-мордам и включим то, что не задаётся через окружение. Никаких ручных запросов к API: всё это тумблеры и поля в интерфейсах (но я это почти все не нажимал, только юзеров создавал, я попросил клода и он через API все сам нажал, рекомендую, а потом я его же попросил написать кнопки в текст статьи, они примерные).

Navidrome (nvd.example.com). При первом входе создаём администратора. Библиотека уже примонтирована (/music), скан идёт по расписанию. Для sonic-похожести нужен плагин AudioMuse: кладём файл audiomuseai.ndp в navidrome/plugins/ и в его настройках указываем адрес AudioMuse (http://audiomuse-ai-flask-app:8000). В compose агент уже включён первым (ND_AGENTS=audiomuseai,deezer) — этого достаточно, чтобы Navidrome начал отдавать «похожие треки».

Soulseek (slskd.example.com). Аккаунт Soulseek заводится сам фактом первого логина с логином/паролем из .env. Проверяем, что демон подключился и что открыт порт раздачи — без входящего порта вы только качаете, но не раздаёте, а на Soulseek это влияет на репутацию.

SoulSync (ss.example.com) — центральный пульт. Здесь всё через интерфейс:

• Источники. Включаем нужные: Soulseek (подхватывается автоматически), YouTube (работает из коробки, качает через VPN-прокси). Для торрентов в настройках указываем адреса нашего Prowlarr и qBittorrent — SoulSync будет искать и там.

• Профиль качества. Ставим режим best_quality (пулит кандидатов со всех источников и берёт лучший по факту, а не первый), cutoff — FLAC 16-bit, и включаем replace lower quality (замена файла на лучший на месте).

• Обслуживание библиотеки (repair-джобы). Включаем те, что чинят метадату скачанного: Unknown Artist Fixer, Metadata Gap Filler (дотягивает MBID из MusicBrainz), Fake Lossless Detector (спектрально ловит псевдо-FLAC), Quality Upgrade (движок апгрейда до FLAC). Про важный нюанс их применения — в разделе «как работает».

• Раскладка. Включаем file organization (Артист/Альбом/Трек) и отмечаем /music как постоянную библиотеку — тогда SoulSync пишет прямо в неё и не пытается растащить уже разложенное.

• Телефон. SoulSync — это PWA: открываем ss.example.com в мобильном браузере и добавляем на домашний экран. Дальше поиск и скачивание — прямо из кармана. Интерфейс там так себе, но привыкнуть можно, а мне надо раз в месяц.

AudioMuse (audiomuse.example.com). Проходим setup-wizard (указываем Navidrome и креды), запускаем первичный анализ библиотеки — воркер посчитает звуковые эмбеддинги, это разово и небыстро. Похожесть работает только по проанализированным трекам, так что дайте анализу закончиться. Чтобы плейлисты обновлялись сами — на странице Cron заводим две ночные задачи: analysis (проанализировать новьё) и clustering (пересобрать sonic-плейлисты и записать их прямо в Navidrome). После этого никаких действий от вас не требуется — плейлисты появляются в Symfonium как обычные.

Explo. Указываем токен ListenBrainz, задаём расписание — раз в неделю он собирает рекомендацию «по вкусу» и кладёт плейлистом в Navidrome.

Повторю, я только в navidrome пользователя создал и попросил нейронку все через API сервисов настроить, она сама все и настроила за пару итерация проверок, что работает.

Как это работает

SoulSync: от «услышал» до «играет»

Вы ищете трек в PWA, SoulSync опрашивает источники и в режиме best_quality берёт лучшую версию, скачивает её, тегирует и раскладывает в Артист/Альбом/Трек прямо в /music. Через минуту Navidrome его проиндексировал — и он играет в наушниках.

Тонкость, которую стоит знать: у SoulSync два пути добавления. Основной, через поиск-и-подтверждение в интерфейсе, приносит трек с полными тегами, обложкой и текстом. Есть и «сырой» путь (скачать по прямой ссылке) — он кладёт файл без обогащения, плоско. Спасает то, что Navidrome браузит по тегам, а не по папкам: даже плоский-но-тегированный файл виден в библиотеке правильно, а безтеговые дочищают repair-джобы поиском по названию (джобы в soulsync многое могут).

Источники под капотом: YouTube и торрентная связка

YouTube — источник «по умолчанию», настройки не требует вовсе. SoulSync ищет прямо по YouTube, качает лучшую аудиодорожку (на выходе .opus, обычно ~130–140 kbps) и весь этот трафик гонит через HTTP-прокси gluetun — в compose выше это уже задано переменными HTTP_PROXY/HTTPS_PROXY, со своего IP SoulSync наружу не ходит. Дальше обычный конвейер: теги и обложка из метадата-источника, раскладка в /music. Полезная деталь — встроенная проверка целостности: длительность скачанного сверяется с ожидаемой (допуск порядка 15 секунд), и «не то» отбрасывается. Это спасает от классической подставы YouTube-поиска, когда вместо студийной версии прилетает лайв, ремикс или десятиминутный «full album» — я на этом допуске живьём видел, как отсеялся файл с дрейфом в 31 секунду: пришла другая редакция трека, и система её честно не взяла.

По качеству без иллюзий: opus с YouTube — это пол, а не потолок. Тут у SoulSync два поведения, и их стоит различать. Простое «скачай сейчас» идёт по цепочке приоритетов источников — это настройка, у меня youtube → soulseek → torrent (YouTube первым: отвечает быстрее всех, для «услышал — добавил» это то, что нужно). А вот автодобор — wishlist, апгрейд качества — собирает кандидатов со всех включённых источников разом и берёт лучшего по качеству: нашёлся FLAC на Soulseek или торрентах — возьмёт его, не нашёлся — YouTube закроет дырку хоть чем-то. Поэтому Soulseek стоит держать включённым, даже если кажется, что «всё равно всё едет с ютуба».

Торренты — это профиль torrents из compose и связка трёх ролей: Prowlarr — «адресная книга» трекеров, qBittorrent — качалка, SoulSync — заказчик. Первая пара живёт в сетевом namespace gluetun (network_mode: service:gluetun), и отсюда неочевидное следствие: у этих контейнеров нет собственного сетевого имени, их веб-морды и API видны по имени VPN-шлюза. То есть в интеграциях указывается не prowlarr:9696, а http://gluetun:9696 и http://gluetun:8080 — это второе после docker-DNS место (грабля №1), где namespace ломает интуицию, закладывайте.

Настройка руками (или инструктажем ИИ — все три пункта делаются через их API):

1. Prowlarr (:9696). Добавляем индексаторы: открытые трекеры заводятся логином/паролем — Prowlarr сам логинится и держит сессию; полузакрытые — пасскеем из профиля на трекере. Тут же берём Settings → General → API Key, он понадобится SoulSync.

2. qBittorrent (:8080). Здесь ровно одно действие: задать постоянный пароль (грабля №4: временный слетает на рестарте — и интеграция молча отваливается). Каталог загрузок в самом qBit настраивать не нужно — SoulSync передаёт свой save_path с каждой раздачей; важно лишь, чтобы у обоих контейнеров был примонтирован один и тот же ./data (в compose выше так и есть).

3. SoulSync → Settings: адрес Prowlarr + его API key, адрес qBittorrent + логин/пароль (оба адреса — через gluetun:, см. выше), путь загрузок /data/torrents и категория (у меня soulsync — по ней закачки SoulSync отличимы от всего остального в qBit). Тест-кнопки должны позеленеть.

Как идёт закачка целиком: SoulSync спрашивает Prowlarr → тот веером опрашивает все заведённые трекеры и возвращает раздачи с сидами → SoulSync выбирает подходящую и отдаёт её qBittorrent с категорией soulsync и путём /data/torrents → qBit качает через туннель → SoulSync видит завершение, вынимает из раздачи нужные файлы, тегирует и раскладывает в /music. Раздачу, которая не двигается (нулевые сиды), SoulSync бросает по stall-таймауту — у меня 10 минут, — так что мёртвые торренты не висят в очереди вечно. Специфика музыкальных торрентов, о которую спотыкаешься сразу: раздача — почти всегда альбом или дискография, а не отдельный трек. Для «услышал — добавил» этот канал избыточен (там отрабатывают Soulseek и YouTube), зато для FLAC-альбомов и редкого русского каталога он основной — тот самый добор «мёртвых» из главы про миграцию ехал именно здесь.

Проверить, что цепочка жива, можно одним запросом к Prowlarr, не тыкая интерфейсы (3000 — категория «музыка»):

curl -s -H "X-Api-Key: $PROWLARR_KEY" \
  'http://localhost:9696/api/v1/search?query=<артист>&categories=3000'
# → JSON с релизами и числом сидов. Релизы пришли — трекеры отвечают, дальше дело qBit.

FLAC-апгрейд на месте

Quality Upgrade — это движок повышения качества. Раз в неделю он читает каждый файл, сравнивает с профилем (cutoff = FLAC), для трека ниже профиля ищет лучшую версию и показывает находку. Подтверждаете — трек качается из общего пула источников, и включённый replace lower quality заменяет старый файл по тому же пути; Navidrome пересканирует, дублей нет.

Важно, почему это ручное подтверждение, а не автомат: AcoustID и матчинг по названию регулярно путают каверы, лайв и ремиксы. Живой пример из практики — «Die Antwoord — Baby’s on Fire» опознаётся по звуку как «Goat». Автозамена «на похожее» тихо угробит библиотеку неправильными версиями. Поэтому машина ищет — человек подтверждает. Тот же принцип у всех джобов, которые могут подменить файл: они по умолчанию только показывают находки, применяете вы.

Но и тут я просто попросил ИИ через API все самому разгрести, а то там поначалу были какие-то тысячи находок. Сам я пару песен искал, нашел, которые нужны были и скачал, а все разгребание это puthon скрипты, которые ИИ себе написал и сам все сделал. Тратить на такую ерунду жизнь смысла нет больше.

Sonic-рекомендации на телефоне

AudioMuse анализирует звук (Essentia + CLAP-эмбеддинги), а не теги, — поэтому находит похожее даже для обскура, которого нет ни в одной метадата-базе. Плагин audiomuseai.ndp добавляет Navidrome стандартное OpenSubsonic-расширение sonic-похожести, и оно уезжает на телефон.

В Symfonium это оживает как Radio Mix «похожее по звуку» — в настройках клиента включается опция использовать серверную похожесть для радио (иначе радио крутит по артисту, а не по звуку). А вот «умные потоки» Smart Flow (режимы вроде Echo Match) для Subsonic-сервера требуют более свежей версии Symfonium — там завезли поддержку нужного расширения; на более старой они серые. Сервер отдаёт всё — упирается в клиент. Ставьте бэту 15.0 и будет работать.

Второй слой рекомендаций — Explo с ListenBrainz — работает по другой оси: не «похожее по звуку из того, что есть», а «чего у тебя нет» по коллаборативному вкусу. Но я пока проверил, что прослушанное правда уезжает в ListenBraiz, рекомендации оно вроде как генерит раз в неделю, проверю еще.

Удаление трека с телефона

Symfonium не умеет слать серверу команду «удали». Обходим просто: заводим на сервере плейлист «Удалить», а на хосте — таймер, который раз в 10 минут переносит помеченные треки в корзину (обратимо, с манифестом). Кинул трек в плейлист с телефона — через несколько минут он уехал из библиотеки, но не пропал безвозвратно. Скрипт тоже написал ИИ, я проверил, что работает.

Миграция и добор «мёртвых» треков

Отдельный сюжет — как перетащить коллекцию из YTM и вернуть удалённое. Из моей миграции осталось 487 «мёртвых» треков — тех, что Google уже удалил (unavailable/copyright), преимущественно русское и нишевое. Первое, что нужно сделать, — зафиксировать их намертво списком (videoId, артист, название), пока не потерялись окончательно; этот список потом не трогаем.

Soulseek по такому нишевому вывозит процентов двадцать, поэтому основным каналом добора стали торренты — открытые и полу-закрытые трекеры через тот же Prowlarr+qBit под VPN. Тонкость русских трекеров: они индексят дискографиями, а не треками, поэтому искать надо по артисту, тянуть архив, вынимать из него нужные треки по совпадению имени файла и удалять балласт — диск не резиновый.

Часть «мёртвых» была голыми videoId без названия. Их можно опознать через публичный YouTube oEmbed — он отдаёт автора и заголовок ролика без единой куки, по одному videoId. То, чего не нашлось на торрентах, добирается YouTube-альтернативами через SoulSync. В сумме у меня вернулось около 372 из 487.

Дальше чистка. Скачанное с YouTube приходит без тегов, и [Unknown Artist] быстро расплодился. Чинить это надо по звуку: AcoustID-фингерпринт опознаёт запись по фактическому содержимому файла, а не по кривому заголовку вида «ARTIST - Title (Official Video) [4K]» — матчинг по такому заголовку ушёл бы не туда. Плюс дедуп по фингерпринту (один трек в разных качествах → оставить лучшее). Честный потолок: то, чего нет ни во FLAC, ни в альтернативной заливке нигде, останется в opus или потеряется — самохостинг не печатает записи, которых не существует.

Главное конечно, а где все это взять? Плейлисты то где? Это в takeout google. Я там достал не только плейлисты, но и всю свою активность начиная с 2009 года, по которой восстановил где и чем я занимался вплоть до дней, включая геолокацию с точностью до города, но это другая история. По активности можно достать и что я слушал, потому, что в плейлистах Гугла останется только то, что он не удалил, а в активности есть все. Я просто попросил ИИ провести анализ и он нарыл ~600 треков из плейлистов и ~2500 треков по косвенным данным активности на “сайте гугла”, а на деле YTM YT.

Плейлисты из Google Takeout — по шагам

Takeout — это исходник, но из коробки он даёт не плейлисты, а сырьё. Покажу конкретно, как превратить его в рабочие плейлисты в своём стеке, на тех же ручках, что и всё остальное. Сам я это, понятно, руками не собирал: скинул ИИ папку выгрузки и задачу, он написал пачку python-скриптов и прогнал их через API SoulSync и Navidrome прямо в контейнере. Ниже — механика, чтобы повторить (или чтобы отдать этот раздел своему Клоду и не объяснять на пальцах).

Что внутри Takeout. Заказываете выгрузку «YouTube and YouTube Music». Плейлисты лежат в Takeout/YouTube and YouTube Music/playlists/ — по одному CSV на плейлист (лайки — отдельным файлом). Нюанс, который экономит полдня недоумения: в CSV только videoId и метка времени, без названий. Гугл отдаёт голые идентификаторы, названия достаём сами. И то же, что уже сказано выше про мёртвых: в плейлистах Takeout остаётся лишь то, что Гугл ещё не удалил; полную картину «что я вообще слушал» даёт Takeout/My Activity/YouTube/ (там сразу с заголовками), но это шумный источник — туда падает вообще всё.

Шаг 1. videoId → артист и название. По голому id тянем метаданные публичным YouTube oEmbed — без единой куки, по одному id:

curl -s 'https://www.youtube.com/oembed?url=https://youtu.be/<videoId>&format=json'
# → {"title":"...","author_name":"Аквариум - Topic", ...}

Канал вида «Артист - Topic» — официальная музыкальная заливка, author_name из него даёт чистого артиста; для обычных каналов заголовок парсим по «Артист — Название». oEmbed вернул 404 — трек Гугл удалил, это «мёртвый» на добор с торрентов (см. выше).

Шаг 2. Разделяем: что уже в библиотеке, что добирать. Для каждой пары (артист, название) спрашиваем Navidrome субсоник-поиском, есть ли трек. Токен субсоника — md5(пароль + соль), считаем его локально, наружу уходит только хеш, не пароль:

curl -s -H 'Host: nvd.music' \
  'http://localhost/rest/search3?query=Аквариум+Город+золотой&u=<user>&t=<md5>&s=<salt>&v=1.16.1&c=cc&f=json'
# song[].id в выдаче → трек в библиотеке; пусто → в добор

song.id из выдачи — это и есть идентификатор для плейлиста.

Шаг 3. Недостающее — в добор через SoulSync. Прогоняем через тот же движок, что наполняет всю библиотеку: сперва резолвим кандидата на Deezer (нужны точные длительность и альбом — страховка от «не той версии»), кладём в wishlist полной карточкой, запускаем обработку. SoulSync качает в лучшем качестве и раскладывает в /music:

# найти кандидата на Deezer (ручка SoulSync, ключ не нужен)
curl -s -H 'Host: ss.music' --data-urlencode 'query=Аквариум Город золотой' \
  -G 'http://localhost/api/deezer/search_tracks'
# → tracks[].id / name / artists / duration_ms

# положить в wishlist полной карточкой (id, имя, артист, альбом, длительность)
# $SS_KEY — разовый ключ SoulSync API из его настроек
curl -s -H 'Host: ss.music' -H "Authorization: Bearer $SS_KEY" \
  -H 'Content-Type: application/json' -X POST 'http://localhost/api/v1/wishlist' \
  -d '{"track_data":{"id":"deezer_123","name":"Город золотой","artists":[{"name":"Аквариум"}],"album":{"name":"…"},"duration_ms":222000},"source_type":"manual"}'

# запустить обработку (авто-обработка wishlist и так висит по расписанию, но можно пнуть)
curl -s -H 'Host: ss.music' -H "Authorization: Bearer $SS_KEY" -X POST \
  'http://localhost/api/v1/wishlist/process'

Место, где легко налажать на пакетном доборе, — сверка длительности. Deezer по «артист + название» охотно отдаёт ремикс, лайв или кавер той же длины плюс-минус пара минут; добавишь вслепую — в плейлист приедет не та версия. Берём кандидата, только если имя совпало И длительность в пределах ±5–6 секунд, остальное — на ручную сверку. Тот же принцип «машина ищет — человек подтверждает», что и у апгрейда качества.

Шаг 4. Собираем плейлист в Navidrome. Когда добор осел и Navidrome пересканировал /music (новым трекам присвоены id), собираем плейлист субсоник-ручкой createPlaylist — имя и список songId:

curl -s -H 'Host: nvd.music' \
  'http://localhost/rest/createPlaylist?name=Мой+перенос&songId=<id1>&songId=<id2>&u=<user>&t=<md5>&s=<salt>&v=1.16.1&c=cc&f=json'

Грабля напоследок: songId, которых нет в текущем индексе Navidrome, ручка молча пропускает. Если songCount в ответе меньше, чем вы слали, — часть треков ещё не доехала из добора или не нашлась вовсе; дособрать позже той же updatePlaylist.

Как это в жизни. Я отдал ИИ папку playlists/ и сказал «собери в Navidrome, чего нет — в добор». Он распарсил CSV, прогнал id через oEmbed, разделил «есть/нет», недостающее с проверкой длительности покидал в wishlist, а из имеющегося собрал плейлист; мёртвое (oEmbed 404) — отдельным списком на торренты. Всё теми же ручками, что выше. Повторить с другим Клодом — дать ему этот раздел и путь к папке Takeout, дальше он допишет скрипты сам.

Грабли

Места, где я потратил время, чтобы вы не потратили.

1. Сетевая ловушка namespace. Контейнер за network_mode: service:gluetun теряет docker-DNS и не видит соседей по имени. Поэтому в туннель сажаем только качалки, а SoulSync держим в обычной сети с выходом через прокси VPN. В compose выше это уже разведено.

2. root-owned каталоги и тихо дохнущие сервисы. Всё крутится под uid 1000; если какой-то каталог остался root-owned от прежнего запуска, systemd-таймеры под обычным пользователем молча падают — юнит зелёный, работа не делается. Если «настроено, но не срабатывает» — первым делом проверяйте владельца каталогов, а не логику.

3. AcoustID путает каверы. Поэтому все операции, которые могут подменить файл (апгрейд качества, ретег по звуку), — на ручном подтверждении. Не автоматизируйте, каким бы заманчивым это ни было. Но я автоматизировал, это всего лишь музыка :)

4. Пароль qBittorrent слетает на рестарте (образ генерит временный при старте) — интеграция с SoulSync отваливается. Лечится тем, что после первого входа задаёте постоянный пароль в веб-морде qBit, тогда хэш ложится в конфиг и переживает рестарт. Делал ИИ.

5. Killswitch проверяйте IP изнутри namespace, а не с хоста — иначе увидите egress хоста и сделаете неверный вывод об утечке.

6. Пин версии SoulSync. Проект очень активный, релизы частые; держите конкретный проверенный тег, а не latest, — ломающий апдейт прилетит ровно тогда, когда раз в неделю зайдёте что-то скачать.

Что в итоге

• Своё ядро. Navidrome отдаёт мою коллекцию по OpenSubsonic, клиент — Symfonium через mTLS. Стек переживает ребут и не требует няньки в обычный день.

• Добавление с телефона. SoulSync-PWA: услышал → нашёл → скачал в лучшем качестве → легло в библиотеку с тегами и обложкой.

• Приватность проверена, а не заявлена. Внешнее приобретение — через VPN; Soulseek-P2P в netns с fail-closed killswitch; домашний IP не светится, наружу только :443 за mTLS.

• Коллекция наполнена и курируется. Теги причёсаны, обслуживание — на repair-джобах, а не ручном труде.

• Рекомендации замкнуты. Explo/ListenBrainz даёт «чего нет», AudioMuse — «похожее по звуку»; sonic доехал до телефона, плейлисты пересобираются каждую ночь сами.

И всё это zero-sub — ни одной активной подписки. Если бы они не хозяйничали в моих плейлистах я так бы и платил, но теперь с ИИ, он настроил все это за три вечера пока я его ругал, что все не так. Самое сложное было подобрать хорошо притертые сервисы и удобные что бы на телефоне было два приложения, одно для поиска (к сожалению PWA лучшее, что найдено) и одно играть. При этом ИИ сам лазит в SoulSync и другие сервисы, я просто в чате пишу “подними качество” или что там у нас по статусу джобов, лазить в PWA SoulSync или еще куда мне не хочется, а в Symfonium на телефоне просто есть огромная коллекция музыки с рекомендациями и просто работает. Как заработало, я так на ковыряниеяи и забил. Symfonium, кстити, не забудьте включить кэширование, что бы задержек не было, оно там выключено по умолчанию. Все вместе даже умные плейлисты строит по спектральному анализу и прочее подобное, все работает и притерто.

P.S. Всем хорошей музыки.

Зачем, почему и что получилось — расскажу ниже.

Зачем свой агент

Все облачные LLM-ассистенты — чужие. Данные уходят на сервера провайдера, контекст ограничен одним окном чата, настоящей долговременной памяти можно сказать нет, есть чат-сессия. При этом умные модели уже бегают локально на средненьком GPU: Qwen, Llama, Mistral. Возникает вопрос: а нельзя ли собрать агента, который будет жить на моём сервере, работать с моими данными и при этом иметь настоящий цикл рассуждений — не просто «спросил → ответил», а полноценный конечный автомат с ветвлениями, памятью и инструментами Причем хочется что бы кода в нем было, почти не было по сравнению с аналогами и он мог править сам себя или легко отлаживаться.

Оказывается, можно. Причём из довольно простых Unix-кирпичиков.

Что дает ниже описанный поход

1. Мало кода, если выкинуть клеекод и типизацию (модуль types), то останется примерно 6к строк пайтон скриптов. У аналогов примерно то же быстро становится сотнями тысяч строк.

2. Наблюдаемость, вся работа агента сразу видна и никаких инфраструктур для отслеживания его работы просто не нужно.

3. Простота конструкции, это просто набор конфигов и немного скриптов. В качестве инсталлятора ansible playbook.

4. Минимальное потребление ресурсов, агент влезет на самую дешевую VPS.

5. Агент может править себя.

6. Вся эта конструкция не требует инфраструктуры вовсе, никаких сложных миллионов контейнеров, мониторинг вытекает из ее свойств, отлаживать проблемы этой штуки очень легко. Достаточно дать ssh на сервер агенту и показать папку где отлаживаемый агент развернут, наблюдаемость у системы просто отличная.

Философия: событие = письмо

Самое неожиданное архитектурное решение Threlium — в его основе лежит электронная почта. Не как транспорт «для связи с пользователем», а как фундаментальная модель данных.

Любое событие в системе — это RFC 5322 сообщение. Буквально MIME-файл с заголовками и телом. Переход между состояниями конечного автомата — доставка нового письма в другой Maildir. Хранилище — тоже Maildir (формат tmp/, new/, cur/, атомарная запись через rename(2)). Индекс — notmuch поверх всех этих Maildir’ов. Это просто обыкновенная переписка между почтовыми ящиками, которая может моделировать как конечный автомат, так и модель акторов если хочется.

Звучит безумно? Возможно. Но вот что это даёт:

• Каждое событие — файл на диске. Можно открыть mutt’ом, grep’нуть, написать скрипт.

• Никакого отдельного брокера сообщений. Maildir — это и очередь, и canonical event store.

• Идемпотентность из коробки: файл либо в new/, либо в cur/, третьего не дано.

• Отказоустойчивость: упал процесс — файл остался в new/, следующий запуск подберёт.

• Полная история навсегда: после обработки файл переезжает в cur/<id>:2,S, не удаляется.

Один notmuch search '*' — и вы видите абсолютно все события системы за всё время. Это логический «архив». Простая почта позволяет просто открыть веб-интерфейс и посмотреть все “размышления” агента.

Конечный автомат на Maildir’ах

Threlium — IRT-tree FSM. Расшифрую: конечный автомат, у которого состояния — очереди Maildir, а граф переходов определяется In-Reply-To цепочками писем. Глобального координатора нет. Состояние фрейма (бюджет шагов, права) живёт прямо в заголовках письма — X-Threlium-Hop-Budget, X-Threlium-Capabilities.

Стадии FSM

Пока что их немного, я просто закончил базу и так как буду развивать ее далее, решил не тянуть и описать ее.

• ingress — единая точка входа. Сюда приходят все сообщения от всех каналов.

• enrich — обогащение контекстом. Здесь подключается LightRAG (граф знаний) и хронология треда.

• reasoning — собственно рассуждение. LLM получает промпт с контекстом и отвечает через tool calls.

• egress_router — маршрутизатор выхода. По depth IRT-цепочки решает: ответ пользователю или возврат в субагент.

• egress_email, egress_telegram, egress_matrix — терминальные стадии доставки наружу.

• cli_intent — политика: можно ли выполнять команду?

• cli_exec — песочница для исполнения shell-команд.

• thread_memory, global_memory — FSM-состояния для работы с памятью.

• archive — финальная запись об отправке.

Контракт стадии

Каждая стадия — Python-модуль threlium.states.<stage> с одной функцией:

def main(msg: EmailMessage, stage: FsmStage, *, config: Config) -> EmailMessage | None:

Принимает письмо — возвращает новое письмо (переход дальше) или None (терминальная стадия). Всё остальное — транспорт и оркестрация — за пределами стадии. Стадия не трогает файлы, не вызывает systemctl, не знает про fdm. Чистая функция над stdlib email.message.EmailMessage. По возможности конечно.

Граф переходов FSM

PlantUML-исходник: Граф переходов FSM

@startuml
left to right direction

package "Вход" {
  actor "Пользователь" as User
  rectangle "bridge-email" as EB
  rectangle "bridge-telegram" as TB
  rectangle "bridge-matrix" as MB
  User --> EB : Email
  User --> TB : Telegram
  User --> MB : Matrix
}

rectangle "fdm → notmuch insert" as FDM
EB --> FDM : run_fdm
TB --> FDM : run_fdm
MB --> FDM : run_fdm

rectangle "ingress" as ING
rectangle "enrich" as ENR
rectangle "reasoning" as REA
FDM --> ING
ING --> ENR
ENR --> REA

rectangle "egress_router" as EGR
rectangle "cli_intent" as CLI
rectangle "thread_memory" as TM
rectangle "global_memory" as GM
rectangle "subagent_intent" as SI
rectangle "reflect" as REF

REA --> EGR : "tool: egress_router"
REA --> CLI : "tool: cli_intent"
REA --> TM : "tool: thread_memory"
REA --> GM : "tool: global_memory"
REA --> SI : "tool: subagent_intent"
REA --> REF : "tool: reflect"

rectangle "cli_exec" as EXEC
rectangle "cli_hitl_out" as HITL
CLI --> EXEC : allow
CLI --> ING : deny
CLI --> HITL : HITL
HITL --> EGR
EXEC --> ING

TM --> ING
GM --> ING
REF --> ING
SI --> ING

rectangle "egress_email" as EE
rectangle "egress_telegram" as ET
rectangle "egress_matrix" as EM
rectangle "subagent_end" as SE
rectangle "archive" as ARC

EGR --> EE : "depth == 0"
EGR --> ET : "depth == 0"
EGR --> EM : "depth == 0"
EGR --> SE : "depth > 0"
SE --> ING

EE --> ARC
ET --> ARC
EM --> ARC

actor "Пользователь" as UserOut
EE --> UserOut
ET --> UserOut
EM --> UserOut
@enduml

Граф переходов FSM

Маршрутизация: fdm + notmuch insert

Для доставки писем между стадиями используется fdm — лёгкий mail delivery agent. Конфиг ~/.fdm.conf (генерируется Ansible из Jinja2-шаблона) содержит правила маршрутизации по заголовку To::

match "To" ... action pipe "notmuch insert --folder=stages/reasoning/Maildir ... && threlium-dispatch.sh"

Ключевое: notmuch insert — это атомарная операция. Файл записывается в Maildir и индексируется в notmuch одной транзакцией. Никакого notmuch new отдельно не нужно. После успешного insert тут же вызывается dispatch-скрипт, который поднимает воркер для обработки.

Почту давно придумали, не нужно писать ее снова для модели акторов. Нам нет острой необходимости экономить миллисекунды так как агенты работают десяткти минут.

Оркестрация: systemd –user

Никаких Celery, RabbitMQ, Kubernetes. Оркестрация — это systemd --user. Вот как работает цепочка:

PlantUML-исходник: Оркестрация systemd

@startuml
top to bottom direction

rectangle "fdm → notmuch insert\n--folder=stages/‹stage›/Maildir" as FDM
rectangle "threlium-dispatch.sh\nnotmuch search tag:unread\nAND folder:‹stage›/Maildir\n→ systemctl start --no-block" as DISP
rectangle "threlium-work@‹stage›:‹thread_id›\nType=exec\npython -m threlium.runners.engine_submit %i\n→ JSON в UNIX-сокет" as WORK
rectangle "threlium-engine.service\nДолгоживущий демон\nparse_rfc822 → main() → run_fdm()" as ENGINE
rectangle "nm_settle()\nnew/‹id› → cur/‹id›:2,S\ntags.discard unread + to_maildir_flags" as SETTLE
rectangle "threlium-sweep@‹stage›:‹thread_id›\nRace backstop\nthrelium-dispatch.sh %i\nперепроверка backlog" as SWEEP
rectangle "RAG-loop в engine\nrag.ainsert + tag +lightrag_indexed" as RAG
rectangle "JSON error → submit exit 1\nRestart=on-failure\nбез sweep" as ERR

FDM --> DISP : "&& threlium-dispatch.sh"
DISP --> WORK
WORK --> ENGINE
ENGINE --> SETTLE
SETTLE --> SWEEP : "exit 0 → OnSuccess"
SWEEP ..> DISP : "хвост unread"
SETTLE ..> RAG : "schedule_index_pending"
ENGINE --> ERR : "exception"
@enduml

Оркестрация systemd

Имя инстанса воркера threlium-work@enrich:000000000012ab.service — это одновременно и мьютекс. systemd гарантирует: один инстанс с данным именем — один тред. Параллельно обрабатываются разные треды (разные thread_id), последовательно — письма одного треда (oldest-first FIFO).

Никакого flock. Никакого пула потоков. Никакого coordinator. Всё бесплатно из systemd: перезапуски при сбоях (Restart=on-failure), лимиты ресурсов (threlium-work.slice с TasksMax, MemoryMax, CPUQuota), cgroup-изоляция, логи через journalctl.

Никакого в сотый раз написанного с нуля с косяками superviser for actors не нужно, KISS…my ass. Причем systemd –user выбран не просто так, это именно пользовательские unit, они живут в папке пользователя и в одном git репозитории все, так что их легко править и коммитить самому агенту если нужно.

Многоканальный вход: Email, Telegram, Matrix

Threlium принимает сообщения из трёх каналов. Каждый канал — это мост (threlium-bridge@<chan>.service), который нормализует входящий сигнал в каноническое RFC 5322 письмо:

Маршрутная информация канала (chat_id, room_id, update_id, reply targets) кодируется в заголовок X-Threlium-Route как base62(JSON). Это позволяет при ответе вернуть сообщение ровно в тот чат/комнату/ящик, откуда оно пришло.

На выходе egress_router определяет канал по X-Threlium-Route и маршрутизирует в egress_email, egress_telegram или egress_matrix. Симметрия: вход и выход устроены одинаково.

PlantUML-исходник: Ingress/Egress мосты

@startuml
left to right direction

package "Ingress-мосты" {
  rectangle "Email\nIMAP IDLE" as E
  rectangle "Telegram\nLong-poll" as T
  rectangle "Matrix\nmatrix-nio sync" as M
}

rectangle "run_fdm\n→ fdm → notmuch insert\nstages/ingress/Maildir" as FDM
rectangle "FSM\ningress → enrich → reasoning → ..." as FSM
rectangle "egress_router\nresolve X-Threlium-Route\n→ channel" as EGR

E --> FDM : "From: email@localhost\nX-Threlium-Route: b62(JSON)"
T --> FDM : "From: telegram@localhost\nX-Threlium-Route: b62(JSON)"
M --> FDM : "From: matrix@localhost\nX-Threlium-Route: b62(JSON)"

FDM --> FSM
FSM --> EGR

package "Egress" {
  rectangle "egress_email\nmsmtp → SMTP" as EE
  rectangle "egress_telegram\nBot API" as ET
  rectangle "egress_matrix\nClient-Server API" as EM
}

EGR --> EE
EGR --> ET
EGR --> EM
@enduml

Ingress/Egress мосты

Чекпоинтов вне union-индекса нет. При рестарте мост восстанавливает курсор из X-Threlium-Route последнего доставленного письма через notmuch-поиск. Никакой отдельной БД offset’ов. Тот же KISS.

LLM: tool calls как единственный механизм

Стадия reasoning — точка контакта с LLM. Используется litellm (Python SDK для OpenAI-совместимых API, версия 1.83 уже без взломов :) ). Модель получает:

1. System-промпт из Jinja2-шаблона reasoning/system.j2.

2. User-промпт с обогащённым контекстом из enrich (контекст графа знаний + хронология треда).

3. Список tool_specs для каждого возможного маршрута: egress_router, cli_intent, thread_memory, global_memory, subagent_intent.

Модель отвечает tool call’ом, а не свободным текстом. Это принципиальное решение: LLM — источник намерения, FSM — исполнитель. Парсинга свободного текста для выбора маршрута нет. Если модель вернула текст без tool call — ReasoningStageError, письмо остаётся в new/+unread, воркер завершается с exit 1, systemd делает retry. Позже я сделаю дополнительные стадии FSM для формирования больших ответов, но пока что есть минимум.

Аргументы tool call валидируются jsonschema (JSON Schema с additionalProperties: false и maxLength-лимитами). Прошла валидация — из аргументов собирается новое письмо с To: <next_stage>@localhost и отправляется через run_fdm в следующую стадию.

Для разных маршрутов — разные JSON-Schema инструментов, разные шаблоны тела и темы письма. Всё живёт в prompts/reasoning/<route>/tool_spec.j2, email_body.j2, email_subject.j2. Оператор может редактировать промпты без правки Python-кода.

Трёхслойная память

У агента три уровня памяти:

1. Локальный тред

Хронология текущего диалога собирается из union notmuch index’а. Стадия enrich проходит по цепочке In-Reply-To до корня ветки и формирует unified_messages — полную хронологию.

2. Глобальные факты

global_memory и thread_memory — обычные FSM-состояния. reasoning может вызвать tool call thread_memory или global_memory, записать факт, и он вернётся в ingress для следующей итерации.

3. Граф знаний (LightRAG)

Embedded LightRAG (lightrag-hku) работает как single-writer внутри threlium-engine. После каждого nm_settle() (когда письмо обработано и переехало в cur/) запускается schedule_index_pending — RAG-loop подбирает settled-сообщения, которые ещё не проиндексированы (NOT tag:unread AND NOT tag:lightrag_indexed), и вставляет их в граф через rag.ainsert(). Это не просто RAG, а граф связанных знаний.

PlantUML-исходник: LightRAG write/read

@startuml
left to right direction

package "Запись (async, после settle)" {
  rectangle "nm_settle()" as SETTLE
  rectangle "schedule_index_pending" as SCHED
  rectangle "Селектор:\nNOT tag:unread\nAND NOT tag:lightrag_indexed" as SEL
  rectangle "rag.ainsert(batch)" as INS
  rectangle "+lightrag_indexed" as TAG
  SETTLE --> SCHED
  SCHED --> SEL
  SEL --> INS
  INS --> TAG
}

package "Чтение (sync, в FSM)" {
  rectangle "enrich" as ENR
  rectangle "LLM: enrich_query_plan.j2" as PLAN
  rectangle "rag.aquery(...)" as AQ
  rectangle "Payload:\n--- user message ---\n--- lightrag context ---" as PAY
  rectangle "reasoning" as REA
  ENR --> PLAN
  PLAN --> AQ
  AQ --> PAY
  PAY --> REA
}

INS ..> AQ : "общий\nworking_dir/"
@enduml

LightRAG write/read

Стадия enrich при формировании контекста для reasoning вызывает rag.aquery() — семантический запрос к графу. Результат вместе с хронологией треда упаковывается в тело письма для reasoning через Jinja2-шаблоны. Пока что опять же это простейшее решение несмотря на мощь GraphRAG подхода, нужно дорабатывать подходы к экономии контекста, но когда кода совсем мало это не сложно, даже не шибко умные нейронки вайбкодят при таких объемах проекта легко.

Линейных цепочек для контекста отслеживать не нужно — весь тред со всеми форками индексируется как единая база знаний (глобальные знания агента). Mutex на весь тред от ingress до ответа не нужен.

Безопасность: решение / политика / исполнение

Слой CLI построен на строгом разделении:

cli_intent использует грубый фильтр: запрещённые подстроки (;, |, $(, &&), белый список базовых команд. Осознанно жёсткий — ложные срабатывания лучше, чем пропущенная инъекция. Если команда не попала ни в allow, ни в deny — уходит на подтверждение к человеку (HITL). Это решение я пока оставил совсем простым так же как и другие, суть в использовании systemd-run в будущем, пока просто заготовка.

HITL-прерывание

PlantUML-исходник: HITL-прерывание

@startuml
participant "reasoning" as R
participant "cli_intent" as CI
participant "cli_hitl_out" as HO
participant "egress_router" as ER
actor "Пользователь" as U
participant "ingress" as I
participant "cli_resume" as CR
participant "cli_exec" as CE

R -> CI : tool call: rm -rf /tmp/data
CI -> CI : classify: не в allow, не в deny
CI -> HO : HITL: спросить пользователя
HO -> ER : письмо с вопросом
ER -> U : «Разрешить rm -rf /tmp/data?»
U -> I : «Да» (ответ через канал)
I -> I : IRT-обход → From: cli_hitl_out
I -> CR : cli_resume
CR -> CE : cli_exec (разрешено)
CE -> I : observation (результат)
@enduml

HITL-прерывание

cli_exec запускает команду через systemd-run --scope с лимитами из X-Threlium-Capabilities текущего фрейма: MemoryMax, CPUQuota, TasksMax, timeout.

Субагенты: рекурсия через IRT-цепочку

Threlium поддерживает вложенные вызовы агентов (L0 → L1 → L2). Реализация — маркеры subagent_intent / subagent_end в IRT-дереве:

• reasoning на L0 вызывает tool subagent_intent → маркер в IRT-цепочке с изолированным hop/cap.

• Субагент на L1 не знает, кто его вызвал. Работает как обычный агент.

• По завершении egress_router по depth > 0 маршрутизирует результат не наружу, а в subagent_end.

• subagent_end находит соответствующий subagent_intent по IRT, копирует hop/cap родителя и возвращает письмо в ingress.

PlantUML-исходник: Субагенты L0/L1

@startuml
top to bottom direction

package "L0 — основной диалог" {
  rectangle "reasoning L0" as R0
  rectangle "subagent_intent\n(маркер + изолированный hop/cap)" as SI
  rectangle "ingress" as ING1
  R0 --> SI : "tool: subagent_intent"
  SI --> ING1
}

package "L1 — субагент" {
  rectangle "enrich" as ENR1
  rectangle "reasoning L1" as R1
  rectangle "egress_router\ndepth=1 > 0" as EGR1
  ING1 --> ENR1
  ENR1 --> R1
  R1 --> EGR1 : "tool: egress_router"
}

rectangle "subagent_end\nIRT-обход → subagent_intent\nкопия hop/cap родителя" as SE
rectangle "ingress L0" as ING0
rectangle "enrich L0" as ENR0
rectangle "reasoning L0\n(с результатом субагента)" as R0_2
rectangle "egress_router\ndepth=0" as EGR0
rectangle "egress_‹chan›\n→ пользователь" as OUT

EGR1 --> SE
SE --> ING0
ING0 --> ENR0
ENR0 --> R0_2
R0_2 --> EGR0 : "tool: egress_router"
EGR0 --> OUT
@enduml

Субагенты L0/L1

Глубина определяется линейным обходом IRT-цепочки: каждый subagent_intent → depth+1, каждый subagent_end → depth−1. Промежуточного in-memory state нет. Пока что решение довольно линейное и предназначено как и вся идея subagent для изоляции контекста, subagent начинает работать как бы “от запроса пользвоателя”, просто пользователь это другой агент. Позже можно реализовать параллельные агенты это в целом уже придумано, сделаю когда захочется, все можно построить на форках почтового треда и стадии слияния в FSM - это ведь по сути просто “обсуждение в почте”. По сравнению с почтой тут только будет ромб в графе, но это решаемо и совсем просто.

Идентификаторы: base62 и msgspec

Внутри системы все Message-ID канонизированы в форму <base62(payload)@localhost>:

• Email: payload = msgspec JSON EmailNativeId(v=1, message_id="<оригинальный MID>")

• Telegram/Matrix: payload = utf8(composite_inner)

Схема обратима: base62.decodebytes + msgspec.json.decode восстанавливают исходный struct. На egress для email — полное восстановление оригинального Message-ID, In-Reply-To, References для корректной цепочки в почтовом клиенте получателя.

base62 использует алфавит [0-9A-Za-z] — строгое подмножество atext RFC 5322, так что канонический Message-ID всегда валиден. Двоеточия Matrix, слэши msgid, $ Matrix-v3 — всё безопасно уходит в base62.

Сериализация через msgspec — детерминистическая (фиксированный порядок полей, без пробелов). Никаких mapping-таблиц и state: всё выводится из самого id через обратное преобразование. Это позволяет превратить в внутреннее почтовое сообщение любое сообщение из внешнего канала. Внутри агент это просто набор папок с eml файлами на диске и все.

Промпты: Jinja2 шаблоны, редактируемые оператором

Всё, что видит LLM и пользователь, генерируется из Jinja2-шаблонов в $THRELIUM_HOME/prompts/<stage>/<purpose>.j2. Код вызывает только render_prompt(name, **vars). Шаблоны деплоятся Ansible из roles/threlium/files/prompts/.

Это касается не только «обычных» промптов, но и:

• Overlay внутренних промптов LightRAG — 12 файлов, копии lightrag.prompt.PROMPTS для текущей версии lightrag-hku.

• addon_params для LightRAG — language, entity_types — JSON из Jinja2.

• Per-route tool-specs для reasoning — 6 маршрутов × 3 файла = 18 артефактов.

Смена поведения агента — правка шаблона и systemctl --user restart threlium-engine.service. Без коммита в Python. Но можно и скрипты свободно править конечно, это не компилируемый язык и это сознательное решение, так как сам агент можнт это делать, а так как ресурсов он ест мало, то на той же машине можно завести второго и когда один агент доломал себя, второго попросить просто откатить git репозиторий в котором живет почивший. Никаких компиляций сложной отладки и прочего.

Развёртывание: Ansible push-модель

Threlium не клонируется git clone-ом на целевой хост. Развёртывание — push-модель: ansible-playbook ansible/playbooks/site.yml с control node заливает всё на target.

Что попадает на target

• Python-пакет threlium (editable install в единый .venv).

• Конфигурации: threlium.yaml, env/*.env, ~/.fdm.conf, ~/.msmtprc.

• systemd-юниты (симлинки в ~/.config/systemd/user/).

• Промпты (Jinja2-шаблоны).

• Dispatch-скрипт и вспомогательные утилиты.

Жизненный цикл хоста

После первого деплоя Ansible свою роль заканчивает. Дальше хост живёт автономно: правки коммитятся в локальный git в threlium_repo_path, применяются оператором или самим агентом (через cli_exec, если capability-профиль разрешает). Повторный прогон Ansible — disaster-recovery.

Конфигурация LLM

Конфигурация LLM (endpoints, модели, таймауты) живёт в threlium.yaml, который генерируется из структурных Ansible-переменных. Два слота для одной модели с разными параметрами? Пожалуйста:

llm_endpoints:
  - model: "openai/qwen3-35b"
    api_base: "http://vllm-host:8000/v1"
    score: 0.0
    chat_template_kwargs:
      enable_thinking: false
  - model: "openai/qwen3-35b"
    api_base: "http://vllm-host:8000/v1"
    score: 1.0
    chat_template_kwargs:
      enable_thinking: true

Маршрутизация вызовов — по LitellmRoutingSite (reasoning, enrich_plan, lightrag_llm и т.д.), каждый site может ехать на свой endpoint с разным score. Это все проработано пока скорее как концепт конечно, но уже работает, дорогие вызовы делает reasoning, а дешевые делает GraphRAG.

Тестирование: e2e через Docker и WireMock

Единственный автоматизированный pytest-gate — e2e в tests/e2e/. Никаких unit-тестов отдельно, просто они для вайбкоженного проекта все равно бесполезны, было 400 юнит-тестов и они просто проверяли, что проект верно не работает. Поведение системы эмерджентно: связка fdm + notmuch + systemd + FSM + LLM — её невозможно адекватно замокать по частям.

Тестовый стек

PlantUML-исходник: Тестовый стек

@startuml
top to bottom direction

rectangle "pytest\n(control node)" as PY

package "Docker Compose" {
  rectangle "sut\nUbuntu 24.04 + полный site.yml\nprivileged, cgroup host\nживой threlium-engine" as SUT
  rectangle "greenmail\nSMTP :3025\nIMAP :3143\nIMAPS :3993" as GM
  rectangle "wiremock\nOpenAI + Matrix mock\nState Extension\nhost :9080 → :8080" as WM
}

PY --> SUT : "compose up/down"
PY --> SUT : "docker exec"
PY --> WM : "Admin API"
SUT --> GM : "docker DNS: greenmail"
SUT --> WM : "docker DNS: wiremock\nthrelium_openai_api_base"
@enduml

Тестовый стек

Стратегия baked-образа SUT: один раз прогоняется полный site.yml на голом Ubuntu → docker commit → threlium/e2e-sut:baked. Дальше тесты стартуют мгновенно из baked-образа.

WireMock с State Extension обеспечивает изоляцию параллельных сценариев: контекст State привязан к X-Threlium-Route конкретного теста. Десять xdist-воркеров бьют в один SUT параллельно — каждый со своим notmuch-тредом и своим контекстом в WireMock. Работает с переменным успехом, но мне хватает.

L0 happy-path

PlantUML-исходник: L0 happy-path

@startuml
left to right direction

rectangle "SMTP inject" as SMTP
rectangle "GreenMail\nINBOX" as GM1
rectangle "IMAP bridge\n(IDLE → fetch)" as IMAP
rectangle "ingress" as ING
rectangle "enrich\n(LightRAG aquery)" as ENR
rectangle "reasoning\n(WireMock: tool call)" as REA
rectangle "egress_router" as EGR
rectangle "egress_email\n(msmtp)" as EE
rectangle "GreenMail\nINBOX pytest@" as GM2
rectangle "pytest\nassert In-Reply-To" as ASSERT

SMTP --> GM1
GM1 --> IMAP
IMAP --> ING
ING --> ENR
ENR --> REA
REA --> EGR
EGR --> EE
EE --> GM2
GM2 --> ASSERT
@enduml

L0 happy-path

Отказоустойчивость

• Крэш стадии: файл остаётся в new/+unread. Restart=on-failure повторяет попытку. Sweep (после успеха) перепроверяет backlog.

• Крэш между rename(2) и Xapian-commit: файл уже в cur/, но notmuch думает, что он в new/. settle_recovery_for_stage() на старте воркера лечит через from_maildir_flags().

• Крэш моста: sys.exit(1) + Restart=on-failure. Курсор восстанавливается из notmuch.

• Крэш движка: все submit’ы получают BindsTo на threlium-engine.service. При рестарте движка воркеры перезапускаются автоматически.

• LightRAG drain прервался: тег +lightrag_indexed не поставлен → следующий drain повторит ainsert. LightRAG dedup гарантирует безопасность.

Отдельной стадии errors/ и error-mail нет. Сбои — structured log в journald и ненулевой exit code. Просто и предсказуемо, а весь процесс “мышления” видно просто в почте.

Админка: Cockpit + Caddy + Roundcube + Dovecot

Раз каждое событие — письмо, логично дать оператору смотреть «мысли» агента через обычный почтовый веб-интерфейс. Для этого на target поднимается стек из четырёх компонентов, которые вместе превращаются в полноценную админ-панель.

Dovecot: IMAP поверх Maildir’ов стадий

Dovecot подключается к тем же Maildir’ам, что и FSM. Единственный конфиг — drop-in 99-threlium-webmail.conf:

namespace inbox {
  inbox = yes
  location = maildir:$THRELIUM_HOME/stages:LAYOUT=fs:DIRNAME=Maildir
}

Каждая стадия FSM (ingress, enrich, reasoning, …) становится IMAP-папкой. Дополнительно настроен virtual namespace — виртуальная папка «All», которая собирает письма из всех стадий в единую ленту. Авторизация — через PAM (тот же POSIX-пользователь, что и агент).

ACL выставлены в режим read-only: lr (list + read) — можно просматривать, но не менять флаги, не удалять, не вставлять. Maildir пишут только Threlium и notmuch, Dovecot — чисто на чтение.

Roundcube: веб-интерфейс для почты агента

Roundcube подключается к локальному Dovecot (localhost:143, plaintext — всё на loopback). SMTP отключён — это read-only интерфейс. Из коробки настроен:

• Режим threads с сортировкой по дате — цепочки рассуждений видны как нити писем.

• Виртуальная папка Virtual/All подключена как архив и в default_folders.

• mail_read_time = -1 — Roundcube не ставит флаг «прочитано» при открытии (в паре с ACL Dovecot).

• SQLite для хранения сессий — никакого MySQL/PostgreSQL.

В Roundcube только надо в настройках показ папки Virtual/All включить и перейти в нее для просмотра всех тредов размышлений агента в виде обычных писем. Это удобно еще и потому, что когда отладка, можно просто скопировать письмо со всеми заголовками и агента попросить что то проверить с этим письмом связанное.

Caddy: единый edge-proxy

Caddy работает как точка входа, объединяя Cockpit и Roundcube на одном порту:

:8080 {
    handle_path /webmail/* {
        root * /usr/share/roundcube
        php_fastcgi unix//run/php/php-fpm.sock
        file_server
    }
    route * {
        reverse_proxy 127.0.0.1:9090 {
            transport http { tls_insecure_skip_verify }
        }
    }
}

Маршрутизация простая: /webmail/* → Roundcube через PHP-FPM, всё остальное → Cockpit на :9090. TLS — tls internal (self-signed) для прода, отключён в e2e. Порт настраивается через threlium_mail_archive_caddy_bind_port.

Cockpit: системная админ-панель с Roundcube внутри

Cockpit даёт из коробки: терминал, просмотр journald-логов (а значит всех логов агента), управление systemd-юнитами (можно рестартовать стадии, мосты, engine), мониторинг ресурсов, файловый менеджер (если доступен cockpit-files из backports).

В Cockpit регистрируется кастомный пакет threlium-mail-archive — это manifest.json + index.html с iframe на /webmail/. В итоге Roundcube появляется прямо как вкладка в Cockpit. Оператор видит в одном окне: системные метрики, логи, юниты и полную переписку агента. Это все вовсе без сложной инфры, оно еще и не ест ресурсов почти.

Cockpit слушает только на 127.0.0.1:9090 — наружу не торчит. Origin-проверка (защита от CSWSH) настраивается через threlium_mail_archive_cockpit_origins_extra в host_vars. Специальный oneshot-юнит threlium-cockpit-tls-clean.service чистит /run/cockpit/tls перед стартом Cockpit — workaround для известного бага с cockpit-certificate-ensure.

Как это выглядит вместе

PlantUML-исходник: Админка: стек Cockpit/Caddy/Roundcube/Dovecot

@startuml
left to right direction

actor "Оператор" as OP

package "Target host" {
  package "Caddy :8080" as CADDY {
    rectangle "/webmail/*" as WM
    rectangle "/* (всё остальное)" as ROOT
  }

  rectangle "Roundcube\nPHP-FPM" as RC
  rectangle "Cockpit :9090\n(loopback only)" as CP
  rectangle "Dovecot :143\n(loopback, PAM)" as DOV

  WM --> RC
  ROOT --> CP

  RC --> DOV : "IMAP localhost:143"

  package "$THRELIUM_HOME/stages/" {
    rectangle "ingress/Maildir" as MD1
    rectangle "enrich/Maildir" as MD2
    rectangle "reasoning/Maildir" as MD3
    rectangle "…/Maildir" as MDN
  }

  DOV --> MD1 : "read-only\nACL: lr"

  rectangle "Cockpit package\nthrelium-mail-archive\niframe → /webmail/" as PKG
  CP -- PKG
  PKG ..> WM : "iframe src"
}

OP --> CADDY : "браузер"
@enduml

Админка: стек Cockpit/Caddy/Roundcube/Dovecot

Весь стек включается одной переменной threlium_mail_archive_web_enabled: true (по умолчанию включён) и деплоится только при полном прогоне (--tags deploy). При --tags refresh веб-стек не трогается.

Ansible playbook: структура и режимы работы

Я уже упоминал push-модель развёртывания, но стоит рассказать подробнее о самом плейбуке — он устроен осознанно непохоже на типичный Ansible-проект.

Один плейбук, одна роль

Весь деплой — единственный файл ansible/playbooks/site.yml. Задачи живут прямо в нём, а не в roles/threlium/tasks/. Почему? Файл короткий, читается как последовательный сценарий, а перенос в роль дал бы include_role с тем же числом строк и сломал бы относительные пути. Роль threlium используется только для хранения переменных, шаблонов, файлов и дефолтов.

ansible/
  playbooks/
    site.yml                    # единственный сценарий
    tasks/
      refresh.yml               # узкий тег: чистка + рестарт
      mail_archive_web.yml      # веб-стек (Cockpit/Caddy/…)
      mail_archive_web_acceptance.yml
      ssh_hardening.yml
  roles/threlium/
    defaults/main.yml           # дефолтные переменные
    vars/main.yml               # канон FSM-стадий
    files/
      scripts/                  # Python-код FSM + bash-скрипты
      prompts/                  # Jinja2-промпты для LLM
      mail-archive/             # статика: dovecot-virtual
    templates/
      config/                   # fdm.conf, msmtprc, threlium.yaml
      systemd/user/             # шаблоны unit-файлов
      mail-archive/             # Caddyfile, cockpit.conf, …
      env/threlium.env.j2
      pyproject.toml.j2
  host_vars/                    # per-host: LLM endpoints, секреты
  group_vars/                   # общие переменные и e2e-оверрайды
  inventory/                    # hosts (прод и e2e)

Фазы деплоя

Каждая фаза — предусловие для следующей:

Два закона идемпотентности

Плейбук разделяет два класса операций:

Класс A — внешние зависимости (apt, pip): state: present — «install if missing». Стандартная идемпотентность Ansible. Не обновляет уже установленное.

Класс B — артефакты Threlium (код, конфиги, юниты, симлинки): перетирание каждый прогон. Файл на target сравнивается с репо и перезаписывается при расхождении. Никаких creates: или маркерных файлов — через baked-образ они превращаются в зашитый T₀.

Исключения из класса B: локальный .git (не стирать историю оператора) и физическая раскладка durable Maildir’ов (не пересоздавать event store с данными).

Два режима: deploy и refresh

PlantUML-исходник: Deploy vs Refresh

@startuml
top to bottom direction

package "--tags deploy (полный прогон)" {
  rectangle "apt: fdm, notmuch,\npython3, cockpit, caddy…" as D1
  rectangle "Каталоги + Maildir'ы" as D2
  rectangle "copy: Python-код FSM" as D3
  rectangle "template: конфиги,\nunit-файлы, env" as D4
  rectangle "pip install + venv" as D5
  rectangle "Веб-стек\n(Cockpit/Caddy/…)" as D6
  rectangle "Acceptance" as D7
  rectangle "Bundle" as D8
  D1 --> D2
  D2 --> D3
  D3 --> D4
  D4 --> D5
  D5 --> D6
  D6 --> D7
  D7 --> D8
}

package "--tags refresh (узкий прогон)" {
  rectangle "Остановка engine + мостов" as R1
  rectangle "Синхронизация:\nscripts/, env,\nшаблоны конфигов/юнитов" as R2
  rectangle "daemon-reload" as R3
  rectangle "Чистка Maildir/notmuch/\nLightRAG" as R4
  rectangle "Рестарт user-units" as R5
  R1 --> R2
  R2 --> R3
  R3 --> R4
  R4 --> R5
}
@enduml

Deploy vs Refresh

deploy — полный bootstrap: apt, venv, pip, веб-стек, acceptance, bundle. Используется для нового хоста или disaster-recovery.

refresh — узкий прогон: синхронизация кода и конфигов с control node + сброс Maildir/notmuch/LightRAG + рестарт user-units. Без apt, без pip, без веб-стека. Основной режим для e2e-тестов: baked-образ SUT переиспользуется, refresh накатывает актуальные артефакты идемпотентно.

Разметка тегов — три контракта:

После bootstrap: автономная эволюция

Ключевое отличие от типичных Ansible-проектов: плейбук — не governor хоста. После bootstrap ответственность переходит локальному git в threlium_repo_path.

• Оператор правит скрипт/конфиг прямо на target → daemon-reload → git commit. Симлинки сразу видят новое.

• Агент — через cli_exec в рамках capability-профиля. Может менять свои промпты, конфиги, даже Python-код, коммитя изменения в локальный git.

• Обратной синхронизации target → control нет и не предполагается. Каждая установка эволюционирует независимо.

Повторный полный ansible-playbook site.yml на живом хосте — только disaster-recovery. Он перетрёт локальные коммиты. Для штатного обновления кода — локальные правки или refresh.

Канон стадий — одна точка правды

Все FSM-стадии определены в единственном месте: roles/threlium/vars/main.yml (threlium_fsm_mailbox_stages). Все задачи плейбука — циклы по этому списку. Добавить стадию = добавить строчку. Рассинхронизация между Maildir’ами, fdm.conf и systemd-юнитами невозможна по конструкции.

Что имеем в итоге

Threlium — самохостный AI-агент, построенный из Unix-примитивов:

Вся система — один Python-пакет с единым venv, один systemd --user manager, один notmuch union-индекс. Никаких Docker-compose’ов в продакшене, никаких баз данных, никаких внешних брокеров. Файлы на диске, процессы в systemd, промпты в Jinja2.

Работает ли это? Работает. Я пишу агенту письмо — он думает, обогащает контекст из графа знаний, рассуждает, при необходимости выполняет команды (с подтверждением или без), и отвечает. Telegram и Matrix — пока не проверял :) Все каналы симметричны, история хранится вечно, контекст глобален.

P.S. Рекомендую LLM для консультаций при настройке. Особенно когда дебажишь, почему notmuch insert повесил +unread, а dispatch-скрипт не поднял воркер. Оказалось — опечатка в folder: термине. Эта конструкция домашнего агента совершенно прозрачна для отладки и модификации другими агентами! :)

Опубликован тут

UPD: случайно не добавил в репу папку с скриптами :) Добавлено.

Много лет назад я опубликовал этот материал, но платформа умерла, сохраню тут этот артефакт далекого прошлого, на мой взгляд до сих пор актуальный. Многим нравится держать книгу в руках и в последнее время мне тоже, особенно после того как ее сам сделал. При этом на самом деле это довольно дешево, сделать книгу. Плюс, поди найди в магазине нужную книгу. Я вот одну только в Москве нашел, у издателя. Вот и попробуем сделать настоящий шитый переплет, даже намного лучше типичного дешевого, сами.

Подготовка

Сразу стоит сказать, что если исходный файл содержит всего несколько десятков страниц, то лучше его распечатать в виде брошюры, многие просмотрщики и редакторы умеют это делать сами, просто в настройках печати надо указать.
Материалы, которые понадобятся для создания книги в хорошем, шитом переплете как в магазине (а скорее всего гораздо качественнее):

Бумага

Это моя находка. Надо найти не просто обычную белую офисную бумагу 80-85 г/м2, из нее получится толстенный, неудобный талмуд, надо найти бумагу для «рукописных работ» или ее называют «писчая бумага», или «потребительская», или «для машинописных работ» (эта особенно хороша, волокна длинные от этого она прочнее). Это бумага от 40 до 65 г/м2 плотности (подобрать по вкусу). Ее найти легко, надо просто спросить в канцелярских товарах. Когда держишь ее в руках, кажется, что она очень тонкая и будет неудобна, но когда будет переплет (закрепленная с одной стороны, толстая пачка листов), будет очень удобно, прям книга. Причем эта бумага потоньше чем обычная книжная и от того книга будет тоньше, что удобно для самодельных книг, объединяющих несколько томов. Но это не все. Есть одно большое достоинство. Эта бумага стоит 60-90р за 500 листов. Считаем. Печать одного листа будет стоить на своем принтере примерно 28 копеек с бумагой и это максимум, если заправлять картридж самому, если не самому, то 50 копеек за лист. Допустим книга 500 страниц, это будет ~128 листов (потом объясню почему). Стоимость распечатки книги, 36р или 70р. Еще надо две картонки А5, кусок ткани, пару метров ниток, тридцать сантиметров тесемок, клей ПВА и пару листов ватмана А4 (можно просто толстой бумаги «для черчения» она бывает гладкая, это красивее). Выходит, с такой бумагой себестоимость всей книги будет ~50р, плюс ваше время, если не брать сушку клея и ходьбу по магазинам в первый раз, часа два, и относительно времени пользования книгой это мелочь. Может себестоимость не первой книги такая, так как придется покупать пачку картона и пр., но в среднем «на закупку» именно так, а многие из материалов по дому можно найти или еще где. В общем издатели/перекупщики имеют выручку минимум десятикратную от себестоимости исходного продукта. Хотя будут вопить, что там и зарплаты и еще куча всего…ну вот что бы это все не оплачивать, гораздо дешевле сделать самому. Последняя книга, что я сделал, стоила в магазине 1100р. Причем в интернет магазине, в обычном такую уже не найти, а значит ждать доставку, а это дольше чем сделать самому. Я сделал ее за 50р. Стоит повозится, первый раз долго, но потом все быстрее.

Картон

Можно детский А5. Его клеем ПВА склеить в пару-тройку слоев и будет основа для жесткого переплета. Но продают и переплетный картон. Я в своем городе нашел одно такое место. Надо смотреть фирмы, торгующие бумагой, обзвонить несколько или на сайтах пошариться. Найти не просто, но можно. Переплетный картон толще детского, но продается листами 70*100см, что неудобно.

Ткань

Для оклейки переплета. Можно пользоваться и обоями (я не пробовал, но пишут, что проще), можно в той же бумажной фирме купить оклейку для переплетов. Но ткань дешевле и если клей не лить струей, то все получится отлично. Ткань надо х/б (другую я не пробовал, а эту в руках держать приятно, но лучше была бы джинса наверное) и плотную, что бы не тянулась особенно. В общем можно пустить на это дело старую одежку. Если будет тоненькая, то клей через нее пропитается легко и это плохо. Сначала от клея могут быть пятна, потом они пропадут когда высохнет но отсвечивать будут. Если же клей намазать тонким слоем, то он через ткань не пройдет и вообще виден не будет что бы так получилось, наносите клей кисточкой и так что бы ПВА не был белыми разводами, под прессом он склеится намного лучше чем без него, так что много не надо.

Нитки

Армированные. Они не рвутся и приятно блестят в переплете.

Тесьма

Просто стропы в тканях купите, тканевая лента, шириной 0.5-1 см или можно взять ткань, согнуть и прострочить по краю. Лучше если они будут потоньше, тогда они не будут выпирать через форзац будущей книги. Купить всегда лучше чем делать самому, во-первых качественнее, а во вторых усилий меньше, за создание переплета и так непросто взяться в первый раз. Так что лучше купить максимум того, что можете, в следующий раз будете сами все делать, когда технологию отработаете, но затраты невелики вообще-то.

Клей ПВА

Канцелярский тоже говорят пойдет, но он хуже. Для намазывания клея удобно использовать кисточку, иначе ткань пойдет не проклеенными пузырями, кисточкой клей будет нанесен равномерно. Клей надо мазать так что бы не было белых разводов, пусть лучше кажется, что его мало чем потом форзац пойдет волнами, а ткань еле заметными но все же пятнами. Мне на одну книгу надо где то 25г клея. Ждать полного высыхания клея не надо. Достаточно что бы он “схватился” под прессом, минут за десять. Но для изготовления картона, который я делаю заранее, я жду до конца. Тогда картон становится прочным и с ним удобно работать. В самом конце, когда собранная книга будет под прессом, вот тогда надо дождаться когда клей полностью высохнет во всей книге. Если так делать, это экономит много времени.

Пара листов плотной бумаги А4

Плотность более 130 г/м2. Как раз тот самый ватман. Из него будут сделаны форзацы книги. Тут лучше бумага поплотнее. Форзацы часть армирования книги.

Инструменты

Пресс

Мой первый пресс выглядел как доска и две гантели. Потом я сходил в хозяйственный магазин и купил пару болтов и к ним пару гаек с барашками, что бы руками закручивать. Доски сверлятся и вот пресс готов. Позже мне на заводе сделали пресс из двух железных пластин и все тех же болтов с барашками, но уже четырех. Доски не хуже, а может и лучше, они не гнуться при затягивании пресса и не повредят бумагу краями. Доски обработать рубанком или взять толстую фанеру/оргстекло. Ширину доски надо побольше, но на всю ширину книги не обязательно, в крайнем случае можно под него фанеру подложить или вообще обойтись. Сейчас у меня металлический пресс размером больше книги с четырьмя болтами по углам. Надо знать, что затягивать очень сильно все равно не придется, достаточно и доски с гантелями. Еще, иногда можно найти объявление о продаже набора доя переплета, советского, такие были, там есть пресс, я в итоге такой нашел.

Острый нож

Он нужен что бы ровно обрезать край книги. Для тонкой бумаги возможно нож не подойдет, у меня нож был недостаточно остр и порвал листы, но ножами режут. Лучше использовать строительный, со сменными лезвиями. Я думаю попробовать круглый, дисковый нож для резки обоев, он не будет рвать листы, зацепляясь за них. Но и обрезать в конечном итоге не так уж и жизненно важно, можно обойтись, можно с готовым книжным блоком (еще без обложки) прийти в типографию и они на гильотине срежут край идеально, что увеличит себестоимость наверное раза в три. Я же подошел к вопросу по другому и зажав в прессе книжный блок (страницы без обложки), выровнял край на шлифовальном круге, при сжатии бумага как деревяшка. Но ножом край будет более качественно отрезан, как и гильотиной. Можно и не резать вовсе.

Мелочи

Линейка (лучше уголок), карандаш, кусок мыла или мела (для раскроя ткани, прямоугольник нарисовать), кисточка для клея, толстая иголка или шило (без них можно обойтись), тонкая иголка, утюг.

Программы

Для подготовки к печати исходных данных нужны будут программы. Это называется допечатная подготовка и спуск полос, за это в типографии берут денег немало, что повышает себестоимость в несколько раз. Буду делать все в ubuntu/linux, но либо эти же программы, либо аналоги есть в windows:

1. Scantailor. Программа понадобится вам если у вас скан книги с сдвоенными страницами. Она их поделит пополам в полуавтоматическом режиме. Так же она страницы выровняет, повернет и настроит поля. Поля лучше сделать к середине книги побольше, а к внешнему краю поменьше. В общем очень удобно пользоваться. Но ей надо выдать страницы в tiff формате.

2. Djview4. Программа умеет сохранять djvu в tiff и pdf. Думаю аналогов миллион. Так же в tiff надо будет сохранить и pdf, я для этого перевожу его сначала в djvu. Но tiff нужен будет только если надо будет воспользоваться scantailor. Программа Djview4 хороша также тем, что быстро работает в отличие от некоторых консольных утилит.

3. Tiffcp умеет собирать отдельные картинки tif в один многостраничный документ tiff.

4. Pdf2ps или pdftops и наоборот, а так же pdf2djvu. Это преобразователи pdf, ps и djvu форматов между собой. Есть также и djvups. tiff2ps конвертирует tiff в  ps формат.

5. Psutils. Набор утилит для работы с PostScript файлами. Вот именно в ps формат потом и надо будет конвертировать любой файл. Именно эти утилиты делают «спуск полос». Нам из всего набора понадобится две утилиты (более подробно в этой статье). Psbook. Это утилита, которая делит книгу на сигнатуры. Сигнатура это тетрадка, из таких отдельных тетрадок состоит переплет «настоящей» книги. Размер сигнатуры должен быть кратен четырем, так как на одном формате А4, можно напечатать четыре страницы формата А5. То есть по две страницы с каждой стороны. Вот потому 128 листов в 500 страничной книге. Psbook  добавит в конце будущей книги, а не просто списка страниц, недостающие до кратности страницы и пересортирует страницы в списке так что бы при печати вышли тетрадки. Вот, кстати, откуда берутся «страницы для заметок» это просто «округление» до кратности. Psnup. Это утилита, которая разместит по две страницы на одном листе. Psmerge. Это утилита, объединяющая несколько ps файлов в один. Psselect. Позволяет выбирать из книг в ps формате отдельные страницы или выбирать страницы в обратном порядке.

6. Impose+. Набор утилит для подготовки книг/буклетов к печати. Используют psutils как основу. Утилита psbl, из состава impose+, умеет делать сигнатуры и прекрасно регулирует поля.

7. Нужен будет также просмотрщик ps файлов. Я пользовался evince. Но можно итоговый файл просто конвертировать обратно в djvu или pdf, что бы потом распечатать. С просмотрщиком ps проще.

Общая схема действий

В схеме два варианта начала. Имеем исходный djvu или pdf файл. Далее все зависит от того, надо ли нам резать страницы пополам, то есть сдвоенны ли страницы на скане книги. В конечном итоге все придет к ps файлу, который уже превращается в книгу, печатается и переплетается. Способов превращения в книгу два, первый сам подбирает поля и часто работает, но если проблемы, то есть второй с гибкими регулировками полей, я пользуюсь вторым.

## Подготовка и печать книги

У меня есть книга в формате djvu. У нее спаренные и цветные страницы:

Далее, что бы было проще, по действиям, но можно и с применением конвеера и даже скрипт накатать, кому надо тот понял. Если вам надо разрезать страницы книги пополам:

1. С помощью djview конвертируем книгу в многостраничный tiff файл. Книга, что я делаю, состоит из двух томов. Я их объединил в один шестисотстраничный том, просто скопировав tif страницы-картинки в одну папку. Бумага не офисная, том будет по толщине как обычная книга (позже я решил делать другую книгу, собрал ее из отдельных, маленьких статей на нужную мне тему, что, кстати, тоже возможно и удобно).

2. Берем Scantailor и режем страницы пополам. Больше нам от него особо ничего не надо, так как скан книги очень качественный, если надо, там все просто. Единственное с полями он пока работает плохо.

3. Получившийся после Scantailor набор tif картинок собираем в tiff файл с помощью ttiffcp -c none ./*.tif ./output.tiff. Эта утилита собирает много картинок в один многостраничный файл и работает быстро, так как сжатие в параметрах отключено. Картинки должны быть в текущей директории и названия имен файлов должны быть сортированы по порядку страниц. Например 1.tif, 2.tif,...,10.tif и т. д. Обратите внимание сортировку страниц 1 и 10. Они обе начинаются с 1 и это может испортить порядок, а может не испортить. Страницы в итоговом файле будут вставлены в соответствии с порядком файлов, отсортированных по именам.  Djview4 и  Scantailor имена сделают сразу сортируемыми правильно. Файлы без сжатия будут огромные, например в сумме 1.5Гб, но зато скорость будет выше так как не надо будет на каждом этапе пережимать их.

4. Конвертируем полученный tiff в ps с помощью tiff2ps -a2 ./output.tiff > output.ps

Если резать страницы не надо, то просто конвертируем в ps формат, исходный djvu, с переводом его в монохромный вид (книга была цветная) djvups -mode=bw -verbose ./in.djvu ./out1.ps. Вместо mode можно задавать и другие режимы вывода, для лазерного монохромнго принтера еще подойдет режим -color=no. Он конвертирует файл в режим «оттенков серого» вместо монохромного. Можно и вовсе не указывать режим, тогда будут сохранены свойства исходного файла. У этой утилиты еще много возможностей, она может делать и сигнатуры, и многое другое, но возможностей по гибкому управлению полями у нее нет. Для конвертации в ps, pdf файлов есть утилиты pdftops, pdf2ps. Главное получить ps. Далее готовим книгу к печати:

1. Делаем отдельные сигнатуры по две страницы на листе и по девять листов в сигнатуре. По сути тетрадки. Есть комплект утилит impose+ (impose, psbl, bboxx), они предназначены для этого и намного превосходят psbook, psnup в чистом виде, которые они используют. В частности в отличие от psnup (с которой я промучился довольно долго) эти утилиты умеют гибко управлять полями и автоматически определять размер полезной области листа, в общем, все для вас. Команда psbl -impose_options "-v -gutter 100 -ym 0 -xm 0" -max_mages 36 ./in.ps. Тут gutter - это поле между страницами. ym — это верхнее поле вдоль длинной стороны листа. xm — поля вдоль короткой стороны листа (именно листы А4, а не страницы, они А5 и их две на листе).  Все размеры полей при необходимости могут быть отрицательными (если поля по умолчанию слишком велики). max_mages — это  число страниц в сигнатуре, это число поделить на 4 и будет число листов, которые надо будет сгибать.

2. У утилиты psbl есть небольшой, но неприятный недостаток. Подготавливая сигнатуры она разделяет ps файл на отдельные файлы сигнатур. Это сделано из лучших побуждений, но неудобно, при печати без двустороннего принтера, это доставляет много неприятностей так как надо отдельные файлы открыть, распечатать сначала четную сторону, потом нечетную в обратном порядке, а этих файлов 15-20 штук на книгу. Применим команду psmerge -oout-all.ps `ls -mv in.ps.*.imposed|tr "\n" " "|tr "," " "` . Обратите внимание на кавычки ` это важно, кавычка та, что на кнопке клавиатуры с буквой «ё». Команды: ls выводит список файлов, разделенных запятой, tr, заменяет запятые и переносы строк на пробелы, а psmerge берет получившийся список имен файлов, разделенных пробелами и объединяет в один. Эта команда объединит все файлы сигнатур вида in.ps.*.imposed в один, звездочка это значит «любые символы», там номера страниц будут, но шаблон имени может быть и другим. Причем сигнатуры будут составлены в правильном, числовом-постраничном порядке. Кстати, для сборки отдельных статей в книгу используется эта же утилита.

3. Для того что бы сделать печать удобной надо воспользоваться еще одной утилитой, psselect. Она сохраняет нужные страницы из исходного файла в целевой, например только нечетные или только четные в обратном порядке и пр. Команда для сохранения нечетных страниц выглядит так psselect -o ./in.ps ./out-odd.ps. Команда для сохранения четных страниц в обратном порядке выглядит так psselect -e -r ./in.ps ./out-reven.ps. После этого этапа у нас есть два файла, подготовленных для печати в любой программе просмотра ps, без всяких проблем.

4. Печатать надо особым образом. Сначала нечетные страницы из файла out-odd.ps. Потом вынуть пачку листов из принтера, у меня она сверху лежит в hp p1102, обычном домашнем принтере, не меняя ориентации пачки положить их в лоток с бумагой (то есть просто сверху вниз). Если вы взялись сбивать листы поровнее, вытащили их и забыли как они лежали, то надо взять листы, повернуть картинкой к себе и ориентровать ее так же как вы видите на экране открытую книгу, которую печатаете, потом надо положить эту картинку вниз на себя как будто крышку ноутбука положили и воткнуть в принтер. Я так пишу потому, что при печати иногда так запаришься все проделывать, что лучше иметь конкретный метод. Далее печатать четные страницы из файла out-reven.ps. При этом они уже в обратном порядке, это надо потому, что первая страница ранее у нас распечаталась последней. Бумага у нас тонкая, так что я беру один лист, поднимаю слегка и остальную пачку под ним придавливаю пальцем, что бы принтер несколько листов сразу не съел. Это неудобно, но не долго и потом не придется выкидывать пятьдесят листов не допечатанного текста или возится с его допечатыванием.

Пример выполнения команд по созданию заготовки для печати, «от и до» приведен ниже. Мне надо было из книги выделить страницы с 1 по 31, так что там в начале есть команда psselect, лишняя:

     $djvups -verbose ./1.djvu ./1.ps
    [##################################################]
    $ psselect -p1-31 ./1.ps ./2.ps
    [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
    [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31]
    Wrote 31 pages, 25905313 bytes
    $ psbl -impose_options "-gutter -30 -ym -30 -xm -10" -max_mages 36 ./2.ps
    num_signatures = 1
    q_per_signature = 8
    psselect 1-31 './2.ps' | fixtd -tumble | psbook > './2.ps.1-31'
    [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
    [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31]
    Wrote 31 pages, 25905313 bytes
    [*] [1] [2] [31] [30] [3] [4] [29] [28] [5] [6] [27] [26] [7] [8] [25] [24]
    [9] [10] [23] [22] [11] [12] [21] [20] [13] [14] [19] [18] [15] [16] [17]
    Wrote 32 pages, 25905485 bytes
    impose -gutter -30 -ym -30 -xm -10  './2.ps.1-31'
    Done!
    $ psselect -e -r ./2.ps.1-31.imposed ./2-er.ps
    [16] [14] [12] [10] [8] [6] [4] [2] Wrote 8 pages, 12988730 bytes
    $ psselect -o ./2.ps.1-31.imposed ./2-odd.ps
    [1] [3] [5] [7] [9] [11] [13] [15] Wrote 8 pages, 12933748 bytes
    $ 

Работает этот пример в подавляющем большинстве случаев, я пробовал на нескольких книгах, надо только поля отрегулировать. В самом простом случае, когда поля вас устраивают сразу, можно воспользоваться командами:

1. Вводим команду psbook -s36 output.ps output1.ps. Это даст нам будущую книгу, состоящую из тетрадок по 36 страниц А5, то есть по 9 листов А4 в тетрадке. Страницы внутри книги будут пересортированы специально для этого и будут добавлены округляющие до четырех пустые страницы так что бы они все были в конце книги.

2. Вводим команду psnup -l -pa4 2 output1.ps > output2.ps. Это даст нам файл в котором на одном листе снова размещено по две страницы. Параметр -pa4 задает формат выходных листов. Зачастую сканированные книги сохранены в формате а5, что вполне логично, но утилита не всегда нормально это понимает и ей надо указать входной формат явно. Это делается другим параметром: -Pa5. Если все же автоматический масштаб, выбранный утилитой psnup, не подходит и страницы сбились куда то в угол листа (у меня так было в этот раз), надо применить параметр -s1 и тем самым жестко задать нужный масштаб. В прошлый раз подошло -s0.83. Команда будет такая `psnup -l -pa4 2 -s1 output1.ps > output2.ps

3. Далее пункты 3 и 4 предыдущего списка или просто печать четных, и нечетных страниц в обратном порядке из просмотрщика.

Создание переплета

Теперь пойдет  непосредственно создание переплета. Несмотря на объем текста, вся подготовка займет не так и много времени, что видно из вышеприведенного, наглядного примера создания заготовки для печати. Но изучение этого всего и поиск наиболее простых вариантов работы, все это заняло кучу времени и именно поэтому я написал эту памятку. По сути, «раскачивался» для создания первой книги я почти пол года и наконец то сделал ее, изучив кучу всего, по другому не умею.
Дополнительно можете глянуть книгу «Переплет и реставрация книг Ю. П. Ирошников, И. Г. Ирошникова» или статью, можно там найти еще картинки, более качественные чем с моего телефона. Далее по пунктам. Сначала надо согнуть тетради пополам. Берем по девять листов (в данном случае) и сгибаем их в отдельные тетради. Потом можно все тетради сложить в пачку и в прессе сжать что бы сгиб был стойкий. Либо можно проводить по сгибу ложкой.

Отмечаем на линейке положения тесемок/дырок и проделываем отверстия шилом или толстой иглой под нитки в тетрадях по линейке. Еще иногда делают по другому. Все тетради зажимают под пресс, а потом делают тонкий пропил (можно и ножом прорезать) там где надо в каждой тетради сделать по отверстию. Но это некрасиво, потом внутри книги отверстия будет видно. Если сделать иголкой, не видно ничего. Тут я «обходиться» не стал так как на края листов смотришь во время чтения все время.

Клеим скотчем тесемки на край стола или зажимаем в прессе, после чего пришиваем к ним тетради. Между собой тетради тоже надо сшить. Этот момент особенно непонятен пока не сделаешь первый раз. Сшивая тетради, надо просто зацеплять текущую тетрадь между двумя предыдущими и завязывать нитку одинарным узелком продев иглу в петлю. Когда тетрадей будет пришито несколько их можно уже на скотче не держать, а пришивать к ним следующие прямо с рук. К тесьме тетради именно пришивать не надо надо просто перехлестнуть через них нитку, надеюсь на картинке это видно. Тогда можно будет после пришивания всех тетрадей тесьму подтянуть или сдвинуть внутри ниточных петелек.

Проклеиваем книжный блок. До этого момента книжный блок (набор тетрадей) можно переделывать, после уже все жестко, но можно добавлять тетради сверху и снизу. Если это отдельные статьи, то тоже вполне нормально выходит. Клей надо нанести так что бы он немного проник между тетрадями. Для этого я сначала зажимаю сам блок, оставляя его торец висеть выдвигая его на сантиметр, тогда тетради немного расходятся. Потом промазываю клеем и наконец зажимаю в прессе до высыхания.

Наклеиваем форзацы. Просто берем край форзаца у сгиба и приклеиваем к первой странице книжного блока.

После этого можно обточить на диске/обрезать ножом края книжного блока. Возьмите картонку А5 и по ней померьте сколько сточить. Надо так сделать что бы картонка на три-пять миллиметров была больше чем книжный блок, как и в обычных книгах. Но я делаю почти впритык, так как на моем инструменте стачивать очень долго. Или не стачиваю вовсе.
Наклеиваем тесемку-закладку на торец блока. Если хочется.
Наклеиваем бинт или марлю на торец блока что бы армировать его. Без этого можно обойтись.
Наклеиваем капталы, но можно обойтись. Каптал - это широкая стропа с одной стороны более толстая чем с другой, а можно и просто стропу. Нужна больше для декорации, чем для усиления. Стропы продаются в тканях, фиг знает как их называют там, у меня с походов парочка валяется, давно покупал, сейчас вообще обошелся.
Делаем выкройку ткани под переплет. Ткань надо погладить. Углы нужно по диагонали отрезать для складывания, либо заморочиться более сложным способом (который я описывать не стану, есть в книге «Переплет и реставрация книг Ю. П. Ирошников, И. Г. Ирошникова», может там видел, не помню, много прошерстил). Не забудьте, что между обложками надо оставить расстояние под торец книги, на выкройке я его не черчу, но оно там есть.

Склеиваем в два-три слоя детский картон А5 с канцтоваров что бы получить более жесткий картон. Надо сделать два листа А5. Лучше подержать под прессом, тогда обложка выйдет плоская. Я взял какие то старые картонные бланки и склеил. Делаем тоненькую полоску картона для армирования торца переплета.

Собираем книгу. Надо просто вставить книжный блок с обмазанными клеем форзацами, в обмазанную клеем обложку. Причем клея не надо много, под прессом он клеит отлично и в небольших количествах (что мне было непривычно), главное всю поверхность обложки покрыть, а для пущего эффекта и форзацы. Я почти всегда перебарщиваю, кажется мало, как и в этот раз. Вставить в сгибы форзацев листы бумаги что бы блок от клея защитить. Выровнять блок и обложку относительно друг-друга, не парьтесь, просто все воткните и выровняйте, я сначала тесемки там ровнял и вытаскивал, оказалось если вставить оно само на место все встанет, если с умом конечно. Если клея много не лить то вставлять защитные листы не надо будет. Особо проклейте тесемки, нанеся на них клей. Лучше для начала без клея посмотреть как оно подходит друг к другу.

Когда высохнет, можно трафаретом на ткань нанести название книги. Тоже можно обойтись.

Заключение

Вот и весь процесс, он занимает где то полдня на второй раз. В выходной вполне можно сделать книжку, такое периодическое хобби, которое успокаивает и расслабляет (если себя не насиловать) и каждый раз когда вы будете брать книгу в руки этот эффект будет повторяться, просто ассоциации будут работать. В конечном итоге не так и много мне книг надо что бы за каждой, месяц охотится по магазинам. Дешевый худ. лит, конечно, так делать, я не стану. Я делаю таким способом книги, к которым не раз обращусь.
В типографии это тоже можно сделать, есть такие услуги, я ими пользовался по «служебной необходимости». Сегодня, печать вам обойдется 1.5р за лист. Переплет около 200р, но переплет будет клееный на скрепках, то есть раскрыть толстую книгу в пятьсот листов и нормально почитать весь день, будет очень неудобно, так печатают вещи потоньше, типа диплома. Плюс ко всему переплет могут не армировать скрепками и он быстро лопнет, а могут и армировать, надо уточнять. Бумага будет офисная, если вы конечно не уточните какая вам нужна и в типографии такую решаться применить на своем оборудовании. Шитый переплет стоит намного дороже.
Помимо снижения стоимости раз в десять, относительно типографии и в двадцать, относительно магазина, самодельный переплет приносит еще и удовольствие от создания отличной вещи, потом книжку в руках держать гораздо приятнее чем это был бы обычный учебник с магазина и это помогает его легче осваивать. Еще осваивать помогает то, что это ваша книга, у меня никогда не было моих книг, даже если я их покупал. На этой я легко делаю пометки на страницах для заметок, задачки решаю (можно даже к концу книги специально добавить страницы для этого), а такого я себе никогда не позволял, как в детстве руки отбили так и смотрел на книги как на музейный экспонат (дорого и редко), и предпочитал пользоваться электронными, прочел сотни книг с монитора. Плюс ко всему раскрыть такой переплет просто удобно, шитые переплеты затем и придумали.
Еще одно преимущество в том, что книгу можно делать самому, вы ее можете сделать из редактируемого файла и оформить как хотите. Можете собрать вообще разрозненный набор статей и документов в книгу, достаточно просто каким то образом это все превратить в pdf. Превращать в pdf, что угодно можно например путем печати на виртуальном pdf принтере, есть такие программы. Если при печати лезут какие то каракули вместо формул, надо найти опцию «печатать как картинку», она обычно в расширенных настройках принтера. Еще можно вместо виртуального принтера воспользоваться функцией «печать в файл» у многих программ, эта функция сделает на выходе либо ps, либо pdf. Объединить получившиеся файлы в один pdf и дальше по схеме. Можно также воспользоваться psmerge для объединения нескольких ps файлов в один.
Тут главное помнить, что это вы делаете, сами, что хотите, то и воротите, я когда инструкцию вижу, мозг вырубается сразу и делаю по инструкции, так что приходится специально помнить об этом. После создания своей первой книги вы станете смотреть на них как на изделие. Развалился переплет какой то, вы его сможете легко взять, что-то придумать и отремонтировать.
Вот например клеенный переплет, который я недавно восстановил. Просверлил его насквозь и ниткой стянул, а небольшие шампуры для сарделек (из сувенирного магазина, не знаю почему их там продавали) использовал как опору для нитки чтобы она страницы не резала. Узелки на концах нитки, проклеил с помощью ПВА. Перед этим всем торцы листков, сложенных в пачку, смазал ПВА и вставил в переплет, это немного, но все же его усилило. В результате имеем целую книгу, а до этого ее в руках держать было сложно, рассыпалась на кучу листов. Причем эти шампуры стали удобной ручкой, за которую книгу можно держать. В общем полезный навык, хотя бы одну книжку сделать самому, вполне можно.

Небольшое отступление по поводу того, что у нас получилось после прошлой статьи:

1. Есть Asus NUC у которого процессор двенадцатого поколения Intel и Intel Xe графикой, NPU и 12 ядрами CPU. Встройка работает с ОЗУ, а значит медленно, но верно сможет работать даже с приличного размера моделями, но все проверять надо, пока, первый заход.

2. Сетевая инфраструктура, которая позволяет нам поднимать в локальной сети за мостом services, сервисы, которые мы можем легко выставить в интернет через Caddy реверс-прокси.

3. Лично у меня на этот сервер переехал мой инстанс Mastodon. Содержать его у хостера было не дешево.

4. Помимо прочего я распилил изолированный мост services на набор отдельных VLAN для групп сервисов что бы изолировать их дополнительно, теперь OPNSense настоящий шлюз между этими сетями. Включил на OPNSense такую штуку как Suricata, которая показывает когда сервисы сканируют автоботы на предмет открытых уязвимостей, не сказать еще хужей. Если бы самодержавные хостеры знали сколько их сканят, они бы беспокоились о безопасности побольше, но о безопасности в другой раз.

Чего мы хотим:

1. Счастья.

2. Пробросить Intel GPU из Proxmox хоста внутрь LXC контейнера, а там и внутрь Docker контейнера. Вложенность такая потому, что запуск среды обработки неронных моделей без Docker это довольно сложное мероприятие.

3. Запустить LXC контейнер с OpenVINO models server (OVMS), который будет движком, обеспечивающим embedding или inference, зависит от наших потребностей. Движек от Intel для их железок, очень оптимизированный и много, что может. Как запуск большого количества моделей, так и маскировку под разные API доступа.

4. В принципе хотим еще и WebUI на это все натянуть, но это за рамками статьи потому, что мне это не нужно и сделаь это просто, так как OVMS поддерживает самые разные распространенные API, например от OpenAI, с которыми работает любая WebUI. Это в его документации описано довольно ясно.

5. Получить возможность сделать curl запрос к нейронке и получить embedding, что мне в данном случае и нужно, так как хочется построить свой RAG и давать к нему доступ всяким нейронкам в виде MCP, если вы понимаете о чем я.

Штош, хватит отступлений, поехали. Напомню только, что если что-то не ясно, спросите нейронку, они отлично пояснят.

Краткое содержание следующих серий

Вот тут и тут можно найти море готовых моделей. После чего вот так их запустить:

Команды

i3draven@ovms:~/ovms$ tree .
.
└── models

2 directories, 0 files
i3draven@ovms:~/ovms$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
i3draven@ovms:~/ovms$ docker run --rm -u 1000   -v ~/ovms/models:/models:rw   openvino/model_server:latest-gpu   --pull   --model_name llm   --source_model OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov --target_device GPU --task text_generation --model_repository_path /models
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (16/16), done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 19 (delta 0), reused 0 (delta 0), pack-reused 3 (from 1)
Receiving objects: 100% (19/19), 17.19 KiB | 0.00 B/s, done.
Checking out files:   0% (0/14)
Downloading lfs size: 2.09 MiB file: /models/OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov/openvino_detokenizer.bin
Progress: [##################################################] 100.00% [2.09 MiB/s]  
Checking out files:  42% (6/14) 
Downloading lfs size: 1.30 GiB file: /models/OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov/openvino_model.bin
Progress: [##################################################] 100.00% [66.60 MiB/s] 
Checking out files:  57% (8/14) 
Downloading lfs size: 5.33 MiB file: /models/OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov/openvino_tokenizer.bin
Progress: [##################################################] 100.00% [5.33 MiB/s] 
Checking out files:  71% (10/14)
Downloading lfs size: 10.89 MiB file: /models/OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov/tokenizer.json
Progress: [##################################################] 100.00% [10.89 MiB/s] 
Model: OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov downloaded to: /models/OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov
Graph: graph.pbtxt created in: /models/OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov
i3draven@ovms:~/ovms$ docker run --rm -u 1000   -v ~/ovms/models:/models:rw   openvino/model_server:latest   --list_models --model_repository_path /models
OpenVINO/DeepSeek-R1-Distill-Qwen-1.5B-int4-ov
i3draven@ovms:~/ovms$ docker run --rm -u 1000   -v ~/ovms/models:/models:rw   openvino/model_server:latest   --add_to_config /models   --model_name DeepSeek-R1-Distill-Qwen-1.5B-int4-ov --model_repository_path /models/OpenVINO
Config updated: /models/config.json
i3draven@ovms:~/ovms$ docker run -d --rm   --user $(id -u):$(id -g)   --device /dev/dri:/dev/dri   --group-add $(stat -c "%g" /dev/dri/render* | head -n 1)   -v ~/ovms/models:/models:ro   -p 9000:9000 -p 8000:8000   openvino/model_server:latest-gpu   --config_path /models/config.json   --port 9000   --rest_port 8000
c4cd80757c4c8abe9f85a9c08806f1691b2a123e7e0e582ae37a968f89c86bc7
i3draven@ovms:~/ovms$ docker ps
CONTAINER ID   IMAGE                              COMMAND                  CREATED         STATUS         PORTS                                                                                      NAMES
c4cd80757c4c   openvino/model_server:latest-gpu   "/ovms/bin/ovms --co…"   3 seconds ago   Up 3 seconds   0.0.0.0:8000->8000/tcp, [::]:8000->8000/tcp, 0.0.0.0:9000->9000/tcp, [::]:9000->9000/tcp   keen_diffie
i3draven@ovms:~/ovms$ docker logs c4cd80757c4c
[2025-11-25 19:52:43.325][1][serving][info][server.cpp:91] OpenVINO Model Server 2025.3.0.6e2e910de
[2025-11-25 19:52:43.325][1][serving][info][server.cpp:92] OpenVINO backend 2025.3.0.dev20250826
[2025-11-25 19:52:43.325][1][serving][info][pythoninterpretermodule.cpp:37] PythonInterpreterModule starting
[2025-11-25 19:52:43.381][1][serving][info][pythoninterpretermodule.cpp:50] PythonInterpreterModule started
[2025-11-25 19:52:43.423][1][modelmanager][info][modelmanager.cpp:156] Available devices for Open VINO: CPU, GPU
[2025-11-25 19:52:43.424][1][serving][info][capimodule.cpp:40] C-APIModule starting
[2025-11-25 19:52:43.424][1][serving][info][capimodule.cpp:42] C-APIModule started
[2025-11-25 19:52:43.424][1][serving][info][grpcservermodule.cpp:102] GRPCServerModule starting
[2025-11-25 19:52:43.424][1][serving][info][grpcservermodule.cpp:179] GRPCServerModule started
[2025-11-25 19:52:43.424][1][serving][info][grpcservermodule.cpp:180] Started gRPC server on port 9000
[2025-11-25 19:52:43.424][1][serving][info][httpservermodule.cpp:35] HTTPServerModule starting
[2025-11-25 19:52:43.424][1][serving][info][httpservermodule.cpp:39] Will start 16 REST workers
[2025-11-25 19:52:43.475][1][serving][info][drogon_http_server.cpp:158] REST server listening on port 8000 with 16 unary threads and 16 streaming threads
[2025-11-25 19:52:43.475][1][serving][info][httpservermodule.cpp:61] HTTPServerModule started
[2025-11-25 19:52:43.475][1][serving][info][httpservermodule.cpp:62] Started REST server at 0.0.0.0:8000
[2025-11-25 19:52:43.475][1][serving][info][servablemanagermodule.cpp:51] ServableManagerModule starting
[2025-11-25 19:52:43.477][1][serving][info][mediapipegraphdefinition.cpp:421] MediapipeGraphDefinition initializing graph nodes
[2025-11-25 19:52:43.477][1][modelmanager][info][servable_initializer.cpp:463] Initializing Language Model Continuous Batching servable
[2025-11-25 19:52:50.779][1][modelmanager][info][mediapipegraphdefinition.cpp:182] Mediapipe: DeepSeek-R1-Distill-Qwen-1.5B-int4-ov inputs: 
name: input; mapping: ; shape: (); precision: UNDEFINED; layout: ...
[2025-11-25 19:52:50.779][1][modelmanager][info][mediapipegraphdefinition.cpp:183] Mediapipe: DeepSeek-R1-Distill-Qwen-1.5B-int4-ov outputs: 
name: output; mapping: ; shape: (); precision: UNDEFINED; layout: ...
[2025-11-25 19:52:50.779][1][modelmanager][info][mediapipegraphdefinition.cpp:184] Mediapipe: DeepSeek-R1-Distill-Qwen-1.5B-int4-ov kfs pass through: false
[2025-11-25 19:52:50.779][1][modelmanager][info][pipelinedefinitionstatus.hpp:59] Mediapipe: DeepSeek-R1-Distill-Qwen-1.5B-int4-ov state changed to: AVAILABLE after handling: ValidationPassedEvent: 
[2025-11-25 19:52:50.779][1][serving][info][servablemanagermodule.cpp:55] ServableManagerModule started
[2025-11-25 19:52:50.779][130][llm_executor][info][llm_executor.hpp:90] All requests: 0; Scheduled requests: 0;
[2025-11-25 19:52:50.779][131][modelmanager][info][modelmanager.cpp:1201] Started model manager thread
[2025-11-25 19:52:50.779][132][modelmanager][info][modelmanager.cpp:1220] Started cleaner thread
i3draven@ovms:~/ovms$ curl http://localhost:8000/v3/chat/completions   -H "Content-Type: application/json"   -d '{"model":"DeepSeek-R1-Distill-Qwen-1.5B-int4-ov","messages":[{"role": "system", "content": "Ты полезный ассистент отвечающий на русском языке."},{"role":"user","content":"Hello"}],"max_tokens":50}' | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   744  100   505  100   239    103     48  0:00:04  0:00:04 --:--:--   136
{
  "choices": [
    {
      "finish_reason": "length",
      "index": 0,
      "logprobs": null,
      "message": {
        "content": "Okay, so I just received a message from someone asking me to act as an assistant. They said, \"Ты полезный ассистент отвечающий на русском языке.\" Translating that, it's",
        "role": "assistant",
        "tool_calls": []
      }
    }
  ],
  "created": 1764100387,
  "model": "DeepSeek-R1-Distill-Qwen-1.5B-int4-ov",
  "object": "chat.completion",
  "usage": {
    "prompt_tokens": 27,
    "completion_tokens": 50,
    "total_tokens": 77
  }
}
i3draven@ovms:~/ovms$ 

Готовый скрипт для скачивания и настройки моделей

Скрипт

#!/bin/bash

# Цвета для вывода
GREEN='\033[0;32m'
BLUE='\033[0;34m'
RED='\033[0;31m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

# Запрос директории для моделей с значением по умолчанию
DEFAULT_DIR="./models"
read -p "Укажите директорию для сохранения моделей [${DEFAULT_DIR}]: " MODEL_DIR
MODEL_DIR=${MODEL_DIR:-$DEFAULT_DIR}

# Создаем директорию если не существует
mkdir -p "$MODEL_DIR"

# Получаем абсолютный путь
MODEL_DIR=$(cd "$MODEL_DIR" && pwd)

echo -e "${BLUE}Используется директория: $MODEL_DIR${NC}"

# Запрос имени модели с примером по умолчанию
DEFAULT_MODEL="OpenVINO/Qwen2.5-7B-Instruct-int8-ov"
echo -e "\n${YELLOW}Пример модели: https://huggingface.co/OpenVINO/Qwen2.5-7B-Instruct-int8-ov${NC}"
read -p "Укажите имя модели [${DEFAULT_MODEL}]: " SOURCE_MODEL
SOURCE_MODEL=${SOURCE_MODEL:-$DEFAULT_MODEL}

# Извлекаем организацию и имя модели
MODEL_ORG=$(dirname "$SOURCE_MODEL")
MODEL_NAME=$(basename "$SOURCE_MODEL")

# Выбор типа задачи (TASK)
echo -e "\n${YELLOW}Выберите тип задачи:${NC}"
PS3="Введите номер или название задачи: "
TASK_OPTIONS=("text_generation" "embeddings" "rerank" "image_generation")
TASK=""

while [[ -z "$TASK" ]]; do
    select task_choice in "${TASK_OPTIONS[@]}"; do
        if [[ -n "$task_choice" ]]; then
            TASK="$task_choice"
            break
        elif [[ -n "$REPLY" ]]; then
            # Проверка, если пользователь ввел текстом
            for option in "${TASK_OPTIONS[@]}"; do
                if [[ "$REPLY" == "$option" ]]; then
                    TASK="$option"
                    break 2
                fi
            done
            if [[ -z "$TASK" ]]; then
                echo -e "${RED}Неверный выбор. Попробуйте снова.${NC}"
            fi
        fi
        break
    done
done

echo -e "${BLUE}Выбрана задача: $TASK${NC}"

# Выбор целевого устройства (TARGET_DEVICE)
echo -e "\n${YELLOW}Выберите целевое устройство:${NC}"
PS3="Введите номер или название устройства: "
DEVICE_OPTIONS=("CPU" "GPU" "MULTI" "HETERO")
TARGET_DEVICE=""

while [[ -z "$TARGET_DEVICE" ]]; do
    select device_choice in "${DEVICE_OPTIONS[@]}"; do
        if [[ -n "$device_choice" ]]; then
            TARGET_DEVICE="$device_choice"
            break
        elif [[ -n "$REPLY" ]]; then
            # Проверка, если пользователь ввел текстом
            for option in "${DEVICE_OPTIONS[@]}"; do
                if [[ "${REPLY^^}" == "$option" ]]; then
                    TARGET_DEVICE="$option"
                    break 2
                fi
            done
            if [[ -z "$TARGET_DEVICE" ]]; then
                echo -e "${RED}Неверный выбор. Попробуйте снова.${NC}"
            fi
        fi
        break
    done
done

echo -e "${BLUE}Выбрано устройство: $TARGET_DEVICE${NC}"

# Определяем версию образа в зависимости от устройства
if [[ "$TARGET_DEVICE" == "GPU" ]]; then
    DOCKER_IMAGE="openvino/model_server:latest-gpu"
else
    DOCKER_IMAGE="openvino/model_server:latest"
fi

echo -e "\n${BLUE}Конфигурация:${NC}"
echo -e "  Модель: $SOURCE_MODEL"
echo -e "  Организация: $MODEL_ORG"
echo -e "  Имя: $MODEL_NAME"
echo -e "  Задача: $TASK"
echo -e "  Устройство: $TARGET_DEVICE"
echo -e "  Docker образ: $DOCKER_IMAGE"


# Шаг 1: Скачиваем модель
echo -e "\n${GREEN}[1/3] Загрузка модели $SOURCE_MODEL...${NC}"
docker run --rm -u $(id -u) \
  -v "$MODEL_DIR":/models:rw \
  "$DOCKER_IMAGE" \
  --pull \
  --source_model "$SOURCE_MODEL" \
  --target_device "$TARGET_DEVICE" \
  --task "$TASK" \
  --model_repository_path /models

if [ $? -ne 0 ]; then
    echo -e "${RED}Ошибка при загрузке модели!${NC}"
    exit 1
fi

# Шаг 2: Добавляем модель в конфиг
echo -e "${GREEN}[2/3] Добавление модели в config.json...${NC}"
docker run --rm -u $(id -u) \
  -v "$MODEL_DIR":/models:rw \
  openvino/model_server:latest \
  --add_to_config /models \
  --model_name "$MODEL_NAME" \
  --model_repository_path /models/"$MODEL_ORG"

if [ $? -ne 0 ]; then

    echo -e "${RED}Ошибка при добавлении модели в конфиг!${NC}"
    exit 1
fi

# Шаг 3: Выводим список моделей
echo -e "${GREEN}[3/3] Список доступных моделей:${NC}"
docker run --rm -u $(id -u) \
  -v "$MODEL_DIR":/models:rw \
  openvino/model_server:latest \
  --list_models \
  --model_repository_path /models

echo -e "\n${BLUE}✓ Готово! Модель $MODEL_NAME загружена и добавлена в конфигурацию.${NC}"

Файл с переменными окружения, ниже в статье описано, что там такое написано и как достать.

.env

i3draven@ovms:~/ovms$ cat ./.env 
RENDER_GID=993
YOUR_UID=1000
i3draven@ovms:~/ovms$ 

docker-compose.yml для запуска сервера, причем со всеми скачанными моделями сразу сработает. Скрипт можно много раз запустить.

docker-compose.yml

i3draven@ovms:~/ovms$ cat ./docker-compose.yml 
services:
  ovms-genai:
    image: openvino/model_server:latest-gpu
    container_name: ovms-genai
    user: "${YOUR_UID}:${YOUR_UID}"
    devices:
      - /dev/dri:/dev/dri
    group_add:
      - "${RENDER_GID}"
    volumes:
      - /home/i3draven/ovms/models:/models:ro
      - /home/i3draven/ovms/models/config.json:/opt/ml/config.json:ro
    ports:
      - "8000:8000"
      - "9000:9000"
    command:
      - --config_path
      - /opt/ml/config.json
      - --port
      - "9000"
      - --rest_port
      - "8000"
    #restart: unless-stopped

Пример запуска

i3draven@ovms:~/ovms$ curl http://localhost:8000/v3/chat/completions   -H "Content-Type: application/json"   -d '{"model":"Qwen2.5-7B-Instruct-int8-ov","messages":[{"role": "system", "content": "Ты полезный ассистент отвечающий на русском языке."},{"role":"user","content":"Hello"}],"max_tokens":250}' | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   590  100   360  100   230     57     36  0:00:06  0:00:06 --:--:--    89
{
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "logprobs": null,
      "message": {
        "content": "Здравствуйте! Как я могу вам помочь сегодня?",
        "role": "assistant",
        "tool_calls": []
      }
    }
  ],
  "created": 1764105373,
  "model": "Qwen2.5-7B-Instruct-int8-ov",
  "object": "chat.completion",
  "usage": {
    "prompt_tokens": 35,
    "completion_tokens": 17,
    "total_tokens": 52
  }
}

Сервер сам все скачает и запустит. Но если интересно понять немного больше о том, что это все такое, то можно прочитать и дальше.

Шаг 0: Настройка Proxmox и проброс GPU в LXC

Есть масса статей на эту тему, но как руками отредактировать конфиги LXC контейнеров, на деле все можно сделать в два клика в UI Proxmox, если знать что делать и как.

1. Установка драйверов Intel на хост Proxmox

Обратите внимание, что установка драйверов на хост это действие противоположное пробросу GPU в виртуалки, вполне вероятно это несовместимые подходы в рамках одного хоста. Подробности можно посмотреть тут и тут

Подключитесь к хосту Proxmox по SSH и выполните следующие команды:

Команды

# Установка зависимостей
apt-get update && apt-get install -y wget gpg

# Добавление ключа репозитория Intel
wget -qO - https://repositories.intel.com/gpu/intel-graphics.key | \
  gpg --yes --dearmor --output /usr/share/keyrings/intel-graphics.gpg

# Добавление репозитория Intel GPU, я ставил сразу noble, но вероятно можно bookworm.
cat > /etc/apt/sources.list.d/intel-gpu.list << 'EOF'
deb [arch=amd64 signed-by=/usr/share/keyrings/intel-graphics.gpg] https://repositories.intel.com/gpu/ubuntu noble client
EOF

# Обновление списка пакетов и установка драйверов
apt-get update
apt-get install -y \
  intel-opencl-icd \
  intel-media-va-driver-non-free \
  ocl-icd-libopencl1 \
  clinfo \
  intel-gpu-tools

Проверьте, что драйвер загружен, возможно нужно будет reboot Proxmox хоста:

Команды

clinfo

Увидите свой GPU в списке.

2. Сбор необходимой информации

На хосте Proxmox:

Проверьте список устройств GPU, именно их нужно будет потом добавлять, у вас будут свои вероятно.

Команды

root@pve:~# ls /dev/dri
by-path  card1  renderD128

Узнайте GID группы render (запишите это число)

root@pve:~# stat -c '%g' /dev/dri/renderD128
993

Внутри LXC контейнера:

Для простоты нам нужен контейнер с ubuntu 24.04, под него вся среда у Intel заточена. При этои мы будем использовать возможности Intel Xe GPU и легко то же самое сделать с CPU или даже обоими. Просто потому, что у меня эта встройка есть на сервере и ее для моих задач достаточно. Но, конечно примерно таким же образом можно настроить и другие GPU, под Nvidia так вообще есть полные подробные гайды. Использовать будем OpenVINO models server, подробности: тут,тут,тут,тут,тут,тут,тут,тут,тут,тут

Я привел серию статей включая статьи про ollama что бы было ясно, что можно ollama сделать фронтендом для интеловских поделок, но я не стал, так как у intel есть свой собственный сервер, который поддерживает API доступа по http и нормально работает без дополнительных прослоек. Правда прослойки конечно могут делать что-то полезное типа конвертации моделей, но мне пойдет и так.

Команды

# Узнайте UID вашего пользователя внутри LXC (запишите это число)
id -u

3. Настройка проброса GPU через веб-интерфейс Proxmox

1. В веб-интерфейсе Proxmox выберите ваш LXC-контейнер

2. Откройте вкладку «Ресурсы» (Resources)

3. Нажмите «Добавить» (Add) → «Проброс устройства» (Device Passthrough). Особо обратите внимание на то, что Device Passthrough доступен только если вы зашли в WebUI под пользователем root.

4. Добавьте устройство /dev/dri/renderD128, в расширенных настройках (advanced галка) нужно задать GID от группы render на хосте Proxmox (у меня 993), который мы ранее достали и UID пользователя в LXC контейнере, которому надо дать доступ (у меня 1000, это тот, что записывали). Так же можно указать права доступа, но по умолчанию они заданы и так достаточные, можно не трогать.

5. Повторите для устройства /dev/dri/card1

4. Отключение AppArmor для контейнера

Недавний баг в Proxmox не дает использовать вложенные docker контейнеры внутри LXC, поправим. Но может его исправят, уже патч был когда я писал статью. Так что если не видите ошибок при старте docker контейнера внутри LXC контейнера, то не нужно. На хосте Proxmox выполните:

Команды

# Замените 100 на ID вашего контейнера
nano /etc/pve/lxc/${lxc_container_id}.conf

Добавьте в конец файла:

Команды

lxc.apparmor.profile: unconfined
lxc.mount.entry: /dev/null sys/module/apparmor/parameters/enabled none bind 0 0

Так будет примерно выглядеть:

Команды

arch: amd64
cores: 8
dev0: /dev/dri/card1,gid=993,uid=1000
dev1: /dev/dri/renderD128,gid=993,uid=1000
features: nesting=1
hostname: ubuntu.24.04
memory: 16768
nameserver: 10.0.40.1
net0: name=eth0,bridge=services,hwaddr=BC:24:11:CD:8A:8F,ip=dhcp,tag=40,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-btrfs:107/vm-107-disk-0.raw,mountoptions=discard,size=64G
swap: 0
unprivileged: 1
lxc.apparmor.profile: unconfined
lxc.mount.entry: /dev/null sys/module/apparmor/parameters/enabled none bind 0 0

Сохраните файл и перезапустите контейнер через веб-интерфейс или pct stop ID/pct start ID. Обратите внимание, что контейнер у меня настроен так, что он работает внутри VLAN, что сделано в моей домашней инфраструктуре и описано тут, вернее написано, что хорошо бы сделать.

5. Установка драйверов в LXC-контейнере

Войдите в консоль LXC, в моей инфраструктуре нет доступа по ssh снаружи к контейнерам, так что войти можно:

1. Web console

2. pct enter ID на хосте Proxmox куда по ssh из внутренней сети можно зайти

3. или ssh если настроено

Команды

# Установка зависимостей
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install -y wget gpg mc jq curl docker-compose-v2 tree

# Добавление ключа репозитория Intel
wget -qO - https://repositories.intel.com/gpu/intel-graphics.key | \
  sudo gpg --yes --dearmor --output /usr/share/keyrings/intel-graphics.gpg

# Добавление репозитория (для Ubuntu 24.04 'noble')
# Измените 'noble' на кодовое имя вашего дистрибутива, если необходимо, но рекомендую именно этот
cat > /tmp/intel-gpu.list << 'EOF'
deb [arch=amd64 signed-by=/usr/share/keyrings/intel-graphics.gpg] https://repositories.intel.com/gpu/ubuntu noble client
EOF
sudo mv /tmp/intel-gpu.list /etc/apt/sources.list.d/intel-gpu.list

# Установка драйверов и утилит
sudo apt-get update
sudo apt-get install -y \
  intel-igc-cm \
  intel-opencl-icd \
  intel-media-va-driver-non-free \
  ocl-icd-libopencl1 \
  clinfo \
  intel-gpu-tools

# Добавление пользователя в группы video и render
sudo usermod -aG video,render $USER
sudo usermod -aG docker $USER
# Применение изменений для текущей сессии
newgrp docker
newgrp render
newgrp video

Проверьте доступ к GPU:

Команды

clinfo

В выводе будет название вашей видеокарты, у меня так:

Команды

i3draven@ubuntu:~$ clinfo |tail -n 10
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  Success (1)
    Platform Name                                 Intel(R) OpenCL Graphics
    Device Name                                   Intel(R) Iris(R) Xe Graphics

ICD loader properties
  ICD loader Name                                 OpenCL ICD Loader
  ICD loader Vendor                               OCL Icd free software
  ICD loader Version                              2.3.2
  ICD loader Profile                              OpenCL 3.0

Все, проброс GPU из Proxmox хоста в LXC контейнер готов!

Шаг 1: Развертывание OpenVINO Model Server

Это как раз сервер, который поддерживает API для доступа к инференсу и эмбеддингам. Сам процесс будет из нескольких этапов:

1. Скачать модель

2. Конвертировать, если нет готовой, ее в формат, понятный OpenVINO, в процессе можно квантизовать и оптимизировать.
   Нужно отметить, что есть и готовые модели, уже в формате openvino их конвертировать не нужно, но выбор не велик, их можно искать по “ov” или “openvino” в имени. В статье про интеграцию с ollama целая пачка показана.

3. Развернуть сервер с нужной моделью. Причем особо стоит отметить, что я использую только embeddings модели для своих нужд, но если хочется чатбота, то есть OpenVINO GenAI, который работает поверх OpenVINO Runtime и специально заточен под LLM. Описан тут и тут. Он встроен в контейнер с OVMS насколько я понимаю. Так же этот же OpenVINO умеет еще море всего, генерировать картинки, говорить и так далее. Все для вас.

4. PROFIT

1: Поиск моделей для конвертации

Все следующие команды выполняются внутри LXC-контейнера. Для работы мне нужны будут embedding модели, то есть те, которые строят “вектора смысла” для текста. Причем желательно с встроенным токенизатором что бы не возиться с этим отдельно. Но сервер поддерживает и LLM модели, что в документации описано и так хорошо, не стану расписывать, LLM проще.

Найдите подходящие embedding-модели на Hugging Face:

Команды

curl -s "https://huggingface.co/api/models?search=embedding" | \
  jq -r '.models[] | "\(.id) - \(.downloads) загрузок"'

Эта команда выведет список моделей с количеством загрузок. Выберите нужную модель, например, BAAI/bge-large-en-v1.5. Так же есть инструмент для скачивания моделей тут, можно использовать и его.

Помимо прочего OVMS умеет и сам качать модели вот тут подробности и даже сразу же сам их конвертировать, что описано тут

Обратите внимание, что конвертировать модели может быть сложным и запутанным процессом, есть масса готовых тут, скачать их можно просто с помощью этого, каталог и так содержит почти триста моделей на все вкусы. Скачать можно одной командой в итоге hf download OpenVINO/Qwen3-Embedding-0.6B-int8-ov --local-dir ~/ovms_models/bge-m3-int4-ov просто имя модели нужной задать.

Но что бы было ясно как в случае надобности конвертировать есть следующий шаг.

Шаг 2: Подготовка и конвертация модели

1. Создание рабочей директории

Команды

# Создайте папку для работы
mkdir -p ~/ovms-embeddings
cd ~/ovms-embeddings

# Создайте папку для моделей
mkdir -p ./models

2. Конвертация модели в формат OpenVINO

Тут есть ряд проблем. Дело в том, что если запустить Intel контейнер в режиме --pull то есть, скачивать модель и потом автоматически конвертировать, то он скачает и конвертирует, но там не будет токенизатор конвертироваться (параметр стоит --disable-convert-tokenizer), не знаю зачем они эту граблю положили туда. Потому мы могли бы скачать и конвертировать как описано в документации:

Команды

docker run --device /dev/dri --group-add=$(stat -c "%g" /dev/dri/render* | head -n 1) --user $(id -u):$(id -g) --rm -v $(pwd)/models:/models:rw openvino/model_server:latest-py --pull --source_model "BAAI/bge-large-en-v1.5" --model_repository_path /models --model_name bge-large-en-v1.5 --target_device GPU --task embeddings --weight-format int8 --log_level DEBUG --overwrite_models --num_streams 8

Но запустим все это напрямую вызвав optimum-cli, выглядит так:

Команды

docker run --device /dev/dri --group-add=$(stat -c "%g" /dev/dri/render* | head -n 1)   --user $(id -u):$(id -g) --rm   -v $(pwd)/models:/models   --entrypoint /usr/local/bin/optimum-cli   openvino/model_server:latest-py   export openvino   --model BAAI/bge-large-en-v1.5   --weight-format int8   --trust-remote-code   --num-samples 8   --library sentence_transformers   --task feature-extraction   ./models/BAAI/bge-large-en-v1.5

Если вдруг будут проблемы и я где то не углядел, а первая команда из докунметации скачала и закэшировала модель, потому вторая ее может сразу не качая использовать, то просто выполните обе команды по очереди. Но на данный момент я думаю второй достаточно для всего.
Мы просто напрямую запускаем optimim-cli с нужными параметрами. Хочу отдельно отметить, что для конвертации используется optimum-cli, эту штуку не плохо бы посмотреть подробнее так как она позволяет подогнать модели под свое железо и оптимизировать их. Есть вагон параметров. Вот полный вывод команд с структурой папок:

Команды

i3draven@ubuntu:~$ cd ./ovms-embeddings/
i3draven@ubuntu:~/ovms-embeddings$ ls
models
i3draven@ubuntu:~/ovms-embeddings$ docker run --device /dev/dri --group-add=$(stat -c "%g" /dev/dri/render* | head -n 1) --user $(id -u):$(id -g) --rm -v $(pwd)/models:/models:rw openvino/model_server:latest-py --pull --source_model "BAAI/bge-large-en-v1.5" --model_repository_path /models --model_name bge-large-en-v1.5 --target_device GPU --task embeddings --weight-format int8 --log_level DEBUG --overwrite_models --num_streams 8
Unable to find image 'openvino/model_server:latest-py' locally
latest-py: Pulling from openvino/model_server
baa9e71a063a: Pull complete 
a76d3e698922: Pull complete 
5bdd5c6068df: Pull complete 
e1d63ab00fa2: Pull complete 
97f5e74b6399: Pull complete 
9cd7a4880448: Pull complete 
f2fd7d158b30: Pull complete 
5774c385c156: Pull complete 
0864fefc1d57: Pull complete 
1a83f47c7fa9: Pull complete 
16efed5f6d0e: Pull complete 
47a75649fb3d: Pull complete 
21b1671afd79: Pull complete 
912688daea51: Pull complete 
94b691fcc499: Pull complete 
Digest: sha256:5431ac5989c3ae548cb8c954f6caf2a2fafa72ab254fbf90ab5db26381ddd9b8
Status: Downloaded newer image for openvino/model_server:latest-py
[2025-11-17 15:37:04.180][1][serving][debug][optimum_export.cpp:144] Optimum-cli executable is present
[2025-11-17 15:37:04.180][1][serving][debug][optimum_export.cpp:180] Executing command: optimum-cli export openvino --disable-convert-tokenizer --task feature-extraction --library sentence_transformers --model BAAI/bge-large-en-v1.5 --trust-remote-code  --weight-format int8 /models/BAAI/bge-large-en-v1.5
/usr/local/lib/python3.12/dist-packages/torch/onnx/_internal/registration.py:162: OnnxExporterWarning: Symbolic function 'aten::scaled_dot_product_attention' already registered for opset 14. Replacing the existing function with new function. This is unexpected. Please report it on https://github.com/pytorch/pytorch/issues.
  warnings.warn(
`SentenceTransformer._target_device` has been deprecated, please use `SentenceTransformer.device` instead.
`SentenceTransformer._target_device` has been deprecated, please use `SentenceTransformer.device` instead.
`loss_type=None` was set in the config but it is unrecognised.Using the default loss: `ForCausalLMLoss`.
Model: BAAI/bge-large-en-v1.5 downloaded to: /models/BAAI/bge-large-en-v1.5
[2025-11-17 15:37:40.150][1][serving][debug][filesystem.cpp:191] Creating file /models/BAAI/bge-large-en-v1.5/graph.pbtxt
Graph: graph.pbtxt created in: /models/BAAI/bge-large-en-v1.5
i3draven@ubuntu:~/ovms-embeddings$ tree .
.
`-- models
    `-- BAAI
        `-- bge-large-en-v1.5
            |-- config.json
            |-- graph.pbtxt
            |-- openvino_model.bin
            |-- openvino_model.xml
            |-- special_tokens_map.json
            |-- tokenizer.json
            |-- tokenizer_config.json
            `-- vocab.txt

4 directories, 8 files
i3draven@ubuntu:~/ovms-embeddings$ docker run --device /dev/dri --group-add=$(stat -c "%g" /dev/dri/render* | head -n 1)   --user $(id -u):$(id -g) --rm   -v $(pwd)/models:/models   --entrypoint /usr/local/bin/optimum-cli   openvino/model_server:latest-py   export openvino   --model BAAI/bge-large-en-v1.5   --weight-format int8   --trust-remote-code   --num-samples 8   --library sentence_transformers   --task feature-extraction   ./models/BAAI/bge-large-en-v1.5
/usr/local/lib/python3.12/dist-packages/torch/onnx/_internal/registration.py:162: OnnxExporterWarning: Symbolic function 'aten::scaled_dot_product_attention' already registered for opset 14. Replacing the existing function with new function. This is unexpected. Please report it on https://github.com/pytorch/pytorch/issues.
  warnings.warn(
`SentenceTransformer._target_device` has been deprecated, please use `SentenceTransformer.device` instead.
`SentenceTransformer._target_device` has been deprecated, please use `SentenceTransformer.device` instead.
`loss_type=None` was set in the config but it is unrecognised.Using the default loss: `ForCausalLMLoss`.
INFO:nncf:Statistics of the bitwidth distribution:
┍━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┑
│ Weight compression mode   │ % all parameters (layers)   │ % ratio-defining parameters (layers)   │
┝━━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┥
│ int8_asym                 │ 100% (147 / 147)            │ 100% (147 / 147)                       │
┕━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┙
Applying Weight Compression ━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% • 0:00:02 • 0:00:00
i3draven@ubuntu:~/ovms-embeddings$ tree .
.
`-- models
    `-- BAAI
        `-- bge-large-en-v1.5
            |-- config.json
            |-- graph.pbtxt
            |-- openvino_detokenizer.bin
            |-- openvino_detokenizer.xml
            |-- openvino_model.bin
            |-- openvino_model.xml
            |-- openvino_tokenizer.bin
            |-- openvino_tokenizer.xml
            |-- special_tokens_map.json
            |-- tokenizer.json
            |-- tokenizer_config.json
            `-- vocab.txt

4 directories, 12 files

Собственно мы добивались появления openvino_detokenizer.bin, openvino_detokenizer.xml когда запускали отдельно конвертацию токенизатора.

Далее просто пример нам это не нужно. Можно сделать конвертацию и полностью из кода или даже токенизатор использовать свой это не то что бы сложно, но предположим, что хотим не возиться. Далее пример вовсе конвертации модели скриптом, эта страшная весчь делает простое действие, качает скрипт, который и конвертирует модель. Только имя модели поменять и параметры конвертации. --weight-format это квантизация, --target_device это собственно под, что затачивать будем, CPU/GPU. Есть гибридные варианты, но я не стал копаться и так мне достаточно. Гибридные, GPU+CPU, описаны тут, так же там описано как использовать NPU от intel, но первые варианты NPU ограниченны относительно возможностей GPU. Работает этот вариант конвертации значительно дольше так как зависимости долго ставит в контейнере. Просто для примера привел.

Команды

docker run --rm \
  --user $(id -u):$(id -g) \
  -v $(pwd)/models:/workspace/models \
  -w /workspace \
  openvino/ubuntu24_dev:latest \
  bash -c "\
    curl -L https://raw.githubusercontent.com/openvinotoolkit/model_server/refs/heads/releases/2025/3/demos/common/export_models/export_model.py -o export_model.py && \
    pip install -r https://raw.githubusercontent.com/openvinotoolkit/model_server/refs/heads/releases/2025/3/demos/common/export_models/requirements.txt && \
    python3 export_model.py embeddings_ov \
      --source_model BAAI/bge-large-en-v1.5 \
      --weight-format fp16 \
      --target_device GPU \
      --config_file_path /workspace/models/config.json \
      --model_repository_path /workspace/models"

После скрипта нужно исправление конфигурации графа. Скрипт экспорта, тот страшный выше в ненужном примере, добавляет параметр NUM_STREAMS, который может вызывать проблемы при работе с GPU. Проблемы можно увидеть в логах сервера при старте и если нужно, можно отредактировать или удалить данный раздел конфига графа вычислений. Это именно конфиг графа вычислений, не конфига сервера:

Команды

# Удалите проблемную строку из graph.pbtxt
sed -i '/plugin_config: \'\'\'{"NUM_STREAMS": 1}\'\'\'/d' \
  ./models/BAAI/bge-large-en-v1.5/graph.pbtxt

Проверьте, что строка удалена:

Команды

# Просмотрите содержимое файла
cat ./models/BAAI/bge-large-en-v1.5/graph.pbtxt

В файле не должно быть упоминания NUM_STREAMS. Редактировать можно с nano/vi чем угодно конечно. Но в случае если вы использовали конвертацию с докером и optimum-cli, это не нужно все, привел для упрощения поиска граблей желающим погрузиться в ручной труд.
Докер в данном случае спасает от установки среды разработки этого всего барахла и там совместить все версии всего так что бы оно работало ох как не просто. Можете посмотреть отдельно контейнер для разработчика, описано тут. Так же обратите внимание, что мы используем контейнер для конвертации openvino/model_server:latest-py, запускать будем openvino/model_server:latest-gpu, а для разработки вовсе нужен openvino/ubuntu24_dev и там в каждом полная среда настроена.

3. Создание файла конфигурации

Теперь снова то, что нам нужно. Для того что бы сервер нашел модель или модели нужен файл конфигурации:

Команды

i3draven@ubuntu:~/ovms-embeddings$ cat ./models/config.json 
{
    "model_config_list": [{
        "config": {
            "name": "BAAI/bge-large-en-v1.5",
            "base_path": "/models/BAAI/bge-large-en-v1.5",
            "target_device": "GPU"
        }
    }],
    "mediapipe_config_list": [{
        "name": "BAAI/bge-large-en-v1.5",
        "graph_path": "/models/BAAI/bge-large-en-v1.5/graph.pbtxt"
    }]
}

Посмотреть подробности и даже несколько моделей одновременно что бы было, можно тут.
Где-то в логах мелькало, что при конвертации взят только первый слой графа или что-то подобное, но я пока вникать не стал и без того пришлось перелопатить много всего, не уверен даже, что это в итоговый заход попало с этими командами, но, можете повнимательнее посмотреть логи.

4. Проверка результата

Вы должны увидеть папки с моделью, токенизатором и файлом config.json. Примерно такие:

Команды

i3draven@ubuntu:~/ovms-embeddings$ tree .
.
|-- docker-compose.yml <-- # еще сделаем
`-- models
    |-- BAAI
    |   `-- bge-large-en-v1.5
    |       |-- config.json
    |       |-- graph.pbtxt
    |       |-- openvino_detokenizer.bin
    |       |-- openvino_detokenizer.xml
    |       |-- openvino_model.bin
    |       |-- openvino_model.xml
    |       |-- openvino_tokenizer.bin
    |       |-- openvino_tokenizer.xml
    |       |-- special_tokens_map.json
    |       |-- tokenizer.json
    |       |-- tokenizer_config.json
    |       `-- vocab.txt
    `-- config.json

4 directories, 14 files

Шаг 3: Создание конфигурации Docker Compose

1. Создание файла .env

Создайте файл с переменными окружения, используя GID который вы записали в самом начале.

Команды

# Замените 993 GID был уменя, ваш GID группы render с хоста Proxmox будет совпадать с LXC
echo "RENDER_GID=$(stat -c '%g' /dev/dri/renderD128)" > .env
# Замените 1000 на ваш UID пользователя в LXC (если отличается)
echo "YOUR_UID=$(id -u)" >> .env

# Проверьте содержимое файла
cat .env

Вывод должен быть примерно таким:

Команды

RENDER_GID=993
YOUR_UID=1000

2. Создание файла docker-compose.yml

Тут все просто, поднимаем сервер, указываем ему конфиг и порт на котором работать:

Команды

cat > docker-compose.yml << 'EOF'
services:
  bge-large-embeddings:
    image: openvino/model_server:latest-gpu
    container_name: bge-large-embeddings
    user: "${YOUR_UID}:${YOUR_UID}"
    ports:
      - "8001:8000"
    devices:
      - /dev/dri:/dev/dri
    group_add:
      - "${RENDER_GID}"
    volumes:
      - ./models:/models:ro
    command: >
      --config_path /models/config.json
      --rest_port 8000
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
EOF

Шаг 4: Запуск и проверка сервера

1. Запуск сервера

Команды

# Запустите сервер в фоновом режиме
docker compose up -d

2. Мониторинг запуска

Команды

# Просмотр логов контейнера в реальном времени
docker compose logs -f

Дождитесь сообщения о том, что сервер запущен и модель загружена. Обычно это занимает 15-20 секунд. Для выхода из просмотра логов нажмите Ctrl+C.

3. Проверка статуса контейнера

Команды

# Проверьте, что контейнер запущен
docker compose ps

Вы должны увидеть контейнер bge-large-embeddings в статусе Up.

4. Отправка тестового запроса

OVMS поддерживает довольно обширное API, описанное тут и может маскироваться под самые разные сервера. Так можно получить состояние модели:

Команды

i3draven@openvino:~/openvino/big$ curl http://localhost:8001/v1/config
{
"BAAI/bge-large-en-v1.5" : 
{
 "model_version_status": [
  {
   "version": "1",
   "state": "AVAILABLE",
   "status": {
    "error_code": "OK",
    "error_message": "OK"
   }
  }
 ]
}

Так можно получить собственно то, ради чего все затевалось, а именно embedding вектор для заданного текста

Команды

# Отправьте запрос на получение эмбеддинга
curl -X POST http://localhost:8001/v3/embeddings \
  -H "Content-Type: application/json" \
  -d '{
    "model": "BAAI/bge-large-en-v1.5",
    "input": "The entire stack, from Proxmox to OVMS, is fully operational."
  }' | jq

Вы должны получить JSON-ответ с векторным представлением текста, примерно такого вида:

Json

{
  "object": "list",
  "data": [
    {
      "object": "embedding",
      "embedding": [0.123, -0.456, 0.789, ...],
      "index": 0
    }
  ],
  "model": "BAAI/bge-large-en-v1.5",
  "usage": {
    "prompt_tokens": 12,
    "total_tokens": 12
  }
}

5. Проверка использования GPU

Можно посмотреть нагрузку на GPU, но запускать нужно на Proxmox хосте, в LXC оно заработать не захотело и я не стал разбираться почему.

Команды

# В отдельном терминале запустите мониторинг GPU
intel_gpu_top

Выше изложена основа для того что бы на своем домашнем сервере завести себе LLM/Embedding модели, которые например будут полезны для тегирования фоточек, просто как чатботы или например для построения RAG системы через MCP для вашего любимого LLM на основе embedding моделей. В документации OpenVINO есть множество статей с примерами, рекомендую. Позже покажу для чего это мне нужно, наверное, как кобычно по настроению. Выдался просто выходной внеочередной.

Прошлая статья была посвящена базовой настройке. Что сейчас я имею в итоге:

1. Домашний сервер Asus NUC, на нем установлен Proxmox, правда я не стал ставить на десктопный Debian, так как передумал делать ему красивую панельку с экранчиком, а значит графический интерфейс ему не нужен и можно просто поставить с iso образа, который предоставляют авторы Proxmox.

2. Роутер к которому подключен сервер и домашняя техника, например мой ноутбук. На роутере OpenWRT. Интернет обычный домашний, без статического IP адреса.

3. VPS в интернете за три копейки с ubuntu 25.04 server. Проверьте что бы у VPS IP адрес в базах спамеров и прочих блок листах не был, а то сайты вас пускать не будут :) Проверить можно тут, там есть `blacklist check`.

Задача:

1. Установить домашний сервис в изолированном окружении.

2. Предоставить доступ к домашним сервисам из интернета.

3. Сохранить доступ к админкам из домашней сети.

Начнем. Заранее предупрежу, что вероятно некоторые настройки, описанные в статье так как я их помню, но должны быть сделаны раньше чем в статье, уж как помню, прочитайте статью целиком прежде чем начать делать.

Обратите внимание, что так как нейронки сейчас отлично могут советовать настройки, если что не ясно, спросите их, просто скопипастив кусок статьи. В случае возникновения проблем, проще всего диагностировать их так, заходите в терминал всех сервисов и серверов, по ssh или в proxmox console и на каждом интерфейсе каждого сервиса запускаете tcpdump -i ${название интерфейсов сетевых}, после чего делаете коннект к VPS или ping и смотрите через какие интерфейсы и что пролетело. Можно отфильтровать лишнее например ssh коннект свой из ловли, что бы контекст нейронки не переполнить, они в целом хорошо понимают до 3к строк текста всего, обычно, по моему опыту. Причем даже если прислать больше они нередко отрезают первые 5к строк кодом на питоне самодельным, так что делите на части. Потом наловленное скармливаете нейронке и просите проанализировать. Она быстро вам опишет где цепочка передачи данных оборвалась.

При этом, нейронку можно попросить написать скрипты, которые скинут в файл настройки фаерволов, таблицы маршрутизации и интерфейсы сетевые, что бы ей можно было промпты потом из этого делать быстро, файл итоговый приложил и все. Я такой скрипт на своему ноутбуке запускаю, он подключается ко всем серверам, что описаны ниже и всю нужную информацию собирает в файл, это экономит дни диагностики проблем.

Первое, что нужно сделать это настроить OpenWRT так что бы br-lan, интерфейс, который там создается сам, обслуживал две VLAN. В одной будет домашняя техника, во второй будет Proxmox. Это нужно что бы изолировать и обезопасить домашнюю технику. Заходим в LuCI в настройки Network->Interfaces->Devices->br-lan->Configure->Bridge VLAN filtering. Там создаем VLAN 100 и VLAN 200, разрешаем VLAN как таковые. В VLAN 200 будет Proxmox, сервер кабелем подключен к какому то LAN порту, вот его туда и добавить как Untagged. Untagged значит, что на стороне самого Proxmox никаких VLAN настроек мы делать не будем, он не будет ставить tags. Остальные порты добавляем в VLAN 100 так же Untagged. Этим мы разделим домашнюю сеть на две подсети, в которых будут отдельно обитать наши сервисы и домашняя техника. Так же нужно добавить пару правил firewall. Я не буду расписывать кнопки это долго, приведу конфиги, которые получатся в итоге и нейронка вам расскажет, что жать.

Это конфиг сети:

Скрытый текст

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'fd61:eb10:9fdd::/48'
    option packet_steering '1'

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4'
    option ipv6 '0'

config interface 'lan'
    option device 'br-lan.100'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ipv6 'off'

config interface 'wan'
    option device 'wan'
    option proto 'dhcp'
    option peerdns '0'
    list dns '9.9.9.9'
    list dns '149.112.112.112'
    option ipv6 'off'

config device
    option name 'phy1-ap0'
    option ipv6 '0'

config device
    option name 'phy0-ap0'
    option ipv6 '0'

config device
    option name 'wan'
    option ipv6 '0'

config device
    option name 'miireg'
    option ipv6 '0'

config device
    option name 'lan4'
    option ipv6 '0'

config device
    option name 'lan3'
    option ipv6 '0'

config device
    option name 'lan2'
    option ipv6 '0'

config device
    option name 'lan1'
    option ipv6 '0'

config device
    option name 'br-wan'
    option type 'bridge'
    list ports 'wan'
    option mtu '1500'
    option ipv6 '0'

config bridge-vlan
    option device 'br-lan'
    option vlan '100'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'

config bridge-vlan
    option device 'br-lan'
    option vlan '200'
    list ports 'lan4'

config interface 'proxmox'
    option proto 'static'
    option device 'br-lan.200'
    option ipaddr '192.168.2.1'
    option netmask '255.255.255.0'

Это конфиг firewall:

Скрытый текст

root@OpenWrt:~# cat /etc/config/firewall

config defaults
    option input 'DROP'
    option output 'DROP'
    option forward 'REJECT'
    option synflood_protect '1'
    option drop_invalid '1'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    list network 'lan'

config zone
    option name 'wan'
    option input 'DROP'
    option output 'ACCEPT'
    option forward 'DROP'
    option mtu_fix '1'
    option masq '1'
    list network 'wan'

config forwarding
    option src 'lan'
    option dest 'wan'

config zone
    option name 'proxmox'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    list network 'proxmox'

config forwarding
    option src 'lan'
    option dest 'proxmox'

config rule
    option name 'Allow LAN to Proxmox Management'
    option src 'lan'
    option dest 'proxmox'
    option dest_ip '192.168.2.2'
    option dest_port '8006'
    option proto 'tcp'
    option target 'ACCEPT'

config rule
    option name 'Allow LAN to Proxmox SSH'
    option src 'lan'
    option dest 'proxmox'
    option dest_ip '192.168.2.2'
    option dest_port '22'
    option proto 'tcp'
    option target 'ACCEPT'

config rule
    option name 'Allow LAN to OPNsense Web'
    option src 'lan'
    option dest 'proxmox'
    option dest_ip '192.168.2.3'
    option dest_port '443'
    option proto 'tcp'
    option target 'ACCEPT'

config rule
    option name 'Allow LAN to OPNsense HTTP'
    option src 'lan'
    option dest 'proxmox'
    option dest_ip '192.168.2.3'
    option dest_port '80'
    option proto 'tcp'
    option target 'ACCEPT'

config rule
    option src 'lan'
    option dest 'proxmox'
    option name 'Allow LAN to Proxmox icmp'
    list proto 'icmp'
    option target 'ACCEPT'

config forwarding
    option src 'proxmox'
    option dest 'wan'

config rule
    option src 'proxmox'
    option name 'Allow-ICMP-from-Proxmox'
    list proto 'icmp'
    option target 'ACCEPT'

config rule
    option src 'proxmox'
    option target 'ACCEPT'
    option name 'Proxmox DNS to OpenWRT'
    option dest_port '53'
    list proto 'tcp'
    list proto 'udp'

config rule
    option src 'proxmox'
    option dest 'lan'
    option name 'Block proxmox to LAN'
    list proto 'all'
    option target 'REJECT'

Тут нужно отметить, что Proxmox сервер у меня настроен с статическим адресом, выдавать серверу адрес по DHCP кажется излишним. Некоторые правила, не относящиеся к задаче я убрал.

По умолчанию в OpenWRT используется для локальнных адресов зона lan, я заменил ее на более правильную home.arpa, а так же добавил DNS записи для нужных мне локальных доменов. Это делается в настройках DNS, если нужно разберетесь, это просто удобство. Так что теперь я могу писать что то вроде proxmox.home.arpa в браузере и открывать админку. Но тут важно то, что Caddy понимает, что home.arpa это локальный адрес, а вот lan она не понимает и потому L4 Proxy, который нам нужен будет, с lan не будет работать.

Далее нужно создать в Proxmox сетевой мост, который будет изолирован от всего. Это позволит обеспечить полную изоляцию наших сервисов, которые мы выставим в интернет, не только внутри VLAN OpenWRT, но и внутри Proxmox хоста. Вот так будет в итоге выглядеть сеть в Proxmox, это все делается с UI, но итог проще показать в виде конфига:

Скрытый текст

root@pve:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface enp114s0 inet manual

iface enx000ec65482c4 inet manual

iface wlo1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.2.2/24
    gateway 192.168.2.1
    bridge-ports enx000ec65482c4
    bridge-stp off
    bridge-fd 0
    nameservers 192.168.2.1

auto services
iface services inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
#Internal services network

В прошлой статье я уже описывал как делать в Proxmox виртуалки, так что сейчас не стану делать это подбробно. Следующим нужно сделать виртуальную машину и установить туда OPNSense он, по моему скромному опыту, намного удобнее и стабильнее чем pf-sense, который я собирался использовать в прошлой статье, главное UI не глючный и все очень ясно описано. Это универсальный комбайн для firewall и, что нам понадобится, он имеет community plugin Caddy, это реверси прокси. Вот такая конфигурация VM где установлен OPNSense:

Скрытый текст

root@pve:~# qm config 100
boot: order=scsi0
cores: 4
cpu: x86-64-v2-AES
efidisk0: local-btrfs:100/vm-100-disk-0.raw,efitype=4m,pre-enrolled-keys=1,size=528K
machine: q35
memory: 8192
meta: creation-qemu=10.0.2,ctime=1761775163
name: opensense
net0: virtio=MAC,bridge=vmbr0,firewall=1,queues=4
net1: virtio=MAC,bridge=services,firewall=1,queues=4
numa: 0
onboot: 1
ostype: l26
parent: P4
scsi0: local-btrfs:100/vm-100-disk-1.raw,discard=on,iothread=1,size=64G
scsihw: virtio-scsi-single
smbios1: uuid=f0313399-c474-416a-9134-8b64b1585a5b
sockets: 1
vmgenid: edf40b71-8f32-46de-b31b-831768f16de4

В процессе установки OPNSense нужно в качестве WAN выбрать vmbr0 от Proxmox, а в качестве LAN выбрать мост services, изолирующий наши внутренние сервисы. В консоли OPNSense они будут называться vtnet0 vtnet1, соответственно. Для vtnet0 нужно задать статический адрес так же как для Proxmox, так как такому важному участнику сети выдавать адрес по DHCP кажется не разумным. В целом для VLAN 200 я DHCP отключил на OpenWRT, потому, что в процессе жизни этой инфраструктуры в VLAN 200 больше не появится никого нового.

Настройки firewall, приведенные выше, разрешают доступ из VLAN 100 то есть с домашнего ноутбука к VLAN 200, но не наоборот. Так что после того как VM OPNSense будет запущена можно будет с ноутбука зайти на адрес, заданный для OPNSense, в моем случае 192.168.2.3 и увидеть его админку. Напомню, что я настроил DNS имена в OpenWRT, так что я могу в браузере зайти на opnsense.home.arpa и попасть в админку. Вот такой у OPNSense итоговый конфиг сети на этом этапе настройки:

Скрытый текст

root@OPNsense:~ # ifconfig
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    description: WAN (wan)
    options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
    ether bc:24:11:99:e5:59
    inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255
    media: Ethernet autoselect (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vtnet1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    description: LAN (lan)
    options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
    ether bc:24:11:44:2a:46
    inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
    media: Ethernet autoselect (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Когда это сделано мы получаем ситуацию когда OPNSense является шлюзом для доступа во внешний мир для всех изолированных сервисов за мостом services. Так что весь их трафик проходит через него. Так как у нас есть изоляция OpenWRT firewall+VLAN, изоляция services внутри моста и OPNSense в качестве firewall, я отключил Proxmox firewall, слишком много было бы изоляций, да и к тому же Proxmox firewall постоянно ломался.

Следующим шагом нужно установить первый сервис, в качестве первого сервиса я выбрал xray. Для того что бы он работал нужно не так и много, есть отличная серия статей на эту тему статья1, статья2, статья3, статья4, статья5. Так же я нашел хорошее описание тут и тут. Итогом будет установка LXC контейнера с ubuntu, вот конфиг LXC контейнера:

Скрытый текст

root@pve:~# pct config 102
arch: amd64
cores: 2
features: nesting=1
hostname: xray
memory: 2048
nameserver: 10.0.0.1
net0: name=eth0,bridge=services,firewall=1,hwaddr=BC:24:11:9A:65:73,ip=dhcp,type=veth
ostype: ubuntu
parent: VPNWorks
rootfs: local-btrfs:102/vm-102-disk-0.raw,size=8G
swap: 0
unprivileged: 1

В LXC контейнере можно запускать вложенные docker контейнеры, так что внтутри я запустил xray в docker compose, так просто удобнее ничего не нужно настраивать, с таким docker-compose.yml:

Скрытый текст

root@xray:~# cat  /home/i3draven/panel/docker-compose.yml 
services:
  3xui:
    image: ghcr.io/mhsanaei/3x-ui:latest
    container_name: 3xui_app
    hostname: my.host.name # если надо
    volumes:
      - $PWD/db/:/etc/x-ui/
      - $PWD/cert/:/root/cert/
    environment:
      XRAY_VMESS_AEAD_FORCED: "false"
      XUI_ENABLE_FAIL2BAN: "true"
    tty: true
    network_mode: host
    restart: unless-stopped

После `docker compose up -d` контейнер будет запущен и готов к работе. В статьях, что я приводил выше описано как сделать соединение VLESS+Reality в админке. Тут нужно отметить, что именно VLESS+Reality наиболее продвинутый способ и я рекомендую именно его. Но в админку надо для начала попасть, для чего нам и нужен будет Caddy. Прежде чем устанавливать Caddy в OPNSense->System->Settings поменяйте порт, на котором будет работать админка OPNSense например на 8443, позже к ней мы доступ сделаем тоже через Caddy, мне так кажется удобным. Далее заходите в OPNSense и устанавливаете community plugin os-caddy.

После установки плагина нужно сделать несколько настроек в плагине. Тут важно понимать, что есть два разных механизма, первый это reverse proxy и второй L4 Proxy в Caddy. Первым мы предоставим доступ к админкам, он работает на L7 сетевом уровне, а вторым будет работать VLESS+Reality так как он нуждается в L4 уровне прокисрования. Вот такой конфиг для Caddy должен получится в итоге:

Скрытый текст

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# caddy_user=root

# Global Options
{
    log {
        output net unixgram//var/run/caddy/log.sock {
        }
        format json {
            time_format rfc3339
        }
        level DEBUG
    }

    servers {
        protocols h1 h2

        log_credentials
        listener_wrappers {
            layer4 {
                import /usr/local/etc/caddy/caddy.d/*.layer4listener

                @bea500f4-0d14-431d-9bba-87ec8df540f1 tls sni google.com www.google.com

                route @bea500f4-0d14-431d-9bba-87ec8df540f1 {
                    proxy tcp/10.0.0.199:8443 {
                    }
                }
            }
            tls
        }
    }

    layer4 {
        import /usr/local/etc/caddy/caddy.d/*.layer4global
    }

    email твоя почта
    grace_period 10s
    import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


# Layer4 default HTTP port
:80 {
}
# Layer4 default HTTPS port
:443 {
}

xray.home.arpa {
    tls /usr/local/etc/caddy/certificates/690295ae86977.pem /usr/local/etc/caddy/certificates/690295ae86977.key {
    }

    handle {
        @f376fb8a-12fa-4dd2-a249-7b9b93e20e38 {
            not client_ip 192.168.1.0/24
        }
        handle @f376fb8a-12fa-4dd2-a249-7b9b93e20e38 {
            abort
        }

        reverse_proxy 10.0.0.199:2053 {
        }
    }
}

opnsense.home.arpa {
    tls /usr/local/etc/caddy/certificates/690295ae86977.pem /usr/local/etc/caddy/certificates/690295ae86977.key {
    }

    handle {
        @f376fb8a-12fa-4dd2-a249-7b9b93e20e38 {
            not client_ip 192.168.1.0/24
        }
        handle @f376fb8a-12fa-4dd2-a249-7b9b93e20e38 {
            abort
        }

        reverse_proxy https://10.0.0.1:8443 {
            transport http {
                tls_insecure_skip_verify
            }
        }
    }
}

import /usr/local/etc/caddy/caddy.d/*.conf

Тут есть несколько моментов в конфиге Caddy. Первый 10.0.0.199 это адрес, который был выдан для xray сервиса на DHCP сервере OPNSense, для внутренних сервисов я не стал отключать DHCP, но зафиксировал lease для данного xray сервера как статический. 10.0.0.199:8443 на этом порту слушает VLESS+Reality сервер, для соединения клиентов, когда я создавал Inbound в 3x ui xray, я задал этот порт. Обратите внимание, что этот порт разрешен в firewall автоматическими правилами, так как админка на него переключена, если порт будет другой, нужно будет специально разрешить его на LAN интерфейсе. Сама же админка доступна на xray сервере в LXC контейнере на 10.0.0.199:2053. Все эти настройки делаются из OPNSense WebUI после установки плагина, конфиг руками писать не нужно. Да, не забудьте не только включить Cadyy плагин в OPNSense, но и разрешить L4 Proxy в нем. При этом обратите внимание на access `not client_ip 192.168.1.0/24`, это запретит доступ к данным локальным доменам из интернета, я не стал его открывать. Иначе знатоки подменят параметры запроса и получат возможность ковырять админку, но нужно домен угадать будет.

Суть проксирования в том, что Caddy опознает на L4 Proxy SNI google.com и тогда передаст сырой поток данных на xray сервер без всякого reverse proxy. После этого если xray сервер опознает VLESS коннект, то он будет работать с ним, если нет, то он прикинется google.com причем со всеми сертификатами и прочим, неотличимо. Если же Caddy не опознает SNI, то начнет работать reverse proxy и если домен будет опознан как xray.home.arpa, то xray сервер админка будет показана, а для домена opensense.home.arpa будет показана админка OPNSense. Caddy тут хороша тем, что очень просто настраивается.

Теперь Caddy работает на 443 и 80 портах на всех интерфейсах, а админку OPNSense мы перенесли на 8443 порт, так что заходить в нее можно пока на любом порту и будет работать.

Далее переходим к настройками VPS у провайдера, это наш внешний сервер, через который мы предоставим к домашним сервисам доступ из интернета. Тут все довольно просто, ставим на него ubuntu 25.04, делаем стандартные настройки безопасности вроде доступа к ssh по ключам и создания пользователя что бы не под root работать и ставим сеть.

Настройки сети такие. Первое нам нужно установить wireguard на VPS. Он нам нужен что бы обеспечить связь с домашним сервером где OPNSense. Конфиг wireguard такой:

Скрытый текст

i3draven@gateway:~$ sudo cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.100.0.1/30
PrivateKey = это приватный ключ на VPS сервере сделанный
ListenPort = 51820

[Peer]
PublicKey = это публичный ключ, сделанный на OPNSense
AllowedIPs = 10.100.0.2/32, 10.0.0.0/24 

В конфиге Wireguard разрешен OPNSense, он клиент для VPS с адресом внутри тоннеля wg0 10.100.0.2/32, а так же для прохождения по тоннелю разрешены пакеты от сети 10.0.0.0/24 это пакеты от сервисов внутри моста service, который изолирует их в нашей внутренней сети. То есть наш xray сервер в итоге должен иметь возможность напрямую обратиться к VPS через этот тоннель как шлюзу 10.100.0.1.

Когда Wireguard на VPS настроен, нужно настроить nftables нам нужно делать NAT для пакетов, которые пришли от внутренних сервисов, например xray и делать NAT для пакетов, которые пришли в VPS и ушли через wg0 внутренним сервисам. То есть VPS будет маскировать как пакеты снаружи внутрь, так и пакеты изнутри наружу. Это, на мой взгляд самая простая конструкция из возможных. Вот настройки nftables:

Скрытый текст

i3draven@gateway:~$ cat /etc/nftables.conf 
#!/usr/sbin/nft -f

flush ruleset

define WAN_IF = "eth0"
define WG_IF = "wg0"
define WEB_SERVER_IP = 10.100.0.2

table ip filter {
    chain LOG_AND_DROP {
        # Можно посмотреть sudo dmesg что блокировалось
        log prefix "[NFTABLES DROP] " level info counter
        drop
    }

    chain INPUT {
        type filter hook input priority filter; policy drop;
        ct state established,related accept

        # Явно разрешаем весь входящий трафик из туннеля от OPNsense
        # Это для того что бы ответные ACK пакеты просто принимались
        iifname $WG_IF accept

        iifname "lo" accept
        ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable } accept
        # Это SSH на порту таком
        tcp dport 8113 ct state new limit rate 5/minute accept
        # Это wireguard
        udp dport 51820 accept
        jump LOG_AND_DROP
    }

    chain FORWARD {
        type filter hook forward priority filter; policy drop;
        ct state established,related accept
        # Прокидываем трафик на Caddy
        iifname $WAN_IF ip daddr $WEB_SERVER_IP tcp dport { 80, 443 } accept        
        iifname $WAN_IF ip daddr $WEB_SERVER_IP udp dport { 80, 443 } accept # Добавим UDP для Xray
        # Разрешить трафику из VPN-сети выходить в интернет
        iifname $WG_IF oifname $WAN_IF accept
        
        jump LOG_AND_DROP
    }

    chain OUTPUT {
        type filter hook output priority filter; policy accept;
    }
}

table ip nat {
    chain PREROUTING {
        type nat hook prerouting priority dstnat; policy accept;
        # DNAT трафика из интернета на OPNsense
        iifname $WAN_IF tcp dport { 80, 443 } dnat to $WEB_SERVER_IP
        iifname $WAN_IF udp dport { 80, 443 } dnat to $WEB_SERVER_IP # И для UDP
    }

    chain POSTROUTING {
        type nat hook postrouting priority srcnat; policy accept;
        oifname $WAN_IF masquerade
        oifname $WG_IF masquerade
    }
}

Вот это правило `iifname “eth0” tcp dport { 80, 443 } dnat to 10.100.0.2` пробрасывает все, что пришло из интернета на OPNSense, где слушает Caddy что бы определить какой из внутренних сервисов будет отвечать на запрос. Тем самым во внутренней сети мы можем по доменам иметь сколько угодно чего угодно. Вот эти два правила `oifname “eth0” masquerade`, `oifname “wg0” masquerade` как раз и занимаются маскировкой трафика.

Думаю это достаточно безопасная настройка nftables, если имеете советы по улучшению, было бы отлично. Но что бы не смотреть на постоянные сканирования портов я на firewall провайдера запретил все порты, кроме тех, что нужны, то есть ssh, wireguard, http, https. В противном случае ядро вашей VPS постоянно будет ловить пакеты от сканеров.

Настройка Wireguard невозможна с одной стороны, нужен как минимум публичный ключ от OPNSense, так что параллельно нужно настроить в OPNSense Wireguard. Я покажу часть конфигурации OPNSense с итогами, но настраивается все как и раньше в WebUI:

Скрытый текст

<wireguard>
      <client version="1.0.0" persisted_at="1762127854.97">
        <clients>
          <client uuid="b0b854fc-86fc-4210-b11c-d9c0e419cb43">
            <enabled>1</enabled>
            <name>frontend_peer</name>
            <pubkey>key</pubkey>
            <psk/>
            <tunneladdress>0.0.0.0/0</tunneladdress>
            <serveraddress>addr VPS server</serveraddress>
            <serverport>51820</serverport>
            <keepalive>25</keepalive>
          </client>
        </clients>
      </client>
      <general version="0.0.1" persisted_at="1762133000.75">
        <enabled>1</enabled>
      </general>
<server version="1.0.1" persisted_at="1762127854.97">
        <servers>
          <server uuid="99ddd6b8-baea-4856-abe3-ce3e65a3e235">
            <enabled>1</enabled>
            <name>frontend</name>
            <instance>0</instance>
            <pubkey>key</pubkey>
            <privkey>key</privkey>
            <port>51820</port>
            <mtu/>
            <dns/>
            <tunneladdress>10.100.0.2/32</tunneladdress>
            <disableroutes>1</disableroutes>
            <gateway/>
            <carp_depend_on/>
            <peers>b0b854fc-86fc-4210-b11c-d9c0e419cb43</peers>
            <debug>1</debug>
            <endpoint/>
            <peer_dns/>
          </server>
        </servers>
      </server>
    </wireguard>

Тут нужно распутаться с тем куда какие ключи поставить, но думаю разберетесь, публичный ключ OPNSense в итоге попадет в конфиг wg0.conf на VPS. Но самое главное тут в том, что при создании Wireguard Instance в OPNSense нужно обязательно указать опцию `Disable routes` это очень важно потому, что при дальнейших настройках связь с OPNSense без нее пропадет. И лишь после запрета создания routes можно сделать peer в котором в качестве allowed ips указать 0.0.0.0/0. Если маршруты создавать не запретить, то будет создан маршрут, который завернет весь трафик в Wireguard.

На вский случай, в Proxmox можно открыть консоль VM или контейнера и там все вернуть. Для OPNSense есть в консоли пункт 13 в меню, который позволяет вернуть бэкап настроек, каждый раз когда вы меняете настройки текущее состояние бэкапиться. Но я рекомендую просто делать snapshot в Proxmox и все, потом легко вернуть снимок виртуалки в состояние до опасных изменений.

Итак, в этот момент у нас есть настроенный тоннель от OPNSense до VPS, но нет маршрутов, так что он пока не работает. Нам нужно сделать еще несколько вещей. Первая это зайти в OPNSense->Interfaces->Assignments и добавить новый Wireguard VPN интерфейс в OPNSense с любым подходящим именем, я назвал WGVPS.

Так же нужно зайти в свойста OPNSense->Interfaces->{LAN, WAN, WGVPS} и снять галочку ` Block private networks` у всех этих интерфейсов. Это уберет автоматически создаваемые правила firewall, которые заблокируют нам трафик через Wireguard тоннель. Это важный момент.

Потом нужно зайти в настройки WGVPS и поставить галочку `Dynamic gateway policy` это приведет к тому, что для динамического интерфейса WGVPS OPNSense создаст шлюз в OPNSense->System->Gateways->Configuration. Это важный момент, шлюз надо создать именно таким способом, не руками, так как VPN динамический интерфейс.

Когда шлюз создан мы можем перейти к настройкам firewall, вот конфиг:

Скрытый текст

<filter>
<rule uuid="631de44f-3131-4677-bc6e-7a0a0e72828f">
      <type>reject</type>
      <interface>wan</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Block LAN to OpenWRT internet</descr>
      <direction>in</direction>
      <quick>1</quick>
      <source>
        <network>lan</network>
      </source>
      <destination>
        <any>1</any>
      </destination>
      <updated>
        <username>root@10.0.0.1</username>
        <time>1762217647.61</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@10.0.0.1</username>
        <time>1762217620.69</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>

    <rule uuid="f6cf4478-9e1d-415e-b54f-6d42d0c0b264">
      <type>pass</type>
      <interface>wan</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Acces from LAN to Firewall UI</descr>
      <direction>in</direction>
      <quick>1</quick>
      <protocol>tcp</protocol>
      <source>
        <address>192.168.1.0/24</address>
      </source>
      <destination>
        <address>(self),wanip</address>
        <port>443</port>
      </destination>
      <updated>
        <username>root@10.0.0.1</username>
        <time>1762086725.77</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@192.168.1.132</username>
        <time>1761839287.60</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>
   <rule uuid="772ecf5a-9d0e-48e2-a8c5-7dcf448cf530">
      <type>pass</type>
      <interface>wan</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Acces from LAN to Firewall UI</descr>
      <direction>in</direction>
      <quick>1</quick>
      <protocol>tcp</protocol>
      <source>
        <address>192.168.1.0/24</address>
      </source>
      <destination>
        <address>(self),wanip</address>
        <port>8443</port>
      </destination>
      <updated>
        <username>root@192.168.1.132</username>
        <time>1761927485.66</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@192.168.1.132</username>
        <time>1761927485.66</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>
  <rule uuid="70b3f1f0-8563-4ebe-b74f-d7f806abaa40">
      <type>pass</type>
      <interface>wan</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Acces from LAN to Firewall UI</descr>
      <direction>in</direction>
      <quick>1</quick>
      <protocol>tcp</protocol>
      <source>
        <address>192.168.1.0/24</address>
      </source>
      <destination>
        <address>(self),wanip</address>
        <port>22</port>
      </destination>
      <updated>
        <username>root@192.168.1.132</username>
        <time>1761848634.17</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@192.168.1.132</username>
        <time>1761846900.64</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>
    <rule uuid="dc0e35d2-53bb-4987-9dfa-60455761f285">
      <type>pass</type>
      <interface>wan</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Access from LAN to DNS</descr>
      <direction>out</direction>
      <quick>1</quick>
      <protocol>udp</protocol>
      <source>
        <any>1</any>
      </source>
      <destination>
        <any>1</any>
        <port>53</port>
      </destination>
      <updated>
        <username>root@192.168.1.132</username>
        <time>1761850932.61</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@192.168.1.132</username>
        <time>1761850932.61</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>

<rule uuid="e1bf2add-31eb-4b58-b824-35fbc9c0401d">
      <type>pass</type>
      <interface>lan</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Allow services to reply to proxy and use DNS</descr>
      <direction>in</direction>
      <quick>1</quick>
      <source>
        <network>lan</network>
      </source>
      <destination>
        <network>(self)</network>
      </destination>
      <updated>
        <username>root@10.0.0.1</username>
        <time>1762560063.06</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@10.0.0.1</username>
        <time>1762560063.06</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>

 <rule uuid="9c026114-0bcb-4419-8cbf-64f256f33bfc">
      <type>pass</type>
      <interface>lan</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>All LAN traffic to VPS</descr>
      <gateway>WGVPS_GW</gateway>
      <direction>in</direction>
      <quick>1</quick>
      <source>
        <network>lan</network>
      </source>
      <destination>
        <address>Local_networks</address>
        <not>1</not>
      </destination>
      <updated>
        <username>root@10.0.0.1</username>
        <time>1762198751.01</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@10.0.0.1</username>
        <time>1762198685.98</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>
<rule uuid="75537f75-d7c0-4757-99fc-df2056ef06c1">
      <type>block</type>
      <interface>lan</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Block access from Services to all other local networks</descr>
      <direction>in</direction>
      <quick>1</quick>
      <source>
        <network>lan</network>
      </source>
      <destination>
        <address>Local_networks</address>
      </destination>
      <updated>
        <username>root@10.0.0.1</username>
        <time>1762560079.99</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
    </rule>



<rule uuid="c404dacf-7834-4c79-b186-c20654166929">
      <type>block</type>
      <interface>opt1</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Block VPS internet to WAN</descr>
      <direction>in</direction>
      <quick>1</quick>
      <source>
        <any>1</any>
      </source>
      <destination>
        <network>wan</network>
      </destination>
      <updated>
        <username>root@10.0.0.1</username>
        <time>1762218108.82</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@10.0.0.1</username>
        <time>1762217998.73</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>

   <rule uuid="34289115-42de-41e4-afb9-db2835ebed67">
      <type>pass</type>
      <interface>opt1</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Allow WG to Caddy HTTPS</descr>
      <direction>in</direction>
      <quick>1</quick>
      <protocol>tcp</protocol>
      <source>
        <any>1</any>
      </source>
      <destination>
        <network>(self)</network>
        <port>443</port>
      </destination>
      <updated>
        <username>root@10.0.0.1</username>
        <time>1761938713.37</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@10.0.0.1</username>
        <time>1761937442.75</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>
  <rule uuid="5d4cb405-c3d4-491b-a185-6cd5121ece4b">
      <type>pass</type>
      <interface>opt1</interface>
      <ipprotocol>inet</ipprotocol>
      <statetype>keep state</statetype>
      <descr>Allow WG to Caddy HTTP</descr>
      <direction>in</direction>
      <quick>1</quick>
      <protocol>tcp</protocol>
      <source>
        <any>1</any>
      </source>
      <destination>
        <network>(self)</network>
        <port>80</port>
      </destination>
      <updated>
        <username>root@10.0.0.1</username>
        <time>1761938704.08</time>
        <description>/firewall_rules_edit.php made changes</description>
      </updated>
      <created>
        <username>root@10.0.0.1</username>
        <time>1761938704.08</time>
        <description>/firewall_rules_edit.php made changes</description>
      </created>
    </rule>
  </filter>

Приводить правила из самого pf с консоли я не стал потому, что они там не будут иметь названий и их намного больше, там много автоматических. Это те, что я настраивал из OPNsense Web UI, цитата из его конфига. Правила разрешают доступ по HTTP HTTPS к Caddy, который слушает на этих портах что бы было доступ к админке OPNSense и прочему. Возможно часть правил нужно создать в самом начале что бы доступ открыть, разберетесь.

Самое важное правило `All LAN traffic to VPS` именно оно заставляет все LAN сервисы ходить в интернет через VPS. Без него клиенты, подключенные к xray будут видеть ваш домашний IP так как сервисы будут ходить в интернет через домашний роутер! Там список Local networks это просто OPNSense->Firewall->Aliases и там я сделал имя для `192.168.1.0/24`,`192.168.2.0/24`,`10.0.0.0/24` сетей.

Наконец, последний этап, мы отказались от создания маршрутов для Wireguard через опцию `Disable routes`, так что нужно добавить маршрут в сеть за wg0 руками. Это делается в OPNSense->System->Routes->Configuration. Создаем маршрут для сети 10.100.0.0/24 (это сеть для Wireguard) и в качестве шлюза выбираем автоматически созданный для Wireguard шлюз, у меня он называется WGVPS_GW. Если бы мы шлюз руками сделали, это не сработало бы, нужен именно динамически создаваемый шлюз. Иначе маршрут сделать можно, но он только в интерфейсе будет показан, но не применится. В итоге пакеты, которые летят от xray в wg0 будут знать куда лететь.

При этом если бы мы не сделали `Disable routes` и 0.0.0.0/0 как разрешенные адреса для Wireguard, то у меня никаким способом не получилось завернуть трафик так что бы все внутренние сервисы из LAN ходили в интернет через VPS, а не через домашний роутер. Оставлять им выход через домашний роутер я посчитал небезопасным. Может быть кто-то в комментариях предложит лучший способ. Не безопасно это потому, в том числе, что любой клиент видит ваш домашний IP.

Что мы имеем в итоге:

1. Доступ ко всем админкам, Proxmox, OPNSense, 3x UI xray, есть через связку OPNSense+Caddy. Доступ только из локальной сети.

2. Есть тоннель между OPNSense и VPS за счет которого все внутренние сервисы могут ходить в интернет и быть видны в интернете за счет NAT на VPS.

3. Локальные сервисы тем не менее могут ходить на разрешенные порты в локальной сети, например 53 порт для DNS. В целом, настройки DNS DHCP я опустил, они не обязательны, но конечно к VPS можно прикрепить доменное имя. Так же обратите внимание, что xray генерирует ссылку подключения с неверным доменом, он берет его из браузера судя по всему, а нужно будет там поставить домен VPS и порт 443, который является фронтом для наших домашних сервисов.

4. Коннект к VPS выглядит так будто на нем стоит xray, но на деле он на домашнем сервере, с бесплатными бэкапами, относительно провайдерского безграничным диском и так далее. То есть в данную конструкцию легко добавить и другие сервисы, просто добавляя домены в Caddy и при этом сохранив xray как скрытый сервис.

Задачи со звездочкой:

1. Настроить на OpenWrt QoS что бы регулировать ширину канала для дома и сервисов.

2. Применить Lynis или аналоги для сканирования безопасности.

3. Поставить среди сервисов автоматический сканер безопасности, который будет предупреждать если вы случайно накосячите.

4. Подумать как сделать эту конструкцию с помощью snat (output nat) на OPNSense. Может будет удобнее.

5. Специально для снижения пинга в играх может конкретно xray перенести на саму vps, изучить возможности реверс прокси у xray.

6. Добавить на VPS второй внешний IP адрес чтобы на него перенести ssh и wireguard для большей маскировки. Тогда на адресе с xray останется только “сайт” под который вы замаскировались.

7. Для экономных, если смириться с тем, что будет терминация https трафика и обойтись без xray vless+reality, то собственную VPS можно заменить на бесплатный Cloudflare tunnel или аналог.

8. Для нервных: можно на уровне proxmox моста services порезать мост на VLAN-ы и сделать opnsense для них шлюзом, для полной изоляции сервисов на случай взлома.

9. В Unbound DNS в OPNSense для LAN сети где xray включить блоклисты на DNS. Это позволит резать рекламу и шпиенское ПО, ладно бы мешало, оно сильно садит батарею телефона, очень вероятно он будет работать раза в два дольше от этого, если вы подключитесь к личному xray и правильно настроите NAT что бы все запросы от клиентов на 53 порт DNS шли через ваш Unbound DNS.

P.S. Если будут рекомендации по улучшению, буду признателен, между подобными заходами покрутить что-то у меня бывает годы проходят и я успеваю забыть детали. При этом OPNSense, xray я и вовсе настраивал впервые. Да, и возможно я найду какие-то проблемы в настройках позже, написал пока не забыл :) В общем советы приветствуются. Так же хочу напомнить о сайтах типа такого, которые при работающем xray позволяют посмотреть утекают ли ваши адреса в сеть при открытии сайтов и например включить DNS в 3x-ui, а так же предпринять другие меры безопасности.

UPD1: Задача 4 и 9 сделаны. После 4 впн стал быстрее намного работать. Для 9 я так же добавил NAT rdr правило что бы все, что даже напрямую лезет куда угодно на 53 порт, попадало в мой Unbound DNS, а то есть гора скрытых хитрецов.

UPD2: Подумалось, что стоило упомянуть. Так как в статье предполагается, что внутренние сервисы находятся в одной изолированной сети services, трафик от caddy до сервисов должен быть https , что бы взлом одного из ваших сервисов не привел к перехвату данных соседних совсем уж просто. Ну, либо п.8 из задач со звездочкой становится обязатнльным. В следующей статье поговорим о безопасности побольше.

UPD3: Нужно отметить, что в современных условиях wireguard как средство связи между домашним сервером и VPS может быть не надежным. Но суть конструкции в том, что мы организуем связь домашнего сервера OPNSense как клиента к внешнему серверу VPS. Само же средство связи может быть любым. Например можно в сети services сделать VM/LXC в котором будет xray vless+reality клиент к серверу xray, установленному на VPS. Это усложнит конструкцию, но не поменяет ее суть. Просто маршрутизация внутри домашнего сервера будет не “внутренний сервис в сети services”->OPNSense->Wireguard->VPS->Internet, а “внутренний сервис в сети services”->OPNSense->VM/LXC xray клиент->OPNSense->домашний роутер->VPS->Internet, где xray клиент->сервер вместо wireguard->VPS. При этом xray в статье выбран только потому, что он позволяет продемонстрировать что такое L4 Proxy. Все остальное дело изобретательности читателя.

UPD4: Для тех кому l4 proxy не нужен, можно взглянуть на проект https://github.com/fosrl/pangolin

UPD5: Для ограничения доступа к админским ресурсам через caddy обратите внимание на аутентификацию через клиентский сертификат. Его можно сгенерировать прямо в OPNSense и после этого использовать в клиентском браузере и caddy. Очень удобно так как браузер о сертификате спросит только один раз и при этом у вас есть защищенная админка очередного дырявого без такой защиты, написанного черти кем и как сервиса, который тем не менее вам нужен :)

Прошло много лет с тех пор как этот проект был мной сделан, так что я решил опубликовать материалы с ним связанные может кому пригодятся. Тут находятся материалы, которые были использованы для конструирования установки горизонтально-направленного бурения (ГНБ или HDD) на основе проколов грунта. Там же учебники, модели и прочие материалы, которые так или иначе мне пригодились при этом. Мой старый друг говорил, что надо все это запатентовать, но не думаю, что это того стоит. Когда-то давно я спроектировал и собрал на заводе, и в гараже, эту установку. На данный момент это для меня давно пройденный этап, но было любопытно. В то время аналоги, которые были по всем параметрам хуже, стоили больше миллиона рублей. Так выглядело железо с проекта в работе :)

ГНБ установка

Часть чертежей и моделей в самом начале я делал в Компас 3D, но оказалось удобнее делать все в Solid Works, он умел делать прочностные расчеты. Помимо всех чертежей первой версии установки тут есть еще и модель-заготовка второй версии все сделано в Solid Works, вторая версия учитывала накопленный опыт и была на мой взгляд перспективной.

Вторая была легче и более гибко настраивалась, но до испытаний так и не дошло я передумал продолжать развивать этот проект так как в России строительство это опасное занятие по многим причинам в том числе потому, что нет планов коммуникаций и всегда есть риск повредить что-то, что просто никому не известно под землей. В целом проект был просто передышкой и личным экспериментом, который затянулся на два года и был успешен. Первая версия до сих пор наверное где-то работает, мы ее продали и я потом год просто жил у моря, осваивал получше программирование под Android :) Работал с ней я конечно не один. Кстати, в планах была и третья версия. Дело в том, что производить железо в РФ совершенно не выгодно по многим причинам. Первая была просто мощнее и надежнее чем у всех, что давало нам большое преимущество, но третья должна была просто быть вне конкуренции, да, мечты, мечты :)

Самой установки мало и была некоторая оснастка, которая была сделана помимо этого. В частности нужна гидравлическая маслостанция. В итоге было придумано использовать двигатели от обычных “Москвичей” и подобных машин со свалки, включая коробку передач. Это позволило сделать маслостанцию с контролем нагрузки буквально за 15тыс рублей. Когда двигатель выходил из строя, такое было пару раз, мы просто увозили его обратно на свалку и сдавали на металл, покупая там же очередной старый с разбора, вообще не ремонтируя их.

Может кому пригодится метод, так как это мало того, что экономит несколько сотен тысяч рублей от покупки дизельной маслостанции, так еще и экономит массу денег на ремонте. В разделе с чертежами можно найти чертеж проставки для маслостанции это просто адаптер, позволяющий подключить гидронасос к коробке передач “Москвича”. Сборку маслостанции мне помог осуществить один очень хороший и умный механик.

Смешно было когда я посчитал необходимый крутящий момент и вроде бы двигатель подходил, но не подумал, что это крутящий момент не на старте его работы, так что пришлось вернуть в конструкцию коробку передач, что потом оказалось очень верным решением по многим причинам. Денег на изменения конструкции уже не было :)

Для маслостанции я сначала собрал “круизконтроль” на ардуино, что бы при повышении нагрузки он автоматически давил на газ, но оказалось, что удобнее просто переключать скорости на каробке передач когда надо и крузиконтроль был отключен. Но было любопытно собрать плату, написать к ней софт и прочее. Я чуть было не начал изобретать и локатор к этому всему, это спец-штука для определения положения буровой головы под землей, но одумался так как это долго, хоть я и придумал кажется решение лучше современных аналогов. Правда это без реализации мои фантазии конечно.

Помимо этого в папке PаthControl можно найти исходники приложения для телефона, если я то скопировал, давно было. Это приложение позволяет просчитывать траекторию прокола так что бы оборудование не сломать. Приложение простое, поначалу я сконструировал свой сплайн в Wolfram с особыми свойствами, но потом оказалось, что для практики достаточно обычных кривых Безье и соблюдения условий на кривизну траектории прокола в ключевых точках, собственно в приложении так и сделано.

Некоторое время приложение было опубликовано в Google Play но со временем устарело и было снято с публикации, так что кому интересно сами соберете, оно наколеночное и писалось мной очень и очень давно, уже десять лет тому назад наверное. Суть приложения в том что бы задать таблицу из точек в метрах (если я верно помню) где прокол должен изгибаться и после этого посмотреть параметры получившейся кривой, не выходят ли они за допустимые для штанг нормы. Нормы брались из спецификаций штанг, которые продавались в то время. Но штанги из приведенных в архиве чертежей выдерживают в несколько раз большие нагрузки, так что никогда не ломались.

P.S. Все материалы за моим авторством я опубликовал без каких бы то ни было гарантий и ответственности, как есть, вы можете делать с ними что угодно :)

P.P.S. В России не живу уже довольно много лет и этот проект просто повод для баек сегодня, вспоминаю с теплотой.

Итак, на чем я решил строить инфраструктуру домашнего облака:

1. Intel NUC. Это спека по которой выпускают компактные компьютеры. Купил Asus Mini PC.

2. Док станция для двух 2.5-3.5 HDD, которая умеет работать со скоростью 10Gbps по USB 3.2

3. Два HDD 3.5 на 8Тб. Что мелочиться.

4. С Orange PI 5b снаял два SDD на 2Тб

5. Докупил еще один NVME SDD на 2Тб что бы внутрь NUC-a воткнуть.

6. Бесперебойник для этой всей красоты.

Выглядит все это вот так:

Идея такова:

1. Поставить на NUC Proxmox 8, в нем сделать набор виртуалок и на них построить все свои сервисы.

2. Приобрести за 4$ в месяц минимальный внешний сервер в облаке что бы через него выставить наружу свои сервисы.

Сетевая инфраструктура будет такова:

1. Внешний сервер будет pfSense c Wireguard VPN. Я вообще имею статью (Как продлить время автономной работы телефона (VPN+DNS)) о том как используя Ansible playbook сделать себе VPN, но это мне нужно было что бы Ansible и IPTables освоить ну и с сетями получше разобраться. Для реального же использования рекомендую pfSense. Он может все на свете, что можно придумать в области VPN, фаерволов и прочего. Плюс удобен и отлично документирован. Не говоря уже о высочайшем качестве.

2. Внутри Proxmox из виртуалок будет сделано две изолированных локальных сети. Изолированных от всего на свете. Одна под личные, вторая под публичные сервисы. Это будут просто два сетевых моста, которые ни к чему не привязаны.

3. Так же внутри будет виртуалка с pfSense, который будет видеть две эти локалки и WAN интерфейс (выход в интернет). Решено пока не морочить голову с VLAN так как сеть простая. Он будет гейтом и будет по VPN соединен с внешним pfSense для публикации сервисов.

4. На внутреннем pfSense будет поднят HAProxy что бы публиковать сервисы из виртуалок на порту. На поддоменах.

5. На внешнем pfSense будет проброшен порт HAProxy внутреннего (он виден в VPN) в интернет. Это позволит на внешнем сервере иметь только VPN и более ничего, а значит он будет копеечный.

6. На начальном этапе на самом деле все pfSense будут подняты прямо в Proxmox, так как VPN pfSense иметь в облаке или нет, не важно пока нет внешних коннектов. Это позволит в безопасной обстановке все протестить.

Такое решение с одной стороны не требует дорогого внешнего сервера. Тут нужно отметить, что трафик тарифицируется с определенного объема и надо это учитывать. С другой позволяет легко сносить поломанные в процессе экспериментов виртуалки, делать шаблоны и снапшеты с бэкапами, виртуалок я уже поломал с десяток и обычно вместо починки просто откатываю, что время экономит. Proxmox великолепен когда работает! При этом изоляция локалок, изоляция обоих pfSense внутри VPN и хост системы позволяет не особо беспокоится над тем, что внешние сервисы будут представлять опасность для моих домашних железок.

Итак, начнем. Первое это установка Proxmox VE. Тут сразу есть грабля. Их iso дистр самодельный на мой взгляд шлак (мое IMHO после огребания проблем, в коментах сказали, что проблем не имеют). Там LVM не работает и при этом debian перелопачен так, что лучше не видеть. Так что попробовав его я поставил Debian Bookworm и уже в него накатил Proxmox. Процесс установки такой же как в моей прошлой статье (OrangePi 5 с Proxmox 8) Оф. дока тут (https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_12_Bookworm) и в ней рекомендуют ставить первым ядро. Мне в коментах подсказали. Я ставил его потом и проблем кажется нет, только KSM никак не проверю работает ли. За исключением того, что не надо прошивки ставить для ARM-а все на прошлую статью похоже:

Редактируем как там описано /etc/hosts

127.0.0.1       localhost
192.168.1.230   pve-main.proxmox.com pve-main

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Добавляем репозитории Proxmox в /etc/apt/source.lists

deb http://ftp.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://ftp.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware


# Proxmox Backup Server pbs-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription
deb http://download.proxmox.com/debian/pbs-client bookworm main
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Устанавливаем aptitude, что бы если будут проблемы с зависимостями она их нашла и решила. В репах Proxmox они бывают, так что рекомендую.

apt-get install aptitude

Отключаем NetworkManager так как PVE рулит сетью с помощью ifupdown2

systemctl stop NetworkManager.service
systemctl disable NetworkManager.service

Отключаем все suspend/hibernate штуки в debian, так как они сервер гасить будут:

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Ставим Proxmox VE (PVE) причем обратите внимание, что ifupdown2 ставится первым. Думаю это может быть важно.

aptitude install ifupdown2 proxmox-ve open-iscasi

В итоге Proxmox установится и заработает. Можно зайти в консоль по https://${host-ip}:8006, но это еще не все. Хочется красивых бэкапов, так что ставим еще Proxmox Backup Server (PBS) эта штука умеет их сжимать и дедуплицировать и еще много чего. Очень хорошая. Я поставил его прямо на тот же хост, что и PVE.

aptitude install proxmox-backup-server proxmox-backup-client

Клиент ставится потому, что бэкапить сам Proxmox сервер тоже хочется и он, как ни странно, сам себя прекрасно бэкапит. Теперь PBS доступен по адресу https://${host-ip}:8007, можно зайти в консоль. Бэкап самого сервера пока сделать некуда, собственно и займемся тем что бы было куда, идея такова:

1. Два HDD будут собраны в один LVM Stripe 2 том, то есть их скорость будет складываться практически при записи. Это не надежно, так как если помрет один, то помрет весь раздел, но скорость мне важнее. При этом расчет сделан на то, что либо помрут HDD с бэкапами, либо помрут SDD с данными и виртуалками, не одновременно и в этом дублирование. Я не бизнес и мне бэкапы в состоянии на пять лет назад не нужны. Либо из текущих данных восстановлю бэкапы, либо из бэкапов текущие данные. Эх, давно я не слышал как работают HDD, звук похож на хаптик вибрики современные на телефонах :)

2. Раздел на внутреннем SDD и два внешних SDD будут слиты в один LVM Stripe 3 том для той же цели, скорость работы. Раздел и диски одинакового размера. Это так получилось потому, что два внешних SSD на деле не 2Гб, а маркетингово обрезаны до круглых чисел. Да, тут есть грабля, не во всех USB портах SSD работали стабильно, иногда начинались тормоза и зависания пока не воткнул в те порты, что умеют USB 3.2 gen 2 + Thunderbolt 4.

3. Сделанный при установке PVE LVM том /dev/pve-main-vg/root будет как раз заменен на том из п.2 Так как если просто добавить в него два SSD, то Stripe 3 не будет.

Собственно собираем два HDD в том. Далее примерно по памяти, если что тут смотреть (https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/stripe_create_ex).

pvcreate /dev/sdX /dev/sdX
vgcreate backups /dev/sdX /dev/sdX
lvcreate -i 2 -I 4 -l 100%FREE -n backups_2_stripe backups
mkfs.ext4 /etc/backups/backups_2_stripe

У нас в итоге есть раздел для бэкапов, который пашет с практически их суммарной скоростью. Этим и многим другим LVM прекрасен. Я не стал мудрить с ZFS и Btrfs хоть они и имеют нечто похожее потому, что LVM проще, плюс у Proxmox есть интеграция с ним, хотя и с FS она есть, не пробовал.

Далее наступает момент преобразования /dev/pve-main-vg/root в Stripe 3 том. Это не обязательно, просто хочется. Сначала я сделал загрузочную флешку с Ubuntu 22.04 live и сделал все с нее (для справки отлично описано тут https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/stripe_create_ex):

1. Монтируем /dev/pve-main-vg/root в /mnt/root

2. Монитруем /dev/backups/backups_2_stripe в /mnt/backups

3. Делаем в /mnt/backups папку /mnt/backups/root_copy

4. Копируем весь рут в папку rsync -avh /mnt/root/ /mnt/backups/root_copy/ команда по памяти, гуглите.

5. Отмонтируем все.

6. Сносим /dev/pve-main-vg/root командой lvremove /dev/pve-main-vg/root он спросит в своем ли ты уме, отвечаем, что кажется да.

7. Сносим так же /dev/pve-main-vg/swap_1 это просто подкачка и она потом все равно будет нужна, но для чистоты эксперимента.

8. Добавляем SSD диски в volume group: vgextend pve-main-vg /dev/sdX && vgextend pve-main-vg /dev/sdX

9. Делаем новый striped LVM logical volume: lvcreate -i 3 -I 4 -l 100%FREE -n rootpve-main-vg

10. Создаем FS: mkfs.ext4 /dev/pve-main-vg/root

11. Далее уменьшаем этот root на 1Гб (так мне проще, отлично описано тут https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/modifying-the-size-of-a-logical-volume_configuring-and-managing-logical-volumes) что бы подкачку впихнуть: lvreduce –resizefs -L -1G pve-main-vg/root

12. Создаем подкачку: lvcreate -i 3 -I 4 -l 100%FREE -n swap_1pve-main-vg

13. Делаем раздел для будущей подкачки собственно подкачкой: mkswap /dev/pve-main-vg/swap_1

14. Копируем из /mnt/backups/root_copy в /dev/pve-main-vg/root все обратно тем же rsync, разберетесь как.

Без раздела подкачки не обойтись даже если памяти много. Раздел в скриптах PVE используется, так что сделал. В итоге у нас есть /dev/pve-main-vg/root, который работает со скоростью в гигабайты в секунду не напрягаясь. Диски подготовлены, пора переходить к настройке PVE. Сначала установим PVE ядро, что бы там KMS работал (работает ли он не проверял пока):

aptitude install proxmox-kernel-6.5.13-1-pve-signed 

Обратите внимание, я поставил подписанное ядро так как у меня Secure Boot в UEFI Bios разрешен. Потом я намудрил с MOK и пришлось его подписывать снова как описано тут (https://pve.proxmox.com/wiki/Secure_Boot_Setup). Но думаю вы обойдетесь, на всякий случай ссылку даю. Далее можно настроить фаервол.

Фаервол устроен в PVE интеренсно. Есть настройки датацентра, настройки отдельных нод и настройки отдельных виртуалок. Что бы он заработал его надо на всех уровнях включить. Каждый следующий уровень наследует правила предыдущего. Важно сначала настроить правила, а потом включить фаервол, иначе он все зарежет. Правила на уровне датацентра такие как на картинке:

Тут открыты все порты, что использует для различных нужд PVE и порты по которым доступны разные виды консолей управления. После создания правил надо на всех уровнях разрешить фаервол, покажу уровень датацентра:

Фаервойл настроен и включен, пора настроить PBS, что бы иметь много бэкапов! Для этого заходим в консоль управления PBS: https://${host-ip}:8007 жмем кнопку add datastore и добавляем наш том с двумя HDD: /dev/backups/backups_2_stripe как хранилище там ничего сложного нет, разберетесь. Один момент, добавляется папка на этом томе потому она у меня монтируется при загрузке сервера для чего в /etc/fstab написано:

/dev/mapper/backups-backups_striped_volume /mnt/backups               ext4    errors=remount-ro 0       1

С момента добавления хранилища нужно сходить в PVE и добавить PBS в качестве storage для бэкапов. Немного странная конструкция на мой вкус, но у них так. Да, установка PVE и PBS на один физический сервер не рекомендована, но так как если все это накроется то настроить снова это много текста в статье, но немного команд, а бэкапы останутся, то я не стал усложнять. Собственно добавление PBS в PVE:

Fingerprint для того что бы добавить PBS как хранилище в PVE можно взять в PBS открыв сертификат, откуда и скопипастить, остальное разберетесь:

Теперь мы можем нажать кнопку “бэкапь!”:

Так же мы можем забэкапить сам PVE сервер. На деле от него нам надо только папку /etc и особенно /etc/pve. Но /etc/pve это точка монтирования fuse FS, так что команда на бэкап должна особо сказать, что ее надо тоже забрать так как по умолчанию PBS клиентъ пропускает точки монтирования. Я для теста залил в бэкап вообще весь диск он точки монтирования пропустил кроме той, что я ему указал:

proxmox-backup-client backup root.pxar:/ --repository ${host-ip}:proxmox-backup-server-data --include-dev /etc/pve

proxmox-backup-server-data это так называется HDD LVM том, добавленный в PBS в качестве хранилища. Люблю длинные самодокументирующие названия.

На пока все, эта конструкция позволит создавать виртуалки, бэкапить дедуплицированно-сжатые бэкапы и вообще куролесить. В следующий раз про сеть, если настроение будет.

UPD: Я особо не разбирался, но кажется что бы работал KSM надо установить пакет aptitude install ksmtuned. При этом освобождение памяти начнется при 80% ее использовании. ОЗУ у меня много для моих задач, так что пока не нужно. Оставлю для желающих разобраться https://pve.proxmox.com/wiki/Dynamic_Memory_Management

P.S Для настроек и консультаций, а так же как учебник очень рекомендую использовать ChatGPT. Она отвечает на конкретный вопрос и не надо долго копаться, потом достаточно погуглить ответ что бы проверить, что не врет. Чаще всего не врет :) Реально очень удобно и она всегда вежлива, не приходится продираться через форумных выпендрежников ради простого ответа :)

Предполагается, что из прошлой статьи у вас уже настроен EDK II загрузчик и вы можете свободно загружаться откуда угодно, а значит дело только в том что бы подготовить образ и настроить proxmox. Этим и займемся.

В качестве базового дистрибутива я выбрал Armbian образ с названием /Armbian_23.11.1_Orangepi5_bookworm_legacy_5.10.160.img.xz, тому есть несколько причин.

• Он пользуется репозиториями дебиана, а значит обновляется.

• Линуксовое ядро у них содержит модуль fuse, которого в ядре в составе дистрибутива от авторов OIrange PI5 нет, а он нужен для proxmox, либо я недомудрил с модулями. Без этого модуля proxmox не установится.

• Ядро в данном образе 5.10, для rk3588s еще нет версии ядра 6.1, производитель только делает.

Как ни странно proxmox поставится только при установке armbian на SSD диск. Пробовал на sdcard поставить, что то не пошло, не стал разбираться. Образ нужно подготовить для UEFI загрузки, что бы его EDK II легко увидел. В прошлой статье я писал, что SSD у меня подключен в USB 3 порт на Orange PI5b так что я просто переткнул его в ноутбук. Так как я пользуюсь linux, то просто в nautilus нажал правую кнопку на образе и выбрал “запись образа” после чего указал, что его надо записать на SSD. Есть много способов залить образ на SSD диск. После того как образ записан на SSD нужно смонтировать разделы оттуда

mount /dev/sde1 /mnt/1
mount /dev/sde2 /mnt/2

С первого раздела надо все перенести на второй в папку /boot. Там ядро с вышеописанным модулем fuse и прочие нужные для загрузки файлы в том числе папка dtb в которой лежат файлы с описанием оборудования на вашей версии OrangePI 5(b) обратите внимание, что нужно будет указать в grub.cfg и armbianEnv.txt верный файл.

Далее берем образ где есть UEFI загрузчик, например я взял его с debian-bookworm-live-arm64.hybrid.iso как писал в прошлой статье. Копируем папки /EFI и /boot/grub с этого образа на первый раздел SSD диска, который там после записи туда armbian образа появился. После чего нужно отредактировать /boot/grub/grub.cfg сделав его таким.

search --no-floppy --fs-uuid b5d4f702-2288-4851-be51-175a746d1b05 --set=root --hint hd0,gpt2
devicetree /boot/dtb/rockchip/rk3588s-orangepi-5b.dtb
linux /boot/Image root=UUID=b5d4f702-2288-4851-be51-175a746d1b05 ro rootwait rootfstype=ext4
initrd /boot/initrd.img-5.10.160-legacy-rk35xx
boot

Меню я делать не стал. Обратите внимание, что b5d4f702-2288-4851-be51-175a746d1b05 это UUID root файловой системы с конкретного образа armbian, если у вас другой, то UUID будет другой, узнать его можно с помощью команды blkid или gparted. Так же важно, что бы файл rk3588s-orangepi-5b.dtb был для вашей версии железа, в моем случае это именно 5b.dtb, в папке dtb много вариантов.

Загрузчик готов, можно переходить к подготовке armbian к работе с proxmox. Для этого отредактируем файлы armbianEnv.txt armbian_first_run.txt.template не уверен, что это обязательно, но я сделал. Содержимое файлов такое

armbianEnv.txt Обратите внимание, что UUID и dtb нужны тоже верные.

verbosity=0
bootlogo=false
overlay_prefix=rockchip-rk3588
fdtfile=rockchip/rk3588s-orangepi-5b.dtb
rootdev=UUID=b5d4f702-2288-4851-be51-175a746d1b05
rootfstype=ext4

armbian_first_run.txt.template

FR_general_delete_this_file_after_completion=1
FR_net_ethernet_enabled=1
FR_net_wifi_enabled=1
FR_net_wifi_ssid='имя вашего вайфая'
FR_net_wifi_key='пароль к вашему вайфаю'
FR_net_wifi_countrycode='GB'
FR_net_use_static=1
FR_net_static_ip='192.168.1.130'
FR_net_static_mask='255.255.255.0'
FR_net_static_gateway='192.168.1.1'
FR_net_static_dns='8.8.8.8 8.8.4.4'

Тут важно отметить, что адрес 192.168.1.130 мне выдал мой роутер с DHCP сервером и я на нем закрепил этот адрес сразу за MAC адресом данной Orange PI5b сетевой карты. Для proxmox важно что бы адреса были статические. Но мы в любом случае далее сделам все статическим.

В соответствии с инструкцией в статье (https://github.com/jiangcuo/Proxmox-Port/wiki/Install-Proxmox-VE-on-Debian-bookworm) редактируем файл /etc/hosts

127.0.0.1   localhost
192.168.1.130   orangepi5.proxmox.com orangepi5
::1         localhost orangepi5 ip6-localhost ip6-loopback
fe00::0     ip6-localnet
ff00::0     ip6-mcastprefix
ff02::1     ip6-allnodes
ff02::2     ip6-allrouters

В этом файле тот же адрес 192.168.1.130 имя хоста orangepi5 оно такое по умолчанию в Armbian. При этом обязательно надо удалить запись 127.0.1.1 иначе вероятно у proxmox будут проблемы. В целом редактирование этого файла обязательная процедура, без этого Proxmox не установится скорее всего.

Переходим к файлу /etc/apt/sources.list в него нужно добавить репозиторий

deb [arch=arm64] https://mirrors.apqa.cn/proxmox/debian/pve bookworm port

Собственно там лежит порт Proxmox 8.1.3. Так же нужно добавить в папку /etc/apt/trusted.gpg файл с ключом

sudo curl https://mirrors.apqa.cn/proxmox/debian/pveport.gpg -o /etc/apt/trusted.gpg.d/pveport.gpg 

Переходим к файлу /etc/network/interfaces его содержимое

source /etc/network/interfaces.d/*
auto lo end1
iface lo inet loopback

iface end1 inet6 auto
iface end1 inet static
        address 192.168.1.130
        netmask 255.255.255.0
        gateway 192.168.1.1

Статический адрес все тот же, что мне выдал роутер 192.168.1.130. Все файлы готовы. Далее можно отмонтировать SSD и подключить его к OrangePI 5b. EDK II найдет его сам или можно выбрать в его меню диск и загрузится с него. Начальную настройку Armbian описывать не буду она совсем простая. После того как Armbian загружен нужно сначала отключить NetworkManager с ним у Proxmox проблемы, он сам рулит сетевыми интерфейсами.

sudo systemctl stop NetworkManager.service
sudo systemctl disable NetworkManager.service

После чего я перезагрузился для надежности. В силу вступят настройки сетевого интерфейса из /etc/network/interfaces. Далее обновляем репозитории и устанавливаем собственно proxmox

sudo aptitude update
sudo aptitude install ifupdown2 proxmox-ve open-iscsi

aptitude в процессе разрешит конфликты в зависимостях и предложит удалить пакет vlan, я согласился. После чего Proxmox 8.1.3 был благополучно установлен на OrangePI 5b. Если будут проблемы с установкой, установочные скрипты proxmox не показывают ошибок, их нужно смотреть через sudo journalctl -b. Но это еще не все. Если не откатить пакет с прошивками то виртуалки работать не станут, просто будут грузить CPU на 100% и висеть.

apt download pve-edk2-firmware-aarch64=3.20220526-rockchip
dpkg -i pve-edk2-firmware-aarch64_3.20220526-rockchip_all.deb

После того как это сделано можно перезагрузить девайс и с ноутбука зайти в консоль по адресу https://192.168.1.130:8006 конкретный айпишник у вас будет свой конечно же. Логопас такой же для рута как вы задали при настройке Armbian. На этом настройка еще не завершена.

Нужно создать bridge, а так как теперь proxmox рулит в /etc/network/interfaces настройками сети, а за счет ifupdown2 девайс для смены настроек не надо перегружать, то в консоли надо сначала удалить IP и Gateway у интерфеса end1 (см. Datacenter->orangepi5->System->Network) не применяя настроек, это очень важно, иначе сеть отвалится, кнопку Apply Configuration нажимать нельзя! После чего нужно создать Linux Bridge задав ему тот же адрес что выдал вам роутер 192.168.1.130, гейт 192.168.1.1 (которые вы отняли у end1) и Bridge ports end1. Вот только потом можно нажать Apply Configuration и оба действия будут выполнены вместе на стороне OrangePI 5b. С этого момента у вас в консоли появится два сетевых интерфейса как на картинке.

Далее создадим первую виртуалку, ее тоже надо настроить строго определенным образом (https://github.com/jiangcuo/Proxmox-Arm64/wiki/Qemu-VM). Сначала закачаем iso дистра, который хотим поставить. Разберетесь как в proxmox заливать данные в хранилище. В моем случае это ubuntu-22.04.3-live-server-arm64.iso. Потом создаем виртуальную машину указав, что в CD привод надо этот образ воткнуть. Обратите внимание, что когда грузить его будете надо подождать, он стартует долго. Любопытный факт, виртуалку грузить будет все тот же EDK II. Другие настройки виртуальной машины на картинке

Тут важно отметить, что если вы собираетесь использовать несколько ядер в виртуалке, то нужно указать к каким ядрам rk3588s привязать эту виртуалку как на картинке там видно, что я выбрал 2 ядра и указал, что виртуальные ядра надо привязать к физическим ядрам процессора из диапазона 0-1. Дело в том, что ядра в SoC разного типа, одни мощные, вторые нет и нельзя запустить виртуалку на одном мощном, а втором слабом так что обязательно надо указать affinity. Для одноядерных виртуалок это кажется не нужно. Так же обратите внимание на тип CPU host.

Все, можно запускать виртуалку и ставить ubuntu в ней. Теперь не придется по сто раз переставлять дистр, есть снапшоты и множество прочих удобств для того что бы не мусорить в одном дистре чем попало. Есть даже LXC контейнеры, это не просто докер, а контейнер системы в целом, легковеснее чем виртуалки. При этом все это на OrangePI 5b работающее почти от батареек, на паре таких девайсов на моей полке можно запустить восемь двухядерных VPS прямо дома бесплатно фактически! Оно еще и с пассивным охлаждением греется при нагрузке до 45 градусов всего!

UPD: После установки Ubuntu рекомендую установить в ней Qemu guest agent (https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_qemu_agent) это значительно дополнит статистику о состоянии VM

UPD: Если используете в виртуалке графический рабочий стол так же удобно поставить spice-vdagent, он позволяет с веб консоли копипастить текст и файлы прямо в виртуалку. Описано там же в мануале на proxmox в разделе 10.2.8

UPD: В старом ядре 5.10 нет KSM, так что с нетерпением жду 6.1 или просто с KSM. Вроде бы производитель обещал еще в Q4 2023 выпустить 6.1, но пока не видать.

UPD: Так как все то же самое можно раскатать на RPi 4 то к своему кластеру в proxmox я и ее добавлю, а то валяется давно.

UPD: Обратите внимание, что по умолчанию proxmox firewall не работает и не показывает никаких ошибок (см. journalctl -b). Что бы заработал скорее всего надо включить в веб консоли в его опциях tcp flags filtering. Осторожно, надо сначала правилами разрешить порты, а то он всю внешку отрежет. Но останется проблема с созданием ipset’s. Если они не нужны то вроде как и ладно, если нужны, то надо патчить фаервол или обновлять ядро. Но распишу как все это решать в следующий раз. Может быть.

UPD: Так как ждать выпуска свежего ядра я не хочу, то использовал пока Intel NUC. О чем далее Личное облако на Proxmox

P.S. Фактически это способ дешево получить в свое распоряжение настоящее взрослое облако с ceph, сложными сетями, бэкапами, снапшетами, мониторингом, репликацией и бесконечным полем для экспериментов ;)