AOLserver
История AOLserver интересна: от коммерческой версии в 1995 году до одного из самых полнофункциональных бесплатных серверов, доступных в настоящее время.
AOLserver появился с именем NaviPress и был одним из первых доступных коммерческих серверов. В конце 1995 года AOL приобрела, компанию, выпустившую NaviPress, и использовала сервер внутри фирмы. В начале 1997 года AOL начала бесплатно распространять сервер по сети Internet.
Во время написания книги последняя версия AOLserver 3.4 поддерживала следующие функции.
Встроенное полное индексирование текста для выполнения функций поиска на Web-сайте.
Встроенный API, доступный из С и языка сценариев Tel.
Полная поддержка CGI и включений со стороны сервера.
Возможность динамического выделения страниц со стороны сервера подобно Active Server Pages фирмы Microsoft.
Связь с базами данных для построения динамических приложений, управляемых базами данных, без использования дополнительных средств интеграции Web и баз данных.
AOLserver можно загрузить с Web-сайта AOLserver по адресу www. aolserver. com/ server/ index.html.
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) модулей для решения множества задач. Из доступных модулей хотелось бы выделить следующие.
Альтернативные системы аутентификации, включая аутентификацию через серверы NIS или базы данных LDAP (Lightweight Directory Access Protocol - Протокол облегченного доступа к каталогам).
Конфигурации сценариев со стороны сервера, которые выполняют те же функции, что и Microsoft Active Server Pages или Netscape Live Wire, включая PHP/FI и HeiTML.
Модули, разработанные для улучшения производительности традиционного CGI. Например, модуль FastCGI использует ярлыки для минимизации времени, затрачиваемого на выполнение программы CGI и возвращение результатов. Модуль Perl позволяет нескольким сценариям Perl выполняться в одном процессе, их компиляция осуществляется только при первом запуске. В результате написанные на Perl сценарии CGI выполняются со скоростью, близкой к скорости выполнения откомпилированных CGI-программ и некоторых Web-приложений, использующих API.
Оригинал исходного кода последней версии Apache, включая откомпилированные выполняемые модули для многих различных систем, в том числе и Linux, доступен на www. apache. org. В Red Hat Linux 7.1 Apache является Web-сервером по умолчанию.
Boa
Boa - последний бесплатный сервер в нашем обзоре. Он малоизвестен, во время работы над книгой была выпущена его первая предварительная версия.
Здесь Boa описан как пример того, что хотя сервер может быть небольшим, простым и даже элементарным, он может выполнять нужную работу. Boa предоставляет только базовую функциональность и имеет меньше возможностей по управлению доступом, чем Apache или WN.
Boa разработан так, что вполне может претендовать на звание самого быстрого из доступных Web-серверов для Linux. Создатели Boa утверждают, что их сервер в два раза быстрее Apache, хотя для доказательства этого заявления требуется дополнительное тестирование на реальных больших Web-сайтах.
Такого выигрыша в производительности Boa достигает за счет однозадачного режима выполнения. Обычные Web-серверы создают несколько процессов для прослушивания запросов, а Boa работает в одном процессе и обрабатывает все приходящие запросы внутри, не используя многозадачный механизм операционной системы. Boa порождает дочерний процесс только при CGI-запросе.
Дополнительная информация о Boa доступна по адресу www. boa. org.
Больше, чем извлечение файлов
Описанная последовательность действий чрезмерно упрощена, но ее цель - описать работу, выполняемую многими Web-серверами.
Конечно же, путешествуя по Web, легко осознать, что Web - это гораздо больше, чем набор статических документов, которые Web-сервер посылает на запросы Web-браузеров. Для запроса информации с сервера или предоставления информации организации-владельцу сервера могут использоваться формы. Можно заказать товары, проверить кредитные карточки и выполнить другие самые разнообразные деловые операции.
Для выполнения таких функций современные Web-серверы должны не только отвечать на HTTP-запросы. Web-серверы обычно обеспечивают два механизма взаимодействий.
Интерфейс простого шлюза (CGI, Common Gateway Interface).
Программный интерфейс приложений сервера (APIs, Application Program Interfaces).
Интерфейс простого шлюза (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-сервер
Пользователи, которые когда-либо использовали Web, вероятнее всего, слышали термин "Web-сервер", но все же они не имеют четкого представления о том, для чего нужен Web-сервер.
Очень часто этот термин имеет двойное значение, обозначая и компьютерное оборудование, и программное обеспечение, выполняемое на компьютере. Корректно использовать термин "Web-сервер" для обозначения программного обеспечения, запускаемого для ответа на запросы Web-клиентов, например Web-браузеров.
Программное обеспечение Web-сервера предназначено для отображения документов, использующих HTTP (Hypertext Transfer Protocol - Протокол передачи гипертекста) и доступных на Web-сайте в ответ на запросы клиентов. Web-сайт использует программное обеспечение Web-сервера.
Последовательность действий следующая: клиент запрашивает документ при помощи URL; Web-сервер принимает запрос, находит в системе URL, соответствующий заданному, - физический файл (который может быть файлом HTML или файлом другого типа). Убедившись, что клиент
имеет разрешение на получение файла, Web-сервер возвращает файл клиенту. Кроме того, обычно Web-сервер ведет запись протокола: кто и какой документ запрашивал, и сколько было запросов, что позволяет получить статистику для определения популярности Web-сайта.
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.
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.
Конфигурационный файл Apache
Хотя подкаталог /etc/httpd/conf включает все три оригинальных конфигурационных файла, собственно конфигурируется только файл httpd. conf. Остальные CONF-файлы оставлены для совместимости с предыдущими версиями.
Структура файла httpd. conf довольно проста. Ниже приведен его листинг по умолчанию:
##
## httpd.conf - конфигурационный файл HTTP-сервера Apache
##
#
# Построил Rob McCool на основе конфигурационных файлов NCSA-сервера. #
# Это основной конфигурационный файл сервера. QH содержит
# конфигурационные директивы для сервера. За дополнительными
# инструкциями обращайтесь по адресу <URL:
http://www.apache.org/docs/
> #
# Если не понятно, о чем речь - лучше не читать. Если в чем-то
# не уверены - обращайтесь к документации в on-line. Вас предупредили. #
# После обработки этого файла, сервер ищет и обрабатывает файлы
# /usr/conf/srm.conf и /usr/conf/access.conf, если вы не заблокировали
# их здесь директивами ResourceConfig и/или AccessConfig.#
# Директивы конфигурирования разбиты на три раздела:
# 1. Директивы, управляющие работой сервера Apache в целом
# (раздел 'global environment') .
# 2. Директивы, определяющие параметры 'сервера 'main' или 'default',
# соответствующие запросам, не обрабатываемы виртуальным хостом.
# Эти директивы также обеспечивают значения по умолчанию для всех
# виртуальных хостов.
# 3. Установки для виртуальных хостов, позволяющие отправлять
# Web-запросы на другие IP-адреса или хосты в расчете на обработку # аналогичным Apache-сервером.
#
# Имена файлов конфигурации и протокола: Если заданные имена файлов
# управления сервером начинаются с "/" (или "drive:/ " для Win32),
# сервер будет использовать явный путь. Если имена не начинаются
# с "/", значение ServerRoot интерпретируется так: "logs/foo.log"
# для ServerRoot, установленного на "/usr/local/apache" будет
# интерпретироваться сервером как "/usr/local/apache/logs/foo.log".
### Раздел 1: Global Environment #
# Директивы этого раздела определяют поведение Apaohe в целом,
# например, задают число параллельно обрабатываемых запросов, # или местоположение конфигурационных файлов.
# #
# ServerType либо inetd, либо standalone. Inetd режим поддерживается
# только на платформе Unix. #
ServerType standalone
#
# ServerRoot: Корень дерева каталогов, в котором сервер хранит # файлы конфигурации, ошибок и протоколов.
#
# Внимание! Если вы хотите разместить его в NFS (или сети), смонтируйте
# файловую систему, затем прочитайте документацию LockFile (доступную
# по адресу <URL:
http://www.apache.org/docs/mod/core.htmlflockfile
>),
# и вы избавите себя от массы забот. #
# Не добавляйте косую черту в конце пути каталога. ServerRoot "/etc/httpd"
#
# Команда LockFile устанавливает путь к файлу блокировки, использующемуся
# если Apache откомпилирован либо с USE_FCNTL_SERIALIZED_ACCEPT, либо с
# USE_FLOCK_SERIALIZED_ACCEPT. Обычно эта команда должна иметь значение
# по умолчанию. Основной причиной, по которой нужно изменять эту
# переменную, является установка каталога протоколов на смонтированной
# NFS, так как файл-блокировки ДОЛЖЕН НАХОДИТЬСЯ НА ЛОКАЛЬНОМ ДИСКЕ.
# PID главного процесса сервера автоматически добавляется к имени файла. #
LockFile /var/lock/httpd.lock
# PidFile: Файл для протоколирования pid сервера PidFile /var/run/httpd.pid
# ScoreBoardFile: Файл для хранения сервером внутренней информации о
# процессе. Требуется не на всех архитектурах. Но если у Вас требуется
# (файл будет создан после запуска Apache), то Вы *должны* убедиться в # том, что ни одна из запускаемых копий Apache не разделяет один и тот # же файл для этой цели.
#
ScoreBoardFile /var/run/httpd.Scoreboard
#
# В стандартной конфигурации сервер обработает этот файл,
# файл srm.conf и access.conf в указанном порядке. Два последних файла
# в этом дистрибутиве пусты, а все директивы объединены в один
# файл для простоты. Ниже приведены закомментированные
# значения по умолчанию. Можно заставить сервер проигнорировать
# эти файлы, задав "/dev/null" (для Unix) или
# "mil" (для Win32) в качестве аргументов директив. #
# ResourceConfig conf/srm.conf
#AccessConfig conf/access.conf
#
# Timeout: Количество секунд перед приемом и посылкой тайм-аута. Timeout 300
# KeepAlive: Разрешить или не разрешить устойчивые соединения (более
# одного запроса на каждое соединение). Для запрещения установите в "Off". KeepAlive On
# MaxKeepAliveRequests: Максимальное количество разрешенных запросов при
# устойчивом соединении. Значение 0 устанавливает неограниченное
#количество. Для обеспечения максимальной производительности рекомендуем
# установить это число большим. # MaxKeepAliveReguests 100
#
# KeepAliveTimeout: Количество секунд для ожидания следующего запроса.
#
KeepAliveTimeout 15
#
# Правила размера серверного пула. Чтобы Вы не гадали, сколько Вам нужно
# процессов для сервера, Apache динамически подстраивается к текущей
# нагрузке — он пытается запустить необходимое количество процессов для # оперирования текущей нагрузкой, плюс несколько резервных серверов для
# обслуживания временных пиков (т.е. нескольких одновременных запросов,
# исходящих из одного браузера Netscape). #
# Делает он это при помощи периодической проверки количества
# серверов, ожидающих запросов. Если их меньше, чем MinSpareServers,
# то он создает дополнительный резерв. Если
больше,
чем
# MaxSpareServers, то он уничтожает некоторые из них.
# Эти значения, вероятно, подходят для многих сайтов #
MinSpareServers 5 MaxSpareServers 20
#
# Количество запускаемых серверов — должно быть умеренное
# приблизительное число. #
StartServers 8
# Предел на общее количество запускаемых серверов, т.е. предел на число
# одновременно соединяющихся клиентов - если этот предел когда-либо
# будет достигнут, клиенты будут ЗАБЛОКИРОВАНЫ, поэтому он НЕ ДОЛЖЕН
# БЫТЬ СЛИШКОМ МАЛЕНЬКИМ. Этот параметр главным образом используется
# как тормоз, чтобы необузданный сервер не потянул за собой Unix,
# который в это время начнет тормозить... #
MaxClients 150
# MaxRequestsPerChild: максимальное количество запросов, разрешенных
# для обработки каждому дочернему процессу перед его удалением.
|
# После этого дочерний процесс будет завершен, чтобы избежать |
||
|
# неприятностей связанных с продолжительным использованием из-за |
||
|
# изъянов Apache (а может и используемых им библиотек) . На многих |
||
|
# системах этот параметр не очень нужен, но некоторые (такие как |
||
|
# Solaris) действительно имеют изъяны в библиотеках. Для таких систем |
||
|
# задайте значение, наподобие 10000; |
||
|
# значение 0 означает "неограниченный". # |
||
|
# Внимание: Это значение не включает keepalive-запросы после .соединения. |
||
|
# Например, если дочерний процесс обрабатывает начальный запрос и 10 |
||
|
# последующих keptalive-запросов, будет учтен только один запрос |
||
|
# при анализе превышения данного предела . |
||
|
# |
||
|
MaxRequestsPerChild 100 |
||
|
# |
||
|
# Listen: Позволяет привязать Apache к конкретным IP-адресам |
||
|
# и/или портам, в дополнение к принятым по умолчанию значениям. |
||
|
# См. также команду VirtualHost. |
||
|
# |
||
|
#Listen 3000 |
||
|
#Listen 12.34.56.78:80 |
||
|
Listen 80 |
||
|
# |
||
|
# BindAddress: Эту сйщию можно использовать для поддержки виртуальных |
||
|
# хостов. Эта опция указывает серверу IP-адрес для прослушивания. Он |
||
|
# может содержать либо "*", либо IP-адрес, либо полное квалифицированное |
||
|
# имя Internet-домена. См. также команду VirtualHost. |
||
|
# |
||
|
# BindAddress * |
||
|
# Поддержка Dynamic Shared Object (DSO - Динамические |
||
|
# совместные объекты) |
||
|
# |
||
|
# Чтобы использовать функциональность модулей, построенных как DSO, |
||
|
# поместите соответствующие строчки 'LoadModule' в этом месте, чтобы |
||
|
# содержащиеся в них команды были доступны до того, как они будут |
||
|
# использованы. Для дополнительной информации о механизме DSO, |
||
|
# пожалуйста, прочтите файл README. DSO из дистрибутива Apache Д. 3 и |
||
|
# запустите 'httpd -1' для получения списка уже встроенных модулей |
||
|
# (они Скомпонованы статически и, таким образом, всегда доступны) |
||
|
# в исполняемом модуле httpd. |
||
|
# # Внимание : Порядок загрузки модулей существенен. Не меняйте |
||
|
# приведенный ниже порядок без консультации со специалистом. |
||
|
# Пример : |
||
|
# LoadModule foo_module libexec/mod_foo.so |
||
|
# |
||
|
# LoadModule imiap_static_module modules /mod_mmap_static. so |
||
|
LoadModule vhost_alias_module modules/mod_vhost_alias.so |
||
|
LoadModule env_module modules /mod_env. so |
||
|
LoadModule conf ig_log_module modules /mod_log_config. so |
||
|
LoadModule agent_log_module modules /mod_log_agent .so |
||
/p>
|
LoadModule referer_log_module modules /mod_log_referer .so |
||
|
#LoadModule mime_magic_module modules /mod_mime_magic .so |
||
|
LoadModule mime_module modules /mod_mime. so |
||
|
LoadModule negotiation_module modules /mod_negotiation. so |
||
|
LoadModule status_module modules /mod_status. so |
||
|
LoadModule info_module modules /mod_info. so |
||
|
LoadModule includes_module modules/mod_include.so |
||
|
LoadModule autoindex_module modules/mod_autoindex.so |
||
|
LoadModule dir_module modules /mod_dir .so |
||
|
LoadModule cgi_module modules /mod_cgi .so |
||
|
LoadModule asis_module modules/mod_asis . so |
||
|
LoadModule imap_module modules /mod_imap. so |
||
|
LoadModule action_module modules /mod_actions . so |
||
|
tLoadModule speling_module modules /mod_speling. so |
||
|
LoadModule userdir_module modules /mod_userdir. so |
||
|
LoadModule alias_module modules/mod_alias .so |
||
|
LoadModule rewrite_module modules /mod_rewrite. so |
||
|
LoadModule access_module modules /mocLaccess. so |
||
|
LuaJWuUule auUuuuQule modules/mod_auth.so |
||
|
LoadModule anon_auth_module modules /mocLauth_anon. so |
||
|
LoadModule db_auth_module modules /mod_auth_db. so |
||
|
#LoadModule digest module modules /mod_dige'st. so |
||
|
#LoadModule proxy_module modules /libproxy. so |
||
|
#LoadModule cern_meta_moduie modules /mod cern_meta.so |
||
|
LoadModule expires_module modules /mod_expires. so |
||
|
LoadModule headers_module modules/mod_headers.so |
||
|
#LoadModule usertrack_module modules /mod_user track. so |
||
|
#LoadMnHn1e example_modul modules /mod_example. so |
||
|
#LoadModule unique_id_module modules /mod_unique_id. so |
||
|
LoadModule setenvif_module moauies/mod_secenvit.so |
||
|
#LoadModule bandwidth_module modules /mod_bandwidth . so |
||
|
ILoadModule put_module modules/mod_put.so |
||
|
<If Define HAVE_PERL> |
||
|
LoadModule perl_module modules /libperl .so |
||
|
</lfDefine> |
||
|
<If Define HAVE_PHP> |
||
|
LoadModule php_module modules /mod_php. so |
||
|
</IfDefine> |
||
|
<IfDefine HAVE_PHP3> |
||
|
LoadModule php3_module modules /libphpS . so |
||
|
</IfDefine> |
||
|
<IfDefine HAVE_PHP4> |
||
|
LoadModule php4_module modules/ Iibphp4. so |
||
|
</IfDefine> |
||
|
<IfDefine HAVE_DAV> |
||
|
LoadModule dav_module modules /libdav. so |
||
|
</IfDefine> |
||
|
<If Define HAVE_ROAMING> |
||
|
LoadModule roaming_module modules /mod_roaming. so |
||
|
</IfDefine> |
||
|
<IfDefine HAVE_SSL> |
||
|
LoadModule ssl_module modules/libssl .so |
||
|
</IfDef ine> |
||
|
# Реконструкция полного списка модулей из всех доступных модулей |
||
|
# (статических и совместных) для обеспечения правильного порядка |
||
/p>
|
# выполнения модулей. |
||
|
# [ВСЯКИЙ РАЗ ПОСЛЕ ПОПРАВОК В СЕКЦИИ LOADMODULE (см. выше) |
||
|
# ТАКЖЕ ОТКОРРЕКТИРУЙТЕ И ЭТУ СЕКЦИЮ] |
||
|
ClearModuleList |
||
|
#AddModule mod_mmap_static.c |
||
|
AddModule mod_vhost_alias.c |
||
|
AddModule mod__env.с |
||
|
AddModule mod_log_conf ig.c |
||
|
AddModule mod_log_agent.c |
||
|
AddModule mod_log_referer.c |
||
|
#AddModule mod_mime_magic . с |
||
|
AddModule mod_mime . с |
||
|
AddModule mod_negotiation.c |
||
|
AddModule mod_status.c |
||
|
AddModule mod_info.c |
||
|
AddModule mod_include.c |
||
|
AddModule mod_auto index . с |
||
|
AddModule mod_dir.c |
||
|
AddModule mod_cgi.c |
||
|
AddModule mod_asis.c |
||
|
AddModule mod_imap.c |
||
|
AddModule mod_actions.c |
||
|
#AddModule mod_spel ing . с |
||
|
AddModule mod_userdir . с |
||
|
AddModule mod_alias.c |
||
|
AddModule mod_rewrite .c |
||
|
AddModule mod_access . с |
||
|
AddModule mod_auth.c |
||
|
AddModule mod_auth_anon . с |
||
|
AddModule mod_auth_db . с |
||
|
#AddModule mod_digest.c |
||
|
#AddModule mod_proxy.c |
||
|
#AddModule mod_cern_meta . с |
||
|
AddModule mod_expires . с |
||
|
AddModule mod_headers . с |
||
|
#AddModule mocLuser track _e |
||
|
#AddModule mod_example.c |
||
|
#AddModule mod_unique_id . с |
||
|
AddModule mod_so.c |
||
|
AddModule mod_setenvif .c |
||
|
#AddModule mod__bandwidth . с |
||
|
#AddModule mod_put.c |
||
|
< If Define HAVE_PERL> |
||
|
AddModule mod_perl.с |
||
|
</IfDefine> |
||
|
<IfDefine HAVE_PHP> |
||
|
AddModule mod_php.c |
||
|
</IfDefine> |
||
|
<IfDefine HAVE_PHP3> |
||
|
AddModule mod_php3 . с |
||
|
</IfDef ine> |
||
|
<If Define HAVE_PHP4> |
||
|
AddModule mod_php4.c |
||
|
</IfDefine> |
||
|
<If Define HAVE_DAV> |
||
|
AddModule mod_dav . с |
||
|
</IfDefine> |
||
|
<IfDefine HAVE_ROAMING> |
||
|
AddModule mod_roaming . с |
||
|
</IfDef ine> |
||
|
<IfDefine HAVE_SSL> |
||
|
AddModule mod_ssl . с |
||
|
</IfDef ine> |
||
|
# ExtendedStatus : определяет, будет ли Apache генерировать |
||
|
# информацию о состоянии в полном объеме (ExtendedStatus On) |
||
|
# или только базисную информацию (ExtendedStatus Off) , |
||
|
# когда вызывается обработчик "server-status". По умолчанию |
||
|
# используется значение Off. |
||
|
# |
||
|
#ExtendedStatus On |
||
|
# |
||
|
### Раздел 2: 'Main' конфигурация сервера |
||
|
# |
||
|
# Директивы этого раздела устанавливают значения, используемые |
||
|
# 'main' сервером, который отвечает на любой запрос, не |
||
|
# обработанный хостом <VirtualHost>. |
||
|
# Эти значения также задают величины по умолчанию для любых |
||
|
# контейнеров <VirtualHost>, которые вы можете |
||
|
# определить позже. |
||
|
# |
||
|
# Все эти директивы могут возникать внутри контейнеров |
||
|
# <VirtualHost>. В этом случае значения по умолчанию будут |
||
|
# заменены этими величинами для виртуальных хостов. |
||
|
# |
||
|
# |
||
|
# Если ваша директива ServerType (см. выше в разделе |
||
|
# 'Global Environment') устанавливает значение "inetd", |
||
|
# следующие несколько директив не оказывают никакого эффекта, |
||
|
# поскольку их значения определены inetd-конфигурацией. |
||
|
# |
||
|
# Переходите к директиве ServerAdmin. |
||
|
# |
||
|
# Port: порт, который прослушивает сервер в режиме standalone. |
||
|
# Если номер порта < 1023, то при загрузке httpd нужно запускать с |
||
|
# привилегиями root . |
||
|
# Port 80 |
||
|
# Чтобы запустить httpd как другого пользователя или группу |
||
|
# пользователей, необходимо вначале запустить httpd как root, a |
||
|
# он затем сам выполнит переключение. |
||
|
# |
||
|
# User/Group: Имя (или #номер) пользователя/группы, под которым |
||
|
# запустить httpd. |
||
|
# На SCO (ОПТ 3) используйте User nouser и Group nogroup |
||
|
# Если на HPUX указать nobody, то нельзя будет использовать |
||
|
# разделяемую память и выходом из положения может быть |
||
|
# создание пользователя www и его использование. |
||
|
# |
||
|
# ПРИМЕЧАНИЕ : в некоторых системах ядро отвергает запросы на |
||
/p> # setgid(Group) или semctl(IPC_SET), если величина (unsigned)
# Group больше 60000;
# не используйте группу nobody на таких системах!
User apache Group apache
# ServerAdmin: Адрес, куда направлять электронную почту
# для решения проблем с сервером.
#
ServerAdmin root@localhost
# ServerName позволяет установить имя хоста, которое будет возвращаться
# клиентам сервера, если оно отличается от имени, получаемого
# программой (т.е. используется "www" вместо настоящего имени хоста). #
# Примечание: Нельзя просто придумать имя хоста и надеяться, что оно
# будет работать. Имя, которое здесь определяется, должно быть
# допустимым DNS-именем для хоста. Если это не понятно -.
# проконсультируйтесь с вашим сетевым администратором.
# Если ваш хост не имеет зарегистрированного DNS-имени, # введите здесь его IP-адрес.
# Вы в любом случае получите доступ к хосту по его адресу
# (например,
http://123.45.67.89/)
и эта директива позволит
# выполнить переадресацию. ServerName localhost
#
# DocumentRoot: Каталог, из которого будут предоставляться документы.
# По умолчанию на все запросы файлы предоставляются из этого каталога,
# но могут использоваться символические ссылки и псевдонимы
# для указания других источников, #
DocumentRoot "/var/www/html"
#
# Каждый каталог, к которому Apache имеет доступ, может быть настроен
# с учетом того, какие сервисы и свойства разрешены и/или запрещены
# в этом каталоге (и его подкаталогах).
# Вначале установим для "default" очень ограниченный набор прав доступа.
#
<Directory />
Options FollowSymLinks AllowOverride None </Directory>
#
# Заметьте: начиная с этого места, необходимо конкретно разрешать
# каждое действие. Если что-то работает не так, как ожидалось,
# убедитесь, что соответствующее действие разрешено.
# Эта строчка должна содержать то же, что и элемент.DocumentRoot.
#
<Directory "/var/www/html">
|
# Здесь допустимы также значения "None", "All" и любые комбинации |
||
|
# "Indexes", "Includes", "FollowSymLinks", "ExecCGI" и "MultiViews". |
||
|
# Заметьте: "MultiViews" должно быть указано *явно* - "Options All" |
||
|
# не устанавливает эту опцию. |
||
|
Options Indexes Includes FollowSymLinks |
||
|
# |
||
|
# Здесь указывается, какие опции могут переопределить файлы .htaccess, |
||
|
# находящиеся в каталогах. Значение может быть "All" или любой |
||
|
# комбинацией "Options", "Filelnfo", "AuthConfig" и "Limit". |
||
|
AllowOverride None |
||
|
# Указывает, кто может брать файлы на этом сервере |
||
|
Order a How, deny |
||
|
Allow from all |
||
|
</Directory> |
||
|
# |
||
|
# UserDir: Имя каталога, которое добавляется к домашнему каталогу |
||
|
# пользователя, если получен запрос типа ~user. |
||
|
# |
||
|
UserDir public_html |
||
|
# |
||
|
# Управление доступом к каталогам UserDir. Ниже приведен пример |
||
|
# для узла, на котором каталоги объявлены доступными только для чтения. |
||
|
# |
||
|
#<Directory /home/*/public_html> |
||
|
# AllowOverride Filelnfo AuthConfig Limit |
||
|
# Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec |
||
|
# <Limit GET POST OPTIONS PROPFIND> |
||
|
# Order allow, deny |
||
|
# Allow from all |
||
|
# </Limit> |
||
|
# <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> |
||
|
# Order" deny, allow |
||
|
# Deny from all |
||
|
# </Limit> |
||
|
#< /Directory> |
||
|
# |
||
|
# Directorylndex: Имя или имена файлов, которые будут использоваться как |
||
|
# индексные файлы HTML. Разделяйте имена пробелами, если их несколько. |
||
|
# |
||
|
Directorylndex index.html index.htm index. shtml index. php index. php4 |
||
|
-> index . php3 index . cgi |
||
|
# |
||
|
# AccessFileName: Имя файла, который нужно искать в каждом каталоге |
||
|
# и который содержит информацию по управлению доступом. |
||
|
# |
||
|
AccessFileName .htaccess |
||
/p>
|
# |
||
|
# Следующие строки защищают файлы .htaccess от просмотра |
||
|
# Web- клиентами. Поскольку файлы .htaccess часто содержат |
||
|
# сведения об авторизации, доступ закрывается из соображений |
||
|
# безопасности. Закомментируйте эти строки, если хотите |
||
|
# предоставить Web-клиентам возможность просмотра содержимого |
||
|
# файлов .htaccess. Если вы изменили директиву AccessFileName |
||
|
# выше, то внесите соответствующие изменения и здесь. |
||
|
# Поскольку часто для файлов парольной защиты используются |
||
|
# файлы .htpasswd, защита будет обеспечена. |
||
|
# |
||
|
<Files - н/ч \ .ht"> |
||
|
Order allow, deny |
||
|
Deny from all |
||
|
</Files> |
||
|
# |
||
|
# CacheNegotiatedDocs : По умолчанию Apache посылает псевдокомментарий: |
||
|
# не кэшировать содержимое документов по договоренности. Это указывает |
||
|
# прокси-серверу не кэшировать документы. Раскомментирование нижестоящей |
||
|
# строки отменяет это действие и прокси-серверам будет разрешено |
||
|
# кэширование документов. |
||
|
# |
||
|
# CacheNegotiatedDocs |
||
|
# |
||
|
# UseCanonicalName: (появилось в 1.3) Если включить эту опцию, то |
||
|
# всякий раз, когда Apache нужно построить самоссылающийся URL |
||
|
# (URL, который ссылается на сервер, с которого идет ответ) , он будет |
||
|
# использовать ServerName и Port для формирования "канонического" |
||
|
# имени. Когда эта опция выключена, сервер будет использовать |
||
|
# переданный клиентом hostname:port, если это возможно. Это также влияет |
||
|
# на SERVER NAME И SERVER PORT в CGI. |
||
|
# |
||
|
UseCanonicalName On |
||
|
# |
||
|
# TypesConfig указывает где нужно искать файл mime. types (или его аналог) |
||
|
# |
||
|
TypesConfig /etc /mime. types |
||
|
# |
||
|
# DefaultType - тип MIME по умолчанию для тех документов, тип |
||
|
# которых сервер не может определить по расширению файлов. |
||
|
# Если ваш сервер содержит в основном текстовые или |
||
|
# HTML-документы, следует задать значение "text/plain". |
||
|
# Если содержимое в основном дцоичное, например, приложения |
||
|
# или иллюстрации, можно использовать значение |
||
|
# "application/ octet-stream", чтобы заблокировать попытки |
||
|
# браузеров отобразить двоичные файлы как текст. |
||
|
# |
||
|
DefaultType text/plain |
||
|
# |
||
|
# mod mime magic позволяет серверу использовать различные |
||
/p>
|
# особенности самого файла для определения его типа. |
||
|
# Директива MIMEMagicFile указывает модулю, где |
||
|
# расположены предлагаемые определения.. |
||
|
# mod mime magic не является частью сервера по умолчанию |
||
|
# (необходимо добавить его самостоятельно с помощью |
||
|
# LoadModule [см параграф DSO в разделе 'Global Environment'], |
||
|
# или рекомпилировать сервер и включить mod mime_magic |
||
|
# как часть конфигурации) , поэтому он заключен в контейнер |
||
|
# <IfModule>. |
||
|
# Это значит, что директива MIMEMagicFile будет отработана |
||
|
# только если модуль является частью сервера. |
||
|
# |
||
|
<IfModule mod_mime_magic . о |
||
|
MIMEMagicFile /usr/ share/magic |
||
|
</IfModule> |
||
|
# |
||
|
# HostnameLookups : Протоколировать имена клиентов или же только |
||
|
# их IP-адреса т.е. www.apache.org (on) или 204.62.129.132 (off) |
||
|
# По умолчанию off, так как для сети намного лучше, когда люди |
||
|
# должны сознательно включать эту опцию. Вариант on приводит |
||
|
# к тому, что каждый клиентский запрос порождает по крайней |
||
|
# мере одно обращение к серверу имен. |
||
|
# |
||
|
HoetnameLookupe O££ |
||
|
# |
||
|
# ErrorLog: Расположение файла протокола ошибок. |
||
|
# Если директива ErrorLog не задана в контейнере |
||
|
# <VirtualHost>, сообщения об ошибках, касающихся |
||
|
# виртуального хоста, будут регистрироваться здесь. |
||
|
# Если вы определили файл регистрации ошибок для |
||
|
# контейнера <VirtualHost>, то сообщения об .ошибках хоста |
||
|
# будут регистрироваться в этом файле, а не здесь. |
||
|
# |
||
|
ErrorLog /var/log/httpd/error_log |
||
|
# |
||
|
# Log~Level: Управляет количеством сообщений, |
||
|
# записывающихся в error log. |
||
|
# Перечень возможных вариантов: debug, info, notice, warn, |
||
|
# error, crit, alert, emerg. |
||
|
# |
||
|
LogLevel warn |
||
|
# |
||
|
# Далее следуют команды, определяющие формат мнемонических |
||
|
# имен, которые будут использоваться в команде CustomLog (см. ниже) . |
||
|
# |
||
|
LogFormat "%h %1 %u %t \"%r\" %>s %b \ "%{Referer}i\" \"%{User- |
||
|
-> Agent }i\" " combined |
||
|
LogFormat "%h %1 %u %t \"%r\" %>s %b" common |
||
|
LogFormat "%{Referer}i -> %U" referer |
||
|
LogFormat "% {User-agent}!" agent |
||
/p>
|
# |
||
|
# Расположение файла протокола доступа (Обычный Формат Протокола) . |
||
|
# Если вы не определили никаких файлов протокола доступа в контейнере |
||
|
# <VirtualHost>, транзакции будут регистрироваться здесь. |
||
|
# Если вы определили файл регистрации для контейнера |
||
|
# <VirtualHost>, то транзакции; хоста будут регистрироваться |
||
|
# в этом файле, а не здесь. |
||
|
# |
||
|
CustomLog /var/log/httpd/access_log common |
||
|
# # Если нужен файл протокола для агентов и рекомендателей - |
||
|
# раскомментируйте нижестоящие команды. |
||
|
# |
||
|
# CustomLog /var/log/httpd/referer_log referer |
||
|
# CustomLog /var/log/httpd/agent_log agent |
||
|
# Чтобы использовался один общий файл для протоколирования доступа, |
||
|
# агента и рекомендателя (Комбинированный Файл Протокола) можно |
||
|
# использовать следующую команду. |
||
|
# |
||
|
# CustomLog /var/log/httpd/access_log combined |
||
|
# |
||
|
# Можно добавить строку, содержащую версию сервера |
||
|
# и имя виртуального хоста для страниц, сгенерированных |
||
|
# сервером (сообщения об ошибках,, списки ЕТР-каталогов, |
||
|
# вывод mod status и mod info и т.п., |
||
|
# но не документы, сгенерированные CGI) . |
||
|
# Задайте значение "EMail", чтобы также включить ссылку |
||
|
# mailto: на ServerAdmin. |
||
|
# Задайте одно из значений: On | Off | EMail |
||
|
# |
||
|
ServerSignature On |
||
|
# |
||
|
# Aliases: Укажите здесь столько псевдонимов, сколько' необходимо |
||
|
# (без ограничения) . Формат следующий: Alias fakename realname |
||
|
# |
||
|
# Заметьте: если завершить фиктивное имя fakename символом "/", |
||
|
# то сервер требует его присутствия в URL. Так, "/icons" не замещается |
||
|
# в этом примере. |
||
|
# |
||
|
Alias /icons/ "/var/www/ icons/" |
||
|
<Directory " /var/www/ icons "> |
||
|
Options Indexes MultiViews |
||
|
AllowOverride None |
||
|
Order a 1 1 ow , deny |
||
|
Allow from all |
||
|
</Directory> |
||
|
# |
||
|
# ScriptAlias: Указывает каталоги, в которых находятся сценарии сервера. |
||
|
# ScriptAliases по сути представляют собой то же самое, что и Aliases, |
||
|
# кроме документов из каталога realname, которые интерпретируются |
||
/p>
|
# как приложения и запускаются сервером по запросу вместо отправки |
||
|
# клиенту в качестве документов . |
||
|
# Правила в отношении "/"/ описанные выше для Alias, |
||
|
# справедливы и для директив ScriptAlias . |
||
|
# |
||
|
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/ " |
||
|
# |
||
|
# "/var/www/cgi-bin" следует заменить на CGI-каталог |
||
|
# ScriptAliased, если он существует и сконфигурирован. |
||
|
# |
||
|
<Directory "/var/www/cgi-bin"> |
||
|
AllowOverride None |
||
|
Options ExecCGI |
||
|
Order allow, deny |
||
|
Allow from all |
||
|
</Directory> |
||
|
# Redirect позволяет указать клиентам те документы, которые раньше |
||
|
# были в вашем пространстве имен, а теперь отсутствуют. Это позволяет |
||
|
# вам сообщить клиентам, где можно найти перемещенный документ. |
||
|
# Формат: Redirect old-URI new-URL |
||
|
# |
||
|
# |
||
|
# Директивы, управляющие отображением листингов, |
||
|
# сгенерированных сервером. |
||
|
# |
||
|
# |
||
|
# Fancy Indexing указывает на тип индексирования .каталогов - |
||
|
# узорчатый или стандартный. |
||
|
# |
||
|
IndexOptions Fancylndexing |
||
|
# |
||
|
# Addlcon указывает серверу какие значки показывать для |
||
|
# различных файлов или расширений файлов. Они отображаются |
||
|
# только для проиндексированных Fancylndexing каталогов. |
||
|
# |
||
|
AddlconByEncoding (CMP, /icons /compressed. gif) x-compress x-gzip |
||
|
AddlconByType (TXT, /icons /text. gif) text/* |
||
|
AddlconByType (IMG, /icons /irnage2 .gif ) image/* |
||
|
AddlconByType ( SND , / icons / sound2 .gif) audio / * |
||
|
AddlconByType (VID, /icons /movie.gif) video/* |
||
|
Addlcon /icons /binary. gif .bin .exe |
||
|
Addlcon / icons /binhex. 'gif .hqx |
||
|
Addlcon /icons /tar. gif .tar |
||
|
Addlcon /icons /world2 .gif .wrl .wrl.gz .vrml .vrm .iv |
||
|
Addlcon /icons /compressed. gif .z .z .tgz .gz .zip |
||
|
Addlcon /icons /a. gif .ps .ai .eps |
||
|
Addlcon /icons /layout. gif .html .shtml .htm .pdf |
||
|
Addlcon /icons /text. gif . txt |
||
/p>
|
Addlcon /icons/c.gif .с |
||
|
Addlcon /icons/p.gif .pi .py |
||
|
Addlcon / icons /f. gif .for |
||
|
Addlcon /icons/dvi.gif .dvi |
||
|
Addlcon /icons /uuencoded.gif .uu |
||
|
Addlcon /icons/script. gif .conf .sh . shar .csh . ksh .tcl |
||
|
Addlcon / icons /tex. gif .tex |
||
|
Addlcon /icons /bomb. gif core |
||
|
Addlcon /icons /back. gif .. |
||
|
Addlcon /icons/hand. right. gif README |
||
|
Addlcon /icons /folder. gif ^^DIRECTORY^^ |
||
|
Addlcon /icons /blank. gif ^^BLANKICON^^ |
||
|
# |
||
|
# Defaultlcon указывает, какой значок .использовать для файлов, |
||
|
# для которых он явно не указан. |
||
|
# |
||
|
Defaultlcon /icons/unknown. gif |
||
|
# AddDescription позволяет разместить краткое описание после. |
||
|
# имени файла в генерируемых сервером индексах. |
||
|
# Формат: AddDescription "описание" ИмяФайла |
||
|
# |
||
|
# AddDescription "GZIP compressed document" . gz |
||
|
# AddDescription "tar archive" .tar |
||
|
# AddDescription "GZIP compressed tar archive" .tgz |
||
|
# |
||
|
# |
||
|
# ReadmeName - имя README-файла, которое сервер будет искать |
||
|
# по умолчанию, чтобы добавить к списку каталогов. |
||
|
# |
||
|
# HeaderName - имя файла, которое сервер будет искать, |
||
|
# чтобы добавить к началу индекса каталогов. |
||
|
# |
||
|
# Сервер сначала будет искать файл name.html и учтет его, |
||
|
# если найдет. Если этот файл не обнаружится, то будет |
||
|
# выполнен поиск файла name . txt . Если сервер найдет |
||
|
# этот файл, то включит его как текстовый файл. |
||
|
# |
||
|
ReadmeName README |
||
|
HeaderName HEADER |
||
|
# |
||
|
# Indexlgnore - список имен файлов, игнорируемых |
||
|
# при индексировании каталога. Разрешается использование |
||
|
# символов подстановки в соответствии с синтаксисом оболочки. |
||
|
# |
||
|
Indexlgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t |
||
|
# |
||
|
# AddEncoding позволяет указать некоторым браузерам |
||
|
# (Mosaic/X 2.1+) распаковывать информация? на лету. |
||
|
# Примечание : не все браузеры это поддерживают . |
||
/p> # Несмотря на схожесть названий, следующие директивы Add*
# не оказывают влияния на директивы настройки FancyIndexing
# приведенные выше. #
AddEncoding x-compress Z AddEncoding x-gzip gz
#
# AddLanguage позволяет указать язык, используемый в документе., Затем
# можно выполнить согласование содержимого, чтобы вернуть браузеру файл
# использованием понимаемого им языка. Заметьте: суффикс не обязан быт
# таким же, как и ключевое слово языка - те, кто имеет документы на
# польском, для которого стандартный сетевой код pi, могут использоват
# "AddLanguage p1.ро" во избежание двусмысленности с таким же
# суффиксом для сценариев perl. #
AdSLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
AddLanguage da .da
AddLanguage el .el
AddLanguage it .it
#
# LanguagePriority позволяет назначить приоритет для некоторых
# языков на случай, если при согласовании содержимого не удастся
# достичь единого мнения.
# Просто перечислите языки в убывающем порядке предпочтения. #
LanguagePriority en fr de
#
# AddType позволяет откорректировать mime.types без их реальной
# модификации, а также позволяет установить определенный тип
# для некоторых файлов.
# Далее приведены директивы для РНР4 (конфликт с PHP/FI, ниже): <IfModule mod_php4.c>
AddType application/x-httpd-php .php4 .php3 .phtml .php
AddType application/x-httpd-php-source .phps </IfModule>
# Далее приведены директивы для РНРЗ: <IfModule mod_php3.c>
AddType application/x-httpd-php3 .php3
AddType application/x-httpd-php3-source .phps </IfModule>
# Далее приведены директивы для PHP/FI (PHP2):
<IfModule mod_php.c>
AddType application/x-httpd-php .phtml </IfModule>
AddType application/x-tar .tgz
# AddHandler позволяет назначить некоторые расширения файлов
# "обработчикам", действия которых не связанны с типом файлов.
# Их можно встроить в сервер либо добавить командой Action (см. ниже). #
# Если вы хотите использовать дополнения на сервере, или CGI вне
# каталогов ScriptAliased, раскомментируйте следующие строки. #
# Для использования сценариев CGI: #
AddHandler cgi-script .cgi #
# Для использования файлов HTML, анализируемых сервером: #
AddType text/html .shtml AddHandler server-parsed .shtml
#
# Раскомментируйте следующую строку, чтобы разрешить
# использовать свойство Apache "send-asis HTTP file" #
#AddHandler send-as-is asis
#
# Для использования файлов рисунков, анализируемых сервером: #
AddHandler imap-file map #
# Чтобы разрешить использование плат типов: #
#AddHandler type-map var
# Action позволяет указать типы источников, которые будут запускать
# сценарий при указании соответствующего файла. Это позволяет
# избежать использования повторяющихся URL в часто используемых
# процессорах CGI-файлов.
# Формат: Action media/type /cgi-script/location
I Формат: Action handler-name /cgi-script/location #
# MetaDir: указывает имя каталога, в котором Apache может
# найти метафайлы. Эти файлы содержат дополнительные HTTP-заголовки,
# включаемые в документы при отправке.
# #MetaDir .web
#
# MetaSuffix: указывает суффикс имен файлов, содержащих метаинформацию. #
# MetaSuffix .meta
#
# Настраиваемые ответные сообщения об ошибках (стиль Apache)
# имеется три варианта #
# 1) обычный текст
# ErrorDocument 500 "The server made a boo boo.
|
# N.B. Символ (") является признаком текста и не отображается |
||
|
# 2) локальное перенаправление |
||
|
#ErrorDocument 404 /missing.html |
||
|
# для перенаправления на локальный URL /missing.html |
||
|
#ErrorDocument 404 /cgi-bin/missing_handler .pi |
||
|
# N.B. Можно перенаправлять на сценарий или документ, |
||
|
# используя включения со стороны сервера. |
||
|
# |
||
|
# 3) внешнее перенаправление |
||
|
#ErrorDocument 402 http : / /some . other_server . com/subscription_inf о . html |
||
|
# N.B. Многие переменные окружения, связанные |
||
|
# с исходным запросом, в таком сценарии будут недоступны. |
||
|
# |
||
|
# Следующие команды модифицируют обычную процедуру ответа HTTP. |
||
|
# Первая команда запрещает keepalive для Netscape 2.x и браузеров, |
||
|
# которые представляются как Netscape 2.x. Известны проблемы, |
||
|
# связанные с этим. Вторая команда - для Microsoft Internet |
||
|
# Explorer 4.0Ь2, которая имеет неправильную реализацию НТТР/1.1 |
||
|
# и неправильно поддерживает keepalive, когда эта опция |
||
|
# используется в ответах 301 и 302 (перенаправление) . |
||
|
BrowserMatch "Mozilla/2" nokeepalive |
||
|
BrowserMatch "MSIE 4\.0b2; " nokeepalive downgrade- 1.0 force-response- 1. 0 |
||
|
# |
||
|
# Следующие команды запрещают ответы HTTP/1.1 браузерам, |
||
|
# которые нарушают спецификацию НТТР/1 отсутствием понимания самых |
||
|
# простых ответов 1.1. |
||
|
# |
||
|
BrowserMatch "RealPlayer 4\.0" force-response-1 .0 |
||
|
BrowserMatch "Java/l\.0" force-response-1 . 0 |
||
|
BrowserMatch "ODK/IN.O" force-response-1 .0 |
||
|
# Если модуль perl установлен, то следующие директивы выполнятся. |
||
|
<IfModule mod_perl.c> |
||
|
Alias /perl/ /var/www/perl/ |
||
|
<Location /perl> |
||
|
SetHandler perl-script |
||
|
PerlHandler Apache: : Registry |
||
|
Options +ExecCGI |
||
|
</Location> |
||
|
</IfModule> |
||
|
# |
||
|
# Разрешает http-размещение (наподобие публикации в Netscape Gold) . |
||
|
# Используйте htpasswd для генерации /etc/httpd/conf/passwd. |
||
|
# Необходимо раскомментировать эти две строки и в начале этого файла: |
||
|
# |
||
|
#LoadModule put_module modules /mod_put. so |
||
|
#AddModule mod_put.c |
||
|
# |
||
|
#Alias /upload /tmp |
||
|
#<Location /upload> |
||
|
# EnablePut On |
||
/p>
|
# AuthType Basic |
||
|
# AuthName Temporary |
||
|
# AuthUserFile /etc/httpd/conf/passwd |
||
|
# EnableDelete Off |
||
|
# umask 007 |
||
|
# <bimit PUT> |
||
|
# require valid-user |
||
|
# </Limit> |
||
|
#</Location> |
||
|
# |
||
|
# Позволяет серверу возвращать отчет, находящийся по URL |
||
|
# http://servername/server-status |
||
|
# Для включения этого режима следует изменить |
||
|
# ".your_domain.com" на ваш домен. |
||
|
# |
||
|
#<Location /server-status> |
||
|
# SetHandler server-status |
||
|
# Order deny, allow |
||
|
# Deny from all |
||
|
# Allow from .your_domain.com |
||
|
#</Location> |
||
|
# Позволяет отчеты о конфигурации удаленного сервера |
||
|
# с URL http: //servername/server-info |
||
|
# (необходимо, чтобы mod info. с был загружен) |
||
|
# Для включения этого .режима следует изменить |
||
|
# ".your_domain.com" на ваш домен. |
||
|
# |
||
|
#<bocation /server- info> |
||
|
# SetHandler server- info |
||
|
# Order deny, allow |
||
|
# Deny from all |
||
|
# Allow from .your_dpmain.com |
||
|
#</Location> |
||
|
# Разрешает доступ к документам локального компьютера с localhost |
||
|
Alias /doc/ /usr/share/doc/ |
||
|
<Location /doo |
||
|
order deny, allow |
||
|
deny from all |
||
|
allow from localhost |
||
|
Options Indexes FollowSymLinks |
||
|
</Location> |
||
|
# Имеются сообщения, что некоторые люди пытаются незаконно использовать |
||
|
# старую ошибку со времен версии 1.1. Эта ошибка была в сценарии CGI, |
||
|
# поставлявшемся как часть Apache. Сняв комментарии с этих строк, можно |
||
|
# перенаправить эти атаки на протоколирующий сценарий, который находится |
||
|
# на phf.apache.org. Или можно самостоятельно записывать их, |
||
|
# используя сценарий support/phf abuse log.cgi. |
||
|
# |
||
|
#<Location /cgi-bin/phf*> |
||
|
# Deny from all |
||
/p> ### Раздел З: Виртуальные хосты
# VirtualHost: Если вы хотите поддерживать несколько
# доменов/имен хостов на вашем компьютере, можете задать
# для них контейнеры VirtualHost. См. документацию по адресу
# <URL:
http://www.apache.org/docs/vhosts/
>
# для ознакомления с подробностями перед тем, как
# приступить к установке виртуальных хостов.
# Можно использовать в командной строке опцию '-S', чтобы
# проверить конфигурацию вашего виртуального хоста.
#
# Если вы хотите использовать именованные виртуальные
# хосты, необходимо определить, по крайней мере, один
# IP-адрес (и номер порта) для них. #
#NameVirtualHost 12.34.56.78:80 #NameVirtualHost 12.34.56.78
|
# |
||
|
# Пример VirtualHost: |
||
|
# Практически любая директива Apache может вставляться в |
||
|
# контейнер VirtualHost . |
||
|
# |
||
|
# <VirtualHos t ip . address . of . host . some_domain . com> |
||
|
# ServerAdmin webmasterShost .some_domain.com |
||
|
# DocumentRoot /www/docs/host . some_domain. com |
||
|
# ServerName host . some_domain . com |
||
|
# ErrorLog logs/host .some_domain.com-error_log |
||
|
# CustomLog logs /host. some_domain.com-access_log common |
||
|
#</VirtualHost> |
||
|
#<VirtualHost _default_:*> |
||
|
#</VirtualHost> |
||
|
<If Define HAVE_SSL> |
||
|
## |
||
|
## SSL Virtual Host Context |
||
|
## |
||
|
# По умолчанию Apache только слушает порт 80. |
||
|
# Определение виртуального сервера (см. ниже) не вызывает |
||
|
# автоматического прослушивания порта виртуального сервера. |
||
|
Listen 443 |
||
|
<VirtualHost _default_:443> |
||
|
# Общая установка виртуального хоста |
||
|
DocumentRoot "/var/www/html" |
||
|
# SSL Engine ключ: |
||
|
# Разрешение/запрет SSL для этого виртуального хоста. |
||
|
SSLEngine on |
||
|
# SSL шифры: |
||
|
# Список шифров, которые клиент может использовать. |
||
|
# См. в документе mod ssl полный список шифров. |
||
|
#SSLCipherSuite ALL: !ADH:RC4+RSA:+HIGH: +MEDIUM: +LOW: +SSLv2 : +EXP: +eNULL |
||
|
# Сертификат сервера: |
||
|
# Адресует SSLCertificateFile на РЕМ-кодированный сертификат. |
||
|
# Если сертификат зашифрован, появится запрос пароля. |
||
|
# Обратите внимание: kill -HUP- вызовет повторный запрос |
||
|
# пароля. Тестовый сертификат можно сгенерировать с помощью |
||
|
# `make certificate' в ходе построения. Если вы используете и |
||
|
# RSA и DSA сертификаты, то оба можно конфигурировать одновременно |
||
|
# (чтобы также разрешить использование шифров DSA и т.д.) . |
||
|
SSLCertificateFile /etc/httpd/conf /ssl .crt/server ,crt |
||
|
#SSLCertif icateFile /etc/httpd/conf /ssl . crt/server-dsa. crt |
||
|
# Частный ключ сервера: |
||
|
# Если ключ не объединен с сертификатом, используйте эту директиву, |
||
|
# чтобы указать файл ключа. Если вы используете и RSA и DSA |
||
|
# сертификаты, то оба можно конфигурировать одновременно |
||
|
# (чтобы также разрешить использование шифров DSA и т.д.) . |
||
/p>
|
SSLCertif icateKeyFile /etc/httpd/conf /ssl . key/server . key |
||
|
#SSLCertificateKeyFile /etc/httpd/conf /ssl. key/server-dsa. key |
||
|
# Цепочка сертификатов сервера : |
||
|
# Адресует SSLCertificateChainFile на файл, содержащий |
||
|
# соединение РЕМ- кодированных СА- сертификатов. Он |
||
|
# формирует цепочку сертификатов для серверного сертификата . |
||
|
# Альтернатива: указанный файл может быть тем же, что и файл |
||
|
# SSLCertificateFile, если СА-сертификаты, для удобства, |
||
|
# непосредственно связаны с серверным сертификатом. |
||
|
#SSLCertificateChainFile /etc/httpd/conf /ssl . crt/ca.crt |
||
|
# Авторизация сертификата (СА) : |
||
|
# Задайте пути верификации сертификата СА, т.е. место где |
||
|
# можно найти сертификаты СА для аутентификации клиентов или |
||
|
# один большой файл, содержащий все сертификаты (файл должен |
||
|
# быть РЕМ-кодированным) . |
||
|
# Внимание : Внутри SSLCACertificatePath следует |
||
|
# хешировать ссылки на файлы сертификатов. Пользуйтесь |
||
|
# Makefile для обновления хешированных ссылок после |
||
|
# внесения изменений. |
||
|
#SSLCACertificatePath /etc/httpd/conf /ssl. crt |
||
|
#SSLCACertificateFile /etc/httpd/conf /ssl. crt/ca-bundle. crt |
||
|
# Список отмененных сертификатов (CRL) : |
||
|
# Задайте путь отмененных СА, чтобы можно было найти список |
||
|
# отмененных СА для аутентификации клиентов или один большой файл, |
||
|
# содержащий все сертификаты (файл должен быть РЕМ-кодированным) . |
||
|
# Внимание : Внутри SSLCARevocationPath следует |
||
|
# хешировать ссылки на файлы сертификатов. Пользуйтесь |
||
|
# Makefile для обновления хешированных ссылок после |
||
|
# внесения изменений. |
||
|
#SSLCARevocationPath /etc/httpd/conf /ssl . crl |
||
|
#SSLCARevocationFile /etc/httpd/conf /ssl . crl/ca-bundle. crl |
||
|
# Аутентификация клиента (тип) : |
||
|
# Тип и глубина верификации сертификатов клиентов. Типы: |
||
|
# none, optional, require и optional no ca. Глубина |
||
|
# задается как номер, который определяет, насколько глубоко |
||
|
# следует проверять цепочку издателя сертификата, |
||
|
# чтобы убедиться в негодности сертификата. |
||
|
#SSLVerifyClient require |
||
|
#SSLVerifyDepth 10 |
||
|
# Контроль доступа: |
||
|
# Посредством SSLRequire можно управлять доступом к каталогам, |
||
|
# задавая произвольные булевы выражения, содержащие обращения |
||
|
# к серверным переменным. Синтаксис выражений представляет собой |
||
|
# нечто среднее между С и Perl. Подробности см. в файле mod ssl. |
||
|
#<Location /> |
||
|
#SSLReqUire ( %{SSL_CIPHER) ! ~ m/ n (ЕХР |NULL) -/ \ |
||
|
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ |
||
|
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ |
||
|
# and %{TIME_WDAY) >= 1 and %{TIME_WDAY} <= 5 \ |
||
|
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ |
||
/p>
|
tt or %{REMOTE_ADDR) =~ m/ n !92\ .76\ . 162\ . [0-9] +$/ |
||
|
#</Location> |
||
|
# Опции SSL Engine: |
||
|
# Установка различных опций SSL engine. |
||
|
# о FakeBasicAuth: |
||
|
# Трансляция клиента Х.509 в Basic Authorisation. |
||
|
# Это значит, что для контроля доступа могут |
||
|
# использоваться стандартные методы Auth/DBMAuth. |
||
|
# Имя пользователя представляет собой однострочную версию |
||
|
# клиентского сертификата Х.509. |
||
|
# Обратите внимание, что от пользователя не требуется |
||
|
# пароль. Каждый ввод в пользовательском файле требует |
||
|
# пароля: ~xxj31ZMTZzkVA' . |
||
|
# о ExportCertData : |
||
|
# Экспортируются две дополнительных переменных: |
||
|
# SSL CLIENT CERT и SSL_SERVER_CERT . Они |
||
|
# содержат РЕМ-кодированные сертификаты сервера |
||
|
# (они существуют всегда) и клиента (существуют |
||
|
§ только, если используется аутентификация клиента) . |
||
|
# Это можно использовать для импорта сертификатов |
||
|
# в CGI- сценарии. |
||
|
# о StdEnvVarc: |
||
|
# Экспортируются V SSL *' переменные окружения, |
||
|
# относящиеся к стандартным SSL/TLS. |
||
|
# По умолчанию это экспортирование заблокировано из |
||
|
# соображений производительности, поскольку операция |
||
|
# извлечения относится к достаточно дорогим, и бесполезна |
||
|
# для обслуживания статического контента. Поэтому |
||
|
# разрешение выдается обычно только для CGI- и |
||
|
# SSI-запросов. |
||
|
# о CompatEnvVars : |
||
|
# Экспортируются устаревшие переменные окружения |
||
|
# для совместимости со старыми версиями Apache-SSL 1.x, |
||
|
# mod ssl 2.0.x, Sioux 1.0 и Stronghold 2.x. Используйте |
||
|
# для совместимости с существующими CGI-сценариями. |
||
|
# о StrictRequire: |
||
|
# Запрещается доступ, когда применяется "SSLRequireSSL" |
||
|
f или "SSLRequire", даже в ситуации "Satisfy any", |
||
|
# т.е. когда применяется эта опция, доступ запрещен |
||
|
# и никакой другой модуль изменить этого не может.. |
||
|
# OptRenegotiate: |
||
|
# Разрешает оптимизированную обработку SSL-соединения |
||
|
# когда SSL-директивы используются в контексте |
||
|
# отдельного каталога. |
||
|
tSSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire |
||
|
<Files ~ "\. (cgi|shtml)$"> |
||
|
SSLOptions +StdEnvVars |
||
|
</Files> |
||
|
<Directory "/var/www/cgi-bin"> |
||
|
SSLOptions +StdEnvVars |
||
|
</Directory> |
||
|
# Примечание: Большинство проблем взлома клиентов |
||
|
# связаны с возможностями подтверждения активности |
||
|
# HTTP (keepalive) , поэтому следует запретить keepalive |
||
/p> # для этих клиентов. Используйте для этого переменную
# "nokeepalive".
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
# Протокол для каждого сервера:
# Место хранения пользовательского SSL файла протокола,
# Используйте эту опцию, если нужен компактный файл
# протокола SSL (без ошибок) на виртуальном хосте.
CustomLog /var/log/httpd/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
</IfDefine>
Заметьте: этот файл содержит и комментарии, и реальные команды конфигурирования. Комментарии начинаются с символа диеза (#). Команды состоят из имени команды, за которым следует параметр.
В файле httpd.conf три раздела: Global Environment, Main Server Configuration и Virtual Hosts. Рассмотрим каждый из них подробно.
Конфигурирование 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-сервере можно стлать сколько угодно виртуальных хостов. Но каждый 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: tcp в поле Other Ports (Другие порты) в разделе Customization (Настройка).
User И Group
Команды User и Group - критические элементы, так как они оказывают существенное влияние на безопасность системы. Обычно httpd запускается как root, но этот процесс не прослушивает соединения. Чаще этот процесс запускает один или несколько дочерних процессов user и group (указанные именем либо ID-номером), определенных этими командами конфигурации.
Запуск процессов Web-сервером, включая программы CGI, в режиме root является огромным риском, особенно если плохо написанный сценарий CGI оставляет большие бреши в защите. Запустив Web-сервер и связанные с ним дочерние процессы под именем пользователя с ограниченными привилегиями, можно снизить опасность успешных атак на сервер.
Обычно Web- сервер запускают под именем apache группой apache или #-1. Автор книги чаще всего использует имя apache и группу apache, так как их легко идентифицировать при чтении файла конфигурации. Это имя (apache) имеет ограниченные привилегии в системе и потенциальный хакер может нанести ограниченный вред, если сценарий CG1 позволит ему прорваться в систему.
Так как большинство этих модулей конфигурируется посредством команд, находящихся в файле конфигурации, очень важно, чтобы все модули загружались до появления любой другой команды файла httpd. conf.
Для большинства базовых инсталляций достаточно использовать список модулей по умолчанию, который можно не корректировать. Если нужно расширить или изменить функциональность Web-сервера, обратитесь к on-line документации по адресу httpd. apache. org за дополнителъной информацией о добавлении загружаемых модулей и использовании команд LoadModule и AddModule.
<Directory /var/www/html>
Options Indexes Includes FollowSymLinks
AllowOverride None
order allow,deny
allow from all
</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-сервер
Web-серверы для Linux
Установка Apache
Конфигурирование Apache
Управление Web-сервером
Построение Web-сайта
Вы уже достаточно долго изучаете Linux и сейчас готовы к обзору наиболее популярного из применений этой операционной системы: использования Linux для создания Web-серверов небольшого и среднего масштабов.
Linux широко используется для разработки и поддержки Web-серверов по нескольким причинам.
Linux обеспечивает гибкость и управляемость Unix.
Установка и запуск Linux практически ничего не стоит.
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.
Построим сайт, который будет содержать информацию о небольшой издательской компании 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. В данном случае исходный текст файла может быть следующим.
<HTML>
<HEAD>
<TITLE>On the Web Publishers</TITLE>
</HEAD>
<BODY BGCOLOR=lightcyan TEXT=midnightblue>
<A HREF="/">
<IMG SRC="/images/logo.gif" BORDER=0></A>
<table CELLPADDING=5 CELLSPACING=5
BGCOLOR=1ightp ink> <TR>
<TD ALIGN=CENTER><A HREF="about">AB00T U</A></TD>
<TD ALIGN=CENTER><A HREF="books">OUR
BOOKS</A></TD>
<TD ALIGN=CENTER><A HREF="contact">CONTACT
US</A></TD> <TD ALIGN=CENTER><A HREF="authors">JUST FOR
AUTHORS</A></TD>
</TR> </TABLE> </DIV>
<FONT SIZE=5>W</F>elcome to <STRONG>On the Web Publishers</STRONG>.
We offer the finest in on-line electronic books at .reasonable prices. Check out what we have to offer ...
<UL>.
<LI><A HREF="about">Learn about what we do</A>
<LI><A HREF="books">See what books we offer</A>
<LI><A HREF="contact">Contact us</A>
</UL>
</BODY> </HTML>
Результат работы этого файла показан на рис. 32.3.
Рис. 32.3.
Домашняя страница
Остальные страницы будут выглядеть примерно так же, кроме формы для контактов /var/ www/html/contact/index.html. Форма для контактов показана на рис. 32.4, она реализуется следующим исходным кодом.
<HTML>
<TITLE>On the Web Publishers</TITLE> </HEAD>
<BODY BGCOLOR=lightcyan TEXT=midnightblue>
<DIV ALIGN=CENTER>
<A HREF="/">
<IMG SRC="/images/ldgo.gif" BORDER=0></A>
<table CELLPADDING=5 CELLSPACING=5
BGCOLOR= 1 ightp ink> <TR>
<TD ALIGN=CENTER><A HREF="/about">ABOUT
US</A></TD>
<TD ALIGN=CENTER><A HREF="/books">OUR
BOOKS</A></TD>
<TD ALIGN=CENTER BGCOLOR=yellow>CONTACT
US</TD> <TD ALIGN=CENTER><A HREF="/authors">JUST FOR
AUTHORS</A></TD> </TR> </TABLE>
<Hl>Drop Us A Line ...</H1> </DIV>
<TABLE ALIGN=CENTER><TR><TD>
<FORM METHOD=POST ACTION="/cgi-bin/formmail">
<INPUT TYPE=TEXT WIDTH=30 NAME=name> Name<BR>
<INPUT TYPE=TEXT WIDTH=30 NAME=address> Address<BR>
<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>
<INPUT TYPE=SUBMIT VALUE="Send Comments"> </FORM> </TD></TR></TABLE>
</BODY> </HTML>
Рис. 32.4.
Форма для контрактов
Эта страница содержит форму и ссылку на CGI-программу, которая обрабатывает данные из формы. В нашем случае используется программа f ormmail (бесплатно распространяемый сценарий CGI, написанный на Perl), которая считывает содержимое формы и отправляет его по почте на предопределенный почтовый адрес. В рассматриваемом примере контактная информация из формы отправляется по почте на главный почтовый адрес книжного магазина.
Forramail написал Matthew M. Wright. Эта программа доступна по адресу http: / /www. worldwideniart.com/scripts/formmail .shtml. Несмотря на то, что в главе не затрагивалось программирование на Perl и CGI, мы приводим исходный код программы. Можно заметить, что создание несложных CGI-программ не требует особых усилий.
#!/usr/bin/perl ################################
# FonriMail Version
1.6 #
# Copyright 1995-1997 Matt Wright mattw@worldwidemart.com #
# Created 06/09/95 Last Modified 05/02/97 #
# Matt's Script Archive, Inc.:
http://www.worldwidemart.com/scripts/
######################################
# COPYRIGHT NOTICE #
#Copyright 1995- 1997 Matthew M. Wright All Rights Reserved. #
# #
# FormMail может быть использована и свободно модифицирована любым
# пользователем, при условии сохранности авторских прав и
# комментариев, приведенных выше. Используя этот код, вы
# соглашаетесь не требовать от автора возмещения убытков при любых
# обстоятельствах, которые могут возникнуть при ее использовании.
#
# Продажа кода этой программы без предварительного письменного согласия
# категорически запрещена. Прежде чем получить деньги за мою программу,
# спросите меня.
#
# Получите разрешение перед распространением этого программного
# обеспечения в пределах Internet и любого другого окружения. Во всех
# случаях знаки авторского права и заголовок должны быть сохранены
######################################
# Определение переменных #
# Более подробную информацию можно найти в файле README. #
# $mailprog определяет местонахождение программы sendmail в системе unix. #
$mailprog = Vusr/lib/sendmail';
# @referers разрешает формам находиться только на серверах, определенных
# в этом поле. Это корректировка безопасности по сравнению с предыдущей
# версией, которая позволяла любому пользователю на любом сервере
# использовать сценарий FormMail на своем Web-сайте.
# referers = Clinux.juxta.com');
# Конец
######################################
# Проверка ссылающегося URL &check_url;
# Получить дату &get_date ;
# Разобрать содержимое формы &parse_form;
# Проверить обязательные поля &check_required;
# Возвратить HTML-страницу или перенаправить пользователя &return_html ;
# Послать E-Mail &send_mail;
sub check_url {
# Локализировать флаг check_referer, который определяет,
# является ли пользователь допустимым. local ($check_referer) = 0;
# Если был- указан URL рекомендателя, убедиться, что для каждого
# допустимого рекомендателя в FormMail передан правильный URL.
if ($ENV{'HTTP_REFERER'}) {
foreach $referer (Oreferers) {
if ($ENV{toTP_REFERER'} =~ m|https? : // ( [^/] *) $referer | i) {
last;
} } }
else {
$check_referer = 1;
}
# Если HTTP_REFERER был недопустимым, возвратить ошибку.
if ($check_referer != 1) { &error <bad_referer') }
}
sub get_date {
# Определить массивы для дней недели и месяцев года.
@days = ('Sunday','Monday','Tuesday','Wednesday',
'Thursday', 'Friday', 'Saturday') ;
@months = ('January','February',"March','April', 'May','June','July', 'August','September', 'October','November','December') ;
# Получить текущее время и формат часов, минут и секунд. Добавить
# 1900 к году, чтобы получить полный 4-цифровой год.
($sec,$min,$hour,$mday,$mon,$year, $wday) = (localtime(time))[0,1,2,3,4,5,6];
$time = sprintf ("%02d:%02d:%02d", $hour, $min, $sec) ; $year += 1900;
# Сформатировать дату.
$date = "$days[$wday], $months[$mon] $mday, $year at $time";
}
sub parse_form {
# Определить ассоциативный массив для конфигурации
# Config = ('recipient',", 'subject',",
'email',", 'realname', ",
'redirect
1
,'
1
, 'bgсоlоr', ",
'background',", 'link_color',",
'vlink_color', ' ', 'text_color', ' ',
'alink_color',", 'title',",
'sort', ' ', 'print_conf ig', ' ',
'required' , " , 'eny_report' , " ,
'return_link_title', ' ', 'return_link_url', ' ',
'print_blank_f ields
1
, ' ', 'missing_f ields_redirect', ") ;
# Определить для формы REQUEST_METHOD (GET или POST) и распределить
# поля формы по парам имя-значение. Если REQUEST_METHOD не был ни
# GET, ни POST, выдать ошибку.
if ($ENV{'REQUEST_METHOD'} eg 'GET') {
# Разложить по парам имя-значение @pairs = split (/&/, $ENV{'QUERY_STRING'} ) ;
}
elsif ($ENV{'REQUEST_METHOD'} eg 'POST') {
# Считать входную информацию read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'} ) ;
# Разложить по парам имя-значение
Opairs = split (/&/, $buf fer) ; } else {
&error ('request_method') ;
}
# Для каждой пары имя-значение
foreach $pair (Opairs) {
# Разложить пару по отдельным переменным local($name, $value) = split(/=/, $pair) ;
# Декодировать кодировку формы для переменных имени и значения
$name =~ tr/+/ / ;
$name =~ s/% ( [a-fA-FO-9] [a-fA-FO-9] ) /packC'c", hex($l) ) /eg;
$value =~ tr/+/ /;
$value =~ s/% ( [a-fA-FO-9] [a-fA-FO-9] )/pack("C", hex($l) ) /eg;
# Если они пытаются использовать включения со стороны сервера,
# удалить их, чтобы они не были угрозой безопасности, если html
# будет возвращен. Еще одна брешь в защите перекрыта.
$value =~ s/<!-( . |\n)*->//g;
# Если имя поля указано в массиве %Config, по вызову
# defined ($Config{$name) }) будет возвращена 1 и нам нужно связать
# это значение с соответствующей переменной конфигурации. Если же
# это не конфигурационное поле формы, записать его в ассоциативный
# массив %Form, добавив перед значением ', ', если там уже есть
# какое-то значение. Также сохраним порядок полей формы в массиве
# @Field_Order, чтобы можно было использовать этот порядок при
# обычной сортировке.
if (defined($Config{$name))) { $Conf ig{$name) = $value,-
else {
if ($Form{$name) && $value) {
$Form{$name) = "$Form{$name} , $'value";
elsif ($value) {
push(@Field_Order,$name); $Form{$name} = $value;
} }
# Последующие шесть строчек удаляют лишние пробелы и символы перевода
# строки из переменных конфигурации, которые могут появиться в случае,
# если редактор переносит строки после некоторой длины строки или если
# были использованы пробелы между именами полей или переменными среды.
$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;
$Config{'print_config'} =- s/ (\s+) ?\n+ (\s+) ?,
# Разложить переменные конфигурации по отдельным именам полей.
@Reguired = split (/, / , $Conf ig{ 'required'} ) ;
@Env_Report = split ( / , / , $Conf ig{'env_report'} ) ;
@Print_Config = split (/,/, $Conf ig{'print_conf ig'} ); }
sub check_required {
# Локализация переменных, используемых в этой подпрограмме.
local ($require, @error) ;
if ( !$Config{ 'recipient '}) {
if (!defined (%Form) ) { &error (bad_referer') } else { kerror ('no_recipient') }
# Для каждого обязательного поля, определенного в форме:
foreach $require (@Required) {
# Если обязательное поле является email, проверить синтаксис email
# адреса, чтобы убедиться в его правильности.
if ($require eq 'email' && !&check_email ($Conf ig{$require} ) ) { /push ( ©error , $require) ;
}
# Иначе, если обязательное поле является полем конфигурации и не
# указано его значение или заполнено пробелами, выдать ошибку.
elsif (def ined($Config{$require} ) ) { if ( !$Config{$require) ) { push (@error , $require) ;
# Если обычное поле формы не заполнено или заполнено пробелами,
# отметить его как ошибочное поле .
elsif ( !$Form{$require}) {
push(@error,$require) ;
# Если найдено хотя бы одно ошибочное поле, послать пользователю
# сообщение об ошибке .
if (@error) { &error('missing_fields',@error) }
sub return_html {
# Инициализировать локальные переменные,
# используемые этой подпрограммой.
local ($key, $sort_order , $sorted_field) ;
# Если используется опция переадресации, напечатать заголовок
# с адресом переадресации.
if ($Config{'redirect'}> {
print "Location: $Config{'redirect'} \n\n";
# Иначе, начать печать страницу ответа.
else {
# Напечатать заголовок HTTP и открывающие дескрипторы HTTP.,
print "Content -type: text/html \n\n";
print "<html>\n <head>\n";
# Напечатать заголовок страницы
if ($Config{'title'}) { print " <title>$Conf ig{'title'}</title>\n" } else { print " <title>Cnacибо</title>\n" } print " </head>\n <body>;
# Получить атрибуты дескриптора Body &body_attributes ;
# Закрыть дескриптор Body print ">\n <center>\n";
# Напечатать специальный или общий заголовок.
if ($Config{'title'}) { print " <hl>$Conf ig{'title'}</hl>\n" }
else { print " <h1>Спасибо Вам за заполнение данной формы</h1>\n" }
print "</center>\n";
print "Ниже находится предоставленная вами информация для ";
print "$Conf ig{'recipient'} . Текущая дата: ";
print "$date<pxhr size=l width=75\%><p>\n";
# Если указано, отсортировать по алфавиту:
if ($Config{'sort'} eq 'alphabetic') { foreach $ field (sort keys %Form) {
# Если поле имеет значение или установлена опция печати пустых
# полей, то распечатать поле формы и его значение.
if ($Config{'print_blank_f ields'} || ?Form{$field}) {
print "<b>$field:</b> $Form{$field}<p>\n";
# Если указан порядок сортировки, отсортировать поля
# формы в указанном порядке.
elsif ($Config{'sort'} =~ /Border :.*,.*/) {
# Присвоить временной переменной $sort_order порядок сортировки,
# убрать лишние переносы строк и пробелы, убрать команду order:
# и разложить поля сортировки в массив.
$sort_order = $Conf ig{'sort'} ;
$sort_order =~ s/(\s+|\n)?, (\s+| \n) ?/, /g;
$sort_order =~ s/ (\s+) ?\n+(\s+)?//g;
$sort_order =~ s/order://;
@sorted_f ields = split (/,/, $sort_order) ;
# Для каждого поля сортировки, если у него есть значение
# или если установлена опция печати пустых полей,
# распечатать поле формы и его значение. foreach $sorted_f ield (@sorted_f ields) {
if ($Config{'print_blank_f ields'} || $Form{$sorted_field) ) { print "<b>$sorted_field:</b> $Form{$sorted_field}<p>\n" ;
# Иначе, использовать порядок, в котором поля были переданы.
else {
# Для каждого поля формы, если оно имеет значение или
# установлена опция печати пустых полей, распечатать поле
# формы и его значение. foreach $ field (@Field_Order) {
if ($Config{'print_blank_f ields'} | | $Form{$f ield} ) { print "<b>$field:</b>' $Form{$f ield}<p>\n";
}
print "<p><hr size=l width=75%xp>\n";
# Проверить наличие ссылки возврата и распечатать ее, если нашли.
if ($Config{'return_link_url'} && $Conf ig{'return_link_title'} ) {
print "<ul>\n";
print "<lixa href =\"$Conflg{'return_link_url'} \">$Conf ig{'return_
->link_title'}</a>\n";
print "</ul>\n";
# Распечатать нижнюю часть страницы.
print «"(END HTML FOOTER)";
<hr size=l width=75%xp>
<centerxfont size=-lxahref="http: //www.worldwidemart.com/scripts,
->formmail.shtml">FormMail</a> V1. 6 ©
1995 -1997 Matt Wright <br> A Free Product of
<a href="http: //www.worldwidemart .com/scripts/">Matt ' s
->Script Archive, Inc.</ax/fontx/center>
</body>
</html>
(END HTML FOOTER)
sub send_mail {
# Локализация переменных, используемых в этой подпрограмме.
local ($print_conf.ig, $key, $sort_order, $sorted_field, $env_report) ;
# Открыть почтовую программу open (MAIL, " | $mailprog -t") ;
- print MAIL "To: $Config{'recipient'}\n";
print MAIL "From: $Conf ig{'email'} ($Config{'realname'} ) \n" ;
# Проверить тему сообщения
if ($Conf ig{ ' subject '}) { print MAIL "Subject:
$Conf ig{'subject'} \n\n"} else {print MAIL "Subject: WWW Form Submission\n\n" }
print MAIL "Ниже находится предоставленная вами информация .
От кого : \n" ; print MAIL "$Conf ig{'realname'} ($Conf ig{'email'} ) , дата:
$date\n"; print MAIL "-" x 75 . "\n\n";
if (@Print_Config) " {
foreach $print_conf ig (@Print_Conf ig) { if ($Conf ig{$print_conf ig} ) {
print MAIL "$print_config: $Config{$print_conf ig} \n\n";
} } }
# Если указано, отсортировать по алфавиту:
if ($Config{'sort'} eq 'alphabetic') { foreach $field (sort keys %Form) {
# Если поле имеет значение или установлена опция печати пустых
# полей, распечатать поле формы и его значение,
if ($Config{'print_blank_fields'} | | $Form{$field) $Form{$field} eq '0') {
print MAIL "$field: $Form{$field}\n\n"; } } }
# Если указан порядок сортировки, отсортировать поля
# формы в указанном порядке .
elsif ($Config{'sort'} = ~ /^order :.*,.*/) {
# Убрать лишние переносы строк и пробелы, убрать команду order:
# и разложить поля сортировки в массив.
$Config{'sort'} =~ s/(\s+|\n)?, (\s+ | \n) ?/ , /g;
$Config{'sort'} =~ s/ (\s+) ?\n+ (\s+) ?//g;
$Config{'sort'} =- s/order://;
@sorted_fields = split(/,/, $Config{'sort'} ) ;
# Для каждого поля сортировки, если у него есть значение или еслк
# установлена опция печати пустых полей, распечатать поле
# формы и его значение.
foreach $sorted_field (Ssorted_fields) {
if ($Config{ 'print_blank_f ields'} | | $Form{$sorted_field} | | $Form{$sorted_f ield} eq '0') { print MAIL "$sorted_field: $Form{$sorted_f ield}\n\n";
# Иначе, использовать порядок, в котором поля были переданы, else {
# Для каждого поля формы, если оно имеет значение или
# установлена опция печати пустых полей, распечатать
# поле формы и его значение, foreach $field (@Field_Order) {
if ($Config{'print_blank_fields'} | | $Form{$field} | | $Form{$field} eq '0') { print MAIL "$field: $Form{$field}\n\n";
}
}
}
print MAIL "-" x 75 . "\n\n";
# Если указаны переменные среды, послать их адресату,
foreach $env_report (@Env_Report) {
if ($ENV{$env_report}) {
print MAIL "$env_report: $ENV{$env_report}\n";
} } close (MAIL);
}
sub check_email {
# Инициализация локальной переменной email
# параметром вызова подпрограммы.
$email = $_[0];
# Если e-mail адрес содержит:
if ($email =- /(@.*@)|(\.\.)|(@\.) (\.@)|(^\.)/ ||
# e- mail адрес имеет неправильный синтакс. Или, если синтакс не
# соответствует следующему шаблону регулярного выражения, то
# проверка основного синтаксиса обнаруживает ошибку.
$email !~ /^.+\@(\[?)[a-zA-Z0-9\-\.3+\.([a-zA-Z] ->{2,3}|[0-9]{1,3})(\]?)$/) {
# Основной синтаксис требует: один или более символов перед
# знаком @, за которым следует необязательный символ '[',
# затем любое число букв, цифр, дефисов и точек
# (допустимые символы домена/IP), и в конце стоит точка,
# за которой находятся 2 или 3 буквы (для суффиксов домена)
# или от 1 до 3 цифр (для IP-адресов). В конце также может
# стоять символ
'
]
', так
как допустимо иметь email-адрес,
# подобный user@[255.255.255].
# Возвратить код ошибки, если e-mail
# адрес не удовлетворяет синтаксису, return 0;
}
else {
# Возвратить true, e-mail адрес соответствует правилам, return 1 ;
} }
sub body_attributes {
# Проверить цвет фона
if .($Config{ 'bgcolor'}) { print " bgcolor=\"$Config{'bgcolor'} \"" }
# Проверить фоновый рисунок
if ($Config{background'}) { print " > background=\"$Config{background'}\"" }
#Проверить цвет ссылок
if ($Config{'link_color'}) { print " link=\"$Conf ig{'link_color'} \" " }
# Проверить цвет посещенных ссылок
if ($Conf ig{'vlink_color'}) { print " vlink=\"$Conf ig{'vlink_color'} \"" }
# Проверить цвет активной ссылки
if ($Config{'alink_color'}) { print " alink=\"$Conf ig{'alink_color'} \"" }
# Проверить цвет текста
if ($Config{'text_color'}) { print " text=\"$Conf ig{'text_color'}A"" }
sub error {
# Локализация переменных и присвоение параметров подпрограммы.
local($error,@error_fields) = @_;
local($host,$missing_field,$missing_field_list);
if ($error eq tad_referer') {
if ($ENV{'HTTP_REFERER'} =~ m| ~https? :
// ( [ \w\ . ] ) | i) { $host = $1; print «"(END ERROR HTML) ";
Content-type: text/html
<html> <head>
<title>HeKoppeктным рекомендатель - в доступе отказано</title> </head>
<body bgcolor=#FFFFFF text=#000000> <center>
<table width=600 bgcolor=#9C9C9C>
<tr><th><font size=+2>Некорректный рекомендатель — в доступе
_>OTKa3aHo</fontx/th></tr> </table>
<table width=600 bgcolor=#CFCFCF> <tr><td>
Фopмa пытается использовать
<a href="http: //www.worldwidemart.com/scripts/formmail.shtiru">FormMail</a>
по адресу
<tt>$ENV{'HTTP_REFERER'}</tt>
, что является недопустимым для доступа к этому CGI-сценарию.<р>
Если Вы пытаетесь сконфигурировать FormMail для запуска этой формы,
->вам нужно добавить следующую информацию к \@referers, более
->подробно об этом написано в файле README.<р>
Добавьте <tt>'$host'</tt> в ваш массив <tt><b>\@referers</b></tt>.
->chr size=1> <centerxfont size=-l>
<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/
">
->Matt's Script Archive, Inc.</a> </font></center>
</td></tr>
</table> </center> </body> </html>
(END ERROR HTML) } else {
print «"(END ERROR HTML)"; Content-type: text/html
<html> ' <head>
<title>FormMail vl.6</title> </head>
<body bgcolor=#FFFFFF text=#000000> <center>
<table width=600 bgcolor=#9C9C9C> <tr>
<th><font size=+2>FormMail</font></th></tr> </table>
<table width=600 bgcolor=fCFCFCF>
<tr><th><tt><font size=+l>Copyright 1995 - 1997 Matt Wright<br> Version 1.6 - Released May 02, 1997<br>
A Free Product of
<&
href="http: //www.worldwidemart.com/scripts/">
->Matt's Script Archive, Inc. </a></font>< /tt>< / th>< / tr> </table> </center> </body> </html> (END ERROR HTML)
} }
elsif ($error eg 'request_method') {
print «"(END ERROR HTML)"; Content-type: text/html
<html> <head>
<title>Ошибка: Метод 3anpoca</title> </head>
<body bgcolor=#FFFFFF text=#000000> <center>
<table width=600 bgcolor=#9C9C9C> <tr>
<th><font size=+2>Error: Request Method</font></th></tr> </table>
<table width=600 bgcolor=#CFCFCF>
<tr><td> Meтод запроса предоставленной Вами формы не совпадает ни с
<tt>GET</tt>, ни с <tt>POST</tt>. Пожалуйста, проверьте форму и
->убедитесь, что оператор
<tt>method=</tt> записан в верхнем регистре и является <tt>GET</tt>
->либо <tt>POST</tt>.<p>
<centerxfont size=-l>
<а 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>
</table> </center> </body> </html>
(END ERROR HTML) } elsif ($error eg 'no_recipient') {
print «"(END ERROR HTML)";
Content-type: text/html
<html> <head>
<title>Omn6Ka: Нет </head>
<body bgcolor=#FFFFFF text=#000000i> <center>
<table width=600 bgcolor=#9C9C9C> <tr><thxfont size=+2>Error: No Recipient</fontx/th></tr> </table>
<table width=600 bgcolor=iCFCFCF>
<tr><td> B переданных для FormMail данных не указан получатель. Пожалуйста, убедитесь, что Вы записали в поле формы 'recipient'
e-mail адрес. Более подробную информацию по заполнению поля формы recipient можно найти в файле README.<hr size=l>
<centerxfont 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>s </ f ontx/eenter> </td></tr> </table> </center> </body> </html>
(END ERROR HTML) }
elsif ($error eq 'missing_f ields') {
if ($Config{'missing_fields_redirect'}) {
print "Location: $Conf ig{'missing_£ields_redirect'} \n\n"; } else {
foreach $missing_field (@error_fields) {
$missing_field_list .= " <li>$missing_f ield\n";' }
print «"(END ERROR HTML)";
Content-type: text/html
<html> <head>
<title>Ошибка: Незаполненные пoля</title> </head> <center>
<table width=600 bgcolor=#9C9C9C>
<tr><th><font size=+2>0шибка: Незаполненные поля</font></th></tr> </table>
<table width=600 bgcolor=fCFCFCF> <tr>
<td>Следующие поля в предоставленной Вами форме незаполнены:<р>
<ul>
$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>
</table> </center> </body> </html> (END ERROR HTML)
exit; }
Эта профамма возвращает пользователю 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).
AuthName Just For Authors AuthType Basic
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 вместо сообщения по умолчанию. Когда пользователь не пройдет аутентификацию, он получит модифицированную страницу с сообщением о неудачной аутентификации.
Раздел 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.
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
.
Управление пользователями и группами
В следующем параграфе (о защите каталогов) вы узнаёте, что одним из основных методов защиты является использование имени и пароля, который ограничивает доступ конкретному ряду пользователей. Пользователи должны правильно ввести свои имя и пароль для получения доступа к защищенному каталогу.
Создавать пользователей очень просто. Для этого достаточно воспользоваться командой 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
Управление протоколами
Последняя рассматриваемая функция администрирования - управление протоколами. 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-сервер после его установки. Кроме того, нужно время от времени выполнять некоторые служебные операции, чтобы убедиться в том, что сервер работает без инцидентов. Необходимо добавлять и удалять пользователей и группы, защищать каталоги при помощи управления доступом и осуществлять контроль протоколов сервера.
Установка Apache
Оставшаяся часть главы посвящена детальному обзору Web-сервера Apache по двум причинам:
Сервер Apache является Web-сервером по умолчанию, который входит в поставку с Red Hat Linux (включая Red Hat Linux 7.1 на прилагаемом компакт-диске).
Так как в настоящее время Apache является самым популярным Web-сервером для Internet, то, вероятнее всего, именно его вы будете использовать на своем компьютере.
Если при установке системы 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
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 К сожалению, он больше не поддерживается.
Web-серверы для Linux
Web впервые появился в мире Unix, поэтому неудивительно, что под Unix-платформы написано наибольшее количество существующих Web-серверов.
Все что существует под Unix, доступно для Linux, в том числе и Web-серверы Unix. Большинство Web-серверов Linux бесплатны. Наиболее известны следующие Web-серверы Linux.
NCSAhttpd
Apache
AOLserver
Boa
WN
W3G/Cern
Наряду с бесплатными серверами существует несколько коммерческих серверов:
FastTrack/iPlanet
Java Web Server
Stronghold
Zeus
WN
Рассмотрим те бесплатные серверы, которые используются реже. Серверы в этой нише рынка помогают увидеть разнообразие технологий и возможностей Web-серверов.
WN - еще один бесплатный сервер с уникальными возможностями, отличающими его от других серверов. WN позволяет проводить полнотекстовый поиск до документам, которые разработчики называют
логическими документами HTML
(документы, состоящие более чем из одного файла). Кроме того, пользователи могут искать файлы на сервере и легко получать удовлетворяющие условиям поиска документы. Пользователи могут загружать простой логический документ, состоящий из нескольких связанных документов, упрощая печать файлов, представляющих собой последовательность небольших документов.
Еще одна уникальная особенность сервера WN - способность работать с условными документами. Сервер WN может создать простой документ с определениями, которые возвращают клиенту правильную версию документа в зависимости от таких переменных, как IP-адрес и версия браузера клиента.
Модель безопасности сервера WN отличает его от Apache и Web-сервера NCSA httpd, которые по умолчанию работают с файлами, пока не нарушены конкретные права доступа. WN не работает ни с одним файлом, пока не получены конкретные права доступа. Реализуя эту модель. сервер становится более безопасным и предоставляет более мощный контроль доступа к файлам.
Копию WN можно получить по адресу hopf.math. nwu. edu.
Загрузка последней версии 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
Если 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 указывает на положение файла httpd. conf.
-d указывает на корневой каталог сервера, переназначая файл конфигурации.
Обычно достаточно использовать флаг - 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 545 0.1 3.8 1104 572 ? S 17:52 0:00 [httpd]
apache 546 0.0 3 .8 1104 572 ? S 17:52 0:00 [httpd]
apache 547 0.2 3.8 1104 572 ? S 17:52 0:00 [httpd]
apache 548 0.1 3.8 1104 572 ? S 17:52 0:00 [httpd]
apacfie 549 0.0 3.8 1104 572 ? S 17:52 0:00 [httpd]
apache 550 0.3 3.8 1104 572 ? S 17:52 0:00 [httpd]
root 544 0.5 4 1104 592 ? S 17:52 0:00 /usr/sbin/httpd
Заметьте: все процессы принадлежат apache за исключением одного, принадлежащего root. Это родительский процесс всех процессов httpd, как раз тот, который нужно остановить командой
#
kill 544
Защита каталогов посредством управления доступом
Как было указано в параграфе о разрешении HTML-каталога, существует возможность установить управление доступом для каждого каталога отдельно. Обычно это делается при помощи файла . htaccess в том каталоге, который надо защитить. В данный файл помещаются необходимые команды конфигурирования.
Для управления доступом в этом файле используются следующие основные команды:
AuthUserFile
AuthGroupFile
AuthName
AuthType
require
order
deny
allow
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. Так как она запрещает доступ всем хостам, то запрашивающему хосту доступ не предоставляется.
Команда 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. Так как она запрещает доступ всем хостам, то запрашивающему хосту доступ не предоставляется.
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.
Инсталляция файлов конфигурации Sendmail
На момент написания книги программа Sendmail была поделена на три отдельных RPM-пакета: пакет собственно программ, пакет конфигурационных утилит и пакет документации. Если вы обращаетесь к Sendmail впервые (или впервые конфигурируете программу), вам следует установить все три пакета. Вы можете их установить с CD-ROM, прилагаемого к книге:
$ rpm -i /mnt/cdrom/RedHat/RPMS/sendmail-cf-8.9.3-10.i386.rpm
Не все файлы конфигурации Sendmail по умолчанию инсталлируются при установке Red Hat Linux 7.1.Для полной инсталляции необходимо предварительно монтировать CD-ROM, прилагаемый к книге (например, как /mnt/cdr,om) и выполнить команду rpm для инсталляции двух пакетов.
$ rpm -i /mnt/cdrom/RedHat/RPMS/sendmail-e.11.2-14.1386.rpm
$ rpm -i /mnt/cdrom/RedHat/RPMS/sendmail-cf-e.11.2-14.1386.rpm
Файлы документации Sendmail по умолчанию не инсталлируются при установке Red Hat Linux 7.1. Если у вас нет второго диска Red Hat CD-ROM (к книге он не прилагается), вам придется загрузить пакет sendmail-8.11.2-14.1386. rpm с узла ftp.redhat. com или www. fpmf ind .net. Если он загружен, например, в каталог / trap, то для установки достаточно выполнить команду:
$ rpm -i /tmp/sendmail-doc-8.11.2-14.1386.rpm
Концепция транспортного агента почты
Обычно пользователи принимают за систему e-mail программное обеспечение для чтения, создания и отправки сообщений. Таким программным обеспечением может быть почтовый модуль Netscape Communicator, Eudora, Pegasus Mail или pine, но все эти программы просто реализуют удобный интерфейс к системам, которые действительно выполняют работу по маршрутизации и получению почты.
Ни в одном из этих случаев программное обеспечение пользователя фактически не выполняет отправку исходящей или получение входящей почты. Перечисленные программы являются Mail User Agents (MUAs - Почтовыми агентами пользователя). Существует множество разнообразных MUA - на все вкусы. И именно они реализуют пользовательский интерфейс в мир e-mail.
За такими MUA-программами стоят транспортные агенты почты. МТА выполняют доставку, получение и маршрутизацию почтовых сообщений. Все МТА твердо придерживаются некоторых стандартных протоколов (например, Простого Протокола Транспорта Почты, известного как SMTP), которые реализуют систему электронной почты Internet (и систему электронной почты почти каждой сети Unix).
Это различие между MUA и МТА имеет очень большое значение. При установке почтового сервера в сети организации или в любой другой компьютерной сети, необходимо работать именно с транспортными почтовыми агентами.
Дополнительные сведения о различных МТА доступны на странице Linux Electronic Mail Admi-nistrator-HOWTO по адресу http: //www. linuxdoc. org/HOWTO/Mail-Administrator-HOWTO.html.
Как отмечалось ранее, конфигурирование Sendmail
Как отмечалось ранее, конфигурирование Sendmail может быть серьезной задачей даже для опытного системного администратора Unix. Для того чтобы разобраться во всех лабиринтах настройки системы, могут потребоваться годы.
Настройки Sendmail сохраняются в /etc/sendmail .cf. Даже беглый взгляд на конфигурационный файл, заданный по умолчанию в Red Hat Linux 7.1, позволяет оценить всю сложность конфигурирования системы.
Просматривая файл, обратите внимание, что он содержит большое количество чрезвычайно загадочных правил, определяющих поведение Sendmail. Любой пользователь, не являющийся экспертом в Sendmail, совершил бы серьезную ошибку, взявшись конфигурировать базисную систему, вручную создавая и редактируя файл конфигурации.
К счастью, для создания файла конфигурации в Sendmail предусмотрена специальная программа m4. Она позволяет создавать более простые файлы конфигурации. Затем
т
4 обрабатывает эти файлы и преобразует их в файлы конфигурации Sendmail. Все, кроме самых опытных пользователей, создают файл конфигурации Sendmail именно этим способом.
Примечание
Дискуссии по вопросу конфигурирования Sendmail при помощи m4 доступны на странице
http://www.sendmail.org/m4/readme.html
. Пример конфигурирования Sendmail при ПОМОЩИ
т
4 приведен на странице http: //www.sendmail.org/m4/intro.html.
Этот параграф начинается с инсталляции необходимых для работы
т
4 файлов конфигурации Sendmail, затем дан обзор интерактивного почтового сервера.
Как отмечалось ранее, конфигурирование Sendmail
Как отмечалось ранее, конфигурирование Sendmail может быть серьезной задачей даже для опытного системного администратора Unix. Для того чтобы разобраться во всех лабиринтах настройки системы, могут потребоваться годы.
Настройки Sendmail сохраняются в /etc/sendmail .cf. Даже беглый взгляд на конфигурационный файл, заданный по умолчанию в Red Hat Linux 7.1, позволяет оценить всю сложность конфигурирования системы.
Просматривая файл, обратите внимание, что он содержит большое количество чрезвычайно загадочных правил, определяющих поведение Sendmail. Любой пользователь, не являющийся экспертом в Sendmail, совершил бы серьезную ошибку, взявшись конфигурировать базисную систему, вручную создавая и редактируя файл конфигурации.
К счастью, для создания файла конфигурации в Sendmail предусмотрена специальная программа m4. Она позволяет создавать более простые файлы конфигурации. Затем т4 обрабатывает эти файлы и преобразует их в файлы конфигурации Sendmail. Все, кроме самых опытных пользователей, создают файл конфигурации Sendmail именно этим способом.
Примечание
Дискуссии по вопросу конфигурирования Sendmail при помощи т4 доступны на странице
http://www.sendmail.org/m4/readme.html
. Пример конфигурирования Sendmail при ПОМОЩИ т4 приведен на странице http: //www.sendmail.org/m4/intro.html.
Этот параграф начинается с инсталляции необходимых для работы т4 файлов конфигурации Sendmail, затем дан обзор интерактивного почтового сервера.
Linux Red Hat 7.1 как почтовый сервер: мощь Sendmail
Концепция транспортного агента почты
Sendmail как основной транспортный агент почты
Конфигурирование Sendmail при помощи m4
В этой главе мы рассмотрим, как с использованием транспортного агента почты Sendmail превратить Linux в почтовый сервер организации.
Необходимость в почтовом сервере возникает тогда, когда связывается множество рабочих станций в сети и необходимо обеспечить для них сервис e-mail. Sendmail позволяет конфигурировать систему Linux для работы в качестве почтового сервера для внутренней переписки, отправки сообщений в Internet и получения сообщений из Internet.
В начале главы рассмотрена концепция МТА (Mail Transport Agent - Транспортный агент почты), затем дан краткий обзор Sendmail, основного МТА в мире Unix, а также некоторых альтернативных программ МТА. В завершение приведены рекомендации по конфигурированию Sendmail.
Qmail
Программ Qmail является альтернативой Sendmail. Хотя программа Qmail не столь известна, как smail, она выполняет некоторые функции, делающие ее конкурентоспособной на рынке МТА.
Разработчик Qmail обратил особое внимание на реализацию функций защиты. За последние годы в Sendmail обнаружен ряд ошибок в защите, которые впоследствии были исправлены. Философия Qmail состоит в том, чтобы сделать все возможное для исключения скрытых изъянов в системе безопасности, поскольку почта постоянно открыта для попыток взлома.
Qmail также пытается сделать процесс доставки настолько надежным, насколько это возможно, с форматом почтового ящика, более устойчивым к сбоям в работе системы при помещении сообщения в почтовый ящик.
Qmail выполняет и обычные функции, характерные для традиционных МТА: пересылка, использование псевдонимов, списки рассылки, управление загрузкой и т.п.
Домашняя страница Qmail - http: //www.qmail.org. На ней приведен список коммерческих организаций, обеспечивающих необходимую поддержку.
Sendmail как основной транспортный агент почты
Похоже, наиболее популярным МТА в мире Unix является программа Sendmail. Эта программа определяет почтовую систему, которая обеспечивает связь с Internet, поддерживая привычную адресацию
(username@some. domain)
и предоставляя стандартные услуги (такие, как автоматическая пересылка почты).
Являясь наиболее популярной программой, Sendmail вырос до самого мощного и сложного МТА систем Unix. Фактически, конфигурирование и управление системой Sendmail может быть настолько сложным в большой организации, что данному вопросу следовало бы посвятить целую книгу.
В главе обращено внимание на конфигурирование и использование Sendmail потому, что именно эта программа является МТА по умолчанию в Red Hat Linux, впрочем, как и в сетях Unix.
Предупреждение
В главе дан общий обзор программы Sendmail и задач ее конфигурирования. Чтобы получить более подробные сведения, обратитесь на Web-сайт www. sendipail. org.
Для начала коротко рассмотрим некоторые альтернативные МТА для Linux.
Small
Sendmail может быть основным транспортным агентом почты в Unix, но в мире Linux чаще используется как МТА программа smail. Отконфигурировать smail проще, чем Sendmail (хотя не всегда). Программа smail обеспечивает те же функции с поддержкой SMTP и UUCP, что делает возможным ее использование в качестве интерактивного почтового сервера.
Пакет smail не входит в состав Linux Red Hat 7.1, в качестве МТА по умолчанию используется Sendmail. Для загрузки последней версии smail обратитесь по адресу ftp: / / ftp. planix. com/ pub/Smail/ или поищите после днюю версию пакета RPM по адресу http: //www.rpmfind.net.
Создание интерактивного почтового сервера
Теперь можно посмотреть на файл конфигурации интерактивного (online) почтового сервера. Интерактивный почтовый сервер легче конфигурировать и понять, чем серверы, работающие в режиме off-line.
Примечание
Несмотря на то, что программа т4 облегчает конфигурирование Sendmail, количество ее опций огромно. В этой главе рассмотрены только те опции, с которыми работают файлы конфигурации. Примеры конфигурационных файлов расположены в подкаталогах каталога /usr/share/sendmail-cf. Созданный вами конфигурационный файл Sendmail располагается В каталоге /usr/share/sendmail-cf/cf.
Интерактивный почтовый сервер является почтовым сервером сети, соединенной с Internet по выделенной линии. Когда отправитель извне направляет почтовое сообщение пользователю локальной сети, оно может быть доставлено непосредственно адресату, а когда пользователь сети посылает письмо, оно отправляется немедленно.
Чтобы направить входящие сообщения к почтовым ящикам пользователей или отправить сообщения, созданные пользователями, необходимо соответствующим о'бразом отконфигурировать Sendmail. Ести существуют препятствия для доставки сообщений, например отсутствие соединения с Internet сообщения будут поставлены в очередь для отправки после установления связи с Internet.
Файл конфигурации, созданный в т4, подобен следующему:
include('../m4/cf.m4')
OSTYPE(4inux' )
undefine("UUCP_RELAY')dnl
undefine('BITNET_RELAY')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
MAILER(local)dnl
MAILER(smtp)
Примечание
Внимательно отнеситесь к апострофам (одиночным кавычкам) в конфигурационных файлах m4. Первая (открывающая) кавычка - всегда обратная ("), расположенная на стандартной клавиатуре над клавишей Tab. Вторая (закрывающая) кавычка (') - обычный апостроф (одиночная кавычка).
Рассмотрим каждую строку этого файла конфигурации.
Строка 1. include (`
..
/m4/cf .m4') Это общие файлы конфигурации, необходимые для того, чтобы сформировать файл конфигурации Sendmail,
Строка 2. OSTYPE (`linux') Указание типа операционной системы (Linux) для установки соответствующих значений по умолчанию.
Строка 3. undef ine ('UUCP_RELAY') He указывая перенаправление UUCP-сообщений, определяем, что нет host-компьютера для получения UUCP-почты, и получатели почты ,в формате UUCP должны быть подключены непосредственно. Учитывая то, что UUCP-почта разрабатывалась во времена, когда большинство сетей непосредственно связаны не были, для большинства случаев можно оставить UUCP RELAY неопределенным.
Строка 4. undef ine (`BITNET_RELAY'} Поскольку локальная сеть не связана с сетью Bitnet, адреса, использующие формат Bitnet, работать не будут.
Строка 5. FEATURE (redirect) Теперь любая почта, направленная по адресу address. REDIRECT, будет перенаправлена с указанием нового адреса пользователя. Если пользователь сменил адрес, его новый адрес может связываться со старым адресом при помощи добавки
.REDIRECT.
Строка 6. FEATURE (always_add_domain) Эта возможность гарантирует, что поле From всегда содержит локальный домен, а содержимое этого поля можно использовать для посылки ответного сообщения.
Строка 7. MAILER (local) Поддержка локальной почты позволяет Sendmail доставлять сообщения в локальные почтовые ящики Unix.
Строка 8. MAILER (smtp) Поддержка SMTP позволяет Sendmail передавать сообщения непосредственно на почтовые серверы адресатов. Этот режим работает в системе, где сервер соединен с Internet и обеспечиваются услуги DNS.
Примечание
Ключевое слово dn1 в конце большинства строк конфигурационного файла sendmail означает "delete through newline" (удалить до конца строки) и позволяет уменьшить число пустых строк в выходном файле . cf (см. ниже).
Для создания файла конфигурации Sendmail из файла конфигурации m4, необходимо создать файл m4 в каталоге /usr/lib/sendmail-cf /cf. Пусть этот файл будет иметь имя online .me. Расширение . тс обычно присваивается файлам конфигурации m4.
Примечание
Если у вас нет опыта работы с Sendmail, обратитесь к простым примерам файлов конфигурации в этом каталоге, включая generic-linux.mc и redhat .me. Можете просто скопировать их в online.me.
Перейдем в каталог /usr/lib/sendmail-cf /cf и выполним следующую команду.
$ m4 online.me > online.cf
Эта команда обрабатывает файл, используя т4, и генерирует файл конфигурации Sendmail, называемый online. cf.
Затем создается резервная копия существующего файла sendmail. cf. Файл sendmail. cf необходимо заменить только что созданным. Следующие команды выполняются администратором системы (root-пользователем).
# ср /etc/sendmail.cf /etc/sendmail.cf.keep
#
ср online.cf /etc/sendmail.cf
Последний этап - перезапуск демона Sendmail.
# /etc/re.d/init.d/sendmail restart
Команды управления демонами могут располагаться в других каталогах, если вы пользуетесь другими дистрибутивами, отличными от Red Hat Linux.
Если демон Sendmail запускался при начальной загрузке, то он загрузит новый файл конфигурации. Если необходимо загрузить Sendmail вручную, используйте следующую команду.
#
/usr/sbin/sendmail -bd
По умолчанию демон Sendmail запускается во время начальной загрузки в большинстве дистрибутивов Linux, если пользователь не укажет иначе. Если необходимо добавить Sendmail в цикл загрузки, можно использовать команду /usr/sbin/sendmail -bd в файле re. local.
