Après 3 mois d’absence et de retrait vis à vis du dernier article, j’ai pris la décision de faire une pause. Des contextes complexes m’ont menés à devenir un homme fatigué, à deux doigts du break. Mais ne nous attardons pas sur ce point si petit soit il mais sans le négliger non plus.

Bref, en parallèle du projet précédent Green Ray, dans ma fièvre créative j’ai conçu sur la même période une autre application. J’ai toujours à l’esprit cette même pudeur de présenter mes travaux, vis à vis des solutions déjà présente sur le marché ou des regards critiques de mes pairs.

J’ai rêvé depuis des nombreuses années d’une solution qui permettrai de suivre dans le temps l’évolution d’un SI en terme de ressource dans un environnement virtualisé VMWare. Je sais encore une fois que ce rêve n’est que la prolongation de la vision de mon prédécesseur. Ce dernier avait pensé et développé un tableau de bord dans un tableur pour définir le seuil de consommation d’un environnement clustérisé VMWare et de définir la charge critique des ressources dans un fonctionnement normal et dégradé. Il avait également poussé le curseur jusqu’à dissocier les grandes familles des ressources virtuelles.

La vie d’une entreprise vous connaissez ? Ca s’en va et ca revient (ou pas…). Vous comprenez qu’il a quitté l’entreprise, emportant avec lui la solution qu’il avait développé sur son temps personnel.

Je me suis donc inspiré de ces réflexions et ai poussé plus loin le curseur jusqu’aux serveurs virtuelles, datastores etc. De ce contexte est né SS_043 ou Dream Nebula, concrétisant l’accomplissement d’un projet de 3 ans. Mon application vient répondre à la problématique.

Comment garantir le capacity planning d’un système d’information virtualisé sous VMWare dans son fonctionnement normal et dégradé dans le temps tout en garantissant une vision la plus précise de chaque type d’environnement ainsi qu’une synthèse des bulles métiers ou clients à des fins de facilitation de refacturation interne ou externe des ressources consommées.

Encore une bien vaste problématique qui pourrait faire le sujet d’une fin de cycle de cinquième année. 🙂

Les premières versions pour répondre aux attentes se basait sur les RVTools et les données qui en étaient retournées. Ainsi il m’était donc facile de marcher dans les pas de mon prédécesseurs et d’integrer et manipuler les données dans un tableau xlsxm.

XLSXM tien donc ?

Oui. Je rappel que je souhaite avoir une traçabilité dans le temps. Donc pas besoin de sortir de Saint-Cyr pour savoir que cela va se traiter par le biais de MACRO en VB. (Normalement avec juste les termes tableurs, MACRO et VB nous SACHONS que cela ne fonctionnera pas dans le temps en terme de maintient de la solution). Et bien spoiler, la première solution aura tenue un an et demi. A la fin cela ne ressemblait plus à grand chose et beaucoup d’options automatisées étaient faites manuellement.

Pourquoi ?

Il y a bien des raisons et je vais les expliquer :

• La mise à jour des composants VMWares (vSphere et vCenter) ajoute ou modifie l’ordre des colonnes. Donc il est nécessaire de réadapter l’ensemble des formules dans le tableur
• Les mises à jour du framework .NET et Windows rendent obsolètes certaines fonctionnalités au sein d’excel. Retour case développement dans les MACRO
• Certaines lignes sautent et donc cela décalent toutes les autres lignes

C’est à partir des points précédents que Dream Nebula ou SS_043 est né 🙂

Mon projet se base sur une technologie, VMWare et son usage des tags. Toutefois et à des fins d’efficience, je me base sur VEEAMOne pour l’attribution des tags VMWares. Je vous laisse si nécessaire vous référer à l’article déjà présent sur le sujet. J’insiste, l’usage de VEEAMOne est optionnel.

Avant-Propos

Attention, bis repetita en approche…

Il est important de comprendre que ce billet ne rentrera pas dans le détail technique et ce pour des raisons évidentes de savoir faire et de protection intellectuelle. Le code source est disponible sur GitHub mais ne sera pas en libre accès. Ah ouai et pourquoi donc ?

Comme j’ai pu le mentionner dans un article précédent je suis satisfait de ce que j’ai réussi à livrer et à créer. J’ai passé un bon nombre d’heure de recherche et de développement à concevoir la solution ainsi que la lecture des différentes documentations. Contrairement à d’autres projets je suis satisfait de la qualité du code produit et de l’architecture de ce dernier.

Ce qui m’amène au point, dois je commercialiser ce dernier ou le laisser à la disposition de tous ? Mon cœur peine à se décider… Je souhaite valoriser mon travail de recherche…

Bref, si votre curiosité est toujours suscitée je pense que le reste de l’article devrait être satisfaite. Dans le cas contraire, je vous laisse exécuter la combinaison Ctrl+F4.

Prérequis

• SE : Windows Server 2k19 et version ultérieures ou Windows 11
• Apps : VCSA version 7 ou plus
• Autres :
  • PowerShell version 5 et superieur
  • PowerBI (optionnel)
  • ODBC drivers (SQLite3)
  • VEEAMOne version 12 ou plus (optionnel)

Guide

• Partie 1 : Théorie
  • Définir l’expression du besoin et aborder le cahier des charges attendu. Ce qui implique l’architecture de l’application, du code. Les solutions retenues ainsi que les notions de sécurité
• Partie 2 : Pratique
  • Guide de déploiement de la solution et paramétrage de cette dernière.
  • Oups, un mot de passe ? On échange avant ? #bisous
• Partie 3 : Démonstration
  • Faire une présentation de la solution dans les différents modes qui ont été développés.

Conclusion

Le mot de la fin

Moi j’ai la lèvre humide et je sais la science, de perdre au fond d’un terminal ISE l’antique conscience. Je sèche tous les pleurs sur mes KPIs triomphants, et fais rire les DSIs du rire du DEVOps

Erwan GUILLEMARD refondu de Charles BAUDELAIRE

Sources

• VMWare – PowerCLI

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é !).

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 !).

SS_039_1_COMBODO_itop_api.psm1

Le module est constitué de 6 fonctions. Nous noterons le camouflage de deux informations capitales (d’où le NON sécurisée plus haut). Il faudrait avec un peu d’huile de coude que je modifie le code pour que ce dernier gère l’authentification via la fonctionnalité CLIXML. Promis je travaille dessus.

Il existe deux versions de ce module. Une version compatible ITOP 2.7.X LTS et une version ITOP 3.2.X LTS. La fonction API propre à la création d’une requête diffère entre ces deux versions.

• formatItopNumberCustomer : Fonction qui permet de récupérer le nom et le numéro identifiant le client dans le cas où le format est du type XX-CUSTOMER. Cette fonction est plus orientée dans le cas de Service Provider. Mais qui peut le plus peu le moins c’est pourquoi la fonction est présente par défaut
• Invoke-RestiTopMethod : Fonction qui permet de réaliser l’appel API
• Get-REST_API_iTop : Fonction qui permet de réaliser des requêtes de type CORE/GET à notre instances ITOP
• Get-Organization : Permet de récupérer la liste des organisations présentes dans ITOP et ceux pour pouvoir créer les requêtes dans la bonne organisation
• CreateRequest-REST_API_ITOP : Fonction qui permet de réaliser des requêtes de type CORE/CREATE à notre instances ITOP pour créer une requête
• ApplyStimulus-REST_API_ITOP : Fonction qui permet de réaliser des requêtes de type CORE/APPLY_STIMULUS à notre instances ITOP pour assigner un état à notre requête créé précédemment

SS_039_1_HTML_report.psm1

Le module est constitué de 2 fonctions.

• Set-ITOP_HTML-VEEAMONEREPORT : Fonction qui prend un certain nombre d’argument en paramètre afin d’établir le rapport HTML qui sera poussé dans le corps de notre requête ITOP
• Set-ITOP_HTML-ErrorReport : Fonction qui prend un certain nombre d’argument en paramètre afin d’établir le rapport HTML d’erreur qui sera poussé dans le corps de notre requête ITOP dans le cas où la fonction initiale n’a pas pu aboutir

SS_039_1_VEEAM_One_api.psm1

Nous retrouvons sensiblement les mêmes fonctions que dans le module dédié à ITOP. Bien qu’à l’inverse, je n’ai pas été fainéant car la gestion de l’authentification est sécurisée pour VEEAMOne…

Passons, le module est composé de 9 fonctions.

• Invoke-RestVEEAMOneMethod : Fonction qui permet de réaliser l’appel API
• Connect-VEEAMOneAPI : Fonction qui permet d’établir la connexion au webservice VEEAMOne
• Disconnection-VEEAMOneAPI : Fonction qui permet de cloturer la connexion au webservice VEEAMOne
• Get-ServerInformations : Fonction qui permet de retourner les informations du serveur VEEAMOne
• Get-Sessions : Fonction qui permet de retourner l’ID de la session en cours
• Get-AllAlarms : Fonction qui permet de retourner toutes les alarmes en cours sur l’application VEEAMOne à tous les niveaux Infrastructures à Backup de l’hôte jusqu’au VMs
• Get-License : Fonction qui permet de retourner les informations relatives aux licences
• VEEAMONE_Extract_Informations : Fonction qui permet de traiter les informations retournées précédemment et de consolider ces dernières
• Get-VEEAMONE_GlobalDataObject : Fonction qui appel la fonction précédente pour consolider le retour dans un seul objet

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.

1 – Création de l’utilisateur

Créer un utilisateur qui devra être utilisateur du domaine.

2 – Assignation à un groupe

Afin de limiter les risques au maximum, nous allons ajouter notre utilisateur au groupe de service pour restreindre le périmètre d’attaque de ce compte.

Nous allons également ajouter ce dernier en tant que membre du GLS VEEAM One Administrator qui est membre du groupe local de notre serveur VEEAMOne.

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.

1 – Personne

2 – Compte utilisateur

3 – Services

4 – Contact

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

1 – SS_039_1.0_ConnectorVEEAMOne-ITOP.ps1

On ne touche pas la première ligne, sauf si les modules changent. Je choisie de gérer le chargement des modules à travers le script.

La seconde ligne se trouve être tout simplement le chemin absolu où va être stocké notre script.

La variable $_const_defaultItopOrganisation doit contenir le nom de l’organisation ITOP par défaut. Dans le cas d’un fonctionnement en tant que Service Providers, l’outil basculera vers dans une autre condition. Si l’organisation client n’est pas trouvé, l’incident sera remonté directement dans l’organisation par défaut.

Il en est de même pour la variable $_const_defaultTeam_from_defaultOrganization qui va contenir l’équipe pour qui le ticket va être assigné. Dans le cas contraire, l’équipe sera définie sur une valeur en dur dans le code.

Nous ne touchons pas au format date.

Plus loin dans le script nous trouvons les variables liées au system notamment pour la partie authentification.

Il sera nécessaire de modifier le nom du domaine, le compte qui va être utilisé pour établir la connexion à l’application VEEAMOne. De renseigner le chemin absolu où va être stocké le fichier CLIXML pour l’authentification.

Je ferai un article sur les différentes gestions des credentials et moyen d’authentification en powershell à l’avenir car je pense utile pour moi de connaitre l’ensemble des méthodes et de faire un rapide feedback. Décidemment, le respect de la loi allgood est dead là !

Bref, je reviendrai sur ce point plus tard, mais dans le cas d’un dysfonctionnement d’authentification il suffira de supprimer le fichier xml.

2 – SS_039_1_VEEAM_One_api.psm1

Dans le fichier de module propre à VEEAMOne il faut regarder les lignes suivantes.

STOP ! RED FLAGS !! Depuis quand on balance des variables dans un fichier module ou header (.h représente !) gros cochon ! Si l’indien ou le vieux VERMEU te voyaient, tu ne convoiterais pas comme ça cette banane !

Oui je sais, pour le coup j’ai fait de la merde par paquet de 10 et c’est dégeulasse Mais avec ça je suis au moins certain que ce n’est pas du chat GPT ! Je vous explique l’hérésie. J’ai d’abord fait le code en ps1 (version 1.0) puis je me suis dit que l’architecture n’était pas la bonne. J’ai donc refactorisé une partie du code mais pas tout. Ce heurte alors à la portabilité des variables, les appels et le transfert d’argument… J’ai fait comme d’habitude. Je remets à demain, qui le remet à plus tard, mais pas à jamais…

Enfin, passons et regardons ce qui doit être modifié

Préciser dans la première ligne l’url de notre serveur VEEAMOne. Ne pas oublier d’ouvrir les flux si besoin et de bien commencer par https:// et terminer par /api.

Pour le reste, pas besoin de toucher 🙂

3 – SS_039_1_COMBODO_itop_api.psm1

Idem que pour le volet précédent concernant le module VEEAMOne, c’est à gerber… Mais c’est comme ça et dans la vie il faut savoir serrer les dents et garder les gros morceaux (si vous avez l’image, oui c’est hard et dégelasse).

Mais comme présenté plus haut, c’est encore plus insupportable car le couple d’authentification à ITOP est en clair dans le fichier…

Oui je vais corriger ça. 🙂 Mais regardons tout de même les variables à adapter.

Dans la première ligne relative à l’url, modifier portail.erwanguillemard.com:443 par votre url en spécifiant le port. Naturellement si vous êtes en HTTPS pas besoin de préciser le port.

Préciser la version de l’API, le compte utilisateur créé précédemment (celui avec le profil REST) ainsi que son mot de passe.

Laissez la varibale d’outfields à *. Sans quoi vous ne retournerez pas l’ensemble de tous les attributs lors des appels API.

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 🙂

Finalement, pas besoin de MARSHAL, après plusieurs semaines (en réalité ça fait 2 ans que je cherche… Mais chut !) je suis tombé dans les méandres d’une discussion entre deux developper .NET dans le cadre d’une autre projet sur cet problématique. Le post datant de 2015, en tant normal je passe alégrement mon chemin, mais là j’ai lu la problématique et la démarche pour tenter de résoudre cette dernière. La théorie est bonne, mais semblait incomplète. Et pour le coup elle était bien incomplète. Tout est une histoire de contexte.

La génération du fichier chiffré (Export-CLIXML) ne doit pas être fait dans la session utilisateur, mais dans le contexte de l’utilisateur. Et donc ? Et donc chers amis, il est nécessaire de générer le fichier depuis la tâche la première fois en demandant au préalable la saisie des credentials par l’utilisateur. De cette manière, même avec ma session qui a servi à l’exécution, je ne peux pas déchiffrer le contenu du fichier (fallait y penser).

Poussant le vice plus loin, cela fonctionne avec mon compte de service, mais également avec un compte de type MSA¹². Pour plus de détail, je vous laisse me contacter 😉

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

1 – Général

2 – Trigger

3 – Action

4 – Conditions

5 – Settings

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. Hourra ! (petit update 3 mois après…). Le gout amer est partie 🙂 A partir de ce jour le script est sécurisé à travers un fichier généré par CLIXML depuis un compte de service standard et gMSA. La méthode était la bonne, mais pas la pratique. Tout est histoire de contexte finalement. Comme quoi avec persévérance 🙂

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. MSA : Managed Service Account ↩︎
13. VM : Virtual Machine ↩︎
14. DRS : Distributed Ressources Scheduler ↩︎