Re: [Glpi-dev] Position of evolution ...
Le 20/07/2011 11:08, Damien Touraine a écrit : Bonjour, J'avance bien dans la proposition (gestion fine des réseaux IPv4). Au demeurant, comme nous avons une arborescence complète du réseau (j'ai, partiellement, mis à jour le wiki en conséquence), il faut que je puisse connaitre tous les réseaux concernés par l'entitée courante. Cela comprend aussi bien le réseau courant que les réseaux de toutes les entitées encêtres (jusqu'à l'entité racine). Donc, existe-t-il un moyen de connaitre la liste de toutes les entitées ancêtres (ie. : le chemin de l'entitée racine à l'entitée courante) ? Salut, getAncectorsOf($table, $items_id) ++ Julien ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Position of evolution ...
Le Thu, 14 Jul 2011 06:35:34 +0200 Damien Touraine damien.toura...@limsi.fr a écrit: Hello, On 07/13/11 17:01, Walid nouh wrote: On 13/07/2011 15:59, Damien Touraine wrote: Hello, On 07/13/11 15:40, Walid nouh wrote: Hello, I just applied the patch, and it's looks really interesting. Thanks a lot ! On the plugin side, it's going to affect several of them : - fusioninventory : I let David reply, but this is more or less the same work as for OCS The plugin also modify the ocsserver class to integrate the OCS mass import plugin withiout problem. But OCS seems to have some lacks (ie : a network card that have several IP is seen as several different cards ...). So I will try to modify the patch regarding fusioninventory Maybe we could improve the FusionInventory agent to collect more data the future. As soon as all theses informations are available in GLPI, it makes more sense. I know that getting IPv6 informations is something that matters for the FusionInventory project for example. As soon as I finish the job on GLPI, I plan to work on fusion inventory. Humm, it's interessing. With integration with Fusion, I will see for modifications (I must create in first branch for 2.5.0, version for GLPI 0.83). Impact computer inventory but switch and printers too. Happy to see that ;) [...] ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Position of evolution ...
Thank you for your contribution. I encourage everyone to give their point of view about this feature. Best regards, -- Jean-Mathieu Doléans GLPi-Project.org ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Position of evolution ...
Some screenshots ? it will be interesting to visualize the new paramters ? no ? Apply the gven patch to take a look. Regards MoYo ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Position of evolution ...
Hello, I just applied the patch, and it's looks really interesting. Thanks a lot ! On the plugin side, it's going to affect several of them : - fusioninventory : I let David reply, but this is more or less the same work as for OCS - addressing : interesting because the plugin integrates a dirty way or managing reserved IP addresses - datainjection : will be more complicated to inject for sure, but we can manage it - webservices - for sure others that I don't use Walid. On 13/07/2011 12:34, Damien Touraine wrote: Hello, With the agreement of MoYo, I specified the evolution I propose inside the wiki of the forge : https://forge.indepnet.net/projects/glpi/wiki/NetworkPortReview Be free to review it and send me comments and propositions to enhance this evolution of the network port. I'm working on the enhancement of the patch I have sent yesterday. So, it is not the final version. Regards Damien Touraine On 07/12/11 14:34, Damien Touraine wrote: Hello, First, I would like to congratulate you for this software. It is very powefull and efficient. Moreover, its object oriented implementation is very well and allow many evolutions. I studied this not as a computer information collector (through the use of OCS inventory, for instance). Actually, I would like to use it as real computing equipement manager (DNS and DHCP files generator). However, I pointed that inside GLPI, the networkport class include both physical/media layer (MAC address) and Host Layer (IP address). However, in our lab, there is several computers that have several network addresses on the same NIC (sometimes with VLAN). Moreover, some computers have DNS aliases. In other word, I suggest to introduce the networknode classes that make abstraction of the material. For instance, the networkNode manage the IP addresses of the card, while the networkport manage the MAC address and its connections with the other equippements. Moreover, I propose the creation of two other classes. The first one manage the internet domains (ie : example.com). Actually, there is already a domain class. But OCS inventory fills this one by the Windows Domain. The second class concern the definition of the networks and the subnetworks (subnet + netmask + gateway). As such, when we add a computer, we can, automatically affect it an IP included in a specific network class (I created the three private classes 10.0.0.0/255.0.0.0, 172.16.0.0/255.240.0 and 192.168.0.0/255.255.0.0). A attachement, i propose a patch that implement all theses elements. I applied it on glpi-unstable-083-2011-07-12 tarball downloaded from the main site. This patch also include an update to integrate the mass import from OCS. I plan to work on this patch to improve it for our requirements (manage the history, unicity of network names, ...). Moreover, I plan to work on a specific plugin which purpose is to generate DNS, DHCP and yellow pages configuration files. Be free to propose other features in this aim. I will try to integrate it. If you are satisfy with my proposition, maybe I can work straightly on a SVN development branch of the project ? Kind Regards Damien Touraine ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Position of evolution ...
Hello, On 07/13/11 15:40, Walid nouh wrote: Hello, I just applied the patch, and it's looks really interesting. Thanks a lot ! On the plugin side, it's going to affect several of them : - fusioninventory : I let David reply, but this is more or less the same work as for OCS The plugin also modify the ocsserver class to integrate the OCS mass import plugin withiout problem. But OCS seems to have some lacks (ie : a network card that have several IP is seen as several different cards ...). So I will try to modify the patch regarding fusioninventory - addressing : interesting because the plugin integrates a dirty way or managing reserved IP addresses The evolution of the plugin I'm working on integrates a more sophisticated automatic allocation of the address. The element that knows if the IP has to be updated is the Network itself now. Actually, there is three state for a network : Automatic IP prohibited, Automatic IP allowed and Automatic IP mandatory. We can include several other types of networks. - datainjection : will be more complicated to inject for sure, but we can manage it I'm to young on this project to know this part of GLPI. Or, maybe I know it as another name. Can you say me how to find it ? - webservices Same question than previous point - for sure others that I don't use For sure, me, too ! That is why I propose you this patch. I know it is perfectible. But, that the way I propose to work on. KR Damien Touraine -- Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS Groupe de RVA VENISE, (http://www.limsi.fr/venise/) Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81 64 ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Position of evolution ...
I do it but i have only red errors from debug mode on a new network port creation (on a fresh install of GLPI SVN with patch), so i don't see any changes (only that i haven't the ip field) :/ You need also to import the empty DB file after applying patch. Regards ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Position of evolution ...
On 13/07/2011 15:59, Damien Touraine wrote: Hello, On 07/13/11 15:40, Walid nouh wrote: Hello, I just applied the patch, and it's looks really interesting. Thanks a lot ! On the plugin side, it's going to affect several of them : - fusioninventory : I let David reply, but this is more or less the same work as for OCS The plugin also modify the ocsserver class to integrate the OCS mass import plugin withiout problem. But OCS seems to have some lacks (ie : a network card that have several IP is seen as several different cards ...). So I will try to modify the patch regarding fusioninventory Maybe we could improve the FusionInventory agent to collect more data the future. As soon as all theses informations are available in GLPI, it makes more sense. I know that getting IPv6 informations is something that matters for the FusionInventory project for example. - addressing : interesting because the plugin integrates a dirty way or managing reserved IP addresses The evolution of the plugin I'm working on integrates a more sophisticated automatic allocation of the address. The element that knows if the IP has to be updated is the Network itself now. Actually, there is three state for a network : Automatic IP prohibited, Automatic IP allowed and Automatic IP mandatory. We can include several other types of networks. my question is to know if such features shouldn't be available for everyone in GLPI's core ? - datainjection : will be more complicated to inject for sure, but we can manage it I'm to young on this project to know this part of GLPI. Or, maybe I know it as another name. Can you say me how to find it ? https://forge.indepnet.net/projects/datainjection/ it's the CSV file injection plugin. During the rewrite for GLPI 0.78, I've work on the networkport to networkport connection, so there's a lot to do in this area. - webservices Same question than previous point https://forge.indepnet.net/projects/webservices/ it's a web to query and update GLPI using SOAP, XML-RPC or REST. Here, it's more about changing the searchOption to fit the new objects. It should'nt be very long (at least to get information about a networkport). - for sure others that I don't use For sure, me, too ! That is why I propose you this patch. I know it is perfectible. But, that the way I propose to work on. you do it the right way :) Walid. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Position of evolution ...
Hello, On 07/13/11 17:01, Walid nouh wrote: On 13/07/2011 15:59, Damien Touraine wrote: Hello, On 07/13/11 15:40, Walid nouh wrote: Hello, I just applied the patch, and it's looks really interesting. Thanks a lot ! On the plugin side, it's going to affect several of them : - fusioninventory : I let David reply, but this is more or less the same work as for OCS The plugin also modify the ocsserver class to integrate the OCS mass import plugin withiout problem. But OCS seems to have some lacks (ie : a network card that have several IP is seen as several different cards ...). So I will try to modify the patch regarding fusioninventory Maybe we could improve the FusionInventory agent to collect more data the future. As soon as all theses informations are available in GLPI, it makes more sense. I know that getting IPv6 informations is something that matters for the FusionInventory project for example. As soon as I finish the job on GLPI, I plan to work on fusion inventory. - addressing : interesting because the plugin integrates a dirty way or managing reserved IP addresses The evolution of the plugin I'm working on integrates a more sophisticated automatic allocation of the address. The element that knows if the IP has to be updated is the Network itself now. Actually, there is three state for a network : Automatic IP prohibited, Automatic IP allowed and Automatic IP mandatory. We can include several other types of networks. my question is to know if such features shouldn't be available for everyone in GLPI's core ? As I don't know now how to develop a plugin, I started to develop it as core element of GLPI. But I though of splitting the automatic IP affectation as a plugin. So the core elements patch sould concern the management of the network nodes (ie : split of the hardware part vs the logic part of the network), the internet addresses and the network definitions. Then, I will also work on several plugins : * one that automatically affect an IP to a node ; * several differents that generate DNS, DHCP and Yellow pages. What do you think about that ? - datainjection : will be more complicated to inject for sure, but we can manage it I'm to young on this project to know this part of GLPI. Or, maybe I know it as another name. Can you say me how to find it ? https://forge.indepnet.net/projects/datainjection/ it's the CSV file injection plugin. During the rewrite for GLPI 0.78, I've work on the networkport to networkport connection, so there's a lot to do in this area. I will give a look on that as soon as possible. - webservices Same question than previous point https://forge.indepnet.net/projects/webservices/ it's a web to query and update GLPI using SOAP, XML-RPC or REST. Here, it's more about changing the searchOption to fit the new objects. It should'nt be very long (at least to get information about a networkport). Same answer than previous one :). - for sure others that I don't use For sure, me, too ! That is why I propose you this patch. I know it is perfectible. But, that the way I propose to work on. you do it the right way :) For me, open source also means open mind KR Damien ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
