Générer un changement de configuration persistant ou transitoire dans les scripts de validation SLAX et XSLT
Les scripts de validation de Junos OS appliquent des règles de configuration personnalisées et peuvent modifier automatiquement la configuration lorsqu’elle n’est pas conforme à vos règles de configuration personnalisées. Pour générer une modification persistante ou transitoire dans les scripts de validation XSLT (Extensible Stylesheet Language Transformations) ou SLAX (Alternative Stylesheet Language Transformations) :
Au début du script, incluez le protocole standard de script de validation XSLT ou SLAX de la section Protocole standard requis pour les scripts de validation.
Passe-partout<?xml version="1.0" standalone="yes"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:junos="http://xml.juniper.net/junos/*/junos" xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm" xmlns:jcs="http://xml.juniper.net/junos/commit-scripts/1.0"> <xsl:import href="../import/junos.xsl"/> <xsl:template match="configuration"> <!-- ... insert your code here ... --> </xsl:template> </xsl:stylesheet>
version 1.2; ns junos = "http://xml.juniper.net/junos/*/junos"; ns xnm = "http://xml.juniper.net/xnm/1.1/xnm"; ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0"; import "../import/junos.xsl"; match configuration { /* * insert your code here */ }À la position indiquée par le commentaire «insert your code here , », inclure une ou plusieurs instructions de programmation XSLT ou leurs équivalents SLAX. Les constructions XSLT couramment utilisées sont les suivantes :
<xsl:choose> <xsl:when> <xsl:otherwise>: construction conditionnelle qui permet de traiter différentes instructions dans différentes circonstances. L’instruction<xsl:choose>contient un ou plusieurs<xsl:when>éléments, chacun d’entre eux testant une expression XPath. Si le test est évalué comme vrai, le processeur XSLT exécute les instructions de l’élément<xsl:when>. Le processeur XSLT ne traite que les instructions contenues dans le premier<xsl:when>élément donttestl’attribut est évalué comme true. Si aucun des attributs des<xsl:when>éléments n’est évalué comme vrai, le contenu de l’élément<xsl:otherwise>, s’iltestest présent, est traité.<xsl:for-each select="xpath-expression">—Instruction de programmation qui indique au processeur XSLT de rassembler un ensemble de nœuds et de les traiter un par un. Les noeuds sont sélectionnés par l’expression XPath dans l’attributselect. Chacun des nœuds est ensuite traité selon les instructions contenues dans l’instruction<xsl:for-each>. Le code à l’intérieur d’une<xsl:for-each>instruction est évalué récursivement pour chaque nœud qui correspond à l’expression XPath. Le contexte est déplacé vers le nœud à chaque passe.<xsl:if test="xpath-expression">: construction conditionnelle qui entraîne le traitement des instructions si l’expression XPath de l’attributtesta la valeur .true
Par exemple, les instructions de programmation XSLT suivantes sélectionnent chaque interface SONET/SDH pour laquelle la famille de protocoles MPLS n’est pas activée :
<xsl:for-each select="interfaces/interface[starts-with(name, 'so-')]/unit"> <xsl:if test="not(family/mpls)">
En SLAX, l’équivalent
for-eachetifles constructions sont :for-each (interfaces/interface[starts-with(name, 'so-')]/unit) { if (not(family/mpls)) {Pour plus d’informations sur l’utilisation des instructions de programmation, y compris des exemples et du pseudocode, consultez Vue d’ensemble des instructions de programmation XSLT. Pour plus d’informations sur l’écriture de scripts en SLAX au lieu de XSLT, reportez-vous à la section Présentation de SLAX.
Incluez des instructions pour modifier la configuration.
Il existe deux façons de générer un changement persistant et deux façons de générer un changement transitoire :
Pour générer une modification permanente, vous pouvez soit référencer le
jcs:emit-changemodèle, soit inclure un<change>élément.Pour générer un changement transitoire, vous pouvez soit référencer le
jcs:emit-changemodèle et passer le paramètre avec'transient-change'selectedtag, soit inclure un<transient-change>élément.
Le
jcs:emit-changemodèle permet d’établir des scripts plus efficaces et moins sujets aux erreurs, car vous pouvez définir le contenu de la modification sans spécifier la hiérarchie XML complète de l’instruction concernée. Au lieu de cela, la hiérarchie XML est définie dans l’expression XPath contenue dans l’instruction de programmation du script.Prenons les exemples suivants. Les deux exemples de changement persistant ont le même résultat, même s’ils placent l’instruction
Modification persistante générée avec le modèle jcs :emit-changeunità des emplacements différents dans les<xsl:for-each>instructions de programmation et<xsl:if>. Dans les deux cas, le script recherche les interfaces SONET/SDH pour lesquelles la famille de protocoles MPLS n’est pas activée, ajoute l’instructionfamily mplsau niveau de la[edit interfaces so-fpc/pic/port unit logical-unit-number]hiérarchie et émet un message d’avertissement indiquant que la configuration a été modifiée. De même, les deux exemples de changement transitoire ont le même résultat. Ils définissent tous deux l’encapsulation PPP (Point-to-Point Protocol) sur toutes les interfaces SONET/SDH sur lesquelles la version IP 4 (IPv4) est activée.Dans cet exemple, le contenu de la modification persistante (contenue dans le
contentparamètre) est spécifié sans inclure la hiérarchie XML complète. Au lieu de cela, l’expression XPath dans l’instruction<xsl:for-each>de programmation définit le contexte de la modification.Le paramètre message est également inclus. Avec ce paramètre, le modèle appelle le
jcs:emit-change<xnm:warning>modèle, ce qui envoie une notification d’avertissement à l’interface de ligne de commande. Le paramètre message inclut automatiquement les informations hiérarchiques actuelles dans le message d’avertissement.<xsl:for-each select="interfaces/interface[starts-with(name, 'so-')]/unit"> <xsl:if test="not(family/mpls)"> <xsl:call-template name="jcs:emit-change"> <xsl:with-param name="content"> <family> <mpls/> </family> </xsl:with-param> <xsl:with-param name="message"> <xsl:text>Adding 'family mpls' to SONET interface.</xsl:text> </xsl:with-param> </xsl:call-template> </xsl:if> </xsl:for-each>
Dans cet exemple, la hiérarchie XML complète menant à l’instruction affectée doit être incluse en tant qu’éléments enfants de l’élément
<change>.Cet exemple inclut les informations de hiérarchie actuelles dans le message d’avertissement en référençant les
jcs:edit-pathmodèles etjcs:statement.<xsl:for-each select="interfaces/interface[starts-with(name, 'so-')]"> <xsl:if test="not(unit/family/mpls)"> <change> <interfaces> <interface> <name><xsl:value-of select="name"/></name> <unit> <name><xsl:value-of select="unit/name"/></name> <family> <mpls/> </family> </unit> </interface> </interfaces> </change> <xnm:warning> <xsl:call-template name="jcs:edit-path"/> <xsl:call-template name="jcs:statement"> <xsl:with-param name="dot" select="unit/name"/> </xsl:call-template> <message>Adding 'family mpls' to SONET interface.</message> </xnm:warning> </xsl:if> </xsl:for-each>
Dans cet exemple, le contenu de la modification transitoire (contenue dans le
contentparamètre) est spécifié sans inclure la hiérarchie XML complète. Au lieu de cela, l’expression XPath dans l’instruction<xsl:for-each>de programmation définit le contexte de la modification. L’opérateuranddans l’expression XPath signifie que les deux opérandes doivent êtretruelorsqu’ils sont convertis en booléens ; le deuxième opérande n’est pas évalué si le premier opérande estfalse.Le paramètre de balise est inclus avec '
transient-change' sélectionné. Sans cetagparamètre, lejcs:emit-changemodèle génère une modification persistante par défaut.<xsl:for-each select="interfaces/interface[starts-with(name, 'so-') \ and unit/family/inet]"> <xsl:call-template name="jcs:emit-change"> <xsl:with-param name="tag" select="'transient-change'"/> <xsl:with-param name="content"> <encapsulation>ppp</encapsulation> </xsl:with-param> </xsl:call-template> </xsl:for-each>
Dans cet exemple, la hiérarchie XML complète menant à l’instruction affectée doit être incluse en tant qu’éléments enfants de l’élément
<transient-change>.<xsl:for-each select="interfaces/interface[starts-with(name, 'so-')\ and unit/family/inet]"> <transient-change> <interfaces> <interface> <name><xsl:value-of select="name"/></name> <encapsulation>ppp</encapsulation> </interface> </interfaces> </transient-change> </xsl:for-each>
Enregistrez le script avec un nom significatif.
Copiez le script dans le répertoire /var/db/scripts/commit sur le disque dur du périphérique ou dans le répertoire /config/scripts/commit sur la clé USB. Pour plus d’informations sur la définition de l’emplacement de stockage des scripts de validation, reportez-vous à la section Stocker les scripts dans la mémoire Flash.
Si l’appareil dispose de deux moteurs de routage et que vous souhaitez que le script prenne effet sur les deux, vous devez copier le script sur les deux moteurs de routage. La
commit synchronizecommande ne copie pas les scripts entre les moteurs de routage.Activez le script en incluant l’instruction
file filenameau niveau de la[edit system scripts commit]hiérarchie.[edit system scripts commit] user@host# set file filename
Si le script génère des changements transitoires, configurez l’instruction
allow-transients.Configurez l’instruction au niveau de la
[edit system scripts commit]hiérarchie pour permettre à tous les scripts de validation d’apporter des modifications transitoires.[edit system scripts commit] user@host# set allow-transients
Vous pouvez également, sur les appareils et les versions pris en charge, configurer l’instruction au niveau de la
[edit system scripts commit file filename]hiérarchie pour que seul le script individuel puisse apporter des modifications transitoires.[edit system scripts commit] user@host# set file filename allow-transients
Validez la configuration.
[edit system scripts commit] user@host# commit
Si tous les scripts de validation s’exécutent sans erreur, toutes les modifications persistantes sont chargées dans la configuration candidate. Toutes les modifications transitoires sont chargées dans la configuration d’extraction, mais pas dans la configuration candidate. Le processus de validation se poursuit ensuite en validant la configuration et en propageant les modifications aux processus concernés sur l’appareil.
Pour afficher la configuration avec des modifications persistantes et transitoires appliquées, exécutez la show | display commit-scripts commande configuration mode.
[edit] user@host# show | display commit-scripts
Pour afficher la configuration en appliquant uniquement des modifications persistantes, exécutez la show | display commit-scripts no-transients commande configuration mode.
[edit] user@host# show | display commit-scripts no-transients
Les modifications persistantes et transitoires sont chargées dans la configuration de la même manière que la load replace commande configuration mode charge une configuration entrante. Lors de la génération d’une modification persistante ou transitoire, l’ajout de l’attribut replace="replace" à un élément de configuration produit le même comportement qu’une replace: balise dans une load replace opération. Les modifications persistantes et transitoires sont chargées dans la configuration avec le load replace comportement. Toutefois, les modifications persistantes sont chargées dans la configuration candidate, et les modifications transitoires sont chargées dans la configuration d’extraction.