Il modo in cui vengono calcolate le date di rilascio e di aggiornamento dei pacchetti

Importante

Le informazioni in questa pagina si riferiscono ai sistemi operativi (OS) Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 e Amazon Linux 2023 per istanze Amazon Elastic Compute Cloud (Amazon EC2). I pacchetti per questi tipi di sistema operativo sono creati e gestiti da Amazon Web Services. Il modo in cui i produttori di altri sistemi operativi gestiscono pacchetti e repository influisce sul modo in cui vengono calcolate le date di rilascio e di aggiornamento. Per sistemi operativi diversi da Amazon Linux, Amazon Linux 2, Amazon Linux 2022 e Amazon Linux 2023, ad esempio Red Hat Enterprise Linux (RHEL) e SUSE Linux Enterprise Server (SLES), consulta la documentazione del produttore per informazioni sul modo in cui i loro pacchetti vengono aggiornati e mantenuti.

Nelle impostazioni per le baseline di patch personalizzate create, per la maggior parte dei tipi di sistema operativo, è possibile specificare che le patch vengano approvate automaticamente per l'installazione dopo un certo numero di giorni. AWS fornisce diverse linee base di patch predefinite che includono date di approvazione automatica di 7 giorni.

Il ritardo è il numero di giorni di attesa dopo il rilascio della patch, prima che questa venga automaticamente approvata per l'applicazione. Ad esempio, si crea una regola utilizzando la classificazione CriticalUpdates e si configura per un ritardo di approvazione automatica di 7 giorni. Di conseguenza, una nuova patch critica con una data di rilascio o l'ultimo aggiornamento al 7 luglio viene approvata automaticamente il 14 luglio.

Per evitare risultati imprevisti con ritardi di approvazione automatica su Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 e Amazon Linux 2023, è importante capire come vengono calcolate le date di rilascio e le date di aggiornamento.

Nella maggior parte dei casi, il tempo di attesa per l'approvazione automatica prima dell'installazione delle patch viene calcolato in base al valore Updated Date in updateinfo.xml, non al valore Release Date. Di seguito sono riportati dettagli importanti sui calcoli della data:

• Release Date è la data in cui viene rilasciato un avviso. Non significa che il pacchetto sia ancora necessariamente disponibile nei repository associati.

• Update Date è l'ultima data in cui l'avviso è stato aggiornato. Un aggiornamento a un avviso può rappresentare qualcosa di piccolo come aggiornamenti di testo o di descrizione. Non significa che il pacchetto sia stato rilasciato a partire da tale data o che sia ancora necessariamente disponibile nei repository associati.

  Ciò significa che un pacchetto potrebbe avere un valore Update Date del 7 luglio ma non essere disponibile per l'installazione fino al 13 luglio (ad esempio). Supponiamo che, in questo caso, una patch di base che specifichi un ritardo di approvazione automatica di 7 giorni venga eseguita in un'operazione Install il 14 luglio. Dato che il valore Update Date corrisponde a 7 giorni prima della data di esecuzione, le patch e gli aggiornamenti del pacchetto vengono installati il 14 luglio. L'installazione avviene anche se è passato solo 1 giorno da quando il pacchetto risulta disponibile per l'installazione effettiva.

• Un pacchetto con le patch del sistema operativo o dell'applicazione può essere aggiornato più di una volta dopo il rilascio iniziale.

• Un pacchetto può essere rilasciato negli archivi AWS gestiti, ma poi ripristinato se successivamente vengono rilevati dei problemi.

In alcune operazioni di applicazione di patch, questi fattori potrebbero non essere rilevanti. Ad esempio, se una patch di base è configurata per installare una patch con valori di gravità di Low e Medium, e una classificazione di Recommended, qualsiasi ritardo nell'approvazione automatica potrebbe avere un impatto minimo sulle tue operazioni.

Tuttavia, nei casi in cui la tempistica delle patch critiche o con alto livello di gravità è più importante, potrebbe essere opportuno esercitare un maggiore controllo sul momento in cui le patch vengono installate. Il metodo suggerito per questa operazione consiste nell'utilizzare repository alternativi di origine delle patch anziché i repository predefiniti per le operazioni di applicazione di patch su un 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. Per ulteriori informazioni, consulta Come specificare un repository alternativo di origine delle patch (Linux).