Cómo se calculan las fechas de lanzamiento y actualización de los paquetes - AWS Systems Manager

Cómo se calculan las fechas de lanzamiento y actualización de los paquetes

importante

La información de esta página es válida para los sistemas operativos (SO) Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 y Amazon Linux 2023 para las instancias de Amazon Elastic Compute Cloud (Amazon EC2). Amazon Web Services crea y mantiene los paquetes para estos tipos de sistemas operativos. La forma en que los fabricantes de otros sistemas operativos administran sus paquetes y repositorios afecta a la forma en que se calculan sus fechas de lanzamiento y actualización. Para sistemas operativos distintos de Amazon Linux, Amazon Linux 2, Amazon Linux 2022 y Amazon Linux 2023, como Red Hat Enterprise Linux (RHEL) y SUSE Linux Enterprise Server (SLES), consulte la documentación del fabricante para obtener información sobre cómo se actualizan y mantienen sus paquetes.

En la configuración de las líneas de base de revisiones personalizadas que cree, para la mayoría de los tipos de sistemas operativos, puede especificar que la instalación de las revisiones se apruebe automáticamente después de un número de días determinado. AWS proporciona varias líneas de base de revisiones predefinidas que incluyen fechas de aprobación automática de 7 días.

Un tiempo de espera hasta la aprobación automática es el número de días que se debe esperar después de que se haya lanzado la revisión y antes de que se apruebe automáticamente para aplicarla. Por ejemplo, se crea una regla mediante la clasificación de CriticalUpdates y se configura para establecer un tiempo de espera hasta la aprobación automática de 7 días. Como resultado, una nueva revisión crítica con una fecha de lanzamiento o una fecha de última actualización datada del 7 de julio se aprueba automáticamente el 14 de julio.

Para evitar resultados imprevistos en los retrasos de aprobación automática para Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 y Amazon Linux 2023, es importante saber cómo se calculan las fechas de lanzamiento y las de actualización.

En la mayoría de los casos, el tiempo de espera hasta la aprobación automática para instalar las revisiones se calcula a partir de un valor de Updated Date en updateinfo.xml, no un valor de Release Date. Los siguientes son detalles importantes sobre estos cálculos de fechas:

  • La Release Date es la fecha en que se lanza un aviso. Esto no significa que el paquete esté necesariamente disponible en los repositorios asociados.

  • La Update Date es la fecha más reciente en que se actualizó el aviso. La actualización de un aviso puede representar algo tan pequeño como la actualización de un texto o descripción. Esto no significa que el paquete se lanzó ese día o que esté necesariamente disponible en los repositorios asociados.

    Esto significa que un paquete puede tener un valor de Update Date del 7 de julio, pero no podrá instalarse hasta, por ejemplo, el 13 de julio. Supongamos que, en este caso, una línea de base de revisiones que especifica un tiempo de espera de 7 días hasta la aprobación automática se ejecuta en una operación Install el 14 de julio. Dado que el valor de Update Date es 7 días antes de la fecha de ejecución, las revisiones y actualizaciones del paquete se instalan el 14 de julio. La instalación se realiza a pesar de que solo ha pasado 1 día desde que el paquete se puede instalar.

  • Un paquete que contenga revisiones del sistema operativo o aplicación se puede actualizar más de una vez después del lanzamiento inicial.

  • Se puede lanzar un paquete en los repositorios administrados por AWS, y más tarde revertirse si se identifican problemas relacionados con él.

En algunas operaciones de aplicación de revisiones, es posible que estos factores no sean importantes. Por ejemplo, si una línea de base de revisiones está configurada para instalar una revisión con valores de gravedad de Low y Medium, además de una clasificación de Recommended, cualquier tiempo de espera hasta la aprobación automática podría tener poco impacto en las operaciones.

Sin embargo, en los casos de revisiones críticas o de gravedad alta cuya programación sea más importante, puede ser conveniente tener un mayor control sobre cuándo deben instalarse. El método recomendado para hacerlo es utilizar repositorios de origen de revisiones alternativos en lugar de los predeterminados para las operaciones de aplicación de revisiones en un nodo administrado.

Puede especificar repositorios de origen de parches alternativos al crear una base de referencia de parches personalizada. En cada base de referencia de parches personalizada, es posible especificar configuraciones de origen de parches para un máximo de 20 versiones de un sistema operativo Linux compatible. Para obtener más información, consulte Cómo especificar un repositorio de origen de parches alternativo (Linux).