[2026-09-29] eagle: personal/projects/personal-os/eagle-dashboard.md personal/tech/docker-mac-disk-issues.md personal/tech/docker-service-administration-skill.md personal/tech/hermes-pairing-multi-profile.md personal/tech/hermes-whale-mattermost-transport.md

This commit is contained in:
Alexey Martemyanov committed 2026-09-29 12:25:49 +06:00
1 parent 1cd3024808
commit c8218ed89c
5 files changed
+285 -5

No files matched your search

+34 -5
View File
@@ -173,12 +173,41 @@ cd <compose-dir> && docker-compose pull && docker-compose up -d
### Осталось (не снесено, осознанно)
`balda-mm:0.1.13`, `0.1.14`, `0.1.15-pr8-5360e90b`, `0.1.15-pr8-5360e90b-runtime210`,
`0.1.15-pr8-0e6d63aa-runtime210`, `balda:mm-classifier` (~560 МБ) — **ветки нового стека**,
который готовится. Снос — по отдельной команде.
~~`balda-mm:0.1.13`, `0.1.14`, `0.1.15-pr8-*`, `balda:mm-classifier` (~560 МБ)~~
✅ **Снесены вторым заходом 2026-09-29.** Alex: «ветки сноси, там щас новый релиз будет,
пересобирать будем всё».
Снесено: `balda-mm:0.1.13`, `0.1.14`, `0.1.15-pr8-5360e90b`,
`0.1.15-pr8-5360e90b-runtime210`, `0.1.15-pr8-0e6d63aa-runtime210`, `balda:mm-classifier`.
**На Mac balda-образов не осталось** — чистое поле под новый релиз.
```bash
# Проверка перед сносом (обязательно): ни один живой контейнер не использует образ
docker ps --format '{{.Names}} {{.Image}}' | grep -i balda # → пусто
```
### Итог чистки 2026-09-29
| Метрика | До | После |
|---|---|---|
| **VM disk `/dev/vdb1`** | **57 ГБ (61%)** | **16 ГБ (17%)** |
| Images | 44 шт / 26.45 ГБ | 19 шт / 15.27 ГБ |
| Containers | 22 | 16 |
| Build Cache | 8.63 ГБ | 1.62 ГБ |
| buildkit volume | 37.71 ГБ | удалён |
**Освобождено суммарно ≈ 41.6 ГБ.**
### Готовность к сборке нового релиза
- ✅ `arm64builder` пересоздастся сам при первой сборке (сейчас `inactive`)
- ✅ Кэш слоёв пуст — сборка пойдёт с нуля (apt/pip/go mod download заново)
- ✅ Старых тегов нет — коллизий имён не будет
- ⚠️ Сборка: `docker-compose build --no-cache` либо `docker buildx build --builder arm64builder --platform linux/arm64 --provenance=false --load`
⚠️ **На Kraken ничего не снесено** — там `balda-executor-mcp` работает,
текущий рабочий образ `balda-mm:0.1.15-pr8-480ec821-runtime210`.
⚠️ Текущий рабочий образ на **Kraken**: `balda-mm:0.1.15-pr8-480ec821-runtime210`
(на Mac его нет).
### Живые контейнеры (16, все рабочие)
@@ -0,0 +1,72 @@
---
title: docker-service-administration (скилл) — что покрывает
created: '2026-09-29'
updated: '2026-09-29'
type: tech
namespace: personal
status: active
tags:
- docker
- skill
- pruning
- disk
related:
- '[[personal/tech/docker-mac-disk-issues.md]]'
- '[[personal/tech/docker_colima_setup.md]]'
---
# `docker-service-administration` (скилл) — карта покрытия
Зеркало скилла `skills/docker-service-administration/SKILL.md`. Нужно, чтобы не перечитывать
весь скилл при вопросе «а это где-то записано?».
## Секции скилла
| Секция | Тема |
|---|---|
| A | Service Containerization — перенос нативных сервисов в Docker, Dockerfile-паттерны |
| B | Compose Recovery — диагностика стека после ребута |
| C | Readiness Audit — что вообще можно контейнеризировать |
| D | Service Upgrade — мажорные апгрейды (Zulip 9→10→11) |
| E | Local Service Dockerization (RU) |
## ✅ Добавлено 2026-09-29 — Disk reclamation
Раздел «Disk reclamation» в Section A (Pitfalls). Ключевое:
### 🔴 Build cache живёт в VOLUME, а не в `builder prune`
```
docker builder prune -f → освобождает только метаданные (1.9 ГБ)
docker rm -f buildx_buildkit_arm64builder0
docker volume rm buildx_buildkit_arm64builder0_state → реальные 37.71 ГБ
```
📌 **Проверено 2026-09-29: освободило 41 ГБ** (VM disk 57 → 16 ГБ, 61% → 17%).
Мерить `colima ssh -- df -h /dev/vdb1`, **не** `docker system df` — тот врёт.
⚠️ Цена: builder уходит в `inactive`, следующая сборка с нуля.
### 🔴 `compose down` НЕ удаляет образ
`docker-compose down` убирает контейнер, образ остаётся. Нужен отдельный `docker rmi`.
В реальном кейсе так остались висеть `balda-executor:0.1.0` (**2.48 ГБ**) и `watchtower`.
### Safe-scope при чистке
| Команда | Вердикт |
|---|---|
| `docker image prune -f` | ✅ только dangling |
| `docker builder prune -f` | ✅ метаданные (+ volume отдельно) |
| `docker container prune -f` | ✅ только остановленные — но **сначала проверить** |
| `docker volume prune` | ❌ **удаляет тома с данными** (БД!) |
| `docker system prune -a` | ❌ сносит все неиспользуемые образы, включая рабочие |
🔴 **Никогда не чистить тома на хосте со stateful-сервисами.** Доказывать, что ничего живого
не задето, диффом списка контейнеров до/после (`comm -23 before after`).
⚠️ **Снос Watchtower = конец автообновлений образов на хосте.** Говорить об этом прямо.
## Связанные заметки
- [[personal/tech/docker-mac-disk-issues.md]] — Colima VM, структура диска, инцидент ENOSPC
- [[personal/tech/docker_colima_setup.md]] — установка Colima
@@ -0,0 +1,136 @@
---
title: Hermes pairing — approve пользователей, multi-profile
created: '2026-09-29'
updated: '2026-09-29'
type: tech
namespace: personal
status: active — процедура проверена 2026-09-29
tags:
- hermes
- pairing
- telegram
- mattermost
- multi-profile
related:
- '[[personal/tech/hermes-whale-mattermost-transport.md]]'
- '[[personal/projects/personal-os/eagle-dashboard.md]]'
---
# Hermes pairing — approve пользователей (multi-profile)
Процедура выдачи доступа новому пользователю к боту Hermes. Проверена 2026-09-29
на инстансе **whale** для telegram и mattermost.
## 🔴 ГЛАВНОЕ: pairing — per-profile, и это легко перепутать
`hermes pairing` работает **внутри того профиля, который задан `HERMES_HOME`**.
На этой машине профилей несколько (минимум **eagle** и **whale**), и у каждого свой
список одобренных пользователей.
```
/Users/admin/.hermes/ ← базовый профиль (Eagle)
/Users/admin/.hermes/hermes-whale/ ← профиль Whale (Кит)
```
🔴 **Перед любым approve — проверить инстанс:**
```bash
echo "HERMES_HOME=$HERMES_HOME"
```
Ожидаемо для Кита: `HERMES_HOME=/Users/admin/.hermes/hermes-whale`.
Alex отдельно предупреждает: **не трогать eagle** (он остановлен, но конфиг живой).
## Команды
```bash
# назначить профиль явно (надёжнее, чем полагаться на окружение)
export HERMES_HOME=/Users/admin/.hermes/hermes-whale
# список: pending + approved
hermes pairing list
# одобрить
hermes pairing approve <platform> <code>
```
Полный путь к бинарю (если `hermes` не в PATH):
```bash
/Users/admin/.hermes/hermes-agent/venv/bin/python -m hermes_cli.main pairing list
```
Подкоманды: `list` · `approve` · `revoke` · `clear-pending`.
## Как выглядит рабочий прогон
```
$ hermes pairing list
Pending Pairing Requests (1):
Platform Code User ID Name Age
-------- ---- ------- ---- ---
telegram fb7ba963 312016878 Alexey 1m ago
No approved users.
$ hermes pairing approve telegram AYJ6JPM9
Approved! User Alexey (312016878) on telegram can now use the bot~
They'll be recognized automatically on their next message.
```
После обоих approve (2026-09-29):
```
Approved Users (2):
Platform User ID Name
---------- ------- ----
telegram 312016878 Alexey
mattermost cbwsorzwoigbtrdnteugnx4aqo admin
```
## 🔴 Питфолл: код в pending ≠ код, который даёт Alex
В обоих прогонах 2026-09-29 **код в `pending` отличался** от того, что прислал Alex:
| Платформа | В pending | Alex прислал | Итог |
|---|---|---|---|
| telegram | `fb7ba963` | `AYJ6JPM9` | ✅ approve прошёл |
| mattermost | `f8c6ca55` | `QHYL8TB9` | ✅ approve прошёл |
Оба раза approve по присланному коду **сработал**, очередь опустела, одобрен ровно
один пользователь на платформу. То есть код из pending — не единственный валидный
(вероятно, привязка идёт по последнему запросу пользователя, а не по показанной строке).
📌 **Практика:** получив код от Alex — выполнять его как есть, не «исправлять» на код
из `pending`. И **всегда сверять `pairing list` после**: должно стать
`Pending: 0` и появиться ожидаемый user id.
## Связка platform ↔ user id (этот сетап)
| Платформа | User ID | Name | Что это |
|---|---|---|---|
| telegram | `312016878` | Alexey | `MY_TELEGRAM_ID` из `~/Documents/documentation/tokens/` |
| mattermost | `cbwsorzwoigbtrdnteugnx4aqo` | admin | аккаунт Alex в MM (`admin@qentra.top`) |
## Что pairing НЕ делает
- **Не поднимает платформу.** Транспорт должен быть подключён отдельно
(env-переменные + блок в `config.yaml`). Для MM — 5 ключей `MATTERMOST_*`,
см. [[personal/tech/hermes-whale-mattermost-transport.md]].
- **Не выдаёт токен бота.** Это разные вещи: токен — доступ бота к платформе,
pairing — доступ человека к боту.
- **Не влияет на другой профиль.** Одобрение в whale не даёт доступа в eagle и наоборот.
## Проверка после approve
```bash
export HERMES_HOME=/Users/admin/.hermes/hermes-whale
hermes pairing list # ожидаем Pending: 0 + нужный user в Approved
```
**Приёмка — сообщение от Alex в UI платформы и ответ бота**, не «pairing list показывает строку».
## Связанные заметки
- [[personal/tech/hermes-whale-mattermost-transport.md]] — транспорт MM + Telegram, env-ключи
- [[personal/projects/personal-os/eagle-dashboard.md]] — управление сервисами Hermes (Eagle/Whale)
@@ -415,7 +415,30 @@ ORDER BY m.date_sent DESC LIMIT 25;"
## Связанные заметки
- [[personal/tech/hermes-pairing-multi-profile.md]] — **как одобрять пользователей (`hermes pairing approve`)**
- [[personal/projects/balda/mattermost-kraken-deploy.md]] — сам сервер MM
- [[personal/tech/kraken-host-resource-limits.md]] — почему не на Kraken
- [[personal/tech/hermes-fork-vs-upstream.md]] — платформы живут в `plugins/platforms/`
- [[personal/tech/hermes-secret-redaction-bypass]] — редактор секретов Hermes
## Что делалось в тот же день рядом (2026-09-29) — чтобы не искать заново
Транспорт MM был **одной из трёх задач той же сессии**. Две другие — в отдельных доках:
| Задача | Док | Итог |
|---|---|---|
| Снос агента **Валера** на Mac | [[personal/projects/balda/balda-valera.md]] | контейнер `balda-agent-valera-1` + образ удалены, **код сохранён** |
| Чистка Docker на Mac | [[personal/tech/docker-mac-disk-issues.md]] | **освобождено 41 ГБ** (57 → 16 ГБ), снесены `balda-executor`, `watchtower`, 16 образов, buildkit-volume 37.71 ГБ |
| Транспорт MM + Telegram + pairing | **этот док** | закрыто |
⚠️ **Пересечение по `balda-executor`.** Он был снесён в рамках чистки Docker (2.48 ГБ образ),
и **это не Валера** — Валера это `balda-agent-valera-1`. Не путать при чтении истории.
## Проверка, что транспорт жив (одна команда)
```bash
grep -E "mattermost connected|platform\(s\)" /Users/admin/.hermes/hermes-whale/logs/gateway.log | tail -3
```
Ожидаемо: `✓ mattermost connected` и `Gateway running with 3 platform(s)` (webhook + mattermost + zulip).
📌 Логи читать **из `hermes-whale/logs/`**, не из `~/.hermes/logs/` (там мёртвый лог Eagle).