Calcul des dates de sortie et des mises à jour des packages

Important

Les informations de cette page s'appliquent aux systèmes d'exploitation (OS) Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 et Amazon Linux 2023 pour les instances Amazon Elastic Compute Cloud (Amazon EC2). Amazon Web Services crée et gère les packages pour ces types de systèmes d'exploitation. La gestion des packages et des référentiels par les fabricants d'autres systèmes d'exploitation influe sur le calcul de leurs dates de sortie et de mise à jour. Pour les systèmes d'exploitation autres qu'Amazon Linux, Amazon Linux 2, Amazon Linux 2022 et Amazon Linux 2023, tels que Red Hat Enterprise Linux (RHEL) et SUSE Linux Enterprise Server (SLES), consultez la documentation du fabricant pour plus d'informations sur la mise à jour et l'entretien de ses packages.

Dans les paramètres des lignes de base de correctifs personnalisées que vous créez, pour la plupart des types de systèmes d'exploitation, vous pouvez spécifier que l'installation des correctifs est approuvée automatiquement après un certain nombre de jours. AWS fournit plusieurs lignes de base de correctifs prédéfinies qui incluent des dates d'approbation automatique de 7 jours.

Un délai d'auto-approbation correspond au nombre de jours à attendre après la publication du correctif et avant son approbation. Par exemple, vous créez une règle à l'aide de la classification CriticalUpdates et la configurez pour un délai d'approbation automatique de 7 jours. Par conséquent, pour un nouveau correctif critique dont la date de sortie ou de la dernière mise à jour est le 7 juillet, l'approbation automatique aura lieu le 14 juillet.

Pour éviter les résultats inattendus liés aux retards d'approbation automatique sur Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 et Amazon Linux 2023, il est important de comprendre comment leurs dates de sortie et de mise à jour sont calculées.

Dans la plupart des cas, le temps d'attente de l'approbation automatique avant l'installation des correctifs est calculé à partir d'une valeur Updated Date dans updateinfo.xml, et non pas d'une valeur Release Date. Voici des détails importants relatifs à ces calculs de date :

• La Release Date est la date à laquelle un avis est publié. Cette publication ne signifie pas forcément que le package est disponible dans les référentiels associés.

• La Update Date est la dernière date de la mise à jour de l'avis. La mise à jour d'un avis peut être aussi petite que la mise à jour d'un texte ou d'une description. Cette mise à jour ne signifie pas que le package est publié à partir de cette date ni qu'il est forcément disponible dans les référentiels associés.

  Cela signifie qu'un package peut avoir une valeur Update Date du 7 juillet mais être indisponible pour l'installation avant (par exemple) le 13 juillet. Supposons dans ce cas qu'un référentiel de correctifs spécifiant un délai d'approbation automatique de 7 jours s'exécute dans une opération Install le 14 juillet. Étant donné que la valeur Update Date est de 7 jours avant la date d'exécution, les correctifs et les mises à jour du package sont installés le 14 juillet. L'installation a lieu même si un seul jour s'est écoulé depuis que le package est disponible pour une installation réelle.

• Après sa publication initiale, un package contenant des correctifs de système d'exploitation ou d'application peut être mis à jour plusieurs fois.

• Un package peut être publié dans les référentiels AWS gérés, puis annulé si des problèmes sont découverts ultérieurement.

Dans certaines opérations d'application de correctifs, ces facteurs peuvent être insignifiants. Par exemple, si la configuration d'un référentiel de correctifs permet l'installation d'un correctif dont les valeurs de gravité sont de Low et Medium, et une classification de Recommended, tout retard de l'approbation automatique aura peu d'impact sur vos opérations.

Toutefois, dans les cas où la synchronisation des correctifs critiques ou de gravité élevée est plus importante, vous pouvez exercer un plus grand contrôle lors de l'installation des correctifs. La méthode recommandée pour ce faire consiste à utiliser des référentiels sources de correctifs alternatifs au lieu des référentiels par défaut pour les opérations d'application de correctifs sur un nœud géré.

Vous pouvez spécifier d'autres référentiels source de correctifs lors de la création d'un référentiel de correctifs personnalisée. Dans chaque référentiel de correctifs personnalisée, vous pouvez spécifier des configurations source de correctifs pour un maximum de 20 versions d'un système d'exploitation Linux pris en charge. Pour de plus amples informations, veuillez consulter Spécification d'un autre référentiel source de correctifs (Linux).