Como especificar um repositório de origem de patches alternativo (Linux) - AWS Systems Manager
Considerações importantes para repositórios alternativosExemplos de uso de repositórios de origem de patches alternativos

Como especificar um repositório de origem de patches alternativo (Linux)

Ao usar os repositórios padrão configurados em um nó gerenciado para operações de aplicação de patch, o Patch Manager, um recurso do AWS Systems Manager, verifica ou instala patches relacionados à segurança. Esse é o comportamento padrão do Patch Manager. Para obter informações completas sobre como o Patch Manager seleciona e instala patches de segurança, consulte Como os patches de segurança são selecionados.

Em sistemas Linux, no entanto, você também pode usar o Patch Manager para instalar patches que não são relacionados à segurança ou que estão em um repositório de origem diferente do padrão configurado em seu nó gerenciado. Você pode especificar os repositórios de origem de patches alternativos ao criar uma linha de base de patch personalizada. Em cada linha de base de patch personalizada, você pode especificar as configurações de origem de patches para até 20 versões de um sistema operacional Linux compatível.

Por exemplo, suponha que a sua frota Ubuntu Server inclua nós gerenciados do Ubuntu Server 14.04 e Ubuntu Server 16.04. Nesse caso, você pode especificar os repositórios alternativo para cada versão na mesma linha de base de patch personalizada. Para cada versão, insira um nome, especifique o tipo de versão do sistema operacional (produto) e forneça uma configuração do repositório. Você também pode especificar um único repositório de origem alternativo que se aplica a todas as versões de um sistema operacional compatível.

nota

Executar uma linha personalizada de referência de patches, que especifica repositórios de patches alternativos para um nó gerenciado, não torna esses repositórios o novo padrão no sistema operacional. Após a conclusão da operação de patch, os repositórios previamente configurados como padrão para o sistema operacional do nó permanecerão como padrão.

Para obter uma lista de exemplos de situações para usar essa opção, consulte Exemplos de uso de repositórios de origem de patches alternativos mais adiante neste tópico.

Para obter informações sobre linhas de base de patch padrão e personalizadas, consulte Listas de referência de patches predefinidas e personalizadas.

Exemplo: usar o console

Para especificar repositórios de origem de patches alternativos quando você está trabalhando no console do Systems Manager, use a seção Patch sources (Origens de patches) na página Create patch baseline (Criar linha de base de patch). Para obter informações sobre como usar as opções de Fontes de patch, consulte Criar uma lista de referência de patches personalizada para o Linux.

Exemplos: usar a AWS CLI

Para obter um exemplo do uso da opção --sources com a AWS Command Line Interface (AWS CLI), consulte Criar uma linha de base de patch com repositórios personalizados para diferentes versões do SO.

Considerações importantes para repositórios alternativos

Tenha em mente os seguintes pontos ao planejar a estratégia de patches usando alternativas de repositórios de patch.

Somente repositórios especificados são usados para a aplicação de patches

Especificar repositórios alternativos não significa especificar repositórios adicionais. Você pode optar por especificar repositórios que não sejam os configurados como padrão em um nó gerenciado. No entanto, você também deve especificar os repositórios padrão como parte da configuração de origem de patch alternativo se você deseja que as atualizações sejam aplicadas.

Por exemplo, em nós gerenciados do Amazon Linux 2, os repositórios padrão são amzn2-core e amzn2extra-docker. Se você deseja incluir o repositório Extra Packages for Enterprise Linux (EPEL) em suas operações de patch, deve especificar os três repositórios como repositórios alternativos.

nota

Executar uma linha personalizada de referência de patches, que especifica repositórios de patches alternativos para um nó gerenciado, não torna esses repositórios o novo padrão no sistema operacional. Após a conclusão da operação de patch, os repositórios previamente configurados como padrão para o sistema operacional do nó permanecerão como padrão.

O comportamento de patches para distribuições com base em YUM depende do manifesto updateinfo.xml

Quando você especifica repositórios alternativos de patch para distribuições com base em YUM, como Amazon Linux 1 ou Amazon Linux 2, Red Hat Enterprise Linux, ou CentOS, o comportamento de patches depende de o repositório incluir ou não uma atualização manifesto na forma de um arquivo updateinfo.xml completo e formatado corretamente. Esse arquivo especifica a data de lançamento, classificações e gravidades dos vários pacotes. Qualquer um dos seguintes afetará o comportamento de patch:

  • Se você filtrar Classificação e Gravidade, mas eles não estiverem especificados em updateinfo.xml, o pacote não será incluído pelo filtro. Isso também significa que os pacotes sem um arquivo updateinfo.xml não serão incluídos no patch.

  • Se você filtrar ApprovalAfterDays, mas a data de liberação do pacote não estiver no formato Unix Epoch (ou não tiver data de liberação especificada), o pacote não será incluído pelo filtro.

  • Há uma exceção se você selecionar a caixa de seleção Incluir atualizações não relacionadas a segurança na página Criar linha de base de patch. Nesse caso, os pacotes sem um arquivo updateinfo.xml (ou que contenham esse arquivo sem valores propriamente formatados de Classificação, Gravidade e Data) serão incluídos na lista de patches pré-filtrados. (Eles ainda deverão corresponder aos outros requisitos de regras de linha de base de patch para serem instalados.)

Exemplos de uso de repositórios de origem de patches alternativos

Exemplo 1 - Atualizações não de segurança para o Ubuntu Server

Você já está usando o Patch Manager para instalar patches de segurança em uma frota de nós gerenciados do Ubuntu Server usando a lista de referência de patches AWS-UbuntuDefaultPatchBaseline predefinida fornecida pela AWS. Você pode criar uma nova linha de base de patch baseada nesse padrão, mas especifique nas regras de aprovação que você deseja que as atualizações não relacionadas à segurança que fazem parte da distribuição padrão sejam instaladas também. Quando essa lista de referência de patches é executada em nós, os patches para problemas relacionados ou não a segurança são aplicados. Você também pode optar por aprovar patches não relacionados a segurança nas exceções de patches que você especifica para uma linha de base.

Exemplo 2 – Personal Package Archives (PPA) para o Ubuntu Server

As instâncias do Ubuntu Server estão executando o software que é distribuído por meio de um Personal Package Archives (PPA) para Ubuntu. Nesse caso, crie uma lista de referência de patches que especifique um repositório PPA que você configurou em seu nó gerenciado como repositório de origem para a operação de aplicação de patch. Em seguida, use o Run Command para executar o documento da lista de referência de patches em seus nós.

Exemplo 3: aplicações corporativas internas no Amazon Linux

Você deve executar algumas aplicações necessárias para a conformidade regulatória do setor nos nós gerenciados do Amazon Linux. Você pode configurar um repositório para essas aplicações em nós, usar o YUM inicialmente para instalar as aplicações e, em seguida, atualizar ou criar uma nova lista de referência de patches para incluir esse novo repositório corporativo. Depois disso, você pode usar o Run Command para executar o documento AWS-RunPatchBaseline com a opção Scan para conferir se o pacote corporativo está listado entre os pacotes instalados e está atualizado dentro do nó gerenciado. Se ele não estiver atualizado, você pode executar o documento novamente usando a opção Install para atualizar os aplicativos.