Rocky Linux i AlmaLinux: brak pakietów w dnf

Dlaczego dnf nie może znaleźć żądanego pakietu

EPEL oraz CRB to dwa repozytoria, których świeżo zainstalowany serwer Rocky Linux lub AlmaLinux nie udostępnia domyślnie. Dlatego dnf install htop na nowej maszynie kończy się komunikatem No match for argument: htop, a następnie Error: Unable to find a match: htop. Nic nie jest uszkodzone i żaden mirror nie jest wyłączony. Podstawowa dystrybucja celowo zawiera ograniczony zestaw pakietów, CRB jest obecne, ale wyłączone, a EPEL to oddzielne repozytorium społecznościowe, które należy dodać samodzielnie.

W systemie Ubuntu ten sam pakiet znajduje się w universe, a universe jest włączone w niemal każdym obrazie chmurowym, więc problem ten nigdy nie występuje. Rodzina Red Hat dzieli pakiety inaczej i domyślnie oferuje ich mniej. Rozwiązanie wymaga trzech poleceń. Reszta tego przewodnika zawiera informacje, o których nikt nie wspomina w pierwszym tygodniu pracy: co gwarantują te repozytoria, czego nie gwarantują oraz jak zapobiec sytuacji, w której repozytorium zewnętrznego dostawcy po cichu przejmuje kontrolę nad systemem bazowym.

W jaki sposób zweryfikowano te polecenia. Nasze kontenery testowe działają wyłącznie na systemie Ubuntu, dlatego polecenia dnf poniżej nie zostały wykonane na naszych własnych maszynach testowych. Są one zgodne z dokumentacją Rocky Linux oraz AlmaLinux. Każdy krok wskazuje oczekiwany wynik, dlatego należy zweryfikować każdy z nich na własnym serwerze, zamiast wklejać cały blok naraz.

Czym są BaseOS, AppStream oraz CRB?

BaseOS to sam system operacyjny: jądro, glibc, systemd oraz podstawowe narzędzia użytkownika. Wersje w tym repozytorium rzadko zmieniają się w trakcie cyklu życia głównego wydania. Większość poprawek, w tym poprawki bezpieczeństwa, jest przenoszona (backportowana) do posiadanej wersji, choć wydania pomocnicze czasami aktualizują kluczowe komponenty do nowszych wersji upstream (na przykład AlmaLinux 9.2 zaktualizował pakiety przestrzeni użytkownika SELinux do wersji 3.5). Numer wersji w BaseOS, który wygląda na przestarzały, nie oznacza braku poprawek. Jest to załatana starsza wersja, co stanowi istotę dystrybucji klasy enterprise.

AppStream zawiera oprogramowanie uruchamiane na systemie: serwery WWW, bazy danych, środowiska uruchomieniowe języków, edytory oraz agenty monitorujące. W wersji 8 znaczna część AppStream była dostarczana jako moduły z alternatywnymi strumieniami, więc dnf module list miało znaczenie i należało wybrać na przykład konkretny strumień PHP. Wersja 9 dostarcza domyślną wersję każdej aplikacji jako zwykły pakiet, więc w systemach Rocky 9 oraz Alma 9 polecenie dnf install instaluje tę wersję bez konieczności wcześniejszego włączania modułu. Alternatywne wersje nadal są dostępne jako strumienie modułów: dokumentacja RHEL 9 wskazuje PHP 8.0 jako zwykły pakiet php, a PHP 8.1 oraz 8.2 jako strumienie php:8.1 i php:8.2, natomiast AlmaLinux 9.8 dodał nowe strumienie, takie jak MariaDB 11.8, PostgreSQL 18 oraz Ruby 4.0. Jeśli wymagana jest wersja inna niż domyślna, dnf module list nadal ma znaczenie w wersji 9.

Extras jest domyślnie włączone i zawiera niewielką liczbę pakietów. Przechowuje głównie pakiety wydawnicze dla innych repozytoriów, z których pochodzi samo epel-release. Dzięki temu nie ma potrzeby ufania przypadkowym adresom URL w celu instalacji EPEL w systemach Rocky lub Alma.

CRB to repozytorium CodeReady Builder, w wersji 8 znane jako PowerTools. Zawiera ono komponenty służące do budowania oprogramowania: nagłówki programistyczne, biblioteki statyczne oraz narzędzia testowe i dokumentacyjne wymagane przez pakiety na etapie kompilacji. Znajduje się ono na serwerach lustrzanych, ale jest domyślnie wyłączone. W produkcie firmy Red Hat ta sama zawartość nosi nazwę CodeReady Linux Builder, jest dostępna w ramach subskrypcji, a producent zaznacza, że nie jest objęta wsparciem technicznym. Rocky oraz Alma dziedziczą zarówno zawartość, jak i domyślny stan wyłączenia.

Dla użytkowników przechodzących z systemów Debian lub Ubuntu: main łączy pakiety uruchomieniowe oraz nagłówki -dev w jednym archiwum, dlatego nie ma tam repozytorium CRB do włączenia. Najbliższym odpowiednikiem EPEL jest universe, które jest utrzymywane przez społeczność i nie wiąże się z gwarancją wsparcia ze strony dostawcy.

Czym jest EPEL i kto za nim stoi

EPEL to skrót od Extra Packages for Enterprise Linux. Jest to projekt społeczności Fedora: pakiety istniejące w Fedorze są przebudowywane dla aktualnego wydania korporacyjnego i utrzymywane przez grupę EPEL Special Interest Group, złożoną głównie z wolontariuszy społeczności Fedora. Red Hat udostępnia infrastrukturę budowania i mirrorowania, a niektórzy inżynierowie Red Hat utrzymują w nim wybrane pakiety. Na tym kończy się relacja. EPEL nie jest produktem Red Hat. Pakiety EPEL nie są objęte umową wsparcia ani SLA (service level agreement), niezależnie od tego, czy działają na RHEL, czy na jego klonie.

Jedna zasada sprawia, że włączenie EPEL jest bezpieczne: pakiet EPEL nigdy nie może zastąpić pakietu z dystrybucji bazowej. Jeśli AppStream dostarcza nginx, EPEL tego nie zrobi. Zasada ta jest egzekwowana przez osoby recenzujące pakiety EPEL, więc jest to gwarancja dotycząca wyłącznie EPEL. Nie chroni ona przed innymi źródłami oprogramowania dodanymi w późniejszym czasie.

Cykl życia pakietów również różni się od dystrybucji bazowej, co staje się problematyczne w trzecim roku eksploatacji. Pakiet BaseOS zazwyczaj zachowuje swoją wersję przez cały dziesięcioletni okres wsparcia wydania głównego, a poprawki są do niego backportowane z rzadkimi, celowymi zmianami wersji (rebase). Utrzymujący pakiet w EPEL deklaruje znacznie krótszy okres wsparcia: propozycja dotycząca cyklu życia pakietów EPEL określa go jako co najmniej jedno wydanie minor RHEL lub 13 miesięcy, w zależności od tego, co nastąpi wcześniej. W praktyce większość pakietów jest utrzymywana znacznie dłużej. Niektóre są wycofywane, gdy opiekun przestaje się nimi zajmować, a inne przeskakują na nową wersję główną w trakcie życia dystrybucji, ponieważ EPEL podąża za Fedorą. W rezultacie rutynowe dnf upgrade może dostarczyć nową wersję główną narzędzia z EPEL na serwerze, który miał pozostać stabilny, a pakiet, od którego zależy system, może przestać otrzymywać aktualizacje bez żadnego powiadomienia. Nowa wersja nie zacznie działać w usłudze, która już pracuje, dlatego needs-restarting wskazuje procesy korzystające ze starych plików binarnych po zakończeniu transakcji.

Warto znać jeszcze jedną konsekwencję przed włączeniem repozytorium: EPEL nie jest budowany pod starsze wydania minor, na których może znajdować się serwer. Polityka EPEL dla Fedory zakłada budowanie wiodącej wersji EPEL 10 względem CentOS Stream 10, a starszych wersji EPEL 10 względem konkretnych wydań minor RHEL 10. EPEL 8 i 9 mają własne definicje celów. Jeśli serwer jest utrzymywany w starszej wersji minor przy użyciu zamrożonego mirrora lub repozytorium punktowego dostawcy, pakiet EPEL może wymagać biblioteki bazowej nowszej niż dostępna w systemie. dnf zgłosi to jako brakującą zależność, co może wyglądać na problem z mirrorem, podczas gdy w rzeczywistości jest to problem rozbieżności wersji.

Włączenie CRB i instalacja EPEL na systemach Rocky lub Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled powinno teraz wyświetlić baseos, appstream, extras, crb oraz epel. Można również zauważyć niewielki wpis epel-cisco-openh264, który dodaje epel-release. Jeśli crb brakuje na tej liście, krok aktywacji nie powiódł się, a kolejna sekcja wyjaśnia przyczynę.

W systemach Rocky 8 oraz Alma 8 repozytorium nadal nosi nazwę PowerTools, dlatego środkowe polecenie przyjmuje postać sudo dnf config-manager --set-enabled powertools. Identyfikatory repozytoriów są wrażliwe na wielkość liter, a starsza dokumentacja CentOS 8 używa zapisu PowerTools z wielkimi literami, co nie będzie pasować. W systemie AlmaLinux 10 repozytorium CRB jest włączone domyślnie od wersji 10.0 (zmiana wprowadzona we wrześniu 2025 r.), więc w tym przypadku wymagany jest jedynie krok epel-release.

epel-release pochodzi z extras, które jest już włączone, więc nie ma adresu URL do zaufania ani klucza do ręcznego zaimportowania. Pakiet zapisuje /etc/yum.repos.d/epel.repo i instaluje klucz podpisu EPEL w lokalizacji /etc/pki/rpm-gpg/. Należy potwierdzić gpgcheck=1 w tym pliku i ignorować wszelkie poradniki zalecające obejście błędu podpisu za pomocą --nogpgcheck. Niepowodzenie weryfikacji podpisu oznacza, że pakiet nie jest tym, za co się podaje, lub ustawienia zegara systemowego są nieprawidłowe.

W systemie Rocky, epel-release instaluje również niewielkie narzędzie pomocnicze w /usr/bin/crb, dzięki czemu sudo crb enable oraz crb status wykonują to samo zadanie bez użycia wtyczki. Przed poleganiem na tym rozwiązaniu należy sprawdzić jego obecność za pomocą command -v crb, ponieważ nie występuje ono w każdej gałęzi każdego systemu typu rebuild.

Aby sprawdzić, czy repozytorium EPEL jest osiągalne, a nie tylko widoczne na liście, należy wyszukać pakiet, który znajduje się wyłącznie w nim:

dnf repoquery --repo=epel htop

Polecenie to wyświetli nazwę pakietu, wersję oraz architekturę. Brak wyniku oznacza, że repozytorium jest włączone, ale nie zwraca danych, co zazwyczaj wynika z problemów z serwerem lustrzanym lub metadanymi, a nie z konfiguracji, dlatego w następnej kolejności należy użyć sudo dnf clean all && sudo dnf makecache.

Dlaczego dnf zgłasza błąd: no such command: config-manager

Jest to pierwszy problem, na który napotykają użytkownicy, a występuje on dokładnie w obrazach systemowych dostarczanych przez większość dostawców VPS.

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager to wtyczka, a nie wbudowane podpolecenie dnf. Jest ona dostarczana w pakiecie dnf-plugins-core, który jest pobierany podczas pełnej instalacji serwera, ale pomijany w obrazach minimalnych, chmurowych oraz kontenerowych. Sugestia wyświetlana przez dnf działa, ponieważ pakiet deklaruje odpowiednią wirtualną zdolność (virtual capability):

sudo dnf install -y 'dnf-command(config-manager)'

Należy użyć cudzysłowów. Nawiasy są składnią powłoki, więc wersja bez cudzysłowów zakończy się błędem składni, a nie błędem dnf.

Jeśli instalacja wtyczki nie jest możliwa, ponieważ wymagane repozytorium jest wyłączone, należy ręcznie edytować plik. Należy odnaleźć plik zawierający daną sekcję, otworzyć go i ustawić enabled=1 wewnątrz [crb]:

grep -rl crb /etc/yum.repos.d/

Jest to dokładnie to samo, co zapisuje config-manager, więc ręczna edycja nie powoduje utraty funkcjonalności. Polecenie dnf repolist --enabled potwierdza wynik.

Niektóre pakiety EPEL nie zainstalują się, dopóki CRB nie zostanie włączone

Drugą częstą pułapką jest błąd, który nie wspomina o CRB. Pakiet EPEL, który odwołuje się do biblioteki dostarczanej wyłącznie w CRB, powoduje błąd podczas rozwiązywania zależności, a komunikat wskazuje bibliotekę oraz pakiet, który jej wymaga:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

Przyczyną jest wyłączone repozytorium CRB, przez co dnf nie widzi jedynego źródła dostarczającego tę bibliotekę. Należy sprawdzić dwie rzeczy w podanej kolejności:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

Jeśli drugie polecenie wskazuje pakiet, podczas gdy zwykła instalacja nadal kończy się niepowodzeniem, oznacza to, że CRB jest wyłączone. Ten typ błędu występuje na tyle często, że w wersji 10 systemu AlmaLinux domyślnie włączono CRB, aby zapobiec takim sytuacjom. --enablerepo=crb działa również jako jednorazowa flaga przy pojedynczej instalacji, jednak jeśli korzystasz z EPEL, pozostaw CRB włączone na stałe. Kolejna aktualizacja EPEL może wprowadzić nową zależność od CRB bez wcześniejszego ostrzeżenia.

Z jakiego repozytorium pochodzi ten pakiet?

Po kilku tygodniach pracy z czterema włączonymi repozytoriami, istotnym pytaniem przestaje być to, co jest zainstalowane, a staje się to, skąd dany pakiet pochodzi.

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

dnf info dla zainstalowanego pakietu wyświetla linię From repo. dnf list installed pokazuje te same informacje w trzeciej kolumnie z przedrostkiem @, więc @epel oznacza instalację z EPEL, a @System oznacza, że dnf nie rozpoznaje źródła, co zazwyczaj wskazuje na użycie rpm -i na pobranym pliku. Linia repoquery podaje liczbę pakietów dla każdego repozytorium; jest to najszybszy sposób, aby odkryć, że odziedziczony serwer posiada czterdzieści pakietów z repozytorium, o którym administrator nigdy nie słyszał. Ostatnie polecenie wyświetla dokładną listę pakietów dostarczonych przez konkretne repozytorium, co stanowi niezbędny inwentarz przed podjęciem decyzji o jego usunięciu.

Odpowiednikiem w systemie apt jest apt-cache policy <package>, a odpowiedniki poleceń dnf i apt warto mieć otwarte w drugiej karcie przez pierwszy miesiąc, ponieważ koncepcje te mapują się bezpośrednio, nawet jeśli flagi są odmienne.

Jak zapobiec zastępowaniu pakietów bazowych przez repozytoria firm trzecich?

EPEL gwarantuje, że nie będzie tego robić. Żadne inne repozytorium nie daje takiej obietnicy. Repozytorium dostawcy bazy danych, agenta lub środowiska uruchomieniowego może dostarczać własną kompilację biblioteki, którą udostępnia również BaseOS. Program dnf zainstaluje ją, ponieważ domyślna zasada działania dnf jest prosta: wygrywa najwyższa wersja, niezależnie od źródła.

Dwa mechanizmy kontrolne wykonują większość pracy; oba znajdują się w pliku repozytorium w sekcji /etc/yum.repos.d/.

Parametr priority= decyduje, które repozytorium wygrywa, gdy kilka z nich zawiera pakiet o tej samej nazwie. Niższe wartości mają pierwszeństwo, a wartością domyślną jest 99. Należy zatem przypisać repozytoriom bazowym niską wartość, a repozytoriom firm trzecich wysoką. Wówczas dnf wybierze pakiet bazowy, nawet jeśli wersja z repozytorium zewnętrznego jest nowsza. Nowoczesny dnf obsługuje to samodzielnie, więc oddzielny pakiet yum-plugin-priorities z czasów CentOS 7 nie jest już częścią rozwiązania.

Parametr includepkgs= to silniejsza opcja filtrowania. excludepkgs= blokuje wskazane pakiety z danego repozytorium, co wymaga przewidzenia, co może ono dostarczyć. includepkgs= działa odwrotnie: repozytorium może dostarczać tylko wymienione nazwy i nic więcej. Repozytorium dostawcy, które powinno udostępniać wyłącznie własnego agenta, wymaga tylko jednej linii konfiguracji.

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

W wersji 8 istnieje jeszcze jedno ustawienie, o którym należy wiedzieć. Pakiet z repozytorium firmy trzeciej może zostać ukryty, gdy moduł AppStream udostępnia pakiet o tej samej nazwie. Parametr module_hotfixes=1 w sekcji danego repozytorium nakazuje dnf zaprzestanie filtrowania. Jeśli pakiet, który z pewnością znajduje się w repozytorium dostawcy, jest zgłaszany jako brakujący lub nie daje się zainstalować na systemie w wersji 8, zazwyczaj jest to przyczyna: filtrowanie modułowe sprawia, że staje się on niewidoczny dla większości poleceń dnf, zamiast zgłaszać konflikt. Wersja 9 posiada mniej modułów, ale nadal korzysta ze strumieni modułów, więc to samo filtrowanie może mieć zastosowanie, gdy pakiet dostawcy współdzieli nazwę z modułem.

Aby przypiąć pakiet do konkretnej wersji, należy zainstalować python3-dnf-plugin-versionlock i użyć sudo dnf versionlock add <package>. Jest to odpowiednik apt-mark hold. Należy zwrócić uwagę na jedną różnicę, która często myli użytkowników przechodzących z systemu Debian: w apt wygrywa wyższy Pin-Priority, natomiast w dnf wygrywa niższy priority.

Dlaczego mieszanie repozytoriów powiązanych z RHEL uniemożliwia aktualizację serwera

Systemy Rocky, Alma, CentOS Stream, Oracle Linux oraz RHEL są na tyle zbliżone, że ich pakiety dają się instalować zamiennie, ale jednocześnie na tyle odmienne, że wynikowa konfiguracja staje się niemożliwa do wspierania przez kogokolwiek. Przyczyny tego stanu rzeczy oraz fakt, dlaczego obecnie CentOS Stream znajduje się przed RHEL, a nie obok niego, opisuje historia podziału Red Hat Linux na Fedorę i RHEL oraz losy CentOS.

Mechanizmem sprawczym są numery wersji. CentOS Stream 9 wyprzedza RHEL 9, a Red Hat określa kod Stream jako bazę dla kolejnego wydania podrzędnego RHEL. Skierowanie systemu Rocky 9 na repozytorium Stream, nawet jednorazowo i tylko dla jednego pakietu, powoduje zainstalowanie wersji nowszych niż te, które obecnie oferuje Rocky. Przyszłe wydanie podrzędne Rocky może dogonić tę wersję, jednak nie ma gwarancji, że dostarczy ten pakiet w wersji równej lub wyższej od posiadanej, a dopóki to nie nastąpi, dnf upgrade nie podejmie żadnych działań wobec tego konkretnego pakietu. Maszyna pracuje wówczas w konfiguracji, której nikt nie testował, co może trwać latami w błędnym przekonaniu o poprawnym łataniu systemu.

Objawem jest sytuacja, w której dnf upgrade nie zgłasza żadnych zadań, podczas gdy sudo dnf distro-sync proponuje obniżenie wersji (downgrade) długiej listy pakietów. Narzędziem naprawczym jest distro-sync: wymusza ono dopasowanie każdego zainstalowanego pakietu do wersji oferowanych przez włączone repozytoria, w tym poprzez obniżenie wersji. Należy najpierw wyłączyć obce repozytorium, następnie uruchomić polecenie i dokładnie przejrzeć listę zmian przed jej zatwierdzeniem. Naprawa kończy się niepowodzeniem, gdy starszy pakiet RPM nie jest już dostępny w mirrorze; w takim przypadku odbudowa serwera z czystego obrazu jest szybsza i bezpieczniejsza niż walka z mechanizmem rozwiązywania zależności.

Pozostałości z ery ELevate to inny częsty wariant tego problemu. ELevate to narzędzie migracyjne AlmaLinux oparte na Leapp, używane do przenoszenia systemów CentOS 7 lub konwersji między różnymi dystrybucjami typu rebuild. Pośpieszna migracja pozostawia pliki repozytoriów EL7 w /etc/yum.repos.d/ oraz zainstalowane pakiety EL7. Można je zlokalizować za pomocą rpm -qa | grep el7. Każdy z nich jest pakietem, którego żadne włączone repozytorium nie będzie w stanie zaktualizować, a późniejsze uruchomienie Leapp zgłosi je jako pakiety niemożliwe do zmapowania, co stanie się blokadą aktualizacji wymagającą ręcznego usunięcia. Należy je usunąć, gdy serwer pracuje stabilnie, a nie w dniu, w którym konieczne jest przeprowadzenie kolejnej dużej aktualizacji.

Repozytorium dostawcy przesłaniające pakiet z AppStream to łagodniejsza wersja tego samego problemu, a rozwiązaniem jest linia includepkgs. Zazwyczaj dotyczy to narzędzi kontenerowych, ponieważ containerd.io z repozytorium Docker jest w konflikcie z runc z AppStream, więc jeden z nich musi zostać usunięty. Należy podjąć decyzję, zapisać wykluczenie i postępować zgodnie ze sprawdzoną procedurą: instrukcja instalacji Docker na Rocky Linux opisuje, które pakiety dystrybucyjne należy usunąć w pierwszej kolejności.

Przeniesienie konfiguracji repozytoriów z apt na dnf

• /etc/apt/sources.list.d/*.sources staje się /etc/yum.repos.d/*.repo, gdzie jeden plik może zawierać kilka definicji [sections], każda z własnym identyfikatorem.
• add-apt-repository universe staje się dnf install epel-release, z tą różnicą, że universe znajduje się wewnątrz archiwum Ubuntu, a EPEL jest oddzielnym projektem.
• apt update nie posiada odpowiednika, o czym należy pamiętać. dnf odświeża metadane według własnego harmonogramu, a dnf makecache wymusza to działanie natychmiast.
• apt-cache policy <pkg> staje się dnf info <pkg>, dodatkowo dnf list --showduplicates <pkg> pozwala wyświetlić wszystkie dostępne wersje.
• apt-mark hold staje się dnf versionlock add, z pakietu python3-dnf-plugin-versionlock.
• Mechanizm pinningu w /etc/apt/preferences.d/ staje się priority= w sekcji repozytorium, przy czym wartości liczbowe działają w odwrotnym kierunku.
• dpkg -S /path/to/file staje się rpm -qf /path/to/file.

Automatyczne aktualizacje przenoszą się jako koncepcja, a nie składnia, ponieważ nie istnieje tutaj unattended-upgrades. Timer, plik konfiguracyjny oraz kwestia tego, czy wymagany jest restart, zostały omówione w dnf-automatic w systemach Rocky i Alma.

Ograniczanie liczby repozytoriów

Włącz CRB, zainstaluj epel-release, a następnie odnotuj wykonane czynności i ich uzasadnienie w systemie zarządzania konfiguracją lub w pliku tekstowym na serwerze. Taka notatka jest niezwykle cenna, gdy serwer ma trzy lata, a obsługuje go inna osoba.

Przeszukaj zasoby przed dodaniem nowych. Uruchom dnf search, następnie dnf info i dopiero wtedy rozważ dodanie nowego repozytorium. Zaskakująco wiele pakietów, dla których użytkownicy włączają EPEL, znajduje się już w AppStream. Monitorowanie systemu jest tego najlepszym przykładem, ponieważ Performance Co-Pilot jest dostępny w podstawowych repozytoriach i nie wymaga żadnych zewnętrznych źródeł. Każde dodatkowe repozytorium to kolejny podmiot, który może dostarczyć pakiet w dowolnym momencie, a każde z nich utrudnia przyszłą aktualizację do nowej wersji głównej systemu.

Jeśli nadal wybierasz między tymi dwiema dystrybucjami, pamiętaj, że układ jest w obu identyczny, a epel-release działa w ten sam sposób. Rzeczywiste różnice leżą gdzie indziej: porównanie Rocky Linux i AlmaLinux omawia filozofię przebudowy systemu, ponieważ AlmaLinux obecnie koncentruje się na zgodności ABI (application binary interface), a nie na wiernym odtwarzaniu kodu linia po linii.

FAQ

Jak włączyć EPEL w systemie Rocky Linux 9 lub AlmaLinux 9?

Uruchom sudo dnf install -y dnf-plugins-core, następnie sudo dnf config-manager --set-enabled crb, a potem sudo dnf install -y epel-release. Potwierdź za pomocą dnf repolist --enabled, co powinno wyświetlić baseos, appstream, extras, crb oraz epel. Włącz CRB przed instalacją pakietów EPEL, ponieważ wiele z nich zależy od bibliotek dostępnych wyłącznie w CRB. W wersji 8 identyfikator repozytorium to powertools zamiast crb.

Czy włączanie EPEL na serwerze produkcyjnym jest bezpieczne?

Repozytorium to jest powszechnie stosowane i opiera się na zasadzie, że pakiety EPEL nigdy nie zastępują pakietów z dystrybucji bazowej, więc jego włączenie nie zmienia zawartości BaseOS ani AppStream. Zastrzeżeniem jest wsparcie: EPEL to projekt społecznościowy Fedory bez umowy o gwarantowanym poziomie świadczenia usług (SLA), a propozycja dotycząca cyklu życia pakietów EPEL zakłada, że opiekun zobowiązuje się do utrzymania pakietu przez okres zaledwie jednego wydania podrzędnego RHEL lub 13 miesięcy. Prowadź inwentaryzację za pomocą dnf repository-packages epel list installed i używaj dnf versionlock dla każdego pakietu EPEL, od którego zależy usługa udostępniana klientom.

Dlaczego dnf zgłasza błąd: no such command: config-manager?

Ponieważ config-manager jest wtyczką dnf, a nie wbudowanym poleceniem, a obrazy minimalne lub kontenerowe są dostarczane bez dnf-plugins-core. Sam komunikat wskazuje rozwiązanie: sudo dnf install -y 'dnf-command(config-manager)', ujęte w cudzysłów, aby powłoka nie interpretowała nawiasów. Jeśli nie można jeszcze nic zainstalować, uruchom grep -rl crb /etc/yum.repos.d/, otwórz wskazany plik i ręcznie ustaw enabled=1 w sekcji [crb].

Jaka jest różnica między CRB a PowerTools?

To to samo repozytorium pod dwiema nazwami. Wersja 8 nazywa je PowerTools z identyfikatorem powertools, wersja 9 i nowsze nazywają je CRB z identyfikatorem crb, a produkt firmy Red Hat określa tę zawartość jako CodeReady Linux Builder. Zawiera ono nagłówki programistyczne, biblioteki statyczne oraz narzędzia do budowania i jest domyślnie wyłączone w systemach Rocky oraz AlmaLinux 9. AlmaLinux 10 włącza je domyślnie od wersji 10.0, więc sprawdź dnf repolist --enabled przed uruchomieniem polecenia włączającego w tym systemie.

Jak usunąć EPEL, aby nie spowodować awarii?

Najpierw wykonaj inwentaryzację za pomocą dnf repository-packages epel list installed, ponieważ usunięcie samego pakietu epel-release nie powoduje usunięcia niczego, co zostało zainstalowane z EPEL. Pakiety te pozostają na dysku, tracą źródło aktualizacji i przestają otrzymywać poprawki bezpieczeństwa bez żadnego komunikatu o błędzie. Decyduj o każdym pakiecie z osobna, usuń lub zastąp te, które nie są już potrzebne, a dopiero potem uruchom sudo dnf remove epel-release. Jeśli coś z EPEL nie zastąpiło żadnego pakietu i musi zostać usunięte, sudo dnf repository-packages epel remove wyczyści ten zestaw w jednej transakcji, więc uważnie przeczytaj proponowaną listę przed jej zatwierdzeniem.