Questions fréquentes sur l'AMI Amazon Linux

Q : Qu'est-ce que l'AMI Amazon Linux ?

L'AMI Amazon Linux est une image Linux prise en charge et mise à jour par Amazon Web Services. Elle est destinée à être utilisée sur Amazon Elastic Compute Cloud (Amazon EC2). Elle assure un environnement stable, sécurisé et à hautes performances pour les applications s'exécutant dans Amazon EC2. Elle inclut également plusieurs packages qui permettent une intégration aisée avec AWS, y compris des outils de configuration de lancement ainsi que de nombreux outils et bibliothèques AWS courants. Amazon Web Services fournit également des mises à jour régulières de sécurité et de maintenance pour toutes les instances exécutant l'AMI Linux Amazon. L'AMI Amazon Linux est fournie sans frais supplémentaires aux utilisateurs d'Amazon EC2.

Q : Est-ce qu'Amazon propose une assistance pour l'AMI Amazon Linux ?

Oui. En souscrivant à AWS Support, vous bénéficiez d'une assistance pour l'AMI Linux Amazon. Vous trouverez plus de détails sur la page AWS Support.

Q : Pendant combien de temps l'AMI Amazon Linux est-elle prise en charge ?

L'AMI Amazon Linux (également appelée Amazon Linux 1) a atteint sa fin de vie le 31 décembre 2023. L'AMI Amazon Linux ne recevra aucune mise à jour de sécurité ni aucune correction de bogues à compter du 1er janvier 2024.

Q : En quoi les périodes standard et de maintenance diffèrent-elles ?

La période de maintenance prend effet une fois que la période standard n'est plus effective pour l'AMI Amazon Linux. Elle s'écoulera du 31 décembre 2020 au 31 décembre 2023. Au cours de cette période, AWS ne proposera plus de prise en charge ni pour les nouveaux types d'instances EC2 et les nouveaux services et nouvelles fonctionnalités AWS, ni pour les nouveaux packages. Au lieu de cela, AWS fournira des mises à jour uniquement pour les correctifs de sécurité critiques et importants qui s'appliquent à un ensemble réduit de paquets. En outre, certains packages, ainsi que les référentiels associés à l'AMI, seront progressivement déclarés obsolètes car arrivés en fin de vie.

Q : Quels sont les packages qui bénéficieront de mises à jour de sécurité critiques au cours de la période de maintenance ?

AWS proposera des mises à jour de sécurité critiques applicables au noyau Linux de l'AMI, ainsi qu'à tous les packages non considérés comme obsolètes.

Q : Quels sont les packages qui ne bénéficieront plus de mises à jour au cours de la période de maintenance ?

Au cours de la période de maintenance, les packages arrivés en fin de vie ne bénéficieront plus de mises à jour, à l'exception de ceux des bibliothèques d'espaces utilisateur de bas niveau.

Les packages suivants ont été rendus obsolètes avec la version 2018.03, et ne seront plus mis à jour dans le cadre de la période de maintenance :

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

De plus, les packages suivants ne seront plus mis à jour dans le cadre de la maintenance et sont en fin de vie :

Tous les packages de compatibilité
BZR (packages bzr-python26 et 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)
Subversion 1.9
Transmission
OpenJDK 1.7.0 (java-1.7.0-openjdk)

Autres packages qui ne bénéficieront plus de mises à jour à partir d'un certain moment de la période de maintenance :

Étant donné la nature des dépendances RPM et le fait qu'un package de haut niveau puisse comprendre plusieurs RPM, la liste complète des packages RPM dans Amazon Linux 1 et de leurs dates de fin de vie est disponible ici.

Q : Puis-je initialiser une AMI Amazon Linux après la fin de la période de maintenance ?

Oui. Cependant, si cette situation venait à changer, nous vous en tiendrons informé de manière anticipée.

Q : Est-ce que l'AMI Amazon Linux sera prise en charge hors d'EC2 ?

Non. L'AMI Amazon Linux est uniquement utilisable dans Amazon EC2.

Q : Puis-je visualiser le code source de l'AMI Amazon Linux ?

Oui. L'outil en ligne de commande yumdownloader, fourni avec l'AMI Amazon Linux, permet de visualiser le code source dans Amazon EC2.

Q : Où puis-je obtenir les mises à jour de l'AMI Amazon Linux ?

Les mises à jour sont fournies par le biais d'un référentiel yum préconfiguré, hébergé dans chaque région Amazon EC2. Les mises à jour de sécurité sont appliquées automatiquement au démarrage initial de l'AMI. Lors de la connexion, un message indique si des mises à jour supplémentaires sont disponibles ou non.

Q : Comment puis-je signaler les bugs ou demander la mise à disposition d'une fonctionnalité ou d'un package ?

Le forum de discussion dédié à Amazon EC2 permet de signaler les éventuels bugs rencontrés et de demander la mise à disposition d'une fonctionnalité ou d'un package. Ce type de forum est supervisé par le service d'assistance aux développeurs AWS et par l'équipe d'ingénierie dédiée à l'AMI Amazon Linux.
 

Q : Comment puis-je activer le référentiel EPEL (Extra Packages for Enterprise Linux) ?

Modifiez la commande /etc/yum.repos.d/epel.repo. Dans la section [epel], remplacez enabled=0 par enabled=1.

Pour activer temporairement le référentiel EPEL 6, utilisez l'option yum --enablerepo=epel.

Les référentiels de l'AMI Amazon Linux ont une priorité supérieure à celle de tout autre référentiel tiers. En effet, car plusieurs packages inclus dans l'AMI Amazon Linux figurent également dans des référentiels tiers, nous souhaitons nous assurer que la version de l'AMI Amazon Linux est installée par défaut.

Q : Comment puis-je définir, par « verrouillage », une version spécifique pour mon AMI ?

La structure du référentiel de l'AMI Amazon Linux permet l'émission d'un flux continu de mises à jour facilitant le passage d'une version de l'AMI à la suivante.

Les mises à jour de packages sont toujours transmises aux référentiels. Elles sont disponibles pour toutes les versions les plus récentes de l'AMI Amazon Linux vers lesquelles l'utilitaire yum pointe. Vous pouvez identifier les référentiels vers lesquels pointe votre instance en vous reportant à la variable « releasever » de la commande /etc/yum.conf. Par défaut, l'AMI Amazon Linux est configurée sur releasever=latest.

En d'autres termes, une AMI Amazon Linux est considérée comme un instantané effectué à un moment donné, et associé à un référentiel dont la structure de mise à jour fournit les derniers packages.

La fonctionnalité de verrouillage au lancement vous permet d'appliquer facilement une version spécifique à votre AMI, si vous ne souhaitez pas nécessairement obtenir plusieurs mises à jour lorsque de nouvelles versions majeures de l'AMI Amazon Linux sont publiées.

Afin d'activer cette fonctionnalité pour les nouvelles instances, initialisez une AMI Amazon Linux (dotée de la version 2015.09, par exemple) et transmettez les données utilisateur suivantes au package cloud-init via la console EC2, la commande ec2-run-instances (avec l'option --user-data) ou la commande ec2-run-instances -f.
#cloud-config
repo_releasever: 2015.09

Afin d'appliquer la version actuelle aux instances existantes (celle-ci étant indiquée dans la commande /etc/system-release), modifiez la commande /etc/yum.conf. Mettez en commentaire la ligne releasever=latest and run yum clean all afin de nettoyer le cache.

REMARQUE : si une version de référentiels autre que la plus récente est définie pour votre AMI, vous ne recevrez plus aucune mise à jour. La seule manière de recevoir des mises à jour continues consiste à utiliser l'AMI la plus récente, ou de mettre régulièrement à jour l'ancienne AMI avec les référentiels pointant vers la version la plus récente.

Q : Comment puis-je désactiver l'installation automatique des mises à jour de sécurité critiques lors du démarrage initial ?

Lors de son premier démarrage, l'AMI Amazon Linux installe, à partir des référentiels de packages, toutes les mises à jour de sécurité considérées comme critiques et ce, avant que des services tels que SSH ne s'initialisent.

Si l'AMI ne peut pas accéder aux référentiels yum, la demande expire une fois le délai d'attente dépassé et plusieurs tentatives sont effectuées avant que la procédure de démarrage ne prenne fin. Cela peut s'expliquer par des réglages de pare-feu ou VPC restrictifs, qui empêchent l'accès aux référentiels de packages de l'AMI Linux Amazon.

Si vous rencontrez ce problème, vous pouvez modifier votre environnement afin que l'AMI Linux Amazon puisse se connecter à ses référentiels de packages. Vous pouvez également désactiver la mise à jour de sécurité lancée au démarrage.

Pour désactiver la mise à jour de sécurité au démarrage depuis la console AWS EC2 :

Sur la page Advanced Instance Options dans l'assistant de demande d'instances, il y a un champ texte pour envoyer les données utilisateur de l'AMI Linux Amazon. Ces données peuvent être saisies sous forme de texte ou téléchargées en tant que fichier. Dans les deux cas, les données doivent correspondre aux éléments suivants :
#cloud-config
repo_upgrade: none

Pour désactiver, depuis la ligne de commande, les mises à jour de sécurité s'effectuant au démarrage :

Créez un fichier texte avec les données utilisateur précédentes, et transmettez-le à l'aide de la commande aws ec2 run-instances et de l'option « --user-data file://<filename> » (cette opération peut également être effectuée à l'aide de la commande ec2-run-instances -f ).

Pour désactiver les mises à jour de sécurité s'effectuant au démarrage lors de la régénération de l'AMI Amazon Linux :

Modifiez la commande /etc/cloud/cloud.cfg et remplacez « repo_upgrade: security » par « repo_upgrade: none ».

Q : Pourquoi le lancement de SSH en cas d'exécution dans un VPC (Virtual Private Cloud), sans passerelle Internet ni instance NAT, est-il si long ?

Reportez-vous à la réponse de la question précédente.

Q : Pourquoi mes matrices RAID sont-elles associées à l'intitulé /dev/md127 et non à l'intitulé /dev/md0 ?

Les versions plus récentes de l'utilitaire mdadm créent des matrices RAID avec des superblocs dotés de la version 1.2. Ceux-ci ne sont pas automatiquement associés à un périphérique numéroté. Référencez les partitions en configurant une étiquette pour le système de fichiers. La plupart des outils de création de systèmes de fichiers utilisent l'indicateur -L pour définir cette étiquette. Une fois définie, l'étiquette est référencée par la commande mount, ou dans /etc/fstab avec l'option LABEL=[NAME].

Exemple : Création d'une matrice RAID0 avec une étiquette
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
Exemple : Définition d'une étiquette pour un système de fichiers ext[2-4] existant.
e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

Q : Pourquoi le groupe wheel était-il désactivé dans le fichier /etc/sudoers et comment puis-je le réactiver ?

En fonction des systèmes d'exploitation Linux, le groupe wheel peut ou non être activé par défaut pour la commande sudo. Nous pensons qu'il est plus sage du point de vue de la sécurité pour l'AMI Linux Amazon que wheel soit désactivé par défaut pour sudo.

Pour contourner ce problème, il existe deux possibilités, selon que vous pouvez communiquer par SSH avec vos instances en tant qu'utilisateur ec2 par défaut et si vous avez modifié les privilèges de cet utilisateur lui permettant d'interagir avec sudo.

Option n° 1 - pour les utilisateurs qui n'ont modifié aucune valeur par défaut, vous devriez toujours avoir la possibilité de communiquer par ssh avec votre instance en tant qu'utilisateur ec2 et, ainsi, appeler sudo pour obtenir un accès racine. À partir de là, vous pouvez modifier le fichier sudoers afin de réactiver wheel.
Option n° 2 - pour les utilisateurs qui ont modifié les valeurs par défaut ou qui ne peuvent pas appeler sudo en tant qu'utilisateur ec2 pour obtenir l'accès racine, nous recommandons de procéder comme suit :

• arrêtez l'instance concernée (sans y mettre fin) ;
• dissociez le volume EBS racine, en utilisant pour ce faire la console EC2 ou les outils d'API EC2 ;
• associez le volume à une autre instance EC2 pour laquelle vous disposez d'un accès racine à distance ;
• connectez-vous à cette instance ;
• montez le volume que vous venez d'associer ;
  sudo mount /dev/xvdf /mnt
• modifiez le fichier sudoers au sein du volume associé et décommentez le groupe wheel ;
  sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
• démontez le volume ;
  sudo umount -d /dev/xvdf
• Dissociez le volume.
• Réassociez le volume à l'instance interrompue (en vérifiant que le périphérique est le même que celui avant dissociation, à savoir /dev/sda1, généralement).
• Démarrez l'instance concernée.

Q : Pourquoi des caractères comme � ou â apparaissent-ils lorsque je communique avec l'AMI Amazon Linux via un terminal ?

L'AMI Amazon Linux utilise par défaut le format d'encodage de caractères UTF-8. Les terminaux client n'utilisant pas l'encodage UTF-8 ne convertissent pas toujours ces caractères de façon correcte. Pour corriger ce problème, définissez l'encodage UTF-8 sur le terminal client.

• Gnome Terminal : dans le menu Terminal, sélectionnez Set Character Encoding, puis UTF-8 ;
• PuTTY : effectuez un clic droit sur la barre de titre pour afficher le menu. Sélectionnez alors Change Settings. Sous Window → Translation → Remote Character Set, sélectionnez UTF-8.

Q : J'ai remarqué l'option report_instanceid dans la commande /etc/yum.repos.d/amzn*.repo. À quoi sert-elle ?

Les référentiels de l'AMI Amazon Linux sont des compartiments S3 associés à chaque région. Lorsque le processus yum de votre instance télécharge des packages depuis ces compartiments, des informations concernant la connexion S3 sont consignées.
Dans le contexte d'Amazon Linux Ami, le paramètre report_instanceid=yes permet aux référentiels de l'AMI Linux Amazon de consigner également l'ID (i-xxxxxxxx) et la région (par ex., us-west-2) de l'instance de téléchargement du package. L'équipe de l'AMI Linux Amazon peut ainsi apporter une assistance plus ciblée et adaptée au client concernant les instances individuelles.
Le paramètre report_instanceid=yes est uniquement activé par défaut pour les référentiels de l'AMI Amazon Linux.

Q : Pourquoi les fichiers de configuration du référentiel yum /etc/yum.repos.d/amzn*.repo sont-ils écrasés lorsque le package de version du système est mis à niveau ?

Ces fichiers de configuration sont écrasés lorsque le package de version du système est mis à niveau, afin de garantir que les instances détectent toujours les modifications apportées à la configuration du référentiel yum de l'AMI Amazon Linux.
Pour les versions de l'AMI Linux Amazon avant 2014.09 :
Ces fichiers sont générés par cloud-init à partir de modèles situés à l'emplacement /etc/cloud/templates/amzn-*.repo.tmpl. Les modifications apportées à ces fichiers de modèles seront conservées.

Pour l'AMI Amazon Linux 2014.09 et les versions ultérieures :

Les fichiers /etc/yum.repos.d/amzn*.repo utilisent désormais des variables yum pour aider les instances à atteindre les référentiels les plus proches géographiquement, afin de ne plus utiliser de modèles cloud-init. Toutes les modifications apportées à ces fichiers seront préservées sous /etc/yum.repos.d/amzn*.repo.rpmsave lorsque la version du système sera mise à niveau.

Pour les utilisateurs effectuant une mise à jour vers la version 2014.09, toutes les modifications apportées aux fichiers /etc/yum.repos.d/amzn*.repo sont enregistrées dans /etc/yum.repos.d/amzn*.repo.rpmsave.

Q : Comment puis-je modifier ou désactiver les couleurs des pages man ?

Les couleurs des pages man sont définies dans /etc/profile.d/less.sh (bash et zsh) et /etc/profile.d/less.csh (csh). Pour les désactiver, supprimez toutes les lignes commençant par LESS_ (bash, zsh) et/ou setenv LESS_ (csh).

Q : Comment puis-je désactiver l'audit d'appels système avec les instances antérieures à la version 2015.09 ?

L'audit d'appels système est désactivé par défaut avec toutes les instances dotées de la version 2015.09 de l'AMI Amazon Linux. Cet audit complexifie les appels système et peut affecter significativement les performances, en particulier avec les applications sollicitant fortement l'espace disque ou le réseau.

Si vous souhaitez utiliser cette fonctionnalité d'audit, recherchez la ligne suivante dans /etc/audit/audit.rules et supprimez-la, ou décommentez-la, puis redémarrez le démon d'audit.
-a never,task
Exemple (accès racine) :
# 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
Pour bénéficier des mêmes améliorations de performances avec les instances antérieures à la version 2015.09, ajoutez la même ligne (-a never,task) à /etc/audit/audit.rules et redémarrez le démon. Si vous souhaitez effectuer une mise à niveau et que vous n'avez apporté aucune modification aux fichiers de règles d'audit, vous pouvez simplement déplacer ou copier le nouveau fichier de règles d'audit par défaut dans /etc/audit/audit.rules.
Exemple (accès racine) :
# 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

Q : Dans quelles situations les données utilisateur MIME multipart peuvent-elles être employées avec le package cloud-init ?

Pour consulter la documentation relative aux ressources MIME multipart pour le package cloud-init, cliquez ici.
Le format MIME multipart pouvant être complexe, il est recommandé d'utiliser l'outil write-mime-multipart pour générer des fichiers multipart. L'outil se trouve dans le package cloud-utils et peut être installé à l'aide de la commande sudo yum install /usr/bin/write-mime-multipart. L'outil se base sur la première ligne du fichier pour déterminer le champ Content-Type, et le package cloud-init utilise ce champ pour établir la méthode d'interprétation du fichier. Des exemples de fichiers sont listés ci-dessous :
#cloud-config
repo_releasever: 2015.09
et
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
La commande write-mime-multipart est illustrée ci-dessous, accompagnée des résultats :
[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==--
Pour en savoir plus sur l'utilisation de l'outil, consultez la page man dédiée à la commande write-mime-multipart.

Q : Comment puis-je configurer un point de terminaison de VPC pour autoriser les connexions avec les référentiels de l'AMI Amazon Linux ?

Il est possible d'accéder aux référentiels yum d'un VPC sans accès à Internet. La politique de votre point de terminaison VPC doit autoriser le trafic entre votre VPC et les compartiments S3 qui hébergent les référentiels de l'AMI Linux Amazon.
Voici un exemple de politique de point de terminaison VPC illustrant ce cas :
{
"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/*"
]
}
]
}
Pour obtenir plus d'informations, consultez la documentation applicable aux points de terminaison d'un VPC.