• La AWS Systems Manager CloudWatch dashboard non sarà più disponibile dopo il 30 aprile 2026. I clienti possono continuare a utilizzare la CloudWatch console Amazon per visualizzare, creare e gestire le proprie CloudWatch dashboard Amazon, proprio come fanno oggi. Per ulteriori informazioni, consulta la [documentazione di Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline` AWS Systems Manager supporta`AWS-RunPatchBaseline`, un documento Systems Manager (documento SSM) perPatch Manager, uno strumento in AWS Systems Manager. Questo documento SSM esegue operazioni di applicazione di patch nei nodi gestiti per aggiornamenti correlati alla sicurezza e di altro tipo. Quando il documento viene eseguito, utilizza la baseline delle patch specificata come “predefinita” per un tipo di sistema operativo se non è specificato alcun gruppo di patch. In caso contrario, utilizza la baseline delle patch associata al gruppo di patch. Per informazioni sui gruppi di patch, consulta [Gruppi di patch](patch-manager-patch-groups.md). È possibile utilizzare il documento `AWS-RunPatchBaseline` per applicare patch ai sistemi operativi e alle applicazioni. (In Windows Server, il supporto delle applicazioni è limitato ai soli aggiornamenti delle applicazioni Microsoft). Questo documento supporta Linux, macOS, e nodi gestiti Windows Server. Il documento eseguirà le operazioni adeguate per ciascuna piattaforma. **Nota** Patch Manager supporta anche il documento SSM legacy `AWS-ApplyPatchBaseline`. Tuttavia, questo documento supporta l'applicazione di patch solo nei nodi gestiti Windows. Ti consigliamo di usare `AWS-RunPatchBaseline` perché supporta l'applicazione di patch nei nodi gestiti Linux macOS, e Windows Server. Una versione 2.0.834.0 o successiva di SSM Agent è richiesta per utilizzare il documento `AWS-RunPatchBaseline`. ------ #### [ Windows Server ] Nei nodi Windows Server gestiti, il `AWS-RunPatchBaseline` documento scarica e richiama un PowerShell modulo, che a sua volta scarica un'istantanea della linea di base della patch che si applica al nodo gestito. Questa snapshot della baseline delle patch contiene un elenco di patch approvate compilate eseguendo una query sulla baseline delle patch su un server Windows Server Update Services (WSUS). Questo elenco viene trasferito all'API di Windows Update, che controlla il download e l'installazione delle patch approvate, in base alle necessità. ------ #### [ Linux ] Nei nodi gestiti Linux, il documento `AWS-RunPatchBaseline` consente di richiamare un modulo Python, che a sua volta scarica una snapshot della baseline delle patch valida per il nodo gestito. Questa snapshot della baseline delle patch utilizza le regole e gli elenchi specificati delle patch approvate e bloccate per controllare il programma di gestione dei pacchetti adeguato per ciascun tipo di nodo: + I nodi gestiti da Amazon Linux 2, Oracle Linux e RHEL 7 utilizzano YUM. Per le operazioni con YUM, Patch Manager richiede `Python 2.6` o una versione supportata successiva (da 2.6 a 3.12). Amazon Linux 2023 utilizza DNF. Per le operazioni DNF, Patch Manager richiede una versione supportata di `Python 2` o `Python 3` (da 2.6 a 3.12). + I nodi gestiti 8 RHEL utilizzano DNF. Per le operazioni DNF, Patch Manager richiede una versione supportata di `Python 2` o `Python 3` (da 2.6 a 3.12). (Nessuna versione è installata per impostazione predefinita su RHEL 8. È necessario installare l'una o l'altra manualmente). + Le istanze Debian Server e Ubuntu Server utilizzano APT. Per le operazioni APT, Patch Manager richiede una versione supportata di `Python 3` (da 3.0 a 3.12). ------ #### [ macOS ] Nei nodi gestiti macOS, il documento `AWS-RunPatchBaseline` consente di scaricare e richiamare un modulo Python, che a sua volta scarica una snapshot della baseline delle patch valida per il nodo. Successivamente, un sottoprocesso Python richiama il AWS Command Line Interface (AWS CLI) sul nodo per recuperare le informazioni di installazione e aggiornamento per i gestori di pacchetti specificati e per guidare il gestore di pacchetti appropriato per ogni pacchetto di aggiornamento. ------ Ogni istantanea è specifica per un gruppo di patch Account AWS, un sistema operativo e un ID di istantanea. Lo snapshot viene consegnato tramite un URL Amazon Simple Storage Service (Amazon S3) prefirmato, che scade 24 ore dopo la creazione dello snapshot. Dopo la scadenza dell'URL, tuttavia, se desideri applicare lo stesso contenuto snapshot ad altri nodi gestiti, è possibile generare un nuovo URL Amazon S3 prefirmato fino a 3 giorni dopo la creazione della copia istantanea. Per farlo, utilizzare il 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). Dopo avere installato tutti gli aggiornamenti approvati e applicabili e dopo avere eseguito il riavvio, le informazioni sulla conformità delle patch vengono generate in un nodo gestito e trasferite a Patch Manager. **Nota** Se il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaseline`, il nodo gestito non viene riavviata dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption). Per informazioni sulla visualizzazione dei dati di conformità delle patch, consulta [Informazioni sulla conformità delle patch](compliance-about.md#compliance-monitor-patch). ## Parametri `AWS-RunPatchBaseline` `AWS-RunPatchBaseline` supporta sei parametri. Il parametro `Operation` è obbligatorio. I parametri `InstallOverrideList`, `BaselineOverride` e `RebootOption` sono facoltativi. `Snapshot-ID` è tecnicamente facoltativo, ma consigliamo di specificare un valore personalizzato quando si esegue `AWS-RunPatchBaseline` esternamente alla finestra di manutenzione. Patch Manager fornisce il valore automaticamente quando il documento viene eseguito come parte di un'operazione della finestra di manutenzione. **Topics** + [ ### Nome parametro: `Operation` ](#patch-manager-aws-runpatchbaseline-parameters-operation) + [ ### Nome parametro: `AssociationId` ](#patch-manager-aws-runpatchbaseline-parameters-association-id) + [ ### Nome parametro: `Snapshot ID` ](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id) + [ ### Nome parametro: `InstallOverrideList` ](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) + [ ### Nome parametro: `RebootOption` ](#patch-manager-aws-runpatchbaseline-parameters-norebootoption) + [ ### Nome parametro: `BaselineOverride` ](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride) + [ ### Nome parametro: `StepTimeoutSeconds` ](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds) ### Nome parametro: `Operation` **Utilizzo**: obbligatorio. **Opzioni**: `Scan` \$1 `Install`. Scan Quando si sceglie l'opzione `Scan`, `AWS-RunPatchBaseline` determina lo stato di conformità delle patch del nodo gestito e riferisce queste informazioni a Patch Manager. `Scan` non richiede l'installazione degli aggiornamenti o il riavvio dei nodi gestiti. L'operazione identifica dove gli aggiornamenti approvati e applicabili al nodo risultano mancanti. Installa Quando si sceglie l'opzione `Install`, `AWS-RunPatchBaseline` tenta di installare gli aggiornamenti applicabili e approvati che risultano mancanti nel nodo gestito. Le informazioni sulla conformità delle patch generate in un'operazione `Install` non visualizzano gli aggiornamenti mancanti, ma sono in grado di specificare lo stato di errore degli aggiornamenti se per qualsiasi motivo l'installazione non è andata a buon fine. Quando un aggiornamento è installato in un nodo gestito, questo viene riavviato per assicurare l'aggiornamento sia installato e attivo. (Eccezione: se il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaseline`, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).) Se una patch specificata dalle regole di baseline viene installata *prima* che Patch Manager aggiorni il nodo gestito, è possibile che il sistema non venga riavviato come previsto. Ciò si verifica quando una patch viene installata manualmente da un utente o installata automaticamente da un altro programma, ad esempio il pacchetto `unattended-upgrades` su Ubuntu Server. ### Nome parametro: `AssociationId` **Utilizzo**: facoltativo. `AssociationId` è l'ID di un'associazione esistente in State Manager, uno strumento di AWS Systems Manager. È utilizzato da Patch Manager per aggiungere i dati di conformità a un'associazione specificata. Tale associazione è correlata a un'operazione di applicazione di patch [configurata in una policy di patch in Quick Setup](quick-setup-patch-manager.md). **Nota** Con `AWS-RunPatchBaseline`, se viene fornito un valore `AssociationId` insieme a una sostituzione della baseline della policy di patch, l'applicazione di patch viene eseguita come un'operazione `PatchPolicy` e il valore `ExecutionType` riportato in `AWS:ComplianceItem` è anche `PatchPolicy`. Se non viene fornito alcun valore `AssociationId`, l'applicazione di patch viene eseguita come un'operazione `Command` e anche il valore `ExecutionType` riportato nel parametro `AWS:ComplianceItem` inviato è `Command`. Se non disponi già di un'associazione da utilizzare, è possibile crearla eseguendo il 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). ### Nome parametro: `Snapshot ID` **Utilizzo**: facoltativo. `Snapshot ID` è un ID univoco (GUID) utilizzato da Patch Manager per assicurare che una serie di nodi gestiti a cui vengono applicate le patch in un'unica operazione abbiano la stessa serie di patch approvate. Anche se il parametro è definito come facoltativo, la best practice dipende dal fatto che `AWS-RunPatchBaseline` sia o meno in esecuzione in una finestra di manutenzione, come descritto nella seguente tabella. **Best practice di `AWS-RunPatchBaseline`** | Modalità | Best practice | Informazioni | | --- | --- | --- | | In esecuzione AWS-RunPatchBaseline all'interno di una finestra di manutenzione | Non fornire un ID della snapshot. Patch Manager la fornirà automaticamente. | Quando utilizzi una finestra di manutenzione per eseguire `AWS-RunPatchBaseline`, non devi fornire l'ID della snapshot generata. In questo scenario, Systems Manager fornisce un valore GUID in base all'ID di esecuzione della finestra di manutenzione. In questo modo, si garantisce che venga utilizzato un ID corretto per tutte le invocazioni di `AWS-RunPatchBaseline` in tale finestra di manutenzione. Si noti che se si specifica un valore in questo scenario, la snapshot della baseline delle patch potrebbe non durare per più di 3 giorni. In seguito, verrà generata una nuova snapshot anche se hai specificato lo stesso ID dopo la scadenza della snapshot. | | In esecuzione AWS-RunPatchBaseline al di fuori di una finestra di manutenzione | Generare e specificare un valore GUID personalizzato per l'ID della snapshot. | Se non utilizzi una finestra di manutenzione per eseguire `AWS-RunPatchBaseline`, ti consigliamo di generare e specificare un ID snapshot univoco per ogni baseline delle patch, soprattutto se stai eseguendo il documento `AWS-RunPatchBaseline` su più nodi gestiti nella stessa operazione. Se specifichi un ID in questo scenario, Systems Manager genera un altro ID snapshot per ciascun nodo gestito a cui viene inviato il comando. Di conseguenza, potrebbero venire specificate varie serie di patch fra i nodi gestiti. Ad esempio, potresti eseguire il documento `AWS-RunPatchBaseline` direttamente tramite Run Command, uno strumento di AWS Systems Manager e destinarlo a un gruppo di 50 nodi gestiti. Specificando un ID snapshot personalizzato verrà creata una singola snapshot di baseline utilizzata per valutare le patch e tutti i nodi, per garantire che il relativo stato finale sia coerente. | | ¹ È possibile utilizzare qualsiasi strumento in grado di generare un GUID per ottenere il valore del parametro ID snapshot. Ad esempio, in PowerShell, è possibile utilizzare il `New-Guid` cmdlet per generare un GUID nel formato di. `12345699-9405-4f69-bc5e-9315aEXAMPLE` | ### Nome parametro: `InstallOverrideList` **Utilizzo**: facoltativo. `InstallOverrideList` consente di specificare un URL https o un URL in stile percorso Amazon S3 per un elenco delle patch da installare. Questo elenco di installazione delle patch, gestito in formato YAML, sostituisce le patch specificate dalla baseline delle patch predefinita corrente. Ciò consente di avere un controllo più granulare su quali patch vengono installate nei nodi gestiti. **Importante** Il nome del file `InstallOverrideList` non consente la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1). Il comportamento dell'applicazione di patch quando si utilizza il parametro `InstallOverrideList`, differisce tra nodi gestiti da Linux e macOS o da Windows Server. Su Linux e macOS, Patch Manager tenta di applicare le patch incluse nell'elenco `InstallOverrideList` delle patch presenti in qualsiasi repository abilitato sul nodo, indipendentemente dal fatto che corrispondano o meno alle regole della baseline delle patch. Sui nodi di Windows Server, tuttavia, le patch nell'elenco `InstallOverrideList` vengono applicate *solo* quando corrispondono anche alle regole della baseline delle patch. I report di conformità rispecchiano gli stati delle patch in base a quanto specificato nella baseline delle patch, non ciò che hai specificato in un elenco `InstallOverrideList` di patch. In altre parole, le operazioni di scansione ignorano il parametro `InstallOverrideList`. In questo modo si garantisce che i report di conformità rispecchino in modo omogeneo gli stati delle patch in base alla policy anziché in base a quanto era stato approvato per una specifica operazione di applicazione di patch. **Nota** Quando esegui la patch di un nodo che utilizza solo un nodo IPv6, assicurati che l'URL fornito sia raggiungibile dal nodo. Se l'opzione di SSM Agent configurazione `UseDualStackEndpoint` è impostata su`true`, viene utilizzato un client S3 dualstack quando viene fornito un URL S3. [Tutorial: applicazione di patch a un server in un IPv6 unico ambiente](patch-manager-server-patching-iPv6-tutorial.md)Per ulteriori informazioni sulla configurazione dell'agente per l'utilizzo del dualstack, consulta. Per una descrizione di come è possibile utilizzare il parametro `InstallOverrideList` per applicare diversi tipi di patch a un gruppo di destinazione in diverse pianificazioni delle finestre di manutenzione, pur utilizzando una singola baseline delle patch, consulta [Scenario di esempio per l'utilizzo del InstallOverrideList parametro in `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md). **Formati URL validi** **Nota** Se il file è archiviato in un bucket pubblicamente disponibile, è possibile inoltre specificare un formato URL https o un URL in stile percorso Amazon S3. Se il file è archiviato in un bucket privato, è necessario specificare un URL in stile percorso Amazon S3. + **formato URL https**: ``` https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml ``` + **URL in stile percorso Amazon S3**: ``` s3://amzn-s3-demo-bucket/my-windows-override-list.yaml ``` **Formati dei contenuti YAML validi** I formati utilizzati per specificare le patch nell'elenco variano in base al sistema operativo del tuo nodo gestito. Il formato generale, tuttavia, è quello riportato di seguito: ``` patches: - id: '{patch-d}' title: '{patch-title}' {additional-fields}:{values} ``` Benché sia possibile specificare altri campi nel file YAML, questi verranno ignorati durante le operazioni delle patch. Inoltre, è consigliabile verificare che il formato del file YAML sia valido prima di aggiungere o aggiornare l'elenco nel bucket S3. Per ulteriori informazioni sul formato YAML, consulta [yaml.org](http://www.yaml.org). Per le opzioni degli strumento di convalida, effettua la ricerca sul Web di “convalida formato yaml”. ------ #### [ Linux ] **id** Il campo **id** è obbligatorio. Utilizzalo per specificare le patch con l'architettura e il nome del pacchetto. Ad esempio: `'dhclient.x86_64'`. Negli id, è possibile utilizzare i caratteri jolly per indicare più pacchetti. Ad esempio: `'dhcp*'` ed `'dhcp*1.*'`. **Titolo** Il campo **titolo** è facoltativo, ma nei sistemi Linux offre funzionalità di filtraggio aggiuntive. Quando utilizzi **titolo**, è necessario che il campo includa le informazioni sulla versione del pacchetto in uno dei seguenti formati: YUM/SUSE Linux Enterprise Server (SLES): ``` {name}.{architecture}:{epoch}:{version}-{release} ``` APT ``` {name}.{architecture}:{version} ``` Per i titoli delle patch di Linux, è possibile utilizzare uno o più caratteri jolly in qualsiasi posizione per ampliare il numero di corrispondenze dei pacchetti. Ad esempio: `'*32:9.8.2-0.*.rc1.57.amzn1'`. Ad esempio: + Il pacchetto apt versione 1.2.25 è correntemente installato nel nodo gestito, ma ora è disponibile la versione 1.2.27. + È possibile aggiungere apt.amd64 versione 1.2.27 all'elenco delle patch. Dipende da apt-utils.amd64 versione 1.2.27, ma apt-utils.amd64 versione 1.2.25 viene specificato nell'elenco. In questo caso, la versione 1.2.27 di apt verrà bloccata dall'installazione e riportata come «Failed-». NonCompliant ------ #### [ Windows Server ] **id** Il campo **id** è obbligatorio. Utilizzatelo per specificare le patch utilizzando Microsoft Knowledge Base IDs (ad esempio KB2736693) e Microsoft Security Bulletin IDs (ad esempio, MS17 -023). Tutti gli altri campi che intendi fornire in un elenco di patch per Windows sono facoltativi e hanno unicamente scopo informativo. È possibile utilizzare altri campi, come **title**, **classification**, **severity** o qualsiasi altro per fornire informazioni più dettagliate sulle patch specificate. ------ #### [ macOS ] **id** Il campo **id** è obbligatorio. Il valore per il campo **id** viene fornito utilizzando un formato `{package-name}.{package-version}` o un formato \$1package\$1name\$1. ------ **Elenchi di patch di esempio** + **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' ``` ### Nome parametro: `RebootOption` **Utilizzo**: facoltativo. **Opzioni**: `RebootIfNeeded` \$1 `NoReboot` **Default**: `RebootIfNeeded` **avvertimento** L'opzione predefinita è `RebootIfNeeded`. Assicurarsi di selezionare l'opzione corretta per il caso d'uso. Ad esempio, quando è necessario che i nodi gestiti vengano riavviati immediatamente per completare un processo di configurazione, scegli `RebootIfNeeded`. Oppure, quando è necessario mantenere la disponibilità dei nodi gestiti fino a un orario di riavvio pianificato, scegli `NoReboot`. **Importante** Non è consigliabile utilizzarlo Patch Manager per applicare patch a istanze di cluster in Amazon EMR (precedentemente chiamato Amazon Elastic). MapReduce In particolare, non selezionare l'opzione `RebootIfNeeded` per il parametro `RebootOption`. (Questa opzione è disponibile nei documenti del comando SSM per l'applicazione di patch `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` e `AWS-RunPatchBaselineWithHooks`). I comandi sottostanti per applicare le patch tramite Patch Manager utilizzano i comandi `yum` e `dnf`. Pertanto, le operazioni generano incompatibilità a causa del modo in cui i pacchetti vengono installati. Per informazioni sui metodi preferiti per l'aggiornamento del software sui cluster Amazon EMR, consulta [Utilizzo dell’AMI predefinita per Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) nella *Guida per la gestione di Amazon EMR*. RebootIfNeeded Quando si sceglie l'opzione `RebootIfNeeded`, il nodo gestito viene riavviato in uno dei seguenti casi: + Patch Manager installato uno o più patch. Patch Manager non valuta se un riavvio è *obbligatorio* per la patch. Il sistema viene riavviato anche se la patch non richiede il riavvio. + Patch Manager rileva una o più patch con lo stato di `INSTALLED_PENDING_REBOOT` durante l'operazione `Install`. Lo stato `INSTALLED_PENDING_REBOOT` indica che l'opzione `NoReboot` è stata selezionata l'ultima volta che l'operazione `Install` è stata eseguita, o che una patch è stata installata all'esterno di Patch Manager dall'ultimo riavvio del nodo gestito. Il riavvio dei nodi gestiti in questi due casi garantisce che i pacchetti aggiornati vengano svuotati dalla memoria e mantengano coerenti il comportamento di patch e di riavvio in tutti i sistemi operativi. NoReboot Quando scegli l'opzione `NoReboot`, Patch Manager non riavvia il nodo gestito anche se ha installato patch durante l'operazione di `Install` Questa opzione è utile se i nodi gestiti non richiedono il riavvio dopo l'applicazione di patch, oppure nel caso di applicazioni o processi in esecuzione su un nodo che non dovrebbero essere interrotti da un riavvio a seguito di un'operazione di applicazione di patch. È utile anche quando si necessita di un maggiore controllo sui tempi dei riavvii del nodo gestito, ad esempio utilizzando una finestra di manutenzione. Quando si sceglie l'opzione `NoReboot` e viene installata una patch, alla patch viene assegnato lo stato `InstalledPendingReboot`. Il nodo gestito stesso, tuttavia, viene contrassegnato come `Non-Compliant`. Dopo che si verifica un riavvio e viene eseguita un'operazione `Scan`, lo stato del nodo gestito diventa `Compliant`. L'opzione `NoReboot` impedisce solo i riavvii a livello di sistema operativo. I riavvii a livello di servizio possono comunque avvenire come parte del processo di applicazione di patch. Ad esempio, quando Docker viene aggiornato, i servizi dipendenti come Amazon Elastic Container Service potrebbero riavviarsi automaticamente, anche con `NoReboot` abilitato. Se disponi di servizi critici, che non devono essere interrotti, prendi in considerazione misure aggiuntive come la rimozione temporanea delle istanze dal servizio o la pianificazione dell'applicazione di patch durante le finestre di manutenzione. **File di monitoraggio dell'installazione delle patch**: per tenere traccia dell'installazione delle patch, in particolare delle patch installate dopo l'ultimo riavvio del sistema, Systems Manager mantiene un file nel nodo gestito. **Importante** Non eliminare o modificare il file di monitoraggio. Se questo file viene eliminato o danneggiato, il rapporto di conformità della patch per il nodo gestito non è accurato. In questo caso, riavvia il nodo ed esegui un'operazione di scansione della patch per ripristinare il file. Questo file di monitoraggio viene archiviato nei seguenti percorsi nei nodi gestiti: + Sistemi operativi Linux: + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json` + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json` + Windows Server sistema operativo: + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json` + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json` ### Nome parametro: `BaselineOverride` **Utilizzo**: facoltativo. È possibile definire le preferenze per l'applicazione di patch in runtime (tempo di esecuzione) utilizzando il parametro `BaselineOverride`. Questa sostituzione della baseline viene mantenuta come oggetto JSON in un bucket S3. Garantisce che le operazioni di applicazione di patch utilizzino le baseline fornite che corrispondono al sistema operativo host anziché applicare le norme dalla baseline delle patch predefinita **Importante** Il nome del file `BaselineOverride` non consente la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1). Per ulteriori informazioni su come utilizzare il parametro `BaselineOverride`, consulta [Utilizzo del BaselineOverride parametro](patch-manager-baselineoverride-parameter.md). ### Nome parametro: `StepTimeoutSeconds` **Utilizzo**: obbligatorio. Il tempo in secondi, compreso tra 1 e 36.000 secondi (10 ore), entro cui un comando deve essere eseguito, prima che venga considerato non riuscito.