auto-sync from MEMORY.md (2026-05-26 18:44)

2026-05-26 18:44:07 +00:00
parent e51c6310f0
commit 35202bc348
7 changed files with 460 additions and 0 deletions
--- a/decisions/2026-05-08-buzharovo-sql-native-backup.md
+++ b/decisions/2026-05-08-buzharovo-sql-native-backup.md
@@ -0,0 +1,75 @@
+---
+date: 2026-05-08
+type: decision
+tags: [decision, buzharovo, 1c, backup, mssql, effector-saver]
+---
+
+# 2026-05-08: Бэкап Бужарово 1С — переход с Effector Saver DT на native MS SQL Backup
+
+## Контекст
+
+Вечером 2026-05-08, после починки rmngr-loop, регулярная задача `Бэкап 1Cv8` в Effector Saver Free 4.8/2 на `server1c.netbird.cloud` (Win 2012 R2, MSSQL 2012 SP4, 1С 8.3.27.1606) **отказывалась завершаться успешно**. Шесть подряд запусков (19:51 → 22:21) падали с одной и той же связкой ошибок:
+
+1. `HRESULT=800401F3` — `V83.ComConnector` не зарегистрирован → Olег зарегистрировал через UI Effector Saver, переключился на 64-bit
+2. `HRESULT=80004005` — "Администратор кластера не аутентифицирован" — у кластера 1С есть проверка авторизации, но **в кластере нет ни одного admin'а**, а добавить нельзя:
+   - В Серверной консоли 1С: `Локальный кластер → Администраторы` показывает количество=0, форма "Новый администратор" заполнена, но при OK **просит логин/пароль и не принимает agent-уровневый admin** (создан Olегом отдельно)
+   - Через COM `V83.COMConnector`: `AuthenticateAgent('admin', '1qaz!QAZ')` проходит, но `RegClusterAdmin` падает "пользователь не выполнил аутентификацию для требуемой операции" (chicken-and-egg: для создания первого cluster admin нужен уже cluster admin)
+   - Через `rac` с `--agent-user`: cluster operations не принимают agent-уровневую аутентификацию (design choice 1С)
+
+3. `Ошибка исключительной блокировки информационной базы` — даже без cluster admin'а Effector Saver продолжает выгрузку, но не может получить эксклюзив, потому что в БД активные сессии. Особенно "вечная" сессия `КулябинПИ sid=4514, начат 12:55:42` — после моего рестарта службы 1С в 19:30 и последующих SQL `KILL` сессий, она **раз за разом возвращается** (вероятно, реально открытый где-то тонкий клиент Павла Ивановича + persistent state в `1CV8Clst.lst`).
+
+## Что пробовали и почему не сработало
+
+| Попытка | Результат |
+|---|---|
+| `regsvr32` x64 `comcntr.dll` | ✅ COM зарегистрирован, переключение Effector Saver на 64-bit убрало `800401F3` |
+| `Restart-Service '1C:Enterprise 8.3 Server Agent'` | ✅ rmngr вылечен, но session 4514 в реестре кластера **persists** между рестартами |
+| `KILL` SQL-сессий через `sa/Qwer1122334400` | ✅ временно (sess=0, locks=0), но 1С rphost восстанавливает соединения за 1-2 мин и сессия 4514 reanimates |
+| `rac cluster admin register` без auth | ❌ "оператор не существует" |
+| `RegClusterAdmin` через COM с `AuthenticateAgent` | ❌ "пользователь не аутентифицирован для требуемой операции" |
+| GUI Серверной консоли 1С — добавить cluster admin | ❌ форма не сохраняет, требует cluster auth (которой нет) |
+
+Тупик: **в кластере БД 1С нет cluster admin'а, и зарегистрировать первого нельзя ни через GUI, ни через rac, ни через COM.** Возможный единственный путь — обнулить `srvinfo\reg_1541\1CV8Clst.lst` целиком (потеря и админов, и регистрации ИБ — нужна перерегистрация ИБ с SQL params; рискованно).
+
+## Решение: native MS SQL Backup
+
+Effector Saver делает **DT-выгрузку через 1С Конфигуратор** (`1cv8.exe DESIGNER /DumpIB`), которая требует эксклюзив на ИБ. Это исторический способ для **файловых** ИБ. Для **клиент-серверных** ИБ на MS SQL правильный путь — **`BACKUP DATABASE` на уровне SQL Server**:
+
+- ✅ **Online backup** — снимает копию во время работы, не требует эксклюзива
+- ✅ Не зависит от 1С-кластера, cluster admin'а, активных сессий
+- ✅ С `WITH COMPRESSION` файл сжимается ~3:1 (3.8 GB → 1.1 GB)
+- ✅ Быстрее — у нас 2 секунды на 3.8 GB БД
+- ✅ Восстанавливается одним запросом `RESTORE DATABASE`
+
+Реализация:
+
+```sql
+BACKUP DATABASE [RitmUl]
+TO DISK = N'C:\backup\RitmUl_<ts>.bak'
+WITH FORMAT, INIT, NAME = N'RitmUl-Full',
+     SKIP, NOREWIND, NOUNLOAD, COMPRESSION, COPY_ONLY,
+     STATS = 5
+```
+
+`COPY_ONLY` — чтобы наш бэкап не ломал log chain если потом настроят differential/log backups.
+
+Запускается через WinRM `python3 + System.Data.SqlClient` с LXC 139 `severny-les` (бот). Storage: `C:\backup\` на server1c (374 GB свободно).
+
+## Артефакт
+
+- **Первый успешный бэкап 2026-05-08:** `C:\backup\RitmUl_2026-05-08_2225.bak` (1105 MB)
+- **Скрипт:** `/root/clawd/scripts/sql_native_backup.py` на LXC 139
+
+## TODO (после возвращения Olега из Египта)
+
+1. **Автоматизировать** — добавить cron на LXC 139 `severny-les`: каждый день в 03:00 МСК запускать `sql_native_backup.py`, ротировать (хранить N дней). Алерт в Telegram-группу при сбое.
+2. **Ротация и трансфер** — настроить копирование `.bak` файлов на внешний носитель (Nextcloud / S3 / Gitea-LFS).
+3. **Тест восстановления** — раз в N дней автоматически развернуть бэкап в тестовую БД и проверить целостность.
+4. **Effector Saver** оставить как есть, не чинить (чинить cluster admin = разбирать `1CV8Clst.lst` бинарник, риск убить ИБ). Можно отключить регулярную задачу `Бэкап 1Cv8` в Effector Saver чтобы не плодились алерты "ошибка".
+5. **TODO документировать** SQL creds в `projects/dttb/credentials.md` (см. блок Бужарово).
+
+## Связанные
+
+- [[projects/buzharovo/server1c]] — обновлён с SQL backup как новый канон
+- [[projects/buzharovo/severny-les-bot]] — бот теперь умеет бэкапить через WinRM+SQL
+- [[decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash]] — про rmngr (отдельная история, починена)
--- a/decisions/2026-05-08-severny-les-bot-buzharovo.md
+++ b/decisions/2026-05-08-severny-les-bot-buzharovo.md
@@ -0,0 +1,77 @@
+---
+date: 2026-05-08
+type: decision
+tags: [decision, buzharovo, bot, openclaw, watchdog, telegram]
+---
+
+# 2026-05-08: Северный лес — отдельный AI-ассистент + watchdog для server1c (Бужарово)
+
+## Контекст
+
+Олег уезжает в отпуск в Египет 2026-05-09 → 2026-05-22. На server1c (Бужарово, VDS 185.13.47.2 / NetBird 100.70.75.103) недавно (2026-05-07) был rmngr-loop, который лечится только `Restart-Service '1C:Enterprise 8.3 Server Agent (x86-64)' -Force` — ребут не помогает (см. [[decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash]]).
+
+Пока Олег в отпуске, нужно:
+1. Чтобы кто-то узнавал когда сервер упал (Telegram-группа руководящего состава Северного леса);
+2. Чтобы можно было дёрнуть восстановительное действие (`/approve restart_1c`) не дожидаясь возвращения Олега из Египта.
+
+Через ~2 недели (после Египта) планируется миграция server1c с VDS на собственный сервер. Бот должен работать **до и после** миграции — поэтому он не на самом server1c, а на dttb-Proxmox через NetBird.
+
+## Развилка: clawdbot vs openclaw vs другой watchdog
+
+Рассматривались три варианта:
+
+| Вариант | Плюсы | Минусы |
+|---|---|---|
+| **clawdbot** (как у [[projects/niikn/clawdbot-niikn|Максимки-Мауля]]) | Проверенный рецепт, проще | Старый стек, не обновляется. exec-approvals самописные. |
+| **openclaw** (свежий стек 137) | Встроенный `exec-approvals.json` whitelist для shell-команд. Plugins, skills, делегирование на Opus 4.7 через Max. Свежий, активная разработка. | Жёсткая schema, есть тонкости (bonjour, IPv6, FakeIP DNS) — но они уже разобраны на 137. |
+| **Голый watchdog без AI** | Минимум зависимостей. | Нет диагностики "почему упало". Невозможно дёрнуть `/restart_1c` через `/approve` — только ручной WinRM. |
+
+**Решение:** **openclaw** — встроенный whitelist для shell-команд (`exec-approvals.json`) — это прямо то что нужно для `/approve` flow. Плюс Опус 4.7 через Max.
+
+## Архитектура
+
+**Изоляция от Максимки (LXC 137):** не подвешиваем как доп.канал на 137 — если openclaw на 137 упадёт (а это бывает: bonjour, FakeIP, Kiro 402), упадут и алерты Бужарово. Для критичной мониторинг-задачи нужен **отдельный** инстанс.
+
+**Хост:** новый LXC 139 на dttb (10.0.0.240, NetBird 100.70.212.78, Ubuntu 24.04, 2c/4GB/10GB).
+
+**Два слоя независимых:**
+1. **buzharovo-watchdog** — bash + curl→TG bot API напрямую, systemd timer 60s. **Не зависит от openclaw.** Если AI-часть упала, алерт всё равно дойдёт.
+2. **openclaw 2026.5.7** — AI-помощник для диагностики и `/approve`-action'ов через WinRM.
+
+**Алерт-уровни:**
+- `OK` — всё доступно;
+- `WARNING` — часть проверок упала;
+- `WARNING_NETBIRD` — NetBird до server1c лежит, публично сервер виден;
+- `CRITICAL` — сервер не отвечает ни публично, ни через NetBird.
+
+Антиспам: алерт шлётся **только при смене уровня**, состояние в `/var/lib/severny-les/state.json`.
+
+**WinRM-actions с подтверждением:**
+- read-only без approval (`/status`, `/check_1c`, `/check_rmngr`);
+- destructive с обязательным `/approve` от Олега `1292155421` (`/restart_1c`, `/kill_orphan_ragent`);
+- ребута сервера НЕ даём (по опыту 2026-05-07 не помогает rmngr-loop).
+
+## Превентивные правки на старте (уроки 137)
+
+Все три "ловушки openclaw" пропатчены сразу:
+1. `plugins.entries.bonjour.enabled = false` — против mDNS crash-loop (см. [[projects/dttb/openclaw#Crash-loop-каждые-40-сек]]).
+2. `pct set 139 --nameserver '1.1.1.1 8.8.8.8'` + правка `/etc/resolv.conf` — против FakeIP DNS от 10.0.0.1.
+3. `NODE_OPTIONS=--dns-result-order=ipv4first` в systemd unit — против IPv6-сбоев Telegram API.
+
+systemd unit для openclaw — **system-level** (`/etc/systemd/system/openclaw-gateway.service`), а не `--user` как на 137. В LXC без user-session `systemctl --user` не работает (`Failed to connect to bus`).
+
+## Что осталось сделать после возвращения Олега
+
+1. **NetBird ACL** `severny-les` → `server1c` (порт 5985 TCP минимум) — без него WinRM-actions не работают, watchdog мониторит только публичные проверки.
+2. **Добавить @bz_sl_bot в TG-группу** руководящего состава, узнать `chat_id`, обновить `/etc/severny-les/watchdog.env` `BZ_TG_CHAT` и `openclaw.json` `groupAllowFrom`.
+3. После миграции server1c на свой сервер — обновить IP в `/root/clawd/INFRASTRUCTURE.md` и в `buzharovo-watchdog.sh`.
+
+## Артефакты
+
+- LXC 139 `severny-les` (10.0.0.240)
+- TG bot `@bz_sl_bot` (token `8322860033:...`)
+- Справочник: [[projects/buzharovo/severny-les-bot]]
+- Persona: `/root/clawd/{IDENTITY,INFRASTRUCTURE,USER,SOUL,TOOLS,MEMORY,HEARTBEAT}.md`
+- Скрипты: `/root/clawd/scripts/check_buzharovo.sh`, `winrm_lib.py`, `check_1c_service.py`, `check_rmngr_cpu.py`, `restart_1c_agent.py`, `kill_orphan_ragent.py`, `heartbeat.sh`
+- Watchdog: `/usr/local/bin/buzharovo-watchdog.sh` + `.service` + `.timer` (60s); `netbird-watchdog` clone с 137 (2 мин)
+- Whitelist: `/root/.openclaw/exec-approvals.json`
--- a/decisions/2026-05-14-buzharovo-watchdog-public-only.md
+++ b/decisions/2026-05-14-buzharovo-watchdog-public-only.md
@@ -0,0 +1,85 @@
+---
+date: 2026-05-14
+type: decision
+tags: [decision, buzharovo, watchdog, netbird, monitoring, openclaw]
+---
+
+# 2026-05-14: Watchdog Бужарово — только публичный канал, NetBird вынесен из alert level
+
+## Контекст
+
+Олег в Египте, прислал что бот "сыпал ошибками вчера, попросил отключить мониторинг". Разведка:
+
+1. **Все сервисы на LXC 139 живы** (`openclaw-gateway`, `buzharovo-watchdog.timer`, `netbird-watchdog.timer`, `netbird.service` — `active+enabled`). Олег ничего не отключал.
+2. **Watchdog v1 правильно держал `WARNING_NETBIRD`** (последний алерт 13 мая ~19:32 МСК), антиспам корректный — повторных алертов не слал.
+3. **Истинный источник "ошибок"** — `openclaw primary model = omniroute/cc/claude-opus-4-7` упёрся в лимит Max-подписки:
+   ```
+   omniroute (cc/claude-opus-4-7) returned a billing error — your API key has run out of credits
+   400 [400]: You're out of extra usage. Add more at claude.ai/settings/usage and keep going.
+   ```
+   Каждое сообщение в боте + каждое ночное `memory-core dreaming` (cron 03:00) → billing 400 → failover на `kr/claude-sonnet-4.5`. На клиенте часть запросов могла отдаться с ошибкой раньше чем failover отработал.
+4. **Server1C NetBird daemon (Windows)** регулярно flap'ает, `last_seen=2026-05-13T08:24:26` — > 25 часов вне mesh, хотя сервер сам публично жив (ping + RDP 3389 OK).
+
+## Решения
+
+### Фикс 1: primary model → free Sonnet 4.5
+
+`/root/.openclaw/openclaw.json`:
+```json
+{
+  "primary": "omniroute/kr/claude-sonnet-4.5",
+  "fallbacks": [
+    "omniroute/cc/claude-sonnet-4-6",
+    "omniroute/gh/claude-sonnet-4.5",
+    "omniroute/cc/claude-opus-4-7"
+  ]
+}
+```
+Hot-reload подхватился. Backup конфига — `/root/.openclaw/openclaw.json.bak.opus-billing-<ts>`.
+
+**Возврат на Opus как primary — только после пополнения Max** или подключения второго конектора в OmniRoute.
+
+### Фикс 2: watchdog v2 — только публичный канал
+
+Переписан `/usr/local/bin/buzharovo-watchdog.sh`. Логика alert-level **больше не учитывает NetBird-проверки**:
+
+- `OK` — `ping 185.13.47.2` ✓ + `TCP 3389` (RDP) ✓
+- `DEGRADED` — один из публичных упал
+- `CRITICAL` — оба публичных упали
+
+NetBird-уровень (`ping 100.70.75.103` + `TCP 5985`) **только логируется** в `state.json` (`ping_nb`, `winrm_nb`), но не меняет level и не порождает алерт.
+
+При первом алерте в новую сессию (prev_level=INIT) добавляется пометка:
+> _NetBird до сервера сейчас лежит — это известная регулярная проблема со стороны Windows-сервера, не влияет на работу 1С для пользователей. Watchdog проверяет только публичный канал._
+
+**Почему так:** NetBird daemon на Server1C (Windows 2012 R2) теряет mesh-сессию регулярно (memory `feedback_netbird_watchdog`). Лечится `Restart-Service netbird` через RDP — но это ручная операция, и поток алертов из-за этого был шумом, а не сигналом. Сервер для пользователей в Бужарово при этом работает — 1С локально доступна.
+
+**Что теряем:** WinRM-actions (`check_1c_service.py`, `check_rmngr_cpu.py`, `restart_1c_agent.py`, `sql_native_backup.py`) идут через NetBird (`100.70.75.103:5985`). Когда NetBird падает — эти actions недоступны. Бот в группе об этом честно скажет: "Не могу проверить состояние службы 1С — туннель до сервера временно лежит". Восстанавливается после `Restart-Service netbird` на server1c через RDP.
+
+**Что НЕ теряем:** алерты о реально критичных событиях (сервер физически лёг публично, сеть провайдера упала, RDP закрылся).
+
+## Деплой
+
+```bash
+pct push 139 wd.sh /usr/local/bin/buzharovo-watchdog.sh
+chmod +x /usr/local/bin/buzharovo-watchdog.sh
+chown root:root /usr/local/bin/buzharovo-watchdog.sh
+echo "{}" > /var/lib/severny-les/state.json   # force re-evaluate
+# Manual run → level=OK, alert "Мониторинг включён" ушёл в группу
+```
+
+## Обновления в vault и persona
+
+- `/root/clawd/MEMORY.md` на LXC 139 — добавлены уроки про Opus billing + watchdog v2
+- [[projects/buzharovo/severny-les-bot]] — обновить ссылку на watchdog v2 (TODO)
+- Этот decision-файл
+
+## NetBird route 10.0.0.0/24 — попутно
+
+Существующий route `Dom` (`cud7q73l0ubs73dr3gc0`) advertised через peer `pve 100.70.121.235 (Эстония)`, **disconnected**. Переключил routing peer на **`openclaw` (`d79s9g2fadhs739mihkg`)** через PUT `/api/routes/cud7q73l0ubs73dr3gc0`. Mac получил доступ к 10.0.0.0/24 через NetBird → openclaw → LAN.
+
+## TODO (опционально, не сейчас)
+
+- **Reverse SSH-туннель** server1c → severny-les для WinRM-actions без зависимости от NetBird. Server1C сам делает outbound SSH → LXC 139 пробрасывает 127.0.0.1:55985 → server1c:5985. WinRM-скрипты целятся в `localhost:55985`. Решает проблему "NetBird лёг — WinRM недоступен".
+- **HTTPS WinRM (5986)** публично с certificate-pin'ом — альтернатива через интернет, но требует настройки SSL и хорошего firewall.
+- **Ночной cron sql_native_backup.py** — автоматизация ежедневных бэкапов БД (TODO от 2026-05-08, см. соответствующий decision).