Iz aoutsorsa u razvoj (Deo 2)

V prejšnjem članku, sem opisal ozadje nastanka Veliam in rešitev za njegovo širitev preko sistema SaaS. V tem članku bom opisal, kaj vse je bilo potrebno, da je izdelek postal javno dostopen, ne le lokalno omejen. O tem, kako smo začeli širitev in s katerimi težavami smo se srečali.

Načrtovanje

Trenutni strežnik za uporabnike je deloval na Linuxu. V skoraj vsaki organizaciji so Windows strežniki, kar pa ne moremo reči za Linux. Osnovna prednost Veliam-a je oddaljeno povezovanje s strežniki in omrežno opremo za NAT. Vendar je bila ta funkcionalnost zelo strogo povezana z zahtevami, da mora biti usmerjevalnik nujno Mikrotik. In to bi očitno mnoge razburilo. Sprva sem razmišljal o dodajanju podpore za usmerjevalnike najbolj razširjenih proizvajalcev. A sem se zavedal, da gre za neskončno dirko z razširjanjem seznama podprtih podjetij. Poleg tega imajo lahko modeli, ki že podpirajo, različen nabor ukazov za spreminjanje pravil NAT. Edina rešitev v tej situaciji se mi je zdela VPN.

Ker smo se odločili, da izdelek distribuiramo, vendar ne kot odprto kodo, je bilo nemogoče vključiti različne knjižnice z odprtimi licencami, kot je GPL. To je sploh posebna tema; po sprejetju odločitve o prodaji izdelka smo morali preučiti polovico knjižnic, saj so bile pod GPL. Ko smo to delali zase, je bilo v redu. Ampak za distribucijo ne ustreza. Prvi VPN, ki mi pride na misel, je OpenVPN. Ampak je GPL. Druga možnost je bila uporabiti japonski SoftEther VPN. Njegova licenca je omogočala vključitev v naš izdelek. Po nekaj dneh različnih testov, kako ga integrirati tako, da uporabnik ne bi moral ničesar nastavljati ali vedeti o SoftEther VPN, smo dobili prototip. Vse je bilo tako, kot mora biti. Vendar nas je ta zasnova nekako zmotila, zato smo se na koncu odločili za nekaj drugega. Na koncu smo vse naredili na običajnih TCP povezavah. Del povezav deluje preko koordinatorja, del direktno preko tehnologije Nat Hole Punching (NHP), ki je bila prav tako realizirana na Free Pascal. Moram reči, da o NHP-ju prej sploh nisem slišal. In ni mi moglo na misel, da lahko povežeš dve omrežni napravi, ki sta obe za NAT, neposredno. Tematiko sem preučil, razumel princip dela in se lotil pisanja. Kar smo zamislili, smo uresničili; uporabnik se poveže z enim klikom na želeno napravo za NAT preko RDP, SSH ali Winbox brez vnosa gesel in nastavitve VPN. In večina teh povezav gre mimo našega koordinatorja, kar ugodno vpliva na latenco in stroške vzdrževanja teh povezav.

Prevod strežniškega dela s Linux na Windows

Pri prehodu na Windows je bilo več težav. Prva je bila, da vgrajen wmic v Windows ne omogoča WQL poizvedb. Naša sistemska rešitev je bila že v celoti zgrajena na njih. In bilo je še nekaj drugega, vendar se trenutno ne spomnim, zakaj smo se končno odločili, da ga ne bomo več uporabljali. Morda so razlike med različicami Windows. Druga težava je bila večnitnost. Ker nisem našel dobre zunanje utilite pod 'sprejemljivo' licenco, sem ponovno zagnal IDE Lazarus. In napisal sem potrebno utilito. Na vhod pride potrebni seznam predmetov in katere točno poizvedbe je treba opraviti, na izhodu pa prejmem podatke. In vse to v večnitnem načinu. Odlično.

Ko sem konfiguriral pthreads za PHP Windows, sem mislil, da bo vse takoj delovalo, a ni bilo tako. Po nekaj časa odpravljanja napak sem ugotovil, da pthreads deluje, vendar za naš sistem ne. Postalo je jasno, da obstajajo posebnosti pri delovanju pthreads v Windows. In res je bilo tako. Prebral sem dokumentacijo, kjer je bilo zapisano, da je število niti v Windows omejeno, in kar se spomnim, je bilo to implicitno. To je predstavljalo težavo. Ko sem začel zmanjševati število niti, pri katerih je aplikacija delovala, je ta delovala zelo počasi. Spet sem odprl IDE in v to orodje dodal funkcionalnost za večnitenjsko pinganje objektov. Vseeno sem dodal tudi skeniranje izhodnih vrat. Po tem je potreba po pthreads za PHP izginila, in več se ne uporablja. V to orodje je bilo dodanih še več funkcionalnosti, in še danes deluje. Po tem sem sestavil namestitveni program za Windows, ki je vseboval Apache, PHP, MariaDB, samo PHP aplikacijo in nabor orodij za komunikacijo s sistemom, napisanih v Free Pascal. Kar se tiče namestitvenega programa, sem mislil, da bom to vprašanje hitro rešil, saj je to izredna in skoraj vsaki programski opremi potrebna stvar. Ali pa sem morda iskal narobe, ali pa še kaj drugega. Vendar sem nenehno naletel na izdelke, ki so bili bodisi premalo prilagodljivi bodisi dragi in še vedno neprilagodljivi. Kljub temu sem našel brezplačni namestitveni program, ki omogoča upoštevanje vseh želja. To je InnoSetup. O tem pišem, ker mi je bilo potrebno poiskati, da bi mogoče komu prihranil čas.

Zavrnitev vtičnika v prid lastnemu klientu

Prej sem pisal, da je bila odjemalska komponenta brskalnik z "vtičnikom". Bili so časi, ko se je Chrome posodabljal in se je postavitev nekoliko popačila, ali pa se je Windows posodabljal in so se izgubili custom uri sheme. Res ni bilo želeli imeti takšne vrste presenečenj v javni različici izdelka. Poleg tega so se custom uri začeli izgubljati po vsaki posodobitvi Windows. Microsoft je preprosto odstranil vse ne njegove veje v ustreznem razdelku. Poleg tega Google Chrome zdaj ne dovoljuje shranjevanja izbire o tem, ali odpreti aplikacijo iz custom uri, in postavlja to vprašanje pri vsakem kliku na spremljani objekt. Na splošno je bilo potrebno normalno sodelovanje z lokalnim sistemom uporabnika, česar brskalnik ne omogoča. Najpreprostejša rešitev v taki shemi se zdi preprosto narediti svoj brskalnik, kot to zdaj mnogi počnejo prek Electron. A veliko stvari je bilo že napisanih v Free Pascalu, vključno s strežniškim delom, zato smo se odločili, da bomo tudi odjemalca naredili v istem jeziku in ne ustvarjali živalskega vrta. Tako je bil napisan odjemalec s Chromiumnom na krovu. Po tem se je začel obsevati z različnimi obvezami.

Izdaja

Nazad do poimanja, smo konačno izabrali naziv za sistem. Neprekidno smo razmatrali različite opcije tokom prelaska sa lokalne verzije na SaaS. Pošto smo prvobitno planirali izlazak ne samo na domaće tržište, glavni kriterijum za izbor naziva bila je dostupnost nezauzetog ili ne previše skupog domena u zoni “.com”. Neke funkcije/moduli još nisu bili preneseni sa lokalne verzije na Veliam, ali smo odlučili da ćemo lansirati sa trenutnom funkcionalnošću, a ostalo ćemo završiti kroz ažuriranja. U prvoj verziji nije bilo HelpDesk-a, Veliam Connector-a, nije bilo moguće menjati pragove aktivacije triggera za obaveštenja i mnogo drugih stvari. Kupili smo Code Sign Certificate, potpisali klijent i server strane. Napravili smo veb sajt za proizvod, započeli procedure registracije softvera, zaštite brenda itd. U principu, spremni smo da počnemo. Osećaj je bio lagana euforija od obavljenog posla i mogućnosti da bi neko mogao da koristi naš proizvod, iako u vezi toga nismo imali sumnje. A onda - stop. Partner je rekao da bez obaveštenja u mesindžerima ne možemo izaći na tržište. Može da se ide i bez mnogo drugih stvari, ali ne i bez ovoga. Nakon kratkih rasprava, integrovana je Telegram, što nam je odgovaralo. Od svih trenutnih mesindžera, to je jedini koji besplatno pruža pristup svom API-ju bez komplikovanih procedura odobravanja. WhatsApp, sa druge strane, predlaže da se obratimo provajderima koji naplaćuju dobro za korišćenje njihovih usluga, a svi naši zahtevi za pristup bez posrednika su ignorisani. Pa, što se tiče Viber-a… ne znam ko ga sada koristi, jer spam i reklame su tamo van kontrole. Krajem decembra, nakon niza unutrašnjih testiranja i testiranja među prijateljima, otvorili smo registraciju za sve i postavili softver za preuzimanje.

Početak distribucije

Od samog početka smo shvatili da nam je potreban manji broj korisnika sistema kako bi testirali proizvod u stvarnom režimu i dali neku prvu povratnu informaciju. Nekoliko kupljenih postova na VK donelo je rezultate. Počele su prve registracije.

Treba reći, da je izrada izlaska na tržište, kada vaša kompanija nema poznato ime, a pritom pruža funkcionalnost bezagentnog nadzora, u koju je potrebno uneti naloge sa svojih servera i radnih stanica, veoma teško. Mnoge ljude to plaši. Od samog početka smo shvatili da će tu biti problema i bili smo spremni na to i tehnički i moralno. Sve daljinske veze, bez obzira na to što se RDP i SSH podrazumevano šifruju, dodatno su šifrovane našim softverom po standardu AES. Svi podaci sa lokalnih servera prenose se na oblak putem HTTPS-a. Nalozi se čuvaju u šifrovanom obliku. Ključevi šifrovanja za sve podsisteme su individualni za svakog klijenta. Za daljinske konekcije se uopšte koriste sesijski ključevi šifrovanja.

Sve što možemo učiniti u ovoj situaciji, kako bi ljudima bilo lakše — to je da budemo što otvoreniji, radimo na bezbednosti i neumorno odgovaramo ljudima na pitanja koja ih muče.

Za mnoge je udobnost i funkcionalnost softvera jača od straha, te se registruju. Neki su pojedinci u objavama na VK pisali da ovaj softver ne treba koristiti, jer prikuplja njihove lozinke i uopšte je to firma bez imena. Treba reći da ovo mišljenje nije imalo samo jedna osoba. Mnogi jednostavno ne shvataju da, kada instaliraju drugi proprietarni softver na server, koji radi kao usluga, ima pune privilegije u sistemu i ne trebaju im nalozi kako bi činili nešto ilegalno (jasno je da se može promeniti korisnik pod kojim se usluga pokreće, ali tako je i ovde, može se uneti bilo koja nalog). Zapravo — strah ljudi je razumljiv. Instalacija softvera na server je uobičajena stvar, dok unos naloga deluje malo zastrašujuće i intimno, jer dobra polovina ljudi ima jednu lozinku za sve usluge, a biti lenj čak i za kreiranje posebnog naloga za testiranje. Međutim, trenutno postoji ogroman broj usluga kojima ljudi veruju sa svojim podacima i ne samo to. A mi težimo da postanemo jedan od njih.

Veliko komentarjev je bilo v smislu, da smo to nekje ukradli. To nas je nekoliko presenetilo. No, dobro mnenje enega človeka, ampak taki komentarji so se pojavljali v različnih publikacijah od različnih ljudi. Sprva nismo vedeli, kako naj se na to odzovemo. Ali naj žalujemo, ker nekateri ljudje menijo, da v Rusiji nihče ne more ničesar narediti sam, ampak lahko le ukrade, ali naj se veselimo, da menijo, da je to mogoče le ukrasti.

Sedaj smo zaključili postopek pridobitve EV Code Sign Certificate. Da bi ga pridobili, je treba opraviti vrsto preverjanj in poslati kup dokumentov o podjetju, del katerih mora overiti odvetnik. Pridobitev EV Code Sign certifikata v pogojih pandemije je pravzaprav ločena tema za članek. Postopek je trajal mesec dni. In to ni bil mesec čakanja, temveč nenehnih zahtevkov po dodatnih dokumentih. Morda pandemija ni povezana s tem, in so vsi imeli postopek tako dolgotrajen? Delite.

Nekateri pravijo, da ne bomo uporabljali, ker nimamo FSTEK certifikata. Moramo razložiti, da ga ne moremo pridobiti in ne bomo, ker mora biti šifriranje po GOST, mi pa načrtujemo širitev programske opreme ne le v Rusiji in uporabljamo AES.

Vsi ti komentarji so budili določeno negotovost v tem, da je mogoče promovirati izdelek, pri katerem je treba vnesti uporabniške račune, ne da bi bili pri tem na ušesih. Tudi ob upoštevanju, da smo vedeli, da bodo tisti, ki so zelo negativno nastrojeni do tega. Po tem, ko je število registracij preseglo tisoč, smo prenehali razmišljati o tem. Še posebej po tem, ko so poleg negativnih mnenj tistih, ki izdelka še niso preizkusili, začele prihajati tudi zelo pozitivne ocene. Treba je reči, da so te pozitivne ocene najboljši motivator za razvoj produkta.

Dodajanje funkcionalnosti oddaljenega dostopa za zaposlene

Ena iz pogostih nalog strank je "omogočite Vani dostop do njegovega računalnika od doma". Postavili smo VPN na Mikrotiku in ustvarili uporabniške račune. A to je resnično težava. Uporabniki niso sposobni gledati navodil in jih po korakih izvesti, da se povežejo preko VPN. Različne različice Windows. Pri eni različici Windows se vse lepo poveže, pri drugi pa potrebuje drug protokol. Na splošno je to vedno zahtevalo ponovno nastavitev omrežne opreme, ki je bila VPN strežnik, in ne vsi zaposleni imajo dostop do tega, kar je bilo neprijetno.

Ampak že imamo oddaljene povezave do strežnikov in omrežne opreme. Zakaj ne bi izkoristili obstoječega prevoza in naredili ločeno, majhno utiliteto, ki bi jo preprosto dali uporabniku za povezovanje? Želeli smo le, da uporabnik ne bi vnašal zapletenih informacij. Preprosto en gumb 'poveži se'. Ampak kako bo ta utilita vedela, kam se povezati, če ima le en gumb? Imeli smo idejo o spletnem sestavljanju potrebne aplikacije na naših strežnikih. Sistemskih administrator pritisne gumb 'prenesi bližnjico', in v naše oblak pride ukaz za sestavljanje individualnega binarja z vgrajenimi informacijami za povezovanje na želeni strežnik / računalnik prek RDP. Na splošno bi bilo to mogoče. Ampak bi trajalo dolgo, administrator bi moral najprej počakati, da se binarni program sestavi, potem pa še, da se prenese. Seveda bi lahko preprosto dodali še en datoteko s konfiguracijo, ampak to bi pomenilo dve datoteki, za enostavnost pa uporabnik potrebuje eno. Ena datoteka, en gumb in brez namestitvenih programov. Po malo raziskovanju Googla sem prišel do zaključka, da, če na konec sestavljenega '.exe' dodamo kakšne informacije, se ne pokvari (no, skoraj). Tja lahko dodamo celo vojne in mir, in bo delovalo kot prej. Greh bi bilo tega ne izkoristiti. Zdaj lahko enostavno na mestu razpakiramo aplikacijo, ki se imenuje Veliam Connector, in preprosto dodamo potrebne informacije za povezovanje na njegov konec. A sama aplikacija ve, kaj z njim narediti. Zakaj sem prej v oklepaju napisal 'no, skoraj'? Ker za to udobje moramo plačati s tem, da aplikacija izgubi svojo digitalno podpisano potrdilo. Ampak mi, v tem trenutku, menimo, da je to majhna cena za to udobje.

Licence tretjih modulov

V zgornjem besedilu sem že omenil, da je bilo po odločitvi, da postane izdelek javno dostopen in ne samo za osebno uporabo, potrebno veliko dela in iskanja zamenjav za nekatere module, ki niso omogočali vključitve v naš izdelek. Po izdaji pa smo naključno odkrili precej neprijetno zadevo. V okviru Veliam Serverja, ki je bil na strani odjemalca, je bila podatkovna baza MariaDB. Ta pa ima licenco GPL. Licenca GPL predvideva, da mora biti programska oprema z odprtokodnim izvorom, in če v našem izdelku vključimo MariaDB, ki ima to licenco, mora biti tudi naš izdelek pod to licenco. Na srečo pa je cilj te licence odprto kodiranje in ne kaznovanje pred sodiščem tistih, ki so naleteli na napako. Če se imetnik pravic pritoži, vas pisno obvesti, vi pa morate v 30 dneh odpraviti kršitev. Svojo napako smo odkrili sami, nismo prejeli nobenih pisem in takoj smo začeli razmišljati o rešitvah. Odgovor se je izkazal za očitnega — prehod na SQLite. Ta baza podatkov nima nobenih omejitev glede licenciranja. Večina sodobnih brskalnikov uporablja SQLite, pa tudi mnogo drugih programov. Našel sem informacije na spletu, da je SQLite najbolj razširjena podatkovna baza na svetu, predvsem zaradi brskalnikov, toda nisem iskal dokazov, zato so to netočni podatki. Začel sem raziskovati, kakšne posledice prinaša prehod na SQLite.

Postaja že netrivialna naloga, ko imamo na stotinah strežnikov pri strankah nameščeno MariaDB in podatke v njej. Nekatere funkcije MariaDB niso na voljo v SQLite. Na primer, v kodi smo uporabljali poizvedbe tipa

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

Ta konstrukcija ne le da izbere podatke iz tabele, ampak tudi zaklene te vrstice. Še nekaj konstrukcij je bilo treba prepisati. Poleg tega, da sem moral prepisati veliko poizvedb, je bilo tudi treba razviti mehanizem, ki ob posodobitvi Veliam Serverja pri stranki prenese vse podatke v novo podatkovno bazo in odstrani staro. Poleg tega transakcije v SQLite niso delovale, kar je predstavljalo resno težavo. A po branju po svetu interneta sem brez težav našel, da je mogoče transakcije v SQLite vključiti s preprostim ukazom pri povezavi.

PRAGMA journal_mode=WAL;

Система успешно выполнена, и теперь серверная часть клиентов работает на SQLite. Мы не заметили никаких изменений в работе системы.

Новая HelpDesk

Необходимо было перенести систему HelpDesk из внутренней версии в SaaS, при этом с рядом изменений. Первое, что хотелось бы сделать, — это интеграция с доменом клиента для прозрачной авторизации пользователей в системе. Сейчас пользователь, чтобы зайти в HelpDesk и оставить запрос, просто нажимает на ярлык на рабочем столе, и открывается браузер. Пользователь не вводит никаких учетных данных. Модуль для Apache SSPI, который входит в состав Veliam Server, автоматически авторизует пользователя под доменной учетной записью. Чтобы оставить запрос в системе, когда пользователь находится вне корпоративной сети, он нажимает на кнопку, и на его почту приходит ссылка, по которой он может авторизоваться в системе HelpDesk без паролей. Если пользователя удалить или отключить в домене, то его учетная запись в HelpDesk также перестанет функционировать. Таким образом, системному администратору не нужно следить за учетными записями как в домене, так и в HelpDesk. Уволился сотрудник — отключил учетную запись в домене, и все, он не сможет зайти в систему ни из корпоративной сети, ни по ссылке. Для работы данной интеграции, системному администратору нужно создать одну GPO, которая добавляет внутренний сайт в зону интрасети in раскидывает ярлык всем пользователям на рабочий стол.

Drugé, čo považujeme za mimoriadne potrebné pre systémy HelpDesk, aspoň pre nás samých — je pripojenie k žiadateľovi priamo z požiadavky na jedno kliknutie. Navyše, pripojenia by mali fungovať, aj keď je systémový administrátor v inej sieti. Pre outsourcing je to nevyhnutné, pre interných systémových administrátorov to tiež býva často veľmi potrebné. Už existuje niekoľko produktov, ktoré skvelo zvládajú úlohu vzdialených pripojení. A rozhodli sme sa pre nich vytvoriť integrácie. Momentálne máme integráciu pre VNC a v budúcnosti plánujeme pridať Radmin a TeamViewer. Použitím našej sieťovej dopravy pre vzdialené pripojenia k infraštruktúre, sme zabezpečili, že VNC sa pripája k vzdialeným pracovným staniciam za NAT. To isté bude platiť aj pre Radmin. Teraz, aby sa mohol pripojiť k používateľovi, stačí v samotnej žiadosti stlačiť tlačidlo “pripojiť sa k žiadateľovi”. Otvorí sa VNC klient a pripojí sa k žiadateľovi bez ohľadu na to, či ste v rovnakej sieti alebo sedíte doma v papučiach. Predtým musí systémový administrátor pomocou GPO nainštalovať VNC Server na všetky pracovné stanice.

Teraz sami prechádzame na nový HelpDesk a používame integráciu s doménou a VNC. To je pre nás veľmi pohodlné. Teraz nemusíme platiť za TeamViewer, ktorý sme používali viac než tri roky pre prácu našej podpory.

Čo plánujeme robiť ďalej

Ko smo izdali izdelek, nismo uvedli nobenih plačljivih tarif, ampak smo preprosto omejili brezplačno različico na 50 objektov za spremljanje. Petdeset omrežnih naprav in strežnikov bi moralo biti dovolj za vse, smo pomislili. In takoj so začeli prihajati zahteve za povečanje limita. Rekli bi, da smo bili nekoliko šokirani — to bi bilo še premalo povedano. Ali so se naše programske opreme res zanimali podjetja, ki imajo toliko strežnikov? Brezplačno smo širili limit za tiste, ki so to zahtevali. Pri nekaterih smo ob njihovem vprašanju vprašali, zakaj toliko — ali res imajo tako veliko število strežnikov in omrežne opreme. In izkazalo se je, da so sistemski skrbniki začeli uporabljati sistem na način, ki ga sploh nismo načrtovali. Vse je bilo preprosto — z našo programsko opremo so začeli spremljati ne samo strežnike, temveč tudi delovne postaje. Odtod tudi veliko povpraševanj po razširitvi limiti. Zdaj smo že uvedli plačljive tarife in omejitve lahko razširite sami.

Strežniki večinoma delujejo bodisi s SAN bodisi z lokalnimi diski v RAID nizih. In prvič smo izdelali izdelek za njih. In spremljanje SMART ni bilo zanimivo za to nalogo. Vendar ob upoštevanju tega, da so ljudje prilagodili programsko opremo za spremljanje delovnih postaj, so se pojavile zahteve po uvajanju spremljanja SMART. Kmalu ga bomo uresničili.

S prihodom Veliam Connectorja, je postalo odveč uvajanje VPN strežnika v podjetniški mreži, ali narediti RDGW, ali preprosto preusmeriti porte do potrebnih naprav za povezovanje prek RDP. Zelo mnogi uporabljajo naš sistem samo za te oddaljene povezave. Veliam Connector je na voljo le za Windows, nekateri uporabniki podjetij pa se povezujejo z domačih prenosnikov, ki delujejo na MacOS, na delovne postaje ali terminale v podjetniški mreži. In tako se zgodi, da je sistemski skrbnik kljub nekaj uporabnikom še vedno prisiljen razmišljati o preusmerjanju ali VPN-ju. Zato zdaj že zaključujemo različico Veliam Connectorja za MacOS. Tisti, ki uporabljajo svojo priljubljeno jabolčno tehnologijo, bodo tudi dobili možnost povezovanja z infrastrukturno podjetja z enim klikom.

Vše mi je zelo všeč, da imeti veliko število uporabnikov sistema ni potrebno razmišljati, kaj ljudje potrebujejo in kaj bi bilo bolj priročno. Sami pišejo svoje želje, tako da imamo veliko načrtov za razvoj v prihodnjem času.

Hkrati načrtujemo, da se zdaj lotimo prevoda sistema v angleščino in njegovega širjenja v tujini. Še ne vemo, kako bomo distribuirali izdelek izven naše države, iščemo možnosti. Morda bo o tem kasneje poseben članek. Morda bo kdo od tistih, ki so prebrali ta članek, lahko predlagal pravi smer, ali pa zna in zna to narediti ter ponudi svoje storitve. Bili bomo hvaležni za pomoč.

Izvor: habr.com