Distribution EOLE

Je propose de découper le problème en deux :
- un mécanisme de "coupure"
- une procédure de déclaration et d’application des plages

Pour le mécanisme de coupure, le plus efficace me semble être la vérification de la présence d’un fichier et de l’utilisateur : minimiser le traitement à chaque courriel traité et laisser la possibilité de ne pas couper le service de courriel pour certains utilisateurs (système par exemple).
La vérification peut être déclenchée dans l’ACL rcpt avec la substitution ${run {commande }{}{}}.
Le fichier dont la présence sert de condition peut-être placé dans un dossier volatile géré par systemd (/var/run/eole/flags/ par exemple).

Ce fichier/drapeau peut être géré manuellement.

La seconde partie du problème concerne la gestion automatique de ce fichier.

Pour créer et supprimer le fichier à certaines heures, on peut utiliser l’utilitaire standard "at".
Pour programmer les tâches "at", on peut envisager de lire un "calendrier" à intervalle régulier pour transcrire les début et fin de plage en commande "touch" et "unlink".

Selon la flexibilité et l’ergonomie souhaitée pour le calendrier, on pourrait envisager plusieurs approche. Le première approche serait de reprendre le mécanisme utilisé pour les plages d’ouverture du réseau dans l’EAD2 (déclaration d’une semaine type uniquement). Une autre approche serait de maintenir un calendrier ics local (format vdir) par import d’un fichier ics, synchronisation sur un calendrier distant ou édition local des événements.

La solution du calendrier ics me semble plus avantageuse vu la flexibilité de déclaration qu’elle permet mais ne se justifie peut-être pas par le cas d’usage (la demande laisse penser qu’une plage unique modifiée par reconfigure est suffisante mais ça me semble trop rigide : quid des jours fériés, des week-ends, des vacances, etc.).

Voici quelques consignes de coupure de la messagerie auxquelles les établissements peuvent être soumis :
- coupures durant les examens ;
- coupures ponctuelles ;
- coupures régulières.

Les établissements impactés utilisent des modules à partir de la version 2.6.2.
Pour cette version, les possibilités d’exploiter le format ics ne sont pas les mêmes (comprendre, les utilitaires identifiés ne sont pas dans les dépôts de paquets voire ne sont pas compatibles).
La partie exim (conditionner à la présence d’un drapeau) peut-être mise en place. Seule l’automatisation de la gestion du drapeau devra être différente (moins flexible probablement).

Pour les versions supérieures à 2.6.2, l’implémentation proposée est la suivante :
- découpage de la gestion des drapeaux et de leur utilisation (comme en 2.6.2 finalement, la gestion étant laissée à l’administrateur)
- la gestion est déclarée dans un nouvel onglet dans genconfig (nouveau dictionnaire voire nouveau projet ?)
- la gestion consiste à associer un drapeau (nom de fichier) à une méthode de création, suppression
- les drapeaux déclarés dans ce nouvel onglet peuvent être utilisés dans d’autres onglets (mais sans lien, compliqué à établir au niveau genconfig)
- les méthodes de gestion proposées sont "manuelle" (gestion externe aux mécanismes eole mais drapeau listé et état récupérable dans des agents ?), "calendrier" (système de lecture de calendrier, de programmation de la commande at), "fixe" (variables dans genconfig pour déclarer des plages et programmer la commande at).