Déployer vos applications avec Fogproject

Fog Project, logiciel de déploiement sous Linux, va vous permettre d’effectuer vos déploiements sur des clients Windows, Linux, et Mac.

N’hésitez-pas : 20 commentaires

Publié le 2 novembre 2021Â

Version PDF Version hors-ligne

Fog Project est un logiciel sous Linux qui va vous permettre d’effectuer vos déploiements pour machines Windows, Linux, et Mac.

Le déploiement sur les clients se fera par le biais d’un serveur PXE fourni par Fog Project. Un client est également disponible pour déployer des applications sur des systèmes en cours d’exécution.

Le déploiement consiste à effectuer des installations automatisées de machines ou installer ou mettre à jour automatiquement des logiciels sur des machines en production.

Pour effectuer des installations automatisées de systèmes d’exploitation, il vous faudra préparer au préalable un « Master ». Ce master sera cloné sur les machines de destination, avec des possibilités de personnalisation automatisée.

À cette fin, la machine cliente devant recevoir le déploiement (l’application du master sur celui-ci) démarrera via le réseau, le serveur de déploiement lui envoyant les éléments nécessaires.

La réalisation d’un master nécessitera des compétences sur le fonctionnement des systèmes d’exploitation concernés ainsi que de leurs outils. Un minimum de compétences en programmation de script sera également nécessaire.

Les tests ont été effectués depuis la version 1.5.9 de Fog Project installée sur une distribution Debian Stretch. Il est possible d’utiliser Fog Project sur d’autres distributions Linux, configurations non testées dans le cadre de ce tutoriel.

Les tests ont été effectués avec des machines virtuelles sous VirtualBox. Le démarrage réseau PXE en UEFI depuis VirtualBox ne fonctionne qu’en entrant dans le BIOS pour le sélectionner.

D’après le forum de Fog Project, la gestion du « Secure Boot » ne semble pas implémentée (non testé).

La partie Mac OS n’a pas été testée (pas de matériel à disposition).

Le site Internet de Fog Project fournit une version .zip et .tar.gz . Il est possible d’effectuer l’installation depuis git , solution que j’ai utilisée.

Il faudra ensuite lancer le script d’installation depuis le dossier bin .

L’installation se déclenchera :

Une première question vous sera posée concernant la distribution que vous utilisez (trouvée par défaut dans mon cas) :

La question suivante concernera le type d’installation : serveur normal ou serveur de stockage :

Nous ferons une installation de serveur normal (nous verrons l’installation d’un serveur de stockage au chapitre 9 Installation d’un nœud de stockage (Storage node) ).

Un serveur de stockage, comme son nom l’indique, ne servira qu’au stockage des images de déploiement. Celui-ci nécessitera d’être connecté à un serveur normal. Un ou plusieurs serveurs de stockage permettront un meilleur équilibrage de charge en cas de déploiements conséquents. Un seul serveur normal est utilisable.

Services installés sur un serveur normal :

Sur un serveur de stockage, seuls les services NFS et FTP sont déployés.

Vous seront ensuite proposés les réglages réseaux (à laisser par défaut en cas de présence d’une seule carte réseau) :

Les prochains réglages concerneront le réseau avec les réglages du serveur DHCP fourni par Fog Project :

Il semblerait que ne pas activer le serveur DHCP de Fog Project empêche le boot PXE.

Puis on règle l’internationalisation :

Pour avoir la possibilité de passer l’interface en français, il faudra répondre « yes »

Il vous faudra ensuite choisir le support HTTPS ou non :

Utiliser le mode HTTPS fera que l’installation sera plus lente. Il faut être patient, le script d’installation semblant bloqué.

L’option d’accès à l’interface en mode https a été testé, pour les autres options que nous allons voir, celles-ci semblent ne pas fonctionner en mode HTTPS. Il est possible que le problème vienne des certificats autosignés.

Vous sera ensuite demandé le hostname à utiliser :

Vous aurez enfin une demande de confirmation regroupant vos choix :

Une fois l’installation terminée, il vous faudra faire une première connexion sur l’interface Web de Fog Project pour installer la base de données, vous avez les indications pour vous connecter sur la console :

Une fois l’opération terminée, vous aurez l’écran suivant :

Vous pourrez alors appuyer sur la touche retour chariot dans la console d’installation, les services utilisés par Fog Project seront installés :

À la fin de la phase de configuration, les informations de connexion, URL, login et mot de passe vous sont indiqués.

Lors de l’accès à l’URL de connexion, vous aurez l’écran d’authentification :

À ce stade, choisir la langue française n’aura aucun effet, nous verrons un peu plus tard comment changer la langue.

Ci-dessous le tableau de bord s’affichant après connexion :

La première étape sera de changer les identifiants de connexion :

cliquer sur l’utilisateur fog permettra de le modifier :

Vous pouvez voir sur l’écran ci-dessus que j’ai changé le nom d’utilisateur par « admin »

puis on change le mot de passe :

Les données d’identification ayant été changées, revenons sur l’écran principal.

Toutes les fonctions principales sont accessibles depuis la barre de menu :

Nous allons commencer par passer l’interface en français.

Après avoir cliqué sur l’icône « Fog configuration », il va falloir aller dans l’onglet « FOG Settings » (en descendant dans la liste à gauche) sur l’écran de configuration :

Il faudra ensuite descendre dans la liste et cliquer sur « General Settings » pour dérouler les réglages. Vous pourrez ensuite sélectionner la langue en changeant la « default locale » :

Après avoir validé en cliquant sur « update » et rafraîchi l’écran en cliquant sur l’icône « dashboard », vous verrez l’interface en français.

La traduction en français est partielle, certaines parties resteront en anglais.

Pour les autres aspects, depuis l’écran de configuration, vous pourrez :

Nous n’entrerons pas dans le détail de ces réglages.

La configuration de base est stockée dans le fichier /opt/fog/.fogsettings , les autres réglages sont stockés dans la base de données MySQL nommée fog.

Vous pourrez faire un import/export de la base de données en sélectionnant « configuration save » dans la liste des choix dans l’onglet configuration.

Les écrans PXE ne seront qu’en anglais.

Nous démarrons un poste client sous Windows grâce à un boot réseau PXE :

Nous aurons le menu suivant :

Il y a deux options d’enregistrement :

Nous utiliserons dans un premier temps la première option, les différences seront expliquées un peu plus bas.

Une fois « quick registration and inventory » (que l’on peut traduire par enregistrement et inventaire rapide) sélectionné, la machine démarrera sur le système fourni par FOG.

Image du boot en cours :

Une fois l’enregistrement effectué, la machine apparaîtra dans la liste des hôtes avec comme nom son adresse MAC :

Vous pourrez changer le nom de la machine en cliquant dessus :

Le fait de changer le nom m’a fait passer l’icône de Windows à « Unknown » (problème lié au mode Quick Registration).

En allant dans l’onglet « inventory », vous aurez des informations sur le matériel :

Les écrans de boot seront identiques :

info : vous pouvez voir que la machine est reconnue en tant que machine Windows (présence de l’icône )

Dans le cadre d’un enregistrement avec l’option « Perform Full Host Registration and Inventory », il vous sera demandé :

Comme il s’agit ici de l’intégration d’une machine existante, nous répondons aux questions par la négative.

Une fois l’opération effectuée, la machine apparaîtra avec le nom saisi.

Pour supprimer un hôte, il faudra cliquer sur l’icône en bas de l’écran après avoir sélectionné l’hôte concerné (dans l’exemple : suppression de la machine nommée Debian) :

Une fois cliqué sur « Delete selected host » en bas de page, vous aurez un second écran ou il faudra de nouveau cliquer sur « Effacer » :

Il vous faudra ensuite entrer un identifiant ayant des droits administrateur :

Il va être intéressant de gérer des groupes de machines pour effectuer des déploiements (exemple : installer une application sur tous les postes ou pour les machines d’un service).

Pour créer un groupe, cela se passera dans la partie groupe :

Une fois le groupe créé, il faut y intégrer les machines. Pour cela, on sélectionne le groupe concerné depuis la liste des groupes :

Une fois dans le groupe, il faudra aller sur l’onglet « membership » :

Il faudra ensuite cocher « check to see what hosts can be added » :

Vous pouvez voir ci-dessous la machine win10 disponible :

Prérequis pour les versions antérieures à Windows 10 : .net framework 4.5.1

Pour installer le client sur le poste, il faudra aller sur la page Web de connexion à Fog Project, vous trouverez le lien du client en bas de page :

Une fois le client téléchargé, le seul point d’attention nécessaire lors de l’installation sera la page de configuration :

Vous pouvez voir que l’adresse du serveur par défaut est « fogserver » : à remplacer par son adresse IP, à moins que vous ayez créé une entrée pour celui-ci dans vos DNS.

Pour le « web root », celui-ci sera à modifier si vous avez effectué des modifications sur le virtualhost créé pour Fog Project.

Fog Project dépend de Mono (l’implémentation libre de la plateforme .NET), qu’il faudra commencer par installer :

Vous pourrez ensuite télécharger le client proprement dit :

Ceci va créer un fichier nommé « download.php?smartinstaller », que l’on renommera en smartinstaller.exe

Mono est l’implémentation libre de l’environnement d’exécution .Net Framework. Celui-ci permet de faire du développement cross-platform, d’où le renommage en fichier .exe

Nous lancerons ensuite son installation par la commande mono smartinstaller.exe  :

Vous seront ensuite posées les questions suivantes :

À la question « enable tray icon », il faudra répondre non, la fonctionnalité n’étant pas disponible sous Linux

Ci-dessous les logs d’installation :

Un snapin correspond à une action de déploiement à effectuer sur les postes auxquels celui-ci sera affecté.

Le snapin sera applicable à une machine ou à un groupe de machines.

Pour fonctionner, le snapin devra être entièrement automatique, et donc n’avoir aucune interaction. Sous Windows, il sera exécuté sous le compte SYSTEM . Ceci limite les possibilités et oblige à travailler ses installations.

Les snapins seront par défaut stockés dans /opt/fog/snapins .

Un snapin sera applicable à une machine en production ou exécutable après déploiement.

Première partie de l’écran de création de snapin :

Le snapin se présentera sous les formes suivantes :

Qu’est-ce qu’un fichier MSI ? MSI pour Microsoft System Installer. Windows installer est le moteur d’installation, de mise à jour et de désinstallation de logiciels fournis avec Windows.

Beaucoup de logiciels sous Windows sont fournis sous forme de fichier .msi. Un MSI devra être conçu pour vous permettre une installation silencieuse avec fourniture des paramètres d’installation sur la ligne de commande.

Pour modifier les paramètres par défaut d’un fichier .msi, ou si celui-ci ne permet pas de lui passer les paramètres nécessaires, vous pouvez utiliser Orca , fourni avec le SDK de Microsoft pour modifier celui-ci.

La modification d’un msi peut être interdite ou soumise à condition par l’éditeur d’un produit.

Exemple : le déploiement d’Adobe Reader .

Pour packager une application à installer en fichier .msi, deux produits font référence :

Vous pouvez retrouver un tutoriel sur Inno Setup ici : Inno Setup .

Nous allons tester l’installation de Firefox sur Windows :

Pour cela, il faudra récupérer le fichier .msi de Firefox sur le site de Mozilla .

Pour une installation simple, il suffira de créer un snapin avec le .msi de Mozilla.

Par défaut, l’option /quiet permettant l’installation silencieuse est sélectionnée :

J’ai décoché l’option « redémarrage après installation », inutile pour Firefox.

La commande générée sera :

Cette commande sera visible dans la page de création du snapin, dans le champ « commande snapin ».

Une fois le snapin créé, il va falloir l’affecter à une machine ou à un groupe de machines. Pour cela, il faut sélectionner celui-ci depuis la liste :

Le numéro 1 visible après le nom de la tâche correspond au numéro de snapin, numéro autoincrémenté à chaque création de snapin.

Une fois la tâche (le snapin) sélectionnée (en cliquant sur son nom), il faudra aller sur l’onglet membership :

Il faudra cocher la case « check to see what hosts can be added » et affecter les machines souhaitées.

Dans l’exemple ci-dessous, la machine « win7 » a été intégrée :

Il est également possible de le faire depuis l’écran d’un hôte dans l’onglet snapin :

Pour affecter un snapin à un groupe, il faudra le faire depuis le groupe lui-même, dans l’onglet snapin :

Restera à intégrer le ou les snapin au groupe (dans notre exemple Firefox) :

Restera ensuite à créer la tâche de déploiement depuis l’onglet « basic task » du groupe (ou de la machine), dans la partie avancée :

il faut ensuite sélectionner « all snapins » pour déployer plusieurs actions ou « single snapin » pour un seul dans la liste des options :

Dans la tâche, il faudra sélectionner le ou les snapin et choisir si le déploiement doit se faire immédiatement ou si celui-ci doit être déclenché à un moment précis :

Vous aurez ensuite confirmation de la création de la tâche :

Vous pouvez voir l’état de la tâche en cliquant sur l’icône tâche en haut :

En passant sur les icônes dans la colonne « status », vous aurez leur signification :

En cas de choix d’installation immédiate, il y aura quand même un petit délai avant exécution de la tâche sur la machine cliente.

Au moment du déclenchement de l’installation, sur un client Windows, vous aurez une notification :

Une nouvelle notification sera affichée une fois le snapin installé. Vous pouvez constater l’ajout d’une icône Firefox sur le bureau :

Une fois le déploiement effectué, vous pourrez remarquer que l’icône Firefox n’a pas été créée dans la barre des tâches. En regardant la documentation de l’installation Firefox , vous pourrez constater qu’il existe une option à passer à l’installeur .exe pour obtenir une icône dans la barre des tâches. La documentation vous fournit également tout ce qu’il faut comme informations pour repackager votre propre .msi .

Dans l’interface Fog Project, vous pouvez voir la liste des snapins installés dans l’onglet « snapin history » :

Si vous supprimez Firefox du poste client et redéclenchez une tâche d’installation, Firefox sera réinstallé. Le snapin apparaîtra une seconde fois dans l’historique.

Rappel : il sera impératif que l’installation soit silencieuse. Certains installeurs le permettent grâce à des paramètres de ligne de commande. Vous devrez rechercher pour chaque logiciel à installer les options pour un déploiement silencieux. En cas d’absence de celui-ci, vous ne pourrez pas le déployer sans utiliser des outils comme Msiexec pour les fichiers .msi ou sans repackager l’application pour que celle-ci soit silencieuse lors de l’installation.

Nous allons tester le déploiement de VLC.

Pour déployer VLC, nous utiliserons les paramètres /L=1036 et /S pour respectivement sélectionner le français et effectuer une installation silencieuse (paramètres disponibles sur le site officiel ).

Nous sélectionnerons batch script et verrons qu’il utilisera cmd /c  :

Il faudra ensuite uploader l’installeur de VLC en cliquant sur « browse », puis indiquer les paramètres. Nous décocherons également le reboot après installation :

Ce qui donnera dans le champ « snapin-command read only » la commande qui sera exécutée :

Exemples courants de déploiement ici .

Les fichiers inhérents aux snapins sont stockés par défaut dans /opt/snapins . Supprimer un snapin ne supprimera pas le fichier qu’il utilise, pensez donc à l’effacer si besoin.

Pour Linux, l’installation d’un logiciel hors déploiement se fait en général par le gestionnaire de paquets de la distribution :

Le fonctionnement est similaire, quel que soit le gestionnaire de paquets.

Exemple pour l’installation de Firefox sur une Debian :

L’option -y servant à l’autoconfirmation

Firefox ESR est la version avec support à long terme (ESR=Extended Support Release)

Flatpak est un système d’installation de logiciels avec double objectif :

Ce système va embarquer toutes les dépendances nécessaires (comme les bibliothèques) avec l’avantage qu’un paquet flatpak ne pourra pas perturber un autre paquet et l’inconvénient que ces dépendances soient stockées à plusieurs reprises, si utilisées par plusieurs paquets flatpak.

Dans le cas d’utilisation de plusieurs paquets flatpak, pour pallier en partie ce problème, il existe des regroupements de bibliothèques pouvant être partagées entre plusieurs applications, regroupements nommés runtimes.

Il est possible de faire cohabiter plusieurs versions d’applications, chacune dans son propre paquet flatpak.

Certaines applications s’installent par script. Elles sont en général fournies sous forme de .tar.gz, qui une fois décompressées, contiendront un fichier exécutable ou un script, en fait un script d’installation automatique (installant automatiquement les prérequis). Un Readme donne en général des indications.

Certains logiciels sont fournis sous forme de sources qu’il va falloir compiler. Cette opération se limitera en général à l’appel d’un script nommé configure , qui va paramétrer les directives de compilation pour votre système, suivi par la compilation proprement dite grâce à la commande make , puis l’installation des fichiers à leur emplacement définitif par make install qui copiera les fichiers nécessaires dans les dossiers adéquats du système. Pour un déploiement de ce type, il vaut mieux compiler le produit sur un poste de test, puis créer un script de déploiement des fichiers compilés nécessaires dans le système de destination. Un fichier readme donne également des explications en général.

Donc, pour installer un logiciel sous Linux vous devrez :

Si vous ne passez pas par le gestionnaire de paquets et devez lancer un script qui copie des fichiers, il faudra créer un snapin pack, que nous verrons au chapitre suivant, celui-ci devra contenir tous les fichiers à déployer ainsi que le script pour les copier dans les bons dossiers.

Un snapin pack est un fichier .zip qui sera copié sur le poste client, décompressé, puis le fichier exécutable y étant contenu passé en argument : .exe, .msi, batch, selon le choix effectué, sera exécuté. Le fichier à exécuter pourra être dans un sous-dossier tant que son chemin relatif est indiqué dans le champ snapin pack file.

Il vous faudra donc préparer de fichier .zip avant le déploiement.

Le déploiement d’un snapin pack se fera de la même façon qu’un snapin standard, vous aurez juste à sectionner « Snapin Pack » dans le champ snapin type. Pour les autres champs, pas de changement.

Ceci permettra de fournir au client un ensemble de fichiers installés automatiquement et non plus un seul fichier.

Le prochain usage de Fog Project que nous allons étudier consistera à créer une image d’une machine, il s’agira d’une archive contenant la capture en l’état de la machine sélectionnée (machine éteinte, redémarrée en PXE).

Les images seront par défaut stockées dans /images/[nom de l'image] . Pour changer le chemin, il faudra aller dans fog configuration → fog settings → FOG Utils.

La première chose à faire sera de créer un conteneur nommé image dans la nomenclature Fog Project.

Pour cela, il faudra accéder à la partie « Image Management » :

Entrer un nom pour l’image et la version de l’OS (si non détecté) suffira (au niveau des flèches bleues).

Il faudra ensuite aller sur l’hôte à capturer depuis la liste des hôtes :

Cliquez sur l’icône pour créer la tâche. Ceci déclenchera l’ouverture des paramètres de la machine, où il vous faudra sélectionner l’image (le conteneur) créée précédemment :

Une fois l’image créée, le nom de celle-ci apparaîtra à côté de l’icône permettant de déclencher la capture :

Lors d’une prochaine capture, vous aurez l’écran suivant. Il faudra relancer la procédure pour arriver sur l’écran de création de la tâche dans le cas où vous venez de créer l’image comme vu ci-dessus.

Nous créons la tâche immédiatement, vous aurez un message comme quoi la tâche a été créée :

vous pourrez ensuite gérer et suivre l’état depuis la liste des tâches :

Au démarrage de la machine à sauvegarder, celle-ci démarre en réseau sur l’image disque Fog Project :

ci-dessous, sauvegarde en cours avec partclone , utilisé par Fog Project :

état de capture en cours depuis l’interface :

La barre de progression indique l’état d’avancement de la capture.

Une fois la capture effectuée, vous pourrez voir les informations afférentes (comme la taille, la date de capture) depuis la liste des images :

La prise d’image pourra vous servir de backup, mais qui ne sera pas incrémental. Utiliser une image en tant que backup n’est pas le but premier de Fog Project.

Dans le cadre de déploiements, le principe sera de préparer une machine avec toutes les applications et réglages communs, que l’on nommera « master » et qui sera anonymisée. Ce « master » servira à déployer la même image sur plusieurs machines.

Windows fournit un outil adapté à cela : sysprep .

Une fois la machine préparée à votre convenance (applications installées par exemple), il faudra lancer sysprep :

Il ne faudra pas redémarrer sur le master, mais en PXE pour effectuer la capture de l’image.

L’outil sysprep peut également utiliser un fichier de réponse sous forme de XML, permettant la personnalisation de l’installation comme :

Commande pour appeler sysprep avec un fichier de réponse :

exemple de fichier de réponse  :

Source : wikipédia.

Les distributions Linux disposent également de système de personnalisation pour l’installation.

Pour les bases Debian :

L’installation d’une base Debian peut être automatisée grâce à un fichier preseed.cfg .

Ce fichier devra soit :

Exemple de fichier de configuration pour Ubuntu, qui est une base Debian :

https://help.ubuntu.com/lts/installation-guide/amd64/apbs04.html

Sur une installation existante, il vous faudrait donc créer le fichier de configuration, l’intégrer dans le gestionnaire de démarrage et enfin capturer l’image. La dernière opération du fichier de configuration devra consister à son autosuppression (retrait de l’option dans le gestionnaire de démarrage)

Le principe sera le même qu’avec preseed . L’utilitaire dédié avec les bases Redhat se nomme kickstart .

Le paramètre à passer au noyau sera :

documentation : https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/6/html/installation_guide/sn-automating-installation

https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/7/html/installation_guide/sect-kickstart-syntax

l’outil d’installation de paquets YAST ( Yet Another Setup Tool ) permet également de faire du « preseed ».

La sous-fonction AutoYaST permettra l’installation automatisée grâce à un fichier de paramètres en XML.

Autoyast inclut une interface graphique :

Documentation officielle pour installation automatisée SUSE

Si vous souhaitez restaurer une image sur une machine existante, vous pouvez directement procéder à la restauration. Dans le cas d’une restauration sur une nouvelle machine, procédez à son inventaire comme vu au chapitre 4 intégration d’un poste existant dans fogproject , puis affectez-y l’image concernée.

Il faudra cliquer sur l’icône correspondant à votre choix de restauration (dans mon cas, j’ai sélectionné multicast).

Demande de confirmation :

La restauration d’une image personnalisée pourra être déployée sur plusieurs machines, ce qui correspond à une opération de déploiement.

Un nœud de stockage permettra :

L’installation se fera de la même façon qu’avec un serveur principal.

Il faudra répondre « S » (Storage Node) à la question concernant le type d’installation :

Il faudra ensuite répondre aux mêmes questions que pour une installation standard, puis aux questions spécifiques à l’installation d’un nœud de stockage :

Les informations indispensables sont récupérables dans les réglages → FOG Storage Node :

Récapitulatif avant validation de l’installation :

Une fois la configuration terminée, vous aurez un récapitulatif d’éléments à conserver :

Dans l’onglet « Storage Management », vous pouvez voir que le nom par défaut du nœud ajouté correspond à son adresse IP, vous pourrez changer ce nom après avoir cliqué sur celui-ci.

Si vous essayez d’accéder à l’interface Web sur le nœud de stockage, vous aurez le message suivant :

Une fois le nœud de stockage configuré, nous l’ajoutons dans le groupe par défaut :

Une fois le nœud intégré dans le groupe, les images présentes sur le premier serveur seront répliqués.

Pour pouvoir stocker certaines images sur le serveur Fog principal et d’autres images sur un serveur de stockage annexe, il va falloir créer un groupe de stockage et y affecter le nouveau serveur de stockage. Jusqu’à présent, nous avions utilisé le groupe de stockage par défaut.

Pour créer un groupe de stockage, il faudra se rendre dans l’onglet stockage, puis sélectionner « Add storage group » :

Vous pourrez ensuite affecter le nœud au nouveau groupe plutôt qu’au groupe par défaut. Vous aurez donc bien deux serveurs de stockage différents :

Si vous ajoutez des serveurs supplémentaires, vous pourrez les affecter aux groupes existants et donc avoir la réplication des images comme dans le premier cas de figure, ou plus répartir les images sur plusieurs serveurs.

Pour pouvoir réinstaller votre serveur Fog Project en cas de problème, il va vous falloir :

Nous partirons du postulat que le serveur de déploiement est secondé par un serveur de stockage.

Nous allons profiter de ce serveur de stockage pour y intégrer une redondance de la base de données. La copie de cette base ne sera pas utilisée en fonctionnement normal, il faudrait pour cela monter un cluster de base de données pour répartir la charge. Il s’agira ici d’une simple synchronisation au niveau base de données.

Nous commençons par créer un fichier de configuration /etc/mysql/conf.d/replication.cnf sur le serveur principal pour activer la réplication.

La première ligne bind-address = 0.0.0.0 permet aux autres machines de communiquer avec MySQL/MariaDB. Par défaut un serveur MySQL/MariaDB ne communique que sur localhost (127.0.0.1).

La ligne server-id devra contenir une valeur différente sur chaque serveur

La dernière ligne log-bin permet d’activer les logs binaires appelés aussi journaux de transactions. Avec cette option, un journal de transactions est utilisé et va enregistrer tous les accès en écritures à la base (INSERT/UPDATE/DROP, etc.). En simplifiant, ceci permet de remettre la base dans un état précédent en utilisant lesdits journaux. La taille et la purge des journaux de transaction sont paramétrables. Ces journaux vont aussi être utilisés pour la réplication, le serveur esclave va récupérer les logs sur le serveur maître et rejouer les opérations nécessaires pour que le maître soit répliqué sur l’esclave.

La relation sera à sens unique, mais il est possible de faire de la synchronisation en créant une double relation maître-esclave. Dans ce cas de figure, il vaudra mieux monter un cluster de bases de données.

Une fois le fichier de configuration créé, il faudra redémarrer le service MySQL/MariaDB.

Pour que le serveur principal soit indisponible le moins longtemps possible, il faudra préparer à l’avance le serveur secondaire. Une fois celui-ci prêt, créez-y le même fichier de configuration que vu ci-dessus en remplaçant la valeur du server id (vous pouvez copier celui-ci avec rsync).

Dans le cadre de ce test, le serveur accueillant la réplication (l’esclave) possède l’adresse IP 192.168.1.201, le serveur principal possède l’adresse IP 192.168.1.200 (le maître).

Sur le serveur principal, la prochaine étape consistera à créer un utilisateur pour la réplication :

Sur le serveur principal, nous exécutons ensuite la commande suivante dans la console MySQL :

Cette commande va forcer l’écriture d’un éventuel cache non enregistré sur le disque et placer un verrou en lecture seule. Cette opération devra être faite avant de relever la position actuelle dans les logs de façon à pouvoir faire un export cohérent et avoir la position de référence dans les logs.

Nous relevons ensuite la position des logs :

Nous avons relevé le nom du fichier log et la position actuelle, nous faisons un export depuis le shell :

Avec -u pour le nom d’utilisateur, -p pour la demande de mot de passe.

Nous pouvons maintenant retourner dans la console MySQL/MariaDB et déverrouiller la base :

Une fois le fichier d’export copié sur le serveur secondaire, nous l’importons :

Nous activons la réplication avec les étapes suivantes :

Puis nous indiquons les paramètres pour la réplication, avec les éléments de position :

Dans l'exemple ci-dessus, à la fin de la première ligne (après la virgule), un retour chariot a été fait, ceci afin de faciliter la lisibilité. Il aurait été possible d'écrire toute la requête sur la même ligne.

La réplication se déclenchera immédiatement. Vous pourrez voir l’état de la réplication avec la commande :

L’option \G permet un affichage plus lisible.

En cas de perte de serveur de stockage, il faudra supprimer ses références dans la base de données (suppression du nœud dans stockage → all storage node).

Une fois cette opération effectuée, il suffira de réinstaller le serveur de stockage, puis de l’intégrer dans Fog Project comme vu dans le chapitre 9 Installation d’un nœud de stockage (Storage node) .

Restera à remettre en service la réplication Sécurisation de la base par réplication MySQL si appliquée.

Nous supposerons que nous avons la base répliquée sur le serveur et une copie du fichier de configuration.

Nous réinstallons un serveur en lui affectant la même IP que celui d’origine.

Nous copions avec rsync le dossier Fog, le fichier de configuration (nous plaçons le fichier .fogsettings dans /fog/ opt ) et un export de la base.

Nous commençons par importer la base dans MySQL/MariaDB :

Nous lançons ensuite l’installation, qui après confirmation réinstallera fog.

Il sera alors possible de se connecter à l’interface Web d’administration.

Par contre, il sera nécessaire de récupérer les images et les snapins depuis le serveur de stockage, la synchronisation de ceux-ci ne se fera pas automatiquement.

Fog Project dispose de fonctionnalités annexes accessibles depuis l’hôte ou le groupe d’hôtes concernés → basic task → avancée :

Pour accéder à cette fonctionnalité, il vous faudra aller sur l’hôte concerné dans l’interface de Fog Project. Une fois celui-ci sélectionné, la fonctionnalité d’arrêt ou de redémarrage sera accessible depuis l’onglet « Power management ».

Vous pourrez choisir l’action :

Vous pourrez ensuite planifier ou lancer immédiatement l’opération :

Sur les hôtes Windows, vous aurez une notification sur le poste client, avec possibilité de décaler celle-ci, ou de l’annuler :

Sur un poste Linux, le redémarrage, une fois pris en compte par Fog Project, sera immédiat sans notification.

Le redémarrage ou arrêt est également applicable à un groupe.

L’option sera effective depuis un compte sans droits administrateur.

Il semblerait que l’option ne fonctionne pas en mode https.

La suppression de mot de passe sera accessible depuis l’écran « basic task » de la machine concernée :

Il faudra alors saisir le nom du compte ou le mot de passe doit être réinitialisé :

Si la machine est en route, cela déclenchera son redémarrage (avec la boite de dialogue permettant le report sous Windows)

Le test de cette fonctionnalité n’a pas abouti. Un message d’erreur « enable to locate SAM file » s’affichant depuis le boot PXE (le fichier SAM est spécifique à Windows), que ce soit avec un client Windows ou un client Linux.

Le problème mentionné ci-dessus est contournable en créant un snapin réinitialisant le mot de passe par un script batch ou PowerShell, mais rendant du coup cette fonctionnalité inutile.

Il est possible depuis Fog Project de déclencher un test mémoire. Celui-ci s’appuie sur l’utilitaire bien connu memtest86+ .

L’option est accessible depuis « basic task » avancé, tout comme pour le changement de mot de passe :

L’option est aussi déclenchable depuis le boot PXE.

memtest en cours d’exécution :

En mode UEFI, memtest n’est pas exploitable, vous aurez un message d’erreur au boot. Il existe une version de memtest compatible UEFI, mais elle n’est pas implémentée dans Fog Project.

Le test de surface va permettre de faire un test physique du disque :

Fog Project utilisait auparavant CLAMAV pour effectuer un scan antivirus sur les postes distants. Cette fonction est dépréciée, mais ni retiré de l’interface ou du démarrage PXE, ni du wiki officiel. Information obtenue depuis le forum de support.

Fog Project vous permettra d’effacer à distance un disque.

Pour ceci, il faudra sélectionner dans les tâches de l’hôte :

Une fois la procédure déclenchée et la machine redémarrée en PXE, vous aurez 60 secondes pour interrompre la procédure en arrêtant l’ordinateur :

Ci-dessous l’effacement en cours :

La commande utilisée pour l’effacement est shred . Celle-ci permet l’effacement sécurisé, le nombre de passes étant sélectionnable (différence entre un fast wipe, un normal wipe, ou un full wipe).

Cette fonctionnalité ne vous permettra pas de faire un effacement d’urgence forcé, la fonctionnalité étant annulable.

Cette opération peut être pratique en cas de nécessité d’effacement de masse, par exemple après remplacement d’un parc informatique.

La fonction « recover » va vous permettre de lancer le bien connu utilitaire Photorec .

Photorec se lance avec sélection automatique du disque source. Il vous faudra sélectionner un dossier de destination, ce qui pourra vous poser des difficultés, celui-ci devant être monté avant destination.

La fonction Debug va vous permettre d’ouvrir un terminal sur le boot PXE :

Vous aurez ensuite un prompt terminal.

Pour un client Linux :

Pour un client Windows :

Vous aurez ensuite accès à toutes les commandes disponibles dans l’image PXE.

Une fois ce que vous avez à faire terminé, il faudra supprimer la tâche Debug dans l’interface Web de Fog sous peine de redémarrer sur l’image PXE en mode Debug.

Fog Project permet également de gérer des imprimantes partagées. Pour cela, il faudra créer la file d’attente et y renseigner les éléments suivant :

Utiliser un logiciel de déploiement pour gérer des files d’attente semble peu utile. Si on fait du déploiement, c’est en général qu’on a une infrastructure avec serveurs, avec lesquels on va en général gérer ce type de services.

L’intérêt est surtout de faciliter le déploiement de ces files d’attente directement sur les clients de Fog Project. Rien n’empêche non plus de déployer des imprimantes avec des login scripts en environnement Active directory dans le cas d’un environnement Windows.

Fog Project va vous permettre de déployer vos systèmes et applications sur PC/Mac.

Les fonctionnalités annexes manquent de fiabilité, mais ne font pas partie de fonctions spécifiquement attendues pour du déploiement. Effectuer par exemple un test de surface disque ou un test mémoire depuis un logiciel de déploiement et donc potentiellement sans être devant la machine ne me paraît de toute façon que peu pertinent.

La traduction en français est à ce stade incomplète, mais comme il s’agit d’un projet Opensource, il suffit d’y participer pour améliorer celle-ci.

Ce produit va trouver son intérêt dans le cadre d’un parc hétérogène.

Je remercie les membres du forum de Fog Project pour leur réponse sur l’Antivirus.

Je remercie LittleWhite ainsi que djibril pour leur relecture technique et escartefigue pour la relecture orthographique.