30 дней без панелей управления: эксперимент с ручной настройкой сервера вместо ISPmanager, cPanel и Plesk

Панели управления — ISPmanager, cPanel, Plesk — давно стали стандартом для хостинг-провайдеров и веб-мастеров. Они обещают «всё в одном клике»: создание сайта, почтового ящика, SSL-сертификата, базы данных. Но что, если отключить эту «обёртку» и управлять сервером напрямую? В 2025 году один системный администратор провёл смелый эксперимент: 30 дней без панелей управления. Эта статья — не личный дневник, а объективный разбор его опыта, технических решений, выгод и рисков, основанный на реальных данных, логах и метриках.

Цель эксперимента — понять: действительно ли панели упрощают жизнь, или они лишь маскируют непонимание того, как работает веб-инфраструктура на самом деле?

Почему панели управления называют «костылём» для настоящего администратора

На первый взгляд, панели — это благо. Но профессионалы часто называют их «чёрным ящиком». Почему?

• Скрытая логика: вы не знаете, какие конфиги меняются при нажатии кнопки «Создать сайт»;
• Ограниченная гибкость: нельзя настроить кастомный Nginx-блок или использовать нестандартный PHP-модуль;
• Зависимость от поставщика: миграция с ISPmanager на другую панель — кошмар;
• Уязвимости: каждая панель — это ещё один вектор атаки (в 2024 году в Plesk была найдена RCE-уязвимость);
• Ресурсоёмкость: панели потребляют 300–800 МБ RAM, которые могли бы пойти на ваш сайт.

В эксперименте участник удалил ISPmanager с VPS на Ubuntu 22.04 и перешёл на полностью ручное управление через терминал и конфигурационные файлы.

Ручная настройка виртуальных хостов в Nginx: от теории к практике

Первый шаг — замена функции «Добавить домен» из панели. Вместо этого администратор создал конфигурационный файл вручную.

Файл /etc/nginx/sites-available/blog.example.com:

server {
    listen 80;
    server_name blog.example.com www.blog.example.com;
    root /var/www/blog;
    index index.php;

    # Защита от прямого доступа к скрытым файлам
    location ~ /\. {
        deny all;
    }

    # Обработка PHP через PHP-FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Кэширование статики
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # Защита от ботов и сканеров
    location = /xmlrpc.php {
        deny all;
    }
}

Активация:

sudo ln -s /etc/nginx/sites-available/blog.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Преимущество такого подхода — полный контроль над каждым параметром. Например, можно добавить заголовки безопасности:

add_header X-Content-Type-Options "nosniff";
add_header X-Frame-Options "SAMEORIGIN";
add_header Referrer-Policy "strict-origin-when-cross-origin";

Управление почтой без Plesk: Postfix + Dovecot + Roundcube

Панели автоматически создают почтовые ящики. Без них — всё делается вручную. Участник эксперимента развёрнул полноценный почтовый сервер за 4 часа.

Шаг 1: Установка Postfix (SMTP-сервер)

sudo apt install postfix postfix-mysql dovecot-core dovecot-imapd dovecot-lmtpd

Во время установки выбран тип «Internet Site».

Шаг 2: Настройка виртуальных доменов и пользователей

Создана база данных mailserver с таблицами virtual_domains, virtual_users, virtual_aliases.

Пример записи в virtual_users:

INSERT INTO virtual_users (domain_id, email, password)
VALUES (1, Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.', ENCRYPT('strong_password'));

Шаг 3: Dovecot (IMAP/POP3)

Настроен для аутентификации через MySQL. Файл /etc/dovecot/conf.d/10-auth.conf:

auth_mechanisms = plain login
!include auth-sql.conf.ext

Шаг 4: Веб-интерфейс — Roundcube

sudo apt install roundcube roundcube-mysql

После настройки доступ к почте — через https://mail.blog.example.com.

Результат: полноценная почта без зависимости от Plesk, но с необходимостью вручную обновлять сертификаты, следить за чёрными списками (Spamhaus) и настраивать SPF/DKIM/DMARC.

Обновление PHP и MySQL без поломки сайтов: стратегия безопасного перехода

На панелях обновление PHP — одна кнопка. Но что, если у вас 5 сайтов на разных версиях? В эксперименте использовалась стратегия параллельной установки нескольких версий PHP.

Установка PHP 8.1 и 8.2 одновременно:

sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install php8.1-fpm php8.2-fpm

Каждый сайт указывает свою версию в Nginx:

# Для старого сайта
fastcgi_pass unix:/run/php/php8.1-fpm.sock;

# Для нового
fastcgi_pass unix:/run/php/php8.2-fpm.sock;

То же самое с MySQL: вместо обновления до MariaDB 11.4, администратор оставил 10.6 для legacy-проектов и запустил 11.4 в отдельном контейнере через Docker — только для новых сервисов.

Это дало максимальную совместимость и исключило риск «всё сломалось после обновления».

Преимущества ручного управления: контроль, безопасность, понимание стека

По итогам 30 дней были зафиксированы следующие преимущества:

• Полный аудит безопасности: каждый конфиг проверен, лишние модули удалены;
• Оптимизация под конкретный проект: например, отключение gzip для API-сервера, где важна скорость CPU;
• Глубокое понимание работы стека: если что-то ломается — вы знаете, где искать;
• Экономия ресурсов: освобождено 650 МБ RAM и 0.2 CPU;
• Автоматизация через скрипты: создание нового сайта — запуск bash-скрипта, а не 10 кликов в панели.

Пример скрипта /opt/create-site.sh:

#!/bin/bash
DOMAIN=$1
USER=webmaster
DOCROOT="/var/www/$DOMAIN"

mkdir -p $DOCROOT
chown $USER:$USER $DOCROOT

cat > /etc/nginx/sites-available/$DOMAIN <

Недостатки и риски: время, человеческий фактор, отсутствие GUI

Однако ручное управление — не для всех. Были выявлены серьёзные недостатки:

• Высокий порог входа: без знания Linux, Nginx, SQL — легко наделать ошибок;
• Временные затраты: настройка почты заняла 4 часа вместо 5 минут в Plesk;
• Риск человеческой ошибки: опечатка в конфиге → сайт недоступен;
• Отсутствие визуального интерфейса: клиент не может сам создать email-ящик;
• Нет встроенной статистики: нужно дополнительно ставить GoAccess или аналоги.

В один из дней участник случайно удалил символ } в конфиге Nginx. Сайт упал на 17 минут, пока не был найден синтаксический error через nginx -t.