grep, bir sysadmin’in en çok kullandığı araçların başında gelir. Log analizi, hata tespiti, konfigürasyon kontrolü gibi onlarca günlük görevi regex gücüyle dakikalar içinde çözebilirsin. Bu yazıda temel kullanımdan ileri seviye senaryolara kadar her şeyi bulacaksın.
Bir web sunucusunda bir şeyler patladığında, ilk içgüdün ne olur? Büyük ihtimalle terminali açıp log dosyasına bakmak istersin. Peki 500 MB’lık bir access.log içinde işine yarayacak satırı nasıl bulacaksın? İşte tam bu noktada grep devreye giriyor. grep, Linux dünyasında o kadar temel bir araç ki onsuz bir terminalde çalışmak, klavyesiz bir bilgisayarda çalışmak gibi hissettiriyor. Bu yazıda grep’i gerçekten verimli kullanmak için bilmen gereken her şeyi, gerçek dünya senaryolarıyla birlikte ele alacağız.
Linux’ta dosya arşivleme denince akla ilk gelen komut tar’dır. Yedekleme, transfer, deployment — bunların hepsinde tar sana lazım olacak. Bu yazıda tar komutunu baştan sona öğreniyoruz, sadece teorik değil, gerçek senaryolarla.
Eğer Linux’ta yöneticilik yapıyorsan, tar komutunu tanımayan biri olarak hayatta kalamassın. Sunucudan veri taşımak, yedek almak, web sitesini deploy etmek, log arşivlemek — hepsinde tar karşına çıkacak. Ama itiraf edelim, tar’ın sözdizimi ilk bakışta biraz kaotik görünüyor. -cvzf mi, -xvf mi, --exclude mı? Hangisi ne yapıyor? Bu yazıda hepsini net bir şekilde açıklayacağım, sana ezber değil anlayış kazandırmak istiyorum.
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.
Parametre
Aciklama
Ornek Cikti
-s
Kernel adi
Linux
-n
Hostname
webserver01.example.com
-r
Kernel release
5.15.0-91-generic
-v
Kernel version (derleme tarihi)
#101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023
-m
Makine mimarisi
x86_64
-p
Islemci tipi
x86_64
-i
Donanim platformu
x86_64
-o
Isletim sistemi
GNU/Linux
-a
Tum bilgiler
Tum 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:
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.
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.
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 PgDn
Bir sayfa aşağı git
b veya PgUp
Bir sayfa yukarı git
j veya Asagi Ok
Bir satır aşağı git
k veya Yukari Ok
Bir satır yukarı git
g
Dosyanın en başına git
G
Dosyanın en sonuna git
/kelime
Aşağı doğru ara
?kelime
Yukarı doğru ara
n
Sonraki arama sonucuna git
N
Önceki arama sonucuna git
q
Çık
h
Yardım ekranını aç
:n
Sonraki dosyaya geç (çoklu dosyada)
:p
Önceki dosyaya geç (çoklu dosyada)
F
Dosyayı 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
+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ı
Özellik
less
more
Geri gitme (yukarı scroll)
Evet
Hayir
Arama yapma
Evet (/ ve ?)
Sinirli (sadece /)
Canlı takip modu
Evet (F tusu)
Hayir
Birden fazla dosya
Evet (:n ve :p)
Kismi
ANSI renk desteği
Evet (-R ile)
Hayir
Satır numarası
Evet (-N ile)
Hayir
Sıkıştırılmış dosya
Evet (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 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.
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.
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.
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.
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.
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.
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.
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çenek
Uzun Hali
Açıklama
-n
–number
Tüm satırlara numara ekler
-b
–number-nonblank
Sadece boş olmayan satırlara numara ekler
-s
–squeeze-blank
Birden fazla boş satırı tek boş satıra indirir
-A
–show-all
Tüm görünmez karakterleri gösterir
-E
–show-ends
Satır sonlarını $ ile gösterir
-T
–show-tabs
Tab karakterlerini ^I olarak gösterir
-v
–show-nonprinting
Yazdı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.
Terminal ekranın kaotik bir hale mi geldi? clear komutu ve Ctrl+L kısayolu günlük işlerini çok daha temiz hale getirir. Bu yazıda clear komutunun tüm inceliklerini, alternatiflerini ve sysadmin senaryolarındaki kullanımını ele alıyoruz.
Uzun bir troubleshooting seansının ardından terminale bakıyorsun ve ekran komut çıktılarıyla, hata mesajlarıyla, log satırlarıyla dolup taşmış durumda. Neyin nerede olduğunu bulmak için scroll yapıp duruyorsun. İşte tam bu noktada terminaldeki en basit ama en kurtarıcı komutlardan biri devreye giriyor: clear. Günde onlarca kez kullandığın bu küçük komutun aslında bilmediğin pek çok yönü var. Gelin hepsini konuşalım.
Linux sistem yönetiminin en temel araçlarından biri olan ln komutu, dosya ve dizinleri bağlantılar aracılığıyla yönetmeni sağlar. Web sunucularında konfigürasyon yönetiminden deployment süreçlerine kadar pek çok alanda işine yarayacak bu komutu baştan sona ele alıyoruz.
ln Komutu Nedir ve Neden Önemli?
Linux dünyasında çalışıyorsan, er ya da geç ln komutuyla yüzleşmek zorunda kalacaksın. Özellikle web sunucusu yönetiyorsan, bu komut senin en yakın dostlarından biri haline gelecek. Nginx veya Apache konfigürasyonlarını yönetirken, deployment scriptleri yazarken ya da paylaşılan kütüphaneleri düzenlerken ln olmadan işlerin çok daha zor olacağını garantiyle söyleyebilirim.
Temel mantığını şöyle açıklayayım: ln komutu, bir dosya ya da dizine başka bir isimden erişmeni sağlayan bağlantılar oluşturur. İki türü var: sembolik bağlantılar (symbolic links) ve sabit bağlantılar (hard links). Bunların arasındaki fark sandığından çok daha önemli, o yüzden ikisini de iyi anlamak gerekiyor.
Sabit Bağlantı (Hard Link) Nedir?
Sabit bağlantıyı anlamak için önce inode kavramını bilmen gerekiyor. Linux dosya sisteminde her dosyanın bir inode numarası vardır. Bu inode, dosyanın gerçek verisinin diskte nerede tutulduğunu, izinlerini, sahibini ve diğer meta verilerini saklar. Bir dosya adı aslında sadece bu inode numarasına bir referanstır.
Sabit bağlantı oluşturduğunda, aynı inode’a işaret eden ikinci bir dosya adı yaratmış olursun. Yani iki farklı isim, aynı veriye bakıyor. Orijinal dosyayı silsen bile, hard link varken veri diskten kalkmaz çünkü inode’a en az bir referans kaldığı sürece veri yaşamaya devam eder.
# Temel hard link oluşturma
ln /var/www/html/config.php /var/www/html/config_backup.php
# İki dosyanın aynı inode'a sahip olduğunu doğrula
ls -li /var/www/html/config.php /var/www/html/config_backup.php
Çıktıda her iki dosyanın da aynı inode numarasını göreceğini fark edeceksin. Bu, iki ismin gerçekten aynı veriye baktığının kanıtıdır.
Uyari: Sabit bağlantılar farklı dosya sistemleri (partition’lar) arasında çalışmaz. /home üzerindeki bir dosyaya /var üzerinden hard link oluşturamazsın. Bu sınırlamayı aklında tut.
Bilgi: Hard link’ler dizinler için oluşturulamaz. Sadece düz dosyalar (regular files) için geçerlidir. Dizin bağlantısı oluşturman gerekiyorsa sembolik bağlantı kullanman gerekecek.
Sembolik Bağlantı (Symbolic Link / Symlink) Nedir?
Sembolik bağlantı ise tamamen farklı bir mantıkla çalışır. Bir symlink, içinde başka bir dosyanın yolunu tutan özel bir dosyadır. Windows’taki kısayollara benzetebilirsin ama çok daha güçlü ve sistem düzeyinde entegre çalışıyor.
Symlink, farklı dosya sistemleri arasında çalışabilir, dizinlere link oluşturabilirsin ve orijinal dosya silindiğinde link kırık (dangling link) hale gelir. Bu son özellik hem avantaj hem dezavantajdır, duruma göre değerlendirmek gerekiyor.
# Temel sembolik bağlantı oluşturma (-s parametresi şart)
ln -s /var/www/html/sites/mysite.com /var/www/html/current
# Sembolik bağlantıyı doğrulama
ls -la /var/www/html/current
# Çıktı: lrwxrwxrwx 1 www-data www-data 28 ... current -> /var/www/html/sites/mysite.com
# Bağlantının nereye işaret ettiğini öğrenme
readlink /var/www/html/current
readlink -f /var/www/html/current # Tam gerçek yolu gösterir
Çıktıdaki o ok işareti (->), dosyanın bir symlink olduğunu ve nereye işaret ettiğini gösterir. İzin kısmındaki “l” harfi de bu dosyanın bir link olduğunun göstergesidir.
Hard Link ve Symlink Karşılaştırması
Özellik
Hard Link
Sembolik Link
Farklı dosya sistemi
Hayır
Evet
Dizin bağlantısı
Hayır
Evet
Orijinal silinirse
Veri korunur
Link kırılır
Farklı inode
Hayır (aynı)
Evet
Dosya boyutu
Orijinalle aynı
Yol uzunluğu kadar
Web sunucu kullanımı
Nadir
Çok yaygın
ln Komutunun Temel Parametreleri
Komutun sözdizimi şu şekildedir:
ln [SECENEK] KAYNAK HEDEF
# En sık kullanilan parametreler:
# -s : Sembolik link oluştur
# -f : Hedef varsa zorla üzerine yaz (force)
# -n : Hedef sembolik linkse dereferans etme
# -v : Ayrıntılı çıktı ver (verbose)
# -r : Göreceli sembolik link oluştur (relative)
# -b : Üzerine yazmadan önce yedek al (backup)
Mevcut Linki Güncellemek
Web sunucusu yönetiminde en sık karşılaşacağın senaryo, mevcut bir symlink’i güncellemektir. Örneğin yeni bir deployment yaptın ve “current” linkini yeni versiyona yönlendirmen gerekiyor.
# Yanlis yontem - bu hata verir ya da beklenmedik davranir
ln -s /var/www/html/releases/v2.0 /var/www/html/current
# Dogru yontem: -sfn kombinasyonu
ln -sfn /var/www/html/releases/v2.0 /var/www/html/current
# Detayli aciklama:
# -s : sembolik link
# -f : varsa uzerine yaz
# -n : hedef dizin linkse, onu takip etme
# Sonucu dogrula
ls -la /var/www/html/current
Uyari: -f parametresini -n olmadan kullanırsan ve hedef bir sembolik link ise, ln yeni linki hedefin içine oluşturabilir. Bu sessiz bir hatadır ve deployment’larında beklenmedik davranışlara yol açar. Her zaman -sfn kullan.
Web Sunucusu Senaryoları: Gerçek Hayattan Örnekler
Nginx: sites-available ve sites-enabled Yönetimi
Nginx kullanıyorsan bu pattern’i mutlaka biliyorsundur. Konfigürasyon dosyaları sites-available altında tutulur, aktif etmek için sites-enabled altına sembolik link oluşturulur. Bu yapı hem düzenli hem de güvenli bir yaklaşım sağlar.
# Yeni bir site konfigurasyonu olustur
nano /etc/nginx/sites-available/mysite.com
# Siteyi aktif et (sembolik link olustur)
ln -s /etc/nginx/sites-available/mysite.com /etc/nginx/sites-enabled/mysite.com
# Konfigurasyonu test et
nginx -t
# Nginx'i yeniden yukle
systemctl reload nginx
# Siteyi deaktif etmek icin linki sil (kaynak dosya kalir)
rm /etc/nginx/sites-enabled/mysite.com
# Tum aktif siteleri listele
ls -la /etc/nginx/sites-enabled/
Bu yaklaşımın güzelliği şu: sites-available altındaki konfigürasyonun kendisine hiç dokunmadan siteyi aktif/pasif edebiliyorsun. Bir şeyler ters giderse konfigürasyon hâlâ orada duruyor, sadece linki silip ekleyerek yönetiyorsun.
Apache: a2ensite ile Aynı Mantık
Apache’de a2ensite ve a2dissite komutları arka planda zaten ln kullanır. Ama bazen bunları bypass ederek doğrudan link oluşturman gerekebilir.
# Apache icin manuel sembolik link
ln -s /etc/apache2/sites-available/mysite.conf /etc/apache2/sites-enabled/mysite.conf
# Veya Apache'nin kendi aracini kullan (tercih edilen)
a2ensite mysite.conf
a2dissite mysite.conf
# SSL sertifikasi icin ornek link yapisi
ln -s /etc/letsencrypt/live/mysite.com/fullchain.pem /etc/ssl/certs/mysite.com.pem
ln -s /etc/letsencrypt/live/mysite.com/privkey.pem /etc/ssl/private/mysite.com.key
Zero-Downtime Deployment: Capistrano Tarzı
Bu senaryo gerçekten değerli. Bir web uygulamasını sıfır kesinti ile güncellemenin en klasik yolu sembolik link rotasyonudur. Capistrano, Deployer ve benzeri araçlar tam olarak bunu yapar.
# Dizin yapisi su sekilde olacak:
# /var/www/myapp/
# releases/
# 20240101120000/
# 20240115093000/
# 20240120150000/ <- en yeni
# shared/ releases/20240120150000 <- aktif versiyon
# Yeni deployment
NEW_RELEASE="/var/www/myapp/releases/$(date +%Y%m%d%H%M%S)"
mkdir -p $NEW_RELEASE
# Kodu kopyala / git clone yap
git clone https://github.com/user/myapp.git $NEW_RELEASE
# Paylasilan dizinleri linkle
ln -s /var/www/myapp/shared/uploads $NEW_RELEASE/public/uploads
ln -s /var/www/myapp/shared/.env $NEW_RELEASE/.env
# Yeni versiyonu aktif et (atomik islem)
ln -sfn $NEW_RELEASE /var/www/myapp/current
# Rollback icin bir onceki versiyona don
PREV_RELEASE=$(ls -t /var/www/myapp/releases/ | sed -n '2p')
ln -sfn /var/www/myapp/releases/$PREV_RELEASE /var/www/myapp/current
echo "Rollback tamamlandi: $PREV_RELEASE"
# Eski surumlerden sadece son 5'ini tut
cd /var/www/myapp/releases && ls -t | tail -n +6 | xargs rm -rf
Ipucu: ln -sfn ile symlink’i değiştirme işlemi atomiktir, yani yarım kalmaz. Bu yüzden Nginx veya Apache bu işlem sırasında asla kırık bir link görmez. Zero-downtime deployment’ın sırrı büyük ölçüde budur.
PHP Sürüm Yönetimi
Birden fazla PHP sürümü kurulu olan sunucularda hangi sürümün varsayılan olduğunu sembolik linklerle yönetebilirsin.
# Mevcut php linkini kontrol et
ls -la /usr/bin/php
readlink -f /usr/bin/php
# PHP 8.2'ye gec
update-alternatives --set php /usr/bin/php8.2
# Ya da manuel olarak:
ln -sfn /usr/bin/php8.2 /usr/local/bin/php
# PHP-FPM socket linkini kontrol et
ls -la /var/run/php/
# php-fpm.sock -> php8.2-fpm.sock gibi bir yapi gormeli
Göreceli ve Mutlak Yol Farkı
Sembolik link oluştururken mutlak yol mu göreceli yol mu kullanmalısın? Bu sorunun net bir cevabı var: genellikle mutlak yol kullanmak daha güvenlidir, ama bazı durumlarda göreceli yol tercih edilir.
# Mutlak yol ile sembolik link (tavsiye edilen)
ln -s /etc/nginx/sites-available/mysite.com /etc/nginx/sites-enabled/mysite.com
# Goreceli yol ile sembolik link
cd /etc/nginx/sites-enabled
ln -s ../sites-available/mysite.com mysite.com
# -r parametresi ile otomatik goreceli link
ln -sr /etc/nginx/sites-available/mysite.com /etc/nginx/sites-enabled/mysite.com
# Goreceli linkin icerigi
readlink /etc/nginx/sites-enabled/mysite.com
# Cikti: ../sites-available/mysite.com
Göreceli yollar, link ve hedef birlikte taşınacaksa mantıklıdır. Örneğin tüm yapıyı farklı bir sunucuya kopyalıyorsan göreceli linkler bozulmaz. Ama sabit bir sunucu yapısında mutlak yollar daha okunabilir ve sorun ayıklaması kolaydır.
Sık Karşılaşılan Sorunlar ve Çözümleri
Kırık Sembolik Linkler (Dangling Links)
Hedef dosya veya dizin silindiğinde symlink kırık kalır. Bunu tespit etmek ve temizlemek için şunları kullanabilirsin:
# Kirık linkleri bul
find /etc/nginx/sites-enabled -type l ! -exec test -e {} ; -print
# Daha kapsamlı arama
find /var/www -maxdepth 3 -xtype l 2>/dev/null
# Kirık linkleri otomatik sil (dikkatli kullan!)
find /etc/nginx/sites-enabled -type l ! -exec test -e {} ; -delete
# Link zinciri takibi
ls -la /etc/nginx/sites-enabled/mysite.com
readlink -f /etc/nginx/sites-enabled/mysite.com # Son hedefi goster, kirıksa hata verir
Uyari: Kırık sembolik linkleri toplu silerken çok dikkatli ol. Özellikle /etc altında otomatik silme işlemi yapmadan önce mutlaka ne bulduğunu listele ve gözden geçir.
İzin Sorunları
Sembolik linkin izinleri her zaman lrwxrwxrwx görünür, bu normaldir. Önemli olan hedef dosyanın izinleridir. Ama link oluştururken de dikkat edilmesi gereken noktalar var:
# Link uzerindeki izinler (her zaman 777 gorunur, yaniltici olma)
ls -la /etc/nginx/sites-enabled/mysite.com
# lrwxrwxrwx 1 root root 42 Jan 20 15:00 mysite.com -> /etc/nginx/sites-available/mysite.com
# Asıl onemli olan hedef dosyanin izni
ls -la /etc/nginx/sites-available/mysite.com
# -rw-r--r-- 1 root root 1234 Jan 20 14:00 mysite.com
# www-data kullanicisi linke erisemiyorsa, hedefin izinlerini kontrol et
namei -l /etc/nginx/sites-enabled/mysite.com # Tum yol boyunca izinleri goster
Log Yönetiminde ln Kullanımı
Web sunucularında log yönetimi de ln’nin sıkça kullanıldığı bir alan. Farklı lokasyonlardaki logları merkezi bir yere toplamak ya da logrotate yapısını düzenlemek için faydalanabilirsin.
Bilgi: Docker imajlarında /dev/stdout’a sembolik link oluşturmak yaygın bir pattern’dir. Bu sayede uygulama log dosyasına yazarken aslında container loglarına yazıyor, docker logs komutuyla takip edebiliyorsun.
Özet: Ne Zaman Hangisini Kullanmalısın?
Pratikte bakacak olursan, web sunucusu yönetiminde neredeyse her zaman sembolik link kullanırsın. Hard link’lerin kullanım alanı daha çok yedekleme araçları ve dosya sistemi düzeyindeki optimizasyonlardır. Ama ikisini de bilmek işinin gereğidir.
Nginx/Apache site konfigürasyonlarını aktif/pasif etmek icin sembolik link kullan
Zero-downtime deployment ve versiyon yönetimi icin sembolik link kullan
Birden fazla yerde erişilmesi gereken paylaşılan konfigürasyon dosyaları icin sembolik link kullan
Log merkezi yönetimi icin sembolik link kullan
Yedekleme araçları (rsync –hard-links gibi) disk alanı optimizasyonu icin hard link kullan
Orijinal silindiğinde verinin kaybolmamasını istediğin durumlarda hard link kullan
Sonraki Adımlar
ln komutunu iyi kavradıktan sonra deployment otomasyonu tarafına bakmanı tavsiye ederim. Bash ile basit bir deployment scripti yazmak, ln -sfn komutunu gerçek ortamda nasıl kullanacağını somutlaştıracak. Bunun yanında inotifywait ile symlink değişikliklerini izleyebileceğini, rsync’in –copy-links ve –keep-dirlinks parametreleriyle link’leri nasıl ele aldığını ve logrotate’in postrotate scriptlerinde ln kullanımını da araştırabilirsin. Bir sonraki yazıda Nginx’in sites-available/sites-enabled yapısını sıfırdan kurarak üzerine otomatik SSL entegrasyonu eklemeyi ele alacağım.
Bu site, deneyiminizi geliştirmek ve ziyaretçi istatistikleri toplamak için çerezler kullanır.
Gizlilik Politikası