Несколько вопросов, актуальных для начинающих (и как показывает практика и не очень начинающих) PHP-программистов по применению PHP на Unix-хостинге.

1. Что такое phpinfo и где его увидеть.

phpinfo - это функция PHP. Она показывает текущие настройки PHP на вашем сайте, подключенные расширения PHP и их настройки. Phpinfo не нужно искать в панели управления хостингом. Самый достоверный phpinfo - это тот который вы создадите сами в том каталоге вашего сайта, настройки PHP в котором вас интересуют больше всего.

Содержание скрипта выглядит очень просто:
<?php phpinfo(); ?>

Выкладываете это файлик по FTP или создаете в файл-менеджере панели управления хостином - и вот ваш phpinfo готов! Наберите адрес скрипта в браузере и вы увидите phpinfo!

Рекомендуем называть такой скрипт не phpinfo.php или info.php, а нестандартным именем, лишь бы расширение имени файла было .php, чтобы нечистый на руку посетитель вашего сайта не смог увидеть ваши настройки.

2. Какой нехороший человек придумал эти права ? Почему у меня постоянно permission denied ?

Отбросив нюансы, которые более интересны администраторам серверов, а не PHP-программистам, следует отметить, что на Unix-хостингах существуют две основные модели подключения обработчика PHP.

PHP как модуль apache. Наиболее распространен на русскоязычных Unix-хостингах. При этом подключении PHP включен в процесс веб-сервера Apache и выполняется с правами пользователя веб-сервера, а не владельца аккаунта.

Этот способ подключения хорош во многих отношениях, но имеются также несколько неприятных моментов. Один из них - права.

Ваш php-скрипт не сможет создать файл в каталоге с правами по-умолчанию, для такого каталога вам нужно установить права 777. Если скрипту требуется выполнять запись в файл - поставьте на этот файл права 666.

Файлы или каталоги, которые создал ваш php-скрипт, вы скорее всего не сможете изменить, в том числе изменить их права, потому что права может менять только владелец файлов, а владелец - тот, кто файл создал, т.е. пользователь веб-сервера :(

PHP как CGI/FastCGI/suphp-CGI. Наиболее распространен на импортных Unix-хостингах. На русскоязычных хостингах используется реже, но часто существет как альтернативный PHP-обработчик на серверах, где PHP подключен как модуль.

При таком подключении проблем с правами ни у вас, ни у вашего скрипта нет, поскольку CGI-php работает от имени владельца аккаунта. Но в этом случае вашему скрипту полностью доступны все без исключения ваши файлы и каталоги! Особенно это опасно, если вы используете устаревшую версию известного скрипта, в котором все дыры известны опытному хакеру наперечет.

Поскольку CGI работает с привилегиями владельца аккаунта, то и доступны ему для записи каталоги и файлы с правами по-умолчанию (755 и 644 соответственно) и дополнительных разрешений ставить не нужно.

В то же время, пожалуйста учтите, что php-скрипт который находится в каталоге с правами на запись для всех или для группы (777) или скрипт, имеющий такие права (666, 777) может не выполняться из соображений безопасности (ошибка 500)!

На наших хостингах используются оба варианта подключения. Если инсталлятор вашего скрипта создает файлы и каталоги самостоятельно, вы можете подключить PHP-CGI, а после окончания установки продолжить использование PHP-модуля.

3. Как изменить настройки PHP ?

Если на вашем хостинге PHP включен как модуль, то менять настройки PHP требуется в файле .htaccess.

Используйте директивы php_value и php_flag. Указывайте php_value для директив, которые имеют числовое или строковое значение.

Например:
php_value upload_max_filesize 16M
php_value post_max_size 24M

Для директив, предполагающих булевое значение используйте php_flag.

Например
php_flag register_globals Off
или
php_flag register_globals 0

Если в phpinfo вы видите Server API - CGI (или FasgCGI) попробуйте в каталоге, где находится ваш php-скрипт, создать файл php.ini.

Если переопределение настроек разрешено политикой безопасности вашего хостера, вместо базового конфига будет читаться ваш файл.

В него пропишите настройки в том формате, в котором они указываются в ini-файле.
upload_max_filesize = 16M
post_max_size = 24M
register_globals = Off

Будьте готовы, что в этом случае могут "отвалиться" Zend Optimizer, Ioncube Loader и другие модули, которые подключаются в базовом php.ini.
Если вы подключаете ваш php.ini, то базовый игнорируются. Используются настройки PHP по-умолчанию плюс скорректированные настройками в вашем php.ini.

Если вам требуются модули, которые отвалились при создании вашего php.ini, узнайте у хостера, какие директивы нужно добавить в ваш php.ini для их подключения.

4. Почему я не могу использовать на хостинге WMKeeper ? У меня вываливается ошибка "Warning: shell_exec() has been disabled for security reasons ..."!

Если на вашем хостинге PHP включен как модуль (Server API - Apache или Apache 2.0 Handler в phpinfo), то хостер вынужден запрещать такие функции как shell_exec, system, dl, passthru, exec, popen и другие, позволяющие php-скрипту выполнять программы операционной системы.

Это сделано потому, что пользователь, под которым работает веб-сервер (и php-модуль) имеет доступ к каталогам всех пользователей. И, несмотря на ограничение open_basedir, нехороший клиент может попытаться просмотреть содержимое каталога другого пользователя из PHP например при помощи системных команд:
echo `ls -l /каталог/другого/пользователя`;

Использовать такие функции вы можете, если есть возможность подключения PHP как CGI. В этом случае защита директорий пользователей осуществляется на уровне прав операционной системы.

Отключение запрещенных фукнций в PHP-CGI осуществляется при помощи создания пустого php.ini файла в каталоге скрипта, если переопределение настроек разрешено политикой безопасности вашего хостера.


5. Почему сайт на PHP, который отлично работает в Windows на Денвере, не работает на вашем глючном хостинге?

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

Зато наблюдаются (хоть и не так часто) другие:

• Имена файлов. Старо как мир, что в Unix-системах, в отличие от Windows, FILE и file - два разных файла, но этот момент время от времени упускают из виду как юнцы, так и убеленные сединами ветераны :) Особенно если ваш FTP-клиент, после установки по-умолчанию, переводит имена файлов в нижний регистр.
   
• Вы залили дистрибутив скрипта, закодированного Zend Encoder и видите - PHP Fatal error: Unable to read ххх bytes. Можно конечно сказать хостеру, что у него глючный сервер, а можно "поблагодарить" ваш FTP-клиент и собственную невнимательность, потому что вы залили закодированные файлы в текстовом режиме, а нужно обязательно в двоичном!
   
• Вы закачали PHP-скрипт и видите: Access denied for user 'root'@'localhost' (using password: NO).
  
  Нужно в панели управления хостингом создать БД, пользователя БД, предоставить пользователю привилегии и прописать данные доступа к базе в конфиге скрипта.
  
  Как root, да еще и без пароля, вы к БД на хостинге не подключитесь :)
  
  На хостинге под управлением Cpanel вы можете использовать для доступа к MySQL те же логин и пароль, которые вы используете для входа в cpanel, но этого лучше никогда не делать. Причины две - первая: данные доступа к аккаунту лежат в открытом виде и через уязвимость в скрипте кто-нибудь может их узнать и зайти в вашу Cpanel или FTP; вторая: вы измените пароль аккаунта в CPanel и у вас "ляжет" сайт :)
  
  Если вы часто обновляете сайт с вашего компьютера, лучше создать на вашем компьютере такую же базу и пользователя с тем же паролем, что и на хостинге.
  
  С root-доступом в MySQL это можно сделать при помощи двух несложных SQL-запросов:
  CREATE DATABASE имя_базы;
  GRANT ALL ON имя_базы.* TO имя_пользователя@localhost IDENTIFIED BY 'пароль';
  В этом случае вы можете смело заменять серверный конфиг локальным - и сайт продложит работу.
   
• Cannot send session cookie - headers already sent by (output started at ...
  
  Суть проблемы в том, что вы пытаетесь отправить cookie-заголовок после того, как в браузер уже были отправлены данные. В этом случае нужно просмотреть скрипт, имя которого указано в ошибке (output started at ...). Часто при редактировании конфигов пользователи добавляют строки после завершающего php-тега "?>". Пустые строки за рамками PHP-тегов - тоже информация, которая выводится в браузер посетителя сайта.
  
  Совет: никогда не редактируйте скрипты в кодировке utf-8 в блокноте Windows. Он добавляет в самое начало скрипта три байта, по которым он впоследствии понимает, что этот файл в utf-8. Это символы с кодами 0xEF, 0xBB, 0xBF, в десятиричном - 239, 187, 191, в текстовом виде это выглядит так "п»ї<?php ...". Но PHP-интерпретатор выводит эти символы вне PHP-тегов в браузер клиента "как есть".
   
• Ошибка 500. Попробуйте переименовать .htaccess во что-то другое - возможно ошибка в нем. Некоторые apache1 не работают в apache2, и, наоборот, apache1 не знает некоторых директив apache2. Если не помогло - переименуйте обратно. Вообще следует отметить, что более новые версии ПО более требовательны к синтаксису. Это относится и к apache mod_rewrite и к PHP и к MySQL.
  
  Проверьте права. Если PHP работает как CGI, все каталоги, которые проходит обработчик PHP на пути к вашему скрипту и сам файл скрипта не должны иметь доступа на запись для группы или остальных.
  
  Поищите в каталоге скрипта error_log - зачастую в нем вы можете найти ошибки PHP, если PHP включен как CGI.

Если ничего не помогло - обращайтесь к хостеру :)

При обращении к хостеру, будьте максимально скрытны. Пожалуйста, напишите с постороннего e-mail адреса, не указывайте ни номера заказа, ни адреса сайта, ни сути проблемы и обязательно выругайте его. В этом случае, хостер вам обязательно постарается помочь в кратчайшие сроки! :)))

[шутка]

Проголосовать за статью и оставить комментарий>>