infra/servers/rpi.md

rpi — домашняя Raspberry Pi 4 (rpi.local, 192.168.10.25)

Поднята 2026-10-11. Домашний сервер за NAT: первая задача — бэкап личного OneDrive на внешний HDD. Мониторится с fr1 через pushgateway (скрейпить её снаружи нельзя — она за домашним роутером).

Железо и ОС

• Raspberry Pi 4, SD 64 ГБ (mmcblk0), питание штатное — vcgencmd get_throttled = 0x0.
• Raspberry Pi OS Lite 64-bit Trixie (Debian 13), образ 2026-10-06-raspios-trixie-arm64-lite.
• Headless-настройка — cloud-init, а не старые ssh/userconf.txt: в Trixie Pi Imager пишет user-data/network-config на bootfs. Наш user-data создал пользователя, ключ, hostname, таймзону MSK.
• Сеть: Ethernet, DHCP. MAC dc:a6:32:db:b0:f9, роутер 192.168.10.254. ⏳ Резерв адреса на роутере — на пользователе (см. хвосты).

Доступ

• С Mac: ssh rpi (алиас → rpi.local, user rus, ключ ~/.ssh/id_ed25519). Резолвится через mDNS (avahi в образе по умолчанию).
• Только по ключу: passwordauthentication no, у rus пароль заблокирован, sudo NOPASSWD (иначе sudo был бы недоступен вовсе).

Диски

Устройство	Модель	Роль
sda	WD My Passport 4 ТБ (WD40NDZW, s/n WD-WX82D6228YCD)	ext4 backup → /mnt/backup
—	WD Elements 1 ТБ (WD10SDRW)	не подключён, ждёт хаба (APFS, не отформатирован)

• fstab по UUID с nofail,x-systemd.device-timeout=30s (stacks/rpi-backup/fstab.line): без диска малина грузится, бэкап просто пропускается (mountpoint -q).
• ⚠️ Два 2.5" HDD от USB Pi 4 не тянут. Проверено 2026-10-11: при раскрутке обоих — over-current на всех USB3-портах; под нагрузкой 4-ТБ диск отваливался (USB disconnect) и залипал в Unit Not Ready. Один диск стабилен (20 ГБ чтения 103 МБ/с, mkfs ~60 ГБ записи без сбросов). Второй диск — только через USB3-хаб с собственным питанием.
• Залипший после отвала диск лечится power-cycle всех USB (Pi 4 переключает питание портов только разом): sudo uhubctl -l 2 -a off; sudo uhubctl -l 1-1 -a off; sleep 8; …-a on.
• SMART на момент ввода: 9 897 ч, 0 переназначенных/ожидающих, Start_Stop 21 946, Load_Cycle 42 530.

Бэкап OneDrive (код — stacks/rpi-backup/)

• rclone (официальный .deb, v1.75.2 — в Debian 1.60, старый), remote onedrive: = личный OneDrive (drive_type personal). Токен — в ~rus/.config/rclone/rclone.conf (600), только на малине. Получен через rclone authorize onedrive на Mac.
• onedrive-backup (таймер каждые 4 ч, 00/4:30): rclone sync в /mnt/backup/onedrive/current, всё удалённое/перезаписанное в облаке — в archive/<ts>/ навсегда (пользователь хочет иметь всё, что когда-либо было в OneDrive). Хэши архива — manifests/archive-<ts>.qxh, лог каждого прогона — logs/sync-<ts>.log (INFO: поштучно что скачано/убрано в архив).
• Целостность: rclone сверяет QuickXorHash каждого скачанного файла с OneDrive; onedrive-verify (вс 05:00) перечитывает весь HDD: rclone check current↔облако + rclone checksum archive↔манифесты. Отчёт — logs/verify-<ts>*.
• Оба юнита под общим flock /run/lock/onedrive-backup.lock — не идут параллельно и не убивают друг друга.
• ⚠️ Файл, загруженный и удалённый в облаке между прогонами (<4 ч), в бэкап не попадёт.
• ⚠️ Personal Vault исключён — rclone через API туда не ходит.
• ⚠️ Архив без ротации: растёт вечно. Скрипт выходит с кодом 2 при заполнении >90 % (→ алерт BackupFailed), плюс HostDisk* если когда-то поставим node-exporter.
• Первая полная выгрузка (368 ГБ) запущена 2026-10-11 ~13:13, ~27 МБ/с (упор в домашний канал).

Вторая копия — 1 ТБ диск в роутере (с 2026-10-11)

• Диск воткнут в роутер Huawei (192.168.10.254), а не в малину — не ест питание USB малины (два HDD от неё не тянут, см. «Диски»). Доступ — SFTP роутера на порту 8022, пользователь root, remote router: в ~rus/.config/rclone/rclone.conf (пароль только там), host key — ~rus/.ssh/known_hosts_router.
• ⚠️ Роутер не считает хэши (shell_type = none, md5sum_command = none) — rclone сравнивает по размеру+mtime, целостность проверяется перечиткой.
• mnt-router.service — rclone mount router: /mnt/router (user rus, --vfs-cache-mode writes, кэш в /mnt/backup/.rclone-cache). Для просмотра/ручной работы; бэкап пишет напрямую в remote, не через FUSE (коды ошибок, без кэша).
• Скорость (замер 2026-10-11, параллельно с выгрузкой OneDrive): запись ~8 МБ/с, чтение ~11 МБ/с — первичная копия ~370 ГБ ≈ 13 ч. Диск 932 ГБ.
• router-backup (stacks/rpi-backup/, таймер 06:00, flock): в router:rpi-backup/ — onedrive/{archive,manifests,logs} только copy (там ничего не удаляется), затем зеркало onedrive/current с --max-delete 1000, затем зеркало зашифрованных servers/ с --max-delete 50. Порядок важен: удалённое из current к этому моменту уже скопировано в archive. Логи — /mnt/backup/router-logs/.
• ⚠️ --max-delete — предохранитель: если локально «пропадёт» много файлов (сбой диска/монтирования), копия на роутере не зачистится, а прогон упадёт с ошибкой → алерт BackupFailed.
• По воскресеньям verify: сверка размеров деревьев + перечитать с роутера последний daily каждого сервера и сравнить sha256.
• Ежемесячно (1-го, 08:00) router-sample: случайные файлы OneDrive из current/ и archive/ старше суток, ~2 ГБ / до 300 шт., перечитываются с роутера и сверяются sha256 с HDD — ловит тихую порчу, которую сверка размеров не видит. Отсутствующий на роутере файл = ошибка. Итог — backup_*{job="backup_router_sample"} → BackupFailed, BackupStale (>35 дней). Проверено 2026-10-11: 20 из 20 скопированных файлов совпали.
• Мониторинг: router_mount_up и заполнение /mnt/router (в smart-metrics, df под timeout 20), итог прогона — backup_*{job="backup_router"}; алерты RouterDiskMountDown (30 мин), BackupDiskFull (>90 %, любой диск бэкапа), BackupStale (>30 ч); ряд «Вторая копия» на дашборде rpi-disk.
• ⚠️ 1 ТБ меньше основного диска: сейчас влезает (~370 ГБ OneDrive + ~100 ГБ серверов), но архив версий растёт вечно — следить за BackupDiskFull.

Бэкап серверов fr1/ru1 (с 2026-10-11, код — stacks/server-backup/)

• Малина — внешняя площадка для VPS: servers-backup.timer (02:15) забирает по SSH выгрузки, которые сервер сам шифрует открытым ключом age (tar | zstd | age). Закрытого ключа на малине нет — ни она, ни Astra, ни взломщик архивы не прочитают. Ключ у владельца: Mac ~/.config/age/servers-backup.key.
• Хранилище /mnt/backup/servers/<host>/{daily,weekly,monthly} (root 700): 14 / 8 / 12, monthly — хардлинк первого daily месяца. fr1 daily ~2.1 ГБ (5.5 мин), ru1 ~17 МБ, fr1 weekly (вс) — тома ботов и imgbot.
• Ключ /etc/server-backup/id_ed25519 (root 600): на серверах ограничен forced command — только запустить выгрузку. Host keys закреплены в /etc/server-backup/known_hosts.
• Целостность: sha256 шифротекста считает сервер, малина сверяет при приёме и по воскресеньям (servers-backup verify). Итог — метрики backup_*{job="backup_servers"}, алерт BackupStale >26 ч, панель на дашборде rpi-disk.
• Пробное восстановление 2026-10-11 на Mac: оба архива расшифрованы, на месте CA OpenVPN (easy-rsa/pki/private/ca.key), ключи AWG, конфиги прокси, репо gitea, снимок gitea.db.

Мониторинг → fr1

• smartd (stacks/rpi-backup/smartd.conf): DEVICESCAN -d removable, -n standby,q (не будить диск), короткий самотест сб 03:00, длинный 1-го числа 05:00. ⚠️ -d sat с DEVICESCAN не работает («Not a SAT device») — тип моста пусть определяет сам.
• smart-metrics (таймер 15 мин): smartctl -n standby → метрики smart_* → job smart. Спящий диск не будится: отдаются значения из кэша /var/lib/smart-metrics/ + smart_disk_standby=1.
• backup-metrics <job> — ExecStopPost=+ у юнитов бэкапа: backup_last_exit_code, backup_last_run_timestamp, backup_last_success_timestamp (время успеха хранится локально в /var/lib/backup-metrics/, т.к. PUT заменяет группу целиком).
• Доставка: metrics-push <job> = ssh с ключом /etc/metrics-push/id_ed25519 (root, 600) на rus@161.97.93.252; host key fr1 закреплён в /etc/metrics-push/known_hosts. На fr1 ключ ограничен forced command (servers/fr1.md → Мониторинг).
• smart-metrics заодно отдаёт backup_disk_size_bytes/backup_disk_avail_bytes для /mnt/backup (statfs, диск не будит).
• Дашборд: https://mon.ruzzy.dev/d/rpi-disk (SMART, износ за сутки, свежесть бэкапов, заполнение).
• ⚠️ BackupStale видит только существующие серии — задача, ни разу не отчитавшаяся, им не ловится. Для этого BackupNeverReported на absent() (с 2026-10-11): OneDrive 12 ч, серверы 26 ч, роутер 30 ч, проверка OneDrive 8 дней; и PushMetricsStale на отсутствие SMART-метрик 1 ч. Доставка в Telegram проверена тестовым алертом 2026-10-11.
• Алерты — группа rpi в stacks/monitoring/prometheus/rules/alerts.yml.

Домашняя печать (с 2026-10-11)

• Brother DCP-L2620DW обнаружен через mDNS: 192.168.10.24, BRW2C9C58C1EEA7.local, IPP порт 631 /ipp/print; чёрно-белый, A4, двусторонняя печать. Ранее службы печати на rpi не было.
• Установлены cups, cups-client, cups-filters, cups-ipp-utils (CUPS 2.4.10); включён cups.service. Очередь по умолчанию home-brother, драйвер everywhere, URI ipp://BRW2C9C58C1EEA7.local:631/ipp/print. По умолчанию A4, одна сторона; printer-is-shared=false, CUPS слушает только 127.0.0.1:631 и [::1]:631. Доступ из Telegram — команда агента, без отдельного открытого веб-интерфейса.
• Код настройки и команда — stacks/rpi-print/; home-print установлен в /usr/local/bin/ (root, 755). home-print status — состояние/очередь; home-print [--duplex] <PDF/PNG/JPEG> — одна копия, A4 с подгонкой. Печать только по прямой просьбе пользователя; приём задания в очередь не означает, что бумага уже вышла.
• Навык home-print установлен 2026-10-11 в ~astra/.codex/skills/home-print/; источник — astra-bot c01ed22, codex/skills/home-print/. Ранее обязательного предпросмотра не было. При просьбе печати извлекает текст из скриншотов и перевёрстывает чёрным по белому, обычные картинки сохраняет и готовит к ч/б печати, формирует PDF и PNG каждой страницы. Отправляет PNG в Telegram отдельным скриптом (токен только из /etc/astra-bot.env, без вывода). Печатает только после явного подтверждения пользователем доставленного предпросмотра, причём тот же PDF, из которого получены PNG. Исторические сведения не дописывает; неразборчивые/обрезанные места отмечает. Скрипты проверены на двухстраничном PDF, вся серия — 28 тестов; установленный навык валидирован. Подключение к новым разговорам (/new), перезапуск бота не нужен.
• ⚠️ DOCX напрямую не печатается — сначала преобразовать в PDF. Hostname выбран вместо DHCP-IP, чтобы пережить смену адреса; требуется mDNS и включённый принтер. printer-error-policy=abort-job исключает неожиданную автоматическую печать старых заданий после ошибки; ошибочный прогон нужно отправить заново.
• Проверено: запрос атрибутов IPP (ipptool) PASS, принтер idle/enabled, A4/Gray/duplex доступны. Портрет успешно преобразован фильтрами CUPS PNG → PDF → PWG Raster (A4, 300 dpi), без ошибок. Тестовая страница A4 отправлена 2026-10-11 в 15:20 MSK: home-brother-1, CUPS сообщил job-completed-successfully, принтер вернулся в idle, очередь пуста; качество на бумаге проверяет пользователь.

Агент Astra (с 2026-10-11)

Агент на базе Codex (OpenAI), работает на самой малине, управление — из Telegram-бота @rasp_contol_bot. Код бота — отдельный репо ruzzy/astra-bot (там же схема работы).

• Пользователь astra (группы sudo, adm, systemd-journal, users), пароль заблокирован, sudo NOPASSWD (/etc/sudoers.d/90-astra) — по решению пользователя. SSH-вход под ним — ключом ~/.ssh/id_ed25519 с Mac (алиас ssh rpi-astra).
• ⚠️ sudo = агент видит всё: токен OneDrive (~rus/.config/rclone/rclone.conf), пуш-ключ метрик (/etc/metrics-push/), deploy-ключ с записью в infra, токен бота. Утечка контекста агента = утечка этих секретов.
• Codex CLI 0.162.1 — полный пакет в /opt/codex, симлинк /usr/local/bin/codex. ⚠️ Голый бинарник из релиза (codex-aarch64-…tar.gz) не годится: remote-control/app-server требуют пакет (codex-package-aarch64-unknown-linux-musl.tar.gz), иначе «this CLI has no complete local package». Логин — подпиской ChatGPT (codex login --device-auth, аккаунт ruzzyrullezz@gmail.com, Plus), токен ~astra/.codex/auth.json (600). Ключ API не используется.
• Агенту разрешено пушить в main ruzzy/infra напрямую (решение пользователя 2026-10-11, перекрывает правило из CLAUDE.md только для него): любые изменения сервера он обязан внести в servers/rpi.md/stacks/ и запушить в том же прогоне, конфликты — pull --rebase без --force, неразрешимые — отдать пользователю. Источник инструкций — codex/AGENTS.md в ruzzy/astra-bot.
• Конфиг ~astra/.codex/config.toml: approval_policy=on-request, sandbox_mode=workspace-write; инструкции агенту — ~astra/.codex/AGENTS.md (паспорт, правила infra, что не трогать).
• astra-bot (astra-bot.service, user astra): /opt/astra-bot/bot.py ⇄ codex app-server (JSON-RPC stdio) ⇄ Telegram long polling. Подтверждения команд/правок — кнопками в чате. Конфиг /etc/astra-bot.env (root 600): TG_TOKEN, TG_ALLOWED_IDS=607015. Тред Codex на чат — ~astra/.local/state/astra-bot.json. Бот лежит в /opt под root, а не в ~/infra, чтобы агент не правил свой код без sudo.
• Приём вложений исправлен 2026-10-11 (раньше бот читал только text, фото и подписи молча пропадали): код — ruzzy/astra-bot. Фото и JPEG/PNG/WebP-документы до 20 МиБ скачиваются через Telegram getFile в ~astra/.local/share/astra-bot/incoming/ (файлы 600, UUID), передаются Codex как localImage; подпись и источник пересылки — текстом. Пересланные /stop и другие команды читаются как цитата. Во время работы сообщения ставятся в очередь процесса, реальная доставка картинки с подписью и источником подтверждена пользователем 2026-10-11.
• Пачки изображений добавлены 2026-10-11 (раньше каждый элемент альбома запускал отдельную задачу и отдельное уведомление очереди): установлен коммит 6276bf8. Бот собирает альбом по media_group_id/чату/отправителю, быстро пересланные картинки без ID — по чату/отправителю; после 1,5 секунды тишины передаёт все картинки, подписи и источники одним запросом Codex в порядке message_id. Служебные уведомления ожидания убраны 2026-10-11 (коммит c4e3cd1): прежняя проверка пустой очереди повторяла их между пачками; очередь сохранена и работает молча. Проверка включает повторное заполнение опустевшей очереди. Предыдущий код — /opt/astra-bot/bot.py.bak-20261011-silent-queue. 23 теста прошли; изменение загружается при перезапуске через restart-check.py. ⚠️ Пауза больше 1,5 секунды разделяет серию на пачки; буфер и очередь не переживают перезапуск. Предыдущий код — /opt/astra-bot/bot.py.bak-20261011-batches.
• Код бота с доработкой Astra перенесён в ruzzy/astra-bot (f9f6c39; текущая установленная версия — c4e3cd1); временная копия stacks/astra-bot/ удалена 2026-10-11. Клон — ~astra/astra-bot. Резервная копия прежнего кода — /opt/astra-bot/bot.py.bak-20261011-incoming.
• ⚠️ Почему не штатный Codex Remote из ChatGPT: телефон к безголовому Linux не сопрягается — официально хостом может быть только macOS/Windows; codex remote-control pair выдаёт код, но и QR, и ручной ввод дают «Pair Failed», до демона попытка даже не доходит (проверено с debug-логом 2026-10-11). Рабочая альтернатива — ChatGPT Desktop на Mac → SSH-хост rpi-astra, но тогда Mac должен быть включён.
• /boot/firmware/cmdline.txt: добавлен cfg80211.ieee80211_regdom=RU (бэкап .bak-20261011) — только чтобы /etc/profile.d/wifi-check.sh не печатал в stdout login-shell предупреждение про rfkill: оно ломало бы stdio-протоколы (Codex app-server по SSH). Wi-Fi не используется.
• Доступ к Gitea — пользователь astra (с 2026-10-11, вместо двух deploy-ключей): один SSH-ключ ~astra/.ssh/gitea, коллаборатор с записью в ruzzy/infra (~astra/infra) и ruzzy/astra-bot (~astra/astra-bot), может создавать свои репо в astra/… (API-токен ~astra/.config/gitea/token, 600, scopes write:repository,write:user, в Gitea — astra-rpi). Почему пользователь, а не deploy-ключи: deploy-ключом нельзя создавать репо, а права коллаборатора видны и меняются в настройках репо. Создавать репо от имени ruzzy нельзя — он пользователь, не организация. git identity Astra (rpi) <astra@rpi.ruzzy.dev>, host key Gitea (RSA) закреплён. Автопулла нет.

Открытые хвосты (на 2026-10-11)

• ⏳ Закрепить 192.168.10.25 за MAC dc:a6:32:db:b0:f9 на роутере.

• ⏳ USB3-хаб с питанием → подключить и отформатировать WD Elements 1 ТБ (вторая копия архива — сейчас копия одна).

• Нет node-exporter (CPU/RAM/диск самой малины в Prometheus не видны) — пуш через pushgateway для node-метрик неудобен; решить, нужен ли.

• Первый прогон бэкапа стартовал до появления ExecStopPost — его итог может не дойти в метрики; backup_last_success_timestamp появится с первого прогона по таймеру. До этого BackupStale молчит (серии нет).

• ⏳ codex-remote.service (демон codex remote-control с RUST_LOG=debug) всё ещё включён и работает, хотя сопряжение не взлетело — убрать или оставить ждать поддержки Linux от OpenAI (решение за пользователем).

• Токен бота передавался через чат с ассистентом — при желании перевыпустить в @BotFather (/revoke) и вписать в /etc/astra-bot.env.

• ⚠️ Закрытый ключ age бэкапа серверов — одна копия, на Mac. Положить вторую вне малины и вне Mac (менеджер паролей/распечатка), иначе потеря Mac = бэкапы fr1/ru1 бесполезны.

• Разово скопировать на малину ~rus/backups (5.4 ГБ) и ~tgclaude/backups (4.2 ГБ) с fr1 — тогда их можно убрать с fr1.

• Пробное восстановление бэкапа серверов — раз в квартал (следующее ~январь 2027), см. stacks/server-backup/README.md.

• Через неделю снять SMART и посчитать реальный прирост Start_Stop/Load_Cycle — прогноз ресурса пока оценочный.

• ⏳ Определить хранение входящих фото: сейчас автоматически не удаляются ради ссылок в старых тредах; очередь сообщений только в памяти и теряется при перезапуске.