Le système
d'exploitation
Le serveur FTP
Le programme d'import
La base de données
Le serveur web
L'interface PHP
NB : La version de l'import gérant la contrainte concernant
l'unicité du DeviceID sera disponible d'ici la fin de la semaine.
La version actuelle ne pose aucun problème tant qu'une
machine
ne réinstalle pas le client en ayant effacé
l'installation précédente.
C'est proftpd qui a
été choisi.
L'installation du serveur ne devrait pas poser de probleme. La
configuration est élémentaire : autoriser les
connexions anonymes en écriture. Les permissions pourront etre
adaptées (par ex supprimer le droit de lecture aux utilisateurs
de sorte à ce que personne ne puisse visualiser les fichiers. Le
repertoire d'arrivée appartiendra donc de
préférence à un
utilisateur privilégié. Actuellement, les inventaires
sont stockés dans le répertoire zipresults.
Le serveur reçoit les fichiers d'inventaire,
qui peuvent être au format .tar.gz ou .zip. C'est sur ce serveur
que se trouve le programme d'import.
Retour
Deux solutions s'offrent
aujourd'hui à
nous.
La première est celle actuellement en test.
Une
tâche cron lancée toutes les minutes exécute un
script perl. Ce
dernier décompresse et désarchive les inventaires
zippés.
Il en resulte 18 sous répertoires (architecture ocs inventory
originale
oblige) dans le répertoire incoming. Une fois
vérifié le code de
retour du programme d'extraction (tar ou unzip), le fichier est
effacé.
Le sript procède ainsi pour tous les
inventaires
trouvés dans incoming. Ensuite, il recupère les noms des
fichiers .csv dans Hardware, car c'est ce fichier qui contient la
clé primaire devant définir la machine dans la base.
(Actuellement, cet identifiant est également le nom des
fichiers). Une fois cet identifiant trouvé, (son
intégrité est vérifiée au niveau du
client), le script efface toutes les entrées se raportant
à cette clé primaire dans la base, et insère
ensuite la mise à jour. (Tous les fichiers .csv portent le meme
nom pour une meme machine). Il n'y a pas de vérification du
contenu ou
même de l'existence des autres fichiers que *.csv dans /Hardware,
ceci
pour la simple et bonne raison qu'ils ne sont pas obligatoirement
présents. En effet, le client Windows ne générera
parfois
aucun fichier(Si les informations sont indisponibles, voire meme
parfois exportera des fichiers vides).
C'est aussi un choix de
flexibilité
et il est tout à fait envisageable de mettre au point un systeme
simple de sauvegarde des données préexistantes dans la
base, ou d'enrichir le script d'import dans une future version pour
inclure une limite de tolérance quant au changement de
configuration de
la machine, pour détecter d'éventuelles erreurs.
(Precisons tout
de même que des contrôles d'intégrité sont
mis en place
au niveau de la base elle même, notamment l'analyse des triplets
deviceid(identifiant unique), mac adress et system S/N). Le nombre
limité d'opérations du programme est aussi un gage de
performance, sachant qu'à terme, c'est jusqu'à 100 000
archives, donc 1 800 000 fichiers qui seront traités.
Pour cette premiere
version, nous sommes
partis du principe que "simple is beautiful" et que "le mieux est
l'ennemi du bien". Je vous engage cependant à aller jeter un
oeil sur la page "l'avenir". Précisons également que
d'ici à la
mise en place de cette "ultime version du futur", de nombreuses
versions et revisions verront le jour.
Enfin, les fichiers .csv
étant ouverts,
interprètés, et les données étant
insérées dans la base, les fichiers sont effacés.
La deuxième solution s'inscrit plus dans une
optique
de service linux : un script qui gère le lancement,
l'arrêt et le
redémarrage (ainsi que le passage de paramètres) de deux
démons
: un pour la décompression et le dépaquetage, l'autre qui
se charge de
la lecture des fichiers et des insertions dans la base. Si la solution
actuellement en test ne pose pas de problème de charge, c'est
celle
pour laquelle nous opterons pour deux raisons majeures :
- La facilité de
maintenance logicielle
(Debuggage, adaptation à la phase de production, portage
(libc)...)
- La simplicité de modification du code (Par
exemple, ajout de contraintes, complexification...)
Le démon se chargeant de l'import utilise
l'api C mysql.
Retour
Tant que la plateforme utilisera
le format de
fichiers .csv décris sur le site d'ocs inventory (Voir ici),
la base portera ce nom. L'ossature de cette base est constituée
des 18 tables correspondant aux 18 répertoires et aux
fichiers
.csv présents dans chacun d'entre eux. Les autres tables servent
à l'administration de la base elle même ou à
stocker des informations supplémentaires saisies par les
administrateurs. Un script perl ou php périodique verifie les
contraintes d'intègrité et les signale aux
administrateurs. (exemple : format des clés primaires, pas
d'adresses MAC identiques, etc...)
Retour
Un serveur apache 1.3, avec php. Vous verrez que
nous avons
adopté la plateforme LAMP, solution connue et
éprouvée.
Retour
La version php utilisée est la 4.1. La
version 5
étant très récente, nous lui avons
préfèré son ainée, testée et
éprouvée.
L'interface fourni un ensemble de services
permettant
l'authentification des administrateurs et la consultation des
données de la base Mysql.
Elle est composée de
plusieurs pages:
1) une page de login
2) une page permettant
d'effectuer des requêtes notamment:
- Toutes les
machines
- Liste
filtrée
- Machines
correspondant à une lettre de commande y
- Machines
ayant un logiciel x
- Machines
n'ayant PAS un logiciel x
- Machines
ayant moins de RAM que xx Mo/Ko
- Machines
n'ayant pas un logiciel x à jour
- Machines en
fin de garantie
Ces
requêtes font
apparaître une liste de machines correspondantes, on peut ensuite:
- classer ces machines
- voir les détails correspondant à
une machine (en cliquant sur son identifiant)
3) une page
affichant tous les
détails materiels et logiciels d'une machine
Certaines modifications des
données sont réalisables directement par cette page,
notamment:
- N° Lettre de commande
- Date de la lettre de commande
- N° Bon de livraison
- Date du bon de livraison
- Date de garantie
Retour