byrsapty
ed8fc831bf
Один коміт, а не десяток тематичних, свідомо: теми переплетені в
спільних файлах (store.go, docker-compose.yml, deploy/README.md), і
розділити їх можна було б лише індексуванням шматків. Коміти, які не
збираються, гірші за один великий — тим паче що це рівно той стан, який
перевірявся разом.
ЩО ПРАЦЮЄ НА СТЕНДІ Й ПЕРЕВІРЕНО ТАМ
0058 подієві алерти: syslog, ncm, compliance спрацьовують у мить
події; правило з нереалізованим джерелом більше не зберігається
мовчки
0059 snmp.walk і прототипи шаблонів — таблиці з динамічним індексом
описуються шаблоном, а не Go
0060 відкат конфігу: план як різниця, маскування паролів із підписом
плану, обов'язковий контрольний збір, verifying при обриві
0061 кнопки Telegram: довге опитування, авторизація не з callback_data
0062 аудит і архів хостів; тест на AST, що падає на ключі без назви
0063 RLS: три ролі, окремий пул для фонових тактів
0064 строки зберігання даних і сторінка сховища
0065 приймач SNMP-трапів; перевірено справжніми пакетами по дроту,
переклад v1→v2 за RFC 3584 дає правильний OID
0066 ескалації сповіщень
0067 алерт про вичерпання диска
0068 поля заливки конфігу переїхали в каталог профілів
Плюс: 137 тестів вебу з нуля (їх не було взагалі), одинадцять справжніх
вад, знайдених ними й виправлених, і виправлення двох інтеграційних
тестів grpcapi, які мовчки пропускались півтора року.
ЩО ЩЕ НЕ ЗАПУСКАЛОСЬ
netpulse установник: одна команда замість 18 змінних і
593 рядків інструкції
RLS з першого запуску нова інсталяція під політиками одразу;
RLS-EXISTING-INSTALL.md лишається тільки для
старих інсталяцій
.forgejo + CI раннер не зареєстрований
Ці три перевірені компіляцією й міркуванням, але не виконанням.
ГОЛОВНИЙ ВИСНОВОК ДВОХ СЕСІЙ
Зелена перевірка доводить рівно те, що вона перевіряє. Тест ізоляції RLS
був правильний і зелений — і пропустив зламаний вхід, бо перевіряв «чи
не видно чужого», коли зламалось «чи видно своє». Інтеграційні тести
grpcapi були зелені, бо не виконувались. Схема, довідник і протокол
описували те, чого в коді не існувало, і виглядало це як готове.
Тому в кожному завданні цих сесій стояла вимога назвати НЕПОКРИТЕ, а
чотири задачі закінчились не можливістю, а відмовою: правило з
нереалізованим джерелом не зберігається, профіль без команд заливки
каже про це замість мовчазної кнопки, міграція RLS валить сама себе на
таблиці без політики, тест словника аудиту падає на ключі без назви.
Подробиці — HISTORY.md, розділи за 26 і 27 серпня.
132 lines
9 KiB
SQL
132 lines
9 KiB
SQL
-- =====================================================================
|
||
-- NetPulse :: поля заливки конфігу для вбудованих профілів
|
||
--
|
||
-- ФАЙЛ ЗГЕНЕРОВАНО. Джерело — db/profiles/catalog.json (блоки
|
||
-- `apply` у профілях і секція `apply_external`). Правити тут
|
||
-- безглуздо: наступна збірка перезапише.
|
||
--
|
||
-- ЦЕ НЕ МІГРАЦІЯ і сама вона нікуди не накочується. Номер міграції
|
||
-- призначає людина, а не генератор: над одним каталогом номерів
|
||
-- працюють паралельні гілки, і вигаданий номер зіткнувся б із чужим.
|
||
-- Щоб зміни доїхали до бази, скопіюй цей текст у нову міграцію.
|
||
--
|
||
-- Чому не в 0014, звідки беруться самі профілі: колонки apply_*
|
||
-- заводить 0060, тобто ПІЗНІШЕ, — вставка в 0014 не може згадати
|
||
-- колонку, якої ще немає. І 0014 уже накочена на стендах, а runner
|
||
-- звіряє sha256 застосованих файлів: зміна її тексту зупинила б
|
||
-- накат усім.
|
||
--
|
||
-- Повторний накат безпечний: UPDATE задає всі поля явно, тож
|
||
-- результат залежить лише від каталогу, а не від того, що вже
|
||
-- стояло в рядку.
|
||
-- =====================================================================
|
||
|
||
-- Cisco IOS. Класика, з якої списані всі інші: `configure terminal`,
|
||
-- заперечення через `no `, вихід із контексту `exit`, збереження
|
||
-- `write memory` (а не `copy run start`, який на частині версій
|
||
-- перепитує ім'я файлу й підвисає на очікуванні Enter).
|
||
UPDATE ncm.profiles SET
|
||
apply_enter = '["configure terminal"]'::jsonb,
|
||
apply_exit = '["end"]'::jsonb,
|
||
apply_commit = 'write memory',
|
||
apply_negate = 'no ',
|
||
apply_block_exit = 'exit',
|
||
apply_supported = true,
|
||
apply_note = NULL
|
||
WHERE tenant_id IS NULL AND key = 'cisco-ios';
|
||
|
||
-- Juniper JUNOS — теж свідомо без відкату, і теж через формат архіву.
|
||
--
|
||
-- Профіль знімає `show configuration | display omit`, тобто ієрархію у
|
||
-- фігурних дужках. Це не набір команд: віддати такий текст рядками в
|
||
-- CLI неможливо. Правильний шлях на JUNOS — `load override terminal` із
|
||
-- вставкою всього файлу, а він не вкладається в модель «команда →
|
||
-- запрошення → наступна команда», на якій побудований увесь наш CLI.
|
||
--
|
||
-- Альтернатива існує: профіль, що знімає `show configuration |
|
||
-- display set`, дав би рядки `set …` із заперечником `delete `. Це
|
||
-- окрема робота — інший профіль збору й переливання архіву, — і робити
|
||
-- її мовчки, підмінивши формат історії, не можна.
|
||
UPDATE ncm.profiles SET
|
||
apply_enter = '[]'::jsonb,
|
||
apply_exit = '[]'::jsonb,
|
||
apply_commit = NULL,
|
||
apply_negate = NULL,
|
||
apply_block_exit = 'exit',
|
||
apply_supported = false,
|
||
apply_note = 'JUNOS зберігається ієрархією у фігурних дужках — це не набір команд. Для відкату потрібен профіль зі збором «show configuration | display set» (рядки set …, заперечення delete …); наявний архів у такому вигляді немає.'
|
||
WHERE tenant_id IS NULL AND key = 'juniper-junos';
|
||
|
||
-- MikroTik RouterOS — свідомо БЕЗ відкату, і причина не в бракові часу.
|
||
--
|
||
-- Вивід `export` виглядає як набір команд, але команди в ньому —
|
||
-- `add …`. Повторне виконання `add` не повертає рядок на місце, а
|
||
-- створює ДРУГИЙ такий самий запис: другу адресу на інтерфейсі, друге
|
||
-- правило фаєрвола. Прибирання ж робиться через `remove [find …]` —
|
||
-- тобто через пошук за критерієм, якого в рядку експорту немає.
|
||
--
|
||
-- Тобто механічний відкат на RouterOS не «поки не зроблений», а дає
|
||
-- гарантовано хибний результат. Правильний шлях — `/system backup` або
|
||
-- `/import` файлом, і це інша функція з іншим транспортом.
|
||
UPDATE ncm.profiles SET
|
||
apply_enter = '[]'::jsonb,
|
||
apply_exit = '[]'::jsonb,
|
||
apply_commit = NULL,
|
||
apply_negate = NULL,
|
||
apply_block_exit = 'exit',
|
||
apply_supported = false,
|
||
apply_note = 'RouterOS: рядки експорту — це add, і повторне виконання не повертає запис, а створює дубль; прибирання потребує remove [find …]. Автоматичний відкат тут дав би гарантовано хибний результат — потрібне відновлення з /system backup або /import файлом.'
|
||
WHERE tenant_id IS NULL AND key = 'mikrotik-routeros';
|
||
|
||
-- ZTE ZXR10 — CLI родини Cisco з тим самим `configure terminal`/`no `.
|
||
-- Збереження коротше: `write`.
|
||
--
|
||
-- Родина в каталозі стоїть huawei — але вона описує поведінку
|
||
-- консолі (пейджер, запрошення), а не синтаксис конфігурації.
|
||
-- Саме тому заливка задана профілем, а не родиною: успадкувати
|
||
-- її від huawei означало б відправити на пристрій чужі команди.
|
||
UPDATE ncm.profiles SET
|
||
apply_enter = '["configure terminal"]'::jsonb,
|
||
apply_exit = '["end"]'::jsonb,
|
||
apply_commit = 'write',
|
||
apply_negate = 'no ',
|
||
apply_block_exit = 'exit',
|
||
apply_supported = true,
|
||
apply_note = NULL
|
||
WHERE tenant_id IS NULL AND key = 'zte-zxr10';
|
||
|
||
-- ZTE ZXAN (OLT C300/C320/C600) — той самий CLI, що й ZXR10. Профіль
|
||
-- заведено окремо в 0028 через запрошення, а не через синтаксис.
|
||
UPDATE ncm.profiles SET
|
||
apply_enter = '["configure terminal"]'::jsonb,
|
||
apply_exit = '["end"]'::jsonb,
|
||
apply_commit = 'write',
|
||
apply_negate = 'no ',
|
||
apply_block_exit = 'exit',
|
||
apply_supported = true,
|
||
apply_note = NULL
|
||
WHERE tenant_id IS NULL AND key = 'zte-zxan';
|
||
|
||
-- D-Link DES/DGS (профіль dlink-me, спільний для xStack і Smart /ME —
|
||
-- див. 0043). Тут два свідомі відступи від класики.
|
||
--
|
||
-- Режиму конфігурації немає: команди виконуються просто із запрошення,
|
||
-- тому apply_enter і apply_exit порожні, а вкладених контекстів не
|
||
-- буває — кожен рядок конфігу самодостатній (`create vlan v10 tag 10`).
|
||
--
|
||
-- Заперечення немає ЗОВСІМ, і це не пропуск. У D-Link немає універсального
|
||
-- `no`: створене прибирається `delete`, налаштоване переписується
|
||
-- `config`, увімкнене вимикається `disable`. Вивести з рядка конфігу
|
||
-- потрібне дієслово автоматично неможливо — `create vlan v10 tag 10`
|
||
-- прибирається як `delete vlan v10`, і жодне механічне правило цього не
|
||
-- дасть. Тому рядки на прибирання йдуть людині переліком, а система
|
||
-- заливає лише те, що додає й переписує.
|
||
UPDATE ncm.profiles SET
|
||
apply_enter = '[]'::jsonb,
|
||
apply_exit = '[]'::jsonb,
|
||
apply_commit = 'save',
|
||
apply_negate = NULL,
|
||
apply_block_exit = '',
|
||
apply_supported = true,
|
||
apply_note = 'D-Link не має універсального заперечення рядка: створене прибирається delete, налаштоване переписується config. Тому зайві рядки система показує переліком «прибрати вручну», а заливає лише додане й змінене.'
|
||
WHERE tenant_id IS NULL AND key = 'dlink-me';
|