@@ -90,6 +90,8 @@ docker run --rm alpine sh -c 'apk add -q openssh sshpass && sshpass -p 1316261 s
> ⚠️ **ВАЖНО (2026-09-14):** `1316261` — пароль **только от OpenWrt-роутера `192.168.2.2`**. Это **НЕ пароль от TrueNAS** (Alex: «Это не пароль от truenas»). Не использовать его для root-операций на TrueNAS.
> ⚠️ **ВАЖНО (2026-09-14):** `1316261` — пароль **только от OpenWrt-роутера `192.168.2.2`**. Это **НЕ пароль от TrueNAS** (Alex: «Это не пароль от truenas»). Не использовать его для root-операций на TrueNAS.
>
>
> 🔑 **Root-операции на TrueNAS делать через WebUI → System → Shell** — этот шелл работает под root, пароль не требуется. Так сделаны `mkdir -p /mnt/.ix-apps/app_configs` и `chown nas:nas /mnt/RED_2TB/backup/t610`. `truenas_admin` **не имеет passwordless sudo** (подтверждено многократно).
> 🔑 **Root-операции на TrueNAS делать через WebUI → System → Shell** — этот шелл работает под root, пароль не требуется. Так сделаны `mkdir -p /mnt/.ix-apps/app_configs` и `chown nas:nas /mnt/RED_2TB/backup/t610`. `truenas_admin` **не имеет passwordless sudo** (подтверждено многократно).
>
> 🧑 **У Alex ЕСТЬ root-SSH на TrueNAS** (2026-09-14: `root@truenas[/mnt/RED_2TB/backup/t610]#`). Агент не должен предлагать ему WebUI-инструкции, если он уже сказал, что работает под root-shell. Агенту root-SSH **недоступен** — только `truenas_admin`.
> 💡 **Бэкап firewall OpenWrt перед любой правкой redirect-правил** (вошло в практику 2026-09-01):
> 💡 **Бэкап firewall OpenWrt перед любой правкой redirect-правил** (вошло в практику 2026-09-01):
**Как ходить с t610 на NAS (факт-проверка 2026-09-14):**`t610 → 192.168.2.197`**ping OK**, а вот **Mac → 192.168.2.197 ping FAIL** (прямого пути нет). То есть бэкап на сторону NAS делается от **t610**, а не от Mac.
**Как работает (проверено 2026-09-14):**крон на TrueNAS от юзера **`nas`** → `ssh` на t610 (ключ `/mnt/RED_2TB/backup/t610/.ssh/id_ed25519`, ограничен `from="192.168.2.197"`) → `tar czf -` собирается НА t610 → архив `t610-config-<ts>.tar.gz` (~605 КБ, 111 файлов) в `/mnt/RED_2TB/backup/t610/` → датасет `backup` целиком уходит в `mailru-crypt:` по воскресеньям. **Лог:**`backup.log` в той же папке.
⚠️ Запись в `/mnt/RED_2TB/backup/` требует **root**; у`truenas_admin`**нет passwordless sudo**. Варианты: root-ключ / отдельный share / стейджинг в `/tmp/` + подмена Alex'ом.
⚠️ **Важно про права (обновлено 2026-09-14):** запись в `/mnt/RED_2TB/backup/` требует root (было `root:root 775`), **но** целевой датасет `backup/t610` — `nas:nas 770`, поэтому сам бэкап пишется **без root**. `truenas_admin` добавлен в группу `nas`. Root нужен был только для `chown nas:nas /mnt/RED_2TB/backup/t610` (один раз). ⚠️ **Пароль `1316261` — НЕ от TrueNAS** (он от OpenWrt-роутера), root-операции — через System → Shell.
- **rclone remotes на Mac отсутствуют** (`rclone listremotes` пуст) — конфиг с`mailru-crypt` живёт **только на TrueNAS**. Бэкап проектировать на стороне NAS, не Mac.
- **rclone remotes на Mac отсутствуют** (`rclone listremotes` пуст) — конфиг с`mailru-crypt` живёт **только на TrueNAS**. Бэкап проектировать на стороне NAS, не Mac.
- **Точки входа:** `ssh truenas_admin@mallexxx.duckdns.org` (внешний), `192.168.2.197` (LAN, только с t610).
- **Точки входа:** `ssh truenas_admin@mallexxx.duckdns.org` (внешний), `192.168.2.197` (LAN, только с t610).
4.**SMB-шара `t610`** — не для доставки (HA OS не умеет SMB-пуш), а **для ручного доступа Alex** к бэкапам с Mac/телефона без ssh.
4.**SMB-шара `t610`** — не для доставки (HA OS не умеет SMB-пуш), а **для ручного доступа Alex** к бэкапам с Mac/телефона без ssh.
5.**Ключ ограничен** на стороне t610: `from="192.168.2.197"` + `no-port-forwarding,no-pty,no-X11-forwarding,no-agent-forwarding`. Т.е. даже при утечке — только стянуть архив, шелла нет.
5.**Ключ ограничен** на стороне t610: `from="192.168.2.197"` + `no-port-forwarding,no-pty,no-X11-forwarding,no-agent-forwarding`. Т.е. даже при утечке — только стянуть архив, шелла нет.
## Что сделано (2026-09-14)
## ✅ СТАТУС: РАБОТАЕТ (проверено живым прогоном 2026-09-14)
| 2 | 🔴 **Zigbee `network_key`** | в **опциях** аддона zigbee2mqtt (не в `/config/zigbee2mqtt/`) | `coordinator_backup.json` в архиве есть, но без `network_key` сеть **не поднять** — все устройства перепаривать |
| 3 | 🔴 **Node-RED `flows_cred.json`** | `/addon_configs/a0d7b954_nodered/` (не читается обычным листингом; секрет `$` — в опциях) | без крипто-секрета креды не расшифруются → **все ноды HA подключать заново** |
| 4 | 🟡 `home-assistant_v2.db` (9.2M) + `-wal` (4.1M) | `/config/` | история сенсоров, **статистика энергии**, климат. Бэкапить на живой системе рискованно (неконсистентность) — через SQLite backup API |
| 5 | 🟡 Файлы `*.bak-*` | `/config/` (6 config + 4 automations) | точки отката миграции, размер мизерный |
**Не нужно бэкапить:**`/config/.cache`, `deps`, `tts`, `.cloud` (пустые/кеш), `.HA_VERSION`, `home-assistant_v2.db-shm`.
**Решение (предложено, ожидает ответа Alex):** добавить в `backup-t610.sh` выгрузку опций аддонов через Supervisor API в JSON перед `tar`. Целевой размер архива ~10–15 МБ.
## Ключевые питфоллы (найдены в этой сессии)
## Ключевые питфоллы (найдены в этой сессии)
### 1. 🔴 `from="192.168.2.197"` — Mac НЕ подходит для проверки ключа
### 1. 🔴 `from="192.168.2.197"` — Mac НЕ подходит для проверки ключа
Mac заходит на t610 как **`192.168.2.157`** (через NAT Rasputin), а не как `.197`. Поэтому `ssh -i <ключ> root@192.168.2.176`**с Mac всегда даёт `Permission denied (publickey)`** — это **правильное поведение** ограничения, а не поломка ключа. Проверять pull-ключ **только с TrueNAS**:
Mac заходит на t610 как **`192.168.2.157`** (через NAT Rasputin), а не как `.197`. Поэтому `ssh -i <ключ> root@192.168.2.176`**с Mac всегда даёт `Permission denied (publickey)`** — это **правильное поведение** ограничения, а не поломка ключа. Проверять pull-ключ **только с TrueNAS** (путь к конфигу — итоговый, см. питфолл №9):
`zfs list` → пусто/`command not found`. Вызывать по абсолютному пути: **`/sbin/zfs`**, **`/sbin/zpool`**. (Иначе можно ошибочно решить, что датасетов нет.)
`zfs list` → пусто/`command not found`. Вызывать по абсолютному пути: **`/sbin/zfs`**, **`/sbin/zpool`**. (Иначе можно ошибочно решить, что датасетов нет.)
### 7. `truenas_admin` не может писать в `~nas` — и `.ssh` надо чинить chown'ом
### 7. `truenas_admin` не может писать в `~nas` — итог: ключ держим в `backup/t610/.ssh` (см. №9)
`~nas` = `/mnt/RED_2TB/storage/nas` (`drwxrwx--- truenas_admin`). `truenas_admin` файлы туда **положить может**, но создаёт их владельцем `truenas_admin` → `nas` их не прочитает. Поэтому после укладки ключа обязателен `chown -R nas:nas ~nas/.ssh`.
`~nas` = `/mnt/RED_2TB/storage/nas`. Промежуточная попытка класть ключ туда **провалилась** (см. №9) — итоговое место ключа: **`/mnt/RED_2TB/backup/t610/.ssh/`**.
### 8. Пароль `1316261` — ❌ НЕ от TrueNAS
### 8. Пароль `1316261` — ❌ НЕ от TrueNAS
В доке `[[family/how-to/truenas-access]]` строка «Пароль root: `1316261`» **ошибочна** для TrueNAS. Alex: «Это не пароль от truenas». `1316261` — пароль от OpenWrt-роутера `192.168.2.2` (там он и правильный). **Для TrueNAS root-операций использовать WebUI → System → Shell** (работает под root, пароль не нужен).
В доке `[[family/how-to/truenas-access]]` строка «Пароль root: `1316261`» **ошибочна** для TrueNAS. Alex: «Это не пароль от truenas». `1316261` — пароль от OpenWrt-роутера `192.168.2.2` (там он и правильный). **Для TrueNAS root-операций использовать WebUI → System → Shell** (работает под root, пароль не нужен).
> 📌 Alex работает под root по SSH сам — **не предлагать ему WebUI-инструкции**, если он уже сказал, что у него есть root-shell.
## Команды (для воспроизведения)
### 9. 🔴 Ключ класть в `backup/t610/.ssh`, НЕ в `~nas/.ssh` — родительский `storage/` непроходим для `nas`
**Симптом:** `Can't open user config file /mnt/RED_2TB/storage/nas/.ssh/config: Permission denied` — при том что сам `.ssh` был `nas:nas 700`.
**Причина:**`nas` не может пройти **сквозь родителей**:
```
/mnt/RED_2TB/storage drwxr-x--- truenas_admin:truenas_admin ← nas не владелец, группы хватает только на r-x
/mnt/RED_2TB/storage/nas drwxrwx--- truenas_admin:truenas_admin ← nas не владелец и не в группе → нет x
/mnt/RED_2TB/storage/nas/.ssh drwx------ nas:nas ← сам в порядке, но путь закрыт
```
`truenas_admin` — **не владелец**`~nas` (после chown), а группа имеет только `r-x` → **создавать там файлы нельзя** (`mkdir: Permission denied`).
**Решение (root НЕ нужен):**`/mnt/RED_2TB/backup/t610` — `nas:nas 770`, группа имеет `rwx`, `truenas_admin` в группе `nas` → пишет свободно. Ключ и `config` кладутся туда, затем `chown nas:nas` (работает **без root**, т.к. `truenas_admin` — владелец созданных файлов):
chown nas:nas /mnt/RED_2TB/backup/t610/.ssh/{config,id_ed25519}# ← БЕЗ root, работает
```
> 💡 **Урок:** `chown nas:nas` на **свои** файлы проходит без root. Root нужен только для чужих. Прежде чем просить Alex'а — проверить `ls -ld` по всей цепочке родителей и `touch` на запись.
### 10. 🔴 `midclt call cronjob.run` даёт ЛОЖНЫЙ `exit 137`/`exit 143` — не признак поломки скрипта
**Симптом:** задача падает за ~1 сек с `CronTask "..." exited with 137 (non-zero) exit status` — хотя скрипт рабочий.
**Причина:** middleware прибивает таск (SIGKILL=137 / SIGTERM=143), когда родительский job `cronjob.run` завершается раньше дочернего процесса. Это баг API-пути, а не скрипта.
**Как отличить:** смотреть **несколько** job'ов и **файловый лог скрипта**. Реальные ошибки скрипта видны как его собственные коды (`exit 2`, `exit 3`) + запись в `backup.log`/`.err`.
**Правильная проверка:** ставить задачу на `* * * * *`, **ждать реального срабатывания** и смотреть появившийся архив, потом вернуть расписание:
### 12. `scp` поверх чужого файла не работает, но `mv` в групповом `rwx`-каталоге — работает
`scp` даёт `Permission denied` при перезаписи файла, принадлежащего `nas`. Обход: положить под новым именем и сделать `mv` (каталог `770` даёт группе `rwx`). ⚠️ После `mv` владелец/права **сбрасываются** на копирующего → обязателен `chmod 755` + `chown nas:nas`.
### 13. `cronjob.run` вызывается кроном как `midclt call cronjob.run <id> true` — задачи от `nas` работают
Проверено: `/etc/cron.d/middlewared` содержит `* * * * * root ... midclt call cronjob.run 2 true`. Системный `cron -f` + `busybox crond -f` живут. Задачи от `nas`**выполняются штатно** (job state=SUCCESS, файлы появляются) — «крон не работает» было ложной тревогой от проверки файла до первой минуты.
### 14. `set -u` + `exit` в циклах на zsh-стороне ломает проверки
Проверки через `ssh ... 'ls /path/*.tar.gz'` на **zsh**-цели дают `zsh:1: no matches found` и рвут цикл (скрипт выходит до `sleep`). Использовать `bash -c` на удалённой стороне или `test -f` / `ls -1 ... 2>/dev/null`.
**Ротация:** хранить N последних архивов (N согласовать).
> ⚠️ НЕ входит (и стоит добавить): **опции аддонов**, `network_key` Zigbee, `flows_cred.json`, `home-assistant_v2.db`. Детали — раздел «НЕ ЗАКРЫТО» выше.
| ~~**B2**~~ | ~~**Node-RED наружу** — выставить порт аддона и поправить Caddy~~ | — | **✅ СНЯТО (2026-09-14 вечер-7):** решение Alex — «оставляем так». Node-RED доступен через **ingress** HA (`http://192.168.2.176/api/hassio_ingress/<token>/`), наружу не выпускается. Домен `nodered.*` не используется. См. §5-кватер-Г и `[[family/how-to/nodered-ventilation]]` |
| ~~**B2**~~ | ~~**Node-RED наружу** — выставить порт аддона и поправить Caddy~~ | — | **✅ СНЯТО (2026-09-14 вечер-7):** решение Alex — «оставляем так». Node-RED доступен через **ingress** HA (`http://192.168.2.176/api/hassio_ingress/<token>/`), наружу не выпускается. Домен `nodered.*` не используется. См. §5-кватер-Г и `[[family/how-to/nodered-ventilation]]` |
| ~~A2~~ | ~~**№7**: Static IP для t610~~ | — | **✅ ВЫПОЛНЕНО 2026-09-14 (вечер-8, §5-кватер-И-1):** на роутере `192.168.2.2` создана static-привязка `dhcp.@host[1]` = `t610` / MAC `9c:8e:99:ef:3f:c5` / `192.168.2.176` → `uci commit dhcp` + `dnsmasq reload`. Проверено: `ping` OK, HA → HTTP 200. Бэкап `/root/dhcp.bak-20260914-104152` |
| ~~A2~~ | ~~**№7**: Static IP для t610~~ | — | **✅ ВЫПОЛНЕНО 2026-09-14 (вечер-8, §5-кватер-И-1):** на роутере `192.168.2.2` создана static-привязка `dhcp.@host[1]` = `t610` / MAC `9c:8e:99:ef:3f:c5` / `192.168.2.176` → `uci commit dhcp` + `dnsmasq reload`. Проверено: `ping` OK, HA → HTTP 200. Бэкап `/root/dhcp.bak-20260914-104152` |
| A3 | **№8**: Бэкап конфигов t610 | 🔶 почти готов | ① **✅ git-синк СДЕЛАН 2026-09-14:** коммит `9d31118` запушен в Gitea (SHA local == remote) — `configuration.yaml`, `automations.yaml`, **новый**`homeassistant/go2rtc.yaml`, `config.yml`. ② **🔄 автобэкап на TrueNAS (выбран вариант B — pull с TrueNAS):** датасет `/mnt/RED_2TB/backup/t610` (`nas:nas` 770) ✅, SMB-шара `t610` (id=3) ✅, ssh-ключ pull разложен ✅ (t610 `authorized_keys` + `~nas/.ssh/`);**осталось: скрипт + крон под `nas` + живой прогон.** Полный план, команды и 8 питфоллов — **[[family/plans/t610-backup-to-truenas]]**. Прошлый `tar`-бэкап `~/tmp-t610/backups/config-t610-20260914-115034.tar.gz` (88 КБ) **устарел** (до камеры/реле/rotate) |
| ~~A3~~ | ~~**№8**: Бэкап конфигов t610~~ | — | **✅✅ ВЫПОЛНЕНО 2026-09-14 (вечер-15).** ① **git-синк:** коммит `9d31118` в Gitea (SHA local == remote) — `configuration.yaml`, `automations.yaml`, **новый**`homeassistant/go2rtc.yaml`, `config.yml`. ② **автобэкап на TrueNAS (вариант B — pull с TrueNAS):** датасет `/mnt/RED_2TB/backup/t610` (`nas:nas` 770), SMB-шара `t610` (id=3), ssh-ключ в `/mnt/RED_2TB/backup/t610/.ssh/` (ограничен `from="192.168.2.197"`), скрипт `backup-t610.sh` (v3), **крон id=3 юзер `nas` 03:30 ежедневно**, ротация 14. **Живой прогон:** 2 архива `t610-config-*.tar.gz` по ~605 КБ, **111 файлов**. В Mail.ru уезжает автоматически (`backup` ⊂ rclone `backup.sh`).**Полностью — `[[family/plans/t610-backup-to-truenas]]`.** ⚠️ Не входит (кандидаты): опции аддонов, `network_key` Zigbee, `flows_cred.json`, `home-assistant_v2.db` | ✅ закрыто |гон.** Полный план, команды и 8 питфоллов — **[[family/plans/t610-backup-to-truenas]]**. Прошлый `tar`-бэкап `~/tmp-t610/backups/config-t610-20260914-115034.tar.gz` (88 КБ) **устарел** (до камеры/реле/rotate) |
| ~~A4~~ | ~~**Ночной свет душевой**: триггер на падение освещённости~~ | — | **✅ ВЫПОЛНЕНО 2026-09-14 (вечер-8, §5-кватер-И-2):** в automation `1771997851260` добавлен триггер `illuminance below:8` + условие `is_occupied`. Проверено через API: `triggers`=2, `conditions`=2 |
| ~~A4~~ | ~~**Ночной свет душевой**: триггер на падение освещённости~~ | — | **✅ ВЫПОЛНЕНО 2026-09-14 (вечер-8, §5-кватер-И-2):** в automation `1771997851260` добавлен триггер `illuminance below:8` + условие `is_occupied`. Проверено через API: `triggers`=2, `conditions`=2 |
| ~~**A5**~~ | ~~**Камера**: USB-вебка Logitech `046d:0825` на t610 → завести в HA~~ | — | **⚠️ ПЕРЕДЕЛАНО 2026-09-14 (вечер-11).** Сначала (вечер-9) завели через `camera: platform: ffmpeg` — **отвергнуто** (`Resource busy`, нет `unique_id`). **Итог вечер-11:** аддон `local_ustreamer` + Generic Camera → `camera.192_168_2_176`, зона `kotelnaia`, `unique_id` ✅. Детали — §5-кватер-И-5 |
| ~~**A5**~~ | ~~**Камера**: USB-вебка Logitech `046d:0825` на t610 → завести в HA~~ | — | **⚠️ ПЕРЕДЕЛАНО 2026-09-14 (вечер-11).** Сначала (вечер-9) завели через `camera: platform: ffmpeg` — **отвергнуто** (`Resource busy`, нет `unique_id`). **Итог вечер-11:** аддон `local_ustreamer` + Generic Camera → `camera.192_168_2_176`, зона `kotelnaia`, `unique_id` ✅. Детали — §5-кватер-И-5 |
| ~~**A6**~~ | ~~**Камера — вернуть схему «как на TrueNAS»** (решение Alex, вечер-10)~~ | — | **✅✅ ВЫПОЛНЕНО 2026-09-14 (вечер-11, §5-кватер-И-3/И-5).** Историч. upstream был `cam.mallexxx.duckdns.org → 192.168.2.197:8090` (контейнер утрачен при пересоздании пула, след — `Caddyfile.bak`). Реализовано **аддоном на t610** (вебка физически там, Docker в HA OS закрыт → аддон). Поднят `local_ustreamer` (`/addons/ustreamer/`, MJPEG :8090) → Generic Camera по URL → **`unique_id` + зона `kotelnaia` + имя «Камера котельной»**. Блок `camera: platform: ffmpeg` из `configuration.yaml`**снесён** (бэкап `.bak-rmcam-20260914-185240`). Осталось: удалить лишний `/config/go2rtc.yaml` |
| ~~**A6**~~ | ~~**Камера — вернуть схему «как на TrueNAS»** (решение Alex, вечер-10)~~ | — | **✅✅ ВЫПОЛНЕНО 2026-09-14 (вечер-11, §5-кватер-И-3/И-5).** Историч. upstream был `cam.mallexxx.duckdns.org → 192.168.2.197:8090` (контейнер утрачен при пересоздании пула, след — `Caddyfile.bak`). Реализовано **аддоном на t610** (вебка физически там, Docker в HA OS закрыт → аддон). Поднят `local_ustreamer` (`/addons/ustreamer/`, MJPEG :8090) → Generic Camera по URL → **`unique_id` + зона `kotelnaia` + имя «Камера котельной»**. Блок `camera: platform: ffmpeg` из `configuration.yaml`**снесён** (бэкап `.bak-rmcam-20260914-185240`). Осталось: удалить лишний `/config/go2rtc.yaml` |
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Alexey Martemyanov