conf: сохранённый конфиг пиннит дефолты старой версии — изменение дефолта по безопасности (CROWDSEC_STRICT 0→1 в v4.0) молча не доезжает до настроенных нод #34

Что происходит

Сохранённый конфиг (/etc/node-accelerator/{optimize,protect}.conf) навсегда пиннит дефолты той версии, при которой нода настраивалась. Когда новая мажорная меняет дефолт по соображениям безопасности, на уже настроенных нодах он молча не применяется — ни при ре-ране, ни при апгрейде тулкита, и na-diagnose о расхождении не сообщает.

Самый заметный случай — CROWDSEC_STRICT, ужесточённый в v4.0 (0 → 1, запрет curl|bash-фоллбэка, который атакующий может форсировать, сделав репозиторий недоступным).

Наблюдалось

2026-09-01, флот из 8 хостов (7 нод + панель), все обновлены до v4.0.1 ре-раном install.sh optimize:

$ grep CROWDSEC_STRICT /etc/node-accelerator/protect.conf
cdn1 : "${CROWDSEC_STRICT:=0}"      # ← v3-дефолт, пиннится с июля
fr1  : "${CROWDSEC_STRICT:=0}"
nl1  : "${CROWDSEC_STRICT:=0}"
ru1  : "${CROWDSEC_STRICT:=0}"
us1  : "${CROWDSEC_STRICT:=0}"
it1  : "${CROWDSEC_STRICT:=1}"      # задавали руками
panel: "${CROWDSEC_STRICT:=1}"

Пять хостов из восьми продолжают работать со старым, осознанно ослабленным значением, при том что оператор считает флот «переведённым на v4». Узнать об этом можно только чтением конфигов на каждом хосте — ни na-diagnose, ни вывод optimize/protect расхождения не показывают.

Корень

scripts/lib/common.sh:303 load_conf подхватывает сохранённые значения идиомой : "${K:=v}" ДО того, как модуль применит свой дефолт (protect.sh:103 CROWDSEC_STRICT="${CROWDSEC_STRICT:-1}"). Идиома идемпотентности («ENV при ре-ране переопределяет») в обратную сторону работает как заморозка: встроенный дефолт не может выиграть у сохранённого никогда. Это правильно для того, что оператор задал осознанно (WHITELIST, NODE_PORT, FW_MODE), и неправильно для того, что он никогда не трогал.

Предлагаемый фикс

Различать «оператор задал» и «записан тогдашний дефолт». Варианты, от дешёвого к полному:

1. Отчёт о расхождении. При старте модуля сравнить сохранённые значения со встроенными дефолтами и напечатать warn по каждому расхождению, отметив ключи с изменившимся в новой версии дефолтом: CROWDSEC_STRICT=0 (сохранён при v3.9; дефолт v4 = 1 — усиление безопасности; оставить: CROWDSEC_STRICT=0, принять новый: CROWDSEC_STRICT=1). Плюс сенсор в diagnose — «конфиг ноды пиннит N устаревших дефолтов».
2. Версия в конфиге. Писать в шапку NA_CONF_VERSION, и при её отставании прогонять список «дефолтов, изменённых между версиями» (небольшая таблица в common.sh), применяя изменения, которых оператор не задавал явно.
3. Разделить файлы: *.conf (что задал оператор — только ключи, пришедшие из ENV) и *.defaults (снимок дефолтов, перезаписывается каждой версией). Тогда «оператор задал» становится машиночитаемым, а не угадываемым.

Минимум — пункт 1: он ничего не ломает и снимает главную проблему («изменение дефолта по безопасности не доезжает до флота и об этом никто не узнаёт»).