• O AWS Systems Manager CloudWatch Dashboard não estará mais disponível a partir de 30 de abril de 2026. Os clientes podem continuar usando o console do Amazon CloudWatch para visualizar, criar e gerenciar os painéis do Amazon CloudWatch exatamente como fazem hoje. Para obter mais informações, consulte a [documentação do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
# Documentos do comando do SSM para aplicação de patches em nós gerenciados
Este tópico descreve os sete documentos do Systems Manager (documentos SSM) atualmente disponíveis para ajudar você a manter seus nós gerenciados protegidos com as mais recentes atualizações relacionadas à segurança.
Recomendamos usar apenas cinco desses documentos em suas operações de aplicação de patches. Juntos, esses cinco documentos do SSM fornecem uma variedade completa de opções de aplicação de patches usando o AWS Systems Manager. Quatro desses documentos foram lançados após os quatro documentos do SSM legados para substituí-los e representam expansões ou consolidações de funcionalidade.
**Documentos do SSM recomendados para aplicação de patches**
Recomendamos usar os cinco documentos do SSM a seguir em suas operações de aplicação de patches.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**Documentos do SSM legados para aplicação de patches**
Os quatro documentos SSM herdados a seguir permanecem disponíveis em alguns Regiões da AWS, mas não são mais atualizados ou suportados. Não é garantido que esses documentos funcionem em ambientes IPv6 e suportem apenas IPv4. Não é garantido que funcionem em todos os cenários e podem perder suporte no futuro. Recomendamos que você não use esses documentos para operações de correção.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Para obter as etapas para configurar as operações de correção em um ambiente que suporta somente IPv6, consulte [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md).
Consulte as seções a seguir para obter mais informações sobre como usar esses documentos do SSM em suas operações de aplicação de patches.
**Topics**
+ [Documentos do SSM recomendados para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-recommended)
+ [Documentos do SSM para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-legacy)
+ [Limitações dos documentos do SSM para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-known-limitations)
+ [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Cenário de exemplo do uso do parâmetro InstallOverrideList em `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Usar o parâmetro BaselineOverride](patch-manager-baselineoverride-parameter.md)
## Documentos do SSM recomendados para aplicação de patches em nós gerenciados
Os cinco documentos do SSM a seguir são recomendados para uso nas operações de aplicação de patches em nós gerenciados.
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
Oferece suporte à configuração e uso de funções básicas do Windows Update para instalar atualizações automaticamente (ou desativar atualizações automáticas). Disponível em todas as Regiões da AWS.
Esse documento do SSM configura o Windows Update para baixar e instalar as atualizações especificadas e reiniciar os nós gerenciados conforme necessário. Use esse documento com o State Manager, uma ferramenta do AWS Systems Manager, para garantir que o Windows Update mantenha sua configuração. Você também pode executá-lo manualmente usando o Run Command, uma ferramenta do AWS Systems Manager, para alterar a configuração do Windows Update.
Os parâmetros disponíveis neste documento oferecem suporte à especificação de uma categoria de atualizações a serem instaladas (ou se as atualizações automáticas devem ser desativadas), bem como especificar o dia da semana e a hora do dia para executar operações de aplicação de patches. Esse documento do SSM é mais útil se você não precisa de controles rigorosos sobre as atualizações do Windows e não precisa coletar informações de conformidade.
**Substitui estes documentos do SSM legados: **
+ *Nenhum*
### `AWS-InstallWindowsUpdates`
Instala atualizações em um nó gerenciado do Windows Server. Disponível em todas as Regiões da AWS.
Esse documento do SSM fornece a funcionalidade básica de aplicação de patches nos casos em que você deseja instalar uma atualização específica (usando o parâmetro `Include Kbs`) ou deseja instalar patches com classificações ou categorias específicas, mas não precisa de informações de conformidade do patch.
**Substitui estes documentos do SSM legados:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Os três documentos legados executam funções diferentes, mas você pode alcançar os mesmos resultados usando diferentes configurações de parâmetro com o documento do SSM mais recente `AWS-InstallWindowsUpdates`. Essas configurações de parâmetro são descritas em [Documentos do SSM para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-legacy).
### `AWS-RunPatchBaseline`
Instala patches em nós gerenciados ou verifica os nós para determinar se qualquer patch qualificado está ausente. Disponível em todas as Regiões da AWS.
`AWS-RunPatchBaseline`O permite controlar aprovações de patches usando a linha de base do patch especificada como “padrão” para um tipo de sistema operacional. Ele relata informações de conformidade de patch que você pode exibir usando as ferramentas de conformidade do Systems Manager. Essas ferramentas fornecem informações sobre o estado de conformidade de patch dos nós gerenciados, como quais nós têm patches ausentes e quais são esses patches. Quando você usa`AWS-RunPatchBaseline`, as informações de conformidade de patch são registradas usando o`PutInventory`Comando da API. Para sistemas operacionais Linux, as informações de conformidade são fornecidas para patches do repositório de origem padrão configurado em um nó gerenciado e de qualquer repositório de origem alternativo especificado em uma lista personalizada de referência de patches. Para obter mais informações sobre repositórios de origem alternativos, consulte [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md). Para obter mais informações sobre as ferramentas de conformidade do Systems Manager, consulte [AWS Systems Manager Compliance](systems-manager-compliance.md).
**Substitui estes documentos legados:**
+ `AWS-ApplyPatchBaseline`
O documento legado `AWS-ApplyPatchBaseline` se aplica apenas a nós gerenciados do Windows Server e não é compatível com a aplicação de patches em aplicações. O `AWS-RunPatchBaseline` mais recente fornece o mesmo suporte para sistemas Windows e Linux. A versão 2.0.834.0 ou posterior do SSM Agent é necessária para usar o documento `AWS-RunPatchBaseline`.
Para obter mais informações sobre o documento do SSM, `AWS-RunPatchBaseline`, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
### `AWS-RunPatchBaselineAssociation`
Instala patches nas suas instâncias ou verifica as instâncias para determinar se qualquer patch qualificado está ausente. Disponível em todas as comerciais Regiões da AWS.
O `AWS-RunPatchBaselineAssociation` difere do `AWS-RunPatchBaseline` de algumas maneiras importantes:
+ O `AWS-RunPatchBaselineAssociation` deve ser usado principalmente com associações do State Manager criadas usando o Quick Setup, uma ferramenta do AWS Systems Manager. Especificamente, quando você usar o tipo de configuração do Host Management do Quick Setup, se você escolher a opção **Scan instances for missing patches daily** (Verificar patches ausentes nas instâncias diariamente), o sistema usará `AWS-RunPatchBaselineAssociation` para a operação.
Na maioria dos casos, no entanto, ao configurar suas próprias operações de patch, você deve escolher [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) ou [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md), ao invés do `AWS-RunPatchBaselineAssociation`.
Para saber mais, consulte os seguintes tópicos:
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation`O suporta o uso de tags para identificar qual linha de base de patch usar com um conjunto de destinos, quando ele for executado.
+ Para operações de patch que usam o `AWS-RunPatchBaselineAssociation`, os dados de conformidade de patches são compilados em termos de uma associação do State Manager. Os dados de conformidade de patches coletados quando `AWS-RunPatchBaselineAssociation` é executado são gravados usando a API `PutComplianceItems` em vez do comando `PutInventory`. Isso impede que os dados de conformidade que não estão associados a essa associação específica sejam substituídos.
Para sistemas operacionais Linux, as informações de conformidade são fornecidas para patches do repositório de origem padrão configurado em uma instância e de qualquer repositório de origem alternativo especificado em uma linha de base de patch personalizada. Para obter mais informações sobre repositórios de origem alternativos, consulte [Como especificar um repositório de origem de patches alternativo (Linux)](patch-manager-alternative-source-repository.md). Para obter mais informações sobre as ferramentas de conformidade do Systems Manager, consulte [AWS Systems Manager Compliance](systems-manager-compliance.md).
**Substitui estes documentos legados:**
+ **Nenhum**
Para obter mais informações sobre o documento do SSM, `AWS-RunPatchBaselineAssociation`, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).
### `AWS-RunPatchBaselineWithHooks`
Instala patches em seus nós gerenciados ou verifica os nós para determinar se qualquer patch qualificado está ausente, com hooks opcionais que você pode usar para executar documentos do SSM em três pontos durante o ciclo de aplicação de patches. Disponível em todas as comerciais Regiões da AWS. Não compatível com o macOS.
O `AWS-RunPatchBaselineWithHooks` difere do `AWS-RunPatchBaseline` na operação `Install`.
O `AWS-RunPatchBaselineWithHooks` oferece suporte a hooks de ciclo de vida executados em pontos designados durante a aplicação de patches em nós gerenciados. Como as instalações de patches às vezes exigem nós gerenciados para reinicializar, a operação de aplicação patches é dividida em dois eventos, para um total de três ganchos que suportam funcionalidade personalizada. O primeiro hook é antes da operação O segundo hook é depois da operação `Install with NoReboot`. O terceiro hook está disponível após a reinicialização do nó.
**Substitui estes documentos legados:**
+ **Nenhum**
Para obter mais informações sobre o documento do SSM, `AWS-RunPatchBaselineWithHooks`, consulte [Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
## Documentos do SSM para aplicação de patches em nós gerenciados
Os quatro documentos do SSM a seguir ainda estão disponíveis em algumas Regiões da AWS. No entanto, eles não estão sendo mais atualizados e podem não ter mais suporte no futuro. Por isso, não recomendamos seu uso. Em vez disso, use os documentos descritos em [Documentos do SSM recomendados para aplicação de patches em nós gerenciados](#patch-manager-ssm-documents-recommended).
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
Oferece suporte apenas aos nós gerenciados do Windows Server, mas não inclui suporte para a aplicação de patches em aplicações, como ocorre em seu substituto, o `AWS-RunPatchBaseline`. Não disponível em Regiões da AWS lançadas após agosto de 2017.
**nota**
O substituto deste documento do SSM, `AWS-RunPatchBaseline`, requer a versão 2.0.834.0 ou posterior do SSM Agent. Você pode usar o documento `AWS-UpdateSSMAgent` para atualizar os nós gerenciados para a versão mais recente do atendente.
### `AWS-FindWindowsUpdates`
Substituído por `AWS-InstallWindowsUpdates`, que pode realizar as mesmas ações. Não disponível em Regiões da AWS lançadas após abril de 2017.
Para obter o mesmo resultado que teria com esse documento do SSM legado, use a seguinte configuração de parâmetro com o documento substituto recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
Substituído por `AWS-InstallWindowsUpdates`, que pode realizar as mesmas ações. Não disponível em nenhuma Regiões da AWS lançada após abril de 2017.
Para obter o mesmo resultado que teria com esse documento do SSM legado, use a seguinte configuração de parâmetro com o documento substituto recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
Substituído por `AWS-InstallWindowsUpdates`, que pode realizar as mesmas ações. Não disponível em nenhuma Regiões da AWS lançada após abril de 2017.
Para obter o mesmo resultado que teria com esse documento do SSM legado, use a seguinte configuração de parâmetro com o documento substituto recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *lista de artigos da base de dados de conhecimento separados por vírgula*
## Limitações dos documentos do SSM para aplicação de patches em nós gerenciados
### Interrupções na reinicialização externa
Se uma reinicialização for iniciada pelo sistema no nó durante a instalação do patch (por exemplo, para aplicar atualizações no firmware ou em atributos como o SecureBoot), a execução do documento de patch poderá ser interrompida e marcada como falha, mesmo que os patches tenham sido instalados com sucesso. Isso ocorre porque o SSM Agent não pode persistir e retomar o estado de execução do documento em reinicializações externas.
Para verificar o status da instalação do patch após uma falha na execução, execute uma operação de patch `Scan` e, em seguida, verifique os dados de conformidade do patch no Patch Manager para avaliar o estado atual de conformidade.
# Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaseline`
O AWS Systems Manager é compatível com o `AWS-RunPatchBaseline`, um documento do Systems Manager (documento SSM) para o Patch Manager, uma ferramenta do AWS Systems Manager. Este documento do SSM executa operações de aplicação de patches em nós gerenciados para atualizações de segurança e outros tipos de atualizações. Quando o documento é executado, ele usa a linha de base do patch especificada como “padrão” para um tipo de sistema operacional se nenhum grupo de patches for especificado. Caso contrário, ele usa a linha de base do patch associada ao grupo de patches. Para obter mais informações sobre grupos de patches, consulte [Grupos de patches](patch-manager-patch-groups.md).
Você pode usar o documento `AWS-RunPatchBaseline` para aplicar patches aos sistemas operacionais e aplicações. (No Windows Server, o suporte a aplicações é limitado a atualizações de aplicações da Microsoft.)
Este documento oferece suporte a nós gerenciados do Linux, macOS e Windows Server. O documento executará as ações adequadas a cada plataforma.
**nota**
Patch Manager O também oferece suporte ao documento SSM legado `AWS-ApplyPatchBaseline`. No entanto, esse documento comporta a aplicação de patches somente em nós gerenciados do Windows. Em vez disso, é recomendável usar o `AWS-RunPatchBaseline` por ser compatível com a aplicação de patches em nós gerenciados do Linux, do macOS e do Windows Server. A versão 2.0.834.0 ou posterior do SSM Agent é necessária para usar o documento `AWS-RunPatchBaseline`.
------
#### [ Windows Server ]
Em nós gerenciados do Windows Server, o documento `AWS-RunPatchBaseline` baixa e invoca um módulo do PowerShell, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches contém uma lista de patches aprovados que é compilada consultando a lista de referência de patches em um servidor Windows Server Update Service (WSUS). Esse snapshot da lista de referência de patches é passado para a API do Windows Update, que controla o download e a instalação de patches aprovados, conforme apropriado.
------
#### [ Linux ]
Em nós gerenciados do Linux, o documento `AWS-RunPatchBaseline` invoca um módulo do Python, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches usa regras e listas de patches aprovados e bloqueados para conduzir o gerenciador de pacotes apropriado para cada tipo de nó:
+ Nós gerenciados do Amazon Linux 2, Oracle Linux e RHEL 7 usam YUM. Para operações YUM, o Patch Manager requer o `Python 2.6` ou uma versão posterior compatível (2.6 - 3.12). O Amazon Linux 2023 usa DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12).
+ RHELOs nós gerenciados do 8 usam o DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12). (Nenhuma versão é instalada por padrão no RHEL 8. É necessário instalar um deles manualmente.)
+ As instâncias do Debian Server e Ubuntu Server usam o APT. Para operações APT, o Patch Manager requer uma versão compatível do `Python 3` (3.0 - 3.12).
------
#### [ macOS ]
Em nós gerenciados do macOS, o documento `AWS-RunPatchBaseline` invoca um módulo do Python, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Em seguida, um subprocesso do Python invoca o AWS Command Line Interface (AWS CLI) em seu nó para recuperar as informações de instalação e atualização para os gerenciadores de pacotes especificados e para direcionar o gerenciador de pacotes apropriado para cada pacote de atualização.
------
Cada snapshot é específico para uma Conta da AWS, um grupo de patches, um sistema operacional e um ID de snapshot. O snapshot é entregue por meio de um URL pré-assinado do Amazon Simple Storage Service (Amazon S3), que expira 24 horas após a criação do snapshot. No entanto, se você quiser aplicar o mesmo conteúdo de snapshot a outros nós gerenciados depois que o URL expirar, você poderá gerar um novo URL pré-assinado do Amazon S3 até três dias após a criação do snapshot. Para fazer isso, use o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Depois que todas as atualizações aprovadas e aplicáveis forem instaladas, e as reinicializações realizadas conforme a necessidade, as informações de conformidade do patch serão geradas em um nó gerenciado e relatadas ao Patch Manager.
**nota**
Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado após a execução do Patch Manager. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
Para obter informações sobre como visualizar dados de conformidade de patches, consulte [Sobre a conformidade de patches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaseline`Parâmetros do
`AWS-RunPatchBaseline`O oferece suporte a seis parâmetros. O parâmetro `Operation` é obrigatório. Os parâmetros `InstallOverrideList`, `BaselineOverride` e `RebootOption` são opcionais. O `Snapshot-ID` é tecnicamente opcional, mas recomendamos que você forneça um valor personalizado para ele quando executar o `AWS-RunPatchBaseline` fora de uma janela de manutenção. O Patch Manager pode fornecer o valor personalizado automaticamente quando o documento for executado como parte de uma operação da janela de manutenção.
**Topics**
+ [Nome do parâmetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nome do parâmetro: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Nome do parâmetro: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Nome do parâmetro: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Nome do parâmetro: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Nome do parâmetro: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### Nome do parâmetro: `Operation`
**Uso**: obrigatório.
**Opções**: `Scan` \$1 `Install`.
Verificar
Quando você escolhe a opção `Scan`, o `AWS-RunPatchBaseline` determina o estado de conformidade dos patches do nó gerenciado e retorna essas informações para o Patch Manager. A opção `Scan` não solicita que atualizações sejam instaladas ou que nós gerenciados sejam reinicializados. Em vez disso, a operação identifica onde existem atualizações ausentes que estão aprovadas e são aplicáveis ao nó.
Instalar
Quando você escolhe a opção `Install`, o `AWS-RunPatchBaseline` tenta instalar as atualizações aprovadas e aplicáveis que estiverem ausentes em seu nó gerenciado. As informações de conformidade dos patches geradas como parte de uma operação `Install` não listam atualizações ausentes, mas poderão indicar atualizações em estado malsucedido se, por qualquer motivo, a instalação da atualização não tiver tido êxito. Sempre que uma atualização é instalada em um nó gerenciado, o nó é reinicializado para garantir que a atualização esteja instalada e ativa. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaseline`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
Se um patch especificado pelas regras da lista de referência for instalado *antes* que o Patch Manager atualize o nó gerenciado, o sistema poderá não ser reinicializado conforme esperado. Isso pode acontecer quando um patch é instalado manualmente por um usuário ou instalado automaticamente por outro programa, como o pacote `unattended-upgrades` no Ubuntu Server.
### Nome do parâmetro: `AssociationId`
**Uso**: opcional.
O `AssociationId` é o ID de uma associação existente no State Manager, uma ferramenta do AWS Systems Manager. Ela é usada pelo Patch Manager para adicionar dados de conformidade à associação especificada. Essa associação está relacionada a uma operação de aplicação de patches [configurada em uma política de patch no Quick Setup](quick-setup-patch-manager.md).
**nota**
Com o `AWS-RunPatchBaseline`, se um valor de `AssociationId` for fornecido junto com uma substituição da lista de referência da política de patch, a aplicação de patches será feita como uma operação `PatchPolicy` e o valor `ExecutionType` informado em `AWS:ComplianceItem` também será `PatchPolicy`. Se nenhum valor de `AssociationId` for fornecido, a aplicação de patches será feita como uma operação `Command` e a informação do valor `ExecutionType` no `AWS:ComplianceItem` enviado também será `Command`.
Se ainda não tiver uma associação que você deseja usar, crie uma associação executando o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html).
### Nome do parâmetro: `Snapshot ID`
**Uso**: opcional.
O `Snapshot ID` é um ID exclusivo (GUID) usado pelo Patch Manager para garantir que um conjunto de nós gerenciados, corrigidos em uma única operação, tenham o mesmo conjunto de patches aprovados. Embora o parâmetro seja definido como opcional, nossa recomendação baseada em práticas recomendadas depende de estar executando ou não o `AWS-RunPatchBaseline` em uma janela de manutenção, conforme descrito na tabela a seguir.
**`AWS-RunPatchBaseline`Práticas recomendadas da**
| Modo | Melhor prática | Detalhes |
| --- | --- | --- |
| RunningAWS-RunPatchBaselineDentro de uma janela de manutenção | Não forneça um ID de snapshot. O Patch Manager fornecerá para você. | Se você usar uma janela de manutenção para executar o `AWS-RunPatchBaseline`, não forneça seu próprio ID de snapshot gerado. Nesse cenário, o Systems Manager fornece um valor GUID com base no ID de execução da janela de manutenção. Isso garante que seja usado um ID correto para todas as invocações do `AWS-RunPatchBaseline` nessa janela de manutenção. Se você especificar um valor nesse cenário, observe que talvez o snapshot da lista de referência de patches não permaneça vigente por mais de três dias. Depois disso, um novo snapshot será gerado, mesmo que você especificar o mesmo ID depois que o snapshot expirar. |
| RunningAWS-RunPatchBaselineFora de uma janela de manutenção | Gere e especifique um valor de GUID personalizado para o ID do snapshot..¹ | Quando você não estiver usando uma janela de manutenção para executar o `AWS-RunPatchBaseline`, recomendamos gerar e especificar um ID de snapshot exclusivo para cada lista de referência de patches, principalmente se estiver executando o documento `AWS-RunPatchBaseline` em vários nós gerenciados na mesma operação. Se você não especificar um ID nesse cenário, o Systems Manager gerará um ID de snapshot diferente para cada nó gerenciado para o qual o comando for enviado. Em consequência disso, vários conjuntos de patches podem ser especificados entre os nós gerenciados. Por exemplo, digamos que você esteja executando o documento `AWS-RunPatchBaseline` diretamente do Run Command, uma ferramenta do AWS Systems Manager, e visando um grupo de 50 nós gerenciados. Ao especificar os resultados de um ID de snapshot personalizado, na geração de um único snapshot da lista de referência, que é usado para avaliar e corrigir todos os nós, garantindo que eles adquiram um estado consistente. |
| ¹ Você pode usar qualquer ferramenta capaz de gerar um GUID para gerar um valor para o parâmetro ID do snapshot. Por exemplo, no PowerShell, você pode usar o cmdlet `New-Guid` para gerar um GUID no formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`. |
### Nome do parâmetro: `InstallOverrideList`
**Uso**: opcional.
Usando o `InstallOverrideList`, especifique um URL de estilo caminho do Amazon S3 para uma lista de patches a serem instalados. Esta lista de instalação de patches mantida no formato YAML substitui os patches especificados pela linha de base de patch padrão atual. Isso fornece a você mais controle granular sobre quais patches estão instalados em seus nós gerenciados.
**Importante**
O nome do arquivo `InstallOverrideList` não pode conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).
O comportamento da operação de aplicação de patches ao usar o parâmetro `InstallOverrideList` difere entre os nós gerenciados pelo Linux e pelo macOS e os nós gerenciados pelo Windows Server. No Linux e no macOS, o Patch Manager tenta aplicar os patches incluídos na lista de patches `InstallOverrideList` que estão presentes em qualquer repositório habilitado no nó, independentemente de os patches corresponderem ou não às regras da lista de referência de patches. Em nós Windows Server, no entanto, os patches na lista de patches `InstallOverrideList` são aplicados *somente* se eles também correspondem às regras da lista de referência de patches.
Lembre-se de que os relatórios de conformidade de patch refletem estados de acordo com o que está especificado na linha de base de patch, e não o que você especifica em uma lista de patches `InstallOverrideList`. Em outras palavras, operações de verificação ignoram o parâmetro `InstallOverrideList`. Isso é para garantir que os relatórios de conformidade reflitam consistentemente os estados de patch de acordo com a política, em vez de algo aprovado para uma determinada operação de patch.
**nota**
Ao corrigir um nó que usa somente IPv6, assegure que a URL fornecida possa ser acessada a partir do nó. Se a opção de configuração `UseDualStackEndpoint` do SSM Agent estiver definida como `true`, um cliente S3 de dualstack será usado quando uma URL S3 for fornecida. Consulte [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obter mais informações sobre como configurar o atendente para usar dualstack.
Para obter uma descrição de como você pode usar o parâmetro `InstallOverrideList` para aplicar diferentes tipos de patches a um grupo de destino, em diferentes programações de janelas de manutenção, enquanto ainda usa uma única lista de referência de patches, consulte [Cenário de exemplo do uso do parâmetro InstallOverrideList em `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).
**Formatos URL válidos**
**nota**
Se o arquivo estiver armazenado em um bucket disponível publicamente, você poderá especificar um formato de URL https ou um URL de estilo de caminho do Amazon S3. Se o arquivo estiver armazenado em um bucket privado, você deverá especificar um URL do estilo de caminho do Amazon S3.
+ **Formato URL em https**:
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **URL estilo de caminho do Amazon S3**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formatos de conteúdo YAML válidos**
Os formatos que você usa para especificar patches em sua lista depende do sistema operacional do nó gerenciado. O formato geral, no entanto, é o seguinte:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Embora você possa fornecer campos adicionais em seu arquivo YAML, eles serão ignorados durante operações de patch.
Além disso, é recomendável verificar se o formato do arquivo YAML é válido antes de adicionar ou atualizar a lista no seu bucket do S3. Para obter mais informações sobre o formato YAML, consulte [yaml.org](http://www.yaml.org). Para as opções de ferramenta de validação, pesquise na Internet por "validadores de formato yaml".
------
#### [ Linux ]
**id**
O campo **id** é obrigatório. Use-o para especificar patches usando o nome do pacote e a arquitetura. Por exemplo: `'dhclient.x86_64'`. Você pode usar caracteres curinga no id para indicar vários pacotes. Por exemplo: `'dhcp*'` e `'dhcp*1.*'`.
**Cargo**
O campo **título** é opcional, mas em sistemas Linux ele fornece recursos de filtragem adicionais. Se você usar o **título**, ele deve conter informações sobre a versão do pacote em um dos seguintes formatos:
YUM/SUSE Linux Enterprise Server (SLES):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Para títulos de patches do Linux, você pode usar um ou mais caracteres curinga em qualquer posição para expandir o número de correspondências de pacotes. Por exemplo: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Por exemplo:
+ A versão do pacote apt 1.2.25 está atualmente instalada em seu nó gerenciado, mas a versão 1.2.27 agora está disponível.
+ Você adiciona a versão apt.amd64 1.2.27 à lista de patches. Depende da versão do apt utils.amd64 1.2.27, mas a versão apt utils.amd64 1.2.25 é especificada na lista.
Neste caso, a versão apt 1.2.27 não poderá ser instalada e será relatada como "Failed-NonCompliant."
------
#### [ Windows Server ]
**id**
O campo **id** é obrigatório. Use-o para especificar os patches usando IDs da Base de Dados de Conhecimento Microsoft (por exemplo, KB2736693 e IDs do boletim de segurança da Microsoft (por exemplo, MS17-023).
Todos os outros campos que você deseja fornecer em uma lista de patches para Windows são opcionais e são apenas para seu próprio uso informativo. Você pode usar campos adicionais, como **título**, **classificação**, **severidade**, ou qualquer outra coisa para fornecer informações mais detalhadas sobre os patches especificados.
------
#### [ macOS ]
**id**
O campo **id** é obrigatório. O valor do**id**pode ser fornecido usando um campo`{package-name}.{package-version}`ou um formato \$1package\$1name\$1.
------
**Exemplo de listas de patch**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nome do parâmetro: `RebootOption`
**Uso**: opcional.
**Opções**: `RebootIfNeeded` \$1 `NoReboot`
**Padrão**: `RebootIfNeeded`
**Atenção**
A opção padrão é `RebootIfNeeded`. Selecione a opção correta para o seu caso de uso. Por exemplo, se os nós gerenciados precisarem reinicializar imediatamente para concluir um processo de configuração, escolha `RebootIfNeeded`. Ou, se você precisar manter a disponibilidade do nó gerenciado até um horário de reinicialização agendado, escolha `NoReboot`.
**Importante**
Não é recomendável usar o Patch Manager para aplicar patches em instâncias de cluster no Amazon EMR (antes chamado de Amazon Elastic MapReduce). Em particular, não selecione a opção `RebootIfNeeded` para o parâmetro `RebootOption`. (Essa opção está disponível nos documentos do SSM Command para aplicação de patches em `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`.)
Os comandos subjacentes para aplicação de patches usando o Patch Manager utilizam os comandos `yum` e `dnf`. Portanto, as operações resultam em incompatibilidades por causa da forma como os pacotes são instalados. Para obter informações sobre os métodos preferenciais para atualizar o software nos clusters do Amazon EMR, consulte [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) no *Guia de gerenciamento do Amazon EMR*.
RebootIfNeeded
Quando você escolhe a opção `RebootIfNeeded`, o nó gerenciado é reinicializado em um dos seguintes casos:
+ Patch ManagerO instalou um ou mais patches.
O Patch Manager não avalia se uma reinicialização é *exigida* pelo patch. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.
+ O Patch Manager detecta um ou mais patches com um status de `INSTALLED_PENDING_REBOOT` durante a operação `Install`.
O status `INSTALLED_PENDING_REBOOT` pode significar que a opção `NoReboot` foi selecionada na última vez em que a operação `Install` foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado.
A reinicialização de nós gerenciados nesses dois casos garante que os pacotes atualizados sejam liberados da memória e mantenham o comportamento da aplicação de patches e da reinicialização consistente em todos os sistemas operacionais.
NoReboot
Quando você escolhe a opção `NoReboot`, o Patch Manager não reinicializa um nó gerenciado, mesmo que tenha instalado patches durante a operação `Install`. Essa opção é útil se você souber que os nós gerenciados não exigem reinicialização após a aplicação de patches, ou se houver aplicações ou processos em execução em um nó que não devam ser interrompidos por uma reinicialização da operação de aplicação de patch. Também é útil quando você deseja mais controle sobre o tempo de reinicializações de nós gerenciados, como, por exemplo, usando uma janela de manutenção.
Se você escolher a opção `NoReboot` e um patch for instalado, o patch receberá um status de `InstalledPendingReboot`. O nó gerenciado em si, no entanto, é marcado como `Non-Compliant`. Depois que ocorre uma reinicialização e uma operação `Scan` é executada, o status do nó gerenciado é atualizado para `Compliant`.
A opção `NoReboot` só impede reinicializações no nível do sistema operacional. Reinicializações no nível de serviço ainda podem ocorrer como parte do processo de aplicação de patches. Por exemplo, quando o Docker é atualizado, serviços dependentes, como o Amazon Elastic Container Service, podem ser reiniciados automaticamente mesmo com `NoReboot` habilitado. Se você tiver serviços críticos que não devem ser interrompidos, considere medidas adicionais, como remover temporariamente as instâncias do serviço ou programar a aplicação de patches durante as janelas de manutenção.
**Arquivo de rastreamento de instalação de patches**: para rastrear a instalação de patches, sobretudo os patches que foram instalados desde a última reinicialização do sistema, o Systems Manager mantém um arquivo em seu nó gerenciado.
**Importante**
Não exclua nem modifique o arquivo de monitoramento. Se esse arquivo for excluído ou corrompido, o relatório de conformidade de patch do nó gerenciado será impreciso. Se isso acontecer, reinicialize o nó e execute uma operação de verificação de patch para restaurar o arquivo.
Esse arquivo de rastreamento é armazenado nos seguintes locais em seus nós gerenciados:
+ Sistemas operacionais Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operacional :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nome do parâmetro: `BaselineOverride`
**Uso**: opcional.
Você pode definir preferências de patches no runtime usando o parâmetro `BaselineOverride`. Essa substituição de linha de base é mantida como um objeto JSON em um bucket do S3. Ele garante que as operações de patch usem as linhas de base fornecidas que correspondem ao sistema operacional host em vez de aplicar as regras da linha de base do patch padrão
**Importante**
O nome do arquivo `BaselineOverride` não pode conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).
Para obter mais informações sobre como usar o parâmetro `BaselineOverride`, consulte [Usar o parâmetro BaselineOverride](patch-manager-baselineoverride-parameter.md).
### Nome do parâmetro: `StepTimeoutSeconds`
**Uso**: obrigatório.
O tempo em segundos, entre 1 e 36.000 segundos (10 horas), para que um comando seja concluído antes de que seja considerado que ele falhou.
# Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineAssociation`
Como o`AWS-RunPatchBaseline`Documento,`AWS-RunPatchBaselineAssociation`O executa operações de aplicação de patches em instâncias para atualizações relacionadas à segurança e outros tipos de atualizações. Você pode usar o documento `AWS-RunPatchBaselineAssociation` para aplicar patches aos sistemas operacionais e aplicações.. (No Windows Server, o suporte a aplicações é limitado a atualizações de aplicações da Microsoft.)
Este documento oferece suporte a instâncias do Amazon Elastic Compute Cloud (Amazon EC2) para Linux, macOS, eWindows Server. Não há suporte para nós que não sejam do EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). O documento executará as ações adequadas a cada plataforma, invocando um módulo Python no Linux e no macOS e um módulo do PowerShell em instâncias do Windows.
O `AWS-RunPatchBaselineAssociation`, porém, difere do `AWS-RunPatchBaseline` das seguintes maneiras:
+ O `AWS-RunPatchBaselineAssociation` deve ser usado principalmente com associações do State Manager criadas usando o [Quick Setup](systems-manager-quick-setup.md), uma ferramenta do AWS Systems Manager. Especificamente, quando você usar o tipo de configuração do Host Management do Quick Setup, se você escolher a opção **Scan instances for missing patches daily** (Verificar patches ausentes nas instâncias diariamente), o sistema usará `AWS-RunPatchBaselineAssociation` para a operação.
Na maioria dos casos, no entanto, ao configurar suas próprias operações de patch, você deve escolher [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) ou [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md), ao invés do `AWS-RunPatchBaselineAssociation`.
+ Quando você usa o`AWS-RunPatchBaselineAssociation`, você pode especificar um key pair de tag no`BaselineTags`campo de parâmetro. Se uma lista de referência de patches personalizada na Conta da AWS compartilha essas tags, o Patch Manager, uma ferramenta do AWS Systems Manager, usa essa lista marcada quando ela é executada nas instâncias de destino em vez da lista de referência de patches "padrão" especificada no momento para o tipo de sistema operacional.
**nota**
Se você optar por usar `AWS-RunPatchBaselineAssociation` em operações de patch diferentes daquelas configuradas usando o Quick Setup e quiser usar o parâmetro `BaselineTags`, forneça algumas permissões adicionais para o [perfil](setup-instance-permissions.md) de instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Para obter mais informações, consulte [Nome do parâmetro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).
Ambos os formatos a seguir são válidos para o parâmetro `BaselineTags`:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Importante**
As chaves e os valores das chaves não podem conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).
+ Quando `AWS-RunPatchBaselineAssociation` é executado, os dados de conformidade de patches coletados são registrados usando o comando da API `PutComplianceItems` em vez do comando `PutInventory`, que é usado pelo `AWS-RunPatchBaseline`. Essa diferença significa que as informações de conformidade de patch que são armazenadas e relatadas por uma *Associação*. Os dados de conformidade de patch gerados fora dessa associação não são substituídos.
+ As informações de conformidade de patch relatadas após a execução de `AWS-RunPatchBaselineAssociation` indica se uma instância está ou não em conformidade. Ele não inclui detalhes em nível de patch, como demonstrado pela saída do comando da AWS Command Line Interface (AWS CLI) a seguir. Os filtros de comando em `Association` como o tipo de conformidade:
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
O sistema retorna informações como estas.
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
Se um valor de par de chaves de etiqueta tiver sido especificado como um parâmetro para o documento `AWS-RunPatchBaselineAssociation`, o Patch Manager pesquisa uma lista de referência de patches personalizada que corresponda ao tipo de sistema operacional e que tenha sido marcada com esse mesmo par de chaves de marca. Essa pesquisa não se limita à linha de base do patch padrão especificada atual ou à linha de base atribuída a um grupo de patches. Se nenhuma lista de referência for encontrada com as etiquetas especificadas, o Patch Manager procura por um grupo de patches, se um tiver sido especificado no comando que executa `AWS-RunPatchBaselineAssociation`. Se não houver correspondência com nenhum grupo de patches, o Patch Manager retorna à lista de referência de patches padrão atual da conta do sistema operacional.
Se mais de uma lista de referência de patches for encontrada com as tags especificadas no documento `AWS-RunPatchBaselineAssociation`, o Patch Manager retorna uma mensagem de erro indicando que apenas uma lista de referência de patches pode ser marcada com esse par de chave-valor para que a operação prossiga.
**nota**
Em nós do Linux, o gerenciador de pacotes apropriado para cada tipo de nó é usado para instalar pacotes:
Instâncias do Amazon Linux 2, Oracle Linux e RHEL usam YUM. Para operações YUM, o Patch Manager requer o `Python 2.6` ou uma versão posterior compatível (2.6 - 3.12). O Amazon Linux 2023 usa DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12)
As instâncias do Debian Server e Ubuntu Server usam o APT. Para operações APT, o Patch Manager requer uma versão compatível do `Python 3` (3.0 - 3.12).
Depois que todas as atualizações aprovadas e aplicáveis forem instaladas, e as reinicializações realizadas conforme a necessidade, as informações de conformidade do patch serão geradas em uma instância e relatadas ao Patch Compliance Service.
**nota**
Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaselineAssociation`, a instância não será reinicializada após a execução do Patch Manager. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).
Para obter informações sobre como visualizar dados de conformidade de patches, consulte [Sobre a conformidade de patches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineAssociation`Parâmetros do
`AWS-RunPatchBaselineAssociation`O oferece suporte a cinco parâmetros. Os parâmetros `Operation` e `AssociationId` são obrigatórios. Os parâmetros `InstallOverrideList`, `RebootOption` e `BaselineTags` são opcionais.
**Topics**
+ [Nome do parâmetro: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Nome do parâmetro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Nome do parâmetro: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Nome do parâmetro: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### Nome do parâmetro: `Operation`
**Uso**: obrigatório.
**Opções**: `Scan` \$1 `Install`.
Verificar
Quando você escolhe a opção `Scan`, o `AWS-RunPatchBaselineAssociation` determina o estado de conformidade dos patches da instância e retorna essas informações para o Patch Manager. A opção `Scan` não solicita que atualizações sejam instaladas ou que instâncias sejam reinicializadas. Em vez disso, a operação identifica onde existem atualizações ausentes que estão aprovadas e são aplicáveis à instância.
Instalar
Quando você escolhe a opção `Install`, o `AWS-RunPatchBaselineAssociation` tenta instalar as atualizações aprovadas e aplicáveis que estiverem ausentes na instância. As informações de conformidade dos patches geradas como parte de uma operação `Install` não listam atualizações ausentes, mas poderão indicar atualizações em estado malsucedido se, por qualquer motivo, a instalação da atualização não tiver tido êxito. Sempre que uma atualização é instalada em uma instância, a instância é reinicializada para garantir que a atualização está instalada e ativa. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no `AWS-RunPatchBaselineAssociation`, a instância não será reinicializada depis que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)).
Se um patch especificado pelas regras da lista de referência for instalado *antes* que o Patch Manager atualize a instância, o sistema poderá não ser reinicializado conforme esperado. Isso pode acontecer quando um patch é instalado manualmente por um usuário ou instalado automaticamente por outro programa, como o pacote `unattended-upgrades` no Ubuntu Server.
### Nome do parâmetro: `BaselineTags`
**Uso**: opcional.
`BaselineTags`O é um par de chaves/valores de tags exclusivo que você escolhe e atribui a uma linha de base de patch personalizada individual. Você pode especificar um ou mais valores para esse parâmetro. Ambos os formatos a seguir são válidos:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Importante**
As chaves e os valores das chaves não podem conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).
O valor de `BaselineTags` é usado pelo Patch Manager para garantir que todas as instâncias de um conjunto que são corrigidas em uma única operação tenham o mesmo conjunto de patches aprovados. Quando a operação de patch é executada, o Patch Manager verifica se uma linha de base de patch para o tipo de sistema operacional está marcada com o mesmo par chave-valor especificado para `BaselineTags`. Se houver uma correspondência, essa lista de referência do patch personalizada será usada. Se não houver uma correspondência, uma linha de base de patch será identificada de acordo com qualquer grupo de patches especificado para a operação de patch. Se não houver nenhum, a linha de base de patch predefinida gerenciada da AWS para esse sistema operacional é usada.
**Requisitos de permissão adicionais**
Se você usar o `AWS-RunPatchBaselineAssociation` em operações de patch diferentes daquelas configuradas usando o Quick Setup, e quiser usar o parâmetro `BaselineTags`, adicione as permissões a seguir ao [perfil](setup-instance-permissions.md) para instâncias do Amazon Elastic Compute Cloud (Amazon EC2).
**nota**
O Quick Setup e `AWS-RunPatchBaselineAssociation` não oferecem suporte a servidores on-premises e máquinas virtuais (VMs).
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
Substitua *patch-baseline-arn* pelo nome do recurso da Amazon (ARN) da linha de referência de patches à qual você deseja fornecer acesso no formato`arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`.
### Nome do parâmetro: `AssociationId`
**Uso**: obrigatório.
O `AssociationId` é o ID de uma associação existente no State Manager, uma ferramenta do AWS Systems Manager. Isso é usado pelo Patch Manager para adicionar dados de conformidade a uma associação especificada. Essa associação está relacionada a uma operação de `Scan` de patch habilitada em uma [configuração do Host Management criada no Quick Setup](quick-setup-host-management.md). Ao enviar resultados da aplicação de patch como dados de conformidade de associação em vez de dados de conformidade do inventário, as informações de conformidade do inventário existentes para as instâncias não são substituídas após uma operação de aplicação de patch, nem em outras IDs de associação. Se ainda não tiver uma associação que você deseja usar, crie uma associação executando o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html). Por exemplo:
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows Server ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### Nome do parâmetro: `InstallOverrideList`
**Uso**: opcional.
O uso do`InstallOverrideList`, você especifica um URL https ou um URL de estilo caminho do Amazon Simple Storage Service (Amazon S3) para uma lista de patches a serem instalados. Esta lista de instalação de patches mantida no formato YAML substitui os patches especificados pela linha de base de patch padrão atual. Isso fornece a você mais controle granular sobre quais patches estão instalados em suas instâncias.
**Importante**
O nome do arquivo `InstallOverrideList` não pode conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).
O comportamento da operação de aplicação de patches ao usar o parâmetro `InstallOverrideList` difere entre os nós gerenciados pelo Linux e pelo macOS e os nós gerenciados pelo Windows Server. No Linux e no macOS, o Patch Manager tenta aplicar os patches incluídos na lista de patches `InstallOverrideList` que estão presentes em qualquer repositório habilitado no nó, independentemente de os patches corresponderem ou não às regras da lista de referência de patches. Em nós Windows Server, no entanto, os patches na lista de patches `InstallOverrideList` são aplicados *somente* se eles também correspondem às regras da lista de referência de patches.
Lembre-se de que os relatórios de conformidade de patch refletem estados de acordo com o que está especificado na linha de base de patch, e não o que você especifica em uma lista de patches `InstallOverrideList`. Em outras palavras, operações de verificação ignoram o parâmetro `InstallOverrideList`. Isso é para garantir que os relatórios de conformidade reflitam consistentemente os estados de patch de acordo com a política, em vez de algo aprovado para uma determinada operação de patch.
**Formatos URL válidos**
**nota**
Se o arquivo estiver armazenado em um bucket disponível publicamente, você poderá especificar um formato de URL https ou um URL de estilo de caminho do Amazon S3. Se o arquivo estiver armazenado em um bucket privado, você deverá especificar um URL do estilo de caminho do Amazon S3.
+ **Exemplo de formato de URL https**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Exemplo de URL estilo de caminho do Amazon S3**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formatos de conteúdo YAML válidos**
Os formatos que você usa para especificar patches em sua lista depende do sistema operacional da instância. O formato geral, no entanto, é o seguinte:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Embora você possa fornecer campos adicionais em seu arquivo YAML, eles serão ignorados durante operações de patch.
Além disso, é recomendável verificar se o formato do arquivo YAML é válido antes de adicionar ou atualizar a lista no seu bucket do S3. Para obter mais informações sobre o formato YAML, consulte [yaml.org](http://www.yaml.org). Para as opções de ferramenta de validação, pesquise na Internet por "validadores de formato yaml".
+ Microsoft Windows
**id**
O campo **id** é obrigatório. Use-o para especificar os patches usando IDs da Base de Dados de Conhecimento Microsoft (por exemplo, KB2736693 e IDs do boletim de segurança da Microsoft (por exemplo, MS17-023).
Todos os outros campos que você deseja fornecer em uma lista de patches para Windows são opcionais e são apenas para seu próprio uso informativo. Você pode usar campos adicionais, como **título**, **classificação**, **severidade**, ou qualquer outra coisa para fornecer informações mais detalhadas sobre os patches especificados.
+ Linux
**id**
O campo **id** é obrigatório. Use-o para especificar patches usando o nome do pacote e a arquitetura. Por exemplo: `'dhclient.x86_64'`. Você pode usar caracteres curinga no id para indicar vários pacotes. Por exemplo: `'dhcp*'` e `'dhcp*1.*'`.
**título**
O campo **título** é opcional, mas em sistemas Linux ele fornece recursos de filtragem adicionais. Se você usar o **título**, ele deve conter informações sobre a versão do pacote em um dos seguintes formatos:
YUM/Red Hat Enterprise Linux (RHEL):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Para títulos de patches do Linux, você pode usar um ou mais caracteres curinga em qualquer posição para expandir o número de correspondências de pacotes. Por exemplo: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Por exemplo:
+ A versão do pacote apt 1.2.25 está atualmente instalada em sua instância, mas a versão 1.2.27 agora está disponível.
+ Você adiciona a versão apt.amd64 1.2.27 à lista de patches. Depende da versão do apt utils.amd64 1.2.27, mas a versão apt utils.amd64 1.2.25 é especificada na lista.
Neste caso, a versão apt 1.2.27 não poderá ser instalada e será relatada como "Failed-NonCompliant."
**Outros campos**
Todos os outros campos que você deseja fornecer em uma lista de patches para Linux são opcionais e são apenas para seu próprio uso informativo. Você pode usar campos adicionais, como **classificação**, **severidade**, ou qualquer outra coisa para fornecer informações mais detalhadas sobre os patches especificados.
**Exemplo de listas de patch**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nome do parâmetro: `RebootOption`
**Uso**: opcional.
**Opções**: `RebootIfNeeded` \$1 `NoReboot`
**Padrão**: `RebootIfNeeded`
**Atenção**
A opção padrão é `RebootIfNeeded`. Selecione a opção correta para o seu caso de uso. Por exemplo, se as instâncias precisarem reinicializar imediatamente para concluir um processo de configuração, escolha `RebootIfNeeded`. Ou, se você precisar manter a disponibilidade das instâncias até um horário de reinicialização agendado, escolha `NoReboot`.
**Importante**
A opção `NoReboot` só impede reinicializações no nível do sistema operacional. Reinicializações no nível de serviço ainda podem ocorrer como parte do processo de aplicação de patches. Por exemplo, quando o Docker é atualizado, serviços dependentes, como o Amazon Elastic Container Service, podem ser reiniciados automaticamente mesmo com `NoReboot` habilitado. Se você tiver serviços críticos que não devem ser interrompidos, considere medidas adicionais, como remover temporariamente as instâncias do serviço ou programar a aplicação de patches durante as janelas de manutenção.
**Importante**
Não é recomendável usar o Patch Manager para aplicar patches em instâncias de cluster no Amazon EMR (antes chamado de Amazon Elastic MapReduce). Em particular, não selecione a opção `RebootIfNeeded` para o parâmetro `RebootOption`. (Essa opção está disponível nos documentos do SSM Command para aplicação de patches em `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`.)
Os comandos subjacentes para aplicação de patches usando o Patch Manager utilizam os comandos `yum` e `dnf`. Portanto, as operações resultam em incompatibilidades por causa da forma como os pacotes são instalados. Para obter informações sobre os métodos preferenciais para atualizar o software nos clusters do Amazon EMR, consulte [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) no *Guia de gerenciamento do Amazon EMR*.
RebootIfNeeded
Quando você escolhe a opção `RebootIfNeeded`, a instância é reinicializada em um dos seguintes casos:
+ Patch ManagerO instalou um ou mais patches.
O Patch Manager não avalia se uma reinicialização é *exigida* pelo patch. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.
+ O Patch Manager detecta um ou mais patches com um status de `INSTALLED_PENDING_REBOOT` durante a operação `Install`.
O status `INSTALLED_PENDING_REBOOT` pode significar que a opção `NoReboot` foi selecionada na última vez em que a operação `Install` foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado.
A reinicialização de instâncias nesses dois casos garante que os pacotes atualizados sejam liberados da memória e mantém o comportamento de patch e reinicialização consistente em todos os sistemas operacionais.
NoReboot
Quando você escolhe a opção `NoReboot`, o Patch Manager não reinicializa uma instância, mesmo que tenha instalado patches durante a operação `Install`. Essa opção é útil se você souber que as instâncias não exigem reinicialização após a aplicação de patches, ou se houver aplicações ou processos em execução em uma instância que não devam ser interrompidos por uma reinicialização de operação de patch. Também é útil quando você deseja mais controle sobre o tempo de reinicializações de instâncias, como, por exemplo, usando uma janela de manutenção.
**Arquivo de rastreamento de instalação de patches**: para rastrear a instalação de patches, sobretudo os patches que foram instalados desde a última reinicialização do sistema, o Systems Manager mantém um arquivo na instância gerenciada.
**Importante**
Não exclua nem modifique o arquivo de monitoramento. Se esse arquivo for excluído ou corrompido, o relatório de conformidade de patch da instância será impreciso. Se isso acontecer, reinicialize a instância e execute uma operação de verificação de patch para restaurar o arquivo.
Esse arquivo de rastreamento é armazenado nos seguintes locais em suas instâncias gerenciadas:
+ Sistemas operacionais Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operacional :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# Documento de comando do SSM para a aplicação de patches: `AWS-RunPatchBaselineWithHooks`
O AWS Systems Manager é compatível com o `AWS-RunPatchBaselineWithHooks`, um documento do Systems Manager (documento SSM) para o Patch Manager, uma ferramenta do AWS Systems Manager. Este documento do SSM executa operações de aplicação de patches em nós gerenciados para atualizações de segurança e outros tipos de atualizações.
O `AWS-RunPatchBaselineWithHooks` difere do `AWS-RunPatchBaseline` das seguintes maneiras:
+ **Um documento do wrapper**, `AWS-RunPatchBaselineWithHooks`, é um wrapper para `AWS-RunPatchBaseline` e depende do `AWS-RunPatchBaseline` para algumas de suas operações.
+ **A operação `Install`**: o `AWS-RunPatchBaselineWithHooks` oferece suporte a hooks de ciclo de vida executados em pontos designados durante a aplicação de patches do nó gerenciado. Como as instalações de patches às vezes exigem nós gerenciados para reinicializar, a operação de aplicação patches é dividida em dois eventos, para um total de três hooks que oferecem suporte à funcionalidade personalizada. O primeiro hook é antes da operação `Install with NoReboot`. O segundo hook é depois da operação `Install with NoReboot`. O terceiro hook está disponível após a reinicialização do nó gerenciado.
+ **Sem suporte à lista de patches personalizada**–`AWS-RunPatchBaselineWithHooks`não é compatível com o`InstallOverrideList`parâmetro .
+ **Suporte ao SSM Agent**: o `AWS-RunPatchBaselineWithHooks` exige que o SSM Agent 3.0.502 ou posterior seja instalado em um nó gerenciado para a aplicação de patches.
Quando o documento é executado, ele usa a linha de base do patch atualmente especificada como “padrão” para um tipo de sistema operacional se nenhum grupo de patches for especificado. Caso contrário, ele usa as linhas de base do patch associadas ao grupo de patches. Para obter mais informações sobre grupos de patches, consulte [Grupos de patches](patch-manager-patch-groups.md).
Você pode usar o documento `AWS-RunPatchBaselineWithHooks` para aplicar patches aos sistemas operacionais e aplicações. (No Windows Server, o suporte a aplicações é limitado a atualizações de aplicações da Microsoft.)
Este documento oferece suporte a nós gerenciados do Linux e Windows Server. O documento executará as ações adequadas a cada plataforma.
**nota**
`AWS-RunPatchBaselineWithHooks` não é compatível com macOS.
------
#### [ Linux ]
Em nós gerenciados do Linux, o documento `AWS-RunPatchBaselineWithHooks` invoca um módulo do Python, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches usa regras e listas de patches aprovados e bloqueados para conduzir o gerenciador de pacotes apropriado para cada tipo de nó:
+ Nós gerenciados do Amazon Linux 2, Oracle Linux e RHEL 7 usam YUM. Para operações YUM, o Patch Manager requer o `Python 2.6` ou uma versão posterior compatível (2.6 - 3.12). O Amazon Linux 2023 usa DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12).
+ RHELOs nós gerenciados do 8 usam o DNF. Para operações DNF, o Patch Manager requer uma versão compatível do `Python 2` ou `Python 3` (2.6 - 3.12). (Nenhuma versão é instalada por padrão no RHEL 8. É necessário instalar um deles manualmente.)
+ As instâncias do Debian Server e Ubuntu Server usam o APT. Para operações APT, o Patch Manager requer uma versão compatível do `Python 3` (3.0 - 3.12).
------
#### [ Windows Server ]
Em nós gerenciados do Windows Server, o documento `AWS-RunPatchBaselineWithHooks` baixa e invoca um módulo do PowerShell, que, por sua vez, baixa um snapshot da lista de referência de patches que se aplica ao nó gerenciado. Esse snapshot da lista de referência de patches contém uma lista de patches aprovados que é compilada consultando a lista de referência de patches em um servidor Windows Server Update Service (WSUS). Esse snapshot da lista de referência de patches é passado para a API do Windows Update, que controla o download e a instalação de patches aprovados, conforme apropriado.
------
Cada snapshot é específico para uma Conta da AWS, um grupo de patches, um sistema operacional e um ID de snapshot. O snapshot é entregue por meio de um URL pré-assinado do Amazon Simple Storage Service (Amazon S3), que expira 24 horas após a criação do snapshot. No entanto, depois que o URL expirar, se você quiser aplicar o mesmo conteúdo de snapshot a outros nós gerenciados, você poderá gerar um novo URL pré-assinado do Amazon S3 até três dias após a criação do snapshot. Para fazer isso, use o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Depois que todas as atualizações aprovadas e aplicáveis forem instaladas, e as reinicializações realizadas conforme a necessidade, as informações de conformidade do patch serão geradas em um nó gerenciado e relatadas ao Patch Manager.
Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaselineWithHooks`, o nó gerenciado não será reinicializado após a execução do Patch Manager. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
**Importante**
Embora a opção `NoReboot` impeça a reinicialização do sistema operacional, ela não impede as reinicializações no nível de serviço que podem ocorrer quando determinados pacotes são atualizados. Por exemplo, atualizar pacotes como o Docker pode acionar reinicializações automáticas de serviços dependentes (como serviços de orquestração de contêineres), mesmo quando `NoReboot` é especificado.
Para obter informações sobre como visualizar dados de conformidade de patches, consulte [Sobre a conformidade de patches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineWithHooks`Etapas operacionais do
Quando o`AWS-RunPatchBaselineWithHooks`é executado, as seguintes etapas são executadas:
1. **Scan** - Uma operação `Scan` que usa o `AWS-RunPatchBaseline` é executada em um nó gerenciado, e um relatório de conformidade é gerado e carregado.
1. **Verificar estados de patch locais**- Um script é executado para determinar quais etapas serão executadas com base na operação selecionada e`Scan`Resultado da Etapa 1.
1. Se a operação selecionada for `Scan`, ela será marcada como concluída. A operação termina.
1. Se a operação selecionada for `Install`, o Patch Manager avalia o resultado `Scan` da Etapa 1 para determinar o que executar a seguir:
1. Se nenhum patch ausente for detectado e nenhuma reinicialização pendente for necessária, a operação prosseguirá diretamente para a etapa final (Etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas.
1. Se nenhum patch ausente for detectado, mas houver reinicializações pendentes necessárias e a opção de reinicialização selecionada for`NoReboot`, a operação prossegue diretamente para a etapa final (Etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas.
1. Caso contrário, a operação prossegue para a próxima etapa.
1. **Operação do hook pré-patch**: o documento do SSM que você forneceu para o primeiro hook do ciclo de vida, `PreInstallHookDocName`, é executado no seu nó gerenciado.
1. **Instalar com NoReboot** - Uma operação `Install` com a opção de reinicialização do `NoReboot` usando `AWS-RunPatchBaseline` é executada em seu nó gerenciado, e um relatório de conformidade é gerado e carregado.
1. **Operação do hook pós-instalação**: o documento do SSM que você forneceu para o segundo hook do ciclo de vida, `PostInstallHookDocName`, é executado em seu nó gerenciado.
1. **Verificar reinicializações** - Um script é executado para determinar se uma reinicialização é necessária para o nó gerenciado e quais etapas executar:
1. Se a opção de reinicialização selecionada for `NoReboot`, a operação prosseguirá diretamente para a etapa final (Etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas.
1. Se a opção de reinicialização selecionada for `RebootIfNeeded`, o Patch Manager verifica se há reinicializações pendentes necessárias do inventário coletado na Etapa 4. Isso significa que a operação continua na etapa 7 e o nó gerenciado é reinicializado em um dos seguintes casos:
1. O Patch Manager instalou um ou mais patches. (O Patch Manager não avalia se o patch exige uma reinicialização. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.)
1. O Patch Manager detecta um ou mais patches com um status de `INSTALLED_PENDING_REBOOT` durante a operação de instalação. O status `INSTALLED_PENDING_REBOOT` pode significar que a opção `NoReboot` foi selecionada na última vez em que a operação Instalar foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado.
Se nenhum patch que atenda a esses critérios for encontrado, a operação de aplicação de patch no nó gerenciado será concluída e a operação prosseguirá diretamente para a etapa final (etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas.
1. **Reinicializações e relatórios** - Uma operação de instalação com a opção de reinicialização do `RebootIfNeeded` é executado em seu nó gerenciado usando o `AWS-RunPatchBaseline` e um relatório de conformidade é gerado e carregado.
1. **Operação de hook pós-reinicialização**: o documento do SSM que você forneceu para o terceiro hook do ciclo de vida, `OnExitHookDocName`, é executado em seu nó gerenciado.
Para uma operação de `Scan`, se a Etapa 1 falhar, o processo de execução do documento pára e a etapa é relatada como falha, embora as etapas subsequentes sejam relatadas como bem-sucedidas.
Para uma operação `Install`, se qualquer uma das etapas do `aws:runDocument` falharem durante a operação, essas etapas serão relatadas como falhas e a operação prosseguirá diretamente para a etapa final (Etapa 8), que inclui um hook fornecido por você. Todas as etapas entre elas são ignoradas. Esta etapa é relatada como falhou, a última etapa relata o status de seu resultado de operação e todas as etapas entre são relatadas como bem-sucedidas.
## `AWS-RunPatchBaselineWithHooks`Parâmetros do
`AWS-RunPatchBaselineWithHooks`O oferece suporte a seis parâmetros.
O parâmetro `Operation` é obrigatório.
Os parâmetros `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` e `OnExitHookDocName` são opcionais.
O `Snapshot-ID` é tecnicamente opcional, mas recomendamos que você forneça um valor personalizado para ele quando executar o `AWS-RunPatchBaselineWithHooks` fora de uma janela de manutenção. Deixe o Patch Manager fornecer o valor automaticamente quando o documento é executado como parte de uma operação de janela de manutenção.
**Topics**
+ [Nome do parâmetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nome do parâmetro: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nome do parâmetro: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nome do parâmetro: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nome do parâmetro: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### Nome do parâmetro: `Operation`
**Uso**: obrigatório.
**Opções**: `Scan` \$1 `Install`.
Verificar
Quando você escolhe a opção `Scan`, o sistema usa o documento `AWS-RunPatchBaseline` para determinar o estado de conformidade dos patches do nó gerenciado e retorna essas informações para o Patch Manager. A opção `Scan` não solicita que atualizações sejam instaladas ou que nós gerenciados sejam reinicializados. Em vez disso, a operação identifica onde existem atualizações ausentes que estão aprovadas e são aplicáveis ao nó.
Instalar
Quando você escolhe a opção `Install`, o `AWS-RunPatchBaselineWithHooks` tenta instalar as atualizações aprovadas e aplicáveis que estiverem ausentes em seu nó gerenciado. As informações de conformidade dos patches geradas como parte de uma operação `Install` não listam atualizações ausentes, mas poderão indicar atualizações em estado malsucedido se, por qualquer motivo, a instalação da atualização não tiver tido êxito. Sempre que uma atualização é instalada em um nó gerenciado, o nó é reinicializado para garantir que a atualização esteja instalada e ativa. (Exceção: Se o parâmetro `RebootOption` estiver definido como `NoReboot` no documento `AWS-RunPatchBaselineWithHooks`, o nó gerenciado não será reinicializado depois que o Patch Manager for executado. Para obter mais informações, consulte [Nome do parâmetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)).
Se um patch especificado pelas regras da lista de referência for instalado *antes* que o Patch Manager atualize o nó gerenciado, o sistema poderá não ser reinicializado conforme esperado. Isso pode acontecer quando um patch é instalado manualmente por um usuário ou instalado automaticamente por outro programa, como o pacote `unattended-upgrades` no Ubuntu Server.
### Nome do parâmetro: `Snapshot ID`
**Uso**: opcional.
O `Snapshot ID` é um ID exclusivo (GUID) usado pelo Patch Manager para garantir que um conjunto de nós gerenciados, corrigidos em uma única operação, tenham o mesmo conjunto de patches aprovados. Embora o parâmetro seja definido como opcional, nossa recomendação baseada em práticas recomendadas depende de estar executando ou não o `AWS-RunPatchBaselineWithHooks` em uma janela de manutenção, conforme descrito na tabela a seguir.
**`AWS-RunPatchBaselineWithHooks`Práticas recomendadas da**
| Modo | Melhor prática | Detalhes |
| --- | --- | --- |
| RunningAWS-RunPatchBaselineWithHooksDentro de uma janela de manutenção | Não forneça um ID de snapshot. O Patch Manager fornecerá para você. | Se você usar uma janela de manutenção para executar o `AWS-RunPatchBaselineWithHooks`, não forneça seu próprio ID de snapshot gerado. Nesse cenário, o Systems Manager fornece um valor GUID com base no ID de execução da janela de manutenção. Isso garante que seja usado um ID correto para todas as invocações do `AWS-RunPatchBaselineWithHooks` nessa janela de manutenção. Se você especificar um valor nesse cenário, observe que talvez o snapshot da lista de referência de patches não permaneça vigente por mais de três dias. Depois disso, um novo snapshot será gerado, mesmo que você especificar o mesmo ID depois que o snapshot expirar. |
| RunningAWS-RunPatchBaselineWithHooksFora de uma janela de manutenção | Gere e especifique um valor de GUID personalizado para o ID do snapshot..¹ | Quando você não estiver usando uma janela de manutenção para executar o `AWS-RunPatchBaselineWithHooks`, recomendamos gerar e especificar um ID de snapshot exclusivo para cada lista de referência de patches, principalmente se estiver executando o documento `AWS-RunPatchBaselineWithHooks` em vários nós gerenciados na mesma operação. Se você não especificar um ID nesse cenário, o Systems Manager gerará um ID de snapshot diferente para cada nó gerenciado para o qual o comando for enviado. Em consequência disso, vários conjuntos de patches podem ser especificados entre os nós. Por exemplo, digamos que você esteja executando o documento `AWS-RunPatchBaselineWithHooks` diretamente do Run Command, uma ferramenta do AWS Systems Manager, e visando um grupo de 50 nós gerenciados. Ao especificar um ID de snapshot personalizado, é gerado um único snapshot da lista de referência, que é usado para avaliar e corrigir todos os nós gerenciados, garantindo que eles adquiram um estado consistente. |
| ¹ Você pode usar qualquer ferramenta capaz de gerar um GUID para gerar um valor para o parâmetro ID do snapshot. Por exemplo, no PowerShell, você pode usar o cmdlet `New-Guid` para gerar um GUID no formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`. |
### Nome do parâmetro: `RebootOption`
**Uso**: opcional.
**Opções**: `RebootIfNeeded` \$1 `NoReboot`
**Padrão**: `RebootIfNeeded`
**Atenção**
A opção padrão é `RebootIfNeeded`. Selecione a opção correta para o seu caso de uso. Por exemplo, se os nós gerenciados precisarem reinicializar imediatamente para concluir um processo de configuração, escolha `RebootIfNeeded`. Ou, se você precisar manter a disponibilidade do nó gerenciado até um horário de reinicialização agendado, escolha `NoReboot`.
**Importante**
Não é recomendável usar o Patch Manager para aplicar patches em instâncias de cluster no Amazon EMR (antes chamado de Amazon Elastic MapReduce). Em particular, não selecione a opção `RebootIfNeeded` para o parâmetro `RebootOption`. (Essa opção está disponível nos documentos do SSM Command para aplicação de patches em `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`.)
Os comandos subjacentes para aplicação de patches usando o Patch Manager utilizam os comandos `yum` e `dnf`. Portanto, as operações resultam em incompatibilidades por causa da forma como os pacotes são instalados. Para obter informações sobre os métodos preferenciais para atualizar o software nos clusters do Amazon EMR, consulte [Using the default AMI for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) no *Guia de gerenciamento do Amazon EMR*.
RebootIfNeeded
Quando você escolhe a opção `RebootIfNeeded`, o nó gerenciado é reinicializado em um dos seguintes casos:
+ Patch ManagerO instalou um ou mais patches.
O Patch Manager não avalia se uma reinicialização é *exigida* pelo patch. O sistema é reinicializado mesmo que o patch não exija uma reinicialização.
+ O Patch Manager detecta um ou mais patches com um status de `INSTALLED_PENDING_REBOOT` durante a operação `Install`.
O status `INSTALLED_PENDING_REBOOT` pode significar que a opção `NoReboot` foi selecionada na última vez em que a operação `Install` foi executada ou que um patch foi instalado fora do Patch Manager na última vez que o nó gerenciado foi reinicializado.
A reinicialização de nós gerenciados nesses dois casos garante que os pacotes atualizados sejam liberados da memória e mantenham o comportamento da aplicação de patches e da reinicialização consistente em todos os sistemas operacionais.
NoReboot
Quando você escolhe a opção `NoReboot`, o Patch Manager não reinicializa um nó gerenciado, mesmo que tenha instalado patches durante a operação `Install`. Essa opção é útil se você souber que os nós gerenciados não exigem reinicialização após a aplicação de patches, ou se houver aplicações ou processos em execução em um nó que não devam ser interrompidos por uma reinicialização da operação de aplicação de patch. Também é útil quando você deseja mais controle sobre o tempo de reinicializações de nós gerenciados, como, por exemplo, usando uma janela de manutenção.
Se você escolher a opção `NoReboot` e um patch for instalado, o patch receberá um status de `InstalledPendingReboot`. O nó gerenciado em si, no entanto, é marcado como `Non-Compliant`. Depois que ocorre uma reinicialização e uma operação `Scan` é executada, o status do nó é atualizado para `Compliant`.
**Arquivo de rastreamento de instalação de patches**: para rastrear a instalação de patches, sobretudo os patches que foram instalados desde a última reinicialização do sistema, o Systems Manager mantém um arquivo em seu nó gerenciado.
**Importante**
Não exclua nem modifique o arquivo de monitoramento. Se esse arquivo for excluído ou corrompido, o relatório de conformidade de patch do nó gerenciado será impreciso. Se isso acontecer, reinicialize o nó e execute uma operação de verificação de patch para restaurar o arquivo.
Esse arquivo de rastreamento é armazenado nos seguintes locais em seus nós gerenciados:
+ Sistemas operacionais Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operacional :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nome do parâmetro: `PreInstallHookDocName`
**Uso**: opcional.
**Padrão**: `AWS-Noop`.
O valor a ser fornecido para o parâmetro `PreInstallHookDocName` é o nome ou o nome do recurso da Amazon (ARN) de um documento do SSM de sua escolha. Você pode fornecer o nome de um documento gerenciado pela AWS ou o nome ou ARN de um documento SSM personalizado que você criou ou que foi compartilhado com você. (Para um documento do SSM que foi compartilhado com você de uma Conta da AWS diferente, você deve especificar o ARN completo do recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
O documento SSM especificado é executado antes da operação `Install` e executa todas as ações suportadas pelo SSM Agent, como um script shell para executar a verificação de integridade da aplicação, antes que o patch seja executado em seu nó gerenciado. Para obter uma lista de ações consulte [Referência de plug-ins de documentos de comando](documents-command-ssm-plugin-reference.md)). O nome do documento SSM padrão é `AWS-Noop`, que não executa nenhuma operação em um nó gerenciado.
Para obter informações sobre como criar um documento SSM personalizado, consulte [Criar conteúdo de documento do SSM](documents-creating-content.md).
### Nome do parâmetro: `PostInstallHookDocName`
**Uso**: opcional.
**Padrão**: `AWS-Noop`.
O valor a ser fornecido para o parâmetro `PostInstallHookDocName` é o nome ou o nome do recurso da Amazon (ARN) de um documento do SSM de sua escolha. Você pode fornecer o nome de um documento gerenciado pela AWS ou o nome ou ARN de um documento SSM personalizado que você criou ou que foi compartilhado com você. (Para um documento do SSM que foi compartilhado com você de uma Conta da AWS diferente, você deve especificar o ARN completo do recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
O documento SSM especificado é executado após o`Install with NoReboot`e executa todas as ações suportadas peloSSM Agent, como um script shell para instalar atualizações de terceiros antes da reinicialização. Para obter uma lista de ações consulte [Referência de plug-ins de documentos de comando](documents-command-ssm-plugin-reference.md)). O nome do documento SSM padrão é `AWS-Noop`, que não executa nenhuma operação em um nó gerenciado.
Para obter informações sobre como criar um documento SSM personalizado, consulte [Criar conteúdo de documento do SSM](documents-creating-content.md).
### Nome do parâmetro: `OnExitHookDocName`
**Uso**: opcional.
**Padrão**: `AWS-Noop`.
O valor a ser fornecido para o parâmetro `OnExitHookDocName` é o nome ou o nome do recurso da Amazon (ARN) de um documento do SSM de sua escolha. Você pode fornecer o nome de um documento gerenciado pela AWS ou o nome ou ARN de um documento SSM personalizado que você criou ou que foi compartilhado com você. (Para um documento do SSM que foi compartilhado com você de uma Conta da AWS diferente, você deve especificar o ARN completo do recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
O documento SSM especificado é executado após a operação de reinicialização do nó gerenciado e executa todas as ações suportadas pelo SSM Agent, como um script shell para verificar a integridade do nó após a conclusão da operação de aplicação do patch. Para obter uma lista de ações consulte [Referência de plug-ins de documentos de comando](documents-command-ssm-plugin-reference.md)). O nome do documento SSM padrão é `AWS-Noop`, que não executa nenhuma operação em um nó gerenciado.
Para obter informações sobre como criar um documento SSM personalizado, consulte [Criar conteúdo de documento do SSM](documents-creating-content.md).
# Cenário de exemplo do uso do parâmetro InstallOverrideList em `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`
Você poderá usar o parâmetro `InstallOverrideList` quando quiser substituir os patches especificados pela lista de referência de patches padrão atual no Patch Manager, uma ferramenta do AWS Systems Manager. Este tópico fornece exemplos que mostram como usar esse parâmetro para obter o seguinte:
+ Aplique diferentes conjuntos de patches a um grupo de nós gerenciados de destino.
+ Aplique esses conjuntos de patches em diferentes frequências.
+ Use a mesma lista de referência de patches para as operações.
Digamos que você quer instalar duas categorias diferentes de patches em nós gerenciados do Amazon Linux 2. Você deseja instalar esses patches em programações diferentes usando janelas de manutenção. Deseja que uma janela de manutenção seja executada todas as semanas e instale todos os patches `Security`. Deseja que outra janela de manutenção seja executada uma vez por mês e instale todos os patches disponíveis ou categorias de patches que não sejam `Security`.
No entanto, só é possível definir uma lista de referência de patches por vez como o padrão para um sistema operacional. Esse requisito ajuda a evitar situações em que uma lista de referência de patches aprova um patch enquanto outro o bloqueia, o que pode levar a problemas entre versões conflitantes.
A estratégia a seguir permite que você use o parâmetro `InstallOverrideList` para aplicar tipos de patches diferentes a um grupo de destino, em diferentes programações, enquanto ainda usa a mesma lista de referência de patches.
1. Na lista de referência de patches padrão, confirme se apenas as atualizações `Security` estão especificadas.
1. Crie uma janela de manutenção que execute o `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation` toda semana. Não especifique uma lista de substituição.
1. Crie uma lista de substituição dos patches de todos os tipos que você deseja aplicar mensalmente e armazene-a em um bucket do Amazon Simple Storage Service (Amazon S3).
1. Crie uma segunda janela de manutenção que é executada uma vez por mês. No entanto, para a tarefa do Run Command registrada para essa janela de manutenção, especifique o local da lista de substituição.
O resultado: somente patches `Security`, conforme definido na lista de referência de patches padrão, são instalados toda semana. Todos os patches disponíveis, ou qualquer subconjunto de patches que você definir, são instalados todos os meses.
**nota**
Ao corrigir um nó que usa somente IPv6, assegure que a URL fornecida possa ser acessada a partir do nó. Se a opção de configuração `UseDualStackEndpoint` do SSM Agent estiver definida como `true`, um cliente S3 de dualstack será usado quando uma URL S3 for fornecida. Consulte [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obter mais informações sobre como configurar o atendente para usar dualstack.
Para obter mais informações e listas de exemplo, consulte [Nome do parâmetro: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).
# Usar o parâmetro BaselineOverride
Defina as preferências da aplicação de patches no runtime usando o recurso de substituição da lista de referência no Patch Manager, uma ferramenta do AWS Systems Manager. Faça isso especificando um bucket do Amazon Simple Storage Service (Amazon S3) que contenha um objeto JSON com uma lista de referência de patches. A operação de patch usa as linhas de base fornecidas no objeto JSON que correspondem ao sistema operacional host em vez de aplicar as regras da linha de base do patch padrão.
**Importante**
O nome do arquivo `BaselineOverride` não pode conter os seguintes caracteres: crase (`), aspas simples ('), aspas duplas (") e cifrão (\$1).
Exceto quando uma operação de patch usa uma política de patch, usar o parâmetro `BaselineOverride` não substitui a conformidade do patch da linha de base fornecida no parâmetro. Os resultados de saída são registrados nos logs de Stdout do Run Command, uma ferramenta do AWS Systems Manager. Os resultados apenas imprimem pacotes marcados como `NON_COMPLIANT`. Isso significa que o pacote está marcado como`Missing`,`Failed`,`InstalledRejected`, ou`InstalledPendingReboot`.
No entanto, quando uma operação de patch usa uma política de patch, o sistema passa o parâmetro de substituição do bucket do S3 associado e o valor de conformidade é atualizado para o nó gerenciado. Para obter mais informações sobre comportamentos de políticas de patch, consulte [Configurações de políticas de patches em Quick Setup](patch-manager-policies.md).
**nota**
Ao corrigir um nó que usa somente IPv6, assegure que a URL fornecida possa ser acessada a partir do nó. Se a opção de configuração `UseDualStackEndpoint` do SSM Agent estiver definida como `true`, um cliente S3 de dualstack será usado quando uma URL S3 for fornecida. Consulte [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obter mais informações sobre como configurar o atendente para usar dualstack.
## Usando a substituição da linha de base do patch com parâmetros Id de Snapshot ou Lista de Sobreposição de Instalação
Há dois casos em que a substituição da linha de base do patch tem um comportamento digno de nota.
**Usando substituição de linha de base e ID de Snapshot ao mesmo tempo**
Os IDs do snapshot garantem que todos os nós gerenciados em um determinado comando de patch apliquem a mesma coisa. Por exemplo, se você corrigir 1.000 nós gerenciados ao mesmo tempo, os patches serão os mesmos.
Ao usar um ID de Snapshot e uma substituição de linha de base de patch, o ID de Snapshot tem precedência sobre a substituição de linha de base do patch. As regras de substituição de linha de base ainda serão usadas, mas elas serão avaliadas apenas uma vez. No exemplo anterior, os patches em seus 1.000 nós gerenciados continuarão sempre os mesmos. Se, no meio da operação de patch, você alterou o arquivo JSON no bucket S3 referenciado para ser algo diferente, os patches aplicados continuarão sendo os mesmos. Isso ocorre porque o ID do Snapshot foi fornecido.
**Usando substituição de linha de base e Lista de Substituição de Instalação ao mesmo tempo**
Você não pode usar esses dois parâmetros ao mesmo tempo. O documento de patch falhará se ambos os parâmetros forem fornecidos e não executará nenhuma verificação ou instalação em seu nó gerenciado.
## Exemplos de código
O exemplo de código a seguir para Python mostra como gerar a substituição de linha de base do patch.
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
Isso produz uma substituição de linha de base de patch, como a seguir.
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```