|
|
|
|
|
|
|
|
You asked us for :
|
|
|
- Ability to define subnets in FD.
|
|
|
- Ability to map subnets to VLANs.
|
|
|
|
|
|
T**o expand on this, we would need the ability to define a subnet, and map it to one or more VLANs. This is really adding references from a VLAN object to the subnet objects by DN. I think this is what you've described below.**
|
|
|
|
|
|
- Ability to automatically assign next free IP in a subnet when creating
|
|
|
a new system.
|
|
|
- Ability to map IP addresses to specific mac addresses
|
|
|
|
|
|
**For more detail on subnet/system/mac mapping, we were envisaging these as interfaces objects. An interface would consist of a name, a mac-address, an optional VLAN, and whether that VLAN is tagged or untagged. The interface would also reference one or more subnets, and allow IP addresses to be assigned from those subnets.**
|
|
|
|
|
|
Faut ptet préciser sur le concept d’interface que ça sera plutôt un attribut composite sur les systèmes et pas un objet à part. (J’ai pas saisi le truc du tag vlan je croyais que c’était chaque vlan qui disait son tag)
|
|
|
|
|
|
tant que les infos restent sur le systeme on peut en faire un objectclass avec ces infos ca ne dupliquera pas la donne et restera correct avec le reste
|
|
|
|
|
|
Je n’ai pas compris. Voir plus bas quand ça reparle d’objectClass pour les interfaces.
|
|
|
|
|
|
je veux dire on peut definir une objectclass fdNetInterface qui contient
|
|
|
|
|
|
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,…])**
|
|
|
|
|
|
|
|
|
Non justement j’avais compris qu’on ne faisait pas de sous-objets. Comment tu envisages l’architecture finalement par rapport à mes exemples LDIF? Je ne comprends pas comment on peut avoir des objets interfaces séparés sans duplication (ou perte de fonctionnalités)
|
|
|
|
|
|
en effet on ne peut pas ne pas dupliquer si on veux rester standard
|
|
|
|
|
|
|
|
|
**Which subnets are shown depends on whether a VLAN is selected:**
|
|
|
** **
|
|
|
** - If a VLAN were selected for the interface, the subnets available for selection would be the subnets available in the VLAN.**
|
|
|
** - If no VLAN were selected for the interface, the subnets available for selection would be all subnets.**
|
|
|
|
|
|
Ça se fait c’est pas plus complexe que les trucs SupAnn
|
|
|
|
|
|
**Multiple interfaces with the same VLAN should be allowed on the same system, but the cardinality of mac-address + VLAN should be 1 within the system, i.e. you can't use the same mac + VLAN combination on multiple interfaces, but you can use the same mac-address with different VLANs on different interfaces within the same system.**
|
|
|
|
|
|
À voir ce que ça donne coté UI alors, à l’origine je pensais cacher les champs ip/macs mais si on doit pouvoir réagir entre les champs en fonction de la mac faudra que les mac/ips soient ajoutées dans leur champ puis sélectionnées dans des menus déroulants coté interface (un peu le même débat que supannEtuEtape quelque part)
|
|
|
|
|
|
**This is imagining interfaces as a 1:1 mapping with host interfaces, i.e. we'd generally name the interfaces to reflect the OS enumerated interfaces on the system (em0, em1 etc..). We'd then use salt to configure the interfaces correctly on the host, and FreeRADIUS to do the correct dynamic tagged/untagged assignment when the machine authenticates to the network..**
|
|
|
|
|
|
Donc ya bien des logiciels qui vont lire tout ça dans le LDAP
|
|
|
|
|
|
our proposition is the following (see attached Commercial Proposal
|
|
|
PR2003-0376) :
|
|
|
|
|
|
Creation of an ipam plugin , this plugin will contain
|
|
|
|
|
|
- list of subnet(s) with the subnet network information, name,
|
|
|
description, allocation date
|
|
|
OK.
|
|
|
|
|
|
- list of vlan(s) which contains one or several subnets
|
|
|
|
|
|
**To expand on VLAN definitions. We were imagining VLAN objects to contain a name, an inner VLAN ID (0-4094), and an optional metro QinQ VLAN ID (0-4094) for the outer tag. The VLAN IDs don't need to be interpreted by anything in Fusion Directory, they're purely for our use/use by dynamic networking services. FreeRADIUS can dynamically assign VLANs (both tagged an untagged) to devices as they complete Mac-Auth or 802.1X, and that's what we'll be using the VLAN IDs for.**
|
|
|
|
|
|
**Modification of the system plugin**
|
|
|
|
|
|
- moving the network configuration to his own tab
|
|
|
|
|
|
**What would happen to existing mac-address and subnet assignments for systems? Would there be an upgrade script to move them into a "default" interface object, or would the interface still allow assigning macs and IPs at a system level, but also the creation of interfaces?**
|
|
|
|
|
|
**If it's the second approach, could we request two network configuration tabs, one for "simple" networking and one for IPAM interfaces. This is so we can disable the "simple" networking tab so our internal users don't get confused.**
|
|
|
|
|
|
J’aurai tendance à proposer de laisser les ips/macs dans l’onglet par défaut et un onglet ajouté par le plugin ipam permettrait l’association des ces ips/macs entre elles ?
|
|
|
|
|
|
Il faut juste garder en tete qu'il faut qu'on puisse les mettre sans le plugin ipam donc je dirais que c'est bon tant qui sont pas dans ipam directement.
|
|
|
|
|
|
Il faut qu’on puisse mettre quoi sans le plugins IPAM? Là je proposais justement de mettre ça dans un onglet à part. Une correspondance mac/ip simple aurait pu être dans systems mais là leur concept d’interface touche aux VLAN et subnets donc difficile à faire marcher sans le plugins ipam.
|
|
|
|
|
|
la question pour moi est, est ce qu'on accepte la duplication de deux attribut pour conserver un mode standard et donc on embraye sur la solution 2, avec un flag dans la config du plugin system pour activer oui ou non le support standard lorsqu'on creer des systemes
|
|
|
|
|
|
*Pour moi tu confonds legacy et standard, les champs ipHostNumber et macAddress c’est les champs standards pour stocker ces informations c’est pas legacy c’est ce qui est encore utilisé aujourd’hui.*
|
|
|
|
|
|
desole je change le mot :)
|
|
|
|
|
|
Dans le mode pas standard, tu vois les interfaces comme sous-nœud ou nœuds liés?
|
|
|
Quel sont les arguments pour faire ça plutôt qu’un attribut composite avec les attributs standards? (on peut même imaginer mettre des attributs séparés pour tout façon SupAnn si ça parait utile)
|
|
|
|
|
|
standard c'est juste la decision de stocker ou pas les attributs ipHostNumber et macAddress hors des objetclass fdnetinterface
|
|
|
|
|
|
«objetclass fdnetinterface» -> dans ton idée ce serait des sous-nœud ou des nœud liés par un attribut qui contient les dn? (foreign key)
|
|
|
|
|
|
Pour moi le plugin ipam pourrait juste contenir les aglomeration
|
|
|
On peut avoir un nouveau tab network mais il devrait rester fonctionnel sans ipam ou juste laissé dans system ça dépend si on veut restructurer cette partie la (tant que ça reste fonctionnel tout seul ^^)
|
|
|
|
|
|
En plus idéalement (point de vue ldap), je penses qui faut qu'on évite de les bouger si on peut pour pas casser les install existante et les plugins. Du coup avoir ipam qui ajoute toute les nouveautés tout en gardant les anciens attribut au même niveau me semble bien (dans la mesure du possible bien sur).
|
|
|
|
|
|
oui en effet je reflechit au tabs :
|
|
|
|
|
|
|
|
|
*
|
|
|
|
|
|
|
|
|
**- Add subnet selection for a system**
|
|
|
|
|
|
- Find the next available ip address for a system in the subnet
|
|
|
|
|
|
- Add a new objectClass to link an ip adress to macs addresses, name an
|
|
|
interface, and link to his subnet
|
|
|
|
|
|
**Perfect, this is what I was describing above.**
|
|
|
|
|
|
*Je croyais qu’on avait décidé l’inverse, pas de sous-objets, je comprends plus c’est quoi l’archi retenue finalement?*
|
|
|
|
|
|
The proposal is flexible for future demands and keep dhcp, dns et others
|
|
|
systems part working without breaking anything
|
|
|
|
|
|
**Yes there'll likely be future requests to deal with DHCP option to subnet assignment, and IP selection in DNS records **
|
|
|
|
|
|
Ben du coup si ya le plugin IPAM et le plugin DHCP en parallèle ça fera de la duplication puisque DHCP stock aussi les subnets, faudra voir comment articuler tout ça
|
|
|
|
|
|
Je resterais d'avis de faire un truc comme on avait pour mail a l'epoque (me semble plus que c'est encore le cas) mais de faire installer dhcp meme si on l'utilise pas pour avoir les attribut ldap deja existant.
|
|
|
|
|
|
The development will be integrated into the 1.4-dev version and will be
|
|
|
documented in the official documentation.
|
|
|
|
|
|
**OK, that's great.**
|
|
|
|
|
|
======
|
|
|
|
|
|
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: fdipamInterface (si onglet séparé)**
|
|
|
**fdNetworkInterface: cn=enps2,ou=isdnflagey,ou=ipam,…**
|
|
|
|
|
|
**dn: cn=enps2,ou=ipam,…**
|
|
|
**ipHostNumber: 10.20.5.251**
|
|
|
**macAddress: 00:55:05:b3:43:11**
|
|
|
|
|
|
Si on fait des objets séparés interfaces:
|
|
|
|
|
|
Soit ils sont stockés coté ipam (ou=ipam)
|
|
|
Soit ils sont stockés sous le nœud du serveur (sous-nœud, potentiellement géré via management dans l’onglet façon services)
|
|
|
? Soit ils sont stockés coté IPAM dans une ou au nom du système (J’ai pas bien compris cette solution, ça pose pleins de question gestion de la base, des liens machines<>interfaces, …)
|
|
|
|
|
|
Coté UI:
|
|
|
|
|
|
Si les interfaces sont créée/éditée coté IPAM, on met simplement un lien vers elles coté systems, donc on les séléctionne avec un dialogue selectManagement. Ça parait un peu relou point de vue workflow a priori. Ça reste cependant proche d’autres outils ipam je crois.
|
|
|
Si les interfaces sont gérées coté systems
|
|
|
|
|
|
* Si sous-nœud ça peut être une classe de management ça semble le plus propre
|
|
|
* Si nœuds liés ça serait un OrderedArrayAttribute avec beaucoup de plomberie dessous pour enregistrer tout au bon endroit, un peu comme les onglets DHCP et DNS qui eux aussi permettent l’édition d’infos stockées ailleurs. (D’ailleurs l’onglet DHCP permet l’association subnet/ip/mac déjà, c’est un exemple d’interface possible pour l’onglet IPAM)
|
|
|
Je tiens à rappeler que tout l’existant (dans FD et hors FD) se base sur les champs **ipHostNumber/macAddress** du système, donc il faudra synchroniser ça avec les interfaces, ce qui veut dire qu’éditer une interface en dehors de FD (via LDAP) cassera la cohérence.
|
|
|
|
|
|
Il faudra aussi se poser la question de l’accès via REST. Il semble qu’actuellement les services sont pas éditable via REST, si on part sur une classe de management on pourra trouver une solution commune. (ou alors peut-être simplement utiliser les opérations classiques avec le système en base, à expérimenter)
|
|
|
|
|
|
**La solution que je préconise, s’il faut à tout prix des objets interface séparés:**
|
|
|
Stocker les interfaces comme des sous-nœuds des systèmes, et les gérer via une classe de management comme onglet.
|
|
|
Quand cet onglet est présent, je pense qu’il doit pouvoir modifier l’onglet principal pour cacher les champs ip/mac, ou les mettre read-only, et les gérer auto en fonction des interfaces
|
|
|
Coté IPAM on peut essayer de faire une classe de management des interfaces pour consultation mais je peux rien promettre en fonctionnalités, il vaut mieux que cela soit fait dans un deuxième temps.
|
|
|
|
|
|
Avantages:
|
|
|
|
|
|
* Facile de lister les interfaces d’un système (il suffit de se mettre en subtree sur la machine)
|
|
|
* On peut aussi lister les interfaces des systèmes d’un département (subtree sur le département)
|
|
|
* Gestion ACL et compagnie via le type d’objet interface
|
|
|
* Permet à l’utilisateur de configurer l’affichage colonne et compagnie, de trier comme il veut (à vérifier que ça marche dans un onglet mais ça devrait le faire. A priori yaura pas de boite de filtre par contre)
|
|
|
* Les interfaces sont defacto liée au système: on le supprime, elle sont suprimées, on le déplace elle sont déplacées
|
|
|
* Le lien interface<>système est directement modélisé et ne nécessite pas un champ LDAP + une recherche LDAP, on voit directement dans le dn/l’arbre qui est associé à qui.
|
|
|
ca me convient combien de jours de dev en plus suite a ces changements ?
|
|
|
|
|
|
Périmètre:
|
|
|
|
|
|
* Gestion des interfaces dans les systèmes comme sous-objets avec leur propre type
|
|
|
* Gestion des VLANs et sous-réseaux dans une classe management IPAM
|
|
|
*
|
|
|
Non-compris:
|
|
|
|
|
|
* Intégration webservice
|
|
|
* Gestion/consultation interfaces coté IPAM
|
|
|
* Intégration DHCP/DNS
|
|
|
|
|
|
|
|
|
|