• 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). # 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.