В , Ek het gepraat oor die agtergrond tot die skepping van Veliam en die besluit om dit deur die SaaS-stelsel te versprei. In hierdie artikel sal ek praat oor wat ek moes doen om die produk nie plaaslik nie, maar publiek te maak. Oor hoe die verspreiding begin het en watter probleme hulle ondervind het.
beplanning
Die huidige backend vir gebruikers was op Linux. Byna elke organisasie het Windows-bedieners, wat nie oor Linux gesê kan word nie. Veliam se vernaamste sterkpunt is afgeleë verbindings met bedieners en netwerktoerusting agter NAT. Maar hierdie funksionaliteit was baie nou gekoppel aan die feit dat die router Mikrotik moes wees. En dit sou natuurlik nie baie tevrede stel nie. Ek het eers begin dink om ondersteuning vir routers van die mees algemene verskaffers by te voeg. Maar ek het verstaan dat dit 'n eindelose wedloop was om die lys van ondersteunde maatskappye uit te brei. Boonop kan diegene wat reeds ondersteun word 'n ander stel opdragte hê om NAT-reëls van model tot model te verander. Die enigste uitweg uit die situasie was blykbaar 'n VPN.
Aangesien ons besluit het om die produk te versprei, maar nie as oopbron nie, het dit onmoontlik geword om verskeie biblioteke met oop lisensies soos GPL in te sluit. Dit is oor die algemeen 'n aparte onderwerp nadat ek die besluit geneem het om die produk te verkoop, moes ek deur die helfte van die biblioteke gaan weens die feit dat hulle GPL was. Toe hulle vir hulself geskryf het, was dit normaal. Maar nie geskik vir verspreiding nie. Die eerste VPN wat by my opkom, is OpenVPN. Maar dit is GPL. Nog 'n opsie was om die Japannese SoftEther VPN te gebruik. Sy lisensie het hom toegelaat om dit by sy produk in te sluit. Na 'n paar dae van verskeie toetse oor hoe om dit op so 'n manier te integreer dat die gebruiker glad nie hoef te konfigureer nie en weet van SoftEther VPN, is 'n prototipe verkry. Alles was soos dit moes wees. Maar om een of ander rede het hierdie skema ons steeds verwar, en ons het dit uiteindelik laat vaar. Maar natuurlik het hulle geweier nadat hulle met 'n ander opsie vorendag gekom het. Op die ou end is alles op gewone TCP-verbindings gedoen. Sommige verbindings werk deur 'n koördineerder, sommige direk deur Nat Hole Punching (NHP) tegnologie, wat ook in Free Pascal geïmplementeer is. Ek moet sê dat ek nog nooit eers van NHP gehoor het nie. En dit het nooit by my opgekom dat dit moontlik was om 2 netwerktoestelle te koppel nie, wat albei direk agter NAT is. Ek het die onderwerp bestudeer, die beginsel van werking verstaan en gaan sit om te skryf. Die plan word gerealiseer, die gebruiker koppel met een klik aan die gewenste toestel agter NAT via RDP, SSH of Winbox sonder om wagwoorde in te voer of 'n VPN op te stel. Boonop gaan die meeste van hierdie verbindings verby ons koördineerder, wat 'n goeie uitwerking het op ping en die koste om hierdie verbindings te diens.
Die oordrag van die bedienerkant van Linux na Windows
Daar was verskeie probleme met die oorskakeling na Windows. Die eerste is dat die ingeboude wmic in Windows jou nie toelaat om WQL-navrae te maak nie. En in ons stelsel was alles reeds op hulle gebou. En daar was nog iets, maar nou het ek vergeet hoekom hulle uiteindelik die gebruik daarvan laat vaar het. Moontlik verskille tussen Windows-weergawes. En die tweede probleem is multithreading. Omdat ek nie 'n goeie derdeparty-hulpmiddel onder 'n "aanvaarbare" lisensie vir ons gevind het nie, het ek die Lazarus IDE weer bekendgestel. En ek het die nodige nut geskryf. Die invoer is die vereiste lys van voorwerpe en watter spesifieke navrae gemaak moet word, en in reaksie ontvang ek data. En dit alles in multi-threaded-modus. Groot.
Nadat ek pthreads vir PHP Windows opgestel het, het ek gedink dat alles dadelik sou begin, maar dit was nie die geval nie. Na 'n tyd van ontfouting het ek besef dat pthreads blykbaar werk, maar dit het nie op ons stelsel gewerk nie. Dit het duidelik geword dat daar 'n eienaardigheid is om met pthreads op Windows te werk. En so was dit. Ek het die dokumentasie gelees, en daar is geskryf dat vir Windows die aantal drade beperk is, en, sover ek onthou, implisiet. Dit het 'n probleem geword. Want toe ek die aantal drade waarop die toepassing geloop het begin verminder, het dit die werk baie stadig gedoen. Ek het die IDE weer oopgemaak en funksionaliteit vir multi-threaded ping van voorwerpe is by dieselfde nut gevoeg. Wel, daar is ook reeds baie poortskandering daar. Eintlik, hierna, het die behoefte aan pthreads vir PHP verdwyn, en dit word nie meer gebruik nie. Verder is nog verskeie funksies by hierdie hulpprogram gevoeg en dit werk tot vandag toe nog. Hierna is 'n installeerder vir Windows saamgestel, wat Apache, PHP, MariaDB, die PHP-toepassing self en 'n stel nutsprogramme vir interaksie met die stelsel ingesluit het, geskryf in Free Pascal. Wat die installeerder betref, het ek gedink dat ek hierdie probleem vinnig sou oplos, want ... Dit is 'n baie algemene ding en nodig vir byna elke sagteware. Óf ek het op die verkeerde plek gesoek, óf iets anders. Maar ek het gedurig op produkte afgekom wat óf nie buigsaam genoeg was nie, óf duur en ook onbuigsaam was. En tog het ek 'n gratis installeerder gevind waarin dit moontlik sal wees om in enige wense voorsiening te maak. Dit is InnoSetup. Ek skryf hieroor hieroor, want ek moes dit naslaan ingeval ek iemand tyd spaar.
Weiering van die inprop ten gunste van jou kliënt
Ek het voorheen geskryf dat die kliëntdeel 'n blaaier met 'n "plugin" was. Daar was dus tye wat Chrome opgedateer is en die uitleg 'n bietjie skeef was, toe is Windows opgedateer en die pasgemaakte uri-skema verdwyn. Ek wou regtig nie hierdie soort verrassings in die publieke weergawe van die produk hê nie. Boonop het die pasgemaakte uri na elke Windows-opdatering begin verdwyn. Microsoft het eenvoudig alle nie-sy takke in die vereiste afdeling uitgevee. Ook, Google Chrome laat jou nou nie toe om die keuse te onthou om 'n toepassing vanaf die pasgemaakte uri oop te maak of nie, en vra hierdie vraag elke keer as jy op 'n moniteringsvoorwerp klik. Wel, oor die algemeen was normale interaksie met die gebruiker se plaaslike stelsel nodig, wat die blaaier nie verskaf nie. Die eenvoudigste opsie in hierdie skema blyk te wees om bloot jou eie blaaier te maak, soos baie nou deur Electron doen. Maar baie dinge is reeds in Free Pascal geskryf, insluitend in die bedienergedeelte, so ons het besluit om die kliënt in dieselfde taal te maak, en nie 'n dieretuin te skep nie. Dit is hoe 'n kliënt met Chromium aan boord geskryf is. Daarna het dit verskeie bande begin kry.
Vrylating
Uiteindelik het ons 'n naam vir die stelsel gekies. Ons het voortdurend deur verskeie opsies gegaan terwyl die proses van omskakeling van die plaaslike weergawe na SaaS aan die gang was. Aangesien ons aanvanklik beplan het om nie net die plaaslike mark te betree nie, was die hoofkriterium vir die keuse van 'n naam die teenwoordigheid van 'n onbesette of nie baie duur domein in die ".com"-sone. Sommige funksies/modules is nog nie van die plaaslike weergawe na Veliam oorgedra nie, maar ons het besluit dat ons dit met die huidige funksionaliteit sal vrystel en die res as opdaterings voltooi. In die heel eerste weergawe was daar geen HelpDesk, Veliam Connector nie, dit was onmoontlik om die drempels vir kennisgewingsnellers te verander en nog baie meer. Ons het 'n kodetekensertifikaat gekoop en die kliënt- en bedieneronderdele onderteken. Ons het 'n webwerf vir die produk geskryf, prosedures begin vir die registrasie van sagteware, 'n handelsmerk, ens. Oor die algemeen is ons gereed om te begin. 'n Effense euforie van die werk wat gedoen is en van die feit dat iemand dalk jou produk sal gebruik, hoewel ons geen twyfel hieroor gehad het nie. En dan stop. Die vennoot het gesê dat dit onmoontlik is om die mark te betree sonder kennisgewings via boodskappers. Dit is moontlik sonder baie ander dinge, maar nie sonder dit nie. Na 'n paar debat is integrasie met Telegram bygevoeg, wat ons gepas het. Van al die huidige kitsboodskappers is dit die enigste een wat gratis toegang tot sy API's bied en sonder enige ingewikkelde goedkeuringsprosedures. Dieselfde WhatsApp stel voor om verskaffers te kontak wat goeie geld vra vir die gebruik van hul dienste, is geïgnoreer. Wel, Viber ... ek weet nie wie dit nou gebruik nie, want ... strooipos en advertensies daar is van die kaarte af. Einde Desember, na 'n reeks interne toetse en toetse onder vriende, is registrasie vir almal oopgemaak en die sagteware is beskikbaar gestel vir aflaai.
Begin van verspreiding
Van die begin af het ons verstaan dat ons 'n klein vloei van stelselgebruikers nodig het sodat hulle die produk in gevegsmodus kan toets en 'n paar eerste terugvoer kan gee. Verskeie aangekoopte poste op VK het vrugte afgewerp. Die eerste registrasies het aangebreek.
Hier moet gesê word dat dit baie moeilik is om die mark te betree wanneer u onderneming nie 'n bekende naam het nie, en terselfdertyd agentlose moniteringsfunksionaliteit verskaf waarin u rekeninge vanaf u bedieners en werkstasies moet invoer. Dit maak baie mense bang. Ons het van die begin af verstaan dat daar probleme hiermee sou wees en was beide tegnies en moreel voorbereid hiervoor. Alle afgeleë verbindings, ten spyte van die feit dat RDP en SSH reeds by verstek geïnkripteer is, word bykomend geïnkripteer deur ons sagteware met behulp van die AES-standaard. Alle data vanaf plaaslike bedieners word via HTTPS na die wolk oorgedra. Rekeninge word in geënkripteerde vorm gestoor. Enkripsiesleutels vir alle substelsels is individueel vir alle kliënte. Vir afgeleë verbindings word sessie-enkripsiesleutels gewoonlik gebruik.
Al wat ons in hierdie situasie kan doen om mense rustiger te laat voel, is om so oop as moontlik te wees, aan veiligheid te werk en nooit moeg te word om mense se vrae te beantwoord nie.
Vir baie is die gerief en funksionaliteit van die sagteware swaarder as die vrees, en hulle registreer. Sommige individue het in gepubliseerde plasings op VK geskryf dat hierdie sagteware nie gebruik kan word nie, want Dit is 'n versameling van hul wagwoorde en oor die algemeen 'n maatskappy sonder naam. Daar moet gesê word dat meer as een persoon hierdie mening gehad het. Baie mense verstaan eenvoudig nie dat wanneer hulle ander eie sagteware installeer op 'n bediener wat as 'n diens werk, dit ook volle regte in die stelsel het en hulle het nie rekeninge nodig om iets onwettigs te doen nie (dit is duidelik dat jy die gebruiker van wie die diens bekendgestel word, maar ook hier kan jy enige rekening invoer). Trouens, mense se vrese is verstaanbaar. Die installering van sagteware op 'n bediener is 'n algemene ding, maar om 'n rekening in te voer is 'n bietjie eng en intiem, aangesien 'n goeie helfte van mense dieselfde wagwoord vir alle dienste het, en die skep van 'n aparte rekening selfs vir 'n toets is lui. Maar op die oomblik is daar 'n groot aantal dienste wat mense vertrou met hul geloofsbriewe en meer. En ons streef daarna om een van hulle te word.
Daar was baie opmerkings wat gesê het ons het dit iewers gesteel. Dit het ons 'n bietjie verras. Wel, goed, die mening van een persoon, maar sulke opmerkings is gevind in verskeie publikasies van verskillende mense. Hulle het eers nie geweet hoe om hierop te reageer nie. Óf om hartseer te wees dat sommige mense die mening het dat niemand in Rusland iets op hul eie kan doen nie, maar net kan steel, óf om bly te wees dat hulle dink dat dit net gesteel kan word.
Ons het nou die prosedure voltooi vir die verkryging van 'n EV-kodetekensertifikaat. Om dit te bekom, moet jy deur 'n reeks tjeks gaan en 'n klomp dokumente oor die maatskappy stuur, waarvan sommige deur 'n prokureur gesertifiseer moet word. Die verkryging van 'n EV-kodetekensertifikaat tydens 'n pandemie is 'n aparte onderwerp vir 'n artikel. Die prosedure het 'n maand geneem. En dit was nie 'n maand van wag nie, maar van voortdurende versoeke vir bykomende dokumente. Miskien het die pandemie niks daarmee te doen gehad nie, en het die prosedure so lank vir almal geneem? Deel.
Sommige sê dat ons dit nie sal gebruik nie, want daar is geen FSTEC-sertifikaat nie. Ons moet verduidelik dat ons dit nie kan kry nie en nie sal kry nie, want om hierdie sertifikaat te verkry, moet enkripsie in ooreenstemming met GOST wees, en ons beplan om die sagteware nie net in Rusland te versprei en AES te gebruik nie.
Al hierdie opmerkings skep 'n mate van twyfel dat dit moontlik is om 'n produk te bevorder wat vereis dat jy rekeninge moet invoer sonder om in die openbaar bekend te wees. Al het ons geweet dat daar diegene sou wees wat 'n baie negatiewe houding hieroor gehad het. Nadat die aantal registrasies 'n duisend oorskry het, het ons opgehou om daaraan te dink. Veral nadat, benewens die negatiwiteit van diegene wat nie eers die produk probeer het nie, baie aangename resensies begin verskyn het. Daar moet gesê word dat hierdie positiewe resensies die grootste motiveerder vir produkontwikkeling is.
Voeg afgeleë toegangsfunksies by vir werknemers
Een van die gereelde take van kliënte is "gee Vanya toegang tot sy rekenaar van die huis af." Ons het VPN op Mikrotik geskep en rekeninge vir gebruikers geskep. Maar dit is 'n werklike probleem. Gebruikers kan nie na die instruksies kyk en dit stap vir stap volg om via VPN te koppel nie. Verskillende weergawes van Windows. In een Windows sluit alles goed aan, in 'n ander is 'n ander protokol nodig. En oor die algemeen was dit altyd geassosieer met die herkonfigurasie van netwerktoerusting, wat as 'n VPN-bediener opgetree het, en nie alle werknemers het toegang daartoe nie en dit was ongerieflik.
Maar ons het reeds afgeleë verbindings met bedieners en netwerktoerusting. Hoekom nie 'n gereedgemaakte vervoer gebruik en 'n aparte klein hulpmiddel maak wat jy eenvoudig aan die gebruiker kan gee om aan te sluit nie. Ek wou net seker maak dat die gebruiker niks abstruus daar ingevoer het nie. Net een knoppie "koppel". Maar hoe sal hierdie program verstaan waar om aan te sluit as dit net een knoppie het? Daar was 'n idee om die vereiste toepassing aanlyn op ons bedieners te bou. Die stelseladministrateur klik die "aflaai kortpad"-knoppie, en 'n opdrag word na ons wolk gestuur om 'n individuele binêre te bou met hardebedrade inligting om aan die verlangde bediener/rekenaar via RDP te koppel. Oor die algemeen kan dit gedoen word. Maar dit neem 'n lang tyd die administrateur sal eers moet wag totdat die binêre saamgestel is en dan afgelaai word. Natuurlik sou dit moontlik wees om eenvoudig 'n tweede lêer by te voeg met die config, maar dit is reeds 2 lêers, en vir eenvoud het die gebruiker een nodig. Een lêer, een knoppie en geen installeerders nie. Nadat ek 'n bietjie op Google gelees het, het ek tot die gevolgtrekking gekom dat as jy 'n bietjie inligting aan die einde van die saamgestelde ".exe" byvoeg, dit nie versleg nie (wel, amper). Jy kan ten minste oorlog en vrede daar byvoeg, en dit sal werk soos voorheen. Dit sal sonde wees om nie hieruit voordeel te trek nie. Nou kan jy eenvoudig die toepassing onderweg uitpak, direk in die kliënt self, soos dit Veliam Connector genoem word, en eenvoudig die inligting wat nodig is om daaraan te koppel aan die einde byvoeg. En die toepassing self weet wat om daarmee te doen. Hoekom het ek "wel amper" 'n bietjie hoër tussen hakies geskryf? Omdat jy vir hierdie gerief moet betaal deurdat die toepassing sy digitale handtekening verloor. Maar op hierdie stadium glo ons dat dit 'n klein prys is om vir sulke gerief te betaal.
Derdeparty-modulelisensies
Ek het reeds hierbo geskryf dat nadat daar besluit is om die produk publiek beskikbaar te stel, en nie net vir ons eie gebruik nie, ons hard moes werk en plaasvervangers moes soek vir sommige modules wat ons nie toegelaat het om in ons produk in te sluit nie. Maar na die vrylating is 'n baie onaangename ding per ongeluk ontdek. Veliam Server, wat aan die kliëntkant was, het die MariaDB DBMS ingesluit. En dit is GPL-gelisensieer. Die GPL-lisensie impliseer dat die sagteware oopbron moet wees, en as ons produk MariaDB insluit, wat hierdie lisensie het, dan moet ons produk onder hierdie lisensie wees. Maar gelukkig is die doel van hierdie lisensie oopbron, nie om diegene te straf wat per ongeluk foute in die hof maak nie. Indien die kopiereghouer 'n eis het, stel hy die oortreder skriftelik in kennis en moet hy die oortreding binne 30 dae uitskakel. Ons het self ons fout ontdek en geen briewe ontvang nie en het dadelik opsies begin oorweeg oor hoe om die probleem op te los. Die oplossing blyk voor die hand liggend te wees - skakel oor na SQLite. Hierdie databasis het geen lisensiebeperkings nie. Die meeste moderne blaaiers gebruik SQLite, en 'n klomp ander programme. Ek het inligting op die internet gekry dat SQLite as die mees wydverspreide DBMS in die wêreld beskou word, juis vanweë die blaaiers, maar ek het nie bewyse gesoek nie, so dit is onakkurate inligting. Ek het die gevare van oorskakeling na SQLite begin bestudeer.
Dit word 'n nie-triviale taak wanneer kliënte 'n paar honderd bedieners geïnstalleer het met MariaDB en data daarin. Sommige MariaDB-kenmerke is nie in SQLite beskikbaar nie. Wel, byvoorbeeld, in die kode het ons navrae gebruik soos
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Hierdie konstruksie maak nie net 'n keuse uit die tabel nie, maar sluit ook die rydata. En nog verskeie ontwerpe moes ook herskryf word. Maar benewens die feit dat ons baie navrae moes herskryf, moes ons ook met 'n meganisme vorendag kom wat, wanneer die kliënt se Veliam-bediener opgedateer word, al die data na die nuwe DBBS sou oordra en die ou een uitvee. Ook, transaksies in SQLite het nie gewerk nie en dit was 'n werklike probleem. Maar nadat ek die omvang van die wêreldwye web gelees het, het ek sonder enige probleme gevind dat transaksies in SQLite geaktiveer kan word deur 'n eenvoudige opdrag deur te gee wanneer u koppel
PRAGMA journal_mode=WAL;Gevolglik is die taak voltooi en nou loop die kliënt se bedienerdeel op SQLite. Ons het geen veranderinge in die werking van die stelsel opgemerk nie.
Nuwe Helpdesk
Dit was nodig om die HelpDesk-stelsel van die interne weergawe na die SaaS-weergawe oor te dra, maar met 'n paar veranderinge. Die eerste ding wat ek wou doen, was integrasie met die kliënt se domein in terme van deursigtige gebruikersmagtiging in die stelsel. Nou, om by HelpDesk aan te meld en 'n versoek in die stelsel te laat, klik die gebruiker eenvoudig op die kortpad op die lessenaar en die blaaier word oopgemaak. Die gebruiker voer geen geloofsbriewe in nie. Die module vir Apache SSPI, wat deel is van Veliam Server, magtig die gebruiker outomaties onder 'n domeinrekening. Om 'n versoek in die stelsel te laat wanneer die gebruiker buite die korporatiewe netwerk is, klik hy op 'n knoppie en hy ontvang 'n skakel in sy e-pos waardeur hy sonder wagwoorde by die HelpDesk-stelsel aanmeld. As 'n gebruiker in 'n domein gedeaktiveer of uitgevee word, sal die HelpDesk-rekening ook ophou werk. Die stelseladministrateur hoef dus nie self rekeninge in beide die domein en HelpDesk te monitor nie. 'n Werknemer stop - hy ontkoppel sy rekening in die domein en dis dit, hy sal nie by die stelsel aanmeld nie vanaf die korporatiewe netwerk nie, nie via 'n skakel nie. Vir hierdie integrasie om te werk, moet die stelseladministrateur een GPO skep, wat и .
Die tweede ding wat ons uiters noodsaaklik ag vir HelpDesk-stelsels, ten minste vir onsself, is om direk vanaf die toepassing met een klik met die aansoeker te koppel. Boonop moet verbindings slaag as die stelseladministrateur op 'n ander netwerk is. Vir uitkontraktering is dit verpligtend, vir voltydse stelseladministrateurs is dit ook dikwels baie nodig. Daar is reeds verskeie produkte wat 'n uitstekende werk van afstandverbindings doen. En ons het besluit om integrasies vir hulle te maak. Ons het nou vir VNC geïntegreer, en in die toekoms beplan ons om Radmin en TeamViewer by te voeg. Deur ons netwerkvervoer vir afgeleë infrastruktuurverbindings te gebruik, het ons VNC aan afgeleë werkstasies agter NAT laat koppel. Dieselfde sal met Radmin gebeur. Nou, om aan 'n gebruiker te koppel, hoef jy net op die "koppel aan aansoeker"-knoppie in die toepassing self te klik. Die VNC-kliënt maak oop en koppel aan die aansoeker, ongeag of jy op dieselfde netwerk is of met pantoffels by die huis sit. Eerstens moet die stelseladministrateur, wat GPO gebruik, VNC Server op almal se werkstasies installeer.
Nou skakel ons self oor na die nuwe HelpDesk en gebruik integrasie met die domein en VNC. Dit is baie gerieflik vir ons. Nou kan ons vermy om vir TeamViewer te betaal, wat ons al meer as drie jaar gebruik om ons ondersteuningsdiens te bedryf.
Wat beplan ons om volgende te doen?
Toe ons die produk vrygestel het, het ons geen betaalde tariewe gemaak nie, maar bloot die gratis tarief beperk tot 50 moniteringsvoorwerpe. Vyf dosyn netwerktoestelle en bedieners behoort genoeg te wees vir almal, het ons gedink. En toe begin versoeke inkom om die limiet te verhoog. Om te sê dat ons 'n bietjie geskok was, is om niks te sê nie. Stel maatskappye wat soveel bedieners het regtig in ons sagteware belang? Ons het die limiet gratis verleng vir diegene wat sulke versoeke gerig het. In reaksie op hul versoek het ons sommige gevra hoekom hulle so nodig het, het hulle werklik so 'n groot aantal bedieners en netwerktoerusting. En dit het geblyk dat stelseladministrateurs die stelsel begin gebruik het op maniere wat ons glad nie beplan het nie. Alles blyk eenvoudig te wees - ons sagteware het nie net bedieners begin monitor nie, maar ook werkstasies. Daarom is daar baie versoeke om limiete uit te brei. Nou het ons reeds betaalde tariewe ingestel en die perke kan onafhanklik uitgebrei word.
Bedieners werk byna altyd met óf bergingstelsels óf plaaslike skywe in 'n RAID-skikking. En ons het aanvanklik die produk vir hulle gemaak. En SMART-monitering was nie interessant vir hierdie taak nie. Maar met inagneming van die feit dat mense sagteware vir die monitering van werkstasies aangepas het, het versoeke vir die implementering van SMART-monitering verskyn. Ons sal dit binnekort implementeer.
Met die koms van Veliam Connector het dit onnodig geword om 'n VPN-bediener in die korporatiewe netwerk te ontplooi, of RDGW te doen, of bloot poorte aan te stuur na die nodige masjiene om via RDP te koppel. Baie mense gebruik ons stelsel net vir hierdie afgeleë verbindings. Veliam Connector is slegs beskikbaar vir Windows, en sommige maatskappygebruikers koppel van tuisskootrekenaars met MacOS na werkstasies of terminale op die korporatiewe netwerk. En dit blyk dat die stelseladministrateur gedwing word, as gevolg van verskeie gebruikers, om steeds terug te keer na die kwessie van aanstuur of VPN. Daarom maak ons nou klaar met die maak van 'n weergawe van Veliam Connector vir MacOS. Gebruikers van hul gunsteling Apple-tegnologie sal ook die geleentheid kry om met een klik aan die korporatiewe infrastruktuur te koppel.
Ek hou baie van die feit dat, met 'n groot aantal stelselgebruikers, jy nie hoef te dink oor wat mense nodig het en wat geriefliker sal wees nie. Hulle skryf self hul wense, so daar is baie ontwikkelingsplanne vir die nabye toekoms.
Terselfdertyd beplan ons nou om die stelsel in Engels te begin vertaal en in die buiteland te versprei. Ons weet nog nie hoe ons die produk buite ons land gaan versprei nie, ons soek opsies. Miskien sal daar later 'n aparte artikel hieroor wees. Miskien sal iemand wat hierdie artikel gelees het die vereiste vektor kan voorstel, of hy weet en weet self hoe om dit te doen en sal sy dienste aanbied. Ons sal u hulp waardeer.
Bron: will.com