yum und dnf

Siehe auch

Software sollte soweit wie nur möglich per Paketmanager installiert und gefpelegt werden. Das Tool der Wahl auf RHEL-basierten Systemen ist yum (ab RHEL 8+ dnf), der ursprünglich aus CentOS stammende Paket-Manager „Yellowdog Updater, Modified“. In Fedora 22 wurde yum gegen die verbesserte Variante dnf („Dandified YUM“) ausgetauscht. Das grafische GNOME-Frontend zu yum heisst „PackageKit“.

  • RHEL 7: yum v3

  • RHEL 8+: hier kommt das auf dnf basierende yum v4 zum Einsatz (yum ist ein symbolischer Link auf dnf)

Was sind dnf Modules, Streams und Profiles?

  • Module sind Paketgruppen, meist für Applikationen, Language Runtimes oder Toolsets.

  • Streams spezifizieren in den meisten Fällen die Major-Version. Streams, die „enabled“ sind, werden mit einem [e] in dnf module list angezeigt, „default“-Streams mit [d]. Nicht alle Module haben einen default-Stream.

  • Profiles geben den Use Case an, beispielsweise „client“, „common“, development“ oder „minimal“. Nicht alle Module haben ein default-Profile.

Beispiel:

  • dnf -y module install NAME:STREAM/PROFILE wird dann konkret beispielsweise zu dnf -y module install redis:redis-7.2/common oder dnf -y module install mongodb/client.

Links:

Doku: https://dnf.readthedocs.io/en/latest

yum/dnf Cheat Sheet

RHEL 8+:

dnf-config-manager --disable 'remi-php*'
dnf-config-manager --enable remi-php74

dnf repolist all
dnf repoquery --whatsupplements langpacks-fr

# list files in a package
dnf repoquery --list langpacks-fr

dnf list httpd
dnf list installed httpd
dnf search httpd
dnf info httpd

dnf install httpd
dnf remove httpd

dnf group list
dnf group info "Security Tools"
dnf group install "Security Tools"

dnf module list
dnf module list --installed
dnf module list httpd
dnf module info httpd
dnf module info --profile httpd:2.4

dnf module reset httpd
# Install PHP 8.1 and Redis 6.2 from Remi-Repo
dnf module install php:remi-8.1
dnf module install redis:remi-6.2

dnf module remove httpd
dnf module disable httpd

dnf update

dnf history
dnf history info 6
dnf history undo 5

Umgang mit yum/dnf erklärt

Listet verfügbare Paket-Gruppen auf. Beispiel „GNOME Desktop“:

dnf grouplist

Installiert eine Paket-Gruppe:

dnf groupinstall

Gibt Informationen zu einem Paket aus:

dnf info sysstat

Installiert ein Paket:

dnf install nano
dnf -y install openvpn-2.3.2-4.el7

Installiert ein Modul (ab yum 4 / RHEL 8+):

dnf install @perl
# or
dnf module install perl

Nur runterladen, aber nicht installieren (wird der Download abgebrochen und erneut gestartet, fängt dieser wieder von vorne an):

dnf --downloadonly --downloaddir=/root install nano

Installiert das Paket, erlaubt yum aber, falsche Bibliotheksversionen (meist neuere) zu deinstallieren und durch passende zu ersetzen:

dnf -y --allowerasing install nano

Repo hinzufügen

dnf install yum-utils
yum-config-manager --add-repo https://www.collaboraoffice.com/repos/CollaboraOnline/CODE-centos7

Deaktiviert im Beispiel das EPEL-Repository, damit ein Paket garantiert nicht aus diesem bezogen wird:

dnf -y --disablerepo=epel --allowerasing install openvas
# persistent
yum-config-manager --disable epel

Installation einer neueren Applikation aus einem anderen Repository, welches mit den RHEL-Repositories kollidiert. Im Beispiel werden alle Repositories deaktiviert, bestimmte externe Repositories aktiviert und PHP aus letzteren installiert:

dnf -y --disablerepo=* --enablerepo=remi-php55,remi install php

Paket entfernen

dnf remove fail2ban

Bemerkung

Fast alle Pakete sind so gebaut, dass ein yum remove angepasste Konfigurationsdateien nicht entfernt.

Listet verfügbare Pakete auf.

dnf list

Listet alle installierten Pakete auf:

dnf list installed

Listet alle installierten PHP-Pakete auf:

dnf list installed php*

Listet verfügbare Pakete auf:

dnf list available

Prüft, ob Updates verfügbar sind:

dnf list updates

Verfügbare Updates für Apache, PHP, MariaDB oder cURL anzeigen (der Befehl liefert den Status-Code 100 zurück, wenn Updates vorliegen.:

dnf check-update | grep -i 'apache\|php\|mysql\|curl'

Wie oben, aber eingeschränkt auf z.B. den Kernel:

dnf list updates kernel

Listet alle installierten Kernel auf und prüft zusätzlich, ob eine neue Kernel-Version als Update verfügbar ist:

dnf list update kernel

Aktualisiert das Betriebssystem sowie alle installierten Pakete:

dnf update

Bereits installierte Software auf eine festgelegte Versionsnummer updaten:

dnf update-to openvpn-2.3.2-4.el7

Sucht nach einer Datei in allen Paketen:

dnf whatprovides */sar

Pakethistorie - alle Pakete anzeigen lassen, die nicht zur Basisausstattung der Distribution gehören, sondern die manuell installiert wurden:

dnf history userinstalled

Yum-Datenbank sowie verwaiste Dateien in /var/cache/yum bereinigen und Liste der schnellsten Mirror-Server löschen - dies sollte vor allen Dingen dann gemacht werden, wenn Repos deaktiviert oder entfernt wurden:

dnf clean all

Bemerkung

Die Option -y bzw. --assumeyes beantwortet die Nachfrage Is this ok [y/d/N] automatisch mit einem „Yes“.

Mirror-Server zu langsam, zu wenig aktuell, gibt immer wieder Fehler? Einfach ignorieren:

/etc/yum/pluginconf.d/fastestmirror.conf
exclude = mirror.example.com

Package Key Rotation

Die Maintainer tauschen den GPG- oder RSA-Key beispielsweise aus Gründen der Sicherheit oder des Alters aus? Hier am Beispiel des Icinga-Repos, gilt aber für alle Repos.

Falls die Maschine bereits Pakete aus dem Repo installiert hat, lassen sich diese danach nicht mehr aktualisieren (und auch keine weiteren aus dem Repo installieren). yum/dnf beschwert sich dann mit folgendem Fehler:

dnf -y install icinga2-doc

GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ICINGA (0x34410682) is already installed
The GPG keys listed for the "ICINGA (stable release)" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.. Failing package is: icinga2-doc-2.14.2-1.el8.x86_64
 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ICINGA
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED

Passiert, wenn der Repo-Key als Datei abgelegt wurde (/etc/yum.repos.d/ICINGA-release.repo definiert die Ablage des Keys in /etc/pki/rpm-gpg/RPM-GPG-KEY-ICINGA). Man benötigt also den neuen Key.

Wer LFOps/Ansible benutzt:

  • Re-Deployment der Repo-Definitionen per Ansible

Wer das manuell oder per Ansible Ad-hoc-Kommando macht:

# download the new key
curl --output /etc/pki/rpm-gpg/RPM-GPG-KEY-ICINGA https://packages.icinga.com/icinga.key
# import the new key to the rpm database
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-ICINGA

Was auch geht: Alternativ kann man auch ein unbedeutendes und winziges Paket aus dem Repo installieren, und so neben der Installation auch ein Update des Keys erzwingen:

dnf -y install icinga2-doc
dnf -y remove icinga2-doc

Kernel-Versionen verwalten

yum ist in der Lage, den Kernel upzugraden oder bestimmte Kernel-Versionen zu installieren. Standardmässig hält yum fünf, dnf dagegen drei Kernel-Versionen vor, in die man die Maschine booten kann. Unter Umständen hilft es, die Anzahl zu erhöhen, besonders unter Fedora Workstation:

/etc/yum.conf
installonly_limit=10

Jede einzelne Kernel-Version beansprucht auf /boot knapp 70 bis 100 MB Plattenplatz.

So installiert man eine bestimmte Kernel-Version:

dnf list kernel
dnf -y install kernel-3.10.0-229.11.1.el7

So entfernt man alle alten Kernel-Versionen, bis auf die beiden neuesten:

dnf -y install yum-utils
package-cleanup --oldkernels --count=2

Version Pinning

Das Kapitel hat eine eigene Seite spendiert bekommen: Version-Pinning.

Nur sicherheitskritische Updates

Wer beispielsweise im Rahmen von Common Criteria nur sicherheitskritsche Updates installieren und Bug Fixes sowie Erweiterungen (Enhancements) aussen vor lassen möchte, verwendet yum so:

dnf -y install yum-plugin-security

dnf updateinfo
dnf list --security
dnf update --security

Automatische Updates

yum hält nicht nur das Betriebssystem, sondern sämtliche über den Paketmanager installierte Software auf dem aktuellsten Stand. Das betrifft Behebung von Fehlern und besonders die Schliessung von Sicherheitslücken. Letztere werden nach dem Common Vulnerabilities and Exposures (CVE)-Standard benannt, einer einheitlichen Namenskonvention für Schwachstellen und Sicherheitsrisiken, wodurch ein reibungsloser Informationsaustausch zwischen den verschiedenen Datenbanken einzelner Hersteller möglich ist.

Folgendes Tool gibt Auskunft darüber, welche Prozess-IDs nach einem yum update neu gestartet werden müssen:

dnf -y install yum-utils

# long list of all updated services (process list)
needs-restarting

# list the affected systemd services only
needs-restarting --services

# kernel-updates and full reboot necessary? check the return code (<> 0: needs reboot)
needs-restarting --reboothint

So kann man automatische Updates per Cron einrichten: yum soll dabei ausschliesslich Fehler per E-Mail melden (Voraussetzung ist, dass bereits der E-Mail-Versand in cron konfiguriert ist) und zufällig zwischen 03:00 und 03:59 Uhr in der Nacht ausgeführt werden.

echo '00 03 * * *  sleep $(( $RANDOM \% 3540)); /usr/bin/yum -y --errorlevel=0 update 1> /dev/null; /usr/bin/needs-restarting > /tmp/nr; if [ -s /tmp/nr ]; then /usr/sbin/reboot; fi' >> /var/spool/cron/root

Downgrade / Undo

Funktioniert nur bei Paketen, die in nur einer Version installiert werden können - also beispielsweise nicht für den Linux-Kernel, C-Libraries, SELinux oder D-Bus.

Warnung

Downgrade auf Produktivsystemen? Vorher prüfen, ob ein Backup des Systems vorhanden ist.

Möglicherweise lässt sich ein Downgrade so durchführen:

cat /var/log/yum.log | grep mypackage
# getting "Aug 08 ... Updated: mypackage-..."

# list the Yum-IDs for all updates
dnf history
# looking for the ID on updates from Aug 08
# getting "277"

# what was done during the update?
dnf history info 277

# ok, try to undo
dnf history undo 277

So geht es auch:

dnf list mypackage --showduplicates
dnf downgrade mypackage-2.7.10-1.el7.noarch

Erhält man die Meldung Only Upgrade available on package ..., dann ist die alte Version (aus gutem Grund) aus den Basis-Repositories entfernt worden. In dem Fall das Vault-Repo aktivieren: das Repository für den alten Kram. Auf einem CentOS 6.7 aktiviert man dann beispielsweise das [C6.6-base]:

/etc/yum.repos.d/CentOS-Vault.repo
[C6.6-base]
name=CentOS-6.6 - Base
baseurl=http://vault.centos.org/6.6/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=1

Jetzt kann die Suche nach alten Versionen wieder wie oben starten.

Der eigentliche Downgrade liefert einen Fehler - Yum kann Paketabhängigkeiten beim Downgrade (zum Glück) nicht auflösen? Hier ist Handarbeit angesagt:

dnf downgrade iptables
# Resolving Dependencies
# ---> Package iptables.x86_64 0:1.4.7-14.el6 will be a downgrade
# ---> Package iptables.x86_64 0:1.4.7-16.el6 will be erased
# Error: Package: iptables-ipv6-1.4.7-16.el6.x86_64 (@base)
#            Requires: iptables = 1.4.7-16.el6

Daher gilt:

dnf downgrade iptables iptables-ipv6

… oder explizit eine bestimmte Version installieren:

dnf -y install iptables-1.4.7-14.el6

Warnung

Die Pakete werden beim nächsten yum update natürlich wieder aktualisiert. Um das im Beispiel für iptables zu verhindern, konfiguriert man Yum:

echo "exclude=iptables*" >> /etc/yum.conf

Nach der Aktion nicht vergessen, das Vault-Repository wieder zu deaktivieren.

Alle Updates und Software-Installationen verhindern:

echo "exclude=*" >> /etc/yum.conf

rpmnew- und rpmsave-Dateien

Was ist der Unterschied zwischen einer *.rpmnew- und einer *.rpmsave-Datei?

Die Basis für die Paketmanager yum und dessen Nachfolger dnf sind RPM-Pakete. Ein gut definiertes RPM-Paket kennt den Unterschied zwischen Konfigurationsdateien und anderen Dateitypen und regelt auch den Umgang mit ihnen, für den Fall, dass ein Paket-Update mit neueren Konfigurationsdateien kommt, diese aber durch den Systemadmin bereits angepasst wurden - ein Überschreiben der Konfigurationsdateien wird somit vermieden.

Ein SysAdmin sollte nach jedem Update nach diesen Dateien suchen, und falls gefunden untersuchen und vergleichen.

rpmnew - the new default config file

rpmnew-Dateien werden angelegt, falls ein Update Änderungen an den originalen Konfigurationsdateien mit sich bringt - sei es, dass Einstellungen hinzugekommen oder weggefallen sind oder sich bestehende geändert haben. Es handelt sich dabei also um die originale Konfigurationsdatei in einer neuen Version. Die bestehende Konfigurationsdatei bleibt unangetastet. Die Neuerungen muss man manuell untersuchen und gegebenenfalls die ursprüngliche Konfigurationsdatei entsprechend nachziehen. Anschliessend kann die .rpmnew-Datei gelöscht werden.

rpmsave - your old config file backed up

Das Update bringt so viele oder wichtige Änderungen an den Konfigurationsdateien mit sich, dass sie vom Paketmanager ausgetauscht wurden. Die Konfigurationsdateien aus dem Update kommen also zum Zug. Die ursprünglich vom Systemadmin vorgesehene Version wird mit der Endung rpmsave versehen. Diese Dateien bleiben auch bei der Deinstallation diverser Pakete wie z.B. chrony oder rsyslog auf dem System liegen.

Um anzupassende Konfigurationsdateien zu finden und zu bearbeiten, gibt es zwei Wege: entweder find / -name *.rpmnew, und dann diff, mv, cp, rm, whatever…, oder rpmconf verwenden:

dnf install rpmconf
rpmconf --all

Configuration file '/var/lib/unbound/root.key'
-rw-r--r--. 1 unbound unbound  818 Aug  4  2017 /var/lib/unbound/root.key.rpmnew
-rw-r--r--. 1 unbound unbound 1250 Sep 24 20:06 /var/lib/unbound/root.key
==> Package distributor has shipped an updated version.
  What would you like to do about it ?  Your options are:
   Y or I  : install the package maintainer's version
   N or O  : keep your currently-installed version
     D     : show the differences between the versions
     M     : merge configuration files
     Z     : background this process to examine the situation
     S     : skip this file

The default action is to keep your current version.

Repos

Umgang mit Repos

Kurzfristig ein sonst deaktiviertes Repo verwenden (angenommen, EPEL wäre deaktiviert):

dnf --enablerepo epel install ntfs-3g

Ein Repo dauerhaft deaktivieren - 3 Wege:

  1. repo-Datei editieren und enabled=1 auf enabled=0 stellen

  2. yum-config-manager --disable epel

  3. mv /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.disabled

Jede andere Dateiendung als .repo führt dazu, dass die Repo-Datei ignoriert wird.

Verhalten bei Repo-Änderungen

Angenommen, MariaDB-server wird aus Repo A installiert, und yum info MariaDB-server zeigt erwartungsgemäss an, dass das Paket aus Repo A stammt. Nun wird Repo A entfernt, und ein völlig anderes Repo B aktiviert - mit neuer Download-URL und anderen (neueren) Versionen von MariaDB-server. Es wird ein yum update durchgeführt - was passiert?

Yum wird das Paket aus dem neuen Repo B ziehen und updaten, egal, ob es ursprünglich aus Repo A stammte. Wichtig ist nur, dass der Name des Software-Paketes übereinstimmt.

Aufbau einer Repo-Konfigurationsdatei

Ein Beispiel für eine minimale Repository-Konfigurationsdatei:

/etc/yum.repos.d/internal.repo
[inhouse]
name=my internal repo
baseurl=http://mirror/$releasever/$basearch/
gpgcheck=0

Wie sieht man, mit was $releasever, $basearch und andere yum-Variablen gefüttert werden?

  • RHEL 7: python -c 'import yum, json; yb = yum.YumBase(); print json.dumps(yb.conf.yumvar, indent=2)'

  • RHEL 8: /usr/libexec/platform-python -c 'import dnf, json; db = dnf.dnf.Base(); print(json.dumps(db.conf.substitutions, indent=2))'

Sonstiges

Outboud Proxy

echo $http_proxy
/etc/yum.conf
# The proxy server - proxy server:port number
proxy=http://mycache.mydomain.com:3128
# The account details for yum connections
proxy_username=yum-user
proxy_password=qwerty

Caching

Daten und Pakete, die Yum für die Installation oder zur Aktualisierung benötigt und heruntergeladen hat, werden nach erfolgreicher Anwendung gelöscht, was den Speicherplatzverbrauch minimiert. Yum lässt sich so konfigurieren, dass es die Dateien behält, indem man Caching einschaltet:

sed -i "s/.*keepcache=0.*/keepcache=1/g" /etc/yum.conf

Vorteile:

  • Yum arbeitet schneller.

  • Yum kann so auch ohne Netzwerkverbindung und nur auf Basis des Caches arbeiten.

  • Pakete lassen sich aus dem Cache kopieren und woanders einsetzen.

So aktiviert man die Einstellung ohne Installation von Software:

dnf list

Der in /var/cache/yum erzeugte Cache wird inkl. der heruntergeladenen RPMs auf einem RHEL 7 Minimalsystem schnell um die 500 MB gross. Das Cache-Verzeichnis kann bei Bedarf jederzeit per rm -rf /var/cache/yum/* geleert werden.

Verifying Keys

Prüfen des Keys eines Packages:

rpm --checksig PACKAGE_FILE

yum.log

Was bedeutet die „1:“, „32:“ usw. vor dem Paketnamen im yum.log?

Beispiel:

1:grub2-common-2.02-0.65.el7.centos.2.noarch
1:grub2-pc-modules-2.02-0.65.el7.centos.2.noarch
32:bind-license-9.9.4-51.el7_4.1.noarch

Die Zahl bezeichnet die RPM-Epoche (Standard: „0:“) - sie überschreibt die normale Reihenfolge im Versionsvergleich. Möchte man also als Package-Maintainer ein älteres Paket als Upgrade definieren, arbeitet man mit RPM-Epochennummern > 0.

Troubleshooting

Error in PREIN scriptlet in rpm package xyz-7.0, xyz-6.0 was supposed to be removed but is not!

In diesem konkreten Beispiel ist das 7.0-Paket davon ausgegangen, dass das 6.0-Paket entfernt wurde - ist es aber nicht, oder aber die RPM-Datenbank und der yum-Cache sind nicht mehr synchronisiert. Das kann helfen:

# not critical
dnf clean all
rpm --rebuilddb
package-cleanup --problems

Falls immer noch nicht, kann man das probieren, aber Obacht: Am Ende war die Installation kaputt.

# Be careful: this is done without any "are you sure" prompting
rpm --erase --noscripts --nodeps openvas-scanner-6.0.0-6930.el7.art.x86_64
Problem: cannot install both iptables-libs-1.8.10-4.el9_4.x86_64 from baseos and iptables-libs-1.8.10-2.el9.x86_64 from @System

Detaillierte Meldung:

  • package iptables-legacy-1.8.10-2.2.el9.x86_64 from @System requires (iptables-libs(x86-64) = 1.8.10-2.el9 or iptables-libs(x86-64) = 1.8.10-2.el9_1), but none of the providers can be installed

  • cannot install the best update candidate for package iptables-libs-1.8.10-2.el9.x86_64

  • cannot install the best update candidate for package iptables-legacy-1.8.10-2.2.el9.x86_64

Abhilfe:

dnf update --allowerasing
dnf install iptables
reboot

Built on 2024-11-18