PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Visual Studio 2015 Preview : développez pour Windows 10

mardi 24 mars 2015 à 17:30

Les outils de développement pour Windows 10 Technical Preview sont disponibles pour les développeurs, de ce fait, ils peuvent dès à présent commencer à développer pour Windows 10 grâce à la Technical Preview 6 de Visual Studio 2015.

visual-studio1
L’objectif est de créer des applications universelles, c’est à dire capable de fonctionner indifféremment que ce soit sur un PC, un smartphone, une tablette ou encore la console Xbox One. Ainsi, l’interface de l’application s’adaptera automatiquement selon le périphérique sur lequel on se trouve.

Cela représente un changement important pour les développeurs, qui devaient jusqu’ici créer des interfaces spécifiques qu’il s’agisse de Windows 8.1 ou de Windows Phone 8.1.

Quelques mots sur l’Adaptive UX

Cette nouvelle fonctionnalité permet de créer une interface qui s’adapte automatiquement à l’écran sur lequel l’application s’affiche. Bien entendu, il sera toujours possible de définir manuellement le comportement de l’application.

Le ViewStateManager permettra de contrôler comment l’interface de l’application change en fonction de la taille de l’écran.

…Et les APIs

Les APIs permettront aux applications de tester la présence d’une fonctionnalité particulière sur l’appareil, dès le lancement de l’application en question. Il s’agit d’une méthode plus directe d’obtenir une information plutôt que de deviner une éventuelle présence par rapport au numéro de version de Windows.

Enfin, Microsoft précise que les applications existantes continueront à être compatibles avec Visual Studio 2015, mais vous invite à tester les nouvelles API introduites.

Si vous êtes inscrit au programme Windows Insider et que vous disposez de la dernière Technical Preview de Windows 10 (build 10041), vous pouvez utiliser ces outils de développement. Attendiez-vous ce kit de développement ?

Pour le téléchargement :

Visual Studio 2015 Technical Preview 6
Tools for Windows 10

J’embauche..

mardi 24 mars 2015 à 14:30

Depuis quelques semaines, on cherche à embaucher un développeur confirmé (Python/Django) pour un tout nouveau projet ! Comme à mon habitude, je me fais aider par des sociétés extérieures afin de trouver le « bon » candidat car je n’ai pas assez de temps pour prendre en charge cette recherche…

Plusieurs semaines sont passées sans la moindre candidature, et pourtant nous nous trouvons en région parisienne puis, miracle, trois CV sont arrivés fin de semaine dernière et trois RDV ont été pris dans la foulée. Il y a pourtant des développeurs sur le marché mais pas toujours avec les compétences que l’on cherche et, dans notre cas, il semblerait que les candidats soient moins nombreux.

Il va falloir maintenant proposer à ces candidats de belles perspectives afin qu’ils soient conquis par le projet que l’on propose et afin qu’ils puissent s’épanouir et acquérir encore plus d’expérience. Dans notre cas, c’est toujours compliqué d’attirer les gens dans notre organisation, pourquoi ? Le cadre de travail que nous proposons n’est pas des plus bucoliques puisqu’il s’agit d’une zone industrielle, ce n’est pas à Paris même et donc difficile d’accès et, cerise sur le gâteau, nos bureaux ne ressemblent pas vraiment à ce que l’on pourrait trouver dans une agence de comm. parisienne, si vous voyez ce que je veux dire…

Alors, comment je m’y prends ? Et bien tout d’abord il faut jouer « cartes sur table » car le but du jeu consiste à ce que le candidat sache exactement où il met les pieds, qu’il comprenne bien ce que l’on va lui demander de faire et dans quelles conditions (latitude, technologies, organisation du projet, méthodes de travail, outils à sa disposition…). En clair je ne fais rien miroiter au candidat que je ne saurai tenir ! Pas de blabla, j’expose clairement le projet, je présente les futurs collaborateurs, l’environnement de travail etc…et j’ai même tendance à noircir un peu le tableau, je préfère que le candidat ait de bonnes surprises une fois chez nous que l’inverse.

L’objectif consistant à garder le candidat sur la durée et non pas à « forcer » un candidat à venir chez nous, par dépit, par nécessité uniquement ou tout simplement parce qu’on lui fait des promesses que l’on ne saura pas tenir.

Donc j’insiste sur l’originalité du projet, l’autonomie car dans notre cas ici on part d’une feuille blanche et sur la « liberté » au sein de notre équipe. Liberté ? Oui, c’est bien de cela qu’il s’agit, liberté de proposer, liberté de choisir, liberté de s’exprimer, liberté dans le choix des outils, liberté de manger à la cantine (ah ben non, on en a pas…), donc liberté de se faire livrer des sushis ou un poulet aux olives, liberté de manger à 11h pour les lève-tôt, à 12h comme les poules, ou à 13h pour le JT, voire à 14h pour les lève-tard, liberté d’écouter de la musique, liberté de s’intéresser aux autres projets de l’équipe, liberté de poser une statuette de Yoda sur son bureau, liberté de ramener son smartphone explosé pour voir si un de nos techs peut lui changer l’écran contre une bière, liberté de ramener ses dosettes de café, liberté de donner un coup de main à notre apprenti quand il cale sur un exercice d’algorithme de son BTS … Bref, liberté de se sentir un peu chez soi, entourés d’amis et de potes, car c’est quand même au « bureau » que l’on passe une bonne partie de notre vie !

Au final, quand la première version de son projet sera sortie et que des utilisateurs du monde entier (oui, nos utilisateurs sont partout !) lui feront les premiers retours, il pourra dire : c’est moi qui l’ai fait !

PS : Ce billet n’est pas une offre d’emploi, ce n’était pas le but et, on vient de trouver l’oiseau rare !

Les GPO ne s’appliquent pas ? 14 pistes à étudier

mardi 24 mars 2015 à 10:30

I. Présentation

Lorsque l’on déploie des stratégies de groupe au sein d’un domaine, il peut arriver que les choses ne se passent pas comme prévu… Surtout lorsque l’on commence à avoir beaucoup de GPO et que l’on utilise des paramètres spécifiques comme les filtres WMI…

Pour « débugger » la GPO et faire en sorte qu’elle fonctionne comme on a envie qu’elle fonctionne, il faudra vérifier sa configuration. Cet article référence une dizaine de points à vérifier pour que les GPO s’appliquent – enfin – correctement.

II. Les 14 pistes à étudier

A. Un paramètre non appliqué, vérifiez l’étendue

Si un paramètre ne s’applique pas, vérifier l’unité d’organisation sur laquelle s’applique la GPO. S’il s’agit d’un paramètre Ordinateur, la GPO doit s’appliquer sur l’OU qui contient l’objet ordinateur ciblé. Sur le même principe s’il s’agit d’un paramètre Utilisateur, la GPO doit s’appliquer sur l’OU qui contient cet utilisateur.

En fait, il faut surtout que l’objet cible soit dans l’étendue de la GPO (l’étendue est aussi appelée scope), c’est-à-dire qu’il soit dans la sous-arborescence sur laquelle s’applique la GPO.

Exemple de cette notion d’étendue :

gpo-debug-1

En fait, vérifiez que l’objet ciblé n’est pas « hors de portée » de la GPO.

B. Le filtre de sécurité

Par défaut, le groupe “Utilisateurs authentifiés” dispose des autorisations nécessaires sur un objet GPO nouvellement créé. Pour rappel, ce groupe inclut tous les utilisateurs… et tous les ordinateurs du domaine !

Filtre de sécurité - GPO

Filtre de sécurité – GPO

De ce fait et si vous avez décidé de modifier ce filtre de sécurité, assurez-vous que l’objet cible de la GPO dispose des autorisations nécessaires. Dans les autorisations NTFS de la GPO, vous retrouverez « Utilisateurs authentifiés » avec le droit « Appliquer la stratégie de groupe » sur « Accepter », ce type d’autorisation est ajouté automatiquement lorsque vous ajoutez un utilisateur ou un groupe dans la zone « Filtrage de sécurité ».

Normalement, on ne modifie pas manuellement ces autorisations, sauf cas particulier. Par exemple, si l’on souhaite empêcher qu’une GPO s’applique sur un utilisateur, un ordinateur, ou un groupe, on passera par la modification manuelle des droits pour passer « Appliquer la stratégie de groupe » sur l’état « Refuser ». Ainsi, la GPO ne s’appliquera pas, d’ailleurs vous pourriez contrôler au sein de votre infrastructure que n’ayez pas ce genre de problème qui pourrait se manifester par des messages du type « Accès refusé ».

C. Filtre WMI

Il est possible d’appliquer un filtre dynamique sous forme de requête WMI sur une GPO. Par exemple, appliquer la GPO uniquement si le système d’exploitation de l’hôte cible est Windows 8.

Ajout d'un filtre WMI - GPO

Ajout d’un filtre WMI – GPO

De ce fait, si vous avez défini un filtre WMI, vérifiez qu’il est correct et qu’il ne pénalise pas votre cible. Autrement dit, vérifiez qu’il n’exclut pas votre cible plutôt que de la prendre en compte.

Par défaut, aucun filtre WMI n’est mis en place. Pour ceux qui souhaitent, voici deux articles qui expliquent la création de filtres WMI fonctionnels :

Filtre WMI du système d’exploitation
Filtre WMI machine virtuelle

D. Vérifier l’état de la GPO

– En sélectionnant une GPO et en cliquant sur l’objet « Détails », il est possible de donner différents états à la GPO (notamment des états de désactivation). Vérifiez que l’état est bien sûr « Activé » pour activer l’ensemble des paramètres (ordinateurs et utilisateurs) définis dans cette GPO.

Vérifier l'état de la GPO

Vérifier l’état de la GPO

E. La délégation

L’onglet délégation regroupe les autorisations appliquées sur l’objet GPO en question, notamment pour déléguer la création d’une GPO à un utilisateur (l’autoriser). De plus, ces autorisations sont importantes pour la réplication des GPO entre les contrôleurs de domaine, car elles régissent les droits d’accès.

On remarque que les informations que l’on retrouve dans cet onglet sont équivalentes à celles que l’on retrouve dans l’onglet « Sécurité », en accédant aux « Propriétés » d’un dossier d’un élément GPO (dans SYSVOL). Voyez par vous-mêmes :

gpo-debug-5

Ce point est à vérifier si vous avez des problèmes de réplication de vos GPOs, ce qui peut impliquer des erreurs d’application par la suite…

F. Les héritages : un nid à problèmes…

Il existe des notions d’héritages pour les stratégies de groupe. Par exemple, si l’on souhaite que la GPO « Default Domain Policy » ne s’applique pas sur une OU en particulier, il suffira de faire clic droit sur l’OU concernée puis « Bloquer l’héritage ».

Les héritages bloqués sont facilement visibles grâce à un icône bleu contenant un point d’exclamation, comme ceci :

Blocage de l'héritage d'une GPO

Blocage de l’héritage d’une GPO

Si vous avez des blocages en place, vérifiez donc qu’ils ne posent pas problème…

À savoir également, le fait que si on désactive l’héritage sur l’OU « Collaborateurs » comme ci-dessus, mais que la GPO « Default Domain Policy » est « Appliqué » (Enforced), elle sera appliquée malgré tout. Autrement dit, elle outrepasse le blocage et s’applique quand même.

G. LSDOU : Kézako ?

L’acronyme LSDOU spécifie l’ordre d’application des stratégies de groupe. De ce fait, la stratégie Locale est appliquée en première et ensuite : Site, Domaine et Unité d’Organisation (Organizational Unit).

Modèle LSDOU

Cette notion est très importante puisque si vous activez un paramètre sur une GPO appliquée au niveau du domaine, et qu’une autre GPO placée au niveau de l’OU désactive ce même paramètre, ce sera la GPO placée la plus proche de la cible qui gagnera.

En fait, en dehors de la stratégie locale, on remarque que plus la GPO est appliquée sur une unité d’organisation proche de l’objet ciblé, plus elle sera prioritaire.

Pour vérifier ceci, vous pouvez utiliser GPResult notamment en générant un rapport HTML (avec l’option /H) pour avoir un résumé complet.

H. Le lien est-il actif ?

Dans la console de gestion des stratégies de groupe, les différentes GPO sont stockées dans un container nommé « Objets de stratégie de groupe ». Ensuite, chaque GPO est liée sur une ou plusieurs OUs, ce qui crée des liens.

Un lien représente un raccourci entre la GPO dans le container et l’OU sur laquelle s’applique cette GPO.

Ces liens peuvent être activé ou désactivé, cela signifie que l’on peut temporairement désactiver un lien pour désactiver l’application de la GPO sur une OU. Ceci est pratique puisque ça évite de devoir supprimer le raccourci et le recréer ultérieurement.

Vous devez vérifier que les liens sont corrects, notamment actif pour la GPO qui doit s’appliquer.

En faisant un clic droit sur un raccourci, il sera possible de savoir si le lien est activé ou non :

Le lien de la GPO est-il actif ?

Le lien de la GPO est-il actif ?

I. Les GPOs « Enforced » – « Appliqué »

Que la traduction de cette option est mauvaise ! En fait, dans la version française de Windows « Enforced » est traduit par « Appliqué », ce qui peut laisser penser que si on n’active pas ce paramètre la GPO ne sera pas appliquée. Ceci est totalement faux.

Il serait plus judicieux de traduire « Enforced » par « Forcé », de ce fait comprenez « Appliqué » par « Forcé » (ou « forcer l’application ») et là ça change la donne…

Cette possibilité remet en cause le schéma d’application LSDOU et offre de nouvelles perspectives pour appliquer les GPOs. En effet, si on active ce paramètre pour une GPO on force son application et on la rend prioritaire par rapport à une autre.

De plus, si deux GPOs sont forcées ce sera celle de plus haut niveau qui sera prioritaire ! Par exemple, si je force la GPO « Default Domain Policy » et la GPO « Utilisateurs_IE », ce sera la première qui gagnera sur la deuxième, car elle est placée « plus haut ».

GPO Enforced

GPO Enforced

On reconnaît facilement une GPO sur laquelle le paramètre « Appliqué » est définit à « Oui », car l’icône contient un verrou.

J. Le loopback processing

Pour faire simple sur la notion de loopback processing, lorsque vous démarrez l’ordinateur, il applique les paramètres ordinateurs définis dans la GPO qui s’applique sur lui. Ensuite, lorsqu’un utilisateur se connecte, les paramètres utilisateurs présents dans la GPO qui s’applique sur l’utilisateur sont alors appliqués. Jusque-là, tout est normal…

Par contre, si vous activez le loopback processing au niveau de la GPO concernée il peut y avoir des surprises… En effet, si c’est actif, les paramètres utilisateurs contenus dans la GPO appliquée sur l’ordinateur seront appliqués à l’utilisateur qui se connecte, alors que cette GPO n’est pas directement appliquée à cet utilisateur ! Les paramètres utilisateurs provenant réellement de la GPO appliquée à l’utilisateur seront traités de différentes façons.

Le traitement dépend de ce que vous avez décidé : cumul des deux (avec priorité aux paramètres de la GPO ordinateur en cas de conflit) ou appliquer en priorité les paramètres définis sur la GPO qui s’applique à l’utilisateur.

Ce paramètre est configurable par GPO :

Configuration de l’ordinateur, Modèles d’administration, Système, Stratégie de groupe, Mode de traitement par boucle de rappel de la stratégie de groupe utilisateur

K. Attention à la fausse piste…

Certains paramètres se ressemblent beaucoup et les différences sont parfois minimes sur le papier, mais « conséquente » dans la réalité. Soyez vigilant et lisez bien la description d’un paramètre, en fait posez-vous la question suivante : « Ce paramètre est-il vraiment celui qui répond à mes attentes ? »

Peut-être que toute votre configuration est parfaite, mais si vous ne choisissez pas le bon paramètre, ça ne marchera pas.

L. Le Best Practice Analyzer

Si vos investigations ne donnent rien, vous pouvez générer une analyse avec le Best Practice Analyzer. En cas de configuration incorrecte, il sera capable de remonter l’information et cela peut fortement aider dans certains cas.

Consultez mon article sur le BPA : Best Practice Analyzer (BPA)

M. L’observateur d’événements

Aussi bien au niveau du contrôleur de domaine que de la cible, l’observateur d’événements fournit bien souvent des informations intéressantes sur l’erreur rencontrée (tout dépend de son origine…).

De ce fait, n’hésitez pas à consulter l’observateur d’événements sur un ordinateur cible sur lequel la GPO ne s’applique pas, mais aussi sur votre contrôleur de domaine.

Une fois dans l’observateur d’événements, au sein du journal créez une nouvelle vue et sélectionnez en source « GroupPolicy (Microsoft-Windows-GroupPolicy) ». Ceci permettra d’afficher tous les événements liés au GPO et provenant de l’ensemble des journaux (Système, Application, etc.).

Créer une vue sur "GroupPolicy (Microsoft-Windows-GroupPolicy)"

Créer une vue sur “GroupPolicy (Microsoft-Windows-GroupPolicy)”

Ce qui permettra d’afficher uniquement les événements liés aux GPOs :

Exemple d'événements liés aux GPOs générés

Exemple d’événements liés aux GPOs générés

N. L’outil RSOP

L’outil RSOP (Resultant Set Of Policy – Résultats de stratégie de groupe) est un outil intéressant pour tester l’application des GPOs, sans courir à droite et à gauche sur les PCs de votre parc informatique.

Choisissez un ordinateur, un utilisateur et l’outil RSOP se chargera de vous afficher un rapport quant à l’application des GPOs pour cet utilisateur sur la machine indiquée. Cet outil permet d’une part de contrôler que tout s’applique bien comme on le souhaite, d’autre part de débugger les GPOs en cas de besoin.

C’est en quelque sorte une exécution à distance d’un GPResult, ce qui rend l’outil plus pratique et plus flexible. De plus, vous pouvez sauvegarder les rapports directement dans la console.

Voici un aperçu de RSOP :

Aperçu d'un RSOP

Aperçu d’un RSOP

Pour générer un rapport, utilisez la console de gestion de stratégie de groupe, effectuez un clic droit sur « Résultats de stratégie de groupe » et suivez l’assistant.

III. Conclusion

En conclusion, lorsque vous mettez en place des GPOs faites le plus simple possible, il ne faut pas que ça devienne « une usine à gaz » et limitez également le nombre d’objets de stratégie de groupe. Il y a des chances pour que ça limite les ennuis… Pensez également à adopter un système de nommage clair et parlant, par exemple pour différencier facilement une GPO Utilisateur d’une GPO Ordinateur.

Avec les points cités ci-dessus, vous devriez pouvoir vous en sortir dans de nombreuses situations, bien qu’il puisse y avoir des cas extrêmes. Si votre problème n’est pas résolu, utilisez notre forum pour exposer votre problème à la communauté. Par ailleurs, si vous souhaitez apporter un complément, veuillez laisser un commentaire sur cet article, ce sera appréciable.

Pwn2own : tous les navigateurs mis à mal !

lundi 23 mars 2015 à 17:30

Lors de la conférence CanSecWest qui aborde la sécurité informatique, la compétition de deux jours “Pwn2own” a pour objectif de mettre à mal les différents navigateurs web pour torturer leur sécurité.

logo-navigateur1Telle une tradition, toutes les dernières versions des navigateurs se sont fait pirater. Mariusz Mlynski est rapide ! Il lui aura fallut que quelques secondes pour exploiter une brèche dans Firefox. Il n’est pas le seul à s’être amusé, puisque le Coréen, JungHoon s’est amusé à contourner les protections de plusieurs navigateurs : Chrome, Safari et Internet Explorer 11. Cela lui a permis d’obtenir 225 000 dollars.

Par ailleurs, le Français, Nicolas Joly a gagné 90 000 dollars pour avoir trouvé une vulnérabilité dans Adobe Flash et la visionneuse PDF Reader.

Tout le monde trouve son compte dans cette compétition : les pirates qui peuvent s’exercer et trouver de nouvelles failles, tout en obtenant une compensation financière en retour… Les entreprises comme Google, Microsoft, Apple ou encore la fondation Mozilla en bénéficient, car cela leur permet d’améliorer la sécurité des navigateurs.

Premiers pas avec le PXE sous Debian

lundi 23 mars 2015 à 15:00

I. Présentation

Remarque : Ce tutoriel publié le 28 Septembre 2011 fût remis à jour et complété le 23 Mars 2015

PXE pour Preboot eXecution Environment, est un système permettant à un hôte client de démarrer via le réseau en récupérant l’image d’un OS qui se trouve sur un serveur PXE. Ce système peut être utilisé aussi pour le chargement d’application telle que GParted, il existe un grand nombre de cas de figure pour ce mécanisme de déploiement.

Bien que le PXE serve seulement à distribuer les images de systèmes d’exploitation par le réseau, il offre trois atouts principaux :

pxe-atout1

Le PXE est un sujet conséquent, il est préférable de découper le sujet en plusieurs tutoriels, d’où l’intérêt de ce tutoriel d’initiation. Dans ce premier tutoriel sur PXE, on se contentera de déployer une seule image, à savoir Debian Wheezy en NetBoot (démarrage par le réseau). Le serveur PXE est sous Debian Wheezy, il dispose de l’adresse IP “192.168.1.155” et il est sur le même réseau que le client PXE.

pxe-schema

Vous êtes prêt ? Alors on va commencer !

II. Obtenir SYSLINUX

Il est nécessaire de commencer par l’installation de Syslinux, qui permet d’obtenir différents chargeurs d’amorçage pour Linux. Tout simplement, installez-le grâce à la commande suivante (avec au préalable la mise à jour des données paquets) :

apt-get update
apt-get install syslinux

On va créer sur notre serveur une arborescence classique pour le serveur TFTP que nous installerons par la suite. L’arborescence à créer est “/srv/tftp“.

mkdir -p /srv/tftp

Syslinux permet d’obtenir un fichier “pxelinux.0” qui correspond au loader chargé par les clients. On va le copier à la racine du TFTP :

cp /usr/lib/syslinux/pxelinux.0 /srv/tftp/

On en a fini avec Syslinux, on va s’intéresser au DHCP et au TFTP.

III. Installation et configuration de DNSMASQ

D’une part, le DHCP permet de distribuer une configuration réseau aux clients PXE, d’autre part, le TFTP permet de rendre disponibles les fichiers d’installation aux clients, ce qui leur permet de réaliser l’installation. Plutôt que d’installer dhcp3 ou tftpd, on va s’appuyer sur le paquet Dnsmasq qui permet de créer facilement une multitude de services (dhcp, dns, tftp…). Faisons simple.

On installe le paquet :

apt-get install dnsmasq

Le fichier de configuration “/etc/dnsmasq.conf” contient toute la configuration relative à Dnsmasq. Éditez ce fichier. Ajoutez ce bloc de configuration :

# Configuration file for dnsmasq.
## Activation d'une plage DHCP pour les clients PXE, de 192.168.1.100 à 105
## Une adresse IP est attribuée pour 6h au client
dhcp-range=192.168.1.100,192.168.1.105,255.255.255.0,6h
## Fichier de boot PXE
dhcp-boot=pxelinux.0
## Activer le TFTP et definir un repertoire (/srv/tftp)
enable-tftp
tftp-root=/srv/tftp

Sauvegardez vos modifications et redémarrez le service Dnsmasq :

service dnsmasq restart

On obtient un message de confirmation comme quoi le service a bien redémarré :

[ ok ] Restarting DNS forwarder and DHCP server: dnsmasq.

Le serveur est prêt au niveau des paquets, il ne reste plus qu’à récupérer une image NetBoot de Debian Wheezy.

IV. Récupérer une image NetBoot de Debian

Directement sur le serveur PXE, on va télécharger les fichiers de la Netboot de Debian via wget. Au préalable, on se positionne à la racine du TFTP puisque c’est dans ce répertoire qu’il faudra stocker les données de l’archive tar.gz obtenue.

cd /srv/tftp
wget http://ftp.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/netboot/netboot.tar.gz

Patientez quelques secondes pendant le téléchargement…

pxe-wget-debian1

Désormais, on va tout simplement extraire le contenu de l’archive téléchargée, et on va la supprimer. Voici les deux commandes qui permettent d’effectuer ces opérations :

tar zxf netboot.tar.gz 
rm netboot.tar.gz

Si l’on prend le temps de voir l’arborescence de données obtenues (avec le paquet tree, non inclus par défaut), voici ce que l’on obtient :

pxe-tree

A partir de ce moment-là, le serveur PXE est prêt et l’installation de Debian par le réseau peut-être effectuée.

V. Installation PXE

On va démarrer notre client PXE, qui doit disposer d’une carte réseau compatible avec le PXE (ça doit être plutôt rare de nos jours qu’une carte ne sache pas gérer le PXE, autrement dit le démarrage sur le réseau).

Sur la copie d’écran ci-dessous, on remarque que le serveur DHCP (dnsmasq) distribue une adresse IP au client, qui va ensuite charger via PXE la configuration par défaut (pxelinux.cfg/default).

pxe-boot1

Une fois la phase d’initialisation terminée, le menu de démarrage de Debian va s’afficher sur le poste client :

Menu Debian obtenu par le boot PXE

Menu Debian obtenu par le boot PXE

VI. Pour aller plus loin…

Ce tutoriel aborde les notions de base du boot PXE, il est possible d’aller plus loin pour bénéficier d’un véritable système de déploiement automatisé. Voici quelques pistes pour vous orienter :

Lorsqu’un client PXE se présente, le déploiement se calque sur le fichier de configuration par défaut de pxelinux, à savoir un fichier nommé “default” et présent dans le répertoire “pxelinux.cfg“.

Lors d’un déploiement sur de multiple machines, il est intéressant d’avoir un fichier de configuration par machine afin de préconfigurer et personnaliser ce que l’on souhaite déployer sur chaque machine.

De ce fait, avant de prendre en compte le fichier de configuration “default“, le PXE cherchera à trouver un fichier de configuration spécifique à la machine cliente. Pour cela, il regarde si le nom d’un fichier correspond à l’adresse MAC du poste client, si ce n’est pas le cas, il regarde par rapport à l’adresse IP au format hexadécimal (Exemple : C0A80167 = 192.168.1.103), si ce fichier n’existe pas non plus il charge le fichier default.

Les fichiers PreSeed de Debian permettent de personnaliser la configuration du système d’exploitation, par exemple, le nom de la machine, le langage, les miroirs à utiliser, le partitionnement des disques, etc. Cela vous fera gagner un temps précieux lors du déploiement d’un machine (ou d’un serveur).

Les directives commencent par “d-i” et après les options disponibles sont nombreuses.

N’hésitez pas à partager vos expériences avec le PXE sous Linux, et vos avis sur la gestion des fichiers de configuration et des fichiers PreSeed.