C’est ainsi qu’un certain nombres d’équipes informatiques utilisent :

• VPN SSL²
• RDS³ via TSGW⁴
• Solution de prise en main à distance (TeamViewer, LogMeIn, NinjaRMM et j’en passe)

Je vois cela d’un autre regard et sous un autre angle. Je veux parler du regard du contrôle, de l’audit et de la non-répudiation ! Du respect du RGPD⁵ et des données stockées. Oui, je fais partie de ces SysAdmins là, ceux qui croient en l’ISO27001 et HDS⁶, ceux qui croient au BASTION <3

Je ne vais pas cracher sur TeamViewer car je l’ai longtemps utilisé à des fins personnelles pour me connecter à mon lab, mais bon niveau sécurité c’est loin d’être fou et encore une fois, où sont mes données ? Et il est toujours borderline dans son utilisation commerciale ou non…

Dans le monde professionnel, j’ai eu le loisir d’utiliser et d’implémenter une solution française de BASTION. Cette solution est super (je n’ai pas d’action chez eux mais c’est avec grand plaisir que je réaliserais de nouveau l’implémentation de cette solution) et les équipes support et commercial sont très compétentes.

Quoi ? Le nom de la solution ? Cleanroom/Cyberelement par SYSTANCIA

Mais voilà. Bien qu’une super solution, moi pauvre petit AdminSys je ne peux pas me payer la solution voyez vous et bonjour l’usage pour du lab. C’est alors que j’ai dû me tourner vers le monde de l’open source…

J’ai fait fumer mes méninges et avec la grosse Adrienne de mon talant (où Montalant ? 🙂 ) je me suis lancé dans l’implémentation d’un bastion GUACAMOLE ! OLE !

En réalité, ce n’est pas ma première tentative d’implémentation du bastion Guacamole, mais je n’ai jamais aimé l’approche Docker et je n’ai jamais eu le temps de vraiment étudier la solution. Pis là bah, je me suis dit c’est le moment de réaliser ce que je n’ai jamais réussi à concrétiser 🙂

Avant-Propos

Cet article va être plutôt conséquent. Donc il est préférable de se prendre un petit pack de cerveza (pourquoi petit ?) pour ne pas se déshydrater pendant ce billet.

Pour rendre ce dernier plus digeste, j’ai pris le parti de scinder quelques fonctionnalités dans des billets dédiés et de couper l’article en plusieurs sous-articles. L’implémentation d’un bastion nécessite un certain nombre de composants tiers et surtout une grande réflexion quant à l’architecture et aux fonctionnalités.

Bref, j’ai fait le choix encore une fois de partir sur un environnement LINUX, RHEL⁷ comme OS⁸ et d’appliquer comme d’accoutumée le durcissement de l’ANSSI⁹ pour les systèmes GNU/LINUX. Le bastion doit être le seul point d’entrée de notre SI pour accéder à nos ressources. C’est pourquoi je veux qu’il soit le plus sécurisé possible. Je vais donc aller relativement loin dans la sécurisation et il n’est donc pas impossible de se perdre en route. C’est toutefois comme ça qu’on apprend ! Il faut pour se trouver savoir se perdre sur des chemins de traverse 🙂

J’ai beaucoup appris et ainsi, je souhaite vous partager mon expérience.

Señor, Señora, Ándale Ándale Arriba !

Prérequis

• SE :
  • GNU/Linux RHEL
• Apps :
  • Guacamole 1.6
  • Tomcat 9.X
  • MariaDB 15.X
  • Nginx
• Autres :
  • Certificats

Guide

• Partie 1 : Théorie
  • Définir ce qu’est un bastion
  • Réflexion sur l’architecture
• Partie 2 : Installation
  • Guide de déploiement
• Partie 3: Sécurisation
  • Réseau
  • Système
  • Application
• Partie 4 : Configuration
  • Paramètres
  • Utilisateurs
  • Groupes
  • Ressources
• Partie 5 : Démonstration
  • Présentation de la solution

Conclusion

Il n’est pas évident aujourd’hui de garder la main sur nos environnements de manière sécurisée, comme il n’est pas aisé de contrôler l’ensemble des activités d’un fournisseur ou prestataire sur notre SI. Même si la connexion est éphémère, nous nous devons de contrôler cette dernière. J’ai repris la lecture des poèmes d’Omar KHAYYÂM, et je suis tombé sur celui-ci que je trouve à la fois beau et adapté à la thématique de mon billet. (Je ne parle pas de politique et je lis depuis très longtemps cet ouvrage).

Considère ce vieux caravansérail qu’on nomme le monde,
dont les portes sont le Jour et la Nuit ;
des souverains y passent avec leur faste,
y demeurent une heure ou deux… puis s’en vont

Omar KHAYYÂM – Robâiyât

Nous pouvons alors facilement considérer que le caravansérail est notre bastion, les voyageurs nos sessions, les gardiens de la porte les administrateurs systèmes et réseaux…

Les solutions de BASTION bien qu’onéreuses viennent pallier à tous cela. Toutefois et c’est souvent l’argument le coût de la solution est difficilement supportable ce qui justifie l’usage à tort et pour tout des VPN SSL, TS GW ou des outils de prise en main à distance. A l’inverse GUACAMOLE répond à l’ensemble des problématiques financières et technologiques. J’ai un bastion gratuit et souverain sur mon SI que demander de mieux ? Ce n’est malheureusement pas gratuit. Regardons de plus près le coût ETP¹⁰ lié à la solution. Il faut installer, maintenir la solution au-delà de son contexte infrastructure mais également applicative. Et comme vous pouvez le constater, c’est loin d’une mince affaire pour qui souhaite bien faire les choses.

Le choix de ne pas passer par la technologie docker m’est propre. Je ne vois pas l’utilité d’une telle solution pour un projet de ce type. Docker reste pour moi un usage de développement et non de production. Je ne dis pas que c’est mauvais, je dis que cela ne m’est pas adapté. Un jour peut-être je changerai d’avis, pour l’instant la tête de cochon que je suis continuera de réaliser ces infrastructures en environnement non containerisé ! (GUILLEMARD ça rime avec tête de lard pour ne pas dire co**ard 🙂 )

Je suis content d’arriver au bout de cet article et de cet outil magnifique qu’est GUACAMOLE. J’aurai appris énormément de choses encore et cela faisait longtemps que je n’avais pas passé des nuits blanches à cogiter sur des débugs et analyses. Je pense toutefois que la solution doit être sauvegardé au cas où et ce peu importe la solution utilisée. Si le bastion reste indisponible pour de bonnes et mauvaise raisons, il nous faut alors passer par la poterne de notre SI pour voir ce qu’il se passe. Son usage doit être restreint au maximum et doit se faire qu’en cas d’extrême nécessité.

La morale de ce billet se résumera à si j’avais un budget je passerai sans hésiter par SYSTANCIA (non je n’ai pas d’action), solution française, support humain et sympathique et une analyse forte en cas d’incident et de correctif applicatif de l’ensemble de leurs solutions (Cleanroom devenu CyberElements). Malheureusement, je n’ai pas le sou et donc je me rabat sur Apache GUACAMOLE et cela n’est pas sans regrets 🙂

Le mot de la fin :

J’initie une connexion guacamole sur fond de paddle. Votre avocat fait appel et vous informe que la balle est au centre. UN-DEUX-TROIS, on ne se bat pas ici ! Superbe relance de l’ami Kaouette, une teq paf pour la 12.

Erwan GUILLEMARD

Sources

• GUACAMOLE : Download page
• GUACAMOLE : Native Installation Guide
• SYSTANCIA

1. SI : Système d’Information ↩︎
2. VPN SSL : Virtual Private Network Secure Socket Layer ↩︎
3. RDS : Remote Desktop Server ↩︎
4. TSGW : Terminal Server GateWay ↩︎
5. RGPD : Règlement Général de Protection des Données ↩︎
6. HDS : Hébergement de Données de Santé ↩︎
7. RHEL : RedHat Entreprise Linux ↩︎
8. OS : Operating System ↩︎
9. ANSSI : Agence National de Sécurité des Systèmes d’Information ↩︎
10. ETP : Employé(e) Temps Plein ↩︎

Mais alors pourquoi faire un article sur Tomcat ?

Parce que premièrement cela aurait rendu l’article indigeste déjà qu’en temps normal ce n’est pas ouf et que deuxièmement en creusant un peu le sujet cela ne se résume pas à juste un dnf install tomcat…

Bref, ce billet sera technique car j’ai hâte de revenir à mon article initial. Mais cela vaut le coup car j’ai appris encore énormément de chose 🙂

Tommy the Cat is my name and I say unto thee

Avant-Propos

L’étude de Tomcat vient simplement de l’implémentation d’un billet qui sera publié prochainement qui nécessite la présence d’un serveur d’applet Java. Je garde volontairement une part de mystère, sinon ce n’est pas marrant non ? 🙂

De mon passé, d’étudiant, j’ai appris la POO¹ lors de mes études en BTS² d’info industrielle sur C++. J’avoue que je n’ai pas bien saisie la pratique… C’est lors de ma licence en sécu logicielle que j’ai unlock et appliqué tous les pratiques de la POO sur le langage JAVA.

Cool ta life mon gars, ça aurait mérité un post Facebook en 2012 avec en premier commentaire « Ba moi hier j’ai mangé une pomme »

Ouai peut-être mais cela a été pour moi une révélation. J’ai trouvé ce langage magnifique et je pensais avoir trouvé ma voie. Et pourtant JAVA est loin d’être un langage des plus fiable et ergonomique. Des IDEs³ NetBeans, Eclipse, Android Studio sans oublier le serveur d’applet web GlassFish je trouvais ça top. Et puis je me suis rendu compte que les applets c’étaient lourds, les applications Java difficilement ergonomique, des failles de sécurités qui doivent être patché avec des updates de la JDK⁴ côté développeur de la JVM⁵, JRE⁶ côté client, le code qui ne devient plus compatible…

Voilà, les raisons de pourquoi j’ai délaissé mon amour de JAVA par dépit à la suite de ces frustrations. L’une des autres raisons et la difficulté de jongler entre la sécurité des versions clients et les progicielles. Accepter de mettre à jour et ne plus travailler car au lancement de l’application ou de fonctionnalité ça crash ou retourne des erreurs de stack traces dans tous les sens ou accepter d’avoir des failles de sécurité partout et pouvoir travailler ?

Bref, encore une fois, un article pour installer un service au premier abord simple mais qui nécessite d’être bien sécurisé.

Prérequis

• SE :
  • Rocky Linux 9.4 et versions ultérieures
• Apps : 
  • Tomcat 10.1.54
• Autres :
  • Hardenned Linux

Théorie

Un peu d’histoire

Il était une fois, un meunier ne laissa pour tous biens, à trois enfants qu’il avait, que son moulin, son âne et son chat...

Bien joué Charles 😉 Je ne vais pas vous compter le conte du Chat Botté de Perrault mais bien celle de Tomcat, je vous rassure, mais la tentation était trop grande <3

L’objectif principal était de fournir une implémentation de référence pour JAVA Web (servlets et JSP7). C’est ainsi que James Duncan DAVIDSON créa Tomcat en 1998 sans lui donner encore de nom. Le projet sera donné à la fondation Apache en 1999 qui le baptisera Tomcat et passera ce dernier sous licence OpenSource Apache. Au cours des années 1999 à 2001, la première version stable de Tomcat est disponible pour principalement être utilisé comme moteur de servlet et est fortement lié au server web Apache. Au fil des années, le projet Tomcat continuera d’évoluer avec l’âge d’or d’internet. A ce jour, la version la plus récente est la version 11 qui comme nous pouvons en douter à une optimisation pour le cloud et les micro services. (Il faut bien vivre avec son temps 🙂 ).

Ce qu’il est important de retenir, c’est que ce dernier reste un projet OpenSource maintenu par une communauté très active. Tomcat reste également un serveur d’application léger très populaire et de base (et c’est pourquoi il est fortement lié à JAVA) la référence de l’implémentation JAVA.

Structure

Il est important comme pour toutes applications de savoir comment cette dernière est structurée et comment elle fonctionne.

Ainsi, nous pouvons différencier 9 répertoires distincts au sein du daemon Tomcat :

• bin : L’ensemble des scripts et exécutables propre au daemon pour démarrer ou arrêter le serveur.
• common : Nous pourrions dire que ce répertoire contient le code (classes et méthodes) commun utilisé par le service Catalina et certaines applications web.
• conf : Le répertoire qui stocke les fichiers de configuration du server.
• lib : Répertoire qui stocke l’ensembles des bibliothèques (les .jar)
• logs : Dossier qui va stocker l’ensemble des journaux d’événement. Attention à ce que ce dernier ne prenne pas trop de place sinon BOUM plus de service. Le mieux serait de le déplacer sur un disque dédié.
• server : Code contenant les méthodes et classes systèmes utilisés uniquement de Catalina.
• shared : Les classes partagées utilisées par toutes les applications
• webapps : Répertoire qui va contenir les applications web (le fichier .war)
• work : Répertoire qui va contenir les répertoires et fichiers temporaires (le cache)

Chacun des répertoires joue un rôle clé et donc selon le contexte doit être sécurisé.

Fonctionnement

Le fonctionnement de Tomcat peut paraitre complexe au premier abord. Toutefois avec un bon schéma, cela devient aussi divin que les croquettes Ultima Saumon pour chat stérilisé (« Sale Histoire » que mon avocat garde sous silence en reprenant la citation d’un membre de la famille).

/!\ Attention : Cette architecture reste valable, mais Tomcat 10 a migré vers Jakarta EE en rendant incompatible les applications basées sur javax.servlet. Donc si usage des Servlets c’est Tomcat 9…

Pour faire simple, si lors du lancement de votre application ne se lance pas et que dans les logs localhost ou catalina vient fleurir l’erreur ClassNotFoundException: javax.servlet, et bien c’est que vous l’avez dans l’OS bien profond et que vous êtes marron… Votre application n’est pas compatible Tomcat 10. Vous êtes bon pour un downgrade <3 Ca fait du bien de temps en temps de se prendre un bon coup de nerf de bœuf sur l’arrière train, ça fait circuler le sang !

Cette structure modulaire d’encapsulation, permet de garantir une certaine souplesse sans avoir à changer la logique des applications.

Je pense qu’il n’y a pas besoin d’en savoir plus pour installer le service sur notre serveur. Passe à la pratique.

Pratique

J’ai pris le parti de sortir pour une nouvelle fois des sentiers battu et de ne pas me limiter à l’installation de Tomcat depuis le repo source. J’ai choisi de déployer ce dernier depuis le site officiel.

Ce choix est motivé par les versions spécifiques nécessaire à certaines applications. De ce fait, l’installation depuis le repo n’est pas d’une grande utilité. Et une nouvelle fois de par mon expérience, il est plus probable de passer par le site officiel.

Dépendances

En termes de dépendance, ce n’est pas bien compliqué, il nous faut la JDK pour faire tourner notre serveur Tomcat. Donc ?

On installe la JDK 🙂

#Install Java
$ sudo dnf install java-21-openjdk-headless

Je passe encore et toujours mon tour sur cette étape qui devient un incontournable des billets que je rédige sous GNU/Linux.

Installation

Bien. Maintenant que notre dépendance est installée, commençons par le début.

Créons notre groupe tomcat et notre utilisateur de service tomcat. Pour répondre au bonne pratique, un service = un compte applicatif. Cela permet de faciliter le debug et surtout en termes de sécurité c’est bien mieux que de tout faire tourner avec le compte root.

$ sudo groupadd tomcat
$ sudo useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat

Naturellement, l’utilisateur tomcat est membre du groupe tomcat…

L’installation se fait de deux manières. Soit par la commande curl qui est nativement présente sur notre SE⁹. Soit par wget qui devra être installé. Il conviendra d’adapter l’URL¹⁰ selon la version recherchée. J’ai décidé de télécharger le .tar.gz directement dans le répertoire /tmp.

Créons-le répertoire /opt/tomcat puis décompressons notre archive stocké sous /tmp dans le répertoire fraichement créé.

$ curl -L --output-dir /tmp -O  https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.54/bin/apache-tomcat-10.1.54.tar.gz
$ mkdir /opt/tomcat
$ tar -xf /tmp/apache-tomcat-10.1.54.tar.gz -C /opt/tomcat --strip-components=1

Bon, si on regarde du côté de l’ANSSI¹¹, ces derniers nous recommandent que notre compte de service tomcat ne doit pas propriétaire des binaires (exécutables). Pourquoi ? Admettons qu’il y est compromission, le compte ne sera pas en possibilité de s’altérer lui-même. Ainsi, nous pouvons voir une sorte de silotage.

$ sudo chgrp -R tomcat /opt/tomcat
$ sudo chmod -R g+r /opt/tomcat/conf
$ sudo chmod g+x /opt/tomcat/conf
$ sudo chown -R tomcat /opt/tomcat/{webapps,work,temp,logs}

Le groupe utilisateur tomcat a donc les droits de lecture et d’exécution sur l’ensemble des sous éléments du répertoire /opt/tomcat. L’utilisateur tomcat sera propriétaire uniquement des sous répertoires et leurs contenus :

• webapps : Répertoire qui va contenir les applications web (le fichier .war)
• work : Répertoire qui va contenir les répertoires et fichiers temporaires (le cache) persistant. C’est à dire utiliser par les servlets.
• temp : Le répertoire va stocker les fichiers à déplacer. Il joue le rôle de passe plat. Les fichiers qui viendraient à persister sont automatiquement supprimés à chaque redémarrage du service.
• logs : Les journaux d’événements, il faut bien que le service puisse écrire ce qui se passe non ?

Sécurité

Niveau sécurité, les actions vont se concentrer et se définir dans le fichier server.xml ainsi que dans le fichier web.xml.

L’objectif sera de se prémunir des attaques classiques MIM¹², Clickjacking, XSS¹³ et de masquer l’identité de notre serveur le plus possible. Parce qu’on ne dévoile pas tout le premier soir 😉

Audit et divulgation d’identité

Commençons par éditer le fichier server.xml.

$ sudo vim /opt/tomcat/conf/server.xml

Un truc qui pourrait être tout bête, appliquons le principe :

Vivons heureux, Vivons cachés !

C’est à dire outre mon langage (car peu parle le Erwan première langue), masquons la version de notre serveur tomcat dans les trames d’entêtes (le header…) HTTP. Ainsi il est possible de savoir que je suis un serveur tomcat, mais de connaitre ma version. 🙂

Malinx le Lynx. D’un autre côté c’est Tomcat… Voilà voilà, il est content de sa vanne…

Dans le connecteur HTTP, ajouter server= » « 

Avant	Après

Tiens, tu ajoutes un secure= »true ». C’est cool, du coup tu forces les connexions chiffrées ? 🙂 Et bien pas du tout ! Je me suis fait k*n aussi. Je suis allé regarder la documentation pour mieux comprendre. Par défaut, secure est à false. Nos applications par le biais de notre server peuvent refuser de délivrer les cookies sensibles ou vouloir rediriger les utilisateurs vers le protocole HTTPS¹⁴. Dans le meilleur des cas ça créé des lenteurs au pire c’est l’infinity loop… Alors que si nous le forçons à true, Tomcat va confirmer auprès de l’application que la requête vient d’un canal sécurisé (ce qui n’est pas le cas. Où le vilain menteur !) même s’il vient d’un canal non sécurisé.

De toute façon, nous allons passer par un reverse proxy nginx et en frontal nous aurons une publication avec une règle de proxy.

Toutefois cela ne suffit pas. Quand est-il des pages d’erreurs ? En creusant un peu il va falloir fermer les valves… 🙂

L’objectif est de supprimer la mention « Apache Tomcat/<version> » dans les pages d’erreurs ainsi que la description des erreurs (la stacktrace. Que de nostalgie…). L’objectif est de donner le moins d’information possible à un potentiel attaquant qui souhaiterai exploiter une CVE¹⁵ en relation avec la version de notre produit. L’objectif est de rendre aveugle l’attaquant le temps que les mécanismes en place ce déclenche ou nous alertes.

Niveau Audit, nous pouvons également renforcer la verbosité si nous suivons les recommandations de l’ANSSI.

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b %D &quot;%{User-Agent}i&quot;" />

• %h : l’adresse IP distante
• %l : Identifiant logique
• %u : Utilisateur authentifié
• %t : horodatage
• %r : Ligne de requête (la méthode et l’URL appelé)
• %s : Code de retour du protocole HTTP
• %b : Taille de la réponse en octet
• %D : Le temps de traitement en ms
• %i : Le User-Agent pour repérer les outils automatisés (nmap et autres) et surtout les navigateurs « chelou » comme diraient mes enfants…

Par exemple :

/!\ Attention : L’activation de l’audit n’est pas anodine en termes d’espace. Il faut penser à mettre en place une rotation des logs. Sinon… BOUM !!!

Toutes les applications par défaut, ça dégage ! Pourquoi garder les éléments de bases qui sont d’autant plus des vecteurs d’attaque et des points de vulnérabilité ?

$ sudo rm -Rf /opt/tomcat/webapps/*

Un truc que je ne connaissais pas et que j’ai trouvé en étudiant Tomcat, c’est le cas de « Protection du Shutdown ». Au premier abord, je me suis demandé qu’est-ce que c’est que ce truc. Le paramètre shutdown est explicite. Et bien voyez-vous c’est marrant, c’est une commande qui permet d’éteindre le daemon. Alors certes, par défaut il est sur le port 8005/tcp et normalement accessible qu’en local. Mais tapons shutdown et pouf ! Notre daemon il va à la niche.

Donc, on change le port et pour le mot de passe on utilise le bon vieux Soleil123! . Vous m’avez compris non ? 🙂

<Server port="-1" shutdown="y2Fxg@kLx4:If2L0_MD1Ccz">

Prévention des attaques

Ouvrons le fichier web.xml.

$ sudo vim /opt/tomcat/conf/web.xml

A la fin de la section <filter>, ajoutons les lignes suivantes :

<!-- Begin R-ONE Modification -->
        <filter>
                <filter-name>httpHeaderSecurity</filter-name>
                <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
                <async-supported>true</async-supported>

                <init-param>
                        <param-name>hstsMaxAgeSeconds</param-name>
                        <param-value>31536000</param-value>
                </init-param>

                <init-param>
                        <param-name>antiClickJackingOption</param-name>
                        <param-value>DENY</param-value>
                </init-param>

                <init-param>
                        <param-name>blockContentTypeSniffingEnabled</param-name>
                        <param-value>true</param-value>
                </init-param>
        </filter>
<!-- End Modification -->

Parcourons en détails chaque ligne pour comprendre ce que nous sécurisons avec les filtres. (Normal c’est du café de Java… Franchement, il ne mérite pas d’aller jouer sur l’autoroute à contre sens pour bien voir le danger ? L’auteur de ce billet est bof, il fait triste à voir.)

L’usage du filtre de sécurité « HttpHeaderSecurityFilter » permet d’ajouter des réponses dans le header des requetes HTTP pour protéger les utilisateurs et les applications des attaques mentionnées ci haut. Ainsi pour une défense en profondeur l’activation de ces options sont primordiales. hstsMaxAgeSeconds indique que le site ne peut être consulté uniquement via le protocole HTTPS et force ainsi le navigateur à chiffrer les requêtes. Cela permet donc de prévenir des attaques d’interception SSL (SSL stripping). antiClickJackingOption aussi connu sous le nom de X-Frame-Options. Cela permet au site de ne pas intégrer l’application dans une balise html iframe et donc de faire une superposition d’interface invisible et valider une action non voulue. blockContentTypeSniffingEnabled ou X-Content-Type-Options: nosniff permet de blague censurée de forcer le navigateur à respecter le type MIME envoyé par le serveur. L’objectif et de se prémunir des attaques XSS.

Il nous reste un dernier point, les cookies. Afin que ces derniers ne soient pas volés par Cookie Monster par exemple, il est primordial d’interdire l’accès au cookie via JavaScript (d’où la présence du http-only à true. Nous bloquons ainsi le vol de session via XSS. L’usage de secure va faire en sorte que le cookie n’est envoyé si et seulement si la connexion est sécurisée.

<!-- Modification R-ONE -->
        <filter-mapping>
                <filter-name>httpHeaderSecurity</filter-name>
                <url-pattern>/*</url-pattern>
        </filter-mapping>
<!-- End Modification -->

Un truc c*n qui m’a fait perdre une nuit de sommeil. J’avais cette put**n d’erreur… A devenir fou !

Après pas mal de recherche, c’est un truc simple. Franchement je suis vraiment un c*n… Mon nouveau fichier de conf, avait pour owner root:root et non tomcat:tomcat. La haine, vraiment. Pensez donc à bien set de nouveau les bons droits…

$ sudo chown tomcat:tomcat -R /opt/tomcat/conf/

Un petit test avant, après ?

Avant	Après

Daemon Firewall

Côté firewall il faut publier le port 8080/tcp

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

Toutefois ça ne fonctionnera pas NANANANERE ! Et pourquoi ? Hein, pourquoi ? A cause du SELinux ventrebleu !

Par défaut le port 8080 n’est pas autorisé dans le SELinux pour la communication HTTP. Il est donc nécessaire de lui dire qu’il en fait partie.

$ sudo semanage port -a -t http_port_t -p tcp 8080

Configuration

Logrotate

Créons et éditons le fichier de rotation propre à tomcat sous /etc/logrotate.d.

$ sudo vim /etc/logrotate.d/tomcat

Nous allons spécifier dans notre fichier que nous souhaitons effectuer la rotation du fichier catalina.out, les fichiers localhost_access_log*.txt ainsi que l’ensemble des fichiers d’extensions .log.

C’est dernier afin de ne pas impacter la production seront vidé à chaud (copytruncate) de manière journalière en gardant 30 jours de rétention (histoire de faciliter les investigations en cas de suspicion). Nous compresserons les points de rétentions si pas de fichier nous ne faisons rien ni si les fichiers sont vides. Nous recréerons les fichiers avec les droits 0640 avec en groupe et propriétaire le compte de service tomcat.

/opt/tomcat/logs/catalina.out
/opt/tomcat/logs/localhost_access_log*.txt
/opt/tomcat/logs/*.log {
    copytruncate
    daily
    rotate 30
    compress
    missingok
    notifempty
    create 0640 tomcat tomcat
}

Une commande que je ne connaissais pas. C’est en me replongeant dans la documentation de logrotate que j’ai découvert qu’il existait un mode debug qui vient simuler notre fichier de rotation. C’est vraiment cool.

$ sudo logrotate -d /etc/logrotate.d/tomcat

Bon ba fonctionne pas. Que pasa ? Ca ne serait pas encore un coup du SELinux ? Mais si, Mais si j’ai cru voir un SELinux !

$ ls -Zd /opt/tomcat/logs
$ sudo semanage fcontext -a -t var_log_t "/opt/tomcat/logs(/.*)?"
$ sudo restorecon -Rv /opt/tomcat/logs

Après vérification du contexte de sécurité, il s’avère que logrotate est bloqué par le SELinux lorsqu’il essai d’écrire dans le répertoire /opt/tomcat/logs. Il convient donc alors d’ajouter le contexte et de restaurer le contexte de sécurité sur le répertoire /opt/tomcat/logs. 🙂

Tu vois Monsieur CHAPPINION, je ne laisse pas la sécurité au hasard et des backdoors partout comme tu aimes le crier haut et fort en te pavanant. Continu de cracher ton VENIN avec ta clic… #bisous #gratuit #faitdubien 🙂

Services

Comme j’ai choisi l’installation depuis le package et non depuis le repo, il faut se farcir à la main le fichier de service. Cela dit, c’est plutôt intéressant de se pencher sur le cas. Encore une fois et c’est mon point de vue, c’est agréable de savoir cuisiner que d’acheter des produits transformés tous les jours.

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

[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking

User=tomcat
Group=tomcat

Environment="JAVA_HOME=/usr/lib/jvm/jre"
Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid"
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/opt/tomcat"

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

# Sécurité Systemd (Sandboxing)
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Normalement maintenant c’est le moment de vérité… Démarrons notre service. Si tout va bien, pas d’erreur. Sinon c’est parti pour du début et avec Java ça peut vite devenir pénible et encore le paroxysme est loin. Mais je ne veux pas vous décourager…

$ sudo systemctl start tomcat
$ sudo systemctl status tomcat

Si c’est ok, le service peut être actif au démarrage du système. Ce dernier se lancera après le service réseau (cf la conf du service).

$ systemctl enable tomcat

Test

Pour vérifier que tout est fonctionnel, il est nécessaire comme nous avons supprimé l’intégralité du contenu de notre répertoire /webapps/ de générer un fichier de test :

$ sudo mkdir /opt/tomcat/webapps/ROOT
$ sudo echo "OK FINAL ROOT" > /opt/tomcat/webapps/ROOT/index.html
$ chown tomcat:tomcat -R /opt/tomcat/webapps/ROOT
$ sudo systemctl restart tomcat

Maintenant depuis un navigateur web, sous réserve d’avoir créé la règle sur votre UTM¹⁶ si vous n’êtes pas dans le même subnet rendez-vous sur l’URL http://<SERVER>:8080 ou depuis directement depuis votre server curl http://127.0.0.1:8080 vous devriez avoir en retour :

Remote	Local

Je pense que nous avons clôt ce billet. Nous voilà avec un server Tomcat sécurisé et fonctionnel… 🙂

Conclusion

Je me suis arraché les cheveux sur ce billet.

Ecoute ma bonne Catalina, tu un engine modèle, mais si tu n’as que des qualités et en termes de verbosité tu es resté comme je l’espérai, c’est le bonheur rangé dans une armoire. Tu vois si c’était à refaire, je t’installerai de nouveau mais tu m’emmerdes !

Erwan Guillemard, revisite d’Un singe en hiver d’Henri VERNEUIL

Mais alors pourquoi je tiens ces propos ? Je me suis une nouvelle fois aventuré dans la stacktrace et dans les logs à la suite d’un 404 Not Found. D’erreur dans le fichier de configuration car sensible à la case sur UN caractère. L’absence de log par moment… Tout ce que j’aime avec JAVA, ou du moins j’aimais… Imaginons maintenant une montée de version ? J’espère que votre formulaire de CAB¹⁷ est à jour et que vous avez un environnement de production iso à votre production.

JAVA et Tomcat c’est un peu comme regardez notre bonne vieille boite de Schrödinger. Le service est démarré, mais cela ne fonctionne. Le chat, c’est notre Tomcat numérique (C’est surtout la faute du mec entre le clavier et la chaise qui est dans un état quantique oui !).

Enfin passons, si j’ai fait un billet sur Tomcat, c’est que je vais surtout en avoir besoin dans l’article prochain et qu’il était vraiment important d’étudier en profondeur ce produit de la gamme Apache. Il faut reconnaitre tout de même qu’en terme de serveur web il y a bien pire 🙂

Rien que les notions de sécurité, nous revenons une nouvelle fois autour des mêmes notions conceptuelles, moindre privilège, réduction de la surface d’attaque, audit, chiffrement et isolation. Ces points sont primordiaux pour Tomcat.

Pourquoi me direz-vous ? Parce que nous publions un service Web qui exécute du code JAVA qui si mal isolé, croyez-moi peut faire énormément de dégât dans un système d’information. Il serait bien de porter si vous utiliser ce dernier renforcer la vigilance sur ce dernier avec votre SIEM¹⁸ (c’est marrant, je n’en ai pas 🙂 )…

Le mot de la fin :

Le chat botté chevauche Tomcat pendant que Charles Perrault configure du HSTS dans une cafetière. Arabica mon chers Watson, je danse la JAVA de Broadway. A non, il y a Catalina en travers sur une requête HTTP, le firewall vous fait chapeau bas !

Erwan GUILLEMARD

Sources

• ANSSI : Standards de sécurité côté navigateur
• Logrotate : Man
• Curl : Man
• Wikipédia : Apache Tomcat
• Tomcat : Documentation

1. POO : Programmation Orientée Objet ↩︎
2. BTS : Brevet de Technicien Supérieur ↩︎
3. IDE : Integrated Environment Development ↩︎
4. JDK : JAVA Development Tools ↩︎
5. JVM : JAVA Virtual Machine ↩︎
6. JRE : JAVA Runtime Environment ↩︎
7. JSP : JAVA Server Pages ↩︎
8. HTTP : HyperText Transfert Protocol ↩︎
9. SE : Système d’Exploitation ↩︎
10. URL : Uniform Resource Locator ↩︎
11. ANSSI : Agence National de Sécurité des Systèmes d’Information ↩︎
12. MIM : Man In the Middle ↩︎
13. XSS : Cross Site Scripting ↩︎
14. HTTPS : Secure HyperText Transfert Protocol  ↩︎
15. CVE : Common Vulnerabilities and Exposures ↩︎
16. UTM : Unified Threat Management ↩︎
17. CAB : Change Advisory Board ↩︎
18. SIEM : Security Information and Event Management ↩︎

Dans mon cas personnel je devrais plutôt dire, Ce matin un prompt Ollama a tué mon serveur…

Toujours dans la dynamique du sujet d’étude en cours « l’IA¹ » et l’étude de la solution Ollama, je suis victime du fait de sa causalité de l’ouverture d’un projet et donc de cet article.

Pour reprendre la conclusion de l’article traitant d’Ollama et de la solution OpenWebUI, j’avais émis l’hypothèse de créer mon propre client Ollama en me passant sur l’API² de ce dernier.

Du fait de la consommation de ressource importante nécessaire au bon fonctionnement d’OpenWebUI et d’Ollama, je voyais plutôt d’un bon œil de créer son propre client. Soit pour faire simple de se passer de la solution OpenWebUI. L’un des arguments complémentaires, l’interface CLI d’Ollama n’est pas hyper user-friendly pour celui qui n’a pas l’habitude des interfaces CLIs. Ce que je souhaite c’est un usage à moyen et grande échelle. Comprendre par là un environnement familial ou pourquoi pas dans une PME ?

Avec l’ensemble de ces réflexions, je me suis dit

« Ok je me lance et si ça les tests sont concluants je fais ma petite application… »

C’est là que ça dérape. Pris d’une creative fever (sans vouloir divulgâcher la suite du billet), le projet SS_045³ va basculer en GS_045⁴ sous son nom de code Zelen Zajac ou en français Lapin Vert. Cela viendra donc concrétiser la création d’un client multiplateforme CLI⁵ et GUI⁶ pour Windows.

Comme quoi, encore une fois d’une petite idée va naitre un projet sympathique. Surement inutile, mais sympathique 🙂 Et je suis certain que le fan club de Chantal Goya sera content #coeur.

Avant-Propos

Contrairement aux projets précédents Green Ray ou Dream Nebula je vais rentrer un peu plus en détail dans la technique et ce pour des raisons simples que j’ai appris et renforcé pas mal de compétence en termes de développement.

Cet article sera donc orienté plus développement qu’infrastructure.

Mon code sera disponible sur GitHub contrairement à d’autres projets.

Pourquoi ce choix et ce revirement de position ?

Parce que je pense que cela peut être profitable à d’autres utilisateurs de la solution Ollama qui veulent se passer d’OpenWebUI. 🙂 Et je pense que là c’est rester dans le monde de l’open-source.

Bref, si votre curiosité est toujours suscitée je pense que le reste de l’article devrait vous satisfaire. Dans le cas contraire, je vous laisse exécuter la combinaison Ctrl+F4 ou Ctrl+W pour fermer cet onglet.

Prérequis

• SE :
  • Windows (Server ou Workstation)
  • GNU/Linux (RHEL⁷ ou Debian)
• Apps :
  • Ollama
• Autres :
  • PowerShell version 5 et supérieur

Guide

• Partie 1 : Théorie
  • Définir l’expression du besoin
  • Aborder le cahier des charges
  • Défendre les solutions techniques retenus
• Partie 2 : Pratique
  • Guide de déploiement de la solution
  • Paramétrage de l’application
• Partie 3 : Démonstration
  • Présentation de la solution dans les différents modes qui ont été développés

Conclusion

Ce petit projet a été source de défis pour ne pas écrire challenges et de montée en compétence sur le code. Oui moi qui ne jure que sur le CLI, je me mets à faire du GUI.

La plus belle satisfaction reste d’avoir fait mon premier code cross-plateform .Net entre les SEs⁸ Windows et Linux. Le côté agnostique permet donc d’avoir une seule version du code ce qui facilite l’évolution et le maintien du code, mais surtout d’offrir les mêmes services peu importe la nature du système de l’utilisateur. Je me sens à ce moment comme un chevalier ayant réussi ça quête… Ou pas car le démoniaque lapin est toujours là est doit être rassasié (amélioré, je voulais dire <3 ) !

Si je me réfère à l’actualité au moment de la rédaction de ce billet, la volonté du gouvernement français de se libérer des technologies américaines sur les outils informatiques aux détriments de solutions françaises et open source viennent alimenter d’eau mon moulin.

Au-delà de ces derniers points, j’ai trouvé intéressant de manipuler l’API OLLAMA dans le cadre d’un réseau local afin d’offrir une solution viable et fiable dans une PME.

Mon application reste certes à évoluer pour être réellement concurrentiel aux solutions actuellement sur le marché. Toutefois est-ce là mon objectif ? Je ne crois pas, du moins je n’ai pas cette prétention.

Ce qui me rassurer néanmoins, ce que j’ai pu faire nativement peut donc être implémenté comme plugin d’une application, voir encore être utilisé comme une passerelle applicative entre deux applications. Par exemple, j’ai la volonté de reprendre mon projet de passerelle applicative entre VEEAMOne et ITOP pour générer des tickets sur le déclenchement d’une alarme d’exploitation géré par l’IA. Ca, c’est bandant comme projet et serait super faire un pas de plus vers l’efficience !

L’IA que je voyais comme une menace est ennemie au final selon l’usage que nous voulons en faire devient un outil puissant. Certes, j’ai mis du temps à être convaincu par la chose mais il n’est jamais trop tard. Le plus important pour moi est de rester supérieur à l’IA dans l’usage que je vais en faire.

Le mot de la fin :

C’est l’histoire d’un Lama qui rencontre un Lapin, vous buvez un verre ? Puis un homme rentre dans un bar. Stop appelez Brigitte BARDOT ! J’ai mon API qui me dérange ! Je je suis agnostique, je suis un lapin !

Erwan GUILLEMARD

Sources

• Windows : Installer Powershell pour Linux
• Article : OpenWebui
• Article : Ollama

1. IA : Intelligence Artificielle ↩︎
2. API : Application Programing Interface ↩︎
3. SS_045 : SystemScript #45 ↩︎
4. GS_045 : GraphicalScript #45 ↩︎
5. CLI : Client Lign Interface ↩︎
6. GUI : Graphical User Interface ↩︎
7. RHEL : RedHat Entreprise Linux ↩︎
8. SE : Système d’Exploitation ↩︎

Difficile néanmoins de progresser vite sur cette technologie puisque je suis Candide. M’enfin comme l’écrivait Franquin, je vais essayer de décortiquer la techno et son fonctionnement et de présenter ma compréhension de la chose. L’objectif étant naturellement de prouver s’il est possible d’altérer l’inaltérable du stockage objet.

Prérequis

• SE : RHEL, UBUNTU
• Apps : VEEAM B&R 12.1
• Autres :
  • Environnement GNU LINUX Durci
  • VEEAM B&R 12.1 et versions ultérieures
  • License VEEAM Entreprise

Avant Propos

Nous allons commencer par un petit brin d’histoire sur l’interface S3.

Qu’est ce que signifie l’interface S3 ? Il signifie Amazon Simple Storage Service (et oui, Jeff BEZOS in da house !). Contrairement à ce que j’ai pu penser, l’interface n’est pas toute jeune (quoi que vous me direz, le temps c’est relatif, non ?). L’API S3 a été officiellement mis sur le marché en 2006 par Amazon.

L’objectif initial était et reste de proposer à des entreprises un service de stockage de données dans le nuage et de s’assurer de la disponibilité et de l’intégrité de ces dernières. Ouai mais bon en 2006, le cloud c’est pas trop d’actualité, c’est plus l’ère du Personal Computer ? Pour la plèbe, oui, mais nous avons toujours un train de retard avec les grands GAFAM³ et autres sociétés de la tech 🙂

Bref, certaines entreprises décident de stocker leurs données chez Amazon à travers ce nouveau service pour s’affranchir des coûts et inconvénients d’un SI local. En contrepartie, Amazon facture ces dites entreprises au stockage (Go) ainsi qu’au trafic internet à destination de ces données. Depuis, l’usage a littéralement explosé puisque nous ne parlons plus en Gigaoctet, mais de manière commune en Téraoctet voir Pétaoctet et certains plus consommateurs que d’autres en Exaoctet (1 Eo = 1 000 000 000 Go) puisque l’usage du cloud n’est plus restreint à un besoin professionnel mais orienté comme un service à destination des usagers (coucou NETFLIX, SPOTIFY, FACEBOOK, X etc).

La base de l’API S3 est donc de fournir une disponibilité de la data la plus haute possible de manière sécurisé tout en restant le plus flexible possible. L’objectif étant de stocker des quantités phénoménales de données. Dans certains cas, il n’est pas rare de parler de DataLake (Lac de données).

Oui mais alors qu’est ce qu’on stocke ? Principalement tout et rien, c’est à dire des données de sauvegarde, d’archive, des applications, sites webs, contenu multimédia, bases de données, etc. Cependant tous ces types de données pour la plupart répondent à un même usage, le WORM⁴. (C’est un super jeu avec des vers qui se tirent dessus ? Non ça c’est WORMS 🙂 )

WORM signifie Write Once Read Many. Soit dans les faits j’écris une fois les données et je les consulte énormément. Par exemple, je charge une photo sur un réseau social. Je vais l’écrire une fois sur le système puis cette dernière sera visible et accessible de tous. La donnée ne va pas vivre. Sur ce principe, il va alors être possible de définir des algorithmes de segmentation de cette donnée pour garantir un gain d’espace, d’évolutivité, la sécurité de la donnée ainsi que sa disponibilité.

Si nous regardons à la loupe les 4 critères ces derniers permettent :

• Gain d’espace : Compression de la données avec déduplication et dans certains cas de l’eraser coding
• Evolutivité : Possibilité de définir un nouveau stockage et de joindre celui ci au système existant à travers internet.
• Sécurité : Les données sont traduites en objets et stockées à plusieurs emplacements de stockage permettant de reconstruire la donnée en cas de corruption d’un ou plusieurs stockages (sur la base de la reconstruction par parité). Il sera également possible de définir une durée de vie à cette donnée (coucou immutability). J’ai vulgarisé. En réalité, l’objet étant une entité logique, ce dernier est stocké sous forme de fragment… Complexe d’un coup non ? 🙂
• Disponibilité : A partir du critère précédent, si un des serveurs où se trouve ma donnée est HS ou momentanément inaccessible, ma donnée continue d’être disponible car ces données en tant qu’objet sont fragmentées sur d’autres serveurs.

Avant d’aller plus loin, il est important de comprendre que l’interface S3 a tout son sens en tant que SaaS⁵. Néanmoins, cela implique de souscrire à ce service chez Amazon par exemple. Ce n’est pas objectif car je recherche une solution OnPremise pour construire et éventuellement proposer ce service dans mon catalogue de service. C’est pourquoi il a été compliqué de trouver une solution S3 OnPremise totalement « open ». L’une des forces du stockage objet (S3) est sa flexibilité. L’un des inconvénients (selon moi) est comment s’assurer que les données (mes datas à moi) ne sont pas utilisées par autrui, sont bien supprimées etc ? Il faut faire confiance mais aujourd’hui cela ne suffit pas…

Bref, en cherchant un petit peu mais pas trop, j’ai identifié une solution opensource MinIO. C’est avec cette dernière que je vais m’amuser avec le stockage objet.

Théorie

L’une des premières questions que nous pouvons nous poser, Linux Hardened VS S3 ?

Comme j’ai pu le présenter dans un article précédent, l’immuabilité au sens hardened du terme est portée par l’OS⁶ nativement. Toutefois, ce dernier est plus adapté pour la protection des fichiers que des données et le risque se trouve au niveau du compte système (Root). S’il y a escalade des droits et donc contournement des mécanismes de sécurité, il est possible de supprimer les données en retirant l’attribut « i« .

Dans le cas de S3, l’approche est différente car c’est le moteur S3 qui gère l’immuabilité et les données ne sont pas stockées sous forme de fichier mais d’objet. Ainsi, pas possible de supprimer la donnée peu importe que nous soyons administrateur, Trump, Gourou d’une secte ou même une divinité. Toutefois, un acte physique devrait faire y arriver…

Histoire

Comme toujours, mon côté père castor il est important de s’intéresser à l’histoire de MinIO.

MionIO a été fondé en 2014 par Arnand Badu Periasamy, Garima Kapoor et Harshavardhana. L’objectif du projet est de démocratiser le stockage cloud autour de la technologie de stockage objet dans le vaste univers de la communauté OpenSource. C’est ainsi que naît Minimal Object Storage » ou MinIO :).

Une première release ou version voit le jour courant 2017. Durant cette période un changement de licence va être réalisé suite à son essor auprès de la communauté. L’ensemble des technologies est alors protégé par la licence GNU-AGPLv3. L’objectif étant de se prémunir des géants de la tech.

Par la suite, le bras de fer et les contentieux vont commencer. MinIO avec la montée en puissance de KUBERNETES est perçu comme une licorne. MinIO ira jusqu’à révoquer les droits d’usage de NUTANIX sur son service NUTANIX Objects pour violation de licence… Quand il y a du pognon en jeu, cela devient vite le bordel, je l’ai toujours dit… M’enfin. Le pourquoi ? L’usage commercial sans paiement, ça ne passe pas…

2025, MinIO cesse la publication d’images Docker et des binaires précompilés pour les versions communautaires. MinIO devient MinIO AIStor.

Malheureusement, c’est le cas classique d’un projet formidable ouvert à tous qui avec le temps s’enferme dans la génération de profit, de protection intellectuelle. MinIO souhaite avoir comme tous les acteurs de ce monde une part du gateau CLOUD+IA.

S3 versus Linux Hardening

Dans un billet précédent, je ventais par Mont et par Vaux les mérites et robustesses du hardening linux, mais qu’en est il du hardening S3 ?

Je pense que pour répondre à cette magnifique question, il est nécessaire de passer par un tableau (oui j’aime rédiger sous la forme de tableau).

Ce que nous pouvons conclure de cette analyse, S3 est plus à même de protéger les données que le hardening LINUX. S3 permettant une meilleure immuabilité dans le temps et ce dernier est prévu pour cet usage précis. Même si cela fonctionne avec la gestion de l’immuabilité LINUX.

Vous lecteurs, ne pouvez pas savoir la souffrance que cela m’apporte d’écrire de tels mots. J’ai toujours défendu bec et ongles le hardening linux et voyez vous, force est de constater que je suis dans le déni. Tel Pierre CAMBRONNE à la bataille de WATERLOO :

La garde meurt mais ne se rend pas.

Pierre CAMBRONNE

Même si dans mon cas c’est un peu exagéré (mais juste un iota hein 🙂 )

Mécanisme S3

Maintenant que nous savons faire la différence entre le hardening et l’API S3, intéressons nous à comment l’objet est rendu immuable 🙂 Chose que j’ai mise un certain temps à assimiler personnellement et qui je le pense ne doit pas forcément être très claire pour bon nombre d’entre nous.

S3 Comment ça marche ?

Pour faire simple car je rentre dans le détail dans la sous partie suivante, lorsque nous envoyons un fichier vers un média S3, le service S3 va générer un fichier de metadata qui va contenir toutes les informations de la donnée. Puis le fichier va être découpé suivant l’algorithme d’Erasure coding paramétré afin de définir notre donnée avec des blocs de données puis de parité.

Le moteur va alors stocker les donnée en respectant les contraintes de restauration et de disponibilité de la données sur chaque disque puis retournera à l’utilisateur le succès ou non de l’opération. Le stockage des données va se faire dans des Buckets.

La durée de vie de la donnée sera stockée dans le fichier de métadonnées. Ainsi, si je souhaite supprimer une donnée pour laquelle la durée de rétention n’est pas atteinte, lors de l’appel de l’opération de suppression, le moteur va lire le fichier de donnée puis me retourner une erreur 403 Forbidden car je ne réponds pas à la condition d’altération de la donnée.

Plutôt simple non ?

Déroulé d’un appel S3

Dans un premier temps, nous l’application (interne ou externe) va émettre une requête HTTP standard conforme à l’API S3. Un PUT pour écrire, un GET pour lire, un DELETE ou LIST pour gérer les objets. Dans les headers, nous devons retrouver les valeurs suivantes (x-amz-*). L’authentification est réalisée pour chaque requête côté client à travers une clé. MinIO vérifie la signature et va consulter les politiques IAM afin de définir si oui ou non l’opération est autorisée. Dans le cas contraire, nous aurons un joli 403 Forbidden. MinIO va parser l’URL afin de router la requête vers la bonne donnée objet dans le bon bucket ainsi que le header pour identifier l’opération à réaliser : Ecriture simple ? Multipart upload ? Téléchargement ? Suppression avec versionning ? Liste des objets ? C’est au niveau du moteur objet, coeur de l’application que tout va se jouer. Pour chaque Objet, MinIO va générer un fichier de métadonnée (x.meta) qui va contenir : Le checksum Le Etag La version La carte de blocks C’est alors l’Erasor Coding qui va découper la donnée en blocs de données et de parité. Les blocs sont distribués sur les disques selon la politique d’EC défini. Si c’est un succès, MinIO retournera le code HTTP 200/204 avec l’Etag de l’objet ainsi qu’un identifiant de requête. Dans le cas contraire (une surcharge par exemple ou un bucket qui n’existe pas) nous aurons un code HTTP 4XX ou 5XX avec un message compatible S3. Le chiffrement (SSE-S3 ou TLS), le versionning, les lifecycle rules et la réplication asynchrone fonctionnent de manière transparente sur toutes les opérations.

Architecture S3

Dans la logique, l’architecture que nous devrions mettre en place est la suivante :

• Infrastructure Clustérisé pour MinIO (ring)
• Protection par un certificat si publication du service
• Mise en place de NAT ⁷+ PAT⁸
• Configuration de l’Eraser Coding

Vous comprendrez qu’il n’est pas possible chez moi d’établir un ring.

Un seul argument s’y oppose, un seul ! C’est dangereux. Bah ceux qui n’aiment pas le danger, faut qu’ils choisissent une autre activité.

Nicolas SARKOZY

En l’occurrence, le danger étant ma formidable épouse, je vais choisir une autre solution. Je lui ai déjà pris une partie de son dressing, de la buanderie, je ne suis pas venu ici pour souffrir okay ? 🙂 (Je t’aime chérie, promis je vais faire le ménage).

Donc, pas de VM que du physique. Toutefois, je vous parle d’Eraser Coding. Qu’est que cela vient faire la dedans ? Je pense qu’une sous partie va être nécessaire.

Eraser Coding

L’Eraser Coding est un moyen de protection des données par calcul mathématique plutôt que la copie des données. Cette technologie est bien plus efficace en terme de stockage que le RAID ou la réplication.

Voyons plutôt.

Une donnée est découpée par N blocs de données et M blocs de parité. La configuration EC:M définit alors le nombre de blocs de parité. Exemple : EC:2, 2 blocs de parité.

Chaque bloc de parité est une combinaison linéaire des blocs de données calculée. Ainsi, n’importe quels N blocs parmi les N+M suffisent à reconstruire l’objet entier, que ce soit des blocs de parité ou de données. Si nous avons 4 blocs de données et 2 de parité, 4 blocs sur 6 permettent de reconstruire la donnée.

Les systèmes vont alors distribuer la donnée aléatoirement sur les disques de l’erasure définit. Soit un seul bloc par disque par objet. Aucun disque ne doit contenir deux blocs du même objet, puisque en cas de panne d’un disque, les blocs restants sur les autres disques doivent permettre de recalculer le bloc manquant.

Faisons une petite comparaison avec un RAID5 et RAID6.

Là on n’y voit plus clair, pourtant, il existe une relation à bien assimiler entre le nombre de parités possibles par rapport au nombre de disques. Cette règle est fondamentale et doit être acquise.

Disques Utilisables = Disques Totaux – Blocs de Parité

Espace Utilisables = (Disques Totaux – EC:N) / Disques Totaux

Donc on ne définit pas au doigt mouillé la parité de notre EC.

Je pense (comme dans tous mes billets lorsque j’arrive à la fin de la partie théorique) que nous sommes suffisamment armés pour nous lancer dans la partie pratique. J’ai choisi d’implémenter un stockage S3 pour mon serveur VEEAM.

Pratiques

Nous considérons que nous possédons déjà un Serveur VEEAM ainsi qu’un serveur physique de préférence (mais virtuel fonctionne aussi bien) RHEL⁹ ou UBUNTU/DEBIAN durci au préalable pour notre stockage objet.

Egalement, notre futur serveur de stockage objet (compatible S3) aura une partition dédiée au stockage montée et formatée au format XFS.

Brouillon enregistré.

Naturellement, cela va être un peu short niveau ressource donc je vais adapter en conséquence les paramètres de ma VM à défaut d’avoir un serveur physique dédié pour le stockage S3.

MinIO

Installation

Serveur

1 – Download me

Il sera nécessaire d’ajouter les sources de l’éditeur en téléchargeant le package RPM puis d’installer celui-ci.

## Community Edition
# wget https://dl.min.io/server/minio/release/linux-amd64/minio-20250907161309.0.0-1.x86_64.rpm -O minio.rpm

or

## AGPL License
# wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio-20240613225353.0.0-1.x86_64.rpm -O minio.rpm

/!\ Attention, ne privilégiez pas la Community Edition, sauf si vous savez ce que vous faites… Perso, nous partirons sur la version sous licence AGPL, bien plus complète.

2 – Install me

# dnf install minio.rpm

Client

Le client va nous permettre d’interagir directement avec notre daemon en ligne de commande.

# curl -L -o /usr/local/bin/mc https://dl.min.io/client/mc/release/linux-amd64/mc

# chmod +x /usr/local/bin/mc
# /usr/local/bin/mc --version

Configuration Système

J’enfonce une porte ouverte. Mais cette étape est importante car elle représente un enjeu majeur de la sécurité de notre serveur de stockage dédié à la sauvegarde et donc de notre système d’exploitation.

1 – Compte dédié

Dans le respect des bonnes pratiques ANSSI nous allons créer un compte système sans home et groupe dédié au service MinIO.

# groupadd -r minio
# useradd -M -r -g minio minio

Nous définissions les droits sur notre répertoire (point de montage naturellement) ainsi que les permissions adéquates.

# chown minio:minio /mnt/minio
# chmod 700 /mnt/minio
# ls -al /mnt/minio

2 – Setting MinIO Systemd Service File

Créons le fichier qui va nous permettre de lancer notre daemon MinIO au démarrage de notre système.

# vim /usr/lib/systemd/system/minio.service

[Unit]
Description=MinIO
Documentation=https://docs.min.io
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
Type=notify

WorkingDirectory=/usr/local

User=minio
Group=minio
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStartPre=/bin/bash -c "if [ -z \"${MINIO_VOLUMES}\" ]; then echo \"Variable MINIO_VOLUMES not set in /etc/default/minio\"; exit 1; fi"
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576

# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity

SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

Attention de bien remplacer la valeur des variables User et Group par celles que nous avons créées précédemment.

3 – Variable d’environnement

Créons maintenant le fichier contenant nos variables d’environnement qui sera utilisé par notre service.

# vim /etc/default/minio

Prenez le temps de définir le nom ainsi que le mot de passe du compte super administrateur qui permettra de s’authentifier à l’interface WEBUI. L’accès à l’interface se fera sur le port 9001.

# MINIO_ROOT_USER and MINIO_ROOT_PASSWORD sets the root account for the MinIO server.
# This user has unrestricted permissions to perform S3 and administrative API operations on any resource in the deployment.
# Omit to use the default values 'minioadmin:minioadmin'.
# MinIO recommends setting non-default values as a best practice, regardless of environment

MINIO_ROOT_USER=adm.minio
MINIO_ROOT_PASSWORD=***********************

# MINIO_VOLUMES sets the storage volume or path to use for the MinIO server.

MINIO_VOLUMES="/mnt/minio"

# MINIO_OPTS sets any additional commandline options to pass to the MinIO server.
# For example, `--console-address :9001` sets the MinIO Console listen port
MINIO_OPTS="--console-address :9001"

En termes de permission sur le fichier, ces derniers sont en modification uniquement par le compte root. Donc nous sommes rassurés.

4 – Manivelle et Service au démarrage

Comme toujours, nous allons faire en sorte que notre daemon démarre lors de la mise sous tension de notre serveur.

Pour ce faire, vérifions dans un premier temps que le service se lance bien.

# systemctl start minio.service
# systemctl status minio.service

Puis comme d’accoutumé

# systemctl enable minio.service

5 -Firewall

Il y a deux choses à bien différencier quant à notre service MinIO. La partie console d’administration et la partie API pour le flux de données.

• Console WEBUI : Port 9001/tcp
• Protocol S3 : Port 9000/tcp

Il est donc nécessaire d’ouvrir les flux sur notre firewall.

# firewall-cmd --permanent --add-port=9001/tcp
# firewall-cmd --permanent --add-port=9000/tcp
# firewall-cmd --reload

Naturellement, si nous souhaitons publier notre service de stockage S3 sur le WEB, il conviendrait de faire un SPAT de IP_PUB:443 à destination de notre IP_LOCAL_MINIO:9000. Pour renforcer la sécurité, nous implémenterons IPS, Géolocalisation, Application Control et filtrage sur les IPs Publics entrantes habilitées uniquement.

Il nous reste alors à créer notre règle sur notre firewall pour accéder à notre interface web. Puis depuis notre navigateur favori d’accéder à notre interface (pour l’instant en http).

A partir de maintenant, nous allons attaquer les choses sérieuses. C’est parti pour les buckets et l’assaut du Colonel Kentucky !

Certificats

Naturellement il va falloir que l’on sécurise un minimum nos services web. Par défaut MinIO utilise le protocole HTTP¹⁰. Pour ce faire je vais me simplifier la tâche en utilisant un certificat auto-signé. J’ai la flemme monstrueuse de passer par un let’s encrypt de me taper des règles de PAT¹¹ entre ma box, mon UTM¹²…

# vim openssl.cnf

Pour ne pas me prendre la tête, je passe dorénavant par des fichiers de configuration tout prêts. Les données les plus importantes étant comme nous pouvons nous en douter les SANs¹³ (et là je ne parle pas stockage, bande de petits malins).

[req]
default_bits = 4096
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[dn]
C = FR
ST = France
L = MACON
O = RONELAB
CN = egapl-minio-01.ronelab.lan

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = egapl-minio-01.ronelab.lan
IP.1 = 10.127.252.250

Nous générons notre clé privée et notre certificat public avec notre bon vieux openssl des familles.

# openssl req -x509 -nodes -newkey rsa:4096 -days 3650 -keyout private.key -out public.crt -config openssl.cnf

Nous créons si ce n’est pas le cas le répertoire home de notre utilisateur de service dédié à MinIO (dans mon cas « minio »), et reste à déplacer les fichiers générés ainsi que l’attribution des permissions pour garantir un minimum de sécurité.

# mkdir -p /home/minio
# mkdir -p /home/minio/.minio
# mkdir -p /home/minio/.minio/certs

# mv public.crt /home/minio/.minio/certs/
# mv private.key /home/minio/.minio/certs/

# chown -R minio:minio /home/minio
# chown -R 700 /home/minio
# chown 600 /home/minio/.minio/certs/private.key
# chown 644 /home/minio/.minio/certs/public.crt

Ne reste alors plus qu’à restart notre daemon et avanti !

# systemctl restart minio

Une chose de plus en moins à réaliser. Passons à la suite. 🙂

Configuration Bucket

La première question est qu’est ce qu’un bucket ? Et je ne parle pas du saut de poulet spaghetti que l’on trouve à KFC M’sieurs Dames. Un peu de sérieux ! (Dixit le gars… C’est le camembert qui dit au curé qu’il est communiste ?)

Un bucket, est un conteneur logique qui va stocker des objets (fichiers et les métadatas). Si nous faisons une comparaison avec un système de fichiers classique nous aurions :

Chaque bucket a sa propre configuration comme :

• Les droits d’accès
• Le chiffrement des objets qui le compose
• Le versionning
• Les règles de cycle de vie (suppression, archivage etc)

Là où nous allons devoir être vigilants va se trouver sur la méthode de création du bucket. En GUI¹⁴ et CLI¹⁵, nous n’avons pas les mêmes options et cela va avoir un impact sur certaines applications et dans mon cas un impact sur VEEAM.
Je ne présenterai que la partie CLI. La partie GUI, il faut RTFM¹⁶… 🙂

CLI

1 – Alias ou AKA

Avant de créer notre bucket il va être nécessaire de créer un alias.

# mc alias list
# mc alias set ronelab http://127.0.0.1:9000 adm.minio 'MyPassword_define_in_file'

2 – Bucket

Une fois notre alias défini nous allons pouvoir créer notre bucket pour VEEAM. Il est important de préciser l’argument -l.

L’argument signifie que ce bucket à l’ObjectLock d’activé. Ce qui va permettre de gérer l’immuabilité des données sur une durée définie.

# /usr/local/bin/mc mb -l ronelab/veeambucket

Nous pouvons également voir les statistiques liées à notre bucket ainsi que sa configuration.

# /usr/local/bin/mc stat ronelab/veeambucket

3 – Account Keys & Policy

# mc admin user add ronelab veeamuser 'MyVeeamPassword'

Définissons la politique qui va être attachée à notre utilisateur. Dans notre cas, les droits de lecture et écriture.

# mc admin policy attach ronelab readwrite --user veeamuser

Vérifions que tout est bon.

# mc admin user info ronelab veeamuser

L’utilisateur étant créé, nous pouvons générer notre clé d’accès qui servira plus tard à l’authentification de l’application VEEAM.

# mc admin user svcacct add ronelab veeam-minio

VEEAM

L’article à la base, je l’avais commencé sur VBR¹⁷ 12.1 courant 2024. Puis ayant dû me focaliser sur ma vie professionnelle et personnelle par la suite, je me dois de refaire l’intégralité de l’intégration sur VEEAM 13.0.X, et plus particulièrement sur la VSA¹⁸ 13.0.X <3

S3-Repository

Comme toujours avant de créer un job, il est nécessaire de passer par la phase d’ajout d’un nouveau backup repository.

Dans Backup Infrastructure, sélectionnez Backup Repositories et avec votre plus beau clic droit, choisissez Add… Le type de backup sera de nature Object storage. Il est important de choisir S3 Compatible puis de choisir de nouveau ce dernier (je pense que MinIO est en capacité de prendre en charge du S3 Glacier, mais dans le doute je ne vais pas m’avancer…).

Une fois cette étape passée, nous voilà enfin dans le Wizard pour configurer notre repo S3.

Honnêtement, rien ne change vraiment de l’ajout d’un repo classique mais je trouve toujours sympa d’illustrer mes actions. Cela me donne un côté sérieux. Toujours dans les limites de mon infra, j’ai limité le nombre de tâches parallèles à 1.

Le gros du travail se situe à l’étape 2 Account. Là en tant que service point, saisissez l’url de votre serveur https://egapl-minio-01.ronelab.lan:9000 [/!\ Attention : Je me suis encore fait avoir sur la capture d’écran… Le port pour l‘API S3 est 9000 et non 9001. A bon entendeur..]. Renseignez la location et complétez les credentials. Pour cette étape, lors de notre création en ligne de commande précédemment, les informations vous ont été retournées. Ce sont ces dernières qui sont attendues. Lorsque vous cliquerez sur suivant, dans le cas de certificat SSC¹⁹, il faudra accepter comme d’accoutumé le certificat.

La partie 3, Bucket est la dernière étape qui diffère d’un ajout classique. Il faudra choisir le bucket à partir du bouton Browse. Si par pur hasard vous obtenez un message d’erreur de la part de VEEAM c’est que vous avez surement utilisé le port 9001 et non 9000 :). Choisissez également le répertoire. Si aucun n’est présent, créez en un depuis le wizard. Il est important de comprendre que l’immuabilité est portée par VEEAM et non par MinIO. C’est pourquoi c’est à vous de cocher la fonctionnalité Immutability Settings et de définir la période d’immuabilitée.

Pour les autres étapes du Wizard, c’est de la rando. Je vous laisse poursuivre.

Une fois le wizard terminé, si nous regardons notre infrastructure, nous retrouvons bien notre nouveau repo 🙂 <3

Job Configuration

Pour la création du job, cela va être exactement la même chose que la création d’un job classique. Le seul point qui va diverger (Oh il a écrit verge… Okay cool…) va être le choix du repository S3, et c’est tout…

Toujours pour des problématiques d’infrastructures j’ai volontairement restreint la planification du job. De toute façon, l’Appliance va être archivé d’ici la fin de semaine donc OSEF j’ai envie de vous dire…

Notre job étant créé, place au test 🙂

Tests

Le test est plutôt simple, je vais lancer un job et tenter de supprimer ce dernier depuis la console VEEAM.

Début	Fin

La sauvegarde s’est bien déroulée, donc cela prouve qu’avec le durcissement ANSSI²⁰ et notre configuration de MinIO je n’ai pas fait de me**e. Regardons notre chaine de sauvegarde.

Si je choisis de supprimer le point, vais je pouvoir supprimer le backup ? La réponse est évidemment non mais nous nous devons de vérifier ce point.

J’ai envie d’écrire, la messe est dite. L’immuabilité fonctionne.

Je me suis posé la question comme pour la partie hardened de supprimer les données de mon serveur standalone. La réponse est évidemment oui si j’ai les droits root. Je peux démonter le disque ou supprimer son contenu. Toutefois, et c’est là que je n’ai pas les ressources, mais si c’était un ring je n’aurais pas pu.

J’ai mentionné plus haut que même une divinité ne peut supprimer les données c’est pourquoi je nuance mes écrits. Il sera toujours possible à l’utilisateur, que dis-je administrateur qui a tous les accès de supprimer les données.

Conclusion

Cet article fait partie des premiers que j’ai commencé à écrire en 2024 et puis je l’ai abandonné. Je pense par frustration à l’époque.

J’ai toujours défendu bec et ongle l’immuabilité hardened vis à vis de l’immuabilité S3. Pourtant il convient de reconnaitre de ma part que le Storage S3 offre plus de sécurité. Néanmoins je reste convaincue qu’un repo hardened répond très bien au ESN ayant aux moins deux sites et qui veulent arrêter de s’emm***er avec des rotations de disque dur externe (même si cela reste une solution viable et qui est toujours mieux que rien).

Dans les deux cas, je trouve bien la possibilité dans ces deux cas de pouvoir recycler des équipements (serveurs) considérés comme obsolètes pour des environnements de production pour les utiliser comme repo S3 standalone ou hardened.

Si je devais faire un choix ?

Je répondrai en politicien, avec ma plus belle langue de bois. Cela dépendra du contexte. 🙂 Il faut garder à l’esprit que le Hardened protège plus facilement des ransonmware, des erreurs humaines et des compromissions VEEAM. A l’inverse, S3 est plus adapté contre la suppression logique, la conformité réglementaire, les suppressions depuis VEEAM.

Toutefois, si j’avais continué ma carrière en ESN, j’implémenterais ce type de solution avec 3 nodes « obsolètes » sur le papier en conservant une extension de garantie des équipements et intégrerais MinIO au catalogue de service. Mais ça, c’est si j’étais toujours dans une ESN.

L’une des ouvertures et projet à venir serait de monter un ring sur 3 sites différents…

Finalement, c’est beau et bien de terminer un article plus de deux ans après… 🙂

Le mot de la fin :

Je range un cadeau dans MinIO, le S3 applaudit en IPv6, le bucket éternue, et ma théière me retourne une Error 418. Très joli coup. Vous passez en case Jacob Delafonte.

Erwan GUILLEMARD

Sources

• AMAZON S3
• Apps – VEEAM Repo & Backup Hardened
• LINUX – useradd Man
• MinIO – Install Guide
• MinIO – VEEAMBucket

1. SE : Système d’Exploitation ↩︎
2. S3 : Simple Storage Service ↩︎
3. GAFAM : Google Amazon Facebook Apple Microsoft ↩︎
4. WORM : Write Once Read Many ↩︎
5. SaaS : Software As A Service ↩︎
6. OS : Operating System ↩︎
7. NAT : Network Address Translation ↩︎
8. PAT : Port Address Translation ↩︎
9. RHEL : RedHat Entreprise Linux ↩︎
10. HTTP : HyperText Transfert Protocol ↩︎
11. PAT : Port Address Translation ↩︎
12. UTM : Unified Tread Management ↩︎
13. SAN : Subject Alternative Name ↩︎
14. GUI : Graphic User Interface ↩︎
15. CLI : Command Line Interface ↩︎
16. RTFM : Read The Fucking Manual ↩︎
17. VBR : Veeam Backup et Replication ↩︎
18. VSA : Veeam Software Appliance ↩︎
19. SSC : Self-Signed Certificat ↩︎
20. ANSSI : Agence National de Sécurité des Systèmes d’Informations ↩︎

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