Ubuntu LTS Sürüm Yükseltme: do-release-upgrade Kullanım Kılavuzu

yazar

Sunucunu güncellemek hiç bu kadar heyecan verici olmamıştı, değil mi? Yıllarca stabil çalışan bir Ubuntu 20.04 LTS sunucusu, bir gün sürüm desteği bitmekte olan bir sistem haline geliyor ve sen de “hadi yükseltelim” diyorsun. Ama bu karar, özellikle production ortamında, dikkatli bir planlama gerektiriyor. do-release-upgrade aracı Ubuntu’nun resmi sürüm yükseltme mekanizması ve doğru kullanıldığında hayatı gerçekten kolaylaştırıyor. Bu yazıda adım adım, gerçek dünya senaryolarıyla bu süreci ele alacağız.

do-release-upgrade Nedir ve Nasıl Çalışır?

do-release-upgrade, Ubuntu’nun ubuntu-release-upgrader paketinin bir parçası olarak gelen ve sistemini bir LTS sürümünden diğerine yükseltmeni sağlayan resmi araç. Paketin arkasında Python tabanlı bir çerçeve var ve yükseltme sürecini şu adımlarla yönetiyor:

  • Mevcut sistem konfigürasyonunu analiz eder
  • Hedef sürüm için paket listelerini çeker
  • Çakışan paketleri tespit eder
  • Bağımlılıkları çözer
  • Paketleri sırasıyla günceller
  • Kernel ve kritik sistem bileşenlerini yeniler

Aracın en güzel tarafı, süreci tamamen interaktif yönetebilmesi ve bir şeyler ters gittiğinde seni uyarması. Kör bir apt dist-upgrade ile karşılaştırıldığında çok daha güvenli.

Ön Hazırlık: En Kritik Aşama

Yükseltmeye başlamadan önce yapman gereken birkaç temel hazırlık var. Bu adımları atlayan sysadminlerin ağzından sonradan pişmanlık dolu hikayeler dinledim.

Sistem Durumunu Kontrol Et

Önce mevcut sisteminizin sağlıklı olduğundan emin ol. Yarım kalmış paket kurulumları, bozuk bağımlılıklar yükseltme sürecini patlatabilir.

# Mevcut Ubuntu sürümünü kontrol et
lsb_release -a

# Sistemi tamamen güncelle
sudo apt update && sudo apt upgrade -y

# Bozuk paketleri kontrol et
sudo dpkg --audit

# Yarım kalmış kurulumları düzelt
sudo apt --fix-broken install

# Gereksiz paketleri temizle
sudo apt autoremove -y
sudo apt autoclean

Bu komutları çalıştırdıktan sonra hiçbir hata mesajı görmüyorsan devam edebilirsin. Eğer dpkg --audit sonuç döndürüyorsa önce o sorunları çöz.

Disk Alanı Kontrolü

Yükseltme süreci ciddi disk alanı gerektiriyor. Minimum 5-6 GB boş alan olması gerekiyor ama 10 GB üzeri olmasını öneririm.

# Disk kullanımını kontrol et
df -h

# En çok yer kaplayan dizinleri bul
du -sh /var/log/* | sort -rh | head -20

# Log dosyalarını temizle (isteğe bağlı)
sudo journalctl --vacuum-size=500M
sudo find /var/log -name "*.gz" -delete

/boot bölümü özellikle kritik. Eski kernel dosyaları burayı doldurmuş olabilir.

# Boot bölümündeki eski kernelleri temizle
sudo apt autoremove --purge

Kritik Servisleri ve Konfigürasyonları Yedekle

Bu adım asla atlanmamalı. Production sunucuda çalışıyorsan, yükseltme öncesi bir snapshot almak en doğrusu. Snapshot alamıyorsan en azından kritik dosyaları yedekle.

# Önemli konfigürasyon dosyalarını yedekle
sudo tar -czf /root/backup-configs-$(date +%Y%m%d).tar.gz 
  /etc/nginx/ 
  /etc/apache2/ 
  /etc/mysql/ 
  /etc/postgresql/ 
  /etc/ssh/sshd_config 
  /etc/fstab 
  /etc/hosts 
  /etc/crontab 
  /var/spool/cron/

# Kurulu paket listesini kaydet
dpkg --get-selections > /root/installed-packages-$(date +%Y%m%d).txt

# Servis durumlarını kaydet
systemctl list-units --type=service --state=active > /root/active-services-$(date +%Y%m%d).txt

SSH Bağlantısı için Önlem Al

Remote sunucularda yükseltme yapıyorsan, SSH bağlantısı koptuğunda süreci kurtarmak için screen veya tmux kullanmak şart. Bu, deneyimli sysadminlerin bile zaman zaman unuttuğu kritik bir nokta.

# Screen kur ve bir oturum başlat
sudo apt install screen -y
screen -S upgrade

# Ya da tmux kullan
sudo apt install tmux -y
tmux new-session -s upgrade

Oturum kopsa bile screen -r upgrade veya tmux attach -t upgrade ile geri bağlanabilirsin.

Ek güvenlik için alternatif bir SSH portu üzerinden backup bağlantısı da açabilirsin:

# sshd konfigürasyonuna geçici olarak ikinci port ekle
sudo sed -i 's/#Port 22/Port 22nPort 2222/' /etc/ssh/sshd_config
sudo systemctl restart sshd

# Firewall'da bu portu aç (UFW kullanıyorsan)
sudo ufw allow 2222/tcp

Release Upgrade Konfigürasyonu

Ubuntu hangi kanaldan yükseltme yapacağını /etc/update-manager/release-upgrades dosyasından belirliyor.

# Mevcut konfigürasyonu görüntüle
cat /etc/update-manager/release-upgrades

Çıktı şöyle görünmeli:

[DEFAULT]
Prompt=lts

Prompt değeri şunlar olabilir:

  • lts: Sadece LTS sürümlerine yükselt (önerilen production için)
  • normal: Her yeni Ubuntu sürümüne yükselt
  • never: Otomatik yükseltme önerilmesin

Production sunucular için lts kalmasını öneririm. Her 6 ayda bir yeni non-LTS sürüme geçmek gereksiz risk.

do-release-upgrade Parametreleri

Aracın temel parametrelerini bilmek önemli:

  • -d: Development sürümüne yükselt (test ortamları için)
  • -f DistUpgradeViewNonInteractive: Tamamen non-interaktif mod
  • -m server: Server modunda çalıştır (GUI bileşenlerini atla)
  • -m desktop: Desktop modunda çalıştır
  • –allow-third-party: Üçüncü taraf repoları da güncelle
  • -q: Quiet mod, daha az çıktı üretir

Yükseltme Sürecini Başlat

Hazırlıkları tamamladıktan sonra yükseltmeyi başlatabilirsin. Screen oturumunun içinde olduğundan emin ol.

# Standard yükseltme (interaktif)
sudo do-release-upgrade

# Server ortamları için (GUI yok, server modunda)
sudo do-release-upgrade -m server

# Eğer henüz yeni sürüm "normal" kanalda değilse ve zorlamak istiyorsan
sudo do-release-upgrade -d

Araç başladığında sana birkaç soru soracak. Genel akış şöyle işleyecek:

1. Adım: Ön kontroller – Mevcut sistem analiz edilir, gereksinimler kontrol edilir.

2. Adım: Yeni sürüm paket listesi indirilir ve analiz edilir.

3. Adım: Kaldırılacak, yüklenecek ve güncellenecek paketler listelenir. Burada “x packages are going to be removed” gibi bir çıktı görürsün. Dikkatli oku.

4. Adım: Paket indirme başlar. Bağlantı hızına göre bu aşama uzun sürebilir.

5. Adım: Paket kurulumu yapılır. Bu aşamada konfigurasyon dosyalarıyla ilgili sorular sorulur.

6. Adım: Sistem yeniden başlatılır.

Konfigürasyon Dosyası Çakışmaları: Ne Yapmalısın?

Yükseltme sırasında en sık karşılaşılan durum konfigürasyon dosyası çakışmaları. Araç sana şöyle bir soru sorar:

Configuration file '/etc/mysql/mysql.conf.d/mysqld.cnf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 Default is N : keep your currently-installed version

Burada D tuşuna basarak önce farkları incele. Özelleştirdiğin ayarların üzerine yazılacaksa N de ve kendi sürümünü koru. Konfigürasyon dosyasında değişiklik yapmamışsan Y diyerek yeni sürümü al.

Genel kural: Üretimde özelleştirilmiş konfigürasyon dosyaları için genellikle N (koru) seçeneği tercih edilir, sonra yeni sürümle manuel karşılaştırma yapılır.

Gerçek Dünya Senaryosu: 20.04’ten 22.04’e Nginx Sunucu Yükseltme

Bir müşterinin web sunucusunda yaşadığım gerçek bir senaryoyu aktarayım. Ubuntu 20.04 üzerinde Nginx, PHP-FPM ve MySQL çalışıyordu. İşte o gün attığım adımlar:

# Önce sistem güncellemesi
sudo apt update && sudo apt dist-upgrade -y

# Nginx konfigürasyonunu test et
sudo nginx -t

# MySQL durumunu kontrol et
sudo systemctl status mysql

# Mevcut PHP sürümünü not et
php --version

# Yükseltme öncesi yedek
sudo mysqldump --all-databases -u root -p > /root/all-databases-backup.sql

# Screen başlat
screen -S server-upgrade

# Yükseltmeyi başlat
sudo do-release-upgrade -m server

Yükseltme sonrasında ilk yaptığım şey kritik servislerin durumunu kontrol etmek oldu:

# Yükseltme sonrası servis kontrolü
sudo systemctl status nginx
sudo systemctl status mysql
sudo systemctl status php8.1-fpm  # Sürüm değişmiş olabilir

# Yeni PHP sürümünü kontrol et
php --version

# Nginx konfigürasyonunu test et
sudo nginx -t && sudo systemctl reload nginx

# Aktif dinleme portlarını kontrol et
sudo ss -tlnp

22.04’e geçince PHP 7.4 yerine PHP 8.1 default geldi. PHP-FPM socket path değiştiği için Nginx konfigürasyonunu güncellememiz gerekti. Bu tür değişiklikler için release notes’u önceden okumak çok önemli.

Sık Karşılaşılan Sorunlar ve Çözümleri

Sorun 1: “No new release found”

# Bu hatayı alıyorsan
sudo do-release-upgrade
# Checking for a new Ubuntu release
# No new release found.

# Çözüm: update-manager-core'u yeniden kur
sudo apt install update-manager-core
sudo do-release-upgrade

# Ya da development kanalını dene (dikkatli kullan)
sudo do-release-upgrade -d

Sorun 2: Üçüncü Taraf Repolar Yüzünden Takılma

PPa veya üçüncü taraf repolar yükseltme sırasında sorun çıkarır. Araç bunları otomatik disable eder ama bazen manuel müdahale gerekir.

# Tüm aktif repoları listele
ls /etc/apt/sources.list.d/

# Sorunlu repoları geçici devre dışı bırak
sudo mv /etc/apt/sources.list.d/problematic-repo.list 
        /etc/apt/sources.list.d/problematic-repo.list.bak

# Yükseltmeden sonra yeniden aktive et ve güncelle
sudo mv /etc/apt/sources.list.d/problematic-repo.list.bak 
        /etc/apt/sources.list.d/problematic-repo.list
sudo apt update

Sorun 3: Disk Alanı Yetersizliği Sırasında

Yükseltme ortasında disk dolar ve sistem kilitlenirse:

# /boot doluysa eski kernelleri temizle
sudo dpkg --list | grep linux-image
sudo apt remove --purge linux-image-5.4.0-XXX-generic

# /var/cache/apt/archives temizle
sudo apt clean

# Log dosyalarını temizle
sudo journalctl --vacuum-size=200M

Sorun 4: Yükseltme Yarıda Kesildi

SSH koptu ve yükseltme yarıda kaldıysa, sisteme erişim sağladıktan sonra:

# Yarım kalan kurulumları tamamla
sudo dpkg --configure -a

# Bozuk bağımlılıkları düzelt
sudo apt --fix-broken install

# Yükseltmeyi yeniden başlatmayı dene
sudo do-release-upgrade

Yükseltme Sonrası Yapılması Gerekenler

Sistem yeniden başladıktan sonra kapsamlı bir kontrol listesi işliyorum:

# Yeni sürümü doğrula
lsb_release -a
uname -r

# Servis durumlarını kontrol et
systemctl --failed

# Önemli servisleri tek tek kontrol et
for service in nginx apache2 mysql postgresql ssh; do
  if systemctl is-active --quiet $service; then
    echo "$service: RUNNING"
  else
    echo "$service: STOPPED or NOT INSTALLED"
  fi
done

# Açık portları kontrol et
sudo ss -tlnp

# Son boot loglarını kontrol et
sudo journalctl -b 0 --priority=err

# Depolama durumu
df -h

# Hafıza durumu
free -h

Üçüncü Taraf Repoları Güncelle

Yükseltme sırasında disable edilen repoları yeni sürüm için güncellemeyi unutma:

# Örneğin Docker reposunu güncelle
sudo rm /etc/apt/sources.list.d/docker.list

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | 
  sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) 
  signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] 
  https://download.docker.com/linux/ubuntu 
  $(lsb_release -cs) stable" | 
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io

Kernel ve Paket Temizliği

Yükseltme sonrası eski kernel ve gereksiz paketler sistemde kalır:

# Eski kernelleri ve gereksiz paketleri temizle
sudo apt autoremove --purge -y

# Paket cache temizle
sudo apt autoclean

# Orphan paketleri kontrol et (deborphan gerekli)
sudo apt install deborphan -y
sudo deborphan

Non-Interactive Yükseltme: CI/CD ve Otomasyonda Kullanım

Bazı durumlarda otomatik yükseltme yapmak gerekebilir, özellikle test ortamları veya image building süreçlerinde. Bu durumda non-interactive modu kullanabilirsin:

# Tamamen non-interaktif yükseltme
# DEBIAN_FRONTEND=noninteractive kritik!
export DEBIAN_FRONTEND=noninteractive

sudo -E do-release-upgrade -f DistUpgradeViewNonInteractive -m server

Ama şunu net söyleyeyim: Production ortamında non-interactive modu kullanmak risklidir. Konfigürasyon dosyası çakışmalarını otomatik çözecek ve beklenmedik değişiklikler yapabilir. Bu modu sadece iyi test edilmiş, otomatize pipeline’lar için kullan.

Yükseltme Planlaması: Zaman Çizelgesi

Deneyimlerime göre ideal bir yükseltme süreci şöyle planlanmalı:

Yükseltmeden 1 hafta önce:

  • Test ortamında yükseltmeyi dene
  • Uygulama uyumluluğunu kontrol et
  • Release notes’u oku
  • Yedekleri doğrula

Yükseltmeden 1 gün önce:

  • Son system update yap
  • Disk alanını kontrol et
  • Maintenance window belirle
  • Ekibi bilgilendir

Yükseltme günü:

  • Snapshot al
  • Screen/tmux başlat
  • Yükseltmeyi başlat
  • Yükseltme sonrası kontrolleri yap

Yükseltmeden 1 hafta sonra:

  • Sistem loglarını gözlemle
  • Performans metriklerini karşılaştır
  • Eski kernel ve paketleri temizle

Rollback Stratejisi

Ubuntu sürüm yükseltmesini geri almak resmi olarak desteklenmiyor. Bu yüzden rollback stratejin şunlardan biri olmalı:

  • Snapshot/Snapshot tabanlı geri alma: Hypervisor snapshot’ı (VMware, KVM, Proxmox) veya cloud snapshot (AWS AMI, Azure Image) en hızlı yol
  • Yedekten geri yükleme: Tam sistem yedeğin varsa buradan dön
  • Yeni sunucu kurulumu: En temiz yöntem, yeni bir sunucuya temiz kurulum yap ve servisleri taşı

Bu yüzden başta belirttiğim snapshot adımı hayati önem taşıyor. Snapshot imkanın yoksa en azından kritik verilerin yedeğini al ve yeni bir sunucu üzerinde rollback senaryosu pratiği yap.

Sonuç

do-release-upgrade doğru kullanıldığında son derece güvenilir bir araç. Ama “doğru kullanmak” demek sistematik bir ön hazırlık, dikkatli izleme ve kapsamlı yükseltme sonrası kontrol demek.

En önemli çıkarımları özetleyecek olursam: her zaman screen veya tmux içinde çalış, yükseltme öncesi mutlaka snapshot veya yedek al, konfigürasyon dosyası çakışmalarını körü körüne geçme, üçüncü taraf repoları sonradan güncelle.

Production ortamında bu süreçten kaçınmak yerine onu planlı yönetmek çok daha akıllıca. Desteksiz bir Ubuntu sürümü üzerinde çalışmak, düzenli yükseltme zahmetinden çok daha büyük güvenlik ve stabilite riskleri taşıyor. Bir sonraki LTS yükseltmenden önce bu rehberi tekrar gözden geçir ve kendi ortamına göre uyarla.

Yorum yapın