cmp Komutu ile İkili Dosya Karşılaştırma Rehberi

cmp komutu, Linux sistemlerde iki dosyayı byte düzeyinde karşılaştırmak için kullanılan güçlü bir araçtır. Sunucu ortamlarında yapılandırma dosyalarını ve ikili dosyaları doğrulamak için sıklıkla tercih edilir. Bu rehberde cmp komutunun tüm seçeneklerini ve gerçek dünya kullanım senaryolarını ele alıyoruz.

cmp Komutu: İkili Dosya Karşılaştırma Rehberi

Web sunucusu yönetiminde en sık karşılaştığım durumlardan biri şu: İki sunucu arasında bir dosyanın gerçekten aynı olup olmadığını doğrulamam gerekiyor. diff komutu metin dosyaları için harika çalışıyor ama binary dosyalarda, derlenmiş uygulamalarda veya konfigürasyon dosyalarının tam bit karşılaştırmasında işler biraz farklı. İşte tam bu noktada cmp komutu devreye giriyor.

Bu yazıda cmp komutunu web sunucusu yönetimi perspektifinden ele alacağız. Nginx binary’lerini karşılaştırmaktan SSL sertifikalarını doğrulamaya, deployment kontrolünden backup doğrulamaya kadar gerçek dünya senaryolarıyla konuyu işleyeceğiz.

cmp Nedir ve Neden Kullanmalısınız?

cmp (compare), iki dosyayı byte byte karşılaştıran bir Unix aracıdır. diff komutundan temel farkı şudur: diff metin odaklı çalışır ve satır bazlı karşılaştırma yapar, cmp ise her türlü dosyayı ham byte düzeyinde karşılaştırır.

Web sunucusu yönetiminde bu ayrım kritik öneme sahip:

  • Binary dosyalar: Nginx, Apache, PHP binary’leri
  • Sıkıştırılmış dosyalar: .tar.gz, .zip paketleri
  • SSL/TLS sertifikaları ve anahtar dosyaları
  • Statik web varlıkları: Minify edilmiş JS/CSS dosyaları
  • Veritabanı dump dosyaları
  • Docker image katmanları

diff bu dosyalara baktığında ya hata verir ya da anlamsız çıktı üretir. cmp ise sizi asla yanıltmaz.

Temel Kullanım

Basit Karşılaştırma

cmp dosya1 dosya2

Eğer dosyalar aynıysa hiçbir çıktı üretmez ve exit code 0 döner. Farklıysa ilk farklı byte’ın konumunu bildirir:

cmp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup
# Çıktı: /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup differ: byte 1024, line 45

Bu basit çıktı bile çok değerli bilgi içeriyor: Hangi byte ve hangi satırda fark başlıyor.

Önemli Seçenekler

cmp komutunun temel bayraklarını bilmek işinizi çok kolaylaştırır:

  • -l (–verbose): Farklı olan tüm byte’ları listeler
  • -s (–quiet): Sessiz mod, sadece exit code döner
  • -n NUM: Sadece ilk NUM byte’ı karşılaştırır
  • -i NUM: Baştan NUM byte atlanarak karşılaştırılır
  • -b: Farklı byte’ları yazdırılabilir karakter olarak gösterir

Gerçek Dünya Senaryoları

Senaryo 1: Deployment Doğrulama

Production sunucusuna yeni bir Nginx binary deploy ettiniz. Peki bu binary gerçekten doğru versiyon mu? MD5 hash kontrolü yerine doğrudan binary karşılaştırması yapabilirsiniz:

#!/bin/bash
# deploy-check.sh - Deployment sonrasi binary dogrulama

STAGING_BINARY="/tmp/nginx-new"
PROD_BINARY="/usr/sbin/nginx"
REFERENCE_BINARY="/opt/binaries/nginx-1.24.0-reference"

echo "=== Nginx Binary Karsilastirma ==="

# Staging ile reference karsilastir
if cmp -s "$STAGING_BINARY" "$REFERENCE_BINARY"; then
    echo "[OK] Staging binary referans ile eslesıyor"
else
    echo "[HATA] Staging binary referans ile eslesmıyor!"
    # Farkli byte sayisini bul
    DIFF_COUNT=$(cmp -l "$STAGING_BINARY" "$REFERENCE_BINARY" 2>/dev/null | wc -l)
    echo "[BILGI] Toplam $DIFF_COUNT byte farki tespit edildi"
    exit 1
fi

# Production'a kopyalandiktan sonra tekrar dogrula
if cmp -s "$PROD_BINARY" "$REFERENCE_BINARY"; then
    echo "[OK] Production binary basariyla deploy edildi"
else
    echo "[KRITIK] Production binary tutarsiz! Rollback gerekiyor!"
    exit 2
fi

echo "Deployment dogrulama tamamlandi."

Bu script deployment pipeline’ınıza kolayca entegre edilebilir. Exit code kontrolü sayesinde CI/CD sistemleriniz hataları otomatik yakalayabilir.

Senaryo 2: SSL Sertifika ve Anahtar Eşleşme Kontrolü

Web sunucusu yönetiminde en sinir bozucu hatalardan biri şudur: SSL sertifikası ile private key birbirine uymuyor. Bu durumu cmp ile dolaylı olarak kontrol edebilirsiniz. Daha da iyi bir yaklaşım ise sertifika ve anahtarın modulus değerlerini karşılaştırmaktır:

#!/bin/bash
# ssl-check.sh - SSL sertifika ve anahtar uyum kontrolu

CERT_FILE="/etc/nginx/ssl/domain.crt"
KEY_FILE="/etc/nginx/ssl/domain.key"
BACKUP_CERT="/backup/ssl/domain.crt"
BACKUP_KEY="/backup/ssl/domain.key"

echo "=== SSL Dosyasi Karsilastirma ==="

# Mevcut sertifikayi backup ile karsilastir
if cmp -s "$CERT_FILE" "$BACKUP_CERT"; then
    echo "[OK] Sertifika backup ile ayni"
else
    echo "[UYARI] Sertifika degismis, yenilenme tarihi kontrol edilmeli"
    # Sadece ilk 100 byte'i karsilastir (header kontrolu)
    echo "Header karsilastirmasi:"
    cmp -n 100 "$CERT_FILE" "$BACKUP_CERT" 2>&1
fi

# Private key backup ile karsilastir
# DIKKAT: Bu islem sadece guvenli ortamda yapilmali!
if cmp -s "$KEY_FILE" "$BACKUP_KEY"; then
    echo "[OK] Private key backup ile ayni"
else
    echo "[KRITIK] Private key degismis! Acil inceleme gerekli!"
    exit 1
fi

Önemli not: Private key dosyalarını karşılaştırırken bu işlemin güvenli bir ortamda yapıldığından emin olun. Key dosyalarını asla network üzerinden düz metin olarak taşımayın.

Senaryo 3: Web Varlıklarının CDN Doğrulaması

Statik dosyalarınızı CDN’e yüklediniz. Peki CDN’deki dosyalar gerçekten doğru mu? Özellikle minify edilmiş JavaScript ve CSS dosyaları için bu kontrol kritiktir:

#!/bin/bash
# cdn-verify.sh - CDN uzerindeki dosyalari yerel kopya ile dogrula

LOCAL_ASSETS="/var/www/html/assets"
CDN_CACHE="/tmp/cdn-cache"
FAILED_FILES=0
CHECKED_FILES=0

# CDN'den dosyalari indir ve karsilastir
echo "=== CDN Dosya Dogrulama Baslıyor ==="

for local_file in "$LOCAL_ASSETS"/*.{js,css,woff2,png,jpg}; do
    [ -f "$local_file" ] || continue
    
    filename=$(basename "$local_file")
    cdn_file="$CDN_CACHE/$filename"
    
    # CDN'den dosyayi indir (wget veya curl ile)
    wget -q "https://cdn.siteniz.com/assets/$filename" -O "$cdn_file" 2>/dev/null
    
    if [ ! -f "$cdn_file" ]; then
        echo "[EKSIK] $filename CDN'de bulunamadi"
        ((FAILED_FILES++))
        continue
    fi
    
    if cmp -s "$local_file" "$cdn_file"; then
        echo "[OK] $filename eslesiyor"
    else
        echo "[HATA] $filename CDN'de farkli!"
        # Fark detaylarini goster
        LOCAL_SIZE=$(stat -c%s "$local_file")
        CDN_SIZE=$(stat -c%s "$cdn_file")
        echo "      Yerel boyut: $LOCAL_SIZE bytes, CDN boyut: $CDN_SIZE bytes"
        ((FAILED_FILES++))
    fi
    ((CHECKED_FILES++))
done

echo ""
echo "=== Sonuc ==="
echo "Kontrol edilen: $CHECKED_FILES dosya"
echo "Hata: $FAILED_FILES dosya"

[ $FAILED_FILES -eq 0 ] && exit 0 || exit 1

Senaryo 4: Çoklu Sunucu Konfigürasyon Senkronizasyonu

Load balancer arkasında 5 web sunucunuz var ve hepsinin aynı konfigürasyona sahip olması gerekiyor. Bu senaryoda cmp ile hızlı bir kontrol yapabilirsiniz:

#!/bin/bash
# multi-server-sync-check.sh
# Tum sunucularda nginx.conf esitligini kontrol eder

MASTER_SERVER="web01"
SERVERS=("web02" "web03" "web04" "web05")
CONFIG_PATH="/etc/nginx/nginx.conf"
TEMP_DIR="/tmp/config-check"
MASTER_CONFIG="$TEMP_DIR/nginx.conf.master"

mkdir -p "$TEMP_DIR"

# Master sunucudan konfig al
echo "Master sunucudan ($MASTER_SERVER) konfig alınıyor..."
scp -q "$MASTER_SERVER:$CONFIG_PATH" "$MASTER_CONFIG"

if [ $? -ne 0 ]; then
    echo "[HATA] Master sunucuya baglanılamadı!"
    exit 1
fi

echo "=== Konfigürasyon Esitlik Kontrolu ==="
ALL_OK=true

for server in "${SERVERS[@]}"; do
    REMOTE_CONFIG="$TEMP_DIR/nginx.conf.$server"
    
    # Uzak sunucudan konfig al
    scp -q "$server:$CONFIG_PATH" "$REMOTE_CONFIG" 2>/dev/null
    
    if [ $? -ne 0 ]; then
        echo "[UYARI] $server sunucusuna baglanılamadı, atlaniyor"
        continue
    fi
    
    if cmp -s "$MASTER_CONFIG" "$REMOTE_CONFIG"; then
        echo "[OK] $server - Master ile esit"
    else
        echo "[FARK] $server - Master ile FARKLI!"
        # Hangi byte'da farklilastigini goster
        FIRST_DIFF=$(cmp "$MASTER_CONFIG" "$REMOTE_CONFIG" 2>&1)
        echo "      İlk fark: $FIRST_DIFF"
        ALL_OK=false
    fi
    
    rm -f "$REMOTE_CONFIG"
done

rm -f "$MASTER_CONFIG"
rmdir "$TEMP_DIR" 2>/dev/null

echo ""
if $ALL_OK; then
    echo "Tum sunucular senkronize durumda."
    exit 0
else
    echo "Senkronizasyon sorunu tespit edildi!"
    exit 1
fi

İleri Düzey Kullanım

Byte Offset ile Kısmi Karşılaştırma

Bazen bir dosyanın sadece belirli bir bölümünü karşılaştırmanız gerekir. Örneğin bir binary’nin sadece header kısmını kontrol etmek istiyorsunuz:

# İlk 512 byte'ı karsilastir (MBR veya dosya header kontrolu)
cmp -n 512 dosya1.bin dosya2.bin

# Belirli bir offsetten baslayarak karsilastir
# dosya1'i 100. byte'tan, dosya2'yi 200. byte'tan baslayarak karsilastir
cmp -i 100:200 dosya1 dosya2

# Tum farkli byte'lari listele ve say
cmp -l dosya1 dosya2 | wc -l

# Farkli byte'larin detaylarini goster
cmp -lb dosya1 dosya2 | head -20

Pipe ile Kullanım

cmp stdin’den de okuyabilir. Bu özellik özellikle network üzerinden dosya kontrolü yaparken çok işe yarıyor:

# Uzak dosyayi indirmeden karsilastir
ssh web02 "cat /etc/nginx/nginx.conf" | cmp /etc/nginx/nginx.conf -

# gzip ile sikistirilmis bir dosyanin icerigini karsilastir
zcat backup.sql.gz | cmp - current.sql

# Hash ile birlikte kullanım
md5sum dosya1 dosya2
# Vs
cmp -s dosya1 dosya2 && echo "Aynı" || echo "Farklı"

cmp vs Diğer Araçlar

Hangi durumda hangisini kullanmalısınız?

  • cmp: Binary dosyalar, hızlı eşit/farklı kontrolü, byte düzeyinde detay gerektiğinde
  • diff: Metin dosyaları, ne değişti görmek istediğinizde, patch üretmek için
  • md5sum / sha256sum: Çok sayıda dosyayı hızlıca karşılaştırmak için, integrity kontrolü için
  • rsync --checksum: Dizinleri senkronize etmek ve farklılıkları bulmak için

Web sunucusu yönetiminde bu araçları birlikte kullanmak en verimli yaklaşımdır. Örneğin önce md5sum ile hızlı tarama yapıp, farklı bulunan dosyalarda cmp -l ile detaylı analiz yapabilirsiniz.

Exit Code’ları Anlama

cmp komutunun döndürdüğü exit code’ları script yazmada kritik öneme sahiptir:

  • 0: Dosyalar aynı
  • 1: Dosyalar farklı
  • 2: Hata oluştu (dosya bulunamadı, erişim engeli vb.)
cmp -s dosya1 dosya2
RESULT=$?

case $RESULT in
    0) echo "Dosyalar identik" ;;
    1) echo "Dosyalar farklı" ;;
    2) echo "Karşılaştırma hatası" ;;
esac

-s (silent) bayrağı ile birlikte bu pattern, script’lerinizde temiz ve güvenilir kontroller yapmanızı sağlar.

Pratik İpuçları

  • Büyük dosyalarda dikkatli olun: cmp -l ile büyük binary dosyaları karşılaştırırsanız çok fazla çıktı üretebilir. Çıktıyı head veya wc -l ile sınırlandırın.
  • Symbolic link’ler: cmp symlink’lerin işaret ettiği dosyaları karşılaştırır, symlink’lerin kendisini değil. Bu genellikle istediğiniz davranıştır ama bilinmesi gerekir.
  • İzin sorunları: cmp okuma iznine ihtiyaç duyar. Root ya da ilgili kullanıcı ile çalıştırın.
  • Cron job’larda kullanım: -s bayrağını her zaman kullanın, gereksiz mail/log çıktısından kaçının.
  • Paralel kontrol: Çok sayıda dosyayı kontrol ederken xargs -P ile paralel çalıştırarak süreci hızlandırabilirsiniz.

Sonuç

cmp komutu, web sunucusu yönetiminde göründüğünden çok daha fazla işe yarayan güçlü bir araçtır. Deployment doğrulamasından CDN kontrolüne, çoklu sunucu senkronizasyonundan SSL sertifika yönetimine kadar geniş bir kullanım alanına sahiptir.

En büyük avantajı şudur: Sizi yanıltmaz. Byte 0’dan başlayarak bit bit karşılaştırma yapar ve iki dosyanın gerçekten aynı olup olmadığını kesin olarak söyler. Metin editörlerinin gizleyebileceği boşluk karakterleri, satır sonu farklılıkları veya encoding sorunları cmp önünde gizlenemez.

Script’lerinizde cmp -s ile sessiz karşılaştırma yapın, exit code’lara göre aksiyonunuzu belirleyin. Bu basit pattern, çok sayıda production sorununu başlamadan önce engellemenizi sağlayacaktır.

Bir sonraki deployment’ınızda veya sunucu senkronizasyonunuzda cmp komutunu kullanmayı deneyin. Küçük bir araç, büyük güven verir.

diff Komutu ile İki Dosya Arasındaki Farkları Bulma

diff komutu, iki metin dosyası arasındaki farkları satır satır karşılaştırarak gösterir. Web sunucusu yapılandırma dosyalarında yapılan değişiklikleri takip etmek ve sorunları tespit etmek için vazgeçilmez bir araçtır. Bu yazıda diff komutunun temel kullanımını ve pratik örneklerini bulabilirsiniz.

diff Komutu ile Dosya Farklarini Bulmak: Web Sunucusu Yonetiminde Pratik Rehber

Web sunucusu yonetirken kac kez “bu config dosyasinda ne degisti ki site coktu?” diye sordunuz kendinize? Ya da production ortaminda calisan bir nginx.conf ile staging’deki versiyonu karsilastirmaniz gerekti mi? Iste tam bu noktada diff komutu hayat kurtarici oluyor. Bu yazida diff komutunu web sunucusu yonetimi perspektifinden ele alacagiz, gercek dunya senaryolariyla pratik kullanim ornekleri goreceksiniz.

diff Nedir ve Neden Onemlidir?

diff (difference) komutu, iki dosya arasindaki farklari satir satir karsilastirip size gosteren bir Unix/Linux aracıdir. 1970’lerden bu yana var olan bu komut, basit gorunumune ragmen sistem yoneticisinin en kritik araclarindan biridir.

Web sunucusu yonetiminde diff komutunu en cok su durumlarda kullanirsiniz:

  • Apache veya Nginx yapilandirma dosyalarini karsilastirirken
  • Bir guncelleme oncesi ve sonrasi config farklarini analiz ederken
  • Backup dosyasiyla mevcut dosyayi karsilastirirken
  • Farkli ortamlar (dev, staging, production) arasindaki konfigurasyonlari inceleyken
  • Log dosyalarindaki beklenmedik degisiklikleri tespit ederken
  • Deployment sirasinda hangi dosyalarin degistigini anlayamadigimizda

Temel Kullanim Sontaksi

diff komutunun temel kullanimi son derece basittir:

diff [secenekler] dosya1 dosya2

Cikti okumak ilk basta biraz kafa karistiric gelebilir. Simdi bunu somutlastiralim. Diyelim ki iki basit nginx konfigurasyonunuz var.

eski_nginx.conf:

worker_processes 2;
keepalive_timeout 65;
gzip off;
server_name example.com;

yeni_nginx.conf:

worker_processes 4;
keepalive_timeout 75;
gzip on;
gzip_min_length 1000;
server_name example.com www.example.com;
diff eski_nginx.conf yeni_nginx.conf

Cikti soyle gorunur:

1c1
< worker_processes 2;
---
> worker_processes 4;
2c2
< keepalive_timeout 65;
---
> keepalive_timeout 75;
3c3,4
< gzip off;
---
> gzip on;
> gzip_min_length 1000;
4c5
< server_name example.com;
---
> server_name example.com www.example.com;

Bu ciktida:

  • < isareti birinci dosyadaki (eski) satiri gosterir
  • > isareti ikinci dosyadaki (yeni) satiri gosterir
  • c harfi “change” (degisim) anlamina gelir
  • a harfi “add” (ekleme) anlamina gelir
  • d harfi “delete” (silme) anlamina gelir

Unified Format: Cok Daha Okunabilir Cikti

Normal diff ciktisi biraz ham kalebilir. Web sunucusu configlerini incelerken genellikle unified format kullanmak cok daha mantiklidir. Bu format, git’in de kullandigi formattir ve degisikliklerin etrafindaki context satirlari da gosterir.

diff -u eski_nginx.conf yeni_nginx.conf

Cikti:

--- eski_nginx.conf    2024-01-15 10:23:45.000000000 +0300
+++ yeni_nginx.conf    2024-01-15 14:30:22.000000000 +0300
@@ -1,4 +1,5 @@
-worker_processes 2;
+worker_processes 4;
-keepalive_timeout 65;
+keepalive_timeout 75;
-gzip off;
+gzip on;
+gzip_min_length 1000;
 server_name example.com;
+server_name example.com www.example.com;

Bu formatta:

  • - ile baslayan satirlar eski dosyada var, yenide yok
  • + ile baslayan satirlar yeni dosyada var, eskide yok
  • Boslukla baslayan satirlar her iki dosyada da ayni sekilde mevcut (context)

-u parametresi yerine -U 5 kullanarak kac satir context gostermek istedigini de belirtebilirsiniz:

diff -U 5 eski_nginx.conf yeni_nginx.conf

Gercek Dunya Senaryosu 1: Apache Config Karsilastirma

Diyelim ki bir Apache guncelleme yaptiniz ve sitenin belirli URL’leri duzgun yonlendirmiyor. Backup’inizdaki .conf dosyasiyla mevcut dosyayi karsilastirmak istiyorsunuz.

# Backup dosyasi genellikle su konumlarda olur
diff -u /etc/apache2/sites-available/mysite.conf /etc/apache2/sites-available/mysite.conf.bak

# Ya da tarih damgali backup varsa
diff -u /etc/apache2/sites-available/mysite.conf /backup/apache/mysite.conf.20240115

Eger farklari bir dosyaya kaydetmek istiyorsaniz (ki bunu mutlaka yapmanizi tavsiye ederim):

diff -u /etc/apache2/sites-available/mysite.conf /backup/apache/mysite.conf.20240115 > /tmp/apache_config_diff.patch

# Dosyayi inceleyin
cat /tmp/apache_config_diff.patch

Bu .patch dosyasini daha sonra patch komutuyla uygulamak icin de kullanabilirsiniz, ama bu baska bir yazinin konusu.

Gercek Dunya Senaryosu 2: Dizin Karsilastirma

Web sunucunuzda /etc/nginx/conf.d/ dizinindeki tum config dosyalarini staging sunucusundakiyle karsilastirmak istiyorsunuz. diff komutu tek tek dosyalar icin degil, dizinler icin de calisir.

# Iki dizini recursive olarak karsilastir
diff -rq /etc/nginx/conf.d/ /backup/nginx/conf.d/

-r recursive (alt dizinleri de dahil et), -q ise quiet mode (sadece hangi dosyalarin farkli oldugunu goster, farklar detayli degil) anlamina gelir.

Cikti soyle gorunur:

Files /etc/nginx/conf.d/default.conf and /backup/nginx/conf.d/default.conf differ
Only in /etc/nginx/conf.d/: ssl.conf
Files /etc/nginx/conf.d/proxy.conf and /backup/nginx/conf.d/proxy.conf differ

Bu ciktidan hemen anliyoruz: ssl.conf dosyasi backup’ta yok, default.conf ve proxy.conf farkli. Simdi detaylari gorelim:

# Sadece farkli olan dosyayi detayli incele
diff -u /etc/nginx/conf.d/default.conf /backup/nginx/conf.d/default.conf

# Ya da tum dizini unified formatla karsilastir
diff -ru /etc/nginx/conf.d/ /backup/nginx/conf.d/

Gercek Dunya Senaryosu 3: SSL Sertifika Konfigurasyonu Kontrolu

SSL sertifika yenileme sonrasi Apache virtual host’un dogru guncellendi mi kontrol etmek istiyorsunuz. Eski ve yeni config arasindaki SSL ile ilgili satirlara odaklanmak istiyorsunuz.

# Temel karsilastirma
diff -u /etc/apache2/sites-available/ssl-site.conf.old /etc/apache2/sites-available/ssl-site.conf

# Sadece degisikliklerin sayisini gormek isterseniz
diff /etc/apache2/sites-available/ssl-site.conf.old /etc/apache2/sites-available/ssl-site.conf | wc -l

Bazen whitespace farkliliklari (bosluk, tab gibi) kafa karistirir. Bunlari ignore etmek icin:

# Whitespace farklarini yoksay
diff -u -b /etc/apache2/sites-available/ssl-site.conf.old /etc/apache2/sites-available/ssl-site.conf

# Bos satirlardaki whitespace farklarini da yoksay
diff -u -B /etc/apache2/sites-available/ssl-site.conf.old /etc/apache2/sites-available/ssl-site.conf

# Buyuk-kucuk harf farklarini da yoksay
diff -u -i /etc/apache2/sites-available/ssl-site.conf.old /etc/apache2/sites-available/ssl-site.conf

Gercek Dunya Senaryosu 4: Deployment Scripti ile Entegrasyon

Production deployment yapan bir script dusunun. Hangi config dosyalarinin degistigini log’a yazmak ve operatore bildirmek istiyorsunuz.

#!/bin/bash

# Deployment oncesi config farklarini kontrol eden script
OLD_CONFIG_DIR="/backup/configs/$(date -d 'yesterday' +%Y%m%d)"
NEW_CONFIG_DIR="/etc/nginx"
LOG_FILE="/var/log/deployment/config_diff_$(date +%Y%m%d_%H%M%S).log"

echo "Config farklari kontrol ediliyor..." | tee "$LOG_FILE"
echo "Tarih: $(date)" | tee -a "$LOG_FILE"
echo "==========================================" | tee -a "$LOG_FILE"

# Farkli dosyalari bul
DIFF_OUTPUT=$(diff -rq "$OLD_CONFIG_DIR" "$NEW_CONFIG_DIR" 2>/dev/null)

if [ -z "$DIFF_OUTPUT" ]; then
    echo "Hicbir config dosyasinda degisiklik yok." | tee -a "$LOG_FILE"
else
    echo "Degisen dosyalar:" | tee -a "$LOG_FILE"
    echo "$DIFF_OUTPUT" | tee -a "$LOG_FILE"
    echo "" | tee -a "$LOG_FILE"

    # Her farkli dosya icin detayli diff al
    while IFS= read -r line; do
        if [[ "$line" == Files* ]]; then
            FILE1=$(echo "$line" | awk '{print $2}')
            FILE2=$(echo "$line" | awk '{print $4}')
            echo "--- Detayli fark: $FILE1 ---" | tee -a "$LOG_FILE"
            diff -u "$FILE1" "$FILE2" | tee -a "$LOG_FILE"
            echo "" | tee -a "$LOG_FILE"
        fi
    done <<< "$DIFF_OUTPUT"

    echo "Log dosyasi kaydedildi: $LOG_FILE"
fi

Bu script sayesinde her deployment’ta hangi config’in nasil degistigine dair tam bir kayit tutulmus olur.

Renk ve Gorsel Gelistirmeler: colordiff

Terminal’de renksiz diff ciktisi okumak yorucu olabilir. colordiff aracini yukleyerek cok daha okunabilir bir deneyim elde edebilirsiniz.

# Ubuntu/Debian
sudo apt install colordiff

# CentOS/RHEL
sudo yum install colordiff

# Kullanim aynı diff gibi
colordiff -u /etc/nginx/nginx.conf /backup/nginx/nginx.conf.bak

~/.bashrc veya ~/.bash_aliases dosyasina ekleyerek diff komutunu otomatik olarak renkli hale getirebilirsiniz:

alias diff='colordiff'

Cikti Formatlarini Karsilastirma

diff komutu farkli cikti formatlari destekler. Web sunucusu yonetiminde en cok kullandiginiz formatlar sunlar olacaktir:

  • Normal format (varsayilan): Eski, minimal cikti. Script’lerde parse etmek icin uygun.
  • Unified format (-u): En okunakli format, git de bu formati kullanir. Insan okumasi icin ideal.
  • Context format (-c): Unified’a benzer ama biraz farkli gorunum. Legacy sistem uyumlulugu icin kullanilir.
  • Side by side (-y): Iki dosyayi yan yana gosterir. Genis terminal’de cok kullanisli.
# Side by side karsilastirma
diff -y --width=200 /etc/nginx/nginx.conf /backup/nginx/nginx.conf.bak

# Side by side, sadece farkli satirlari goster
diff -y --suppress-common-lines /etc/nginx/nginx.conf /backup/nginx/nginx.conf.bak

diff ile Binarileri ve Ozet Karsilastirma

Config dosyasi gibi gorunen ama aslinda binary olan (ornegin SSL private key .der formati) ya da cok buyuk log dosyalarini karsilastirirken ozet yontem ise yarar. Burada md5sum veya sha256sum ile kombine kullanmak pratiktir.

# Iki dosyanin hash'ini karsilastir (icerik ayni mi diye bak)
md5sum /etc/nginx/nginx.conf /backup/nginx/nginx.conf.bak

# Ya da dogrudan diff ile binary dosyalari karsilastir (farkli mi degil mi sorar)
diff <(md5sum /etc/nginx/nginx.conf) <(md5sum /backup/nginx/nginx.conf.bak)

Pratik Ipuclari ve Kisayollar

Gunluk is hayatinda isinizi kolaylastiracak birkac ipucu:

Geri donus kodu kontrolu: diff komutu fark buldugunda 1, bulamadiginda 0, hata olustugunda 2 doner. Bunu script’lerde kullanabilirsiniz.

diff dosya1 dosya2
if [ $? -eq 0 ]; then
    echo "Dosyalar ayni"
elif [ $? -eq 1 ]; then
    echo "Dosyalar farkli"
fi

Process substitution ile canli karsilastirma: Bir komutun ciktisini dosyayla karsilastirmak istediginizde:

# Mevcut nginx config ile parse edilmis halini karsilastir
diff <(nginx -T 2>/dev/null | grep -v '#') /etc/nginx/nginx.conf

Recursive, sadece belirli uzantilar: Tum dizini degil, sadece .conf dosyalarini karsilastirmak icin:

# find ile birlikte kullanin
find /etc/nginx -name "*.conf" -exec sh -c 'diff -u "$1" "/backup/nginx${1#/etc/nginx}" 2>/dev/null' _ {} ;

Sonuc

diff komutu, web sunucusu yonetiminin vazgecilmez bir parcasidir. Nginx veya Apache config dosyalarindaki beklenmedik degisiklikleri tespit etmek, deployment oncesi ve sonrasi karsilastirma yapmak, backup kontrolu saglamak gibi pek cok kritik gorevde bu komutu kullanacaksiniz.

En onemli cikartim: diff -u formatini alisinkanlik haline getirin. Unified format hem okunabilir hem de patch komutuyla dogrudan uygulanabilir oldugu icin en pratik secenektir.

Buyuk bir degisiklik yapmadan once her zaman mevcut config’in bir kopyasini alin ve degisiklik sonrasi diff ile karsilastirmayi ihmal etmeyin. Gece 2’de production’da yarim saatlik kesintiye neden olan “kucuk bir bosluk hatasi”nin acisini yasamak istemiyorsaniz, diff komutunu is akisinizin standart bir parcasi haline getirin.

Bir sonraki yazida patch komutuyla diff ciktisini nasil uygulayacagimizi ve bu ikilinin CI/CD pipeline’larinda nasil kullanildigini ele alacagiz.

tail Komutu ile Log Takibi ve Canlı Dosya İzleme

tail komutu, Linux sistemlerde log dosyalarının son satırlarını görüntülemek ve canlı olarak takip etmek için vazgeçilmez bir araçtır. Web sunucusu yöneticileri için Apache, Nginx ve uygulama loglarını anlık izlemede kritik rol oynar. Bu yazıda tail komutunun tüm parametrelerini ve gerçek dünya kullanım senaryolarını ele alıyoruz.

tail Komutu: Log Takibi ve Canli Dosya Izleme

Web sunucusu yonetiminin en kritik becerilerinden biri log dosyalarini etkili sekilde okumak ve izlemektir. Bir sorun ciktiginda, bir saldiri algiladiginizda veya performans dusuklugu yasadiginizda ilk basvuracaginiz yer log dosyalaridir. Bu noktada tail komutu, sysadmin’in en yakin dostu haline gelir.

Bu yazida tail komutunu tum detaylariyla ele alacagiz. Temel kullanimi, web sunucusu senaryolari, gercek dunya ornekleri ve bazi ileri seviye kullanim sekilleri uzerinden gecelim.

tail Nedir ve Ne Ise Yarar?

tail komutu, bir dosyanin son satirlarini ekrana basmak icin kullanilir. Adini “kuyruk” anlamina gelen ingilizce “tail” kelimesinden alir, yani dosyanin kuyrugundan, yani sonundan okur.

Linux’ta log dosyalari surekli buyuyen dosyalardir. Bir Apache veya Nginx web sunucusu her HTTP istegiyle access.log dosyasina yeni bir satir ekler. Hata olustugunda error.log dosyasina kayit duser. Bu dosyalari cat ile acmaya calisirsakyuzlerce binlerce satiri terminalinize dokecektir. tail ise sadece ilgilendiginiz son kismi getirir.

En temel kullanimi:

tail /var/log/nginx/access.log

Bu komut varsayilan olarak dosyanin son 10 satirini gosterir. Hizli bir kontrol icin idealdir.

Temel Parametreler

-n: Satir Sayisi Belirleme

Varsayilan 10 satir cok kisa veya uzun gelebilir. -n parametresiyle istediginiz satir sayisini belirleyebilirsiniz:

# Son 50 satiri goster
tail -n 50 /var/log/nginx/error.log

# Son 100 satiri goster
tail -n 100 /var/log/apache2/access.log

# Kisaltilmis kullanim
tail -50 /var/log/nginx/error.log

Burada ufak ama cok isine yarayacak bir numara: Satir sayisinin onune + koyarsaniz anlam degisir. +20 derseniz “20. satirdan itibaren goster” anlamina gelir:

# 20. satirdan itibaren sonuna kadar goster
tail -n +20 /var/log/nginx/access.log

Bu ozellik ozellikle uzun log dosyalarinda belirli bir noktadan sonrasini okumak istediginizde cok isine yarar.

-f: Canli Izleme (Follow)

Bu, tail komutunun en cok kullanilan ve en degerli ozelligidir. -f parametresi ile dosyaya yazilan yeni satirlari anlik olarak ekraninizdatakip edebilirsiniz.

tail -f /var/log/nginx/access.log

Bu komutu calistirdiginizda terminal “bekler” moduna girer ve dosyaya her yeni satir eklendiginde onu aninda gosterir. Web sunucunuza gelen istekleri gercek zamanli izlemek icin muhtesemdir.

-f modundan cikmak icin CTRL + C tusuna basin.

-F: Daha Akilli Takip

-f ile -F arasinda onemli bir fark var. -F parametresi log rotation (log dosyasi dongusunu) destekler. Yani log dosyasi yeniden adlandirilip yeni bir dosya olusturulsa bile -F yeni dosyayi otomatik olarak takip etmeye baslar.

tail -F /var/log/nginx/access.log

Uzun sureli izleme yapacaksaniz -f yerine -F kullanin. Logrotate servisi gece yari calisip access.log dosyasini access.log.1 olarak yeniden adlandirdiginda -F sorunsuz devam eder, -f ise eski dosyayi izlemeye devam eder.

Web Sunucusu Senaryolari

Senaryo 1: Nginx Hata Loglarini Canli Izleme

Bir kullanici “siteniz calismyor” diye sizi aradi. Ilk yapacaginiz sey buyuk ihtimalle sudur:

tail -f /var/log/nginx/error.log

Ekranda su tur satirlar gormeye baslarsaniz:

2024/01/15 14:32:11 [error] 1234#0: *567 connect() failed (111: Connection refused) while connecting to upstream

Hemen anliyorsunuz: Nginx upstream’e, yani arkasindaki uygulamaya (PHP-FPM, Node.js vs.) baglanamiyor. Sorun nginx’in kendisinde degil, arkasindaki serviste.

Senaryo 2: Apache Access Log ile Trafik Analizi

Sunucunuz yavasladiysa kimin ne yaptigini anlamak istersiniz:

tail -n 200 /var/log/apache2/access.log | grep "POST"

Bu komut son 200 satir icindeki POST isteklerini filtreler. Birinin formunuzu spam amacli kullanip kullanmadigini hemen gorebilirsiniz.

Daha spesifik bir ornek:

# Belirli bir IP'nin isteklerini canli izle
tail -f /var/log/apache2/access.log | grep "192.168.1.100"

# 404 hatalarini canli izle
tail -f /var/log/nginx/access.log | grep " 404 "

# 500 hatalarini canli izle
tail -f /var/log/nginx/access.log | grep " 500 "

Senaryo 3: Birden Fazla Log Dosyasini Ayni Anda Izleme

Bu cok bilinen ama az kulllanilan bir ozellik. tail -f ile birden fazla dosyayi ayni anda izleyebilirsiniz:

tail -f /var/log/nginx/access.log /var/log/nginx/error.log /var/log/php8.1-fpm.log

Cikti su formatta olur, hangi dosyadan geldigini ust baslikta yazar:

==> /var/log/nginx/access.log <==
192.168.1.1 - - [15/Jan/2024:14:35:22 +0300] "GET /api/users HTTP/1.1" 200 1234

==> /var/log/nginx/error.log <==
2024/01/15 14:35:23 [warn] FastCGI sent in stderr: "PHP message: PHP Warning..."

Bu ozelligi kesfettigimde “neden bunu daha once bilmiyordum” diye dusunmustum. Bir sorun debug ederken cok fazla zaman kazandiriyor.

Ileri Seviye Kullanim Ornekleri

multitail ile Daha Guzel Izleme

Standart tail yetmiyorsa multitail aracini deneyin. Her log dosyasini ayri bir pencerede, renkli sekilde gosterir:

# Kurulum
apt-get install multitail   # Debian/Ubuntu
yum install multitail       # CentOS/RHEL

# Kullanim
multitail /var/log/nginx/access.log /var/log/nginx/error.log

grep ile Guclu Filtreleme

tail -f ciktilarini grep ile pipe’layarak cok spesifik filtrelemeler yapabilirsiniz:

# Sadece 5xx hatalarini goster
tail -f /var/log/nginx/access.log | grep -E " 5[0-9]{2} "

# Belirli bir endpoint'i izle
tail -f /var/log/nginx/access.log | grep "/api/payment"

# Birden fazla filtre (ve mantigi)
tail -f /var/log/nginx/access.log | grep "POST" | grep "/login"

# Birden fazla filtre (veya mantigi)
tail -f /var/log/nginx/access.log | grep -E "POST|PUT|DELETE"

awk ile Log Analizi

tail ciktisini awk‘a gondererek daha anlamli bilgiler cikarabilirsiniz:

# Sadece IP adreslerini ve HTTP status kodlarini goster
tail -n 100 /var/log/nginx/access.log | awk '{print $1, $9}'

# Sadece 200 OK olmayan istekleri goster
tail -n 500 /var/log/nginx/access.log | awk '$9 != 200 {print $1, $7, $9}'

watch ile Periyodik Kontrol

tail -f yerine bazi durumlarda watch komutuyla tail‘i birlestirebilirsiniz:

# Her 2 saniyede bir son 20 satiri yenile
watch -n 2 'tail -20 /var/log/nginx/error.log'

Gercek Dunya Senaryosu: DDoS Saldirisi Algilama

Bir aksam sunucunuzun load average’i aniden yukseldi. Ne yapiyorsunuz? Hemen log takibine basliyorsunuz:

# Canli trafigi izle
tail -f /var/log/nginx/access.log

Ekranda ayni IP’den saniyede onlarca istek goruyorsunuz. Simdi su komutla dogrulayabilirsiniz:

# Son 1000 istekte en cok istek yapan IP'leri bul
tail -n 1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Cikti:

    847 185.220.101.45
    234 192.168.1.200
     12 10.0.0.1

185.220.101.45 IP’si son 1000 istekte 847 kez istek yapmis. Bu bir bot veya DDoS kaynagi. Simdi bu IP’yi engelleyebilirsiniz:

# Anlik olarak bu IP'yi izlemeye devam et
tail -f /var/log/nginx/access.log | grep "185.220.101.45"

Engelleme sonrasi bu satirin durmasini izliyorsunuz. Boyle bir senaryoda tail -f olmadan ne yapardik bilemiyorum.

Log Rotation ile Birlikte Calisma

tail -F kullanmaniz gereken en onemli durum log rotation’dir. Cron veya logrotate servisi gece yari log dosyalarini rotate ettiginde ne olur?

# logrotate sonrasi eski dosya
/var/log/nginx/access.log.1

# Yeni bos dosya
/var/log/nginx/access.log

Eger -f kullaniyorsaniz tail eski dosyayi (access.log.1) izlemeye devam eder, yeni dosyaya gecmez. -F kullaniyorsaniz bunu otomatik halleder:

# Guvenli ve akilli takip
tail -F /var/log/nginx/access.log

# systemd journal log takibi (logrotation derdi olmayan alternatif)
journalctl -fu nginx

tail ile systemd Journal Entegrasyonu

Modern Linux sistemlerinde bazi servisler syslog yerine direkt journald’a yazar. Bu durumda journalctl komutunun -f secenegi devreye girer, ama tail ile de entegre edebilirsiniz:

# journalctl canli izleme (tail -f muadili)
journalctl -fu nginx

# Son 50 satir + canli takip
journalctl -n 50 -fu php-fpm

# Belirli bir zaman araligindaki loglar
journalctl -u nginx --since "1 hour ago"

Pratikte her ikisini de bilmek gerekiyor, cunku bazi kurulumlar dosya bazli log, bazilari journal bazli calisiyor.

Performans Ipuclari

tail -f calisirken bazen terminali bir suru gereksiz satir doldurabilir. Bazi pratik ipuclari:

  • Buffer flush sorunu: tail -f ciktisini pipe’ladiginizda bazen satirlar anlinda gelmeyebilir. stdbuf -oL ile bunu cozebilirsiniz:
tail -f /var/log/nginx/access.log | stdbuf -oL grep "ERROR" | stdbuf -oL awk '{print $1, $9}'
  • Yuksek trafikli sunucularda: Saniyede binkerce istek alan sunucularda tail -f terminali cok hizli dolduracaktir. grep ile mutlaka filtreleyin.
  • Uzak sunucularda: SSH uzerinden tail -f yaparken baglanti koperse islem durur. screen veya tmux icinde calistirin:
screen -S log-takip
tail -f /var/log/nginx/error.log | grep "error|crit|emerg"
# CTRL+A D ile screen'den ayrilin, baglanti kopsa bile devam eder

Hizli Referans Tablosu

En cok kullanacaginiz kombinasyonlar:

  • tail -f dosya : Canli takip
  • tail -F dosya : Canli takip (log rotation destekli)
  • tail -n 100 dosya : Son 100 satir
  • tail -f dosya | grep "kelime" : Filtreli canli takip
  • tail -f dosya1 dosya2 : Coklu dosya takibi
  • tail -n +50 dosya : 50. satirdan itibaren
  • tail -c 1000 dosya : Son 1000 byte

Sonuc

tail komutu, gorunuste basit bir arac ama web sunucusu yonetiminde neredeyse her gun kullanacaginiz bir sysadmin silahi. Ozzellikle tail -f ve tail -F kombinasyonlarini, bunlari grep ve awk ile birlestirrmeyi ogrendiginizde log analizi cok daha hizli ve verimli hale geliyor.

Pratik tavsiyem su: Bir sonraki kez sunucunuzda bir sorun ciktiginda direk panik yapmak yerine tail -f /var/log/nginx/error.log yazin ve ekrana bakin. Cogu zaman cevap zaten oradadir, sadece okumasi gerekiyor.

Log okumak bir beceridir ve her okudukca daha iyi hale gelirsiniz. Zamanla hata mesajlarini taniyor, pattern’leri fark ediyor ve sorunlari cok daha hizli cozuyorsunuz. Bu da sizi daha iyi bir sysadmin yapan seylerden biri.

head Komutu ile Dosyanın İlk Satırlarını Görüntüleme

head komutu, Linux sistemlerde bir dosyanın ilk satırlarını hızlıca görüntülemek için kullanılan temel bir araçtır. Web sunucusu log dosyalarını ve yapılandırma dosyalarını incelerken büyük dosyaları tamamen açmadan önizleme imkanı sunar. Bu yazıda head komutunun söz dizimini ve web sunucusu yönetimindeki pratik kullanım senaryolarını ele alacağız.

head Komutu ile Dosyanın İlk Satırlarını Görüntüleme

Web sunucusu yönetiminde her gün onlarca log dosyasına, konfigürasyon dosyasına ve çıktıya bakman gerekiyor. Bu dosyaların tamamını açmak hem zaman kaybı hem de gereksiz kaynak tüketimi. İşte bu noktada head komutu devreye giriyor. Basit ama bir o kadar güçlü olan bu araç, dosyanın sadece başını sana gösteriyor – ve çoğu zaman ihtiyacın olan tek şey bu.

Bu yazıda head komutunu web sunucusu yönetimi bağlamında, gerçek dünya senaryolarıyla ele alacağız.

head Komutu Nedir?

head, bir dosyanın veya standart girdi akışının ilk N satırını (ya da N byte’ını) ekrana basan bir Unix komutudur. Varsayılan davranışı ilk 10 satırı göstermektir. Hiçbir parametre vermeden kullandığında bu 10 satırı alırsın.

Temel sözdizimi şu şekilde:

head [SECENEK] [DOSYA]

Neden bu kadar önemli? Düşün: 500 MB’lık bir Nginx access log dosyan var. cat ile açmaya kalkarsan terminal çöker, less ile açsan bile dosyanın başına gitmek için zaman harcarsın. head ise anında sonucu verir.

Temel Kullanım

Varsayılan Davranış – İlk 10 Satır

head /var/log/nginx/access.log

Bu komut sana Nginx access log dosyasının ilk 10 satırını getirir. Web sunucusu yeni kurulduysa ya da log rotasyonu yapıldıysa, ilk kayıtların nasıl göründuğunu hızlıca kontrol etmek için idealdir.

Örnek çıktı:

192.168.1.100 - - [15/Jan/2025:08:23:11 +0300] "GET / HTTP/1.1" 200 1234
192.168.1.101 - - [15/Jan/2025:08:23:15 +0300] "GET /index.html HTTP/1.1" 200 5678
...

Satır Sayısını Belirleme

-n parametresiyle kaç satır görmek istediğini söyleyebilirsin:

head -n 20 /var/log/nginx/error.log

Ya da daha kısa yazımla:

head -20 /var/log/nginx/error.log

Her iki kullanım da aynı sonucu verir. Ben genellikle -20 kısa formunu tercih ederim, daha az tuşa basmak gerekiyor.

Web Sunucusu Senaryolarında Kullanım

Senaryo 1 – Nginx Konfigürasyonunun Basini Kontrol Etme

Bir sunucuya yeni bağlandında ve Nginx konfigürasyonunun genel yapısını hızlıca anlamak istediğinde:

head -30 /etc/nginx/nginx.conf

Bu komut sana konfigürasyon dosyasının ilk 30 satırını gösterir. Worker process sayısı, event modeli gibi kritik ayarlar genellikle dosyanın başında olduğu için bu yöntem oldukça etkili.

Senaryo 2 – Apache Access Log Analizi

Apache access log dosyasında en son hangi IP adreslerinin sunucuya ilk istekleri attığını görmek için:

head -50 /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn

Bu pipeline’da ne oluyor:

  • head -50 ilk 50 satiri alıyor
  • awk '{print $1}' sadece IP adreslerini çekiyor
  • sort | uniq -c her IP’nin kaç kez geçtiğini sayıyor
  • sort -rn en çok tekrar edenden başlayarak sıralıyor

Senaryo 3 – Birden Fazla Dosyayı Aynı Anda Kontrol Etme

Birden fazla log dosyasının basini aynı anda görmek istiyorsan:

head -5 /var/log/nginx/access.log /var/log/nginx/error.log /var/log/php8.1-fpm.log

head her dosyanın basini ayrı bir başlıkla gösterir:

==> /var/log/nginx/access.log <==
[ilk 5 satir]

==> /var/log/nginx/error.log <==
[ilk 5 satir]

==> /var/log/php8.1-fpm.log <==
[ilk 5 satir]

Bu özelliği özellikle sabahın köründe servislere ilk bakışta kullanıyorum. Tek komutla sistemin genel durumunu anlıyorum.

Senaryo 4 – SSL Sertifika Dosyasini Kontrol Etme

SSL sertifikasının doğru formatta olup olmadığını hızlıca kontrol etmek için:

head -3 /etc/ssl/certs/sunucu.crt

Beklenen çıktı:

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
...

Eğer dosyanın başı -----BEGIN CERTIFICATE----- ile başlamıyorsa, yanlış dosyaya bakıyorsun ya da dosya bozuk demektir.

Uyarı: SSL sertifika dosyalarını düzenlemeden önce mutlaka yedek al. head ile sadece okuma yapıyorsun, bu yüzden güvenli, ama ileride yapacağın işlemlerde dikkatli ol.

-c Parametresi ile Byte Bazlı Okuma

head sadece satır bazlı değil, byte bazlı da çalışabilir. -c parametresi bunu sağlar:

head -c 100 /var/log/nginx/access.log

Bu komut dosyanın ilk 100 byte’ını gösterir. Peki bu ne işe yarar?

  • Dosya formatini doğrulamak için (magic bytes kontrolü)
  • Binary dosyaların basini incelemek için
  • Küçük chunk’lar halinde dosya transferi yaparken test etmek için

Örnek – bir war ya da jar dosyasinin gerçekten Java archive olup olmadığini kontrol etmek:

head -c 4 /opt/tomcat/webapps/uygulama.war | xxd

Çıktıda 504b 0304 görüyorsan (ZIP/JAR magic bytes) dosya geçerlidir.

İpucu: -c parametresini byte boyutunu hızlıca tahmin etmek için kullanabilirsin. Örneğin bir JSON response’unun ilk 200 byte’ına bakarak formatın bozuk olup olmadığını anlayabilirsin.

Pipeline ile Güçlü Kombinasyonlar

grep ile Birlikte

Nginx konfigürasyonunda ilk 50 satır içinde sadece server_name satırlarini bulmak:

head -50 /etc/nginx/sites-enabled/default | grep "server_name"

tail ile Birlikte – Belli Bir Aralik

Bir log dosyasinin 100. ile 150. satırları arasını görmek istiyorsan head ve tail komutlarını birlikte kullanabilirsin:

head -150 /var/log/nginx/access.log | tail -50

Bu kombinasyon şunu yapıyor: önce ilk 150 satırı alıyor, sonra bunların son 50 tanesini gösteriyor. Yani 101-150. satırları elde ediyorsun.

wc ile Birlikte

Log dosyasının ilk 100 satırındaki toplam karakter sayısını bulmak:

head -100 /var/log/apache2/access.log | wc -c

watch ile Birlikte – Gerçek Zamanlı Takip

Bu kombinasyon biraz farklı ama çok işe yarıyor. Bir dosyanın başi periyodik olarak değişiyorsa (örneğin bir queue dosyası veya sıralı işlem listesi):

watch -n 2 'head -20 /var/log/nginx/access.log'

Her 2 saniyede bir ilk 20 satırı yeniden gösterir. tail -f‘nin aksine bu yöntem dosyanın statik başına bakıyor, anlık takip için tail -f daha uygun ama bazı durumlarda watch + head kombinasyonu işe yarıyor.

Gerçek Dünya Senaryosu – Yeni Sunucu Kurulumunda İlk Kontroller

Bir sunucuya yeni bağlandığında şu kontrol listesini head ile hızlıca yapabilirsin:

# Sistem bilgisini kontrol et
head -5 /etc/os-release

# Hostname ve hosts dosyasi
head -10 /etc/hosts

# Nginx kurulu mu ve konfigürasyon basli mi?
head -20 /etc/nginx/nginx.conf

# PHP-FPM havuz ayarlari
head -30 /etc/php/8.1/fpm/pool.d/www.conf

# MySQL/MariaDB konfigürasyonu
head -40 /etc/mysql/mysql.conf.d/mysqld.cnf

Bu scripti bir dosyaya kaydedip yeni sunucularda çalıştırabilirsin. Beş dakika içinde sunucunun genel durumunu anlarsın.

head vs tail – Hangisini Ne Zaman Kullanmalısın?

Bu ikisi sık sık karıştırılır. Kural basit:

  • head: Dosyanın formatını anlamak, ilk kayıtları görmek, konfigürasyon dosyalarını hızlı incelemek için kullan
  • tail: En son logları, aktif hataları, gerçek zamanlı akışı takip etmek için kullan

Web sunucusu log yönetiminde genellikle tail -f kullanırsın çünkü yeni gelen istekleri anlık izlemek istersin. Ama log rotasyonu sonrası yeni oluşan dosyanın dogru başladığından emin olmak için head kullanırsın.

İpucu: Log rotasyonu yaptıktan hemen sonra head -5 /var/log/nginx/access.log ile yeni log dosyasının temiz başladığını doğrula. Eski kayıtlar taşınmış olmamalı.

Büyük Dosyalarda Performans Avantajı

Bu konu çok önemli ama genellikle göz ardı ediliyor. head komutu büyük dosyaları tamamen okumaz. Gerekli satır sayısına ulaştığında okumayı durdurur.

Şöyle düşün: 2 GB’lık bir Apache access log dosyan var.

# Bu komut 2 GB'yi tamamen okur - kötü fikir
cat /var/log/apache2/access.log | head -10

# Bu komut sadece ilk 10 satırı okur - iyi fikir
head -10 /var/log/apache2/access.log

Aralarındaki fark saniyeler ile milisaniyeler arasında olabilir. Üretim sunucusunda I/O yükünü düşük tutmak istiyorsan cat | head yerine doğrudan head kullan.

Uyarı: cat dosya | head -10 şeklindeki kullanım “useless use of cat” antipattern’idir. Bu kullanım gereksiz yere bir süreç daha başlatır ve büyük dosyalarda cat tüm dosyayı okumaya çalışır. Her zaman head -10 dosya formunu tercih et.

Konfigürasyon Dosyası Şablonu Oluşturma

Bazen bir konfigürasyon dosyasının sadece başındaki yorum satırlarını ve temel ayarları başka bir dosyaya kopyalamak istersin:

# Nginx konfigürasyonunun ilk 50 satirini yedege al
head -50 /etc/nginx/nginx.conf > /root/nginx_config_header_backup.txt

# Içerigini dogrula
head -10 /root/nginx_config_header_backup.txt

Ya da mevcut bir konfigürasyonu template olarak kullanmak istersen:

# Var olan konfigürasyonun basindaki genel ayarlari yeni dosyaya kopyala
head -30 /etc/nginx/sites-available/mevcut-site > /etc/nginx/sites-available/yeni-site
echo "" >> /etc/nginx/sites-available/yeni-site
echo "# Buraya yeni site ayarlarini ekle" >> /etc/nginx/sites-available/yeni-site

Sorun Giderme Senaryosu

Diyelim ki bir müşteri sana şikayetle geldi: “Sitemiz sabah 08:00-09:00 arasında yavaşlıyor.” Log analizi yapmak için:

# Kac satir log var bilgisini al
wc -l /var/log/nginx/access.log

# Ilk 100 satirin formatini kontrol et
head -100 /var/log/nginx/access.log

# Saat 08:00 ile baslayan kayıtların bu dosyada olup olmadığini kontrol et
head -500 /var/log/nginx/access.log | grep "08:0"

Bu adımlar sana log formatının doğru olup olmadığını ve problematik zaman dilimine ait kayıtların mevcut dosyada bulunup bulunmadığını gösterir.

Faydalı Aliaslar ve Fonksiyonlar

Günlük kullanım için bashrc’ne şunları ekleyebilirsin:

# Nginx loglarının basini goster
alias nginxhead='head -50 /var/log/nginx/access.log'
alias nginxerr='head -50 /var/log/nginx/error.log'

# Apache için
alias apachehead='head -50 /var/log/apache2/access.log'

# Tüm önemli log baslarini göster
function logcheck() {
    echo "=== NGINX ACCESS ==="
    head -10 /var/log/nginx/access.log
    echo ""
    echo "=== NGINX ERROR ==="
    head -10 /var/log/nginx/error.log
    echo ""
    echo "=== PHP-FPM ==="
    head -10 /var/log/php8.1-fpm.log
}

Bu aliasları tanımladıktan sonra sabah kontrol rutinini tek komutla yapabilirsin:

source ~/.bashrc
logcheck

Sonuç

head komutu, görünürde basit ama web sunucusu yönetiminde günlük hayatın vazgeçilmez parçasi. Özellikle şu durumlar için aklında tutmalısın:

  • Büyük log dosyalarına hızlı göz atmak
  • Konfigürasyon dosyalarının genel yapısını anlamak
  • Log rotasyonu sonrası yeni dosyaları doğrulamak
  • SSL sertifikası ve diğer kritik dosyaların formatını kontrol etmek
  • Pipeline’larda gereksiz I/O yükünden kaçınmak

Tek başına kullandığında bile güçlü olan head, grep, awk, tail ve watch gibi araçlarla birleşince gerçek bir güç merkezi haline geliyor. Komut satırı araçlarının güzelliği de zaten bu – birbirini tamamlayan küçük parçalar.

Bir dahaki sefere büyük bir log dosyasini analiz etmek için cat yazmaya kalktığında dur ve head‘i düşün. I/O yükünü düşür, terminali kirletme, işini hızlıca gör.

uname Komutu ile Sistem Bilgisi Ogrenme Teknikleri

Bir Linux sunucusuna baglandiginda ilk yapman gereken sey sistemi tanimaktir. uname komutu bu is icin en temel araclardan biridir ve dogru kullandiginda sana cok fazla bilgi verir. Bu yazida uname komutunu her acisindan ele alacagiz.

Yeni bir sunucuya SSH ile baglandin. Ne yapiyorsun? Cogu deneyimli sysadmin refleks olarak birkac komut girer – bunlarin basinda uname gelir. Kernel versiyonu ne, mimari 32 bit mi 64 bit mi, hangi isletim sistemindeyiz? Bunlari bilmeden sunucuda is yapmak, haritasiz yabanci bir sehirde araba kullanmaya benzer.

Bu yazida uname komutunu derinlemesine inceleyecegiz. Sadece temel kullanimi degil, gercek dunya senaryolarinda nasil kullandiginizi, scriptlere nasil entegre ettiginizi ve baska hangi komutlarla birlikte guclu bir sistem bilgisi tablosu olusturdugunuzu konusacagiz. Hazirsan baslayalim.

uname Nedir ve Neden Onemlidir?

uname, Unix ve Linux sistemlerde sistem bilgilerini goruntuleyen temel bir komuttur. Adi “Unix Name” kelimelerinin kisaltmasindan gelir. POSIX standartlarina dahil oldugu icin neredeyse her Unix/Linux sistemde bulunur – ister Ubuntu, ister CentOS, ister FreeBSD, ister macOS olsun.

Web sunucusu yonetiyorsan bu komut sana ozellikle kritik anlarda yardimci olur. Mesela bir guvenlik acigi cikmis, CVE numarasi var elimde, etkilenen kernel versiyonunu bilmem gerekiyor. Ya da bir yazilimi derleyeceksin, mimariyi dogrulaman lazim. Belki bir destek bileti aciyorsun ve karsi taraf “kernel versiyonunu gonder” diyor. Tum bu durumlarda uname ilk duragin olacak.

Temel Kullanim: Parametreler ve Ciktilari

Ilk once parametrelere bakalim. uname komutunu parametresiz calistirirsan sadece sistem adini gosterir. Ama asil guc parametrelerde sakli:

# Parametresiz kullanim - sadece kernel adini gosterir
uname
# Cikti: Linux

# Tek tek parametre kullanimi
uname -s   # Kernel adi (System)
uname -n   # Network hostname
uname -r   # Kernel release (versiyon)
uname -v   # Kernel version (derleme bilgisi)
uname -m   # Makine mimarisi
uname -p   # Islemci tipi
uname -i   # Donanim platformu
uname -o   # Isletim sistemi

# Hepsini bir arada gormek icin
uname -a

Simdi bu parametrelerin ne anlama geldigini tek tek konusalim. Cogu zaman sadece uname -a kullanilir ama ne gordugunu anlamak cok onemli.

ParametreAciklamaOrnek Cikti
-sKernel adiLinux
-nHostnamewebserver01.example.com
-rKernel release5.15.0-91-generic
-vKernel version (derleme tarihi)#101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023
-mMakine mimarisix86_64
-pIslemci tipix86_64
-iDonanim platformux86_64
-oIsletim sistemiGNU/Linux
-aTum bilgilerTum alanlari birlestirerek gosterir

uname -a Ciktisini Dogru Okumak

Pratik bir ornek uzerinden gidelim. Tipik bir Ubuntu sunucusunda uname -a ciktisi soyle gozukur:

uname -a
# Linux webserver01 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

# Bu ciktiyi parcalayalim:
# Linux             -> Kernel adi (-s)
# webserver01       -> Hostname (-n)
# 5.15.0-91-generic -> Kernel release (-r)
# #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 -> Kernel version (-v)
# x86_64            -> Makine mimarisi (-m)
# x86_64            -> Islemci tipi (-p)
# x86_64            -> Donanim platformu (-i)
# GNU/Linux         -> Isletim sistemi (-o)

Burada kernel versiyonu olan 5.15.0-91-generic satirini iyi anlamak lazim. Uc bolumden olusuyor: ana versiyon (5), alt versiyon (15), yama seviyesi (0) ve ardinda distroye ozgu ek bilgi. Bu numarayi guvenlik acigi aradigin zaman cok kullaniyor olacaksin.

Ipucu: Kernel versiyonunu CVE veritabanlarinda ararken uname -r ciktisini aynen kullanma. Cogu CVE, upstream kernel versiyonuna gore siniflaydirilir, distro paket numarasina gore degil. Ornegin 5.15.0-91-generic, upstream olarak 5.15 kernel ailesine karsilik gelir.

Gercek Dunya Senaryosu 1: Guvenlik Yamasi Kontrolu

Diyelim ki bir guvenlik acigi haberi okudun. Etkilenen sistemler kernel 5.x serisinin belirli bir versiyonuna kadar olan surumler. Elindeki tum web sunucularini kontrol etmen gerekiyor. Iste bu noktada uname‘i script ile birlestiriyorsun:

#!/bin/bash
# Birden fazla sunucuda kernel versiyonunu kontrol et
# sunucular.txt dosyasinda her satirda bir IP/hostname oldugununu varsayiyoruz

SUNUCU_LISTESI="sunucular.txt"
ETKILENEN_VERSIYON="5.15.0-88"

while IFS= read -r sunucu; do
    echo -n "$sunucu: "
    kernel=$(ssh -o ConnectTimeout=5 -o StrictHostKeyChecking=no "$sunucu" 'uname -r' 2>/dev/null)
    if [ $? -eq 0 ]; then
        echo "Kernel: $kernel"
        # Basit versiyon karsilastirmasi
        if [[ "$kernel" == *"$ETKILENEN_VERSIYON"* ]]; then
            echo "  *** DIKKAT: Bu sunucu etkilenebilir! ***"
        fi
    else
        echo "BAGLANTI HATASI"
    fi
done < "$SUNUCU_LISTESI"

Bu script, listendeki sunuculara baglanip kernel versiyonlarini ceker ve etkilenen versiyonla karsilastirir. Otuz sunucuyu tek tek kontrol etmek yerine bunu calistirip kahveni icer, geri dondugun zaman sonuclar seni bekliyor olur.

Gercek Dunya Senaryosu 2: Mimari Bazli Paket Yukleme

Web sunucularinda bazen 32 bit ve 64 bit sistemler karisik kullanilabilir (evet, hala boyle ortamlar var). Yazdigin deployment scriptinin dogru mimariye gore paket indirmesi gerekiyor. Iste uname -m burada devreye giriyor:

#!/bin/bash
# Mimariye gore dogru binary indir ve yukle

MIMARU=$(uname -m)
APP_VERSION="2.4.1"
BASE_URL="https://releases.example-app.com"

case "$MIMARI" in
    x86_64)
        PACKAGE_URL="${BASE_URL}/app-${APP_VERSION}-linux-amd64.tar.gz"
        echo "64-bit sistem tespit edildi, amd64 paketi indiriliyor..."
        ;;
    aarch64|arm64)
        PACKAGE_URL="${BASE_URL}/app-${APP_VERSION}-linux-arm64.tar.gz"
        echo "ARM64 sistem tespit edildi, arm64 paketi indiriliyor..."
        ;;
    armv7l)
        PACKAGE_URL="${BASE_URL}/app-${APP_VERSION}-linux-armv7.tar.gz"
        echo "ARMv7 sistem tespit edildi, armv7 paketi indiriliyor..."
        ;;
    i686|i386)
        PACKAGE_URL="${BASE_URL}/app-${APP_VERSION}-linux-386.tar.gz"
        echo "32-bit sistem tespit edildi, 386 paketi indiriliyor..."
        ;;
    *)
        echo "Bilinmeyen mimari: $MIMARI"
        exit 1
        ;;
esac

wget -q "$PACKAGE_URL" -O /tmp/app.tar.gz
tar -xzf /tmp/app.tar.gz -C /opt/
echo "Kurulum tamamlandi."

Bu tarz scriptler ozellikle Ansible playbook yazmadan once prototip cikarmak icin cok isiniza yarar. Mimariye gore dallandirma yaparak hem tek scriptle tum ortamlari yonetebilirsin hem de hata riskini minimize edersin.

uname’in Sinirlamalari ve Tamamlayici Komutlar

uname guclu bir arac ama tek basina tam resmi vermez. Mesela hangi Linux dagitimini kullandigini soylemez. Ubuntu mu, CentOS mu, Debian mi? Bunu anlamak icin baska kaynaklara bakman gerekiyor:

# Distro bilgisi icin - modern sistemlerde calisir
cat /etc/os-release

# Eski sistemlerde
cat /etc/issue

# lsb_release komutu (varsa)
lsb_release -a

# Tum sistem bilgisini toplu gormek icin
echo "=== KERNEL ==="
uname -a
echo ""
echo "=== DISTRO ==="
cat /etc/os-release 2>/dev/null || cat /etc/issue 2>/dev/null
echo ""
echo "=== CPU MIMARISI ==="
uname -m
echo ""
echo "=== HOSTNAME ==="
hostname -f 2>/dev/null || uname -n

Web sunucusu yonetiminde bu bilgilerin hepsini bir arada gormek cok isine yarar. Ozellikle bir destek sureci baslayinca veya yeni bir ekip uyesi sunucuya el atacaksa bu bilgileri bir README dosyasina veya wiki’ye not etmek iyi bir aliskanlik.

hostnamectl ile Gelismis Sistem Bilgisi

Systemd kullanan modern sistemlerde hostnamectl komutu daha zengin cikti verir. uname ile birlikte kullaninca cok kapsamli bir sistem profili cikartabilirsin:

# hostnamectl cok daha detayli bilgi verir
hostnamectl

# Tipik cikti:
#  Static hostname: webserver01
#        Icon name: computer-server
#          Chassis: server
#       Machine ID: a1b2c3d4e5f6...
#          Boot ID: x9y8z7w6...
# Operating System: Ubuntu 22.04.3 LTS
#           Kernel: Linux 5.15.0-91-generic
#     Architecture: x86-64

# Sadece mimari almak icin
hostnamectl | grep Architecture

# Sadece OS bilgisi
hostnamectl | grep "Operating System"

# uname ile karsilastirmali rapor
echo "uname ciktisi:"
uname -a
echo ""
echo "hostnamectl ciktisi:"
hostnamectl

Web Sunucusu Ortamlarinda Pratik Kullanim Senaryolari

Web sunucusu yonetirken uname‘e en cok ihtiyac duydugun durumlar sunlar:

  • Nginx veya Apache’nin belirli bir versiyonu kernel ozelligi gerektiriyorsa uyumlulugu kontrol etmek
  • Let’s Encrypt/Certbot kurulumu oncesinde sistem gereksinimlerini dogrulamak
  • Docker veya container teknolojisi kurmadan once kernel versiyonunu kontrol etmek
  • eBPF tabanli monitoring araclari icin kernel gereksinimine bakmak
  • SSL/TLS ayarlari icin kernel crypto subsystem versiyonunu anlamak
  • Load balancer veya firewall kurulumu oncesinde netfilter/nftables destegini kontrol etmek

Bunlarin cogu icin sadece uname -r ciktisina bakman yeterli. Ama bazi durumlarda daha derin bir kontrol gerekebilir. Mesela Docker icin minimum kernel gereksinimini kontrol eden basit bir script:

#!/bin/bash
# Docker kurulumu icin kernel gereksinimleri kontrolu

KERNEL_VERSION=$(uname -r)
ARCH=$(uname -m)

echo "Sistem Bilgisi:"
echo "  Kernel: $KERNEL_VERSION"
echo "  Mimari: $ARCH"
echo ""

# Kernel versiyonunu parcalara ayir
MAJOR=$(echo "$KERNEL_VERSION" | cut -d. -f1)
MINOR=$(echo "$KERNEL_VERSION" | cut -d. -f2)

echo "Kernel Ana Versiyon: $MAJOR"
echo "Kernel Alt Versiyon: $MINOR"
echo ""

# Docker icin minimum kernel 3.10
if [ "$MAJOR" -gt 3 ] || ([ "$MAJOR" -eq 3 ] && [ "$MINOR" -ge 10 ]); then
    echo "GECTI: Kernel versiyonu Docker icin yeterli (min. 3.10)"
else
    echo "BASARISIZ: Kernel versiyonu cok eski! Docker icin en az 3.10 gerekli."
    exit 1
fi

# Mimari kontrolu
if [ "$ARCH" = "x86_64" ] || [ "$ARCH" = "aarch64" ]; then
    echo "GECTI: Desteklenen mimari tespit edildi."
else
    echo "UYARI: Bu mimari ($ARCH) icin Docker destegi sinirli olabilir."
fi

echo ""
echo "Kontrol tamamlandi."

Uyari: Kernel versiyonu tek basina yeterli degildir. Docker gibi araclarin cgroup versiyonu, namespace destegi ve baska kernel modulleri gibi gereksinimleri de vardir. Yukaridaki script temel bir on kontrol icin kullanilabilir, resmi kurulum dokumantasyonunu her zaman takip et.

Monitoring ve Loglama Icin uname Kullanimi

Sistem izleme scriptleri yazarken log kayitlarina sistem bilgisini eklemek cok iyi bir aliskanlik. Logdaki bir hataya bakarken hangi kernel ve mimari oldugunu bilmek zaman kazandirir. Ozellikle farkli versiyonlarda farkli davranislar gosteren problemlerde bu bilgi altin degerinde:

#!/bin/bash
# Sistem bilgisini log dosyasina yaz
# Bu scripti cron ile gunluk calistirabilisin

LOG_DIR="/var/log/sysinfo"
LOG_FILE="${LOG_DIR}/system_snapshot_$(date +%Y%m%d).log"

mkdir -p "$LOG_DIR"

{
    echo "======================================"
    echo "Sistem Anlık Goruntu - $(date '+%Y-%m-%d %H:%M:%S')"
    echo "======================================"
    echo ""
    echo "[KERNEL BILGISI]"
    echo "Tam uname -a ciktisi: $(uname -a)"
    echo "Kernel adi: $(uname -s)"
    echo "Kernel versiyonu: $(uname -r)"
    echo "Kernel derleme: $(uname -v)"
    echo "Mimari: $(uname -m)"
    echo "Hostname: $(uname -n)"
    echo ""
    echo "[OS BILGISI]"
    if [ -f /etc/os-release ]; then
        grep -E '^(NAME|VERSION|ID)=' /etc/os-release
    fi
    echo ""
    echo "[SISTEM KAYNAKLARI]"
    echo "CPU cekirdek sayisi: $(nproc)"
    echo "Toplam RAM: $(free -h | awk '/^Mem:/ {print $2}')"
    echo "Disk kullanimi:"
    df -h / | tail -1
    echo ""
    echo "======================================"
} >> "$LOG_FILE"

echo "Sistem bilgisi kaydedildi: $LOG_FILE"

Bu scripti /etc/cron.daily/ altina koyarsan her gun otomatik olarak calisir ve sistemin gecmisini kayit altina alirsin. Kernel guncellemenin ardinda hangi versiyona gectinizi, ne zaman gectinizi bu loglardan takip edebilirsin.

macOS ve Diger Unix Sistemlerinde uname

Sadece Linux degil, macOS da dahil hemen her Unix sisteminde uname calisir. Gelistirme ortaminda Mac kullanip production’da Linux calistiriyorsan bunu bilmen faydali. Aralarindaki farklara dikkat et:

  • macOS’ta uname -s ciktisi “Darwin” olarak gelir
  • macOS’ta uname -r Darwin kernel versiyonunu verir, macOS surumunu degil
  • FreeBSD’de uname -s ciktisi “FreeBSD” olarak gelir
  • Cross-platform script yazarken uname -s ile OS kontrolu yapmak iyi bir pratik

Eger hem Linux hem macOS’ta calisacak bir script yaziyorsan, bunu su sekilde handle edebilirsin:

#!/bin/bash
# Cross-platform sistem bilgisi - Linux ve macOS destekli

OS_TYPE=$(uname -s)

case "$OS_TYPE" in
    Linux)
        echo "Linux sistem tespit edildi."
        echo "Kernel: $(uname -r)"
        echo "Mimari: $(uname -m)"
        if [ -f /etc/os-release ]; then
            DISTRO=$(grep '^NAME=' /etc/os-release | cut -d= -f2 | tr -d '"')
            echo "Dagitim: $DISTRO"
        fi
        PAKET_YONETICISI="apt-get veya yum"
        ;;
    Darwin)
        echo "macOS (Darwin) tespit edildi."
        echo "Darwin kernel: $(uname -r)"
        echo "macOS surumu: $(sw_vers -productVersion 2>/dev/null || echo 'bilinmiyor')"
        echo "Mimari: $(uname -m)"
        PAKET_YONETICISI="brew"
        ;;
    FreeBSD)
        echo "FreeBSD tespit edildi."
        echo "Versiyon: $(uname -r)"
        PAKET_YONETICISI="pkg"
        ;;
    *)
        echo "Bilinmeyen sistem: $OS_TYPE"
        PAKET_YONETICISI="bilinmiyor"
        ;;
esac

echo "Onerilecek paket yoneticisi: $PAKET_YONETICISI"

Sonraki Adimlar

uname komutuna hakim olduktan sonra sistem bilgisi toplama konusunda kendini daha da gelistirebilecegin bir yol haritasi sunuyorum:

  • procfs’i ogrenin: /proc/version, /proc/cpuinfo, /proc/meminfo gibi dosyalar uname’den cok daha derin sistem bilgisi verir. Bunlari okumak icin ek bir komuta gerek yok, sadece cat yeterli.
  • dmidecode komutuna bakin: Donanim bilgisi (BIOS versiyonu, RAM slotlari, anakart modeli) icin dmidecode vazgecilmezdir. Root yetkisi gerektirir.
  • lscpu ve lsblk ogrenin: CPU detaylari icin lscpu, disk yapisi icin lsblk harika tamamlayicilardır. uname ile birlikte kullandiginda tam bir donanim profili cikarabilirsin.
  • Ansible facts mekanizmasina bakin: Birden fazla sunucu yonetiyorsan Ansible’in otomatik olarak toplayan ansible_facts modulu seni cok ugrastirici manuel islerden kurtarir.
  • Monitoring sistemine entegre et: Prometheus, Grafana veya benzeri araclara uname bilgilerini label olarak ekleyebilirsin. Boylece metriklerine bakarken hangi kernel versiyonunda oldugunu aninda gorursun.
  • Kernel changelog takibi: uname -r ile ogrendigin versiyon numarasini kernel.org veya distronun changelog sayfasiyla eslestirerek sisteme ne zaman hangi degisikliklerin geldigi hakkinda bilgi sahibi olabilirsin.

uname komutu tek basina kucuk ve sade gorunebilir, ama dogru kullanildiginda sistem yonetiminin temel taslarindan biridir. Guvenlik kontrollerinde, deployment scriptlerinde, troubleshooting sureclerinde ve otomasyonda surekli isinize yarayacak. Scriptlerine entegre et, loglarina ekle ve her yeni sunucuya baglandiginda ilk reflekslerinden biri haline getir.

less Komutu ile Büyük Log Dosyalarını Sayfalayarak Okuma

Web sunucusu yönetirken en çok ihtiyaç duyduğun şeylerden biri büyük log dosyalarını terminali dondurmadan okuyabilmek. less komutu tam da bu iş için var ve cat’ten çok daha güçlü. Bu yazıda less’i sysadmin gözüyle ele alıyoruz.

Gece 2’de production sunucusu alarm verdi, SSH’a bağlandın, /var/log/nginx/error.log dosyasına bakmak istiyorsun. İlk refleks olarak cat /var/log/nginx/error.log yazıyorsun ve terminal binlerce satırı sana fırlatıyor. Ekran kayıyor, bir şey göremiyorsun, history’de kaybolup gidiyorsun. Tanıdık geldi mi? İşte bu yazı tam da o anın çaresi için.

less komutu, büyük dosyaları terminal oturumunu mahvetmeden, kontrollü biçimde okumanı sağlayan bir sayfalayıcı. Aslında adındaki felsefeyi seviyorum: “less is more” — yani less, more komutunun geliştirilmiş hali ve gerçekten de daha fazlasını yapıyor. Hadi her şeyi sıfırdan konuşalım.

less Nedir, Neden cat Kullanmamalısın?

cat komutu dosyayı baştan sona stdout’a basar ve çıkar. 50 MB’lık bir Nginx access log için bu tam bir felakettir. Terminal buffer’ın taşar, scroll yapmak işkenceye döner, arama yapamazsın. more komutu biraz daha iyidir ama sadece aşağı gidebilirsin — yani geri dönemezsin.

less ise dosyayı bellekte tamamen açmaz. Sadece görüntülediğin kısmı okur, bu yüzden 2 GB’lık bir log dosyasını bile anında açar. Hem yukarı hem aşağı gidebilirsin, içinde arama yapabilirsin, birden fazla dosyayı sırayla gezebilirsin. Web sunucusu yönetiminde bu araç neredeyse her gün işine yarar.

Temel Kullanım

En basit kullanım şekli dosya adını argüman olarak vermek. Birkaç yaygın senaryoya bakalım:

# Tek bir dosyayı aç
less /var/log/nginx/error.log

# Apache access log
less /var/log/apache2/access.log

# Syslog'u oku
less /var/log/syslog

# Bir config dosyasını incele
less /etc/nginx/nginx.conf

# Birden fazla dosyayı sırayla aç
less /var/log/nginx/error.log /var/log/nginx/access.log

Dosyayı açtıktan sonra sağ altta dosya adını ve yüzde kaçında olduğunu görürsün. Birden fazla dosya açtığında kaçıncı dosyada olduğun da gösterilir. Basit ama çok işe yarayan bir ayrıntı.

Bilmen Gereken Klavye Kısayolları

less’in gücü kısayollarında yatıyor. Bunları bir kere ezberleyince terminalde çok daha hızlı hareket edersin. En sık kullandıklarımı tabloda derledim:

Kısayolİşlev
Space veya PgDnBir sayfa aşağı git
b veya PgUpBir sayfa yukarı git
j veya Asagi OkBir satır aşağı git
k veya Yukari OkBir satır yukarı git
gDosyanın en başına git
GDosyanın en sonuna git
/kelimeAşağı doğru ara
?kelimeYukarı doğru ara
nSonraki arama sonucuna git
NÖnceki arama sonucuna git
qÇık
hYardım ekranını aç
:nSonraki dosyaya geç (çoklu dosyada)
:pÖnceki dosyaya geç (çoklu dosyada)
FDosyayı canlı takip et (tail -f gibi)

Özellikle F kısayoluna dikkat et. less içinde F tuşuna basarsan dosya gerçek zamanlı güncellenmeye başlar, tıpkı tail -f gibi. Üstelik istediğin zaman Ctrl+C ile canlı takipten çıkıp yine normal okuma moduna geçebilirsin. Bu, tail -f’e göre büyük avantaj çünkü geçmişe dönüp bakabiliyorsun.

Satır Numarası ile Çalışmak

Bir hata mesajında “line 342” gibi bir referans gördüğünde doğrudan o satıra atlamak isteyebilirsin. Bunun için birkaç yöntem var:

# Dosyayı satır numaralarıyla aç
less -N /var/log/nginx/error.log

# less içinde satır numaralarını aç/kapat
# less'i açtıktan sonra -N yazıp Enter'a bas

# Belirli bir satıra atla: less içinde 342g yaz
# ya da komut satırından direkt aç
less +342 /etc/nginx/nginx.conf

# İlk açılışta belirli bir kelimeyi ara
less +/"upstream" /etc/nginx/nginx.conf

Ipucu: less içinde 342g yazarsan (yani sayı + g) direkt o satıra atlar. Büyük config dosyalarında çok işine yarar, özellikle birinin sana “677. satıra bak” dediği durumlarda.

Pipe ile Kullanım — Asıl Güç Burada

less’i sadece doğrudan dosya açmak için kullanmak israfı olur. Asıl gücünü pipe’larla birleştirdiğinde ortaya çıkar. Web sunucusu senaryolarında en çok şöyle kullanıyorum:

# grep çıktısını sayfalayarak görüntüle
grep "500" /var/log/nginx/access.log | less

# Son 500 satırı oku ama sayfalayarak
tail -500 /var/log/nginx/error.log | less

# Birden fazla grep filtresi uygulayıp sayfalama
grep "POST" /var/log/apache2/access.log | grep "404" | less

# journalctl çıktısını sayfalayarak oku
journalctl -u nginx --since "2024-01-01" | less

# ps çıktısını sayfalayarak incele
ps aux | less

# Uzun bir komutun yardım çıktısını oku
nginx -T | less

nginx -T komutu tüm nginx konfigürasyonunu birleştirilmiş olarak döker. Bu çıktı bazen yüzlerce satır olabiliyor. Direkt terminale basmak yerine less’e pipe etmek hayat kurtarır.

Renk ve Çıktı Formatını Koruma

Bir sorunla karşılaşmış olabilirsin: bazı komutların renkli çıktısını less’e pipe ettiğinde renkler kayboluyor. Bu, ANSI renk kodlarının pipe üzerinden geçerken bazı araçlar tarafından ezilmesinden kaynaklanıyor. Bunu çözmek için:

# ANSI renk kodlarını koru (-R bayrağı)
grep --color=always "error" /var/log/syslog | less -R

# Kalıcı olarak ayarlamak için .bashrc veya .zshrc'ye ekle
export LESS="-R"

# Ya da alias tanımla
alias less='less -R'

# git log çıktısını renkli sayfalama
git log --oneline --color=always | less -R

# journalctl çıktısını renkli oku
journalctl -u php8.1-fpm --output=short-precise --no-pager | less -R

Ipucu: LESS ortam değişkenini .bashrc’ye eklersen her seferinde -R yazmak zorunda kalmazsın. Özellikle renkli grep çıktılarını sık kullanıyorsan bu ayarı bir kere yap ve unut.

Gerçek Dünya Senaryosu: Nginx 502 Hatalarını Araştırma

Diyelim ki bir web uygulamasında kullanıcılar intermittent 502 hatası aldığını bildiriyor. İşte bu durumda less’i nasıl kullanırdım:

# Önce son birkaç saatin error loguna bak
tail -2000 /var/log/nginx/error.log | less

# less içindeyken /502 yazarak 502 hatalarını ara
# n tuşuyla sonraki, N ile önceki hataya atla

# Daha hedefli: sadece 502 içerenleri filtrele
grep "502" /var/log/nginx/error.log | less

# Zaman damgasıyla birlikte incele
grep "2024/01" /var/log/nginx/error.log | grep "502" | less

# upstream bağlantı hatalarını ara
grep --color=always "upstream" /var/log/nginx/error.log | less -R

# PHP-FPM logunu da incele (502'nin kaynağı orası olabilir)
less /var/log/php8.1-fpm.log
# less içinde /error veya /fatal yazarak kritik hataları bul

Bu iş akışı sayesinde terminali boğmadan, spesifik hataları hızlıca bulabiliyorsun. Özellikle gece saatlerinde stres altında çalışırken bu tür sistematik bir yaklaşım çok değerli.

Gerçek Dünya Senaryosu: Büyük Config Dosyasını Güvenle İnceleme

Devir aldığın bir sunucuda Nginx konfigürasyonunu anlamaya çalışıyorsun. Dosya 800 satır, içinde upstream blokları, server blokları, location direktifleri iç içe geçmiş. İşte böyle bir durumda:

# Tüm nginx config'i birleştirilmiş halde oku
nginx -T 2>/dev/null | less

# less içinde /server_name yazarak virtual host'ları bul
# /upstream yazarak backend tanımlarını bul
# /ssl_certificate yazarak SSL ayarlarını bul

# Sadece nginx.conf'u satır numarasıyla aç
less -N /etc/nginx/nginx.conf

# Tüm site config'lerini sırayla incele
less /etc/nginx/sites-enabled/*
# :n ile sonrakine, :p ile öncekine geç

# Apache için .htaccess dosyalarını bul ve oku
find /var/www -name ".htaccess" | xargs less

Uyari: find + xargs + less kombinasyonunu kullanırken çok sayıda .htaccess dosyası bulunabilir. Her birine :n ile geçmek yerine önce find ile listeyi görüp, tek tek ilgilendiğin dosyaları açman daha pratik olabilir.

Sıkıştırılmış Log Dosyalarını Okuma

Linux log rotasyon sistemleri eski logları genellikle .gz formatında sıkıştırır. error.log.2.gz gibi dosyaları okumak için less’in özel bir kardeşi var: zless. Ama aslında modern less sürümleri bunu otomatik halleder.

# Sıkıştırılmış log dosyasını oku (zless)
zless /var/log/nginx/error.log.2.gz

# Ya da modern less ile doğrudan (lesspipe etkinse)
less /var/log/nginx/error.log.2.gz

# lesspipe'ı etkinleştirme (.bashrc'ye ekle)
eval "$(lesspipe)"

# Birden fazla sıkıştırılmış dosyayı sırayla oku
zless /var/log/nginx/error.log.1.gz /var/log/nginx/error.log.2.gz

# Sıkıştırılmış log içinde grep yap, çıktıyı say
zcat /var/log/nginx/access.log.1.gz | grep "404" | wc -l

Eski tarihlerdeki olayları araştırırken sıkıştırılmış logları açmak zorunda kalmak gereksiz disk kullanımı yaratır. zless veya lesspipe entegrasyonu bu sorunu tamamen ortadan kaldırır.

Yatay Kaydırma ve Uzun Satırlar

Access log dosyalarında satırlar bazen terminal genişliğini aşar. Varsayılan davranışta less bu satırları keser ve devamını görmezsin. Bunu kontrol etmek için:

# Satır kesmeden aç (yatay scroll ile)
less -S /var/log/nginx/access.log

# less içinde yatay kaydırma: Sol/Sag ok tuslari
# ya da Alt+( ve Alt+) ile kaydır

# Kombinasyon: satır numarası + satır kesme yok
less -SN /var/log/nginx/access.log

# JSON log formatındaki access loglar için özellikle kullanışlı
less -S /var/log/nginx/access.json

# Çok uzun satırlı dosyada belirli kolonu arama
less -S /var/log/nginx/access.log
# less içinde /"POST /api" yazarak API isteklerini bul

JSON formatında log tutan Nginx veya uygulama sunucularında -S bayrağı özellikle değerli. Her satır ayrı bir JSON objesi oluyor ve kesmeden görmek veri bütünlüğünü korur.

Faydalı less Bayrakları Özeti

  • -N: Satır numaralarını göster
  • -S: Uzun satırları kırpma, yatay kaydırmaya izin ver
  • -R: ANSI renk kodlarını işle, renkli çıktı göster
  • -i: Arama yaparken büyük/küçük harf farkını gözetme
  • -F: Dosya tek ekrana sığıyorsa less açmadan direkt göster, çık
  • -X: Çıkışta ekranı temizleme (çıktı terminalde kalsın)
  • -e: Dosya sonuna iki kez ulaşınca otomatik çık
  • +F: Açılışta direkt canlı takip (tail -f) modunda başla
  • -p kelime: Açılışta direkt belirtilen kelimeyi ara ve ona atla

Alias ve Konfigürasyon Önerileri

Günlük iş akışını hızlandırmak için birkaç alias ve ortam değişkeni tanımlamak işini çok kolaylaştırır. Ben .bashrc’me şunları ekledim ve artık düşünmeden kullanıyorum:

# .bashrc veya .zshrc'ye eklenecekler

# Varsayılan less bayrakları: renk + büyük/küçük harf duyarsız arama
export LESS="-R -i"

# lesspipe etkinleştir (sıkıştırılmış dosyalar için)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# Nginx logları için kısayollar
alias nginx-error='less /var/log/nginx/error.log'
alias nginx-access='less -S /var/log/nginx/access.log'
alias apache-error='less /var/log/apache2/error.log'

# Canlı takip kısayolları
alias nginx-live='less +F /var/log/nginx/error.log'

# Syslog takibi
alias syslog='less +F /var/log/syslog'

# .bashrc'yi yeniden yükle
source ~/.bashrc

Ipucu: LESS ortam değişkeni less’in her çalışmasında otomatik uygulanır. Bu yüzden sık kullandığın bayrakları buraya taşıyabilirsin. -i bayrağı özellikle log araştırırken çok işine yarar çünkü büyük/küçük harf farkı olmadan Error, ERROR, error hepsini bulur.

less ile more Karşılaştırması

Özelliklessmore
Geri gitme (yukarı scroll)EvetHayir
Arama yapmaEvet (/ ve ?)Sinirli (sadece /)
Canlı takip moduEvet (F tusu)Hayir
Birden fazla dosyaEvet (:n ve :p)Kismi
ANSI renk desteğiEvet (-R ile)Hayir
Satır numarasıEvet (-N ile)Hayir
Sıkıştırılmış dosyaEvet (zless/lesspipe)Hayir

Tablodan da anlaşılacağı gibi more’u kullanmak için gerçekten özel bir sebep yok. Bazı çok eski veya minimal sistemlerde less bulunmayabilir, o zaman more’a mecbur kalabilirsin. Ama eğer seçme şansın varsa her zaman less kullan.

Sonraki Adımlar

less komutunu artık temel düzeyde iyi kullanabiliyorsun. Buradan sonra şu yönlere gidebilirsin:

  • grep + less kombinasyonu: grep’in -A, -B, -C bayraklarını less ile birleştirerek hata etrafındaki bağlamı görmek çok güçlü bir yöntem. Örneğin hata satırının öncesi ve sonrasını birlikte analiz edebilirsin.
  • multitail: Birden fazla log dosyasını aynı anda, ekranı bölerek takip etmek istiyorsan multitail aracına bak. Özellikle birden fazla servis birlikte debug edilirken çok kullanışlı.
  • lnav: Log dosyaları için geliştirilmiş, renkli ve yapısal analiz yapabilen bir sayfalayıcı. JSON loglarını otomatik parse ediyor, SQL benzeri sorgular bile yazabiliyorsun.
  • gzip log rotasyonu: logrotate konfigürasyonunu öğrenmek, eski logların düzgün sıkıştırılıp yönetilmesi için çok önemli. zless ile de pekiştirdiğin bilgiyle eski logları rahatlıkla okuyabilirsin.
  • lesskey: less’in kendi konfigürasyon dosyası olan lesskey ile kişisel kısayollar tanımlayabilirsin. Çok ileri düzey bir ihtiyaç ama varoluşundan haberdar olmak iyi.

less bir terminal aracı olarak sade görünebilir ama doğru kullandığında log analizi ve dosya inceleme süreçlerini ciddi ölçüde hızlandırır. Özellikle web sunucusu yönetiminde günde onlarca kez kullandığın bir araç haline gelecek. Kısayolları ezberledikçe ve pipe kombinasyonlarına alıştıkça terminalde gerçekten uçtuğunu hissedersin.

echo Komutu: Terminal Çıktısı ve Değişken Kullanımı — Sysadmin Rehberi

echo komutu ilk bakışta çok basit görünür ama web sunucusu yönetiminde scriptlerin bel kemiğini oluşturur. Değişkenlerden log yazmaya, config dosyası üretmeye kadar echo’nun tüm inceliklerini bu yazıda bulacaksın.

echo komutunu ilk öğrendiğinde muhtemelen şöyle düşündün: “Bu kadar mı? Ekrana bir şey yazdırıyor, tamam.” Ben de öyle düşünmüştüm. Ama yıllarca web sunucusu yönetirken fark ettim ki echo, scriptlerin en sık kullanılan ve en çok küçümsenen komutu. Nginx config’i otomatik üretmek, Apache virtual host dosyası oluşturmak, deploy scriptlerine durum mesajı eklemek… Bunların hepsinde echo var. Hadi sıfırdan, ama bu sefer doğru şekilde öğrenelim.

echo Nedir ve Nerede Çalışır?

echo, kendisine verdiğin argümanları standart çıktıya (stdout) yazan bir komuttur. Linux’ta hem bir shell built-in komutu olarak hem de /bin/echo veya /usr/bin/echo yolunda bağımsız bir binary olarak bulunur. Bu fark önemsiz gibi görünse de scriptlerde taşınabilirlik açısından kritik hale gelebilir.

Bash’in kendi içindeki echo ile sistemdeki /bin/echo arasında davranış farkları var. Özellikle -e ve -n gibi flag’lerde bu fark kendini gösteriyor. Hangi echo’yu kullandığını anlamak için şunu çalıştır:

# Hangi echo kullaniliyor?
type echo

# Sistemdeki echo binary yolu
which echo

# Bash built-in olarak mu cagiriliyor?
type -a echo

Genel kural şu: eğer taşınabilir script yazıyorsan ve kaçış karakterleri kullanman gerekiyorsa, echo yerine printf kullanmayı düşün. Ama web sunucusu ortamında Bash scriptleri yazarken echo gayet yeterli.

Temel Kullanım ve Bayraklar

echo’nun üç temel bayrağı var ve bunları ezberlemen gerekiyor:

  • -n: Satır sonu karakterini bastırma, yani çıktının sonuna newline ekleme
  • -e: Kaçış karakterlerini yorumla ( , , vb.)
  • -E: Kaçış karakterlerini yorumlama (bazı sistemlerde varsayılan değil, açıkça belirtmek gerekir)
# Temel kullanim
echo "Merhaba, Dunya"

# Satir sonu olmadan yaz (-n)
echo -n "Sunucu durumu kontrol ediliyor: "
echo "OK"

# Kacis karakterleriyle (-e)
echo -e "Satir 1
Satir 2
Satir 3"

# Tab karakteri
echo -e "Kolon1	Kolon2	Kolon3"

# Renk kodlariyla terminal ciktisi (ANSI)
echo -e "\e[32mBasarili\e[0m: Nginx yeniden baslatildi"
echo -e "\e[31mHata\e[0m: Port 80 kullanimda"

Renk kodlarına gelince: web sunucusu deploy scriptlerinde yeşil/kırmızı renk kullanmak, script çıktısını izleyen birinin durumu anında anlamasını sağlar. Küçük bir detay ama production deploy sırasında gerçekten fark yaratıyor.

Değişken Kullanımı

echo’nun asıl gücü değişkenlerle birleştiğinde ortaya çıkıyor. Web sunucusu scriptlerinde sürekli değişken değerlerini ekrana basmak, log dosyalarına yazmak ya da config dosyalarına aktarmak gerekir. Burada tırnak işaretlerinin nasıl davrandığını anlamak şart.

Kural basit: çift tırnak içinde değişkenler expand edilir, tek tırnak içinde edilmez. Bu fark seni ciddi baş ağrısından kurtarır.

# Degisken tanimlama
SITE_NAME="mywebsite.com"
WEB_ROOT="/var/www/html"
PHP_VERSION="8.2"
SERVER_IP=$(hostname -I | awk '{print $1}')

# Cift tirnak: degisken expand edilir
echo "Site adi: $SITE_NAME"
echo "Web root: $WEB_ROOT"
echo "PHP versiyonu: $PHP_VERSION"
echo "Sunucu IP: $SERVER_IP"

# Tek tirnak: degisken oldugu gibi yazilir
echo 'Degisken: $SITE_NAME'
# Cikti: Degisken: $SITE_NAME

# Karma kullanim
echo "Domain: ${SITE_NAME}, Root: ${WEB_ROOT}/"

# Komut ciktisini degiskene atayip echo ile goster
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}')
echo "Disk kullanimi: $DISK_USAGE"

# Array degiskenlerini gosterme
declare -a SITES=("site1.com" "site2.com" "site3.com")
echo "Birinci site: ${SITES[0]}"
echo "Tum siteler: ${SITES[@]}"

Ipucu: Değişkenleri kullanırken ${DEGISKEN} formatını alışkanlık haline getir. $DEGISKEN da çalışır ama süslü parantez, değişken adının nerede bittiğini kesin olarak belirtir. Özellikle ${SITE_NAME}.conf gibi kullanımlarda süslü parantez olmadan hata alırsın.

Web Sunucusu Senaryolarında echo Kullanımı

Şimdi gerçek hayata gelelim. Web sunucusu yönetirken echo’yu en çok şu üç senaryoda kullanıyorum: config dosyası üretmek, deploy scriptlerine durum mesajı eklemek ve hızlı diagnostic çıktısı almak.

Nginx Virtual Host Config Üretmek

Bir müşteri için yeni bir domain kuruyorsun diyelim. Her seferinde aynı Nginx config’i elle yazmak yerine, parametreleri değişkene atayıp echo ile dosyayı üretebilirsin. Bu, hem hata riskini azaltır hem de süreci hızlandırır.

#!/bin/bash
# nginx_vhost_create.sh — Otomatik Nginx virtual host olusturucu

DOMAIN="$1"
WEB_ROOT="/var/www/${DOMAIN}"
NGINX_CONF="/etc/nginx/sites-available/${DOMAIN}.conf"
PHP_SOCK="/run/php/php8.2-fpm.sock"

if [ -z "$DOMAIN" ]; then
    echo "Kullanim: $0 "
    exit 1
fi

echo "[INFO] $DOMAIN icin Nginx config olusturuluyor..."

# Web dizinini olustur
mkdir -p "${WEB_ROOT}/public"
echo "[OK] Dizin olusturuldu: ${WEB_ROOT}"

# Config dosyasini yaz
cat > "${NGINX_CONF}" << EOF
server {
    listen 80;
    server_name ${DOMAIN} www.${DOMAIN};
    root ${WEB_ROOT}/public;
    index index.php index.html;

    access_log /var/log/nginx/${DOMAIN}_access.log;
    error_log  /var/log/nginx/${DOMAIN}_error.log;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:${PHP_SOCK};
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
EOF

echo "[OK] Nginx config yazildi: ${NGINX_CONF}"
echo "[INFO] Sites-enabled sembolik link olusturuluyor..."
ln -sf "${NGINX_CONF}" "/etc/nginx/sites-enabled/${DOMAIN}.conf"
echo "[OK] Sembolik link olusturuldu"
echo "[INFO] Nginx test ediliyor..."
nginx -t && echo "[OK] Nginx config gecerli" || echo "[HATA] Nginx config hatali!"

Bu scriptte hem cat heredoc hem de echo birlikte kullanılıyor. echo durum mesajları için, cat ise çok satırlı config bloğu için daha uygun. İkisini karıştırmak yerine amaca göre seçmek önemli.

Deploy Script’inde Durum Çıktısı

Canlı ortama deploy yaparken her adımın ne durumda olduğunu bilmek istiyorsun. echo ile renkli ve yapılandırılmış çıktı üretmek, deploy sürecini takip etmeyi çok kolaylaştırır.

#!/bin/bash
# deploy.sh — Web uygulamasi deploy scripti

# Renk tanimlari
GREEN="\e[32m"
RED="\e[31m"
YELLOW="\e[33m"
BLUE="\e[34m"
RESET="\e[0m"

APP_DIR="/var/www/myapp"
GIT_BRANCH="main"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

log_info()    { echo -e "${BLUE}[INFO]${RESET} $1"; }
log_success() { echo -e "${GREEN}[OK]${RESET} $1"; }
log_warning() { echo -e "${YELLOW}[UYARI]${RESET} $1"; }
log_error()   { echo -e "${RED}[HATA]${RESET} $1"; }

echo -e "
${BLUE}================================================${RESET}"
echo -e "${BLUE} Deploy Basladi: ${TIMESTAMP}${RESET}"
echo -e "${BLUE}================================================${RESET}
"

log_info "Proje dizinine geciliyor: ${APP_DIR}"
cd "${APP_DIR}" || { log_error "Dizin bulunamadi: ${APP_DIR}"; exit 1; }

log_info "Git pull islemi: origin/${GIT_BRANCH}"
git pull origin "${GIT_BRANCH}" && log_success "Kod guncellendi" || { log_error "Git pull basarisiz"; exit 1; }

log_info "Composer bagimliliklar yukleniyor..."
composer install --no-dev --optimize-autoloader 
    && log_success "Composer tamamlandi" 
    || { log_error "Composer basarisiz"; exit 1; }

log_info "Cache temizleniyor..."
php artisan cache:clear && log_success "Cache temizlendi"

log_info "Nginx yeniden yukleniyor..."
systemctl reload nginx && log_success "Nginx reload edildi" || log_error "Nginx reload basarisiz"

echo -e "
${GREEN}================================================${RESET}"
echo -e "${GREEN} Deploy Tamamlandi: $(date '+%Y-%m-%d %H:%M:%S')${RESET}"
echo -e "${GREEN}================================================${RESET}
"

echo ile Dosyaya Yazmak

echo’yu yönlendirme operatörleriyle kullanmak, web sunucusu yönetiminde en sık başvurulan tekniklerden biri. Yeni bir dosya oluşturmak için > kullanırsın, mevcut dosyaya eklemek için >> kullanırsın. Bu farkı unutursan ciddi sorunlarla karşılaşabilirsin.

Uyari: > operatörü dosyanın mevcut içeriğini tamamen siler ve üzerine yazar. /etc/nginx/nginx.conf gibi kritik bir dosyada > ile echo kullanıyorsan, önce yedeğini al. Bu hatayı production’da bir kez yaşarsan, bir daha yaşamazsın.

# Yeni dosya olusturma (veya ustune yazma)
echo "ServerName mywebsite.com" > /tmp/apache_test.conf

# Dosyaya ekleme (append)
echo "DocumentRoot /var/www/html" >> /tmp/apache_test.conf
echo "ErrorLog /var/log/apache2/error.log" >> /tmp/apache_test.conf

# Log dosyasina tarihli kayit ekleme
LOG_FILE="/var/log/deploy.log"
echo "$(date '+%Y-%m-%d %H:%M:%S') - Deploy baslatildi: $(whoami)" >> "${LOG_FILE}"
echo "$(date '+%Y-%m-%d %H:%M:%S') - Git commit: $(git rev-parse --short HEAD)" >> "${LOG_FILE}"

# Basit bir durum dosyasi olusturma
echo "OK" > /var/www/html/health.txt
echo "Last-Updated: $(date -u +%Y-%m-%dT%H:%M:%SZ)" >> /var/www/html/health.txt

# PHP bilgi dosyasi olusturma (test ortami icin)
echo "" > /var/www/html/info.php
echo "[UYARI] info.php olusturuldu, test sonrasi silmeyi unutma!"

# /dev/null'a yonlendirme: ciktiyi susturma
echo "Bu mesaj gorunmeyecek" > /dev/null

Özel Değişken Türleri ve echo

Bash’in özel değişkenleri web sunucusu scriptlerinde çok işe yarar. Bu değişkenleri echo ile birleştirdiğinde, scriptlerin debug edilmesi ve izlenmesi çok kolaylaşır.

DeğişkenAnlamıÖrnek Kullanım
$0Scriptin adıecho “Script: $0”
$1, $2…Positional parametrelerecho “Domain: $1”
$#Argüman sayısıecho “$# arguman verildi”
$?Son komutun çıkış koduecho “Cikis kodu: $?”
$$Mevcut process IDecho “PID: $$”
$@Tüm argümanlarecho “Tum: $@”
$HOSTNAMESunucu adıecho “Sunucu: $HOSTNAME”
$USERAktif kullanıcıecho “Kullanici: $USER”
#!/bin/bash
# server_info.sh — Sunucu ozet bilgisi

echo "========================================"
echo " Sunucu Ozet Raporu"
echo "========================================"
echo "Script      : $0"
echo "Calistiran  : $USER"
echo "Sunucu Adi  : $HOSTNAME"
echo "Tarih/Saat  : $(date '+%d.%m.%Y %H:%M:%S')"
echo "Uptime      : $(uptime -p)"
echo "----------------------------------------"
echo "CPU Kullanim: $(top -bn1 | grep 'Cpu(s)' | awk '{print $2}')%"
echo "RAM Kullanim: $(free -h | awk '/^Mem:/ {print $3"/"$2}')"
echo "Disk (/)    : $(df -h / | awk 'NR==2 {print $3"/"$2" ("$5" dolu)"}')"
echo "----------------------------------------"
echo "Aktif Nginx : $(systemctl is-active nginx)"
echo "Aktif MySQL : $(systemctl is-active mysql)"
echo "Aktif PHP   : $(systemctl is-active php8.2-fpm)"
echo "----------------------------------------"
echo "Acik Portlar:"
ss -tlnp | grep LISTEN | awk '{print "  " $4}'
echo "========================================"

# Son komutun basarili olup olmadigini kontrol et
if [ $? -eq 0 ]; then
    echo "Rapor basariyla olusturuldu."
else
    echo "Rapor olusturulurken sorun yasandi. Cikis kodu: $?"
fi

echo ile PHP ve Apache .htaccess Oluşturmak

Web sunucusu yönetiminde sık karşılaşılan bir senaryo: birden fazla site için standart .htaccess veya PHP yapılandırma dosyaları oluşturmak. echo ile bunu script haline getirdiğinde, onlarca siteyi dakikalar içinde yapılandırabilirsin.

#!/bin/bash
# setup_site_config.sh — Site yapılandırma dosyalarini olustur

DOMAIN="${1:-ornek.com}"
WEB_ROOT="/var/www/${DOMAIN}/public"

echo "[INFO] ${DOMAIN} icin yapilandirma dosyalari olusturuluyor..."

# .htaccess olustur (Apache icin)
cat > "${WEB_ROOT}/.htaccess" << 'HTACCESS'
Options -Indexes
ServerSignature Off


    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^ index.php [L]



    ExpiresActive On
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"

HTACCESS
echo "[OK] .htaccess olusturuldu"

# php.ini override olustur
PHP_INI="/var/www/${DOMAIN}/php.ini"
echo "upload_max_filesize = 64M" > "${PHP_INI}"
echo "post_max_size = 64M" >> "${PHP_INI}"
echo "max_execution_time = 120" >> "${PHP_INI}"
echo "memory_limit = 256M" >> "${PHP_INI}"
echo "display_errors = Off" >> "${PHP_INI}"
echo "log_errors = On" >> "${PHP_INI}"
echo "error_log = /var/log/php/${DOMAIN}_error.log" >> "${PHP_INI}"
echo "[OK] php.ini override olusturuldu: ${PHP_INI}"

echo "[INFO] Tum dosyalar basariyla olusturuldu."
echo "Domain     : ${DOMAIN}"
echo "Web Root   : ${WEB_ROOT}"
echo "htaccess   : ${WEB_ROOT}/.htaccess"
echo "PHP Config : ${PHP_INI}"

Sık Yapılan Hatalar

echo kullanımında yıllar içinde gördüğüm ve bizzat yaptığım hataları paylaşayım:

  • Tek tırnak ve çift tırnak karıştırmak: Değişken içeren stringleri tek tırnak içine almak, değişkenin expand edilmemesine yol açar. Her zaman bilinçli seç.
  • $? kontrolünü geciktirmek: $? sadece bir sonraki komutu çalıştırana kadar geçerli. echo $? demeden önce başka bir komut çalıştırırsan, o komutun çıkış kodunu görürsün.
  • Özel karakterleri escape etmemek: echo ile string içinde ! kullanmak Bash history expansion’ı tetikler. Özel karakterlerin önüne \ koy veya tek tırnak kullan.
  • -e flag’ini unutmak: veya kullanacaksan -e flag’ini eklemeyi unutma, yoksa bu karakterler olduğu gibi ekranda görünür.
  • >> yerine > kullanmak: Log dosyasına eklemek istediğinde > ile tüm log geçmişini silmek, en acı verici hatalardan biri.

Uyari: Eğer scriptlerini sudo ile çalıştırıyorsan ve echo ile kritik sistem dosyalarına yazıyorsan, her adımda bir yedek al. “sudo echo ‘bir sey’ > /etc/critical.conf” şeklindeki komutlar, yönlendirme operatörünün sudo kapsamı dışında kalması nedeniyle beklenmedik şekilde davranabilir. Bu durumda “sudo tee” kullanmak daha güvenlidir.

echo mi, printf mi?

Bu soruyu kaçınılmaz olarak soruyorsun. Kısa cevap: web sunucusu scriptlerinde echo genellikle yeterli. Ama şu durumlarda printf’e geç:

  • Farklı shell’lerde (sh, dash, zsh) çalışması gereken taşınabilir scriptler yazıyorsun
  • Sayısal formatlama gerekiyor (örneğin: %.2f ile ondalık basamak kontrolü)
  • Çıktıda kesin boşluk hizalaması önemli
  • Kaçış karakteri davranışının tutarlı olmasını garanti altına almak istiyorsun

Sonraki Adımlar

echo komutunu bu yazıda sıfırdan ele aldık ve web sunucusu yönetimindeki gerçek dünya kullanım senaryolarına baktık. Ama bu sadece bir başlangıç. echo’yu gerçekten verimli kullanmak için şu konulara da hakim olman gerekiyor:

  • tee komutu: Hem ekrana yazmak hem de dosyaya kaydetmek istediğinde echo | tee kombinasyonu hayat kurtarır. Özellikle sudo gerektiren dosyalara yazarken.
  • printf komutu: Taşınabilir ve formatlı çıktı için echo’nun daha güçlü alternatifi. C programcıları kendini evinde hisseder.
  • Heredoc (cat << EOF): Çok satırlı içerik üretirken echo’yu defalarca çağırmak yerine heredoc kullanmak çok daha temiz kod üretir.
  • Bash string manipülasyonu: ${DEGISKEN#prefix}, ${DEGISKEN%suffix} gibi parametre expansion teknikleri, echo ile birleştiğinde çok güçlü araçlara dönüşür.
  • Cron ile echo: Cron job’larında echo çıktısını log dosyasına yönlendirerek otomatik raporlama sistemi kurabilirsin.

Web sunucusu yönetiminde otomasyon ne kadar çok olursa, manuel hata riski o kadar azalır. echo komutunun bu kadar basit görünmesine aldanma — iyi yazılmış bir scriptte bu küçük komut, saatlik manuel işleri dakikalara indirir. Şimdi gidip kendi deploy scriptini yaz, içine biraz renk ekle ve terminal çıktısını güzelleştir. Bir dahaki deploy’da farkını göreceksin.

cat Komutu: Dosya İçeriği Görüntüleme ve Birleştirme Rehberi

Linux dünyasında her gün onlarca kez kullandığın cat komutu, göründüğünden çok daha yetenekli bir araç. Dosya okumaktan log analizi yapmaya, config birleştirmekten veri akışı oluşturmaya kadar uzanan geniş kullanım alanlarını gerçek sunucu senaryolarıyla anlattım.

Sysadmin olarak yıllar içinde fark ettim ki en basit araçlar çoğu zaman en fazla işe yarayan araçlar oluyor. cat komutu tam olarak böyle bir araç. İsmini “concatenate” yani birleştirme kelimesinden alıyor ama çoğu insan onu sadece dosya okumak için kullanıyor. Oysa bir web sunucusu yönetiyorsan, log dosyalarından config karşılaştırmalarına kadar pek çok kritik işte cat sana zaman kazandırır. Gelin bu komutu gerçekten tanıyalım.

cat Nedir ve Ne Yapar?

cat, Unix/Linux sistemlerde dosya içeriklerini standart çıktıya yazan temel bir araçtır. 1971’den bu yana Unix’in ayrılmaz bir parçası olan bu komut, POSIX standardının zorunlu araçları arasında yer alır. Yani hangi Linux dağıtımında çalışıyor olursan ol, cat orada seni bekliyor olacak. Nginx mi, Apache mi, Ubuntu mu, CentOS mu — fark etmez.

Temel söz dizimi son derece basit:

# Temel kullanim
cat [secenek] [dosya...]

# Tek dosya okuma
cat /etc/hostname

# Birden fazla dosya okuma
cat /etc/hostname /etc/os-release

# Standart girdi okuma (CTRL+D ile bitir)
cat

Bu kadar basit görünen bir komutun neden ayrı bir yazı hak ettiğini sorabilirsin. Cevap şu: cat’i sadece “dosya açma” komutu olarak görmek, bir tornavidayı sadece vida sıkmak için kullanmak gibi. Gelin seçeneklere ve gerçek senaryolara geçelim.

Temel Seçenekler ve Anlamları

cat komutunun fazla seçeneği yok ama olanlar oldukça işe yarıyor. Özellikle web sunucusu config dosyalarını incelerken bunları çok kullanacaksın.

SeçenekUzun HaliAçıklama
-n–numberTüm satırlara numara ekler
-b–number-nonblankSadece boş olmayan satırlara numara ekler
-s–squeeze-blankBirden fazla boş satırı tek boş satıra indirir
-A–show-allTüm görünmez karakterleri gösterir
-E–show-endsSatır sonlarını $ ile gösterir
-T–show-tabsTab karakterlerini ^I olarak gösterir
-v–show-nonprintingYazdırılamayan karakterleri gösterir

Bu seçenekleri pratikte nasıl kullandığını görelim. Özellikle -n ve -A seçenekleri web sunucusu config dosyalarında hata ayıklarken hayat kurtarıcı oluyor.

# Satir numaralariyla nginx config dosyasini oku
cat -n /etc/nginx/nginx.conf

# Apache virtual host dosyasini satir numaralariyla goster
cat -n /etc/apache2/sites-enabled/000-default.conf

# Gizli karakterleri goster (tab ve satir sonu dahil)
# Config dosyasinda sekme/bosluk karisikligini tespit etmek icin mukemmel
cat -A /etc/nginx/sites-available/mysite.conf

# Bos olmayan satirlara numara ekle, coklu boslugu sikistir
cat -bs /etc/nginx/nginx.conf

# Sadece satir sonlarini goster (Windows CRLF sorununu tespit et)
cat -E /etc/apache2/.htaccess

Ipucu: Windows’tan FTP ile yüklenen config dosyaları bazen CRLF satır sonları içerir. cat -A komutu bu satırların sonunda ^M$ gösterir. Apache veya Nginx bunu parse edemez ve seni saatlerce hata ayıklamaya mahkum eder. Bu yüzden config dosyalarını düzenlerken her zaman -A ile bir kontrol yap.

Web Sunucusu Log Dosyalarını Okumak

Web sunucusu yönetiminin en kritik parçalarından biri log okumaktır. Apache ve Nginx’in access log ile error log dosyaları, sitenle ne olduğunu anlaman için birincil kaynakların. cat burada genellikle diğer araçlarla birlikte pipeline içinde kullanılır.

# Nginx access log dosyasini oku
cat /var/log/nginx/access.log

# Apache error log dosyasini oku
cat /var/log/apache2/error.log

# Birden fazla log dosyasini birlestirip oku
# Ornegin: birden fazla virtual host logu tek seferde
cat /var/log/nginx/site1-access.log /var/log/nginx/site2-access.log

# Log icerigini grep ile filtrele - 500 hatalarini bul
cat /var/log/nginx/access.log | grep " 500 "

# Son 100 satiri bul (cat + tail kombinasyonu)
cat /var/log/apache2/error.log | tail -100

# IP adreslerine gore erisim sayisi (cat + awk + sort)
cat /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Belirli bir tarih icin log satirlarini filtrele
cat /var/log/nginx/access.log | grep "14/Jan/2025"

Uyari: Büyük log dosyalarında cat kullanırken dikkatli ol. Gigabaytlarca büyümüş bir access.log dosyasını cat ile açmak terminali uzun süre kitleyebilir ve sisteme gereksiz I/O yükü bindirir. Bu tür durumlarda tail, less veya grep doğrudan daha iyi tercihlerdir. cat’i büyük dosyalar için pipeline’ın başında kullanmak yerine, grep veya awk’a doğrudan dosya argümanı vermek daha verimlidir.

Dosya Birleştirme: cat’in Asıl Gücü

cat komutunun adının nereden geldiğini hatırlıyor musun? Concatenate — birleştirme. İşte bu özelliği web sunucusu yönetiminde gerçekten çok işe yarıyor. SSL sertifika dosyalarını birleştirmek, birden fazla config parçasını tek dosyaya toplamak, yedek log dosyalarını arşivlemek gibi senaryolarda cat olmadan yaşayamazsın.

# SSL sertifika zinciri olusturma (en klasik kullanim senaryosu)
# Once site sertifikasi, sonra intermediate CA, sonra root CA
cat domain.crt intermediate.crt root.crt > fullchain.pem

# Sertifika ve ozel anahtari birlestir (bazı uygulamalar ister)
cat domain.crt domain.key > combined.pem

# Let's Encrypt ile manuel zincir olusturma
cat /etc/letsencrypt/live/example.com/cert.pem 
    /etc/letsencrypt/live/example.com/chain.pem > /etc/ssl/example_fullchain.pem

# Birden fazla .htaccess parcasini birlestir
cat htaccess-security.txt htaccess-redirects.txt htaccess-cache.txt > .htaccess

# Nginx include dosyalarini tek dosyada topla (debug icin)
cat /etc/nginx/conf.d/*.conf > /tmp/nginx-all-configs.txt

# Apache config parcalarini birlestir
cat /etc/apache2/conf-enabled/*.conf > /tmp/apache-merged.conf

Ipucu: SSL sertifika zinciri oluştururken sıralama kritiktir. Her zaman domain sertifikasını önce, root CA’yı en sona koy. Sırayı karıştırırsan tarayıcılar sertifikayı güvensiz olarak işaretler ve müşterilerinden şikayet gelmeye başlar.

Dosyaya Yazmak: Yönlendirme Operatörleriyle cat

cat komutunu yönlendirme operatörleriyle birlikte kullanmak, hızlı dosya oluşturma ve içerik ekleme için son derece pratik. Özellikle bir sunucuya bağlandığında editör kurmak istemediğin durumlarda ya da script içinde hızlıca bir dosya oluşturman gerektiğinde çok işe yarıyor.

# Yeni bir dosya olustur ve icerik gir (CTRL+D ile bitir)
cat > /etc/nginx/conf.d/custom-headers.conf

# Var olan dosyaya icerik ekle (ustune yazmaz)
cat >> /var/log/deployment.log

# Heredoc ile script icinde dosya olustur
cat > /etc/nginx/conf.d/security.conf < /etc/nginx/nginx.conf.backup

# Bos dosya olustur (touch gibi ama farklı)
cat /dev/null > /var/log/myapp/app.log

# Deployment notunu log dosyasina ekle
echo "=== Deployment: $(date) ===" | cat - /tmp/changelog.txt >> /var/log/deployment.log

Uyari: Tek büyüktür işareti ( > ) hedef dosyanın üzerine yazar ve eski içeriği siler. Bunu production ortamında yanlış dosyaya yönlendirirsen geri dönüşü olmayan veri kaybı yaşarsın. Her zaman iki kez kontrol et. Mümkün olduğunca önemli dosyalara yazmadan önce yedeğini al.

Gerçek Dünya Senaryo: Web Sunucusu Sorun Tespiti

Diyelim ki gece 2’de telefon çaldı, sitenin down olduğunu söylüyorlar. SSH ile sunucuya bağlandın. Tam olarak ne kullanacaksın? İşte bu noktada cat ve arkadaşları devreye giriyor.

# Adim 1: Nginx durumunu kontrol et
systemctl status nginx

# Adim 2: Son hatalara bak
cat /var/log/nginx/error.log | tail -50

# Adim 3: Config dosyasinda syntax sorunu var mi?
cat -n /etc/nginx/nginx.conf | grep -n "server_name|listen|root"

# Adim 4: Virtual host config dosyasini incele
cat -n /etc/nginx/sites-enabled/production.conf

# Adim 5: PHP-FPM soket/port ayarini kontrol et
cat /etc/nginx/sites-enabled/production.conf | grep fastcgi_pass

# Adim 6: PHP-FPM pool config ile eslesip eslesmedigini karsilastir
cat /etc/php/8.2/fpm/pool.d/www.conf | grep "^listen"

# Adim 7: Disk dolulugunu hizlica kontrol et (full disk = log yazamiyor = crash)
cat /proc/mounts | grep -v tmpfs
df -h

# Adim 8: Erisim logunda anormal trafik var mi?
cat /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -5

Bu akışı standart bir troubleshooting runbook’una koyabilirsin. Ekibindeki junior sysadmin’lere de öğrettiğinde, gece aramalarını azaltabilirsin.

Config Dosyası Karşılaştırma ve Yönetim

Web sunucusu yönetiminde config dosyaları kutsal metinler gibidir. Neyin ne zaman değiştiğini takip etmek, eski konfigürasyona dönmek ya da iki sunucu arasındaki farkı anlamak için cat’i diff ve diğer araçlarla birlikte sık kullanırsın.

# Mevcut nginx config ile yedeği karsilastir
diff <(cat /etc/nginx/nginx.conf) <(cat /etc/nginx/nginx.conf.backup)

# Iki sunucudaki config farkini bul (SSH uzerinden)
diff <(cat /etc/nginx/nginx.conf)  /tmp/all-nginx-configs.txt
cat /tmp/all-nginx-configs.txt

tac, zcat ve Türevleri: Bilmene Değer Kardeşler

cat’in bazı kardeşleri var ve bunlar da web sunucusu yönetiminde işe yarıyor. Bunları öğrenmek için ayrı saatler harcamana gerek yok ama isimlerini ve ne yaptıklarını bilmek, doğru zamanda doğru aracı seçmeni sağlar.

  • tac: cat’in tersine çalışır, dosyayı sondan başa okur. Log dosyasının son satırlarını önce görmek için kullanılır.
  • zcat: Sıkıştırılmış .gz dosyalarını açmadan okur. Rotasyon yapılmış log arşivlerini okurken hayat kurtarır.
  • bzcat: bzip2 ile sıkıştırılmış dosyaları okur.
  • xzcat: xz formatındaki dosyaları okur.
# Log dosyasini sondan basa oku (en yeni kayit once)
tac /var/log/nginx/access.log | head -20

# Rotasyon yapilmis gz logunu acmadan oku
zcat /var/log/nginx/access.log.1.gz

# Tum rotasyon loglarini birden ara
zcat /var/log/nginx/access.log.*.gz | grep "500"

# Eski ve yeni loglari birlestir
zcat /var/log/apache2/access.log.2.gz | cat - /var/log/apache2/access.log > /tmp/merged-access.log

# Log rotasyon arsivlerini tarih sirali birlestir
ls -t /var/log/nginx/access.log*.gz | xargs zcat | cat - /var/log/nginx/access.log > /tmp/full-history.log

Performans ve Dikkat Edilmesi Gerekenler

cat kullanırken bilmen gereken birkaç önemli nokta var. Bu noktaları göz ardı edersen, production ortamında istemediğin sonuçlarla karşılaşabilirsin.

Uyari: “Useless Use of Cat” (UUOC) olarak bilinen anti-pattern’den kaçın. Örneğin cat dosya | grep pattern yerine grep pattern dosya kullanmak hem daha hızlı hem de daha az sistem kaynağı tüketir. Büyük log dosyalarında bu fark önemli hale gelir.

Uyari: Binary dosyaları cat ile açmaya çalışma. Terminali bozabilir, beklenmedik kontrol karakterleri çalıştırabilir. Şüpheli bir dosyayı önce file komut ile kontrol et.

Ipucu: Büyük dosyalarla çalışırken cat yerine less veya more kullanmak terminali kitlemez ve geriye ileri gitme imkanı tanır. Sadece tüm içeriği pipeline’a aktarman gerektiğinde cat tercih et.

Sonraki Adımlar

cat komutunu artık sadece dosya açan bir araç olarak görmüyorsundur umarım. Web sunucusu yönetiminde bu komutu günlük rutininin bir parçası haline getirdiğinde, troubleshooting sürelerin kısalacak ve config yönetimi çok daha düzenli hale gelecek.

cat’i daha verimli kullanmak için şu araçları da öğrenmeni öneririm:

  • less ve more: Büyük dosyaları sayfalayarak okumak için. Özellikle GB’lık log dosyalarında cat’in yerini tutarlar.
  • grep: cat ile pipeline oluşturarak log filtreleme işlerini otomatize etmek için olmazsa olmaz.
  • awk ve sed: cat’ten gelen veriyi işlemek, dönüştürmek ve rapor oluşturmak için güçlü araçlar.
  • tail -f: Gerçek zamanlı log izleme için cat’in yerini tutan araç. Aktif bir web sunucusunda hataları anlık görmek için kullanılır.
  • diff: cat ile birleştirdiğinde config dosyalarını karşılaştırma süreçlerini otomatize edebilirsin.

Bir sonraki yazıda tail ve head komutlarını web sunucusu log yönetimi perspektifinden ele alacağım. O yazıda cat ile birlikte nasıl güçlü bir log analiz pipeline’ı oluşturabileceğini de göreceğiz. Sorularını yorumlara bırakabilirsin.