• El panel de AWS Systems Manager CloudWatch dejará de estar disponible después del 30 de abril de 2026. Los clientes pueden seguir utilizando la consola de Amazon CloudWatch para ver, crear y administrar sus paneles de Amazon CloudWatch, tal y como lo hacen actualmente. Para obtener más información, consulte la [documentación del panel de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
# Documentos de comando de SSM para la aplicación de revisiones a nodos administrados
En este tema se describen los nueve documentos de Systems Manager (documentos de SSM) disponibles para que pueda mantener los nodos administrados actualizados con las últimas revisiones relacionadas con la seguridad.
Se recomienda utilizar solo cinco de estos documentos en las operaciones de aplicación de revisiones. En conjunto, estos cinco documentos de SSM le proporcionan una gama completa de opciones de aplicación de revisiones con AWS Systems Manager. Cuatro de estos documentos se publicaron después de los cuatro documentos de SSM heredados a los que sustituyen, y contienen ampliaciones o consolidaciones de funcionalidad.
**Documentos de SSM recomendados para las revisiones**
Recomendamos utilizar los cinco documentos de SSM a continuación en las operaciones de revisión.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**Documentos de SSM heredados para las revisiones**
Los siguientes cuatro documentos de SSM heredados permanecen disponibles en algunas Regiones de AWS, pero ya no se actualizan ni se admiten. No se garantiza que estos documentos funcionen en entornos IPv6, y solo son compatibles con IPv4. No se puede garantizar que funcionen en todos los escenarios y es posible que pierdan soporte en el futuro. Le recomendamos que no utilice estos documentos para las operaciones de aplicación de parches.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Para ver los pasos para configurar las operaciones de aplicación de revisiones en un entorno que solo admite IPv6, consulte [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md).
Consulte las secciones siguientes para obtener más información sobre el uso de estos documentos de SSM en las operaciones de aplicación de revisiones.
**Topics**
+ [Documentos de SSM recomendados para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-recommended)
+ [Documentos de SSM heredados para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-legacy)
+ [Limitaciones conocidas de los documentos de SSM para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-known-limitations)
+ [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Ejemplo de escenario para utilizar el parámetro InstallOverrideList en `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Uso del parámetro BaselineOverride](patch-manager-baselineoverride-parameter.md)
## Documentos de SSM recomendados para la aplicación de revisiones a nodos administrados
Se recomienda utilizar los siguientes cinco documentos de SSM para las operaciones de aplicación de revisiones en los nodos administrados.
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
Admite configurar las funciones básicas de Windows Update y utilizarlas para instalar actualizaciones de forma automática (o para desactivar las actualizaciones automáticas). Disponible en todas las Regiones de AWS.
Este documento de SSM indica a Windows Update que descargue e instale las actualizaciones especificadas y que reinicie los nodos administrados según sea necesario. Utilice este documento con State Manager, una herramienta de AWS Systems Manager, para asegurarse de que Windows Update conserve su configuración. También puede ejecutarlo de forma manual con Run Command, una herramienta de AWS Systems Manager, para cambiar la configuración de Windows Update.
Los parámetros disponibles en este documento permiten especificar la categoría de actualizaciones que se deben instalar (o si se deben desactivar las actualizaciones automáticas), así como especificar el día de la semana y la hora del día en que se deben ejecutar las operaciones de aplicación de revisiones. Este documento de SSM es más útil si no se necesita un control estricto sobre las actualizaciones de Windows y no es necesario recopilar información de conformidad.
**Documentos de SSM heredados a los que sustituye: **
+ *Ninguno*
### `AWS-InstallWindowsUpdates`
Instala actualizaciones en un nodo administrado de Windows Server. Disponible en todas las Regiones de AWS.
Este documento de SSM proporciona la funcionalidad básica de aplicación de revisiones para los casos en los que se desea instalar una actualización específica (mediante el parámetro `Include Kbs`), o se desea instalar revisiones con clasificaciones o categorías específicas, pero no se necesita información de conformidad de revisiones.
**Documentos de SSM heredados a los que sustituye:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Los tres documentos heredados realizan diferentes funciones, pero se pueden alcanzar los mismos resultados mediante una configuración de parámetros distinta con el documento de SSM más reciente `AWS-InstallWindowsUpdates`. Esta configuración de parámetros se describe en [Documentos de SSM heredados para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-legacy).
### `AWS-RunPatchBaseline`
Instala revisiones en los nodos administrados o los examina para determinar si falta alguna revisión que sea aplicable. Disponible en todas las Regiones de AWS.
`AWS-RunPatchBaseline` le permite controlar las aprobaciones de revisiones mediante la línea de base de revisiones que se especifica como “predeterminada” para un tipo de sistema operativo. Genera informes de conformidad de revisiones que se pueden visualizar con las herramientas de conformidad de Systems Manager. Estas herramientas proporcionan información sobre el estado de conformidad de revisiones de los nodos administrados como, por ejemplo, en qué nodos faltan revisiones y cuáles son esas revisiones. Cuando utiliza `AWS-RunPatchBaseline`, la información relativa a la conformidad de revisiones se registra mediante el comando `PutInventory` de la API. En el caso de los sistemas operativos Linux, se proporciona información sobre la conformidad para las revisiones tanto del repositorio de origen predeterminado configurado en un nodo administrado como de los repositorios de origen alternativos que se especifiquen en una base de referencia de revisiones personalizada. Para obtener más información sobre los repositorios de origen alternativos, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md). Para obtener más información acerca de las herramientas de conformidad de Systems Manager, consulte [Conformidad de AWS Systems Manager](systems-manager-compliance.md).
**Documentos heredados a los que sustituye:**
+ `AWS-ApplyPatchBaseline`
El documento heredado `AWS-ApplyPatchBaseline` se aplica únicamente en el caso de los nodos administrados de Windows Server y no ofrece soporte para la aplicación de revisiones. El nuevo documento `AWS-RunPatchBaseline` ofrece la misma compatibilidad para sistemas Windows y Linux. Es necesario disponer de la versión 2.0.834.0 del SSM Agent u otra posterior para poder utilizar el documento `AWS-RunPatchBaseline`.
Para obtener más información acerca del documento `AWS-RunPatchBaseline` de SSM, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
### `AWS-RunPatchBaselineAssociation`
Instala revisiones en las instancias o las examina para determinar si falta alguna revisión que sea aplicable. Disponible en todas las comerciales Regiones de AWS.
`AWS-RunPatchBaselineAssociation` difiere de `AWS-RunPatchBaseline` en algunos aspectos relevantes:
+ `AWS-RunPatchBaselineAssociation` está diseñado para que se utilice principalmente con asociaciones de State Manager creadas con Quick Setup, una herramienta de AWS Systems Manager. Especialmente cuando se utiliza el tipo de configuración Quick Setup de administración de host, si elige la opción **escanear las instancias para detectar las revisiones que faltan cada día**, el sistema utiliza `AWS-RunPatchBaselineAssociation` para efectuar la operación.
Sin embargo, en la mayoría de los casos, a la hora de configurar sus propias operaciones de aplicación de revisiones, debe elegir [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) o [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) en lugar de `AWS-RunPatchBaselineAssociation`.
Para obtener más información, consulte los temas siguientes:
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` admite el uso de etiquetas que permiten identificar cuál es la línea de base de revisiones que se utilizará con un conjunto de destinos cuando se ejecute.
+ Para las operaciones de aplicación de revisiones que utilizan `AWS-RunPatchBaselineAssociation`, los datos de conformidad de las revisiones se compilan en función de una asociación específica de State Manager. Los datos de conformidad de revisiones que se recopilan cuando se ejecuta `AWS-RunPatchBaselineAssociation` se registran mediante el comando `PutComplianceItems` de la API en lugar del comando `PutInventory`. Por consiguiente, se evita que se sobrescriban los datos de conformidad que no se encuentran relacionados con esta asociación en particular.
En el caso de los sistemas operativos Linux, se proporciona información sobre la conformidad para las revisiones tanto del repositorio de origen predeterminado configurado en una instancia como de los repositorios de origen alternativos que se especifiquen en una línea de base de revisiones personalizada. Para obtener más información sobre los repositorios de origen alternativos, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md). Para obtener más información acerca de las herramientas de conformidad de Systems Manager, consulte [Conformidad de AWS Systems Manager](systems-manager-compliance.md).
**Documentos heredados a los que sustituye:**
+ **Ninguno**
Para obtener más información acerca del documento `AWS-RunPatchBaselineAssociation` de SSM, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).
### `AWS-RunPatchBaselineWithHooks`
Instala revisiones en los nodos administrados o analiza los nodos para determinar si falta alguna revisión aplicable, con enlaces opcionales que se pueden utilizar para ejecutar documentos de SSM en tres puntos durante el ciclo de aplicación de revisiones. Disponible en todas las comerciales Regiones de AWS. No se admite en macOS.
`AWS-RunPatchBaselineWithHooks` se diferencia de `AWS-RunPatchBaseline` en la operación `Install`.
`AWS-RunPatchBaselineWithHooks` admite enlaces de ciclo de vida que se ejecutan en puntos designados durante la aplicación de revisiones en los nodos administrados. Dado que las instalaciones de revisiones en ocasiones requieren que se reinicien los nodos administrados, la operación de aplicación de revisiones se divide en dos eventos, lo que supone un total de tres enlaces que permiten una funcionalidad personalizada. El primer enlace tiene lugar antes de la operación `Install with NoReboot`. El segundo enlace tiene lugar después de la operación `Install with NoReboot`. El tercer enlace está disponible después del reinicio del nodo.
**Documentos heredados a los que sustituye:**
+ **Ninguno**
Para obtener más información acerca del documento `AWS-RunPatchBaselineWithHooks` de SSM, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
## Documentos de SSM heredados para la aplicación de revisiones a nodos administrados
Los cuatro documentos de SSM a continuación aún están disponibles en algunas Regiones de AWS. Sin embargo, ya no están actualizados y puede que ya no cuenten con más soporte en el futuro, por lo que recomendamos que no se utilicen. En su lugar, utilice los documentos se describe en [Documentos de SSM recomendados para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-recommended).
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
Admite solo los nodos administrados de Windows Server, pero no incluye la compatibilidad con el uso de revisiones en aplicaciones que se encuentra en su sustitución, `AWS-RunPatchBaseline`. No está disponible en Regiones de AWS lanzadas después de agosto de 2017.
**nota**
El sustituto de este documento de SSM, `AWS-RunPatchBaseline`, requiere la versión 2.0.834.0 del SSM Agent u otra posterior. Puede utilizar el documento `AWS-UpdateSSMAgent` para actualizar los nodos administrados a la versión más reciente del agente.
### `AWS-FindWindowsUpdates`
Ha sido sustituido por `AWS-InstallWindowsUpdates`, que puede realizar las mismas acciones. No está disponible en Regiones de AWS lanzadas después de abril de 2017.
Para lograr el mismo resultado que obtendría a partir de este documento de SSM heredado, utilice la siguiente configuración de parámetros con el documento de sustitución recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
Ha sido sustituido por `AWS-InstallWindowsUpdates`, que puede realizar las mismas acciones. No está disponible en ninguna de las Regiones de AWS lanzadas después de abril de 2017.
Para lograr el mismo resultado que obtendría a partir de este documento de SSM heredado, utilice la siguiente configuración de parámetros con el documento de sustitución recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
Ha sido sustituido por `AWS-InstallWindowsUpdates`, que puede realizar las mismas acciones. No está disponible en ninguna de las Regiones de AWS lanzadas después de abril de 2017.
Para lograr el mismo resultado que obtendría a partir de este documento de SSM heredado, utilice la siguiente configuración de parámetros con el documento de sustitución recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *lista de artículos de KB separada por comas*
## Limitaciones conocidas de los documentos de SSM para la aplicación de revisiones a nodos administrados
### Interrupciones de reinicio externo
Si el sistema del nodo inicia un reinicio durante la instalación de una revisión (por ejemplo, para aplicar actualizaciones al firmware o a características como SecureBoot), la ejecución del documento de revisión puede interrumpirse y marcarse como fallida aunque las revisiones se hayan instalado de manera correcta. Esto se debe a que el agente de SSM no puede conservar y reanudar el estado de ejecución del documento tras reinicios externos.
Para comprobar el estado de instalación de la revisión tras una ejecución fallida, ejecute una operación de `Scan` de aplicación de revisiones y, a continuación, compruebe los datos de cumplimiento del parche en Patch Manager para evaluar el estado de cumplimiento actual.
# Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`
AWS Systems Manager es compatible con `AWS-RunPatchBaseline`, un documento de Systems Manager (documento de SSM) para Patch Manager, una herramienta de AWS Systems Manager. Este documento de SSM realiza operaciones de aplicación de revisiones en los nodos administrados para actualizaciones relacionadas con la seguridad y de otros tipos. Cuando el documento se ejecuta, utiliza la línea de base de revisiones especificada como “predeterminada” para un tipo de sistema operativo en caso de que no se hubiera indicado ningún grupo de revisiones. En caso contrario, utiliza la línea de base de revisiones que se asocia con el grupo de revisiones. Para obtener información acerca de los grupos de revisiones, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
Puede utilizar el documento `AWS-RunPatchBaseline` para aplicar revisiones a los sistemas operativos y a las aplicaciones. (En Windows Server, la compatibilidad con las aplicaciones se limita a las actualizaciones de las aplicaciones publicadas por Microsoft).
Este documento es compatible con los nodos administrados de Linux, macOS y Windows Server. El documento se encargará de realizar las acciones adecuadas para cada plataforma.
**nota**
Patch Manager Además, es compatible con el documento de SSM heredado `AWS-ApplyPatchBaseline`. Sin embargo, este documento solo es compatible con la aplicación de revisiones en nodos administrados de Windows. Se recomienda que utilice `AWS-RunPatchBaseline` en su lugar porque es compatible con la aplicación de revisiones en los tipos de nodos administrados de Linux, macOS y Windows Server. Es necesario disponer de la versión 2.0.834.0 del SSM Agent u otra posterior para poder utilizar el documento `AWS-RunPatchBaseline`.
------
#### [ Windows Server ]
En nodos administrados de Windows Server, el documento `AWS-RunPatchBaseline` descarga e invoca un módulo de PowerShell, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones contiene una lista de revisiones aprobadas que se compila al consultar dicha línea de base de revisiones en un servidor de Windows Server Update Services (WSUS). Esta lista se transfiere a la API de Windows Update, que controla la descarga y la instalación de las revisiones aprobadas, según proceda.
------
#### [ Linux ]
En nodos administrados de Linux, el documento `AWS-RunPatchBaseline` invoca un módulo de Python, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones utiliza las reglas definidas y las listas de revisiones aprobadas y bloqueadas con el fin de impulsar el administrador de paquetes adecuado para cada tipo de nodo:
+ Los nodos administrados de Amazon Linux 2, Oracle Linux y RHEL 7 utilizan YUM. Para las operaciones de YUM, Patch Manager requiere `Python 2.6` o una versión posterior compatible (2.6 a 3.12). Amazon Linux 2023 usa DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12).
+ RHELLos nodos administrados de 8 utilizan DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12). (Ninguna de las dos versiones viene instalada en RHEL 8 de forma predeterminada. Para ello, deberá instalar una u otra versión manualmente).
+ Las instancias de Debian Server y Ubuntu Server usan APT. Para las operaciones de APT, Patch Manager requiere una versión compatible de `Python 3` (3.0 a 3.12).
------
#### [ macOS ]
En nodos administrados de macOS, el documento `AWS-RunPatchBaseline` invoca un módulo de Python, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. A continuación, un subproceso de Python invoca la AWS Command Line Interface (AWS CLI) en el nodo a fin de recuperar la información de instalación y actualización de los administradores de paquetes especificados e impulsar el administrador de paquetes adecuado para cada paquete de actualización.
------
Cada instantánea se corresponde con una Cuenta de AWS, un grupo de revisiones, un sistema operativo y un ID de instantánea. La instantánea se entrega a través de una URL prefirmada de Amazon Simple Storage Service (Amazon S3), que se vence transcurridas las 24 horas desde la creación de la instantánea. Sin embargo, si desea aplicar el mismo contenido de la instantánea a otros nodos administrados una vez que la URL se haya vencido, puede generar una nueva dirección de Amazon S3 prefirmada hasta tres días después de la creación de la instantánea. Para ello, utilice el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Cuando se han instalado todas las actualizaciones aprobadas y aplicables, y se han realizado los reinicios necesarios, se genera la información de conformidad de revisiones en un nodo administrado y se notifica a Patch Manager.
**nota**
Si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia después de que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
Para obtener información sobre cómo ver los datos de conformidad de revisiones, consulte [Acerca de la conformidad de parches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaseline`Parámetros
`AWS-RunPatchBaseline` admite seis parámetros. El parámetro `Operation` es obligatorio. Los parámetros `InstallOverrideList`, `BaselineOverride` y `RebootOption` son opcionales. `Snapshot-ID` es opcional desde el punto de vista técnico, pero se recomienda proporcionar un valor personalizado al ejecutar `AWS-RunPatchBaseline` fuera de un periodo de mantenimiento. Patch Manager puede suministrar el valor automáticamente cuando el documento se ejecuta como parte de una operación de un periodo de mantenimiento.
**Topics**
+ [Nombre del parámetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nombre del parámetro: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Nombre del parámetro: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Nombre del parámetro: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Nombre del parámetro: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Nombre del parámetro: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### Nombre del parámetro: `Operation`
**Usage**: requerido.
**Opciones**: `Scan` \$1 `Install`.
Examen
Cuando elige la opción `Scan`, `AWS-RunPatchBaseline` determina el estado de conformidad de las revisiones del nodo administrado y notifica esta información a Patch Manager. `Scan` no solicita que se instalen actualizaciones ni que se reinicien los nodos administrados. En lugar de ello, la operación identifica las actualizaciones aprobadas que faltan y que son aplicables al nodo.
Instalación
Al elegir la opción `Install`, `AWS-RunPatchBaseline` intenta instalar las actualizaciones aprobadas y aplicables que faltan en el nodo administrado. La información de conformidad de revisiones generada como parte de una operación `Install` no muestra las actualizaciones que faltan, pero podría notificar aquellas que presentan un estado de error si la instalación de la actualización no se ha podido realizar por cualquier motivo. Cuando una actualización se instala en un nodo administrado, este se reinicia para garantizar que la actualización esté instalada y activa. (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`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
Si se instala una revisión especificada por las reglas de la línea de base *antes* de que Patch Manager actualice el nodo administrado, es posible que el sistema no se reinicie como es debido. Esto puede ocurrir cuando un usuario instala manualmente una revisión o cuando la instala automáticamente otro programa, como el `unattended-upgrades` paquete de Ubuntu Server.
### Nombre del parámetro: `AssociationId`
**Usage**: opcional.
`AssociationId` es el ID de una asociación existente en State Manager, una herramienta de AWS Systems Manager. Patch Manager lo utiliza para agregar datos de conformidad a la asociación especificada. Esta asociación está relacionada con una operación de aplicación de revisiones que está [configurada en una política de revisiones en Quick Setup](quick-setup-patch-manager.md).
**nota**
Con el `AWS-RunPatchBaseline`, si se proporciona un valor `AssociationId` junto con una anulación de la línea de base de la política de revisiones, la aplicación de revisiones se realiza como una operación `PatchPolicy` y el valor `ExecutionType` informado en `AWS:ComplianceItem` también es `PatchPolicy`. Si no se proporciona un valor `AssociationId`, la aplicación de revisiones se realiza como una operación `Command` y el informe del valor `ExecutionType` en el `AWS:ComplianceItem` enviado también es `Command`.
Si aún no dispone de una asociación que desee utilizar, puede crear una mediante la ejecución del comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html).
### Nombre del parámetro: `Snapshot ID`
**Usage**: opcional.
`Snapshot ID` es un ID exclusivo (GUID) que utiliza Patch Manager para garantizar que un conjunto de nodos administrados en los que se aplican revisiones en una sola operación tenga el mismo conjunto de revisiones aprobadas. Aunque el parámetro se define como opcional, nuestra mejor práctica recomendada depende de si se ejecuta o no `AWS-RunPatchBaseline` en un periodo de mantenimiento, tal como se describe en la siguiente tabla.
**`AWS-RunPatchBaseline`Prácticas recomendadas de**
| Mode | Práctica recomendada | Details |
| --- | --- | --- |
| Ejecución de AWS-RunPatchBaseline dentro de un periodo de mantenimiento | No proporcione un ID de instantánea, sino que Patch Manager lo hará en su lugar. | Si utiliza un periodo de mantenimiento para ejecutar `AWS-RunPatchBaseline`, no debe proporcionar su propio ID de instantánea generado. En este caso, Systems Manager proporciona un valor GUID en función del ID de ejecución del periodo de mantenimiento. De este modo, se garantiza que se utilice un ID correcto para todas las invocaciones de `AWS-RunPatchBaseline` en dicho periodo de mantenimiento. Si especifica un valor en este caso, tenga en cuenta que la instantánea de la línea de base de revisiones no podría mantenerse durante más de tres días. Después de eso, se generará una nueva instantánea, aunque especifique el mismo ID después de que expire la instantánea. |
| Ejecución de AWS-RunPatchBaseline fuera de un periodo de mantenimiento | Genere y especifique un valor GUID personalizado para el ID de instantánea.¹ | Cuando no esté utilizando un periodo de mantenimiento para ejecutar `AWS-RunPatchBaseline`, se recomienda generar y especificar un ID de instantánea exclusivo por cada línea de base de revisiones, especialmente si ejecuta el documento `AWS-RunPatchBaseline` en varios nodos administrados durante la misma operación. Si no especifica un ID en este caso, Systems Manager genera otro ID de instantánea para cada nodo administrado al que se envía el comando. Esto podría generar diferentes conjuntos de revisiones que se especifican entre los nodos administrados. Por ejemplo, supongamos que se ejecuta el documento `AWS-RunPatchBaseline` directamente a través de Run Command, una herramienta de AWS Systems Manager, y selecciona como destino un grupo de 50 nodos administrados. Al especificar un ID de instantánea personalizado, se genera una sola instantánea de la línea de base que se utiliza para evaluar y aplicar revisiones en todos los nodos, lo que garantiza que tengan un estado coherente. |
| ¹ Puede utilizar cualquier herramienta que genere un GUID con el fin de crear un valor para el parámetro de ID de la instantánea. Por ejemplo, en PowerShell, puede utilizar el cmdlet `New-Guid` para generar un GUID con el formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`. |
### Nombre del parámetro: `InstallOverrideList`
**Usage**: opcional.
Mediante `InstallOverrideList`, se puede especificar una URL de https o una URL de tipo ruta de Amazon S3 a una lista de revisiones que deben instalarse. Esta lista de instalación de revisiones, que mantiene en formato YAML, invalida las revisiones especificadas por la línea de base de revisiones predeterminada actual. De este modo, se le proporcionará un control pormenorizado sobre qué revisiones se instalan en los nodos administrados.
**importante**
El nombre de archivo `InstallOverrideList` no puede contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
El comportamiento de la operación de revisión cuando se utiliza el parámetro `InstallOverrideList` difiere entre Linux y los nodos administrados por macOS y los nodos administrados por Windows Server. En Linux y macOS, Patch Manager intenta aplicar los parches incluidos en la lista de parches de `InstallOverrideList` que estén presentes en cualquier repositorio habilitado en el nodo, independientemente de que los parches coincidan o no con las reglas de la línea de base de revisiones. Sin embargo, en los nodos Windows Server, los parches de la lista de parches `InstallOverrideList` se aplican *solo* si también cumplen con las reglas de la línea de base de revisiones.
Tenga en cuenta que los informes de conformidad reflejan los estados de revisiones de acuerdo con lo que se especifica en la línea de base de revisiones, no lo que especifique en una lista de revisiones `InstallOverrideList`. En otras palabras, las operaciones de análisis omiten el parámetro `InstallOverrideList`. De este modo, se garantiza que los informes de conformidad reflejen de forma coherente los estados de revisiones de acuerdo con la política, en lugar de lo que se ha aprobado una operación específica para la aplicación de revisiones.
**nota**
Cuando aplique revisiones a un nodo que solo usa IPv6, asegúrese de que se pueda acceder a la URL proporcionada desde el nodo. Si la opción de configuración `UseDualStackEndpoint` de SSM Agent está establecida en `true`, se utiliza un cliente S3 de pila doble cuando se proporciona una URL de S3. Consulte [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obtener más información sobre cómo configurar el agente para usar la pila doble.
Para obtener una descripción de cómo puede utilizar el parámetro `InstallOverrideList` para aplicar diferentes tipos de revisiones a un grupo de destino en diferentes programaciones de ventanas de mantenimiento al tiempo que utiliza una única línea de base de revisiones, consulte [Ejemplo de escenario para utilizar el parámetro InstallOverrideList en `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).
**Formatos de URL válidos**
**nota**
Si su archivo se encuentra almacenado en un bucket de acceso público, puede especificar un formato de URL de https o una URL de tipo ruta de Amazon S3. Si su archivo se encuentra almacenado en un bucket privado, debe especificar una URL de tipo ruta de Amazon S3.
+ **Formato de URL https**:
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **URL de tipo ruta de Amazon S**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formatos de contenido YAML válidos**
Los formatos que utiliza para especificar revisiones en su lista dependen del sistema operativo del nodo administrado. El formato general, sin embargo, es el siguiente:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Aunque puede proporcionar campos adicionales en su archivo YAML, estos se pasan por alto durante las operaciones de revisiones.
Además, le recomendamos que verifique que el formato de su archivo YAML es válido antes de añadir o actualizar la lista de su bucket de S3. Para obtener más información acerca del formato YAML, consulte [yaml.org](http://www.yaml.org). Para consultar las opciones de herramientas de validación, realice una búsqueda web de "validadores de formato yaml".
------
#### [ Linux ]
**id**
El campo **id** es obligatorio. Utilícelo para especificar revisiones mediante el nombre del paquete y la arquitectura. Por ejemplo: `'dhclient.x86_64'`. Puede utilizar comodines en id para indicar varios paquetes. Por ejemplo: `'dhcp*'` y `'dhcp*1.*'`.
**Título**
El campo **title (título)** es opcional, pero en sistemas Linux ofrece capacidades de filtrado adicionales. Si utiliza **title (título)**, debería contener información de la versión del paquete en uno de los siguientes formatos:
YUM/SUSE Linux Enterprise Server (SLES):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Para los títulos de las revisiones de Linux, puede utilizar uno o varios comodines en cualquier posición para ampliar el número de paquetes coincidentes. Por ejemplo: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Por ejemplo:
+ la versión del paquete apt 1.2.25 actualmente está instalada en el nodo administrado, pero la versión 1.2.27 ya está disponible.
+ Puede añadir la versión apt.amd64 1.2.27 a la lista de revisiones. Depende de la versión apt utils.amd64 1.2.27, pero la versión apt-utils.amd64 1.2.25 se especifica en la lista.
En este caso, la versión apt 1.2.27 se bloqueará a partir de la instalación y se registrará como "Failed-NonCompliant".
------
#### [ Windows Server ]
**id**
El campo **id** es obligatorio. Úselo para especificar las revisiones con los ID de la Base de conocimientos de Microsoft (por ejemplo, KB2736693) y del boletín de seguridad de Microsoft (por ejemplo, MS17-023).
Cualquier otro campo que desee proporcionar en una lista de revisiones para Windows es opcional y solo para fines informativos propios. Puede utilizar campos adicionales como, por ejemplo, **title (título)**, **classification (clasificación)**, **severity (gravedad)** o cualquier otro para proporcionar información más detallada sobre las revisiones especificados.
------
#### [ macOS ]
**id**
El campo **id** es obligatorio. Se puede proporcionar el valor del campo **id** mediante un formato `{package-name}.{package-version}` o un formato \$1package\$1name\$1.
------
**Listas de revisiones de ejemplo**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nombre del parámetro: `RebootOption`
**Usage**: opcional.
**Opciones**: `RebootIfNeeded` \$1 `NoReboot`
**Valor predeterminado**: `RebootIfNeeded`
**aviso**
La opción predeterminada es `RebootIfNeeded`. Asegúrese de seleccionar la opción correcta para su caso de uso. Por ejemplo, si los nodos administrados deben reiniciarse inmediatamente para completar un proceso de configuración, elija `RebootIfNeeded`. O bien, si necesita mantener la disponibilidad de los nodos administrados hasta una hora de reinicio programada, elija `NoReboot`.
**importante**
No recomendamos el uso de Patch Manager para revisar las instancias de clústeres en Amazon EMR (antes denominado Amazon Elastic MapReduce). En concreto, no seleccione la opción `RebootIfNeeded` para el parámetro `RebootOption`. (Esta opción está disponible en los documentos de SSM Command para implementar revisiones `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, y `AWS-RunPatchBaselineWithHooks`).
Los comandos subyacentes para implementar revisiones mediante el uso de Patch Manager y los comandos `yum` y `dnf`. Por lo tanto, las operaciones generan incompatibilidades debido a la forma en que se instalan los paquetes. Para obtener información sobre los métodos preferidos para actualizar el software en los clústeres de Amazon EMR, consulte [Uso de la AMI predeterminada para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) en la *Guía de administración de Amazon EMR*.
RebootIfNeeded
Cuando se elige la opción `RebootIfNeeded`, el nodo administrado se reinicia en cualquiera de los siguientes casos:
+ Patch Manager instaló una o más revisiones.
Patch Manager no evalúa si la revisión *requiere* llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.
+ Patch Manager detecta uno o más revisiones con un estado de `INSTALLED_PENDING_REBOOT` durante la operación `Install`.
El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación `Install` o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
El reinicio de los nodos administrados en estos dos casos garantiza que los paquetes actualizados se eliminen de la memoria y mantiene un comportamiento de aplicación de revisiones y reinicio consistente en todos los sistemas operativos.
NoReboot
Cuando elige la opción `NoReboot`, Patch Manager no reinicia un nodo administrado aunque haya instalado revisiones durante la operación `Install`. Esta opción es útil si sabe que los nodos administrados no requieren reinicio después de aplicar las revisiones, o si dispone de aplicaciones o procesos que se ejecutan en un nodo que no deberían verse interrumpidos como consecuencia del reinicio de una operación de aplicación de revisiones. También es útil cuando se desea tener más control sobre el tiempo de los reinicios del nodo administrado, por ejemplo, mediante un periodo de mantenimiento.
Si elige la opción `NoReboot` y se ha instalado una revisión, se asigna a la revisión un estado de `InstalledPendingReboot`. Sin embargo, el nodo administrado en sí mismo está marcado como `Non-Compliant`. Una vez que se produce un reinicio y se ejecuta una operación `Scan`, el estado del nodo administrado se actualiza a `Compliant`.
La opción `NoReboot` solo impide los reinicios a nivel del sistema operativo. Los reinicios a nivel de servicio aún pueden producirse como parte del proceso de aplicación de revisiones. Por ejemplo, cuando se actualiza Docker, los servicios dependientes, como Amazon Elastic Container Service, pueden reiniciarse automáticamente incluso con `NoReboot` habilitado. Si tiene servicios críticos que no deben interrumpirse, considere tomar medidas adicionales, como eliminar temporalmente las instancias del servicio o programar la aplicación de revisiones durante los periodos de mantenimiento.
**Archivo de seguimiento de instalación de revisiones**: para realizar un seguimiento de la instalación de revisiones, especialmente las instaladas desde el último reinicio del sistema, Systems Manager mantiene un archivo en el nodo administrado.
**importante**
No elimine ni modifique el archivo de seguimiento. Si este archivo se elimina o está dañado, el informe de conformidad de revisiones para el nodo administrado es inexacto. Si esto sucede, reinicie el nodo y ejecute una operación de análisis de revisiones para restaurar el archivo.
Este archivo de seguimiento se almacena en las siguientes ubicaciones de los nodos administrados:
+ Sistemas operativos Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operativo :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nombre del parámetro: `BaselineOverride`
**Usage**: opcional.
Puede definir las preferencias de aplicación de revisiones en tiempo de ejecución mediante el parámetro `BaselineOverride`. Esta anulación de la base de referencia se mantiene como un objeto JSON en un bucket de S3. Garantiza que las operaciones de aplicación de revisiones utilicen las bases de referencia proporcionadas que concuerdan con el sistema operativo del host en lugar de aplicar las reglas de la línea de base de revisiones predeterminada
**importante**
El nombre de archivo `BaselineOverride` no puede contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
Para obtener más información acerca de cómo utilizar el parámetro `BaselineOverride`, consulte [Uso del parámetro BaselineOverride](patch-manager-baselineoverride-parameter.md).
### Nombre del parámetro: `StepTimeoutSeconds`
**Usage**: requerido.
El tiempo en segundos, entre 1 y 36 000 segundos (10 horas), para que un comando se complete antes de considerar que se ha producido un error.
# Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`
Al igual que el documento `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` realiza operaciones de aplicación de revisiones en las instancias para actualizaciones relacionadas con la seguridad y de otros tipos. Además, puede utilizar el documento `AWS-RunPatchBaselineAssociation` para aplicar revisiones a los sistemas operativos y a las aplicaciones. (En Windows Server, la compatibilidad con las aplicaciones se limita a las actualizaciones de las aplicaciones publicadas por Microsoft).
Este documento admite instancias de Amazon Elastic Compute Cloud (Amazon EC2) para Linux, macOS y Windows Server. No admite nodos que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). El documento se encargará de realizar las acciones adecuadas para cada plataforma, para lo cual invocará un módulo de Python en las instancias de Linux y macOS, así como un módulo de PowerShell en las instancias de Windows.
Sin embargo, `AWS-RunPatchBaselineAssociation` se diferencia de `AWS-RunPatchBaseline` en los siguientes aspectos:
+ `AWS-RunPatchBaselineAssociation` está diseñado para que se utilice principalmente con asociaciones de State Manager creadas con [Quick Setup](systems-manager-quick-setup.md), una herramienta de AWS Systems Manager. Especialmente cuando se utiliza el tipo de configuración Quick Setup de administración de host, si elige la opción **escanear las instancias para detectar las revisiones que faltan cada día**, el sistema utiliza `AWS-RunPatchBaselineAssociation` para efectuar la operación.
Sin embargo, en la mayoría de los casos, a la hora de configurar sus propias operaciones de aplicación de revisiones, debe elegir [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) o [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) en lugar de `AWS-RunPatchBaselineAssociation`.
+ Cuando se utiliza el documento `AWS-RunPatchBaselineAssociation`, se puede especificar un par de claves de etiqueta en el campo correspondiente al parámetro `BaselineTags` del documento. Si una línea de base de revisiones personalizada en su Cuenta de AWS comparte estas etiquetas, Patch Manager, una herramienta de AWS Systems Manager, utiliza esa línea de base etiquetada cuando se ejecuta en las instancias de destino en lugar de la línea de base de revisiones “predeterminada” que actualmente se encuentra especificada para el tipo de sistema operativo.
**nota**
Si elige utilizar `AWS-RunPatchBaselineAssociation` en las operaciones de aplicación de revisiones distintas de las configuradas mediante Quick Setup, y desea utilizar el parámetro opcional `BaselineTags`, es necesario que proporcione algunos permisos adicionales al [perfil de instancias](setup-instance-permissions.md) para las instancias de Amazon Elastic Compute Cloud (Amazon EC2). Para obtener más información, consulte [Nombre del parámetro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).
Los dos siguientes formatos son válidos para su parámetro `BaselineTags`:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**importante**
Los valores y las claves de las etiquetas no pueden contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
+ Los datos de conformidad de revisiones que se recopilan cuando se ejecuta `AWS-RunPatchBaselineAssociation` se registran mediante el comando `PutComplianceItems` de la API en lugar del comando `PutInventory`, que utiliza `AWS-RunPatchBaseline`. Esta diferencia implica que la información de conformidad de revisiones se almacena y notifica en función de una *asociación* específica. Los datos de conformidad de revisiones generados fuera de esta asociación no se sobrescriben.
+ La información de conformidad con la revisión notificada con posterioridad a la ejecución de `AWS-RunPatchBaselineAssociation` indica si una instancia está en conformidad o no. No se incluyen los detalles a nivel de revisión, como se demuestra con la salida del siguiente comando de la AWS Command Line Interface (AWS CLI). El comando filtra en `Association` como el tipo de conformidad:
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
El sistema devuelve información similar a la siguiente.
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
Si se ha especificado un valor de par de claves de etiqueta como parámetro para el documento `AWS-RunPatchBaselineAssociation`, Patch Manager busca una línea de base de revisiones personalizada que concuerde con el tipo de sistema operativo y que se haya etiquetado con ese mismo par de claves de etiquetas. Esta búsqueda no se limita a la línea de base de revisiones predeterminada que se haya especificado ni a la base de referencia asignada a un grupo de revisiones. Si no se encuentra ninguna base de referencia con las etiquetas especificadas, Patch Manager busca a continuación un grupo de revisiones, siempre que se haya especificado uno en el comando que ejecuta `AWS-RunPatchBaselineAssociation`. Si no hay ningún grupo de revisiones que concuerde, Patch Manager vuelve a la línea de base de revisiones predeterminada actual para la cuenta del sistema operativo.
Si se encuentra más de una línea de base de revisiones con las etiquetas especificadas en el documento `AWS-RunPatchBaselineAssociation`, Patch Manager devuelve un mensaje de error donde se indica que solo es posible etiquetar una línea de base de revisiones con ese par de valor de clave para proceder con la operación.
**nota**
En los nodos de Linux, se utiliza el administrador de paquetes adecuado para cada tipo de nodo a fin de instalar los paquetes:
Las instancias de Amazon Linux 2, Oracle Linux y RHEL usan YUM. Para las operaciones de YUM, Patch Manager requiere `Python 2.6` o una versión posterior compatible (2.6 a 3.12). Amazon Linux 2023 usa DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12)
Las instancias de Debian Server y Ubuntu Server usan APT. Para las operaciones de APT, Patch Manager requiere una versión compatible de `Python 3` (3.0 a 3.12).
Una vez que se haya completado un análisis, o bien después de que se hayan instalado todas las actualizaciones aprobadas y aplicables, y se hayan realizado los reinicios necesarios, se genera la información de conformidad de revisiones en una instancia y se notifica al servicio de conformidad de revisiones.
**nota**
Si el parámetro `RebootOption` se establece en `NoReboot` en el documento `AWS-RunPatchBaselineAssociation`, la instancia no se reinicia después de que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).
Para obtener información sobre cómo ver los datos de conformidad de revisiones, consulte [Acerca de la conformidad de parches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineAssociation`Parámetros
`AWS-RunPatchBaselineAssociation` admite cinco parámetros. Los parámetros `Operation` y `AssociationId` son obligatorios. Los parámetros `InstallOverrideList`, `RebootOption` y `BaselineTags` son opcionales.
**Topics**
+ [Nombre del parámetro: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Nombre del parámetro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Nombre del parámetro: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Nombre del parámetro: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### Nombre del parámetro: `Operation`
**Usage**: requerido.
**Opciones**: `Scan` \$1 `Install`.
Examen
Cuando elija la opción `Scan`, `AWS-RunPatchBaselineAssociation` determina el estado de conformidad de las revisiones de la instancia y notifica esta información a Patch Manager. `Scan` no solicita que se instalen actualizaciones ni que se reinicien las instancias. En lugar de ello, la operación identifica las actualizaciones aprobadas que faltan y que son aplicables a la instancia.
Instalación
Al elegir la opción `Install`, `AWS-RunPatchBaselineAssociation` intenta instalar las actualizaciones aprobadas y aplicables que faltan en la instancia. La información de conformidad de revisiones generada como parte de una operación `Install` no muestra las actualizaciones que faltan, pero podría notificar aquellas que presentan un estado de error si la instalación de la actualización no se ha podido realizar por cualquier motivo. Cuando una actualización se instala en una instancia, esta se reinicia para garantizar que la actualización esté instalada y activa. (Excepción: si el parámetro `RebootOption` se establece en `NoReboot` en el documento `AWS-RunPatchBaselineAssociation`, la instancia no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).)
Si se instala una revisión especificado por las reglas de la base de referencia *antes* de que Patch Manager actualice la instancia, es posible que el sistema no se reinicie como es debido. Esto puede ocurrir cuando un usuario instala manualmente una revisión o cuando lo instala automáticamente otro programa, como el `unattended-upgrades` paquete de Ubuntu Server.
### Nombre del parámetro: `BaselineTags`
**Usage**: opcional.
`BaselineTags` es un par de valor de clave de etiqueta único que usted elige y asigna a una línea de base de revisiones personalizada particular. Puede especificar uno o más valores para este parámetro. Los dos formatos que se indican a continuación son válidos:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**importante**
Los valores y las claves de las etiquetas no pueden contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
Patch Manager utiliza el valor `BaselineTags` para garantizar que un conjunto de instancias en las que se aplican revisiones en una sola operación tenga el mismo conjunto de revisiones aprobados. Cuando se ejecuta la operación de aplicación de revisiones, Patch Manager comprueba si una línea de base de revisiones para el tipo de sistema operativo está etiquetada con el mismo par de valor de clave que se especifica para `BaselineTags`. Si hay una concordancia, se utiliza esta línea de base de revisiones personalizada. Si no hay ninguna concordancia, se identifica una línea de base de revisiones en función de cualquier grupo de revisiones especificado para la operación de aplicación de revisiones. En caso de que no haya ninguno, se utiliza la línea de base de revisiones predefinida administrada por AWS para ese sistema operativo.
**Requisitos de permisos adicionales**
Si elige utilizar `AWS-RunPatchBaselineAssociation` en las operaciones de aplicación de revisiones distintas de las configuradas mediante Quick Setup, y desea utilizar el parámetro opcional `BaselineTags`, es necesario que agregue los siguientes permisos al [perfil de instancias](setup-instance-permissions.md) para las instancias de Amazon Elastic Compute Cloud (Amazon EC2).
**nota**
Quick Setup y `AWS-RunPatchBaselineAssociation` no admiten servidores locales ni máquinas virtuales.
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
Sustituya *patch-baseline-arn* por el nombre de recurso de Amazon (ARN) de la línea de base de revisiones al que desea proporcionar acceso, con el formato `arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`.
### Nombre del parámetro: `AssociationId`
**Usage**: requerido.
`AssociationId` es el ID de una asociación existente en State Manager, una herramienta de AWS Systems Manager. Patch Manager lo utiliza para agregar datos de conformidad a la asociación especificada. Esta asociación está relacionada con una operación de revisión `Scan` habilitada en una configuración de [Administración de host creada en Quick Setup](quick-setup-host-management.md) . Con el envío de los resultados de la aplicación de revisiones como datos de conformidad de la asociación en lugar de datos de conformidad de inventario, la información de conformidad de inventario existente para sus instancias ni otros ID de asociación no se sobrescribe luego de una operación de aplicación de revisiones. Si aún no dispone de una asociación que desee utilizar, puede crear una mediante la ejecución del comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html). Por ejemplo:
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows Server ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### Nombre del parámetro: `InstallOverrideList`
**Usage**: opcional.
Mediante `InstallOverrideList`, se puede especificar una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) para una lista de revisiones que deben instalarse. Esta lista de instalación de revisiones, que mantiene en formato YAML, invalida las revisiones especificados por la línea de base de revisiones predeterminada actual. De este modo, se le proporcionará un control más detallado sobre qué revisiones se instalan en las instancias.
**importante**
El nombre de archivo `InstallOverrideList` no puede contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
El comportamiento de la operación de revisión cuando se utiliza el parámetro `InstallOverrideList` difiere entre Linux y los nodos administrados por macOS y los nodos administrados por Windows Server. En Linux y macOS, Patch Manager intenta aplicar los parches incluidos en la lista de parches de `InstallOverrideList` que estén presentes en cualquier repositorio habilitado en el nodo, independientemente de que los parches coincidan o no con las reglas de la línea de base de revisiones. Sin embargo, en los nodos Windows Server, los parches de la lista de parches `InstallOverrideList` se aplican *solo* si también cumplen con las reglas de la línea de base de revisiones.
Tenga en cuenta que los informes de conformidad reflejan los estados de revisiones de acuerdo con lo que se especifica en la línea de base de revisiones, no lo que especifique en una lista de revisiones `InstallOverrideList`. En otras palabras, las operaciones de análisis omiten el parámetro `InstallOverrideList`. De este modo, se garantiza que los informes de conformidad reflejen de forma coherente los estados de revisiones de acuerdo con la política, en lugar de lo que se ha aprobado una operación específica para la aplicación de revisiones.
**Formatos de URL válidos**
**nota**
Si su archivo se encuentra almacenado en un bucket de acceso público, puede especificar un formato de URL de https o una URL de tipo ruta de Amazon S3. Si su archivo se encuentra almacenado en un bucket privado, debe especificar una URL de tipo ruta de Amazon S3.
+ **Ejemplo de formato de URL https**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Ejemplo de URL de estilo ruta de Amazon S3**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formatos de contenido YAML válidos**
Los formatos que utiliza para especificar revisiones en su lista dependen del sistema operativo de la instancia. El formato general, sin embargo, es el siguiente:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Aunque puede proporcionar campos adicionales en su archivo YAML, estos se pasan por alto durante las operaciones de revisiones.
Además, le recomendamos que verifique que el formato de su archivo YAML es válido antes de añadir o actualizar la lista de su bucket de S3. Para obtener más información acerca del formato YAML, consulte [yaml.org](http://www.yaml.org). Para consultar las opciones de herramientas de validación, realice una búsqueda web de "validadores de formato yaml".
+ Microsoft Windows
**id**
El campo **id** es obligatorio. Úselo para especificar las revisiones con los ID de la Base de conocimientos de Microsoft (por ejemplo, KB2736693) y del boletín de seguridad de Microsoft (por ejemplo, MS17-023).
Cualquier otro campo que desee proporcionar en una lista de revisiones para Windows es opcional y solo para fines informativos propios. Puede utilizar campos adicionales como, por ejemplo, **title (título)**, **classification (clasificación)**, **severity (gravedad)** o cualquier otro para proporcionar información más detallada sobre las revisiones especificados.
+ Linux
**id**
El campo **id** es obligatorio. Utilícelo para especificar revisiones mediante el nombre del paquete y la arquitectura. Por ejemplo: `'dhclient.x86_64'`. Puede utilizar comodines en id para indicar varios paquetes. Por ejemplo: `'dhcp*'` y `'dhcp*1.*'`.
**título**
El campo **title (título)** es opcional, pero en sistemas Linux ofrece capacidades de filtrado adicionales. Si utiliza **title (título)**, debería contener información de la versión del paquete en uno de los siguientes formatos:
YUM/Red Hat Enterprise Linux (RHEL):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Para los títulos de las revisiones de Linux, puede utilizar uno o varios comodines en cualquier posición para ampliar el número de paquetes coincidentes. Por ejemplo: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Por ejemplo:
+ la versión del paquete apt 1.2.25 actualmente está instalada en la instancia, pero la versión 1.2.27 ya está disponible.
+ Puede añadir la versión apt.amd64 1.2.27 a la lista de revisiones. Depende de la versión apt utils.amd64 1.2.27, pero la versión apt-utils.amd64 1.2.25 se especifica en la lista.
En este caso, la versión apt 1.2.27 se bloqueará a partir de la instalación y se registrará como "Failed-NonCompliant".
**Otros campos**
Cualquier otro campo que desee proporcionar en una lista de revisiones para Linux es opcional y solo para fines informativos propios. Puede utilizar campos adicionales como, por ejemplo, **classification (clasificación)**, **severity (gravedad)** o cualquier otro para proporcionar información más detallada sobre las revisiones especificados.
**Listas de revisiones de ejemplo**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nombre del parámetro: `RebootOption`
**Usage**: opcional.
**Opciones**: `RebootIfNeeded` \$1 `NoReboot`
**Valor predeterminado**: `RebootIfNeeded`
**aviso**
La opción predeterminada es `RebootIfNeeded`. Asegúrese de seleccionar la opción correcta para su caso de uso. Por ejemplo, si las instancias deben reiniciarse inmediatamente para completar un proceso de configuración, elija `RebootIfNeeded`. O bien, si necesita mantener la disponibilidad de las instancias hasta una hora de reinicio programada, elija `NoReboot`.
**importante**
La opción `NoReboot` solo impide los reinicios a nivel del sistema operativo. Los reinicios a nivel de servicio aún pueden producirse como parte del proceso de aplicación de revisiones. Por ejemplo, cuando se actualiza Docker, los servicios dependientes, como Amazon Elastic Container Service, pueden reiniciarse automáticamente incluso con `NoReboot` habilitado. Si tiene servicios críticos que no deben interrumpirse, considere tomar medidas adicionales, como eliminar temporalmente las instancias del servicio o programar la aplicación de revisiones durante los periodos de mantenimiento.
**importante**
No recomendamos el uso de Patch Manager para revisar las instancias de clústeres en Amazon EMR (antes denominado Amazon Elastic MapReduce). En concreto, no seleccione la opción `RebootIfNeeded` para el parámetro `RebootOption`. (Esta opción está disponible en los documentos de SSM Command para implementar revisiones `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, y `AWS-RunPatchBaselineWithHooks`).
Los comandos subyacentes para implementar revisiones mediante el uso de Patch Manager y los comandos `yum` y `dnf`. Por lo tanto, las operaciones generan incompatibilidades debido a la forma en que se instalan los paquetes. Para obtener información sobre los métodos preferidos para actualizar el software en los clústeres de Amazon EMR, consulte [Uso de la AMI predeterminada para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) en la *Guía de administración de Amazon EMR*.
RebootIfNeeded
Cuando se elige la opción `RebootIfNeeded`, la instancia se reinicia en cualquiera de los siguientes casos:
+ Patch Manager instaló uno o más revisiones.
Patch Manager no evalúa si la revisión *requiere* llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.
+ Patch Manager detecta uno o más revisiones con un estado de `INSTALLED_PENDING_REBOOT` durante la operación `Install`.
El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación `Install` o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
El reinicio de las instancias en estos dos casos garantiza que los paquetes actualizados se eliminen de la memoria y mantiene un comportamiento de aplicación de revisiones y reinicio consistente en todos los sistemas operativos.
NoReboot
Cuando elige la opción `NoReboot`, Patch Manager no reinicia una instancia aunque haya instalado revisiones durante la operación `Install`. Esta opción es útil si sabe que las instancias no requieren reinicio después de aplicar las revisiones, o si dispone de aplicaciones o procesos que se ejecutan en una instancia que no deberían verse interrumpidos como consecuencia del reinicio de una operación de aplicación de revisiones. También es útil cuando se desea tener más control sobre el tiempo de los reinicios de la instancia, por ejemplo, mediante un periodo de mantenimiento.
**Archivo de seguimiento de instalación de revisiones**: para realizar un seguimiento de la instalación de revisiones, especialmente las revisiones que se hayan instalados desde el último reinicio del sistema, Systems Manager mantiene un archivo en la instancia administrada.
**importante**
No elimine ni modifique el archivo de seguimiento. Si este archivo se elimina o está dañado, el informe de conformidad de revisiones para la instancia es inexacto. Si esto sucede, reinicie la instancia y ejecute una operación de análisis de revisión para restaurar el archivo.
Este archivo de seguimiento se almacena en las siguientes ubicaciones de las instancias administradas:
+ Sistemas operativos Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operativo :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager es compatible con `AWS-RunPatchBaselineWithHooks`, un documento de Systems Manager (documento de SSM) para Patch Manager, una herramienta de AWS Systems Manager. Este documento de SSM realiza operaciones de aplicación de revisiones en los nodos administrados para actualizaciones relacionadas con la seguridad y de otros tipos.
`AWS-RunPatchBaselineWithHooks` se diferencia de `AWS-RunPatchBaseline` en los siguientes aspectos:
+ **Un documento contenedor:** `AWS-RunPatchBaselineWithHooks` es un contenedor de `AWS-RunPatchBaseline` y se basa en `AWS-RunPatchBaseline` para realizar algunas de sus operaciones.
+ **La operación `Install`**: `AWS-RunPatchBaselineWithHooks` admite enlaces de ciclo de vida que se ejecutan en puntos designados durante la aplicación de revisiones en los nodos administrados. Dado que las instalaciones de revisiones en ocasiones requieren que se reinicien los nodos administrados, la operación de aplicación de revisiones se divide en dos eventos, lo que supone un total de tres enlaces que permiten una funcionalidad personalizada. El primer enlace tiene lugar antes de la operación `Install with NoReboot`. El segundo enlace tiene lugar después de la operación `Install with NoReboot`. El tercer enlace está disponible después del reinicio del nodo administrado.
+ **Sin compatibilidad con la lista de parches personalizados:** `AWS-RunPatchBaselineWithHooks` no admite el parámetro `InstallOverrideList`.
+ **Compatibilidad con SSM Agent**: `AWS-RunPatchBaselineWithHooks` requiere que se instale la versión 3.0.502 o una posterior de SSM Agent en el nodo administrado en el que se aplicará la revisión.
Cuando el documento se ejecuta, utiliza la base de referencia de parches que actualmente se encuentra especificada como “predeterminada” para un tipo de sistema operativo en caso de que no se hubiera indicado ningún grupo de parches. En caso contrario, utiliza las bases de referencia de parches que se asocian con el grupo de parches. Para obtener información acerca de los grupos de parches, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
Puede utilizar el documento `AWS-RunPatchBaselineWithHooks` para aplicar revisiones a los sistemas operativos y a las aplicaciones. (En Windows Server, la compatibilidad con las aplicaciones se limita a las actualizaciones de las aplicaciones publicadas por Microsoft).
Este documento es compatible con los nodos administrados de Linux y Windows Server. El documento se encargará de realizar las acciones adecuadas para cada plataforma.
**nota**
`AWS-RunPatchBaselineWithHooks` no es compatible conmacOS.
------
#### [ Linux ]
En nodos administrados de Linux, el documento `AWS-RunPatchBaselineWithHooks` invoca un módulo de Python, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones utiliza las reglas definidas y las listas de revisiones aprobadas y bloqueadas con el fin de impulsar el administrador de paquetes adecuado para cada tipo de nodo:
+ Los nodos administrados de Amazon Linux 2, Oracle Linux y RHEL 7 utilizan YUM. Para las operaciones de YUM, Patch Manager requiere `Python 2.6` o una versión posterior compatible (2.6 a 3.12). Amazon Linux 2023 usa DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12).
+ RHELLos nodos administrados de 8 utilizan DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12). (Ninguna de las dos versiones viene instalada en RHEL 8 de forma predeterminada. Para ello, deberá instalar una u otra versión manualmente).
+ Las instancias de Debian Server y Ubuntu Server usan APT. Para las operaciones de APT, Patch Manager requiere una versión compatible de `Python 3` (3.0 a 3.12).
------
#### [ Windows Server ]
En nodos administrados de Windows Server, el documento `AWS-RunPatchBaselineWithHooks` descarga e invoca un módulo de PowerShell, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones contiene una lista de revisiones aprobadas que se compila al consultar dicha línea de base de revisiones en un servidor de Windows Server Update Services (WSUS). Esta lista se transfiere a la API de Windows Update, que controla la descarga y la instalación de los parches aprobados, según proceda.
------
Cada instantánea se corresponde con una Cuenta de AWS, un grupo de parches, un sistema operativo y un ID de instantánea. La instantánea se entrega a través de una URL prefirmada de Amazon Simple Storage Service (Amazon S3), que se vence transcurridas las 24 horas desde la creación de la instantánea. Sin embargo, si desea aplicar el mismo contenido de la instantánea a otros nodos administrados una vez que la URL se haya vencido, puede generar una nueva dirección de Amazon S3 prefirmada hasta tres días después de la creación de la instantánea. Para ello, utilice el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Cuando se han instalado todas las actualizaciones aprobadas y aplicables, y se han realizado los reinicios necesarios, se genera la información de conformidad de revisiones en un nodo administrado y se notifica a Patch Manager.
Si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaselineWithHooks`, el nodo administrado no se reinicia después de que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
**importante**
Si bien la opción `NoReboot` impide el reinicio del sistema operativo, no impide los reinicios a nivel de servicio que pueden producirse cuando se actualizan determinados paquetes. Por ejemplo, la actualización de paquetes como Docker puede provocar el reinicio automático de los servicios dependientes (como los servicios de orquestación de contenedores) incluso cuando `NoReboot` está especificado.
Para obtener información sobre cómo ver los datos de conformidad de revisiones, consulte [Acerca de la conformidad de parches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineWithHooks`Pasos operativos de
Cuando se ejecuta `AWS-RunPatchBaselineWithHooks`, se llevan a cabo los siguientes pasos:
1. **Análisis**: se ejecuta una operación `Scan` con `AWS-RunPatchBaseline` en el nodo administrado, y, de este modo, se genera y carga un informe de conformidad.
1. **Verificación de los estados del parche local:** se ejecuta un script para determinar los pasos que se llevarán a cabo en función de la operación seleccionada y el resultado de `Scan` del paso 1.
1. Si la operación seleccionada es `Scan`, esta se marcará como completada. La operación finaliza.
1. Si la operación seleccionada es `Install`, Patch Manager evalúa el resultado de `Scan` del paso 1 para determinar qué ejecutar a continuación:
1. Si no se detectan parches faltantes ni se requieren reinicios pendientes, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. Si no se detectan parches faltantes, pero hay reinicios pendientes, y la opción de reinicio seleccionada es `NoReboot`, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. De lo contrario, la operación continúa con el siguiente paso.
1. **Operación de enlace previa a la aplicación de revisiones**: el documento de SSM que ha proporcionado para el primer enlace de ciclo de vida, `PreInstallHookDocName`, se ejecuta en el nodo administrado.
1. **Instalación con NoReboot**: se ejecuta una operación `Install` con la opción de reinicio de `NoReboot` mediante `AWS-RunPatchBaseline` en el nodo administrado, y, de este modo, se genera y carga un informe de conformidad.
1. **Operación de enlace posterior a la instalación**: el documento de SSM que ha proporcionado para el segundo enlace de ciclo de vida, `PostInstallHookDocName`, se ejecuta en el nodo administrado.
1. **Verificación del reinicio**: se ejecuta un script para determinar si es necesario reiniciar el nodo administrado y cuáles son los pasos a ejecutar:
1. Si la opción de reinicio seleccionada es `NoReboot`, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. Si la opción de reinicio seleccionada es `RebootIfNeeded`, Patch Manager verifica que no haya reinicios pendientes necesarios a partir del inventario recopilado en el paso 4. Esto significa que la operación continúa con el paso 7 y el nodo administrado se reinicia en cualquiera de los siguientes casos:
1. Patch Manager instaló una o más revisiones. (Patch Manager no evalúa si la revisión requiere llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.)
1. Patch Manager detecta una o más revisiones con un estado `INSTALLED_PENDING_REBOOT` durante la operación de instalación. El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación de instalación o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
Si no se encuentran revisiones que requieran un reinicio, la operación de aplicación de revisiones en el nodo administrado se completa, de modo que la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. **Instalación e informe**: se ejecuta una operación de instalación con la opción de reinicio de `RebootIfNeeded` en el nodo administrado mediante `AWS-RunPatchBaseline`, y, de este modo, se genera y carga un informe de conformidad.
1. **Operación de enlace posterior al reinicio**: el documento de SSM que ha proporcionado para el tercer enlace de ciclo de vida, `OnExitHookDocName`, se ejecuta en el nodo administrado.
Para una operación `Scan`, si se produce un error en el paso 1, el proceso de ejecución del documento se detiene y ese paso se notifica como un error, aunque los posteriores se hayan realizado correctamente.
Para una operación `Install`, si se produce un error en alguno de los pasos de `aws:runDocument` durante la operación, esos se notifican como error, de modo que la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios. Este paso se notifica como error, mientras que el último paso notifica el estado del resultado de su operación, y todos los pasos intermedios se notifican como realizados correctamente.
## `AWS-RunPatchBaselineWithHooks`Parámetros
`AWS-RunPatchBaselineWithHooks` admite seis parámetros.
El parámetro `Operation` es obligatorio.
Los parámetros `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` e `OnExitHookDocName` son opcionales.
`Snapshot-ID` es opcional desde el punto de vista técnico, pero se recomienda que proporcione un valor personalizado cuando ejecute `AWS-RunPatchBaselineWithHooks` fuera de un periodo de mantenimiento. Permita que Patch Manager proporcione el valor automáticamente cuando se ejecute el documento como parte de una operación del periodo de mantenimiento.
**Topics**
+ [Nombre del parámetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nombre del parámetro: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nombre del parámetro: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nombre del parámetro: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nombre del parámetro: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### Nombre del parámetro: `Operation`
**Usage**: requerido.
**Opciones**: `Scan` \$1 `Install`.
Examen
Cuando elige la opción `Scan`, el sistema utiliza el documento `AWS-RunPatchBaseline` para determinar el estado de conformidad de las revisiones del nodo administrado y notifica esta información a Patch Manager. `Scan` no solicita que se instalen actualizaciones ni que se reinicien los nodos administrados. En lugar de ello, la operación identifica las actualizaciones aprobadas que faltan y que son aplicables al nodo.
Instalación
Al elegir la opción `Install`, `AWS-RunPatchBaselineWithHooks` intenta instalar las actualizaciones aprobadas y aplicables que faltan en el nodo administrado. La información de conformidad de revisiones generada como parte de una operación `Install` no muestra las actualizaciones que faltan, pero podría notificar aquellas que presentan un estado de error si la instalación de la actualización no se ha podido realizar por cualquier motivo. Cuando una actualización se instala en un nodo administrado, este se reinicia para garantizar que la actualización esté instalada y activa. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaselineWithHooks`, 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`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)).
Si se instala una revisión especificada por las reglas de la línea de base *antes* de que Patch Manager actualice el nodo administrado, es posible que el sistema no se reinicie como es debido. Esto puede ocurrir cuando un usuario instala manualmente una revisión o cuando la instala automáticamente otro programa, como el `unattended-upgrades` paquete de Ubuntu Server.
### Nombre del parámetro: `Snapshot ID`
**Usage**: opcional.
`Snapshot ID` es un ID exclusivo (GUID) que utiliza Patch Manager para garantizar que un conjunto de nodos administrados en los que se aplican revisiones en una sola operación tenga el mismo conjunto de revisiones aprobadas. Aunque el parámetro se define como opcional, nuestra mejor práctica recomendada depende de si se ejecuta o no `AWS-RunPatchBaselineWithHooks` en un periodo de mantenimiento, tal como se describe en la siguiente tabla.
**`AWS-RunPatchBaselineWithHooks`Prácticas recomendadas de**
| Mode | Práctica recomendada | Details |
| --- | --- | --- |
| Ejecución de AWS-RunPatchBaselineWithHooks dentro de un periodo de mantenimiento | No proporcione un ID de instantánea, sino que Patch Manager lo hará en su lugar. | Si utiliza un periodo de mantenimiento para ejecutar `AWS-RunPatchBaselineWithHooks`, no debe proporcionar su propio ID de instantánea generado. En este caso, Systems Manager proporciona un valor GUID en función del ID de ejecución del periodo de mantenimiento. De este modo, se garantiza que se utilice un ID correcto para todas las invocaciones de `AWS-RunPatchBaselineWithHooks` en dicho periodo de mantenimiento. Si especifica un valor en este caso, tenga en cuenta que la instantánea de la línea de base de revisiones no podría mantenerse durante más de tres días. Después de eso, se generará una nueva instantánea, aunque especifique el mismo ID después de que expire la instantánea. |
| Ejecución de AWS-RunPatchBaselineWithHooks fuera de un periodo de mantenimiento | Genere y especifique un valor GUID personalizado para el ID de instantánea.¹ | Cuando no esté utilizando un periodo de mantenimiento para ejecutar `AWS-RunPatchBaselineWithHooks`, se recomienda generar y especificar un ID de instantánea exclusivo por cada línea de base de revisiones, especialmente si ejecuta el documento `AWS-RunPatchBaselineWithHooks` en varios nodos administrados durante la misma operación. Si no especifica un ID en este caso, Systems Manager genera otro ID de instantánea para cada nodo administrado al que se envía el comando. Esto podría generar diferentes conjuntos de revisiones que se especifican entre los nodos. Por ejemplo, supongamos que se ejecuta el documento `AWS-RunPatchBaselineWithHooks` directamente a través de Run Command, una herramienta de AWS Systems Manager, y selecciona como destino un grupo de 50 nodos administrados. Al especificar un ID de instantánea personalizado, se genera una sola instantánea de la base de referencia que se utiliza para evaluar y aplicar revisiones en todos los nodos administrados, lo que garantiza que tengan un estado coherente. |
| ¹ Puede utilizar cualquier herramienta que genere un GUID con el fin de crear un valor para el parámetro de ID de la instantánea. Por ejemplo, en PowerShell, puede utilizar el cmdlet `New-Guid` para generar un GUID con el formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`. |
### Nombre del parámetro: `RebootOption`
**Usage**: opcional.
**Opciones**: `RebootIfNeeded` \$1 `NoReboot`
**Valor predeterminado**: `RebootIfNeeded`
**aviso**
La opción predeterminada es `RebootIfNeeded`. Asegúrese de seleccionar la opción correcta para su caso de uso. Por ejemplo, si los nodos administrados deben reiniciarse inmediatamente para completar un proceso de configuración, elija `RebootIfNeeded`. O bien, si necesita mantener la disponibilidad de los nodos administrados hasta una hora de reinicio programada, elija `NoReboot`.
**importante**
No recomendamos el uso de Patch Manager para revisar las instancias de clústeres en Amazon EMR (antes denominado Amazon Elastic MapReduce). En concreto, no seleccione la opción `RebootIfNeeded` para el parámetro `RebootOption`. (Esta opción está disponible en los documentos de SSM Command para implementar revisiones `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, y `AWS-RunPatchBaselineWithHooks`).
Los comandos subyacentes para implementar revisiones mediante el uso de Patch Manager y los comandos `yum` y `dnf`. Por lo tanto, las operaciones generan incompatibilidades debido a la forma en que se instalan los paquetes. Para obtener información sobre los métodos preferidos para actualizar el software en los clústeres de Amazon EMR, consulte [Uso de la AMI predeterminada para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) en la *Guía de administración de Amazon EMR*.
RebootIfNeeded
Cuando se elige la opción `RebootIfNeeded`, el nodo administrado se reinicia en cualquiera de los siguientes casos:
+ Patch Manager instaló una o más revisiones.
Patch Manager no evalúa si la revisión *requiere* llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.
+ Patch Manager detecta uno o más revisiones con un estado de `INSTALLED_PENDING_REBOOT` durante la operación `Install`.
El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación `Install` o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
El reinicio de los nodos administrados en estos dos casos garantiza que los paquetes actualizados se eliminen de la memoria y mantiene un comportamiento de aplicación de revisiones y reinicio consistente en todos los sistemas operativos.
NoReboot
Cuando elige la opción `NoReboot`, Patch Manager no reinicia un nodo administrado aunque haya instalado revisiones durante la operación `Install`. Esta opción es útil si sabe que los nodos administrados no requieren reinicio después de aplicar las revisiones, o si dispone de aplicaciones o procesos que se ejecutan en un nodo que no deberían verse interrumpidos como consecuencia del reinicio de una operación de aplicación de revisiones. También es útil cuando se desea tener más control sobre el tiempo de los reinicios del nodo administrado, por ejemplo, mediante un periodo de mantenimiento.
Si elige la opción `NoReboot` y se ha instalado una revisión, se asigna a la revisión un estado de `InstalledPendingReboot`. Sin embargo, el nodo administrado en sí mismo está marcado como `Non-Compliant`. Una vez que se produce un reinicio y se ejecuta una operación `Scan`, el estado del nodo se actualiza a `Compliant`.
**Archivo de seguimiento de instalación de revisiones**: para realizar un seguimiento de la instalación de revisiones, especialmente las instaladas desde el último reinicio del sistema, Systems Manager mantiene un archivo en el nodo administrado.
**importante**
No elimine ni modifique el archivo de seguimiento. Si este archivo se elimina o está dañado, el informe de conformidad de revisiones para el nodo administrado es inexacto. Si esto sucede, reinicie el nodo y ejecute una operación de análisis de revisiones para restaurar el archivo.
Este archivo de seguimiento se almacena en las siguientes ubicaciones de los nodos administrados:
+ Sistemas operativos Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operativo :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nombre del parámetro: `PreInstallHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `PreInstallHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta antes de la operación `Install` y lleva a cabo cualquier acción admitida por SSM Agent, como un script de shell que verifique la comprobación de estado de la aplicación antes de implementar revisiones en el nodo administrado. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
### Nombre del parámetro: `PostInstallHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `PostInstallHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta después de la operación `Install with NoReboot` y realiza cualquier acción admitida por SSM Agent, como un script de shell que permite instalar actualizaciones de terceros antes de proceder al reinicio. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
### Nombre del parámetro: `OnExitHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `OnExitHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta después de la operación de reinicio del nodo administrado y lleva a cabo cualquier acción admitida por SSM Agent, como un script de shell que compruebe el estado del nodo una vez completada la operación de aplicación de revisiones. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
# Ejemplo de escenario para utilizar el parámetro InstallOverrideList en `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`
Puede utilizar el parámetro `InstallOverrideList` cuando desee anular las revisiones especificadas por la línea de base de revisiones predeterminada actual en Patch Manager, una herramienta de AWS Systems Manager. Este tema proporciona una serie de ejemplos que muestran cómo utilizar este parámetro para obtener los siguientes resultados:
+ Aplique diferentes conjuntos de revisiones a un grupo de nodos administrados de destino.
+ Aplique estos conjuntos de revisiones en diferentes frecuencias.
+ Utilice la misma línea de base de revisiones para ambas operaciones.
Imagine que desea instalar dos categorías de revisiones distintas en los nodos administrados de Amazon Linux 2. Quiere instalar estas revisiones en diferentes programaciones mediante períodos de mantenimiento. Quiere que se ejecute un período de mantenimiento todas las semanas y que instale todas las revisiones de `Security`. Quiere que se ejecute otro período de mantenimiento una vez al mes y que instale todas las revisiones disponibles, o revisiones de categorías distintas a `Security`.
Sin embargo, solo se puede definir una línea de base de revisiones a la vez como la predeterminada de un sistema operativo. Este requisito ayuda a evitar situaciones en las que una línea de base de revisiones aprueba una revisión mientras que otra la bloquea, lo que puede provocar problemas entre versiones en conflicto.
La siguiente estrategia le permite utilizar el parámetro `InstallOverrideList` para aplicar diferentes tipos de revisiones a un grupo de destino, en diferentes programaciones, sin dejar de utilizar la misma línea de base de revisiones.
1. En la línea de base de revisiones predeterminada, asegúrese de que solo se especifican las actualizaciones `Security`.
1. Cree un periodo de mantenimiento que ejecute `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation` cada semana. No especifique una lista de anulación.
1. Cree una lista de anulación de las revisiones de todos los tipos que desee aplicar mensualmente y almacénela en un bucket de Amazon Simple Storage Service (Amazon S3).
1. Cree un segundo período de mantenimiento que se ejecute una vez al mes. Sin embargo, para la tarea Run Command que registre en este periodo de mantenimiento, especifique la ubicación de su lista de anulación.
El resultado: solo se instalan las revisiones de `Security` semanalmente, tal como se define en su línea de base de revisiones. Todas las revisiones disponibles, o cualquier subconjunto de revisiones que defina, se instalan cada mes.
**nota**
Cuando aplique revisiones a un nodo que solo usa IPv6, asegúrese de que se pueda acceder a la URL proporcionada desde el nodo. Si la opción de configuración `UseDualStackEndpoint` de SSM Agent está establecida en `true`, se utiliza un cliente S3 de pila doble cuando se proporciona una URL de S3. Consulte [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obtener más información sobre cómo configurar el agente para usar la pila doble.
Para obtener más información y muestras, consulte [Nombre del parámetro: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).
# Uso del parámetro BaselineOverride
Puede definir las preferencias de parches en tiempo de ejecución mediante la característica de anulación de base de referencia de parches en Patch Manager, una herramienta de AWS Systems Manager. Para ello, especifique un bucket de Amazon Simple Storage Service (Amazon S3) que contenga un objeto JSON con una lista de bases de referencia de parches. La operación de aplicación de parches utiliza las bases de referencia proporcionadas en el objeto JSON que concuerda con el sistema operativo del host en lugar de aplicar las reglas de la base de referencia de parches predeterminada
**importante**
El nombre de archivo `BaselineOverride` no puede contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
Salvo cuando una operación de revisión utiliza una política de revisión, el uso del parámetro `BaselineOverride` no sobrescribe la conformidad con la línea de base proporcionada en el parámetro. Los resultados de salida se registran en los registros Stdout de Run Command, una herramienta de AWS Systems Manager. Los resultados solo imprimen los paquetes marcados como `NON_COMPLIANT`. Esto significa que el paquete está marcado como `Missing`, `Failed`, `InstalledRejected`, o `InstalledPendingReboot`.
No obstante, cuando una operación de revisión utiliza una política de revisión, el sistema pasa el parámetro de anulación desde el bucket de S3 asociado y se actualiza el valor de conformidad del nodo administrado. Para obtener más información sobre los comportamientos de las políticas de revisiones, consulte [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
**nota**
Cuando aplique revisiones a un nodo que solo usa IPv6, asegúrese de que se pueda acceder a la URL proporcionada desde el nodo. Si la opción de configuración `UseDualStackEndpoint` de SSM Agent está establecida en `true`, se utiliza un cliente S3 de pila doble cuando se proporciona una URL de S3. Consulte [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obtener más información sobre cómo configurar el agente para usar la pila doble.
## Uso de la anulación de la base de referencia de parches con los parámetros de ID de instantánea o de lista de anulación de instalación
Se dan dos casos en los que la anulación de la base de referencia de parches presenta un comportamiento destacable.
**Uso de la anulación de la base de referencia y el ID de la instantánea al mismo tiempo**
Los ID de las instantáneas garantizan que todos los nodos administrados de un determinado comando de aplicación de revisiones apliquen lo mismo. Por ejemplo, si se aplican revisiones a 1000 nodos a la vez, estas serán las mismas.
Cuando se utiliza un ID de instantánea como una anulación de la base de referencia de parches, el ID de instantánea tiene prioridad sobre la anulación de la base de referencia de parches. Las reglas de anulación de la base de referencia se seguirán utilizando, pero solo se evaluarán una vez. En el ejemplo anterior, las revisiones en los 1000 nodos administrados continuarán siendo siempre las mismas. Si a mitad de la operación de aplicación de parches cambió el archivo JSON en el bucket de S3 referenciado para que sea diferente, los parches aplicados seguirán siendo los mismos. Esto se debe a que se proporcionó el ID de la instantánea.
**Uso de la anulación de la base de referencia y de la lista de anulación de la instalación al mismo tiempo**
No se pueden utilizar estos dos parámetros a la vez. El documento de aplicación de revisiones presenta un error si se proporcionan ambos parámetros, y no realiza ningún análisis ni instalación en el nodo administrado.
## Ejemplos de código
En el siguiente ejemplo de código para Python, se muestra cómo generar la anulación de la base de referencia de parches.
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
De este modo, se obtiene una anulación de la base de referencia de parches como la que se muestra a continuación.
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```