Не знаю з чим порівняти пропозицію. Можливо з котом? Начебто можна і без нього, але з ним трохи краще. Особливо, якщо він працює))
Постановка проблеми:
- Хочу налаштовувати SIP телефони швидко, просто, безпечно. При установці телефону і особливо при його переконфігуруванні.
- Багато вендори мають свої формати конфігів, свої утиліти для генерації конфігів, свої способи захисту конфігів. А розбиратися з кожним не дуже хочеться.
- Багато рішень щодо provisioning, а) орієнтовані одного вендора чи одну телефонну систему, б) досить громіздко реалізуються, купа скриптів, параметрів, бр-р…
За пунктом 3 зроблю коментар, що є відмінні системи. , , , де у відкритому доступі є шаблони для різних вендорів. Є комерційні рішення, де також можна налаштувати у модулі провіжну роботу телефонів різних виробників, наприклад, АТС Yeastar.
На Хабре також повно рецептів як налаштувати апарати різних вендорів: , . Але, як кажуть, у всіх систем є фатальний недолік. Тож зробимо свій велосипед.
свій формат
Як говориться в xkcd, не хочеш розбиратися з 14 форматами. . Тому ми використовуємо загальні установки для будь-якого телефону і зробимо свій json-формат конфіга.
Приблизно такий:
{
"key": "sdgjdeu9443908",
"token": "590sfdsf8u984",
"model": "gxp1620",
"vendor": "grandstream",
"mac": "001565113af8",
"timezone_offset": "GMT+03",
"ntp_server": "pool.ntp.org",
"status": true,
"accounts": [
{
"name": "Мобилон",
"line": 1,
"sip_register": "sip.mobilonsip.ru",
"sip_name": "sip102",
"sip_user": "sip102",
"sip_password": "4321",
"sip_auth": "sip102"
}
]
}Так ось, у будь-якому телефоні необхідно налаштувати локальний час, sip-лінії. Тут усе просто. Ще приклади можна переглянути .
свій сервер провіжна
У мануалах виробника зазвичай є пункт, де йдеться: візьміть CSV, запишіть там логін-пароль-мак-адресу, нашим фірмовим скриптом згенеруйте файлики, покладіть їх під вебсервер Apache і буде добре.
У наступному пункті мануалу зазвичай розповідається, що ще можна і зашифрувати згенерований файл конфіга.
Але все це класика. Сучасний підхід зі смузі та твіттером каже, що треба зробити готовий вебсервер, який буде не такий потужний як Apache, а робитиме лише одну маленьку справу. Формувати та віддавати конфіги за посиланням.
Тут зупинимося і пригадаємо, що багато SIP-телефони зараз можуть отримати конфіги по http/https, тому інших реалізацій (ftp, tftp, ftps) ми не розглядаємо. Потім кожен телефон знає свою мак-адресу. Тому ми зробимо два посилання: одне персональне - за ключом пристрою, друге загальне, яке працює по зв'язці загальний токен і мак-адресу.
Також я не зупинятимуся на zero-config'і, тобто. налаштування телефону "з нуля", тобто. ви встромили його в мережу і він хоп заробив. Ні, в моєму сценарії, ви встромили в мережу, зробили попереднє налаштування (налаштували його отримувати конфіг від сервера провіжна), а потім п'єте піноколаду і переналаштовуєте телефон як треба через провіжн. Роздавати Option 66 – це турбота DHCP-сервера.
До речі, зовсім замучився говорити "provisioning", тому слово скоротилося до "провіжн", не штовхайте, будь ласка, ногами.
І ще: у нашого сервера провіжна немає UI, тобто. інтерфейсу користувача. Можливо, поки що, але з певний, т.к. мені не потрібно. Зате є API для збереження/видалення налаштувань, отримання списку вендорів, моделей, що підтримуються, все описано за канонами swagger специфікації.
Чому API, а не UI? Т.к. у мене вже є своя телефонна система, то, я маю джерело облікових даних, де мені достатньо взяти ці дані, скомпонувати потрібний json і опублікувати на сервері провіжна. А вже сервер провіжна за правилами, вказаними в json-файлі, видасть потрібному пристрою його конфіг або не видасть, якщо пристрій не те, або не відповідає за критеріями, зазначеними також у цьому json'і.
Ось такий мікросервіс провіжна вийшов. Називається , вихідний код доступний на гітхабі, також є , приклад використання докеру .
Ключові фішки:
-
у будь-якому випадку обмежений доступ до конфігу за часом за промовчанням 10 хвилин. Якщо ви хочете зробити ще раз конфіг доступним, переопублікуйте конфігурацію знову.
-
один формат для всіх вендорів, все підстроювання прибрано в sonata, відправляєш стандартизований json, налаштовуєш будь-яке доступне обладнання.
-
всі конфіги, що видаються, пристроям логуються, всі проблемні місця можна переглянути в лозі і побачити помилки
-
можливе використання одного загального посилання з token, кожен телефон отримує свій конфіг, вказавши mac-адресу. Або персональне посилання по key.
-
API для керування (management) та видачі конфігів телефонам (provisioning) розділені по портах
-
Тести. Для мене дуже важливо було зафіксувати формат конфіга, що видається, і всі звичайні ситуації видачі конфіга покривати тестами. Щоб це все чітко працювало.
Мінуси:
Поки що не використовується шифрування в рамках sonata. Тобто. ви, звичайно, можете почати використовувати https, поставивши, наприклад, nginx, перед sonata. Але фірмові методи поки що не задіяні. Чому? Проект ще молодий, запровіжнив свою чи першу сотню пристроїв. І, звісно, збираю ідеї, зворотний зв'язок. Далі, щоб зробити все безпечно, щоб конфіги не можна було посніфати в мережі, ймовірно, варто заморочитися на ключі шифрування, tls і їжа з ними, але це буде продовження.
Відсутність UI. Можливо, це суттєвий мінус для кінцевого користувача, але для системного адміністратора скоріше важлива консольна утиліта, ніж повноцінна програма. Зробити консольну утиліту було в планах, але чи не впевнена чи потрібна вона?
Що в підсумку?
Невеликий і простий веб-сервер для провіжна кількох моделей телефонів з API для керування.
Ще раз, як це має працювати?
- Встановлюємо sonata.
- Формуємо json-конфіг та публікуємо його в sonata.
- Потім одержуємо від sonata посилання для провіжна.
- Потім це посилання вказуємо у телефонному апараті.
- Апарат затягує конфіг
у наступній експлуатації лише два кроки:
- Формуємо json-конфіг та публікуємо його в sonata
- Апарат затягує конфіг
Які телефони просуваються?
Вендори Grandstream, Fanvil, Yealink. Конфіги в рамках вендора більш-менш однакові, але можуть відрізнятися залежно від прошивки, можливо, необхідно буде протестувати додатково.
Які правила можна задавати?
По часу. Ви можете вказати час, до якого буде доступний конфіг.
За mac-адресою. При віддачі конфіга за персональним посиланням пристрою також буде перевірено mac-адресу.
За ip. За IP-адресою, звідки зроблено запит.
Як взаємодіяти з sonata?
Через API, роблячи http запити. API буде доступно у вашій інсталяції. Т.к. API підтримує swagger специфікацію, то можна скористатися для тестових запитів до API.
Ок, добре. Річ прикольна, як спробувати?
Найпростіше розгорнути docker-образ на основі репозиторію . У репозиторії лежить інструкція із встановлення.
А якщо я знаю node.js?
Якщо у вас є досвід використання JavaScript, то ви швидко розберетеся, як все тут влаштовано.
Чи буде розвиток sonata?
Частково своїх цілей я досяг. Подальший розвиток – це питання моїх завдань на тему автоматизації налаштування телефонів. Є ще можливість розширити конфіги для налаштування кнопок телефону, додати провіж адресних книжок, можливо ще щось, напишіть у коментарях.
Резюме та подяки
Буду радий конструктивним пропозиціям/запереченням/коментарам та питанням, т.к. цілком можливо щось незрозуміло описав.
Також висловлюю подяку всім колегам, хто допомагав, консультував, тестував, надав/подарував телефони для тестів. Реально, до проекту причетна різною мірою безліч людей, з якими я спілкувався по роботі. Те, в чатах та емейлах. Дякую за ідеї та думки.
Джерело: habr.com