4.4. Software-Management (Maschinenübersetzung)
YUM Leistungssteigerung und Unterstützung für modulare Inhalte
Auf Red Hat Enterprise Linux 8 wird die Softwareinstallation durch die neue Version des YUM-Tools gewährleistet, das auf der DNF-Technologie basiert.
YUM auf DNF-Basis hat folgende Vorteile gegenüber dem bisherigen YUM v3 auf RHEL 7:
- Leistungssteigerung
- Unterstützung für modulare Inhalte
- Gut durchdachte, stabile API zur Integration mit Werkzeugen
Detaillierte Informationen über die Unterschiede zwischen dem neuen YUM-Tool und der Vorgängerversion YUM v3 von RHEL 7 finden Sie unter http://dnf.readthedocs.io/en/latest/cli_vs_yum.html.
YUM basierend auf DNF ist kompatibel mit YUM v3, wenn Sie von der Befehlszeile aus arbeiten, Konfigurationsdateien bearbeiten oder erstellen.
Für die Installation von Software können Sie den yum
Befehl und seine einzelnen Optionen wie bei RHEL 7 verwenden. Pakete können unter den bisherigen Namen mit Provides
. Pakete bieten auch Kompatibilitäts-Symlinks, so dass die Binärdateien, Konfigurationsdateien und Verzeichnisse an üblichen Stellen zu finden sind.
Beachten Sie, dass die von YUM v3 bereitgestellte alte Python-API und die Libdnf C-API instabil sind und sich während des Lebenszyklus von Red Hat Enterprise Linux 8 wahrscheinlich ändern werden. Benutzern wird empfohlen, ihre Plugins und Skripte auf die neue DNF Python API zu migrieren, die stabil und vollständig unterstützt wird. Die DNF Python API ist verfügbar unter https://dnf.readthedocs.io/en/latest/api.html
Einige der YUM v3-Funktionen können sich in YUM basierend auf DNF unterschiedlich verhalten. Wenn sich eine solche Änderung negativ auf Ihre Arbeitsabläufe auswirkt, öffnen Sie bitte einen Fall mit Red Hat Support, wie unter How do I open and manage a support case on the Customer Portal?
(BZ#1581198)
Bemerkenswerte Drehzahlmerkmale in RHEL 8
Red Hat Enterprise Linux 8 wird mit RPM 4.14 ausgeliefert. Diese Version enthält viele Verbesserungen gegenüber RPM 4.11, das in RHEL 7 verfügbar ist. Zu den bemerkenswertesten Merkmalen gehören:
-
Die
debuginfo
Pakete können parallel installiert werden - Unterstützung bei schwachen Abhängigkeiten
- Unterstützung von reichen oder booleschen Abhängigkeiten
- Unterstützung für das Paketieren von Dateien mit einer Größe von mehr als 4 GB
- Unterstützung von Datei-Triggern
Zu den wichtigsten Änderungen gehören auch:
- Strengerer Spec-Parser
- Vereinfachte Signatur zur Überprüfung der Ausgabe im non-verbosen Modus
- Zu- und Abschreibung in Makros
(BZ#1581990)
RPM validiert nun den gesamten Paketinhalt, bevor mit der Installation begonnen wird
Auf Red Hat Enterprise Linux 7 verifizierte das RPM-Dienstprogramm beim Entpacken den Inhalt der Nutzlast einzelner Dateien. Dies ist jedoch aus mehreren Gründen nicht ausreichend:
- Wenn die Payload beschädigt ist, wird sie erst nach der Ausführung von Skript-Aktionen bemerkt, die irreversibel sind.
- Wenn die Nutzlast beschädigt ist, bricht das Upgrade eines Pakets ab, nachdem einige Dateien der vorherigen Version ersetzt wurden, was eine funktionierende Installation unterbricht.
- Die Hashes für einzelne Dateien werden auf unkomprimierten Daten ausgeführt, was die RPM anfällig für Dekompressorschwachstellen macht.
Bei Red Hat Enterprise Linux 8 wird das gesamte Paket vor der Installation in einem separaten Schritt mit dem besten verfügbaren Hash validiert.
Pakete, die auf Red Hat Enterprise Linux 8 basieren, verwenden einen neuen SHA256
Hash auf der komprimierten Nutzlast. Bei signierten Paketen ist der Payload-Hash zusätzlich durch die Signatur geschützt und kann daher nicht geändert werden, ohne eine Signatur und andere Hashes auf dem Paketkopf zu brechen. Ältere Pakete verwenden den MD5
Hash des Headers und der Payload, es sei denn, er wird durch die Konfiguration deaktiviert, z.B. im FIPS-Modus.
Mit dem Makro`%_pkgverify_level` kann zusätzlich die Signaturprüfung vor der Installation erzwungen oder die Nutzlastverifizierung vollständig deaktiviert werden. Darüber hinaus kann das %_pkgverify_flags
Makro verwendet werden, um einzuschränken, welche Hashes und Signaturen erlaubt sind. So ist es beispielsweise möglich, die Verwendung des schwachen MD5
Hash auf Kosten der Kompatibilität mit älteren Paketen zu deaktivieren.
(JIRA:RHELPLAN-1499)