Je rassure le lecteur qui s’est égaré ici, ce billet va être simple.

Bref, j’ai la problématique suivante, lorsque je déploie une nouvelle machine Linux (RHEL¹ ou Debian) je suis le guide d’hygiène et sécurité de l’ANSSI². Ce qui se traduit par le partitionnement strict des points de montage système et de données. Sauf que lorsque la taille de notre disque varie, difficile de définir de tête quelle volumétrie doit être provisionnée pour chaque partition…

C’est donc là que j’ai pris un coup de sang.

En voiture Simone, c’est parti !

Avant-Propos

Je ne vais pas rentrer dans le détail du code qui compose mon application, ce n’est pas l’objectif. Si l’on souhaite comprendre ce dernier, un peu de réverse engineering et le tour est joué (surtout que j’ai commenté le code).

Je n’aborderai pas non plus la partie de durcissement des systèmes GNU Linux. Pourquoi ?

1. Ce n’est pas le sujet de ce billet
2. Je traite le sujet dans un de mes premiers articles que je ne partage que sur contact et échange
3. Je pars du principe que cela sera fait après déploiement du SE³.

L’objectif est vraiment de comprendre ou du moins rappeler la structure d’un système GNU quant à son arborescence d’organisation de fichier. Et donc outre à mesure à comprendre pourquoi nous devons allouer plus ou moins d’espace de stockage.

Concernant l’application que j’ai développé, bien que je revienne sur ce point plus bas dans ce billet, cette dernière n’est pas fonctionnelle sur les environnements GNU Linux du fait de la GUI⁴.

Il est également important de souligné que cette application n’est compatible qu’avec la version 5.X de powershell.

Prérequis

• SE : Environnement Windows non obsolète
• Apps : Non Applicable
• Autres :
  • PowerShell version 5.X

Théorie

Si nous devons commencer par la base, il serait bon de se poser la question

« Comment est structurer un environnement GNU Linux ? »

Contrairement à certaines connaissances que j’ai pu fréquenter, oui c’est un point important. Cela évite de faire n’importe quoi et dans une outre mesure d’apprendre quelques choses. (Toutes ressemblances avec des personnes existantes et purement fortuite).

T’es un peu chafouin en ce moment non ? Tu ne voudrais pas ton petit suppositoire à la verveine ?

Légèrement agacé avec une pointe de colère et donc de sarcasme il est vrai. L’hypocrisie des uns fait le désespoir des autres. Mais OKLM comme disent les d’jeuns je prends un sacré recul. Cependant, je suis partant pour la verveine mais pas en suppositoire, plus en pousse café 🙂 Et puis Monsieur, Madame, Mademoiselle, je suis bien fatigué… J’en ai marre…

Regardons alors de plus près l’architecture n à n-1.

(Pas de panique je vais prendre le temps de décrire chaque répertoire).

Nous avons le répertoire parent de notre arborescence, communément appelé « la Racine » (et non rien à voir avec l’organisation de l’ombre de Konoha dans Naruto [super référence…]) ou root. C’est sous ce répertoire / que nous allons retrouver les répertoires qui organise notre SE.

J’en peux plus. C’est que c’est long comme retour aux bases… J’espère ne pas avoir oublié de répertoire.

L’une des mauvaises pratiques lors du déploiement d’un SE Linux est d’allouer l’ensemble de l’espace disponible à /, de ce fait si par exemple je viens à blinder le /var/tmp ou /var/log mon système est à genoux. Donc sur un disque il convient de partitionner les répertoires.

Oui mais quels répertoires ?

En réponse à cette question, je mets en 3/4 face et je réponds par un Uraken des familles en sortant le guide de l’ANSSI.

Cela offre également une autre possibilité concernant la sécurité. Au-delà d’assurer le fonctionnement du système quant au potentiel risque de saturation de stockage, il est possible de définir des options sur les points de montage de nos répertoires. Ainsi il est possible de limiter l’accès au device ou l’exécution de programme. Je préconise également d’ajouter le répertoire /var/log/audit. Je ne rentre volontairement pas dans le détail car j’explique ce point de recommandation (R12) dans mon billet concernant le durcissement d’un système GNU Linux.

Ok pour ce qui est de la segmentation, mais du coup, quel doit être la répartition niveau stockage ?

C’est plutôt simple. Encore une fois, il suffit de chercher un peu. Malheureusement il n’y a pas de recommandation empirique. C’est donc à nous de définir les seuils par répertoire en tenant compte des critères énoncés précédemment.

Pour ma part cela donne :

Voilà ce qui est pour la théorie. Comme ça me soule de ne pas savoir quel espace allouer pour 30 Gio, 40 Gio, 50 Gio de disque, j’ai été contraint de faire une petite application en Powershell… Pourquoi changer une équipe qui gagne ?

Application

Je reste un puriste en termes de développement et je ne peux me passer de Windows Powershell ISE⁷. Je sais qu’il existe mieux comme IDE⁸ (Visual Studio Code par exemple) mais je n’arrive pas à me faire à l’idée de quitter ISE…

Cela fait-il de moi un vieux réactionnaire ? Un dev de l’ancien temps ?

Bref, je laisse cette question existentielle en suspens.

Je me suis amusé pour une fois à réaliser une interface GUI⁹ via WindowsForm. Moi l’amoureux du CLI¹⁰ je reconnais mettre amusé. Encore une fois je sais que je ne savais rien et j’ai donc encore appris.

Réaliser une application GUI en plaçant les items au pixel c’est marrant mais vite casse gueule. Cela demande une gymnastique d’esprit qui ne me rebute pas.

Il y a toutefois un bémol non négligeable à l’utilisation de WindowsForm, cela ne permet pas l’opérabilité multiplateforme. Logique puisque WindowsForm fait partie intégrante de Windows, donc pas possible de faire fonctionner ce dernier sous Linux.

Il faudrait donc que je compose un mode de fonctionnement CLI pour assurer l’opérabilité. Cela n’est qu’au final que le développement d’une fonction d’affichage.

La première version de mon application ne se base pas pour l’instant sur un fichier de configuration ce qui implique que les seuils minimums et maximums sont défini en dur dans le code (en tant que constante global tout de même je ne suis pas un sauvage !).

J’offre également la possibilité de définir la taille minimum ou maximum à provisionner.

Pour bien comprendre (c’est un grand mot) je propose la courte vidéo de présentation de la version béta de mon app.

Démonstration

GitHub

Miaou

Conclusion

Qu’il est bon de revenir aux bases. Sans cela, je pense que je n’aurai pas eu l’idée de faire du GUI en powershell depuis mon ISE. Il est vrai que cela permet également de revenir peut-être aux prémices de ce blog qui étaient :

• L’aspect pédagogique
• Aborder les bases
• Réaliser des petits projets
• Sortir des sentiers battus

Ainsi, je renoue avec certaines valeurs laissées de côté dans le cadre des derniers gros projets que j’ai pu mener. Toutefois, je reste une tête de c*n à laisser transparaitre ma désinvolture, sarcasmes et autres tournures de phrases et expressions vitriolés 🙂 (Ce blog et mes articles restent un loisir personnel et cela m’amuse d’user de ma liberté d’expression tout en tachant de rester respectueux).

Bref, il est temps de clôturer ce billet et d’attaquer d’autres thématiques 🙂

Le mot de la fin :

J’ai évalué et calculé mon incompétence, elle est à la hauteur de vos mensonges et de votre lâcheté. Un petit partitionnement de prime et de service ? Vous méritez bien convenablement un pâté lorrain en cadeau ?

Erwan GUILLEMARD

Sources

• Debian : Recommanded Partitioning
• Ubuntu : DiskSpace

1. RHEL : RedHat Entreprise Linux ↩︎
2. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
3. SE : Système d’Exploitation ↩︎
4. GUI : Graphical User Interface ↩︎
5. GRUB : GRand Unifier Bootloader ↩︎
6. BDD : Base De Données ↩︎
7. ISE : Integrated Scripting Environment ↩︎
8. IDE : Integraded Development Environment ↩︎
9. GUI : Graphical User Interface ↩︎
10. CLI : Command Line Interface ↩︎

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

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

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

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

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

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

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

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

XLSXM tien donc ?

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

Pourquoi ?

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

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

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

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

Avant-Propos

Attention, bis repetita en approche…

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

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

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

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

Prérequis

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

Guide

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

Conclusion

Le mot de la fin

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

Erwan GUILLEMARD refondu de Charles BAUDELAIRE

Sources

• VMWare – PowerCLI

Une fois n’est pas coutume, je me réfère aux saintes écritures

Et moi, je te dis que tu es Pierre, et que sur cette pierre je bâtirai mon Église, et que les portes du séjour des morts ne prévaudront point contre elle.

Matthieu, 16:13:18

De ce verset, je bâti donc le mien

Et moi, je te dis que tu es SS_034, et que sur cette application je bâtirai mes KPIs, et que les défaillances des jobs de protection ne prévaudront point contre elle.

Le rédacteur de ce billet

Ne voyez pas dans cette reformulation une quelconque provocation de ma part ou quelques pensées négatives quant à mon sarcasme et ironie qui m’habite. J’ai une éducation des plus classiques dans l’ordre mariste. Passons.

Enfin, vous comprendrez mieux je pense l’allusion à la rédaction des articles précédents sur les différents produits VEEAM puisque mon application s’appuie sur ces derniers. Cela à représenter un travail personnel titanesque en dehors de mon activité professionnelle…

Mais c’est quoi ton application SS_034 ou Green Ray ? Et ça sert à quoi ? Quel rapport avec les produits VEEAM ?

Avant de répondre à l’ensemble des questions, la problématique à laquelle j’ai été confronté prends son origine courant mars 2023, dans mon environnement professionnel.

Comment s’assurer de l’état des mécanismes de protection des systèmes d’informations quotidien fournit par les produits VEEAM et établir à partir de ces données des indicateurs de performance afin de s’assurer du bon respect des engagements contractuels interne ou externe.

C’est marrant car je dirai que cette problématique conviendrait pour un mémoire de fin de cycle de 5 année. 🙂

/!\ Spoiler, j’ai non seulement trouvé une solution à cette problématique mais ce dernier a pris une tournure inattendue au cours de ces deux dernières années.

Hé banane, nous nous en doutons sinon tu n’aurais pas pondu un article… Mouai, bà je suis certains qu’il existe déjà des applications ou fonctionnalités internes ou externes à VEEAM qui permet de faire ça ? Tu as réinventé la roue… Encore un article p*te à clic…

C’est vrai que l’argumentaire se tiens, toutefois pouvez vous me sortir les statistiques par jobs ou par organisations sur un mois précis ? Sur 13 mois glissant ? Déduire une tendance ? Allez y je vous regarde 🙂

Donc pour répondre aux 3 questions précédemment énoncées :

• En tant que MSP¹ dans le milieu professionnel, l’usage des produits VCC², VSPC³ pour administrer et gérer les différents serveurs de sauvegarde VBR⁴ ou VB MO365⁵, il est logique que je me concentre sur les solutions de l’éditeur VEEAM. De plus VEEAM s’inscrit depuis la 5 années consécutives comme le leader de la sauvegarde sur le marché.
• L’application développée par mes soins vient collecter, traiter et présenter les données quotidiennes des jobs de sauvegardes tout en garantissant la flexibilité de la solution et la plus grande sécurité possible
• Le nom du projet est SS_034_TOOLS_Backup-Reporting (toujours ma nomenclature personnelle SystemScript numéro 34). Mes proches m’ont fait remarquer à maintes reprises que le nom est difficilement commercialisable. C’est pourquoi Green Ray est plus adapté. En raison d’un relevé quotidien des outils VEEAM d’un vert caractéristique, je me suis dit que cela revenait à guetter le dernier rayon vert du soir 🙂

Tu dis difficilement commercialisable ? Je reviendrai plus tard sur ce point.

Avant-Propos

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

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

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

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

Prérequis

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

Guide

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

Conclusion

Bien, difficile de conclure un projet sur lequel je reste assez nébuleux (mais pas opaque, je tiens à la nuance). Certes il y a la théorie et je garde le guide d’installation dans sa culotte de chasteté, mais la démonstration fait le taf non ? 🙂

Je vois dans cette solution un bon moyen d’assister les RSSIs⁶, DSIs⁷ qu’ils soient internalisés ou non. Cela permet de montrer du concret au DG⁸, DAF⁹ ou PDG¹⁰ quant au travail de longue haleine réalisé par les équipes (oui, on ne va pas se mentir pour le commun des utilisateurs nous sommes désagréables et nous passons nos journées à boire des cafés en nous tirant sur le noeud… Sans oublier les cabinets de recrutement qui trouve normal de nous proposer un salaire confortable de 30-35k€ annuel). Plus sérieusement, cela permet à la direction d’accorder un crédit et de la confiance à ses collaborateurs et d’avoir ainsi une bonne vision de la sécurité de son entreprise.

J’ai malheureusement trop vu de société externalisée ou équipe interne faire preuve de laxisme ou pire maquiller les rapports de sauvegarde et ce à l’insu de leur client ou employeur/repsonbale… Mais bon, c’est triste d’écrire ces mots. La fin justifie les moyens… C’est qu’il faut la décrocher cette prime annuelle…

Je ne peux donc qu’encourager encore une fois les DAF, DSI, DG ou PDG de réclamer les indicateurs des jobs de protection journalier, hebdomadaire, mensuel et annuel. Même si vous ne comprenez pas grand chose, cela reste des chiffres et il est important de savoir pourquoi certaines fois cela n’a pas fonctionné et comment les équipes ont traité le dysfonctionnement. Et il faut faire preuve à certain moment de fermeté et dans d’autres cas être indulgent. Il n’est pas aisé de garder une main de fer dans un gant de velours.

De plus, ces métriques jouent un rôle important auprès de votre assurance en cas de sinistre informatique. En plus je suis quasiment certains qu’une police d’assurance cybersécurité a été souscrit. Le risque zéro n’existant pas, si vous arrivez à prouver que votre sauvegarde tiens la route et fait l’objet d’un point de suivi régulier cela devrait faciliter l’indemnisation du sinistre.

Si nous revenons plus à même du projet Green Ray, la flexibilité de l’application permettant d’interfacer n’importe quelle solution de reporting (puisque que basé sur une BDD¹¹) répond au niveau et compétence de chaque RSI ou DSI. La possibilité d’activer ou non le mode debug facilite la correction d’erreur comme le contrôle dans un fichier de log.

Bien que pour l’instant l’application ne prend en compte que les jobs de protection de type Backup, BackupCopy et Replication ainsi que les jobs de protection pour Microsoft O365, l’application a été pensée pour s’adapter assez rapidement que ce soit aux différents niveaux, de l’acquisition des données à leurs restitutions en passant par leurs traitements. Si ce n’est pas évolutif à quoi bon ? Egalement le fait qu’elle puisse traiter plusieurs organisations permets de répondre à un besoin de fournisseur de service et de faciliter la tâche d’un Responsable des Services Hébergés par exemple <3 (A la limite du narcissisme non ? C’est inquiétant).

Le seul regret que j’ai pour l’instant en ce mois de Mars 2025 reste que le code est écrit en Powershell et non en C#, C/C++ ou VB .NET (PS c’est en .NET non ? 🙂 ). Je pourrais me lancer dans un programme en C/C++ mais pour le coup je suis rouillé. Il serait pas mal d’incorporer le rendu directement dans VEEAM (VEEAM One ou dans la VSPC) mais le produit ne doit pas être ouvert pour réaliser ce type d’opération (et heureusement).

La version béta 2.0 (en dehors de la factorisation du mode service pour éviter la redondance de code) est stable. Je sais qu’il reste des optimisations possibles et de potentiel modules à développer, mais ça l’avenir nous le dira si oui ou non je vais investir de nouveau du temps 🙂 En toutes circonstances je suis bien loin de la version 1.0 à manipuler des CSVs dans un fichier XLSX avec des formules à rallonges !

Le mot de la fin

Mes PKIs ils sont super ! Quand on les refreshent ils sortent. On peut acquisitionner à Quimper ou à Chalon-Sur-Saone. Ils ont l’option… sécurisantes. Qui résonnent dans mon bureau-eau-eau…

Erwan GUILLEMARD refondu de Arne VINZON

Sources

• VEEAM : Leader Gartner

1. MSP : Managed Services Providers ↩︎
2. VCC : VEEAM Cloud Connect ↩︎
3. VSPC : VEEAM Service Provider Console ↩︎
4. VBR : VEEAM Backup et Replication ↩︎
5. VB MO365 : VEEAM Backup for Microsoft 365 ↩︎
6. RSSI : Responsable Sécurité des Systèmes d’Informations ↩︎
7. DSI : Directeur des Systèmes d’Informations ↩︎
8. DG : Directeur Général ↩︎
9. DAF : Directeur Administratif et Financier ↩︎
10. PDG : Président Directeur Général ↩︎
11. BDD : Base De Données ↩︎

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

Ces Judas électroniques étaient inexistant il n’y a pas si longtemps. A défaut d’être chez soi et de lorgner dans le Judas pour vérifier qui frappe à la porte (ou s’abandonner au plaisir solitaire du commérage), nous étions bien e******s quand nous n’étions pas chez nous. D’où les systèmes d’alarmes, sirènes qui hurlent et c*****t les c******s du voisinage.

A partir de ce postulat et avec un peu d’imagination, mon domicile c’est mon serveur LINUX. Se pose la question de vérifier qui frappe à la porte, qui rentre, qui rentre pas. Qui se fait kick par Jean-Pierre, notre bon chien (plus petit que Cerbère quand même car il bouffe ce c*n) quand je ne suis pas scotché sur mon système le nez dans mes journaux de log.

Une nouvelle fois je me suis tourné vers une solution purement personnelle. Pourquoi ?

Parce que j’ai pas trouvé chaussure à mon pied…

Afin de répondre à cette question, je vais vérifier si des utilisateurs sont lock et envoyer une notification mail à l’équipe en charge du MCO du serveur. Si ça ne suffit, pas, le mail reviendra tant que le compte n’aura pas été unlock.

Plusieurs raisons peuvent être dû au verrouillage d’un compte :

• Syndrome des doigts palmés
• Oublie du login, password
• Compte non habilité à se connecter
• Tentative d’intrusion

Dans la majorité des cas, il résulte du syndrome du palmipède. Le compte est rapidement déverrouillé (par un autre compte ou par un autre biais). Dans le dernier cas, il convient d’éplucher les journaux et de mettre rapidement des mesures pour isoler et interdire les IPs sources ayant tenter de s’authentifier. D’aller consulter son Responsable Sécurité pour engager les actions nécessaires en adéquations selon le risque couru.

Prérequis

• RHEL, Debian, Ubuntu
• Mutt, cyrus-sasl-plain, Faillock

Locked Account & Notifications

Installation et configuration de MUTT

Concernant cette partie, je vous invite à parcourir la section déjà documentée dans l’article Apps – MUTT.

Configuration de Faillock

Le module faillock vient remplacer le module pam_tally2 devenu obsolète il y a un petit moment déjà. Il est présent nativement sur quasi tout les systèmes à ce jour.

Je ne traite pas volontairement dans cette partie de la politique de mot de passe. Cela fera parti d’un autre article à la limite de l’indigeste.

Il va être nécessaire de modifier les fichiers password-auth et system-auth du module d’authentification.

password-auth

Editer le fichier password-auth

$ sudo /etc/pam.d/password-auth

Ajouter les lignes suivantes dans le fichier

1) auth        required      pam_faillock.so preauth audit silent deny=5 unlock_time=900

2) auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900

3) account     required      pam_faillock.so

La première ligne assure que l’utilisateur à 5 tentatives de connexion avant de voir son compte verrouillé pour une durée de 15 minutes. Nous choisissons de logger l’information et de ne pas indiquer que le compte est désactivé.

La seconde ligne indique qu’en cas d’échec de la ligne précédente, le compte sera locked.

La troisième ligne indique que le module d’authentification faillock et requis.

system-auth

Editer le fichier system-auth

$ sudo /etc/pam.d/system-auth

Ajouter les lignes suivantes dans le fichier

1) auth        required      pam_faillock.so preauth audit silent deny=5 unlock_time=900

2) auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900

3) account     required      pam_faillock.so

Les explications sont les mêmes que pour le module précédent.

Test

Vérifions que les modifications apportées ont bien été prise en compte. Pour se faire nous allons vérifier l’état des comptes Valid

$ sudo faillock

Volontairement nous allons verrouiller le compte adm.r-one. Il est nécessaire d’avoir un second shell d’ouvert en parallèle pour déverrouiller le compte ou de passer par la console système en root directement.

Ou encore, en dernière option d’attendre 15 minutes.

Nous allons libérer l’utilisateur adm.r-one puis vérifier que ce dernier est bien unlocked.

$ sudo faillock --user adm.r-one --reset
$ sudo faillock

Configuration et installation du Script

J’ai toujours pour habitude de positionner mes scripts à la racine du système 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 potentiel des droits.

$ sudo mkdir /script
$ sudo mkdir /script/SS_027-LINUX_LockAccount

Editez le fichier ou copiez le fichier suivant : SS_027_D_LINUX_LockAccount.sh

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

• Les constantes
• Une fonction vérifiant l’OS
• Une fonction vérifiant les derniers logon authentifiés avec succès (utilisateurs et services)
• Une fonction vérifiant les comptes verouillés
• Une fonction pour préparer le mail
• Une fonction d’envoi de mail
• Une fonction pour forger le mail en html

Comme tous mes autres outils, les premiers échanges de mails se sont fait au format texte brut, puis pour un soucis de compréhension j’ai dû passer au format HTML…

Il est encore trop tôt pour expliquer cette aversion personnel pour le monde du web… Mais passons, il est donc possible d’envoyer les notifications sous les deux formats.

Pour le script, comme pour mon premier article sur le sujet je ne souhaite pas pour l’instant rendre ce dernier accessible à la disposition de tous.

Couvrez ce code que je ne saurais voir. Par de pareils objets les AdminSys sont blessées, Et cela fait venir de coupables pensées…

Molière 2.0

Et surtout cela me demanderai de configurer mon GitHub, de soigner mon code etc.

So, comment le code fonctionne ? De la plus simple des façons.

Le code va vérifier la version du SE, puis vérifier si des comptes sont verrouillés ou non. Si un des comptes est verrouillés, nous récupérons ces derniers. Nous récupérons la date de la dernière fois que tous les comptes se sont connectés (afin de contrôler qu’il n’y a pas de Léviator sous Racaillou). S’ensuit la préparation du mail, le « forgeage » puis l’envoi.

Dans le cas où aucun compte n’est verrouillé, le code ne fait rien.

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

$ sudo ls -ahl /script/SS_027-LINUX_LockAccount/

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

Configuration du cron

Comme nous voulons une alerte plutôt réactive, mais qui ne spam pas trop non plus, j’aime par confort définir une vérification toutes les 3 minutes. Libre à chacun de faire comme il le souhaite.

# vim /etc/crontab

Ce qui nous donne dans notre BAL, lorsqu’un compte est verrouillé la notification ci-dessous.

Conclusion

La roue a dû encore une fois être réinventée. Mais cette solution me convient et répond à mon besoin.

Nous revenons toujours sur ce curseur bénéfices, risques que cette solution apporte.

Si niveau système, la configuration et l’usage du module faillock dans les modules d’authentifications relève de la bonne pratique, ma solution pose question.

Avantages

• Suivi des alertes quasi en temps réel sur lock du compte

Inconvénients

• Utilise le compte root pour la tâche planifiée
• Repose sur un paquet, application tiers « MUTT »
• Doit être ajusté selon les SEs qui ne sont pas pris en charge
• S’assurer que le script n’est pas altéré

Au delà des axes récurrents d’améliorations, nous comptons plus d’inconvénients que d’avantages. Le point le plus bloquant selon moi est que tout repose sur le daemon assurant les notifications mails. Si le daemon vient à planter ou à être la cible d’un individu malveillant rendant ce dernier inopérant, l’attaquant a le champ libre.

Dans un sens si nous revenons à notre analogie initiale du serveur et de notre maison, l’individu malveillant nous à couper notre système d’alarme, internet et électricité ect.

Nous devons donc coupler des mécanismes de sécurité supplémentaires en amont et aval de notre serveur.

Le mot de la fin :

J’Houdini ma twingo et pars avant l’orage. Vous ne pouvez pas vous êtes faillock avec Francis Huster pendant deux madeleines

Erwan GUILLEMARD

Sources

• Faillock
• Mutt