AWS EC2: Patches für Amazon Linux einspielen mit yum

    yum Package ManagerNach dem Er­zeugen einer Instanz aus einem Linux-AMI muss der virtuelle Server regel­mäßig mit Updates ver­sorgt werden. Amazon stellt zu diesem Zweck für seine beiden Linux-Varianten zwei vor­kon­figurierte Yum-Repositories bereit. Die weit­gehend auto­matisierte Aktuali­sierung des AMI lässt sich manuell anpassen.

    Beim Erzeugen einer Amazon-Linux-Instanz aus dem AMI werden Sicherheits-Updates automatisch aus den konfi­gurierten Repos eingespielt, und zwar vor dem Start von Diensten wie SSH. Bei der Anmeldung zeigt die Meldung des Tages (/etc/motd) an, ob zusätzliche Aktualisierungen verfügbar sind.

    Nach dem Login erhält der Benutzer einen Hinweis auf die verfügbaren Updates.

    yum-Konfiguration anzeigen

    Die Paket­quellenliste ist unter /etc/yum.repos.d verfügbar. Ein Blick in amzn-main-repo offenbart die repo-Details und ob das Repo aktiv ist ("enabled=1"). Wie die URL für mirrorlist zeigt, benötigt die Instanz einen Internetzugang für den Zugriff auf das Repo.

    Die datei amzn-main-repo enthält die Einstellungen für die konfigurierten Repositories.

    Der Zugriff auf die Repos erfolgt wie bei RHEL, CentOS und Fedora üblich, mithilfe des Aktualisierungs-Tools yum. Da die Repositories in jeder Region gehostet sind, kann AWS Updates schnell und ohne zusätzliche Daten­übertragungs­kosten bereitstellen.

    Die Verwandtschaft zur Red-Hat-Familie zeigt sich auch am vorbereiteten Epl-Repo, das allerdings nicht per Default aktiviert ist (enabled = 0). Dies lässt sich aber durch Bearbeiten mit einen Editor wie nano, vim oder vi (vorinstalliert) schnell beheben.

    Kontinuierliche Updates

    AWS erstellt und wartet das Linux-AMI als Rolling Release, so dass Nutzer kontinuierlich von einer Version zur nächsten über­gehen können. Unter diesem Verfahren kann man sich einen "Fluss von Paketen" vorstellen, wobei die Images immer ein Snapshot zu einer bestimmten Zeit sind.

    Der obligatorische erste Befehl in jedem User-Daten-Script

    yum update -y

    bleibt aber trotzdem sinnvoll, auch wenn sich die Benutzer um Sicherheits-Patches praktisch nicht kümmern müssen.

    AWS lädt Paket­aktualisierungen per Push-Verfahren in die Repositories hoch und macht sie auch in jeder neuen Version von Amazon Linux AMI verfügbar. yum ist dabei so konfiguriert ist, dass es auf das jeweils letzte Release verweist, was ein Blick auf die Variable

    releasever=latest

    in /etc/yum.conf zeigt.

    Anstatt des neuesten Releases kann man Amazon Linux auch auf eine bestimmte Version festlegen.

    Allerdings können Nutzer bei Bedarf mit der Funktion Lock and Launch eine bestimmte Version ihrer AMIs beibehalten, so dass diese keine Paket­aktualisierung erhalten, wenn AWS neue Haupt­versionen von Amazon Linux AMI freigibt.

    Dies kann man etwa beim Instanziieren erreichen, indem man in den User-Daten etwa repo_releasever: 2015.09 verwendet. Außerdem kann man sich, sofern gewünscht, fest auf eine bestimmte Version festlegen, indem man diese in /etc/system-release einträgt, dann in /etc/yum.conf die Zeile releasever=latest auskommentiert. Zum Abschluss führt man

    yum clean all

    aus, um den Cache zu löschen.

    Deaktivieren von automatischen Sicherheits-Updates

    Kann die Instanz nicht auf die konfigurierten yum-Paketquellen zugreifen, dann wird die Aktuali­sierung nach mehreren Wieder­holversuchen abgebrochen. Mögliche Gründe dafür können ein­schränkende Security-Group- oder VPC-Einstellungen (Route Tables, Subnets) sein, die einen Zugriff auf die Paket-Repositories verhindern.

    Auch Instanzen in einem privaten Subnetz sollten sich zum Beispiel über einen NAT-Dienst oder eine NAT-Instanz beim ersten Start mit Aktualisierungen und später mit Updates versorgen können. Man kann aber eine Sicherheits­aktualisierung beim Systemstart auch bewusst unterbinden, indem man den User-Daten

    #cloud-config
    repo_upgrade: none

    mitgibt. Andernfalls kann man nach dem Provisionieren der Instanz an der Konsole die Datei /etc/cloud/cloud.cfg bearbeiten und den Eintrag

    repo_upgrade: security

    zu

    repo_upgrade: none

    ändern.

    Keine Kommentare