Faisabilité d'un plugin

DsiNice · 2008-11-21 00:53:52

Bonjour,
J'aimerai étudier la faisabilité d'un plugin basé sur les fonctions de Fog. Au premier coup d'œil, pour moi qui n'ai jamais touché au php (plutot asp), et n'ai pas fait de requêtes sql depuis longtemps, la tâche semble ardue.
J'ai pris contact il y quelques temps avec une société pour un devis de formation, j'attends que mon employeur donne son accord et j'essaie de préparer le terrain.
Fog est une application php/mysql qui permet de déployer des masters trés efficacement.
Pour commencer j'aimerais comparer la structure des bases, avec un shéma relationnel (MCD) je pourrais gagner pas mal de temps.
Avant de me lancer dans du 'reverse engineering' avec DBDesigner J'aimerai savoir si quelqu'un a le modèle xml de la base au format du logiciel.Ou si il a de la doc disponible (déscriptif des tables, des champs.).
J'ai fait le tour de l'espace de développement collaboratif et j'ai rien trouvé sur la base
Si j'arrive a estimer la masse de travail, peut-être qu'une création de poste est envisageable pour développer.
Si vous avez quelques conseils sur la meilleurs façon de procéder..
Merci

wawa · 2008-11-21 09:06:23

bonjour DsiNice,
1/ pas de modèle XML, si vous le faîtes ça nous intéresse
2/ il y a ça, mais je ne sais pas si c'est très à jour https://dev.indepnet.net/glpi/wiki/SchemaDb et https://dev.indepnet.net/glpi/wiki/DescripTiondb

DsiNice · 2008-11-21 17:58:09

Merci pour ces précieux liens

Jm0u · 2008-12-08 14:40:07

DsiNice,

Des nouvelles sur ce plugin ?

Jm0u

DsiNice · 2009-02-26 01:57:13

Les nouvelles,
La formation qui doit aborder le développement de plugin va avoir lieu. De mon coté pour savoir de quoi on allait parler je réfléchi toujours à ce que je souhaite obtenir.

En se basant sur une version stable et éprouvée des fonctions de base de fog qui sont essentiellement le déploiement pour mon projet. Je vais laisser de coté les fonctions apportées par l'agent fog que je n'utiliserait pas.
D'autant plus que tout ce qu'il apporte pourrait être intégré par le fichier de réponse pour la configue de base, ou par des Gpo.
Pour le plugin, il faudrait récupérer :
1 Le script d'installation qui installe et paramètre tous les logiciels nécessaires
- serveur dhcp, nfs, tftp, apache, mysql...
- outil etherwake, udp-cast, script fog
- service multicast
2 La fonction d'inventaire par boot pxe est très pratique, et pas la plus complexe à mettre en place dans le plugin
3 La fonction de gestion des images bien sure
4 La fonction de gestion des tâches
5 La fonction qui permet d'avoir un monitoring de l'utilisation de bande passante dans l'interface (gros morceau)
6 La fonction d'historique des déploiements
7 On pourrait ajouter une fonction qui permet de générer les fichiers de réponse
Voilà du pain sur la planche
Et je tombe sur un premier problème. Comme Glpi fonctionne sur Windows et Linux, il faudrait que le plugin aussi malheureusement, Fog ne fourni que des scripts pour Linux, bien que ça doit être faisable.

Dans un premier temps, pour palier au plus urgent, je vais tenter d'utiliser fog avec la base de glpi, en commençant par intégrer les tables de fog a la manière d'un plugin. Ensuite, basculer progressivement sur l'interface de Glpi les différents écrans de Fog, tout en le gardant exploitable.
1 Il faut modifier la page de création de la base dans fog pour qu'elle l'intégre sa structure dans Glpi
2 les données recueillies par l'inventaire pxe sont stocké dans un csv pour un modèle du plugin "injection de donnée"
3 le plugin "gestion des salles" ressemble pas mal, il faudrait rajouter un onglet "image disque" dans les détails de l'ordinateur
4 même type de gestion que fog
5 ?
6 pas urgent
7 j'ai fait ce type de modification dans Fog, il faut générer un simple fichier texte ou Xml (suivant l'Os) en fonction d'un formulaire puis le copier sur le poste a la fin du déploiement (poste préalablement sysprepé)
qu'en pensez vous ?

Je n'ai pas réussi à importer la structure de la base glpi avec les liaisons (DBdesigner, SQLdesigner, Toad). je vais donc tenter de les faire. En regardant comment est fait le plugin "gestion des salles", j'ai un bon aperçu du but à atteindre, mais une formation ne fera pas de mal.
Le plugin example ne fonctionne pas (v 0.71.5), j'ai récupérer le trunk svn ! Il ne s'affiche pas dans la liste des plugins à configurer.
@+

JMD · 2009-02-26 02:42:51

Une question vous semblez partir dans l'optique d'une réécriture sous forme de plugin de FOG.

Ne serait-il pas judicieux d'étudier plutot la conception d'un plugin de communication entre GLPI et FOG ?

Cela me semblerait plus pertinent en terme de maintenabilité et d'efforts de dev.

remi · 2009-02-26 08:09:19

> Le plugin example ne fonctionne pas (v 0.71.5), j'ai récupérer le trunk svn ! Il ne s'affiche pas dans la liste des plugins à configurer.

Normal, les plugins du "trunk" fonctionne avec GLPI "trunk" (la future 0.72)

D'ailleurs, vu le temps nécessaire au développement d'un plugin, je te conseille cette version, sinon il y aura pas mal de modification pour le passage 0.71 > 0.72.

+

DsiNice · 2009-02-26 12:52:15

JMD wrote:

Une question vous semblez partir dans l'optique d'une réécriture sous forme de plugin de FOG.
Ne serait-il pas judicieux d'étudier plutot la conception d'un plugin de communication entre GLPI et FOG ?
Cela me semblerait plus pertinent en terme de maintenabilité et d'efforts de dev.

Oui, le but final, si j'ai les ressources nécessaire c'est de refaire les fonctions intéressantes de fog sous forme de plugin. Mais dans un premier temps (justement par souci d'économie en effort de dev), je souhaiterais utiliser directement depuis fog la base de Glpi.
Par le biais du plugin, ajouter les tables nécessaires et les champs dans la table Glpi_computers (Enfin j'ai bien compris que les tables d'origines ne sont pas modifiable, mais une liaison 1to1 sur la table ajoutée par le plugin donnera le même résultat.)
Le déploiement se ferait toujours depuis fog. Le plugin ne fait que mettre à jour une structure de base utilisable par Fog. Le gros du travail de dev sera au niveau de fog ou il faudra modifier les requêtes pour pointer sur la base Glpi.
Comment imaginiez vous la communication ?

DsiNice · 2009-02-26 12:53:41

remi wrote:

> Le plugin example ne fonctionne pas (v 0.71.5), j'ai récupérer le trunk svn ! Il ne s'affiche pas dans la liste des plugins à configurer.
Normal, les plugins du "trunk" fonctionne avec GLPI "trunk" (la future 0.72)
D'ailleurs, vu le temps nécessaire au développement d'un plugin, je te conseille cette version, sinon il y aura pas mal de modification pour le passage 0.71 > 0.72.
+

+1

Forum GLPI-Project

Announcement

#1 2008-11-21 00:53:52

Faisabilité d'un plugin

#2 2008-11-21 09:06:23

Re: Faisabilité d'un plugin

#3 2008-11-21 17:58:09

Re: Faisabilité d'un plugin

#4 2008-12-08 14:40:07

Re: Faisabilité d'un plugin

#5 2009-02-26 01:57:13

Re: Faisabilité d'un plugin

#6 2009-02-26 02:42:51

Re: Faisabilité d'un plugin

#7 2009-02-26 08:09:19

Re: Faisabilité d'un plugin

#8 2009-02-26 12:52:15

Re: Faisabilité d'un plugin

#9 2009-02-26 12:53:41

Re: Faisabilité d'un plugin

Board footer