• 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à.
# Documenti sul comando SSM per l'applicazione di patch a nodi gestiti
Questo argomento descrive gli otto documenti di Systems Manager (documenti SSM) attualmente disponibili, utili per assicurarti che i nodi gestiti vengano applicati patch mediante gli aggiornamenti più recenti correlati alla sicurezza.
Consigliamo di utilizzare solo cinque di questi documenti per le applicazione di patch. Questi cinque documenti SSM offrono una gamma completa di opzioni di applicazione di patch utilizzando AWS Systems Manager. Quattro di questi documenti sono stati rilasciati successivamente ai quattro documenti SSM legacy che sostituiscono e rappresentano espansioni o consolidamenti di funzionalità.
**Documenti SSM consigliati per l'applicazione di patch**
Consigliamo di utilizzare i cinque documenti SSM seguenti per le operazioni di applicazione di patch.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**Documenti SSM legacy per l'applicazione di patch**
I seguenti quattro documenti SSM legacy rimangono disponibili in alcune Regioni AWS ma non sono più aggiornati o supportati. Non è garantito che questi documenti funzionino solo in IPv6 ambienti e supporto. IPv4 Non è possibile garantire che funzionino in tutti gli scenari e potrebbero perdere supporto in futuro. Si consiglia di non utilizzare questi documenti per le operazioni di applicazione di patch.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Per i passaggi per configurare le operazioni di patching in un ambiente che supporta solo la tecnologia, IPv6 consulta. [Tutorial: applicazione di patch a un server in un IPv6 unico ambiente](patch-manager-server-patching-iPv6-tutorial.md)
Per ulteriori informazioni sull'uso di questi documenti SSM nelle operazioni di applicazione di patch, consulta le seguenti sezioni.
**Topics**
+ [Documenti SSM consigliati per i nodi gestiti di applicazione di patch](#patch-manager-ssm-documents-recommended)
+ [Documenti SSM legacy per l'applicazione di patch a nodi gestiti](#patch-manager-ssm-documents-legacy)
+ [Limitazioni note dei documenti SSM per l'applicazione di patch ai nodi gestiti](#patch-manager-ssm-documents-known-limitations)
+ [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Scenario di esempio per l'utilizzo del InstallOverrideList parametro in `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Utilizzo del BaselineOverride parametro](patch-manager-baselineoverride-parameter.md)
## Documenti SSM consigliati per i nodi gestiti di applicazione di patch
I seguenti cinque documenti SSM sono consigliati per l'uso nelle operazioni di applicazioni di patch nei nodi gestiti.
**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`
Supporta la configurazione di funzioni Windows Update di base e il relativo utilizzo per l'installazione automatica degli aggiornamenti (o per disabilitare gli aggiornamenti automatici). Disponibile in tutte le Regioni AWS.
Questo documento SSM richiede a Windows Update di scaricare e installare gli aggiornamenti specificati e di riavviare i nodi gestiti in base alle esigenze. Utilizzate questo documento conState Manager, uno strumento incluso AWS Systems Manager, per assicurarvi che Windows Update mantenga la sua configurazione. È inoltre possibile eseguirlo manualmente utilizzandoRun Command, uno strumento in AWS Systems Manager, per modificare la configurazione di Windows Update.
I parametri disponibili in questo documento ti consentono di specificare una categoria di aggiornamenti da installare (o se disabilitare gli aggiornamenti automatici), nonché di specificare l'ora e il giorno della settimana dell'esecuzione delle operazioni di applicazione di patch. Questo documento SSM è utile in particolare se non devi controllare rigidamente gli aggiornamenti Windows e se non devi raccogliere le informazioni sulla conformità.
**Sostituisce i seguenti documenti SSM legacy: **
+ *Nessuno*
### `AWS-InstallWindowsUpdates`
Installa gli aggiornamenti su un nodo gestito Windows Server. Disponibile in tutte le Regioni AWS.
Questo documento SSM offre le funzionalità delle basi di patch nel caso desiderassi installare un aggiornamento specifico (utilizzando il parametro `Include Kbs`) o installare le patch con specifiche classificazioni o categorie, senza necessità di avere le informazioni sulla conformità delle patch.
**Sostituisce i seguenti documenti SSM legacy:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
I tre documenti legacy svolgono diverse funzioni, ma è possibile ottenere gli stessi risultati utilizzando altre impostazioni dei parametri con il più recente documento SSM `AWS-InstallWindowsUpdates`. Tali impostazioni dei parametri sono descritte in [Documenti SSM legacy per l'applicazione di patch a nodi gestiti](#patch-manager-ssm-documents-legacy).
### `AWS-RunPatchBaseline`
Consente di installare patch nei nodi gestiti o analizza i nodi per stabilire se eventuali patch qualificate risultano mancanti. Disponibile in tutte le Regioni AWS.
`AWS-RunPatchBaseline` consente di controllare le approvazioni delle patch utilizzando la baseline delle patch specificata come «predefinita» per un tipo di sistema operativo. Fornisce le informazioni sulla conformità delle patch visualizzabili con gli strumenti di conformità di Systems Manager. Questi strumenti offrono approfondimenti sullo stato di conformità delle patch dei nodi gestiti, ad esempio a quali nodi mancano le patch e quali sono tali patch. Quando si utilizza `AWS-RunPatchBaseline`, le informazioni sulla conformità delle patch vengono registrate utilizzando il comando API`PutInventory`. Per i sistemi operativi Linux, le informazioni sulla conformità vengono fornite per le patch dal repository di fonte di default configurato in un nodo gestito e da qualsiasi repository di origine alternativo specificato in una baseline delle patch personalizzata. Per ulteriori informazioni sui repository di origine alternativi, consulta [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md). Per ulteriori informazioni sugli strumenti di conformità di Systems Manager, consulta [ConformitàAWS Systems Manager](systems-manager-compliance.md).
**Sostituisce i seguenti documenti legacy:**
+ `AWS-ApplyPatchBaseline`
Il documento legacy `AWS-ApplyPatchBaseline` è valido solo per i nodi gestiti Windows Server e non fornisce supporto per l'applicazione di patch alle applicazioni. Il più recente `AWS-RunPatchBaseline` offre lo stesso supporto per i sistemi Windows e Linux. Una versione 2.0.834.0 o successiva di SSM Agent è richiesta per poter utilizzare il documento `AWS-RunPatchBaseline`.
Per ulteriori informazioni sull'utilizzo del documento SSM `AWS-RunPatchBaseline`, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
### `AWS-RunPatchBaselineAssociation`
Consente di installare patch nelle istanze o analizza le istanze per stabilire se eventuali patch qualificate risultano mancanti. Disponibile in tutte le Regioni AWS commerciali.
`AWS-RunPatchBaselineAssociation` differisce da `AWS-RunPatchBaseline` in alcuni modi importanti:
+ `AWS-RunPatchBaselineAssociation` è destinato all'uso principalmente con associazioni State Manager create utilizzando Quick Setup, uno strumento di AWS Systems Manager. In particolare, quando utilizzi il tipo di configurazione di gestione host Quick Setup, scegliendo l'opzione **Scan instances for missing patches daily** (Scansiona le istanze per le patch mancanti ogni giorno), il sistema utilizza `AWS-RunPatchBaselineAssociation` per l'operazione.
Nella maggior parte dei casi, tuttavia, quando si impostano le proprie operazioni di patch, è necessario scegliere [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) o [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) invece di `AWS-RunPatchBaselineAssociation`.
Per ulteriori informazioni, consulta i seguenti argomenti:
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` supporta l'utilizzo di tag per identificare la baseline delle patch da utilizzare con un insieme di destinazioni durante l'esecuzione.
+ Per le operazioni di applicazione di patch che utilizzano `AWS-RunPatchBaselineAssociation`, i dati di conformità delle patch vengono compilati in termini di un'associazione State Manager specifica. I dati di conformità delle patch raccolti quando `AWS-RunPatchBaselineAssociation` viene registrato utilizzando il comando `PutComplianceItems` al posto del comando `PutInventory`. Ciò impedisce che i dati di conformità non associati a questa particolare associazione vengano sovrascritti.
Per i sistemi operativi Linux, le informazioni sulla conformità vengono fornite per le patch dal repository di origine predefinito configurato in un'istanza e da qualsiasi repository di origine alternativo specificato in una baseline delle patch personalizzata. Per ulteriori informazioni sui repository di origine alternativi, consulta [Come specificare un repository alternativo di origine delle patch (Linux)](patch-manager-alternative-source-repository.md). Per ulteriori informazioni sugli strumenti di conformità di Systems Manager, consulta [ConformitàAWS Systems Manager](systems-manager-compliance.md).
**Sostituisce i seguenti documenti legacy:**
+ **Nessuno**
Per ulteriori informazioni sull'utilizzo del documento SSM `AWS-RunPatchBaselineAssociation`, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).
### `AWS-RunPatchBaselineWithHooks`
Consente di installare patch nei nodi gestiti o li analizza per determinare se eventuali patch qualificate risultano mancanti, con hook opzionali che è possibile utilizzare per eseguire i documenti SSM in tre punti durante il ciclo di applicazione di patch. Disponibile in tutte le Regioni AWS commerciali. Non supportato su macOS.
`AWS-RunPatchBaselineWithHooks` differisce da `AWS-RunPatchBaseline` nella sua operazione `Install`.
`AWS-RunPatchBaselineWithHooks` supporta gli hook del ciclo di vita che vengono eseguiti in punti designati durante l'applicazione di patch del nodo gestito. Poiché le installazioni di patch a volte richiedono il riavvio dei nodi gestiti, l'operazione di applicazione di patch è suddivisa in due eventi, per un totale di tre hook che supportano funzionalità personalizzate. Il primo hook è prima dell'operazione `Install with NoReboot`. Il secondo hook è dopo dell'operazione `Install with NoReboot`. Il terzo hook è disponibile dopo il riavvio del nodo.
**Sostituisce i seguenti documenti legacy:**
+ **Nessuno**
Per ulteriori informazioni sull'utilizzo del documento SSM `AWS-RunPatchBaselineWithHooks`, consulta [Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
## Documenti SSM legacy per l'applicazione di patch a nodi gestiti
I seguenti quattro documenti SSM sono ancora disponibili in alcune Regioni AWS. Tuttavia, non sono più aggiornati e potrebbero non essere più supportati in futuro, pertanto ne sconsigliamo l'utilizzo. In sostituzione, usa i documenti descritti in [Documenti SSM consigliati per i nodi gestiti di applicazione di patch](#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`
Supporta solo lei nodi gestiti Windows Server, ma non include il supporto per l'applicazione di patch alle applicazioni disponibili nel rispettivo documento sostitutivo `AWS-RunPatchBaseline`. Non disponibile nelle versioni Regioni AWS lanciate dopo agosto 2017.
**Nota**
La sostituzione per questo documento SSM, `AWS-RunPatchBaseline`, richiede la versione 2.0.834.0 o una versione successiva di SSM Agent. È possibile utilizzare il documento `AWS-UpdateSSMAgent` per aggiornare i nodi gestiti alla versione più recente dell'agente.
### `AWS-FindWindowsUpdates`
Sostituito da `AWS-InstallWindowsUpdates`, che è in grado di eseguire le stesse operazioni. Non disponibile nella versione Regioni AWS lanciata dopo aprile 2017.
Per ottenere lo stesso risultato del documento SSM legacy, utilizza la seguente configurazione dei parametri con il documento sostitutivo consigliato, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
Sostituito da `AWS-InstallWindowsUpdates`, che è in grado di eseguire le stesse operazioni. Non disponibile nelle versioni Regioni AWS lanciate dopo aprile 2017.
Per ottenere lo stesso risultato del documento SSM legacy, utilizza la seguente configurazione dei parametri con il documento sostitutivo consigliato, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
Sostituito da `AWS-InstallWindowsUpdates`, che è in grado di eseguire le stesse operazioni. Non disponibile nelle versioni Regioni AWS lanciate dopo aprile 2017.
Per ottenere lo stesso risultato del documento SSM legacy, utilizza la seguente configurazione dei parametri con il documento sostitutivo consigliato, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *comma-separated list of KB articles*
## Limitazioni note dei documenti SSM per l'applicazione di patch ai nodi gestiti
### Interruzioni esterne del riavvio
Se il sistema sul nodo avvia un riavvio durante l'installazione della patch (ad esempio, per applicare aggiornamenti al firmware o funzionalità simili SecureBoot), l'esecuzione del documento di applicazione delle patch potrebbe essere interrotta e contrassegnata come fallita anche se le patch sono state installate correttamente. Ciò si verifica perché l'agente SSM non può persistere e riprendere lo stato di esecuzione del documento dopo riavvii esterni.
Per verificare lo stato di installazione delle patch dopo un'esecuzione non riuscita, esegui un'operazione di `Scan` patch, quindi controlla i dati di conformità delle patch in Patch Manager per valutare lo stato di conformità corrente.
# 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.
# Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineAssociation`
Come il documento `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` esegue operazioni di applicazione di patch sulle istanze per aggiornamenti correlati alla sicurezza e di altro tipo. È possibile utilizzare il documento `AWS-RunPatchBaselineAssociation` 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 le istanze Amazon Elastic Compute Cloud (Amazon EC2) per Linux, macOS, e Windows Server. Non supporta nodi non EC2 in un ambiente [ibrido e multicloud](operating-systems-and-machine-types.md#supported-machine-types). Il documento eseguirà le azioni appropriate per ogni piattaforma, richiamando un modulo Python su Linux macOS e istanze e PowerShell un modulo su istanze Windows.
`AWS-RunPatchBaselineAssociation`, tuttavia, differisce da `AWS-RunPatchBaseline` nei seguenti modi:
+ `AWS-RunPatchBaselineAssociation` è destinato all'uso principalmente con associazioni State Manager create utilizzando [Quick Setup](systems-manager-quick-setup.md), uno strumento di AWS Systems Manager. In particolare, quando utilizzi il tipo di configurazione di gestione host Quick Setup, scegliendo l'opzione **Scan instances for missing patches daily** (Scansiona le istanze per le patch mancanti ogni giorno), il sistema utilizza `AWS-RunPatchBaselineAssociation` per l'operazione.
Nella maggior parte dei casi, tuttavia, quando si impostano le proprie operazioni di patch, è necessario scegliere [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) o [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) invece di `AWS-RunPatchBaselineAssociation`.
+ Quando utilizzi il documento `AWS-RunPatchBaselineAssociation`, è possibile specificare una coppia di chiavi di tag nel campo parametro `BaselineTags` del documento. Se una patch di base personalizzata Account AWS condivide questi tagPatch Manager, uno strumento in AWS Systems Manager uso utilizza quella baseline con tag quando viene eseguita sulle istanze di destinazione anziché la baseline di patch «predefinita» attualmente specificata per il tipo di sistema operativo.
**Nota**
Quando si sceglie di utilizzare `AWS-RunPatchBaselineAssociation` nelle operazioni di applicazione di patch diverse da quelle configurate con Quick Setup, e si desidera utilizzare il suo parametro `BaselineTags` opzionale, è necessario fornire alcune autorizzazioni aggiuntive al [profilo dell'istanza](setup-instance-permissions.md) per istanze Amazon Elastic Compute Cloud (Amazon EC2). Per ulteriori informazioni, consulta [Nome parametro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).
Entrambi i formati seguenti sono validi per il parametro `BaselineTags`:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Importante**
Le chiavi e i valori dei tag non consentono la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1).
+ Quando viene eseguito `AWS-RunPatchBaselineAssociation`, i dati di conformità delle patch raccolti vengono registrati utilizzando il comando API di `PutComplianceItems` al posto del comando `PutInventory`, che viene utilizzato da `AWS-RunPatchBaseline`. Questa differenza indica che le informazioni sulla conformità delle patch che vengono archiviate e segnalate per una specifica *associazione*. I dati di conformità delle patch generati al di fuori di questa associazione non vengono sovrascritti.
+ Le informazioni sulla conformità delle patch riportate dopo l'esecuzione di `AWS-RunPatchBaselineAssociation`indicano se un'istanza è conforme o meno. Non include dettagli a livello di patch, come dimostra l'output del comando seguente (). AWS Command Line Interface AWS CLI Il comando filtra su `Association` come tipo di conformità:
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
Il sistema restituisce informazioni simili alle seguenti.
```
{
"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"
}
]
}
```
Quando un valore di una coppia di chiavi di tag è stato specificato come parametro per il documento `AWS-RunPatchBaselineAssociation`, Patch Manager cerca una baseline delle patch personalizzata che corrisponda al tipo di sistema operativo ed è stata contrassegnata con la stessa coppia di chiavi di tag. Questa ricerca non è limitata alla baseline delle patch predefinita corrente specificata o alla base assegnata a un gruppo di patch. Quando non viene trovata alcuna baseline con i tag specificati, Patch Manager cerca un gruppo di patch, se ne è stato specificato uno nel comando che esegue `AWS-RunPatchBaselineAssociation`. Quando nessun gruppo di patch viene abbinato, Patch Manager torna alla baseline delle patch predefinita corrente per l'account del sistema operativo.
Quando viene trovata più di una baseline delle patch con i tag specificati nel documento`AWS-RunPatchBaselineAssociation`, Patch Manager restituisce un messaggio di errore che indica che solo una baseline delle patch ha la possibilità di essere contrassegnata con quel valore di chiave in modo che l'operazione continui.
**Nota**
Sui nodi Linux, il gestore di pacchetti idonei per ogni tipo di nodo viene utilizzato per installare i pacchetti:
Amazon Linux 2, Oracle Linux e le istanze RHEL 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).
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).
Al termine di una scansione, o dopo che tutti gli aggiornamenti approvati e applicabili sono stati installati, con eventuali riavvii eseguiti, le informazioni sulla conformità delle patch sono generate su un'istanza e riportate al servizio Patch Compliance.
**Nota**
Quando il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaselineAssociation`, l'istanza non viene riavviata dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-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-RunPatchBaselineAssociation`
`AWS-RunPatchBaselineAssociation` supporta cinque parametri. I parametri `Operation` e `AssociationId` sono obbligatori. I parametri `InstallOverrideList`, `RebootOption` e `BaselineTags` sono facoltativi.
**Topics**
+ [Nome parametro: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Nome parametro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Nome parametro: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Nome parametro: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### Nome parametro: `Operation`
**Utilizzo**: obbligatorio.
**Opzioni**: `Scan` \$1 `Install`.
Scan
Quando si sceglie l'opzione `Scan`, `AWS-RunPatchBaselineAssociation` determina lo stato di conformità delle patch dell'istanza e riferisce queste informazioni a Patch Manager. `Scan` non richiede l'installazione degli aggiornamenti o il riavvio delle istanze. L'operazione identifica dove gli aggiornamenti approvati e applicabili all'istanza risultano mancanti.
Installa
Quando si sceglie l'opzione `Install`, `AWS-RunPatchBaselineAssociation` tenta di installare gli aggiornamenti applicabili e approvati che risultano mancanti nell'istanza. Le informazioni sulla conformità delle patch generate in un'operazione `Install` non visualizzano gli aggiornamenti mancanti, ma possono specificare lo stato di errore degli aggiornamenti se per qualsiasi motivo l'installazione non è andata a buon fine. Quando un aggiornamento è installato in un'istanza, questa viene riavviata per assicurare l'aggiornamento sia installato e attivo. (Eccezione: se il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaselineAssociation`, l'istanza non viene riavviata dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta[Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)).
Se una patch specificata dalle regole di baseline viene installata *prima* Patch Manager dell'aggiornamento dell'istanza di Gestione patch, è 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: `BaselineTags`
**Utilizzo**: facoltativo.
`BaselineTags` è un un key value di tag univoco, scelto e assegnato a una baseline delle patch personalizzata. È possibile specificare uno o più valori per questo parametro. Sono validi entrambi dei seguenti formati:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Importante**
Le chiavi e i valori dei tag non consentono la presenza dei seguenti caratteri: backtick (`), virgolette singole ('), virgolette doppie (“) e simbolo del dollaro (\$1).
Il valore `BaselineTags` è utilizzato da Patch Manager per assicurare che una serie di istanze a cui vengono applicate le patch in un'unica operazione abbiano la stessa serie di patch approvate. Quando viene eseguita l'operazione di patch, Patch Manager controlla se una baseline delle patch per il tipo di sistema operativo è contrassegnata con la stessa coppia di key value per `BaselineTags`. Se c'è una corrispondenza, viene utilizzata questa baseline delle patch personalizzata. Se non esiste una corrispondenza, una baseline delle patch viene identificata in base a qualsiasi gruppo di patch specificato per l'operazione di applicazione di patch. Se non ce ne sono, viene utilizzata la linea di base delle patch predefinite AWS gestite per quel sistema operativo.
**Requisiti di permesso aggiuntivi**
Se utilizzi `AWS-RunPatchBaselineAssociation` nelle operazioni di applicazione di patch diverse da quelle configurate utilizzando Quick Setup, e desideri utilizzare l'opzione opzionale `BaselineTags`, è necessario aggiungere le seguenti autorizzazioni al [profilo dell'istanza](setup-instance-permissions.md) per istanze Amazon Elastic Compute Cloud (Amazon EC2).
**Nota**
Quick Setupe `AWS-RunPatchBaselineAssociation` non supportano server e macchine virtuali locali (). VMs
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
Sostituisci *patch-baseline-arn* con l'Amazon Resource Name (ARN) della patch di base a cui desideri fornire l'accesso, nel formato. `arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`
### Nome parametro: `AssociationId`
**Utilizzo**: obbligatorio.
`AssociationId` è l'ID di un'associazione esistente in State Manager, uno strumento di AWS Systems Manager. È usato da Patch Manager per aggiungere i dati di conformità a un'associazione specificata. Questa associazione è correlata a un'operazione `Scan` di patch abilitata in una [configurazione di gestione host creata in Quick Setup](quick-setup-host-management.md). Inviando i risultati delle patch come dati di conformità dell'associazione anziché come dati di conformità dell'inventario, le informazioni sulla conformità dell'inventario esistenti per le tue istanze non vengono sovrascritte dopo un'operazione di patch o per altre associazioni. IDs 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). Esempio:
------
#### [ 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
```
------
### Nome parametro: `InstallOverrideList`
**Utilizzo**: facoltativo.
Utilizzando `InstallOverrideList`, è possibile specificare un URL https o un URL in stile percorso Amazon Simple Storage Service (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 nelle istanze.
**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.
**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.
+ **Esempio di formato URL https**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Esempio di 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 dell'istanza. 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”.
+ Microsoft Windows
**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.
+ 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/Red Hat Enterprise Linux (RHEL):
```
{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 nell'istanza, 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
**Altri campi**
Tutti gli altri campi che intendi fornire in un elenco di patch per Linux sono facoltativi e hanno unicamente scopo informativo. È possibile utilizzare altri campi, come **classification**, **severity** o qualsiasi altro per fornire informazioni più dettagliate sulle patch specificate.
**Elenchi di patch di esempio**
+ **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'
```
### 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 le istanze vengano riavviate immediatamente per completare un processo di configurazione, scegli `RebootIfNeeded`. Oppure, quando è necessario mantenere la disponibilità delle istanze fino a un orario di riavvio pianificato, scegli `NoReboot`.
**Importante**
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.
**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`, l'istanza viene riavviata 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 delle istanze 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 l'istanza anche se ha installato patch durante l'operazione di `Install` Questa opzione è utile se le istanze non richiedono il riavvio dopo l'applicazione di patch, oppure nel caso di applicazioni o processi in esecuzione su un'istanza che non dovrebbero essere interrotti da un riavvio a seguito di un'operazione di applicazione di patch. È utile anche quando vuoi un maggiore controllo sui tempi dei riavvii dell'istanza, ad esempio utilizzando una finestra 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 nell'istanza gestita.
**Importante**
Non eliminare o modificare il file di monitoraggio. Quando questo file viene eliminato o danneggiato, il rapporto di conformità della patch per l'istanza non è accurato. In questo caso, riavvia l'istanza ed esegui un'operazione di scansione della patch per ripristinare il file.
Questo file di monitoraggio viene archiviato nei seguenti percorsi nelle istanze gestite:
+ 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`
# Documento di comando SSM per l'applicazione di patch: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager supporta`AWS-RunPatchBaselineWithHooks`, 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.
`AWS-RunPatchBaselineWithHooks` differisce da `AWS-RunPatchBaseline` nei seguenti modi:
+ **Un documento wrapper** – `AWS-RunPatchBaselineWithHooks` è un wrapper per `AWS-RunPatchBaseline` e si basa su `AWS-RunPatchBaseline` per alcune delle sue operazioni.
+ **L'operazione `Install` ** – `AWS-RunPatchBaselineWithHooks` supporta gli hook del ciclo di vita che vengono eseguiti in punti designati durante l'applicazione di patch del nodo gestito. Poiché le installazioni di patch a volte richiedono il riavvio dei nodi gestiti, l'operazione di applicazione di patch è suddivisa in due eventi, per un totale di tre hook che supportano funzionalità personalizzate. Il primo hook è prima dell'operazione `Install with NoReboot`. Il secondo hook è dopo dell'operazione `Install with NoReboot`. Il terzo hook è disponibile dopo il riavvio del nodo gestito.
+ **Nessun supporto per l'elenco di patch personalizzato** – `AWS-RunPatchBaselineWithHooks` non supporta il parametro di `InstallOverrideList`.
+ **Il supportoSSM Agent** – `AWS-RunPatchBaselineWithHooks`richiede che SSM Agent 3.0.502 o versione successiva deve essere installata sul nodo gestito di patch.
Quando il documento viene eseguito, utilizza la baseline delle patch attualmente specificata come “predefinita” per un tipo di sistema operativo se non è specificato alcun gruppo di patch. In caso contrario, vengono utilizzate le baseline delle patch associate al gruppo di patch. Per informazioni sui gruppi di patch, consulta [Gruppi di patch](patch-manager-patch-groups.md).
È possibile utilizzare il documento `AWS-RunPatchBaselineWithHooks` 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 i nodi gestiti da Linux e Windows Server. Il documento eseguirà le operazioni adeguate per ciascuna piattaforma.
**Nota**
`AWS-RunPatchBaselineWithHooks` non è supportato su macOS.
------
#### [ Linux ]
Nei nodi gestiti Linux, il documento `AWS-RunPatchBaselineWithHooks` 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).
------
#### [ Windows Server ]
Nei nodi Windows Server gestiti, il `AWS-RunPatchBaselineWithHooks` 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à.
------
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 tre 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.
Se il parametro `RebootOption` è impostato su `NoReboot` nel documento `AWS-RunPatchBaselineWithHooks`, il nodo gestito non viene riavviata dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
**Importante**
Sebbene l'opzione di `NoReboot` impedisca il riavvio del sistema operativo, non impedisce i riavvii a livello di servizio, che potrebbero verificarsi quando determinati pacchetti vengono aggiornati. Ad esempio, l'aggiornamento di pacchetti come Docker può attivare il riavvio automatico dei servizi dipendenti (come i servizi di orchestrazione dei container), anche quando `NoReboot` viene specificato.
Per informazioni sulla visualizzazione dei dati di conformità delle patch, consulta [Informazioni sulla conformità delle patch](compliance-about.md#compliance-monitor-patch).
## Fasi operative di `AWS-RunPatchBaselineWithHooks`
Quando `AWS-RunPatchBaselineWithHooks` è in esecuzione, vengono portati a termine i seguenti passaggi:
1. **Scan**- Un'operazione di `Scan` utilizzando `AWS-RunPatchBaseline` viene eseguita sul nodo gestito e viene generato e caricato un report di conformità.
1. **Verificare gli stati delle patch locali** - Viene eseguito uno script per determinare quali passaggi verranno eseguiti in base all'operazione selezionata e al risultato di `Scan` della fase 1.
1. Se l'operazione selezionata è `Scan`, essa è contrassegnata come completata. L'operazione si conclude.
1. Se l'operazione selezionata è `Install`, Patch Manager valuta il risultato di `Scan` dal Passaggio 1 per determinare cosa eseguire dopo:
1. Se non vengono rilevate patch mancanti e non sono necessari riavvii in sospeso, l'operazione procede direttamente al passaggio finale (Passaggio 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati.
1. Se non vengono rilevate patch mancanti, ma sono necessari riavvii in sospeso e l'opzione di riavvio selezionata è `NoReboot`, l'operazione procede direttamente alla fase finale (Step 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati.
1. Altrimenti, l'operazione passa alla fase successiva.
1. **Funzionamento con hook pre-patch**: il documento SSM fornito per il primo hook del ciclo di vita, `PreInstallHookDocName`, viene eseguito sul nodo gestito.
1. **Installa con NoReboot**: sul nodo gestito viene eseguita un'`Install`operazione con l'opzione di `NoReboot` riavvio utilizzata e `AWS-RunPatchBaseline` viene generato e caricato un rapporto di conformità.
1. **Operazione hook post-installazione**: il documento SSM fornito per il secondo hook del ciclo di vita, `PostInstallHookDocName`, viene eseguito sul nodo gestito.
1. **Verifica del riavvio** - Viene eseguito uno script per determinare se è necessario un riavvio per il nodo gestito e quali passaggi eseguire:
1. Quando l'opzione di riavvio selezionata è `NoReboot`, essa procede direttamente alla fase finale (Step 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati.
1. Quando l'opzione di riavvio selezionata è `RebootIfNeeded`, Patch Manager verifica se sono necessari riavvii in sospeso dall'inventario raccolto al passaggio 4. Ciò significa che l'operazione continua nella fase 7 e il nodo gestito viene riavviato in uno dei seguenti casi:
1. Patch Manager ha installato una 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.)
1. Patch Manager rileva una o più patch con lo stato di `INSTALLED_PENDING_REBOOT` durante l'operazione di installazione. Lo stato `INSTALLED_PENDING_REBOOT` indica che l'opzione `NoReboot` è stata selezionata l'ultima volta che l'operazione di installazione è stata eseguita, o che una patch è stata installata all'esterno di Patch Manager dall'ultimo riavvio del nodo gestito.
Quando non vengono rilevate patch che rispondono a questi criteri, l'operazione di applicazione della patch del nodo gestito viene completata e si passa direttamente alla fase finale (passaggio 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati.
1. **Riavvio e report** - Un'operazione di installazione con l'opzione di riavvio di `RebootIfNeeded` viene eseguito sul nodo gestito utilizzando `AWS-RunPatchBaseline` e viene generato e caricato un report sulla conformità.
1. **Operazione hook post-riavvio**: il documento SSM fornito per il terzo hook del ciclo di vita, `OnExitHookDocName`, viene eseguito sul nodo gestito.
Per un'operazione `Scan`, se il Passaggio 1 non va a buon fine, il processo di esecuzione del documento si interrompe e il passaggio viene segnalato come non andato a buon fine, anche se i passaggi successivi vengono segnalati come esito positivo.
Per un'operazione `Install`, se uno qualsiasi dei passaggi `aws:runDocument` non va a buon fine durante l'operazione, tali passaggi vengono segnalati come non andati a buon fine e l'operazione procede direttamente al Passaggio finale (Passaggio 8), che include un hook fornito. Tutti i passaggi intermedi vengono saltati. Questo passaggio viene segnalato come non andato a buon fine, l'ultimo passaggio riporta lo stato del risultato dell'operazione e tutti i passaggi intermedi vengono segnalati come esito positivo.
## Parametri di `AWS-RunPatchBaselineWithHooks`
`AWS-RunPatchBaselineWithHooks` supporta sei parametri.
Il parametro `Operation` è obbligatorio.
I parametri `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` e `OnExitHookDocName` sono facoltativi.
`Snapshot-ID` è tecnicamente facoltativo, ma è consigliabile fornire un valore personalizzato per esso quando si esegue `AWS-RunPatchBaselineWithHooks` al di fuori di una finestra di manutenzione. Consenti a Patch Manager di fornire il valore automaticamente quando il documento viene eseguito nell'ambito di un'operazione di manutenzione.
**Topics**
+ [Nome parametro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nome parametro: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nome parametro: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nome parametro: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nome parametro: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### Nome parametro: `Operation`
**Utilizzo**: obbligatorio.
**Opzioni**: `Scan` \$1 `Install`.
Scan
Quando si sceglie l'opzione `Scan`, il sistema utilizza il documento `AWS-RunPatchBaseline` per determinare lo stato di conformità delle patch dell'istanza 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-RunPatchBaselineWithHooks` 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-RunPatchBaselineWithHooks`, il nodo non viene riavviato dopo l'esecuzione di Patch Manager. Per ulteriori informazioni, consulta [Nome parametro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-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: `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-RunPatchBaselineWithHooks` sia o meno in esecuzione in una finestra di manutenzione, come descritto nella seguente tabella.
**Best practice di `AWS-RunPatchBaselineWithHooks`**
| Modalità | Best practice | Informazioni |
| --- | --- | --- |
| In esecuzione AWS-RunPatchBaselineWithHooks 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-RunPatchBaselineWithHooks`, 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-RunPatchBaselineWithHooks` 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-RunPatchBaselineWithHooks 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-RunPatchBaselineWithHooks`, ti consigliamo di generare e specificare un ID snapshot univoco per ogni baseline delle patch, soprattutto se stai eseguendo il documento `AWS-RunPatchBaselineWithHooks` 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. Ad esempio, potresti eseguire il documento `AWS-RunPatchBaselineWithHooks` 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 gestiti, 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: `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 diventa `Compliant`.
**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: `PreInstallHookDocName`
**Utilizzo**: facoltativo.
**Default**: `AWS-Noop`
Il valore da fornire per il parametro `PreInstallHookDocName` è il nome o l'Amazon Resource Name (ARN) di un documento SSM di tua scelta. Puoi fornire il nome di un documento AWS gestito o il nome o l'ARN di un documento SSM personalizzato che hai creato o che è stato condiviso con te. (Per un documento SSM che è stato condiviso con te da un altro Account AWS, devi specificare l'ARN completo della risorsa, ad esempio`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)
Il documento SSM specificato viene eseguito prima dell'operazione `Install` esegue tutte le operazioni supportate da SSM Agent, ad esempio uno script di shell per controllare il controllo dell'integrità dell'applicazione prima che venga eseguita l'applicazione di patch sul nodo gestito. Per un elenco di operazioni, consulta [Documentazione di riferimento del plugin per i documenti di comando](documents-command-ssm-plugin-reference.md)). Il nome di default del documento SSM è `AWS-Noop`, che non esegue alcuna operazione sul nodo gestito.
Per informazioni sulla creazione di un documento SSM personalizzato, consulta [Creazione del contenuto del documento SSM](documents-creating-content.md).
### Nome parametro: `PostInstallHookDocName`
**Utilizzo**: facoltativo.
**Default**: `AWS-Noop`
Il valore da fornire per il parametro `PostInstallHookDocName` è il nome o l'Amazon Resource Name (ARN) di un documento SSM di tua scelta. Puoi fornire il nome di un documento AWS gestito o il nome o l'ARN di un documento SSM personalizzato che hai creato o che è stato condiviso con te. (Per un documento SSM che è stato condiviso con te da un altro Account AWS, devi specificare l'ARN completo della risorsa, ad esempio`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)
Il documento SSM specificato viene eseguito dopo l'operazione `Install with NoReboot` ed esegue tutte le azioni supportate da SSM Agent, ad esempio uno script di shell per l'installazione di aggiornamenti di terze parti prima del riavvio. Per un elenco di operazioni, consulta [Documentazione di riferimento del plugin per i documenti di comando](documents-command-ssm-plugin-reference.md)). Il nome di default del documento SSM è `AWS-Noop`, che non esegue alcuna operazione sul nodo gestito.
Per informazioni sulla creazione di un documento SSM personalizzato, consulta [Creazione del contenuto del documento SSM](documents-creating-content.md).
### Nome parametro: `OnExitHookDocName`
**Utilizzo**: facoltativo.
**Default**: `AWS-Noop`
Il valore da fornire per il parametro `OnExitHookDocName` è il nome o l'Amazon Resource Name (ARN) di un documento SSM di tua scelta. Puoi fornire il nome di un documento AWS gestito o il nome o l'ARN di un documento SSM personalizzato che hai creato o che è stato condiviso con te. (Per un documento SSM che è stato condiviso con te da un Account AWS diverso, è necessario specificare l'ARN della risorsa completa, ad esempio `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
Il documento SSM specificato viene eseguito dopo l'operazione di riavvio del nodo gestito ed esegue tutte le operazioni supportate da SSM Agent, ad esempio uno script di shell per verificare l'integrità del nodo dopo il completamento dell'operazione di applicazione di patch. Per un elenco di operazioni, consulta [Documentazione di riferimento del plugin per i documenti di comando](documents-command-ssm-plugin-reference.md)). Il nome di default del documento SSM è `AWS-Noop`, che non esegue alcuna operazione sul nodo gestito.
Per informazioni sulla creazione di un documento SSM personalizzato, consulta [Creazione del contenuto del documento SSM](documents-creating-content.md).
# Scenario di esempio per l'utilizzo del InstallOverrideList parametro in `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`
Usa il parametro `InstallOverrideList`, quando vuoi sovrascrivere le patch specificate dalla baseline delle patch corrente della patch predefinita, in Patch Manager, uno strumento di AWS Systems Manager. In questo argomento vengono forniti esempi che illustrano come utilizzare questo parametro per effettuare le seguenti operazioni:
+ Applicare diversi set di patch a un gruppo target di nodi gestiti.
+ Applicare questi set di patch a frequenze diverse.
+ Utilizzare la stessa baseline delle patch per entrambe le operazioni.
Supponiamo che vuoi installare due diverse categorie di patch nei nodi Amazon Linux 2. Vuoi installare queste patch su pianificazioni diverse utilizzando le finestre di manutenzione. Vuoi eseguire una finestra di manutenzione ogni settimana e installare tutte le patch `Security`. Vuoi eseguire un'altra finestra di manutenzione una volta al mese e installare tutte le patch disponibili o le categorie di patch diverse da `Security`.
Tuttavia, solo una baseline delle patch alla volta può essere specificata come predefinita nel sistema operativo. Questo requisito consente di evitare situazioni in cui una baseline delle patch approva una patch mentre un'altra la blocca, il che può causare problemi tra versioni in conflitto.
Con la seguente strategia, è possibile utilizzare il parametro `InstallOverrideList` per applicare diversi tipi di patch a un gruppo di destinazione in pianificazioni diverse, pur utilizzando la stessa baseline delle patch:
1. Nella baseline delle patch predefinita, assicurati che siano specificati solo gli aggiornamenti `Security`.
1. Crea una prima finestra di manutenzione che esegue `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation` ogni settimana. Non specificare un elenco di sostituzioni.
1. Crea un elenco di sostituzioni delle patch di tutti i tipi che vuoi applicare su base mensile e archivialo in un bucket Amazon Simple Storage Service (Amazon S3).
1. Crea una seconda finestra di manutenzione che viene eseguita una volta al mese. Tuttavia, per l'attività Run Command che vuoi registrare per questa finestra di manutenzione, specifica la posizione dell'elenco di sostituzioni.
Il esito: ogni settimana vengono installate solo le patch `Security`, come definito nella baseline delle patch predefinita. Tutte le patch disponibili, o qualsiasi sottoinsieme di patch che definisci, vengono installate ogni mese.
**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 maggiori informazioni ed esempi, consulta [Nome parametro: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).
# Utilizzo del BaselineOverride parametro
È possibile definire le preferenze di applicazione di patch in fase di runtime utilizzando la funzionalità di sostituzione della baseline in Patch Manager, uno strumento di AWS Systems Manager. Per farlo, specificare un bucket Amazon Simple Storage Service (Amazon S3) contenente un oggetto JSON con un elenco delle baseline delle patch. L'operazione di applicazione di patch utilizza le baseline fornite nell'oggetto JSON che corrispondono al sistema operativo host anziché applicare le regole 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).
Tranne quando un'operazione di patch utilizza una policy di patch, l'utilizzo del parametro `BaselineOverride` non sovrascrive la conformità della patch della baseline fornita nel parametro. I risultati dell'output vengono registrati nei log Stdout da Run Command, uno strumento di AWS Systems Manager. I risultati stampano solo i pacchetti contrassegnati come `NON_COMPLIANT`. Ciò significa che il pacchetto è contrassegnato come `Missing`, `Failed`, `InstalledRejected`, oppure `InstalledPendingReboot`.
Tuttavia, quando un'operazione di patch utilizza una policy di patch, il sistema passa il parametro di sostituzione dal bucket S3 associato e il valore di conformità viene aggiornato per il nodo gestito. Per ulteriori informazioni sul comportamento delle policy di patch, consulta [Configurazioni delle policy di patch in Quick Setup](patch-manager-policies.md).
**Nota**
Quando stai applicando la patch a 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.
## Utilizzo della sostituzione della baseline delle patch con i parametri ID Snapshot o dell'installazione Install Override List
Esistono due casi in cui la sostituzione della baseline delle patch ha un comportamento degno di nota.
**Utilizzo simultaneo della sostituzione della baseline e dell'ID snapshot**
Gli ID snapshot assicurano che tutti i nodi gestiti di un particolare comando di applicazione di patch applichino tutte la stessa cosa. Ad esempio, quando si esegue la patch di 1.000 nodi contemporaneamente, le patch saranno le stesse.
Quando si utilizzano sia un ID snapshot che una sostituzione della baseline delle patch, l'ID snapshot ha la precedenza sulla sostituzione della baseline della patch. Le regole di sostituzione della baseline verranno comunque utilizzate, ma verranno valutate una sola volta. Nell'esempio precedente, le patch tra i 1.000 nodi gestiti saranno sempre le stesse. Se, a metà dell'operazione di applicazione di patch, è stato modificato il file JSON nel bucket S3 di riferimento per essere diverso, le patch applicate saranno comunque le stesse. Questo perché è stato fornito l'ID snapshot.
**Utilizzo simultaneo della sostituzione della baseline e Install Override List**
Non è possibile utilizzare questi due parametri nello stesso momento. Il documento di applicazione di patch non va a buon fine se vengono forniti entrambi i parametri e non esegue alcuna scansione o installazione nel nodo gestito.
## Esempi di codice
Il seguente esempio di codice per Python mostra come generare la sostituzione della baseline delle patch.
```
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)
```
Ciò produce una sostituzione della baseline delle patch simile alla seguente.
```
[
{
"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": []
}
]
```