L`université de Marne-La-Vallée - Centre de Ressources Informatiques

Université de Marne-la-Vallée
Centre de Ressources Informatiques
Rapport de stage
Maitrise Informatique
L.I.A.M.
Logiciel d'Inventaire Automatisé des Machines
Auteur :
Date :
Maître de Stage :
Période de Stage :
Stéphane LECLERCQ
27 juin 2003
Dragan CVIJETIC
Du 7 avril 2003 au 7 juillet 2003
1 PRÉSENTATION DE L'ENTREPRISE...................................................1
1.1 L'université de Marne la Vallée :................................................................................................1
1.2 Le Centre de Ressources Informatiques :..................................................................................2
1.2.1 Organisation : ...................................................................................................................................................2
1.2.2 Mon rôle au sein du C.R.I. : .............................................................................................................................3
2 LOGICIEL D'INVENTAIRE....................................................................5
2.1 Introduction à LIAM :...............................................................................................................5
2.1.1 Pourquoi un logiciel d'inventaire ?. : ...............................................................................................................5
2.1.2 Le logiciel LIAM. : ............................................................................................................................................5
2.2 Moyens mis à disposition :.........................................................................................................6
2.3 Répartition du travail de développement :.................................................................................7
3 FONCTIONNEMENT DE LIAM.............................................................8
3.1 Fonctionnement général :...........................................................................................................8
3.2 Le module PAR :.......................................................................................................................9
3.3 Fonctionnement de MakeLIAM :.............................................................................................10
4 LES INFORMATIONS REMONTÉES PAR LE CLIENT LIAM.........12
4.1 Client LIAM Linux :................................................................................................................12
4.2 Client LIAM Macintosh :.........................................................................................................21
4.3 Client LIAM Windows :...........................................................................................................24
5 LA PROCÉDURE D'INJECTION DE LIAM.........................................26
5.1 Le collecteur de mails :............................................................................................................26
5.2 Les informations traitées par l'injecteur LIAM :......................................................................27
5.3 L'injection en base de données :...............................................................................................30
6 LA BASE DE DONNÉES LIAM...........................................................32
7 LE FRONTAL WEB LIAM-VISUAL....................................................34
7.1 Le Frontal :...............................................................................................................................34
7.2 DBIX : Interfacage Frontal - Base de données :......................................................................37
8 CONCLUSION SUR LE STAGE...........................................................39
ANNEXE A : GLOSSAIRE.......................................................................40
ANNEXE B : DTD LIAM..........................................................................41
1 - PRÉSENTATION DE L'ENTREPRISE
1.1 - L'université de Marne-La-Vallée
L'université de Marne-La-Vallée a été mise en place dans le cadre du plan « UNIVERSITE
2000 », initié par le ministère de l'éducation nationale. Elle existe depuis 1989 en tant qu'antenne
délocalisée de PARIS VII (JUSSIEU). Elle est devenue autonome en 1991. Elle est composée d'un
pôle universitaire pluridisciplinaire comprenant filières classiques et formations par apprentissage,
d'un Institut Universitaire de Technologie (IUT) ainsi que d'instituts dédiés à la recherche. Elle jouit
d'infrastructures modernes tant sur le plan des moyens techniques que des locaux. Elle compte
actuellement près de 10 000 étudiants répartis dans une centaine de filières gérées par un personnel
administratif de plus de 200 personnes et environ 400 enseignants.
L'université est répartie géographiquement sur quatre sites :
•
•
•
•
les 8 bâtiments du site de la cité Descartes,
l'IUT de Meaux,
le STAPS et le Centre de télétravail à Coulommiers,
et depuis septembre 2002 le second pôle de l'université à Serris / Val d'Europe.
1
L'université s'est dotée en 1997 d'un Centre de Ressource Informatique, le CRI, où sont
regroupés la quasi-totalité des employés informaticiens mis à part trois collègues détachés à
l'IUT. Avec un parc informatique constitué de plus de 2000 postes, l'université de Marnela-Vallée est l'une des universités les plus informatisées de France.
1.2 - Le Centre de Ressources Informatiques
Le rôle du CRI est d'assurer le développement cohérent des moyens informatiques, du réseau
et des systèmes d'information, de veiller à la disponibilité des ressources matérielles et logicielles
ainsi que de garantir la sécurité réseaux.
D'un point de vue administratif, le CRI a le statut de service commun, c'est à dire qu'il
intervient indépendamment de toute entité que ce soit pour un service administratif (service financier,
scolarité), une composante pédagogique (UFR, institut, etc.) ou encore pour les laboratoires de
recherche.
1.2.1 - Organisation
Le CRI compte aujourd'hui 26 informaticiens répartis principalement en quatre équipes :
•
le service "systèmes, réseaux et micro", chargé de l'administration :
• des serveurs transversaux (DNS, Mail, News, accès distant, WEB, et gestion cache,
FTP public )
• du réseau (matériels actifs, câblage, routeurs et politique d'accès, sécurité)
• des serveurs généralistes (gestion des comptes, applications de gestion administrative
et documentaire)
• des serveurs de calcul - des serveurs dédiés aux enseignements)
De pair avec l'équipe systèmes et réseaux, l'équipe micro assure l'installation, la
configuration et la maintenance des postes clients et imprimantes (environ 2000 postes installés à
l'université), ainsi que le câblage local des salles et bureaux.
•
le service informatique de gestion, chargé de la mise en oeuvre et du suivi des applications
de gestion pour les domaines administratifs et pédagogiques :
•
•
•
•
•
finances et comptabilité : progiciel national NaBuco
paie sur budget propre : progiciel national Sigagip
personnel : progiciel GVRH (Virtualia)
maintenance des locaux ou GMAO : progiciel SAM (SITEalpha)
scolarité : progiciel national APOGEE
et applications en intranet pour la logistique interne au fonctionnement du CRI (gestion des
interventions du CRI, suivi du parc micro-informatique)
•
l'équipe informatique documentaire pour le Service commun de la documentation :
• catalogage des bibliothèques
• bases Current Contents, Diane, Inspec, WAIS
• PELLEAS : projet XML pour le système d'information documentaire du
Polytechnicum de Marne-la-vallée
2
•
•
Cyberthèses pour la numérisation des thèses et mémoires des étudiants
le service téléphonie, chargé de l'administration des commutateurs PBX et des infrastructures
de réseau vocal
Organigramme du CRI
Tous les locaux du CRI sont situés au même étage du même bâtiment. Ils sont composés de
plusieurs bureaux ainsi que d'une grande salle où cohabitent les membres de l'équipe systèmes,
réseaux et micro. Cette configuration spatiale favorise beaucoup la communication entre les
différents membres des équipes.
1.2.2 - Mon rôle au sein du CRI
Mon maître de stage pour cette periode de trois mois fut M. Dragan Cvijetic, Ingénieur
Système de l'équipe réseaux et chargé du développement en Ressources systèmes. Les activités de
cette équipe font appel à un certain nombre de domaines de compétence parmi lesquels on retrouve :
•
•
•
l'optimisation et le développement des infrastructures et ressources,
maintenance des services (mail, DNS, web, etc.),
la maintenance du parc ainsi que de l'infrastructure réseau déjà en place.
Concernant ce dernier point, il faut souligner que travailler dans une université et plus
particulièrement au CRI, c'est aussi un réel travail de communication. Les membres du CRI sont les
seuls interlocuteurs techniques au niveau informatique au sein de l'université, de ce fait ils sont en
relation directe avec les usagers. Le CRI organise une permanence le midi du lundi au vendredi afin
de répondre aux questions et problèmes des étudiants. Les administratifs disposent quant à eux d'un
outil accessible depuis le site Internet de l'université qui leur permet d'envoyer des Demandes de
3
Travaux (DT). Parmi les problèmes les plus souvent rencontrés on trouve :
•
•
•
•
les problèmes de configuration logicielle (par ex. configuration de Netscape),
les problèmes liés au système (par ex. oubli de mot de passe),
les problèmes liés aux matériels (par ex. disque dur en panne),
les problèmes liés à l'exploitation de l'infrastructure réseau (par ex. panne réseaux dans
un bâtiment).
Par ailleurs, le CRI assure un service de "help desk" pour les demandes de dépannages
urgents et de préparation de devis informatiques. Le CRI intervient aussi bien au niveau matériel que
logiciel.
Après une intégration rapide au sein de l'équipe réseaux, systèmes et micro j'ai abordé avec
mon binome la mise en place du projet de stage. Celui-ci consiste à créer un logiciel d'inventaire
permettant d'automatiser la gestion du parc informatique et de construire la base de données
associée.
4
2 - LOGICIEL D'INVENTAIRE
2.1 – Introduction à LIAM
2.1.1 – Pourquoi un logiciel d'inventaire ?
Le C.R.I. avait besoin d'un moyen pratique pour suivre l'état du parc informatique de
l'Université. Il y a plus de 2000 machines réparties entre Marne la Vallée et le Val d'Europe et il est
actuellement impossible de toutes les répértorier à la main. L'avantage d'un lieu commun de
réferencement des machines est double :
• pour le C.R.I., savoir par exemple quelles sont les machines de plus de 5 ans, ou quelles
sont les machines qui ont moins de 128Mo de RAM (pour eviter d'installer un système
d'exploitation Windows XP sur une machine n'ayant pas assez de mémoire).
• pour les enseignants, pouvoir obtenir facilement la liste des salles informatiques où l'on
peut trouver un logiciel particulier installé sur toutes les machines, afin de mener à bien
leurs Travaux Dirigés.
L'année derniere, un apprenti de la filière Ingénieurs 2000 a commencé à travailler sur le
logiciel d'inventaire, mais les besoins exacts n'étaient pas encore établis, ni les fonctionalités prévues
et la façon dont elles devaient être implémentées. En conséquence, beaucoup de documentation et de
séléction sur différentes approches du problème ont été faits, mais aucun développement n'a abouti
par manque de temps.
Cette année, le C.R.I avait une idée très précise des besoins devant être implémentés dans un
logiciel d'inventaire, et nous avons pu commencer à développer très rapidement et à nous concentrer
sur les difficultés techniques.
Un besoin essentiel est notamment de pouvoir automatiser au maximum la procédure
d'inventaire car il est illusoire dans la pratique de mobiliser une personne pour renseigner et tenir à
jour une base de données sur l'inventaire nombreuses machines du campus. Le logiciel doit être
automatisé et demander le moins d'intervention humaine possible pour être exploitable par le C.R.I.
Le logiciel doit être scindé en quatre parties :
• un logiciel client permettant de faire l'inventaire de la machine sur laquelle il est.
• un serveur de clients pour les differents systèmes d'exploitation supportés par le logiciel
d'inventaire.
• un moteur d'inventaire qui traite les données des clients, et met à jour une base de
données contenant tous les inventaires reçus.
• un frontal Web permettant de consulter la base de données inventaire et d'obtenir des
informations rapidement et simplement.
2.1.2 – Le logiciel LIAM.
Ce projet a été baptisé LIAM (pour Logiciel d'Inventaire Automatisé des Machines). Il
consiste à établir pour chaque machine (le client) la liste du matériel présent ainsi que la liste des
logiciels installés plus un certain nombre d'informations complémentaires telles que le modèle ou
encore le numéro de série de la machine.
LIAM doit être automatisé dans le sens où il n'est pas nécéssaire de se déplacer
physiquement pour effectuer l'inventaire des machines, ni d'entrer à la main toutes les informations
concernant le parc informatique.
Ces informations, une fois collectées, seront envoyées par le client vers un serveur
« intelligent » qui se chargera d'effectuer toutes les opérations précédant l'insertion en base. Cette
5
dernière sera du reste une base de données standard (PostgreSQL). Cette dernière pourra être
exploitée par une interface sous forme de pages web. Un des objectifs principaux du projet est de
pouvoir exécuter ce programme sur les trois principales catégories de systèmes d'exploitation
composant l'ensemble du parc informatique de l'université, à savoir Windows, Linux et Mac.
Une première phase de ce projet consistait à étudier différents logiciels d'inventaire afin de se
faire une idée sur la marche à suivre ainsi que sur les aspects qualitatifs et quantitatifs des résultats à
produire. L'écriture d'un logiciel d’inventaire interne au CRI est justifiée pour deux raisons
principales :
•
•
nous avons un cahier des charges précis et aucun des logiciels testés n’y répond de façon
adéquate,
les logiciels proposés sur le marché sont souvent trop chers, sachant qu'une licence
d'utilisation est nécéssaire pour chaque marchine du parc.
Les différents logiciels testés, une dizaine au total, avaient déjà été sélectionnés pour la plupart par
les membres de l'équipe micro. Parmi ces logiciels on trouve OCS Inventory Manager, Advisor de
Belarc ou encore Network INventory nAvigator (NINA) d'Alloy Software. De la phase de test,
réalisée exclusivement sous Windows, il est ressorti que ces logiciels tenaient leurs informations en
grande partie de la base de registre. Cependant, en particulier pour l'inventaire matériel, ils
effectuaient vraisemblablement des tâches supplémentaires telles qu'un parcours du disque dur ou
encore l'interrogation du BIOS.
2.2 - Moyens mis à disposition
Afin de mener à bien le stage et le bon développement de LIAM, le C.R.I. nous a mis à
disposition un PC de développement Windows pour la version Windows du client, et deux PC de
développement Linux pour le client Linux, le BootStrap, l'injecteur, les serveurs SQL et Web. Un
Macintosh s'est ajouté lors du deuxième mois de stage pour développer et tester le client Mac.
Toutes ces machines sont en acces complet (administrateur, super utilisateur).
Certaines machines de développement de membres consentants du C.R.I., ont servi de banc
d'essai pour les premières versions du client, afin de corriger les bugs les plus importants et de
s'assurer que LIAM ne provoque pas de problème sur une machine sur laquelle il n'arrive pas à finir
son inventaire pour une raison quelconque. Enfin, des accès restreints ont été ouverts sur les
serveurs de l'Université pour déployer le client LIAM afin d'avoir un bon échantillon du parc
informatique du campus et affiner la qualité du traitement des informations diverses récupérées.
Le C.R.I. a été très à l'écoute de nos besoins de développement et réactifs aux problèmes
rencontrés avec les systèmes, notamment au niveau des droits et éspaces nécéssaires sur les serveurs
Web tels que le serveur étudiant, et un climat de confiance s'est rapidement installé à ce niveau. Nous
avions un espace de sauvegarde en cas de problème critique avec une machine de développement, ce
qui est arrivé un lundi matin. La encore le C.R.I. a été très rapide et une nouvelle image a été
réinstallée et configurée en moins d'une heure. De nombreux livres sur les sujets divers abordés par
LIAM étaient également disponibles.
Les conditions matérielles et logicielles du stage ont donc été optimales et ont permis une
réalisation rapide des premières versions tests des clients, ainsi qu'un déploiement sur des serveurs de
l'Université en quelques heures dès lors que les clients avaient atteint une stabilité raisonnable.
6
2.3 - Répartition du travail de développement
Mon binôme, Julien Lesaint, et moi même sommes développeurs de LIAM. Nous avons pu
répartir les tâches à notre convenance, ce qui a acceleré le développement général car puisque nous
travaillons depuis plus de 4 ans en binome, nous connaissons les domaines de prédilection de chacun.
Lors de la première semaine nous avons programmé des clients/serveurs de bootstrap et mail
temporaires en Perl. Je m'occupais de la partie serveur pour toutes les tâches et Julien de la partie
client.
Ensuite, nous avons procédé au développement des clients Linux et Windows. Julien à
développé le client Windows tandis que je programmais la version Linux. Le client Windows étant
plus long à développer (notemment concernant l'inventaire des logiciels Windows), j'ai crée la DTD
pour les données XML à partir de celle de l'année dernière, globalement en simplifiant le format des
données pour le rendre plus facilement maintenable, puis j'ai programmé le moteur d'injection. Julien
a crée le script de déploiement « MakeLIAM » permettant la création rapide d'archives contenant des
exécutables LIAM pour le redéploiement d'une nouvelle version, puis a pris en charge le serveur
Web définitif avec la création du Frontal, et je me suis occupé de la mise en place et administration
du serveur de Base de Données et des scripts d'interfacage Frontal / Base de Données. Le design de
la base de données a été repris de celui de l'année dernière, en le simplifiant comme pour la DTD et
dans le même but. La mise en place du Macintosh m'a permis de créer le client Mac mais des
contraintes techniques et la priorité basse pour le C.R.I. de cet ajout à LIAM n'ont permis que
d'implémenter qu'un support préliminaire pour cette plateforme (voir section client Macintosh).
Il est important de noter que chacun avait droit de regard sur les scripts de l'autre et que le
travail en commun était favorisé par l'interaction constante des différentes parties de LIAM. Notre
tuteur Dragan Cvijetic a participé activement a l'élaboration de certaines parties, et a notamment crée
un script permettant d'ajouter les dates d'achat des PC de marque « DELL » dans la base de données
à partir de leur numéro de série. L'ensemble du personnel du C.R.I. a montré un interêt et un
enthousiasme croissant pour LIAM au fur et à mesure de son développement et ont apporté de
nombreuses critiques, idées et conseils.
7
3 - FONCTIONNEMENT DE LIAM
3.1 - Fonctionnement général
LIAM est un logiciel complexe non pas par son fonctionnement interne mais par la mise en
oeuvre de nombreux protocoles et modules devant coexister et communiquer ensemble. Les clients
seuls n'apportent rien de mieux que ce que d'autres projets Open Source proposent, l'Injecteur, la
base de données, le support XML, le serveur web, les mails et autres aspects plus techniques de
LIAM ne sont d'aucune utilité s'ils ne sont pas ensembles. Je vais décrire succintement le rôle de
chacun des modules intervenant dans le fonctionnement de LIAM, puis reprendre pas à pas en
détaillant plus chaque partie. Ce rapport ne se voulant pas être une documentation technique, les
détails internes aux langages et protocoles ne seront pas, ou brièvement évoqués.
HTTP POST
BootStrap
application/x-zip
Win32Liam.zip
ou
LinuxLiam.zip
Serveur HTTP
unzip liam.zip
exec client LIAM
inventaire. xml.gz
SMTP
[email protected]
Serveur mail
Fonctionnement du BootStrap et Client LIAM
Le lancement de LIAM sur toute plateforme est effectué par un « BootStrap ». C'est un
client générique et simple. A son lancement, il décompresse les fichiers necessaires à son execution
(voir module PAR), il fait une requète HTTP sur le serveur Web sur lequel se trouvent les clients
LIAM, grâce au module HTTP::Request. Selon la nature de la requête (contenant en postdata le
nom du système d'exploitation sur lequel est le BootStrap), le serveur Web envoie le bon client
LIAM à la machine : Windows, Linux ou Macintosh. Ce client est compressé pour minimiser
l'occupation du réseau.
A sa réception, le BootStrap décompresse le client LIAM dans un dossier temporaire, puis le
lance en lui passant la main (le BootStrap stoppe son execution au moment où le client se lance). Le
client LIAM décompresse à son tour les fichiers nécessaires à son exécution, puis (sous Linux
8
uniquement) positionne des variables d'environnement conernant la langue du système avant
d'effectuer son inventaire.
Au fur et à mesure de l'inventaire, une hashmap attachée à un fichier XML se construit à
l'aide du module XML::Simple. A la fin de la procédure, LIAM compresse le fichier XML crée avec
le module Compress::Zlib, puis l'envoie par mail au serveur avec le module Mail::Sender. Enfin,
LIAM nettoie les fichiers et dossier qu'il a crée dans le dossier temporaire.
Côté serveur, l'administrateur lance un autre script LIAM, l'Injecteur, dont le rôle est de
récuperer les mails envoyés par les clients, de décompresser et traiter leurs fichiers XML avant
d'injecter les informations dans la base de données LIAM. Ce script est toujours lancé à la main, car
son temps d'execution est beaucoup plus long que celui des clients (ce qui est intentionnel puisque le
minimum de traitements d'informations est placé coté client). Un autre script permet d'ajouter les
dates d'achat des PC « DELL » dans la base de données, il est à part car le site DELL envoie des
cookies lors d'une demande, et il est nécéssaire d'attendre deux secondes entre chaque requète sur le
site ce qui augmente grandement le temps de traitement lorsque beaucoup de PC doivent être traités.
Enfin, l'utilisateur final peut acceder à LIAM via un frontal Web interfacé avec la base de
données. Le Frontal est entièrement dynamique et aucune donnée n'est mise en cache sur le serveur.
Je vais maintenant expliquer le principe du module « PAR » permettant de créer des binaires
executables à partir de scripts Perl, ainsi que de MakeLIAM qui est un outil aidant au déploiement,
puis reprendre chaque point de ce survol du fonctionnement de LIAM et les détailler avec plus de
précision. Les parties que j'ai développé seront evidemment plus détaillées que celles qui ont été
crees par mon binôme.
3.2 - Le module PAR
Un des problèmes posés par LIAM et l'utilisation du langage Perl est son comportement sur
les machines clientes. Le problème est le suivant : les scripts Perl ont besoin d'un interpréteur pour
fonctionner, or, même s'il est très répandu, il n'est pas systématiquement présent sur les machines
Linux. Pire encore, sous Windows il est très rarement installé si l'utilisateur n'est pas lui-même un
développeur Perl. Il est utopique de penser à installer sur l'ensemble du parc informatique des
logiciels tels qu'ActivePerl pour pouvoir executer les scripts, surtout sur les machines administratives
qui sont indépendantes. L'année dernière le peu de développement sous Perl, ainsi que l'absence du
module PAR n'avaient pas permis de résoudre ce problème.
PAR est un croisement entre un compilateur et un wrapper Perl. Il permet d'inclure dans un
exécutable un interpreteur Perl, les modules nécéssaires à l'exécution du ou des scripts concernés,
ainsi qu'un système automatique de décompression et d'execution de ces derniers.
Le principal attrait est que l'on peut alors se passer de l'installation d'un interpréteur Perl sur
la machine cliente. Il faut toutefois noter que malgré la stabilité de PAR, surtout comparé à
« perlcc » (le compilateur « standard » de Perl) qui ne fonctionne quasiment jamais, il n'est pas
exempt de bugs. Les modules incluant des sous modules dans leurs propres sources sont souvent mal
interpretés et PAR cherchera ce sous module dans un sous dossier du module (qui n'existe bien
evidemment pas), produisant une erreur.
9
Script Perl .pl
Modules
PAR
Executable
Interpreteur Perl
Principe de fonctionnement de PAR
D'autre part, sous Linux l'interpreteur Perl est compilé et lié dynamiquement avec certaines
librairies, ces librairies peuvent être incluses dans l'archive client de LIAM mais une condition reste
impérative pour que le client LIAM puisse s'executer : La version de la librairie « C » doit être la
même sur la machine de développement et sur les serveurs où elle est deployée, sinon l'interpreteur
produit une erreur au moment de son lancement. Cela a posé un problème pour Linux, et
actuellement une version de LIAM est disponible en mode binaire pour les serveurs Linux possédant
la même version de la librairie C que la machine de développement, et une version script uniquement
sur les serveurs possédant Perl mais dans une autre version de la librairie C.
Bien qu'imparfait, PAR a été un outil décisif dans le déploiement de LIAM sur le parc de
machines Windows de l'Université. Il suffit de compiler le client LIAM Windows ou Linux avec PAR
et de le mettre sur le site Web appelé par le BootStrap à son exécution, son déploiement est alors
immédiat pour l'ensemble du parc.
Nous espérons qu'une prochaine version de PAR permette le choix d'une version de
l'interpréteur Perl (compilée avec la bonne librairie C) pour pouvoir déployer facilement de nouvelles
version de LIAM sur des serveurs Linux différents.
3.3 - Fonctionnement de MakeLIAM
MakeLIAM est un script Perl permettant de créer rapidement les archives et exécutables
nécéssaires au déploiement de LIAM, quelle que soit la machine sur laquelle il est lancé. Il
fonctionne sous trois modes.
- Le mode « bootstrap » avec l'option -boot : MakeLIAM passe le script du BootStrap à
PAR puis eventuellement crée un petit script bash (pour Linux) afin de positionner les variables
d'environnement pour lancer le BootStrap.
- Le mode « exécutable » : C'est le comportement par défaut, MakeLIAM passe le script du
client concerné (en reconnaissant le système d'exploitation sur lequel il est) à PAR pour créer le
client exécutable d'un système d'exploitation.
- Le mode « all » avec l'option -all : Le mode « all » se comporte comme le mode par défaut,
et en plus place l'exécutable ainsi que tous les programmes nécéssaires au fonctionnement du client
dans une archive zip prête à être déployée sur le serveur Web.
10
Machine Linux
développement
Machine Windows
développement
BootStrap
Windows
BootStrap
Linux
MakeLiam
Déploiement Windows
Déploiement Linux
Fonctionnement de MakeLIAM, mode -boot
Dev. Windows
(MakeLiam)
Dev. Linux
(MakeLiam)
Win32liam.exe
Programmes annexes
Fichier de configuration
LinuxLiam (binaire)
Programmes annexes
Fichier de configuration
MakeLiam
Win32liam.zip
LinuxLiam.zip
Serveur de clients (HTTP)
Fonctionnement de MakeLIAM, mode -all
11
4 - LES INFORMATIONS REMONTÉES PAR LE
CLIENT LIAM
Les informations sur les machines clientes qui peuvent être obtenues et envoyées par LIAM
sont nombreuses. Elles ont été classées par catégories pour plus de clareté et de portabilité. Sous
Linux, la récupération de ces informations se base sous Linux en grande majorite sur le système de
fichiers /proc, et sous Macintosh entièrement sur la commande « AppleSystemProfiler ». L'objectif
pour LIAM est d'être dépendant du minimum de programmes externes possibles pour améliorer la
portabilité et la rapidité du code et homogéniser les informations récupérées plus facilement. Un
programme externe peut donner sa propre interprétation des informations brutes du système et nous
ne voulons pas cela.
4.1 - Client Liam Linux
LIAM est actuellement dépendant de deux programmes externes pour la récupération des
informations système et hardware : « dmidecode » qui permet d'accéder au BIOS et est
incontournable car les informations sont supposées impossible à récupérer uniquement avec Perl.
J'utilise aussi « ifconfig » pour obtenir les adresses MAC et IP des cartes réseau sous Linux. Après
étude des fichiers sources de « ifconfig » j'ai pu constater que l'obtention de ces adresses passaient
par la création d'une ou de plusieurs sockets et d'appels système sur celles ci afin d'obtenir leurs
caractéristiques. Une prochaine version de LIAM pourra donc utiliser des sockets pour obtenir
directement ces informations plutôt que d'utiliser un programme externe.
Un point important à noter est que LIAM fixe des variables d'environnement sous Linux afin
d'avoir le langage de base de la machine et non la langue francaise lorsqu'elle est mise par defaut. Le
but est de pouvoir utiliser LIAM sur un système de langue quelconque sans devoir créer une version
par langue (notemment pour les regexp). Les variables positionnées sont :
$LC_ALL
$LANG
$LANGUAGE
Elles doivent etre toutes positionnées à « C » pour avoir le langage anglais par défaut. Cela
permet d'avoir par exemple «Interrupt:5 Base address:0xec80 » au lieu de
« Interruption:5 Adresse de base:0xec80 ».
Nous avons divisé les informations envoyées en plusieurs sections afin d'améliorer la clareté
et de pouvoir maintenir le programme plus facilement au fur et à mesure des modifications ou ajouts
nécessaires. Pour ordonner ces informations et les sortir sous format XML, nous utilisons le module
XML::Simple qui permet de lier une hashmap à un fichier XML, quel que soit le sens de la
conversion. Pour chaque partie de recherche nous envoyons une partie de l'arborescence de la
hashmap. Ces parties sont plus ou moins profondes (vers les feuilles) selon le type d'information
désiré. Le fichier XML suit une DTD (voir annexe B) et est de la forme suivante :
<inventaire>
<systeme>
<module_systeme>
<propriete_sys_1>information<propriete_sys_1>
<propriete_sys_2>information<propriete_sys_2>
12
...
</module_systeme>
...
</systeme>
<hardware>
<module_hardware>
...
</module_hardware>
...
</hardware>
<software>
<soft>
...
</soft>
</software>
</inventaire>
Nous allons maintenant étudier, partie par partie, les méthodes de récupération des
informations par le client LIAM.
•
Le chassis : Regroupe les informations relatives au chassis, généralement contenues dans
le BIOS de la carte mère de l'ordinateur. Nous utilisons un logiciel externe pour acceder
au bios : dmidecode. Il permet d'afficher les propriétés complètes et accessibles du
BIOS.
Si l'utilisateur n'est pas l'administrateur (root) au lancement de LIAM, le chassis ne sera
pas renseigné. Il est à noter que c'est un cas d'exception, le comportement par défaut de
LIAM étant de fonctionner sous droits administrateur.
Exemple d'information récupérée sur la machine de développement Linux :
Handle 0x0200
DMI type 2, 8 bytes.
Board Information Block
Vendor: Dell Computer Corporation
Product: OptiPlex GX110
Version:
Serial Number:
Handle 0x0300
DMI type 3, 13 bytes.
Chassis Information Block
Vendor: Dell Computer Corporation
Chassis Type: Space­saving
Version: (null)
Serial Number: LUQ85
Asset Tag: (null)
Cinq champs sont utilisés pour la représentation d'un chassis :
- name : Le nom de l'ordinateur, ici « OptiPlex GX110 »
- constructor : Le fabricant de l'ordinateur, ici « Dell Computer Corporation »
- serial : Le numéro de série de l'ordinateur, qui permet notamment de l'identifier dans la
base complète d'ordinateurs lorsqu'il est présent. Ici le numéro de série est « LUQ85 ».
Si ce numéro de série n'est pas renseigné ou lisible, la reconnaissance de la machine est
faite sur une combinaison de l'adresse MAC et de l'adresse IP de la machine (voir
informations Net).
- date_achat : La date d'achat de l'ordinateur. Ce champ n'est renseigné que pour les
ordinateurs DELL. A partir du numéro de série de l'ordinateur, une série de requètes sur
le site web de DELL est éffectuée pour obtenir sa date d'achat. Ceci est géré par un
13
script externe car le traitement prend du temps : Il est nécéssaire de placer un delai
artificiel de quelques secondes entre chaque requète au site DELL pour obtenir les
informations voulues. En outre, un module Dell::Sysinfo a été crée pour implémenter
cette fonctionalité de différentes façons et même en dehors de LIAM.
- fin_maintenance : La date de fin de maintenance de l'ordinateur. Ce champ doit être
rempli à la main car les durées de maintenance sont variables d'un ordinateur a un autre.
Le résultat sous format XML est de la forme
<chassis>
<constructor>Dell Computer Corporation</constructor>
<serial>LUQ85</serial>
<name>OptiPlex GX110</name>
</chassis>
•
Le bios : Les informations BIOS non relatives au chassis. Nous utilisons également
dmidecode pour afficher les propriétés du BIOS qui nous intéressent.
Handle 0x0000
DMI type 0, 20 bytes.
BIOS Information Block
Vendor: Dell Computer Corporation
Version: A07
Release: 03/29/2001
BIOS base: 0xF0000
ROM size: 448K
Capabilities:
Flags: 0x001F00007FE9DE90
Les informations du BIOS renseignent trois champs :
- type : Il peut y avoir uniquement deux types d'informations BIOS : Le BIOS système
qui est celui de la carte mère. Et le BIOS vidéo pour la carte vidéo lui étant associé.
Actuellement seul Windows permet de renseigner LIAM sur des BIOS vidéo, donc nous
nous contentons du BIOS de la carte mère sous Linux. En conséquence, ce champ est
systématiquement fixé a « systeme ».
- version : La version du BIOS étudié. Ce champ n'est pas toujours renseigné. Toutefois
sur la machine de développement c'est le cas et il vaut « A07 ».
- date : La date de la version du BIOS. Ce champ est systématiquement renseigné, même
lorsque la version du BIOS n'est pas présente. Il est donc possible de reconnaître un
même BIOS via son type et sa date (voir la partie Injection pour plus de détails). La
machine de développement donne pour date de BIOS : « 03/29/2001 ».
Cela donne sous XML pour la machine de développement
<bios type="system">
<date>03/29/2001</date>
<version>A07</version>
</bios>
A noter le type du BIOS mis en attribut plutot qu'en élément.
•
Les ide : Permet de reconnaître et avoir des détails sur tous les périphériques IDE
(Disques durs, lecteurs de disquettes, lecteurs zip, lecteurs de CD-ROM/DVD...). Les
informations sont remontées en utilisant l'arborescence sous Linux /proc/ide/*. Le seul
14
champ devant absolument être renseigné est le nom du périphérique IDE (voir ci-après).
Nous avons par exemple /proc/ide/hda représentant un disque dur. Les champs
disponibles sont :
- idename : Le nom du périphérique IDE. Sous Linux c'est le nom système du
périphérique (hda/hdb...). Nous récupérons donc chaque nom de sous dossier dans le
dossier /proc/ide.
- idetype : Le type du périphérique IDE. Cette information est extraite à partir du
fichier /proc/ide/***/media dont le contenu est un mot unique représentant ce type de
média. Cela peut être un disque dur « disk », un lecteur de CD-ROM « cdrom », un
lecteur de disquettes « floppy », etc.
- ideinfo : Généralement le modèle du périphérique IDE. Cela peut être aussi d'autres
informations a son sujet et cela varie selon le constructeur. Le champ peut aussi être
omis par le constructeur. Sous Linux, nous étudions le contenu du fichier /
proc/ide/***/model qui contient, sur une ligne, les informations du modêle du
périphérique IDE étudié. Sur la machine de développement le fichier /proc/ide/hda/model
a pour contenu « WDC WD75AA-75BAA0 ».
- idesize : La taille du périphérique IDE. Ce champ ne contient des informations
pertinentes que si le périphérique étudié est un disque dur (mais il n'est pas
systématiquement renseigné). Pour le remplir sous Linux nous utilisons le contenu du
fichier /proc/ide/***/capacity qui contient sur une ligne une valeur représentant la taille
maximale du périphérique en octets. Par exemple, pour le disque montré ci-dessus, le
fichier /proc/ide/hda/capacity contient « 14726880 ».
Un exemple de code XML produit par la récupération de ces informations pour un
périphérique IDE est :
<ide>
<idename>hda</idename>
<idetype>disk</idetype>
<idesize>14726880</idesize>
<ideinfo>WDC WD75AA­75BAA0</ideinfo>
</ide>
•
Les pci : Rassemble les périphériques PCI branchés sur le PC dont LIAM effectue
l'inventaire. L'ensemble des périphériques PCI sont détaillés sous Linux par le fichier /
proc/bus/pci/devices. Ce fichier contient une ligne par périphérique attaché. Le format de
chaque périphérique est :
0000 80862530 0 f0000008 00000000
00000000 00000000 00000000 00000000 00000000
08000000 00000000 00000000 00000000
00000000 00000000 00000000
Ce format paraît obscur au premier abord, mais la seule chose qui nous interesse est le
deuxième groupe de chiffres. Ce groupe 80862530 doit être scindé en deux parties :
Les quatre premiers chiffres 8086 qui représentent l'identifiant constructeur d'une carte
PCI, et les quatre derniers chiffres 2530 qui identifient le type de cette carte.
Ces groupes de chiffres, identificateurs, ne sont pas exploitables seuls par un humain,
mais ils sont suffisants pour que l'injecteur côté serveur puisse faire le traitement. Les
groupes de chiffres sont donc uniquement séparés et placés « tels quels » dans le fichier
XML afin de gagner de la place, ainsi que d'éviter que certains fichier nécéssaires à la
lecture de ces groupes de chiffres soient dans un endroit du système de fichiers inconnu
par le client. En plus de la normalisation effectuée à ce niveau, le client est plus rapide
15
car il n'a pas à traiter ces identificateurs.
La sortie sous format XML est de la forme :
<pci>
<pci_type_id>2530</pci_type_id>
<pci_vendor_id>8086</pci_vendor_id>
</pci>
et ce pour chaque périphérique PCI.
•
Les usb : Tout comme les périphériques PCI, la section USB regroupe les périphériques
USB mais aussi le support USB sur une machine. Ce dernier point est très interessant car
contrairement aux bus PCI qui existent sur quasiment l'ensemble des machines
d'aujourd'hui, le support des périphériques USB n'est pas toujours présent sur les
machines datant d'il y a plusieurs années.
Les périphériques USB ou bien le support de ces périphériques est décrit dans le fichier /
proc/bus/usb/devices. Bien que parallèle au fichier d'information pour les cartes PCI, ce
fichier a une syntaxe totalement différente. Ceci est un exemple de déscription pour un
périphérique (une souris optique) :
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5
MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=
1
P: Vendor=046d ProdID=c00e Rev=11.10
S: Manufacturer=Logitech
S: Product=USB­PS/2 Optical Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02
Driver=hid
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=10ms
Les autres périphériques sont décris par d'autres lignes se suivant, mais dont la
succession est toujours la même. Il est à noter cependant que même si l'ordre de la lettre
préfixe de chaque ligne est toujours le même, il peut y avoir un nombre différent de
lignes possédant un préfixe identique.
Les lignes qui nous intéressent pour LIAM sont les lignes commençant par « P », elles
contiennent en effet l'identifiant vendeur et le type de carte. Ici l'identifiant vendeur est
046d et l'identifiant carte est c00e. Les informations complémentaires concernant le nom
du vendeur ou de la carte ne sont pas conservées, car elles sont dépendantes de la
machine sur laquelle elles se trouvent. Dans un souci de normalisation des données nous
ne gardons que les identifiants standards et le traitement sera effectué au niveau de
l'Injecteur.
Le fichier XML peut contenir plusieurs entrées USB de la forme :
<usb>
<usb_type_id>0000</usb_type_id>
<usb_vendor_id>0000</usb_vendor_id>
</usb>
L'id 0000 / 0000 indique la présence d'un port USB, utile lorsqu'aucun périphérique USB
est branché (voir Injecteur pour le traitement de cette information).
16
<usb>
<usb_type_id>c00e</usb_type_id>
<usb_vendor_id>046d</usb_vendor_id>
</usb>
Cette deuxième entrée traduit la souris que nous venons de voir.
•
Les processeurs : LIAM supporte les systèmes multiprocesseurs, et la version Linux
n'échappe pas à cette règle. Trois informations sont remontées par processeur dans le
fichier XML créé par le client. Toutes sont issues du fichier /proc/cpuinfo et d'autres
pourront être ajoutées dans de prochaines versions de LIAM. Voici un exemple de
contenu du fichier /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping : 4
cpu MHz : 2405.502
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr
sse sse2 ss ht tm
bogomips : 4797.23
Il est assez facile d'extraire les informations de chaque processeur en lisant une
caractéristique par ligne jusqu'à retrouver un bloc commencant par « processor ». Les
informations les plus importantes et envoyées par LIAM sont :
- constructor : Le constructeur du processeur. Il est décrit sur la ligne « vendor_id ».
Cela peut etre Intel, AMD, Cyrix ou tout autre constructeur de processeur.
- info : Le modèle du processeur, correspondant à la ligne « model name ». On y
retrouve la catégorie du processeur (pentium, x86, alpha...), parfois à nouveau le
constructeur et parfois aussi la vitesse « annoncée » du processeur.
- speed : La vitesse constatée du processeur. Elle est mesurée au démarrage par le BIOS
et n'est pas forcément la même que celle annoncée par la ligne « model name ». Que le
processeur soit overclocké, underclocké, ou tout simplement déficient, les variations
peuvent être grandes.
Les autres informations données sur chaque processeur ne nous interessant pas
actuellement, le code XML produit par la récupérations de ces trois caracteristiques est,
pour chaque processeur reconnu, du type suivant :
<proc>
<procconstructor>GenuineIntel</procconstructor>
<procspeed>2405.502</procspeed>
<procinfo>Intel(R) Pentium(R) 4 CPU 2.40GHz</procinfo>
</proc>
17
•
La mémoire : Sous Linux, il n'est pas possible d'avoir le détail de chaque barette de
mémoire facilement, contrairement à Macintosh. Le fichier donnant les informations
intéressantes est /proc/meminfo. Son contenu est (par exemple) :
total: used: free: shared: buffers: cached:
Mem: 527691776 319037440 208654336 0 5902336
204873728
Swap: 1118597120 0 1118597120
MemTotal: 515324 kB
MemFree: 203764 kB
MemShared: 0 kB
Buffers: 5764 kB
Cached: 200072 kB
SwapCached: 0 kB
Active: 87324 kB
Inactive: 195984 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 515324 kB
LowFree: 203764 kB
SwapTotal: 1092380 kB
SwapFree: 1092380 kB
Seule la ligne « MemTotal » nous intéresse. A l'avenir, il sera possible d'utiliser d'autres
champs de ce fichier pour obtenir des précisions plus importantes sur la mémoire de
chaque machine ainsi que de son utilisation. Cette ligne permet de remplir les deux
champs du fichier XML produit par le client LIAM :
- ramsize : la taille totale de la mémoire vive dans le système.
- ramunit : l'unité de mémoire utilisée : ici « kB ». Elle est utile pour mettre en parallèle
des systèmes Windows et Linux car l'unité utilisée n'est pas la même d'une machine à une
autre.
Le XML produit a pour forme :
<memory ramunit="kB">
<ramsize>515324</ramsize>
</memory>
D'autres entrées « memory » peuvent évidemment décrire plusieurs barettes memoire. Un
système ne divisant pas la mémoire en plusieurs barettes verra son total mémoire
apparaître en tant que barette unique (voir la séction Injection – mémoire).
•
L'OS : Bien que nous sachions déjà sous quel OS le client est lancé, puisqu'il y a une
version différente pour Windows, Linux et Macintosh, il est pertinent de determiner sous
quelle version de l'OS on est. Sous Windows nous pouvons savoir si nous sommes sous
95, 98, NT, 2000, XP ainsi que le service pack. Sous Linux nous envoyons le nom de la
distribution, sa version, et eventuellement la version du noyau.
La procédure est la même que pour la majorite des autres recherches, le fichier /
proc/version semble contenir tout ce dont nous avons besoin. Exemple :
Linux version 2.4.20­2­686 (herbert@gondolin) (gcc version
2.95.4 20011002 (Debian prerelease)) #1 Sat May 17 12:26:47
EST 2003
18
Le problème est que trop d'informations sont disponibles par ce biais. Il est peu pertinent
de connaître la date de compilation du kernel ou la version de gcc utilisée...
Nous avons donc réduit ces informations au nom et à la version de la distribution. Cela
donne pour ce système : « Linux version 2.4.20­2­686 Debian
prerelease ». Cette information sera ensuite envoyée dans la structure OS en plus
de l'information génerale sur le nom de l'OS, à savoir « Linux ».
Le code XML produit est de la forme :
<os>
<osinfo>Linux
version
prerelease</osinfo>
<osname>Linux</osname>
</os>
•
2.4.20­2­686
Debian
Le réseau : C'est une partie très importante de l'indexage LIAM. En effet, si jamais
LIAM ne tourne pas sous droits administrateur, ou si le chassis ne possède pas de
numéro de série, c'est à partir des adresses MAC et IP qu'une machine peut être
référencée. Pour récuperer l'ensemble des informations dont nous avons besoin, nous
utilisons trois modes de recherche : l'utilitaire « ifconfig », le fichier /proc/pci, et
l'executable « hostname ». Les champs devant être remplis sont :
- netname : le nom d'une carte réseau. Sous Linux le nom de la première carte réseau est
généralement « eth0 ». Pour obtenir les cartes reseaux nous utilisons « ifconfig » dont le
retour est, par exemple pour la machine de développement :
eth0 Link encap:Ethernet HWaddr 00:B0:D0:65:9A:97
inet addr:10.1.33.56 Bcast:10.1.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:124928 errors:0 dropped:0 overruns:164 frame:0
TX packets:9640 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:19156986 (18.2 MiB) TX bytes:3970290 (3.7 MiB)
Interrupt:5 Base address:0xec80
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:79476 errors:0 dropped:0 overruns:0 frame:0
TX packets:79476 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11789780 (11.2 MiB) TX bytes:11789780 (11.2 MiB)
A noter que nous ignorons l'entrée « loopback » qui n'a aucun interêt pour l'inventaire
d'une machine. Nous avons donc toutes les interfaces réseau et pour chacune d'entre elles
nous pouvons créer une entrée « net » à laquelle nous allons associer trois autres champs
:
- macaddress : L'adresse MAC de l'interface réseau étudiée. Elle est contenue dans la
première ligne de chaque déscription d'interface. Pour la machine de développement c'est
« 00:B0:D0:65:9A:97 ».
- ipaddress : L'adresse IP de l'interface réseau étudiée. Elle se trouve sur la ligne juste en
dessous de celle contenant l'adresse MAC. La machine de développement Linux a pour
adresse IP « 10.1.33.56 ».
- description : La déscription du périphérique associé à l'interface réseau. La procédure
pour récuperer cette description est un peu plus compliquée que pour le reste du client.
En effet, elle n'est pas indiquée en clair sur les descriptions d'ifconfig et il n'y a aucun
19
autre moyen facile d'associer une adresse IP ou MAC à une interface. La solution à
implementer dans une prochaine version de LIAM est de créer une socket sur chaque
interface et de demander ses caractéristiques, afin de se dégager de la dépendance d'un
logiciel externe.
Dans un premier temps, nous avions pris l'interruption de chaque interface et nous avons
cherché à quel périphérique correspond cette interruption dans le fichier /proc/pci. Un
problème est survenu : certaines interruptions sont partagées par plusieurs périphériques,
et lorsque cela arrive, LIAM ne sait pas lequel correspond à une carte réseau à coup sur.
Nous avons donc testé l'adresse de base et la faisons correspondre avec celle contenue
dans le fichier /proc/pci. Pour le moment, je n'ai récupéré que les bonnes cartes via ce
processus, donc nous sommes assez confiants sur la stabilité de cette méthode. Extrait du
fichier /proc/pci :
Bus 1, device 12, function 0:
Ethernet controller: 3Com Corporation 3c905C­TX/TX­M
[Tornado] (rev 120).
IRQ 5
Master Capable. Latency=64. Min Gnt=10.Max Lat=10.
I/O at 0xec80 [0xecff].
Non­prefetchable 32 bit memory at 0xfdfffc00
[0xfdfffc7f].
Nous retrouvons l'adresse « 0xec80 » dans la description ifconfig et dans la description
de /proc/pci. C'est donc la description qui nous intéresse et il ne reste plus qu'à relever
son nom pour le placer dans l'onglet « description » de la partie « net » pour son
interface.
- hostname : Ne faisant pas réellement partie de la partie « net » mais étant traitée en
même temps au niveau du client, nous étudions cette caracteristique ici. Le nom de
machine est tout simplement récupéré sous Linux par la commande « hostname » dont la
sortie est le nom de machine sur une ligne. Il n'est pas génant d'utiliser cette commande
tellement elle est standard sur tous les systèmes Linux et UNIX en général.
Un exemple de sortie XML pour la partie net de la machine de développement Linux est
de la forme :
<net>
<netname>eth0</netname>
<macaddress>00:B0:D0:65:9A:97</macaddress>
<description>Ethernet controller: 3Com Corporation
3c905C­TX/TX­M [Tornado] (rev 120).</description>
<ipaddress>10.1.33.56</ipaddress>
</net>
<hostname>lair</hostname>
•
Logiciels : L'inventaire logiciel constitue un module à lui seul, il a un aspect beaucoup
plus important sous Windows que sous Linux a cause du manque de point commun
d'informations sur les logiciels, mais n'en reste pas moins une des fonctionalités de LIAM
les plus importantes, et doit donc être performant, précis et exhaustif.
La liste des logiciels ou plutot des packages installés peut être actuellement lue sur des
distributions Debian-like grâce à l'utilitaire « dpkg », ainsi que sur des distributions
RedHat et Mandrake-like grâce à la commande « rpm ». Pour savoir quel logiciel utiliser,
nous testons l'existence de certains fichiers : par exemple sous Debian nous cherchons le
fichier /etc/debian_version, sous Mandrake nous cherchons le fichier /etc/mandrakerelease, etc.
20
Le choix d'utiliser la présence de ces fichiers plutôt que le contenu du fichier /
proc/version est motivé par le coté parfois obscur de ce dernier pour obtenir les infos
nécéssaires. Si l'emplacement des fichiers /etc/* change lors de distributions Linux
futures, il se peut qu'une nouvelle décision soit prise pour une version future de LIAM.
Une fois la distribution Linux connue et l'utilitaire de paquetages lancé, je traite la sortie
afin de récupérer les informations pertinentes à l'inventaire qui sont :
- name : Le nom du logiciel, parfois abregé. C'est souvent le nom du package plutôt que
le nom complet du logiciel.
- version : La version du logiciel. Cette information est particulièrement importante pour
les librairies sous Linux.
- info : La description du logiciel. C'est la description sommaire du package qui tient en
général sur quelques dizaines de caractères au plus.
- os : L'OS sur lequel est installé le logiciel ou package. Ce champ n'est pas rempli par le
client (voir Injection).
Un exemple d'inventaire d'un logiciel et d'une librairie sous format XML est :
<soft>
<info>Archiver for .zip files</info>
<version>2.30­5</version>
<name>zip</name>
</soft>
<soft>
<info>compression library ­ runtime</info>
<version>1.1.4­12</version>
<name>zlib1g</name>
</soft>
4.2 - Client Liam Macintosh
Le support Macintosh pour LIAM n'est que préliminaire. Les ordinateurs sous MacOS 10
sont en partie similaires à Linux, mais n'ont pas de système de fichiers /proc. A la place, un utilitaire
appelé « AppleSystemProfiler » permet de récupérer un grand nombre d'informations sur le matériel
du Macintosh.
Un problème s'est présenté pour l'inventaire du Mac : Il faut télécharger des outils de
développement sur le site d'Apple pour acceder de facon plus approfondie au système. Cependant
ces outils font 300Mo, le site d'Apple n'est ni rapide ni fiable, et le navigateur Web Mac (Internet
Explorer Mac) plante régulièrement. Apres quelques tentatives infructueuses, le développement Mac
a été gelé en attendant de finir complètement le développement Windows et Linux.
•
Chassis : Deux champs sont renseignés pour le chassis sous Mac
- serial : Non présent sur la machine de développement, il est tout de même disponible
dans le system profiler :
Customer serial number = ­
Sales order number = Not available
•
Bios : Une information seule est contenue dans « AppleSystemProfiler »
boot rom info = 2.5f1 BootROM built on 04/04/00 at
17:34:38
21
- type : Toujours « systeme ».
- version : Ici la version est « 2.5Fl »
- date : Ici la date est 04/04/00. Je ne prends pas en compte l'heure, elle n'est pas
référencée dans la table BIOS de la base de données et est par ailleurs inutile.
•
Ide : Les informations sur les périphériques IDE sont disponibles et commencent par
« Hard drive » ou « CD-ROM » (aucun autre nom connu pour le moment)
Hard drive
unit number = 0
device revision = BAC51JJ
ata device type = ata
device serial = N2058PXC
device model = Maxtor 91023U2
Disk size = 9.50 GB (1K = 1024) 11 GB (1K = 1000)
Macintosh HD
Writable = Yes
Ejectable = No
Volume size = 9.50 GB (1K = 1024) 11 GB (1K = 1000)
CD­ROM
unit number = 1
device revision = 0A0C
ata device type = atapi
device serial =
device model = MATSHITA CR­1750
- idename : Le modèle du périphérique considéré. Ici « Maxtor 91023U2 » pour le
disque dur, et « MATSHITA CR-1750 » pour le lecteur de CD-ROM.
- ideinfo : Non défini.
- idetype : Le type du périphérique est celui qui se trouve sur la première ligne sans
tabulation : « Hard Drive » ou « CD-ROM »
- idesize : La taille du disque dur lorsque c'en est un. Nous l'avons sur la ligne Disk
size = 9.50 GB (1K = 1024) 11 GB (1K = 1000). Nous ne retenons
que 9.50 GB comme valeur.
•
Pci : Malheureusement, sur les MacOS 10 de test, la ligne concernant les périphériques
PCI ne comprenait pas d'items les indexant
­­­­­ Slot information ­­­­­
En conséquence, aucune information n'est conservée pour la table PCI.
•
Usb : Les périphériques USB sont correctement définis sur « AppleSystemProfiler ».
Nous pouvons extraire la liste facilement, en voici un extrait :
­­­­­ USB information ­­­­­
USB Bus 0 ()
USB Bus 1 ()
Hub in Apple Extended USB Keyboard (ID = 0x)
Vendor Mitsumi Electric (ID = 0x)
Class ID = 0x
Subclass ID = 0x
Protocol = 0x
Bus power available = 0 Ma
22
Malheureusement, seule la description est disponible, alors que LIAM doit prendre en
compte les identifiants USB vendeur et carte. La description peut être utilisée pour
l'injection dans la base, mais elle est actuellement peu pratique.
•
Processeurs : Nous ne pouvons avoir que la vitesse du processeur dans la liste donnée
par le logiciel.
Machine speed = 350 Mhz
En conséquence, et sachant que les processeurs Mac sont propriétaires, LIAM remplit
les champs suivants :
- constructor : le champ est fixé à « Apple »
- info : le champ est rempli avec « Mac »
- speed : la valeur relevée sur la ligne dans l'« AppleSystemProfiler » est la seule non
statique dans la construction du XML relatif au processeur.
•
Mémoire : Contrairement à la majorité des informations Mac, la mémoire est très
détaillée.
Memory data
­­­­­­­­­­­
Location Type Speed Info Size
DIMM0/J13 SDRAM PC100­322S 64 MB
DIMM1/J14 SDRAM PC100­333S 64 MB
Pour chaque barette nous pouvons créer une entrée « memory » dans le fichier XML
dont les champs sont remplis de la même facon que pour Linux
- ramsize : Ici « 64 ».
- ramunit : Ici « MB ».
On notera que l'unité de mesure est la même que pour Windows, contrairement à Linux
qui affiche l'unité en « kB ».
•
Os : Les deux champs concernant l'OS de la machine sont également remplis. Le system
profiler nous donne la version exacte de MacOS
System version = Mac OS X 10.0.4 (4S10)
- osname : Ce champ est positionné à « Macintosh ».
- osinfo : Toute la valeur de « System version » est recopiée.
•
Réseau : Je peux tirer plusieurs informations de la section réseau du system profiler,
malheureusement certains champs doivent être remplis de facon statique.
­­­­­­ Ethernet ­­­­­
Where =
flags = =8863<UP,BROADCAST,b6,RUNNING,SIMPLEX,MULTICAST>
Ethernet address = 00.03.93.47.80.6A
IP = 10.1.29.230
netmask = 0xffff0000
broadcast = 10.1.255.255
­­­­­­­­­­­­­­­
- netname : Ce champ n'est pas renseigné. Il est positionné par le client LIAM à
« NetMac »
23
- description : La description de la carte rattachée à l'interface réseau est également
manquante. LIAM le remplit avec « undefined ».
- macaddress : L'adresse MAC est renseignée. On notera l'utilisation de points comme
séparateurs au lieu de double points sous Linux ou de tirets sous Windows.
- ipaddress : Aussi renseigné.
•
Logiciels : LIAM ne supporte pas l'inventaire logiciel sous Macintosh pour le moment.
4.3 - Client LIAM Windows
Le client LIAM pour Windows à été développé par mon binôme Julien Lesaint. Je
n'énoncerai que succintement les méthodes de récupération des informations sur ce système
d'exploitation.
La difficulté principale de l'inventaire Windows fut la localisation des détails pertinents dans
la base de registre. La majorité des informations système et logiciel sont contenus dans la base de
registre Windows, mais cette base n'est pas toujours renseignée, et leur localisation change d'une
version de Windows à un autre, voire d'une machine à une autre. Heureusement, deux modules Perl
permettent de récupérer directement certaines de ces informations, ce qui a eu pour effet d'accelerer
le développement.
Cependant, des périphériques tels que les cartes PCI ont un système de référencement
tellement obscur dans la base de registre qu'il était impossible de suivre clairement un chemin pour
les inventorier. Il a fallu faire appel à des programmes externes non seulement pour le BIOS, comme
pour la version Linux de LIAM, mais aussi pour obtenir la liste des cartes PCI branchées. La
récupération des informations concernant les interfaces réseaux est faite grâce au programme
« ipconfig ». L'inventaire des périphériques USB est effectué avec le service WMI de Windows.
Malheureusement ce service n'est pas installé sur toutes les machines et un test pour savoir si le
service est disponible est nécéssaire, car lorsqu'on essaie d'accéder au service WMI alors qu'il n'est
pas lancé, Windows termine le processus LIAM sans aucun message d'erreur.
L'inventaire logiciel sous Windows est aussi difficile pour plusieurs raisons :
Il est impossible de définir précisement l'endroit où sont installés les logiciels.
• Il n'existe pas de commande équivalentes à la commande dpkg -l de linux pour obtenir une
liste des softs installés.
• Les logiciels n'informent que très rarement la base de registres de leur existance.
• Certaines entrées de la base de registres ne sont pas effacées après que le logiciel soit
désinstallé.
• L'information contenue dans la base des registres n'est pas uniforme pour tous les logiciels.
De plus, cela prendrait trop de temps pour scanner le(s) disque(s) dur(s) de la machine au
complet (de l'ordre de plusieurs minutes sur la majorité des PC du parc informatique de l'université).
Une stratégie à été mise en place pour obtenir le plus d'informations pertinentes sur les logiciels
installée.
1.Lecture des logiciels installés dans la branche de désinstallation des logiciels de windows.
2.Lecture des associations entre les types de fichiers et les applications utilisées pour ouvrir ces
fichiers. Le chemin des programmes est ensuite vérifié et leurs caractéristiques sont demandés
(certaines propriétés des exécutables Windows comme le nom, la version, le langage sont
directement incluses dans le fichier)
3.Lecture du menu démarrer et répétition de l'étape précédente pour tous les liens vers des
programmes trouvés, en écartant les doublons.
4.Scan différentiel du disque dur pour tous les dossiers où l'on n'a pas trouvé de programme, et
•
24
répétition de la procédure expliquée en 2.
Un dernier traitement est fait sur les données trouvées pour écarter tous les symboles (sigles
copyright, etc.) risquant de perturber le bon fonctionnement de l'Injecteur.
25
5 - LA PROCÉDURE D'INJECTION DE LIAM
Le plus gros du traitement des informations côté serveur se trouve à cet endroit. Pour
référencer une machine dans la base de données, trois grandes étapes sont nécéssaires : le POP des
mails provenant des clients LIAM Linux et Windows, le traitement de leurs informations afin de
normaliser/corriger/completer ce que les fichier XML contiennent, et enfin l'injection dans la base de
données. Le schéma ci dessous illustre le système d'Injection de LIAM :
POP
Serveur mail
Collecteur
Verification des mails
SGBDR
LIAM I.A.
(LiaMatrix)
Moteur LIAM
Serveur de SGBDR
Vue d'ensemble de la procédure d'Injection de LIAM
5.1 - Le collecteur de mails
Le collecteur de mails est la première étape du moteur d'injection de LIAM. Tout d'abord,
une connexion sur la base de données est établie, cette connexion est unique et persistera jusqu'à la
fin de la récupération, du traitement et de l'injection des données de tous les mails reçus. La
connexion vers la boite POP est ensuite établie, pour cela j'utilise le module Mail::Box::Manager.
Chaque mail dans la boite est lu, et son attachement décodé dans un dossier temporaire grâce à
Convert::UULib. L'attachement est ensuite degzippe avec le module Compress::Zlib et le traitement
du fichier XML peut démarrer.
Le fichier XML détaché du mail est d'abord confronté à la DTD LIAM grâce au module
XML::LibXML. Si le XML ne correspond pas à la DTD il y a fort a parier que l'attachement est une
tentative de pollution de la base de données (un moyen de conserver le XML et de log les adresses
mail pour l'administrateur est prévu dans une prochaine version de LIAM, la priorité donnée par le
C.R.I. est basse cependant) et LIAM passe directement au mail suivant. Sinon il est traité pour
26
injection (voir ci-après). Après injection, le mail est marqué sur le serveur POP comme devant être
détruit (configurable lorsqu'on veut diagnostiquer/deboguer le comportement de LIAM).
A la fin de la lecture de tous les mails, la boîte mail est fermée (les mails sont detruits), le
contenu du dossier temporaire LIAM est detruit (la conservation des fichiers XML est
paramétrable), et la connexion à la base de données est rompue.
5.2 - Les informations traitées par l'Injecteur LIAM
Le fichier XML une fois décompressé et associé à une hashmap grace au module
XML::Simple est traité avant injection dans la base de données. Chaque injection est éffectuée après
traitement d'une partie (un processeur, le système d'exploitation, une carte pci...). La procédure
d'injection est la même pour chaque partie, nous la détaillerons plus loin dans ce document, après les
explications sur le traitement.
De la même facon que pour la création du fichier XML, chaque fonction se passe un
morceau de l'arborescence de la hashmap afin d'acceder directement aux informations voulues.
Lorsqu'on ajoute une caracteristique dans l'inventaire, il suffit de faire correspondre la fonction coté
client à celle coté injecteur. Cela aide grandement à maintenir le logiciel plus facilement.
Pour chaque partie, LIAM traite chaque sous element de la hashmap dans une boucle et
conserve les identifiants des items parsés (pci, ide, proc, soft...), identifiants qui servent plus tard a
lier un identifiant de machine a son inventaire complet.
•
Le chassis : Peu de traitement sur le chassis, une simple vérification est effectuée sur le
serial du chassis : Si il n'est pas présent, LIAM le fixe a « undefined ». Lors des
premières versions de développement de LIAM, Chaque machine ne possédant pas de
sérial était répértoriée par une valeur non définie, ce qui causait des problèmes pour
associer une machine avec son matériel autant du coté Injection que du coté Frontal.A
présent la valeur « undefined » est considérée comme machine ne possédant pas de serial
et prise en compte lorsqu'une comparaison ou une reconnaissance sur le serial d'une
machine est effectuée.
•
Le bios : Pas de traitement sur le champ « type » qui est systématiquement renseigné par
le client LIAM. En revanche, un test de présence de la version du BIOS étudié est fait, et
si la version est absente elle est remplacée par « undefined » afin d'eviter les erreurs de
requêtes « vides ».
Les dates envoyées par les utilitaires BIOS de LIAM Windows et LIAM Linux sont de
format très variés et parfois totalement incohérents; exemple : 2009/97/23 au lieu de
23/09/1997. Le point bloquant à l'injection dans la base de données est que la date
envoyée doit être correctement formatée sinon PostgreSQL renvoie une erreur.
Un premier travail est de corriger les incohérences jour/mois : Si un mois est au dela de
12, c'est un jour et nous l'echangeons avec l'emplacement du mois. Cela a permis de
corriger de nombreuses erreurs, mais ne permet pas de reconnaître si une date telle que
09/03/2001 correspond au 9 mars 2001 ou au 3 septembre 2001. En outre, les dates trop
mal formées (incoherentes mois/années) ne sont pas corrigées.
Le champ date a été laisse sous format texte pour le moment afin de pouvoir entrer
toutes les dates dans la base de données, et un traitement plus approfondi sur ces dates,
ou un changement de l'utilitaire BIOS sera effectué dans une prochaine version de
LIAM.
•
Les ide : Le seul traitement que LIAM produit sur les périphériques IDE avant injection
27
dans la base de données est une vérification de chacun des quatre champs : Si l'un ou
plusieurs de ces champs n'est pas renseigné il est fixé à « undefined ». D'autres
traitements visant a normaliser le format des données des périphériques IDE sont prévus
dans une prochaine version de LIAM.
•
Les pci : Comme constaté lors de leur description, les clients LIAM n'envoient que les
identifiants vendeur et carte des périphériques PCI. Toute la reconnaissance et le
traitement de ces cartes sont donc faits juste avant l'injection.
Sur le serveur se trouve un fichier appelé « pci.ids ». Le comportement par défaut de
LIAM est de le chercher a certains endroits « types » du système, mais il peut être aussi
configuré pour le chercher à un emplacement particulier. Ce fichier contient un index
quasi exhaustif des identifiants PCI et de leur description correspondante. Un court
extrait de ce fichier ressemble a ceci :
102d Wyse Technology Inc.
50dc 3328 Audio
102e Olivetti Advanced Technology
102f Toshiba America
0009 r4x00
0020 ATM Meteor 155
102f 00f8 ATM Meteor 155
1030 TMC Research
1031 Miro Computer Products AG
5601 DC20 ASIC
5607 Video I/O & motion JPEG compressor
5631 Media 3D
6057 MiroVideo DC10/DC30+
On notera que pour chaque identifiant vendeur, tout à gauche, correspond un ou
plusieurs identifiants carte en retrait d'une tabulation. Si ce fichier n'est pas présent sur la
machine et que LIAM n'a pas de connexion vers internet pour en récupérer un sur le site
web par défaut possédant cet index, LIAM ne traitera pas les périphériques PCI.
Le but est donc, pour chaque paire d'identifiants, de chercher d'abord dans le fichier
l'identifiant vendeur, puis une fois celui-ci trouvé (et son nom mémorisé), chercher le bon
identifiant carte en retrait afin d'avoir le nom complet « vendeur + carte ». Si la paire est
trouvée, l'injection est effectuée. Sinon, la carte est considérée comme inconnue et n'est
pas injectée; on admettra que les chances qu'une carte ne soit pas référencée sont infimes,
et que si c'est le cas il y a de bonnes chances pour qu'elle le soit quelques jours plus tard
si c'est une carte très récente.
•
Les usb : De même que les périphériques PCI, nous ne récupérons que les identifiants
vendeur et type donc il est necessaire de faire leur traitement afin d'avoir leur description
dans la base LIAM. La procédure est identique à la reconnaissance des cartes PCI, nous
avons un fichier « usb.ids » contenant l'association de tous les identifiants vendeur +
périphérique avec leur description.
Cependant, tous les périphériques USB ne sont pas référencés par la base usb.ids, et
certains le sont au niveau de la base pci.ids. Il faut donc balayer une fois le fichier
usb.ids, puis le fichier pci.ids si l'identifiant n'a pas été trouvé. Si la paire d'identifiants
n'est présente dans aucune des deux bases, elle est ignorée (tout comme les cartes PCI, la
probabilité que cela arrive est faible et non définitive).
Il reste le cas particulier de la paire d'identifiants 0000 / 0000. Elle n'est pas référencée
par les bases, et pour cause ce n'est pas un périphérique USB mais un port, ou support
USB sur le PC. Dans ce cas, LIAM renseigne le champ à la main en remplissant la
déscription par « USB support » avant injection.
28
•
Les processeurs : Les informations concernant les processeurs sont rigoureusement
remplies dans les systèmes d'exploitation concernés. Il est inutile de vérifier si elles sont
présentes. En revanche, le format de la vitesse du processeur n'est pas la même sous
Windows que sous Linux. En conséquence, un ajustement du format est fait et la vitesse
est tronquée à l'unité.
De plus, les vitesses sont relevées par le BIOS de la carte mère, elles sont différentes à
chaque lancement de la machine. Il serait peu pertinent de rentrer les vitesses dans la
base de données sans les arrondir, cela rendrait les opérations de recherche difficile et le
nombre d'entrées dans la table des processeurs directement proportionnel au nombre de
machines rebootées ce qui peut devenir rapidement bloquant.
En pratique, les vitesses des processeurs ne sont pas directement arrondies. Le problème
s'est posé de savoir comment arrondir, car selon la vitesse du processeur, un arrondi plus
ou moins important est nécessaire (par exemple : a la dizaine pour des processeurs
cadencés à 100Mhz, a la centaine pour des processeurs cadencés à 1500Mhz). Il est
important de ne pas devoir mettre cet aspect de LIAM à jour régulierement ou de tenir
une base de proportions ou fourchettes à jour. J'ai trouvé une solution assez simple au
problème : au moment de l'injection, je demande à la base de données la liste des
processeurs de même nom et fabricant, et qui ont pour vitesse la vitesse du processeur
que je veux injecter avec comme marge d'erreur plus ou moins 10%. Cette marge est
suffisante pour récuperer à coup sur le processeur de même type si il est déjà dans la
base, et insuffisante pour avoir des doublons.
•
La mémoire : Aucun traitement n'est fait avant injection, les champs mémoire sont
toujours remplis par le client Windows ou Linux.
Dans une prochaine version de LIAM le champ unité memoire sera peut être supprimé
dans la base de données et une conversion sera faite soit au niveau du client (peu
probable, ce n'est pas le but d'alourdir le client) soit avant injection (plus probable) afin
d'avoir toutes les entrées mémoire regroupées en Mo. Actuellement nous pouvons avoir
une entrée 256Mo, une entree 256000Ko, et une entrée 2 fois 128Mo. Pour cette
dernière, le besoin de connaître les barettes elles mêmes devra être etudié avant de penser
à les additionner.
•
L'OS : De façon identique à la mémoire, les champs OS sont toujours renseignés par le
client. Aucun traitement n'est fait à ce niveau, et le C.R.I. est pleinement satisfait des
informations injectées dans la base de données.
•
Le réseau : Trois opérations sont faites sur les informations remontées par le client
concernant le réseau. D'une part le format des adresses MAC n'est pas exactement le
même sous Windows et sous Linux. Les séparateurs Windows sont des tirets « - » et les
séparateurs Linux des deux points « : ». Nous avons choisi la norme Linux pour les
injections. Tous les tirets des adresses MAC sont remplacés par des deux points lors du
traitement.
D'autre part, la description de la carte réseau attachée à une interface et à un couple
adresse MAC / adresse IP n'est pas toujours renseignée. Un test est fait sur cette
description, et si elle est absente, LIAM la positionne à « undefined » avant l'injection en
base de données.
Le nom d'hôte de la machine subit deux traitements : Le premier est la suppression de
tous les retours à la ligne eventuels dans le champ du nom d'hôte. Le deuxième est un
test de présence de ce champ. En théorie ce champ est toujours renseigné, même par
« localhost », mais ce nom étant bloquant pour l'injection des identifiants de la machine
29
dans la base si il n'est pas présent, ce test de sécurité est fait. Si le nom est absent il est
positionné à « undefined ».
•
Logiciels : La récupération des logiciels est assez simple et complète sous Linux, mais
sous Windows elle est très chaotique malgré les differentes méthodes de récupération des
caractéristiques des logiciels. Il est nécéssaire de verifier la présence de chaque élément
dans une description d'un logiciel. Les champs nom, version, et information sont vérifiés
tour à tour et remplacés par « undefined » si l'un ou plusieurs d'entre eux est absent.
De plus, le champ « OS » de chaque logiciel est fixé au moment du traitement juste avant
l'injection, ce champ est stocké depuis le début de l'inventaire en lisant le sujet du mail
reçu et contient soit « Win32 » soit « LINUX » actuellement (le support Macintosh pour
les softs est absent dans cette version de LIAM).
5.3 - L'injection en Base de Données
L'injection d'une machine dans une base de données est répartie en trois étapes, elles même
parfois divisées en plusieurs parties. Le but est en premier de référencer tout le materiel disponible de
la machine dans la base de données, puis d'ajouter la machine dans la base (ou de la reconnaître) et
enfin de mettre à jour les associations machine/materiel dans les tables correspondantes.
Le point essentiel pour le C.R.I lors de cette injection est qu'elle doit être automatique et ne
pas nécéssiter d'intervention humaine. La base de données doit être tenue à jour par LIAM
uniquement et permettre la consultation de l'inventaire dès le traitement et l'injection des machines
dans la base de données par le logiciel.
La description des différentes tables et la convention de nommage les concernant sont
développés dans la partie « La Base de Données » plus loin dans ce rapport.
- Le référencement du materiel
Après le traitement de chaque item, que cela soit un soft, processeur, os, carte pci... une
requête SQL est faite sur la table concernée pour vérifier si l'item est déjà présent. La requête est
toujours suffisamment précise pour ne récuperer qu'un seul item. S'il est présent dans la base de
données son identifiant est conservé pour la troisième partie de l'injection, sinon une insertion a lieu
dans la table avec toutes les informations requises, puis le nouvel identifiant est à son tour conservé.
- Le référencement d'une machine
Lorsque l'ensemble du materiel est contenu dans la base, LIAM essaie de reconnaître la
machine dans la base. L'identification d'une machine est sur la table « computer » dont les champs
sont : Le numéro de série, l'adresse IP, l'adresse MAC, le nom d'hote. On constatera qu'hormis le
nom d'hote (pas necéssairement unique) ces champs sont aussi contenus dans les tables chassis ou
net. LIAM tente de reconnaître la machine de deux facons différentes :
- Si la machine possède un numéro de série, une requète SQL est faite sur ce numéro. Si la
machine est présente, son identifiant est conservé pour la troisième partie de l'injection, sinon les
informations de la machine (serial si présent, adresse MAC, adresse IP, nom d'hote) sont insérées et
le nouvel identifiant est gardé.
- Si la machine ne possède pas de numéro de série, une requèete SQL est faite sur le couple
adresse MAC + adresse IP. Le comportement est le même : Si la machine est absente, elle est insérée
dans la base de données et dans tous les cas son identifiant est conservé.
- La mise à jour des associations machine/materiel
Une fois la machine et son materiel/logiciel connus et référencés dans la base de données, il
ne reste plus qu'à les associer. Afin d'eviter les doublons ou des entrées parasites dans la base
30
(exemple : un logiciel qui a été désinstallé ou une carte qui a été remplacée par une d'un autre type),
un premier balayage des tables de liaisons « comp_* » est fait, en enlevant toutes les entrées
concernant la machine considérée. Ensuite, une nouvelle entrée associant chaque identifiant d'un
objet materiel ou logiciel à l'identifiant de la machine est crée. A la fin de cette procédure LIAM peut
passer au fichier XML suivant.
Remarques
La procédure la plus longue lorsque la base de données est encore relativement vierge est la
première. Lorsqu'elle est bien fournie, c'est la troisième. Dans tous les cas le traitement des logiciels
est le plus long (insertion de toutes les descriptions de logiciels dans la première procédure, mise a
jour de tous les liens dans la troisième).
Nous partons du principe qu'une machine a forcement une adresse IP et MAC (uniques sauf
multiboot), ce qui est le cas pour le parc informatique de l'Université. Si une machine n'a ni numéro
de série ni adresse MAC/IP, LIAM produit une erreur. Une prochaine version pourrait gérer ce cas
de figure et reconnaître une machine selon d'autres caracteristiques, mais cette fonctionalité a une
priorité très basse dans les besoins du C.R.I.
31
6 - LA BASE DE DONNÉES LIAM
La base de données de LIAM est une partie importante du projet. En effet, c'est ce qui
distingue le plus LIAM d'autres logiciels d'inventaire. La majorité des logiciels se contentent
d'afficher les caracteristiques d'une machine, LIAM permet en plus l'injection de ces données dans
une base, et la consultation de cette base via un frontal Web. En fait, mis à part le client et le
bootstrap (qui accèdent à d'autres serveurs), toutes les parties de LIAM accèdent à une base de
données.
Le type de base de données choisi pour LIAM est PostgreSQL, mais d'autres bases de
données peuvent être choisies et utilisées de façon transparente avec quelques modifications de
connexion, pourvu qu'elles soient supportées par DBI sous Perl.
Table index
Computer
idcomp | .....
Table intermédiaire
Comp_xxx
idcomp | idxxx
Table périphérique
xxx
id | .....
Principe d'organisation des tables de la base de données LIAM
Un des buts de LIAM est d'être portable sans trop de soucis, lorsqu'il y aura d'autres types de
périphériques, d'autres informations à remonter et injecter. Il est donc important de garder une
structure de tables relativement simple. Même pour un parc informatique de plusieurs milliers de
machines, la taille totale des tables ne devrait pas dépasser la centaine de milliers d'entrées. D'autre
part, le nombre d'utilisateurs de la table à un instant T est supposé très réduit. Le besoin d'une grande
performance dans la base est donc accéssoire. Sur ces bases nous avons défini trois types de table :
- Les tables périphériques : Elles sont nommées selon ce qu'elles représentent, par exemple
« soft » ou « pci ». Elles contiennent les informations relatives à chaque item de ce type dans une ou
plusieurs machines. Un champ « id » identifie de facon unique chaque entrée et est utilisé dans les
tables intermédiaires. Les autres champs sont très variables d'une table à une autre.
- La table « computer » : C'est aussi la table principale, celle qui permet d'identifier une
machine sur la base. Elle a comme les tables périphériques un identifiant « idcomp » ainsi que
plusieurs champs utilisés par LIAM pour la reconnaître à partir d'un fichier XML décrivant une
machine : le numéro de série, l'adresse MAC et l'adresse IP. Enfin, un champ contenant le nom d'hôte
de l'ordinateur permet à l'utilisateur du frontal d'identifier de facon moins obscure une machine
répértoriée par LIAM.
- Les tables intermédiaires : Elles ont toutes pour nom comp_xxx avec « xxx » prenant le
nom d'une table périphérique. Chacune de ces tables contient deux champs : « idcomp », qui est
l'identifiant d'une machine référencée dans la table « computer », et « idxxx » (xxx etant le nom d'une
table périphérique) qui est l'identifiant d'une entrée dans la table périphérique concernée. Nous avons
par exemple la table « comp_pci » qui lie des machines à des périphériques pci, contient les champs
« idcomp » et « idpci »
Les identifiants de chaque table font appel à une séquence PostgreSQL. Le champ
s'autoincrémente à chaque nouvelle insertion dans la base, ce qui facilite le traitement au niveau de
l'injecteur LIAM : inutile de chercher un identifiant non utilisé, celui crée par la séquence sera
forcément unique.
Au niveau de la sécurité et de l'administration de LIAM, il y a deux comptes sur la base de
32
données. Un premier compte réservé à l'administrateur pour l'injection des données par le moteur
LIAM et l'adminsitration générale de la base. Ce compte possède tous les droits sur la base (super
utilisateur). Un second compte existe en lecture seule (SELECT uniquement) sur toutes les tables de
LIAM. Ce compte est utilisé par le frontal Web pour toutes les requètes, qu'elles soient valides ou
non, bien formées ou mal formées, entrées à la main ou suite à un clic sur un lien.
Il est important que ce second compte ait accès en lecture seule sur toutes les tables de la
base. Si toutes les tables ne sont pas accessibles, une navigation sur le frontal produira rapidement
des erreurs, si le compte a des accès en écriture, une requète faite à la main peut parasiter de façon
permanente les informations de la base de données.
33
7 - LE FRONTAL WEB LIAM-VISUAL
Un des points essentiels où se démarque LIAM des autres logiciels d'inventaire est le fait de
pouvoir consulter une base de données avec l'ensemble des PC automatiquement inventoriés. Le but
était de créer un outil de navigation simple et efficace pour le C.R.I. ainsi que pour les professeurs
ayant besoin de connaître par exemple si les machines une salle informatique sont pourvues d'un
logiciel bien particulier pour leurs travaux pratiques. D'une manière plus générale, l'interface doit :
– Etre simple d'utilisation et permettre la navigation sans connaître le langage SQL.
– Permettre aux personnes connaissant le langage SQL de taper des requêtes plus poussées
directement dans la base, sans avoir à connaître l'adresse du serveur de base de données
LIAM ni les informations de compte PostgreSQL en lecture seule.
HTTP Request
mod-perl
Client WEB
HTTP Response
HTTP::Mason
LIAM::DBIX
SQL Response
SQL Request
Serveur HTTP
SGBDR
Serveur de SGBDR
Principe de fonctionnement du Frontal LIAM-VISUAL
7.1 - Le Frontal
Le frontal actuel est basé sur un serveur apache-perl avec le module HTML::Mason
permettant le traitement des requêtes lors de la navigation ou de leur entrée manuelle. Son
fonctionnement est le suivant : le frontal reçoit les requêtes ou actions de l'utilisateur et les transmet
au serveur Apache. Le serveur effectue ensuite en général une requête à la base de données via un
module d'interfacage LIAM-BDD appelé « DBIX », puis met en forme les résultats de la requête de
manière plus intuitive. Une page HTML est ensuite générée par Mason puis renvoyée au navigateur
du client.
Mon binôme Julien Lesaint a travaillé principalement sur le Frontal Web et moi sur
l'interfacage entre le frontal et la base de données PostgreSQL
34
Le frontal LIAM-VISUAL (accueil)
Les différentes pages accessibles du Frontal ont plusieurs parties communes et d'autres
uniques. Les parties communes a toutes les pages sont :
– Entêtes : l'entête contient le logo de LIAM ainsi que le titre du Frontal Web dans le coin
supérieur gauche de la page Web. A droite nous avons la liste des sections principales du
site : Accueil, Naviguer, Aide, et A Propos.
– Barre de Contenu des Tables : cette barre est la liste des tables consultables de la base de
données LIAM. Pour chaque lien, une boîte de dialogue contextuelle est affichée pour
décrire les champs contenus dans la table, y compris les champs d'identification de table
qui sont masqués lors de la consultation. Cette barre sert de navigation rapide entre les
différentes tables et d'indication des champs de chaque table pour pouvoir faire des
requêtes SQL sur la base de données sans avoir à connaître par coeur les champs de
toutes les tables.
– Barre Contextuelle : juste en dessous de la barre de titre, elle rappelle l'endroit ou se
trouve l'utilisateur sur le site et contient éventuellement une barre de résultats.
35
Le Frontal LIAM-VISUAL (apres une requète, barre contextuelle visible)
–
–
Barre de Résultats : ne s'affiche que lorsqu'une table de resultats est montrée à
l'utilisateur. Elle permet de naviguer entre les différentes pages de résultats de la requête,
ainsi que de fixer le nombre maximum de résultats visibles sur une page (pouvant prendre
la valeur 20, 50 ou 100).
Pied de Page : contient dans le coin inferieur gauche le copyright du C.R.I. et dans le coin
inferieur droit un lien vers le site Web de l'Université. Au dessus, un petit formulaire
permet d'entrer à la main directement une requete SQL et de la soumettre à la base. Ces
requetes, comme la navigation, sont en lecture seule (droits SELECT uniquement).
La partie unique du Frontal LIAM-VISUAL est la Table de Résultats : elle n'est affichée que
lorsqu'une requête a été émise (directe ou de navigation). Pour chaque ligne de cette table, un lien
permet d'accéder sur la partie précise de la table via une requète SQL. Le comportement est différent
selon la nature de la table :
• Pour la table « computer » les liens accèdent à l'inventaire complet de la machine
concernée.
• Pour les autres tables, les liens permettent d'avoir la liste des références vers l'objet
considéré (la liste des machines possédant ce périphérique ou logiciel).
Les entêtes de table sont particulières. Elles sont constituées d'un bouton, un menu déroulant
et un champ de texte et ont pour fonctionalité de permettre a l'utilisateur de filtrer les résultats vis à
vis d'un champ.
Filtrage : lorsque l'utilisateur veut filtrer les résultats d'une requète SQL (directe ou de
navigation) sur le Frontal, il lui suffit de sélectionner un comparateur sur le champ concerné via un
36
menu déroulant, puis d'entrer sa contrainte de filtrage dans la boite de texte prévue à cet effet.
L'interpretation de la contrainte de filtrage est bien sur dépendante du comparateur selectionné. Les
filtres sont insensibles à la casse (pas de distinction majuscules-minuscules) et permettent la syntaxe
élaborée des regexp.
Tri : Un tableau de résultats peut également être trié selon un champ par l'utilisateur. Il lui
suffit de cliquer sur le bouton d'entête d'une colonne sans entrer de contrainte de filtrage pour les
classer par ordre croissant (selon le format de la colonne, des nombres ne seront pas triés selon le
mêmes critère que des chaines de caractères). Un deuxième clic sur cette colonne fera un tri par
ordre décroissant.
7.2 - DBIX : Interfacage Frontal - Base de données
DBIX, le module d'interfacage Frontal – Base de Données LIAM, est assez complet et
complexe. En effet, plus la navigation est intuitive pour l'utilisateur entre les tables via le Frontal,
plus le module d'interfacage doit interpréter les paramêtres envoyés avec un simple clic. Une partie
de ce traitement est fait par les scripts directement sous Mason, la bonne fonction de DBIX est
choisie et appelée. Toutes les fonctions de DBIX remplissent des structures variées passées en
paramêtre, et ont pour valeur de retour :
• Le nombre de réponses si celui ci est égal ou supérieur à zero.
• -1 si la requète SQL est invalide
• -2 si le serveur de base de données n'est pas accessible
DBIX se connecte sur la base de données à chaque requète provenant du Frontal. Un fichier
de configuration permet de regler les informations de compte et l'adresse du serveur de base de
données. Dans une prochaine version de LIAM une connexion permanente à la base de données est
prévue, en forcant une déconnexion lorsque le frontal est inactif pendant un temps défini, et une
tentative de reconnexion automatique lorsque le lien vers la base de données est inactif avant de
produire une erreur (-2).
Les fonctions accessibles de LIAM-DBIX par le Frontal utilisent pour la majorite
DBIx::Recordset qui permet d'envoyer des requêtes de facon abstraite (via une hashmap) et de
naviguer facilement parmi les réponses.
• submitRequest : permet d'envoyer une requête SQL « telle quelle » à la base
PostgreSQL. Pour cela nous utilisons le module DBIx::Easy qui est une interface plus
brute que DBIx::Recordset pour les requètes SQL en Perl.
• getMachineInfo : Fonction qui remplit trois structures : une système, une hardware et
une software qui sont constituées des réponses des tables concernées pour une machine
passée en paramètre.
• tableContent : accédée lorsque l'utilisateur souhaite avoir le contenu d'une table sur le
Frontal. Une structure est remplie avec tout le contenu de cette table.
• quickListTables : permet d'avoir la liste des tables principales (computer et
périphériques, pas intermédiaires) sans leurs champs, et le nombre d'entrées par table
sans balayer toutes les tables. Un gain de 5 secondes a été effectué sur l'affichage de la
page d'accueil où cette information est demandée par rapport à l'ancienne méthode.
• listTables : donne la liste des tables principales et de leurs champs, mais n'inclut pas le
nombre de lignes par table. Utilisé pour l'aide contextuelle.
• TableReferences : remplit une structure avec la liste des références vers l'objet considéré.
En pratique, nous obtenons pour un périphérique, un logiciel, un système d'exploitation...
le nombre de machines incluant cet objet dans son inventaire sur la base de données.
37
Cet ensemble permet le bon déroulement de toutes les fonctionalités du Frontal, car d'une
part les structures demandées sont différentes, et d'autres part chaque partie de DBIX est optimisée
pour sa tâche. Il n'y a donc aucune perte de temps dues aux informations inutiles lors des requêtes
SQL sur la base de données.
38
8 - CONCLUSION SUR LE STAGE
Au cours du stage, de nombreuses techniques et connaissances ont été mises en oeuvre : Les
langages HTML, XML, SQL, Perl bien sur, les protocoles HTTP, SMTP, POP. La mise en place et
administration de serveurs Web et BDD. Une compréhension approfondie des mécanismes des
systèmes Linux et Windows, tant au niveau matériel que logiciel et administratif, à été nécéssaire afin
de pouvoir extraire les informations pertinentes pour l'inventaire de chaque machine.
Le stage de cette année était également ma toute première expérience en entreprise. J'ai
beaucoup appris aux côtés des employés du C.R.I. et compris les enjeux d'un rythme d'entreprise. Le
travail en binôme sous la tutelle de Dragan Cvijetic m'a permis de mener à bien un projet et le suivre
sur plusieurs mois, ce qui est à titre personel assez gratifiant.
LIAM a un certain avenir, la version actuelle est la 1.01 et ses données sont exploitables par
le C.R.I. qui compte suivre et déployer ce projet. Grâce au fait que LIAM soit sous licence GPL,
mon binome Julien Lesaint et moi même comptons maintenir et faire évoluer LIAM pendant notre
temps libre car nous avons aquis un certain attachement à ce projet intéressant. En outre, nous avons
prolongé le stage d'un mois en dehors du cadre de la Maitrise Informatique, en accord avec le C.R.I.,
afin d'améliorer LIAM et de suivre son déploiement sur d'autres serveurs de l'Université.
39
Annexe A : Glossaire
DTD (Document Type Definition) : L’intérêt de tout vocabulaire XML (NITF, NewsML…) dépend
de sa capacité à décrire les centres d’intérêts d’un groupe particulier, par exemple l'inventaire d'une
machine en ce qui nous concerne. Cela implique de créer un ensemble de descriptions qui pourront
être utilisées pour baliser des éléments intéressants. La DTD est la definition des éléments utiles de
n’importe quel vocabulaire XML. Pour les développeurs, la DTD est un élément clef dans la création
d’outils capables de baliser un article. Pour les documentalistes et les utilisateurs, elle contient les
outils qui leur permettent d’extraire ce qu’ils veulent. En plus de définir ce qui est important, une
DTD est une liste exclusive qui évite toute confusion en ignorant tous les éléments qui ne sont pas
standard. Dans LIAM, tout fichier XML ne suivant pas la DTD spécifique pour LIAM n'est pas
traité.
HTML::Mason : Module Perl permettant de développer des sites web interactifs à l'instar de Jakarta
Tomcat pour Java. Les pages HTML sont crées dynamiquement par Mason à partir de scripts Perl et
peuvent meler du code perl avec du code HTML de facon transparente pour l'utilisateur.
Perl::Tk : Module Perl standard permettant de créer des interfaces graphiques. Il est basé sur des
widgets et une utilisation orientée objet et gère l'interface utilisateur de facon évènementielle lors de
l'execution des programmes utilisant ce module.
XML (eXtensible Markup Language) : HTML est connu depuis longtemps comme le langage de
balisage des pages Web, mais il décrit seulement l’apparence du contenu : il peut certes comprendre
que certains mots doivent apparaître avec une police plus grosse et une couleur différente mais il ne
sait pas que ces mots désignent en fait un titre ou le nom de l’auteur, contrairement justement à
XML, dont les balises se rapportent à la signification et à la structure. Un document balisé en XML
peut être interrogé sur des éléments spécifiques et XML est rapidement devenu incontournable sur
Internet : grâce à lui, on sait par exemple que tel ou tel numéro sur une page Web désigne un prix ou
un numéro de commande. L’industrie de la presse s’efforce de créer ses propres vocabulaires XML
pour définir non seulement les éléments d’une page mais aussi des informations comme des
corrections, le copyright et les droits de propriété intellectuelle. En s’accordant sur un langage
standard, il devient très facile de rechercher et d’archiver de l’information mais aussi d’extraire (de
façon automatique) les sections souhaitées pour les réutiliser ailleurs sans intervention humaine
longue et coûteuse.
40
Annexe B : DTD pour LIAM
<?xml version="1.0" encoding="iso­8859­1"?>
<!ELEMENT inventaire (system | software | hardware)*>
<!­­ inventaire ­­>
<!ELEMENT system (os | net | bios | chassis | hostname)*>
<!ELEMENT software (soft)*>
<!ELEMENT hardware (pci | ide | usb | proc | memory)*>
<!­­ SECTIONS ­­>
<!­­ system ­­>
<!ELEMENT os (osinfo | osname | osversion)*>
<!ELEMENT net (ipaddress | netname | macaddress | description)*>
<!ELEMENT chassis (serial | constructor | name)*>
<!ELEMENT bios (date | version)*>
<!ATTLIST bios type (system | video) #REQUIRED>
<!ELEMENT hostname (#PCDATA)>
<!­­ hard ­­>
<!ELEMENT pci (pci_vendor_id | pci_type_id)*>
<!ELEMENT ide (idename| idesize | ideinfo | idetype)*>
<!ELEMENT usb (usb_vendor_id | usb_type_id)*>
<!ELEMENT proc (procinfo| procconstructor| procspeed)*>
<!ELEMENT memory (ramsize)*>
<!ATTLIST memory ramunit CDATA #REQUIRED>
<!­­ soft ­­>
<!ELEMENT soft (name | info | version)*>
<!­­ ELEMENTS ­­>
<!­­ os ­­>
<!ELEMENT osinfo (#PCDATA)>
<!ELEMENT osname (#PCDATA)>
<!ELEMENT osversion (#PCDATA)>
<!­­ memory ­­>
<!ELEMENT ramunit (#PCDATA)>
<!ELEMENT ramsize (#PCDATA)>
<!­­ net ­­>
<!ELEMENT ipaddress (#PCDATA)>
<!ELEMENT netname (#PCDATA)>
<!ELEMENT macaddress (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!­­ pci ­­>
<!ELEMENT pci_vendor_id (#PCDATA)>
<!ELEMENT pci_type_id (#PCDATA)>
<!­­ ide ­­>
<!ELEMENT idename (#PCDATA)>
<!ELEMENT idesize (#PCDATA)>
<!ELEMENT ideinfo (#PCDATA)>
<!ELEMENT idetype (#PCDATA)>
<!­­ usb ­­>
<!ELEMENT usb_vendor_id (#PCDATA)>
41
<!ELEMENT usb_type_id (#PCDATA)>
<!­­ proc ­­>
<!ELEMENT procinfo (#PCDATA)>
<!ELEMENT procconstructor (#PCDATA)>
<!ELEMENT procspeed (#PCDATA)>
<!­­ soft ­­>
<!ELEMENT version (#PCDATA)>
<!ELEMENT info (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!­­ bios ­­>
<!ELEMENT date (#PCDATA)>
<!­­ chassis ­­>
<!ELEMENT serial (#PCDATA)>
<!ELEMENT constructor (#PCDATA)>
42