• 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). # 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.