Коллекция эксперта: скрипты обслуживания Linux в один клик (очистка мусора / смена DNS / мониторинг)

Честно говоря, в 2026 году маркетинговые обещания облачных провайдеров по-прежнему сыплются со всех сторон. У многих пользователей уже есть несколько «архивных топ-тарифов», купленных по скидкам, или 1-ядерные 1 ГБ машины, готовые под хостинг сайтов. Но возникает критическая проблема: купить сервер легко, а поддерживать его в рабочем состоянии — головная боль.

Особенно если речь идет о серверах с «мертвыми HDD (SMR-черепица)» или провайдерах «скам-хостинга», которые могут исчезнуть в любой момент. Стандартные образы ОС часто забиты мусорными логами, а базовые DNS-настройки могут быть сломаны, из-за чего установка окружения затягивается на часы.

Хватит воды. Сегодня мы разберем Linux-скрипты для обслуживания в один клик, которые эксперты запускают сразу после установки системы в 2026 году. Вы узнаете, как безопасно очищать мусор, как принудительно фиксировать DNS в современных системах, и развеем главный миф новичков — можно ли вообще смотреть температуру на VPS?

🥇 Сводная таблица основных скриптов обслуживания (оптимизировано для 2026)

Для наглядного сравнения я собрал самые востребованные направления для ежедневного обслуживания. Обратите внимание на карточку ниже:

🧠 Практика: три ключевых сценария обслуживания и скрипты в один клик

⚠️ Важное условие: Все указанные скрипты затрагивают сетевые настройки системы и очистку пакетного менеджера. Их необходимо запускать от имени пользователя root или добавлять sudo перед каждой командой для получения прав администратора.

1. Глубокая очистка мусора: не позволяйте старым логам съедать ваш архивный топ-тариф

Многие новички, купив сервер с диском на 10 ГБ, через несколько дней после установки веб-окружения получают ошибку No space left on device (недостаточно места на диске). Обычно это происходит из-за того, что стандартные логи journalctl и кэш пакетного менеджера ежедневно разрастаются.

Для таких серверов, которые легко превращаются в «простаивающие серверы» с малым диском, вам потребуется этот комбинированный скрипт очистки. Эксперты специально разделили его для Debian и RHEL-систем, чтобы избежать ошибок пакетного менеджера.

✅ Скрипт очистки для Debian / Ubuntu:

#!/bin/bash
echo "Начало очистки мусора в системе Debian/Ubuntu..."
if [ "$(id -u)" -ne 0 ]; then echo "Ошибка: требуется запуск с правами root!"; exit 1; fi

# Очистка системных логов, сохранение за 7 дней (баланс между отладкой и экономией места)
journalctl --vacuum-time=7d
# Очистка неиспользуемых зависимостей и кэша пакетов
apt autoremove -y && apt clean -y && apt autoclean -y
# Удаление только тех файлов кэша пользователей, которые не открывались более 7 дней, чтобы не удалить важные конфиги
find /root/.cache/ -type f -atime +7 -delete 2>/dev/null
find /home/*/.cache/ -type f -atime +7 -delete 2>/dev/null
echo "Очистка завершена! Крепкая стабильность."

(Примечание: перед запуском apt autoremove, если вы вручную компилировали и устанавливали ключевые библиотеки, проверьте список удаляемых пакетов, чтобы случайно не стереть нужное.)

✅ Скрипт очистки для CentOS / RHEL / AlmaLinux:

#!/bin/bash
echo "Начало очистки мусора в системе CentOS/RHEL..."
if [ "$(id -u)" -ne 0 ]; then echo "Ошибка: требуется запуск с правами root!"; exit 1; fi

journalctl --vacuum-time=7d
# Автоматическое определение пакетного менеджера yum/dnf
if command -v dnf >/dev/null 2>&1; then
    dnf autoremove -y && dnf clean all
else
    yum autoremove -y && yum clean all
fi
find /root/.cache/ -type f -atime +7 -delete 2>/dev/null
find /home/*/.cache/ -type f -atime +7 -delete 2>/dev/null
echo "Очистка завершена!"

2. Принудительная смена DNS: устранение обрывов сети у провайдеров «скам-хостинга»

Вы наверняка сталкивались с такой аномалией: сервер пингуется, но при загрузке скриптов через wget или выполнении apt update процесс зависает на Resolving host.... Причина в том, что у некоторых мелких провайдеров настройки DNS на хост-узлах изначально настроены крайне плохо.

⚠️ Временное решение: Если DNS полностью перестал работать и вы не можете открыть сайт или загрузить скрипт через wget, сначала выполните эту команду для восстановления базового разрешения имен, а затем запустите полный скрипт ниже:

echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf > /dev/null

Почему нельзя просто заблокировать файл через chattr +i?

В современных Linux-дистрибутивах 2026 года (например, Ubuntu 20.04+, Debian 11+) за DNS по умолчанию отвечает служба systemd-resolved. Файл /etc/resolv.conf в этом случае — лишь символическая ссылка на файловую систему в оперативной памяти (tmpfs). Если вы попытаетесь жестко заблокировать его, система выдаст ошибку, а разрешение имен полностью сломается! Вам потребуется этот финальный скрипт с интеллектуальным определением архитектуры:

✅ Скрипт интеллектуальной блокировки DNS (работает на всех архитектурах):

#!/bin/bash
echo "Принудительное изменение и блокировка DNS..."
if [ "$(id -u)" -ne 0 ]; then echo "Ошибка: требуется запуск с правами root!"; exit 1; fi

# Проверка на современную систему с systemd
if pidof systemd > /dev/null; then
    # Безопасное изменение основного конфига systemd-resolved (учитывает уже раскомментированные строки)
    sed -i 's/^#*DNS=.*/DNS=1.1.1.1 8.8.8.8/' /etc/systemd/resolved.conf
    sed -i 's/^#*DNSStubListener=.*/DNSStubListener=yes/' /etc/systemd/resolved.conf
    systemctl restart systemd-resolved
    # Принудительная пересоздание симлинка для защиты от перезаписи DHCP
    ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
    echo "DNS успешно изменен! В системах с systemd изменения сохраняются навсегда, файлы блокировки не нужны."
else
    # Адаптация для Alpine или старых систем без systemd
    chattr -i /etc/resolv.conf 2>/dev/null
    cat > /etc/resolv.conf <<EOF
nameserver 1.1.1.1
nameserver 8.8.8.8
EOF
    chattr +i /etc/resolv.conf
    echo "DNS успешно изменен и заблокирован через chattr."
fi

3. Мониторинг температуры и состояния оборудования: развеиваем главный миф!

Это самый распространенный пробел в знаниях. Многие новички, следуя старым инструкциям из интернета, пытаются установить lm-sensors на свои дешёвые VPS, чтобы проверить температуру процессора.

Эксперты раскрывают суровую правду: на 99% стандартных VPS невозможно увидеть реальную температуру CPU!

Поскольку вы арендуете виртуальную машину (на базе KVM / OpenVZ / LXC), данные с аппаратных датчиков физического уровня по умолчанию полностью изолированы хост-узлом. Реальную температуру через команду sensors можно получить только на выделенных физических серверах (Bare Metal) или в редких случаях, когда провайдер настроил аппаратный проброс датчиков в кастомных KVM.

Если ваш VPS постоянно зависает или падает, дело не в температуре. В 99% случаев причина в серьезном «оверселле (повышенной перепродаже)» или наличии на том же узле «шумного соседа», который активно майнит.

✅ Альтернатива: скрипт в один клик для проверки реального уровня «эксплуатации» (CPU Steal):

Забудьте про температуру. Нам нужен параметр Steal Time (время CPU, отнятое хост-узлом или соседями). Просто запустите:

top

В верхней части вывода найдите строку %Cpu(s) и обратите внимание на значение st (Steal Time).

Примечание: этот параметр работает только для архитектур полной виртуализации, таких как KVM/Xen. В контейнерах OpenVZ/LXC из-за общего ядра реальное значение st не отображается.

Наблюдайте за интерфейсом top в течение 5–10 минут. Если среднее значение st стабильно превышает 5%, это указывает на возможный оверселл. Если оно держится выше 10% — это критический оверселл! В таком случае лучшее решение — не запускать скрипты, а срочно сделать бэкап данных и готовиться «выйти» с запросом на возврат средств.

Если вы хотите быстро определить, какой именно процесс пожирает ресурсы, вот дополнительный минималистичный скрипт для диагностики:

# Вывод TOP-10 процессов по загрузке CPU
ps aux --sort=-%cpu | head -11

🛒 Итоги по избеганию ошибок и ежедневным операциям

Независимо от того, купили ли вы сервер с премиум-маршрутами или самый дешевый VPS для экспериментов, логика обслуживания остается неизменной: поддерживайте чистоту диска, обеспечивайте стабильное разрешение имен и постоянно отслеживайте аномальную нагрузку.

Итог: Не ведитесь на модные технические термины. Освоив эти три глубоко оптимизированных скрипта, вы обеспечите своему VPS крепкую стабильность. Сэкономленное на бессмысленных манипуляциях с системой время лучше потратить на оптимизацию вашего интернет-магазина DTC или реальных бизнес-процессов. В этом и заключается истинная цель работы с серверами!

❓ FAQ: Частые вопросы по обслуживанию и диагностике Linux VPS

Q1: Почему при запуске команды sensors на VPS система не находит ни одного датчика?

A1: Потому что вы используете виртуализированный экземпляр (например, KVM или LXC). Физическое оборудование (включая материнскую плату и датчики температуры CPU) полностью изолировано механизмами безопасности хост-узла. Это нормальное поведение, диагностика не требуется. Для оценки нагрузки сервера используйте команду top и отслеживайте параметры Load Average (средняя нагрузка системы) и st (Steal Time).

Q2: Повлияет ли запуск скрипта очистки на мое веб-окружение (например, Nginx/MySQL)?

A2: Предоставленные в статье скрипты очистки абсолютно безопасны. Команда apt autoremove удаляет только изолированные пакеты, от которых больше ничего не зависит, а journalctl --vacuum-time=7d стирает только системные логи старше 7 дней. Они никак не затрагивают конфигурации работающих служб, файлы баз данных или директории веб-сайтов. Пользователи хостинга могут запускать их без опаски.

Q3: Я принудительно изменил /etc/resolv.conf, но после перезагрузки сервера DNS снова сбросился. Почему?

A3: В современных Linux (например, Ubuntu 20.04+) сетевыми настройками динамически управляет служба systemd-resolved, которая перезаписывает файл resolv.conf при каждом запуске. Прямое редактирование этого файла не даст эффекта. Используйте «Скрипт интеллектуальной блокировки DNS» из этой статьи: он вносит изменения в базовый файл /etc/systemd/resolved.conf, что гарантирует сохранение настроек после перезагрузки.