Не знам с какво да сравня 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, запишете там логин-парола-mac адрес, с нашия фирмен скрипт генерирайте файлове, сложете ги под уебсървър Apache и всичко ще бъде наред.
В следващата точка на ръководството обикновено се описва, че също можете да шифровате генерирания конфигурационен файл.
Но това всичко е класика. Съвременният подход със смутита и Twitter казва, че трябва да създадете готов уеб сървър, който няма да е толкова мощен като Apache, а просто да извършва една малка работа. Да генерира и предоставя конфигурации по линк.
Тук спираме и си припомняме, че почти всички SIP телефони сега могат да получат конфигурации по http/https, затова не обсъждаме други реализации (ftp, tftp, ftps). Следователно, всеки телефон знае своя мак адрес. Така че ще направим две връзки: една персонализирана — по ключа на устройството, втората обща, която работи на базата на общ токен и мак адрес.
Също така няма да се спирам на zero-config, т.е. настройката на телефона „от нулата“, т.е. вкарвате го в мрежата и той хоп заработи. Не, в моя сценарий вкарвате в мрежата, правите предварителна настройка (настройвате го да получава конфиг от сървъра за провизия), а след това пиете пино колада и пренастройвате телефона както трябва чрез провизия. Да давате Option 66 — това е задача на DHCP сървъра.
Между другото, напълно ми омръзна да казвам „provisioning“, затова думата се съкрати до „провизия“, не ме ритайте, моля.
И още: нашият сървър за провизия няма UI, т.е. потребителски интерфейс. Може би, временно, но не съм сигурен, защото не ми е необходим. Затова има API за запазване/изтриване на настройки, получаване на списък с поддържани доставчици, модели, всичко е описано по каноните на swagger спецификацията.
Защо API, а не UI? Защото вече имам собствена телефонна система, имам източник на идентификационни данни, откъдето ми е достатъчно да взема тези данни, да съставя нужния json и да публикувам на сървъра за провизия. А вече сървъра за провизия според правилата, посочени в json файла, ще предостави на нужното устройство неговия конфиг или няма да го предостави, ако устройството не е това или не отговаря на критериите, посочени също в този json.
Ето такъв микросервис за провизия се получи. Намира се , изходният код е наличен на гитхаб, също има , пример за използване на docker .
Ключови функции:
във всеки случай ограничен достъп до конфигурацията по време, по подразбиране 10 минути. Ако искате отново да направите конфигурацията достъпна — публикувайте конфигурацията отново.
един формат за всички доставчици, всичката настройка е премахната в sonata, изпращате стандартизиран json, настройвате всяко налично оборудване.
всички предоставени конфигурации на устройствата са логвани, всички проблемни места могат да бъдат разгледани в логовете и да се видят грешките.
възможно е да се използва една обща връзка с token, всеки телефон получава своя конфигурация, посочвайки mac адрес. Или лична връзка по ключ.
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
