Apache Modül Sorunları: Yükleme ve Çakışma Hatalarını Çözme

Apache kurulumu tamamdır, config dosyaları yerli yerinde, ama sunucu bir türlü ayağa kalkmıyor. Ya da daha kötüsü, çalışıyor ama bazı özellikler sessiz sedasız devre dışı. Apache modül sorunları tam da böyle sinir bozucu bir karaktere sahip: bazen çığlık atar, bazen hiç ses çıkarmaz. Bu yazıda modül yükleme hatalarını, çakışma senaryolarını ve bunları nasıl düzelteceğini adım adım ele alacağız.

Apache Modül Sistemi Nasıl Çalışır

Apache’nin modüler yapısı onun en büyük güçlerinden biri, ama aynı zamanda sorun kaynağı da olabiliyor. Temel mantık şu: Apache çekirdeği minimal bir yapıyla başlar, ihtiyaç duyulan işlevsellik modüller aracılığıyla eklenir. Bu modüller ya derleme zamanında statik olarak gömülür ya da çalışma zamanında dinamik olarak yüklenir.

Dinamik modüller .so uzantılı paylaşımlı kütüphane dosyalarıdır ve genellikle şu dizinlerde bulunur:

• /usr/lib/apache2/modules/ (Debian/Ubuntu sistemlerde)
• /usr/lib64/httpd/modules/ (RHEL/CentOS sistemlerde)
• /usr/local/lib/httpd/modules/ (kaynak koddan derlenmiş kurulumlar)

Mevcut yüklü modülleri görmek için:

# Statik ve dinamik tüm modülleri listele
apache2 -M
# veya
httpd -M

# Sadece dinamik modülleri filtrele
apache2 -M 2>/dev/null | grep -i "shared"

# Modül dosyalarını doğrudan listele
ls -la /usr/lib/apache2/modules/

Bu komutların çıktısını iyice incelemeye alışman gerekiyor. Özellikle apache2 -M komutunun hata çıktısı verip vermediğine dikkat et, çünkü bu komut aynı zamanda config dosyalarını da parse ediyor.

En Yaygın Modül Yükleme Hataları

“Cannot load” Hatası

Apache loglarında en sık karşılaşılan modül hatası budur:

AH00534: httpd: Configuration error: No MPM loaded.
[Wed Oct 11 14:23:01.123456 2023] [so:error] [pid 1234] AH06665: No code signing authority...
httpd: Syntax error on line 12 of /etc/httpd/conf/httpd.conf:
Cannot load modules/mod_ssl.so into server: libssl.so.3: cannot open shared object file

Bu hatanın birkaç farklı nedeni olabilir. En yaygın ikisi: modül dosyası gerçekten o dizinde yok, ya da modülün bağımlı olduğu sistem kütüphanesi eksik.

# Modül dosyasının var olup olmadığını kontrol et
ls -la /usr/lib/apache2/modules/mod_ssl.so

# Modülün bağımlılıklarını kontrol et
ldd /usr/lib/apache2/modules/mod_ssl.so

# Eksik kütüphane sorunlarını bul
ldd /usr/lib/apache2/modules/mod_ssl.so | grep "not found"

ldd çıktısında not found görüyorsan iş biraz daha karmaşıklaşıyor. Kütüphane ya hiç kurulu değil ya da kurulu ama ldconfig cache’i güncellenmemiş.

# Kütüphane cache'ini güncelle
sudo ldconfig

# Sonra tekrar dene
ldd /usr/lib/apache2/modules/mod_ssl.so

# Belirli bir kütüphaneyi ara
find /usr/lib* /lib* -name "libssl.so*" 2>/dev/null

Modül Versiyonu Uyumsuzluğu

Apache güncelledikten sonra eski modüllerin çalışmayı reddetmesi çok karşılaşılan bir durum. Özellikle üçüncü parti modüllerde (mod_security, mod_pagespeed, mod_wsgi gibi) sık görülür.

# Apache sürümünü öğren
apache2 -v
httpd -v

# Modülün hangi Apache sürümüne göre derlendiğini kontrol et
strings /usr/lib/apache2/modules/mod_wsgi.so | grep -i "apache"

# Paket yöneticisi üzerinden modülün sürümünü kontrol et
apt show libapache2-mod-wsgi-py3 2>/dev/null | grep Version
dpkg -l | grep mod-wsgi

Gerçek dünya senaryosu: Ubuntu 20.04’ten 22.04’e yükseltme yapıyorsun, Apache 2.4.41’den 2.4.52’ye geçiyor ve mod_wsgi nedeniyle Django uygulamaların çöküyor. Çözüm genellikle modülü yeniden kurmak:

# Modülü kaldır ve yeniden kur
sudo apt remove libapache2-mod-wsgi-py3
sudo apt install libapache2-mod-wsgi-py3

# Eğer özel bir Python ortamı kullanıyorsan pip ile kur
pip install mod_wsgi
mod_wsgi-express module-config

Modül Çakışma Sorunları

Modül çakışmaları, yükleme hatalarından daha sinsi bir karaktere sahip. Sunucu genellikle ayağa kalkar ama beklenmedik davranışlar sergiler.

MPM Çakışması

Apache’nin en kritik çakışma noktası MPM (Multi-Processing Module) seçimidir. Aynı anda sadece bir MPM aktif olabilir: prefork, worker veya event.

# Aktif MPM'i kontrol et
apache2 -V | grep -i mpm
httpd -V | grep MPM

# Hangi MPM modüllerinin enable edildiğini gör
ls /etc/apache2/mods-enabled/ | grep mpm

Eğer birden fazla MPM enable edilmişse Apache başlamayı reddeder:

AH00534: httpd: Configuration error: No MPM loaded.
[error] AH00526: Syntax error on line 1 of /etc/apache2/mods-enabled/mpm_event.load:
Cannot load /usr/lib/apache2/modules/mod_mpm_event.so: already loaded

# Mevcut MPM'i disable et
sudo a2dismod mpm_prefork

# Yeni MPM'i enable et
sudo a2enmod mpm_event

# PHP kullanıyorsan dikkat: PHP-FPM ile event MPM kullan
# mod_php ile prefork MPM kullanman gerekir
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.1-fpm

Kritik not: mod_php (libapache2-mod-php) thread-safe değildir ve kesinlikle prefork MPM gerektirir. worker veya event MPM ile mod_php kullanmaya çalışırsan ya hata alırsın ya da veri bütünlüğü sorunlarıyla karşılaşırsın. Modern kurulumlarda PHP-FPM + event MPM kombinasyonunu tercih et.

SSL ve Diğer Modüller Arasındaki Çakışma

mod_ssl birçok başka modülle çakışabilir. Özellikle mod_gnutls ile birlikte kullanmaya çalışırsan:

# Çakışan modülleri tespit et
apache2 -t 2>&1 | head -20

# Config syntax kontrolü
apache2 -t -D DUMP_MODULES 2>&1 | grep -E "(ssl|tls|gnutls)"

Tipik hata mesajı şöyle görünür:

AH02562: Failed to configure certificate (with chain), check /etc/ssl/certs/example.com.crt
SSLEngine: mod_ssl and mod_gnutls are mutually exclusive, only one SSL/TLS module can be loaded

Çözüm basit ama dikkatli yapılmalı:

# mod_gnutls'u devre dışı bırak
sudo a2dismod gnutls

# mod_ssl'in aktif olduğundan emin ol
sudo a2enmod ssl

# Config'i test et
sudo apache2ctl configtest

# Servisi yeniden başlat
sudo systemctl restart apache2

mod_rewrite ve mod_alias Çakışması

Bu ikisi birlikte kullanıldığında öncelik sırası önemli hale gelir. mod_alias direktifleri (Alias, Redirect) mod_rewrite kurallarından önce işlenir ve bu beklenmedik davranışlara yol açabilir.

# Her iki modülün de yüklü olduğunu doğrula
apache2 -M | grep -E "(rewrite|alias)"

# Config'de çakışma potansiyeli olan direktifleri bul
grep -rn "^Alias|^Redirect|^RewriteRule|^RewriteCond" /etc/apache2/sites-enabled/

Gerçek senaryo: Bir e-ticaret sitesinde URL yönlendirmeleri karışmış. .htaccess‘te RewriteRule ile kurgulanmış URL’ler, VirtualHost config’indeki Alias direktifiyle çakışıyor.

# /etc/apache2/sites-enabled/shop.conf örneği
# Sorunlu konfigürasyon:
# Alias /images /var/www/media/images
# Bu, RewriteRule ile /images/ yolunu yakalamayı engelleyebilir

# Çözüm: Alias'ı daha spesifik yap veya RewriteRule önceliğini ayarla
# ya da mod_rewrite içinde PassThrough kullan:
# RewriteRule ^/images - [L]

Log Analizi ile Modül Sorunlarını Tespit Etmek

Apache logları modül sorunlarını çözmede birincil kaynağın. Ama doğru log seviyesiyle çalışman şart.

# Log seviyesini geçici olarak debug'a al
# /etc/apache2/apache2.conf veya ilgili VirtualHost config'inde:
# LogLevel debug

# Sadece belirli modülün debug loglarını aktif et (Apache 2.4+)
# LogLevel ssl:trace3 rewrite:trace5

# Canlı log takibi
tail -f /var/log/apache2/error.log | grep -E "(AH[0-9]+|error|warn|module)"

# Son 100 satırda modül hatası ara
tail -100 /var/log/apache2/error.log | grep -i "module|cannot load|so:"

Startup Hatalarını Yakalamak

Apache başlarken oluşan modül hatalarını yakalamak için journalctl kullanmak genellikle daha güvenilir:

# systemd journal üzerinden Apache startup hatalarını izle
journalctl -u apache2 -b --no-pager | grep -E "(error|warn|fail|module)"

# Bir önceki boot'taki hataları gör
journalctl -u apache2 -b -1 --no-pager

# Gerçek zamanlı izleme
journalctl -u apache2 -f

# Apache'yi manuel olarak başlatıp hatayı direkt gör
sudo apache2 -X 2>&1
# -X bayrağı Apache'yi tek process modunda başlatır, debug için idealdir

apache2 -X komutu özellikle kullanışlı çünkü Apache’yi arka plana atmadan başlatıyor ve tüm hataları terminale basıyor. Modül yükleme sorunlarını tespit etmenin en hızlı yolu bu.

Debian/Ubuntu’da Modül Yönetimi

a2enmod ve a2dismod araçları Debian tabanlı sistemlerin güzelliği. Ama bunların perde arkasında ne yaptığını bilmek sorun çözmeyi kolaylaştırıyor.

# a2enmod aslında şunu yapıyor:
# /etc/apache2/mods-available/modname.load -> /etc/apache2/mods-enabled/modname.load sembolik link oluşturuyor

# Manuel olarak aynı şeyi yapabilirsin:
sudo ln -s /etc/apache2/mods-available/ssl.load /etc/apache2/mods-enabled/ssl.load
sudo ln -s /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-enabled/ssl.conf

# Bozuk sembolik linkleri bul (modül silindikten sonra kalabilir)
find /etc/apache2/mods-enabled/ -xtype l -print
# Bu komut hedefi olmayan (dangling) symlink'leri listeler

# Bozuk linkleri temizle
find /etc/apache2/mods-enabled/ -xtype l -delete

# Sonra config'i test et
sudo apache2ctl configtest

Gerçek senaryo: Bir paket güncellemesi sırasında mod_php7.4 kaldırıldı ama symlink /etc/apache2/mods-enabled/ içinde kalmaya devam etti. Apache her başlatmada “Cannot load” hatası veriyordu ama neden bölümünde symlink’in bozuk olduğu net görünmüyordu. find komutuyla dangling symlink’leri tespit etmek bu tür durumları hızla çözüyor.

RHEL/CentOS/Rocky Linux’ta Modül Yönetimi

Red Hat tabanlı sistemlerde modül yapısı biraz farklı. Sembolik link sistemi yok, bunun yerine LoadModule direktifleri conf dosyalarında tutuluyor.

# RHEL sistemlerde aktif modülleri listele
grep -r "^LoadModule" /etc/httpd/conf.modules.d/ | sort

# Belirli bir modülü devre dışı bırak (satır başına # ekle)
sudo sed -i 's/^LoadModule mpm_prefork_module/#LoadModule mpm_prefork_module/' 
    /etc/httpd/conf.modules.d/00-mpm.conf

# Config kontrolü
sudo httpd -t

# SELinux modül sorunlarına dikkat!
# SELinux bazen modüllerin yüklenmesini engelleyebilir
ausearch -c 'httpd' --raw | audit2allow -M myhttpd
# semodule -i myhttpd.pp

# SELinux loglarını kontrol et
grep httpd /var/log/audit/audit.log | grep denied

SELinux uyarısı: RHEL sistemlerde modül sorunlarının arkasında sıklıkla SELinux yatıyor. Apache “Cannot load” hatası veriyorsa ve modül dosyası mevcut, bağımlılıklar tamam görünüyorsa ilk şüphelenen SELinux ol.

Üçüncü Parti Modüllerde Sorun Giderme

mod_security, mod_pagespeed, mod_evasive gibi üçüncü parti modüller sisteme paket yöneticisi dışından kurulduğunda ek sorunlar çıkarabiliyor.

mod_security Sorunları

# mod_security'nin doğru yüklenip yüklenmediğini kontrol et
apache2 -M | grep security

# mod_security config sözdizimini kontrol et
sudo apache2ctl -t -D DUMP_RUN_CFG 2>&1 | head -30

# mod_security kural dosyası hatalarını bul
grep -r "SecRule|SecAction" /etc/modsecurity/ | head -5
sudo apache2 -t 2>&1 | grep -i "modsecurity|SecRule"

# Kural setini geçici devre dışı bırakarak test et
# /etc/modsecurity/modsecurity.conf içinde:
# SecRuleEngine DetectionOnly
# yerine Off yaparak Apache'nin başlayıp başlamadığına bak

Kaynak Koddan Derlenen Modüller

Bazen paket yöneticisinde olmayan modülleri kendin derlemen gerekiyor. Bu durumda en önemli nokta Apache’nin apxs (APache eXtenSion) aracını doğru versiyonla kullanmak:

# apxs'in doğru Apache'ye ait olduğunu doğrula
which apxs
apxs -q PREFIX
apxs -q VERSION

# Modülü derle ve kur
cd /usr/src/mod_custom
sudo apxs -c -i mod_custom.c

# Derleme başarılıysa modülü Apache config'ine ekle
echo "LoadModule custom_module /usr/lib/apache2/modules/mod_custom.so" | 
    sudo tee /etc/apache2/mods-available/custom.load

sudo a2enmod custom
sudo apache2ctl configtest

Config Test ve Rollback Stratejisi

Modül değişikliklerini production’da yapmadan önce mutlaka test etmeli, hızlı geri dönüş planın olmalı.

# Değişiklik öncesi mevcut konfigürasyonu yedekle
sudo cp -r /etc/apache2 /etc/apache2.backup.$(date +%Y%m%d_%H%M%S)

# Config dosyasını test et (servis yeniden başlatmadan)
sudo apache2ctl configtest
# ya da
sudo apachectl -t

# Grace restart: aktif bağlantıları kesmeden yeniden yükle
sudo apache2ctl graceful

# Hızlı rollback gerekirse
sudo rm -rf /etc/apache2
sudo cp -r /etc/apache2.backup.20231011_142301 /etc/apache2
sudo systemctl restart apache2

# Yüklü modüllerin tam listesini bir dosyaya kaydet (documentation için)
apache2 -M 2>/dev/null | sort > /root/apache_modules_$(date +%Y%m%d).txt

Graceful restart yetenği özellikle production’da kritik. Normal restart tüm aktif bağlantıları keserken graceful mevcut bağlantıların tamamlanmasını bekler. Modül güncellemelerinde her zaman graceful tercih et.

Sık Karşılaşılan Hata Kodları ve Anlamları

Apache modül hatalarında AH prefix’li hata kodları içeriği anlamamızı kolaylaştırıyor:

• AH00534: MPM yüklenmemiş veya birden fazla MPM aktif
• AH00526: Syntax hatası, genellikle yanlış direktif veya modül yüklenmeden kullanılan direktif
• AH01630: mod_ssl ile ilgili sertifika veya protokol hatası
• AH00052: Geçersiz AllowOverride değeri, genellikle ilgili modül yüklenmemiş
• AH06665: Kod imzalama hatası (macOS’ta sık görülür)
• AH01909: SSL bağlantı hatası, cipher suite uyumsuzluğu

# Belirli bir AH kodunu logda ara
grep "AH00534" /var/log/apache2/error.log

# Tüm AH kodlu hataları say ve sırala
grep -oh "AH[0-9]{5}" /var/log/apache2/error.log | sort | uniq -c | sort -rn

Bu son komut özellikle işe yarıyor: logda en sık tekrar eden hata kodlarını görüyorsun ve o koda odaklanıyorsun. Binlerce satır log yerine 10 satırlık özet.

Modül Bağımlılık Haritası

Bazı modüller başka modüllerin aktif olmasını gerektirir. Bu bağımlılıkları bilmemek saatler kaybettiriyor:

• mod_ssl çalışmak için mod_socache_shmcb modülüne ihtiyaç duyar (session cache için)
• mod_proxy_fcgi için mod_proxy aktif olmalı
• mod_dav_svn için hem mod_dav hem mod_authz_svn gerekli
• mod_auth_digest için mod_auth_basic gerekmiyor ama karıştırılıyor
• mod_deflate için mod_filter önerilir (Apache 2.4+)

# Bağımlılık sorununu config test ile yakala
sudo apache2ctl configtest 2>&1 | grep -i "required|depends|need"

# mod_proxy_fcgi için örnek doğru sıra
sudo a2enmod proxy
sudo a2enmod proxy_fcgi
sudo a2enmod setenvif
sudo apache2ctl configtest

Sonuç

Apache modül sorunları genellikle birkaç temel kategoriye düşüyor: eksik veya bozuk modül dosyaları, kütüphane bağımlılığı sorunları, MPM çakışmaları ve yanlış modül sıralaması. Sorun giderme sürecinde izlemen gereken sıra şu şekilde olmalı: önce apache2 -t ile syntax kontrolü, sonra apache2 -M ile yüklü modülleri doğrulama, ardından ldd ile bağımlılık kontrolü ve son olarak log dosyalarında AH kodlarını inceleme.

En önemli alışkanlık config değişikliklerini yedeklemek ve configtest komutunu servisi yeniden başlatmadan önce mutlaka çalıştırmak. Production sistemlerde graceful restart kullanmak ise aktif kullanıcıları etkilememek açısından kritik.

Karşılaştığın hatayı logda gördüğünde önce AH kodunu not al, Apache dokümantasyonunda veya hata veritabanında o koda bak. Çoğu durumda sorunun tam açıklaması ve çözüm yolu orada yazıyor. Tecrübe de önemli tabii, zamanla hangi hata hangi modül sorununa işaret ediyor sezgisel olarak anlıyorsun. Ama sistematik yaklaşım her zaman sezginin önünde gelir.