Bundle-Aktivierung über promises.cf

Wenn man die Bundles nicht direkt von der Kommandozeile aufruft, wie es nur zum Testen gedacht und HIER erklärt ist, gibt es mehrere Möglichkeiten der Bundle-Aktivierung. Die erste Möglichkeit ist es, das in der /var/cfengine/masterfiles/promises.cf zu tun. Hier findet man den body common control direkt ganz oben. In der bundlesequence gibt man das/die bundle/s an und bei inputs (etwas tiefer) die promise-Datei/n, die das/die Bundle/s enthalten. Das kann ein einzelnes Bundle und eine einzelne Promise-Datei sein:

body common control
{
  bundlesequence => {
                      "MyBundle"",
                    };
  inputs =>  {
               MyPromise.cf, ### Kommentar: das MyBundle befindet sich in der MyPromise.cf ###
             };

oder ganze Listen von Promises und Bundles, die in unserem eigenen common bundle als Variablen definiert sind. Das kann in unserer eigenen Promise-Datei, bspw. /var/cfengine/masterfiles/MyPromises/MyPromises.cf, so aussehen:

bundle common MyPromiseSetup
{
vars:
  rhel6::
    "MyBundles" slist => { "bundle1", "bundle2", "bundle4" };
    "MyPromises" slist => { "promise-datei-1", "promise-datei-2", "promise-datei-4" };
} 

Hier ist die Klasse rhel6 als Entscheidungskriterium eingesetzt; die beiden Variablen werden also nur auf Redhat6-Systemen mit den definierten Listen gefüllt. In der promises.cf gibt man dann diese Variablen an:

body common control
{
  bundlesequence => {
                     "MyPromiseSetup", ### Kommentar: Das ist der Name des eigenen common bundles, siehe 12 Zeilen drüber ###
                     @(MyPromiseSetup.MyBundles) ### Kommentar: das @ Zeichen sagt dem cf-agent, dass er durch alle Listenelemente (also durch alle Bundles) der Variablen MyBundles laufen soll. ###
                    };
  inputs =>  {
               MyPromise.cf,
               @(MyPromiseSetup.MyPromises)
             };

Bundle-Aktivierung über main.cf

Eine andere (hard-codierte) Möglichkeit ist es die Datei main.cf zu verwenden. Hierin kann keine Bundlesequence definiert werden. Hier finden Methoden ihre Anwendung. Die Datei /services/main.cf ist recht leer, um nicht von anderen Policies abzulenken:

bundle agent main
# User Defined Service Catalogue
{
methods:
# Activate your custom policies here
}

Hier ruft man dann unter methods seine Bundles auf, bspw:

methods:
    "any" ### KOMMENTAR: Das ist ein Platzhalter für die Zukunft, also zuerst einfach "any" übernehmen
      usebundle => myBundle("$(ParameterListe)"); ### Siehe <a href="../startbeispiel.html">Methods-Beispiel im Startbeispiel</a>
      usebundle => EinAnderesBundle("$(Paramter)");
      usebundle => UndNocheinBundle("$(Parameter)"):

Das waren die hard-codierten Möglichkeiten, die eigene Policy, bestehend aus Promises und Bundles, zu aktivieren. Hard-codiert, weil die Namen der Bundles und Promises-Dateien hier fest eingetragen werden.

Bundle-Aktivierung via autorun

Seit der Version 3.6 können Bundles via Tags aktiviert werden. Das Feature heißt "autorun". In der ausgelieferten Konfiguration sucht autorun nach Dateien in /var/cfengine/inputs/services/autorun, die den Tag autorun gesetzt haben; alle diese Dateien werden ausgeführt, also die Bundles aktiviert. Nach der Installation liegt dort diese Beispieldatei:

CFE-Node001:/var/cfengine/inputs/services/autorun # cat hello.cf
bundle agent hello_world_autorun
{
meta:
  "tags" slist => { "autorun" };

reports:
  verbose_mode::
    "$(this.bundle): Hello, this is an automatically loaded bundle";
}

Das Bundle hello_world_autorun wird somit automatisch ausgeführt; lässt man den Agenten mit -v (cf-agent -v) im verbose mode laufen, wird man den Report "hello_world_autorun: Hello, this is an automatically loaded bundle" im Syslog sehen bzw. auf der Konsole oder wohin man sich die Ausgabe auch umleitet.

Abstrakte Möglichkeiten der Bundle-Aktivierung

Es gibt noch weitere abstrakte Möglichkeiten der Bundle-Aktivierung; bspw. dass ein Bundle nur dann evaluiert wird, wenn es eine Hardclass des gleichen Namens gibt. Man könnte dann ein Bundle "SLES11_4" (für SuSE 11, ServicePack 4) nennen und das wird nur ausgeführt, wenn es eine gleichnamige Hardclass gibt. Diese wird es nur auf SLES11_4 Systemen geben. Auf diese Art und Weise lassen sich sehr ausgefeilte Automationsmechanismen realisieren.