В , vaig parlar dels antecedents de la creació de Veliam i de la decisió de distribuir-lo a través del sistema SaaS. En aquest article parlaré del que he hagut de fer perquè el producte no sigui local, sinó públic. Sobre com va començar la distribució i quins problemes van trobar.
Paleta
El backend actual per als usuaris estava a Linux. Gairebé totes les organitzacions tenen servidors Windows, cosa que no es pot dir sobre Linux. El principal punt fort de Veliam són les connexions remotes a servidors i equips de xarxa darrere de NAT. Però aquesta funcionalitat estava molt lligada al fet que l'encaminador havia de ser Mikrotik. I això, òbviament, no satisfaria molts. Primer vaig començar a pensar en afegir suport per a encaminadors dels venedors més habituals. Però vaig entendre que era una carrera interminable per ampliar la llista d'empreses recolzades. A més, els que ja són compatibles poden tenir un conjunt diferent d'ordres per canviar les regles NAT d'un model a un altre. L'única manera de sortir de la situació semblava ser una VPN.
Com que vam decidir distribuir el producte, però no com a codi obert, es va fer impossible incloure diverses biblioteques amb llicències obertes com ara GPL. En general, aquest és un tema a part després de prendre la decisió de vendre el producte, vaig haver de passar per la meitat de les biblioteques pel fet que eren GPL. Quan escrivien per ells mateixos, era normal. Però no apte per a la distribució. La primera VPN que em ve al cap és OpenVPN. Però és GPL. Una altra opció era utilitzar la VPN SoftEther japonesa. La seva llicència li va permetre incloure-la al seu producte. Després d'un parell de dies de proves diverses sobre com integrar-lo de manera que l'usuari no necessiti configurar res i conèixer SoftEther VPN, es va obtenir un prototip. Tot era com havia de ser. Però per alguna raó aquest esquema encara ens va confondre i finalment el vam abandonar. Però, naturalment, es van negar després d'haver plantejat una altra opció. Al final, tot es va fer amb connexions TCP habituals. Algunes connexions funcionen a través d'un coordinador, algunes directament mitjançant la tecnologia Nat Hole Punching (NHP), que també es va implementar a Free Pascal. He de dir que mai abans havia sentit parlar de NHP. I mai se m'ha passat pel cap que fos possible connectar 2 dispositius de xarxa, tots dos directament darrere de NAT. Vaig estudiar el tema, vaig entendre el principi de funcionament i em vaig asseure a escriure. El pla es realitza, l'usuari es connecta amb un clic al dispositiu desitjat darrere de NAT mitjançant RDP, SSH o Winbox sense introduir contrasenyes ni configurar una VPN. A més, la majoria d'aquestes connexions superen el nostre coordinador, la qual cosa té un bon efecte en el ping i el cost del servei d'aquestes connexions.
Transferència de la part del servidor de Linux a Windows
Hi va haver diversos problemes en canviar a Windows. El primer és que el wmic integrat a Windows no us permet fer consultes WQL. I al nostre sistema tot ja estava construït sobre ells. I hi havia alguna cosa més, però ara he oblidat per què finalment van abandonar el seu ús. Possiblement diferències entre les versions de Windows. I el segon problema és el multithreading. No vaig trobar una bona utilitat de tercers amb una llicència "acceptable" per a nosaltres, vaig tornar a llançar l'IDE Lazarus. I vaig escriure la utilitat necessària. L'entrada és la llista necessària d'objectes i quines consultes específiques s'han de fer, i en resposta rebo dades. I tot això en mode multifils. Genial.
Després de configurar pthreads per a PHP Windows, vaig pensar que tot començaria de seguida, però no va ser així. Després d'un temps de depuració, em vaig adonar que els pthreads semblaven funcionar, però no funcionava al nostre sistema. Va quedar clar que hi ha alguna peculiaritat en treballar amb pthreads a Windows. I així va ser. Vaig llegir la documentació, i allà estava escrit que per a Windows el nombre de fils és limitat i, pel que recordo, implícitament. Això es va convertir en un problema. Perquè quan vaig començar a reduir el nombre de fils en què s'executava l'aplicació, va fer la feina molt lentament. Vaig tornar a obrir l'IDE i a la mateixa utilitat es va afegir la funcionalitat per fer ping multiprocés d'objectes. Bé, també hi ha molta exploració de ports. De fet, després d'això, la necessitat de pthreads per a PHP va desaparèixer i ja no s'utilitza. A més, s'han afegit diverses funcionalitats més a aquesta utilitat i encara funciona fins avui. Després d'això, es va muntar un instal·lador per a Windows, que incloïa Apache, PHP, MariaDB, la pròpia aplicació PHP i un conjunt d'utilitats per interactuar amb el sistema, escrites en Free Pascal. Pel que fa a l'instal·lador, vaig pensar que resoldria ràpidament aquest problema, perquè... Això és una cosa molt comú i necessària per a gairebé tots els programes. O estava buscant al lloc equivocat, o alguna cosa més. Però constantment em vaig trobar amb productes que no eren prou flexibles, o cars i també inflexibles. I tanmateix, he trobat un instal·lador gratuït en el qual serà possible satisfer qualsevol desitjo. Això és InnoSetup. Escric sobre això aquí perquè ho havia de buscar per si estalviava temps a algú.
Rebuig del connector a favor del vostre client
Abans vaig escriure que la part del client era un navegador amb un "connector". Així que hi va haver moments en què Chrome es va actualitzar i el disseny estava una mica tort, després es va actualitzar Windows i l'esquema d'uri personalitzat va desaparèixer. Realment no volia tenir aquest tipus de sorpreses a la versió pública del producte. A més, l'uri personalitzat va començar a desaparèixer després de cada actualització de Windows. Microsoft simplement ha suprimit totes les branques que no són les seves a la secció requerida. A més, ara Google Chrome no us permet recordar l'opció d'obrir o no una aplicació des de l'uri personalitzat, i fa aquesta pregunta cada vegada que feu clic a un objecte de monitoratge. Bé, en general, era necessària una interacció normal amb el sistema local de l'usuari, que el navegador no proporciona. L'opció més senzilla d'aquest esquema sembla ser crear el vostre propi navegador, com ara molts ho fan mitjançant Electron. Però ja s'havien escrit moltes coses en Free Pascal, inclosa la part del servidor, així que vam decidir fer el client en el mateix idioma, i no crear un zoo. Així és com es va escriure un client amb Chromium a bord. Després d'això, va començar a adquirir diversos fleixos.
Alliberament
Finalment vam triar un nom per al sistema. Vam passar constantment per diverses opcions mentre el procés de conversió de la versió local a SaaS estava en marxa. Com que inicialment teníem previst entrar no només al mercat nacional, el criteri principal per seleccionar un nom era la presència d'un domini desocupat o poc car a la zona “.com”. Algunes funcions/mòduls encara no s'han portat de la versió local a Veliam, però vam decidir que els llançaríem amb la funcionalitat actual i completaríem la resta com a actualitzacions. A la primera versió no hi havia HelpDesk, Veliam Connector, era impossible canviar els llindars dels activadors de notificacions i molt més. Vam comprar un certificat de signatura de codi i vam signar les parts del client i del servidor. Vam escriure un lloc web per al producte, vam iniciar procediments per registrar programari, una marca, etc. En general, estem preparats per començar. Una lleugera eufòria per la feina feta i pel fet que potser algú farà servir el teu producte, encara que no en teníem cap dubte. I després parar. El soci va dir que és impossible entrar al mercat sense notificacions a través de missatgeria. És possible sense moltes altres coses, però no sense això. Després d'un cert debat, es va afegir la integració amb Telegram, que ens va bé. De tots els missatgers instantanis actuals, aquest és l'únic que ofereix accés a les seves API de manera gratuïta i sense procediments d'aprovació complexos. El mateix WhatsApp suggereix contactar amb els proveïdors que cobren bons diners per utilitzar els seus serveis es van ignorar totes les cartes demanant accés sense juntes. Bé, Viber... no sé qui l'utilitza ara, perquè... el correu brossa i la publicitat allà estan fora de les llistes. A finals de desembre, després d'una sèrie de proves internes i proves entre amics, es va obrir el registre per a tothom i es va posar a la seva disposició el programari per a la seva descàrrega.
Inici de la distribució
Des del principi, vam entendre que necessitàvem un petit flux d'usuaris del sistema perquè poguessin provar el producte en mode de combat i donar un primer comentari. Diverses publicacions comprades a VK van donar els seus fruits. Han arribat les primeres inscripcions.
Aquí s'ha de dir que entrar al mercat quan la teva empresa no té un nom famós, i alhora oferir una funcionalitat de monitorització sense agent en la qual necessites introduir comptes des dels teus servidors i estacions de treball, és molt difícil. Això fa por a molta gent. Vam entendre des del principi que hi hauria problemes amb això i estàvem preparats per a això tant tècnicament com moralment. Totes les connexions remotes, malgrat que RDP i SSH ja estan xifrats per defecte, el nostre programari també les xifra mitjançant l'estàndard AES. Totes les dades dels servidors locals es transfereixen al núvol mitjançant HTTPS. Els comptes s'emmagatzemen en forma xifrada. Les claus de xifratge per a tots els subsistemes són individuals per a tots els clients. Per a connexions remotes, generalment s'utilitzen claus de xifratge de sessió.
Tot el que podem fer en aquesta situació perquè la gent se senti més tranquil·la és ser el més obert possible, treballar la seguretat i no cansar-nos mai de respondre les preguntes de la gent.
Per a molts, la comoditat i la funcionalitat del programari superen la por i es registren. Algunes persones van escriure en publicacions publicades a VK que aquest programari no es pot utilitzar perquè Aquesta és una col·lecció de les seves contrasenyes i, en general, una empresa sense nom. Cal dir que més d'una persona tenia aquesta opinió. Moltes persones simplement no entenen que quan instal·len un altre programari propietari en un servidor que s'executa com a servei, també té tots els drets del sistema i no necessiten comptes per fer alguna cosa il·legal (està clar que podeu canviar el usuari des del qual s'inicia el servei, però aquí també podeu introduir qualsevol compte). De fet, les pors de la gent són comprensibles. Instal·lar programari en un servidor és una cosa habitual, però entrar en un compte és una mica espantós i íntim, ja que bona meitat de la gent té la mateixa contrasenya per a tots els serveis i crear un compte independent fins i tot per a una prova és mandrós. Però en aquests moments hi ha un gran nombre de serveis en els quals la gent confia amb les seves credencials i molt més. I ens esforcem per ser un d'ells.
Hi havia molts comentaris que deien que ho vam robar en algun lloc. Això ens va sorprendre una mica. Bé, d'acord, l'opinió d'una persona, però aquests comentaris es van trobar en diverses publicacions de diferents persones. Al principi no sabien com reaccionar davant d'això. Ja sigui per estar trist que algunes persones opinen que a Rússia ningú no pot fer res pel seu compte, sinó que només pot robar, o bé per estar content de pensar que això només es pot robar.
Ara hem completat el tràmit per obtenir un certificat de signatura de codi EV. Per obtenir-lo, cal passar una sèrie de controls i enviar un munt de documents sobre l'empresa, alguns dels quals han d'estar certificats per un advocat. L'obtenció d'un certificat de signatura de codi EV durant una pandèmia és un tema independent per a un article. El tràmit va durar un mes. I no va ser un mes d'espera, sinó de constants peticions de documents addicionals. Potser la pandèmia no hi va tenir res a veure i el procediment va trigar tant a tothom? Compartir.
Alguns diuen que no l'utilitzarem perquè no hi ha certificat FSTEC. Hem d'explicar que no ho podem obtenir i no ho aconseguirem perquè per obtenir aquest certificat, el xifratge ha d'estar d'acord amb GOST, i tenim previst distribuir el programari no només a Rússia i utilitzar AES.
Tots aquests comentaris posen en dubte que és possible promocionar un producte que requereixi entrar a comptes sense ser conegut públicament. Tot i que sabíem que hi hauria qui tingués una actitud molt negativa envers això. Després de superar el miler d'inscripcions, vam deixar de pensar-hi. Sobretot després que, a més de la negativitat dels que ni tan sols havien provat el producte, van començar a aparèixer crítiques molt agradables. Cal dir que aquestes crítiques positives són el principal motivador per al desenvolupament del producte.
Afegir la funcionalitat d'accés remot per als empleats
Una de les tasques freqüents dels clients és "donar a Vanya accés al seu ordinador des de casa". Vam crear VPN a Mikrotik i vam crear comptes per als usuaris. Però això és un problema real. Els usuaris no poden veure les instruccions i seguir-les pas a pas per connectar-se mitjançant VPN. Diferents versions de Windows. En un Windows tot es connecta bé, en un altre es necessita un protocol diferent. I en general, això sempre es va associar amb la reconfiguració dels equips de xarxa, que actuaven com a servidor VPN, i no tots els empleats hi tenen accés i això era inconvenient.
Però ja tenim connexions remotes a servidors i equips de xarxa. Per què no utilitzar un transport preparat i fer una petita utilitat a part que simplement podeu donar a l'usuari perquè es connecti. Només volia assegurar-me que l'usuari no hi introduïa res abstrus. Només un botó "connectar". Però, com entendrà aquesta utilitat on connectar-se si només té un botó? Hi va haver una idea per crear l'aplicació necessària en línia als nostres servidors. L'administrador del sistema fa clic al botó "Descarrega la drecera" i s'envia una ordre al nostre núvol per crear un binari individual amb informació cablejada per connectar-se al servidor/ordinador desitjat mitjançant RDP. En general, això es podria fer. Però això porta molt de temps; l'administrador hauria d'esperar primer fins que el binari es compila i després es descarrega. Per descomptat, seria possible afegir simplement un segon fitxer amb la configuració, però ja són 2 fitxers, i per senzillesa l'usuari necessita un. Un fitxer, un botó i sense instal·ladors. Després de llegir una mica a Google, vaig arribar a la conclusió que si afegiu alguna informació al final del compilat ".exe", no es deteriora (bé, gairebé). Almenys hi podeu afegir guerra i pau, i funcionarà com abans. Seria un pecat no aprofitar-ho. Ara només podeu desempaquetar l'aplicació sobre la marxa directament al mateix client, per la qual cosa s'anomena Veliam Connector, i simplement afegir la informació necessària per a la connexió al final. I la mateixa aplicació sap què fer-hi. Per què he escrit "bé gairebé" entre parèntesis una mica més alt? Perquè s'ha de pagar per aquesta comoditat, ja que l'aplicació perd la seva signatura digital. Però en aquesta etapa, creiem que aquest és un petit preu a pagar per tal comoditat.
Llicències de mòduls de tercers
Ja vaig escriure més amunt que després que es va decidir posar el producte a disposició del públic, i no només per al nostre propi ús, vam haver de treballar molt i buscar substitucions per a alguns mòduls que no ens permetessin incloure-nos al nostre producte. Però després del llançament, es va descobrir accidentalment una cosa molt desagradable. Veliam Server, que estava al costat del client, incloïa el SGBD MariaDB. I té llicència GPL. La llicència GPL implica que el programari ha de ser de codi obert, i si el nostre producte inclou MariaDB, que té aquesta llicència, el nostre producte ha d'estar sota aquesta llicència. Però, afortunadament, l'objectiu d'aquesta llicència és de codi obert, no castigar els que cometen errors accidentalment als tribunals. Si el titular dels drets d'autor té una reclamació, ho notificarà per escrit al infractor i ha d'eliminar la violació en un termini de 30 dies. Vam descobrir el nostre error nosaltres mateixos i no vam rebre cap carta i de seguida vam començar a considerar opcions sobre com resoldre el problema. La solució va resultar òbvia: canviar a SQLite. Aquesta base de dades no té restriccions de llicència. La majoria dels navegadors moderns utilitzen SQLite i un munt d'altres programes. He trobat informació a Internet que SQLite és considerat el SGBD més estès del món, precisament pels navegadors, però no he buscat proves, per tant, es tracta d'una informació inexacta. Vaig començar a estudiar els perills de canviar a SQLite.
Això es converteix en una tasca no trivial quan els clients tenen diversos centenars de servidors instal·lats amb MariaDB i dades. Algunes funcions de MariaDB no estan disponibles a SQLite. Bé, per exemple, al codi hem utilitzat consultes com
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Aquesta construcció no només fa una selecció de la taula, sinó que també bloqueja les dades de la fila. I també es van haver de reescriure diversos dissenys més. Però a més d'haver hagut de reescriure moltes consultes, també hem hagut de plantejar un mecanisme que, en actualitzar el servidor Veliam del client, portaria totes les dades al nou SGBD i eliminaria l'antic. A més, les transaccions a SQLite no van funcionar i això va ser un problema real. Però després de llegir la immensitat de la World Wide Web, vaig trobar sense cap problema que les transaccions a SQLite es poden habilitar passant una ordre senzilla en connectar-me.
PRAGMA journal_mode=WAL;Com a resultat, la tasca es va completar i ara la part del servidor del client s'executa a SQLite. No hem observat cap canvi en el funcionament del sistema.
Nou HelpDesk
Va ser necessari portar el sistema HelpDesk de la versió interna a la versió SaaS, però amb alguns canvis. El primer que volia fer era la integració amb el domini del client en termes d'autorització d'usuari transparent al sistema. Ara, per iniciar sessió a HelpDesk i deixar una sol·licitud al sistema, l'usuari simplement fa clic a la drecera de l'escriptori i s'obre el navegador. L'usuari no introdueix cap credencial. El mòdul per a Apache SSPI, que forma part de Veliam Server, autoritza automàticament l'usuari amb un compte de domini. Per deixar una sol·licitud al sistema quan l'usuari es troba fora de la xarxa corporativa, fa clic en un botó i rep un enllaç al seu correu electrònic mitjançant el qual s'inicia la sessió al sistema HelpDesk sense contrasenyes. Si un usuari està desactivat o suprimit en un domini, el compte de HelpDesk també deixarà de funcionar. Per tant, l'administrador del sistema no necessita supervisar els comptes tant al domini com al mateix HelpDesk. Un empleat surt: desconnecta el seu compte al domini i ja està, no iniciarà sessió al sistema ni des de la xarxa corporativa, ni mitjançant un enllaç. Perquè aquesta integració funcioni, l'administrador del sistema ha de crear un GPO, que и .
La segona cosa que considerem extremadament necessària per als sistemes HelpDesk, almenys per a nosaltres, és connectar-nos amb el sol·licitant directament des de l'aplicació amb un sol clic. A més, les connexions han de passar si l'administrador del sistema es troba en una xarxa diferent. Per a l'externalització això és obligatori, per als administradors de sistemes a temps complet també és molt necessari. Ja hi ha diversos productes que fan un excel·lent treball de connexions remotes. I vam decidir fer integracions per a ells. Ara ens hem integrat per a VNC, i en el futur tenim previst afegir Radmin i TeamViewer. Utilitzant el nostre transport de xarxa per a connexions remotes d'infraestructura, vam fer que VNC es connectés a estacions de treball remotes darrere de NAT. El mateix passarà amb Radmin. Ara, per connectar-se a un usuari, només cal que feu clic al botó "connectar amb el sol·licitant" de la mateixa aplicació. El client VNC s'obre i es connecta amb el sol·licitant, independentment de si esteu a la mateixa xarxa o asseguts a casa amb sabatilles. En primer lloc, l'administrador del sistema, mitjançant GPO, ha d'instal·lar el servidor VNC a les estacions de treball de tothom.
Ara nosaltres mateixos estem canviant al nou HelpDesk i utilitzant la integració amb el domini i VNC. Això és molt convenient per a nosaltres. Ara podem evitar pagar per TeamViewer, que fa més de tres anys que utilitzem per executar el nostre servei d'assistència.
Què tenim previst fer a continuació?
Quan vam llançar el producte, no vam fer cap tarifa de pagament, sinó que simplement vam limitar la tarifa gratuïta a 50 objectes de seguiment. Vam pensar que cinc dotzenes de dispositius i servidors de xarxa haurien de ser suficients per a tothom. I llavors van començar a arribar les peticions per augmentar el límit. Dir que estàvem una mica impactats és no dir res. Les empreses que tenen tants servidors estan realment interessades en el nostre programari? Hem ampliat el límit de forma gratuïta per a aquells que han fet aquestes peticions. En resposta a la seva sol·licitud, vam preguntar a alguns per què necessitaven tant, si realment tenien un nombre tan gran de servidors i equips de xarxa. I va resultar que els administradors del sistema van començar a utilitzar el sistema de maneres que no havíem previst gens. Tot va resultar senzill: el nostre programari va començar a supervisar no només els servidors, sinó també les estacions de treball. Per tant, hi ha moltes peticions per ampliar els límits. Ara ja hem introduït tarifes de pagament i els límits es poden ampliar de manera independent.
Els servidors gairebé sempre funcionen amb sistemes d'emmagatzematge o discs locals en una matriu RAID. I inicialment vam fer el producte per a ells. I el monitoratge SMART no era interessant per a aquesta tasca. Però tenint en compte el fet que la gent ha adaptat programari per a la monitorització de les estacions de treball, han aparegut peticions per a la implementació de la monitorització SMART. Ho implementarem aviat.
Amb l'arribada de Veliam Connector, es va fer innecessari desplegar un servidor VPN a la xarxa corporativa, o fer RDGW, o simplement reenviar ports a les màquines necessàries per connectar-se mitjançant RDP. Molta gent utilitza el nostre sistema només per a aquestes connexions remotes. Veliam Connector només està disponible per a Windows i alguns usuaris de l'empresa es connecten des d'ordinadors portàtils domèstics amb MacOS a estacions de treball o terminals de la xarxa corporativa. I resulta que l'administrador del sistema es veu obligat, a causa de diversos usuaris, a tornar encara al tema del reenviament o VPN. Per tant, ara estem acabant de fer una versió de Veliam Connector per a MacOS. Els usuaris de la seva tecnologia Apple preferida també tindran l'oportunitat de connectar-se a la infraestructura corporativa amb un sol clic.
M'agrada molt el fet que, tenint un gran nombre d'usuaris del sistema, no t'has d'avorrir sobre què necessita la gent i què serà més convenient. Ells mateixos escriuen els seus desitjos, de manera que hi ha molts plans de desenvolupament per al futur proper.
Paral·lelament, ara tenim previst començar a traduir el sistema a l'anglès i distribuir-lo a l'estranger. Encara no sabem com distribuirem el producte fora del nostre país, estem buscant opcions. Potser hi haurà un article a part sobre això més endavant. Potser algú que ha llegit aquest article podrà suggerir el vector requerit, o ell mateix sap i sap com fer-ho i oferirà els seus serveis. Agrairem la vostra ajuda.
Font: www.habr.com