Не знаю с чем сравнить provisioning. Может быть с котом? Вроде можно и без него, но с ним немного лучше. Особенно, если он работает ))

Постановка проблемы:

1. Хочу настраивать SIP-телефоны быстро, просто, безопасно. При установке телефона и уж тем более при его переконфигурировании.
2. Многие вендоры имеют свои форматы конфигов, свои утилиты для генерации конфигов, свои способы защиты конфигов. А разбираться с каждым не очень хочется.
3. Многие решения по provisioning, а) ориентированы на одного вендора или одну телефонную систему, б) достаточно громоздко реализуются, куча скриптов, параметров, бр-р...

По пункту 3 сделаю комментарий, что есть отличные системы провижна для FreePBX, для FusionPBX, для Kazoo, где в открытом доступе есть шаблоны для телефонов различных вендоров. Есть коммерческие решения, где также можно настроить в модуле провижна работу телефонов разных производителей, например, АТС Yeastar.

На Хабре также полно рецептов как настроить аппараты различных вендоров: раз, два. Но как говорится, у всех систем есть фатальный недостаток. Поэтому сделаем свой велосипед.

свой формат

Как говорится в xkcd, не хочешь разбираться с 14 форматами — придумай 15-й. Поэтому мы используем общие настройки для любого телефона и сделаем свой 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-линии. Тут все просто. Еще примеры можно посмотреть здесь.

cвой сервер провижна

В мануалах производителя обычно есть пункт, где говорится: возьмите csv, запишите там логин-пароль-мак-адрес, нашим фирменным скриптом сгенерите файлики, положите их под вебсервер Apache и будет хорошо.

В следующем пункте мануала обычно рассказывается, что еще можно и зашифровать сгенерированный файлик конфига.

Но это все классика. Современный подход со смузи и твиттером говорит, что надо сделать готовый вебсервер, который будет не такой мощный как Apache, а будет делать только одно маленькое дело. Формировать и отдавать конфиги по ссылке.

Тут остановимся и вспомним, что почти все SIP-телефоны сейчас могут получить конфиги по http/https, поэтому иных реализаций (ftp, tftp, ftps) мы не рассматриваем. Затем, каждый телефон знает свой мак-адрес. Поэтому мы сделаем две ссылки: одна персональная — по ключу устройства, вторая общая, которая работает по связке общий токен и мак-адрес.

Также я не буду останавливаться на zero-config'е, т.е. настройке телефона "с нуля", т.е. вы воткнули его в сеть и он хоп заработал. Нет, в моем сценарии, вы воткнули в сеть, сделали предварительную настройку (настроили его получать конфиг от сервера провижна), а затем пьете пиноколаду и перенастраиваете телефон как надо через провижн. Раздавать Option 66 — это забота DHCP-сервера.

Кстати, совсем замучился говорить "provisioning", поэтому слово сократилось до "провижн", не пинайте, пожалуйста, ногами.

И еще: у нашего сервера провижна нет UI, т.е. пользовательского интерфейса. Возможно, пока, но не уверен, т.к. мне не требуется. Зато есть API для сохранения/удаления настроек, получения списка поддерживаемых вендоров, моделей, все описано по канонам swagger спецификации.

Почему API, а не UI? Т.к. у меня уже есть своя телефонная система, то, у меня есть источник учетных данных, где мне достаточно взять эти данные, скомпоновать нужный json и опубликовать на сервере провижна. А уже сервер провижна по правилам, указанным в json-файле, выдаст нужному устройству его конфиг или не выдаст, если устройство не то, или не соответствует по критериям, указанным также в этом json'е.

Вот такой вот микросервис провижна получился. Называется sonata, исходный код доступен на гитхабе, также есть готовый докер-образ, пример использования докера здесь.

Ключевые фишки:

• в любом случае ограниченный доступ к конфигу по времени, по умолчанию 10 минут. Если вы хотите сделать еще раз конфиг доступным — переопубликуйте конфигурацию вновь.

  
  

• один формат для всех вендоров, вся подстройка убрана в sonata, отправляешь стандартизированный json, настраиваешь любое доступное оборудование.

  
  

• все выдаваемые конфиги устройствам логируются, все проблемные места можно просмотреть в логе и увидеть ошибки

  
  

• возможно использование одной общей ссылки с token, каждый телефон получает свой конфиг, указав mac-адрес. Либо персональную ссылку по key.

  
  

• API для управления (management) и выдачи конфигов телефонам (provisioning) разделены по портам

  
  

• Тесты. Для меня очень важно было зафиксировать формат выдаваемого конфига и все обычные ситуации выдачи конфига покрывать тестами. Чтобы это все четко работало.

  
  

Минусы:

Пока никак не используется шифрование в рамках sonata. Т.е. вы, конечно, можете начать использовать https, поставив к примеру, nginx, перед sonata. Но вот фирменные способы пока еще не задействованы. Почему? Проект еще молодой, запровижнил свою едва ли первую сотню устройств. И, конечно, собираю идеи, обратную связь. Далее, чтобы сделать все безопасно, чтобы конфиги нельзя было поснифать в сети, вероятно, стоит заморочиться на ключи шифрования, tls и еже с ними, но это будет продолжение.

Отсутствие UI. Возможно, это существенный минус для конечного пользователя, но для системного администратора скорее важна консольная утилита, чем полноценное приложение. Сделать консольную утилиту было в планах, но не уверен нужна ли она?

Что в итоге?

Небольшой и простой веб-сервер для провижна нескольких моделей телефонов с API для управления.

Еще раз, как это должно работать?

1. Устанавливаем sonata.
2. Формируем json-конфиг и публикуем его в sonata.
3. Затем получаем от sonata ссылку для провижна.
4. Затем эту ссылку указываем в телефонном аппарате.
5. Аппарат затягивает конфиг

в последующей эксплуатации только два шага:

1. Формируем json-конфиг и публикуем его в sonata
2. Аппарат затягивает конфиг

Какие телефоны провижнятся?

Вендоры Grandstream, Fanvil, Yealink. Конфиги в рамках вендора более-менее одинаковые, но могут отличаться в зависимости от прошивки — возможно необходимо будет протестировать дополнительно.

Какие правила можно задавать?

По времени. Вы можете указать время, до которого конфиг будет доступным.
По mac-адресу. При отдаче конфига по персональной ссылке устройства также будет проверен mac-адрес.
По ip. По ip-адресу, откуда сделан запрос.

Как взаимодействовать c sonata?

Через API, делая http запросы. API будет доступно в вашей инсталяции. Т.к. API поддерживает swagger спецификацию, то можно воспользоваться online-утилитой для тестовых запросов к API.

Ок, отлично. Вещь прикольная, как попробовать?

Проще всего развернуть docker-образ на основе репозитория sonata-sample. В репозитории лежит инструкция по установке.

А если знаю node.js?

Если у вас есть опыт использования JavaScript, то вы быстро разберетесь как все здесь устроено.

Будет ли развитие sonata?

Частично своих целей я достиг. Дальнейшее развитие — это вопрос моих задач по теме автоматизации настройки телефонов. Есть еще возможность расширить конфиги для настройки кнопок телефона, добавить провижн адресных книжек, возможно еще что-то, напишите в комментариях.

Резюме и благодарности

Буду рад конструктивным предложениям/возражениям/комментариям и вопросам, т.к. вполне может быть что-то непонятно описал.

Также выражаю благодарность всем коллегам, кто помогал, консультировал, тестировал, предоставил/подарил телефоны для тестов. Реально, к проекту причастно в разной мере множество людей, с которыми я общался по работе, в чатах и емейлах. Спасибо за идеи и мысли.