Архив метки: apache

ISPManager 5 Lite или жестокий и беспощадный отечественный бизнес

apache, ispmanager, Панели управления хостингом, ,

Поработав недавно с панелью ISPManager 4, оставшись слегка недовольным результатом, решил проверить на что же способна панель ISPManager 5 Lite. Привлекла она меня возможностью установки на FreeBSD. Правда, как оказалось, только на FreeBSD 9. На десятку ставиться наотрез отказалась даже с принудительным выбором ОС. Перед установкой, согласно информации на сайте, необходимо иметь рабочий ключ активации. Это, в общем-то, при наличии возможности получить бесплатный триал-период на 2 недели, меня ни капельки не испугало.

Итак, развернул чистую FreeBSD 9.2 на виртуальной машине, скачал установочный скрипт и запустил. COREmanager скачался и запустился довольно быстро, настала пора установки ISPmanager. Я выбрал custom вариант установки с целью установить postfix в качестве почтового сервера и apache22-itk-mpm в качестве веб-сервера. Я знал, что установка apache-itk-mpm не всегда проходит без плясок с бубном, но имея достаточный опыт работы с FreeBSD, я был уверен, что все ошибки легко устраню. И да, я читал предупреждение в доках ISP о том, что установка apache-itk-mpm не проходит без глюков и лучше сначала поставить apache22, удалить его, и поставить apache22-itk-mpm. Но логика была простая: если опция в скрипте есть, то, возможно, все уже пофиксили, а доки подправить забыли. Иначе, если опция не работает, зачем добавлять ее в скрипт?

Естественно, процесс установки был прерван и случилось это на установке апача. Но! Причина была не в том, что не смог установиться апач, а в том, что по какой-то причине был недоступен mod_rpaf2. Скачать его не удалось, порт не собрался и установка всей панели была прервана. Попытка установить порт вручную тоже не увенчалась успехом и именно по причине отсутствия исходников порта. Да, такое случается в FreeBSD и лечится ручным поиском исходников и «подкладыванием» их в /usr/ports/distfiles.

А вот недовольство разработчиками панели началось непосредственно после этого. Логично было бы предположить, что если установка прервалась по какой-то причине, ее можно будет возобновить. Не тут-то было! Никакой заветной кнопочки «Retry» или чего-то похожего не обнаружилось! Ладно, мы пойдем другим путем и запустим установку с нуля. Авось, инсталлер увидит, что некоторые приложения уже стоят и не будет пробовать их переустановить. А если и будет, то distfiles уже на месте. Не было бы у меня этой записи, если бы все прошло без проблем… Панель запросила ключ активации… И, естественно, ругнулась на то, что этим ключом уже кто-то активировался (я, при прошлой попытке) и поэтому он не подходит. Таким образом, я был послан далеко и надолго к «your license provider» для решения проблемы.

Активация триал-лицензии ISPmanager

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

Обещания ISPmanager

И именно здесь я столкнулся с самым выдающимся предпродажным сервисом! Сервисом, который просто обязан быть не хуже (а зачастую лучше, для привлечения клиентов) сервиса послепродажной техподдержки! Никогда бы не догадался, что такое в принципе возможно в довольно серьезном бизнесе… Мне предложили КУПИТЬ возможность обращения в техподдержку! Это гениально, мне просто больше нечего сказать…

Техподдержка ISPmanager

P.S. Естественно, я не отправлял до этого ни одного запроса в ТП, а вся проблема кроется в том, что какое-то количество запросов идет вместе с коммерческой лицензией. Триал-лицензия не дает права пользования техподдержкой.

Работа WordPress на nginx + apache (постоянный 301 редирект)

apache, nginx, Wordpress, , , ,

В последнее время связка nginx + apache стала очень популярной среди администраторов веб-серверов. Эта связка довольно эффективна: nginx обеспечивает высокую скорость отдачи статического контента, кэширование, балансировку нагрузки, а apache, в свою очередь, давно признан стандартом де-факто среди веб-серверов за свою многофункциональность.

Ожидаемым было и появление хостинг-провайдеров, работающих с данной связкой. Чаще всего настройка nginx в данной связке ограничивается примерно такой конструкцией:

location / {
     index index.php index.html index.htm;
     try_files $uri $uri/ @proxy;
}
location ~ \.php$ {
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header Host $host;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_pass http://127.0.0.1;
}
location @proxy {
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header Host $host;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_pass http://127.0.0.1;
}

В таком случае установка WordPress вызовет бесконечную переадресацию с кодом 301. Дело в том, что nginx при получении запроса GET / будет подставлять индексный файл index.php и отправлять этот запрос на прокси, в качестве которого выступает apache. Apache, в свою очередь, запустит этот файл и за обработку запроса и формирование страницы примется WordPress. Для пущей красоты WordPress удалит из адресной строки index.php, который туда «дописал» nginx и вернет новый «красивый» урл с редиректом 301 клиенту. Клиент перейдет по нему, nginx допишет index.php и мы будем иметь то, что имели в самом начале.

Разные браузеры по-разному воспримут данную ситуацию, но бОльшая часть текущих версий после некоторого количества редиректов перестанет следовать им и выдаст страницу с ошибкой. Другими словами, сайт работать не будет.

Во избежание такой ситуации можно применить простой фикс: добавить в nginx еще один location, который будет отправлять запросы без указания конкретного файла сразу на apache без дописывания индексного файла. Таким образом, надо добавить примерно такую конструкцию:

location ~[^?]*/$ {
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header Host $host;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_pass http://127.0.0.1;
}

В таком случае запрос вида GET / будет передан на apache без изменений, wordpress его корректно обработает и вернет главную страницу сайта. При этом, естественно, индексный файл index.php должен быть определен и в конфигурации apache.