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 in 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 weitverbreitete 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: 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 oft werden Updates für das Amazon Linux AMI verfügbar sein?

Das Amazon Linux AMI wird als rotierende Freigabe erstellt und gewartet. Unsere Benutzer sollten sich Amazon Linux AMI als einen Fluss mit Paketen vorstellen, von dem die AMI-Abbilder selbst nur ein Snapshot zu einer bestimmten Zeit sind.

 

Es wird vorausgesetzt, dass eine rotierende Freigabe sicherstellt, dass unsere Amazon Linux AMIs und unsere Kundeninstances, die auf diesen AMIs basieren, die neuesten Funktionen von EC2 und AWS bei deren Start unterstützen. Damit dient Amazon Linux AMI auch als Referenzpunkt für andere Linux AMI-Hersteller (sowohl Drittanbieter und Subunternehmer von Amazon Linux AMI), damit diese die Funktion ebenfalls unterstützen können.

 

Dieses Modell bedeutet, dass die Kunden mit höherer Wahrscheinlichkeit die neusten Sicherheits-, Leistungs- und Funktionsverbesserungen ausführen, womit eine große Anzahl möglicher Probleme bereits gelöst sind.

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: Wird das Amazon Linux AMI auch außerhalb von EC2 unterstützt?

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

F: Wie können Fehler gemeldet und Anforderungen 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?

Seit der Version von Amazon Linux AMI ist die Repository-Struktur darauf konfiguriert, einen fortlaufenden Fluss von Updates bereitzustellen, die Ihnen gestatten, fließend von einer Version des Amazon Linux AMI zur nächsten überzugehen.

Paketaktualisierungen werden immer per Push-Verfahren in die Repositorys geladen und sind in jeder Version von Amazon Linux AMI verfügbar, in der Yum so konfiguriert ist, dass auf die "letzte" verwiesen wird. Sie können erkennen, auf welche Repositorys Ihre Instance verweist, indem Sie sich die Variable "releasever" in /etc/yum.conf  anschauen – standardmäßig ist diese für Amazon Linux AMI auf releasever=latest gesetzt.

Anders gesagt, Amazon Linux AMIs werden als zeitpunktbezogene Snapshots behandelt und weisen eine Repository- und Update-Struktur auf, mit der Sie stets über die neuesten Pakete verfügen, die wir erstellt und per Push-Verfahren in das Repository geladen 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.

Wenn Sie diese Funktion in neuen Instances aktivieren möchten, starten Sie z. B. ein 2015.09 Amazon Linux AMI, wobei folgende Benutzerdaten entweder über die EC2-Konsole oder über aws ec2 run-instances mit dem Flag --user-data flag (dies ist auch mit ec2-run-instances -f möglich ) an cloud-init übergeben werden.

#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 aus, und führen Sie dann yum clean all aus, um den Cache zu löschen.

HINWEIS: Wenn Sie Ihr AMI mit einer 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 Nutzerdaten und leiten Sie sie an das Flag aws ec2 run-instances with the --user-data file:// 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
  • Trennen Sie das Volume ab.
  • 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 aktualisiert wird?

Diese Konfigurationsdateien im Repository werden überschrieben, wenn das Systemversionspaket aktualisiert 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 Upgrades der Systemversion werden Änderungen dieser Dateien als /etc/yum.repos.d/amzn*.repo.rpmsave aufbewahrt.

Wenn Benutzer ein Upgrade 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: LESS_ (bash, zsh) und/oder setenv LESS_ (csh).

F: Wie aktiviere ich Systemaufrufauditierung in Instances, die vor 2015.09 erstellt wurden?

Systemaufrufauditierung wurde standardmäßig bei neuen Starts von 2015.09 Amazon Linux AMI deaktiviert.  Systemaufrufauditierung erzeugt zusätzliche Last bei jedem Systemaufruf und kann besonders in laufwerks- oder netzwerkintensiven Anwendungen zu erheblichen Leistungseinbußen führen.

Wenn Sie Systemaufrufauditierung benötigen, suchen Sie die folgende Zeile in /etc/audit/audit.rules und entfernen Sie sie oder kommentieren Sie aus. Starten Sie den Auditdämon dann erneut.

 -a never,task

Beispiel (als Root):

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

Wenn Sie dieselbe Leistungsverbesserung für Instances erhalten möchten, die vor 2015.09 AMIs gestartet wurden, fügen Sie dieselbe Zeile (  -a never,task ) zu /etc/audit/audit.rules hinzu. Starten Sie dann den Dämon erneut. Wenn Sie ein Upgrade durchführen und keine Änderungen an Dateien mit Auditregeln vorgenommen haben, können Sie die neuen Dateien mit den Standardregeln einfach in /etc/audit/audit.rules verschieben oder kopieren.

Beispiel (als Root)

# auditctl -l
Keine Regeln
# 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

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

Die Dokumentation für MIME-Multipart für cloud-ini ist hier zu finden.

MIME-Multipart kann ein schwieriges Format sein. Daher wird empfohlen, das Werkzeug write-mime-multipart zum Erzeugen der Multipart-Datei zu verwenden. Dieses Werkzeug befindet sich im Paket cloud-utils und kann mit sudo yum install /usr/bin/write-mime-multipart installiert werden. Das Werkzeug verwendet die erste Zeile in der Datei, um den Inhaltstyp zu bestimmen. 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

Es folgt ein Beispiel für eine write-mime-multipart inklusive Ausgabe:

[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: 7 bit
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: 7 bit
Content-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 Werkzeugs finden Sie unter man write-mime-multipart.

F: Wie kann ich einen VPC-Endpunkt konfigurieren, um Verbindungen zu den Amazon Linux AMI-Speicherorten zu erlauben?

Es ist möglich, ohne Internet-Zugriff auf die Yum-Speicherorte innerhalb eines VPC zuzugreifen.  Ihr VPC-Endpunkt 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.