📖 Теория: Linux Mini project

К оглавлению урока

⚡ Суть проекта

  • Роль: веб-разработчик — восстановление Linux-сервера
  • Среда: Amazon EC2, Apache httpd, MediaWiki
  • Проблемы: httpd inactive → No space left → access_log 7 ГБ → неверный $wgServer → сломан cron
  • Решение: очистить лог → cp LocalSettings.php → исправить конфиг → починить cron → backup_logs.sh

Концепция проекта

Роль и задача

Вы — веб-разработчик, который получил задачу на восстановление работоспособности Linux-сервера. На сервере работает веб-приложение MediaWiki, веб-сервер Apache httpd и настроены бэкапы. По неизвестной причине сервис перестал работать.

Среда проекта

  • Облачная платформа: Amazon EC2 (Amazon Linux 2)
  • Веб-сервер: Apache HTTP Server (httpd)
  • Веб-приложение: MediaWiki — движок для Википедии
  • Подключение: SSH с ключом (ich.pem)
  • Адрес сервера: 18.192.103.67 (пример учебного сервера)

Что такое Apache httpd

Apache HTTP Server — один из самых распространённых веб-серверов в мире. Управляется через service httpd или systemctl httpd. Логи хранятся в /var/log/httpd/:

  • access_log — каждый HTTP-запрос к серверу
  • error_log — ошибки сервера

Что такое access_log и почему он переполняет диск

Access log — журнал работы веб-сервера, в который записываются все запросы, которые он обрабатывает. На нагруженном сервере этот файл может расти очень быстро — в нашем случае достиг 7 ГБ и занял всё доступное дисковое пространство (10 ГБ), что привело к остановке всех сервисов.

Признак проблемы с диском: при нажатии TAB в терминале появляется: -bash: cannot create temp file for here-document: No space left on device

MediaWiki и LocalSettings.php

MediaWiki — движок для wiki-сайтов (тот же, что за Википедией). Конфигурация хранится в файле /var/www/html/mediawiki/LocalSettings.php. Ключевой параметр:

# /var/www/html/mediawiki/LocalSettings.php
$wgServer = "https://18.153.51.162";

Если IP в $wgServer не совпадает с реальным IP сервера — MediaWiki не будет работать корректно даже после восстановления httpd.

Диагностика дискового пространства

Два главных инструмента:

# Показать использование файловых систем (human-readable)
df -h

# Найти файлы больше 100 МБ
find / -type f -size +100M

# То же, но с размером каждого
find / -type f -size +100M -exec du -h {} +

В нашем проекте df -h покажет: /dev/nvme0n1p1 10G 10G 0 100% / — диск занят на 100%.

Cron и ротация логов

После восстановления сервиса нужно предотвратить повторение инцидента. Для этого настраивается автоматическая ротация логов через cron:

  • Скрипт backup_logs.sh архивирует access_log в tar.gz
  • Удаляет архивы старше 3 дней (find -mtime +3 -exec rm)
  • Cron запускает скрипт ежедневно в полночь: 0 0 * * *

Некорректный cron root

В проекте у root уже есть задание cron, но оно некорректное:

* * * * * tar -czf /var/log/httpd/log_$(date +\%Y\%m\%d).tar.gz -C /var/log/httpd .

Проблемы этого задания:

  • Интервал * * * * * — каждую минуту (слишком часто)
  • Архивирует сам себя — архив создаётся в той же директории, что и логи, и попадает в следующий архив

Нужно изменить интервал на ежедневный (0 0 * * *) и перенести архивы в отдельную директорию.