Проект "Хостинг Обыкновенный" успешно работает с августа 2005 года
Внимание: открыт Клуб пользователей хостинга обыкновенного, где Вы можете задавать свои вопросы.
Q: При запросе страницы я получаю страницу ошибки 500. Что делать?
A: Прежде всего - для отладки любых ошибок веб-сервера, желательно включить журнал ошибок (лог ошибок) в панели управления хостингом. Сам журнал (файл error.log) при этом появится в директории logs вашего домашнего каталога, а сообщения об ошибках начнут писаться в течение 3-х часов.
По анализу сообщений об ошибках в журнале ошибок можно делать выводы о причине, их вызвавшей. Вообще, можно выделить 2 категории причин ошибок:
Самым идеальным вариантом будет случай, когда вы сможете понять, после какого вашего действия произошла данная ошибка 500. Тогда вам будет легче её локализировать и устранить. Сейчас же дадим некоторые наиболее типичные случаи и советы, куда нужно "смотреть":
Q: При запуске моего скрипта я получаю сообщение bad interpreter: No such file or directory и скрипт при этом не выполняется.
A: Это сообщение появляется в 2-х случаях - неверный путь к интерпретатору (обычно указывается в самой первой строке скрипта после символов #!, например #!/usr/bin/perl) или формат файла отличный от ASCII (переводы строк состоят не из одного символа с кодом 10 (\n), а из 2-х: 10 13 (\r\n). Двусимвольный перевод строк характерен для DOS и Windows-кодировок, но никак не применим для UNIX-сценариев.
По этому вполне рабочие скрипты на Windows-системах будут выполняться нормально, а у нас - с ошибкой сервера 500. Для преобразования файла скрипта в ACSII-вид, можно использовать специальные программы-перекодировщики текстов, стандартный Windows'овский блокнот (notepad) - имеет ACSII-опцию при сохранении, а некоторые FTP-клиенты (например, рекомендуемый нами FAR) - автоматически могут переконвертировать текстовые файлы в ACSII-вид при закачке файлов на сервер.
Кроме этого, предоставляемый нами файл-менеджер также автоматически выполняет вовремя закачки на сервер (при необходимости) преобразование скриптов в ACSII-вид.
Q: При вызове php-скрипта я получаю сообщение 404: файл /cgi-bin/php/index.php не найден.
A: Очень распространенная ошибка пользователей связанная с вмешательством в иерархию файлов в директорию cgi-bin. В этой директории не нужно располагать никакие php-файлы - в ней расположен только интерпретатор php и файл его настроек (файлы php и php.ini соответственно). Помимо этих файлов в директории cgi-bin можно располагать cgi-скрипты.
Сами же php-файлы нужно располагать как и обычные html-документы в директории htdocs. Итак, если данная ошибка появилась, то вам необходимо восстановить исходное состояние php-интерпретатора, а именно - 2 файла (php и php.ini). В дальнейшем настоятельно рекомендуем осторожно относится к этим двум файлам. При необходимости внесений изменений в настройки php-интерпретатора - можете это делать (изменять файл php.ini), однако делайте это грамотно и зная, что делаете и что хотите добиться. Поломанные php-интерпретаторы обмену и возврату не подлежат. Ещё попутное замечание - не перезаписывайте файл настроек php.ini "своим" - это чревато поломками начиная от платформо-зависимых настроек и заканчивая настройками, зависящими от версии интерпретатора php.
Q: У меня на хостинге не работает "учебный" скрипт HTTP-аутентификации на php. В чём дело?
A: Дело в том, что HTTP-аутентификация на php работает только в случае, если php работает как модуль веб-сервера Apache (о чём чётко написано в документации). У нас интерпретатор php установлен как cgi-приложение, а предоставлять php как модуль Apache мы не можем. Однако вы сами можете настраивать HTTP-аутентификацию для отдельных файлов или всего каталога из файл-менеждера.
Q: Мои на 100% рабочие php-скрипты не корректно работают на Вашем хостинге. При сабмите формы данные серверу не передаются. Что делать?
A: Это самая распространённая ошибка. Дело в том, что с некоторых времён разработчики php решили отключить по умолчанию (в целях повышения безопасности) глобальную регистрацию переменных, переданных скрипту различными методами (GET, POST и т.д.). Если вы писали свои скрипты "в старом" стиле, полагаясь на автоматическую регистрацию переменных, и вы не хотите их переписывать, присвойте переменной register_globals значение On (в конфигурационном файле php.ini, который находится в директории ~/cgi-bin вашего домашнего каталога).
Также некоторые скрипты используют массивы переменных $HTTP_*_VARS[], автоматическое создание которых также по умолчанию отключено. Включить создание этих массивов можно с помощью переменной register_long_arrays. И не забывайте, что в конфигурационном файле php.ini строки, в начале которых стоит точка с запятой ";", являются комментариями! И изменение значения закомментированных переменных ни к чему не приведёт!
Q: Какие пути интерпретаторов/программ на вашем сервере (perl, python, sendmail,..)?
A: Эти пути на всех серверах хостинга www.ho.ua следующие:
Q: Поддерживает ли хостинг Zend optimizer?
A: Нет. И устанавливать его мы не планируем, даже для отдельных хостингов. Среди причин - невозможность поддержки скриптов (без сохранения исходников остаются одни бинарные файлы), возможные проблемы из-за несовместимости версий php, Zend Optimizer'a и даже ОС (такие факты известны).
Q: При добавлении php-директив php_value в файл .htaccess появляется ошибка 500
A: Установка переменных интерпретатора php в файле .htaccess с помощью php_value ... возможна только в том случае, если php работает как модуль веб сервера Apache. У нас php работает как cgi-приложение и его настройки можно выполнить в файле ~/cgi-bin/php.ini.
Q: Как внести изменения в настройки php (php.ini)?
A: Файл настроек php.ini интерпретатора php может располагаться в директории ~/cgi-bin. Однако, начиная с версии php 5.3 существует более гибкая возможность изменения настройки php - через так называемый файл .user.ini, который следует располагать в той же директории, в которой расположены сами php-скрипты. При этом, по аналогии с файлами .htaccess веб-сервера Apache, настройки php могут быть переопределены во вложенных каталогах через размещенный в них файл .user.ini. Т.е. для каждой директории сайта можно установить свои определенные настройки php. Если же файла .user.ini в директории нет, то php будет использовать настройки из глобального файла настроек. А внесенные в файл .user.ini настройки лишь переопределяют настройки по умолчанию из глобального файла настроек php. Отметим, что в принципе, опции в глобальном файле настроек php имеют рекомендованные разработчиками php значения и должны подойти для большинства корректно-написанных php-скриптов.
Сам файл настроек имеет достаточно понятный синтаксис, а комментарии и примеры файла Вы можете найти в Интернет. Мы приведем лишь некоторые советы и определения новичкам:
Q: Можно ли установить модуль CURL (для php или perl)?
A: Нет. По одной простой причине - у нас запрещены все исходящие соединения и данный модуль просто бесполезен в данной ситуации.
Q: Какие режимы (права) доступа для исполняемых сценариев (скриптов) и обычных файлов и директорий?
A: Мы приведем лишь рекомендуемые режимы доступа в буквенном (rwx) и восьмеричном форматах:
Более подробно о режимах доступа вы можете узнать из официальных источников UNIX-систем и в статьях, посвященных UNIX. Одно замечание - не увлекайтесь черезчур широким режимом доступа rwxrwxrwx (777) или узко-параноидальным rw------- (600) - первое является отражением высокой неграмотности и дурным тоном, а второе - на нашем сервере бесполезным, поскольку никто кроме вас самих не может получить доступ к вашей домашней директории (и её содержимому).
Единственным исключением может быть случай конфигурационных файлов сайта, в котором могут храниться пароли и другие "никому не нужные" данные. Однако в этом случае правильным будет защитить данные файлы с помощью директив веб-сервера (с помощью файла .htaccess) или вообще "вынести" данные файлы в корень вашей домашней директории (т.е. не хранить их в директории htdocs). С корня домашней директории скрипты и php-сценарии смогут без проблем получить доступ к данным в этих файлах настроек, а вот посторонние через веб-сервер получить доступ не смогут ни при каких режимах доступа самого файла.
Q: Тестовые скрипты не работают, хотя вчера ещё все было в порядке. Что делать?
A: Наши рекомендации таковы:
Q: Где можно узнать о разных типах журнальных файлов (лог-файлов), ведение которых можно включить в Панели управления хостингом?
A: У нас есть следующие типы журнальных файлов:
Приведённые в описании журнальных файлов переменные (с знаком % вначале) заменяются на следующие реальные значения:
Более подробно о журнальных файлах вы можете узнать из документации к веб-серверу Apache.
Q: Журнальный файл сильно большой. Как можно его удалить или уменьшить размер?
A: Управление журнальными файлами (создание, очистка и удаление) производится из панели управления хостингом (кнопка "Журнальные файлы"). В панели вы можете как очистить журнальные файлы, так и изменить их ведение - для уменьшения занимаемого или дискового пространства можно уменьшить их количество, выбрать компрессию старых журнальных файлов, а также уменьшив параметр архивации (например, с еженедельной до ежедневной).
Ни в коем случае не рекомендуем удалять журнальные файлы (кроме ротированных (архивных) с именами, в конце которых присутствуют числовой индекс) через FTP-клиент или файл-менеджер. Это может негативно отразиться на работоспособности вашего сайта.
We provide domain name registration for UA and COM.UA in Ukraine since 2000 / Мы регистрируем украинские домены с 2000 года