Site perso d'un administrateur d'infrastructures sécurisées

Catégorie : Exploiter et maintenir les services de déploiement des postes de travail.

Déployer un OS via le réseau avec FOG 1.5.10 sur Debian 12

Le déploiement d’une image d’OS à l’aide de FOG (Free Open-Source Ghost) est une méthode très efficace pour installer un système d’exploitation sur de multiples machines à partir d’une seule image source.

FOG utilise PXE (Preboot Execution Environment) pour démarrer les machines clientes sans disque dur, CD/DVD ou clé USB, puis déploie l’image stockée sur le serveur FOG.

Le clonage d’une image d’OS à l’aide de FOG (Free Open-Source Ghost) est une méthode très efficace pour déployer un système d’exploitation identique sur de multiples machines à partir d’une seule image source.

FOG, fonctionnant sur une machine sous Debian, utilise PXE (Preboot Execution Environment) pour démarrer les machines clientes sans disque dur, CD/DVD ou clé USB, puis déploie l’image qu’il a préalablement stockée.

Le principe de fonctionnement est le suivant :

  1. On commence par créer une machine (ou VM) sur laquelle on installe Windows 10 de manière « basique ».
  2. Le service FOG sur Debian capture une image de cette VM sous Windows 10.
  3. Un Windows Server agit en tant que serveur DHCP et distribue des adresses IP aux nouvelles machines qui sont déployées à partir de cette image.
  4. Une machine « nue » (c’est-à-dire sans OS) est utilisée pour tester le déploiement de l’image précédemment capturée par FOG, le tout via le réseau.

Pré-requis

Pour tester ce service de déploiement, je vous propose de mettre en place ce lab suivant (Sur VMWare ou Virtualbox par exemple) :

  • Une machine sous Debian 12 server (sans interface graphique, c’est gourmand ces bêtes là) sur laquelle on installera FOG
  • Une machine sous Windows Server 19 qui aura pour rôle de distribuer dynamiquement les IP aux machines qui rejoignent le réseau (sous-entendu, installer le service DHCP)
  • Une machine sous Windows 10 « vanilla » avec un utilisateur lambda qui servira pour la capture
  • Une VM « vide » sans OS

Concernant la configuration « réseau » :

  • Pour la simulation du réseau, je créé un NAT qui aura comme ip 10.0.2.0/24
  • Mon serveur DHCP sous WindowsServer aura comme IP fixe l’adresse 10.0.2.10
  • Le service DHCP distribuera des adresses sur la plages 10.0.2.20 – 10.0.2.30
  • Mon serveur Debian aura quand à lui l’adresse fixe 10.0.2.15
  • Bien sûr toutes ces machines sont sur le même réseau 😉

Installation de Windows 10 et Windows Server

Je ne vais pas revenir sur ces étapes, il suffit simplement de créer 2 machines, l’une avec un Windows 10 « classique », l’autre avec un Windows Server 2019 sur lequel on installe le service DHCP sur l’étendue 10.0.2.20 – 10.0.2.30.

Si vous ne savez pas comment faire, je vais décrire le processus dans un futur article !

Installation de FOG

L’installation de FOG se fait via les commandes suivantes (sur le serveur Debian 12 bien sûr !)

apt-get update && apt-get upgrade
cd /tmp
wget https://github.com/FOGProject/fogproject/archive/1.5.10.tar.gz
tar -xvzf 1.5.10.tar.gz
cd fogproject-1.5.10/bin 
./installfog.sh

L’installation guidée qui va suivre permet de créer le fichier de configuration .fogsettings qui se trouveras par la suite dans le dossier /opt/fog/ (cf la documentation officielle ici : https://docs.fogproject.org/en/1.5.9/reference/install_fogsettings.html)

Détail du processus d’installation de FOG

  • A l’étape 1, choisissez l’option 2 (on est sur Debian) :
  • Ensuite, choisissez l’installation « normale »
  • L’installeur trouve automatiquement l’interface réseau, choisissez No quand il vous demande si vous voulez en utiliser une autre :
  • Ensuite, il faut configurer l’adresse du routeur, choisissez Y et vérifiez que le routeur est le bon (en général c’est l’adresse de la passerelle de votre VM, soit 10.0.2.2 si vous utilisez Virtualbox avec un réseau NAT)
  • Même manip pour le serveur DNS, qui se trouve normalement à l’adresse 10.0.2.3 sur VirtualBox
  • Ensuite, on peut refuser la mise en place d’un serveur DHCP via FOG car nous passons déjà par Windows Server
  • FOG propose ensuite de charger un pack de langue, mais comme on est bons en anglais (n’est-ce pas ??) on va laisser ça par défaut !
  • Il nous demande enfin si on veut utiliser HTTPS pour notre interface web. Comme c’est un lab privé, on va rester du http classique, mais bien sûr l’idée c’est de passer en https pour sécuriser les échanges dans un environnement de production (et ça demande quelques manips supplémentaires indiquées ici : https://wiki.fogproject.org/HTTPS)
  • Enfin pour la dernière étape vous pouvez sélectionner « N » par défaut lorsque l’installeur vous propose de changer le nom d’hôte.

Si tout s’est bien déroulé vous devriez avoir un résumé de votre installation, que vous pouvez copier/coller dans fichier texte à part

A la fin il nous indique les options à activer sur le serveur DHCP, ce que nous allons faire très bientôt ! Validez l’installation en cliquant sur « Y ». Si tout se passe bien vous devriez voir ceci :

NB : n’allez pas plus loin pour l’instant, il y a une manipulation à faire dans l’interface web d’abord !!

Configuration de FOG depuis l’interface web

Maintenant que FOG est installé, vous pouvez vous rendre sur son interface web via l’URL indiquée à la fin de l’installation (de mon côté j’ai opté pour une connexion depuis ma machine hôte, avec une redirection de ports, mais vous pouvez tout à fait vous y connecter « naturellement » via une VM disponible sur le même réseau)

Cliquez sur « Install / Update Now » pour finaliser l’installation de la base de données. Si tout se déroule bien vous devriez voir ce message :

Retournez sur la machine Debian et appuyez sur « Entrée » pour valider l’installation de la BDD. Une fois celle-ci terminée, vous aurez les infos de connexion à l’interface web, en l’occurence fog et password :

De retour sur l’interface web, connectez vous avec les identifiants indiqués précédemment

L’interface ressemble à cela :

La configuration sur Windows Server

Maintenant que l’installation et la configuration du serveur FOG est terminée, il va falloir faire une petite manipulation sur le serveur DHCP pour indiquer aux ordinateurs démarrant via le réseau où le trouver.

En effet, par défaut, le serveur DHCP se contente de distribuer des IP, pas d’indiquer le chemin vers une quelconque plateforme !

Pour ce faire, il va donc falloir utiliser des options d’étendues dans le gestionnaire DHCP du serveur Windows, en l’occurence les options 66 et 67

Euh non, c’est pas l’option 66 ça !

Les options d’étendue 66 (Boot Server Host Name) et 67 (Bootfile Name) sur un serveur DHCP Windows sont utilisées dans des scénarios de démarrage en réseau, aussi connu sous le nom de PXE (Preboot eXecution Environment).

Ces options indiquent à un client PXE où trouver le serveur TFTP et quel fichier de démarrage (bootfile) charger. Ces options sont essentielles pour les scénarios de déploiement d’image système ou d’installation de systèmes d’exploitation sur des ordinateurs via le réseau.

Voici un aperçu de ces options :

  1. Option 66 – Boot Server Host Name:
    • Cette option spécifie l’adresse du serveur TFTP (Trivial File Transfer Protocol).
    • Cela peut être une adresse IP ou un nom d’hôte.
    • Le client PXE utilisera cette adresse pour contacter le serveur TFTP et télécharger le fichier de démarrage spécifié dans l’option 67.
  2. Option 67 – Bootfile Name:
    • Cette option spécifie le nom du fichier de démarrage que le client PXE doit charger.
    • Ce fichier est généralement un chargeur d’amorçage spécifique à l’environnement ou à l’outil de déploiement que vous utilisez (par exemple, FOG, mais aussi Windows Deployment Services, etc.).

Lorsqu’un ordinateur démarre via PXE, il envoie une requête DHCP pour obtenir une adresse IP et des informations supplémentaires nécessaires pour le démarrage en réseau. Si les options 66 et 67 sont configurées sur le serveur DHCP, elles sont transmises au client PXE. Le client utilise ensuite ces informations pour contacter le serveur TFTP, télécharger le fichier de démarrage et commencer le processus de démarrage en réseau.

Voici comment faire pour ajouter ces options sur Windows Server : rdv dans Gestionnaire DHCP -> Cliquer sur le gestionnaire du serveur (ipv4) -> aller dans l’onglet « Options d’étendue » puis faites un clic droit dans la fenêtre pour ajouter une option :

Capture de l’image

Maintenant que le serveur DHCP est configuré pour indiquer l’emplacement du serveur FOG, il va falloir créer un « master » de déploiement, sorte de « clone » d’un OS déjà installé sur une machine.

En l’occurence, on va utiliser la VM tournant sous Windows 10 comme « patient 0 » qui servira à créer une armée de clones de Windows.

Décidemment, les analogies avec Star Wars sont légion dans ce milieu… 😀

Lancez la VM, mais en choisissant de booter sur le réseau (F12 sur Virtualbox, option « l », ou en définissant le réseau comme 1ere source de boot dans la configuration du système). Vous devriez arriver sur cet écran :

Sélectionnez « Quick Registeration and Inventory » pour faire remonter l’hôte dans FOG

Normalement, si vous vous rendez dans l’onglet « hosts » de l’interface web, vous devriez voir la machine :

Rdv dans l’onglet « Images » puis cliquez sur « Create new image » pour créer une nouvelle image Windows 10. Donnez lui un nom et choisissez l’OS « Windows 10 » dans la liste déroulante :

Cliquez sur Add pour ajouter l’image.

Ensuite, retournez dans « Hosts » -> « List All Hosts » puis sélectionnez l’hôte afin de lui attribuer une image :

Revenez ensuite à « List all hosts » puis cliquez sur le bouton orange « Capture » :

Puis activez la tâche pour enclencher la capture de l’image sur le réseau :

Relancez la VM en bootant sur le réseau. L’outil Partclone devrait se lancer tout seul pour effectuer la capture

Une fois la capture terminée, rdv de nouveau dans l’interface web de FOG pour constater la présence de l’image (qui « pèse » pas loin de 12 go)

Déploiement du « Master » via le réseau

Le master désigne le « modèle » qui a été capturée avec FOG. Il comprend l’ensemble de l’OS en mode « prêt à l’emploi » qui va pouvoir être installé en quelques minutes sur une machine vierge.

Voici les dernières étapes à suivre pour finaliser notre processus de déploiement automatique via le réseau.

N’oubliez pas les pré-requis suivants :

  • La machine nue doit booter sur le même réseau que les autres !

On allume la VM et on boote sur le réseau pour que FOG puisse prendre le relai ; ensuite il faut créer un enregistrement pour ajouter la machine dans le gestionnaire :

NB : si vous avez le message d’erreur suivant

8354 timer not connected to IO APIC

Dans la configuration de votre VM, essayez simplement d’ajouter un processeur. Chez moi ça a réglé le problème.

Ensuite, une fois le processus d’enregistrement terminé, rdv dans l’interface web, rubrique « Hosts » -> « List all hosts » et cliquez sur « Deploy » :

Choisir l’image à déployer :

Ensuite dans « Tasks » -> cliquer sur « Deploy »

Puis cliquer sur « Task » pour activer la tâche de déploiement

Enfin, il suffit de redémarrer la VM et laisser la magie de Parclone opérer :

Une fois la restauration terminée, laissez la machine booter normalement : vous devriez arriver sur votre clone de Windows 10 prêt à l’emploi !

Qu’est-ce qu’une architecture « HA » en réseau ?

Dans les discussions entre administrateurs système, on rencontre souvent des acronymes plus ou moins bizarres, et il faut s’y faire. L’un d’entre eux m’a interpelé dernièrement : l’infrastructure dite « HA »

« HA » fait, en réalité, référence à « High Availability » (Haute Disponibilité en français). Une infrastructure en HA est conçue pour être résiliente et minimiser les temps d’arrêt.

L’objectif est d’assurer que les services et applications restent disponibles même en cas de défaillance d’un composant de l’infrastructure.

Voici quelques caractéristiques et composants couramment associés à une infrastructure en HA :

  1. Redondance : C’est l’un des principes fondamentaux de la HA. Si un composant tombe en panne, un autre composant redondant prend le relais. Par exemple, si un serveur tombe en panne, un autre serveur avec les mêmes données et applications peut prendre le relais.
  2. Basculage automatique (Failover) : En cas de défaillance d’un composant, le système est capable de basculer automatiquement vers un composant redondant sans intervention humaine.
  3. Équilibrage de charge (Load Balancing) : Distribue le trafic entrant entre plusieurs serveurs pour éviter qu’un seul serveur ne soit surchargé.
  4. Clusters : Groupes de serveurs travaillant ensemble pour fournir une haute disponibilité. Si un serveur du cluster tombe en panne, les autres serveurs continuent de fonctionner.
  5. Réplication de données : Les données sont stockées à plusieurs endroits pour garantir leur disponibilité. Si un site de stockage tombe en panne, les données sont toujours accessibles depuis un autre site.
  6. Surveillance et alertes : Les systèmes de surveillance surveillent en permanence la santé et les performances de l’infrastructure. En cas de problème, des alertes sont générées pour informer les administrateurs.
  7. Mises à jour et maintenance sans interruption : La capacité de mettre à jour ou de maintenir une partie de l’infrastructure sans affecter la disponibilité globale du service.
  8. Conception sans point unique de défaillance (SPOF) : Éliminer tout composant dont la défaillance pourrait entraîner une interruption de service.

L’infrastructure en HA est essentielle pour les entreprises et les services qui nécessitent une disponibilité continue, comme les banques, les hôpitaux, les sites de commerce électronique, etc.

Cependant, la mise en place d’une telle infrastructure peut être coûteuse et complexe, nécessitant une planification minutieuse et une certaine expertise technique. J’aborderai cette question un peu plus tard, pour l’instant avoir connaissance du concept dans l’ensemble, c’est déjà pas mal !

Fièrement propulsé par WordPress & Thème par Anders Norén