CentOS 7 EOL Sonrası Geçiş Seçenekleri: Hangi Dağıtımı Seçmeli?

yazar

Haziran 2024’te CentOS 7, resmi olarak End of Life sürecine girdi ve bu tarihten itibaren güvenlik yamaları, hata düzeltmeleri ve teknik destek tamamen sona erdi. Eğer hâlâ CentOS 7 üzerinde üretim ortamı işletiyorsan, bu yazı tam sana göre. Panik yapmaya gerek yok ama harekete geçmek için de artık gerçekten geç kalınmış sayılır. Gelin mevcut seçenekleri, göç süreçlerini ve dikkat edilmesi gereken kritik noktaları tek tek ele alalım.

CentOS 7 EOL Durumu ve Riskleri

CentOS 7, RHEL 7 tabanlı ve uzun yıllar boyunca kurumsal ortamların vazgeçilmezi olmuş bir dağıtımdı. Red Hat’in 2020’de CentOS’un geleneksel yolunu değiştirip CentOS Stream’e yönelmesi, milyonlarca sunucuyu bir anda belirsizliğe sürükledi.

EOL sonrasında karşılaşabileceğin somut riskler şunlar:

  • Güvenlik açıkları: Yeni keşfedilen CVE’ler için herhangi bir yama yayınlanmayacak. Bu, saldırı yüzeyinin her geçen gün büyümesi anlamına geliyor.
  • Uyumluluk sorunları: PCI-DSS, HIPAA, ISO 27001 gibi uyumluluk standartları desteklenmeyen işletim sistemi kullanımını açıkça yasaklıyor.
  • Yazılım desteği: Çoğu yazılım satıcısı CentOS 7 üzerinde destek vermeyi bıraktı. Açtığın destek taleplerinde “önce işletim sistemini güncelleyin” yanıtıyla karşılaşacaksın.
  • Yeni paket eksikliği: EPEL ve diğer repolar CentOS 7 için paket güncellemeyi yavaşlattı, bazıları tamamen durdurdu.

Geçiş Seçenekleri Neler?

Elinde birkaç farklı yol var. Hangisini seçeceğin; mevcut altyapının karmaşıklığına, bütçene ve ekibinin kapasitesine göre değişecek.

1. Rocky Linux 8 veya 9’a Geçiş

Rocky Linux, CentOS’un eski rolünü devralmak için Greg Kurtzer tarafından kuruldu. RHEL ile birebir uyumlu, topluluk destekli ve tamamen ücretsiz. Kurumsal ortamlar için en popüler seçenek haline geldi.

Rocky Linux 8: RHEL 8 tabanlı, 2029’a kadar destek var. Rocky Linux 9: RHEL 9 tabanlı, 2032’ye kadar destek var. Eğer uzun vadeli düşünüyorsan doğrudan 9’a geçmek mantıklı.

2. AlmaLinux’a Geçiş

CloudLinux ekibi tarafından geliştirilen AlmaLinux de RHEL uyumlu, ücretsiz ve topluluk destekli. Rocky Linux ile neredeyse aynı özellikleri taşıyor. Bazı ekipler AlmaLinux’un daha hızlı güvenlik yaması yayınladığını öne sürüyor, ancak pratikte ikisi arasındaki fark minimaldir.

3. RHEL’e Geçiş (Ücretsiz Geliştirici Lisansı)

Red Hat, küçük ortamlar için 16 sunucuya kadar ücretsiz RHEL lisansı sunuyor. Büyük kurumlar için ücretli lisans modelini değerlendirmek gerekiyor. Red Hat desteği, sertifikalı yazılımlar ve öngörülebilir yaşam döngüsü istiyorsan bu seçenek mantıklı.

4. Oracle Linux

Oracle Linux da RHEL uyumlu ve ücretsiz bir seçenek. Oracle’ın kendi Ksplice teknolojisiyle yeniden başlatma gerektirmeyen çekirdek güncellemesi sunması önemli bir avantaj. Ancak bazı ekipler Oracle bağımlılığından çekiniyor.

5. EL7 Genişletilmiş Destek (TuxCare/AlmaLinux ELS)

Hemen göç edemiyorsan, TuxCare veya AlmaLinux’un sunduğu ücretli genişletilmiş destek seçeneği bir köprü çözümü olabilir. Bu servisler CentOS 7 için güvenlik yamalarını ek ücret karşılığında sunmaya devam ediyor. Bu bir son çare çözümü; uzun vadeli strateji olarak düşünme.

Rocky Linux’a Yerinde Geçiş (In-Place Migration)

En çok tercih edilen senaryo yerinde geçiş, yani mevcut sunucuyu yeni bir kurulum yapmadan Rocky Linux’a dönüştürmek. Bunun için migrate2rocky aracı kullanılıyor.

Önemli uyarı: Yerinde geçiş CentOS 7’den direkt Rocky Linux 8’e değil, önce CentOS 7’yi Rocky Linux 7 eşdeğerine (aslında bu pek mantıklı değil), ardından yükseltme yapılıyor. Gerçekte CentOS 7’den Rocky Linux 8’e direkt yerinde geçiş desteklenmiyor. Desteklenen yol CentOS 8’den Rocky Linux 8’e geçiş. CentOS 7 için en sağlıklı yol temiz kurulum ya da aşağıda anlatacağım Leapp aracıyla RHEL 8 uyumlu platforma yükseltme.

Leapp ile CentOS 7’den AlmaLinux 8’e Yükseltme

Leapp, Red Hat’in geliştirdiği ve RPM tabanlı sistemlerde büyük sürüm atlama işlemini gerçekleştiren bir araç. ELevate projesi bu aracı CentOS 7 için de kullanılabilir hale getirdi.

# ELevate reposunu ekle
sudo curl -o /etc/yum.repos.d/elevate.repo 
  https://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm

# elevate-release paketini kur
sudo yum install -y 
  https://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm

# AlmaLinux 8 hedefli leapp-upgrade paketini kur
sudo yum install -y leapp-upgrade-el7toel8

Leapp ön kontrol aşamasını çalıştır. Bu aşama sistemde potansiyel sorunları tespit eder:

sudo leapp preupgrade --target almalinux8

Çıktıyı dikkatlice incele. Genellikle şu tarz uyarılar görürsün:

# Uyarı raporu dosyası
cat /var/log/leapp/leapp-report.txt

# Yaygın sorunları çözmek için örnek: PAM modülü uyarısı
sudo leapp answer --section check_vdo.no_vdo_devices=True

Sorunları çözdükten sonra yükseltmeyi başlat:

sudo leapp upgrade --target almalinux8
# Yükseltme tamamlandıktan sonra sistem yeniden başlar
sudo reboot

Yükseltme sonrası kontroller:

# Versiyon kontrolü
cat /etc/os-release

# Yükseltme loglarını kontrol et
cat /var/log/leapp/leapp-upgrade.log | grep -i error

# Eski kernel artıklarını temizle
sudo dnf remove $(dnf repoquery --installonly --latest-limit=-1 -q)

Temiz Kurulum ile Geçiş Senaryosu

Karmaşık yapıya sahip sistemlerde yerinde geçiş yerine temiz kurulum her zaman daha güvenli. Özellikle veritabanı sunucuları, middleware katmanları ve onlarca özel konfigürasyon içeren sistemlerde bu yolu tercih etmeni öneririm.

Sistem Envanteri Çıkarma

Göç öncesi mevcut sistemin tam envanterini almak kritik. Şu betiği tüm CentOS 7 sunucularında çalıştır:

#!/bin/bash
# centos7_inventory.sh - Sistem envanteri betiği

echo "=== SISTEM BILGILERI ===" > /tmp/inventory_$(hostname).txt
hostnamectl >> /tmp/inventory_$(hostname).txt

echo -e "n=== KURULU PAKETLER ===" >> /tmp/inventory_$(hostname).txt
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}n" | 
  sort >> /tmp/inventory_$(hostname).txt

echo -e "n=== AKTIF SERVISLER ===" >> /tmp/inventory_$(hostname).txt
systemctl list-units --type=service --state=running >> /tmp/inventory_$(hostname).txt

echo -e "n=== ACIK PORTLAR ===" >> /tmp/inventory_$(hostname).txt
ss -tlnp >> /tmp/inventory_$(hostname).txt

echo -e "n=== CRON JOBS ===" >> /tmp/inventory_$(hostname).txt
for user in $(cut -f1 -d: /etc/passwd); do
  crontab -u $user -l 2>/dev/null | grep -v "^#" | 
    awk -v user="$user" '{print user": "$0}'
done >> /tmp/inventory_$(hostname).txt

echo -e "n=== DISK KULLANIMI ===" >> /tmp/inventory_$(hostname).txt
df -hT >> /tmp/inventory_$(hostname).txt

echo "Envanter dosyasi: /tmp/inventory_$(hostname).txt"

Konfigürasyon Yedekleme

#!/bin/bash
# Kritik konfigurasyon dosyalarini yedekle
BACKUP_DIR="/backup/migration_$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR

# Sistem konfigurasyonlari
cp -rp /etc/httpd $BACKUP_DIR/ 2>/dev/null
cp -rp /etc/nginx $BACKUP_DIR/ 2>/dev/null
cp -rp /etc/mysql $BACKUP_DIR/ 2>/dev/null
cp -rp /etc/postgresql $BACKUP_DIR/ 2>/dev/null
cp -rp /etc/ssh $BACKUP_DIR/
cp -rp /etc/sudoers* $BACKUP_DIR/
cp -rp /etc/cron* $BACKUP_DIR/
cp -rp /etc/sysctl.conf $BACKUP_DIR/
cp -rp /etc/security $BACKUP_DIR/
cp -rp /etc/pam.d $BACKUP_DIR/

# Repo listesi
rpm -qa > $BACKUP_DIR/rpm_packages.txt
pip freeze > $BACKUP_DIR/pip_packages.txt 2>/dev/null
gem list > $BACKUP_DIR/gem_packages.txt 2>/dev/null

# Firewall kurallari
iptables-save > $BACKUP_DIR/iptables_rules.txt
firewall-cmd --list-all > $BACKUP_DIR/firewalld_rules.txt 2>/dev/null

echo "Yedek alindi: $BACKUP_DIR"
tar czf /backup/migration_backup_$(date +%Y%m%d).tar.gz $BACKUP_DIR

Yaygın Göç Sorunları ve Çözümleri

Python 2 Bağımlılıkları

CentOS 7’nin en büyük sorunlarından biri Python 2 bağımlılıkları. Rocky Linux 8 ve AlmaLinux 8 varsayılan olarak Python 3 geliyor. Eski Python 2 betiklerini hemen tespit et:

# Python 2 ile yazilmis scriptleri bul
find /usr/local/bin /opt /home -name "*.py" -exec head -1 {} ; 
  2>/dev/null | grep -l "python2|python " | head -20

# Alternatif: shebang satirlarini kontrol et
grep -r "#!/usr/bin/python$|#!/usr/bin/env python$" 
  /usr/local/bin /opt/scripts 2>/dev/null

Python 2 scriptlerini Rocky Linux 8/9’da çalıştırmak istiyorsan:

# Rocky Linux 8'de Python 2 kurulumu (gecici cozum)
sudo dnf install python2 python2-pip

# Scriptin shebang satirini guncelle
sed -i 's|#!/usr/bin/python$|#!/usr/bin/python3|g' /path/to/script.py

SELinux Politika Farklılıkları

RHEL/Rocky Linux 8 ve 9’da SELinux politikaları önemli ölçüde değişti. Geçiş sonrası servisler başlamıyorsa ilk kontrol noktası bu:

# SELinux hatalarini goster
ausearch -m AVC -ts recent | audit2why

# Gecici olarak permissive moda al (test icin)
setenforce 0

# Yeni politika modulu olustur
ausearch -m AVC -ts recent | audit2allow -M mycustom_policy
semodule -i mycustom_policy.pp

# Kalici cozum icin enforcing'e don
setenforce 1

Servis ve Daemon Farklılıkları

Rocky Linux 9’da systemd davranışı bazı noktalarda değişti. Özellikle ağ yapılandırması NetworkManager tabanlı, eski network servisi artık yok:

# CentOS 7'deki eski agi yeni sistemde tanimla
# /etc/sysconfig/network-scripts yerine nmcli kullan

nmcli connection show
nmcli con add type ethernet ifname eth0 
  con-name "Production-NIC" 
  ipv4.addresses "192.168.1.100/24" 
  ipv4.gateway "192.168.1.1" 
  ipv4.dns "8.8.8.8,8.8.4.4" 
  ipv4.method manual

nmcli con up "Production-NIC"

Ansible ile Toplu Göç Yönetimi

Onlarca sunucun varsa her birine tek tek el atmak hem zaman kaybı hem de hata riskini artırır. Ansible ile göç sürecini otomatize edebilirsin:

# playbook: centos7_precheck.yml
---
- name: CentOS 7 Goc Oncesi Kontroller
  hosts: centos7_servers
  become: yes
  tasks:

    - name: OS versiyonunu kontrol et
      fail:
        msg: "Bu sunucu CentOS 7 degil: {{ ansible_distribution }} {{ ansible_distribution_version }}"
      when: not (ansible_distribution == "CentOS" and ansible_distribution_major_version == "7")

    - name: Disk alani kontrolu (min 10GB bos)
      fail:
        msg: "Yetersiz disk alani: {{ item.size_available | int // 1024 // 1024 // 1024 }}GB bos"
      when:
        - item.mount == "/"
        - item.size_available | int < 10737418240
      loop: "{{ ansible_mounts }}"

    - name: Aktif servisleri kaydet
      shell: systemctl list-units --type=service --state=running --no-pager --plain | awk '{print $1}'
      register: running_services

    - name: Servis listesini dosyaya yaz
      copy:
        content: "{{ running_services.stdout }}"
        dest: "/tmp/pre_migration_services_{{ inventory_hostname }}.txt"

    - name: Kritik paketlerin versiyonlarini kaydet
      shell: rpm -qa --queryformat "%{NAME}=%{VERSION}n" | sort
      register: package_list

    - name: Paket listesini dosyaya yaz
      copy:
        content: "{{ package_list.stdout }}"
        dest: "/tmp/pre_migration_packages_{{ inventory_hostname }}.txt"

Geçiş Sonrası Doğrulama

Sistemi göç ettirdikten sonra her şeyin düzgün çalıştığını doğrulamak için sistematik bir yaklaşım izle:

#!/bin/bash
# post_migration_check.sh

echo "=== GOCS SONRASI KONTROL ==="
echo ""

echo "1. OS Versiyonu:"
cat /etc/os-release | grep -E "NAME|VERSION"
echo ""

echo "2. Kernel Versiyonu:"
uname -r
echo ""

echo "3. Kritik Servislerin Durumu:"
for service in sshd crond rsyslog firewalld; do
    status=$(systemctl is-active $service 2>/dev/null)
    echo "   $service: $status"
done
echo ""

echo "4. SELinux Durumu:"
getenforce
echo ""

echo "5. Firewall Durumu:"
firewall-cmd --state
echo ""

echo "6. Disk Kullanimi:"
df -hT | grep -v tmpfs
echo ""

echo "7. Son 50 Sistem Log Hatasi:"
journalctl -p err -n 50 --no-pager

Gerçek Dünya Senaryosu: E-Ticaret Sunucusu Göçü

Bir müşterimizin CentOS 7 üzerinde çalışan, Apache + PHP 7.2 + MySQL 5.7 tabanlı e-ticaret platformunu Rocky Linux 9’a taşıma sürecini kısaca anlatalım.

Karşılaştığımız başlıca sorunlar şunlardı:

  • PHP 7.2 uyumsuzluğu: Rocky Linux 9 varsayılan olarak PHP 8.1 geliyor. Uygulamanın PHP 8.1 ile uyumlu olup olmadığını test etmemiz gerekti. Remi reposu bu geçiş sürecinde hayat kurtardı.
  • MySQL 5.7 yok: Rocky Linux 9’da MySQL 5.7 resmi repolardan gelmiyor. MySQL 8.0’a geçiş yaptık, uygulama katmanında bazı SQL sorgu düzeltmeleri gerekti.
  • Özel Apache modülleri: Bazı özel derleme modüller yeniden derlenmesi gerekti.
# Rocky Linux 9'da PHP 7.4 kurulumu (Remi repo ile)
dnf install -y https://rpms.remirepo.net/enterprise/remi-release-9.rpm
dnf module reset php -y
dnf module enable php:remi-7.4 -y
dnf install -y php php-fpm php-mysqlnd php-gd php-xml php-mbstring

# MySQL 8.0 kurulumu
cat > /etc/yum.repos.d/mysql.repo << 'EOF'
[mysql80-community]
name=MySQL 8.0 Community Server
baseurl=https://repo.mysql.com/yum/mysql-8.0-community/el/9/$basearch/
enabled=1
gpgcheck=1
gpgkey=https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
EOF

dnf install -y mysql-community-server

Geçiş süreci toplam 4 saat sürdü. Sistemi önce staging ortamında test ettik, sonra prodüksiyon ortamına geçiş için gece bakım penceresi oluşturduk.

Hangi Seçeneği Seçmeli?

Bu sorunun cevabı duruma göre değişiyor ama şu rehber ilkeleri kullanabilirsin:

  • Hız ve maliyet önceliksin: AlmaLinux 8 veya Rocky Linux 8, ELevate ile yerinde geçiş yap.
  • Uzun vadeli stabilite: Rocky Linux 9 veya AlmaLinux 9, temiz kurulum tercih et.
  • Red Hat desteği lazım: Kurumsal RHEL lisansı al, Red Hat’in ücretsiz 16 sunucu teklifinden başla.
  • Oracle veritabanı ortamı: Oracle Linux mantıklı bir seçenek olabilir.
  • Geçiş için zaman lazım: TuxCare ELS ile birkaç ay satın al, köklü bir plan yap.
  • Bulut ortamı: AWS, Azure veya GCP üzerindeysen RHEL veya Rocky Linux AMI/image’larına geçmek en kolay yol.

Sonuç

CentOS 7 EOL süreci artık gerçek ve geçiş kaçınılmaz. İyi haber şu: Rocky Linux ve AlmaLinux gibi güçlü alternatifler mevcut, ELevate gibi araçlar göç sürecini önemli ölçüde kolaylaştırıyor ve topluluk desteği son derece güçlü.

Tavsiyem şu: Önce envanter çıkar, tüm CentOS 7 sistemlerini belgele. Sonra risk bazlı bir önceliklendirme yap; internete açık ve kritik sistemler ilk sırada olsun. Staging ortamında göç sürecini test et, sonra prodüksiyona geç. Temiz kurulum her zaman yerinde geçişten daha öngörülebilir sonuçlar verir, fakat ELevate de birçok senaryoda gayet iyi çalışıyor.

Geçişi erteleyen her gün, desteklenmeyen bir işletim sisteminde çalışmanın getirdiği riski büyütüyor. 2024 başında başlayan bu süreçte artık “henüz vakit var” deme lüksümüz kalmadı.

Yorum yapın