Domande frequenti sulle AMI Amazon Linux

D: Cos'è l'AMI Amazon Linux?

L'AMI Amazon Linux è un'immagine Linux completa di supporto e manutenzione fornita da Amazon Web Services per l'uso con Amazon Elastic Compute Cloud (Amazon EC2). È progettata per fornire un ambiente stabile, sicuro e ad alte prestazioni per applicazioni in esecuzione su Amazon EC2. Include pacchetti che consentono di integrarla con facilità con AWS, tra cui strumenti per la configurazione di avvio e diverse librerie e tool di AWS tra i più utilizzati. Amazon Web Services fornisce aggiornamenti di protezione e manutenzione a tutte le istanze che eseguono l'AMI Amazon Linux. Le AMI Amazon Linux sono disponibili senza alcun costo aggiuntivo per gli utenti di Amazon EC2.

D: Amazon fornisce supporto per le AMI Amazon Linux?

Sì. Le AMI Amazon Linux sono supportate tramite abbonamento ad AWS Support. Per ulteriori informazioni, consulta la pagina di supporto AWS.

D: Per quanto tempo saranno supportate le AMI Amazon Linux?

L'AMI Amazon Linux (chiamata anche Amazon Linux 1) ha raggiunto la fine del ciclo di vita il 31 dicembre 2023. Amazon Linux AMI non riceverà aggiornamenti di sicurezza o correzioni di bug a partire dal 1° gennaio 2024.

D: Qual è la differenza tra il "Supporto per la manutenzione" e il periodo di assistenza standard?

Il supporto per la manutenzione si riferisce all'arco di tempo successivo al termine dell'assistenza standard per le AMI Amazon Linux. Il supporto per la manutenzione ha prolungato l'assistenza dal 31 dicembre 2020 al 31 giugno 2023. In questo arco di tempo, AWS non aggiungerà più supporti per nuovi tipi di istanze EC2, nuovi servizi e funzionalità AWS o nuovi pacchetti. AWS fornirà, invece, aggiornamenti esclusivamente per correzioni di sicurezza importanti o critiche che si applicano a un set limitato di pacchetti. Inoltre, durante il periodo di "Supporto per la manutenzione", alcuni pacchetti presenti nelle AMI e i relativi repository diventeranno lentamente obsoleti, come indicato nelle pratiche relative alla fine dell'upstream.

D: Qual è l'elenco dei pacchetti che disporrà di patch sulla sicurezza critiche o importanti durante il periodo "Supporto per la manutenzione"?

AWS fornirà aggiornamenti importanti o critici sulla sicurezza ai kernel Linux presenti nella AMI e a tutti i pacchetti, a esclusione di quelli con spazio utente obsoleto.

D: Quali pacchetti non riceveranno più gli aggiornamenti durante il periodo "Supporto per la manutenzione"?

Durante la finestra di manutenzione, tutti i pacchetti (al di fuori delle librerie con spazio utente di basso livello) che hanno raggiunto la fine della vita delle fonti upstream non riceveranno più gli aggiornamenti.

I seguenti pacchetti sono obsoleti dalla versione originale 2018.03 e non riceveranno ulteriori aggiornamenti come parte del periodo di supporto per la manutenzione:

MySQL 5.1
PHP 5.3
PHP 5.4
PHP 5.5
PHP 7.0
PostgreSQL 8
Python 2.6
Ruby 1.8
Ruby 1.9
Ruby 2.1
Ruby 2.2

Inoltre, i seguenti pacchetti non riceveranno ulteriori aggiornamenti come parte del supporto per la manutenzione e sono a fine vita:

Tutti i pacchetti compatibili
BZR - (pacchetti bzr-python26 e bzr-python27)
Ganglia
Mercurial
MySQL 5.5
Python 3.4 (python34)
Python 3.5 (python35)
PostgreSQL 9.3 (postgresql93)
PHP 7.1
PHP 7.2
Tomcat 7
Tomcat 8
Ruby 2.3
Ruby 2.4
PostgreSQL 9.4
Puppet 2.7.x (puppet)
Puppet 3.7.x (puppet3)
Versione secondaria 1.9
Trasmissione
OpenJDK 1.7.0 (java-1.7.0-openjdk)

Inoltre, altri pacchetti che smetteranno di ricevere aggiornamenti durante il periodo di manutenzione sono:

A causa della natura delle dipendenze RPM e del modo in cui uno di questi pacchetti di primo livello può essere composto da diversi RPM, è disponibile un elenco completo di tutti i pacchetti RPM in Amazon Linux 1 e le relative date di fine vita qui.

D: Posso avviare le AMI Amazon Linux quando è terminato il periodo di supporto per la manutenzione?

Sì. Se questa policy dovesse subire delle modiche, lo comunicheremo per tempo.

D: Le AMI Amazon Linux sono supportate anche al di fuori di EC2?

No. Le AMI Amazon Linux sono disponibili solamente all'interno di Amazon EC2.

D: È possibile visionare il codice sorgente di un'AMI Amazon Linux?

Sì. Lo strumento a riga di comando yumdownloader --source fornito nell'AMI Amazon Linux consente di visionare il codice sorgente all'interno di Amazon EC2.

D: Da dove è possibile aggiornare un'AMI Amazon Linux?

Gli aggiornamenti vengono forniti tramite un repository yum preconfigurato in hosting in ciascuna regione in cui è disponibile Amazon EC2. Gli aggiornamenti di sicurezza vengono applicati automaticamente all'avvio dell'AMI. All'accesso, la funzione Message of the Day (/etc/motd) consente di capire se sono disponibili ulteriori aggiornamenti.

D: Come si segnalano i bug e si effettua la richiesta di funzionalità o pacchetti?

È disponibile un forum di discussione su Amazon EC2 nel quale è possibile segnalare bug e richiedere funzionalità e pacchetti. Questi forum sono monitorati dagli sviluppatori di AWS Support e dal team responsabile delle AMI Amazon Linux.
 

D: Come si abilita il repository Extra Packages for Enterprise Linux (EPEL)?

È necessario modificare /etc/yum.repos.d/epel.repo. Nella sezione contrassegnata come [epel] , modifica enabled=0 in enabled=1.

Per attivare temporaneamente il repository EPEL 6, usa l'opzione della riga di comando yum --enablerepo=epel.

Nota: i repository di AMI Amazon Linux sono configurati con priorità maggiori rispetto ai repository di terze parti. Questo perché molti pacchetti che fanno parte dell'AMI Amazon Linux sono contenuti anche in repository di terze parti e vogliamo assicurarci che sia installata di default la versione dell'AMI Amazon Linux.

D: Come si blocca l'AMI in uso su una versione specifica?

La struttura del repository dell'AMI Amazon Linux viene configurata in modo da fornire un flusso continuo di aggiornamenti per passare da una versione di AMI Amazon Linux a quella successiva.

Gli aggiornamenti dei pacchetti vengono sempre caricati nei repository e sono disponibili in qualsiasi versione di AMI Amazon Linux configurata per indirizzare alla versione più recente di yum. Puoi visionare verso quali repository indirizza un'istanza consultando la variabile "releasever" in /etc/yum.conf; di default, l'impostazione di un'AMI Amazon Linux è releasever=latest.

In altre parole, le AMI Amazon Linux vengono trattate come snapshot nel tempo con una struttura di repository e di aggiornamento che fornisce i pacchetti più recenti che abbiamo creato e caricato nel repository.

La funzione "lock on launch" offre un modo semplice per mantenere le AMI in una determinata versione principale, nel caso i clienti non desiderino ricevere pacchetti di aggiornamenti ogni volta che pubblichiamo una versione principale di AMI Amazon Linux.

Per abilitare questa funzione nelle nuove istanze, è possibile ad esempio avviare un'AMI Amazon Linux 2015.09 con i seguenti dati utente su cloud-init, tramite la console EC2 oppure tramite il comando aws ec2 run-instancescon il flag --user-data (è valido anche il comando ec2-run-instances -f).
#cloud-config
repo_releasever: 2015.09

Per bloccare le istanze esistenti alla versione corrente (indicata in /etc/system-release), modifica /etc/yum.conf. Commenta la riga in cui sono contenuti i termini releasever=latest ed esegui yum clean all per svuotare la cache.

NOTA: se un'AMI viene bloccata su una versione dei repository che non è la più recente, non riceverai più alcun aggiornamento. L'unico modo per continuare a ricevere il flusso continuo di aggiornamenti per un'AMI Amazon Linux è utilizzare l'AMI più recente o aggiornare la vecchia versione con i repository indirizzati alla più recente.

D: Come si disabilita l'installazione automatica di aggiornamenti di sicurezza critici o importanti all'avvio dell'AMI?

Al primo avvio, prima ancora che vengano avviati altri servizi (ad esempio SSH), l'AMI Amazon Linux installa dai repository di pacchetti gli aggiornamenti di sicurezza degli spazi utente segnalati come "critici" o "importanti".

Se l'AMI non può accedere ai repository yum, si verificherà un timeout e saranno eseguiti diversi tentativi prima di completare la procedura di avvio. Questa situazione può verificarsi se ad esempio le impostazioni del firewall o di VPC sono troppo restrittive e impediscono all'AMI Amazon Linux di accedere ai repository di pacchetti.

Se si verifica questo problema, è possibile modificare l'ambiente in modo che l'AMI Amazon Linux riesca a collegarsi ai propri repository di pacchetti oppure disabilitare gli aggiornamenti di sicurezza all'avvio.

Per disabilitare gli aggiornamenti di sicurezza all'avvio dalla console di AWS EC2:

Nella pagina "Opzioni istanza avanzate” della procedura guidata di richiesta delle istanze è presente un campo testuale che serve a inviare dati utente relativi all'AMI Amazon Linux. Tali dati possono essere inseriti sotto forma di testo o caricate sotto forma di file. In entrambi i casi, i dati devono essere:
#cloud-config
repo_upgrade: none

Per disabilitare gli aggiornamenti di sicurezza all'avvio dalla riga di comando è sufficiente:

Creare un file di testo con le informazioni elencate in precedenza ed eseguirlo tramite il comando aws ec2 run-instances with the --user-data file://<filename> (è valido anche il comando ec2-run-instances -f).

Per disabilitare gli aggiornamenti di sicurezza durante il raggruppamento di AMI Amazon Linux è sufficiente:

Modificare /etc/cloud/cloud.cfg e cambiare repo_upgrade: security in repo_upgrade: none.

D: Perché quando viene eseguito tramite Cloud Privato Virtuale (VPC - Virtual Private Cloud) senza Internet gateway o istanza NAT, l'avvio del metodo SSH richiede tempi più lunghi?

Vedi la risposta alla domanda precedente.

D: Perché gli array RAID in uso si avviano con il comando /dev/md127 invece che con il comando /dev/md0?

Le nuove versioni di mdadm creano array RAID con superblocchi versione 1.2, che non si associano automaticamente con un dispositivo numerato. Per distinguere le partizioni è necessario impostare un'etichetta per il file system. La maggior parte degli strumenti di creazione di file system utilizzano il flag -L per impostare l'etichetta. Una volta impostata, l'etichetta viene mostrata in base al montaggio o in /etc/fstab con LABEL=[NAME].

Esempio: creazione di un array RAID 0 con un'etichetta.
mdadm --create --verbose /dev/md0 --level=0 --name=0 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 -L RAID0 /dev/md0
mkdir -p /mnt/RAID0
mount LABEL=RAID0 /mnt/RAID0
Esempio: impostazione dell'etichetta per un file system ext[2-4] esistente.
e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

D: Perché il gruppo wheel è stato disabilitato tramite /etc/sudoers, e come lo si riattiva?

Le opzioni predefinite dei sistemi operativi Linux sull'abilitazione dei gruppi wheel per il comando sudo possono variare. A nostro parere, disabilitare di default l'opzione wheel per il comando sudo consente una maggiore sicurezza per l'AMI Amazon Linux.

Questo problema, che può manifestarsi in modi differenti in base al fatto che l'utente abbia o meno la possibilità di impiegare il comando SSH nelle istanze come ec2-user di default e nonché di utilizzare i comandi sudo, può essere aggirato in due modi.

Opzione 1: per gli utenti che non hanno modificato le impostazioni predefinite, è possibile usare il comando SSH sull'istanza come ec2-user e quindi chiamare il comando sudo per ottenere accesso root e modificare il file sudoers per abilitare i gruppi wheel.
Opzione 2: per gli utenti che hanno modificato le impostazioni predefinite o che non possono eseguire comandi sudo da ec2-user a root, consigliamo la seguente procedura:

• Arrestare l'istanza interessata (senza terminarla).
• Distaccare il volume EBS root utilizzando la console EC2 o gli strumenti API di EC2.
• Collegare il volume a un'altra istanza EC2 di cui si dispone di accesso root in remoto.
• Accedere a tale istanza.
• Montare il volume appena collegato.
  sudo mount /dev/xvdf /mnt
• Modificare il file sudoers nel volume collegato e annullare i commenti al gruppo wheel.
  sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
• Smontare il volume.
  sudo umount -d /dev/xvdf
• Scollegare il volume.
• Ricollegare il volume all'istanza arrestata (assicurandosi che il dispositivo coincida con quello pre-distaccamento, di solito /dev/sda1).
• Avviare l'istanza interessata.

D: Perché compaiono caratteri strani come � o â durante la comunicazione con l'AMI Amazon Linux tramite un terminale?

L'AMI Amazon Linux utilizza di default la codifica dei caratteri UTF-8. I terminali client, che non usano la codifica UTF-8, non sempre sono in grado di tradurre correttamente i caratteri UTF-8. Per risolvere il problema, è sufficiente impostare la codifica del terminale in UTF-8:

• Terminale GNOME: dal menu del terminale, seleziona Imposta crittografia dei caratteri, quindi UTF-8.
• PuTTY: clicca col tasto destro sulla barra del titolo per aprire il menu. Quindi seleziona Modifica impostazioni. In Finestra → Traduzione → Set remoto di caratteri, seleziona UTF-8.

D: In /etc/yum.repos.d/amzn*.repo è presente un'opzione report_instanceid. Qual è la sua funzione?

I repository di AMI Amazon Linux sono bucket S3 situati in tutte le regioni. Quando un processo yum su un'istanza scarica pacchetti da questi bucket, vengono registrate le informazioni sulla connessione a S3.
Nel contesto dell'AMI Amazon Linux, l'impostazione report_instanceid=yes consente ai repository di AMI Amazon Linux di memorizzare anche l'id (i-xxxxxxxx) e la regione (ad es. us-west-2) di un'istanza che scarica un pacchetto. In questo modo il team responsabile delle AMI Amazon Linux potrà offrire ai clienti un supporto personalizzato e specifico per le istanze individuali.
L'impostazione report_instanceid=yes è abilitata di default solo per i repository di AMI Amazon Linux.

D: Perché i file di configurazione del repository yum /etc/yum.repos.d/amzn*.repo vengono sovrascritti quando si esegue l'upgrade del pacchetto system-release?

Questi file di configurazione dei repository vengono sovrascritti quando si esegue l'upgrade del pacchetto system-release per assicurare che le istanze riflettano sempre le modifiche alla configurazione del repository yum dell'AMI Amazon Linux.
Per le versioni di AMI Amazon Linux precedenti alla 2014.09:
Questi file vengono generati da cloud-init a partire da modelli situati nel percorso /etc/cloud/templates/amzn-*.repo.tmpl. Le modifiche apportate a questi file di modello sono permanenti.

Per la versione 2014.09 di AMI Amazon Linux e le versioni successive:

I file /etc/yum.repos.d/amzn*.repo impiegano variabili yum per semplificare la comunicazione tra le istanze e i repository geograficamente più prossimi, consentendo di non impiegare più i modelli cloud-init. Le modifiche apportate a questi file saranno conservate in /etc/yum.repos.d/amzn*.repo.rpmsave quando viene eseguito l'upgrade della versione di sistema.

Gli utenti che eseguono l'upgrade alla versione 2014.09 potranno vedere tutte le modifiche apportate ai file /etc/yum.repos.d/amzn*.repo salvate come /etc/yum.repos.d/amzn*.repo.rpmsave.

D: Come si modificano o disattivano i colori delle pagine man?

I colori delle pagine man possono essere configurati in /etc/profile.d/less.sh (bash e zsh) e/etc/profile.d/less.csh (csh). Per disattivarli, è sufficiente rimuovere tutte le righe che iniziano con export LESS_ (bash, zsh) e/o setenv LESS_ (csh).

Come si disabilitano gli audit delle chiamate di sistema sulle istanze pre-2015.09?

Nei nuovi avvii dell'AMI Amazon Linux 2015.09, l'audit delle chiamate di sistema è disabilitato di default. L'audit delle chiamate di sistema aggiunge un certo carico di lavoro per ogni chiamata di sistema e può causare un sensibile calo delle prestazioni, in particolar modo in applicazioni gravose sul disco o sulla rete.

Quando occorre un audit delle chiamate di sistema, è sufficiente individuare e rimuovere (o escludere mediante un commento) la riga seguente in /etc/audit/audit.rules, riavviando quindi il daemon di audit.
-a never,task
Ad esempio (come root):
# auditctl -l
LIST_RULES: task,never
# sed -i.bak -e '/^-a never,task$/ s/^/#/' /etc/audit/audit.rules
# service auditd restart
# auditctl -l
No rules
Se desideri ottenere lo stesso miglioramento delle prestazioni su istanze provenienti da AMI pre-2015.09, aggiungi la stessa riga ( -a never,task ) in /etc/audit/audit.rules, quindi riavvia il daemon. Se stai eseguendo un upgrade e non hai apportato alcuna modifica al file delle regole di audit, puoi semplicemente spostare o copiare il nuovo file di regole di default al percorso /etc/audit/audit.rules
Ad esempio (come root)
# auditctl -l
No rules
# cp -p /etc/audit/rules.d/audit.rules.default /etc/audit/audit.rules
cp: overwrite ‘/etc/audit/audit.rules’?
# service auditd restart
# auditctl -l
LIST_RULES: task,never

D: Sono disponibili esempi di utilizzo di dati utente mime-multipart con cloud-init?

Puoi trovare la documentazione per mime-multipart per cloud-init qui.
Il formato MIME multipart può essere complicato, quindi per generare file multipart ti consigliamo di usare lo strumento write-mime-multipart. Questo strumento si trova nel pacchetto cloud-utils e può essere installato col comando sudo yum install /usr/bin/write-mime-multipart. Si tratta di uno strumento che usa la prima riga di un file per determinare il parametro Content-Type; cloud-init usa questo parametro per stabilire come interpretare il file. Alcuni file di esempio:
#cloud-config
repo_releasever: 2015.09
e
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
Il seguente è un esempio di write-mime-multipart, comprensivo di output:
[ec2-user@ip-172-31-4-37 ~]$ write-mime-multipart repo_releasever-2015.09.cfg ci-was-here.sh
Content-Type: multipart/mixed; boundary="===============6347220379374809187=="
MIME-Version: 1.0
--===============6347220379374809187==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="repo_releasever-2015.09.cfg"
#cloud-config
repo_releasever: 2015.09
--===============6347220379374809187==
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ci-was-here.sh"
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
--===============6347220379374809187==--
Ulteriori informazioni su come usare lo strumento sono disponibili con man write-mime-multipart.

D: Come si configura un endpoint VPC per consentire le connessioni con i repository di un'AMI Amazon Linux?

È possibile accedere ai repository yum all'interno di VPC senza accedere a Internet. La policy dell'endpoint VPC deve consentire il traffico proveniente dal cloud privato virtuale verso i bucket S3 che ospitano i repository dell'AMI Amazon Linux.
Di seguito illustriamo un esempio di policy dell'endpoint VPC utile a tale scopo:
{
"Statement":[
{
"Sid": "Amazon Linux AMI Repository Access",
"Principal": "*"
"Action":[
"s3:GetObject",
],
"Effect":"Allow",
"Resource":"*"
"arn:aws:s3:::packages.*.amazonaws.com/*",
"arn:aws:s3:::repo.*.amazonaws.com/*"
]
}
]
}
Per ulteriori informazioni, consulta la documentazione relativa agli endpoint VPC.