Журнал доступа замер на какой-то дате: файл лежит, размер не меняется, в журнале ошибок пусто. Сайт продолжает работать. Вы теряете не только видимость — всё, что зависит от логов, тоже тихо останавливается.
Главный процесс OpenLiteSpeed стартует от root, но обслуживающие запросы рабочие процессы понижаются до непривилегированного пользователя (обычно nobody или lsadm). Именно этот процесс открывает файл лога. Если каталог логов имеет права 750 и принадлежит другому пользователю, рабочий процесс не сможет его открыть — и не сообщит об этом как об ошибке, а просто перестанет писать. Проблема повторяется и после ротации: если новый файл создаётся с неверным владельцем, запись больше не возобновится. Решение — привести владельца и права каталога в соответствие с пользователем, от которого реально работает OpenLiteSpeed.
Вы открываете журнал доступа, и последняя строка датирована неделями ранее. Сайт работает, посетители приходят, а в файл ничего не дописывается. В журнале ошибок подсказок нет — часто потому, что он лежит в том же каталоге и тоже не пишется.
Этот сбой особенно обманчив, потому что ничто не выглядит сломанным. Сервер здоров, страницы открываются, мониторинг зелёный. Просто вы ослепли.
OpenLiteSpeed применяет разделение привилегий: главный процесс стартует от root, чтобы занять привилегированные порты, а затем понижает обрабатывающие запросы процессы до непривилегированного пользователя. Файл лога открывает и пишет именно вторая группа.
В установках через панель каталог логов часто принадлежит пользователю сайта или root и имеет права 750. Это означает: «владелец читает, пишет и входит; группа читает и входит; остальные не могут ничего». Если рабочий пользователь OpenLiteSpeed не владелец и не в группе, он не может даже войти в каталог.
Неоткрываемый файл лога не является для OpenLiteSpeed фатальной ошибкой. Сервер продолжает обслуживать запросы и отбрасывает запись. Это разумное решение — сайт не должен падать из-за логирования, — но оно усложняет диагностику.
Чтобы выставить верные права, нужно знать, кто пишет. Ответ — в основной конфигурации:
grep -E '^user|^group' /usr/local/lsws/conf/httpd_config.confМожно подтвердить и по работающим процессам: первая строка — главный процесс (root), остальные — рабочие:
ps -eo user,group,comm | grep -E 'litespeed|lshttpd'Рядом положите текущее состояние каталога логов:
ls -la /home/example.com/logs/Если владелец каталога отличается от рабочего пользователя, а права — 750, причина найдена.
Чище всего отдать каталог группе, от которой работает OpenLiteSpeed, и дать этой группе право записи — так вы решаете задачу, не открывая каталог всем:
chgrp nogroup /home/example.com/logs
chmod 770 /home/example.com/logsИсправьте владельца и у существующих файлов: верные права на каталог не помогут, если сам старый файл недоступен для записи:
chown nobody:nogroup /home/example.com/logs/*.log
/usr/local/lsws/bin/lswsctrl restartПосле перезапуска отправьте запрос и убедитесь, что записи действительно идут, — не полагайтесь на предположение:
curl -sS -o /dev/null https://example.com/
tail -2 /home/example.com/logs/example.com.access_logВот здесь начинается коварство. Вы исправляете права каталога, считаете задачу закрытой, а через несколько дней логи снова замирают. Причина — ротация создаёт новый файл с неверным владельцем.
В конфигурации ротации нужно явно указать, кому принадлежит новый файл:
create 0640 nobody nogroupЕсли вы используете собственную настройку rollingSize в OpenLiteSpeed, файл создаёт он сам и проблемы не возникает. Путаница начинается там, где внешний logrotate и внутренняя ротация борются за один файл: выберите что-то одно, не запускайте оба.
Потеря лога неприятна сама по себе, но настоящая цена — всё, что от него зависит. Когда fail2ban не находит строк для чтения, он не выдаёт ошибку — он просто никого не банит. Jail показывается активным, вывод статуса выглядит здоровым, счётчик банов стоит на нуле.
fail2ban-client status wordpress-olsВы можете видеть «Currently failed: 0, Total banned: 0» не потому, что перебора паролей нет, а потому, что лог не читается. На сайте с реальным трафиком долгий ноль — не норма; проверьте, идут ли записи.
То же касается статистики трафика, отслеживания ошибок и аудита безопасности. Принимая сервер, одним из первых дел проверьте, относятся ли логи к сегодняшнему дню.
Молчаливые сбои дороже шумных: вы не знаете об их существовании, пока не решите их поискать. Права на каталог логов — хрестоматийный случай: одна ошибка в chmod отключает и видимость, и построенный поверх неё слой безопасности, не оставляя следов нигде. Добавьте в список обслуживания одну строку: последняя строка лога — сегодняшняя?
grep -E '^user|^group' /usr/local/lsws/conf/httpd_config.confchgrp nogroup logs && chmod 770 logs плюс владелец файловcreate 0640 nobody nogrouprollingSize на одном файлеСкорее всего, рабочий пользователь OpenLiteSpeed не может его открыть. Главный процесс стартует от root, но обрабатывающие запросы процессы понижаются до непривилегированного пользователя; если каталог логов имеет права 750 и этот пользователь не владелец и не в группе, он не может даже войти. OpenLiteSpeed не считает это фатальным и молча отбрасывает запись.
Это ротация логов. Если созданный при ротации новый файл получает неверного владельца, запись снова прекращается. Добавьте в конфигурацию logrotate строку create 0640 nobody nogroup. И не запускайте внешний logrotate вместе с собственной настройкой rollingSize на одном файле.
Прямая. Когда fail2ban нечего читать, он не выдаёт ошибку: jail выглядит активным, счётчик банов стоит на нуле. На сайте с реальным трафиком это не норма. Сначала проверьте, идут ли записи в лог, и только потом — шаблон фильтра.
Решит, но так делать не стоит. Право записи для всех позволяет любому процессу на сервере изменить или удалить записи, и журнал перестаёт быть надёжным источником для аудита. Правильный путь — отдать каталог группе OpenLiteSpeed и использовать 770.