-[feedback_no_unauthorized_actions.md](feedback_no_unauthorized_actions.md) — НЕ самовольничать на серверах
-[feedback_no_unauthorized_actions.md](feedback_no_unauthorized_actions.md) — НЕ самовольничать на серверах
-[feedback_clarify_ambiguous_no.md](feedback_clarify_ambiguous_no.md) — Короткое «нет X» ≠ «делай Y». При multi-choice уточнять, не интерпретировать самостоятельно
-[feedback_no_manual_override.md](feedback_no_manual_override.md) — НЕ вмешиваться в автоматику
-[feedback_no_manual_override.md](feedback_no_manual_override.md) — НЕ вмешиваться в автоматику
-[feedback_alt_bugzilla_defaults.md](feedback_alt_bugzilla_defaults.md) — ALT Bugzilla: priority=P5, rep_platform=x86_64
-[feedback_alt_bugzilla_defaults.md](feedback_alt_bugzilla_defaults.md) — ALT Bugzilla: priority=P5, rep_platform=x86_64
-[feedback_dnsroot_danger.md](feedback_dnsroot_danger.md) — НИКОГДА не менять dnsRoot в AD crossRef
-[feedback_dnsroot_danger.md](feedback_dnsroot_danger.md) — НИКОГДА не менять dnsRoot в AD crossRef
...
@@ -47,6 +48,10 @@
...
@@ -47,6 +48,10 @@
-[feedback_upgrade_sisyphus.md](feedback_upgrade_sisyphus.md) — обновление LXC ALT p11 → Sisyphus
-[feedback_upgrade_sisyphus.md](feedback_upgrade_sisyphus.md) — обновление LXC ALT p11 → Sisyphus
-[feedback_skill_confirmation_direct.md](feedback_skill_confirmation_direct.md) — подтверждения от skill'ов спрашивать напрямую, не через lavtomate
-[feedback_skill_confirmation_direct.md](feedback_skill_confirmation_direct.md) — подтверждения от skill'ов спрашивать напрямую, не через lavtomate
-[feedback_no_routes_on_remote_nat_peers.md](feedback_no_routes_on_remote_nat_peers.md) — НЕ добавлять маршруты на удалённой машине за NAT при настройке туннелей; MASQUERADE на нашей стороне достаточно
-[feedback_no_routes_on_remote_nat_peers.md](feedback_no_routes_on_remote_nat_peers.md) — НЕ добавлять маршруты на удалённой машине за NAT при настройке туннелей; MASQUERADE на нашей стороне достаточно
-[feedback_no_bbr.md](feedback_no_bbr.md) — НЕ включать TCP BBR; оставлять cubic. Не трогать tcp_reordering
-[feedback_lxc_via_ssh_not_pct.md](feedback_lxc_via_ssh_not_pct.md) — В LXC ходить через `ssh root@<ct-ip>`, не через `pct exec` с PVE-host
-[feedback_never_bypass_epm_play.md](feedback_never_bypass_epm_play.md) — НИКОГДА не обходить `epm play` ручной загрузкой бинарей — фиксить prerequisites и повторять
-[reference_remote_ssh_access.md](reference_remote_ssh_access.md) — Доступ к удалённым хостам через reverse-SSH на anyssh.ru: parentglobal=:10337/etersoft, rpi=:10338/root и др.
-[lesson_anyssh_ru_in_91232225.md](lesson_anyssh_ru_in_91232225.md) — anyssh.ru = 91.232.225.8, не маршрутизировать всю /24 через туннель
-[lesson_anyssh_ru_in_91232225.md](lesson_anyssh_ru_in_91232225.md) — anyssh.ru = 91.232.225.8, не маршрутизировать всю /24 через туннель
-[lesson_lavtomate_bug_create_confirmation.md](lesson_lavtomate_bug_create_confirmation.md) — bug_create сломан: НЕ ретраить, проверять через confirmation_check
-[lesson_lavtomate_bug_create_confirmation.md](lesson_lavtomate_bug_create_confirmation.md) — bug_create сломан: НЕ ретраить, проверять через confirmation_check
-[lesson_dns_free_ip_check_both_zones.md](lesson_dns_free_ip_check_both_zones.md) — поиск свободного IP: проверять ОБЕ зоны (forward+reverse) и ping
-[lesson_dns_free_ip_check_both_zones.md](lesson_dns_free_ip_check_both_zones.md) — поиск свободного IP: проверять ОБЕ зоны (forward+reverse) и ping
...
@@ -96,3 +101,6 @@
...
@@ -96,3 +101,6 @@
-[lesson_sieve_domain_split.md](lesson_sieve_domain_split.md) — sieve расщепление при symlink доменов: managesieve пишет по login-домену, доставка читает по spool-symlink → правила Roundcube не применяются
-[lesson_sieve_domain_split.md](lesson_sieve_domain_split.md) — sieve расщепление при symlink доменов: managesieve пишет по login-домену, доставка читает по spool-symlink → правила Roundcube не применяются
-[lesson_lavtomate_master_active_empty.md](lesson_lavtomate_master_active_empty.md) — Lavtomate пишет пустой master active.script без `include "roundcube"` → правила Roundcube глохнут; ручной workaround + задание в lavtomate/docs/task-sieve-master-include.md
-[lesson_lavtomate_master_active_empty.md](lesson_lavtomate_master_active_empty.md) — Lavtomate пишет пустой master active.script без `include "roundcube"` → правила Roundcube глохнут; ручной workaround + задание в lavtomate/docs/task-sieve-master-include.md
-[lesson_bind_dynamic_zone_freeze_thaw.md](lesson_bind_dynamic_zone_freeze_thaw.md) — BIND dynamic (DDNS) zones игнорируют `rndc reload` для изменений в zone file; нужен `rndc freeze` → edit → `rndc reload` → `rndc thaw`. Проверка: `rndc zonestatus ZONE in VIEW`
-[lesson_nf_conntrack_table_full.md](lesson_nf_conntrack_table_full.md) — Загадочные drops на NAT-шлюзе при сохранении старых сессий: `dmesg | grep conntrack`. Default `nf_conntrack_max=8192` — мало, поднять до 524288 + `_buckets=131072`
-[lesson_telemt_middle_proxy_egress_match.md](lesson_telemt_middle_proxy_egress_match.md) — telemt middle-proxy ME pool init работает только если src_ip (NAT'd) совпадает с registered у @MTProxybot. Без ME — direct-DC, **в 4× больше памяти**. Решение: telemt на самом egress-узле или satellite через туннель к egress с тем же ad_tag
Когда я предложил пользователю несколько вариантов и он отвечает коротко («нет», «не хочу», «не надо»), **обязательно уточнить какой именно вариант он отверг и хочет ли он что-то ещё делать**.
**НЕ** интерпретировать «нет X» как «делай Y» (где Y — оставшийся вариант). По умолчанию короткое «нет» = «не делай ничего из обсуждаемого», а не «делай альтернативу».
## Why
2026-05-28: я предложил CT 691 три варианта решения media-проблемы:
- (1) IPsec/strongSwan CT 691 ↔ egw2 — новый прямой туннель
- (2) WireGuard — то же
- (3) Откатить policy на CT 691 (revert middle-proxy через egw2 в direct-DC)
- (4) Host-level GRE на enceladus
- (5) Убрать CT 691 из chat.eterfund.ru apex
Пользователь написал: «нет прямой не хочу».
Моя интерпретация: «нет варианта (1)/(2), значит делай (3)». Я выполнил откат: убрал systemd unit `route-via-egw2`, flush'нул rules и routes, отключил `use_middle_proxy`. Без подтверждения.
Реальный смысл пользователя: «не хочу делать прямой туннель» — то есть «не делай (1)/(2)», но без указания «делай (3)». Скорее всего: «не делай **ничего из этих радикальных вариантов**, обсудим дальше».
Пользователь обнаружил мои изменения: «Я не просил ничего менять вообще-то». Пришлось делать обратный откат через 5 минут.
## How to apply
- Короткие «нет/не хочу» в multi-choice контексте → задать вопрос: «Тогда какой вариант: A/B/C, или ничего пока не делать?»
- Действовать **только при явном «да» / «делай X»**, а не при отрицательных уточнениях
- Также применимо к: «не надо ad_tag менять», «не сейчас», «не сегодня» — всё это не означает «сделай что-то другое»
- Если есть сомнение, ВСЕГДА уточнить устно, до выполнения
- Особенно критично для **destructive операций** (удаление rules, отключение сервисов, restart telemt)
## Связано
-[[feedback-no-unauthorized-actions]] — НЕ самовольничать
- CLAUDE.md «ведёшь себя осмотрительно и спрашиваешь»
Доступ в LXC контейнеры — через **ssh внутрь CT** (`ssh root@<ct-ip>`), а не через `pct exec NNN` с PVE-хоста.
## Why
2026-05-29: я наткнулся на `Insecure $ENV{ENV}` taint-ошибку pct.pm на enceladus (вызвана `ENV=$HOME/.bashrc` в `/root/.bashrc`), пытался воркэраундить через `unset ENV; pct exec ...`, потом предложил фиксить host'овый bashrc. User сказал «тебе не нужен pct exec» — то есть в эти контейнеры можно (и нужно) заходить ssh напрямую, не делать крюк через PVE host.
## How to apply
- Для CT с известным IP — `ssh root@<ct-ip>` напрямую (предварительно проверить known_hosts актуальность)
-`pct exec` оставлять для случаев когда **нет** сети внутри CT или CT не запущен
- НЕ предлагать править host-level конфиги (типа `/root/.bashrc` на PVE-хосте) ради того чтобы `pct exec` работал — это не та проблема которую стоит решать
- Если есть выбор между `ssh root@enceladus 'pct exec 691 ...'` и `ssh root@91.232.225.43 ...` — выбирать второе
## Связано
-[[feedback-no-unauthorized-actions]]
- enceladus: `/root/.bashrc:20` экспортирует `ENV` → ломает `pct exec`, но это не наша проблема
Если `epm play <package>` падает (нет зависимостей, недостающие репозитории, GPG keys и т.п.) — **обязательно**:
1. Прочитать ошибку
2. Установить недостающие prerequisites (`epm ei p7zip tar xz`, `dnf install epel-release`, импорт GPG ключей и т.д.)
3. Повторить `epm play`
**НЕЛЬЗЯ** в ответ на ошибку:
- Скачать бинарь напрямую (curl/wget) с upstream releases
- Скопировать в `/opt/<pkg>/` руками
- Создать systemd unit вручную
## Why
User feedback 2026-05-29: «Очень плохо, что ты как сделал. Запомни никогда не обходить ошибки установки через epm play.»
Контекст: я предположил (ошибочно) что бинарь telemt на schat был скопирован вручную из-за того что `epm play telemt` ранее падал на AlmaLinux. Реально оказалось — `epm play` справился, бинарь правильный. Но **сам принцип** — что в случае ошибки нужно фиксить prereqs, а не обходить вручную — пользователь подтвердил как важный.
Последствия ручного обхода (гипотетические):
- Бинарь не отслеживается package manager'ом → не обновится `epm Upgrade`, не получит security fix
- Невозможно `rpm -V` проверить целостность
- Hosts диверджат между собой (одни через epm, другие вручную)
- При расследовании багов «почему ведёт себя по-разному» — съедается много времени
## How to apply
- Если `epm play X` падает: прочитать что ругается, поставить недостающее (`epm ei p7zip tar`, `dnf install epel-release`, импорт GPG keys), повторить
-**Никогда не скачивать бинарь вручную** в ответ на provisioning ошибку
- Если действительно нет другого пути (upstream not packaged) — **попросить сборщика пакетов** собрать ALT RPM ([alt-packaging-agents](https://gitlab.eterfund.ru/etersoft/alt-packaging-agents))
- Все хосты в одной роли должны иметь **тот же** package source
## Замечание про `epm play` на non-ALT
На AlmaLinux/Rocky/Debian `epm play` использует upstream-сборки (через prescription `/etc/eepm/play.d/<pkg>.sh`), а не ALT RPM. Поэтому бинарь может отличаться от ALT-сборки — это **нормально** и **не** считается «ручной установкой».
**Не включать BBR** на серверах. Использовать `cubic` (default ядра). Также не трогать `tcp_reordering` без явного запроса.
## Why
2026-05-29: я предложил BBR + reordering tweaks для оптимизации schat / egw2 / enceladus (telemt media transfer). После применения user сказал «ну и не надо bbr» — отказал. Эффект BBR на этих proxy-узлах не проявился, а вмешательство в kernel TCP стек без согласования — лишний риск.
## How to apply
- Не включать BBR без явного «да» от пользователя
- Если уже включил по своей инициативе — откатить (`sysctl -w net.ipv4.tcp_congestion_control=cubic`, очистить /etc/sysctl.d/99-tcp-tuning.conf)
- TCP buffer-related tweaks (`tcp_rmem`/`tcp_wmem`/`netdev_max_backlog`/`rmem_max`) считать дискуссионными — спрашивать
- Не путать с conntrack tuning (нужен на NAT-шлюзах — [[lesson-nf-conntrack-table-full]])
## Связано
-[[feedback-no-unauthorized-actions]]
-[[lesson-telemt-middle-proxy-egress-match]] — реальное решение media-проблемы было middle-proxy, не BBR
description:chat.eterfund.ru DNS-балансировка через .43 (telemt CT 691 как TLS-прокси) + beget 217.12.37.55; бэкенд переехал на enceladus; разобран инцидент ARP-конфликта с gyle CT 716
Postfix по `smtpd_sasl_path = smtpd` НЕ ходит в `/etc/sasl2/`, а в `/etc/postfix/sasl/`. Это конфигурируется при сборке cyrus-sasl2 (`SASL_PATH` env или `--with-configdir`). На ALT-mail это не дефолт, специально настроено.
**Why:** Я потерял ~30 минут в баге #19044 пытаясь поменять фильтр SMTP submission в `/etc/sasl2/smtpd.conf` — изменения никак не влияли, Postfix их не видит. В реальном `/etc/postfix/sasl/smtpd.conf` фильтр уже был `smtpauth = 1` с самого начала.
**How to apply:** Прежде чем менять SASL-конфиг под Postfix — всегда проверять `grep -rl smtpauth /etc/postfix /etc/sasl2`. В отличие от типичных гайдов в интернете, Postfix здесь читает не `/etc/sasl2/`.
Для отладки SASL: `sql_verbose: yes` + `log_level: 7` в нужном файле, потом смотреть `/var/log/mail/all`.
См. также [[lesson-cyrus-sasl-restart]] (про кэш sql_select в процессах), [[project-mail-password-hash-migration]].
На NAT-шлюзе (gateway с MASQUERADE/SNAT) неожиданно ломается связность:
-**Существующие SSH-сессии продолжают работать** (запись в conntrack создана давно, packets ходят)
-**Новые соединения дропаются**: `ssh: connect to host X port 22: Connection timed out`
-**Ping** к хосту 100% loss (новый ICMP-track не создаётся)
-**GRE/IPsec туннели** интермиттентно теряют пакеты — те же conntrack-проблемы
- В `dmesg`: `nf_conntrack: nf_conntrack: table full, dropping packet` + `net_ratelimit: N callbacks suppressed`
## Корень
`nf_conntrack_max` имеет очень маленький default на свежеустановленных системах (нередко **8192**). Активный NAT-router с прокси-трафиком (telemt, GRE-tunnels, etc.) забивает таблицу за минуты, особенно при churn-нагрузке (короткие коннекты → много TIME_WAIT).
vdska (NAT для divserver/gre.vdska.egw/IPsec) весь день казался «нестабильным» — то отвечает, то нет. Я ошибочно списал утреннее падение на свой `netplan apply` и потратил часы на ребут/восстановление. Реальная причина — `nf_conntrack_max=8192` забит до отказа (8188/8192 entries, 99.9% TCP NAT-потоков).
**Правило:** при загадочных «mixed» drops на NAT-шлюзе — `dmesg | grep conntrack`**первым делом**, до диагностики netplan/firewall/routes.
Если смена пароля в Roundcube «не работает» (молча валится, в `/var/log/roundcube/errors.log` — `DB Error: [1064] You have an error in your SQL syntax ... near '%c WHERE username = ...'`), смотри `/usr/share/roundcube/plugins/password/config.inc.php` на устаревшие плейсхолдеры.
**Why:** В Roundcube 1.2+ SQL-драйвер плагина `password` (`drivers/sql.php`) распознаёт только `%P/%O/%p/%o/%l/%d/%u/%h`. Старые `%c`, `%n`, `%q` (вместе с `password_crypt_hash` и `password_hash_algorithm`) — deprecated и просто уходят в SQL литералом. Конфиг при апгрейдах никто не обновляет, поэтому древние установки тихо ломаются.
**How to apply:** Минимальная правка:
-`%c` → `%P` в `password_query`
- Установить `password_algorithm = 'sha512-crypt'` (или `'sha256-crypt'`)
-`password_algorithm_prefix = ''` — пустая строка, иначе хэш в БД получит обёртку `{SHA512-CRYPT}...`, которую `crypt(plain, stored)` SASL'а не разберёт
- Закомментировать `password_crypt_hash`, `password_hash_algorithm` (для чистоты)
В CT 366 (roundcube.eterhost.ru, 10.20.30.66, доступ через `border`) файл не из rpm — создан вручную, безопасно править на месте. PHP-плагин логирует успешные смены в `/var/log/roundcube/password.log` (файл создаётся apache2; не путать с `password` без `.log`).
description:На mail.etersoft.ru sieve-каталоги НЕ ходят по spool-symlink etersoft.ru→office.etersoft.ru. Roundcube managesieve пишет в каталог по login-домену, а Cyrus при доставке читает по реальному пути spool. Логинить пользователя надо стабильно под одним доменом.
(не тестировал, но логически совпадает с тем как сделан symlink для spool)
**Why:** пока симлинка для sieve нет, надо либо строго один login-домен на пользователя, либо ручной симлинк на каждого. Лучше системно: симлинк всего sieve-каталога домена `e/etersoft.ru → o/office.etersoft.ru` — но он сейчас не пуст, потребует консолидации.
**How to apply:** при жалобах «правила в Roundcube не применяются» на mail.etersoft.ru первым делом проверять обе sieve-папки `domain/e/etersoft.ru/<X>/<USER>` и `domain/o/office.etersoft.ru/<X>/<USER>`, сравнивать `defaultbc` и даты. Активный скрипт — тот, что в `o/office.etersoft.ru` (туда смотрит доставка через spool-symlink).
## Связано
- 2026-05-13: удалил `e/etersoft.ru/l/lav` (вариант A) — lav логинится только как @office
- В логах: `All ME servers for DC failed at init dc=X alive=0 target_writers=N`
-`ME pool is not ready yet; retrying ... attempt=N retry_limit=unlimited`
- При этом TCP-сокеты к `:8888` ESTABLISHED видны (`ss -tn | grep :8888`)
-`RPC handshake OK` встречается в логах, но writers всё равно `0`
- Direct DC fallback работает (`upstream_connect_success_total` растёт)
Telegram явных reject не возвращает — handshakes завершаются "OK", но writers не активируются.
## Корень
Telegram ME-серверы **молчаливо отказываются** становиться "active writers" для прокси, если **`reflected_ip` upstream (= NAT'd src_ip как видит Telegram) НЕ совпадает с IP, зарегистрированным в @MTProxybot для этого ad_tag**.
Проверка через `tcpdump`/логи: смотри `local_addr_nat=X.X.X.X ... reflected_ip="X.X.X.X"` — это то, что Telegram видит. Должно совпадать с IP, который ты указал боту при `/newproxy`.
Это **НЕ** «лимит ad_tag на egress IP» (моя ранняя гипотеза). beget+schat работали несмотря на mismatch — потому что они оказались на egress IP hetzner (135.181.95.108), который не пересекался с их registered IPs. CT 691 с registered=.43 не работал — а реально шёл через hetzner.egw NAT.
## Эффект middle-proxy mode на ресурсы
Confirmed на 2026-05-28: при ~9000 клиентов
-**С работающим ME pool** (schat через egw2, 50 active writers): **1.0 GB RSS** ≈ 115 KB/client
2. Зарегистрировать **этот** IP в @MTProxybot `/newproxy IP port secret` → ad_tag
3. В config: `use_middle_proxy = true`, `ad_tag = "..."`, при необходимости `bind_addresses = ["<tunnel-src>"]`
4. Restart (`use_middle_proxy` не подхватывается hot-reload, требует restart)
5. Проверка: через 30-60s `curl :9090/metrics | grep me_writers_active_current` — должно быть `>0`
6. В логе должны быть `reflected_ip="<registered-IP>"` (совпадает с registered)
## Нюанс — `middle_proxy_nat_ip` (override STUN)
Telemt определяет `reflected_ip` (что сообщить Telegram'у) через **STUN-пробу к публичному STUN-серверу**. STUN-пакеты идут по **default route**, **НЕ** через policy routing tables.
Это критично если у тебя гибридный egress:
- Default route → IP X (видит STUN, отдаёт telemt'у как reflected_ip)
- Policy-routed traffic к Telegram CIDRs → через туннель → IP Y (реально видит Telegram)
X ≠ Y → ME init fails (Telegram видит src=Y, telemt уверяет что мы X, ad_tag регистрирован для Y).
Пример (CT 691):
- bind=91.232.225.43, default egress=.43 (нет NAT, публичный IP офиса)
-**MISMATCH → ME pool пуст** несмотря на правильную маршрутизацию
**Решение:** добавить в config `[general]`:
```toml
middle_proxy_nat_ip="178.105.209.27"
```
Telemt пропустит STUN и сообщит этот фиксированный IP. ME init проходит.
**Когда НЕ нужен:** если default route ВЕСЬ идёт через тот же туннель что и telegram-CIDR трафик (как schat — там gre3=default), STUN сам корректно определяет .27 — override не нужен.
Подтверждено 2026-05-28 на CT 691: с override `middle_proxy_nat_ip = "178.105.209.27"` ME pool активировался, память снизилась с 4297 → 1922 MB.
## Связано
-[[lesson-divserver-telemt-mtproxy]] — старая схема через GRE
- chat.eterfund.ru pool — IP в публичной round-robin записи
-[[reference-remote-ssh-access]] — доступ к remote endpoints
**Etersoft#19044** (NEW, P5, assigned lav@): mail.etersoft.ru — переход с DES crypt на SHA-512 в `accountuser.password` (mysql.auth.dmz.etersoft.ru, БД `mail`).
**Why:** DES crypt — 13 символов, только первые 8 байт пароля; ~21M c/s на builder64 john. Аудит 2026-04-28: 19 из 152 аккаунтов office имели слабые пароли.
- Бэкапы `.bak.20260520`/`.bak.20260521` рядом с оригиналами.
**Осталось:**
- Принудительный сброс 19 слабых паролей (список — комментарий #1 в баге, пароли в `builder64:~/tmp/claude/john.pot`). При смене они автоматически перейдут на `$6$`.
- Отдельная заметка: SASL-юзер `mail`@`%` в mysql имеет `GRANT ALL PRIVILEGES ON mail.*`, при этом креды в открытом виде в `/etc/sasl2/{Cyrus,smtpd}.conf`. Сузить до `SELECT`.
См. также [[lesson-roundcube-password-plugin-config]], [[lesson-cyrus-sasl-restart]].
Хост-relay в офисной подсети. Удалённые машины за NAT держат `ssh -R PORT:localhost:22 etersoft@anyssh.ru -N` — мы заходим обратной стороной как `ssh -p PORT user@anyssh.ru`.
## Активные обратные туннели (по состоянию 2026-05-28)
| Порт на anyssh.ru | Хост | Пользователь | Описание |
|---|---|---|---|
| 10337 | parentglobal (ALT Workstation K 11, Cosmote/Greece) | `etersoft@` | seedbox/ipsec gateway, IKEv2 к ikev2.gr.egw (.139) |
Полный список открытых портов: `ssh root@anyssh.ru 'ss -tlnp | grep sshd'`.
## Альтернатива — через IPsec tunnel
Если у хоста IPsec к нашему ikev2.*-CT — обычно достижим через jumphost:
- parentglobal: `ssh -J root@91.232.225.139 root@10.10.10.6` (10.10.10.4/30 ipsec0 на .139)
- rpi: **НЕ работает** — sshd внутри Docker container, не доступен на host через 10.10.10.6
## Известные проблемы
-**rpi**: чтобы `ssh -J root@91.232.225.140 root@10.10.10.6` работало — нужно либо поднять sshd host'а с bind на 10.10.10.6 (но этот IP внутри Docker netns), либо `docker run -p 10.10.10.6:22:22`, либо переместить IPsec из контейнера на host.
## Связано
-[[lesson-anyssh-ru-in-91232225]] — не маршрутизировать всю 91.232.225/24 через ipsec0 на удалённой машине, иначе порвём обратный SSH-туннель
-[[feedback-no-routes-on-remote-nat-peers]] — никаких маршрутов на офисные подсети на удалённой стороне tunnel'а
**Доступ:**`ssh time` (алиас в ~/.ssh/config, порт 6122, пользователь lav, потом sudo). Внутри это CT, hostname `gitlab.eterfund.ru.local`, IP 10.20.30.2 на venet0. Прямой `ssh root@time.office.etersoft.ru` НЕ работает — только через алиас `time`.
**База:** MySQL `eter_time` на `mysql.dmz.etersoft.ru`, таблица `eter_session`. Креды лежат в `/var/www/webapps/time/python/load/config.py`.
-**Обёртка:**`/var/www/webapps/time/python/load/load_sessions.sh` — берёт last за 3 дня
-**Конфиг:**`/var/www/webapps/time/python/load/config.py` — список `remote_hosts` (с каких машин забирать) и `allow_nx_hosts` (с каких ещё и NX-сессии)
-**Крон (timeuser):**`30 0,3,9-23 * * *` — каждые ~3 часа
**Важно:** если сессии с какой-то машины не приходят — проверить, есть ли её hostname в `remote_hosts` в `config.py`. Список редактируется руками (sudo). Бэкап делается рядом: `config.py.bak.YYYYMMDD`.
