Dans , j'ai parlé de l'historique de création de Veliam et de la décision de sa distribution via le système SaaS. Dans cet article, je vais expliquer ce qu'il a fallu faire pour que le produit passe de local à public. Comment nous avons commencé la distribution et les problèmes auxquels nous avons été confrontés.
Planification
La partie serveur actuelle pour les utilisateurs était sous Linux. Presque toutes les organisations disposent de serveurs Windows, ce qui n'est pas le cas pour Linux. La principale force de Veliam réside dans les connexions distantes aux serveurs et aux équipements réseau derrière un NAT. Mais cette fonctionnalité était très strictement liée au fait que le routeur devait nécessairement être un MikroTik. Cela aurait clairement frustré beaucoup de gens. J'ai d'abord pensé à ajouter le support pour les routeurs des vendeurs les plus courants. Mais je comprenais que c'était une course sans fin pour élargir la liste des entreprises prises en charge. De plus, même celles qui sont déjà prises en charge peuvent avoir un ensemble de commandes variable d'un modèle à l'autre pour modifier les règles NAT. La seule solution semblait être le VPN.
Comme nous avons décidé de distribuer le produit, mais pas en open source, il est devenu impossible d'inclure différentes bibliothèques sous des licences ouvertes comme la GPL. C'est un sujet à part, après avoir pris la décision de vendre le produit, nous avons dû examiner la moitié des bibliothèques à cause de leur licence GPL. Quand nous développions pour nous-mêmes, c'était acceptable. Mais pour la distribution, ce n'est pas adapté. Le premier VPN qui vient à l'esprit est OpenVPN. Mais il est GPL. Une autre option était d'utiliser SoftEther VPN japonais. Sa licence permettait de l'inclure dans notre produit. Après quelques jours de tests pour intégrer cela de manière à ce que l'utilisateur n'ait absolument rien à configurer ni à savoir sur SoftEther VPN — un prototype a été créé. Tout était comme il se devait. Mais, pour une raison quelconque, ce schéma nous troublait quand même, et nous y avons finalement renoncé. Naturellement, nous avons renoncé après avoir trouvé une autre solution. Finalement, tout a été réalisé sur de simples connexions TCP. Une partie des connexions fonctionne via un coordinateur, une autre directement grâce à la technologie Nat Hole Punching (NHP), qui a également été mise en œuvre en Free Pascal. Il faut dire que je n'avais jamais entendu parler de NHP auparavant. Je n'avais même pas imaginé qu'il était possible de connecter directement deux dispositifs réseau, tous deux derrière NAT. J'ai étudié le sujet, compris le principe de fonctionnement et me suis mis à écrire. Ce qui était prévu a été réalisé, l'utilisateur se connecte d'un clic au dispositif désiré derrière NAT par RDP, SSH ou Winbox sans avoir à entrer de mots de passe ni à configurer le VPN. De plus, la grande majorité de ces connexions passe à côté de notre coordinateur, ce qui a un bon impact sur le ping et le coût de maintenance de ces connexions.
Migration de la partie serveur de Linux vers Windows
Il y avait plusieurs problèmes lors du passage à Windows. Le premier — le wmic intégré dans Windows ne permet pas d'effectuer des requêtes WQL. Or, dans notre système, tout était déjà basé là-dessus. Et il y avait autre chose, mais je ne me souviens plus pourquoi nous avons finalement renoncé à son utilisation. Peut-être à cause des différences entre les versions de Windows. Et le deuxième problème — la multithéresse. Ne trouvant pas de bonne utilitaire tiers sous une licence "acceptable" pour nous, j'ai à nouveau lancé l'IDE Lazarus. Et j'ai écrit l'utilitaire nécessaire. En entrée, je fournis la liste requise des objets et les requêtes à effectuer, et en réponse, je reçois les données. Et tout cela en mode multithread. Excellent.
Après avoir configuré pthreads pour PHP Windows, je pensais que tout fonctionnerait, mais ce n'était pas si simple. Après un certain temps de débogage, j'ai réalisé que pthreads semblait fonctionner, mais qu'il ne fonctionnait pas dans notre système. Il est devenu évident qu'il y avait une particularité de l'utilisation de pthreads sous Windows. C'était effectivement le cas. J'ai lu la documentation, et il était mentionné que le nombre de threads est limité pour Windows, et si je me souviens bien, cela n'était pas explicite. Cela a posé un problème. Car lorsque j'ai commencé à réduire le nombre de threads pour lesquels l'application fonctionnait, elle exécutait son travail très lentement. J'ai de nouveau ouvert l'IDE, et la fonctionnalité de ping multi-thread des objets y a été ajoutée. Et en prime, il y a eu l'ajout du scan de ports. En fait, après cela, le besoin de pthreads pour PHP a disparu et il n'est plus utilisé. Par la suite, quelques autres fonctionnalités ont été ajoutées à cet outil, et il fonctionne toujours aujourd'hui. Après cela, j'ai assemblé un installateur pour Windows, qui comprenait Apache, PHP, MariaDB, l'application PHP elle-même et un ensemble d'outils pour interagir avec le système, écrits en Free Pascal. En ce qui concerne l'installateur, je pensais que ce problème serait résolu rapidement, car c'est une chose extrêmement courante et nécessaire pour presque tous les logiciels. Soit je ne cherchais pas correctement, soit autre chose. Mais je tombais constamment sur des produits qui étaient soit pas assez flexibles, soit chers et peu flexibles. Cependant, j'ai finalement trouvé un installateur gratuit, qui permet de prévoir toutes les options souhaitées. C'est InnoSetup. Je parle de cela ici parce que j'ai dû chercher, au cas où je pourrais faire gagner du temps à quelqu'un.
Abandon du plugin au profit de son client
J'ai précédemment mentionné que la partie cliente était un navigateur avec un « plug-in ». Il y avait des moments où Chrome se mettait à jour et l'affichage devenait un peu déformé, ou bien Windows se mettait à jour et le schéma URI personnalisé disparaissait. Je ne voulais vraiment pas de ce genre de surprises dans la version publique du produit. D'ailleurs, le schéma URI personnalisé commençait à disparaître après chaque mise à jour de Windows. Microsoft supprimait tout simplement toutes les branches non liées à elle dans la section appropriée. De plus, Google Chrome ne permet plus de mémoriser le choix d'ouvrir ou non l'application à partir d'un schéma URI personnalisé, et il pose cette question à chaque clic sur l'objet de surveillance. En gros, il était nécessaire d'avoir une interaction normale avec le système local de l'utilisateur, ce que le navigateur ne permet pas. La solution la plus simple dans ce cas semble être de créer son propre navigateur, comme beaucoup le font actuellement avec Electron. Cependant, beaucoup de choses avaient déjà été écrites en Free Pascal, y compris dans la partie serveur, donc nous avons décidé de créer le client dans le même langage pour ne pas créer un zoo de technologies. C'est ainsi qu'un client avec Chromium à bord a été développé. Après cela, il a commencé à se doter de divers wrappers.
La version
Nous avons enfin choisi un nom pour le système. Nous avons constamment examiné différentes options pendant le processus de transformation de la version locale en SaaS. Comme nous avions initialement prévu de lancer notre produit non seulement sur le marché intérieur, le critère principal pour choisir un nom était la disponibilité d'un domaine libre ou peu coûteux en .com. Certaines fonctionnalités/modules n'avaient pas encore été portés de la version locale vers Veliam, mais nous avons décidé de sortir avec les fonctionnalités actuelles et de compléter le reste par des mises à jour. Dans la toute première version, il n'y avait pas de HelpDesk, de Veliam Connector, il n'était pas possible de modifier les seuils de déclenchement des notifications, et bien d'autres choses. Nous avons acheté un Code Sign Certificate, signé les parties client et serveur. Nous avons créé un site pour le produit, commencé les procédures d'enregistrement du logiciel, de la marque, etc. En gros, nous étions prêts à commencer. Une légère euphorie provenant du travail accompli et de la possibilité que quelqu'un utilise notre produit, même si nous n'en avions pas de doutes. Et là, stop. Un partenaire a dit qu'il était impossible de sortir sur le marché sans notifications dans les messageries. On pouvait se passer de beaucoup d'autres choses, mais pas de ça. Après de brèves discussions, nous avons ajouté une intégration avec Telegram, ce qui nous allait. Parmi tous les messagers disponibles, c'est le seul qui offre l'accès à son API gratuitement et sans procédures de validation compliquées. WhatsApp, quant à lui, demande de passer par des fournisseurs qui facturent des sommes importantes pour utiliser leurs services, toutes les demandes d'accès sans intermédiation ont été ignorées. Quant à Viber... je ne sais pas qui l'utilise encore, car le spam et la publicité y sont omniprésents. Fin décembre, après plusieurs tests internes et parmi des amis, nous avons ouvert l'inscription à tous et mis le logiciel en téléchargement.
Début de la distribution
Depuis le tout début, nous avons compris qu'il nous fallait un petit flux d'utilisateurs du système pour qu'ils testent le produit en conditions réelles et nous donnent un premier retour. Quelques publications achetées sur VK ont porté leurs fruits. Les premières inscriptions ont commencé à arriver.
Il faut dire qu'entrer sur le marché sans avoir un nom célèbre pour sa société, tout en fournissant une fonctionnalité de surveillance sans agent, où il faut entrer des identifiants de ses serveurs et postes de travail, est très difficile. Cela effraie beaucoup de gens. Nous avons compris dès le début que cela poserait des problèmes et nous étions prêts à y faire face, tant techniquement que moralement. Toutes les connexions à distance, bien que RDP et SSH soient chiffrés par défaut, sont chiffrées à nouveau par notre logiciel selon la norme AES. Toutes les données des serveurs locaux sont transmises dans le cloud via HTTPS. Les identifiants sont stockés sous forme chiffrée. Les clés de chiffrement pour tous les sous-systèmes de tous les clients sont individuelles. Pour les connexions à distance, des clés de chiffrement de session sont également utilisées.
Tout ce que nous pouvons faire dans cette situation pour rassurer les gens, c'est d'être aussi transparents que possible, de travailler sur la sécurité et de ne pas nous fatiguer à répondre aux questions qui les préoccupent.
Pour beaucoup, la commodité et la fonctionnalité du logiciel l'emportent sur la peur, et ils s'inscrivent. Certaines personnes ont écrit dans des publications sur VK que ce logiciel ne devrait pas être utilisé car c'est un collecteur de leurs mots de passe et que c'est une entreprise inconnue. Il convient de noter que cet avis n'était pas isolé. Beaucoup ne comprennent tout simplement pas que lorsqu'ils installent un autre logiciel propriétaire sur leur serveur, qui fonctionne comme un service, il a également des droits complets dans le système et ils n'ont pas besoin de comptes pour faire quoi que ce soit d'illégal (bien sûr, il est possible de changer l'utilisateur à partir duquel le service est lancé, mais ici aussi, n'importe quel compte peut être entré). En réalité, les inquiétudes des gens sont compréhensibles. Installer un logiciel sur un serveur est une pratique courante, mais entrer un identifiant de compte est déjà un peu effrayant et intime, car beaucoup de gens ont un seul mot de passe pour tous les services, et il est paresseux de créer un identifiant distinct même pour un test. Mais à l'heure actuelle, il existe une énorme quantité de services auxquels les gens confient non seulement leurs identifiants, mais bien plus encore. Et nous aspirons à devenir l'un d'eux.
De nombreux commentaires étaient du genre que nous avions volé cela quelque part. Cela nous a légèrement surpris. Bon, l'opinion d'une seule personne, mais de tels commentaires étaient présents dans diverses publications de différentes personnes. Nous ne savions pas d'abord comment réagir à cela. Fallait-il être triste de constater que certaines personnes pensent qu'en Russie, personne ne peut rien faire soi-même, mais qu'il ne peut que voler, ou fallait-il se réjouir qu'ils pensent qu'il n'est possible de voler que ce qui est précieux ?
Nous venons de terminer la procédure d'obtention du certificat de signature de code EV. Pour l'obtenir, il est nécessaire de passer une série de vérifications et d'envoyer une multitude de documents sur l'entreprise, dont certains doivent être notariés. Obtenir un certificat de signature de code EV dans le contexte de la pandémie est en fait un sujet à part entière pour un article. La procédure a duré un mois. Et ce mois n'était pas consacré à l'attente, mais à des demandes constantes de documents supplémentaires. Peut-être que la pandémie n'y est pour rien et que tout le monde a eu une procédure aussi longue ? Partagez votre expérience.
Certains disent qu'ils ne vont pas l'utiliser parce qu'il n'y a pas de certificat FSTEK. Nous devons expliquer que nous ne pouvons pas l'obtenir et que nous ne le ferons pas parce que pour obtenir ce certificat, le chiffrement doit être conforme aux normes GOST, tandis que nous prévoyons de distribuer le logiciel non seulement en Russie et utilisons AES.
Tous ces commentaires suscitaient une certaine incertitude quant à la possibilité de promouvoir un produit nécessitant la création de comptes sans être connu du public. Même si nous savions qu'il y aurait ceux qui seraient très négatifs à ce sujet. Après que le nombre d'inscriptions a dépassé les mille, nous avons cessé d'y penser. Surtout après qu'en plus des critiques négatives de ceux qui n'avaient même pas essayé le produit, sont apparus des avis très positifs. Il faut dire que ces avis positifs sont le plus grand motivateur pour le développement du produit.
Ajout de la fonctionnalité d'accès à distance pour les employés
Une des demandes fréquentes des clients est « faites en sorte que Vania puisse accéder à son ordinateur depuis chez lui ». Nous avons mis en place un VPN sur MikroTik et créé des comptes pour les utilisateurs. Mais c'est vraiment un problème. Les utilisateurs ne sont pas capables de suivre le manuel et de le faire pas à pas pour se connecter via le VPN. Il y a différentes versions de Windows. Sur une version, tout se connecte bien, tandis que sur une autre, un autre protocole est nécessaire. En général, cela a toujours été lié à la reconfiguration du matériel réseau qui servait de serveur VPN, et tous les employés n'ont pas accès à celui-ci, ce qui était inconfortable.
Mais nous avons déjà des connexions distantes aux serveurs et à l'équipement réseau. Pourquoi ne pas utiliser un transport prêt à l'emploi et créer un utilitaire de petite taille, que l'on peut simplement donner à l'utilisateur pour la connexion. Il fallait juste faire en sorte que l'utilisateur n'ait rien à saisir de compliqué. Juste un bouton « se connecter ». Mais comment cet utilitaire saura où se connecter s'il n'y a qu'un seul bouton ? L'idée était de construire en ligne l'application nécessaire sur nos serveurs. L'administrateur système appuie sur le bouton « télécharger le raccourci », et une commande est envoyée vers notre cloud pour construire un binaire individuel avec des informations intégrées pour se connecter au serveur / ordinateur requis par RDP. En général, cela aurait pu être fait. Mais c'est long, l'administrateur devrait d'abord attendre que le binaire soit compilé, puis qu'il soit téléchargé. On aurait bien sûr pu ajouter simplement un deuxième fichier de configuration, mais cela fait déjà deux fichiers, et pour simplifier, l'utilisateur a besoin d'un seul. Un fichier, un bouton et aucun installateur. Après avoir un peu exploré les vastes horizons de Google, je suis arrivé à la conclusion que si l'on ajoute des informations à la fin d’un « .exe » compilé, cela ne se dégrade pas (enfin presque). On peut ajouter même Guerre et Paix, et cela continuera de fonctionner comme avant. C'est un péché de ne pas en profiter. Maintenant, on peut simplement décompresser l'application sur le vif directement dans le client, d'ailleurs cela s'appelle Veliam Connector, et simplement ajouter à la fin les informations nécessaires pour la connexion. Et l'application elle-même sait quoi en faire. Pourquoi ai-je écrit plus haut entre parenthèses « enfin presque » ? Parce qu'il faut payer ce confort par le fait que l'application perd sa signature de signature électronique. Mais à ce stade, nous considérons que c'est un petit prix à payer pour un tel confort.
Licences de modules tiers
J'ai déjà mentionné ci-dessus qu'après avoir décidé de rendre le produit accessible au public plutôt que de l'utiliser uniquement pour nos propres besoins, il a fallu travailler dur et rechercher des remplacements pour certains modules qui ne nous permettaient pas d'inclure notre produit. Cependant, après la sortie, nous avons découvert par accident une chose assez désagréable. Dans Veliam Server, qui était du côté client, se trouvait la base de données MariaDB. Et elle est sous licence GPL. La licence GPL exige que le logiciel soit open source, et si notre produit comprend MariaDB qui a cette licence, alors notre produit doit également être sous cette licence. Mais heureusement, le but de cette licence est d'assurer le code source ouvert, et non de punir en justice ceux qui se sont trompés par inadvertance. Si le titulaire des droits a une réclamation, il doit en informer par écrit l'infracteur, qui doit remédier à la violation dans les 30 jours. Nous avons découvert notre erreur nous-mêmes et nous n'avons pas reçu de lettres, nous avons donc immédiatement commencé à envisager des solutions pour résoudre le problème. La solution était évidente : passer à SQLite. Cette base de données n’a aucune restriction de licence. La plupart des navigateurs modernes utilisent SQLite, ainsi qu'une multitude d'autres programmes. J'ai trouvé sur Internet que SQLite est considérée comme la base de données la plus répandue au monde, justement à cause des navigateurs, mais je n’ai pas vérifié les preuves, donc c'est une information inexacte. J'ai commencé à étudier les conséquences du passage à SQLite.
Cela devient déjà une tâche non triviale lorsque plusieurs centaines de serveurs installés chez des clients utilisent MariaDB et contiennent des données. Certaines fonctionnalités de MariaDB ne sont pas disponibles dans SQLite. Par exemple, dans le code, nous avons utilisé des requêtes de type
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Cette construction effectue non seulement une sélection dans la table, mais bloque également les lignes de données. Et quelques autres constructions ont également dû être réécrites. Mais en plus du fait qu'il a fallu réécrire de nombreuses requêtes, il a également fallu inventer un mécanisme qui, lors de la mise à jour de Veliam Server pour le client, portera toutes les données dans la nouvelle base de données et supprimera l'ancienne. De plus, les transactions ne fonctionnaient pas dans SQLite, ce qui constituait un véritable problème. Mais après avoir exploré les vastes horizons du web, j'ai facilement découvert que les transactions dans SQLite peuvent être activées en passant une simple commande lors de la connexion.
PRAGMA journal_mode=WAL;En fin de compte, la tâche est accomplie et maintenant la partie serveur pour les clients fonctionne sur SQLite. Nous n'avons remarqué aucun changement dans le fonctionnement du système.
Nouveau HelpDesk
Il était nécessaire de porter le système HelpDesk de la version interne vers la version SaaS, mais avec quelques modifications. La première chose que nous souhaitions faire était l'intégration avec le domaine du client concernant l'authentification transparente des utilisateurs dans le système. Maintenant, pour accéder à HelpDesk et soumettre une demande, l'utilisateur n'a qu'à cliquer sur le raccourci sur le bureau et le navigateur s'ouvre. L'utilisateur n'entre aucune donnée d'identification. Le module pour Apache SSPI, inclus dans Veliam Server, authentifie automatiquement l'utilisateur avec le compte de domaine. Pour soumettre une demande dans le système lorsque l'utilisateur se trouve en dehors du réseau d'entreprise, il clique sur un bouton et reçoit par e-mail un lien lui permettant de se connecter à HelpDesk sans mot de passe. Si un utilisateur est désactivé ou supprimé dans le domaine, son compte dans HelpDesk cessera également de fonctionner. Ainsi, l'administrateur système n'a pas besoin de suivre manuellement les comptes à la fois dans le domaine et dans HelpDesk. Si un employé est licencié, il désactive le compte dans le domaine et c'est tout, il ne pourra pas accéder au système ni depuis le réseau d'entreprise ni via le lien. Pour que cette intégration fonctionne, l'administrateur système doit créer une GPO qui et .
Deuxièmement, ce que nous considérons comme absolument nécessaire pour les systèmes HelpDesk, en tout cas pour nous-mêmes, c'est la connexion au demandeur directement depuis la demande en un clic. De plus, les connexions doivent fonctionner même si l'administrateur système se trouve dans un autre réseau. Pour l'externalisation, c'est indispensable, et pour les administrateurs systèmes internes, c'est souvent également très nécessaire. Il existe déjà plusieurs produits qui remplissent parfaitement la tâche des connexions à distance. Et nous avons décidé de créer des intégrations pour eux. Actuellement, nous avons réalisé une intégration pour VNC, et à l'avenir, nous prévoyons d'ajouter Radmin et TeamViewer. En utilisant notre transport réseau pour les connexions à distance à l'infrastructure, nous avons fait en sorte que VNC se connecte aux postes de travail distants derrière un NAT. Il en sera de même avec Radmin. Pour se connecter à un utilisateur, il suffit actuellement de cliquer sur le bouton "se connecter au demandeur" dans la demande. Le client VNC s'ouvre et se connecte au demandeur, peu importe si vous êtes dans le même réseau ou si vous êtes chez vous en pantoufles. Au préalable, l'administrateur système doit installer le serveur VNC sur tous les postes de travail à l'aide des GPO.
Nous sommes actuellement en train de passer à un nouveau HelpDesk et d'utiliser l'intégration avec le domaine et VNC. C'est très pratique pour nous. Nous n'avons plus besoin de payer pour TeamViewer, que nous avons utilisé pendant plus de trois ans pour faire fonctionner notre service d'assistance.
Que prévoyons-nous de faire ensuite
Lorsque nous avons lancé notre produit, nous n'avons proposé aucun tarif payant et avons simplement limité le tarif gratuit à 50 objets de surveillance. Cinquante appareils réseau et serveurs devraient suffire à tout le monde, avons-nous pensé. Puis les demandes d'augmentation de limite ont commencé à arriver. Dire que nous étions un peu choqués est peu dire. Est-ce que notre logiciel intéressait vraiment des entreprises avec autant de serveurs ? Nous avons élargi gratuitement la limite pour ceux qui faisaient de telles demandes. Pour certains, nous avons demandé en réponse à leur demande pourquoi ils en avaient besoin, ont-ils vraiment autant de serveurs et d'équipements réseau ? Et il s'est avéré que les administrateurs système avaient commencé à utiliser le système d'une manière que nous ne avions pas du tout prévue. Tout était simple — ils ont commencé à surveiller non seulement des serveurs, mais également des stations de travail avec notre logiciel. D'où de nombreuses demandes d'augmentation des limites. Maintenant, nous avons déjà introduit des tarifs payants et les limites peuvent être étendues de manière autonome.
Les serveurs fonctionnent presque toujours soit avec des systèmes de stockage, soit avec des disques locaux dans un ensemble RAID. Nous avons donc initialement conçu le produit pour eux. La surveillance SMART n'était pas pertinente pour cette tâche. Cependant, compte tenu du fait que les gens ont adapté le logiciel pour surveiller des stations de travail, des demandes de mise en œuvre de la surveillance SMART ont émergé. Nous la mettrons en œuvre bientôt.
Avec l'arrivée de Veliam Connector, le déploiement d'un serveur VPN dans le réseau d'entreprise, la création d'un RDGW, ou simplement le transfert de ports vers les machines nécessaires pour se connecter via RDP est devenu inutile. Beaucoup utilisent notre système uniquement pour ces connexions distantes. Veliam Connector est uniquement disponible sous Windows, et certains utilisateurs d'entreprises se connectent depuis leurs ordinateurs portables personnels sous MacOS à des stations de travail ou des terminaux dans le réseau d'entreprise. Ainsi, l'administrateur système est contraint, en raison de quelques utilisateurs, de revenir à la question des redirections ou du VPN. C'est pourquoi nous sommes déjà en train de finaliser une version de Veliam Connector pour MacOS. Les utilisateurs de leur précieuse technologie Apple auront également la possibilité de se connecter à l'infrastructure d'entreprise en un clic.
J'apprécie particulièrement le fait qu'avec un grand nombre d'utilisateurs du système, il n'est pas nécessaire de se creuser la tête pour comprendre ce dont les gens ont besoin et ce qui serait le plus pratique. Ils expriment eux-mêmes leurs souhaits, donc il y a beaucoup de projets de développement pour le proche avenir.
Parallèlement, nous prévoyons de commencer la traduction du système en anglais et sa diffusion à l'étranger. Nous ne savons pas encore comment nous allons distribuer le produit en dehors de notre pays, nous recherchons des options. Peut-être qu'il y aura un article séparé à ce sujet plus tard. Peut-être que quelqu'un parmi ceux qui ont lu cet article pourra nous donner des orientations, ou même connaît et sait comment faire cela et proposera ses services. Nous vous serions reconnaissants pour toute aide.
Source : habr.com
