Comment fonctionnent les scripts de validation
Les scripts de validation contiennent des instructions qui appliquent des règles de configuration personnalisées et sont invoqués pendant le processus de validation avant que les vérifications de validité standard de Junos OS soient effectuées. Vous activez les scripts de validation en énumérant les noms d’un ou plusieurs fichiers de script de validation au niveau de la [edit system scripts commit]
hiérarchie. Ces fichiers doivent être ajoutés au répertoire de script de validation approprié sur l’équipement.
Lorsque vous effectuez une opération de validation, Junos OS exécute chaque script à son tour, transmettant les informations de la configuration du candidat post-héritage aux scripts. Le script inspecte la configuration, effectue les tests et les validations nécessaires et génère un ensemble d’instructions pour l’exécution de certaines actions. Une fois tous les scripts de validation exécutés, Junos OS traite ensuite toutes les instructions des scripts. Si le processus de validation n’est pas interrompu par un script de validation, Junos OS applique toutes les modifications de script de validation et effectue son inspection finale de la configuration du paiement.
Lorsque vous validez une configuration inspectée par un ou plusieurs scripts de validation, vous devrez peut-être augmenter la quantité de mémoire allouée aux scripts de validation pour accueillir le traitement des configurations de grande taille. Par défaut, la quantité maximale de mémoire allouée pour la partie de segment de données d’un script exécuté représente la moitié de la mémoire totale disponible du système, jusqu’à une valeur maximale de 128 Mo. Pour augmenter le nombre maximal de mémoire alloué pour chaque script de validation exécuté, configurez l’instruction max-datasize size
avec une limite de mémoire appropriée en octets au niveau de la [edit system scripts commit]
hiérarchie avant de valider la configuration.
Les actions de script de validation peuvent inclure la génération de messages d’erreur, d’avertissement et de journalisation système. Si des erreurs sont générées, l’opération de validation échoue et la configuration du candidat reste inchangée. Il s’agit du même comportement que pour les erreurs de validation standard. Les scripts de validation peuvent également générer des modifications de la configuration système. Étant donné que les modifications sont chargées avant l’exécution des vérifications de validation standard, elles sont validées pour une syntaxe correcte, tout comme les instructions déjà présentes dans la configuration avant l’application du script. Si la syntaxe est correcte, la configuration est activée et devient la configuration active et opérationnelle de l’équipement.
Les scripts de validation ne peuvent pas apporter de modifications de configuration à des instructions protégées ou dans des hiérarchies protégées. Si un script de validation tente de modifier ou de supprimer une hiérarchie ou une déclaration protégée, Junos OS émet un avertissement indiquant que la modification ne peut pas être apportée. L’absence de modification d’un élément de configuration protégé n’arrête pas le script de validation ou le processus de validation.
Les sections suivantes abordent plusieurs concepts importants liés à l’entrée et à la sortie du script de validation :
Saisie de script de validation
L’entrée d’un script de validation est la configuration du candidat post-héritage au format API XML Junos. Le terme post-héritage signifie que toutes les valeurs des groupes de configuration ont été héritées par leurs cibles dans la configuration de candidature et que les parties inactives de la configuration ont été supprimées. Pour plus d’informations sur les groupes de configuration, consultez le Guide de l’utilisateur CLI.
Lorsque vous envoyez la commit
commande, Junos OS génère automatiquement la configuration du candidat au format XML et la lit dans le processus de gestion (mgd), auquel moment l’entrée est évaluée par des scripts de validation.
Pour afficher le format XML de la configuration du candidat post-héritage dans l’interface de ligne de commande, émettre la show | display commit-scripts view
commande.
[edit] user@host# show | display commit-scripts view
Pour afficher toutes les données des groupes de configuration, y compris les modifications générées par des scripts dans les groupes, émettre la show groups | display commit-scripts
commande.
[edit] user@host# show groups | display commit-scripts
Sortie du script de validation
Au cours du processus de validation, les scripts de validation activés sont exécutés de manière séquentielle et le script de validation, ou jeu d’instructions, est fourni à Junos OS. Une fois tous les scripts de validation exécutés, Junos OS traite ensuite toutes les instructions des scripts.
Les actions de script de validation peuvent inclure la génération de messages d’avertissement, d’erreur et de journalisation système, ainsi que l’ajout de modifications persistantes et transitoires à la configuration. Le tableau 1 présente brièvement les différents éléments, modèles et fonctions que les scripts de validation peuvent utiliser pour ordonner à Junos OS d’effectuer diverses actions au cours du processus de validation. Dans certains cas, il existe plusieurs façons d’effectuer la même action. Les scripts SLAX et XSLT renvoyant une arborescence de résultats, des éléments de sortie tels <syslog><message>
que les scripts SLAX et XSLT sont directement ajoutés dans l’arborescence des résultats.
Sortie du script de validation |
SLAX/XSLT |
Python |
---|---|---|
Générez un message d’avertissement à l’utilisateur qui s’engage. |
|
jcs.emit_warning() |
Générez un message d’erreur et provoquez l’échec de l’opération de validation. |
|
jcs.emit_error() |
Générez un message de journalisation système. |
jcs:syslog()
|
jcs.syslog() |
Générer une modification permanente de la configuration. |
|
emit_change(content, 'change', format) |
Générer une modification transitoire de la configuration. |
|
emit_change(content, « changement transitoire », format) |
Générez un changement persistant par rapport au nœud de contexte actuel tel que défini par une expression XPath . |
XSLT <xsl:call-template name="jcs:emit-change"> <xsl:with-param name="content"> SLAX call jcs:emit-change() { with $content = { } } |
– |
Générez un changement transitoire par rapport au nœud de contexte actuel tel que défini par une expression XPath. |
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 = { } } |
– |
Générez un message d’avertissement combiné à une modification de configuration. Vous pouvez utiliser cet ensemble de balises pour générer une notification que la configuration a été modifiée. |
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 traite cette sortie et effectue les actions appropriées. Les erreurs et avertissements sont renvoyés à l’interface CLI de Junos OS ou à une application cliente du protocole XML Junos. La présence d’une erreur provoque automatiquement l’échec de l’opération de validation. Les modifications persistantes et transitoires sont chargées dans la base de données de configuration appropriée.
Pour tester la sortie des messages d’erreur, d’avertissement et de journalisation système à partir de scripts de validation, la commande est commit check | display xml
émise.
[edit] user@host# commit check | display xml
Pour afficher une trace détaillée du traitement des scripts de validation, émettez la commit check | display detail
commande.
[edit] user@host# commit check | display detail
Les messages de journalisation système n’apparaissent pas dans la sortie de trace, de sorte que vous ne pouvez pas utiliser l’opération de vérification de validation pour tester les messages de journalisation système générés par les scripts. De plus, les messages de journalisation système sont écrits dans le journal système pendant une opération de validation, mais pas lors d’une opération de vérification de validation.
Scripts de validation et modèle de validation Junos OS
Junos OS utilise un modèle de validation pour mettre à jour la configuration de l'équipement. Ce modèle vous permet d’apporter une série de modifications à une configuration de candidat sans affecter le fonctionnement de l’équipement. Une fois les modifications terminées, vous pouvez valider la configuration. L’opération de validation enregistre les modifications de configuration du candidat dans la configuration actuelle.
Lorsque vous validez un ensemble de modifications dans la configuration du candidat, deux méthodes sont utilisées pour transmettre ces modifications à la configuration actuelle :
Modèle de validation standard : utilisé lorsqu’aucun script de validation n’est actif sur l’équipement.
Modèle de script de validation : intègre des scripts de validation dans le modèle de validation.
Modèle de validation standard
Dans le modèle de validation standard, le processus de gestion (mgd) valide la configuration du candidat en fonction des règles de validation standard de Junos OS. Si le fichier de configuration est valide, il devient la configuration active actuelle. La figure 1 et la discussion qui l’accompagne expliquent le fonctionnement du modèle de validation standard.

Dans le modèle de validation standard, le logiciel effectue les opérations suivantes :
Une fois la configuration du candidat validée, elle est copiée pour devenir la configuration de paiement.
Le processus mgd valide la configuration du paiement.
En cas d’erreur, la configuration de paiement est copiée en tant que configuration active actuelle.
Modèle de validation avec scripts de validation
Lorsque des scripts de validation sont ajoutés au modèle de validation standard, le processus devient plus complexe. Le processus mgd transmet d’abord une configuration de paiement au format XML à un pilote de script, qui gère la vérification de la configuration du paiement par les scripts de validation. Une fois la vérification terminée, le pilote de script renvoie un fichier d’action au processus mgd. Le processus mgd suit les instructions fournies dans le fichier d’action pour mettre à jour le candidat et les configurations de paiement, émettre des messages sur l’interface cli ou l’application cliente et écrire des informations dans le journal système selon les besoins. Après traitement du fichier d’action, le processus mgd effectue la validation de Junos OS standard. La figure 2 et la discussion qui l’accompagne expliquent ce processus.

Dans le modèle de script de validation, Junos OS effectue les opérations suivantes :
Lorsque la configuration du candidat est validée, le processus mgd envoie la configuration du candidat au format XML au pilote de script.
Chaque script de validation activé est invoqué en fonction de la configuration du candidat, et chaque script peut générer un ensemble d’actions pour le processus mgd à exécuter. Les actions sont collectées dans un fichier d’action.
Le processus mgd effectue les actions suivantes pour l’erreur de script de validation, l’avertissement et les messages de journalisation système dans le fichier d’action :
erreur : le processus mgd arrête le processus de validation (c’est-à-dire, l’opération de validation échoue), renvoie un message d’erreur à l’interface de ligne de commande ou au client de protocole XML Junos et ne prend aucune autre mesure.
avertissement : le processus mgd transfère le message à l’interface de ligne de commande ou au client de protocole XML Junos.
message du journal système : le processus mgd transfère le message au processus de journalisation système.
Si le fichier d’action inclut des modifications persistantes, le processus mgd charge les modifications demandées dans la configuration du candidat.
La configuration du candidat est copiée pour devenir la configuration de paiement.
Si le fichier d’action inclut des modifications transitoires, le processus mgd charge les modifications demandées dans la configuration de paiement.
Le processus mgd valide la configuration du paiement.
En l’absence d’erreurs de validation, la configuration de paiement est copiée pour devenir la configuration active actuelle.
Les scripts de validation ne peuvent pas apporter de modifications de configuration à des instructions protégées ou dans des hiérarchies protégées. Si un script de validation tente de modifier ou de supprimer une hiérarchie ou une déclaration protégée, Junos OS émet un avertissement indiquant que la modification ne peut pas être apportée. L’absence de modification d’un élément de configuration protégé n’arrête pas le script de validation ou le processus de validation.
Les modifications apportées à la configuration du candidat pendant l’opération de validation ne sont pas évaluées par les règles personnalisées pendant cette opération de validation. Toutefois, les modifications persistantes sont maintenues dans la configuration du candidat et sont évaluées par les règles personnalisées lors des opérations de validation ultérieures. Pour plus d’informations sur la façon dont les scripts de validation modifient la configuration du candidat, reportez-vous à la commande Avoiding Potential Conflicts When Using Multiple Commit Scripts.
Les modifications transitoires ne sont jamais évaluées par les règles personnalisées dans les scripts de validation, car elles ne sont apportées à la configuration de paiement qu’une fois que les scripts de validation ont évalué la configuration du candidat et que le candidat est copié pour devenir la configuration de paiement. Pour supprimer un changement transitoire de la configuration, supprimez, désactivez ou désactivez le script de validation (comme indiqué dans Le contrôle de l’exécution des scripts de validation pendant les opérations de validation), ou commentez le code qui génère le changement transitoire.
Pour plus d’informations sur les différences entre les modifications persistantes et transitoires, consultez la rubrique Présentation de la génération de modifications de configuration persistantes ou transitoires à l’aide de scripts de validation.