Description
Cette page est là pour tenter d'expliquer assez rapidement le fonctionnement de BCfg2. Pour avoir une description complète vous pouvez consulter le site web.
Il est préférable d'avoir d'abord lu la page d'introduction.
Dépôt
Principe général
Le dépôt est utilisé par le serveur pour générer la description de l'état d'un client.
La procédure est la suivante:
- Génération d'une configuration abstraite
- Instanciation des éléments de la configuration abstraite
Nous allons maintenant décrire plus précisément tout ça.
La configuration abstraite
La configuration abstraite d'un client correspond à un ensemble d'éléments décrits par le tableau suivant:
Type BCfg2 |
Paramètre |
Description |
Un nom de fichier |
Un fichier de configuration a placer sur le client |
|
Package |
Un nom de paquet (sans sa version) |
Un paquet à installer sur le client |
Service |
Un nom de service |
Un service qui doit être lancé ou non |
Ces éléments sont les principaux utilisés, consultez la doc officielle pour la liste complète.
La configuration littérale
La configuration littérale consiste en une version concrète de ce qui précède:
Élément abstrait |
Élément concret |
Le contenu du fichier |
|
Package |
La version du paquet |
Service |
Comment le lancer (avec /etc/init.d, ...), si il doit être actif ou non... |
Les éléments concrets sont associés aux éléments abstraits par les générateurs.
Un générateur est en fait une fonction qui a un élément abstrait et aux informations sur un client (= les méta-données, décrites plus loin) associe l'élément concret correspondant.
Chaque générateur indique la liste des éléments abstraits pour lesquels il peut générer une configuration concrète. Chaque élément abstrait doit pouvoir être généré par exactement un générateur. Dans le cas contraire, considéré comme une erreur, BCfg2 refusera de produire la configuration concrète.
L'ensemble de la configuration concrète envoyée au client est contenue dans un fichier xml, on peut l'avoir en utilisant la commande:
# bcfg2 -c <fichier>
ou à l'aide de l'utilitaire bcfg2-info
La configuration de chaque générateur se trouve dans /var/lib/bcfg2/<nom du plug-in>.
Note: regarder ../Plugins pour la description de chacun des plug-ins.
Les bundles
Il peut être utile de "lier" différents éléments de configuration entre eux. Par exemple si service S lit sa configuration dans un fichier de configuration C que l'on a modifié et intégré dans BCfg2, on veut que lorsque le fichier C soit modifié, le service S soit redémarré (ou juste rechargé).
C'est le rôle des bundles. Un bundle est tout simplement un ensemble d'éléments de configuration abstraits. Si un client contient un bundle dans ses méta-données alors BCfg2 va se charger de gérer toutes les dépendances entre les différents éléments de ce bundle lors de la reconfiguration d'un serveur.
La définition des bundles se trouve dans /var/lib/bcfg2/Bundler.
Comment est décrite la configuration abstraite
La configuration abstraite est décrite par un système de groupe. À la base à chaque client est associé un groupe (cette association est faite dans le fichier /var/lib/bcfg2/Metadata/clients.xml).
Un groupe est un ensemble de bundles ainsi que de de noms d'autres groupes (cette description est faite dans le fichier /var/lib/bcfg2/Metadata/groups.xml).
En partant du groupe associé à un client puis en parcourant récursivement tous les groupes contenus dans ces groupes on obtient un ensemble de groupes et de bundles qui constitue avec le nom du client ses méta-données (celles qui sont passées au générateur).
Enfin en expansant tout les bundles (le contenu des bundles peut dépendre des groupes du client), on obtient un ensemble d'éléments de configuration abstraits qui constitue la configuration abstraite du client.
Note : comme certains éléments ne nécessitent pas forcément de bundles - par exemple si on veut que son éditeur de texte favori soit installé sur tous les serveurs - on dispose du plug-in Base qui liste des éléments de configuration (avec possibilité de filtrer sur les groupes du client) sans aucune relation entre eux.
Note : pour qu'un groupe puisse être associé à un client dans clients.xml il faut qu'il ait le tag profile défini à true.
On voit ainsi qu'à ce niveau on a une grande liberté d'organisation. Les choix effectués pour le Cr@ns sont décrits ici.
