В , kalbėjau apie Veliam kūrimo aplinkybes ir sprendimą platinti ją per SaaS sistemą. Šiame straipsnyje kalbėsiu apie tai, ką turėjau padaryti, kad produktas būtų ne vietinis, o viešas. Apie tai, kaip prasidėjo platinimas ir su kokiomis problemomis jie susidūrė.
Planavimas
Dabartinė vartotojų sistema buvo „Linux“. Beveik kiekviena organizacija turi Windows serverius, ko negalima pasakyti apie Linux. Pagrindinė Veliam privalumas yra nuotoliniai ryšiai su serveriais ir tinklo įranga už NAT. Tačiau ši funkcija buvo labai glaudžiai susijusi su tuo, kad maršrutizatorius turėjo būti „Mikrotik“. Ir tai akivaizdžiai daugelio netenkintų. Pirmiausia pradėjau galvoti apie palaikymą maršrutizatoriams iš labiausiai paplitusių pardavėjų. Bet supratau, kad tai buvo nesibaigiančios lenktynės plėsti remiamų įmonių sąrašą. Be to, tie, kurie jau palaikomi, gali turėti skirtingą komandų rinkinį, skirtą NAT taisyklėms keisti kiekvienam modeliui. Vienintelė išeitis iš situacijos buvo VPN.
Kadangi nusprendėme platinti produktą, bet ne kaip atvirojo kodo, tapo neįmanoma įtraukti įvairių bibliotekų su atviromis licencijomis, tokiomis kaip GPL. Paprastai tai yra atskira tema, priėmus sprendimą parduoti produktą, turėjau pereiti pusę bibliotekų dėl to, kad jos buvo GPL. Kai jie rašė sau, tai buvo normalu. Bet platinimui jis netinka. Pirmasis VPN, kuris ateina į galvą, yra „OpenVPN“. Bet tai GPL. Kita galimybė buvo naudoti japonišką SoftEther VPN. Licencija leido jį įtraukti į savo gaminį. Po poros dienų įvairių bandymų, kaip jį integruoti taip, kad vartotojui visiškai nereikėtų nieko konfigūruoti ir žinoti apie SoftEther VPN, buvo gautas prototipas. Viskas buvo taip, kaip ir turi būti. Tačiau kažkodėl ši schema vis tiek mus supainiojo, ir galiausiai jos atsisakėme. Tačiau, žinoma, jie atsisakė, kai sugalvojo kitą variantą. Galų gale viskas buvo daroma naudojant įprastus TCP ryšius. Kai kurie ryšiai veikia per koordinatorių, kai kurie tiesiogiai per „Nat Hole Punching“ (NHP) technologiją, kuri taip pat buvo įdiegta „Free Pascal“. Turiu pasakyti, kad apie NHP niekada net nebuvau girdėjęs. Ir man niekada neatėjo į galvą, kad galima prijungti 2 tinklo įrenginius, kurie abu yra tiesiai už NAT. Išstudijavau temą, supratau veikimo principą ir atsisėdau rašyti. Planas įgyvendinamas, vartotojas vienu paspaudimu prisijungia prie norimo įrenginio už NAT per RDP, SSH ar Winbox neįvesdamas slaptažodžių ir nenustatęs VPN. Be to, dauguma šių jungčių praeina pro mūsų koordinatorių, o tai turi gerą poveikį ping ir šių jungčių aptarnavimo išlaidoms.
Serverio pusės perkėlimas iš Linux į Windows
Perjungiant į „Windows“ kilo keletas problemų. Pirmasis yra tas, kad Windows integruotas wmic neleidžia atlikti WQL užklausų. Ir mūsų sistemoje viskas jau buvo pastatyta ant jų. Ir dar kažkas buvo, bet dabar jau pamiršau, kodėl jie galiausiai atsisakė jo naudojimo. Galimi skirtumai tarp „Windows“ versijų. Ir antroji problema yra daugiagija. Neradęs geros trečiosios šalies paslaugų pagal mums „priimtiną“ licenciją, vėl paleidau Lazarus IDE. Ir parašiau reikiamą įrankį. Įvestis yra reikalingas objektų sąrašas ir kokios konkrečios užklausos turi būti pateiktos, o atsakydamas gaunu duomenis. Ir visa tai kelių sriegių režimu. Puiku.
Nustačius pthreadus PHP Windows, maniau, kad viskas tuoj prasidės, bet taip nebuvo. Po tam tikro laiko derinimo supratau, kad pthreads atrodo veikiantis, bet mūsų sistemoje tai neveikė. Tapo aišku, kad „Windows“ sistemoje yra tam tikrų ypatumų dirbant su pthreadais. Taip ir buvo. Perskaičiau dokumentaciją, ten buvo parašyta, kad Windows gijų skaičius ribotas ir, kiek pamenu, netiesiogiai. Tai tapo problema. Nes kai pradėjau mažinti gijų skaičių, kurioje programa paleido, ji darbą atliko labai lėtai. Dar kartą atidariau IDE ir prie tos pačios programos buvo pridėta kelių gijų objektų pingo funkcija. Na, ten jau yra daug prievadų nuskaitymo. Tiesą sakant, po to PHP pthreadų poreikis išnyko ir jis nebenaudojamas. Be to, prie šios priemonės buvo pridėtos dar kelios funkcijos ir ji veikia iki šiol. Po to buvo surinkta „Windows“ diegimo programa, kurioje buvo „Apache“, PHP, „MariaDB“, pati PHP programa ir bendravimo su sistema paslaugų rinkinys, parašytas „Free Pascal“. Kalbant apie montuotoją, maniau, kad šią problemą greitai išspręsiu, nes... Tai labai įprastas dalykas ir būtinas beveik kiekvienai programinei įrangai. Arba ieškojau ne toje vietoje, arba ko nors kito. Tačiau nuolat susidurdavau su produktais, kurie buvo arba nepakankamai lankstūs, arba brangūs ir nelankstūs. Ir vis dėlto radau nemokamą montuotoją, kuriame bus galima pateikti bet kokius pageidavimus. Tai InnoSetup. Rašau apie tai čia, nes turėjau pasidomėti, jei kam nors sutaupysiu laiko.
Papildinio atsisakymas jūsų kliento naudai
Anksčiau rašiau, kad kliento dalis buvo naršyklė su „įskiepiu“. Taigi buvo laikai, kai „Chrome“ buvo atnaujinta ir išdėstymas buvo šiek tiek kreivas, tada „Windows“ buvo atnaujintas ir pasirinkta uri schema išnyko. Tikrai nenorėjau turėti tokių netikėtumų viešoje produkto versijoje. Be to, tinkintas uri pradėjo dingti po kiekvieno „Windows“ atnaujinimo. „Microsoft“ tiesiog ištrynė visas ne savo šakas reikiamame skyriuje. Be to, „Google Chrome“ dabar neleidžia atsiminti pasirinkimo atidaryti ar ne programą iš tinkinto uri ir užduoda šį klausimą kiekvieną kartą, kai spustelėsite stebėjimo objektą. Na, apskritai buvo reikalinga įprasta sąveika su vartotojo vietine sistema, kurios naršyklė nepateikia. Atrodo, kad paprasčiausias variantas šioje schemoje yra tiesiog sukurti savo naršyklę, kaip daugelis dabar daro per Electron. Tačiau daugelis dalykų jau buvo parašyta Free Pascal, įskaitant ir serverio dalį, todėl nusprendėme padaryti klientą ta pačia kalba, o ne kurti zoologijos sodą. Taip buvo parašytas klientas su Chromium. Po to ji pradėjo įsigyti įvairių dirželių.
Atleisti
Galiausiai pasirinkome sistemos pavadinimą. Vykstant vietinės versijos konvertavimo į SaaS procesą, nuolat nagrinėjome įvairias parinktis. Kadangi iš pradžių planavome žengti ne tik į vidaus rinką, pagrindinis vardo pasirinkimo kriterijus buvo neužimto ar nelabai brangaus domeno buvimas „.com“ zonoje. Kai kurios funkcijos/moduliai dar nebuvo perkeltos iš vietinės versijos į Veliam, bet nusprendėme jas išleisti su esamomis funkcijomis, o likusias užbaigti kaip atnaujinimus. Pačioje pirmoje versijoje nebuvo HelpDesk, Veliam Connector, nebuvo įmanoma pakeisti pranešimų aktyviklių slenksčių ir daug daugiau. Nusipirkome Code Sign Certificate ir pasirašėme kliento ir serverio dalis. Sukūrėme produkto svetainę, pradėjome programinės įrangos, prekės ženklo ir tt registravimo procedūras. Apskritai esame pasirengę pradėti. Lengva euforija dėl atlikto darbo ir nuo to, kad galbūt kas nors pasinaudos jūsų gaminiu, nors mes dėl to neabejojome. Ir tada sustoti. Partneris teigė, kad be pranešimų per pasiuntinius patekti į rinką neįmanoma. Tai įmanoma be daugelio kitų dalykų, bet ne be šito. Po tam tikrų diskusijų buvo pridėta integracija su „Telegram“, kuri mums tiko. Iš visų dabartinių momentinių pranešimų siuntėjų tai yra vienintelis, kuris suteikia prieigą prie savo API nemokamai ir be jokių sudėtingų patvirtinimo procedūrų. Ta pati WhatsApp siūlo kreiptis į paslaugų teikėjus, kurie ima gerus pinigus už naudojimąsi jų paslaugomis, buvo ignoruojami visi laiškai, kuriuose prašoma prieigos be tarpiklių. Na, Viber... Nežinau, kas juo dabar naudojasi, nes... šlamštas ir reklama yra iš sąrašo. Gruodžio pabaigoje, po daugybės vidinių ir draugų testų, registracija buvo atidaryta visiems, o programinę įrangą buvo galima atsisiųsti.
Platinimo pradžia
Nuo pat pradžių supratome, kad mums reikia nedidelio srauto sistemos vartotojų, kad jie galėtų išbandyti produktą koviniu režimu ir pateikti pirmuosius atsiliepimus. Keli įsigyti įrašai VK davė vaisių. Atvyko pirmosios registracijos.
Čia reikia pasakyti, kad įeiti į rinką, kai jūsų įmonė neturi garsaus pavadinimo, ir tuo pačiu užtikrinti be agentų stebėjimo funkcionalumą, kuriame reikia įvesti paskyras iš savo serverių ir darbo vietų, yra labai sunku. Tai gąsdina daug žmonių. Nuo pat pradžių supratome, kad dėl to kils problemų ir buvome tam pasiruošę tiek techniškai, tiek morališkai. Visi nuotoliniai ryšiai, nepaisant to, kad RDP ir SSH jau yra užšifruoti pagal nutylėjimą, mūsų programinė įranga papildomai šifruoja naudojant AES standartą. Visi duomenys iš vietinių serverių per HTTPS perduodami į debesį. Paskyros saugomos šifruota forma. Visų posistemių šifravimo raktai yra individualūs visiems klientams. Nuotoliniams ryšiams paprastai naudojami seanso šifravimo raktai.
Viskas, ką galime padaryti šioje situacijoje, kad žmonės jaustųsi ramesni, tai būti kiek įmanoma atviresniems, stengtis užtikrinti saugumą ir nepavargti atsakyti į žmonių klausimus.
Daugeliui programinės įrangos patogumas ir funkcionalumas nusveria baimę, ir jie registruojasi. Kai kurie asmenys VK paskelbtuose įrašuose rašė, kad šios programinės įrangos negalima naudoti, nes Tai yra jų slaptažodžių rinkinys ir paprastai neįvardijama įmonė. Reikia pasakyti, kad tokią nuomonę turėjo ne vienas. Daugelis žmonių tiesiog nesupranta, kad kai jie įdiegia kitą patentuotą programinę įrangą serveryje, kuris veikia kaip paslauga, ji taip pat turi visas teises sistemoje ir jiems nereikia paskyrų, kad galėtų daryti ką nors neteisėto (aišku, kad galite pakeisti vartotojas, iš kurio paleidžiama paslauga, tačiau čia taip pat galite įvesti bet kurią paskyrą). Tiesą sakant, žmonių baimės suprantamos. Įdiegti programinę įrangą serveryje yra įprastas dalykas, tačiau įvesti paskyrą yra šiek tiek baisu ir intymi, nes nemaža pusė žmonių turi tą patį slaptažodį visoms paslaugoms, o sukurti atskirą paskyrą net bandymui – tingu. Tačiau šiuo metu yra daugybė paslaugų, kuriomis žmonės pasitiki savo kredencialais ir dar daugiau. Ir mes siekiame tapti vienu iš jų.
Buvo daug komentarų, kad mes jį kažkur pavogėme. Tai mus šiek tiek nustebino. Na, gerai, vieno žmogaus nuomonė, bet tokių komentarų buvo rasta įvairiuose leidiniuose iš skirtingų žmonių. Iš pradžių jie nežinojo, kaip į tai reaguoti. Arba liūdėti, kad kai kurie žmonės laikosi nuomonės, kad Rusijoje niekas nieko negali padaryti pats, o gali tik vogti, arba džiaugtis, kad mano, kad tai galima tik pavogti.
Dabar baigėme EV kodo ženklo sertifikato gavimo procedūrą. Norėdami jį gauti, turite atlikti daugybę patikrinimų ir išsiųsti daugybę dokumentų apie įmonę, kai kurie iš jų turi būti patvirtinti teisininko. EV Code Sign sertifikato gavimas pandemijos metu yra atskira straipsnio tema. Procedūra truko mėnesį. Ir tai buvo ne laukimo mėnuo, o nuolatiniai prašymai dėl papildomų dokumentų. Gal pandemija nieko bendro neturėjo, o procedūra visiems taip užtruko? Dalintis.
Kai kas sako, kad nenaudosime, nes nėra FSTEC sertifikato. Turime paaiškinti, kad negalime jo gauti ir negausime, nes norint gauti šį sertifikatą, šifravimas turi atitikti GOST, o programinę įrangą planuojame platinti ne tik Rusijoje ir naudoti AES.
Visi šie komentarai kelia abejonių, ar įmanoma reklamuoti produktą, kuriam reikia įvesti paskyras, viešai nežinant. Nors žinojome, kad bus labai neigiamai nusiteikusių į tai. Registracijų skaičiui viršijus tūkstantį, nustojome apie tai galvoti. Ypač po to, kai, be neigiamo tų, kurie net nebandė produkto, pradėjo pasirodyti labai malonūs atsiliepimai. Reikia pasakyti, kad šie teigiami atsiliepimai yra didžiausias produkto kūrimo motyvas.
Darbuotojų nuotolinės prieigos funkcijų įtraukimas
Viena iš dažnų klientų užduočių yra „suteikti Vanijai prieigą prie savo kompiuterio iš namų“. „Mikrotik“ iškėlėme VPN ir sukūrėme paskyras vartotojams. Bet tai tikra problema. Vartotojai negali žiūrėti instrukcijų ir žingsnis po žingsnio jų laikytis prisijungdami per VPN. Įvairios Windows versijos. Viename Windows viskas jungiasi gerai, kitame reikia kito protokolo. Ir apskritai tai visada buvo siejama su tinklo įrangos, kuri veikė kaip VPN serveris, pertvarkymu, o ne visi darbuotojai turi prieigą prie jo ir tai buvo nepatogu.
Bet mes jau turime nuotolinius ryšius su serveriais ir tinklo įranga. Kodėl gi nepasinaudojus paruoštu transportu ir nepadarius atskiro mažo įrankio, kurį galite tiesiog duoti vartotojui prisijungti. Tiesiog norėjau įsitikinti, kad vartotojas ten neįvedė nieko sudėtingo. Tik vienas mygtukas „prisijungti“. Bet kaip ši programa supras, kur prisijungti, jei ji turi tik vieną mygtuką? Kilo idėja sukurti reikiamą aplikaciją internetu mūsų serveriuose. Sistemos administratorius paspaudžia mygtuką „Atsisiųsti spartųjį klavišą“ ir į mūsų debesį siunčiama komanda sukurti atskirą dvejetainį failą su laidine informacija, skirta prisijungti prie norimo serverio/kompiuterio per KPP. Apskritai tai būtų galima padaryti. Bet tai užtrunka ilgai, pirmiausia administratorius turės palaukti, kol bus sukompiliuotas ir tada atsisiųstas dvejetainis failas. Žinoma, būtų galima tiesiog pridėti antrą failą su konfigūracija, bet tai jau 2 failai, o vartotojui dėl paprastumo reikia vieno. Vienas failas, vienas mygtukas ir jokių diegimo programų. Šiek tiek pasiskaitęs Google priėjau prie išvados, kad jei sukompiliuoto „.exe“ pabaigoje pridėsite šiek tiek informacijos, tada jis nepablogės (na, beveik). Ten galima bent jau pridėti karą ir taiką, ir veiks kaip anksčiau. Būtų nuodėmė tuo nepasinaudoti. Dabar galite tiesiog išpakuoti programą kelyje tiesiai pačiame kliente, beje, ji vadinama Veliam Connector, ir tiesiog pridėti informaciją, reikalingą prisijungimui prie jos pabaigos. Ir pati programa žino, ką su ja daryti. Kodėl skliausteliuose šiek tiek aukščiau parašiau „na beveik“? Nes už šį patogumą reikia mokėti, nes programa praranda skaitmeninį parašą. Tačiau šiuo metu manome, kad tai nedidelė kaina už tokį patogumą.
Trečiųjų šalių modulių licencijos
Aukščiau jau rašiau, kad po to, kai buvo nuspręsta prekę padaryti viešai prieinamą, o ne tik savo reikmėms, teko sunkiai dirbti ir ieškoti pakaitalų kai kuriems moduliams, kurie neleido patekti į mūsų gaminį. Tačiau po paleidimo atsitiktinai buvo aptiktas labai nemalonus dalykas. „Veliam Server“, kuris buvo kliento pusėje, apėmė „MariaDB“ DBVS. Ir tai yra GPL licencija. GPL licencija reiškia, kad programinė įranga turi būti atvirojo kodo, o jei mūsų gaminyje yra MariaDB, turintis šią licenciją, mūsų produktas turi būti pagal šią licenciją. Bet, laimei, šios licencijos tikslas yra atvirasis kodas, o ne bausti netyčia suklydusius teisme. Jei autorių teisių turėtojas turi pretenziją, jis apie tai raštu praneša pažeidėjui ir jis privalo per 30 dienų pažeidimą pašalinti. Mes patys atradome savo klaidą ir negavome jokių laiškų ir iškart pradėjome svarstyti variantus, kaip išspręsti problemą. Sprendimas pasirodė akivaizdus – pereiti prie SQLite. Ši duomenų bazė neturi licencijavimo apribojimų. Dauguma šiuolaikinių naršyklių naudoja SQLite ir daugybę kitų programų. Internete radau informacijos, kad SQLite yra laikoma plačiausiai pasaulyje paplitusia DBVS, būtent dėl naršyklių, tačiau įrodymų neieškojau, todėl tai netiksli informacija. Pradėjau tyrinėti perėjimo prie SQLite pavojus.
Tai tampa nereikšminga užduotimi, kai klientai turi kelis šimtus serverių su MariaDB ir joje esančiais duomenimis. Kai kurios MariaDB funkcijos SQLite nepasiekiamos. Na, pavyzdžiui, kode naudojome tokias užklausas kaip
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Ši konstrukcija leidžia ne tik pasirinkti iš lentelės, bet ir užrakinti eilutės duomenis. Ir dar kelis dizainus taip pat teko perrašyti. Tačiau be to, kad turėjome perrašyti daugybę užklausų, taip pat turėjome sugalvoti mechanizmą, kuris atnaujinus kliento Veliam Server visus duomenis perkeltų į naują DBVS ir ištrintų senąjį. Be to, operacijos SQLite neveikė ir tai buvo tikra problema. Tačiau perskaičiusi žiniatinklio platybes, be jokių problemų sužinojau, kad SQLite operacijas galima įjungti perduodant paprastą komandą jungiantis
PRAGMA journal_mode=WAL;Dėl to užduotis buvo atlikta ir dabar kliento serverio dalis veikia SQLite. Sistemos veikimo pokyčių nepastebėjome.
Nauja pagalbos tarnyba
Reikėjo perkelti HelpDesk sistemą iš vidinės versijos į SaaS versiją, tačiau su tam tikrais pakeitimais. Pirmas dalykas, kurį norėjau padaryti, buvo integracija su kliento domenu skaidrios vartotojo autorizacijos sistemoje. Dabar, norėdamas prisijungti prie HelpDesk ir palikti užklausą sistemoje, vartotojas tiesiog spusteli darbalaukyje esančią nuorodą ir atsidaro naršyklė. Vartotojas neįveda jokių kredencialų. „Apache SSPI“ modulis, kuris yra „Veliam Server“ dalis, automatiškai įgalioja vartotoją pagal domeno paskyrą. Norėdami palikti užklausą sistemoje, kai vartotojas yra už įmonės tinklo ribų, jis paspaudžia mygtuką ir į el. laišką gauna nuorodą, per kurią prisijungia prie HelpDesk sistemos be slaptažodžių. Jei vartotojas yra išjungtas arba ištrintas domene, HelpDesk paskyra taip pat nustos veikti. Taigi sistemos administratoriui nereikia stebėti paskyrų tiek domene, tiek pačiam HelpDesk. Darbuotojas išeina - jis atjungia savo paskyrą domene ir viskas, jis neprisijungs prie sistemos ne iš įmonės tinklo, ne per nuorodą. Kad ši integracija veiktų, sistemos administratorius turi sukurti vieną GPO, kuris и .
Antras dalykas, kurį laikome itin reikalingu HelpDesk sistemoms, bent jau mums patiems, yra prisijungimas prie pareiškėjo tiesiai iš programos vienu paspaudimu. Be to, ryšiai turi praeiti, jei sistemos administratorius yra kitame tinkle. Užsakomosioms reikmėms tai yra privaloma, nuolat dirbantiems sistemos administratoriams taip pat dažnai labai reikalinga. Jau yra keletas produktų, kurie puikiai atlieka nuotolinio ryšio darbą. Ir mes nusprendėme juos integruoti. Dabar integravome VNC, o ateityje planuojame pridėti Radmin ir TeamViewer. Naudodami tinklo transportą nuotoliniam infrastruktūros ryšiui, VNC prisijungėme prie nuotolinių darbo stočių, esančių už NAT. Tas pats nutiks ir su Radminu. Dabar, norėdami prisijungti prie vartotojo, tiesiog turite spustelėti mygtuką „Prisijungti prie pareiškėjo“ pačioje programoje. VNC klientas atsidaro ir prisijungia prie pareiškėjo, nepriklausomai nuo to, ar esate tame pačiame tinkle, ar sėdite namuose su šlepetėmis. Pirma, sistemos administratorius, naudodamas GPO, turi įdiegti VNC serverį kiekvienoje darbo vietoje.
Dabar mes patys pereiname prie naujojo HelpDesk ir naudojame integraciją su domenu ir VNC. Tai mums labai patogu. Dabar galime nemokėti už „TeamViewer“, kurią naudojome daugiau nei trejus metus savo palaikymo tarnybai vykdyti.
Ką planuojame veikti toliau?
Išleisdami prekę jokių mokamų tarifų nedarėme, o tiesiog apribojome nemokamą tarifą iki 50 stebėjimo objektų. Penkių dešimčių tinklo įrenginių ir serverių turėtų pakakti visiems, pagalvojome. Ir tada pradėjo eiti prašymai padidinti limitą. Pasakyti, kad buvome šiek tiek šokiruoti, reiškia nieko nepasakyti. Ar įmonės, turinčios tiek daug serverių, tikrai domisi mūsų programine įranga? Tiems, kurie pateikė tokius prašymus, limitą pratęsėme nemokamai. Atsakydami į jų užklausą, kai kurių paklausėme, kodėl jiems tiek daug reikia, ar jie tikrai turi tiek daug serverių ir tinklo įrangos. Ir paaiškėjo, kad sistemos administratoriai pradėjo naudoti sistemą taip, kaip mes visai neplanavome. Viskas pasirodė paprasta – mūsų programinė įranga pradėjo stebėti ne tik serverius, bet ir darbo vietas. Todėl yra daug prašymų išplėsti limitus. Dabar jau įvedėme mokamus tarifus ir limitus galima plėsti savarankiškai.
Serveriai beveik visada dirba su saugojimo sistemomis arba vietiniais diskais RAID masyve. Ir iš pradžių gaminį gaminome jiems. O SMART stebėjimas šiai užduočiai nebuvo įdomus. Bet atsižvelgiant į tai, kad žmonės pritaikė programinę įrangą darbo stotims stebėti, atsirado prašymų įdiegti SMART stebėjimą. Greitai ją įgyvendinsime.
Atsiradus „Veliam Connector“, nebereikėjo diegti VPN serverio įmonės tinkle, atlikti RDGW ar tiesiog persiųsti prievadus į reikiamus įrenginius, kad būtų galima prisijungti per RDP. Daugelis žmonių mūsų sistemą naudoja tik šiems nuotoliniams ryšiams. „Veliam Connector“ galima naudoti tik „Windows“, o kai kurie įmonių vartotojai iš namų nešiojamųjų kompiuterių, kuriuose veikia „MacOS“, jungiasi prie darbo stočių ar terminalų įmonės tinkle. Ir pasirodo, kad sistemos administratorius dėl kelių vartotojų priverstas vis tiek grįžti prie persiuntimo ar VPN klausimo. Todėl dabar baigiame kurti „Veliam Connector“ versiją, skirtą „MacOS“. Mėgstamos „Apple“ technologijos vartotojai taip pat turės galimybę vienu paspaudimu prisijungti prie įmonės infrastruktūros.
Man labai patinka tai, kad turint daug sistemos vartotojų, nereikia sukti galvos, ko žmonėms reikia ir kas bus patogiau. Jie patys rašo savo pageidavimus, tad artimiausios ateities plėtros planų – nemažai.
Lygiagrečiai dabar planuojame pradėti sistemos vertimą į anglų kalbą ir platinimą užsienyje. Dar nežinome, kaip prekę platinsime už savo šalies ribų, ieškome variantų. Galbūt vėliau apie tai bus atskiras straipsnis. Galbūt kas nors perskaitęs šį straipsnį galės pasiūlyti reikiamą vektorių, arba jis pats žino ir moka tai padaryti ir pasiūlys savo paslaugas. Būsime dėkingi už jūsų pagalbą.
Šaltinis: www.habr.com