|
|
|
|
|
|
|
|
|
|
| Главная | Учебник | Статьи | FAQ | Книги | Ссылки |
Установка PHP + Apache: CGI vs. module
Почему лучше ставить PHP как модуль сервера Apache и как это сделать.
Данное руководство (?) ни в коей мере не претендует на полноту отражения затронутых вопросов. Оно не описывает нюансов настройки веб-сервера Апач. Только самое необходимое. И только связанное с работой PHP совместно с веб-сервером Апач. И, естественно, возможны различные неточности и ошибки. Просьба указать на них (контактная информация — в конце статьи).
Сразу предупреждаю — те, кто дорожат своим временем (либо те, кому побыстрее хочется заполучить работающий веб-сервер) могут пропустить мои излияния (включая вступление, теоретическую и добрую половину практической части) и сразу перейти к Уроку 2. Там описывается установка PHP как модуля Apache под Win32. А остальное… Ну, кто-то, наверное, прочитает. ;)) Надеюсь, таких будет немало.
Вступление
Итак, почему я написал эту статью? И зачем нам вообще такая экзотика как Апач и PHP под Win32?
Для отладки скриптов PHP на локальной машине мне понадобилось установить веб-сервер + PHP под Win32 (принципиально пользуюсь MS Windows — ибо, на мой взгляд, продуктивная работа, связанная с веб-дизайном, под Unix и его клонами попросту невозможна — при этих словах я увернулся от летящего в меня Тухлого Помидора — эти системы хороши как серверная основа, но не более того). Спорить со мной не надо, да я и не буду. Кроме того, вы же читаете эту статью, а, значит, планируете установить Апач + PHP именно под всеми ненавистной Виндой. ;))
Не помню уж, что это был за первый испытанный мной веб-сервер, но запуск парсера PHP мои скрипты осуществляли строчкой #!c:/php/php.exe что не есть очень удобно. Хотя… Авторы PHP (в официальной документации!) указывают на то, что с точки зрения безопасности такой способ — наилучший. При этом сам парсер "живет" далеко от самих файлов со скриптами. И скрипт передается ему на выполнение не веб-сервером, а интерпретатором командной строки. Но я не думаю, что этому способу установки вообще есть смысл обращать пристальное внимание. Мы же с Вами не параноики и не мазохисты.
Памятуя о том, что большинство провайдеров использует в качестве веб-сервера Апач, решил установить его виндовую версию на локальной машине. Да и не только в провайдерах дело. Пожалуй, это, если и не самый, то один из самых конфигурируемых серверов. Сказано — сделано. Осталось прикрутить PHP. В Сети нашлось много руководств, подписанных разными авторами, но их содержание было подозрительно схожим... Чуть ли не с точностью до знаков препинания. Видимо, бОльшая часть этих статей представляет собой оригиналы разной свежести и клоны статей Дмитрия Котерова и Александра Бугакова. Если кого-то пропустил, I beg your pardon.
Итак, в них описывается способ установки PHP как CGI-программы. Этот способ заполонил всю сеть и многие даже не подозревают, что можно сделать иначе. Но мы его назовем "альтернативным". Да-да, именно так! Более того — я скажу, что это вредный способ. Он ссорит между собой тех, кто работает под виндой, и линуксоидов. Ибо когда первые жалуются: "у меня PHP как-то не так работает", вторые с кривой ухмылкой заявляют "Виндовз — маст дай! Линукс — рулез форева! Ставьте линукс — и таких проблем не будет. Потому что под виндовз НЕВОЗМОЖНО установить PHP как модуль Апача. Хоть в лепешку расшибись." Нет, я не хочу дискутировать о достоинствах или недостатках той или иной операционной системы. Тем более, не в данной статье. Но я сам чуть было не обратился в эту веру.
Теперь впечатления. Запускаем скрипт, который пытается послать заголовки (header) — неа, не работает :(( Заглядываем в мануал: в чем дело? Ах, какая досада... Оказывается, PHP должен работать как модуль Апача. Жалко... Ведь под винду нам модуль не установить... Так, а как насчет авторизации по коду 403? Тоже не работает... Придется и от этого отказаться...
Придется ли? Скорее всего, нет! Конечно, универсального решения я выдать не смогу, но постараюсь объединить в данной статье все (ну, или почти все) что известно мне о работе Апача + PHP под Win32. Возможно, статья будет исправлена и дополнена. Пишите письма.
Теоретическая часть.
Итак, как Вы поняли (из моего повествования, документации на PHP либо из других источников) возможны ДВА способа установки PHP на веб-сервере. Как CGI-программу и как модуль сервера. В принципе, подчеркну, в принципе, особой разницы нет. В любом случае, веб-сервер передает ядру PHP скрипт, путь к которому содержится в запросе клиентского браузера. В случае работы PHP как CGI порождается новый процесс, которому, собственно, и передается скрипт. В случае работы модуля, его код уже "висит" в памяти сервера. Это — основное принципиальное отличие. Что из этого следует — додумайте сами.
Итак, как устанавливать PHP для работы совместно с веб-сервером Апач? Как CGI или как модуль Апача? Практически, особой разницы нет, но... Как упомянуто выше, вы ДОЛЖНЫ установить PHP как модуль для реализации функций работы с заголовками и авторизацией. Впрочем, это явления одного порядка. Кроме того, в случае PHP как CGI-программы, переменная $PHP_SELF (которая должна хранить имя выполняемого скрипта) содержит все что угодно, но только не имя. Это не самое страшное, что бывает, но вдруг придется использовать чей-то чужой скрипт, в котором она широко используется... Бывает, что при повторном вызове скрипта по имени, которое содержит переменная $PHP_SELF, скрипт просто прекращает свою работу. Битая ссылка. Как это ни печально. Можно, наверное, назвать еще несколько отличий, но, как мне кажется, и этой разницы вполне достаточно, чтобы сделать выбор в пользу PHP-модуля.
Да, и еще. Установив PHP как модуль, вы получите возможность управлять некоторыми его параметрами из файлов .htaccess Для экспериментального сервера это, пожалуй, не настолько уж важно — все-таки, Вы являетесь и администратором. Но дистрибутивы некоторых программ PHP поставляются с файлами .htaccess, которые изменяют параметры PHP, и отказываются работать, если им это не удается. Можно поправить php.ini, но всякий раз для каждого скрипта его править... Нет, это выше человеческих сил!
Итак, короткая теоретическая часть и долгое вступление, вернее, лирическое отступление ;)) закончились. Приступим к практике.
Практическая часть.
Прежде всего, настоятельно рекомендую проверить работу веб-сервера Apache ДО каких-либо измывательств над бедным животным ;)) Поверьте, это сохранит Вам и многим другим кучу времени, нервов и физических сил. Не торопитесь устанавливать PHP, не проверив работоспособность Апача. Даже если Вам ОЧЕНЬ хочется. Всему свое время. Вам проще будет локализовать причину, если не будете торопиться.
Урок 1. Установка PHP а-ля CGI
Данный вопрос неплохо освещен в Сети. Но — справедливости ради упомянем его, ограничившись, правда, лишь ключевыми моментами.
Альтернативный способ. Прежде всего, рекомендуется все, что связано с локальной копией веб-сервера, сложить в одну директорию, а директорию, в свою очередь, подключить как виртуальный диск командой subst f: путь-к-директории, чтобы все было "как в юниксе". Действительно, мудрое решение. Особенно удобно не лазать по деревьям директорий (мы же не обезьяны, в конце-то концов) — все, что относится к веб-серверу, под рукой. Но не все, далеко не все имеют возможность выделить для экспериментов целый логический диск. Поэтому данный совет весьма полезен.
На установке самого веб-сервера я задерживаться, пожалуй, не буду. Ничего сложного нет, все конфигурационные файлы неплохо самодокументированы. Да и руководств по установке и настройке его в Сети — МОРЕ.
Итак, Апач уже установлен в директорию типа f:/usr/local/apache (где f — буква, соответствующая виртуальному диску) и полностью работоспособен. Соответственно, PHP хорошо бы установить рядышком — скажем, в f:/usr/local/php
Распаковываем архив дистрибутива PHP. Нам прямо-таки жизненно необходимо не так уж и много файлов. Это:
Представьте себе, это — ВСЁ! Кто-то спросит: а почему же оригинальный дистрибутив занимает аж по 3-5 мегабайт в архиве (в зависимости от версии и комплектации). А потому что в нем содержатся различные библиотеки расширений для генерации картинок "на лету", для работы с базами данных Postgre SQL, SyBase SQL и т.п. Заметьте: поддержка MySQL в PHP версии 4 встроена прямо в ядро и не требует никаких дополнительных файлов. Все эти расширения вы можете поставить в любой момент.
Установили, скопировали php.ini-dist из дистрибутива в директорию windows и переименовали его в php.ini. Попробовали, работает ли PHP сам по себе? Создайте в директории с PHP текстовый файл с именем, например, test.php: <? echo "TEST" ?>
И запускаете его из командной строки: php.exe test.php
Получаете такое вот:
| Content-type: text/html TEST |
Это означает, что PHP сам по себе работает.
Если у Вас не работает либо Apache, либо PHP, то рано нам заниматься конфигурированием связки Апач + PHP. Пусть оно сначала по отдельности все заработает. Обратитесь к разделу "Траблшутинг".
Итак, предыдущий шаг показал нам, что все О.К.
Последующие настройки касаются только файла конфигурации Апача httpd.conf. Добавим mime-тип, соответствующий расширению программ PHP: AddType application/x-httpd-php .php .php3 .phtml
Причем это следует сделать в секции описания модуля mod_mime — это стандартный модуль апача. Либо добавить в конфигурационный файл mime.types — но, мне кажется, лучше вносить изменения только в один файл, а не в десять сразу.
Затем поставим действие (action) в соответствие указанному нами типу:
<Directory "f:/usr/local/php"> Options ExecCGI </Directory> ScriptAlias "/__php_dir__/" "f:/usr/local/php/" Action application/x-httpd-php "/__php_dir__/php.exe"
Это рекомендуется сделать непосредственно перед секцией Virtual Hosts.
Ну и все на этом... Скопировали созданный нами тестовый файл в корневой каталог веб-сервера и набрали его URL в строке веб-браузера. Должно работать. Если нет — обратитесь к секции "Траблшутинг" ниже. Может, поможет. Также посмотрите настройки Апача — особенно секцию Virtual Hosts, если вы пытались обратиться к своему серверу по имени (ну, типа http://vasjapupkin.com/test.php).
Урок 2. Установка PHP как модуля Апачи
Необходимые материалы (тот минимум, с которым все работает):
Ход работы.
LoadModule php4_module "путь-к-директории-php/php4apache.dll"
Если Вы следовали приведенным выше рекомендациям назначения имен директорий, то она должна выглядеть как:
LoadModule php4_module "f:/usr/local/php/php4apache.dll"
#<Directory "f:/usr/local/php"> # Options ExecCGI #</Directory> #ScriptAlias "/__php_dir__/" "f:/usr/local/php/" #Action application/x-httpd-php "/__php_dir__/php.exe"
Траблшутинг
Допустим, оно у вас не заработало с первого раза... Что делать? Ну, прежде всего, конечно же, надо отправить во все конференции сообщение типа: "А-а-а-а-а!!! Хелп!!! У меня НИ-ЧЕ-ГО не работает!!!" И, разумеется, письмо автору данной статьи ;)) Самое главное — сообщите как можно меньше информации о своей системе — ну да, в конференциях ведь участвуют исключительно вундеркинды и телепаты, а Ваш покорный слуга — так и вовсе Маг и Волшебник. Таким как он догадаться, на какой системе Вы работаете, и в чем может быть дело — вообще пара пустяков! ;)) Да, кстати, в конференциях быстрее всего отвечают на постинги, набранные ЗАГЛАВНЫМИ БУКВАМИ. Ведь от долгой работы с компьютером портится зрение и Ваш постинг, набранный строчными буквами могут просто не заметить. ;))
А если серьезно, не надо паниковать. Давайте разберемся.
Симптомы: Апача запустилась. Но скрипты не выполняются — либо нагло лезут в окно браузера, либо хотят сохраниться на локальном диске.
Диагноз: Скрипт не передается на выполнение парсеру PHP
Лечение:
1. Проверьте работоспособность самого PHP. Для этого создайте в директории с php.exe файл, допустим, test.php:
<? echo "TEST" ?>
Запустите его командой php.exe test.php. Должны увидеть следующее:
| Content-type: text/html TEST |
Заметьте: между первой и третьей строками есть пустая строка. Так надо, так должно быть. Именно так и никак иначе.
Если это не срабатывает — PHP страшно ругается и плюется, проверьте, есть ли у вас все необходимые файлы. А именно, файл php4ts.dll в директории с PHP либо в директории, содержащейся в переменной окружения PATH. Киньте ее в системную директорию windows и не мучайтесь. (Ну, я же предупреждал — сначала проверьте работоспособность компонентов!)
Есть, но все равно проблема остается? Пожалуй, следует заглянуть поглубже... Впрочем, это выходит за рамки данной статьи. Скажу лишь, что файл php.ini, включенный в дистрибутив, требует настройки только в исключительных случаях. Поверьте, Ваш случай — самый ординарный. ;)) Скорее всего, тогда дело в поврежденных выполняемых файлах дистрибутива.
2. PHP сам по себе все-таки работает... Проверим связку Апач + PHP...
Если у вас PHP сконфигурирован для работы в качестве модуля Апача (настоятельно рекомендую настроить его именно так! это дело всей моей жизни), проверьте загрузку модуля и назначение mime-типа application/x-httpd-php
Если PHP работает как внешняя программа, дополнительно к назначению mime-типа, проверьте назначение action, которое ставится в соответствие данному типу (см. Урок 1)
Симптомы: Апач вообще не запускается. Выскакивает черное окошко сеанса MS-DOS и тут же закрывается.
Предварительный диагноз: Неправильная конфигурация Апача. Что-то неправильно прописано в конфигурационных файлах. Либо отсутствует библиотека, необходимая для запуска модуля PHP — php4apache.dll, либо само ядро php4ts.dll
Лечение: Ставим более точный диагноз:
Если самостоятельно не удастся разобраться, в чем же дело, это здорово поможет, если не Вам, то, возможно, специалисту, к которому Вы обратитесь (Эй! Я не сказал, чтобы все обращались ко мне!) Описания типа "я все нормально установил, но Он тут же вываливается" вряд ли кого удовлетворят. Все-таки, Апач, хоть и довольно невразумительно (а разве бывает в мире программ иначе?), но все же сообщает, почему он не может стартовать. Так вот: СМОТРИТЕ НА ЭКРАН — там часто сообщается о причинах ошибок программ. Не всегда, но часто. И данный случай — не исключение.
Итак, сначала попытайтесь вспомнить, ругался ли он так ДО установки PHP. Если нет, то:
В случае установки в виде CGI проверьте правильность написания директив настройки Апача и в тех ли секциях Вы сделали изменения. Других вариантов нет. Дело в этом и только в этом. Ибо PHP вызывается Апачем для выполнения скриптов и не играет никакой роли при запуске самого Апача. Поэтому дальше речь пойдет ТОЛЬКО о PHP как модуле Апача. На CGI больше не останавливаемся.
Если Вы устанавливаете PHP как модуль Апача, следует посмотреть, может, ему чего-то не хватает? ;)) Попробуйте, например, положить php4ts.dll в директорию с Апачем. Иногда это помогает. В общем, дайте простор фантазии. Только не рукам! Не надо бить компьютер за то, что вы такой неумеха ;)) А выглядит оно, бывает, устрашающе — Апач рушится, вызывая ошибку в apachecore.dll. Но это все неправда. Вам для работы требуется пиво, программам — библиотеки и файлы конфигурации. Не так ли? ;))
По моим наблюдениям, разные версии Апача ведут себя несколько по-разному при подключении PHP модуля. Пожалуйста, поправьте меня, если у Вас есть данные считать по-другому.
Так, Apache 1.3.12 ищет php4ts.dll сначала в своей директории (где лежит Apache.exe), затем в директориях, указанных в переменной окружения PATH. Вполне может быть, что в Вашем случае в системной директории Windows лежит php4ts.dll от другой версии PHP Как правило, от старой версии ;)) И php4apache.dll не может ее загрузить. А ТУ САМУЮ версию просто не находит. Честно сказать, я терпеть не могу, когда программы при инсталляции кидают в системную директорию свои библиотеки. Я скорее примирись с тем, что одна и та же библиотека будет у меня лежать в двух директориях. Речь идет о директории Апача и о директории с php.exe (иногда полезно) и библиотекой php4apache.dll. Вообще говоря, это все можно положить прямо в директорию Апача — и далеко ходить не надо, и апдейт проще произвести — нигде не забудете старую библиотеку.
Apache 1.3.14 ищет php4ts.dll сначала в той директории, где у Вас лежит php3apache.dll. В данном случае все файлы PHP можно сложить в одну директорию. Я так и сделал.
Еще бывают случаи, когда Вы пытаетесь прикрутить к PHP-модулю Апача дополнительные модули и библиотеки (например, пресловутую php_gd.dll) от других версий PHP. Не уверен, что это удастся. Во всяком случае, Апач (точнее, PHP в его составе) шибко ругается, что не совпадают внутренние версии API. Для начала лучше их все отключить. Понятно, где — в php.ini. В любом случае, присматривайтесь к сообщениям, выдаваемым при запуске.
Да, и еще. Подключая дополнительные модули, обязательно пропишите переменную extension_dir в файле php.ini — по умолчанию PHP ищет их в той же директории, в которой находится (./) а в дистрибутиве они лежат в директории extensions/ — странно, да?..
