Ik weet niet goed wat ik moet vergelijken met provisioning. Misschien met een kat? Het lijkt te kunnen zonder, maar met het is het net iets beter. Vooral als het werkt)
Probleemstelling:
- Ik wil SIP-telefoons snel, eenvoudig en veilig instellen. Bij het installeren van de telefoon en vooral bij het herconfigureren.
- Veel leveranciers hebben hun eigen configuratieformaten, hun eigen tools voor het genereren van configuraties, hun eigen manieren om configuraties te beveiligen. En daar wil ik me niet mee bezighouden.
- Veel provisioning-oplossingen zijn a) gericht op één leverancier of één telefoonsysteem, b) worden vrij log gerealiseerd, met een hoop scripts, parameters, brr...
Wat betreft punt 3, ik wil opmerken dat er uitstekende provisioning-systemen zijn , , , waar er openbare sjablonen voor telefoons van verschillende leveranciers beschikbaar zijn. Er zijn commerciële oplossingen waarin ook de werking van telefoons van verschillende fabrikanten in de provisioning-module kan worden ingesteld, bijvoorbeeld de Yeastar PBX.
Op Habr zijn ook veel recepten te vinden over hoe je apparaten van verschillende leveranciers kunt instellen: , . Maar zoals men zegt, alle systemen hebben een fataal gebrek. Daarom gaan we onze eigen fiets maken.
onze eigen indeling
Zoals gezegd in xkcd, als je niet wilt uitzoeken hoe je met 14 indelingen om moet gaan — . Daarom gebruiken we algemene instellingen voor elke telefoon en maken we ons eigen JSON-configuratieformaat.
Ongeveer zo:
{
"key": "sdgjdeu9443908",
"token": "590sfdsf8u984",
"model": "gxp1620",
"vendor": "grandstream",
"mac": "001565113af8",
"timezone_offset": "GMT+03",
"ntp_server": "pool.ntp.org",
"status": true,
"accounts": [
{
"name": "Mobilon",
"line": 1,
"sip_register": "sip.mobilonsip.ru",
"sip_name": "sip102",
"sip_user": "sip102",
"sip_password": "4321",
"sip_auth": "sip102"
}
]
}Dus, in elke telefoon moet je de lokale tijd en sip-lijnen instellen. Dit is eenvoudig. Je kunt ook voorbeelden bekijken .
je eigen provisioning server
In de handleidingen van de fabrikant staat meestal een punt waarin staat: neem een CSV-bestand, schrijf daar in login-wachtwoord-MAC-adres, genereer met ons eigen script bestanden, zet ze onder de Apache-webserver en het zal goed zijn.
In het volgende punt van de handleiding wordt meestal verteld dat je ook het gegenereerde configuratiebestand kunt versleutelen.
Maar dit is allemaal klassiek. De moderne aanpak met smoothies en Twitter zegt dat we een kant-en-klaar webserver moeten maken, die niet zo krachtig is als Apache, maar alleen één kleine taak uitvoert. Configuraties genereren en leveren via een link.
Hier stoppen we en herinneren we ons dat bijna alle SIP-telefoons nu configuraties via http/https kunnen ontvangen, dus andere implementaties (ftp, tftp, ftps) beschouwen we niet. Bovendien kent elke telefoon zijn eigen MAC-adres. Daarom maken we twee links: één persoonlijke - op basis van het apparaatsleutel, de tweede algemene, die werkt op een combinatie van een algemene token en een MAC-adres.
Ook zal ik niet stilstaan bij zero-config, dat wil zeggen dat de telefoon "uit de doos" is ingesteld: je steekt hem in het netwerk en hij hop, het werkt. Nee, in mijn scenario steek je hem in het netwerk, maak je een voorlopige configuratie (stel je in om configuraties van de provizijnserver te ontvangen), en dan drink je een piña colada en stel je de telefoon opnieuw in zoals het moet via provisioning. Het verstrekken van Option 66 is de verantwoordelijkheid van de DHCP-server.
Trouwens, ik ben helemaal moe van het zeggen van "provisioning", dus het woord is ingekort tot "provizijn", trap alsjeblieft niet op me.
En nog iets: onze provisioningserver heeft geen UI, dat wil zeggen, geen gebruikersinterface. Misschien voorlopig, maar ik ben er niet zeker van, aangezien ik het niet nodig heb. Maar er is wel een API voor het opslaan/verwijderen van instellingen, het verkrijgen van een lijst van ondersteunde leveranciers, modellen, alles is beschreven volgens de regels van de swagger-specificatie.
Waarom API en niet UI? Omdat ik al mijn eigen telefoonsysteem heb, heb ik een bron van referenties waar ik deze gegevens eenvoudig kan ophalen, de benodigde json kan samenstellen en kan publiceren op de provisioningserver. De provisioningserver geeft dan, volgens de regels in het json-bestand, de benodigde configuratie aan het apparaat, of niet, als het apparaat niet juist is of niet voldoet aan de criteria die ook in deze json zijn aangegeven.
Zo is deze provisioning-microservice ontstaan. Het heet , de source code is beschikbaar op GitHub, er is ook een , een voorbeeld van het gebruik van Docker .
Belangrijke kenmerken:
in ieder geval beperkte toegang tot de configuratie in de tijd, standaard 10 minuten. Als je de configuratie opnieuw toegankelijk wilt maken, publiceer de configuratie opnieuw.
één formaat voor alle leveranciers, alle aanpassingen zijn in sonata geïntegreerd, je stuurt een gestandaardiseerde json, configureert elke beschikbare apparatuur.
Alle configuraties die aan apparaten worden uitgegeven, worden gelogd. U kunt alle probleemgebieden in het logboek bekijken en fouten zien.
Het is mogelijk om één gezamenlijke link met token te gebruiken, waarbij elke telefoon zijn eigen configuratie ontvangt door het mac-adres op te geven. Of een persoonlijke link op basis van key.
De API voor beheer en het uitgeven van configuraties aan telefoons is opgesplitst over poorten.
Tests. Voor mij was het erg belangrijk om het format van de uitgegeven configuratie vast te leggen en alle gebruikelijke situaties van configuratie-uitgifte te dekken met testen. Zodat dit alles duidelijk werkt.
Nadelen:
Op dit moment wordt er nog geen encryptie gebruikt binnen sonata. U kunt natuurlijk beginnen met https door bijvoorbeeld nginx voor sonata te plaatsen. Maar de specifieke methoden zijn nog niet ingezet. Waarom? Het project is nog jong en heeft nauwelijks zijn eerste honderd apparaten geconfigureerd. En ik verzamel natuurlijk ideeën en feedback. Verder, om alles veilig te maken zodat configuraties niet in het netwerk kunnen worden onderschept, is het waarschijnlijk de moeite waard om te kijken naar encryptiesleutels, tls en dergelijke, maar dat wordt een vervolg.
Gebrek aan UI. Dit kan een aanzienlijk nadeel zijn voor de eindgebruiker, maar voor de systeembeheerder is een consoletool waarschijnlijk belangrijker dan een volledig applicatie. Een consoletool maken was in de plannen, maar ik ben niet zeker of deze nodig is.
Wat is het resultaat?
Een kleine en eenvoudige webserver voor de provisioning van verschillende modellen telefoons met een API voor beheer.
Nogmaals, hoe zou dit moeten werken?
- We installeren sonata.
- We formuleren de json-configuratie en publiceren deze in sonata.
- Daarna krijgen we van sonata een link voor provisioning.
- Vervolgens geven we deze link op in het telefoontoestel.
- Het toestel haalt de configuratie op.
In de latere exploitatie slechts twee stappen:
- We formuleren de json-configuratie en publiceren deze in sonata.
- Het toestel haalt de configuratie op.
Welke telefoons worden geprovisioned?
Leveranciers zoals Grandstream, Fanvil, Yealink. De configuraties binnen de leverancier zijn min of meer hetzelfde, maar kunnen verschillen afhankelijk van de firmware; mogelijk is het nodig om extra te testen.
Welke regels kunnen worden ingesteld?
Op tijd. U kunt de tijd opgeven tot wanneer de configuratie beschikbaar is.
Op mac-adres. Bij het uitgeven van de configuratie via een persoonlijke link wordt ook het mac-adres gecontroleerd.
Op ip. Op het ip-adres van waaruit de aanvraag is gedaan.
Hoe interactie hebben met sonata?
Via de API, door HTTP-verzoeken te doen. De API is beschikbaar in uw installatie. Aangezien de API de Swagger-specificatie ondersteunt, kunt u gebruik maken van voor testverzoeken naar de API.
Oké, prima. Het is een leuk ding, hoe kan ik het proberen?
De eenvoudigste manier is om een Docker-image te draaien op basis van de repository . In de repository vindt u de installatiegids.
А если знаю node.js?
Als u ervaring heeft met JavaScript, zult u snel begrijpen hoe alles hier werkt.
Zal er ontwikkeling van Sonata zijn?
Deels heb ik mijn doelen bereikt. Verdere ontwikkeling is een kwestie van mijn taken op het gebied van het automatiseren van telefooninstellingen. Er is nog ruimte om de configuraties uit te breiden voor het instellen van telefoontoetsen, een provision-adresboek toe te voegen, misschien nog iets anders, laat het weten in de reacties.
Samenvatting en dankbetuigingen
Ik sta open voor constructieve voorstellen/bezwaar/commentaar en vragen, aangezien het goed mogelijk is dat er iets niet duidelijk is beschreven.
Ook wil ik mijn dank uitspreken aan alle collega’s die hebben geholpen, geadviseerd, getest en telefoons voor testen hebben verstrekt/gegeven. Echt, veel mensen waaraan ik op verschillende manieren heb gewerkt, zijn op dit project betrokken, zowel in chatgroepen als via e-mails. Bedankt voor de ideeën en gedachten.
Bron: habr.com
