Come specificare un repository alternativo di origine delle patch (Linux)

Quando si utilizzano gli archivi predefiniti configurati su un nodo gestito per le operazioni di patchingPatch Manager, una funzionalità di AWS Systems Manager, scansiona o installa patch relative alla sicurezza. Questo è il comportamento predefinito per Patch Manager. Per informazioni dettagliate sulle modalità in cui Patch Manager seleziona e installa le patch di sicurezza, consulta Come vengono selezionate le patch di sicurezza.

Nei sistemi Linux, tuttavia, puoi anche usare Patch Manager per installare patch non correlate alla sicurezza o che si trovano in un repository di origine diverso da quello di default configurato nel nodo gestito. Puoi specificare repository alternativi di origine delle patch al momento della creazione di una base di patch personalizzata. In ciascuna base di patch personalizzata, puoi specificare le configurazioni di origine delle patch per un massimo di 20 versioni di un sistema operativo Linux supportato.

Ad esempio, supponiamo che il tuo parco istanze Ubuntu Server includa nodi gestiti sia Ubuntu Server 14.04 sia Ubuntu Server 16.04. In questo caso è possibile specificare repository alternativi per ciascuna versione nella stessa base di patch personalizzata. Per ciascuna versione, dovrai specificare un nome, il tipo di versione del sistema operativo (prodotto) e fornire una configurazione del repository. Puoi anche specificare un singolo repository di origine alternativo valido per tutte le versioni di un sistema operativo supportato.

Nota

L'esecuzione di una patch di base personalizzata che specifica repository di patch alternativi per un nodo gestito non li rende i nuovi repository di default del sistema operativo. Al termine dell'operazione di applicazione delle patch, i repository precedentemente definiti come valori predefiniti del sistema operativo del nodo rimangono valori predefiniti.

Per un elenco di scenari di esempio per l'utilizzo di questa opzione, consulta Utilizzi di esempio per repository alternativi di origine delle patch più avanti in questo argomento.

Per informazioni sulle basi di patch predefinite e personalizzate, consulta Informazioni sulle basi di patch predefinite e personalizzate.

Esempio: utilizzo della console

Per specificare repository alternativi di origine delle patch con la console Systems Manager, utilizza la sezione Patch sources (Origini patch) della pagina Create patch baseline (Crea una base di patch) . Per ulteriori informazioni sull'utilizzo delle opzioni Patch sources (Origini patch), consulta Creazione di una patch di base personalizzata (Linux).

Esempio: utilizzo del AWS CLI

Per un esempio di utilizzo dell'opzione --sources con AWS Command Line Interface (AWS CLI), consulta Creazione di una base di patch con repository personalizzati per varie versioni dei sistemi operativi..

Considerazioni importanti sui repository alternativi

Durante la pianificazione della strategia di applicazione di patch con repository alternativi, tieni presente quanto segue:

Per l'applicazione di patch vengono utilizzati solo i repository specificati

La specifica di repository alternativi non comporta l'aggiunta di altri repository. Puoi scegliere di specificare repository diversi da quelli configurati come predefiniti in un nodo gestito. Tuttavia, per fare in modo che vengano applicati i relativi aggiornamenti, dovrai anche specificare i repository predefiniti come parte della configurazione dell'origine delle patch alternativa.

Ad esempio, su tutti i nodi gestiti Amazon Linux 2, i repository di default sono amzn2-core e amzn2extra-docker. Se desideri includere il repository Extra Packages for Enterprise Linux (EPEL) nelle operazioni di applicazione di patch, dovrai specificare tutti i tre repository come repository alternativi.

Nota

L'esecuzione di una patch di base personalizzata che specifica repository di patch alternativi per un nodo gestito non li rende i nuovi repository di default del sistema operativo. Al termine dell'operazione di applicazione delle patch, i repository precedentemente definiti come valori predefiniti del sistema operativo del nodo rimangono valori predefiniti.

Il comportamento dell'applicazione di patch per distribuzioni basate su YUM dipende dal manifest updateinfo.xml

Quando si specificano repository di patch alternativi per distribuzioni basate su Yum, come Amazon Linux 1 o Amazon Linux 2 Red Hat Enterprise Linux o CentOS, il comportamento di applicazione delle patch dipende dal fatto che il repository includa un manifesto di aggiornamento sotto forma di file completo e formattato correttamente. updateinfo.xml Questo file specifica la data di rilascio, le classificazioni e le gravità dei vari pacchetti. Una qualsiasi delle seguenti attività inciderà sul comportamento dell'applicazione di patch:

• Se applichi filtri in base alla classificazione e alla gravità, ma queste non sono specificate in updateinfo.xml, il pacchetto non verrà incluso dal filtro. Ciò significa anche che i pacchetti senza un file updateinfo.xml non saranno inclusi nell'applicazione di patch.

• Se attivi il filtro ApprovalAfterDays, ma la data di rilascio del pacchetto non è in formato Unix Epoch (o non ha una data di rilascio specificata), il pacchetto non verrà incluso dal filtro.

• Si verifica un'eccezione se selezioni la casella di controllo Includi aggiornamenti non critici nella pagina Crea baseline delle patch. In questo caso, i pacchetti senza un file updateinfo.xml (o quelli contenenti questo file senza i valori Classification (Classificazione), Severity (Gravità) e Date (Data) formattati correttamente) saranno inclusi nell'elenco prefiltrato delle patch. Per essere installati, dovranno comunque soddisfare gli altri requisiti delle regole della base di patch.

Utilizzi di esempio per repository alternativi di origine delle patch

Esempio 1 - Aggiornamenti non correlati alla sicurezza per Ubuntu Server

Stai già utilizzando Patch Manager per installare patch di sicurezza su una flotta di nodi Ubuntu Server gestiti utilizzando la linea di base di patch predefinita AWS fornita. AWS-UbuntuDefaultPatchBaseline Puoi creare una nuova base di patch basata su quella predefinita, specificando però nelle regole di approvazione che desideri installare anche aggiornamenti non correlati alla sicurezza che fanno parte della distribuzione predefinita. Quando questa patch di base viene eseguita nei tuoi nodi, vengono applicate le patch sia per le problematiche relative alla sicurezza sia per quelle di altro tipo. Puoi scegliere di approvare le patch non correlate alla sicurezza anche nelle eccezioni specificate per una base.

Esempio 2 - Personal Package Archives (PPA) per Ubuntu Server

I nodi gestiti di Ubuntu Server eseguono un software distribuito tramite un Personal Package Archives (PPA) per Ubuntu. In questo caso, devi creare una patch di base che specifichi un repository PPA configurato nei nodi gestiti come repository di origine per l'applicazione di patch. Potrai quindi usare Run Command per eseguire il documento della patch di base nei nodi.

Esempio 3 - Applicazioni aziendali interne in Amazon Linux

Nei nodi gestiti Amazon Linux, devi eseguire alcune applicazioni necessarie per la conformità normativa del settore. Puoi configurare un repository per queste applicazioni nei nodi, utilizzare YUM per installare inizialmente le applicazioni, quindi aggiornare o creare una nuova patch di base per includere il nuovo repository aziendale. Successivamente, potrai utilizzare Run Command per eseguire il documento AWS-RunPatchBaseline con l'opzione Scan per assicurarti che il pacchetto aziendale sia elencato tra quelli installati e sia aggiornato nel nodo gestito. Se non è aggiornato, puoi eseguire nuovamente il documento con l'opzione Install per aggiornare le applicazioni.