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)
};
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.
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.
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.