Concepts clé

Source de données

Une source depuis laquelle le serveur va collecter des données. Cela peut être tout ce qui contient des données : base de données, annuaire LDAP, service Web, fichier plat…

Plugin source de données

Un plugin Hermes chargé de collecter des données à partir d’un type de source de données spécifique et de les fournir au serveur.

Serveur

application hermes-server : interroge les sources de données à intervalles réguliers et convertit tous les changements entre les données récentes et les données précédentes en événements qui seront envoyés sur un bus de messages par un plugin producteur de bus de messages.

Bus de messages

Service externe comme Apache Kafka ou RabbitMQ qui collecte les événements du serveur et les fournit aux clients dans le même ordre que celui où ils ont été émis.

Plugin producteur de bus de messages

Un plugin Hermes exécuté par le serveur, chargé d’émettre des événements sur un type de bus de messages spécifique.

Plugin consommateur de bus de messages

Un plugin Hermes exécuté par les clients, chargé de consommer des événements depuis un type de bus de messages spécifique.

Client

application hermes-client : consomme les événements du bus de messages via le plugin consommateur de bus de messages et appelle les méthodes appropriées implémentées sur le plugin client pour propager les changements de données sur la cible.

Corbeille

Si activée dans la configuration, le client ne supprimera pas immédiatement les données mais les stockera dans la corbeille pendant le nombre de jours configuré. Si les données sont ajoutées à nouveau durant ce délai, le client les restaurera depuis la corbeille. Sinon, une fois la limite de rétention de la corbeille atteinte, les données seront supprimées.

Selon l’implémentation choisie sur le plugin client, cela peut permettre de nombreux scénarios, e.g. désactiver un compte ou le garder actif pendant une période de grâce.

File d’erreurs

Lorsqu’une exception est levée lors du traitement d’un événement sur le plugin client, l’événement est stocké dans une file d’erreurs. Tous les événements suivants concernant les mêmes objets de données ne seront pas traités mais stockés dans la file d’erreurs jusqu’à ce que le premier soit traité avec succès. Le traitement des événements dans la file d’attente d’erreurs est relancé périodiquement.

Auto remédiation

Parfois, un événement peut être stocké dans la file d’erreurs en raison d’un problème de données (e.g. un nom de groupe avec un point terminal génèrera une erreur sur Active Directory). Si le point terminal est ensuite supprimé du nom de groupe sur la source de données, l’événement modified sera stocké dans la file d’erreurs et ne sera pas traité tant que le précédent n’aura pas été traité, ce qui ne pourra jamais se produire sans procéder à une opération risquée et non-souhaitable : l’édition manuelle du fichier cache du client.

L’auto remédiation résout ce type de problèmes en fusionnant les événements d’un même objet dans la file d’erreurs. Elle n’est pas activée par défaut, car elle peut perturber l’ordre de traitement normal des événements.

Plugin client

Un plugin Hermes exécuté par le client, chargé d’implémenter des méthodes simples de traitement d’événements visant à propager les changements de données vers un type de cible spécifique.

Plugin d’attribut

Un plugin Hermes exécuté par le serveur ou le client qui sera utilisable comme un nouveau filtre Jinja, permettant de modifier des données.

Initsync

Un client ne peut pas commencer à traiter de nouveaux événements en toute sécurité sans disposer de l’ensemble du jeu de données complet préalable. Ainsi, le serveur est capable d’envoyer une séquence d’événements spécifique appelée initsync qui contiendra le modèle de données serveur et l’ensemble de données. Un client déjà initialisé l’ignorera silencieusement, mais un client non initialisé le traitera pour initialiser sa cible en ajoutant toutes les entrées fournies par la séquence initsync, puis commencera ensuite à traiter normalement les événements suivants.

Modèle de données (datamodel)

Comme il existe des différences entre eux, veuillez consulter modèle de données serveur et modèle de données client.

Type de données

Également nommé “type d’objet”. Un type de données avec son mapping d’attributs qui sera géré par Hermes.

Clé primaire

L’attribut type de données qui permet de distinguer une entrée d’une autre. Il doit évidemment être unique.

Modèle de données serveur

Configuration des types de données que le serveur doit gérer, avec leurs mapping d’attributs respectifs. Le nom de l’attribut distant est le nom de l’attribut utilisé sur la source de données.

Le modèle de données du serveur est construit en spécifiant les éléments suivants :

Politique de conflit de fusion

Définit le comportement si un même attribut obtient des valeurs différentes sur différentes sources de données.

Contraintes de fusion

Permet de déclarer des contraintes pour garantir la cohérence des données lors de la fusion des données, lorsque le serveur interroge plusieurs sources de données.

Clés étrangères

Permet de déclarer des clés étrangères dans un type de données, que les clients utiliseront pour appliquer leur politique de clés étrangères. Voir Clés étrangères pour plus de détails.

Contraintes d’intégrité

Permet de déclarer des contraintes entre plusieurs types de données pour assurer la cohérence des données.

Attributs à ne mettre qu’en cache

Attributs du modèle de données qui seront uniquement stockés dans le cache, mais ne seront ni envoyés dans les événements, ni utilisés lors de la comparaison avec le cache.

Attributs secrets

Attributs du modèle de données qui contiendront des données sensibles, comme des mots de passe, et ne doivent jamais être stockés dans le cache ni affichés dans les journaux. Ils seront tout de même envoyés aux clients, à moins qu’ils ne soient également définis comme attributs locaux.

Remarque

Comme ces attributs ne sont pas mis en cache, ils seront considérés comme ajoutés CHAQUE fois que le serveur interrogera les sources de données.

Attributs locaux

Attributs du modèle de données qui ne seront pas envoyés dans les événements, mis en cache ni utilisés lors de la comparaison avec le cache, mais qui pourront être utilisés dans les templates Jinja.

Modèle de données client

Configuration des types de données que le client doit gérer, avec leur mapping d’attributs. Le nom de l’attribut distant est le nom de l’attribut utilisé sur le modèle de données du serveur.

Information

Si vous vous demandez pourquoi ce mapping est nécessaire, voici pourquoi :

  1. il permet la transformation des données locales via des filtres Jinja et les plugins d’attribut sur le client.
  2. il permet de réutiliser (et de partager) les plugins client sans nécessiter de modification du modèle de données serveur ni du code du plugin, mais simplement en modifiant le fichier de configuration client.

Le modèle de données client est construit en spécifiant les éléments suivants :

Mapping d’attributs

Également appelé “attrsmapping”. Mapping (clé/valeur) qui associe le nom de l’attribut interne (en tant que clé) à celui distant (en tant que valeur). Le distant peut être un modèle Jinja pour transformer des données avec des filtres Jinja et des plugins d’attribut.