Uygulamanın Desteklediği Linux Dağıtımı ve Çekirdek Sertifikasyon Aralığı

Linux Sistem Yönetimi

“Asgarinin üzerindeyiz, sorun olmaz”

Çekirdek sertifikasyonu hakkındaki en yaygın yanılgı, üreticinin yayımladığı tek bir satırı yanlış okumaktan doğuyor. Oracle 19c ve RHEL 9 örneğinde, yamanın içine bakarak.

26 Ağustos 2026

Kurumsal Linux ortamlarında yıllardır aynı cümleyi duyuyorum:

Sık duyulan

“Üreticinin istediği asgari çekirdek sürümü şu. Biz onun üzerindeyiz. O zaman en güncel yamaya çıkabiliriz.”

Cümle mantıklı görünüyor. Yazılım bir asgari sürüm istiyor, siz o sürümün üzerindesiniz, dolayısıyla şart sağlanmış oluyor. Sürüm numaraları sonuçta artan bir sayı dizisi; büyük olan küçüğü kapsar.

Ne yazık ki bu, işletim sistemi çekirdeğine modül yükleyen yazılımlar söz konusu olduğunda doğru değil. Bu yazıda neden doğru olmadığını, Oracle Database 19c ile Red Hat Enterprise Linux 9 örneği üzerinden, doğrulanabilir kanıtlarla anlatacağım. Örnek Oracle ama mesele Oracle’a özgü değil — sonunda buna döneceğim.

Asgari sürüm bir taban çizgisidir, aralık değil

Oracle’ın Grid Infrastructure ve RAC kurulum kılavuzundaki işletim sistemi kontrol listesinde RHEL 9 satırı şöyle:

Oracle — OS Checklist for Grid Infrastructure and Oracle RAC, 19c

Red Hat Enterprise Linux 9: 5.14.0-70.22.1.el9_0.x86_64 or later

“or later” ifadesi, cümleyi okuyan herkesi aynı yere götürüyor: daha yeni olan her çekirdek uygun. Oysa bu satır yalnızca alt sınırı söylüyor. Bir üst sınır olup olmadığı hakkında hiçbir şey söylemiyor — ve üst sınır, aynı belgede değil, yazılımın kendi içinde tanımlı.

Bunu görmek için belgeleri okumayı bırakıp yazılımın içine bakmak gerekiyor.

Kanıt: yamanın içine bakmak

Oracle’ın küme dosya sistemi ACFS ve disk filtresi AFD, kullanıcı alanında çalışan programlar değil; çekirdek modülleri. Oracle bu modülleri sizin sisteminizde kaynak koddan derletmiyor. Her Release Update’in (RU) içine, belirli çekirdek sürümleri için önceden derlenmiş olarak koyuyor.

Elimdeki en güncel yama olan 19.29.0.0.251021 (Ekim 2025) GI RU’sunun içindeki ACFS bileşenini açıp usm/install/Oracle/EL9/x86_64/ dizinine baktığımda karşıma çıkan sürücülerin tamamı şunlar:

oracleacfs-5.14.0-284.11.1.el9_2.x86_64.rpm    →  RHEL 9.2
oracleacfs-5.14.0-362.18.1.el9_3.x86_64.rpm    →  RHEL 9.3
oracleacfs-5.14.0-427.13.1.el9_4.x86_64.rpm    →  RHEL 9.4
oracleacfs-5.14.0-503.11.1.el9_5.x86_64.rpm    →  RHEL 9.5
oracleacfs-5.14.0-570.12.1.el9_6.x86_64.rpm    →  RHEL 9.6

RHEL 9 ara sürümleri ve en güncel RU’daki ACFS sürücü karşılıkları

9.0yok

9.1yok

9.25.14.0-284

9.35.14.0-362

9.45.14.0-427

9.55.14.0-503

9.65.14.0-570

9.7yok

9.8yok

belgedeki
asgari sürüm

bugün kurulan
tipik sistem

Derlenmiş sürücü var Sürücü yok

Bu liste üç şeyi birden söylüyor.

Birincisi, destek bir aralık değil, ayrık bir liste. Her RHEL ara sürümü için tam olarak bir sürücü var. “Şu sürümden sonrası” diye bir şey yok; “şu beş sürüm” var.

İkincisi, listenin bir tavanı var. En güncel yamanın desteklediği en yeni çekirdek 5.14.0-570, yani RHEL 9.6. Sisteminiz 9.7 veya 9.8 ise — ki bugün yeni kurulan bir RHEL 9 büyük ihtimalle öyle olacak — bu çekirdek için Oracle’ın yayımladığı bir sürücü yok.

Üçüncüsü, ve en can sıkıcısı: belgedeki asgari sürümün kendisi bile listede yok. Kontrol listesi 5.14.0-70 diyor, yani RHEL 9.0. Ama yukarıdaki listede 9.0 ve 9.1 için sürücü bulunmuyor. Yani kontrol listesindeki asgari şartı harfiyen sağlayan bir sistem kurup ACFS kullanmaya kalksanız, çalışmayacaktı.

Belgedeki tek satıra bakıp karar vermenin neden yetmediği tam olarak burada görülüyor.

Kurulum daha ilk adımda duruyor

İşin ilginç tarafı, bu sistemlerde sorun genellikle çalışma zamanında değil, çok daha erken ortaya çıkıyor.

Oracle 19c’nin baz kurulum medyası olan 19.3.0.0’ın içindeki ön koşul doğrulama tanım dosyasına (cv/cvdata/cvu_prereq.xml) baktığımda, tanımlı işletim sistemlerinin tamamı şunlar:

<OPERATING_SYSTEM RELEASE="OL7">
<OPERATING_SYSTEM RELEASE="RHEL7">
<OPERATING_SYSTEM RELEASE="SUSE12">
<OPERATING_SYSTEM RELEASE="SUSE15">

Listede RHEL 8 bile yok. Sebep basit: bu dosyanın tarihi 18 Şubat 2019. RHEL 9, Mayıs 2022’de çıktı. Medya, üzerine kurulmasını istediğiniz işletim sisteminden üç yıl eski.

Kurulum sihirbazı sistemi tanıyamadığı için ön koşul kontrolünde duruyor. Bu bir hata değil, tasarlanmış davranış.

İnternette bu noktada CV_ASSUME_DISTID gibi bir değişkenle kurulum programına sistemi RHEL 7 ya da 8 gibi tanıtmayı öneren çok sayıda yazı bulacaksınız. Yöntem işe yarıyor — kurulum ilerliyor. Ama ortaya çıkan şey, üreticinin desteklemediği bir konfigürasyon. Bir laboratuvarda sorun değil; üretim ortamında, bir destek talebinin ilk kapanma sebebi.

Doğru yol: yamayı kurulum sırasında uygulamak

Oracle’ın desteklediği yöntem, çoğu kişinin farkında olmadığı bir seçenekte gizli. Grid Infrastructure kurulum kılavuzundan:

Oracle — Applying Patches During a GI Installation or Upgrade, 19c

“Starting with Oracle Grid Infrastructure 18c, you can download and apply Release Updates (RUs) and one-off patches during an Oracle Grid Infrastructure installation or upgrade.”

Komut şu şekilde:

./gridSetup.sh -applyRU /yol/38298204 \
               -applyOneOffs /yol/one-off-1,/yol/one-off-2

Yani kurulum programı, kendisini önce yamalıyor, sonra kuruluma başlıyor. Yamalanmış kurulum programı yeni işletim sistemlerini tanıyor, güncel ön koşul tanımlarına sahip oluyor ve doğru sürücüleri getiriyor.

Buradan çıkan pratik sıralama şöyle:

1. Hedef RHEL ara sürümüne, RU’nun sürücü listesine bakarak karar verin.
2. Sistemi o sürüme kurun ve çekirdeği sabitleyin.
3. Üreticinin ön hazırlık paketini (oracle-database-preinstall-* benzeri) kurun.
4. OPatch’i güncelleyin — 19.29 için asgari 12.2.0.1.47.
5. Kurulumu -applyRU ile başlatın.
6. Kurulum sonrası acfsdriverstate supported ve afddriverstate supported ile doğrulayın.

Sıra önemli. Kurulum sonrası da aynı sıra geçerli: önce yazılımı hedef çekirdeği destekleyen seviyeye çıkarın, sonra işletim sistemini güncelleyin. Ters sırada ilerlerseniz, sunucu açılıyor ama sürücüsü olmayan bir çekirdeğe düşüyor; dosya sistemi mount edilemiyor, küme kaynakları gelmiyor.

Peki bu kısıttan kaçınmak mümkün mü?

Kısmen, evet. Ve burada 2026 itibarıyla çoğu kişinin kaçırdığı önemli bir gelişme var.

ASM disklerinin yönetimi için üç yol var: AFD (ASM Filter Driver), ASMLib ve udev kuralları. Yaygın kanı, Oracle’ın kendi ürünü olan AFD’nin tercih edilmesi gerektiği yönünde. Oysa Oracle 19c dokümantasyonundaki bildirim şöyle:

Oracle — Changes in This Release, 19c · “Deprecation of Oracle ASMFD”

“Oracle ASM Filter Driver (ASMFD) is deprecated on both Linux and Oracle Solaris beginning with Oracle Database 19c. It will be desupported in a future release.

On Linux systems running kernel 5.14 or higher (including Oracle Linux, RedHat Enterprise Linux, and SUSE Linux Enterprise Server), ASMFD filtering is already disabled and will not be supported going forward.”

RHEL 9’un tamamı 5.14 çekirdek ailesinde. Yani AFD’nin varlık sebebi olan özellik — ASM disklerine Oracle dışı yazmaları engelleyen filtre — RHEL 9’da zaten çalışmıyor. Geriye kalan tek işlevi disk adlandırma ve kalıcılık.

Oracle aynı yerde ASMLib v3’e geçilmesini öneriyor. Ancak ASMLib bir Oracle Linux bileşeni: “Oracle ASMLib is included with the Oracle Linux packages, and with SUSE Linux Enterprise Server.” Red Hat dağıtımları için ayrı bir destek notuna yönlendiriliyor ve Oracle’ın ASMLib indirme sayfaları RHEL 5, 6, 7 ile OL8, OL9 için mevcutken RHEL 8 ve RHEL 9 için bulunmuyor.

Geriye udev kalıyor — ve udev, Oracle’ın kendi kurulum kılavuzunda “Configuring Device Persistence Manually for Oracle ASM” başlığı altında adım adım belgelenmiş durumda.

RHEL 9’da	AFD	ASMLib v3	udev
19c’deki durumu	Deprecated	Destekleniyor	Destekleniyor
Filtreleme	Devre dışı	—	—
Erişilebilir mi	Evet	Belirsiz	Evet
Çekirdek modülü gerektirir mi	Evet	Hayır	Hayır
Çekirdek sürümüne kilitler mi	Evet	Hayır	Hayır

Sonuç açık: RHEL 9’da AFD, sizi çekirdek sürümüne kilitliyor ve karşılığında asıl faydasını sunmuyor. udev yalnızca bir alternatif değil, üreticinin kendi yol haritasıyla uyumlu olan tercih.

Bir ayrımı vurgulamakta fayda var: AFD ile ACFS aynı şey değil. AFD bir disk filtresi, ACFS bir küme dosya sistemi. udev’e geçmek AFD kaynaklı çekirdek kilidini kaldırır; ancak gerçekten ACFS dosya sistemi kullanıyorsanız oradaki kilit yerinde durur. ACFS’i gerçekten ihtiyaç duyduğunuz için mi yoksa kurulum sırasında öyle geldiği için mi kullandığınız, sorulmaya değer bir soru.

Bu yalnızca Oracle’ın meselesi değil

Buraya kadar anlattığım her şey Oracle örneği üzerindendi ama kural genel: çekirdeğe modül yükleyen her yazılım, çekirdek sürümüne sıkı biçimde bağlıdır.

Aynı davranışı şuralarda da görürsünüz:

• Depolama ve küme dosya sistemleri (GPFS/Spectrum Scale, Lustre, ZFS on Linux)
• Yedekleme ajanları ve snapshot sürücüleri
• GPU sürücüleri (NVIDIA) ve hızlandırıcı yığınları
• Sanallaştırma misafir araçları
• Kernel modülü olan güvenlik/EDR ajanları
• Bazı ağ ve multipath eklentileri

Bu ürünlerin bir kısmı DKMS ile kaynak koddan derlenir; onlarda esneklik daha fazladır ama bu sefer de derlemenin yeni çekirdek API’siyle uyumlu olması gerekir. Bir kısmı ise Oracle gibi önceden derlenmiş modül dağıtır; orada esneklik sıfırdır.

Buna karşılık, tipik bir uygulama yığını — web sunucusu, PHP, MariaDB, uygulama sunucuları — çekirdek sürümüne bu düzeyde bağlı değildir. Onlarda “asgarinin üzerinde olmak” çoğu zaman gerçekten yeterlidir. Yanılgı da buradan doğuyor: ekipler bir alanda geçerli olan sezgiyi, geçerli olmadığı bir alana taşıyorlar.

Pratik kontrol listesi

Bir sisteme çekirdek güncellemesi planlarken şu dört soruyu sorun:

1. Bu sistemde çekirdek modülü yükleyen bir ürün var mı? lsmod çıktısını dağıtımın kendi paketleriyle karşılaştırın; dışarıdan gelen modülleri tespit edin.
2. Varsa, hedef çekirdek üreticinin sertifikasyon listesinde mi? Belgedeki asgari sürüme değil, ürünün kendi sürücü listesine bakın. Çoğu zaman bu liste yamanın içindedir.
3. Sıra ne olmalı? Neredeyse her zaman: önce uygulamayı hedef çekirdeği destekleyen sürüme çıkar, sonra işletim sistemini güncelle.
4. Geri dönüş planı ne? Eski çekirdek GRUB’da duruyor mu, grubby --default-kernel beklediğiniz değeri veriyor mu?

Ve kümelenmiş sistemlerde bir beşincisi: güncelleme düğüm düğüm yapılır, pencere kapanmadan tüm düğümler aynı seviyede eşitlenir.

Kapanış

“En güncel yamaya çıkmak” güvenlik açısından doğru bir refleks ve çoğu sunucu için doğru cevap. Ama çekirdek modülü barındıran sistemlerde hedef, “en güncel” değil, “üreticinin desteklediği en güncel” olmalı. Bu ikisi aynı şey değil ve aradaki fark, bir bakım penceresinin sessizce geçmesiyle gece yarısı telefonla uyanmak arasındaki fark olabiliyor.

En sağlıklısı, bu konuşmayı sorun çıktığında değil, hedef sürüme karar verirken yapmak. Sistem ekibiyle veritabanı ekibi burada karşı taraflar değil; aynı hizmetin iki parçası. Bir tarafta çıkan aksaklığın faturasını er geç ikisi birlikte ödüyor.

Kaynaklar

• Oracle — Operating System Checklist for Oracle Grid Infrastructure and Oracle RAC, 19c · docs.oracle.com
• Oracle — Applying Patches During an Oracle Grid Infrastructure Installation or Upgrade, 19c · docs.oracle.com
• Oracle — Changes in This Release for Oracle Database (“Deprecation of Oracle ASMFD”), 19c · docs.oracle.com
• Oracle — Configuring Device Persistence Manually for Oracle ASM, 19c · docs.oracle.com
• Oracle — Installing and Configuring Oracle ASMLIB Software, 19c · docs.oracle.com
• Oracle — About Oracle Grid Infrastructure Software Patch Levels, 19c · docs.oracle.com
• Mike Dietrich (Oracle) — Oracle Database 19c is certified on OL9 and RHEL9 · mikedietrichde.com
• Oracle MOS — ACFS and AFD Support On OS Platforms (Certification Matrix), Doc ID 1369107.1
• Oracle MOS — Requirements for Installing Oracle Database/Client 19c (19.19+) on OL9 or RHEL9, Doc ID 2982833.1

Yazıdaki sürücü listesi ve cvu_prereq.xml içeriği, Oracle’ın kendi kurulum ve yama medyasından doğrudan çıkarılmıştır.

Ansible · Değişkenler

Ansible değişkenlerini doğru yerde tutmak

Ansible'da 22 farklı değişken katmanı var. Asıl soru “hangisi kazanır?” değil — belgelerde yazıyor. Asıl soru şu: bu değişkeni nereye koymalıyım?

Ansible öğrenirken herkesin karşılaştığı bir an vardır: bir değişkeni değiştirirsiniz ama hiçbir şey olmaz. Başka bir yerde tanımlı aynı isimli değişken sizinkini eziyordur. Bu noktada çoğu kişi öncelik tablosunu ezberlemeye çalışır. Oysa tabloyu ezberlemek semptomu tedavi eder; hastalığı değil.

Hastalık şu: değişkeni ne olduğuna değil, o an aklınıza gelen yere koymak. Bu yazıda gerçek bir projeden — RHEL 9 ve RHEL 10 için osbuild-composer ile imaj üreten bir rolden — örneklerle, bir değişkenin yerini nasıl belirleyeceğinizi anlatacağım. Kendi yaptığım hatayı da göstereceğim.

Önce kısa hatırlatma: öncelik sırası

Ansible değişkenleri en düşükten en yükseğe doğru şu sırayla uygular. Sondakiler öncekileri ezer:

#	Katman	Ne zaman kullanılır
2	Rol defaults/	Rolün makul varsayılanı
3	Envanter dosyasındaki grup değişkenleri	Nadiren; dağınık olur
4	Envanter group_vars/all	Tüm makinelere ortak makine bilgisi
5	Playbook group_vars/all	Playbook'a özgü, tüm gruplara
6	Envanter group_vars/*	Ortama/gruba özgü makine bilgisi
7	Playbook group_vars/*	Playbook'un gruba özgü zorlaması
9	Envanter host_vars/*	Tek makineye özgü
11	Facts ve set_fact	Çalışma anında keşfedilen
12	Play vars:	Playbook'un kendi bağlamı
15	Rol vars/	Rolün ezilmemesi gereken sabitleri
18	include_vars	Koşullu yükleme (ör. sürüme göre)
22	-e extra vars	Tek çalıştırmaya özgü; her şeyi ezer

Dikkat edilecek iki nokta var. Birincisi: group_vars/ ve host_vars/ iki ayrı yerde bulunabilir — envanterin yanında ve playbook'un yanında. İkincisi: playbook'un yanındaki, envanterinkini ezer.

Bunu kanıtlayalım

İddiaya güvenmeyin, ölçün. Üç katmanda aynı değişkeni tanımlayıp tek tek kaldıralım:

$ tree
├── inventory/
│   ├── hosts.yml
│   └── group_vars/all.yml        → nereden: "2-INVENTORY group_vars/all"
├── group_vars/all.yml            → nereden: "3-PLAYBOOK group_vars/all"
├── roles/demo/defaults/main.yml  → nereden: "1-ROLE defaults"
└── pb.yml

$ ansible-playbook -i inventory/hosts.yml pb.yml
kazanan -> 3-PLAYBOOK group_vars/all

$ rm group_vars/all.yml && ansible-playbook ...
kazanan -> 2-INVENTORY group_vars/all

$ rm inventory/group_vars/all.yml && ansible-playbook ...
kazanan -> 1-ROLE defaults

Playbook group_vars > envanter group_vars > rol defaults. Beklendiği gibi.

Pratik ipucu. Bir değerin nereden geldiğini merak ettiğinizde tahmin etmeyin: ansible-inventory --graph --vars ve ansible-inventory --host <makine> size envanterden gelenlerin tamamını gösterir. Rol katmanları için de ansible-playbook --list-tasks ve bir debug görevi en hızlı yoldur.

Asıl soru: bu değişken neyi tarif ediyor?

Karar kuralı bu kadar basit. Değişkenin adına değil, anlamına bakın:

Değişken neyi tarif ediyor?	Yeri	Neden
Makineyi / ortamı “RHEL 9 sunucusu şudur”	Envanter group_vars/	Envanterle birlikte seyahat eder. Aynı envanteri kullanan her playbook aynı bilgiyi alır.
Rolün makul varsayılanını “aksi söylenmedikçe böyle davran”	Rol defaults/	En düşük öncelik = her katmandan ezilebilir. Rol kendi kendine yeter hale gelir.
Playbook'un kendi bağlamını “çıktıları buraya yaz”	Play vars:	Hedef makineyle ilgisi yoktur; envantere konursa yanlış yere yayılır.
Bu çalıştırmaya özgü seçimi “şimdi RHEL 10 üret”	-e	Her şeyi ezer, kalıcı değildir. Tam da geçici seçim için.
Ezilmemesi gerekeni iç sabitler, eşleme tabloları	Rol vars/	Yüksek önceliklidir; kullanıcının kazara ezmesini istemediğiniz şeyler.

Gerçek bir örnek: osbuild imaj üretim rolü

Bu rol, parametre alarak RHEL 9 veya RHEL 10 için ISO / qcow2 / vmdk imajları üretiyor:

ansible-playbook build-image.yml \
  -e rhel_version=10 -e image_template=devel \
  -e '{"image_types":["qcow2","vmdk"]}'

rhel_version doğrudan hedef grubu seçiyor: RHEL 9 imajı RHEL 9 sunucusunda üretilmeli, çünkü osbuild-composer kendi host sürümünü varsayılan distro olarak alır.

Envanterde ne var

# inventory/group_vars/osbuild_rhel10.yml
ansible_user: remzi
ansible_become: true
osbuild_expected_major: "10"
osbuild_extra_sources:
  - id: crb
    url: https://cdn.redhat.com/.../codeready-builder/os
    required_for_templates: ["devel"]

Bunların hepsi makineyi tarif ediyor. “RHEL 10 sunucusunda CRB deposu gerekir” bilgisi, hangi playbook'u çalıştırdığınızdan bağımsızdır. Yarın bir cleanup.yml yazarsanız o da aynı envanteri kullanıp aynı bilgiyi alır.

Rol varsayılanlarında ne var

# roles/osbuild_image/defaults/main.yml
run_boot_test: true
enable_kdump: true
kdump_crashkernel: "2G-64G:256M,64G-:512M"
min_free_gib: {minimal: 12, devel: 30}

lvm_volumes:
  - {name: rootlv,     mount: /,          size_gib: 30, label: root}
  - {name: varcrashlv, mount: /var/crash, size_gib: 2,  label: var_crash}
  # ... 11 mantıksal birim

Disk şeması burada olmalı, çünkü rolün ne ürettiğini tarif ediyor. Üstelik tek kaynak olması sayesinde hem customizations.disk (qcow2/vmdk) hem de kickstart logvol satırları (ISO) aynı listeden üretiliyor — ikisinin birbirinden ayrışması yapısal olarak imkânsız hale geliyor.

Playbook'ta ne var

# build-image.yml
  vars:
    image_fetch_dir: "{{ playbook_dir }}/imajlar"
    artifact_dir: "{{ playbook_dir }}/artifacts"

Bunlar kontrol makinesinin yolları. Hedef sunucuyla hiçbir ilgileri yok. Ayrıca playbook_dir ancak playbook bağlamında anlamlıdır — envantere koyarsanız, aynı envanter başka bir dizinden kullanıldığında yanlış çözülür.

Benim yaptığım hata

İlk versiyonda politika değişkenlerinin hepsini envanterin group_vars/all.yml dosyasına koymuştum:

# inventory/group_vars/all.yml   ← YANLIŞ
run_boot_test: true
enable_kdump: true
min_free_gib: {minimal: 12, devel: 30}
compose_timeout_min: 90
image_fetch_dir: "{{ playbook_dir }}/imajlar"

Çalışıyordu. Ama iki gerçek sakıncası vardı:

1. Ezme zinciri yanlış yerden başlıyordu. enable_kdump rolün varsayılanı olmalıydı. Envantere konunca rol defaults'ı sessizce eziliyor ve rol tek başına anlamsız hale geliyor — birisi rolü başka bir projede kullanmak istese, hangi değişkenleri tanımlaması gerektiğini bilemez.
2. İkinci bir ortam eklendiğinde kopyalama zorunluluğu. inventory/prod/ ve inventory/test/ açtığınızda, ortamla hiç ilgisi olmayan politika değişkenlerini de iki kez yazmanız gerekir. Kopya olan yerde er geç ikisi birbirinden ayrışır.

Düzeltilmiş hali:

Değişken	Önce	Sonra
ansible_user, osbuild_extra_sources	envanter group_vars	aynı — doğruydu
enable_kdump, run_boot_test, min_free_gib	envanter group_vars/all	rol defaults
image_fetch_dir, artifact_dir	envanter group_vars/all	play vars:
rhel_version, image_types	-e	aynı — doğruydu

Envanterin group_vars/all.yml dosyası artık boş — ama silmedim. İleride gerçekten tüm makinelere ortak bir makine ayarı gerektiğinde (proxy, zaman sunucusu, ortak depo) yeri orasıdır. Dosyanın içine bunu bir yorum olarak yazdım; boş bir dosyadan çok, niyeti belgelenmiş bir dosya bırakmak daha iyidir.

Sürüme göre değişenler: include_vars

Bu projede öğrendiğim en değerli şeylerden biri, sürüm farklarını veri olarak tutmaktı. RHEL 10'da kdump, kexec-tools paketinden ayrılıp kdump-utils'e taşınmış. Bunu göreve gömmek yerine:

- name: "Sürüme özel değişkenleri yükle"
  ansible.builtin.include_vars:
    file: "rhel{{ rhel_version }}.yml"

Böylece vars/rhel9.yml ve vars/rhel10.yml sürüm farklarını taşır, görevler sürümden bağımsız kalır. include_vars'ın önceliği yüksektir (18. sıra) — bu tam olarak istediğimiz şey: sürüme özgü veri, genel varsayılanı ezmeli.

Daha da iyisi: bu projede kdump paketini sabit yazmak yerine çalışma anında sorduk — dnf repoquery --file /usr/lib/systemd/system/kdump.service. Sonuç: RHEL 9'da kexec-tools, RHEL 10'da kdump-utils bulundu, hiçbir yere sabit yazılmadan. Değişkene hiç gerek kalmadı. En iyi değişken, yazmak zorunda kalmadığınız değişkendir.

Kaçınılması gereken üç tuzak

1. set_fact tipi sessizce değiştirir

Bir JSON dosyasını okuyup metin araması yapmak istedim:

- set_fact:
    manifest_text: "{{ manifest_raw.content | b64decode }}"

- assert:
    that: "'org.osbuild.lvm2.create' in manifest_text"   # her zaman False!

İçerik JSON'a benzediği için Ansible onu otomatik olarak dict'e çevirdi. Dolayısıyla in operatörü metin değil anahtar araması yaptı. Aradığım şey dosyada vardı ama testi hiç geçmiyordu. Çözüm: metin araması yerine from_json ile ayrıştırıp yapısal denetim yapmak.

2. delegate_to bağlantı değişkenlerini değiştirir

- command: "{{ 'cp ...' if ansible_connection == 'local' else 'scp ...' }}"
  delegate_to: localhost      # ← ansible_connection artık 'local'!

Delegasyon yapılan görevde ansible_connection, delegasyon hedefinin bağlantı türüdür. Asıl hedefin bilgisini kullanacaksanız, onu delegasyondan önce bir set_fact ile saklayın. Bu hatayı fark etmem, aynı kodun bir sunucuda çalışıp diğerinde patlamasını görmemi gerektirdi.

3. -e geri alınamaz

Extra vars her şeyi ezer ve playbook içinden değiştirilemez. Bu yüzden -e'yi yalnızca o çalıştırmaya özgü seçimler için kullanın (rhel_version, image_types). Kalıcı politikayı -e ile taşımaya başlarsanız, her çalıştırmada uzun bir komut satırı ezberlemek zorunda kalırsınız — ve bir gün birini yazmayı unutursunuz.

Özet: karar ağacı

Soru	Cevap
Makineyi/ortamı mı tarif ediyor?	Envanter group_vars/ · host_vars/
Rolün makul varsayılanı mı?	Rol defaults/
Sürüme/platforma göre mi değişiyor?	Rol vars/ + include_vars
Playbook'un kendi bağlamı mı?	Play vars:
Bu çalıştırmaya mı özgü?	-e
Kullanıcı ezerse bozulur mu?	Rol vars/ (defaults değil)

Bu kuralı uyguladığınızda öncelik tablosunu ezberlemenize gerek kalmaz — çünkü çakışma çıkmaz. Tablo, ancak aynı değişkeni birden fazla katmanda tanımladığınızda gerekir; ve bunu yapıyorsanız muhtemelen değişkeni yanlış yere koymuşsunuzdur.

Bu yazıdaki örnekler, RHEL 9 ve RHEL 10 için osbuild-composer ile ISO / qcow2 / vmdk imajları üreten gerçek bir Ansible rolünden alınmıştır. Öncelik sırasının tamamı için: Ansible — Using Variables.

Podman'da "unresolvable CDI devices nvidia.com/gpu=all" Hatası ve Çözümü

Podman'da "unresolvable CDI devices nvidia.com/gpu=all" Hatası ve Çözümü

Podman ile GPU gerektiren bir container (örneğin RHEL CLA, ollama, vllm gibi) çalıştırmaya çalışırken şu hatayı alabilirsiniz:

Error: setting up CDI devices: unresolvable CDI devices nvidia.com/gpu=all

Bu hata, NVIDIA sürücünüz düzgün çalışıyor olsa bile (nvidia-smi çıktısı normal görünse bile) ortaya çıkabilir. Sorunun kaynağı, Podman'ın GPU'ya erişmek için kullandığı CDI (Container Device Interface) spec dosyasının sisteminizde bulunmamasıdır.

CDI Nedir?

CDI, container runtime'larının (Podman, Docker vb.) GPU gibi özel donanımlara erişimini standartlaştıran bir arayüzdür. Podman, --device nvidia.com/gpu=all gibi bir parametre aldığında, /etc/cdi/nvidia.yaml dosyasına bakarak GPU'nun container'a nasıl sunulacağını öğrenir. Bu dosya yoksa veya güncel değilse, yukarıdaki hatayı alırsınız.

Çözüm Adımları

1. NVIDIA Container Toolkit Kurulumu

Öncelikle nvidia-container-toolkit paketinin kurulu olup olmadığını kontrol edin:

rpm -q nvidia-container-toolkit

Kurulu değilse, NVIDIA'nın resmi repo'sunu ekleyip kurun:

curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | \
  sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo

sudo dnf install -y nvidia-container-toolkit

2. CDI Spec Dosyasını Oluşturun

Bu adım sorunun asıl çözümüdür. Aşağıdaki komut, sisteminizde bulunan NVIDIA GPU'ları tarayarak CDI spec dosyasını oluşturur:

sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

3. Doğrulama

Spec'in başarıyla oluşturulduğunu doğrulayın:

nvidia-ctk cdi list

Çıktıda şuna benzer satırlar görmeniz gerekir:

INFO[0000] Found 2 CDI devices
nvidia.com/gpu=0
nvidia.com/gpu=all

4. Container'ı Tekrar Çalıştırın

Artık Podman GPU'yu CDI üzerinden çözebilir durumda. Uygulamanızı tekrar başlatın:

rhel-cla start

Alternatif: Spesifik GPU Belirtme

Eğer gpu=all hâlâ çözülemiyorsa, uygulamanızın yapılandırma dosyasında cihazı spesifik olarak belirtmeyi deneyin:

# nvidia.com/gpu=all yerine:
nvidia.com/gpu=0

Örneğin RHEL CLA için bu ayar ~/.config/rhel-cla/.env dosyasındadır.

Önemli Not

Kernel veya NVIDIA sürücü güncellemesi sonrasında CDI spec dosyası geçersiz hale gelebilir. Sürücü güncellemesi yaptıktan sonra sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml komutunu tekrar çalıştırmayı unutmayın.

Ortam Bilgisi

Bu yazıdaki çözüm aşağıdaki ortamda test edilmiştir:

• Fedora / RHEL tabanlı dağıtımlar
• NVIDIA GeForce RTX 4060 Laptop GPU
• NVIDIA Driver 595.80, CUDA 13.2
• Podman (rootless ve rootful)

Umarım işinize yarar. Sorularınız varsa yorumlarda belirtebilirsiniz.

Ne işe yarar; sar -n DEV

sar -n DEV|awk 'BEGIN{mak=0} !/txpck|x86|CPU|^[ \t]*$/{if (mak<$5) {mak=$5;li=$0}} END{print mak,li;}'