Motivation¶
Organisation du réseau dans un ordinateur et entre des ordinateurs¶
Les ordinateurs sont reliés entre eux par un réseau. Cette séparation repose, généralement, sur le protocol IP (Internet Protocol). Ce dernier regroupe les 7 couches du modèle OSI en 4 couches (liaison, internet, transport et application). La première couche (liaison) est le regroupement des couches physique et liaison du modèle OSI. Elle correspond, généralement, au protocol réseau bas niveau utilisé (Ethernet, FDDI, PPP, Infiniband, Myrinet, ...). La couche au dessus (internet = réseau du modèle OSI) correspond à la couche IP. La couche de transport est celle associée au protocole TCP ou UDP. La dernière couche (application) est celle propre aux applications (NTP, WWW, SSH, Telnet, ...).
L'existant au sein de GLPI 0.83¶
Dans GLPI, le seul élément réseau présent est le NetworkPort
. Ce dernier regroupe les deux premières couches (liaison et internet). En effet, l'adresse MAC (protocole Ethernet) ainsi que la prise réseau (physique) font partie de la couche liaison. En revanche, l'adresse IP et les informations de réseau (masque et passerelle) sont du domaine de la couche internet. De plus, il ne modèlise que les réseaux en étoile ou en arbre (ie : connexion de deux NetworkPort
entre eux).
- D'une part, certaines machines spécifiques (routeurs, firewalls, serveurs, ...) possèdent des architectures qui font intervenir plusieurs "interfaces réseaux" (ie : couche de liaison) regoupées (agrégat ou trunk) sous une seule et même adresse IP (couche internet).
- D'autre part, Ethernet est le protocol réseau "LAN" le plus utilisé à l'heure actuelle. Mais d'autres type de réseaux existent : PPP, Infiniband, FDDI, Myrinet, Token Ring, .... Ces derniers répondent à des contraintes particulières (débit, latence, distance, connecté...).
- De plus, beaucoup d'anciens types de réseaux et certains nouveaux types réseaux (Wi-Fi, Wimax) ne sont pas organisés en étoile comme les réseaux Ethernet courants. Ils sont, souvent, organisés sous la forme de connexion N vers N ports. Il reste la question de très vieux protocoles tel que 10Base2 (Ordinateurs chainés par des câbles BNC). Devons-nous, encore, les prendre en compte ?
Un autre point limitant repose sur le fait que dans les NetworkPort
, il y a la notion une NetworkInterface
. Mais cette information est redondante par rapport aux carte réseau. De plus, ces cartes réseaux sont "naturellement" rattachées aux ordinateurs. Je penses que la notion d'interface n'a pas vraiment de signification pour un switch réseau. Quant aux autre équippement (téléphone, imprimantes, ...), ils sont relativement proches d'un PC et pourraient, à terme, admettre des cartes de même nature que les PCs (ie : créer Printer_DeviceNetworkCard
, Phone_DeviceNetworkCard
, ...).
Proposition¶
Ces propositions sont mises en place dans le "trunk" de GLPI. Mais elles ne sont pas encore validées.
Afin de lever ces limitations, je proposes de découper leNetworkPort
en deux éléments différents :
NetworkName
: regroupe ce qui concerne la couche internetNetworkPort
: regroupe ce qui concerne la couche de liaison
Par ailleurs, je propose de remplacer le lien vers une NetworkInterface
par un lien vers un Computer_DeviceNetworkCard
. Cela permettra plus facilement de mettre à jours les données spécifiques au port (adresse MAC, type de médium, version Wifi, ...) à partir des informations de la carte auquel le port est rattaché.
NetworkName
¶
Un noeud réseau (feuille terminale, ou pas) est caractérisé par deux informations.
- La première information concerne les adresses IP du noeud (basées sur les "Internet Protocol resources"). La seconde information concerne la résolution de ces adresses IP. Plusieurs adresses IPs sont disponibles car il est courant d'attacher une adresse IPv4 et une adresse IPv6 à un noeud. De plus, un noeud peut, également, posséder des adresses multicast ou des adresses dans des scopes différents (cf. IPv6).
- La résolution des adresses concerne, d'une part, un label au sens DNS du terme et le rattachement à un FQDN (Fully Qualified Domain Name). D'une part, le label concerne le nom du noeud dans le réseau courant. D'autre part, le FQDN correspond au nom de domaine (par exemple :
indetpnet.net
). Ce dernier correspond à la classeFQDN
.
Structure de donnée¶
Comme plusieurs adresses IP peuvent être associée à un noeud, sa base de donnée ne contient par l'adresse IP telle que décrite dans Internet Protocol resources. En revanche, elle doit contenir un champs regroupant l'ensemble de ces adresses au format textuel. En effet, cela permet de faire des affichages (notamment lors de l'affichage du noeud par leNetworkPort
ou le NetworkEquipment
) sans faire de recherche SQL. C'est, également, utilisé par la classe Search
pour faire des recherches sur les noeuds réseaux (hors adresses IPs).La structure de donnée est, donc, la suivante :
id | int(11) | Identifiant du noeud |
entities_id | int(11) | Identifiant de l'entitée d'appartenance |
items_id | int(11) | élément auquel se rattache le noeud |
itemtype | varchar(11) | |
name | varchar(255) | Nom (label) du noeud réseau et identifiant du FQDN |
fqdns_id | int(11) | |
ip_addresses | text | Version textuelle (ie. lisible par l'homme) des adresses IP attachées au noeud courant |
dhcp | int(1) | est-ce une adresse affectée automatiquement par DHCP ? |
Commentaires avant la mise en oeuvre dans le trunk :
MoYo : node_type et node_id c'est itemtype et items_id ?
Damien : effectivement. A un moment, j'avais un soucis dans les liens (URL) car les champs itemtype et items_id rentraient en conflit avec ceux du NetworkName. Mais il est vrai que ce sont les noms itemtype et items_id qui doivent être utilisés à la place.
MoYo : je ne comprend plus du tout l'architecture entre Node / Port / IP... Est-ce Item -> Port -> Node -> IPs ou Item -> Port -> Node + IPs
Damien : C'est la première organisation. L'adresse IP est attachée à un Noeud réseau. Ce noeud est attaché à un port réseau qui est lui-même attaché à l'item. A noter que le noeud réseau peut être attaché, directement au NetworkEquipement
(qui possèdent une adresse IP intrinsèque pour son contrôle).
MoYo : la copie de l'information d'entité dans l'objet est importante si on a besoin de faire des contrôle de droit sur l'objet. On n'a ainsi pas à remonter à l'objet parent (en particulier pour le moteur de recherche) _
_Damien : Effectivement, j'oubliais ce point. Il faut, donc, ajouter l'entitée sur les noeuds réseaux.
MoYo : cf avis sur les adresses IP en textuel ici : Internet Protocol resources
Je me demande si un nud réseau doit avoir sa propre entité ou s'il appartient à l'entité de l'objet auquel il se rattache.
Le champs DHCP précise sur le nud courant est affecté par DHCP ou pas. Ce champs ne concerne que les adresses IPv4. En effet, en IPv6, la notion de résolution automatique d'adresse a été étendue et rendue obligatoire pour certaines catégorie d'adresses (link local, notamment). Donc, un nud peut avoir des adresses fixes ET une résolution automatique par DHCP.
Le champs DHCP n'est pas présent dans le trunk.
NetworkPort
et ses instanciations¶
Section qui a évolué par rapport à la version précédente pour tenir compte de ce qui a réellement été mis en place dans le trunk
Comme les informations du protocol Internet seront gérées par leNetworkName
, le nouveau NetworkPort
ne les contient plus. Il perd, également, tout ce qui concerne la couche physique (adresse MAC et prise réseau). Ces informations seront gérées par des classes d'instanciation. Un champs instantiation_type
a été ajouté au NetworkPort
. Il décrit son type d'instanciation (Ethernet, Wifi, Loopback, PPP, ...). Les classes d'instanciation contiennent les informations de la couche physique. Elles héritent toutes du
NetworkPortInstantiation
. Chaque entrée d'instanciation possède le même id
que celui du NetworkPort
qu'elle spécialise. Il y a autant de classe que de type d'instanciation :
NetworkPortEthernet
: Ethernet, contient une adresse MAC, un lien vers la carte réseau, un lien vers la prise réseau, un type (T, LX, SX) et une vitesse (10, 100, 1000, 10000, ...) ;NetworkPortWifi
: WiFI, contient une adresse MAC, un lien vers le réseau wifi auquel il est connecté, un lien vers le port Wifi du point d'accès, le numéro de version (a, a/b, ...) et le mode de gestion du wifi (ad-hoc, managed, master, ...) ;NetworkPortLocal
: boucle locale (loopback), ne contient aucune information ;NetworkPortDialup
: PPP, contient l'adresse MAC ;NetworkPortAggregate
: agrégation de port ou trunk (selon les constructeurs), contient l'adresse MAC et une liste deNetworkPort
qui sont agrégés ;NetworkPortAlias
: alias de port, contient l'adresse MAC et leNetworkPort
d'origine de l'alias. C'est utilisé par certains OS pour donner des noms différents à un unique port (utilisé pour les VLANs ou multiplier les adresses IP pour un port donné) ;NetworkPortMigration
: classe utilisée lors de la migration lorsque l'on ne connait pas le type de port. Ses champs sont ceux duNetworkPort
avant la migration, sans la partie Internet (ie.: ce qui concerne leNetworkName
).
Ajouts supplémentaires¶
En plus de ces deux modification profonde du NetworkPort
, je suggères différentes améliorations.
amélioration de la jonction d'une carte avec un ordinateur¶
Mise en oeuvre dans le trunk
Évolution de l'affichage des composants d'un ordinateur. En effet, avant, il était impossible de voir tous les composants "identiques" d'un même ordinateur. Donc, il était impossible de modifier le champs specificity
des liens pour chaque exemplaire présent. Avec le dépliement de chaque composant, et la possibilité de supprimer ou d'ajouter distinctement chaque "carte", il devient plus aisé de choisir la bonne carte réseau à partir du NetworkPortEthernet
ou du NetworkPortWifi
.
champs pci_usb_id¶
Solution non mise en oeuvre, mais qui pourrait l'être
Sur les deux pincipaux modèles de types de bus PC (PCI et USB), il y a la notion de ID. C'est un identifiant sur 4 valeurs héxadécimales qui définit de manière unique un modèle de carte pour un fabricant donnée (chaque fabricant a le sien). C'est l'élément sur lequel se basent Linux et BSD (surement windows également), pour savoir quel pilote attacher à un périphérique donnée. C'est, donc, une donnée invariante d'un OS à l'autre pour une carte donnée.
Donc, je suggère de l'ajouter aux classes héritées de CommonDevice
ainsi qu'à la classe Manufacturer
. Cela permettra de faire une recherche plus aisée pour l'import de matériel pour les ordinateur multi-boot.
Problèmes lors de la migration¶
La migration des bases de données précédentes doit transformer les NetworkPort
de telle sorte qu'ils s'adaptent au nouveau format.
Fichier de log de la migration¶
Un fichier spécifique est créé dans le répertoire de log de GLPI afin de retracer toutes les erreurs de la migration.
Ce fichier peut être relu par l'administrateur système pour nettoyer la base et s'assurer qu'il n'y a pas eu de perte malencontreuse lors de la migration.
Parmi les erreurs, on peut avoir des adresses IP tronquées ou invalides, des passerelles n'appartenant pas au réseau définit dans le NetworkPort
, ...
Il y a, également, le plugin nettoyeur de migration qui permet de faire la même chose de manière beaucoup plus pratique et ergonomique. Ce plugin est particulièrement utile après la migration de grosses bases de données.
Extraction des FQDN¶
Les FQDN répondent un des critères bien précis (cf. contraintes sur les noms internet). La classe Domain contient indifféremment des noms de domaines internet et des noms de domaines Windows. Donc, la première tâche est de filtrer les entrées de la table glpi_domains, pour ne retenir que celles qui contiennet un '.' et sont valides (ie : chaque label est correctement formé).
Cela permet de peupler la base glpi_fqdns.
Extraction des réseaux¶
Les réseaux sont implicitement contenus dans les NetworkPort@s. Pour les créer, il suffit de les extraire de la table glpi_networkports. Plutôt que d'utiliser le champs @subnet
des NetworkPort
, nous utilisons le champs ip
masqué par le masque de réseau. En effet, les entrées subnet
sont généralement moins fiables que l'adresse IP d'un port.
Les réseaux sont placés dans le entitées auxquelles appartiennent les NetworkPort
qui les ont générés.