Администрирование Web-сервера Apache и руководство по электронной коммерции. Администрирование сервера Apache и руководство по электронной коммерции

Резюме

Эта книга задумывалась как достаточно полное справочное руководство по Web-серверу Apache. Изложенный в ней материал предполагает определенный уровень компьютерной грамотности, но знания сетевых технологий при этом не требуется. Несмотря на то, что основная проблематика книги лежит в области электронной коммерции, в приложениях затронуты самые разнообразные проблемы и информация, необходимая для создания и функционирования Web-сервера. Это проблема соответствия имен и IP-адресов, детали протокола ТСР/IР и синтаксис регулярных выражений. Кроме того, в перспективе Web-администрирования затронуты темы создания системы электронных платежей и взаимодействия с базами данных.

Apache

Web-сервер Apache называют самым главным сокровищем движения "открытые программные системы". Его можно получить совершенно бесплатно. Он имеет отличные рабочие характеристики и поэтому используется более широко, чем все остальные Web-серверы вместе взятые. В настоящий момент 61,5 процентов всех Web-узлов в мире созданы с использованием сервера Apache.

Распространение "открытых программных систем" во многом аналогично процессу естественного биологического отбора - все ОС Linux и утилиты sendmail мира постепенно заполняют обложку журнала "Time" и перемалываются рекламной машиной в то время как легионы DOS-утилит медленно, но неотвратимо приближаются к устройству /dev/null истории. Сервер Apache никогда не был бы настолько популярен, если бы он не работал надежно.

Сервер Apache имеет еще одно преимущество не присущее остальным открытым системам: он так прост, что любой достаточно квалифицированный пользователь может овладеть им во всей его полноте. Видит Бог, я не являюсь большим поклонником Microsoft, но если передо мной поставить задачу выбора между ОС Linux и ОС Windows 2000, я бы мгновенно выбрал Windows - не успели бы вы и глазом моргнуть. И, между прочим, это нельзя рассматривать как неуважение к Linux: операционные системы, в частности многопользовательские, очень сложны. Единственный способ сделать их доступными для среднего пользователя - это упрощение.

К счастью, набор задач, которые можно решить с помощью сервера Apache, не настолько широк. Те из вас, кто начинает изучение сервера с неуверенностью и чувством страха перед новым, сможет с облегчением узнать, что сами по себе процедуры конфигурирования и обслуживания сервера не являются очень сложными. Суть освоения сервера, в зависимости от уровня вашего опыта, заключается в освоении основных концепций операционной системы, освоении команд, которые помогут заставить машину делать то, что вам нужно, и освоении жаргона. Если вы являетесь докой в одной из указанных проблематик, вас ожидает действительно приятный сюрприз.

Краткая история

Сервер Apache берет свое начало от сервера httpd , созданного Робом Макколом (Rob McCool ) в Национальном центре по применению суперкомпьютеров (National Center for Supercomputing Applications - NCSA). В 1995 году сервер httpd был самым популярным из существовавших тогда Web-серверов, но когда в 1994 Маккол покинул NCSA, развитие программы замерло. Поэтому для его поддержки и развития небольшая группа Web-администраторов сплотилась и образовала ядро организации, которая теперь хорошо известна как "Apache group". Ее членами являются

Брайан Белендорф (Brian Behlendorf )

Рой Т. Филдинг (Roy T. Fielding )

Роб Хартилл (Rob Hartill )

Дэвид Робинсон (David Robinson )

Клиф Скольник (Cliff Skolnick )

Рэнди Тербуш (Randy Terbush )

Роберт Тау (Robert S. Thau )

Эндрю Вильсон (Andrew Wilson )

При тесном сотрудничестве с Эриком Хагбергом (Eric Hagberg ), Фрэнком Петерсом (Frank Peters ) и Николасом Пиочем (Nicolas Pioch ), "Apache group incorporated" опубликовали исправления ошибок для httpd 1.3 , добавили несколько новых возможностей и в апреле 1995 выпустили очередную версию сервера под именем Apache 0.6.2.

С тех пор "Apache group", так они вскоре стали известны, посвятили себя настройке и усовершенствованию программного обеспечения. Сейчас имеются версии практически для всех основных операционных систем, хотя платформа Unix среди них является бесспорным лидером.

По своей сути Web-сервер Apache является конечным результатом грандиозного совместного труда группы программистов самой высокой квалификации. Возникает естественный вопрос, что их подвигло на работу над Apache вместо того, чтобы за хорошие деньги разрабатывать обычное коммерческое программное обеспечение. Здесь можно процитировать Web-узел apache.org :

"Сервер Apache существует для того, чтобы обеспечить надежные решения на коммерческом уровне с использованием протокола HTTP. Он является платформой, на основании которой как частные лица, так и организации могут создавать надежные системы и для экспериментальных, и критических задач. Мы верим, что публикуемый в Internet инструментарий, попадая в руки любому желающему или компаниям, занимающимся разработкой программных продуктов, смогут помочь сделать деньги, создавая дополнительные услуги по созданию специализированных модулей и оказывая услуги по технической поддержке. Мы понимаем, что "владение" рынком является экономическим преимуществом, а в программной индустрии это означает, что достаточно контролировать поступления платежей от пользователей программного продукта. Обычно такого положения вещей можно достичь "владением" протоколом, с помощью которого компании ведут свой бизнес. По той причине, что протоколы, использующиеся в Internet, являются "ничейными", он все еще остается полем действия больших и маленьких компаний. Таким образом, представляется возможным предотвратить "частное владение" протоколом и обеспечить существование надежного программного продукта, использующего протокол, доступного абсолютно бесплатно для всех компаний, а это недооценить невозможно."

Открытые программные средства

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

С точки зрения конечного пользователя это имеет смысл. Например во время работы над этой книгой у нас в офисе возникла масса проблем. Большое коммерческое программное обеспечение, которое работало на большой коммерческой же операционной системе перешло в безответное состояние. Оно перестало реагировать на ввод. Мы попытались отследить стек и некоторые другие вещи, но, за неимением на руках исходного текста, не смогли предпринять никаких существенных шагов. Поэтому была снята вся возможная диагностика и вместе с программным обеспечением передана на анализ поставщику. Совершенно естественно, проблема была решена, но это заняло две недели.

Следовательно, это очень сложная процедура. Если бы мы работали с открытым программным средством, то решение обязательно бы было найдено значительно быстрее. А в этом конкретном случае не было понятно, в чем, собственно, заключается проблема, и даже если бы мы знали причину, то определенно не смогли бы ее исправить. Мы полностью находились во власти нашего поставщика.

Конечно, работа с "открытыми системами" несколько необычна. Ведь в случае работы с открытым программным обеспечением нет никого, кто бы непосредственно отвечал за сопровождение открытой версии сервера Apache, нет бесплатного номера, по которому можно позвонить в 2 часа ночи, если что-то произошло с сервером и неизвестно, что делать. Поддержка существует в виде группы новостей и Web-узлов, но она приходит тогда, когда это удобно тому, кто осуществляет поддержку, а не тому, кому она нужна.

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

Я позволю себе предположить, что качество открытого текста обычно выше, чем у коммерческих продуктов. Ведь основной мотивацией разработчиков, работающих над "открытыми" продуктами, является любовь к программированию как к творческому процессу. Таким образом, при работе с "открытыми продуктами" можно получить самые лучшие образцы программ. Это разительно контрастирует с коммерческим продуктом, при работе с которым большая часть рабочего времени тратится на встречи, телефонные разговоры и, в конечном счете, инвентаризацию остатков.

Структура этой книги

Книга рассчитана на администраторов сервера Apache самой различной квалификации. Предполагается знакомство с основными концепциями, используемыми в компьютерной индустрии. Специальной подготовки для Web-администрирования не требуется. Для тех, кто совершенно не знаком с сервером Apache, имеется достаточно большой вводный раздел, в котором можно найти все, что необходимо для того, чтобы как можно скорее войти в курс дела.

После ознакомления с основными концепциями у вас может возникнуть желание побыстрее реализовать одну или две возможности сервера (например виртуальный хостинг). Главы этой книги скомпонованы в независимые отдельные очерки, посвященные самым различным темам. И с ними можно ознакомиться в произвольном порядке.

Вследствие своей открытости миру сервер Apache постоянно совершенствуется. Каждый день предлагаются и добавляются новые возможности. Иногда это усовершенствование базовых функций сервера, но чаще всего - новые или усовершенствованные модули. По этой причине, даже опытные администраторы время от времени должны расширять область своей компетенции. Надеюсь, что эта книга может предложить что-нибудь существенное вниманию даже опытных администраторов Apache.

Наконец, в приложениях обсуждается масса проблем, посвященных работе в сетях и программированию. Многие из них непосредственно с сервером Apache не связаны, но так как серверу Apache необходима работающая сеть, ваша карьера как Web-администратора скорее всего потребует определенных знаний по общему администрированию сетей и программированию. Приложения нельзя назвать всеобъемлющими, но они могут оказаться очень полезными.

Часть I, "Основы"

Часть I посвящена основным концепциям и методам администрирования сервера Apache. Она проведет вас через процедуру получения и инсталляции сервера Apache, настроенного в соответствии с вашими потребностями. Если вы не были знакомы с сервером Apache ранее, то, скорее всего, придется последовательно прочесть все четыре главы, а особенно внимательно главу 1, "Основные концепции". Информации, содержащейся в главах с 1 по 4, вместе с приложениями, будет вполне достаточно, чтобы смог начать работу любой новичок.

Часть II, "Администрирование Web-сервера"

В части II описаны более сложные функции сервера Apache. И если вы освоили основные концепции сервера, то можете пропустить главы, содержащиеся в этой части. Каждая глава задумывалась как самодостаточный очерк на тему, которая видна из самого названия главы.

Часть III, "Электронная коммерция"

В части III обсуждаются проблемы, имеющие непосредственное отношение к электронной коммерции, взаимодействию с базами данных и механизмами заработка денег с помощью Internet. Последняя глава этой части посвящена конкретному исследованию создания инфраструктуры коммерческого узла.

Часть IV, "Приложения"

В приложениях имеется информация, которая слишком узкоспециальна для того, чтобы быть включенной в остальные части книги (например синтаксис директив), или которую можно охарактеризовать как сопутствующую информацию (например приложение Е, "Концепция Unix"). Некоторые из них представлены в виде кратких обучающих очерков, другие - как простой справочный материал.

Как работать с этой книгой

В материале, изложенном в книге, можно встретить примеры команд и конфигурационных директив, обычно сопровождающиеся объяснениями, а иногда распечаткой. Подробной информации о синтаксисе директив и системных команд в основных главах нет. Такую информацию можно найти в приложениях, в частности в приложении A, "Основные директивы", и Б, "Прочие директивы". Надо надеяться, что по виду незнакомой вам команды можно определить ее применение.

Успех или неудача любой конкретной транзакции сервера Apache зависит от внутренней конфигурации сервера, передаваемого содержимого, конфигурации операционной системы и капризов сервисов поддержки сети. Поэтому нельзя сказать со всей уверенностью будут ли примеры, представленные здесь, работать на конкретной машине. Автор только может со всей ответственностью поклясться в том, что у него все они работали.

В некоторых случаях начальная тематика определенной главы была заложена в предыдущей главе. Например виртуальные узлы, о безопасности которых говорится в главе 8, "Безопасность", были рассмотрены в главе 4, "Запуск, перезапуск и остановка". Если смысл определенной конфигурационной директивы неясен, можно посоветовать обратиться к предметному указателю или прочесть о ее назначении в предыдущих главах.

Следует подчеркнуть, что в примерах команд операционной системы предпочтение делается в пользу команд ОС Unix в целом и команд ОС Linux в частности. В этом нет никакого совпадения, ведь при написании этой книги в качестве тестового сервера использовалась именно Linux-машина, некоторая часть работ проводилась на ОС Windows NT, Windows 95 и Mac OS X.

Одно из соглашений для ОС Unix, которым я очень горжусь, но которого нельзя встретить нигде в документации по серверу Apache, это практика объявления переменной окружения. В ней может храниться длинный путь к каталогу. В книге можно встретить системную переменную ОС Unix $APACHE , хранящую имя каталога, в котором установлен Web-сервер Apache. (В конфигурационных файлах этот каталог упоминается под именем ServerRoot .)

Типографские соглашения

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

Пример директивы с параметрами

Большие примеры конфигурационных файлов обычно выделяются отдельно.

ДирективаA

ДирективаB

ДирективаC

ДирективаD

Наконец, я попытался подразделить описание директив с применением заголовков, имеющих определенный смысл. В то время, как большинство директив сервера Apache имеют имена, которые дают достаточно опытному пользователю подсказку об их функциях (например, AddModule и Port), другие относятся к возможностям, присущим только Web-серверу Apache, и описать их с помощью двенадцати символов представляется достаточно затруднительным (например DocumentRoot).

Все вопросы, комментарии, исправления или предложения по усовершенствованию можно посылать по адресу [email protected] .

Гидра

Вместо послесловия, примите мои соображения о значении создания, изображенного на обложке этой книги. Это гидра, она была нарисована парнем по имени Том Пост (Tom Post ). Мифологические звери стали традиционной тематикой оформления обложек книг, посвященных открытым системам, издаваемых издательством "Prentice Hall". Таким образом, гидра является довольно подходящим олицетворением Apache. Ведь многочисленные экземпляры Apache, работающие одновременно на одном компьютере, очень напоминают многочисленные головы гидры. Разве это не так? За столь удачный выбор мифологического образа с острыми зубами хочется поблагодарить моего редактора Майлса Уильямса (Miles Williams ), а также за то, что он не надоедал мне всякими единорогами, нимфами и прочей нечистью.

HTTPS (HyperText Transfer Protocol Secure) - это не самостоятельный протокол, а развитие HTTP (HyperText Transfer Protocol) в сторону безопасности. То есть, к обычному HTTP прикрутили механизм шифрования передаваемых данных. Шифрование реализуется с помощью SSL (Secure Sockets Layer). Как это работает на практике?

При подключении к серверу по протоколу HTTPS (cтандатный порт TCP 443), браузер с сервером сначала здороваюся, обмениваются поддерживаемыми алгоритмами шифрования, договариваются какой алгоритм будут использовать. Сервер отдает браузеру открытый ключ (сертификат), который будет использоваться для шифрования. Договариваются о взаимовыгодном сотрудничестве короче. Обычно им удается договориться и они устанавливают защищенное соединение. Происходит все это на шестом уровне модели OSI. И только после этого уже вступает в действие HTTP, который работает на прикладном - седьмом уровне.

Для активации поддержки HTTPS на уже установленном Apache требуется: , , и (Или ).

Генерация самоподписного сертификата

Заходим в директорию к апачу где хранятся ключи.

# cd /etc/apache2/ssl

Создаем самоподписный сертификат и новый ключ сервера без пароля:

# openssl req -new -newkey rsa:1024 -nodes -keyout citename-CA.key -x509 -days 365 \
" \
-out citename-CA.crt

Аргументы команды:

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

# chmod 600 /etc/apache2/ssl/*.crt

Настройка сервера apache

Включаем поддержку SSL в строке опций сервера. Для этого добавим туда -D SSL

Конфигурация виртуального хоста

Конфигурируем файл виртуального хоста. Можно и дефолтный виртуальный хост, если включена его поддержка в Apache.

Осталось перезапустить Apache

# /etc/init.d/apache reload

Настройка нескольких виртуальных хостов для работы с SSL

Например, есть три хоста с одинаковым IP адресом: citename.ru, shop.citename.ru, cite-name.ru. Для них нужно поднять три сайта с разным содержимым и доступом к ним через HTTPS.

Создаем для них самоподписные сертификаты.

# cd /etc/apache2/ssl
# openssl req -new -newkey rsa:1024 -nodes -keyout citename-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=Sales/CN=citename.ru/emailAddress=Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. " \
-out citename-CA.crt
# openssl req -new -newkey rsa:1024 -nodes -keyout shop-citename-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=Sales/CN=shop.citename.ru/emailAddress=Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. " \
-out shop-citename-CA.crt
# openssl req -new -newkey rsa:1024 -nodes -keyout cite-name-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=IT/CN=cite-name.ru/emailAddress=Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. " \
-out cite-name-CA.crt
# chmod 600 /etc/apache2/ssl/*.crt
# chmod 600 /etc/apache2/ssl/*.key

И конфигурируем виртуальные хосты.

До сих пор наше повествование ограничивалось простейшими случаями. Это когда на одной узловой машине установлен один экземпляр сервера Apache и он обслужи вает только один IP адрес для обработки запросов пользователей, поступающих на один Web узел. В реальной практике такой вариант маловероятен. Более вероятно существование десятков, если не сотен узлов, каждый из которых имеет специфиче ские требования к ресурсам и конфигурации.

Сервер Apache имеет возможность конфигурирования для поддержки множества IP адресов (см. директивы BindA ddress и Listen). Для каждого IP адреса он может поддерживать множество портов1 . Каждая комбинация сопровождаемых IP адресов и портов имеет один или много узлов. В этой главе детализируется три метода настрой ки сервера Apache для обеспечения хостинга нескольких узлов:

1. Домашние страницы пользователей.

2. Виртуальный хостинг по имени.

3. Виртуальный хостинг по IP адресу.

Первый метод - пользовательские домашние страницы - самый простой, но он вряд ли удовлетворит пользователей, которые хотят платить деньги за эту услугу. Этот метод за ключается в том, что в каталоге User создаются пользовательские подкаталоги, и все за просы к домашним страницам сервер Apache перенаправляет на каталоги пользователей.

1 Термины IP адрес и порт детально обсуждаются в приложении А, "Основные директивы".

Виртуальный хостинг является возможностью сервера Apache, которая позволяет одно му серверу обрабатывать запросы к множеству различных Web узлов. Сервер настраивается таким образом, чтобы различать запросы виртуальных узлов по имени, IP адресу или по тому и другому одновременно. Сервер Apache можно сконфигурировать, чтобы на разные узлы действовали разные директивы (и, следовательно, вели себя по разному). Для этих целей используется директива virtualHost. По умолчанию виртуальные узлы наследуют свойства основного экземпляра сервера. Однако почти все основные директивы сервера могут быть или проигнорированы или дополнены с помощью директивы virtualHost.

Виртуальный хостинг очень популярен из экономических соображений. От десят ков до тысяч узлов с трафиком от самого низкого до среднего могут поддерживаться с помощью лишь одного физического узла. Доменные имена рекомендуется регистри ровать. Обычно взимается плата за несколько имен. Виртуальный хостинг осуществ ляется по имени или по IP адресу.

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

Вероятно, вы уже догадались, что третий метод, в иртуальный хостинг по IP адресу, заключается в том, что одна машина является узлом для множества IP адресов. Ранее это был один единственный способ множественного хостинга и сейчас он все еще ос тается единственным решением для обеспечения трафика, поступающего от старых версий броузеров2 . IP адреса могут связываться с несколькими сетевыми картами (NIC). С другой стороны, современные операционные системы позволяют поддержи вать множество IP адресов с помощью одной сетевой карты.

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

5.2. Домашние страницы пользователей

При применении этого метода испол ьзуется директива UserDir для того, чтобы разместить URL в некоторых каталогах системы, как это показано на рис. 5.1.

5.2.1. Директива UserDir some_directory

Эта директива предназначена для того, чтобы показать, что Web содержимое будет найдено в конкретном подкаталоге корневого каталога пользователя. Когда работает эта директива, сервер Apache принимает запросы в виде:

http://www.example.com/~userguy

и использует системные ресурсы для определения корневого каталога пользователя userguy. Скажем, он находится в каталоге /home, таким образом, путь к корневому каталогу пользователя userguy будет составлять /home/userguy. Если действует ди ректива, аналогичная

UserDir some_directory,

сервер Apache будет искать отображаемое Web содержимое в подкаталоге some_directory каталога /home/userguy 3 . В соответствии с логикой нашего приме ра это приведет в каталог

/home/userguy/some_directorу

2 Броузеры, реализующие стандарты HTTP меньше, чем 1.1, из за причин, о которых мы расскажем позднее, не могут поддерживать хостинг по имени.

3 Значение по умолчанию public_html

Рис. 5.1. Домашние страницы пользователей

5.2.2. Директива UserDir /an/absolute/path

Есть способ, заключающийся в задании абсолютного пути к определенному ката логу, в котором хранится Web содержимое всех пользователей. Этот метод предпола гает, что каждый пользователь имеет свой собственный подкаталог в каталоге, задан ном директивой UserDir.Например, если сервер Apache получает URL

http://www.example.com/~timmy/x flies.html,

когда действует директива UserDir /var/user/webspace,

то сервер возвращает /var/user/webspace/timmy/x files.html

5.2.3. Директива UserDir /an/absolute/*/with/wildcard

Из всех трех вариантов директивы UserDir этот вариант самый вероятный претендент на применение. В этом методе задается абсолютный путь к каталогу, где пользователи хра нят свои Web документы. Здесь вместо имени пользователя указывается звездочка "*". И когда сервер Apache получает запрос к определенному пользователю

http://www.example.com/~susie,

он анализирует имя пользователя (об этом свидетельствует символ "~") и замещает звездочку именем пользователя. Например, если в настоящий момент действует ди ректива UserDir:

UserDir /home/*/public_html,

сервер Apache переадресует этот URL в каталог /home/susie/public_html

5.3. IP$адреса и порты

Перед тем как сконфигурировать виртуальный хостинг, необходимо настроить сервер на прослушивание соответствующих портов. По умолчанию сервер Apache следит за IP

портом 80 для всех IP адресов, имеющихся на сервере. В соответствии с задачами, стоя щими перед сервером, этого может быть достаточно. Директивы, описанные в этом разде ле, позволят вам производить настройку ваших адресов и мониторинг порта.

5.3.1. Определение IP$адресов:

директива BindAddress address

Директива BindAddress задает серверу Apache режим мониторинга определенного IP адреса или целого ряда адресов. Следующая директива устанавливает режим про слушивания сервером Apache адреса 192.168.1.10:

BindAddress 192.168.1.10

Чтобы прослушивались все активные IP адреса, нужно задать команду

5.3.2. Определение одного IP$порта: директива Port portnum

По умолчанию сервер Apache прослушивает IP порт 80 заданного IP адреса. Это правильно, так как порт 80 является "стандартным портом", определенным протоко лом HTTP, и поэтому к нему будет обращаться наибольшее число Web броузеров.

С другой стороны, может потребоваться изменить эту стандартную установку и, таким образом, ограничить доступ только теми броузерами, которые знают прослуши ваемый порт. Типичнымпримером такого использования сервера Apache является ис пользование его в качестве proxy-сервера, а еще такой режим работы может приго диться для настройки корпоративной intranet. Отметим, что в отличие от директивы Listen (которая будет рассмотрена в следующем разделе), только одна директива Port может быть применена в один момент времени. Например, чтобы сервер Apache начал прослушивать порт 4444, необходимо задать директиву

5.3.3. Определение одного или более IP$порта: директива Listen

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

Кроме того, директива Listen может использоваться для определения IP адресов. Предположим, что в вышеприведенном примере прослушивается IP адрес 192.168.1.2. Следующие команды Listen будут иметь аналогичный эффект:

Listen 192.168.1.2:80

Listen 192.168.1.2:

5.3.4. Настройка множества IP$портов

Можно предложить два метода поддержки множества IP адресов на одной системе:

Купить и установить несколько интерфейсных плат.

В некоторых операционных системах для установки мониторинга одной интерфейс ной платы множеством IP адресов можно воспользоваться командой ifconf ig.

Совершенно очевидно, что идея покупки множества интерфейсных карт не нуждается в комментариях. Чего нельзя сказать об использовании команды ifconfig . Команда ifconfig (interface configurationконфигурация- интерфейса) выполняет две функции:

Отображение информации о конфигурации существующего интерфейса.

Изменение или добавление информации о конфигурации интерфейса.

Первая функция имеет неоспоримую пользу, но не относится непосредственно к серверу. Для этого достаточно командой ifconfig определить имя нужной карты.

/home/root> ifconfig eth0

В результате будет получен следующий ответ (конечно, в зависимости от типа системы):

eth0 Link encap:Ethernet HWaddr 0 0: 2 0: 7 8: 1 7: 9 A: Е В

inet addr:192.168.1.1 Beast:192.168.1.255 mask:255 . 255 . 255 . 0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:!

RX packets:260652 errors:0 dropped:0 overruns:0 frame:0

TX packets:565370 errors:0 dropped:0 overruns:0 carrier:0 collisions:0

С другой стороны, команду ifconfig иногда можно использовать для ввода новой информации. Вот команда, которая создает виртуальное устройство eth0:l. Оно бу дет отслеживать различные IP адреса (192.168.100.2).

/home/root> ifconfig eth0:1 192.168.1.2 netmask 255 . 255 . 255 . 0

В случае успешного конфигурирования, устройство et h0:1 ведет себя так, будто оно присутствует в действительности, отвечая на запросы команды pings и запросы пользователей, как если бы вы и правда потратили 50 долларов на новую карту.

5.4. Виртуальный хостинг по имени

Виртуальный хостинг по имени является относительно новой доработкой стандарта HTTP. По этому методу множество различных доменных имен ассоциируется с одним IP адресом. Все доменные имена зарегистрированы, и все запросы перенаправляются к од ному и тому же IP адресу. Сервер отличает один запрос от другого с помощью заголовка HOST, настроенного для каждого виртуального узла, сконфигурированного на сервере.

Это, без всяких сомнений, хорошее решение несколько снизило скорость истоще ния адресного пространства Internet. Проблема заключается только в том, что с заго ловком HOST работают только броузеры, удовлетворяющие стандарту HTTP 1.1. По этому получить доступ к таким виртуальным узлам в помощью устаревших броузеров будет довольно проблематично.

Процесс настройки такого хостинга можно разбить на три этапа:

Информирование DNS о том, что уже существующий IP адрес также имеет от ношение к имени нового виртуального узла.

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

5.4.1. Система доменных имен и регистрация имени

Система доменных имен (DNS) - это своеобразный аналог желтых страниц Inter net. Это распределенная база данных IP адресов и связанных с ними доменных имен. Без системы доменных имен или чего нибудь подобного Internet не смог бы сущест вовать. Без базы DNS, задаваемый в броузере URL является совершенно бесполезным до тех пор, пока соответствующий ему IP адрес не будет найден в базе данных DNS.

Учитывая продолжающееся расширение Internet, хороших доменных имен остается все меньше и меньше. Уже все возможные трехбуквенные комбинации имен доменов исчерпаны, так что по этому поводу даже не стоит беспокоиться. Большинство анг лийских слов уже тоже использованы. Запрос по получению новых доменных имен можно направлять по адресу http://www.networksolutions.com (см. рис. 5.2).

Рис. 5.2. Регистрация доменного имени

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

DNS представляет собой распределенную базу данных, т.е. ее нельзя найти всю сразу на одном сервере. Запрос пользователя может обойти много серверов, и только после этого будет найдено совпадение. Побочный эффект заключается в том, что прописка нового доменного имени по всемирной сети DNS занимает часы, а иногда даже и сутки.

5.5. Настройка виртуального хостинга по имени на сервере Apache

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

1. С помощью директивы NameVirtualHost определить IP адрес, который будет использоваться для виртуального хостинга.

2. С помощью пары директив Vir tualHost выделить директивы, которые будут иметь отношение только к определенному виртуальному Web узлу.

5.5.1.НазначениеIPдля виртуальногохостингапоимени: NameVirtualHost

С помощью директивы NameVirtualHost задайте IP адрес виртуального узла в конфигурационном файле httpd.conf. Например директива вида

NameVirtualHost 192.168.1.1

предупредит сервер Apache о том, что существует возможность получения запроса по ад ресу 192.168.1.22 к серверам, отличающимся от стандартного сервера. Чтобы сервер Apache смог извлечь какую то пользу из этой информации, необходимо задать с помо щью скобок VirtualHost директивы, специфические для виртуального хостинга.

Номер порта можно задать с помощью директивы NameVirtualHost.

NameVirtualHost 192.168.1.1:80

Виртуальный хостинг по имени работает только для Web броузеров, удовлетво ряющих стандарту HTTP 1.1 или выше. Причина этого заключается в том, что стан дарт HTTP 1.1 имеет директиву HOST, которая задает имя узла (и порта). Отсюда Web броузер берет информацию. Без этой директивы сервер не сможет определить, какой же из Web узлов можно ассоциировать с IP адресом, запрашиваемым пользователем.

5.5.2. Запуск виртуального хостинга: директива VirtualHost

Директива VirtualHost является "операторной скобкой". Она применяется только попарно и ограничивает начало и окончание директив, занимающихся виртуальным хостингом. Продолжая пример, мы имеем:

ServerName www.examplel.org

DocumentRoot/some/other/directory

Необходимо обратить внимание на то, что директивы, находящиеся внутри скобок , относятся только к виртуальному узлу, заданному директивой ServerName. Директивы, заключенные в скобки , отменяют стандарт ные установки, действующие для данного IP адреса. Ограничений на количество ди ректив, которые могут быть заключены в операторные скобки , нет. Но есть определенные разумные пределы (см. табл. 5.1).

Таблица 5.1. Директивы, неприменимые в виртуальном хостинге

5.5.3. Виртуальный узел по умолчанию

Использование ключевого слова _default_ вместо IP адреса свидетельствует о том, что заданная вами конфигурационная информация будет использоваться по умолчанию в случае, когда поступающие запросы не смогут найти нужный виртуаль ный узел среди существующих узлов. Делать это не обязательно, но сделав это, вы не пожалеете. Текущая конфигурация сервера может быть настолько простой, что это со вершенно не потребуется, но при всем при этом такой стандартный подход может оказаться достаточно полезным.

Стандартные директивы...

5.5.4. IP$адрес или доменное имя?

При более внимательном рассмотрении команд, описанных в этой главе (VirtualHost, BindAddress и т.д.), можно заметить, что многие из них скорее предна значены для определения доменных имен, чем IP адресов. Например набор директив

Различные директивы...

технически правильный и действительно более читабельный, чем при использовании IP адреса. К сожалению, это отрицательно сказывается на производительности. При хостинге по имени сервер Apache, каждый раз получая запрос, будет вынужден искать заданное имя в DNS, а это существенно замедляет работу.

5.6. Виртуальный хостинг по IP$адресу

Виртуальный хостинг по IP адресу не предполагает, что пользовательские броузеры бу дут посылать заголовок Host (этохарактерно только для броузеров, совместимых со стан дартом HTTP 1.1), и, следовательно, в зависимости от требований к узлу, не может пре тендовать на исключительность. Вот этапы процессавиртуального хостинга по IP адресу:

1. Создание и регистрация нового имени виртуального узла.

2. Настройка системы таким образом, чтобы она имела возможность отслеживать новые IP адреса (см. раздел "IP адреса и порты" в этой главе).

3. Задание в DNS связи между новым IP адресом и именем узла.

4. Сообщение серверу Apache о том, как можно обработать запросы, направлен ные к виртуальному узлу.

Большая часть этих требований уже обсуждалась. Сведения о том, как создаются и регистрируются новые имена узлов, можно найти в разделе "Виртуальный хостинг по имени" в этой главе. Процедура создания нового имени является аналогичной. Одна ко при регистрации имени нового виртуального узла с использованием DNS необхо димо создать новый IP адрес.

Конфигурирование системы с тем, чтобы она могла отслеживать новые IP адреса, обсуждается в разделе "IP адреса и порты" ранее в этой главе.

Основное различие между конфигурированием сервера Apache для виртуального хостинга по имени и виртуального хостинга по IP адресу заключается в том, что во втором случае не требуется прибегать к услугам директивы NameVirtualHost. Чтобы создать узел с именем www.example2.com по адресу 192.168.1.2, необходимо:

ServerNamewww.example2.com

5.6.1.Комбинированиевиртуальных узлов, базирующихся на именах и на IP$адресах

Нет причины, которая могла бы воспрепятствовать объединению обеих подходов на одной системе. Сначала создайте весь нужный виртуальный хостинг по адресу, а потом задайте соответствие адресов для виртуального хостинга по имени. Если дирек тива NameVirtualHost хоть один раз применялась к определенному IP адресу, то этот адрес уже будет потерян для виртуального хостинга по адресу.

5.7. Что нужно настраивать для виртуального хостинга

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

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

Как минимум, необходимо задать директиву ServerName для каждого виртуаль ного узла:

ServerName www . site2 . com

Другим необходимым элементом является директива Docum entRoot, задающая старто вую точку для любого поиска. Я думаю, что в ситуации, когда для Web документов раз личных клиентов отводятся отдельные каталоги, это будет бесспорно уместно.

DocumentRoot /home/site2

Директива Serve rAdmin позволяет указать точный почтовый адрес администрато ра каждого виртуального узла. Это адрес, куда будет поступать почта с сообщениями о проблемах, возникающих при работе сервера.

ServerAdmin [email protected]

Можно упомянуть также файлы ErrorLog и TransferLog, так как иханализ уп рощает отладку и анализ трафика. Однако следует помнить, что Unix системы (включая и ОС Linux) обычно накладывают ограничение на число файлов, открывае мых отдельными процессами. Назначение отдельного регистрационного файла для каждого виртуального узла может быстро превысить этот предел. К сожалению, я вы нужден попросить вас обратиться к системной документации, чтобы узнать, каким образом можно повлиять на ограничения, накладываемые каждой конкретной систе мой. При наличии таких либо подозрений, проверьте файл syslog вашей системы. ОС Unix очень хорошо фиксирует нарушения такого типа.