Come specificare un repository alternativo di origine delle patch (Linux)
Quando usi i repository configurati in modalità predefinita in un nodo gestito per le operazioni di applicazione di patch, Patch Manager, uno strumento di AWS Systems Manager, verifica o installa le patch correlate 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, è possibile 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. È possibile specificare repository alternativi di origine delle patch al momento della creazione di una baseline delle patch personalizzata. In ciascuna baseline delle patch personalizzata, è possibile 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 anche nodi Ubuntu Server 25.04 gestiti. In questo caso è possibile specificare repository alternativi per ciascuna versione nella stessa base di patch personalizzata. Per ciascuna versione, sarà necessario specificare un nome, il tipo di versione del sistema operativo (prodotto) e fornire una configurazione del repository. È possibile 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 di 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 Baseline delle 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 baseline delle patch) . Per ulteriori informazioni sull'utilizzo delle opzioni Patch sources (Origini patch), consulta Creazione di una baseline delle patch personalizzata per Linux.
Esempi: utilizzando l'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.
Argomenti
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. È possibile 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 di 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 manifesto updateinfo.xml
Quando specifichi repository di batch alternativi per distribuzioni basate su YUM, come Amazon Linux 2, oppure Red Hat Enterprise Linux, il comportamento dell'applicazione di patch varia a seconda che il repository includa o meno un manifesto di aggiornamento sotto forma di un file updateinfo.xml completo e correttamente formattato. 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 fileupdateinfo.xmlnon saranno inclusi nell'applicazione di patch. -
Se applichi i filtri in base a ApprovalAfterDays, ma la data di rilascio del pacchetto di rilascio non è in formato Epoch Unix o non è stata specificata la data di rilascio, il pacchetto non sarà incluso nel 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 le patch di sicurezza in un parco istanze di nodi gestiti di Ubuntu Server con la AWS baseline delle patch predefinita fornita da AWS-UbuntuDefaultPatchBaseline. È possibile creare una nuova baseline delle 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. È possibile 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
Esempio 3: applicazioni aziendali interne in versioni Amazon Linux supportate
Nei nodi gestiti Amazon Linux, devi eseguire alcune applicazioni necessarie per la conformità normativa del settore. È possibile configurare un repository per queste applicazioni nei nodi, utilizzare YUM per installare inizialmente le applicazioni, quindi aggiornare o creare una nuova baseline delle patch 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, è possibile eseguire nuovamente il documento con l'opzione Install per aggiornare le applicazioni.
