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) ?
Par ailleurs, j'essayes de prendre en compte le maximum de demandes,
mais certains vont bien au-delà de mes compétences actuelles. De plus,
elles pourraient recquérir une refonte beaucoup plus profonde des
réseaux GLPI. Je fais référence, ici, aux souhaits de Serge Facchin
concernant la prise en compte des aggrégas, NAT et autres. Je penses que
nous pourrions différer leur mise en oeuvre dans une version ultérieur.
En tout cas, j'intègre ces commentaire dans ma propre réflexion, afin
que les évolutions souhaitées soient plus aisément lorsque nous nous
pencherons sur ces évolutions. Cela pose-t-il problème de les différer à
une version ultérieur de GLPI ?
Cordialement
Damien Touraine
On 07/12/11 17:16, MoYo wrote:
Hi,
thanks for your contribution. It was really interestign because we
planned to completly review this part.
In order to understand completly your proposal, do you have time for a
short call on IRC or by phone tomorrow or next week ?
I do a quick review of your patch and have few questions about it.
It will be also possible to include in your changes others features
like http://www.glpi-project.org/forum/viewtopic.php?pid=127533
Regards
Julien
Le 12/07/2011 14:34, Damien Touraine a écrit :
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
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
--
--------------------------------------------------------------------
Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS
Groupe de RV&A "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
