Erişim kaydı belli bir tarihte donmuştur; dosya durur, boyutu değişmez, hata kaydında tek satır yoktur. Site normal çalışmaya devam eder. Kaybettiğiniz şey sadece görünürlük değildir — log'a bağlı her şey de sessizce durur.
OpenLiteSpeed ana süreci root olarak başlar, ama istekleri karşılayan işçi süreçler ayrıcalıksız bir kullanıcıya düşer (çoğu kurulumda nobody ya da lsadm). Log dosyasını açan taraf bu ayrıcalıksız süreçtir. Log dizini 750 izinli ve başka bir kullanıcıya aitse, işçi süreç dosyayı açamaz — ve bunu bir hata olarak bildirmez, yalnızca yazmayı bırakır. Sorun logrotate sonrasında da tekrarlar: yeni dosya yanlış sahiplikle oluşturulursa kayıt bir daha başlamaz. Çözüm, log dizininin sahipliğini ve iznini OpenLiteSpeed'in çalıştığı kullanıcıya göre ayarlamaktır.
Erişim kaydına bakarsınız ve son satır haftalar öncesine aittir. Site çalışmaktadır, ziyaretçi gelmektedir, ama dosyaya hiçbir şey eklenmemektedir. Hata kaydında ipucu yoktur; çoğu zaman hata kaydı da aynı dizinde olduğu için o da yazılmıyordur.
Bu arıza özellikle yanıltıcıdır çünkü hiçbir şey bozulmuş gibi görünmez. Sunucu sağlıklıdır, sayfalar açılır, izleme yeşildir. Yalnızca gözünüz kapanmıştır.
OpenLiteSpeed ayrıcalık ayrımı uygular: ana süreç root olarak başlar (ayrıcalıklı portları dinleyebilmek için), ardından istekleri işleyen süreçleri ayrıcalıksız bir kullanıcıya düşürür. Log dosyasını açan ve ona yazan taraf bu ikinci gruptur.
Panel kurulumlarında log dizini çoğu zaman site kullanıcısına ya da root'a ait olur ve 750 iznine sahiptir. 750, "sahibi okur-yazar-girer, grup okur-girer, diğerleri hiçbir şey yapamaz" demektir. OpenLiteSpeed'in işçi kullanıcısı ne sahip ne de gruptaysa, dizine giremez bile.
Açılamayan bir log dosyası, OpenLiteSpeed için ölümcül bir hata değildir. Sunucu isteği karşılamaya devam eder ve kaydı düşürür. Bu tasarım tercihi mantıklıdır — log yüzünden site düşmez — ama teşhisi zorlaştırır.
Doğru izni verebilmek için önce kimin yazdığını bilmeniz gerekir. Bu bilgi ana yapılandırmadadır:
grep -E '^user|^group' /usr/local/lsws/conf/httpd_config.confÇalışan süreçlerden de doğrulayabilirsiniz; ilk satır ana süreci (root), diğerleri işçileri gösterir:
ps -eo user,group,comm | grep -E 'litespeed|lshttpd'Log dizininin mevcut durumunu da yan yana koyun:
ls -la /home/alanadi.com/logs/Dizin sahibi ile işçi kullanıcı farklıysa ve izin 750 ise, sebebi bulmuşsunuz demektir.
En temiz yaklaşım, dizini OpenLiteSpeed'in çalıştığı gruba vermek ve gruba yazma izni tanımaktır. Böylece herkese açık hâle getirmeden sorunu çözersiniz:
chgrp nogroup /home/alanadi.com/logs
chmod 770 /home/alanadi.com/logsMevcut dosyaların sahipliğini de düzeltin; dizin izni doğru olsa bile eski dosya yazılamaz durumda kalabilir:
chown nobody:nogroup /home/alanadi.com/logs/*.log
/usr/local/lsws/bin/lswsctrl restartYeniden başlatmanın ardından bir istek gönderip kaydın gerçekten aktığını doğrulayın — varsaymayın:
curl -sS -o /dev/null https://alanadi.com/
tail -2 /home/alanadi.com/logs/alanadi.com.access_logAsıl sinsi kısım burasıdır. Dizin iznini düzeltip sorunu çözdüğünüzü düşünürsünüz; birkaç gün sonra loglar yine durur. Sebep, günlük döndürme sırasında yeni dosyanın yanlış sahiplikle oluşturulmasıdır.
Döndürme yapılandırmasında yeni dosyanın kimin adına açılacağı açıkça belirtilmelidir:
create 0640 nobody nogroupOpenLiteSpeed'in kendi rollingSize ayarını kullanıyorsanız dosyayı zaten kendisi oluşturur ve bu sorun çıkmaz. Karışıklık, harici logrotate ile dahili döndürmenin aynı dosyada çakıştığı kurulumlarda başlar: ikisinden birini seçin, ikisini birden çalıştırmayın.
Log'un durması tek başına da can sıkıcıdır, ama asıl bedel log'a bağlı sistemlerdir. fail2ban, okuyacak satır bulamadığında hata vermez — sadece hiç kimseyi engellemez. Jail listesinde kural aktif görünür, durum çıktısı sağlıklıdır, yasaklanan IP sayısı sıfırda kalır.
fail2ban-client status wordpress-ols"Currently failed: 0, Total banned: 0" çıktısını kaba kuvvet saldırısı olmadığı için değil, log okunamadığı için görüyor olabilirsiniz. Trafiği yüksek bir sitede bu sayının uzun süre sıfır kalması normal değildir; log akışını kontrol edin.
Aynı şey trafik istatistikleri, hata izleme ve güvenlik denetimi için de geçerlidir. Bir sunucuyu devraldığınızda ilk bakılacak yerlerden biri, logların gerçekten bugüne ait olup olmadığıdır.
Sessiz arızalar, gürültülü arızalardan pahalıdır: çünkü onları aramaya karar verene kadar varlıklarını bilmezsiniz. Log dizini izni bunun ders kitabı örneğidir — tek bir chmod hatası hem görünürlüğü hem de ona bağlı güvenlik katmanını devre dışı bırakır ve hiçbir yerde iz bırakmaz. Bakım listenize tek satır ekleyin: log dosyasının son satırı bugüne ait mi?
grep -E '^user|^group' /usr/local/lsws/conf/httpd_config.confchgrp nogroup logs && chmod 770 logs + dosya sahipliğicreate 0640 nobody nogroup satırı eksiktirrollingSize aynı anda kullanılmamalıBüyük ihtimalle OpenLiteSpeed'in işçi kullanıcısı dosyayı açamıyordur. Ana süreç root olarak başlar ama istekleri işleyen süreçler ayrıcalıksız bir kullanıcıya düşer; log dizini 750 izinliyse ve o kullanıcı sahip ya da grup değilse dizine giremez. OpenLiteSpeed bunu ölümcül hata saymaz, kaydı sessizce düşürür.
Sebep log döndürmedir. Döndürme sırasında oluşturulan yeni dosya yanlış sahiplikle açılırsa kayıt yeniden durur. logrotate yapılandırmasına create 0640 nobody nogroup satırını ekleyin. Ayrıca harici logrotate ile OpenLiteSpeed'in kendi rollingSize ayarını aynı dosyada birlikte kullanmayın.
Doğrudan ilgisi var. fail2ban okuyacak log satırı bulamadığında hata üretmez; jail aktif görünür ve yasaklanan IP sayısı sıfırda kalır. Trafiği olan bir sitede bu sayının uzun süre sıfır kalması normal değildir. Önce log akışını, sonra filtre desenini kontrol edin.
Çözer ama yapmayın. Log dizinine herkese yazma izni vermek, sunucudaki herhangi bir sürecin kayıtları değiştirmesine veya silmesine imkân tanır; bu da denetim izini güvenilmez kılar. Doğru yaklaşım dizini OpenLiteSpeed'in grubuna verip 770 kullanmaktır.