- Import de données dans GLPI
- Liste des champs à ajouter au coeur :
- Fonctionnement des imprimantes :
- Import des ordinateurs / switchs / imprimantes réseau
Import de données dans GLPI¶
Le schéma global :¶
Les plugins envoient les données formatées au coeur |
Puis
passage dans les critère d'existance du matériel |
Puis
Passage dans les verrous de champs |
Puis
Passage dans les dictionnaires |
Puis
Mise à jour des champs + historique |
Pour l'import, voir le chantier sur la lib d'import générique
Criteres généraux (coeur) :¶
Ces critères ont étés codés dans FusionInventory et fonctionnent très bien
- Critères d'existance 1 (avec choix multiple)
- IP
- nom
- numéro de série
- adresse mac
- Critères d'existance 2 (avec choix multiple)
- IP
- nom
- numéro de série
- adresse mac
Si on a des critères personnalisées (comme pour Datainjection), on cherchera directement ces critères là.
- Walid : pour moi nouveau type de moteur de règles : voir #2235 && ImproveOcsFusion
- MoYo : idem
Verrous de champs¶
Dictionnaires¶
Utiliser les dictionnaires comme on le fait déjà, donc rien de spécial à ajouter / modifier là dessus
- Walid : ajouter dico des composants et des imprimantes
- MoYo : pas mieux
Voir page sur les nouveaux dictionnaires à ajouter
Mise à jour des champs¶
Comme d'habitude mise à jour + historique ;)
Liste des champs à ajouter au coeur :¶
Computers¶
Ajouter un champs qui défini l'archi de l'OS (32 bits, 64 bits, Alpha...)- archname (ou alors une dropdown)
Composant : batterie¶
Création d'un composant d'ordinateur :
Table : glpi_devicebatteriesChamps :
- id
- designation
- capacity
- comment
- manufacturers_id
- devicebatterytypes_id
Exemple: id = 1 designation = EV06047 capacity = 4400 comment = manufacturers_id = 3 devicebatterytypes_id = 1
MoYo : manufacturedate : ne peut être dans cette table car spécifique à chaque batterie et non à un type de batterie ?
David : Oui c'est exact, je corrige
Champs :
- id
- name
- comment
Exemple : id = 1 name = Lithium comment =Table : glpi_computers_devicebatteries
Champs :
- id
- computers_id
- devicebatteries_id
- serial
- lastcapacity
- manufacturedate
Exemple : id = 1 computers_id = 365 devicebatteries_id = 1 serial = 61E6 lastcapacity = 3800 manufacturedate = 2005-01-10Buts :
- Identifier les batteries qui peuvent poser soucis (rappels de contructeurs)
- identifier les batteries qui ne sont plus performantes (exemple voir les batteries qui ne se recharge qu'a 40% car sont vieilles
- Walid : ça me semble pertinent
- MoYo : idem
Bios¶
Création d'un composant d'ordinateur :
Table : glpi_devicebiosChamps :
- id
- designation
- comment
- manufacturers_id
- datebios
- version
Champs :
- id
- computers_id
- devicebios_id
MoYo : est-ce que datebios et version ne serait à définir dans le composant bios ? peut-on avoir une date différente pour une même version de bios ? Est-ce qu'on ne caractériserait pas un bios par : désignation / version ?
David : En effet la date est liée a la version du bios, donc on l'integre à glpi_devicebios
- Walid : faisait parti des champs à ajouter de toute façon
- MoYo : idem. Comme un composant ou autre ?
- David : Comme un composant je pense
Disque dur¶
Modification d'un composant d'ordinateur :
Table : glpi_devicedrivesChamps :
- id
- designation
- is_writer
- speed
- comment
- manufacturers_id
- interfacetypes_id
- devicedrivemodels_id
MoYo : on a pas le serial sur les drives ? le firmware ne serait pas plutôt à mettre dans la table de liaison ?
David : le firmware caractérise un élément disque dur (comme pour la version d'un bios par exemple)
Walid : et qu'est ce qui se passe dans le cas d'un flashage de bios de disque dur ?
Champs :
- id
- name
- comment
- serial
MoYo : il y aurait quoi dans cette table ?
David : j'ai oublié de mettre le serial
Champs :
- id
- computers_id
- deviceharddrives_id
- specificity
- serial
- firmware
- Walid : quel intérêt d'avoir les infos SCSI dans un outil de gestion de parc ? pour moi c'est technique, donc destiné à rester dans fusion
- MoYo : serial / modele OK. Type : pour le moment on ne remontait que disques locaux et réseaux.
- David : Pour la partie technique ca peut etre externe au coeur ouais
Variables d'environnement¶
Gérer les variables d'environnement
Ne remonter que celles qu'on veut (comme les clés de registre), donc à définir sur le logiciel de remontée de ces informations
Affichage de ces variables dans le même onglet que l'onglet des clés de registre
Champs :
- id
- computers_id
- key (varchar 255)
- path (text)
- Walid : est ce que ça a un intérêt dans GLPI ? SI oui, gestion comme les clefs de registre ?
- MoYo : idem
- David : je l'ai mis mais pour moi c'est pas trop à intégrer au coeur
- doum : C'est le genre de truc qui n'est ni du monitoring, ni de l'inventaire. De la gestion de conf ? ca peut quand même avoir une forte liaison avec l'inventaire soft. Genre certains softs qui ne fonctionnent pas sans positionner x variables. Pour la partie helpdesk c'est pratique de pouvoir vérifier que les clés y sont.
Niveau onglet, histoire de pas en créer encore un nouveau, peut etre les faire apparaitre au meme endroit que le registre ?
Composant mémoire¶
Table : glpi_computers_devicememoriesChamps :
- id
- computers_id
- devicememories_id
- specificity
- slotnumber
- serial
MoYo : est-ce que le numéro de slot est vraiment important ? Car au final une fois dans la machine faire le lien entre le numéro remonté et son emplacement n'est pas trivial.
David : je ne penses pas que celà soit très pertinent de le garder
- Walid : je suis d'accord
- MoYo : idem
composant : controleur¶
Table : glpi_devicepcisChamps :
- id
- designation
- comment
- manufacturers_id
- revision
Champs :
- id
- computers_id
- devicepcis_id
- serial
MoYo : est-ce que la révision ne serait pas une caractéristique du controleur lui même ? comme la version d'un bios ?
David : exact,c'est une caractéristique du controleur
- identifier les cartes
- Informations requises par OPSI pour chercher le bon driver (recupere l'inventaire via webservice)
- Walid : cela a un intérêt pour les outils tiers, mais pour un gestonnaire de parc, je ne vois pas l'intérêt...
- MoYo : fabricant déjà remonté je pense / pour le reste idem que walid
- Gonéri : ça me semble intéressant pour la gestion des doublons, on peut vouloir suivre les investissements fait sur des cartes PCI-X RAID par exemple. A noté qu'il y a aussi un champ serial que j'avais oublié.
ANTIVIRUS¶
Créer un plugin pour gérer l'antivirus
- COMPANY Comapny name
- NAME
- GUID Unique ID
- ENABLED 1 if the antivirus is enabled.
- UPTODATE 1 if the antivirus is up to date.
- VERSION
- Walid : comment ajouter les données dans GLPI ? Nouvel objet ? Nouvelle table ? Y'a-til une liaison avec le soft d'antivirus remonté par l'outil d'inventaire ?
- MoYo : idem ?
- David : Ca serait plutot un objet, pas de liaison avec l'antivirus installé, je le mettrai plutot dans la partie computer
But :
- et quels process associés à cet objet ?
- permet de voir les antivirus qui ne sont pas a jour et ceux qui sont désactivés
CPU¶
Table : glpi_deviceprocessorsChamps :
- id
- designation
- frequence
- comment
- manufacturers_id
- specif_default
- cachesize (in kio)
- corenumber
Champs :
- id
- computers_id
- deviceprocessors_id
- specificity
- serial
- MoYo : serial, core, cache OK / Thread ?
- David : le nombre de thread est important aussi (comme les cores)
Logiciels¶
Commentaire de la réunion du 15/07/2010 :
Il faut réfléchir sur le global des logiciels, comment gérer ces champs, etc.
Champs intéressants :
- date d'installation (INSTALLDATE, ex : 02/02/2010)
- is pack oui/non
- pack name : c'est le nom du pack dans lequel ce logiciel se trouve
- serial : numéro de série / licence du logiciel
- IS64BIT If the software is in 32 or 64bit, (1/0)
- Walid : quel intérêt de stocker dans GLPI la commande de désinstallation. Ca sert à fusion, pas à glpi.
- Walid : comment gérer les packs ? dans un logiciel ? nouvel objet attaché à un logiciel ?
- MoYo : pareil que Walid / intérêt de guid, url info, méthode de détection ? / date install OK /
- David : Pour le pack je voyait un soft avec une ralation avec un ou plusieurs autres, mais faut que je réfléchisse à ca car faut pas que ca devienne usine a gaz
Gestion des packs logiciels
Virtual Machines¶
Commentaire de la réunion du 15/07/2010 :
A discuter et faire des specs en septembre
- UUID = numero de serie de la vm
- STATUS The VM status: running, idle, paused, shutdown, crashed, dying, off
- MoYo : a réfléchir complètement sur la gestion des VM
- Walid : voir page GlpiServers
=================================================
h3. Port réseau
- virtuel : vrai carte réseau ou pas (VPN, tunnel PPP, lo0, etc) oui/non
- Adresse ip v6
- gestion de plusieurs adresses IP
- IP du DHCP
- MTU
- status (up/down)
- SPEED Interface speed in Mb/s
- Walid : comment gérer plusieurs IP sur un même port ?
- MoYo : virtuel ? IPV6 OK / IP du DHCP : intéressant ? / Speed on le remonte dans le type pour le moment je crois.
- David : Certains ports réseaux sont virtuel (genre une connection VPN c'est du virtuel par rapport à la carte réseau). IP du DHCP peut être intéressant dans le cas ou on a des merdouilles avec. le type et la vitesse peut très bien être différente.
- Gonéri : pour moi l'info virtuel est très importante pour la gestion des doublons. Elle a été ajoutée pour GLPI à la base.
- Et donc comment tu penses gérer dans GLPI un port avec plusieurs IP ?
Carte réseau (composant)¶
- PCISLOT
- STATUS (up/down)
- MANAGEMENT Whether or not it is a HP iLO, Sun SC, HP MP or other kink of Remote Management Interface
- SPEED Interface speed in Mb/s
- MoYo : Speed OK, le reste ?
Fonctionnement des imprimantes :¶
Etant donnée que l'on remonte les numéros de série des imprimantes locale, le fonctionnement actuel des imprimantes me pose un soucis.
Je verrais plutot à la place de la connexion actuelle de l'ordinateur avec l'imprimante :
- Connexion locale entre l'ordinateur et l'imprimante (type unique)
- Connexions "logicieles" qui est en fait les imprimantes partagées installées sur les ordinateurs distants pour pouvoir imprimer (type globale)
Celà permet de différencier les 2 qui ne sont pas la même chose.
pour les imprimantes réseaux, on aurait uniquement les connexions "logicieles"
Import des ordinateurs / switchs / imprimantes réseau¶
Actuellement dans le plugin fusion, chaque matériel découvert (découverte réseau) est ajouté dans une table de matériel découvert avec le minimum d'informations nécessaires. Ensuite l'admin sélectionne ceux qu'il gère et les importe dans les tables d'inventaire de glpi (celui pemret de gérer les ordi des prestataires par exemple).
L'idée est que certains vont faire remonter les infos dans glpi qui est bien souvent en http et non en https et par conséquent je verrais bien remonter les ordinateurs dans une table "inconnus" comme les switch et imprimantes dans fusion. Ceci permettra de les gérer correctement et d'éviter une injection de données (problème de sécurité potentielle).
Des avis ?
Walid : quel est le rapport entre HTTP, HTTPS et matos inconnu ?
David : Si on utilise le https avec certificat (comme pour OCS actuellement) la remonté ne se fait que si l'agent a le certificat.
Si on n'utilise pas de certificat, celà signifie potentiellement que si une personne veut envoyer des données à la con sur le serveur, ca ne posera pas de soucis et on va avoir des merdouilles dans glpi. Donc ce que je propose, c'est que lorsque les machines remontent dans glpi, on les mette dans une zone temporaire (matos inconnu) et qu'on les valide (import dans les tables glpi , ex : computer, printer...) afin de valider que ce sont bien les données (machines / matériels) de la société. J'ai peur qu'on se ramasse des gros soucis de sécurité et que des bases soient pourris par des personnes au comportement négatif.