Skip to content

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

Конфігураційний файл 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: 776M776G776M776b776d776e
  DBPass: 776S776e776M776L776a776N776U776a776G
  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}

Behaviour

Блок для редагування поведінки програми. AutoRefresh - контролює автоматичне оновлення статусу хостів. Незалежно від цієї настройки, в будь-який момент у програмі можна натиснути F5 щоб оновити статус (доступність) нод. Підсекція Logging дозволяє детально контролювати лог програми (в тому числі відключити повністю). УВАГА! Це контроль launcher.log котрий наразі в активній роботі, а не користувацього логу що виводиться на екран.

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 у Абхард додано обов'язкову авторизацію по токенах. Деталі роботи з токенами описано нижче.

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

При ініціалізації Абхарда лаунчер записує токени для всіх працівників у таблицю s_tokens. В полі service_url зберігається адреса Абхарда, за якою каси звертатимуться до нього в повсякденній роботі — тобто локальна адреса у мережі магазину. Оскільки лаунчер підключається через VPN, адреса у полі url конфігу хоста зазвичай є VPN-адресою, що для кас непридатна. Тому лаунчер підставляє в service_url адресу з поля "Підставити ІР", а не ту, за якою підключався сам.

Приклад: лаунчер підключився до Абхарда за VPN-адресою http://172.27.12.125:4601/, а в полі "Підставити ІР" вибрано 192.168.10.4 — в базу запишеться http://192.168.10.4:4601/. Саме цю адресу Casa використовуватиме для пошуку свого токена.

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

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

Логіка синхронізації: - Зчитує наявні токени з Абхарда через GET /api/admin/tokens і бере перший токен кожної ролі (administrator, worker, probationer). - Якщо токени ролей worker або probationer відсутні — створює їх на льоту через POST /api/admin/tokens. - Для кожного активного працівника з r_workers (і для запису -1 "Default cashdesk") вставляє або оновлює рядок у s_tokens за допомогою update or insert ... matching(user_id, service_name, token, service_url). Один токен призначається всім працівникам однієї ролі. - У service_url записується адреса з поля «Підставити ІР» (аналогічно до ініціалізації). - Якщо фактично додано нові записи, у лог виводиться відповідне повідомлення.

Наявні записи з іншими service_url не чіпаються і звісно повністю ігноруються записи для всіх інших сервісів.

Перенаправлення пристроїв (redirect)

Абхард підтримує тип пристрою redirect — коли фізичний пристрій (принтер, сканер, ваги або ПРРО) обслуговується іншим екземпляром Абхарда, а не тим, до якого підключена каса. Такий пристрій у конфігурації Абхарда матиме subtype: redirect і два додаткових поля: redirect_url (базова адреса віддаленого Абхарда) та redirect_name (ім'я пристрою на тому Абхарді).

Лаунчер розпізнає redirect-пристрої автоматично і прозоро перенаправляє запити до них на відповідний екземпляр Абхарда. Токен для віддаленого екземпляра береться з поля AbhardToken запису Connections або Workstations у launcher.yaml, для якого AbhardURL збігається з redirect_url.

Приклад: є магазин де одна каса (192.168.10.4) обслуговує власний Абхард, а друга (192.168.10.5) не має свого принтера і перенаправляє друк на першу. В launcher.yaml для цього потрібно мати токени обох екземплярів:

Connections:
- Name: Магазин (сервер)
  IP: 172.27.12.125
  DBAlias: shop1
  AbhardURL: http://172.27.12.125:4601/
  AbhardToken: admin-token-for-vpn-instance
  Workstations:
  - Name: Каса 1
    IP: 192.168.10.4
    AbhardURL: http://172.27.12.125:4601/
    AbhardToken: admin-token-for-vpn-instance
  - Name: Каса 2
    IP: 192.168.10.5
    AbhardURL: http://192.168.10.4:4601/
    AbhardToken: admin-token-for-local-instance

Для другої каси AbhardURL вказує на локальну адресу першої — саме туди redirect_url у конфігурації Абхарда другої каси повинен вказувати. Якщо токен для redirect_url не знайдено в жодному записі дерева підключень, лаунчер виконає запит без авторизації і отримає 401.