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).

Cela limite l'évolution du système :

• 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 le NetworkPort en deux éléments différents :

• NetworkName : regroupe ce qui concerne la couche internet
• NetworkPort : 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.

1. 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).
2. 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 classe FQDN.

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 le NetworkPort 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 nœud 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 nœud 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 nœud 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 le NetworkName, 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 de NetworkPort qui sont agrégés ;
• NetworkPortAlias : alias de port, contient l'adresse MAC et le NetworkPort 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 du NetworkPort avant la migration, sans la partie Internet (ie.: ce qui concerne le NetworkName).

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.

Création des NetworkName
Pour chaque NetworkPort, son adresse IP est extraite (champs ip) et transformée en un NetworkName dont le nom (ie : label DNS) est l'adresse IP dont les '.' sont remplacés par des '-' (seul caractère non alphanumérique autorisé pour les labels DNS) et préfixé par migration-.
Si le champs ip contient une information non valide, un log est généré.¶

Mise à jours de NetworkPort
Pour chaque port, on extrait son type (champs networkinterfaces_id et table glpi_networkinterfaces) et on essaie de le transformer en un port valide (NetworkPortEthernet, NetworkPortLocal, ...). Si ce n'est pas possible, alors, on le transforme en NetworkPortMigration.
Après la transformation, l'entrée est créée dans la table et ses champs sont dupliqués à partir de ceux du NetworkPort d'origine.¶