Netpulse_SasS/db/profiles

Каталог команд роботи з конфігом

catalog.json — джерело істини про те, як зняти конфіг із кожної підтримуваної платформи і як залити його назад. 148 платформ, 67 вендорів.

SQL із каталогу породжується, а не правиться руками: два описи одного й того самого розійшлися б із першою ж правкою, і невідомо було б, який справжній.

python build.py            # перезібрати згенероване
python build.py --check    # звірити, чи воно актуальне

Генератор пише два файли, і це не примха:

файл	що несе
server/migrations/0014_ncm_profiles.sql	самі профілі: команди збору
apply.generated.sql	поля заливки (apply_*) для наявних профілів

apply.generated.sql — не міграція. Колонки apply_* заводить міграція 0060, тобто пізніше за 0014: вставка в 0014 не може згадати колонку, якої на той момент ще немає. До того ж 0014 уже накочена на стендах, а netpulse-migrate звіряє sha256 застосованих файлів і зупиняє накат на розбіжності — зміна тексту 0014 зупинила б оновлення всім. Тому поля заливки їдуть окремо: скопіюй apply.generated.sql у нову міграцію під номером, який призначила людина. Номер генератор не вигадує свідомо — над одним каталогом номерів працюють паралельні гілки.

Будова

{
  "families": {
    "cisco": {
      "pager": "terminal length 0",       // чим вимкнути посторінковий вивід
      "prompt": "[>#]\\s*$",              // за чим ловити кінець виводу
      "enable_required": true,            // чи потрібен привілейований режим
      "scrub": ["^Building configuration"],  // вирізати з diff — шум, що змінюється щоразу
      "redact": ["(password|secret) \\S+"]   // замаскувати перед записом у Git
    }
  },
  "vendor_family": { "bdcom": "cisco" },   // чий CLI успадкував вендор
  "profiles": [
    {
      "key": "cisco-ios",
      "name": "Cisco IOS",
      "vendor": "cisco",
      "family": "cisco",
      "config": "show running-config",      // головна команда
      "startup": "show startup-config",     // необовʼязково
      "prepare": ["undo terminal monitor"], // необовʼязково: підготовка консолі
      "strip_lines": 3,                     // скільки службових рядків відкинути
      "alternatives": ["show config current_config"],  // для інших моделей родини
      "apply": {                            // як ЗАЛИВАТИ конфіг; без блоку — заливка вимкнена
        "comment": ["чому саме так"],       // їде коментарем над UPDATE
        "enter": ["configure terminal"],    // чим увійти в режим конфігурації
        "exit": ["end"],                    // чим із нього вийти
        "commit": "write memory",           // чим зберегти, щоб пережило перезавантаження
        "negate": "no ",                    // префікс заперечення рядка; null — родина не вміє
        "block_exit": "exit",               // чим вийти з вкладеного контексту
        "supported": true,                  // чи є заливка взагалі
        "note": "…"                         // що сказати людині, коли заливки немає
      }
    }
  ],
  "apply_external": {                        // заливка для профілів, заведених
    "zte-zxan": { "…": "…" }                 // не каталогом, а руками (0028, 0034/0043)
  }
}

Як додати платформу

1. Додай запис у profiles. Мінімум — key, name, vendor, family, config.
2. Якщо CLI не схожий на жодну наявну родину — заведи нову у families.
3. Якщо заливка на цій платформі перевірена — додай блок apply. Не перевірена — не додавай: див. «Про заливку».
4. python build.py.
5. Перенеси нові рядки у нову міграцію. 0014 чіпати не можна: вона вже накочена, а runner звіряє sha256 і зупиниться на зміненому файлі. Так уже робили для zte-zxan (0028) і dlink-me (0034, 0043). INSERT іде з ON CONFLICT DO NOTHING, UPDATE задає всі поля явно — повторний накат безпечний в обох випадках.

Про заливку

Блок apply описує, як віддати конфіг пристрою назад: увійти в режим конфігурації, прибрати зайвий рядок, зберегти. Живе він у каталозі поруч із командами збору, а не в разовій міграції, з однієї причини: профіль, доданий без полів заливки, виглядав би робочим, а відкат для нього мовчки не спрацював би — і побачили б це рівно тоді, коли відкат знадобився.

Заливка задається профілем, а не родиною. Родина описує поведінку консолі (пейджер, запрошення), і збігається вона не з синтаксисом конфігурації: zte-zxr10 стоїть у родині huawei через запрошення, а конфігурується як Cisco. Успадкувати заливку від родини означало б відправити на пристрій чужі команди.

Профіль без блоку apply лишається без заливки, і це нормально. apply_supported = false — чесна відповідь «не вміємо», з якої інтерфейс робить вимкнену кнопку з поясненням. Вигадана команда гірша за відсутню: вона пише на живе залізо. Тому коли заливки немає з розібраної причини — заповнюй note: порожнє поле перетворює свідоме рішення на схоже на недогляд (див. mikrotik-routeros, juniper-junos).

Родини

Родина описує поведінку консолі, а не вендора: bdcom, arista, brocade та ще з десяток говорять діалектом Cisco, h3c і 3com — діалектом Huawei. Тримати це один раз на родину, а не копіювати в кожен профіль, — різниця між правкою в одному місці й правкою в сорока.

Родина generic — запасний варіант: промпт [>#]\s*$, без вимкнення пейджера, з обережним маскуванням паролів і community.

Про промпти

prompt і pager задані за родиною й перевіряються на живому залізі. Одна родина покриває десятки платформ, і дрібні відхилення трапляються: прошивка може давати інший символ запрошення або не розуміти команду вимкнення пейджера. Команди збору конфігу натомість специфічні для платформи й узяті точно.

Чому не в БД

Каталог — код, а не дані клієнта: він однаковий для всіх інсталяцій, має переглядатись у code review і їхати разом із релізом. Тенант може завести власний профіль (ncm.profiles із заповненим tenant_id) — вбудовані при цьому лишаються недоторканими.