Ня ведаю з чым параўнаць provisioning. Можа быць з катом? Накшталт можна і без яго, але з ім крыху лепш. Асабліва, калі ён працуе ))
Пастаноўка праблемы:
- Жадаю наладжваць 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