În , am povestit despre istoria creării Veliam și despre decizia de a-l distribui prin sistemul SaaS. În acest articol, voi vorbi despre ce a fost necesar pentru ca produsul să devină nu local, ci public. Despre cum a început distribuția și cu ce probleme ne-am confruntat.
Planificare
Partea serverului actual pentru utilizatori a fost pe Linux. Aproape în fiecare organizație există servere Windows, ceea ce nu se poate spune despre Linux. Principala forță a Veliam este conectarea la distanță la servere și echipamente de rețea în spatele NAT. Dar această funcționalitate era foarte strict legată de faptul că routerul trebuia să fie neapărat un Mikrotik. Și acest lucru ar fi nemulțumit evident pe mulți. La început, am început să mă gândesc la adăugarea suportului pentru routerele celor mai comune furnizori. Dar înțelegeam că aceasta este o cursă nesfârșită cu extinderea listei de companii suportate. Mai mult decât atât, chiar și cele care sunt deja suportate pot avea un set diferit de comenzi pentru modificarea regulilor NAT de la un model la altul. Singura ieșire din situație se vedea ca fiind VPN.
Întrucât am decis să distribuim produsul, dar nu ca open source, nu mai putem include diverse biblioteci cu licențe deschise de tip GPL. Aceasta este o temă separată; după ce am hotărât să vindem produsul, a fost necesar să revizuim jumătate din biblioteci din cauza licenței GPL. Când scriam pentru noi, era în regulă. Dar pentru distribuire, nu este adecvat. Primul VPN care îmi vine în minte este OpenVPN. Dar acesta este GPL. A mai fost opțiunea de a folosi SoftEther VPN din Japonia. Licența acestuia permitea integrarea în produsul nostru. După câteva zile de teste pentru a-l integra astfel încât utilizatorii să nu trebuiască să facă nicio configurație sau să știe despre SoftEther VPN, am obținut un prototip. Totul a decurs bine. Totuși, dintr-un motiv oarecare, această schemă ne-a deranjat, iar la final am renunțat la ea. Desigur, am renunțat doar după ce am conceput o altă variantă. În final, am realizat totul pe conexiuni TCP obișnuite. O parte din conexiuni funcționează printr-un coordonator, iar o parte direct prin tehnologia Nat Hole Punching (NHP), care a fost de asemenea implementată pe Free Pascal. Trebuie să spun că nu auzisem anterior despre NHP. Nu îmi trecea prin minte că două dispozitive de rețea, ambele aflate în spatele NAT-ului, pot fi conectate direct. Am studiat subiectul, am înțeles principiul de funcționare și m-am apucat de scris. Ceea ce am conceput a fost realizat: utilizatorul se conectează cu un singur clic la dispozitivul dorit din spatele NAT-ului prin RDP, SSH sau Winbox, fără a introduce parole sau a configura VPN. Mai mult, cea mai mare parte a acestor conexiuni ocolesc coordonatorul nostru, ceea ce se reflectă pozitiv asupra latenței și costurilor de întreținere a acestor conexiuni.
Migrând partea de server de pe Linux pe Windows
Am întâmpinat mai multe probleme la trecerea pe Windows. Prima — wmizrc în Windows nu permite efectuarea de interogări WQL. În sistemul nostru, totul era deja construit pe baza lor. Și mai era ceva, dar acum nu-mi amintesc de ce am renunțat definitiv la utilizarea lui. Posibil, diferențele între versiunile Windows. A doua problemă — multithreading. Neavând o utilitate bună terță parte sub o licență „acceptabilă”, am repornit IDE-ul Lazarus și am scris utilitatea necesară. La intrare se furnizează lista de obiecte necesară și ce anume interogări trebuie efectuate, iar ca răspuns primesc datele. Toate acestea se desfășoară în mod multithreaded. Excelent.
După ce am configurat pthreads pentru PHP pe Windows, am crezut că totul va funcționa fără probleme, dar nu a fost așa. După o perioadă de depanare, mi-am dat seama că pthreads părea să funcționeze, dar în sistemul nostru nu a funcționat. A devenit clar că există o particularitate a utilizării pthreads pe Windows. Așa a și fost. Am citit documentația, iar acolo era menționat că, pentru Windows, numărul de thread-uri este limitat, și, din câte îmi amintesc, această limitare nu era chiar explicită. Aceasta a devenit o problemă, pentru că, atunci când am început să reduc numărul de thread-uri pentru care aplicația funcționa, aceasta îndeplinea sarcinile foarte lent. Am deschis din nou IDE-ul și în aceeași utilitar am adăugat funcționalitatea de ping multithreading pentru obiecte. Și, de asemenea, am inclus și scanarea porturilor. Practic, după asta, necesitatea utilizării pthreads pentru PHP a dispărut, și nu a mai fost folosit. Ulterior, în această utilitară au fost adăugate și câteva funcționalități suplimentare și funcționează și astăzi. După aceea, am creat un installer pentru Windows, care includea Apache, PHP, MariaDB, aplicația PHP în sine și un set de utilitare pentru interacțiunea cu sistemul, scrise în Free Pascal. În ceea ce privește installer-ul, mă așteptam să rezolv rapid această problemă, deoarece este o necesitate extrem de comună și utilă pentru aproape fiecare software. Fie că am căutat greșit, fie din alte motive, dar am dat mereu peste produse care erau fie insuficient de flexibile, fie scumpe și totodată inflexibile. Totuși, am găsit un installer gratuit, care permitea să iau în considerare toate cerințele. Acesta este InnoSetup. Scriu despre asta aici pentru că a fost nevoie să caut, și poate ajut pe cineva să economisească timp.
Renunțarea la plugin în favoarea clientului meu
Am menționat anterior că partea clientului era un browser cu un „plugin”. Așa că au fost vremuri când, fie Chrome se actualiza și layout-ul era puțin strâmb, fie Windows se actualiza și schemele URI personalizate se pierdeau. Nu îmi plăcea deloc să am acest tip de surprize în versiunea publică a produsului. În plus, schemele URI personalizate au început să se piardă după fiecare actualizare a Windows-ului. Microsoft pur și simplu ștergea toate ramurile non-proprii din secțiunea respectivă. De asemenea, Google Chrome acum nu permite salvarea alegerii de a deschide sau nu aplicația din URI personalizat, punând această întrebare la fiecare clic pe obiectul de monitorizare. În general, era necesară o interacțiune normală cu sistemul local al utilizatorului, lucru pe care browserul nu îl oferă. Cea mai simplă variantă în acest scenariu părea să fie crearea propriului browser, așa cum fac mulți în prezent prin Electron. Dar deja multe lucruri fuseseră scrise în Free Pascal, inclusiv partea de server, de aceea s-a decis ca și clientul să fie realizat în aceeași limbă, pentru a evita divergențele. Astfel, a fost scris un client cu Chromium la bord. După aceea, a început să fie echipat cu diverse extensii.
Lansare
În sfârșit am ales un nume pentru sistem. Am evaluat constant diferite opțiuni în timpul procesului de tranziție de la versiunea locală la SaaS. Deoarece ne-am planificat inițial să ieșim nu doar pe piața internă, principalul criteriu pentru alegerea numelui a fost disponibilitatea unui domeniu liber sau nu foarte scump în zona „.com”. Unele funcționalități/module încă nu fuseseră portate din versiunea locală în Veliam, dar am decis că vom lansa cu funcționalitatea actuală, iar restul să fie completat prin actualizări. În prima versiune nu existau HelpDesk, Veliam Connector, nu era posibil să modifici pragurile de activare ale notificărilor și multe altele. Am achiziționat un certificat Code Sign, am semnat părțile client și server. Am scris un site pentru produs, am început procedurile de înregistrare a software-ului, mărcii comerciale etc. În general, suntem gata să începem. O ușoară euforie din munca depusă și din gândul că produsul tău ar putea fi folosit de cineva, deși în această privință nu am avut niciun dubiu. Și apoi, stop. Partenerul a spus că nu putem iesi pe piață fără notificări în aplicațiile de mesagerie. Putem să renunțăm la multe alte lucruri, dar nu la asta. După câteva dispute scurte, am adăugat integrarea cu Telegram, care a fost acceptabilă pentru noi. Dintre aplicațiile de mesagerie existente, aceasta este singura care oferă acces gratuit la API-ul său, fără proceduri complicate de aprobat. WhatsApp, de exemplu, recomandă să contactăm furnizorii care percep o sumă considerabilă pentru utilizarea serviciilor lor, toate solicitările de acces direct au fost ignorate. Iar Viber… nu știu cine îl folosește acum, deoarece spamul și reclamele sunt copleșitoare. La sfârșitul lunii decembrie, după o serie de teste interne și teste între prieteni, am deschis înregistrarea pentru toți și am pus software-ul disponibil pentru descărcare.
Începerea distribuției
De la început am înțeles că avem nevoie de un flux mic de utilizatori ai sistemului pentru a testa produsul în condiții reale și a oferi o primă reacție. Câteva postări cumpărate pe VK au dat roade. Au început primele înregistrări.
Este important de menționat că, atunci când o companie nu are un nume celebru, intrarea pe piață și oferirea unei funcționalități de monitorizare fără agent, care necesită introducerea acreditivelor pentru servere și stații de lucru, este foarte dificilă. Acest lucru îi sperie pe foarte mulți oameni. De la început, am știut că vom întâmpina probleme și am fost pregătiți din punct de vedere tehnic și moral. Toate conexiunile la distanță, deși RDP și SSH sunt criptate în mod implicit, sunt criptate suplimentar de software-ul nostru conform standardului AES. Toate datele din serverele locale sunt transmise în cloud prin HTTPS. Acreditivele sunt stocate într-o formă criptată. Cheile de criptare pentru toate subsistemele sunt individuale pentru fiecare client. Pentru conexiunile la distanță se folosesc chei de criptare pe sesiuni.
Tot ce putem face în această situație pentru a îi liniști pe oameni este să fim cât mai transparenți, să lucrăm la securitate și să nu obosim să răspundem la întrebările care îi neliniștesc.
Pentru mulți, confortul și funcționalitatea software-ului depășesc teama, iar ei se înregistrează. Unele persoane au scris în postările publicate pe VK că acest software nu poate fi folosit, deoarece ar aduna parolele lor și că este o companie necunoscută. Trebuie să menționăm că această opinie nu este singulară. Multe persoane pur și simplu nu înțeleg că, atunci când instalează un alt software proprietar pe server, care funcționează ca un serviciu, acesta are aceleași drepturi complete în sistem și nu au nevoie de acreditive pentru a face ceva ilegal (e clar că se poate schimba utilizatorul sub care rulează serviciul, dar la fel este și aici, orice acreditiv poate fi introdus). De fapt, temerile oamenilor sunt justificate. Instalarea software-ului pe server este o practică obișnuită, dar introducerea acreditivelor este deja puțin înfricoșătoare și intimă, deoarece mulți oameni au aceeași parolă pentru toate serviciile, iar a crea un cont separat chiar și pentru un test este o corvoadă. Dar în prezent există o mulțime de servicii cărora oamenii le încredințează datele lor de autentificare și nu numai. Și ne străduim să devenim unul dintre acestea.
Multe comentarii au fost de genul că am furat asta de undeva. Ne-a uimit puțin. Ei bine, este opinia unei singure persoane, dar astfel de comentarii au apărut în diverse publicații de la diferiți oameni. La început nu știam cum să reacționăm la asta. Să ne întristăm de faptul că unii oameni cred că în Rusia nimeni nu poate face nimic singur, ci doar poate fura, sau să ne bucurăm că se consideră că ceva de genul acesta poate fi furat doar.
Acum am finalizat procedura de obținere a certificatului EV Code Sign. Pentru a-l obține, trebuie să trecem printr-o serie de verificări și să trimitem o mulțime de documente despre companie, dintre care unele trebuie să fie autentificate de un avocat. Obținerea certificatului EV Code Sign în condițiile unei pandemii este, de fapt, un subiect separat pentru un articol. Procedura a durat o lună. Și aceasta a fost o lună nu de așteptare, ci de solicitări constante de documente suplimentare. Poate pandemia nu a fost de vină și toată lumea a trecut printr-o procedură atât de lungă? Împărtășiți.
Unii spun că nu vom folosi din cauza că nu avem certificat FSTEK. Trebuie să explicăm că nu putem să-l obținem și nu o vom face deoarece pentru a obține acest certificat, criptarea trebuie să fie conform GOST, iar noi plănuim să distribuim software nu doar în Rusia și folosim AES.
Toate aceste comentarii au provocat o oarecare neîncredere că este posibil să promovăm un produs la care trebuie să introducem conturi, fără a fi la înălțime. Chiar și având în vedere că știm că vor fi cei care au opinii foarte negative despre asta. După ce numărul înregistrărilor a depășit o mie, am încetat să ne gândim la asta. În special după ce, pe lângă negativitatea celor care nici măcar nu au încercat produsul, au început să apară și recenzii foarte plăcute. Trebuie să spun că aceste recenzii pozitive sunt cel mai mare motivator pentru dezvoltarea produsului.
Adăugarea funcției de acces de la distanță pentru angajați
Una dintre sarcinile frecvente din partea clienților este „fă-ți lui Vanea acces la calculatorul său de acasă”. Am configurat un VPN pe Mikrotik și am creat conturi pentru utilizatori. Dar acesta este, într-adevăr, o problemă. Utilizatorii nu sunt capabili să urmărească instrucțiunile și să le execute pas cu pas pentru a se conecta prin VPN. Există diferite versiuni de Windows. Într-o versiune de Windows, totul se conectează bine, în alta este necesar un alt protocol. Și, în general, aceasta a fost întotdeauna legată de reconfigurarea echipamentului de rețea, care servește ca server VPN, iar nu toți angajații au acces la acesta, și a fost incomod.
Dar avem deja conexiuni la distanță cu servere și echipamente de rețea. De ce să nu folosim un transport gata făcut și să creăm o micuță utilitate pe care să o putem oferi utilizatorului pentru a se conecta? Mi-am dorit doar să fac astfel încât utilizatorul să nu fie nevoit să introducă nimic complicat. Doar un singur buton "conectare". Dar cum va înțelege această utilitate unde să se conecteze, dacă are doar un buton? A fost o idee de a crea online aplicația necesară pe serverele noastre. Administratorul de sistem apasă butonul "descarcă scurtcuget", iar la noi în cloud se trimite comanda de construire a unui binar personalizat cu informația de conectare la serverul / computerul dorit prin RDP. În general, acest lucru ar fi putut fi realizat. Dar durează mult, administratorul ar trebui să aștepte mai întâi ca binarul să fie compilat și apoi să fie descărcat. Ar fi fost, desigur, posibil să adăugăm pur și simplu un al doilea fișier cu configurația, dar asta ar fi fost deja 2 fișiere, iar pentru simplitate utilizatorului îi trebuie un singur fișier. Un fișier, un buton și fără instalatori. După ce am citit puțin pe Google, am ajuns la concluzia că, dacă la sfârșitul fișierului compilat “.exe” se adaugă anumite informații, acesta nu se strică (aproape). Poți adăuga până și „Război și pace”, iar acesta va funcționa ca înainte. Ar fi păcat să nu profităm de asta. Acum putem pur și simplu să desfășurăm aplicația chiar în client, de altfel se numește Veliam Connector, și să adăugăm informația necesară conectării la sfârșitul acesteia. Iar aplicația însăși știe ce să facă cu aceste informații. De ce am scris mai sus în paranteză „aproape”? Pentru că, pentru această comoditate, trebuie să plătim cu faptul că aplicația își pierde semnătura digitală. Dar noi, în acest stadiu, considerăm că este un preț mic pentru atâta comoditate.
Licențele modulelor terțe
Am menționat mai sus că, după ce s-a decis să facem produsul accesibil publicului, nu doar pentru uzul intern, a fost necesar să muncim destul de mult și să căutăm înlocuitori pentru anumite module care nu ne permiteau să ne integrăm produsul. Dar, după lansare, am descoperit întâmplător o problemă destul de neplăcută. În cadrul Veliam Server, care era pe partea clientului, se afla baza de date MariaDB. Aceasta are licența GPL. Licența GPL prevede că software-ul trebuie să fie cu sursă deschisă, iar dacă produsul nostru include MariaDB care are această licență, produsul nostru trebuie să fie, de asemenea, sub această licență. Dar, din fericire, scopul acestei licențe este sursa deschisă, nu pedepsirea în instanță a celor care au greșit din întâmplare. Dacă deținătorul drepturilor are o reclamație, acesta trebuie să notifice în scris încălcătorul, iar acesta trebuie să remedieze încălcarea în termen de 30 de zile. Am descoperit greșeala noastră singuri, nu am primit scrisori și am început imediat să considerăm opțiunile pentru a rezolva problema. Soluția s-a dovedit a fi evidentă - trecerea la SQLite. Această bază de date nu are restricții de licențiere. Majoritatea browserelor moderne folosesc SQLite, precum și o mulțime de alte programe. Am găsit pe internet informații că SQLite este considerată cea mai răspândită bază de date din lume, datorită browserelor, dar nu am căutat dovezi, așa că aceasta este o informație inexactă. Am început să studiez consecințele trecerii la SQLite.
Aceasta devine o sarcină ne-trivială atunci când există câteva sute de servere instalate la clienți cu MariaDB și date în ea. Unele funcționalități ale MariaDB nu sunt disponibile în SQLite. De exemplu, în cod am folosit interogări de tipul
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Această construcție nu doar că face selecția din tabel, dar blochează și acele linii de date. Și au fost necesare să fie rescrise și câteva alte construcții. Dar, pe lângă faptul că a trebuit să rescriu multe interogări, a fost necesar să inventez un mecanism care, la actualizarea Veliam Server la client, să migrateze toate datele în noua bază de date și să elimine pe cea veche. De asemenea, tranzacțiile nu funcționau în SQLite și aceasta a fost o problemă reală. Dar după ce am citit pe internet, am găsit fără probleme că tranzacțiile în SQLite pot fi activate, prin transmiterea unui simplu comenzi la conectare
PRAGMA journal_mode=WAL;În concluzie, sarcina a fost realizată și acum partea de server pentru clienți funcționează pe SQLite. Nu am observat nicio modificare în funcționarea sistemului.
New HelpDesk
A fost necesară portarea sistemului HelpDesk din versiunea internă în versiunea SaaS, însă cu anumite modificări. Primul lucru pe care dorim să-l facem este integrarea cu domeniul clientului în ceea ce privește autentificarea transparentă a utilizatorilor în sistem. Acum, pentru a accesa HelpDesk și a lăsa o solicitare în sistem, utilizatorul pur și simplu apasă pe scurtătura de pe desktop și se deschide browserul. Utilizatorul nu introduce nicio informație de autentificare. Modulul pentru Apache SSPI, care face parte din Veliam Server, autentifică automat utilizatorul sub contul de domeniu. Pentru a lăsa o solicitare în sistem, atunci când utilizatorul se află în afara rețelei corporative, el apasă pe un buton, iar pe e-mailul său primește un link, prin care se autentifică în sistemul HelpDesk fără a folosi parole. Dacă utilizatorul este dezactivat sau șters din domeniu, contul său din HelpDesk va înceta, de asemenea, să funcționeze. Astfel, administratorul de sistem nu trebuie să urmărească conturile atât în domeniu, cât și în HelpDesk. Dacă un angajat a fost concediat — a dezactivat contul în domeniu și tot, el nu va putea accesa sistemul nici din rețeaua corporativă, nici prin link. Pentru a activa această integrare, administratorul de sistem trebuie să facă o GPO care și .
Al doilea lucru pe care îl considerăm extrem de necesar pentru sistemele HelpDesk, cel puțin pentru noi înșine — este conectarea la solicitant direct din cerere cu un singur clic. Mai mult, conexiunile trebuie să fie posibile chiar dacă administratorul de sistem se află într-o altă rețea. Acest lucru este obligatoriu pentru outsourcing, iar pentru administratorii de sistem angajați este de asemenea adesea foarte necesar. Există deja câteva produse care se ocupă excelent de sarcina conectării de la distanță. Și am decis să facem integrări pentru ele. În prezent, am realizat o integrare pentru VNC și, în viitor, planificăm să adăugăm Radmin și TeamViewer. Folosind transportul nostru de rețea pentru conexiuni la distanță către infrastructură, am făcut astfel încât VNC să se conecteze la stațiile de lucru de la distanță prin NAT. Același lucru va fi valabil și pentru Radmin. Acum, pentru a te conecta la utilizator, trebuie doar să apesi butonul „conectează-te la solicitant” din cerere. Se deschide clientul VNC și se conectează la solicitant, indiferent dacă ești în aceeași rețea sau te afli acasă în papuci. În prealabil, administratorul de sistem trebuie să instaleze VNC Server pe toate stațiile de lucru, prin GPO.
Acum noi înșine trecem la noul HelpDesk și folosim integrarea cu domeniul și VNC. Este foarte convenabil pentru noi. Acum putem să nu mai plătim pentru TeamViewer, pe care l-am utilizat timp de peste trei ani pentru a funcționa serviciul nostru de suport.
Ce plănuim să facem în continuare
Când am lansat produsul, nu am creat planuri plătite, ci am limitat planul gratuit la 50 de obiecte de monitorizare. Cinci zeci de dispozitive de rețea și servere ar trebui să fie suficiente pentru toți, ne-am gândit. Apoi, au început să vină cereri pentru creșterea limitei. Să spunem că am fost puțin șocați — nu e nimic de spus. Așa cum se poate să fie interesate de software-ul nostru companii care au un număr atât de mare de servere? Am extins gratuit limita pentru cei care au făcut astfel de cereri. La unii, în răspunsul la cererea lor, am întrebat de ce le-ar trebui atât de multe, nu cumva au un număr atât de mare de servere și echipamente de rețea. Și s-a dovedit că administratorii de sistem au început să folosească sistemul exact așa cum nu ne-am planificat deloc. Totul s-a dovedit a fi simplu — cu software-ul nostru au început să monitorizeze nu doar servere, ci și stații de lucru. De aici și multe cereri pentru extinderea limitelor. Acum am introdus planuri plătite și limitele pot fi extinse autonom.
Serverele lucrează aproape întotdeauna fie cu o stocare ierarhică fie cu discuri locale într-un RAID. Și am creat inițial produsul pentru ele. Monitorizarea SMART nu era relevantă pentru această sarcină. Însă, având în vedere că oamenii au adaptat software-ul pentru monitorizarea stațiilor de lucru, au apărut cereri pentru implementarea monitorizării SMART. În curând o vom implementa.
Odată cu apariția Veliam Connector, nu mai este necesară desfășurarea unui server VPN în rețeaua corporativă, sau să facem RDGW, sau pur și simplu să deschidem porturi către mașinile necesare pentru conectarea prin RDP. Foarte mulți folosesc sistemul nostru doar pentru aceste conexiuni de la distanță. Veliam Connector este disponibil doar pe Windows, iar unii utilizatori din companii se conectează de pe laptopuri acasă care rulează MacOS la stațiile de lucru sau terminalele din rețeaua corporativă. Și astfel, administratorul de sistem este nevoit din cauza câtorva utilizatori să revină la problema deschiderii de porturi sau VPN. De aceea, acum suntem aproape să finalizăm versiunea Veliam Connector pentru MacOS. Utilizatorii tehnicii lor preferate Apple vor avea, de asemenea, posibilitatea de a se conecta la infrastructura corporativă cu un singur clic.
Îmi place foarte mult că, având un număr mare de utilizatori în sistem, nu trebuie să-mi fac griji cu privire la ceea ce le trebuie și ce ar fi mai convenabil. Ei își scriu singuri dorințele, așa că avem multe planuri de dezvoltare pentru perioada următoare.
Între timp, planificăm să ne ocupăm de traducerea sistemului în limba engleză și de distribuirea acestuia în străinătate. Deocamdată, nu știm cum ne vom distribui produsul în afara țării noastre, căutăm opțiuni. Poate că va exista un articol separat pe această temă mai târziu. Poate cineva dintre cei care au citit acest articol ne poate sugera direcția necesară, sau poate cunoaște și știe cum să facă acest lucru și să-și ofere serviciile. Am fi recunoscători pentru ajutor.
Sursa: habr.com
