#recette1

Question : Comment construire un fichier de "politique" cfengine de base ?

Réponse :

Un seul fichier suffit généralement à décrire la politique à suivre pour automatiser l'administration d'un parc informatique donné. Commençons d'abord par ces quelques définitions cruciales pour comprendre la structure d'un fichier de politique cfengine3.

Un fichier de politique cfengine3 est constitué de conteneurs (de type bundles ou bodies).

Les bundles contiennent des groupements de promesses.

Les bodies contiennent des attributs de configuration liés souvent à des promesses.

Une promesse est une déclaration d'intention concernant un fichier, une commande, un service ou un espace de stockage par exemple.

L'exemple suivant décrit une politique qui vise à assurer qu'un fichier donné existe sur tous les nœuds de notre parc, de le créer dans le cas contraire et d'afficher un message de log après chaque vérification faire par cfengine.

body common control { bundlesequence => { "recette1" }; } bundle agent recette1 { files: "/tmp/premier.txt" create => "true"; reports: cfengine:: "premiere recette executee"; }

Procédons maintenant à l'explication de chaque ligne de notre fichier .cf :

Ligne 1: Le "body common" est la section où sont définis les attributs communs à tous les bundles présents dans le fichier politique.

Ligne 3: Ici l'attribut bundlesequences donne la liste des bundles à invoquer. Ici nous allons invoquer le bundle "recette1" de type agent.

Ligne 7: Ici est défini le bundle (ou conteneur de promesses) de type agent nommé "recette1". Ce conteneur contient deux promesses (une promesse concernant un fichier et une autre concernant un rapport d'activité à afficher).

Ligne 9: le mot clé "files:" indique que la promesse suivante est de type "files" et concerne donc un fichier.

Ligne 10 et ligne 11: Plus précisément, la promesse concerne le fichier "/tmp/premier.txt". Le corps de la promesse est constitué de l'attribut "create" ayant la valeur "true". Cela indique que dans le cas où la promesse n'est pas tenue (c'est à dire dans le cas où le fichier nommé "premier.txt" n'existe pas dans le répertoire "/tmp"), l'agent d'exécution cfengine3, doit créer ce fichier pour satisfaire cette promesse.

Ligne 13: le mot clé "reports:" indique que la promesse suivante est de type "reports" et concerne donc un rapport d'activité à afficher.

Ligne 15: Plus précisément, la promesse concerne celle d'afficher à chaque exécution de l'agent cfengine3 le message "premiere recette executee" vers la sortie standard.

Ligne 14: Contrairement à la promesse de type "files", celle là est conditionnée par la définition de la classe "cfengine3". Sachant que cette classe est définie par défaut, la promesse sera toujours évaluée. Nous aborderons la notion de classe dans les recettes suivantes.

Vérifier la syntaxe

Sur un nœud donné, exécuter la commande suivante :

$ cf-promises -f recette1.cf

L'absence de message en sortie indique que la syntaxe du fichier de politique recette1.cf est valide. Dans le cas contraire, le message en sortie indique des erreurs de syntaxe.

Exécuter la politique sur un noeud donné

Sur un nœud donné, exécuter la commande suivante :

$ cf-agent -K -f recette1.cf

Cette commande spéciale, exécute la politique contenue dans le fichier recette1.cf sur le nœud en question. Plus tard nous verrons comment cfengine exécute la même politique périodiquement sur plusieurs nœuds en même temps à l'aide d'une architecture client/serveur.

Pour finir