Bu kapsamlı rehberde; Keyhel Panel’de Jailed SSH ortamında güvenlikten ödün vermeden, gerekli izinleri ayarlamayı, NVM (Node Version Manager) kullanarak Node.js kurmayı ve uygulamalarınızı PM2 ile 7/24 kesintisiz nasıl çalıştıracağınızı adım adım anlatıyoruz.

1. Adım: Ön Hazırlık – “Ek İkili Dosyalar” ve Kütüphane İzinleri

Jailed SSH (Hapishane) ortamı, kullanıcıyı sadece belli başlı komutlarla sınırlandırır. NPM’in paketleri indirebilmesi, zipli dosyaları açabilmesi ve özellikle Vite/Rollup gibi modern araçların Linux çekirdek kütüphanelerine ulaşıp derleme (build) yapabilmesi için sunucu panelinizden bazı komutlara izin vermeniz gerekir.

Hosting panelinizden (Örn: KeyHelp’te Yapılandırma > Sınırlandırılmış SSH > Ek İkili Dosyalar bölümüne) aşağıdaki listeyi eksiksiz olarak ekleyin ve kaydedin:

/usr/bin/node
/usr/bin/npm
/usr/local/bin/pm2
/usr/bin/sed
/usr/bin/awk
/usr/bin/tr
/usr/bin/uname
/usr/bin/tar
/usr/bin/gzip
/usr/bin/xz
/usr/bin/sort
/usr/bin/grep
/usr/bin/tail
/usr/bin/head
/usr/bin/cut
/usr/bin/wc
/usr/bin/dirname
/usr/bin/find
/usr/bin/tee
/usr/bin/sha256sum
/usr/bin/rm
/usr/bin/cp
/usr/bin/mv
/lib/x86_64-linux-gnu/librt.so.1
/usr/lib/x86_64-linux-gnu/librt.so.1
/lib64/librt.so.1

Not: Listenin sonundaki librt.so.1 yolları, Vite ve Rollup kullanan projelerde derleme sırasında alınan Error: librt.so.1: cannot open shared object file (ERR_DLOPEN_FAILED) hatasının kesin çözümüdür.

2. Neden Jailed SSH’ta Standart Node.js Kurulumu Çöker?

İzinleri verdikten sonra bile, sistem sizi genellikle /www veya /home/kullaniciadi gibi bir dizine hapseder. Ancak Node.js ve NPM, kurulum ve önbellek (cache) işlemleri için ana sunucu dizinlerine (/.npm) erişmeye çalışır.

Bu durum karşılaştığımız en meşhur hatayı doğurur: Error: EACCES: permission denied, mkdir '/.npm'

Çözüm: Uygulamaları “Root” düzeyinde değil, tamamen kullanıcının kendi izole alanında (Kapsayıcı mantığıyla) kurmaktır.

3. Adım Adım NVM ile Özel Node.js Motoru Kurmak

Her müşteriye veya projeye kendi bağımsız Node.js motorunu atamak için NVM kullanıyoruz. Bu sayede aynı sunucuda bir proje Node 18 ile çalışırken diğeri Node 20 ile çakışmadan çalışabilir.

Terminalinize giriş yapın ve ortamı uyandırmak için şu komutları sırasıyla girin (NVM kurulu değilse standart cURL komutuyla kurabilirsiniz):

# NVM'in yolunu belirleyin
export NVM_DIR="/www/.nvm"

# NVM'i aktif edin
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# İstediğiniz Node sürümünü kurun ve kullanın (Örn: v20)
nvm install 20
nvm use 20

4. NPM EACCES (Yetki) Hatalarını Tamamen Aşmak

NPM’in sunucu kök dizinlerine dosya yazmaya çalışmasını engellemek için ona “Ev” dizininin neresi olduğunu söylemeliyiz. Aşağıdaki komut, NPM’in tüm önbellek dosyalarını kısıtlı alanımız olan /www içerisine yazmasını sağlar:

export HOME="/www"

Sürüm Çakışmalarını (ERESOLVE) Gidermek

Projelerinizde paket sürümleri uyuşmazlığı (npm error ERESOLVE) yaşıyorsanız, NPM’e eski tip bağımlılık çözümlemeyi kullanmasını söyleyerek kurulumu zorlayabilirsiniz:

npm install --legacy-peer-deps

5. Jailed Ortamda PM2 Kurulumu ve “module_conf.json” Hatası Çözümü

Uygulamanızı arka planda sürekli çalıştıracak olan PM2’yi kurmak, yetki sorunlarının en çok yaşandığı yerdir. PM2 logları ve PID dosyalarını ana dizindeki /.pm2 içine yazmaya çalışır. Bunu önlemek için PM2’nin çalışma alanını yeniden yönlendiriyoruz:

# PM2'ye yeni bir ev gösteriyoruz
export PM2_HOME="/www/.pm2"

# PM2'yi global olarak kuruyoruz
npm install -g pm2

Kurulumun başarılı olup olmadığını test etmek için:

pm2 status

Bu komut size boş da olsa o meşhur PM2 tablosunu vermelidir.

6. Uygulamayı Başlatmak ve PM2’yi Kalıcı Hale Getirmek

Tüm altyapımız hazır. Şimdi Node.js veya derlenmiş (build edilmiş) projemizi canlıya alalım.

1. Uygulamanızın klasörüne girin:

cd /www/

2. PM2 ile uygulamayı başlatın: Birden fazla uygulama barındırıyorsanız --name parametresi ile isimleri birbirinden ayırmayı unutmayın.

pm2 start index.js --name "proje-adi" --cwd /www/

3. İşlemi Kaydedin: Sunucu herhangi bir sebeple yeniden başlatıldığında uygulamanızın otomatik olarak tekrar açılması için listeyi kaydedin:

pm2 save

Bonus: SSH Her Açıldığında Ayarları Korumak (.bashrc Otomasyonu)

Jailed SSH ortamları çok “unutkandır”. Terminali kapatıp açtığınızda pm2 status veya npm komutları tekrar hata verebilir. Çünkü girdiğimiz export komutları hafızadan silinir.

Her girişinizde tek bir kelimeyle ortamı hazırlamak için kendinize bir kısayol (alias) oluşturun:

echo 'alias start="export HOME=/www && export PM2_HOME=/www/.pm2 && export NVM_DIR=/www/.nvm && [ -s \"\$NVM_DIR/nvm.sh\" ] && . \"\$NVM_DIR/nvm.sh\" && nvm use 20"' >> /www/.bashrc
source /www/.bashrc

Artık SSH’a her bağlandığınızda sadece start yazıp Enter’a basmanız yeterlidir. Tüm NVM ve PM2 yollarınız saniyeler içinde arka planda hazır hale gelecektir.

Özet

Kısıtlı SSH izinleri, modern web uygulamaları geliştirmek için bir engel değildir. Doğru yapılandırılmış NVM ortamları, çekirdek librt izinleri ve export yönlendirmeleri ile ana sunucuya hiçbir zarar vermeden (Root yetkisi kullanmadan) tamamen izole, güvenli ve yüksek performanslı Node.js barındırma altyapıları kurabilirsiniz. Başarılar dileriz!

Spam trafiği; credential stuffing, carding, scraping, brute force, form spam, API kötüye kullanımı gibi farklı otomasyon davranışlarından oluşur. OWASP’ın Automated Threats to Web Applications (OAT) sınıflandırması, hangi uç noktalar için hangi saldırıların tipik olduğuna dair ortak bir dil sağlar; savunmayı tek bir CAPTCHA’ya indirgemek yerine tehdit odaklı düşünmeyi kolaylaştırır. owasp.org+1

Ana savunma katmanları (özet strateji)

1. WAF + kural setleri: ModSecurity ile OWASP Core Rule Set (CRS) başlangıç bariyeri sağlar; SQLi/XSS gibi klasik istismarlara ek olarak brute force ve hız sınırlamaya yardımcı kurallar içerir. owasp.org+1

2. Oran sınırlama (rate limit) / bağlantı kotası: Nginx’in limit_req ve limit_conn modülleri IP ya da özel anahtarlar (örn. IP+username) üzerinden istek hızını düşürür; leaky-bucket algoritması kullanır. nginx.org+1

3. Risk skorlu doğrulama: Cloudflare Turnstile gibi “sessiz” tarayıcı sinyali tabanlı çözümler; düşük güven hâlinde hafif challenge göstererek sürtünmeyi azaltır. Google reCAPTCHA (Enterprise), OAT kategorilerine göre akış bazlı öneriler sunar. Cloudflare Docs+2Cloudflare Docs+2

4. Honeypot/decoy taktikleri: Görünmeyen form alanları, sahte endpoint’ler ve (Cloudflare tarafında) AI Labyrinth gibi “yönlendirip oyalayan” çözümlemeler, robots.txt’ye uymayan yeni nesil tarayıcılara karşı etkili bir ek katmandır. The Cloudflare Blog

5. Scraper ekosistemi ve robots.txt gerçekliği: 2024–2025’te yayıncılar ve altyapı sağlayıcıları, robots.txt’yi yok sayan ve kimliğini gizleyen AI tarayıcılarına karşı (örn. varsayılan engelleme, “Pay Per Crawl” gibi) daha agresif önlemler duyurdu; robots.txt tek başına yeterli değil. The Verge+2Reuters+2

6. Ölçüm temizliği: Başarıyı ölçmek için GA4’te internal ve developer trafiğini filtrele; aksi hâlde bot azaltma etkisini göremezsin. Google Yardım

7. API’lere özel sıkılaştırma: 2024’te web saldırıları %33 artarken API’ler birincil hedef hâline geldi; rate limit + kimlik doğrulama + davranışsal sinyaller şart. vmblog.com+1

Uygulanabilir kontrol listesi (Hızlı başlangıç)

• Kritik uçları çıkar: /login, /signup, ödeme/form akışları, /search, ürün beslemeleri ve API uçları; her birini OAT kategorisiyle eşleştir. owasp.org

• WAF/CRS’i aç ve tuning yap: Hatalı pozitifleri azaltmak için istisna kuralları tanımla. CRS Project

• Oran sınırla: Nginx ile IP ve akışa özgü anahtarlarla rate limiting uygula. nginx.org

• Riskli akışlarda challenge: Turnstile/reCAPTCHA’yı login, kayıt ve ödeme gibi yüksek riskli akışlarda puan/karar mekanizmasıyla devreye al. Cloudflare Docs+1

• Honeypot/decoy ekle: Form honeypot’ları + (Cloudflare kullanıyorsan) AI Labyrinth. The Cloudflare Blog

• Scraper yönetimi: ASN/ülke/UA sinyalleriyle kurallar, hız limitleri, JSON/Feed uçlarına Accept/Referer hijyeni.

• Ölçüm temizliği: GA4 iç/developer trafiğini dışla. Google Yardım

• Sürekli gözlem: 429/5xx oranları, çerezsiz istek patlamaları, belirli ASN/ülkelerden ani sıçramalar için alarmlar kur.

• Trendleri izle: Akamai’nin yıllık/çeyreklik SOTI raporları API/bot eğilimlerini takip için iyi bir referans. Akamai

Uygulama Taslağı (kopyala–uyarla)

A) Nginx: Oran sınırlama ve basit işaretler

Login akışı için IP + kullanıcı adı birleşik anahtar:

Nginx’in limit_req modülü leaky-bucket yöntemiyle çalışır; anahtar seçiminde IP’nin NAT arkasında paylaşılıyor olabileceğini unutma. nginx.org+1

Form spam için honeypot + hız limiti:

Sık kazınan uçlar (search/feed/sitemap) için dar boğaz:

B) Cloudflare: Turnstile + WAF mantığı + AI Labyrinth

Turnstile entegrasyonu (özet):

Sunucuda (ör. Node) doğrularken token’ı /siteverify ile kontrol et; puan düşükse ek doğrulama iste. Turnstile, Cloudflare CDN’i kullanmasan bile gömülebilir; önce sessiz sinyaller toplar, gerekirse hafif bir challenge gösterir. Cloudflare Docs+1

AI Labyrinth (decoy sayfalarla oyalama): robots.txt’ye uymayan/bilinen AI tarayıcılarına karşı botu “labirente” sokarak kaynaklarını tüketen yeni savunma; Cloudflare üzerinde ücretsiz/opt-in sunuluyor. The Cloudflare Blog

Güncel bağlam: Cloudflare 2025’te AI crawler’ları varsayılan engelleme ve Pay Per Crawl seçeneklerini duyurdu; robots.txt’yi yok sayan botlara karşı altyapı seviyesinde kontrol sağlıyor. The Verge+1

C) AWS WAF: Bot Control + yönetilen kurallar

• AWS WAF Bot Control: Bilinen bot kategorilerini (iyi/kötü) ayıran yönetilen kurallar; özel kurallarla birleştirilebilir. docs.aws.amazon.com+1

Örnek (IP başına /login rate limit + Bot Control):

D) Google reCAPTCHA (Enterprise): OAT uyumlu mimari

Google’ın OAT tehditlerine göre en iyi uygulamalar kılavuzu, kart dolandırıcılığı, credential stuffing vb. senaryolarda puan tabanlı karar akışları ve “ek doğrulama” önerir. Uygulamada, skor/bağlama göre “izin ver / MFA iste / insan doğrulaması iste / reddet” kuralı tanımla. Google Cloud+1

E) GA4: İç/developer trafiğini dışla (ölçüm temizliği)

• Internal traffic: IP’leri “Define internal traffic” ile tanımla, ardından Data Filters’ta Exclude olarak aktif et. Google Yardım

• (İpucu) GA4, iç trafikten gelen vuruşlara tt=internal işareti koyar; validasyonu kolaylaştırır. selnekovic.com

F) İzleme & alarm fikirleri

• 429/5xx oranı ve endpoint başına z-skor sapmaları.

• Cookie-less istek oranı, ASN/ülke bazlı patlamalar.

• Decoy/honeypot isabetleri metriki (AI Labyrinth/honeypot sayfalarına giriş).

• API saldırı trendleri için Akamai’nin SOTI raporlarını periyodik takip. vmblog.com

Neden robots.txt tek başına yetmiyor?

Son 1 yılda; kimliğini gizleyen, robots.txt’yi görmezden gelen ya da UA/başlık taklidi yapan AI tarayıcılarına dair çok sayıda bulgu paylaşıldı. Bu yüzden altyapı seviyesinde engelleme (WAF/ASN/UA/Rate limit/Decoy) gereklidir. arstechnica.com+1

Kullanıcı deneyimi: “kademeli sürtünme” prensibi

• Herkese CAPTCHA göstermek yerine, risk skorlu ve kademeli zorlaştırma kullanın: düşük riskli akışlarda sürtünme yok; risk yükseldikçe MFA / challenge / manuel inceleme. Turnstile ve reCAPTCHA bu modeli destekler. Cloudflare Docs+1

Ek: Somut “kural seti” taslağı (özet)

1. Nginx: /login için IP+username anahtarıyla limit_req; form uçlarına honeypot + saatlik limit; “sıcak” scraping uçlarına 1 r/s sınırı. nginx.org

2. Cloudflare: Turnstile’ı yalnızca login/signup/ödeme gibi riskli akışlara yerleştir; AI Labyrinth’i aç; bilinen AI UA’ları ve “şüpheli oran” için WAF’ta Managed Challenge uygula. Cloudflare Docs+1

3. AWS WAF: Önde Allowlist → Bot Control → Common Rule Set → akışa özel rate limit. docs.aws.amazon.com

4. GA4: Internal/Developer filtreleri Active; bot benzeri oturumlar için ayrı segment oluştur. Google Yardım

5. Sürekli iyileştirme: Hatalı pozitif vakalarını toplayıp istisnalar yaz; eşikleri haftalık gözden geçir.

6. Trend takibi: API saldırıları ve scraper davranışlarına dair Akamai SOTI raporlarını takip et. Akamai

İlk Teşhis: Günlükleri (Log) ve Servis Durumunu Kontrol Edin

1. Plesk arayüzü erişilemiyorsa, sunucuya SSH ile bağlanın ve MariaDB/MySQL durumuna bakın:

   systemctl status mariadb
journalctl -u mariadb -n 200 --no-pager


   (Windows’ta Olay Görüntüleyici ve Plesk SQL Server servisini kontrol edin.) support.plesk.com

2. Geçmiş boot loglarını inceleyin (özellikle beklenmedik yeniden başlatma sonrası):

   journalctl --boot=-1 -n 5000


   (Forumda doğrulanan pratik bir yaklaşım.) Plesk Forum

3. Disk doluluk:

   df -h
du -sh /var/lib/mysql/* | sort -h


   Diskin dolması, MySQL’in başlamasını engeller ve 500 hatasına yol açar. Plesk Forum

Hızlı Onarım: Plesk Repair Utility (Önerilen)

Çalıştırın:

Bu komut Plesk veritabanı tutarlılığını denetler, gerekirse otomatik yedek (dump) alır ve onarım dener. Linux/Windows’ta kullanılabilir. Ek seçenek gerekmez. docs.plesk.com+2plesk.com+2

Not – Geçici 500 Hatası: plesk repair installation gibi geniş onarım çalışırken Plesk kısa süre erişilemez ve 500 hatası görülebilir; bu, bilinen bir Repair Kit davranışı/bug’ıdır ve işlem bitince kaybolur. support.plesk.com

Senaryo A: SQLSTATE[HY000][2002] Connection refused

Belirti:

Neden: MariaDB/MySQL servisinin down olması veya başlayamaması.
Çözüm:

1. Servisi başlatın/yeniden başlatın:

   systemctl restart mariadb
systemctl status mariadb


2. Loglardaki temel sebebi giderin (ör. yapılandırma, port çakışması, izinler).

3. Ardından plesk repair db çalıştırın.
   Kaynak ve aynı hatanın resmi analizi: support.plesk.com

Senaryo B: SQLSTATE[HY000][2002] No such file or directory

Belirti:

Neden: MySQL socket dosyası yok/yanlış yol, servis kapalı veya disk taşması sonucunda soket oluşmuyor.
Çözüm:

1. Servisi yeniden başlatın; /etc/my.cnf içindeki socket yolunu ve /var/lib/mysql/mysql.sock varlığını doğrulayın.

2. Disk doluysa alan açın (bkz. Senaryo D).

3. Gerekirse /tmp izinlerini ve AppArmor/SELinux kısıtlarını kontrol edin.
   Doğrulama: Plesk Forum+1

Senaryo C: Plesk SQL Server Error 1053 (Windows) / Port Çakışması

Belirti: 1053; Event Viewer’da “Bind on TCP/IP port 3306… already in use”.
Neden: Plesk SQL Server servis yapılandırması hatalı ya da 3306 portunu başka bir mysqld kullanıyor.
Çözüm:

1. Hizmetin “Path to executable” ayarını doğru my.ini bilgisiyle güncelleyin.

2. Port çakışması varsa bağlanan diğer MySQL örneğini kapatın/portu değiştirin.
   Kaynak: support.plesk.com

Senaryo D: Disk Dolu (No space left on device)

Belirti: MySQL başlatılamıyor; günlüklerde “No space left on device”.
Çözüm:

1. df -h ile dolu diskleri tespit edin, gereksiz log/backupları temizleyin.

2. MariaDB’yi yeniden başlatın, ardından plesk repair db.
   Resmi Plesk çözüm makalesi: Plesk Forum

Senaryo E: Bozulmuş Plesk Sistem Veritabanları (psa vb.)

Belirti: psa tabloları “crashed”/tutarsız; Plesk arayüzü 500 veriyor.
Çözüm (önce yedek alın):

1. Repair Utility:

   plesk repair db


2. Gerekirse günlük yedekten geri yükleme (Plesk’in otomatik dump’ları):
   Plesk günlük/pre-upgrade dump’tan psa’yı geri yükleme adımları resmi rehberde anlatılır. (Örnek komutlar ve değiştirme notları rehberde mevcut.) plesk.com

3. Alternatif CLI restore notları (ilerseviye): dump’tan apsc/psa geri yükleme pratikleri. (Topluluk deneyimi; dikkatle uygulayın.) The WP Guru

Uyarı: Manuel mysqlcheck --repair veya innodb_force_recovery gibi adımlar verinizi riske sokabilir; önce resmi repair ve resmi geri yükleme yollarını deneyin. docs.plesk.com+1

Senaryo F: Geçici — Repair Çalışırken Plesk İnaccessible

Belirti: plesk repair installation sırasında panel 500 hatası döner.
Çözüm: İşlem tamamlanınca düzelir; bilinen bir davranış/bug kaydı mevcuttur. support.plesk.com

Senaryo G: Eksik/Silinmiş Dosya veya Antivirüs Karantinası (Windows)

Belirti: “500 Internal Server Error – Failed opening required …”
Çözüm: Eksik dosyayı aynı sürüm çalışan bir Plesk’ten geri getirin; antivirüse %plesk_dir% için istisna ekleyin. support.plesk.com

Adım Adım Standart Düzeltme Akışı (Önerilen Playbook)

1. Servisleri kontrol et: systemctl status mariadb → hata varsa log oku. support.plesk.com

2. Disk alanı: df -h → doluysa temizle. Plesk Forum

3. Repair Utility çalıştır: plesk repair db (Linux/Windows). docs.plesk.com+1

4. Socket/Port doğrula: mysql.sock yolu ve 3306 çakışması. (Windows’ta hizmet yapılandırması.) support.plesk.com+1

5. Hâlâ sorun var mı? Plesk sistem DB’lerini dump’tan geri yükle (örn. psa). plesk.com

6. Geçici 500 mi? Repair esnasında oluştuysa görmezden gelebilirsiniz; işlem bitince panel geri gelir. support.plesk.com

SSS

Bu hata neden “genel” gözüküyor?
“500 Plesk\Exception\Database” şemsiye bir hatadır; somut sebep loglarda çıkar. Plesk Forum

Plesk’te veritabanını GUI’den de onarabilir miyim?
Evet; “Websites & Domains → Databases → Check and Repair”. (Sürümünüze göre görünüm değişebilir.) lets-rebuild.com

Repair sırasında 500 görürsem?
Bu beklenen bir davranış olabilir; repair bitince panel geri gelir (EXTPLESK-3451). support.plesk.com

İleri Düzey Notlar ve İpuçları

• Komutları üretimde uygulamadan önce snapshot/backup alın.

• Plesk Repair Utility, tutarsızlık bulursa otomatik dump alıp onarım dener; bu nedenle ilk başvuru aracınız olmalı. docs.plesk.com

• Hata No such file or directory ise socket yolunu ve /tmp izinlerini kontrol edin; Connection refused ise servis gerçekten çalışmıyor demektir. support.plesk.com+1

İlk 5 Dakikalık Teşhis

1. Hata kayıtları: cPanel: Metrics → Errors; Plesk: alan adında Logs; CWP: HTTPD/Nginx, PHP, AutoSSL ve servis log’ları.
2. DNS kontrolü: A/AAAA, MX, TXT (SPF/DKIM/DMARC)
3. SSL/AutoSSL: Let’s Encrypt’i yenile; 80/TCP erişilebilir olmalı (HTTP-01 doğrulaması).
4. PHP limitleri: upload_max_filesize + post_max_size + max_execution_time
5. Mail teslimi: SPF/DKIM/DMARC + rDNS(PTR)

DNS / Alan Adı Hataları

Belirti: Site bazı bölgelerde açılıyor/hiç açılmıyor, e-postalar gelmiyor.

Panel yolları: cPanel: Domains → Zone Editor; Plesk: Websites & Domains → DNS Settings; CWP: DNS Functions.

dig +short example.com A
dig +short example.com AAAA
dig +short example.com MX
dig +short NS example.com

Not: NS değişiminde TTL/propagasyon 24–48 saat sürebilir.

SSL/TLS (HTTPS) ve AutoSSL

Belirti: “Not secure”, “expired”, “hostname mismatch”, LE başarısız.
Kritik: Let’s Encrypt HTTP-01 yalnızca 80/TCP’ten doğrular.

• cPanel/WHM: AutoSSL (sağlayıcı: Let’s Encrypt)
• Plesk: Let’s Encrypt / SSL It! (site + mail + Plesk arayüzü)
• CWP: Loglar → /var/log/cwp/autossl.log, /root/.acme.sh/acme.sh.log

Öneri: HTTP→HTTPS yönlendirmesi kalsın; fakat .well-known/acme-challenge dosyalarına 80’den erişim bozulmasın.

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Web Sunucusu & Uygulama Hataları (500/502/503/504)

İzlenecek yol: cPanel Errors → ip

Kime göre? Yeni–orta seviye kullanıcı, WordPress ağırlıklı, paylaşımlı hosting kullananlar.
Amaç: Hızlı uygulanan, hatayı çözen, arama niyeti yüksek konularla organik trafik toplamak.

🔍 Neden paylaşımlı hostta güvenlik kritik?

Aynı fiziksel sunucuda birçok site bir aradadır. İzolasyon zafiyetleri, log dosyaları üzerinden bilgi sızdırma (log snooping) ve log zehirleme (log poisoning) gibi saldırı yüzeyleri doğurabilir. Bu yüzden temel korumalar + doğru yapılandırma şarttır. arXiv+1

1) 🧱 ModSecurity (WAF) açık mı? (cPanel → Security → ModSecurity)

Ne sağlar? HTTP isteklerini imza/kurallarla filtreleyip yaygın web saldırılarını kırpar. cPanel’de her domain için aç/kapat yapılabilir; erişemiyorsan sağlayıcından etkinleştirmesini iste. Kurallar için en yaygın set OWASP Core Rule Set (CRS)’tir. cPanel & WHM Documentation+1

İpucu: WAF bazen yanlış pozitif üretebilir. Gerekirse alan adına özel kural istisnası veya geçici kapatma ile test edebilirsin (kalıcı kapatma önerilmez). cPanel & WHM Documentation

2) 🔒 HTTPS zorunlu + (mümkünse) HSTS

Trafiği şifreleyen HTTPS hem güvenlik hem de SEO tarafında onaylı bir sinyaldir. Sertifikan yoksa kur; varsa HTTP→HTTPS yönlendirmesini zorunlu kıl ve HSTS değerlendir. Google for Developers

3) 🧰 Dosya/klasör izinlerini düzelt (WordPress)

Genel pratik:

• Dosyalar: 644

• Klasörler: 755
  Bu kombinasyon, çoğu WordPress kurulumunda güvenli/çalışır denge sunar. Ayrıntılı izin rehberi için resmi geliştirici dokümantasyonuna bak. WordPress Developer Resources

4) 🧾 .htaccess ile hızlı korumalar

a) Dizin listelemeyi kapat

Bu, klasör içeriğinin listelenmesini durdurur; uygulanabilirliği AllowOverride ayarına bağlıdır. Apache HTTP Server

b) Hassas dosyaları web’den gizle

Apache 2.4’te Require all denied ile eşleşen dosyalar doğrudan sunulmaz. (Yine AllowOverride önemli.) Apache HTTP Server

Not: .htaccess her ortamda her direktifi çalıştırmayabilir; sunucu yapılandırması belirleyicidir. (Apache, .htaccess’in nasıl ve ne zaman kullanılması gerektiğini resmi kılavuzda anlatır.) Apache HTTP Server

5) 🔐 SFTP/SSH kullan; FTP’yi bırak

FTP veriyi ve parolaları şifrelemeden taşır. SFTP/SSH ile güvenli kanaldan aktarım yap. WordPress güvenlik kılavuzları da SSH/SFTP’yi önerir. WordPress Developer Resources+1

6) 🧩 PHP tarafında “sınırlandırma” (mümkün olan yerde)

• open_basedir: PHP’nin erişebileceği dizinleri sınırlar (siteler arası dolaşmayı önlemeye yardım eder). Etkinleştirme şekli hosting ortamına göre değişir. php.net

• disable_functions: exec, shell_exec, system gibi riskli fonksiyonları devre dışı bırakır (destek/etki PHP sürümü ve handler’a bağlıdır). php.net

cPanel’de nereden bakarım? MultiPHP INI Editor üzerinden alan adına tanımlı, panelin izin verdiği yönergeleri düzenleyebilirsin. (Bazı direktifler paylaşımlı hostta kilitli olabilir.) cPanel & WHM Documentation

7) 💾 Yedeklemeyi otomatiğe bağla + geri yüklemeyi test et

cPanel Backup Wizard ile tam veya kısmi yedek alabilir, ihtiyaçta geri yükleyebilirsin. Gerçekten işe yarayıp yaramadığını en az bir kez küçük bir geri yükleme testiyle doğrula. cPanel & WHM Documentation

8) 🚀 CDN ekle (temel hız + saldırı yüzeyi azaltma)

CDN; içeriği kullanıcıya yakın POP’lardan ileterek performans ve erişilebilirlik kazandırır; çoğu CDN aynı zamanda temel DDoS/WAF katmanı da sunar. Başlangıç planları genelde yeterlidir. (Seçim marka bağımsız.) (Genel ilkedir; ürün isimleri değişebilir.)

9) 🧹 Eklenti/tema hijyeni (WordPress)

• Sadece güvenilir kaynaklardan tema/eklenti.

• Güncellemeleri geciktirme (major öncesinde mutlaka yedek).

• Kullanmadıklarını sil (pasif bırakma).
  Bu tavsiyeler WordPress güvenlik kılavuzlarında temel başlıklardır. WordPress Developer Resources

10) 👀 İzleme ve log bilinci

Erişim/hatâ loglarını düzenli kontrol et (403, 404 patlamaları, sıra dışı POST istekleri). Paylaşımlı hostta log izolasyonu yoksa risk büyür; sağlayıcından her alan adının loglarının ayrıldığını teyit et. arXiv

✅ 30 Dakikalık Hızlı Kontrol Listesi

1. ModSecurity: cPanel → Security → ModSecurity → On. (Her domaini kontrol et.) cPanel & WHM Documentation

2. HTTPS: Sertifika kurulu mu? HTTP→HTTPS yönlendirme aktif mi? (SEO + güvenlik) Google for Developers

3. .htaccess:

   • Options -Indexes ekle. Apache HTTP Server

   • FilesMatch ile .env/.ini/.log vb. engelle. Apache HTTP Server

4. İzinler: Dosyalar 644, klasörler 755 mi? (WordPress resmî kaynak) WordPress Developer Resources

5. SFTP: FTP yerine SFTP/SSH kullan. wordfence.com

6. PHP sınırları: (Varsa) open_basedir ve disable_functions durumunu incele. php.net+1

7. Yedek: cPanel Backup Wizard ile kısmi yedek al; küçük bir geri yükleme testi yap. cPanel & WHM Documentation

🧪 Sık karşılaşılan mini sorunlar & hızlı çözümler

“Dizinlerim listeleniyor, herkes görüyor!”
.htaccess dosyana Options -Indexes ekle; sonuç görmüyorsan sunucuda AllowOverride kısıtlı olabilir (destekle kontrol et). Apache HTTP Server

“WAF kapatınca hızlanır mıyım?”
Genelde kapatma; ModSecurity + OWASP CRS yaygın saldırıları daha başta kırpar. Hata yaşıyorsan kural istisnası veya domain bazlı ince ayar yap. cPanel & WHM Documentation+1

“FTP güvenli mi?”
Hayır, parolalar şifresiz gider. SFTP/SSH kullan. wordfence.com

📎 Kod şablonları (kopyala–yapıştır)

.htaccess – Dizin listelemeyi kapat + hassas dosyaları engelle

(Apache 2.4 söz dizimi; AllowOverride = All değilse çalışmayabilir.) Apache HTTP Server

wp-content/uploads için örnek izinler

• Klasörler: 755

• Dosyalar: 644 WordPress Developer Resources

📚 Kaynaklar (Güvenilir dokümantasyon)

• cPanel – ModSecurity (kullanıcı arayüzü & WHM kurulumu notları) cPanel & WHM Documentation

• OWASP Core Rule Set (CRS) – proje sayfası owasp.org

• Google – “HTTPS bir sıralama sinyali” duyurusu (resmî) Google for Developers

• WordPress Developer – Dosya izinleri WordPress Developer Resources

• cPanel – Backup Wizard cPanel & WHM Documentation

• WordPress Hardening (SSH/SFTP önerileri dahil) WordPress Developer Resources

• Apache – .htaccess ve yapılandırma bölümleri Apache HTTP Server+1

• Akademik – Paylaşımlı hosting’te log saldırıları (snooping/poisoning) arXiv+1

Linux sistemlerinde paket yönetimi sırasında bazen güncelleme hatalarıyla karşılaşabilirsiniz. Özellikle CentOS, AlmaLinux, Rocky Linux gibi RHEL tabanlı dağıtımlarda kullanılan yum paket yöneticisi, en güncel sürümleri yüklemek ister. Ancak bu her zaman mümkün olmaz.

İşte bu durumda yum update --nobest, uyumlu sürümlere güncelleme yaparak hataları aşmanıza yardımcı olur.

Normal yum update Neden Hata Verebilir?

Standart güncelleme komutu:

Bu komut en güncel paketleri kurmaya çalışır. Ancak bazı durumlarda:

• Bağımlılık sorunları (dependency conflicts) yaşanabilir.

• Yeni sürüm uyumsuz olabilir.

• Üretim ortamında stabilite bozulabilir.

Örnek hata çıktısı:

yum update --nobest ile Çözüm

Komut:

Bu parametre sayesinde:

• En güncel sürüm zorunlu tutulmaz.

• Uyumlu olan en uygun sürüm seçilir.

• Güncellemeler tamamen kesilmez.

Kullanım Senaryoları

1. Üretim Sunucularında

En güncel sürüm bağımlılık hatası verirse, --nobest sayesinde bir alt ama stabil sürüm kullanılabilir.

2. Geliştirme Ortamında

Yeni teknolojiler denerken tüm sistem güncellemeleri sırasında çıkabilecek hatalar --nobest ile aşılabilir.

Avantajları

• ✅ Güncellemeler tamamen engellenmez.

• ✅ Daha esnek güncelleme sağlar.

• ✅ Bağımlılık hatalarını azaltır.

Dezavantajları

• ⚠️ Sistem her zaman en güncel olmayabilir.

• ⚠️ Güvenlik yamaları gecikebilir.

• ⚠️ Uzun vadede uyumluluk sorunları çıkabilir.

Sonuç

yum update --nobest, Linux güncellemelerinde bağımlılık hatalarını çözmek için pratik bir yöntemdir. Ancak güvenlik ve uzun vadeli uyumluluk açısından dikkatli kullanılmalıdır.

E-posta yönetimi bir sunucu panelinin omurgasıdır. CentOS Web Panel (CWP) üzerinde eski Roundcube sürümleri güvenlik riski oluşturabilir. Bu rehberde, Roundcube 1.5.11 sürümüne adım adım ve güvenle yükseltmeyi anlatıyoruz. 🚀

🔒 Neden 1.5.11?

CWP’nin varsayılan Roundcube sürümü çoğu kurulumda eski kalabiliyor. 1.5.x serisi; güvenlik yamaları, uyumluluk ve daha iyi eklenti desteğiyle öne çıkıyor.
1.5.11, 1.5 hattındaki en güncel ve kararlı sürümlerden biri olduğu için tavsiye edilir. ✅

🧭 Aşamalar – Adım Adım Kurulum

1) INTL PHP Eklentisini Kur (Gerekirse) 🧩

Sunucunda intl eklentisi yoksa, aşağıdaki komutlarla (EL7/EL8) kurulumu tamamlayabilirsin:

CentOS 7 / EL7:

CentOS 8 / EL8:

Kaldırma:

2) Roundcube 1.5.11 Paketini İndir ⬇️

3) Paketi Aç ve Kurulum Script’ini Çalıştır 🛠️

Kurulum sırasında ekranda şunu göreceksiniz:

Burada y tuşuna basarak devam edin. Ardından şu çıktılar gelecek:

4) Temizlik 🧹

ℹ️ Çoğu sistemde dosya izinleri CWP tarafından otomatik ayarlanır; ayrıca chown veya chmod girmenize gerek kalmayabilir.

5) Test Et ve Servisi Yeniden Başlat 🔁

Çıktı şu şekilde olacaktır:

🧪 Komut Özeti

✅ Sonuç

• CWP üzerinde mevcut Roundcube sürümü genellikle 1.4.x gibi eski.

• 1.5.11, en güncel güvenlik yamalarını içerir.

• Kurulum sırasında y onayını vermeyi unutmazsanız süreç sorunsuz ilerler.

• Olası hatalarda restart_cwpsrv komutu çoğu zaman çözüm sağlar. ✨

Snuffleupagus Nedir?

Snuffleupagus, PHP için geliştirilen açık kaynak kodlu bir güvenlik modülüdür. PHP kodunun davranışını kısıtlar, zararlı işlemleri engeller ve potansiyel saldırılara karşı sitenizi korur.
ModSecurity gibi WAF çözümlerine ek olarak çalışabilir ve özellikle 0-day saldırılarına karşı ek koruma sağlar.

Temel Özellikleri

• Gerçek zamanlı güvenlik politikası uygulama

• Exploit ve zafiyetlere karşı otomatik önlemler

• Detaylı raporlama ve loglama

Snuffleupagus Kurulumu (Adım Adım)

1. Sunucu Gereksinimleri

• PHP 7.0 ve üstü

• Linux tabanlı bir hosting/sunucu (Ubuntu, CentOS, Debian vb.)

2. Snuffleupagus’u Yükleme

A. Ubuntu/Debian için:

B. CentOS/RHEL için:

3. PHP’ye Entegre Etme

Kurulumdan sonra, php.ini dosyanıza şu satırı ekleyin:

Ardından Apache/Nginx’i yeniden başlatın:

4. Temel Güvenlik Politikaları Oluşturma

Snuffleupagus, politika dosyalarıyla yönetilir. Basit bir örnek:

Böylece PHP’de en tehlikeli fonksiyonlar devre dışı bırakılır.

Snuffleupagus’un Sağladığı Avantajlar

• 0-day Exploitlere karşı yüksek koruma

• Hangi PHP fonksiyonlarının çalışıp çalışamayacağını kolayca kontrol etme

• Detaylı loglama ve saldırı tespiti

• Performans kaybı olmadan maksimum güvenlik

• Sunucuda paylaşımlı siteler için ekstra güvenlik katmanı

Sıkça Sorulan Sorular

Snuffleupagus, ModSecurity’nin yerini tutar mı?

Hayır, ModSecurity WAF seviyesinde koruma sağlarken Snuffleupagus, PHP’ye özel koruma katmanı ekler. Birlikte kullanılması önerilir.

Paylaşımlı hostingde kullanılabilir mi?

Sunucu yönetimi sizdeyse ve root erişiminiz varsa, evet!

Sonuç

Gelişen saldırı yöntemlerine karşı Snuffleupagus kullanmak, PHP siteleriniz için ek bir güvenlik zırhı sağlar. Özellikle hosting şirketleri, ajanslar ve kurumsal siteler için önerilen bir çözümdür.

CentOS 9 işletim sistemi üzerinde zaman zaman şifre unutulmaları ya da güvenlik sebepleriyle şifre sıfırlamaları gerekebilir. Sistem yöneticileri ya da kullanıcılar bu tür durumlarla karşılaştığında, işlemi doğru bir şekilde gerçekleştirmek önemlidir. Burada adım adım CentOS 9 Şifre sıfırlama işlemine nasıl başlayabileceğinizden ve nelere dikkat etmeniz gerektiğinden bahsedeceğiz. İster tecrübeli bir sistem yöneticisi olun, ister bu alanda yeni olun, bu rehber şifre sıfırlama işleminizi kolaylaştıracak. Bu süreçte izlenecek doğru adımlar, hem sistem güvenliğinizi koruyacak hem de kullanıcılara erişilebilir bir çözüm sunacaktır.

Ana Noktalar

1. CentOS 9’da şifre sıfırlama önemlidir ve dikkat gerektirir.
2. Doğru adımlarla şifre sıfırlama işlemi basitleşir.
3. Sistem güvenliğini sağlamak için doğru yöntemler uygulanmalıdır.

Linux Kullanıcı Hesaplarının Parola Güvenliği

Parola güvenliği, Linux kullanıcı hesapları için kritik bir konudur. Parola yönetimi zayıf olduğunda, sistemler kötü niyetli saldırılara karşı savunmasız hale gelir. O yüzden dikkatli olunması ve adımların doğru atılması önemlidir. Örneğin, genel parolalardan kaçınmak gerekir. Ayrıca, düzenli aralıklarla parolaları yenilemek önemlidir. Ne var ki, bazı adımlar karmaşık gelebilir. Bu nedenle, rehber niteliğinde bir Centos 9 Şifre sıfırlama adım adım süreci hazırlamak yararlı olabilir.

Centos 9 İçin Şifre Sıfırlama Rehberi

1. Grub Kurtarma Modu: Bilgisayarı açarken GRUB menüsünde ‘e’ tuşuna basın.
2. kernal satırını bulun: ‘ro’ ifadesini ‘rw init=/sysroot/bin/sh’ ile değiştirin.
3. Tek Kullanıcı Moduna Geçiş: Bu işlemden sonra Ctrl+x veya F10 tuşuna basarak boot edin.
4. Chroot Ortamı: chroot /sysroot komutunu çalıştırın.
5. Parolayı Değiştir: passwd komutunu kullanarak şifrenizi değiştirin.
6. Selinux Etkinleştirme: touch /.autorelabel komutu çalıştırarak yeniden başlatmayı sağlayın.
7. Sistemi Yeniden Başlatma: reboot komutu ile sistemi açın.

Centos 9 şifre sıfırlama rehberi, karmaşık görünse de adımlar dikkatle uygulanmalıdır. Özellikle, güvenli parola oluşturulması, kullanıcı hesaplarının koruma altında olmasını sağlar. Buna göre, dikkatli ve planlı hareket etmek önem kazanır.

Grub Menü Üzerinden Kurtarma Moduna Erişim

Komut satırında, el yordamıyla müdahale gerektiren bir işlem düşünün: adım adım Centos 9 Şifre sıfırlama işlemi. Teknolojik sistemlerin karışıklığında kaybolmak sizi şaşırtabilir; lakin, bazen karmaşıklık bir düğmeye basmak kadar kolaydır. Başlangıçta kurtarma moduna ulaşabilmek için Grub menüsüne erişmeniz şart. Grub menüsüne erişebildiğinizde, kurtarma modu kayıtları arasında kendinizi kaybolmuş hissetmeniz mümkün. Ancak size iyi haber; kararlı bir yönlendirme için Grub üzerinden adımları takip edeceksiniz. Bir yol haritası düşünün: Centos 9 Şifre sıfırlama nasıl yapılır aşaması. Bu aşamada, belirli komutlar sizi yolunuza çıkarabilir veya çıkmaz sokaklara sürükleyebilir. Yanlış bir adım sizi eski dosya derinliklerine sürüklüyor gibi görünse de, doğru komutlar ile istenilene ulaşmak mümkündür. Kurtarma komutları arasında gezinirken kaybolmayın; çünkü uygun adımlar sizi güvenli bir çıkışa götürebilir. Özellikle şifre sıfırlama sürecine odaklanın ve dikkatlice devam edin. Adım adım Centos 9 Şifre sıfırlama yöntemi ile bu işlem düşündüğünüz kadar zor olmayacak!

Root Parolasını Sıfırlama Adımları

Root parolanızı, kimi zaman unutabiliyoruz, değil mi? Bu gibi durumlarda, özellikle CentOS 9 üzerinde şifre sıfırlama adımları işinize yarayacaktır. İlk adımda sistemi yeniden başlatın ve boot menüsüne erişin. Menüde, kurtarma modunu tercih edebilirsiniz. Lâkin, burada dikkatli olun: Yanlış bir seçim süreci zorlaştırabilir. Bu aşamada, root erişimleri düzenlemek için komut satırını kullanmak gerekebilir. Terminalde, sırayla gerekli komutları girin ve yeni parolanızı belirleyin.

Nihai Sonuç

Tüm adımları dikkatlice izlediğinizde, başarıyla root parolanızı sıfırlamış olacaksınız. Ancak, adımları harfiyen takip etmek önem arz ediyor. Garip gelebilir ama bazı adımlar karmaşık görünebilir. İşin sonunda, şifre sıfırlama işlemlerinin başarılı şekilde tamamlanması, sistem üzerinde yönetim kontrolünü yeniden ele almak için kritik rol oynayacaktır.

İhtiyaç Duyabileceğiniz Komutlar ve Düzeltmeler

Günlük hayatın koşturmacasında, beklenmedik aksaklıklarla karşılaşmak kaçınılmaz olabilir. İşte tam da bu noktada bazı pratik komutlar işinizi kolaylaştırabilir. Ancak, çoğu zaman bu komutların da anlaşılması zor olabiliyor. Elinizin altında küçük bir rehber olması kimi zaman işleri oldukça pratik bir hâle getirebilir. Örneğin, “ctrl + z” ile yanlış yapılan işlemleri geri alabilirsiniz; fakat her yazılım bu kısayolu desteklemeyebilir. Etkili olmak niyetiyle, sürekli güncel kalmak ve farklı durumlara karşı hazırlıklı olmak önemlidir. Aksi takdirde, karmaşıklıkların üstesinden gelmek zorlayıcı olabilir.

Parola Politikalarının Güçlendirilmesi

Günümüzde dijital dünyada gezinirken, güvenlik önlemlerinin önemi her geçen gün artıyor. Ancak, birçok insan halen güçlü parolaların ne denli kritik olduğunun farkında değil. Ne yazık ki, basitçe kullandığınız ‘123456’ veya ‘qwerty’ gibi parolalar, kolayca tahmin edilebilir. Oysa ki, parola politikalarını güçlendirerek, çevrimiçi varlıklarımızı korumak mümkün. Özellikle, karmaşık karakter dizileri kullanmak ve parolaları düzenli olarak değiştirmek bu süreçte hayati rol oynar. Ayrıca, her hesap için aynı parolayı kullanmamak ve iki faktörlü kimlik doğrulama sistemlerini tercih etmek de önemli bir adım olur. Dijital varlıklarınızı korumanın en etkili yollarından biri, parola yönetim araçlarını kullanmak. Bu tür araçlar, parolalarınızın güvenliğini artırır ve gerektiğinde onları düzenlemenizi kolaylaştırır. Unutmayın, bir hesaba ulaşmak o kadar da zor değil. Dolayısıyla, güçlü ve güncel parolalar kullanmak kritik öneme sahiptir.

Sorun Giderme: Yaygın Hatalar ve Çözümleri

Sorun gidermede, birçok yaygın hatayla karşılaşırsınız; çözümüne ulaşmak karmaşık olabilir. Özellikle bilgisayar sistemlerinde, küçük bir değişiklik büyük problemlere yol açabilir. Bununla birlikte, doğru teşhis ve etkili bir çözüm stratejisi geliştirmek kritik öneme sahiptir. Hataların kaynağı bazen basit bir yazılım güncellemesi eksikliği olabilir, bazen ise donanımın kendi içindeki bir çelişki olabilir. Oysa, çoğu zaman sadece derin bir nefes almak ve her adıma dikkatlice odaklanmak işleri yoluna koyabilir. Ne var ki yanlış bilgiye dayalı adımlar sorunu daha karmaşık hale getirebilir.

“Gerçek bilgelik, ne kadar az şey bildiğimizi fark etmekle başlar.” – Sokrates

Yaygın Hatalar

Özetle, hataları giderirken sabırlı olmak ve doğru adımları takip etmek önemlidir. Bu nedenle, daima doğru bilgi ve araçlara erişim sağlamaya çalışın.

Bunları da İnceleyebilirsiniz:

Linux sunucuda şifre sıfırlama işlemi nasıl yapılır? – Radore Destek

Sonuç

Adım adım CentOS 9 şifre sıfırlama sürecini detaylarıyla ele aldığımız bu rehberin sonunda, artık şifre sıfırlamanın ne kadar erişilebilir olduğunu görüyorsunuz. Karmaşık gibi görünen bu adımlar, aslında biraz dikkat ve özenle kolayca aşılabilir. Yine de, her adımı dikkatlice uyguladığınızdan emin olun. Böylece, sistemi güvende tutarken aynı zamanda performansını da en üst seviyede korumuş olursunuz. Teknoloji dünyasında bilgi paylaştıkça değer kazanır, bu rehbere ihtiyacı olabilecek kişilerle paylaşmayı unutmayın. Gelecek yazılarda daha fazla pratik bilgiyle görüşmek üzere, teknolojiyle kalın!

Sıkça Sorulan Sorular

CentOS 9 parolamı unuttum, ne yapabilirim?

CentOS 9 parolanızı unuttuysanız, sisteminizi kurtarma modunda başlatarak parolanızı sıfırlayabilirsiniz. Bunun için sistem açılışında ‘grub’ menüsünü açarak ‘recovery’ seçeneğini seçin ve süreci takip edin.

CentOS 9’da parolamı sıfırlamak için hangi araçları kullanabilirim?

Parolanızı sıfırlamak için tek ihtiyacınız olan şey kurtarma moduna erişimdir. Bash kabuğuna ulaştığınızda ‘passwd’ komutunu kullanarak yeni bir parola belirleyebilirsiniz.

Parola sıfırlama işlemi sırasında veri kaybı yaşar mıyım?

Parola sıfırlama işlemi doğrudan kullanıcı verilerini etkilemez. Ancak işlem sırasında dikkatli olmalısınız. Yalnızca gerekli adımları takip ettiğinizden emin olun.

Grub menüsüne erişemiyorum, ne yapmalıyım?

Grub menüsüne erişimde problem yaşıyorsanız, bilgisayarınızı yeniden başlatırken klavyeden ‘Esc’ veya ‘Shift’ tuşlarını tekrar tekrar basarak grub menüsüne erişmeye çalışın.

CentOS 9 için parola sıfırlama işlemi diğer Linux dağıtımlarından farklı mı?

Temel süreç tüm Linux dağıtımlarında benzerdir. Ancak versiyonlar ve dağıtımlar arasında menü ve komut isimlerinde ufak tefek farklılıklar olabilir. CentOS 9 dokümantasyonunu incelemek faydalı olabilir.

1. CWP’nin Log Temizleme Scriptini Kullanma

CWP, kendi dahili temizleme scriptine sahiptir. Bu script, log dosyalarını hızlıca temizlemek için kullanılabilir. SSH üzerinden root olarak giriş yapın ve şu komutu çalıştırın:

Bu komut, gereksiz log dosyalarını temizleyecek ve disk alanı açacaktır.

2. Bash Script ile Hızlı Log Temizleme

Eğer kendi scriptinizi oluşturmak istiyorsanız, bash kullanarak basit bir script yazabilirsiniz. SSH terminaline bağlanarak şu adımları izleyin:

Bir bash script oluşturun:

İçine aşağıdaki kodları ekleyin:

Scripti çalıştırılabilir hale getirin:

Scripti çalıştırmak için:

3. Cron Job ile Otomatik Temizleme

Disk alanını düzenli olarak temizlemek için cron job oluşturabilirsiniz. Böylece belirlediğiniz periyotlarda loglar otomatik olarak temizlenir. SSH terminalinde cron job eklemek için:

Şu satırı ekleyin (her gece 3:00’te log temizleme için):

Bu yöntemlerle disk alanınızı optimize edebilir, log dosyalarını temizleyerek sunucu performansını artırabilirsiniz.