|
|
|
Hello,
|
|
|
|
|
|
|
|
je propose qu'on fasse une reunion d'une 1/2h a 13h00 aujourd'hui pour
|
|
|
|
parler de ce que demande freeradius afin de definir les possibilites et
|
|
|
|
les couts
|
|
|
|
|
|
|
|
rappel:
|
|
|
|
|
|
|
|
- Ability to define subnets in FD.
|
|
|
|
- Ability to map subnets to VLANs.
|
|
|
|
- Ability to automatically assign next free IP in a subnet when creating
|
|
|
|
a new system.
|
|
|
|
- Ability to map IP addresses to specific mac addresses, or to create
|
|
|
|
the concept of interfaces. i.e. One system would contain multiple
|
|
|
|
interface objects.
|
|
|
|
\url{https://en.wikipedia.org/wiki/IP\_address\_management}
|
|
|
|
|
|
|
|
|
|
|
|
What parameters have a subnet besides address and mask?
|
|
|
|
From what I see on the web, people have been using groups in LDAP to represent VLANs, would it make sense to have a VLAN tab on groups of systems in FD for this?
|
|
|
|
|
|
|
|
il faut voir ca dans le context du lien wikipedia des outils de type ipam
|
|
|
|
|
|
|
|
An interface always has one and only one mac address no? Is it needed to store more than the mac address for each interface?
|
|
|
|
|
|
|
|
Regarding storing the mapping between ip and mac addresses, I guess we would need to add a specific fields which store this separately, like SupAnn is doing for composite fields:
|
|
|
|
\url{https://services.renater.fr/documentation/supann/supann2018/recommandations2018/modele/composites}
|
|
|
|
They use a syntax with [key=value] to be able to filter easily on this, like (fdIpMacMapping="*[ip=fe80::fe15:b4ff:fe00:801d]*"). But as we would keep the separate fields ipHostNumber and macAddress, maybe we could settle for a simpler <mac>|<ip> syntax.
|
|
|
|
|
|
|
|
j'ai pas encore d'idee sur l'implementation.
|
|
|
|
|
|
|
|
comme tout cela est de la gestion reseau, la creation d'un concept d'interface qui peut contenir de multiple interface et de de multiple ip est la voie
|
|
|
|
|
|
|
|
en ce concerne
|
|
|
|
|
|
|
|
Chaque fois qu’on crée de nouveaux concepts dans FD va se poser la question de l’interaction avec l’existant, c’est pour ça que je pars de l’existant pour comprendre ce qui manque. On essaie d’éviter de dupliquer quand on peut.
|
|
|
|
|
|
|
|
bien compris mais ici on peut envisager la creation d'un objet interface qui serait utilise pour les systemes par exemple
|
|
|
|
|
|
|
|
Mais qu’est-ce que cet objet apporterait par rapport à des champs sur le système?
|
|
|
|
|
|
|
|
je pense plus large mais je devrait le documenter, la reflexion doit plus porter sur comment integrer un fonctionnement de type ipam dans fusiondirectory
|
|
|
|
|
|
|
|
C’est à dire?
|
|
|
|
|
|
|
|
les demandes sont plus de type de gestion de plage ip, reseau, vlan
|
|
|
|
|
|
|
|
On revient à ma question, quels sont les attributs d’un (sous-)réseau, les attributs d’un vlan?
|
|
|
|
|
|
|
|
L'IPAM ça ce veut etre surtout du "visuel" en général ou on peut l'utiliser pour faire de la configuration plus loin comme par exemple du dhcp etc?
|
|
|
|
|
|
|
|
\url{https://www.combodo.com/teemip-online-demo}
|
|
|
|
|
|
|
|
regardez cette demo je dois retourner en formation
|
|
|
|
|
|
|
|
j'essaie de revenir vers 16h45/17h00
|
|
|
|
|
|
|
|
J'ai l'impression que c'est un groupement de visuel et de config car je vois du dns management etc
|
|
|
|
|
|
|
|
Je serais d'avis que VLAN et subnets soit comme des groupes vu qu'on final c'est un ensemble par la suite, mais faudrait surement une partie dans dashboard pour que ce soit consultable
|
|
|
|
|
|
|
|
D’après le soft donné en exemple, attributs d’un sous-réseau:
|
|
|
|
|
|
|
|
* Bloc de Sous-réseaux: Net 10
|
|
|
|
* IP de Sous-réseau: 10.246.24.0 (dhcp)
|
|
|
|
* Masque : 255.255.252.0 - /22 (dhcp)
|
|
|
|
* IP de la passerelle: 10.246.27.254
|
|
|
|
* IP de broadcast: 10.246.27.255
|
|
|
|
* Organisation
|
|
|
|
* Nom
|
|
|
|
* Etat: Alloué
|
|
|
|
* Type
|
|
|
|
* Note
|
|
|
|
* Demandeur
|
|
|
|
* Date d'allocation
|
|
|
|
* Date de libération
|
|
|
|
(Les sous-réseau v6 ont les mêmes champs à part le broadcast)
|
|
|
|
|
|
|
|
Avec une notion de «Bloc de sous-réseaux» qui contient des sous-réseaux (qui représente un bloc IP je crois)
|
|
|
|
|
|
|
|
Ya aussi des plages IP, je sais pas pourquoi c’est séparé. (dhcp avec range ip)
|
|
|
|
A mon avis plages ip c'est dans le sens tu prends un 1 sous reseau du genre IP/24 et ce qui reste tu le segmente (c'est souvent pour des vlan) genre 1 -> 10 pour tel genre de fonctions etc)
|
|
|
|
|
|
|
|
Un VLAN fait juste le lien entre des sous-réseaux et des interfaces physique visiblement.
|
|
|
|
Je suis étonné qu’il puisse être lié à plusieurs sous-réseaux, surtout qu’on peut pas préciser quelle interface va dans quel sous-réseau.
|
|
|
|
|
|
|
|
Quoi que mes cours de vlan remonte a loin, mais j'ai l'impression que le vlan c'est globalement un tag sur un paquet du coup une 1 interface peut envoyer des paquets vers différent vlan en fonction du tag qui a dessus
|
|
|
|
|
|
|
|
Ya un système de requête que je comprends pas bien (pas clair si c’est des trucs traités automatiquement ou à la main)
|
|
|
|
A priori c’est du ticketing traité à la main. (donc dans le cas de FD ça serait pas intégré)
|
|
|
|
|
|
|
|
Je me demande si pour créer les "subnets" ce serait pas mieux de faire un tab mais qui rempli certains champs du coté dhcp car y sont déjà existant
|
|
|
|
-> C’est flou pour moi l’interaction de tout ça avec le DHCP parce qu’en effet c’est très lié. Tout ce qu’on remplit là va être repris coté DHCP. On peut essayer de tout afficher ailleurs alors que c’est stocké coté DHCP (genre dans l’édition d’un système on affiche la correspondance mac<>ip alors qu’elle est stockée coté DHCP), mais j’ai peur que ça pose des soucis pour des cas où ya pas de DHCP (car je crois que cette gestion d’IP peut se faire en l’absence de DHCP aussi)
|
|
|
|
|
|
|
|
Je penses que ce serait pas grave, au pire y utilise pas le dhcp ldap pour l'infra je dirais. Mais c'est une bonne question si ça risque pas de les perturber, même si pour moi quand tu fais du management / listing pour des ip c'est que ça doit etre gerer quelque part. Ca permettrait aussi de pas devoir dupliquer des champs qui existe. (Je pensais simplifier aussi la création mais ça n'a pas de sens de faire ce genre de chose sur un systeme par exemple).
|
|
|
|
|
|
|
|
Une interface a juste nom/description/mac/vitesse, et est associée à des VLANs et des IPs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(Ok à la relecture la partie ci-dessous re-décrit quasiment le fonctionnement de notre plugin DHCP en fait, à part que les sous-réseaux sont dans les configs DHCP et sont pas des groupes)
|
|
|
|
Instinctivement, si je devais faire un ajout bête\&méchant à FD pour gérer plus finement les IPs, ça donnerait:
|
|
|
|
|
|
|
|
1. Ajout d’un tab sur les groupes de machines permettant de renseigner IP, masque, passerelle, ?broadcast Ca me semble le mieux et ça reste cohérent avec la notion de group qu'on a avec subnet / vlan -> sauf qu’en l’état je différencie pas subnet et vlan je dois essayer de relire un peu mais de mémoire vlan ça rajoutait juste un genre de tag
|
|
|
|
1. Refonte de l’interface coté systèmes pour lier chaque IP à une adresse Mac, avec stockage des associations dans un champ LDAP supplémentaire.
|
|
|
|
1. Vérifications que les IPs entrées sont dans les réseaux indiqué dans les groupes de la machine
|
|
|
|
1. Bouton pour suggérer une IP depuis les groupes. pour le bouton je verrais bien un moyen de définir quel subnet on utilise pour la machine -> ben c’est les groupes auxquelles elle appartient qui représentent les subnets dans cette proposition
|
|
|
|
1. Ensuite se pose la question de l’interaction DHCP (qui a déjà toutes ces infos a priori?) -> oui on a déjà tout ce fonctionnement avec notre plugin DHCP en fait, quasiment
|
|
|
|
|
|
|
|
Faudrait vérifier mais j'ai l'impression que quand je lis la partie VLAN ça semble etre uniquement pour des routeur / switch si c'est vraiment le cas dans FD ça devrait etre plus de l'informatif j'ai l'impression
|
|
|
|
|
|
|
|
Non de ce que j’ai compris l’idée est bien de gérer avec FD c’est lui qui doit être autoritaire.
|
|
|
|
|
|
|
|
Je veux dire d'apres ce que j'ai vu sur wiki ça parle de switch / routeur je penses pas que FD a les protocoles pour gerer ça donc ce serait plus de l'informatif que de l'utilisation comme dns/dhcp etc
|
|
|
|
|
|
|
|
Si il me semble que le but c’est que derrière freeradius pioche les infos dans le LDAP.
|
|
|
|
|
|
|
|
Car si c'est pour freeradius tout la partie vlan ça devrait aller dans freeradius du coup je trouves quite a avoir un visuel séparé (comme un dashboard)
|
|
|
|
|
|
|
|
|
|
|
|
Apres avoir relu tout ca je pense qu'on doit creer un plugin a part pour la gestion des subnets et VLAN
|
|
|
|
|
|
|
|
plugin ipam aura une liste qui montrera :
|
|
|
|
|
|
|
|
- les objets de type subnet
|
|
|
|
- Les objets de type VLAN
|
|
|
|
- Les objets de type interface
|
|
|
|
|
|
|
|
l'ensemble des fonctionalites copier/coller/snapshot/templates
|
|
|
|
|
|
|
|
definition de l'objet subnet contenant deux sections
|
|
|
|
|
|
|
|
informations générales
|
|
|
|
|
|
|
|
|
|
|
|
* Organisation
|
|
|
|
* Nom
|
|
|
|
* Etat
|
|
|
|
* Type
|
|
|
|
* Note
|
|
|
|
* Demandeur
|
|
|
|
* Date d'allocation
|
|
|
|
* Date de libération
|
|
|
|
Informations IP
|
|
|
|
|
|
|
|
* Bloc de Sous-réseaux: Net 10 (dans notre cas voir si on prevoit de grouper des sous reseaux )
|
|
|
|
* IP de Sous-réseau: 10.246.24.0
|
|
|
|
* Masque : 255.255.252.0 - /22
|
|
|
|
* IP de la passerelle: 10.246.27.254
|
|
|
|
* IP de broadcast: 10.246.27.255
|
|
|
|
definition de l'objet vlan contenant deux sections
|
|
|
|
|
|
|
|
informations générales
|
|
|
|
|
|
|
|
|
|
|
|
* Organisation
|
|
|
|
* Etat
|
|
|
|
* Description
|
|
|
|
* Demandeur
|
|
|
|
VLAN
|
|
|
|
|
|
|
|
|
|
|
|
* VLAN TAG
|
|
|
|
* Type
|
|
|
|
* Liste des sous reseaux associes
|
|
|
|
|
|
|
|
* sous reseaux
|
|
|
|
* nom sous reseau
|
|
|
|
Du cote systemes
|
|
|
|
|
|
|
|
- migrer Network settings de serveur vers un onglet network interfaces
|
|
|
|
|
|
|
|
|
|
|
|
* on cree une objectClass
|
|
|
|
|
|
|
|
|
|
|
|
- Ability to automatically assign next free IP in a subnet when creating
|
|
|
|
a new system.
|
|
|
|
- Ability to map IP addresses to specific mac addresses, or to create
|
|
|
|
the concept of interfaces. i.e. One system would contain multiple
|
|
|
|
interface objects.
|
|
|
|
|
|
|
|
Est-ce que tu peux expliquer qui/quoi va utiliser ces informations dans le LDAP?
|
|
|
|
|
|
|
|
ces en deux parties :
|
|
|
|
|
|
|
|
|
|
|
|
* d'un cote on a donc un liste de subnet avec les vlan et leur subnet associes
|
|
|
|
* de l'autre cote sur les systemes on va utiliser la partie subnet pour pouvoir assigner un machine dans un subnet et proposer des ip libres dans ce subnet
|
|
|
|
Mais quel logiciel va aller chercher ces informations dans le LDAP?
|
|
|
|
|
|
|
|
la partie subnet/vlan n'a pas de logiciel specifique qui va venir chercher ces données , je vais donner un exemple concret a partir de notre infra
|
|
|
|
|
|
|
|
chez online on a 2 block d'ip sur des subnet differents
|
|
|
|
|
|
|
|
195.154.20.64/27
|
|
|
|
|
|
|
|
195.154.20.128/27
|
|
|
|
|
|
|
|
on a pas a l'heure actuelle de gestion de ca dans fusiondirectory
|
|
|
|
|
|
|
|
ce qui est interessant c'est en effet de pouvoir gerer ces deux subnet, voir les machines qui sont dedans
|
|
|
|
|
|
|
|
Tu n’as pas toutes ces informations dans le DHCP?
|
|
|
|
|
|
|
|
on n'a pas de dhcp et on parle de gestion reseau, il faut sortir le dhcp de l'equation pour pouvoir parler de gestion reseau
|
|
|
|
|
|
|
|
C’est cette partie que j’arrive le moins à comprendre, comment s’assure-t-on que l’ip dans FD et sur la machine est la même en l’absence de DHCP? Et dans les cas où le DHCP est présent, cela représente une duplication importante des informations non? (et accessoirement, puisque rien de vient lire ces informations, rien n’empêche en théorie de les stocker dans une configuration DHCP il me semble)
|
|
|
|
|
|
|
|
|
|
|
|
non on parle ici de gestion ip c'est separe du dhcp dans ce concept de base , le dhcp fait du dynamique ici on fait de la gestion d'ip statique ,
|
|
|
|
|
|
|
|
Donc:
|
|
|
|
1) C’est des cas où les IPs sont configurées à la main sur chaque machine?
|
|
|
|
oui le cas des ip des serveurs par exemple
|
|
|
|
2) Les plugins ipam et dhcp seraient incompatibles (jamais utilisé en même temps ou en tous cas pas sur les mêmes machines) ?
|
|
|
|
non pas necessairement vu que c'est pas les meme objectClass d'un point de vue fd l'un c'est du fonctionnel, l'autre c'est de la configuration
|
|
|
|
|
|
|
|
|
|
|
|
\url{https://images.opensides.be/EZpZCw5s/JKx1zKyI}
|
|
|
|
|
|
|
|
vu de chez online avec toute nos ip fixes de vms
|
|
|
|
|
|
|
|
-> c’est quoi les sd* c’est les vlans?
|
|
|
|
|
|
|
|
|
|
|
|
Y faut le voir comme des données arbitraire enfaite, juste comme des infos qu'on décide comme si on ferait un plan réseau
|
|
|
|
|
|
|
|
|
|
|
|
Pour la partie systèmes, je ne saisi pas la proposition «migrer Network settings de serveur vers un onglet network interfaces», il y aurai quoi dans cet onglet? Ce serait en remplacement des objectClass/attributs standards qu’on utilise actuellement?
|
|
|
|
|
|
|
|
Je dirais que ce serait plus comme un lien <donnée interface>:<donnée ip> de ce qu'on aura du côté du plugin ipam par exemple
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
je reflechit a un formalise qui permet de voir que l'ip et la mac sont associes, les attributs ne changement pas on utilise tjrs
|
|
|
|
|
|
|
|
ipHostNumber
|
|
|
|
macAddress
|
|
|
|
|
|
|
|
je me posait la question de creer une object class a nous
|
|
|
|
|
|
|
|
fdNetworkInterfaces
|
|
|
|
name
|
|
|
|
lien ou le subnet en lui meme
|
|
|
|
ipHostNumber
|
|
|
|
macAddress
|
|
|
|
|
|
|
|
d'un point de vue interface ca permet de selectionner ton subnet, et fd te trouve l'ip encore disponible depuis la gestion des subnet.
|
|
|
|
|
|
|
|
ca pose aussi la question de la visualisation cote subnet des ip deja utilise
|
|
|
|
La visualisation que tu me montres chez online je peut déjà te la faire dans le dashboard à partir du moment où je connais la liste des subnets.
|
|
|
|
|
|
|
|
je me doute mais ici on parle bien de gestion pas juste d'affichage
|
|
|
|
|
|
|
|
je resume en dessous
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Les sous-nœuds c’est toujours l’enfer à gérer, particulièrement pour FD (pardon j’avais lu fdNetworkInterface au singulier, si tu parles d’une OC pour l’onglet c’est possible, même si je suis pas encore convaincu du besoin d’un onglet spécifique faut que je reregarde notre interface)
|
|
|
|
|
|
|
|
J’avais proposé un champ d’agglomération:
|
|
|
|
|
|
|
|
* They use a syntax with [key=value] to be able to filter easily on this, like (fdIpMacMapping="*[ip=fe80::fe15:b4ff:fe00:801d]*"). But as we would keep the separate fields ipHostNumber and macAddress, maybe we could settle for a simpler <mac>|<ip> syntax.
|
|
|
|
*
|
|
|
|
oui ca se sera a discuter cote detail mais globalement oui
|
|
|
|
|
|
|
|
*
|
|
|
|
On peut aussi ajouter le nom de l'interface peut être (pour ce qui est plan reseau/switch etc on mets souvent le nom associé car c'est plus facilement lisible)
|
|
|
|
Mais le nom dépend de l’OS que tu boot dessus non?
|
|
|
|
Oui mais souvent c'est lié à l'utilisation actuel, si on veut parler de l'interface enps2 par exemple ce sera plus parlant que la mac xxx je penses
|
|
|
|
|
|
|
|
===== Questions ====
|
|
|
|
|
|
|
|
|
|
|
|
* Un VLAN est lié à un ou plusieurs subnets?
|
|
|
|
* Un subnet est lié à un seul VLAN?
|
|
|
|
\url{https://www.commentcamarche.net/contents/543-vlan-reseaux-virtuels}
|
|
|
|
|
|
|
|
le type 3 par exemple est tres courant et c'est la demande initiale
|
|
|
|
Tu as dis plus haut qu’un VLAN était lié à des sous-réseau, je demandais les limites de ces relations, est-ce que plusieurs VLAN peuvent être reliés au même sous-réseau?
|
|
|
|
|
|
|
|
===========================
|
|
|
|
|
|
|
|
Resume :
|
|
|
|
|
|
|
|
|
|
|
|
* Cote ipam nouveau plugin avec liste des subnet et vlan
|
|
|
|
* question si on rempli des objets interface de ce cote la on tombe dans l'histoire des ous noeuds si je comprend bien
|
|
|
|
* Non pour moi si on remplit des interfaces coté IPAM (d’un point de vue interface, hors de l’édition des systèmes), c’est pas des sous-nœuds c’est des nœuds liés, mais c’est compliqué aussi et ça duplique probablement de l’information (puisque j’imagine que l’objet interface stockerait au moins sa mac)
|
|
|
|
* l'objet interface stockerait
|
|
|
|
* fdNetworkInterfaces
|
|
|
|
* name
|
|
|
|
* lien ou le subnet en lui meme
|
|
|
|
* ipHostNumber
|
|
|
|
* macAddress
|
|
|
|
* qui serait utilise dans le systeme
|
|
|
|
* Donc duplication d’information pour ip et mac
|
|
|
|
* il n'y a pas duplication si tu selectionne le subnet et une des networkinterface disponible qui est stocke cote ipam
|
|
|
|
* J’ai pas compris alors, le système ne stockerait plus ses IPs/Macs, seulement le lien vers l’interface?
|
|
|
|
* en effet c'est une bonne question quelle serait l'impact sur les plugins dhcp et dns de ce mode de fonctionnement ?
|
|
|
|
* Ça casse tout
|
|
|
|
* plus precisement
|
|
|
|
* Ben coté FD toutes les interactions/clé étrangères et compagnie sont à refaire, même je pense coté argonaut ça utilise aussi beaucoup tout ça (identification des machines par leur IP, etc…). Et coté outils je connais pas tout mais j’imagine aussi que pas mal s’attendent à trouver les infos des systèmes dans leur objet dans les champs standards.
|
|
|
|
* ok et donc autre option si on se sert de l'objectclass networkinterface juste a des fins de selections et qu'on stocket comme avant + liaisons ca change rien
|
|
|
|
|
|
|
|
* Globalement IP et MAC peuvent etre multivalué du coup ça pourrait juste etre un lien qui combine les 2 ça éviterait de casser les applications qui utilise les attributs directement je crois
|
|
|
|
|
|
|
|
|
|
|
|
Exemples LDIF:
|
|
|
|
|
|
|
|
Actuel:
|
|
|
|
|
|
|
|
* dn: cn=isdnflagey,ou=servers,ou=systems,l=FED-BXQ,dc=ecolo,dc=lan
|
|
|
|
* cn: isdnflagey
|
|
|
|
* description: isdnflagey
|
|
|
|
* fdMode: unlocked
|
|
|
|
* ipHostNumber: 10.20.5.251
|
|
|
|
* fdDNSZoneDn: zoneName=ecolo.lan.,ou=dns,l=WDC,dc=ecolo,dc=lan
|
|
|
|
* macAddress: 00:55:05:b3:43:11
|
|
|
|
* objectClass: top
|
|
|
|
* objectClass: fdServer
|
|
|
|
* objectClass: ipHost
|
|
|
|
* objectClass: ieee802Device
|
|
|
|
* objectClass: fdDNSHost
|
|
|
|
Choix 1 - Attribut d’agrégat
|
|
|
|
|
|
|
|
* dn: cn=isdnflagey,ou=servers,ou=systems,l=FED-BXQ,dc=ecolo,dc=lan
|
|
|
|
* cn: isdnflagey
|
|
|
|
* description: isdnflagey
|
|
|
|
* fdMode: unlocked
|
|
|
|
* fdDNSZoneDn: zoneName=ecolo.lan.,ou=dns,l=WDC,dc=ecolo,dc=lan
|
|
|
|
* ipHostNumber: 10.20.5.251
|
|
|
|
* macAddress: 00:55:05:b3:43:11
|
|
|
|
* objectClass: top
|
|
|
|
* objectClass: fdServer
|
|
|
|
* objectClass: ipHost
|
|
|
|
* objectClass: ieee802Device
|
|
|
|
* objectClass: fdDNSHost
|
|
|
|
* **objectClass: fdNetworkSTUFF (si onglet séparé)**
|
|
|
|
* **fdNetworkInterface: [ip=10.20.5.251][mac=00:55:05:b3:43:11][name=enps2][subnet=10.20.5.251/27]**
|
|
|
|
* **(ou [subnet=cn=10.20.5.251/27,ou=subnets,…])**
|
|
|
|
* **(ou [subnet=cn=monsubnet,ou=subnets,…])**
|
|
|
|
*
|
|
|
|
Choix 2 - Object interface lié
|
|
|
|
|
|
|
|
* dn: cn=isdnflagey,ou=servers,ou=systems,l=FED-BXQ,dc=ecolo,dc=lan
|
|
|
|
* cn: isdnflagey
|
|
|
|
* description: isdnflagey
|
|
|
|
* fdMode: unlocked
|
|
|
|
* fdDNSZoneDn: zoneName=ecolo.lan.,ou=dns,l=WDC,dc=ecolo,dc=lan
|
|
|
|
* ipHostNumber: 10.20.5.251** (si duplication)**
|
|
|
|
* macAddress: 00:55:05:b3:43:11 **(si duplication)**
|
|
|
|
* objectClass: top
|
|
|
|
* objectClass: fdServer
|
|
|
|
* objectClass: ipHost
|
|
|
|
* objectClass: ieee802Device
|
|
|
|
* objectClass: fdDNSHost
|
|
|
|
* **objectClass: fdNetworkSTUFF (si onglet séparé)**
|
|
|
|
* **fdNetworkInterface: cn=enps2,ou=ipam,…**
|
|
|
|
*
|
|
|
|
|
|
|
|
* **dn: cn=enps2,ou=ipam,…**
|
|
|
|
* **ipHostNumber: 10.20.5.251**
|
|
|
|
* **macAddress: 00:55:05:b3:43:11**
|
|
|
|
* **cn: enps2**
|
|
|
|
* **subnet: <dn>**
|
|
|
|
*
|
|
|
|
Choix 3 - Sous-nœud interface
|
|
|
|
|
|
|
|
* dn: cn=isdnflagey,ou=servers,ou=systems,l=FED-BXQ,dc=ecolo,dc=lan
|
|
|
|
* description: isdnflagey
|
|
|
|
* fdMode: unlocked
|
|
|
|
* cn: isdnflagey
|
|
|
|
* fdDNSZoneDn: zoneName=ecolo.lan.,ou=dns,l=WDC,dc=ecolo,dc=lan
|
|
|
|
* ipHostNumber: 10.20.5.251** (si duplication)**
|
|
|
|
* macAddress: 00:55:05:b3:43:11** (si duplication)**
|
|
|
|
* objectClass: top
|
|
|
|
* objectClass: fdServer
|
|
|
|
* objectClass: ipHost
|
|
|
|
* objectClass: ieee802Device
|
|
|
|
* objectClass: fdDNSHost
|
|
|
|
* **objectClass: fdNetworkSTUFF**
|
|
|
|
* **dn: cn=enps2,cn=isdnflagey,ou=servers,ou=systems,l=FED-BXQ,dc=ecolo,dc=lan**
|
|
|
|
* **ipHostNumber: 10.20.5.251**
|
|
|
|
* **macAddress: 00:55:05:b3:43:11**
|
|
|
|
* **cn: enps2**
|
|
|
|
* **subnet: <dn>**
|
|
|
|
*
|
|
|
|
|
|
|
|
J'aime bien le choix 2 perso sauf que du coup je laisserai tout ce qui est ip/mac côté serveur pour évité la duplication et ipam fera que lire les attribut de l'autre coté
|
|
|
|
|
