Projet – Passerelle VEEAMOne/ITOP

Bien, ça fait un petit moment que j’avais ça en réserve et que je me devais de vous présenter ce petit projet. Cela m’a demandé du temps. Pourquoi vous demandez vous ?

Excellente question à toi qui vient d’aborder la lecture de ce billet. La réponse est simple et s’articule en deux points. Laissez-moi donc les énumérer :

• J’attendais impatiemment la sortie communautaire LTS¹ ITOP 3.2.X en lieu et place de la version 2.7.X (entre nous ITOP c’est fait une sacrée beauté <3)
• J’avais une flemme monstrueuse de remonter un ITOP from scratch, sur un environnement durci et configurer ce dernier pour « mon organisation »

Bref, malgré un emploi du temps le jour bien remplie. Me voilà repris d’insomnie et de doutes qu’il faut ma foi bien occuper.

Sinon, tu te la joues BOOMER qui raconte sa LIFE sur Facebook ? Tu vas nous parler de ton projet et de tes travaux ? #RIENAFOUTRE

Promis, j’arrête pour au moins deux paragraphes… Je suis parti d’une problématique professionnelle (qui n’intéresse malheureusement que moi et non certains de mes pairs…), comment s’assurer des états de notre outils de supervision (monitoring) et du bon traitement des alarmes avertissements ou erreurs remontées sur notre SI² ?

Une première approche est de prendre un ETP³ compétent et qui ne coute pas trop à la société, de le scotcher à une chaise devant la solution de monitoring et de l’autoriser à dormir que lorsque tout est au vert fixe !

Cette première méthode est loin de plaire à nos amis syndicalistes, partisans du code du travail et certains RH.

Il y a donc une seconde approche, celle où les éditeurs de solution de surveillance des SIs partent du postulat que les alertes sont envoyées par courriel (hé oui je n’ai pas écrit e-mail). Mais là encore, c’est compliqué de ne pas se noyer dans la volumétrie des mails et de ne pas passer à côté d’un événement important. Point positif, nous pouvons mettre plusieurs personnes/collaborateurs derrière une BAL⁴. Quoi que cela demande de la communication (et la communication dans une entreprise n’est pas une compétence acquise de tous. Un peu comme la politesse…).

Et enfin, il y a la troisième approche. Qui arrive timidement par certains éditeurs de solution de supervision qui propose d’interfacer leurs plateformes avec une solution de ticketing (souvent ITSM⁵). Là autant vous dire que je fais un gros cœur avec les mains devant mon écran. C’est ainsi que dans un article précédent traitant de VEEAMOne (je n’ai toujours pas d’action qu’on se le dise), VEEAMOne propose une connexion à la solution de ticketing ServiceNow. Franchement c’est super, il n’y a rien à faire sauf sortir le chéquier, changer de solution de ticketing si nous en avions déjà un, lancer des projets de migration… Bref ça me pose un problème car ce n’est pas l’outil que j’utilise pour la gestion de mes tickets.

Là, encore une fois nous avons deux possibilités :

• Notre solution ITSM peut créer des tickets sur réception de notification mail. Soit de manière plus concrète avec un peu de paramétrage, nous allons faire créer une requête lors de la réception d’un email d’alerte ou d’avertissement. (Perso, je ne suis pas fan de cette méthode).
• Nous utilisons les APIs des deux solutions et nous développons une petite passerelle 🙂 (Perso j’aime d’avantage).

Toutefois et comme c’est la solution que je vais présenter il est important de comprendre avant d’aller plus loin qu’il y a des avantages et beaucoup de contraintes à développer une passerelle (entre nous, nous l’appellerons GW⁶ parce que c’est un mot qui me soule à écrire. Hé oui au ch***e la loi Toubon ! Mais que de grossièreté !).

Avantages	Inconvénients
Langages libres Découvertes techniques Satisfaire l’appétence techniques	Avoir une documentation sur les deux APIs MCO du code lors des montées de version Bien penser son code Penser générique

Nous remarquerons l’acquisition des compétences et maitrise de l’application PAINT. Oui, j’ai un doctorat en PAINT appliqué !

Prérequis

• SE : Windows Server 2k19 et version ultérieures
• Apps : VEEAMOne 12.x, ITOP 3.2.X
• Autres :
  • PowerShell version 5 et ultérieures

Avant-Propos

Comme d’habitude, je vais proposer ci-dessous un usage sécuriser de l’outil. Je n’ai pas la prétention toutefois de garantir un haut niveau de sécurité dans le code (ça fait longtemps et je suis un peu rouillé dans ce domaine).

J’annonce en amont que le code source ne sera pas accessible sur le GitHub en libre accès. Ah ouai et pourquoi donc ?

Je suis plutôt content de ce que j’ai créé. Toutefois, je ne suis pas satisfait de la qualité du code et de certaines méthodes que j’ai pu développer. Je pense qu’un grand pas a été fait mais que cette aventure nécessite d’être porté par et avec d’autres personnes et ceux afin de proposer ce projet comme quelques choses d’abouti et de communautaire. Mais voyez vous, je ne suis plus dev et je rentre sur un terrain et domaine ou le jugement est facile, faire un peu moins.

C’est pourquoi, si vous êtes intéressé par ce projet, je suis à votre disposition pour échanger et collaborer sur ça factorisation et évolution.

Je vous rassure toutefois, je vais aller assez loin dans mes choix et dans la logique dont j’ai construit cette GW. Sinon à quoi bon faire un article sur le sujet si ce n’est que pour satisfaire une petit plaisir solitaire issue du fruit d’une masturbation intellectuelle ?

Théorie

Je tiens à garder un format à peu près standard pour chacun de mes articles. Dans ce cas précis, nous considérons cette partie plus comme un cahier des charges et expressions des besoins. Naturellement, nous apporterons des réponses et solutions ce qui n’est donc pas tout à fait juste un cahier des charges.

(Mais qu’est-ce qu’il peut être torturé ce garçon… Oui mais non ce n’est pas ça, mais ça tout de même. Quelqu’un veut-il prendre l’initiative de lui mettre un coup de pelle derrière les oreilles pour qu’il aille à l’essentiel ?)

Expression du besoin

Bien, nous avons tous à ce jour des infrastructures virtualisées en local (onpremise) ou dans le cloud (privé ou public). En tant que fournisseur de service (Service Provider), je suis contraint de réaliser l’exploitation de l’ensemble de mon infrastructure hébergé chaque jour pour l’ensemble de nos clients. Toutefois, mon périmètre est restreint aux services et infrastructures permettant d’assurer le bon fonctionnement des environnements constituant notre infrastructure.

Comment s’assurer que les serveurs clients ont bien leurs MCO⁷ d’effectuer par les équipes opérationnelles ? Comment s’assurer que le responsable informatique effectue bien son MCO ?

Il est facile et malheureusement (je l’ai constaté) il est facile de cacher des dysfonctionnements d’exploitations aux yeux de l’entreprise et de ces dirigeants. Un peu comme il est facile de cacher des cadavres dans les placards quand il n’y a plus de place sous le tapis.

Possédant une solution ITSM/CMDB⁸, j’ai nommé ITOP (là non plus je n’ai pas d’action), pourquoi ne pas faire remonter les éléments de notre supervision VEEAMOne dans ce dernier.

Cela permettrait de s’assurer d’être pro actif lors d’un potentiel dysfonctionnement d’exploitation (espace disque, consommation élevée de CPU, RAM etc.) et dans les cas les plus complexe de garder une trace du traitement et donc nourrir la base de connaissance de notre service IT ?

Il sera donc utile de définir un cycle de vie.

Cahier des Charges

Afin de répondre aux besoins, je prends le parti de ne pas développer de module directement côté ITOP, ni côté VEEAMOne.

Pourquoi ? ITOP n’est pas pour moi une solution que je maitrise à 100% et cela demande des compétences WEB (HTML/CSS/PHP/JS et autres frameworks) que je ne possède pas. Côté VEEAMOne l’application n’est pas « ouverte ». Toutefois la solution que je souhaite proposer tend à une intégration côté VEEAMOne. Finalement, une fois que le code a été pondu une fois, il suffit de le traduire et l’adapter dans un autre langage.

J’ai choisi d’utiliser en langage le framework .NET Powershell (version 5 et plus) afin d’exécuter les opérations sur un un environnement Windows.

Le script sera utilisé sur un serveur Windows indépendant des deux solutions applicatives.

Dans un premier temps, le script sera utilisé de manière quotidienne une seule fois à 09h00. Aucun module d’exception sera implémenté car rien ne justifie de ne pas faire remonter les alertes. Lors de la présence d’une alerte dans la console de supervision, une alerte sera créée singulièrement avec pour contenu la dite alarme au format HTML 5.

Le demandeur du ticket sera un utilisateur identifié comme une service bot. Le ticket sera affecté au service IT compétent et identifié.

Topographie – Infrastructure

L’infrastructure réseau est plutôt simple. Il suffira de prendre les ports par défaut si ces derniers n’ont pas été modifiés (1239 pour accéder l’API WEB de VEEAMOne et 443 pour accéder à l’API d’ITOP). Dans le cas contraire, il faudra chercher un dans les paramètres pour trouver l’information.

Dans l’idée, je souhaite tirer les informations et données du serveur VEEAMOne via le Serveur Tools et pousser les données vers le Serveur ITOP.

Topographie – Applicative

La logique de traitement a été identifié et pensé de la manière suivante (dans un premier temps car je pense perfectible la chose).

Nous admirons le schéma pour apprendre à compter jusqu’à 9 !

• 1 : Appel API pour l’ouverture de session de manière sécurisé et demande de récupération des données à collecter
• 2 : Autorisation de connexion et retour des données collectées ou non si absente
• 3 : Traitement des données brutes récupérées de VEEAMOne afin de faciliter la création des requêtes ITOP
• 4 : Appel API pour l’ouverture de session de manière NON sécurisée (pour l’instant) et demande de récupération des données nécessaires à la qualification des données à traiter
• 5 : Autorisation de connexion et retour des données demandées
• 6 : Création d’une requête via API avec les informations traitées/extraites de VEEAMOne et les informations ITOP.
• 7 : Retour de la requête API, si cette dernière retourne un code différent de 0 il faudra se plonger dans la documentation et dans le MCD⁹ d’ITOP.
• 8 : Appel d’un stimulus par appel API pour assigner la requête à une équipe et respecter le cycle de vie ITOP.
• 9 : Comme pour l’étape 7 il conviendra d’être vigilant à l’erreur retournée. Sans quoi, vous retourner avec ADJANI en case piscine.

Topographie – Logiciel

Le script sera pensé de la manière suivante. Une partie exécutable permettant de réaliser l’appel des différentes fonctions et l’import des modules comportant les fonctions statiques.

En résumer, nous avons un fichier .ps1 qui va servir d’exécutable et trois fichiers module powershell qui nous permettrons de réaliser distinctement les actions pour chacune des applications VEEAMOne et ITOP.

Tain le mec nous dit plus haut avec un air supérieur qu’il va nous apprendre à compter jusqu’à 9 et là il nous dit 3 fichiers pour 2 applications. Tu nous prendrais pas par hasard pour des raclures de bidets ?

C’est juste et c’est bien l’effet souhaité. Je me suis aperçu avec le temps que la génération de rapport en HTML pesait lourd dans les fonctions ou dans les modules et qu’il ne serait pas déconnant de dédier un module à la partie HTML. De plus un rapport nous pouvons considérer celui-ci comme immuable dans le temps. Donc il peut être qualifié comme module. 🙂 Soit en conclusion 2+1 = 3. Mais n’allons pas plus loin.

Et si nous regardions ce qu’il y a dans le ventre des 3 modules ? Oui mais gros malin, tu nous as dit que tu ne voulais pas partager ton code. Tu vas faire comment ? Hé bien dirons nous que cela revient à regarder un porno sur CANAL+ sans abonnement (époque que certains lecteurs ne connaitront jamais). On devine, mais personne n’en profite vraiment (où alors vous êtes des grands malades !).

Sécurité

La partie sécurité est un vrai enjeu. Je n’ai malheureusement pas implémenté dans cette version à ce moment (version 1.3) la redirection des sorties dans un fichier de log. J’ai gardé le mode debug, mais cela ne sera viable sur le long terme pour assurer un support adéquat.

Il en va de soi que nous avons besoin de 3 comptes en nous basant sur le principe de RBAC¹⁰.

• VEEAMOne : Un compte permettant d’accéder à l’application en API en pouvant réaliser des requêtes. Donc membre du GLS VEEAM ONE Administrator par chance, le serveur étant joint au domaine, il suffira de peupler le bon GGS. Néanmoins, ce compte doit être vu comme un compte de service. Donc à restreindre dans les règles de l’art pour empêcher toutes ouvertures de sessions
• ITOP : Le compte doit être protégé par un mot de passe robuste. Ce dernier doit avoir obligatoirement les profils Administrator et REST Services User. Ce compte devant accéder à l’ensemble des données cela justifie le profil Administrator.
• Compte de Service : Il va être nécessaire d’utiliser un compte de service pour exécuter notre tâche. Je préfère dans un premier temps passer par un compte utilisateur du domaine restreint plutôt que par un gMSA¹¹

Il faut également se poser la question du répertoire où va être stocké et appelé les scripts. Je ne préfère pas stocker ce dernier sur un partage réseau mais en local sur la partition système. Toutefois, je retire l’accès du groupe utilisateur et ajoute la lecture et exécution uniquement sur le GLS des comptes de services restreints.

Il en sera de même pour le répertoire _auth qui va contenir l’ensemble des éléments sécurisés d’accès aux ressources via CLIXML.

Je pense qu’avec toutes ces informations nous devrions être en capacité de réaliser le paramétrage nécessaire pour une implémentation.

Pratiques

L’implémentation se déroulera en quatre mouvements (comme une symphonie), c’est à dire le paramétrage des solutions et création des comptes, le paramétrage du script, la mise en place de la tâche planifiée et pour finir les tests de bon fonctionnement.

Paramétrages des solutions & création des accès

VEEAMOne

Pour l’application VEEAMOne, il n’y a pas grand chose à faire. Tout va se faire au niveau de la création d’un utilisateur dans notre Active Directory.

Bien, passons à ITOP.

ITOP

Contrairement à VEEAMOne, il va falloir réaliser un certain nombre de modification sur notre ITOP.

La création d’un ticket nécessite plusieurs champs :

• Le client
• Un demandeur
• L’origine
• Le titre
• Le corps
• Le service
• Type de Requête
• L’impact
• L’urgence
• La priorité
• L’Equipe de contact

Nous allons avoir besoin de nous assurer de la bonne existence des champs ci-haut en vert. Dans le cas contraire, il faudra créer ces derniers.

Paramétrage du script

Encore une fois, pourquoi nous narguer avec ton script si tu nous en donnes pas l’accès ? Tu connais l’histoire de Marie-Antoinette ?

Je le redis, ma décision de ne pas lever le voile maintenant n’est pas définitive et je préfère anticiper lorsque celui-ci deviendrait accessible de tous. Toutefois avec les éléments déjà communiqués il est aisé de faire du reverse engineering.

Certaines variables sont donc à définir. Il serait plus aisé de créer un fichier xml (pour les jeunes dinosaures comme moi à défaut d’un fichier ini pour les vieux dinosaures) ou d’un fichier json (pour la nouvelle génération) pour gérer la configuration de l’outil. M’enfin, je ne suis que sur une version 1.3 et je dois monter en compétence dans certain domaine. Le temps étant toujours l’éternel problème…

Applicable pour la version 1.3

Sécurité

Deux aspects sont à considérer sur ce point. Je ne traiterai pas de la partie gMSA car cela fera le biais d’un autre billet.

• Qui peut accéder au répertoire scripts ?
• Qui peut accéder au fichier permettant l’authentification ?

A ces deux questions, je répondrai uniquement les utilisateurs administrateurs du domaines et local de notre serveur en contrôle total ainsi que le groupe de services en lecture exécutions et écritures uniquement sur le répertoire _auth. Oui sinon comment exporter le fichier xml ?

Ainsi, nous passerions des droits suivants :

Avant	Après

Taches Planifiées

Pour la tache planifiée, rien de plus simple il suffit de suivre le vieux Raffiki (ou Riquiqui mais à trop le suivre celui là on peut terminer mal mon copaing), il connait le chemin.

Néanmoins, j’ai buté et bute encore sur un os. Je vous ai cassé les pieds avec le CLIXML pour sécuriser l’authentification ? Et bien cela se retourne contre moi… Mais pourquoi donc ?

Le principe du chiffrement via CLIXML repose sur l’usage d’une SecureString au sens .NET du terme. Pour assurer ce chiffrement, le système utilise l’information de la session utilisateur ainsi que du SE. Or pour déchiffrer l’information il faut donc que les conditions de chiffrement soient présente (évident Capt’ain Obivous).

Chiffrement	Déchiffrement

Sauf que dans notre contexte et avec les moyens mise en œuvre pour sécuriser le compte de service nous nous retrouvons avec un usage batard… Effectivement, même si la tache planifiée utilise le bon compte, cette dernière est planifié dans une autre session. Ce qui nous retourne une erreur « bête » de déchiffrement… (POWNED mon gars).

Paradoxalement, si nous appelons le script en dehors de la tâche planifiée, ce dernier fonctionne sans problème. J’ai déjà des idées et piste pour prendre pleine possession du sujet. Il faut contacter MARSHAL 🙂

M’enfin comme dirait Gaston LAGAFFE, je pose tout de même les paramètres de la tâche planifiée ici.

En truandant la chose (comprendre en insérant le password en dur et en clair), c’est ok.

Tests et Debug

Nous n’allons pas nous mentir, une petite fonction ou menu de debug ne serait pas du luxe. Je me le note c’est promis. (T’ain, il y a du pain sur la planche d’ici Noël…).

Allons jeter un œil du côté de chez Swann euh de notre ITOP pardon dans la vue des tickets en cours. Oui j’ai aussi du travail sur mon infra @home. 🙂 Mais cela nous montre l’intérêt de la solution ?

Et si nous regardons une requête plus en détail ?

Nous retrouvons la valeur des attributs renseignés précédemment dans notre appel API. Le ticket est bien assigné à notre organisation 00-RONELAB, le demandeur est le Service VEEAMONE. La requête est dans l’état Assignée à une équipe Equipe Interne depuis l’origine Supervision. La catégorie de Service est SE etc. Nous retrouvons également dans le corps de notre requête l’ensemble des informations contextuelles dans la première et seconde ligne puis le détail de l’erreur dans la troisième ligne.

Oui mais si ça ne fonctionne pas, tu debugs comment ?

Pour le coup, il nous suffira de lire les retours des calls API d’ITOP. Si c’est 0 tu exaltes de joie si c’est 100 tu lis gentiment le message d’insultes et tu corriges. Dans la grande majorité des cas les erreurs résultent d’une modification côté ITOP d’une valeur attendue ou d’une valeur manquante.

Je vous glisse un exemple ci-dessous du script en mode debug sur la création d’une requête à la suite d’une alarme VEEAMOne.

Dans le bloc jaune, nous avons la création du ticket. Nous voyons clairement le retour code=0 nous informant que l’opération de création c’est bien passé. Notre ticket est donc dans l’état « Nouveau ». Dans le bloc rouge qui gère l’assignation de notre requête (pour respecter le cycle de vie) nous constatons que nous avons une erreur qui est retourné lors de notre appel API, présence d’une insulte et d’un code=100. Etrangement, la requête échoue mais le ticket est bien assigné. Au vu du message, la requête est incomplète ou doit comporter une erreur de syntaxe. A creuser… 🙂

Conclusion

La supervision comme nous le savons déjà offre une bonne vision de l’état de santé de notre système d’information. Cependant, il résulte lors d’incidents ou de dysfonctionnements légers d’exploitation un manque de suivi quant à leur résolution. Certes, un dysfonctionnement d’espace disque sur une VM¹² n’apporte pas d’information technique quant à sa résolution. A l’inverse, un dysfonctionnement de synchronisation DRS¹³ qui nécessite de toucher au service vpxuser nécessite de nourrir la base de connaissance et de garder une trace dans la solution ITSM.

Vous êtes efficaces ? Soyons efficients ! L’avantage d’une passerelle applicative permet de se focaliser sur un point d’entrée unique et donc d’être réactif. Attention cela ne veut pas dire qu’il ne faut pas regarder les autres consoles.

Il sera également intéressant de mesurer la volumétrie de requête créé et de se poser la question sur la stabilité ou non du SI et d’engager ou non un plan correctif sur l’infrastructure ou sur imaginons dans un certains cas son remplacement ou son renforcement.

Sur le plan service, cette méthode permettrait également de faire grandir les équipes opérationnelles quant aux traitements des différentes alarmes remontées.

D’un point de vu personnel, je souffre de cette frustration de vouloir bien faire sans atteindre pleinement mon but. Le code ne sera jamais assez bien pour moi. Il reste à améliorer, factoriser, sécuriser. C’est un métier, un métier que je n’ai pas su faire le mien à l’époque et maintenant (d’un autre côté du cherche aussi, développer en Notepad++ et en Powershell ISE aussi…). La frustration sur le CLIXML me laisse un gout amer. Néanmoins, pourquoi mentir et dire que tout va bien et que cela fonctionne alors que ce n’est pas le cas ? C’est également l’objectif de ce site parler de ce qui fonctionne et de ce qui ne fonctionne pas ou pas comme il devrait.

Il serait également facile de me reprocher sur ce petit projet de ne pas avoir émis la possibilité de traiter directement les flux de mails directement dans ITOP. Mais la tâche devient tout de suite plus titanesque. Comment gérer la remédiation dans le cas d’une variation d’alarme ? Je laisse ça a d’autre, il y a des APIs il faut les utiliser. La génération de ticket sur un flux de messagerie entrant doit selon moi être définie dans un cas d’usage précis et n’est pas adapté à un usage de monitoring, supervision.

Bref, à voir si certaines personnes seraient intéressés d’échanger sur le sujet et de faire grandir ce petit projet. A savoir que je ne baisserai pas les bras car SPOILER ALERTE, j’ai déjà développé les GWs :

• VEEAM B&R <-> ITOP
• VSPC <-> ITOP

Oui M’sieurs, Dames ! Et je vais faire les mêmes articles mais avec les corrections !

Bonjour, je viens pour la clim ! Mon papa m’a toujours dit de ne pas accepter les call APIs des inconnus… C’est que j’ai eu un CRUD sur toi, tu aimes les films de gladiateur ?

Erwan GUILLEMARD

Sources

• ServiceNow
• VEEAMOne
• ITOP by COMBODO

1. LTS : Long Time Support ↩︎
2. SI : Système d’Information ↩︎
3. ETP : Equivalent Temps Plein ↩︎
4. BAL : Boites Aux Lettres ↩︎
5. ITSM : Information Technology Service Management ↩︎
6. GW : GateWay ou Passerelle ↩︎
7. MCO : Maintien en Condition Opérationel ↩︎
8. CMDB : Configuration Management Database ↩︎
9. MCD : Modèle Conceptuel des Données ↩︎
10. RBAC : Role Based Access Control ↩︎
11. gMSA : GroupManaged Service Account ↩︎
12. VM : Virtual Machine ↩︎
13. DRS : Distributed Ressources Scheduler ↩︎