I , jeg fortalte om baggrunden for oprettelsen af Veliam og beslutningen om at distribuere det via SaaS-systemet. I denne artikel vil jeg beskrive, hvad der skulle gøres for at produktet kunne blive offentligt i stedet for lokalt. Om hvordan distributionen begyndte, og hvilke problemer vi stødte på.
Planlægning
Den nuværende serverdel for brugerne var på Linux. Næsten i hver organisation er der Windows-servere, hvilket ikke kan siges om Linux. Veliam's største styrke er fjernforbindelser til servere og netværksudstyr bag NAT. Men denne funktion var meget strengt bundet til, at routeren nødvendigvis skulle være en MikroTik. Og det ville tydeligvis ikke tilfredsstille mange. Jeg begyndte først at overveje at tilføje support til routere fra de mest udbredte producenter. Men jeg indså, at dette ville være et uendeligt kapløb med at udvide listen over de understøttede mærker. Desuden kan de, der allerede er understøttet, have forskellige sæt af kommandoer til at ændre NAT-regler fra model til model. Den eneste løsning jeg så, var VPN.
Da vi besluttede at distribuere produktet, men ikke som open source, kunne vi derfor ikke inkludere forskellige biblioteker med åbne licenser som GPL. Det er overhovedet et separat emne. Efter beslutningen om at sælge produktet måtte vi gennemgå halvdelen af bibliotekerne, da de var GPL. Det var fint, da vi udviklede til os selv, men det passer ikke til distribution. Den første VPN, der kom i tankerne, er OpenVPN, men den er GPL. Der var også muligheden for at anvende den japanske SoftEther VPN. Dens licens tillod at inkludere den i vores produkt. Efter et par dages test for at finde ud af, hvordan vi kunne integrere det, så brugeren ikke skulle konfigurere noget eller kende til SoftEther VPN – fik vi en prototype. Alt fungerede som det skulle. Men af en eller anden grund føltes denne ordning stadig forkert, og vi afviste den i sidste ende. Men naturligvis afviste vi den, efter vi havde fundet på en anden løsning. Vi endte med alt implementeret via almindelige TCP-forbindelser. Delen af forbindelserne går gennem en koordinator, og en del direkte via Nat Hole Punching (NHP), som også blev implementeret i Free Pascal. Jeg må sige, at jeg ikke tidligere havde hørt om NHP. Jeg kunne ikke forestille mig, at man kunne forbinde to netværksenheder, som alle var bag NAT, direkte. Jeg studerede emnet, forstod principperne og begyndte at skrive. Det planlagte blev gennemført, brugeren kan med et klik oprette forbindelse til en enhed bag NAT via RDP, SSH eller Winbox uden at indtaste adgangskoder og konfigurere VPN. Desuden går størstedelen af disse forbindelser uden om vores koordinator, hvilket er gavnligt for latency og omkostningerne ved at vedligeholde disse forbindelser.
Oversættelse af serverdelen fra Linux til Windows
Der var flere problemer under overgangen til Windows. Det første var, at den indbyggede wmic i Windows ikke tillader at lave WQL-forespørgsler. Og i vores system var alt allerede bygget på dem. Der var også noget andet, men jeg kan ikke huske, hvorfor vi helt opgav at bruge det. Måske forskelle mellem Windows-versioner. Det andet problem var multithreading. Jeg fandt ikke et godt tredjeparts værktøj under en "acceptable" licens, så jeg startede IDE Lazarus igen. Og skrev det nødvendige værktøj. Input er en nødvendig liste over objekter og hvilke forespørgsler der skal laves, og som output får jeg data. Og alt dette i multithreadet tilstand. Fremragende.
Efter at jeg havde konfigureret pthreads til PHP Windows, troede jeg, at alt ville fungere perfekt, men sådan gik det ikke. Efter noget tid med fejlfinding indså jeg, at pthreads tilsyneladende virkede, men ikke på vores system. Det blev klart, at der var en særlig måde, som pthreads fungerede på i Windows. Og det var rigtigt. Jeg læste dokumentationen, og der stod, at antallet af tråde er begrænset til Windows, og så vidt jeg husker, var dette ikke eksplicit nævnt. Det blev et problem. For da jeg begyndte at reducere antallet af tråde, hvor applikationen kunne køre, blev det meget langsomt. Jeg åbnede IDE'en igen, og i det samme værktøj blev der tilføjet funktionalitet til multitrådede pingninger af objekter. Og desuden blev portscanning også tilføjet. Efter dette blev behovet for pthreads til PHP elimineret, og det blev ikke længere brugt. Dernæst blev der tilføjet flere funktionaliteter til dette værktøj, som stadig fungerer i dag. Efter dette blev der samlet en installationsprogram til Windows, som omfattede Apache, PHP, MariaDB, selve PHP-applikationen og et sæt værktøjer til interaktion med systemet, der var skrevet i Free Pascal. Med hensyn til installationsprogrammet troede jeg, at jeg hurtigt ville løse dette problem, da det er en meget udbredt og nødvendig ting for næsten enhver software. Enten har jeg ikke ledt ordentligt, eller der var noget andet. Men jeg stødte konstant på produkter, der enten ikke var fleksible nok, eller var dyre og ligeledes ufleksible. Men jeg fandt faktisk en gratis installationsprogram, der kunne dække alle ønsker. Det er InnoSetup. Jeg skriver herom, fordi jeg måtte lede lidt, så jeg måske kan spare nogen tid.
Fravalg af plugin til fordel for sin kunde
Jeg skrev tidligere, at klientdelen var en browser med et "plugin". Der var tider, hvor Chrome opdateredes, og layoutet blev lidt skævt, eller Windows opdateredes, og custom URI-skemaer forsvandt. Jeg ville meget gerne undgå den slags overraskelser i den offentlige version af produktet. Desuden begyndte custom URI'er at forsvinde efter hver Windows-opdatering. Microsoft fjernede simpelthen alle ikke-ejede grene i den relevante sektion. Derudover tillader Google Chrome nu ikke at huske, om man ønsker at åbne en applikation fra custom URI, og stiller dette spørgsmål ved hvert klik på overvågningsobjektet. Generelt var der brug for et ordentligt interaktion med brugerens lokale system, hvilket browseren ikke kunne give. Den simpleste løsning i en sådan struktur var at lave sin egen browser, som mange gør nu via Electron. Men mange ting var allerede skrevet i Free Pascal, også i serverdelen, så vi besluttede at lave klienten i samme sprog for at undgå at skabe unødvendig kompleksitet. Så blev klienten skrevet med Chromium ombord. Derefter begyndte den at udvikle sig med forskellige omskrivninger.
Udgivelsen
Endelig valgte vi et navn til systemet. Vi gennemgik konstant forskellige muligheder, mens vi omdannede fra den lokale version til SaaS. Da vi oprindeligt planlagde at gå ind på mere end blot det indenlandske marked, var det primære kriterium for udvælgelsen af navnet tilgængeligheden af en ubeskattet, eller ikke alt for dyr, domæne i ".com". Nogle funktioner/modules var stadig ikke porteret fra den lokale version til Veliam, men vi besluttede, at vi ville lancere med den nuværende funktionalitet og derefter tilføje det øvrige som opdateringer. I den allerførste version var der ingen HelpDesk, Veliam Connector, det var ikke muligt at ændre tærsklerne for udløsning af notifikationsudløsere, og meget mere. Vi købte et Code Sign Certificate, signerede klient- og serverdelen. Vi lavede en hjemmeside til produktet, begyndte procedurerne for registrering af software, varemærker osv. I det hele taget er vi klar til at starte. Der er en let eufori over det udførte arbejde og over det faktum, at måske vil nogen bruge dit produkt, selvom vi ikke havde nogen tvivl om det. Og her stopper det. Partneren sagde, at man ikke kan gå på markedet uden notifikationer i messenger. Man kan undvære mange andre ting, men ikke dette. Efter en kort debat blev der tilføjet en integration med Telegram, som vi var tilfredse med. Blandt de nuværende messengere er dette den eneste, der tilbyder gratis adgang til sine API'er uden komplekse godkendelsesprocedurer. Den samme WhatsApp beder om at kontakte udbydere, som tager pæne penge for at bruge deres tjenester; alle e-mails med anmodninger om at give adgang uden mellemled blev ignoreret. Hvad angår Viber... Jeg ved ikke, hvem der bruger det nu, da spam og reklame der overstiger alles oplevelse. I slutningen af december, efter en række interne tests og tests blandt venner, åbnede vi registreringen for alle og gjorde softwaren tilgængelig til download.
Start af distribution
Fra starten vidste vi, at vi havde brug for en lille strøm af brugere til systemet, så de allerede i live-mode kunne teste produktet og give en første feedback. Flere købte indlæg på VK gav resultater. De første registreringer strømmede ind.
Det skal siges, at det er meget svært at gå ind på markedet, når din virksomhed ikke har et berømt navn, og samtidig tilbyde funktionaliteten af agentfri overvågning, hvor man skal indtaste loginoplysninger fra sine servere og arbejdsstationer. Dette skræmmer mange mennesker. Vi vidste fra starten, at der ville være problemer, og vi var både teknisk og mentalt forberedte på det. Alle fjerntilslutninger, på trods af at RDP og SSH allerede krypteres som standard, krypteres yderligere af vores software efter AES-standarden. Alle data fra de lokale servere sendes til skyen via HTTPS. Loginoplysningerne opbevares i krypteret form. Krypteringsnøglerne for alle undersystemer er individuelle for hver kunde. Til fjerntilslutninger anvendes der særlige session krypteringsnøgler.
Alt, hvad vi kan gøre i denne situation for at gøre folk mere rolige, er at være så åbne som muligt, arbejde på sikkerheden og ikke blive trætte af at besvare de spørgsmål, der bekymrer folk.
For mange overvinder bekvemmeligheden og funktionaliteten af softwaren frygten, og de registrerer sig. Nogle personer har i offentliggjorte indlæg på VK skrevet, at denne software ikke kan bruges, da den samler deres adgangskoder, og at virksomheden generelt er ukendt. Det skal siges, at sådan en mening ikke kun er hos én person. Mange forstår simpelthen ikke, at når de installerer en anden proprietær software på serveren, som kører som en tjeneste, har den præcis de samme rettigheder i systemet, og de har ikke brug for loginoplysninger for at gøre noget ulovligt (det er klart, at man kan ændre brugeren, som tjenesten kører fra, men det kan man også her; man kan indtaste hvilken som helst konto). Faktisk er folks bekymringer forståelige. At installere software på serveren er en almindelig sag, men det at indtaste en konto er lidt skræmmende og intimt, da mange mennesker har det samme password til alle tjenester, og det er besværligt at lave en separat konto selv til test. Men i øjeblikket er der et væld af tjenester, som folk stoler på med deres loginoplysninger og mere end det. Og vi stræber efter at blive en af dem.
Mange kommentarer indeholdt en bemærkning om, at vi på en eller anden måde havde stjålet dette. Det overraskede os lidt. Det er én persons mening, men sådanne kommentarer dukkede op i forskellige publikationer fra forskellige mennesker. Vi vidste ikke, hvordan vi skulle reagere. Skulle vi være kede af, at nogle mennesker mener, at ingen i Rusland kan gøre noget selv, men kun kan stjæle, eller skulle vi være glade for, at de mener, at det kun kan stjæles.
Vi har nu afsluttet proceduren for at få et EV Code Sign Certificate. For at opnå det skal man gennemgå en række kontroller og sende en masse dokumenter om virksomheden, hvoraf nogle skal være bekræftet af en advokat. At få et EV Code Sign-certifikat under pandemien er overhovedet et emne for en særskilt artikel. Proceduren tog en måned. Og det var ikke en måned med forventning, men med konstante anmodninger om yderligere dokumenter. Måske er pandemien ikke årsagen, og at alle havde en så lang procedure? Del venligst.
Nogle siger, at de ikke vil bruge det, fordi der ikke er noget FSTEK-certifikat. Vi må forklare, at vi ikke kan få det, og ikke vil, fordi for at få dette certifikat skal krypteringen være efter GOST-standarten, og vi planlægger at distribuere softwaren ikke kun i Rusland og bruger AES.
Alle disse kommentarer skabte en vis usikkerhed i forhold til, om det er muligt at promovere et produkt, der kræver indtastning af konti, uden at være på listen over de kendte. Selvom vi vidste, at der ville være dem, som ville være meget negative over for det. Efter antallet af registreringer oversteg tusind, stoppede vi med at tænke på det. Især efter at vi ikke kun fik negativ feedback fra dem, der slet ikke havde prøvet produktet, men også meget positive anmeldelser. Det skal siges, at disse positive anmeldelser er den største motivation for produktudvikling.
Tilføjelse af funktionalitet til fjernadgang for medarbejdere
En af de mest almindelige anmodninger fra kunderne er "lav adgang for Vania til sin computer hjemmefra". Vi opsatte en VPN på MikroTik og oprettede konti for brugerne. Men det har virkelig vist sig at være en udfordring. Brugerne kan ikke finde ud af at følge instruktionerne for at oprette forbindelse via VPN. Der er forskellige versioner af Windows. I én Windows fungerer det fint, men i en anden er der brug for en anden protokol. Og generelt har det altid været forbundet med omkonfigurering af netværksudstyr, der fungerede som VPN-server, og ikke alle medarbejdere har adgang til det, hvilket har været besværligt.
Men har vi ikke allerede fjernforbindelser til servere og netværksudstyr? Hvorfor ikke udnytte den eksisterende transport og lave et lille program, som bare kan gives til brugeren for at oprette forbindelse? Jeg ville kun sørge for, at brugeren ikke skulle indtaste noget kompliceret. Bare en knap "forbind". Men hvordan skal dette program forstå, hvor det skal oprette forbindelse, hvis der kun er én knap? Der var en idé om online bygning af den nødvendige applikation på vores servere. Systemadministratoren trykker på knappen "download genvej", og der sendes en kommando til vores cloud for at bygge en individuel binærfil med indbygget information om, hvordan man opretter forbindelse til den ønskede server / computer via RDP. Generelt kunne det lade sig gøre. Men det ville tage tid, administratoren skulle vente, indtil binærfilen blev kompileret, og derefter downloade den. Man kunne selvfølgelig tilføje en anden fil med en konfiguration, men så ville der være to filer, og for enkelhedens skyld har brugeren brug for én. En fil, én knap og ingen installatører. Efter at have læst lidt om sagen på Google, kom jeg frem til, at hvis man tilføjer nogen information til slutningen af den kompilerede “.exe”, så går den ikke i stykker (næsten). Man kan tilføje selv Krigen og Freden, og den vil stadig fungere som før. Det ville være en skam ikke at udnytte dette. Nu kan man bare i realtid pakke applikationen ud direkte i klienten, som for øvrigt hedder Veliam Connector, og blot tilføje den nødvendige information til forbindelse i slutningen. Og selve applikationen ved, hvad den skal gøre med det. Hvorfor skrev jeg lige før i parentes "næsten"? Fordi man betaler prisen for denne bekvemmelighed ved, at applikationen mister sin digitale signatur. Men på dette tidspunkt anser vi, at dette er en lille pris at betale for sådan en bekvemmelighed.
Licenser til tredjepartsmoduler
Tidligere nævnte jeg, at efter beslutningen om at gøre produktet offentligt tilgængeligt i stedet for kun til eget brug, var det nødvendigt at arbejde hårdt og finde erstatninger til visse moduler, der forhindrede os i at inkludere dem i vores produkt. Men efter udgivelsen opdagede vi tilfældigt en uheldig ting. I Veliam Server, der var på klientsiden, var der en database MariaDB. Og den er under GPL-licensen. GPL-licensen forudsætter, at softwaren skal være open source, og hvis vores produkt inkluderer MariaDB, som har denne licens, så skal vores produkt også være under denne licens. Men heldigvis er målet med denne licens åben kildekode og ikke retsforfølgelse af dem, der ved en fejl har gjort noget forkert. Hvis rettighedshaverne fremsætter et krav, skal de skriftligt underrette overtræderen, som derefter skal rette overtrædelsen inden for 30 dage. Vi opdagede vores fejl selv, og vi modtog ikke noget brev, og vi begyndte straks at overveje, hvordan vi kunne løse problemet. Løsningen viste sig at være åbenlys - skiftet til SQLite. Denne database har ingen licensbegrænsninger. De fleste moderne browsere bruger SQLite, og det samme gør en masse andre programmer. Jeg fandt oplysninger på internettet, som siger, at SQLite er den mest udbredte database i verden, netop på grund af browsere, men jeg søgte ikke beviser, så det er unøjagtige oplysninger. Jeg begyndte at undersøge, hvad overgangen til SQLite ville indebære.
Det bliver en ikke-triviel opgave, når der er flere hundrede servere med MariaDB installeret hos kunderne og data i dem. Nogle funktioner i MariaDB er ikke tilgængelige i SQLite. For eksempel brugte vi forespørgsler af typen
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Denne konstruktion gør ikke kun en selektion fra tabellen, men blokerer også de data rækker. Og flere andre konstruktioner skulle også skrives om. Men udover at vi skulle omskrive mange forespørgsler, skulle vi også finde en mekanisme, der ved opdatering af Veliam Server hos kunden, kunne portere alle data til den nye database og fjerne den gamle. Derudover fungerede transaktioner ikke i SQLite, og det var et reelt problem. Men efter at have læst på internettets enorme ressourcer, fandt jeg uden problemer, at transaktioner i SQLite kan aktiveres ved at sende en simpel kommando ved forbindelse.
PRAGMA journal_mode=WAL;Som opfølgning er opgaven udført, og nu fungerer den serverbaserede del for kunderne på SQLite. Vi har ikke bemærket nogen ændringer i systemets funktion.
Ny HelpDesk
Fra den interne version til SaaS-versionen skulle HelpDesk-systemet porteres med nogle ændringer. Det første, vi ønskede at implementere, var integrationen med kundens domæne for at muliggøre en gennemsigtig autorisation af brugere i systemet. Nu kan brugeren, for at tilgå HelpDesk og oprette en forespørgsel, blot klikke på en genvej på skrivebordet, hvorefter browseren åbnes. Brugeren indtaster ikke nogen loginoplysninger. Modul til Apache SSPI, der er inkluderet i Veliam Server, autoriserer automatisk brugeren med domæne-kontoen. For at oprette en forespørgsel i systemet, når brugeren befinder sig uden for det virksomhedsnet, klikker han på en knap, og han modtager en link på sin e-mail, hvorefter han kan logge ind i HelpDesk-systemet uden adgangskoder. Hvis brugeren deaktiveres eller slettes i domænet, vil hans konto i HelpDesk også stoppe med at fungere. På denne måde behøver systemadministratoren ikke selv at overvåge konti både i domænet og i HelpDesk. Hvis en medarbejder er blevet fyret — deaktiver kontoen i domænet, og så kan de ikke logge ind i systemet hverken fra det corporate netværk eller via linket. For at få denne integration til at fungere, skal systemadministratoren oprette en GPO, der og .
For us, the second essential feature in HelpDesk systems is the ability to connect to the requester directly from the request with a single click. Moreover, these connections must work even if the system administrator is on a different network. This is essential for outsourcing and often very necessary for in-house system administrators as well. There are already several products that handle remote connections well, and we decided to create integrations for them. Currently, we have developed integration for VNC and plan to add Radmin and TeamViewer in the future. By using our network transport for remote connections to the infrastructure, we ensured that VNC connects to remote workstations behind NAT. The same will apply for Radmin. Now, to connect to a user, you simply need to click the “connect to requester” button in the request. The VNC client opens and connects to the requester regardless of whether you are on the same network or sitting at home in your slippers. Prior to this, the system administrator needs to install VNC Server on all workstations using GPO tools.
We are currently transitioning to a new HelpDesk and using the integration with the domain and VNC. This is very convenient for us. Now we no longer have to pay for TeamViewer, which we used for over three years for our support service.
What we plan to do next
Da vi lancerede produktet, lavede vi ikke nogen betalte planer, men indskrænkede blot den gratis plan til 50 overvågningsobjekter. Femoghalvfjerds netværksenheder og servere skulle være tilstrækkelige for alle, tænkte vi. Og så begyndte anmodningerne om at øge begrænsningen at komme. At sige, at vi var lidt chokerede, ville være en underdrivelse. Var der virkelig virksomheder, som var interesserede i vores software, der havde så mange servere? Vi udvidede gratis grænserne for dem, der gjorde sådanne anmodninger. Til nogle af dem spurgte vi, hvorfor de havde brug for så mange, om de virkelig havde så mange servere og netværksudstyr. Og det viste sig, at systemadministratorer begyndte at bruge systemet på en måde, som vi slet ikke havde planlagt. Alt var ret simpelt - vores software begyndte ikke kun at overvåge servere, men også arbejdsstationer. Heraf kom mange anmodninger om at udvide grænserne. Nu har vi allerede indført betalte planer, og grænserne kan udvides selvstændigt.
Servere arbejder næsten altid enten med SAN eller med lokale diske i RAID-opsætninger. Og vi udviklede oprindeligt et produkt til dem. Og overvågning af SMART var ikke interessant til denne opgave. Men i takt med at folk tilpassede softwaren til overvågning af arbejdsstationer, dukkede der anmodninger op om implementering af SMART-overvågning. Snart vil vi realisere det.
Med introduktionen af Veliam Connector blev det unødvendigt at implementere en VPN-server i det corporate netværk, eller at lave RDGW, eller blot viderekoble porte til de nødvendige maskiner for at oprette forbindelse via RDP. Mange bruger vores system udelukkende til disse fjerndatakoblinger. Veliam Connector findes kun til Windows, mens nogle brugere fra virksomheder opretter forbindelse fra deres hjemmebærbare computere med MacOS til arbejdsstationer eller terminaler i det corporate netværk. Og det betyder, at systemadministratorer alligevel bliver nødt til at tage spørgsmålet om viderekobling eller VPN op igen på grund af et par brugere. Derfor er vi nu ved at afslutte udviklingen af Veliam Connector-versionen til MacOS. Brugere af deres elskede Apple-teknologi får også mulighed for at tilslutte til virksomhedens infrastruktur med ét klik.
Jeg værdsætter virkelig, at når der er mange brugere af systemet, behøver man ikke at bekymre sig om, hvad folk har brug for, og hvad der vil være mere bekvemt. De skriver selv deres ønsker, så der er mange planer for udviklingen i den nærmeste fremtid.
Samtidig planlægger vi nu at oversætte systemet til engelsk og sprede det i udlandet. Vi ved endnu ikke, hvordan vi vil distribuere produktet uden for vores land, så vi leder efter muligheder. Måske bliver der senere en separat artikel om dette. Måske kan nogle af dem, der læser denne artikel, give et nyttigt perspektiv eller allerede ved, hvordan man gør det og tilbyder deres tjenester. Vi vil være taknemmelige for hjælp.
Kilde: habr.com
