Distribution EOLE

L’analyse détaillée dans le scénario me semble correcte.
Concernant la correction proposée, elle met en lumière un problème de fonctionnalités qui ne pourra peut-être pas être résolu.

Le code actuel, si on met de côté le fait qu’il n’est finalement pas fonctionnel, voulait permettre de renseigner des chemins différents bios/uefi en fonction des plages déclarées dans genconfig. Le déplacement des classes dans la partie globale ne permet pas cette différenciation.
Avant l’introduction de l’uefi, les classes n’étaient pas utilisées comme actuellement et la distinction était possible.

Pour l’instant, deux choix se dessinent :
- utiliser une classe globale et ne plus permettre de renseigner des fichiers différents pour chaque groupe (risque de régression, surtout dans le cas où l’uefi n’est pas utilisé et où la configuration générée est valide telle quelle)
- chercher une autre solution de déclarer la variable filename permettant une allocation dynamique à la délivrance du bail dhcp et une différenciation au moment de la templatisation du fichier.

Le problème pourrait être contourné si on estime que l’uefi peut être généralisé, au moins à l’échelle d’une plage, dispensant ainsi de prévoir les deux cas.

Si je reformule :

AVANT (18/11/2021 #33317)
Il n'y avait que du boot legacy et dans genconfig (onglet dhcp si le service de boot tftp est activé) on pouvait choisir par plage DHCP un fichier de boot différent :

group A {
  option routers "192.168.1.1";
  filename "totoA.pxe";
}
group B {
  option routers "192.168.10.1";
  filename "totoB.pxe";
}

MAINTENANT
Le boot UEFI est pris en compte et dans genconfig (onglet dhcp si le service de boot tftp est activé) on peut choisir par plage DHCP un fichier de boot legacy et un fichier UEFI différent. De même, dans l'onglet TFTP on peut choisir un fichier de boot UEFI et un fichier legacy. Ainsi, si aucun fichier UEFI n'est spécifié, la conf DHCP est quasi identique à l'ancienne (sans class). Le problème vient de l'instruction "match" dans les class dans les groups. À partir du moment où un match est positif, la class et le group (et ses confs) sont appliqués.

group A {
  option routers "192.168.1.1";
  class "Legacy-totoA" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient" 
    if substring (option vendor-class-identifier, 15, 5) = "00000" {
      filename "totoA.pxe";
  }
  else {
    filename "totoA.uefi";
  }
}
group B {
  option routers "192.168.10.1";
  filename "totoB.pxe";
}
group C {
  option routers "192.168.20.1";
  class "Legacy-totoC" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient" 
    if substring (option vendor-class-identifier, 15, 5) = "00000" {
      filename "totoC.pxe";
  }
  else {
    filename "totoC.uefi";
  }
}

Là, dans ce cas, si le client envoie une requête qui match la condition dans les classes, le client va toujours matcher le premier bloc et recevoir en ip de routeur 192.168.1.1.

Les classes doivent être en dehors de group (et aussi de subnet en ce qui concerne le bout de config DHCP sur le tftp ?) et il ne devrait y en avoir qu'une class par "match". Cela implique dans l'implémentation actuelle que tous les fichiers de boot UEFI ou legacy doivent être identiques (si la condition est matchée).
Bref, l'implémentation est complètement à revoir. Pour cela, il faudrait maquetter pour trouver une solution (d'autres conditions possibles ? Une autre instruction que match ? Boot à multi-étage ? Etc...) et cela demande beaucoup de temps et donc, devrait être fait dans une future tâche. Pour le moment un simple workaround en extériorisant la class et en prenant comme fichiers les "premiers" fichiers trouvés dans la conf eole, devrait suffire (c'est le comportement actuel finalement, sauf que là on matcherait aussi le bon groupe/on enverrai les bonnes options DHCP). Rajouter un warning dans la doc semble nécessaire aussi. Est-ce que ce plan d'action convient ?