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

L'AMI Linux Amazon 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 est conçue pour fournir un environnement d'exécution stable, sécurisé et à hautes performances pour les applications exécutées sur 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 Linux Amazon est fournie sans frais supplémentaires à tous les utilisateurs d'Amazon EC2.

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

Oui. L'outil de ligne de commande yumdownloader --source fourni dans l'AMI Linux Amazon permet de visualiser le code source au sein d'Amazon EC2.

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

Les mises à jour sont fournies par le biais d'un dépôt 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. A la connexion, le Message du jour (/etc/motd) indique s'il y a ou non des mises à jour supplémentaires disponibles.

Q : A quelle fréquence les mises à jour de l'AMI Linux Amazon sont-elles disponibles ?

L'AMI Linux Amazon est conçue et tenue à jour en tant que version continue. Nous encourageons les utilisateurs à considérer l'AMI Linux Amazon comme un seul flot de packages, dont les AMI elles-mêmes constituent simplement des instantanés à un moment donné.

 

En fournissant une version continue, nous garantissons que nos AMI Linux Amazon et les instances de nos clients basées sur ces AMI prennent en charge les dernières fonctionnalités d'EC2 et d'AWS dès leur lancement. De cette façon, l'AMI Linux Amazon sert également de point de référence aux autres producteurs d'AMI Linux (producteurs tiers et distributeurs de l'AMI Linux Amazon) afin qu'ils puissent également prendre en charge ces fonctionnalités.

 

Avec ce modèle, les clients sont plus susceptibles d'exécuter les dernières améliorations de sécurité, de performances et de fonctionnalités, ce qui permet d'atténuer de nombreux problèmes qu'ils pourraient rencontrer.

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

Oui. En souscrivant à AWS Support, vous bénéficiez d'une assistance pour l'AMI Linux Amazon. Pour en savoir plus, consultez la page AWS Support.

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

Non. L'AMI Linux Amazon est uniquement disponible pour une utilisation dans Amazon EC2.

Q : Comment signaler des bugs ou demander une fonctionnalité ou un package ?

Le forum de discussion Amazon EC2 permet aux clients de nous informer des éventuels bugs rencontrés et de nous faire part de leurs demandes concernant certaines fonctionnalités ou certains packages. Les forums comme celui-ci sont placés sous l'égide du service d'assistance des développeurs AWS et de l'équipe d'ingénierie de l'AMI Amazon Linux.

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

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

Pour activer temporairement le dépôt EPEL 6, utilisez l'option de ligne de commande yum --enablerepo=epel.

Notez que les dépôts de l'AMI Linux Amazon sont configurés avec une priorité supérieure à celle de tout autre dépôt tiers. En effet, plusieurs packages inclus dans l'AMI Linux Amazon figurent également dans des dépôts tiers et nous voulons être certains que la version de l'AMI Linux Amazon est installée par défaut.

Q : Comment verrouiller mon AMI pour une version spécifique ?

La structure du référentiel de l'AMI Linux Amazon est configurée pour fournir un flux continu de mises à jour, qui vous permet de passer d'une version de l'AMI Linux Amazon à la suivante.

Les mises à jour des packages sont toujours transmises aux référentiels et sont disponibles pour toutes les versions de l'AMI Linux Amazon sur lesquelles yum est configuré de manière à pointer vers « latest ». Vous pouvez savoir vers quels référentiels pointe votre instance en observant la variable « releasever » dans /etc/yum.conf. Par défaut, l'AMI Linux Amazon est définie sur releasever=latest.

En d'autres termes, les AMI Linux Amazon sont considérées comme des instantanés à un moment donné, avec un référentiel dont la structure de mise à jour vous fournit les derniers packages que nous avons mis au point et transmis au référentiel.

La fonctionnalité de verrouillage au lancement existe afin de permettre aux clients de conserver facilement leurs AMI sur une version majeure en particulier, s'ils ne souhaitent pas nécessairement obtenir plusieurs mises à jour des packages lorsque nous publions de nouvelles versions majeures de l'AMI Linux Amazon.

Pour activer cette fonctionnalité sur de nouvelles instances, lancez une AMI Linux Amazon (par exemple 2015.09) avec les données utilisateur suivantes, transmises à cloud-init via la console EC2 ou aws ec2 run-instances avec l'indicateur --user-data (vous pouvez également les transmettre avec ec2-run-instances -f).

#cloud-config
repo_releasever: 2015.09

Afin de verrouiller les instances existantes pour la version actuelle (indiquée dans /etc/system-release), modifiez /etc/yum.conf. Mettez en commentaire la ligne releasever=latest et exécutez yum clean all afin de nettoyer le cache.

REMARQUE : si votre AMI est verrouillée dans une version de référentiels autre que la plus récente, vous ne recevrez plus aucune mise à jour. La seule façon de recevoir un flux continu de mises à jour pour l'AMI Linux Amazon est d'utiliser l'AMI la plus récente, ou tout du moins de mettre régulièrement à jour l'AMI avec les référentiels pointant vers la version la plus récente.

Q : Comment désactiver l'installation automatique des mises à jour de sécurité importantes et critiques lors du lancement initial ?

À son premier démarrage, l'AMI Linux Amazon installe à partir des dépôts de packages toutes les mises à jour de sécurité indiquées comme critiques ou importantes pour l'espace utilisateur et ce, avant que les services, tels que SSH, ne démarrent.

Si l'AMI ne peut pas accéder aux dépôts yum, elle expire une fois le délai d'attente dépassé et plusieurs tentatives sont effectuées avant de terminer la procédure de démarrage. Cela peut s'expliquer par des réglages de pare-feu ou VPC restrictifs, qui empêchent l'accès aux dépôts 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 dépôts 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 être de type :

#cloud-config
repo_upgrade: none

Pour désactiver la mise à jour de sécurité au démarrage depuis la ligne de commande :

Créer un fichier texte avec les user-data précédentes, et envoyez-le aux run-instances aws ec2 avec le flag --user-data file:// (cela peut aussi être fait avec ec2-run-instances -f ).

Pour désactiver la mise à jour de sécurité au démarrage lors de la regénération des packages de l'AMI Linux Amazon :

Modifiez /etc/cloud/cloud.cfg et remplacez repo_upgrade: security par repo_upgrade: none.

Q : Pourquoi faut-il autant de temps pour que SSH se lance en cas d'exécution dans un VPC (Virtual Private Cloud) sans passerelle Internet ni instance NAT ?

Voir la réponse à la question précédente.

Q : Pourquoi mes matrices RAID commencent-elles à partir de /dev/md127 au lieu de /dev/md0 ?

Les versions plus récentes de mdadm créent des matrices RAID avec des superblocs version 1.2, lesquels ne réalisent pas automatiquement l'assemblage avec 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 l'étiquette. Une fois définie, l'étiquette est référencée par monte ou dans /etc/fstab avec 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 : Pour quelle raison le groupe wheel était-il désactivé dans /etc/sudoers et comment le réactiver ?

Les systèmes d'exploitation Linux présentent des valeurs par défaut différentes concernant l'activation de wheel pour 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, d'appeler sudo pour obtenir un accès racine. A 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 mettez en commentaire 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 arrêtée (en prenant soin de vérifier que le périphérique est le même que celui avant dissociation, généralement : /dev/sda1).
  • Démarrez l'instance concernée.

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

L'AMI Linux Amazon 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 : Je vois une option report_instanceid dans /etc/yum.repos.d/amzn*.repo. A quoi sert-elle ?

Les dépôts de l'AMI Linux Amazon 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 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 Linux Amazon.

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 du référentiel sont écrasés lorsque le package de version du système est mis à niveau pour garantir que les instances perçoivent toujours les modifications apportées à la configuration du référentiel yum de l'AMI Linux Amazon.

Pour les versions de l'AMI Linux Amazon avant 2014.09 :

Ces fichiers sont générés par cloud-init à partir de gabarits situés à l'emplacement /etc/cloud/templates/amzn-*.repo.tmpl. Les modifications apportées à ces fichiers de gabarit 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 gabarits 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.

Les utilisateurs effectuant une mise à jour vers la version 2014.09 verront toutes les modifications apportées aux fichiers /etc/yum.repos.d/amzn*.repo enregistrés sous /etc/yum.repos.d/amzn*.repo.rpmsave.

Q : Comment modifier ou désactiver les couleurs des pages de manuel ?

Les couleurs des pages de manuel 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 l'exportation LESS_ (bash, zsh) et/ou setenv LESS_ (csh).

Q : Comment désactiver l'audit des appels systèmes sur les instances lancées avant septembre 2015 ?

L'audit des appels systèmes a été désactivé par défaut dans les nouveaux lancements de l'AMI Linux Amazon 2015.09.  Cette fonction engendre des frais pour chaque appel au système et peut occasionner une dégradation notable des performances, tout particulièrement dans les applications nécessitant des opérations intensives sur le disque ou le réseau.

Si vous avez besoin d'utiliser l'audit des appels systèmes, recherchez la ligne suivante dans /etc/audit/audit.rules et supprimez-la ou mettez-la en commentaire, puis redémarrez le démon de l'audit.

 -a never,task

Exemple (à la racine) :

# auditctl -l
LIST_RULES: task,never
# sed -i.bak -e '/^-a never,taskUSD/ s/^/#/' /etc/audit/audit.rules
# service auditd restart
# auditctl -l
No rules

Si vous souhaitez bénéficier d'une amélioration identique des performances sur les instances démarrées à partir des AMI lancées avant septembre 2015, ajoutez la même ligne (-a never,task) à /etc/audit/audit.rules, puis redémarrez le démon. Si vous effectuez une mise à niveau et que vous n'avez apporté aucune modification aux fichiers de règles de l'audit, vous pouvez tout simplement déplacer ou copier le nouveau fichier de règles par défaut dans /etc/audit/audit.rules.

Exemple (à la 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 : Pouvez-vous fournir un exemple d'utilisation des données utilisateur mime multipartie avec cloud-init ?

La documentation concernant le format mime multipartie pour cloud-init est disponible ici.

MIME multipartie est un format qui peut se révéler compliqué. Nous vous recommandons donc d'utiliser l'outil write-mime-multipart pour générer le fichier multipartie. Cet outil se trouve dans le package cloud-utils et peut être installé avec sudo yum install /usr/bin/write-mime-multipart. L'outil se sert de la première ligne du fichier pour déterminer le champ Content-Type et cloud-init utilise ce champ pour établir la méthode d'interprétation du fichier. Quelques exemples de fichiers :

#cloud-config
repo_releasever: 2015.09

et

#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt

Voici un exemple de write-mime-multipart, sorties comprises :

[ec2-user@ip-172-31-4-37 ~]USD 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==--

Obtenez plus d'informations sur l'utilisation de cet outil avec man write-mime-multipart.

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

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 plus d'informations, consultez la documentation sur les points de terminaison VPC.