Como funcionam os scripts de confirmação
Os scripts de confirmação contêm instruções que aplicam regras de configuração personalizadas e são invocadas durante o processo de confirmação antes que as verificações de validade padrão do Junos OS sejam realizadas. Você habilita scripts de confirmação listando os nomes de um ou mais arquivos de script comprometidos no nível hierárquico [edit system scripts commit] . Esses arquivos devem ser adicionados ao diretório de script de compromisso apropriado no dispositivo.
Quando você realiza uma operação de confirmação, o Junos OS executa cada script por sua vez, passando as informações na configuração do candidato pós-herança para os scripts. O script inspeciona a configuração, realiza os testes e validações necessários e gera um conjunto de instruções para realizar determinadas ações. Depois de todos os scripts de confirmação terem sido executados, o Junos OS processa todas as instruções dos scripts. Se o processo de confirmação não for interrompido por um script de confirmação, o Junos OS aplica todas as alterações de script de confirmação e realiza sua inspeção final da configuração de checkout.
Ao cometer uma configuração inspecionada por um ou mais scripts de confirmação, você pode precisar aumentar a quantidade de memória alocada para os scripts de confirmação para acomodar o processamento de grandes configurações. Por padrão, a quantidade máxima de memória alocada para a porção do segmento de dados de um script executado é metade da memória total disponível do sistema, até um valor máximo de 128 MB. Para aumentar o máximo de memória alocada para cada script de compromisso executado, configure a max-datasize size declaração com um limite de memória apropriado em bytes no nível de [edit system scripts commit] hierarquia antes de cometer a configuração.
Cometer ações de script pode incluir gerar mensagens de erro, aviso e log do sistema. Se erros forem gerados, a operação de confirmação falhar e a configuração do candidato permanecer sem alterações. Esse é o mesmo comportamento que ocorre com erros padrão de confirmação. Os scripts de confirmação também podem gerar alterações na configuração do sistema. Como as alterações são carregadas antes que as verificações de validação padrão sejam realizadas, elas são validadas para corrigir a sintaxe, assim como as declarações já presentes na configuração antes da aplicação do script. Se a sintaxe estiver correta, a configuração é ativada e se torna a configuração ativa e operacional do dispositivo.
Os scripts de confirmação não podem fazer alterações de configuração para declarações protegidas ou dentro de hierarquias protegidas. Se um script de confirmação tentar modificar ou excluir uma declaração ou hierarquia protegida, o Junos OS emite um aviso de que a mudança não pode ser feita. A falha em modificar um elemento de configuração protegida não impede o script de confirmação ou o processo de confirmação.
As seções a seguir discutem vários conceitos importantes relacionados à entrada e saída do script de confirmação:
Entrada de script de confirmação
A entrada para um script de confirmação é a configuração do candidato pós-herança no formato de API Junos XML. O termo pós-herança significa que todos os valores do grupo de configuração foram herdados por seus alvos na configuração do candidato e que as partes inativas da configuração foram removidas. Para obter mais informações sobre grupos de configuração, consulte o Guia do usuário do CLI.
Ao emitir o comando, o commit Junos OS gera automaticamente a configuração do candidato no formato XML e a lê no processo de gerenciamento (mgd), momento em que a entrada é avaliada por quaisquer scripts de confirmação.
Para exibir o formato XML da configuração do candidato pós-herança na CLI, emita o show | display commit-scripts view comando.
[edit] user@host# show | display commit-scripts view
Para exibir todos os dados de grupos de configuração, incluindo alterações geradas por script nos grupos, emita o show groups | display commit-scripts comando.
[edit] user@host# show groups | display commit-scripts
Confirmação de saída de script
Durante o processo de confirmação, scripts de confirmação habilitados são executados sequencialmente, e a saída de script de confirmação, ou conjunto de instruções, é fornecida ao Junos OS. Depois de todos os scripts de confirmação terem sido executados, o Junos OS processa todas as instruções dos scripts.
Cometer ações de script pode incluir a geração de mensagens de aviso, erro e log do sistema e alterações persistentes e transitórias na configuração. A Tabela 1 descreve brevemente os vários elementos, templates e funções que os scripts confirmam podem ser usados para instruir o Junos OS a realizar várias ações durante o processo de confirmação. Em alguns casos, existem várias maneiras de realizar a mesma ação. Como os scripts SLAX e XSLT devolvem uma árvore de resultado, elementos de saída como <syslog><message> os presentes nos scripts SLAX e XSLT são adicionados diretamente na árvore de resultado.
Confirmação de saída de script |
SLAX / XSLT |
Python |
|---|---|---|
Gere uma mensagem de aviso ao usuário comprometido. |
|
jcs.emit_warning() |
Gere uma mensagem de erro e deixe a operação de confirmação falhar. |
|
jcs.emit_error() |
Gere uma mensagem de log do sistema. |
jcs:syslog()
|
jcs.syslog() |
Gere uma mudança persistente na configuração. |
|
emit_change(content, 'mudança') format |
Gere uma mudança transitória para a configuração. |
|
emit_change(content, 'mudança transitória') format |
Gere uma mudança persistente em relação ao nó de contexto atual definido por uma expressão XPath . |
XSLT <xsl:call-template name="jcs:emit-change"> <xsl:with-param name="content"> SLAX call jcs:emit-change() {
with $content = { }
}
|
– |
Gere uma mudança transitória em relação ao nó de contexto atual definido por uma expressão 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 = { }
}
|
– |
Gere uma mensagem de alerta em conjunto com uma mudança de configuração. Você pode usar este conjunto de tags para gerar uma notificação de que a configuração foi alterada. |
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() |
O Junos OS processa essa saída e realiza as ações apropriadas. Erros e avisos são passados de volta para o Junos OS CLI ou para um aplicativo de cliente de protocolo Junos XML. A presença de um erro faz com que a operação de confirmação falhe automaticamente. Mudanças persistentes e transitórias são colocadas no banco de dados de configuração apropriado.
Para testar a saída de mensagens de erro, aviso e log do sistema a partir de scripts de confirmação, emita o commit check | display xml comando.
[edit] user@host# commit check | display xml
Para exibir um traço detalhado do processamento de script de confirmação, emita o commit check | display detail comando.
[edit] user@host# commit check | display detail
As mensagens de registro do sistema não aparecem na saída de rastreamento, de modo que você não pode usar a operação de verificação de confirmação para testar mensagens de log do sistema geradas por script. Além disso, as mensagens de registro do sistema são escritas no log do sistema durante uma operação de confirmação, mas não durante uma operação de verificação de confirmação.
Comprometa scripts e o modelo de confirmação do Junos OS
O Junos OS usa um modelo de confirmação para atualizar a configuração do dispositivo. Esse modelo permite que você faça uma série de alterações na configuração de um candidato sem afetar a operação do dispositivo. Quando as alterações estiverem completas, você pode confirmar a configuração. A operação de confirmação salva as mudanças de configuração do candidato na configuração atual.
Quando você confirma um conjunto de mudanças na configuração do candidato, dois métodos são usados para encaminhar essas mudanças à configuração atual:
Modelo de confirmação padrão — usado quando nenhum script de confirmação está ativo no dispositivo.
Comprometa o modelo de script — incorpora scripts de compromisso no modelo de confirmação.
Modelo de confirmação padrão
No modelo de confirmação padrão, o processo de gerenciamento (mgd) valida a configuração do candidato com base nas regras padrão de validação do Junos OS. Se o arquivo de configuração for válido, ele se tornará a configuração ativa atual. A Figura 1 e a discussão que acompanham explicam como funciona o modelo padrão de confirmação.
de compromisso padrão
No modelo de confirmação padrão, o software executa as seguintes etapas:
Quando a configuração do candidato é comprometida, ela é copiada para se tornar a configuração de checkout.
O processo mgd valida a configuração de checkout.
Se nenhum erro ocorrer, a configuração de checkout será copiada como a configuração ativa atual.
Comprometa o modelo com scripts de confirmação
Quando scripts de confirmação são adicionados ao modelo de confirmação padrão, o processo se torna mais complexo. O processo mgd primeiro passa uma configuração de checkout formatada por XML para um driver de script, que lida com a verificação da configuração de checkout pelos scripts de confirmação. Quando a verificação estiver concluída, o condutor de script retorna um arquivo de ação ao processo mgd. O processo mgd segue as instruções no arquivo de ação para atualizar as configurações de candidato e checkout, emitir mensagens para o CLI ou aplicativo do cliente e escrever informações para o log do sistema conforme necessário. Após o processamento do processo de ação, o processo mgd executa a validação padrão do Junos OS. A Figura 2 e a discussão que acompanham explicam esse processo.
No modelo de script de confirmação, o Junos OS executa as seguintes etapas:
Quando a configuração do candidato é comprometida, o processo mgd envia a configuração do candidato com formato XML para o driver de script.
Cada script de confirmação habilitado é invocado contra a configuração do candidato, e cada script pode gerar um conjunto de ações para o processo mgd realizar. As ações são coletadas em um arquivo de ação.
O processo mgd executa as seguintes ações para cometer erros de script, aviso e mensagens de log do sistema no arquivo de ação:
erro — o processo mgd interrompe o processo de confirmação (ou seja, a operação de confirmação falha), devolve uma mensagem de erro ao cliente de protocolo CLI ou Junos XML e não toma mais nenhuma ação.
aviso : o processo mgd encaminha a mensagem para o CLI ou para o cliente de protocolo Junos XML.
mensagem de log do sistema — o processo mgd encaminha a mensagem para o processo de log do sistema.
Se o arquivo de ação incluir quaisquer alterações persistentes, o processo mgd carrega as alterações solicitadas na configuração do candidato.
A configuração do candidato é copiada para se tornar a configuração de checkout.
Se o arquivo de ação incluir quaisquer alterações transitórias, o processo mgd carrega as alterações solicitadas na configuração de checkout.
O processo mgd valida a configuração de checkout.
Se não houver erros de validação, a configuração de checkout será copiada para se tornar a configuração ativa atual.
Os scripts de confirmação não podem fazer alterações de configuração para declarações protegidas ou dentro de hierarquias protegidas. Se um script de confirmação tentar modificar ou excluir uma declaração ou hierarquia protegida, o Junos OS emite um aviso de que a mudança não pode ser feita. A falha em modificar um elemento de configuração protegida não impede o script de confirmação ou o processo de confirmação.
As alterações feitas na configuração do candidato durante a operação de confirmação não são avaliadas pelas regras personalizadas durante essa operação de confirmação. No entanto, mudanças persistentes são mantidas na configuração do candidato e são avaliadas pelas regras personalizadas durante as operações de confirmação subsequentes. Para obter mais informações sobre como os scripts de confirmação mudam a configuração do candidato, consulte Evitando conflitos potenciais ao usar vários scripts de confirmação.
As mudanças transitórias nunca são avaliadas pelas regras personalizadas em scripts de confirmação, porque elas só são feitas na configuração de checkout depois que os scripts de confirmação avaliarem a configuração do candidato e o candidato for copiado para se tornar a configuração de checkout. Para remover uma mudança transitória da configuração, remover, desabilitar ou desativar o script de confirmação (conforme discutido no controle da execução de scripts de confirmação durante as operações de confirmação), ou comentar o código que gera a mudança transitória.
Para obter mais informações sobre diferenças entre mudanças persistentes e transitórias, consulte a visão geral da geração de mudanças de configuração persistentes ou transitórias usando scripts de confirmação.