Pourquoi ?

Parce que tout ou une grande partie à déjà été dit dans l’article traitant d’Ollama. J’avais jugé trop indigeste de fondre les deux sujets. Donc ici, la partie théorie sera plutôt courte et en conséquence la partie Pratique un peu plus étoffée concernant l’implémentation et la configuration de l’application.

Bref, l’objectif de cet article sera d’implémenter une interface graphique publiée pour faciliter l’usage de notre solution Ollama plurimodales (LLM¹) aux utilisateurs. J’ai pris le parti d’utiliser la solution OpenWebUI.

Avant-Propos

Vous l’avez bien compris, dans l’introduction, je n’ai pas l’attention de m’éterniser 10 000 ans sur le sujet.

Je pars du principe que nous avons déjà déployé et configuré la solution Ollama et quelques modèles de traitement IA² sur un serveur.

J’ai une nouvelle fois pris le parti de déployer l’application sous une distribution RHEL³ afin d’avoir un niveau de sécurité optimale. Toutefois et vous pourrez le constatez par la suite dans la partie théorie, je ne respecterai pas l’architecture par faute de ressource disponible néanmoins, je recommande de suivre l’architecture qui sera à venir.

Dans le cadre d’une solution d’IA hébergée localement se pose la question de mettre en place un tel portail dans une organisation. A cela je répondrai que cela permettra de garder un certain contrôle des requêtes, prompts, effectués par l’ensemble des utilisateurs de l’organisation et d’en faciliter les usages. Dans des domaines sensibles tels que l’industrie et production cela peut aux yeux de la direction et de la DSI⁴ se révéler rassurant.

Prérequis

• SE :
  • Rocky Linux 9.x et version ultérieures (pour ma part ça sera du 10.x)
  • macOS
  • Windows
• Apps : 
  • Ollama
• Autres :
  • Minimum 4 CPU⁵
  • Minimum 4 Gio de RAM⁶
  • Stockage rapide (SSD⁷ ou Nvme)

Théorie

KesaKo OpenWebUI

Je pense comme toujours qu’il est important de se poser la traditionnelle question. Que fait l’application que nous allons utiliser, comment elle fonctionne et qui est derrière.

Qu’est-ce que c’est ?

OpenWebUI, c’est une interface web issue d’une projet open-source (#biscotto) qui permet d’utiliser des modèles d’IA depuis un navigateur WEB hébergé localement.

Le projet est né du sud-coréen Tim Jaeryang BAEK qui prône l’autonomie numérique face aux grands du monde de la tech. Le projet est développé en Python (version supérieur ou égale à 3.11) pour la partie BackEnd et HTML/CSS, Svelte, JS et TS pour la partie FrontEnd.

Personnellement, je trouve que l’interface ressemble fortement à celle de ChatGPT. Mais son mon avis personnel hein 🙂

A quoi ça sert ?

La solution va permettre comme les outils classiques en ligne (pour ne pas dire les géants du Cloud) d’effectuer des opérations (énumération en approche) :

• Discuter avec des modèles d’IA (LLM)
• Exploiter des modèles localement (LLM)
• S’Interfacer avec des sources locales et clouds (et oui nous pouvons faire de l’hybridation).
• Téléverser (waouh, tu n’as pas écrit uploader !) des fichiers pour les analyser par l’IA

Nous retrouvons donc dans l’ensemble les mêmes fonctionnalités que les outils en ligne quant à l’usage de l’IA 🙂 C’est cool non ? <3

Avantages / Inconvénients

L’utilisation d’OpenWebUI n’est pas sans conséquences vis à vis des services qu’il peut apporter.

Il suffit de regarder le constat déjà porté sur l’utilisation d’Ollama.

Bon, cela je vous dirai l’utilisateur il s’en tamponne le coquillard. Lui que ce soit technique à mettre en place, il s’en lustre l’asperge. Par contre, si la réponse est lente, c’est le Game Over.

Logique, pourquoi utiliser la solution locale qui met une plombe à répondre alors qu’un bon vieux Gémini, Copilot, ChatGPT te donne la réponse en 1/4 de seconde après une petite pression sur la touche Enter du clavier ?

Ce qui nous ramène selon moi à l’un des plus grands maux de la société actuelle. Nous ne savons ce que signifie attendre et être patient. Si dans les années 60 la compilation d’un programme pouvait prendre la nuit, aujourd’hui cela prendra quelques minutes. L’essor des nouvelles technologies, nous apportent de par les performances et leurs mobilités l’informations et l’assurance de pouvoir joindre un individu ou une ressource si quand bien même nous avons du réseau. Toutefois, force est de constaté que si comme cela s’est passé plusieurs fois au cours de l’année 2025 et 2026 l’un des maillons qui assure le fonctionnement tombe et nous coupe de nos ressources, nous nous retrouvons comme une poule qui a trouvé un couteau. Je pense et cela n’est qu’un point de vue personnel que nous devrions nous remettre en question face à cette forme de dépendance et servitude, Master & Servant, je dis STOP ! #sendkissesagain

Architecture & Best Pratices

Lors de la présentation de la solution, j’ai introduit la possibilité d’utiliser OpenWebUI en mode hybride. Ce qui implique donc une communication des flux sortants via les protocoles HTTP⁹ et HTTPS¹⁰ vers les IAs compatibles dans le cloud et autres repos propres au SE¹¹ et maintien de l’application. Afin de ne pas surcharger inutilement le schéma, j’ai totalement exclu cette partie. Néanmoins il conviendra de réaliser un filtrage strict en sortie des flux pour des raisons de sécurité. Donc de jouer avec les politiques de votre UTMs¹².

Bien, rentrons concrètement dans l’architecture. La solution applicative OpenWebUI vient se placer entre le poste client et l’application Ollama.

Il convient dans le respect des bonnes pratiques de dissocier OpenWebUI de Ollama puisque nous allons publier, ouvrir l’application en interne et pourquoi pas depuis nos WANs¹³. Cela implique de mettre OpenWebUI dans un réseau isolé (DMZ¹⁴) et Ollama dans le réseau T1, T1′ par exemple.

Par défaut, dans un fonctionnement UNIX dans un déploiement hors Docker, le port de communication de l’interface Web se fait via le protocole http sur le port 8080. Il est néanmoins possible de forcer les connexions en https sur le port 443 via nginx (je reviendrai plus en détail sur ce point).

Si nous regardons d’un peu plus près l’architecture de la VM¹⁵, nous pouvons constater que j’ai dédié un disque. Mais pourquoi ?

OpenWebUI est très très lourd. Son déploiement peut se révéler un poil pénible pour ne pas dire chiant à mourir (je reviendrai là-dessus dans la partie pratique).

Bref, pour pallier à ce problème, j’ai dédié un disque d’une capacité de 100 Gio.

Bien, on se lance dans la pratique ? Après on est bien aussi ici 🙂

Pratique

Oui j’ai dit plus haut que je ne respecterai pas cette topologie. Par manque de ressource, je vais tailler à la hussarde et tout mutualiser sur une seule machine. Il faut bien faire avec les moyens que l’on a, c’est comme ça.

Installation

OpenWebUI propose plusieurs modes de déploiement :

• Docker : Officiellement supporté et recommandé pour la plupart des utilisateurs (avec plusieurs sous-catégorie alternatives de déploiement)
• Python : Orienté pour les environnements faibles en ressources et pour une installation manuelle
  • uv
  • conda
  • venv
• Kubernetes : Idéal pour les déploiements en entreprise qui nécessite une adaptabilité et ordonnancement
  • Helm
• Third Party

Pour ma part, la seule chose qui m’intéresse et pour laquelle je suis à peu près à l’aise c’est Python. Je vois déjà les puristes de la containerisation me rétorquer sauvagement « Pourquoi pas Docker ?« . Encore une fois et je suis désolé, je ne comprends pas l’intérêt de Docker dans mon métier. Tant que je n’aurai pas pleinement assimilé ou eu le besoin de l’utilisé, je bloque. Attention, je ne dis pas que c’est de la me*de hein ? Loin de moi l’idée.

Donc je partirai sur Python en environnement virtuel (venv).

Pourquoi ce choix ? Simplement parce que RHEL utilise également Python dans une version différente et qu’à ce jour la version 3.12 n’est pas encore officiellement supporté par OpenWebUI… Rien que pour ça je déteste Python autant que Java. Pourquoi faire simple…

Création de l’environnement virtuel

Dans mon répertoire ollama, j’ai créé un second répertoire openwebui.

$ sudo mkdir -p /mnt/ollama/openwebui
$ sudo cd /mnt/ollama/openwebui/

Une fois déplacé dans le répertoire, nous créons l’environnement virtuel venv. Original comme nom n’est il pas ?

$ sudo python3 -m venv venv

Activation de l’environnement virtuel

Etant toujours dans le même répertoire créé précédemment, nous allons activer notre environnement virtuel.

$ sudo source venv/bin/activate

Installation

Maintenant que tout est bon, il est toujours dans notre environnement virtuel de démarrer l’installation. Cette dernière se déroulera en 3 temps.

• La mise à jour de pip
• La création d’un répertoire temporaire pour stocker les sources de l’installation qui sont plutôt volumineuse
• L’installation en faisant référence à notre répertoire temporaire

Simple comme bonjour, et pourtant sachez que je me suis bien cassé la tête pour trouver l’astuce du répertoire temporaire…

$ sudo pip install --upgrade pip 
$ sudo mkdir /mnt/ollama/tmp
$ sudo TMPDIR=/mnt/ollama/tmp pip install open-webui

Lors de l’installation si comme moi vous avez des ressources limitées, aucun respect des préconisations matériels. Je vous recommande de tuer le temps pendant facile une heure et de laisser tranquille votre bécanne. Tiens, je reparle de patience, comme de par hasard 🙂

Sans hésitez, la réponse D Jean-Pierre, ça sera mon dernier goulot.

Blague mise à part, 291 packages à installer avec des grosses dépendances pour certains d’entre eux (Nvidia par exemple…). Reprenez un peu de la réponse D en attendant.

Toujours pas terminé ? Bon ba comme on dit j’ai nous « On va pas la mécher [la bouteille naturellement] », terminez là et allez en chercher une nouvelle pour poursuivre la connaissance de la réponse D.

Démarrage

Si vous n’êtes pas tombé et que vous n’êtes plus très sobre, c’est bon signe. 🙂 Normalement, l’installation est terminée.

/!\Attention :L’abus des bons produits et notamment d’alcool est dangereux pour la santé. (Que l’on n’aille pas dire que je fasse de la publicité ou l’apologie de l’alcool #loievin)

Vérifions que cela fonctionne avec la première commande.

$ sudo open-webui --help

C’est rassurant de se dire que cela fonctionne. Pas de message d’erreur. Il ne nous reste maintenant plus qu’à démarrer notre service sur son interface et son port avec la commande ci-dessous.

$ sudo open-webui serve --host 10.227.250.11 --port 8080

Toutefois, il conviendra d’autoriser les flux au niveau de l’UTM local à notre serveur en amont. Pour cela, j’explique dans la partie suivante Configuration comment ouvrir les flux http sur le port 8080/tcp.

Normalement, l’ensemble des composants sont en cours de chargement et une fois l’ensemble chargé, vous devriez avoir dans votre CLI¹⁶ la chose suivante.

Il est à noter que des notes d’informations vont vite prendre le relai, ces derniers affichant l’ensemble des requêtes HTTP.

Si nous sommes à ce stade c’est que tout est bon 🙂 Avant de rentrer plus en détail de l’outil, il est nécessaire de regarder la partie Configuration.

Configuration

Cette partie pourrait je pense être amélioré. L’un des points les plus complexes et de mettre en place le mode service (j’y ai passé un temps certain…).

Utilisateur dédié

Pour des raisons de sécurité, il convient de créer un utilisateur dédié pour notre application. Nous partons sur un compte de service et non un compte utilisateur.

$ sudo useradd -r -s /bin/false openwebui
$ sudo chown -R openwebui:openwebui /mnt/ollama/openwebui

Un petit changement de propriétaire et le tour est joué.

ParFeu

Par défaut, le port qui sera utilisé pour accéder à l’interface web d’OpenWebUI est 8080/tcp en http.

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

On est d’accord que si nous souhaiterions mieux faire en termes de sécurité, il serait plus intelligent de créer la policy suivante :

$ sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.127.50.0/24" port port="8080" protocol="tcp" accept'
$ sudo firewall-cmd --reload

Ayant un UTM en amont, je me permets donc de me contenter de la première solution.

Un petit test de vérification depuis le poste source :

Mode Service

Commençons par créer notre fichier de service. La difficulté que j’ai rencontrée ici est de jouer avec l’environnement virtuel et le service OpenWebUI à démarrer. J’ai bien trouvé une solution de contournement à mon problème toutefois cela me laisse un gout amer car la solution ne me semble pas propre du tout.

C’est je pense l’un des points qui me frustre le plus dans le monde du libre, l’imbrication de solution tierce et dans un sens une non-standardisation des méthodes d’implémentations. Bien que je doive le reconnaitre c’est ce qui fait tout son charme. Je t’aime moi non plus. On se croirait dans Andromaque…

$ sudo vim /etc/systemd/system/openwebui.service

Regardons d’un peu plus près le contenu de ce fichier. Nous retrouvons la description de notre service ainsi que son ordre de démarrage. OpenWebUI étant intimement lié à Ollama, il convient donc de définir ce dernier comme service requis. Au niveau du service, nous sommes sur un type simple, le service étant exécuter par l’utilisateur dédié openwebui. Il peut être acceptable bien que s’est sacrément cochon d’utiliser le compte root. Mais bon nous voulons éviter de faire étalage de notre amateurisme. WorkingDirectory représente le répertoire de travail dans lequel le programme sera exécuté. Environment permet de définir les variables d’environnement. ExecStart permet d’exécuter la commande. Dans mon cas, j’en ai deux dont une qui est commentée (et qui ne fonctionne pas). Restart permet de définir le rédémarrage automatique dans le cas où le service viendrait à crash par exemple. RestartSec défini le délai de redémarrage en seconde. Et pour finir, WantedBy pour spécifier le mode de service. Ici cela équivaut au mode normal.

[Unit] Description=Open WebUI Service After=network.target ollama.service Requires=ollama.service [Service] Type=simple User=openwebui WorkingDirectory=/mnt/ollama/openwebui Environment="TMPDIR=/mnt/ollama/tmp" Environment="PATH=/mnt/ollama/openwebui/venv/bin:/usr/bin:/usr/sbin" #ExecStart=/mnt/ollama/openwebui/venv/bin/open-webui serve --host 10.227.250.11 --port 8080 ExecStart=/bin/bash -c 'source /mnt/ollama/openwebui/venv/bin/activate && open-webui serve --host 10.227.250.11 --port 8080' Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

Comme nous venons de créer un nouveau service, il sera nécessaire de recharger l’ensemble du systemctl pour intégrer le nouveau service à la liste des services disponible. Après, j’ai envie de dire c’est le schéma classique d’activation, démarrage et vérification.

$ sudo systemctl daemon-reload
$ sudo systemctl enable openwebui
$ sudo systemctl start openwebui
$ sudo systemctl status openwebui

Nginx, HTTPS

Je suis partagé quant à la rédaction de cette sous partie. Oui il est important de sécuriser l’accès à l’interface Web, mais j’ai peur d’être hors sujet et d’alourdir l’article. Mais d’un autre côté, je ne veux pas non plus bâcler la chose… Encore un pu**n de choix cornélien…

Bref, je vais faire au plus simple et si besoin écrirai un billet sur Nginx.

Installation

L’installation et activation du service, je passe mon tour.

$ sudo dnf install nginx
$ sudo systemctl enable nginx
$ sudo systemctl start nginx

Certificats

Là encore une fois je rencontre un petit problème. Je n’ai pas de certificat public que je pourrais utiliser, ma topologie réseau ne me permet pas d’utiliser un certificat Let’s Encrypt et sans vouloir spoiler je n’ai pas envie de me prendre la tête. Donc ça va finir avec un bon vieux certificat autosigné 🙂

La génération n’est pas bien compliquée et si besoin, j’ai déjà rédigé un article sur le sujet.

Créons le répertoire qui va contenir nos éléments de sécurité :

$ sudo mkdir -p /etc/nginx/ssl

Générons notre certificat :

$ sudo openssl req req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/nginx/ssl/openwebui.key \
-out /etc/nginx/ssl/openwebui.crt

Configuration

Créons et éditons notre fichier de configuration. Je prendrai le temps d’expliquer l’intégralité du fichier de configuration.

$ sudo vim /etc/nginx/conf.d/openwebui.conf

server {
    listen 80;
    server_name 10.227.250.11;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name 10.227.250.11;

    ssl_certificate /etc/nginx/ssl/openwebui.crt;
    ssl_certificate_key /etc/nginx/ssl/openwebui.key;

    # TLS sécurisé
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;

    # sécurité headers
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    # taille upload
    client_max_body_size 100M;

    # compression
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml;

    location / {

        proxy_pass http://10.227.250.11:8080;

        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket support (important OpenWebUI)
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

La première section permet de réaliser la redirection du protocole HTTP vers HTTPS de manière permanente. Ainsi si je contacte l’url http://10.227.250.11, je serais automatiquement redirigé vers https://10.227.254.11.
Le second bloc indique que nous écoutons sur le port 443 sur l’interface 10.227.250.11. L’emplacement des fichiers contenant la clé privée ainsi que le certificat sont spécifiés pour activer la couche de sécurité (j’ai l’impression d’enfoncer des portes ouvertes…). J’indique qu’elles sont les versions des protocoles TLS17 autorisées et laisse le serveur choisir le chiffrement le plus sûr. Côté en-tête, j’ai repris les suggestions de sécurité implémentée pour ITOP. Soit la restriction de mettre le site en iframe externe, de restreindre le navigateur à deviner le tye MIME qui est utilisé et surtout d’activer la protection anti-cross-site scripting. Niveau upload, j’ai vu large et j’ai autorisé le téléversement de fichier de 100 Mio. Côté performance, j’ai activé la compression des flux pour optimiser un peu les performances réseaux.
Le troisième bloc concerne la partie Reverse Proxy. Toutes les requêtes qui sont envoyées sur https://10.227.250.11 sont redirigées vers le port 8080. Concernant les en-têtes il est nécessaire d’utiliser les websockets car seront transmis l’ip du client, le protocole utilisé et le NDD18 ou l’IP demandé. Les deux lignes suivantes permettent de réaliser la jonction entre nginx et les websockets.

Une fois la configuration faite, il est important de réaliser un petit contrôle de notre petit fichier afin de s’assurer que ce dernier ne comporte pas d’erreur.

$ sudo nginx -t 

Il faudra penser à recharger la configuration et hop le tour est joué.

Sécurité

Nous souhaitons toujours publier notre interface web en HTTPS. Donc il va falloir jouer avec nos UTMs !

Sur le plan interne, autorisons nos flux https :

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

Nous pourrions comme énoncé plus haut pour le protocole HTTP être bien plus rigoureux dans notre règle de sécurité. Mais encore une fois ayant un UTM en amont, j’accepte le risque. Juste ne pas oublier de créer la règle sinon vous passez pour un c*n.

Si nous sommes joueurs, nous pouvons essayer de joindre directement notre interface web depuis notre navigateur. Normalement vous devez vous prendre dans les dents

Ca vous fait la b**e hein ? Je vous rassure je me suis pris la même rouste. J’ai oublié d’autoriser le contexte de mon SELinux pour autoriser les services http à accéder aux réseaux 😀

$ sudo setsebool -P httpd_can_network_connect 1

Un petit F5 et hop c’est tout bon <3

Normalement avec toutes nos actions, nous devons joindre notre interface web depuis un navigateur de manière sécurisée (hormis l’erreur liée à notre certificat autosigné). Allez, on passe à la partie démonstration ?

Démonstration

Pour le test, j’ai décidé de changer un peu de format et de passer par des formats vidéo. Surtout que dans ce cas précis, cela évitera de mon côté de blablater. Cependant, ce n’est pas pour autant que le travail est plus simple ou plus rapide.

J’ai également pris le parti de commenter mes enregistrements et vidéos en anglais (oui même avec mon anglais aussi rouillé qu’une vieille cantine de bidasse, si vous voulez trikitez mes vidéos je vous laisse ce plaisir 🙂 ).

Conclusion

La combinaison des solutions OpenWebUI et Ollama fonctionne à la perfection. Si nous associons le côté multimodèle d’Ollama et son fonctionnement hybride avec la puissance de l’interface OpenWebUI il est alors possible de fournir une solution complète à destination des utilisateurs.

Toutefois, je reste profondément frustré pour l’instant. L’ajout de la couche OpenWebUI vient rallentir et allourdir l’usage d’Ollama. D’un autre côté, est ce vraiment pertinent comme remarque à savoir que je ne réponds à aucun prérequis matériel ? C’est là où le bât blesse encore une fois. Cela fonctionne mais à quel prix ?

Il est également important de prendre en compte les couts annexes et variables (comme au hasard, la consommation électrique, refroidissement…) périphériques à l’usage de l’IA. Nous parlons du réchauffement climatique, de limiter nos émissions de carbone et j’en passe pour d’un autre côté user de l’IA à tort ou à raison. Je ne tiens pas à lancer un débat climatosceptique ou sur est-ce bien ou non d’utiliser l’IA.

Je pense simplement qu’il y a encore beaucoup à faire pour accorder en synergie la puissance et l’usage de l’IA avec les convictions écologiques et environnementales. Si nous être vivant allons avoir chaud, que dire des CPUs/GPUs ? #tousdanslemêmebateau Bref, un moratoire serait nécessaire en somme. Mais je laisse ça au pisse violon que je suis.

Je reste convaincu de la fiabilité et viabilité de la solution dans un milieu professionnel, malheureusement, pour moi je préfère me passer de l’interface Web. Donc en d’autres termes, je vais rollback mon snapshot (ou restaurer mon backup au choix). Après tout, je peux toujours utiliser l’interface CLI directement depuis une session SSH¹⁹ ? Oui mais pas que.

Pourquoi ne pas faire une petite interface qui exploite l’API Ollama ?

Ah nous y voila ! Ca sent le projet long comme un jour sans pain encore en approche. Blague mis à part, peut être que cela n’aboutira pas. Mais j’ai envie de pousser relativement loin la solution Ollama.

Pour faire vraiment simple. OpenWebUI c’est supercool mais il faut les ressources pour pouvoir l’utiliser pleinement pour ne pas souffrir d’une grande frustration. 🙂

Le mot de la fin :

Je branche OpenWebUI sur une prise RJ45 en camembert ! Je contre avec un lama qui compile une girafe. Vous ne pouvez pas, il y a Sandrine ROUSSEAU au festival de la tête de veau.

Erwan GUILLEMARD

Sources

• OpenWebUI : Quick Started

1. LLM : Large Language Models ↩︎
2. IA : Intelligence Artificielle ↩︎
3. RHEL : RedHat Entreprise Linux ↩︎
4. DSI : Direction des Services Informatiques ↩︎
5. CPU : Central Processing Unit ↩︎
6. RAM : Random Access Memory ↩︎
7. SSD : Solid State Drive ↩︎
8. GPU : Graphics Processing Unit ↩︎
9. HTTP : Hypertext Transfer Protocol ↩︎
10. HTTPS : Hypertext Transfer Protocol Secure ↩︎
11. SE : Système d’Exploitation ↩︎
12. UTM : Unified Threat Management ↩︎
13. WAN : Wide Area Network ↩︎
14. DMZ : DeMilitarized Zone ↩︎
15. VM : Virtual Machine ↩︎
16. CLI : Command Line Interface ↩︎
17. TLS : Transport Layer Security ↩︎
18. NDD : Nom De Domaine ↩︎
19. SSH : Secure SHell ↩︎

Robot : nom masculin, du tchèque robota, travail forcé, mot créé en 1920 par K. Capek.

Dans les œuvres de science-fiction, machine à l’aspect humain, capable de se mouvoir, d’exécuter des opérations, de parler.

Appareil automatique capable de manipuler des objets ou d’exécuter des opérations selon un programme fixe, modifiable ou adaptable.

Définition Larousse

Au vu du titre de cet article et de la définition posée précédemment, difficile de ne pas deviner le sujet qui va être abordé.

Hé oui, moi le puriste, je vais parler d’IA¹ et pire que cela l’utiliser de manière récurrente. Je me sens en ce moment comme le capitaine Haddock face au lama dans l’œuvre d’Hergé, Tintin et le temple du soleil.

Naturellement, au vu de mes précédents écrits, c’est vous lecteurs et l’ensemble des solutions IA qui me crachent dessus. C’est l’arroseur arrosé en somme, moi qui ne voulais pas entendre parler de ça…

Mais alors pourquoi un tel revirement de situation M’sieur GUILLEMARD ?

Je pense qu’il faut vivre avec son temps et ignorer cet outil technologique serait signer mon arrêt de mon mort d’ici quelques années et devenir un être never been à défaut d’has been…

Après tout Errare humanum est, perseverare diabolicum² non ?

Avant-Propos

J’ai pris le parti d’être méfiant vis à vis des outils d’IA en ligne gratuit ou du moins libre d’utilisation.

• ChatGPT
• Gemini
• Copilot
• Claude
• …

Je ne me mouille pas trop dans les moteurs d’IA…

Dire que je n’ai jamais utilisé l’un de ces moteurs serait me parjurer et il faut reconnaitre qu’il y a un côté pratique. Difficile une fois avoir gouter à la simplicité pour ne pas l’utiliser à tout va pour tout et rien. C’est là pour moi le piège de la pauvreté intellectuelle. Comme toutes les bonnes choses il faut savoir ne pas en abuser.

En dehors de l’aspect social et sociétal qui me préoccupe tant, se pose la question des données saisies dans le moteur de recherche ou plutôt de prompt.

• Que deviennent les données saisies ?
• Que deviennent les données retournées ?
• Combien de temps sont conservés ces données ?
• A qui profitent ces données ?
• Qui sur surveillent les données ?

Cela fait un bon nombre de question non ? Surtout qu’un grand nombre des acteurs de l’IA sont aux US, Chine etc avec une législation bien singulière. Qui de nos jours lis encore les CGUs³ (et qui les a déjà lus) ?

C’est ainsi que grâce à mon directeur j’ai découvert la solution OLLAMA. Solution open-source qui exécute des modèles d’intelligence artificielle (aussi appelé LLM⁴) localement. Tout de suite, le projet m’a séduit et je me suis demandé

Et pourquoi pas ?

Dans le pire des cas, je mourrai moins c*n ce soir comme dirait un philosophe du cercle familial.

Naturellement, j’ai choisi d’user de OLLAMA sur ma distribution favorite RockyLinux. L’environnement a été préalablement durci.

On se lance dans la théorie puis dans la pratique mes petits Lamas ?

Prérequis

• SE :
  • Rocky Linux 9.x et version ultérieures (pour ma part ça sera du 10.x)
  • macOS
  • Windows
• Apps : 
  • Ollama
• Autres :
  • GPU⁵
  • Minimum 4 CPU⁶
  • Stockage rapide (SSD⁷ ou Nvme)

Théorie

Je vais essayer d’être le moins rassoir possible. Toutefois et encore il est nécessaire d’où nous partons pour en être là maintenant avec l’IA.

Un peu d’histoire

La notion d’intelligence artificielle vient de loin dans notre histoire, puisque l’homme depuis l’antiquité rêve d’objets animés intelligents qui pourraient répondre à ces besoins.

Ce qui est fascinant ce trouve dans les différentes cultures à travers les âges. Que ce soit :

• Les automates d’Héphaïstos dans la mythologie grecque
• La tentation de créé l’Homme servi par l’alchimie aux moyen âge comme la science Talkim du grand savant islamique Jabir ibn Hayyan (Geber en latin), des homoculus par le médecin suisse de conviction chrétienne Paracelse qui s’inspirera des travaux de Zosime de Panopolis sans oublier l’un des plus connue de tous ces automates, le Golem d’argile présent dans le Talmud du judaïsme, créé par le rabbin Maharal pour protéger la communauté juive de Prague face aux multiples pogroms (j’ai d’ailleurs eu la possibilité de visiter le cimetière juif de Prague et de comprendre tout cela).
• Plus tard, nous retrouverons des œuvres telles que
  • Les Aventures de Pinocchio de Carlo Collodi avant d’être adapté en dessin animé par Disney
  • Frankenstein de Mary Shelley
  • Ou encore Deep Blue qui viendra à bout de Garry Kasparov aux échecs.

Bref, tout cela pour dire que depuis l’origine de l’humanité, nous Homme recherchons à créer des objets autonomes et intelligents à notre services. Pour de multiples raisons, défensives, assistanat etc. Le plus troublant, cette pensée de création pourtant contre religieuse et présente dans toutes les cultures et religions portées par ces savants et lettrés (et ça, voyez-vous je trouve ça beau, très beau).

Enfin, il faudra attendre le XXème siècle et l’arrivée des premiers ordinateur programmable pour que l’IA se développe pleinement.

C’est le pionnier et j’oserai dire le père de l’IA John McCarthy qui ouvre la voie, notamment par cette citation :

C’est la science et l’ingénierie de la fabrication de machines intelligentes, en particulier de programmes informatiques intelligents. Elle est liée à la tâche similaire qui consiste à utiliser des ordinateurs pour comprendre l’intelligence humaine, mais l’IA ne doit pas se limiter aux méthodes qui sont biologiquement observables.

John McCarthy – Wikipédia

Le sujet étant réellement complexe, il est difficile de concrétiser et de répondre aux attentes des investissements privés et étatiques durant la période 70 à 80. Ce qui vaudra un ralentissement dans la rechercher et la montée en puissance de l’IA que nous connaissons ce jour en 2026. Et pourtant les théories et grands principes mathématiques et logiques sont établis et adopté par la DARPA⁸. C’est ainsi que s’affronte deux grands systèmes :

Le système logiciste VS Le système neuronale

C’est en 2010, que l’IA fait réellement son entrée dans nos vies du quotidien et dans les différents secteurs d’activités.

Pour entrer davantage dans le détail je vous invite à lire la page wikipédia (cf les sources). J’ai promis de faire court. 🙂

Les modèles d’IA

Les modèles d’IA, c’est un peu comme un oignon, il y plusieurs couches.

Déjà il est important de dissocier le Machine Learning du Deep Learning.

Machine Learning

Le process pourrait se décrire de la manière suivante :

• Phase 1 : Identifier les mots clés fournit en entrée les plus pertinents afin de préparer ces derniers à être analysé. Nous parlons généralement de datasets.
• Phase 2 : Choisir le bon modèle ou algorithme qui sera le plus pertinent à être utilisé selon l’identification des datasets identifiés et analysés.
• Phase 3 : Construire le modèle d’analyse basé sur l’algorithme choisie lors de l’étape précédente.
• Phase 4 : Jouer le modèle sur un ensemble de jeux de données afin d’obtenir plusieurs jeux de données.
• Phase 5 : Utiliser le modèle pour attribuer une note à l’ensemble des jeux de données retournés et fournier des patterns pertinents adaptés aux datasets initiaux.

Deep Learning

Le process pourrait se décrire de la manière suivante :

• Phase 1 : Comprendre le contexte présenté par l’utilisateur et décider ou non si le Deep Learning est nécessaire ou non.
• Phase 2 : Identifier les mots clés fournit en entrée les plus pertinents afin de préparer ces derniers à être analysé. Nous parlons généralement de datasets.
• Phase 3 : Choisir le bon modèle ou algorithme qui sera le plus pertinent à être utilisé selon l’identification des datasets identifiés et analysés.
• Phase 4 : Jouer le modèle sur un ensemble de jeux de données afin d’obtenir plusieurs jeux de données.
• Phase 5 : Compare le modèle ainsi que ces performances face aux données existantes identifiés ou non identifiées avec notre contexte initial.

Pour le comprendre au mieux, il convient de reprendre le Diagramm de Venn pour comprendre comment s’imbriquent ces différentes notions d’apprentissage.

IA : a pour objectif de comprendre le langage humain, de réaliser les analyses prédictives offrir une IHM9 et AGI10. Machine Learning : se compose de l’apprentissage automatique, la clustérisassions, les arbres décisionnels, le SVM11, LLM et NLP12. Réseaux Neuronales : comprend les RAG13 / Finetuning ainsi que les Feed Forward. Deep Learning

Bien que rapide dans la présentation, de ce qu’est l’IA, je pense que nous avons suffisamment d’éléments pour aborder les différents types d’IA.

Toutefois, je suis loin d’être spécialiste de l’IA et mes connaissances théoriques remontent de mes cours de 2014 et de ce que j’ai pu lire et apprendre depuis ces dernières semaines. Je vous invite donc à lire plus en détails son fonctionnement en profondeur.

Bon allez ça sera tout pour l’instant. Regardons de plus prêt Ollama. 🙂

Architecture et Best-Pratices

Ollama étant cross plateform, j’ai pris le parti de déployer ce dernier sous RHEL. Donc le guide va suivre dans ce sens. Ce choix est motivé par mes soins pour garder une meilleure maitrise des ressources qui vont être consommées par le système. Pour MacOS, je ne me prononce pas car je n’utilise pas ce dernier. Sous Windows, je voyais déjà mon petite dernier faire du rodéo sur l’hyperviseur qui gambade dans le couloir au premier prompt soumis… 🙂

Comme énoncé ci-haut, il faut au minimum en ressource : * 4 vCPUs * 16 Gio de RAM * 2 Gio de GPU * Stockage Rapide Malheureusement pour moi, je n’ai pas les ressources nécessaires, mais cela ne m’empêchera pas d’aller au bout des choses. Je propose toutefois de dissocier les modèles et une partie de l’architecture OLLAMA sur un disque dédié pour des raisons de performances lors de la soumissions des prompts et ne pas saturer le disque système. L’accès à l’application se fera par des call API14 sur le port 11434/tcp.

Si nous voulions aller plus loin il serait bien de dédié un disque pour les logs et ainsi améliorer les performances.

Niveau sécurité, je suis resté sur mon durcissement classique et divulgâchage alerte ça fonctionne (Jacques TOUBON, le retour aurait été fier de moi pour ce coup-là !).

Je ne vois plus qu’un dernier point à aborder et nous pouvons passer à la pratique. Oui comme toute bonne chose, il faut faire durer le plaisir. #sendkisses

Conséquences de l’IA

L’IA est à ce jour (2025) adopté par environ 2/3 de la population mondiale que ce soit à des fins professionnels ou personnels dont environ 73% dans le contexte pro. Ainsi, difficile de nier que l’usage particulier et bien au-dessus des institutions organisationnelles.

Comme énoncé bien plus tôt dans cette partie, l’usage est principalement à destination des centres de services et à destination des utilisateurs (chatbots, service clients) 60%, l’automatisation des ventes et marketings 13%, l’optimisation des systèmes IT 9%, l’aide à la décision entre 5 et 10% et la production de contenu entre 5 et 10% également. Bien que mes chiffres date de 2023-2024.

Dans son usage concrets, l’IA est utilisée à 46% pour la recherche d’informations, 43% pour la rédaction de textes et 33% pour de l’analyse ou traduction.

Les estimations à venir d’ici 2030 seraient un usage de l’IA par 80 à 85% de la population mondiale. Cette escalade et course n’est pas sans conséquence sur le plan économique et disponibilité des ressources en termes de composants électroniques.

Qui dit plus d’usage, dit plus de ressource de calcul et donc plus de composants et plus d’énergie. Le système peine à suivre. C’est ainsi qu’en moyenne, l’évolution des couts entre 2024 et 2026 (estimé sur le plan mondial) et de :

• RAM (DDR5) : +170 à +250 %
• SSD : +60 à +100 %
• GPU : +10 à 25 %
• CPU : +0% à +10%

Cela entraine donc une hausse des offres Cloud et service SaaS/IaaS/PaaS/BaaS et j’en passe ainsi que des couts équipements embarquant ce type de composants. Difficile de faire sans IA de nos jours.

Bon c’est promis, passe à la pratique, je ferme la parenthèse que je n’ai jamais ouverte.

Pratique

Avant de se lancer dans l’installation, si je reprends les prérequis énoncés ci-haut, sachez que :

• Je n’ai pas de GPU
• Je n’ai pas de stockage rapide
• Mon hypervisieur est monoprocesseur

Tout pour bien fonctionner en somme 🙂

Installation

L’installation va se dérouler en 2 parties. Une partie pour installer Ollama, une partie pour l’installation des modèles d’intelligence artificielle.

Ollama

Installation

La documentation fournit sur le site est simple et claire. Il suffit alors de télécharger et d’exécuter le contenu du script install.sh.

Vérifier en amont que le paquet zstd est installé sur notre environnement.

$ sudo dnf install zstd

Si nous rentrons plus en détail, les arguments :

• -f : ignore les redirections en cas de retour autre que le code 200 du protocole HTTP¹⁵
• -s : supprime la barre de suppression et rend l’exécution de la commande silencieuse
• -S : indique les erreurs
• -L : permet de suivre les redirections HTTP

$ sudo curl -fsSL https://ollama.com/install.sh | sh

L’installation c’est bien passée. Toutefois, le script nous informe qu’aucun équipement GPU n’a été détecter et donc que les calculs seront effectués par notre CPU. Ce qui va donc être plutôt lent dans mon cas personnel.

Service au démarrage

Nous retrouvons une commande maintenant bien connue dans les environnements RHEL. Ainsi à chaque démarrage de notre système notre daemon ollama va être démarré.

$ sudo systemctl enable ollama

Firewalling

Encore une fois et comme toujours, il est nécessaire d’ouvrir le port 11434/tcp si nous souhaitons joindre l’API depuis l’extérieur (comprendre hors localhost).

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

On est d’accord que si nous souhaiterions mieux faire en termes de sécurité, il serait plus intelligent de créer la policy suivante :

$ sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.127.50.0/24" port port="11434" protocol="tcp" accept'
$ sudo firewall-cmd --reload

Ayant un UTM¹⁶ en amont, je me permets donc de me contenter de la première solution.

HTTP ou HTTPS ?

Un doute m’habite… Le port 11434/tcp, ça ne serait pas du http ?

Bien vu l’aveugle ! Effectivement et niveau sécurité c’est pas super, il faudrait mieux user du protocole https. Pour ça, j’ai une solution passons par un reverse proxy 🙂

Je suis partagé quant à la rédaction de cette sous partie. Oui il est important de sécuriser l’accès à l’interface Web, mais j’ai peur d’être hors sujet et d’alourdir l’article. Mais d’un autre côté, je ne veux pas non plus bâcler la chose… Encore un pu**n de choix cornélien…

Bref, je vais faire au plus simple et si besoin écrirai un billet sur Nginx.

Installation

L’installation et activation du service, je passe mon tour.

$ sudo dnf install nginx
$ sudo systemctl enable nginx
$ sudo systemctl start nginx

Certificats

Là encore une fois je rencontre un petit problème. Je n’ai pas de certificat public que je pourrais utiliser, ma topologie réseau ne me permet pas d’utiliser un certificat Let’s Encrypt et sans vouloir spoiler je n’ai pas envie de me prendre la tête. Donc ça va finir avec un bon vieux certificat autosigné 🙂

La génération n’est pas bien compliquée et si besoin, j’ai déjà rédigé un article sur le sujet.

Créons le répertoire qui va contenir nos éléments de sécurité :

$ sudo mkdir -p /etc/nginx/ssl

Générons notre certificat :

$ sudo openssl req req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/nginx/ssl/ollama.key \
-out /etc/nginx/ssl/ollama.crt

Configuration

Créons et éditons notre fichier de configuration. Je prendrai le temps d’expliquer l’intégralité du fichier de configuration.

$ sudo vim /etc/nginx/conf.d/ollama.conf

#server {
#    listen 80;
#    server_name 10.227.250.11;
#
#    return 301 https://$host$request_uri;
#}

server {
    listen 11444 ssl;
    http2 on;
    server_name 10.227.250.11;

    ssl_certificate /etc/nginx/ssl/ollama.crt;
    ssl_certificate_key /etc/nginx/ssl/ollama.key;

    # TLS sécurisé
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;

    # sécurité headers
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    # taille upload
    client_max_body_size 100M;

    # compression
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml;

    location / {

        proxy_pass http://10.227.250.11:11434;

        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_buffering off;

        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

La première section permet de réaliser la redirection du protocole HTTP vers HTTPS de manière permanente. Ainsi si je contacte l’url http://10.227.250.11, je serais automatiquement redirigé vers https://10.227.254.11. Toutefois, la section est commentée car elle entre en conflit avec une autre configuration d’un billet à venir 😉
Le second bloc indique que nous écoutons sur le port 11444 sur l’interface 10.227.250.11. L’emplacement des fichiers contenant la clé privée ainsi que le certificat sont spécifiés pour activer la couche de sécurité (j’ai l’impression d’enfoncer des portes ouvertes…). J’indique qu’elles sont les versions des protocoles TLS17 autorisées et laisse le serveur choisir le chiffrement le plus sûr. Côté en-tête, j’ai repris les suggestions de sécurité implémentée pour ITOP. Soit la restriction de mettre le site en iframe externe, de restreindre le navigateur à deviner le tye MIME qui est utilisé et surtout d’activer la protection anti-cross-site scripting. Niveau upload, j’ai vu large et j’ai autorisé le téléversement de fichier de 100 Mio. Côté performance, j’ai activé la compression des flux pour optimiser un peu les performances réseaux.
Le troisième bloc concerne la partie Reverse Proxy. Toutes les requêtes qui sont envoyées sur https://10.227.250.11 sont redirigées vers le port 11434. Concernant les en-têtes il est nécessaire d’utiliser les websockets car seront transmis l’ip du client, le protocole utilisé et le NDD18 ou l’IP demandé.

Une fois la configuration faite, il est important de réaliser un petit contrôle de notre petit fichier afin de s’assurer que ce dernier ne comporte pas d’erreur.

$ sudo nginx -t 
$ sudo systemctl restart nginx

Tiens une erreur 🙂 Regardons ça dans la partie suivante…

Sécurité

Nous souhaitons toujours publier notre interface web en HTTPS. Donc il va falloir jouer avec nos UTMs !

Sur le plan interne, autorisons nos flux https :

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

Toutefois lors de la relance du service on se tape une bonne grosse erreur. C’est lié au SELinux. Nginx n’est pas autorisé par le SELinux a écouter sur le port 11444. Donc il faut l’autoriser.

#Install semanage
$ sudo dnf install policycoreutils-python-utils

#Ajout du port comme autorisé à l'écoute
$ sudo semanage port -a -t http_port_t -p tcp 11444

#Relance du service nginx
$ sudo systemctl restart nginx

Normalement nous ne devons plus avoir d’erreur. Toutefois si nous essayons de joindre l’url https://egapl-ollama-01:11444 nous devons avoir un jolie 502 Bad Gateway dans notre navigateur 😀

Ca vous fait la b**e hein ? Je vous rassure je me suis pris la même rouste. J’ai oublié d’autoriser le contexte de mon SELinux pour autoriser les services http à accéder aux réseaux 😀

$ sudo setsebool -P httpd_can_network_connect 1

Un petit F5 et hop c’est tout bon <3

Normalement avec toutes nos actions, nous devons joindre notre interface web depuis un navigateur de manière sécurisée (hormis l’erreur liée à notre certificat autosigné).

Emplacement des modèles

Lors de ce benchmark, j’ai été confronté à un problème d’espace disque lié aux modèles. Effectivement, les modèles sont au minimum supérieur à 3 Gio. Et c’est là que c’est le drame car « pouf » je me tape un message d’erreur…

La solution est donc de déplacer le répertoire de modèle vers un autre disque. J’ai vu large, j’ai provisionné 100 Gio. Je pars du principe que le disque est monté et formaté.

$ sudo chown -R ollama:ollama /mnt/ollama

Le changement de l’emplacement du répertoire du modèle va se faire par surcharge du service qui démarre Ollama. Naturellement, on ne modifie pas le service de base car les changements ne seront pas persistants. D’où la surcharge…

$ sudo mkdir /etc/systemd/system/ollama.service.d
$ sudo vim /etc/systemd/system/ollama.service.d/override.conf

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="OLLAMA_MODELS=/mnt/ollama/ollama-models"
Environment="OLLAMA_HOST=0.0.0.0"

Notons que le mode Debug est actif et que le chemin de nos modèles est défini. J’ai également défini la variable OLLAMA_HOST qui va nous permettre de joindre notre application depuis une source externe à notre machine.

Il convient alors de recharger, forcer le gestionnaire de services à recharger l’ensemble de ses configurations. Dans un second temps nous redémarrerons le daemon ollama afin de prendre en considération les changements présents dans notre fichier de surcharge. Par mesure de sécurité (car la confiance n’exclut pas le contrôle) j’aime à vérifier que le service est bien actif.

$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama
$ sudo systemctl status ollama
$ sudo ls -al /mnt/ollama/ollama-models/

Dans les sources, nous pouvons constater la présence de nos variables surcharger. Néanmoins nous pouvons afficher le contenu de notre répertoire cible pour les modèles afin de vérifier que l’arborescence est bien présente.

Installer des modèles

J’ai fait le parti car c’est « un peu » l’objectif de base de ce billet d’avoir des modèles locaux qui vont être utilisés. Je ne souhaite pas utiliser des connexions avec des sources externes afin de garder un contrôle sur mes recherches et usage.

J’ai fait le choix d’étudier 4 modèles LLM :

• Llama3
• Qwen
• Mistral
• DeepSeek-Coder

Je propose dans un premier temps de faire un comparatif de ces modèles.

Avec ce tableau, je pense que nous avons un bon récapitulatif. Toutefois et pour les curieux il existe une centaine de modèles compatible avec Ollama (Lien). J’ai fait mon choix, à vous de faire le vôtre. Vous êtes des grands garçons et des grandes filles hein ? #bisous

L’installation pour les modèles choisies, suivent tous la même logique. Pas de quoi épiloguer pendant 107 ans….

Llama3

$ sudo ollama pull llama3

Qwen

$ sudo ollama pull qwen

Mistral

$ sudo ollama pull mistral

DeepSeek-Coder

$ sudo ollama pull deepseek-coder:6.7b

Pour voir l’ensemble des modèles il est possible de lister ces derniers grâce à la commande suivante :

$ sudo ollama list

Démarrage de Ollama

Maintenant que tout est fonctionnel, démarrons Ollama et c’est parti pour un périple des possibles comme Heinrich Harrer à l’assaut du Nanga Parbat (l’élévation n’étant pas celle que l’on croit 🙂 ).

$ ollama

Dans le menu qui s’offre à nous, la première option permet de démarrer, lancer un de nos modèles localement. Toutefois, en dessous de cette première option de navigation, nous retrouvons la possibilité d’établir des connexions externes vers des moteurs en ligne tel que : * Claude Code * Codex * OpenClaw * Droid * Pi * Cline Si vous possédez un compte, vous pouvez réaliser la jonction, mais alors à quoi bon avoir un moteur d’IA interne ?

Si nous cliquons sur le premier choix, il nous est alors demandé de choisir un modèle. Il est possible de télécharger un modèle directement depuis ce menu ou de choisir un modèle précédemment installé tout en bas de cette interface.

Tests

Et si on se lançais un petit benchmark de nos 4 modèles pour voir le fonctionnement ? 🙂

Amusons-nous tel un lamastico <3

Pour le test, j’ai décidé de partir sur quelque chose de simple et ISO sinon cela ne sert strictement à rien.

La question sera :

Peux-tu évaluer et me proposer une version plus robuste de cette fonction powershell s’il te plait ? [Suivie d’une petite fonction maison qui peut être amélioré]

Llama

Qwen

J’ai du tronquer la partie de la réponse en anglais car cela aurait pris énormément d’espace. Toutefois la réponse retournée est plus que satisfaisante pour celui qui sait parler la langue de Shakespeare

Mistral

DeepSeek-Coder

Je pense que cela est évident en termes de conclusions. Pour 1 prompt identique, nous avons quartes réponses différentes et un point commun. Si certains modèles mettent plus de temps de réponse il est indéniablement contestable que ça chauffe niveau calcul. Dans certains cas, j’aime même du SWAP ! Bref, côté consommation électrique, ça consomme… Mais bon je m’y attendais ce n’est pas la première fois que je fais des étincelles avec ma b*te…

Plus sérieusement, je sais quitte à me répéter ou pas ce que je dois faire pour améliorer ma fonction. Et je suis un peu déçu du résultat. Néanmoins en modifiant légèrement le prompt, en précisant :

Peux-tu évaluer et me proposer une version plus robuste, sécurisé de cette fonction powershell s’il te plait comme si tu étais un développeur sénior avec un regard plus critique et sévère ? [Suivie d’une petite fonction maison qui peut être amélioré]

Résultat Prompt initial (qwen)	Résultat Prompt plus précis (qwen)

/!\ Attention : J’ai volontairement gardé que la suggestion de la fonction et non le blabla d’en-tête qui explique tout ce qui va être appliqué.

Encore une fois pas de magie, il suffit de bien rédiger son prompt et là j’obtiens un retour plus précis à mes attentes.

Si je résume la situation sur le test à iso périmètre selon le contexte :

• RAM : 8 Go
• vCPU : 4
• Processeur Physique : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz (Mono)
• Contexte : Coding

Durée des réponses	Qualité des réponses

En conclusion Qwen est de loin celui qui met le plus de temps à délivrer la réponse. Cela s’explique par une explication plus poussée ce qui prends un certain temps à l’affichage. Cependant la qualité de la réponse retournée est de loin supérieur aux trois autres LLMs.

Il serait intéressant de pousser la comparaison sur un prompt de réflexion pur.

De tous les tests de modèles (du moins sur les quatre déployés) c’est qwen qui me convient le mieux. Néanmoins tout dépendra encore une fois du contexte et de ce que je souhaite réaliser avec l’IA.

Conclusion

Je suis plutôt satisfait bien que sans répondre aux prérequis il faut savoir s’armer de patiente. Dans l’ensemble Ollama est une bonne solution mais cette dernière doit être utilisé avec un certain contrôle selon les LLMs que l’on pourrait être amené à utiliser. Naturellement le retour de prompt vient de la qualité de celui que l’utilisateur aura exprimé.

De ce fait, Ollama ne garantit pas une fiabilité aussi conséquente que les géants du Cloud. Toutefois il permet d’assurer la confidentialité, sécurité des données localement et de nos recherches contrairement aux outils en ligne.

Ce qui pourrait toutefois rebuter son usage serait de passer par l’interface CLI dans le terminal. Effectivement c’est loin d’être ergonomique pour un usage quotidien d’un utilisateur n’ayant pas d’expérience dans ce domaine. Mais il existe toutefois des alternatives à cette problématique par des outils intermédiaires qui viennent se placer entre l’utilisateur et Ollama. Ce sujet sera abordé dans un prochain billet.

Initialement, je souhaitais aborder le sujet dans ce billet mais cela aurait été trop indigeste. Donc j’ai CUT comme on dit dans notre milieu 🙂

Ollama fournissant une documentation riche et simple il sera alors possible de jouer avec son API. Vous me connaissez avec le temps, s’il y a une documentation, une API… Que vais-je bien pouvoir faire avec le framework .NET et Powershell ? 🙂 L’objectif serait de proposer par exemple un petit client de bureau Windows pour les utilisateurs. Il serait également possible de mettre en place des passerelles d’automatisation inter applicatives intelligente comme L’ouverture d’un incident sur un event VEEAMOne dans ITOP ou une fonction de contrôle de code depuis PowerShell ISE par exemple.

Cette étude m’ouvre un nombre de porte considérable en guise de projet et de sujet d’étude et ce malgré les contraintes matérielles. Est-ce que je vais utiliser longtemps la solution, je ne pense honnêtement pas car cette dernière est assez énergivore pour mon petit lab et je ne travaille pas chez EDF ni n’habite Versailles. Mais cela peut (pour ne pas dire m’a) réconcilié avec l’utilisation de l’IA. Comme quoi il n’y a que les cons qui ne changent pas d’avis et nous sommes tous le con d’un autre.

Le mot de la fin :

J’ai cherché votre nom sur Ollama ? Comme ça vous êtes triple champion du monde de descente de Guiness catégorie galopin ?

Vous devez faire erreur avec une autre personne, je suis un DC10 fantôme sortant d’une tempête codéinée.

Milles excuses M’sieur Ollama.

Erwan GUILLEMARD

Sources

• Définition Larousse
• Wikipédia : IA
• DataBird : Type d’IA
• Ollama : Documentation
• Ollama : Téléchargement
• Ollama : Bibliothèque de modèle
• OpenWebUI : Documentation
• OpenWebUI : Intégration Ollama
• Comparatif : Modèles performances
• Comparatif : Modèles usages
• Usage de l’IA : DAFMag
• Répartition de l’usage : BPIFrance
• Usage de l’IA : LeMonde

1. IA : Intelligence Artificielle ↩︎
2. L’erreur est humaine, persévérer diabolique ↩︎
3. CGU : Conditions Générales d’Utilisations ↩︎
4. LLM : Large Language Models ↩︎
5. GPU : Graphics Processing Unit ↩︎
6. CPU : Central Processing Unit ↩︎
7. SSD : Solid State Drive ↩︎
8. DARPA : Defense Advanced Research Projects Agency ↩︎
9. IHM : Interface Homme Machine ↩︎
10. AGI : Artificial General Intelligence ↩︎
11. SVM : Support Vector Machine ↩︎
12. NLP : Natural Language Processing ↩︎
13. RAG : Retrieval Augmented Generation ↩︎
14. API : Application Programming Interface ↩︎
15. HTTP : Hypertext Transfer Protocol ↩︎
16. UTM : Unified Threat Management ↩︎

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

Alors non je ne vais pas abandonner MariaDB. Ce billet simple et efficace traitera de la SGBD¹ PostgreSQL. Le pourquoi de cet intérêt soudain se justifie par la rupture technologique de nombreux éditeurs du marché vers ce moteur puissant. Ne nous voilons pas la face, ce jour les grands acteurs de BDDs² proposent des versions communautaires qui sont limités en termes de volumétrie et de fonctionnalité. Pour jouir de l’ensemble des fonctionnalités il faut passer à la caisse.

$$$ Bonjour le bandit manchot $$$

Les bases de données étant de plus en plus volumineuse et l’évolution que nous utilisateurs nous en faisons facilite auprès de ces mêmes éditeurs la mise à jour de leurs tarifications. C’est de bonne guerre (ou pas). Ce « ou pas » laisse donc la voie à d’autres alternatives. Plus simple, moins complexes et parfois plus puissante en s’alignant sur le principe de la philosophie OpenSource.

Je laisse une version communautaire, tu passes à la caisse si tu veux un service d’assistance ou de maintenance.

Il y aura toujours chez certains éditeurs quelques fonctionnalités en moins. Toutefois, je pense que c’est dans cette approche et la bonne et je réfléchis à adopter le même principe dans un projet de vie d’une plus grande dimension.

Bref, après cette marche de l’éléphant (sans prendre de LSD³ ou autres acides). Je me fais un petit guide sur PostreSQL 🙂

Avant-Propos

Il me semble important une nouvelle fois de préciser que ce billet portera sur le déploiement d’un environnement PostgreSQL dans sa dernière version stable à ce jour (release 18 en ce mois de grace Octobre 2025). Sur Windows, le déploiement ne m’intéresse pas des masses. Par contre sur un système GNU/LINUX, j’écris un OUI majuscule (gras, italique, souligné rouge !).

Bien que les chiffres ne soient pas réellement suivis, PostgreSQL estime la part d’environnement de production d’environ (lien) :

• 52 % l’usage sur les systèmes GNU/LINUX
• 23% l’usage sur les systèmes Windows

La raison de mon choix est que nous retrouvons un grand nombre d’appliance qui utilise PostgreSQL dans des environnements GNU/UNIX. Donc en tant que SysAdmin il faut bien savoir se positionner 🙂 (franchement, quelle remarque de me*de…).

Je considère que l’environnement sera durci selon les recommandations de l’ANSSI⁴ concernant les systèmes GNU/LINUX et comme d’accoutumé, je pars sur ma distribution RHEL favorite RockyLinux.

Prérequis

• SE :
  • Rocky Linux 9.4 et version ultérieures
• Apps : 
  • PostgreSQL 18.4
• Autres :
  • Non applicable

Théorie

L’implémentation d’un SGBD passe forcément par une réflexion de sa topologie. Nous ne balançons pas une application 1-tiers, on essaie à minima d’adopter une architecture 2-Tiers. Soit 1 serveur Frontend et 1 serveur Backend.

Pour des raisons qui sont évidentes (enfonçage de porte ouverte) une application publiée ne doit pas héberger la BDD. L’application doit être en DMZ⁵ et la BDD dans une autres bulles avec un contrôle des flux entrants et sortants interlans.

M’sieur? Et pour l’identification des flux ? Pour l’attribution des ressources ? Comment on fait ?

Donnez moi un R, un T, un F et un M… RTFM⁶ ! Il suffit encore une fois d’avoir le courage de se palucher le wiki de l’éditeur applicatif. Un peu d’huile de coude n’a jamais fait de mal.

Une fois la topologie bien pensée, passons à l’architecture de notre serveur BDD.

Comme tout SGBD déployé il convient au minima d’implémenter la topologie ci-contre. Soit, un disque dédié au système UNIQUEMENT. Un disque dédié au stockage des données de notre SGBD et en dernier lieu un disque dédié au dump de nos BDDs avec une périodicité définie. J’ajouterai également un quatrième disque quant aux journaux de la BDDs et les journaux de transaction (les fameux transaction logs). Toutefois, ayant une petite infrastructure, je m’octroie le luxe de laisser ces derniers dans le /var/log.

Hardware Requirements

Niveau des ressources là c’est une autre histoire… Si la documentation officielle nous communique les ressources et interopérabilités avec les dépendances tierces, je n’ai malheureusement pas trouvé d’informations sur les ressources matérielles. Dans un sens logique car cela va dépendre de ce que nous souhaitons traiter comme données etc.

J’ai donc décidé d’appliquer de mon plein gré et non sous la contrainte de calquer les recommandations MariaDB (lien). Toutefois, cela fait un peu beaucoup pour moi…

Je partirai donc pour un minimum 2 vCPU et 4 Gio de RAM. Dans l’idéal, je serai je pense sur du 4 vCPU et 8 Gio de RAM. Comme écrit plus haut, tout dépendra de ce que notre application va consommer en termes de traitement. Il faudra alors raisonner en bon père de famille (spéciale dédicasse) et ajuster les ressources afin d’éviter la sur ou sous allocation.

Côté réseau, la documentation nous indique que le port 5432/tcp est le port de communication par défaut. Surprise, nous pouvons changer le port dans le fichier de configuration…

Je pense qu’avec le peu de base énoncée, nous pouvons passer à la pratique.

Pratique

Un dernier point pour faire une magnifique transition entre la théorie et cette partie. Il est à noter que les dépôts officiels des distributions contiennent une version de la solution PostgreSQL. Toutefois, il ne s’agit généralement pas de la dernière version. Il est recommandé d’ajouter le dépôt de l’éditeur et de ne pas utiliser le dépôt système pour PostgreSQL.

Installation

Franchement, je trouve là la démarche super-mega overcool de proposer un webwizard pour définir comment déployer PostgreSQL selon les différents OS⁷ et distributions (nous noterons au passage un excellent usage de la figure de style hyperbolique) (lien).

Je ne vais pas copier bêtement le script proposé. Mais reprendre chacune des lignes. Ce que je trouve admirable, c’est la simplicité du déploiement. Pas besoin d’installer 10k de dépendance en amont et de configurer ces dernières.

1 – Ajout du repo

A partir du lien fournit par le webwizard installer le nouveau repo :

$ sudo dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

2 – Désactivation du package de la source de distribution

Comme indiqué précédemment, il convient de désactiver la version de postgreSQL contenu dans le repo par défaut. Ainsi, nous aurons une plus grande flexibilité dans le choix de version de nos composants.

A noter que mon système étant durci j’ai été contrait de réaliser l’opération en tant que root.

# dnf -qy module disable postgresql

3 – Installation du Server PostgreSQL

Rien de plus simple, il suffit de faire une petite recherche par précaution puis une installation de notre package.

# dnf search postgresql18-server
# dnf install postgresql18-server

4 – Initialisation et démarrage

Comme tous SGBDs, il convient d’initier la première installation. Puis de s’assurer que le service va être lancer automatiquement au démarrage du système en cas de reboot.

Pour conclure, le traditionnel démarrage de notre daemon.

# /usr/pgsql-18/bin/postgresql-18-setup initdb
# systemctl enable postgresql-18
# systemctl start postgresql-18

Pour le fun, une petite vérification 🙂

Notre daemon PostgreSQL étant déployé, j’arrive toujours à ce point d’application des bonnes pratiques systèmes. C’est là que ça peut être délicat si on se plante dans la configuration car cela peut mener à repartir de zéro. D’où l’importance de lire la documentation encore une fois.

C’est qu’un éléphant ça trompe énormément !

Et voilà comment on casse tout 😀

Déplacement de la BDD Location

Si nous gardons la topologie mis en place ci-haut, il sera nécessaire de déplacer le répertoire data stocké sur /var/lib/pgsql/18/data vers notre répertoire /mnt/database/postgresql/data monté sur notre disque /dev/sdb.

Je ne vais pas mentir, je me suis pris les pieds dans le tapis une fois et j’ai dû restaurer ma VM. Toutefois, les étapes ci-dessous sont bien éprouvées et valide.

1 – Arret du service

La base de la base est donc d’arrêter le service postgresql :

$ sudo systemctl stop postgresql-18.service
$ sudo systemctl status postgresql-18.service

Il est primordiale de s’assurer que le service ne tourne plus.

2 – Création de l’architecture cible

Sur notre partition /dev/sdb1 préalablement configurée et montée sur /mnt/database, nous allons créer et définir les droits et permissions pour autoriser notre compte postgres à accéder à ce dernier.

$ sudo mkdir /mnt/database/postgresql
$ sudo mkdir /mnt/database/postgresql/pg_sock
$ sudo mkdir /mnt/database/postgresql/data
$ sudo chown postgres:postgres /mnt/database/postgresql
$ sudo chmod 755 /mnt/database
$ sudo chmod 700 -R /mnt/database/postgresql

Mais alors pourquoi 700 ? La base de donnée ainsi que l’ensemble des fichiers de ressources doivent être accessible uniquement de l’application par sécurité.

3 – Déplacement des données

Comme j’ai pris l’habitude de faire comme pour MariaDB, je vais copier le contenu du répertoire data puis renommer la source afin d’éviter tous dysfonctionnements.

$ sudo rsync -av /var/lib/pgsql/18/data/ /mnt/database/postgresql/data/
$sudo mv /var/lib/pgsql/18/data /var/lib/pgsql/18/data.ori

Une erreur classique lors de l’usage de la commande rsync reste l’oublie du /. Cela entrainera la copie du répertoire et non de son contenu uniquement. En gros, ça va bégayer dans les chemins (../postgresql/data/data/…).

4 – Modification de la configuration du service

Le service est configuré pour démarrer le daemon sous /var/lib/psql/18. Pour prendre en charge le nouveau chemin, il faut modifier ce dernier. La philosophie et de surcharger la configuration.

Créer le répertoire qui va contenir la surcharge de notre daemon psql :

$ sudo mkdir -p /etc/systemd/system/postgresql-18.service.d

Créer un fichier de surcharge qui va contenir le chemin du répertoire data :

$ sudo tee /etc/systemd/system/postgresql-18.service.d/override.conf > /dev/null <<'EOF'
[Service]
Environment="PGDATA=/mnt/database/postgresql/data/"
EOF

Par acquis de conscience, j’aime vérifier que le fichier est bien présent ainsi que le contenu de ce dernier.

$ sudo cat /etc/systemd/system/postgresql-18.service.d/override.conf

Le daemon ‘system’ a été altéré (puisque j’ai ajouté une configuration) et donc ? Un petit reload des familles pour prendre en compte le changement et zou.

$ sudo systemctl daemon-reload

5 – SELinux

Un étape un peu border avec la sécurité (comme un excès de Delirium un jeudi soir pour oublier une semaine compliqué).

Toutefois, il est important de noter un petit point et non des moindres sur notre fichier /etc/fstab. Il va être nécessaire d’ajouter le contexte sur notre partition et de relabeliser notre point partition.

Editons le fichier avec VIM, VI ou NANO puis modifier la ligne comme ci-dessous en ajoutant au niveau des droits defaults,context=system_u:object_r:postgresql_db_t:s0

Ce qui veut dire en SELinux :

• Defaults : Activation des droits standards
• Context=
  • system_u : Identité SELinux, sans impact concernant notre SGBD
  • object_r : Rôle d’objet de type fichier
  • postgresql_db_t : Match avec le type de données PostgreSQL autorisé par SELinux. Ainsi, SELinux interdit à PostgreSQL d’accéder à des fichiers qui ne sont pas dans le contexte.
  • s0 : Le niveau de sécurité par défaut.

Il sera nécessaire de définir le bon contexte sur notre nouveau répertoire.

$ sudo semanage fcontext -a -t postgresql_db_t "/mnt/database/postgresql(/.*)?"
$ sudo restorecon -Rv /mnt/database/postgresql/

6 – Démarrage du service

Le moment de vérité.

Vais je vomir l’ensemble de mes bières et commander une nouvelle tournée pour noyer mon échec ou commander une nouvelle tournée pour célébrer le succès de cette opération ? 🙂

$ sudo systemctl start postgresql-18
$ sudo systemctl status postgresql-18

Il faut noter que le service fonctionne. Néanmoins, il convient de se demander si nous pouvons requêter notre BDD à la suite de ce changement.

$ sudo -u postgres psql -c "SELECT version();"

Vérifions également que le chemin du PGDATA a bien été pris en compte.

$ sudo -u postgres psql -c "SHOW data_directory;"

Ouf ça fonctionne 🙂

Place à l’étape suivante ! BA-BA-BAR POM POM POM POM

Sécurisation & Configuration

Nous revenons encore et toujours au même point. Qui dit données implique la sensibilité de ces dernières. Aujourd’hui braquer une banque ne rapporte pas grand-chose. Le rapport bénéfices/risques n’est pas bon… Mais braqué des données, utiliser ces dernières et les revendre apporte un bien meilleur rapport en termes de bénéfices / risques.

Donc, je me retrousse les manches car je ne suis pas un manche !

Si du côté MariaDB il existe le fameux mysql_secure_installation, ce n’est malheureusement pas le cas chez PostgreSQL.

Il se pose alors de dresser un inventaire rapide des points que nous souhaitons sécuriser :

1. Mot de passe du compte postgres
2. Restreindre l’accès réseaux
3. Mettre en place une stratégie d’authentification
4. Utiliser des algorithmes de chiffrement fort
5. Supprimer les BDDs inutiles
6. Droits sur les fichiers
7. SELinux
8. Firewall embarqué (même si je préfère le terme embedded)
9. Audit et Journaux d’événements

Ca fait une petite tripoté n’est-il pas ? Naturellement, certains des points ci-haut ont déjà été traité lors du déploiement et du changement d’emplacement de la base de données.

1 – Password Account DB

Comme pour MariaDB (compte root), l’utilisateur postgres ne possède pas de mot de passe. Il convient par sécurité de définir ce dernier afin qu’il ne vienne une idée à un individu malveillant (comme un RSSI ⁸lors d’un audit ou pire un SysDBA⁹) de mettre sa truffe humide dans notre BDD.

$ su - postgres
$ psql -c "alter user postgres with password 'MyP@ssw0rd'"

Il est important de faire un petit clear de l’historique de frappe. Un mot de passe en clair c’est pas cool.

2 – Network Restrictions

Ouvrons le fichier de configuration /mnt/database/postgresql/data/postgresql.conf.

Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

Recherchez la section CONNECTIONS AND AUTHENTIFICATION.

Se pose alors la question, depuis où je peux consulter ma BDDs et sur quel port ? Personnellement, le port je le laisse par défaut soit 5432/tcp. Toutefois, la source, il est bien de spécifier le subnet ou les adresses IPs qui sont autorisé à se connecter à notre SGBD. Naturellement, la valeur ‘*’ est proscrite.

Ce paramétrage va de pair avec la configuration de notre UTM¹⁰ embedded (cf le point plus bas).

3 – Authentification Policies

On va changer de fichier. L’objectif est de définir qui va se connecter à quoi, comment et depuis où.

Direction /mnt/database/postgresql/data/pg_hba.conf

La logique de lecture est la suivante TYPE correspond à la nature de l’authentification (local? hôte ?) pour quelle DATABASE (all ? replication ? db_test ?) pour quel USER (all ? r-one ?) depuis quelle ADDRESS (127.0.0.1/32 ? 0.0.0.0/0 ? 10.36.16.0/24 ?) et par quel METHOD (peer ? scram-sha-256? MD5?).

Il est certain qu’il faut limiter l’usage au maximum du all comme du masque 0.0.0.0/0. Toutefois, il n’y a pas de base les paramètres « implicites » de refus des connexions. C’est donc à implémenter (dernières lignes de la capture d’écran).

On sauvegarde, puis on reload le service.

$ sudo systemctl reload postgresql-18

4 – Suite de chiffrement

Toujours dans le fichier de configuration /mnt/database/postgresql/data/postgresql.conf. Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

Recherchez la section CONNECTIONS AND AUTHENTIFICATION et activez l’algorithme de chiffrement scram-sha-256. Le MD5, nous passons notre tour hein ? Autant allez aux champignons sans capotes, c’est du pareil au même.

5 – Nettoyage des BDDs inutiles

Il est important de lister les bases présentes sur notre SGBD et de supprimer les bases qui ne servent à rien.

$ su - postgres  -c "\l"
$ psql

postgres=#\l
postgres=# DROP DATABASE NAME_BDD;

Attention : Il ne faut en aucun cas supprimer les bases template0 et template1. Ces dernières permettent (pour la 1) de générer les futurs BDDs) et (pour la 0) de regénérer la BDD de modèle.

6 – Permissions et ACLs

Comme expliqué ci haut et pour des raisons évidentes. L’accès aux données doivent être accessible uniquement du compte utilisateur postgres et root. Pas de quoi foutez milles éléphants…

Je glisse toutefois les commandes.

$ sudo chown -R postgres:postgres /mnt/database/postgresql/data
$ sudo chmod 700 /mnt/database/postgresql/data

7 – SELinux <3

Nous retrouvons la commande saisie ci-haut si nous avons modifié le database location.

Ainsi nous définissons le contexte de fichier de type postgresql_db_t à l’ensemble des éléments qui sont situer sous /mnt/database/postgresql. Puis on restore le contexte.

$ sudo semanage fcontext -a -t postgresql_db_t "/mnt/database/postgresql(/.*)?"
$ sudo restorecon -Rv /mnt/database/postgresql/

8 – Firewall

Avant c’était iptables maintenant c’est firewalld ou ufw. Personnellement je reste sur la configuration de firewalld.

Il convient d’autoriser les flux 5432/tcp dans notre firewall si des connexions se font depuis un autre réseau ou une autre machine.

$ sudo firewall-cmd --permanent --add-service=postgresql
$ sudo firewall-cmd --reload

Cela étant, il serait également plus précis de filtrer les connexions entrantes sur un réseau ou une adresse ip uniquement sur le port 5432/tcp.

J’assume cette configuration du fait de mon UTM en amont qui filtre l’ensemble des flux inter-lans.

9 – Logs & Audits

Ouvrons le fichier de configuration /mnt/database/postgresql/data/postgresql.conf. Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

# vim /mnt/database/postgresql/data/postgresql.conf

Se rendre ensuite dans la section REPORTING AND LOGGING. Puis vérifiez que la configuration suivante est active.

Activation de logging_collector sur on afin de récupérer les erreurs sous la forme json ou csv. L’emplacement où va être stocké les journaux. Par défaut celui-ci se trouve dans le répertoire log. Il faudra renseigner si l’emplacement est différent le chemin absolu, le chemin relatif si c’est un cluster. log_directory = ‘log’ Le nom du fichier, par défaut ce dernier est sous le format postgresql-%Y-%m-%d_%H%M%S.log. log_filename = ‘postgresql-%a.log’ Activer la journalisation pour l’ensemble des événements de connexion et de déconnexion. log_connections = on log_disconnections = on En guise de traitement des logs, nous choisirons ddl pour avoir les définitions des commandes utilisés. Attention, l’usage de all peut être dangereux vis à vis des ressources. log_statement = ‘ddl’

Une fois les modifications apportées, n’oubliez pas que notre serveur PostgreSQL à besoin d’être redémarré :

$ sudo systemctl restart postgresql-18

Pour une configuration spécifique comme la gestion de la mémoire allouée, les fonctionnalités et j’en passe. Je pense qu’il est inutile d’aborder cela dans ce billet.

Pourquoi ? Parce que cet aspect-là et intrinsèquement lié aux dépendances des applications qui nécessite le SGBD PostgreSQL.

Premiers Pas

Cette sous partie vise plus à entrevoir les commandes de bases pour instancier une BDD dans le cadre de déploiement d’une application (spoiler Odoo par exemple ?).

Je n’ai pas la prétention de réinventer la roue, il existe la documentation pour cela et je n’ai pas non plus la prétention de devenir SysDBA. J’ai juste envie de faire les choses bien et surtout en suivant la doctrine des 3S, Simple, Standard et Sécurisé (14 ans d’ESN¹¹ ça vous forge un homme !).

Création d’un user

La création d’un utilisateur suit un paradigme différent de MariaDB. La finesse de l’application du contexte d’un utilisateur se fera dans le fichier pg_hba.conf.

$ psql -U postgres

postgres=# CREATE USER user_odoo WITH PASSWORD 'MyPassw0rd';

Création d’une BDD

La création d’une BDD nécessite qu’un utilisateur (de la SGBD naturellement) ait le privilège CREATEDB ou d’utiliser un compte super utilisateur. Cela parait logique mais pas pour tout le monde. La documentation nous rappelle que la création d’une nouvelle base de données sera effectué en réalisant un clone de la BDD template1 (si, le truc qui ne fallait pas supprimer).

postgres=# CREATE DATABASE bdd_odoo;

Toutefois, nous pouvons allez plus loin en définissant le propriétaire de la BDD, le jeu de caractère de la BDD ainsi que la collation locale afin de faciliter le tri des chaines. Par exemple :

postgres=# CREATE DATABASE bdd_odoo_18
			WITH OWNER user_odoo
			ENCODING 'UTF8'
			LC_COLLATE 'fr_FR.UTF-8'
			LC_CTYPE 'fr_FR.UTF-8'
			TEMPLATE template0;

/!\ ARTUNG /!\ Bicyclette et petit vélo !

Il n’est pas impossible que vous tombiez sur une erreur de ce type « invalid LC_COLLATE locale name« . Cela signifie que tu vivras ta vie sans aucun soucis. (Tes vraiment sûre ?) En gros, il manque le fichier de mappage de caractère au niveau système. Soit il n’est pas présent, soit il n’est pas généré.

Afin de vérifier si ce dernier est présent :

$ sudo locale -a | grep fr

Si cela ne retourne rien c’est que le packet ne doit pas être installé. Alors installons le vin diou !

$ sudo dnf install glibc-langpack-fr
$ sudo locale -a | grep fr

Surprise le fichier de mappage est présent ! Si nous rejouons la requête, cela fonctionne.

Attribution des privilèges et rôles

Comme tous systèmes de base de données, un incontournable reste la notion de rôle et de privilège.

Dans la pratique, il convient et je sais que j’enfonce une porte ouverte d’adopter la bonne pratique de créer des rôles et d’affecter les rôles aux utilisateurs. Un rôle sur la BDD en modification, en lecture, superutilisateur ect.

Ainsi et c’est d’une logique implacable, si modification il doit avoir, je ne modifierai QUE le rôle et non utilisateur par utilisateur. MALINX le LYNX…

Rôles

Par défaut, nous retrouvons :

Toujours dans le spoil (parce que je suis un mec underground moi. MOUMOUNIGAN !) je vais créer un rôle pour ODOO qui permettra uniquement de se connecter, de créer une bdd avec un mot de passe.

postgres=# CREATE ROLE r_odoo LOGIN CREATEDB;

Pour attribuer le rôle à un utilisateur (en prenant toujours le cas ODOO avec notre role r_odoo et user_odoo) :

postgres=# GRANT r_odoo TO user_odoo;

Privilèges

La notion de privilèges que ce soit sur la BDD, les tables où les schémas suivent le principe de SQL. Ainsi il suffira d’user des commandes GRANT accompagner de :

• CONNECT ON
• USAGE
• SELECT ON ALL
• SELECT, INSERT, UPDATE, DELETE
• ALTER
• DROP
• …

Il est important de prendre en compte que le propriétaire de la BDD a tous les droits.

Toujours dans notre exemple ODOO, il n’y aura donc pas de privilèges à appliquer.

PostgreSQL Client

Il existe un outil que j’ai découvert à travers un case chez VEEAM pour un problème de protection O365 du nom de pgAdmin. Cette solution officielle est l’outil graphique pour administrer PostrgreSQL.

Je pense important de présenter cette dernière car dans le cas où nous ne nous serions pas SQL native language ou seconde langue. Cela nous permettrait de bien comprendre certains dysfonctionnements ou structures.

L’installation n’est pas en soi bien complexe… Ma grand-mère y arriverait sans difficulté. Toutefois, je glisse le tips…

Certains pourrait dire, oui c’est un PHPMyAdmin. Oui c’est un fait. C’est une IHM¹² en GUI¹³ pour faciliter l’expérience quotidienne.

Pour se connecter, il suffira de renseigner les informations de connexion et de s’assurer au préalable que la politique de communication est bien présente sur notre UTM concernant les flux interlans. Sans oublier de vérifier :

• La configuration du fichier pg_hba.conf est compliante
• Les adresses d’écoutes dans le fichier postgresql.conf ne sont pas restreinte cas localhost et que le bind d’interface est bien configuré. (Le bind c’est l’ip de l’interface du serveur, pas l’adresse ip du client… Je dis ça parce que je vous vois venir hein !)

Et si nous jetions un coup d’œil dans le viseur pour observer nos logs voir si on voit notre pachyderm numérique ?

$ sudo tail -f /mnt/database/postgresql/data/log/postgresql-Wed.log

Impeccable. Tout fonctionne 🙂

Conclusion

Ce billet revient aux prémices des premiers articles rédigés il y a maintenant quasiment deux ans. Quelques choses de simple qui vise à jouer les aides mémoires de ma cafetière qui commence à s’effriter.

Je ne tenais pas à me lancer dans un benchmark de « Est ce que l’otarie et plus fort que l’éléphant ? » cela ne m’intéresse pas le moindre du monde. Toutefois et comme j’ai pu l’aborder en avant propos, le tournant des éditeurs vers la solution PostgreSQL mérite de s’intéresser à cette dernière.

• VEEAM enchaine sa rupture technologique avec Windows (SE¹⁴ et/ou MSSQL) pour RHEL et PostgreSQL
• ODOO qui reste dans la philosophie du libre
• La Société Générale (faut bien renflouer les caisses après le passage de Jérôme KERVIEL… Ok, la blague est mauvaise, mais il fallait la faire. Trop tentante).
• Patrick BALKANY pour gérer son patrimoine non déclaré. Ah non autant pour moi c’est une fake news… Que je suis naïf 🙂

Au delà des deux derniers points douteux, il est bien je pense de se garder deux SGBDs relationnels sous le coude les solutions MariaDB et PostgreSQL. L’implémentation de la couche de sécurité relève d’un défi parfois mais reste nécessaire et plus qu’indispensable de nos jours.

Il manque toutefois un point que je n’ai pas développé ici. La possibilité de sauvegarder une base de manière périodique. J’avais traité le sujet pour MariaDB à la suite d’une connerie de ma part un vendredi aprem sur l’environnement de production. Je pense qu’il serait bien de reprendre ce projet et de l’adapter pour PostgreSQL 🙂

Ca fait un sujet supplémentaire à traiter d’ici la fin d’année. Mais surtout, le levé de voile ayant été fait un poil plus tôt ce billet est le tremplin pour l’implémentation d’ODOO comme mon ERP à venir.

Le mot de la fin :

Egaré dans la base de données infernale, le sysadmin se nomme R-ONE. A la recherche du datalocation, le problème s’appelle la durcification. Avec la solution VEEAM, il a pu rollback super vite. Dérivant à dos d’éléphant, R-ONE arrivera toujours dans l’étang… (faut bien se mouiller un peu qu’ils disaient les anciens)

Erwan GUILLEMARD

Sources

• PostgreSQL Secteur par OS
• PostgreSQL – Main Apps Guide
• PostgreSQL – Download
• PGAdmin – Download
• MariaDB – Hardware Requirements

1. SGBD : Système de Gestion de Base de Données ↩︎
2. BDD : Base De Données ↩︎
3. LSD :  LySergique Diéthylamide ↩︎
4. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
5. DMZ : Demilitarized Zone ↩︎
6. RTFM : Read The Fuck*ng Manual ↩︎
7. OS : Operating System ↩︎
8. RSSI : Responsable Sécurité des Systèmes d’Informations ↩︎
9. SysDBA : Administrateur des Systèmes de Bases de Données ↩︎
10. UTM : Unified threat management ↩︎
11. ESN : Entreprise des Services Numériques ↩︎
12. IHM : Interface Homme Machine ↩︎
13. GUI : Graphical User Interface ↩︎
14. SE : Système d’Exploitation ↩︎

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

Mais en dehors de l’aspect technique et du maintien opérationnel nous pouvons ajouter l’aspect financier « déclaratif mensuel des licences » en supplément. Bonjour la boite d’anxiolytique.

Cela passe encore quand c’est une petite structure, mais quand en plus nous devenons fournisseur de la solution (provider chez nos amis d’outre-manche) cela peut vite devenir un calvaire de facturer mensuellement les bonnes quantités et d’éviter une sur ou sous facturation. Egalement et je l’ai déjà vu, se faire régulariser de manière pro-active pour une « mauvaise déclaration » n’a rien d’une partie de plaisir.

Ayant dans mon quotidien professionnel la lourde tâche de garantir la disponibilité de l’infrastructure et produit lié à la sauvegarde à travers les produits VEEAMs en tant qu’usager et fournisseurs de service, je suis contraint de réaliser chaque fin du mois un rapport lié à la consommation de TOUS les produits de chacune de nos organisations.

Afin de ne pas voir une vague de suicide collectif, VEEAM a su entendre les cris du SysAdmin en détresse et a su proposer un outil pour lui faciliter la tâche ! Mais qu’est ce que nous sommes gâtés dit donc !

Plus sérieusement, VEEAM avec son nouveau système de licence universelle (VUL¹) a su rendre les choses simples et s’adapter à l’évolution des SIs² et s’adapter par sa flexibilité d’évolution des ressources présentes sur ces derniers aussi bien sur les infrastructures Cloud (Privées, Publics) ou les infrastructures OnPremise (je reviendrais plus en détail sur ce point plus bas).

Au delà de la flexibilité technique automatiquement cela ouvre la porte à une flexibilité et efficience budgétaire.

On tient quelque chose là ? Tu as mis chers amis le doigt sur un sujet sensible. Tu as mis le doigt sur la VUL… (En raison de la blague d’un trop haut niveau de qualité sur l’échelle du beauf, 10 minutes de suspension…)

Ainsi, en simplifiant le système de licensing et l’application de ce dernier, VEEAM offre avec l’un de ces produits la possibilité de :

• Unifier l’ensemble des solutions sous une seule application (une grande partie)
• Permettre la gestion par les clients d’un fournisseur « l’administration » de leur environnement VEEAM
• Avoir une vue orienté business et maitriser les éléments financiers
• Garantir l’état de santé de leurs environnements

Et voilà que la solution VSPC³ fait son entrée. Un tonnerre d’applaudissement pour la VEEAM Service Provider Console ! (Les 10 minutes de suspension sont toutes relatives…)

VEEAM le leader de la sauvegarde développa une solution centrale pour suivre et d’administrer chaque solution. Dans cette solution ils déversèrent leurs simplicités et leurs volontés de faciliter la vie des SysAdmins. Une application, la VSPC pour les administrer tous… #CRAQUAGE?

Prérequis

• SE : Windows Server 2k19 et versions ultérieures
• Apps : VEEAM B&R 12.x, VEEAMOne 12.x, VSPC 8.0
• Autres :
  • VEEAM B&R 12.x
  • VEEAM One 12.x
  • License VEEAM Entreprise

Avant-Propos

Il est important dans la continuité des bonnes résolutions de cette année 2025 d’essayer de réaliser des billets moins conséquents.

C’est pourquoi, je partirai du principe où les environnements VEEAM B&R et VEEAM One sont déjà déployés. Je pars également du principe dans le bon respect du silotage réseau et de la mise en place du tiering que nos 3 environnements ne sont pas sur le même réseau.

Nous verrons donc dans les parties ci-dessous comment déployer l’application VSPC sur une architecture 2 tiers. L’objectif étant (Attention spoiler) d’implémenter dans un second billet l’architecture (light) VCC⁴ [sous réserve d’obtenir une licence NFR⁵, mais je pense que cela ne sera pas possible. Sauf peut-être en demandant poliment et gentiment].

Je n’aborderai donc pas ce point ni celui de MS O365⁶ (pour des raisons de ressources). C’est pourquoi les schémas seront épurés au possible. Croyez moi, cela va nous simplifier la vie.

Comme pour les autres articles et encore une fois quitte à me répéter. Il s’agit là de mon implémentation, établie sur le guide officiel. Comme d’accoutumé, rien ne vous oblige à suivre MON mode opératoire.

Guide

Vous êtes plusieurs à m’avoir fait la douce remarque que mes articles vous amenaient à des états de crapulences du fait de leur longueur passablement excessive. J’ai pris la bonne résolution de faire plus court et de jouer les citrates de bétaïne pour nos cellules grises. Malheureusement, je n’y arrive pas…

Alors m’est venu l’idée de changer de format et de vous présenter des « sous-parties ». A voir si ce format est plus adapté. 🙂

• Partie 1 : Théorie
  • Aborder les bonnes pratiques, l’architecture et topologie la plus adéquate pour la VSPC. Les performances systèmes requis, le mode de licensing ainsi que les permissions
• Partie 2 : Pratique
  • Installation de l’infrastructure 2/3, configuration de l’application en tant que VSPC uniquement et Intégration de deux produits VEEAM.
• Partie 3 : Visite Guidée
  • Présentation des différents menus, onglets et fonctionnalités proposé par la console VSPC

Conclusion

Le produit VEEAM Service Provider Console est un produit puissant qui permet de centraliser en un seul point l’ensemble des produits VEEAM d’une ou plusieurs organisations. Pensé pour les fournisseurs de services managés, cette solution sait transformer des données techniques en données analytiques et financières tout en garantissant une flexibilité des services clients, allant même si nous le souhaitons s’inscrire non plus dans une offre B2B⁷ mais dans une logique commerciale B2B2B⁸ (et non 2Be3…).

Son objectif ? Je dirai plutôt ces objectifs au pluriel.

Faciliter l’administration et le MCO⁹ des environnements VEEAM des différentes organisations liées à la VSPC. Démontrer l’efficience de la solution sur la flexibilité d’ajustement des licences à la hausse comme à la baisse sur les différents produits en temps réel. Les outils internes présent permettent de définir une stratégie commerciale simple et efficace sur les différents produits VEEAM, que nous MSP¹⁰ avons dans notre catalogue de service.

<3 La VSPC, le rêve de tous SysAdmin gestionnaire d’hébergement <3

Toutefois, l’outil n’est pas parfait…

Quoi, t’es choqué déçu ?! T’es qu’un sa**p ! Je m’explique, ne dressez pas mon procès sans savoir ce que je vais écrire 🙂

Oui l’outil n’est pas parfait à mon gout. Il est difficile de dissocier la partie VSPC des services VCC bien que logique car ce dernier est prévu pour une usage fournisseur. Admettons que cela ne soit pas un problème, cela nécessite je pense une équipe dédiée à la sauvegarde et autres modes de protection.

Une équipe pour gérer VEEAM ? Oui une équipe pour traiter TOUS les produits VEEAM depuis l’hébergement Providers et Managed. L’offre doit être construit dans ce sens afin de fournir un service clé en main à vos clients (du moins si je monte ma boite demain, je tournerai une offre dans ce sens et je ne vous dis pas tout ! ) :

• Gestion des sauvegardes, réplications avec rapports hebdomadaire, mensuels, annuels
• MCO des produits VEEAMs
• Ajustements des licences
• TCO, plan d’investissement et d’amortissement
• Revendeur en tant que marque blanche

De mon expérience personnelle (si maigre soit elle), l’exploitation VEEAM n’est pas bien réalisée par les équipes externes ou internes. La mise à jour d’un certains nombres de VEEAM prend un temps important. Imaginons maintenant la mise à jour des infrastructure :

• VSPC
• VEEAMOne
• VEEAM Backup et Réplication
• VB Microsoft O365
• VCC
• etc

Et attention, à l’ordre d’application…

Maintenir l’architecture VEEAM peut vite devenir complexe. De plus, la validation des prérequis et l’élaboration de la matrice d’interopérabilité entre les solutions tierces demande également une bonne analyse.

Bref, une équipe dédiée à VEEAM est impératif #MYPOINTOFVIEW.

La grosse faiblesse de la VSPC à mon sens reste le détail de l’analytique et du nombre de data exploitable. Difficile de faire une analyse sur 13 mois glissante ou sur une période donnée par organisation ou par job… Donc l’établissement de rapports hebdomadaire, mensuels ou annuels sont compromis ? Non car comme je l’ai dit, l’API¹¹ fournit par la VSPC, noyaux convergeant des solutions VEEAM qui y sont liées va nous offrir par sa flexibilité et puissance la bouffée d’oxygène dont nous avons besoin pour arriver à nos fins 🙂

[Non je n’ai toujours pas d’action VEEAM, mais peut-être un petit peu amoureux… :-°]

Bref, si cet article est présent et si j’ai voulu présenter cette solution il faut se douter que j’ai une idée derrière la tête. Prochainement, je vous lâche un teaser comme dise la GEN Z (pas certain qu’ils disent ce genre de chose. Un banger peut-être ?).

Le mot de la fin

Si Voltaire considère le travail comme la plus grande consolation pour les malheurs inséparables de la condition humaine, c’est qu’il ne connaissait pas la VSPC et qu’il aurait dû faire craquer le compte CPF de Candide pour la VMCE !

Erwan GUILLEMARD

Sources

• VSPC : Guide
• VSPC : Guide Ports
• VSPC : Guide Permissions
• VSPC : VEEAMOne
• VSPC : VEEAM B&R
• VSPC : Guide API

1. VUL : VEEAM Universal License ↩︎
2. SIs : Système d’Information ↩︎
3. VSPC : VEEAM Service Provider Console ↩︎
4. VCC : VEEAM Cloud Connect ↩︎
5. NFR : Not For Resale ↩︎
6. MS O365 : Microsoft Office 365 ↩︎
7. B2B : Business To Business ↩︎
8. B2B2B : Business To Business To Business ↩︎
9. MCO : Maintient en Condition Opérationnel ↩︎
10. MSP : Managed Service Provider (Fournisseur de Services Administrés) ↩︎
11. API : Application Programming Interface ↩︎

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

Pourquoi commencer ce billet en étant si désagréable ? Parce que le sujet de la supervision, surveillance ou « monitoring » représente un enjeu capital pour l’activité des entreprises et il existe un large panel de solution payante ou gratuite sur le marché. Toutes ces solutions ne couvrent pas les mêmes périmètres de surveillance. Il est donc facile de multiplier les applications et de ne plus savoir où donner de la tête.

Personnellement, j’aime dissocier la surveillance d’un SI avec 3 types de solutions :

• Firewall et Liens
• Réseau Local
• Equipements Infrastructures Physiques et Virtuels

Dans certains cas, une 4 et dernière brique peut être amenée à être utilisée pour superviser des services applicatifs. Néanmoins, je ne suis pas un grand fan de ce niveau de surveillance (mais c’est mon opinion personnel) et il faut bien justifier le poste d’un Responsable Informatique dans sa société non ? (Je suis réducteur, mais un RSI ça sert à bien d’autre chose et ça ne fait pas que de boire des cafés toute la sainte journée avec Martine de l’accueil. Coucou Martine 🙂 ).

Je souhaite donc aborder le point de surveillance « Equipements Infrastructures Physiques et Virtuels » à travers une solution payante.

Soyons claire sur un point car je vois venir les détracteurs de la communauté GNU/UNIX et autres DAFs (bien trop proche de leurs budgets).

« Ouai mais il y a des solutions gratuites sous licence GNU qui font très bien l’affaire. En plus tu n’arrêtes pas de nous em*****r avec tes RHELs. VENDU ! »

Mon avocat à la barre, commis d’office me représente et assure ma défense.

« Mon client, tiens à préciser qu’il présentera une solution de supervision libre dans un autre billet car il est important de couvrir un périmètre similaire et plus flexible. Mon client s’engage dans cette démarche pour réduire sa peine si toutefois il est jugé coupable. Dans un second temps, il est important de se rapporter à la maxime « Le pas cher coute trop cher ». Une solution libre et gratuite c’est bien. Mais le jour où le MCO ne se passe pas comme prévu il est facile de passer un nombre d’heure conséquent. Les solutions payantes offrent un service de support et de correctif en cas de vulnérabilité critique. » CHEH ! Et en plus je vais tenter de vous convaincre que nous pouvons gagner ou économiser du MONEY MONEY.

J’ai donc décidé, d’après le titre de ce billet de continuer avec les solutions VEEAM, VEEAMOne.

Pourquoi le choix de VEEAMOne ? La solution est cross plateforme et permet d’avoir une bonne visibilité sur le socle de virtualisation, les ressources virtualisées ainsi que l’ensemble des éléments et environnement propres à la sauvegarde (VBO365, VDP). La cerise sur le gâteau reste la partie Business View, Reporting et Capacity Planning. Mais promis, je reviendrai plus en détail sur ces points bonus.

Je me garde également pour plus tard un autre article pour lequel j’ai besoin de VEEAMOne 🙂

Prérequis

• SE : Windows Server 2k19 et version ultérieures
• Apps : VEEAM B&R 12.x, VEEAMOne 12.x, VMWare/Hyperv
• Autres :
  • VEEAM B&R 12.x
  • License VEEAM Entreprise

Avant-Propos

Dans une logique de garantir un niveau de sécurité optimal, j’ai dans un premier temps longtemps pensé que l’ensemble des environnements de surveillance (supervision/monitoring) devaient être dans le même subnet que les éléments d’administrations ou de management. Maintenant, mon approche est différente. Je préfère dédier un subnet pour l’ensemble des solutions.

Mais pourquoi ? Je juge ces éléments sensibles. Ils donnent une bonne, trop bonne visibilité sur l’ensemble du SI. Admettons que la bulle de monitoring soit compromise, il nous suffira de restreindre totalement les flux réseaux ou à en limiter les flux depuis des ressources isolés. De plus, et cela se vérifie avec le temps certaines solutions de monitoring apportent des fonctionnalités d’actions sur les ressources sous surveillance ou de remédiations automatiques. (Mon dernier HP Tour Customer & Partner nous indique bien la tendance de l’IA et sa capacitée [monstrueuse ?] de traitement). Bref, ce n’est pas un outil à mettre dans toutes les mains, c’est un coup à être satellisé…

Théorie

Architecture & Best Pratices

Encore une fois, chacun voit midi à sa porte. Il est donc compliqué de définir une MO¹ empirique. Cela dépendra des technologies et solutions utilisées que ce soit en socle de virtualisation (VMWare, HyperV etc) et produits VEEAM (VBO MS365, VBR², VCC³ etc).

Mais commençons par le début. Qu’est-ce que contient VEEAM One et qu’a-t-il dans le ventre ?

VEEAM One se décompose de deux grandes parties. Une partie client et une partie serveur.

Clients

Comme on s’en doute, cela permet d’accéder aux données des environnements virtualisés ainsi que les données relatives à la sauvegarde, réplication et autres. Toutefois, nous distinguerons deux types de client.

Client Lourd : Son objectif est de permettre à travers la console d’accéder à l’ensemble des données de manière efficiente et d’avoir une vue globale sur notre infrastructure et d’interagir avec ce dernier selon les alertes remontées par les différentes sondes. Il sera nécessaire de déployer/installer le client sur le poste concerné et d’ouvrir les ports.

Client Web : A l’inverse, la console web est moins orientée « opérationnelle » au sens technique, mais plus au sens qualitatif avec l’élaboration de rapport, de tableau de bord et de définir l’évolution du SI (capacity planning, optimisation des ressources, optimisation des couts etc). Si les flux sont ouverts, il suffira d’accéder à ce dernier à travers un navigateur web à travers l’url https://monserver.contoso.lab:1239

Ce qui nous donne le schéma des flux suivants.

Donc si nous résumons, les choses. Le client lourd sera satisfaire les équipes opérationnelles et la partie client web les responsables / directeurs de services. Les jambes et la tête en sommes. 🙂

Dans son fonctionnement et c’est là l’une des forces de la solution. Le client lourd fonctionne sur la base d’une API. Ce qui implique que nous pouvons réaliser TOUTES les actions qui sont présents dans la console 😀 (Vous me voyez venir avec mes grosses charentaises ? )

Serveur

La partie serveur est bien plus complexe. De facto, les deux clients présentés précédemment sont présents sur le serveur

• VEEAM One Client
• VEEAM One Web Client

Ce qui est logique puisqu’il faut bien administrer la solution…

Toutefois, nous rencontrons également les rôles suivants :

• VEEAM One Server
• VEEAM One Database
• VEEAM One Agent
• VEEAM One WebServices

Dans le détail de chaque rôle, la partie Server va servir à la collecte des informations, des données et stocker ces dernières dans la Database afin de pouvoir par la suite les restituer sur l’action de l’utilisateur à travers les clients (web ou lourd). Il est possible de mutualiser la base de données VEEAMOne (MSSQL) avec d’autres produits. Toutefois je préfère ne pas mettre tous mes œufs dans le même panier et tenter de mutualiser mes BDDs, cela reviendrait à essayer d’additionner un veau avec des cigarettes…

La partie WebServices permettra comme nous pouvons nous en douter de garantir l’accès depuis un navigateur web au WebClient ainsi qu’à l’API.

C’est quoi la partie Agent ? Ne me dit pas qu’il faut se palucher le déploiement d’un agent sur les ressources que nous souhaitons surveiller ? Si c’est le cas, j’arrête ma lecture après ta réponse !

La partie Agent n’est pas à déployer sur toutes les ressources et heureusement. VEEAM One a été pensé pour être flexible ! La communication avec les applications de virtualisation se font soit par le biais de protocoles « classiques » ou par les APIs constructeurs.

L’Agent est nécessaire uniquement lors du monitoring, de remonter d’informations (logs) et d’effectuer des commandes de remédiations si nécessaire entre les serveurs VBRs et le serveur VEEAM One. Le guide, recommande son installation, toutefois il n’est obligatoire de déployer l’agent (personnellement, pourquoi ne pas le faire ?).

La partie Agent comporte deux modes. Un mode client (paramètre par défaut) ainsi qu’un mode serveur. La différence entre les deux se trouve dans l’exécution des commandes de remédiation qui ne sont présentes que dans le mode client. La partie serveur quant à elle va gérer les mises à jour des signatures et analyser les journaux VBR.

Et si nous réalisions une petite Map des différents flux ? 🙂 Naturellement, je ne compte pas réinventer la roue, mais juste mettre en avant ce que je vais implémenter plus tard. Pour le reste, il suffira de consulter le lien constructeur.

Comme pour le serveur VEEAM dans un billet précédent, une restriction des flux sortant vers l’extérieur est appliquée sur le serveur VEEAMOne. Ainsi, seul les URLs et NDDs habilités à communiquer avec VEEAM et MS sont autorisés.

Soit pour VEEAM One :

• Serveurs de mise à jour :
  • dev.veeam.com
• Serveurs de licences :
  • one.butler.veeam.com
  • download2.veeam.com

Okay, maintenant que nous voyons un peu plus clair dans nos différents flux, posons-nous la traditionnelle question du « le principe de moindre privilège ».

Access & Less Privileged

Cette partie (peu importe la solution à mettre en place) est un véritable casse-tête. La simplicité voudrait que nous attribuions les permissions root ou system pour avoir la paix.

« Regarde, ça fonctionne ! » J’aime à répondre à ça soit par le traditionnel « Peinture sur merde égal propreté » ou « Je travaillais comme ça quand mon patron m’a viré« .

Soyons sérieux deux secondes… VEEAM nous mache encore une fois le travail et nous allons voir en détail comment configurer les différents comptes avec les moindres privilèges. Cependant, je pense utile de nous remémorer que dans certains cas, il est obligatoire d’attribuer des permissions d’administrateur du domaine ou à privilège (sudo) et malheureusement nous ne pouvons pas faire autrement.

Dans ce cas de figure, il est difficile de faire autrement. Néanmoins, nous pouvons et je dirai même c’est notre devoir de mettre tous les artifices en place pour restreindre le périmètre d’exposition de ce type de compte.

Nous distinguons dans notre cas 3 accès à configurer. L’accès à l’application, l’accès à notre socle de virtualisation et notre infrastructure de sauvegarde.

1 – VEEAM BR : Infrastructure de sauvegarde

Dans le respect des bonnes pratiques, notre serveur VEEAM n’est pas joint au domaine. Nous avons besoin pour interconnecter VEEAMOne à notre serveur VEEAM d’un compte administrateur local.

Pourquoi ? Parce que VEEAMOne doit avoir les droits nécessaires pour déployer son agent. Comme présenté précédemment, il nous faut contraindre ce compte.

Typiquement, nous pouvons considérer ce compte comme une compte de service. Il nous faudra alors interdire les connections locales et distantes à ce compte directement sur le serveur VEEAM.

Attention, étant un compte local il sera nécessaire d’effectuer au minima une rotation du mot de passe une fois par an.

2 – VMWare : Infrastructure de virtualisation

Là, c’est plutôt simple, il suffit d’utiliser directement le compte root de notre VCSA⁴.

NO WWWWAAAAYYYYY !

RTFM⁵ mon gars ! VEEAM explique ce qu’il faut faire (ici). Je ne vais donc pas m’attarder là-dessus.

Là, il y a deux écoles. Je n’ai pas encore fait un article sur le sujet VCSA et personnellement je ne sais pas si j’ai envie d’en faire un car les interfaces changes tout le temps au gré des montées de version VMWare. Bref, il reste à définir si nous souhaitons utiliser des comptes locaux ou un compte du domaine pour interconnecter VEEAMOne à notre environnement VMWare.

Les raisons sont toujours les mêmes. Sécurité, Sécurité et Sécurité.

3 – VEEAMOne : Application

L’application se base également sur le principe de moindre privilège ainsi que sur le principe de RBAC⁶ (un truc vraiment cool pour les SysAdmins).

Nous retrouvons donc les schémas 3-Tiers classiques, utilisateurs lecture seul, utilisateur avec pouvoir et les utilisateurs administrators.

Sur notre serveur VEEAMOne, nous retrouverons ainsi les groupes locaux qu’il siéra à notre guise de peupler en respectant les bonnes pratiques et recommandation avec les ressources de notre domaine.

Pour enfoncer le clou, les rôles énumérés précédemment permettent les actions ci-dessous. A nous de mettre les bonnes ressources techniques en face du bon profil.

Rôles	Permissions
VO Read-Only	Accès à la surveillance des données en lecture seule Accès à la génération de rapport
VO Powered	Accès à la surveillance des données Accès à la génération de rapport
VO Administrator	Accès à l’ensemble de la plateforme Accès à l’administration des données Accès à la génération de rapports Modification de la configuration VEEAMOne

Licensing

Pratiques

Nous considérons que le serveur Windows a été durci au préalable et que nous possédons un serveur à jour.

Nous avons également téléchargé en amont les sources (iso) de Veeam One.

Nous ne traiterons ici que de l’installation d’un server VEEAMOne « AllinOne » (car j’ai un petit lab). Mais il est possible d’envisager un déploiement 3-Tiers (VEEAMOne Server, MSSQL Server et VEEAMOne UI). Je propose quelques choses de standard (car il faut sur un petit LAB se satisfaire du nécessaire et être heureux) sur la base de VEEAM BR, ESXi⁷ et VCSA.

Installation

Nous partons donc du principe que notre serveur Windows est déjà configuré et joint à un domaine (oui oui, j’ai bien écrit joint à un domaine). Que nous avons une appliance vCenter (joint ou non au domaine) ainsi qu’un serveur VEEAM BR (non joint au domaine et préalablement durci et conforme aux recommandations VEEAM.

Les prérequis en termes de ressources doivent être les suivantes (pour une Single Server):

• OS : WIN10, WIN11, WS 2012 à WS 2022
• CPU : 4 cores (minimum)
• RAM : 8 Go (Minimum) / 16 Go (Recommandé)
• Disk : 50 Go pour la SGBD MSSQL et VEEAMOne DB
• Network : 1 Gbps minimum

Top à la vachette, démarrons l’installation !

1 – You are a wizard Veeam ONE !

2 – Server or client ?

3 – Licenses & EULA

4 – License bite ! (Ou restez en Community Edition)

5 – VEEAM One Service Account (si si ombre !)

6 – System Check… Hold on 2 minutes

7 – Install or not 😀 (Customize)

8.0 – Customize, Choose VEEAM Components

8.1 – Customize, Database

8.2 – Customize, DataLocations

8.3 – Customize, Mode

8.4 – Customize, Ports

8.5 – Customize, Resume & Install (sure ?)

9 – Install ongoing, please offer me a coffee <3

10 – CONGRATULATION

A prononcer façon Smash Brosh 🙂

Configuration

Lors du premier lancement du client VEEAMOne, nous allons être invité à configurer l’application. Il faut comprendre par configuration le paramétrage général du serveur. Pour ce qui relève de la configuration des autres vues ou fonctionnalités, cela relèvera d’une partie dédiée dans cet article ou d’un article à part entière (je n’ai pas encore décidé).

De la sorte et je pense qu’il est utile de le souligner une nouvelle fois, un système de supervision et de monitoring sans être notifier reviens à commander un steack frites alors que l’on aime pas les frites et que l’on est végétarien. Hé ben c’est con ! Configurons alors les notifications.

1 – SMTP un incontournable !

Nous commençons à avoir l’habitude avec les solutions VEEAM de configurer les notifications. C’est exactement la même chose que pour VEEAM BR, à l’exception que l’IHM⁸ est d’une couleur différente.

M’autorisez vous à passer cette partie ? Naturellement car je fais ce que je veux 🙂 Le seul point, bien penser à ouvrir les flux outbounds concernant le protocole utilisé. Sinon ba ça marche pas et ça ne court pas non plus… (Il est comique le garçon…)

2 – A qui le postier doit il délivrer le courrier ?

Dans ce cas, nous pouvons ajouter plusieurs adresses mails en destinataire des notifications selon l’état des notifications (Toutes, les erreurs et avertissements, les resolved etc).

Toutefois, cela pose un problème car si nous souhaitons notifier qu’une équipe particulière sur certaines ressources, cela va être difficile de se coltiner toutes les notifications de l’infrastructure et donc d’être pollué…

Il faut voir ce paramétrage ci à destination de l’équipe Cloud, Services Hébergés et autres fiches de poste. Concernant les notifications plus ciblées à destination d’équipe spécialisée, je reviendrai dessus dans la partie Business View.

3 – Politiques de notification

Pour cette étape, je suis un peu un SysAdmin sans personnalité car je vais laisser les paramétrages par défaut.

Il est possible de définir et de modifier un template. Dans mon cas d’usage, je trouve (et encore une fois il va nous dire que c’est son avis personnel…) que ça fait le taf.

4 – SNMP

Encore un classique de la supervision. Qui dit supervision dit log et donc SNMP⁹. Cela permet d’avoir une bonne visibilité de son réseau, des équipements et de l’état de santé de ces derniers.

Je ne l’utilise pas.

HAAAANNNN, NANI !!!!

J’ai une excuse. Dans un contexte professionnel, je préfère utiliser les solutions propriétaires. L’inconvénient, c’est que cela à un coup. Néanmoins, je pense qu’il serait temps de regarder d’un peu plus prêt cette fonctionnalité de collecte.

5 – ITSM : ServiceNow

Et si nous cherchions un peu d’efficience pour notre infrastructure, les équipes opérationnelles ? L’un des rêves d’un SysAdmin (surtout le mien) reste d’intégrer les alertes dans la solution ITSM¹⁰ afin de pouvoir traiter de manière pro-active les alertes systèmes.

VEEAMOne propose de s’interconnecter à la solution ITSM ServiceNow. M***e pas de bol je n’utilise pas cette solution. Donc je passe mon tour…

« Tristesse, ton petit cœur doit saigner et tu dois roter du sang en boule sur ton paillasson ? »

Hé non ! Si VEEAMOne ne propose pas de passerelle avec la solution ITSM que j’utilise (ITOP pour ne pas la nommer), les deux solutions possèdent une API¹¹. Vous voyez où je veux en venir. 🙂

Je prépare cette introduction depuis longtemps et j’espère vous présenter mon connecteur dans le prochain article. Je ne suis pas vache, je vous lâche un petit teasing <3

6 – Le puit de Log

Le puit de log… Fonctionnalité que je n’utilise pas non plus. Mais sur laquelle je devrais me pencher.

Garantir un historique des alarmes déclenchées et centraliser ces dernières seraient vraiment sympa. Toutefois, je rencontre une problématique. Je n’ai pas ce jour mis là main sur une solution libre qui soit facile d’administrer et de maintenir. Libre ne veut pas dire gratuit que nous nous entendons bien.

Par exemple, j’ai utilisé la solution GrayLog. Nous sommes vite limités par la licence communautaire sur le notre de flux journalier échangé. Il suffirait de prendre la CB est hop le tour est joué.

1-0 pour la solution

J’ai voulu mettre à jour la plateforme et j’ai tout cassé. Il suffirait de passer en SaaS chez l’éditeur comme ça plus de problème de MCO.

2-0 pour la solution

Pour le coup, je demande la VAR. Je ne suis pas fan de l’hébergement en SaaS dans ce cas précis. L’arbitre accorde donc 1-1, balle au centre…

Conclusion, il faut que je torture encore quelques cellules grises dans mes travaux nocturnes pour étudier ce point.

7 – Récap

Le petit récapitulatif, comme nous avons l’habitude de l’avoir chez VEEAM. Je trouve cela d’une simplicité et d’une efficacité remarquable. Chose que nous n’avons pas toujours sur d’autres solutions.

Tu vas vraiment nous faire croire que t’as pas d’action chez VEEAM ?

La configuration terminée, nous pouvons admirer notre console vierge et vide de toutes données. Il faut l’avouer, il y a là un côté tristoune. Je rassure, pas pour bien longtemps.

Virtual Infrastructure

La vue Virtual Infrastructure va nous permettre de suivre l’intégralité de l’état de santé ainsi que les évènements de notre SIs depuis le socle de virtualisation jusqu’aux SEs des machines virtuelles.

Comme souligné précédemment, l’objectif est d’être proactif face à un dysfonctionnement d’infrastructure ou d’anomalie sur un serveur virtuelle en production.

VEEAMOne prend en charge les produits suivants, VMWare, VMWare Cloud Director, Microsoft Hyper-V.

Un exemple ci-dessous d’ajout d’une appliance VCSA.

VMWare

1 – Add Server

Sous Virtual Infrastructure, faire un clic droit et ajouter un nouveau serveur.

2 – VMWare Connection

VEEAMOne nous demande si nous souhaitons ajouter une appliance ou un hote directement. Renseignons le nom DNS de notre appliance.

3 – Credentials

J’ai fait le choix (pour l’instant) de ne pas binder mon appliance VCSA à mon AD. C’est pourquoi j’ai créé un compte local svc.veeamon@vsphere.local sur mon appliance avec les permissions nécessaires.

Naturellement, il ne faut pas oublier d’ouvrir les ports interlan dans le cas de segmentation des réseaux.

4 – Summary

Le traditionnel rappel et voilà notre appliance VEEAMOne connecté à notre VSCA.

Veeam Backup & Replication

La vue Veeam Backup & Replication comme son nom l’indique va traiter de la sauvegarde et de l’ensemble des jobs de protection. Si la vue d’infrastructure vient à donner une bonne visibilité de notre infrastructure virtuelle, nous aurons avec cette vue ci une visibilité sur l’ensemble de notre infrastructure VEEAM.

Depuis l’état du serveur de sauvegarde, des jobs en passant par la charge des proxies VEEAM ainsi que l’utilisation des repos de sauvegarde ainsi que le détail des chaines (full et incréments).

Lors de la présentation de la solution dans la partie « Théorique » le déploiement d’un agent de supervision permettra de réaliser en plus de la remontée d’informations la possibilité de réaliser des actions de remédiations.

1 – Add Server

M’sieur, un petit clic droit sur Add Server 🙂

2 – VEEAM BR Connection

Nous renseignons comme précédemment pour l’ajout d’une ressource d’infrastructure le nom DNS de notre serveur VBR. Il est également possible d’intégrer un serveur VB Entreprise Manager.

Je n’utilise pas ce dernier et pourtant c’est le manque de temps en ce moment qui vient ralentir ma boulimie intellectuelle et m’empêche d’avancer.

Je coche volontairement l’installation de l’agent VEEAMOne pour avoir les actions de remédiation et d’avoir le relevé de journaux d’événements ainsi que son analyse.

La seconde coche permet de joindre notre serveur VBR à notre serveur VEEAMOne et donc avoir directement dans la console VBR les informations et performance de notre infrastructure de sauvegarde. (Franchement, il ne faut pas hésiter C’est du read only pas de risque 🙂 )

3 – Credentials

Renseignons le compte local de notre serveur VBR qui va permettre le relevé d’installation. J’ai déjà expliqué les actions préconisées pour garantir un niveau de sécurité acceptable.

Toutefois, rappelons-nous qu’il est nécessaire d’avoir les droits d’administrations pour que VEEAMOne puisse installer l’agent VEEAMOne. Sans quoi vous aurez le joli message ci-dessous <3

4 – Summary

Le récap, le récap, le récap !

Une fois ajoutée, nous obtenons une interface vide. Pas de panique, c’est normal. Ce n’est pas un bug.

En regardant l’image précédente, nous remarquons en bas à droite que l’infrastructure est en cours d’import. Ah ouf ! Il en sera de même avec l’installation de l’agent et la remontée de log. Il faut faire preuve de patience et non pas cliquer 50 fois sur le bouton d’impression au risque de griller notre imprimante. Les données remonteront d’elles-mêmes comme présenté dans le début de cette partie.

Dans la même logique, si nous avons coché l’accès aux tableaux de bords dans la console VBR, il sera nécessaire d’attendre l’intégration des datas.

Dans notre console VBR, dans l’onglet Analytics nous retrouverons les informations sur la planification, durée des jobs. La sollicitation de telle ou telles ressources, l’espace de stockage de nos repos ainsi qu’une vue globale MENSUELLE de nos jobs de sauvegarde (et dire qu’avant cette fonctionnalité je me suis fait iéch à faire des extracts et tableau xlsx…. Je les utilise toujours pour mes indicateurs hein 😉 ).

Sinon, il est tout à fait possible d’avoir les mêmes informations dans la WebConsole VEEAMOne. Si vous savez, le truc qui commence par https et se termine par 1239 du type https://monseveur_VEEAMOne.contoso.com:1239.

Business View

Cette partie est intéressante pour celui qui sait la manier. Personnellement j’ai mis un certain temps à comprendre son mécanisme et l’intérêt que cet onglet peut apporter.

Dans cette « Vue Affaire », il va nous être possible de faire presque quasiment tout ce que nous souhaitons en termes de filtre et d’identification sur les ressources VMs, Hosts, Datastores et Clusters.

Cette vue va donc nous permettre de répondre à des problématiques financières et techniques.

• Financière : Afin d’avoir un rapport précis des ressources consommées par un service (SaaS) ou d’infrastructure (IaaS). D’assurer l’efficacité et l’efficience de notre infrastructure afin de définir si nous sommes en over-capaciting ou under-capaciting. Investir, pas investir ? Prospecter, pas prospecter ? (Mon PDG répondrait sans hésiter OUI ! et il a bien raison)
• Technique : Pour garantir un état de santé par service, la présence de snasphot, la possibilité de notifier que certaines ressources aux bonnes équipes… J’en passe car la liste pourrait être longue.

Sincèrement, je vois la partie Business View comme le pivot et point le plus important pour maitriser son budget ainsi que son SI.

Bon hormis le fait que je laisse l’impression que mon exploitation n’est pas faite à la maison. Objection lecteur ! Mon MCO est fait. Il se trouve que l’erreur disque sur mon second AD est lié à la sauvegarde Windows et que je n’ai pas acquittée cette dernière (Oui j’ai bien écrit Acquitté et non Résoudre).

Mais bon entre nous, un système de monitoring sans erreurs et avertissements ça serait d’un ennui non ?

Par défaut nous avons la vue ci-contre. Il sera alors possible pour nous de définir des nouvelles catégories pour chacune des familles présentée plus tôt. Nous allons réaliser les catégorisations selon 3 critères. *** Single Parameter *** Muliple Conditions *** Grouping expression

Je pense que pour bien comprendre la puissance de ces trois méthodes de catégorisation, il faut que nous nous attardions dessus.

1 – Single Parameter

Comme présenter rapidement plus haut, nous allons catégoriser une ressource sur un groupe d’objet qui se base sur une propriété du type concerné (VMs, Hosts, Datastores ou Clusters).

L’étape qui suit vous demandera si vous souhaitez créer un tag sur l’environnement vSphere ou non. Personnellement je n’utilise pas les tags sur ce genre de catégorisation.

Je reviendrai plus bas sur la notion de tag au sens VMWare du terme car il y a des subtilités à assimiler.

Le cas d’usage pour cette catégorisation (à mon sens) et de filtrer, identifier rapidement des ressources sur des actions, états simples. Je dirais donc parfait pour l’administration et le MCO.

2 – Multiple Parameter

La catégorisation mutli-paramètres va nous offrir plus de possibilité quant à la possibilité de trier et de sélectionner les ressources que nous souhaitons obtenir.

Comme nous pouvons le constater ci-dessous, la liste des critères de ciblage est plutôt conséquente. Passant des paramètres systèmes aux éléments d’infrastructures en réalisant une halte par la sauvegarde. Nous retrouvons également les classiques opérateurs de comparaisons (Equals, Not Equals, Contains, Starts/Ends with…) par rapports à une valeurs.

Comme vu ci-dessus, j’ai choisi ici d’identifier l’ensemble des VMs contenu dans les VM Folder qui contiennent les noms IaaS et SaaS. Il faudra comprendre VM Folder au sens VMWare du terme lors de la création d’un dossier dans la vue VMs & Templates de notre VCSA naturellement.

Contrairement au cas de catégorisation précédent, je vais choisir de créer les tags vSphere. Ainsi, les ressources (VMs) qui se trouvent sous le répertoire parents IaaS se verront identifiés comme un type IaaS. Il en sera de même pour le type SaaS.

C’est là que le sujet commence à devenir intéressant. Car comme évoqué plus tôt, nous commençons à travailler la donnée de notre infrastructure en donnée financière.

Quels est la part de notre infrastructure consommée et allouée à nos services BaaS, SaaS, IaaS, ect… Quels est la part de notre SI allouée à son fonctionnement et la production ?

Je vois dans déjà dans le fond de la salle les yeux pétillants des DAFs, DCs et autres dirigeant d’entreprises. Oui, nous SysAdmins nous savons vous faire faire des économies et apporter un vrai valeur ajoutée <3. (Je développerai ce point dans la conclusion).

3 – Grouping Expression

Je crois que c’est la méthode de catégorisation que je préfère car elle permet de faire presque tout ce que l’on souhaite. Cette vue est orientée « développeur » (le style old school VisualBasic).

Ci-dessous, un exemple avec la catégorie VMs with Snapshots qui va selon la date des snapshots nous offrir une vue et métriques sur les snasphots présent si c’est la durée de vie de ces derniers est inférieurs à 1 jour, 7 jours, 30 jours. Dans cet usage, cela permet au SysAdmin d’avoir une granularité sur une tâche bien distincte et dans certaines situations maintenir le curseur sur ce qui est acceptable ou non.

Au-delà de cette possibilité, il est également possible de gérer (créer, pas supprimer hein) les tags vSphere de manière dynamique selon l’évolution de l’infrastructure de notre arborescence VMs & Templates. Ainsi, admettons que nous créons une nouvelle bulle SaaS ou IaaS sous cette même infrastructure, l’ensemble des ressources qui se trouvent sous ce dernier sera identifié comme IaaS ou SaaS et du nom du répertoire. Pratique donc par la suite de sortir des indicateurs de ressources et de faire une facturation à la carte (refacturation interne ou facturation à un client final).

Pour bien comprendre l’intérêt des tags vSphere générés par VEEAMOne, pourquoi ne pas se lancer un petit RVTools des familles ? 🙂

C’est un coup des Indiens Lucky Luke, il y a des flèches partout !

Au delà de mon humour douteux (ainsi que mon admiration pour Terence Hill quand j’étais jeune garçon), nous avons là un outil puissant. La création des tags par catégorisation au délà du client et de la solution VEEAMOne est exploitable dans VMWare. Donc, il va nous être possible avec de l’huile de coude et un peu de rigueur d’établir des métriques et rapports sur l’évolution d’une bulle, d’un service. Et pourquoi pas établir un outil de capacity planning ? Tout devient possible.

J’avais pour projet de créer une petite application sur un moteur SQLite ou MariaDB un outil de suivi des ressources sur 13 mois glissants. Malheureusement, pour moi il faut faire du web…

Oui, on sait, c’est une étape traumatisante de ta vie. Tu ne voudrais pas débuter une thérapie et arrêter de nous briser les noix avec ça ?

Oui, promis je vais y penser. Mais au délà du traumatisme, il faut du temps et difficile de me cloner (et je ne suis pas certain que cela soit une bonne chose). Toutefois et dans le cadre professionnel, j’ai développé un fichier excel qui fait le taf mais comme tous fichiers excel, ce dernier ne connait que son maitre. C’est pour ça qu’une petite application web serait sympa. Et je crois qu’il est important de souligner que les fichiers excel pour faire tout et rien. C’est has been maintenant car il faut faire du PowerBI… Je pense que je ferai un article là-dessus quand j’aurai redéveloppé une solution plus simple (en gros sans code en VB et des formules de 5 km de long).

J’ai déjà bien abordé le sujet des tags. Il y a néanmoins une chose importante à savoir sur l’utilisation de ces derniers. L’application des tags vSphere (création) peut prendre un temps certain c’est pourquoi il faut être patient (selon la documentation cela peut prendre jusqu’à 3 heures et plus selon la taille de l’infrastructure). De plus il sera nécessaire de se rendre dans la console WEB pour réaliser une collection des données.

Par défaut cette dernière est définit quotidiennement à 03:00 AM.

J’ai personnellement modifié cette dernière pour qu’elle se lance toutes les 3heures. Attention à vos performances. Il est également possible de lancer une collecte de données manuellement.

VEEAM Report

La partie Report se passe sur le client Web (https://monVEEAMOne.contoso.lan:1239). Une fois connecté, c’est dans la partie Dashboard et Reports que nous allons avoir les outils les plus pertinents.

Dashboard

Dans le tableau principal, nous allons retrouver les catégories par défaut. Il sera toutefois possible d’ajouter des « tuiles » avec des vues personnalisées. Je trouve que les tuiles présentes suffisent largement à mon activité. Je pense qu’il est important de présenter chacune d’entre elles. Pourquoi ? Parce qu’il est facile de ne pas comprendre les informations présentées et de passer à côté de métriques et d’éléments qui faciliterons la prise de décision technique et financière. 🙂

1 – Veeam Backup & Réplication

Sans grande surprise, nous retrouvons ce que nous avions déjà vu précédemment dans VEEAM BR dans la rubrique Analytics. Normal puisque VEEAMBR vient chercher les métriques dans VEEAMOne qui vient lui aussi les chercher dans VEEAMBR.

La boucle est bouclée.

Blague à part et j’adore le phénomène démo. J’ai la majorité de mes jobs qui ne passent pas. Cela se retranscrit dans mes charts. A moi de résoudre le problème.

Merci qui ? Merci Jacquie et … Non un peu de sérieux ! Merci VEEAM One <3

2 – HeatMap

Comme pour la partie précédente, nous retrouvons également cette partie dans la console VEEAM BR.

Si la première partie de l’accordéon concernait les jobs et l’état des jobs, là nous sommes plus sur les performances et usages des différentes ressources de l’infrastructures VEEAM. La notion de dégradée sera utilisée de vert à rouge selon l’usage et la sollicitation des différents composant VEEAM.

3 – vSphere Trends

J’avoue que cette vue n’est pas bien parlante dans mon cas car je ne possède pas de Cluster VMware.

Toutefois, cette vue va permettre d’afficher les tendances de notre cluster concernant l’utilisation des différentes ressources. Parfait pour identifier les pics et évolution du SI sur une période.

4 – vSphere Alarms

L’une de mes vues favorites. Pourquoi ? Car elle indique et offre une visibilité totale de l’état de vie de notre SI. L’évolution du nombre d’avertissements ou d’erreurs critiques.

Au déla des métriques quantitatives, ces métriques sont identifiées par catégories. Ce qui facilite grandement et facilement les actions prédictives vis à vis d’une panne d’infrastructure logique ou physique.

5 – vSphere Hosts & Clusters

Nous retrouvons comme dans la tuile numéro 3 – vSphere Trends le même constat aussi triste soit-il dans mon cas. Pas de cluster, pas de métrique…

Ce qui n’est que partiellement vrai. Puisque nous constatons dans cette vue la tendance de consommation à la hausse ou à la baisse des ressources d’un hôte VMWare ou d’un cluster. Cela peut donc se traduire par, à la hausse ou en sous-évaluation de l’infrastructure et un besoin de renforcer cette dernière. A la baisse, une infrastructure surévaluation de l’infrastructure vis à vis de son usage quotidien.

Dans la logique, je dirai que nous devons tendre vers une constante en acceptant un léger taux de variation et non à une fonction croissante, décroissante.

6 – vSphere Datastores

Un incontournable ! Pour les nostalgiques des ayatollahs de l’exploitation à travers les RVTools. Nous retrouvons l’évolution des datastores à la hausse comme à la baisse sur l’espace disponible. La visibilité des vmdks quant à l’espace consommé et l’espace disponible. La latence des différents datastores (impeccable pour la prédiction d’un disque qui va lâcher), les IOPS pour chaque datastore.

Que dire de plus. C’est merveilleux, c’est extra !

7- vSphere VMs

J’ai l’impression de me répéter… Après les datastores et la partie hosts & clusters, maintenant c’est au tour des virtuals machines.

Cette fenêtre permet d’identifier assez rapidement si une VMs nécessite l’ajout de ressources supplémentaires ou une surallocation. Elle permet également dans un certain contexte d’orienter un potentiel dysfonctionnement de type hardware, ou software (mauvaise configuration d’une application métier par exemple comme ça au hasard).

8 – vSphere Infrastructure

De nouveau un petit coup de pouce sur les ressources disponibles et sur les ressources consommées.

Parfait pour éviter l’overprovisionning, le balloning 🙂

9 – vSphere Capacity Planning

La vue crainte par les SysAdmins, DSI et DAF.

Cela correspond à partir des tendances d’usage en une projection de la durée de vie de l’infrastructure et donc de son renouvellement ou de sa consolidation en ajoutant des ressources supplémentaires.

En gros :

Exprimer le besoin, Présenter le devis, Faire valider l’investissement, Obtenir le chèque signé, Mettre en production les ressources. Simple non ? :p

Pour le reste, il suffit d’un peu d’imagination et d’établir les métriques que l’on souhaite obtenir et pourquoi pas générer les rapports et se les faire envoyer dans notre boite mail ?

Le conseil que je donnerai, c’est de se perdre dans le choix des possibles qu’offre VEEAMOne et de garder en tête « Est ce que cela m’apporte une valeur ajoutée business et technique ?« . Si c’est le cas alors vous êtes, nous sommes sur la bonne voie 🙂

Report

La fonctionnalité du Report et de générer des rapports. Merci Capt’aine Obvious…

Oooooh ba si on ne peut plus rigoler… Pour faire simple nous allons être dans la capacité de générer des rapports précis sur des thématiques précises :

• Charge de l’infrastructure
• Facturation VEEAM Backup
• Supervision VEEAM Backup
• Optimisation vSphere
• Capacity Planning
• …

Il suffit de regarde l’interface.

Prenons deux exemples. L’un orienté pour le business et l’autre pour la technique.

1 – Business – Facturation VEEAM Backup

Admettons que nous souhaitons vérifier ce que nous devrions facturer à un client des bulles T0 et T1 mensuellement. Et que le cout de la sauvegarde est de 24,79€ du TB.

Nous configurons les paramètres en sélectionnant nos différents tags T0 et T1 ainsi que les jobs concernés. Nous précisons la période sur le mois en cours. Puis nous cliquons sur Preview en haut à gauche.

Et tadam ! Voilà notre rapport (sur deux pages).

Page 1	Page 2

Franchement, que demander de plus ? Nous avons même inclus le cout de notre repository (multipliant le cout par 4). Et nous voilà avec le cout pour le mois en cours. A oui nous sommes le 01 Octobre…. J’ai peut-être eu la main lourde sur le prix unitaire au TB 🙂

Bref, pas mal pour mettre en évidence le ROI¹² <3

2 – Technique – Surdimensionnement des VMs

Nous allons vérifier par le biais d’un rapport que nos ressources allouées sur notre infrastructure ne sont pas sous/surprovisonnées. Dans le cas contraire, il faudra engager ou non des actions.

On valide une nouvelle fois sur Preview, puis on tourne trois fois sur sa chaise de bureau.

Page 1	Page 2	Page 3

Alors c’est super nous pouvons faire des économies en réduisant considérablement les ressources !

Tout doux bijoux !

Ce ne sont que des recommandations, il ne faut pas prendre tout pour argent comptant. L’évaluation est une moyenne et viens prendre en compte les piques de suractivités. Mais ce n’est pas pour autant qu’il ne faut pas réfléchir. Dans le cas de mon lab, les ressources se (je ne sais pas si je peux me permettre cette expression… Allez… Vous ferez mon procès ultérieurement) touchent ! Mais si nous ciblons une heure bien précise (genre sauvegarde par exemple) les recommandations ne seront pas les mêmes. Il est également important de bien faire attention au paramètre de génération du rapport.

Le rapport sera différent si nous considérons le compteur de vRAM en « Active » et « Consumed ».

Pourquoi avoir pris ces deux exemples ? Tout simplement pour montrer la dimension économique et technique de la supervision. Dans un monde de brut où nous licencions au vCPU, il est important de maitriser l’allocation des ressources. Il est également important de ne pas mettre en péril son organisation quant à la sauvegarde vis à vis de son activité tout comme mettre celle-ci en péril parce que cette dernière représente un cout certain.

Dans un contexte particulier de Service Provider (Fournisseur de Service), il est également important d’avoir un curseur le plus juste possible entre la facturation client et le service délivré sans offrir des ressources sans le vouloir et vendre à perte.

Les rapports, c’est la vie.

Conclusion

La supervision et l’ensemble des outils qui sont mis à disposition par VEEAMOne permettent d’unifier et de rendre la Technique au service de l’administration et de la stratégie financière. Une telle synergie ne doit pas être négligée et doit être mis en place.

De par mon expérience de responsable informatique auprès des clients que j’ai accompagnés, l’informatique et la gestion du SI sont toujours trop onéreux. Menant souvent à l’accumulation à terme d’une dette technique conséquente qui devra être acquitter plus tard. L’erreur qui est faite à ce moment par le responsable informatique est de ne pas avoir présenté les choses sous le bon angle.

Mais alors qu’est ce que le bon angle pour éviter la traditionnelle tragédie racinienne ou choix cornélien ?

Je pense que pour répondre à cette question, il faut que le Responsable Informatique prenne de la hauteur pour présenter le SI sans aborder de terme technique pour commencer et présenter des métriques ainsi que des projections sur l’évolution du SI.

Je fais un aparté, sans déco**é une fois, j’ai un DG qui a explosé en réunion à la suite de la prononciation du mot switch xD. La personne qui avait énuméré le mot a dû donner une définition. Chose qu’il a fait en parlant de commutateur… Le DG a explosé de nouveau. Mon collègue à côté fini par intervenir (avant un nouvelle intervention de la personne en interne) en expliquant « c’est une multiprise réseaux ». Le DG a compris sans problème. 🙂 Aparté terminé.

De rapprocher ce dernier sur l’activité de l’organisation et de définir les axes d’évolutions possibles. Un plus serait de soutenir un budget prévisionnel ainsi qu’un plan d’amortissement. Présenter de cette façon en tenant compte du besoin et de l’activité de l’organisation va faciliter les décisions et permettre à la direction d’avoir une vision claire de son informatique. Mais pour en arriver là, il est nécessaire de savoir ce que nous souhaitons surveiller et interpréter. N’oublions pas que si les diseuses de bonnes aventures lisent dans les boules de cristal, les membres de la direction lisent dans les fichiers excels et les SysAdmins dans les logs. <3

Je pense qu’il est donc primordiale d’utiliser VEEAMOne (non je n’ai toujours pas d’action chez VEEAM) pour répondre aux besoins du quotidien d’un SysAdmin ainsi que pour la stratégie d’une organisation. Il faut cependant de la rigueur et ne pas se disperser dans les catégorisations et l’élaboration des rapports. L’objectif étant de maitriser son SI, se prémunir des pannes et de garantir une stratégie d’investissement financier.

VEEAM ? One ! Raviolis ? Je relance avec une requête CIM. Je contre avec un arbre ! Dommage, il y avait un DAF en diagonal. Aïe Aïe Aïe, votre SI va chercher son solde de tout compte. Mais vous gagnez un pins de Marlène SCHIAPPA. Alors heureux ?

Erwan GUILLEMARD

Sources

• VEEAM One : Guide
• VEEAM One : Guide – Ports
• VEEAM One : Supported Virtualization Platforms
• VEEAM One : Supported VEEAM BR
• VEEAM One : Supported System
• VEEAM One : Sizing
• ITOP
• RVTOOLS

1. MO : Mode Opératoire ↩︎
2. VBR : VEEAM Backup et Réplication ↩︎
3. VCC : VEEAM CloudConnect ↩︎
4. VCSA : VCenter Server Appliance ↩︎
5. RTFM : Read The Fucking Manual (please 🙂 ) ↩︎
6. RBAC : Role Based Access Control ↩︎
7. ESXi : Elastic Sky X Integrated ↩︎
8. IHM : Interface Homme Machine ↩︎
9. SNMP : Simple Network Management Protocol ↩︎
10. ITSM : Information Technology Service Management  ↩︎
11. API : Application Programming Interface ↩︎
12. ROI : Return On Investisment ↩︎

À L.LU , mon étoile, le plus parfait des sciences.

Si hardened est un bien vilain mot, immuable ne vaut pas mieux. Et à chaque fois que j’ai évoqué ces termes à quelqu’un j’ai dû donner une définition.

Qui demeure inchangé, ne subit pas ou ne paraît pas subir de modification pendant un temps relativement long

Dictionnaire Larousse

Le titre de ce billet ainsi que les multiples appels du pied du précédent article technique sur VEEAM, ne laisse pas de doute quant au fil conducteur de ce feuillet technique.

Nous aborderons ici la sauvegarde dit immuable ou inaltérable pour répondre à l’un des bonnes pratiques et recommandations de la sauvegarde.

Prérequis

• SE : Ubuntu Server 20.04 LTS
• Apps : VEEAM B&R 12.1
• Autres :
  • Environnement GNU LINUX Durci
  • VEEAM B&R 12.1

Avant Propos

Le pourquoi du comment de la sauvegarde Immuable ou Hardened vient d’un constat. Avec l’évolution depuis 2015 des virus de nature cryptographique, les attaquants ne s’amusent plus à effacer toutes traces d’un SI (car c’est moins drôle de nous jours ce coup de HOCUS, POCUS) mais de chiffrer ce dernier de virer les sauvegardes et de tenir une situation de prise d’otage (sans permettre un syndrome de Stockholm) et de chantage à divulguer les données d’entreprise sur le Dark & Deep Web. Toutefois, les rançons demandées dans la grande majorité des cas sont indexées sur le CA des sociétés piègés ou de la nature critique des données extorquées…

Alors il y a bien des techniques, mécanismes pour assurer une sauvegarde hors ligne. L’une des plus vieilles à ma connaissance reste la sauvegarde sur bande (Tape). Même si cette dernière comme le langage COBOL était amené à mourir car dépassé par notre évolution technologique. Force est de constatée, que cette technologie reste l’un des mécanismes fiables pour assurer une sauvegarde hors ligne. Il y a bien la sauvegarde sur média externe (pour ne pas dire HDD) qui fonctionne très bien. Mais ce genre de solution, voyez vous, ça rentre parfaitement dans le cadre d’une PME ou d’un SI local (pour ne pas dire OnPremise) qui n’a pas un SI avec des fluctuations de stockage à la hausse. Pour résumer, comment assurer la sauvegarde déconnecté dans un datacenter ou une infrastructure qui peut être amené à grossir rapidement ?

Je vois (c’est mon point de vu. Si vous n’êtes pas d’accord, je suis prêt à échanger sur le sujet) les avantages et inconvénients suivants :

« Ouai mais qu’est ce que tu fais du Stockage Objet, des buckets toussa toussa ? C’est bien inaltérable non ? »

Oui et non. Je n’ai pas encore eu le loisir de jouer avec les stockages objets S3 ou d’autres technologies qui se base sur ce standard. Avant toutes choses, il est je pense important de se poser la question de la nature des données que nous souhaitons sauvegarder. Il y a des avantages et des inconvénients au type de sauvegarde en blocks et objets. Certains types de données sont plus favorables à l’un ou l’autre des technologies de sauvegarde. Bref, spoiler c’est un billet en réflexion et sur lequel je me dois de me motiver (à coup de grand coup de pied au c*l car je suis à l’ouest du néant en ce moment).

Bref, si nous rattrapons notre fil d’ariane, je vois dans une cloud privé un facilité à choisir la sauvegarde hardened sur un serveur dédié. Si le SI augmente et que nous devons ajouter des ressources des nœuds supplémentaires, j’ajoute un nouveau repo. Si mon SI diminue, je recycle mon serveur de repository pour un autre usage. Seul hic, cela demande de bonnes compétences en GNU/LINUX (mais cela est il vraiment un frein ? Les compétences ça s’acquiert non 🙂 ).

Pour ce billet, je vais tricher un peu. N’ayant pas de repo physique sur mon lab (et que mon lab tiens à mon poste perso), nous partirons d’un serveur virtuel qui « jouera » le rôle de notre repo physique.

Ce dernier sera sur un SE¹, Ubuntu Server 20.04 LTS² durci préalablement selon le guide de recommandation de l’ANSSI³. Un disque pour la sauvegarde est dédié, monté et formaté en XFS⁴.

Euh Question M’sieur GUIGUI ! Toi qui nous rabache du RHEL matin, midi et soir. Pourquoi d’un coup tu pars sur un Ubuntu ? Ca t’a pris comme un envie de ch**r de changer de distrib ?

A cette question, je répondrai tendrement qu’il s’agit simplement et tout bonnement des prérequis de l’éditeur VEEAM. Sinon, la question n’aurait pas eu lieu :rhel: (pour ceux qui ont connu le :noel: ).

Fin de l’avant propos, place à la lecture du menu avant de mettre un coup de fourchette.

Théorie

Attaquons donc ce menu qui nous fait tant de l’oeil. La première question que nous nous devons de poser est « Qu’est ce que l’immuabilité ? » et la seconde question, « Comment fonctionne t’elle ? »

Introduction à l’ i-mmuabilité

L’immuabilité au sens UNIX du texte existe depuis le 16 Janvier 1996. Cette commande est présente dans le paquet E2fsprogs de la release 1.02. (Si je me fourvoie, merci de me le dire car j’ai du mal à trouver l’histoire de cette dernière…).

Cette commande permet de définir des attributs complémentaires sur les systèmes de fichiers dont notamment l’immuabilité des fichiers.

Pour manipuler ces attributs, nous pouvons utiliser l’ensemble des commandes suivantes :

• chattr
• lsattr
• getattr
• setxattr

Observons ci dessous l’ensemble des commandes suivantes :

$ sudo chattr +i test.txt
$ sudo lsattr test.txt
$ sudo rm -Rf test.txt
$ sudo chattr -i test.txt
$ sudo lsattr test.txt
$ sudo rm -Rf test.txt

J’ai appliqué l’attribut d’immutabilité sur le fichier test.txt et surprise, même en élevant mes droits, je ne suis pas autorisé à supprimer le document. Cela ne sera possible qu’en retirant l’attribut. Nous tenons le début de notre mécanisme.

Ouvrez le GUILLEMARD « 

Je pense après une courte nuit de réflexion que je dédierai un article sur les attributs étendus car il y a énormément de matière sur le sujet. De plus, j’ai ouvert the PANDORAS BOX (toi aussi tu te souviens des jours anciens des LANs sur AoM ? Petit canaillou de cheater va) et je me dois de boire jusqu’à la lie ce module et l’éventail des fonctionnalités qu’il propose.

«  Fermez le GUILLEMARD

Mais alors comment cette fonctionnalité va t-elle être pilotée par notre serveur VEEAM ?

V-immutability-M

Là deux possibilités. Either you speak and read english and you can directly jump to the Veeam hardened guide. Ou alors on peut regarder ensemble ma compréhension du sujet.

Après tout, je n’ai eu que 5/20 au BAC en LV1 Anglais, ça promet d’être sympa 🙂 (Si si et j’ai même pas été au rattrapage ! Et il est content…)

Bref, nous verrons plus bas lors du déploiement que lorsque nous ajoutons notre Serveur Ubuntu en tant que Single Use Credential nous allons déployer les rôles :

• Transport : (veeamtransport) pour le service datamover (port tcp/6162)
• Installer : (veeamdeploymentsvc) pour déployer l’ensemble des composants et permettre de maintenir à jour les différents composants (ports tcp/2500

Toutefois, c’est lorsque nous déclarerons notre repository en tant que Hardened repository que cela va devenir intéressant. Car c’est à ce moment que nous allons définir les paramètres de gestion de l’immuabilité sur une période minimum de 7 jours (promis je reviendrai un jour sur la magie du nombre 7). Bref une fois configuré, voilà les services les plus importants.

• VEEAM Data Mover : Ces ce dernier qui va communiquer avec notre serveur VEEAM et récupérer les paramètres de temps quant aux datas qui doivent être inaltérables. Une fois les informations en sa possession, il réalise une passe décisive au service ci dessous VEEAM Immutability Service (veeamimmureposvc), comme la passe décisive de Djorkaeff à Thuram à la 47eme minutes du match France-Croatie en 1998 (Souviens toi du 12 Juillet 1998 !).
• VEEAM Immutability Service : Va aller mettre une patate à Jean-Pierre… Promis j’arrête, Bah Pourquoi ?… Tu vas la fermer ta grande gu***e !! Ce service va vérifier sur les chaque fichiers de backup toutes les 20 minutes les attributs immuables jusqu’à ce que le date de fin soit atteinte. Ce service est un sous service de VEEAM Data Mover.

A partir de la version 12.1.0.2131, le mécanisme change avec un control, détection sur un potentiel décalage de temps.

Lorsque le VEEAM Immutability Service démarre, un fichier timeLog va être créé sous /etc/veeam/immureposvc/. Ce fichier sera mis à jour toutes les 10 minutes.

Oui mais que se passerai t-il si la valeur du moveTime ou accelerationTime dépasse 24 heures ?

Par sécurité, les données relatifs aux opérations de rétentions seront bloqués. Un message d’avertissement remontera dans la session du job de sauvegarde. Ce qui est rassurant. Oui mais voilà, comment j’unlock la situation ? Ba en suivant le KB mon gars…

Architecture

Dans les recommandations et l’un des prérequis de l’implémentation d’un repository hardened est d’avoir un équipement dédié sans surcouche de virtualisation. Nous parlons donc de serveur et non pas d’hyperviseur.

En dehors des bonnes pratiques de configuration d’un serveur, je ne m’intéresserai qu’à la partie réseau. La configuration de la partie ILO/IDRAC/IPMI ne sera pas abordée. Pourquoi ? car je n’en ai pas envie et surtout je n’ai pas les moyens de le mettre en œuvre sur mon lab. Peut être un jour dans un autre article.

Au vu de la criticité de ce que nous souhaitons mettre en place, il nous faut dissocier la partie management de la partie sauvegarde.

Avec des équipements d’infrastructures adéquates et selon la volumétrie de datas à sauvegarder, l’agrégation d’interfaces est nécessaire. Au minima SFP+⁵, au maximum FC⁶. Assurer les performances réseaux sont un fait, toutefois si le stockage ne suit pas et génère un goulot d’étranglement (bolteneck), cela ne sert pas à grand chose.

Réseau

Bien entendu, si notre Firewall gère les liaisons supérieurs à 1 Gbits/s, il y a un intérêt de faire un VLAN dédié à l’immuabilité dissocié de la sauvegarde. Dans le cas contraire et assurer de bonne performance, il conviendra de rester dans le même subnet et de passer par commutation.

Encore une fois, si nous avons de la micro segmentation, cela facilitera grandement les choses sur un même subnet. Dans le cas contraire, il sera nécessaire de définir les règles côté repo selon les interfaces, sources et destinations avec les ports et protocoles autorisées à transiter.

Lors de la configuration du repository et donc sans restriction les flux réseaux sont les suivants :

Une fois les ressources push du serveur VEEAM vers le serveur hardened (tcp:22), le service VEEAM Installer se charge d’installer et de déployer les composants (tcp:6160). Une fois les dépendances installées, la sauvegarde se déroulera à travers le service VEEAM Data Mover (tcp:6162) ainsi que le service Mount Server (tcp:2500-3000).

Soit au final nous n’avons besoin que des flux suivants :

Ok, ça c’est pour VEEAM, mais niveau serveur physique, il n’y a pas des choses à faire ?

Bien vu l’aveugle. Il sera nécessaire d’autoriser les protocoles :

Users & Permissions

Dans l’idée, il convient d’utiliser un compte utilisateur pour la sauvegarde veeam. Ce dernier aura la charge de quelques services. Ce compte ne doit en aucun cas être membre du groupe SUDO. Il l’est uniquement lors du déploiement et lors du MCO logiciel. Ensuite les droits doivent lui être retirés.

Il en va de même que l’accès au répertoire qui va contenir les sauvegardes doivent avoir des droits restreints à notre seul et unique utilisateur VEEAM que ce soit en tant qu’utilisateur et groupe.

Les droits devant être défini sur 700.

Mouai, c’est enfoncer une porte ouverte non ? Ouai ba j’ai vu des SysAdmins faire des choses à la limite de faire voir des choses terribles à un petit garçon.

Il en va de soi, mais le sticky bit on oublie. Perso, je ne comprends qu’elle serait l’utilité du sticky bit. Mais bon, si VEEAM le précise, c’est bien que certains SysAdmins ont essayés.

Chaînes, maillons, et immutabilité

Pour assurer l’immuabilité des données de nos chaines, le mécanisme qui sera utilisé sera le même que pour la Foreward Incremental avec automatiquement une active full ou une syntetic full.

Pourquoi ? Une petit schéma s’impose.

Partons du principe que nous définissions le nombre de point d’immuabilité à 7 jours. Avec une synthétique full hebdomadaire tous les dimanches.

Sauf que voilà, il y a un problème. Le premier point immuable est une full et le dernier point avant la dernière full est une incrémental (Sunday to Saturday). L’immuabilité étant défini à 7 jours les points sont donc inaltérables tant que l’échéance du dernier point incrémental n’est pas atteint. Si la full est supprimée les incréments ne sont pas utile. Donc nous devons attendre de nouveau 7 jours pour supprimer la première chaine et la création d’une troisième full.

Nous avons pas 7 points inaltérables mais 13 points.

Une fois la full réalisée le 3 dimanches nous passons à 14 points. C’est à ce moment là, une fois la full terminée et rendu inaltérable que les 6 premières points de la chaine se verront retirés l’attribut d’immuabilité puis les maillons seront supprimés (Le principe, se base sur le Grand-Père, Père et fils).

Et puis on recommence.

Donc nous avons un minimum de 7 points de rétention et un maximum de 13 points.

Un point sur lequel je n’ai toutefois pas encore fait de test, reste le traitement de l’externalisation (backup copy). Le principe de GFS doit alors être configuré. J’essaierai plus tard.

Je pense que maintenant nous avons toutes les informations requises pour passer à la pratique. Il n’est pas impossible que certaines parties ne soient pas toutes à fait complètes. Il est difficile de tout couvrir et de ne rien oublier. Mais on peut toujours échanger pour toutes questions.

Pratique

Configuration Repository

$ sudo useradd usr.veeam
$ sudo passwd usr.veeam

$ sudo usermod -aG sudo usr.veeam

$ sudo gpasswd -d usr.veeam sudo

$ sudo gdisk /dev/sdX
   * n
   * 1
   * Paramètres par défaut
   * 8300
   * w
   * y

$ sudo mkfs.xfs /dev/sdX1

$ sudo mkdir /mnt/veeam
$ sudo mkdir /mnt/veeam/hardened_repository
$ sudo mount -o rw /dev/sdX1 /mnt/veeam/hardened_repository

$ sudo chmod 700 -R /mnt/veeam/hardened_repository
$ sudo chown usr.veeam:usr.veeam /mnt/veeam/hardened_repository

Si je n’ai rien omis, nous pouvons passer à la suite et toutes les étapes devraient bien se passer. Dans le cas contraire, je vous autorise à me donner une grande tape sur l’épaule, promis je vous dirai merci pour ne pas m’en reprendre une dizaine.

Intégration dans VEEAM

Ajout du serveur Linux

1 – Scream my Name !

Dans l’onglet Backup Infrastructure, sélectionnez ajouter un serveur. Puis ajouter un nouveau serveur Linux.

Comme ci-dessous vous avez deux possibilités. Soit vous ajoutez l’IP de votre repo (absence de serveur DNS dans mon cas et flemme d’aller faire une surcharge dans le fichier host juste pour le lab) ou d’ajouter le nom DNS. Ayant plusieurs repositories, j’aime bien mettre une petite description (surtout en l’absence de nom DNS).

2 – Linux Credential (une fois seulement)

Dans la partie SSH Connection, nous n’avons pas d’entrée dans le gestionnaire de mot de passe de notre VEEAM. Et nous ne voulons surtout pas que nos informations d’authentifications soient stockées (Sinon à quoi faire du hardened ?).

Cliquons donc sur Add et sélectionnons la dernière proposition « Single-use credentials« . Normalement vous devriez avoir l’écran ci-dessous.

Si vous avez fait les choses proprement, vous renseignez le login de votre compte utilisateur propre à VEEAM avec son petit mot de passe. Dans mon cas svc.veeam et password1234 ou azerty1234. Cochez la case d’élévation de privilège ainsi que la case « Use su if sudo fails » et là, renseigner le mot de passe du compte root.

Toujours si vous avez bien fait les choses, le compte svc.veeam est à ce moment un compte membre du groupe sudo. Donc un utilisateur à privilège le temps de l’installation. Si ce n’est pas le cas, ajoutez le :

$ sudo usermod -aG sudo svc.veeam

Pour le fun, essayer de mettre en compte utilisateur le compte root. Normalement, VEEAM devrait exprimer votre nom indien avec sa main « Dresser avec le Majeur« . 🙂

3 – Actions Review

Si vous êtes là c’est que le serveur VEEAM arrive à pu initier la connexion en SSH avec notre futur repository immuable.

Les composants transport et installer vont être déployés. Ces derniers ne sont pas déjà présent sur le serveur. Pour le moment pas un faux pas !

Passons à l’étape suivante.

4 – Jamais du premier coup 😉

Bon ba nous voilà comme un con sur un quai de gare un jour de grève à la SNCF… Ca ne fonctionne pas BORDEL ! (Pourquoi tu n’as pas censurer l’injure ? Parce que je suis frustré d’avoir durci une saloperie de système GNU/LINUX dans l’état de l’art et d’avoir des erreurs de ce type. Je suis pas une base de loisir MERDE !)

Monsieur, Calmez vous ! Oui, c’est bon. Pas de castagne. LINUX et VEEAM sont sympa car ils nous donnent gentiment le message d’insulte que l’un donne à l’autre. C’est alors qu’en bon copain nous allons arrondir les angles pour que VEEAM et notre repo LINUX puissent fleurter ensemble.

L’une des mesures de sécurité que j’applique sur mes systèmes GNU en terme de durcissement est d’interdire l’exécution sur la partition /var et /tmp. Donc un petit remove de l’argument noexec et un remount des partitions et c’est repartie comme en 40 ! (Il y a quelques choses d’autres à faire mais je le garde pour moi).

On relance un Previous, puis un Next pour relancer le déploiement. Là, à la surprise générale, l’installation se déroule sans accro.

Alors elle est pas belle la vie ?

5 – Congratulations

L’installation est terminée. Les composants ont bien été déployées nous avons ci-dessous le récapitulatif.

Toutefois, nous devons remettre en l’état les quelques points de sécurité que nous avons assouplis pour permettre l’arrimage de notre repository Hardened LINUX à notre serveur VEEAM.

• Retirer l’utilisateur svc.veeam du groupe sudo
• Rétablir les arguments noexec sur les partitions /var, /tmp
• Rétablir les paramètres que l’auteur a vraiment décider de ne pas divulger

Ajout du repository

1 – Quels types choisir ?

Choisissons le type de repository pour déclarer notre repo hardened, soit Direct Attached Storage.

2 – Linux Hardened Repository

Dans les choix, j’hésite vraiment sur l’option pour notre type de repo. Peut-être la réponse numéro 3, Linux (Hardened Repository) ?

3 – Scream my Name (Again)

On note le nom de notre repo. Tachons donc de rester logique et de choisir un nom dans le standard des repositories. Pour ma part REPO_HARDENED_01. Comme j’aurais pu avoir un REPO_SVG_01 ou REPO_EXT_01. Soignons pragmatique Père UBU par ma chandelle verte !

4 – Server Selection

Le serveur ayant été ajouté précédemment nous avons le listing de chacune des partitions présentent et montée.

Dans la liste (5ème positions) nous retrouvons bien notre partition sous /mnt/veeam/hardened_repository monté sur /dev/sdb1.

5 – Choix du repository (Path)

Sélectionnons la partition qui nous intéresse.

Activons ensuite les paramètres de clonage rapide sur les volumes XFS. Je défini la durée de l’immuabilité sur 14 jours (le minimum étant 7 jours). Je limite le nombre de tâche parallélisé à 4.

Dans les options avancées, j’ai pour habitude d’activer l’alignement des blocks pour améliorer les performances quant à la sauvegarde et à la restauration malgré une légère hausse du CPU.

J’active également le paramètre d’utiliser le paramètre per machine backup files car il améliore les performances de stockage pour les équipements qui bénéficient de flux important d’I/O. Ce qui tombe bien est notre cas.

Les deux autres options ne doivent pas être cochés, puisque nous n’avons pas de support rotatif et l’option de décompression n’est pas compatible avec la sauvegarde immuable.

6 – Where is the mount Server ?

De nouveau nous avons un petit récapitulatif des rôles à ajouter ou déjà présent sur notre repo.

• Transport
• vPower NFS
• Mount Server

Il est possible de cocher la case de recherche de chaine existante. Ce n’est pas notre cas.

7 – Applying

Nous appliquons la configuration de notre repo. Deux avertissements toutefois. Dû au durcissement de mon SE GNU/LINUX. Toutefois rien de bien méchant car on regarde l’avertissement lié au service de déploiement.

8 – Petit Résumé

Encore une fois, le petit récapitulatif nous informant que le repo a bien été créé.

Backup Job & Tests

Pour ce point, je ne vois pas de grand intérêt à décrire comme créer un jobs de backup. C’est pourquoi j’irai à l’essentiel, un en mot un seul, pour être succinct, sans détour et fioriture, bref j’irai droit au but…

Pourquoi cette entrée en matière dans cette partie ? Simplement car cela dépend de la source sur laquelle le serveur de sauvegarde se base.

• VMWare VCenter
• VMWare ESXi
• NUTANIX Prism Element
• NUTANIX Prism Central
• MICROSOFT HyperV
• VEEAM Backup Agent
• etc

La liste pourrait s’allonger comme un jour sans pain au vu du nombre de point d’entrée OnPremise et Cloud.

Dans mon cas et sur mon petit environnement de lab, ça sera sur un job de sauvegarde pour du VEEAM Backup Agent pour Windows (en Guest Processing) d’un serveur local.

Backup

Nous considérons qu’un compte d’administration est déjà présent pour la sauvegarde est durci dans les règles de l’art et que le serveur source se trouve dans la bonne configuration pour être sauvegardé.

1 – Storage

Dans la partie Storage de notre job (peut importe le type), il nous suffit de sélectionner notre repository hardened.

Le nombre de point de rétention doit être en adéquation avec la politique d’immuabilité en place comme décris dans la partie théorique. Dans mon cas 14 jours.

2 – Storage GFS

La sauvegarde hardened se base sur le principe GFS⁷. Effectivement et comme une nouvelle fois expliqué précédemment, il n’est pas possible et cela n’a pas de sens de faire de la RI⁸ mais bien FI⁹.

Je défini donc de réaliser une full backup synthétique de manière hebdomadaire, le 7 jour de la semaine, 7 jour où le Seigneur exténué (comme moi d’ailleurs) d’avoir travaillé si dure les 6 jours précédents de prendre un jour de repo. Et comme la sauvegarde est là pour nous prémunir de tout aléas

Les premiers seront les derniers, et les derniers seront les premiers

Marc 10:31

Nous pouvons faire confiance à Saint Marc. Amen.

Laissons notre job tourner et admirer les performances et actions en cours.

Tests

Une fois le job terminé avec succès. L’une de nos grandes questions que nous devons nous poser en tant que SysAdmin (et que n’importe quel client, chef d’entreprise doit se poser) est « Comment s’assurer que la chaine de sauvegarde est bien inaltérable, immuable ? »

Le plus simple, c’est de supprimer la chaine de sauvegarde ou l’une des ressources protégées. Normalement, dans la boite de dialogue se préparant à l’exécution de la suppression, vous devriez avoir un violent message d’avertissement vous informant que NON, VEEAM ne veut pas. Mais comme VEEAM n’est pas si en désaccord avec votre volonté de supprimer le backup, il vous donne toutefois la date d’échéance où il sera possible de supprimer la chaine si et seulement si le job est désactivé naturellement.

Si nous voulons allés plus loin, c’est du côté repo qu’il faudra contrôler que l’attribut d’immutabilité est bien positionné sur nos fichiers. Un petit coup de lsattr et le tour est joué.

Altérer l’inaltérable ?

Super cette sauvegarde immuable ! Avec ça, nous sommes paré à toutes éventualités contre la suppression et altération de nos chaines de sauvegarde.

Sauf que ce n’est pas tout à fait vrai. Désolé de vous mettre un stop. En haut de ce billet, j’ai insisté sur la topologie et l’architecture. Tout va reposer sur cette dernière pour ne pas altérer le contenu de votre repository hardened.

Avant de rentrer plus dans les explications, je rappel dans le contexte que le système GNU est durci. Le compte utilisateur dédié à la sauvegarde n’a pas de droit d’élévation, le daemon ssh est désactivé.

Allez, faut y aller, oui mais où ? Maintenant rentrons dans le vif du sujet.

En me connectant directement à mon repo en console ou en direct. Regardons nos différents maillons de chaines pour notre job. J’ai deux full. Pourquoi ? Parce que je suis un abruti qui lors du la configuration de mon job, j’ai oublié de chiffrer ma chaine. M’en rendant compte après coup, j’ai donc corrigé ce petit détail. Sauf que activer le chiffrement d’un job implique forcément de repartir sur un full. Merdouille non ?

Alors comment faire pour supprimer le premier maillon .vbk qui est indépendant de mon second .vbk ?

• Je suis patient et j’attends 28 jours
• Je supprime le point au niveau système et je clean ma configuration

Pour le coup je ne serai pas patient et je vais donc contourner l’immuabilité.

1. Je liste uniquement les maillons de la chaine qui sont des fulls (.vbk) afin d’identifier le point que je souhaite faire disparaitre
2. Etant en root, je retire l’attribut d’immuabilité sur le fichier
3. Je liste de nouveau les attributs des maillons de la chaine qui sont des fulls (.vbk) pour vérifier que c’est bon
4. Je supprime le fichier
5. Je liste de nouveau les attributs des maillons de la chaine qui sont des fulls (.vbk) pour vérifier que je n’ai plus qu’un fichier vbk

Nous nous déconnectons de notre console. Et regardons notre chaine côté VEEAM Ordo.

Là j’ai été un vite en besogne car j’ai déjà nettoyer la configuration. Mais notre point remontait comme inaccessible car nous l’avons supprimé (petite icone rouge et police en italique). Mais une fois nettoyé, nous avons 4 points en lieu et place de 5.

Donc il est possible d’altérer l’inaltérable sous certaines conditions.

Conclusion

La sauvegarde immuable ou hardened est vraiment une solution indispensable des organisations. Cette dernière ne doit pas être négligé. Malheureusement et c’est là un triste constat les organisations et entreprises pour des raisons de coût néglige cette protection supplémentaire.

« J’ai déjà une sauvegarde et une externalisation, je ne risque rien. Mon Service interne est parano ou Mon prestataire informatique me prend pour une vache à lait »

Ce sentiment de puissance, de confiance et d’invincibilité pourtant ne tiens qu’à un fil et c’est lorsque ça tourne mal qu’il nous reste plus qu’à pleurer en regardant comme Loth, sa femme pétrifié de sel (Genése 19:26). Attention, la facture est salée.

Toutefois, l’implémentation d’un tel système nécessite des aptitudes avancées pour les systèmes LINUX/GNU ce qui peut représenter un frein à la mise en place de ce dernier. Notamment sur la partie durcissement. A cela peut s’ajouter des budgets ainsi que des ressources limitées sur l’infrastructures ne permettant pas d’assurer cette fonctionnalité.

Il reste à moindre cout l’usage et l’implémentation d’une sauvegarde sur disque externe. Cependant je pense que cette solution est moins performante, plus espacée dans le temps, moins adapté à l’évolution du SI et soumis au risque humain (oublie, corruption, etc). Mais cela reste une solution.

Encore une fois la question de curseur se pose sur le rapport bénéfices risques. Qu’est ce que je suis prêt à accepter pour mon organisation ? Il suffit d’avoir frôlé la banque route ou d’avoir dans ces connaissances un patron qui a perdu son entreprise ou sauver de peu son business pour se sentir concerné.

Ouai mais tu nous as démontré que ce n’était pas inaltérable à 100%. Tu ne serais pas en train de nous refourguer une solution pour éviter le bug de l’an 2000 ?

Oui je conçois et l’ai démontré. Nulle solution n’est parfaite est sécurisé à 100%. Toutefois les opérations pour retirer l’immuabilité nécessite de passer plusieurs mécanismes de sécurités et le risque bien de présent est minime voir nul. Disons que si un individu malveillant s’attaque à la sauvegarde immuable, normalement l’équipe interne ou le service IT seront informés car c’est le point d’entrée le plus complexe à infiltrer. Et donc, cet individu aura pris le temps de mettre un joyeux bor**l sur l’ensemble de notre infra au préalable.

Nous pourrions également dire que 7 jours ou 14 jours d’immuabilité c’est peu. Et pourtant il faut voir cette sauvegarde comme l’as dans la manche qui nous sortira de l’échec et compromission de notre sauvegarde et externalisation. C’est une sauvegarde certes, mais la dernière carte à jouer. Sincèrement, vous SysAdmin/DSI persuadez votre DG, DAF ou PDG d’implémenter cette fonctionnalité.

Rare image d’échange entre un DAF avec un DSI/SysAdmin concernant le budget informatique

Vous DG, DAF ou PDG, écoutez votre SysAdmin/DSI et permettez lui de passer des nuits tranquilles loin des valium, tranxène, nembutal (ouai je sais ça faut beaucoup de référence à HFT, mais je suis dans ma période de vilain garnement 🙂 ).

Le mot de la fin

Consonnes, Voyelles. Je demande un 50/50 sur une garde sans. Risquez comme opération, mais ça passe et vous partez avec Maïté car votre préféré c’est le rondelé.

Erwan GUILLEMARD

Sources

• Définition Immuable
• VEEAM B&R 12.1 – Hardened Guide
• Linux – chattr
• E2fsprogs

Je remercie LLU, d’avoir su me mettre sur la voie et d’avancer sur ce sentier.

1. SE : Système d’Exploitation ↩︎
2. LTS : Long Time Support ↩︎
3. ANSSI : Agence National de Sécurité des Systèmes d’Informations ↩︎
4. XFS : X File System ↩︎
5. SFP+ : Small Form-Factor Pluggable+ (10 Gb/s) ↩︎
6. FC : Fiber Channnel ↩︎
7. GFS : Grand Father, Father, Son ↩︎
8. RI : Reverse Incremental ↩︎
9. FI : Forward Incremental ↩︎