dnf, rpm i repozytoria

Wstęp

piątek, 16:45, terminal na serwerze z RHEL, właśnie skończyło się dnf upgrade, a w drugim oknie aplikacja wyrzuca błędy

Piątek, za kwadrans piąta. Zrobiłeś aktualizację, a aplikacja przestała działać. Na Ubuntu zaczynasz grzebać: co się zmieniło, z jakiej wersji na jaką, jak to cofnąć.

Na Red Hacie wpisujesz dwie komendy. Pierwsza pokazuje historię wszystkich operacji na pakietach z numerami. Druga cofa wybraną operację. Ctrl+Z dla całego serwera.

Dziś hurtownia Red Hata od zaplecza: dnf, rpm, pliki repozytoriów, płyta ISO jako hurtownia bez internetu, EPEL i łatki bezpieczeństwa.

Zanim cokolwiek: rejestracja (tylko RHEL)

Red Hat Enterprise Linux to system z subskrypcją. Dopóki nie zarejestrujesz maszyny, hurtownia Red Hata jest dla Ciebie zamknięta. Rocky Linux i AlmaLinux tego kroku nie mają, tam hurtownie są otwarte od razu.

sudo subscription-manager register
sudo subscription-manager repos --list-enabled

Pierwsza zapyta o login i hasło do konta Red Hat. W firmie częściej zobaczysz wersję z kluczem aktywacyjnym, bez wpisywania haseł:

sudo subscription-manager register --activationkey=<nazwa_klucza> --org=<ID_organizacji>

Druga pokazuje, do których repozytoriów masz dostęp. Na świeżym RHEL 10 zobaczysz tam BaseOS i AppStream.

Hurtownie: repolist i pliki .repo

Do pokazów w tej lekcji zbudowałem sobie malutki pakiet powitanie i własną hurtownię z dwiema jego wersjami. Dzięki temu zobaczysz każdą operację od A do Z, bez czekania na prawdziwe aktualizacje. Wszystkie komendy działają identycznie z hurtowniami Red Hata.

dnf repolist

repo id                        repo name
lokalne                        Lokalne repozytorium kursu

Na prawdziwym RHEL zobaczysz tu dwie linijki z BaseOS i AppStream. Skąd dnf wie o hurtowniach? Z plików w /etc/yum.repos.d/. Nazwa folderu to pamiątka po yumie. Zajrzyjmy do mojego:

[lokalne]
name=Lokalne repozytorium kursu
baseurl=file:///srv/repo
enabled=1
gpgcheck=0

W nawiasie kwadratowym identyfikator. name to opis dla ludzi. baseurl to adres hurtowni: https:// dla serwera w internecie, file:// dla folderu na dysku. enabled=1 znaczy „korzystaj”. A gpgcheck=0 znaczy „nie sprawdzaj plomby”, co w moim domowym laboratorium jest w porządku, bo pakiet sam zbudowałem. W prawdziwej hurtowni zawsze gpgcheck=1 i linijka gpgkey= ze ścieżką do klucza.

dnf repolist --all pokaże też hurtownie wyłączone.

Dodawanie hurtowni z internetu. Wiele firm publikuje gotowy plik .repo, a dnf umie go pobrać i odłożyć na miejsce:

sudo dnf config-manager --add-repo http://127.0.0.1:8765/kurs.repo

Adding repo from: http://127.0.0.1:8765/kurs.repo

Plik ląduje w /etc/yum.repos.d/. Włączanie i wyłączanie hurtowni bez edytowania plików:

sudo dnf config-manager --disable kurs
sudo dnf config-manager --enable kurs

Szukanie, informacje, instalacja

dnf search powitanie
dnf info powitanie

====================== Name & Summary Matched: powitanie =======================
powitanie.noarch : Wypisuje powitanie z pliku konfiguracyjnego

Instalacja, specjalnie starszej wersji, żeby było co aktualizować:

sudo dnf install powitanie-1.0

Dependencies resolved.
================================================================================
 Package             Architecture     Version           Repository         Size
================================================================================
Installing:
 powitanie           noarch           1.0-1             lokalne           6.3 k

Transaction Summary
================================================================================
Install  1 Package

Najpierw plan, potem pytanie „Is this ok [y/N]”. Duże N znaczy, że domyślna odpowiedź to „nie”. Red Hat zakłada, że jak wciśniesz Enter bez czytania, to raczej przez przypadek.

A teraz najczęstsze pytanie admina: „w którym pakiecie jest ta komenda?”. Na Ubuntu odpowiadał dpkg -S, ale tylko dla zainstalowanych pakietów. dnf przeszukuje całą hurtownię:

dnf provides /usr/bin/powitanie

powitanie-1.0-1.noarch : Wypisuje powitanie z pliku konfiguracyjnego
Repo        : @System
Matched from:
Filename    : /usr/bin/powitanie

@System znaczy „już masz”. W prawdziwym życiu wpisujesz dnf provides semanage i dowiadujesz się, który pakiet doinstalować, żeby komenda z poradnika zaczęła działać. Jak podasz samą nazwę, dnf sam sprawdzi ją w /usr/bin i /usr/sbin.

Aktualizacje: check-update, upgrade, łatki bezpieczeństwa

dnf check-update
echo $?

powitanie.noarch                          1.1-1                          lokalne
100

Lista pakietów z nowszą wersją. I ciekawostka: kod wyjścia 100 znaczy „są aktualizacje”, a 0 „nie ma”. Kciuk ani w górę, ani w dół, tylko „mam wiadomość”. Idealne do skryptów.

sudo dnf upgrade

Upgrading:
 powitanie           noarch           1.1-1             lokalne           6.3 k

Zauważ: na Red Hacie nie ma osobnego „update katalogu”. dnf sam odświeża katalog, kiedy jest starszy niż ustawiony czas. A komenda dnf update działa, ale to stara nazwa. Dokumentacja dnf oznacza ją jako przestarzały skrót do upgrade. Ludzie piszą yum update od lat i nikt im tego nie odbierze.

Łatki bezpieczeństwa. Red Hat do każdej poprawki wydaje komunikat, tak zwany advisory: co naprawia, jakie luki i jak bardzo jest pilny. dnf umie je czytać:

dnf updateinfo --security
dnf updateinfo list --security
sudo dnf upgrade --security

Pierwsza daje podsumowanie: ile jest łatek bezpieczeństwa, z podziałem na ważność. Druga listę: identyfikator komunikatu, ważność i pakiet. Trzecia instaluje tylko pakiety z poprawkami bezpieczeństwa i nic poza tym. Idealne na serwer produkcyjny, gdzie „nowe funkcje” to ostatnie, czego chcesz w piątek.

Czy po aktualizacji trzeba zrestartować?

sudo dnf needs-restarting -r
echo $?

-r to „reboothint”, podpowiedź o restarcie. Kod wyjścia 1 znaczy „restart potrzebny”, na przykład po nowym jądrze albo nowej bibliotece systemowej, 0 znaczy „nie trzeba”. Bez -r komenda wypisze procesy, które dalej używają starych wersji plików.

[Ubuntu] Na Ubuntu podobną rolę pełni plik /var/run/reboot-required. Jeśli istnieje, system prosi o restart.

Usuwanie

sudo dnf remove powitanie

Tu jest ważna różnica w stosunku do apt. dnf przy usuwaniu od razu sprząta zależności, które nie są już nikomu potrzebne. W pierwszej wersji mojej hurtowni powitanie wymagało jeszcze pomocniczego pakietu-atrapy. Zobacz, co dnf zaplanował:

Removing:
 powitanie            noarch          1.0-1             @lokalne           47
Removing unused dependencies:
 bash-atrapa          noarch          1.0-1             @lokalne            0

Czyli remove i autoremove w jednym. Dokumentacja dnf mówi, że tak jest domyślnie, a wyłączysz to flagą --noautoremove. Osobne dnf autoremove też istnieje, na wypadek gdyby coś zostało.

Historia i cofanie

To jest supermoc dnf.

dnf history

ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     2 | -y upgrade               | 2026-11-03 16:41 | Upgrade        |    1
     1 | -y install powitanie-1.0 | 2026-11-03 16:41 | Install        |    1

Każda operacja ma numer, datę, komendę i liczbę zmienionych pakietów. Szczegóły jednej:

dnf history info 2

Transaction ID : 2
Return-Code    : Success
Command Line   : -y upgrade
Packages Altered:
    Upgrade  powitanie-1.1-1.noarch @lokalne
    Upgraded powitanie-1.0-1.noarch @@System

I teraz Ctrl+Z:

sudo dnf history undo 2

Downgrading:
 powitanie           noarch           1.0-1             lokalne           6.3 k
...
Downgraded:
  powitanie-1.0-1.noarch

dnf zrobił odwrotność operacji numer 2. Była aktualizacja, jest powrót do starej wersji. Cofnięcie samo też trafia do historii jako nowa operacja, więc można cofnąć cofnięcie. Jak w edytorze tekstu.

Jeden haczyk: żeby zejść do starej wersji, ta stara wersja musi być jeszcze dostępna w hurtowni. W mojej jest. W innych bywa różnie, więc sprawdzaj, zanim na tym oprzesz plan awaryjny.

Hurtownia bez internetu: lokalne repozytorium z ISO

Serwer w piwnicy banku, bez dostępu do internetu. Jak tam instalować pakiety? Płyta instalacyjna RHEL, ta pełna, w wersji DVD, zawiera komplet pakietów z BaseOS i AppStream. Robimy z niej hurtownię.

Montujemy obraz. Pamiętasz montowanie z modułu o dyskach?

sudo mkdir -p /mnt/rhel10
sudo mount -o loop,ro -t iso9660 /root/rhel-10-dvd.iso /mnt/rhel10
ls /mnt/rhel10

W środku są foldery BaseOS i AppStream, każdy z własnym repodata. Plik /etc/yum.repos.d/dvd.repo:

[dvd-BaseOS]
name=RHEL 10 DVD BaseOS
baseurl=file:///mnt/rhel10/BaseOS
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

[dvd-AppStream]
name=RHEL 10 DVD AppStream
baseurl=file:///mnt/rhel10/AppStream
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

Dwie sekcje, bo to dwie hurtownie. Pakiety z płyty są podpisane przez Red Hata, więc plomba zostaje włączona. Sprawdzenie:

dnf repolist

Żeby montowanie przetrwało restart, dopisujesz obraz do /etc/fstab tak jak dysk, z typem iso9660 i opcjami loop,ro. To typowe zadanie egzaminacyjne na RHCSA, często w wersji „hurtownia jest pod adresem HTTP”, wtedy w baseurl wpisujesz ten adres.

EPEL: hurtownia dodatków

W repozytoriach Red Hata nie ma wszystkiego. Nie ma tam na przykład htop. Wtedy wchodzi EPEL, czyli Extra Packages for Enterprise Linux: dodatkowe pakiety budowane przez społeczność Fedory specjalnie pod RHEL i jego klony.

Na RHEL 10:

sudo subscription-manager repos --enable codeready-builder-for-rhel-10-$(arch)-rpms
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

Pierwsza włącza CodeReady Linux Builder, hurtownię z narzędziami dla programistów, której część pakietów z EPEL potrzebuje. Uwaga: Red Hat nie daje wsparcia dla pakietów z CodeReady. Druga instaluje pakiet, który zawiera plik .repo i klucz EPEL. Tak, instalujesz hurtownię jako pakiet. Karton, w którym jest adres innej hurtowni.

[Rocky / Alma] Tam jest prościej, bo epel-release jest w ich własnej hurtowni:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release

Ważne: EPEL to nie Red Hat. Red Hat nie daje do tych pakietów wsparcia. Na serwerach firmowych dodawaj go świadomie, a nie odruchowo.

rpm: pytania do magazyniera

rpm to magazynier Red Hata. Nie instalujesz nim z hurtowni, ale pytasz o to, co już leży na półkach. Pięć pytań, które musisz znać, wszystkie zaczynają się od -q jak „query”, zapytanie:

rpm -qa | wc -l
rpm -qi powitanie

-qa to wszystkie zainstalowane pakiety, „query all”. -qi to etykieta jednego pakietu:

Name        : powitanie
Version     : 1.0
Release     : 1
Architecture: noarch
Install Date: Tue Nov  3 16:27:56 2026
Signature   : (none)
Summary     : Wypisuje powitanie z pliku konfiguracyjnego

Signature: (none), bo mój pakiet nie jest podpisany. Prawdziwe pakiety Red Hata mają tu informację o kluczu, którym je podpisano.

rpm -ql powitanie
rpm -qf /usr/bin/powitanie

/etc/powitanie.conf
/usr/bin/powitanie
powitanie-1.0-1.noarch

-ql to lista plików, jak dpkg -L. -qf to „do którego pakietu należy plik”, jak dpkg -S. Na RHEL rpm -qf /usr/bin/ls odpowie coreutils z numerem wersji.

I piąte pytanie, moje ulubione: czy ktoś grzebał w plikach pakietu?

rpm -V powitanie

S.5....T.  c /etc/powitanie.conf
.M.......    /usr/bin/powitanie

Pusto znaczy „wszystko jak z fabryki”. Każda kropka to test, który przeszedł. Litera to test, który nie przeszedł. S zmienił się rozmiar, 5 zmieniła się suma kontrolna, czyli treść, T zmieniła się data modyfikacji, M zmieniły się uprawnienia. A c oznacza plik konfiguracyjny. Ja dopisałem linijkę do ustawień i zmieniłem uprawnienia programu. W ustawieniach to normalne. Ale zmieniona suma kontrolna w /usr/bin na serwerze, na którym nikt nic nie budował? To jest moment, w którym robi się zimno i zaczyna się śledztwo.

Jak to działa pod spodem

Hurtownia dnf to folder z pakietami i podfolderem repodata. Najważniejszy plik to repomd.xml, spis treści. Wskazuje na skompresowane spisy: primary z nazwami, wersjami i zależnościami, filelists z listami plików i other z historią zmian. W RHEL 10 dnf domyślnie nie pobiera już filelists, bo jest duży. Dociąga go dopiero wtedy, kiedy potrzebuje, na przykład przy dnf provides z pełną ścieżką.

dnf pobiera katalogi do /var/cache/dnf/, układa z nich łamigłówkę zależności i rozwiązuje ją. Potem pobiera pakiety, sprawdza podpisy i przekazuje transakcję do rpm. rpm wypakowuje pliki, uruchamia skrypty instalacyjne i zapisuje wszystko w swojej bazie. W RHEL 10 ta baza leży w /usr/lib/sysimage/rpm/, a /var/lib/rpm zostało jako drogowskaz.

I sprytna rzecz z plikami ustawień. Kiedy usuwałem pakiet ze zmienionym plikiem konfiguracyjnym, rpm napisał:

warning: /etc/powitanie.conf saved as /etc/powitanie.conf.rpmsave

Zamiast wyrzucić Twoje ustawienia, odkłada je z dopiskiem .rpmsave. A przy aktualizacji, gdy zmieniłeś plik, a pakiet przynosi nową wersję, rpm zostawia Twój plik, a nowy kładzie obok jako .rpmnew. Po każdej większej aktualizacji warto poszukać takich plików:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Ściąga flag