Глава 32 . Построение собственного Web-сервера
Вы уже достаточно долго изучаете Linux и сейчас готовы к обзору наиболее популярного из применений этой операционной системы: использования Linux для создания Web-серверов небольшого и среднего масштабов.
Linux широко используется для разработки и поддержки Web-серверов по нескольким причинам.
В этой главе рассмотрены основные принципы превращения персонального компьютера под управлением Linux в Web-сервер для сайта Intranet или Internet. Глава начинается с обзора задач Web-сервера и основных Web-серверов, доступных под Linux.
Приведена подробная информация по установке, конфигурированию и сопровождению Web-сервера Apache - наиболее популярного Web-сервера для Internet, который в настоящее время поставляется с Red Hat Linux 7.1.
В конце главы поэтапно рассмотрен пример построения простой Web-странички с использованием Apache. Глава позволит пользователю уверенно экспериментировать с различными Web-серверами, работающими под Linux. Более того, пользователь сможет самостоятельно создать свой Web-сайт, используя Linux и Apache.
Что такое Web-сервер
Пользователи, которые когда-либо использовали Web, вероятнее всего, слышали термин "Web-сервер", но все же они не имеют четкого представления о том, для чего нужен Web-сервер.
Очень часто этот термин имеет двойное значение, обозначая и компьютерное оборудование, и программное обеспечение, выполняемое на компьютере. Корректно использовать термин "Web-сервер" для обозначения программного обеспечения, запускаемого для ответа на запросы Web-клиентов, например Web-браузеров.
Программное обеспечение Web-сервера предназначено для отображения документов, использующих HTTP (Hypertext Transfer Protocol - Протокол передачи гипертекста) и доступных на Web-сайте в ответ на запросы клиентов. Web-сайт использует программное обеспечение Web-сервера.
Последовательность действий следующая: клиент запрашивает документ при помощи URL; Web-сервер принимает запрос, находит в системе URL, соответствующий заданному, - физический файл (который может быть файлом HTML или файлом другого типа). Убедившись, что клиент имеет разрешение на получение файла, Web-сервер возвращает файл клиенту. Кроме того, обычно Web-сервер ведет запись протокола: кто и какой документ запрашивал, и сколько было запросов, что позволяет получить статистику для определения популярности Web-сайта.
Больше, чем извлечение файлов
Описанная последовательность действий чрезмерно упрощена, но ее цель - описать работу, выполняемую многими Web-серверами.
Конечно же, путешествуя по Web, легко осознать, что Web - это гораздо больше, чем набор статических документов, которые Web-сервер посылает на запросы Web-браузеров. Для запроса информации с сервера или предоставления информации организации-владельцу сервера могут использоваться формы. Можно заказать товары, проверить кредитные карточки и выполнить другие самые разнообразные деловые операции.
Для выполнения таких функций современные Web-серверы должны не только отвечать на HTTP-запросы. Web-серверы обычно обеспечивают два механизма взаимодействий.
Интерфейс простого шлюза (CGI - Common Gateway Interface)
Для придания интерактивности Web-серверу наиболее широко применяется механизм CGI. При использовании CGI к HTTP-протоколу добавляется очень простое расширение для запроса статических файлов.
CGI обеспечивает стандартизованный метод запуска программы на сервере и передачи программе данных из формы на обработку. Эти программы можно писать практически на любом языке программирования или сценариев. Обычно используются С, Perl и Java.
Когда пользователь запрашивает CGI-программу (возможно, при предоставлении заполненной формы или щелчке на ссылке к программе) Web-сервер передает данные пользователя CGI-программе и ожидает, пока программа вернет результат. Данные, возвращенные CGI-npor-раммой, сразу же передаются клиенту тем же образом, каким возвращается браузеру содержимое статического файла. Правильное формирование данных, возвращаемых браузеру, и обработка непредвиденных обстоятельств входит в задачу CGI-программы.
В целом, технология CGI разработана достаточно хорошо. Простота метода передачи данных от сервера в CGI-программу и способ построения результирующих данных, которые программа возвращает серверу, означает, что можно создавать несложные CGI-программы, не имея большого опыта программирования.
Изменять и тестировать CGI-программы несложно, так как для их написания можно использовать популярные языки сценариев, например Perl.
То, что CGI-интерфейс является стандартом, означает, что сценарий CGI или программа, написанная для одного Web-сервера Linux, будет выполняться на любом другом Web-сервере Linux. Возможно, этот сценарий или программа будут выполняться и на любом другом сервере Unix, если они написаны на языке, интерпретируемом в соответствующих операционных системах.
Несмотря на все преимущества, CGI имеет серьезные недостатки, делающие его непривлекательным для некоторых Web-сайтов. Два главных недостатка относятся к категориям безопасности и скорости.
С момента появления Web в интерфейсе CGI были обнаружены значительные просчеты, позволяющие опытному злоумышленнику получить доступ к системе с Web-сервером, если сценарий плохо написан. Поэтому, использование CGI нежелательно на тех Web-серверах, где безопасность данных является первостепенной задачей - на большинстве корпоративных Internet и Intranet-серверов и особенно на сайтах, которые реализуют финансовые операции и продажу по кредитным карточкам в режиме on-line.
Интерфейс CGI не очень эффективен. Web-сервер запускает один или несколько процессов, которые отвечают на запросы клиента. Браузер запускает дочерние процессы для CGI-программы. передает данные новому процессу и ожидает его завершения. На загруженном сайте это может привести к большому числу новых процессов, нуждающихся в запуске за короткий период времени, особенно если CGI-сценарии используются интенсивно. Каждый запрос для CGI-программы приводит к запуску отдельного процесса.
Этот неэффективный способ обработки большого количества данных и запросов является причиной того, что многие ведущие Web серверы снабжены собственными API (Application Program Interfaces - Программный интерфейс приложений) для написания программ сервера.
Программный интерфейс приложений (API - Application Program Interface)
Программные интерфейсы приложений (API) предоставляют методы написания программ, хорошо интегрированных в Web-сервер и не требующих новых процессов для каждого запроса.
API позволяет разрабатывать Web-приложения для обработки большего количества запросов по сравнению с аналогичными CGI-решениями. Кроме того, API-методы меньше критикуются в отношении безопасности.
API-программы обычно выполняют те же функции, что и CGI-программы, например обработку информации, содержащейся в формах, доступ к базам данных и проверку кредитных карточек.
Наибольшим недостатком API является то, что они привязывают приложение к конкретному Web-серверу. Перенос приложения на другой сервер может потребовать значительных изменений в программе и, чаще всего, для больших приложений невозможен.
Помните: сервер должен быть хорошо протестирован на предмет безопасности, производительности и гибкости перед созданием на сервере большого приложения, использующего встроенный в сервер API.
Web-серверы для Linux
Web впервые появился в мире Unix, поэтому неудивительно, что под Unix-платформы написано наибольшее количество существующих Web-серверов.
Все что существует под Unix, доступно для Linux, в том числе и Web-серверы Unix. Большинство Web-серверов Linux бесплатны. Наиболее известны следующие Web-серверы Linux.
Наряду с бесплатными серверами существует несколько коммерческих серверов:
Apache
По некоторым подсчетам Apache является наиболее широко используемым программным обеспечением Web-серверов. Apache означает "A Patchy Server", т.е. "Сервер с заплатами". Этот Web-сервер возник из попыток залатать NCSA httpd, один из первоначальных Web-серверов, чтобы исправить некоторые ошибки и добавить больше функций.
В результате появился Apache как некоммерческая альтернатива для систем Unix. Недавно он был перенесен в Windows и может использоваться как Web-сервер на системах с Windows NT/2000.
Apache предлагает многочисленные возможности, которые делают его привлекательным для системных администраторов Unix. Помимо использования конфигурации, основанной на первоначальных конфигурационных файлах NCSA httpd, для Apache доступен исходный код программы. Он разрабатывается коллективно, как и многие другие приложения для среды Linux.
Apache предлагает собственный API, являющийся альтернативой CGI (который тоже поддерживается в Apache). Можно использовать API при создании сменных (plug-in) модулей для решения множества задач. Из доступных модулей хотелось бы выделить следующие.
Оригинал исходного кода последней версии Apache, включая откомпилированные выполняемые модули для многих различных систем, в том числе и Linux, доступен на www. apache. org. В Red Hat Linux 7.1 Apache является Web-сервером по умолчанию.
NCSA httpd
NCSA httpd является одним из первых двух Web-серверов (наряду с Web-сервером Сеrn), на которых начинал строиться Web. NCSA httpd разработан в Национальном Центре Суперкомпью-терных Приложений при Университете штата Иллинойс, расположенном близ городов Urbana и Champaign, который также является родиной Mosaic, первого графического Web-браузера, открывшего Web путь к всемирной популярности.
NCSA httpd предлагает основной набор функций для обеспечения работы всех Web-сайтов, кроме наиболее требовательных. Этот набор включает встроенную поддержку для нескольких хостов, основную и упрощенную аутентификацию, управление доступом на уровне каталогов, включения со стороны сервера и полную поддержку CGI.
Оригинал исходного текста и готовый двоичный код NCSA httpd доступен по адресу hoohoo. ncsa.uiuc.edu.
W3C/Cem
Сервер Jigsaw - это построенный средствами Java преемник сервера Сегп, который был одним из первых Web-серверов. Как сервер, полностью построенный средствами Java, он может работать под управлением любой операционной системы, поддерживающей этот язык, включая Unix/Linux и Microsoft Windows.
Jigsaw строится с использованием нескольких разновидностей Java-объектов, включая:
Resources (Ресурсы). Ресурсы определяют, что отображается на Web-странице, включая статические объекты (текст, файлы иллюстраций) и динамические объекты (сценарии).
Frames (Фреймы). Эти объекты определяют, как обрабатываются ресурсы. Фрейм включает всю необходимую для обработки определенного ресурса информацию, например, объект HTTPframe обрабатывает HTTP-ресурс.
Filters (Фильтры). Средство динамической модификации ресурсов. Например, если Web-tam распознает незарегистрированного пользователя, этот пользователь "фильтруется" на входную страницу.
Indexer (Индексатор). Средство классификации ресурсов. Два главных индекса - каталоги (для группировки файлов) и расширения (для обычных файлов, наподобие, ТХТ или INI).
На момент написания книги окончательно отлаженной была версия Jigsaw 2.2.O. Версии Jigsaw соответствуют версиям ядра Linux, например, если вы обнаружите версию Jigsaw с номером, средняя цифра которого нечетная (скажем, Jigsaw 2.3.4), значит перед вами не окончательная версия. W3C поддерживает страницу, посвященную этому серверу по адресу www. w3.org/ Jigsaw.
Примечание
Предыдущий WSC-сервер (Cern) был одним из первых в Internet К сожалению, он больше не поддерживается.
WN
Рассмотрим те бесплатные серверы, которые используются реже. Серверы в этой нише рынка помогают увидеть разнообразие технологий и возможностей Web-серверов.
WN - еще один бесплатный сервер с уникальными возможностями, отличающими его от других серверов. WN позволяет проводить полнотекстовый поиск до документам, которые разработчики называют логическими документами HTML (документы, состоящие более чем из одного файла). Кроме того, пользователи могут искать файлы на сервере и легко получать удовлетворяющие условиям поиска документы. Пользователи могут загружать простой логический документ, состоящий из нескольких связанных документов, упрощая печать файлов, представляющих собой последовательность небольших документов.
Еще одна уникальная особенность сервера WN - способность работать с условными документами. Сервер WN может создать простой документ с определениями, которые возвращают клиенту правильную версию документа в зависимости от таких переменных, как IP-адрес и версия браузера клиента.
Модель безопасности сервера WN отличает его от Apache и Web-сервера NCSA httpd, которые по умолчанию работают с файлами, пока не нарушены конкретные права доступа. WN не работает ни с одним файлом, пока не получены конкретные права доступа. Реализуя эту модель. сервер становится более безопасным и предоставляет более мощный контроль доступа к файлам.
Копию WN можно получить по адресу hopf.math. nwu. edu.
Boa
Boa - последний бесплатный сервер в нашем обзоре. Он малоизвестен, во время работы над книгой была выпущена его первая предварительная версия.
Здесь Boa описан как пример того, что хотя сервер может быть небольшим, простым и даже элементарным, он может выполнять нужную работу. Boa предоставляет только базовую функциональность и имеет меньше возможностей по управлению доступом, чем Apache или WN.
Boa разработан так, что вполне может претендовать на звание самого быстрого из доступных Web-серверов для Linux. Создатели Boa утверждают, что их сервер в два раза быстрее Apache, хотя для доказательства этого заявления требуется дополнительное тестирование на реальных больших Web-сайтах.
Такого выигрыша в производительности Boa достигает за счет однозадачного режима выполнения. Обычные Web-серверы создают несколько процессов для прослушивания запросов, а Boa работает в одном процессе и обрабатывает все приходящие запросы внутри, не используя многозадачный механизм операционной системы. Boa порождает дочерний процесс только при CGI-запросе.
Дополнительная информация о Boa доступна по адресу www. boa. org.
Stronghold
Stronghold является одним из наиболее известных коммерческих Web-серверов для Linux. Stronghold - это коммерческая версия Apache, дополненная поддержкой SSL.
Поддержка SSL (Secure Sockets Layer - Уровень безопасного соединения) необходима при создании безопасных связей браузер-сервер, используемых приложениями интерактивной торговли или там, где нужно зашифровать или скрыть от любопытных глаз данные, передающиеся между клиентом и сервером.
Stronghold имеет все средства для создания безопасного сервера, включая средства для Certificate Authority (сертификация полномочий). При помощи Certificate Authority можно выдавать цифровые сертификаты, санкционированные сторонними организациями по утверждению сертификатов, например Verisign. Кроме того, Stronghold поддерживает аппаратные акселераторы шифрования, равно как и 128-битовые ключи для повышения надежности шифрования.
Stronghold поставляется с полным текстом исходного кода, что позволяет использовать его аналогично Apache, включая компиляцию вместе с модулями для Apache и написание собственных модулей.
Stronghold распространяет фирма С2 Software по адресу http://www.c2.net/products/sh3/index.php3 .
FastTrack/iPlanet
FastTrack - известный Web-сервер от Netscape. К сожалению, фирма Netscape не интересовалась разработкой Web-серверов для некоммерческих операционных систем (таких как Linux) до того, как было принято решение выпустить в свободное распространение браузер и исходные тексты к нему.
С появлением альянса между AOL/Netscape и Sun интерес к FastTrack оживился. Теперь он входит в семейство iPlanet Web-серверов и серверов приложений. FastTrack сейчас реализован с помощью свободно-распространяемой Java-версии Web-сервера iPlanet. Enterprise-версия этого сервера распространяется как коммерческий продукт.
Управлять Web-сервером FastTrack очень просто. Все действия по конфигурированию и администрированию выполняются через Web-формы. Эти формы позволяют Web-мастеру производить все операции: от создания списков пользователей до управления доступом к файлам на уровне каталогов.
FastTrack имеет поддержку включений со стороны сервера, CGI и собственный API Netscape пя разработки приложений. Он поддерживает Live Wire фирмы Netscape, среду разработки для JavaScript со стороны сервера.
Сервер также можно использовать как безопасный сервер по технологии SSL. Для получения более подробной информации о нем обращайтесь по адресу http: / /home. netscape. com/ fasttrack/v3.0/index.html.
AOLserver
История AOLserver интересна: от коммерческой версии в 1995 году до одного из самых полнофункциональных бесплатных серверов, доступных в настоящее время.
AOLserver появился с именем NaviPress и был одним из первых доступных коммерческих серверов. В конце 1995 года AOL приобрела, компанию, выпустившую NaviPress, и использовала сервер внутри фирмы. В начале 1997 года AOL начала бесплатно распространять сервер по сети Internet.
Во время написания книги последняя версия AOLserver 3.4 поддерживала следующие функции.
AOLserver можно загрузить с Web-сайта AOLserver по адресу www. aolserver. com/ server/ index.html.
Java Web Server
Java Web Server отдела JavaSoft фирмы Sun - уникальный Web-сервер. Несмотря на то, что Java Web Server не разрабатывался специально под Linux, теоретически он может работать на любой платформе с Виртуальной Машиной Java (Java Virtual Machine), так как полностью разработан на Java.
Java Web Server предлагает многочисленные функции, выделяющие его среди коммерческих предложений, включая систему серверных аплетов для написания приложений без необходимости возврата к CGI, полную поддержку SSL, что позволяет использовать сервер безопасными приложениями, например интерактивными магазинами.
Для улучшения производительности можно создать компилированные страницы, состоящие как из HTML, так и из программного кода. Для сбора статистической информации в программах можно регистрировать сессии пользователей при помощи встроенного механизма регистрации.
К сожалению, с расширением соглашения между AOL/Netscape и Sun возникает необходимость поддержки трех Web-серверов. К моменту написания книги было принято решение о прекращении развития этого продукта в начале 2001 года. Однако, это по прежнему популярный коммерческий Web-сервер. Если вам необходимы услуги в области администрирования или поддержки Java Web Server, можно обратиться к его домашней странице по адресу http: / /www. sun. com/ software/ jwebserver/ index. html.
Zeus
Zeus - последний Web-сервер, рассматриваемый в этой главе. Последняя версия Zeus - 3.3.8 -представляет Web-сервер для Unix/Linux и Macintosh OS X. Он предлагает встроенную поддержку кластеризации, что явно дает серверу потенциальные преимущества для объемных сайтов. Кластеризация позволяет реализовать обслуживание одного Web-адреса несколькими Web-серверами.
Это дает возможность распределить нагрузку запросов по всем серверам группы, а значит обрабатывать большее количество запросов одновременно.
Упомянутые возможности позволили Zeus стать Web-сервером для ряда наиболее загруженных Web-сайтов, включая eBay и British Telecom. Разработки, ориентированные на ядро Linux 2.4, позволяют надеяться на то, что мощность Zeus Web-сервера будет расти. В настоящее время IBM Linux Technology Center считает, что производительность Zeus-серверов для ядра Linux 2.4 почти вдвое выше, чем у серверов на базе ядра Linux 2.2.
Кроме того, Zeus предлагает поддержку ISAPI (API из Internet Information Server фирмы Microsoft) как под Unix, так и под Windows NT/2000. Zeus поддерживает сервлеты (servlet) Java, подобные тем, которые используются в Java Web Server, и предлагает интегрированную связность с базами данных при помощи стандарта доступа к базам данных JDBC.
Zeus предлагает 128-битовое шифрование SSL по всему миру. Из-за того, что Правительство США ограничивает экспорт 128-битовой технологии шифрования, компании США предлагают на экспорт криптографические программные продукты с "ослабленной" 56-битовой кодировкой. Большинство сообщений о взломе шифров программ, таких как Netscape, относились к версиям программ с 56-битовой кодировкой.
Информация о Zeus доступна по адресу www. zeus. со. uk.
Установка Apache
Оставшаяся часть главы посвящена детальному обзору Web-сервера Apache по двум причинам:
Если при установке системы Linux выполнена достаточно полная инсталляция, то, вероятнее всего, Apache уже установлен. Существует много способов проверить, установлен ли Apache. Можно использовать команду rpm.
$ rpm -q apache
Если Apache уже установлен, ответ команды будет примерно таким:
apache-1.3.19-5
Если в ответ на команду rpm получено сообщение, что Apache уже установлен, то часть главы до параграфа "Конфигурирование Apache" можно пропустить.
Установка Apache с CD-ROM Red Hat
Наиболее простой способ установки Apache - с прилагаемого к книге диска CD-ROM. Для этого смонтируйте CD-ROM (обычно в /mnt/cdrom) и выполните команду cd в каталог /imt/cdrom/RedHat/RPMS. (Если CD-ROM смонтирован не в /mnt/cdrom, перейдите в каталог, соответствующий точке монтирования). Этот каталог содержит все файлы rpm полного дистрибутива Red Hat Linux. Для установки пакета выполните команду rрm
$ rpm -i apache-1.3.19-5.1386.rpm
Загрузка последней версии Apache
Если планируется запустить высококлассный или очень объемный Web-сервер, загрузите последнюю версию Apache с узла httpd.apache.org (рис. 32.1). При использовании последней версии можно быть уверенным, что незначительные ошибки, которые не повлияли бы на небольшой сайт, не проявятся при работе с более сложным или более посещаемым сайтом.
Рис. 32.1. Web-сайт Apache
Примечание
Приведенная далее информация по конфигурированию и управлению Apache подразумевает использование версии этого Web-сервера с Red Hat CD-ROM, прилагаемого к книге Новые версии Apache совместимы сверху вниз. Конфигурационные файлы, рассматриваемые в главе, должны работать и с новыми версиями Apache.
При загрузке Apache с Web-сайта Apache можно загрузить либо оригинал исходного кода, либо откомпилированные исполняемые файлы для Linux. Существуют бесспорные аргументы в пользу первого способа, особенно если планируется разработка программ с использованием API Apache или внедрение дополнительных модулей в сервер. Однако рекомендуем загрузить уже готовые исполняемые модули для построения Web-сайта с базовым набором свойств Apache. В книге нет руководства по компилированию собственной копии Apache, так как для этого требуется более тщательное изучение Web-серверов.
Для получения последнего дистрибутива исполняемых модулей Apache перейдите в браузере на Web-сайт Apache (httpd. apache. org) и выберите ссылку загрузки (Download). Это приведе-к каталогу файлов и ссылке под названием Binaries. Последовав за ссылкой Binaries, укажите операционную систему (в нашем случае, Linux). В окне браузера отобразится список доступных файлов. Во время написания книги этот список был следующим.
Заметьте: судя по именам файлов, текущей версией является Apache I.3.6. Обозначения 1586 и 1686 указывают, что пакет откомпилирован с оптимизацией для процессоров класса Pentium либо Pentium II соответственно.
Файлы README являются текстовыми. Не мешало бы их прочесть перед загрузкой. Файлы . gz сжаты утилитой gzip. ASC-файлы включают сигнатуру PGP. После загрузки выбранного пакета распакуйте файл во временном каталоге. Для распаковки архива в подкаталог текущего каталога используйте команду:
$ tar xzvf apache-file-name
В данном случае подкаталог называется apache_l .3.20, хотя он может быть и другим в зависимости от версии Apache, доступной при загрузке исполняемых модулей. В этом каталоге есть полный исходный текст загруженной версии с примерами конфигурационных файлов и полной документацией в формате HTML.
Чтобы установить загруженные исполняемые модули, выполните установочный сценарий install-bindist. sh из каталога распакованного архива.
$ install-bindist.sh
По умолчанию эта команда установит сервер Apache в /usr/local/etc. Заметьте: Red Hat помещает Apache-сервер в каталог /usr/sbin, конфигурационные файлы в /etc/httpd/conf и делает каталог /var /www/html корневым для Web-документов. В этой главе подразумеваются умолчания, принятые в Red Hat, так как они используются при инсталляции Apache с CD-ROM, прилагаемого к книге.
Примечание
Если вы используете другую версию Apache, указанные каталоги могут быть другими. Воспользуйтесь командами find или locate, чтобы найти их.
Дистрибутивы исполняемых кодов Apache содержат полные инструкции по компиляции пакета из прилагаемых исходных текстов, поэтому если обнаружится, что загруженные откомпилированные модули работают не так, как ожидалось (возможно, из-за проблем несовместимости с библиотеками Linux), можно использовать инструкции для построения собственных исполняемых модулей.
Конфигурирование Apache
До версии 1.3.6 конфигурирование Apache производилось тремя основными конфигурационными файлами: httpd.conf, srm.conf, и access .conf. В Red Hat при стандартной установке Apache файлы конфигурации находятся в /etc/httpd/conf/, хотя расположение их легко изменить (это показано далее при рассмотрении запуска Web-сервера Apache). Начиная с версии 1.3.6, эти три файла объединены в один: httpd. conf. Этот общий файл выполняет функции всех трех файлов и его содержимое почти такое же, как и у исходных трех файлов.
Роль конфигурационных файлов Apache не очень четко определена и иногда функции дублируются, но обычно они используются следующим образом.
httpd.conf. Используется для установки общих параметров, таких как номер порта, используемого сервером, и списка загружаемых при запуске сервера модулей. Этот файл также указывает на расположение файлов srm. conf и access. conf.
srm.conf. Определяет другие общие параметры: структуру корневого дерева документов сервера и правила, относящиеся к программам CGI.
access.conf. Используется для установки ограничений доступа для сервера или отдельных каталогов.
Рассмотрим основные параметры, на которые должен обратить внимание любой Web-мастер перед запуском Apache на открытом Web-сервере. В дальнейших примерах используется сервер Apache версии 1.3.19, поставляемый с предварительной версией Red Hat Linux 7.1. Эта версия Apache использует один конфигурационный файл /etc/httpd/conf /httpd. conf.
С помощью задаваемых в этом файле параметров можно определить поведение Apache-сервера в целом, в отношении ответов на запросы HTTP, и в отношении любых виртуальных хостов, которые выглядят как отдельные Web-сайты для любого браузера.
Конфигурационный файл Apache
Хотя подкаталог /etc/httpd/conf включает все три оригинальных конфигурационных файла, собственно конфигурируется только файл httpd. conf. Остальные CONF-файлы оставлены для совместимости с предыдущими версиями.
Структура файла httpd. conf довольно проста. Ниже приведен его листинг по умолчанию:
# инструкциями обращайтесь по адресу <URL: http://www.apache.org/docs/ > #
# по адресу <URL: http://www.apache.org/docs/mod/core.htmlflockfile >),
# то он создает дополнительный резерв. Если больше, чем
# для обработки каждому дочернему процессу перед его удалением.
|
</IfDefine> |
|
# |
# (например, http://123.45.67.89/) и эта директива позволит
<Directory "/var/www/html">
|
# |
|
<Files - н/ч \ .ht"> |
|
AddlconByType ( SND , / icons / sound2 .gif) audio / * |
# Несмотря на схожесть названий, следующие директивы Add*
AdSLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
AddLanguage da .da
AddLanguage el .el
# языков на случай, если при согласовании содержимого не удастся
AddType application/x-httpd-php .php4 .php3 .phtml .php
AddType application/x-httpd-php3 .php3
# Далее приведены директивы для PHP/FI (PHP2):
# ErrorDocument 500 "The server made a boo boo.
# <URL: http://www.apache.org/docs/vhosts/ >
# для ознакомления с подробностями перед тем, как
# Можно использовать в командной строке опцию '-S', чтобы
#NameVirtualHost 12.34.56.78:80 #NameVirtualHost 12.34.56.78
|
# можно найти сертификаты СА для аутентификации клиентов или |
|
#SSLReqUire ( %{SSL_CIPHER) ! ~ m/ n (ЕХР |NULL) -/ \ |
|
tt or %{REMOTE_ADDR) =~ m/ n !92\ .76\ . 162\ . [0-9] +$/ |
|
# Экспортируются V SSL *' переменные окружения, |
# Место хранения пользовательского SSL файла протокола,
# протокола SSL (без ошибок) на виртуальном хосте.
</IfDefine>
Заметьте: этот файл содержит и комментарии, и реальные команды конфигурирования. Комментарии начинаются с символа диеза (#). Команды состоят из имени команды, за которым следует параметр.
В файле httpd.conf три раздела: Global Environment, Main Server Configuration и Virtual Hosts. Рассмотрим каждый из них подробно.
Раздел Global Environment
Директивы и модули этого раздела управляют операциями сервера Apache в целом. Все, что входит в этот раздел, применимо ко всем хостам Apache, независимо от того, идет ли речь о виртуальном хосте или главном сервере.
Server-Type
Первая команда, которая будет описана - это ServerType. Сервер Apache может работать в двух режимах. Первый режим - самостоятельный (standalone), когда его собственные процессы прослушивают соединения и в режиме inetd, с которым читатель уже ознакомился в параграфе о работе сетей. Во втором режиме (с inetd) inetd прослушивает соединения и запускает процесс Apache при установлении соединения. Если Web-сервер Apache запускается впервые, то лучше не запускать его в самостоятельном режиме, пока вы не ознакомитесь с inetd и не получите необходимые основания для работы сервера в самостоятельном режиме.
ServerRoot
ServerRoot используется для задания базового каталога, в котором находятся файлы конфигурации и протоколов. Red Hat устанавливает их в каталог etc/httpd. В этом каталоге есть каталог conf, содержащий три файла конфигурации, и каталог logs для протоколов в виде ссылки на/var/log/httpd.
Можно по своему усмотрению переместить этот каталог внутри системы на позицию, соответствующую вашему стилю администрирования. Но проще всего оставить все файлы там, куда их помещает дистрибутив Linux.
Загрузка Модулей
Первая секция состоит из последовательности команд LoadModule, за которыми следует последовательность команд AddModule. Функциональность Apache создается и расширяется за счет использования модулей. В ранних версиях Apache эти модули были объединены в исполняемый файл Apache - httpd. Начиная с версии Apache 1.3 можно использовать модули, загружаемые при запуске сервера.
Так как большинство этих модулей конфигурируется посредством команд, находящихся в файле конфигурации, очень важно, чтобы все модули загружались до появления любой другой команды файла httpd. conf.
Дм большинства базовых инсталляций достаточно использовать список модулей по умолчанию, который можно не корректировать. Если нужно расширить или изменить функциональность Web-сервера, обратитесь к on-line документации по адресу httpd. apache. org за дополнительной информацией о добавлении загружаемых модулей и использовании команд LoadModule и AddModule.
Конфигурирование главного сервера
На Apache-сервере можно создать сколько угодно виртуальных хостов. Но каждый Apache-сервер требует главного хоста. Директивы в секции главного сервера определяют параметры по умолчанию для главного хоста, равно как и любые директивы, не заданные в рамках любого виртуального хоста.
Port
Команда Port - второй важный элемент. Подразумевается, что по умолчанию Web-сервер работает с 80-м портом. Когда браузер запрашивает URL без порта, он подразумевает, что URL запрашивается с сервера через порт 80. Если вы используете брандмауер с высоким или средним уровнем защиты, удостоверьтесь в том, что он настроен на разрешение приема WWW-данных, как описано в гл. 31.
Из-за уязвимости процессов, работающих с номерами портов меньше 1024, можно попробовать запустить сервер чеоет порт с номером выше 1024 (если запускается Web-сервер с ограниченным
доступом по сети Internet и необходимо избежать риска, связанного с номерами портов меньше 1024). Обычно для таких Web-серверов используются порты 8000 и 8080, но можно выбрать любой свободный порт. Если вы используете брандмауер с высоким уровнем защиты, удостоверьтесь в том, что он настроен на разрешение приема WWW-данных для выбранного порта. Настраивая свой брандмауер с помощью утилиты lokkit, описанной в главе Chapter 31, при использовании порта 8080, введите 8080 :udp, 8080: top в поле Other Ports (Другие порты) в разделе Customization (Настройка).
User И Group
Команды User и Group - критические элементы, так как они оказывают существенное влияние на безопасность системы. Обычно httpd запускается как root, но этот процесс не прослушивает соединения. Чаще этот процесс запускает один или несколько дочернюифоцессов user и group (указанные именем либо ID-номером), определенных этими командами конфигурации.
Запуск процессов Web-сервером, включая программы CGI, в режиме root является огромным риском, особенно если плохо написанный сценарий CGI оставляет большие бреши в защите. Запустив Web-сервер и связанные с ним дочерние процессы под именем пользователя с ограниченными привилегиями, можно снизить опасность успешных атак на сервер.
Обычно Web-сервер запускают под именем apache группой apache или #-1. Автор книги чаще всего использует имя apache и группу apache, так как их легко илентифицировать при чтении файла конфигурации. Это имя (apache) имеет ограниченные привилегии в системе и потенциальный хакер может нанести ограниченный вред, если сценарий CGI позволит ему прорваться в систему.
ServerAdmin
Эта команда устанавливает электронный адрес администратора Web-сайта. Когда сервер генерирует автоматическое сообщение об ошибке, например, об отсутствии запрашиваемой страницы, то этот электронный адрес добавляется к странице, сообщающей, к кому нужно обращаться для извещения об ошибке. Убедитесь, что это правильный адрес, который действительно является адресом администратора сервера.
ServerName
Команда ServerName устанавливает имя хоста, возвращаемое клиентам с запрашиваемыми страницами. Это должно быть одно из допустимых имен сервера в соответствии с DNS-записью или таблицей хостов сети. В среде Intranet имя хоста можно определить в таблицах хостов, используя NIS, либо на сервере DNS вашего сайта. Для Web-сервера Intranet нужно убедиться, что указанное в этой команде имя допустимо в DNS-записи вашего домена. Если уверенности в этом нет, уточните у администратора записей имен доменов.
В этом примере для ServerName задано значение localhost. Если у вас есть свой домен, вы можете изменить это имя на имя Интернет-домена, например, mommabears. com.
DocumentRoot
Команда DocumentRoot указывает местоположение корневого каталога для файлов HTML. Для Red Hat Linux 7.1 по умолчанию это каталог /var/www/html. Если для ServerName задано значение mommabears. com, клиент с браузером должен иметь возможность получить доступ к файлу /var/www/html /file, html, используя URL-адрес http: //www.mommabears.com/ file.html.
Разрешение каталога HTML
Приведенный далее код является разделом примера файла httpd. conf, имеющего отношение к корневому каталогу F-HTML-документов. Комментарии удалены.
</Directory>
Структура этого элемента такова, что необходимые команды помещаются между открывающим и закрывающим дескрипторами <Directory> и </Directory> соответственно. Открывающий дескриптор указывает каталог, на который распространяются все команды, находящиеся между дескрипторами, в данном случае /var/www/html.
Обратите внимание: между дескрипторами <Directory> и </Directory> находятся четыре команды.
Команда Options указывает, какие специальные действия можно выполнить с файлами, находящимися в каталоге и его подкаталогах. Возможны значения None, All, Indexes, Includes, FollowSymLinks, ExecCGI и MultiViews. Для HTML каталогов обычно используются значения None, когда на сайте находятся только обычные файлы HTML и рисунки, и Includes, если планируется разрешить серверу обработку HTML. (Некоторые обрабатываемые сервером файлы HTML позволяют включать другие файлы в содержимое HTML-файла, и эта опция разрешает такое действие).
Следующая команда, AllowOverride, указывает, как влияет локальный файл . htaccess на переопределение элементов файла глобального доступа httpd. conf. Возможны значения None, All, Options, FileInfo, AuthConfig и Limit. Например, величина Options ограничивает возможности файла .htaccess переопределением команды Options. На тех серверах, где Web-мастер полностью контролирует содержимое, проще всего санкционировать файлу httpd. conf полное право переопределения. Если имеется сервер с несколькими пользователями, которые контролируют состав своих собственных каталогов, будет разумно ограничить их привилегии по переопределению конфигурации глобального доступа.
Команды order и allow используются вместе для определения тех, кто имеет доступ к страницам каталога. Приведенная в примере команда order al low, deny указывает, что сначала следует использовать команду allow и, если она не позволяет пользователю получить требуемый файл, то тогда применяется команда deny.
Обычно приходится использовать order allow, deny, если не применяется управление доступом. Если необходимо решшзовать управление доступом, то order deny, allow является лучшей командой (это станет понятно позже при построении небольшого Web-сайта с контролем доступа).
После команды order находится команда allow, которая указывает, что всем пользователем разрешается доступ. Чтобы узнать, как запретить доступ пользователей, прочтите документацию по Apache (http: / /httpd. apache. org).
UserDir
UserDir полезна тогда, когда Web-мастер разрешает каждому пользователю системы иметь собственную Web-страничку. Пользователь организовывает свою Web-страничку в подкаталоге, находящемся в его домашнем каталоге. Эта команда указывает имя подкаталога в домашнем каталоге пользователя, который нужно принимать за его Web-каталог.
Обычно используется public_html. Поэтому если у пользователя testuser есть каталог /home/ testuser/public_html, то к этому каталогу можно получить доступ через Web, используя URL http://servername/ ~testuser.
Directory-Index
Directory Index указывает, какие файлы должны приниматься как индексные. Это позволяет для такого URL, как http: / /www. mommabears. com получить доступ к нужному файлу.
В примере httpd.conf имеется семь элементов в Directorylndex: index.html, index.htm, index.shtml, index.php, index.php4, index.php3 и index.cgi. Это означает, что для любого URL, в котором не указано имя файла, а только имя каталога, сервер сначала попробует вернуть файл index. html из указанного каталога. Если такого файла нет, будет передан файл index. htm; если этого файла нет, то клиенту будет передан файл index. shtml и т.д. - вплоть до последнего седьмого.
Если ни один файл не найден, то сервер возвращает листинг каталога либо сообщение об ошибке, в зависимости от других настроек конфигурации.
AccessFileName
AccessFileName используется для указания имени файла, содержащего информацию управления доступом для данного каталога. Можно хранить информацию управления доступом в конфигурационном файле httpd. conf или в файлах . htaccess в каждом каталоге.
В примере указано, что если в каталоге есть файл . htaccess, то он содержит информацию управления доступом для каталога.
ScriptAlias
Очень важно корректно использовать команду ScriptAlias, чтобы указать каталог размещения программ CGI и сценариев. ScriptAlias указывает, какой каталог используется для сценариев CGI, и какой URL соответствует этому каталогу. Это единственное место, куда можно поместить программы CG1, пока не будут назначены другие условия для запуска CGl-программ по расширениям (как это выполнено далее посредством команды AddHandler).
В примере, приведенном выше, используется следующая команда.
ScriptAlias /cgi-bin/ "/var/www/cgi-bin"
Эта строка показывает, что URL http: //www.moramabears.com/cgi-bin/ соответствует /var/www/cgi-bin/. Подразумевается, что все файлы в этом каталоге являются сценариями CGI и сервер пытается запустить их, вместо того, чтобы возвратить их запрашиваемому клиенту.
Разрешение каталога CGI
По сравнению с описанием HTML-каталога, приведенным ранее, описание CGI-каталога выглядит несколько иначе:
<Directory /var/www/cgi-bin>
AllowOverride None Options ExecCGI Order allow,deny Allow from all
</Directory>
Обратите внимание, что все переопределения запрещены. Это вполне разумно, поскольку CGI представляет собой брешь в защите даже для хорошо сконфигурированной системы. Такой подход позволяет избежать различных ошибок защиты, связанных с CGI-каталогами.
AddHandler и AddType
Команды AddHandler и AddType нужно рассматривать вместе.
AddHandler позволяет отождествить файлы, имеющие указанное расширение, с определенным действием, которое можно реализовать как встроенное в сервере (например, запуск программ CGI), или как внешнее действие, обычно вызывающее специальную программу вне сервера и передающее запрашиваемый файл.
AddType создает новый тип MIME для указанного расширения. Типы MIME важны для указания клиенту, как нужно обращаться с файлом. Например, если в браузер передается файл с типом MIME text /plain, то браузер не интерпретирует код HTML в этом файле, в то время как тип MIME text /html заставляет браузер обрабатывать принимаемый файл как файл HTML.
Эти команды обычно применяются для того, чтобы разрешить выполнение сценариев CGI вне указанного каталога CGI-сценариев и разрешить серверу обрабатывать HTML, что позволяет обрабатывать встроенные в HTML-файл специальные дескрипторы перед возвращением страницы.
Разрешение сценариев CGI
Вы можете использовать команду AddHandler, чтобы разрешить обработку CGI вне заданного для CGI каталога. В примере файла httpd. conf используется команда
AddHandler cgi-script .cgi
которая указывает, что любой файл с расширением .cgi вне заданного каталога CGI должен рассматриваться как программа CGI и обязательно обрабатываться. Без этой команды любой
сценарий CGI, находящийся вне каталога CGI, не рассматривается как программа CGI. Клиенту просто будет возвращено содержимое файла: пользователь увидит фактический^код программы сценария, а не результаты его выполнения.
Разрешение обработки HTML для сервера
Для этого используются обе команды - AddHandler и AddType- Для Apache обычно указывается:
AddType text/html .shtml AddHandler server-parsed .shtml
Здесь AddType гарантирует, что результат обработки сервером файла HTML (эти файлы имеют расширение . shtml) рассматривается браузером клиента как файл HTML и отображается соответственно.
Строка AddHandler указывает, что файлы с расширением . shtml обрабатываются сервером. Это эффективно разрешает обработку сервером HTML для файлов . shtml.
Управление Web-сервером
Пользователь должен уметь запустить и остановить Web-сервер после его установки. Кроме того, нужно время от времени выполнять некоторые служебные операции, чтобы убедиться в том, что сервер работает без инцидентов. Необходимо добавлять и удалять пользователей и группы, защищать каталоги при помощи управления доступом и осуществлять контроль протоколов сервера.
Запуск и остановка Apache
Если Apache установлен при установке Red Hat, то загрузочные файлы во время старта системы уже настроены на запуск Apache. Эти настройки находятся в файле /etc/re. d/ init. d/ httpd. Данный файл является исполняемым сценарием, которому передаются два возможных параметра: start и stop. Если планируется использовать версию Apache, поставляемую с дистрибутивом Red Hat и расположение конфигурационных файлов не будет изменяться, то можно запускать и останавливать Web-сервер вручную, используя команду
# /etc/re.d/init.d/httpd start
для запуска сервера и команду
# /etc/re. d/init.d/httpd stop
для останова сервера.
Примечание
Запуск и останов Web-сервера производятся пользователем root, чтобы главный процесс сервера мог изменять пользователей для запуска дочерних процессов при прослушивании соединений.
Если устанавливаются собственные исполняемые модули или скомпилированные из исходников новые двоичные файлы, или необходимо изменить расположение конфигурационных файлов, то нужно уметь вручную запускать команду httpd.
Обычно httpd находится в /usr/sbin/. Допустимы два ключа.
Обычно достаточно использовать флаг - f, поскольку ServerRoot указан в файле httpd. conf. Например, если файлы конфигурации находятся в /home/httpd/conf, то запустить сервер можно с использованием следующей команды.
# /uar/sbin/httpd -f /etc/httpd/conf/httpd.conf
Если сервер запущен самостоятельно, без использования /etc/re. d/init. d/httpd, и его надо остановить вручную, то нужно знать правильный ID процесса (PID) для сервера. PID сервера можно определить, используя команду ps.
# ps -aux | grep httpd
Эта команда выдает список процессов подобный следующему.
Заметьте: все процессы принадлежат apache за исключением одного, принадлежащего root. Это родительский процесс всех процессов httpd, как раз тот, который нужно остановить командой
# kill 544
Управление пользователями и группами
В следующем параграфе (о защите каталогов) вы узнаёте, что одним из основных методов защиты является использование имени и пароля, который ограничивает доступ конкретному ряду пользователей. Пользователи должны правильно ввести свои имя и пароль для получения доступа к защищенному каталогу.
Создавать пользователей очень просто. Для этого достаточно воспользоваться командой htpasswd, которая при обычной установке Apache из дистрибутива Red Hat Linux находится в /usr/bin/htpasswd. Эта программа используется как для создания файла паролей, так и для добавления индивидуальных пользователей. Файл паролей выполняет функцию хранилища имен пользователей и зашифрованных паролей, используемых Apache для управления доступом.
# htpasswd -с filename user-name
При выполнении этой команды создается файл filename и добавляется первый пользователь. Флаг -с указывает, что файл нужно создать. Файл паролей может находиться где угодно, лишь бы он был доступен для Web-сервера Apache. Неплохим местом для него может служить каталог с файлами конфигурации. Например, команда
# htpasswd -с /etc/httpd/conf/users userl
создает файл пользователей в том же каталоге, что и другие файлы конфигурации Apache, и до-бавляегв него пользователя userl.
При выполнении этой команды программа дважды запрашивает пароль - для проверки его корректности. Затем пароль шифруется и записывается в /etc/httpd/conf /users. Соответствующая строка этого файла выглядит примерно так:
userl:N3ImVAxFtiv0
Формат строки: имя пользователя, двоеточие и зашифрованный пароль. Информация о каждом пользователе находится на отдельной строке.
Хотя это выглядит, как пароли в системном файле паролей (/etc/passwd), и файл паролей Apache зашифровывается аналогично, процесс шифрования в htpasswd совсем иной. Нельзя просто скопировать зашифрованные пароли из /etc/passwd для создания файла паролей Apache.
Для добавления пользователей после создания файла используется команда htpasswd без флага -с.
$ htpasswd /etc/httpd/conf/users user2
Эта команда добавляет пользователя user2, дважды запрашивая пароль..Результирующий файл паролей содержит две строки.
user1:N31mVAxFtiv0. user2:WROTrb116.3pPk
Кроме пользователей, несомненно, придется создавать группы. Группы объединяют несколько пользователей под одним именем, упрощая ссылку на пользователей с одинаковыми правами при конфигурировании управления доступом для каталогов.
Этот файл содержит один или несколько элементов, каждый из которых находится в отдельной строке,
имеющей формат:
Например, чтобы создать группу authors, состоящую из двух пользователей, зарегистрированных ранее, используется следующая строка.
authors: user1 user2
Защита каталогов посредством управления доступом
Как было указано в параграфе о разрешении HTML-каталога, существует возможность установить управление доступом для каждого каталога отдельно. Обычно это делается при помощи файла . htaccess в том каталоге, который надо защитить. В данный файл помещаются необходимые команды конфигурирования.
Для управления доступом в этом файле используются следующие основные команды:
AuthUserFile И AuthGroupFile
Команды AuthUserFile и AuthGroupFile позволяют указать расположение файлов пользователей и групп. В нашем примере эти команды следующие:
AuthUserFile /etc/httpd/conf/users AuthGroupFile /etc/httpd/conf/groups
Эти команды очень важны: без них сервер не будет знать, где искать пользователей и их пароли.
AuthName
AuthName используется для указания домена аутентификации. Это подсказка пользователям, чтобы они знали, как вводить имя и пароль. Например, AuthName Authors Only отображает пользователю подсказку Authors Only при запросе имени и пароля.
AuthType
AuthType предназначена для указания типа аутентификации, используемого для доступа к Web-странццам в перечисленных каталогах. Поскольку единственная доступная для AuthType опция basic, эта директива мало влияет на функционирование текущей версии Apache.
Require
Команда require используется при ограничении доступа пользователям и группам. Команда может использоваться для ограничения доступа пользователей, перечисленных в файле паролей, перечисленных в команде пользователей или для всех перечисленных в команде групп.
Для ограничения доступа любого пользователя, упомянутого в файле паролей, используется следующая команда:
require valid-user
Для ограничения доступа конкретных пользователей используется формат require user usernamel username2 ивегпате3 . .. Для ограничения доступа членам групп используется строка
require group groupname1 groupname2 grouрname3 ...
Order
Команда order используется в сочетании с элементами deny и allow для управления доступом на уровне хостов, а не пользователей. Используя order, deny и allow можно разрешить доступ только конкретным хостам, задав их IP-адреса или имена.
Команда order указывает порядок применения команд deny и allow. Например, в команде order allow,deny вначале выполняется команда allow, и если хост клиента не соответствует условиям команды allow, то выполняется команда deny. Аналогично, order deny, allow изменяет порядок, выполняя вначале команду deny.
Deny
Команда deny указывает, каким хостам запрещен доступ к каталогу. Возможны значения all, частичное имя хоста и частичный или полный IP-адрес. Например,
deny from all означает, что всем хостам запрещен доступ. Аналогично, deny from .juxta.com запрещает доступ всем хостам домена juxta. com. При использовании IP-адресов формат такой же: deny from 194.148.43.195 Команда запрещает доступ указанному хосту.
Allow
Команда allow выполняет обратную по сравнению с deny функцию: указывает, каким хостам разрешен доступ к данному каталогу. Она имеет те же параметры, что и команда deny.
Создание файла доступа
Рассмотрим все эти команды на двух примерах: разрешение доступа для группы и разрешение доступа по имени домена.
Разрешение доступа для группы
Следующий пример файла . htaccess разрешает доступ к конкретному каталогу только пользователям группы authors.
AuthName Authors Only AuthUserFile /etc/httpd/conf/users AuthGroupFile /etc/httpd/conf/groups require group authors
Заметьте: в этом примере указана команда AuthName для подсказки, указаны файлы паролей и групп, а также то, что пользователь должен быть членом группы authors для получения доступа к каталогу.
Разрешение доступа по имени домена
Следующий пример файла . htaccess разрешает доступ к конкретному каталогу только пользователям, которые обращаются к Web-сайту из хоста, находящегося в домене juxta.com:
order allow,deny allow from.juxta.com deny from all
Обратите внимание на порядок следования allow и deny. Логика работы следующая: при обращении к каталогу имя домена хоста сравнивается с доменом juxta. com. Если хост находится в этом домене, то доступ предоставляется. Если нет, то выполняется анализ по команде deny. Так как она запрещает доступ всем хостам, то запрашивающему хосту доступ не предоставляется.
Управление протоколами
Последняя рассматриваемая функция администрирования - управление протоколами. Apache создает два важных протокола: протокол доступа и протокол ошибок. Вместе они обеспечивают важной информацией многие функции, включая отладку ошибочных сценариев CGI и генерацию статистических отчетов доступа с подробной информацией об использовании Web-сайта.
Однако если о них забыть, эти протоколы будут увеличиваться в объеме, достигая огромнных размеров. С увеличением их размера значимость информации уменьшается, ибо обработка данных затрудняется.
.Поэтому полезно установить график чередования протоколов. Чередование протоколов означает сохранение текущей версии в архиве и создание нового, пустого протокола. В зависимости от посещаемости сайта следует производить чередование протоколов раз в месяц, неделю или день
Red Hat Linux 7.1 включает протоколы Apache в каталог /var/log/httpd. Они чередуются ; другими протоколами из /var/log в ежедневном режиме, как указано в сценарии /etc/ cron.daily/logrotate.
Для чередования протоколов используется утилита rotatelogs, поставляемая с дистрибутивом Apache. По умолчанию Red Hat Linux устанавливает ее в /usr/sbin/rotatelogs. Для использования программы добавьте следующую строку в файл httpd. conf.
TransferLog " |/usr/sbin/rotatelogs /some/location/file time"
Элемент /sorae/location/f ile дает базовое имя файла для чередующихся протоколов Число, соответствующее системному времени начала протоколирования, добавляется к имена файла. Параметр time, в секундах, указывает, как часто выполняется чередование протоколов.
Построение Web-сайта
После того, как Web-сервер сконфигурирован и отлажен, создадим для примера небольшой Web-сайт, чтобы показать, как развертывать информацию в Web.
Построим сайт, который будет содержать информацию о небольшой издательской компании On The Web Publishers. Разместим на сайте список новых изданий, общую информацию об издателе, форму для контактов и защищенный паролем раздел для эксклюзивного использования авторами, имеющим контракт с издателем.
В рамках поставленной задачи попытаемся создать сайт, содержащий HTML-документы и изображения, использующий CGI-программирование и выполняющий контроль доступа защищенного паролем раздела на сайте.
Определим структуру сайта, как показано на рис. 32.2.
Рис. 32.2. Структура Web-сайта
Создадим файлы, необходимые для реализации этой структуры. Подразумевая использование конфигурации, рассмотренной ранее в главе, поместим корневой каталог для дерева HTML-документов в /var /www/html, а каталог CGI - в /var /www/cgi-bin. Дерево каталогов и файлов:
/var/www/html/index.html
/var/www/html/about/index.html
/var/www/html/books/index.html
/var/www/html/contact/index.html
/var/www/html/authors/index.html
/var/www/cgi-bin/formmail
Кроме последнего файла, который мы рассмотрим вкратце, все перечисленные файлы являются HTML-файлами. Все вспомогательные файлы с изображениями, используемые HTML-файлами, можно разместить в тех же каталогах, что и файлы HTML. Многие Web-мастера предпочитают размешать все файлы с изображениями в другом каталоге. Этот каталог может быть следующим.
/var/www/html/images/
Так как в главе не рассматривался язык HTML, оценим два HTML-файла в качестве примеров соответствующих документов. Начнем с главной домашней странички /var/www/html/ index. html. В данном случае исходный текст файла может быть следующим.
<A HREF="/">
<IMG SRC="/images/logo.gif" BORDER=0></A>
<FONT SIZE=5>W</F>elcome to <STRONG>On the Web Publishers</STRONG>.
</BODY> </HTML>
Результат работы этого файла показан на рис. 32.3.
Рис. 32.3. Домашняя страница
Остальные страницы будут выглядеть примерно так же, кроме формы для контактов /var/ www/html/contact/index.html. Форма для контактов показана на рис. 32.4, она реализуется следующим исходным кодом.
<A HREF="/">
<IMG SRC="/images/ldgo.gif" BORDER=0></A>
US</A></TD>
BOOKS</A></TD>
<INPUT TYPE=TEXT WIDTH=30 NAME=city> City<BR>
<INPUT TYPE=TEXT WIDTH=30 NAME=state> State<BR>
<INPUT TYPE=TEXT WIDTH=30 NAME=zip> Zip/Post Code<BR>
<INPUT TYPE=TEXT WIDTH=30 NAME=country> Country<BR>
<INPUT TYPE=TEXT WIDTH=30 NAME=email> E-mail<BR>
Comments:<BR>
<TEXTAREA ROWS=10 COLS=30 NAME=commentS WRAP=HARD></TEXTAREA><BR>
</BODY> </HTML>
Рис. 32.4. Форма для контрактов
Эта страница содержит форму и ссылку на CGI-программу, которая обрабатывает данные из формы. В нашем случае используется программа f ormmail (бесплатно распространяемый сценарий CGI, написанный на Perl), которая считывает содержимое формы и отправляет его по почте на предопределенный почтовый адрес. В рассматриваемом примере контактная информация из формы отправляется по почте на главный почтовый адрес книжного магазина.
Forramail написал Matthew M. Wright. Эта программа доступна по адресу http: / /www. worldwideniart.com/scripts/formmail .shtml. Несмотря на то, что в главе не затрагивалось программирование на Perl и CGI, мы приводим исходный код программы. Можно заметить, что создание несложных CGI-программ не требует особых усилий.
# FonriMail Version 1.6 #
# Matt's Script Archive, Inc.: http://www.worldwidemart.com/scripts/
# COPYRIGHT NOTICE #
# пользователем, при условии сохранности авторских прав и
# случаях знаки авторского права и заголовок должны быть сохранены
# Конец
if ($check_referer != 1) { &error <bad_referer') }
# Определить массивы для дней недели и месяцев года.
# Получить текущее время и формат часов, минут и секунд. Добавить
($sec,$min,$hour,$mday,$mon,$year, $wday) = (localtime(time))[0,1,2,3,4,5,6];
# Определить ассоциативный массив для конфигурации
'redirect 1 ,' 1 , 'bgсоlоr', ",
'print_blank_f ields 1 , ' ', 'missing_f ields_redirect', ") ;
# Декодировать кодировку формы для переменных имени и значения
# будет возвращен. Еще одна брешь в защите перекрыта.
# были использованы пробелы между именами полей или переменными среды.
$Config{'required'} =- s/ (\s+|\n)?,(\s+|\n)?/,/g;
$Config{'required'} =- s/ (\s+) ?\n+ (\s+) ?//g;
$Config{'env_report'} =- s/ (\s+ | \n) ?, (\s+ | \n) ?/ , /g;
$C6n£ig{'env_repO3rt'} =- s/ (\s+) ?\n+ ( \s-i-) ? //g;
$Config{'print_config'} =- s/ (\s+| \n) ?, (\s+| \n) ?/, /g;
# Разложить переменные конфигурации по отдельным именам полей.
@Env_Report = split ( / , / , $Conf ig{'env_report'} ) ;
# Локализация переменных, используемых в этой подпрограмме.
# Для каждого обязательного поля, определенного в форме:
# указано его значение или заполнено пробелами, выдать ошибку.
# отметить его как ошибочное поле .
# с адресом переадресации.
# Напечатать заголовок HTTP и открывающие дескрипторы HTTP.,
print "Ниже находится предоставленная вами информация для ";
print "$Conf ig{'recipient'} . Текущая дата: ";
# Если указано, отсортировать по алфавиту:
# полей, то распечатать поле формы и его значение.
# Присвоить временной переменной $sort_order порядок сортировки,
# и разложить поля сортировки в массив.
$sort_order = $Conf ig{'sort'} ;
$sort_order =~ s/(\s+|\n)?, (\s+| \n) ?/, /g;
$sort_order =~ s/ (\s+) ?\n+(\s+)?//g;
# Проверить наличие ссылки возврата и распечатать ее, если нашли.
->formmail.shtml">FormMail</a> V1. 6 ©
1995 -1997 Matt Wright <br> A Free Product of
<a href="http: //www.worldwidemart .com/scripts/">Matt ' s
# Локализация переменных, используемых в этой подпрограмме.
if ($Conf ig{ ' subject '}) { print MAIL "Subject:
print MAIL "Ниже находится предоставленная вами информация .
От кого : \n" ; print MAIL "$Conf ig{'realname'} ($Conf ig{'email'} ) , дата:
# Если указано, отсортировать по алфавиту:
# полей, распечатать поле формы и его значение,
# и разложить поля сортировки в массив.
$Config{'sort'} =~ s/(\s+|\n)?, (\s+ | \n) ?/ , /g;
$Config{'sort'} =~ s/ (\s+) ?\n+ (\s+) ?//g;
$Config{'sort'} =- s/order://;
# Для каждого поля формы, если оно имеет значение или
# Если указаны переменные среды, послать их адресату,
# параметром вызова подпрограммы.
# Если e-mail адрес содержит:
# соответствует следующему шаблону регулярного выражения, то
# знаком @, за которым следует необязательный символ '[',
# стоять символ ' ] ', так как допустимо иметь email-адрес,
if ($ENV{'HTTP_REFERER'} =~ m| ~https? :
<table border=0 width=600 bgcolor=#9C9C9C>
<table border=0 width=600 bgcolor=#CFCFCF> <tr><td>
<a href="http: //www.worldwidemart.com/scripts/formmail.shtiru">FormMail</a>
по адресу
<tt>$ENV{'HTTP_REFERER'}</tt>
Если Вы пытаетесь сконфигурировать FormMail для запуска этой формы,
->вам нужно добавить следующую информацию к \@referers, более
Добавьте <tt>'$host'</tt> в ваш массив <tt><b>\@referers</b></tt>.
<a href="http: //www.worldwidemart.com/scripts/fonnmail.shtnil">
->FormMail</a> VI.6 © 1995 - 1997 Matt Wright<br>
A Free Product of <a href=" http://www.worldwidemart.com/scripts/ ">
<table border=0 width=600 bgcolor=#9C9C9C> <tr>
A Free Product of
<& href="http: //www.worldwidemart.com/scripts/">
<table border=0 width=600 bgcolor=#9C9C9C> <tr>
<tr><td>Meтод запроса предоставленной Вами формы не совпадает ни с
<tt>GET</tt>, ни с <tt>POST</tt>. Пожалуйста, проверьте форму и
<tt>method=</tt> записан в верхнем регистре и является <tt>GET</tt>
<а href="http: / /www. worIdwidemart. com/scripts/ formmai1. shtml">
->ForMail</a> vi.6 © 1995 - 1997 Matt Wright<br>
A Free Product of <a href=" http://www.worldwidemart.com/scripts/ ">Matt's
->Script Archive, Inc.</a> </font></center> </td></tr>
print «"(END ERROR HTML)";
<tr><td>B переданных для FormMail данных не указан получатель. Пожалуйста, убедитесь, что Вы записали в поле формы 'recipient' e-mail адрес. Более подробную информацию по заполнению поля формы recipient можно найти в файле README.<hr size=l>
<a href=" http://www.worldwidemart.com/scripts/formmail.shtml ">
->FormMail</a> VI.6 © 1995 - 1997 Matt Wright
<br> A Free Product of <a href=" http://www . worldwidemart. com/scripts/">Matt's
<table border=0 width=600 bgcolor=fCFCFCF> <tr>
$missing_field_list </ulxbr>
Эти поля должны быть заполнены для успешной подачи формы. <р> Пожалуйста, используйте кнопку Back браузера для возврата к форме ->и исправьте данные. <hr size=l> <center><font size=-l>
<a href ="http : //www. worldwidemart . com/scripts/formmail.shtml">
->FormMail</a> VI. 6 © 1995 - 1997 Matt Wright<br> A Free Product of
<a href="http: //www. worldwidemart. com/scripts/">Matt's
->Script Archive, Inc.</a> < / font>< / center> </td></tr>
Эта профамма возвращает пользователю HTML-страницу, сообщающую о том, что контактна)? информация в форме обработана или содержит ошибки, если таковые имеются. Это очень важный компонент всех CGI-программ - они должны либо вернуть правильные данные браузеру (например. HTML-документ или содержимое файла с изображением), либо перенаправить браузер на правильный URL.
Профамма f ormmail реализует много других функций: она может установить строку темь; (subject) при отправке e-mail и выполнить проверку того, что сценарий не используется незаконно пользователями с других Web-сайтов. Более детальная информация доступна на Web-сайте профаммы.
Последний, важный этап создания Web-сайта - оформление офаничений доступа для каталога /var/www/html/authors/, чтобы только уполномоченные пользователи имели доступ к файлам в этом каталоге. Чтобы сформулировать эти офаничения, нужно решить две задачи Во-первых, следует создать файл пользователей с перечнем необходимых пользователей (мы уже делали это в предыдущем парафафе, посвященном защите каталогов с использованием управления доступом). Нужно создать офаничения доступа для всех пользователей, которым предоставляется доступ к каталогу.
Во-вторых, нужно создать фуппу. Назовем ее authors, чтобы было проще выполнять работ по администрированию доступа к каталогу. Создается эта фуппа добавлением в файл групп (group) Web-сервера строки для фуппы, которая выглядит примерно так:
authors: author1 author2 author3
Эта строка указывает, что трем пользователям предоставляется доступ к каталогу.
Наконец, нужно создать файл .htaccess в каталоге /var/www/html/authors/ ("Auth" в приведенных ниже командах относится к аутентификации, authentication, а не к нашей группе authors).
AuthUserFile /etc/httpd/conf
/users AuthGroupFile /etc/httpd/conf
/groups require group authors
AuthName указывает отображаемую пользователю подсказку. AuthUserFile сообщает серверу, где искать список допустимых пользователей и паролей, a AuthGroupFile - где находится список допустимых групп. Наконец, команда require указывает, что только членам группы authors нужно предоставить доступ к каталогу.
Если пользователь попытается получить доступ к данному каталогу в начале сессии, он увидит диалоговое окно аутентификации, отображаемое браузером, подобное тому, которое отображает Netscape-(pnc. 32.5).
Рис. 32.5. Диалоговое окно аутентификации пользователя в Netscape
По умолчанию, если пользователь не пройдет аутентификацию, он получит страницу с сообщением об ошибке и предложением пройти аутентификацию. Для предоставления специализированной страницы, извещающей об ошибке аутентификации, следует отредактировать файл httpd.conf, чтобы указать на специализированное сообщение об ошибке, добавив в файл следующую строку:
ErrorDocument 401 /error.html
Этот элемент указывает, что при возникновении ошибки 401 (Authorization Required - Требуется аутентификация) сервер должен возвращать указанный URL вместо сообщения по умолчанию. Когда пользователь не пройдет аутентификацию, он получит модифицированную страницу с сообщением о неудачной аутентификации.
Что дальше
Мы узнали, как операционная система Linux может служить гибким инструментом построения сетевого сервера, в данном случае Web-сервера.
Следующая глава посвящена другой важной задаче, которую может решать Linux: работе почтового сервера. Почтовый сервер выполняет обработку всей приходящей и исходящей почты для сети. Он определяет, какие сообщения предназначены для внутренних пользователей (и направляет эти сообщения в их почтовые ящики), а какие - для абонентов внешних сетей (и направляет их в Internet).
Настройка почтового сервера - нетривиальная задача для среды Unix, особенно при использовании программы Sendmail, которая является основным почтовым сервером Linux. Тем не менее, для большинства сетей эта задача выполнима. На почтовый сервер Linux'a можно положиться - он доставляет множество сообщений с небольшими ежедневными затратами по администрированию. Убедитесь в этом сами.