Переезд с cPanel на голый сервер: что придётся делать руками

MAATRIX

Панель управления вроде cPanel закрывает десяток рутинных задач одним кликом — вы даже не задумываетесь, что за этим кликом стоит демон, конфиг и cron-задача. Когда вы уходите на голый сервер с одним SSH-доступом, эти задачи никуда не деваются — просто теперь их выполняете вы, руками, и если что-то сломается в три часа ночи, чинить тоже будете вы. Разберём по пунктам, что именно перестаёт делаться «само», и как закрыть каждый пункт без панели.

Виртуальные хосты и домены: конфиги вместо кликов

В cPanel новый сайт — это форма «Add Domain», после которой панель сама создаёт директорию, virtual host и правит DNS-зону. На голом сервере это три отдельных ручных шага для каждого сайта: каталог, конфиг веб-сервера, перезагрузка службы.

Минимальный конфиг для nginx на новый домен:

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

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Дальше — символическая ссылка и проверка синтаксиса:

mkdir -p /var/www/example.com/public_html
ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Если сайтов десять — это десять почти одинаковых файлов, которые легко копировать со скриптом или через шаблон (Ansible, простой bash с sed), но панель за вас это уже не сделает. Отдельная головная боль — PHP-FPM пул на каждый сайт, если нужна изоляция процессов между клиентами: свой www.conf с своим пользователем и сокетом на сайт, а не общий www-data на всех.

SSL-сертификаты: certbot и таймер вместо AutoSSL

AutoSSL в cPanel тихо продлевал Let's Encrypt в фоне, и вы об этом даже не вспоминали. На голом сервере certbot нужно поставить и один раз выпустить сертификат вручную:

apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

Честный нюанс: современный пакет certbot почти всегда сам ставит systemd-таймер (certbot.timer), который дважды в сутки проверяет сертификаты на истечение — отдельный cron в большинстве случаев не нужен, это уже не 2015 год. Проверить, что таймер жив:

systemctl list-timers | grep certbot

Если таймера нет (минимальный образ, контейнер, старый дистрибутив) — тогда действительно нужен cron:

0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Ключевой момент — --deploy-hook: без него сертификат обновится на диске, но nginx не подхватит новый файл, пока его не перезапустят. Это одна из самых частых причин, почему «сертификат вроде обновился, а браузер ругается» — обновление и релоад сервиса это два разных события, и панель раньше связывала их за вас.

Почта: свой Postfix/Dovecot или отказ от почты на этом сервере

Это тот пункт, где честнее всего признать: держать почту на том же сервере, что и сайты — решение с реальной ценой. cPanel давал встроенный почтовый стек с антиспамом, вебмейлом и автоматической репутацией IP. Голый сервер вам этого не даёт вообще ничего — только пустой Postfix, если вы его сами поставите.

Базовая установка:

apt install postfix dovecot-imapd dovecot-pop3d

Дальше — SPF, DKIM, DMARC-записи в DNS, обратная PTR-запись у хостера, настройка TLS для приёма и отправки, борьба с тем, что письма падают в спам у Gmail и Mail.ru. Это не один вечер, это недели донастройки и наблюдения за репутацией IP.

Практичная альтернатива, которую стоит рассмотреть честно: не держать почту на сервере с сайтами вообще, а использовать сторонний почтовый сервис (Yandex 360, Google Workspace, или транзакционный провайдер типа Mailgun/SES для писем «от сайта») и просто прописать MX на него. Для большинства проектов это дешевле по времени, чем самостоятельно поддерживать репутацию IP годами.

Файлы и доступ: SFTP с отдельными пользователями вместо FTP в панели

В cPanel каждый клиент получал FTP-аккаунт из формы за 10 секунд. На голом сервере обычного FTP чаще всего просто нет — вместо него SFTP поверх SSH, и для каждого сайта/клиента стоит завести отдельного системного пользователя без шелла, ограниченного своей директорией:

adduser --home /var/www/example.com --shell /usr/sbin/nologin client_example
mkdir -p /var/www/example.com/public_html
chown root:root /var/www/example.com
chmod 755 /var/www/example.com
chown client_example:client_example /var/www/example.com/public_html

В /etc/ssh/sshd_config добавляется chroot-блок:

Match User client_example
    ChrootDirectory /var/www/example.com
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Грабля, о которую спотыкаются почти все: chroot требует, чтобы сама директория (/var/www/example.com) и все родительские каталоги принадлежали root и не были доступны на запись группе/остальным — иначе sshd откажется стартовать сессию с ошибкой Broken pipe без внятного объяснения в логе клиента. Подробнее о том, как вообще устроено управление пользователями и правами в Linux, если это в новинку — в статье про пользователей и группы.

Если сайтов и клиентов много, эту схему стоит один раз оформить скриптом — вручную повторять пять команд на каждого нового клиента быстро надоедает.

Бэкапы: cron-скрипт вместо кнопки в панели

В cPanel резервная копия — это чекбокс в разделе Backup Wizard. На голом сервере нужно самостоятельно решить, что бэкапить, куда и как часто, и написать это в cron.

Минимальный скрипт для сайта и базы данных:

#!/bin/bash
DATE=$(date +%F)
tar -czf /backups/example.com-$DATE.tar.gz /var/www/example.com
mysqldump example_db | gzip > /backups/example_db-$DATE.sql.gz
find /backups -mtime +14 -delete

И в crontab:

0 2 * * * /usr/local/bin/backup-example.sh >> /var/log/backup-example.log 2>&1

Критично хранить копию не на этом же диске — иначе при отказе сервера или его диска вы теряете и сайт, и бэкап одновременно. Практический план настройки бэкапов с нуля, включая перенос копий на другой сервер, разобран в статье про бэкапы и архив на отдельном VPS.

Мониторинг ресурсов: своя система вместо графиков в панели

cPanel показывал графики CPU, RAM и диска прямо в интерфейсе. На голом сервере, если ничего не поставить, у вас нет вообще никакого визуального контроля — только top и df -h, которые нужно вспомнить запустить руками в момент, когда уже что-то не так.

Быстрый вариант — легковесный агент вроде netdata:

curl -Ss https://get.netdata.cloud/kickstart.sh | sh

Более выносливый вариант для нескольких серверов — связка node_exporter + Prometheus + Grafana, но это уже отдельная служба, которую тоже нужно поддерживать. Важно не просто поставить агента, а настроить хотя бы простейший алерт на нехватку места на диске или на недоступность сервиса — мониторинг, в который никто не смотрит, ничем не лучше его отсутствия, и это одна из самых частых практических ошибок при переезде с панели.

Базы данных: консоль и phpMyAdmin отдельно

phpMyAdmin в cPanel был встроен и доступен из коробки. На голом сервере после установки самого MySQL или MariaDB —

apt install mysql-server
mysql_secure_installation

— веб-интерфейса для баз данных нет вообще. Три реалистичных пути: ставить phpMyAdmin отдельно как ещё один сайт со своим virtual host и своей защитой доступа (Basic Auth поверх него — обязательно, иначе это открытая дверь), использовать более лёгкую альтернативу вроде Adminer (один PHP-файл), либо просто работать через консоль mysql по SSH — для разработчика это часто быстрее, чем кликать в веб-интерфейсе. Разница между этими вариантами и о том, во что легко превратить сервер, если оставить открытым выбор по умолчанию, хорошо видна на общем сравнении подхода в статье про панель против чистого сервера.

Если на сервере несколько сайтов с разными базами, для каждого стоит завести отдельного MySQL-пользователя с правами только на его базу — не общего root-доступа для всех проектов:

CREATE USER 'example_user'@'localhost' IDENTIFIED BY 'сложный_пароль';
GRANT ALL PRIVILEGES ON example_db.* TO 'example_user'@'localhost';
FLUSH PRIVILEGES;

Частые вопросы