yum und dnf

Siehe auch

Links:

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

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“.

yum/dnf Cheat Sheet

RHEL 8+:

dnf config-manager --enable rht-updates
dnf config-manager --disable rht-updates

dnf repolist all
dnf repoquery --whatsupplements 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“:

yum grouplist

Installiert eine Paket-Gruppe:

yum groupinstall

Gibt Informationen zu einem Paket aus:

yum info sysstat

Installiert ein Paket:

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

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

yum install @perl
# or
yum module install perl

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

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

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

yum -y --allowerasing install nano

Repo hinzufügen

yum 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:

yum -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:

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

Paket entfernen

yum remove fail2ban

Bemerkung

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

Listet verfügbare Pakete auf.

yum list

Listet alle installierten Pakete auf:

yum list installed

Listet alle installierten PHP-Pakete auf:

yum list installed php*

Listet verfügbare Pakete auf:

yum list available

Prüft, ob Updates verfügbar sind:

yum 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.:

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

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

yum list updates kernel

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

yum list update kernel

Aktualisiert das Betriebssystem sowie alle installierten Pakete:

yum update

Bereits installierte Software auf eine festgelegte Versionsnummer updaten:

yum update-to openvpn-2.3.2-4.el7

Sucht nach einer Datei in allen Paketen:

yum 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:

yum 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

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:

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

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

yum -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:

yum -y install yum-plugin-security

yum updateinfo
yum list --security
yum 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:

yum -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

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 ansible
# getting "Aug 08 ... Updated: ansible-..."

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

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

# ok, try to undo
yum history undo 277

So geht es auch:

yum list ansible --showduplicates
yum downgrade ansible-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:

yum 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:

yum downgrade iptables iptables-ipv6

… oder explizit eine bestimmte Version installieren:

yum -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

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

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:

yum 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):

yum --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:

yum 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
yum 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

Built on 2022-06-03