Red Hat: Red Hat Nedir ve Linux ile İlişkisi Ne?

Yeni bir seriye başlıyoruz. Bu blogda şimdiye kadar iki yol yürüdük. Algoritmalar serisinde kalem ve kâğıtla, bir bilgisayara iş yaptırmanın mantığını çözdün. Java serisinde o mantığı gerçek bir dile dökmeye başladık; hatta JVM’in içine girip motorun nasıl döndüğüne baktık. Şimdi bir kat daha aşağı iniyoruz: yazdığın programların üzerinde koştuğu zemine, yani işletim sistemine. Bu zeminin dünyadaki sunucularda en yaygın hâli Linux, Linux’un iş dünyasındaki en tanınmış temsilcisi de Red Hat.

Bu ilk bölümde hiçbir şey kurmayacağız, tek satır komut yazmayacağız. Önce oturup şu soruların cevabını verelim: Linux tam olarak ne, “çekirdek” dedikleri şey ne yapıyor? “Dağıtım” ne demek, neden yüzlerce tane var? Linux’ta bir program nasıl kuruluyor, şu “paket yöneticisi” denen şey ne? “Red Hat” bir şirket mi, bir işletim sistemi mi, yoksa ikisi birden mi? Kırmızı şapka nereden çıktı? Fedora, CentOS, RHEL, Rocky, Alma… bu isim kalabalığı ne? Ve en meraklı soru: herkesin bedava indirebildiği bir yazılımdan bir şirket nasıl olup da milyarlarca dolar kazanıyor? Hani Algoritmalar serisinin ilk yazısında çay demlemeyi adım adım yazmıştık ya; bu sefer gerçekten demle, biraz oturacağız.

Önce zemini görelim: işletim sistemi ne iş yapar?

Java yazısında bir bilgisayarın aslında ne kadar “aptal” olduğunu konuşmuştuk, hatırlıyor musun? Tek başına yalnızca toplama, karşılaştırma, bir yerden bir yere taşıma gibi minik işler yapabiliyordu; onu akıllı gösteren şey bu işleri saniyede milyarlarca kez yapmasıydı. Şimdi o resme bir parça daha ekleyelim.

Bir bilgisayarda aynı anda onlarca program çalışır: tarayıcı, müzik, bir metin editörü, arka planda güncelleme kontrolü… Hepsi aynı işlemciyi, aynı belleği, aynı diski, aynı ağ bağlantısını istiyor. Kim hangi sırayla işlemciyi kullanacak? Bir programın belleğine başka bir program karışırsa ne olacak? Klavyeye basıldığında o tuş hangi pencereye gidecek? Diskteki bir dosyayı iki program aynı anda yazmaya kalkarsa?

Bu soruların hepsini cevaplayan, donanımla programlar arasında duran o büyük yönetici programa işletim sistemi diyoruz. Bir apartmanın yöneticisi gibi düşün: daireler (programlar) suyu, elektriği, asansörü (donanımı) doğrudan kendi aralarında paylaşmaz; yönetici düzeni kurar. Kim ne zaman neyi kullanır, kim kimin dairesine giremez, hepsi bellidir. Windows bir işletim sistemidir, macOS bir işletim sistemidir, telefonundaki Android ve iOS da öyle. Linux da bu ailenin bir üyesi… ama birazdan göreceğin gibi, “Linux” kelimesi aslında bundan biraz daha dar bir şeyi anlatıyor.

flowchart TD
    U["Sen (kullanıcı)"] --> A["Uygulamalar<br/>tarayıcı, editör, Java programın"]
    A --> S["Kabuk ve sistem araçları<br/>komut satırı, kütüphaneler"]
    S --> K["Çekirdek (kernel)<br/>işlemci, bellek, disk, ağ paylaşımı"]
    K --> H["Donanım<br/>CPU, RAM, disk, ağ kartı"]

Şemayı yukarıdan aşağıya oku. Sen en üstte, uygulamalarla konuşuyorsun. Uygulamalar doğrudan donanıma dokunmaz; araya kabuk, kütüphaneler ve en önemlisi çekirdek girer. Donanımla gerçekten konuşan tek katman en alttaki çekirdektir.

”Linux” dediğimiz şey tam olarak ne?

Bu sorunun kısa cevabı çoğu kişiyi şaşırtıyor: Linux, tek başına bir işletim sistemi değil, işletim sisteminin çekirdeğidir. Yani yukarıdaki şemanın yalnızca bir katmanı. Kabuk yok, kurulum programı yok, tarayıcı yok, hatta dosyaları listeleyecek bir komut bile yok. Çekirdek, donanımı yöneten ve programlara “işlemciyi kullan, belleği al, diske yaz” gibi hizmetleri sunan motor; o kadar.

Bir araba düşün. Motor arabanın kalbidir, onsuz araba yürümez. Ama tek başına bir motorla bir yere gidemezsin: şasi, tekerlekler, direksiyon, koltuklar, gösterge paneli gerekir. Linux, motordur. Etrafına konulan her şeyle birlikte ortaya çıkan arabaya ise dağıtım (distribution) denir; ona birazdan ayrı bir bölüm ayıracağız. Şimdilik şunu yerine oturt: Red Hat Enterprise Linux bir dağıtımdır, Ubuntu bir dağıtımdır, Fedora bir dağıtımdır. Hepsinin içinde aynı motor, Linux çekirdeği çalışır.

Çekirdek tam olarak ne yapıyor?

“Donanımı yönetiyor” dedik ama bunu biraz açalım, çünkü serinin ilerleyen bölümlerinde yapacağımız hemen her şey bu beş işten birine dokunacak.

flowchart LR
    K["Linux çekirdeği"] --> P["Süreç yönetimi<br/>hangi program ne zaman, ne kadar işlemci kullanır"]
    K --> M["Bellek yönetimi<br/>her programa kendi odası; kimse kimseninkine giremez"]
    K --> D["Aygıt sürücüleri<br/>disk, ağ kartı, klavye, ekran kartı ile konuşan çevirmenler"]
    K --> F["Dosya sistemleri<br/>diskteki ham baytları dosya ve klasör olarak sunar"]
    K --> N["Ağ yığını<br/>paketleri alır, gönderir, kime ait olduğunu bilir"]

• Süreç yönetimi. Çalışan her programa “süreç” (process) denir. İşlemci aynı anda tek bir şey yapabilir (çekirdek başına); çekirdek, süreçleri milisaniyelik dilimlerle sırayla işlemciye sokup çıkarır. O kadar hızlı yapar ki sen hepsinin aynı anda çalıştığını sanırsın. Bu işi yapan parçaya zamanlayıcı (scheduler) denir. 9. bölümde süreçleri elimizle listeleyip durduracağız.
• Bellek yönetimi. Her programa “sadece senin” diye bir bellek alanı verir ve bir programın başkasının alanına elini uzatmasını engeller. Java yazısındaki o RAM’deki “kutular” var ya; onların gerçekten hangi fiziksel yongada durduğunu program bilmez, çekirdek bilir.
• Aygıt sürücüleri. Binlerce farklı disk, ağ kartı, klavye, ekran kartı var ve her biri kendi dilini konuşur. Sürücü, o dili bilen çevirmendir. Linux’un dünyanın hemen her donanımında çalışabilmesinin sırrı, çekirdeğin içinde gelen devasa sürücü koleksiyonudur.
• Dosya sistemleri. Bir disk aslında numaralı bloklardan oluşan bir bayt yığınıdır. “Belgeler klasörünün içindeki rapor.txt” gibi bir şeyi diskteki bloklara çeviren katman çekirdektir. 4. ve 11. bölümlerin konusu.
• Ağ yığını. İnternete giden ve gelen her paketi çekirdek işler: adresi kime ait, hangi programa teslim edilecek, hepsini o bilir. 10. bölümde göreceğiz.

Peki bir program çekirdekten bir şey isteyeceği zaman ne oluyor? Bir lokanta düşün. Müşteri (program) mutfağa (donanıma) giremez; garsona (çekirdeğe) söyler, garson mutfağa gider, yemeği getirir. Programın çekirdeğe “şu dosyayı oku” ya da “şu adrese paket gönder” demesinin resmî adı sistem çağrısıdır (system call).

flowchart TD
    A["Program: &quot;rapor.txt dosyasını oku&quot;"] --> L["C kütüphanesi (glibc)<br/>isteği çekirdeğin anlayacağı biçime çevirir"]
    L --> SC["Sistem çağrısı: read()<br/>kullanıcı alanından çekirdek alanına geçiş"]
    SC --> PZ{"Bu programın bu dosyayı<br/>okumaya izni var mı?"}
    PZ -->|"Hayır"| ERR["Hata döner: izin yok"]
    PZ -->|"Evet"| FS["Dosya sistemi: dosya diskin<br/>hangi bloklarında?"]
    FS --> DRV["Disk sürücüsü: blokları oku"]
    DRV --> HW["Donanım: disk"]
    HW --> BACK["Veri programa geri döner"]

Şemadaki “kullanıcı alanı” ve “çekirdek alanı” ayrımı önemli. Çekirdek, mutfak gibi kapalı bir bölgede çalışır; programlar salonda oturur. Salonda ne olursa olsun (bir program çökse bile) mutfak ayakta kalır. Bu ayrım, Linux sunucularının aylarca kapatılmadan çalışabilmesinin nedenlerinden biridir. Bir de o “izin var mı?” sorusuna dikkat: çekirdek her isteği kimin yaptığına bakarak cevaplar. 6. bölümde kullanıcıları ve izinleri öğrendiğinde, bu sorunun ne kadar merkezî olduğunu göreceksin.

Motorun hikâyesi: 1991, Helsinki

Linux’un doğuşu, yazılım tarihinin en sevimli hikâyelerinden biri. 1991 yılında Helsinki Üniversitesi’nde okuyan 21 yaşındaki Linus Torvalds, kendi bilgisayarında kullanmak için bir işletim sistemi çekirdeği yazmaya başlıyor. Ağustos 1991’de bir internet tartışma grubuna şu mesajı gönderiyor (biraz sadeleştirerek çeviriyorum):

“Merhaba, Minix kullanan herkese. (Ücretsiz) bir işletim sistemi yapıyorum; sadece bir hobi, GNU gibi büyük ve profesyonel olmayacak…”

“Sadece bir hobi.” O hobi bugün dünyadaki sunucuların büyük çoğunluğunu, en hızlı 500 süper bilgisayarın tamamını, cebindeki Android telefonu, evindeki modemi, akıllı televizyonu, hatta Mars’ta uçan minik helikopteri çalıştırıyor. Torvalds çekirdeğin adını önce “Freax” koymayı düşünmüş; dosyaları koyduğu sunucunun yöneticisi klasöre “Linux” adını vermiş ve isim öyle kalmış.

Linux’un kısa zaman çizelgesi

Red Hat’in kendi zaman çizelgesini birazdan göreceksin; önce motorun kendi yolculuğu. Ezberlemek için değil, “bu iş ne zamandır dönüyor” hissini almak için.

Dağıtım (distro): motorun etrafındaki araba

Şimdi araba benzetmesine geri dönelim ve arabanın içine bakalım. Bir Linux dağıtımı, çekirdeğin etrafına neler koyar? Bu listeyi bilmek, serinin geri kalanının haritasını cebine koymak demek; çünkü her bölüm bu parçalardan birini açacak.

flowchart TD
    subgraph D["Bir Linux dağıtımının katmanları (aşağıdan yukarıya)"]
        direction TB
        DE["Masaüstü ortamı (isteğe bağlı): GNOME, KDE<br/>sunucularda çoğu zaman yoktur"]
        APP["Uygulamalar ve sunucu yazılımları<br/>web sunucusu, veritabanı, Java..."]
        PM["Paket yöneticisi + depolar<br/>rpm / dnf ve internetteki paket rafları"]
        SH["Kabuk ve temel araçlar<br/>bash, coreutils (ls, cp, grep...)"]
        INIT["Başlatma sistemi: systemd<br/>açılışta servisleri sırayla ayağa kaldırır"]
        LIBC["C kütüphanesi: glibc<br/>her programın ortak alet çantası"]
        K["Linux çekirdeği"]
        DE ~~~ APP ~~~ PM ~~~ SH ~~~ INIT ~~~ LIBC ~~~ K
    end

Tek tek, aşağıdan yukarıya:

• Çekirdek. Motor. Az önce tanıdın.
• C kütüphanesi (glibc). Hemen her programın “dosya aç”, “bellek iste”, “ekrana yaz” gibi ortak işleri yaptığı hazır fonksiyon koleksiyonu. Şemadaki sistem çağrısı akışında garsona giden yol buradan geçiyordu. Fonksiyonlar yazısında “bir kere yaz, herkes kullansın” demiştik ya; glibc bunun işletim sistemi boyutundaki hâli.
• Başlatma sistemi (systemd). Bilgisayar açıldığında çekirdekten sonra çalışan ilk program. Sabah ilk kalkan ve evdeki herkesi sırayla uyandıran kişi gibi: ağı başlatır, disk bölümlerini bağlar, web sunucusunu ayağa kaldırır, giriş ekranını açar. 8. bölümün konusu.
• Kabuk ve temel araçlar. Kabuk (bash), yazdığın komutları alıp çalıştıran programdır; coreutils ise ls, cp, mkdir gibi yüzlerce küçük aracın toplu adı. 3. bölümde başlıyoruz.
• Paket yöneticisi ve depolar. Program kurup kaldırma altyapısı; birazdan uzun uzun konuşacağız.
• Uygulamalar ve sunucu yazılımları. Dağıtımın depolarından kurabildiğin her şey: web sunucusu, veritabanı, editörler, Java, Python…
• Masaüstü ortamı. Pencereler, menüler, simgeler. RHEL’de varsayılan GNOME’dur. Ama dikkat: bir sunucuda çoğu zaman masaüstü yoktur; her şey terminalden yönetilir. Bu yüzden terminali erken öğreneceğiz.

Bunların üstüne dağıtım şunları da ekler: bir kurulum programı (RHEL’de adı Anaconda; 2. bölümde kullanacağız), varsayılan yapılandırma kararları (hangi güvenlik katmanı açık, hangi dosya sistemi kullanılır), belgeler ve bir güncelleme akışı. Yani dağıtım, parçaların toplamından fazlasıdır: parçaların birbirine uyduğunu test eden, birlikte çalıştıklarına kefil olan, güncellemelerini yıllarca sürdüren bir “üretici”.

Dağıtımlar neden birbirinden farklı?

Aynı motoru kullanan yüzlerce dağıtım varsa, fark nerede? Cevap: fabrikanın verdiği kararlarda. Şu altı başlık, iki dağıtım arasındaki farkın neredeyse tamamını açıklar.

Bir dağıtımı öğrenince diğerleri neden tanıdık geliyor, şimdi görüyorsun: tablodaki kararların hiçbiri çekirdeği, kabuğu, dosya sistemi mantığını, kullanıcı ve izin sistemini değiştirmiyor. Değişen, paketleme ve birkaç varsayılan. Kabaca yüzde doksan ortak, yüzde on “aile şivesi”.

Aileler ve çatallama

Dağıtımların çoğu birkaç büyük aileye ayrılır. Bunun nedeni açık kaynağın en güçlü hakkı: çatallama (fork). Kod herkese açık olduğu için, beğenmediğin bir dağıtımı alıp kendi yoluna gidebilirsin. Ubuntu, Debian’ın kodunu alıp “daha kolay kurulan, daha sık sürüm çıkaran” bir dağıtım yapmak isteyen Canonical’ın 2004’te açtığı bir çataldır. Linux Mint, Ubuntu’nun çatalı. CentOS, Rocky ve Alma da RHEL’in.

flowchart LR
    L["Linux çekirdeği"] --> RH["Red Hat ailesi<br/>rpm / dnf"]
    L --> DEB["Debian ailesi<br/>deb / apt"]
    L --> SU["SUSE ailesi<br/>rpm / zypper"]
    L --> AR["Arch ailesi<br/>pacman"]
    RH --> F["Fedora"] --> RHEL["RHEL"] --> RA["Rocky / Alma"]
    DEB --> UB["Ubuntu"] --> MI["Linux Mint"]
    SU --> OS["openSUSE"]
    AR --> MA["Manjaro"]

Aileleri birbirinden ayıran en görünür şey, tablonun ilk satırı: paket biçimi. Red Hat ailesi rpm paketleri ve dnf aracını kullanır; Debian ailesi deb paketleri ve apt aracını. Bir Ubuntu’da apt install yazdığın yerde RHEL’de dnf install yazarsın, gerisi büyük ölçüde aynıdır.

Sürüm modelleri: sabit mi, yuvarlanan mı?

Tablodaki ikinci satır, dağıtım seçerken en çok kafa karıştıran konu. İki yaklaşım var:

flowchart LR
    subgraph S["Sabit sürüm: RHEL, Debian, Ubuntu LTS"]
        direction LR
        S1["RHEL 9.0"] --> S2["9.1"] --> S3["9.2"] --> S4["..."] --> S5["RHEL 10.0<br/>(büyük sıçrama)"]
    end
    subgraph R["Yuvarlanan sürüm: Arch, openSUSE Tumbleweed"]
        direction LR
        R1["bugün"] --> R2["yarın"] --> R3["haftaya"] --> R4["...<br/>sürüm numarası yok,<br/>her gün küçük güncellemeler"]
    end

Sabit sürüm (point release) modelinde dağıtım belirli aralıklarla numaralı sürümler çıkarır; bir sürüm çıktıktan sonra içindeki programların büyük sürümleri değişmez, yalnızca hata ve güvenlik düzeltmeleri gelir. Bir şirketin sunucusu için istediğin şey budur: bugün çalışan şey, yarınki güncellemeden sonra da aynı şekilde çalışsın. Yuvarlanan sürüm (rolling release) modelinde ise sürüm numarası yoktur; her gün en yeni programlar akar. Meraklı bir masaüstü kullanıcısı için keyifli, bir banka sunucusu için kâbus.

RHEL sabit sürüm modelinin en katı örneklerinden biridir ve bunu bir tempo hâline getirmiştir: yaklaşık üç yılda bir büyük sürüm (RHEL 8, 9, 10), altı ayda bir küçük sürüm (9.4, 9.5, 9.6…) ve her büyük sürüm için on yıl destek. Sürüm numarasını şöyle okursun: 10.2 → büyük sürüm 10 (hangi “nesil”), küçük sürüm 2 (o neslin kaçıncı güncelleme paketi).

RHEL ile Ubuntu’nun farkı ne?

“Linux” deyince çoğu kişinin aklına ilk gelen isim Ubuntu; iş dünyasında en çok karşılaşacağın isim ise RHEL. İkisini yan yana koymak, yukarıdaki tablonun en somut örneği ve “hangisini öğrenmeliyim?” sorusunun cevabı.

Önce ortak nokta: ikisi de aynı motoru, Linux çekirdeğini kullanır. İkisinde de systemd, bash, GNOME, aynı dizin ağacı, aynı kullanıcı ve izin mantığı, aynı ls, cp, grep vardır. Bir Ubuntu makinesinde öğrendiğin şeylerin yüzde doksanı RHEL’de aynen geçer, tersi de öyle. Fark, iki fabrikanın verdiği kararlarda:

Tabloyu okuduktan sonra iki şeyi ayırt et. Birincisi, felsefe farkı: Ubuntu “herkes için, hemen, ücretsiz” diyor; RHEL “on yıl aynı kalsın, biri kefil olsun, gerekirse arayabileyim” diyor. İkisi de haklı; farklı ihtiyaçlara cevap veriyorlar. Ubuntu’nun adı bile bunu anlatır: Zulu ve Xhosa dillerinde “insanlık, birlikte var olma” demek. İkincisi, komut farkı: günlük işte hissedeceğin farklar birkaç araçtan ibaret. apt yerine dnf, ufw yerine firewalld, AppArmor yerine SELinux. Bunları serinin ilgili bölümlerinde öğrendiğinde, bir Ubuntu makinesine oturduğunda yalnızca “karşılığı neydi?” diye düşünmen yeterli olacak.

Öteki kurumsal Linux’lar: SUSE, Oracle, Amazon

RHEL ile Ubuntu bu pazarın en görünür iki yüzü ama tek oyuncular değil. Bir sunucu odasında karşına şunlar da çıkabilir:

Ortak nokta: hepsinde aynı çekirdek, aynı kabuk, aynı komut kültürü. Fark yine paketleme, destek modeli ve arkasındaki kurum.

Bir de donanım tarafı var. RHEL yalnızca bildiğin PC işlemcilerinde (x86_64) değil; telefonlardaki ve Raspberry Pi’daki türden ARM işlemcilerde, IBM’in Power sunucularında ve bankaların hâlâ kullandığı IBM Z anabilgisayarlarında (mainframe) da çalışır. Java yazısındaki “bir kez yaz, her yerde çalıştır” sözü işletim sistemi katında da geçerli: aynı RHEL, aynı komutlar, bambaşka demir.

Üst akım ve alt akım: nehir benzetmesi

Son bir kavram, sonra Red Hat’in hikâyesine geçiyoruz. Bir dağıtım, içindeki binlerce programın hiçbirini kendisi yazmaz. Çekirdeği Torvalds’ın ekibi, bash’i GNU projesi, GNOME’u GNOME topluluğu, web sunucusunu Apache vakfı geliştirir. Bu projelere üst akım (upstream) denir; dağıtım ise alt akımdır (downstream): nehrin yukarısından gelen suyu toplayıp şişeleyen tesis.

Bu nehir tek yönlü değildir. Dağıtım bir hata bulup düzelttiğinde, düzeltmeyi yukarıya, üst akıma gönderir ki herkes yararlansın. Red Hat’in bu konuda bir ilkesi var: “önce üst akım” (upstream first). Bir özelliği RHEL’e koymadan önce onu asıl projeye kabul ettirir. Bu yüzden Red Hat, Linux çekirdeğinin ve pek çok temel projenin en büyük katkıcılarından biridir. Aile ağacına geldiğimizde bu nehri Fedora’dan RHEL’e kadar izleyeceğiz.

Paketler ve paket yöneticisi: Linux’ta program nasıl kurulur?

Dağıtımın katmanlarında “paket yöneticisi”ni “birazdan” diye geçmiştik. Şimdi sırası, çünkü bu kavram Linux’a yeni gelenlerin en çok yabancılık çektiği yer. Windows’ta program kurmak nasıl olur? Bir web sitesine gidersin, setup.exe indirirsin, “İleri, İleri, Son” dersin. Her program kendi kurulumunu kendi getirir; ne yaptığını pek bilmezsin; güncellemeleri her program ayrı ayrı kendi kontrol eder.

Linux dünyası bunu tam tersinden çözer: telefonundaki uygulama mağazası gibi. Dağıtım, binlerce programı kendi raflarında hazır tutar. Sen “şunu istiyorum” dersin; sistem programı raftan alır, ihtiyaç duyduğu diğer parçaları da yanına ekler, kurar, kaydını tutar ve hepsini tek komutla güncel tutar. Bu düzenin üç temel taşı var: paket, bağımlılık ve depo.

Paket nedir?

Bir paket, tek bir programın (ya da kütüphanenin) kurulmak için gereken her şeyini içeren kutudur. Red Hat ailesinde bu kutuların uzantısı .rpm’dir. IKEA’dan aldığın bir kutu gibi düşün: içinde parçalar var, üstünde ne olduğu yazıyor, içinde montaj talimatı var ve “bunun için şu vidalar da gerekir” diyen bir liste.

flowchart TD
    subgraph P["httpd-2.4.62-1.el10.x86_64.rpm  (bir paketin içi)"]
        direction TB
        F["Dosyalar<br/>çalıştırılabilir program, kütüphaneler, ayar dosyaları, belgeler, simgeler"]
        MD["Üstbilgi (metadata)<br/>ad, sürüm, açıklama, lisans, boyut, kim paketledi"]
        DEP["Bağımlılık listesi<br/>&quot;çalışmam için şu paketler de kurulu olmalı&quot;"]
        SCR["Betikler<br/>kurulumdan önce / sonra yapılacak küçük işler (kullanıcı oluştur, servisi kaydet)"]
        SIG["Dijital imza<br/>paketin gerçekten Red Hat'ten geldiğinin kanıtı"]
        F ~~~ MD ~~~ DEP ~~~ SCR ~~~ SIG
    end

Şemadaki dosya adını da okumayı öğren, çünkü sürekli göreceksin: httpd-2.4.62-1.el10.x86_64.rpm. Parçaları: httpd (paketin adı, bu bir web sunucusu), 2.4.62 (programın kendi sürümü), 1 (paketleyicinin kaçıncı denemesi), el10 (Enterprise Linux 10 için paketlenmiş), x86_64 (hangi işlemci mimarisi için). Tek bir dosya adından bile o kadar şey öğreniyorsun.

Bağımlılık: kimse tek başına değil

Modern programlar tek başına yaşamaz. Bir web sunucusu, şifreleme için ayrı bir kütüphane kullanır; o kütüphane sıkıştırma için başka bir kütüphaneye yaslanır; o da C kütüphanesine. Her program bu kütüphanelerin kendi kopyasını taşısaydı diskte aynı şeyden yüzlerce kopya olurdu ve bir güvenlik açığı çıktığında yüzlerce yeri düzeltmek gerekirdi. Onun yerine kütüphane bir kez kurulur, herkes onu paylaşır. Bir programın “çalışmam için şunlar kurulu olmalı” listesine bağımlılık (dependency) denir.

Güzel fikir, ama bir tuzağı var ve o tuzak Linux tarihinin en meşhur baş ağrısını doğurdu.

Depo: raflar ve katalog

Paketler nerede duruyor? İnternet üzerindeki depolarda (repository). Bir depo iki şeyden oluşur: paket dosyalarının kendisi (raflar) ve hangi paketin hangi sürümünün orada olduğunu, neye bağımlı olduğunu anlatan bir katalog (metadata). Paket yöneticisi önce kataloğu indirir, sonra ne alacağına oradan bakar. Aynı deponun dünyanın farklı yerlerinde kopyaları vardır; bunlara ayna (mirror) denir, sana en yakınından indirirsin.

RHEL’de ana depolar aboneliğine bağlıdır ve ikiye ayrılır: BaseOS (işletim sisteminin çekirdek parçaları) ve AppStream (uygulamalar, diller, sunucu yazılımları; bunların bazıları birden fazla sürümle sunulur). Bunların dışında topluluğun RHEL için sürdürdüğü EPEL gibi ek depolar da vardır; ana depoda olmayan bir programı çoğu zaman oradan bulursun.

Bir de güven meselesi var. İnternetten indirdiğin bir paketin gerçekten Red Hat’ten geldiğini, yolda birinin içine bir şey katmadığını nereden bileceksin? Her paket, Red Hat’in gizli anahtarıyla imzalanır; senin sistemin ise Red Hat’in açık anahtarını tanır ve her paketi kurmadan önce imzayı doğrular. Mağazadaki hologram etiketi gibi: imza tutmuyorsa paket kurulmaz. 7. bölümde bunu kendi gözünle göreceksin.

İki katman: rpm ve dnf

Red Hat ailesinde paket işi iki araca bölünmüştür ve ikisini karıştırmak çok yaygın.

• rpm alt katmandır. Tek bir .rpm dosyasını kurar, kaldırır, “bu dosya hangi paketten geldi?” gibi sorulara cevap verir ve kurulu her paketin kaydını tuttuğu bir veritabanı yönetir. Ama depolara bakmaz, bağımlılık indirmez; sen ona ne verirsen onu kurar. Depodaki görevli gibi: kutuyu rafa koyar, defterine yazar.
• dnf üst katmandır. Depoları tarar, istediğin paketi bulur, bağımlılık zincirini çözer, hepsini indirir, imzaları doğrular ve kurulumu rpm’e yaptırır. Satın alma müdürü gibi: “şunu istiyorum” dersin, gerisini o halleder.

Günlük işte dnf kullanırsın; rpm’i çoğunlukla sorgulamak için elinde tutarsın. dnf install httpd dediğinde perde arkasında olanları takip edelim:

flowchart TD
    S(["dnf install httpd"]) --> M["Depo kataloglarını oku<br/>(gerekirse güncelle)"]
    M --> F{"httpd depoda var mı?"}
    F -->|"Hayır"| E1["Hata: paket bulunamadı"]
    F -->|"Evet"| D["httpd'nin bağımlılık listesine bak"]
    D --> Q{"Kurulu olmayan bir<br/>bağımlılık kaldı mı?"}
    Q -->|"Evet"| A["Onu da listeye ekle;<br/>onun bağımlılıklarına bak"]
    A --> Q
    Q -->|"Hayır"| L["Kurulacakların listesini göster,<br/>onay iste"]
    L --> DL["Paketleri en yakın aynadan indir"]
    DL --> V{"İmzalar geçerli mi?"}
    V -->|"Hayır"| E2["Dur: güvenilmeyen paket"]
    V -->|"Evet"| I["rpm ile kur,<br/>veritabanına kaydet, betikleri çalıştır"]
    I --> OK(["httpd hazır"])

Şemadaki döngüye dikkat: “kurulu olmayan bağımlılık kaldı mı?” sorusu, cevap “hayır” olana kadar tekrar sorulur. Döngüler yazısında “tekrar sorulan karar” diye anlattığımız şey tam olarak bu. Bir web sunucusu için bu döngü birkaç tur döner; büyük bir masaüstü ortamı için yüzlerce.

Güncelleme ve “RHEL’deki sürümler neden eski görünüyor?”

dnf update dediğinde dnf, kurulu paketlerin sürümlerini depo kataloğuyla karşılaştırır ve yenisi olanları indirip kurar. Buraya kadar basit. Ama RHEL’in sabit sürüm modeliyle birleşince yeni başlayanları şaşırtan bir durum ortaya çıkar: “RHEL 9’da Python 3.9 var, oysa dünyada Python 3.13 çıktı; bu sistem güncel değil mi?”

Cevap, geri taşıma (backport) kavramında. RHEL bir sürüm çıkardığında içindeki programların büyük sürümlerini on yıl boyunca dondurur; çünkü kurumsal müşteri “bugün çalışan yarın da aynı çalışsın” ister. Ama güvenlik açıkları ve önemli hatalar bekleyemez. Red Hat’in mühendisleri bu düzeltmeleri programın yeni sürümünden alıp eski sürüme geri taşır: sürüm numarası 3.9 kalır, ama içindeki kod yamalıdır. Yani RHEL’de eski görünen bir sürüm numarası, “güncellenmemiş” değil, “kasıtlı olarak sabit tutulup ayrıca yamalanmış” demektir. Üst akımda yeni bir özelliğe ihtiyacın varsa, AppStream depoları bazı diller ve araçlar için birden fazla sürümü yan yana sunar.

Öteki kutular: deb, Flatpak ve konteynerler

Paket biçimi aileye göre değişir ama fikir aynıdır: Debian ailesinde .deb paketleri ve apt, SUSE’de rpm ve zypper, Arch’ta pacman. Son yıllarda bir de “her dağıtımda çalışsın” diye tasarlanmış evrensel biçimler çıktı: Flatpak (masaüstü uygulamaları için, Fedora ve Red Hat’in desteklediği), Snap (Ubuntu’nun) ve AppImage (tek dosya, kurulumsuz). Sunucu tarafında ise paketlemenin en yeni hâli konteyner imajıdır: program, bağımlılıklarıyla birlikte tek bir kutuya konur ve her yerde aynı çalışır. Serinin 14. bölümünde Podman ile bunu yapacağız; o zaman “bu da bir paket yöneticisi aslında” diyeceksin.

Kırmızı şapkanın hikâyesi

Şimdi serinin adını taşıyan şirkete gelelim. Red Hat’in hikâyesi iki kişiyle başlıyor ve ikisi de başlangıçta birbirini tanımıyor.

Marc Ewing ve dedesinin şapkası

1990’ların başında Marc Ewing, Pittsburgh’daki Carnegie Mellon Üniversitesi’nde okuyan bir bilgisayar öğrencisi. Kampüste onu herkes tanıyor, çünkü sürekli aynı şapkayı takıyor: dedesinden kalma, kırmızı bir Cornell Üniversitesi lakros şapkası. Bilgisayar laboratuvarında sıkışan öğrencilere “kırmızı şapkalı çocuğu bul, o çözer” deniyor. Ewing kendi yazılım projelerine de bu şapkanın adını veriyor.

Mezun olduktan sonra Ewing, Linux için o zamana kadar yapılanlardan daha kolay kurulan, daha derli toplu bir dağıtım hazırlamaya koyuluyor. 1994’ün sonbaharında, Cadılar Bayramı’na denk gelen bir günde ilk sürümü yayımlıyor; adı Red Hat Linux. O sürüm bugün hâlâ “Halloween sürümü” diye anılıyor. Ewing’in dağıtımını farklı kılan şeylerden biri, az önce tanıdığın RPM paket sistemiydi; bunu Erik Troan’la birlikte yazdı ve rpm otuz yıl sonra hâlâ bu ailenin temel taşı.

Bob Young ve kaputu kaynaklı araba

Aynı yıllarda Kanadalı bir girişimci olan Bob Young, katalogla Unix ve Linux yazılımları ve kitapları satan ACC Corporation adında küçük bir şirket işletiyor. Young, müşterilerinin en çok Ewing’in Red Hat Linux’unu istediğini fark ediyor. 1995’te Ewing’in işini satın alıp kendi şirketiyle birleştiriyor ve Red Hat Software doğuyor. Ewing teknik tarafı, Young işi yönetiyor. Şirket Kuzey Carolina’ya, bugün hâlâ merkezinin bulunduğu Raleigh bölgesine yerleşiyor.

Young’ın o dönemde herkese anlattığı bir benzetme var ve bence hâlâ açık kaynağı en iyi anlatan cümlelerden biri:

“Kaputu kaynakla kapatılmış bir araba satın alır mıydınız?”

Kapalı kaynaklı yazılım, kaputu kaynaklı arabadır: içine bakamazsın, tamirini yalnızca üretici yapabilir, sorun çıkınca beklersin. Açık kaynaklı yazılımda kaput açıktır; istersen kendin bakarsın, istersen başka bir tamirciye götürürsün. Peki o zaman Red Hat neyi satıyor? Bu sorunun cevabı birazdan, ayrı bir başlıkta.

Yıllar içinde

Buradan sonrasını duraklar hâlinde görelim, sonra önemli olanlarda tek tek duracağız.

flowchart TD
    T1["1993-1994<br/>Marc Ewing dağıtımı hazırlar;<br/>Cadılar Bayramı sürümü çıkar"] --> T2["1995<br/>Bob Young ile birleşme,<br/>Red Hat Software kurulur"]
    T2 --> T3["1999<br/>Halka arz; hisseler ilk günde fırlar"]
    T3 --> T4["2002-2003<br/>İlk Red Hat Enterprise Linux;<br/>Red Hat Linux biter, Fedora doğar"]
    T4 --> T5["2004<br/>Topluluk CentOS projesini başlatır"]
    T5 --> T6["2006<br/>JBoss satın alınır: Java dünyasına giriş"]
    T6 --> T7["2012<br/>Yılda 1 milyar dolar gelire ulaşan<br/>ilk açık kaynak şirketi"]
    T7 --> T8["2014<br/>CentOS Red Hat çatısına girer"]
    T8 --> T9["2015<br/>Ansible satın alınır"]
    T9 --> T10["2019<br/>IBM 34 milyar dolara satın alır;<br/>yeni logo: yalnızca şapka"]
    T10 --> T11["2020-2021<br/>CentOS Stream öne çıkar;<br/>Rocky Linux ve AlmaLinux doğar"]
    T11 --> T12["2023<br/>Kaynak kod erişimi tartışması"]
    T12 --> T13["2025<br/>RHEL 10 yayımlanır"]

1999: Wall Street’te bir gün. Ağustos 1999’da Red Hat halka açıldı ve hisse fiyatı ilk günde birkaç katına çıktı; o güne kadarki en büyük ilk gün yükselişlerinden biriydi. “Bedava dağıtılan bir yazılımdan şirket mi olur?” diyenlere ilk cevap buydu.

2002-2003: Büyük karar. O zamana kadar Red Hat Linux hem meraklılara hem şirketlere aynı üründü ve kutuda satılıyordu. 2002’de şirketler için ayrı, uzun süre desteklenen bir sürüm çıktı: Red Hat Enterprise Linux. 2003’te ise Red Hat Linux 9 ile eski ürün sona erdirildi ve topluluk tarafı Fedora adıyla ayrı bir projeye dönüştü. (Fedora, bir fötr şapka türü; logo ile uyumu tesadüf değil.) Bu ayrım, birazdan göreceğin aile ağacının temelidir.

2004: CentOS. RHEL’in kaynak kodu açıktı; topluluktan bir grup bu kodu alıp Red Hat markalarını çıkararak ücretsiz, birebir uyumlu bir sürüm derledi: CentOS (Community Enterprise Operating System). Yıllarca “bedava RHEL” olarak küçük şirketlerin ve hobicilerin gözdesi oldu. 2014’te Red Hat, CentOS projesini kendi çatısı altına aldı.

2006 ve sonrası: Java dünyası. Red Hat, Java uygulama sunucusu JBoss’u satın aldı. Bu blogda adı sık sık geçecek olan Quarkus’un da Red Hat’in ürünü olduğunu duyunca artık şaşırmayacaksın. Yani bu iki seri sandığından daha yakın: Java’yı orada öğreniyorsun, o Java’nın koştuğu sunucuyu burada.

2019: IBM. Ekim 2018’de duyurulan ve Temmuz 2019’da tamamlanan anlaşmayla IBM, Red Hat’i 34 milyar dolara satın aldı; o güne kadarki en büyük yazılım satın almasıydı. Red Hat, IBM içinde ayrı bir şirket gibi çalışmayı sürdürdü. Aynı yıl logo da değişti: yıllardır kullanılan, şapkanın altındaki gölgeli yüz (“Shadowman”) gitti, geriye yalnızca kırmızı şapka kaldı.

2020-2021: CentOS Stream ve yeni klonlar. Aralık 2020’de Red Hat, klasik CentOS Linux’u sonlandıracağını ve odağın CentOS Stream’e kayacağını duyurdu. Stream, RHEL’in bir sonraki sürümünün sürekli güncellenen ön izlemesi; yani RHEL’in “birebir kopyası” değil, “bir adım önü”. Bedava RHEL kopyasına alışmış topluluk bu karardan hoşlanmadı ve 2021’de iki yeni proje doğdu: CentOS’un kurucularından Gregory Kurtzer’in başlattığı Rocky Linux (adını, hayatını kaybeden CentOS kurucu ortağı Rocky McGaugh’dan alıyor) ve CloudLinux şirketinin başlattığı AlmaLinux (“alma”, birçok dilde “ruh” demek).

Aile ağacı: üst akımdan Fedora’ya, Fedora’dan RHEL’e

Bütün bu isimleri tek bir resme oturtalım. Nehir benzetmesini hatırla: su yukarıdan aşağıya akıyor.

flowchart TD
    UP["Üst akım projeleri<br/>Linux çekirdeği, GNU, GNOME, systemd, Apache...<br/>(binlerce bağımsız proje)"] --> F["Fedora<br/>topluluk, 6 ayda bir sürüm, 13 ay destek<br/>en yeni teknoloji; test pisti"]
    F --> CS["CentOS Stream<br/>RHEL'in bir sonraki küçük sürümünün<br/>sürekli güncellenen ön izlemesi; prototip"]
    CS --> R["RHEL<br/>kurumsal ürün, abonelik, 10 yıl destek<br/>bayiden alınan araba"]
    R --> RA["Rocky Linux / AlmaLinux<br/>ücretsiz, RHEL uyumlu topluluk dağıtımları<br/>aynı araba, markasız"]

Bir benzetmeyle: Fedora, bir otomobil markasının konsept araçları ve test pisti. Yeni fikirler önce burada denenir; heyecanlı ama bazen sarsıntılı. CentOS Stream, seri üretime girmek üzere olan prototip: neredeyse bitmiş, bir sonraki modelde ne olacağını gösteriyor. RHEL, bayiden aldığın araba: yıllarca test edilmiş, garantili, on yıl boyunca yedek parçası (güncellemesi) çıkan. Rocky ve Alma ise aynı fabrikanın çıktısını başka bir markayla satan üreticiler: araba aynı, garanti ve bayi desteği yok, ama bedava.

Bu akış somut: her RHEL sürümü belirli bir Fedora sürümünün dondurulmuş ve yıllarca cilalanmış hâlidir. RHEL 8, Fedora 28’den; RHEL 9, Fedora 34’ten; RHEL 10, Fedora 40’tan türedi. Fedora’da bugün gördüğün bir yenilik, iki-üç yıl sonra RHEL’de karşına çıkar.

RHEL’in sürüm tarihi

Her sürümü ezberlemene gerek yok; ama tabloya bir göz atarsan hem RHEL’in temposunu hem de Linux’un son yirmi yılda nasıl değiştiğini görürsün.

Peki ben hangisini kurmalıyım?

flowchart LR
    Q1{"Amacın ne?"} -->|"Öğrenmek, denemek,<br/>kişisel proje"| A1["RHEL, ücretsiz geliştirici<br/>aboneliğiyle<br/>(bu seride yapacağımız bu)"]
    Q1 -->|"Şirket sunucusu,<br/>destek şart"| A2["RHEL aboneliği"]
    Q1 -->|"Ücretsiz ama<br/>RHEL uyumlu sunucu"| A3["AlmaLinux ya da<br/>Rocky Linux"]
    Q1 -->|"En yeni her şey,<br/>günlük masaüstü"| A4["Fedora"]
    A1 --> N["Hepsinde komutlar ve<br/>kavramlar aynı"]
    A2 --> N
    A3 --> N
    A4 --> N

Bu seride RHEL’in kendisini kuracağız, çünkü Red Hat bireysel geliştiricilere ücretsiz bir abonelik veriyor: bir hesap açıyorsun, 16 sisteme kadar RHEL’i indirip kurabiliyor ve güncelleyebiliyorsun. Bir sonraki bölümün konusu tam olarak bu. Ama elinde bir Alma ya da Rocky varsa da seriyi hiç zorlanmadan takip edebilirsin.

Herkes bedava indirebiliyorsa Red Hat neyi satıyor?

Yazının başında sorduğumuz meraklı soruya geldik. Kaynak kod açık, Alma ve Rocky bedava, Fedora bedava. Red Hat nasıl oluyor da yılda milyarlarca dolar kazanıyor?

Cevap tek kelime: abonelik. Ve abonelikle satılan şey yazılımın kendisi değil, yazılımın etrafındaki hizmetler. Bir RHEL aboneliği aldığında şunları alıyorsun:

• Test edilmiş güncellemeler. Her yama, binlerce donanım ve yazılım bileşimiyle denendikten sonra sana geliyor. Sunucun bir güncelleme yüzünden çökmesin diye.
• Güvenlik yamaları ve on yıllık ömür. Yeni bir güvenlik açığı duyulduğunda Red Hat’in ekibi düzeltmeyi hazırlıyor (hani şu geri taşıma işi) ve on yıl boyunca hazırlamaya devam ediyor.
• Sertifikalı uyumluluk. “Bu sunucu modeli, bu veritabanı, bu Java sürümü RHEL üzerinde test edildi ve destekleniyor” garantisi. Bir bankanın “çalışıyor gibi” ile yetinmediğini tahmin edersin.
• Bir telefon numarası. Gece üçte sunucu açılmadığında arayabileceğin, cevap vermek zorunda olan bir destek ekibi.
• Hukuki güvence ve araçlar. Kullandığın kodun lisans durumuna kefil olan bir şirket; ayrıca sistemleri toplu yönetme ve izleme gibi ek araçlar.

Bob Young’ın arabasına geri dönersek: Red Hat arabayı satmıyor, kaput açık. Sattığı şey bakım sözleşmesi, garanti ve yol yardımı. Evde hobi olarak tamir edebileceğin bir araba için bunlara para vermezsin; ama binlerce yolcu taşıyan bir otobüs filosu işletiyorsan verirsin. Şirketler de tam olarak bu yüzden veriyor.

flowchart TD
    SRC["Açık kaynak kod<br/>(Linux, GNU, binlerce üst akım projesi)"] --> RH["Red Hat<br/>seçer, test eder, yamalar,<br/>sertifikalar, 10 yıl bakar"]
    RH --> SUB["Abone (şirket)<br/>RHEL + güncellemeler + destek"]
    SUB -->|"Sorun çıktı"| SUP{"Destek hattı"}
    SUP -->|"Yama hazırlanır"| RH
    RH -->|"Geliştirmeler üst akıma geri döner<br/>(önce üst akım ilkesi)"| SRC

Şemadaki son oku kaçırma: Red Hat’in yazdığı düzeltmeler yalnızca abonelere gitmiyor, üst akım projelerine geri dönüyor. Bu döngü modelin kalbidir: kod ortak mal olarak kalır, şirket onun üzerine hizmet satar.

Aboneliklerin türleri de var. Bu serinin kullanacağı bireysel geliştirici aboneliği ücretsizdir ve 16 sisteme kadar geçerlidir; ekipler için de ücretsiz bir sürümü vardır. Şirketler ise sunucu başına yıllık ödenen, destek seviyesine (mesai saatleri ya da 7/24) göre değişen standart ve premium abonelikler alır. Hepsinde yazılım aynıdır; fark, yanında gelen hizmettir.

Güvenlik açıkları çıktığında ne olur? Red Hat’in farkı

Abonelik listesindeki “güvenlik yamaları” maddesi kâğıt üstünde sıradan görünüyor. Ama son yıllarda yaşanan birkaç olaya bakınca, o maddenin neden şirketlerin RHEL’e para vermesinin en büyük nedeni olduğunu anlıyorsun. Önce birkaç kelimeyi yerine oturtalım.

Güvenlik açığı, bir programdaki, kötü niyetli birinin yapmaması gereken bir şeyi yapmasına (dosyalarını okumasına, makineni ele geçirmesine) izin veren hatadır. Her ciddi açığa dünya çapında bir kimlik verilir: CVE numarası. CVE-2024-3094 diye okursun: 2024 yılı, o yılın 3094. kaydı. Açığı kapatan düzeltmeye yama (patch) denir. Açık, yaması hazır olmadan kamuya ya da saldırganlara sızmışsa buna sıfır gün (zero-day) denir: savunanların hazırlanmak için sıfır günü vardır. Bunu önlemek için sektör bir gelenek geliştirmiştir: koordineli açıklama. Açığı bulan kişi önce yazılımın geliştiricilerine ve büyük dağıtımcılara gizlice haber verir; herkes yamasını hazırlar; belirlenen günde açık, CVE ve yamalar aynı anda yayımlanır. Bu gizli döneme ambargo denir. Red Hat, açıkları önem derecesine göre dört seviyede sınıflar (düşük, orta, önemli, kritik) ve her yamayı numaralı bir güvenlik duyurusuyla (RHSA) yayımlar.

Kapatmak neden bu kadar uzun sürüyor?

Şunu duymuşsundur: büyük bir açık çıkar, aylar hatta yıllar sonra hâlâ o açıktan girilen sistemler haberlere düşer. Ama dikkat: uzun süren şey çoğu zaman yamanın yazılması değildir; yamanın dünyadaki milyonlarca sisteme ulaşması ve uygulanmasıdır. Üç darboğaz var:

1. Yazılımın bakımcısı olmayabilir. Açık kaynak dünyasında pek çok kritik parça bir-iki gönüllünün elindedir. Yama yazacak kimse yoksa ya da geç kalırsa, herkes bekler.
2. Yama her yere ayrı ayrı taşınmalıdır. Aynı kütüphane yüzlerce dağıtımda, binlerce üründe, milyonlarca gömülü cihazda (modem, akıllı televizyon, kamera) ve konteyner imajında ayrı ayrı paketlenmiştir. Her birinin üreticisi yamayı kendi paketine taşımak zorundadır; çoğu bunu hiç yapmaz.
3. Yama uygulanmayabilir. En sık görülen ve en pahalı olan bu. 2017’de Equifax adlı kredi şirketi, Apache Struts’taki bir açık için yama çıktıktan iki ay sonra bile yamayı uygulamamıştı; saldırganlar o açıktan girip 147 milyon kişinin bilgisini çaldı. Aynı yıl WannaCry fidye yazılımı, Microsoft’un iki ay önce yamaladığı bir açıkla 150 ülkede yüz binlerce bilgisayarı kilitledi; İngiltere’de hastaneler ameliyat erteledi. 2021’in Log4Shell’inden yıllar sonra bile yamasız sistemlere rastlanıyor.

Yani bir açığın kapanma süresi, yamanın yazılması artı dağıtılması artı uygulanmasıdır. İlk ikisi dağıtımcının işi, üçüncüsü sistem yöneticisinin. Yani bir gün senin.

flowchart TD
    A["Açık bulunur<br/>(araştırmacı, mühendis, bazen saldırgan)"] --> B["Gizli bildirim: üst akım geliştiriciler<br/>ve dağıtımcılar (ambargo dönemi)"]
    B --> C["Yamalar hazırlanır ve test edilir<br/>Red Hat: geri taşıma, RHSA taslağı"]
    C --> D["Koordineli açıklama günü:<br/>CVE ve yamalar aynı anda yayımlanır"]
    D --> E{"Yama uygulandı mı?"}
    E -->|"Evet: dnf update"| F(["Açık kapandı"])
    E -->|"Hayır"| G["Saldırganlar açığı kullanan araçlar yazar<br/>(çoğu zaman saatler içinde)"]
    G --> H["İhlal: veri sızıntısı, fidye yazılımı<br/>(Equifax 2017, WannaCry 2017)"]
    H --> E

Red Hat’in müdahalesi neden hızlı?

Red Hat’in 2001’den beri yalnızca bu işle uğraşan bir Ürün Güvenliği ekibi var. Bu ekip ambargolu bildirimleri ilk alanlar arasındadır; çünkü Red Hat hem dünyanın en büyük Linux dağıtımcısı hem de çekirdek, glibc, systemd, OpenSSL gibi kritik parçaların bakımcılarını kendi bünyesinde çalıştıran bir şirkettir. Çoğu zaman yamayı yazan mühendis zaten Red Hat’te çalışmaktadır. Red Hat ayrıca CVE numarası verme yetkisi olan az sayıdaki kuruluştan biridir; XZ olayındaki CVE-2024-3094 numarasını Red Hat verdi. Sonuç: koordineli açıklama günü geldiğinde yama çoğunlukla hazırdır; sen sabah dnf update dediğinde gelir.

İkinci bir avantaj, biraz önce tanıdığın sabit sürüm modelinden gelir: RHEL, programların eski ve iyice test edilmiş sürümlerini taşıdığı için, en yeni sürümlere eklenen taze hatalardan çoğu zaman hiç etkilenmez. Aşağıdaki tabloda bunun iki örneğini göreceksin.

Olaylardan örnekler

Red Hat bugün: yalnızca bir işletim sistemi değil

Red Hat’in adı RHEL ile anılıyor ama şirketin bugünkü ürün ailesi çok daha geniş. Hepsini şimdi öğrenmene gerek yok; sadece isimleri duyduğunda “ha, o Red Hat’in” diyebil diye bir harita çizelim.

flowchart BT
    RHEL["RHEL<br/>işletim sistemi, her şeyin zemini"] --> POD["Podman<br/>konteynerler (14. bölüm)"]
    POD --> OCP["OpenShift<br/>yüzlerce sunucuda konteyner yönetimi<br/>(Kubernetes tabanlı)"]
    RHEL --> ANS["Ansible<br/>yüzlerce sunucuda aynı işi<br/>tek komutla yaptırma"]
    OCP --> APP["Uygulama tarafı<br/>Quarkus, JBoss EAP<br/>(Java serisinin dünyası)"]
    RHEL --> SAT["Satellite ve Insights<br/>binlerce makineyi toplu yönetme"]
    RHEL --> RAI["RHEL AI<br/>kendi sunucunda açık<br/>yapay zekâ modeli çalıştırma"]
    OCP --> OAI["OpenShift AI<br/>modelleri ölçekte<br/>eğitme ve sunma"]

Aşağıdan yukarıya oku. Her şeyin altında RHEL var. Onun üstünde Podman, programları “konteyner” denen taşınabilir kutulara koymanı sağlıyor. Yüzlerce sunucuda binlerce konteyneri yönetmek gerekince OpenShift devreye giriyor. Ansible, “şu 200 sunucuda şu ayarı yap” gibi işleri tek komutla yaptıran otomasyon aracı. Quarkus ve JBoss EAP ise Java uygulamalarının koştuğu katman; Java serisi ilerledikçe onlarla orada karşılaşacaksın. Bu seride bu yığının en altındayız ve sağlam bir zemin kurmadan yukarı çıkmıyoruz.

Bir de görünmeyen taraf var: Red Hat’in yalnızca ürünleri değil, dağıtımın içindeki parçaların kendisi de büyük ölçüde Red Hat mühendislerinin elinden çıkmıştır. Az önce tanıdığın systemd’yi 2010’da Red Hat’te çalışan Lennart Poettering ve Kay Sievers yazdı. Masaüstü ortamı GNOME’un, ağ yönetimi aracı NetworkManager’ın, ses altyapısının, Linux çekirdeğinin ve konteyner dünyasının temeli Kubernetes’in en büyük katkıcıları arasında Red Hat var. “Önce üst akım” ilkesi lafta kalmıyor.

Red Hat ve yapay zekâ

Haritanın sağ tarafındaki iki yeni kutuyu açayım, çünkü bugün Red Hat’in en çok konuşulan tarafı bu. Önce yeni başlayan için bir yer tespiti: ChatGPT gibi bir sohbet asistanı bir web sayfası değildir; arkasında binlerce GPU’lu (grafik işlemcili) sunucu çalışır ve o sunucuların neredeyse tamamı Linux kullanır. Bir modeli eğitmek (training), ona milyarlarca örnek veri göstermek demek; çalıştırmak (inference) ise eğitilmiş modele soru sorup cevap almak. İkisi de dev sunucu filolarında, işletim sisteminin üstünde olur. Yani yapay zekâ dünyasında Red Hat’in ilk rolü, hep olduğu gibi, zemin olmak: GPU sunucularında RHEL.

Onun üstüne 2023’ten itibaren bir ürün ailesi kurdu:

İki fikir bu tablonun tamamını açıklıyor. Birincisi, Red Hat’in sloganı: “herhangi bir model, herhangi bir donanım, herhangi bir bulut.” Tıpkı RHEL’in her sunucu markasında çalışması gibi, modelin de hangi şirketin çipinde ya da bulutunda koştuğunun fark etmemesi. İkincisi, bu yazıda üç kez karşına çıkan açık kaynak refleksi: modelin ağırlıkları açık olsun (Granite), eğitme yöntemi açık olsun (InstructLab), çalıştırma motoru açık olsun (vLLM). Kapalı bir yapay zekâ servisi, Bob Young’ın kaputu kaynaklı arabasının 2020’lerdeki hâlidir; Red Hat aynı kaputu bu sefer yapay zekâ için açmaya çalışıyor.

Peki bir banka bunu neden istesin, “ChatGPT’ye sorarız olur biter” demesin? Çünkü müşteri verisini dışarıdaki bir servise gönderemez; hem yasa (Türkiye’de KVKK, Avrupa’da GDPR) hem sağduyu buna izin vermez. Modeli kendi RHEL sunucusunda çalıştırırsa veri evden çıkmaz. Yazının son notunda bu cümleye geri döneceğiz.

Nerelerde çalışıyor?

Somutlaştıralım. New York Borsası’nın işlem sistemleri RHEL üzerinde çalışıyor. Dünyanın en büyük bankaları, havayolu ve telekom şirketleri, kamu kurumları… Red Hat, Fortune 500 listesindeki şirketlerin büyük çoğunluğunun müşterisi olduğunu söylüyor. Büyük bulut sağlayıcılarının hepsi (Amazon, Microsoft, Google) RHEL’i hazır sunuyor. Türkiye’de de bankaların, telekom operatörlerinin ve kamu sistemlerinin arka odalarında büyük ihtimalle bu aileden bir makine var. Yani öğrendiğin şey bir hobi aracı değil; dünyanın para ve veri altyapısının üzerinde durduğu zemin.

”Kurumsal” tam olarak ne demek?

Bu yazıda “kurumsal” kelimesini bolca kullandım; biraz somutlaştırayım, çünkü bankaların RHEL’i seçmesinin nedeni tam olarak burada. Kurumsal (enterprise) bir ortamı sıradan bir bilgisayardan ayıran üç şey var: ölçek (yüz değil, on binlerce makine), sorumluluk (sistem durursa para, bazen hayat kaybı) ve denetim (bir düzenleyici kurum gelip “bunu nasıl güvenceye aldınız?” diye sorar).

O son maddeyi karşılamak için işletim sisteminin bağımsız kurumlarca sınanmış olması gerekir. RHEL’in taşıdığı belgelerden birkaçı:

• FIPS 140-3. Şifreleme modüllerinin ABD ve Kanada devlet standardına göre test edilmiş olması. Kamu ve finans kurumlarının çoğu bunu şart koşar.
• Common Criteria. Uluslararası bir güvenlik değerlendirme standardı; bağımsız laboratuvarlar sistemi didik didik eder.
• DISA STIG ve CIS profilleri. “Güvenli bir sunucu şöyle ayarlanır” diyen resmî yapılandırma rehberleri. RHEL bunları hazır profil olarak sunar; OpenSCAP adlı yerleşik araçla sistemin rehbere uyup uymadığını tek komutla denetlersin.
• PCI DSS gibi sektör kuralları. Kredi kartı işleyen her sistemin uyması gereken kurallar; RHEL’in profilleri bunlara da hazır cevap verir.

Bir de sertifikalı katalog var: hangi sunucu modeli, hangi veritabanı, hangi SAP ya da Oracle sürümü RHEL üzerinde resmî olarak destekleniyor, hepsi tek bir listede. Bir banka “çalışıyor gibi” demez, “bu listede” der. Kurumsal Linux’un ücretini haklı çıkaran şey, yazılımın kendisinden çok bu kâğıt yığınıdır.

Sistemin içine kısa bir bakış: ileride neler var?

Yazıyı kapatmadan, serinin ilerleyen bölümlerinde uzun uzun açacağımız üç kavramı şimdiden birer cümleyle tanıştırayım; böylece 2. bölümde kurulum ekranında gördüğün şeyler yabancı gelmez.

Açılış zinciri. Güç düğmesine bastığında olanlar bir bayrak yarışı gibidir:

flowchart TD
    B["1. UEFI / BIOS: anakart yazılımı diski bulur"] --> G["2. GRUB: önyükleyici, hangi çekirdek yüklenecek?"]
    G --> K["3. Linux çekirdeği: donanımı tanır"]
    K --> S["4. systemd: servisleri sırayla başlatır"]
    S --> LG["5. Giriş ekranı ya da komut satırı"]

Anakartın kendi minik yazılımı (UEFI) diski bulur ve önyükleyiciyi (GRUB) çalıştırır; GRUB çekirdeği belleğe yükler; çekirdek donanımı tanıyıp ilk programı, systemd’yi başlatır; systemd de sırayla her şeyi ayağa kaldırır. 8. bölümde bu zincirin her halkasına dokunacağız.

Terminal, kabuk ve komut. Üçü sık karıştırılır. Terminal, yazdıklarını gösteren pencere; kabuk, o pencerede yazdığın satırı okuyup çalıştıran program (RHEL’de bash); komut ise kabuğa söylediğin tek bir iş (ls gibi). Pencere, garson, sipariş. 3. bölümde başlıyoruz.

root ve sıradan kullanıcı. Linux’ta her şeyi yapabilen tek bir hesap vardır: root. Geri kalan herkes yalnızca kendi dosyalarına dokunabilir; sistem dosyaları için root’tan izin ister (sudo komutuyla). Sistem çağrısı şemasındaki “izin var mı?” sorusu buradan besleniyor. 6. bölümün konusu.

Sertifika yolu: RHCSA, RHCE ve ötesi

Seriyi “RHCSA müfredatını izleyerek” yazdığımı söylemiştim; ne olduğunu iki paragrafla anlatayım. RHCSA (Red Hat Certified System Administrator), Red Hat’in temel sistem yöneticiliği sertifikası. Sınavı diğer pek çok bilişim sınavından ayıran şey şu: çoktan seçmeli soru yoktur. Karşına gerçek bir RHEL makinesi konur ve “şu kullanıcıyı oluştur, şu diski bağla, şu servisi açılışta başlat, SELinux’u şöyle ayarla” gibi somut görevler verilir. Yapabiliyorsan geçersin, yapamıyorsan geçemezsin. Bu yüzden ezberle alınamaz; iyi ki de öyle.

Bir üst basamak RHCE (Red Hat Certified Engineer), Ansible ile otomasyon üzerine kurulu. Onun da üstünde, uzmanlık sınavlarını toplayarak ulaşılan RHCA (Architect) var. Bu seri RHCSA’nın konularını sırayla kapsıyor; serinin son bölümünde sınavın kendisini, nasıl hazırlanılacağını ve sonrasında hangi yolların açıldığını konuşacağız.

Serinin yol haritası

Nereye gittiğimizi baştan bil istiyorum. Her bölüm bir öncekinin üstüne çıkacak, tıpkı diğer serilerde olduğu gibi:

Güncel liste ve yayımlanan bölümler her zaman Red Hat sayfasında duruyor.

Kendin düşün

Bu bölümde komut yazmadık, o yüzden sorular da kâğıt üstünde. Amaç, kavramların yerine oturup oturmadığını görmek.

Soru 1 — Telefonunda Linux var mı? (kolay)

Android telefonların Linux çekirdeği kullandığını söyledik. Buna göre “Android bir Linux dağıtımıdır” demek doğru mu? Araba benzetmesiyle düşün.

Soru 2 — Doğru rafa koy (kolay)

Şu dört ismi tanımlarıyla eşleştir: Fedora, CentOS Stream, RHEL, AlmaLinux. (a) On yıl desteklenen, abonelikle satılan kurumsal ürün. (b) RHEL’in bir sonraki sürümünün ön izlemesi. (c) Altı ayda bir sürüm çıkaran, en yeni teknolojiyi ilk deneyen topluluk dağıtımı. (d) RHEL ile uyumlu, ücretsiz topluluk dağıtımı.

Soru 3 — Bağımlılık zinciri (orta)

Kurmak istediğin fotoeditor paketi resimlib’e, resimlib de sikistirma’ya bağımlı; sikistirma zaten kurulu. dnf install fotoeditor dediğinde dnf hangi paketleri indirir? Akış şemasındaki döngüyü elle takip et.

Soru 4 — Eski görünen sürüm (orta)

Bir arkadaşın “RHEL 9’da Python 3.9 var, güncel değil, bu sistem güvensiz” diyor. Geri taşıma kavramıyla ona iki cümlelik bir cevap yaz.

Soru 5 — Kaputu açık araba (orta)

Bir arkadaşın “Kod zaten açıksa Red Hat’e para vermek saçmalık, herkes Alma kurar geçer” diyor. Ona hangi durumda haklı, hangi durumda haksız olduğunu bir paragrafla anlat.

Soru 6 — Komutlar taşınır mı? (orta)

RHEL’de öğrendiğin bir komutun Ubuntu’da da çalışıp çalışmayacağını tahmin etmen gerekiyor. Sence hangi tür komutlar iki tarafta da aynı olur, hangileri farklı olur? “RHEL ile Ubuntu’nun farkı ne?” tablosuna bak.

Soru 7 — Yama vardı (orta)

Equifax olayında Apache Struts açığının yaması Mart 2017’de çıkmıştı; şirket Mayıs’ta ele geçirildi. Güvenlik akış şemasında bu şirket hangi kutuda takıldı? Bu durumun bir sistem yöneticisiyle ilgisi ne?

Son not: her şeyin altında veri var

Bu yazıyı kapatmadan önce, bütün bu çekirdek, paket, abonelik hikâyesinin neden önemli olduğunu tek kelimeyle söyleyeyim: veri.

Yirminci yüzyılın en değerli şeyi petroldü; ülkeler onun için savaştı. Yirmi birinci yüzyılın petrolü veri ve bu artık bir benzetme değil. Hesap numaraların, sağlık kayıtların, konumun, mesajların, alışkanlıkların, yüzün ve sesin… hepsi bir sunucuda duruyor ve o sunucuların büyük çoğunluğu Linux çalıştırıyor. Verin çalındığında olacaklar artık “şifremi değiştiririm” ile sınırlı değil: kimliğinle kredi çekilebilir, sesin ve yüzün yapay zekâyla taklit edilip ailen dolandırılabilir, bir şirketin bütün verisi şifrelenip fidye istenebilir, bir hastane günlerce kapanabilir. 2016’da yaklaşık 50 milyon Türkiye vatandaşının kimlik bilgilerini içeren bir veritabanı internete düştü; o veri hâlâ dolaşımda. Yapay zekâ bu tabloyu iki yönden büyütüyor: modeller veriyle besleniyor (senin verinle de) ve çalınan veriyle yapılabileceklerin listesi her yıl uzuyor.

Bu yüzden bir sistem yöneticisinin asıl işi sunucuyu ayakta tutmak değil, veriyi korumaktır. Bu serideki her bölüm aslında ona hizmet ediyor: kullanıcılar ve izinler (kim neye dokunabilir), SELinux (kural çiğnense bile çekirdek “dur” der), güvenlik duvarı (kim içeri girebilir), güncellemeler (bilinen deliklerin kapanması), disk şifreleme ve yedekleme. Komutları öğreneceksin, ama her komutun arkasında şu soru dursun: bu, verinin kimin elinde olduğunu değiştiriyor mu?

Red Hat’in bu alandaki işi de üç katmanda özetlenebilir:

• Çekirdek seviyesinde kilitler. SELinux’un ana bakımcısı Red Hat; 2005’ten beri RHEL’de varsayılan olarak açık. Linux’un disk şifreleme aracının (LUKS) bakımcısı bir Red Hat mühendisi; şifreli bir sunucu diskini açılışta ağdaki anahtar sunucusundan otomatik açan Clevis/Tang yöntemi Red Hat’te doğdu.
• Sistem geneli şifreleme kuralları. RHEL 8’den beri tek komutla bütün sistemin “zayıf şifrelemeyi reddet” moduna geçmesi; FIPS onaylı modüller; RHEL 10 ile kuantum sonrası şifreleme, yani gelecekteki kuantum bilgisayarların bugünkü şifreleri kırma ihtimaline karşı bugünden hazırlık.
• Kimlik, tespit ve tedarik zinciri. Kurum içi kimlik yönetimi (Identity Management) ve uygulamalar için Keycloak (Red Hat’te doğdu, 2023’te bağımsız bir vakfa devredildi); Insights ile açıkların sen fark etmeden önce tespiti; XZ olayından sonra önemi artan yazılım tedarik zinciri güvencesi (imzalı yapılar, her paketin malzeme listesi); konteynerlerin root olmadan çalışması (Podman); ve verinin bellekteyken bile şifreli kaldığı gizli hesaplama üzerinde çalışmalar.

Yapay zekâ bağını da kapatalım: bir kurum müşteri verisini dışarıdaki bir sohbet servisine gönderemez; KVKK ve GDPR bunu zaten yasaklar. Çözüm, modeli kendi sunucunda çalıştırmak. RHEL AI ve OpenShift AI’ın varlık nedeni tam olarak bu cümle: veri evden çıkmasın.

Özet ve sırada ne var?

Kaynaklar ve daha fazla okuma

Yazıdaki bilgilerin kaynakları ve bir sonraki adım için başvurabileceğin resmî sayfalar:

• Red Hat geliştirici aboneliği: RHEL’i ücretsiz indirmek için (2. bölümün konusu).
• RHEL yaşam döngüsü: her sürümün destek tarihleri.
• Red Hat güvenlik güncellemeleri ve CVE veritabanı: yazıdaki olayların resmî kayıtları, örneğin CVE-2024-3094 (XZ arka kapısı).
• Fedora, CentOS Stream, Rocky Linux, AlmaLinux: aile ağacındaki dağıtımlar.
• Pardus: TÜBİTAK’ın dağıtımı.
• kernel.org: Linux çekirdeğinin evi; Linux’un tarihi (Wikipedia, İngilizce).
• Red Hat AI, InstructLab, vLLM: yapay zekâ bölümündeki projeler.
• RHCSA sertifikası: sınavın resmî sayfası.
• Fotoğraflar, Wikimedia Commons: Linus Torvalds, Richard Stallman, Tux, Bob Young, Red Hat Tower.