22 Mayıs 2019 Çarşamba

Linux tabanlı bir sistem kurulumu yaparken nelere dikkat etmeliyim

=========================================================================
Linux Sunucu Kurulum, Yapılandırma, Test ve Teslim Rehberi
=========================================================================

Sürüm: 2.0  -  Güncelleme: 24.07.2026
Hazırlayan: Remzi AKYÜZ
Kapsam: RHEL 8/9/10, türevleri ve Fedora sunucular (genel amaçlı + veritabanı/yoğun G/Ç iş yükleri)

Bu rehberdeki her madde iki soruya hizmet eder: (1) sorun ÇIKMASIN, (2) sorun çıkarsa
KANIT hazır olsun. 

BÖLÜM 1 — KURULUM AŞAMASI
---------------------------------------------------


--- 1.1 Disk düzeni ve LVM ---

- LVM'siz sistem düşünmeyin (istisnalar hariç). Tüm veri bölümleri LVM üzerinde olmalı.


- /boot için 2 GB ayırın. Eski kerneller genellikle temizlenmez; boot dolarsa
  yarım kalan kernel güncellemesi sistemi açılmaz hale getirebilir.

- Şu bölümlerin her biri AYRI bir LV olmalı:
  /var, /var/log, /var/log/audit, /var/log/journal, /tmp, /var/tmp,
  /var/spool (mail/squid gibi uygulamalar kullanır), /var/crash, /var/spool/abrt, /home.

  Gerekçe: kontrol edilmeyen günlük/geçici dosyalar kök bölümü doldurup sistemi
  durduramaz; log dolsa bile uygulama çalışmaya devam eder.

- /var/crash boyutu: kdump sıkıştırılmış vmcore üretir; kdumpctl estimate çıktısına
  göre boyutlandırın ve en az tahminin 2 katını ayırın (büyük RAM'li sistemlerde
  RAM kadar ayırmak pratik olmayabilir; 1 TB RAM'li sunucumuzda çalışan uygulamanın özelliğine göre ayarlama yapabilirsiniz. Teslim öncesi kdump TESTİYLE doğrulanır, bkz. 3.3).

- Volume group'un tamamını dağıtmayın: en az %10 boş bırakın (beklenmedik
  büyütmeler, snapshot ihtiyacı).

- Dosya sistemi: RHEL'de kök ve veri bölümleri XFS. Btrfs destekleyen dağıtımlarda
  (Fedora/SUSE) kök için btrfs + snapper düşünülebilir; RHEL'de btrfs desteklenmez.

- RAM yeterliyse /tmp tmpfs olabilir; ancak yoğun bellek tüketen iş yüklerinde
  (veritabanı) tmpfs /tmp önerilmez , /tmp'ye yazan bir süreç RAM baskısını artırır

- Swap: mümkünse ayrı bir disk/LUN üzerinde. Swap kullanımı görülüyorsa bu ayrıca
  çözülmesi gereken bir sorundur; swap'ın varlığı müdahale zamanı kazandırır.


--- 1.2 Ağ ---

- Kullanılacak arayüzleri STATİK yapılandırın; kullanılmayan arayüzlerde autoconnect
  kapatın: nmcli con mod <profil> connection.autoconnect no.

- Bonding/çok yollu ağ varsa teslim öncesi failover testi planlayın 

- FC SAN'lı sunucularda multipath yapılandırmasını kurulumda yapın; yol sayısı ve
  path checker ayarlarını depolama ekibiyle teyit edin.


--- 1.3 Kurulum tercihleri ---

- Minimal kurulum + ihtiyaç duyulan paket grupları. Kullanılmayan servis kurulmaz.
- Saat dilimi ve RTC'nin UTC tutulması kurulumda ayarlanmalı
  (timedatectl set-local-rtc 0). Saha dersi: RTC yerel saatte tutulursa journald'nin
  erken açılış kayıtları saatlerce kayık görünür ve olay incelemesini yanıltır.

- Kurulumda root parolası kasada saklanacak şekilde belirlenir; günlük kullanım
  kişisel hesap + sudo  iledir 



BÖLÜM 2 — KURULUM SONRASI YAPILANDIRMA
----------------------------------------------------------------------------


--- 2.1 Zaman senkronizasyonu ---

- chronyd etkin ve kurum NTP kaynaklarına bağlı olmalı (chronyc tracking ile teyit).


--- 2.2 Bellek yönetimi (yoğun bellek/G-Ç iş yükleri için KRİTİK) ---

/etc/sysctl.d/98-bellek-watermark.conf:

    # RAM'in ~%0,4'u (buyuk RAM'de NUMA dugumu basina ~1 GiB atomik/surucu rezervi)
    vm.min_free_kbytes = <RAM_kB * 0.004>      # 1 TB icin 4194304
    # kswapd uyanma bandi %2 (varsayilan %0,1) — erken uyanma alani
    vm.watermark_scale_factor = 200

- UYARI: min_free_kbytes RAM'in %5'ine yaklaştırılmamalı (ani OOM riski).
- Önce test ortamında uygulayın; 48-72 saat /proc/vmstat allocstall_*,
  pgscan_direct/pgscan_kswapd oranı ve PSI memory izleyin.

- Veritabanı sunucularında THP kapalı (transparent_hugepage=never) ve
  vm.swappiness=1 (uygulama üreticisinin önerisine göre).

- RHEL 9 MGLRU notu: lru_gen kaynaklı soft lockup çözüm makaleleri mevcuttur
  (Red Hat KB 7113642, 7077348). Yoğun bellek iş yüklerinde kernel'i güncel tutun;
  benzer belirti görülürse Red Hat vakasında bu makaleleri referans verin.


--- 2.3 Çökme teşhisi: kdump + panik tetikleyicileri (İKİSİ BİRLİKTE) ---

kdump tek başına yeterli değildir.

- kdump etkin: kdumpctl status → operational; crashkernel rezervasyonu doğrulanır
  (RHEL 9/10: kdumpctl reset-crashkernel).
- Panik tetikleyicileri — /etc/sysctl.d/99-panik-tetik.conf:

      kernel.softlockup_panic = 1     # CPU kilitlenmesi -> panik -> vmcore
      kernel.hung_task_panic = 0      # istege bagli; etkisi degerlendirilerek
      kernel.panic = 10               # panik sonrasi otomatik yeniden baslama (sn)
      kernel.unknown_nmi_panic = 1    # iLO/BMC'den NMI ile elle vmcore alma imkani

- Fiziksel sunucularda iLO/iDRAC "Generate NMI" prosedürü runbook'a yazılmalı
  (tam donmada kontrollü vmcore almanın tek yolu).

- Teslim öncesi kdump GERÇEKTEN test edilir (bkz. 3.3).


--- 2.4 Loglama ve denetim (kanıt altyapısı) ---

- Kalıcı journald: /var/log/journal dizini (ayrı LV, bkz. 1.1) +
  journald.conf'ta Storage=persistent, SystemMaxUse= ile tavan.

- auditd:
  - Servis etkin; kurallar: en azından kritik komutlar + execve kaydı (root dahil,
    auid!=unset filtresiz düşünülmemeli — kaza analizinde baş aktör çoğu zaman root'tur).

  - space_left_action/admin_space_left_action değerlerini gözden geçirin:
    SUSPEND, diski korur ama sessiz denetim körlüğü yaratır. Saha dersi: auditd
    açılışta hatalı "no space" tespitiyle SUSPEND'e düştü ve 21 gün hiçbir kayıt
    yazmadı. En azından SYSLOG + alarm kombinasyonunu değerlendirin.

  - Açılış sonrası auditd'nin GERÇEKTEN yazdığını doğrulayın (bkz. 3.4) ve
    audit.log tazeliğini izlemeye bağlayın (bkz. 2.7).

- Zaman damgalı ve anında yazılan shell history: HISTTIMEFORMAT +
  PROMPT_COMMAND='history -a' (readonly kilidiyle); kaza anında son komutlar kaybolmaz.

- sysstat: kurulu + etkin; örnekleme 1 dakika, HISTORY en az 28 gün.

- PCP (pmlogger): süreç bazlı geçmiş gerekiyorsa proc.*/hotproc kaydı açılarak.

- Merkezi log iletimi (rsyslog/filebeat): kurulduktan sonra ÇALIŞTIĞI doğrulanır
  ve failed durumu izlemeye bağlanır. 

--- 2.5 Güvenlik temeli ---

- SELinux enforcing — kapatmak yasak; öğrenmek zor olsa da kapatılan SELinux bir
  daha açılmıyor.

- Root ile SSH girişi kapalı (PermitRootLogin no); kişisel hesap + sudo.

- Dışa açık sunucularda firewalld + fail2ban; istekler servise ulaşmadan sınırlandırılır.

- Kullanılmayan servisler kapatılır; dinleyen portlar teslim dokümanına yazılır.


--- 2.6 Kritik servis koruması ---

- sshd/sssd gibi yaşam hattı servislerine OOM koruması:

      # /etc/systemd/system/sshd.service.d/100-OOMscore.conf
      [Service]
      OOMScoreAdjust=-1000

- Veritabanı/uygulama servislerinde Restart= politikası bilinçli seçilir ve
  bellek sınırları (MemoryMax) uygulama kotalarıyla uyumlu ayarlanır
  (OOM öldür-başlat döngüsü önlenir).

--- 2.7 İzleme entegrasyonu (yanlış metriğe güvenmeyin) ---

Zorunlu alarmlar:
- MemAvailable / kbmemfree (RAM'in %5'i altı: uyarı; %2 altı: kritik) — %memused DEĞİL.

- PSI memory (/proc/pressure/memory some/full avg10).

- multipathd: "path checkers took longer", "remaining active paths" log kalıpları.

- systemctl --failed birim sayısı (>0 uyarı).

- Log tazeliği: audit.log ve messages'ın SON kayıt yaşı (>1 saat: uyarı) —
  donmuş/askıda kayıt süreçlerini yakalar (auditd SUSPEND vakası).

- sar örnek sürekliliği: beklenen örnek gelmediyse uyarı (tıkalı sistemin dolaylı belirtisi).

- Disk doluluk: klasik %85/%95 eşikleri + /boot ayrıca.



BÖLÜM 3 — TESLİM ÖNCESİ TESTLER
-------------------------------

Her test, sonucuyla birlikte teslim dokümanına işlenir. "Kurulu" değil "ÇALIŞTIĞI
GÖSTERİLMİŞ" teslim edilir.


--- 3.1 Yeniden başlatma testi (en az 2 kez, biri güç çevrimli) ---

 - Temiz reboot + (mümkünse) güç çevrimi sonrası:

  - Tüm dosya sistemleri mount oldu mu (findmnt --verify; fstab hatası yok)?

  - systemctl --failed = 0 birim?

  - Tüm beklenen servisler ayakta, dinleyen portlar tam?

  - auditd gerçekten kayıt yazıyor mu? (bkz. 3.4 — açılış yarışı tam bu anda tetiklenir)


--- 3.2 Saat/zaman testi ---

- chronyc tracking senkron; timedatectl → RTC in local TZ: no.


--- 3.3 kdump/çökme testi (bakım penceresinde, veri yokken) ---

    kdumpctl status                 # operational
    echo 1 > /proc/sys/kernel/sysrq
    echo c > /proc/sysrq-trigger    # kontrollu panik

- Beklenen: sistem panik → kdump kernel → /var/crash/<tarih>/vmcore oluşur →
  otomatik yeniden başlar. vmcore boyutu not edilir, /var/crash LV boyutu teyit edilir.

- Bu test yapılmadan "kdump hazır" YAZILAMAZ


--- 3.4 Denetim/loglama kanıt testi ---

- Testi yapan kişi SSH ile girer, sudo  ile root yetkisi alır, birkaç komut çalıştırır; ardından:
  - ausearch -i -m USER_LOGIN,USER_CMD -ts recent → girişler ve komutlar görünüyor mu?
  - execve kuralı: ausearch -i -m EXECVE -ts recent → komutlar kayıtlı mı?
  - tail -1 ile audit.log'un son kayıt zamanı ŞU AN mı? (donmuş auditd tuzağı)
  - journalctl --since -1h kalıcı journal'dan geliyor mu (journalctl --disk-usage)?
  - history dosyasında zaman damgaları (#<epoch>) var mı?
- Merkezi log tarafında (ELK/Splunk) bu test kayıtlarının ULAŞTIĞI görülür.


--- 3.5 Bellek/dayanıklılık testi 
- Kontrollü yük (ör. stress-ng --vm/dosya okuma yüküyle page cache doldurma) altında:
  - MemAvailable alarmı tetikleniyor mu? PSI yükseliyor mu?
  - kswapd çalışıyor, sistem yanıt vermeye devam ediyor mu (allocstall patlamıyor)?

--- 3.6 Depolama/ağ yolu testleri (uygunsa) ---

- Multipath: tek yol çekilerek failover; multipath -ll'de failed yol kalmadığı teyidi.

- Bonding: aktif link çekme testi.


--- 3.7 Kabul taraması (otomatik kapı) ---

    sudo ./sunucu-inceleme.sh --gun 2 --arsivsiz




BÖLÜM 4 — TESLİM
----------------


--- 4.1 Teslim kontrol listesi (özet) ---

    [ ] Disk düzeni 1.1'e uygun (ayrı LV'ler, /boot 1G, VG %10 boş)  
    [ ] RTC=UTC + chrony senkron  
    [ ] Watermark/panik sysctl'leri uygulanmış (98-bellek-watermark, 99-panik-tetik)  
    [ ] kdump TESTLE kanıtlanmış (vmcore üretildi, tarih: ____)  
    [ ] Kalıcı journald + auditd (execve dahil) + zamanlı history + sysstat 1 dk  
    [ ] auditd açılış sonrası YAZIYOR (test kaydı: ____)  
    [ ] SELinux enforcing, root SSH kapalı, firewall kuralları belgelendi  
    [ ] Kullanılmayan arayüzlerde autoconnect kapalı; failed birim = 0  
    [ ] İzleme alarmları (MemAvailable, PSI, multipath, failed-unit, log tazeliği) TEST edildi  
    [ ] Merkezi log akışı doğrulandı  
    [ ] sunucu-inceleme.sh çıkış kodu 0 (rapor arşivi ekte)  
    [ ] Reboot testleri (2x) sorunsuz  


--- 4.2 Taban çizgisi (baseline) paketi ---

Teslimle birlikte arşivlenir; ileride "ne değişti?" sorusunun cevabıdır:

- sosreport çıktısı (teslim günü alınır),
- sunucu-inceleme.sh tam koşum raporu (tar.gz),
- paket listesi, dinleyen portlar, servis listesi, disk/LVM düzeni çıktıları.


--- 4.3 Teslim dokümanı içeriği ---

- Sunucu kimliği (donanım, OS, kernel, roller), disk/ağ şeması,
- Yapılan tüm yapılandırmaların listesi (bu rehberin madde numaralarıyla),
- Test sonuçları (tarih + yapan kişi + çıktı özetleri),
- İzleme/alarm listesi ve eskalasyon zinciri,
- Bilinen sınırlamalar / istisnalar (rehberden sapmalar gerekçesiyle yazılır).



Hiç yorum yok:

Yorum Gönder

Not: Yalnızca bu blogun üyesi yorum gönderebilir.

Ansible değişkenlerini doğru yerde tutmak

Ansible Değişkenlerini Doğru Yerde Tutmak Ansible · Değişkenler Ansible değişkenlerini doğru yerde tutmak Ansible'd...