Давным-давно в нашей хостинг-панели Parallels Plesk Panel мы сделали такую интересную фишечку: если вводился адрес панели с указанием порта (8443), но без указания шифрования (https), то Plesk перенаправлял пользователя на адрес
https://<server_hostname>:8443
. Это было удобно. Кто-то к этому поведению привык. А кто-то — даже учел в своих процессах. В версии 11.5 мы заменили веб-сервер, обслуживающий сам Plesk, c lighttpd на nginx. И нечаянно сломали ту самую маленькую фишечку. Просто не смогли придумать, зачем бы она была нужна, и с новым веб-сервером ее не реализовали. Пользователям, обращавшимся по адресу http://<domain>:8443
, стала показываться ошибка 400 — «Bad request».
Наши пользователи тут же напомнили нам, написав отзыв на forum.parallels.com (а мы читаем наш форум, да), — что ломать хорошие фичи и не давать ничего взамен — это плохо. Простите нас 🙂 Вы скоро сможете увидеть в превью Parallels Plesk Panel 12.x, что мы ее вернули.
Зачем мы все это рассказываем? Хотим поделиться одним интересным use-case от наших пользователей, опубликованном на форуме Parallels и дополнить его.
Итак, допустим, хостнейм вашего сервера — panel.provider.com
, и вы установили валидный SSL-сертификат для защиты Plesk. Теперь вы можете сказать своим клиентам: "Чтобы попасть в панель управления хостингом, вам нужно просто дописать :8443 к имени вашего домена. Например, example.com:8443"
. Далее «автомагически» клиента перенаправляют с http://example.com:8443
на httpS://panel.provider.com:8443
, что избавляет клиента от просмотра ужасной и страшной ошибки про SSL-сертификат, выданный не для его домена, о попытке украсть его данные и прочие страшилки от браузеров. Ваш клиент видит «зеленую» адресную строку в браузере, не видит ошибок — и доверие к провайдеру вырастает.
Как же это все работает, и что с этим можно сделать еще
Вся магия скрыта в конфигурационном файле /etc/sw-cp-server/config, а именно — в строке:
error_page 497 https://$hostname:$server_port$request_uri;
Эта строка говорит веб-серверу (это работает только в случае nginx), что в случае простого HTTP-запроса на порт HTTPS нужно перенаправлять пользователя на «правильный» адрес. Правильный адрес состоит из указания корректного протокола HTTPS, хостнейма сервера, порта и оставшейся части ссылки из «неправильного» запроса.
Как многие уже догадались, можно заменить переменную $hostname
на определенный адрес. Таким образом мы избавляемся от жесткой привязки к хостнейму сервера. Только править наш конфигурационный файл — это очень плохая идея, так как, скорее всего, последующие обновления Plesk не смогут корректно установиться из-за того, что конфигурационный файл был изменен. Поэтому мы сделаем свой файл, в котором просто переопределим эту инструкцию. Создадим файл /etc/sw-cp-server/conf.d/zzz-myhost.conf
со следующим содержимым:
error_page 497 https://panel.provide.com:$server_port$request_uri;
перезапустим sw-cp-server
/etc/init.d/sw-cp-server restart
Таким образом, все пользователи будут отправлены по адресу https://panel.provider.com:8443
вне зависимости от хостнейма сервера.
Плюшка+
А для тех, кто не любит работать в консоли и напрямую править конфигурационные файлы, мы написали расширение, выполняющую для вас эту работу. Особенно это может пригодиться тем, кто активно использует Custom View и у кого нет root-доступа к серверу.
Единственный минус этого расширения — настройки автоматически не применяются. Поэтому необходимо перезапустить сервис sw-cp-server
или перезагрузить сервер полностью.
Писать расширения для Plesk’a очень просто. Все подробности есть в документации.
Ссылки
- Расширение – custom-plesk-host
- Plesk Extensions Guide
По каким функциям Plesk скучаете вы?
ссылка на оригинал статьи http://habrahabr.ru/company/parallels/blog/205614/
Добавить комментарий