Конфігурація

2026-07-202026-09-18

Конфігураційний файл launcher.yaml має бути коректним YAML документом. Найпростіший спосіб перевірити конфіг на відсутність помилок - командою yamllint launcher.yaml у консолі Linux або на сайті https://www.yamllint.com/. Інші деталі про конфігурування програми наведено у файлі [config.md].

Connections

Записи у цьому блоці мають три обо'язкових поля - Name, IP, та DBAlias. Додатково можна вказувати DBUser, DBPass, та Workstations. DBUser i DBPass мають бути закодованими. У Workstations може бути перелік робочих станцій що працюють з відповідним сервером. УВАГА! Ім'я користувача і пароль бази даних саме кодуються а не шифруються. Різниця в тому, що розкодувати закодований текст дуже просто; він не призначений для приховування інформації. Я просто на даному етапі не бачу необхідності у витрачанні часу і зусиль для повноцінного шифрування.

Приклад конфігурації

Connections:
- Name: Local test 1
  IP: 192.168.50.123
  DBAlias: localtest1
  DBUser: AtFrRwlWl7xf
  DBPass: HyArGd5FS8go
  AnydeskID: 123456798
  AnydeskPassword: abacussupport
  Workstations:
  - IP: 192.168.50.201
    Name: Cashdesk
  - IP: 192.168.50.202
    Name: Manager

Додаткові змінні

Починаючи з версії 3.0.6 у блоках Connections та Workstations можна вводити будь-які інші додаткові змінні. Ці змінні пізніше можна використовувати у AppButtons.

Поля AbhardURL та AbhardToken мають особливий сенс для роботи з Абхардом — детальніше у відповідному розділі нижче.

AppButtons

Кожен запис складається з двох обов'язкових полів - Caption та Command. Caption - це те що буде виводитись на відповідній кнопці, а Command - те що буде запускатися. В Command можна підставляти IP адресу обраного вузла а також будь-яку змінну визначену користувачем.

Приклад конфігурації

- Caption: ping
  Command: ping -t {IP}
- Caption: AnyDesk
  Command: anydesk -ip {IP} -id {AnydeskID} -password {AnydeskPassword}

Крім того, є два необов'язкових поля.

Capture: true — команда виконується синхронно, лаунчер чекає її завершення і виводить весь її вивід у лог. Без цього поля (типово false) команда просто запускається і живе своїм життям, навіть після закриття лаунчера.

Refresh: true — після завершення команди лаунчер перечитує дані з бази: версію та білд, перелік профілів у полі "Підставити ІР" та перелік версій файлів. Потрібне для команд, що змінюють базу — інакше довелось би перемикатись на інший вузол і назад, щоб побачити зміни. Працює лише разом з Capture: true, бо тільки тоді відомо, що команда вже відпрацювала; в іншому разі поле ігнорується із попередженням у лозі.

- Caption: "Apply preset"
  Capture: true
  Refresh: true
  Command: '"C:\Program Files\Firebird\Firebird_3_0\isql.exe" -i preset.sql -user {DBUser} -password {DBPass} {IP}:{DBAlias}'

Behaviour

Блок для редагування поведінки програми. AutoRefresh - контролює автоматичне оновлення статусу хостів. Незалежно від цієї настройки, в будь-який момент у програмі можна натиснути F5 щоб оновити статус (доступність) нод.

Position

Зберігає координати та стан вікна програми при зупинці і відновлює їх при запуску.

Locations

Тут зберігаються шляхи до різних каталогів що потрібні під час роботи програми. УВАГА! Каталог Backup знаходиться на сервері і лаунчер - якщо включена відповідна галочка - буде робити резервну копію бази на той самий сервер де знаходиться база (якщо firebird має права доступу туди). Можливість робити віддалений бекап засобами клієнтської бібліотеки появилась відносно недавно і у лаунчері наразі не реалізована.

Логи

З моменту переходу на кольоровий вивід логу роботи програми, лог зберігається у форматі RTF. У консолі Linux його зручно переглядати командою catdoc -w logfile.log; графічні середовища мають підтримувати формат RTF з коробки але залежно від налаштувань системи можливо доведеться перейменувати файл з logfile.log у logfile.rtf.

Деталі роботи з Абхардом

Починаючи з версії 3.0.0.131 у лаунчері з'явилась можливість відправляти команди абхарду. При цьому ланучер під'єднується до того абхарда, котрий описаний для ІР що обрано у полі "Підставити ІР", тобто його поведінка в цьому плані аналогічна до інших кнопок запуску програм.

Якщо для вибраної ІР адреси у базі даних вказано адреса абхарда '127.0.0.1', тоді лаунчер підставить замість замість неї адресу відповідного сервера. Тобто, якщо вибрати клієнта "Тестовийклієнт" з VPN адресою '172.27.0.123' і у базі даних цього клієнта буде зареєстровано лише один хост '127.0.0.1' для котрого ІР адреса абхарда у полі BLOCK_CONTENT вказана також як '127.0.0.1', тоді лаунчер буде під'єднуватися до цього абхарда за VPN адресою. Якщо адреса у полі BLOCK_CONTENT буде інша, тоді швидше за все нічого не вийде. Справа в тому що якщо, наприклад, у магазині "Світ книг" Абхард працює на ІР 192.168.0.15 і інші каси під'єднуються до нього по локалці, а Лаунчер запущений у зовсім іншому місці з зовсім іншою мережею де навіть немає підмережі 192.168.0.0/24 то для того щоб можна було під'єднатись - умовно - з Мишина до Світу книг, потрібно мати правильно налаштовану маршрутизацію між мережами що швидше за все ніхто робити не буде.

Починаючи з версії 3.2.0 у Абхард додано обов'язкову авторизацію по токенах. Деталі роботи з токенами описано нижче.

Ініціалізація та збереження токенів

При ініціалізації Абхарда лаунчер видає три токени — по одному на роль (адміністратор, працівник, стажист) — і зберігає їх під мнемонічними кодами, що містять назву служби, назву профілю та роль. Каса підбирає потрібний токен за роллю працівника, який зараз працює.

Адреса Абхарда в токені більше не зберігається. Тому не має значення, що лаунчер підключався через VPN, а каси працюють у локальній мережі: обидві адреси можна перелічити в профілі, і Каса, Склад чи Барком візьмуть ту з них, яка для них доступна. Сам лаунчер перебору не робить — він бере перший запис списку і, якщо там 127.0.0.1, підставляє адресу обраного вузла. Тож першою в списку має стояти адреса для кас, а не для лаунчера. Поле «Підставити ІР» тепер лише вибирає профіль.

Те саме роблять і для решти служб, але з боку "Складу": у редакторі конфігурації кнопка активації служб видає токени для abhard, abrest і abasyn для вибраного профілю за одну дію і одразу ж прописує їхні коди в сам профіль.

Приклад: магазин, менеджер і віддалений адміністратор

У магазині мережа 192.168.1.0/24: сервер 192.168.1.100 з abasyn і abrest та чотири каси, на кожній свій абхард. Адміністратор працює з дому через VPN — сервер видно як 172.27.10.11, каси як 172.27.10.12-15. Удома в адміністратора теж 192.168.1.0/24, тож адреса 192.168.1.100 для нього означає власний комп'ютер, а не сервер магазину. Менеджер з ноутбуком буває і в магазині, і вдома. Кожній ролі потрібен свій профіль.

Каси — профілі kasa1...kasa4:

abhard:
  enabled: true
  urls:
    - http://127.0.0.1:4601/
abasyn:
  enabled: true
  urls:
    - http://192.168.1.100:4602/
abrest:
  enabled: true
  urls:
    - http://192.168.1.100:4603/

Всі параметри окрім адрес для простоти пропущено.

Менеджер — профіль manager:

abhard:
  enabled: false
abasyn:
  enabled: true
  urls:
    - http://192.168.1.100:4602/
    - http://172.27.10.11:4602/
abrest:
  enabled: true
  urls:
    - http://192.168.1.100:4603/
    - http://172.27.10.11:4603/

Локальна адреса стоїть першою: при запуску у магазині склад бачить абасин/абрест на локальному сервері і починає з ними працювати. При запуску по VPN адреси на ІР 192.168.1.100 або взагалі будуть недоступні або навіть якщо випадково така адреса і буде в локальній мережі з якої підключається менеджер, там навряд чи буде запущено abasyn/abrest. Тому після таймауту склад підключається до другої у списку адреси і працює з нею.

Адміністратор — профіль admin:

abhard:
  enabled: false
abasyn:
  enabled: true
  urls:
    - http://172.27.10.11:4602/
abrest:
  enabled: true
  urls:
    - http://172.27.10.11:4603/

Адреси 192.168.1.100 тут немає взагалі: адміністратор під'єднуєтсья лише по VPN. Профіль admin (чи подібний) має існувати в базі кожного клієнта, до якого адміністратор під'єднується.

Лаунчер і Склад в адміністратора

Позначка «Підставити ІР» керує двома різними речами, і для цих двох дій її ставлять по-різному.

Ініціалізувати абхард каси — позначку поставити, вибрати kasa1. Лаунчер візьме 127.0.0.1 з профілю каси й підставить адресу обраного вузла.
Запустити Склад — позначку зняти. Тоді Склад візьме профіль з власного settings.yaml адміністратора, тобто admin, і працюватиме через VPN.

Якщо позначку залишити, Склад успадкує профіль каси: шукатиме abasyn і abrest за 192.168.1.100 у домашній мережі адміністратора, а абхард — на власному комп'ютері. Обладнання каси при цьому все одно не з'явиться, бо підстановку адреси робить лише лаунчер.

Панель стану служб у самому лаунчері бере адреси з першого профілю в базі, а не з профілю адміністратора. З дому вона майже завжди покаже abasyn і abrest недоступними, хоча зі Складу вони працюють — це не несправність.

Тестове середовище (is_testing)

Якщо у блоці Connections вказано is_testing: true, лаунчер після кожного успішного підключення до Абхарда автоматично синхронізує токени між Абхардом і базою даних. Це спрощує роботу з тестовими середовищами, де базу відновлено з резервної копії і збережені токени вже не відповідають токенам у Абхарді, розгорнутому в цьому середовищі.

Логіка синхронізації: - Зчитує наявні токени з Абхарда через GET /api/admin/tokens і бере перший токен кожної ролі (administrator, worker, probationer). - Якщо токени ролей worker або probationer відсутні — створює їх на льоту через POST /api/admin/tokens. - Зберігає по одному токену на роль під кодом відповідного профілю. Раніше збережений токен тієї ж ролі позначається як застарілий, тож чинним завжди лишається останній. - Якщо фактично додано нові записи, у лог виводиться відповідне повідомлення.

Токени інших профілів і всіх інших служб не чіпаються.