Cómo se instalan las revisiones - AWS Systems Manager

Cómo se instalan las revisiones

Patch Manager, una capacidad de AWS Systems Manager, utiliza el mecanismo integrado adecuado para un tipo de sistema operativo con el fin de instalar actualizaciones en un nodo administrado. Por ejemplo, en Windows Server, se utiliza la API de Windows Update y en Amazon Linux 2 se utiliza el administrador de paquetes yum.

Elija entre las siguientes pestañas para obtener información acerca de cómo Patch Manager instala parches en un sistema operativo.

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

En los nodos administrados de Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 y Amazon Linux 2023, el flujo de trabajo de la instalación de parches es el siguiente:

  1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro InstallOverrideList para los documentos AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

  2. Aplique GlobalFilters tal y como se especifica en la base de referencia de parches, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.

  3. Aplique ApprovalRules tal y como se especifica en la base de referencia de parches. Cada regla de aprobación puede definir un paquete como aprobado.

    Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación Include nonsecurity updates (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

    Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.

    Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

  4. Aplique ApprovedPatches tal y como se especifica en la base de referencia de parches. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por GlobalFilters o si ninguna regla de aprobación especificada en ApprovalRules les concede la aprobación.

  5. Aplique RejectedPatches tal y como se especifica en la base de referencia de parches. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

  6. Si hay varias versiones de un parche aprobadas, se aplica la última.

  7. La API de actualización de YUM (Amazon Linux 1, Amazon Linux 2) o la API de actualización de DNF (Amazon Linux 2022, Amazon Linux 2023) se aplica a los parches aprobados de la siguiente manera:

    • Para las líneas de base de revisiones predeterminadas y proporcionadas por AWS, solo se aplican las revisiones especificadas en updateinfo.xml (solo actualizaciones de seguridad). Esto se debe a que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad no está seleccionada. Las líneas de base predefinidas equivalen a una línea de base personalizada con lo siguiente:

      • La casilla de verificación Incluir actualizaciones no relacionadas con la seguridad no está seleccionada

      • Una lista de GRAVEDAD de [Critical, Important]

      • Una lista de CLASIFICACIÓN de [Security, Bugfix]

      En Amazon Linux 1 y Amazon Linux 2, el comando YUM equivalente para este flujo de trabajo es el siguiente:

      sudo yum update-minimal --sec-severity=critical,important --bugfix -y

      En Amazon Linux 2022 y Amazon Linux 2023, el comando dnf equivalente para este flujo de trabajo es el siguiente:

      sudo dnf upgrade-minimal --sec-severity=critical --sec-severity=important --bugfix -y

      Si la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad está seleccionada, se aplican las revisiones que están en updateinfo.xml y no las que están en updateinfo.xml (actualizaciones de seguridad y no relacionadas con la seguridad).

      En Amazon Linux 1 y Amazon Linux 2, si se selecciona una línea de base con Incluir actualizaciones no relacionadas con la seguridad y tiene una lista de gravedad de [Critical, Important] y una lista de clasificación de [Security, Bugfix], el comando YUM equivalente es el siguiente:

      sudo yum update --security --sec-severity=critical,important --bugfix -y

      En Amazon Linux 2022 y Amazon Linux 2023, el comando dnf equivalente es el siguiente:

      sudo dnf upgrade --security --sec-severity=critical --sec-severity=important --bugfix -y
      nota

      Para Amazon Linux 2022 y Amazon Linux 2023, un nivel de gravedad de revisiones Medium equivale a un nivel de gravedad Moderate que podría definirse en algunos repositorios externos. Si incluye Medium revisiones de gravedad en la línea de base de revisiones, también se instalarán en las instancias Moderate revisiones de gravedad de revisiones externas.

      Cuando consulta los datos de cumplimiento mediante la acción DescribeInstancePatches de la API, el filtrado para el nivel de gravedad Medium informa revisiones con niveles de gravedad tanto Medium como Moderate.

      Amazon Linux 2022 y Amazon Linux 2023 también admiten el nivel de gravedad de la revisión None, que es reconocido por el administrador de paquetes DNF.

  8. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption).

CentOS and CentOS Stream

En los nodos administrados de CentOS y CentOS Stream, el flujo de trabajo de instalación de revisiones es el siguiente:

  1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro InstallOverrideList para los documentos AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

    Aplique GlobalFilters tal y como se especifica en la base de referencia de parches, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.

  2. Aplique ApprovalRules tal y como se especifica en la base de referencia de parches. Cada regla de aprobación puede definir un paquete como aprobado.

    Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación Include nonsecurity updates (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

    Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.

    Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

  3. Aplique ApprovedPatches tal y como se especifica en la base de referencia de parches. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por GlobalFilters o si ninguna regla de aprobación especificada en ApprovalRules les concede la aprobación.

  4. Aplique RejectedPatches tal y como se especifica en la base de referencia de parches. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

  5. Si hay varias versiones de un parche aprobadas, se aplica la última.

  6. Se aplica la API de actualización YUM (en las versiones CentOS 6.x y 7.x) o la actualización DNF (en CentOS 8 y CentOS Stream) en las revisiones aprobadas.

  7. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption).

Servidor Debian and Raspberry Pi OS

En las instancias de Debian Server y Raspberry Pi OS (anteriormente Raspbian), el flujo de trabajo de instalación de revisiones es el siguiente:

  1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro InstallOverrideList para los documentos AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

  2. Si está disponible una actualización para python3-apt (una interfaz de biblioteca de Python para libapt), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción Include nonsecurity updates [Incluir actualizaciones no relacionadas con la seguridad]).

    importante

    Solo en Debian Server 8: debido a que algunos nodos administrados de Debian Server 8.* hacen referencia a un repositorio de paquetes obsoleto (jessie-backports), Patch Manager lleva a cabo los siguientes pasos adicionales para garantizar que las operaciones de aplicación de revisiones se efectúen correctamente:

    1. En el nodo administrado, la referencia al repositorio jessie-backports se indica en la lista de ubicaciones de origen (/etc/apt/sources.list.d/jessie-backports). Por consiguiente, no se intenta descargar los parches desde esa ubicación.

    2. Se importa una clave de firma de actualización de seguridad de Stretch. Esta clave proporciona los permisos necesarios para las operaciones de actualización e instalación en las distribuciones de Debian Server 8.*.

    3. A esta altura, se ejecuta la operación apt-get para asegurarse de que la versión más reciente de python3-apt esté instalada antes de que comience el proceso de aplicación de parches.

    4. Una vez finalizado el proceso de instalación, se restaura la referencia al repositorio jessie-backports y se elimina la clave de firma del conjunto de claves de las fuentes de apt. Esto se hace para dejar la configuración del sistema tal como estaba antes de la operación de aplicación de parches.

    La próxima vez que Patch Manager actualice el sistema, se repetirá el mismo proceso.

  3. Aplique GlobalFilters tal y como se especifica en la base de referencia de parches, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.

  4. Aplique ApprovalRules tal y como se especifica en la base de referencia de parches. Cada regla de aprobación puede definir un paquete como aprobado.

    nota

    Como no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Debian Server, las opciones de aprobación automática no son compatibles con este sistema operativo.

    Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación Include nonsecurity updates (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

    Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.

    Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

    nota

    En Debian Server y Raspberry Pi OS, las versiones candidatas a revisiones se limitan a las revisiones incluidas en debian-security.

  5. Aplique ApprovedPatches tal y como se especifica en la base de referencia de parches. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por GlobalFilters o si ninguna regla de aprobación especificada en ApprovalRules les concede la aprobación.

  6. Aplique RejectedPatches tal y como se especifica en la base de referencia de parches. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

  7. La biblioteca de APT se utiliza para actualizar paquetes.

    nota

    Patch Manager no admite el uso de la opción Pin-Priority de APT para asignar prioridades a los paquetes. Patch Manager agrega las actualizaciones disponibles de todos los repositorios habilitados y selecciona la actualización más reciente que coincide con la línea de base de cada paquete instalado.

  8. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption).

macOS

En los nodos administrados macOS, el flujo de trabajo de instalación de revisiones es el siguiente:

  1. La lista de propiedades /Library/Receipts/InstallHistory.plist es un registro de software que se ha instalado y actualizado mediante los administradores de paquetes softwareupdate y installer. Mediante la herramienta de línea de comandos pkgutil (para installer) y el administrador de paquetes softwareupdate, se ejecutan comandos de la CLI para analizar esta lista.

    Para installer, la respuesta a los comandos de la CLI incluye detalles de package name, version, volume, location y install-time, pero Patch Manager solo utiliza package name y version.

    Para softwareupdate, la respuesta a los comandos de la CLI incluye el nombre del paquete (display name), version y date, pero Patch Manager utiliza únicamente el nombre del paquete y la versión.

    Para Brew y Brew Cask, Homebrew no admite que sus comandos se ejecuten con el usuario raíz. Como resultado, Patch Manager consulta y ejecuta los comandos de Homebrew como propietario del directorio de Homebrew o como usuario válido perteneciente al grupo de propietarios de ese directorio. Los comandos se asemejan a softwareupdate y installer, y se ejecutan a través de un subproceso de Python para recopilar los datos de los paquetes, y el resultado se analiza con el objetivo de identificar los nombres y las versiones de los paquetes.

  2. Aplique GlobalFilters tal y como se especifica en la base de referencia de parches, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.

  3. Aplique ApprovalRules tal y como se especifica en la base de referencia de parches. Cada regla de aprobación puede definir un paquete como aprobado.

  4. Aplique ApprovedPatches tal y como se especifica en la base de referencia de parches. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por GlobalFilters o si ninguna regla de aprobación especificada en ApprovalRules les concede la aprobación.

  5. Aplique RejectedPatches tal y como se especifica en la base de referencia de parches. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

  6. Si hay varias versiones de un parche aprobadas, se aplica la última.

  7. Invoque la CLI del paquete correspondiente en el nodo administrado para procesar las revisiones aprobadas de la siguiente manera:

    nota

    installer carece de la funcionalidad para buscar e instalar actualizaciones. Por lo tanto, para installer, Patch Manager solo notifica qué paquetes están instalados. Como resultado, los paquetes installer nunca se notifican como Missing.

    • Para las líneas de base de revisiones predeterminadas proporcionadas por AWS y las líneas de base de revisiones personalizadas en las que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad no está seleccionada, solo se aplican las actualizaciones de seguridad.

    • Para las líneas de base de revisiones personalizadas en las que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad sí está seleccionada, se aplican tanto las actualizaciones de seguridad como las que no están relacionadas con la seguridad.

  8. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption).

Oracle Linux

En los nodos administrados Oracle Linux, el flujo de trabajo de instalación de revisiones es el siguiente:

  1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro InstallOverrideList para los documentos AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

  2. Aplique GlobalFilters tal y como se especifica en la base de referencia de parches, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.

  3. Aplique ApprovalRules tal y como se especifica en la base de referencia de parches. Cada regla de aprobación puede definir un paquete como aprobado.

    Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación Include nonsecurity updates (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

    Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.

    Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

  4. Aplique ApprovedPatches tal y como se especifica en la base de referencia de parches. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por GlobalFilters o si ninguna regla de aprobación especificada en ApprovalRules les concede la aprobación.

  5. Aplique RejectedPatches tal y como se especifica en la base de referencia de parches. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

  6. Si hay varias versiones de un parche aprobadas, se aplica la última.

  7. En los nodos administrados de la versión 7, la API de actualización de YUM se aplica a las revisiones aprobadas como se indica a continuación:

    • Para las líneas de base de revisiones proporcionadas por AWS y para las líneas de base de revisiones personalizadas en las que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad no está seleccionada, solo se aplican las revisiones especificadas en updateinfo.xml (solo actualizaciones de seguridad).

      El comando yum equivalente para este flujo de trabajo es:

      sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y

    • Para las líneas de base de revisiones personalizadas en las que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad sí está seleccionada, se aplican las revisiones que están en updateinfo.xml y las que no están en updateinfo.xml (actualizaciones de seguridad y no relacionadas con la seguridad).

      El comando yum equivalente para este flujo de trabajo es:

      sudo yum update --security --bugfix -y

      En los nodos administrados de las versiones 8 y 9, la API de actualización de DNF se aplica a las revisiones aprobadas como se indica a continuación:

      • Para las líneas de base de revisiones proporcionadas por AWS y para las líneas de base de revisiones personalizadas en las que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad no está seleccionada, solo se aplican las revisiones especificadas en updateinfo.xml (solo actualizaciones de seguridad).

        El comando yum equivalente para este flujo de trabajo es:

        sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important

      • Para las líneas de base de revisiones personalizadas en las que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad sí está seleccionada, se aplican las revisiones que están en updateinfo.xml y las que no están en updateinfo.xml (actualizaciones de seguridad y no relacionadas con la seguridad).

        El comando yum equivalente para este flujo de trabajo es:

        sudo dnf upgrade --security --bugfix

  8. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption).

AlmaLinux, RHEL, and Rocky Linux

En los nodos administrados de AlmaLinux, Red Hat Enterprise Linux y Rocky Linux, el flujo de trabajo de instalación de revisión es el siguiente:

  1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro InstallOverrideList para los documentos AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

  2. Aplique GlobalFilters tal y como se especifica en la base de referencia de parches, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.

  3. Aplique ApprovalRules tal y como se especifica en la base de referencia de parches. Cada regla de aprobación puede definir un paquete como aprobado.

    Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación Include nonsecurity updates (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

    Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.

    Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

  4. Aplique ApprovedPatches tal y como se especifica en la base de referencia de parches. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por GlobalFilters o si ninguna regla de aprobación especificada en ApprovalRules les concede la aprobación.

  5. Aplique RejectedPatches tal y como se especifica en la base de referencia de parches. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

  6. Si hay varias versiones de un parche aprobadas, se aplica la última.

  7. La API de actualización de YUM (en RHEL 7) o la API de actualización de DNF (en AlmaLinux 8 y 9, RHEL 8 y 9 y Rocky Linux 8 y 9) se aplica a las revisiones aprobadas de la siguiente manera:

    • Para las líneas de base de revisiones proporcionadas por AWS y para las líneas de base de revisiones personalizadas en las que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad no está seleccionada, solo se aplican las revisiones especificadas en updateinfo.xml (solo actualizaciones de seguridad).

      En RHEL 7, el comando yum equivalente para este flujo de trabajo es:

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      En AlmaLinux, RHEL 8 y Rocky Linux, los comandos dnf equivalentes para este flujo de trabajo son los siguientes:

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y

    • Para las líneas de base de revisiones personalizadas en las que la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad sí está seleccionada, se aplican las revisiones que están en updateinfo.xml y las que no están en updateinfo.xml (actualizaciones de seguridad y no relacionadas con la seguridad).

      En RHEL 7, el comando yum equivalente para este flujo de trabajo es:

      sudo yum update --security --bugfix -y

      En AlmaLinux 8 y 9, RHEL 8 y 9 y Rocky Linux 8 y 9, el comando dnf equivalente para este flujo de trabajo es el siguiente:

      sudo dnf update --security --bugfix -y

  8. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption).

SLES

En los nodos administrados de SUSE Linux Enterprise Server (SLES), el flujo de trabajo de instalación de revisiones es el siguiente:

  1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro InstallOverrideList para los documentos AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

  2. Aplique GlobalFilters tal y como se especifica en la base de referencia de parches, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.

  3. Aplique ApprovalRules tal y como se especifica en la base de referencia de parches. Cada regla de aprobación puede definir un paquete como aprobado.

    Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación Include nonsecurity updates (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

    Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.

    Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

  4. Aplique ApprovedPatches tal y como se especifica en la base de referencia de parches. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por GlobalFilters o si ninguna regla de aprobación especificada en ApprovalRules les concede la aprobación.

  5. Aplique RejectedPatches tal y como se especifica en la base de referencia de parches. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

  6. Si hay varias versiones de un parche aprobadas, se aplica la última.

  7. La API de actualización de Zypper se aplica a los parches aprobados.

  8. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption).

Servidor Ubuntu

En los nodos administrados Ubuntu Server, el flujo de trabajo de instalación de revisiones es el siguiente:

  1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro InstallOverrideList para los documentos AWS-RunPatchBaseline o AWS-RunPatchBaselineAssociation, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

  2. Si está disponible una actualización para python3-apt (una interfaz de biblioteca de Python para libapt), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción Include nonsecurity updates [Incluir actualizaciones no relacionadas con la seguridad]).

  3. Aplique GlobalFilters tal y como se especifica en la base de referencia de parches, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.

  4. Aplique ApprovalRules tal y como se especifica en la base de referencia de parches. Cada regla de aprobación puede definir un paquete como aprobado.

    nota

    Debido a que no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Ubuntu Server, las opciones de aprobación automática no son compatibles con este sistema operativo.

    Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación Include nonsecurity updates (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

    Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.

    Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

    Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación Include nonsecurity updates (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

    nota

    Para cada versión de Ubuntu Server, las versiones candidatas a parches se limitan a los parches que forman parte del repositorio asociado a esa versión, como se muestra a continuación:

    • Ubuntu Server 14.04 LTS: trusty-security

    • Ubuntu Server 16.04 LTS: xenial-security

    • Ubuntu Server 18.04 LTS: bionic-security

    • Ubuntu Server 20.04 LTS): focal-security

    • Ubuntu Server 20.10 STR: groovy-security

    • Ubuntu Server 22.04 LTS: jammy-security

    • Ubuntu Server 23.04: lunar-lobster

  5. Aplique ApprovedPatches tal y como se especifica en la base de referencia de parches. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por GlobalFilters o si ninguna regla de aprobación especificada en ApprovalRules les concede la aprobación.

  6. Aplique RejectedPatches tal y como se especifica en la base de referencia de parches. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

  7. La biblioteca de APT se utiliza para actualizar paquetes.

    nota

    Patch Manager no admite el uso de la opción Pin-Priority de APT para asignar prioridades a los paquetes. Patch Manager agrega las actualizaciones disponibles de todos los repositorios habilitados y selecciona la actualización más reciente que coincide con la línea de base de cada paquete instalado.

  8. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption).

Windows Server

Cuando se realiza una operación de aplicación de revisiones en un nodo administrado de Windows Server, este solicita una instantánea de la base de referencia de revisiones adecuada a Systems Manager. Esta instantánea contiene la lista de todas las actualizaciones disponibles en la base de referencia de parches que se aprobaron para su implementación. Esta lista de actualizaciones se envía a la API de Windows Update, que determina qué actualizaciones son aplicables al nodo administrado y se instala cuando sea necesario. Si se instalan las actualizaciones, el nodo administrado se reinicia después, tantas veces como sea necesario para completar todas las revisiones necesarias. (Excepción: si el parámetro RebootOption se configura en NoReboot en el documento AWS-RunPatchBaseline, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte Nombre del parámetro: RebootOption). El resumen de la operación de aplicación de parches se puede encontrar en la salida de la solicitud de Run Command. Puede encontrar más registros en el nodo administrado de la carpeta %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs.

Como la API de Windows Update se utiliza para descargar e instalar parches, se respetan todos los ajustes de la política de grupos de Windows Update. No se necesitan ajustes de la política de grupos para utilizar Patch Manager, pero se aplicará la configuración que haya definido, por ejemplo, dirigir nodos administrados a un servidor Windows Server Update Services (WSUS).

nota

De forma predeterminada, Windows descarga todos los parches del sitio de Windows Update de Microsoft porque Patch Manager utiliza la API de Windows Update para impulsar la descarga e instalar los parches. Como resultado, el nodo administrado debe poder acceder al sitio de Microsoft Windows Update; si no, la aplicación de revisiones no se realizará correctamente. De forma alternativa, puede configurar un servidor WSUS para que funcione como un repositorio de revisiones y configurar los nodos administrados para que se dirijan al servidor WSUS mediante las políticas de grupo.