Bu rehber neyi çözer?
Patch yönetimi yalnız apt/dnf komutu değildir; envanter, risk önceliği, test, bakım penceresi, reboot, rollback ve doğrulama kurumsal sürecin parçasıdır.
Repository yönetimi
Resmi/onaylı repository kullanılmalı, üçüncü parti kaynak sayısı minimum tutulmalı ve signing key yaşam döngüsü izlenmelidir.
Repository değişikliği supply-chain riskine dahil edilmelidir.
Security update ve normal update
Kritik güvenlik yamaları risk bazlı SLA ile ele alınabilir; özellik yükseltmeleri farklı cadence kullanabilir.
Kernel, glibc ve kritik servislerde restart/reboot etkisi önceden bilinmelidir.
Test ve bakım penceresi
Üretime benzer staging/pilot grubu uyumsuzlukları erken yakalar.
Cluster/HA sistemlerde mimari uygunsa node-by-node patch uygulanabilir.
Doğrulama ve rollback
Patch sonrası servis sağlık, port/endpoint, log ve monitoring kontrolleri yapılmalıdır.
Rollback yalnız snapshot değildir; config, package version ve uygulama data uyumluluğu birlikte düşünülmelidir.
Sık Sorulan Sorular
Otomatik update açılmalı mı?
Güvenlik update otomasyonu faydalı olabilir; kritik sunucularda test, reboot ve bakım penceresiyle birlikte tasarlanmalıdır.
Kernel update reboot ister mi?
Yeni kernel’in aktif olması genellikle reboot gerektirir; bazı dağıtımlar seçili düzeltmeler için live patch sunar.
Üçüncü parti repository neden riskli?
Bağımlılık, imza anahtarı ve supply-chain riskini kurumun kontrol alanının dışına genişletebilir.
Kaynaklar ve teknik referanslar
Linux Sunucu Projenizi Değerlendirelim
Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.
Mimari ve çalışma modeli
Linux yama yönetiminde paket deposu, sürüm politikası, kernel ve çalışan servisler birlikte değerlendirilir. Paket yüklenmesi bellekteki eski süreci her zaman değiştirmez. Dağıtım backportu upstream sürüm numarasından farklı görünebilir; güvenlik düzeltmesi üretici advisorysiyle doğrulanmalıdır. Otomatik güncelleme rol bazında test ve reboot politikasıyla yönetilir.
- 1Depo ve advisory
- 2Pilot paket değişimi
- 3Restart/reboot
- 4Çalışan sürüm ve sağlık
Tasarım parametreleri
- Repo güveni
- İmzalı paket, güvenilir repo ve pin/versionlock politikasını belgeleyin; güvenlik backportlarını dikkate alın.
- Çalışan sürüm
- Paket kurulumu sonrası process restart ve kernel reboot ihtiyacını takip edin.
- Servis ve kullanıcı
- Gerçek servis kullanıcısını, grup üyeliğini, çalışma dizinini ve gerekli yetkileri listeleyin. Root ile başarılı test sınırlı hesapla çalışmayı kanıtlamaz.
- Depolama ve kalıcılık
- Mount, dosya sistemi, inode ve kalıcı veriyi birlikte kontrol edin. Yeniden başlatma ve yeniden oluşturma aynı test değildir.
- Ağ ve güvenlik katmanı
- Dinlenen arayüz, firewall, TLS ve SELinux/AppArmor politikalarını ayırın. Bir katmandaki engel başka katmanın ayarıyla çözülmez.
- Paket ve işletim yöntemi
- Sürüm, depo, güncelleme yöntemi ve servis bağımlılıklarını belgeleyin. Bakım sonrası reboot ve uygulama doğrulamasını planlayın.
Hesap ve uygulama örneği
Örnek pilotta paket değişikliği öncesi servis sağlık sonucu kaydedilir. Güncelleme, gerekirse reboot ve aynı sağlık testi sırasıyla uygulanır. Kernel sürümü ile çalışan kernel ayrılır. Paket downgradeinin veri formatını veya bağımlılıkları geri almadığı durumlar için uygulama kurtarma planı gerekir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
uname -r
cat /etc/os-releaseHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Güncelleme sonrası bağımlılık bozuldu | Repo karışımı veya desteklenmeyen paket sürümü olabilir. | Paket kaynaklarını, dependency çözümünü ve önce/sonra sağlık testini karşılaştırın. |
| Servis aktif ama yanıt vermiyor | Process sağlığı, port dinleme ve uygulama sağlığı farklı kontrollerdir. | Yerel sağlık kontrolünü uzak istemci isteğiyle karşılaştırın; log ve bağımlılık durumunu inceleyin. |
| Dosya yazılamıyor | İzin, ACL, read-only mount, inode veya disk doluluğu etkili olabilir. | Servis kimliğiyle dizin zincirini ve mount durumunu doğrulayın; izinleri topluca açmayın. |
| Reboot sonrası yapılandırma kayboldu | Geçici mount, runtime ayarı veya yanlış yapılandırma kaynağı kullanılmış olabilir. | Kalıcı ayarı ve açılış sırasını kontrol edin; temiz reboot testini tekrarlayın. |
Kabul ve doğrulama kontrolleri
- Backport kanıtını, çalışan sürümü ve uygulama sağlık sonucunu birlikte saklayın.
- Servisi tanımlanan sınırlı kimlikle çalıştırıp temel iş akışını test edin.
- Reboot sonrasında mount, ağ, zaman ve uygulama durumunu doğrulayın.
- Yapılandırma, veri ve anahtarları ayrı kurtarma kalemleri olarak kaydedin.
- Güncellemeden önce ve sonra aynı sağlık testini çalıştırın.
- Ayrı hedefe geri yükleyerek platform bağımlılıklarını doğrulayın.
İlgili kavramlar
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
İzolasyon ile sanallaştırma ayrımı
Container ve sanal makine aynı izolasyon sınırını sunmaz. Containerlar host çekirdeğini paylaşırken sanal makineler konuk işletim sistemi çalıştırır. Rootless kullanım, namespace ve capability kısıtları riski azaltabilir; yapılandırma ve host güvenliği yine önemlidir. Image, çalışan container ve kalıcı volume ayrı yaşam döngülerine sahiptir. Image güncellemek veriyi yedeklemez. Testte process izinlerini, mountları, ağ erişimini ve kalıcı verinin yeniden oluşturma sonrasında korunmasını ayrı ayrı doğrulayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.