Como as datas de lançamento e atualização de pacotes são calculadas

Importante

As informações nesta página se aplicam aos sistemas operacionais (SOs) Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 e Amazon Linux 2023 para instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Os pacotes para esses tipos de SOs são criados e mantidos pela Amazon Web Services. A forma como os fabricantes de outros SOs gerenciam seus pacotes e repositórios afeta a forma como as datas de lançamento e de atualização deles são calculadas. Para sistemas operacionais além de Amazon Linux, Amazon Linux 2, Amazon Linux 2022 e Amazon Linux 2023, como Red Hat Enterprise Linux (RHEL) e SUSE Linux Enterprise Server (SLES), consulte a documentação do fabricante para obter informações sobre como seus pacotes são atualizados e mantidos.

Nas configurações da lista de referência de patches personalizada que você cria, para a maioria dos tipos de SO, é possível especificar que os patches sejam aprovados automaticamente para instalação após um determinado número de dias. O AWS fornece várias listas de referência de patches predefinidas que incluem datas de aprovação automática de sete dias.

Um atraso de aprovação automática é o número de dias para aguardar após o lançamento do patch, antes que a aplicação do patch seja aprovada automaticamente. Por exemplo, você cria uma regra usando a classificação CriticalUpdates e a configura para um atraso de aprovação automática de 7 dias. Como resultado, um novo patch crítico com data de lançamento ou data da última atualização em 7 de julho será aprovado automaticamente em 14 de julho.

Para evitar resultados inesperados com atrasos na aprovação automática no Amazon Linux 1, no Amazon Linux 2, no Amazon Linux 2022 e no Amazon Linux 2023, é importante entender como as datas de lançamento e de atualização desses serviços são calculadas.

Na maioria dos casos, o tempo de espera de aprovação automática antes da instalação dos patches é calculado com base em um valor Updated Date em updateinfo.xml, e não um valor Release Date. Veja a seguir detalhes importantes sobre esses cálculos de data:

• Release Date é a data de lançamento de uma notificação. Isso não significa que o pacote já esteja necessariamente disponível nos repositórios associados.

• Update Date é a última data em que a notificação foi atualizada. Uma atualização de uma notificação pode representar algo tão pequeno quanto uma atualização de texto ou descrição. Isso não significa que o pacote tenha sido liberado nessa data ou já esteja necessariamente disponível nos repositórios associados.

  Isso significa que um pacote pode ter um valor Update Date de 7 de julho, mas não estará disponível para instalação até (p. ex.) 13 de julho. Nesse caso, suponha que uma lista de referência de patches que especifique um atraso de aprovação automática de 7 dias seja executada em uma operação Install em 14 de julho. Como o valor Update Date é de 7 dias antes da data de execução, os patches e atualizações no pacote serão instalados em 14 de julho. A instalação acontece mesmo que apenas 1 dia tenha passado desde que o pacote foi disponibilizado para instalação efetiva.

• Um pacote contendo patches de sistema operacional ou aplicativo pode ser atualizado mais de uma vez após o lançamento inicial.

• Um pacote pode ser lançado nos repositórios gerenciados da AWS e ser revertido se houver a descoberta de problemas posteriormente.

Em algumas operações de aplicação de patches, talvez esses fatores não sejam importantes. Por exemplo, se uma lista de referência de patches estiver configurada para instalar um patch com valores de severidade de Low e Medium, e uma classificação de Recommended, qualquer atraso na aprovação automática pode ter pouco impacto em suas operações.

No entanto, em casos nos quais o tempo de patches críticos ou de alta severidade é mais importante, pode ser necessário que você exerça mais controle sobre quando os patches são instalados. O método recomendado para fazer isso é usar repositórios alternativos de origem de patch em vez dos repositórios padrão para operações de patch em um 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. Para ter mais informações, consulte Como especificar um repositório de origem de patches alternativo (Linux).