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 system operacyjny w podstawowej formie: jądro, glibc, systemd oraz kluczowe narzędzia użytkownika. Wersje pakietów w tym repozytorium są zamrożone na cały okres wsparcia wydania głównego, a poprawki bezpieczeństwa są przenoszone (backported) do tych starszych wersji. Numer wersji, który wygląda na przestarzały w BaseOS, 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 programowania, edytory oraz agenty monitorujące. W wersji 8 znaczna część AppStream była dostarczana jako moduły z alternatywnymi strumieniami, dlatego dnf module list miało znaczenie i wymagało wyboru, na przykład konkretnego strumienia PHP. Wersja 9 niemal całkowicie zrezygnowała z modularności, więc w Rocky 9 oraz Alma 9 zazwyczaj dostępna jest jedna wersja danego pakietu bez konieczności wcześniejszego aktywowania modułu.

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 szczegółowi nie ma potrzeby ufania przypadkowym adresom URL w celu instalacji EPEL na systemach Rocky lub Alma.

CRB to repozytorium CodeReady Builder, znane w wersji 8 jako PowerTools. Zawiera ono komponenty budowania dystrybucji: nagłówki programistyczne, biblioteki statyczne oraz narzędzia testowe i dokumentację, których pakiety wymagają w czasie kompilacji. Repozytorium znajduje się na serwerach lustrzanych, ale jest domyślnie wyłączone. W produktach Red Hat ta sama zawartość nosi nazwę CodeReady Linux Builder, jest dostępna w ramach subskrypcji, jednak Red Hat zaznacza, że nie jest ona objęta wsparciem technicznym. Rocky oraz Alma dziedziczą zarówno zawartość, jak i domyślny stan wyłączenia.

Dla czytelników wywodzących się z systemów Debian lub Ubuntu: main łączy pakiety uruchomieniowe oraz nagłówki -dev w jednym archiwum, dlatego nie ma tam repozytorium CRB do aktywacji. Najbliższym odpowiednikiem EPEL jest universe, które jest utrzymywane przez społeczność i nie posiada gwarancji 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 bieżącego wydania korporacyjnego i utrzymywane przez grupę EPEL Special Interest Group, składającą się głównie z wolontariuszy ze społeczności Fedora. Red Hat udostępnia infrastrukturę budowania i serwery lustrzane, a niektórzy inżynierowie Red Hat utrzymują w nim wybrane pakiety. Na tym kończy się relacja. EPEL nie jest produktem firmy Red Hat. Pakiety EPEL nie są objęte umową wsparcia ani SLA (service level agreement), niezależnie od tego, czy używasz RHEL, czy jego klonów.

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

Cykl życia pakietów różni się od tego w podstawowej dystrybucji, co często staje się problemem w trzecim roku eksploatacji. Wersja pakietu w BaseOS jest zamrożona na cały dziesięcioletni okres wsparcia głównego wydania. Utrzymujący pakiet w EPEL deklaruje znacznie krótszy okres: 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ą główną wersję w trakcie życia dystrybucji, ponieważ EPEL podąża za Fedorą. Dlatego rutynowe dnf upgrade może dostarczyć nową główną wersję 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 jest również automatycznie ładowana przez działające usługi, więc needs-restarting wskazuje procesy, które po zakończeniu transakcji nadal korzystają ze starego pliku binarnego.

Warto znać jeszcze jedną konsekwencję przed włączeniem repozytorium: EPEL jest budowany w oparciu o najnowsze wydanie minor RHEL. Jeśli serwer jest utrzymywany w starszej wersji minor przy użyciu zamrożonego serwera lustrzanego lub repozytorium typu vendor point release, pakiet EPEL może wymagać nowszej biblioteki podstawowej niż ta, która jest zainstalowana. dnf zgłasza to jako brakującą zależność, co może wyglądać na problem z serwerem lustrzanym, 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 pewności. Repozytorium dostawcy bazy danych, agenta lub środowiska uruchomieniowego języka może dostarczać własną wersję biblioteki, która jest już dostępna w BaseOS. Program dnf zainstaluje ją, ponieważ domyślna zasada dnf jest prosta: wygrywa najwyższa wersja, niezależnie od źródła.

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

priority= decyduje, które repozytorium wygrywa, gdy więcej niż jedno oferuje pakiet o tej samej nazwie. Niższe liczby mają pierwszeństwo, a wartością domyślną jest 99. Należy zatem przypisać repozytoriom bazowym niską liczbę, 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 osobny pakiet yum-plugin-priorities z ery CentOS 7 nie jest już częścią rozwiązania.

includepkgs= to silniejsza opcja filtrowania. excludepkgs= blokuje wskazane pakiety z repozytorium, co wymaga przewidzenia, co może ono dostarczyć. includepkgs= działa odwrotnie: repozytorium może dostarczać tylko te 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 warto wiedzieć. Pakiet z repozytorium zewnętrznego może być ukryty, gdy moduł AppStream dostarcza pakiet o tej samej nazwie, a module_hotfixes=1 w sekcji danego repozytorium instruuje dnf, aby przestał go filtrować. Jeśli pakiet jest widoczny dla dnf repoquery, ale nie daje się zainstalować na systemie w wersji 8, zazwyczaj jest to przyczyna. Wersja 9 wycofała niemal wszystkie moduły, więc problem ten występuje tam rzadko.

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 osoby przechodzące z systemu Debian: w apt wygrywa wyższy Pin-Priority, natomiast w dnf wygrywa niższy priority.

Dlaczego mieszanie repozytoriów pokrewnych RHEL uniemożliwia aktualizację serwera

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 różne, że wynikowy system staje się niemożliwy do wspierania. Przyczyny tego podobieństwa oraz fakt, że CentOS Stream znajduje się obecnie przed RHEL, a nie obok niego, wyjaśnia historia podziału Red Hat Linux na Fedorę i RHEL oraz losy CentOS.

Mechanizmem sprawczym są numery wersji. CentOS Stream 9 wyprzedza RHEL 9, więc wskazanie repozytorium Stream w systemie Rocky 9 – nawet jednorazowe i dla pojedynczego pakietu – powoduje zainstalowanie wersji nowszych niż te, które kiedykolwiek pojawią się w Rocky. Gdy nadejdzie kolejna wersja minor systemu Rocky, wersja pakietu w repozytorium będzie niższa od posiadanej, więc dnf upgrade pominie ten pakiet. Maszyna pracuje w konfiguracji, której nikt nie testował, a stan ten utrzymuje się przez lata, podczas gdy administrator zakłada, że system jest poprawiony.

Objawem jest sytuacja, w której dnf upgrade nie zgłasza żadnych zadań, podczas gdy sudo dnf distro-sync sugeruje obniżenie wersji (downgrade) długiej listy pakietów. Narzędziem naprawczym jest distro-sync: wymusza ono dopasowanie każdego zainstalowanego pakietu do oferty włączonych repozytoriów, wliczając w to obniżenie wersji. Najpierw należy wyłączyć obce repozytorium, następnie uruchomić polecenie i dokładnie przejrzeć listę zmian przed jej zaakceptowaniem. Naprawa kończy się niepowodzeniem, gdy starszy pakiet RPM nie jest już dostępny w mirrorze; w takim przypadku odtworzenie serwera z czystego obrazu jest szybsze i bezpieczniejsze niż walka z mechanizmem rozwiązywania zależności.

Pozostałości po erze 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 dystrybucjami typu rebuild. Pośpieszna migracja pozostawia pliki repozytoriów EL7 w /etc/yum.repos.d/ oraz zainstalowane pakiety EL7. Można je zidentyfikować za pomocą rpm -qa | grep el7. Każdy z nich jest pakietem, którego żadne włączone repozytorium nie zaktualizuje, a kolejne 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 planowanej dużej aktualizacji.

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

Przeniesienie 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 [sections], każdą z własnym identyfikatorem.
• add-apt-repository universe staje się dnf install epel-release, z tą różnicą, że universe nadal 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 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 python3-dnf-plugin-versionlock.
• Pinning 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ę raczej jako koncepcja niż składnia, ponieważ nie ma tutaj unattended-upgrades. Timer, plik konfiguracyjny oraz kwestia wymaganego restartu 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?

Jest to rozwiązanie powszechnie stosowane, oparte na zasadzie, że pakiety EPEL nigdy nie zastępują pakietów z dystrybucji bazowej, więc włączenie repozytorium nie zmienia zawartości BaseOS ani AppStream. Ograniczeniem jest wsparcie: EPEL to projekt społecznościowy Fedora bez umowy o poziomie świadczenia usług (SLA), a opiekun pakietu zobowiązuje się do jego utrzymania przez okres od jednego wydania minor 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 wystawiona na zewnątrz.

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. Komunikat błędu 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 instalacja nie jest jeszcze możliwa, 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 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 uszkodzić systemu?

Najpierw wykonaj inwentaryzację za pomocą dnf repository-packages epel list installed, ponieważ usunięcie samego pakietu epel-release nie usuwa 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. Podejmij decyzję dla każdego pakietu 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 zostało zastąpione i musi zostać usunięte, sudo dnf repository-packages epel remove wyczyści zestaw w jednej transakcji, więc dokładnie przeczytaj proponowaną listę przed jej zatwierdzeniem.