HDT : Hardware Detection Tool (v 0.5.0)

37

22

avr.

2011

Noyau

Hardware Detection Tool est un outil de bas niveau permettant l’identification du matériel cible sur le matériel cible : extraire les informations, vérifier la conformité, valider ce matériel, voire anticiper les besoins d’installations et mettre en œuvre les processus adéquats.

Cette nouvelle version, sortie aujourd’hui, ajoute la possibilité d’extraction et d’envoi du rapport par le réseau.

Sommaire

• Visualisations
• Supports disponibles
• Création d'une clef USB
• Exportation réseau
  • Le dump
  • Intégration : triviale et rapide
  • Exemples d’usage
• Mise à jour des infos pour HDT
• Conclusion
• Syslinux & Kernel

Hardware Detection Tool (HDT) liste de multiples informations :

• Processeur
• Mémoire (e820, e801, 8800h)
• Bus PCI
  • Carte mère
  • BIOS
  • Chassis
  • Module Mémoire
  • CPU
  • Système
  • Sécurité du système
  • IPMI
  • Batterie
• Disques durs
  • Section du MBR
  • Détection de bootloader
  • Identification de swap
• Ainsi que la détection des modules noyau

Visualisations

Le « Menu Mode », une interface graphique permettant une navigation aisée, à l’aide des flèches directionnelles, dans la totalité des informations. Différents modes de CLI — interface en ligne de commande — permettent d’avoir le résumé des informations, mais aussi d’interroger type par type, et cela pour les modes d’affichage TEXT et VESA.

Par exemple, ici, une vue sur l’interface graphique, pour une carte réseau :

Qemu 8139 RealTek

Et ici, une vue de la CLI, en mode VESA, pour l’ACPI :

Qemu acpi

Supports disponibles

• Image de disquette 1,44 Mio
  
• Image ISO amorçable
  
• Module COM32 pour SYSLINUX

Création d'une clef USB

À noter que l’utilisation de HDT peut également s’avérer pratique pour le particulier, afin de jeter un œil de manière précise sur le matériel convoité (les informations pertinentes étant souvent absentes des étiquettes, pourtant souvent indispensables à tout geek sourcilleux sur son achat). Cet usage sera également utile lors d’install parties. Pour l’utiliser simplement, voici les instructions :

• récupérez l’image de CD amorçable ;
• rendez‐la « hybride » : « isohybrid --partok hdt-0.5.0.iso » ;
• copiez‐la sur votre clef USB : « dd if=hdt-0.5.0.iso of=/dev/sdc » ;
• Et hop, dans la popoche la clef HDT :).

Exportation réseau

Le dump

HDT 0.5.0 propose désormais l’exportation des informations au travers du réseau. Cette exportation se fait sous la forme d’une archive tar compressée gzip contenant plusieurs fichiers : chaque fichier correspondant à une partie du dump, soit processeur(s), DMI, ACPI, PCI, mémoire, disques, VESA... Ces fichiers sont formatés au standard JSON, permettant un traitement facile et efficace, quels que soient les outils choisis.

Intégration : triviale et rapide

Ce court résumé se place dans la configuration la plus simple : celle d’une machine unique servant à la fois de serveur DHCP, de serveur TFT, ce dernier étant unique, sans restrictions sur les adresses MAC, ni configuration particulière. Il devrait permettre à tous de tester facilement, tout en apportant les informations utiles pour l’intégration de HDT dans des systèmes complexes existants.

• Créez un répertoire nommé « hdt » à la racine de votre serveur TFTP (par exemple : « /tftpboot/hdt/ »).

• Renseignez le fichier default du service TFTP afin qu’il pointe vers les modules COM32 de HDT :
  
  Le fichier default est le bon choix : toutes les machines inconnues seront automatiquement enregistrées (numéros de série, identifiants matériels, etc.) sans impacter les machines connues, qui bénéficient certainement de fichiers de configurations distincts nommés en fonction de chaque adresse MAC.

LABEL HDT

kernel hdt.c32 auto='dump'

C’est ici qu’il faut définir les informations à extraire, en spécifiant les options idoines, en utilisant la directive « auto= » ici « \'dump\' », afin d’automatiquement envoyer les informations extraites sur le serveur TFTP. Par défaut, c’est le même serveur que celui utilisé précédemment, c’est donc ici également que vous pourrez placer la directive « tftp_ip= », s’il faut envoyer ces informations sur un serveur tiers. C’est également ici qu’on pourra prendre soin d’utiliser la directive de reboot après celle de dump :p.

• Utilisez les fichiers dump :
  

zcat <filename> | cpio -id

Illustration : résultat de traitement sur un dump :


"vesa.product" : "Intel(r) 82945GM Chipset Family Graphics Controller"
"cpu.model" : "Intel(R) Atom(TM) CPU N270 @ 1.60GHz"
"dmi.system.serial" : "LUS030A073826166682500"


Là, on pourra faire en sorte de créer des dossiers correspondant à chaque machine, y placer l’extraction, puis lancer un traitement tiers se servant des informations récupérées.

Boot de hdt.c32 par le réseau, sur un client :
pxe boot

Ici, ce client vient d’envoyer sa configuration :
dump on lan

Exemples d’usage

Cette nouvelle fonction de HDT prend dès à présent en option l’adresse IP de votre choix comme serveur TFTP. Ceci permet, dans le cas d’un réseau dense, d’envoyer les fichiers ailleurs que sur le serveur TFTP indiqué par le serveur DHCP, et permet donc une meilleure granularité dans le traitement des tâches dévolues à chaque service, à chaque machine, lorsque c’est nécessaire dans votre réseau. On pourra, par exemple, imaginer un serveur DHCP central indiquant le serveur TFTP nommé « install » ayant en défaut pour toute adresse MAC inconnue un envoi de hdt.c32 avec la directive tftp_ip qui envoie vers le serveur nommé « asset », lui‐même chargé de recueillir toutes les informations matérielles, précises et réelles, sur les nouvelles machines. Luxueux, n’est‐ce pas ?

L’administrateur système pourra aller plus loin encore, en traitant ses informations au fur et à mesure, afin d’aiguiller automatiquement un type d’installation en fonction du modèle et du matériel, dans un système d’installation préparé pour cela. Ainsi, au lieu d’avoir besoin au préalable des informations telles que « mac_address liée à type_installation », il devient possible de distinguer automatiquement un portable d’une station de travail ou d’une machine serveur, sans jamais avoir vu « la couleur de la machine » auparavant (et plus finement encore, selon la complexité de vos installations automatiques)... Le gain de temps et de main d’œuvre devient très intéressant.

Mise à jour des infos pour HDT

Pour terminer, HDT utilise les fichiers pci.ids, modules_alias et modules_pcimap. Il est capable de prendre ces fichiers en externe via les directives correspondantes. Par exemple, « pciids=path_to_file ». Il sera simple d’avoir cette base toujours à jour pour HDT.

Il est également possible de tester une même machine, avec plusieurs fichiers venant de plusieurs versions différentes de systèmes... Par exemple, pour savoir si telle machine n’aura pas de problème majeur avec telle version de tel système... Il est également possible d’envisager une extraction d’informations tierces de ces fichiers, afin de faire un traitement pour une création automatique du nom du fichier initial vide, dont HDT a besoin dans l’arborescence « path_tftp/hdt/ ». Mais ici, il serait plus simple d’avoir simplement des fichiers dont les noms sont les adresses MAC, pour un traitement automatique et immédiat suivant l’extraction d’informations. ;)

Conclusion

Hardware Detection Tool remplit diverses fonctions utiles à divers besoins :

• avoir toujours dans la poche de quoi regarder avec précision un matériel ;
• enregistrer tout matériel effectuant des requêtes sur le serveur PXE ; non seulement son adresse MAC, mais aussi ses numéros de série, permettant ainsi de lancer une procédure automatique ;
• renseigner avec ces informations auprès d’un serveur d’asset, ou une feuille de calcul, immédiatement et à bas niveau, permettant également de lancer une procédure automatique ;
• affiner une solution d’installation par le réseau, en la rendant plus autonome en temps et en intervention humaine.
  

À vous d’en faire l’usage correspondant à vos besoins et / ou améliorant vos systèmes.

Syslinux & Kernel

HDT étant un module pour Syslinux, son intégration se fera dans le prochain Syslinux. L’hébergement étant assuré par kernel.org. Puis, il rejoindra naturellement toutes les distributions GNU/Linux dans leurs empaquetages respectifs de Syslinux.

HDT est distribué sous licence MIT.

Aller plus loin

• Site Web du projet (807 clics)