В , beszéltem a Veliam létrehozásának hátteréről és arról a döntésről, hogy a SaaS rendszeren keresztül terjesztem. Ebben a cikkben arról fogok beszélni, hogy mit kellett tennem, hogy a termék ne helyi legyen, hanem nyilvános legyen. Arról, hogyan kezdődött a terjesztés és milyen problémákkal találkoztak.
Планирование
A felhasználók jelenlegi háttérrendszere Linuxon volt. Szinte minden szervezet rendelkezik Windows szerverrel, ami nem mondható el a Linuxról. A Veliam fő erőssége a NAT mögötti szerverekhez és hálózati berendezésekhez való távoli kapcsolatok. De ez a funkció nagyon szorosan kötődött ahhoz, hogy a routernek Mikrotiknak kellett lennie. Ez pedig nyilván sokakat nem elégítene ki. Először a leggyakoribb gyártók útválasztóinak támogatásán kezdtem el gondolkodni. De megértettem, hogy ez egy végtelen versenyfutás a támogatott cégek listájának bővítéséért. Ezenkívül a már támogatottak eltérő parancskészlettel rendelkeznek a NAT-szabályok modellenkénti módosításához. Az egyetlen kiút a helyzetből a VPN volt.
Mivel úgy döntöttünk, hogy a terméket terjesztjük, de nem nyílt forráskódúként, lehetetlenné vált, hogy különféle nyílt licencekkel rendelkező könyvtárakat, például GPL-t tegyünk bele. Ez általában egy külön téma, miután meghoztam a döntést a termék eladásáról, a könyvtárak felét kellett végigjárnom, mert GPL-esek. Amikor maguknak írtak, az normális volt. De nem alkalmas terjesztésre. Az első VPN, ami eszünkbe jut, az OpenVPN. De ez GPL. Egy másik lehetőség a japán SoftEther VPN használata volt. Az engedélye lehetővé tette számára, hogy beépítse a termékébe. Néhány napos különféle tesztek után, hogyan lehet integrálni úgy, hogy a felhasználónak egyáltalán ne kelljen konfigurálnia és ismernie kell a SoftEther VPN-t, prototípust kaptunk. Minden úgy volt, ahogy lennie kell. De valamiért ez a rendszer még mindig összezavart minket, és végül feladtuk. De természetesen visszautasították, miután más lehetőséget találtak ki. Végül minden normál TCP-kapcsolaton történt. Egyes kapcsolatok koordinátoron keresztül működnek, mások közvetlenül a Nat Hole Punching (NHP) technológián keresztül, amelyet a Free Pascalban is implementáltak. Azt kell mondanom, hogy korábban még csak nem is hallottam az NHP-ről. És eszembe sem jutott, hogy 2 hálózati eszközt lehetett csatlakoztatni, mindkettő közvetlenül a NAT mögött van. Tanulmányoztam a témát, megértettem a működési elvet és leültem írni. A terv megvalósul, a felhasználó egy kattintással csatlakozik a kívánt NAT mögötti eszközhöz RDP-n, SSH-n vagy Winboxon keresztül jelszó megadása és VPN beállítása nélkül. Sőt, ezeknek a kapcsolatoknak a többsége túlmegy a koordinátorunkon, ami jó hatással van a ping-re és a kapcsolatok kiszolgálásának költségeire.
A szerverrész átvitele Linuxról Windowsra
A Windows rendszerre váltáskor több probléma is adódott. Az első az, hogy a windowsba beépített wmic nem teszi lehetővé a WQL lekérdezések végrehajtását. És a mi rendszerünkben már minden rájuk épült. És volt még valami, de most már elfelejtettem, miért hagyták el végül a használatát. Lehetséges különbségek a Windows verziók között. A második probléma pedig a többszálúság. Mivel nem találtam egy jó harmadik féltől származó segédprogramot a számunkra „elfogadható” licenc alatt, újra elindítottam a Lazarus IDE-t. És megírtam a szükséges segédprogramot. A bemenet a szükséges objektumok listája, és hogy milyen konkrét lekérdezéseket kell végrehajtani, válaszul adatokat kapok. És mindezt többszálas módban. Nagy.
Miután beállítottam a pthreadeket a PHP Windowshoz, azt hittem, hogy minden azonnal elindul, de nem így történt. Némi hibakeresés után rájöttem, hogy a pthreadek működni látszanak, de a rendszerünkön nem működtek. Világossá vált, hogy van néhány sajátosság a pthread-ekkel való munkában a Windows rendszeren. És így is lett. Elolvastam a dokumentációt, ott az volt írva, hogy a Windows esetében limitált a szálak száma, és ha jól emlékszem, implicit. Ebből probléma lett. Mert amikor elkezdtem csökkenteni a szálak számát, amin az alkalmazás futott, nagyon lassan tette a dolgát. Újra megnyitottam az IDE-t, és ugyanahhoz a segédprogramhoz hozzáadták az objektumok többszálú pingelésének funkcióját. Nos, ott is sok port szkennelés van. Valójában ezek után megszűnt a PHP pthread-szükséglete, és már nem használják. Ezenkívül számos további funkciót adtunk ehhez a segédprogramhoz, és a mai napig működik. Ezt követően összeállítottak egy Windows-telepítőt, amely tartalmazta az Apache-t, a PHP-t, a MariaDB-t, magát a PHP-alkalmazást és a rendszerrel való interakcióhoz szükséges segédprogramokat, Free Pascal-ban. A telepítővel kapcsolatban arra gondoltam, hogy gyorsan megoldom ezt a problémát, mert... Ez egy nagyon gyakori dolog, és szinte minden szoftverhez szükséges. Vagy rossz helyen kerestem, vagy valami mást. De folyamatosan találkoztam olyan termékekkel, amelyek vagy nem voltak elég rugalmasak, vagy drágák és rugalmatlanok is. És mégis találtam egy ingyenes telepítőt, amelyben bármilyen kívánság teljesíthető. Ez az InnoSetup. Azért írok erről itt, mert utána kellett néznem, hátha valakinek időt spórolok.
A bővítmény elutasítása az ügyfele javára
Korábban írtam, hogy a kliens rész egy „plugin”-es böngésző volt. Így előfordult, hogy a Chrome-ot frissítették, és az elrendezés kissé ferde volt, majd a Windows frissítése és az egyéni uri-séma eltűnt. Nagyon nem akartam, hogy ilyen meglepetések legyenek a termék nyilvános verziójában. Sőt, az egyéni uri kezdett eltűnni minden Windows frissítés után. A Microsoft egyszerűen törölte az összes nem saját ágát a szükséges részben. Ezenkívül a Google Chrome most nem teszi lehetővé, hogy megjegyezze, hogy az egyéni uri-ból meg kell-e nyitni vagy sem egy alkalmazást, és minden alkalommal felteszi ezt a kérdést, amikor egy megfigyelő objektumra kattint. Nos, általában normális interakcióra volt szükség a felhasználó helyi rendszerével, amelyet a böngésző nem biztosít. Ebben a sémában a legegyszerűbb megoldásnak az tűnik, ha egyszerűen elkészíti a saját böngészőjét, ahogy azt sokan most az Electronon keresztül teszik. De sok minden meg volt már írva a Free Pascalban, így a szerver rész is, ezért úgy döntöttünk, hogy a klienst ugyanazon a nyelven készítjük el, nem pedig állatkertet. Így készült egy Chromiummal rendelkező kliens. Ezt követően különféle pántokat kezdett beszerezni.
Kiadás
Végül nevet választottunk a rendszernek. Folyamatosan különböző lehetőségeken mentünk keresztül, miközben a helyi verzióról SaaS-re való átállás folyamatban volt. Mivel eleinte nem csak a hazai piacra terveztünk belépni, a névválasztás fő szempontja az volt, hogy a „.com” zónában legyen egy üres vagy nem túl drága domain. Egyes funkciók/modulok még nem kerültek át a helyi verzióból a Veliamba, de úgy döntöttünk, hogy kiadjuk őket a jelenlegi funkcionalitással, a többit pedig frissítésként egészítjük ki. A legelső verzióban nem volt HelpDesk, Veliam Connector, lehetetlen volt megváltoztatni az értesítési triggerek küszöbértékeit és még sok mást. Vásároltunk egy Code Sign Certificate tanúsítványt, és aláírtuk a kliens és a szerver részeket. Weboldalt írtunk a termékhez, megkezdtük a szoftverek, védjegyek stb. regisztrálásának folyamatát. Általában készen állunk a kezdésre. Enyhe eufória az elvégzett munkától és attól, hogy esetleg valaki használni fogja a termékét, bár efelől nem volt kétségünk. És akkor állj meg. A partner szerint messengeren keresztüli értesítés nélkül lehetetlen piacra lépni. Sok minden más nélkül is lehetséges, de e nélkül nem. Némi vita után hozzáadták a Telegram-integrációt, ami nekünk megfelelt. Az összes jelenlegi azonnali üzenetküldő közül ez az egyetlen, amely ingyenes hozzáférést biztosít API-jához, bonyolult jóváhagyási eljárások nélkül. Ugyanez a WhatsApp azt javasolja, hogy vegye fel a kapcsolatot azokkal a szolgáltatókkal, akik jó pénzt kérnek szolgáltatásaik használatáért; minden tömítés nélküli hozzáférést kérő levelet figyelmen kívül hagytak. Nos, Viber... Nem tudom, ki használja most, mert... a spam és az ottani reklámok lekerültek a listáról. December végén egy sor belső teszt és baráti teszt után mindenki számára megnyílt a regisztráció, és letölthetővé tették a szoftvert.
Elosztás kezdete
Már a kezdetektől fogva megértettük, hogy szükségünk van egy kis rendszerhasználói körre, hogy harci módban tesztelhessék a terméket és első visszajelzést adhassanak. A VK-n több megvásárolt bejegyzés meghozta gyümölcsét. Megérkeztek az első regisztrációk.
Itt el kell mondani, hogy nagyon nehéz belépni a piacra, ha a cégének nincs híres neve, és ugyanakkor ügynök nélküli felügyeleti funkcionalitást biztosítani, amelyben fiókokat kell megadnia a szerverekről és a munkaállomásokról. Ez sok embert megijeszt. Már az elejétől fogva megértettük, hogy ezzel gondok lesznek, és felkészültünk erre mind technikailag, mind erkölcsileg. Minden távoli kapcsolat, annak ellenére, hogy az RDP és az SSH alapértelmezés szerint titkosítva van, a szoftverünk az AES szabványt használva tovább titkosítja. A helyi szerverekről minden adat HTTPS-en keresztül kerül átvitelre a felhőbe. A fiókokat titkosított formában tároljuk. A titkosítási kulcsok minden alrendszerhez egyediek minden ügyfél számára. A távoli kapcsolatokhoz általában munkamenet-titkosítási kulcsokat használnak.
Ebben a helyzetben csak annyit tehetünk, hogy az emberek nyugodtabbnak érezzék magukat, hogy a lehető legnyitottabbak legyünk, dolgozunk a biztonságon, és soha nem fáradunk el az emberek kérdéseinek megválaszolásával.
Sokak számára a szoftver kényelme és funkcionalitása felülmúlja a félelmet, és regisztrálnak. Egyesek a VK-n közzétett bejegyzésekben azt írták, hogy ez a szoftver nem használható, mert Ez a jelszavaik gyűjteménye, és általában egy név nélküli cég. Azt kell mondanunk, hogy nem egy embernek volt ez a véleménye. Sokan egyszerűen nem értik, hogy amikor más szabadalmaztatott szoftvert telepítenek egy szolgáltatásként működő szerverre, akkor annak is teljes joga van a rendszerben, és nincs szükségük fiókokra illegális műveletekhez (egyértelmű, hogy módosíthatja a felhasználó, akitől a szolgáltatás elindult, de itt is bármilyen fiókot megadhat). Valójában az emberek félelme érthető. Szoftver telepítése a szerverre megszokott dolog, de a fiókba belépés kicsit ijesztő és intim, hiszen az emberek jó felének minden szolgáltatáshoz ugyanaz a jelszava, külön fiók létrehozása pedig még egy teszthez is lusta. Jelenleg azonban rengeteg olyan szolgáltatás létezik, amelyekben az emberek megbíznak a hitelesítő adataikkal és még sok mással. Mi pedig arra törekszünk, hogy azok közé tartozzunk.
Sok hozzászólás érkezett arról, hogy valahol elloptuk. Ez kicsit meglepett minket. Nos, oké, egy személy véleménye, de ilyen megjegyzéseket különböző emberek különböző kiadványaiban találtak. Először nem tudták, hogyan reagáljanak erre. Vagy szomorúnak lenni azon, hogy egyesek azon a véleményen vannak, hogy Oroszországban senki nem tud egyedül csinálni semmit, csak lopni tud, vagy örülni annak, hogy azt hiszik, ezt csak lopni lehet.
Mostanra befejeztük az EV Code Sign Certificate megszerzésének folyamatát. Ennek megszerzéséhez egy sor ellenőrzésen kell keresztülmennie, és el kell küldenie egy csomó dokumentumot a cégről, amelyek egy részét ügyvédi igazolással kell ellátni. Az EV Code Sign tanúsítvány megszerzése világjárvány idején egy cikk külön témája. Az eljárás egy hónapig tartott. És ez nem egy hónapnyi várakozás volt, hanem folyamatos további dokumentumok kérése. Lehet, hogy a járványnak semmi köze nem volt hozzá, és mindenkinél ilyen sokáig tartott az eljárás? Ossza meg.
Egyesek azt mondják, hogy nem fogjuk használni, mert nincs FSTEC tanúsítvány. El kell magyaráznunk, hogy nem tudjuk megszerezni, és nem is fogjuk, mert a tanúsítvány megszerzéséhez a titkosításnak meg kell felelnie a GOST-nak, és a szoftvert nem csak Oroszországban tervezzük terjeszteni, és az AES-t használni.
Mindezek a megjegyzések kétségbe vonják, hogy lehetséges-e olyan termék reklámozása, amelyhez fiókok megadása szükséges anélkül, hogy nyilvánosan ismertté válna. Annak ellenére, hogy tudtuk, hogy lesznek, akik nagyon negatívan viszonyulnak ehhez. Miután a regisztrációk száma meghaladta az ezret, már nem gondoltunk rá. Különösen azután, hogy azok negativitása mellett, akik még nem is próbálták a terméket, nagyon kellemes vélemények kezdtek megjelenni. Azt kell mondanunk, hogy ezek a pozitív vélemények a termékfejlesztés legnagyobb motivációi.
Távoli hozzáférési funkciók hozzáadása az alkalmazottak számára
Az ügyfelek egyik gyakori feladata, hogy „adjon hozzáférést Ványának otthonról a számítógépéhez”. Megemeltük a VPN-t a Mikrotikon, és fiókokat hoztunk létre a felhasználók számára. De ez valós probléma. A felhasználók nem nézhetik meg az utasításokat, és nem követhetik azokat lépésről lépésre a VPN-en keresztüli csatlakozáshoz. A Windows különböző verziói. Az egyik Windowsban minden jól kapcsolódik, a másikban más protokollra van szükség. És általában ez mindig a hálózati berendezések újrakonfigurálásával járt, amelyek VPN-kiszolgálóként működtek, és nem minden alkalmazott fér hozzá, és ez kényelmetlen volt.
De már van távoli kapcsolatunk a szerverekkel és a hálózati berendezésekkel. Miért ne használjon kész transzportot, és készítsen egy külön kis segédprogramot, amelyet egyszerűen megadhat a felhasználónak a csatlakozáshoz. Csak meg akartam győződni arról, hogy a felhasználó nem ír be semmi elgondolkodtatót. Csak egy gomb a "csatlakozás". De hogyan fogja ez a segédprogram megérteni, hogy hova kell csatlakozni, ha csak egy gombja van? Volt egy ötlet, hogy a szervereinken online építsük fel a szükséges alkalmazást. A rendszeradminisztrátor rákattint a „letöltési parancsikon” gombra, és a rendszer egy parancsot küld a felhőnkbe, hogy hozzon létre egy egyedi bináris fájlt vezetékes adatokkal a kívánt szerverhez/számítógéphez RDP-n keresztül történő csatlakozáshoz. Általában ezt meg lehet tenni. Ez azonban sokáig tart; az adminisztrátornak először meg kell várnia a bináris lefordítását, majd letöltését. Természetesen lehetőség lenne egyszerűen hozzáadni egy második fájlt a konfigurációval, de ez már 2 fájl, és az egyszerűség kedvéért egy kell a felhasználónak. Egy fájl, egy gomb és nincs telepítő. Kicsit Google-n olvasgatva arra a következtetésre jutottam, hogy ha a lefordított “.exe” végéhez adunk némi információt, akkor az nem romlik (na jó, majdnem). Legalább háborút és békét adhat hozzá, és úgy fog működni, mint korábban. Bűn lenne ezt nem kihasználni. Most már egyszerűen kicsomagolhatja az alkalmazást útközben, közvetlenül a kliensben, ahogyan azt Veliam Connectornak hívják, és a végén egyszerűen hozzáadhatja a hozzá való csatlakozáshoz szükséges információkat. És maga az alkalmazás tudja, mit kell vele kezdeni. Miért írtam kicsit feljebb zárójelbe, hogy „jól majdnem”? Mert ezért a kényelemért fizetni kell annyiban, hogy az alkalmazás elveszti digitális aláírását. Jelenleg azonban úgy gondoljuk, hogy ez csekély ár az ilyen kényelemért.
Harmadik fél modullicencei
Fentebb már írtam, hogy miután elhatározták, hogy nyilvánosan is elérhetővé tesszük a terméket, és nem csak saját használatra, keményen kellett dolgoznunk, és cserét kellett keresnünk néhány olyan modulhoz, amely nem engedte bekerülni a termékünkbe. Ám a megjelenés után véletlenül egy nagyon kellemetlen dolgot fedeztek fel. A kliens oldalon lévő Veliam Server tartalmazta a MariaDB DBMS-t. És GPL licenccel rendelkezik. A GPL licenc azt jelenti, hogy a szoftvernek nyílt forráskódúnak kell lennie, és ha termékünk tartalmazza a MariaDB-t, amely rendelkezik ezzel a licenccel, akkor termékünknek ezen licenc alatt kell lennie. De szerencsére ennek a licencnek a célja a nyílt forráskód, nem az, hogy megbüntesse azokat, akik véletlenül hibáznak a bíróságon. Ha a szerzői jog jogosultja igényt tart, írásban értesíti a jogsértőt, aki a jogsértést 30 napon belül köteles megszüntetni. Mi magunk fedeztük fel a hibánkat, és nem kaptunk levelet, és azonnal elkezdtük mérlegelni a probléma megoldásának lehetőségeit. A megoldás kézenfekvőnek bizonyult - váltson SQLite-ra. Ennek az adatbázisnak nincsenek licenckorlátozásai. A legtöbb modern böngésző SQLite-ot és egy csomó más programot használ. Az interneten találtam olyan információt, hogy az SQLite a világ legelterjedtebb DBMS-ének számít, pont a böngészők miatt, de nem kerestem bizonyítékot, így ez pontatlan információ. Elkezdtem tanulmányozni az SQLite-ra váltás veszélyeit.
Ez nem triviális feladattá válik, ha a klienseken több száz szerver van telepítve MariaDB-vel és adatokkal. Néhány MariaDB-funkció nem érhető el az SQLite-ban. Nos, például a kódban olyan lekérdezéseket használtunk, mint pl
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Ez a konstrukció nem csak a táblázatból választ, hanem a soradatokat is zárolja. És még több tervet is át kellett írni. De amellett, hogy rengeteg lekérdezést kellett átírnunk, ki kellett találnunk egy olyan mechanizmust is, amely a kliens Veliam Serverének frissítésekor minden adatot az új DBMS-re portol, a régit pedig törli. Ezenkívül az SQLite tranzakciói nem működtek, és ez valódi probléma volt. De miután elolvastam a hatalmas világhálót, minden probléma nélkül rájöttem, hogy az SQLite-ban a tranzakciók engedélyezhetők egy egyszerű parancs átadásával csatlakozáskor
PRAGMA journal_mode=WAL;Ennek eredményeként a feladat befejeződött, és most az ügyfél szerver része fut SQLite-on. A rendszer működésében változást nem észleltünk.
Új HelpDesk
A HelpDesk rendszert át kellett vinni a belső verzióról a SaaS verzióra, de némi változtatással. Az első dolog, amit meg akartam tenni, a kliens domainjével való integráció volt a rendszerben való átlátható felhasználói jogosultság szempontjából. Most, hogy bejelentkezzen a HelpDeskbe és kérést hagyjon a rendszerben, a felhasználó egyszerűen rákattint az asztalon lévő parancsikonra, és megnyílik a böngésző. A felhasználó nem ad meg hitelesítő adatokat. Az Apache SSPI modulja, amely a Veliam Server része, automatikusan engedélyezi a felhasználót egy tartományfiók alatt. Kérést hagyni a rendszerben, amikor a felhasználó a vállalati hálózaton kívül tartózkodik, rákattint egy gombra, és e-mailjében kap egy linket, amelyen keresztül jelszavak nélkül bejelentkezik a HelpDesk rendszerbe. Ha egy felhasználót letiltanak vagy törölnek egy tartományban, akkor a HelpDesk-fiók is leáll. Így a rendszergazdának nem kell magának a tartományban és a HelpDeskben is figyelnie a fiókokat. Egy alkalmazott kilép - leválasztja fiókját a domainben, és ennyi, nem fog bejelentkezni a rendszerbe nem a vállalati hálózatról, nem linken keresztül. Ahhoz, hogy ez az integráció működjön, a rendszergazdának létre kell hoznia egy csoportházirend-objektumot, amely и .
A második dolog, amit rendkívül szükségesnek tartunk a HelpDesk rendszerek számára, legalábbis saját magunk számára, hogy egy kattintással közvetlenül az alkalmazásból kapcsolódjunk a jelentkezőhöz. Ezenkívül a kapcsolatoknak át kell menniük, ha a rendszergazda egy másik hálózaton van. Az outsourcingnál ez kötelező, a főállású rendszergazdáknál gyakran nagyon is szükséges. Már számos olyan termék létezik, amely kiválóan teljesíti a távoli kapcsolatokat. És úgy döntöttünk, hogy integráljuk őket. Mostanra integráltuk a VNC-t, és a jövőben tervezzük a Radmin és a TeamViewer hozzáadását. Hálózati átvitelünk segítségével távoli infrastrukturális kapcsolatokhoz a VNC-t a NAT mögötti távoli munkaállomásokhoz kötöttük. Ugyanez fog történni Radminnal is. Most, hogy csatlakozzon egy felhasználóhoz, csak rá kell kattintania magában az alkalmazásban a „csatlakozás a kérelmezőhöz” gombra. A VNC kliens megnyílik és csatlakozik a jelentkezőhöz, függetlenül attól, hogy ugyanazon a hálózaton vagy otthon ülsz papucsban. Először is, a rendszergazdának a GPO használatával telepítenie kell a VNC-kiszolgálót mindenki munkaállomására.
Most mi magunk váltunk át az új HelpDeskre, és integráljuk a tartományt és a VNC-t. Ez nagyon kényelmes számunkra. Most elkerülhetjük, hogy fizessünk a TeamViewerért, amelyet több mint három éve használunk támogatási szolgáltatásunk működtetésére.
Mit tervezünk ezután?
A termék kiadásakor nem állítottunk fel fizetős tarifákat, hanem 50 felügyeleti objektumra korlátoztuk az ingyenes tarifát. Öt tucat hálózati eszköznek és szervernek mindenkinek elégnek kell lennie – gondoltuk. Aztán elkezdtek érkezni kérések a limit növelésére. Ha azt mondjuk, hogy egy kicsit megdöbbentünk, akkor nem mondunk semmit. Valóban érdeklődnek a szoftvereink iránt a sok szerverrel rendelkező cégek? Ingyenesen meghosszabbítottuk a limitet azoknak, akik ilyen kérelmet nyújtottak be. Megkeresésükre néhányan megkérdeztük, miért van szükségük ennyire, valóban van-e ilyen sok szerverük és hálózati eszközük. És kiderült, hogy a rendszergazdák olyan módon kezdték használni a rendszert, ahogyan mi egyáltalán nem terveztük. Minden egyszerűnek bizonyult - szoftverünk nemcsak a szervereket, hanem a munkaállomásokat is figyelni kezdte. Ezért számos kérés van a limitek bővítésére. Most már bevezettük a fizetős tarifákat, és a limitek önállóan bővíthetők.
A kiszolgálók szinte mindig tárolórendszerekkel vagy RAID-tömbben lévő helyi lemezekkel működnek. És kezdetben nekik készítettük el a terméket. A SMART monitorozás pedig nem volt érdekes ehhez a feladathoz. De figyelembe véve azt a tényt, hogy az emberek szoftvereket adaptáltak a munkaállomások megfigyelésére, kérések jelentek meg a SMART felügyelet megvalósítására. Hamarosan megvalósítjuk.
A Veliam Connector megjelenésével szükségtelenné vált VPN szervert telepíteni a vállalati hálózatba, vagy RDGW-t csinálni, vagy egyszerűen csak továbbítani a portokat a szükséges gépekre az RDP-n keresztüli csatlakozáshoz. Sokan csak ezekhez a távoli kapcsolatokhoz használják rendszerünket. A Veliam Connector csak Windows rendszeren érhető el, és néhány vállalati felhasználó MacOS-t futtató otthoni laptopjáról csatlakozik a vállalati hálózat munkaállomásaihoz vagy termináljaihoz. És kiderül, hogy a rendszergazda több felhasználó miatt kénytelen mégis visszatérni a továbbítás vagy a VPN kérdéséhez. Ezért most befejezzük a Veliam Connector MacOS-verziójának elkészítését. Kedvenc Apple-technológiájuk felhasználóinak lehetőségük lesz egyetlen kattintással csatlakozni a vállalati infrastruktúrához.
Nagyon szeretem, hogy sok rendszerfelhasználó mellett nem kell azon törni a fejét, mire van szüksége az embereknek, és mi lesz a kényelmesebb. Ők maguk írják le kívánságukat, így rengeteg fejlesztési terv van a közeljövőre.
Ezzel párhuzamosan most azt tervezzük, hogy megkezdjük a rendszer angolra fordítását és külföldre történő terjesztését. Még nem tudjuk, hogyan terjesztjük a terméket hazánkon kívül, keressük a lehetőségeket. Erről talán később lesz egy külön cikk. Talán valaki, aki elolvasta ezt a cikket, tudja javasolni a szükséges vektort, vagy ő maga tudja és tudja, hogyan kell csinálni, és felajánlja szolgáltatásait. Nagyra értékelnénk a segítségét.
Forrás: will.com