AWS Systems Manager Change Manager não está mais aberto a novos clientes. Os clientes atuais podem continuar usando o serviço normalmente. Para obter mais informações, consulte mudança de disponibilidade do AWS Systems Manager Change Manager.
Como as datas de lançamento e atualização de pacotes são calculadas
Importante
As informações desta página se aplicam aos sistemas operacionais (SOs) Amazon Linux 2 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 do Amazon Linux 2 e Amazon Linux 2023, como Red Hat Enterprise Linux, consulte a documentação do fabricante para obter informações sobre como os pacotes deles 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 2 e Amazon Linux 2023, é importante entender como as datas de lançamento e de atualização desses serviços são calculadas.
nota
Se um repositório do Amazon Linux 2 ou Amazon Linux 2023 não fornecer informações de data de lançamento para pacotes, o Patch Manager usará o horário de compilação do pacote como a data para especificações de data de aprovação automática. Se o horário de compilação do pacote não puder ser determinado, o Patch Manager usa uma data padrão de 1º de janeiro de 1970. Isso resulta no Patch Manager ignorar quaisquer especificações de data de aprovação automática nas lista de referência de patches que estão configuradas para aprovar patches para qualquer data após 1º de janeiro de 1970.
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 Datede 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çãoInstallem 14 de julho. Como o valorUpdate 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 obter mais informações, consulte Como especificar um repositório de origem de patches alternativo (Linux).