D: Cos'è l'AMI Amazon Linux?

Un'AMI Amazon Linux è un'immagine Linux provvista 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 molto 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: È 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 di Amazon EC2. Gli aggiornamenti di sicurezza vengono applicati all'avvio dell'AMI. All'accesso, la funzione Message of the Day (/etc/motd) informa della disponibilità o meno di ulteriori aggiornamenti.

D: Con quale frequenza saranno disponibili gli aggiornamenti per le AMI Amazon Linux?

AMI Amazon Linux è un servizio creato e mantenuto secondo un modello di rilascio continuo. Il servizio va considerato come un unico fiume di pacchetti di cui le immagini AMI non sono altro che snapshot di un determinato istante.

 

Grazie al modello di rilascio continuo, le AMI Amazon Linux e le istanze dei clienti basate su tali AMI supportano, al momento del lancio, tutte le funzionalità più recenti di EC2 e di AWS. In questo modo, AMI Amazon Linux può fungere da punto di riferimento per altri produttori di AMI Linux (sia terze parti sia produttori a valle rispetto ad AMI Amazon Linux) consentendo loro di offrire il supporto per tali funzionalità.

 

Con questo modello di rilascio, i clienti sfruttano più facilmente i miglioramenti in fatto di sicurezza, prestazioni e funzionalità, ottimizzando il funzionamento delle loro soluzioni.

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 AWS Support.

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: Come si segnalano i bug e si richiedono 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 --enablerepro=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. 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 su cloud-init, tramite la console di EC2 oppure tramite il comando aws ec2 run-instances con 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 respository 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 è aggiornarla con i repository indirizzati alla versione 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 "Advanced Instance Options" della procedura guidata Request Instances, è presente un campo di testo che serve per inviare informazioni relative all'AMI Amazon Linux. Queste informazioni possono essere inserite sotto forma di testo o caricate sotto forma di file. In entrambi i casi, devono essere le seguenti:

#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 con il flag --user-data file:// (è 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 Virtual Private Cloud (VPC) senza gateway Internet 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 a seconda che l'utente abbia la possibilità di impiegare il comando SSH nelle istanze come ec2-user di default e abbia la possibilità 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, selezionare Set Character Encoding, quindi UTF-8.
  • PuTTY: fare clic destro sulla barra del titolo per aprire il menu. Selezionare Change Settings. In Window → Translation → Remote Character Set, selezionare 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 per le AMI Amazon Linux potrà offrire un supporto clienti 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 che si trovano al 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 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).

D: 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’? y
# 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 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==--

Per 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 in cui si trovano in hosting i repository dell'AMI Amazon Linux.

Di seguito illustriamo un esempio di policy dell'endpoint VPC per ottenere questo risultato.

{
  "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 sugli endpoint VPC.