CentOS 7 Sunucumu AlmaLinux'a Nasıl Taşırım? Yerinde Geçiş Rehberi

Sunucuya bağlanıp alışkanlıkla yum update yazıyorsunuz ve ekran şu satırla doluyor:

Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os
14: curl#6 - "Could not resolve host: mirrorlist.centos.org"

Bu bir ağ arızası değil. CentOS 7'nin desteği 30 Haziran 2024'te bitti; ayna listesi sunucuları kapatıldı ve paketler arşive (vault.centos.org) taşındı. Yani makineniz hâlâ çalışıyor, siteler açılıyor, hiçbir şey bozulmuş görünmüyor — ama uzun süredir tek bir güvenlik yaması almıyor. Türkiye'de bu tarifin üzerine oturan çok sayıda üretim sunucusu var: bir zamanlar kurulmuş, iyi çalıştığı için kimse dokunmamış ve şimdi internete açık halde yamasız duruyor.

İnternetteki Türkçe rehberlerin büyük bölümü ise CentOS 8 dönemine ait ve size doğrudan almalinux-deploy.sh çalıştırmanızı söylüyor. Elinizde CentOS 7 varsa o betik işinizi görmez; farklı bir yol, farklı bir araç ve iki ayrı ana sürüm atlaması gerekir. Daha da önemlisi, bazı makinelerde doğru cevap "dönüştürme" değildir.

Bu rehberde önce elinizdeki sürümü kesinleştireceğiz, sonra dört soruluk bir karar ağacıyla hangi yolun sizin makineniz için doğru olduğunu belirleyeceğiz. Ardından CentOS 8 için tek adımlık dönüştürmeyi, CentOS 7 için zorunlu iki ayaklı ELevate yolunu, panel kurulu sunucularda neden bambaşka bir aracın kullanılması gerektiğini ve son olarak yerinde dönüştürmenin yanlış karar olduğu durumları tek tek göreceğiz. Sonunda dönüşümün gerçekten tamamlandığını kanıtlayan bir doğrulama listesi var.

yum update Neden Çalışmıyor ve Elinizde Hangi Sürüm Var?#

Her şeyden önce hangi ana sürümde olduğunuzu kesinleştirin. CentOS 7 ile CentOS 8 arasındaki fark burada kozmetik değil; izleyeceğiniz yolun tamamını değiştirir.

# Ana sürüm ve tam sürüm numarası
cat /etc/redhat-release
cat /etc/os-release

# Çekirdek sürümü (el7 / el8 eki ana sürümü ele verir)
uname -r

# Mimari — ELevate yalnızca x86_64 destekler
uname -m

CentOS Linux release 7.9.2009 (Core) görüyorsanız 7 ailesindesiniz. CentOS Linux release 8.5.2111 görüyorsanız 8 ailesindesiniz ve işiniz çok daha kolay. CentOS Stream release 8 yazıyorsa dikkat: Stream, RHEL'in kararlı kopyası değil, RHEL'in öncesinde gelen geliştirme dalıdır ve dönüştürme senaryoları farklı işler.

Depoların arşive taşınmış olması, geçiş yapana kadar hiçbir paket kuramayacağınız anlamına gelmez. yum'u vault adresine yönlendirerek makineyi geçici olarak yeniden çalışır hale getirebilirsiniz — dönüşüm araçlarının kendisi de paket indirmek zorunda olduğu için bu adım çoğu zaman zorunludur:

# Önce mevcut repo dosyalarını yedekleyin
mkdir -p /root/repo-yedek && cp -a /etc/yum.repos.d/*.repo /root/repo-yedek/

# mirrorlist satırlarını kapatıp baseurl'u vault'a çevirin
sed -i 's/^mirrorlist=/#mirrorlist=/' /etc/yum.repos.d/CentOS-*.repo
sed -i 's|^#\?baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|' /etc/yum.repos.d/CentOS-*.repo

yum clean all && yum makecache

Bu, geçişi ertelemenin değil, geçişi yapabilmenin yoludur. Arşiv deposu yeni güvenlik yaması yayınlamaz; sadece kapanış tarihinde donmuş paketleri sunar.

Karar Ağacı: Hangi Yolu Seçeceğinizi Dört Soruda Belirleyin#

Komut yazmadan önce şu dört soruyu sırayla cevaplayın. Cevaplar, izleyeceğiniz bölümü doğrudan belirler.

Dördüncü soru, bu rehberin en çok atlanan ama en pahalıya mal olan maddesi. Ona ayrı bir bölüm ayırdım.

İki noktayı baştan kabul ederek başlayın. Birincisi: yerinde dönüştürmenin geri dönüşü yoktur. leapp upgrade ya da almalinux-deploy.sh bir kez tamamlandığında, sistemi eski haline döndüren bir geri alma komutu bulunmaz. Tek geri dönüş yolunuz işlem öncesinde alınmış tam bir snapshot veya imaj yedeğidir. İkincisi: ana sürüm atlaması tek adım kuralına tabidir. CentOS 7'den doğrudan AlmaLinux 9'a geçilmez; önce 8'e, sonra 9'a çıkılır. Bu kural, Ubuntu Server'da LTS sürümleri arasında yalnızca bir sonrakine atlayabilmenizle aynı mantığa dayanır.

CentOS 8'deyseniz: Tek Adımlık almalinux-deploy Yolu#

CentOS 8'in desteği 31 Aralık 2021'de bitti, ama teknik olarak şanslısınız: AlmaLinux 8 ile CentOS 8 aynı ana sürüm ve aynı RHEL 8 tabanına sahip. Yani ortada bir yükseltme değil, sadece paketlerin sağlayıcısının değiştirilmesi işi var. almalinux-deploy betiği tam olarak bunu yapar: depo tanımlarını ve GPG anahtarlarını değiştirir, centos-* release paketlerini AlmaLinux karşılıklarıyla takas eder ve kurulu paketleri AlmaLinux yapılarıyla senkronlar.

Betik CentOS 8.3 ve üzeri kurulumların yanı sıra Rocky Linux 8, Oracle Linux 8 ve RHEL 8 sistemlerini de hedefler. Aynı işi AlmaLinux 9 tarafında da yapar; yani zaten 9 tabanlı bir dağıtımdaysanız ana sürüm değişmeden sağlayıcı değişimi mümkündür.

# Sistemi güncel duruma getirin ve yeniden başlatın
dnf -y update && reboot

# Betiği indirip inceleyin (kök olarak indirilen bir betiği okumadan çalıştırmayın)
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
less almalinux-deploy.sh

# Dönüşümü başlatın
bash almalinux-deploy.sh

İşlem tipik bir sunucuda 10-20 dakika sürer ve sonunda yeniden başlatma ister. Betiğin en sevilecek yanı, uyumsuz bir durum tespit ettiğinde başlamadan durmasıdır; ekrana düşen uyarıyı geçiştirmeyin.

Rocky Linux tarafında karşılığı migrate2rocky (EL8 için) ve migrate2rocky9 (EL9 için) betikleridir. İki dağıtım arasında gündelik kullanımda anlamlı bir fark yoktur; ancak barındırma sektöründe bir tercih sebebi doğdu: cPanel ve WHM, 134 sürümüyle Rocky Linux 8 ve 9 desteğini sonlandırdı ve hedef dağıtım olarak AlmaLinux'u önerdi. cPanel kullanıyorsanız veya ileride kullanma ihtimaliniz varsa AlmaLinux'u seçmek sizi ikinci bir göçten kurtarır. İki ailenin genel karşılaştırması için sunucu için Linux dağıtımı seçimi yazısına bakabilirsiniz.

CentOS 7'deyseniz: Zorunlu İki Adımlı ELevate ve leapp Yolu#

CentOS 7'den AlmaLinux'a geçiş, sağlayıcı değişimi değil gerçek bir ana sürüm yükseltmesidir: RPM veritabanı, systemd, glibc, Python, OpenSSL ve paket yöneticisinin kendisi (yum yerine dnf) değişir. Bunu yapan araç, AlmaLinux'un ELevate projesidir; altında Red Hat'in yerinde yükseltme çatısı olan leapp çalışır, ELevate ise leapp'in RHEL dışı dağıtımları da tanımasını sağlayan veri kümelerini ve yamaları getirir.

ELevate tek adımlık bir araçtır: bir seferde yalnızca bir ana sürüm atlar. Desteklenen basamaklar 7 → 8, 8 → 9 ve 9 → 10 şeklindedir. CentOS 7'den doğrudan AlmaLinux 9'a geçiş desteklenmez. Hedefiniz 9 ise iki ayrı yükseltmeyi arka arkaya yapmanız, her birinden sonra sistemi doğrulamanız ve her birinin öncesinde ayrı snapshot almanız gerekir.

Birinci ayak: CentOS 7'den AlmaLinux 8'e#

# Sistemi son CentOS 7 paketleriyle güncelleyin
yum update -y && reboot

# ELevate deposunu ve leapp araçlarını kurun
yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
yum install -y leapp-upgrade leapp-data-almalinux

# ÖNCE analiz: hiçbir şeyi değiştirmez, sadece rapor üretir
leapp preupgrade

leapp preupgrade bu işin en önemli komutudur ve çıktısını okumadan devam etmek en sık yapılan hatadır. Rapor /var/log/leapp/leapp-report.txt dosyasına yazılır ve bulguları ağırlıklarına göre sınıflar: inhibitor (yükseltmeyi durdurur, çözülmeden devam edilemez), high (yüksek risk) ve bilgilendirme notları. Raporu satır satır gözden geçirin:

less /var/log/leapp/leapp-report.txt
grep -i "inhibitor\|risk factor: high" /var/log/leapp/leapp-report.txt

Bazı bulgular sizden açık bir onay ister; leapp bunları bir answerfile üzerinden sorar. Örneğin CentOS 7'den 8'e geçişte kaldırılacak bir PAM modülü için tipik onay şöyledir:

leapp answer --section remove_pam_pkcs11_module_check.confirm=True

Tüm engelleyiciler temizlendikten sonra asıl işlem başlar. Bu komut paketleri indirir, geçici bir yükseltme ortamı hazırlar ve yeniden başlatmanın ardından dönüşümü konsol üzerinde yürütür:

leapp upgrade
reboot

İşlem sırasında sunucu birkaç kez yeniden başlar ve toplamda bir saati aşabilir. Bu süre boyunca SSH erişimi kesilir; ekranı yalnızca sağlayıcınızın VNC veya KVM konsolundan izleyebilirsiniz. Konsol erişiminiz olduğunu işleme başlamadan önce test edin.

İkinci ayak: AlmaLinux 8'den AlmaLinux 9'a#

Birinci ayaktan sonra sistemi doğrulayın, servislerin ayakta olduğunu görün ve yeni bir snapshot alın. Ancak ondan sonra ikinci ayağa geçin:

dnf update -y && reboot

dnf install -y https://repo.almalinux.org/elevate/elevate-release-latest-el8.noarch.rpm
dnf install -y leapp-upgrade leapp-data-almalinux

leapp preupgrade
# raporu tekrar okuyun
leapp upgrade
reboot

İkinci ayak genellikle birincisinden daha temiz geçer, çünkü sistem artık RPM ve dnf dünyasında modern bir tabana oturmuştur. Yine de aynı disiplini uygulayın: rapor okunmadan upgrade çalıştırılmaz.

cPanel veya Plesk Varsa Genel ELevate'i Asla Çalıştırmayın#

Bu, rehberin en kritik uyarısı. cPanel kurulu bir CentOS 7 sunucusunda düz leapp upgrade çalıştırırsanız elinizde bozuk bir sistem kalır. Sebep basit: panel, kendi PHP sürümlerini (EasyApache ve ea-php* paketleri), kendi MySQL/MariaDB paketlerini, kendi Apache derlemesini ve kendi depo tanımlarını yönetir. Genel leapp bu paketleri tanımaz, dağıtımın standart karşılıklarıyla takas etmeye çalışır ve panelin bütün yapılandırmasını dağıtır.

Her panelin bu iş için kendi aracı var:

cPanel tarafında akış şöyledir; --check adımı yükseltmeyi engelleyecek durumları (desteklenmeyen depolar, uyumsuz veritabanı sürümü, eksik lisans) önceden listeler:

wget -O /scripts/elevate-cpanel \
  https://raw.githubusercontent.com/cpanel/elevate/release/elevate-cpanel
chmod 700 /scripts/elevate-cpanel

# Yalnızca kontrol — hiçbir değişiklik yapmaz
/scripts/elevate-cpanel --check

# Kontroller temizse başlatın
/scripts/elevate-cpanel --start

cPanel'in kendi belgeleri iki şartı özellikle vurgular: cPanel'in mevcut işletim sisteminiz için en güncel minör sürümünde olmalısınız ve hedef dağıtımla uyumlu bir MySQL/MariaDB sürümü çalıştırmalısınız. Pratikte bu, dönüşüme başlamadan önce veritabanı motorunu yükseltmeniz gerekebileceği anlamına gelir; yani sıra dışı bir bağımlılık zinciri doğar: veritabanı yükseltmesi, işletim sistemi yükseltmesinin ön koşulu haline gelir.

Plesk tarafında centos2alma aracı da aynı leapp altyapısını kullanır, ancak Plesk servislerini işlem sırasında durdurup dönüşüm sonrası ilk açılışta bir "finish" aşaması çalıştırır. Siteler ve e-posta bu süre boyunca kapalıdır; Plesk kendi belgelerinde tipik kesintiyi 30-60 dakika olarak verir.

EPEL dışındaki üçüncü parti depoları (Remi, IUS, Webtatic, MariaDB'nin kendi deposu, elle eklenmiş özel depolar) dönüşüm öncesinde kaldırmanız gerekir. Bunlar leapp'in bağımlılık çözümünü kilitleyen bir numaralı sebeptir.

Dönüşüm Öncesi Geri Dönüşü Mümkün Kılan Hazırlık#

Yerinde dönüştürmenin geri alma komutu olmadığı için, geri dönüş planınız işlem başlamadan önce hazır olmak zorunda. Aşağıdaki sıra pazarlık konusu değildir:

1. Sanal makine snapshot'ı alın. Sağlayıcınızın panelinden tam disk snapshot'ı alın ve alındığını doğrulayın. Bu, dönüşüm yarıda kalırsa tek kurtarıcınızdır.
2. Snapshot'tan bağımsız, sunucu dışında bir yedek alın. Snapshot aynı altyapıda durur; hipervizör tarafında bir sorun olursa ikisini birden kaybedersiniz. Veritabanlarını mysqldump ile ayrı bir dosyaya, site dosyalarını ve /etc altını başka bir makineye alın.
3. Yapılandırmayı yazıya dökün. rpm -qa > /root/paketler-oncesi.txt, systemctl list-unit-files --state=enabled > /root/servisler-oncesi.txt, crontab -l ve firewall-cmd --list-all çıktılarını saklayın. Dönüşümden sonra neyin eksik olduğunu bu listelerle bulacaksınız.
4. Konsol erişimini test edin. SSH kesildiğinde bakacağınız tek ekran VNC/KVM konsoludur; işlem günü çalışmadığını fark etmek çok geç olur.
5. Bakım penceresi ilan edin. İşlem panele ve makinenin yüküne göre yarım saatten bir buçuk saate kadar sürebilir. Bu sürede siteler ve e-posta kapalıdır.
6. Disk alanını kontrol edin. /boot bölümünde yeni çekirdek için yer, /var/lib/leapp için birkaç GB boş alan gerekir; df -h ile ikisini de doğrulayın.

Ne Zaman Yerinde Dönüştürme Yanlış Karardır#

Şimdi rehberin en dürüst kısmı. Yerinde dönüştürme cazip görünür, çünkü "hiçbir şeyi taşımam gerekmeyecek" diye düşünürsünüz. Ama leapp, sisteminizin paket yöneticisi tarafından bilinen kısmını dönüştürür. Paket yöneticisinin bilmediği ne varsa, dönüşümden sonra kendi başının çaresine bakmak zorundadır.

Aşağıdakilerden ikisi veya daha fazlası sizde varsa, dönüştürme yerine yeni bir AlmaLinux sunucusu kurup veriyi taşımak neredeyse her zaman daha hızlı, daha ucuz ve daha az riskli olur:

• /usr/local altına kaynaktan derlenmiş yazılımlar var (elle derlenmiş Nginx, PHP, ImageMagick, Python).
• Yıllar içinde birden çok üçüncü parti depo eklenmiş ve hangi paketin nereden geldiği artık belirsiz.
• Sunucuda ne çalıştığını tam olarak kimse bilmiyor; devraldığınız bir makine.
• Uygulamanız zaten çok eski bir PHP veya Python sürümüne bağımlı ve dönüşümden sonra yine elle uğraşacaksınız.
• Makine aynı anda birden çok rolü üstlenmiş: web, veritabanı, e-posta ve DNS tek kutuda.
• Sağlayıcınızda snapshot alma imkânınız yok.

Bu senaryolarda dönüştürme, mevcut karmaşayı yeni bir ana sürümün üzerine taşır; teknik borcu silmez, faiziyle devreder. Temiz kurulumun ek maliyeti bir sunucu kirasının birkaç günlük bedelidir. Buna karşılık eski makine dokunulmadan ayakta kalır, yani DNS'i çevirene kadar gerçek anlamda geri dönüş hakkınız olur — dönüştürmede olmayan tek şey budur. Bu yaklaşımın adım adım uygulaması için sunucudan sunucuya taşıma ve panel kullanıyorsanız cPanel hesap taşıma rehberlerine bakın.

Basit bir ölçüt: dönüşüm sonrası doğrulama listesini bir saatte tamamlayabileceğinizi düşünmüyorsanız, dönüştürmeyin.

Dönüşüm Sonrası Doğrulama Listesi#

Sunucu açıldı ve SSH'a düşüyorsunuz; iş bitmedi. Dönüşüm başarılı görünse bile geride CentOS kalıntısı paketler, başlamayan servisler ve yarım kalan bağımlılıklar olabilir. Sırayla doğrulayın:

# 1. Gerçekten AlmaLinux mı?
cat /etc/redhat-release
grep -E 'NAME|VERSION_ID' /etc/os-release

# 2. Geride CentOS paketi kaldı mı? (boş çıktı = temiz)
rpm -qa | grep -i centos
rpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -i centos

# 3. Eski ana sürümden kalan paket sayısı
rpm -qa | grep -c '\.el7\.'

# 4. Paket tutarlılığı ve senkron
dnf check
dnf distro-sync

# 5. Başlayamayan servisler
systemctl --failed

# 6. Önyükleme sırasındaki hatalar
journalctl -p 3 -xb --no-pager | head -50

Üçüncü komut sıfırdan büyük bir sayı dönerse hemen panik yapmayın; bazı el7 paketleri yalnızca uyumluluk katmanıdır. Ama listeyi rpm -qa | grep '\.el7\.' ile açıp içinde web sunucusu, PHP veya veritabanı görüyorsanız o paketleri elle yeniden kurmanız gerekir.

Ardından uygulama katmanını doğrulayın: web sunucusu ayakta mı, PHP-FPM havuzları çalışıyor mu, veritabanı bağlantısı açılıyor mu, cron görevleri hâlâ tanımlı mı, güvenlik duvarı kuralları korunmuş mu, SELinux hangi modda ve sertifika yenileme zamanlayıcısı aktif mi? Dönüşüm öncesinde aldığınız paketler-oncesi.txt ve servisler-oncesi.txt çıktıları burada karşılaştırma tabanınız olur.

Son olarak, artık yum değil dnf dünyasındasınız. Komut adları büyük ölçüde aynı kalsa da işlem geçmişi, modül akışları ve geri alma yetenekleri değişti; günlük kullanım için DNF ile paket yönetimi rehberi geçişten sonraki ilk haftada işinizi kolaylaştırır. Snapshot'ı ise en az bir hafta silmeyin; sorunların çoğu ilk günde değil, ilk yedekleme veya faturalandırma döngüsünde ortaya çıkar.

Sıkça Sorulan Sorular#

CentOS 7'den doğrudan AlmaLinux 9'a geçebilir miyim?#

Hayır. ELevate tek seferde yalnızca bir ana sürüm atlar; desteklenen basamaklar 7 → 8, 8 → 9 ve 9 → 10 şeklindedir. Hedefiniz AlmaLinux 9 ise önce 8'e yükseltmeniz, sistemi doğrulamanız, yeni bir snapshot almanız ve ancak ondan sonra ikinci yükseltmeyi başlatmanız gerekir. Doğrudan 9'u hedefleyen bir komut yoktur; zorlarsanız yarıda kalmış bir sistemle karşılaşırsınız.

AlmaLinux mu Rocky Linux mu seçmeliyim?#

Teknik olarak ikisi de RHEL ile ikili uyumludur ve gündelik kullanımda fark hissetmezsiniz. Ancak barındırma tarafında pratik bir ayrım doğdu: cPanel ve WHM, 134 sürümüyle Rocky Linux 8 ve 9 desteğini sonlandırdı ve hedef olarak AlmaLinux'u önerdi. cPanel kullanıyorsanız veya kullanma ihtimaliniz varsa AlmaLinux sizi ikinci bir göçten kurtarır. Panel kullanmıyorsanız seçim büyük ölçüde tercih meselesidir.

Dönüşüm yarıda kalırsa ne yaparım?#

Tek gerçek çözüm, işlemden önce aldığınız snapshot'a geri dönmektir. Yerinde dönüştürmenin geri alma komutu yoktur; yarım kalmış bir RPM veritabanını elle onarmak çoğu zaman temiz kurulumdan daha uzun sürer. Bu yüzden snapshot alınmadan ve konsol erişimi test edilmeden işlem başlatılmamalıdır. Snapshot alamıyorsanız yerinde dönüştürme sizin için uygun bir yöntem değildir.

cPanel sunucumda neden düz leapp çalıştıramıyorum?#

cPanel kendi PHP sürümlerini, kendi Apache derlemesini, kendi veritabanı paketlerini ve kendi depolarını yönetir. Genel leapp bu paketleri tanımaz ve dağıtımın standart karşılıklarıyla takas etmeye çalışır; sonuç, panelin ve üzerindeki tüm hesapların yapılandırmasının dağılmasıdır. Bunun yerine cPanel'in kendi elevate-cpanel betiğini kullanın; o betik leapp'i panelin farkında olacak şekilde sarmalar.

Yerinde dönüştürme yerine temiz kurulumu ne zaman seçmeliyim?#

Sunucuda kaynaktan derlenmiş yazılım, çok sayıda üçüncü parti depo veya kimsenin tam olarak bilmediği elle yapılmış müdahaleler varsa temiz kurulum daha güvenlidir. Yeni bir AlmaLinux sunucusu kurup veriyi taşımak, eski makineye hiç dokunmadığınız için gerçek bir geri dönüş hakkı verir; dönüştürme ise mevcut karmaşayı yeni ana sürüme taşır. Maliyeti birkaç günlük ek sunucu kirasıdır.

Dönüşümden sonra veritabanım ve PHP sürümüm de değişir mi?#

Evet, çoğu durumda değişir; ana sürüm atlaması dağıtımın sunduğu varsayılan paket sürümlerini de yükseltir. Bu yüzden geçiş öncesinde uygulamanızın hedef sürümdeki PHP ve MySQL/MariaDB ile uyumlu olduğunu doğrulayın. Özellikle veritabanı motorunun ana sürüm atlaması ayrı bir risk kalemidir ve kendi geri dönüş planını gerektirir; işletim sistemi geçişiyle aynı bakım penceresine sıkıştırmayın.

ELevate ile yükseltme sırasında sunucuya ne kadar süre erişemem?#

Düz bir leapp yükseltmesinde işlem birkaç yeniden başlatma içerir ve bir saati aşabilir; Plesk'in centos2alma aracı tipik kesintiyi 30-60 dakika olarak verir, cPanel tarafında da benzer bir aralık beklenir. Bu süre boyunca SSH kapalıdır ve tek görüş alanınız sağlayıcının konsoludur. Bakım penceresini gerçek süreden geniş tutun ve müşterilerinize önceden haber verin.