Jag vet inte vad jag ska jämföra provisionering med. Kanske med en katt? Det verkar möjligt utan det, men med det är det lite bättre. Speciellt om det fungerar))
Formulering av problemet:
- Jag vill ställa in SIP-telefoner snabbt, enkelt och säkert. När du installerar en telefon, och ännu mer när du konfigurerar om den.
- Många leverantörer har sina egna konfigurationsformat, sina egna verktyg för att generera konfigurationer och sina egna sätt att skydda konfigurationer. Och jag vill egentligen inte ha att göra med alla.
- Många provisioneringslösningar, a) är fokuserade på en leverantör eller ett telefonsystem, b) är ganska besvärliga att implementera, många skript, parametrar, brrr...
När det gäller punkt 3 kommer jag att kommentera att det finns utmärkta provisioneringssystem , , , där mallar för telefoner från olika leverantörer är allmänt tillgängliga. Det finns kommersiella lösningar där du även kan konfigurera driften av telefoner från olika tillverkare i provisioneringsmodulen, till exempel Yeastar PBX.
Habré är också full av recept på hur man ställer in enheter från olika leverantörer: , . Men som de säger, alla system har ett fatalt fel. Så vi gör vår egen cykel.
ditt eget format
Som de säger i xkcd, om du inte vill hantera 14 format - . Därför använder vi allmänna inställningar för alla telefoner och gör vårt eget json-konfigurationsformat.
Något som det här:
{
"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"
}
]
}Så i alla telefoner måste du konfigurera lokal tid och SIP-linjer. Allt är enkelt här. Du kan se fler exempel .
din egen serverprovisionering
I tillverkarens manualer finns det vanligtvis en punkt där det står: ta en csv, skriv ner ditt inloggningslösenord-mac-adress, generera filer med vårt proprietära skript, lägg dem under Apache-webbservern och allt kommer att bli bra.
Nästa stycke i manualen brukar säga att du också kan kryptera den genererade konfigurationsfilen.
Men dessa är alla klassiker. Det moderna tillvägagångssättet med smoothies och Twitter säger att du behöver göra en färdig webbserver som inte blir lika kraftfull som Apache, utan bara gör en liten sak. Generera och skicka konfigurationer med en länk.
Låt oss stanna här och komma ihåg att nästan alla SIP-telefoner nu kan ta emot konfigurationer via http/https, så vi överväger inte andra implementeringar (ftp, tftp, ftps). Sedan känner varje telefon sin egen MAC-adress. Därför kommer vi att göra två länkar: en personlig - baserad på enhetsnyckeln, den andra allmänna, som fungerar med en kombination av en gemensam token och en MAC-adress.
Dessutom kommer jag inte att uppehålla mig vid zero-config, dvs. ställa in telefonen från grunden, d.v.s. du kopplade in den till nätverket och den började fungera. Nej, i mitt scenario ansluter du den till nätverket, gör den preliminära installationen (ställer in den för att ta emot konfigurationen från provisioneringsservern) och dricker sedan pina colada och konfigurerar om telefonen efter behov genom provisioneringen. Distributionsalternativ 66 är DHCP-serverns ansvar.
Förresten, jag är helt trött på att säga "provisioning", så ordet förkortades till "provision", snälla sparka mig inte.
Och en sak till: vår provisioneringsserver har inget användargränssnitt, dvs. användargränssnitt. Kanske, för nu, men inte säker, för... Jag behöver det inte. Men det finns ett API för att spara/ta bort inställningar, få en lista över leverantörer som stöds, modeller, allt beskrivs enligt kanonerna i swagger-specifikationen.
Varför API och inte UI? Därför att Jag har redan mitt eget telefonsystem, då har jag en källa till autentiseringsuppgifter, där jag bara behöver ta denna data, kompilera nödvändig json och publicera den på provisioneringsservern. Och provisioneringsservern, enligt reglerna som anges i json-filen, kommer att ge den nödvändiga enheten dess konfiguration eller kommer inte att ge den om enheten inte är korrekt eller inte uppfyller kriterierna som också anges i denna json.
Så här blev provisioneringsmikrotjänsten. Kallad , källkoden är tillgänglig på GitHub, det finns också , exempel på docker-användning .
Nyckelfunktioner:
-
i alla fall begränsad åtkomst till konfigurationen av tid, som standard 10 minuter. Om du vill göra konfigurationen tillgänglig igen, publicera om konfigurationen igen.
-
ett format för alla leverantörer, alla justeringar tas bort i sonata, du skickar standardiserad json, konfigurerar all tillgänglig utrustning.
-
alla konfigurationer som utfärdas till enheter loggas, alla problemområden kan ses i loggen och fel kan ses
-
Det är möjligt att använda en gemensam länk med en token; varje telefon får sin egen konfiguration genom att ange mac-adressen. Eller en personlig länk via nyckel.
-
API:er för hantering (hantering) och provisionering av konfigurationer till telefoner (provisioning) är uppdelade efter portar
-
Tester. Det var mycket viktigt för mig att fixa formatet för den utfärdade konfigurationen och täcka alla vanliga situationer med att utfärda en konfiguration med tester. Så att allt fungerar tydligt.
Nackdelar:
Än så länge används inte kryptering på något sätt inom Sonata. De där. du kan naturligtvis börja använda https genom att sätta nginx framför sonata till exempel. Men patentskyddade metoder har ännu inte använts. Varför? Projektet är fortfarande ungt, det har lanserat sina första hundra enheter. Och såklart samlar jag in idéer och feedback. Vidare, för att göra allt säkert, så att konfigurationerna inte kan sniffas på nätverket, är det förmodligen värt att bry sig om krypteringsnycklar, tls och igelkotten med dem, men detta blir en fortsättning.
Brist på UI. Kanske är detta en betydande nackdel för slutanvändaren, men för en systemadministratör är ett konsolverktyg viktigare än en fullfjädrad applikation. Det fanns planer på att göra ett konsolverktyg, men jag är inte säker på om det behövs?
Resultatet?
En liten och enkel webbserver för att tillhandahålla flera telefonmodeller med ett API för hantering.
Återigen, hur ska detta fungera?
- Installerar sonat.
- Vi skapar en json-konfiguration och publicerar den i sonata.
- Sedan får vi en provisioneringslänk från sonata.
- Då anger vi denna länk i telefonen.
- Enheten laddar konfigurationen
Det finns bara två steg i efterföljande drift:
- Vi skapar en json-konfiguration och publicerar den i sonata
- Enheten laddar konfigurationen
Vilka telefoner kommer att marknadsföras?
Leverantörer Grandstream, Fanvil, Yealink. Konfigurationerna inom leverantören är mer eller mindre desamma, men kan skilja sig beroende på firmware - det kan vara nödvändigt att testa ytterligare.
Vilka regler kan du sätta?
Med tiden. Du kan ange den tid fram till vilken konfigurationen ska vara tillgänglig.
Med mac-adress. När du skickar in konfigurationen via enhetens personliga länk kommer även mac-adressen att kontrolleras.
Av ip. Efter IP-adress där begäran gjordes.
Hur interagerar man med sonat?
Via API, gör http-förfrågningar. API:et kommer att vara tillgängligt i din installation. Därför att API:et stöder swagger-specifikationen, du kan använda för testförfrågningar till API.
OK bra. Coola grejer, vad sägs om att testa det?
Det enklaste sättet är att distribuera en docker-avbildning baserad på ett arkiv . Förvaret innehåller installationsinstruktioner.
Vad händer om jag känner till node.js?
Om du har erfarenhet av att använda JavaScript kommer du snabbt att ta reda på hur allt fungerar här.
Kommer det att bli en Sonata-utveckling?
Jag uppnådde delvis mina mål. Vidareutveckling är en fråga om mina uppgifter på temat automatisering av telefoninställningar. Det finns också en möjlighet att utöka konfigurationerna för att konfigurera telefonknappar, lägga till adressboksprovisionering, kanske något annat, skriv i kommentarerna.
Sammanfattning och erkännanden
Jag kommer gärna ha konstruktiva förslag/invändningar/kommentarer och frågor, eftersom... Det kan mycket väl vara så att han beskrev något obegripligt.
Jag uttrycker också min tacksamhet till alla mina kollegor som hjälpte, gav råd, testade och tillhandahållit/donerat telefoner för tester. I verkligheten är många människor som jag kommunicerade med på jobbet involverade i projektet i olika grad, e, i chattar och e-postmeddelanden. Tack för idéerna och tankarna.
Källa: will.com