Amazon Linux AMI – Häufig gestellte Fragen

F: Was ist das Amazon Linux AMI?

Das Amazon Linux AMI (Amazon Machine Image) ist ein von Amazon Web Services bereitgestelltes, unterstütztes und gepflegtes Linux-Image zur Verwendung auf Amazon EC2 (Amazon Elastic Compute Cloud). Es bietet eine stabile, sichere und High-Performance-Ausführungsumgebung für Anwendungen auf Amazon EC2. Außerdem enthält es Pakete für die einfache Integration mit AWS, darunter Startkonfigurations-Tools und viele weit verbreitete AWS-Bibliotheken und -Tools. Amazon Web Services bieten laufend Sicherheits- und Wartungsaktualisierungen für alle Instances, auf denen das Amazon Linux AMI ausgeführt wird. Das Amazon Linux AMI wird Amazon EC2-Nutzern kostenlos bereitgestellt.

F: Bietet Amazon Support für das Amazon Linux AMI?

Ja. Das Amazon Linux AMI wird durch Abonnements für AWS Support unterstützt. Weitere Informationen finden Sie auf der AWS-Support-Seite.

F: Wie lange wird das Amazon-Linux-AMI noch unterstützt?

Das Amazon-Linux-AMI (auch Amazon Linux 1 genannt) erreichte am 31. Dezember 2023 sein Lebensende. Amazon Linux AMI wird ab dem 1. Januar 2024 keine Sicherheitsupdates oder Fehlerbehebungen mehr erhalten.

F: Wie unterscheidet sich der Wartungssupport vom Standardsupportzeitraum?

Der Wartungssupport bezieht sich auf den Zeitraum nach dem Ende des Standardsupports für Amazon Linux AMI. Der Wartungssupport erstreckt sich vom 31. Dezember 2020 bis zum 31. Dezember 2023. Während dieses Zeitraums bietet AWS keinen Support mehr für neue EC2-Instance-Typen, neue AWS-Services und -Funktionen sowie neue Pakete. Stattdessen stellt AWS Updates nur für kritische und wichtige Sicherheitsfixes bereit, die für eine reduzierte Anzahl an Paketen gelten. Zusätzlich werden einige Pakete im AMI und in seinen Repositorys während des gesamten Wartungssupportzeitraums gemäß ihrer End-of-Life-Praktiken langsam veraltet.

F: Wie lautet die Liste der Pakete, die kritische und wichtige Sicherheitspatches während des Wartungssupportzeitraums erhalten?

AWS stellt dem Linux-Kernel im AMI kritische und wichtige Sicherheitsupdates bereit sowie alle, auch veraltete Userspace-Pakete.

F: Welche Pakete erhalten während des Wartungssupportzeitraums keine Updates mehr?

Während des Wartungsfensters erhalten sämtliche Pakete außerhalb der Benutzerraum-Bibliotheken der unteren Stufe, die ihr End-of-Life in ihren Upstreamquellen erreicht haben, keine Updates mehr.

Die folgenden Pakete wurden mit der ursprünglichen Version 2018.03 veraltet und werden im Rahmen des Wartungs-Support-Zeitraums nicht mehr aktualisiert:

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

Darüber hinaus erhalten die folgenden Pakete keine weiteren Updates im Rahmen des Wartungs-Supports und sind End of Life:

Alle Kompat-Pakete
BZR - (bzr-python26- und bzr-python27-Pakete)
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)

Zusätzlich gibt es einige andere Pakete, die irgendwann während des Wartungszeitraums keine Updates mehr erhalten werden:

Aufgrund der Natur von RPM-Abhängigkeiten und der Tatsache, dass eines dieser Top-Level-Pakete aus mehreren RPMs bestehen kann, ist eine vollständige Liste aller RPM-Pakete in Amazon Linux 1 und ihrer End of Life-Zeitpunkte hier verfübar.

F: Kann ich nach dem Ende des Wartungs-Support-Zeitraums Amazon Linux AMIs starten?

Ja, und falls sich diese Richtlinie jemals ändert, geben wir dies im Voraus bekannt.

F: Wird das Amazon Linux AMI außerhalb von EC2 unterstützt?

Nein. Das Amazon Linux AMI ist nur für die Verwendung innerhalb von Amazon EC2 verfügbar.

F: Kann ich den Quellcode des Amazon Linux AMI anzeigen?

Ja. Das Befehlszeilen-Tool "yumdownloader" im Amazon Linux AMI ermöglicht die Anzeige des Quellcodes in Amazon EC2.

F: Wo erhalte ich Updates für das Amazon Linux AMI?

Updates werden über ein vorkonfiguriertes Yum-Repository bereitgestellt, das in jeder Amazon EC2-Region gehostet wird. Sicherheits-Updates werden automatisch beim ersten Start des AMI eingespielt. Bei der Anmeldung gibt die Meldung des Tages (/etc/motd) an, ob zusätzliche Aktualisierungen verfügbar sind.

F: Wie können Fehler gemeldet und Anfragen von Funktionen und Paketen gestellt werden?

Wir verwenden das Amazon EC2-Diskussionsforum für Fehlerberichte, Funktions- und Paketanforderungen. Diese Foren werden vom AWS-Entwicklungs-Support sowie dem Amazon Linux AMI-Technikerteam überwacht.
 

F: Wie kann das Repository EPEL (Extra Packages for Enterprise Linux) aktiviert werden?

Bearbeiten Sie /etc/yum.repos.d/epel.repo. Ändern Sie im Abschnitt, der mit [epel] markiert ist, den Eintrag enabled=0 in enabled=1.

Um das EPEL 6-Repository vorübergehend zu aktivieren, verwenden Sie die yum-Befehlszeilenoption --enablerepo=epel.

Beachten Sie, dass die Amazon Linux AMI-Repositorys mit höherer Priorität konfiguriert werden als alle Repositorys von Drittanbietern. Der Grund ist, dass einige Pakete, die Bestandteil des Amazon Linux AMIs sind, auch in Repositorys von Drittanbietern enthalten sind, und wir sicherstellen möchten, dass im Normalfall die AMI-Version von Amazon Linux AMI installiert wird.

F: Wie kann das AMI fest auf eine bestimmte Version eingestellt werden?

Die Amazon Linux AMI-Repository-Struktur ist so konfiguriert, dass ein kontinuierlicher Updatefluss bereitgestellt wird, mit dem Sie von einer Version der Amazon Linux AMI zur nächsten rollen können.

Paketupdates werden immer in die Repositorys geschoben und sind für alle Versionen von Amazon Linux AMI verfügbar, für die yum so konfiguriert ist, dass es auf „neueste“ verweist. Sie können auf die Repositorys sehen, auf die Ihre Instance verweist, indem Sie die Variable „latest“ in /etc/yum.conf anzeigen. Standardmäßig hat das Amazon Linux AMI releasever=latest set eingestellt.

Anders gesagt, Amazon Linux AMIs werden als zeitpunktbezogene Snapshots behandelt und weisen eine Repository- und Update-Struktur auf, mit der Sie über die neuesten Pakete verfügen, die wir erstellt und in das Repository geschoben haben.

Die Funktion „Lock and Launch“ dient dazu, damit die Benutzer eine bestimmte größere Version Ihrer AMIs beibehalten können, wenn Sie nicht unbedingt eine Paketaktualisierung erhalten möchten, wenn wir neue Hauptversionen des Amazon Linux AMI freigeben.

Um diese Funktion in neuen Instances zu aktivieren, starten Sie (beispielsweise) ein Amazon Linux AMI 2015.09, indem Sie die folgenden Benutzerdaten an „cloud-init“ übergeben, entweder über die EC2-Konsole oder aws ec2-run-instances mit dem Flag --user-data (dies kann auch mit ec2-run-instances -f erfolgen).
#cloud-config
repo_releasever: 2015.09

Um vorhandene Instances fest auf ihre aktuelle Version festzulegen (die in /etc/system-release angegeben ist), bearbeiten Sie /etc/yum.conf. Kommentieren Sie die Zeile releasever=latest and run yum clean all aus, um den Cache zu löschen.

HINWEIS: Wenn Sie Ihr AMI auf eine Version der Speicherorte sperren, die nicht der neuesten entpricht, erhalten Sie keine weiteren Aktualisierungen. Die einzige Möglichkeit, einen kontinuierlichen Fluss von Aktualisierungen für Amazon Linux AMI zu erhalten, besteht in der Verwendung des neuesten AMI. Ansonsten müssen Sie Ihr altes AMI ständig aktualisieren und die Speicherorte auf das neueste verweisen lassen.

F: Wie kann die automatische Installation kritischer und wichtiger Sicherheits-Updates beim ersten Start deaktiviert werden?

Beim ersten Starten installiert das Amazon Linux AMI alle als kritisch oder wichtig bewerteten Userspace-Sicherheitsupdates aus den Paket-Repositorys, und zwar vor dem Start von Diensten wie SSH.

Wenn das AMI nicht auf die yum-Repositorys zugreifen kann, wird es unterbrochen. Vor Abschluss des Systemstarts werden mehrere Versuche unternommen. Mögliche Gründe dafür sind einschränkende Firewall-Einstellungen oder VPC-Einstellungen, die den Zugriff auf die Amazon Linux AMI-Paket-Repositorys verhindern.

Wenn dieses Problem auftritt, können Sie Ihre Umgebung derart ändern, dass das Amazon Linux AMI auf die Paket-Repositorys zugreifen kann, oder Sie können die Sicherheitsaktualisierungen beim Systemstart deaktivieren.

Deaktivieren der Sicherheitsaktualisierung beim Systemstart über die AWS EC2-Konsole:

Auf der Seite mit den erweiterten Instance-Optionen im Request Instances Wizard (Instance-Anforderungsassistenten) gibt es ein Textfeld zum Senden von Amazon Linux AMI-Benutzerdaten. Diese Daten können als Text eingegeben oder als Datei hochgeladen werden. Folgendes sollte auf jeden Fall gelten:
#cloud-config
repo_upgrade: none

Deaktivieren der Sicherheitsaktualisierungen beim Systemstart über die Befehlszeile:

Erstellen Sie eine Textdatei mit den vorstehenden Benutzerdaten und leiten Sie sie an das Flag aws ec2 run-instances with the --user-data file://<filename> weiter (auch mit ec2-run-instances -f möglich).

Deaktivieren der Sicherheitsaktualisierungen beim Systemstart beim erneuten Bündeln des Amazon Linux AMI:

Bearbeiten Sie /etc/cloud/cloud.cfg und ändern Sie repo_upgrade: security zu repo_upgrade: none.

F: Warum dauert es so lange, bis SSH startet, wenn es in einer Virtual Private Cloud (VPC) ohne Internet-Gateway- oder NAT-Instance ausgeführt wird?

Lesen Sie die Antwort der vorhergehenden Frage.

F: Warum beginnen die RAID-Arrays bei /dev/md127 statt bei /dev/md0?

Neuere Versionen von mdadm erstellen RAID-Arrays mit Superblöcken der Version 1.2, die nicht automatisch mit einem numerierten Gerät assembliert werden. Verweisen Sie auf Partitionen, indem Sie ein Label für das Dateisystem festlegen. Die meisten Dateisystem-Erstellungstools verwenden das Flag -L zum Festlegen des Labels. Nach dem Festlegen wird auf das Label durch die Einbindung oder in /etc/fstab mit LABEL=[NAME] verwiesen.

Beispiel: Erstellen eines RAID0-Arrays mit einem Label.
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
Beispiel: Festlegen des Labels eines vorhandenen ext[2-4]-Dateisystems.
e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

F: Warum wurde die Gruppe „wheel“ in „/etc/sudoers“ deaktiviert und wie kann sie wieder aktiviert werden?

Linux-Betriebssysteme weisen unterschiedliche Standardeinstellungen im Hinblick auf die Aktivierung von wheel für sudo auf. Unserer Meinung nach stellt die standardmäßige Deaktivierung von wheel für sudo die sinnvollere Haltung zur Sicherheit für das Amazon Linux AMI dar.

Zu diesem Thema bestehen zwei Problemumgehungen, die in dem Punkt voneinander abweichen, ob normale ec2-Benutzer über die Fähigkeit zum Herstellen von SSH-Verbindungen mit Instances verfügen und ob die Möglichkeit dieser Benutzer zum Verwenden von sudo geändert wurde oder nicht.

Option #1: Benutzer, deren Standardeinstellungen nicht geändert wurden, sollten nach wie vor in der Lage sein, als ec2-user Verbindungen zu ihrer Instance per SSH herzustellen und von da aus sudo aufzurufen, um den Root-Zugriff zu erhalten; hier kann dann die sudoers-Datei geändert werden, um wheel wieder zu aktivieren.
Option #2: Für Benutzer, deren Standardeinstellungen geändert wurden oder die nicht die Möglichkeit haben, von ec2-user per sudo auf Root zuzugreifen, empfehlen sich die folgenden Schritte:

• Halten Sie die betroffene Instance an (beenden Sie sie jedoch nicht).
• Heben Sie die Zuordnung des EBS-Rootvolumes auf; verwenden Sie dazu entweder die EC2-Konsole oder die EC2-API-Tools.
• Ordnen Sie das Volume einer anderen EC2-Instance zu, für die Sie Root-Remotezugriff besitzen.
• Melden Sie sich bei dieser Instance an.
• Stellen Sie das neu zugeordnete Volume bereit.
  sudo mount /dev/xvdf /mnt
• Bearbeiten Sie die sudoers-Datei im zugeordneten Volume, und heben Sie die Auskommentierung der Gruppe wheel auf.
  sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
• Heben Sie die Bereitstellung des Volumes auf.
  sudo umount -d /dev/xvdf
• Heben Sie die Zuordnung des Volumes auf.
• Ordnen Sie das Volume wieder der angehaltenen Instance zu (vergewissern Sie sich, dass das Gerät das gleiche ist, das es vor dem Aufheben der Zuordnung war, normalerweise: /dev/sda1).
• Starten Sie die betroffene Instance.

F: Warum werden seltsame Zeichen wie � oder â angezeigt, wenn ich mit dem Amazon Linux AMI über ein Terminal kommuniziere?

Das Amazon Linux AMI verwendet standardmäßig die Zeichencodierung UTF-8. Auf Client-Terminals, die nicht mit der UTF-8-Codierung arbeiten, werden UTF-8-Zeichen nicht immer ordnungsgemäß übersetzt. Legen Sie zur Korrektur dieser Anzeige die Codierung des Client-Terminals auf UTF-8 fest:

• GNOME-Terminal: Wählen Sie im Menü „Terminal“ den Befehl Set Character Encoding und dann UTF-8 aus.
• PuTTY: Klicken Sie mit der rechten Maustaste auf die Titelleiste, um das Menü einzublenden. Klicken Sie dann auf Change Settings. Wählen Sie unter Window → Translation → Remote Character Set die Option UTF-8.

F: Ich sehe die Option report_instanceid in /etc/yum.repos.d/amzn*.repo. Was ist ihre Aufgabe?

Die Amazon Linux AMI-Speicherorte sind S3-Buckets in jeder Region. Wenn der Yum-Prozess für Ihre Instance-Pakete aus diesen Buckets herunterlädt, werden Informationen zur jeweiligen S3-Verbindung aufgezeichnet.
Beim Amazon Linux AMI, können Amazon Linux AMI-Repositories mit der Einstellung report_instanceid=yes auch die ID der Instance (i-xxxxxxxx) sowie die Region (z. B. usa-west-2) einer Instance protokollieren, die ein Paket herunterlädt. Dadurch kann das Amazon Linux AMI-Team für einzelne Instances einen fokussierteren und spezifischeren Support leisten.
report_instanceid=yes ist standardmäßig nur für die Amazon Linux AMI-Repositorys aktiviert.

F: Warum werden Konfigurationsdateien im Repository „Yum“ vom Typ „/etc/yum.repos.d/amzn*.repo“ überschrieben, wenn das Systemversionspaket aufgerüstet wird?

Diese Konfigurationsdateien im Repository werden überschrieben, wenn das Systemversionspaket aufgerüstet wird. So ist sichergestellt, dass Instances Änderungen an der Konfiguration des Amazon Linux AMI Yum-Repository immer erkennen.
Amazon Linux AMI-Versionen vor 2014.09:
Diese Dateien werden von Cloud-Init aus Vorlagen in /etc/cloud/templates/amzn-*.repo.tmpl erstellt. Änderungen an diesen Vorlagendateien werden persistent gespeichert.

Amazon Linux AMI-Versionen ab 2014.09:

/etc/yum.repos.d/amzn*.repo-Dateien verwenden jetzt YUM-Variablen, damit die Instances die geografisch nächstgelegenen Repositorys erreichen. Es werden also keine Cloud-Init-Vorlagen mehr eingesetzt. Bei Aufrüstungen der Systemversion werden Änderungen dieser Dateien als /etc/yum.repos.d/amzn*.repo.rpmsave aufbewahrt.

Wenn Benutzer ein Aufrüstung auf 2014.09 durchführen, werden alle Bearbeitungen an /etc/yum.repos.d/amzn*.repo-Dateien als /etc/yum.repos.d/amzn*.repo.rpmsave gespeichert.

F: Wie kann ich Farben von Handbuchseiten ändern oder deaktivieren?

Farben von Handbuchseiten werden in /etc/profile.d/less.sh (bash und zsh) und /etc/profile.d/less.csh (csh) konfiguriert. Um sie zu deaktivieren, entfernen Sie alle Zeilen, die wie folgt beginnen: export LESS_ (bash, zsh) und/oder setenv LESS_ (csh).

F: Wie kann ich die Prüfung von Systemaufrufen für Instances vor 2015.09 deaktivieren?

Die Prüfung von Systemaufrufen wurde bei Neueinführungen der Amazon Linux AMI 2015.09 standardmäßig deaktiviert. Die Prüfung von Systemhinzufügungen erhöhen sich bei jedem Systemaufruf und kann zu einer spürbaren Leistungsverschlechterung führen, insbesondere bei Anwendungen, die Festplatten oder Netzwerke erfordern.

Wenn Sie eine Prüfung von Systemaufrufen benötigen, finden Sie die folgende Zeile in /etc/audit/audit.rules, entfernen Sie sie oder kommentieren Sie sie aus, und starten Sie den Audit-Daemon erneut.
-a never,task
Beispiel (als root):
# auditctl -l
LIST_RULES: Aufgabe, niemals
# sed -i.bak -e '/^-a never,task$/ s/^/#/' /etc/audit/audit.rules
# service auditd restart
# auditctl -l
No rules
Wenn Sie die gleiche Leistungsverbesserung für Instances erhalten möchten, die vor AMIs vor 2015.09 gestartet wurden, fügen Sie dieselbe Zeile ( -a never, task ) zu /etc/audit/audit.rules hinzu und starten Sie den Daemon neu. Wenn Sie eine Aufrüstung durchführen und keine Änderungen an Prüfungsregeldateien vorgenommen haben, können Sie die neue Standardregeldatei einfach nach /etc/audit/audit.rules verschieben oder kopieren
Beispiel (als 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: Aufgabe, niemals

F: Können Sie ein Beispiel für die Verwendung von MIME-mehrteiligen Benutzerdaten mit Cloud-init angeben?

Die Dokumentation zu MIME-Multipart für Cloud-init befindet sich hier.
MIME-Multipart kann ein kompliziertes Format sein. Daher sollten Sie das write-mime-multipart-Tool zum Erstellen der Multipart-Datei verwenden. Dieses Tool befindet sich im Paket cloud-utils und kann mit sudo yum install /usr/bin/write-mime-multipart installiert werden. Das Tool verwendet die erste Zeile der Datei, um den Inhaltstyp zu bestimmen und cloud-init verwendet den Inhaltstyp, um zu bestimmen, wie die Datei interpretiert werden soll. Einige Beispieldateien:
#cloud-config
repo_releasever: 2015.09
und
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
Hier ist ein Beispiel für Write-Mime-Multipart, einschließlich Ausgabe:
[ec2-user@ip-172-31-4-37 ~]$ write-mime-multipart repo_releasever-2015.09.cfg ci-was-here.sh
Inhalts-Typ: multipart/mixed; boundary="===============6347220379374809187=="
MIME-Version: 1.0
--===============6347220379374809187==
Inhalts-Typ: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Inhalt-Übertragung-Kodierung: 7bit
Inhalt-Disposition: attachment; filename="repo_releasever-2015.09.cfg"
#cloud-config
repo_releasever: 2015.09
--===============6347220379374809187==
Inhalts-Typ: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Inhalt-Übertragung-Kodierung: 7bit
Inhalt-Disposition: attachment; filename="ci-was-here.sh"
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
--===============6347220379374809187==--
Weitere Informationen zur Verwendung des Tools finden Sie unter man write-mime-multipart.

F: Wie konfiguriere ich einen VPC-Endpunkt, um Verbindungen zu Amazon Linux AMI-Repositorys zuzulassen?

Es ist möglich, ohne Internet-Zugriff auf die Yum-Speicherorte innerhalb eines VPC zuzugreifen. Ihr VPC-Endpunktrichtlinie muss Datenverkehr von Ihrem VPC zu den S3-Buckets erlauben, auf denen die Amazon Linux AMI-Speicherorte gehostet sind.
Unten sehen Sie ein Beispiel einer VPC-Endpunktrichtlinie, mit der dies erreicht wird:
{
"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/*"
]
}
]
}
Weitere Informationen finden Sie in der Dokumentation zu VPC-Endpunkten.