Bu rehber neyi çözer?
Dağıtım seçimi bir marka tercihi değil; yaşam döngüsü, vendor uyumluluğu, paket sürümleri, destek modeli ve ekip yetkinliği kararıdır.
Seçim kriterleri
LTS/uzun destek süresi, güvenlik güncelleme politikası, paket depoları, donanım/uygulama sertifikasyonu, kurumsal destek ve ekip deneyimi temel kriterlerdir.
Birincil dağıtım standardı patch, hardening ve otomasyonu sadeleştirir.
Ubuntu Server
LTS sürümler, geniş dokümantasyon, cloud-init, AppArmor ve bulut ekosistemindeki yaygınlığıyla genel amaçlı sunucularda sık değerlendirilir.
Canonical destek seçenekleri ve Ubuntu Pro gibi modeller kurumsal gereksinimlerde ayrıca incelenebilir.
Debian
Kararlılık ve sade yapı isteyen ekipler için güçlü temeldir. Daha muhafazakâr paket sürümleri üretimde avantaj, yeni özellik ihtiyacında ise sınırlama olabilir.
Vendor sertifikasyonu ve ticari destek gereksinimi proje bazında kontrol edilmelidir.
RHEL tabanlı sistemler
Kurumsal destek, sertifikasyon ve belirli vendor gereksinimleri öne çıkıyorsa RHEL ekosistemi sık değerlendirilir.
SELinux, RPM/DNF ve kurumsal yaşam döngüsü yönetimi operasyon modelinin temel parçalarıdır.
Standartlaştırma
Çok sayıda dağıtım patch, monitoring, hardening ve troubleshooting maliyetini yükseltir.
Mümkünse bir ana ve bir ikincil dağıtım standardı belirlenmeli; istisnalar teknik gerekçeyle yönetilmelidir.
Sık Sorulan Sorular
Tek dağıtım tüm sunucular için yeterli mi?
Çoğu kurum büyük bölümü tek dağıtımda standardize edebilir; belirli vendor veya uygulamalar istisna gerektirebilir.
LTS neden önemli?
Uzun destek süresi üretim sunucularında upgrade ve güvenlik bakımını daha öngörülebilir yapar.
Dağıtım değiştirmek neden maliyetlidir?
Otomasyon, monitoring, hardening, dokümantasyon ve ekip bilgisi yeniden uyarlanır.
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
Dağıtım seçiminde destek yaşam döngüsü, paket kaynakları, uygulama sertifikasyonu ve ekip işletim yöntemi birlikte değerlendirilir. Aynı Linux çekirdeği bütün paket, sürücü ve yönetim araçlarının aynı olduğu anlamına gelmez. Rolling release ile uzun destekli sürüm farklı değişiklik ritmi yaratır. Ticari destek ve topluluk işletimi için sorumluluk modeli açık olmalıdır.
- 1Uygulama/donanım ihtiyacı
- 2Dağıtım yaşam döngüsü
- 3Pilot ve otomasyon
- 4Bakım standardı
Tasarım parametreleri
- Paket ve destek dönemi
- Kernel, uygulama paketi ve güvenlik güncelleme politikasını ayrı inceleyin; paket sürümü patch durumunu tek başına göstermez.
- Ekosistem uyumu
- Üretici sertifikasyonu, repo kaynağı ve ekip araçlarını doğrulayın; desteklenen major sürümü kaydedin.
- 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 üç aday dağıtımda aynı uygulamayı kurun, TLS ve backupı test edin, destek bitişini kaydedin. Paket adının farklı olmasıyla işlev eksikliğini karıştırmayın. Otomasyon ve rollback testi, yeni sistemin ekip tarafından sürdürülebilir olduğunu göstermelidir.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Uygulama bağımlılığı repoda yok | Seçilen dağıtım/sürüm üretici beklentisine uymuyor olabilir. | Destek matrisi ve imzalı repo seçeneklerini doğrulayın; rastgele binary indirmeyin. |
| 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
- Dağıtım, uygulama ve sürücü destek sürelerini ortak yaşam döngüsü tablosunda tutun.
- 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.
Birincil teknik dokümantasyon
Linux server nedir, hangi dağıtım seçilmeli?
Linux server, Linux tabanlı bir işletim sistemiyle dosya, web, e-posta, VPN, veritabanı veya kimlik hizmeti sunan fiziksel ya da sanal sunucudur. Dağıtım seçimini yalnız popülerliğe göre yapmayın. Uygulamanın desteklediği sürüm, güvenlik güncellemeleri, ekip deneyimi, yedekleme ve geri dönüş gereksinimleri birlikte değerlendirilmelidir.