[ OK ]Kernel başlatılıyor...
~/im/blog
Beni İşe Alın

Konuşalım

Çözülmesi gereken bir altyapı probleminiz mi var veya projeniz için desteğe mi ihtiyacınız var? Yeni projeler için bana ulaşabilirsiniz.

İletişime geç

Bağlantılar

Beni sosyal medyada ve profesyonel ağlarda bulun.

© 2026 Irfan Miral. Tüm hakları saklıdır.Geliştiren:Irfan Miral
Gizlilik PolitikasıŞartlar & Koşullar
Ana SayfaHizmetlerHakkımda/ÖzgeçmişBlogİletişimAraçlar
2026-01-08• 5 dk okuma süresi

Her Yeni Sunucuda Tekrar Kullandığım Bash Betikleri

DevOps Bash Linux Administration Automation

Reklam

Devraldığım her sunucuya—ister sıfır bir VPS olsun, ister müşterinin yıllardır çalıştırdığı bir makine olsun—aynı küçük betik setini /usr/local/bin dizinine bırakırım.

Hiçbiri öyle çok zekice veya karmaşık şeyler değil. Beş dakikada yazıp unutacağınız türden şeyler. Buna rağmen, ufak güncellemeler haricinde bu betikleri yıllardır gittiğim her yere taşıyorum. Çünkü kendilerini defalarca kez amorti ettiler.

1. "Bu sunucu ne alemde" anlık görüntüsü

Yeni veya aşina olmadığım bir sunucuda çalıştırdığım ilk şey, hızlı bir genel durum (snapshot) betiğidir. Disk kullanımını, belleği, işlemci yükünü (load average), en çok bellek tüketen işlemleri ve ağ portlarında dinlemede olan her şeyi ekrana basar:

#!/bin/bash
# server-snapshot.sh
echo "== Uptime & Load =="
uptime

echo -e "\n== Disk Usage =="
df -hT --total | grep -E '^(Total|/dev)'

echo -e "\n== Memory =="
free -h

echo -e "\n== Top 5 Memory Consumers =="
ps aux --sort=-%mem | head -6

echo -e "\n== Listening Ports =="
ss -tulpn | grep LISTEN

Elle yazamayacağınız hiçbir şey yok. Ancak tam olarak hatırlamadığınız bir sunucuya her girişinizde beş ayrı komutu tek tek yazmak, bir şeylerin gözden kaçmasının tam olarak bir numaralı sebebidir. Tek bir betik, tek bir bakış ve tek bir ayar dosyasına bile dokunmadan önce makinenin zihinsel bir modeli kafamda oluşmuş olur.

2. Diski gerçekten neyin yediğini bulmak

"Disk dolu" alarmı, en sık aldığım uyarılardan biridir. Ve bunun sebebi neredeyse hiçbir zaman insanların beklediği yer çıkmaz. Bu betik root'tan aşağı doğru iner, dizinleri boyutuna göre sıralar ve sizi binlerce satır çıktıyla boğmamak için mantıklı bir derinlikte durur:

#!/bin/bash
# disk-hogs.sh
du -ahx --max-depth="${1:-3}" / 2>/dev/null | sort -rh | head -25

Parametre vermeden çalıştırırsanız üç kademe derine iner. Bir sayı verirseniz o kadar derine iner. On vakadan dokuzunda sorunun kaynağı rotasyona girmemiş loglar, birinin orada unuttuğu eski bir yedek veya canlı sunucuya bir şekilde sızmayı başarmış başıboş bir node_modules dizinidir.

3. Gösterge paneli (dashboard) olmadan sertifika süresi kontrolü

Özellikle daha küçük müşteri kurulumlarında her site janjanlı bir izleme (monitoring) altyapısının arkasında çalışmaz. Bu tür durumlar için, bir domain listesi üzerinde dönen hızlı bir döngü bana her SSL sertifikasında tam olarak kaç gün kaldığını söyler:

#!/bin/bash
# cert-check.sh
while read -r domain; do
  expiry=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
    | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(( ($(date -d "$expiry" +%s) - $(date +%s)) / 86400 ))
  printf "%-35s %s days\n" "$domain" "$days"
done < domains.txt

Her müşteri için her satırında bir hostname olan bir domains.txt tutarım ve bunu aylık olarak çalıştırırım. Let's Encrypt genelde yenilemeleri otomatik olarak hallettiği için, bu betiğin asıl işi arka planda sessizce patlayan yenileme işlemlerini yakalamaktır.

4. Logları ve journal şişkinliğini temizlemek

systemd journal'ı ve uygulama logları, birkaç ay içinde diski sessizce doldurma eğilimindedir. Ortada bir "gizemli" disk kullanımı problemi avına çıkmadan önce şu temizlik betiğini çalıştırırım:

#!/bin/bash
# log-cleanup.sh
journalctl --vacuum-time=2weeks
find /var/log -name "*.gz" -mtime +30 -delete
find /var/log -name "*.log.*" -mtime +30 -delete

Kasıtlı olarak muhafazakar bir şekilde ayarlanmıştır. İki haftalık journal logları ve 30 günlük rotasyona girmiş uygulama logları, neredeyse her türlü hata ayıklama (debug) oturumu için fazlasıyla yeterlidir; aynı zamanda diskin adım adım %100'e doğru sürünmesini engeller.

Hepsini tek bir yerde tutmak

Bunların hepsi, yönettiğim her sunucuya kopyaladığım (clone) küçük bir git reposunda yaşar:

git clone https://github.com/yourname/server-toolkit /opt/toolkit
ln -s /opt/toolkit/*.sh /usr/local/bin/

Burada asıl önemli olan betiklerin kendisi değil. Önemli olan kısım, aylardır giriş yapmadığım bir sunucuda gece saat 11'de bir şeyler ters göründüğünde boş bir terminal ekranıyla baş başa kalmamaktır. Her zaman çalıştırdığım o aynı komutları çalıştırıyor olmanın verdiği aşinalık, betiklerin tekil değerinden çok daha değerlidir.

Reklam

Yardıma mı ihtiyacınız var?

Eğer Sunucu Yönetimi ve Bakımı işini sizin yerinize birinin halletmesini tercih ederseniz, benim asıl işim tam olarak bu.

İletişime Geç
ÖncekiCyberPanel Güvenlik Olayı: Kötü Amaçlı Yazılım Temizliği ve Sunucu SıkılaştırmaSonraki Küçük Projeler İçin Kurtarıcı GitLab CI/CD Pipeline'ı