Feature #4573

Integration of DHCP field inside NetworkPort

Added by webmyster almost 6 years ago. Updated over 5 years ago.

Status:FeedbackStart date:10/05/2013
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Inventory
Target version:previously planned as 0.86

Description

It can be usefull to display if the NetworkPort has been assigned a dynamic IP address or not.
I think a single boolean field inside glpi_networkports can do the trick.

dhcp.diff Magnifier - First implementation of DHCP server for 0.84 (6.64 KB) webmyster, 10/15/2013 02:20 PM

History

#1 Updated by ddurieux almost 6 years ago

A field to add the ip of DHCP can be a good idea too

#2 Updated by webmyster almost 6 years ago

ddurieux wrote:

A field to add the ip of DHCP can be a good idea too

What do you mean ? Actually, I don't known any OS that allows both static and dynamic IP address on the same network port. On Unix you can, but each kind of address resolution is done on different port (real and alias ones).
Thus, I think that only the NetworkPort needs this 'is_dhcp' field, not the IPAddress.

If you mean "adding a special field IP_Address on the NetworkPort", I think it is not relevant with the new network framework. But I can miss something...

#3 Updated by ddurieux almost 6 years ago

Add a field witch contain the IP of the DHCP server when IP is from DHCP, agent ocs and fusion get this information and in some cases can be a good idea to add it into GLPI

#4 Updated by webmyster almost 6 years ago

That is possible. Instead of providing the IP addresse of the server, I suggest to add dhcp_servers_id and dhcp_serveritemtype fields that point to the DHCP server (Computer, NetworkEquipment ...).

What do you think about that ?

#5 Updated by ddurieux almost 6 years ago

Great idea ;)

#6 Updated by webmyster almost 6 years ago

One drawback: inside the plugin (Fusion or OCS), you will have to search for the right DHCP server Computer or NetworPort with its IP.
When the computer that owns the DHCP server IP does not exists, you will have to create it ...
Is it OK for you ?

#7 Updated by ddurieux almost 6 years ago

Yes, and put form of dhcp server in setup>dropdown menu, like ipnetwork

#8 Updated by webmyster almost 6 years ago

What do you think of attached patch (for 0.84) ?

#9 Updated by ddurieux almost 6 years ago

Not good idea to have db modifications in versions of 0.84, prefer add in 0.85

#10 Updated by webmyster almost 6 years ago

So, target version must be 0.85. It's not a problem for me, just a comment.

#11 Updated by moyo almost 6 years ago

  • Category set to Inventory
  • Target version changed from 0.84.3 to 0.85

#12 Updated by ddurieux almost 6 years ago

I think may have itemtype + items_id to link the DHCP with the device (itemtype like Computer ans items_id is the id of the computer)

#13 Updated by ddurieux almost 6 years ago

Je pensais faire un nouvel item 'dhcpserver' (table glpi_dhcpservers) dans lequel on a les champs :

id entities_id itemtype items_id ip

et rajouter dans le glpi_networkports un champ dhcpservers_id

#14 Updated by webmyster almost 6 years ago

C'est une bonne idée de centraliser cette information. Je vois cependant plusieurs questions :

Dans le cadre de l'import par OCS ou fusion, la création se fait sans trop de problème. Mais Peut-on/doit-on autoriser l'utilisateur à créer des serveurs DHCP depuis l'interface (ie. hors import) ? Si oui, au delà de l'ajout d'un champs is_dynamic à la classe, comment cela s'intègre-il avec les serveurs automatiquement importés : lequel choisir ?

Faut-il autoriser la modification d'informations ? Par exemple, si on modifie l'adresse IP, on risque d'avoir des soucis lors des imports ultérieurs.

Plutôt que de pointer vers un item (itemtype, items_id), pourquoi ne pas pointer vers une adresse IP, sachant que celle-ci est nécessairement reliée à un item ? Cela éviterait la redondance de l'adresse IP.

Mais j'ai plus de soucis pour la suppression :
Nous pourrions supprimer le DHCPServer (proposition de nom pour la classe) dès qu'il n'est plus utilisé par aucune machine. Mais que se passe-t-il en cas de redondance : si l'un des serveurs est en phase de maintenance lourde et toutes les requêtes DHCP sont honorées par l'autre serveur, cela détruirait la première entrée alors que lors de sa remise en route, il resservira à nouveau une adresse.
Si nous laissons l'utilisateur détruire les serveurs inutilisés (par exemple, suite au réaddressage d'un serveur), le fera-t-il ?

En fait, mon soucis avec cette nouvelle classe, c'est que cette information est automatiquement déduite lors de l'import. En toute logique, les utilisateurs n'ont aucun contrôle dessus. Est-il souhaitable de rentrer dans les tables cette information "volatile" qui ne dépend pas de la saisie d'un utilisateur et qui peut se déduire des entrées déjà présentes dans les tables ?

#15 Updated by ddurieux almost 6 years ago

Oui il faut que l'utilisateur puisse créer des serveurs dhcp. Donc en effet faut le is_dynamic

L'ip est le champ le plus important, donc a mon avis, une fois le dhcp créé avec son ip, il ne faut pas pouvoir modifier l'ip

Si tu peux lier une adresse ip a 2 items oui ca serait mieux

Dans le cas d'une utilisation manuelle par l'utilisateur, c'est lui qui gère la creation et la suppression du dhcp

#16 Updated by moyo over 5 years ago

  • Status changed from New to Feedback

#17 Updated by moyo over 5 years ago

  • Target version changed from 0.85 to previously planned as 0.86

Also available in: Atom PDF