Funktionsweise von Commit-Skripten
Commitskripte enthalten Anweisungen zur Durchsetzung benutzerdefinierter Konfigurationsregeln und werden während des Commit-Prozesses aufgerufen, bevor die Standardmäßigen Junos OS-Gültigkeitsprüfungen durchgeführt werden. Sie aktivieren Commit-Skripte, indem Sie die Namen einer oder mehrerer Commit-Skriptdateien auf [edit system scripts commit] Hierarchieebene auflisten. Diese Dateien müssen dem entsprechenden Commit-Skriptverzeichnis auf dem Gerät hinzugefügt werden.
Wenn Sie einen Commit-Vorgang ausführen, führt Junos OS jedes Skript nacheinander aus und übergibt die Informationen in der Kandidatenkonfiguration nach der Vererbung an die Skripte. Das Skript untersucht die Konfiguration, führt die erforderlichen Tests und Validierungen durch und generiert eine Reihe von Anweisungen für die Ausführung bestimmter Aktionen. Nachdem alle Commit-Skripte ausgeführt wurden, verarbeitet Junos OS alle Anweisungen der Skripte. Wenn der Commit-Prozess nicht durch ein Commit-Skript angehalten wird, wendet Junos OS alle Commit-Skriptänderungen an und führt seine endgültige Prüfung der Checkout-Konfiguration durch.
Wenn Sie eine Konfiguration festlegen, die von einem oder mehreren Commit-Skripten untersucht wird, müssen Sie möglicherweise den Arbeitsspeicher erhöhen, der den Commit-Skripten zugewiesen wird, um die Verarbeitung großer Konfigurationen zu ermöglichen. Standardmäßig beträgt die maximale Speichermenge, die für den Datensegmentteil eines ausgeführten Skripts zugewiesen wird, die Hälfte des insgesamt verfügbaren Arbeitsspeichers des Systems, bis zu einem maximalen Wert von 128 MB. Um den maximalen für jedes ausgeführte Commit-Skript zugewiesenen Arbeitsspeicher zu erhöhen, konfigurieren Sie die max-datasize size Anweisung mit einer entsprechenden Speichergrenze in Bytes auf Hierarchieebene [edit system scripts commit] , bevor Sie die Konfiguration festlegen.
Commit-Skriptaktionen können das Generieren von Fehlern, Warnungen und Systemprotokollmeldungen umfassen. Wenn Fehler generiert werden, schlägt der Commit-Vorgang fehl, und die Kandidatenkonfiguration bleibt unverändert. Dies ist das gleiche Verhalten wie bei Standard-Commit-Fehlern. Commit-Skripte können auch Änderungen an der Systemkonfiguration generieren. Da die Änderungen geladen werden, bevor die Standardvalidierungsprüfungen durchgeführt werden, werden sie für die korrekte Syntax validiert, genau wie Anweisungen, die bereits in der Konfiguration vor der Anwendung des Skripts vorhanden sind. Wenn die Syntax korrekt ist, wird die Konfiguration aktiviert und wird zur aktiven, betrieblichen Gerätekonfiguration.
Commit-Skripte können keine Konfigurationsänderungen an geschützten Anweisungen oder innerhalb geschützter Hierarchien vornehmen. Wenn ein Commit-Skript versucht, eine geschützte Anweisung oder Hierarchie zu ändern oder zu löschen, gibt Junos OS eine Warnung aus, dass die Änderung nicht vorgenommen werden kann. Wenn ein geschütztes Konfigurationselement nicht geändert wird, wird das Commit-Skript oder der Commit-Prozess nicht angehalten.
In den folgenden Abschnitten werden mehrere wichtige Konzepte im Zusammenhang mit der Ein- und Ausgabe von Commit-Skripten diskutiert:
Commit-Skripteingabe
Die Eingabe für ein Commit-Skript ist die Kandidatenkonfiguration nach der Vererbung im Junos XML API-Format. Der Begriff Postvererbung bedeutet, dass alle Konfigurationsgruppenwerte von ihren Zielen in der Kandidatenkonfiguration geerbt wurden und dass die inaktiven Teile der Konfiguration entfernt wurden. Weitere Informationen zu Konfigurationsgruppen finden Sie im CLI-Benutzerhandbuch.
Wenn Sie den commit Befehl ausstellen, generiert Junos OS automatisch die Kandidatenkonfiguration im XML-Format und liest sie in den Verwaltungsprozess (mgd), in dem die Eingaben von Commit-Skripten ausgewertet werden.
Um das XML-Format der Kandidatenkonfiguration nach der Vererbung in der CLI anzuzeigen, erteilen Sie den show | display commit-scripts view Befehl.
[edit] user@host# show | display commit-scripts view
Geben Sie den show groups | display commit-scripts Befehl aus, um alle Konfigurationsgruppendaten anzuzeigen, einschließlich skriptgenerierten Änderungen an den Gruppen.
[edit] user@host# show groups | display commit-scripts
Ausgabe von Commit-Skripten
Während des Commit-Prozesses werden aktivierte Commit-Skripte sequenziell ausgeführt, und die Commit-Skriptausgabe oder Befehlssatz wird an Junos OS bereitgestellt. Nachdem alle Commit-Skripte ausgeführt wurden, verarbeitet Junos OS alle Anweisungen der Skripte.
Commit-Skriptaktionen können das Generieren von Warnungs-, Fehler- und Systemprotokollmeldungen sowie das Vornehmen anhaltender und vorübergehender Änderungen an der Konfiguration umfassen. Tabelle 1 beschreibt kurz die verschiedenen Elemente, Vorlagen und Funktionen, mit denen Commit-Skripte Junos OS anweisen können, während des Commit-Prozesses verschiedene Aktionen auszuführen. In einigen Fällen gibt es mehrere Möglichkeiten, dieselbe Aktion auszuführen. Da SLAX- und XSLT-Skripte eine Ergebnisstruktur zurücksenden, werden Ausgabeelemente wie <syslog><message> die in SLAX- und XSLT-Skripten direkt dem Ergebnisbaum hinzugefügt.
Ausgabe von Commit-Skripten |
SLAX / XSLT |
Python |
|---|---|---|
Generieren Sie eine Warnmeldung an den festlegenden Benutzer. |
|
jcs.emit_warning() |
Generieren Sie eine Fehlermeldung und führen Sie dazu, dass der Commit-Vorgang fehlschlägt. |
|
jcs.emit_error() |
Generieren Sie eine Systemprotokollmeldung. |
jcs:syslog()
|
jcs.syslog() |
Generieren Sie eine dauerhafte Änderung der Konfiguration. |
|
emit_change(content, "ändern", format) |
Generieren Sie eine vorübergehende Änderung der Konfiguration. |
|
emit_change(content, "transient-change", format) |
Generieren Sie eine anhaltende Änderung relativ zum aktuellen Kontextknoten , wie durch einen XPath-Ausdruck definiert. |
XSLT <xsl:call-template name="jcs:emit-change"> <xsl:with-param name="content"> SLAX call jcs:emit-change() {
with $content = { }
}
|
– |
Generieren Sie eine transiente Änderung relativ zum aktuellen Kontextknoten, wie durch einen XPath-Ausdruck definiert. |
XSLT <xsl:call-template name="jcs:emit-change"> <xsl:with-param name="tag" select="'transient-change'"/> <xsl:with-param name="content"> SLAX call jcs:emit-change() {
with $tag = "transient-change";
with $content = { }
}
|
– |
Generieren Sie eine Warnmeldung zusammen mit einer Konfigurationsänderung. Sie können diese Tags verwenden, um eine Benachrichtigung zu generieren, dass die Konfiguration geändert wurde. |
XSLT <xsl:call-template name="jcs:emit-change"> <xsl:with-param name="message"> <xsl:text> SLAX call jcs:emit-change() {
with $message = {
expr "message";
}
}
|
jcs.emit_warning() |
Junos OS verarbeitet diese Ausgabe und führt die entsprechenden Aktionen aus. Fehler und Warnungen werden an die Junos OS CLI oder an eine Junos XML-Protokoll-Clientanwendung übergeben. Das Vorhandensein eines Fehlers führt automatisch dazu, dass der Commit-Vorgang fehlschlägt. Persistente und vorübergehende Änderungen werden in die entsprechende Konfigurationsdatenbank geladen.
Um die Ausgabe von Fehlermeldungen, Warnungen und Systemprotokollmeldungen aus Commit-Skripten zu testen, erteilen Sie den commit check | display xml Befehl.
[edit] user@host# commit check | display xml
Um eine detaillierte Ablaufverfolgung der Commit-Skriptverarbeitung anzuzeigen, führen Sie den Befehl aus commit check | display detail .
[edit] user@host# commit check | display detail
Systemprotokollmeldungen werden in der Ablaufverfolgungsausgabe nicht angezeigt, sodass Sie den Commit-Check-Vorgang nicht verwenden können, um mit Skript generierte Systemprotokollmeldungen zu testen. Darüber hinaus werden Systemprotokollmeldungen während eines Commit-Vorgangs in das Systemprotokoll geschrieben, nicht jedoch während eines Commit-Überprüfungsvorgangs .
Commit-Skripte und das Junos OS Commit-Modell
Junos OS verwendet ein Commit-Modell, um die Gerätekonfiguration zu aktualisieren. Mit diesem Modell können Sie eine Reihe von Änderungen an einer Kandidatenkonfiguration vornehmen, ohne den Betrieb des Geräts zu beeinträchtigen. Wenn die Änderungen abgeschlossen sind, können Sie die Konfiguration bestätigen. Der Commit-Vorgang speichert die Änderungen der Kandidatenkonfiguration in der aktuellen Konfiguration.
Wenn Sie eine Reihe von Änderungen in der Kandidatenkonfiguration vornehmen, werden zwei Methoden verwendet, um diese Änderungen an die aktuelle Konfiguration weiterzuleiten:
Standard-Commit-Modell: Wird verwendet, wenn keine Commit-Skripte auf dem Gerät aktiv sind.
Commit-Skriptmodell: Integriert Commit-Skripte in das Commit-Modell.
Standard-Commit-Modell
Im Standard-Commit-Modell validiert der Managementprozess (mgd) die Kandidatenkonfiguration basierend auf Junos OS-Standardvalidierungsregeln. Wenn die Konfigurationsdatei gültig ist, wird sie zur aktuellen aktiven Konfiguration. In Abbildung 1 und der zugehörigen Diskussion wird erläutert, wie das Standard commit-Modell funktioniert.
Im Standard-Commit-Modell führt die Software die folgenden Schritte aus:
Wenn die Kandidatenkonfiguration festgelegt wird, wird sie kopiert, um zur Bezahlkonfiguration zu werden.
Der mgd-Prozess validiert die Checkout-Konfiguration.
Wenn kein Fehler auftritt, wird die Checkout-Konfiguration als aktuelle aktive Konfiguration kopiert.
Commit-Modell mit Commit-Skripten
Wenn Commit-Skripte zum Standard-Commit-Modell hinzugefügt werden, wird der Prozess komplexer. Der mgd-Prozess übergibt zunächst eine XML-formatierte Checkout-Konfiguration an einen Skripttreiber, der die Überprüfung der Checkout-Konfiguration durch die Commit-Skripte übernimmt. Wenn die Überprüfung abgeschlossen ist, gibt der Skripttreiber eine Aktionsdatei an den mgd-Prozess zurück. Der mgd-Prozess folgt den Anweisungen in der Aktionsdatei, um die Kandidaten- und Checkout-Konfigurationen zu aktualisieren, Nachrichten an die CLI- oder Client-Anwendung zu senden und Informationen nach Bedarf in das Systemprotokoll zu schreiben. Nach der Verarbeitung der Aktionsdatei führt der mgd-Prozess die Standardmäßige Junos OS-Validierung durch. Abbildung 2 und das begleitende Gespräch erläutern diesen Prozess.
Commit-Skripten
Im Commit-Skriptmodell führt Junos OS die folgenden Schritte aus:
Wenn die Kandidatenkonfiguration festgelegt wird, sendet der mgd-Prozess die KANDIDATENkonfiguration im XML-Format an den Skripttreiber.
Jedes aktivierte Commit-Skript wird für die Kandidatenkonfiguration aufgerufen, und jedes Skript kann eine Reihe von Aktionen für den mgd-Prozess generieren. Die Aktionen werden in einer Aktionsdatei erfasst.
Der mgd-Prozess führt die folgenden Aktionen für Commit-Skriptfehler, Warnungen und Systemprotokollmeldungen in der Aktionsdatei aus:
error: Der mgd-Prozess stoppt den Commit-Prozess (d. h. der Commit-Vorgang schlägt fehl), gibt eine Fehlermeldung an den CLI- oder Junos XML-Protokoll-Client zurück und führt keine weiteren Maßnahmen aus.
Warnung: Der mgd-Prozess leitet die Nachricht an die CLI oder den Junos XML-Protokoll-Client weiter.
Systemprotokollnachricht: Der mgd-Prozess leitet die Nachricht an den Systemprotokollprozess weiter.
Wenn die Aktionsdatei dauerhafte Änderungen enthält, lädt der mgd-Prozess die angeforderten Änderungen in die Kandidatenkonfiguration.
Die Kandidatenkonfiguration wird in die Checkout-Konfiguration kopiert.
Wenn die Aktionsdatei vorübergehende Änderungen enthält, lädt der mgd-Prozess die angeforderten Änderungen in die Checkout-Konfiguration.
Der mgd-Prozess validiert die Checkout-Konfiguration.
Wenn keine Validierungsfehler auftreten, wird die Checkout-Konfiguration kopiert, um die aktuell aktive Konfiguration zu werden.
Commit-Skripte können keine Konfigurationsänderungen an geschützten Anweisungen oder innerhalb geschützter Hierarchien vornehmen. Wenn ein Commit-Skript versucht, eine geschützte Anweisung oder Hierarchie zu ändern oder zu löschen, gibt Junos OS eine Warnung aus, dass die Änderung nicht vorgenommen werden kann. Wenn ein geschütztes Konfigurationselement nicht geändert wird, wird das Commit-Skript oder der Commit-Prozess nicht angehalten.
Änderungen, die während des Commit-Vorgangs an der Kandidatenkonfiguration vorgenommen werden, werden während dieses Commit-Vorgangs nicht von den benutzerdefinierten Regeln bewertet. Hartnäckige Änderungen werden jedoch in der Kandidatenkonfiguration beibehalten und von den benutzerdefinierten Regeln bei späteren Commit-Vorgängen bewertet. Weitere Informationen darüber, wie Commit-Skripte die Kandidatenkonfiguration ändern, finden Sie unter Vermeidung potenzieller Konflikte bei verwendung mehrerer Commit-Skripte.
Vorübergehende Änderungen werden niemals nach den benutzerdefinierten Regeln in Commit-Skripten bewertet, da sie erst in der Checkout-Konfiguration vorgenommen werden, nachdem die Commit-Skripte die Kandidatenkonfiguration ausgewertet haben und der Kandidat in die Checkout-Konfiguration kopiert wurde. Um eine vorübergehende Änderung aus der Konfiguration zu entfernen, entfernen, deaktivieren oder deaktivieren Sie das Commit-Skript (wie unter Steuern der Ausführung von Commit-Skripten während Commit-Vorgängen beschrieben) oder kommentieren Sie den Code, der die transiente Änderung generiert.
Weitere Informationen über Unterschiede zwischen persistenten und transienten Änderungen finden Sie unter Übersicht über das Generieren von persistenten oder transienten Konfigurationsänderungen mithilfe von Commit-Skripten.