Linux Komut Satırı: Temel Kodlar ve Püf Noktaları

Linux Komut Satırı: Temel Kodlar (ls, cd, mkdir) Hakkında Bilmeniz Gerekenler

Linux Komut Satırı: Temel Kodlar (ls, cd, mkdir) aslında göz korkutan siyah ekranın arkasındaki en basit, en işe yarar üç arkadaş. Dosya yöneticisinde tıklaya tıklaya yaptığın her şey, terminalde bu üç komutla başlıyor. İster yeni başlayan ol, ister yıllardır root olarak yaşayan biri; şunu çok net söyleyebilirim: Bu üç komut parmaklarının ucuna yerleşmeden terminalle arandaki mesafe hiç kapanmıyor.

İşin güzel yanı şu: Karmaşık gibi görünen çoğu sunucu problemi, dosya sisteminde düzgün gezinebilmek ve doğru klasörde doğru komutu çalıştırmakla çözülüyor. SSH ile sunucuya bağlandığında “Ben şu an neredeyim?” sorusunu çözen pwd, “Burada ne var?” sorusunu çözen ls ve “Yeni proje için klasör açmam lazım” dediğinde devreye giren mkdir ile temel kası oluşturuyorsun. Bu yazıda, terminali ilk kez açan bir kullanıcının da, yoğun trafikli bir projeyi yöneten sistem yöneticisinin de işine yarayacak seviyede, sade ama profesyonel bir çerçeve kuracağız.

Şöyle düşünün: Grafik arayüz (GNOME, KDE, cPanel dosya yöneticisi vs.) aslında sadece arkada bu komutları çalıştıran bir kabuk. Sen klasör simgesine tıkladığında, sistem içeride ls ile liste alıyor; klasör taşıdığında, arka planda başka bir komut zinciri dönüyor. Yani Linux komut satırı ve temel kodlar, sistemle en doğrudan konuşabildiğin dil.

Bu üçlü neden bu kadar kritik?

• ls: Bulunduğun dizinde hangi dosyalar, klasörler, izinler ve sahiplikler var; hepsini gösterir. Sunucuda “dosya yok” sanıp saatler harcayanların çoğu aslında yanlış dizinde ls bakıyordu.
• cd: Dizinler arasında gezinmeyi sağlar. Yanlış dizinde çalışılan her komut, potansiyel bir felaket. “Yanlış klasörde rm -rf çalıştırdım” diyenlerin dramatik hikâyeleri buradan geliyor.
• mkdir: Yeni klasör oluşturur. Basit gibi görünür ama proje yapısını düzenli kurup kurmaman, ileride yönetilebilirlik farkı olarak geri döner.

Aslında durum tam olarak şöyle: Terminal bilmek, “linuxçu” olmak için değil, kontrolü kaybetmemek için şart. Grafik arayüz çöker, SSH her zaman oradadır.

Bir efsaneyi de aradan çıkaralım: “Sunucu paneli varken komut satırına ihtiyaç yok.” Bu, gerçekte en çok sorun çıkaran bakış açısı. Panel güzel, işleri kolaylaştırıyor; ama panel arayüzü de sonuçta sınırlı. Gün geliyor, tek satırlık bir cd /var/www && ls -lah çıktısı, panelde üç sayfa gezeceğin işi saniyede çözüyor.

Yapılandırma ve Yönetim: Adım Adım

Kaynak Yönetimi – Limitleri Zorlamayın

Şimdi diyeceksin ki, “ls, cd, mkdir ile kaynak yönetiminin ne alakası var?” Oldukça fazla. Sunucu kaynaklarını (CPU, RAM, disk I/O) verimli kullanmanın başlangıç noktası, nerede ne çalıştığını doğru okumak.

İşin püf noktası şurada: Yüksek CPU kullanımı uyarısı aldığında ilk refleksin servisleri kapatmak olmamalı. Önce dizin yapısını doğru okuyup, hangi projede ne çalışıyor, nerede cache var, loglar nerede şişmiş; bunlara bakman gerekiyor.

• cd /var/log → Log dizinine geç.
• ls -lah → Hangi log dosyası şişmiş, boyutlar ne durumda bak.
• Genelde ilk kontrol edilecek dosyalardan biri: /var/log/syslog veya /var/log/messages (dağıtıma göre değişir).

Dürüst olmak gerekirse, “Aşırı kaynak kullanımı” uyarısı geldiğinde, kullanıcıların yarısı doğrudan RAM veya CPU yükseltmeye koşuyor. Önce bir ls -lah ile log dizinine bakıp, 20 GB’lık tek bir error log dosyasını fark etseler, sorun 2 dakikada çözülmüş olacak. Tıpkı bir araba motoru gibi, sunucular da yüksek devirde (trafikte) doğru soğutmaya (kaynağa) ihtiyaç duyar; ama önce kaputu açıp nereye baktığını bilmen lazım.

Güvenlik Duvarı ve Port Ayarları

“Dış dünyaya açık her port, açık bir penceredir” cümlesi terminalde çok daha anlamlı. SSH ile bağlandığın sunucuda her işlem, aslında bir kapıdan içeri girip çıkmak gibi. ls ile hangi servisin hangi dizinde durduğunu, cd ile konfigürasyon dosyalarına ulaşmayı öğrenmeden güvenlik sağlanmıyor.

Basit ama kritik birkaç nokta:

• SSH portu: Varsayılan 22 portunu değiştirmek her şeyi çözmez ama “ilk taramada bulunma” ihtimalini azaltır. Konfigürasyon dosyası genelde: /etc/ssh/sshd_config. Buraya ulaşmak için:
  • cd /etc/ssh
  • ls ile dosyaları gör.
• FTP: Eğer kullanmıyorsan, kapatmak en temizi. Dürüst olayım, çoğu modern projede SFTP/SSH varken klasik FTP’ye gerçekten ihtiyaç kalmadı.
• Firewall: ufw / firewalld kullanıyorsan, hangi portların açık olduğunu bilmeden “site açılmıyor” diye gün harcayabilirsin. Bağlantı sorunu olduğunda ilk bakacağın yerlerden biri burası.

Ek olarak, eğer siteni web hosting üzerinde barındırıyorsan, çoğu firewall kuralı sağlayıcı tarafından yönetilir. Ama VDS veya cloud sunucu kullanıyorsan, port ve firewall yönetimi artık senin sorumluluğunda; terminal bilgisi bu noktada zorunlu hale geliyor.

Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi

İşin bir de yazılım tarafı var. Panelden PHP versiyonunu seçmek kolay, ama hangi projenin hangi dizinde hangi versiyonu kullandığını anlamak için yine iş ls ve cd seviyesine iniyor.

“En güncel sürüm en iyisidir” kafası burada genelde ters teper. Evet, PHP 8.x performans ve güvenlik açısından çok iyi; ama eski bir CMS veya custom yazılım kullanıyorsan, uyumsuzlukla siteni komple devre dışı bırakabilirsin.

• Önce proje dizinine geç: cd /var/www/proje-adi
• ls ile composer.json, config.php gibi dosyalara bak.
• Dökümantasyonda tavsiye edilen minimum PHP sürümünü kontrol et.

Veritabanı tarafında “altın kural” şu: Okuma ve yazma dengesini iyi kur, gereksiz sorgu attırma. Genelde kullanıcılarımızdan duyduğumuz en büyük şikayet şu oluyor: “Site çok yavaşladı, sunucu mu yetmiyor?” İnceleyince görüyoruz ki, sayfa başına yüzlerce gereksiz sorgu çalışıyor, index’ler eksik. En güçlü donanım, kötü tasarlanmış veritabanını kurtarmıyor.

Bu arada, performansınızı artırmak için Linux sayfamızdaki diğer çözümlere de bakabilirsiniz.

Uygulama: Kurulum ve Yayına Alma

Terminali açın, şu komutu girin demiyorum ama mantık şu: Her şey dizin yapısını anlamakla başlıyor. Linux komut satırı: Temel kodlar (ls, cd, mkdir) ile önce zemini hazırlıyorsun.

1. Bağımlılıkları kontrol et: Projenin ihtiyaç duyduğu PHP modülleri, veritabanı türü, cache sistemi… Bunlar genelde proje dökümantasyonunda yazıyor. O dizine cd ile gidip config dosyalarını incelemeden, “neden çalışmıyor” sorusunun cevabını bulamazsın.
2. Dizin yapısını kur:
   • mkdir /var/www/proje-adi
   • Gerekirse alt klasörler: mkdir -p /var/www/proje-adi/public
   • Sonra cd /var/www/proje-adi ile projenin kalbine gir.
3. Dosyaları yerleştir: SFTP/rsync/git ile projeyi bu dizine al. Ardından ls ile dosyaların düzgün gelip gelmediğini kontrol et.
4. Config’i düzenle: Veritabanı adı, kullanıcı adı, şifre, host bilgisi… Hepsi genelde .env veya config.php gibi dosyalarda. Bunlara ulaşmak için yine ls ile dosya listesini okuyorsun.

Genelde düzgün planlanmış bir kurulumu, dizin yapısı zaten hazırsa, 5–10 dakikada ayağa kaldırmak mümkün. Asıl zaman kaybı, “proje nereye kurulmuş, hangi klasör web root, loglar nerede birikiyor” sorularına cevap ararken yaşanıyor.

Sık Karşılaşılan Sorunlar ve Pratik Çözümler

Birkaç ek pratik sorun ve Linux komut satırı ile ilişkisini de açalım:

• “Dosya yok” hatası: Çoğunlukla yanlış dizindesin.
  • pwd ile bulunduğun dizini kontrol et.
  • ls ile gerçekten o dosya var mı bak.
• “Permission denied” hatası:
  • ls -l ile dosya/klasör izinlerine bak.
  • Gerekiyorsa ilgili kullanıcıya okuma/yazma izni ver (burada da dikkat, gelişi güzel 777 vermek çözüm değil, yeni problem).
• “404 ama dosya aslında orada” durumu:
  • Web sunucusunun (Apache/Nginx) hangi dizini DocumentRoot olarak kullandığını kontrol et.
  • Yanlış dizine deploy ettiysen, cd ile doğru web root’a geçip ls ile dosyaları teyit et.

Sıkça Sorulan Sorular

Linux komut satırı: Temel kodlar (ls, cd, mkdir) kullanmak güvenli mi?

Evet, bu üç komut başlı başına son derece güvenli; dosya silmez, sistem bozmaz. Tehlike genelde bunlarla yanlış dizine gidip, sonra agresif komutlar (örneğin hatalı rm -rf) çalıştırıldığında ortaya çıkıyor. Yani risk, komutlardan çok, yanlış yerde yanlış işi yapmaktan geliyor. Dizini her zaman pwd ile teyit etmek iyi bir refleks.

Fiyat/Performans dengesini nasıl kurarım?

Aslında durum şöyle: Önce ihtiyacını doğru ölç, sonra kaynak al. Küçük–orta ölçekli projelerde iyi optimize edilmiş bir web hosting planı, yanlış yapılandırılmış pahalı bir VDS’ten daha iyi performans verir. Yük artınca VDS veya sanal sunucu tarafına geçersin; ama ister paylaşımlı ister dedicated olsun, terminalde temel komutları bilmek maliyeti de performansı da daha iyi yönetmeni sağlar.

Taşıma (Migration) işlemi zor mu?

Kâğıt üzerinde zor gibi görünür, pratikte doğru araçlarla oldukça yönetilebilir. SSH ile eski sunucudan yeni sunucuya geçerken, cd ile doğru dizinlere girip, ls ile dosya yapısını kontrol edip, yeni tarafta aynı yapıyı mkdir ile kurmak işin temel adımları. Bilhost tarafında bu süreç büyük ölçüde otomatik ve destekli ilerliyor; WordPress gibi sistemlerde özellikle, yapılandırma ve taşıma için ek araçlar kullanıyoruz. Yani “Dosyalarım kaybolur mu, site günlerce kapalı kalır mı?” korkusu yaşamadan, teknik ekibin yönlendirmesiyle işi halledebiliyorsun.

Sonuç

İşin özü şu: Linux komut satırı: Temel Kodlar (ls, cd, mkdir) öğrenmeden sunucu yönetmek, gözün kapalı araba kullanmaya benziyor. Bir süre gidersin ama ilk virajda risk başlar. Terminalde nereye baktığını, hangi dizinde durduğunu ve klasör yapını nasıl kurduğunu bildiğinde; ister shared hosting olsun, ister VDS, ister cloud sunucu, operasyonun çok daha öngörülebilir hale gelir.

Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma hayat kurtarır. Eğer bir yerde takılırsan biz buradayız, yorumlarda sorularını bekliyorum. Ayrıca, projeni büyütmeyi düşünüyorsan, uygun altyapı için WordPress hosting veya cloud sunucu seçeneklerine de göz atabilirsin.