Il modo in cui vengono calcolate le date di rilascio e di aggiornamento dei pacchetti - AWS Systems Manager

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

Importante

Le informazioni in questa pagina si applicano ai sistemi operativi (OS) di Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 e Amazon Linux 2023 per le istanze di 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 delle patch di base personalizzate create, per la maggior parte dei tipi di sistemi operativi è possibile specificare che le patch vengano approvate automaticamente per l'installazione dopo un certo numero di giorni. AWS fornisce diverse linee di base predefinite per le patch 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 dovuti a ritardi nell'approvazione automatica su Amazon Linux 1, Amazon Linux 2. Amazon Linux 2022 e Amazon Linux 2023, è importante capire il modo in cui vengono calcolate le date di rilascio e 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 nei repository gestiti da AWS, ma può essere poi ripristinato se in seguito vengono rilevati 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.

È 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. Per ulteriori informazioni, consultare Come specificare un repository alternativo di origine delle patch (Linux).