Раздел: Компьютерная документация -> Операционные системы -> Windows

Благодарности

Автор благодарит:

• Александра Сиренко aka skyx - системного администратора ISP Telematika
• Андрея Венина aka shaelf - PHP программиста.

Их замечания и поправки преобразили изначальный вид статьи до неузнаваемости. За что им огромное спасибо.

Вместо предисловия

Про что эта статья?

Если вы еще не догадались, AMP это аббревиатура, означающая классическую связку: Apache, MySQL, PHP. Эти три продукта настолько "сроднились" что воспринимаются практически как одно целое. В этой статье я опишу процесс установки и конфигурирования этой связки для ОС Windows, кратко освящу основные особенности работы Apache на платформе Windows. Кроме того, отдельно будет описан процесс установки и настройки ActivePerl, а также настройка Apache для обработки CGI сценариев, на примере Perl. Отмечу, что основной акцент будет сделан именно на настройке Web сервера.

Для кого эта статья?

Во-первых, для Web разработчиков. В первую очередь для тех, которые с завидным постоянством задают одни и те же вопросы на форуме :. Подавляющее большинство людей у нас работают с ОС от Microsoft. Этому есть целый ряд причин, как субъективных, так и вполне объективных. А вот детища Microsoft - IIS с ASP, не говоря уже про MSSQL, не так популярны среди заказчиков, хостеров, а соответственно и Web разработчиков. Так уж сложилось. Не ставить же им Linux/FreeBSD только ради того, чтобы испытать свое творение (поделие?) в боевых условиях? Итак - первые потенциальные читатели это Web программисты. Кстати, все дальнейшее изложение строиться именно с учетом того, что читать его будут программисты.

Во-вторых, я не вижу причин, почему такая связка не может использоваться в реальных условиях. Пример - фирма, в которой работает квалифицированный Windows администратор, решила создать корпоративный сайт на собственной машине (потому что доверяет только своему админу), а разработчики все, как на зло, предлагают PHP движки. В этом случае вполне возможно развертывание корпоративного сайта под ОС Windows с использованием AMP. Возможно не самое лучшее решение, но, поверьте, квалифицированный администратор вполне сможет обеспечить надежную работу такого сервера. Это лучше, чем изучать с нуля FreeBSD либо Linux - в этом случае ошибки неизбежны. Тем более, что по отзывам компетентных людей, которым я не имею оснований не доверять, Windows 2003 - вполне надежная штука.

И наконец статья может быть полезна всем, кто интересуется Web сервером Apache, и при этом не хочет менять привычную "среду обитания" - Windows.

Куда ставить

Куда ставим? Я ставлю на Windows XP SP2. Вам рекомендую ставить на любую ОС от Microsoft, старше, чем Windows NT. На Windows NT тоже можно, при наличии Service Pack 6a, но я этого делать не рекомендую. Аппаратные требования - на любой машине, на которой заработают указанные ОС, будет работать и Apache :.

Apache. Установка и настройка

Какую версию выбрать?

Первая проблема, с которой столкнется любой, начинающий работать с Apache - выбор версии. На сегодняшний день есть три ветки Apache: 1.3, 2.0, и 2.2. Что выбрать? Однозначный ответ - НЕ Apache 1.3.

Сервер Apache 1.3 для UNIX подобных ОС представляет собой процесс, с множеством предварительно порожденных дочерних процессов (preforked). Для операционной системы Windows такой способ обслуживания множества запросов чужд. Windows использует многопоточность. Кроме того, версия Apache 1.3 для Windows использовала в основном сетевые функции POSIX, а у Microsoft, как известно, существует своя, своеобразная, реализация стека TCP/IP. В версии 1.3 полноценная поддержка Windows так и не была реализована, поэтому на сайте http://httpd.apache.org НЕ рекомендуют использовать ветку 1.3 (текущий релиз, на момент написания статьи, 1.3.35) на операционных системах от Microsoft.

При разработке второй ветки, разработчики пошли другим путем. Apache всегда был модульным сервером. Это значит что основная функциональность реализовывалась сервером при помощи подключаемых модулей, таких как mod_php например. Начиная с Apache 2.0, в отдельные модули вынесли и ту часть сервера, которая отвечает за прием и обработку сетевых соединений. Называются эти модули MPM - multiprocessing modules. Таким образом, вопреки распространенному заблуждению, Apache 2.х не является "многопоточным сервером" в той своей части, которая касается приема и обработки запросов. На самом деле при сборке предоставляется возможность выбора нужного модуля. Хотите - используйте старый проверенный метод preforked и ставьте модуль mpm_prefork. Хотите большей производительности - используйте гибридный модуль mpm_worker. И так далее. Для Windows существует специальный модуль mpm_winnt который использует специфические вызовы Windows API, сетевые функции Winsock2, а не POSIX.

Таким образом, вывод очевиден. Ставим Apache второй ветки. Какой именно - 2.0 или 2.2? Среди нововведений 2.2 - переработанная система аутентификации, усовершенствованные модули кэширования, добавлен модуль балансировки загрузки для mod_proxy, поддержка файлов размером более 2-х Гб и так далее. Пока что это для нас несущественно. В первоначальном варианте этой статьи использовался Apache 2.2, однако выяснилось, что он категорически отказывается загружать имеющийся в моем дистрибутиве PHP модуль PHP (для Apache 2.2 модуль от 2.0 не подходит). Поэтому пришлось от него отказаться и использовать Apache 2.0.58

Как ставить

Способа есть два. Apache поставляется как в виде исходных текстов, так и в виде бинарного дистрибутива. Для ОС Windows бинарный дистрибутив представляет собой стандартный пакет "Windows Installer", иначе говоря, файл с расширением msi.

Я настоятельно рекомендую вам использовать именно второй способ установки, даже если у вас в системе установлен компилятор. На сайте Apache даются описания установки из исходных кодов, в том числе и для ОС Windows. Однако профессиональные системные администраторы практически никогда не занимаются ручной сборкой ПО из исходных текстов, хотя в среде начинающих юниксоидов существует ошибочное мнение, что "установка из сырцов это круто и правильно". От них, собственно и пошел тот миф, что в Linux/UNIX все ставиться руками и из исходников. На самом деле, любой опытный системный администратор использует тот способ установки, который принят в конкретной операционной системе: rpm пакеты в Red Hat, систему портов во FreeBSD или Gentoo, ну и MSI пакеты в ОС Windows. К установке из исходных текстов прибегают в исключительном случае. Такой подход позволяет лучше контролировать установленное в системе ПО, упрощает обновление, установку заплаток и тому подобное. Кроме того, установка ПО в системе Windows, как правило, выполняется в режиме мастера, где вы, в большинстве случаев можете установить все необходимые вам параметры пакета, что избавит от необходимости ковыряться потом в конфигурационных файлах.

Я вас убедил? Будем, как правильные люди, загружать себе пакет MSI и ставить готовый бинарный дистрибутив. Выбирайте здесь http://httpd.apache.org/download.cgi нужное зеркало и качайте. Нужный нам файл будет называться apache_2.0.58-win32-x86-no_ssl.msi. Как видно из названия, поддержка SSL в дистрибутив не включена. И не ищите пакет с поддержкой SSL. Его нет. Так что если вам нужно использовать SSL, придется устанавливать патчи вручную. В этой статье я не буду рассматривать как это делается. Может в другой раз :

И последнее. Для тех, кто не ищет легких путей, скажу, что собирать Apache вручную можно при помощи компилятора Microsoft Visual C++, начиная с версии 5.0. Также вам понадобиться Platform SDK (включен в поставку MSVC++ 6.0 и более поздних версий), утилита awk либо gawk и много терпения.

Установка

Итак, мы скачали нужный нам MSI пакет. Запускаем инсталляцию. Начинается все традиционно: вам предложат прочитать лицензионное соглашение, несколько раз нажать клавишу next: Если вы хоть раз устанавливали ПО для Windows, ничего нового вы для себя не увидите. Первое окно мастера, которое заслуживает внимания, выглядит так:

Рисунок 1

• Network domain - DNS имя домена, в который входит ваш сервер. Если такового нет, например вы ставите Apache на отдельно стоящей машине, можете в принципе писать все, что душе угодно. Обычно пишут что-то вроде domain.local.
• Server Name - DNS имя вашей машины + имя домена.

  Тут надо сделать небольшое лирическое отступление. Читая различные топики на форуме, я сделал вывод, что многие начинающие Web мастера (и не только) не различают NetBIOS и DNS имена хостов, а также не представляют механизмов разрешения этих имен в IP адреса. Подробное рассмотрение вопроса просто не укладывается в рамки статьи, вкратце скажу следующее - имена, с которыми работает Apache - это DNS имена. Для корректной работы сервера имена хостов, с которыми он будет работать должны быть занесены в DNS. Проще всего выяснить настройки DNS у своего системного администратора, либо провайдера. Если вы работаете с локальной машиной - можете использовать файл %SystemRoot%\system32\drivers\etc\hosts. В нем также прописывается соответствие IP адресов и символических имен. NetBIOS имен Apache не знает и знать не хочет.

  Я устанавливаю Apache на машину, входящую в локальную сеть городского провайдера. Имя машины в данном случае - net-11-125-ilyichevsk.loc. Можете сюда также ввести IP адрес своей машины.

• Administrator's email address - почтовый адрес администратора, который Apache будет показывать клиентам вместе с сообщениями об ошибках. Так что если вы не уверены, что настроите Apache как следует, лучше не помещайте туда свой реальный почтовый адрес :

Следующий вопрос - как вы хотите установить Apache? На стандартный 80 порт, для всех пользователей и запускать как сервис, или только для вас, на порт 8080 и запускать вручную? Выбирать вам, замечу лишь, что для первого типа установки нужны права администратора. Кроме того, если машина не принадлежит вам безраздельно, другим пользователям установка новой службы может не понравиться. ;)

Следующее окно - выбор типа инсталляции.

Рисунок 2

Как обычно, это Typical, то есть стандартная установка и Custom, установка выборочная, рекомендуемая для продвинутых пользователей. Мы с вами выберем естественно выборочную установку и попадаем в следующее окно (рисунок 3)

Рисунок 3

Тут нас интересует не столько выбор компонентов (ставьте все, пригодится) сколько выбор пути для установки. Путь на вашем месте я бы выбирал покороче, без пробелов, точек и тому подобных изысков. Путаться будете меньше.

Жмем кнопку Next, и откидываемся на спинку кресла. Дальше установщик все делает сам. Впрочем, делает он все так быстро, что вы вряд ли успеете даже за кофе сходить. После установки в трее появится значок (попробуйте сами найти его на картинке :) Apache, нажав на который правой кнопкой, вы сможете вызывать Apache monitor и поуправлять состоянием службы.

Рисунок 4

Установка завершена. Теперь проверим, работоспособность нашего сервера, набрав в браузере адрес http://127.0.0.1, либо http://localhost, что в принципе одно и то же. Должны получить

Рисунок 5

Все просто и понятно, не так ли? Вы ЭТО видите? Значит, все сделано правильно и Web сервер работает. Если же что то идет не так: обычно дело в простой невнимательности - например у вас установлен "самый лучший firewall для ОС Windows" Agnitum Outpost, который блокирует входящие соединения на 80-й порт. Или вы просто забыли запустить службу :

Теперь скажу пару слов о структуре каталогов нашего сервера. Я, как вы наверное заметили, ставил Apache в каталог D:\www\. Установщик создал в нем подкаталог Apache2. Этот каталог (D:\www\Apache2) описывается директивой ServerRoot файла httpd.conf. Документация называет его "каталогом где живет сервер". Смысл этой директивы в следующем: если в файле httpd.conf не указан абсолютный путь к какому либо файлу, он отсчитывается, начиная с пути, указанного в ServerRoot. Например, директива:

LoadModules modules/mod_alias.so

Загрузит модуль, который находится (для моего ServerRoot) в D:\www\Apache\modules или, иначе говоря, в ServerRoot\modules.

Содержит следующие подкаталоги (перечислю основные):

• Bin - каталог, содержащий различные приложения сервера Apache - собственно сам сервер, утилиты ротации логов, тестирования производительности и т. п.
• Cgi-bin - в этом каталоге обычно находятся CGI сценарии. Подробнее о том, как настроить Apache на выполнение CGI сценариев я расскажу ниже. Замечу лишь, что их можно размещать не только в этом каталоге, но делать этого не рекомендую.
• Conf - файлы конфигурации Apache, в том числе главный конфигурационный файл httpd.conf
• Htdocs - каталог, в который сервер по умолчанию переправляет все запросы страниц. Указывается директивой DocumentRoot (DocumentRoot = ServerRoot\htdocs). Например по ссылке http://localhost/index.html на моем сервере вы попадете на файл D:\www\Apache\htdocs\index.html.
• Modules - в этом каталоге находятся различные модули Apache, загружаемые директивой LoadModule

Если вы заметили, то в примерах при описании путей мы применяли как традиционный для Windows обратный слэш ' \ ', так и ' / ' - прямой слэш, применяемый в UNIX. Это несущественно. Вы можете использовать в конфигурационном файле и тот и другой способ записи. И еще. Если вы не послушались и ставили Apache куда-нибудь в Program Files, помните - все имена с пробелами, которые вам понадобится внести вручную в конфигурационный файл httpd.conf надо заключать в кавычки:

Alias /photo/   "D:/my photo/nature"

Что крутить руками

Если вы уже насладились зрелищем работающего Web сервера и разобрались, что куда ставится: останавливайте службу. Можете сделать это через значок в трее, если нашли, конечно, можете через оснастку служб Панели управления. Windows Installer - это хорошо, но кое что все же придется делать руками. Многие статьи дают рекомендации по после установочной настройке Apache. Они описывают, как должны выглядеть директивы ServerRoot, DocumentRoot, ServerAdmin и т. п. Смысла в этом не вижу, поскольку если вы последовали моему совету и ставили Apache из MSI пакета, то все эти директивы установлены автоматически и правильно. Так что файл httpd.conf мы пока руками трогать не будем.

А вот что сделать очень желательно, так это изменить пользователя, от имени которого работает Apache, для повышения безопасности нашего сервера. Если вы не устанавливали Apache как службу, можете этот раздел смело пропустить.

В ОС семейства UNIX при инсталляции Web сервера создается специальная учетная запись (обычно apache) с правами которой и работает Web сервер. Поэтому, даже обнаружив в Apache уязвимость, максимум, что получит взломщик - это права непривилегированного пользователя Apache. В ОС Windows по умолчанию, Apache выполняется с привилегиями пользователя LocalSystem, что совершенно недопустимо. Во-первых - данный пользователь не имеет доступа ни к каким сетевым ресурсам - ни через именованные каналы, ни через RPC, ни через DCOM. Во-вторых, данный пользователь имеет очень большие полномочия в локальной системе. Если хотя бы один из пунктов вас не устраивает, делаем следующее:

• Создаем учетную запись пользователя, например apache, назначаем ей пароль.
• Проверяем, что учетная запись входит в группу пользователей (не администраторов!)
• Запрещаем для данной учетной записи локальный вход (см. рисунок 6), запустив оснастку MMC gpedit.msc
• В соответствии с документацией Apache, там же выставляем политики, позволяющие Apache работать в режиме операционной системы, а смотрим, чтобы не был запрещен вход в качестве службы

Рисунок 6

Следующий шаг установка - прав на папки и файлы:

• Папки htdocs, cgi-bin и их содержимое - пользователь apache должен иметь права на чтение и выполнение. По умолчанию эти права установлены для группы пользователей, в которую входит наш специальный пользователь, поэтому менять ничего не придется.
• Папка logs - установите права на запись для пользователя Apache
• На файл bin\httpd.exe - собственно это и есть наш процесс Apache установите права на чтение и выполнение. Впрочем, эти права уже имеет группа Пользователи, так что и тут менять, скорее всего, ничего не придется.

Ну и, наконец, запускаем оснастку управления службами, и устанавливаем для службы Apache запуск от имени пользователя Apache, как показано на рисунке 7.

Запустите сервер Apache. Теперь вы должны увидеть в диспетчере процессов в списке запущенных служб процесс Apache (httpd) работающий от имени пользователя apache (см. рисунок 8)

Рисунок 7


Рисунок 8

Особенности Apache на платформе Windows

Первое, про что надо упомянуть - это файлы .htaccess. Вещь полезная, используемая, но в "умолчальном" виде на платформе Windows неприменимая. Потому что создать файл с точкой в начале имени вам не удастся, как бы вы не старались. Хотя правильнее будет сказать, что вам не удастся создать такой файл стандартными средствами Windows. В файловых менеджерах, типа FAR или Total Commander, такие имена файлов допустимы. Но, согласитесь, если любимый пользователями Проводник протестует против подобных имен, искать обходные пути - не лучшее решение. К счастью есть более простое решение. Используйте директиву AccessFileName. С ее помощью можно явно указать имя файла, используемого для регулирования доступа к каталогам. Например:

AccessFileName   htaccess

Почувствуйте разницу :. Обратите внимание, что в этом случае вам придется побеспокоится о том, чтобы кто попало не мог читать ваш новый htacсess файл. В конфигурации по умолчанию за это отвечает следующий блок директив: <FilesMatch "^\.ht"> Order allow,deny Deny from all </FilesMatch>

Данные директивы запрещают доступ к файлам, начинающимся с .ht. Если вы создаете файл без точки как в примере выше, можете использовать такой код:

<FilesMatch "^ht">
       Order allow,deny
       Deny from all
</FilesMatch>

Следующее отличие - это директивы для управления процессами и потоками. В Windows нельзя менять значение директивы MaxRequestPerChild, которая в UNIX позволяет регулировать число соединений, обслуживаемых каким либо порожденным процессом Apache. По умолчанию, значение этой директивы равно 0. Для Windows, таковым оставаться и должно. Потому как для Windows процесс - он один единственный. И перезапуск его при достижении допустимого числа подключений вовсе не желателен, Так же в Windows неприменимы директивы MaxSpareServers, MinSpareServers, StartServers. Для Windows существуют специальные директивы, относящиеся к модулю mpm_winnt например ThreadLimit, ThreadPerChild. Подробности смотрите в документации Apache.

Еще одна специфическая особенность Apache под Windows - способ задания интерпретатора для выполнения CGI скриптов. В UNIX интерпретатор задается при помощи shebang - явного указания интерпретатора в первой строке скрипта. Для Windows традиционным способом является выяснение типа файла через реестр. Как Apache для Windows будет определять интерпретатор для конкретного скрипта, зависит от параметра ScriptInterpreterSource. Этот параметр позволяет определять нужный интерпретатор как при помощи shebang последовательности, так и через реестр.

И напоследок я скажу...

Для начала - про настройку Apache на выполнение CGI сценариев и про виртуальные хосты. Этим темам посвящен, наверное, каждый второй вопрос про Apache на форуме. Итак:

Для включения CGI в Apache есть несколько способов. Можно использовать опцию +ExecCGI. Например:

<Directory D:/www/Apache2/scripts>
   Options +ExecCGI
</Directory>

Таким образом, в каталоге D:/www/Apache2/scripts мы разрешили исполнять CGI сценарии. Теперь мы должны "обьяснить" Apache, что файлы с определенным расширением это CGI скрипты. Делается это при помощи директивы AddHandler, например:

<Directory D:/www/Apache2/scripts>
   Options +ExecCGI
   AddHandler cgi-script .pl .cgi .exe
</Directory>

Второй вариант:

<Directory D:/www/Apache2/scripts >
   Options +ExecCGI
   SetHandler cgi-script
</Directory>

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

И, наконец, последний вариант - использование директивы ScriptAlias:

ScriptAlias   /cgi-bin/    "D:/www/Apache2/cgi-bin/"

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

Теперь про виртуальный хостинг. Виртуальный хостинг - это функция, которая позволяет на одном физическом сервере разместить несколько сайтов. Настраивается по IP, именам и портам.

При использовании виртуального хостинга по IP каждое имя сайта, расположенного на сервере представлено своим IP адресом. Это могут быть как различные физические интерфейсы, а соответствующие им адреса,так и виртуальные интерфейсы. Напомню, что все современные операционные системы позволяют назначать одному физическому интерфейсу более одного IP адреса. Кроме установки на сервере нескольких IP адресов нужно также корректно настроить преобразование имен через DNS либо файл %SystemRoot%\system32\drivers\etc\hosts. Если вы невнимательно читали раздел про установку Apache, напомню - NetBIOS имен Apache НЕ понимает. Для IP-based виртуального хостинга, при наличии двух IP адресов, секции VirtualHost могут выглядеть так:

<VirtualHost 192.168.0.1>
   ServerName   vhost1.net.local
   DocumentRoot   D:/www/Apache2/vhosts/vhost1
   ErrorLog   logs/vhost1_error.log
   AccessLog   logs/vhost1_access.log
</VirtualHost>

<VirtualHost 192.168.1.1>
   ServerName   vhost2.net.local
   DocumentRoot   D:/www/Apache2/vhosts/vhost2
   ErrorLog   logs/vhost2_error.log
   AccessLog   logs/vhost2_access.log
</VirtualHost>

Для тестирования обратитесь к серверу по адресу http://192.168.0.1. Если сервер по запросу разных адресов выдает разные сайты, значит настроено все правильно. Теперь вводите имена, соответствующие IP адресам ваших виртуальных хостов. Если что то не работает - проверяйте настройки вашего DNS сервера.

Конфигурирование виртуального хостинга (далее в/х) основанного на именах практически ничем не отличается от в/х основанного на IP адресах. Разница в том - что вам не требуется больше одного IP адреса. Файл конфигурации будет выглядеть следующим образом:

NameVirtualHost   192.168.0.1

<VirtualHost 192.168.0.1>
   ServerName   vhost1.net.local
   DocumentRoot   D:/www/Apache2/vhosts/vhost1
   ErrorLog   logs/vhost1_error.log
   AccessLog   logs/vhost1_access.log
</VirtualHost>

<VirtualHost 192.168.0.1>
   ServerName   vhost2.net.local
   DocumentRoot   D:/www/Apache2/vhosts/vhost2
   ErrorLog   logs/vhost2_error.log
   AccessLog   logs/vhost2_access.log
</VirtualHost>

Как видите - меняется заголовок директивы VirtualHost - теперь у нас используется один IP адрес. Также - добавилась директива NameVirtualHost, которая указывает Apache, что адрес 192.168.0.1 используется для name-based в/х. Директива ServerName указывает, какой виртуальный хост отдавать клиенту, имя хоста передается браузером в заголовке Host. Эта возможность появилась только в протоколе HTTP 1.1, HTTP 1.0 не поддерживает виртуальные хосты основанные на именах. Так что если на ваш сайт хотят посетители с совсем древними браузерами - не используйте этот вид в/х ;

При в/х по портам нужный пользователю контент определяется по номеру порта, на который он присоединился.

<VirtualHost 192.168.0.1:8888>
   ServerName   vhost.net.local
   DocumentRoot   D:/www/Apache2/vhosts/vhost8888
</VirtualHost>

Кроме того надо добавить директиву Port (либо Listen) для любого порта, который будет использоваться для в/х. В нашем случае

Port 8888

Один из вариантов использования в/х на портах - при настройке определенной части сайта через SSL.

Кроме того - не помешает установить директиву AddDefaultCharset, которая отвечает за кодировку страницы, в заголовке которой эта самая кодировка не указана. Поскольку мы используем Windows, логично будет установить умолчальной кодировкой CP1251

AddDefaultCharset   WINDOWS-1251

Обратите внимание, чтобы в httpd.conf присутствовала строка, "объясняющая" Apache, что, собственно, такое - WINDOWS-1251:

AddCharset   WINDOWS-1251   .cp-1251    .win-1251

На этом, непосредственно с Apache мы закончим. Нельзя объять необъятное. Поэтому со всем вопросами по настройке обращайтесь на http://httpd.apache.org

Ставим PHP

В случае PHP вопроса о версии у меня лично не возникает. PHP 5-ой версии, судя по документации и отзывам web разработчиков - большой шаг вперед. Как по возможностям, так и в быстродействии. Поэтому ставить будем PHP 5.

На этот раз придется забыть о "правильном" способе установки через Windows Installer, и вот почему. На www.php.net, естественно, есть соответствующий установочный пакет, однако там же написано, что включает он только CGI версию PHP. Никаких расширений, в том числе и модуля Apache данный пакет не содержит. Поэтому скачаем архив php-5.1.3-Win32.zip, и установим PHP вручную. Впрочем, вся установка заключается в распаковке содержимого архива в какой либо каталог. Я использовал путь D:\www\php. Теперь переименуем файл php.ini-dist (либо php.ini-recommended) в php.ini. Некоторые советуют копировать его в системный каталог Windows, однако я в этом смысла не вижу - зачем захламлять системный каталог, если PHP без труда находит свой конфиг в текущем для интерпретатора каталоге (в моем случае это D:/www/php/)

Теперь, собственно настройка. PHP в связке с Apache можно использовать двумя способами. Первый - это использовать соответствующий модуль Apache. Второй - использовать PHP как бинарные CGI приложения. Что лучше? Мы рассмотрим оба способа и решим для себя, что нам подходит больше.

Итак, для начала попробуем настроить PHP как CGI. Для этого, как мы помним, достаточно поместить в каталог, указанный директивой ScriptAlias наш файл, и указать в заголовке скрипта, каким интерпретатором его исполнять. Скрипт будет следующий:

#!D:/www/php/php-cgi.exe

   <?php       phpinfo( );    ?>

Обратите внимание, использовать нужно именно php-cgi.exe, а не php.exe.

Казалось бы - все просто. Однако если вы попробуете вызвать такой скрипт из строки бразуера, вы получите ошибку № 500. Как оказалось, бинарная сборка PHP для Windows сделана с опцией force-cgi-redirect. Эта опция предотвращает вызов скриптов непосредственно, по адресу вида http://host.local.net/cgi-bin/script.php. Вместо этого, PHP будет обрабатывать пришедший запрос только в том случае, если он был перенаправлен веб-сервером. Для решения это проблемы существует несколько вариантов:

• Мы можем изменить опцию cgi.force_redirect в файле php.ini:

  cgi.force.redirect = 0
  

  Этот способ представляется мне наиболее предпочтительным.

• Можем использовать перенаправление, как рекомендует официальный сайт PHP (см. http://www.php.net/manual/ru/security.cgi-bin.force-redirect.php). Для этого, добавляем следующие строки в файл

  ScriptAlias   /php/   "D:/www/php/"
  Action php-script   /php/php-cgi.exe
  AddHandler   php-script   .php
  

  Обращение к php скриптам в этом случае будет происходить по ссылке вида http://localhost/php/test.php. Теперь вы можете явно не задавать интерпретатор в скрипте. В этом случае, однако, скрипты придется располагать в том же каталоге что и интерпретатор php-cgi.exe, а именно - в D:/www/php. Это, на мой взгляд, ужасный вариант, хотя именно такой метод использования CGI PHP я видел в одной статье:

• Чаще делают наоборот - расположить интерпретатор в каталоге cgi-bin (или другом). Делать этого не рекомендую. Хотя бы - с точки зрения безопасности. Хотя такие настройки встречаются на некоторых бесплатных хостингах. Бог им судья:.

Будем считать, что вы тоже отдали предпочтение варианту №1. Правим php.ini и пробуем еще раз запустить наш скрипт. На этот раз http://localhost/cgi-bin/test.php выдаст нам весьма объемную страничку, с разнообразной информацией о вашей версии PHP и окружении. Обратите внимание на параметр Server API - его значение должно быть "CGI/FastCGI".

Какие плюсы у использования CGI PHP? Это, в первую очередь, исполнение скрипта от имени владельца что позволяет, при использовании suexec, обеспечить безопасность выполнения скрипта средствами ОС. Права на каталоги, дисковые квоты - все можно настраивать стандартными средствами Windows. Минусом является низкая, по сравнению с mod_php, скорость выполнение скрипта. Выходом может служить, например, использование модуля FastCGI. Подробнее смотрите http://www.fastcgi.com/.

Теперь рассмотрим настройку PHP как модуля Apache. Вся настройка укладывается в три строчки

LoadModule   php5_module   "D:\www\php\php5apache2.dll"
AddType   application/x-httpd-php   .php
PHPIniDir   "D:/www/php"

Убираем из нашего скрипта строку #!D:/www/php/php-cgi.exe, помещаем его в каталог, на который указывает директива DocumentRoot (или один из его подкаталогов) и вводим в браузере соответствующую ссылку, например http://localhost/test.php. Вы должны получить ту же страницу, что и в примере с CGI PHP, однако, обратите внимание - параметр Server API поменял значение на "Apache 2.0 Handler".

Как правило, рекомендуется использовать PHP как модуль Apache. В этом случае скрипты исполняются значительно быстрее, однако в этом случае труднее обеспечить безопасность работы сервера. Когда PHP используется как модуль Apache, он наследует права пользователя, с которыми был запущен веб-сервер (Для нашего случая - пользователя apache). Хотя пользователь, от имени которого работает Web сервер, не обладает большими правами, мы теряем гибкость в выставлении прав на файлы и каталоги, доступ к различным БД и т. п. Однако кое-что мы сделать все же можем:

Для начала нужно включить защищенный режим, изменив значение директивы safe_mode. Далее - устанавливаем следующие директивы:

• open_basedir. Эта директива ограничивает список файлов, которые могут быть открыты в PHP, указанным деревом директорий независимо от того, используется защищенный режим или нет. Каждый раз, когда скрипт пытается открыть файл, проверяется расположение файла. В случае, если он находится вне указанного дерева директорий, PHP отказывает в открытия файла. Все символические ссылки распознаются и преобразуются, поэтому обойти это ограничение при помощи символических ссылок невозможно. Такой подход защищает нас от подобных попыток несанкционированного доступа:

  $file = 'D:\www\Apache2\conf\httpd.conf;
  $fo = file($file);
  for($i = 0; $i < count($fo); $i++) 
  {
     echo $fo[$i]."\n";
  }
  

  Пример немного притянут за уши :, но идея понятна, я думаю. И вообще - нечего кому попало читать наш конфигурационный файл.

• safe_mode_exec_dir. В случае, когда PHP работает в защищенном режиме, данная директива не дает выполнять программы, находящихся вне заданной директории, функциями типа system или exec.
• doc_root. при включенном безопасном режиме, файлы вне директории, указанной этой директивой, не обрабатываются.
• user_dir. Имя каталога для PHP файлов в домашнем каталоге пользователя.
• safe_mode_allowed_env_vars. Значением этой директивы является список префиксов, разделенных двоеточиями. В защищенном режиме пользователь может модифицировать только те переменные окружения, имена которых начинаются с одного из указанных префиксов. По умолчанию, пользователю доступны переменные, которые начинаются с префикса PHP_: PHP_VAR=XXX. В случае, если этой директиве указать пустое значение, пользователь получит возможность модифицировать любую переменную окружения, что не есть хорошо!
• safe_mode_protected_env_vars. Эта директива содержит список переменных окружения, разделенных двоеточием, значение которых пользователь не сможет изменить, используя функцию putenv(). Значения этих переменных остаются защищенными, даже если их модификация разрешена директивой safe_mode_allowed_env_vars.

Отметим

Отдельно нужно сказать об одиозной директиве register_globals. Должен сказать, что написать эту статью меня побудило прочтение статьи, в которой рекомендовалось эту опцию включить :. НИКОДА не включайте register_globals. Эта опция позволяет "перемешать" переменные внутри скрипта и переменные передаваемые пользователем снаружи. Простой пример:

if (authenticated_user()) 
{
    $authorized = true;
}
if ($authorized) {
    include "/top-secret/burn-before-reading/data.php";
}

Если register_globals = on, то вызвав этот скрипт с параметром:

http://host.local.net/auth.php?authorized=1

мы легко обходим проверку.

К сожалению, многие разработчики игнорируют опасность использования данной директивы и включают ее. Аргументируется это обычно: да никак не аргументируется. Вроде бы, так им удобнее и проще. $_GET['var'] превращается просто в $var - действительно, печатать меньше надо :. Проблема в том, что подобная практика превращается в стиль программирования, соответственно, как грибы множатся дырявые проекты, создающие дурную славу языку. Начиная с версии 4.2.0 (!) по умолчанию глобальные переменные отключены, однако находятся умельцы, которые их включают. Мой вам совет - НЕ ДЕЛАЙТЕ ТАК НИКОГДА.

MySQL

Установка

У нас уже есть работающий Web сервер с поддержкой PHP. Осталась самая малость - установить и настроить MySQL. Вообще говоря, я не самый горячий поклонник MySQL, хотя мне встречались фанаты, доказывающие, что эта СУБД может ВСЕ! Всего она не может, поэтому если вы испытываете необходимость в действительно серьезной СУБД - используйте PostgreSQL, или, учитывая платформу - MS SQL. Благо в PHP есть соответствующие расширения. Я в свое время успешно скрещивал PHP с Oracle. Но в 90 (99?) процентах Web проектов с головой хватает возможностей MySQL.

Какую версию MySQL выбрать? Я буду использовать MySQL 4.x, а именно 4.1.18. Объяснять свой выбор не буду, скажу лишь, что некоторые известные мне фирмы (серъезные фирмы) до сих пор используют на хостингах 3.23 и этого вполне хватает. Версию 5.х использовать смысла не вижу. Да, в ней появились (наконец-то) хранимые процедуры, представления, нормальная (?) поддержка внешних ключей для всех типов таблиц: Однако, на мой взгляд, что бы не говорили фанаты MySQL - если нужны все эти возможности: см. выше - берем другие, серьезные СУБД, которые, более или менее, полноценно реализуют стандарты ANSI.

Впрочем, довольно лирики. Приступаем к установке. Ставить будем - как положено, при помощи пакета Windows Installer. Для этого качаем с сайта MySQL соответствующий архив (для моего случая - mysql-4.1.18-win32.zip), распаковываем, и запускаем находящийся там файл setup.exe.

Останавливаемся, как всегда на следующем окошке:

Рисунок 9

Мы с вами люди продвинутые, поэтому вбираем выборочную установку, как показано на рисунке. Попадаем на выбор компонентов:

Рисунок 10

Я обычно меняю путь установки, Компоненты оставляю по умолчанию, за исключением того, что ставлю Benchmark Suite - набор утилит для тестирования производительности базы. Отмечу, что он требует установленного в системе Perl. У меня он есть.

Все! Жмем Next и ждем, пока установщик закончит работу. После копирования всего, чего нужно, инсталлятор предложит вам создать аккаунт на MySQL.com. Этот шаг смело можете пропустить. После чего появится сообщение о завершении установки.

Рисунок 11

Галочку НЕ снимайте и нажимайте Finish. Теперь самое интересное :: Далее - читать не придется, в основном придется смотреть картинки. Согласитесь, это много приятнее. Итак:

Настройка

Как вы догадываетесь, настройка тоже будет выполняться традиционным для Windows мастером. Вот таким:

Рисунок 12

Нажимаем Next, после чего нам предложат выбрать тип настройки.

Рисунок 13

От предложения использовать стандартную конфигурацию мы с негодованием откажемся, и выберем конфигурацию подробную - "Detailed Configuration"

Появится следующее окно:

Рисунок 14

Тут нам предлагают определиться с типом сервера. От этого будет зависеть использование сервером MySQL ресурсов машины. На выбор дается три варианта:

• Developer Machine. Как следует из названия, использовать этот вариант следует, если вы ставите MySQL на машине разработчика, где крутится еще куча всякого нужного (и ненужного, как обычно у разработчиков) софта. В этом случае MySQL автоматически будет настроен на минимальное использование ресурсов.
• Server Machine. В этом случае предполагается, машина серверная и что на машине, кроме MySQL, крутится еще парочка серверных приложений. Например - Apache :. В этом случае, очевидно, MySQL будет настроен на совместное использование ресурсов с несколькими, потенциально ресурсоемкими приложениями.
• Dedicated MySQL Server Machine. Последний вариант - это монопольное использование ресурсов MySQL. Если у вас есть выделенная машина ТОЛЬКО под базу MySQL, я вас поздравляю - выбирайте этот вариант.

Я использую вариант Server Machine, поскольку девелопером не являюсь. При имеющихся ресурсах (1 Gb RAM, AMD64 3000+) все работает отлично.

Следующее окно предлагает нам выбрать тип хранилища базы:

Рисунок 15

• Mutltifunctional Database. Я обычно выбираю эту опцию. В этом случае создаются хранилища "общего назначения", с возможностью использования как InnoDB, так и MyISAM таблиц.
• Transactional Database Only. База оптимизируется для серверов приложений или Web приложений с большим числом транзакций. Основным движком для хранилищ становится InnoDB.
• Non-Transacional Database Only. Используется для большинства простых Web приложений, для сбора статистики и т. п. Активируется только движок MyISAM.

Что выбрать - ваше дело. Преимущества транзакционных таблиц InnoDB:

• Надежность.
• Можно сочетать несколько операторов и принимать все эти операторы одной командой COMMIT.
• Поддержка откатов
• Если произойдет сбой во время обновления, все изменения будут восстановлены (в нетранзакционных таблицах все внесенные изменения не могут быть отменены).
• Лучше обеспечивает параллелизм при одновременных обновлениях таблицы и чтении.

Преимущества нетранзакционных таблиц MyISAM:

• Скорость
• Меньший расход дискового пространства
• Для обновлений используется меньше памяти.

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

При выборе вариантов 1 и 2, вам предложат выбрать расположение табличных пространств InnoDB

Рисунок 16

Выбираем, жмем Next. Теперь будем выбирать, на какую загрузку мы рассчитываем:

Рисунок 17

Я, не мудрствуя лукаво, выбираю вариант номер 1 - Decision Support (DSS)/OLAP - ок. 20 одновременных подключений. Вариант Online Transaction Processing (OLTP) рассчитан на базы, которые обслуживают более 500 активных подключений. Вариант Manual Setting - позволяет выбрать число потенциальных конкурирующих подключений вручную.

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

Рисунок 18

Тут - на ваше усмотрение. В принципе, если Web сервер расположен на той же машине, можно и отключить галочку. Локальные взаимодействия идут через именованные каналы.

Внимание!!! Этап очень важный. Определение кодировки символов, которую MySQL будет использовать в таблицах по умолчанию. Выбирайте ее здесь, чтобы потом не мучится с ручной настройкой через утилиты командной строки. Опытным пользователям ручная настройка проблем не создаст, однако если есть возможность сделать проще, почему бы ею не воспользоваться? В общем случае - достаточно выставить все параметры так, как показано на рисунке 19 ниже:

Рисунок 19

Следующее окно (потерпите, осталось совсем немного):

Рисунок 20

Тут все понятно - ставить ли MySQL как службу, выбор имени службы (оставляем по умолчанию), автоматический либо ручной запуск службы ( на ваше усмотрение). Я также устанавливаю галочку Include Bin Directory In Windows PATH для того, чтобы удобнее было работать в FAR с утилитами командной строки MySQL.

Что касается установки в качестве службы - все что мы говорили про Apache применимо и здесь. В том числе - и смена пользователя, от имени которого выполняется служба MySQL.

Следующий шаг - настройка безопасности

Рисунок 21

Здесь мы устанавливаем пароль пользователя root (не забудьте его : ), можем разрешить (лучше не надо) доступ пользователя root с удаленной машины. Так же можем создать анонимный аккаунт, хотя нам этого делать не рекомендуют. Ну мы и не будем.

ВСЕ! Жмем Next, в следующем окне - Execute: и мы получаем настроенный MySQL сервер. Чтобы проверить, все ли мы сделали правильно - набираем в командной строке:

mysqladmin --pipe -uroot -p version status proc

и вводим по запросу пароль. Отмечу одну тонкость. Если вы делали все в точности как я, вам придется использовать еще одну опцию при запуске утилиты mysqladmin, а именно - опцию --pipe. Дело в том, что по умолчанию MySQL использует TCP/IP, а мы, если помните, его отключили, поскольку используем MySQL исключительно локально. Поэтому при подключении к базе нам надо явно, опцией --pipe, указать, что мы используем именованные каналы, следующим образом:

mysqladmin --pipe -uroot -p version status proc

Мы должны получить нечто следующее:

D:\www\MySQL\bin\mysqladmin.EXE  Ver 8.41 Distrib 4.1.18, for Win32 on ia32
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version      4.1.18-nt
Protocol version        10
Connection                 Named pipe: MySQL
UNIX socket             MySQL
Uptime:                    12 min 34 sec

Threads: 1  Questions: 8  Slow queries: 0  Opens: 11  Flush tables: 1  Open tabl
es: 5  Queries per second avg: 0.011
Uptime: 754  Threads: 1  Questions: 8  Slow queries: 0  Opens: 11  Flush tables:
 1  Open tables: 5  Queries per second avg: 0.011
--------------------------------------------------------------------------
| Id | User | Host      | db | Command | Time | State | Info             |
--------------------------------------------------------------------------
| 4  | root | localhost |    | Query   | 0    |       | show processlist |
--------------------------------------------------------------------------

Настройка PHP на работу с MySQL

Эта часть настройки AMP почему то тоже часто вызывает проблемы. На самом деле - все просто. Делаем в 3 этапа.

Как вы помните, мы оставили файл php.ini в каталоге PHP, указав модулю Apache путь к нему директивой PHPIniDir. Откроем этот файл и найдем там параметр:

extension_dir = "./"

Меняем значение на "./ext" (либо на полный путь к ext) - именно в каталоге ext находятся различные расширения PHP, в том числе и php_mysql.dll. Напомню, что ext - это подкаталог каталога, в который установлен PHP.

Второй шаг - находим в php.ini строчку

;extension=php_mysql.dll

и раскомментируем ее - т. е. уберем в начале строки точку с запятой :.

И третье - прописываем в системной переменной окружения PATH путь к каталогу, в который устанавливался PHP. У меня это, напомню - D:\www\php. Это нужно для того, чтобы PHP подхватил библиотеку libmysql.dll. Обращаю ваше внимание - это самая распространенная ошибка. Тут вам поможет наш старый знакомый - тестовый скрипт, который использует функцию phpinfo. Вызовите его и посмотрите секцию Apache Environment, переменную PATH. В этой переменной ОБЯЗАТЕЛЬНО должен присутствовать каталог, в котором лежит libmysql.dll.

На этом все. Чтобы проверить, что все работает, используем следующий скрипт:

<?php 
$db = mysql_connect(".", "root", "123") 
   or 
   die("Could not connect : " . mysql_error());
 mysql_select_db("test",$db) or die ("Could not select database");
 
  $date = mysql_query("SELECT CURDATE()") or die ("Query failed: " . mysql_error()); 
  echo mysql_result($date, 0); 
  mysql_close($db);
?>

При обращении скрипт выдаст вам текущую дату, если конечно все сделано правильно. Обратите внимание на первый параметр функции mysql_connect - в документации сказано, что это адрес хоста, к которому подключается скрипт и на котором запущена база MySQL. Поскольку мы не используем TCP/IP, то вместо адреса или имени хоста указываем точку - это значит, что подключение выполняется через именованные каналы. Если же вы не отключали использование TCP/IP - можете указать имя своего хоста или его адрес (в т. ч. и localhost либо 127.0.0.1).

Коротко о Perl

Нам понадобится установленный на машине дистрибутив Perl - ActivePerl для Windows. Традиционно - качаем MSI пакет с www.activeperl.com, запускаем мастера установки: все как всегда. Обращаю ваше внимание на следующее окошко:

Рисунок 22

Обязательно поставьте галочки так, как указано на рисунке. Более никаких сложностей и особенностей в установке ActivePerl нет - не в пример PHP :.

Проверить работу Perl CGI можно с помощью Perl скрипта, который устанавливается по умолчанию при инсталляции Apache в каталог cgi-bin, и называется printenv.pl. Поменяйте в заголовке путь к интерпретатору perl.exe на тот, который используете вы, либо просто напишите

#!perl 

не зря ведь мы при установке ставили галочку Add Perl to the PATH environment variable (рис. 22) ;). Теперь вызовите скрипт по ссылке http://localhost/cgi-bin/printenv.pl. Работает? Отлично.

Теперь, для общего развития, попробуем настроить наш Web сервер на обработку CGI сценариев специфическим для Windows путем. Помните, я говорил про директиву ScriptInterpreterSource? Давайте посмотрим, как можно ее использовать. Добавим в файл httpd.conf следующую строку:

 
ScriptInterpreterSource registry

Перезапустите Apache. Теперь удалим из файла cgi-bin\printenv.pl первую строчку, в которой указано, каким интерпретатором обрабатывать скрипт и попробуем этот сценарий вызывать. Все работает? Правильно. Взгляните на последний рисунок - напротив опции Create Perl File extension association стоит галочка. Это значит, в реестр сделана соответствующая запись о том, какой программой обрабатывать файл с определенным расширением, в данном случае - расширением pl. А теперь переименуйте printenv.pl в printenv.cgi и попробуйте вызвать скрипт из браузера еще раз. Моментально получите ошибку 500 - Apache не знает, каким образом обрабатывать данный сценарий.

На этом все. За рамками статьи осталось множество вопросов - настройка и использование mod_perl, настройка SSI, вопросы, связанные с аутентификацией средствами Apache, использованием файлов htaccess: Я уже не говорю о том, сколько можно написать про PHP и MySQL. Но, как говорил классик, "Нельзя объять необъятное". Данная статья, я надеюсь, даст вам стартовый толчок и убережет от типичных ошибок, которые делают новички.

Вопросы, поправки, замечания принимаются и приветствуются.

• e-mail: sql82@list.ru
• ICQ: 325540316

Автор: Андрей Товстик aka squirL
Источник: www.codenet.ru