J’ai trouvé l’idée excellente et c’est par nostalgie et regard critique que je me lance à l’aventure pour vous faire découvrir comment je suis arrivé là où j’en suis aujourd’hui. Je pense alors que vous comprendrez mon évolution à travers le temps 🙂

Avant-Propos

Naturellement, le mémoire est repris en tant que tel. Je ne touche pas à son contenu. Les syntaxes et autres fautes d’orthographes resteront à la postérité. 🙂

Ce projet de fin de cycle est particulier car il a été réalisé à quatre main. Les deux mains de l’auteur ainsi que les deux mains de Robin GRIVET, camarade avec qui le projet a été un pur plaisir de collaboration si ce n’est plus. Cela sonne comme un petit air de remember 🙂

La thématique du projet était de développer un banc de test pour réaliser des contrôles non destructifs par Magnéto Impédance Géante (GMI¹). En partenariat avec le LPP² et le Lycée Eiffel de Dijon, (promotion 2012) et ARDPI³.

Le document ci-dessous se déroule en 3 parties. Une partie commune, une partie propre à chacun de nous sur des tâches bien précises. Afin de ne pas tronquer le document la partie de mon binôme sera également présenté. Son droit d’auteur lui appartenant et je me réserve sous son avis de retirer ce dernier.

Attention, vous voilà parti pour un voyage de 67 pages 🙂

Partie Commune

Analyse du cahier des charges

Présentation du projet

L’objectif de notre projet est de développer un système de contrôle non destructif (CND⁴) par magnétoscopie avec un capteur à effet de magnéto impédance géante (MIG ou GMI en anglais) afin de réaliser un scan de la cible ferromagnétique pour contrôler la qualité de cette dernière.

Le projet consiste à analyser par balayage les imperfections présentent dans les matériaux dans le domaine de l’industrie ou de localiser des tumeurs cancéreuses dans le domaine médical.

Nous réaliserons le banc de test de ce capteur. Le capteur quand a lui est conçu par 2 partenaires. L’un de nos partenariats est établit avec le Laboratoire de Physique de Plasma situé à PALAISEAU (F-91128) pour qui nous allons développer le banc de test pour qu’ils puissent tester leurs capteurs GMI. Le second partenaire est l’entreprise ARDPI situé à SELONGEY  (21260) qui commence à s’intéresser au développement de banc de test pour les capteurs de types CND et qui développe en même temps que nous un banc de test similaire. Seul le Laboratoire de Physique des Plasmas a pu nous fournir un capteur GMI. L’entreprise ARDPI, elle n’a pas encore eu le temps de développer son propre capteur. Nous nous baserons donc sur le capteur fourni par le LPP.

Partenaire

Laboratoire de Physique des Plasmas Ecole Polytechnique Route de Saclay F-91128 PALAISEAU Cedex	Lycée Gustave Eiffel DIJON 15 Avenue Champollion 21000 DIJON	Agence pour la Recherche et le Développement de Produits Industriels 39 Bis Rue de la Roche 21260 SELONGEY

Cahier des charges

Nous sommes contraints d’après un cahier des charges bien définies de traiter un certain nombre de spécification.

Objectif:   Faire une analyse de la pièce sans contact.   Fonctionnalités:   Paramétrage personnalisable :    Cette fonctionnalité permet de pouvoir définir des paramètres comme les paramètres d’alimentation du capteur GMI, d’acquisition, de l’alimentation de l’émetteur de champ et des paramètres du Robot 3 axes  souhaitées. Ces données seront stockées dans un fichier au format XML.   Mode Manuel :   Ce mode doit permettre à l’utilisateur de pouvoir réaliser le paramétrage du capteur GMI par déplacement manuel (Joystick)  de façon précise en concordance avec le capteur Z. Dans le cas de capteur de type CND au parle de contrôle du lift-off.   Mode Automatique :   Une fois avoir définie les paramètres souhaitées, l’on peut démarrer la séquence de balayage de la pièce en ayant positionné le capteur sur le début de la cible ferromagnétique. Une fois la séquence terminée, les données seront enregistrées.   Surveillance Vidéo :   Permet de vérifier qu’il n’y est pas de contact entre le capteur CND et la cible afin d’éviter toute détérioration des deux instruments.   Sauvegarde & Consultation des données :   Sauvegarde les données de l’acquisition ainsi qu’une copie de paramètres souhaités dans un fichier de type TXT. Le contenu de ce fichier doit être exploitable. Lors d’une consultation de donnée, l’on doit pouvoir retranscrire dans un plot 3D les données et nous devons afficher les valeurs dans un tableau.   Affichage plot 3D :   Le plot 3D doit présenter une représentation du contenu de la pièce en affichant une image de la cible en fonction des données d’acquisition. De plus, les paramètres du Plot 3D doivent être modifiables par l’utilisateur.

Contraintes

Ce projet est définis selon un certain nombre de contraintes, que ce soit des contraintes dû au développement du programme (contraintes logicielles) ainsi que du matériel imposé ou spécifier par le client (contraintes matérielles). Mais le plus important reste la contrainte budgétaire imposé par le client ainsi que le temps impartie pour élaborer le développement du système.

• Contrainte budgétaire :  2 500€.
• Contrainte temporelle :  220 heures

Spécifications Logicielles

• Le fichier de configuration système doit être au format de fichier XML.
• L’enregistrement des données doit être au format TXT.
• Doit comporter 2 modes de pilotage : Automatique et manuel. – Le pilotage doit être synchronisé avec l’acquisition.

Spécifications Matérielles

Besoins et fonctionnalités

Présentation Matérielle

Nous allons présenter dans cette partie, le matérielle ainsi que les logiciels et autres softwares dont nous avons besoin de manière générale. Une présentation plus poussée du matérielle sera faite dans chacune des partie individuelles.

Ressource Matérielle

	PXI5 NI-1042Q qui est notre PC6 embarqué. Ainsi que les que celui-ci comporte.   (cf Partie Individuelle)
	Générateur Base Fréquence de nom Agilent 33220A. Pouvant être commandé à distance via le protocole GPIB7.
	Le Charly Robot 3 axes et son contrôleur de puissance communicant via la liaison RS2328.
	Webcan de marque Hercule et un Joystick de chez Logitech en interface de connexion USB. (cf Partie Individuelle)
	Capteurs fin de course pour le Charly Robot 3 axes. Capteur Analogique pour l’axe Z du Charly Robot 3 axes. Différents capteurs CND de type GMI. (Nous renvoyons pour plus d’information vers les parties individuelles)

Ressource Logicielle

	Lecteur Média player sous licence GPL9 (gratuit). Permet d’afficher la WebCam dans l’application.
	Logiciel de réalisation des diagrammes de type UML10.
	Logiciel de réalisation des diagrammes de type UML et de dessin pour schéma électrique.
	IDE11 Labview Version 8.0, nécessaire pour exécuter l’application.
	OS12 Windows XP Pack SP213 présent sur le PC embarqué.

Analyse et distribution des taches

Répartition des taches

Analyse

Nous allons utiliser un boîtier de connexion National Instrument Scb-68 pour connecter les différents capteurs présent sur le robot.

Le déplacement de la colonne du robot se déroule sur 3 axes : X, Y, Z. Donc il est nécessaire d’ajouter des capteurs fin de course pour éviter de forcer le robot quand celui-ci arrive au maximum de sa position. Il nous faut donc :

• 2 capteurs de positions de type TOR pour les axes X et Y.
• 1 capteur de position de type ANALOGIQUE pour l’axe Z afin de pouvoir gérer le lift-off du capteur GMI.

Dans un premier temps, nous utiliserons un PC pour les phases de prototypages. Puis nous travaillerons avec un PXI 1042Q contenant un système embarqué (dont LabView  comme plateforme de développement (IDE)), un oscilloscope, un GBF¹⁴, 2 ports USB, un port RJ45, comportant 8 slots possible pour pouvoir rajouter des cartes d’acquisitions. La possibilité de pouvoir rajouter plusieurs cartes d’acquisitions et un choix déterminant qui explique pourquoi nous utilisons pour le projet un PXI avec PC embarqué, et non un PC.

Pour commander le robot, nous devons avoir un contrôleur de puissance pour faire l’intermédiaire entre le robot et le PXI, afin de pouvoir traduire les trames envoyées au Charlie Robot.

Conception Générale

Configuration

Ce diagramme de flots de données représente le fonctionnement de la fonctionnalité « Configuration » en expliquant de manière générale le fonctionnement de réglage et de commande des instruments.
	De façon plus détailler, l’on voit le fonctionnement plus détaillé de la « Configuration Emetteur ».

Sauvegarde

Ce diagramme de flots de données représente le fonctionnement de la fonctionnalité « Sauvegarde» en expliquant de manière générale le fonctionnement d’enregistrement des données.

Mode Manuel

Ce diagramme de flots de données représente le fonctionnement de la fonctionnalité «Mode Manuel» en expliquant de manière générale le fonctionnement du contrôle du robot 3 axes (via un Joystick) ainsi que de l’affichage des données.

Mode Automatique

Ce diagramme de flots de données représente le fonctionnement de la fonctionnalité «Mode Automatique» en expliquant de manière générale le fonctionnement du contrôle du robot 3 axes ainsi que de l’affichage des données.

Synchronisation

Pour pouvoir réaliser l’acquisition suivant le mode de balayage automatique, nous devons réaliser une synchronisation entre ces deux fonctionnalités. Nous avons donc choisie de faire une synchronisation de type logicielle. C’est-à-dire que nous allons laisser le programme faire des acquisitions en continue. Mais si la position retournée par le Charly Robot est différente de la position actuelle, alors nous enregistrons la valeur acquise.

Nous avons représenté à travers ce diagramme d’activité le fonctionnement général de notre application logicielle.  Nous avons trois activités distinctes, qui sont les activités du Charly Robot 3 axes, les activités de l’application commandant le Charly Robot 3 axes et l’application qui commande l’acquisition.

Nous démarrons les 3 activités en même temps. 

Dans un premier temps, nous allons initialiser le Charly Robot en générant une trame que nous allons envoyés. Le Charly Robot dés que celui-ci à été mis sous tension attend de recevoir une trame. Une fois cette trame reçue, il va exécuter la trame reçue. Si l’opération a échouée, le Charly Robot retourne un acknowledge d’erreur, à l’application commandant le Charly Robot. Celui ne peut continuer sans la réception de l’acquittement. Sinon, dans le cas où l’opération à réussi, le Charly Robot retournera un acknowledge valide.  

Auparavant, nous avons initialisé les paramètres d’acquisition. Puis l’on lance l’acquisition. Nous attentons l’acknowledge valide du Charly Robot pour valider l’acquisition des données. Puis, l’on enregistrera ces valeurs avant de recommencer l’opération c’est-àdire la réception d’un acquittement valide renvoyé par le Charly Robot.

Consultation

Ce diagramme de flots de données représente le fonctionnement de la fonctionnalité «Consultation» en expliquant de manière générale le fonctionnement de la lecture et l’affichage du contenue des données sauvegardées.

Intégration Commune

Légende :     En vert les fonctionnalités développées par l’étudiant 1 : Robin GRIVET   En bleu les fonctionnalités développées par l’étudiant 2 : Erwan GUILLEMARD   En jaune les fonctionnalités principales de l’application   En rose : L’Application Générale   En saumon la fonctionnalité de navigation de l’application générale.

Développement

Interface

Voici le prototype de l’interface de notre application. La navigation dans cette application se passe sur une seule fenêtre. Nous avons caché les onglets de navigation, et choisie de naviguer dans l’interface à partir des boutons en haut de la fenêtre.

En sélectionnant l’un des boutons, nous allons changer d’onglet. Il en est de même pour les sous onglets de navigation, mais nous ne jugeons pas nécessaire de s’étendre sur ce point car la méthode de navigation est la même.

Mode User/Admin : Navigation

Comme dis plus haut, nous proposons un mode supplémentaire au cahier des charges. Nous voulons créer un mode utilisateur qui aurait accès a toutes les fonctionnalités décrites dans le cahier des charges, et créer un mode administrateur qui lui aurait accès à un onglet en plus, l’onglet OPTIONS il faut donc l’appeler autrement (voir commentaire plus haut).

Le contenu de cet onglet permet d’avoir accès à un affichage plus poussé et qui n’est pas nécessaire pour l’utilisateur. De plus, l’administrateur à la possibilité de configurer des paramètres de base de l’application auxquels l’utilisateur n’a pas l’utilité d’y avoir accès. 

C’est sur l’onglet ACCEUIL de notre application que nous sélectionnons le mode d’utilisation. Par défaut, le mode de connexion est paramétré pour se lancer en mode  « USER ». Pour changer de mode d’utilisation, il suffit de sélectionner le mode « Administrateur ». Un mot de passe est alors demandé. Si l’identification de marche pas, « l’Accès est refusé ». Si l’identification est valide, « l’Accès est autorisé ». Le mot de passe est password.

Au début, nous effectuons une identification avec une structure conditionnelle. Se qui se traduirait en langage C par un Switch case. Nous avons attribué la valeur de 0 pour l’identifiant Utilisateur, et 1 pour l’identifiant Administrateur.

L’on récupère l’état des boutons pour pouvoir savoir qu’elle onglet faire apparaitre. Nous utilisons ensuite un nœud de méthode du conteneur  MenuPrincipal qui va par la suite nous permettre dans le cas d’un accès autorisé de faire apparaitre le sixième onglet du conteneur MenuPrincipal par l’utilisation d’un nœud de propriété en rendant le bouton visible et en autorisant l’accès à cette onglet  « OPTIONS ».

Le code dans le cas ou l’identifiant choisie est Utilisateur, nous masquons avec les nœuds de méthodes et de propriété l’onglet « OPTIONS » ainsi que le champ demandant le mot de passe et le bouton pour soumettre l’accès. Cependant, la navigation des onglets ne change pas.

Conclusion

Pour parfaire cette partie commune, nous pouvons donc dire que la quasi-totalité du projet qui nous à été donné à été réalisé. Nous avons seulement quelques fonctionnalités qui ne sont pas complètes. 

La partie Synchronisation est en cours de recherche et nous à posé et nous pose encore des problèmes.

Pour ce qui est du Mode Automatique, il reste seulement à intégrer le code des capteurs fin de course du Charly Robot 3 axes. 

Le Mode Manuel est incomplet car nous ne traitons pas le positionnement du capteur Z pour contrôler le lift-off du capteur GMI. La fonction d’Acquisition est elle non complète du fait du problème d’interface de connexion entre la carte d’acquisition 6251 et l’oscilloscope 5112.

Et la fonctionnalité du Capteur Z n’est pas complète, car l’on ne contrôle pas le positionnement de l’axe Z en fonction du lift-off souhaité pour le capteur GMI.

Partie Individuelle : Travail Réalisé par GRIVET Robin

Analyse des Fonctionnalités

Pour pouvoir réaliser le déplacement du capteur magnétique (GMI : Giant Magneto Impédance), nous devons détacher les différentes fonctionnalités composant le système.

Je devrais réaliser les fonctions permettant le pilotage du robot, ainsi que son contrôle visuel : Pilotage manuel du robot Ce mode permet le déplacement du robot à partir d’un joystick Il permet d’optimiser les paramètres du robot et a terme d’améliorer les acquisitions automatique Scan magnétique automatique Le scan sera effectué de façon automatique à partir des paramètres du mode manuel. Les paramètres d’acquisition seront enregistrés dans un fichier XML (Etudiant 2) afin de garder une trace des paramètres de chaque acquisition. Contrôle visuel caméra Le contrôle visuel permettra de contrôler les déplacements du robot depuis le poste utilisateur. Il sera possible de mettre en pause l’acquisition d’image. Acquisition Distance Z et fin de course Distance Z : L’acquisition du lift-off (distance entre le capteur et la pièce à scanner) sera nécessaire pour éviter la collision entre le capteur et la cible, ainsi que pour modifier la précision des acquisitions du capteur GMI. Les capteurs fins de course seront utilisés pour protéger le robot : ils permettront d’avoir un contrôle logiciel des dépassements de la zone de déplacement du robot.

Les capteurs fins de course seront utilisés pour protéger le robot : ils permettront d’avoir un contrôle logiciel des dépassements de la zone de déplacement du robot.

• Convertisseur 24V to 5V : Permet de réaliser l’alimentation de la carte interface des capteurs (Z et fin de course) en 5V depuis une alimentation 24V afin de réaliser l’acquisition des tensions des capteurs.
• Webcam : Permet l’acquisition d’images pour le contrôle visuel
• Joystick : Permet de faire l’acquisition des mouvements de l’utilisateur pour ensuite piloter le robot manuellement.
• Capteur de position optique : Permet de mesurer la distance entre le capteur GMI et la cible à analyser. Il sera utilisé pour la sécurité du robot et pour paramétrer les acquisitions.
• Interrupteur fin de course : Permet d’acquérir des signaux correspondant à un dépassement de la table du robot et à termes permettront de mettre hors tension le nouveau contrôleur du robot.

Pilotage manuel du Robot

Nous disposons d’un robot Charly pilotable sur 3axes. Il est alimenté par un module de puissance qui traduira les commandes de l’utilisateur pour les  moteurs pas à pas du robot. Le module est piloté par des trames de chaines de caractères via RS232.        Pour acquérir les déplacements que l’utilisateur désire réaliser, Nous devrons acquérir les données d’un joystick, pour ensuite traduire celles-ci en commande pour le robot.   Logitech Attack 3   11 Boutons programmables USB Faible coût (30€)

Scan magnétique automatique

Ce scan devra permettre l’acquisition d’une cible de façon totalement autonome. L’utilisateur devra auparavant utiliser le mode manuel afin de paramétrer l’acquisition automatique.  Pour cela, il faudra choisir plusieurs paramètres :

• La distance Z entre le capteur et la cible
• Le pas de déplacement du robot (résolution)
• Un point de référence
• La surface de la zone à scanner

Le mode manuel permettra à l’utilisateur de définir et d’optimiser ses paramètres. Plusieurs mesures pourront être effectuées pour être ensuite comparer. On déduira ainsi les meilleurs paramètres de l’acquisition pour la cible en question, dans le but d’améliorer la rapidité entre chaque acquisition.

Le scan va suivre une séquence de déplacement de type balayage :

Contrôle visuel caméra

L’utilisateur disposera d’un contrôle visuel en temps réel sur le robot grâce à une caméra. Celle-ci permettra de contrôler les déplacements depuis le poste de commande des l’utilisateur en mode manuel. Ce contrôle permet également de surveiller le bon déroulement des acquisitions avec une certaine distance de sécurité entre le poste de contrôle le banc d’acquisition (Dans le  cas de matériaux dangereux par exemple).

Ce contrôle sera effectué avec les fonctions activeX ainsi qu’avec un programme de traitement vidéo compatible avec activeX. Nous avons donc choisi VLC 1.0.1 car la dernière version de ce logiciel pose des problèmes de compatibilité avec le plugin activeX. L’acquisition des images ce fera de façon permanente et ce dès le lancement du programme. Il sera possible de mettre en pause l’acquisition, et également de la relancer.

Hercules Classic Silver   30 Images par seconde Résolution vidéo 800×600 Pince de fixation Faible coût (20€)   La qualité de l’image n’étant pas la priorité de notre contrôle, nous avons donc choisi une webcam bon marché.

Acquisition distance Z et fin de course

Nous disposons d’un capteur de type analogique sur l’axe Z, afin d’éviter que le capteur GMI entre en collision avec la cible à analyser ce capteur permettra de contrôler le lift-off. Pour faire l’acquisition de ce capteur, je devrai réaliser une carte d’interface.

Elle permet l’acquisition :

• D’une tension analogique 0-3V du capteur Z
• De 4 tensions logiques 0-5V des capteurs de fin de course

Les capteurs de fin de course tout-ou-rien (TOR¹⁵) sont disposé sur le robot de façon à traduire un dépassement sur les axes X et Y (min et max). Nous ferons ensuite l’acquisition de ses tensions avec la carte SCB68 afin de les faire intervenir dans le programme.

Interrupteur fin de course	Panasonic AZ7100   Grande résistance aux chocs Faible coût (8€)   Les capteurs de fin de course on été choisie selon un critère de solidité afin que les déplacements du robot n’endommage pas les capteurs.
Capteur distance Z	Capteur optique Sharp   Plage de mesure ( 20 à 150cm ) Sortie analogique Résolution : ± 1mm Tension d’alimentation : 5V   Nous avons choisi ce capteur car utilise une technologie compatible avec nôtre projet (Optique). Il dispose d’une plage de mesure assez courte, qui correspond a notre besoin, ainsi qu’une bonne résolution.
	Caractéristique de la carte :   Résolution 16 bits 16 voix analogiques/8 voix différentielles Echantillonnage 1,25 M/s   Cette carte sera intégrée dans le PXI afin de faire l’acquisition de la carte scb-68.
SCB-68	Caractéristique de l’interface de connexion :   Communication I/O16 68 broches Un capteur de température 5 Switches Compatible RSE17 / Différentiel   L’acquisition des tensions des capteurs (Z et fin de course) sera réalisée grâce à la carte d’acquisition scb-68.

Codage des différentes fonctionnalités : Sous VI

Pour réaliser les différentes fonctions, nous devrons coder un programme Labview.

J’utiliserai dans un premier temps une version antérieure (7.2, faute de licence 8.0 sur les postes de développement) pour développer mes prototypes.

Ces prototypes ont pour but de prendre en main le logiciel de codage ainsi que ses nombreuses fonctions, mais également de mieux ce représenter comment réaliser les différentes fonctions pour optimiser chaque partie de code.

Mode Manuel

Acquisition joystick

Dans cette partie, nous devrons réaliser l’acquisition des données du joystick afin de retranscrire son mouvement pour le robot. Nous ferons l’acquisition des boutons du joystick ainsi que ses 3 axes :

• Les 2 axes du manche représenteront les déplacements du robot sur les deux mêmes axes (XY).
• De l’axes Z (roulette), Qui sera utiliser pour modifier la temporisation d’envoie de trame.
• Les boutons, auxquelles nous attribuons des fonctions utiles tel que :
  • L’initialisation des axes du robot
  • Le marquage d’un point de référence
  • Un retour à l’origine
  • Fonction  d’envoie de trame manuelle.

Pour les axes : Integer : [-32768 | 32768] Pour les boutons : Bouléen : [0 | 1]

Communication RS232

Nous devrons réaliser un code permettant la communication entre le module de puissance (robot) et le pc de développement.

Pour cela, Je suis parti d’un exemple donné dans labview, pour l’adapter à nos besoins. J’ai commencé par étudier le .vi exemple fournit avec labview, afin de comprendre son fonctionnement, et ainsi de récupérer les blocs fonctionnel dont nous avons besoin.

Blocs utilisés :

Création Communication Série	Ce bloc correspond à la fonction qui va ouvrir la ligne série. On lui envoie les paramètres de communication : Parité – taille buffer – Bit de stop – bit de donnée – débit en baud On peut désormais utiliser les fonctions série – Sortie d’erreur
Envoie Série	Ce bloc permet l’envoie de caractères sur la ligne série. (Write) On spécifie la ligne série utilisée et la chaîne à envoyer. Sortie d’erreur
Réception Série	Ce bloc réceptionne les caractères de la ligne série. (Read) On lui indique la ligne série a lire et le nombre de caractère à récupérer. On obtient le(s) caractère(s) en sortie, ainsi que la sortie d’erreur.

Une fois les blocs repérés, on crée un code simplifié avec les fonctions importantes afin d’alléger le code et de faciliter l’intégration avec les autres fonctions.

Générateur de trame

Ce générateur de trame aura pour but de crée une trame de chaîne de caractère constituant une commande pour le robot. Nous réaliserons un générateur de trame suivant le modèle de la commande suivante :

DistanceX | VitesseX | DistanceY | VitesseY | DistanceZ | VitesseZ | DistanceZ2 | VitesseZ2 | Fin trame

Cette commande (@0A) correspond a un déplacement relatif du robot, c’est-à-dire qu’il ce déplace suivant les mesures souhaitées à partir du point auquel il ce trouve. Le paramètre Z2 correspond au déplacement négatif en Z, c’est-à-dire quand la tête dur robot remonte.
Ce paramètre peu être utile lorsque le robot est utilisée pour percer, ainsi on peut spécifier une vitesse de perçage différente de la vitesse de remonter de la perceuse. Cette option permet de gagner du temps lors de l’usinage. Nous n’aurons pas besoin d’exploiter cette fonction.

• Les variables DistanceX et DistanceY sont récupérées à partir de la position du manche du joystick. (On multipliera les valeurs acquises par un coefficient modifiable depuis l’interface).
• La Distance Z sera définit manuellement dans l’interface, ou sera géré en fonction de la valeur du Capteur de distance optique sur l’axe Z.
• La vitesse des axes est définit dans l’interface par l’utilisateur, elle sera la même pour tout les axes.
  • La vitesse de tous les axes (même Z2) doit être supérieure à 0, sinon la commande n’est pas validée.

On part d’une trame de base contenant la commande du robot en dur [1] pour ensuite concaténer les informations nécessaires.
Chaque séquence [2] correspond à une valeur (distance ou vitesse) convertie en chaîne de caractère puis concaténée avec la virgule qui sépare les différents champs.
On concatène ensuite les caractères CR¹⁸ (Carriage Return) et LF¹⁹ (Line Feed) pour achever la trame [3].

On obtient une chaîne de caractère correspondant à un déplacement relatif du robot qui prête à lui être envoyé.

On réalise ensuite un test.   On entre les paramètres, et on essaye de créer la trame.  On constate que la trame correspond aux paramètres choisi, la fonction est donc réalisée avec succès.

Intégration des prototypes

Une fois les 3 fonctions de base réalisée, on va fusionner les codes afin d’obtenir un programme permettant le déplacement du robot par le joystick.

On commence par faire l’acquisition du joystick, et on convertie la valeur des axes X et Y pour créer les trames. Les valeurs sont ensuite récupérer pour créer les trames avec le générateur.

On crée ensuite une condition, si on appuie sur la gâchette du joystick, on rentre dans la boucle de condition qui contient la fonction d’envoie et de réception série. Ainsi, à chaque appuie de gâchette, on envoie une trame de déplacement correspondant à la position du joystick au moment de l’appuie et on récupère ensuite la réponse du robot.

En Rouge : Les paramètres de la communication série En Jaune : Les données circulant sur la ligne En Vert : Les données du joystick En Bleu : Paramètres déplacement et info programme : PasZ : On définit la distance minimum parcourue en Z Coefficient : Modifie la distance à parcourir par rapport a la position du joystick VitesseCharly : Modifie la vitesse de déplacement du robot sur les 3 axes. Y Axis et X Axis : Position actuel du joystick (Int) • Tempo mS : Temps minimum entre chaque envoie de trame.

On test ensuite l’intégration des partie, on branche le joystick, et on essaye de déplacer le robot. Le test est un succès, le robot ce déplace suivant les instructions de l’utilisateur via le joystick.

Mode automatique

Pour réaliser la séquence d’acquisition, il faut :

• La communication avec le robot
• La séquence de déplacement

Le programme est composé en deux grandes parties exécutées successivement :

• La première partie qui consiste à initialiser la communication RS232 entre le PC et le robot et à réinitialiser les variables du programme pour recommencer un balayage.
• Dans la seconde partie, On génère les trames nécessaires pour le balayage, puis ses trames seront envoyées de façon à décrire le plan de déplacement.

Boucle séquentielle principale :

Initialisation communication série

Pour réaliser la communication, on commence par initialiser la liaison série :

• En rouge : On crée la liaison série avec le numéro de port.
• En vert : Paramètres pour la configuration de la liaison.
• En bleu : Initialisation des variables local pour la suite de la séquence.

1. On récupère les paramètres de l’utilisateur pour paramétrer la communication
   • Numéro de port – Vitesse de transmissions – Bits de données – Parité – Bits de stop – taille du buffer
2. On utilise un nœud de propriété pour modifier les paramètres (le contrôle de flot de donnée)
3. On indique la taille du buffer pour la réception.

Envoie des trames – Réalisation du balayage

Une fois la liaison établie, on peut envoyer les commandes au robot. Pour envoyer les trames, on utilisera toujours la même structure :

• Boucle séquentielle : Envoie de la trame, puis réception de la réponse du robot.

Pour communiquer sur la liaison série, on utilise les fonctions VISA : Ces blocs fonctionnels sont comparables à des drivers et permettent de réaliser des fonctions de base sur un même matériel. On commence par ouvrir une session sur le périphérique spécifié par Nom de ressource VISA (input refnum) et la fonction renvoie un identificateur de session qui sera récupérer par les différentes fonctions afin d’agir sur le même périphérique.

Le programme de déplacement est composé de 2 parties :

• Balayage de la zone (1 à 4)
• Fin de balayage et retour a l’origine (5 et 6)

L’envoie des trames réalise le déplacement ci-contre. Le principe est de répéter cette séquence jusqu’à atteindre la valeur maximal sur l’axe Y. On ajoute donc une condition à la suite de ses 4 trames : Si « DistanceActuelY = DistanceY » Faire « Envoie trame fin de séquence » Faire « Envoie trame retour origine » Sinon Recommencer la séquence

Une fois la distance maximal en Y atteinte, on considère que la séquence est terminée, il ne reste plus qu’a envoyer la dernière trame (Flèche bleu) qui finira le balayage. Cette dernière trame est la même que celle utilisé précédemment pour l’incrémentation X (Flèche noir), On reprend donc la même trame, que nous devrons envoyé le même nombre de fois, afin de décrire le même déplacement. Puis la trame de retour a l’origine du balayage, afin de recommencer l’opération.

1 – Incrémentation X 1 : C’est le nombre de fois que la trame sera envoyée : On calcul cette valeur : NbrBoucleX = DistanceX / PasX 2 : C’est le PasX définit par l’utilisateur. Il est utilisé ici pour créer la trame de déplacement. Une fois la boucle de répétition terminée, on peut en déduire qu’on a atteint la distance X maximum du balayage, on peut donc incrémenter Y.

2 – Incrémentation Y 1 : C’est le PasY définit par l’utilisateur. Il est utilisé ici pour créer la trame de déplacement. Une fois l’incrémentation Y faite, on peut recommencer le déplacement sur l’axe X mais il sera négatif afin de revenir à la position initiale (sur l’axe X).

3 – Incrémentation -X 1 : C’est le nombre de fois que la trame sera envoyée : On calcul cette valeur : NbrBoucleX = DistanceX / PasX 2 : C’est le PasX définit par l’utilisateur. Il est utilisé ici pour créer la trame de déplacement mais celle-ci doit être négative. On utilisera donc l’opposé de PasX pour créer la trame. Une fois la boucle de répétition terminée, on peut en déduire qu’on est revenu à la position X=0, on peut donc incrémenter Y.

4 – Incrémentation Y On envoie a nouveau la trame d’incrémentation de l’axeY crée précedement.

Le balayage est réalisé, il ne reste plus qu’a revenir au point d’origine de l’acquisition. On sort de la boucle de balayage et on réalise un dernier test pour envoyé la commande de retour : Le balayage est terminé (PositionY>distanceY ? = Fin) Le programme n’est pas terminé (BouclePrincipal) La flèche correspond à un test : L’envoie de la trame de retour est validé lorsque le balayage est terminer, mais pas la boucle principal. On envoie la trame de retour, et on modifie les variables afin que le programme ce termine.

L’interface du prototype : Dans un premier temps on définit les paramètres du balayage : La surface DistanceX DistanceY La résolution PasX PasY La vitesse de déplacement du robot La tempo Temps entre chaque envoie de trame Les paramètres Z ne sont pas utilisés dans ce prototype. Dans un second temps on affiche des informations utiles au déroulement du programme tel que les trames qui vont être envoyées, ou le nombre de boucle à effectuer.

Le programme est fait de telle façon que, lorsqu’on l’exécute, il réalise une séquence de déplacement avec retour à l’origine et prend fin (afin de faciliter l’intégration).

On fait ensuite un test unitaire pour de valider le déplacement du robot :
Pour ce faire, on fixe un marqueur à la place du capteur GMI, et on maintient une feuille de papier avec du scotch sur le plateau du robot. On démarre ensuite le balayage, et on vérifie si le chemin parcouru correspond à celui désiré.

On crée un graphe XY représentant le déplacement du robot On voit que les déplacements sont similaires.

Le 3eme essaie correspond bien au balayage demandé, le code est donc opérationnel, la fonction est validée.

Contrôle visuel par webcam

Pour faire l’acquisition des images de la webcam, nous avons besoins d’un logiciel de traitement vidéo.
Pour ça, on utilise le logiciel VLC media player (Gratuit). Nous utilisons la version 1.0.1 car la dernière version (1.2) est incompatible avec le contrôle activeX. L’installation de ce logicielle est précisé dans la notice d’utilisation.
La webcam est disposée sur le robot afin d’avoir un contrôle visuel sur ses déplacements.
Le flux vidéo est acquis et affiché dans l’interface utilisateur. Ce contrôle permettra de garder un œil sur les déplacements du robot pendant un balayage afin de prévenir tout
incident.
Nous aurons donc besoin d’une webcam afin de faire l’acquisition des images. Le programme d’acquisition de la webcam ce compose en 2 parties exécutées successivement :

• Initialisation du contrôle ActiveX avec VLC et lancement acquisition
• Arrêt acquisition

Acquisition du capteur Z et des capteurs fin de course

Nous avons fixé les capteurs de fin de course aux extrémités du robot ainsi que des butées réglables. Le capteur Z est amarré à la tête du robot, et pointe en direction du plateau.

Choix des composants :

On utilise des résistances (1.5Kohms) afin de fixé un faible courant :

On a donc un courant d’environ 33mA, ce qui est suffisant au fonctionnement, sans trop consommer d’énergie.
On dessine un schéma de la carte à réaliser (Le fusible n’apparaît pas, il sera a la sortie du convertisseur de tension)

On utilise un bornier faisant office d’entrée et sorties. Câblage du bornier :

On réalise ensuite la carte, et on branche les capteurs afin d’effectuer des tests unitaires.

Le test de la carte a été réalisé avec un voltmètre, Chaque tension à été testées avec succès.
Nous ferons ensuite l’acquisition de ces tensions avec la carte SCB68 pour intégrer ces informations dans le programme. Cette partie est traitée par mon binôme.

Après intégration, on réalise un test depuis labview afin de valider l’acquisition des données.

Sur le graphe de gauche : La tension du capteur Z, correspondant au lift-off. Entre 0 et 3V. Sur le graphe de droite : On a les 4 tensions des capteurs fins de courses. Ici, on appuie sur l’un des capteurs, et on peut voir que la tension bleu correspondante est à 5V.

Partie Individuelle : Travail Réalisé par GUILLEMARD Erwan

Présentation des fonctionnalités à Réaliser

Pour pouvoir réaliser le banc de test du capteur GMI (Giant Magneto Impédance), nous devons détacher les différentes fonctionnalités composant le système.
Pour ma part, je devrais développer et réaliser les fonctionnalités suivantes du banc de test :

• Acquisition du signal
• Visualisation du signal
• Configuration des paramètres
• Capteurs de position Axe Z
• Accessibilité aux données enregistrées

Acquisition du signal

Nous recherchons à déduire l’impédance dégager par le capteur CND. Pour cela, nous allons effectuer plusieurs opérations sur les deux tensions acquises. Pour cela, nous allons déduire l’image du courant à partir de la tension aux bornes de la résistance. Puis avec la tension aux bornes de la bobine, nous pourrons l’impédance du capteur GMI. Ensuite selon la fréquence d’acquisition, l’on choisira d’orienté le signal vers la carte d’acquisition 6251 (dans le cas de fréquence inférieur à 20MHz ou la carte d’acquisition 5112 (dans le cas de fréquence supérieur à 20MHz).

Visualisation du signal

Le signal une fois traité (de manière physique) doit être affiché dans un historique en fonction de ces coordonnées spatiales puis les valeurs seront affichées dans un graphique tridimensionnel.

Configuration des paramètres

L’utilisateur doit pouvoir configurer divers paramètres selon le type de pièce que le banc de test doit analyser.
Pour cela l’utilisateur doit pouvoir sélectionner le type de signal pour alimenter le capteur GMI (émetteur et récepteur) ainsi que la fréquence et la tension. L’utilisateur peut configurer les paramètres d’acquisitions de la carte d’acquisition 6251 et 5112 (Tension Max-Min, Fréquence, échantillonnage, noms voie physique d’acquisition). Il doit aussi pouvoir configurer l’emplacement de l’enregistrement des fichiers de données.
Le fichier de configuration doit être en format XML²⁰ et une copie de ce fichier doit être présente en en-tête de chaque fichier de sauvegarde au format TXT²¹.

Capteurs de position Axe Z

Pour le lift-off, il est nécessaire d’installer un capteur de type analogique sur l’axe Z du Robot 3 axes à proximité du capteur GMI.
Cependant, la première fonction de ce capteur est de permettre d’obtenir une meilleure précision pour l’acquisition du capteur GMI en contrôlant la position verticale de ce dernier par rapport à la pièce à tester.

Accessibilité aux données enregistrées

L’utilisateur doit pouvoir charger et exploiter un fichier sauvegardé antérieurement. Restituant les données t’elle que les valeurs de l’acquisition ainsi que les paramètres de configurations propre à cette acquisition.

Présentation des périphériques et instruments utilisés

PC Embarqué : NI-PXI 1042Q

Pour notre projet de développement d’un banc de test par contrôle non destructif par magnétoscopie, il est imposé par le cahier des charges que nous devons utiliser un pc embarqué de chez National Instrument « NI-PXI 1042Q ».
Pour commencer le PC embarqué est imposé par le cahier des charges. Cependant, l’on aurait pu réaliser le banc de test à partir d’un simple PC. Mais l’avantage qu’offre le PC embarqué de chez National Instrument se situe au niveau du nombre de port PXI ainsi que son port GPIB et de la liaison série (RS232) directement intégré à l’appareil. Les cartes peuvent quant à elles communiquer par le bus PXI (routage de signaux en fond de panier).

PC Embarqué

Le PC embarqué contient le système d’exploitation Windows XP SP2 et nous utilises la version de développement 8.0 de LabView. Il comporte : 2 Ports RS 232 (1 entrée / 1 sortie) 2 Ports USB 1 Port GPIB 1 Port PS2 1Port VGA 1 Port Eternet 8 Slots Disponibles dont 7 Slots PXI

Carte d’Acquisition NI-PXI 6251

Caractéristique de la carte : Résolution 16 bits 16 voix analogiques/8 voix différentielles Echantillonnage 1,25 M/s

Carte d’Acquisition NI-PXI 5412

Caractéristique de la carte : Résolution 14 bits Tension Max -6V à 6V Plage de Fréquence 0 à 20 MHz Signaux: Carre, Sinus, Triangle, Aléatoire, DC

Carte d’Acquisition NI-PXI 5112

Caractéristique de la carte : Résolution 8 bits 2 voix Bande Passante Max 100Mhz Echantillonnage 1M/s

GBF Agilent 33220A

APPLY: <fonction> [<fréquence>[,<amplitude>[,<décalage>] ]] Par exemple, l’instruction suivante émise depuis l’ordinateur commande au générateur de fournir en sortie un signal sinusoïdal de 3 Vpp avec une fréquence de 5 kHz et une tension de décalage de -2.5V. APPL:SIN 5 KHZ, 3.0 VPP, -2.5 V

Interface de Connexion : SCB-68

Capteurs

Capteur CND

Définition

Les capteurs par contrôle non destructifs (CND) sont composés de deux parties. 

Une partie émettrice qui va générer un signale qui aura pour conséquence de créer une perturbation sur la cible, la pièce que l’on souhaite contrôler.

Et une partie réceptrice qui est chargé de récupérer les perturbations émis par la cible que l’on a excitée.  C’est le signal récupéré par la partie réceptrice du capteur qui nous intéresse. 

Dans l’industrie, il existe une multitude de capteur par contrôle non destructif. Ces capteurs ce départage en plusieurs familles chacun ayant ces avantages et inconvénients et des propriétés propres.

Il y a les capteurs par ultrasons, les capteurs par micro-ondes, les capteurs par thermographies, les capteurs par radiographies, les capteurs par courants de Foucault ou capteurs par magnétoscopies que nous utilisons comme capteur de notre banc de test. 

L’avantage qu’offrent les capteurs par contrôle non destructifs est assez intéressant d’un point de vue économique et technologique.

Ces capteurs permettent la caractérisation de l’état d’une pièce, d’un matériau sans l’endommager et permet la détection de défaut comme des microfissures, imperfections etc. Ils permettent aussi de mesurer des paramètres dimensionnels et ou constitutifs comme par exemple l’épaisseur, la longueur, la largueur d’une pièce ou d’un matériau. Ou encore de pouvoir définir ces états de contraintes. De plus ces capteurs, répondent à des enjeux de sécurité, de coûts, de précision sur les mesures etc. Ce qui justifie leurs applications et leurs utilisations dans des domaines varier comme les Transports, l’Industrie, l’Energétique, le Médical, etc

Capteur GMI (Giant Magneto Impedance)

Les capteurs par contrôle non destructifs (CND) sont composés de deux parties.  Une partie émettrice qui va générer un signale qui aura pour conséquence de créer une perturbation sur la cible, la pièce que l’on souhaite contrôler. Et une partie réceptrice qui est chargé de récupérer les perturbations émis par la cible que l’on a excitée.  C’est le signal récupéré par la partie réceptrice du capteur qui nous intéresse.    Dans l’industrie, il existe une multitude de capteur par contrôle non destructif. Ces capteurs ce départage en plusieurs familles chacun ayant ces avantages et inconvénients et des propriétés propres. Il y a les capteurs par ultrasons, les capteurs par micro-ondes, les capteurs par thermographies, les capteurs par radiographies, les capteurs par courants de Foucault ou capteurs par magnétoscopies que nous utilisons comme capteur de notre banc de test.    L’avantage qu’offrent les capteurs par contrôle non destructifs est assez intéressant d’un point de vue économique et technologique. Ces capteurs permettent la caractérisation de l’état d’une pièce, d’un matériau sans l’endommager et permet la détection de défaut comme des microfissures, imperfections etc. Ils permettent aussi de mesurer des paramètres dimensionnels et ou constitutifs comme par exemple l’épaisseur, la longueur, la largueur d’une pièce ou d’un matériau. Ou encore de pouvoir définir ces états de contraintes. De plus ces capteurs, répondent à des enjeux de sécurité, de coûts, de précision sur les mesures etc. Ce qui justifie leurs applications et leurs utilisations dans des domaines varier comme les Transports, l’Industrie, l’Energétique, le Médical, etc Il est important de savoir que même en l’absence d’une cible ferromagnétique, l’on peut avoir des variations dans les valeurs de notre Impédance. Cela est dû à la réception par le capteur GMI du champ magnétique terrestre.

Capteur Axe Z

Nous devons alors choisir un capteur selon plusieurs caractéristiques :

• La plage de précision
• Le coût
• Le type de capteur
• L’interface de communication

Pour la famille de capteur, nous avons après réflexion choisit de prendre un capteur de type « optique ». La raison de se choix se fait selon la logique suivante. Nous ne pouvons pas prendre un capteur de type magnétique, car cela pourrait créer des interférences magnétiques avec notre capteur.

Nous aurions pu choisir d’utiliser un capteur de type « sonore » basé sur le principe d’écho, mais cela nous paraissait moins précis que le capteur de type optique (infrarouge).

Nous avons donc cherché un capteur correspondant au critère demandé puis avons demandé un devis auprès du constructeur.

Nous avons donc trouvé un capteur optique d’une grande précision (20 mm) sur une plage de mesure convenant à notre système. De plus l’interface de communication est en liaison série ce qui ne pose aucun problème car le PXI possède de port RS 232. Cependant, ce capteur étant très performant, son prix ne nous permet pas de le choisir du fait de la contrainte budgétaire.

Finalement, nous garderons dans notre choix le capteur fourni par la plateforme de distribution Conrad.   Bien que ce capteur soit moins performant que le capteur précédent, celui-ci reste abordable au niveau du prix. Il a une sorti de type analogique, et son interface de connexion peut être directement connecté à un PC, il ne nécessite pas d’interface de connexion pour fonctionner. Nous le connecterons par la suite à l’interface de connexion SCB-68

Codage des différentes fonctionnalités : Sous VI

Avant de commencer à coder directement l’application du banc de test du capteur, il est nécessaire développer chacune des fonctionnalités dont nous aurons besoin pour le fonctionnement de l’application. Pour cela, nous allons créer plusieurs dossiers dans notre dossier projet. Chaque dossier comportant exclusivement les codes nécessaires pour chaque fonction qui composera le logiciel notre banc de test.

Acquisition

Carte d’acquisition 6251

Cette carte de chez National Instrument va nous permettre d’acquérir directement le signal depuis l’interface de connexion SCB-68 de chez National Instrument. Nous utiliserons cette carte dans le cas où la fréquence d’acquisition est inférieure ou égale à 20 MHz.

Nous l’utiliserons aussi pour contrôler l’état des capteurs fin de course et le capteur de l’axe Z présent sur le Charly Robot 3 axes. Pour cela nous devons définir en fonction des différents capteurs les voies d’acquisition sur l’interface de connexion SCB-68 suivant le mode d’acquisition, c’est-à-dire Différentiel ou Commun (RSE) d’après les caractéristiques des capteurs.

Cette partie de code se déroule sur deux niveaux. Nous utilisons un assistant DaQmx en paramétrant les paramètres des voies d’acquisitions suivants les caractéristiques du tableau ci-dessus. Cependant nous devons laisser le choix à l’utilisateur de pouvoir modifier les paramètres d’acquisition pour le capteur GMI. Pour cela, nous allons récupérer les valeurs entrées par l’utilisateur. Ces valeurs, vont être transmises grâce à des variables partagés, à l’assistant DaqMx que nous avons modifié, donc à notre sous-VI « Carte_6251 » qui est un VI-Standard (couleur Jaune).   La différence entre un VI-Express (couleur Bleu) et un VIStandard est que l’on peut modifier les paramètres de la fonction standard, se qui n’est pas possible lors de l’utilisation de la fonction express. (Identique à la surcharge de fonction).

Donc l’acquisition se fait en fonction des paramètres contenue dans les variables partagées que nous avons définis dans le fichier projet de notre code. De cette façon, l’on peut voir les variables partagées comme un espace mémoire partagé gérer par une machine virtuelle

(service sous LabView utilisant la MVP²² : Machine à variable partagé). Lors de la communication et du passage de variable entre les VI, l’on va charger dans la variable partagé nos valeurs, puis lors de la lecture de ces valeurs, le MVP va mettre à jour la variable partagée appelée et va fournir le contenu chargé précédemment.

L’avantage de l’utilisation des variables partagées est dans la transmission de valeur entre les VI.

Dans le corps du notre VI « Carte_6251 », nous définissons le nombre de voie, ainsi que la tension d’acquisition, le mode, le nom des voies etc. Puis l’on définit la fréquence d’acquisition ainsi que le taux d’échantillonnage.  Ensuite, nous appelons diverses fonctions afin de finaliser les paramètres de l’acquisition que nous allons faire.

Plusieurs capteurs sont acquis par la carte d’acquisition NI-PXI 6251. Nous nous intéressons seulement ici au capteur GMI.  Donc une fois avoir acquis nos deux tensions, nous allons traiter les 2 signaux afin de pouvoir calculer l’Impédance. Pour cela, nous allons dans un premier temps désassembler les signaux. Le premier signal qui est désassemblé correspond à Ugmi. Le second signal correspond lui à la tension Vr(t) = R*i(t). Nous allons calculer la tension efficace du signal Ugmi grâce à la fonction « Mesures d’amplitudes et de niveau » que l’on configure pour que celui-ci applique le calcule de la moyenne Quadratique (RMS23). Ensuite, nous allons traiter la seconde voie désassemblée afin de transformer le signal Vr(t) en i(t). L’on sait que : Vr(t)=Ri(t)          i(t)=Vr(t)/R        i(t)=Vr(t)/50 Une fois avoir calculé l’intensité, nous allons calculer le courant efficace grâce à la même fonction utilisé précédemment « Mesures d’amplitudes et de niveau » pour laquelle nous choisissons la fonctionnalité calcule de moyenne Quadratique (RMS). Afin de pouvoir déterminer l’impédance, il suffit de fait le quotient de la tension efficace sur le courant efficace soit : |Zgmi|  =  Ugmieff   /   Igmieff

Carte d’acquisition 5112

Cette carte de chez National Instrument va nous permettre comme précédemment d’acquérir le signal dans le cas où la fréquence d’acquisition est quant à elle supérieur à 20MHz afin d’obtenir une meilleur précision au niveau de l’acquisition.

Cependant, il était nécessaire d’après le cahier des charges de passée avant par la carte multiplexeur 2503. Cette carte de multiplexage ayant pour but d’orienter selon la fréquence d’acquisition voulue de basculer les 2 signaux du capteur GMI vers la carte d’acquisition 6251 ou la carte d’acquisition (oscilloscope) 5112.

Malheureusement, nous ne pouvons pas utiliser ce module multiplexeur du fait qu’il n’y a qu’un seul relai que l’on puisse commander.

Donc nous ne pouvons pas sélectionner le type de carte d’acquisition. La solution que nous avons retenue est de laisser à l’utilisateur de choisir lui-même la carte qu’il souhaite utiliser pour l’acquisition.

Il reste à revoir le schéma de connexion entre le capteur et la carte oscilloscope 5112. Et là se trouve un autre problème. Car l’acquisition des signaux fournit par le capteur GMI vers la carte d’acquisition 6251 se fait en mode Différentiel. Or comme nous souhaitons faire l’acquisition sur la carte 5112 qui n’est autre qu’un oscilloscope, les masses sont reliées (entrées en mode commun ou RSE). 

Pour le moment, nous ne somme pas en possession d’une solution qui nous permet de réaliser le schéma de câblage pour effectuer cette acquisition.  Cependant, comme précédemment, nous utiliserons une fonction express de LabView « NiScope – Express » que nous allons transformer en Fonction Standard pour que l’on puisse modifier les paramètres d’acquisitions de la carte.

Alimentation du Capteur GMI

Alimentation Emetteur

GBF Agilent 33220A

Le Générateur Base Fréquence (GBF) Agilent 33220A est un Générateur qui peut être utilisé directement par un technicien de manière direct ou qui peut être commandé à distance depuis un poste fixe. La communication du générateur est basé sur le protocole GPIB dans les commandes de contrôle sont spécifié dans la documentation fournit avec l’appareil.

Donc pour commander le GBF à via la liaison GPIB, il suffira de saisir la commande suivante : APPL : Signal Frequence Tension Comme type de signal nous pouvons choisir entre : SINUS SIN CARRE SQR TRIANGLE RAMP BRUIT NOIS CONTINUE DC Pour la fréquence, il suffit d’envoyer la valeur. Par défaut, l’unité est en Hertz. Pour la tension, comme pour la fréquence, il suffit d’entrer une valeur. L’unité par défaut est VPP24.

Contrôle Port GPIB

Sous LabView, nous réalisons le code qui permet de créer la séquence qui va permettre de contrôler le type de signal, la tension et la fréquence que nous voulons obtenir en sorti du GBF.

Cependant, il faudra pour la communication spécifier l’adresse de l’appareil. A la mise sous tension de celui-ci, l’adresse de connexion est indiquée sur l’interface du GBF (Si celui-ci est connecté à un PC).

Dans un premier temps nous allons construire la séquence qui va nous permettre de prendre le contrôle du GBF. En suivant  la syntaxe fournit par la documentation technique de l’appareil (voir parti ci-dessus). Donc nous laissons  l’utilisateur  renseigner les paramètres de tension, fréquence et le type de signaux voulue. Donc nous construisons la chaine de caractère suivante en concaténant les paramètres :   APPL : « TypeSignaux »_«Fréquence »,_«Tension »   Les valeurs de Fréquence et de Tension étant de type Double, il est nécessaire de les convertir en chaine de caractère.    Attention : ‘_’ dans la syntaxe de la séquence que nous construisons est considérer comme le caractère espace.

Ensuite, nous rentrons dans une structure de type séquence. Premièrement, nous utilisons une fonction GPIB de communication propre à LabView pour se connecter au GBF Agilent. Nous définissons l’adresse de l’appareil, et nous transmettons la syntaxe que nous avons crée auparavant. Nous ajoutons un « time out » de 5 secondes dans le cas d’une incapacité au PXI de se connecter au GBF. Puis l’on récupère en sortie de cette fonction un booléen qui certifie le bonne envoie de la syntaxe à l’appareil ainsi que le bonne état de connexion. Ensuite dans la seconde partie de notre structure séquentielle, nous ajoutons une temporisation d’une seconde. Puis dans la dernière partie de notre séquentielle, nous récupérons l’acquittement en vérifiant si la syntaxe envoyé à bien été lu et interprété par le GPIB. Nous devons récupérer en cas de succès le message suivant : Et en cas d’échec, ce type de message :

Alimentation du récepteur

Carte alimentation 5412

Pour alimenter le capteur GMI, nous utilisons la carte NI-PXI 5412 qui est un Générateur Base Fréquence (GBF). Pour cela, nous avons été confrontés à un problème assez important du fait que nous ne pouvons configurer le GBF de façon continue dû a des commutations intempestifs générer par la fonction d’initialisation de la carte. Les conséquences de vouloir configurer le GBF en continue, sont que sur le long terme nous risquons d’endommager la carte d’alimentation et deuxièmement, la carte ne délivre pas de courant car elle est s’initialise en boucle.

Pour parer ce problème et permettre à l’utilisateur de pouvoir gérer l’alimentation de la carte en tant réel, nous avons ajouté un bouton qui une fois activée transmet les paramètres au Sous VI « Carte_5412 ». Nous avons essayé de faire notre propre alimentation, mais cela n’a jamais été concluant. Alors nous avons utilisé une fonction LabView NI_FGEN EXPRESS que nous avons modifié. 

L’avantage de modifier un module EXPRESS de LabView nous permet de pouvoir passer des arguments en paramètre, et donc de changer les paramètres d’alimentation. Car un VI-Expresse ne contient que des paramètres prédéfinis par l’utilisateur et ne peux être changé via la face avant de notre programme.

Un VI-EXPRESS d’origine est de facilement reconnaissable par ça couleur bleue. Une fois modifier, celui-ci peut-être renommé et doit être enregistrer comme sous-vi indépendant. Sa couleur est jaune pastel.

Le code comporte deux niveaux :   Le premier niveau permet de recueillir les données saisies par l’utilisateur depuis l’interface de la face avant. Si l’utilisateur appuie sur le bouton d’alimentation,  les paramètres sont envoyés au second niveau du programme. Le second niveau représente les fonctions de bas niveau de LabView permettant d’alimenter la carte d’alimentation NI-PXI 5412. Dans un premier temps, nous allons contrôler s’il existe des erreurs avant d’initialiser la carte. S’il existe des erreurs, un message s’affichera. Dans un second temps, nous récupérons les paramètres que nous avons transmis.  Seulement à partir de maintenant, nous allons interagir avec la carte d’alimentation. Nous allons l’initialiser, puis la mettre en état d’arrêt. Cela est nécessaire du fait que l’étape qui suit définie la fonction standard de la carte ainsi que la définition d’une impédance interne (50 ohms par défaut). Puis l’on va transmettre nos paramètres d’amplitude, fréquence et le type de signal que nous voulons avoir en sortie de notre carte.  Avant de remettre la carte sous tension, l’on va configurer les propriétés niFgen du rapport cyclique de la carte d’alimentation NI-PXI – 5412.

Capteur Optique Axe Z

Les problèmes que nous avons rencontrés sur cette fonctionnalité se trouve au niveau de la traduction de la tension que nous fourni le capteur en distance. La documentation fournit par le fournisseur ne nous donne pas d’expression mathématique pour nous permettre de faire le lien entre la tension fournie et la distance entre le capteur et la cible.

Après avoir longtemps médité sur le meilleur moyens de déterminer cette valeur, nous avons décidé de crée un tableau de valeur afin de pouvoir vérifier l’allure de la courbe fournie par le constructeur et surtout pour avoir un tableau de référence de la tension fournie par le capteur en fonction de la distance.

Nous avons donc réalisé notre table en faisant varier un carton devant le capteur avec un pas de 1cm sur une plage de 0 à 60 cm. L’acquisition des données nous a permis de confirmer la courbe fournit par le fournisseur.

Pour déterminer la position entre le capteur optique et la cible, nous avons utilisé le tableau de valeur déterminé précédemment comme valeur de référence. Ayant un tableau bidimensionnel, nous allons désassembler ce tableau 2D en deux tableaux 1D. Le premier tableau contenant les distances, le second contenant les tensions. Ainsi, nous sommes sures que l’indexation des 2 tableaux est la même. De cette façon, il suffit de comparer la valeur de la tension acquise avec les tensions contenues dans le tableau. De façon générale l’on recherche l’indexation de notre tableau via la condition :   (U Max > U Acqui) ET (U Acqui > U Min)   Soit de façon pratique :   (U(ref)[i] >U Acqui) && ((U Acqui >U (ref)[i+1] )   Si la condition n’est pas réalisée, nous continuons notre séquence qui va se répéter tant que la condition n’est pas réalisée (soit l’indice de notre tableau). Une fois la condition réalisée, l’on va extraire la plage de distance grâce à notre tableau de référence. Il suffit pour cela d’utiliser les mêmes indices qui ont validés la condition. Ensuite, nous faisons la valeur moyenne des distances maximale et minimale. Nous venons donc de déterminer la distance entre la cible et le capteur Z.

Cependant, cette manière de déterminer la distance en fonction de la tension renvoyée n’est pas aussi précise qu’elle ne pourrait l’être. Notre capteur pouvant donner une précision de l’ordre du millimètre, nous ne donnons avec cette méthode qu’une précision de l’ordre du centimètre. Pour obtenir cette précision, il aurait été nécessaire d’établir un tableau de référence avec un pas de 1mm. Chose plutôt ardu et longue.

Il nous reste maintenant à gérer l’axe Z du Charly Robot 3 axes avec la position du Capteur Optique sur ce même axe pour le mode Manuel. Pour cela, nous allons laisser à l’utilisateur de choisir de gérer l’axe via le contrôle de l’axe Z par le joystick ou par un champ de commande. Dans le cas du contrôle de l’axe Z par un champ de commande, l’utilisateur devra saisir une distance comprise entre 33cm  et 38,5cm. Il nous suffira de comparer la distance souhaitée avec la distance lue.

Plot 3D

Les résultats doivent être affichés dans un graphique tridimensionnel afin de représenter la pièce scannée. Pour cela, nous devons tracer les points de coordonnée X ; Y ; Z. Les coordonnées de l’axe X et l’axe Y correspondent au positionnement du Charly Robot 3 axes. Les coordonnées de l’axe Z correspondent aux variations du capteur GMI.

Dans ce prototypage, nous simulons les variations des valeurs en X, Y  via deux potentiomètres. Les variations de l’axe Z sont obtenus en créant un tableau 2 dimensions des variations des variables X et Y. Les valeurs simulées sont affichées dans un historique afin de pouvoir connaître les valeurs composant la surface représenté. La représentation graphique des données comporte plusieurs choix d’ergonomie. L’utilisateur peut donc modifier la mise à l’échelle automatique, l’affichage des axes ainsi qu’une mise à l’échelle manuelle. Il est aussi possible de choisir le style de courbe voulue (nuage de point,  surface pleine avec trait, etc) ainsi que le système de coordonnée souhaitée (Cartésienne, Cylindrique, Sphérique).

Fichier de Configuration XML

Les paramètres saisis par l’utilisateur doivent être sauvegardés dans un fichier portant l’extension .xml (Extensible Markup Language). La caractéristique de ce langage est basée sur l’arborescence et l’organisation des données dans le fichier. Ainsi, nous pouvons donc créer des balises personnalisées ayant pour contenu ce que nous souhaitons lui donner en guise de valeur.

Ecriture dans un fichier XML

Le problème rencontré dans cette partie, ce situe dans l’écriture des données à l’intérieur du fichier.

Car il existe plusieurs méthodes possibles pour écrire dans un fichier au format XML. 

La première méthode qui a été utilisé, était réalisable sous la version 8.0 de LabView alors que l’exemple était extrait d’une version supérieur.

Cependant, bien que la méthode soit bonne, elle ne permet pas d’exploiter le contenu du fichier. Car la méthode de lecture associée à cette écriture ne peut-être réalisée sous la version 8.0 de LabView. En conclusion la méthode d’écriture est basé sur l’exemple fournit par LabView version 8.0.

Il suffit d’aplanir les donnés d’un type en format XML. Dans notre cas, nous allons donc aplanir 18 fois des données puis  l’on va concaténer ces valeurs  et écrire ces dernières dans un fichier XML. L’on peut voir ici le résultat de l’écriture des données dans le un éditeur de texte. L’arborescence du fichier est faite de façon automatique. L’on voit que nous avons pour chaque valeur :   -Le type de donnée entre balise   -Le nom du champ   -La valeur que contient ce champ.

Lecture d’un fichier XML

Pour la lecture du fichier XML, nous devons dans la première phase renseigner le chemin où se trouve le fichier XML. Puis pour lancer la lecture, il suffit de cliquer sur le bouton « Ouvrir ». L’on utilise la fonction lire dans un fichier XML. Puis dans une boucle conditionnel, si la lecture du fichier c’est passé sans erreur nous allons extraire les valeurs correspondants aux paramètres que nous souhaitons. Sinon, dans le cas d’une erreur dans la lecture du fichier, l’on affiche qu’une erreur est survenue lors de cette action. Dans le cas d’aucune erreur, nous allons afficher le contenu du fichier dans un indicateur de façon à pouvoir vérifier la présence de tous les champs. Les données fournies par le fichier XML vont être traités ensuite dans une structure séquentielle. Au totale, la structure séquentielle comporte autant d’étape qu’il y a de valeur à extraire. La méthode que nous utilisons pour extraire ces données consiste à rechercher les valeurs contenues entre les balises en utilisant l’indexation du fichier XML. Donc dans un premier temps, nous recherchons dans les données extraites qu’elle information nous voulons en précisant son indexation. Puis l’on utilise la fonction « Redresser à partir d’un fichier XML » en indiquant le type de donnée que l’on souhaite redresser : 0 de couleur Orange pour un DOUBLE champ  vide de couleur Violet pour un string Ensuite pour facilité la transmission des données entre les Sous VI, nous assemblons ces valeurs dans un cluster indicateur. Cependant, si lors du redressement une erreur subvient, l’on affiche un message d’erreur à l’utilisateur en lui spécifiant l’origine de l’erreur.

Fichier de Sauvegarde TXT

Pour le fichier de sauvegarde. L’on va définir une structure pour le contenu de données composants le fichier. De plus, nous proposons une modification du cahier des charges en incluant dans le fichier de sauvegarde une copie de données composants le fichier XML afin que l’utilisateur puisse retrouver les paramètres choisies lors de l’acquisition effectuée par le passé.  Ainsi, nous proposons la structure suivante :

Nous proposons comme nom de fichier par défaut le modèle suivant :

Après avoir définie la structure de notre fichier TXT ainsi que son nom, nous pouvons maintenant écrire dans ce fichier et lire ce fichier.

Ecriture dans un fichier TXT

Dans un premier temps, l’on récupère la date de la machine. Puis l’on crée la chaine de caractère correspondant à notre nom du fichier sous le format « Acqui_JJ_MM_AAAA ».   Attention, à la fin de chaque ligne, nous avons les caractères « Fin de ligne et Retour à la ligne ».   Puis nous utilisons une fonction « Boite de Dialogue Fichier » pour laisser le choix à l’utilisateur de modifier l’emplacement ou va être enregistré le fichier ainsi que de modifier le nom du fichier. Puis nous utilisons une fonction « Ouvrir/créer/remplacer un fichier » dans lequel nous spécifions que nous voulons Ouvrir ou créer un nouveau fichier avec seulement les droits d’écritures. L’on rentre ensuite les paramètres de la pièce qui va définir le nombre de point d’acquisition qui va définir le nombre de ligne d’expression régulière. Nous convertissons ensuite la valeur de nombre d’acquisition en un type chaine de caractère que nous allons concaténer avec le caractère fin de ligne et retour charriot. Puis l’on utilise la fonction « Ecrire dans un fichier TXT » pour écrire la valeur du nombre d’acquisition en guise de première valeur de notre fichier.   Dans la seconde section de notre structure séquentielle, nous allons récupérer les valeurs de configurations souhaitées par l’utilisateur et convertir les valeurs de type entier ou double en type string. Puis nous allons concaténer ces valeurs en intercalant entre chaque valeur le caractère fin de ligne et retour chariot. Ce qui nous fait au total 18 valeurs donc ce qui va prendre 18 lignes au total dans notre fichier de la ligne 2 à la ligne 19. Il nous reste plus qu’à relier le contenu de la chaine créer vers une nouvelle fonction « Ecrire dans un fichier TXT » relié au même fichier.   Dans la dernière partie de notre boucle séquentielle, nous traitons et simulons l’enregistrement des valeurs acquissent d’une pièce ferromagnétique selon le modèle énoncé plus haut :   HH:MM:SS___X___Y___Val   Dans cette structure séquentielle, nous récupérons le nombre d’acquisition que nous allons réaliser et nous allons décrémenter cette valeur avant de faire entrer cette valeur dans une boucle DoWhile. La condition de fin de cette boucle est établie tant que la valeur d’itération de la boucle est supérieur ou égale au nombre d’acquisition que l’on décrémente. Dans cette boucle DoWhile, nous avons mis une temporisation de 100 ms pour avoir des valeurs différentes et pour simuler une synchronisation. L’on réalise des traitements sur l’affichage de l’horodatage de façon à formaliser l’heure est la date sur le format que nous souhaitons. Puis l’on va concaténer les valeurs HH:MM:SS avec les valeurs simulées en ajoutant entre les valeurs un caractère de tabulation et de finir la chaine avec les caractères de fin de ligne et de retour chariot. L’opération sera réalisée tant que nous n’avons pas atteint la condition de fin de boucle. Une fois être sortie de la boucle DoWhile nous mettons fin à la structure séquentielle. Nous appelons la fonction « Fermer un fichier ». Nous venons ainsi de générer notre fichier de sauvegarde d’on un exemple de contenu est visible ci-contre.

Lecture dans un fichier TXT

Pour la lecture d’un fichier d’acquisition, nous allons dans un premier temps ouvrir une boite de dialogue permettant à l’utilisateur de sélectionner le fichier qu’il souhaite consulter. Pour cela avant de rentrer dans la structure séquentielle, nous utilisons une fonction « Boite de Dialogue Fichier » pour laisser le choix à l’utilisateur de choisir quel fichier consulter. Puis nous utilisons une fonction « Ouvrir/créer/remplacer un fichier » dans lequel nous spécifions que nous voulons seulement ouvrir un fichier seulement la lecture de disponible. Ensuite nous relions cette fonction à une fonction qui va nous fournir la taille du fichier texte que l’on souhaite ouvrir. Cette fonction est indispensable pour lire un fichier. Puis l’on va utiliser la fonction « Lire dans un fichier texte » en précisant la taille du fichier. Nous récupérons en sorti de cette fonction une chaine de caractère qui contient toutes les données contenu dans notre fichier texte. Ayant accès au contenu du fichier, nous pouvons maintenant refermer le fichier texte grâce à la fonction « Fermer un fichier ».   A partir de maintenant, nous allons traiter le contenu du fichier que nous venons de lire. Dans un premier temps, nous allons lire les expressions qui ne sont de forme régulière. C’est-à-dire les 19 premières lignes qui contiennent le nombre d’acquisition ainsi que les configurations souhaitées lors de l’acquisition. Pour cela nous allons utiliser la fonction « Balayer un fichier » en indiquant le chemin du fichier et en précisant le type des données que l’on veut extraire. Dans notre cas, nous recherchons des données de type chaine de caractère. Une fois ces données extraient, nous les affichons. Seule la donnée correspondante au nombre d’acquisition est converti en entier 32 bit.   Dans la seconde partie de notre structure séquentielle, nous allons traiter les expressions régulières, soit dans notre cas les données d’acquisition. Nous allons utiliser la fonction « Chaîne au format tableur en tableau » en indiquant que nous souhaitons avoir en sorti un tableau 2 Dimensions et que notre séparateur tableur est le caractère tabulation. Ensuite, nous allons faire plusieurs opérations pour supprimer les expressions irrégulières. Pour cela nous allons supprimer les 19 premières lignes de notre tableau 2 dimensions. Ainsi, nous récupérons un tableau 2D contenant exclusivement des données : Après avoir obtenue ce tableau, nous allons décimer celui-ci de façon à obtenir 3 tableaux 1D contenant les valeurs de X, les valeurs de Y, les valeurs Val. Pour cela, nous utilisons la fonction « Sous ensemble d’un tableau » pour isoler les colonnes que l’on souhaite avoir, puis l’on va utiliser la fonction « Redimensionner un tableau » pour obtenir un tableau 1 dimension de nos valeurs. Une fois les tableaux 1D obtenue,  l’on convertie les tableaux de type string en tableau de type entier 32 bit, puis en type double.  Dans la dernière partie de notre séquence il ne reste plus alors à afficher le résultat du fichier dans un plot 3D à partir des tableaux. Seul les données de l’axe Z doivent être sous la forme d’une matrice, ou les données de l’axe Z sont exprimées en fonction des données de l’axe Y.

Intégration Individuelle

Conclusion

Pour faire un point sur cette partie individuelle, nous pouvons dire que cette dernière à été menée à environ 92% de l’objectif finale. Les phases qui ne sont pas réalisées se situent au niveau de l’intégration finale avec la partie individuelle de l’Etudiant 1 (Robin GRIVET).

Pour la fonctionnalité du Capteur Z tous a été réalisé au niveau du prototypage. Cette fonctionnalité est donc opérationnelle. Cependant, nous avons rencontré de nombreux dilemme dans la phase d’intégration intermédiaire avec la fonctionnalité Mode Manuel. Donc l’intégration à échouer, et nous ne sommes pas en mesure de réaliser le contrôle de l’axe Z du Charly robot en fonction du lift-off du capteur GMI.

L’intégration de la fonctionnalité de Sauvegarde n’est pas complète du fait que pour générer un fichier TXT, nous devons réaliser une Acquisition du capteur GMI en Mode Automatique. Or nous sommes en cours de recherche de solution pour créer la synchronisation entre ces deux fonctionnalités. Une fois la synchronisation réalisée, nous pourrons écrire le fichier de sauvegarde.

Cependant, la fonction d’écriture dans un fichier texte est bien opérationnel mais ne fonctionne quand simulant des valeurs.

Conclusion

C’est marrant de retomber sur ce projet de fin de cycle par hasard 14 ans plus tard. Avec le recul j’aurais choisi d’autres technologies 🙂 Les fautes d’orthographes sont légion et le style, parlons du style. C’est lourdingue à souhait. Mais ne faut il pas commencer quelque part ? 🙂 J’ai volontairement fait sauter les plannings car comme tout le monde le sait, les plannings sont bidons car saisie aux derniers moments et n’apporte aucune plus valu.

La nostalgie me reprend. Je revois le travail effectué avec mon binôme Robin, le temps passé chez lui et au labo. De notre machine à café qui finira par partir avec el grande Zini, café qui lorsqu’il était préparé par mes soins était tout simplement imbuvable. De l’engueulade qui nous avions pris lors de la présentation de notre projet à mi-parcours par Joël MOUTOUSSAMY, alors que pour nous notre rendu était correct. Le souvenir lors de notre soutenance du reboot le PC qui avait planté après le passage de Robin.

Ce projet m’aura rapporté la note de 14/20.

Au-delà de la note c’est à ce moment précis que j’ai compris mon projet professionnel. Je voulais m’orienter dans la R&D, rester dans le milieu industriel et devenir enseignant. Chose qui par la suite changera quelque peu 🙂

Le mot de la fin :

Vous convoitez ma banane Monsieur GRIVET ?

Un professeur à R. GRIVET durant un contrôle sur table

1. GMI : Geant Magneto-Impedant ↩︎
2. LPP : Laboratoire de Physique et Plasma ↩︎
3. ARDPI : Agence pour la Recherche et le Développement de Produits Industriels ↩︎
4. CND : Contrôle Non Destructif ↩︎
5. PXI : Extension for Instrumentation ↩︎
6. PC : Personal Computer ↩︎
7. GPIB : General Purpose Interface Bus ↩︎
8. RS232 : Recommended Standard 232 ↩︎
9. GPL : General Public License ↩︎
10. UML : Unified Modeling Language ↩︎
11. IDE : Interface de DEveloppement ↩︎
12. OS : Operating System ↩︎
13. SP2 : Service Pack 2 ↩︎
14. GBF : Générateur Base Fréquence ↩︎
15. TOR : Tout Ou Rien ↩︎
16. I/O : Input / Output ↩︎
17. RSE : Referenced Single-Ended ↩︎
18. CR : Cariage Return ↩︎
19. LF : Line Feed ↩︎
20. XML : eXtensible Markup Language ↩︎
21. TXT : Texte ↩︎
22. MVP : Machine à Variable Partagé ↩︎
23. RMS : Root Main Square ↩︎
24. VPP : Valeur Pic à Pic ↩︎

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 de quel mécanisme de sécurité vais-je aborder ?

Dans l’ère du temps, nous parlons sans cesse de PAM¹, PIM², ZTNA³, termes qui jusqu’il y a quelques années étaient obscurs et commençaient tous justes à émerger. Si aujourd’hui ces termes sont incontournables, je m’interroge à implémenter ces derniers dans un environnement OnPremise (pour ne pas dire mon environnement) en tenant compte :

• Du modèle de tiering de l’infrastructure
• De la segmentation en place des rôles et permissions
• Du durcissement de sécurité

Toutefois et encore une fois, comme le disait un ancien collègue la sécurité ce n’est pas pratique et je souhaite mettre en place une certaine souplesse à certains comptes utilisateurs bien identifiés.

Pif, PAM, Pouf, Je suis informaticien ; Pif, PAM, Pouf ça c’est vraiment trop bien !

Donc me voilà parti pour l’étude et l’implémentation d’une des fonctionnalités PAM fournit par Windows, l’appartenance temporaire à un groupe ou Temporary Group Membership (TGM⁴).

Avant-Propos

Je pars du principe que nous avons un environnement Windows avec un contrôleur ADDS⁵. Ce dernier est OnPremise est non hybride (pas de jonction avec AAD⁶).

Notre architecture se base sur la segmentation en tiering de notre SI⁷ et notre ADDS est durci selon les préconisations de l’ANSSI⁸.

L’objectif que je me fixe est donc de mettre en place la fonctionnalité d’attribution de droit d’administration temporairement à un utilisateur sans à avoir de :

• Créer un compte d’administration dédié à un usage ponctuel
• D’attribuer les droits d’administration (domaine ou local) permanent

Comme d’accoutumé (car nous ne changeons pas les bonnes vieilles habitudes) l’environnement Windows sera durci selon les bonnes pratiques et j’utiliserai mes deux contrôleurs de domaine 2025 en CORE.

Prérequis

• SE :
  • Windows Server : 2k16 et version ultérieures
• Apps :
  • ADDS
• Autres :
  • Non applicable

Théorie

Il est important de comprendre comment fonctionne et ce qu’apporte l’ajout de la fonctionnalité « Privileged Access Management Feature ».

Il est impératif et primordial que l’ensemble des serveurs AD soit au minima en version WS 2k16 et donc que le schéma de la forêt soit en version 2016.

Au vu des derniers propos énoncés, nous pouvons nous douter que nous allons altérer le schéma de notre AD. Ce qui est implicite (mais enfonçons une porte ouverte), l’installation de cette fonctionnalité sera irréversible (oui c’est une extension du schéma… La base j’en encore envie d’écrire. Oups c’est fait).

Extension du schéma Active Directory

Je juge important de savoir ce qui va être ajouté. C’est pourquoi une sous partie va être nécessaire pour regarder plus en détail la liste des nouveaux objets et attributs.

La liste n’est pas longue. Toutefois il convient de rappeler que « ce n’est pas le nombre d’objet qui fait la force » mais leur usage.

Et avec tous les points, quand est-il des risques ? Oh quasi rien (#MDR)

Risques

Structurels

L’un des premiers risques seraient lors du déploiement de la fonctionnalité. Il est important de bien prendre en compte le côté irréversible de l’opération. Je recommanderai de vérifier en amont l’état de santé des DCs et de la topologie souhaitée. L’objectif étant de ne pas se coltiner une dette technique des familles à la suite d’une mauvaise conception.

Délégations

Attention à la délégation sur notre container (CN=Shadow Principal Configuration). Si ces derniers sont trop larges un type comme Waldo peut se définir Admin du Domain en créant un ShadowPrincipal. Et hop ! Une escalade invisible…

Sécurités

Continuons de parler d’escalade (perso, moi c’est le bloc jusqu’à ce que je ni**e deux ménisques), le risque d’une escalade furtive et temporaire…

Les mécanismes PAM octroyant des droits temporaires, l’usage d’un compte admin temporaire serait peu visibles dans les journaux d’audit et sont souvent peu, voire mal surveillés. Ainsi, un attaquant peut devenir Admin du Domain pour 1 heure réaliser une opération de type DCsync plus la création d’une backdoor et ce je la jouer à la David Copperfield…

Une attaque directe par ShadowPrincipals à travers un compte compromis ayant les droits PAM. De cette manière, notre Charlie ou Waldo peut créer un ShadowPrincipal ajoutant un TTL à un groupe d’administration (Tiers 0) sans à avoir besoin de modifier directement le groupe. Cette méthode permettrait de contourner un grand nombre de mécanisme de sécurité en place.

L’attaque par SID, le classique des classiques. Comme vu précédemment, l’attribut msDS-ShadowPrincipalSid accepte des SID internes et externes (dans le cas de forêt approuvé). Ainsi, une mauvaise gestion des relations d’approbations ou la compromission d’une forêt externe donnerait automatiquement un accès privilégié au SI local.

Opérationnels

La perte d’un accès administrateur qui aurait été délégué sur une mauvaise évaluation de la durée du TTL pourrait être lourd de conséquence. Risque de ne plus être administrateur durant une opération critique nécessitant les droits d’administrations par exemple et donc de se retrouver totalement bloqué.

Une complexité trop élevée peut également relever d’un frein. Cela peut rendre les débogages longs et fastidieux (un peu comme ma b**e… Très très drôle M’sieur…) ainsi que des comportements inattendus. La pire chose possible reste la mauvaise formation des équipes et le risque d’erreurs fréquentes par les équipes de Niveau 0 ou 1.

Gouvernances et Humains

De la mauvaise formation des équipes relèvent souvent de processus non définis ou totalement ignoré. Ainsi il ne serait pas rare d’assigner des TTLs trop longs dans le temps pour avoir la paix (qu’est-ce que la sécurité peut être pénible) ou de définir des TTLs trop courts et d’enchainer les élévations temporaires.

Se pose alors la question de « Mais à quoi sert le PAM finalement ? »

L’excès de confiance et son mauvais usage peut entrainer un faux sentiment de sécurité. Le PAM a été implémenté, nous ne risquons rien. Sauf que les comptes d’administrations ne sont pas protégés correctement et dans le cas de compromission d’un poste admin… Je ne fais pas de dessin hein ?

Audits et Conformités

Comme inscrit précédemment, les journaux d’évènements sont assez difficiles à identifier et à corréler dans le cadre d’attribution temporaire des droits. Ainsi, l’expiration d’un TTL n’est pas un évènement clair pour l’audit. Ce qui peut facilement limiter l’analyse et le diagnostic de la part des équipes.

C’est pourquoi il va être nécessaire de porter une vigilance particulière sur les événements suivants :

Event ID	Description / Rôles / Types
4728	Ajout à un groupe global
4732	Ajout à un groupe local
4756	Ajout à un groupe universel
4729	Expiration ou Suppression à un groupe global
4733	Expiration ou Suppression à un groupe local
4757	Expiration ou Suppression à un groupe universel
5137	Création d’un objet
5136	Modification d’un objet
5141	Suppression d’un objet
4672	Attribution de privilège élevés
4624	Logon d’un compte ayant des droits d’administration
4634	Logoff d’un compte ayant des droits d’administration
4648	Logon explicite d’un compte ayant des droits d’administration
4662	Accès d’objets AD sensibles
4719	Modification audit policy
1102	Effacement des journaux
4768/4769	Kerberos (corrélation des TTLs)

A cela s’ajoute les diverses solutions du marché qui viennent auditer la santé des SIs et notamment celui des AD. Ces derniers ne prennent pas en compte l’attribut member;TTL et ShadowPrincipal. Les SIEMs¹⁴ valant paroles d’évangiles pour les SOCs¹⁵, hop ni une ni deux l’informations passent à la trappe.

Recommandations

Les objectifs sont de pouvoir garantir AUCUN accès administrateur permanent afin d’obtenir une élévation temporaire, traçable et approuvée (je reviendrai sur ces points dans la partie pratique). Tout cela afin de contenir et maitrisé en cas de compromission l’impact ainsi que la surface d’exposition.

Il est également primordial de comprendre que l’usage du PAM au sens windows du terme ne doit servir que pour :

• Admin du Domaine
• Administrateur de l’entreprise
• Administrateur du schéma
• Administrateurs DC¹⁶
• Autres (Comptes ADCS¹⁷, ADFS¹⁸, AAD Connect)

L’usage pour du helpdesk ou pour des serveurs applicatifs doit être proscrit. Ce qui est logique car il revient à Services Informatiques d’arbitrer sur les demandes utilisateurs. Néanmoins, pour octroyer des droits d’administrateur à un stagiaire ou prestataire ça fonctionne très bien mais encore une fois sous réserve DE certains mécanismes.

Cela passe donc par plusieurs axes.

Architecture

Il est important de noter qu’avant toutes choses, les serveurs en Tiers 0 ne doivent pas avoir accès à internet en dehors des URLs approuvés (et c’est non négociable) et ne doivent contenir QUE les logicielles d’architecture et de sécurité (donc vous me virez vos salop***ies de NinjaRMM, LogMeIn, TeamViewer et compagnie).

• URLs des serveurs antivirus (genre TrendMicro etc)
• URLs des serveurs de mises à jour Microsoft

Il va de soi qu’étant en Tiers 0, le réseau est isolé et filtré en entrée et sortie. Il n’y a pas d’administration direct depuis une ressources de Tiers 1 ou 2.

Ci-contre, la topologie comme cette dernière devrait l’être avec MIM et PAM. Le fait d’intercaler un server MIM-PAM entre notre ADDS et nos postes clients permettent d’user comme dit précédemment des mécanismes d’approbations de workflow et d’automatisation. Le serveur PAM doit être vu comme un bastion dans un réseau isolé de niveau T0.

La mise place d’une telle architecture va être relativement complexe pour moi au vu des ressources disponibles niveau homelab. Je vais donc me passer du serveur intermédiaire MIM PAM.

Cette topologie est compatible et valide bien qui moins recommandée quant aux risques accrus relatif à l’audit et d’un contrôle moins efficace. Cela nous demandera donc en contrepartie d’être irréprochable sur les groupes, droits et permissions lié à la délégation. Il sera nécessaire d’avoir un regard et contrôle réguliers des scripts Powershell.

Donc me concernant je resterai sur mon modèle en place de tiering T0-T1-T2 avec segmentation et contrôle des flux.

Comptes & IDs

Cela me semble logique, mais important de le répéter il ne faut en aucun cas user d’authentification interactif et de ne pas utiliser de compte administrateur. Et cherry on the cake, les comptes sont TOUJOURS nominatifs (oui même pour vous les éditeurs).

Ainsi, pas de compte admin permanent. 🙂

Néanmoins, il est important d’avoir des comptes brises-glaces afin de ne pas se couper l’herbe sous le pied. Dans la logique il en faudrait minimum deux et selon l’ANSSI maximum deux (Décidemment la sécurité c’est borderline). Naturellement ces comptes doivent être utilisés en cas d’extrême urgence et lors de leurs usages une alerte doit être notifiée.

Ce qu’il faut comprendre avec PAM, nous ne mettons pas tous nos œufs dans le même panier.

Nomenclatures des groupes

Après ce qui a été dit dans le volet ci-haut, il est nécessaire de définir des GGS¹⁹ propres au PAM et d’ajouter ces derniers en tant que membre des groupes adéquates.

Ainsi pour ma part j’userai de la nomenclature suivante :

GGS_PAM_NOM_Elevation

Simple et efficace.

Durée de vie

Crucial dilemme de la définition de la durée de l’élévation de droit temporaire… Dans la logique une intervention standard est de 30 à 60 minutes en cas de crise nous pourrions définir 120 minutes maximum. Toute durée supérieure à 2 heures et donc interdit.

Oui mais voilà, je dois faire une opération sensible en tant que SysAdmin sur un SI sur la journée comment je fais ?

Excellente question à laquelle je répondrai, nous sommes SysAdmin et donc nous avons l’accréditation pour intervenir sur notre SI. Donc je n’utiliserai pas PAM mais le système classique de mon compte utilisateur avec élévation de droit avec mon compte administrateur délégué ou super administrateur.

Mon presta doit faire une montée de version de la solution applicative sur l’un de nos serveurs pour la journée soit 7 heures de boulot. Comment tu réponds à ça Monsieur jesaistout ?

J’ai pour habitude de ne jamais laissé un prestataire intervenir seul sur mon SI ou un SI sous ma responsabilité. Donc je passe ma journée à surveiller d’un coin de l’œil ces actions. Et dans son cas, je me note de renouveler personnellement toutes les deux heures ça durée de vie. Généralement il n’y a pas trop besoin car le prestataire est administrateur local du serveur mais certaines fois il est nécessaire de lui octroyer les droits d’administrations du domaine (et ça, ça fait froid dans le dos et en dit long sur la topologie de la solution applicative…).

En complément, il en va de soi mais la tacite reconduction des renouvellements des TTLs et à bannir et encore une fois pas de TTL trop long par ne pas être emme**é toutes les deux minutes.

Bien je pense qu’avec tout ça nous en savons assez pour passer à la pratique non ?

Pratique

Installation

Commençons par vérifier le niveau fonctionnel de notre forêt. Nous retrouvons la commande qui devient normalement un automatisme maintenant 🙂

> Get-ADForest

La preuve à l’appui, ci-contre la preuve que pour l’attribut ForestMode la valeur Windows2016Forest est présente. Donc les prérequis sont atteints. Néanmoins, je recommande un petit contrôle de santé de l’AD par précaution et actions avant de poursuivre.

Vérifions maintenant si la fonctionnalité est déjà présente ou non sur notre SI.

> Get-ADOptionalFeature -Filter "name -eq 'Privileged Access Management Feature'"

Si la valeur de l’attribut EnabledScopes est vide, la fonctionnalité n’est pas déployée sur le système. Sinon ba elle l’est déjà. Evident Cap’taine Obvious !

Activons alors cette fonctionnalité.

/!\Attention : C’est à ce moment que l’opération devient irréversible. Et deuxième point de vigilance il faut que nous soyons administrateur du schéma temporairement

> Enable-ADOptionalFeature 'Privileged Access Management Feature' -Scope ForestOrConfigurationSet -Target ronelab.lan

Il suffira de valider le déploiement en activant la touche T pour oui pour tout. Et quelques secondes plus tard, c’est terminé. Oui tous ces mots pour ça… Il faut bien faire durer le plaisir non ? <3

Si nous voulons vraiment valider le bon déploiement de notre fonctionnalité, nous pouvons rappeler la seconde commande ci-haut pour vérifier les paramètres d’activation de notre scope.

Nous constatons donc que cette dernière n’est plus vide ou $null. Nous pourrions également aller nous balader dans la configuration de notre AD pour trouver notre container.

Place à l’assignation temporaire des droits 🙂

Attribution temporaire

Bhin alors comment qui font qu’on fait pour assigner des droits temporaires ?

De la manière la plus simple du monde gazier, même si au passage il faudrait parler un langage au minima courant plutôt que familier.

Pour se faire, un compte admin et un accès à l’un de nos DCs en powershell (où au DC en lui même). Je proscris volontairement les RSATs. Pourquoi ? Parce qu’un DC doit être le plus isolé possible.

# Définir notre TTL en secondes en tant que variable de type Timespan
> $ttl=New-TimeSpan -Hours 1 -Minutes 15
# Ajouter notre utilisateur temporairement au groupe
> Add-ADGroupMember -Identity "GGS_PAM_AdminDomain_Elevation" -Members "john.doe" -MemberTimeToLive $ttl

Et c’est tout. Je vous l’avais dit, rien de bien difficile. Un peu de RTFM et de ligne de commande… Ce qui est intéressant c’est de s’attarder sur les événements de sécurité. Nous retrouvons avec exactitude ce que nous avons énoncé dans la partie théorie concernant le périmètre d’audit.

Ouai mais alors comment vérifier que notre utilisateur à bien des droits qui court dans le temps ?

Vérifications et Analyses

Soyons un peu curieux et penchons nous dans les attributs de notre objets utilisateurs, groupe d’élévation (auquel appartient notre utilisateur) et notre groupe final.

No Surprise ! Il n’y a rien !

Etonnant non ? 🙂 J’ai été surpris et j’ai donc reparcouru la documentation en long, large diagonale… Pourquoi pouvons nous obtenir l’information en powershell (oups j’ai divulgâché la suite) et pas en GUI ?

C’est là que c’est malin. La durée de vie se trouve sur le lien entre l’objet utilisateur et le groupe d’appartenance (rien sur le groupe cible ce qui est logique).

> Get-ADGroup -Filter * -Properties members -ShowMemberTimeToLive | Where-Object {$_.members -match "TTL*"}

Et donc côté Kerberos qu’est ce qui se passe ? La documentation en parle et nous invite à être vigilant sur ces événements (4768 et 4769). Naturellement comme tout ajout à un groupe, il est nécessaire de fermer et d’ouvrir de nouveau la session pour prendre en compte le changement.

#Dans le contexte de l'utilisateur
> klist

Nous pouvons donc constater (modulo mon temps d’ouverture de session) que notre TGT20 à une durée de 1h11 / 1h15. Ce qui correspond à la durée définit dans notre délégation. Une fois le temps imparti passé, le ticket sera renouvelé et donc les droits temporaires d’administrations retirés.

Et alors côté journaux d’événements qu’elles sont les nouvelles ma sœur Anne (#BARBEBLEU) ?

J’ai envie de dire il suffit de parcourir les journaux d’évènement de sécurité.

Bon par contre ne nous cachons pas c’est un peu pénible pour ne pas dire casse-cou***e de taper les requêtes powershell. Il faut définir le TTL, connaitre les SAMs des utilisateurs, connaitre les groupes. Bref, source d’erreur à gogo. Alors à votre avis en tant que fainéant qu’ais je bien pu faire ? 🙂

Applications

Oui, cela peut paraitre étrange, mais j’ai réalisé une application GRAPHIQUE. Un jour à marquer dans les calendriers FOR SURE d’une bière blanche !

J’ai commencé à faire l’outil en PS CLI, mais j’ai vite trouvé que cela n’était pas ergonomique. Alors je me suis demandé pourquoi ne pas réaliser une application en VB.NET ? Flemme monstrueuse. Puis pourquoi pas reprendre une frustration passé du GUI en powershell ?

Hé bien voilà, que je réouvre une vieille blessure et alors quel pied put**n ! Je me suis éclaté.

Bon il reste quelques points à améliorer :

• Multitâche pour retourner les valeurs de l’AD
• Ajouter des petites icones sympas
• Ajouter un petit About (j’ai droit à mes droits d’auteur)
• Publier l’application en certifiant cette dernière
• Quelques contrôles d’erreurs ? :p

Bref pas mal de petite chose mais rien de bien méchant.

Démonstration

Rien de telle qu’une petite démonstration en images successives pour comprendre, aussi appelé vidéo.

Github

Miaou

Conclusion

Je mettais attaqué à ce morceau en ne pensant à la base ne pas y consacrer autant de temps. Je me suis rendu compte une nouvelle fois que ce sont les choses les plus simples qui requiert davantage de recul et de réflexion.

Je lutte encore entre les bonnes pratiques et recommandations contre mon usage et le périmètre d’applicabilité. Dans un certaine mesure PAM, PAM, PAM je me mettrai bien une cartouche pour ne pas avoir connu plus tôt cette fonctionnalité. Bref, il est nécessaire d’étudier avec sérieux son implémentation et son usage.

Je n’ai volontairement pas abordé le système de délégation des droits AD et sur les GPOs. Mais cela reste un impondérable car tout va reposer sur cette base. Ouvrir d’un côté pour mieux fermer de l’autre, dilemme cornélien que la sécurité. Et honnêtement si j’avais traité ce point, l’article serait insoutenable (comme la poitrine de PAMELA dans Alerte à Malibu ; Franchement tu devais la faire celle-là espèce de 90tard, tu ne pouvais pas t’en empêcher ?).

Je suis conscient qu’il reste des axes d’améliorations (notamment sur le code). Toutefois, je pense que si suite il doit y avoir cela plus sur PIM ce qui ouvrira la voie vers l’environnement Azure.

Le mot de la fin :

Si je PAM sur PAMELLA ? J’offre un CADEAU en infogérance ? Malheureusement vous ne pouvez pas Jean-Pat il y a une « couille dehors » en diagonale. Vous retournez en case magouille. Un partout PAM au centre…

Erwan GUILLEMARD

Sources

• Microsoft : Fonctionnalités WS 2k16
• Microsoft : PAM
• Microsoft : Class ShadowPrincipal
• Microsoft : Class Container ShadowPrincipal

1. PAM : Privilege Access Manager ↩︎
2. PIM : Privilege Identity Manager ↩︎
3. ZTNA : Zero Trust Network Access ↩︎
4. TGM : Temporary Group Membership ↩︎
5. ADDS : Active Directory Domain Service ↩︎
6. AAD : Azure Active Directory ↩︎
7. SI : Système d’Information ↩︎
8. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
9. SID : Security IDentifier ↩︎
10. AD : Active Directory ↩︎
11. TTL : TimeToLive ↩︎
12. MIM : Microsoft Inditity Manager ↩︎
13. PIM : Privileged Identity Manager ↩︎
14. SIEM : Security Information Event Management ↩︎
15. SOC : Security Operation Center ↩︎
16. DC : Domain Controler ↩︎
17. ADCS : Active Directory Certificates Services ↩︎
18. ADFS : Active Directory Federation Services ↩︎
19. GGS : Groupe Global de Sécurité ↩︎
20. TGT : Ticket Granting Ticket ↩︎

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

Plus sérieusement et sans détour, il se trouve que ce sont les choses les plus simples dans la vie qui sont le plus souvent bâclées ou négligées. C’est pourquoi je me suis dit, et si je m’attardais un peu plus sur les politiques de mots de passe dans un environnement WINDOWS ?

Il relève de nombreux articles déjà sur le net qui traite ce sujet, mais voyez-vous encore une fois je pense aller un peu plus loin que les excellents articles déjà présents. Difficile de parler de ce que j’ai fait sans toutefois présenter les bases 🙂

Mais alors jusqu’où es-tu allé cette fois ci ?

Je suis parti de la politique classique de définition de la politique de mot de passe dans un domaine AD¹ et du traitement des événements de verrouillage de compte. Sujet traité par mon précédent mentor et qui m’a demandé un peu de recherche pour arriver à mes fins (je voulais faire ma propre solution, comprendre et maitriser le sujet).

Bref, cela sera je le pense un petit billet avec du script, des schémas et naturellement du powershell avec une pointe de désinvolture et assurément de sécurité.

Avant-Propos

Comme rédigé légèrement plus tôt, je n’ai pas la volonté de faire un article détaillé qui reprend la majorité des articles déjà présent sur le NET. Il me faut néanmoins une base de départ.

Mon mentor, dans le cadre d’une esquisse de PSSI² il y a un certain nombre d’année c’est dit qu’il serait bien d’informer l’équipe du SI interne (ou externalisé) d’un potentiel blocage, verrouillage de compte sur un AD. La première question que nous pourrions nous poser serait d’abord quel cas pourrait entrainer un verrouillage d’un compte ?

• Un dysfonctionnement de la couche 8 du modèle OSI³ :
  • Je suis méchant avec cette couche, je sais bien. Nous parlons ici (ou plutôt je parle car cela n’engage que ma responsabilité ET ma personne) du dysfonctionnement entre le siège du bureau et le clavier. Soit en un mot et un seul ? L’utilisateur bien sûr !! Mais qu’est ce que ce mec est condescendant… C’est affligeant. Généralement, le verrouillage de compte est généré par une erreur de frape lors de la saisie et dans certains cas (compte non nominatif utilisé par plusieurs collaborateurs) de la saisie d’un mauvais mot de passe.
• Une tentative de Charlie qui veut « poutrer » le compte de Bob pour récupérer le cœur d’Alice
  • On comprend assez aisément le brute force d’un intru pour s’infiltrer dans le SI⁴ est tout casser…
• Un dysfonctionnement de la couche 7 du modèle OSI :
  • Oui celle-là existe officiellement et concerne la couche applicative :). Je ne peux pas non plus raconter des conneries en permanence tout de même. Pour faire simple une application a des informations qui ne sont pas à jour (un client de messagerie qui pete un plomb par exemple).

Donc l’intérêt de notifier l’équipe interne ? S’assurer que notre utilisateur ne veut pas s’octroyer une pause-café supplémentaire ou que nous avons un petit malin dans la place qui veut nous faire passer nos prochains jours à la première place de l’enfer dans le plus beau des pandémoniums <3

Mon côté brun ténébreux qui ressort avec les vilains corbeaux de Sir Alan Edgar Poe… Alors comment faire pour déceler un verrouillage de compte et comment notifier les équipes ? Spoiler ? La suite dans les parties ci-dessous.

Prérequis

• SE : 
  • Windows Server 2k16 et version ultérieures
• Apps : 
  • Rôle ADDS
• Autres :
  • PowerShell version 5 et supérieure
  • SMTP
  • Domaine AD

Théorie

Avant de commencer, posons nous la question de comment fonctionne l’authentification dans poste dans une domaine (pour faire simple, nous restons dans une forêt avec un seul domaine).

Authentification, comment ça marche ?

En tous lieux, je dirai avec des chaussures… Ok, je sors…

Nous pourrions résumer le cycle de vie de l’authentification en 7 étapes (encore la magie du nombre 7…) l’authentification d’un utilisateur.

1. Saisie des identifiants login et mot de passe
   • Rien de bien sorcier, CONTOSO\John.Doe et mon superpassword (si tenter que le mot de passe soit bien celui attendu dans l’AD pour l’utilisateur John DOE…
2. Localisation du DC via DNS
   • Notre poste va alors à travers l’enregistrement DNS⁵ _ldap._tcp.dc._msdcs.contoso.x pour trouver un DC⁶ disponible
3. Négociation, KERBEROS ou NTLM ?
   • Deux mots protocoles qui peuvent faire peur. Je ne rentre pas dans le détail des deux protocoles. Gardons à l’esprit toutefois que KERBEROS est supérieur au protocole NTLM⁷ (d’ailleurs KERBEROS est utilisé comme protocole par défaut).
   • Cas de KERBEROS, le poste demande un TGT⁸ auprès du KDC⁹ du DC à travers une requête. Si le couple d’authentification saisie est correct le KDC retournera en réponse le TGT chiffré ainsi qu’une clé de session. Le poste à travers le TGT va demander un TGS¹⁰ afin d’accéder aux différentes ressources du SI (fichiers, imprimantes etc…).
   • Cas de NTLM, le poste va réaliser un challenge au DC en attendant une réponse.
4. Validation du compte
   • Une fois la négociation réussi (Où est-ce qu’il a appris à négocier ?), le DC va vérifier le mot de passe haché, le compte doit être actif (soit pas verrouillé, expiré ou désactivé), récupérer les groupes de sécurité de l’utilisateur ainsi que les stratégies de connexion et de mot de passe.
   • C’est marrant, c’est cette étape qui nous intéresse 🙂
5. Chargement du profil
   • Si la vérification du compte utilisateur est ok, alors c’est réussi. HIGH FIVE ! Le poste va alors charger le profil local ou selon la configuration un profil itinérant. Dans le pire des cas, un profil temporaire.
6. Application des GPO
   • Dans la logique, ensuite sont téléchargées et appliquées les GPO¹¹ utilisateurs, ordinateurs…
7. Ouverture de session
   • Hé nous voilà normalement sur notre bureau.

Bon j’avoue que la partie négociation, j’avais dit que je ne rentrerai pas dans le détail. J’effleure la technicité et croyez moi, nous pourrions aller beaucoup plus loin. Toutefois, demander à vos Admins Systèmes et Réseaux ou Techniciens Systèmes et Réseaux, je ne suis pas certains qu’ils vous expliquent clairement le cycle de vie d’authentification d’un utilisateur…

Stratégie de mot de passe

Avant de rentrer plus dans le détail de ce qui nous intéresse, il est important de parler de la stratégie de mot de passe. Cela s’est plutôt bien démocratisé car nous retrouvons sur la grande majorité des sites web à ce jour le traditionnel message :

Votre mot de passe doit répondre aux critères minimaux ci-dessous :

• 16 caractères minimum
• 1 Majuscule
• 1 Minuscule
• 1 caractère numérique
• 1 caractère spécifique

Je vous vois déjà hurler, ou vos utilisateurs vous ont gueulé dessus… Quant à la politique mis en place. Mais alors que devons nous appliquer et à qui ? L’objectif est de sécuriser les SIs sans pour autant être un vrai tyran avec ces utilisateurs. Gardons toujours à l’esprit que « Trop de sécurité tue la sécurité ». A quoi bon exiger 26 caractères pour retrouver le mot de passe sur un post-it ou AZERTY123456AZERTY123456azerty123456azerty123456$…

Pour cela, j’aime me référer à l’ANSSI¹² comme ça je peux dire haut et fort, « C’est pas moi, c’est eux qui veulent. » 🙂 Je suis courageux n’est ce pas ? 🙂

Dans le guide de Recommandation relatives à l’authentification multi-facteurs et aux mots de passe, il est recommandé d’appliquer la politique de mot de passe suivante (R20):

• Catégorie des mots de passe
• Longueur des mots de passe (Entre 9 et 11, c’est faible. Entre 12 et 14 c’est moyen. Au-delà de 15 c’est fort)
• Règles de complexité des mots de passe (le nombre de caractère utilisable)
• Délais d’expiration des mots de passe (la fréquence de renouvellement)
• Mécanisme de limitation d’essais d’authentification
• Mécanisme de contrôle de la robustesse des mots de passe
• Méthode de conservation des mots de passe
• Méthode de recouvrement d’accès en cas de perte ou de vol des mots de passe
• Mise à disposition d’un coffre-fort de mot de passe

Dans notre cas, seuls les points en vert nous intéressent. Pour définir techniquement notre GPO ou notre FGPP.

D’où tu dis que je suis un FDP ?! Gros Tarba va ! Je vais….

STOP ! En aucun cas je vous insulte ! FGPP¹³ ou Fine Grained Password Policy permettent de manière plus simple de définir plusieurs politiques de mots de passe dans une organisation selon les services et criticité de ces derniers. Croyez-moi, c’est bien plus simple que la gestion par GPO. Ca nous le verrons rapidement dans la pratique quant au déploiement.

Dans tous les cas, j’aime définir la stratégie de mot de passe « par défaut » dans la GPO (vous pouvez me jeter des petits cailloux au visage et du sable dans les yeux), Default Domain Policy : HERESIE ! BLASPHEME ! AU BUCHET ! (Oui ba c’est bien la seule chose que je modifie dans la Default Domain Policy) :

J’ouvre un aparté, dans le cas d’un poste hors domaine que nous souhaiterions durcir, il suffira de faire de même. Il faut que je pose la question de scripter cela. Aparté fermée.

J’ai donc une politique de mots de passe qui s’appliquent (sans verrouillage de compte) par défaut pour l’ensemble des utilisateurs de mon parc, de mon domaine. Néanmoins, je vais définir par FGPP une politique par groupe utilisateur.

Dans ma logique, je choisie de faire trois politiques par défaut en respectant le tiering d’administration des comptes utilisateurs.

Administrateur du domaine > Utilisateurs avec pouvoir > Utilisateur du domaine

La puissance des FGPPs résident dans la possibilité de définir une pondération sur chaque politique. Ainsi, un utilisateur peut se retrouver avec une ou plusieurs politiques liées. Les politiques ne pouvant se cumuler, la politique avec la pondération la plus forte sera minoritaire par rapport à une politique avec une pondération plus faible.

« Unbelievable » diraient nos voisins outre-manche ! Nous retrouvons les mêmes paramètres que dans notre GPO… A noter et point important, la FGPP vaut sur la GPO si cette dernière est lié à un utilisateur ou un groupe d’utilisateur.

Authentification & events

Pour bien comprendre le fonctionnement de l’authentification, nous avons vu ci-haut que tout se passe sur nos DCs. Comme le système n’est pas trop mal foutu (et qu’accessoirement l’authentification à un système relève de la plus grande criticité) tout est consigné dans les journaux d’événements de sécurité.

Elle est pas belle la vie ?

Alors la question est la suivante, qu’elle est ou plutôt qu’elles sont les événements qui nous sont important ? Microsoft est vraiment sympa car ils ont pour nous référencier les événements à surveiller…

Mon cœur cogne un truc esthétique ! Vous voyez tout ce qu’il est possible de faire en termes de sécurité et de suivi, gestion du SI ? Limite ça me fait ba**er. Je vais soumettre l’ID d’un nouveau projet au comité qui vie dans ma cafetière.

Dans notre cas, précis il y a deux événements qui nous intéressent :

• 4624 : Hérité des événements 528 et 540, je cite « L’ouverture de session d’un compte s’est correctement déroulée. »
• 4740 : Hérité de l’événements 644, je cite « Un compte d’utilisateur a été verrouillé. »

Il est important de comprendre dans l’annexe que la notion de criticité est celle qui remonte dans les journaux d’événements. Personnellement certains événements pourraient être revu à la hausse. Enfin, c’est mon opinion personnelle qui n’a de crédit que pour le type qui écrit ces mots…

C’est donc dans le déclenchement de l’évent 4740 que nous trouverons notre bonheur.

Approche

La question est comment récupérer l’information que le compte d’un utilisateur ou compte de service est verrouillé ?

Consultation des objets

Dans un premier temps, j’ai pensé à scruter l’état de chaque objet utilisateur ou ordinateur de l’AD sur un intervalle définis dans le temps.

Le professeur rend les copies, et c’est un 4/20 qui tombe… L’idée peut paraitre bien, mais c’est mauvais. Oui je vais avoir l’information des comptes verrouillés, mais cela n’est pas du tout optimisé, cela va charger pour rien le serveur et générer des lenteurs et niveau proactivité c’est un zéro pointé. Imaginons si nous étions sur un SI avec genre 2k d’objets dans l’AD ?

Consultation des évènements déclenchés

La seconde approche consiste à définir une tache planifiée qui se déclenche sur un événement déclenché. Je l’ai fait il y a peu pour contourner un dysfonctionnement non patché de MS, donc c’est faisable. Mais je n’aime pas cette méthode car elle ouvre une vieille blessure intellectuelle… Ce traumatisme tout bête me dite vous ? Comment retourner et transmettre un paramètre de l’événement déclenché dans un script powershell…

Je peux vous dire qu’en 2015 je me suis torturé l’esprit à un point ou écouter du Evanescence en slip le soir de la Saint Valentin avec un kebab douteux et de l’alcool frelaté relève du plaisir (passe encore pour le kebab et l’alcool m’enfin).

Dix ans après, je rempile sur cette problématique et spoiler je trouve la solution. Comme quoi, un informaticien c’est comme un bon vin. Plus on le garde plus c’est bon. Enfin tout dépend de l’organisation. Oups pardon, je voulais dire la cave 🙂

Vous l’aurez compris ça sera la seconde méthode qui sera utilisé. Nous retournerons alors les attributs suivants :

• Le nom du compte qui lock
• Le nom de l’ordinateur, équipement source qui a cherché à s’authentifier
• Le nom de domaine

Là où j’ai merdé, ce que j’ai choisi de prendre en temps le temps de déclenchement du script et non le temps de lock de l’event. Ce qui du coup dans une configuration spécifique fausse complétement les informations. Donc il doit y avoir une adaptation de ma part sur la première version du code…

Sécurité

Nous sommes dans le domaine ? Nous allons réaliser une tâche planifiée ? Alors la réponse elle est vite répondu mon copaing ! Nous passerons par un compte de service managé, oui un gMSA¹⁴ comme d’habitude (et dire que je ne jugeais que par les comptes de services restreint avant…).

Les droits seront mis sur le script ainsi que l’ensemble des dépendances des utilisateurs externes. Sur le répertoire en somme ? Oui c’est ça…

Structure

S’agissant d’un petit projet, je me suis demandé si je devais ou non découper ce billet en différent sous article. Au final, je ne pense pas. Il y a eu plus indigeste que ça par le passé 🙂

Topographie – Applicative

Nous retrouvons donc l’architecture classique de mes projets précédents (Etonnant non ?) 🙂

A la racine du répertoire, nous retrouvons cette fois ci UN fichier exécutable (au lieu de DEUX) :

• SS_044_WIN_AD_LOCKACCOUNT_1.0.0_Services.ps1 : Fichier pensé pour fonctionner uniquement en mode service. Il ne peut être exécuté si et seulement si un event 4740 est levé. A voir si je fais un mode debug ou pas.

La suite se déroule en 3 répertoires distincts.

• Modules : Répertoire contenant les modules powershell développé pour l’application. Aujourd’hui au nombre de deux dissociant la partie Windows Système et HTML.
• Log : Répertoire qui va contenir la ou les traces d’exécution du code si l’option est activée. Cela à son importance car il permet au petit gars qui à dev l’application dans sa cave de corriger les bugs. Le fichier ne prend pas de place et est réinitialisé à chaque lancement.
• Config : Répertoire contenant le fichier de configuration powershell. Je reviendrai plus en détail sur le contenu de ce fichier dans la partie Pratique. Contrairement aux projets DreamNebula et GreenRay, je n’ai pas développé la fonction de reconstruction, régénération du fichier de configuration. Inutile car il n’y a pas de mode manuel et il n’y a pas grand-chose dans le fichier de conf…

Topographie – Logiciel

Je me passe par fénéantise la topographie du logiciel. Il n’est pas complexe du tout… Pour faire simple, cela se résume au cycle de vie suivant :

• 0 : Entrez dans le journal d’événement de sécurité d’un événement 4740.
• 1 : Déclenchement de la tâche planifiée sur l’événement. Récupération des informations liées au verrouillage du compte utilisateur, le poste source et le domaine d’application. Ces valeurs de type strings sont passés en argument du script powershell qui est exécuté SS_044_WIN_AD_LOCKACCOUNT_1.0.0_Services.ps1.
• 2 : Le script lit la configuration, puis charge les modules. Une fois les modules chargés, le corps du mail est construit et ce dernier est envoyé par mail. Naturellement et selon les options activées, le mode debug redirigeras l’ensemble des transactions powershell dans le fichier de log dans le répertoire du même nom.

Et le code ? Il est sur GitHub. Je ne souhaite pas le présenter. Toutefois, je partagerai volontiers ces derniers avec celui qui viendra m’en exprimer le souhait. Ca sera l’occasion de papoter un peu 🙂

Pratique

Configuration

Avant de lancer le script, il est nécessaire de faire un tour vers le fichier de configuration contenu dans le répertoire config à la racine du projet. Je vais prendre le temps de décrire chacune des parties de ce fichier.

Le fichier se découpe en 1 partie et 1 sous-partie.

* Une sous-partie globale qui définit les paramètres du script et de son fonctionnement * Une sous-partie concernant l’envoie de notification SMTP15, futur feature/bug (rayer la mention inutile) à venir

Avec la compréhension du fichier de configuration, je pense que nous pouvons passer à la suite, soit déployer l’application sur le serveur.

Installation

Je passe alégrement la partie gMSA il y a un certain nombre d’article sur le net (comme déjà dit dans des billets précédents) qui traite déjà du sujet. Pour le reste, j’ai comme d’habitude renforcé la sécurité et implémenté mes propres mécanismes (la preuve en est, j’ai passé deux put**n d’heures à trouver pourquoi ma tâche ne se lançait pas…).

Là où ça se corse, c’est au niveau de la tache planifiée. Si vous êtes sur un environnement possédant l’expérience utilisateur, vous êtes sauvés. En revanche, dans mon cas sur mes serveurs CORE, je l’ai mais alors bien profond dans la cucurbitacée… Voyez vous comme quoi une chose tout insignifiante soit il peut devenir un vrai casse-tête.

Mais alors qu’elle est cette petite chose insignifiante ?

The ScheduledTask

A première vue, vous vous demandez pourquoi je parle de la tache planifiée… Il s’avère que dans la version WINDOWS Core, nous ne pouvons pas créer de tache planifiée sur un déclenchement d’événement.

En réalité, nous pouvons constater également le dysfonctionnement sur un environnement WINDOWS avec expérience utilisateur. Il suffit d’utiliser la console powershell (il suffit de revenir aux bases du RTFM¹⁶).

Donc comment faire une tache planifiée, si :

• Nous n’avons pas d’interface graphique
• Les commandes powershell ne fonctionne pas
• Les moyens de contournement comme WAC¹⁷ ne fonctionne pas (normale co**ard c’est du powershell derrière)
• La console mmc.exe en remote pas plus de chance

J’ai essayé l’exécutable schtasks mais je ne suis pas arrivé à mes fins. Vous vous voulez la vérité ? J’ai lu qu’il fallait faire une fichier XML et ajouté les champs blablablabla… Je me suis dit « No Way » je vais encore me foirer dans une balise ou je vais avoir un problème d’encodage sur des caractères à la mord moi le noeud…

J’ai donc pensé à un autre moyen (tu as surtout épluché le net et les divers forum technet oui…). Pourquoi ne pas créer la tache sur mon poste avec des paramètres que je modifierai une fois importé ? Et bien ça voyez vous, ça fonctionne.

La création de la tâche ne pose pas de problème. Je joins toutefois la petite capture pour la configuration des critères de déclenchement de l’évent.

Une fois la tache créée, exportons là et ouvrons cette dernière dans un éditeur de texte.

Oh mais dit donc, ça ne serait pas ? Hé si le voilà notre fichier XML que l’on devait construire via la commande svctasks. Et dire qu’une tache planifiée ça ressemble à ça. Vous noterez que j’ai occulté deux parties. La première partie permet de récupérer les valeurs de l’événement. Il sera nécessaire de modifier manuellement le fichier XML. Mais je reviendrai plus en détails sur ce point dans la sous partie à venir (c’est ça ma frustration décennale !). La seconde partie permet de passer les variables que contiennent les valeurs récupérées ci haut en paramètre de notre script.

Bien. Maintenant importons la tâche 🙂

> $myTask = Get-Content "PATH_WHERE_XML_FILE\myTask.xml" | Out-String
> Register-ScheduledTask -XML $myTask -TaskName "PROD_EVENT_4740" -TaskPath "\_ronelab"

Récupérer les valeurs

Comme écrit plus haut, ce point va mettre fin à une frustration longue de 10 ans. Comment retourner les valeurs levées dans un event depuis l’exécution d’une tâche planifiée…

Là j’ai lu un nombre important de documentation pour comprendre comment cela fonctionne et comment mettre en œuvre la chose surtout. Toujours dans la démarche des 3S¹⁸.

Dans les approches :

• Quel est la structure, schéma du fichier XML d’une tache planifié : Lien
• Quel est la structure la plus adapté pour un eventTrigger de type complexe : Lien
• Un exemple d’implémentation : Lien

Avec la plus grande sincérité du monde, je n’avais pas il y a 10 ans de cela la maturité intellectuelle pour assimiler cette notion. Aujourd’hui je rougis de l’imbécile que je suis et de la simplicité et évidence de son mécanisme.

Maintenant que j’ai compris (mais que je n’ai pas expliqué 🙂 Il faut bien que vous vous investissiez aussi non ? Passons à la compréhension d’un événement. Il faudra sélectionner un évent 4740 et se rendre dans la vue Detail en Friendly, mais nous pouvons aussi se la jouer XML.

Nous notons deux catégories que nous pouvons déployer :

• System : Va contenir l’ensemble des balises et valeurs propres au déclenchement de la tâche avec les propriétés de l’évent. Comme dit plus tôt, l’un des attributs qui pourrait nous intéresser est le temps où l’évent a été inscrit dans le journal. Je prenais le temps de lancement du script, mais ce dernier n’est pas la bonne source de temps. Bref, il convient alors de noter le chemin de l’attribut qui nous intéresse :
  • Event/System/TimeCreated/@SystemTime

Il est important de noter que tout part de notre événement d’où le Event en début de path. Puis le chemin /System/TimeCreated/ jusqu’à la variable qui contient notre valeur spécifiée par le @ devant SystemTime

• EventData : Va contenir l’ensemble des balises et valeurs propres à l’évènement de sécurité déclenché. Ce qui nous intéresse ce sont les attributs TargetUserName qui contient le login utilisé et verrouillé, TargetDomainName qui contient le nom de poste cible où la connexion a tenté d’être initier et le SubjectDomainName qui contient le nom de domaine cible du compte verrouillé. Soit alors les les chemins suivants :
  • Event/EventData/Data/@[Name= »TargetDomainName »]
  • Event/EventData/Data/@[Name= »SubjectDomainName »]
  • Event/EventData/Data/@[Name= »TargetUserName »]

Alors comment intégrer proprement dans notre fichier XML correspondant à notre tache planifier nos 4 paths pour récupérer les valeurs ?

Normalement, nous avons eu toutes les informations ci-haut pour réaliser l’opération 🙂

Nous avons défini nos variables qui contiennent nos données. Il suffit alors de passer nos variables en arguments de notre script. Je passe une nouvelle fois mon tour. Le passage de variable en arguments d’un script powershell c’est un basique. La modification peut être réalisé en graphique dans le TaskScheduler ou directement dans le fichier XML.

Maintenant, il ne reste plus qu’à réimporter la tache de nouveau puis de réaliser un test.

Reporting

Pour le test, rien de plus facile… J’ai choisie d’initier une connexion à l’une des ressources des domaines à partir d’un compte pour lequel la FGPP est active : * RONEALB\erwan.guillemard Depuis une instance de bureau à distance, je décide de mettre en application ma plus belle couche 8 en saisissant 5 fois mon mot de passe de manière erroné. Windows m’informe que mon compte a été verrouillé à la suite de plusieurs tentatives d’authentifications infructueuses. Quelques minutes après, je reçois le mail ci-contre.

En regardant en détail, j’ai bien les informations qui m’informe que le compte erwan.guillemard a été verrouillé à la suite d’une plusieurs tentatives de connexions depuis la machine EGWKS-RDB01 le 26/09/2025 à 20:31:40 sur le domaine RONELAB.

Toutefois et si je regarde avec précision le déclenchement de la tâche, j’ai 7 minutes de retard dans le temps affiché dans mon mail et la date d’entrée dans le journal de sécurité. Ce retard s’explique par une mauvaise prise en compte de la valeur DateTime. Je pensais que la valeur Datetime du script serait définis lors du lancement du script à la détection de l’événement. Cependant, mon SI étant très ancien, la tache met une bonne dizaine de minutes (en grossissant le trait) à se lancer. Ainsi je génère un delta ce qui n’est pas super en termes de sécurité. Il faudrait donc que je récupère la valeur DateTime présente dans l’événement.

Conclusion

Je suis content d’avoir réinventé mon propre système de notification sur le verrouillage d’un compte utilisateur dans un domaine à partir de la problématique qu’avait il y a maintenant plusieurs années un ancien collègue. Ainsi, j’ai pu combler une problématique vieille de 10 ans en relation avec les événements et les taches planifiées (dans mon projet de mémoire sur la supervision Shinken).

J’ai également constaté que les modules développés dans les projets précédents m’ont fait gagner un temps monstrueux. Cela me permet donc de me dire et de m’auto-confirmer que premièrement je ne fais pas que de la merde, secondement qu’à partir de maintenant je vais prendre un chemin différent quant à l’ensemble des problématiques qui nécessite un dev en powershell.

Le plus difficile restera je le pense de toujours garder une vision claire et qui réponde au 3S.

Si je devais être efficient, je reprendrais mes bouts de code existant concernant la création de ticket dans la solution ITSM de COMBODO (ITOP) pour générer un ticket en criticité haute pour le verrouillage d’un compte. De cette manière, le centre de service ou les équipes locales (internalisées ou externalisées) pourraient être proactives quant à tous comportements succès en relation avec l’authentification et l’accès à des ressources. Ce qui pourrait alors se résumer selon notre bon vieux William Shakespear par « Le plaisir d’un travail en guérit la peine ».

J’ai encore une fois repris une idée. Je pense qu’il serait temps que je reprenne un peu de temps pour innover. Certes, comprendre et mettre en pratique les idées de mes paires et une bonne chose mais je pense qu’il est souhaitable de vivre pleinement une nouvelle fois cette satisfaction personnelle. Mon ultime rature se limitera à « Est ce que cela valait ce billet ?« .

Je vous laisse jugez de tout ça et prendre contact si vous voulez le bout de code 🙂

Le mot de la fin :

Vous êtes surqualifié pour le poste ? Que neni, j’aime les salsifis et je sens vaguement le chou. Je vous embauche et Toper Harley reste dans la boucle. Merci, j’ai les films de programmateurs.

Erwan GUILLEMARD

Sources

• ANSSI : Guide d’authentification multi facteur et mots de passe
• WINDOWS : Authentification & Identification
• WINDOWS : Evénements à surveiller
• WINDOWS : Type Complexe EventType
• WINDOWS : KERBEROS
• WINDOWS : Svctasks
• WINDOWS : New-ScheduledTask
• WINDOWS : Register-ScheduledTask
• WINDOWS : Event & Queries

1. AD : Active Directory ↩︎
2. PSSI : Politique de Sécurité des Systèmes d’Informations ↩︎
3. OSI : Open Systems Interconnection ↩︎
4. SI : Système d’Informations ↩︎
5. DNS : Domain Name Service ↩︎
6. DC : Domain Controller ↩︎
7. NTLM : NT Lan Manager ↩︎
8. TGT : Ticket Granting Ticket ↩︎
9. KDC : Key Distribution Center ↩︎
10. TGS : Ticket Granting Server ↩︎
11. GPO : Group Policy Object ↩︎
12. ANSSI : Agence Nationale de Sécurité des Systèmes Informatiques ↩︎
13. FGPP : Fine Grained Password Policy ↩︎
14. gMSA : Group Managed Service Account ↩︎
15. SMTP : Simple Mail Transfert Protocol ↩︎
16. RTFM : Read The F*cking Manual ↩︎
17. WAC : Windows Admin Center ↩︎
18. 3S : Simple, Standard, Sécurisé ↩︎

Comme dit précédemment pour GreenRay, il s’agit là d’un Readme dans un format différent du traditionnel fichier txt et du wiki.

Prérequis

Dernier point avant de taper dans le fond du sujet, le déploiement ne se fait que dans un environnement WINDOWS (Workstation ou Server) ayant au minimum la version Powershell 5 d’installer et qui prend en charge les communication TLS¹ en version 1.2 minimum.

Bien que pas j’ai automatisé un bon nombre d’installation de dépendances certaines restent tout de même à déployer manuellement. Toutefois, les outils à déployer manuellement concernent la partie exploitation de la donnée qui peuvent et doivent être dissocier de la partie serveur.

Naturellement et bien que cela coule de source, LES PRIVILEGES ADMINISTRATEURS sont nécessaire au premier usage pour l’installation des dépendances (logique non ?).

Back End

Les prérequis sont les suivants :

• Module powershell PSSQLite : Ce dernier est déployé automatiquement par l’application. Toutefois, il est possible d’installer cette dernière manuellement.
• Module powershell PowerCLI VMWare : J’ai à ce jour une version alpha du déploiement automatique du module. Toutefois ce dernier n’est pas intégré dans le projet Dream Nebula, mais dans un projet à part SS_042_VMWareInstalled-PowerCLI. Il sera donc nécessaire de déployer ce dernier manuellement.

> Get-InstalledModule | Where-Object {$_.Name -eq "PSSQLite" -or $_.Name -like "VMWare.*"}

> Find-Module -Name "VMWare.PowerCLI"
> Install-Module -Name "VMWare.PowerCLI"

Front End

Sur le serveur ou poste qui servira à exploiter les données il sera nécessaire d’installer les dépendances suivantes :

• Drivers ODBC² for SQLite3
• Microsoft PowerBI (si powerBI utilisé)
• DB³ Browser for SQLite (en option mais pratique pour débugger ou altérer des données dans les tables)

L’installation des divers composants ne représente aucun point bloquant. J’ajoute en fin de ce billet les sources pour télécharger les différents composants. Pour vraiment prendre la main de chacun le processus d’installation est disponible ci-dessous.

Configuration

Avant de lancer le script, il est nécessaire de faire un tour vers le fichier de configuration contenu dans le répertoire config à la racine du projet. Je vais prendre le temps de décrire chacune des parties de ce fichier.

Le fichier se découpe en 1 partie et 5 sous-parties.

* Une sous-partie globale qui définit les paramètres du script et de son fonctionnement * Une sous-partie dédiée à la VCSA4 permettant d’établir la connexion à l’API5. * Une sous-partie dédiée à l’export des données au format CSV, reliquat de la version 1 LEGACY * Une sous-partie concernant l’envoie de notification SMTP6, futur feature/bug (rayer la mention inutile) à venir * Une sous-partie dédiée à la base de données SQLite. Faut bien stocker les données quelques parts * Une sous-partie concernant le paramétrage du mode service en tant que tâche planifiée

Après cette longue énumération rébarbative, regardons en détail chacune des parties et sous-parties. Bandant n’est il pas ? J’avoue que je ne fais pas ch**r du tout car mes deux applications ont le même tronc, socle, base… Vous voyez quoi ? 🙂

J’ai ajouté dans la solution la possibilité d’éditer le fichier directement depuis l’interface console. Par sécurité, j’ai ajouté une fonctionnalité de régénération automatique du fichier en cas de suppression ou de corruption. Hé oui, j’en ai eu marre de me repalucher le fichier de configuration plusieurs fois à la mano…

Avec la compréhension du fichier de configuration, je pense que nous pouvons passer à la suite, soit déployer l’application sur le serveur.

Installation

Comme toujours, je dédie une disque et volume pour mon application, 5Go suffit amplement.

Les raisons sont toujours les mêmes et cela reste un point immuable de mon caractère professionnel. Il est impératif de dissocier le système d’exploitation des applications ou data pour se prémunir de toutes anomalies du système et d’un dépassement d’espace de stockage. Nous générons des logs et nous avons une base de données foutre bleu ! (Pourquoi bleu… Personne n’a jamais su m’expliquer…).

l suffit de déposer le répertoire à la racine du lecteur D:\ ou d’ailleurs puis de définir les paramètres du fichier de configuration. Et puis c’est tout. 🙂

Lancer le script SS_43_1.0.0_VMWare-PowerCLI.ps1 pour réaliser les opérations d’initialisation et vérification des dépendances. On me chuchote dans l’oreillette qu’il faut faire un clic droit Exécuter avec Powershell (en tant Administrateur).

Attention : Seule la première initialisation nécessite les droits d’administrations.

Lors de la première initialisation EN MODE MANUEL (MAIN), les credentials de connexion vous seront demandés dans le contexte de votre machine et de VOTRE session pour générer le fichier CLIXML.

Dans la première image, nous constatons la présence de 4 menu.

• [01] Edit Configuration : Permet d’ouvrir le fichier de configuration et de modifier ce dernier.
• [02] Restore Default Settings : Permet de lancer un rappel max ou le sort de magie blanche Vie Max / Vie 2 sur le fichier de configuration pour ressusciter, régénérer celui-ci face au spell UTLIMA que vous avez lancé sur ce pauvre fichier !
• [03] Reload Configuration : Permet de recharger le fichier de configuration et l’ensemble des variables de l’application.
• [04] VCSA Establish Session : Permet d’ouvrir la connexion à l’appliance VMWare à partir des éléments transmis plus tôt.

Si la connexion aboutie, vous devriez voir apparaitre ce même menu avec d’autres options complémentaires.

• [05] VCSA Close Session : Permet de terminer la session en cours.
• [06] Add VCSA Role (CSV File) : Permet de créer le rôle VMWAre avec les bonnes permissions pour l’appliance. Entre nous, je l’ai fait une fois et l’automatiser et bien… c’est chiant… C’est pourquoi, je dois revoir le fonctionnement. Aujourd’hui il est plus simple de le faire manuellement. M’enfin c’est comme ça.
• [07] Single Node Summary : Permet de faire l’inventaire et l’affichage des ressources d’une single node VMWare dans la console. Je reviendrai sur ce point plus tard. 🙂 Un peu de suspense pardi.
• [08] Cluster Node Summary : La même chose que précédemment mais pour une cluster VMWare avec plusieurs nodes 🙂
• [09] VMWare Inventory : Génère les rapports au format HTML. Je présenterai rapidement la chose, mais de mon point de vue, remplacer par les rapports PowerBI.
• [10] Send Bill Report : Envoi les données par mail pour une potentielle refacturation.

Naturellement, si le mode DEBUG est activé et que la redirection des sorties dans un fichier de log également, nous devons avoir en amont les entrées ci-dessous.

Concernant le mode Service, le fonctionnement et partiellement le même sans les fonctionnalités manuelles. En gros et pour faire simple, cela suit simplement le cycle de vie :

• Je vérifie les prérequis pour l’application
• Je m’authentifie à l’appliance
• J’exécute mes requetes
• Je récupère les données et les stocks dans la BDD
• Je me casse Whiskas

Donc normalement notre tache planifiée est là. Je passe encore une fois mon tour sur l’usage et la création du compte gMSA.

A ce stade, nous avons donc installé l’ensemble des modules (VMware et PSSQLite), déployé la tache planifiée avec le mode service, généré notre BDD et réalisé notre première extraction.

Comme pour GreenRay dans le cas de possible erreur, je rédigerai une quatrième partie KB.

Et maintenant si nous regardions le rendu ?

Exploitation des données, Reporting

Je pense aborder cette partie en 3 axes. Une vue de la console CLI, la vue HTML bien que j’hésite encore sur son sort (Vivre ou laisser mourrir ?) et pour terminer la partie Microsoft PowerBI.

Mais avant toutes choses, ayant passé un peu moins de 300 heures sur le projet, je vous fournit le modèle de liaison de données (MLD) de ma BDD lié à PBI.

Je ne suis pas satisfait de ma BDD. Il manque un élément crucial. Bien qu’implémenté dans le projet GreenRay, je ne l’ai pas fait ici. Oui, il n’y a pas de log. Ca, voyez vous c’est moche… Aussi moche que Robert HUE au congrès du MEDEF…

Après bien que ce soit SS_043, il est la première graine, la première application vis à vis de SS_034. D’où je crois cet oubli, absence, négligence ou fénéantise de ma part sur la BDD. Pardon SS_043…

CLI View

Comme vu ci-haut, j’ai voulu permettre d’un simple petit coup de powershell d’afficher la synthèse VMware d’un node. Sans pour avoir à jongler d’un onglet à l’autre dans l’interface web ESXi ou VCSA.

C’est juste du one shot. Toutefois, je ne pourrais pas montrer de vu CLI d’un cluster. Je vous garantit toutefois qu’il est fonctionnel. Néanmoins, je ne peux partager les données.

Bref, si nous appuyons sur [07] Single Node Summary nous afficherions dans notre console une synthèse de notre hote, l’usage CPU, RAM ainsi que l’ensemble de la consommation du stockage de chaque datastore. Par amusement, j’ai même refait l’association des VMNic avec les vSwitchs et les groupes de ports… (Drôle de loisir…). A la base, je voulais savoir si lors d’ajout de ressource je pouvais ou non ajouter une ressource virtuelle sans tomber dans le piège de surallocation.

La différence avec la vue cluster ? J’affiche les informations et configurations de HA et DRS. Toutefois, je dois revoir la configuration réseau. L’affichage ne prends pas en compte pour l’instant les DVS¹¹.

HTLM Report

Je partais dans l’idée, dans une entreprise de faire dans un petit serveur web un push des données pour que toutes personnes puissent consulter les données. Voilà pourquoi j’ai généré des fichiers HTML simple qui reprend les informations CLI vu plus haut en ajoutant une vue par bulle/client.

Pour cela il faudra se rendre dans le sous répertorie export :

Cela ouvrira de facto lors de l’ouverture du fichier main.html votre navigateur par défaut. L’ensemble du site est navigable (oui je me suis fait iech avec les liens hypertextes. En plus ils sont dynamiques selon les données recueillis par l’application. J’ai fait un effort !).

Nous retrouvons donc la partie infrastructure avec les informations d’inventaire du système puis selon l’infrastructure matérielle une synthèse d’une infrastructure mononode ou en cluster. Ensuite et par bulle, nous avons une synthèse dans l’état actuel des ressources consommés. Pour la suite, je serai malheureusement contraint d’anonymiser certaines données.

Attention : J’ai fait chacune des pages web à la main en mode Notepad++ et ISE. Alors s’il vous plait soyez indulgent.

Il reste encore du boulot, j’ai trouvé ça fun et rigolo à développer. M’enfin c’est juste ma spécialité (le gars modeste…). Ma spécialité c’est de réinventer la roue 🙂

PowerBI Report

Là, contrairement aux deux modèles de reporting ci-haut vise un tout autre dimension. Car là nous allons pouvoir élargir notre vision dans le temps en affichant et travaillant sur un historique des ressources.

En des mots plus simple, l’évolution sur 13 mois glissant des ressources. 🙂

Ouvrer le fichier présent dans le répertoire Report.

Une fois ouvert, changer la source de données. Sinon vous allez avoir une erreur ODBC. Naturellement les drivers ODBC pour SQLite ont été installé préalablement sinon c’est la mort assurée…

Paramétrage de la source

Depuis l’application PowerBI, Fichier > Options et paramètres > Paramètres de la source de données.

Changer la source existence

S’affiche à vous la configuration où charger les données. Il y a de forte chance que vous vous retrouviez avec l’un de mes Paths. Changer alors le chemin pour pointer vers votre BDD.

Dans la nouvelle fenêtre qui apparait, en premier lieu sélectionner en source de données SQLite3 Datasource. Modifier le chemin afin que celui soit de la forme database=<path>.

En guise de clause de réduction de ligne, choisissez LIMIT, puis confirmer la modification.

Chargement des données

Il ne reste alors qu’à charger, actualiser les données dans le rapport existant.

Normalement et il y a peu de chance que ce ne soit pas le cas, vous devriez avoir une multitude de coche vert en face de chaque table vous annonçant que les données ont été chargé avec succès.

Une fois les données actualisées, vous devriez avoir le rendu ci-dessous par défaut. Il vous faudra alors jouer avec les différents filtres et objets de contrôles sur les pages pour coller à vos données.

Rappelons nous notre problématique initiale. Je dis nous, mais au final c’est bien à moi de me rappeler ma problématique. Je pense que cette dernière est répondue avec un peu plus de fonctionnalité que prévu.

Ainsi, nous avons une visibilité totale sur l’ensemble du SI et des éléments virtuels qui le composent. Nous pouvons également donner la tendance et l’évolution dans le temps justifiant à la demande interne ou externe d’un potentiel sur ou sous facturation. Elle permet également dans l’application de la bonne licence Microsoft O365 de publier le modèle et donc de partager l’information à d’autres collaborateurs en temps réel.

Certains filtres restent toutefois à adapter selon ce que nous souhaitons afficher ou interpréter. Pour le reste, je vous laisse regarder les différents chevaux de mon carrousel ci-haut.

Comme pour l’article précédent, je pense faire une vidéo de démonstration (que je n’ai pas fait pour l’instant d’ailleurs. Non pas par fénéantise. Mais par épuisement moral. Il faut que je pense à Rosetta, à ressources humaines… Bref, je suis content de ce que j’ai rendu et accouché. Toutefois, il reste encore un peu d’ajustement. Dommage que cela ne puisse être utilisé au quotidien dans ma profession et ce pour des sujets de droit à la propriété intellectuelle.

A ce moment précis de mon second break, il se passe huit mois entre le début des première ligne de code et la fin de rédaction de cet article. Il me fallait terminer ce projet qui je le pense ne doit pas finir aux oubliettes. J’aimerai qu’il puisse à terme rendre service à d’autres SysAdmins et s’adapter à d’autres systèmes, socles de virtualisation.

Sources

• Microsoft PowerBI
• SQLite ODBC Driver
• DB Browser SQLite
• VMWare PowerCLI

1. TLS : Transport Layer Security ↩︎
2. ODBC : Open Database Connectivity ↩︎
3. DB : Database ↩︎
4. VCSA : VMware System Appliance ↩︎
5. API : Application Programming Interface ↩︎
6. SMTP : Simple Mail Transport Protocol ↩︎
7. LD : Liste Distribuée ↩︎
8. BAL : Boite aux lettres ↩︎
9. FQDN : Fully Qualified Domain Name ↩︎
10. gMSA : Group Managed Service Accounts ↩︎
11. DVS : Distributed Virtuals Switchs ↩︎

Des outils qui permettent de réaliser un suivie de la charge d’une infrastructure il en existe un certain nombre. J’ai donc ce besoin de suivre mon SI¹ et de définir de manière simple pour l’instant un planning de capacité de mon environnement VMWare qu’il soit basé sur une architecture standalone ou distribuée.

Toutefois, ce qui est emmerdant encore et toujours c’est le cout lié à ces solutions. Logique, car cela demande un certain recul et analyse et d’être flexible aux diverses solutions des éditeurs de virtualisation. Coucou VEEAMOne 🙂 Il existe aussi des solutions gratuites mais cela nécessite de manipuler ensuite les données retournées. Oui je pense à toi mon bon vieux RVTools.

De mon expérience d’administrateur système et réseau, j’ai constaté (comme je me suis fait avoir d’ailleurs) un manque crucial des équipes à tenir comptes des ressources matériels de leurs infrastructures. Que ce soient des jeunes loups qui viennent d’entrer sur le marché du travail ou de certains vieux loups charlot qui opère encore dans le milieu… C’est ainsi que les problématiques de surallocation des ressources voient le jour :

• Memory Balloning
• Storage Overprovisionned
• Storage Latency
• CPU Exhausted
• etc

Dans la grande majorité des cas, un suivi fin de l’exploitation permet d’éviter ce genre de cas de figure et dans d’autres cas de prévenir sa direction ou son client d’une évolution d’infrastructure à budgéter. L’une de mes bonnes pratiques (surtout celle que mes mentors m’ont transmises) et de prendre le SI de production et de prendre 20% de plus pour se prémunir des potentiels changements à venir et garder de l’évolutivité.

L’extraction des indicateurs de performance du SI permettra ainsi sur le plan technique de s’assurer de la charge et allocation de chacune des ressources matérielles et de définir l’allocation des ressources par services au plus bas niveau. Sur le plan financier et administratif cela permet de prévoir les investissements du SI tout comme il permet de refacturer en interne différents services. Derniers points qui peut-être marque d’espièglerie, la DSI² ou Direction peut se rendre compte des conseils et des compétences du RSI³.

Dans le contexte d’un petit fournisseur de service (je ne parle pas des OVH, AWS et autres mastodontes), il est difficile de facturer les ressources aux clients de la manière la plus juste possible sans tomber dans le cas de surfacturation ou sou facturation. Ces indicateurs permettent donc de justifier le cout et l’évolution des ressources mis à leurs dispositions sur leurs demandes.

Il est donc nécessaire de trouver une solution qui permet d’assurer un suivie de l’infrastructure sur une durée défini qui puisse être orienté MSP⁴ comme pour un client final. D’assurer une visibilité macroscopique jusqu’au plus bas niveau des ressources. Tout comme pour l’article précédent GreenRay, il est important de décorréler la partie métrique et son rendu. Le service qualité doit pouvoir exploiter et présenter les métriques dans la plus grande transparence et honnêteté qu’il soit. (Surtout c’est le boulot de la qualité de rendre sexy un truc qui de base ne l’est pas trop, sauf pour les AdminSys dans mon genre 🙂 ).

Cahier des Charges

Ok, on voit où l’on veut aller. Pensons maintenant à partir de ce qui est établi comment mettre en œuvre tout ça sans tomber dans l’éternelle piège de la dispersion et donc de ne voir aboutir ce projet. Encore une fois, mon esprit aura fait des siennes et le projet au final va comporter des fonctionnalités encore en cours de développement… Oui je suis comme ça et je ne compte pas changer dans le cadre de mes loisirs.

Nous resterons dans un premier temps sur le socle de virtualisation VMware (et ce même si BROADCOM est passé par là avec son chéquier) et les produits vSphere de base (comprendre VCSA et ESXi) et donc son API⁵. (Donnez moi le moyen de faire cela pour les socles de virtualisation PROXMOX, AHV et HyperV, JE VOUS SUIS !).

Je souhaite également utiliser la solution VEEAMOne pour bénéficier de la gestion des TAGS de manière automatique dans l’environnement VMware. L’aillant déjà déployé et configuré (cf le billet en question), autant en profité. Ce point est optionnel et nous pouvons nous passer de ce dernier. Il est tout à fait possible d’administrer les TAGS directement dans l’environnement vCenter.

Pourquoi tu parles de TAGS ?

Les TAGS ou marqueurs vont me permettre d’identifier les ressources virtuelles. Par exemple d’identifier les ressources virtuelles propres au bon fonctionnement de l’infrastructure et les ressources virtuelles propres à la production et donc au bon fonctionnement de l’organisation. Cela permet d’avoir un ratio Production/Infrastructure.

Il en va ainsi de même pour les services IaaS⁶, SaaS⁷ et pourquoi pas par environnement de service, réseau ou clients (dans le cas d’un MSP).

Les TAGs permettront d’apporter une finesse dans l’analytique.

Si nous faisons une petite synthèse, la solution doit pouvoir se connecter à l’API VCSA⁸ by VMware. De nouveau la question, quel langage utilisé ? JE TE CHOISIS ! Framework .Net avec powershell afin d’établir un mode manuel et un mode service. Certes pas esthétique mais avons-nous réellement besoin d’une interface GUI⁹ pour l’instant ? Naturellement, il est obligatoire que la solution laisse une trace de son exécution dans un fichier et ce à des fins de debug et de contrôle.

L’outil comportant un mode service, ce dernier doit être planifié de manière journalière pour traiter le point de suivi des métriques sur une durée donnée.

Les données seront stockées dans une base de données flexible et légère qui puisse être utilisé en dehors de la production et s’interfacer rapidement avec tous types de systèmes. Je propose d’utiliser SQLite3.

Concernant la partie exploitation et génération des métriques, j’ai pris parti d’utiliser PowerPI pour des raisons de praticité et de gain de temps. J’avais par le passé compiler les informations dans un fichier excel mais force est de constater que la solution n’est pas viable dans le temps en termes de gestion. L’avantage d’une BDD¹⁰ comme source de données et qu’elle reste interfaçable avec tous types de solutions (Web, Application lourde ou encore et toujours le terrible tableur Excel).

Pour la partie sécurité, nous resterons concernant la consultation des données VMware sur un compte restreint en lecture seul (pas besoin de plus et encore on peut affiner les droits de manière drastique). Quant à l’exécution de la tâche planifiée dédiée au mode service un compte gMSA¹¹ répondra à toutes les problématiques (dans le cas d’un poste joint à un domaine), sinon cela un compte local restreint. J’oubliais également que les informations d’identification seront chiffrées nativement par le SE¹² Windows dans le contexte d’exécution du poste et de la session.

En conclusion de notre liste de course, notre application utilisera :

• Connecteur API à l’Appliance VCSA VMware
  • Orienté MSP et SI finaux
  • Couvrir les architectures standalone et distribuée
  • Suivre les ressources virtualisées
  • Suivre les ressources matérielles
• Langage de développement & Fonctionnalités
  • .NET Framwork à travers Powershell (v5 ou plus)
  • Journalisation de l’exécution du code
  • Export des données en CSV et HTLM
  • Mode manuel et mode service
  • Fichier de configuration
  • Aide au déploiement
  • Visualisation en mode CLI
• SGBD
  • SQLite3
• Reporting
  • Microsoft PowerBI
• Securité
  • Si poste au domaine, création et utilisation d’un compte de service gMSA dédiéSi hors domaine, création d’un compte restreint au poste
  • Chiffrement des données d’authentification par les algorithmes natives Windows
  • Token API en lecture seule sur la VCSA

Il est temps de passer à la construction et définissions de nos différents niveaux de topographie d’architecture, applicative et logiciel.

Topographie – Infrastructure

La topographie a été pensé pour être la plus simple et standard (pour faciliter la gestion et l’évolution de l’application). J’ai fait le choix de tout embarqué dans l’application, mais il est toutefois possible de mettre en place une architecture 2 ou 3 tiers en dissociant les parties Engine, Reporting et BDD.

En d’autres termes, il est seulement nécessaire dans le cadre d’une architecture 1 tiers d’autoriser la communication des flux https/tcp entre l’appliance vCenter et notre application.

Topographie – Applicative

Depuis mon dernier gros projet, je suis désolé de vous apprendre que je ne suis toujours pas architecte applicatif. Renseignez vous, à l’agence des amants de Madame Müller, j’ai des restes !

A la racine du répertoire, nous retrouvons les deux fichiers exécutables :

• SS_43_1.0.0_VMWare-PowerCLI_Main.ps1 : Qui est le fichier d’instanciation de la solution est qui permet également de réaliser toutes les actions en mode manuel.
• SS_43_1.0.0_VMWAre-PowerCLI_Services.ps1 : Presque le même fichier que le fichier Main mais dédié au mode service avec un code adapté. Il ne peut être exécuté si et seulement si l’instanciation et initialisation à eu lieu.

La suite se déroule en 6 répertoires distincts.

• Modules : Répertoire contenant les modules powershell développé pour l’application. Aujourd’hui au nombre de quatre dissociant la partie BDD, Windows, HTML et VMware.
• Database : Répertoire contenant la BDD qui va stocker les données. La SGBD étant sous SQLite il n’y a pas besoin de moteur SQLite. Seul le module SQLite pour powershell est nécessaire en termes de dépendance. La base de données est automatiquement générée si cette dernière n’est pas présente ou si cette dernière à un nom qui diffère du fichier de configuration. Uniquement lors de l’exécution du script en mode manuel.
• Config : Répertoire contenant le fichier de configuration powershell. Effectivement depuis des années je faisais ça directement dans le code… Je mourrai moins con ce soir comme dirait quelqu’un que je connais bien 🙂 Je reviendrai plus en détail sur la partie 2 sur le contenu de ce fichier. Afin de palier à toute suppression malencontreuse du fichier de configuration, j’ai développé une fonction pour regénérer ce dernier. Oui je suis adepte du Alt+Maj+Del et j’ai dû recommencer mon fichier. Maintenant plus de problème avec mon combo favori <3
• Report : Là où je stocke les fichiers Microsoft PowerBI. Je reviendrais sur ce point dans la partie 2.
• Log : Répertoire qui va contenir la ou les traces d’exécution du code si l’option est activée. Cela à son importance car il permet au petit gars qui à dev l’application dans sa baignoire de corriger les bugs. Le fichier ne prend pas de place et est réinitialiser à chaque lancement.
• Export : Répertoire qui va contenir les données extraites selon les tags dans des rapports HTMLs. Les rapports ont été pensé pour être navigable et donc faciliter la consultation des rapports dans un navigateur internet. Cette fonctionnalité a été abandonnée pour l’instant car retranscrit dans PBI¹³. Mais cette fonctionnalité à le droit d’être finalisé et elle le sera. 🙂
• Import : Répertoire qui va contenir les sources CSV avec les permissions à définir le plus finement possible sur l’environnement VMware.

Il est important de noter que le script manuel et le script de service peuvent être dissocier. Ce qui se traduit dans un sens par je peux utiliser un serveur en mode type console avec l’outil manuel et garder l’automatisation sur un serveur avec uniquement le strict nécessaire.

Topographie – Logiciel

Comme toujours le code peut être optimisé, factorisé. Néanmoins, je considère cette version béta comme stable. Bien que par moment quelques ajustements restent nécessaire et quelques fonctionnalités ont besoin d’être finalisées. De plus, je pense sincèrement que d’autres cerveaux et d’autres idées permettraient de pousser plus loin certaines fonctionnalités existantes et de voir d’autres fonctionnalités naitre.

Oh ! La flemme du type qui ne veut pas se palucher un visio et montrer qu’il bosse encore à l’ancienne genre papier/crayon !

Dans son fonctionnement, nous pourrions voir le fonctionnement suivant :

• 0 : Contrôle et vérification des prérequis. Pour simplifier la chose, lecture du fichier de configuration vérification de la BDD et tout le toutim. Et dans une certaine mesure, création de la tâche planifiée
• 1 : Appel API vers l’appliance VMWare afin d’établir la connexion à l’appliance et réaliser les opérations de lecture nécessaire
• 2 : Traitement des données retournée par l’API VMWare afin de stocker ces dernières dans la SGBD, naturellement si l’option est activée l’ensemble des sorties consoles sont redirigées dans un fichier de log
• 3 : Laisser la possibilité d’exploitation des données
  • 3.1 : PS Output (cli) pour un affichage rapide des données dans la console powershell avec un affichage user friendly des performances et ressources VMWare (sinon tu as quasi la même chose dans la partie Dashboard de VMWare tu sais ?)
  • 3.2 : HTML Output pour générer une synthèse navigable par bulles et environnements virtuels
• 4 : Envoi d’une notification mail via le protocole SMTP pour informer du bon succès de la tâche.
• 5 : Possibilité d’exploitation dans Microsoft PowerBI.
  • Une fois le modèle en place de reporting (PowerBI) configuré (comprendre faire les jointures dans l’application), rafraichir les données. Modification des filtres dans un objectif d’exploitation

Comme d’accoutumé, je ne présente pas pour l’instant les différents bouts de code. Les raisons ? Toujours les mêmes. Première ça serait indigeste ici (bien que pour ça il y a GitHub), la seconde étant que je ne souhaite pas que mes travaux s’évaporent dans la nature. Et j’ajoute une troisième raison. Vous savez ce que vous pouvez « potentiellement recruter » dans votre équipe interne. (Oui, j’ai toujours en travers mon dernier entretien professionnel où je n’étais pas assez technique… Mais ce de bonne guerre #coeuraveclesmains). Je me pose toutefois la question et laisse part à la réflexion de rendre mon projet communautaire.

Sécurité

A ce moment de la rédaction, je ne vois qu’un point négatif sur l’ensemble du projet qui nécessite d’être amélioré. Ce point concerne la partie SGBD.

SGBD

Comme pour le projet GreenRay, la problématique est la même. Tout reste à faire… Bien que la BDD ne contienne pas de données sensibles pouvant nuire à la sécurité du SI cette BDD reste conforme à la législation en vigueur avec la RGPD¹⁴.

Toutefois, le choix de SQLite et de son caractère singulier cross plateforme nécessite de sécuriser son contenu et intégrité. Hors, de ce côté là, pas de chiffrement de la BDD ni de côte d’accès. Alors comme dans le projet précédent il faudrait envisager de développer d’autres plugins pour d’autres SGBDs relationnels.

Une sécurité de base, serait de paramétrer les ACLs afin que le fichier de BDD ne soit accessible que du compte de service et des comptes utilisateurs habilités à lancer l’application en manuel.

Concernant le MCD… Toujours le même dilemme…

Toujours pareil ! Boum boum dans les oreilles ! Le MCD¹⁵ a été pensé sur papier puis construit sur les bases d’un modèle existant… Partager le MCD revient à publier mon code finalement. Avec un peu d’huile de coude et de reverse engineering vous me remiserez au placard.

Pis bon, je vois venir les SysDBAs¹⁶ me dire que c’est pas MERISE nanani nanana… La structure de la BDD n’était pas d’une complexité folle, cette dernière n’était composée que de 13 tables.

VMware

Concernant VMWare, j’ai pensé à deux approches. Une approche d’authentification à travers une jonction à un domaine et à l’authentification locale.

Dans les deux cas, j’ai choisi de limiter l’accès en lecture seul. L’objectif du projet étant rappelons le de suivre et d’interpréter dans le temps l’évolution des infrastructures et non d’interagir par une méthode tierce. Ce qui renforce la sécurité. Toutefois, il sera nécessaire d’attribuer les droits manuellement bien que cela pourrait s’automatiser.

Naturellement, le couple d’authentification ne doit pas apparaitre en clair. Si je permets la saisie manuelle des credentials, dans le cadre de l’automatisation de la tâche le mot de passe doit être chiffré.

Comme d’hab (j’ai envie de dire), je préfère utiliser les fonctionnalités natives du système pour chiffrer le mot de passe avec les WAPI¹⁷ dans un fichier XML. Encore et toujours ce bon vieux CLIXML. Ainsi, l’accès à l’appliance est sécurisé et l’impact est maitrisé.

Taches Planifiées

Là, toujours le même dilemme. Le serveur ou poste qui va exécuter le script est il au domaine ou non ?

Dans le cadre d’un environnement hors domaine, il conviendra de créer un compte utilisateur dédié avec les droits nécessaire pour assurer la sécurité. Néanmoins et lors de la création de la tâche, il conviendra de préciser le mot de passe ainsi que le compte local. Ce qui n’est pas ouf en termes de MCO. Mais c’est aujourd’hui l’une des méthodes que j’affectionne si le serveur est hors domaine.

A l’inverse, si l’environnement est lié à un domaine, l’approche est différente et j’ai pour le coup changer mon fusil d’épaule (va t’il passer l’arme à gauche ?). Je suis devenu un convaincu des groupes de compte de services administrés (gMSA) dans une certaine mesure. Après réflexion sur mon infrastructure ainsi que les 43 types de scripts développés, je me suis dit qu’il n’était pas déconnant de définir un serveur de script dédiée à des tâches planifiées.

De ce fait, je n’installe pas sur tous les serveurs les RSATs¹⁸ ActiveDirectory et la rotation de mes mots de passe est périodique sans avoir à repasser, modifier les taches à chaque fois. C’est cool non ?

Il subsiste toutefois une petite pirouette si nous venions à utiliser les fonctions de chiffrement windows pour encoder et décoder une information. La création de la tâche nécessitera une configuration manuelle pour assurer le chiffrement.

Dépendances

Oui, je m’appuie sur des dépendances tierces. Il me semble important de parler de ces derniers avant toutes choses. Premièrement pour rendre à Caesar ce qui appartient à Caesar et deuxièmement pour comprendre comment le projet est construit.

• Connecteur .Net VMware – VMWare PowerCLI : Pour communiquer directement avec l’appliance VMware, il suffit d’installer et d’utiliser le plugin VMware.PowerCLI depuis le repo de base powershell (PSGallery). Ainsi, nous disposons de l’interface de commande compatible pour interagir avec les produits vSphere, vSAN, NSX, VMware Cloud on AWS etc.
• Interface .Net Powershell – SQLite : Pour communiquer avec une base de données SQLite, j’ai installé le plugin powershell PSSQLite depuis le repo officiel.
• Connecteur MS PowerBI et SQLite : Il me manquait les drivers ODBC¹⁹, j’ai donc dû télécharger et installer ces derniers afin d’assurer la connexion entre l’application PowerBI et la BDD SQLite (lien).

Et c’est tout. Rien de plus, rien de moins.

Avec toute la théorie, je pense que nous pouvons maintenant aborder la seconde partie pratique qui n’est rien d’autre que le guide d’installation et de configuration de l’application développée.

1. SI : Système d’Information ↩︎
2. DSI : Directeur des Systèmes d’Informations ↩︎
3. RSI : Responsable des Systèmes d’Informations ↩︎
4. MSP : Managed Services Provider ↩︎
5. API : Application Programing Interface ↩︎
6. IaaS : Interface as a Service ↩︎
7. SaaS : Software as a Service ↩︎
8. VCSA : VMware System Appliance ↩︎
9. GUI : Graphic User Interface ↩︎
10. BDD : Base de données ↩︎
11. gMSA : Groupe Managed Service Account ↩︎
12. SE : Système d’Exploitation ↩︎
13. PBI : Microsoft Power BI ↩︎
14. RGPD : Règlement Général sur la Protection des Données ↩︎
15. MCD : Modèle Conceptuel de Données ↩︎
16. SysDBAs : Administrateur des systèmes de base de données ↩︎
17. WAPI : Windows Application Programing Interface ↩︎
18. RSATs : Remote System Administration Tools ↩︎
19. ODBC : Open Database Connectivity ↩︎