In , ho parlato della storia della creazione di Veliam e della sua diffusione tramite il sistema SaaS. In questo articolo, vi racconterò cosa è stato fatto affinché il prodotto diventasse pubblico anziché locale. Di come abbiamo iniziato la distribuzione e quali problemi abbiamo affrontato.
Pianificazione
L'attuale parte server per gli utenti era su Linux. Quasi ogni organizzazione ha server Windows, il che non si può dire di Linux. Il principale punto di forza di Veliam è la connessione remota a server e dispositivi di rete dietro NAT. Ma questa funzionalità era molto strettamente legata al fatto che il router doveva necessariamente essere un Mikrotik. E questo ovviamente non avrebbe soddisfatto molte persone. Inizialmente ho iniziato a pensare di aggiungere il supporto per i router dei fornitori più comuni. Ma capivo che sarebbe stata una corsa infinita per ampliare l'elenco delle aziende supportate. Inoltre, anche quelli già supportati potrebbero avere, da modello a modello, un insieme di comandi diversi per modificare le regole NAT. L'unica soluzione che vedevo era il VPN.
Poiché abbiamo deciso di distribuire il prodotto, ma non come open source, non è stato più possibile includere nella propria composizione diverse librerie con licenze aperte come la GPL. Questo è un argomento a parte: dopo aver preso la decisione di vendere il prodotto, abbiamo dovuto rivedere metà delle librerie a causa del fatto che erano GPL. Quando scrivevamo per noi stessi, andava bene. Ma per la distribuzione non è utile. Il primo VPN che viene in mente è OpenVPN. Ma è GPL. Avevamo anche l'opzione di usare il giapponese SoftEther VPN. La sua licenza permetteva di includerlo nel proprio prodotto. Dopo un paio di giorni di vari test su come integrarlo in modo che l'utente non dovesse configurare nulla e non dovesse sapere nulla di SoftEther VPN, è emerso un prototipo. Tutto era come doveva essere. Ma, per qualche motivo, questo schema ci ha comunque confusi e alla fine abbiamo rinunciato ad esso. Ma naturalmente abbiamo rinunciato solo dopo aver pensato a un'altra opzione. Alla fine, abbiamo fatto tutto su normali connessioni TCP. Parte delle connessioni funziona attraverso un coordinatore, parte direttamente tramite la tecnologia Nat Hole Punching (NHP), che è stata anch'essa implementata su Free Pascal. Devo dire che di NHP non ne avevo mai sentito parlare prima. E non mi era nemmeno venuto in mente che fosse possibile collegare 2 dispositivi di rete, entrambi dietro NAT, direttamente. Ho studiato l'argomento, ho capito il principio di funzionamento e ho iniziato a scrivere. Quello che avevo in mente è stato realizzato; l'utente si connette con un clic al dispositivo desiderato dietro NAT tramite RDP, SSH o Winbox senza inserire password e configurare VPN. Inoltre, la maggior parte di queste connessioni avviene senza passare per il nostro coordinatore, il che influisce positivamente sul ping e sul costo di gestione di queste connessioni.
Traduzione della parte server da Linux a Windows
Ci sono stati diversi problemi durante il passaggio a Windows. Il primo è che il wmic integrato in Windows non consente di effettuare query WQL. E nel nostro sistema tutto era già basato su di esse. C'era anche qualcos'altro, ma ora non ricordo perché abbiamo definitivamente rinunciato al suo utilizzo. Forse le differenze tra le versioni di Windows. La seconda problematica è la multithreading. Non trovando un buon strumento di terze parti con una licenza 'consentita' per noi, ho riavviato l'IDE Lazarus. E ho scritto l'utilità necessaria. In input fornisco l'elenco degli oggetti richiesti e quali query devono essere eseguite, e come risposta ottengo i dati. E il tutto in modalità multithreading. Ottimo.
Dopo aver configurato pthreads per PHP su Windows, pensavo che tutto sarebbe partito senza problemi, ma così non è stato. Dopo un po' di debugging, ho capito che pthreads sembrava funzionare, ma nella nostra sistema non andava. È diventato chiaro che c'era qualche particolarità nel funzionamento di pthreads su Windows. Ed era proprio così. Ho letto la documentazione e lì c'era scritto che per Windows il numero di thread è limitato, e per quanto ricordo in modo neppure troppo chiaro. Questo è diventato un problema. Perché, quando ho cominciato a ridurre il numero di thread con cui l'applicazione funzionava, essa lavorava molto lentamente. Ho riaperto l'IDE e nella stessa utility è stata aggiunta una funzionalità per il ping multithreading degli oggetti. E per di più, è stata inclusa anche la scansione delle porte. Diciamo che dopo questo, la necessità di pthreads per PHP è venuta meno e non è più stato utilizzato. Successivamente, in questa utility sono state aggiunte altre funzionalità e continua a funzionare fino ad oggi. Dopo di che è stato creato un installer per Windows, che includeva Apache, PHP, MariaDB, l'applicazione PHP stessa e un insieme di utility per interagire con il sistema, scritte in Free Pascal. Per quanto riguarda l'installer, pensavo di risolvere rapidamente questo problema, dato che è una cosa molto comune e necessaria per quasi ogni software. O non cercavo nel modo giusto, o c'era qualcos'altro. Ma continuavo a trovare prodotti che erano o non abbastanza flessibili, o costosi e comunque anche poco flessibili. Eppure, ho trovato un installer gratuito, che permette di prevedere tutte le esigenze. Questo è InnoSetup. Scrivo qui di questo perché mi è costato una ricerca, magari risparmio del tempo a qualcuno.
Abbandono del plugin a favore del proprio cliente
Ho scritto in precedenza che la parte client era un browser con un "plugin". C'erano momenti in cui Chrome si aggiornava e la formattazione risultava un po' distorta, oppure Windows si aggiornava e gli schemi URI personalizzati si disattivavano. Non avrei voluto avere questo tipo di sorprese nella versione pubblica del prodotto. Inoltre, gli URI personalizzati hanno iniziato a disattivarsi dopo ogni aggiornamento di Windows. Microsoft semplicemente rimuoveva tutti i rami estranei nella sezione necessaria. Inoltre, Google Chrome ora non consente di salvare la scelta di aprire o meno l'applicazione dagli URI personalizzati, e pone questa domanda ad ogni clic sull'oggetto di monitoraggio. E in generale, era necessario avere una normale interazione con il sistema locale dell'utente, cosa che il browser non offre. L'opzione più semplice in tale schema sembrava semplicemente creare un proprio browser, come fanno molti ora tramite Electron. Ma molte cose erano già state scritte in Free Pascal, anche nella parte server, quindi abbiamo deciso di realizzare anche il client nello stesso linguaggio, piuttosto che moltiplicare gli zoologhi. Così è stato scritto un client con Chromium a bordo. Dopo di che ha iniziato a arricchirsi di vari collegamenti.
Rilascio
Finalmente abbiamo scelto il nome per il sistema. Abbiamo esaminato diverse opzioni mentre procedevamo alla trasformazione dalla versione locale al SaaS. Poiché inizialmente pianificavamo di espanderci non solo nel mercato interno, il criterio principale per la scelta del nome è stato che il dominio nella zona “.com” fosse disponibile o non troppo costoso. Alcune funzioni/module non erano ancora state portate dalla versione locale a Veliam, ma abbiamo deciso di lanciarsi con le attuali funzionalità e completare il resto successivamente tramite aggiornamenti. Nella prima versione non c'era HelpDesk, né Veliam Connector, non si potevano modificare le soglie per attivare le notifiche e molto altro. Abbiamo acquistato un certificato di firma del codice, firmato le parti client e server. Abbiamo creato un sito per il prodotto, avviato le procedure di registrazione del software, del marchio, ecc. In sintesi, eravamo pronti a partire. Leggera euforia per il lavoro svolto e per la possibilità che qualcuno potesse usare il nostro prodotto, anche se in merito a questo non avevamo dubbi. E poi stop. Il partner ha detto che non si può entrare nel mercato senza notifiche nei messaggi. Si può fare a meno di molte altre cose, ma non di questo. Dopo brevi discussioni, è stata aggiunta l'integrazione con Telegram, che ci ha soddisfatti. Tra tutti i messaggeri attuali, questo è l'unico che offre accesso alle proprie API gratuitamente e senza procedure di approvazione complicate. Lo stesso WhatsApp invita a contattare fornitori che chiedono buone cifre per utilizzare i loro servizi; tutte le e-mail di richiesta di accesso diretto sono state ignorate. E per quanto riguarda Viber… Non so chi lo usi ora, poiché spam e pubblicità sono fuori controllo. A fine dicembre, dopo vari test interni e test tra amici, abbiamo aperto le registrazioni per tutti e pubblicato il software per il download.
Inizio della distribuzione
Fin dall'inizio abbiamo capito che avevamo bisogno di un numero limitato di utenti del sistema affinché potessero testare il prodotto in modalità operativa e fornire un primo feedback. Alcuni post sponsorizzati su VK hanno dato buoni risultati. Sono arrivate le prime registrazioni.
Qui bisogna dire che entrare nel mercato quando la tua azienda non ha un nome famoso e fornire funzionalità di monitoraggio senza agenti, per le quali è necessario inserire le credenziali dei propri server e workstation, non è affatto semplice. Molte persone ne sono spaventate. Fin dall'inizio abbiamo capito che ci sarebbero state delle difficoltà e siamo stati pronti a farvi fronte sia tecnicamente che moralmente. Tutte le connessioni remote, nonostante RDP e SSH siano già cifrati di default, vengono ulteriormente cifrate dal nostro software secondo lo standard AES. Tutti i dati dai server locali vengono trasferiti nel cloud tramite HTTPS. Le credenziali sono conservate in forma cifrata. Le chiavi di cifratura per tutti i subsistemi dei clienti sono individuali. Per le connessioni remote vengono utilizzate chiavi di sessione di cifratura.
Tutto ciò che possiamo fare in questa situazione per rassicurare le persone è essere il più trasparenti possibile, lavorare sulla sicurezza e non stancarci mai di rispondere alle domande che li preoccupano.
Per molti, la comodità e le funzionalità del software superano la paura, e si registrano. Alcune persone nei post pubblicati su VK hanno scritto che questo software non può essere usato perché raccoglie le loro password ed è una company senza nome. Va detto che questo punto di vista non era di una sola persona. Molti semplicemente non capiscono che quando installano un altro software proprietario sul server, che opera come servizio, ha esattamente gli stessi diritti nel sistema e non ha bisogno di credenziali per compiere azioni illecite (è chiaro che è possibile cambiare l'utente da cui viene avviato il servizio, ma anche qui si possono inserire credenziali qualunque). In realtà, le preoccupazioni delle persone sono comprensibili. L'installazione di software su un server è qualcosa di abituale, ma inserire le credenziali è già un po' spaventoso e intimo, visto che molti hanno una sola password per tutti i servizi e sono riluttanti a creare un account separato anche solo per un test. Tuttavia, al momento ci sono un'enorme quantità di servizi ai quali le persone affidano le loro credenziali e non solo. E ci sforziamo di diventare uno di questi.
Molti commenti erano di questo tipo, che noi avessimo rubato da qualche parte. Questo ci ha sorpreso un po'. Va bene l'opinione di una persona, ma commenti simili sono apparsi in varie pubblicazioni da diverse persone. Non sapevamo inizialmente come reagire a ciò. Se rattristarsi per il fatto che alcuni pensano che in Russia nessuno possa fare nulla da solo, ma possa solo rubare, o rallegrarsi che pensano che cose del genere si possano solo rubare.
Ora abbiamo concluso la procedura per ottenere il certificato EV Code Sign. Per ottenerlo, è necessario passare attraverso una serie di controlli e inviare un sacco di documenti sull'azienda, parte dei quali devono essere certificati da un avvocato. Ottenere il certificato EV Code Sign in tempi di pandemia è un argomento completamente a parte. La procedura si è protratta per un mese. E non è stato un mese di attesa, ma di richieste costanti di documenti aggiuntivi. Potrebbe che la pandemia non c'entrasse nulla e che per tutti la procedura fosse così lunga? Condividi.
Alcuni dicono che non utilizzeranno perché non c'è il certificato FSTEK. Dobbiamo spiegare che non possiamo ottenerlo e non lo faremo perché per ottenere questo certificato la crittografia deve essere conforme al GOST, mentre noi pianifichiamo di distribuire il software non solo in Russia e utilizziamo AES.
Tutti questi commenti suscitavano una certa insicurezza riguardo alla possibilità di promuovere un prodotto in cui è necessario inserire credenziali senza essere noti. Anche considerando che sapevamo che ci sarebbero state persone che avrebbero reagito in modo molto negativo a questo. Dopo che il numero di registrazioni ha superato le mille, abbiamo smesso di pensarci. Soprattutto dopo che, oltre alle critiche di chi non aveva nemmeno provato il prodotto, hanno cominciato ad arrivare anche recensioni molto positive. Va detto che queste recensioni positive sono il più grande motivatore per lo sviluppo del prodotto.
Aggiunta della funzionalità di accesso remoto per i dipendenti
Una delle richieste più comuni da parte dei clienti è "fai in modo che Vania abbia accesso al suo computer da casa". Abbiamo impostato una VPN su Mikrotik e creato account per gli utenti. Ma è davvero un problema. Gli utenti non sono in grado di seguire le istruzioni e farlo passo dopo passo per connettersi tramite VPN. Diverse versioni di Windows. In un sistema Windows si connette tutto bene, in un altro è necessario un protocollo differente. In generale, ciò è sempre stato collegato alla riconfigurazione dell'hardware di rete, che fungeva da server VPN, e non tutti i dipendenti hanno accesso a questo, il che è scomodo.
Ma abbiamo già collegamenti remoti ai server e all'hardware di rete. Perché non sfruttare i trasporti già pronti e creare un'utility di dimensioni ridotte che possiamo semplicemente fornire all'utente per la connessione? Volevo solo fare in modo che l'utente non dovesse inserire nulla di complicato. Solo un pulsante "collegati". Ma come farà questa utility a capire dove collegarsi se ha solo un pulsante? C'era l'idea di una costruzione online dell'applicazione necessaria sui nostri server. L'amministratore di sistema preme il pulsante "scarica collegamento", e noi nel nostro cloud riceviamo il comando per assemblare un binario individuale con le informazioni di collegamento integrate al server/computer giusto tramite RDP. In generale, si poteva fare. Ma è lungo, l'amministratore dovrebbe prima aspettare che il binario venga compilato e poi scaricato. Certo, si potrebbe anche aggiungere semplicemente un secondo file di configurazione, ma ciò comporterebbe avere 2 file, mentre per semplicità all'utente serve uno solo. Un file, un pulsante e niente installer. Dopo aver navigato un po' su Google, sono giunto alla conclusione che se si aggiunge qualche informazione alla fine di un “.exe” compilato, questo non si danneggia (beh, quasi). Si può aggiungere anche Guerra e Pace, e continuerà a funzionare come prima. È un peccato non approfittarne. Adesso possiamo semplicemente estrarre l'applicazione al volo direttamente nel client, tra l'altro si chiama Veliam Connector, e aggiungere a essa le informazioni necessarie per la connessione alla fine. E l'applicazione stessa sa cosa fare con queste informazioni. Perché ho scritto tra parentesi "quasi"? Perché per questa comodità bisogna accettare che l'applicazione perda la sua firma digitale. Ma noi, a questo punto, riteniamo che sia un basso prezzo per tale comodità.
Licenze dei moduli di terze parti
Ho già scritto sopra che, dopo aver deciso di rendere il prodotto accessibile al pubblico e non solo per uso personale, è stato necessario lavorare duramente per trovare sostituzioni per alcuni moduli che non permettevano di essere inclusi nel nostro prodotto. Ma già dopo il rilascio, è emersa accidentalmente una questione piuttosto spiacevole. Nel Veliam Server, che era lato client, c'era il database MariaDB. E questo con licenza GPL. La licenza GPL implica che il software deve avere codice sorgente aperto e, se il nostro prodotto include MariaDB che ha questa licenza, allora anche il nostro prodotto deve essere sotto questa licenza. Ma per fortuna, l'obiettivo di questa licenza è il codice sorgente aperto e non la punizione legale di chi ha commesso un errore. Se il titolare dei diritti presenta un reclamo, deve avvertire il trasgressore per iscritto e quest'ultimo deve correggere la violazione entro 30 giorni. Abbiamo scoperto il nostro errore da soli e non abbiamo ricevuto lettere e ci siamo subito messi a esplorare opzioni su come risolvere il problema. La soluzione è risultata ovvia: passare a SQLite. Questo DB non ha alcuna restrizione di licenza. La maggior parte dei moderni browser utilizza SQLite, così come un sacco di altri programmi. Ho trovato sul web informazioni che indicano che SQLite è considerato il database più diffuso al mondo, proprio a causa dei browser, ma non ho cercato prove, quindi questa è un'informazione imprecisa. Ho iniziato a studiare i rischi del passaggio a SQLite.
Diventa già un compito non banale quando ci sono alcune centinaia di server installati presso i clienti con MariaDB e i dati in essa. Alcune funzionalità di MariaDB non sono disponibili in SQLite. Ad esempio, nel codice sono state utilizzate query del tipo
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Questa costruzione non fa solo la selezione dalla tabella, ma blocca anche le righe di dati. E ci sono state altre costruzioni che abbiamo dovuto riscrivere. Ma oltre al fatto che abbiamo dovuto riscrivere molte query, è stato necessario anche inventare un meccanismo che durante l'aggiornamento di Veliam Server presso il cliente porti tutti i dati nel nuovo DB e rimuova il vecchio. Inoltre, le transazioni in SQLite non funzionavano e questo era un vero problema. Ma dopo aver esplorato il vasto mare del web, ho trovato facilmente che le transazioni in SQLite possono essere attivate, passando un semplice comando durante la connessione
PRAGMA journal_mode=WAL;Alla fine, il compito è stato completato e ora la parte server sui client funziona con SQLite. Non abbiamo notato alcuna modifica nel funzionamento del sistema.
Nuovo HelpDesk
Era necessario portare il sistema HelpDesk dalla versione interna alla versione SaaS, ma con alcune modifiche. La prima cosa che volevamo fare era integrare il dominio del cliente per la trasparente autorizzazione degli utenti nel sistema. Adesso, per accedere a HelpDesk e lasciare una richiesta nel sistema, l'utente deve semplicemente cliccare sull'icona sul desktop, e si apre il browser. L'utente non inserisce alcun dato di accesso. Il modulo per Apache SSPI, che fa parte di Veliam Server, autorizza automaticamente l'utente con l'account di dominio. Per lasciare una richiesta nel sistema quando l'utente si trova al di fuori della rete aziendale, clicca su un pulsante e riceve un link via email, tramite il quale si autorizza nel sistema HelpDesk senza password. Se l'utente viene disattivato o rimosso dal dominio, anche l'account in HelpDesk smetterà di funzionare. In questo modo, l'amministratore di sistema non deve controllare manualmente gli account sia nel dominio che in HelpDesk. Se un dipendente si dimette, l'amministratore disattiva l'account nel dominio e basta, non potrà accedere al sistema né dalla rete aziendale né tramite il link. Per far funzionare questa integrazione, l'amministratore di sistema deve impostare una GPO che e .
La seconda cosa che riteniamo estremamente necessaria per i sistemi HelpDesk, almeno per noi, è la connessione all'utente direttamente dalla richiesta con un clic. Inoltre, le connessioni devono funzionare anche se l'amministratore di sistema si trova su una rete diversa. Per il lavoro esternalizzato è fondamentale, ma anche per gli amministratori di sistema internamente è spesso molto necessario. Esistono già diversi prodotti che gestiscono perfettamente l'accesso remoto. Abbiamo quindi deciso di fare integrazioni per loro. Attualmente abbiamo realizzato un'integrazione per VNC e in futuro prevediamo di aggiungere Radmin e TeamViewer. Utilizzando il nostro trasporto di rete per connessioni remote all'infrastruttura, abbiamo configurato VNC in modo che possa collegarsi a workstation remote dietro NAT. Lo stesso avverrà con Radmin. Ora, per collegarsi a un utente, basta premere il pulsante "collegati all'utente" direttamente nella richiesta. Si apre il client VNC e si connette all'utente indipendentemente dal fatto che siate nella stessa rete o che siate a casa in ciabatte. Prima di tutto, l'amministratore di sistema deve installare VNC Server su tutte le workstation tramite GPO.
Ora stiamo passando a un nuovo HelpDesk e stiamo utilizzando l'integrazione con il dominio e VNC. Questo è molto comodo per noi. Ora possiamo smettere di pagare per TeamViewer, che abbiamo utilizzato per oltre tre anni per il nostro servizio di supporto.
Cosa intendiamo fare in seguito
Quando abbiamo lanciato il prodotto, non abbiamo creato piani a pagamento, ma abbiamo semplicemente limitato il piano gratuito a 50 oggetti di monitoraggio. Cinque dozzine di dispositivi di rete e server avrebbero dovuto bastare a tutti, abbiamo pensato. E poi hanno iniziato a pervenire richieste per aumentare il limite. Dire che siamo rimasti un po' scioccati è dire poco. Davvero le aziende con così tanti server sono interessate al nostro software? Abbiamo ampliato gratuitamente il limite per coloro che presentavano tali richieste. A alcuni abbiamo chiesto, in risposta alla loro richiesta, perché avessero bisogno di così tanti, non avendo così tanti server e apparecchiature di rete. E si è scoperto che gli amministratori di sistema hanno iniziato a utilizzare il sistema in un modo che non avevamo affatto previsto. È stato tutto molto semplice: hanno iniziato a monitorare non solo i server, ma anche le stazioni di lavoro con il nostro software. Ecco perché sono arrivate molte richieste di ampliamento dei limiti. Ora abbiamo già introdotto piani a pagamento e i limiti possono essere ampliati autonomamente.
I server lavorano quasi sempre con SAN o con dischi locali in un array RAID. E inizialmente abbiamo creato un prodotto per loro. Il monitoraggio SMART non era interessante per questo scopo. Tuttavia, considerando che le persone hanno adattato il software per monitorare le stazioni di lavoro, sono emerse richieste per implementare il monitoraggio SMART. Lo realizzeremo a breve.
Con l'arrivo di Veliam Connector, non è più necessario implementare un server VPN nella rete aziendale, fare RDGW, o semplicemente inoltrare le porte verso le macchine necessarie per la connessione tramite RDP. Molti utilizzano il nostro sistema solo per queste connessioni remote. Veliam Connector è disponibile solo per Windows, mentre alcuni utenti aziendali si connettono alle stazioni di lavoro o ai terminali nella rete aziendale con i loro laptop domestici che eseguono MacOS. Così, l'amministratore di sistema si trova costretto, a causa di alcuni utenti, a tornare alla questione dell'inoltro delle porte o della VPN. Pertanto, stiamo già terminando la versione di Veliam Connector per MacOS. Gli utenti della loro amata tecnologia Apple avranno anche la possibilità di connettersi all'infrastruttura aziendale con un solo clic.
Mi piace molto il fatto che, avendo un gran numero di utenti del sistema, non c'è bisogno di chiedersi cosa necessitano le persone e cosa sarebbe più comodo. Loro stessi scrivono i propri desideri, quindi ci sono molti piani per lo sviluppo a breve termine.
Parallelamente, stiamo pianificando di tradurre il sistema in inglese e di espanderlo all'estero. Non sappiamo ancora come distribuiremo il prodotto al di fuori del nostro paese, stiamo cercando delle opzioni. Forse in seguito ci sarà un articolo separato su questo. Potrebbe darsi che qualcuno di coloro che hanno letto questo articolo possa suggerire la giusta direzione, oppure conosce e sa come farlo e offrirà i propri servizi. Saremmo grati per l'aiuto.
Fonte: habr.com
