Как настроить выделенный сервер

Содержание

Постановка задачи
Гипервизор для своего хостинга
Почтовый сервер и шлюз
Как сбросить пароль root через консоль
Backup сайтов
Как открыть панель управления ISPmanager на выделенном сервере
Открыть панель через личный кабинет на сайте Рег.ру
По URL панели управления
Мониторинг сайтов и серверов
Ставим веб-сервер
Ставим MySQL
Переносим базу
Как подключиться к серверу Dedicated по FTP
Как изменить пароль root по SSH
Подключение к выделенному серверу с Windows по RDP
Через функционал «Подключение к удаленному рабочему столу»
Через меню «Выполнить»
Как узнать IP-адрес Dedicated сервера и его конфигурацию
Второй способ
Выделенный сервер в качестве первичного DNS-сервера
Интерфейс управления первичным сервером имён
Создать свои собственные DNS-серверы на базе домена:
Как подключиться к серверу Dedicated
Как подключиться к серверу Dedicated по SSH
На вашем компьютере установлена ОС Windows
На вашем компьютере установлена Linux-подобная ОС (Ubuntu, Kubuntu, Fedora)
Подключаемся к Bitbucket
Первый способ
Другой регистратор
Хранение логов в ELK Stack
Где можно увидеть доступы к Dedicated (выделенному серверу)
Мониторинг и бэкап
Как добавить домен на выделенный сервер (Dedicated)
Почтовый сервер

Постановка задачи

Ситуация самая жизненная. Интернет-магазин, размещенный на шаред-хостинге, после запуска начал получать клиентов, но появились пожелания к функциональности, и разработчики активно занялись доработкой сайта. Выяснилось, что, когда в этом участвует несколько человек, постоянно копировать файлы через FTP для теста, да и еще на рабочий сайт, очень проблемно. Терялся контроль, кто когда что сделал, нужно было беспокоиться о сохранении оригинальных файлов, чтобы было легко откатиться. Владельцу приходилось или согласовывать правки, или копировать все самому. Разработчик не мог сразу посмотреть результат и ждал. Процесс сильно тормозился. В итоге пришли к тому, что нужно использовать возможности Git и создать новый сайт-зеркало, где можно было бы все обкатывать. При такой схеме разработчик мог сразу тестировать код, а в случае одобрения код переносили в master и выкладывали уже на рабочий сайт. Также можно легко отслеживать коммиты.

Вторая проблема: хостинг постоянно падал. Причину в итоге нашли: Entry processes limit — параметр, который определяет количество CGI/PHP-процессов, входящих внутрь виртуального контейнера, и о котором не сильно любят говорить маркетологи хостера. На графиках его тоже не видно, только маленькая графа в таблице. В итоге при небольших нагрузках CPU и RAM (не более 20%) сервер вообще не работал даже при минимальном количестве посетителей. В итоге было принято решение переезжать.

Гипервизор для своего хостинга

В подавляющем большинстве случаев я использую виртуализацию на базе Proxmox. Выделенный сервер арендую у Selectel
. В зависимости от бюджета и потребностей, это может быть простенький сервер из двух дисков на десктопном железе, либо полноценный сервер с железным рейд контроллером и постоянной ip-kvm панелью.

Если сервер без рейд контроллера, то используется софтовый рейд mdadm. Установка и настройка proxmox
на софтовом рейде у меня подробно описана. У Selectel удобно выполнены базовые шаблоны для установки. Если я заказываю сервер, то сразу выбираю в качестве системы Debian на raid1. Установщик автоматически накатывает систему на mdadm. Остается только установить гипервизор. Самому разбивать диски и собирать mdadm не придется.

В простейшем случае в качестве шлюза используется хостовая система гипервизора. Iptables и Nat настраиваются на ней. Если у вас будут использоваться несколько выделенных серверов и их придется объединять по vpn через интернет, то я настраиваю шлюз в виде отдельной виртуальной машины. Можно и на самом гипервизоре, но я не люблю смешивать функционал. К тому же, когда у вас шлюз в отдельной виртуальной машине, его проще забэкапить и развернуть в другом месте. То есть в целом переезд проекта будет проще и быстрее.

Если у вас только один внешний IP адрес, то на гипервизоре используются 2 сетевых интерфейса:

Реальная сетевая карта с настроенным внешним IP адресом.
Виртуальный бридж, обычно vmbr0 для сети виртуальных машин, а так же для их связи с самим гипервизором.

Если используются несколько IP адресов, которые нужно будет назначать разным виртуальным машинам, то сетевых интерфейса будет 3:

Реальная сетевая карта без настроек IP адреса.
Бридж vmbr1, в который будет включен сетевой интерфейс, в который приходит линк с внешними ip адресами. На этом бридже будет настроен реальный IP адрес самого гипервизора, если нет отдельного шлюза. Этот же бридж будет подключен к тем виртуальным машинам, где нужен внешний ip адрес.
Бридж vmbr0 для виртуальной сети виртуальных машин.

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

С гипервизором разобрались, переходим к следующему элементу web хостинга — frontend серверу.

Почтовый сервер и шлюз

В качестве шлюза так же можно взять либо готовую сборку, к примеру, на базе pfsense
, clearos
или чего-то подобного, либо настроить все самому. Я обычно настраиваю сам, так как не люблю зоопарк из систем. Мне нравится единообразие. Так удобнее управлять инфраструктурой, поэтому все собираю сам. Вот пример настройки шлюза на centos 7
. Статья давно написана, на полностью актуальна. Ничего принципиально не поменялось.

При необходимости на шлюзе настраивается либо openvpn сервер
, либо vpn клиент, если сервер уже есть. Если используется отдельный шлюз, я в него прокидываю реальный ip адрес, убираю его с самого гипервизора и делаю шлюзом по-умолчанию для гипервизора саму виртуалку со шлюзом. Главное не забыть ее поставить в автозагрузку, иначе после ребута гипервизора потеряете к нему доступ.

Если используются несколько дедиков в проекте, не объединенных в локальную сеть в рамках ЦОД, я их объединяю с помощью openvpn через интернет.

Как сбросить пароль root через консоль

В случае если root-пароль окончательно утерян, подключитесь к консоли сервера с помощью KVM
или IPMI
.

Если сервер уже включен, то перезагрузите его, используя комбинацию клавиш на виртуальной клавиатуре Ctrl+Alt+Del
. После загрузки BIOS
появится меню загрузчика GRUB
:

Важно!
Если меню не появилось и началась загрузка ОС, значит в файле /etc/default/grub
установлен параметр GRUB_TIMEOUT=0
, который не позволяет выбрать ОС на этапе загрузки. Чтобы меню GRUB
появилось, перезагрузите сервер и удерживайте Shift
до появления меню.
Чтобы сбросить пароль, нужно загрузиться в ОС в однопользовательском режиме
(single mode). Для этого в меню GRUB нажмите e
;
Параметр ro (read-only)
отвечает за загрузку ядра Linux в режиме «только чтение». Чтобы после сброса root-пароля изменения были сохранены, необходимо заменить ro на rw (read-write)
— режим «чтение-запись».
Далее необходимо указать запуск командной оболочки bash, прописав в конце строки init=/bin/bash
. В итоге строка загрузки, для данного примера, примет следующий вид:
```
   linux   /vmlinuz-4.9.0.-7-amd64 root=/dev/mapper/vg00-root rw nomodeset consoleblank=0 fsck.repair=yes panic=10 apparmor=0 systemd.restore_state=0 init=/bin/bash  
  
```
После этого нажмите Ctrl+X
или F10
и дождитесь загрузки ОС в однопользовательском режиме. После того как загрузка будет завершена, появится командная строка от пользователя root.
Параметр rw необязательно прописывать в строку начальной загрузки. Изменить режим работы в одиночном режиме возможно после загрузки системы, выполнив команду:
Для установки нового root-пароля введите команду passwd
. Введите новый пароль, нажмите Enter
, введите подтверждение пароля, нажмите Enter
;
Сохраните изменения, выполнив команду:
Перезагрузите систему следующей командой:
Важно
: если выполняется сброс root пароля на CentOS, и после смены пароля система не перезагружается обычным способом, выполните следующую команду:

Сброс пароля root могут выполнить наши специалисты в рамках услуги Администрирование сервера
. В случае если у вас отсутствует услуга администрирование сервера, работы по сбросу root пароля могут быть произведены в рамках платного почасового администрирования
.

Backup сайтов

Для бэкапа я предпочитаю арендовать виртуальные машины в ruvds
. К ним можно подключить большие диски — от 500 Гб и больше.

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

Если собираетесь делать бэкапы виртуальных машин, то настраивайте nfs сервер, подключайте его по vpn к гипервизору и настраивайте как отдельное хранилище для бэкапов. Штатным средством proxmox
делайте регулярные бэкапы. В качестве nfs сервера отлично подходят виртуалки ruvds, так как там полноценная операционная система.

На этой же виртуалке ruvds я настраиваю простенький внешний мониторинг Zabbix для удаленным наблюдением за сайтами и физическими серверами по внешним ip адресам.

Так же я настраиваю дублирование бэкапов на s3 подобные хранилища с помощью rclone
. Например, в selectel
. Похожие хранилища есть у mail.ru и yandex.cloud. Облачные сервисы mail.ru я в настоящее время тестирую. Возможно будут статьи по этому поводу.

Я обычно делаю 3 контейнера в s3 с именами day, week, month и настраиваю правила хранения в них:

day — 14 дней
week — 31 день
month — бессрочно

Следить за ротацией не надо, хранилище само удаляет старые архивы. У меня пока открыт вопрос по мониторингу бэкапов в s3 и их автоматическому разворачиванию для проверки. Пока не прорабатывал этот вопрос.

Как открыть панель управления ISPmanager на выделенном сервере

Открыть панель через личный кабинет на сайте Рег.ру

Авторизуйтесь на сайте Рег.ру и перейдите в раздел Мои хостинг и услуги
.
Кликните по названию необходимой услуги выделенного сервера из списка ваших услуг.
В карточке услуги на вкладке «Управление» кликните по пункту:

Если вы открываете панель управления впервые, вы увидите в браузере предупреждение:

Как пройти это предупреждение в Firefox

Нажмите Я понимаю риск
, после чего кликните Добавить исключение
:

В открывшемся окне кликните Подтвердить исключение безопасности
:

Важно!
Самоподписанный бесплатный сертификат обеспечивает такую же защиту передаваемых данных, как и заверенный платный сертификат.

Где взять пароль root

Пароль суперпользователя «root» вы можете увидеть в личном кабинете. Для этого авторизуйтесь на сайте Рег.ру
и перейдите к списку заказанных слуг
. Кликните на названии услуги выделенного сервера и на открывшейся странице перейдите в раздел Доступы
:

Также пароль root указан в стартовом письме, которое приходит на контактный e-mail при заказе услуги:

Если пароль «root» не подходит, его можно восстановить: Управление услугой VPS

По URL панели управления

   https://123.123.123.123/manager
или 
https://123.123.123.123:1500

Мониторинг сайтов и серверов

Для мониторинга виртуальных машин и сервисов нашего хостинга я всегда использую Zabbix
. У меня накопилось огромное количество статей по нему практически на все случаи, с которыми я сталкиваюсь. В общем случае я настраиваю:

Мониторинг mdadm
или железного контроллера. По последним, к сожалению, у меня нет статей, но в целом проблем с настройкой не возникает. У меня всегда гуглились подходящие решения. Если у сервера есть idrac
, ilo, ipmi, можно с них брать нужные данные.
Если есть доступ к смарту дисков, то настраиваю мониторинг smart
. Очень рекомендую это делать, чтобы в случае выхода из строя какого-то диска, у вас была полная информация о нем, чтобы передать ее в службу технической поддержки для замены.
Мониторинг подключений по ssh
. Мне сразу приходит уведомление, если кто-то подключается к серверу по ssh. Если доступ есть не только у меня, то обязательно это настраиваю. Сильно упрощает жизнь и готовит к проблемам 🙂 Если доступ только у меня, то это небольшая защита и возможность быстро среагировать на несанкционированный доступ, хотя в реальности у меня ни разу такого не было.
Мониторинг веб сервера
, в данном случае frontend и backend. Иногда мониторинг бэка не делаю. Реально не так уж часто он нужен, хотя кажется, что полезно получать все метрики. Но лично моя практика такова, что они мне на деле чаще всего не нужны.
Мониторинг сайта
. Это одна из самых главных метрик, так как напрямую отвечает на вопрос, все ли у нас в порядке. Если сайт не работает или не доступен, то это наивысший приоритет проблемы. Так как мониторинг у нас локальный, он не дает полную картину происходящего, нужен еще один внешний. О нем подробнее расскажу далее. Локальный мониторинг сразу определяет, к примеру, если у нас упал backend и вместо страницы сайта видим 500-ю ошибку nginx. Или что-то еще. В общем, важная штука, рекомендую внимательно отнестись к мониторингу сайта. Рекомендую к нему обращаться напрямую через внутреннюю сеть гипервизора по локальному ip фронта. Для этого надо либо в host файл виртуалки с zabbix добавить все сайты по локальному ip, либо завести свой локальный dns сервер. Обычно я это делаю, если используется отдельная виртуальная машина под шлюз.
Мониторинг делегирования домена
и ssl сертификата
. Штука не обязательная, настраивается по желанию. Если делегирование не так критично, так как регистраторы завалят напоминаниями на почту, то мониторинг ssl сертификатов рекомендую сделать. Их часто забывают продлить или возникают технические ошибки при работе с автопродлением Let’s Encrypt.
Я всегда настраиваю мониторинг бэкапов
в том или ином виде. Он сильно зависит от конкретной ситуации, от данных, от места хранения бэкапов и т.д. Готовых решений нет, приходится импровизировать на месте. Но если не настрою мониторинг бэкапов, не могу спать спокойно. Бэкапы периодически разворачиваю вручную и проверяю. Это сильно ограничивает количество клиентов, с которыми могу сотрудничать, так как труд ручной. Но это меня много раз спасало. Так что не пренебрегаю.
Если есть почтовый сервер, настраиваю мониторинг postfix
. За почтовым сервером рекомендую внимательно следить, особенно за очередью и количеством отправленных сообщений. Иногда учетки ящиков утекают в сеть и сервер начинает массово спамить. Если вовремя это не заметить и не остановить, можно залететь в спам листы и надолго там засесть. Это может парализовать работу того же интернет магазина, так как без почты он перестает нормально функционировать.

Читайте также: Программы типа anydesk

Основное по мониторингу перечислил. Частенько настраиваю что-то еще, в зависимости от потребностей конкретного заказчика. Если решение не типовое и нишевое, то статью не пишу по нему, хотя шаблоны себе сохраняю. Если есть какие-то критичные службы linux
, можно мониторить еще и их.

Особенно удобно мониторить отклик сайта с локального сервера. Здесь нет сетевых задержек, которые возникают при работе внешнего мониторинга. Тут чистая производительность web сервера. Вкупе с внешним мониторингом получается полная и легко интерпретируемая картинка производительности веб сервера и скорости доступа к сайту. Только с двумя мониторингами — внешним и внутренним, можно адекватно оценивать и искать узкие места в работе сайта.

Ставим веб-сервер

Несмотря на их разнообразие, выбор установки обычно сводится к трем вариантам: Apache, nginx или nginx как реверс Apache. Apache очень гибок в настройках и использует модули для обработки динамических запросов, поэтому хорошо справляется с динамикой. Nginx хорош в отдаче статики и потребляет меньше ресурсов, но для обработки динамики использует сторонний модуль, что снижает скорость и чуть усложняет настройки. В зависимости от конкретного приложения каждый из них может иметь свои плюсы и минусы и показывать разную скорость. Поэтому окончательный выбор веб-сервера всегда приходится подтверждать практикой, подбирая оптимальный вариант. Проблема nginx — то, что в некоторых специфических движках следует вручную возиться с редиректами, когда на Apache все будет работать буквально из коробки, достаточно просто включить mod_rewrite.

Нагрузочное тестирование можно произвести при помощи ab (Apache Benchmark, входит в apache2-utils) или siege. Причем лучше проверить с localhost и удаленного узла, чтобы видеть, как работает сеть.

   # ab -c 10 -n 6000 http://example.org/

Хотя ab — это скорее для себя, чтобы оценить эффективность установок. Человека со стороны обычно интересует только то, что показывает Google PageSpeed
, поэтому ориентироваться следует и на него.

В последнем случае сайт на старом хостинге давал 60, после переноса на VDS (с такими же параметрами) он в Apache в установке по умолчанию показывал 72, nginx с голым конфигом — 62, после добавления сжатия — 78. На этом и остановились, выбрали nginx. В репозитории несколько пакетов, для большинства ситуаций достаточно базового core, содержащего все основные модули, для PHP нам понадобится FPM.

   # apt nginx install nginx php7.0-fpm

   # nano /etc/nginx/nginx.conf
http {
    ....
    open_file_cache max=200000 inactive=60s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    server_tokens off;
    server_names_hash_bucket_size 64;
    reset_timedout_connection on;
    client_body_timeout 10;

    gzip on;
    gzip_disable "msie6";
    gzip_static on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js;
}

Создаем настройки для домена:

   # nano /etc/nginx/sites-available/example.org
server {
    listen 80;
    server_name example.org default;

    root /var/www/example.org;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    rewrite_log on; # Полезная настройка для отладки
    index index.php;

    try_files $uri $uri/ /index.php?$query_string;

    location ~ \.php$ {
        include /etc/nginx/fastcgi_params;
        # fastcgi_pass 127.0.0.1:9000;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }

    # Кешируем картинки и txt/XML/JS/CSS. Можно убрать ненужное или что-то добавить
    location ~* ^.+\.(jpg|jpeg|gif|png|js|css|txt|xml)$ {
        access_log off;
        expires 30d;
    }

    # Блокируем доступ к каталогу .git (о нем дальше), по аналогии добавляем свои правила
    location ~ /\.git {
        deny all;
    }

}

Это общий пример для стандартного движка. Некоторые движки вроде OpenCart или WebAsyst требуют специфических настроек, и даже не всегда работает то, что предлагается в Сети.

Проверяем, работает ли сжатие. Это можно сделать, просмотрев заголовок Content-Encoding в Firebug (он должен показывать gzip), или при помощи специального сервиса
.

   # ln -s /etc/nginx/sites-available/example.org /etc/nginx/sites-enabled/example.org

   # service nginx restart

Но работать еще не будет. Нужно настроить PHP. Для FPM все установки находятся в /etc/php/7.0/fpm. Проверяем, что в pool.d/www.conf учетная запись совпадает с используемой nginx и включен сокет.

   # nano /etc/php/7.0/fpm/pool.d/www.conf
user = www-data
group = www-data
listen = /run/php/php7.0-fpm.sock

Кроме этого, можно обратить внимание на параметры, определяющие количество процессов, которые будут обслуживать PHP-запросы.

   pm = dynamic
pm.max_children = 15
pm.start_servers = 6
pm.min_spare_servers = 2
pm.max_spare_servers = 6

На чуть загруженных серверах может не хватать количества процессов. В логах об этом сразу скажут.

# cat /var/log/php7.0-fpm.log WARNING: [pool www] server reached pm.max_children setting

, consider raising it

Еще важный файл php.ini. Параметров там много, и можно рассказывать долго. Но изначально следует включить сжатие, установить максимальный размер файла на аплоад, подключить mail(), сессии и очень желательно включить акселератор OPcache.

   # nano /etc/php/7.0/fpm/php.ini
zlib.output_compression = On
upload_max_filesize = 2M

[mail function]
sendmail_path = sendmail -t -i

[Session]
session.save_path = "/var/lib/php/sessions"
[opcache]
opcache.enable=1
opcache.memory_consumption=128
pcache.max_accelerated_files=2000

Обязательно проверяем права доступа на /var/lib/php/sessions, чтобы туда мог писать nginx, иначе сессии не будут образовываться. Перезапускаем.

   # service php7.0-fpm restart

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

   # tar -zcvf backup.tar.gz /var/www

И на новом месте распаковываем:

   # tar -zxvf backup.tar.gz /var/www

Но для сайта нам нужна СУБД.

Проверяем сжатие отдаваемых веб-сервером данных

Ставим MySQL

C MySQL все очень просто. Вводим

   # apt install mysql-server

На запрос указываем пароль root, и уже можно работать. Если не требуется доступ к нему извне, то следует разрешить использовать только локалхост или сокет.

   # nano /etc/mysql/my.cnf
socket    = /var/run/mysqld/mysqld.sock
skip-networking
# bind-address        = 127.0.0.1

После изменений перезапускаем:

   # service mysql restart

Остальные параметры обычно настроены оптимально для большинства ненагруженных узлов. В процессе работы следует смотреть за журналами и значениями текущих переменных.

   # mysqladmin -uroot -p extended-status

Вероятно, что-то придется подкрутить. Для быстрой оптимизации лучше воспользоваться советами, выдаваемыми скриптом MySQLTuner, который есть в репозитории.

Скрипт MySQLTuner позволяет оптимизировать MySQL

Переносим базу

   # mysqldump -uroot -p workbase > base.sql

   # mysql -uroot -p
mysql> CREATE DATABASE workbase;
mysql> use workbase;
mysql> source base.sql;
mysql> GRANT ALL PRIVILEGES ON workbase.* to 'baseadmin'@'localhost' IDENTIFIED BY 'password';

Заодно добавим учетку с меньшими правами для бэкапа.

   mysql> GRANT SELECT, LOCK TABLES ON *.* to 'backup'@'localhost' IDENTIFIED BY 'backup_pass';
mysql> FLUSH PRIVILEGES;

Настраиваем подключение к БД в параметрах движка, и можно работать.

Как подключиться к серверу Dedicated по FTP

Данная инструкция предназначена для серверов Dedicated с установленной панелью управления ISPmanager.

Перейдите в раздел FTP-пользователи
и нажмите кнопку Создать FTP-пользователя
:

создать пользователя ftp 1
В появившемся окне заполните поля и нажмите OK
:
- Имя
  ― логин нового FTP-пользователя на латинице,
- Пароль
  ― пароль нового пользователя,
- Подтверждение
  ― контрольное подтверждение пароля.

Инструкция по настройке FileZilla

Запустите клиент и перейдите в меню Файл
— Менеджер Сайтов
или нажмите сочетание клавиш «CTRL»+«S»
:
Нажмите Новый сайт
и заполните поля:

настройка filezilla шаг 2
- Хост
  ― IP-адрес вашего сервера,
- Порт
  ― порт можно не указывать или указать стандартный порт протокола FTP — 21,
- Тип входа
  ― нормальный,
- Пользователь
  ― логин созданного вами пользователя,
- Пароль
  ― пароль созданного пользователя.
Перейдите во вкладку Настройки передачи
и заполните поля:
- Режим передачи
  ― Пассивный,
- установите галочку Ограничение одновременных подключений
  и укажите значение 8 в поле Макс. число подключений
  .

Инструкция по настройке Total Commander

Запустите клиент и перейдите в меню Сеть
— Соединиться с FTP сервером
или нажмите сочетание клавиш CTRL+F:
Нажмите кнопку Добавить
:
- Имя соединения
  ― произвольное название нового подключения,
- Сервер[:Порт]
  ― IP-адреса вашего сервера. Порт можно не указывать или указать стандартный порт протокола FTP — 21 (указывается через символ «:», например 123.123.123.123:21),
- Учетная запись
  ― логин созданного вами пользователя,
- Пароль
  ― пароль созданного пользователя.
  Установите галочку Пассивный режим обмена
  и нажмите ОК
  :
Выберите в списке созданное вами подключение и нажмите Соединиться
:

В случае если вы помните актуальный пароль пользователя root, для сброса пароля используйте команду passwd
.

Как изменить пароль root по SSH

Подключитесь к серверу по SSH
;
Введите новый пароль, нажмите Enter
, введите подтверждение пароля, нажмите Enter
.

Подключение к выделенному серверу с Windows по RDP

Через функционал «Подключение к удаленному рабочему столу»

Терминальный клиент Remote Desktop Connection
(подключение к удаленному рабочему столу RDP) — популярное средство администрирования серверов на базе ОС Windows.

Нажмите Пуск
, перейдите в папку Стандартные — Windows
и выберите Подключение к удаленному рабочему столу
:

Где взять пароль администратора

Пароль администратора для подключения к удаленному рабочему столу по RDP вы можете увидеть в информационном письме, отправленном вам на почту сразу после активации услуги сервера. Также данная информация продублирована в личном кабинете Рег.ру: Информация о включенных сервисах и паролях доступа для Dedicated
.

Через меню «Выполнить»

Готово, вы осуществили подключение к удаленному рабочему столу по RDP.

Как узнать IP-адрес Dedicated сервера и его конфигурацию

Перейдите к списку услуг
и кликните по имени Dedicated-сервера:
В карточке услуги на вкладке «Управление» перейдите на вкладку Доступы
:

Также информация об IP указана в стартовом письме, которое приходит на контактный email при заказе услуги:

Второй способ

Вы можете воспользоваться бесплатной поддержкой DNS, входящей в стандартный пакет услуг «Reg. Dedicated». Для этого вам предоставляется удобный интерфейс для управления зоной на базе ISPmanager и DNSmanager. При пользовании данной услугой у вашего регистратора для домена в качестве DNS-серверов необходимо прописывать: ns5.hosting.reg.ru
и ns6.hosting.reg.ru
.

Если вместе с услугой «Аренда сервера» вы заказали панель управления ISPmanager

Зайдите в вашу панель управления ISPmanager с правами администратора.
В левом меню перейдите в раздел Доменные имена
или Управление DNS
.

ns5.hosting.reg.ru.

В поле «URL панели управления» введите

В поле «Пароль» введите ваш пароль для доступа к DNS (не следует путать его с паролем пользователя root).

https://ns5.hosting.reg.ru/manager/dnsmgr

Повторите операцию добавления вторичного сервера имён для адреса

% 10
В левом меню перейдите в раздел
Доменные имена

или

Управление DNS

и нажмите на

Настройки по умолчанию

https://ns6.hosting.reg.ru/manager/dnsmgr
В поле «Серверы имён» введите
и ns6.hosting.reg.ru.
.
Поставьте галочку «Применить к существующим».

Теперь при создании домена в панели управления вашим сервером домен будет автоматически создан на вторичных серверах ns5.hosting.reg.ru
и ns6.hosting.reg.ru
, которые вы сможете прописать как DNS-сервера для данного домена у вашего регистратора.

Выделенный сервер в качестве первичного DNS-сервера

Если вы не заказывали панель управления ISPmanager и хотите, чтобы ваш выделенный сервер выступал в качестве первичного DNS-сервера, для вас предусмотрен интерфейс управления вторичными серверами имён:

Перейдите в раздел «Доменные имена».
Нажмите на Создать новый домен
.
В поле «Имя домена» введите имя добавляемого вами домена.
Повторите операцию добавления домена на втором сервере ( https://ns6.hosting.reg.ru/manager/dnsmgr
).

Интерфейс управления первичным сервером имён

Если вы не хотите, чтобы ваш выделенный сервер выступал в качестве первичного DNS-сервера, для вас предусмотрен интерфейс управления первичным сервером имен:

Перейдите в раздел «Доменные имена».
Нажмите на Создать новый домен
.
В поле «Доменное имя» введите имя добавляемого вами домена.

Создать свои собственные DNS-серверы на базе домена:

а) необходимо иметь основной IP вашего выделенного сервера и дополнительный, полученный при подключении услуги «Дополнительный IP адрес на ваш выбор»;

b) необходимо настроить свои DNS-серверы в ISPManager:

Зайдите в вашу панель управления ISPmanager с правами администратора.
Откройте раздел Управление DNS
или Доменные имена
и нажмите Настройки по умолчанию
:
В поле «Серверы имён» укажите два DNS-сервера:

ns1.yourdomain.ru.
, ns2.yourdomain.ru.
:

Управление хостингом

Самый главный вопрос при создании своего хостинга — как им управлять. Именно этот вопрос решают все готовые панели, но при этом добавляют массу новых проблем. В общем случае я не рекомендую использовать панели управления хостингом. Сам их терпеть не могу, так как намучался с ними. Там вечно какие-то проблемы, если тебе надо хоть немного кастомизировать настройки. А уж как они умирают при обновлении. Сколько я этих проблем повидал.

Сейчас просто не работаю с панелями вообще. Если кто-то предлагает взять на поддержку сервер с панелью управления хостингом (ispmanager, plex, vestacp), сразу отказываюсь. Я не могу гарантировать стабильную работу сайтов на них.

Раньше я писал bash скрипты для быстрого добавления сайта или настройки системы. Когда сайтов не много, создавал их руками. Сейчас я все стараюсь делать с помощью ansible
. В паблик пока не готов выдать свои наработки. Их оформить отдельный труд. Нужно для начала хотя бы обзорную статью про ansible написать. Черновик уже год как написан, но не хватает времени оформить в полноценную статью.
Перечислю основные моменты, которые нужно автоматизировать:
При добавлении виртуальной машины базовые настройки системы
, подключение к мониторингу.
При создании сайта — создание конфига nginx на фронте и бэке, запрос на сертификат, создание директорий и системного пользователя для сайта, создание php-fpm пула, настройка ротации логов, создание базы данных и пользователя, доступ пользователя по sftp.
Поправить скрипт создания бэкапов. Создаю их bash скриптом. Есть мысли тоже через ansible делать, но пока не прорабатывал тему.
Добавление мониторинга сайта в Zabbix. Пока не реализовал. Надо делать через api заббикса. Руки не дошли. С автоматизацией веб проверок в заббиксе пока все плохо.
Это основное. Может что-то забыл. Первое время все делал топорно единой yaml лапшой файла плейбука. Последнее время все переделываю с использованием шаблонов, ролей, задач, хендлеров, инвентаря и т.д. Стараюсь использовать ansible правильно.
В чем большое преимущество подобной автоматизации, помимо того, что можно быстро создать сущности на большом количестве объектов, когда у тебя этих объектов мало? В том, что настроив и проверив один раз какую-то процедуру, ее можно смело запускать без боязни где-то ошибиться. Она всегда отработает так, как ее настроили.
Например, при настройке firewall я всегда опасаюсь применять изменения в правилах. Вдруг где-то ошибся и что-то пойдет не так. Отрубится какой-то сервис или еще хуже — потеряю доступ к серверу. А когда у тебя есть шаблон и готовый плейбук по добавлению правил или заливки готового набора правил из шаблона, тебе достаточно проверить только переменные, чтобы в них не было ошибок. Далее прогнать на всякий случай плейбук в режиме check
, а потом применить, если все в порядке.
В такой последовательности меньше шансов получить ошибку. Это облегчает управление даже тогда, когда автоматизация не дает существенной прибавки к производительности из-за малого масштаба информационной системы. Зачастую, настройка и отладка плейбуков занимает больше времени, чем ручная работа. Но это дает задел на будущий рост и опыт. Даже если роста не будет в этом проекте, наработки пригодятся в другом.
Плейбуки храню в git. Приучил себя вообще все хранить в git. Первое время было не привычно и казалось, что не удобно. Но в итоге привык и оценил удобство репозиториев.

Как подключиться к серверу Dedicated
Если на вашем Dedicated сервере
установлена операционная система семейства Linux (Centos, Debian, Ubuntu)
, воспользуйтесь одним из способов подключения, указанным ниже:
Если на вашем Dedicated сервере установлена ОС семейства Windows
, подключение к выделенному серверу происходит через терминальный клиент RDP
.
Как подключиться к серверу Dedicated по SSH
В зависимости от операционной системы, которая установлена на вашем домашнем компьютере (не путайте с ОС сервера), выполните следующие действия:
На вашем компьютере установлена ОС Windows
Для подключения по протоколу SSH выполните следующие действия:
Запустите ssh-клиент PuTTY.

На следующей строке введите ваш пароль и нажмите Enter
.
Важно!
В целях безопасности вводимый пароль не отображается на экране в виде символов.
На вашем компьютере установлена Linux-подобная ОС (Ubuntu, Kubuntu, Fedora)
Чтобы подключиться по SSH, используйте терминал, доступный в операционной системе:
В Unity ( Ubuntu
): «Главное меню» — в поисковой строке введите слово «Терминал». Либо просто нажмите комбинацию клавиш: Ctrl+Alt+T
,
В Xfce ( Xubuntu
): Главное меню — Приложения — Система — Терминал,
В KDE ( Kubuntu
): Главное меню — Приложения — Система — Терминал,
Нажмите Enter
и введите пароль root.
Подключаемся к Bitbucket
Вся изюминка переноса состояла в использовании при разработке веб-сайта Git. Выглядело интересно, осталось только это все реализовать. Здесь можно пойти несколькими путями. Самый, наверное, простой — инициализировать локальный репозиторий и позволить разработчику при коммите выкладывать файлы прямо на сервер. Минус здесь — мы фактически даем ему доступ на сервер. Поэтому лучше перестраховаться, и самым правильным вариантом будет использовать посредника с возможностью автоматического pull файлов после коммита. Так мы получаем еще один источник бэкапа. В качестве промежуточного сервиса был выбран сервис «ведро битов» Bitbucket
, предлагающий всякие вкусности вроде бесплатных «private»-репозиториев и удобного интерфейса. Хотя, в принципе, это может быть любой другой подобный сервис — GitHub или Google Cloud Source Repositories.
Механизм взаимодействия будет простым. Создаем репозиторий (можно в отдельной теме), инициализируем Git прямо в корне сайта (как вариант, можно переносить с другого каталога, но это не так интересно), добавляем удаленный репозиторий Bitbucket и подключаем сервер к аккаунту Bitbucket. Чтобы коммит на Bitbucket сразу попадал на веб-сайт, будем использовать механизм хуков. Сам Git предоставляет такую возможность, а в Bitbucket есть даже два варианта.
Для пула можно использовать протокол HTTPS или Git — ставить эту схему в уже рабочий сайт или разворачивать с нуля. В случае HTTPS меньше настроек, просто после инициализации подключаем удаленный репозиторий и в последующем тянем из него изменения.
# git init # git clone https://аккаунт@bitbucket.org/тема/репозиторий.git .
Но если придется экстренно вносить правки в файлы вручную, то возможен конфликт при будущих pull. Если же используем SSH, то настроек чуть больше, но зато, поправив файл, можем сразу сделать commit, избежав возможных проблем.
# git commit -a -m "wp-config correction"
Для подключения через Git/SSH нужно на Bitbucket загрузить публичный ключ. Генерируем:
# ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
В качестве имени вводим bitbucket, чтобы не путаться. На запрос пароля жмем ввод. Меняем сразу права, иначе будет ругаться.
# chmod 0600 ~/.ssh/bitbucket
Проверяем, работает ли ssh-agent:
# eval "$(ssh-agent -s)" Agent pid 7782
# ssh-add ~/.ssh/bitbucket Enter passphrase for /root/.ssh/bitbucket: # ssh-add -l
Смотрим, чтобы в ~/.ssh/config была информация для идентификации хоста Bitbucket:
Host bitbucket.org IdentityFile ~/.ssh/bitbucket
# git clone git@bitbucket.org:аккаунт/тема/репозиторий.git
Это вариант самый беспроблемный, так как сайт фактически ставим с нуля и не будет конфликтов между локальными файлами и теми, что уже есть в репозитории. В других случаях следует инициализировать репозиторий и добавить удаленный.
# git init # git remote add origin git@bitbucket.org:аккаунт/тема/репозиторий.git
После чего тянуть изменения git pull origin master. Главная проблема в том, что Git не хочет инициализировать репозиторий в каталоге, в котором уже есть файлы. Выкрутиться можно несколькими способами. Самый простой — проделать это все в отдельном каталоге, а затем скопировать в рабочий и проверить работу git pull. Но файлы в Git и локальные не должны различаться, иначе придется использовать git checkout, который набросает лишние строки в файле, в результате можем получить нерабочий сайт. Причем нет необходимости переносить весь сайт, достаточно перенести только каталог .git.
Не забываем про права доступа. Так как имя начинается с точки, то шаблон * не сработает, нужно указать явно.
# chown -R www-data:www-data /var/www/site/.*
Для большего контроля следует в .gitignore
внести все файлы, которых не должны касаться изменения. Например, для WP это могут быть основные файлы и каталоги.

Проверяем работу с Bitbucket вручную
wp-config.php wp-includes/ wp-admin/ wp-content/uploads/
Теперь разработчик может выкладывать код в Bitbucket, а мы забирать на сайт. Осталось только автоматизировать процесс. В Git это позволяет система хуков — фактически скриптов, выполняющихся в зависимости от наступления определенного события. Реализованы хуки и в Bitbucket. Причем доступно сразу два варианта: веб-хук (Webhooks) и службы. В логах они выглядят так:
"POST /post.php HTTP/1.0" 200 236 "-" "Bitbucket-Webhooks/2.0" "POST /post.php HTTP/1.0" 200 703 "-" "Bitbucket.org"
Настраиваются они через API или веб-интерфейс (меню «Настройки»). На проект можно создать несколько хуков. Для настройки веб-хука нужно указать URL и событие (всего 21 событие). В Webhooks на указанный в установках URL отправляется POST-запрос с данными в JSON-формате (в интерфейсе есть возможность просмотра View requests), при необходимости можно их отобрать и обработать запрос в зависимости от параметров.

Добавляем Webhooks в настройках Bitbucket
Нам для нашей схемы достаточно, чтобы Bitbucket при пуше (repo:push) просто «дернул» URL в веб-хуке, а мы по этому событию вытянем коммит из репозитория. Создаем простой скрипт:
# nano bitbucket.php <?php shell_exec("/usr/bin/git pull origin master 2>&1"); ?>
В целях безопасности можно его назвать как-нибудь случайно типа 12ghrt78.php и ограничить доступ к скрипту из сетей Bitbucket: 131.103.20.160/27, 165.254.145.0/26, 104.192.143.0/24. Хотя иногда приходится его вызывать из браузера. Указываем файл в настройках веб-хука на событие Repository push. Теперь при пуше разработчиком веб-сервер вытянет коммит из Bitbucket. В зависимости от настройки хостинга может не хватить прав доступа. В этом случае ничего не остается, как разрешить выполнять команду через sudo:
shell_exec("sudo /usr/bin/git pull origin master 2>&1");
Набираем команду visudo и в /etc/sudoers записываем:
www-data ALL=(root) NOPASSWD:/usr/bin/git
Теперь должно работать.
Первый способ
Если домен находится на обслуживании в компании REG. RU, вы можете воспользоваться бесплатными DNS-серверами: ns1.reg.ru
и ns2.reg.ru
:
Авторизуйтесь на сайте REG. RU, перейдите в раздел «Мои домены и услуги»
и кликните на имя домена.
В блоке «Управление» выберите пункт DNS-серверы и управление зоной
.
Другой регистратор
Хранение логов в ELK Stack
Я складываю все логи в elasticsearch. У меня есть статья про установку и настройку ELK Stack
. Недавно я обновил инструкцию по установке, но скрины оставил старые. Очень хлопотно их заменять. Сам процесс установки отражен правильно, так как я регулярно пользуюсь своей статьей. У меня есть несколько примеров
того, как можно анализировать логи различных сервисов.
В контексте данной статьи по настройке приватного хостинга нас будет интересовать сбор web логов и их анализ:
Статьи немного устарели в том плане, что в процессе эксплуатации мои дашборды изменились, но принцип тот же. Главное его понять, а дальше уже не будет проблем делать так, как удобно лично вам. Например, я не настраиваю GEO карты. В реальности они мне не нужны. Так, для красоты только. Ниже пример моего актуального дашборда для этого сайта.

По дашборду я сразу получаю актуальную информацию о состоянии сайта — информация о средней скорости ответа на php запросы и карта распределения ответов по шкале. Почти все запросы укладываются в интервалы до 300 мс, что считаю хорошим результатом. Напоминаю, что это информация только о php запросах. На сайте настроено кэширование, так что большинство страниц уходят к посетителю значительно быстрее напрямую через nginx, минуя обработчик php.
Тут же можно сделать выборку по медленным запросам, по запросам с определенных ip адресов, посмотреть запросы с различными кодами ошибок и т. д. В общем, без такого дашборда я ощущаю себя слепым. Я не понимаю, как понять, что с сайтом все в порядке, или наоборот узнать, какие у него проблемы, если у тебя нет под рукой подобной информации. Сайт может начать сыпать пятисотыми ошибками, а тебе надо как-то вручную грепать access log и пытаться понять, проблема единичная или масштабная. А тут все под рукой.
Я так привык в ELK, что на сервера почти не хожу. Все логи собираю в нем (обязательно системные) и там же просматриваю. Плюс к этому мониторинг и управление через ansible, но об этом позже. Ходить на сервера по ssh практически нет необходимости.
Такой подход очень хорошо масштабируется, поэтому я его и использую, хотя на моих масштабах это и не так актуально, но тем не менее, хочется все делать правильно с заделом на будущее. У меня был проект, который начался с одного сервера и нескольких докер контейнеров, а закончился примерно сотней виртуалок. Я очень пожалел, что с самого начала не начал автоматизировать процессы. Просто не был готов к этому. Не было опыта и понимания. Все росло постепенно и каждый раз вручную сделать было быстрее. Но в какой-то момент я стал просто зашиваться. Повезло, что проект в итоге усох, но не по моей вине 🙂
На фронте у меня логи всех сайтов складываются в одну директорию /var/log/nginx
и оттуда единым шаблоном уходят в filebeat, а с него в logstash и далее в elasticsearch в один общий индекс, который бьется по дням. Раньше я каждый сайт отправлял в отдельный индекс, но со временем понял, что это не удобно. Так приходится для каждого индекса создавать свои визуализации и дашборды. Когда сайтов много это хлопотно, хотя и можно автоматизировать, но большого смысла нет на моих масштабах.
Сейчас я собираю все в один индекс, делаю единый dashboard и в нем уже с помощью фильтров просматриваю данные по разным сайтам. Я вывел в лог nginx информацию об имени виртуального домена. Это удобно и быстро настраивается. Для каждого нового сайта не надо вообще ничего делать. Filebeat автоматом забирает его логи. С помощью фильтра в Kibana просматривается информация в логах.
Где можно увидеть доступы к Dedicated (выделенному серверу)
Как зайти на выделенный сервер описано в инструкции ниже:
Авторизуйтесь на сайте Рег.ру и перейдите к списку услуг
. Кликните по названию нужного выделенного сервера:

В карточке услуги на вкладке «Управление» перейдите на вкладку Доступы
:

Перейдя по ссылке, вы увидите всю необходимую информацию о паролях и доступах к услуге.

Мониторинг и бэкап
Две важные вещи — мониторинг и бэкап. После установки сайт может падать из-за неоптимальных настроек. Поэтому лучше сразу установить хотя бы простое решение, позволяющее перезапускать сервисы. В репозиториях есть отличные утилиты healt-check или monit, проверяющие не только сервисы, но и общее состояние системы. Настроек там много, и на первых порах или на легких сайтах можно обойтись простеньким скриптом. Для nginx он будет выглядеть примерно так:
# nano monitor.sh #!/bin/bash RESTART="/etc/init.d/nginx restart" PGREP="/usr/bin/pgrep" HTTPD="nginx" $PGREP ${HTTPD} if [ $? -ne 0 ]; then $RESTART fi
По аналогии можно добавить контроль MySQL, PHP-FPM и SMTP-сервера.
Решений для бэкапа в репозитории больше чем достаточно, в зависимости от ситуации и наличия ресурсов можно подобрать себе любой по вкусу. В самом простом случае можно использовать самописный скрипт, который будет собирать папки /etc, веб-серверы и SQL-базы и отправлять их на FTP. Файлы будем хранить неделю. Чтобы файлы удалялись автоматически, в имени будем использовать остаток от деления, тогда новый файл с таким же именем будет перезатираться. В нашем примере будем делить на 7.
# nano backup.sh #!/bin/sh # Данные FTP FTPD="/" FTPU="user" FTPP="password" FTPS="ftp.server.name" # Системные файлы и каталог для архивов BACKUP=/var/archives TAR="/bin/tar" GZIP="/bin/gzip" FTP="/usr/bin/ftp" # Переменные MySQL MUSER="backup" MPASS="backup_pass" MHOST="localhost" MYSQLDUMP="/usr/bin/mysqldump" SQLFILE=$BACKUP/$DOY/sql.$DOY.sql.gz # Чистим старые файлы [ ! -d $BACKUP ] && mkdir -p $BACKUP || /bin/rm -f $BACKUP # Создаем каталог DOY1=`date +%j` DOY=`expr $DOY1 % 7` mkdir $BACKUP/$DOY # Собираем архивы /etc, сайтов и SQL $TAR -cf $BACKUP/$DOY/etc.tar /etc $TAR -cf $BACKUP/$DOY/www.tar /var/www/ $MYSQLDUMP -u $MUSER -h $MHOST -p$MPASS --all-databases | $GZIP -9 > $SQLFILE # Создаем единый архив ARCHIVE=$BACKUP/backup-$DOY.tar.gz ARCHIVED=$BACKUP/$DOY $TAR -zcvf $ARCHIVE $ARCHIVED # Отправляем на FTP cd $BACKUP DUMPFILE=backup-$DOY.tar.gz $FTP -in $FTPS <<END_SCRIPT quote user $FTPU quote pass $FTPP cd $FTPD mput $DUMPFILE bye END_SCRIPT # Убираем временные файлы и оставляем последнюю копию на локальном сервере rm -rf $ARCHIVED rm -rf backup-last.gz mv $DUMPFILE backup-last.gz exit
Прогоняем первый раз оба файла вручную, чтобы убедиться в их работоспособности. И добавляем задачи в /etc/crontab. Мониторить будем каждые десять минут, резервную копию будем создавать ежедневно в 20:00.
*/10 * * * * root /bin/sh /root/dbmonitor.sh 2>&1 /var/log/monitor.log 00 20 * * * root /bin/sh /root/backup.sh 2>&1 /var/log/backup.log
# service cron restart
На данный момент мы имеем полностью настроенный веб-сервер.
Как добавить домен на выделенный сервер (Dedicated)
Управление зоной домена происходит на DNS-серверах, указанных для него. Вы можете посмотреть DNS-серверы вашего домена, воспользовавшись инструкцией Как узнать, какие DNS-серверы прописаны для домена
.
Если для вашего домена указаны и , управление зоной происходит на странице домена в Личном кабинете. Посмотрите инструкцию: Настройка ресурсных записей DNS для домена
;
Если для вашего домена указаны и , управление зоной домена на Dedicated сервере происходит или в панели управления ISPmanager, или в панели DNSadmin.

Если домен был добавлен в панели управления ISPmanager
В этом случае управление зоной домена происходит в ISPmanager: откройте панель управления
— и перейдите в раздел Управление DNS
или Доменные имена
. Выберите домен и нажмите кнопку Управлять DNS записями
. Там вы сможете создавать, редактировать и удалять ресурсные записи для домена:
Управление ресурсными записями происходит в разделе Доменные имена
— Записи
:

Если домен был добавлен в панели DNSmanager
Это два сервера: https://ns5.hosting.reg.ru
и https://ns6.hosting.reg.ru
. Через них управлять зоной можно только в том случае, если домен был добавлен как «master»
(Dedicated выступает в качестве вторичного DNS):
Если кликнуть на Записи
, вы попадёте на страницу редактирования записей домена:
Если же домен был добавлен как «slave»
, то это означает, что Dedicated выступает в качестве первичного DNS, и редактировать зону необходимо непосредственно на нём.

Вы не помните, как привязывали домен к Dedicated
Если вы не помните, где именно добавляли домен, то просто проверьте поочерёдно:
Почтовый сервер
Хотя некоторые приложения могут напрямую подключаться к внешнему SMTP (что очень даже хорошо: в случае взлома провайдер не забанит аккаунт из-за рассылки спама), но в большинстве приложений для отправки почты используют функцию mail()
, а поэтому нам потребуется локальный SMTP-сервер. Здесь опять два варианта: настроить полноценный сервер или установить прокси, который будет подменять SMTP, переправляя запросы на внешний сервер (потребуется почтовый ящик). В качестве последнего отлично подходит ssmtp, который есть в репозитории. Хотя установить «большой» сервер в минимальной конфигурации — дело пяти минут.
# apt install postfix
В процессе выбираем «Интернет-сайт» и указываем домен.
# nano /etc/postfix/main.cf myhostname = example.org mydestination = $myhostname, localhost.localdomain, localhost # Чтобы подключались только с локальных адресов mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
# service postfix restart
И почта должна уже работать. Единственный момент — если почтовый ящик домена привязан к Gmail, то, когда в него идет письмо с этого же домена, технология DMARC Gmail может его отбросить как спам. Хотя если отправитель будет другой, то все будет работать. В этом случае следует убедиться, что SMTP-сервер не отправляет hostname, которое дал серверу хостер. Строку mydestination следует изменить на
mydestination = $mydomain, localhost.$mydomain, localhost

Настройки Postfix во время установки