В , 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 costat del servidor actual per als usuaris estava activat LinuxGairebé totes les organitzacions tenen Windows servidors, cosa que no es pot dir de LinuxEl principal punt fort de Veliam són les connexions remotes a servidors i equips de xarxa darrere del NAT. Tanmateix, aquesta funcionalitat estava estrictament lligada al fet que l'encaminador havia de ser un Mikrotik. Això clarament no satisfaria a molta gent. Inicialment vaig considerar afegir compatibilitat amb els encaminadors dels proveïdors més populars. Però em vaig adonar que aquesta seria una cursa interminable per ampliar la llista d'empreses compatibles. A més, fins i tot les que ja són compatibles poden tenir diferents conjunts d'ordres per canviar les regles NAT segons el model. Una VPN semblava l'única solució.
Com que vam decidir distribuir el producte, però no com a codi obert, no vam poder incloure diverses biblioteques amb llicències obertes com la GPL. Això és un altre problema: després de decidir vendre el producte, vam haver de reelaborar la meitat de les biblioteques perquè eren GPL. Quan escrivim per a nosaltres mateixos, això estava bé. Però no és adequat per a la distribució. La primera VPN que em ve al cap és... OpenVPNPerò és GPL. Una altra opció era utilitzar la VPN japonesa SoftEther. La seva llicència permetia incloure-la al producte. Després d'un parell de dies de diverses proves sobre com integrar-la perquè l'usuari no hagués de configurar res ni saber res sobre la VPN SoftEther, vam crear un prototip. Tot va funcionar com s'esperava. Però per alguna raó, aquest esquema encara ens molestava i finalment el vam abandonar. Naturalment, el vam abandonar després de trobar una altra opció. Al final, tot es va fer mitjançant connexions TCP normals. Algunes connexions funcionen a través d'un coordinador, altres directament mitjançant la tecnologia Nat Hole Punching (NHP), que també es va implementar a Free Pascal. He de dir que mai havia sentit a parlar de NHP abans. I mai se m'havia acudit que es poguessin connectar directament dos dispositius de xarxa, tots dos darrere d'un NAT. Vaig estudiar el tema, vaig entendre el principi i em vaig asseure a escriure. La idea s'ha implementat: l'usuari es connecta amb un sol clic al dispositiu desitjat darrere d'un NAT mitjançant RDP, SSH o Winbox, sense introduir contrasenyes ni configurar una VPN. A més, la majoria d'aquestes connexions eviten el nostre coordinador, cosa que té un efecte positiu sobre el ping i el cost de manteniment d'aquestes connexions.
Traducció de la part del servidor de Linux en Windows
Problemes amb la transició a Windows N'hi havia diversos. Primer, el wmic integrat a Windows no permet consultes WQL. I el nostre sistema ja estava basat en elles. I hi havia algunes altres coses, però he oblidat per què finalment ho vam abandonar. Potser hi ha diferències entre versions. WindowsI el segon problema és el multithreading. Incapaç de trobar una bona utilitat de tercers amb una llicència acceptable, vaig tornar a iniciar l'IDE Lazarus i vaig escriure la utilitat necessària. Pren la llista d'objectes requerida i les consultes específiques que s'han de fer com a entrada i rep les dades en resposta. I tot això en mode multithreading. Excel·lent.
Després de configurar pthreads per a PHP Windows Pensava que tot funcionaria bé, però no va funcionar. Després d'una mica de depuració, em vaig adonar que els pthreads semblaven funcionar, però no funcionaven al nostre sistema. Va quedar clar que hi havia alguna peculiaritat amb els pthreads a WindowsAixí és com va ser. Vaig llegir la documentació i deia que per a Windows El nombre de fils d'execució és limitat i, pel que recordo, és implícit. Això es va convertir en un problema. Perquè quan vaig començar a reduir el nombre de fils d'execució de l'aplicació, funcionava molt lentament. Vaig tornar a obrir l'IDE i la mateixa utilitat s'havia actualitzat amb la funcionalitat de ping d'objectes multifil. I també es va afegir l'escaneig de ports. Després d'això, la necessitat de pthreads per a PHP va desaparèixer i ja no s'utilitza. Més tard es van afegir diverses funcions més a aquesta utilitat, i encara funciona avui dia. Després d'això, es va compilar un instal·lador per a Windows, que incloïa Apache, PHP, MariaDB, la mateixa aplicació PHP i un conjunt d'utilitats per interactuar amb el sistema, totes escrites en Free Pascal. Pel que fa a l'instal·lador, vaig pensar que resoldria ràpidament aquest problema, ja que és extremadament comú i necessari per a gairebé tots els programes. O bé no buscava al lloc correcte, o era una cosa completament diferent. Però em trobava constantment amb productes que no eren prou flexibles o que eren cars i també inflexibles. Finalment, vaig trobar un instal·lador gratuït que pot satisfer qualsevol necessitat: InnoSetup. N'escric aquí perquè l'he hagut de buscar, per si de cas estalvia temps a algú.
Rebuig del connector a favor del vostre client
Abans vaig escriure que el costat del client era un navegador amb un "connector". Així que hi havia vegades que Chrome s'actualitzava i el disseny es tornava una mica maldestre, o Windows Actualitzaré i l'esquema d'UR personalitzat desapareixerà. Realment no volia tenir aquest tipus de sorpresa a la versió pública del producte. A més, els esquemes d'UR personalitzats van començar a desaparèixer després de cada actualització. WindowsMicrosoft simplement ha eliminat totes les branques que no són de Microsoft a la secció pertinent. Google Chrome tampoc recorda l'opció d'obrir una aplicació des d'una URL personalitzada, fent aquesta pregunta cada vegada que feu clic en un objecte supervisat. Finalment, calia una interacció adequada amb el sistema local de l'usuari, cosa que el navegador no proporciona. L'opció més senzilla en aquest escenari sembla ser simplement crear el vostre propi navegador, com molts fan ara amb Electron. Però moltes coses ja estaven escrites en Free Pascal, inclòs el costat del servidor, per la qual cosa van decidir fer el client en el mateix llenguatge en lloc de crear una barreja. Així doncs, es va escriure un client amb Chromium a bord. Després d'això, va començar a adquirir diverses vinculacions.
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 peticions més habituals dels clients és "donar accés a l'Ivan al seu ordinador des de casa". Vam configurar una VPN a Mikrotik i vam crear comptes d'usuari. Però això és un problema real. Els usuaris no poden seguir les instruccions ni seguir les instruccions pas a pas per connectar-se mitjançant VPN. Diferents versions WindowsEn un Windows, tot es connecta correctament, però en un altre, es requereix un protocol diferent. I, en general, això sempre implicava reconfigurar l'equip de xarxa que servia com a servidor VPN, i no tots els empleats hi tenien accés, cosa que 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, ja no cal implementar un servidor VPN a la xarxa corporativa, ni crear un RDGW, ni simplement reenviar ports a les màquines necessàries per a les connexions RDP. Molta gent utilitza el nostre sistema únicament per a aquestes connexions remotes. Veliam Connector només està disponible a Windows, i alguns usuaris corporatius es connecten des d'ordinadors portàtils domèstics amb macOS a estacions de treball o terminals de la xarxa corporativa. Això significa que l'administrador del sistema es veu obligat a revisar el problema del reenviament o de les VPN a causa de la presència de múltiples usuaris. Per tant, actualment estem finalitzant el desenvolupament de la versió per a macOS del connector Veliam. Els usuaris dels seus dispositius Apple preferits també podran 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
