Организация Web-доступа в среде zLinux на сервере z9 BC

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

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

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

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

Основной целью данного диплома будет рассмотрение web-сервера и последующая его настройка.

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

Постановка задачи

1.1.1 Объединение серверов

Объединение серверов с помощью z/VM

Novell и IBM разработали Linux для мэйнфреймов с возможностью использовать преимущества виртуализации. При запуске SUSE Linux Enterprise Server на мэйнфрейме IBM System Z можно создавать несколько виртуальных машин, которые работают на одном процессоре, и работать с несколькими виртуальными серверами параллельно. Данная возможность освобождает от необходимости приобретения дополнительного аппаратного обеспечения. Кроме того, виртуальные сервера позволяют объединять несколько физических систем.

Запуск .NET приложений на System Z

Расширение Mono на SUSE Linux Enterprise и инструменты для Visual Studio позволяют корпоративным разработчикам и независимым разработчикам разрабатывать и запускать Windows .NET приложения на SUSE Linux Enterprise Server. Mono позволяет использовать существующие .NET-приложения и разрабатывать новые, запуская их на Linux, тем самым снижая затраты и повышая производительность сервера.

1.1.2 Поддержка встроенных средств для Linux (IFL)

IFL является специализированным процессором от IBM, который обрабатывает несколько рабочих нагрузок Linux. IFLs позволяет купить одну лицензию программного обеспечения и использовать ее на многих виртуальных машинах Linux, что делает Linux на мэйнфреймах еще более доступным. IFLs позволяет избежать покупки дополнительных, более дорогих центральных процессоров для System z.

1.1.3 Более простые и эффективные системы управления

Управления пакетами с ZYPP

SUSE Linux Enterprise Server включает ZYPP - систему быстрого обновления на любом дистрибутиве Enterprise Linux. Novell имеет оптимизированный ZYPP для повышения производительности и точности, который более многофункционален, чем такие инструменты, как YUM и Smart.

YaST / AutoYaST, WebYaST

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

Starter система

SUSE Linux Enterprise Starter - это система для System Z, позволяющая предварительно настроить установку сервера, что делает развертывание системы более легким, устраняя необходимость в отдельной системе для размещения установочных файлов. Кроме того, этот инструмент не требует подключение к сети вне мэйнфреймов для установки Linux серверов.

1.1.4 Расширенный менеджер безопасности

Приложение AppArmor® входит в состав SUSE Linux Enterprise и является эффективным, простым в использовании приложением, обеспечивающим основы безопасности для Linux. Оно активно защищает операционную систему и приложения от внешних и внутренних угроз и атак. AppArmor включает политики по умолчанию, которые обеспечивают безопасность даже самых сложных приложений с минимальными затратами времени и ресурсов.

1.1.5 Высокая доступность и кластеризация

Novell включает расширение SUSE Linux Enterprise High Availability в каждой подписки на SUSE Linux Enterprise Server для System Z. Это расширение позволяет поддерживать непрерывность бизнеса, защиты целостности данных и снижения времени незапланированных простоев для критически важных рабочих нагрузок. Оно обеспечивает все необходимые службы мониторинга, обмена сообщениями и управления ресурсами кластера. Имеет ту же функциональность что и решения сторонних производителей, но по более доступной цене.

1.1.6 Улучшенная производительность

SUSE Linux Enterprise Server для System Z является выбором № 1 для запуска Linux на мэйнфреймах IBM, так как данная операционная система оптимизирована для мейнфреймов, как никакая друга ОС Linux.http://translate.googleusercontent.com/translate_c?hl=ru&ie=UTF8&prev=_t&rurl=translate.google.ru&sl=en&tl=ru&u=http://www.novell.com/products/systemz/features/linux_on_system_z.html&usg=ALkJrhi_bgocEJEiMU8BKFgTa8ocFCrhsA

Динамическое добавление / удаление

Динамическое добавление/удаление центральных процессоров (CPUs) и памяти позволяет настроить ресурсы для гостей Linux под z/VM во время работы мейнфрейма. Таким образом, процессоры могут быть выделены динамически гостям Linux и могут использоваться по мере необходимости. В результате, время работы для гостей Linux и приложений увеличивается.

Управление вертикальными процессорами

С помощью этой функции вы можете переключаться между горизонтальной и вертикальной поляризацией процессора через атрибут Sysfs. Как результат, можно достичь максимальной производительности системы Z серверов путем поддержания неоднородного доступа к памяти каждого сервера (NUMA).

Поддержка больших страниц памяти

Теперь система может выделять память для процесса в блоки по 2 Мб вместо 4 Кб. По мере увеличения объема памяти, необходимые таблицы страниц потребляют огромное количество физической памяти. Меньшее число больших по объему страниц может решить эту проблему, и тем самым увеличить производительность путем улучшения пропускной способности.

Следующее поколение криптографического HW драйвера

SUSE Linux Enterprise Server для System Z включает аппаратное ускорение шифрования, что увеличивает число защищенных транзакций в секунду. Такие функции, как разгрузка центрального процессора и повышение безопасности помогают снизить риск и расходы на техническое обслуживание.

1.2 Техническая информация

1.2.1 Системные требования

Минимальные системные требования для установки Linux сервера.

Локальная установка: 512 Мб оперативной памяти.

Используя Secure Shell (SSH): 512 Мб оперативной памяти.

Через Virtual Network Computing (VNC) с использованием File Transfer Protocol (FTP): 512 Мб оперативной памяти.

Минимальные системные требования для работы Linux сервера.

512 Мб оперативной памяти.

750 Мб на жестком диске для программного обеспечения.

750 Мб на жестком диске для хранения пользовательских данных.

Общие рекомендации.

От 512 Мб до 4 Гб оперативной памяти, минимум по 256 Мб на каждый процессор.

4 Гб на жестком диске.

Сетевой интерфейс (Ethernet, беспроводной или модем).

Для Xen виртуального хост-сервера минимум по 512 МБ оперативной памяти для каждого виртуального хоста сервера.

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

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

Для файловых серверов требуется дополнительная память и диски, или избыточный массив недорогих дисков (RAID) для ускорения системы ввода/вывода.

1.2.2 Ограничения ядра

В следующей таблице приведены ограничения для ядра, используемого в SUSE Linux Enterprise 11 с пакетом обновления SP1. Эти ограничения распространяются на все продукты SUSE Linux Enterprise Server и SUSE Linux Enterprise Desktop, основанные на версии 11 SP1 с версией ядра 2.6.32.

Таблица 1 - Ограничения ядра версии 2.6.32

1.2.3 Поддержка файловых систем

SUSE Linux Enterprise Server поддерживает ext3, ReiserFS, XFS, и OCFS2. Текущей файловой системой по умолчанию для установки новых SUSE Linux Enterprise 11 является ext3. OCFS2 является кластерной файловой системой. XFS используется для крупномасштабных систем с большой нагрузкой и несколькими параллельными операциями чтения и записи (например, для баз данных и файловых серверов с Samba, NFS и т.д.).

Так же может потребоваться использовать две файловые системы одновременно ext3 и XFS.

На Рис. 1 представлена сравнительная характеристика возможностей файловых систем поддерживаемых SUSE Linux Enterprise Server.

Рис. 1 - Возможности файловых систем

2. Web-сервер Apache

2.1 Описание web-сервера Apache

Apache HTTP-сервер являете свободно распространяемым web-сервером. Apache так же является кроссплатформенным ПО, и поддерживает операционные системы Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS.

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

Сервер Apache состоит из ядра и подключаемых модулей. Ядро Apache включает в себя основные функциональные возможности, такие как обработка конфигурационных файлов, протокол HTTP и система загрузки модулей. Ядро (в отличие от модулей) полностью разрабатывается Apache Software Foundation, без участия сторонних программистов. Теоретически, ядро Apache может функционировать в чистом виде, без использования модулей, но функциональность такого решения крайне ограничена. Модули могут быть включены в состав сервера, как в момент компиляции, так и загружены динамически, через директивы конфигурационного файла.

В модулях реализуются такие вещи, как:

Поддержка языков программирования.

Добавление функционала.

Исправление ошибок или модификация основных функций.

Усиление безопасности.

Ниже представлены базовые модули, входящие в состав сервера при сборке по умолчанию:

access авторизация доступа;

actions позволяет привязать CGI скрипт к обработчику, MIME типу или методу запроса;

alias отображение URL в файловую систему и перенаправление;

asis обработчик send-as-is позволяет обрабатывать файлы, которые содержат часть заголовков ответа в себе;

auth аутентификация Basic, построенная на текстовых файлах;

autoindex в отсутствии сделанного вручную индексного файла каталога (задаётся модулем dir) создаёт его "на ходу" из списка находящихся в каталоге файлов;

cgi обработчик CGI; устанавливается по умолчанию для prefork MPM;

cgid обработчик CGI; устанавливается по умолчанию для гибридных MPM;

dir отображение имени каталога, указанного в URL;

env устанавливает и изменяет переменные окружения;

imap обработка графических карт сервером;

include реализует фильтр SSI;

log_config журнал доступа;

mime ассоциация файла по суффиксу имени с его обработкой (обработчики и фильтры) и типом содержимого (MIME тип, язык, набор символов и кодировка);

negotiation позволяет серверу выбрать один из возможных документов для обслуживания клиента на основе характеристик каждого клиента;

setenvif позволяет устанавливать переменные окружения в зависимости от характеристик запроса;

status выдача информации о текущем состоянии сервера;

userdir директива UserDir позволяет определить каталог в домашнем каталоге пользователя, который надо использовать при обработке URL вида http://www.company.ru/~username/

Модули расширения, которые необходимо добавить явно при сборке Apache:

auth_anon доступ анонимных клиентов к закрытым каталогам по ftp;

auth_dbm аутентификация Basic, построенная на DBM;

cern_meta позволяет добавлять заголовки в ответ;

для каждого файла создаётся отдельный файл с дополнительными заголовками; MetaDir, MetaFiles, MetaSuffix);

dav и dav_fs реализация протокола WebDAV;

deflate реализует фильтр DEFLATE;

expires управление содержимым заголовков Expires и Cache-Control;

ext_filter позволяет использовать внешнюю программу в качестве фильтра;

headers удаление и замена заголовков запросов и ответов;

info выдача информации о конфигурации сервера;

log_forensic записывает в отдельный журнал полные заголовки каждого запроса для отладки тяжёлых случаев;

logio считает входящие и исходящие байты для каждого запроса, что позволяет использовать форматы %I и %O в модуле log_config);

mime_magic определяет MIME тип по содержимому файла;

proxy позволяет Apache работать как прокси-сервер;

для обслуживания протокола FTP требуется модуль proxy_ftp, HTTP - proxy_http, CONNECT/SSL - proxy_connect и ssl; для кэширования может использоваться модуль cache; может работать в режиме прямого (ProxyRequests) и обратного (ProxyPass, RewriteRule) прокси (балансировка загрузки, кэширование, обход экрана или слияние адресных пространств нескольких серверов);

proxy_connect вспомогательный модуль для модуля proxy;

proxy_ftp вспомогательный модуль для модуля proxy;

proxy_http вспомогательный модуль для модуля proxy;

rewrite более мощное средство преобразования URL, чем alias;

so загрузка дополнительных модулей при запуске и перезапуске сервера вместо пересборки сервера; директивы LoadModule, LoadFile;

speling пытается скорректировать опечатки в URL;

ssl поддержка криптографического протокола, который обеспечивает установление безопасного соединения между клиентом и сервером;

suexec позволяет запускать CGI программы под указанным именем пользователя и группы;

unique_id уникальный идентификатор для каждого запроса;

usertrack отслеживание клиентов с помощью куки;

vhost_alias организация массового виртуального хостинга, имя из заголовка запроса "Host:" используется для определения каталога, из которого брать файлы.

В отличие от первой версии Apache 2 может использовать различные MPM модули. Сервер может быть собран только с одним MPM. MPM осуществляет запуск процессов, потоков и привязку запросов клиентов к процессу или потоку. Область действия всех директив, кроме AssignUserID - сервер.

Типы MPM:

prefork - MPM с ветвлением; никаких потоков, каждому запросу выделяется отдельный процесс, процессы порождаются заранее и используются при обработке последовательных запросов; директивы:

MinSpareServers число (минимальное число запасных процессов; недостающие процессы создаются с темпом 1 штука в секунду);

MaxSpareServers число (максимальное число запасных процессов; лишние процессы завершаются);

worker - гибридный MPM: запускается множество процессов, каждый из которых имеет множество обслуживающих потоков; директивы:

ThreadsPerChild число (число потоков на каждый обслуживающий процесс; создаются при запуске процесса, число потоков никогда не меняется)

leader - экспериментальный вариант MPM worker (-with-mpm=leader и -enable-nonportable-atomics=yes)

threadpool - экспериментальный вариант MPM worker

perchild - MPM с фиксированным количеством процессов, процессы запускаются с различными полномочиями и могут обслуживать указанное количество потоков; используются директивы:

NumServers число-процессов

ChildPerUserID uid gid число-процессов

AssignUserID uid gid (используется при описании виртуального сервера)

StartThreads число (5 штук на процесс для perchild, сколько обслуживающих потоков запускать в начале работы)

MaxThreadsPerChild число (64)

Система конфигурации Apache

Система конфигурации Apache основана на текстовых конфигурационных файлах. Имеет три условных уровня конфигурации:

Конфигурация сервера (httpd.conf).

Конфигурация виртуального хоста (httpd.conf c версии 2.2 extra/httpd-vhosts.conf).

Конфигурация уровня директории (.htaccess).

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

Apache имеет встроенный механизм виртуальных хостов. Он позволяет полноценно обслуживать на одном IP-адресе множество сайтов (доменных имён), отображая для каждого из них собственное содержимое. Для каждого виртуального хоста можно указать собственные настройки ядра и модулей, ограничить доступ ко всему сайту или отдельным файлам.

Apache имеет различные механизмы обеспечения безопасности и разграничения доступа к данным. Основными являются:

Ограничение доступа к определённым директориям или файлам.

Механизм авторизации пользователей для доступа к директории по методу HTTP-Авторизации (mod_auth_basic) и digest-авторизации (mod_auth_digest).

Ограничение доступа к определённым директориям или всему серверу, основанное на IP-адресах пользователей.

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

Существуют модули, реализующие авторизацию через СУБД.

В некоторых MPM-модулях присутствует возможность запуска каждого процесса Apache используя различные uid и gid с соответствующими этим пользователям и группам пользователей. Также, существует механизм suexec, используемый для запуска скриптов и CGI-приложений с правами и идентификационными данными пользователя. Для реализации шифрования данных, передающихся между клиентом и сервером, используется механизм SSL, реализованный через библиотеку OpenSSL.

Переменные окружения

Сервер позволяет обмениваться информацией с внешними программами (CGI) и между модулями с помощью переменных окружения. Имя переменной должно начинаться с буквы и может содержать буквы, цифры и символ нижнего подчёркивания. Перед вызовом CGI сервер устанавливает переменные запроса в соответствии со стандартом (некоторые модуля добавляют свои переменные):

DOCUMENT_ROOT="абсолютное-имя-директории-документов-сервера"

GATEWAY_INTERFACE="CGI/1.1"

HTTP_ACCEPT="image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png"

HTTP_ACCEPT_CHARSET="iso-8859-1,*,utf-8"

HTTP_ACCEPT_LANGUAGE="ru, en"

HTTP_CACHE_CONTROL="max-age=259200"

HTTP_CONNECTION="keep-alive"

HTTP_HOST="www.printhouse.ru" - если клиент посылает поле HOST в запросе

HTTP_IF_MODIFIED_SINCE="Wednesday, 26-Jul-00 15:20:17 GMT; length=1437"

HTTP_USER_AGENT="Mozilla/4.05 [en] (X11; I; SunOS 5.5 sun4m)"

HTTP_VIA="1.0 acache.deol.ru:3129 (Squid/2.3.STABLE1)" - proxy

HTTP_X_FORWARDED_FOR="195.161.72.28" - proxy

PATH="директории, в которых ищутся исполняемые программы"

QUERY_STRING=""

REMOTE_ADDR="клиент или прокси"

REMOTE_PORT="39885"

REQUEST_METHOD="GET"

REQUEST_URI="/cgi-bin/printenv"

SCRIPT_FILENAME=абсолютное имя файла"

SCRIPT_NAME="логическое имя объекта"

SERVER_ADDR="IP адрес"

SERVER_ADMIN="почтовый адрес администратора сервера"

SERVER_NAME="имя-определенное-по-IP"

SERVER_PORT="80"

SERVER_PROTOCOL="HTTP/1.0"

SERVER_SIGNATURE="

Apache/1.3.12 Server at dual.deol.ru Port 80\n"

SERVER_SOFTWARE="Apache/1.3.12 (Unix) rus/PL29.4"

Директивы модуля env:

SVDFLA PassEnv имя-переменной ... (передаёт значение системной - установливается в момент запуска сервера - переменной окружения)

SVDFLA SetEnv имя-переменной значение

SVDFLA UnsetEnv имя-переменной ...

Модуль setenvif позволяет устанавливать переменные в зависимости от характеристик запроса (директивы выполняются последовательно):

SVDFLA BrowserMatch регулярное-выражение [!]имя-переменной[=значение] ... (установить переменную (в 1) или присвоить значение или удалить переменную в зависимости от заголовка запроса "User-Agent:")

BrowserMatchNoCase - сравнение без учёта регистра символов

SVDFLA SetEnvIf имя-атрибута регулярное-выражение [!]имя-переменной[=значение] ... (установить переменную (в 1) или присвоить значение (может содержать $1-$9 как значения подвыражения, см. PCRE) или удалить переменную в зависимости от значения атрибута:

имя поля заголовка запроса (например: Host, User-Agent, Referer, Accept-Language и др.), вместо имени поля можно указывать регулярное выражение

Remote_Host

Remote_Addr

Server_Addr

Request_Method (GET, POST и т.д.)

Request_Protocol ("HTTP/0.9", "HTTP/1.1" и т.д.)

Request_URI

имя переменной окружения, установленной предыдущими директивами SetEnvIf[NoCase]

SetEnvIfNoCase - сравнение без учёта регистра символов

Директива RewriteRule модуля rewrite имеет опцию установки переменной окружения.

Модуль unique_id уставливает "уникальное" для каждого запроса значение в переменную UNIQUE_ID.

Использование переменных в модулях:

модуль include (SSI) позволяет выводить значения переменных командой echo и использовать их для условного исполнения

модуль access позволяет управлять доступом, основываясь на значениях переменных

модуль log_config позволяет заносить значения переменных в журнал и принимать решения о записи вообще

модуль header позволяет добавлять поля в заголовок ответа, основываясь на значениях переменных

модуль mod_ext_filter может активировать внешний фильтр, основываясь на значениях переменных

модуль rewrite может использовать различные варианты, основываясь на значениях переменных

Специальные переменные окружения, меняющие обработку запроса сервером:

downgrade-1.0 (обрабатывать запрос в соответствии с протоколом HTTP/1.0)

force-no-vary (не вставлять поле Vary в заголовок ответа)

force-response-1.0 (выдавать ответ в формате HTTP/1.0)

gzip-only-text/html (запретить использование модуля deflate для всех типов содержимого, кроме text/html)

no-gzip (запретить использование модуля deflate для всех типов)

nokeepalive

prefer-language (модуль negotiation выбирает вариант, основываясь на этикетке языка, указанной в запросе)

redirect-carefully (для доступа DAV Microsoft WebFolders)

suppress-error-charset (сопроводительный текст перенаправления не помечается как ISO-8859-1)

2.2 Инсталляция web-сервера Apache

2.2.1 Сборка web-сервера Apache

Требования, необходимые для успешной сборки сервера:

Дисковое пространство

На диске должно быть как минимум 50 Mб свободного места для временных файлов. После установки Apache занимает приблизительно 10 Mб. Точный размер занимаемого места будет зависеть в основном от выбранной конфигурации и дополнительно устанавливаемых модулей, не входящих в дистрибутив Apache.

ANSI-C компилятор и необходимая среда сборки

В вашей системе должен присутствовать ANSI-C компилятор. Рекомендуется использовать GNU C компилятор (GCC) от Free Software Foundation (FSF) (версии 2.7.2 вполне достаточно). Также стоит убедиться в том, чтобы в переменной окружения PATH был указан каталог, содержащий основные утилиты, необходимые для сборки (make и другие).

Синхронизация времени

В некоторых заголовках HTTP протокола указывается время. Поэтому необходимо, чтобы в системе присутствовало средство синхронизации времени. Обычно для этих целей используются программы ntpdate или xntpd, основанные на сетевом протоколе синхронизации времени (Network Time Protocol - NTP).

Загрузка дистрибутива

Apache можно загрузить со страницы загрузки Apache HTTP Software Foundation, на которой также приводится список некоторых зеркальных серверов. Пользователям, работающим на unix-подобных системах, рекомендуется собирать Apache из исходных кодов. Процесс сборки достаточно прост и позволяет настроить сервер под любые нужды.

Конфигурирование сборки

Скачав и распаковав дистрибутив сервера Apache 2.0, необходимо сконфигурировать свою версию сборки перед последующей установкой.

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

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

Наиболее интересными из них являются следующие:

-prefix=/путь_к_директории ? задает путь инсталляции сервера Apache.

-enable-имя_модуля ? включение модуля не входящего в состав сборки по умолчанию

-disable-имя_модуля ? исключение модуля входящего в состав сборки по умолчанию

-with-module=тип-модуля:имя-файла ? добавление внешнего модуля, не входящего в комплект поставки, ищется в каталоге modules/тип-модуля

Ключи для скрипта ./configure, влияющие на его выполнение:

-C

-config-cache

псевдоним для -cache-file=config.cache

-cache-file=FILE

результаты тестирования скрипта будут сохраняться в файл FILE

эта опция отключена по умолчанию

-h

-help [short|recursive]

вывод справки и выход

с аргументом short будет отображаться справка только выбранного пакета

с аргументом recursive будет показана краткая справка для всех пакетов, включенных в дистрибутив

-n

-no-create

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

-q

-quiet

не выводит checking ... сообщения в процессе настройки

-srcdir=DIR

Определяет каталог DIR как источник файлов установки

по умолчанию это каталог, где производиться настройка, или родительский

-silent

тоже что и -quiet

-V

-version

показывает информацию об версии, авторских правах а затем завершается

Для того чтобы скомпилировать модули как динамически подключаемые объекты (DSO), т.е. они могут быть загружены и выгружены из сервера во время его работы, требуется использовать параметр shared для опции -enable-имя_модуля следующим образом:

-enable-[module]=shared (требуется наличие модуля so).

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

Опция -enable-layout=LAYOUT производит настройку дерева каталогов для установки сервера в соответсвии с шаблоном LAYOUT, что позволяет отдельно указать места для каждого типа файла в пределах директории установки сервера Apache.

Файл config.layout содержит несколько шаблонов конфигураций. Также можно создавать свои собственные конфигурации следуя примерам. Различные схемы в этом файле сгруппированы в блоки по именам <Layout FOO>...</Layout>, где вместо FOO подставляется имя. По умолчанию используется макет Apache .

Ниже представлены параметры конфигурационного скрипта для моей сборки сервера:

./configure -prefix=/opt/apache2 \

-with-mpm=prefork \

-disable-imagemap \

-disable-userdir \

-enable-proxy \

-enable-proxy-http \

-enable-proxy-ftp \

-enable-auth-digest=shared \

-enable-charset-lite \

-enable-expires \

-enable-info \

-enable-rewrite=shared \

-enable-usertrack \

-enable-so

Мною был выбран тип MPM-модуля prefork, как наиболее простой и стабильный в работе. Впоследствии во время эксплуатации сервера настройки MPM можно будет изменять, подбирая наиболее эффективные при текущей нагрузке на сервере.

Также в сборку были включены дополнительные модули для обеспечения прокси: mod_proxy_http, mod_proxy_ftp, модуль обеспечения динамического подключения модулей: mod_so, модуль выдающий информацию о сервере: mob_info, модуль для отслеживания клиентов с помощью куки: mod_usertrack, модуль управляющий содержимым заголовков: mod_expires управляющий содержимым заголовками и модуль mod_charset_lite для перекодировки документов из кодировки хранения в кодировку клиента. В целях повышения безопасности от внешнего вмешательства из сборки были исключены модуль mod_userdir, позволяющий создавать отдельные каталоги для каждого пользователя, и модуль mod_imagemap, отвечающий за поддержку карт изображений.

2.2.2 Установка web-сервера Apache

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

make,

затем произвести установку нового сервера командой

make install.

Эта команда скопирует все необходимые файлы в директорию, определенную опцией -prefix. Если данная опция не была указана, то по умолчанию будет использоваться путь /usr/local/apache/.

2.2.3 Запуск web-сервера Apache

httpd - собственно сам сервер. В Unix программа httpd представляет собой демон, выполняющийся в фоновом режиме и обслуживающий поступающие запросы.

Демон httpd может быть запущен со следующими ключами:

-d значение-ServerRoot

-f имя-конфигурационного-файла (относительно ServerRoot)

-k start | restart | graceful | stop | graceful-stop

-C директива (выполнить директиву до чтения файла конфигурации)

-c директива (выполнить директиву после чтения файла конфигурации)

-D параметр (определение параметра для условной конфигурации)

-e значение-LogLevel

-E имя-файла (выводить сообщения об ошибке в указанный файл)

-l (выдать список модулей, динамически подключённые модули не указываются)

-L (выдать список директив для каждого модуля)

-M (выдать список модулей, динамически подключённые модули указываются)

-S (разбор конфигурации виртуальных хостов)

-t (проверить конфигурацию)

-X (отладочный режим)

-v (выдача краткой информации о версии сервера)

-V (выдача полной информации о версии сервера)

-h (выдать синтаксис командной строки)

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

./bin/apachectl start

Скрипт apachectl принимает следующие команды:

start

stop

restart (предварительно проверяется синтаксис файла настройки)

fullstatus (нужен mod_status и lynx)

status

configtest

graceful (перезапуск без обрывания текущих соединений, статистика не сбрасывается; журналы закрываются не сразу, рекомендуемая пауза - 15 минут)

help

Содержимое скрипта apachectl представлено ниже:

#!/bin/sh

#

# Licensed to the Apache Software Foundation (ASF) under one or more

# contributor license agreements. See the NOTICE file distributed with

# this work for additional information regarding copyright ownership.

# The ASF licenses this file to You under the Apache License, Version 2.0

# (the "License"); you may not use this file except in compliance with

# the License. You may obtain a copy of the License at

#

# http://www.apache.org/licenses/LICENSE-2.0

#

# Unless required by applicable law or agreed to in writing, software

# distributed under the License is distributed on an "AS IS" BASIS,

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

# See the License for the specific language governing permissions and

# limitations under the License.

#

#

# Apache control script designed to allow an easy command line interface

# to controlling Apache. Written by Marc Slemko, 1997/08/23

#

# The exit codes returned are:

# XXX this doc is no longer correct now that the interesting

# XXX functions are handled by httpd

#0 - operation completed successfully

#1 -

#2 - usage error

#3 - httpd could not be started

#4 - httpd could not be stopped

#5 - httpd could not be started during a restart

#6 - httpd could not be restarted during a restart

#7 - httpd could not be restarted during a graceful restart

#8 - configuration syntax error

#

# When multiple arguments are given, only the error from the _last_

# one is reported. Run "apachectl help" for usage info

#

ARGV="$@"

#

# |||||||||||||||||||| START CONFIGURATION SECTION ||||||||||||||||||||

# ---------- ----------

#

# the path to your httpd binary, including options if necessary

HTTPD='/opt/apache2/bin/httpd'

#

# pick up any necessary environment variables

if test -f /opt/apache2/bin/envvars; then

. /opt/apache2/bin/envvars

fi

#

# a command that outputs a formatted text version of the HTML at the

# url given on the command line. Designed for lynx, however other

# programs may work.

LYNX="lynx -dump"

#

# the URL to your server's mod_status status page. If you do not

# have one, then status and fullstatus will not work.

STATUSURL="http://localhost:80/server-status"

#

# Set this variable to a command that increases the maximum

# number of file descriptors allowed per child process. This is

# critical for configurations that use many file descriptors,

# such as mass vhosting, or a multithreaded server.

ULIMIT_MAX_FILES="ulimit -S -n `ulimit -H -n`"

# ---------- ----------

# |||||||||||||||||||| END CONFIGURATION SECTION ||||||||||||||||||||

# Set the maximum number of file descriptors allowed per child process.

if ["x$ULIMIT_MAX_FILES" != "x"] ; then

$ULIMIT_MAX_FILES

fi

ERROR=0

if [ "x$ARGV" = "x" ] ; then

ARGV="-h"

fi

case $ARGV in

start|stop|restart|graceful|graceful-stop)

$HTTPD -k $ARGV

ERROR=$?

;;

startssl|sslstart|start-SSL)

echo The startssl option is no longer supported.

echo Please edit httpd.conf to include the SSL configuration settings

echo and then use "apachectl start".

ERROR=2

;;

configtest)

$HTTPD -t

ERROR=$?

;;

status)

$LYNX $STATUSURL | awk ' /process$/ { print; exit } { print } '

;;

fullstatus)

$LYNX $STATUSURL

;;

*)

$HTTPD $ARGV

ERROR=$?

esac

exit $ERROR

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

/usr/local/apache2/bin/apachectl -f /usr/local/apache2/conf/httpd.conf

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

Если во время запуска Apache произойдет какая-либо фатальная ошибка, то перед тем, как завершить свою работу, сервер пошлет на консоль или в ErrorLog сообщение, описывающее данную ошибку.

Скрипт apachectl разработан таким образом, что он может действовать как стандартный init-скрипт системы SysV. Он может принимать аргументы start, restart, и stop и переводить их в соответствующие сигналы процессу httpd. Поэтому для запуска сервер автоматически после перезагрузки системы, достаточно добавить вызов скрипта apachectl в системные файлы, отвечающие за загрузку операционной среды, расположенные в каталоге /etc/init.d/. Для этого возьмем стандартный init-скрипт httpd.init для Apache из директории /bin/rpm/ нашего дистрибутива и отредактируем его под свои нужды. Содержимое измененного скрипта представлено ниже:

#!/bin/bash

#

# Startup script for the Apache Web Server

#

# chkconfig: - 85 15

# description: Apache is a World Wide Web server. It is used to serve \

# HTML files and CGI.

# processname: httpd

# pidfile: /usr/local/apache2/logs/httpd.pid

# config: /usr/local/apache2/conf/httpd.conf

# Source function library.

/etc/rc.d/init.d/functions

if [-f /etc/sysconfig/httpd]; then

/etc/sysconfig/httpd

fi

# Path to the apachectl script, server binary, and short-form for messages.

apachectl=/opt/apache2/bin/apachectl

httpd=/opt/apache2/bin/httpd

pid=$httpd/logs/httpd.pid

prog=httpd

RETVAL=0

# The semantics of these two functions differ from the way apachectl does

# things - attempting to start while running is a failure, and shutdown

# when not running is also a failure. So we just do it the way init scripts

# are expected to behave here.

start() {

echo -n $"Starting $prog: "

daemon $httpd $OPTIONS

RETVAL=$?

echo

[$RETVAL = 0] && touch /var/lock/subsys/httpd

return $RETVAL

}

stop() {

echo -n $"Stopping $prog: "

killproc $httpd

RETVAL=$?

echo

[$RETVAL = 0] && rm -f /var/lock/subsys/httpd $pid

}

reload() {

echo -n $"Reloading $prog: "

killproc $httpd -HUP

RETVAL=$?

echo

}

# See how we were called.

case "$1" in

start)

start

;;

stop)

stop

;;

status)

status $httpd

RETVAL=$?

;;

restart)

stop

start

;;

condrestart)

if [-f $pid] ; then

stop

start

fi

;;

reload)

reload

;;

graceful|help|configtest|fullstatus)

$apachectl $@

RETVAL=$?

;;

*)

echo $"Usage: $prog {start|stop|restart|condrestart|reload|status"

echo $"|fullstatus|graceful|help|configtest}"

exit 1

esac

exit $RETVAL

Затем скопируем этот скрипт в директорию /etc/init.d/ и дадим ему права на выполнение. После выполним команды, обеспечивающие запуск сервера вместе с системой:

chkconfig -add httpd

chkconfig -level 2345 httpd on

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

2.2.4 Остановка и перезапуск web-сервера Apache

Для того чтобы остановить или перезапустить Apache, необходимо послать сигнал запущенным процессам httpd. Существует два способа отправить подобные сигналы. Во-первых, можно послать сигналы непосредственно процессам, используя команду kill. Стоит помнить, что процессов httpd в системе выполняется несколько, однако не следует отсылать сигналы ни одному из них, кроме родительского - его pid (идентификатор процесса) записывается в файл, путь к которому задается директивой PidFile.

Существуют три сигнала, которые можно отправить родительскому процессу: TERM, HUP, и USR1 - их значение будет объяснено ниже.

Чтобы отправить сигнал родительскому процессу, следует набрать следующую команду:

kill -TERM `cat /opt/apache2/logs/httpd.pid`

Второй способ передать сигналы процессам httpd - это использование опции -k в командной строке с аргументами: stop, restart и graceful, как будет описано ниже. Это параметры командной строки для исполняемого файла httpd, однако рекомендуется передавать их, используя скрипт apachectl, который более корректно передаст эти параметры программе httpd.

После того, как будут отправлены сигналы процессу httpd, можно узнать состояние сервера, набрав:

tail -f /usr/local/apache2/logs/error_log

Немедленная остановка

Сигнал: TERM

apachectl -k stop

После получения сигнала TERM или stop, родительский процесс пытается немедленно уничтожить все дочерние процессы. Это может занять несколько секунд. Затем родительский процесс сам завершает работу, при этом все текущие запросы прекращают обрабатываться, а новые запросы игнорируются.

Немедленный перезапуск

Сигнал: HUP

apachectl -k restart

Отправленный родительскому процессу сигнал HUP или restart вызывает немедленное уничтожение всех дочерних процессов, также как и при обработке сигнала TERM, однако родительский процесс не завершает работу. Он перечитывает конфигурационные файлы и открывает заново log-файлы. Затем он порождает новых потомков и продолжает обработку запросов. Статистика сервера при получении сигнала HUP полностью обнуляется. Если Ваш конфигурационный файл содержит ошибки, то попытка перезапустить сервер вызовет немедленное прекращение его работы с сообщением об ошибке.

Мягкий перезапуск

Сигнал: USR1

apachectl -k graceful

При получении сигнала USR1 или graceful, родительский процесс призывает дочерние процессы к завершению работы сразу же после обработки своего текущего запроса (или к незамедлительной остановке, если дочерний процесс ничего не обрабатывает). Родительский процесс перечитывает конфигурационные файлы, открывает заново log-файлы. После того, как какой-то из дочерних процессов завершает работу, родительский процесс заменяет его дочерним процессом нового поколения, т.е. с новой конфигурацией, который начинает обрабатывать новые запросы незамедлительно.

На некоторых платформах, не поддерживающих передачу сигнала USR1 как сигнала для инициации мягкого перезапуска, могут использоваться другие сигналы (такие как WINCH). Команда apachectl graceful отправит корректный сигнал на любой платформе.

Программа разработана таким образом, что количество процессов и потоков, определённое директивами MPM-модуля, оставалось неизменным на протяжении всего процесса перезапуска. Кроме того, для поддержания числа запущенных процессов, определённого директивой StartServers, используется следующий способ:

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

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

Статистика сервера при получении сигнала USR1 не обнуляется. Так было сделано для того, чтобы уменьшить промежуток времени, в течение которого сервер не может обрабатывать новые запросы (которые операционная система будет ставить в очередь, т.е. они не пропадут в любом случае), а также для того, чтобы учитывать измененные настройки. Для этого сервер хранит таблицу статистики, в которую записываются результаты работы всех дочерних процессов, вне зависимости от их поколения. Модуль mod_status также использует символ G, чтобы обозначить те дочерние процессы, которые всё ещё обрабатывают запросы и которые были созданы до сигнала к мягкому перезапуску.

В настоящее время нет способа определить, что все дочерние процессы закончили запись в старый log-файл (т.е. log-файл, в который производилась запись до перезапуска). Рекомендуется подождать некоторое время, после того как будет послан сигнал USR1, прежде чем делать что-либо со старым log-файлом. Например, если на выполнение запросов пользователей, подключённых через очень медленный канал, уходит не более 10 минут, тогда логично будет подождать 15 минут, прежде чем делать что-либо со старым log-файлом.

Если конфигурационный файл содержит ошибки, то попытка перезапустить сервер вызовет немедленное прекращение работы родительского процесса с сообщением об ошибке. В случае мягкого перезапуска дочерние процессы продолжают обрабатывать свои запросы, после чего они завершат свою работу. Это может вызвать проблемы, так как сервер не будет в состоянии установить соединение с необходимыми портами. Перед выполнением перезапуска, следует проверить синтаксис конфигурационных файлов с помощью параметра -t командной строки. Однако это всё ещё не гарантирует, что сервер перезапустится корректно. Чтобы проверить семантику конфигурационных файлов, равно как и их синтаксис, можно попробовать запустить httpd, будучи непривилегированным пользователем. Если ошибки отсутствуют, то httpd попытается открыть сокеты и log-файлы, но не сможет этого сделать, потому что у него отсутствуют необходимые для этого права (или потому что в текущее время работающий httpd уже установил соединение с нужными портами, заняв их). Если сбой происходит по любой другой причине - значит, скорее всего, существует ошибка в конфигурационном файле, которая должна быть исправлена перед началом мягкого перезапуска.

2.2.5 Обновление web-сервера Apache

Первым шагом при обновлении является чтение информации о релизе и файла CHANGES, находящегося в дереве исходных кодов - это поможет понять, каким образом обновление повлияет на ваш текущий web-сервер. При переходе между разными ветками сервера (например, с 1.3 на 2.0, или с 2.0 на 2.2), появляются существенные нововведения в конфигурировании процесса сборки или работы сервера, которые потребуют анализа и ручной настройки. Все модули также необходимо будет обновить, для того чтобы они могли соответствовать изменениям.

Обновление, осуществляемое внутри одной ветки сервера (например, с 2.0.55 на 2.0.57) существенно проще. Выполнение команды make install не перезапишет никакие существующие документы, файлы логов или конфигурационные файлы. В дополнение к этому, разработчики сервера сделали всё возможное, чтобы избежать несовместимости в опциях скрипта configure, рабочей конфигурации сервера и API модулей для разных младших релизов внутри одной ветки. В большинстве случаев можно использовать идентичную строку запуска скрипта configure, тот же самый конфигурационный файл и быть уверенным, что все модули продолжат работать. (Это верно только для версий сервера, начиная с 2.0.41; предыдущие версии имеют несовместимые изменения.)

Для обновления с одного младшего релиза на другой, следует найти файл config.nice, который должен находиться либо в каталоге build сервера, либо в корне дерева исходных кодов рабочего сервера. Этот файл содержит в себе точную копию строки запуска скрипта configure, которая использовалась при конфигурировании дерева исходных кодов установленной версии сервера. Затем, чтобы осуществить обновление, нужно скопировать файл config.nice в дерево исходных кодов новой версии сервера, внесите в него все необходимые изменения, а затем выполнить следующие команды:

/config.nice make make install

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

linux сервер виртуальный хост

2.3 Конфигурирование web-сервера Apache

2.3.1 Основные настройки web-сервера Apache

Настройка сервера осуществляется с помощью текстового файла httpd.conf, состоящего из директив. Имя файла можно изменить при запуске сервера ключом "-f". Директива Include позволяет вставлять содержимое дополнительных файлов (можно указывать шаблон имени или имя каталога). Для вступления в действие изменений файла настройки необходимо перезапустить сервер. Некоторые директивы могут ссылаться на дополнительные файлы с другим синтаксисом. Каждая директива располагается на отдельной строке. Продолжение на следующую строку делается с помощью символа '\' в конце строки. Комментарии начинаются с символа '#'. Пробелы в начале строки игнорируются.

Сервер состоит из множества модулей, которые могут выбираться при сборке или загружаться динамически. Модуль Core отключить нельзя. Каждая директива определяет поведение одного из модулей и имеет смысл только, если этот модуль включен при сборке или с помощью динамической загрузки. Директивы могут выполняться в зависимости от наличия модуля (секция IfModule) или установки параметра при запуске сервера (секция IfDefine).

Секция IfDefine включает директивы, применяемые только если при запуске сервера была установлена (не установлена) соответствующая переменная (ключ -D):

<IfDefine [!]имя-переменной>

...