Вместо вступления
Статью хотелось бы начать с маленького вступления о себе и своей причастности к WEB-девелопменту. Ещё буквально некоторое время назад аренда хостинга на коммерческой основе для меня не значила ничего, для своих опытных «проб пера» использовал различные бесплатные хостинги (все прекрасно помнят такие хостинги как boom, народ, холм и пр.). Всё это использовалось сначала для изучения и понимания html-разметки, а в дальнейшем и знакомство с азами php.
Но всё это было не серьёзно и делалось лишь с одной целью утолить жажду интереса к новому (ранее не познанного мною). И вот, буквально этой осенью, мои друзья решили создать свою фирму, выбрали направление — Туристический бизнес. После регистрации всех необходимых документов она предстали перед вопрос где и как заказывать сайт. Рассмотрев несколько вариантов контор, предоставляющих услуги разработки сайтов, друзьями было принято решение попросить сделать им сайт, естественно на не безвозмездной основе, но и не по рыночным ценам.
Свою работу я начал с подбора бесплатного движка для сайта, на котором можно основать более менее приемлемый сайт, естественно внеся некоторые изменения как в оформление сайта, так и в код движка. На изучение различных движков, попутно работая по основному месту работы, ушла примерно неделя.
На домашнем ноутбуке я поставил LAMP и начал детальный обзор того или иного движка. Сказать честно, я не ожидал увидеть такого многообразия бесплатных движков и выбор предстоял сложный. Во всех них были свои плюсы и минусы. И вот перебрал не один десяток движков я остановился на InstantCMS. Но о подходе к выбору и причинах я говорить не буду, статья будет о выборе хостинга и том, с какими трудностями я столкнулся, уже выбрав хостинг, дабы поделиться с вами этим, а также услышать ваши комментарии.
Выбор хостинга
При выборе хостинга были определённые условия, которым он должен отвечать:
- Иметь поддержку php, mysql
- Предоставлять ssh-доступ
- Иметь возможность использовать почту вида user@domain.tld
- Плата не должна быть высокой
- Почтовые ящики должны быть большими
Рассмотрев различные хостинги, я пришёл к выводу, что условия 1-3 выполняются всеми хостерами. С 5-м условием всё обстояло довольно таки интересно:
- Некоторые хостеры ограничивают количество используемых почтовых ящиков до определённого значения, что было неприемлемо
- На других хостингах место под почту было ограничено общим дисковым пространством, выделяемым под сам хостинг
- На третьих хостингах выделялось определённое место под почту, в среднем 100Mb (как например на этом NetAngels.ru)
- Разброс цен
Рассмотрев все предложения из всего огромного количество хостеров я остановил свой выбор на питерском хостинге TimeWeb.ru, а именно на их тарифе Optimo, по ряду причин:
- Приемлемая годовая плата за хостинг + домен: 1600 руб.
- Дисковое пространство: 2000 Mb
- 5 сайтов, 5 баз MySQL, 5 ftp-логинов
- SSH, php, Zend и прочее (по моему мнению поддерживают всё существующее)
- Неограниченное число почтовых ящиков вида user@domain.tld, а также выделение 1 Gb под каждый ящик
Конечно можно было бы выбрать любой другой хостинг и «приаттачить» Я.почту или Gmail, но в тот момент об я этом я просто не задумался.
Выбор сделан. Регистратор
Зарегистрировав хостинг, TimeWeb.ru предоставили 10 дней пробного периода, что тоже очень порадовало.
Домен был зарегистрирован через регистратора r01.ru. Следующим шагом было передать документы регистратору для проверки, что и было сделано 07-12-2010. Были переданы следующие документы:
- Свидетельство о государственной регистрации (ОГРН)
- Свидетельство о постановке на учет в налоговом органе (ИНН)
- Приказ о назначении единоличного исполнительного органа
- Протокол о назначении единоличного исполнительного органа
У регистратора понравилась приватность данных, воспользовавшись ей через whois стали выводиться следующие данные:
god@9gate:~/test$ whois abcekb.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).
domain: ABCEKB.RU
nserver: ns1.timeweb.ru.
nserver: ns2.timeweb.ru.
nserver: ns3.timeweb.org.
nserver: ns4.timeweb.org.
state: REGISTERED, DELEGATED, VERIFIED
org: OOO Uralskie tehnologii
phone: +7 495 7950139 395291
e-mail: abcekb.ru@r01-service.ru
registrar: R01-REG-RIPN
created: 2010.12.03
paid-till: 2011.12.03
source: TCI
Last updated on 2011.02.10 06:58:42 MSK/MSD
То есть вместо телефона и e-mail указаны реквизиты регистратора, которые перенаправляются на мои реальные реквизиты.
Но, появился и негативный момент: всем прекрасно известно, если документы не передать или их не одобрят делегирование сайта может быть приостановлено. И вот, 08.02.2010, через 2 месяца после подачи заявки решил проверить профиль на сайте регистратора:
> Информация проверена Нет
> Подтверждающие документы просмотрены Нет
что не сильно то меня обрадовало. Тут же было принято решение создать ticket, дабы разрешить проблему. В течении часа на почту пришёл ответ:
Здравствуйте.
Информация по договору проверена.
С уважением,
Сафина Венера
Департамент регистрации доменов R01...
Проверив профиль я убедился, что всё хорошо. Но тем не менее для меня это оставило негативный отпечаток о данном регистраторе.
О хостинге
Начав пользоваться хостингом сразу же был расстроен неработающим shh-доступом. Пришлось писать в саппорт. Опять же порадовал живой чат, через который мне сообщили что по дефолту ssh выключен и попросили данные договора, после чего в течении 10 минут ssh был включён. По данному вопросу у меня в голове так и крутится вопрос: «Почему ssh изначально выключен?»
Далее был процесс переноса сайта с ноутбука на хостинг и начало его эксплуатации.
За два месяца пользования хостингом появилось некоторое негативное мнение о хостинге:
Во-первых: 3 или 4 раза сайт не был доступен по 5-10 минут (это только те разы, с которыми я столкнулся)
Во-вторых: первый месяц (в декабре) не работало бэкапирование MySQL баз из админки управления хостингом.
Для меня и для фирмы, для которой этот сайт, это конечно не критично, но неприятно.
Подводные камни
А вот тут я столкнулся с серьёзным на мой взгляд недочётом.
Появилась необходимость использования mod_rewrite и .htaccess-авторизация. Начну с mod_rewrite.
mod_rewrite и Auth
В процессе разработки появилась необходимость переадресации запросов. Обычные редиректы с *.domain.tld на www.domain.tld не вызвали никаких сложностей, ЧПУ также использовалось прекрасно.
Но в один прекрасный момент понадобилось сделать редирект при запросе архива на страницу загрузки этого файла. Вот тут то я и столкнулся с проблемой. Пол дня потратил на изучение структуры .htaccess, но ничего не выходило, редирект не работал. В последствии выяснилось, что это из-за хостера.
Приведу пример данного негатива, но не касательно того, что нужно было мне, а приблизительно.
Имеем .htaccess со следующим содержимым:
RewriteEngine on
RewriteBase /
RewriteRule ^index\.html$ - [NC,L,F]при открытии файла index.html получаем положенную ошибку 403 Доступ запрещён.
Далее меняем содержимое .htaccess на следующее:
RewriteEngine on
RewriteBase /
RewriteRule ^test\.zip$ - [NC,L,F]
Как вы думаете, что должно произойти при попытке запросить test.zip? 403? Я тоже так думал, но не тут то было — файл спокойно загрузился. Чуть ранее конечно само правило было описано несколько не так, и я сломал голову пытаясь понять в чём дело. Но приведя правило к такому виду проблема не пропала, далее были ещё час экспериментов, после которых я понял: моей вины тут нет.
Написав в .htaccess следующий текст:
$_$
RewriteEngine on
RewriteBase /
RewriteRule ^test\.zip$ - [NC,L,F]
RewriteRule ^index\.html$ - [NC,L,F]Был удивлён результатом работы. При запросе index.html — 500 Internal server error. При запросе test.zip — качаю архив.
Выше сказанное справедливо при наличии test.zip на сервере. Удалив файл test.zip я получил такую же ошибку 500 в случае с «испорченным» .htaccess и 403 в случае с запретом.
Далее, решил узнать чем это грозит.
Имеем .htacces со следующим содержимым:
AuthName 'Restricted Area'
AuthType Basic
AuthUserFile /path/to/authfile/.authfile
require valid-user
Options +ExecCGI
DirectoryIndex extern.pl
, где /path/to/authfile — реальный путь к файлу с логином и паролем.
- Открываем сайт — получаем 403
- Открываем файл index.html- получаем 403
- Пытаемся открыть ссылку на несуществующий файл — получаем 403
- Открываем существующие test.txt, test.zip и подобные — качаем
Написал в саппорт, где при оставлении заявки радостно сообщили что ответят в течении 20 минут.
Запрос оставил 9 февраля 2011 11:13, ответ получил 10.02.2011 00:32:13. Далеко не 20 минут, ну да ладно.
Ответ меня сильно разочаровал:
У нас стоит связка nginx+apache и статика отдается через nginx, в этом случае apache не задействован, а файл .htaccess не обрабатывается.Я был просто шокирован. В случае с невозможностью сделать
RewriteRule ^news.zip$ /dnl [NC,R=301,L]при существовании файла news.zip я ещё могу потерпеть, хотя это не есть хорошо, и я бы сказал ужасно. Ведь в данном случае не получится следить за реферером при запросе архивов, картинок, мультимедиа и прочего по прямым ссылкам.Ну а самый главный минус невозможность сделать [F] на существующий файл, а также невозможность сделать нормальную авторизацию средствами .htaccess (апача) — ведь это разве безопасно, когда статику можно дёргать с сайта без пароля.
Вместо вывода
Да, хостинг недорогой, даёт много места, хорошую поддержку web-технологий, много больших почтовых ящиков, это конечно всё хорошо, но вот такая связка nginx+apache, по моему мнению, не просто камень в их огород, а целый булыжник. И в довесок периодическая недоступность сайта тоже не является показателем качества хостера. Надеюсь данная статья будет хоть кому-то полезна. Ну и мой совет касаемо хостера — использовать только для «бытовых» нужд.