Paket Bağımlılığı Çakışması: Güncelleme Neden Sistemi Bozar?
Rutin bir güvenlik güncellemesi çalıştırdınız. Paket yöneticisi bir kütüphaneyi yükseltti ve o kütüphaneye bağlı üç servis birden çalışmayı bıraktı. Güncellemede hata yoktu — bağımlılık zinciri kırıldı.
Bu yazı, paket bağımlılıklarını ve güvenli güncellemeyi ele alıyor.
Bağımlılık Zinciri
Bir paket tek başına çalışmaz:
- Kütüphanelere bağımlıdır.
- O kütüphaneler de başkalarına.
- Sürüm aralıkları tanımlıdır.
- Aralıklar çakışabilir.
Dördüncü madde sorunun kaynağıdır: iki farklı uygulama aynı kütüphanenin farklı sürümlerini gerektirdiğinde sistem paket yöneticisi bunu çözemez — birini memnun etmek diğerini bozar.
Bu duruma bağımlılık cehennemi denir.
Üçüncü madde ise esneklik sağlar ama sınırsız değildir; her paket hangi sürüm aralığıyla çalışacağını bildirir.
İki Farklı Paket Dünyası
| Tür | Kapsamı |
|---|---|
| Sistem paketleri | Tüm sunucu geneli |
| Dil paketleri | Proje bazında |
İkisini karıştırmamak gerekir çünkü çakışma çoğunlukla ilkinde yaşanır: sistem paketleri tüm sunucuda tek bir sürümle bulunur — iki uygulama farklı sürüm isterse çözüm yoktur; dil paketleri ise her proje kendi klasöründe farklı sürüm tutabilir.
Bu nedenle uygulama bağımlılıklarını mümkün olduğunca proje seviyesinde tutmak sorunu baştan önler.
Sistem paketleri yalnızca gerçekten sistem geneli olması gerekenler için kullanılmalıdır.
Güncelleme Türleri
- Güvenlik güncellemesi. Dar kapsamlı.
- Küçük sürüm güncellemesi. Uyumlu olmalı.
- Büyük sürüm güncellemesi. Kırıcı değişiklik içerebilir.
- Dağıtım sürümü yükseltme. En riskli.
Birinci madde en güvenli olanıdır ve düzenli uygulanmalıdır: güvenlik güncellemeleri genellikle yalnızca açığı kapatan yamayı içerir ve sürüm numarası değişmez — bu, uyumluluğu koruyarak koruma sağlayan tasarımdır.
Bu nedenle güvenlik güncellemelerini ertelemek için teknik bir gerekçe genellikle yoktur.
Üçüncü madde ise dikkat gerektirir ve değişiklik notları okunmalıdır.
Dördüncü madde ise ayrı bir proje gibi planlanmalı, test ortamında denenmelidir.
Çakışmayı Önlemek
| Yöntem | Etkisi |
|---|---|
| Proje bazlı bağımlılık | İzolasyon sağlar |
| Konteyner kullanmak | Tam ayrışma |
| Sürüm sabitleme | Öngörülebilirlik |
| Depo kısıtlama | Beklenmedik kaynak engellenir |
Dördüncü satır sık atlanan bir önlemdir: üçüncü taraf depolar aynı paketin farklı sürümlerini sunabilir ve paket yöneticisi beklenmedik bir kaynaktan güncelleme çekebilir — hangi paketin hangi depodan geleceğini sınırlamak bu sürprizi önler.
Bu, özellikle özel yazılım depoları eklenmiş sunucularda önemlidir.
Üçüncü satır ise kararlılık sağlar ama güvenlik güncellemelerini de engelleyebileceği için dikkatli kullanılmalıdır.
İkinci satır ise en kesin çözümdür; her uygulama kendi bağımlılıklarıyla birlikte paketlenir.
Güncelleme Öncesi
- Neyin güncelleneceğini görün.
- Değişiklik notlarını okuyun.
- Anlık görüntü veya yedek alın.
- Test ortamında deneyin.
Birinci madde çoğu paket yöneticisinde mümkündür ve mutlaka yapılmalıdır: güncelleme öncesi hangi paketlerin değişeceğini listelemek, beklenmedik bir büyük sürüm yükseltmesini işlem başlamadan fark etmenizi sağlar.
Basit bir güvenlik güncellemesi sandığınız işlem, bir veritabanı sürümünü yükseltiyor olabilir.
Üçüncü madde ise sanal sunucularda kolaydır ve geri dönüş imkânı verir.
Dördüncü madde ise kritik sistemlerde zorunludur.
Geri Alma
- Önceki sürüme düşürme.
- Anlık görüntüden dönüş.
- Yedekten geri yükleme.
Birinci madde her zaman mümkün değildir ve bir tuzağı vardır: bir paketi eski sürüme düşürmek, o güncellemeyle birlikte gelen veritabanı veya yapılandırma değişikliklerini geri almaz — paket eskir ama veri yeni biçimde kalır ve uygulama açılmaz.
Bu özellikle veritabanı sunucularında yaşanır.
İkinci madde bu sorunu tamamen çözer çünkü tüm sistemi o ana döndürür.
Bu nedenle riskli güncellemeler öncesi anlık görüntü almak en güvenli yaklaşımdır.
Otomatik Güncelleme
| Kapsam | Değerlendirme |
|---|---|
| Yalnızca güvenlik | Önerilir |
| Tüm güncellemeler | Riskli |
| Otomatik yeniden başlatma | Çok dikkatli |
Birinci satır iyi bir dengedir: yalnızca güvenlik güncellemelerini otomatikleştirmek, açıkların aylarca açık kalmasını önler ve uyumluluk riski düşük olduğu için kabul edilebilir bir tercihtir.
Elle güncelleme yapılan sunucularda güncellemeler genellikle ertelenir ve unutulur.
Üçüncü satır ise beklenmedik kesinti üretebilir. Çekirdek güncellemesi sonrası otomatik yeniden başlatma, yoğun bir anda gerçekleşebilir.
Bu ayar kullanılacaksa zaman penceresi tanımlanmalıdır.
Güncelleme Sonrası Servisler
- Eski kütüphane bellekte kalabilir.
- Servis yeniden başlatılmalıdır.
- Yeniden başlatılmayan servis korumasızdır.
Üçüncü madde güvenlik güncellemelerinde kritik bir eksikliktir: bir kütüphanedeki açığı kapatan güncelleme kurulsa bile, o kütüphaneyi zaten belleğe yüklemiş çalışan servisler eski ve açık sürümü kullanmaya devam eder — yeniden başlatılmadıkça koruma devreye girmez.
Bu, güncelleme yapıldığı hâlde savunmasız kalmanın en yaygın nedenidir.
Çoğu dağıtım, yeniden başlatılması gereken servisleri listeleyen bir araç sunar.
Bu liste güncelleme sonrası kontrol edilmelidir.
Çekirdek Güncellemeleri
- Yeniden başlatma gerektirir.
- Eski çekirdek saklanır.
- Sorun çıkarsa eskiye dönülebilir.
İkinci ve üçüncü maddeler önemli bir güvenlik ağı sağlar: yeni çekirdek açılışta sorun çıkarırsa önyükleyici menüsünden bir önceki sürümle başlatabilirsiniz — bu, çekirdek güncellemelerini geri alınabilir kılar.
Bu nedenle en az bir eski çekirdek sürümü diskte tutulmalıdır.
Ancak bu menüye erişebilmek için konsol erişimi gerekir; uzaktan yalnızca ağ üzerinden bağlanıyorsanız bu seçenek kullanılamaz.
Birinci madde ise planlama gerektirir ve bakım penceresine alınmalıdır.
Güncelleme öncesi anlık görüntü alabilmek riski büyük ölçüde azaltır; VDS kiralama hizmeti panelinden anlık görüntü alıp güncelleme sonrası gerekirse geri dönebilirsiniz.
Sonuç
Bağımlılık çakışmasının kökeni tektir: sistem paketleri tüm sunucuda tek sürümle bulunur ve iki uygulama farklı sürüm isterse çözüm yoktur. Bu yüzden uygulama bağımlılıklarını proje seviyesinde tutun. Güncelleme öncesi neyin değişeceğini mutlaka listeleyin — basit sandığınız bir işlem bir veritabanı sürümünü yükseltiyor olabilir. Ve sonrasında servisleri yeniden başlatmayı unutmayın: kütüphaneyi belleğe yüklemiş servisler açık sürümü kullanmaya devam eder.
Sıkça Sorulan Sorular (SSS)
Bağımlılık çakışması nasıl oluşur?
İki uygulama aynı kütüphanenin farklı sürümlerini gerektirdiğinde. Sistem paketleri tüm sunucuda tek sürümle bulunduğu için birini memnun etmek diğerini bozar. Çözüm, uygulama bağımlılıklarını proje seviyesinde veya konteyner içinde tutmaktır.
Güvenlik güncellemelerini ertelemeli miyim?
Genellikle hayır. Güvenlik güncellemeleri çoğunlukla yalnızca açığı kapatan yamayı içerir ve sürüm numarası değişmez — uyumluluğu koruyarak koruma sağlayacak şekilde tasarlanır. Bunları otomatikleştirmek de kabul edilebilir bir tercihtir.
Güncelledim ama hâlâ savunmasız mıyım?
Servisleri yeniden başlatmadıysanız evet. Kütüphaneyi zaten belleğe yüklemiş çalışan servisler eski ve açık sürümü kullanmaya devam eder. Çoğu dağıtım yeniden başlatılması gereken servisleri listeleyen bir araç sunar; güncelleme sonrası bu listeyi kontrol edin.
Güncellemeyi geri alabilir miyim?
Paketi eski sürüme düşürmek her zaman yetmez — o güncellemeyle gelen veritabanı veya yapılandırma değişiklikleri geri alınmaz, paket eskir ama veri yeni biçimde kalır. En güvenli yol, riskli güncellemeler öncesi anlık görüntü almak ve gerekirse tüm sistemi o ana döndürmektir.
