В , snakket jeg om bakgrunnen for opprettelsen av Veliam og beslutningen om å distribuere den gjennom SaaS-systemet. I denne artikkelen vil jeg snakke om hva jeg måtte gjøre for å gjøre produktet ikke lokalt, men offentlig. Om hvordan distribusjonen startet og hvilke problemer de møtte.
Планирование
Den nåværende backend for brukere var på Linux. Nesten hver organisasjon har Windows-servere, noe som ikke kan sies om Linux. Veliams hovedstyrke er fjerntilkoblinger til servere og nettverksutstyr bak NAT. Men denne funksjonaliteten var veldig tett knyttet til det faktum at ruteren måtte være Mikrotik. Og dette ville åpenbart ikke tilfredsstille mange. Jeg begynte først å tenke på å legge til støtte for rutere fra de vanligste leverandørene. Men jeg forsto at dette var et endeløst kappløp for å utvide listen over støttede selskaper. Dessuten kan de som allerede støttes ha et annet sett med kommandoer for å endre NAT-regler fra modell til modell. Den eneste veien ut av situasjonen så ut til å være en VPN.
Siden vi bestemte oss for å distribuere produktet, men ikke som åpen kildekode, ble det umulig å inkludere ulike biblioteker med åpne lisenser som GPL. Dette er generelt et eget emne; etter å ha tatt beslutningen om å selge produktet, måtte jeg gå gjennom halvparten av bibliotekene på grunn av det faktum at de var GPL. Når de skrev for seg selv, var det normalt. Men ikke egnet for distribusjon. Den første VPN-en du tenker på er OpenVPN. Men det er GPL. Et annet alternativ var å bruke den japanske SoftEther VPN. Lisensen hans tillot ham å inkludere det i produktet sitt. Etter et par dager med ulike tester på hvordan man integrerer det på en slik måte at brukeren ikke trenger å konfigurere noe i det hele tatt og vite om SoftEther VPN, ble det skaffet en prototype. Alt var som det skulle være. Men av en eller annen grunn forvirret dette opplegget oss fortsatt, og vi forlot det til slutt. Men naturlig nok takket de nei etter at de kom med et annet alternativ. Til slutt ble alt gjort på vanlige TCP-forbindelser. Noen forbindelser fungerer gjennom en koordinator, noen direkte gjennom Nat Hole Punching (NHP)-teknologien, som også ble implementert i Free Pascal. Jeg må si at jeg aldri hadde hørt om NHP før. Og det gikk aldri opp for meg at det var mulig å koble til 2 nettverksenheter, som begge er rett bak NAT. Jeg studerte emnet, forsto operasjonsprinsippet og satte meg ned for å skrive. Planen er realisert, brukeren kobler seg med ett klikk til ønsket enhet bak NAT via RDP, SSH eller Winbox uten å skrive inn passord eller sette opp en VPN. Dessuten går de fleste av disse forbindelsene forbi vår koordinator, noe som har en god effekt på ping og kostnadene ved å betjene disse forbindelsene.
Overføring av serversiden fra Linux til Windows
Det var flere problemer ved bytte til Windows. Den første er at den innebygde wmic-en i Windows ikke lar deg lage WQL-spørringer. Og i vårt system var alt allerede bygget på dem. Og det var noe annet, men nå har jeg glemt hvorfor de til slutt forlot bruken. Muligens forskjeller mellom Windows-versjoner. Og det andre problemet er multithreading. Da jeg ikke fant et godt tredjepartsverktøy under en "akseptabel" lisens for oss, lanserte jeg Lazarus IDE igjen. Og jeg skrev det nødvendige verktøyet. Inngangen er den nødvendige listen over objekter og hvilke spesifikke spørringer som må gjøres, og som svar mottar jeg data. Og alt dette i flertrådsmodus. Flott.
Etter at jeg satte opp pthreads for PHP Windows trodde jeg at alt skulle starte med en gang, men det var ikke tilfelle. Etter en tid med feilsøking innså jeg at pthreads så ut til å fungere, men det fungerte ikke på systemet vårt. Det ble klart at det er noe særegenhet ved å jobbe med pthreads på Windows. Og slik ble det. Jeg leste dokumentasjonen, og det ble skrevet der at for Windows er antall tråder begrenset, og så vidt jeg husker implisitt. Dette ble et problem. For da jeg begynte å redusere antall tråder applikasjonen kjørte på, gjorde den jobben veldig sakte. Jeg åpnet IDE igjen og funksjonalitet for multi-threaded pinging av objekter ble lagt til det samme verktøyet. Vel, det er allerede mye portskanning der også. Faktisk, etter dette, forsvant behovet for pthreads for PHP, og det brukes ikke lenger. Videre ble flere funksjoner lagt til dette verktøyet, og det fungerer fortsatt den dag i dag. Etter dette ble et installasjonsprogram for Windows satt sammen, som inkluderte Apache, PHP, MariaDB, selve PHP-applikasjonen og et sett med verktøy for å samhandle med systemet, skrevet i Free Pascal. Når det gjelder installatøren, tenkte jeg at jeg raskt ville løse dette problemet, fordi... Dette er en veldig vanlig ting og nødvendig for nesten all programvare. Enten så jeg på feil sted, eller noe annet. Men jeg kom stadig over produkter som enten ikke var fleksible nok, eller dyre og også lite fleksible. Og likevel fant jeg et gratis installasjonsprogram der det vil være mulig å sørge for eventuelle ønsker. Dette er InnoSetup. Jeg skriver om dette her fordi jeg måtte slå det opp i tilfelle jeg sparer noen tid.
Avslag på plugin til fordel for din klient
Jeg skrev tidligere at klientdelen var en nettleser med en "plugin". Så det var tider da Chrome ble oppdatert og oppsettet var litt skjevt, så ble Windows oppdatert og det tilpassede uri-skjemaet forsvant. Jeg ville virkelig ikke ha slike overraskelser i den offentlige versjonen av produktet. Dessuten begynte den tilpassede uri å forsvinne etter hver Windows-oppdatering. Microsoft slettet ganske enkelt alle andre grener i den nødvendige delen. Google Chrome lar deg nå heller ikke huske valget om å åpne eller ikke et program fra den tilpassede urien, og stiller dette spørsmålet hver gang du klikker på et overvåkingsobjekt. Vel, generelt var normal interaksjon med brukerens lokale system nødvendig, noe nettleseren ikke tilbyr. Det enkleste alternativet i denne ordningen ser ut til å være å ganske enkelt lage din egen nettleser, slik mange nå gjør gjennom Electron. Men mange ting var allerede skrevet i Free Pascal, inkludert i serverdelen, så vi bestemte oss for å lage klienten på samme språk, og ikke lage en dyrehage. Slik ble en klient med Chromium om bord skrevet. Etter det begynte den å få forskjellige stropper.
Utgivelse
Til slutt valgte vi et navn på systemet. Vi gikk hele tiden gjennom ulike alternativer mens prosessen med å konvertere fra den lokale versjonen til SaaS var i gang. Siden vi opprinnelig planla å gå inn på ikke bare hjemmemarkedet, var hovedkriteriet for å velge et navn tilstedeværelsen av et ledig eller ikke veldig dyrt domene i ".com"-sonen. Noen funksjoner/moduler er ennå ikke overført fra den lokale versjonen til Veliam, men vi bestemte oss for at vi skulle gi dem ut med gjeldende funksjonalitet og fullføre resten som oppdateringer. I den aller første versjonen var det ingen HelpDesk, Veliam Connector, det var umulig å endre terskelverdiene for varslingsutløsere og mye mer. Vi kjøpte et kodetegnsertifikat og signerte klient- og serverdelene. Vi skrev en nettside for produktet, startet prosedyrer for registrering av programvare, et varemerke osv. Generelt er vi klare til å starte. En liten eufori fra arbeidet som er utført og fra det faktum at noen kanskje vil bruke produktet ditt, selv om vi ikke var i tvil om dette. Og så stopp. Partneren sa at det er umulig å komme inn på markedet uten varsler via messengers. Det er mulig uten mange andre ting, men ikke uten dette. Etter litt debatt ble integrasjon med Telegram lagt til, noe som passet oss. Av alle gjeldende direktemeldinger, er dette den eneste som gir tilgang til API-ene sine gratis og uten noen komplekse godkjenningsprosedyrer. Den samme WhatsApp foreslår å kontakte leverandører som krever gode penger for å bruke tjenestene deres; alle brev som ber om tilgang uten pakninger ble ignorert. Vel, Viber... Jeg vet ikke hvem som bruker det nå, fordi... spam og reklame er utenfor listene. I slutten av desember, etter en rekke interne tester og tester blant venner, ble registreringen åpnet for alle og programvaren ble gjort tilgjengelig for nedlasting.
Start av distribusjon
Helt fra begynnelsen forsto vi at vi trengte en liten flyt av systembrukere slik at de kunne teste produktet i kampmodus og gi noen første tilbakemeldinger. Flere innkjøpte innlegg på VK bar frukter. De første påmeldingene har kommet.
Her skal det sies at det er svært vanskelig å komme inn på markedet når bedriften din ikke har et kjent navn, og samtidig tilby agentløs overvåkingsfunksjonalitet der du må legge inn kontoer fra servere og arbeidsstasjoner. Dette skremmer mange mennesker. Vi forsto helt fra starten at det ville bli problemer med dette og var forberedt på dette både teknisk og moralsk. Alle eksterne tilkoblinger, til tross for at RDP og SSH allerede er kryptert som standard, blir i tillegg kryptert av programvaren vår ved hjelp av AES-standarden. All data fra lokale servere overføres til skyen via HTTPS. Kontoer lagres i kryptert form. Krypteringsnøkler for alle undersystemer er individuelle for alle klienter. For eksterne tilkoblinger brukes vanligvis øktkrypteringsnøkler.
Alt vi kan gjøre i denne situasjonen for å få folk til å føle seg roligere er å være så åpne som mulig, jobbe med sikkerhet og aldri bli lei av å svare på folks spørsmål.
For mange oppveier bekvemmeligheten og funksjonaliteten til programvaren frykten, og de registrerer seg. Noen individer skrev i publiserte innlegg på VK at denne programvaren ikke kan brukes pga Dette er en samling av passordene deres og generelt et firma uten navn. Det må sies at mer enn én person hadde denne oppfatningen. Mange mennesker forstår ganske enkelt ikke at når de installerer annen proprietær programvare på en server som kjører som en tjeneste, har den også fulle rettigheter i systemet, og de trenger ikke kontoer for å gjøre noe ulovlig (det er klart at du kan endre bruker som tjenesten er lansert fra, men også her kan du angi hvilken som helst konto). Faktisk er folks frykt forståelig. Å installere programvare på en server er en vanlig ting, men å legge inn en konto er litt skummelt og intimt, siden en god halvpart av mennesker har samme passord for alle tjenester, og å opprette en egen konto selv for en test er lat. Men for øyeblikket er det et stort antall tjenester som folk stoler på med sin legitimasjon og mer. Og vi streber etter å bli en av dem.
Det var mange kommentarer som sa at vi stjal den et sted. Dette overrasket oss litt. Vel, ok, meningen til en person, men slike kommentarer ble funnet i forskjellige publikasjoner fra forskjellige mennesker. Først visste de ikke hvordan de skulle reagere på dette. Enten for å være trist over at noen har den oppfatning at i Russland kan ingen gjøre noe på egenhånd, men bare stjele, eller for å være glad for at de tror at dette bare kan stjeles.
Vi har nå fullført prosedyren for å få et EV-kodeskiltsertifikat. For å få det, må du gå gjennom en rekke kontroller og sende en haug med dokumenter om selskapet, hvorav noen må attesteres av en advokat. Å få et EV Code Sign-sertifikat under en pandemi er et eget emne for en artikkel. Prosedyren tok en måned. Og det var ikke en måned med venting, men med konstante forespørsler om ytterligere dokumenter. Kanskje pandemien ikke hadde noe med det å gjøre, og prosedyren tok så lang tid for alle? Dele.
Noen sier at vi ikke vil bruke det fordi det ikke er noe FSTEC-sertifikat. Vi må forklare at vi ikke kan skaffe det og ikke vil fordi for å få dette sertifikatet, må kryptering være i samsvar med GOST, og vi planlegger å distribuere programvaren ikke bare i Russland og bruke AES.
Alle disse kommentarene sår en viss tvil om at det er mulig å markedsføre et produkt som krever at du legger inn kontoer uten å være offentlig kjent. Selv om vi visste at det ville være de som hadde en veldig negativ holdning til dette. Etter at antallet påmeldinger passerte tusen, sluttet vi å tenke på det. Spesielt etter, i tillegg til negativiteten til de som ikke en gang hadde prøvd produktet, begynte det å dukke opp veldig hyggelige anmeldelser. Det må sies at disse positive anmeldelsene er den største motivatoren for produktutvikling.
Legger til funksjonalitet for ekstern tilgang for ansatte
En av de hyppige oppgavene fra klienter er "gi Vanya tilgang til datamaskinen hans hjemmefra." Vi tok opp VPN på Mikrotik og opprettet kontoer for brukere. Men dette er et reelt problem. Brukere kan ikke se instruksjonene og følge dem trinn for trinn for å koble til via VPN. Ulike versjoner av Windows. I ett Windows henger alt godt sammen, i et annet trengs en annen protokoll. Og generelt var dette alltid forbundet med rekonfigurering av nettverksutstyr, som fungerte som en VPN-server, og ikke alle ansatte har tilgang til det, og dette var upraktisk.
Men vi har allerede fjerntilkoblinger til servere og nettverksutstyr. Hvorfor ikke bruke en ferdig transport og lage et eget lite verktøy som du enkelt kan gi til brukeren for å koble til. Jeg ville bare forsikre meg om at brukeren ikke skrev noe abstrut der. Bare én knapp "koble til". Men hvordan vil dette verktøyet forstå hvor det skal kobles til hvis det bare har én knapp? Det var en idé å bygge den nødvendige applikasjonen online på våre servere. Systemadministratoren klikker på «last ned snarvei»-knappen, og en kommando sendes til skyen vår for å bygge en individuell binær med kablet informasjon for å koble til ønsket server/datamaskin via RDP. Generelt kan dette gjøres. Men dette tar lang tid; administratoren må først vente til binærfilen er kompilert og deretter lastet ned. Selvfølgelig ville det være mulig å ganske enkelt legge til en andre fil med konfigurasjonen, men dette er allerede 2 filer, og for enkelhets skyld trenger brukeren en. Én fil, én knapp og ingen installasjonsprogrammer. Etter å ha lest litt på Google, kom jeg til den konklusjonen at hvis du legger til litt informasjon på slutten av den kompilerte ".exe", så blir den ikke dårligere (vel, nesten). Du kan i det minste legge til krig og fred der, og det vil fungere som før. Det ville være synd å ikke utnytte dette. Nå kan du ganske enkelt pakke ut applikasjonen mens du er på farten, rett i selve klienten, forresten den heter Veliam Connector, og ganske enkelt legge til informasjonen som er nødvendig for å koble til den på slutten. Og applikasjonen selv vet hva den skal gjøre med den. Hvorfor skrev jeg «vel nesten» i parentes litt høyere? Fordi du må betale for denne bekvemmeligheten ved at applikasjonen mister sin digitale signatur. Men på dette stadiet tror vi at dette er en liten pris å betale for en slik bekvemmelighet.
Tredjeparts modullisenser
Jeg skrev allerede ovenfor at etter at det ble besluttet å gjøre produktet offentlig tilgjengelig, og ikke bare for eget bruk, måtte vi jobbe hardt og se etter erstatninger for noen moduler som ikke lot oss inkludere i produktet vårt. Men etter utgivelsen ble det ved et uhell oppdaget en veldig ubehagelig ting. Veliam Server, som var på klientsiden, inkluderte MariaDB DBMS. Og det er GPL-lisensiert. GPL-lisensen innebærer at programvaren må være åpen kildekode, og hvis produktet vårt inkluderer MariaDB, som har denne lisensen, må produktet vårt være under denne lisensen. Men heldigvis er formålet med denne lisensen åpen kildekode, og straffer ikke de som ved et uhell gjør feil i retten. Hvis rettighetshaveren har et krav, gir han skriftlig beskjed til overtrederen, og han må fjerne bruddet innen 30 dager. Vi oppdaget feilen vår selv og mottok ingen brev og begynte umiddelbart å vurdere alternativer for hvordan vi skulle løse problemet. Løsningen viste seg å være åpenbar - bytt til SQLite. Denne databasen har ingen lisensieringsbegrensninger. De fleste moderne nettlesere bruker SQLite, og en haug med andre programmer. Jeg fant informasjon på Internett om at SQLite regnes som den mest utbredte DBMS i verden, nettopp på grunn av nettleserne, men jeg lette ikke etter bevis, så dette er unøyaktig informasjon. Jeg begynte å studere farene ved å bytte til SQLite.
Dette blir en ikke-triviell oppgave når klienter har flere hundre servere installert med MariaDB og data i den. Noen MariaDB-funksjoner er ikke tilgjengelige i SQLite. Vel, for eksempel, i koden brukte vi spørringer som
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Denne konstruksjonen gjør ikke bare et utvalg fra tabellen, men låser også raddataene. Og flere flere design måtte også skrives om. Men i tillegg til at vi måtte skrive om mange spørringer, måtte vi også komme opp med en mekanisme som ved oppdatering av klientens Veliam-server ville portere alle dataene til det nye DBMS og slette det gamle. Dessuten fungerte ikke transaksjoner i SQLite, og dette var et reelt problem. Men etter å ha lest omfanget av World Wide Web, fant jeg uten problemer at transaksjoner i SQLite kan aktiveres ved å sende en enkel kommando når du kobler til
PRAGMA journal_mode=WAL;Som et resultat ble oppgaven fullført og nå kjører klientens serverdel på SQLite. Vi merket ingen endringer i driften av systemet.
Ny HelpDesk
Det var nødvendig å portere HelpDesk-systemet fra den interne versjonen til SaaS-versjonen, men med noen endringer. Det første jeg ønsket å gjøre var integrasjon med klientens domene i form av transparent brukerautorisasjon i systemet. Nå, for å logge på HelpDesk og legge igjen en forespørsel i systemet, klikker brukeren ganske enkelt på snarveien på skrivebordet og nettleseren åpnes. Brukeren oppgir ingen legitimasjon. Modulen for Apache SSPI, som er en del av Veliam Server, autoriserer automatisk brukeren under en domenekonto. For å legge igjen en forespørsel i systemet når brukeren er utenfor bedriftsnettverket, klikker han på en knapp og han mottar en lenke i e-posten som han logger inn på HelpDesk-systemet uten passord. Hvis en bruker er deaktivert eller slettet i et domene, slutter også HelpDesk-kontoen å fungere. Dermed trenger ikke systemadministratoren selv å overvåke kontoer i både domenet og HelpDesk. En ansatt slutter - han kobler fra kontoen sin i domenet og det er det, han vil ikke logge på systemet ikke fra bedriftens nettverk, ikke via en lenke. For at denne integrasjonen skal fungere, må systemadministratoren opprette ett GPO, som и .
Den andre tingen vi anser som ekstremt nødvendig for HelpDesk-systemer, i hvert fall for oss selv, er å koble til søkeren direkte fra applikasjonen med ett klikk. Dessuten må tilkoblinger passere hvis systemadministratoren er på et annet nettverk. For outsourcing er dette obligatorisk, for heltidsansatte systemadministratorer er det også ofte svært nødvendig. Det er allerede flere produkter som gjør en utmerket jobb med eksterne tilkoblinger. Og vi bestemte oss for å lage integrasjoner for dem. Vi har nå integrert for VNC, og i fremtiden planlegger vi å legge til Radmin og TeamViewer. Ved å bruke nettverkstransporten vår for eksterne infrastrukturforbindelser, fikk vi VNC til å koble til eksterne arbeidsstasjoner bak NAT. Det samme vil skje med Radmin. Nå, for å koble til en bruker, trenger du bare å klikke på "koble til søker"-knappen i selve applikasjonen. VNC-klienten åpner og kobler seg til søkeren, uansett om du er på samme nettverk eller sitter hjemme i tøfler. Først må systemadministratoren, ved hjelp av GPO, installere VNC Server på alles arbeidsstasjoner.
Nå går vi selv over til den nye HelpDesk og bruker integrasjon med domenet og VNC. Dette er veldig praktisk for oss. Nå kan vi slippe å betale for TeamViewer, som vi har brukt i mer enn tre år for å drive supporttjenesten vår.
Hva planlegger vi å gjøre videre?
Da vi ga ut produktet, laget vi ingen betalte tariffer, men begrenset rett og slett gratistariffen til 50 overvåkingsobjekter. Fem dusin nettverksenheter og servere burde være nok for alle, tenkte vi. Og så begynte det å komme inn forespørsler om å øke grensen. Å si at vi ble litt sjokkert er å si ingenting. Er selskaper som har så mange servere virkelig interessert i programvaren vår? Vi utvidet grensen gratis for de som kom med slike forespørsler. Som svar på forespørselen deres spurte vi noen hvorfor de trengte så mye, hadde de virkelig et så stort antall servere og nettverksutstyr. Og det viste seg at systemadministratorer begynte å bruke systemet på måter vi ikke hadde planlagt i det hele tatt. Alt viste seg å være enkelt - programvaren vår begynte å overvåke ikke bare servere, men også arbeidsstasjoner. Derfor er det mange forespørsler om å utvide grensene. Nå har vi allerede innført betalte tariffer og grensene kan utvides uavhengig.
Servere fungerer nesten alltid med enten lagringssystemer eller lokale disker i en RAID-array. Og vi laget først produktet for dem. Og SMART-overvåking var ikke interessant for denne oppgaven. Men tatt i betraktning at folk har tilpasset programvare for overvåking av arbeidsstasjoner, har det dukket opp forespørsler om implementering av SMART-overvåking. Vi implementerer det snart.
Med bruken av Veliam Connector ble det unødvendig å distribuere en VPN-server i bedriftsnettverket, eller gjøre RDGW, eller bare videresende porter til de nødvendige maskinene for tilkobling via RDP. Mange bruker systemet vårt kun for disse eksterne tilkoblingene. Veliam Connector er kun tilgjengelig for Windows, og noen bedriftsbrukere kobler fra bærbare hjemmemaskiner som kjører MacOS til arbeidsstasjoner eller terminaler på bedriftsnettverket. Og det viser seg at systemadministratoren er tvunget, på grunn av flere brukere, til fortsatt å gå tilbake til spørsmålet om videresending eller VPN. Derfor er vi nå ferdig med å lage en versjon av Veliam Connector for MacOS. Brukere av deres favoritt Apple-teknologi vil også ha muligheten til å koble til bedriftens infrastruktur med ett klikk.
Jeg liker virkelig det faktum at du, med et stort antall systembrukere, ikke trenger å tenke på hva folk trenger og hva som vil være mer praktisk. De skriver selv ønsker, så det er mange utbyggingsplaner for den nærmeste tiden.
Parallelt planlegger vi nå å begynne å oversette systemet til engelsk og distribuere det til utlandet. Vi vet ennå ikke hvordan vi skal distribuere produktet utenfor landet vårt, vi ser etter alternativer. Kanskje det kommer en egen artikkel om dette senere. Kanskje noen som har lest denne artikkelen vil kunne foreslå den nødvendige vektoren, eller han selv vet og vet hvordan han skal gjøre det og vil tilby sine tjenester. Vi setter pris på din hjelp.
Kilde: www.habr.com