Distribution EOLE

Utilisation d'un serveur central DHCP (avec relais) :
- solution de contournement : permettre l'accès à plusieurs serveurs EAD sur une seule fenêtre (un onglet EAD par serveur). Implique d'ajouter le port 4201 (service ead) dans le modèle 2zones-reference.xml. Et rédaction d'une doc d'accompagnement. (mais ne résoud pas réellement le pb. Chaque serveur est serveur DHCP, pas de gestion centralisée des adresses)
- résolution du cas : demande auprès de l'équipe Eole d'autorisation d'une même adresse MAC si les réseaux sont différents.

--> intégré dans scénario prochain #14762

eSSL-wifi :
gestion du proxy du poste. Quelle méthode adopter pour les postes se connectant dans la zone wifi , et plus généralement quelle méthode de configuration du navigateur pour les postes mobiles :
- proxy.pac du service, proxy local --> la configuration du navigateur doit être modifiée manuellement
- proxy.pac national --> ok en situation de mobilité. Mais n'utilisera jamais le proxy local.
- déployer une solution wpad sur tous les eSSL (qqsoit l'endroit où le poste se connecte , il récupère les valeurs locales, voire nationales)
==> tester, et proposer wpad pour la 2.5.2 ??

---> intégré dans scénario prochain #14759

zones eSSL :
possibilité (et intérêt) d'ajouter une nouvelle zone, pour la ToIP !!?

--> Bonne idée mais mieux vaut attendre un peu --> recommandation TOIP à propuire cette année

EAD :
- prévoir un compte sspécifique assistance pour pouvoir se connecter à l'EAD d'un serveur sans avoir à connaitre le mot de passe root ou éole
- concerne aussi l'ESBL voire l'ECDL

ESSL - WIFI - DHCP :
- changer la conf du logrotate qui conserve actuellement seulement 10 semaines de logs. Passer à 52 semaines.

--> intégré dans scénario prochain #14741

eSSL - WIFI - ERA :
- rajouter la possibilité d'utiliser une variable CREOLE dans la définition des plages horaires afin de laisser aux services la gestion de celles-ci via le zéphir.

--> intégré dans scénario prochain #14739

DHCP
- rajouter la possibilité de gérer une ip haute et une ip basse dans les définitions de plages DHCP plutôt qu'obligatoirement un réseau, cela permettrait de générer des règles iptables de ce type : https://www.frozentux.net/iptables-tutorial/chunkyhtml/x2702.html#TABLE.IPRANGEMATCH

Ajouter une vérifiation sur la présence de valeurs dans le champ ' Réseaux supplémentaires, autorisés à accéder au Proxy et au cache DNS'. Actuellement il peut-etre laissé vide, et si c'est le cas la valeur "None/" pollue les fichiers de conf de squid et bind9. Et empeche le démarrage de ces services. #14873