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.
Kurumsal Linux ortamlarında yıllardır aynı cümleyi duyuyorum:
“Ü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:
Red Hat Enterprise Linux 9:
5.14.0-70.22.1.el9_0.x86_64or 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.6asgari sürüm
tipik sistem
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:
“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-2Yani 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:
- Hedef RHEL ara sürümüne, RU’nun sürücü listesine bakarak karar verin.
- Sistemi o sürüme kurun ve çekirdeği sabitleyin.
- Üreticinin ön hazırlık paketini (
oracle-database-preinstall-*benzeri) kurun. OPatch’i güncelleyin — 19.29 için asgari12.2.0.1.47.- Kurulumu
-applyRUile başlatın. - Kurulum sonrası
acfsdriverstate supportedveafddriverstate supportedile 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 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 |
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:
- 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. - 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.
- Sıra ne olmalı? Neredeyse her zaman: önce uygulamayı hedef çekirdeği destekleyen sürüme çıkar, sonra işletim sistemini güncelle.
- Geri dönüş planı ne? Eski çekirdek GRUB’da duruyor mu,
grubby --default-kernelbeklediğ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.
