Gestion de drapeaux

Un drapeau est un fichier servant de marqueur d’un état du système. Un drapeau, par sa présence ou son absence, permet d’identifier deux états différents.

Une gestion de drapeaux est apparue utile pour des raisons d’automatisation de leur création et suppression.

La gestion des drapeaux est accessible via l’installation du paquet optionnel eole-flag disponible à partir de la version 2.7.2.

Exemple

Le premier cas d’usage est celui du conditionnement du comportement d’un programme en fonction d’un planning. C’est le cas mis en place pour la messagerie dont une coupure peut être souhaitée à certaines heures de la journée

Principe de fonctionnement

La gestion de drapeau retenue s’articule autour des points suivants :

  • un emplacement dédié géré par systemd-tmpfiles impliquant que les drapeaux ne doivent pas être perçus comme persistants ;

  • un nom correspondant au nom du fichier créé ;

  • une méthode d’automatisation.

L’automatisation est pensée comme l’application d’un planning, au moins une fois par jour via un timer déclenchant l’interprétation d’un planning et termes de tâches at. Seules les tâches du jour sont programmées.

Un planning est propre à chaque drapeau quoiqu'un même planning puisse être utilisé pour l'automatisation de plusieurs drapeaux.

Un planning est constitué de la déclaration d’une série de plages avec, notamment, une heure de début et une heure de fin. Ces plages sont utilisées pour programmer la création et la suppression des drapeaux.

Pour des raisons d’ergonomie de saisie des plannings, il est possible de choisir si une plage correspond à la présence ou à l’absence du drapeau.

Exemple

Examinons la configuration nécessaire à la coupure de la messagerie en dehors des plages de travail.

D’un côté, Exim peut être configuré pour interdire l’envoi de courriel si un fichier spécifique est présent dans le système de fichiers. De l’autre côté, on peut automatiser la création et la suppression de ce fichier spécifique via un planning d’évènements.

Il est possible d’utiliser les événements comme marqueur de la présence du fichier ou comme marqueur de son absence. La différence tient au nombre d’événements nécessaires pour représenter les plages de fermeture au cours d’une journée. Dans le cas classique envisagé ici, il faut un événement si celui-ci marque l’absence du fichier verrouillant l’envoi de courriels ou deux événements si ceux-ci marquent la présence de ce fichier.

Méthodes d’automatisation

Deux méthodes sont actuellement implémentées :

  • manuelle
  • fichier

La méthode manuelle n’est pas, à proprement parler, une méthode d’automatisation. Toutefois, la déclaration d’un drapeau géré manuellement permet de pouvoir recenser ce dernier.

La méthode d’automatisation basée sur un fichier permet de fournir le planning sous forme de fichier et, ainsi, d’exploiter les possibilités de dépôt du module Zéphir.

Actuellement, le fichier doit contenir le planning au format json dont un exemple est fourni ci-après.

Le planning peut servir à déclarer des plages qui ont différentes périodes de répétition :

  • weekly : plages d’une semaine type ;
  • monthly : plages répétées à des jours précis tous les mois ;
  • yearly : plages répétées à des jours précis tous les ans ;
  • unique: plages propres à des jours précis de l’année.

Chaque plage est déclarée en indiquant une date, une étiquette, une heure de début et une heure de fin.

L’étiquette est off est utilisée en opposition à l’étiquette on. Elle permet d’annuler un événement d’une période moins prioritaire.

Les heures de début et de fin de plages sont à la minute près et sont interprétées en heure locale.

La date adopte un format différent selon le contexte :

weekly : jour de la semaine (de 1 à 7, du lundi au dimanche) ;

monthly : numéro du jour du mois (les dépassements sont ignorés par le traitement) ;

yearly : numéros du mois et du jour sans mention de l’année (MM-JJ) ;

unique : date complète (AAAA-MM-JJ).

1
{
2
    "monthly": [
3
        [1, "on", "07:30", "17:30"],
4
        [4, "on", "07:30", "17:30"]
5
    ],
6
    "weekly": [
7
        [1, "on", "08:00", "17:00"],
8
        [2, "on", "08:00", "17:00"],
9
        [3, "on", "08:00", "17:00"],
10
        [4, "on", "08:00", "17:00"],
11
        [5, "on", "08:00", "17:00"]
12
    ],
13
    "yearly": [
14
        ["12-25", "off", "00:00", "24:00"]
15
    ],
16
    "unique": [
17
        ["2024-07-04", "off", "00:00", "24:00"],
18
        ["2024-06-27", "off", "00:00", "24:00"],
19
        ["2024-07-06", "off", "00:00", "24:00"]
20
    ]
21
}

La priorité des plages déclarées est fonction du contexte. Seules les plages du contexte le plus prioritaire sont prises en compte. Du plus prioritaire au moins prioritaire, les contextes sont ordonnés de la façon suivante en fonction de leur spécificité :

  1. unique,

  2. yearly,

  3. monthly,

  4. weekly.

Configuration

La configuration de la gestion des drapeaux est regroupée dans l’onglet spécifique Drapeaux.

Les variables de configuration disponibles sont variables selon la méthode d’actualisation sélectionnée.

  • Nom du drapeau : nom du fichier qui sera créé sur le système de fichier (pas de chemin absolu) ;

  • Méthode d’actualisation du drapeau : manuelle ou fichier, indique quel mécanisme mettre en œuvre pour la création des tâches de gestion du drapeau (si manuelle, aucun mécanisme n’est mis en place).

Les variables suivantes sont disponibles pour la méthode d’actualisation basée sur un fichier.

  • Impact d’une plage de programmation : drapeau présent ou drapeau absent, indique si la plage doit être interprétée comme une plage de présence du fichier ou une plage d’absence du fichier ;

  • Fichier de déclaration des plages : emplacement du fichier de planning sur le système de fichier local (le fichier peut y être déposé par n’importe quel moyen à la disposition de l’administrateur) ;

  • Format de déclaration des plages : format du planning (actuellement, seul un planning au format json respectant le modèle décrit précédemment est pris en charge).

Utilisation en ligne de commande

Le paquet installe un timer flag-switch.timer, un service flag-switch.service ainsi qu’une commande flag-switch.

Le service interprétant le planning pour le traduire sous forme de tâche pour la commande at est déclenché via un timer quotidien lancé à 00:00 au délai d'exécution près.

Le service peut également être lancé à la demande via la commande systemctl start flag-switch.service. C’est notamment utile dans le cas où le fichier de planning aurait été mis à jour après exécution du timer.

Enfin, la commande flag-switch peut être utilisée en dehors du contexte du service pour, notamment, supprimer les programmations relatives aux drapeaux ou supprimer tous les drapeaux en place.

Remarque

Pour éviter les tâches en doublon, l’application d’un planning s’accompagne toujours de la suppression, au préalable, des tâches précédemment programmées.