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 ↩︎

Mon binôme et moi-même rigolions à quelques blagues potaches de ma part. Tout allait bien. J’enchainais dans notre solution ITSM¹ les requêtes SQL²/OQL³ avec des gros mots comme DROP, DROP CASCADE. (Vous le voyez le drame qui arrive ? Iceberg droit devant !

Attention spoiler, ça ne va pas se terminer avec l’anneau dans le volcan !).

Un collègue passe m’avertir qu’il ne peut plus traiter de ticket. Je me souviens lui avoir répondu avec un aplomb digne d’un politicien que c’était normal. Pourquoi s’arrêter en si bon chemin dans l’exécution de mes requêtes, il n’y a pas de message d’erreur ? Tant que je gagne je joue ! xD

J’ai un peu moins rigolé quand deux minutes montre en main le responsable du centre de service m’a indiqué que s’il y a quelques minutes nos collègues ne pouvaient plus s’assigner de ticket, cette fois si, ils n’existaient même plus et ne pouvaient plus sélectionner leur nom sur l’interface WEBUI⁴.

Pour vous résumer mon état :

Si ça en a le gout, la texture et l’odeur. C’est que s’en est !

Ce n’est pas de moi, mais l’auteur je l’espère se reconnaitra

Avant de poursuivre ce conte digne des frères GRIMM, je souhaite dans cet article vous faire part d’une situation particulière à la limite du critique, de la réflexion pour corriger cette situation et des solutions pour se prémunir d’une potentielle récidive. Chassez le naturel, il revient au goulot…

Prérequis

• SE: RHEL, DEBIAN, UBUNTU
• Apps: bash, crontab, Mariadb/Mysql
• Autres: Au moins une base de données, Apps – MUTT

(Reprise de l’histoire)

Effectivement, j’ai bien « défoncé » quelques tables et jointures. L’application ITSM colonne vertébrale de notre organisation n’est plus fonctionnel. Il est 15h00 et l’ensemble des équipes sont à l’arrêt. Paradoxalement, j’aurai dû continuer de passer des requêtes SQLs car si nous ne pouvions pas traiter les demandes et incidents des utilisateurs, ces derniers pouvaient créer des tickets.

A ce moment, nous avions bien identifié l’origine du dysfonctionnement (1m98, 85 kilos… oui mais pas que). Nous envisagions mes collègues et moi une once d’espoir pour faire machine arrière quant à mes actions sur la base de données.

C’est un peu plus difficile quand j’ai annoncé ne pas avoir noté toutes les requêtes que j’avais exécuté, et que les journaux de logs sont vides.

Pourtant, personne ne doit travailler le vendredi après midi, le vendredi après midi on est bleu. La décision est prise. Il va falloir restaurer la base de données.

Réunion de crise

Récapitulons donc la situation, la production est hors service. Nous ne pouvons pas revenir en arrière, la production continue de tourner et à cette époque nous avions un fonctionnement particulier avec l’un des nos clients pour lequel notre outil ITSM était « master » d’un seconde instance ITSM satellite « slave » avec des synchronisations. Bref, un truc super mais sensible en cas de non respect du cycle de vie des tickets.

En dehors du cas singulier précédent, il faut savoir que dans le fonctionnement de notre organisation, nous avons des engagements de résultats sur le traitements des demandes et incidents (SLA⁵, OLA⁶, SLR⁷ etc).

Revenir en arrière en restaurant la base de données, oui mais sans perdre les tickets et requêtes utilisateurs en cours.

A quelle heure pouvons nous donc restaurer la BDD ? Encore une fois c’est là où le bât blesse. Nous n’avons pas de dump de la base… (Nous voici donc au volant d’une voiture qui roule à vive allure, nous pensons que tout va bien puis que d’un coup nous découvrons que l’assurance n’est pas à jour. Que l’ensemble des témoins du tableau de bord s’allument tous comme un sapin de Noël et que les freins vont surement lâchés.)

Nous décidons de contacter l’éditeur qui malheureusement ne peut rien faire pour nous dans le contexte et arrive à la même conclusion que nous. La restauration en date de la veille et inéluctable.

Nous réalisons toutefois un export de l’ensemble de toutes les requêtes créés, modifiées entre le matin même de 06h00 à 18h00 sur l’environnement ITSM de production ainsi que sur l’environnement ITSM satellite du client, puis coupons les services. De mémoire, cela représentait un volume de 300 tickets environ.

Excès de confiance

Pourquoi cette situation ? Pourquoi ce changement n’a-t-il pas été soumis à un CAB ? Si vous avez pris un peu le temps de lire d’autres articles ou de lire ma présentation, je suis quelqu’un de malchanceux marqué du signe du chat noir ascendant Pierre RICHARD (mais je le vis bien je vous rassure). Nous avions initialement mon collègue et moi pour objectif « d’alléger » notre base de données de production. C’est pourquoi, dans le cadre du contrat de support et d’assistance avec l’éditeur, après une analyse commune, nous avions établit une liste de requête précise.

Toutefois et par prudence, il était impératif de tester sur notre environnement de test/préproduction à ISO périmètre de l’environnement de production les dites requêtes. Chose qui a été réalisé par mes soins sans rencontrer la moindre complication ou dysfonctionnement. Le résultat est positif, tous les voyants sont verts. Pourquoi ne pas appliquer les modifications sur l’environnement de production ?

C’est là, que ça ne va pas. L’environnement de préproduction ne fonctionne pas à ISO périmètre de l’environnement de production. Ce dernier est sans cesse sollicité se qui n’est pas le cas de l’environnement de préprod. (C’est diabolique). Et donc, l’application des requêtes ont générés d’autres erreurs. L’outil ITSM m’a gentiment proposé de corriger les dîtes erreurs. Je suis donc sortie allégrement du contexte de mon changement sans m’en rendre compte.

Je pensais maitriser mes actions et n’ais à aucun moment pensé qu’il s’agissait d’un changement ! Il a suffit d’un excès de confiance. Pour mettre à genoux l’organisation (rien de bien dramatique en soi quand nous voyons aujourd’hui l’impact d’un crypto, ce n’est pas du tout le même impact).

Mais vous savez même si la chat et noir, il a toujours quelques poils blancs dans son pelage 🙂 L’incident tombant un vendredi, il nous reste le week-end pour trouver une solution.

Plan d’actions

C’est incroyable de se dire que l’action d’un individu à impacté l’ensemble des services et nécessité cinq collaborateurs de trois services différents. Néanmoins, personnes n’a été malveillant à mon égard à ma grande surprise. Nous étions une équipe face, un bloc face à l’incident en cours.

Nous avions donc défini le plan d’action suivant :

• Restauration du serveur de base de donnée à la veille dans un environnement isolé
• Réalisation du dump de la base de données
• Exportation de la base de données
• Désactivation de l’appareillage entre l’ITOP master et le satellite (slave)
• Importation de la base de données sur l’environnement de production
• Réalisation des mêmes actions côté ITOP satellite
• Réactivation de l’appareillage entre les deux ITOP
• Reprise des requêtes côté satellite depuis le fichier CSV exporté plus tôt
• Reprise des requêtes côté master depuis le fichier CSV exporté plus tôt

Sur le papier cela sonnait bien. Et pourtant encore nous allions buter sur deux points bêtes. C’est toujours quand nous sommes dans l’embarras (pour ne pas dire dans la m***e) que nous nous rendons compte de la réalité des choses.

• A l’époque, dans une console VMWare (version 5.5 de mémoire) il était ardu de taper certains caractères spécifiques. Nous avons buter pendant 30 minutes pour saisir le caractère « @« .
• Lors de l’import d’un dump existant ITOP, lors de l’application d’un setup il est nécessaire de supprimer l’intégralité d’une table VIEWS. Nous ne le savions pas à l’époque… (J’ai dans mes tablettes un article en cours à ce propos). Nous ne sommes pas SysDBA, mais nous avons tout de même réalisé le STATMENT qui va bien. (Malgré tous ces péripéties, ils t’ont laissé faire du SQL ? Non je vous rassure j’étais sous tutelle 🙂 ).

Reprise des données

La diversité des tickets et les différents paramètres des ces derniers allaient rendre difficile l’automatisation de réimport des requêtes. Il ne suffit pas de reprendre les tickets, il est nécessaire de leurs appliquer un « stimulus » afin que les notifications, SLA, le cycle de vie etc s’appliquent. L’éditeur nous avait prévenu quelques heures auparavant qu’il allait falloir user d’huile de coude.

J’ai eu à cœur d’assumer ma faute et de porter la responsabilité de cet échec. Si mon binôme n’était pas disponible samedi pour m’aider il l’était dimanche. Toutefois, j’ai fait tout ce qui était possible pour qu’il n’ait rien à faire.

Sur les 300 et quelques tickets, il aura dû en traiter une vingtaine et c’est je crois toujours 20 de trop. A grand coup de copier/coller, 270 tickets il faut compter à peu près 19h. (J’ai oublié de préciser que ma femme m’a mis un savon le soir comme quoi il est interdit de faire des changements le vendredi, blablabla. J’ai encore le souvenir de la voir partir le samedi soir avec ces copines et revenir tôt le dimanche matin. Ca fait ne me rajeunit pas).

Dénouement et fin

Le lundi matin, tout était de nouveau fonctionnel. Le week-end a été long et les heures de sommeil rares. Toutefois, « la bêtise » était assumée. Un nombre incalculable de « Je suis désolé », « Veuillez accepter mes excuses » auprès de mes collègues ont eu lieu. Il me semble que cela les a plus agacé que l’incident en lui même. (Effectivement le gars qui se là joue Les 120 journées de Sodome c’est usant).

Le plus beau, restera qu’aucun de nos clients n’a remarqué l’incident et le changement des SLAs de quelques heures. Si quelques interlocuteurs clients l’ont remarqués ils n’ont pas demandés plus de compte que cela.

Un REX⁸ a eu lieu en comité et nous avons su pointer les points qui devaient être améliorer. Le plus gros étant de s’assurer au moins un dump de la base de données entre deux points de sauvegarde. Oui mais comment faire et surtout par où commencer.

Réflexion

A la suite de la petite histoire ci-haut, qui commence mal mais qui se termine plutôt bien. L’une des premières questions que je me suis posé est qu’est ce que propose ITOP ? Est ce que la solution embarque un système de sauvegarde, de dump de base de données ?

La réponse est oui ! Mais ça ne me convient pas !

Mais il est jamais content se type. Il y a des solutions mises en place par l’éditeur dans sa solution et ça ne lui convient pas. Je le vois déjà écrire « Oui je veux pas réinventer la roue, mais… ». Tu serais pas un SysAdmin frustré par hasard ? Qu’est ce qui a ?

Pour le coup le contexte est différent. Si nous reprenons l’architecture 2-tiers (Apps – iTOP), nous avons d’un côté notre serveur web et de l’autre notre serveur de BDD. Jusque là pas de problème.

Ce qui me gène dans l’outil mise à disposition pour COMBODO, c’est que le stockage des dumps se fait du côté où est exécuter la commande mysqldump. Soit côté Front et donc stocké dans le répertoire web itop (/var/www/html/portail.erwanguillemard.com/data/backups/).

En quoi ça te gène ? En réalité il y a plusieurs points.

• Espace disque : Il existe un risque de saturation de l’espace de stockage du serveur web et de la partition /var/. La saturation de la partition (ou du disque) peut (plutôt va) rendre inaccessible le portail web. (Tu connais les hardlinks ?)
• Sécurité : Stocker les dumps de la base de données de production sur le serveur front publié vers l’extérieur représente un risque en cas d’intrusion donc de vulnérabilité et de vol de données dans le pire des cas
• Granularité : Possible uniquement de ne garder que 5 points de rétentions du lundi au vendredi à partir de 23:30.
• Mécanisme : Ce dernier est propre à ITOP est non pas une couche hors de l’application. Que se passe-t-il si le front reboot lors de la tâche de backup ou si le réseau est indisponible, si l’application est indisponible ?

Donc si nous te comprenons bien, la fonctionnalité est naze ? Non, loin de là. Au contraire, je trouve que c’est une excellente fonctionnalité car elle permet pour les petites bases de données de réaliser un dump dans les meilleurs délais et de ne pas avoir à se connecter directement au serveur backend. De plus, il est possible de réaliser une restauration directement depuis le portail ITOP (webui).

C’est à partir de ce constat que j’ai décidé d’écrire ma lettre au Père Noël (ou Saint Nicolas suivant notre situation géographique).

Petit Papa Noël, 

J'ai été bien sage en ce début d'année 2019 même si j'ai fait une petite boulette. Afin de ne pas reproduire cette bêtise, je souhaiterai avoir une solution qui réalise les points suivants :
* Un outil qui réalise 2 dumps par jour ou plus (automatisation)
* Un outil qui envoi un mail en cas de succès ou d'erreur du dump
* Un outil qui puisse avoir une fonctionnalité de dump manuel
* Un outil qui soit GENERIQUE et s'adapte à n'importe quelle base de données MySQL/MariaDB.
* Un outil qui fonctionne sous GNU (RHEL et DEBIAN) en bash.

Merci Père Noël, je t'aime tu es le meilleur.

Bisous, 

Erwan

Hélas, je n’ai toujours pas eu de réponse à ma lettre. A croire que ma « boulette » n’était pas si petite que ça… Ce n’est pas grave…

Allez, on est pas des manches, on se relève les manches et… BANZAÏ !

Merci Groland

Configuration et installation du Script

Bien qu’initialement, l’outil que j’ai développé venait répondre à un besoin professionnel, la version présentée dans cette article a pour seul lien que le contexte et a été développé, testé sur mon temps personnel.

Lecture du script

Comme toujours nous positionnerons le script à la racine du système de notre serveur SGBD dans un répertoire à part avec des droits spécifiques. L’objectif étant de toujours garantir un niveau de sécurité suffisant et d’éviter une escalade potentielle des droits.

J’insiste sur ce point, l’ensemble des actions ci-dessous sont à réaliser sur le serveur backend.

$ sudo mkdir /script
$ sudo mkdir /script/SS_015-LINUX_MYSQL_DUMP-BDD

Editez le fichier ou copiez le fichier suivant : SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

A ce jour le fichier en version E est construit de la manière suivante :

• Les constantes
• Une fonction vérifiant les prérequis
• Une fonction réalisant le dump de la base de données
• Une fonction assurant la rotation des fichiers de dumps suivant le nombre de points de rétention définit
• Une fonction pour préparer le mail
• Une fonction d’envoi de mail
• Une fonction pour forger le mail en html

Je vous propose de parcourir ensemble le script, fonction par fonction. L’objectif étant de partager ce bout de code et peut être pouvoir le soir me coucher en me persuadant que quelques parts, sur le SI d’une organisation ce bout de code, maigre contribution personnel fonctionne… Laissez moi un peu rêver ou alors dites vous que vous m’en vendez (du rêve naturellement) !

1 – Les constantes

Les noms des variables sont normalement explicites. Pour éviter toutes ambiguïtés :

• _modeHTML : Pour avoir des bô rapport en HTML
• _author : Pour afficher dans le rapport le nom du créateur
• _version : Pour la version du script
• _dateRelease : Pour la date du script (dernière modification)
• _mailTo : Contient l’email du destinataire qui va être spamé de mail
• _pathLogRepository : Emplacement où seront stockés les logs à chaque exécution du script.
• _pathLogFile : Nom du fichier de log
• _pathBDDRepository : Emplacement où seront stockées les dumps
• _nbRetention : Nombre de dump à conserver
• _dbName : Nom de la base de données concerné par le traitement
• _dbUser : Nom du compte Mariadb/MySQL qui sera autorisée à réaliser le dump de la BDD
• _dbPassword : Mot de passe du compte renseigné précédemment

2 – Fonction : Check Prérequis

Cette fonction à pour objectif de vérifier et de contrôler que toutes les conditions nécessaires au bon déroulement du script soient présentes.

• Création du répertoire de log si absent
• Création du fichier de log si absent ou différent

• Création du répertoire des dumps 1/2 et 2/2 journalier

Si et seulement si les conditions sont présentes alors le script fera appel à la fonction suivante dumpCreate.

« J’ai une question bête ? C’est quoi ta variable $codeArg et la commande tee ? »

Il est important de se rappeler « il n’y a pas de question bête, il n’y a que des réponses stupides« .

Lorsque j’ai écrit ce bout de code il y a 4 ans, je souhaitais offrir la possibilité de réaliser l’automatisation des dumps mais de garder la possibilité de lancer manuellement un dump sans à avoir à taper la commande mysqldump, le login et le mot de passe.

De ce fait, si nous appelons le script :

• Sans argument : Réalise un dump de la base de données à l’instant T
• Avec argument (MidDay ou MidNight) : Réalise un dump de la base de données dans un répertoire spécifique. A son intérêt si appelé dans une tâche planifiée.

La commande tee offre un avantage car elle permet de retourner l’affichage d’un terminal dans un fichier. Ce qui permet de voir ce qui se passe lors de l’exécution du script et de garder une trace de l’ensemble des actions. D’un côté cela reste plus lourd dans la syntaxe que le traditionnel 2>&1 qui ne gère que le stdout et stderr. Probablement qu’aujourd’hui je ferai différemment.

3 – Fonction : Dump Create

Nous rentrons dans le vif du sujet. Je réalise le dump de la base en deux temps.

• Export du dump .sql
• Compression du dump .sql en .gzip

Toujours en prenant en compte l’argument passé lors de l’appel du script pour positionner le dump dans le bon répertoire. Dans le cas contraire, le dump sera écrit à la racine du répertoire contenant les dumps.

Dans cette fonction, les commandes les plus intéressantes sont bien entendu les commandes mysqldump et gzip.

Pourquoi faire en deux temps alors qu’il est tout à fait possible de réaliser ces deux actions en une seule commande ?

Excellente question pour laquelle je ne me souviens plus pourquoi j’ai fait ça. Peut-être pour le plaisir de chercher midi à quatorze heures que sait où mon côté néophyte ?

Nous précisons l’utilisateur qui va réaliser le dump de la BDD (attention au permission sur la base) ainsi que son mot de passe -u $_dbUser et -p$_dbPassword. L’option –master-data permet de se positionner si une réplication SQL est se place sur la dernière position. L’option –quick est utile dans le cas de BDDs importante. Cela va permettre de récupérer les lignes d’une table, ligne par ligne, plutôt que de récupérer l’intégralité de toutes les lignes et de les garder en mémoire avant de l’écrire. L’option –single-transaction qui est à mon sens l’option la plus importante de notre ligne de commande puisque cette option permet de réaliser le dump de notre base de données à chaud sans verrouiller les tables ni bloquer l’application. Pour faire plus simple, cela permet de garantir la consistance des données de notre DUMP. L’option –verbose est quant à elle compréhensible. Nous indiquons la BDD dont nous souhaitons réaliser le dump $_dbName, redirigeons l’ensemble des flux dans le répertoire adéquate puis l’ensemble des flux dans notre fichier de log.

La compression est plus simple puisque nous appelons la commande gzip en indiquant que nous voulons de la verbe et que nous allons forcer la création de l’archive. Comme pour la commande précédente, nous redirigerons l’ensemble des flux dans notre fichier de log.

Et donc si nous souhaitons faire cette opération en une fois ?

Il suffirait de faire un pipe des deux commandes.

$ sudo /usr/bin/mysqldump -u $_dbUser -p$_dbPassword --master-data --quick --single-transaction --verbose $_dbName > $argDump/`date +"%Y-%m-%d"`-$_dbName.sql 2>>$_pathLogRepository/$_pathLogFile | /bin/gzip -f -v $_pathBDDRepository/`date +"%Y-%m-%d"`-$_dbName.sql 2>>$_pathLogRepository/$_pathLogFile

Je ne l’ai toutefois pas testé. Donc à vérifier, mais il n’y devrait pas avoir de raison que ça ne fonctionne pas.

Il y a toutefois une variation entre le commande présente dans le wiki de COMBODO et ma commande. Je ne précise pas les arguments –opt, –default-character-set=utf8, –-add-drop-database. Pourquoi cette prise de liberté soudaine ?

L’option –opt est activé par défaut et si nous ne référons au manuel mysqldump, cette commande est un raccourcie de plusieurs autres commandes. Dans notre cas et si l’installation de MySQL/MariaDB a été effectué comme dans un précédent article , la question ne se pose pas. A l’inverse, nous ne spécifions pas l’encodage des caractères –-default-character-set. Cela pourrait nous porter préjudice. Néanmoins et par défaut si ce dernier n’est pas spécifier, mysqldump utilisera le type utf8mb4. On ne va pas se mentir, je ne suis pas super à l’aise sur le sujet. Si ce n’est que l’utf8mb4 est plus récent que le format utf8 et prend en charge les emojis etc. Par expérience, tous les dumps que j’ai dû réimporter jusqu’à présent ont été réalisé sans spécifier le type d’encodage utf8. Je n’ai pas constaté d’erreurs ou de dysfonctionnements. Moralité, je vais me mettre au diapason. (D’un côté faut être un peu c*n pour dire j’ai RTFM mais j’ai pas appliqué les recommandations de l’éditeur…).

4 – Fonction : CleanUp Repository

Je vois déjà certains SysAdmins ou Dev se dire « Nan le gazié il est pas sérieux avec son _nbRetention, il a pas osé faire une fonction de rotation de ces fichiers .sql/.gzip ?! » Et bien désolé de vous décevoir, la réponse est bien un énorme OUI, j’ai osé.

Pourquoi ? Simplement pour me demander comment ferai je si je devais me passer de logrotate. Et le cas échéant, j’ai appris quelques choses d’autres et j’ai donc un as dans ma manche si je dois faire une rotation de fichier un jour sans logrotate.

(Comme déjà dit plusieurs fois, il est important de savoir se perdre de temps en temps.)

La commande find permet de lister l’ensemble des éléments sur un critère. Dans notre usage, nous souhaitons lister tous les éléments (fichiers réguliers) d’un des répertoires contenant nos Dumps -type f dont la dernière modification est inférieurs au nombre de point de rétention -mtime +$argNbRetention. (Notons que cela s’exprime en jour donc 5 x 24heures). Les fichiers ne répondant pas au critère sont supprimés -delete.

Je passe mon tour sur les trois dernières fonctions qui sont ennuyeuse au possible et qui pour moi n’apportent aucun intérêt dans le projet. Puisque cela concerne l’envoi d’un mail de notification de succès ou d’échec de l’archivage ou de la réalisation du dump.

Qui dit notification mail, dit serveur de messagerie (Apps – MUTT).

Nous contrôlons les droits sur le fichier afin de s’assurer que ce dernier est bien en 700 pour root:root.

$ sudo ls -ahl /script/SS_015-LINUX_MYSQL_DUMP-BDD

Dans le cas contraire, il sera nécessaire de réaliser les opérations adéquates.

Configuration du cron

Perso, je souhaite avoir un delta de 6 heures maximum en cas de panne et donc (attention largage de gros mots dans deux secondes) dans RTO⁹ de 1 heure ! Généralement, les entreprises travaillant de 8h00 à 18h00 du Lundi au Vendredi, nous allons automatiser nos dumps à 12h30 et à 18h30 sur les mêmes jours. Libre à chacun de faire comme il le souhaite. (Attention toutefois si vous avez des jobs de sauvegardes en parallèle des dumps car les SEs n’aiment pas ça, ni le matériel d’ailleurs les I/O¹⁰ un univers passionnant).

# vim /etc/crontab

Ainsi, chaque Lundi au Vendredi à 12h30 en tant que root, le script stocké sous /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh avec l’argument MidDay viendra générer un dump de la base de données compressée sous l’emplacement de stockage par défaut /midday/. Il sera de même à 18h30 mais avec l’argument MidNight, sous l’emplacement /midgnight/.

Configuration des logs

Si vous avez déjà déployé l’un de mes outils, vous devez déjà avoir la configuration de rotation des logs pour le contenu du répertoire /var/log/ERWAN.

Dans le cas contraire, éditez un fichier de rotation.

$ sudo vim /etc/logrotate.d/rone_scripts

/var/log/ERWAN/SS_015-LINUX_MYSQL_DUMP-BDD.log {
        daily
        rotate 7
        copytruncate
        missingok
        notifempty
}

Configuration de la BDD

Euh… Je veux bien que tu parles de backup, de dump, de SQL toussa toussa. Mais qu’est ce que vient faire la configuration de la BDD dans cet article ?

Je répondrai à cette question par une question me chuchote mon avocat.

On lance le dump avec quel compte, le root ?

Effectivement, vu sous cette angle c’est moche. Qui peut le plus peut le moins. Mais le risque est de ne pas exposer d’avantage notre système et de maitriser autant que faire se peu les utilisateurs et les privilèges qui leurs sont associés.

Alors nous allons créer un compte dédié pour la sauvegarde de nos bases MariaDB/MySQL. (D’ailleurs saviez vous que le Dauphin de MySQL est une dédicace à la fille ainée de son fondateur et qu’à la suite de son rachat par SUN puis ORACLE, il dédiera l’Otarie à sa fille cadette ? Non ? Et bien voilà, nous mourrons moins c*n ce soir).

# mysql -u root -p

[(none)]> CREATE USER `svc.backup`@'localhost' IDENTIFIED BY '5uZ9Bc5KLkIJ0io0Z_Px9';

[(none)]> GRANT LOCK TABLES, SELECT, PROCESS, SHOW VIEW, TRIGGER ON *.* TO 'svc.backup'@'localhost';

[(none)]> FLUSH PRIVILEGES;

Dans les grandes lignes, nous créons notre utilisateur SQL (on pense à changer éventuellement le nom du user et le mot de passe), rien de bien compliqué. Ce qui nous intéresse en revanche se sont les permissions que nous attribuons à notre utilisateur :

• LOCK TABLES : Parce que nous utilisons l’argument single-transaction pour la consistance de la BDD
• SELECT : Pour dump les tables
• PROCESS : Dans le cas où nous viendrions à utiliser l’argument no-tablespaces. Dans notre cas pratique, inutile mais peut-être pas pour d’autres BDDs.
• TRIGGER : Pour dumps les tables TRIGGER de notre BDDs. Comme pour l’option ci-dessous, ça serait dommage de ne sauvegarder qu’un bout de notre BDD. Ca serait comme faire une soirée raclette mais en ne touchant pas au plateau de charcuterie. Aucun intérêt de faire une soirée raclette/dump.
• SHOW VIEW : Pour sauvegarder la table des VIEWS. Dans notre cas, nous les supprimerons si nous devons réaliser un dump de la BDD iTop. Toutefois, nous voulons un backup complet en cas d’avarie.

Allez, fermons notre connexion SQL et passons à l’étape suivante. La princesse Peach nous attend, à moins que ce ne soit Peggy du Muppet Show. Je les confonds toutes les deux.

Configuration du script

Il sera nécessaire avant la configuration du script de dédié un disque pour nos dumps (comme indiqué plus haut). L’une des grandes questions étant oui mais comment définir l’espace de stockage afin de ne pas faire de surallocation de ressources ?

Il est toujours difficile d’apporter une réponse empirique à cette question. J’ai pour habitude de partir sur la formule suivante :

DiskSize (Go) = (BDDSize (Go) * AVG Compression Rate * NBRetentionPoints) * 30 %

Par exemple, si nous partons des données suivantes pour un total de deux jobs automatisés par jour sur 5 jours avec un taux de compressions de 46% et que notre BDD fait 2 Go :

DiskSize (Go) = (2 Go * 0,46 * (2*5)) * 1,3

DiskSize (Go) = 11,96 Go

Il nous faudrait donc un disque dédié de 12 Go. Nous avons prévu une marge de 30% d’espace de stockage afin de ne pas avoir d’alerte relative à notre supervision et saturer notre espace disque. Nous n’avons ainsi pas la nécessité d’étendre tous les deux jours ou quatre matins notre partition.

Attention à l’évolution de notre base de données dans le temps. Si cette dernière « gonfle » rapidement, il sera nécessaire d’engager les actions adéquates.

Optionnellement, si vous réalisez une sauvegarde de votre machine (ce qui est vivement recommandé) par une solution tierce (VEEAM, HYCU etc) vous aurez votre nombre de point de rétention de sauvegarde en dump plus votre notre de point de rétention max définit dans notre script. Cela nous fait une bonne assurance.

Pour la suite, je considère donc que nous avons monté un disque de 12 Go sous /mnt/backup/.

Les droits sur le répertoire /mnt/backup doivent être 700 pour l’utilisateur root:root. N’oublions pas qu’en dehors de la sauvegarde, nous avons un autre backup de notre BDD. Il est donc logique de ne faire confiance à personne d’autre que root.

Editons notre script et modifions les variables suivantes.

$ sudo vim /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

• _mailTo : préciser l’adresse qui va recevoir les rapports de dump deux fois par jour.
• _pathBDDRepository : préciser le répertoire racine créé précédemment qui va contenir nos sauvegardes /mnt/backup.
• _nbRetention : Le nombre de point que vous avez définit dans notre formule. Vous pouvez l’augmenter ce dernier ou le diminuer à votre guise. Tant que l’espace de stockage arrive à suivre, pas de problème.
• _dbName : Le nom de la database dont nous voulons réaliser le dump.
• _dbUser : Le compte SQL dédié uniquement à la réalisation des dumps.
• _dbPassword : Le mot de passe du compte SQL ci-haut.

Et le reste, pas touche, sauvegarder les modifications.

Bon, plus qu’à tester.

Test, Let’s the Rock of Begins

Afin de vérifier que tout va bien nous allons exécuter un dump manuellement et simuler l’automatisation d’un dump.

# /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

#/script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh MidNight

Normalement si nous avons bien fait les choses, nous devrions avoir dans notre console le retour suivant :

Si nous laissons tourner notre script 24 heures, nous devrions avoir la structure suivante dans notre répertoire /mnt/backup

Nous pourrions supprimer un sous répertoire, ce dernier sera recréé lors de la prochaine exécution du script dans le contrôle des prérequis. 🙂

Au début, je voulais joindre en pj le fichier de log. Mais tant que nous n’avons pas une grosse BDDs ça passe, après c’est plus délicat. Je dois faire des efforts dans ce sens pour mieux gérer la verbosité de mes journaux je crois.

Néanmoins, nous pouvons faire une tour dans le répertoire de log et consulter l’ENSEMBLE de toutes les actions réalisées par le script.

Soit en petit échantillon.

Et pour terminer, le plus important car nous ne sommes pas en permanence sur notre terminal putty, le petit mail nous informant du bon succès des opérations.

GitHub

Le code source ? C’est par là => LIEN (Licence GNU).

Conclusion

Il n’y a rien de pire que l’excès de confiance dans la profession d’AdminSys. A la différence des chirurgiens et autres médecins qui sont en dessus des divinités, l’AdminSys se voit vite revenir à la réalité. Je pense et s’est ce que mes mentors m’ont inculqués, peu importe la tâche nous devons être en permanence vigilant.

C’est avec ce genre de situation que nous prenons pleinement conscience des manquements sur nos systèmes d’informations et qu’il est nécessaire de trouver des solutions palliatives, payantes ou homemade (bancales la plus part du temps mais qui font ce que nous attendons).

Dans mon cas et pour revenir à la situation initiale, je pense avoir répondu à ma problématique d’indisponibilité des données entre deux points de sauvegarde (24h). Mais c’est encore loin d’être parfait. La solution est générique certes, mais elle pourrait tellement être optimisée, factorisée et simplifiée.

Pourtant nous ne sommes pas allés au bout de ce projet. Et j’avoue que j’étais partagé pour aborder ce point. Je traiterai ce dernier dans un autre billet. Mais ce que nous devons garder à l’esprit c’est que nous avons un dump de notre base de données SQL (que ce soit, ITOP, ZABBIX ou autres applications), qu’est ce qui nous dit que le contenu de notre dump est intègre et fiable ? Il faudrait réimporter ce dernier dans un environnement de test et recetter le dump. Ainsi la boucle serait bouclée et nous validerions notre processus de reprise de données à partir d’un dump de bout en bout. Cela viendra s’inscrire dans le PAS¹¹ de notre application, organisation.

Le mot de la fin :

Il était une petite requête, pirouette cacahouète. Il était une petite requête qui a fait une grosse boulette.

Pirouette, pas de caouhète. Vous passez en week end studieux sans apéro…

Erwan GUILLEMARD

Source

• FIND
• GZIP
• ITOP – DataBackup (v3.X)
• ITOP – DataBackup (v2.7.X)
• MYSQLDUMP – master-data
• MYSQLDUMP – quick
• MYSQLDUMP – single-transaction
• MYSQLDUMP – minimum privileges
• TEE

1. ITSM : Information Technology Service Management ↩︎
2. SQL : Structured Query Language ↩︎
3. OQL : Object Query Language ↩︎
4. WEBUI : WEB User Interface ↩︎
5. SLA : Service Level Agreement ↩︎
6. OLA : Operational Level Agreement ↩︎
7. SLR : Service Level Requirement ↩︎
8. REX : Retour d’EXpérience ↩︎
9. RTO : Recovery Time Objective (différent du RPO Recovey Point Objective) ↩︎
10. I/O : Input / Output ↩︎
11. PAS : Plan d’Assurance Sécurité ↩︎

Il existe la norme ISO 9001 visant à mettre en place un système de management de la qualité dans l’objectif de mesurer et d’améliorer en continu la satisfaction des utilisateurs. L’inconvénient d’une norme est que cette dernière doit être renouvelée tous les trois ans et nécessite de passer par un audit externe pour être de nouveau recertifié. Pour obtenir la certification, il est nécessaire d’embrasser la norme dans sa totalité et ce même si seulement un toute petite partie vous intéresse ou vous concerne.

En comparaison il existe ITIL¹. ITIL est presque comparable à la norme ISO 9001. Toutefois, il s’agit d’un ensemble de bonne pratiques et est adapté pour le management des systèmes d’information. Nous retrouvons la notions de KPI², de niveau d’engagement, de qualité de service etc. Etant un ensemble de bonne pratique il est donc possible contrairement à la norme ISO 9001 de sélectionner se qui est indispensable pour l’activité de notre organisation.

Niveau certification cette dernière est portée par les hommes et non par la société sans échéance de validité. Il existe plusieurs niveau de certification.

Si je vous parle de ces deux notions, c’est que je souhaiterai vous présenter une solution opensource ITSM³ (construit sur l’une des bases ITIL), incluant une CMDB⁴. Je vous parle d’ITOP, de Combodo.

J’ai rencontré cette solution en 2014 lorsque j’étais un jeune « trou du cru » sur le marché du travail. Cette solution était utilisée par la société pour gérer au quotidien le parc informatique, les requêtes utilisateurs, les enquêtes de satisfaction et à l’époque le MCO⁵ afin d’être pro-actif afin d’éviter de potentiel incident d’infrastructure.

Bref, cette solution me permet de garder un peu la forme côté GNU, en pratiquant mon bash et me remettant en cause en permanence quant à la sécurité et la bonne gestion des systèmes LINUX. Mais également comme cette solution gère les tickets de créer des passerelles entre des applications tierces (SPOILER, ça sera dans d’autres articles).

Dans cette article, je souhaite partager avec vous mon retour d’expérience sur le déploiement d’ITOP (Community ce qui entre nous ne change rien de la version Essential ou Entreprise pour ce que fait sur mon temps libre) sur une architecture 2-Tiers durcie.

Point important, j’ai pour habitude de ne travailler qu’avec des versions LTS⁶ et non STS⁷ (ça c’est juste pour le fun). Donc à ce jour, la dernière version LTS et la 2.7. C’est cette version que je déplorerai.

Le schéma topologique ci dessus représente l’infrastructure que nous allons mettre en place. Ce schéma sera amené à évoluer en vu des projets à venir.

Dans la logique, il devrait y avoir publication. Malheureusement, mon lab à domicile, possède certaines contraintes :

• Absence de Firewall
• Absence de hyperviseur ayant suffisamment de ressource pour faire tourner l’ensemble de mon lab
• Absence d’IP Public fixe
• Absence d’équipement physique ou virtuelle pour réaliser de la micro segmentation (nous ferrons à l’ancienne).
• Faible débit, 100 Mbits/s. Blague mise à part, il n’y a pas si longtemps j’avais une ADSL 10Mbits/s. Donc pas si faible que ça. 🙂

Ce n’est pas grave, chaque chose en son temps. La publication n’est pas le point le plus ardu du déploiement.

Prérequis

• SE : RHEL
• Apps : ITOP, APACHE, MariaDB
• Autres : LINUX – Durcissement GNU, Recommandation ANSSI, ITOP (documentation)

Installation et Durcissement du SE

Concernant cette partie, je vous invite à parcourir la section déjà documentée dans l’article LINUX – Durcissement GNU, Recommandation ANSSI .

Je pars du principe que le durcissement a été réalisé. Si ce n’est pas le cas, vous pouvez suivre directement la documentation de l’éditeur pour le déploiement.

Concernant les recommandations matérielles (physiques ou virtuelles), vous retrouverez les préconisations ci-dessous de l’éditeur

Pour ce qui est des préconisations des composants et dépendantes logicielles

Backend

Je recommande toujours dans le cadre des serveurs de base de données de dédié un disque pour le SGBD⁸ et un disque pour réaliser les dumps de ou des bases de données.

Dans notre cas, nous allouerons un disque de 20Go pour le SGBD et un disque de 20 Go pour nos dumps.

Dans le respect des bonnes pratiques GNU, je crée deux répertoires sous /mnt

• databases
• dump

$ sudo mkdir /mnt/databases
$ sudo mkdir /mnt/dump

Il est nécessaire d’avoir préalablement créé les partitions et monté ces dernières en xfs.

Pardon, M’sieur, mais moi je débute avec Linux. Vous pouvez me dire comment qu’on fait, c’est pas plug and play ? On m’appelle le chevalier blanc, je vais et je vole au secours d’innocent…. Bref c’est un basique, mais n’avons nous pas tous commencé par là ? Je vous invite à parcourir la section déjà documentée dans l’article LINUX – Disk & Part.

Mariadb – Installation

Si vous êtes sur un environnement durci, avant de lancer les installations il y a quelques choses à faire, sinon vous allez être marron 🙂

Il est nécessaire dans le cas de notre version d’ITOP de déployer la version 10.6 de MariaDB. Toutefois, j’ai décidé pour des raisons pratique de faire un article dédié sur l’installation, configuration et sécurisation du serveur MariaDB. Je vous invite à vous référer à ce dernier dans l’article Apps – MariaDB.

iTOP – Configuration

L’installation, configuration et sécurisation étant terminée, nous allons enfin aborder le sujet ITOP côté BDD.

Il est à noter que nous pouvons sécuriser d’avantage ITOP en implémentant la couche SSL entre notre serveur web (front) et notre serveur BDD (back). Nous aborderons dans une section singulière cette fonctionnalité optionnelle.

Les opérations SQL se déclinent en cinq mouvement comme une symphonie fantastique.

Création de l’utilisateur

Créer un utilisateur en prenant bien soin d’indiquer son nom, le subnet et son mot de passe.

> CREATE USER `itop_rone`@'192.168.13.0/255.255.255.0' IDENTIFIED BY 'fnd4D6CTFy3ykjq29AgB';

Création de la base de données

> CREATE DATABASE `itop_rone_db`;

Sélection de la base de données

> USE 'itop_rone_db';

Attribution des droits

> GRANT USAGE ON *.* TO 'itop_rone'@'192.168.13.0/255.255.255.0' IDENTIFIED BY 'fnd4D6CTFy3ykjq29AgB';

Attribution des privilèges

> GRANT ALL PRIVILEGES ON `itop_rone_db`.* TO 'itop_rone'@'192.168.13.0/255.255.255.0';

Nous pouvons quitter la console SQL. La configuration d’ITOP est terminée pour la partie BDD. Pour le reste, il faudra attendre la configuration du front end et le lancement de la toute première instance de wizard ITOP.

N’oubliez pas également que le port SQL doit être ouvert sans quoi votre server refusera les flux entrant sur le port 3306/tcp.

$ sudo firewall-cmd --permanent --add-port=3306/tcp
$ sudo firewall-cmd --reload

Frontend

Installation des Dépendances

Si vous êtes sur un environnement durci, avant de lancer les installations il y a quelques choses à faire, sinon vous allez être marron 🙂

Nous allons attaquer l’installation de la partie web. Toujours en adéquation avec les prérequis logiciels pour la version 2.7.9. Avant toutes choses, mettons à jour notre système.

# dnf update

Et nous voila emmerdés. Notre gestionnaire de paquet connait bien les paquets php que nous souhaitons mais dans leurs dernière version 8.X. Sauf que nous voulons la version 7.4… Chaque problème, sa solution.

Nous allons ajouter le repo Remi à notre système fournit par Fedora. Si nous nous rappelons l’un des point de recommandation de l’ANSSI, sommes nous à 100% sure de ce repo ? La réponse est oui. Ce repo est gérée par une communauté Fedora pour la gestion des paquets PHP en version 7 et 8. Fedora étant un système RHEL nous sommes donc compatible. Néanmoins il est important de noter qu’il viendra prendre l’ascendant sur les paquets PHP fournit par le système.

Ajouter le repo Remi.

# dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm

Regardons les versions disponibles de php et celles disponibles et actifs sur notre SE

# dnf module list php

Le retour est explicit, la version qui fait foi est la version 8.1 du repo system (AppStream). Installons donc en lieu et place la version qui nous intéresse, la 7.4.

# dnf module install php:remi-7.4

Installons les dépendances nécessaires en prenant garde à la version des modules php que nous allons installer afin que ces derniers sont bien dans la version attendu. Sinon c’est un peu con.

# dnf install php php-zip php-mysqlnd php-mcrypt php-xml php-cli php-soap php-ldap php-gd mod_ssl graphviz php-pear-Net-Socket php-imap

Ajoutons le daemon httpd comme service à lancer automatiquement au démarrage (sinon c’est con va falloir le faire manuellement si la bécane va reboot comme pour la SGBD).

$ sudo systemctl enable httpd

Ajouter les règles de firewall pour ouvrir les ports 80/tcp et 443/tcp.

$ sudo firewall-cmd --permanent --add-port=443/tcp
$ sudo firewall-cmd --permanent --add-port=80/tcp
$ sudo firewall-cmd --reload

Créons sous /var/www/html/ le répertoire qui va contenir l’ensemble des ressources ITOP. Le nom est libre (mais nous allons tacher d’être cohérent), attention toutefois de garder ce dernier de côté car le path sera utilisé dans le fichier de configuration ci-bas. Nous reviendrons quelques lignes plus bas sur l’installation.

$ sudo mkdir /var/www/html/portail.erwanguillemard.com

C’est presque terminée. Il ne nous reste plus qu’a déployer ITOP. Toutefois il nous reste à configurer notre serveur Apache et sécuriser ce dernier.

Apache – Configuration

La configuration est nécessaire pour publier et accéder à notre serveur web.

Intrinsèquement, va se jouer la sécurisation du serveur WEB à travers les aspects tels que la redirection de port http vers https, la mise en place d’un certificat, prévention de man in the middle, ect.

Pour le coup, le travail est déjà fait par l’éditeur. Et ça nous n’allons pas nous plaindre ! Pour un fois, c’est plaisant d’avoir un éditeur de solution applicative qui ne laisse pas ces utilisateurs sans directives précises. Je trouve également que cela marque considérablement l’implication de COMBODO vis à vis de ces utilisateurs, de sa communauté et de l’importance des données qui pourraient être contenu dans la, les bases de données ITOP. Lien

Editer un nouveau fichier sous /etc/httpd/conf.d/ pour rester cohérent, il est de bonne pratique de donner en nom de fichier le sous-domaine (quand il y en a un) suivi du nom de domaine et de l’extension avec l’extension conf. Ainsi, dans le cas de modification de la configuration le risque d’erreur de fichier est restreint (du moins normalement).

$ sudo vim /etc/httpd/conf.d/portail.erwanguillemard.com.conf

Editez le fichier comme ci-dessous, bien que je ne suis pas familier des configurations WEB (désolé, un traumatisme durant mes études…) je vais expliquer autant que faire se peux ma configuration. Toutefois et comme énoncé précédemment, c’est à vous d’adapter les valeurs (nom et chemin hein).

• <IfModule mod_ssl.c> : Vérifie que le module est bien présent, sans quoi la configuration qui suit ne sera pas appliquée. Normalement, le module est présent de base dans le package d’installation par défaut de httpd.
• <VirtualHost *:443> : Indique que notre serveur écoute sur toutes les IPs uniquement sur le port 443
• SSLEngine on : Précise que nous allons utiliser du chiffrement SSL
• SSLCertificateFile : Indique le fichier .crt ou .csr qui va servir au chiffrement des requêtes HTTP
• SSLCertificateKeyFile : Indique le fichier .key qui va servir à déchiffrer les requêtes HTTPS
• SSLCertificateChainFile : Permet de retourner la chaîne de certification lors des connexions HTTPS. Commentée dans mon cas car je n’ai pas de certificat et passe donc par un autosigné

• ServerName : Le nom qui sera utilisé par le virtualhost pour que le serveur puisse s’authentifier
• DocumentRoot : L’emplacement de notre site web
• <Directory Path> : Définit les options et paramètres pour le site dont nous avons spécifié le chemin
• Options -Indexes -FollowSymplinks : Autorise l’indexation des répertoires ainsi que l’exécution des liens symboliques contenu dans ce dernier
• AllowOverride All : Prend en compte les directives présents dans le fichier .htaccess
• Order allow, deny : Définit l’ordre de traitement des règles. Ici les règles seront acceptées avant les règles refusées répond favorablement aux règles et se vera alors autorisé l’accès.
• Allow from all : Autorise l’accès sans restriction

Dans l’état, notre fichier de configuration est correct. Nous sommes donc pret à publier notre appliance si les sources étaient présent dans notre répertoire.

Néanmoins, il manque deux points cruciaux. Le premier est comme toujours dans notre environnement durci la configuration du SELinux. Le second point, comme évoqué plus tôt concerne la sécurisation de notre instance ITOP à travers les recommandations de l’éditeur quand aux daemon apache ainsi que le moteur php.

Bien, reprenons donc là où nous en étions.

Le SELinux étant actif, il va être nécessaire d’autoriser notre bon vieux démon apache à joindre le réseau, les bdds à travers le réseau et de définit les contextes d’exécution.

$ sudo setsebool -P httpd_enable_homedirs on
$ sudo setsebool -P httpd_can_network_connect_db 1
$ sudo setsebool -P httpd_can_network_connect on
$ sudo chcon -R -t httpd_sys_rw_content_t /var/www/html/portail.erwanguillemard.com

Apache & PHP – Sécurisation

De mon point de vu personnel ce point bien que facultatif est à implémenter. Jusqu’à présent je ne m’étais jamais penché sur le sujet. Le web m’aillant traumatisé, tant que c’est fonctionnel ça m’allait très bien. De nos jours, nous ne pouvons pas nous permettre de faire l’impasse sur la sécurité et comme nous avons déjà les recommandations et préconisations de l’éditeur, pourquoi se priver ?

Je ne compte pas reprendre en détails toutes les recommandations, les instructions sur le site officiel (rappel du lien) sont plus qu’explicites.

Apache

1 – HTTPS tu utiliseras

L’explication de pourquoi utiliser le protocole HTTPS et non pas HTTP est je pense acquis par tout le monde. Il relève d’une évidence.

Afin de se prémunir de l’usage du protocole HTTP, j’aime à faire une redirection. Dans notre fichier de configuration sous /etc/httpd/conf.d/ ajouter les lignes suivantes au début du fichier avant <IfModule mod_ssl.c>

COMBODO préconise d’utiliser l’argument Strict-Transport-Security en indiquant l’age d’expiration et le périmètre d’application.

PHP

Comme résumé par COMBODO, par défaut, le moteur PHP à un certains nombre de paramètres qui peuvent (doivent ?) être durci. L’ensemble des modifications seront à réaliser dans le fichier /etc/php.ini

$ sudo vim /etc/php.ini

1 – Prévenir l’injection de code JS pour sniffer les sessions

Perso, la seul chose que j’ai sniffé de ma vie c’est du poivre et j’étais gamin. Blague à part, il est nécessaire d’activer le paramètre session.cookie_httponly.

2 – T’envoi que si c’est sécure !

Comme précisé sur le site officiel, ce point n’est applicable que si nous utilisons le protocole HTTPS. Je ne reviens pas sur cette évidence ? La mesure vise à envoyer les cookies et à ne fonctionner que si les connexions sont chiffrées. Activer le paramètre session.cookie_secure.

3 – Il fait bon d’être LAXiste pour une fois…

Afin de rendre les cookies de session plus difficile à intercepter il faudrait activer la valeur LAX (laxiste) pour le paramètre session.cookie_samesite. Pour plus de détails, je vous laisse suivre la documentation. Notez l’avertissement de COMBODO pour les reverse proxy quant au bon fonctionnement.

4 – Couvrez ces informations que je ne saurais voir

L’un des points présent de l’ANSSI qui est magistralement mis en évidence par COMBODO est la lecture des configurations des solutions déployées sur notre SI. L’option zend.execption_ignore_args est actif par défaut et doit être désactivé. Dans certains cas, il est possible de retrouver dans les journaux de logs des informations sensibles tel que les logins et mdp de la BDD par exemple (rien que ça ?)

ITOP – Installation

Créons sous /var/www/html/ le répertoire qui va contenir l’ensemble des ressources ITOP. Le nom est libre, attention toutefois de garder ce dernier de côté car le path sera utilisé dans le fichier de configuration ci-bas.

$ sudo mkdir /var/www/html/portail.erwanguillemard.com

Télécharger le paquet d’installation 2.7.9. Deux possibilités s’offrent à nous :

• Télécharger directement l’archive depuis le serveur front
• Télécharger depuis une machine tierce puis transfert en SSH (scp ou sftp)

Personnellement, j’ai tendance à utiliser la première méthode. Tout dépendra de mon humeur et surtout du contexte de sécurité. Dans les deux cas, un contrôle de l’empreinte est nécessaire.

$ wget https://sourceforge.net/projects/itop/files/itop/2.7.9/iTop-2.7.9-11939.zip/download

$ sha1sum /home/adm.r-one/download

Le cas présent, l’empreinte est identique, nous pouvons poursuivre le déploiement. Créer un répertoire temporaire puis décompresser l’archive.

$ mkdir iTop
$ unzip download -d iTop
$ ls -al iTop/ 

Copier l’intégralité du contenu du répertoire web dans le répertoire créé plus tôt sous /var/www/html/<mon_site>/.

$ sudo cp -R iTop/web/* /var/www/html/portail.erwanguillemard.com/

Modifier les droits sur l’ensemble du répertoire sous /var/www/html/<mon_site> afin d’autoriser l’utilisateur ainsi que le groupe apache à opérer. Puis autoriser le contexte SELinux pour que le daemon httpd puisse écrire dans notre répertoire web.

$ sudo chown apache:apache -R /var/www/html/portail.erwanguillemard.com/
$ sudo chcon -R -t httpd_sys_rw_content_t /var/www/html/portail.erwanguillemard.com

Nous allons pouvoir lancer le wizard.

iTOP – Instanciation

Dans un navigateur rendez-vous sur l’url https://votre_url/setup. Cela fonctionne également avec l’IP, mais SPOILER ALERT, vous allez avoir une surprise durant le déploiement (à la suite de notre configuration) 🙂

Si vous ne publiez pas votre ITOP et que vous êtes en situation de lab, vous pouvez remédier à cette situation avec une petite surchage DNS dans votre fichier host ou alors un enregistrement de type A dans votre serveur DNS. Pour la première option, ce n’est pas bien catholique, mais c’est pour le bonne cause, c’est pour du test.

1 – Welcome 🙂

Si notre serveur apache est bien configuré, nous devons avoir dans notre navigateur internet l’image ci-dessous. En complément, cette première étape nous indiquera si l’ensemble des prérequis et dépendances sont bien présents sur notre serveur Front. Dans le cas contraire, vous n’aurez pas de Ok.

Ce n’est pas bien grave dans le cas contraire. Il vous suffira d’installer le ou les paquets manquants.

Bon on continue ? 🙂

2 – Install to or Upgrade to, that’s the question…

Ici, dans notre situation initiale nous savons que nous allons installer une nouvelle instance d’ITOP. Toutefois à l’avenir si nous parlons de « relancer » un setup, il conviendra de sélectionner l’upgrade d’une instance existante.

3 – License Agreement

Ho, tiens une page inutile… C’est ce que nous pourrions penser. Néanmoins, cette page à son importance puisqu’elle vient rendre à Caesar ce qui appartient à Caesar et nous informe sur les licences protégeant les différentes sources et dépendances utilisées et nécessaires au fonctionnement et déploiement d’ITOP.

4 – Database Configuration

Une des étapes que je préfère. Pourquoi ? Parce que nous sommes dans l’exemple même de la pensée Manichéenne. Ici, si nous avons bien configuré notre serveur Front et Back end nous devons ne devrions pas avoir de problème. Dans le cas contraire c’est que nous avons merdé dans une étape.

En cas d’erreur, il relève généralement des manquements suivants :

• Oublie d’ouverture du port 3306 sur le backend
• Oublie ou mauvaise définition des PRIVILEGES ou GRANT sur la base de données
• Oublie d’autorisation des contextes du SELinux sur notre Front relatif à l’usage des BDDs à travers le réseau
• Un problème de couche 8. Vous ne savez pas taper ou réaliser un copier/coller. 😀

La source du dysfonctionnement pouvant être variée, il n’existe pas de guide universel pour réaliser un diagnostic précis. Le seul conseil que je peux vous donner et d’approcher une analyse par dichotomie et de revenir au base en reprenant couche par couche le modèle OSI.

5 – Admin Account

Définissez, le mot de passe du compte admin ainsi que la langue que vous souhaitez.

6 – Les paramètres divers

Choisissez la langue par défaut de l’appliance. Pour le reste ne touchez à rien. La seule modification autorisée en dehors de la langue reste le choix d’une instance de démo ou de production. La différence entre les deux instances est implicite.

7 – Configuration Management

Sélectionnez les options et modules que vous souhaitez dans votre solution ITSM. Vous êtes libre de faire du vélo sans roulette !

8 – Service Management

Faites le choix du type de service managée. Dans mon cas personnel, j’ai choisi Service Providers puis que dans mon Lab, je souhaite me positionner comme une ESN distribuant le service à ces clients.

9 – Ticket Management

Vous avez 3 possibilitées, activer un portail simple à l’attention des utilisateurs pour déclarer les ticket, une version plus avancée ou pas de portail.

10 – Change Management

Est ce que vous souhaitez gérer les changements dans ITOP ? Personnellement non, mais vous peut-être ? Qui sait ?

11 – Additional ITIL Tickets

Alors contrairement à l’étape 10, je veux gérer les problèmes ainsi que les erreurs connues. Mais cela reste un choix purement personnel.

12 – Synthèse

Nous arrivons au bout du WIZARD. Nous retrouvons ici l’ensemble de nos choix et options que nous souhaitons déployés. Si tout est correct, nous pouvons initier l’étape suivante.

13 – Install

Si l’installation se passe bien vous devriez avoir les informations ci-dessous, puis être invité à accéder au portail.

Bien, nous voilà au terme de notre article, nous voici sur un ITOP tout propre, tout beau et vide. Mais l’appliance est opérationnelle et c’est là bien l’objectif que nous nous sommes fixé en début de ce billet.

Pop pop pop garçon ! Tu vas pas planter tes lecteurs comme ça ? Oui j’ai oublier d’aborder quelques points.

Premièrement, oui notre instance est vide et il va falloir configurer cette dernière. Pour la faire courte, je vais faire un article dédié car cela risque de faire de long.

Secondement, il reste quelques petites configurations dont l’une des plus importantes, l’exécution des tâches en background, les notifications ect. Je vous propose d’aborder ces quelques points dans les sous parties ci-dessous.

ITOP – Paramétrage du cron

Je vais reprendre ce que j’ai l’habitude de faire de mon côté, vous retrouverez en détails l’ensemble des actions sur le site de l’éditeur (Lien).

Connectons nous à notre appliance dans un navigateur web (https://portail.erwanguillemard.com/pages/UI.php) avec le compte admin et ajoutons un nouvel utilisateur (Administration>Compte Utilisateur) interne à ITOP. Créer une nouvelle personne, puis compléter la fiche de contact en spécifiant le profil Administrator (cf les deux captures ci-dessous). Gardons bien à l’esprit que les noms doivent être parlant pour faciliter le MCO de notre application.

Une fois l’utilisateur créé, connectons nous sur notre serveur front en ssh.

Les deux fichiers nécessaires aux taches en arrière plan seront stockés dans le répertoire web sous /conf/itop. Nous allons donc créer ce répertoire, lui appliquer les droits et saisir le contenu du fichier cron.params. (Naturellement, vous adapter les chemins ainsi que les noms de fichiers 🙂 )

$ sudo mkdir /var/www/html/portail.erwanguillemard.com/conf/itop
$ sudo chown apache:apache -R /var/www/html/portail.erwanguillemard.com/conf/itop
$ sudo vim /var/www/html/portail.erwanguillemard.com/conf/itop/cron.params

Faisons de même avec le fichier cron.sh. Notez que dans le script bash, nous réorientons les flux de sortie dans un fichier de log. Il est nécessaire d’adapter les droits en conséquence. Je vous recommande également d’appliquer une stratégie de rotation des logs avec logrotate. Effectivement et par expérience, le fichier de log va grossir autant que le nombre de données et d’utilisateur sur votre appliance. Si vous ne voulez pas saturer votre espace de stockage, vous savez quoi faire.

$ sudo vim /var/www/html/portail.erwanguillemard.com/conf/itop/cron.sh

Auparavant dans les premières version d’ITOP que j’ai manipulé, les tâches planifiées (cron) étaient lancés en tant que root. Avec le temps, (va tout s’en va…) il est de bonne pratique de ne pas utiliser le compte root pour des applications et d’utiliser ce dernier avec parcimonie. C’est pourquoi toujours en suivant les recommandations de COMBODO, nous allons réaliser ces tâches avec l’utilisateur apache.

J’aime dans un premier temps afficher l’ensemble des tâches exécutés par l’utilisateur puis j’ajoute la nouvelle tâche. Pour le bien de l’application il est recommandé d’exécuter la tâche toutes les 5 minutes. (Alors pourquoi tu as mis 6 ? Je sais pas, peut être parce qu’il n’est pas premier ? 🙂 )

$ sudo crontab -u apache -l
# crontab -u apache -e

Nous réappliquons les permissions ainsi que les acls sur nos deux nouvelles ressources. L’objectif étant de sécuriser au maximum le contenu de ces deux fichiers.

$ sudo chown apache:apache -R /var/www/html/portail.erwanguillemard.com/conf/itop
$ sudo chmod 750 //var/www/html/portail.erwanguillemard.com/conf/itop/cron.sh
$ sudo chmod 640 /var/www/html/portail.erwanguillemard.com/conf/itop/cron.params
$ sudo systemctl restart crond

Pour débugger et ou contrôler la bonne exécution des tâches planifiées, nous pouvons utiliser la commande ci-dessous pour lancer manuellement les tâches. Nous pouvons également contrôler le contenu du fichier de log. En cas de dysfonctionnement, soit vous n’avez aucun retour ou des erreurs.

Dans certains cas, le cron est fonctionnel mais « planté ». L’exécution des tâches de fond étant réalisées de manière procédurale, si une tache se retrouve en carafe, les autres tâches resteront en attente. L’identification de l’incident sera plutôt facile car les compteurs des prochains « run » seront antérieur à la date de la dernière exécution.

$ sudo php /var/www/html/portail.erwanguillemard.com/webservices/cron.php --auth_user=service.itop --auth_pwd='yS=>LMuN>5OrzvW2{Qj.' --status_only=1
ou
$ sudo tail -f /var/log/itop_cron.log

ITOP – Notifications

Promis ensuite notre environnement sera opérationnel et nous n’aurons plus qu’à peupler notre application et donc notre base de données. Toutefois, notre solution de ticketing doit envoyer des notifications mails pour les échéances des CIs, le cycle de vie des requêtes, les dépassements des SLAs, TTRs etc. De base, ITOP utilise la fonction PHPMail sauf que pour des raisons de sécurité je préfère passer par un relai SMTPS.

Dans iTop la configuration est plutôt simple et la documentation aussi clair que de l’eau de roche, il suffira de suivre le wiki et de lire les commentaires du fichier de configuration générale. A ce niveau il y a deux moyens possible :

• Web : Sous Configuration > Configuration Générale (si profil admin)
• CLI : Sous /var/www/html/<site>/conf/production/config-itop.php

Pour des raisons pratiques, vous conviendrez que l’interface en WEBUI va nous faciliter les choses, alors pourquoi se priver ?

Dans mon cas, je commente la ligne par défaut PHPMail pour remplacer la valeur par SMTP puis implique la configuration comme suit.

Une fois la configuration effectuée, cliquez sur le bouton enregistrer en haut de la page. Si vous avez une erreur de syntaxe, ITOP qui est bien sympa vous l’indiquera.

Pour tester si notre configuration à travers notre relai SMTP fonctionne bien, utilisons la fonctionnalité mise à disposition sous https://site/setup/email.test.php

Test – Config

Test – Confirm

Test – Le facteur est passé

Conclusion

L’une des grandes questions que vous pourriez me poser, c’est pourquoi tout ce cirque pour installer ITOP ? Question purement légitime. La première raison, est une raison de cœur. Cette solution m’a accompagné au tout début de vie professionnelle comme SysAdmin et représente la clé de voute du service que l’IT délivre au quotidien tout en garantissant un bon suivi du parc informatique. La seconde est non des moindres, la solution est OpenSource. Nous pouvons donc mettre les mains facilement dans le moteur et se salir le bout des doigts en faisant « évoluer » la solution à notre convenance, au besoin des organisations et des ces utilisateurs.

En l’occurrence, j’ai un certain nombre de module qui viennent compléter ITOP pour en faire MON ITOP. Ces derniers pourraient satisfaire la communauté, pourquoi pas ? Je me suis donc dit que la première fondation de cet édifice devait passer par l’installation d’ITOP. Je pense également continuer quelques plus petits articles comme l’upgrade d’une instance existante ou autres.

Et sinon, tu parles de module, tu la craches ta VALDA ? C’est un pop up HELLO WORD ?

Dans les articles à venir, je souhaite partager mon expérience sur :

• Un petit plugin d’administration en bash d’ITOP (front)
• Un plugin de réalisation de dump de la BDD sur un certain nombre de point de rétention en mode service en bash (back). Indépendant de ce qui est actuellement présent dans ITOP
• Un plugin d’externalisation de la BDD ITOP sur un autre site en bash
• Un gros plugin (presque une passerelle) d’intégration de suivi de sauvegarde entre la solution VEEAM (Service Provider Console et Data Plateform) et ITOP en powershell

Le monde du libre n’a pas de limite tant qu’il y aura du partage et une communauté pour faire vivre les solutions. ITOP et COMBODO s’inscrivant en plein dans cette ligné.

Le mot de la fin :

Je VEEAMZip mes serveurs ITOP et tente l’upgrade avec Jacques TOUBON ? Vous ne pouvez pas le C: est full. Vous tombez en case SYNERBOX et vous devez appliquer la loi AllGood.

Erwan GUILLEMARD

Sources

• ISO 9001
• ITIL
• ITOP
• ITOP – Secure your ITOP
• Mariadb – Repo
• Remi – Repo (PHP 7.4)

1. ITIL, Information Technology Insfrastructure Library ↩︎
2. KPI, Key Performances Indicators ↩︎
3. ITSM, Information Technology Service Management ↩︎
4. CMDB, Configuration Management DataBase ↩︎
5. MCO, Maintient en Condition Opérationnel ↩︎
6. LTS, Long Time Support ↩︎
7. STS, Small Time Support ↩︎
8. SGBD, Système de Gestion de Base de Données ↩︎