如何计算软件包发布日期和更新日期
重要
本页面上的信息适用于 Amazon Elastic Compute Cloud（Amazon EC2）实例的 Amazon Linux 1、Amazon Linux 2、Amazon Linux 2022 和 Amazon Linux 2023 操作系统（OS）。这些 OS 类型的软件包由 Amazon Web Services 创建和维护。其他操作系统的软件包和存储库的发布日期和更新日期的计算方式受其制造商管理方式的影响。对于除 Amazon Linux、Amazon Linux 2、Amazon Linux 2022 和 Amazon Linux 2023 之外的操作系统，如 Red Hat Enterprise Linux（RHEL）和 SUSE Linux Enterprise Server（SLES），请参阅制造商的文档，以了解有关如何更新和维护其程序包的信息。
在您创建的自定义补丁基准设置中，对于大多数操作系统类型，您可以指定补丁在特定天数后自动批准安装。AWS 提供了几个预定义的补丁基准，其中包括 7 天的自动批准日期。
自动批准延迟是发布补丁后到自动批准补丁用于修补前等待的天数。例如，可以使用 CriticalUpdates 分类创建规则，并将其配置为自动批准延迟为 7 天。此时，发布日期或最后更新日期为 7 月 7 日的新关键补丁将在 7 月 14 日自动获得批准。
为避免在 Amazon Linux 1、Amazon Linux 2、Amazon Linux 2022 和 Amazon Linux 2023 上出现自动批准延迟的意外结果，了解其发布日期和更新日期的计算方式至关重要。
在大多数情况下，安装补丁之前的自动批准等待时间根据 updateinfo.xml 中的 Updated Date 值，而不是 Release Date 值计算。以下是有关这些日期计算的重要细节：
-
Release Date是指通知发布的日期。但这并不意味着该软件包在相关存储库中可用。 -
Update Date是指通知最后更新的日期。通知的更新可以指文本更新或描述更新这样的小更新。但这并不意味着该软件包在该日期发布，也不意味着在相关存储库中可用。这意味着如果软件包的
Update Date值为 7 月 7 日，可能直到（例如）7 月 13 日才能安装。假设在这种情况下，如果补丁基准指定的自动批准延迟为 7 天，则会在 7 月 14 日的Install操作中运行。因为Update Date值是运行日期前 7 天，所以软件包中的补丁和更新将在 7 月 14 日安装。即使自软件包可用于实际安装以来仅过了 1 天，安装仍会进行。 -
包含操作系统或应用程序补丁的软件包在首次发布后可以更新多次。
-
软件包可以发布到 AWS 托管存储库中，但如果以后发现它有问题，则可以回滚。
在某些补丁操作中，这些因素可能并不重要。例如，如果补丁基准配置为安装严重性的值为 Low 和 Medium，且分类为 Recommended 的补丁，则任何自动批准延迟都可能几乎不会对您的操作产生影响。
但是，如果关键或高严重性补丁的安装时间较为重要，您可能需要对补丁的安装时间进行更多的控制。执行此操作的建议方法是使用替代补丁源存储库，而不是默认存储库来执行托管节点上的补丁操作。
您可以在创建自定义补丁基准时指定备用补丁源存储库。在每个自定义补丁基准中，您可以为多达 20 个版本的受支持的 Linux 操作系统指定补丁源配置。有关更多信息，请参阅 如何指定备用补丁源存储库 (Linux)。
