Fra outsourcing til utvikling (Del 2)

I den forrige artikkelen, jeg har fortalt om bakgrunnen for opprettelsen av Veliam og om beslutningen om å distribueres gjennom SaaS-systemet. I denne artikkelen vil jeg fortelle om hva som måtte gjøres for at produktet skulle bli offentlig, snarere enn lokalt. Om hvordan distribusjonen startet og hvilke problemer vi støtte på.

Planlegging

Den nåværende serverdelen for brukerne var på Linux. Nærmest hver organisasjon har Windows-servere, noe man ikke kan si om Linux. Den viktigste styrken til Veliam er fjernkoblinger til servere og nettverksutstyr bak NAT. Men denne funksjonaliteten var veldig rigid knyttet til at ruteren måtte være en MikroTik. Og dette ville åpenbart ikke tilfredsstille mange. Jeg begynte først å tenke på å legge til støtte for rutere fra de mest populære produsentene. Men jeg forsto at dette ville være et endeløst kappløp med å utvide listen over støttede merker. I tillegg kan de som allerede støttes, ha varierende sett med kommandoer for endring av NAT-regler fra modell til modell. Den eneste utveien fra situasjonen så ut til å være VPN.

Siden vi bestemte oss for å distribuere produktet, men ikke som open source, kunne vi derfor ikke inkludere ulike biblioteker med åpne lisenser som GPL. Dette er egentlig et eget tema; etter beslutningen om å selge produktet, måtte vi gå gjennom halvparten av bibliotekene fordi de var GPL. Da vi utviklet for oss selv, var det greit. Men for distribusjon var det ikke passende. Den første VPN-en som kommer til tankene, er OpenVPN. Men den er GPL. Det var også et alternativ å bruke den japanske SoftEther VPN. Lisensen tillot inkludering i vårt produkt. Etter noen dagers testing for å integrere det slik at brukeren ikke måtte gjøre noe oppsett eller vite om SoftEther VPN, fikk vi en prototype. Alt så ut til å være i orden. Men av en eller annen grunn følte vi oss fortsatt usikre på denne løsningen, og vi avviste den til slutt. Men vi ga selvfølgelig slipp først etter at vi hadde funnet et annet alternativ. Til slutt fikk vi det til å fungere på vanlige TCP-tilkoblinger. Noen tilkoblinger går gjennom en koordinator, mens andre går direkte gjennom NAT Hole Punching (NHP)-teknologi, som også ble implementert i Free Pascal. Jeg må si at jeg tidligere ikke hadde hørt om NHP i det hele tatt. Det kunne aldri falmet meg inn at man kunne knytte to nettverksenheter som begge befinner seg bak NAT direkte. Jeg studerte emnet, forstod prinsippet bak og begynte å skrive. Det jeg hadde tenkt, ble realisert; brukeren kobles på med ett klikk til ønsket enhet bak NAT via RDP, SSH eller Winbox uten å måtte skrive inn passord eller sette opp VPN. Dessuten går størsteparten av disse tilkoblingene forbi vår koordinator, noe som er gunstig for både ping og kostnadsøkonomien knyttet til disse tilkoblingene.

Oversettelse av serverdelen fra Linux til Windows

Det var flere problemer med overgangen til Windows. Det første var at den innebygde wmic i Windows ikke tillater WQL-forespørsel. I systemet vårt var alt allerede bygget på dem. Og det var noe mer, men jeg husker ikke hvorfor vi endelig ga opp bruken av det. Kanskje forskjellene mellom versjonene av Windows. Det andre problemet var multitråding. Etter å ikke ha funnet et godt tredjepartsverktøy med en 'akseptabel' lisens, startet jeg på nytt IDE Lazarus. Jeg skrev det nødvendige verktøyet. Inn er det ønskede listen over objekter og hvilke spesifikke forespørsel som skal gjøres, og i respons får jeg data. Og alt dette skjer i multitrådet modus. Utmerket.

Etter at jeg hadde konfigurert pthreads for PHP på Windows, trodde jeg at alt ville fungere perfekt, men slik ble det ikke. Etter en tid med feilsøking forsto jeg at pthreads tilsynelatende fungerte, men rett og slett ikke i vårt system. Det ble klart at det var noen spesifikke egenskaper ved hvordan pthreads fungerte i Windows. Og slik var det. Jeg leste dokumentasjonen, og der stod det at antallet tråder er begrenset i Windows, og så vidt jeg husker, var dette ikke eksplisitt nevnt. Dette ble et problem. For når jeg begynte å redusere antall tråder der applikasjonen kunne kjøre, gikk det veldig sakte. Jeg åpnet IDE-en igjen, og til verktøyet ble det lagt til funksjonalitet for multitrådet pinging av objekter. Og i tillegg ble portskanning lagt til. Egentlig, etter dette, ble behovet for pthreads for PHP borte, og det ble ikke lenger brukt. Senere ble det lagt til flere funksjonaliteter i dette verktøyet, og det fungerer den dag i dag. Etter dette ble det laget en installasjonsprogram for Windows, som inkluderte Apache, PHP, MariaDB, selve PHP-applikasjonen og en gruppe verktøy for systeminteraksjon, skrevet i Free Pascal. Når det gjelder installasjonsprogrammet, trodde jeg at dette ville bli raskt løst, siden det er en svært vanlig og nødvendig ting for nesten all programvare. Enten lette jeg på feil måte, eller noe annet. Men jeg fant konstant produkter som enten var for lite fleksible eller dyre og også lite fleksible. Til slutt fant jeg en gratis installasjonsprogram som kan tilpasses enhver ønskemål. Det er InnoSetup. Jeg skriver om dette her fordi jeg måtte lete en del, kanskje jeg kan spare noen tid for andre.

Avslag på plugin til fordel for sin egen klient

Jeg skrev tidligere at klientdelen var en nettleser med et «plugin». Det var tider da Chrome ble oppdatert og layouten ble litt skakk, eller Windows ble oppdatert og den tilpassede URI-skjemaet forsvant. Jeg ønsket absolutt ikke slike overraskelser i den offentlige versjonen av produktet. Dessuten begynte det tilpassede URI-skjemaet å forsvinne etter hver Windows-oppdatering. Microsoft fjernet bare alle ikke-standards grener i den nødvendige seksjonen. Nå tillater heller ikke Google Chrome å huske valget om å åpne applikasjonen fra tilpassede URI-er, og stiller dette spørsmålet hver gang man klikker på overvåkingsobjektet. Generelt sett må det være et normalt samarbeid med brukerens lokale system, noe nettleseren ikke gir. Den enkleste løsningen virker å lage sin egen nettleser, slik mange nå gjør gjennom Electron. Men mange ting var allerede skrevet i Free Pascal, inkludert i serversiden, så vi bestemte oss for å lage klienten i samme språket og ikke skape en dyrehage. Slik ble klienten bygget med Chromium om bord. Etter det begynte den å vokse med forskjellige innpakninger.

Utgivelsen

Endelig valgte vi et navn for systemet. Vi vurderte stadig forskjellige alternativer mens prosessen med å omforme den lokale versjonen til SaaS pågikk. Siden vi først og fremst planla å gå ut på det interne markedet, var det viktigste kriteriet i navneuttaket at det fantes et ledig, eller ikke altfor dyrt domene i “.com”-sonen. Noen funksjoner/moduler var fortsatt ikke blitt portert fra den lokale versjonen til Veliam, men vi bestemte oss for at vi ville slippe med det nåværende funksjonaliteten, mens det gjenstående ville bli ferdigstilt som oppdateringer. Den aller første versjonen hadde ikke HelpDesk, Veliam Connector, det var ikke mulig å endre tersklene for varslingstriggere og mye mer. Vi kjøpte code sign certificate, signerte kunde- og serverdelene. Vi lagde en nettside for produktet, begynte prosedyrene for registrering av programvaren, varemerket osv. Generelt er vi klare til å begynne. En lett eufori over det utførte arbeidet og at det muligens vil bli noen som bruker produktet ditt, selv om vi ikke hadde noen tvil om dette. Og så stopper alt. Partneren vår sa at man ikke kunne gå ut på markedet uten varsler til meldingsapper. Man kan klare seg uten mye annet, men ikke uten dette. Etter korte diskusjoner ble integrasjonen med Telegram lagt til, noe som passet oss. Av alle de nåværende meldingsappene, er dette den eneste som gir gratis tilgang til sitt API uten kompliserte godkjenningsprosedyrer. Den samme WhatsApp ber om å kontakte leverandører som tar seg godt betalt for å bruke tjenestene deres; alle forespørslene om å gi tilgang uten mellomledd har blitt ignorert. Vel, og Viber… Jeg vet ikke hvem som bruker det nå, siden spam og reklame der er avskyelige. På slutten av desember, etter en rekke interne tester og tester blant venner, åpnet vi registreringen for alle og gjorde programvaren tilgjengelig for nedlasting.

Start av distribusjon

Fra starten av forstod vi at vi trengte en liten strøm av brukere av systemet for at de skulle kunne teste produktet under virkelige forhold og gi tilbakemeldinger. Noen betalte innlegg på VK ga resultater. De første registreringene kom inn.

Det er viktig å si at det er veldig utfordrende å komme inn på markedet når selskapet ditt ikke har et kjent navn, samtidig som du tilbyr funksjonaliteten til agentfri overvåkning, der du må angi legitimasjonene for servere og arbeidsstasjoner. Mange mennesker blir skremt av dette. Vi forsto helt fra begynnelsen at det ville bli problemer, og vi var forberedt både teknisk og mentalt. Alle eksterne tilkoblinger, til tross for at RDP og SSH allerede er kryptert som standard, blir også kryptert av programvaren vår etter AES-standarden. Alle data fra lokale servere overføres til skyen via HTTPS. Legitimasjonene lagres i kryptert form. Krypteringsnøklene for alle under-systemer er individuelle for hver kunde. For eksterne tilkoblinger brukes også sesjonskrypteringsnøkler.

Alt vi kan gjøre i denne situasjonen for å gjøre folk mer komfortable, er å være så åpne som mulig, jobbe med sikkerhet og ikke bli slitne av å svare på folks bekymrende spørsmål.

For mange overveier bekvemmelighet og programvarefunksjonalitet frykten, og de registrerer seg. Noen personer har skrevet i publiserte innlegg på VK at denne programvaren ikke kan brukes fordi den samler inn passordene deres og generelt er et ukjent selskap. Det må sies at denne oppfatningen ikke bare var hos én person. Mange forstår ikke at når de installerer annen proprietær programvare på serveren, som kjører som en tjeneste, har den også full tilgang til systemet, og de trenger ikke legitimasjoner for å gjøre noe ulovlig (klart, man kan endre brukeren som tjenesten kjøres under, men det samme gjelder her, man kan angi hvilken som helst legitimasjon). Faktisk er folks bekymringer forståelige. Å installere programvare på serveren er vanlig, men det å angi en legitimasjon er litt skremmende og intimt, siden mange har ett passord for alle tjenester, og det er ofte lat som gjør at de ikke lager en egen konto selv for testing. Men for øyeblikket finnes det et enormt antall tjenester som folk stoler på med sine legitimasjoner og mer. Og vi streber etter å bli en av dem.

Det har vært mange kommentarer av typen at vi har stjålet dette fra et sted. Dette overrasket oss litt. Vel, det er én persons mening, men slike kommentarer har blitt sett i ulike publikasjoner fra forskjellige personer. Vi visste ikke i begynnelsen hvordan vi skulle reagere. Skulle vi bli triste over at noen mener at ingen i Russland kan gjøre noe selv, men bare kan stjele, eller skulle vi være glade for at de mener at slike ting bare kan stjeles.

Vi har nå fullført prosessen med å få EV Code Sign Certificate. For å oppnå dette må man gjennomgå en rekke sjekker og sende inn et stort antall dokumenter om selskapet, hvorav noen må være bekreftet av en advokat. Å få EV Code Sign-sertifikatet under pandemien er for øvrig et tema for en egen artikkel. Prosessen tok en måned. Og det var en måned med kontinuerlige forespørsel om ytterligere dokumenter. Kanskje pandemien ikke har noe med det å gjøre, og alle har hatt en så lang prosess? Del gjerne med oss.

Noen sier at vi ikke vil bruke det fordi vi ikke har FSTEK-sertifikatet. Det er nødvendig å forklare at vi ikke kan få det og ikke vil det, fordi for å få dette sertifikatet må krypteringen være i henhold til GOST, og vi planlegger å distribuere programvare ikke bare i Russland og bruker AES.

Alle disse kommentarene skapte en viss usikkerhet om at det var mulig å promotere et produkt der man må registrere kontoer, uten å være i offentligheten. Selv med tanke på at vi visste at det ville være de som var veldig negative til dette. Etter at antallet registreringer oversteg tusen, sluttet vi å tenke på det. Spesielt etter at vi, i tillegg til negativiteten fra de som ikke engang hadde prøvd produktet, begynte å få svært positive tilbakemeldinger. Det må sies at disse positive tilbakemeldingene er den største motivasjonen for å utvikle produktet.

Legge til funksjonalitet for ekstern tilgang for ansatte

En av de vanlige forespørslene fra kunder er «gjør det slik at Ivan kan få tilgang til datamaskinen sin hjemme». Vi satte opp VPN på Mikrotik og laget kontoer for brukerne. Men dette er virkelig et problem. Brukerne er ikke i stand til å se gjennom instruksjoner og følge dem trinn for trinn for å koble seg til VPN. Ulike versjoner av Windows. I én Windows fungerer det bra, men i en annen kreves det en annen protokoll. Og generelt sett har dette alltid vært knyttet til omkonfigurering av nettverksutstyret som fungerte som VPN-server, og ikke alle ansatte har tilgang til den, noe som har vært upraktisk.

Men har vi ikke allerede fjernkontakter til servere og nettverksutstyr? Hvorfor ikke dra nytte av eksisterende transport og lage et lite program som bare kan gis til brukeren for tilkobling? Jeg ønsket kun å gjøre det slik at brukeren ikke måtte skrive inn noe komplisert. Bare én knapp «tilkoble». Men hvordan skal dette programmet forstå hvor det skal koble seg til, hvis det bare har én knapp? Det var en idé om en nettbasert sammensetning av den nødvendige applikasjonen på våre servere. Systemadministratoren trykker på «last ned snarvei»-knappen, og vi får en kommando til skyen for å bygge en individuell binærfil med innholdet for tilkobling til den nødvendige serveren / datamaskinen via RDP. Generelt kunne dette vært gjort. Men det tar tid, administratoren måtte vente til binærfilen ble kompilert, og deretter lastet ned. Man kunne selvfølgelig bare ha lagt til en annen fil med konfigurasjonen, men det blir allerede to filer, og for enkelhetens skyld trenger brukeren bare én. Én fil, én knapp, og ingen installatører. Etter å ha lest litt på nettet, kom jeg til den konklusjon at hvis man legger til noe informasjon på slutten av den kompilerte “.exe”-filen, så blir den ikke ødelagt (når sant skal sies, nesten). Man kan til og med legge til «Krig og Fred», og den vil fungere som før. Det ville være en skam å ikke utnytte dette. Nå kan man enkelt pakke ut applikasjonen, som for øvrig heter Veliam Connector, direkte i klienten, og ganske enkelt skrive til den den nødvendige informasjonen for tilkobling. Og selve applikasjonen vet hva den skal gjøre med dette. Hvorfor skrev jeg «nesten» i parentes litt lengre oppe? Fordi for denne bekvemmeligheten må man betale med å miste applikasjonens digitale signatur. Men vi anser, på dette tidspunktet, at dette er en liten pris å betale for slik bekvemmelighet.

Lisens for tredjepartsmoduler

Som jeg allerede har nevnt, etter at vi bestemte oss for å gjøre produktet tilgjengelig for allmennheten og ikke bare for eget bruk, måtte vi jobbe en del med å finne erstatninger for enkelte moduler som ikke tillot oss å inkludere dem i produktet vårt. Men etter at vi hadde lansert, oppdaget vi tilfeldigvis noe svært ubehagelig. I Veliam Server, som var installert hos kunden, var det en MariaDB-database. Og den har GPL-lisens. GPL-lisensen krever at programvaren skal ha åpen kildekode, og hvis vår produkt inkluderer MariaDB som har denne lisensen, så må også produktet vårt være under den lisensen. Heldigvis er hensikten med denne lisensen å fremme åpen kildekode, og ikke å straffe de som ved et uhell gjør feil. Hvis rettighetshaver får en klage, må de varsle krenkeren skriftlig, og denne må innen 30 dager rette opp i krenkingen. Vi oppdaget feilen vår selv og fikk ingen brev, og begynte straks å vurdere alternativer for å løse problemet. Løsningen ble åpenbar – vi gikk over til SQLite. Denne databasen har ingen lisensieringsbegrensninger. De fleste moderne nettlesere bruker SQLite, og mange andre programmer også. Jeg fant informasjon på internett om at SQLite anses å være den mest utbredte databasen i verden, akkurat på grunn av nettleserne, men jeg søkte ikke etter bevis, så det kan være unøyaktig informasjon. Jeg begynte å se på konsekvensene av å bytte til SQLite.

Dette blir en ikke-triviell oppgave når det er flere hundre servere installert hos kunder med MariaDB og data i den. Noen funksjoner i MariaDB er ikke tilgjengelige i SQLite. For eksempel brukte vi forespørselstyper som

Select * FROM `table` WHERE `id`>1000 FOR UPDATE

Denne konstruksjonen gjør ikke bare en utvelgelse fra tabellen, men også låser dataene i de radene. Flere andre konstruksjoner måtte også omskrives. Men i tillegg til at vi måtte omskrive mange forespørslener, måtte vi også finne på en mekanisme som under oppdateringen av Veliam Server hos kunden vil portere alle data til den nye databasen og fjerne den gamle. I tillegg fungerte ikke transaksjoner i SQLite, og det var et reelt problem. Men etter å ha sett nærmere på internett, fant jeg uten problemer ut at transaksjoner i SQLite kan aktiveres ved å sende en enkel kommando ved tilkobling.

PRAGMA journal_mode=WAL;

Som oppgaven er gjennomført, og nå fungerer den serverbaserte delen for kundene med SQLite. Vi har ikke merket noen endringer i systemets funksjon.

Ny HelpDesk

Fra den interne versjonen til SaaS-versjonen måtte HelpDesk-systemet porteres, men med noen endringer. Først og fremst ønsket vi å integrere med kundens domene når det kommer til sømløs brukerautentisering i systemet. Nå kan brukeren, for å få tilgang til HelpDesk og legge inn en forespørsel i systemet, ganske enkelt klikke på snarveien på skrivebordet, og nettleseren åpnes. Brukeren trenger ikke å angi noen påloggingsinformasjon. Modulen for Apache SSPI, som er en del av Veliam Server, autentiserer brukeren automatisk med domenekontoen. For å legge inn en forespørsel i systemet når brukeren er utenfor bedriftsnettverket, klikker han på en knapp, og han får tilsendt en lenke på e-post, som lar ham logge inn i HelpDesk uten passord. Hvis en bruker deaktiveres eller slettes i domenet, vil også kontoen i HelpDesk slutte å fungere. På den måten trenger systemadministratoren ikke å overvåke kontoene både i domenet og i HelpDesk. Hvis en ansatt har sluttet, deaktiverer han kontoen i domenet, og det er det; han får ikke tilgang til systemet verken fra bedriftsnettverket eller via lenken. For å få denne integrasjonen til å fungere, må systemadministratoren opprette en GPO som legger til det interne nettstedet i intranettsonen og fordeler snarveien til alle brukere på skrivebordet.

Det andre vi anser som helt nødvendig for HelpDesk-systemer, i alle fall for oss selv, er å kunne koble til søker direkte fra forespørselen med ett klikk. Videre må tilkoblinger fungere selv om systemadministratoren befinner seg i et annet nettverk. Dette er obligatorisk for outsourcet support, og for interne systemadministratorer er det også ofte veldig nødvendig. Det finnes allerede flere produkter som utmerket håndterer oppgaven med eksterne tilkoblinger. Og vi har bestemt oss for å lage integrasjoner for dem. Nå har vi laget en integrasjon for VNC, og i fremtiden planlegger vi å legge til Radmin og TeamViewer. Ved å bruke vår nettverksløsning for eksterne tilkoblinger til infrastrukturen, har vi fått til at VNC kobler seg til eksterne arbeidsstasjoner bak NAT. Det samme vil skje med Radmin. Nå, for å koble til brukeren, trenger man bare å trykke på knappen "koble til søker" i selve forespørselen. VNC-klienten åpner seg og kobler til søkeren uansett om man er på samme nettverk eller sitter hjemme i slippers. På forhånd må systemadministratoren installere VNC Server på alle arbeidsstasjoner ved hjelp av GPO.

Nå går vi selv over til det nye HelpDesk og bruker integrasjonen med domenet og VNC. Det er veldig praktisk for oss. Nå kan vi unngå å betale for TeamViewer, som vi har brukt i mer enn tre år for å drive vår supporttjeneste.

Hva planlegger vi å gjøre videre

Da vi lanserte produktet, hadde vi ingen betalte abonnementer, men begrenset det gratis abonnementet til 50 overvåkingsobjekter. Femti nettverksenheter og servere burde være tilstrekkelig for alle, tenkte vi. Og så begynte forespørslene om å øke grensen å komme inn. Å si at vi var litt sjokkerte, ville være en underdrivelse. Var det virkelig selskaper med så mange servere som var interessert i programvaren vår? Vi utvidet gratis grensen for dem som sendte slike forespørselen. Hos noen spurte vi, som svar på deres forespørsel, hvorfor de trengte så mange, hadde de virkelig så mange servere og nettverksutstyr? Det viste seg at systemadministratorene begynte å bruke systemet på en måte vi overhodet ikke hadde planlagt. Alt viste seg å være enkelt — programvaren vår begynte å overvåke ikke bare serverne, men også arbeidsstasjonene. Derav mange forespørselene om utvidelse av grensen. Nå har vi allerede innført betalte abonnementer, og grensene kan utvides selvstendig.

Servere jobber nesten alltid med SAN eller med lokale disker i RAID-array. Og vi hadde opprinnelig utviklet produktet for dem. SMART-overvåkning var ikke interessant for denne oppgaven. Men med tanke på at folk tilpasset programvaren for overvåkning av arbeidsstasjoner, dukket det opp forespørselene om å implementere SMART-overvåkning. Snart vil vi implementere det.

Med introduksjonen av Veliam Connector, ble det unødvendig å sette opp en VPN-server i det bedriftsnettverket, eller lage RDGW, eller bare forwarde porter til de nødvendige maskinene for tilkobling via RDP. Mange bruker systemet vårt bare for disse eksterne tilkoblingene. Veliam Connector er kun tilgjengelig for Windows, og noen bedriftsbrukere kobler seg fra sine hjemmebærbare datamaskiner som kjører MacOS til arbeidsstasjoner eller terminaler i bedriftsnettverket. Og det viser seg at systemadministratorene må gjenoppta spørsmålet om portforwarding eller VPN på grunn av noen få brukere. Derfor er vi nå ferdige med å lage en versjon av Veliam Connector for MacOS. Brukerne av sin foretrukne Apple-teknologi vil også få muligheten til å koble seg til bedriftsinfrastrukturen med ett klikk.

Det er veldig bra at når det er mange brukere av systemet, trenger man ikke å tenke for mye på hva folk ønsker og hva som vil være mer praktisk. De skriver selv sine ønsker, så det er mange planer for utvikling i løpet av den nærmeste tiden.

Samtidig planlegger vi nå å oversette systemet til engelsk og spre det internasjonalt. Vi vet ikke ennå hvordan vi skal distribuere produktet utenfor vårt land, og leter etter løsninger. Kanskje det senere vil komme en egen artikkel om dette. Kanskje noen av de som har lest denne artikkelen kan gi nyttig retning, eller vet og kan hvordan dette gjøres og tilbyr sine tjenester. Vi vil sette pris på hjelpen.

Kilde: habr.com