В , falei dos antecedentes da creación de Veliam e da decisión de distribuílo a través do sistema SaaS. Neste artigo, falarei do que tiven que facer para que o produto non fose local, senón público. Sobre como comezou a distribución e que problemas atoparon.
Planificación
O backend actual para os usuarios estaba en Linux. Case todas as organizacións teñen servidores Windows, o que non se pode dicir sobre Linux. A principal fortaleza de Veliam son as conexións remotas a servidores e equipos de rede detrás de NAT. Pero esta funcionalidade estaba moi ligada ao feito de que o enrutador tiña que ser Mikrotik. E isto obviamente non satisfaría a moitos. Primeiro comecei a pensar en engadir soporte para enrutadores dos provedores máis comúns. Pero entendín que esta era unha carreira interminable para ampliar a lista de empresas apoiadas. Ademais, aqueles que xa están soportados poden ter un conxunto diferente de comandos para cambiar as regras NAT dun modelo a outro. A única forma de saír da situación parecía ser unha VPN.
Desde que decidimos distribuír o produto, pero non como código aberto, fíxose imposible incluír varias bibliotecas con licenzas abertas como GPL. Este é xeralmente un tema separado; despois de tomar a decisión de vender o produto, tiven que pasar pola metade das bibliotecas debido ao feito de que eran GPL. Cando escribían por si mesmos, era normal. Pero non apto para a distribución. A primeira VPN que se me ocorre é OpenVPN. Pero é GPL. Outra opción era usar a VPN SoftEther xaponesa. A súa licenza permitiulle incluíla no seu produto. Despois dun par de días de probas diversas sobre como integralo de forma que o usuario non necesite configurar nada e coñecer a VPN de SoftEther, conseguiuse un prototipo. Todo foi como debía ser. Pero por algún motivo este esquema aínda nos confundiu, e finalmente abandonámolo. Pero, naturalmente, negáronse despois de que se lles ocorrese outra opción. Ao final, todo se fixo en conexións TCP regulares. Algunhas conexións funcionan a través dun coordinador, outras directamente a través da tecnoloxía Nat Hole Punching (NHP), que tamén se implementou en Free Pascal. Debo dicir que nunca antes oín falar de NHP. E nunca se me ocorreu que fose posible conectar 2 dispositivos de rede, ambos directamente detrás de NAT. Estudei o tema, entendín o principio de funcionamento e senteime a escribir. O plan realízase, o usuario conéctase cun clic ao dispositivo desexado detrás de NAT a través de RDP, SSH ou Winbox sen introducir contrasinais nin configurar unha VPN. Ademais, a maioría destas conexións pasan polo noso coordinador, o que ten un bo efecto no ping e no custo do servizo destas conexións.
Transferir a parte do servidor de Linux a Windows
Houbo varios problemas ao cambiar a Windows. O primeiro é que o wmic integrado en Windows non che permite facer consultas WQL. E no noso sistema xa estaba todo construído sobre eles. E había algo máis, pero agora esquecín por que finalmente abandonaron o seu uso. Posiblemente diferenzas entre as versións de Windows. E o segundo problema é o multithreading. Non atopando unha boa utilidade de terceiros baixo unha licenza "aceptable" para nós, iniciei de novo o Lazarus IDE. E escribín a utilidade necesaria. A entrada é a lista requirida de obxectos e que consultas específicas hai que facer, e en resposta recibo datos. E todo isto en modo multi-fíos. Genial.
Despois de configurar pthreads para PHP Windows, pensei que todo comezaría de inmediato, pero non foi así. Despois dun tempo de depuración, decateime de que pthreads parecía funcionar, pero non funcionaba no noso sistema. Quedou claro que hai algunha peculiaridade ao traballar con pthreads en Windows. E así foi. Lin a documentación, e alí estaba escrito que para Windows o número de fíos é limitado, e, polo que recordo, implícito. Isto converteuse nun problema. Porque cando comecei a reducir o número de fíos nos que se executaba a aplicación, fixo o traballo moi lentamente. Abrín de novo o IDE e engadíronse á mesma utilidade a funcionalidade para o ping multiproceso de obxectos. Ben, xa hai moita exploración de portos alí tamén. En realidade, despois disto, a necesidade de pthreads para PHP desapareceu e xa non se usa. Ademais, engadíronse varias funcionalidades máis a esta utilidade e aínda funciona a día de hoxe. Despois disto, montouse un instalador para Windows, que incluía Apache, PHP, MariaDB, a propia aplicación PHP e un conxunto de utilidades para interactuar co sistema, escritas en Free Pascal. En canto ao instalador, pensei que resolvería rapidamente este problema, porque... Isto é algo moi común e necesario para case todos os programas. Ou estaba mirando no lugar equivocado, ou outra cousa. Pero constantemente atopeime con produtos que non eran o suficientemente flexibles, ou caros e tamén inflexibles. E aínda así, atopei un instalador gratuíto no que será posible cubrir calquera desexo. Este é InnoSetup. Escribo sobre isto aquí porque tiven que buscalo por se aforro tempo a alguén.
Rexeitamento do complemento a favor do teu cliente
Anteriormente escribín que a parte do cliente era un navegador cun "complemento". Entón, houbo momentos nos que Chrome se actualizou e o deseño estaba un pouco torto, despois actualizouse Windows e desapareceu o esquema uri personalizado. Realmente non quería ter este tipo de sorpresas na versión pública do produto. Ademais, o uri personalizado comezou a desaparecer despois de cada actualización de Windows. Microsoft simplemente eliminou todas as ramas que non son as súas na sección requirida. Ademais, Google Chrome agora non permite lembrar a opción de abrir ou non unha aplicación desde o uri personalizado e fai esta pregunta cada vez que fai clic nun obxecto de monitorización. Ben, en xeral, era necesaria a interacción normal co sistema local do usuario, que o navegador non ofrece. A opción máis sinxela deste esquema parece ser simplemente facer o teu propio navegador, como moitos están facendo agora a través de Electron. Pero xa se escribiran moitas cousas en Free Pascal, incluso na parte do servidor, polo que decidimos facer o cliente no mesmo idioma, e non crear un zoolóxico. Así se escribiu un cliente con Chromium a bordo. Despois diso, comezou a adquirir varios tirantes.
Lanzamento
Finalmente escollemos un nome para o sistema. Pasamos constantemente por varias opcións mentres estaba en marcha o proceso de conversión da versión local a SaaS. Dado que inicialmente planeabamos entrar non só no mercado doméstico, o principal criterio para seleccionar un nome era a presenza dun dominio desocupado ou non moi caro na zona ".com". Algunhas funcións/módulos aínda non foron portados desde a versión local a Veliam, pero decidimos que os publicaríamos coa funcionalidade actual e completaríamos o resto como actualizacións. Na primeira versión non había HelpDesk, Veliam Connector, era imposible cambiar os limiares dos disparadores de notificacións e moito máis. Compramos un certificado de sinatura de código e asinamos as partes do cliente e do servidor. Escribimos un sitio web para o produto, iniciamos trámites para rexistrar software, marca comercial, etc. En xeral, estamos preparados para comezar. Unha lixeira euforia polo traballo realizado e polo feito de que quizais alguén utilice o teu produto, aínda que disto non tiñamos dúbidas. E despois para. O socio dixo que é imposible entrar no mercado sen notificacións a través de mensaxeiros. É posible sen moitas outras cousas, pero non sen isto. Despois dalgún debate, engadiuse a integración con Telegram, que nos conveña. De todos os actuais mensaxeiros instantáneos, este é o único que ofrece acceso ás súas API de xeito gratuíto e sen procedementos de aprobación complexos. O mesmo WhatsApp suxire poñerse en contacto con provedores que cobran un bo diñeiro por usar os seus servizos; ignoraron todas as cartas solicitando acceso sen xuntas. Ben, Viber... Non sei quen o usa agora, porque... o spam e a publicidade están fóra das listas. A finais de decembro, tras unha serie de probas internas e probas entre amigos, abriuse o rexistro para todos e púxose a disposición do software para descargar.
Inicio da distribución
Desde o primeiro momento, entendemos que necesitábamos un pequeno fluxo de usuarios do sistema para que puidesen probar o produto no modo de combate e dar os primeiros comentarios. Varias publicacións compradas en VK deron os seus froitos. Chegaron as primeiras inscricións.
Aquí hai que dicir que entrar no mercado cando a túa empresa non ten un nome famoso e, ao mesmo tempo, proporcionar unha funcionalidade de vixilancia sen axentes na que necesitas introducir contas desde os teus servidores e estacións de traballo, é moi difícil. Isto asusta a moita xente. Entendemos desde o primeiro momento que ía haber problemas con isto e estabamos preparados para iso tanto técnica como moralmente. Todas as conexións remotas, a pesar de que RDP e SSH xa están cifradas de forma predeterminada, o noso software cífrase adicionalmente mediante o estándar AES. Todos os datos dos servidores locais transfírense á nube a través de HTTPS. As contas almacénanse en forma cifrada. As claves de cifrado de todos os subsistemas son individuais para todos os clientes. Para conexións remotas, úsanse xeralmente claves de cifrado de sesión.
O único que podemos facer nesta situación para que a xente se sinta máis tranquila é estar o máis abertos posible, traballar na seguridade e non cansar nunca de responder ás preguntas da xente.
Para moitos, a comodidade e a funcionalidade do software superan o medo e rexístranse. Algunhas persoas escribiron en publicacións publicadas en VK que este software non se pode usar porque Esta é unha colección dos seus contrasinais e xeralmente unha empresa sen nome. Hai que dicir que máis dunha persoa tiña esta opinión. Moitas persoas simplemente non entenden que cando instalan outro software propietario nun servidor que se executa como un servizo, tamén ten todos os dereitos no sistema e non precisan contas para facer algo ilegal (está claro que pode cambiar o usuario desde o que se inicia o servizo, pero aquí tamén podes introducir calquera conta). De feito, os medos da xente son comprensibles. Instalar software nun servidor é algo común, pero entrar nunha conta dá un pouco de medo e íntimo, xa que boa metade das persoas teñen o mesmo contrasinal para todos os servizos e crear unha conta separada mesmo para unha proba é preguiceiro. Pero neste momento hai un gran número de servizos nos que a xente confía coas súas credenciais e moito máis. E esforzámonos por converternos nun deles.
Houbo moitos comentarios que dicían que o roubamos nalgún sitio. Isto sorprendeunos un pouco. Ben, vale, a opinión dunha persoa, pero tales comentarios atopáronse en varias publicacións de diferentes persoas. Ao principio non sabían como reaccionar ante isto. Xa sexa por estar triste que algunhas persoas teñan a opinión de que en Rusia ninguén pode facer nada por si só, senón que só pode roubar, ou ben por estar contentos de que pensen que isto só se pode roubar.
Agora completamos o procedemento para obter un certificado de sinatura do código EV. Para obtelo cómpre pasar unha serie de comprobacións e enviar unha morea de documentos sobre a empresa, algúns dos cales deben estar certificados por un avogado. A obtención dun certificado de sinal de código EV durante unha pandemia é un tema separado para un artigo. O procedemento levou un mes. E non foi un mes de espera, senón de constantes solicitudes de documentos complementarios. Quizais a pandemia non tivese nada que ver e o procedemento durou tanto para todos? Compartir.
Algúns din que non o usaremos porque non hai certificado FSTEC. Temos que explicar que non podemos obtelo e non o conseguiremos porque para obter este certificado, o cifrado debe estar de acordo con GOST e pensamos distribuír o software non só en Rusia e usar AES.
Todos estes comentarios poñen en dúbida que é posible promocionar un produto que require entrar en contas sen ser coñecido públicamente. Aínda que sabiamos que habería quen tivese unha actitude moi negativa ante isto. Despois de que o número de inscricións superou o milleiro, deixamos de pensar niso. Especialmente despois de que, ademais da negatividade dos que nin sequera probaran o produto, comezaron a aparecer críticas moi agradables. Hai que dicir que estas críticas positivas son o maior motivador para o desenvolvemento do produto.
Engadindo a funcionalidade de acceso remoto para os empregados
Unha das tarefas frecuentes dos clientes é "dar acceso a Vanya ao seu ordenador desde a casa". Creamos VPN en Mikrotik e creamos contas para usuarios. Pero este é un problema real. Os usuarios non poden ver as instrucións e seguilas paso a paso para conectarse mediante VPN. Diferentes versións de Windows. Nun Windows todo se conecta ben, noutro é necesario un protocolo diferente. E, en xeral, isto sempre estivo asociado á reconfiguración dos equipos de rede, que actuaban como servidor VPN, e non todos os empregados teñen acceso a el e isto era un inconveniente.
Pero xa temos conexións remotas a servidores e equipos de rede. Por que non usar un transporte preparado e facer unha pequena utilidade separada que pode simplemente darlle ao usuario para que se conecte. Só quería asegurarme de que o usuario non introduciu nada abstruso alí. Só un botón "conectar". Pero como entenderá esta utilidade onde conectarse se só ten un botón? Houbo unha idea para crear a aplicación necesaria en liña nos nosos servidores. O administrador do sistema fai clic no botón "Descargar atallo" e envíase un comando á nosa nube para construír un binario individual con información cableada para conectarse ao servidor/ordenador desexado mediante RDP. En xeral, isto podería facerse. Pero isto leva moito tempo; o administrador tería que esperar primeiro ata que o binario sexa compilado e despois descargado. Por suposto, sería posible simplemente engadir un segundo ficheiro coa configuración, pero este xa son 2 ficheiros, e para simplificar o usuario necesita un. Un ficheiro, un botón e sen instaladores. Despois de ler un pouco en Google, cheguei á conclusión de que se engades algunha información ao final do ".exe" compilado, entón non se deteriora (ben, case). Polo menos podes engadir guerra e paz alí, e funcionará como antes. Sería un pecado non aproveitar isto. Agora podes simplemente desempaquetar a aplicación en calquera lugar, directamente no propio cliente, polo que se chama Veliam Connector, e simplemente engadir a información necesaria para conectarse a ela ao final. E a propia aplicación sabe que facer con ela. Por que escribín "ben case" entre parénteses un pouco máis alto? Porque hai que pagar por esta comodidade xa que a aplicación perde a súa sinatura dixital. Pero neste momento, cremos que este é un pequeno prezo a pagar por tal comodidade.
Licenzas de módulos de terceiros
Xa escribín anteriormente que despois de que se decidiu poñer o produto a disposición do público, e non só para o noso propio uso, tivemos que traballar moito e buscar substitucións para algúns módulos que non nos permitisen incluír no noso produto. Pero despois do lanzamento, descubriuse accidentalmente unha cousa moi desagradable. Veliam Server, que estaba no lado do cliente, incluía o DBMS MariaDB. E ten licenza GPL. A licenza GPL implica que o software debe ser de código aberto e, se o noso produto inclúe MariaDB, que ten esta licenza, entón o noso produto debe estar baixo esta licenza. Pero, afortunadamente, o propósito desta licenza é de código aberto, non castigar a aqueles que cometen erros accidentalmente no xulgado. Se o titular dos dereitos de autor ten unha reclamación, notificará por escrito ao infractor e deberá eliminar a infracción nun prazo de 30 días. Descubrimos o noso erro nós mesmos e non recibimos ningunha carta e inmediatamente comezamos a considerar opcións sobre como resolver o problema. A solución resultou obvia: cambiar a SQLite. Esta base de datos non ten restricións de licenza. A maioría dos navegadores modernos usan SQLite e moitos outros programas. Atopei información en Internet de que SQLite é considerado o DBMS máis estendido do mundo, precisamente polos navegadores, pero non busquei probas, polo que esta é información inexacta. Comecei a estudar os perigos de cambiar a SQLite.
Isto convértese nunha tarefa non trivial cando os clientes teñen varios centos de servidores instalados con MariaDB e datos nel. Algunhas funcións de MariaDB non están dispoñibles en SQLite. Ben, por exemplo, no código usamos consultas como
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Esta construción non só fai unha selección da táboa, senón que tamén bloquea os datos da fila. E tamén houbo que reescribir varios deseños máis. Pero ademais de que tivemos que reescribir moitas consultas, tamén tivemos que idear un mecanismo que, ao actualizar o Servidor Veliam do cliente, portase todos os datos ao novo DBMS e eliminase o antigo. Ademais, as transaccións en SQLite non funcionaron e este foi un problema real. Pero despois de ler a inmensidade da World Wide Web, descubrín sen ningún problema que as transaccións en SQLite se poden habilitar pasando un simple comando ao conectar
PRAGMA journal_mode=WAL;Como resultado, a tarefa completouse e agora a parte do servidor do cliente execútase en SQLite. Non observamos ningún cambio no funcionamento do sistema.
Novo HelpDesk
Foi necesario portar o sistema HelpDesk da versión interna á versión SaaS, pero con algúns cambios. O primeiro que quería facer era a integración co dominio do cliente en termos de autorización de usuario transparente no sistema. Agora, para iniciar sesión en HelpDesk e deixar unha solicitude no sistema, o usuario simplemente fai clic no atallo do escritorio e ábrese o navegador. O usuario non introduce ningunha credencial. O módulo para Apache SSPI, que forma parte de Veliam Server, autoriza automaticamente ao usuario cunha conta de dominio. Para deixar unha solicitude no sistema cando o usuario está fóra da rede corporativa, fai clic nun botón e recibe no seu correo electrónico unha ligazón a través da cal accede ao sistema HelpDesk sen contrasinais. Se un usuario está desactivado ou eliminado nun dominio, a conta de HelpDesk tamén deixará de funcionar. Así, o administrador do sistema non precisa supervisar as contas tanto no dominio como no propio HelpDesk. Un empregado sae: desconecta a súa conta no dominio e xa está, non iniciará sesión no sistema nin desde a rede corporativa nin a través dunha ligazón. Para que esta integración funcione, o administrador do sistema debe crear un GPO, que и .
O segundo que consideramos extremadamente necesario para os sistemas de HelpDesk, polo menos para nós, é conectarse ao solicitante directamente desde a aplicación cun só clic. Ademais, as conexións deben pasar se o administrador do sistema está nunha rede diferente. Para a subcontratación é obrigatorio, para os administradores de sistemas a tempo completo tamén é moi necesario. Xa hai varios produtos que fan un excelente traballo de conexións remotas. E decidimos facerlles integracións. Agora integrámonos para VNC e, no futuro, pensamos engadir Radmin e TeamViewer. Usando o noso transporte de rede para conexións de infraestrutura remotas, fixemos que VNC se conectase a estacións de traballo remotas detrás de NAT. O mesmo ocorrerá con Radmin. Agora, para conectarse a un usuario, só tes que facer clic no botón "conectar ao solicitante" na propia aplicación. O cliente VNC ábrese e conéctase ao solicitante, independentemente de se estás na mesma rede ou estás sentado na casa con chinelos. En primeiro lugar, o administrador do sistema, usando GPO, debe instalar o servidor VNC nas estacións de traballo de todos.
Agora nós mesmos estamos cambiando ao novo HelpDesk e utilizando a integración co dominio e VNC. Isto é moi cómodo para nós. Agora podemos evitar pagar por TeamViewer, que levamos máis de tres anos usando para executar o noso servizo de soporte.
Que pensamos facer a continuación?
Cando lanzamos o produto, non fixemos ningunha tarifa de pago, senón que simplemente limitamos a tarifa gratuíta a 50 obxectos de seguimento. Cinco ducias de dispositivos e servidores de rede deberían ser suficientes para todos, pensamos. E entón comezaron a chegar as peticións para aumentar o límite. Dicir que estabamos un pouco impresionados é non dicir nada. As empresas que teñen tantos servidores están realmente interesadas no noso software? Ampliamos o límite de forma gratuíta para aqueles que fixeron este tipo de solicitudes. En resposta á súa solicitude, preguntamos a algúns por que necesitaban tanto, se realmente tiñan un número tan grande de servidores e equipos de rede. E resultou que os administradores do sistema comezaron a usar o sistema de xeitos que non tiñamos planeado en absoluto. Todo resultou sinxelo: o noso software comezou a supervisar non só os servidores, senón tamén as estacións de traballo. Por iso hai moitas solicitudes para ampliar os límites. Agora xa introducimos tarifas de pago e os límites pódense ampliar de forma independente.
Os servidores case sempre funcionan con sistemas de almacenamento ou discos locais nunha matriz RAID. E inicialmente fixemos o produto para eles. E o seguimento SMART non foi interesante para esta tarefa. Pero tendo en conta o feito de que a xente adaptou o software para monitorizar as estacións de traballo, apareceron solicitudes para a implantación da vixilancia SMART. Implementarémolo en breve.
Coa chegada de Veliam Connector, fíxose innecesario implantar un servidor VPN na rede corporativa, ou facer RDGW, ou simplemente reenviar portos ás máquinas necesarias para conectarse mediante RDP. Moitas persoas usan o noso sistema só para estas conexións remotas. Veliam Connector só está dispoñible para Windows, e algúns usuarios da empresa conéctanse desde portátiles domésticos con MacOS a estacións de traballo ou terminais da rede corporativa. E resulta que o administrador do sistema vese obrigado, debido a varios usuarios, a volver aínda ao tema do reenvío ou VPN. Polo tanto, agora estamos rematando de facer unha versión de Veliam Connector para MacOS. Os usuarios da súa tecnoloxía favorita de Apple tamén terán a oportunidade de conectarse á infraestrutura corporativa cun só clic.
Gústame moito o feito de que, tendo un gran número de usuarios do sistema, non tes que pensar sobre o que a xente necesita e o que será máis conveniente. Eles mesmos escriben os seus desexos, polo que hai moitos plans de desenvolvemento para o futuro próximo.
Paralelamente, agora temos previsto comezar a traducir o sistema ao inglés e distribuílo no estranxeiro. Aínda non sabemos como distribuiremos o produto fóra do noso país, estamos a buscar opcións. Quizais haxa un artigo separado sobre isto máis adiante. Quizais alguén que leu este artigo poida suxerir o vector necesario, ou el mesmo sabe e sabe como facelo e ofrecerá os seus servizos. Agradeceríamos a súa axuda.
Fonte: www.habr.com