Linux sistem yönetimi

ln Komutu: Sembolik ve Sabit Bağlantı Oluşturma Rehberi

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.

# Dagitik loglari merkezi klasore topla
mkdir -p /var/log/webapps
ln -s /var/log/nginx/mysite.access.log /var/log/webapps/mysite-access.log
ln -s /var/log/nginx/mysite.error.log /var/log/webapps/mysite-error.log
ln -s /var/log/php8.2-fpm.log /var/log/webapps/php-fpm.log

# /dev/stdout ve /dev/stderr'a link - Docker konteynerlerinde yaygin
# Bazi uygulamalarda log dosyasini stdout'a yonlendirmek icin:
ln -sf /dev/stdout /var/log/nginx/access.log
ln -sf /dev/stderr /var/log/nginx/error.log

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.

rm Komutu ile Dosya Silme: Web Sunucusunda Güvenli Kullanım Rehberi

Linux’ta rm komutu basit görünür ama yanlış kullanıldığında web sunucunu dakikalar içinde çökertebilir. Bu yazıda rm’nin tüm inceliklerini, güvenli kullanım yöntemlerini ve gerçek sunucu senaryolarını ele alıyoruz.

Linux dünyasında bazı komutlar vardır ki görünürde masum, ama elinde patlayacak dinamit gibidir. rm komutu da tam olarak bu kategoriye girer. Web sunucusu yönetiyorsan ve terminale “rm -rf /” yazarsan ne olacağını merak ediyorsan, cevap şu: bir daha o sunucuyu göremezsin. Abartmıyorum.

Ama paniklemene de gerek yok. rm komutu doğru anlaşıldığında ve doğru kullanıldığında vazgeçilmez bir araçtır. Eski log dosyalarını temizlemek, geçici upload dosyalarını silmek, eski deployment kalıntılarını ortadan kaldırmak — bunların hepsinde rm kullanırsın. Bu yazıda hem temel kullanımı hem de bir web sunucusu yöneticisi olarak günlük hayatta karşılaşacağın gerçek senaryoları ele alacağız.

rm Komutu Nedir ve Nasıl Çalışır?

rm, “remove” kelimesinin kısaltmasıdır ve Linux/Unix sistemlerde dosya ile dizinleri silmek için kullanılır. Windows’taki Delete tuşundan temel farkı şudur: silinen dosyalar Geri Dönüşüm Kutusu’na gitmez. Silinen dosya gider, noktası.

Teknik olarak konuşmak gerekirse, rm komutu dosyanın kendisini değil, dosya sistemindeki inode bağlantısını siler. Eğer o dosyaya başka hard link yoksa, inode ve veri blokları serbest bırakılır. Bu yüzden bazen özel araçlarla (extundelete, testdisk gibi) silinen dosyaları kurtarmak mümkün olabilir — ama buna güvenerek çalışma, her silme işlemini geri dönüşü olmayan bir işlem olarak gör.

Temel Söz Dizimi

rm komutunun temel kullanımı son derece sade:

rm [seçenekler] [dosya/dizin]

# Tek dosya silmek
rm dosya.txt

# Birden fazla dosya silmek
rm dosya1.txt dosya2.txt dosya3.log

# Belirli bir pattern ile silmek
rm *.log

# Belirli bir dizindeki tüm .tmp dosyalarını silmek
rm /var/www/html/uploads/*.tmp

Bu kadar basit. Ama işte tam burada dikkatli olmak gerekiyor. Yukarıdaki son komuta bak: /var/www/html/uploads dizinindeki tüm .tmp dosyalarını silmek istiyorsun. Eğer yanlışlıkla bir boşluk karakteri koyarsan ya da dizin adını yanlış yazarsan, sonuçlar beklenmedik olabilir.

Önemli Parametreler ve Anlamları

Parametre	Uzun Hali	Ne Yapar?
-r	–recursive	Dizini ve içindeki her şeyi siler
-f	–force	Var olmayan dosyalar için hata vermez, onay istemez
-i	–interactive	Her silme işleminden önce onay ister
-I	–interactive=once	3’ten fazla dosya veya -r kullanılıyorsa bir kez onay ister
-v	–verbose	Her silinen dosyayı ekrana yazar
-d	–dir	Boş dizinleri siler (rmdir gibi)

Web Sunucusunda Gerçek Kullanım Senaryoları

Teoriyi bir kenara bırakalım ve asıl konuya gelelim: web sunucusu yönetirken rm’yi nerede, nasıl kullanırsın?

Senaryo 1: Eski Log Dosyalarını Temizleme

Nginx veya Apache çalıştırıyorsun ve /var/log dizini dolmaya başladı. Disk dolunca web sunucusu yeni bağlantılara cevap veremez hale gelir. Bu yüzden log rotasyonu ve temizliği kritik önem taşır. Logrotate kullanıyor olsan bile, bazen manuel müdahale gerekir:

# 30 günden eski nginx access log dosyalarını bul ve sil
find /var/log/nginx/ -name "access.log.*" -mtime +30 -exec rm -v {} ;

# 7 günden eski tüm .gz uzantılı sıkıştırılmış logları sil
find /var/log/apache2/ -name "*.gz" -mtime +7 -exec rm -v {} ;

# Silmeden önce ne silineceğini gör (dry-run)
find /var/log/nginx/ -name "*.log.*" -mtime +30 -print

Ipucu: rm’yi doğrudan find ile kullanmadan önce mutlaka -print ile ne silineceğini gör. Bu alışkanlık seni bir gün büyük bir felaketten kurtarabilir.

Senaryo 2: Upload Klasöründeki Geçici Dosyaları Temizleme

PHP tabanlı bir web uygulaması çalıştırıyorsun ve kullanıcılar dosya yüklüyor. Yarım kalan yüklemeler, işlenmeyi bekleyen geçici dosyalar, hatalı upload’lar zamanla birikir. Bunu düzenli olarak temizlemek hem disk alanı hem de güvenlik açısından önemli.

# /var/www/html/uploads dizinindeki 24 saatten eski .tmp dosyalarını sil
find /var/www/html/uploads/ -name "*.tmp" -mtime +1 -exec rm -f {} ;

# Boş dizinleri de temizle
find /var/www/html/uploads/ -type d -empty -exec rm -d {} ;

# İşlem sonrası ne kadar yer açıldığını kontrol et
df -h /var/www/

Senaryo 3: Eski Deployment Dosyalarını Kaldırma

Manuel veya CI/CD ile deployment yapıyorsan, eski versiyonlar birikebilir. Bir WordPress güncellemesinden sonra eski plugin dosyalarını temizlemek ya da manuel olarak yüklediğin eski bir PHP uygulamasının kalıntılarını kaldırmak gerekebilir:

# Eski deployment klasörünü sil (dikkatli ol, önce ls ile kontrol et)
ls -la /var/www/
rm -rf /var/www/app_v1.2.3/

# Aktif deployment sembolik linkini değiştirmeden önce eski versiyonu kaldır
rm -rf /var/www/releases/20231101120000/

# Belirli dosya uzantılarını recursive olarak sil (örn: .bak dosyaları)
find /var/www/html/ -name "*.bak" -type f -delete

Uyari: rm -rf komutunu çalıştırmadan önce mutlaka pwd ile hangi dizinde olduğunu kontrol et ve silmek istediğin yolu tam olarak belirt. Eksik bir slash, yanlış bir dizin adı büyük sorunlara yol açabilir.

rm -rf: Güçlü Ama Tehlikeli

Bu parametre kombinasyonunu ayrıca ele almak istiyorum çünkü en çok kullanılan ve en tehlikeli olanı bu. -r recursive (alt dizinlerle birlikte), -f ise force (onay istemeden, hata görmezden gelerek) demek. İkisini birleştirdiğinde önüne gelen her şeyi süpüren bir komut elde edersin.

Gerçek bir hikaye anlatayım: Bir sysadmin, eski bir web uygulamasını kaldırmak için şu komutu çalıştırmak istiyor: rm -rf /var/www/eski-uygulama. Ama yanlışlıkla araya bir boşluk giriyor: rm -rf /var/www/ eski-uygulama. Bu durumda sistem önce /var/www/ dizinini, ardından eski-uygulama adlı dosyayı silmeye çalışır. /var/www/ dizininin tüm içeriği gider.

Uyari: rm -rf komutunu root kullanıcısı olarak çalıştırırken son derece dikkatli ol. Modern Linux sistemleri rm -rf / komutunu –no-preserve-root parametresi olmadan çalıştırmana izin vermez, ama bu seni her şeyden korumaz. /var/www, /etc, /home gibi kritik dizinlerde rm -rf kullanmadan önce iki kez düşün.

Güvenli rm Kullanımı için Pratik Yöntemler

1. -i Parametresi ile Onaylı Silme

Eğer kritik bir dizinde çalışıyorsan ve tam olarak emin değilsen, -i parametresini kullan. Her dosya için senden onay ister:

# Her silme için onay iste
rm -i *.log

# Recursive silme için bir kez onay iste (-I büyük harf)
rm -rI /var/www/eski-klasor/

# Önce ne silineceğini listele, sonra karar ver
ls -la /var/www/html/cache/
rm -riv /var/www/html/cache/

2. Alias ile Güvenli rm Tanımla

Bazı sysadminler rm komutunu doğrudan çağırmak yerine, her zaman onaylı çalışması için alias tanımlar. Bu özellikle yeni başlayan ekip üyeleri için iyi bir pratiktir:

# ~/.bashrc veya ~/.bash_aliases dosyasına ekle
alias rm='rm -i'

# Alias'ı aktif et
source ~/.bashrc

# Eğer bir kez onaysız çalıştırmak istersen
rm -rf /gecici/klasor/
# veya
command rm -rf /gecici/klasor/

Bilgi: Alias tanımladıktan sonra rm komutunun her zaman -i ile çalışacağını unutma. Script’lerin içinde rm kullanıyorsan, orada da bu davranışı dikkate alman gerekir. Script’lerde genellikle rm veya command rm kullanmak daha güvenlidir.

3. trash-cli: Geri Dönüşüm Kutulu rm Alternatifi

Eğer silme işlemlerinde biraz güvenlik ağı istiyorsan, trash-cli aracını kullanabilirsin. Bu araç dosyaları direkt silmek yerine önce bir çöp klasörüne taşır:

# trash-cli kur (Debian/Ubuntu)
apt install trash-cli

# Dosyayı çöpe gönder
trash-put /var/www/html/gereksiz-dosya.php

# Çöp kutusunu listele
trash-list

# Çöp kutusunu boşalt
trash-empty

# Yanlış sildiysen kurtar
trash-restore

Production sunucularda trash-cli kullanmak tartışmalı bir konu. Disk dolma riskini artırır, ama kritik dosyaların yanlışlıkla silinmesi riskini azaltır. Ekibinin deneyim seviyesine göre karar ver.

Web Sunucusunda Sık Yapılan Hatalar

Yıllar içinde gördüğüm, işittiğim ve ne yazık ki zaman zaman yaşadığım hataları listeleyelim:

Dizin değişkeninin boş olması: rm -rf $APP_DIR/ komutunda APP_DIR değişkeni boşsa rm -rf / çalışır
Wildcard’ı yanlış kullanmak: rm *.php gibi bir komut mevcut dizindeki tüm PHP dosyalarını siler, hangi dizinde olduğundan emin ol
Sembolik linklerin hedefini silmek: rm -rf ile sembolik bir dizini silmeye çalışırken hedef dizini de silebilirsin
root olarak çalışırken dikkatsiz olmak: sudo ile çalışırken sistem dosyalarını silmek çok kolaydır
Production ve test sunucularını karıştırmak: Birden fazla terminal penceresi açık tutup yanlış pencerede komut çalıştırmak

Bash Script’lerinde rm Kullanımı

Otomatik temizlik script’leri yazarken rm’yi kullanmak kaçınılmaz. Ama script içinde rm kullanırken daha da dikkatli olmak gerekiyor, çünkü bir hata tüm sistemde otomatik olarak çalışabilir.

#!/bin/bash
# Güvenli temizlik scripti örneği

set -euo pipefail  # Hata durumunda dur, tanımsız değişkende dur

# Değişkenleri tanımla
WEB_ROOT="/var/www/html"
LOG_DIR="/var/log/nginx"
MAX_AGE_DAYS=30

# Kritik kontrol: değişken boş mu?
if [ -z "$WEB_ROOT" ] || [ -z "$LOG_DIR" ]; then
    echo "HATA: Dizin değişkenleri boş olamaz!"
    exit 1
fi

# Dizin var mı kontrol et
if [ ! -d "$WEB_ROOT/cache" ]; then
    echo "Cache dizini bulunamadı, atlanıyor."
else
    echo "Cache temizleniyor..."
    find "$WEB_ROOT/cache" -type f -mtime +1 -delete
    echo "Cache temizlendi."
fi

# Eski logları temizle
echo "$MAX_AGE_DAYS günden eski loglar temizleniyor..."
find "$LOG_DIR" -name "*.gz" -mtime +$MAX_AGE_DAYS -exec rm -v {} ;

echo "Temizlik tamamlandi."
df -h $WEB_ROOT $LOG_DIR

Ipucu: Script’lerin başına set -euo pipefail eklemek iyi bir alışkanlıktır. -e herhangi bir komut hata verirse script’i durdurur, -u tanımlanmamış değişkeni kullanmaya çalışırsan hata verir, -o pipefail ise pipeline’daki hataları yakalar. Bu üç ayar, rm içeren otomatik script’lerde kritik öneme sahiptir.

Silinen Dosyaları Kurtarma Girişimi

Teorik olarak ele alalım: yanlışlıkla bir dosyayı sildiysen ne yaparsın? Önce paniği bırak, sonra adım adım düşün.

Dosya hala açık bir process tarafından kullanılıyorsa /proc/[pid]/fd/ üzerinden kurtarılabilir
ext4 dosya sisteminde testdisk veya extundelete araçlarıyla kurtarma denenebilir
Disk üzerine yeni yazma yapılmadan önce ne kadar hızlı müdahale edersen o kadar iyi
En güvenli çözüm her zaman yedeğe dönmektir — backupsuz çalışma

# Açık dosya tanımlayıcılarını kontrol et
# Silinmiş ama hala açık olan dosyaları gösterir
lsof | grep deleted

# Eğer process bulunursa, içeriği kurtar
# Örnek: PID 1234, fd 3 numaralı dosya tanımlayıcısı
cat /proc/1234/fd/3 > /tmp/kurtarildi.txt

# Dosya sistemi durumunu kontrol et (unmount gerekir)
# extundelete sadece unmount edilmiş partition üzerinde çalışır
extundelete /dev/sda1 --restore-all

Uyari: Silme işlemi sonrası kurtarma denemesi yaparken hedef partition’a asla yeni veri yazma. Kurtarmayı farklı bir disk üzerine yap. Her yeni yazma işlemi silinen verinin üzerine yazabilir ve kalıcı kayba yol açar.

rm ve Web Sunucusu Güvenliği

Web sunucusu yönetirken rm komutunu güvenlik bağlamında da düşünmek gerekiyor. Saldırganlar web uygulamasına sızdığında bazen dosyaları silmeye çalışabilir ya da zararlı dosyalar bırakabilir. Bu yüzden özellikle kritik web dizinlerinde dosya izinlerini doğru yapılandırmak önemli.

Öte yandan, web uygulamasının kendisinin rm komutunu tetikleyecek shell komutları çalıştırıp çalıştıramayacağını da kontrol altında tutmalısın. PHP uygulamalarında exec(), system(), passthru() gibi fonksiyonların mümkünse devre dışı bırakılması veya en azından kısıtlanması gerekir.

Hizli Referans: rm Komutunun En Sık Kullanılan Formları

Komut	Ne Yapar?	Ne Zaman Kullan?
rm dosya.txt	Tek dosya siler	Belirli bir dosyayı silerken
rm -i dosya.txt	Onay sorarak siler	Kritik dizinlerde çalışırken
rm -f dosya.txt	Hata vermeden siler	Script’lerde, dosya olmayabilir
rm -r dizin/	Dizini recursive siler	Dizin kaldırırken
rm -rf dizin/	Onaysız recursive siler	Emin olduğunda hızlı temizlikte
rm -v dosya.txt	Verbose, işlemi gösterir	Ne silindiğini takip ederken
rm — -dosya.txt	Tire ile başlayan dosyayı siler	Özel isimli dosyalarda

Ozet

rm komutu Linux sistemlerde dosya ve dizin silmenin temel yoludur. Basit söz dizimine karşın, özellikle web sunucusu ortamlarında yanlış kullanıldığında ciddi hasara yol açabilir. -r ve -f parametrelerini birlikte kullanırken her zaman dikkatli ol, değişken tabanlı yolları doğrula, ve önemli işlemlerden önce ne sileceğini gözden geçir.

Otomatik script’lerde set -euo pipefail kullanmak, değişken boşluk kontrolü yapmak ve silme öncesi find ile önizleme almak gibi alışkanlıklar, zamanla seni büyük felaketlerden koruyacak. Ayrıca ne kadar deneyimli olursan ol, backup almayı ihmal etme — rm’nin geri alınamaz olduğunu her zaman aklında tut.

Sonraki Adimlar

rm komutuna hakim olduysan, sıradaki adımlar şunlar olabilir:

find komutu ile rm’yi birlikte kullanmayı derinlemesine öğren, karmaşık temizlik senaryolarını handle etmek için gerekli
rsync ile yedekleme kurarak silme işlemleri öncesi güvenli bir ağ oluştur
logrotate yapılandırmasını öğren, log dosyalarını manuel rm ile silmek yerine otomatize et
cron job’ları ile düzenli temizlik script’leri yaz ve bunları rm yerine find -delete kombinasyonuyla güvenli hale getir
ZFS veya Btrfs gibi snapshot destekleyen dosya sistemlerini araştır, anlık görüntüler sayesinde yanlış silme işlemlerini kolayca geri alabilirsin