A , beszéltem a Veliam létrejöttének hátteréről és a SaaS rendszer szerinti elosztásának megoldásáról. Ebben a cikkben arról fogok beszélni, mit kellett tennem ahhoz, hogy a termék ne helyi, hanem nyilvános legyen. Arról, hogyan indult a terjesztés és milyen problémákkal szembesültünk.
Tervezés
A felhasználók számára elérhető aktuális szerveroldal Linuxon futott. Szinte minden szervezetnek vannak Windows szerverei, amit nem mondhatunk el a Linuxról. A Veliam fő erőssége a távoli kapcsolatok létrehozása szerverekhez és a NAT mögötti hálózati berendezésekhez. De ez a funkció nagyon szigorúan a MikroTik routerekhez volt kötve. Nyilvánvalóan ez sokaknak nem lenne megfelelő. Először azt gondoltam, hogy hozzá kellene adnunk a legelterjedtebb gyártók routereinek támogatását. De tudtam, hogy ez egy végtelen verseny lenne a támogatott cégek listájának bővítésével. Továbbá, azok a modellek, amelyek már támogatottak, is különböző NAT szabályok módosítására vonatkozó parancsokkal rendelkezhetnek a változók között. Az egyetlen megoldás, amit láttam, a VPN volt.
Mivel úgy döntöttünk, hogy a terméket forgalmazzuk, de nem mint nyílt forrású szoftvert, így lehetetlenné vált különböző, GPL licenc alatt elérhető könyvtárakat is magában foglalni. Ez egy teljesen külön téma, a termék eladásáról hozott döntést követően át kellett néznünk a könyvtárak felét, mivel GPL licenc alatt álltak. Amikor saját magunknak fejlesztettük, az rendben volt. De terjesztéshez nem megfelelő. Az első, ami eszembe jut, a OpenVPN. De az GPL. Volt egy másik lehetőség, a japán SoftEther VPN használata. Az ő licencük lehetővé tette, hogy beilleszkedjen a saját termékünkbe. Pár napos tesztelés után, hogy hogyan integráljuk úgy, hogy a felhasználónak semmit ne kelljen beállítania vagy tudnia a SoftEther VPN-ről — elkészült a prototípus. Minden rendben volt. De valamiért ez a séma mégis kényelmetlen volt számunkra, és végül elvetettük. Persze csak azután mondtunk le róla, hogy kitaláltunk egy másik megoldást. Végül minden normál TCP kapcsolatokat használt. A kapcsolatok egy része koordinátoron keresztül, másik része közvetlenül a Nat Hole Punching (NHP) technológia segítségével, amely szintén Free Pascal-on lett megvalósítva. Azt kell mondanom, hogy korábban az NHP-ről még nem hallottam. Eszembe sem jutott volna, hogy két NAT mögötti hálózati eszközt közvetlenül összekapcsolhatunk. Áttekintettem a témát, megértettem a működési elvet, és elkezdtem írni. Amit megálmodtunk, megvalósult, a felhasználó egy kattintással kapcsolódik a szükséges NAT mögötti eszközhöz RDP, SSH vagy Winbox segítségével, a jelszavak megadása és a VPN beállítása nélkül. Ráadásul ezeknek a kapcsolatoknak a nagy része elkerüli a koordinátorunkat, ami jól hat a pingre és a kapcsolatok fenntartási költségeire.
A szerveroldali átállás Linuxról Windowsra
Több probléma merült fel a Windowsra való átállás során. Az első — a beépített wmic a Windowsban nem teszi lehetővé WQL lekérdezések végrehajtását. A mi rendszerünk már minden erre épült. Volt még valami, de most nem emlékszem, hogy végül miért mondtunk le a használatáról. Lehet, hogy a Windows verziók közötti eltérések miatt. A második probléma — a több szál kezelés. Miután nem találtam jó külső eszközt az "elfogadható" licenc alatt, újra elindítottam a Lazarus IDE-t. Írtam egy szükséges eszközt. A bemenetben meg kell adni a szükséges objektumok listáját és az elvégzendő lekérdezéseket, míg a kimenetben adatokat kapok. És mindez több szálon fut. Kiváló.
Miután beállítottam a pthreads-t a PHP Windows rendszerén, azt hittem, minden zökkenőmentesen fog futni, de nem így történt. Néhány hibakeresési idő után rájöttem, hogy a pthreads látszólag működik, de a mi rendszerünkben nem. Nyilvánvalóvá vált, hogy van valami különös a pthreads működésében Windows alatt. Így is történt. Elolvastam a dokumentációt, és ott írták, hogy Windows alatt a szálak száma korlátozott, és amennyire emlékszem, ez nem volt egyértelmű. Ez problémát okozott. Mert amikor elkezdtem csökkenteni a szálak számát, amelynél a program működött, az nagyon lassan végezte el a munkát. Ismét megnyitottam az IDE-t, és a programhoz hozzáadtam a több szálon történő pingelést. Sőt, a portok beolvasását is belefoglaltam. Valójában ezután elvesztette a pthreads iránti szükségességét a PHP, és már nem használjuk. Ezt követően további funkciókkal bővült a program, és azóta is működik. Ezután elkészítettem egy telepítőt Windows rendszerhez, amely magában foglalta az Apache-t, a PHP-t, a MariaDB-t, magát a PHP alkalmazást, és egy csomó segédprogramot a rendszerrel való kölcsönhatáshoz, amelyet Free Pascal nyelven írtam. A telepítővel kapcsolatban azt hittem, ezt a kérdést gyorsan meg tudom oldani, mert ez egy rendkívül elterjedt és majdnem minden szoftverhez szükséges dolog. Vagy nem jól kerestem, vagy valami más. De folyamatosan olyan termékekbe botlottam, amelyek vagy nem voltak elég rugalmasak, vagy drágák és szintén nem rugalmasak. Mégis találtam egy ingyenes telepítőt, amely lehetővé tette minden kívánság előrelátását. Ez az InnoSetup. Itt írok róla, mert kénytelen voltam keresgélni, hátha ezzel időt spórolok valakinek.
A bővítmény elhagyása a saját ügyfél javára
Korábban már említettem, hogy az ügyféloldal egy böngésző volt "pluginnal". Voltak idők, amikor a Chrome frissítése elcsúsztatta a dizájnt, vagy amikor a Windows frissítése miatt elvesztek a custom uri sémák. Nagyon nem akartam ilyen meglepetéseket az alkalmazás nyilvános verziójában. A custom uri sémák minden Windows frissítés után elvesztek, mivel a Microsoft egyszerűen törölte az összes nem saját szálat a megfelelő szekcióból. Ezen kívül a Google Chrome most már nem engedi megjegyezni a választásunkat, hogy megnyissuk-e az alkalmazást a custom uri-ból, és minden kattintásnál megkérdezi ezt a monitoring objektumokra. Összességében képesnek kellett lennie a felhasználó helyi rendszerével való normális interakcióra, amit a böngésző nem biztosít. A legegyszerűbb megoldás ebben a helyzetben az lenne, ha saját böngészőt készítenénk, ahogyan sokan most az Electront használják. De sok dolog már Free Pascal nyelven íródott, beleértve a szerveroldali részt is, ezért úgy döntöttünk, hogy az ügyfélt is ugyanazon a nyelven készítjük el, nem pedig egy állatkertet létrehozva. Így készült el a kliens, Chromium motorral a fedélzeten. Ezt követően különféle keretrendszerekkel gazdagodott.
Kibocsátás
Végre kiválasztottuk a rendszer nevét. Folyamatosan variáltunk a különböző lehetőségekkel, miközben a helyi verziót SaaS-ra alakítottuk. Mivel eredetileg nemcsak a hazai piacra terveztünk belépni, a névválasztás fő szempontja az volt, hogy szabad vagy nem túl drága domain álljon rendelkezésre a " .com" zónában. Néhány funkció/modul még nem volt átportolva a helyi verzióból a Veliam-ra, de úgy döntöttünk, hogy a jelenlegi funkcionalitással indítunk, a többit pedig frissítések formájában pótoljuk. Az első verzióban nem volt HelpDesk, Veliam Connector, nem lehetett módosítani az értesítési trigger küszöbértékeit, és még sok más hiányzott. Megvásároltunk egy Code Sign Certificate-t, aláírtuk az ügyfél- és szerveroldali részeket. Elkészítettük a termék weboldalát, megkezdtük a szoftver- és védjegyregisztrációs eljárásokat stb. Összességében készen állunk a startra. Fájó eufória töltött el a végzett munka miatt és azzal kapcsolatban, hogy a termékünket valószínűleg valaki használni fogja, bár ezzel kapcsolatban nem voltak kétségeink. Aztán hirtelen megálltunk. Az egyik partner azt mondta, hogy értesítések nélkül nem szabad piacra lépni. Sok más dolog nélkül lehet, de ez nélkül nem. Rövid viták után hozzájárultunk a Telegram integrációhoz, ami nekünk megfelelő volt. A jelenlegi üzenetküldők közül ez az egyetlen, amely ingyenesen és bonyolult jóváhagyási eljárások nélkül biztosítja az API-ját. A WhatsApp viszont azt javasolja, hogy forduljon olyan szolgáltatókhoz, akik jó pénzt kérnek a szolgáltatásaikért, minden kérésünket, hogy biztosítsanak közvetlen hozzáférést, figyelmen kívül hagyták. A Viber-ről pedig... fogalmam sincs, ki használja most, mivel a spam és a reklám mértéke ott rendkívüli. December végén, számos belső és baráti teszt után megnyitottuk a regisztrációt mindenki számára, és elérhetővé tettük a szoftvert letöltésre.
Kezdő terjesztés
Már az elején tudtuk, hogy szükség van egy kis felhasználói áramlásra a rendszerben, hogy a terméket valós körülmények között teszteljék, és valamilyen visszajelzést adjanak. Néhány megvásárolt poszt a VK-ban eredményt hozott. Megkezdődtek az első regisztrációk.
Itt érdemes megemlíteni, hogy a piacra lépés, amikor a cégednek nincs híres neve, és közben olyan funkciót kell nyújtani, mint az ügynök nélküli megfigyelés, amelyhez be kell írni a saját szerverek és munkaállomások fiókjait, nagyon nehéz. Sok embert ez megijeszt. Mi az elejétől fogva tudtuk, hogy ezzel problémák lesznek, és technikailag, valamint lelkileg is készen álltunk rá. Minden távoli kapcsolat, habár az RDP és SSH alapértelmezés szerint már titkosítva van, a mi szoftverünkkel további titkosításon megy keresztül az AES szabvány szerint. Minden adat a helyi szerverekből HTTPS-en keresztül kerül az felhőbe. A fiókok titkosítva vannak tárolva. Az összes alrendszerhez tartozó titkosító kulcsok minden ügyfél esetében egyediek. A távoli kapcsolatok esetében egyáltalán session kulcsokat használnak a titkosításhoz.
Amit ebben a helyzetben tehetünk, hogy az emberek nyugodtabbak legyenek, az az, hogy maximálisan nyitottak vagyunk, dolgozunk a biztonságon, és fáradhatatlanul válaszolunk az emberek aggasztó kérdéseire.
Sokaknak a szoftver kényelme és funkcionálása felülmúlja a félelmet, ezért regisztrálnak. Néhány személy a közzétett bejegyzésekben a VK-n írta, hogy ezt a szoftvert nem szabad használni, mert ez az ő jelszavaik gyűjtője, és egyáltalán egy no-name cég. Ezt a véleményt nem egy ember osztotta. Sokan egyszerűen nem értik, hogy amikor egy másik zártkörű szoftvert telepítenek a szerverükre, amely szolgáltatásként működik, ugyanúgy teljes jogokkal rendelkezik a rendszeren, és nem szükségesek a fiókok ahhoz, hogy illegális dolgokat tehessenek (nyilvánvaló, hogy meg lehet változtatni azt a felhasználót, amelyik a szolgáltatást futtatja, de itt is bármelyik fiókot be lehet írni). Valójában az emberek aggályai érthetőek. Szoftver telepítése a szerverre szokásos dolog, de a fiók beírása már kicsit ijesztő és intim, mivel a jó emberek felének ugyanaz a jelszava van minden szolgáltatásra, és külön fiók létrehozása még tesztelés céljából is lustaságot igényel. De jelenleg hatalmas mennyiségű szolgáltatás létezik, amelyeknek az emberek megbíznak az adataikban és nemcsak az adataikban. Mi pedig arra törekszünk, hogy az egyik ilyen szolgáltatás legyünk.
Sok olyan megjegyzést kaptunk, hogy valahonnan elloptuk ezt. Ez egy kicsit meglepett minket. Hát, egy ember véleménye, de ilyen megjegyzések különböző publikációkban, különböző emberektől is megjelentek. Eleinte nem tudtuk, hogyan reagáljunk erre. Szomorkodjunk, hogy egyesek szerint Oroszországban senki sem képes önállóan bármit tenni, csak ellopni, vagy örüljünk, hogy azt hiszik, hogy ilyesmit csak ellopni lehet.
Most fejeztük be az EV Code Sign Certificate megszerzésének eljárását. Ennek megszerzéséhez számos ellenőrzésen kell átesni, és rengeteg céges dokumentumot kell benyújtani, amelyek egy részét ügyvédnek kell hitelesítenie. Az EV Code Sign tanúsítvány megszerzése a pandémia körülményei között — ez egy külön téma a cikkhez. Az eljárás egy hónapig tartott. És ez nem várakozási hónap volt, hanem folyamatos kiegészítő dokumentumok kérésének hónapja. Lehet, hogy a pandémia nem is számít, és mindenkinél ilyen lassan zajlott az eljárás? Ossza meg.
Egyesek azt mondják, hogy nem fogjuk használni, mert nincs FSTEK tanúsítvány. Meg kell magyaráznom, hogy ezt nem tudjuk megszerezni és nem is fogjuk, mert ennek megszerzéséhez — a titkosításnak a GOST szerint kell lennie, míg mi olyan szoftver forgalmazását tervezzük, amely nemcsak Oroszországban kerül forgalomba, hanem AES-t is használ.
Mindezek a megjegyzések némi bizonytalanságot keltettek abban, hogy ez lehetséges — olyan terméket népszerűsíteni, amelyhez felhasználói fiókokat kell létrehozni, anélkül, hogy közben a köztudatban lennénk. Még figyelembe véve azt is, hogy tudtuk, hogy lesznek, akik nagyon negatívan viszonyulnak ehhez. Miután a regisztrációk száma átlépte az ezret, abbahagytuk a gondolkodást ezen. Főleg miután azokon kívül, akik még csak nem is próbálták ki a terméket, nagyon kedves vélemények is megjelentek. Fontos megjegyezni, hogy ezek a pozitív vélemények — a legnagyobb motivációt jelentik a termék fejlesztésében.
Távhozzáférési funkció hozzáadása a munkatársak számára
Az egyik gyakori kérés az ügyfelektől az, hogy „adózzon Vanének a számítógépe otthoni eléréséhez”. VPN kapcsolatok létrehozása MikroTik-en történt, és felhasználókat hoztunk létre. De ez igazán problémát jelent. A felhasználók nem képesek végigkövetni az útmutatót és lépésről lépésre csatlakozni a VPN-hez. Különböző Windows verziók. Az egyik Windows verzióval minden rendben, a másikkal más protokoll szükséges. Összességében ez mindig hálózati berendezések újra konfigurálásával járt, amelyek VPN szerverként működtek, és nem minden alkalmazottnak van hozzáférése ezekhez, ami kényelmetlen volt.
De már van távoli kapcsolódásunk a szerverekhez és a hálózati berendezésekhez. Miért ne használnánk a meglévő szállítást, és ne készítenénk egy külön kis segédprogramot, amit egyszerűen csak átadhatunk a felhasználónak a csatlakozáshoz? Csak azt akartuk, hogy a felhasználónak ne kelljen semmi bonyolultat beírnia. Csak egy „csatlakozás” gomb. De hogyan fogja ez a segédprogram tudni, hova kell csatlakozni, ha csak egy gomb van benne? Volt ötletünk online összeállítani a szükséges alkalmazást a szervereinken. A rendszergazda megnyomja a „parancsikon letöltése” gombot, és a felhőnkbe egy parancs érkezik az egyedi bináris fájl összeállítására, amelyben az adott szerverhez / számítógéphez való RDP kapcsolódási információk vannak beágyazva. Összességében ezt meg lehetett volna csinálni. De ez időigényes, a rendszergazdának várnia kellett volna, amíg a bináris fájl lefordul, majd letöltésre kerül. Természetesen hozzáadhattunk volna egy második fájlt a konfigurációval, de így már kettő fájl lenne, míg a felhasználónak egyszerűség kedvéért egyre van szüksége. Egy fájl, egy gomb és semmilyen telepítő. Miután egy kicsit átböngésztem a Google-t, arra a következtetésre jutottam, hogy ha valamilyen információt adunk a lefordított „.exe” végére, akkor az nem rontja el (majdnem). Akár a Háború és béke is betehető, és ugyanúgy fog működni, mint korábban. Kár lenne ezzel nem élni. Most már egyszerűen a kliensben közvetlenül kicsomagolhatjuk az alkalmazást, amelynek neve Veliam Connector, és egyszerűen hozzáfűzhetjük a csatlakozáshoz szükséges információt a végéhez. Az alkalmazás pedig tudja, mit kell tennie ezzel. Miért írtam a fenti szövegben a zárójelben, hogy „majdnem”? Mert ezért a kényelmért fizetni kell azzal, hogy az alkalmazás elveszíti az ECDSA aláírását. De mi, jelen állapotban, úgy gondoljuk, hogy ez a kényelemért kis ár.
Harmadik fél moduljainak licencei
Már írtam, hogy miután eldöntöttük, hogy a terméket nyilvánossá tesszük, nem csupán saját használatra, alaposan rá kellett dolgoznunk és meg kellett keresnünk néhány modul helyettesítését, amelyek megakadályozták, hogy beépítsük őket a termékünkbe. De a kiadás után véletlenül felfedeztünk egy kellemetlen dolgot. A Veliam Serverben, amely az ügyfélnél volt, a MariaDB adatbázis-kezelő volt, amely GPL licenc alatt áll. A GPL licenc azt feltételezi, hogy a szoftvernek nyílt forráskódúnak kell lennie, és ha a termékünkbe belekerül a MariaDB, amely ennek a licencnek a hatálya alá tartozik, akkor a mi termékünket is ezen a licencen kell kiadnunk. Szerencsére azonban ennek a licencnek a célja a nyílt forráskód, nem pedig a bírósági büntetés azok számára, akik véletlenül hibáztak. Ha a jogtulajdonosnak kifogása van, írásban értesíti a jogsértőt, akinek 30 napon belül orvosolnia kell a megsértést. Mi magunk fedeztük fel a hibánkat, így nem kaptunk értesítést, és azonnal elkezdtük keresni a megoldásokat a problémára. A megoldás nyilvánvalóvá vált - áttérés az SQLite-ra. Ennek az adatbázisnak nincsenek licencelési korlátozásai. A legtöbb modern böngésző SQLite-ot használ, és számos más program is. Találtam az interneten információt arról, hogy az SQLite a világ legelterjedtebb DBMS-ének számít, pontosan a böngészők révén, de nem kerestem forrást, így ez nem pontos információ. Elkezdtem tanulmányozni, milyen következményekkel jár az SQLite-ra való áttérés.
Ez már nem trivialis feladat, amikor több száz MariaDB-vel telepített szerver van az ügyfeleknél, amelyekben adatok találhatóak. Néhány MariaDB funkció nem érhető el az SQLite-ban. Például a kódban olyan lekérdezéseket használtunk, mint
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Ez a konstrukció nemcsak a táblázatból választja ki az adatokat, hanem blokkolja az adott sorokat is. Továbbá, több konstrukciót is át kellett írni. De azon kívül, hogy sok lekérdezést újra kellett írni, ki kellett találnunk egy mechanizmust is, amely a Veliam Server frissítésekor az ügyfélnél áttelepíti az összes adatot az új adatbázisba, és eltávolítja a régit. Ezenkívül az SQLite-ban nem működnek a tranzakciók, ami valós problémát jelentett. De miután átnéztem a világhálót, gond nélkül rátaláltam arra, hogy az SQLite-ban a tranzakciókat be lehet kapcsolni, ha a csatlakozáskor egyszerű parancsot átadunk,
PRAGMA journal_mode=WAL;A feladatot elvégeztük, és most az ügyfelek szerveroldala SQLite-on működik. Nem észleltünk változásokat a rendszer működésében.
Új HelpDesk
A belső verzióból a SaaS verzióra szükség volt a HelpDesk rendszer portálására, de némi módosítással. Az első, amit el akartunk végezni, az a felhasználók átlátható bejelentkezésének integrálása az ügyfél domainjével. Jelenleg a felhasználónak ahhoz, hogy bejusson a HelpDesk-be és létrehozzon egy kérelmet, csak rákell kattintania az asztali parancsikón, és megnyílik a böngésző. A felhasználónak nem kell semmilyen bejelentkezési adatot megadnia. Az Apache SSPI modul, amely a Veliam Server része, automatikusan bejelentkezteti a felhasználót a domain-felhasználói fiókjával. Ha a felhasználó a vállalati hálózaton kívül szeretne kérelmet leadni, akkor rákattint a gombra, és e-mailben kap egy linket, amellyel jelszó megadása nélkül bejelentkezhet a HelpDesk rendszerbe. Ha a felhasználót kikapcsolják vagy törlik a domainből, akkor a HelpDesk fiók is megszűnik működni. Így a rendszeradminisztrátornak nem kell figyelemmel kísérnie a fiókokat sem a domainben, sem a HelpDesk-ben. Ha egy dolgozó elbocsátásra kerül, egyszerűen csak kikapcsolja a fiókot a domainben, és kész, nem tud belépni a rendszerbe sem a vállalati hálózaton, sem a linken keresztül. Az integráció működéséhez a rendszeradminisztrátornak egy GPO-t kell létrehoznia, amely és .
A második dolog, amit rendkívül szükségesnek tartunk a HelpDesk rendszerekhez, legalábbis a saját részünkre — az a kérvényezőhöz való csatlakozás egy kattintással közvetlenül a kérelemből. Sőt, a csatlakozásoknak akkor is működniük kell, ha a rendszergazda egy másik hálózatban van. Az outsourcing számára ez kötelező, a saját rendszergazdák számára is gyakran nagyon szükséges. Már van néhány termék, amelyek remekül kezelik a távoli csatlakozások feladatát. Ezért úgy döntöttünk, hogy integrációkat készítünk számukra. Jelenleg integrációt készítettünk a VNC-hez, a jövőben pedig tervezünk hozzáadni Radminot és TeamViewert. Használva a mi hálózati szállítóeszközünket a távoli kapcsolatokhoz, úgy alakítottuk ki, hogy a VNC csatlakozik a távoli munkaállomásokhoz NAT mögött. Ugyanez fog igaz lenni az Radminra is. Jelenleg ahhoz, hogy csatlakozzon a felhasználóhoz, egyszerűen meg kell nyomni a „csatlakozás a kérvényezőhöz” gombot a kérelmen. Megnyílik a VNC kliens és csatlakozik a kérvényezőhöz, függetlenül attól, hogy egy hálózatban van-e vele, vagy otthon ücsörög a papucsában. Előtte a rendszergazda GPO eszközökkel telepítse mindenkinek a munkaállomására a VNC Server-t.
Jelenleg mi magunk is átállunk az új HelpDesk-re, és használjuk a domainek és a VNC integrációját. Ez számunkra nagyon kényelmes. Mostantól nem kell fizetnünk a TeamViewer-ért, amelyet több mint három éve használtunk a támogatási szolgálatunkhoz.
Mit tervezünk a következőkben
Amikor kiadtuk a terméket, nem készítettünk pénzes csomagokat, hanem egyszerűen korlátoztuk a ingyenes csomagot 50 figyelhető objektumra. Ötven hálózati eszköznek és szervernek elegendőnek kell lennie mindenkinek, gondoltuk. Aztán elkezdtek beérkezni a limitemelési kérelmek. Mondani, hogy kissé sokkoló volt — nem mondanék mást. Tényleg érdeklődtek cégek a szoftverünk iránt, akiknek ennyi szerverük van? Ingyenesen bővítettük a limitemelési kéréseket, akiktől ilyen kérés érkezett. Néhányan a válaszunkban megkérdeztük, hogy miért van szükségük ennyire, vajon valóban ennyi szerver és hálózati berendezés áll rendelkezésükre? Kiderült, hogy a rendszergazdák úgy kezdték el használni a rendszert, ahogyan eredetileg nem terveztük. Minden nagyon egyszerű lett — nemcsak a szervereket, hanem a munkaállomásokat is figyelték a szoftverünkkel. Ezért is érkezett sok kérés a korlátok bővítésére. Jelenleg már bevezettük a fizetős csomagokat, és a határokat önállóan is ki lehet terjeszteni.
A szerverek szinte mindig vagy tároló tömbökkel (SZKD), vagy helyi lemezekkel RAID tömbökben működnek. Mi eredetileg számukra készítettük a terméket. A SMART figyelés nem volt érdekes ehhez a feladathoz. De figyelembe véve, hogy az emberek alkalmazták a szoftvert munkaállomások figyelésére, megjelentek a SMART figyelés megvalósítására vonatkozó kérelmek. Hamarosan megvalósítjuk.
A Veliam Connector megjelenésével feleslegessé vált a VPN server telepítése a vállalati hálózatban, vagy RDGW-t készíteni, vagy csak portokat nyitni a szükséges gépekhez való RDP kapcsolódáshoz. Nagyon sokan csak ezekhez a távoli kapcsolatokhoz használják a rendszerünket. A Veliam Connector csak Windows alatt érhető el, de néhány vállalati felhasználó MacOS-t futtató otthoni laptopról csatlakozik munkaállomásokhoz vagy terminálokhoz a vállalati hálózatban. Így a rendszergazdának a felhasználók miatt ismételten a portnyitás vagy VPN kérdéséhez kell visszatérnie. Ezért jelenleg már a Veliam Connector MacOS verzióján dolgozunk. A felhasználók, akik kedvenc alma eszközeiket használják, szintén lehetőséget kapnak arra, hogy egyetlen kattintással csatlakozzanak a vállalati infrastruktúrához.
Nagyon tetszik, hogy a sok felhasználóval rendelkező rendszer esetén nem kell azon gondolkodni, hogy mit szeretnének az emberek, és mi lenne a kényelmesebb. Ők maguk írják meg a kívánságaikat, így rengeteg fejlesztési tervünk van a közeljövőre.
Párhuzamosan arra is tervezzük, hogy angolra fordítjuk a rendszert, és külföldön terjesztjük. Még nem tudjuk, hogyan fogjuk elérni a terméket országunkon kívül, keresünk lehetőségeket. Lehet, hogy erről később külön cikk fog születni. Talán valaki, aki elolvasta ezt a cikket, tud tanácsot adni a megfelelő irányról, vagy esetleg maga is tudja, hogyan lehet ezt megtenni, és felajánlja a szolgáltatásait. Hálásak lennénk a segítségért.
Forrás: habr.com
