Rocky Linux ve AlmaLinux'ta EPEL ve CRB Depoları

dnf neden istediğiniz paketi bulamıyor

EPEL ve CRB, yeni kurulmuş bir Rocky Linux veya AlmaLinux sunucusunda varsayılan olarak sunulmayan iki depodur; bu nedenle yeni bir makinede dnf install htop komutu No match for argument: htop yanıtını verir ve ardından Error: Unable to find a match: htop hatası alınır. Herhangi bir bozulma yoktur ve hiçbir yansıma (mirror) sunucusu kapalı değildir. Temel dağıtım, paketlerin küçük bir kısmını bilinçli olarak sunar; CRB yüklü gelir ancak kapalıdır, EPEL ise ayrıca eklemeniz gereken bir topluluk deposudur.

Ubuntu üzerinde aynı paket universe içinde yer alır ve universe neredeyse tüm bulut imajlarında etkinleştirilmiş durumdadır; bu yüzden bu soru hiç gündeme gelmez. Red Hat ailesi paketlerini farklı şekilde sınıflandırır ve varsayılan olarak daha az paket sunar. Çözüm üç komuttan ibarettir. Bu kılavuzun geri kalanı, ilk haftada kimsenin size söylemediği kısımları içerir: bu depoların neleri taahhüt ettiği, neleri taahhüt etmediği ve üçüncü taraf bir deponun temel sisteminizi sessizce ele geçirmesini nasıl engelleyeceğiniz.

Bu komutlar nasıl kontrol edildi. Komut test container'larımız yalnızca Ubuntu çalıştırdığı için aşağıdaki dnf komutları kendi test makinelerimizde çalıştırılmamıştır. Bu komutlar, Rocky Linux ve AlmaLinux belgelerini takip eder. Her adım, görmeniz gereken çıktıyı belirtir; bu nedenle tüm bloğu tek seferde yapıştırmak yerine her birini kendi sunucunuzda kontrol edin.

BaseOS, AppStream ve CRB nedir?

BaseOS, işletim sisteminin kendisidir: çekirdek, glibc, systemd ve temel kullanıcı alanı. Buradaki sürümler, ana sürümün yaşam döngüsü boyunca nadiren değişir. Güvenlik düzeltmeleri dahil olmak üzere çoğu düzeltme, halihazırda sahip olduğunuz sürüme geriye dönük olarak aktarılır (backport); ancak ara sürümler bazen temel bir bileşeni daha yeni bir upstream sürümüne yükseltebilir (örneğin, AlmaLinux 9.2, SELinux kullanıcı alanı paketlerini 3.5 sürümüne güncellemiştir). BaseOS içinde yıllar öncesinden kalmış gibi görünen bir sürüm numarası, yamasız bir paket olduğu anlamına gelmez. Bu, kurumsal bir dağıtımın temel amacı olan, yamalanmış eski bir sürümdür.

AppStream, üzerinde çalıştırdığınız öğeleri barındırır: web sunucuları, veritabanları, dil çalışma zamanları, düzenleyiciler ve izleme aracıları. 8. sürümde, AppStream'in büyük bir kısmı alternatif akışlara sahip modüller olarak sunuluyordu; bu nedenle dnf module list önemliydi ve örneğin bir PHP akışını seçmeniz gerekiyordu. 9. sürüm, her uygulamanın varsayılan sürümünü düz bir paket olarak sunar; bu nedenle Rocky 9 ve Alma 9 üzerinde düz bir dnf install komutu, önce bir modülü etkinleştirmenize gerek kalmadan size o sürümü sağlar. Alternatif sürümler hala modül akışları olarak gelir: RHEL 9, PHP 8.0'ı standart php paketi olarak, PHP 8.1 ve 8.2'yi ise php:8.1 ve php:8.2 akışları olarak belgeler; AlmaLinux 9.8 ise MariaDB 11.8, PostgreSQL 18 ve Ruby 4.0 gibi yeni akışlar eklemiştir. Varsayılan sürüm dışında bir şeye ihtiyacınız varsa, 9. sürümde dnf module list hala önemlidir.

Extras varsayılan olarak etkindir ve oldukça küçüktür. Çoğunlukla diğer depolar için sürüm paketlerini barındırır; epel-release de buradan gelir. Bu detay, Rocky veya Alma üzerinde EPEL kurmak için neden rastgele bir URL'ye güvenmenize gerek olmadığının nedenidir.

CRB, 8. sürümde PowerTools olarak adlandırılan CodeReady Builder deposudur. Dağıtımın derleme tarafını barındırır: geliştirme başlıkları (headers), statik kütüphaneler ve paketlerin derleme zamanında ihtiyaç duyduğu test ve dokümantasyon araçları. Zaten yansıda (mirror) bulunur ve varsayılan olarak devre dışıdır. Red Hat'in kendi ürününde aynı içerik CodeReady Linux Builder olarak adlandırılır, abonelikle birlikte gelir ve Red Hat, bu içeriğin destek kapsamında olmadığını belirtir. Rocky ve Alma, hem içeriği hem de varsayılan olarak devre dışı olma durumunu devralır.

Debian veya Ubuntu'dan gelen okuyucular için: main, çalışma zamanı paketlerini ve -dev başlıklarını tek bir arşivde karıştırır, bu nedenle etkinleştirilecek bir CRB yoktur. EPEL'in en yakın karşılığı, topluluk tarafından sürdürülen ve herhangi bir satıcı destek taahhüdü taşımayan universe deposudur.

EPEL nedir ve arkasında kim vardır

EPEL, Extra Packages for Enterprise Linux ifadesinin kısaltmasıdır. Bir Fedora projesidir: Fedora'da bulunan paketlerin mevcut kurumsal sürüm için yeniden derlenmiş halidir. Çoğunluğu Fedora topluluğundan gönüllülerden oluşan EPEL Özel İlgi Grubu (Special Interest Group) tarafından yönetilir. Red Hat, derleme ve yansıma (mirror) altyapısını barındırır; bazı Red Hat mühendisleri de paketlerin bakımını üstlenir. İlişki burada sona erer. EPEL bir Red Hat ürünü değildir. EPEL paketleri için RHEL veya yeniden derlenmiş sürümler üzerinde herhangi bir destek sözleşmesi veya SLA (hizmet seviyesi anlaşması) bulunmaz.

EPEL'in etkinleştirilmesini güvenli kılan tek bir politika vardır: Bir EPEL paketi, temel dağıtımdan gelen bir paketin yerini asla alamaz. Eğer AppStream nginx paketini sunuyorsa, EPEL sunmayacaktır. Bu kural, EPEL paketlerini inceleyen kişiler tarafından uygulanır; dolayısıyla bu yalnızca EPEL ile ilgili bir taahhüttür. Daha sonra ekleyeceğiniz diğer unsurlara karşı sizi korumaz.

Yaşam döngüsü taahhüdü de temel dağıtımdan farklıdır ve üçüncü yılda sorun yaratan kısım budur. Bir BaseOS paketi, genellikle ana sürümün on yıllık ömrü boyunca aynı sürüm numarasını korur; düzeltmeler geriye dönük olarak aktarılır (backport) ve yalnızca nadiren kasıtlı bir sürüm yükseltmesi (rebase) yapılır. Bir EPEL paket sorumlusu çok daha kısa bir süre için taahhütte bulunur: EPEL'in sürüm tabanlı paket yaşam döngüsü önerisi, bunu en az bir RHEL ara sürümü veya 13 ay (hangisi daha kısaysa) olarak tanımlar. Uygulamada çoğu paket bundan çok daha uzun süre korunur. Bazıları paket sorumlusu ilgilenmeyi bıraktığında kullanımdan kaldırılır, bazıları ise EPEL Fedora'yı takip ettiği için dağıtımınızın ömrü boyunca yeni bir ana sürüme geçiş yapar. Bu nedenle, rutin bir dnf upgrade işlemi, kararlı olduğunu düşündüğünüz bir makinede bir EPEL aracının yeni bir ana sürümünü size getirebilir ve bağımlı olduğunuz bir paket, size ulaşan herhangi bir duyuru olmaksızın güncelleme almayı durdurabilir. Ayrıca yeni bir sürüm, halihazırda çalışan bir serviste hemen devreye girmez; bu nedenle işlem tamamlandığında hangi süreçlerin hala eski ikili dosyayı kullandığını size needs-restarting bildirir.

Etkinleştirmeden önce bilinmesi gereken bir diğer sonuç şudur: EPEL, sunucunuzda tutuyor olabileceğiniz eski ara sürümlere göre derlenmez. Fedora'nın EPEL politikası, güncel EPEL 10 ara sürümünü CentOS Stream 10'a göre, önceki EPEL 10 ara sürümlerini ise belirli RHEL 10 ara sürümlerine göre derler; EPEL 8 ve 9'un kendi hedef tanımları vardır. Eğer bir sunucuyu dondurulmuş bir yansıma veya satıcıya ait bir nokta sürüm deposu kullanarak eski bir ara sürümde tutuyorsanız, bir EPEL paketi elinizdekinden daha yeni bir temel kütüphaneye ihtiyaç duyabilir. dnf bunu eksik bir bağımlılık olarak raporlar; bu durum aslında bir sürüm uyumsuzluğu (version skew) sorunu olmasına rağmen bir yansıma sorunu gibi görünür.

Rocky veya Alma üzerinde CRB'yi etkinleştirme ve EPEL kurma

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 komutu artık baseos, appstream, extras, crb ve epel öğelerini listelemelidir. Ayrıca epel-release tarafından eklenen küçük bir epel-cisco-openh264 girdisi de görebilirsiniz. Eğer crb bu listede yoksa, etkinleştirme adımı gerçekleşmemiştir; bir sonraki bölüm bunun nedenini açıklamaktadır.

Rocky 8 ve Alma 8 üzerinde depo hala PowerTools olarak adlandırılmaktadır, bu nedenle orta komut sudo dnf config-manager --set-enabled powertools halini alır. Depo kimlikleri büyük/küçük harfe duyarlıdır; eski CentOS 8 belgeleri bunu büyük harflerle PowerTools şeklinde yazar ancak bu eşleşmeyecektir. AlmaLinux 10 üzerinde CRB deposu 10.0 sürümünden itibaren (Eylül 2025'te değiştirilmiştir) varsayılan olarak etkindir, bu nedenle orada yalnızca epel-release adımını uygulamanız yeterlidir.

epel-release, halihazırda etkin olan extras kaynağından gelir; bu nedenle güvenilecek bir URL veya elle içe aktarılacak bir anahtar yoktur. Paket, /etc/yum.repos.d/epel.repo dosyasını yazar ve EPEL imzalama anahtarını /etc/pki/rpm-gpg/ altına kurar. O dosyadaki gpgcheck=1 değerini doğrulayın ve sizi imza hatasını --nogpgcheck ile aşmaya yönlendiren hiçbir kılavuzu dikkate almayın. Başarısız bir imza denetimi, paketin iddia ettiği şey olmadığı veya sistem saatinizin yanlış olduğu anlamına gelir.

Rocky üzerinde epel-release, /usr/bin/crb konumuna küçük bir yardımcı araç da kurar; bu sayede sudo crb enable ve crb status eklenti olmadan aynı işi yapar. Buna güvenmeden önce command -v crb ile mevcut olup olmadığını kontrol edin, çünkü her yeniden yapılandırma dalında bulunmayabilir.

EPEL'in yalnızca listelenmekle kalmayıp erişilebilir olduğunu kanıtlamak için, yalnızca EPEL'de bulunan bir paketi sorgulayın:

dnf repoquery --repo=epel htop

Bu komut paket adını, sürümünü ve mimarisini yazdırır. Sessizlik, deponun etkin olduğu ancak hiçbir sonuç döndürmediği anlamına gelir; bu genellikle bir yapılandırma sorunundan ziyade bir yansıma (mirror) veya meta veri sorunudur, bu yüzden bir sonraki adımda sudo dnf clean all && sudo dnf makecache komutunu deneyin.

Neden dnf, config-manager komutunun bulunamadığını söylüyor

Bu durum, kullanıcıların karşılaştığı ilk engeldir ve tam olarak çoğu VPS sağlayıcısının sunduğu imajlarda yaşanır.

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, dnf'in yerleşik bir alt komutu değil, bir eklentisidir. Tam sunucu kurulumlarında otomatik olarak gelen ancak minimal imajlarda, bulut imajlarında ve container imajlarında dahil edilmeyen dnf-plugins-core paketi içerisinde yer alır. dnf'in kendi önerisi işe yarar çünkü paket bu sanal yeteneği tanımlar:

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

Komutu tırnak içine alın. Parantezler shell sözdizimi olduğundan, tırnak kullanılmayan bir sürüm dnf hatası yerine sözdizimi hatası verir.

Eğer ihtiyacınız olan depo devre dışı olduğu için eklentiyi kuramıyorsanız, dosyayı manuel olarak düzenleyin. İlgili bölümü içeren dosyayı bulun, açın ve [crb] altındaki enabled=1 değerini şu şekilde ayarlayın:

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

Bu işlem, config-manager komutunun yaptığı işlemin aynısıdır; dolayısıyla manuel yapmak herhangi bir kayba yol açmaz. dnf repolist --enabled komutu sonucu doğrular.

Bazı EPEL paketleri CRB etkinleştirilmeden kurulamaz

İkinci yaygın tuzak, hiçbir zaman CRB'den bahsetmeyen bir hata verir. Yalnızca CRB içinde sunulan bir kütüphaneye bağımlı olan bir EPEL paketi, bağımlılık çözümleme sırasında başarısız olur ve hata mesajı, kütüphanenin adını ve onu talep eden paketi belirtir:

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

Bunun nedeni CRB'nin devre dışı olmasıdır; bu nedenle dnf, söz konusu kütüphaneyi sağlayan tek depoyu göremez. Şu iki adımı sırasıyla kontrol edin:

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

Eğer ikinci komut bir paket adı döndürüyor ancak normal kurulum hala başarısız oluyorsa, CRB kapalıdır. Bu hata türü o kadar yaygındır ki AlmaLinux, bunun yaşanmasını engellemek için 10. sürümde CRB'yi varsayılan olarak etkinleştirmiştir. --enablerepo=crb de tek seferlik bir kurulumda bayrak olarak kullanılabilir, ancak EPEL kullanıyorsanız CRB'yi kalıcı olarak etkin bırakın; çünkü bir sonraki EPEL güncellemesi, sizi önceden uyarmadan yeni bir CRB bağımlılığı getirebilir.

Bu paket hangi depodan geldi?

Dört deponun etkin olduğu birkaç haftanın ardından, asıl önemli soru neyin yüklü olduğu değil, nereden geldiğidir.

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 komutu, yüklü bir paket üzerinde çalıştırıldığında bir From repo satırı yazdırır. dnf list installed, aynı bilgiyi üçüncü sütunda başında bir @ ile gösterir; bu nedenle @epel, paketin EPEL'den yüklendiği, @System ise dnf'in paketin kaynağını bilmediği anlamına gelir; bu durum genellikle birinin indirilen bir dosya üzerinde rpm -i çalıştırmasıyla oluşur. repoquery satırı, depo başına bir sayı verir; bu, devraldığınız bir sunucuda daha önce hiç duymadığınız bir depodan gelen kırk paket olduğunu keşfetmenin en hızlı yoludur. Son komut, bir deponun size tam olarak ne verdiğini listeler ve bir depoyu kaldırmaya karar vermeden önce ihtiyacınız olan envanter budur.

Buradaki apt alışkanlığı apt-cache policy <package> komutudur ve dnf ve apt komut karşılıkları belgesini ilk ay boyunca ikinci bir sekmede açık tutmak faydalıdır; çünkü kavramlar, bayraklar (flags) farklı olsa bile birbirleriyle net bir şekilde eşleşir.

Üçüncü taraf bir deponun temel bir paketi değiştirmesini nasıl engellerim?

EPEL bunu yapmayacağını taahhüt eder. Başka hiçbir depo bu garantiyi vermez. Bir veritabanı, aracı veya dil çalışma zamanı için kullanılan bir satıcı deposu, BaseOS'in de sağladığı bir kütüphanenin kendi sürümünü sunabilir. dnf, varsayılan kuralı "nereden gelirse gelsin en yüksek sürüm kazanır" şeklinde olduğu için bu paketi yükleyecektir.

İki kontrol mekanizması işin büyük kısmını halleder ve her ikisi de /etc/yum.repos.d/ altındaki depo dosyasında bulunur.

priority=, aynı paket adına sahip birden fazla depo olduğunda hangisinin kazanacağına karar verir. Daha düşük sayılar kazanır ve varsayılan değer 99'dur; bu nedenle temel depolarınıza düşük bir sayı, üçüncü taraf depolara ise yüksek bir sayı verin. Böylece dnf, üçüncü taraf sürümü daha yeni olsa bile temel paketi tercih eder. Modern dnf bunu kendi başına yönetir, bu yüzden CentOS 7 dönemindeki ayrı yum-plugin-priorities paketi artık çözümün bir parçası değildir.

includepkgs=, filtreleme seçenekleri arasında daha güçlü olanıdır. excludepkgs=, bir depodan belirli paketleri engeller; bu da deponun neleri sunabileceğini tahmin etmenizi gerektirir. includepkgs= ise bunu tersine çevirir: bu depo yalnızca belirtilen isimleri sağlayabilir, başka hiçbir şeyi sunamaz. Yalnızca kendi aracını sağlaması gereken bir satıcı deposu için bu tek satırlık bir işlemdir.

[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

Sürüm 8'de bilinmesi gereken bir ayar daha vardır. Bir AppStream modülü aynı ismi sağladığında, üçüncü taraf bir depodan gelen paket gizlenebilir; bu deponun bölümündeki module_hotfixes=1 ayarı, dnf'e filtrelemeyi durdurmasını söyler. Eğer satıcının deposunda kesinlikle bulunan bir paket 8 sürümü yüklü bir makinede eksik görünüyorsa veya yüklenmiyorsa, genellikle sebebi budur: modüler filtreleme, bir çakışma bildirmek yerine paketi çoğu dnf komutu için görünmez kılar. Sürüm 9'da daha az modül bulunur ancak yine de modül akışları (module streams) mevcuttur, bu nedenle bir satıcı paketi bir modülle aynı ismi paylaştığında aynı filtreleme uygulanabilir.

Bir paketi belirli bir sürüme sabitlemek için python3-dnf-plugin-versionlock paketini yükleyin ve sudo dnf versionlock add <package> komutunu kullanın. Bu, apt-mark hold komutunun karşılığıdır. Debian dünyasından gelenleri yanıltan bir farkı not edin: apt içinde daha yüksek bir Pin-Priority kazanırken, dnf içinde daha düşük bir priority kazanır.

RHEL tabanlı depoların karıştırılmasının sunucuyu neden yükseltilemez hale getirdiği

Rocky, Alma, CentOS Stream, Oracle Linux ve RHEL, paketlerinin birbirine kurulabileceği kadar yakın, ancak sonuçta kimsenin destekleyemeyeceği bir yapıya dönüşecek kadar da birbirinden uzaktır. Bu dağıtımların neden bu kadar yakın olduğu ve özellikle Stream'in neden RHEL'in yanında değil de önünde konumlandığı, Red Hat Linux'un Fedora ve RHEL olarak nasıl bölündüğünün ve CentOS'un akıbetinin hikayesidir.

Bunun temel mekanizması sürüm numaralarıdır. CentOS Stream 9, RHEL 9'un ilerisinde çalışır ve Red Hat, Stream kodunu bir sonraki RHEL ara sürümünü oluşturacak kod olarak tanımlar. Bir Rocky 9 sunucusunu, tek bir paket için bile olsa, bir kez Stream deposuna yönlendirmek, elinizde Rocky'nin mevcut sürümünden daha ileride paketler kalmasına neden olur. Daha sonraki bir Rocky ara sürümü bu sürüme yetişebilir, ancak hiçbir şey o paketi sizin sürümünüzde veya üzerinde sunacağını garanti etmez; bu gerçekleşene kadar dnf upgrade pakete dokunmayacaktır. Makine artık kimsenin test etmediği bir kombinasyonla çalışır ve siz sistemin yamalı olduğunu varsayarken, bu durum yıllarca sessizce devam edebilir.

Bunun belirtisi, dnf upgrade komutunun yapılacak bir işlem olmadığını bildirmesi, sudo dnf distro-sync komutunun ise uzun bir paket listesini düşürmeyi (downgrade) önermesidir. distro-sync onarım aracıdır: yüklü her paketi, düşürmeler dahil olmak üzere, etkinleştirilmiş depoların sunduğu sürümlerle eşleşmeye zorlar. Önce yabancı depoyu devre dışı bırakın, ardından komutu çalıştırın ve kabul etmeden önce önerilen listeyi inceleyin. Eski RPM artık yansıda (mirror) bulunmadığında onarım başarısız olur; bu noktada sunucuyu temiz bir imajdan yeniden kurmak, bağımlılık çözücü ile uğraşmaktan daha hızlı ve güvenlidir.

ELevate döneminden kalan artıklar, bu sorunun diğer yaygın bir türüdür. ELevate, bir CentOS 7 sunucusunu ileri taşımak veya yeniden derlenmiş dağıtımlar arasında geçiş yapmak için kullanılan, Leapp tabanlı bir AlmaLinux taşıma aracıdır. Aceleye getirilmiş bir taşıma işlemi, /etc/yum.repos.d/ dizininde EL7 depo dosyalarının ve hala yüklü olan EL7 paketlerinin kalmasına neden olur. Bunları rpm -qa | grep el7 ile bulun. Bunların her biri, etkin hiçbir deponun güncelleyemeyeceği paketlerdir ve daha sonraki bir Leapp çalışması bunları eşleyemediği paketler olarak raporlar; bu da elle temizlemeniz gereken bir yükseltme engelleyicisine dönüşür. Bunları, bir sonraki ana sürüm yükseltmesine ihtiyaç duyduğunuz gün değil, sunucu sakin durumdayken temizleyin.

Bir satıcı deposunun AppStream paketini gölgelemesi, aynı sorunun hafif bir versiyonudur ve yukarıdaki includepkgs satırı bunun çözümüdür. Konteyner araçları genellikle bu duruma yol açar; çünkü Docker'ın kendi deposundan gelen containerd.io, AppStream'deki runc ile çakışır, bu yüzden birinin gitmesi gerekir. Bir kez karar verin, dışlamayı (exclusion) not edin ve bilinen doğru bir sırayı takip edin: Rocky Linux üzerinde Docker kurulumu rehberi, önce hangi dağıtım paketlerinin kaldırılması gerektiğini açıklar.

apt'den dnf'ye depo (repository) geçişi

• /etc/apt/sources.list.d/*.sources, /etc/yum.repos.d/*.repo haline gelir; burada tek bir dosya, her biri kendi kimliğine sahip birden fazla [sections] barındırabilir.
• add-apt-repository universe, dnf install epel-release haline gelir; aradaki fark, universe'un Ubuntu'nun kendi arşivinde yer alması, EPEL'in ise ayrı bir proje olmasıdır.
• apt update'ın bir karşılığı yoktur, bunu hatırlamanız gerekir. dnf meta verileri kendi zamanlamasına göre yeniler, dnf makecache ise bunu hemen yapmaya zorlar.
• apt-cache policy <pkg>, dnf info <pkg> haline gelir; ayrıca sunulan tüm sürümleri görmek için dnf list --showduplicates <pkg> kullanılır.
• apt-mark hold, python3-dnf-plugin-versionlock içinden dnf versionlock add haline gelir.
• /etc/apt/preferences.d/ içindeki sabitleme (pinning), depo bölümünde priority= haline gelir ve numaralar ters yönde işler.
• dpkg -S /path/to/file, rpm -qf /path/to/file haline gelir.

Otomatik güncellemeler, söz dizimi olarak değil fikir olarak aktarılır çünkü burada unattended-upgrades yoktur. Zamanlayıcı, yapılandırma dosyası ve yeniden başlatma gerekliliği gibi konular Rocky ve Alma üzerinde dnf-automatic bölümünde ele alınmıştır.

Depo listesini kısa tutun

CRB'yi etkinleştirin, epel-release paketini kurun ve ardından yaptıklarınızı ve nedenlerini, yapılandırma yönetimi aracınıza veya sunucu üzerinde düz bir dosyaya not edin. Sunucu üç yıllık olduğunda ve yönetimi başkasına devrettiğinizde, bu notun değeri tahmin ettiğinizden çok daha fazladır.

Yeni bir depo eklemeden önce arama yapın. dnf search komutunu, ardından dnf info komutunu çalıştırın ve ancak o zaman yeni bir depo eklemeyi düşünün. İnsanların EPEL'i etkinleştirme nedenlerinin şaşırtıcı bir kısmı zaten AppStream içinde mevcuttur. Sistem izleme bunun en net örneğidir; çünkü Performance Co-Pilot temel depolarda yer alır ve herhangi bir üçüncü taraf yazılıma ihtiyaç duymaz. Eklenen her yeni depo, size herhangi bir Salı günü paket gönderebilecek yeni bir taraf demektir ve her biri, bir sonraki büyük sürüm yükseltmesini daha zor hale getirir.

Eğer hala iki dağıtım arasında seçim yapıyorsanız, bu düzenin her ikisinde de aynı olduğunu ve epel-release aracının her iki tarafta da aynı şekilde çalıştığını bilmelisiniz. Asıl farklar başka yerlerdedir: Rocky Linux ve AlmaLinux karşılaştırması, AlmaLinux'un artık birebir yeniden oluşturma yerine ABI (uygulama ikili arayüzü) uyumluluğunu hedeflemesi nedeniyle yeniden oluşturma felsefesindeki farkları ele almaktadır.

FAQ

Rocky Linux 9 veya AlmaLinux 9 üzerinde EPEL nasıl etkinleştirilir?

Önce sudo dnf install -y dnf-plugins-core, ardından sudo dnf config-manager --set-enabled crb ve son olarak sudo dnf install -y epel-release komutlarını çalıştırın. baseos, appstream, extras, crb ve epel öğelerini listelemesi gereken dnf repolist --enabled komutu ile doğrulamayı yapın. EPEL paketlerini kurmadan önce CRB'yi etkinleştirin; çünkü birçok paket, yalnızca CRB tarafından sağlanan kütüphanelere bağımlıdır. 8 numaralı sürümde depo kimliği crb yerine powertools şeklindedir.

Üretim sunucusunda EPEL'i etkinleştirmek güvenli midir?

Yaygın olarak kullanılır ve EPEL paketlerinin temel dağıtımdaki paketlerin yerini asla almaması ilkesi üzerine kuruludur; bu nedenle etkinleştirmek, BaseOS veya AppStream tarafından sağlananları değiştirmez. Buradaki çekince destektir: EPEL, hizmet seviyesi anlaşması (SLA) bulunmayan gönüllü bir Fedora projesidir ve EPEL paket ömrü önerisi, bir paket sorumlusunun paketi en az bir RHEL ara sürümü veya 13 ay boyunca desteklemesini bekler. dnf repository-packages epel list installed ile bir envanter tutun ve müşteriye dönük bir servisin bağımlı olduğu tüm EPEL paketleri için dnf versionlock kullanın.

dnf neden "no such command: config-manager" hatası veriyor?

Çünkü config-manager yerleşik bir komut değil, bir dnf eklentisidir ve minimal veya container imajları dnf-plugins-core olmadan gelir. Hata mesajının kendisi çözümü sunar: Kabuğun parantezleri okumaması için tırnak içine alınmış sudo dnf install -y 'dnf-command(config-manager)' komutunu çalıştırın. Henüz hiçbir şey kuramıyorsanız, grep -rl crb /etc/yum.repos.d/ komutunu çalıştırın, belirttiği dosyayı açın ve [crb] bölümündeki enabled=1 ayarını manuel olarak yapın.

CRB ve PowerTools arasındaki fark nedir?

Bunlar aynı deponun iki farklı ismidir. 8 numaralı sürümde powertools kimliği ile PowerTools olarak adlandırılırken, 9 ve sonraki sürümlerde crb kimliği ile CRB olarak adlandırılır; Red Hat'in kendi ürününde ise bu içerik CodeReady Linux Builder olarak geçer. Geliştirme başlıklarını, statik kütüphaneleri ve derleme zamanı araçlarını içerir; Rocky ve AlmaLinux 9 üzerinde varsayılan olarak devre dışıdır. AlmaLinux 10, 10.0 sürümünden itibaren bunu varsayılan olarak etkinleştirir, bu nedenle orada etkinleştirme komutunu çalıştırmadan önce dnf repolist --enabled dosyasını kontrol edin.

EPEL'i sistemde sorun yaratmadan nasıl kaldırabilirim?

Önce dnf repository-packages epel list installed ile envanter çıkarın; çünkü yalnızca epel-release paketini kaldırmak, EPEL üzerinden kurulan hiçbir şeyi silmez. Bu paketler diskte kalır, güncelleme kaynaklarını kaybeder ve herhangi bir hata uyarısı vermeden güvenlik yamalarını almayı durdurur. Paket bazında karar verin, artık ihtiyacınız olmayanları kaldırın veya değiştirin, ancak ondan sonra sudo dnf remove epel-release komutunu çalıştırın. Eğer EPEL'den gelen bir paket hiçbir şeyin yerini almadıysa ve mutlaka gitmesi gerekiyorsa, sudo dnf repository-packages epel remove tüm seti tek bir işlemde temizler; bu nedenle onay vermeden önce önerilen listeyi dikkatlice okuyun.